Evolution of open protocols

Beginning in the 1980's, more and more manufacturers of HVAC-related equipment began incorporating microprocessor-based controllers in their products at the factory. In the beginning, these controllers were designed to be stand-alone. With the increase in popularity of networked building automation and energy management systems, communications ports were added to these stand-alone controllers and various communications protocols, or languages, evolved.

[an error occurred while processing this directive]

The earliest of these protocols were often proprietary to the equipment manufacturer. Later, as specifications began to require that mechanical and electrical equipment provide serial interfaces, several of the most common protocols became de facto standards. Modicon's MODBUS and OPTO-22's OPTOMUX are two examples. Other companies recognized the need for a common protocol as a business opportunity and developed their own protocols and supporting products to supply to the industry (Echelon's LonWorks, emWare's DeviceGate, Bosch's CAN, Cimetrics' 9-bit Solution, etc.).

Eventually, several industry standards bodies formed committees to define protocols that would be available to be deployed without licenses or royalties (ASHRAE-BACnet, OPC Foundation-OPC, Profibus International-Profibus, etc.).

Initially these standard protocols utilized flat data structures of independent and possibly unrelated values (MODBUS registers, LonTalk Network Variables, OPC Items, etc.) In a flat data structure, each piece of information stands alone. For example, 76.6 might represent a temperature, but the units and name of that data sample would each be stored separately in the program. As object-oriented programming paradigms gained widespread acceptance as an alternative to flat data structures, a more object-oriented approach toward field data was desired. In an object-oriented data structure, 76.6 would be packaged with the units (°F) and the name (Zone Temperature). Having these related pieces of information stored together as an object assists in data interpretation. In addition, multiple objects can then be grouped together into another object in a hierarchical fashion. For example, the Zone Temperature and Zone Setpoint objects might be grouped into a Zone Control object. This movement toward object-oriented programming gave birth to the current generation of object-oriented protocols - BACnet, LonMark Functional Profiles, and European Installation Bus Object Interface Specification (EIB - ObIS), among others.

Figure 1: BAS Protocol Evolution

Current Problems

[an error occurred while processing this directive]To understand where we're headed, it is helpful to realize just how far our industry has advanced. In the 1980's, there wasn't a protocol that could meet the majority of a Building Automation system's needs. As we press forward into the 21st century, our problem is not one of "not enough" but one of "too much." We now have not one, but several standard protocols that can meet the needs of an average building automation system. The various building automation system manufacturers build products that support one or more of the standard protocols that are available, however, integrating more than one protocol into a single system can be a challenge.

Although the data structures for the standard protocols are similar, their implementations are quite different. Gateways between any two of the standard protocols tend to be complex, and bridging more than two can become unwieldy.

A second problem area stems from the fact that building automation systems are increasingly seen as a part of a much larger information system. Facilities Managers now routinely have specialized software for managing their tenant spaces, their assets, their equipment maintenance, and even for their energy procurement. The requirements for "information integration" are now much broader than when the standard protocols and their corresponding data models were conceived.

If BACnet, EIB objects, and LonMark functional profiles are methods of modeling information, what is needed is a unified information model to include these BAS protocols as well as other facility-related applications.

A Parallel Evolution

Above, we described an evolution of communications methods from proprietary, flat protocols to open, object-oriented information models. Simultaneous with this development, a parallel evolution has been taking place in the Information Technology realm. The 1970's were the years of the mainframe/dumb terminal architecture. The 1980's saw the birth of the PC. The 1990's brought networked PC's with client-server architecture. In the late 90's and early 00's, (due largely to the explosive popularity of the internet) we're seeing a return to the 70's style approach relabeled the "thin-client architecture." Dumb terminals have been replaced with web browsers. Mainframe computers have been replaced with web server farms.

Figure 2: Evolution of Information Technology

In their white paper Web Services - The Web's next revolution, IBM points out several trends that are becoming apparent:

Content is becoming dynamic - The first web pages were static. Today, sites provide up-to-the-minute content, incorporating news headlines, weather forecasts, and current chilled water supply temperatures on the same page.

Bandwidth is getting cheaper - Some analysts predict that in a few years, there will be enough bandwidth for a full-motion video channel that chronicles the life of every person on earth. Whether that happens or not, bandwidth is growing exponentially cheaper year after year.

Storage is getting cheaper - The capacities of hard drives, DVDs, CD-ROMs, and removable storage media are far greater than they were a few years ago. This trend is likely to continue.

Enterprise computing is becoming more important - The need to integrate information from our familiar desktop PCs with mobile phones, pagers, and palmtop computers on the low-end and with mini and mainframe-based corporate information systems on the high-end is increasing.

Enter Web Services

[an error occurred while processing this directive]The IT industry has responded to these trends by creating something called Web services. Web services are a new breed of Web application. They are self-contained, modular applications that can be run over the Internet and can be integrated into other applications. Web services perform functions that can be anything from simple requests to complicated business processes. For example, a weather bureau could offer a Web service that allows a building automation system to automatically retrieve temperature forecast data for use by various control algorithms. Similarly, the building automation system itself could offer a Web service that allows a tenant's accounting system to obtain up-to-the-minute figures on energy consumption. In the past, this type of data exchange would require a custom, "hard coded" data request to retrieve information that already existed in the host computer. A Web service, on the other hand, is a way to allow any authorized client to actually run an application on the host computer and generate data that didn't previously exist. In our accounting example, the tenant's computer would provide information on the inclusive dates and building areas, and the Web service host computer would calculate and return the energy consumption data. 

These are very simple examples. In reality, Web services can be very complex, and a single application program may call upon multiple Web services. What is the future of Web services in Building Automation? Let's look at the four trends in terms of Web services: 

Content is becoming dynamic - A Web service has to be able to combine content from many different sources. That may include furniture inventories, maintenance schedules and work orders, energy consumption and forecasts, as well as traditional building automation information. 

Bandwidth is getting cheaper - A Web service can now deliver types of content (streaming video or audio, for example) unthinkable a few years ago. As bandwidth continues to grow, Web services must adapt to new content types. 

Storage is getting cheaper - A Web service must be able to deal with massive amounts of data intelligently. That means using technologies such as database replication, LDAP directories, caches, and load balancing software to make sure that scalability isn't an issue. 

Enterprise computing is becoming more important - A Web service can't require that users run a traditional browser on some version of Windows. Web services have to serve all sorts of devices, platforms, and browser types, delivering content over a wide variety of connection types for a wide variety of purposes. 

The Hypertext Markup Language (HTML) format was designed for web pages to be read by humans. Like a universal word processor format, HTML combines text, pictures, and formatting information so a browser can display it on a screen. HTML is not adequate for information exchange between computers, however, because it provides no information about the data that may be contained on the screen and no way to search for specific pieces of data. For Web services to address all of these needs, two other, more flexible technologies are crucial: 

XML (eXtensible Markup Language) - XML is a technology for moving structured data across the web or a corporate network. Like the object oriented protocols described previously, XML documents include more than just raw data. An XML document includes a definition of the data structure, so the receiving computer knows what information is contained in which fields. 

SOAP (Simple Object Access Protocol) - XML is basically a file format. SOAP is a way of using XML over a network. SOAP provides a computer application with a tool that can read the data definitions in an XML document and extract the required data. SOAP is to XML what HTTP is to HTML. 

All of the major Enterprise Software vendors are fielding products and platforms that support the Web services architecture using XML and SOAP, including Microsoft.NET, IBM WebSphere, Sun Microsystems SunOne, Hewlett Packard Web services platform, Oracle 9i, BEA Systems WebLogic, among others. 

The Marriage of the Web Services Architecture with Building Automation Information Models

Since BACnet and EIB objects and LonMark functional profiles are information models, and XML is a modeling language, we could express these high level information models in XML and in so doing make them compatible with the emerging Web services architecture. Because of the flexibility of XML and the web services architecture, these high level models could be expanded to include other types of facility-related (but not necessarily building automation-related) information. If each building automation protocol developed its own XML model, however, we would have similar but incompatible system models. Today's problems of translating from one protocol to another at the building controller level would become tomorrow's translation problems at the Web services level. What's needed is a unified system model, in XML, that can be used by any building automation protocol. 

It should also be mentioned that this push toward Web services architecture should not be interpreted as an end to standard protocols. Web Services are useful as a computer-to-computer or software-application-to-software-application interface, but they are "overkill" as a device-to-device interface. While it might be possible to expose information as XML at a building-controller level, it would not be practical to do so at a zone or unitary-controller level. Web services should be viewed more as a successor to OPC than a replacement for BACnet, EIB, or LON.

Figure 3. Web Services Architecture 

Conclusion 

XML, TCP/IP, or even Web services alone cannot provide interoperability between vendors. In order for interoperability to occur, vendors must not only agree on HOW they will communicate, but also on WHAT they will communicate. Because they include a high-level abstraction of what information is to be communicated, BACnet, EIB, and LonMark all provide the WHAT component of interoperability. By combining these information models with XML, and expanding the objective to include other non-HVAC related aspects of the facility, Web services can provide an information platform that is high-level, cross-platform, cross-discipline, and multi-vendor. A new initiative is needed to define a comprehensive information model for the facility. This initiative would ideally include the following:

• A company, customer, or special interest group to champion the cause (similar to the way LON was championed by Echelon and BACnet was championed by Cornell University and NIST)

• Endorsements by one or more appropriate professional organizations (ASHRAE, BOMA, APPA, etc.)

• Participation by at least one - preferably several - vendors from each category of service (Building Automation, Space Management, Maintenance Management, Energy Procurement, etc.)

• Leverage Internet technologies and standards, while avoiding technologies that lock implementers into a specific operating system or programming language.

• Participation by customers and customer advocates (Building Owners, Consulting Engineers, Universities, etc.)

The last item may be the most important of all. Historically, vendor-driven standards initiatives in our industry have been either slow to be adopted or never adopted at all. However, customer-driven standards initiatives have been adopted much more quickly and have remained in use longer. In order for any widespread adoption of Web services architecture in integrating facilities information to take place, there will need to be a groundswell of demand from the customer and customer-advocate communities.

More Articles

[an error occurred while processing this directive]
[Click Banner To Learn More]

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