AutomatedBuildings.com Review

We want the best information that you can provide with your deep domain knowledge to present to us actionable information.

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.

I have been asked several times recently why we went our own way, away from the standard packaged “Enterprise Energy Management Systems” A few posts ago, I wrote how energy management systems have been pitched to owners and operators.

I still have my response to the salesman’s follow-up email. The vendors name has been removed, well partly out of politeness, but really because, it could have been almost any building automation system vendor, and any presentation – including a few I heard pitched in Chicago three weeks ago.

Your letter tap-dances around the fundamental issue that your system is *not* designed as we have indicated. Please show us the favor of not talking around that. Java does not make something open. ODBC access to pre-digested data does not make something open.

Having said that, your system does provide many very interesting features, features that we have already worked long and hard to get with our current system and includes some that the Energy side of the house really likes. I am positive that with a good deal of work, we could get what we already have. It may be entirely possible that with some small amount of additional effort, we can get beyond that to something marginally better.

The unfortunate truth is that we are already have a system, it does many of the same things, and the likelihood of changing in mid-generation is slim. The system we will change to is one that qualitatively changes and advances the way we can access building systems operating data. This is only going to be achieved by allowing direct unfiltered, un-aggregated access to local data.

We feel quite strongly that this will be achieved when local, shall we say "floor-level" controllers can be accessed as a standard web service. As a term of art, a Web service is "a collection of functions that are packaged as a single entity and published to the network for use by other programs. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide."

We are certain, that Web Services are defined in terms of XML and SOAP (http://www.w3.org/TR/SOAP/) expressing standard semantics.

We are telling you, as we have been telling all vendors for the last year, if you want to show us something new, show us XML and SOAP.

When you can show us that, we will be able to afford to abandon our current working system . When you can show us that, we will be able to let central admin applications compete purely on merit, something [your company] should be poised to do.

Until that time, you can only offer us marginal improvements, even if, as you have described below, you are the supreme implementation of the technology of the 90s.

I am happy to discuss this with you any time. But please do not do us both the disservice of agreeing with me for half a letter, and then describing how your system meets these requirements (architectural, as well as standards) in every way. Please re-read your own writing if you need to understand why the proposal as written is unacceptable (your note contains its own rebuttals on scaling and access). You do the evaluation of your product a disservice by doing so.

I have shared this letter, with identifying information removed as it was here, with several friends in control companies. Nearly always, the first question was “It wasn’t us, was it?” The sad thing is, I could still write this same letter today, a full five years later. The standards have moved on. Some of the links may be broken. SOA (Service Oriented Architecture) based on SOAP is in place and running the business to business infrastructure of America. Standards are now in place for business transactions and business processes in XML.

But for access to operating information from embedded building control systems, for the ability to coordinate control systems with any sort of high-level directives. . . I’m still waiting.

All of the current web services standard offered by the mainline controls companies are REST, meaning they let me push a point in using XML, and they let me read a point using XML. To some extent, they let me get many points using XML, as I can request a log, or a trend, or a history, and get back many time-stamped values.

But none of them is abstract. Which means none of them feel like a printer driver. If you want, you can find a networked printer. Whatever kind of printer you find, you can usually print to it without further thought. Some of them are in color. Some of them allow double sided printing. Some of them have more than one bin. You can find out by inspecting it from afar. In any case, if what you want to do is print, you can just print.

You do not have to know how a printer works. You do not have to know how a fuser works. You do not have to know how to operate the ink jets. All those internal relays, they mean nothing to you. You can just print.

Contrast this to our general experience with engineered systems. Generally, you will not know what it is. Is it a thumb-drive, is it a camera, or is it a printer. Is it an air conditioning system, a power system, or an intrusion detection system? The system won’t tell you.

You will not know where it is. You cannot link it to Google earth. You cannot link it to your administrative space assignment. You probably can’t even map it to the CAD plans that were delivered to you with the building two years ago. You are expected to know.

Until these systems know what they are, you can’t really perform the most basic interactions with them. I would like to invite the A/C to the meeting, just as I invite other people. But what am I inviting? Is it the air handler above the ceiling? Is it the thermostat? Is it the outside air temperature outside that I cannot set at all? Until systems can describe what they are, I can’t use them. The enterprise can’t use them.

Until the systems know what they are, I can have no security. Well, I can have one security: keep away! I cannot say that all administrative assistants at the departmental level have the right to set the thermostat. I cannot say that maintenance personnel get to see deep details until the system can tell the difference between the deep details and the superficial. Without nuance, there is no security.

I have no way to integrate building systems into long running processes. They do not know what services they provide; they only have settings, and measurements. With REST, they do not understand work flow languages like BPEL (Business Process Execution Language). I cannot integrate them into management frameworks like WSDM (WS – Distributed Management) or like WS-Man (WS – Management).

Two weeks ago, I listened as a major building systems company asked the Data Center group at IBM what they wanted revealed. The answer “We do not want raw data. We want the best information that you can provide with your deep domain knowledge to present to us actionable information. We do not want to become electrical engineers.”

Events	Want Ads
Our Sponsors	Resources