The University of North Carolina at Chapel Hill is the nation’s first state university, founded in 1789.
So perhaps it’s appropriate that the home of the Tar Heels will be the first school of its size to integrate all of its individual building automation systems (BAS) into an enterprise building management system (EBMS) using web services. This new system, designed by Affiliated Engineers, Inc. will be fully implemented over the next 12 to 16 months.
Due to the massive size of the current building automation infrastructure—more than 140 buildings with approximately 33,000 BAS points throughout the school’s 729-acre campus—UNC felt that it was time to integrate all of the disparate systems and system points into one graphical user interface. The EBMS method is a new approach to multiple building operations that will allow UNC’s traditional automation systems to actively interact with new and existing enterprise systems being utilized by both business and educational units all across campus. This interaction is made possible through the use of normalized data—XML (extensible markup language) and SOAP (simple object access protocol)—that can be shared with and drawn from existing programs such as space planning, registration, billing or any number of other enterprise-level systems.
Creation of the EBMS at UNC involved a thorough understanding of campus requirements and the various individual BAS currently installed. For a systems integrator to bid the project accurately, this knowledge was critical. The resultant request for proposal package included all bidding requirements, technical specifications, a legacy system point list and network architecture requirements. An exhaustive survey of the campus buildings was undertaken to document the existing automation systems and develop a detailed legacy point list, which included information on system type, building and system level, controller types, manufacturer and software and hardware revisions currently in use and planned for EBMS integration. In addition, an extensive survey was per-formed to confirm current workstation functionality and graphic utilization, ensuring the EBMS would match certain characteristics common to these existing interfaces.
The RFP and subsequent procurement was developed with a two-step process in mind. The goal was to identify the best “value” solution and not necessarily be limited to a low-bid option. The rules of procurement in North Carolina allowed for this sort of strategy when purchasing technology-based solutions. The first step required bidders to submit a detailed technical proposal based on the RFP package requirements. Where a technical requirement could not be met, the bidders were required to submit an exception or alternative solution. The evaluation criteria emphasized the need to meet or improve upon the technical requirements established under the RFP. References and experience of key personnel on the team were also evaluated. As indicated in the scoring sheet (below right), the total cost of ownership was given the most weight supporting the goal of the University to find the best first-cost and life-cycle cost solutions. The second step involved subsequent interviews, questions and answers, and actual price proposals. In accordance with the local state procurement office, the “best value” response would be awarded the project.
Keeping the evaluation and RFP processes in mind, let’s review the situation before the upgrade. The existing building-level control systems were reporting to eight different BAS front ends using materials and software from six different manufacturers, and all operating with various open and proprietary communication protocols (BACnet, LonWorks, JCI-N2, etc.). BAS capacity is expected to grow by an additional seven million sq. ft. of space currently in design or under construction. The sheer complexity and the increased point count associated with this growth will further limit the ability of the HVAC facility-services staff to effectively manage the many different and incompatible control systems in use under the current model. This model, which is similar to most large campus environments, stretches already limited resources in such a way that limits—or in many cases, completely removes—the concepts of energy conservation, preventive maintenance and proactive problem resolution from the staff’s standard operating procedures.
UNC requested a system that would develop a simplified and intuitive operational environment that would ensure the HVAC facility-services group would regain its ability to focus on these value-added services, as well as integrate the existing BAS into a single coherent system that follows current information technology standards of information transfer. The biggest challenge of the project was to develop a method of integration that ensured a normalized data stream at the enterprise (WAN/LAN) level of the system.
As the BAS is increasingly seen as one part of this larger enterprise structure, the need for meaningful and usable information is growing. Certain IT trends—for example, lower bandwidth costs and lower memory cost—continue to push the need for data integration at all levels of the building environment, including the BAS. The IT industry has already developed a set of rules—termed “web services”—that is used to describe the methods needed to share data between computers. Web services are self-contained, modular web applications that can be run over the Internet and can be integrated into other applications. One of UNC’s goals was to transform its wealth of BAS data into an environment that would enable intelligent and real-time business decisions. In other words, the EBMS needed to have the ability to import and export data into and out of other third-party applications like maintenance management, human resource planning, utility management/billing and asset management.
Since most of the existing BAS data at UNC was part of legacy and/or proprietary systems, some mechanism for data normalization had to be developed. A key component of the EBMS design is the incorporation of what was defined under this project as the enterprise building-level translator (EBLT). The EBLT “normalizes” or transforms building data into XML/SOAP messages. XML and SOAP are the basic components of web services. XML is a specification detailing how to encode information and is ubiquitous in the IT infrastructure. However, it is not a complete communication system and must be layered on top of a communication component like SOAP.
Switching gears from how building data is transmitted to how it is used, most of the data generated from a BAS is never actually stored and hence never analyzed. The EBMS employs a robust data historian server application that provides constant and real-time data storage. The requirements can become quite large when considering the storage space needed to record data for 33,000 points at 15-minute intervals over a one- to two-year span. While the data storage needs can be large, the decreased cost per megabyte has made this a non-issue. Utilizing web services to access this data makes it very easy to analyze and integrate it with different applications. The primary goal of the historian is to analyze systems to show the financial impact of decisions and measure performance relative to established engineering models. For example, at UNC, the EBMS will collect utility usage information and real-time utility rates, and calculate real-time price per sq. ft. usage at the building level. The impact of control strategy modifications and building performance deficiencies can be reviewed in real time.
This integration method also provides traditional building HVAC control systems the ability to have new custom applications developed economically for non-traditional clients by using readily available software-development platforms like Microsoft’s .NET or JAVA’s J2EE. These platforms are easy to use and give the facility engineer the ability to create custom applications geared specifically to his or her organization.
EBMS also provides the facilities group at UNC the ability to publish services for other departments. For example, web access to a selected subset of data points can be provided to a researcher to monitor his laboratory conditions remotely. An administrative assistant can set up occupancy schedules and temperature preferences for several dozen conferences simultaneously from his or her own spreadsheet. The classroom schedules set up by the registrar’s office can be automatically incorporated into the HVAC occupancy schedules.
And, the EBMS takes energy use into consideration as well, allowing development of cooperative energy use agreements between utilities and the building occupants. Users may subscribe to various levels of demand management. Higher levels of demand management could result in preferential rate structures as compared to lower levels of demand management.
UNC entered this project with the goal of developing the highest level of operational support to the building occupants, becoming better stewards of the energy being consumed—all while the campus continues to expand in size and complexity. Creating such a system based on IT standards will enable the HVAC facility services staff to have a much more significant impact on the operation and management of the campus. At the same time UNC will also have the ability to implement enhanced demand management strategies and analyze building energy consumption in near real-time fashion.
The EBMS will provide UNC with the management and analysis tools needed for system diagnostics and proactive management such as trending, occupancy scheduling and alarm management. These and many other application examples will give the HVAC facility-services staff the tools necessary to ensure occupant comfort, energy conservation and effectively managed assets. This can now be done at the lowest possible cost and with a minimal staff.
At UNC, the EBMS will allow the traditional BAS to move from a proprietary and private world—little understood by the building occupants—to a system that everyone can actively use to enhance their use of the space they occupy.
Sample Evaluation Criteria
|Note: Actual numbers may vary from state to state and site to site.|
|Technical Specification Requirements||200|
|Project Work Plans||50|
|Total Cost of Ownership||300|
|Key Personnel Experience||125|
|Other Value Added Services||50|
A Graphic Solution
The University of North Carolina, Chapel Hill’s new EBMS has been specified to utilize scalable vector graphics (SVG) to represent data. SVG is an emerging web standard for two-dimensional graphics. Like HTML, SVG is written in plain text and rendered by the browser, except that SVG is not just rendered text, but also shapes and images, which can be animated and made interactive.
Developed by the World Wide Web Consortium, SVG is written in XML. Its scalable nature means that similar graphics can be used on 52-in. plasma monitors, laptops or PDAs without losing resolution or functionality. Since SVG is XML-based, data can be embedded in the code so that graphics represent real-time information. For example, different colors and shapes of graphics can represent different temperature ranges. Graphics representing alarms can differ by the severity of the alarm event, making it easy for operators to know how to act on various events. Once the user interface is in place, BAS points will be mapped to the graphics one building at a time, and as new buildings pop up on campus, they can be added to the system as well.