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.

Smart Operations are a necessary part of Smart Energy. Maybe GBXML is, too.

It is easy to think we are playing the end game, but we are really working on the early stages of smart energy.

Smart grids may end at the edges of the grid, they may know no bounds, i.e., ZigBee and SEP, or they may end at the meter. Beyond the meter may be a collection of dumb systems, a minimal collection of defined systems with defined responses, or a micro-grid with its own economy, and own dynamics. I think that every node a microgrid is the future.

I was pulled back to thinking about buildings as I prepared to speak at the AHR show in Orlando next week, and by an announcement about an upcoming seminar on GBXML (GB = Green Building). GBXML is a format designed for the exchange of engineering information, particularly that related to energy use and energy efficiency, during the design process. GBXML may be the key to understanding microgrids in buildings.

The challenge when we treat the end nodes as micro-grids is categorizing and measuring the services they provide. These may be relatively clear in the data center, but even there, understanding HVAC support services is relatively obscure to the IT operator. Going a step further and treating the data center as the district energy center for thermal distribution is hard to understand, harder to account for, and therefore difficult for most enterprises to work with. What are the services in the end nodes?

So, after a building has been partially renovated a few times, and has three EMS (energy management systems), each managing a dozen zones, what effect is there on which part of the business when load is shed in a particular way? Which departments, or tenants, are even affected? Do tenants have QOS agreements, and if so, how are they affected.

Full-fledged BIM (Building Information Model), as defined in NBIMS and BuildingSmart, is too fat, too heavy to use in everyday operations. GBXML is a light-weight one-off of the IFCs in BuildingSmart. It was developed to model energy use, and to exchange energy models within buildings. GBXML includes formal definitions of geometries and spaces, and common models for the components of the energy using systems in buildings. It might just be the map between the design, the operations, and the services. GBXML might just be BIM-Light.

Somewhere between the intriguing, but not yet all that useful Microsoft Hohm and Google Energy, there needs to be a path for buildings as service providers. Understanding services in buildings requires understanding tenants, and their purposes. Perhaps Building Service Profiles link to the spaces in the light-weight BIM (GBXML) and therefore to the tenant services.

Energy profiles linked to the Building Service Profiles, then, become the links between Demand Response and graphical, tenant aware interfaces for building operations.

Last week, I received an announcement of a GBXML seminar in building design (http://www.gbxml.org/events.php). So far, efforts such as LEEDS have not yet delivered on the vision of sustainable energy-efficient high-performance buildings. The unhappy truth today is that most "green" buildings are poor energy performers within a couple years of delivery. Commissioning is a one-time act with no visible links to ongoing operations. Maybe using GBXML to both define the services of buildings and to operate/visualize their operations will not only enable stronger DR, but will lead to better every-day operations.

I am convinced that long term models for distributed energy, and for rapid innovations in energy use, come in this area. All the early incentives of DR, and the early visualizations of Google Energy and Hohm, are merely the tip of wedge for DER and smart energy in the end nodes. We need an interface between design, construction, operations, and smart energy. GBXML may be the most important enabler of net zero, near grid, and off-grid facilities. It may be what we need to apply the facilities capability management approaches pioneered by the Coast Guard to the policy-based net zero security and survivability of the NZ Army base.

I recommend that you check out the seminar on GBXML if you are interested in the real potential of smart energy.

body>

Small standards for small things

We were discussing standards upon which to build standards today. Before systems can communicate, there is a lot of work building the platform they communicate from. So much of the small work that will be needed for the internet of things is based upon constrained communications between resource-constrained devices. I found myself spitting out acronyms right and left – a veritable techno-glossolalia

There is a whole set of standards needed by the utilities to share billing information with a third party, such as Google Energy or Microsoft Hohm. The utilities are constrained by their mandate to make all services universally available. This means they are trying to accomplish the goals they call OpenADE (Automated Data Exchange) using only the equipment they already have in homes.

http://www.smartgridipedia.org/index.php/OpenADE_Charter

oBIX is a low level (the the extent REST or SOAP is ever low level) protocol for talking to control systems. oBIX was designed as an object-oriented model from which higher level objects could be created (a process that oBIX call defining contracts). Today, all contracts are proprietary, but the work plan has always anticipated standard contracts…standard contracts currently anticipated include include WS-Calendar scheduling, Energy Interoperation, and energy profiles. Non-energy related plans include binding for RSS and ATOM.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=obix

There is a suite of low-level pre-standards efforts to develop applications extremely constrained in resources and communications. They all seem to have names that are one-offs of 6LoWPAN (IPv6 over Low power Wireless Area Networks). Note: ZigBee pre-dates 6LoWPAN and is not entirely compatible with IPv6.

There is the compressed HTTP over PANs (CHOWPAN) recently submitted to the IETF.

http://ftp2.kr.vim.org/internet-drafts/draft-frank-6lowpan-chopan-00.txt

There is the Applications for 6LoWPAN work in the IETF, submitted by the Utilities

http://zachshelby.org/2009/07/07/6lowapp-embedded-application-protocols/

There is the new Service Discovery for 6LowApp submitted to the IETF by PGE.

http://tools.ietf.org/html/draft-sturek-6lowapp-servicediscovery-00

There is also considerable work done on discovery and profiles this summer in the OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) TC. This work is subtitled “Enabling secure Web service messaging, discovery, description, and eventing on resource-constrained endpoints” Note: while WS-DP defines how to communicate a profile, it does not actually define any particular profiles—for example, an energy profile could be communicated if we knew what an energy profile looked like.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-dd

One of the interesting aspects of this committee which had the major OS companies, the major enterprise management software companies, and the major printer companies represented, was that Schneider Electric was on board. Schneider representatives have stated that all of their switch-gear will support WS-DD and WS-DP eventually. Schneider contracted with a 3rd party to develop WS-DD and WS-DP for very small devices as an open source project. They used this project to assert (as all OASIS TC’s must) that they had successfully implemented WS-DD and WS-DP. This site can be found at the address below and downloaded under the BSD license.

https://forge.soa4d.org/

Hope this helps everyone keep caught up!