BSI Part 1: What is the Building System Interface?
After the ASHRAE meetings, and during the AHR conference, several of us are getting together to discuss building system metadata. The goal is to define interfaces to support quick fast integrations of building systems into the wider world. This is the first of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.
In my smart grid work, I began describing each end node as a microgrid. A microgrid is a self-contained entity responsible for managing its own energy use, generation, storage, conversion, and as a last resort, market operations. This model eliminates...
After the ASHRAE meetings, and during the AHR conference, several of us are getting together to discuss building system metadata. The goal is to define interfaces to support quick fast integrations of building systems into the wider world. This is the first of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.
In my smart grid work, I began describing each end node as a microgrid. A microgrid is a self-contained entity responsible for managing its own energy use, generation, storage, conversion, and as a last resort, market operations. This model eliminates direct grid control of buildings. Maximum grid incentives, all delivered to a single energy services interface (ESI), the locus of market bidding for the building.
The ESI is the external face of the participants in smart energy. The ESI facilitates the communications among the entities that produce and distribute electricity and the entities that manage the consumption of electricity. An ESI may be in front of one system or several, one building or several, or even in front of a microgrid. In keeping with service integration principles, there is no direct interaction across the ESI.
Today, an ESI is most often on the outside of a building system. The leaders in commercial energy management, companies like Target, put the business between the ESI and the building systems. Target evaluates energy use, and changes in energy use as normal business decisions, and building systems respond to business operations. Target though, is unusually aware of its decision processes, has many nearly identical buildings, and has strict commissioning standards. For the rest of us to be like Target, we need a Building Systems Interface (BSI).
The BSI must expose several services. New systems will certainly incorporate the market-oriented interfaces of smart energy, for use inside the building microgrid. Other services will interact with the business, linking corporate calendars to building operations. Another will request and consume weather information; if nothing else, a data center should take advantage of a cold winter such as this to limit cooling loads.
Systems must tie their information to the space that the enterprise inhabits. It is not enough for points to self-describe themselves as an air handler—that air handler must describe itself in terms of the service it provides to a particular space. Space is what the building systems support, space is what the tenants recognize.
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.
Even live-load, or plug-load, must be able to describe itself in relation to space. Panel sub-metering and BIM-based circuit tracing (PLie – panel layout information exchange) put even the coffee pot and copier as part of the BIM model for energy use. Even home appliances must be participants.
Understanding Inheritance in WS-Calendar
Traditional service communications have assumed near real time response. Traditional schedule ahead markets have been similar to the informally communicated “allow two weeks for shipping”. Smart energy markets demand we do better, scheduling delivery of services, now and in the future, within 15 minute windows or even within 4 second intervals. Prices, and delivery and consumption will all swing every hour of every day. Real opportunities will arise for those who can help the consumer in the home or commercial property buy low, sell high, and buffer their internal needs in between.
This requires clear communication of time and schedule...
Traditional service communications have assumed near real time response. Traditional schedule ahead markets have been similar to the informally communicated “allow two weeks for shipping”. Smart energy markets demand we do better, scheduling delivery of services, now and in the future, within 15 minute windows or even within 4 second intervals. Prices, and delivery and consumption will all swing every hour of every day. Real opportunities will arise for those who can help the consumer in the home or commercial property buy low, sell high, and buffer their internal needs in between.
This requires clear communication of time and schedule, whether we are talking price, or product, or service. WS-Calendar is a new specification that will be at the center of new market communications. WS-Calendar extends enterprise standards used for personal and business schedules to service communications and markets. WS-Calendar defines the Interval, and relationships between Intervals to create the Sequence. The power of WS-Calendar comes from remotely referencing Sequences and in influencing Sequences that are incomplete to define actionable services.
Sequences are composed of intervals for which a set of temporal relations have been defined. ICalendar has long defined relationships between calendar components, intervals are just another calendar component. In WS-Calendar, we reference a sequence by defining a “parent” relationship with any single interval in the sequence. We refer to the interval within a sequence that has this relationship as the Designated Interval.
Wherever there is “missing” information in the Designated Interval, it can be inherited is inherited from the referring component; we use the “parent” relationship to reference the designated interval. These references may be local or remote. Some, but not all, of the information can be inherited by the other intervals in the sequence. Adding additional references can further specify information in the sequence through inheritance; these additional references created by specifying an additional component that has a parent relation to the previous referring component. In this way, we can create a grand-parent and a great grand-parent.
Each parent bequeaths information to its child. A child inherits this information in accord with the inheritance rules. If the child is itself a parent, it bequeaths its information, the bound result of its internal information and its inheritance, to its child. Information to complete the specification of a sequence flows in this way from parent to child, from the outer reference to the inner sequence.
Inheritance by the designated interval is governed by slightly different inheritance rules than the other intervals in the sequence. In particular, only the designated interval can inherit the start date and time from its parent. The starting date and times if other intervals in a sequence are computed using the temporal relationships within the sequence. Other information can be inherited by all intervals in a sequence. Other specifications that incorporate WS-Calendar must define how inheritnace will work with their payloads.
The referring components are called Gluons. In physics, gluons are particles that affect the exchanges of force between quarks, but are not themselves quarks. By analogy, WS-Calendar Gluons affect the referencing and binding of intervals in a sequence, but are not themselves intervals or part of sequences. Because intervals can inherit almost any property from a Gluon, Gluons must contain most of the same information elements as Intervals. Because Intervals can contain information payloads for specifications that use WS-Calendar, and these payloads can inherit information from gluons in the same way intervals do, Gluons must be able to contain information payloads from those specifications as well.
Gluons are essentially pretty simple. They can be incorporated as part of a larger communication, whether e-commerce or building controls (oBIX). This gluon can invoke a sequence, or modify it, or both with a single call.
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
I like a Winter Morning
I like waking up warm, under the covers in a cold room. When the kids were younger, I had to leap out of bed at the alarm, and walk the dogs, and make breakfasts, and pack lunches, and get the kids out the door, like a paratrooper sergeant shouting “Go!. Go!,Go!”. Now a can lie in bed and revel in the warmth, and let WCPE (Great Classical Music 24 hours a day) ease me awake. Today, for the first day of winter, the Waltz of the Snowflakes at 5:30 was as good a background for a joyful awakening as one could hope for.
Rusty is old, and slow, and no longer chases into the next county. He stays close in the dark, even as the herds of deer, meticulously eating the buds off my camellias chuff their startlement and prance off into the dark. The cold air keeps smells down, and they are as startled as I when I come on them in the dark. From the bottom of the hill, it’s a half mile to the old store, and the morning paper.
The guinea fowl are in a tree off the road, calling quietly to each other in their cold weather voices. By summer, they are outraged, and angry, shouting their annoyance at all who pass near. But in dark winter, they are quiet, perhaps they do not know I am about. Perhaps they are calling to sooth each other, back and forth like night hikers on the glacier, awed by the silent dark, but keeping an eye on each other.
Up ahead are the brightest Christmas houses, right across from each other. On one side, the Hispanic family has moved in, and dedicated a passion to Christmas lights that I remember from growing up in San Diego. I remember in 1969, San Diego’s 200th, when we were asked to keep our lights up all year. The town’s colors are Brown and Gold, and the call went out to change all the Christmas colors to yellow after Christmas. Changing light bulbs is not as easy when they are up as when they are on the floor. I seem to remember that my mother kept me in the tall carob trees on either side of the driveway for all of January, two sacks of tiny bulbs in my hands.
On the other side of the street is the solar power house. They always offer me light on my morning walk, as self-powered driveway lights create an aura around the Clyde Jones chainsaw sculptures. But with Christmas, they have thrown all caution, and perhaps solar power to the wind and the sculptures are awash in tiny lights. Perhaps they are leaders in using the early morning energy surplus; but I think it is the Joy of lighting for Christmas.
From there on, it is lights all the way to the store, a lot of purple this year. The road is silent, with no one else about. Even the dogs are all inside on these cold nights. Rusty and I have the walk alone, with the dear, and the fowl, and the lights. Any colder, and it might be too much of a good thing. The full moon was getting ready to hide for the day.
I like a winter morning.
New Daedalus
Daedalus designed buildings, automated statues, and built wings for human flight. Daedalus worked by eye and hand, his designs scratched with a stylus on wax tablets. Until recently, we merely perfected his means of work, using better pens, and paper, and finally drawing on computers.
It is only recently that we have begun to leave the methods of Daedalus behind.
Simulations and digital twins guide each decision. Intelligence, or at least behaviors, imbue each system and device. Cyberphysical systems replace household servants and chauffeurs, operate factories, and manage energy logistics. The most pressing concerns are how intelligent systems and buildings will respond to us, and to each other.