Schedule & Commissioning and the Future of LEED

As Chair of WS-Calendar, I receive a number of inquiries about the incorporation of time and schedule into other specifications. In particular, the wider visibility of VAVAILABILITY is attracting some interest. Occasionally these include fragments of xml, and inquiries as to how to apply this information.

WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.

NREL has recently released a report recommending tagging standards for building systems. This tagging standard is part of a larger recommendation on proper commissioning standards. The same report (http://www.nrel.gov/docs/fy11osti/50073.pdf) posits that a properly commissioned building system interface be able to offer up a light-weight building model, linked to these standard tags. This creates standard semantics for the building system as a minimum commissioning requirement for a future version of LEED.

Continuous commissioning is today limited by a market friction between changing the service provider. Initial set-up costs require analyzing the building system tags, reviewing the [paper] plans, and interpreting the variations between design and as-built drawings. A properly commissioned building should have resolved these issues already in ways that are re-useable by others. There is a growing sense that buildings should continuously update these energy models to maintain LEED certification.

Energy models predict energy use, and building systems are responsible for the energy use in buildings; these systems typically do not change much after commissioning. A changing energy models is caused most often by a change in business practices. Live energy models must be mappable to changing occupant business practices.

Business processes, though, are primarily linked to spaces, not to the systems. Some systems, i.e., food service equipment, may be linked directly to the business process; it may be that even these processes are stated most clearly through space use schedules. In a building with dynamic management of business processes, the energy models may need to be just as dynamic.

My work in communications for smart energy is concerned with communicating the volatility of energy supply and demand with prices. Facilities that understand their energy use will be able to control economic risk through committing advance purchases of energy on a schedule.

Operational scheduling of building systems in BIM promises to refine our understanding of energy use throughout the day. Linking building spaces to building systems will link energy use to business processes. Continuous commissioning makes energy models relevant throughout the life cycle of a building. Smart energy will create new value propositions for those who understand the schedules when they will use energy.

Operational BIM Schedules and Pre-Design Programming

As Chair of WS-Calendar, I receive a number of inquiries about the incorporation of time and schedule into other specifications. In particular, the wider visibility of VAVAILABILITY is attracting some interest. Occasionally these include fragments of xml, and inquiries as to how to apply this information.

WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.

Facility Programming is an important early step in step in the Integrated Design Process. Programming is defined in the Whole Building Design Guidelines (WBDG) as “the research and decision-making process that identifies the scope of work to be designed.” Programming is the first part of the design cycle, during which systems and space requirements are identified by the activities they will support. If the design process is compliant with the formal BIM process (BuildingSmart, NBIMS, etc.), then these systems and spaces are identified as described in the IFCs.

BIM is a collection of information sets and models with identified interfaces / information exchanges between them. A model that is of growing interest is the building’s energy model, which is today derived from a combination of structural and purpose models and [normally] a side questionnaire about the building’s use.

I have recently received early sketches (XML Fragments) of programming documents from Dr. Chris Bogen (Engineering Research and Development Center) in which building services and systems, as expressed in open buildingSMART model format, are included in vavailability to express, for example, the operating schedules of systems supporting dining facilities (and their energy requirements). The ERDC project is aiming toward the development of a format that can be used to compare the expected resource use of a facility during design and express the actual resource use identified through analysis of building sensor systems. With the additional pattern detection algorithms under development at the lab, ERDC expects to have a tool that will compare building use to identify when the use of a building doesn’t match it’s design prediction. The ultimate goal of this work is to create building simulators directly from data provided during traditional design and construction processes.

Over time, many buildings are found to have different energy use profiles then their models predict. Often this is due to changes in operating schedules from that which was predicted. We are beginning to see mandates to update these energy models to match actual results, particularly in government owned or funded facilities.

Lifetime maintenance and updating of these programming documents, including changing the operations schedules, establishes a baseline to compare predicted vs. actual use, and to thereby sooner to detect anomalies due to system degradation or misconfiguration.

An advantage of potential automated modeling within incorporated vavailability, is that schedules can easily be understood and manipulated by building operators/occupants. Once an energy model is in-place, it would be straight-forward to iteratively try out different systems schedules and examine different energy profiles. As we move to dynamic markets, the capability to project different times of use and compare those to projected energy prices might become a new source of value to building operators.

Converging with the Internet of Things

Service integration is coming to the world of Calendars. Calendars are coming to the Internet of Things. These two trends have the potential to open up whole new classes of easy integration in buildings and in personal devices. This integration got its initial acceleration from the needs of smart energy. The long term reach, though, is much farther.

Traditional e-calendars are store, copy, and forward messages. There are five copies of a meeting for five people. Changing a meeting time requires finding and updating those five messages. This is easy if the messages are on a small office LAN on one server. It poses some daunting problems if those messages are spread over two corporate servers, Gmail, a stand-alone PC, and a cell phones. If 50 are attending that meeting, things can get complex. If it is a community schedule, with 5,000 subscribers, it is almost impossible to support the diversity of clients.

Jon Udell (http://blog.jonudell.net/) has long advocated distributed calendars for communities, encouraging people and organizations to be the authoritative sources for their schedules instead of sending a flurry of messages that may soon be out of date. (If you are interested, read all you can on the ElmCity Project.) Jon’s blog introduced me to Mark Surman and the phrase “cities that think like the web” (http://commonspace.wordpress.com/). When we apply these approaches to Smart Energy, we may get “grids that think like the web.”

The way that WS-Calendar has developed since Thanksgiving makes this all easier. Standard REST and SOAP services for calendar communications reduce the barriers to distributed community calendaring. Mike Douglas is testing his SOAP concepts to synchronize dissimilar calendar servers (Exchange and BedeWorks). Community Calendars are about to get much easier to implement.

WS-Calendar, though, was created to support smart energy. Schedules and events for energy shortage and surplus, communicated along with volatile prices.

There is a long history of simple calendar communications for small devices. Older cell phones interacted with iCalendar communications despite extreme resource constraints. Open source and silicon already exists for simple calendar processing. When these services get reduced chips that we can afford to put everywhere some interesting things happen.

Consider a Calendar Service on your smart thermostat. Add a community calendar server to your house. Maybe it’s on the magnetized thin film computer stuck to the front of the refrigerator. Maybe it’s on your wireless router. The home community calendar shares schedule services with the Dad’s Android, with Mom’s Blackberry, and with the Kids iPhones. Maybe, following the Elm City model, the house calendar subscribes to the high school community server, and that of the church as well. The electric car will need this kind of information, and can create charging schedules that are themselves shared. Messages about schedule electricity shortage and abundance come through the Energy Services Interface (ESI).

Then we would have a smart thermostat that thinks like the web, in a house that thinks like the web.

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 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.