Lifecycle Data Management and Information Integration

(This post was prepared during a FIATECH workshop on capital project priorities)

Do you find capital projects seem to ask the same questions again and again. Promises made in programming are lost in delivery. Contractors are unable to guess what the designers wanted. It can be hard to discover if you got what you asked for, and if everything works as promised. Do you wonder if your staff will be able to maintain a new facility in the right way, with the right parts, so you are unsure you will get full value from your investment?

Background:

A 2005 NIST study of the costs of poor interoperability estimated that $16 billion was lost each year in the capital industry.

Vision:

All information associated with the design, construction, and operation of a building is captured and maintained for the life of the asset. Standard interfaces let any authorized person access the information they need using the tool they want. All design information and choices are available to the contractor during construction. During building handover, the commissioning agent compares results to the goals and promises made during design. Maintenance personnel have direct access to all information they need for best results.

Challenges:

The most significant challenges are cultural and organizational rather than technical. Contracts must demand delivery and sharing of all information in existing standard formats. Business processes need to be recast to reflect new responsibilities and liabilities; contract language must be adjusted.

Benefits:

Eliminating the costs of re-creating data and improving operations through appropriate access to information will reduce costs of acquisition and preserve asset value. Common data formats will improve interoperability at every stage of the facility life-cycle, increasing accuracy. Interoperability will increase competition and drive innovation while increasing accountability.

www.fiatech.org

Information Stewardship

A design firm came on to campus the other day to begin conversations on the new School of Information and Library Science (SILS). Library Science has been one of the more interesting areas of IT in the last few years, as they are positioning themselves as the side of Information Technology (IT) not concerned with the bits and bytes, nor with the collection of data, but with delivery of information.

The Art of the Librarian has always been about the delivery of the right information in the right format at the right time. Google delivers vast amounts of references at your fingertips, each information set and document only a click away. Little Billy in the second grade asks the school Librarian for a book about frogs and his handed a book with lots of pictures and small words. Nine years later, William, now taking AP Biology, asks the school Librarian for a book about frogs and gets an entirely different set of volumes. Librarians know that context determines the correct information.

The design firm knows a little something about its audience, and they presented a pitch that the project use new approaches based information stewardship. New approaches can be a difficult sell to someone who has one chance once to build a building. Even so, it seems to me the Information Stewardship is a good line to take with Librarians.

Information Stewardship appears include keeping all design information on-line and electronically readable. All commissioning information will also be kept on line. Making a statement that speaks to me, the firm also asked that they have access to live operating data for at least a year, to make sure that the building delivers the energy and performance goals that are specified in the design.

This last point is particularly important. One of the worst failings of first generation LEEDS Green Buildings was their long term performance. Platinum building performance was never verified. Innovative designed were never adequately explained to maintenance and operations personnel. At last, that nettlesome vibration is solved putting a brick on the damper. At last, that noise in the duct is blocked by shoving a file cabinet in front of the oversized return. A year after delivery, the performance is poor.

Regular readers will recognize the goals of this project as being similar to those of the National Building Information Model Standard (NBIMS), now known as buildSmart. It is interesting that the design firm professed no awareness of NBIMS, and in particular, no awareness of the Common Operations Building Information Exchange (COBIE) which specifies the hand-off of information from design and construction to operations.

SILS has recently begun offering concentrations in Bioinformatics. There is some discussion about adding a concentration in Business Informatics. Perhaps, with the aid of Building Information Stewardship, we can begin the development of Building Informatics. If so, this could be the missing piece in developing the abstractions needed to develop truly responsive buildings for the transacted energy grid.

Is anyone else as confused as I about the differences between Informatics, Infomatics, and Analytics? They seem to be used interchangeably, but in different conversations. Please post if you can define the distinctions.

XML is not enough to create an Enterprise Interface

On the NBIMS list yesterday, Louis Hecht with the Open Geospatial Consortium (OGC) observed:

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.

And he was exactly right. Bad XML Schemas, and perhaps most first generation XML schemas do not provide semantics. Good XML schemas implement semantics, bad ones do not. For an example, within the Building 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.

The larger point is true. XML and XML schema do not inherently include semantics - but 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. Our next challenge is to figure out how oBIX accepts an ICAL invitation to make the building system "occupant aware".

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.

It is still my plan that as I become more familiar with NBIMS, I will be able to discover the Semantics I need 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.

Got an idea on how we can bring semantics  to building systems XML  - please post a comment...

Hospitals and Control Systems Data

Of late, I have been so interested in the Grid, that I have forgotten the internal enterprise and the use it can make of information from embedded systems. Recently I fielded a question on hospital recordkeeping, refrigerators, and TJC (The Joint Commission) compliance.

There are refrigerators dispersed throughout every hospital that store medication, research samples, lab cultures, et al. To maintain their TJC certification, hospitals must monitor and record the refrigerator temperatures. Today, many have a manual process of reading and recording this information, followed by log consolidation and other potentially manual processes. The question concerned how to best support this process.

My answer follows.

Embedded control systems are inside each of the embedded systems you name. Access to the information within these systems is, alas, non-standard and quirky. Even if you can get the reading from a particular sensor, it is likely to be non-qualified and non-abstract. Those are fancy words to say that you may be asking a temperature sensor and getting the answer back in millivolts. Even getting that answer is hard, because the protocols used inside the systems do not look like anything that your IT folks have seen before.

There is a new standard, now in early adoption, for getting to the information in controls systems. oBIX (open building information exchange) is a web services based protocol developed within OASIS ( www.oasis-open.org ), meaning within a business communications group rather than within a controls manufacturers group. Several manufacturers are in early testing of there oBIX gateways to underlying controls systems. I am using 70 such gateways to get to building operation information right now.

What is good about web services is that they are open and accessible. They do not require that you be an engineer in the control room to get to information. I have seen Excel spreadsheets using only out of the box software polling a web service periodically and automatically adding another row of data.

If you work in hospitals, you may have run across HAVE (Hospital Availability Exchange) standard. HAVE lets, say, emergency medical responders poll nearby hospitals operators for the shortest wait time for critical diagnostic equipment. Because the HAVE standard includes no patient or procedure oriented information, it cannot put HIPAA sensitive information in play – only wait times and resource availability.

For implementation today, you should rely on someone else’s advice. But for mid term planning, look to service oriented architectures based upon abstract surfaces expressed as web services.

Full disclosure here – I am co-chair of the oBIX committee. Some in ASHRAE would passionately defend BACnet-WS as the architecture of choice. That discussion is a long and nuanced one that I will spare you. But *I* say, starting asking your suppliers about oBIX.