The Taxonomies of oBIX

Note: Niels Bohr famously observed that prediction is very difficult, especially about the future. Getting down into the technical weeds of a specification that is not yet complete is also difficult. I received numerous requests to explain how Haystack fits into future versions of oBIX. OBIX is a specification whose development is in mid-flight. OBIX 1.1 comes out for its first public review in July. The enterprise wrapper for oBIX, aka oBIX 2.0 is months away. Perhaps some readers here will join and help us get to the final form faster.

OBIX does 1.1 not require or support Haystack. OBIX 1.1 will not even mention haystack, except, perhaps, as an example. OBIX 1.1 will be able to provide metadata for any point. That metadata may be drawn from any formal or informal taxonomy. oBIX 1.1 does not define how taxonomies are applied to an oBIX server. Haystack is useful taxonomy of growing popularity that can be used to provide metadata about any oBIX point.

Haystack is a taxonomy that describes a lightweight building information model (Slim BIM) for BAS systems. Haystack tags are unique in that they were developed as a folksonomy, i.e., through an informal consensus among users. Haystack advocates may point out that all the formal taxonomies once created to classify internet searches were beaten by the automatically generated folksonomy at the heart of the Google search engines. Traditional large BIM models provide taxonomies developed through formal processes and often mandated by national agencies; metadata in oBIX can be the entry point into Big BIM. OBIX is taxonomy agnostic, and can support both, or either.

Interactions with an oBIX server begin by entering the “lobby” and asking for information about the system. One of the new inquiries in 1.1 will be “Which meta-information standards do you support?” A valid answer is “None”. For backward compatibility, an error message, from an oBIX 1.0 server that does not understand the question must be interpreted as answering “None”. If the oBIX server supports one or more meta-information standards, it will name them. We have not spent much time on the Lobby inquiries yet, but I think this answer should include a local tag, a URI for each taxonomy, and an optional URL for queries based on that taxonomy. Those queries are a subject for oBIX 2.x.

Under oBIX 1.1, a client can query a point for its metadata. The oBIX server returns a collection, with each element including a tag identifying the element’s taxonomy, and the metadata information. If some of that metadata is based on Haystack, then the returned metadata information may include one or more Haystack Tags. The same set may include elements drawn from other taxonomies. It is not hard to imagine a single BAS gateway that supports a Haystack, EMIX (Energy Market Information Exchange), Tenant Information, and situation awareness / security.

There are many taxonomies for building systems already in wide use. Walmart and Target, two companies that have unusually complete construction and commissioning specifications, have long mandated the use of specific tagging standards. The Intelligent Kitchen standard, promulgated by McDonald’s could specify a meta-information specification. Many use oBIX to interact with control systems that have nothing to do with BAS. Groups such as OPC, used widely in industrial scenarios, have their own taxonomies. SensorML, a standard developed by the Open Geospatial Consortium (OGC) is widely used for scientific observations and for situation awareness; SensorML provides a taxonomy that can easily be applied to oBIX points.

Every taxonomy is the outward manifestation of an information model. Haystack assigns responsibility for assembling a building’s specific model to the client. The client must assemble the sum of all the tags, and follow all the references, to create a coherent model of the systems exposed. There will be many incomplete models generated from BAS gateways that are badly integrated or commissioned. To enable a client to query the model directly, the server itself must have a model. Model-based queries are part of oBIX 2.x and have no place in oBIX 1.x.

Not all BAS systems need to or will incorporate model service or even meta-information. It is easy to imagine an information appliance that acts as the model holder for an underlying metadata-free [BACnet] system. Such a system would provide direct access to the points in the underlying system, and offer up the meta-information provided by the taxonomy. There might be advantages to setting these up as audit-servers unable to interfere with the underlying control operations. A standards-based BIM server, serving up BIMSie, may be an example that brings such systems into conformance with DOD and EU expectations without requiring re-development of the underlying control protocols.

We should resist the impulse to develop the one, true, absolute application model for all time, and baking the taxonomy that represents that model into every low level protocol everywhere. What we should do, is develop standard lamina, layered information models that live outside the work of an individual integrator, but provide higher level access that increases the value of the initial integration.

Consider a microgrid consisting of a green building, and an oBIX serving using Haystack to describe its underlying systems. Alongside could be an oBIX server managing solar generation, and another managing private wind farm. The oBIX gateway to these distributed energy resources could support SensorML-derived tags, useful to describe the weather and environmental data gathering that best predict energy generation. All three systems could also support the EMIX taxonomy to describe the energy supplied as well as the energy used in the green building.

oBIX works with collections of points named Contracts. Within the simpler taxonomies, one can imagine building a contract to include all points with a given tag. A more interesting query might leverage the model in the taxonomy; for Haystack, this might include all temperature sensors on Air Handlers with a relation to a given chilled water loop. Some queries will not be answerable from a single interface. An external BIM server might be the appropriate way to build a query against a more complex taxonomy. Such queries are out of scope for oBIX 1.x; we intend to define a model for such queries within oBIX 2.0.

The most interesting contracts will be built from querying two or more taxonomies at the same time. Look to a generic query language for both intra- and cross-taxonomy contracts in oBIX 2.x. We have some ideas on how to do this already, but that is much, much deeper in the weeds then I want to go at this time.

Work Plan for oBIX 2.0

Some of you know that the oBIX Committee (open Building Information Exchange) is meeting again. The work is moving ahead on multiple fronts. We have separated encodings (XML and COAP) from the core specification. We are working on separate transport 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 about the oBIX 2.0, the enterprise services.

The core specification (1.x) requires each oBIX server to provide a lobby. Clients can ask the server what is in the lobby, and thereby discover how to interact with the system behind that server. Contracts are special purpose agreements that are added to the lobby. Clients can invoke contracts by accessing the elements listed in the lobby. Vendors and integrators can add functionality to an oBIX server by creating contracts to add to the lobby.

Our current plan is to define enterprise services by specifying new types of contracts to place in the lobby. oBIX servers will then state which types of contracts they support, which encodings, and which transports. As of March 2013, we anticipate the following sections:

Energy

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 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 historian does not scale well in its current form. A request for, say, a one year history on several sensors is larger and more unwieldy than it need be. It may be necessary to support variations such as projections. We do not want to break compatibility.

Alarm Logic.

This topic extends alarm contracts to include logic for alarms. 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. If I am talking to 100 oBIX servers, I may want to apply that diagnostic to every AHU attached to each of them.

Building Information Models (BIM)

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). oBIX BIM contracts will describe how an oBIX server will make BIM accessible, and how to apply BIM as a semantic framework for the control points.

Enterprise Scheduling

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). This is likely to use the same semantic frameworks as security, i.e., to specify a room rather than a thermostat. Enterprise scheduling is made possible in part by the BIM framework as described above.

Security Composition

oBIX 1.0 defines a monolithic model, all or nothing, for access to points and settings. This access should be limitable by role and by organization. Advanced security contracts 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.

Please contact me if you would like to join in this work.

BSI and a blast from the past

Every now and then I run across an old email that I have long forgotten, but speaks to my current activities. I think that this comment, written long ago in the oBIX forum speaks to something I need to return to. Jon recently gave me and WS-Calendar and EMIX some excellent advice on on creating standards for re-use and extension.

-----Original Message-----
From: Considine, Toby (Facilities Technology Office)
Sent: Wednesday, January 05, 2005 6:36 AM
To: 'jon.bosak@sun.com'
Cc: 'Grobler, Francois ERDC-CERL-IL'
Subject: RE: oBIX Guiding Principles

There are parts of Control Systems that are very business oriented. If an embedded control system detects that it needs maintenance, and can submit a maintenance request to an identified partner, clearly that work order looks like a normal business transaction.

Meeting and occupancy schedules might look like UBL (room will be occupied tomorrow from 2-4; use oBIX to inform HVAC, Access Control, Intrusion Detection, A/V management control systems. Read the Electric Meter before and after the meeting). Does the UBL standard extend the ICAL standard, or subsume it or...? Clearly, there is a benefit for scheduling functions to re-use commonly implemented scheduling requests.

These functions are in the future. What oBIX has to start with doing is exposing the event driven world of controls to the enterprise. For the most part, this starts with state. What are all the room temperatures on the 3rd and 4th floors? For how many hours did the compressors run today?Which areas of the building are currently secured? Some of this information is creeping into QOS agreements in real estate, and so intersects with the work of OSCRE (Open Systems for Commercial Real Estate). To my knowledge, UBL does not really include the nomenclatures for this because this is outside of the normal business functions. Am I wrong? Can you refer me to any relevant portions of UBL?

I think an early use for oBIX will be to provide a platform on which GRIDWISE (www.gridwise.org) type applications are built. That may be the first place where standard UBL functions hit, as price incentives are offered to buildings on the spot market to forefend brown-outs and the like. That feels more like bid/delivery/request rebate.

The construction industry has long had a separate open standard for construction documents, known as the IFC (Industry Foundation Classes) developed by the International Association for Interoperability (http://www.iai-international.org/iai_international/) and already required in many international construction projects. The IFC space includes construction documents, spatial data, spatial modeling, etc. The EU, in particular, leans heavily on this ISO specification, particularly in the Nordic countries. The largest landlord in the world, the GSA, has mandated that all transmittals for the design, construction, and acceptance of buildings. The closely related GBXML (Green Building XML) is a lightweight variant of IFCXML focused more on performance issues. GB Modeling, using GBXML for transferring building performance data, is required for those projects that wish to be designated as compliant with programs using words such as "sustainable" and "LEEDS". We have long considered that IFCML and the closely related GBXML were our most important shared spaces. Is there a defined interface/mapping between IFCXML and UBL?

Thanks for your comments

tc

-----Original Message-----
From: jon.bosak@sun.com
Sent: Tuesday, January 04, 2005 9:20 PM
To: Considine, Toby (Facilities Technology Office)
Subject: Re: oBIX Guiding Principles

| G) If, as seem likely, this document is adopted as an OASIS standard,
| I recommend that we steal freely from this document, reusing as much
| as we can in our rules for developing subsidiary oBIX services as well
| as in the core document. It is well written and defends its decison
| in a language that is focused and apropriate for the enterprise
| developer.

Since UBL is probably going to become the dominant standard for international trade documents, why don't you just adopt the UBL schemas and have done with it? After all, UBL is based on a pretty widely adopted specification (xCBL 3.0) that was developed specifically for electronic marketplaces. If there are any data elements missing from UBL 1.0 that are needed for oBIX, we can probably include them in UBL 1.1.

Jon

Ready for the BSI

I want to get back to buildings soon. Smart grids are engaging, but I think our goals for the future will be met by buildings.

For months, all my writing has been about smart grids. More particularly, for November, it has all been about smart grid standards.

As I write this, the essential market interfaces of the grid are in review. A common communication of schedule and interval, suitable for sharing schedules between grid and enterprise and building and finance finished public review last Tuesday. We have nearly 80 comments to settle, but soon we will be ready to discuss using ws-calendar not only in smart grids, but in buildings.

Energy Market Information (EMIX), the critical description of energy product and price has two more weeks for public review. Energy prices always have a schedule, and EMIX uses WS-Calendar. EMIX supports demand response, but more importantly, full participation of buildings in all energy markets. EMIX is in review until the 17^th.

Energy Interop was released for public review last Saturday. EI (as we call it) defines the essential e-commerce framework for interactions between grids and aggregators and utilities and, yes, buildings. EI is locked for review until December 27.

Now, I am reeling from a week at Grid-Interop, at which I have spoken 5 times, sat In two meetings of the Smart Grid Architectural Committee, and practiced politics (difficult for me) in numerous other meetings. In October and November I put three of the four market interfaces of the smart grid out for public review. Light, loose, market oriented, interfaces that transfer incentives for participation to the buildings. Now I am longing to talk of buildings again.

Today, at Grid-Interop, the focus shifted to buildings as microgrids, each responsible for managing energy use, generation conversion, storage, and, only as a last resort, market operations to make up the difference. This is what I wanted to accomplish when I got started on Smart Energy. No grid control, which would strangle in-building innovation. Maximum grid incentives, all delivered to a single energy services interface (ESI), the locus of market bidding for the building.

Now I turn back to the building, Now I want to think of the Building Systems Interface (BSI), the abstract interface to building systems. Some of it is building services as in BAS, abstracted with system metadata, and associated with the space it supports, the space that the tenants recognize. Some of it is simple appliances, and the way the communicate in homes. Some of it is the live or plug load, perhaps discover able, perhaps mappable to space using PLie.

So what are the essential building services? There is energy management, accessible for low integration re-hosting in the clouds, There is performance contracting, also in the clouds. There is energy auditing, which must be based upon the zero integration costs (because the metadata is already in the BSI). Energy auditing? Well what if we call it a live LEED rating, or perhaps 3^rd party verification of the performance of the performance contractors… BIFER (BI for emergency responders) may even come from that mix.

There is an enterprise service, that links between the occupants and their activities and the BAS and its performance. It communicates to support business activities while using the common schedule communications developed for smart grids. It is aware of the market conditions and deals made with the grid though the ESI. It knows whether the volatile energy of the renewables-based grid is scarce or abundant. It can report back to the enterprise how and where energy is being used right now.

This needs some standards to fly, to be cheap enough to let these cloud-based services flourish. PLie needs to be advanced to a standard. oBIX trends for energy management must be accessible form self-metering systems and from switch panels, and be able to support the NAESB Energy Usage Information standards. There must be a light-weight BIM, my vote is for GBXML, able to act as the spatial lens through which to view energy use.

I want to define the BSI…

But now, rest, and sleep.