Azure IoT Reference Guide For Industrial Equipment Manufacturers (Part 2)
Azure IoT Reference Guide For Industrial Equipment Manufacturers (Part 2)
Check out this guide on using the Azure IoT Reference Architecture for the manufacturing of industrial equipment. Click here to learn more!
Join the DZone community and get the full member experience.Join For Free
Digi-Key Electronics’ Internet of Things (IoT) Resource Center Inspires the Future: Read More
This Azure IoT reference implementation guide provides industrial equipment manufacturers with an accelerated, flexible path for delivering differentiated connected products to gain a competitive advantage through digital transformation with Microsoft Azure. This guide follows the best practices and patterns outlined in the official Microsoft Azure IoT Reference Architecture with additional domain-specific recommendations and in-depth walkthroughs based on Bright Wolf’s decade of experience designing and delivering industrial connected products for some of the largest companies in the world.
Collecting and transforming data from pumps, motors, filters, chillers, and other industrial equipment across manufacturing, oil and gas, cold chain transportation, healthcare, agriculture, and other verticals – and integrating this data into enterprise business systems for generating insights and actions embedded inside your customers’ operations – presents a unique set of challenges for equipment manufacturers that don’t apply to other kinds of IoT projects. These include incorporating legacy devices already deployed in the field, achieving and maintaining regulatory compliance, and integrating securely with a wide variety of applications and business tools across multiple business units and product lines.
Bright Wolf works directly with industrial OEMs from prototype to production to help you design and commercialize connected versions of your products. We refer to this “Thing Maker” sub-category of IoT as connected product systems. This document is intended for product management and technical teams in engineering who are considering developing an industrial Connected Product System on Azure.
Connected Product Specific Design Considerations (Cont'd)
There are many design considerations that a connected product architect needs to consider when planning the development of the system. This section highlights the key considerations.
There is a complex set of considerations regarding pending commands that are being held on the cloud side, waiting for the device to connect again. Sometimes these commands may cancel each other out and shouldn’t be performed at all. Other times the commands may have a time to live before they are no longer valid. The state machine to manage this logic is often custom based on the specific control model of the device. Building this control capability directly from cloud primitives and verifying the control loop for correctness can be challenging.
Devices, Connectivity, Field Gateways (Edge Device), Cloud Gateway
One additional consideration of this topic is the situation where devices exist outside of the synchronized time domain. In terms of the Network Time Protocol (NTP), these are stratum 16 devices. In these cases, it is critical for the first device that has access to a synchronized time source to attempt to timestamp the events and telemetry data to the best of its ability. It is frequently the case that these timestamps have some degree of ambiguity. It can be useful to upstream consumers to pass along that variability, along with information about the order of arrival.
Topology and Entity Store
The Azure IoT Reference Architecture describes the topology and entity store as a foundational component of your IoT system. Implementing this part of the system is time-consuming, difficult work that is central to the success and longevity of the system. In an effort to move quickly to a prototype, most system design projects shortcut these important aspects and later regret that decision as retrofitting foundational architecture proves prohibitive. This is further exacerbated as the initial system grows or is replicated across multiple product lines or business units within a company or organization.
Similar to other enterprise infrastructure components leveraged by development teams for IoT projects, Bright Wolf provides production-ready services in this area, enabling development projects to proceed quickly without sacrificing these critical design factors. This foundation layer provides a flexible IoT data/Metadata model and data management API layer for your topology and entity store. The data itself is still stored in Azure managed data stores in your Azure subscription, ensuring that you stay in control of your data.
Rather than implement access control checks in all of your application code, declarative policy descriptions enable enforcement of access control over the data in your topology and entity store. You can have one topology and entity store for all your customers and feel confident that they can’t see each other’s data, with a hierarchical and tag-based organization by the customer, customer site, sub-site, and groups, granting role assignments in various contexts such as device type, customer, customer site and sub-site.
Business Systems Integration and Back-end Application Processing
For connected product systems, the enterprise API is one of the most critical aspects of the entire system, requiring diligence and design for the solution to be capable of delivering the required business outcomes. The API should exist between the system and all other consumers of data from the system. This provides a stable boundary that can be managed as the product evolves. Web Applications, Mobile and Voice Applications and Enterprise systems (including those implemented with Azure Logic Apps) should interact with the connected product system through its API. Implementing these integrations through an API prevents tight coupling between systems, provides flexibility in evolving the system over time and prevents cascading failure modes between systems. It also ensures proper data and user policy enforcement for all consumers of the API, as described in the User Management paragraph.
Machine Learning (At-Rest Data Analytics)
Predictive Models take significant volumes of data to train. These models must then be deployed, and the required input data must be shared with the model to generate predictions. These predictions are then made available to the system applications and end users.
Perhaps the most important aspect of an ML-enabled industrial IoT system is the concept of learning loops. Learning loops are feedback loops from humans in the field on the accuracy of the prediction. This feedback mechanism is critical in two ways:
- Providing a feedback mechanism to humans beings provides them with a voice in the system and has been found to greatly aid in adoption rates for relying on predictions.
- Data scientists desperately need feedback on the performance of their models in the real world.
As a best practice, the feedback on the prediction accuracy should be collected and stored them in the entity and topology store and accessed through the IoT System API.
Industrial Learning Loops and Predictive Maintenance
Connected product makers are uniquely positioned at the right point in the value chain to develop a large and varied enough training set to train predictive maintenance models for their products. To improve the accuracy of their models over time, feedback should be collected from the consumers of each prediction, such as a “yes/no” response from service technicians as to whether or not each machine reported as needing service did, in fact, have issues requiring attention. Such learning loops are critical to the evolution of your predictive model over time as well as for gaining acceptance of the value of the prediction by field service staff.
Asset Vs Device Lifecycle
In IoT, while devices may be sending the data, it is the assets that are the logical thing being monitored. There are several cases where this distinction can matter over time:
Asset Sale – Some of the time stream data should be available to the new owner and some of the data should not. For example, the maintenance data should transfer to the new owner, but the prior location or performance history should not transfer.
Device Malfunction – A device may cease to function due to a variety of reasons. A new device should be logically associated with the asset without interrupting the history of the asset’s data and metadata.
Device Return – Devices may be returned by a customer and reconditioned and sent out to another customer. In this case, a device needs to associate its data with a new asset. The new asset owner should not be able to see any of the data of the prior asset.
Here is a more detailed look at an Azure IoT cloud architecture following best practices outlined in the Microsoft Azure IoT Reference Architecture. Bright Wolf components provide critical industrial connected product system capabilities such as asset and data modeling, access control, and an Enterprise API.
For low power devices, Azure Sphere and the Azure IoT Client SDKs are used to communicate with the Azure IoT Hub. For more powerful devices and Gateways, Azure IoT Edge is used to manage containers on the edge. Bright Wolf GearBox provides a variety of additional edge capabilities including configurable protocol adapter runtimes, onboard historian, local HMI, and integration with various Azure IoT Edge components.
Industrial Protocol Clients
Configurable protocol adapter runtimes are able to collect, process, and transform machine data from your control systems and programmable logic controllers (PLCs). These include popular protocols like Modbus, OPC-UA, J1939, and other industrial PLC protocols. Toolkits are available for adding additional protocol support as needed.
A local, onboard historian keeps the history of the local sensor data and various other computed outputs that need to either be shared locally or sent to the cloud. This historian has a configurable database option and can make use of a variety of local datastores.
Web HMI Framework
GearBox also contains a local HMI framework and library, built in HTML5 and CSS for enabling the rapid creation of local user interfaces for the connected product. In cases where an HMI refresh is desired, this toolset enables rapid development of a new brandable user interface. These HMI components support touch interfaces as well as physical hard button input.
To enable edge developers to easily specify the payloads that they want to be sent to the cloud and the conditions and rules for transmitting those payloads, GearBox also contains a configurable Gateway Client that interfaces with Azure IoT Edge or the Azure IoT Client SDK.
Together with Azure services at the edge, these components enable development teams to produce solutions running in the field with the power to execute local logic, make decisions, and take action locally with or without connectivity to the cloud. Additionally, this flexible architecture provides gateway hardware independence for preventing hardware lock-in.
Azure IoT Solution Acceleration For Industrial Equipment Makers
Using this Azure IoT reference architecture at the edge and in the cloud, industrial equipment manufacturers are accelerating their digital transformation with Microsoft Azure IoT, avoiding commoditization, and gaining a competitive advantage in the market. To learn more or get started, let us know your requirements and goals and we’ll help you put together a plan for a rapid delivery of your connected product systems.
Published at DZone with permission of James Branigan . See the original article here.
Opinions expressed by DZone contributors are their own.