AutomatedBuildings.com Column - Work Plan for oBIX 2.0

The oBIX Committee (open Building Information Exchange) is meeting again. The work is moving ahead on multiple fronts. We have separated encodings (XML and Constrained Application Protocol CoAP) from the core specification, to allow easy adoption of new encodings. We have separated the bindings from the core as well, and are creating separate transport binding specifications for SOAP and REST (including JSON). We are doing a refresh of the core specification for consistency and conformance. I am most excited, however, because we are finally moving on to defining the enterprise services, which we are calling oBIX 2.0.

oBIX started nearly a decade ago as an effort to define a standard means of communication with any building system using XML. Automated Building’s own Ken Sinclair was there at the beginning, along with Ron Zimmer of CABA and the visionary Paul Ehrlich, then at Trane. John Petze dedicated more corporate resources to bringing it along than anyone else. Anto Budiardjo oversaw the initial meetings and gave me constant advice. By 2006, we had created an OASIS specification, and oBIX was well on its way to being the essential middleware protocol of building systems.

The core specification (1.x) requires each oBIX server to provide a lobby. Clients can access the lobby to discover how to interact with the system behind that server. Contracts are special purpose agreements that are added to the lobby. Clients can create and invoke contracts by accessing the elements listed in the lobby. Vendors and integrators can add functionality to an oBIX server by defining special purpose contracts and placing them in the lobby. Under oBIX 1.1, soon ready for public review, the lobby of oBIX servers will provide access to contracts, as it does today, as well as itemize the encodings and bindings it supports.

With enterprise services, we are defining new types of contracts to place in the lobby. These contracts will be designed for more direct interaction with enterprise systems, able to participate in service oriented architectures (SOA) and interact with corporate security systems and to participate in policy-based management. oBIX servers will provide access to these contract types through the lobby.

As of our last meeting, we are discussing the following enterprise contract types:

oBIX Servers are likely to participate in collaborative energy ecosystems including those managed by Energy Interoperation (OpenADR 2.0) or as described by ASHRAE SPC 201. We plan to incorporate the information models and semantics developed to support the US national Smart Grid efforts, including Green Button. Potential contracts include not only energy usage reporting, but projections and commitments as well. We anticipate leveraging the existing OASIS Energy Market Information Exchange (EMIX) specific information exchange requirements as defined in NAESB REQ 21

The oBIX historian does not scale well in its current form. A request for, say, a one year history on several sensors is too large and more unwieldy than it need be. We will define means to handle larger data sets, including ones that convey multiple readings, including energy usage, in a single series. This model may be able used to convey requests and projections as well as reports. We do not want to break compatibility, so these contracts will be in addition to the existing historian contracts.

Enterprise alarm logic will define a means to convey more complex queries. If A happens followed within three minutes by B. If the cycle between occurrences of A is less than 5 minutes. This is in effect defining diagnostics with interactions between functions. These queries may apply across many systems behind a single oBIX server, or across many oBIX servers. If I am talking to 100 oBIX servers, I may want to apply that diagnostic to every AHU attached to each of them. This implies the ability to apply higher level semantics above the low-level points – see notes on BIM and tagging below.

In buildings, control systems operate building systems. Building systems support the various spaces in a building, whether securing them, monitoring, them, or conditioning them. The relation between a building system and spaces in a building is described in a Building Information Model (BIM).

There is an existing set of rich models for BIM, including readily accessible profiles codified in the US National BIM Standards (NBIMS). There is growing use and adoption of the Common Operations Building information exchange (COBIE), which specifies the subset of a larger BIM needed for operating a building. COBie can also be generated as the output of standards-based commissioning processes.

Most mainline Computerized Maintenance Management Systems (CMMS) are already able to incorporate COBie information directly. Other efforts are defining the use of COBie Lite in enterprise resource scheduling, including conference rooms and office spaces. COBie shares a semantic framework with existing services provided by standards-based BIM Servers.

We plan to profile the use of the soon-to-be-released XML expression of COBie, COBie Lite, as a semantic framework for oBIX points.

Tagging standards address some of the same issues as BIM. A report from the National Renewable Energy Labs (NREL) states that common tagging standards are critical to developing vibrant markets for building-based services, including cloud services. (http://www.nrel.gov/docs/fy11osti/50073.pdf) But few companies have developed tagging standards or enforce them during commissioning. Brian Frank, primary author of oBIX 1.0, has devoted much effort to tagging as an “open source ontology” for building systems in the Haystack Project. (http://project-haystack.org/)

When tags can be applied to points, then one can create complex queries based on the tags. These queries can themselves be the basis of oBIX contracts. The Committee has just begun discussing tagging standards, and how they relate to the functionalities offered by BIM-aware contracts.

[an error occurred while processing this directive]Enterprise Scheduling applies the semantics of WS-Calendar to schedule interactions with building systems. This includes a notion of service oriented schedules instead of the control oriented schedules as today. (Example: Request room at temperature by 8:30 rather than Request room to begin heating at 8:10).

Enterprise scheduling relies in part on the meta-information provided by BIM or Tagging. For the enterprise to create a contract that asks for the Sycamore Conference Room to be ready between 9:00 AM and 11:30 AM, the relevant systems must be tagged with a room identifier for that conference room.

In enterprise calendaring systems, rooms are part of a general class of objects called resources; resources are the “non-people” things being scheduled. In enterprises, there is a need to catalogue accurately the attributes of a resource: internet connectivity, phone bridge, projection screen, capacity, etc. COBie (see BIM above) is one potential source for this information. If the information in both the enterprise system and the building system share is loaded from a common COBie set, it could be straight-forward to map enterprise resources and BAS contracts.

There is a class of enterprise calendar interactions under the name VPOLL. VPOLL looks find the best time for multiple participants using multiple systems to meet. In effect, VPOLL looks to create a standards-based interaction to accomplish what many use Doodle Polls for today. (http://doodle.com/) VPOLL interactions can consider the relative costs of meetings and participants. Perhaps oBIX will support VPOLLING of building systems as well.

oBIX 1.0 assumes a monolithic model, all or nothing, for access to points and settings. This access could be limitable by role and by organization. We will define a means to define policy frameworks for secure access to oBIX servers. This is likely to be an intersection of roles, i.e., integrator, operator, tenant, guest as applied to business function. In buildings, business functions are defined by the spaces they are in. The relation between building systems and space can be found through reference to the BIM.

We will not define a mandatory set of roles, or a mandatory framework, but instead define a means to apply notions of space (say a particular tenant) and of role to access to an oBIX server. We anticipate a means to discover the roles available on a server, to map those roles into a discoverable space, i.e. BIM. This topic includes addressing federated security, and may include how to apply SAML, XACML, and similar specifications to oBIX servers.

Participation in oBIX 2.0 is open to all OASIS members. OASIS membership is by company, so a single company can put as many participants or observers on the Committee as it wants. If you would like to participate, please contact me at Toby.Considine@gmail.com for assistance in getting signed up.

Editor's Note: We are very pleased that the industry is using our Linkedin group to ask questions and gather information.

This group interaction allows us a closer relationship with our online content and allows the content to be taken off site to Linkedin Open chat space for a real discussion.

But what I like best is that we are now seeing interaction from this group on our web site and content has more industry input by those who care.

The result of all this group interaction is more reading of AutomatedBuildings.com plus a better understanding of the value of the content placed there.

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

Events	Want Ads
Our Sponsors	Resources