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.