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.”
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.