MQTT-enabled Sitewise Gateways

Use an MQTT-enabled AWS IoT Sitewise gateway to send data from various industrial equipment, using SFC, to Sitewise Service in the cloud. An example showing how to ingest data to Sitewise from Modbus equipment.

Overview of MQTT-enabled Sitewise Gateways

The External Broker Integration represents a fundamental evolution in AWS IoT SiteWise Edge's architecture, introducing a more streamlined and flexible approach to data handling. At its core, the system now operates the MQTT broker that results the backbone across the function of data collection, processing, and transmission. The system is based on three main components that are :

MQTT Broker, serves as the heart of the system. It functions as a central communication hub where all internal components interact and exchange information. It provides an external interface that allows for custom integrations, making the system more versatile and adaptable to various industrial needs.
OPC-UA Collector, operates as a specialized MQTT client. Its primary role is to gather data from OPC-UA sources and publish this information through the MQTT broker. This component ensures reliable data acquisition from industrial systems while maintaining compatibility with existing OPC-UA infrastructure.
SiteWise Publisher, acts as the bridge between edge and cloud storage and data modeling.It efficiently manages the transmission of the ingested data to AWS IoT SiteWise Cloud, with related capabilities of store and forward (for loss of internet connectivity). ensuring that data is securely stored in the cloud.

This architectural redesign brings several significant advantages. The standardization of communication through MQTT protocols simplifies the overall system while maintaining robust functionality. The flexible integration capability allows external modules - External Protocol Concerters - to connect seamlessly as MQTT clients, similar to the built-in OPC-UA collector creating a unified data flow ensures that all data, regardless of its source, follows a consistent path through the MQTT-based pipeline, using standardized topic structures for the measurement identification. The result is a system where OT and custom protocols can be integrated with the same ease as native protocols like OPC-UA. This uniformity in data processing and filtering enables organizations to combine data from diverse sources into a single, cohesive asset management system.

Figure 1: MQTT-enabled Sitewise Gateway - Open for external Protocol-Converters

MQTT-enabled Gateway - Message Format

The MQTT message format follows the AWS IoT SiteWise API standard, utilizing a JSON structure that specifies both 'alias' and 'values' properties. Here's an example of the required format:

Key components of the message format:

propertyAlias: A unique identifier that maps to the asset property in AWS IoT SiteWise
propertyValues: An array containing measurement data points
- value: The actual measurement value
- timestamp: The Unix timestamp in milliseconds with nano second where is needed
- quality: quality of the measurements

This standardized format ensures consistent data handling and proper integration with AWS IoT SiteWise's asset modeling system. All MQTT messages must adhere to this structure for successful data ingestion and processing. The 'propertyAlias' plays a fundamental role in the AWS IoT Publisher's filtering and routing mechanisms. This identifier must maintain consistency with the MQTT topic structure to ensure proper data flow. The propertyAlias structure should mirror your MQTT topic hierarchy, making IoT SiteWise ready for the implementation of a Unified Name Space (UNS).

An Integration Example using SFC

In this example, we will demonstrate how to integrate a cold room refrigeration system with AWS IoT SiteWise. The refrigeration system exposes data via Modbus TCP protocol, and we will utilize the Shopfloor Connectivity (SFC) framework as external protocol converter, collecting and publishing the data to the local MQTT broker.

Figure 2: SFC used as External protocol converter, collecting fom Modbus-TCP & sending to local MQTT broker

As shown in Figure 2, the demonstration system consists of five main components:

Cold Room Equipment simulator (Modbus TCP). The physical refrigeration system being monitored, equipped with Modbus TCP capability for data communication.
SFC handles protocol conversion and data transformation from Modbus TCP to MQTT.
AWS IoT SiteWise Edge component that processes and manages data collection, including the MQTT broker for message handling.
AWS IoT SiteWise Cloud - The cloud service that stores, processes, and manages asset data and models.
Visualization Interface The dashboard system that displays real-time cold room monitoring data and analytics.

Steps

The SFC supports several OT protocols, and implement message manipulation through Velocity templates. That gives the possibility to ingest data from different protocols with simple configuration avoiding to write any code.

Login to SW Gateway and clone Repo

Login to your v3 MQTT-enabled Sitewise Gateway
fyi check the running containers: run docker ps - you should see the emqx container bound to port 1883 (that is the mqtt port where we will send data later)
clone that repo:

Run Modbus simulator

Modbus simulation will be started at port 502
Make sure to have the program running detached from your current shell using e.g. screen

Install SFC

We're using ready to use kotlin SFC binary modules, available as tar.gz from github

sfc-main - the core module, receiving config and doing all the source/target processing.
mqtt-target - generic mqtt adapter, to send data to mqtt broker topics
debug-target - inspect the SFC-Output in stdout
modbus-tcp - adapter, to read from modbus devices

Inspect the SFC config and Velocity Template

Note: SFC also comes with a native SitewiseEdge Adapter, having all mappings for the the v3 MQTT-enabled Gateway already included. That example here shows the generic payload-transformation capabilities of SFC.

The json file sfc-config.json represents an in-process SFC configuration. It does:

define the Sources and the source-channels (=modbus registers)
define the Targets, where the source data is sent to (=mqtt broker) - related by one or more Schedules
- within the Targets.swMqttTarget config sections we set TopicName to %channel%. The Mqtt-Target adapter supports to use source channel names as dynamic variables, in order to fan out each channel value to a matching mqtt-topic (channel-name==mqtt-topic-name).
- within the Targets.swMqttTarget config sections we set Template to reference an Apache Velocity Template
- within the Targets.swMqttTarget config sections we set TemplateEpochTimestamp to true, so that epochTimestamps are available in the Velocity Template context.
- Template and TemplateEpochTimestamp are needed to transform the standard SFC Output Format to a Sitewise BatchPutAssetPropertyValue

sfc-config.json

Definition of the source: The source definition consists of two essential components that work together to establish the data collection framework. The first component is the Endpoint Configuration, which defines all necessary connection parameters to the data source. This includes the protocol-specific settings, connection credentials, network address and port information, as well as communication timeouts.

The second component is the Data Structure Definition, which specifies exactly what data needs to be collected from the source. This encompasses the measurement points, their respective data types and specific reading parameters. The data structure definition ensures that the system knows precisely which information to collect and how to interpret it.

Definition of the target Like in the source the Targets section defines all necessary connection parameters to the target and the related template for the message transformation.

Message transformation SFC includes a built-in Velocity template capability that simplifies message formatting for AWS IoT SiteWise. This template automatically handles the conversion of data into the required AWS IoT SiteWise JSON format. Through simple configuration settings, the template ensures that messages are properly structured with the required 'alias' and 'values' properties. This eliminates the need for custom code development and reduces the complexity of message transformation.

swBatchPutTemplate.vm

sfc-config.json

Definition of the reading frequency The final component of the configuration involves setting the data ingestion frequency, which, in the case of Modbus, corresponds to the reading frequency from the device. This setting determines how often the system polls the Modbus device for new data.

Run SFC

Check Data in Sitewise Service

With the system successfully configured, we can now leverage AWS IoT SiteWise Monitor's capabilities to visualize and analyze cold room data with :

Dashboard Creation, Create customized dashboards to display real-time and historical data from refrigeration systems. These dashboards can include temperature trends, operational metrics, and system status indicators.
Alarm Configuration ,Set up alarms to monitor critical parameters and receive notifications when values exceed predetermined thresholds. This ensures prompt response to potential issues in your cold room operations.
Data Analysis, Access comprehensive data visualization tools to analyze performance trends, identify patterns, and optimize your refrigeration system's operation.

Figure 3: Sitewise Monitor

Conclusion

This architectural enhancement of AWS IoT SiteWise Edge significantly expands the potential for custom integrations in industrial IoT scenarios. The new MQTT-based architecture delivers three key advantages:

Legacy System Integration Organizations can now seamlessly integrate legacy systems that use proprietary protocols, preserving existing infrastructure investments while modernizing data collection capabilities.
Specialized Equipment Support The architecture enables direct incorporation of data from specialized sensors and equipment, regardless of their native communication protocols, expanding monitoring capabilities across diverse industrial assets.
Environmental Adaptability The flexible architecture allows for customized solutions that adapt to unique industrial environments, accommodating specific operational requirements and constraints.

By leveraging this MQTT-based architecture, manufacturers can create comprehensive IoT solutions that unite diverse data sources. This integration capability leads to more efficient operations, better decision-making, and enhanced industrial process insights.

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Site Terms, Privacy, and more.