A new concept is gaining momentum in the swirling alphabet soup surrounding the latest advances in building automation and systems interoperability.
And, it likely will further revolutionize how buildings are run, managed, and maintained in today’s technology-focused society.
The newest player is oBIX, or the open Building Information Xchange. It is an initiative to define Internet standards, such as the programming language XML (Extensible Markup Language) and Web services – automated resources accessed via the Internet using an XML platform – for communications between building systems and enterprise applications.
“In short, it is a way to provide an open, secure, network-friendly method to share information between disparate systems, as well as business systems,” notes past oBIX Chair Paul Ehrlich, a business development leader at Trane Global Controls and Contracting in St. Paul, MN.
oBIX burst to life in April 2003 as the CABA XML/Web Serv-ices Guideline Committee, a working group of the Continental Automated Buildings Association (CABA), based in Toronto. It has rapidly grown and evolved, developing a life unto itself. Those involved in oBIX believe that use of the programming language XML and related Web services are instrumental in enabling interoperability and data sharing within commercial facilities in a secure, reliable way.
Savvy building owners and managers are realizing that their buildings are a prime source of data, providing insight into operations in the same way such key areas as sales, human resources, marketing, and financial information are being used for business intelligence. As noted in the Guideline for XML for Use in Facility Management (www.caba.org/aboutus/com_standard.html#obix), this segment also views IT networks as being both the “backbone for communications and the channel to collect and disseminate all business data.”
“There’s an overwhelming amount of data contained within buildings, and unfortunately, very little of it is used in a way that really helps [building owners and managers] improve the overall efficiency of a building,” notes Barry Haaser, executive director of San Jose, CA-based LonMark International, which supports the oBIX initiative.
While use of industry-specific standards – including BACnet,® LonTalk,® Modbus,® and more – can achieve this, sometimes complicated translation is necessary. Other challenges also arise, including security issues, database and business application compatibility, and IT staff support.
According to the Guideline for XML, using common network standards in an open, interoperable method will permit the integration of both business systems and sub-systems in a method that can be secure, and most importantly, extensible.
“The intention is to be able to tie all building systems in with the use of oBIX regardless of the protocols or technologies applied within these systems,” Ehrlich notes. “It doesn’t matter if these systems are based on existing open protocols, such as BACnet, LonTalk, or Modbus, or vendors’ proprietary protocols. In order to make a system oBIX-friendly, it will need to have access to a network that supports TCP/IP. Also, the system will either need to be designed to support oBIX, or a gateway will be required.”
New oBIX Chair Toby Considine, manager of Technology Serv-ices for Facilities Operations at the University of North Carolina – Chapel Hill, stresses that it is important to remember that oBIX is not a replacement for control system protocols. “It is not a competitor for BACnet/XML or Lon XML. Because oBIX is an abstraction of the building control systems, it does not replace them. Most early implementations will involve gateways to the control systems,” he says. “Lon and BACnet are controls protocols that are used in controls systems. oBIX is an enterprise protocol that talks to control systems over the Internet. Lon and BACnet will be, as they have been, the best open protocols for implementing controls systems, particularly those that have HVAC as a significant component.”
While considerable effort has been expended over the years to extend the BACnet and Lon systems to communicate over TCP/IP, such efforts largely have focused on communicating with other control systems. But, technology experts note, the resulting distributed control systems are still isolated from the other information technology-based systems.
“If diverse applications from HVAC to lighting, from access control to human resources, from parking to tenant billing for after-hours energy consumption, or from dorm residence to administration enrollment, are to be optimized for the enterprise, they need to do so over the IT infrastructure and use Internet technology,” says committee member Rob Zivney, vice president of Marketing at Hirsch Electronics, a Santa Ana, CA, manufacturer of high security access control and security management systems.
He continues: “BACnet and LonWorks® haven’t yet done that. These protocols do a good job of addressing control and process monitoring applications on dedicated networks. However they don’t even contemplate HTTP or operate over the Intranet or Internet in a meaningful way.”
That’s where oBIX comes in. Instead of replacing these tried-and-true systems, oBIX works with them, striving to develop a standard to provide an “abstract instrumented interface to building control systems with an enterprise focus.”
The Nuts and Bolts
First, when these technology experts say “enterprise,” they are talking about business and the software that runs the business. Well-known enterprise applications include SAP, Oracle Financials, and PeopleSoft. Smaller enterprise applications include Great Plains and Peachtree, as well as ones all the way down to QuickBooks®.
The enterprise also can be described in terms of the disciplines of enterprise software, including Customer Relationships Management (CRM), Manufacturing Requirements Planning (MRP), Enterprise Requirements Planning (ERP), and Sales Force Automation (SFA), among others.
Thirdly, enterprise applications can be described by the tools used by enterprise developers who work within such environments as Java, Pearl, and .NET, using such tools as MS Office, IBM Web Services Toolkit, and Apache Axis.
oBIX will work with these systems through an abstract instrumented interface. By way of analogy, Considine suggests that you think of a car.
“The control system of my manual transmission VTEC sedan is quite different from that of my wife’s automatic transmission minivan,” he notes. “In neither car do I, the operator, really want to know what the different control systems in the two cars are, nor do I want to have to know how the injection and carburetion decisions really change at different speeds under VTEC.”
Instead, the cars have instruments to do the work: a speedometer, fuel-level gauge, engine temperature gauge, and warning lights. Some cars have additional instruments, such as a tachometer and an oil gauge, and perhaps even a cruising range.
“With these instruments, I can drive a car without knowing anything about its control system,” Considine says. “I can also drive any car.”
He again stresses that as an interface to building control systems, oBIX does not replace existing protocols BACnet and Lon.
“Those protocols are under the hood,” Considine says, continuing with the car analogy. “oBIX is a protocol for operating or for supervising those systems. oBIX wants to make the mechanical infrastructure a full participant in the enterprise. Just as delivery men in trucks have grown into full-blown logistics operations when they became IT-enabled, so will the mechanical systems become full players in the enterprise.”
What This Means for Commercial Buildings
In terms of the facilities industry, “enterprise application integration” is a “long way of saying ‘building intelligence,’ ” Ehrlich notes.
“It is the connection between facility management systems and the business systems that are used for making decisions regarding purchasing, operations, and other daily business decisions,” he says.
The benefits of oBIX are simple. It is something that is readily supported and provides secure communications using an organization’s Intranet and the Internet. This means users will be able to easily access facility information from any location in the world, yet be protected against hacking by unauthorized users.
oBIX will provide easy integration between a broad range of facility systems, such as HVAC, security, fire alarm, electrical, and more, as well as easy connection to business applications, including such tools as databases and spreadsheets.
Examples of relevant business systems in the facilities industry that could tie into oBIX include maintenance management, energy information and asset management systems, HR systems, and enterprise resource management. oBIX uses the same technology as many of these systems and is designed to make the movement of data possible using standard tools to achieve building intelligence.
“oBIX will bring the relevant information and methods up from the control systems to the world where enterprise application developers work,” Considine says. “It will provide information to these large systems and take directions from them. But, it also will be available to smaller systems.”
But it goes beyond that. oBIX’s integration does not cover just one system, but all of the building control systems. It’s not limited to HVAC or access control. It doesn’t just work in the A/V or meeting rooms. It works in all of them.
A BuilConn (www.builconn.com) survey in 2003 identified 47 separate vertical industries of building control systems. Considine says he knows of still others not on the list. “These vertical markets have their own protocols. They have their own vocabularies,” he notes. “It is a goal of oBIX that the supervisory message to each system to ‘schedule an event from 6:00 p.m. to 9:30 p.m. next Tuesday’ be sufficiently abstract that no special knowledge of their internal scheduling data structures is required.”
According to Considine, building owners will be able to offer enhanced services to tenants without risking assets on long-cycle complex integration projects, providing services across multiple buildings in multiple locations.
Consequently, facilities managers will be able to more easily orchestrate operations across multiple control systems, keeping these systems as separate islands of automation within a supervisory framework.
Tenants will benefit as the quality of service provided by facilities managers improves, Considine points out.
“The tenant will be able to better maintain virtual corporations across multiple sites,” he says. “As the owner is able to unbundle services provided by the facility, tenants will be able to select the services they require while better understanding their actual cost. Tenants will be able to directly monitor the quality of service in the facility. Information that is hard to get today and that may affect regulatory compliance or business operations will be easy to get.”
Zivney cites one of Hirsch’s exit control systems as an example of this kind of functionality. Not only can the system count how many people are in a building at a given time, it also can pinpoint where in the building they are and track other important usage information, such as energy.
“Let’s say a fifth-floor tenant goes in the front door after-hours and pre-sents the access card. Now the lighting on the fifth floor is turning on prior to the floor being occupied. All the lights are lit in the area,” Zivney says. “The card access tells the HVAC to go from unoccupied setpoints to occupied setpoints. This starts from the time the person uses the card when he or she first enters the building, so the property manager gets to charge that particular tenant organization from the time that person walks into the front lobby door until they walk out. It also can provide such discrete information as who that person is and what time they came in so the tenant can learn if it is only one person working after-hours and [whether to] tell them to change their habits.”
Jumping In, Getting Involved
In order to reach complete interoperability at an enterprise level, the facilities department will need to boost relations with the IT department, if such measures haven’t already been taken.
“You might have your turf battles, but you have to develop a relationship with your IT department because you can really help each other,” Zivney urges. “The IT department doesn’t want to drive the applications and be experts, but they do provide the infrastructure. You have to look at the IT department as an important resource.”
Externally, you’ll want to start monitoring the Organization for the Advancement of Structured Information Standards (OASIS) happenings. OASIS is an open organization, so if you visit (www.oasis-open.org), you can sign up to watch the committee proceedings. While there, visit the oBIX area and read the various white papers.
“If you see an area of concern, send an e-mail to the participants,” Considine says.
Finally, get involved. The committee is inviting facilities professionals to become involved as advisors in the creation of the standard. Join the group and put in your proverbial two cents. They need you to provide information on how the facilities management industry wants to use oBIX. They need real-use cases to study so they can prioritize the features for early delivery.
The group is crafting a subcommittee for oBIX within OASIS to make sure less technical or less controls-oriented participants will have forums to discuss what they want from oBIX and to use that feedback to tune the objectives of the data structures subcommittee, Considine notes.
“Not surprisingly, we have more participation by controls manufacturers than we have by any other stakeholder in the building environment,” he says. “We need equal participation from owners and facilities managers to make sure we not only create oBIX, but create the right oBIX.”
Robin Suttell (email@example.com), based in Cleveland, is contributing editor at Buildings magazine.
The Not-So-Mysterious XML and its Buddy SOAP
XML isn’t some Space-Age machine or development. In short, this software language, more formally known as extensible markup language, is merely a text format for description, storage, and transmission of data.
It is analogous to HTML (hypertext markup language) that is used to describe the World Wide Web. In non-technical terms, the difference between HTML and XML is this: HTML is a method used to share information between computers (Web servers) and humans through text and images to the browsers as a Web page, while XML is the standard way to share data between computer and computer. It addresses data only.
HTML and XML both grew out of language derived from desktop publishing applications. Where HTML uses abbreviations in its language to deliver the text and images to a Web browser, XML is written in plain text without what experts refer to as the “abbreviations and laxity of HTML.”
“The plain text makes XML easier to read and understand,” says Rob Zivney, vice president of Marketing at Hirsch Electronics, Santa Ana, CA, and a member of the oBIX committee. “This is one of the first key features that leads to XML’s compelling benefit – interoperability.”
XML is also extensible. That means it is easy for one manufacturer/developer to add new lines of code in order to add more features without requiring all other applications using XML to also change their protocols or code base to support the additions. Extensibility, Zivney says, is the second key feature because it encourages and allows systems manufacturers to continue to add value in their offerings, yet keeps everyone sharing a common language.
The “ML” portion of XML means that tags are placed before and after data to describe the data. For example, an “element” in XML that defines a door in an access control system might look like this: Lobby Entrance. This clear text feature makes it easy for one manufacturer to understand another’s application and database.
A more important question than “What is XML?” is “What is SOAP?” says new oBIX Chair Toby Considine, manager of Technology Services for Facilities Operations at the University of North Carolina – Chapel Hill.
SOAP, Simple Object Access Protocol, is a means to ask for and get XML and looks a great deal like a standard Web page or e-mail reader, Considine says.
“The Web today has been derided as ‘eye candy,’ meaning you can look at it, but you cannot plug three corporate websites into your stock picker and expect to get anything out of it,” Considine says. “SOAP has been described as, ‘Letting computers surf the Web for data like people surf the Web for eye candy.’ ”
How does this apply to commercial buildings? Simple. XML and SOAP will enable systems to ask a database, a Web server, and a thermostat for the last known temperature using the same methods.
“To make this vision possible, we will require standards, not only for cataloguing building systems and their data points, but for characterizing data and for defining secure access to those systems,” Considine says. “Because SOAP is the basis for electronic business, we can leverage work already done for all of those except describing building data.”