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.

Commercial Use of Live Energy Models

This is one of a series of posts on how the semantic expression in WS-Calender is beginning to affect buildings and smart energy. WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.

In a previous blog, I discussed new directions in commissioning; including commissioning that incorporates BIM, schedules, and continuous energy models.

Performance Contracting and the new Commissioning

Many building owners are suspicious of energy performance contractors because the performance contractor is both a player and a score keeper. Because a significant effort is required to understand the information in building systems, there are significant start-up costs. These costs, both in money and time, require that each contract include a significant minimum contract lengths over which to amortize the up-front costs. These up-front costs make it uneconomical for energy contracting to use a third party auditor to verify results.If the owner selects a new a new performance contractor, the up-front costs will be incurred again.

Standard semantic tags and ready access to a light-weight BIM can change this.

Imagine a market wherein a cloud-based energy performance contractor could offer same-day initial reports. That same market also supports a number of 3^rd party auditors, cloud-based, each able to independently assess the results of the performance contractor. Each of these parties can hook up to the BSI, read the BIM, read the tags, and begin analyzing right away. A potential energy performance contractor could offer the building owner a selection of third party auditors to report the success of the contract.

This competition between cloud-based services would drive rapid innovation. On one side driving costs down, on the other driving richer models. These models are likely to build upon two significant efforts currently underway. ASHRAE SPC201 would inform the models, and through the linkage of systems and space, become more nuanced. Schedule-based business assertions, as we are beginning to see in the links of WS-Calendar and the IFCs would make these models more business aware.

Continuous commissioning based on such a foundation would support an ecosystem of cloud-based service suppliers, each able to grow to scale.

Retail use of Live Energy Models

As we move in this direction, we move from information models that are tuned to reflect changed operating hours to models that can tied increased energy use to short term activities, including, say those associated with a sale in one portion of a store. That portion of a store with an ongoing sale may have increased HVAC driven by increased traffic or brighter lights to attract shoppers and display the merchandise, and other enhanced amenities. A side effect of the brighter lights may be increased heat load, thus causing still more HVAC requirements than at first expected.

The most respected retailers with superior operations are already using these sorts of models to fine-tune their special Sales.

Non-Energy adaptive re-use of new Energy Components

Because the approaches described above rely on the composition of multiple standards, they create components that building integrators can re-assemble to meet other purposes.

Emergency responders have long wished for a variety of interactive means to acquire situational awareness of the facilities they are entering. The standard light-weight building model described above is a natural basis for situation awareness sharing. During an emergency response, the goal may be closer to raw sensor readings than to energy use. Those sensor readings, like the performance information, cannot be interpreted without a framework that indicates the spaces and the business purposes where those sensors are located.

Common abstractions, business purposes, and frameworks are the foundations for policy-based interactions with any system. The business-purpose-based analysis of space and system and schedule, is a likely target for adaptive reuse for emergency-response based policy. In the simplest (and direst) case, the facility is on fire, every asset is at risk, and so every bit of information about a building might be shared. In a simpler case, if the Spill Response Team is responding to a minor spill in the warehouse, it is inappropriate to share with them acess to, say, a webcam in the executive suite.

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.

Doing things at the right time

I have been writing too much elsewhere to write as much as I’d like here recently. WS-Calendar, EMIX, and EnergyInterop all have drafts out for comments this week. Standards specifications require a lot of coordination to get into publication.

Last Sunday, the WS-Calendar Technical Committee released a draft for comments. This is a small component among standards, but one that can help integrate building systems into the businesses that inhabit them. Already there are early attempts to integrate this specification into energy, into the enterprise, as well as into building operations.

I couldn’t make it through a week without using the IETF standards iCalendar and its supporting communications tools iMIP, iTIP, and calDAV. I am thankful for the many hours they save me every week. I think you may feel the same way, too.

What, you say? You don’t think about these standards? Well, that’s because they are ubiquitous, they work, and are therefore invisible. You use them to schedule meetings, and webinars, to remember plane travel and hotels reservations. They are everywhere, they work, and so we don’t talk about them.

WS-Calendar builds upon these specifications to bring schedules and synchronization to web services and inter-process communications. We created WS-Calendar to create, share, invoke, adjust, and track coordinated response between domains and organizations. By domains, I mean different groups that speak different languages. WS-Calendar will see use in financial instruments and building systems, in energy markets and in enterprise systems, in PDAs and electric cars.

Of most interest to automated buildings readers is how it affects building systems, and what new opportunities it opens up there. Years ago, when became chair of the oBIX TC (Technical Committee), I observed that the BAS needed to know the schedule of the conference room. My corporate calendar already knows when meetings begin each day, when they end each day, and how many people are in each meeting.

There is already a rough draft to incorporate WS-Calendar into oBIX, the OASIS web services standard for communicating with building systems. I have discussed use of WS-Calendar with many members of the BACnet community. It is likely that both communities will soon be able to use this specification to communicate with their respective building systems.

We can expect that enterprise systems will soon support this information sharing. Apple, Microsoft, and Oracle all participated in the WS-Calendar process. I have heard of a trial use of WS-Calendar directly from a Microsoft Exchange server. The makers of registrar’s office software, used to schedule college classes, are looking to communicate class schedules, and the number of students in each class, directly with the building systems.

Smart grids and demand response are everywhere in the news today. Smart grids communicate energy shortages and surpluses to the end nodes of the grid: buildings, homes, and industries. New standards for energy market communications include WS-Calendar. Through WS-Calendar, Energy, Enterprise, and Buildings communicate in a common language to discuss when and how to perform.

WS-Calendar is based on a suite of documents, all currently seeking comments. xCal defines a standard way to render iCalendar information in XML. CalWS is a web service standardizing the API for Calendaring & Scheduling functions on any platform supporting calendaring. WS-Calendar is the component for inter-domain communications.

Comments on WS-Calendar can be posted using the comments link at http://www.oasis-open.org/committees/ws-calendar/

Its almost here – and time to start planning how to use it.