Reducing Barriers and Opening Doors for Building Automation Products in the Industrial Internet of Things

  • June 12, 2014
  • Feature

By Bob Dolin, Echelon

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. Multiprotocol, multimedia solutions will enable interconnection and intercommunication among currently disparate building automation networks. Such 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. 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 (IIoT). 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 platforms like Echelon’s multiprotocol IzoT come in.   Implications of a Common IP Infrastructure for the Building Automation Market 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.

Robert “Bob” Dolin is the system architect at Echelon Corp. He has worked for the company since 1989 and was named chief technology officer in 1995. Dolin is the principal or co-inventor of 14 Echelon patents, and is one of the designers of the LonWorks protocol, the network development system environment, the Neuron C programming model, and LonWorks network management.  He holds a BS degree in Electrical Engineering and Computer Science from the University of California at Berkeley.

Learn More

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..