In addition to connectivity, storing the recorded data is crucial for continuous improvement and data-based analyses. In this context, in addition to a unified namespace (UNS) for connection, the introduction of a historian is also necessary. This stores data for the long term and provides analysis tools. Integrating a historian into the UNS – i.e. the integration of the historian into MQTT – standardizes and simplifies access to this data. The following guide describes the technical implementation of this integration to create the conditions for data-based process optimization in your smart factory.
Options for integrating Historian with MQTT
When integrating UNS / MQTT with Historian, it is particularly important to consider the data modelling (topics and payload), as the correct contextualization and uniform storage of the data simplifies subsequent analysis or makes it possible in the first place. This translation is typically the matching of the UNS namespace (e.g. modeled according to ISA95) to the asset model available in the Historian. 
In practice, this integration of Historians to MQTT is realized in two ways: via a gateway or via direct communication using interfaces already available in the Historian. The selection of the appropriate option depends on the specific use-case requirements and the existing infrastructure. 
Option 1: Gateway
A gateway is often necessary, as not all historians have a direct connection option. In addition, a gateway acts as a central transformation unit that builds the bridge between the asset/data models in the UNS (usually ISA-95) and the specific asset model of the respective historian. This harmonization ensures consistent and seamless integration of the data, even if the systems have different structures.
Option 2: Direct communication
Compatible data historians can be connected to the MQTT broker of the UNS via an integrated interface, which enables uncomplicated data exchange. However, this method lacks standardized structures for topics and payloads, which can lead to inconsistencies. In addition, the asset/data model in the historian must match the UNS exactly, otherwise there is a risk of inconsistent data records. Many MES applications also do not support a native MQTT connection, which makes direct integration difficult or even impossible.
Step-by-step guide
As an MQTT connection is not available for many data historians today or can only be programmed at high additional cost, the gateway solution is examined in more detail below.
1) Prerequisites
Check the existing infrastructure and configure the necessary access rights to the systems to ensure reliable integration.
Check infrastructure: Check whether the Data Historian and MQTT Broker are fully functional and set up a test environment. This allows you to test the integration and subsequent adjustments in a controlled environment before making changes in the production environment.
Select a gateway: Ensure that your gateway natively supports Historian and MQTT protocols. Check compatibility with other relevant systems (e.g. control systems, ERP) in your OT/IT landscape. Ensure that the gateway offers the required security features. Depending on the use case, the gateway should meet additional requirements (e.g. redundancy, scalability). Configure the network: Make the necessary adjustments to your network topology. This includes the configuration of ports and firewalls to enable communication and at the same time prevent unauthorized access.
Access and authorizations: Ensure that you have access to the Data Historian, the MQTT Broker as well as the Gateway. This also includes the necessary user rights and authorizations to be able to make configurations. If necessary, install the corresponding configuration software for the systems.
2) Identify Data Historian Asset Model
This step is about understanding the specific asset model and data structure of your data historian. This information is crucial for successful integration into the UNS.
Find out how assets are modelled in the Data Historian: Analyze how assets (e.g. machines, plant parts) are structured and organized in the Data Historian. This structure is later used to create unique and meaningful MQTT topics that contextualize the data in the UNS.
Examine the data modelling in the Data Historian: Investigate how data is stored and structured in the Data Historian. What data types (e.g. numeric values, text, timestamps) are used? How are the data points organized (e.g. in tables, hierarchical structures)? This information is important to correctly translate the data into MQTT messages and publish them in the UNS.
Identify UNS data that requires trend analysis: Identify which data in the UNS is relevant for trend analysis and long-term considerations. This data is typically obtained from the Data Historian. Determine which events or conditions should trigger the sending of data from the Data Historian to the UNS (e.g. periodic updates, changes to specific data points).
3) Define MQTT namespace
The data models and topic structures from the Data Historian recorded in the second step must now be carefully adapted to the Unified Namespace (UNS). This ensures a uniform and consistent data landscape that can be used and understood company-wide. There are two key aspects to consider: Topic structure: The design of the MQTT topics is crucial to making historical data understandable across production lines and locations. A best practice is to use the ISA95 standard, which provides a clear and hierarchical structure for organizing production data. Data modelling: Uniform data modelling ensures that data is available in uniform formats and units throughout the company. This enables scalable use of the data by all participants in the UNS. Additionally, facilitates the integration of different systems and applications.
4) Integration of Historian to MQTT namespace
In this step, you establish a connection between the gateway, the data historian and the MQTT broker. The gateway acts as a bridge between the two protocols and translates Historian assets into standardized UNS topics.
Connectivity test: Check the connectivity between your Data Historian, Gateway and the MQTT Broker. Pay particular attention to compliance with the security guidelines. This includes the correct setup of authentication and encryption methods.
Mapping the MQTT payload: Map the relevant nodes from the Historian namespace to the data model defined in step 3. If necessary, complete the data model with static inputs (e.g. for metadata such as machine type and ID).
Mapping the MQTT topics: Specify how the MQTT payloads are mapped to the MQTT topics. This can include simple 1:1 mappings or, depending on the use case requirements, require more complex transformations.
Implement transformation logic: Use the functionalities of your gateway to perform the required data conversions. This can include the scaling of measured values, the conversion of data types or the aggregation of data points.
5) Integration in test environment
Define message transmission: Specify when the historical data should be updated in MQTT. The update can take place when specific historian data changes (best practice) or according to a predefined cycle (e.g. every second). You can also define important MQTT settings such as Quality of Service (QoS), Retain and Report by Exception. Check data integrity: Ensure that the data in your test environment flows correctly from the data historian via the gateway to the MQTT broker and that all security mechanisms work as planned.
6) Go-Live and monitoring
Go-live: After successful testing, you can put the Historian to MQTT integration into operation. Set up monitoring: Implement monitoring and alerting features to continuously monitor system performance and data transmission integrity. Logging and diagnostics: Ensure that detailed logs are available for troubleshooting and optimizing system performance.
Conclusion
The integration of Historian with MQTT into a Unified Namespace allows companies to maximize the value of their data. This approach enables data-driven learning and improves industry processes. It also provides a long-term solution for storing historical process data. The data becomes accessible for trend analysis and optimization. Whether using a direct connection or a gateway, seamless integration is key. It unlocks the full potential of data within the UNS framework.
