Looking Ahead: The Self Maintaining, Self Repairing Facility

So how do building systems fit together in the future? I have some pretty solid ideas about what it will look like, but it is hard to project the time sequence, or the time scale. Here’s what I see.

Building designers will come to recognize the importance of data stewardship. Building systems will deliver information back to the designers and owners on actual building performance. This information will guide future programming, design, construction, and operations. Similar informational interfaces will support the business and regulatory environment of the building.

Buildings will be designed and constructed to be an integrated system of intelligent systems. These intelligent systems will use the information from self monitoring equipment and systems to continuously optimize conditions and performance. Intelligent buildings will actively support business operations. Facilities owners, operators, and service providers will all be able to access the same systems information in real time. They will use this information to respond to changes in business and environmental requirements to ensure that the facility will continue to support each intended use, old or new.

Each building system will stand alone yet interact with others as the higher level of a business service. Each system will gather data from its sensors and manage its actuators to support and defend the service it provides. Each building system will hide its internal operations, exposing accurate actionable information for continuous decision support.

Within each class of service, systems will compete to deliver the most economical or highest quality service through standards based interfaces. Each system will analyze its own operations to flag problems and make recommendations for external intervention. Each system will share information transparently with other systems, without requiring deep integration with other systems. Building owners will take advantage of informational interoperability to select systems based upon the quality of information and of the underlying operations without regard to the specific technologies used within each system.

Resilient systems of systems will ensure optimal facility utilization and operation even during crises. Each systems will attain situation awareness through communications with its peer systems and with systems external to the building. Examples of external communications include weather stations, demand/response requests from the power company, and emergency (CAP) alerts from homeland security.

One mission of each system in the buildings is to support the effective and efficient performance of the business functions within that facility. The facilities operations of an intelligent building are energy efficient, environmentally correct, and sustainable while leaving a minimal [carbon] footprint.

Building systems will interact to requests in support of business operations and tenants using communications protocols and interaction patterns familiar to enterprise programmers. Because each system defends its mission and exposes only informational interfaces, these interactions will be safe and secure.

Facilities operations will define system performance by the provision of business services, not the operations of process and inputs. Examples of business systems expressed as services include healthful work environment, alert students, regulatory compliance and system metrics will align themselves with these measures. Landlords offering such services will experience lower vacancies and be able to charge higher rents as they are able to document the Quality of Services (QOS) they offer.

Informational Interoperability

Power grid reliability, human heat pumps, and data centers as energy resources – what is the common thread? All of these rely on being to get above the details of the systems to see interrelationships between the systems. This approach requires systems to compete on delivering of service, rather than focusing on process. Systems that provide a similar service, albeit with fundamentally different internal processes, must be swappable.

We must move beyond protocol interoperability to informational interoperability.

In engineered systems, interoperability usually means “we can get some signal of some kind between systems”. That signal is data oriented, meaning it is a raw fact that is neither actionable nor useful on its own. Someone with deep domain knowledge program the interactions around those facts. This leads to over-integration between systems.

Informational interoperability raises the bar, by allowing systems to compete on performance and service. Data is not information; often too much data can hide information. Only when facts from the underlying process are assembled into patterns that have meaning and can influence action does data rise to the level of information.

If you have two or more systems that can both consume and produce the same information interface, then those systems are informationally interoperable. If several external systems share the same informational interface to the local system while performing different services, then the local systems interface is reusable.

If I am performing an energy intensive task such as intake reheating, it matters little if my heat source is electric coils, a central steam plant, a solar thermal collector, or the data center downstairs. Each has a cost (which may even be negative), each has a quality, and each has performance characteristics. Systems with informational interfaces can select or which thermal source to use, either at design time or on the fly. Such systems would not need to know any details about the internal operations of their design source.

The best system interactions are built using reusable informational interfaces. The most accepted and best understood reusable informational interface is money. Money provides actionable information about scarcity and value. Monetary interfaces are highly re-useable and interoperable.

Bad systems hide information about performance, scarcity, and value; good systems expose such information in ways that allow innovators to take advantage of this information. Let the systems use whatever low-level protocols they want internally. On the outside, we need information interoperability.

Thinking about Thinking about Turkey Point

Last week five power plants in Florida went off line following a problem in a substation. Active discussion ensued in the blogosphere. One of the first headlines was “Terrorist attack not suspected in plant failures” One of the first comments I saw was on the lines of “Great. Now the IT guys will all come on-line and tell us how we should have done it”.

I’m not going to do that. I have nothing useful to say on the design of any power plants, let alone nuclear plants. All systems were performing as designed. In the belts and suspenders world of nuclear plants, the entire grid is one of the redundant power sources for the cooling systems. The plants were supposed to shut down one of the safety systems lost redundancy. What we saw in Florida was carefully designed systems doing what they were designed to do. If every one of my ideas were fully implemented in the grid, in the building systems, and in building design, these plants would, and should, still have shut down.

If the grid as a whole were re-built as interoperable services with economic interfaces (prices), the blackouts in Florida would not have been as far reaching in their effects. The service oriented grid will enable an ecosystem of local reliability and storage. That ecosystem will support innovation and technology diversity at the distribution and building level. (Note: In power, transmission refers to the long distance transport of energy, the high voltage towers marching to the horizon; distribution refers the lower voltage movement of power around neighborhoods). That market will create islands of reliability wherever it is worthwhile.

The key element is informational interoperability. In engineered systems, interoperability usually means “we can get some signal of some kind between systems”. That signal is data oriented, meaning it is a raw fact that is neither actionable nor useful on its own. Someone with deep domain knowledge program the interactions around those facts. This leads to over-integration between systems.

Very good systematic thinkers tend to extend their systems beyond the domain in which they are skilled. Power engineers tend to build a single giant robot covering continent-sized territories. Faced with the diversity forced upon it by scale, this robot becomes more and more brittle. The only response within the paradigm is for the engineer to become more and more controlling, which ameliorates the systems but makes the long-term problem worse.

Bad systems interfaces hide information about scarcity and value; good systems expose such information. Power systems hide information about scarcity, value, and reliability in systems without interfaces. Utility regulators simplify system interfaces to support historical practice rather than innovation.

The best system interactions are defined around reusable informational interfaces. The most accepted and best understood reusable informational interface is money. Money provides actionable information about scarcity and value. Monetary interfaces are highly re-useable and interoperable.

If we had good informationally interoperable interfaces including a substantial monetary component between each system in the power grid, the plants at Turkey Point would still have shut down. They are well designed systems engineered for safety and long-term reliability. What would be different is that their customers would not rely solely on the fragile power robot. What would change are the local markets in reliability that would spring up. Local markets would let new classes of innovators seek profits in providing new value.

Fitting controls into buildingSmart

I have long wondered how we are going to bring building control systems into the wider world. How are we going to use energy models to instrument actual building performance? How are we going to provide the confusing mass of sensors and actuators as surface that is meaningful to Enterprise systems and functions?

I have long favored buildingSmart as a source of the structure and meaning (or semantics as we call them in dweeb-speak). BuildingSmart is the National Building Information Model Standard (NBIMS) rebranded to be more user friendly and international in scope. Building Information Models (BIMs) are data models to track all information about the design, construction, acquisition, and operation of a building. A good BIM starts with the earliest design intents and continues through the final destruction of the building.

I have long known that the fundamental glue of NBIMS is the IDM. Until today, I had no good idea what an IDM was, or how I might go about constructing one for a control system.

It was clear that fitting building controls into BIM would complete many parts of the model while lending coherence to and standard descriptions to control systems. BIM defines energy models during design, models that are not much use during operations. BIM describes assets and provides a framework for defining the interaction between those assets. This sounds quite close to defining the surfaces used in Service Oriented Architecture (SOA).

Today, Dianne Davis, NBIM IDM Technical Chair from AEC InfoSystems was gracious enough to make things clearer for me. IDM stands for Information Delivery Manual. The IDM is a plain English description of the information exchanges needed between two adjacent systems. In buildingSmart, there is an IDM for the exchange between design intents and massing studies, and between massing studies and structural design, and so on.

An IDM for building systems could be added in to the BIM very early on, perhaps right after massing. “I need 3,000 sf of animal quarters which will considered regulated space. The rules for regulated space are that the temperature, humidity, and ventilation be at a defined level, and that information be tracked and reported at an interval not to exceed a certain time. The regulated space requirements for Animal Quarters must meet standard A, while the regulated space requirements for stogie of labile chemicals (such as drug storage) must meet standard B” This approach defines the performance standard required of systems based upon the programmed use of space at a very early stage.

When expressed like this, IDM standards become significant information for energy models. Both standards above, for animal quarters and for drug storage hare similar in that they may have requirements that temperature and humidity be kept in tight, albeit different, ranges. The animal quarters, however, have quite different ventilation requirements, and thereby a different energy cost.

The same IDM defines the performance standards to be tested during commissioning. It should be straightforward to add this IDM information to the COBIE (Common Operations Building Information Exchange) commissioning information. COBIE is that portion of buildingSmart that defines the handover at the end of construction of building information to operations. COBIE also includes a framework for tying commissioning reports to the underlying systems from the design.

It is easy to imagine that an IDM standard for building systems becomes the basis for bidding and construction as well. It is not hard to imagine that IDMs could be defined for each of the 48 types of systems in the original list of vertical markets compiled at the founding of oBIX, whether Intrusion Detection or Medical Gas Distribution.

Who is willing to help me define IDMs for building systems so controls can find a home in the BIM?