Tackling the challenges of industrial IoT

4The Internet of Things (IoT) promises to transform the way that we deploy industrial applications by combining the best practices from the IT space with cloud-based analytics and machine learning.

New industrial IoT (IIoT) deployments will benefit from improved operational efficiencies due to the quantity and quality of the information available to optimize processes. Wider use of IT technologies such as common protocols and RESTful interfaces will also enable tighter integration between the various systems (e.g., factory floor, purchasing, and sales) and allow operators to tap into the large and growing pool of IT talent. New and emerging standards will control how all these technologies work together in harmony. With all these promising developments for IIoT, one critical area has remained relatively impervious to standardization: the sensor domain. Challenges such as security, synchronization, scaling, and lack of interoperability have in the past impeded progress. Now, however, with coordination between PICMG, the DMTF [Distributed Management Task Force], and other organizations, this situation is changing.

Plug-and-play architectures of the 1990s transformed our expectations of how new devices could be added to our computing systems. Prior to plug-and-play, adding a new peripheral device to a computer required manual configuration of the hardware and software. Now users expect that when a new device is plugged in, the computer will “automatically” detect the new hardware, configure it, and make it immediately available. This isn’t automatic, of course, but rather a well-defined process in which the software queries the hardware and the hardware reports its capabilities. However, adding new sensors and actuators in an industrial deployment still falls largely into the manual configuration category.

PICMG seeks to tackle the IIoT challenges and accelerate its deployment by providing two new open specifications. The first is an architecture and data model that leverages existing IT technologies and enables plug-and-play at the sensor domain, while the second is a postage stamp-sized form factor that allows existing sensors to be easily converted into “smart sensors” that play seamlessly within the larger IIoT-enabled facility. Read on to learn about some of the issues we expect to encounter, as well as some possible solutions. With the combined talent of our member companies, along with collaboration with other industry organizations, PICMG hopes to conquer the challenges and make these plans a reality in 2019.

Challenge #1: Security

The first challenge that we expect to encounter is that of network and data security. While security is important regardless of the application, it becomes even more critical when breaches of the network can potentially take over factory operations, stall transportation systems, or affect the stability of the power grid. Fortunately, there are some common-sense precautions and best practices that can already be applied.

First and foremost, security can be strengthened by applying the adage: If it doesn’t need to be connected, don’t connect it. Most of us realize that an internet-enabled thermostat or security camera in our home creates a potential target for hackers. After weighing the risks, we make an informed decision about whether or not the risks are offset by the convenience that Internet connectivity brings. For industrial applications, the calculus is different. Almost no amount of convenience could offset the potential risks associated with takeover of a “Smart Factory Control” application, for instance.

Industrial IoT deployments must firewall their mission-critical systems away from the outside world, allowing only monitoring (not control) through carefully secured access points. This “walled fortress” approach (Figure 1) is not unlike what telecommunications companies have successfully used for network management for years. Although the data network is open to all their customers for use, the management and control network is tightly secured. IIoT sensor specifications must provide appropriate security features for sensors living within the walled fortress environment of their facility.

Figure 1: Example implementation of the “walled fortress” security architecture for IIoT.

At this point, you might be asking, “Is this even the Internet of Things, if the things are not connected to the internet?” This is a valid question and is probably technically true. Remember, though, that the business values associated with IIoT are largely centered around leveraging internet technology and the internet talent pool, not necessarily connecting an industrial application to the broader internet.

Challenge #2: Synchronization

The next challenge that we expect to face in standardizing sensor domain IIoT is that of synchronization. In other types of IoT, sensors work relatively autonomously from each other and the acceptable system response time to sensor events is often in the range of several seconds to many minutes. Neither is the case in industrial applications. Take, for example, a robotic arm that is responsible for welding: The motion of each joint must be carefully coordinated with the other joints in order to quickly and accurately accomplish its task. In practice, this means that the multiple motors must respond to the same stimulus (e.g., “start moving” command) within a very short and deterministic timeframe.

Three potential solutions exist for accomplishing this synchronization: sideband signals, network multicasting, and network time synchronization. The first and simplest option connects all the devices that must be coordinated to another signal for the purpose of synchronization. This technique works well for situations where the devices are located in physical proximity to each other. The second, using UDP [user datagram protocol] multicast capabilities can eliminate some of the networking delays associated with multiple TCP/IP commands (one to each device) as it melds them into one command that is sent simultaneously to all the devices at once. The last option requires each sensor endpoint to maintain an accurate clock source, which they synchronize to a reference clock found on the network. When commands are sent to the sensor nodes, they can be coded to begin or end with respect to a specific network time. These possible solutions are shown in Figure 2. It is expected that IIoT specifications will support a variety of these options.

Figure 2: Possible synchronization methods for IIoT.

Challenge #3: Memory footprint

The third challenge associated with applying internet technologies to the sensor domain is the limited memory capacity of the microcontrollers that are otherwise ideal for this application. This problem stems from the fact that most higher-level internet management protocols are human-readable (think XML and JSON). While this is desirable for the people who develop and manage the IT infrastructure, the text-based approach is an extremely inefficient method for storing and conveying information. For instance, the 300+ words of this article’s first two paragraphs would push the limits of data storage for most 8-bit microcontrollers.

While the first reaction to solve this problem might be to use a microcontroller that has more memory, this may adversely change the solution cost and make smart sensors cost-prohibitive. Augmenting the memory of an existing microcontroller using external devices such as flash memory may solve the problem but has similar drawbacks on cost.

An alternate solution (Figure 3) is to allow the sensor domain to transmit the data in a binary coded fashion. In this solution, data is stored and transmitted as a coded sequence of binary information, rather than human-readable text. This dramatically reduces the amount of memory required to store the sensor information and puts it well within reach of most 8-bit microcontrollers. The binary data is converted to human-readable text for use by the rest of the network. The translation occurs within an IoT gateway device and only works well if the data structures that are communicated at the sensor level closely match the human-readable version created by the gateway. Standardization in both of these domains is key.

Figure 3: Conversion of human-readable data representation to binary-coded representation.

Challenge #4: Data model

The final challenge to consider is that of the data model itself. This challenge is the most abstract and is probably new to those who are not familiar with IT management. Rather than dig into all the technical details, let’s use a more familiar example: Computer plug-and-play.

When we plug a new piece of hardware into our computer, the computer software interrogates the new hardware to determine what it is and what its resource needs are. The hardware, in turn, responds with information that describes itself in a manner that the computer hardware understands. The information describing the hardware can be thought of as a “data model” – a description of the hardware, its needs, and capabilities.

In IT implementations, the data model also forms the interface by which the device behavior can be altered. By writing a modified data model (or portion thereof) back to the device, the device behavior is updated with the changes. For instance, a thermostat data model might contain a field that specifies the temperature setpoint at which the air-conditioning unit should turn on. Updating this field in the device’s data would signal the thermostat to change the setpoint to the new value.

The real challenge with defining data models is providing flexibility to support today’s and anticipated future devices without adding undue complexity. Since interoperability between vendors is essential, this activity can only happen within the context of a standards organization

Ongoing work

PICMG is moving forward with an aggressive schedule to advance IIoT. The PICMG approach encourages a firewalled, secure network architecture that supports a variety of synchronization methods and a uniform data model that scales down to the sensor domain through binary encoding. Using well-established practices, the specifications will provide plug-and-play interoperability at the sensor domain to the “last foot” of the IIoT network. In March 2018, we formed an alliance with the DMTF in order to extend the Redfish management API to industrial applications. In June 2018 we demonstrated a proof-of-concept CNC machine using 8-bit microcontrollers and restful APIs at Sensor Expo, and we are currently poised to begin specification work on both the postage-stamp form factor and the IIoT data model efforts.

If you are interested in more information about PICMG, its IIoT activities, or how you can join in this work, please contact us (address to right). PICMG is committed to accelerating the deployment of IIoT. We hope that you will consider joining the team.

Doug Sandy is the Vice President of Technology for PICMG, with over 24 years of industry experience in the embedded computing, industrial automation, telecommunications, and cloud computing spaces. Doug has worked as Technical Fellow, Chief Technology Officer, and Chief Architect for major corporations including Motorola, Emerson, and Artesyn Embedded Technologies. He now enjoys training the next generation of engineers at Arizona State University’s Polytechnic Campus where he is a full-time educator and program coordinator for software-engineering capstone projects. Readers may reach Doug at [email protected]

PICMG[PCI Industrial Computer Manufacturers Group] www.picmg.org