Discoverable Abstract Interfaces

Interfaces to traditional control systems are concrete and detailed, and therefore their operation is complex; one cannot operate such systems without detailed specific understanding, or what is called domain knowledge. There is often little overlap between different areas of domain knowledge.

My car has a complex control system built using the CAN protocol. I have no knowledge of that protocol. I operate the car using a much simpler abstract interface. The one on the right makes it go faster. The one on the left slows the car down. This dial says how fast it is going. That dial says how much fuel is left. By understanding this abstract high level interface, I can operate any car. My mechanic needs to know the control system – I do not.

Because the interface is abstract, it is discoverable. I can sit in my wife’s car, and in a few minutes understand the differences. The dials are slightly different. My car is manual and hers is automatic. Mine has a tachometer and hers does not. The interfaces support some diversity, but the diversity is within a small range so the details to operate each car can be discovered quickly by the driver.

When I am in the car, I become, in effect, the control system for the car. This system interacts the other driver-car systems using a simple abstract interface based on lights. I use abstract signals to indicate slowing and turning, and the other systems react as driven by the needs of their systems. By using a highly abstract interface, no a priori negotiations between drivers is required to coexist on the same systems bus, or “road”.

Before complex control systems are ready for the enterprise, they must hide their complexity and detailed domain knowledge behind an abstract interface. For that interface to be available to computer systems rather than to people, it must be formatted for machines rather than for people.

And that is what I mean by discoverable abstract interfaces.

Let's Make Energy Models Relevant

Energy modeling is an important part of designing more performant and healthful buildings. Energy modeling is a foundational requirement of important initiatives such as the Zero Energy Building Initiative (link) or the Zero Net Carbon Building project (link). Building Energy Modeling is also an important tool to determine problems in building design before the more expensive construction process begins. Today, because of lack of integration and a reluctance to re-think the design-build process, Energy Modeling is often an ineffective sop to public constituencies, adding cost but little value to a project. This is particularly true for construction projects performed by government agencies, with their commitment to traditional processes and metrics that are often in conflict with innovation and new business processes.

New building projects have two sources of design constraints: organizational goals and design intents. Organizational goals are larger than any single project, and stem often from public pronouncements. All new buildings will be at least LEED Silver. Each new office building will have an energy budget 20% below that of our existing portfolio when it comes on line. Design intents are transcribed for each building, often during marathon charrettes with lots of soggy deli take-out. Together they describe the success points against which the design should be evaluated.

Many of today’s energy models are generated in response to organizational intents. Energy models are a source of green points, and they may have some tangential applicability to the construction documents. They are rarely an intrinsic part of the design process. They are often a sub-contract let by the design firm.

It is more useful to think of Energy Modeling as an audit or commissioning process applied to the design. Just as we wish to commission a building before we accept occupancy, we should commission the design before we bring it to bid. Just as we commission a building to see if it works as designed, we should commission the design to see if it has met the organizational goals and design intents. The energy model is one part of commissioning the design, and as an audit, it may be best be performed by a third party working for the owner rather than the designer.

Often the sole real liability for the designer pre-construction is meeting the bidding budget. If this constraint is not met, we return to the designer for the misnamed “value engineering”. A better process, based upon a persistent building model, would re-subject all value engineered designs to energy modeling as well as the other design validation processes currently being developed [1] . These models would then present explicitly to the owner the compromises to design intent and organizational goals that derive from the value engineering process.

This increased liability on the designer will not come without cost. Increased liability demands increased payment for increased value. This increased cost will be easy to recapture. Errors are always easiest and cheapest to fix earlier in any process.

---

[1] See efforts by the International Codes Council (ICC) to automate compliance checking, beginning with automated Energy Code Compliance checking, with Electrical Code, Plumbing Code and other compliances in the plans.

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. 

Principles of Networked Electronics and Energy Efficiency

I had the pleasure of talking to Bruce Nordman of Lawrence Berkeley National Laboratory (LNBL) this evening. It is always nice to come upon someone who has bear end of the same bone as oneself, coming at some related issues from a completely different perspective.

Bruce is presenting at the International Energy Agency next month. Poor guy, he has to go to Paris when I got to go to Chicago. Bruce is approaching problems from the perspective of the electronics world—and so recognizes some things faster than I.

DC Power? We discussed Galvin, and he leapt immediately to POE (Power over Ethernet) , USB (Universal Serial Bus) and FireWire as the de facto standard DC power plugs. I don’t think that these will handle my microwave or my white boxes (Washing Machine, Refrigerator, etc) but it makes sense that these might be the starting place for DC power connectors. I have long admired the elegance of the Blackberry USB Power Supply.

But what drew me to share this conversation were Bruce’s Guiding Principles, as outlined on the IEA site (see below). Bruce is an advocate of all networked electronics being designed for effective power management. TO this end, he (and his co-authors) have described their guiding principles for design. They make a good set of rules for building systems, or for houses, or for the Grid, as well.

The Guiding Principles are:

• The existence of one device on a network should not cause another device to stay awake when it might otherwise go to sleep.
• The network should be designed such that a legacy or incompatible device will not prevent the rest of the network from effectively using power management.
• Devices should expose their own power state to the rest of the network and be able to report estimated or actual power use levels.
• Product interfaces — for people or other products — should follow (international) standard principles and designs.
• Products or devices that influence energy consumption should adhere to (international) standards for behavior and communication appropriate to their function.
• Products and connections should have the ability to modulate energy use in response to the amount of service required.
• Energy efficiency efforts should not favor any particular hardware — or even software — technology. All network technologies must be the target for efficiency efforts. Future buildings will include many different technologies; those in any particular building will be diverse, and always changing.
• Harmonization of basic principles underlying efficient design for networked devices should cross all end uses and be global.