March 2014
Article
AutomatedBuildings.com

Daikin Integration to BACnet, Modbus, KNX, WIFI, Mobile Apps
Intesis

(Click Message to Learn More)


Multiprotocol, Multimedia Solutions

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

Bob Dolin

Bob Dolin,
CTO,
Echelon Corp.

Articles
Interviews
Releases
New Products
Reviews
Distech Controls
Editorial
Events
Sponsors
Site Search
Newsletters
Reliable Controls
Archives
Past Issues
Home
Editors
eDucation
Control Solutions, Inc
Training
Links
Software
Subscribe
Blue Ridge Technologies

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:

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:

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.
Market Chart

Implications of a Common IP Infrastructure for the Building Automation Market

Control Solutions, Inc 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.

footer

Haystack Connect 2015
[Click Banner To Learn More]

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

Events

Want Ads

Our Sponsors

Resources