Azure IoT Reference Guide For Industrial Equipment Manufacturers (Part 1)
Azure IoT Reference Guide For Industrial Equipment Manufacturers (Part 1)
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
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.
Azure IoT Reference for Industrial Connected Product Systems
Over the last decade, Bright Wolf has built production enterprise IoT systems deployed globally across a variety of industries. Our experiences (both successes and failures) have taught us that there are three key, foundational architectural areas especially critical to connected product system success. This includes asset and data modeling, access control, and an enterprise API. When designed correctly, these fundamental system components can enable the agility and control required to succeed in an evolving IoT space. When done incorrectly or deferred, the results can prove fatal to the project and inflict lasting damage on the organization responsible.
Things, Insights, and Actions
Microsoft describes IoT applications as "things" (or devices), sending data or events that are used to generate "insights," which are, then, used to generate "actions" that help improve a business or process. An example is an engine (a thing), sending pressure and temperature data used to evaluate whether the engine is performing as expected (an insight). This is used to proactively to prioritize the maintenance schedule for the engine (an action). This document provides a reference implementation for accelerating delivery of Azure IoT solutions that take action on business insights found through gathering data from industrial assets, enterprise systems, and 3rd party data to generate improved business outcomes and customer value.
Architecture Overview and Subsystems
The Microsoft Reference Architecture document explains how IoT applications consist of the following core subsystems: 1) devices (and/or on-premise edge gateways) that have the ability to securely register with the cloud, and connectivity options for sending and receiving data with the cloud, 2) a cloud gateway service, or hub, to securely accept that data and provide device management capabilities, 3) stream processors that consume that data, integrate with business processes, and place the data into storage, and 4) a user interface to visualize telemetry data and facilitate device management. Industrial IoT solutions also require 5) telemetry data transformation which allows restructuring, combination, or transformation of telemetry data sent from devices, 6) machine learning which allows predictive algorithms to be executed over historical telemetry data, enabling scenarios such as predictive maintenance, and 7) user management which allows splitting of functionality amongst different roles and users.
Bright Wolf solution implementations include the Azure services as outlined in the Reference Architecture, with the addition of our Strandz data management layer, GearBox edge suite, and SpringBoard application blocks for accelerating delivery of Azure IoT solutions designed for meeting the rigorous enterprise requirements and unique complexities of industrial connected product systems.
Connected Product-Specific Design Considerations
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.
Enterprise REST API
When creating a Connected Product, it is crucial to establish the digital interface to your product, just as you would establish an interface for your physical product. Your physical product will have mounting brackets and other interfaces that are managed over the life cycle of that product line. In the same way, the digital interface to the connected version of your product will have data formats, protocols, and other digital interfaces that require the same degree of care, attention, and lifecycle management.
Integrations with other business systems are required for delivering the outcomes promised by your Connected Product initiative, but these integrations should be created through a managed interface, not by allowing ad-hoc connections to the inner workings of your Connected Product System. Establishing a clean boundary between the Connected Product System and other business systems enables ongoing evolution and avoids significant rework as requirements change. An ounce of prevention is worth many pounds of cure in this case.
User management is an area where the wrong implementation can hobble the business and go-to-market strategies and result in cross-cutting rework of the system. It’s also critical to the security and trustworthiness of the system. The roles assigned to each user need to protect both the data in the system as well as the operations that can be performed.
In many IoT systems that are made available B2B, the end customer will desire to use their own Identity Provider (IdP) to manage the authentication of their own users. The authorization of those users will be left as a concern for the IoT system. When multi-tenant capabilities are required by enterprises seeking to service multiple customers from a unified system, this presents a challenge of how to integrate with multiple IdPs from each end customer. A common mistake made when attempting to implement authorization capabilities is to rely on the IAM service to provide the enforcement capabilities for your system. This approach may work when it is an internal system with relatively few users, but it becomes untenable to IT departments to allow your customers and other non-organizational members of your value delivery chain to have IAM users in your Azure subscription.
In an ideal scenario, user role descriptions are made in a declarative form that can be easily audited by your CISO and CIO to ensure that the roles don’t leak data or allow access to a portion of the system that they shouldn’t. It is also critical to understand the potential for extensibility. For example, consider what it would take to add new role types to the system later.
Data Layer Considerations
Additional key design factors for production Connected Product Systems include how the architecture handles Identity, Time, and Chain of Custody. While it’s possible to deliver a system that does not account for each in depth, data quality will progressively degrade and make extraction of business value all but impossible.
Authorization Enforcement Points
To simplify management and auditing, implementers should consider centralizing the policy decision points, so that enforcement isn’t spread throughout the code-base of the system. Using a declarative policy description language also simplifies auditing of the policies and ensuring that policy authors work with an already vetted suite of policy choices.
Device and Data Models
Delivering business outcomes requires taking data sources, metadata, and context, and allowing external systems to access, reason about, and compute over those inputs. How you model the data and where you model and describe the metadata determine the level of value your system can ultimately deliver. A well-architected system should be able to provide context and meaning for all consumers of data from the system, including unknown future users and external systems needed to drive evolving business models.
Bright Wolf’s experience is that keeping data and metadata external from the application code or business logic provides far greater flexibility as your business case evolves. Doing so enables you to integrate your system with other data stores and value extraction points, such as Power BI, that need access to the metadata, not just the raw data streams.
Data Records and Streams
The Azure IoT Reference Architecture provides a good overview of the design considerations for Data Records and Streams. There are a few additional items that are important to industrial equipment makers seeking digital transformation.
Many devices persist data locally and transmit that data at a later time to the cloud (perhaps when a device loses and returns to cellular connectivity). It is often desirable to transmit current state upon establishment of cellular communications so that any current alarms can be transmitted immediately. Following the current state transmission, a request would be sent to start sending the cached data. This pattern results in both re-transmission of previously received data, as well as the out-of-time-order arrival of telemetry data. In cases with cached data, it is critical to ensure the data ingestion pipeline can properly handle cached data ingestion without firing spurious notifications.
Depending on the device’s capabilities, there are several issues that can come up regarding timestamp resolution. In some cases, the device has a higher resolution timestamp than the cloud system is designed to support. In this case, it can be critical to keep the order of event information for events from the same device that map to the same timestamp resolution. In other cases, devices may not have a valid clock timestamp when the event occurs. In these cases, there are various techniques for attempting to derive the timestamp of the event based on a synchronization of the server time with the device clock.
Over the lifespan of the system, it will be the case that sensor data will be determined to be bad. As an example, this situation is often due to a broken sensor. This data needs to be marked as untrusted in the data record and stream so that consumers of the data understand not to rely on the reading.
Data Records Format
One additional best practice to consider is to send the firmware version along with the message version in the payload. We have encountered many bugs from device makers where they intended for the new firmware to support a protocol version, but they, in fact, introduced a bug that wasn’t caught before the firmware was fielded. By including the firmware version in the payload, rules can be configured in your data processing pipeline, for example, Azure Stream Analytics, to handle messages differently by the combination of firmware version and protocol version.
Check out Part 2 tomorrow where we continue to discuss the connected product-specific design considerations, including device interaction, Cloud Gateway, and more!
Published at DZone with permission of James Branigan . See the original article here.
Opinions expressed by DZone contributors are their own.