By Mike Donlon
Throughout the building automation "protocol wars" of the last decade, a revolution was taking place in the networking and computing industries. The Internet and its associated protocols became the dominant driving force for technology in the 1990s.
Computers of all different types, with different operating systems from different manufacturers, came together in cyberspace under a unified set of protocols. That is the crowning achievement of the Internet. This type of technical cooperation is unprecedented in history.
Many building automation systems (BAS) do incorporate Internet protocols into different parts of the system. However, BACnet®, LonWorks®, and proprietary protocols still dominate the core infrastructure of the BAS networks. Internet protocols are usually tagged onto the product line as an option, and only in places where it is convenient for the manufacturer.
One reason that BAS equipment manufacturers have not adopted Internet protocols as the core networking standard is cost. Internet protocols, in general, are more sophisticated and require more computing power than is typically available on smaller, inexpensive BAS control products. Historically, networking protocols were the domain of mainframes and business computers, while embedded electronics used serial communications. But in the past year or two, the price of 32-bit controllers, networking chips, and software has allowed true TCP/IP networking to become a realistic and cost-effective solution at the controller level. It is now possible to have 32-bit Internet-capable processors inside of every single BAS controller in a building.
Another reason for the lack of Internet protocol support is that the well-established Internet protocols do not directly address all the needs of a building automation system. They provide great interconnectivity, addressing, and graphical display. They do not specifically dictate how to exchange BAS data (like temperatures or alarms) between BAS components. However, emerging standards address the general need for meaningful component-based interoperability.
TCP stands for the Transmission Control Protocol and IP stands for the Internet Protocol. TCP and IP are actually separate protocols that, when used in conjunction (TCP/IP), provide reliable point-to-point connections. TCP/IP handles all of the error detection, transmissions, addressing, and routing needed to seamlessly carry messages from network to network. But the Internet itself is not a necessary part of the TCP/IP protocol. Local area networks (LANs) can also employ the TCP/IP protocol for short local connections. In this example, TCP/IP is still used even though connections don't leave the local network. Two neighboring devices can "speak" TCP/IP on a single LAN. Global connectivity is just a bonus. In true multi-layered fashion, TCP/IP itself does not specify the format of the connection. This is left up to the application - as it should be. Building automation systems can use TCP/IP today as the underlying connection protocol for building automation. This TCP/IP infrastructure is an absolute must for buildings that want to lay the groundwork for the interoperable devices of the future.
HTTP protocol defines a way that graphical data is transmitted over TCP/IP for display to people using a web browser. It is a complete, well-defined, and widely accepted protocol. All building automation systems can and should offer this type of universally accepted protocol in their systems. It would be remiss in this day and age not to offer some sort of web connectivity to a building automation system.
Mike Donlon is director of Research and Development at New Orleans-based
Computrols Inc. (www.computrols.com).
