Proceedings of the 2007 American Control Conference, New York City, July 11-13. Copyright AACC 2007. Leveraging the Web: A Universal Framework for Building Automation Tariq Samad and Brian Frank Abstract Building automation systems today employ an array of communication protocols, data formats, and software platforms. Some of these are proprietary, others are standards-based, but in neither case can true integration and interoperability be achieved. We describe a new framework for building automation that is based on multiprotocol network devices and a common object model and that leverages the Web to enable heterogeneous building automation systems to be rapidly and efficiently implemented and managed. Applications of this framework to energy management, equipment monitoring, and demand-response strategies are outlined. I. INTRODUCTION Building automation architectures are often structurally complex and hierarchical because of the variety of different protocols and communication media used for different functions and for different manufacturers equipment. Integration of heterogeneous equipment requires extensive use of multiple toolsets and gateways and extensive custom programming, limiting the economic viability of such integration. Building management systems thus tend to be either single-vendor-based or a combination of products from different vendors that is not well integrated. Whereas legacy systems were generally based on proprietary integration mechanisms, more recent systems follow emerging standards. However, this has only exacerbated the problem because of the fact that the standards themselves have not been designed to interoperate. In reality, the recent push toward standard protocols has created more languages that need to be integrated instead of fewer. The number of legacy devices also implies that wholesale replacement of all the automation components in a building is untenable. We need a solution that can accommodate the multitudes of both new standards and legacy systems an automation framework that brings together all embedded devices, old, new, standard, or otherwise, into a single environment that T. Samad is with Honeywell Laboratories, 3660 Technology Drive, Minneapolis, MN 55418, U.S.A. (tariq.samad@honeywell.com). B. Frank is with Tridium, Inc., 3951 Westerre Parkway, Richmond, VA 23233. acts to shield the user (and software developer) from the distinctions between different systems. In this paper we describe a recently developed approach to building automation that overcomes the hurdles of multiple, incompatible protocols prevalent in the industry; that allows devices from different manufacturers to be integrated together seamlessly within one automation system; that simplifies the configuration, monitoring, and maintenance of heterogeneous systems with a unified toolset accessible from a browser by an authorized user; and that enables high-value applications such as energy management and remote monitoring of equipment. This approach has been developed (and is now deployed in a large number of commercial applications) by Tridium, an independent business entity of Honeywell International Inc. We first describe the two main elements of the approach: a class of Java-based network devices and a software infrastructure and object model, Niagara AX. Next, we sketch how novel, distributed building automation architectures can be composed using the new approach. Before concluding, we review some applications that have been developed based on this new automation framework. Portions of this paper are taken from white papers and other material on the Tridium Website [1]. II. INTELLIGENT MULTIPROTOCOL DEVICES Networked devices are, of course, already widely available for building management. However, today s devices are vendor- and/or protocol-specific; they have been designed to operate in specific types of communication networks, such as BACnet, LONworks, MODbus, and Cbus. In order for vendor- and protocol-agnostic building automation systems to be developed, intelligent network devices are needed that can accommodate different communication protocols. The new automation framework described in this paper includes a family of such devices, called JACEs (for Java Application Control Engine, Figure 1) [2]. As shown, JACEs use x86 or Power PC processors running a variety of real-time operating systems. Fieldbus drivers can be provided for any of the broadly used standard or proprietary networks. Communications at the enterprise level can rely on a variety of protocols as well,
including HTTP, OPC, and SOAP. For communication among Niagara components, a new protocol, Fox, has been developed. One JACE device can connect to multiple, diverse control networks (physical ports are provided for different connectors). JACE devices also host Web servers. This feature allows devices to be monitored and configured directly from a browser where security privileges permit. A JACE component can serve up Web pages including graphics, parameter values, and configuration screens. Configuration information is not only for the JACE device lower-level equipment (e.g., regulatory controllers, sensor transmitters) connected to the JACE device can also be configured remotely. III. A COMPONENT OBJECT MODEL FOR BUILDING AUTOMATION JACE devices provide the hardware and protocol interconnectivity required for a universal building automation system. But interoperability is also required at a semantic level for example, a temperature measurement communicated by one sensor must be recognized as such by a temperature controller even if the two components speak different protocols and are from different vendors. This semantic interoperability is also essential to allow the same tools to be used for monitoring and configuration regardless of how this information is encoded or communicated. The Niagara framework includes a common object model that provides this capability. The object model is a hierarchical composition of concepts in building automation, from the elementary level of simple data types to abstract concepts such as communication sessions and control schedules. Figure 2 shows a part of the Niagara AX class diagram representing the object model. The common object model can be thought of as a uniform, normalized database of objects for the user or application developer to work with. The database becomes the platform through which other applications interact with the various systems. On top of this object database the infrastructure provides a set of general services such as a real-time control engine, scheduling, alarming, and Internet connectivity (see Figure 3). The common object model, which has access to all of the data and actions supported by the diverse systems, can now serve as a foundation for other software applications that provide value to the operation of the facility. Software elements can be developed once and re-used in multiple applications. The component-based design of the framework eliminates the need to create dedicated applications, with separate development effort, for each system. An extensive library of components that addresses the majority of application needs is also available. The common objects also make it easy to build browserbased displays, reports, alarms, and even supervisory control logic that works across the multiple systems. The result is true interoperability without the need for users to get mired in the details of competing protocols and without the need to disturb the installed systems. This approach also allows system expansion through the addition of existing device types while at the same time enabling expansion with devices based on new and emerging protocols. It provides the owner with the ability to choose best of breed smart devices and systems. The object model is, in a sense, a metaprotocol. It is itself evolving into a standard, obix, that is part of an industry-wide initiative to define XML and Web services mechanisms for communications between building control systems and enterprise software applications [3][4]. IV. NIAGARA-ENABLED SYSTEM ARCHITECTURES Examples of this new building automation architecture, illustrating the use of JACE devices as intelligent gateways for integrating multiple networks and types of devices, are shown in Figure 4. As illustrated, the architecture is scalable and can be used for applications ranging from single buildings to multiple, geographically dispersed facilities. This new approach to building automation provides several benefits to building owners and operators: customized systems with components and subsystems from different vendors can be readily implemented; the configuration and commissioning time and cost associated with building management systems can be substantially reduced; systems can be monitored and controlled remotely; and information from multiple facilities can be centrally accessed for comparisons and identification of best practices. V. APPLICATIONS The combination of JACE devices and the Niagara AX framework provides the elements needed for developing high-value applications for building automation. Such applications can be developed by customers and third parties and several have also been developed by Tridium. We briefly describe some of these available applications, packaged in the Vykon Energy product, below. Case studies of theses and other applications are available on the Web [5]. Remote Monitoring and Control. Being notified that events occur in real time is beneficial, but without the ability to make changes and avoid ramifications, the notification means little. With Vykon Energy users can log onto a standard web-browser to alter schedules, change setpoints, and adjust mechanical system control parameters (Figure 5 [left]). Because Vykon Energy is based on the
Niagara Framework, the type of system users are communicating with is transparent. Whether a chiller, an air handler, or a lighting panel, the user interface is the browser and can be accessed from anywhere at anytime. Profiling with Normalized Data. Vykon Energy provides a robust and flexible profiling application through which users can trend and analyze values such as energy, temperatures, production, and facility data. With such information, users can determine how buildings, mechanical systems, and other variables affect one another. The Web-based user interface is a user-friendly application that turns logged data into useful and actionable information. Users can compare meters to one another to determine the most and least efficient strategies and buildings. Figure 5 (right) profiles main electric and gas meters and normalizes data for outside air temperature (OAT) and floor area. The user can determine the correlation between OAT and HVAC with results presented in the scatter plot. By comparing energy consumption between buildings an energy services company can determine the most efficient strategies. Correlations make it possible to determine the effect one variable has on another. Comparing Pre-retrofit with Post-retrofit Results. Users can compare a meter versus a historical baseline or imported data. A user can choose to compare lighting from several facilities versus historical results. Because days of the week do not align between months weekends can be eliminated from the evaluation. By comparing a lighting meter prior to and following a retrofit and eliminating weekends, savings from lighting or other energy efficiency measures can be quantified. Enabling Demand-Response Strategies. In addition to including external environmental data such as weather and pricing, Vykon Energy integrates temperature controls, lighting panels, metering technologies, and other systems that are consuming energy in an end-user facility. Common protocols such as Modbus, LonWorks, BACnet, and DNP 3.0, can all be integrated into the demand response (DR) program. By adding connectivity to proprietary systems, demand response opportunities are significantly expanded. Once the pricing signal/curtailment request and the field devices have been linked, if/then logic can be defined to automate the DR program. Programming is done through a graphical interface. Multiple kw readings can be aggregated and linked to a pricing signal. For example, the DR program could specify that when the aggregate power demand is between 5000 and 8000 kw any time between 11:00 a.m. and 4:00 p.m., and the pricing per kwh exceeds $.50, then lighting should be reduced in zone 1, the temperature setpoint in zone 8 should be offset by 3 degrees, and an available microturbine should be turned on. VI. CONCLUDING COMMENTS Niagara AX has been adopted in multiple markets to create solutions for real time monitoring, control and machine-to-machine applications. Today over 50,000 instances of Niagara are operating in over 6,000 installations worldwide supporting applications like energy management, building systems automation, maintenance repair operations (MRO), service bureaus, total facilities management, and cradle-to-grave product support services. Future work is focusing on several fronts. We note two here. First, the framework described can be used to enhance the enterprise-level integration of building automation devices. A proposed architecture, which exploits features of the IEC 1499 standard and IBM s WebSphere technology, is shown in Figure 6. Second, variations of the problems with current building automation systems that we sketched earlier can be found in other automation domains as well. The automation framework we have presented is not likely to be suitable directly for many of these domains, but the concept of a framework that incorporates multiprotocol devices, a semantic object model, and World Wide Web integration is, we believe, relevant. REFERENCES [1] Tridium, available online at http://www.tridium.com. [2] JACEm available online at http://www.tridium.com/cs /products_/_services/jace. [3] obix: Open building information exchange, available online at http://www.obix.org. [4] B. Frank, The obix M2M web, available online at http://www.automatedbuildings.com/news/jul06/articles/tridium/ 060620121505obix.htm. [5] Case studies, available online at http://www.tridium.com/cs/ library/case_study_main.
Figure 1. Niagara JACE architecture Figure 2. Part of the Niagara AX class diagram
Web-server with dynamic data/e-mail alarming, etc. User interface/data Presentation Internet connectivity TCP/IP, HTTP, SNMP Internet connectivity Data logging, archiving Information management Real-time control loops/ schedules/ alarming Java Component Object Model LON, OPC, MODBUS, BACnet, Legacy, etc. Control functions Data normalization Device-level communications Integrated, graphical dev toolset Figure 3. Integration of communications, the common object model, and services Figure 4. Web-enabled architectures for building management systems Figure 5. Application screenshots for remote monitoring (left0 and energy consumption profiling (right)
Figure 6. Proposed enterprise architecture based on Niagara/JACE