New Daedalus

I had a very nice conversation with Bob Smith of Tall Trees yesterday about building services. Bob is one of my co-conspirators launching the Building Service Performance ONTOLOG group. Bob had just submitted the laundry list of check-offs developed by the City of Irvine for its construction process to the ONTOLOG discussion.

I was both happy and disturbed to receive this document. These check-offs clearly drive the contracting process, They are also inherently backward looking, enshrining the best practices of yesterday as we move forward. The best practices of yesterday are better than the normal practices of today, but can be the enemy of better practices going forward. They trade innovation for good enough.

The ONTOLOG (just google it) project is to define an ontology of Building Service Performance. The problem we are trying to resolve is that while people want specific services from their buildings, we always specify technologies or systems, which is something quite different. Buildings may be providing alert students, productive office workers, or regulated environments to store labile chemicals. By discussing the services rather than the systems, we can

• Allow earlier discussion of / decisions on building goals in keeping with buildingSmart approaches
• Move conversations about building performance to the business level where commercial building owners will get interested (we want to provide healthy office space metrics in the upper quartile while staying within energy use goals).
• Commissioning then gets re-defined in terms of service performance effectiveness rather than in terms of system operations, a much more useful measurement.
• Commissioning numbers that look like B are simple enough to get built in to the sales and leasing processes for commercial buildings, enabling owners to monetize improved performance.

Check off lists such as Bob provided are the opposite of this approach. Nonetheless, I agreed to try to dig up two other documents that are contrary to the goals and thinking of the new group.

One such document is the original list of nearly 50 vertical control system markets that we came up with as oBIX was launching. These systems are specified in buildings now, but only rarely with any sort performance or business deliverable tied to them.

The other document I am trying to come up with is a comprehensive list of ICC (International Codes Council) domains. It struck us during conversation that many of the ICC areas deal with avoiding the failure to perform these services. While we are trying to twist these services around into a new ontology, a list of all the services which must not fail to be provided would be useful.

I have found neither list yet. If you think you have one, please send it along.

Peter Carbone, Vice President of SOA for Nortel, gave a nice high level talk on the challenges facing a company that grew up with rigid account control and vertical integration in a regulated environment learning to dance in the world of SOA and mash-ups. As markets for building systems are still characterized by rigid account control and vertical integration, and the power grid is still vertically integrated, regulated, and almost complete account control, there are some useful lessons.

Infrastructure convergence was the enabling and driving change for telecommunications. Provisioning telecommunications was long the most difficult task. Over the last decade, the diverse communication infrastructure converged to a single packet-based infrastructure with resulting dramatic simplification of security and reliability. The questions move from “What low level communications do you need” to “What interactive services do you need?”

This evolution changed how Nortel had to think about and market their services. Before the change, Nortel sold vertically integrated applications that were inflexible. As the core technologies converged, Nortel was forced to decompose advanced services into core functions and then plug them back into the new architecture.

Fortunately, decomposing integrated services into core functions looks a lot like defining a service for service oriented architecture. Fundamental telecommunications functions can now be built into enterprise applications without requiring exotic skills are deep domain knowledge.

Skills-based routing and deployment was one example. Peter discussed a SAP integration with critical system causing expensive downtime, emergency part ordering, and synchronizing communication with an outside expert so that the repair personnel, the piece of equipment, and, via telecommunications and real-time identification of the expert on call, the expert’s telepresence were synchronized.

In a similar vein, he discussed abstracting the GPS function from the cell phone to block access in the security system when the phone was in a forbidden zone. Peter gave many more examples and you can find his slides on the OASIS conference site.

So what can building systems and the power grid learn from this?

Well, the owners expect the systems to just run, and are annoyed whenever someone says words like BACnet or LON (or any other control protocol) in their presence. We need to decompose advanced services to discover the core functions, from the owner’s and the tenant’s perspective, and present them as interfaces that can be plugged back into the enterprise.

As Peter summed up the C-Level response: “I just spent $100 Million fixing my processes, you had better be compatible.”

Building services that can present themselves as that can interact with SAP, or with PeopleSoft will have an advantage. The services that know how to display themselves on Google Earth will know how to request the nearest technician.

Likewise, Grid requests that present themselves to ERP services will find faster acceptance. Grid requests that describe grid pricing as shapes that can be pinned to Google Earth will enable the enterprise to come up with multi-site responses that may be different from any single site.

No one cares about the old vertical applications. Enterprise interactions are everything.

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.

“Make everything as simple as possible, but not simpler.” -- Albert Einstein.

There is a recurring tendency to simplify complex systems in ways that will add complexity. Over the course of an evening with systems engineers, I have heard “Which one control protocol will we use? Will it be able to go all the way to the enterprise? When will all systems in a building be integrated into one system? How long before every sensor has an IP address?”

Metcalf’s law is misunderstood.“The value of a network goes up as the square of its nodes.” That is true for social networks. It is true for systems. It isn’t necessarily true for points. Too many points can actually reduce the value of a network.

On un-switched Ethernet networks, we used to manage what I called the cocktail party syndrome. Response would be nearly linear as you added nodes until the network reached a tipping point when response collapsed entirely. Packet collisions would increase. Re-transmittals would begin bouncing off re-transmittals. Like adding one more couple and one more bottle to a cocktail party, and suddenly you can hear the party from six blocks away—and effective communication is over for the evening.

Take that same network and split it in two, and communication throughput soars. Let half the party gather in the kitchen, and half in the living room, and the quality of conversation improves—Unless you divide the crowd wrong, and most conversation is between rooms. In that case, you made the problem worse.

The composition of partiers in each room of this cocktail party seem to break down on pretty traditional lines. There are exceptions, but they tend to prove the rule. In the same way, the traditional building system functions belong in different rooms. We need open communication between the rooms – but the intimacy of those communications should be socially defined and limited, both at the party and in building systems. These social constraints are the system interface.

Behind each interface, there should be one protocol. Inside that room, a domain expert should define the system, and make it performant. Even if the system in the other room happens to speak the same language, it should still be installed according the constraints of its own domain, and by its own domain expert. This simplifies the job, and the performance, and the warrantability of each building system.

The interface enforces the social rules. Some points may need to be protected. Some points may need to be interpreted, or combined, to be useful outside their domain. Those constraints make the society better…

And as most folks discover some time at their second college mixer, when some insist on violating that interface contract, and insisting on inappropriately intimate contact between the rooms….eeeeewwwww

A few years back, we passed around a list, and quickly came up with more than 40 different types of building control systems. It was a nice list, a comprehensive list – except it was not.

When I returned home, I shared the list with someone I worked with whose work I respected. The colleague worked in a part of the University that was called, at that time, Classroom Technologies. I described how we were going to come up with a way to interact with these systems. He glanced at the list for just a moment and said “But you left off what I do – AV and Event Management…”

A week later, another friend, who worked with systems at the hospital, and I were enjoying the late spring weather during an afternoon of malted beverages at the fine Chapel Hill old beer garden “He’s Not Here”. He asked if he could see the list, and right off said “Where’s Medical Gas Distribution?”

And so my education went.

Each of these control systems have a different mission. The primary service each can provide the enterprise is to defend its mission first, and to respond to requests second. Even when systems look alike, and use the same protocols, they may have different missions. Vents, fans, actuators, and ducts? It is either a HVAC or it is a Laboratory Fume Hood. Woe betide the person who flood the lab with poisonous gas because he thinks he is working on the former.

I think that control systems should be smaller. Too often they are as large as people can make them, based upon shared communication protocols. They need to be smaller, small enough to have a single mission. Then we need to make them perform that mission well.