MQTT
Assembly Line
Using MQTT Store and Forward + Canary
Unlocking the Full Potential of Manufacturing Capabilities Through Digital Twins on AWS
In this post, we will explore the collaboration between Amazon Web Services (AWS) and Matterport to create a digital twin proof of concept (POC) for Belden Inc. at one of its major manufacturing facilities in Richmond, Indiana. The purpose of this digital twin POC was to gain insights and optimize operations in employee training, asset performance monitoring, and remote asset inspection at one of its assembly lines.
The onsite capture process required no more than an hour to capture a significant portion of the plant operation. Using the industry-leading Matterport 3D Pro3 capture camera system, we captured high-resolution imagery with high-fidelity measurement information to digitally recreate the entire plant environment.
The use of MQTT protocol to natively connect and send equipment data to AWS IoT Core further streamlined the process. MQTT, an efficient and lightweight messaging protocol designed for Internet of Things (IoT) applications, ensured seamless communication with minimal latency. This integration allowed for quick access to critical equipment data, facilitating informed decision making and enabling proactive maintenance measures.
Throughout the plant, sensors were strategically deployed to collect essential operational data that was previously missing. These sensors were responsible for monitoring various aspects of machine performance, availability, and health status, including indicators such as vibration, temperature, current, and power. Subsequently, the gathered operational data was transmitted through Belden’s zero-trust operational technology network to Belden Horizon Data Operations (BHDO).
Securely sending industrial data to AWS IoT services using unidirectional gateways
Unidirectional gateways are a combination of hardware and software. Unidirectional gateway hardware is physically able to send data in only one direction, while the gateway software replicates servers and emulates devices. Since the gateway is physically able to send data in only one direction, there is no possibility of IT-based or internet-based security events pivoting into the OT networks. The gateway’s replica servers and emulated devices simplify OT/IT integration.
A typical unidirectional gateway hardware implementation consists of a network appliance containing two separate circuit boards joined by a fiberoptic cable. The “TX,” or “transmit,” board contains a fiber-optic transmitter, and the “RX,” or “receive,” board contains a fiber-optic receiver. Unlike conventional fiber-optic communication components, which are transceivers, the TX appliance does not contain a receiver and the RX appliance does not contain a transmitter. Because there is no laser in the receiver, there is no physical way for the receiving circuit board to send any information back to the transmitting board. The appliance can be used to transmit information out of the control system network into an external network, or directly to the internet, without the risk of a cyber event or another signal returning into the control system.
The Blueprint for Industrial Transformation: Building a Strong Data Foundation with AWS IoT SiteWise
AWS IoT SiteWise is a managed service that makes it easy to collect, organize, and analyze data from industrial equipment at scale, helping customers make better, data-driven decisions. Our customers such as Volkswagen Group, Coca-Cola İçecek, and Yara International have used AWS IoT SiteWise to build industrial data platforms that allow them to contextualize and analyze Operational Technology (OT) data generated across their plants, creating a global view of their operations and businesses. In addition, our AWS Partners such as Embassy of Things (EOT), Tata Consulting Services (TCS) Edge2Web, TensorIoT, and Radix Engineering have made AWS IoT SiteWise the foundation for purpose-built applications that enable use cases such as predictive maintenance and asset performance monitoring. Through these engagements with customers and partners, we have learned that the main obstacles in scaling digital transformation initiatives include project complexity, infrastructure costs, and time to value.
With newly added APIs, AWS IoT SiteWise now allows you to bulk import, export, and update industrial asset model metadata at scale from diverse systems such as data historians, other AWS accounts, or – in the case of AWS Independent Software Vendors (ISV) Partners – their own industrial data modeling tools.
To collect real-time data from equipment, AWS IoT SiteWise provides AWS IoT SiteWise Edge, software created by AWS and deployed on premises to make it easy to collect, organize, process, and monitor equipment at the edge. With SiteWise Edge, customers can securely connect to and read data from equipment using industrial protocols and standards such as OPC-UA. In collaboration with AWS Partner Domatica, we recently added support for an additional 10 industrial protocols including MQTT, Modbus, and SIMATIC S7, diversifying the type of data that can be ingested into AWS IoT SiteWise from equipment, machines, and legacy systems for processing at the edge or enriching your industrial data lake. By ingesting data to the cloud with sub-second latency, customers can use AWS IoT SiteWise to monitor hundreds of thousands of high-value assets across their industrial operations in near real time.
Sparkplug: From Specification to Standard
The Eclipse Foundation announced that the Sparkplug® 3.0 specification has been published as an International Standard. The publication of Sparkplug as an international standard is the outcome of a transposition of the specification through the Publicly Available Specification (PAS) transposition process offered by the ISO and IEC Joint Technical Committee (JTC 1) for information technology, a consensus-based, voluntary international standards group. Going forward, Sparkplug will also be known as ISO/IEC 20237. This mirrors the case of MQTT, which has been standardized as ISO/IEC 20922 in 2016.
☁️🧠 Automated Cloud-to-Edge Deployment of Industrial AI Models with Siemens Industrial Edge
Due to the sensitive nature of OT systems, a cloud-to-edge deployment can become a challenge. Specialized hardware devices are required, strict network protection is applied, and security policies are in place. Data can only be pulled by an intermediate factory IT system from where it can be deployed to the OT systems through highly controlled processes.
The following solution describes the “pull” deployment mechanism by using AWS services and Siemens Industrial AI software portfolio. The deployment process is enabled by three main components, the first of which is the Siemens AI Software Development Kit (AI SDK). After a model is created by a data scientist on Amazon SageMaker and stored in the SageMaker model registry, this SDK allows users to package a model in a format suitable for edge deployment using Siemens Industrial Edge. The second component, and the central connection between cloud and edge, is the Siemens AI Model Manager (AI MM). The third component is the Siemens AI Inference Server (AIIS), a specialized and hardened AI runtime environment running as a container on Siemens IEDs deployed on the shopfloor. The AIIS receives the packaged model from AI MM and is responsible to load, execute, and monitor ML models close to the production lines.
A Comparative Analysis of Data Modelling Standards for Smart Manufacturing
In essence, adopting data modeling standards can facilitate seamless data exchange across the entire value chain, enhancing overall efficiency and cooperation among various applications and machines. Crucial to this evolution is semantic modeling, allowing machines to deduce meaning without human intervention. Thus, the concept of information modeling, encapsulating not only data but its meaning, is paramount to facilitating intelligent, autonomous decisions.
The Digital Twin Definition Language (DTDL) language follows JSON syntax but is based on JSON-LD. JSON-LD, or JSON for Linked Data, is a method of encoding Linked Data using JSON. It is a World Wide Web Consortium (W3C) standard that provides a way to enrich your data by contextualizing it with schemas (vocabularies) that you choose. This makes it easy to define complex models and relationships between different parts of a system.
Sparkplug and OPC UA, on the other hand, provide a way to structure data and ensure interoperability. Sparkplug uses MQTT and Protocol Buffers, focusing on SCADA/IIoT solutions and efficient data encoding, while OPC UA provides a more generalized approach, offering industry-specific guidelines through companion specifications.
Flexible, Low-Cost Water Monitoring with Edge I/O
Using the CODESYS control engine on the network’s main controller, an Opto 22 groov EPIC, the team configured each station as a remote I/O point, wrote polling logic, and defined appropriate alarm limits. CODESYS is the team’s preferred control platform because it allows them to use all the IEC languages where they are most appropriate. Typically, they use Structured Text (ST) for math and time calculations, Function Block (FB) for the main program routine, and Ladder (LD) when they need to orchestrate a specific sequence of actions.
Jared’s team decided to flip their approach. Instead of scanning all the remote I/O at high resolution from the main controller, they connected these three sites to an MQTT broker using the modules’ native MQTT publishing capabilities. They chose to use HiveMQ’s cloud-native MQTT broker, which allows 100 MQTT clients to communicate for free, keeping maintenance costs down for the district.
With the exception of the HiveMQ broker, all of this functionality—control engine, HMI server, Node-RED, MQTT publish-subscribe communication, device security—runs on the groov devices and does not require a Windows PC or external server for data or communication.
How United Manufacturing Hub Is Introducing Open Source to Manufacturing and Using Time-Series Data for Predictive Maintenance
The United Manufacturing Hub is an open-source Helm chart for Kubernetes, which combines state-of-the-art IT/OT tools and technologies and brings them into the hands of the engineer. This allows us to standardize the IT/OT infrastructure across customers and makes the entire infrastructure easy to integrate and maintain. We typically deploy it on the edge and on-premise using k3s as light Kubernetes. In the cloud, we use managed Kubernetes services like AKS. If the customer is scaling out and okay with using the cloud, we recommend services like Timescale Cloud. We are using TimescaleDB with MQTT, Kafka, and Grafana. We have microservices to subscribe to the messages from the message brokers MQTT and Kafka and insert the data into TimescaleDB, as well as a microservice that reads out data and processes it before sending it to a Grafana plugin, which then allows for visualization.
We are currently positioning the United Manufacturing Hub with TimescaleDB as an open-source Historian. To achieve this, we are currently developing a user interface on top of the UMH so that OT engineers can use it and IT can still maintain it.
Building Industrial Digital Twins on AWS Using MQTT Sparkplug
Even better, a Sparkplug solution is built around an event-based and publish-subscribe architectural model that uses Report-By-Exception for communication. Meaning that your Digital Twin instances get updated with information only when a change in the dynamic properties is detected. Firstly, this saves computational and network resources such as CPU, memory, power and bandwidth. Secondly, this results in a highly responsive system whereby anomalies picked up by the analytics system can be adjusted in real-time.
Further, due to the underlying MQTT infrastructure, a Sparkplug based Digital Twin solution can scale to support millions of physical assets, which means that you can keep adding more assets with no disruptions. What’s more, MQTT Sparkplug’s definition of an MQTT Session State Management ensures that your Digital twin Solution is always aware of the status of all your physical assets at any given time.
Heineken’s Event-Driven Connectivity Strategy
To understand the scope of this connectivity project, it’s important to realize that Heineken runs more than 3,500 applications globally, connecting them with more than 5,000 interfaces. ERP systems in use across the company include SAP, Oracle’s JD Edwards, and Microsoft Dynamics, as well as the Hybris and Virto e-commerce platforms, Salesforce customer relationship management, and various manufacturing execution and invoicing systems.
Groeneweg adds that, with its new event-driven system in place, Heineken can now deploy scalable “plug-and-play” technologies quickly to take advantage of timely business insights at scale. To explain this, Groeneweg offers an example involving the introduction of a new global invoice management application. Before the implementation of Heineken’s event-driven system, multiple point-to-point integrations would need to be built to embed the new application into the company’s IT landscape. “We would have to connect it to at least 20 applications to get master data, ERP data, customer data, etc.,” says Groeneweg. “With the event-driven approach, we just point the chatbot to the right topics and queues where the data is already available from all the source systems it needs to access. No integration work is required at all.”
Connecting Factories Seamlessly with Azure and MQTT
Integrating Falkonry with Azure IoT
Falkonry Clue applies advanced analytics to multivariate time-series data to discover meaningful patterns. This valuable operational data is supplied to Clue’s powerful AI engine by leveraging Microsoft Azure’s IoT infrastructure. Clue is designed to fit seamlessly into Azure’s reference architecture thereby easing the integration process.
Connecting the plant to the cloud, the Azure IoT Hub acts as a bi-directional communications brain for all connected IoT devices – managing data transfers, updates, setting up credentials for every device, and defining access control policies. These connected devices include OPC UA enabled sources such as most SCADA systems that support the MQTT protocol for data transfer.
Application Layer Protocol Options for M2M and IoT Functionality
With adoption of Internet of Things (IoT) and Industry 4.0 functions, devices are increasingly connected via industrial protocols. What’s more, today’s machine to machine (M2M) communications are rapidly standardizing on these protocols. Complicating matters is that IoT protocols don’t describe a single application-layer protocol, as several standards are in operation. So while early IoT implementations used standard internet protocols, there are also dedicated IoT protocols now available.
Modeling communication structures and identifying the right protocol for a particular application can be daunting. This article outlines what various protocols do as well as the options available for these protocols — so design engineers can more easily select the most suitable to integrate.
Apache Kafka and MQTT (Part 1 of 5) – Overview and Comparison
Apache Kafka and MQTT are a perfect combination for many IoT use cases. This blog series covers the pros and cons of both technologies. Various use cases across industries, including connected vehicles, manufacturing, mobility services, and smart city are explored. The examples use different architectures, including lightweight edge scenarios, hybrid integrations, and serverless cloud solutions. This post is part one: Overview and Comparison.