Industrial IoT tech not ready for safety system prime time

“Today, there are a lot of tools to manage, and we need a template for each one. Getting them right is a complicated task.” Herman Storey discussed industrial network and device management needs at this week’s EcoStruxure Triconex User Group meeting in Galveston, Texas.

The limitations of industrial communication protocols are already being circumvented by Industrial IoT technology to add edge devices, condition monitoring and even process instrumentation to process manufacturing environments. Might the same approach bring benefits to safety systems?

“IIoT is a more user-friendly and functional infrastructure for control and safety systems that will do things we can’t do now because what we have is too slow,” said Herman Storey, principal, Herman Storey Consulting, in a presentation at the EcoStruxure Triconex User Group meeting this week in Galveston, Texas. “It also needs cybersecurity—authentication, authorization, time synchronization, key management and encryption. It has the high speed, but needs better options for routable, remote and mobile industrial applications. I can see its use for new applications, but do we need cloud-based applications? I’m not so sure.”

For industrial applications, industry needs to settle on one infrastructure. It shouldn’t be the Apple model, where each application is a data island and no information is shared, nor the Google model where all information is accessible to all applications—"an Internet of Everything,” Storey said. “We need an industrial model with a white list, lockdown, and security management and tools, where all access is managed by who can access data and what they can do with it.”

In what industry has now—the legacy model—each communication bus has its own app and network technology, where sharing and management are not supported. Current safety bus standards only protect data in the application layer. Configuration is not protected, networks are not protected or managed (no authentication or authorization), and field devices don’t have encryption/decryption chips. Devices and networks can’t be upgraded, and device support is more difficult than necessary. Device revision migration is not well supported, which is a management of change issue.

Update files for device support come over the internet and require system installation. Field networks are too slow to support user-friendly support features.

“So, what we need is a new infrastructure, not the IIoT,” Storey said. “It’s not yet available.”

One possibility is TSN/DetNet, a joint venture of IEEE, IETF, and AVnu. “This technology will improve time synchronization, priority, scheduling, and network management for any IP network,” Storey said. IEEE TSN is improving 802.1, 802.3, 802.11, 802.15.4 and 1588. IETF DetNet will support those improvements’ ability to manage data streams or sessions instead of packets. AVnu Alliance will provide compliance assurance and support for network management. “Time synchronization is now 1 msec in 1588,” Storey said.

Real-time applications will be able to offer significant performance improvements with this technology applied to data streams from end to end, with the ability to prioritize, schedule and synchronize both communications and applications. “Most communication protocols are adopting this new technology to work with their application layer,” Storey said. “Improved speed and management will allow for security and enhanced ease of use.

“Improved technology is available to developers and is prototyped, but you can’t buy it today.”

Support and certification organizations are developing interoperability specifications and conformance tests so existing application information can be retained and reused. The new technology will meet security and safety requirements, and improve user friendliness. “Eventually, new applications will become available, but new technology adoption will take a long time—I think decades,” Storey said.

Device management needs work, too

Meanwhile, today several standards related to intelligent device management (IDM) are in progress. ISA108 Part 1 has been published by ISA and submitted to IEC as a new work item proposal. IEC formed SC65E WG10 for this work, a document has been circulated in IEC and comments resolved. IEC 63082-1 has been recirculated in IEC, and is out for comment now. “ISA108 Part 2 development is in progress and will be submitted to IEC when it’s ready,” Storey said.

IDM standards are needed to specify tools, devices and systems to manage data. “Today, there are a lot of tools to manage, and we need a template for each one. Getting them right is a complicated task,” Storey said. We have separate configuration tools for device and host integration. Visitor hosts (handhelds) are hard to use, which often results in incomplete configurations and configuration mismanagement (or configuration drift). “To make configurations and diagnostics work right, we need tools for both the device and the system, and for startups when we have multiple users, we need simultaneous multiple access with secure, shared data,” Storey added. “Download and migration tools need a lot of support from the vendors.”

Further, “A lot of people claim backward compatibility when it doesn’t work,” Storey said. “Work processes are not standardized, and common tools don’t support good work processes. Some tools require interactive single-parameter entry for configuration—devices don’t come with workable sets of default parameters (templates). “Current protocols also leave a lot to be desired for implementing diagnostics, finding undiagnosed faults and dealing with alerts,” Story said.

In conclusion, “They’re good products but there are things that can help us. And we’ll need work processes to go with the tools,” Storey said. “Our current safety committee standards allow this mess. Do we want to fix it? Users will benefit but vendors may not see the ROI—barriers are money. Progress will depend on standards upgrades, and I encourage you to get involved.”