IP-all-the-way is the way to go

To take full advantage of building management systems, we need Internet protocol all the way down to the simplest devices.


Varun Nagaraj is senior vice president and general manager, Internet of Things, at Echelon Corp. He has more than 20 years of high-tech product planning and strategy experience. He holds a BSEE from IIT Bombay, a master’s in computer engineering from NortLately at industry events, or talking with customers, beneath the curiosity about the Internet of Things (IoT), I hear some resistance. In particular, there’s a brewing debate about how far Internet protocol (IP) should go in buildings’ networks. 

Today, IP can be found in gateways or supervisory controllers within a building network. But to realize IP’s simpler, lower-cost management benefits, we need IP-all-the-way to the fieldbus controllers and to the smallest, lowest-powered devices, including sensors and actuators.

I can hear the objections. IP is expensive, so how can we afford to IP-enable below the gateway/supervisory controller level? Aren’t IP networks complex to set up, erasing the ease-of-management argument? What about security? Doesn’t IP’s increased attack surface practically invite hackers to mess with your network? And why add another protocol to the legacy ones already in place and working just fine? 

These are understandable concerns, but I stand by my advocacy of IP-all-the-way—specifically, IPv6 (the IP version required to grant enough addresses for the billions of devices out there) all the way to the fieldbus and device input/output (I/O) level. Let me explain why.

It’s true that currently available silicon makes IP-enabling, low-cost devices cost-prohibitive. But next-generation system-on-chip (SOC) technology will provide the makers of controllers, sensors, actuators, and similar devices with everything they need to IP-enable small, low-power, low-cost devices. I’m not talking about vanilla IP technology. These new IP chips will include a secure IP stack, a range of connectivity options (wired and wireless), enough processing capability with low power consumption to run sufficient application code, and software services. 

Important to this scenario is the concept of communities of devices: a distinct segment within the broader IoT in which devices work cooperatively with each other to achieve a larger goal, such as the comfort of an entire building. A community of devices can be IP-enabled, but it doesn’t necessarily mandate Internet connectivity. It operates primarily as an autonomous and resilient peer-to-peer network. In fact, today’s building network is an example of a community of devices that includes sensors, actuators, and various controllers working harmoniously to optimize comfort, safety, and energy efficiency. 

Another objection to an all-IP building network is the upfront planning complexity. Yes, compared to a fieldbus based on twisted pair wiring or compared to simple digital or analog I/O, it’s more complicated to address a particular device with IP. On the other hand, a bit of early complexity is well worth the long-term gains in flexibility. An all-IP network is the simplest, fastest, and most cost-effective way to adapt and change over time. 

Then there’s the issue of security. Many building networks have grown accustomed to security through obscurity, depending on the chaotic mixture of simple wires and cables to thwart potential hackers. In this environment, the very cohesiveness of IP is viewed as a security threat. 

If we believe the Internet works—and clearly, it does—then we also must believe that methods exist to secure IP networks. The key is embedding security directly into IP chips, where Internet-proven security mechanisms are transparent to device developers as well as building network owners. We don’t have to resort to stone-age technologies to implement secure networks in modern all-IP buildings. 

As for integrating IP with legacy protocols, today’s accepted approach for interconnecting networks is through gateways that map functionality between different protocols. But what if we implement gateway functionality in the device itself, through the IP chip? A single device could present itself as an IP device, or a BACnet-over-IP device, or a LonWorks-over-IP device, at the push of a button. And it could integrate multiple media types as easily as multiple protocol types. 

IP-all-the-way in building networks remains an aspiration, I admit. IP-enabling the very lowest-cost devices might never make economic sense. But even aspirationally, IP-all-the-way is an important commitment. The benefits of IP in building networks are clear, but we won’t realize the full potential unless we go all-in. 

Talk to your clients about IP, and start pushing IP as far down into the network as you can. Your clients will thank you.

Varun Nagaraj is senior vice president and general manager, Internet of Things, at Echelon Corp. He has more than 20 years of high-tech product planning and strategy experience. He holds a BSEE from IIT Bombay, a master’s in computer engineering from North Carolina State University, and an MBA from Boston University

Anonymous , 08/01/13 10:06 AM:

I can see that it seems an easy win to place everything on the IP using UDP or TCP as the protocol, however the author seems to have overlooked a few major issues that would limit the capabilities of and All-IP system.

Statistical wait time
When each field device wants to transmit its feedback or command, it would very often come into conflict with other devices transmitting (wired or WiFi), thus the IP stack allows for a statistic based wait time before retransmit. This is typically from 1/64 to 1x the maximum transmit time of the packet. As you load up your IP network with all these devices, you will soon hit the limited for the max number of connections. Thus required more data switches or wifi access points (APs). The last thing you want is for the boss not to be able to get a wifi signal because the DALI lighting system is using them all. We could add more, but this is an expensive route and if using wifi, limits the bandwidth you can get out of each APs.

Wiring Topolgies
Twisted pairs (TP) are free topology, so you can spur, tree, star and any combination of the above. If using wired, you can only use a fixed star topology. Cat5 (the cheapest IP cable) even if cheaper than TP adds up when you are running miles of the stuff.

The IP/data network is fast, but that comes with issues of electrical interference. Wireless HART is the a good example of how to overcome this, but it is not an IP network! TP is slow by design and it is robust. You can zip tie (and pull) a KNX next to a 440v cable with no issue of interference.

Motorway versus feed road (freeway for those west of the pond)
If you stick all the fieldbus data on a fast IP network, you need to tie the switches and access points together using a faster connection (similar to the speed limit on a normal road that feeds the freeway/motorway). This means your back bone network must be über fast! That is expensive! Also pretty unnecessary if you are only transmitting tiny fieldbus data telegrams. Put the fieldbus on a control network at slower speeds (c1200kbaud) then your freeway backbone only needs to be "standard speeds".

Telegram Utilisation Efficiency
IP packets are huge. WiFi IP packets are event bigger! A switching telegram to a relay is 1bit, the largest control network telegram payload you will see is 14+2bytes. The overhead in an IP packet is massive due to the complexity of the system it works in, multi protocol, error checking, multiple mediums etc. By design, a control network will only talk over one medium (typically TP) thus reducing the header overhead. This gives a better payload-packet efficiency over TP than any IP. Thinking back to the freeway analogy, this means you are filling a fast and expensive data network with data packets that are mostly full of none relevant information.

The ideal answer is everything you use in the buildings to be on the same network, unfortunately, this is just simply in achievable. Standards have appeared to allow you to reduce the number of protocols in a complete system to a minimum, these standards are all pulled together using IP too. I always think IP as the net that all the other protocols fall into and where you hang your head end. Then I divide up my systems into 2 categories: master-slave and peer to peer. The master-slave approach is good for plant room and BACnet and the peer to peer is good for room/user level using protocols such as KNX or Lon. You then hang you system specific master-slave protocols off your peer to peer systems for thing such a DALI or SMI. The automotive industry have the same approach with an engine management system (master-slave) then a CAN peer to peer network with LIN master slave for specific sub system control such as door locks. The central screen is IP and the CAN and the EMS talk their native protocol in IP form directly to it. It works, and there are many technical reasons why the designers went down this route and created these protocols.
click me