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).