Award winning manufacturer of IT-based building automation.
The Taxonomies of oBIX Every taxonomy
outward manifestation of an information model.
outward manifestation of an information model.
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 last month 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 1.1 does 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
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
server 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
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.
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.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]