Getting excited about FIATECH next week.

While I have attended a FIATECH charrette and teleconference or two, I am looking forward to my first FIATECH Conference down in New Orleans next week. It was very tempting to place the oBIX development process as a FIATECH project a few years back. In the end, we decided that it was more important to place oBIX among the e-commerce standards at OASIS, but I have long had a solid appreciation for the vision in the capital projects technology roadmap.

Several of the FIATECH projects are this year coming out of the woodwork after a quiet period. This is normal for new technologies and methods. Initial excitement is followed by disillusionment, which is followed by actual use.

A speaker observed last year at an OASIS conference that those of us who understand Service Oriented Architecture (SOA) should hunker down for a few years of abuse. Vendors have oversold products that may have a few symptoms of the approach, but substitute products and slogans for the hard work of thinking about the business. (Pretty much any product that includes the phrase “Enterprise Service Bus” fits this description.) The speaker went on to observe that the season of disillusionment was at hand.

Several FIATECH initiatives have gone through this cycle. FIATECH is now one of the main loci for ISO 15926 efforts. ISO 15926 started life as "Industrial automation systems and integration—Integration of life-cycle data for process plants including oil and gas production facilities" This work slowed when half done, only to be revived as a FIATECH project. There it has developed a generic data model and Reference Data Library for process plants, and has become the most compelling standard for modeling any state information. We have discussed within oBIX whether we can adopt some of the ISO 15926, now considered a general purpose standard for data integration, sharing, exchange, and hand-over between computer systems. I am looking forward to learning more about ISO 15926 this week.

By most accounts, BIM (Building Information Modeling) has also served its years in the wilderness, and come out of the crucible as buildingSmart. FIATECH remains one of the best forums to discuss real life BIM experiences across a wide range of construction activities.

This year, with FIATECH meeting in New Orleans, Kimon Onuma is launching BIMStorm New Orleans. I very much hope that he can carve out a little time to talk to me. His planning system provides an astonishing nexus for live data exchange between tools and purposes of BIM related information. When I look at OPS, however, I see a tool just as interesting for operating a building, for pulling modeled information out of building systems to produce building dashboards. I also see the potential for an integrated operations repository, particularly useful with outsourced maintenance and analytics.

I recently accepted a request to become co-champion of Element 5 of FIATECH’s Capital Projects Roadmap. Element 5 is titled Intelligent, Self-Maintaining and Repairing Operational Facilities. I will be presenting a talk aligned with that entitled “The Enterprise-Responsive Facility”

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?

Beyond Efficiency, Beyond Sustainability

Regular readers know that sustainable buildings are not sustainable unless their inhabitants are willing to continue using their features. Nothing is less sustainable than the feature that is uncomfortable, or awkward to use. For the owner of commercial buildings, the desired amenities are ones that reduce costs, or extend asset life while reducing tenant inconvenience.

Building Systems that support agile integration open up realms of integration for everyday use. These functions have been available, at great expense, for those who absolutely required them. Others have been adopted by those are simply driven, like the energy strategies used by those who live off the grid. These functions, and the amenities they offer, will make the the operating efficiencies they also provide sustainable.

So what kinds of new abilities will real sustainable buildings offer? Access to information will allow all service providers to improve operating efficiencies and to offer new and enhanced services. Whether the service providers be life safety related or task (contract) related, operating efficiencies allows improved use of resources while reducing risk and liability. Below are some benefits that intelligent, agile integration will offer to building operators:

• Knowledge Systems for Autonomous Maintenance –Intelligent systems able to determine and communicate maintenance and repair needs based on defined requirements (e.g., reliability predictions/calculations) vs. measured performance and sensed and assessed condition.
• Automation Technologies for Life-Limiting Factors - Able to detect, assess, and repair materials, structures, equipment, and systems affected by corrosion, fatigue, breakage, stress, and other life-limiting factors.
• Automation Technologies for Critical Performance Factors - Able to detect, assess, and repair materials, structures, equipment, and systems with respect to safety, security, health, and environmental issues.
• Facility Condition Knowledge Base & Baseline - Real-time human and machine access, both locally and remotely, to as-built/installed configurations, maintenance/repair history, and material/equipment life predictions.
• Uniform Equipment/Process Information Standards - Digital documentation and sharing of data on material and equipment properties and characteristics (including simulation models) and O&M best practices.
• Sharable Standard Equipment/Process Models - Mathematically accurate 3-D simulation and performance models for all forms of material and equipment, such that vendor-provided models can be "plugged together" into the master facility simulation model.
• Facility O&M Advisory System - Intelligent advisory systems able to process status information from all facility sensors and systems in real time and make optimum recommendations for proactive and corrective actions (including emergency response) and which is able to implement the desired actions through automated command and control systems and through communication with O&M personnel.
• Integrated Safety/Security Systems - Continuous monitoring for safety/security hazards and threats from personnel, equipment, and materials and provide automated tracking and alerting capability when a hazard is detected or suspected.
• Facility O&M Systems Integration – Connection of the facility O&M system to higher-level enterprise management systems, enabling passing of status and activity information to enterprise functions such as business planning, labor allocation, resupply, and other site support functions.
• Enterprise O&M Systems Integration –Connection of the facility O&M system to customers, equipment/material suppliers/manufacturers, and automated design advisory systems, including the feedback of maintenance/repair results/data to the master facility simulation model.
• Enterprise Control Model Linkages - Feedback of maintenance and repair results and data to process-level, facility-level, and enterprise-level knowledge systems, enabling visibility of performance and issues, real-time updating of operational control models, and extension of the planning and design knowledge bases.
• Shared O&M Knowledge Bases - Accessible databases of maintenance and repair experience for different kinds of capital projects/facilities, enabling the sharing of expertise across the industry with appropriate provisions for anonymity, security, and intellectual property protection.

These higher order activities require common building semantics (naming of things) BuildingSmart looks to be the only game in town for capital asset semantics. These semantics will unify the information coming from the sensors below into objects intelligible to the building owner.

WS-Are-We-There-Yet

We now have web services to almost any conceivable control system. We have BACnet-XML and BACREST. We have TAC Web Services. We have LON XML. We have oBIX. So...are we there yet?

As Louis Hecht has written:

XML does not provide semantics. XML does not solve business problems. XML Schemas do not provide semantics or solve business problems. XML, by itself, does not solve interoperability problems, yet it is an important tool for doing so.

This is true, to a point. Bad XML Schema, and perhaps most first generation XML schemas do not provide semantics. Good XML schemas implement semantics, bad ones do not. For an example form within this space, I would argue the GBXML provides semantics. Even oBIX 1.0, frustrating to me, offers semantics, but one limited to points services and therefore not readily accessible to business functions. Establishing base semantics was a critical early goal of that project.

Good XML Schemas are all about semantics, for without semantics there is no interoperability. I would refer to something like UBL (Universal Business Language) as an overarching semantic framework that is being built into numerous schemas at a deep level.

Louis’s larger point is true. XML and XML schema do not inherently include semantics—even if the good schema do.

One of the reasons that I am watching NBIMS so closely from the oBIX vantage point is that the higher semantics will need to be there before oBIX has an enterprise interface. I have a hard time imagining what applying Policy to point services even means.

As Enterprise programmers will never be control engineers, we are going to have to wrap up the standard functions into business services. In oBIX if I define a set of functionalities for a given period of time, it is called a contract. For these to be useful, we will need to pre-define several contracts and make each of them discoverable. Discovery will mean that we need to describe each one in terms of the service it provides. The Description/Catalogue will need to be machine readable rather than human readable, which means it will be based on Semantics.

But whose semantics?

I am hoping we can find a way to map Design Intents / Systems modeled by the energy model / spaces served into Service descriptions. It would make sense, then, to invite the control system's Service to the same meeting. To do that, to make a Service that can be subject to Policy, that can have rational Security applied, that can be Discovered by enterprise applications will require that we have Semantics embedded in the XML of the Service Descriptions.

I believe that as we all become more familiar with NBIMS, we will be able to discover the Semantics needed to do this. Somewhere in the check list of Services to be Commissioned, in the Systems in the Energy Model, and even in the Function analyzed by the Code Compliance checker are the Semantics needed to create discoverable abstract services.

And that XML will be an order of magnitude more useful because it is semantically laden.