Still Waiting. . .

I began considering the implications of SOAP for Building Controls since the summer of 2000, when I killed some time (so I thought) at a conference by sitting in on a talk by Don Box, chair of the SOAP committee, presenting what was then version 0.9 of the standard.  It was clear at that time that SOAP was going to be the means for integration and coordination of services across virtual enterprises comprised of hundreds of corporations.

What really opened my eyes, though, was the guy sitting next to me.  As we chatted during breaks, he described himself as a chief software engineer for a manufacturer of UPnP (Universal Plug and Play) chipsets, something that if I recall properly, he was making for considerably less than $10 each.  He was there, he said, because he figured that he might be able to incorporate the entire SOAP protocol, incorporating open-source code already available on the web, it would cost him less than $2 per chip-set, but that the value and market of for his chip-set would grow immensely.

I do not know if he has brought this to market, yet; I do know that this idea, of SOAP everywhere, was electrifying to me.  When I returned to the University, we re-vamped our plans, drew up a new roadmap, and began looking for a system based upon the concepts that are now being defined in oBIX.

Recently, I have been going through some of my old SOAP and XML related correspondence.  I came across a letter written in the spring of 2001 to a well thought of building automation system vendor.  

The vendor in question had listened politely to us as we described our requirement for a completely open system, one that would allow many users to get direct access to the information they required, one that was ready for decentralized exchange of information with other control systems.  The system we described would allow tenants to get direct access to the information they needed as it fit into their business models, not those of central monitoring and control.

The salesman, who was quite good, nodded, and then claimed that that was exactly what he was selling.  The system was open because it was written in Java.  The system let tenants harvest data directly because they could go to a web page and drill down when they wanted to look at data. His PowerPoint included the same slide all presentations seemed to have, a slide showing his system was open because all data was gathered to a single server, and we could make reports for tenants from there.

In other words, the same tired presentation and the same story we heard from everyone: web pages with proprietary data formats somehow constitute data sharing, an cross-platform programming language somehow means open standards, controlled access to carefully vetted stale data from a central server is somehow live access to operating data.

We have come a long way, but we are not there yet. 

oBIX and Green Buildings

oBIX is an effort to provide an enterprise interface to building control systems based on the internet standards used in e-Business. Building control systems are all the embedded semi-intelligent systems in a building, whether in HVAC, Elevators, Access Control, Fume Hoods, Fire Alarms, Occupancy monitoring, Power Distribution, Utility Metering, Emergency Generators. . .

US Green Building Council (USGBC) standards are often closely related to the underlying control systems, whether they are goals of efficient energy use, healthful environment, on-site energy production, and, of course, commissioning. The best known of these standards are the Leadership in Energy & Environmental Design Standards (LEEDS)

The controls industry today poses its own problems. It is routine that the control system from one vendor does not interoperate with that of another vendor. When they do communicate, it is through protocols known only within the industry such as BACNet or LON or Niagra, or worse, a format specific to a single brand; operating information is not readily available to the owner or to the tenant. When a savvy operator does get access to this information, that information is extremely detailed at the micro-level and therefore hard-to-understand.

A key challenge for LEEDS is ways to facilitate and routinize commissioning. An acknowledged problem is ongoing measurement and validation of these systems, as evidenced by the poor ongoing energy posture of some facilities constructed to be Platinum. ASHRAE (American Society of Heating, Refrigeration, and Air Conditioning Engineers) has a proposed standard (189P) which looks to address some of these issues by defining (among other things) what information should be available from control systems.

The path to oBIX has a several steps. The first is a standard web-services based specification for communicate to the control systems at the concrete level that they operate. This function, which I shorthand as WS-Controls, is complete and allows for point access to each function and sensor within a control system.

The next step is to build some abstractions for each domain, i.e., family of systems, to make this data more useful. Control work is such detailed work, and relies so much on attention to that detail, that it is hard for someone not very immersed in the engineering to be able to understand what is going on. Abstractions will combine host of points into air handling systems, while hiding such details as “the actuator that fires immediately before the heating coil switches on to close the damper”. Abstractions will also allow the curious to request information about room temperature or humidity without plunging into the morass that is building tagging standards.

One of the abstract services we hope to provide is analytic information of the sort measured during commissioning. Ideally, the abstraction of an in-place control system control system would be able to plug right back in to the data structures created for pre-construction building performance analysis with analytical information that either is or is not in conformance the performance goals as designed.

This enables, in concept, the self-commissioning building. (I know, I still want field verification – but maybe the cost-effective statistical verification becomes more reasonable if we have 100% self-commissioning.) This then opens up the possibility of continuously commissioning systems providing ongoing instantaneous performance validation. Such a capability would substantially extend the reach concept of LEEDS for existing facilities.

Daedalus: Architect, Engineer, Craftsman

Keep those emails and questions coming. Several ask "Why New Daedalus?". Some observe that Daedalus crashed into the sea. (That was his son.) Some remember Daedalus as a literary magazine. Well here is the myth of Daedalus.

As in all myths, the ones of Daedalus are varied. He was an artisan descended from the founding royal family of Athens, and was considered the best craftsman and architect of his day. He was the first sculptor able to create lifelike arms separate from the body. His designs have at one time or another been associated with every significant architectural masterpiece in Athens. His skill was said to be a direct gift from Athena.

He fled the law in Athens, and ended up in Crete, where he designed and built the largest and most elaborate building of the day, the Labyrinth. There he was not only the king’s architect, but he built a naughty device for Minos’ daughter, the end result of which was the half-man, half bull Minotaur.

He, like many who work in Facilities Operations, had the best view of the Labyrinth, in a high tower, but could never leave. He crafted wings of feathers and wax to allow him to escape with his son Icarus – but it ended badly for the son. After his escape, he designed and built the most famous structures in Sicily.

Another version has him assisting Theseus in finding his way through the Labyrinth. In this version, he returned to Athens with Theseus and built more of the acropolis.

Daedalus, then, was the best Architect, Builder, and Craftsman of the classical world. He was the archetype for architects and engineers, for contractors and craftsman. That is why I invoke Daedalus.

But why New? From Daedalus's rude sketches until today, drafting was refined and automated, but unchanged. Mechanical systems were wrought by clever craftsman, but not fully designed.

Today, modeling is radically changing the way we design buildings. Building systems are designed to be interactive and responsive. Information Technology is embedded in every step of the design / build / operate life-cycle. We even expect the building to interact intelligently with the outside world. Intelligent response is becoming pervasive in buildings.

This fundamental change is causing a profound shift in how we work with capital assets. This is arguable the biggest change in design since the days, and methods, of Daedalus.

This is why I call this site New Daedalus.