Award winning manufacturer of IT-based building automation.
Work Plan for
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
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
Advanced Reporting and Aggregation (Historian)
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.
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.
Building Information Models (BIM)
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.
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
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.
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
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
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.
You can join the discussion about oBIX 2.0 in the Automated Buildings
forum at Linked In
Or browse the complete forum.
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.
result of all this group interaction is more reading of
AutomatedBuildings.com plus a better understanding of the value of the
content placed there.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]