Multiprotocol, Multimedia Solutions Will Reduce Barriers and Open Doors for Building Automation Products in the Industrial Internet of Things

Bob Dolin, CTO, Echelon Corp.

Overview

The emerging Industrial Internet of Things (IIoT) represents the next generation of control networks for building automation. But unlike the consumer Internet of Things, the IIoT isn’t starting from scratch. The hundreds of millions of building automation devices already operating on networks, using a plethora of protocols and both wired and wireless media, must be stitched together—easily and cost-effectively.

Echelon is focusing on multiprotocol, multimedia solutions that enable interconnection and intercommunication among currently disparate building automation networks. These IIoT-based solutions will not only break down silos between various building automation systems, but the use of a common IP infrastructure will also open new market opportunities for device makers and help increase revenues through streamlined inventory management.

The Need to Bring Devices and Device Networks Together

Building automation systems today face similar challenges as those faced by computer networking in the 1980s. Back then, competing computer-networking systems—from companies such as IBM, DEC, Data General, and Wang—had developed into a number of large islands. These separate networks benefited each individual supplier and its customers, but they made communicating across technologies difficult or impossible.

Looking inside a typical building today, you see air-conditioning systems that can’t communicate with lighting systems, and security systems talking yet another language on another network island. Besides the potential efficiencies that could be gained if disparate building automation networks could communicate with one another, there’s another huge reason to overcome protocol and media incompatibilities among these network islands: the Internet of Things and, more specifically, the Industrial Internet of Things.

Market researchers such as those at IHS predict that by 2020, the IoT will represent almost 40% of all Internet-connected devices; that there will be a billion industrial and commercial devices installed on the IoT by 2017; and that the IIoT will add 500 million new units per year. Those predictions provide tremendous economic incentives to enabling communications among building automation devices on various networks.

Consumer IoT Solutions Won’t Work in the IIoT

While the IIoT is an important part of the larger IoT story, it’s a big mistake to equate the consumer IoT—applications such as wearable fitness trackers or home thermostats—with the Industrial IoT.

Industrial automation today is very sophisticated, and IIoT requirements are far more stringent than those for the consumer IoT. IIoT devices often operate in lights-out mission-critical environments, where they need a certain toughness. For instance, IIoT devices require:

• Resilience in the face of failures, which includes:

• Packet recovery: New low-power links have very low bandwidth compared to Ethernet and, unlike Ethernet, the links are not as reliable. Packets can be lost due to interference, noise, or collisions—requiring more bandwidth to recover from the loss. IIoT protocol stacks must recover quickly from intermittent packet loss, or report a message failure to the application.
• Real-time requirements: Late packets mean communications failures in most control systems, so the network must be engineered to meet an application’s real-time requirements.
• Failure resistance: Distributed systems must avoid single points of failure, such as non-redundant routers or switches.
• Network-wide delivery: Protocols must support network-wide—i.e., spanning all the links within the system—confirmed multicast messaging.
• Detection of duplicate packets and acting upon them only once.

• Industrial-grade security—encryption, authentication, record/playback resistance, protection of keys and keying material, secure key management and key distribution, role-based authentication and user management.
• Physical connectivity requirements, because one implication of the need for reliability under any circumstances is that IIoT environments often are not conducive to wireless communications.
• Control services—support for a uniform set of network-wide (spanning multiple links) services including multicast, secure multicast, confirmed multicast, priority messaging, and application-level interoperability constructs.
• Autonomy, for self-configuration, self-securing, and operation without human intervention.
• Scalability to thousands of nodes spread among multiple links.
  

In addition, many IIoT situations do not require—and in fact are not possible with—interaction with an Internet server or cloud. Unlike the consumer IoT, the IIoT must include peer-to-peer, autonomous communities of devices. For response-time reasons, nodes cannot wait to be granted access to the network by a server, nor can they go through a lengthy session set-up sequence.

Traditionally, these communities of devices adopted protocols meant to work specifically for their prescribed operations. In building automation, the result has been the rise of protocols such as BACnet, LonTalk, DALI, C-Bus, Modbus, X10, etc.

The Role of IP

The flourishing of the Internet depended on bridging the disparate networks connecting PCs of the 1980s era. That bridge was IP: Internet Protocol.

For the IoT and IIoT, IP can also serve as the bridging protocol. More specifically, it will be IPv6, which will expand the addressing capabilities of IP to encompass the billions of devices expected to make up the IoT.

Currently, industrial systems connect to the Internet and internal IP networks through gateways. These gateways require custom provisioning and programming to expose the necessary data to the enterprise systems. Invariably, the gateway constrains what information can pass back and forth, and its configuration is difficult to evolve to support new requirements. For control networks in building automation, IP addressing will move from the gateway to the field bus level, and gateway functionality—e.g., the translation of data into a common format—will be integrated onto chips. At the same time, there will be greater reliance on routers than gateways for connecting networks.

Still, transitioning the billion or so legacy industrial devices will take more than IPv6. Because IP stops at the addressing and routing of packets, there will be a need for higher-level protocol services running on top of IPv4/IPv6 UDP socket interfaces that manage reliability, security, and device interoperability. That’s where the multiprotocol IzoT platform for the IIoT comes in.

The Multiprotocol IzoT™ Platform for the IIoT

The Echelon IzoT platform—available initially as software stacks and system-on-chip (SoC) offerings—is designed to provide a pathway to the IIoT for both the installed base of legacy industrial devices and new devices.

Some of the characteristics and capabilities of the IzoT platform important for building automation networks include:

• Industrial-grade reliability

• Rapid detection of packet failures, with support for end-to-end acknowledgements and responses for discovering and retransmitting lost packets
• No single point of failure
• Duplicate detection of packets
• Priority messaging, so that emergency or mission-critical messages can be propagated through the network ahead of non-emergency messages in router queues
• Multiple, simultaneous communications transactions, so that a device that is responsible for supervising a large number of devices isn’t stopped when a single device fails to respond

• End-to-end security
  

•  AES-GCM for symmetric key encryption and authentication with 128-bit keys
• Elliptic Curve cryptography for public key encryption and authentication
• Key agreement using ECHD
• Authentication using ECDSA
• FIPs 140-2 Level 1 Certification

• Backward compatibility so that legacy devices can be integrated into the common infrastructure
• Peer-to-peer operation to eliminate the need for a master controller and design out that single point of failure
• Node and application discovery to simplify commissioning and repair
• Application-level interoperability to allow devices from multiple suppliers to work together
• Interoperable self-installation to allow devices from different manufacturers to be integrated into a network without commissioning tools
• Scalability inherited through IP to allow very large networks spanning all building or campus-wide systems
  

The IzoT platform includes technology that simplifies the incorporation of both existing and new building automation devices and networks into the IIoT. For example, the decision to base the IzoT stack on UDP rather than TCP permits the use of multicast and confirmed multicast messaging so that a single message can simultaneously go to multiple destinations. As a result, more-constrained nodes can work on slower, more error-prone links—which allows systems designers to economically extend IP to the simplest of control nodes.

Above all, however, the IzoT platform is noteworthy for its ability to provide a full range of industrial-grade capabilities while also supporting multiple protocols, over a common IP infrastructure, within a single device or application.

Implications of a Common IP Infrastructure for the Building Automation Market

[an error occurred while processing this directive] The ability of both existing and new building automation devices, running whatever protocols have evolved within their particular domains, to interoperate with one another is key to extracting optimal benefit from the IIoT.

Interoperability among currently disparate building automation networks will not only increase their efficiency, manageability, and cooperation, it will also improve the overall quality and safety of building automation systems.

Multiprotocol support has huge implications for the business of building automation companies. Instead of designing, manufacturing, supporting, and tracking different unique products for each protocol option, companies can reduce their number of SKUs (stock keeping units) when a single device can be configured to support multiple protocols.

Companies can also expand their business. For instance, those that traditionally have made only LonWorks products can now also compete for BACnet bids, and vice versa.

At a higher level, then, multiprotocol, multimedia device and application support over a common IP infrastructure will allow building automation companies to address new markets and to reap greater revenues for the same design effort.

About the Author

Robert "Bob" Dolin, Echelon’s system architect, has worked for the company since 1989. He is the principal or co-inventor of 14 Echelon patents, and is a designer of the LonWorks protocol, the network development system environment, the Neuron C programming model, and LonWorks network management. Before joining Echelon, Dolin spent 11 years at ROLM Corporation, where he was a main developer of its PBX telephone system  Dolin has a B.S. degree in Electrical Engineering and Computer Science from the University of California at Berkeley.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]