MQTT
Assembly Line
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.