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.

Too Much Integration

Recently, a friend described to me a great installation of one of the low level protocols. A few years back, when they added an IP binding to the protocol, they had been able to construct an integrated control system between two factory production lines. One was at a final assembly factory in a northern city and the other at a supplier in a rural area down south.

Each of these factories used the same low level control protocol. My friend described to me how they were able to integrate the inventory control and JIT manufacturing at the two plats by linking their control systems. He was quite proud of it, and I’m sure it was a technical tour de force.

I was horrified.

There is no useful control level information exchanged between the two factories. Unless they do no quality control, there are no real exact inventory linkages between the systems. Certainly, there is no real-time linkage – they are a day’s drive by truck apart. There are only two reasons to link the systems: (1) they use the same protocol or (2) the interface is so contrary to what the corporation expects that they do not want to do it twice.

The first reason is a horrible reason to link systems. It is an example of the “Small Boy with a Hammer” school of analysis. More importantly, it skips all interesting and useful service integration by plunging quickly to process integration. Process integration is the process of paving the cow-paths. Process integration makes for brittle systems. Process integration prevents agile decision-making in the future. More importantly, process integration forgets the services that each system performs and replaces it with a mechanistic approach that belies the services.

I like to refer to system services as an overlay on system mission. Each system has a mission, and its first job is to defend the integrity of that mission. HVAC systems have a mission to provide healthful air conditions and long term maintainability of a building. They should defend this mission, including preventing outbreaks of Legionnaire’s Disease blocking large growths of mildew in the walls while providing the services of responding to requests to shed load or to the requests by occupants who push the thermostat up. Fume Hood systems have a mission of life safety that they must not skip. This system must defend this mission, as flooding the lab with poisonous gas is not an acceptable response to a load shedding request. Two systems. Nearly identical components. Perhaps the same protocols. Radically different missions.

The transition to a service orientation is going to be a difficult one for controls engineers. This sort of over-integration was understandable when low level protocols were all that was available. It was appropriate when there was no higher level interface to the control systems. It was appropriate when hand-crafting the enterprise interface, a process requiring someone skilled in translation between the worlds of production and controls, was the most difficult step.

But it is a bad architecture, one forced upon the practitioner, as the lack of structural steel forced heavy stone massing on early high-rise buildings.

We need to stop oner-integrating control systems. We have interfaces now.

To HAVE and to Have Not

I was talking to someone today who argued, passionately, that if a protocol did not let you get to all the details, then it was irreparably badly designed.

This is wrong in several ways. If a public protocol that exposes systems to people from another domain, it is a security problem. It is harder to use because it has unnecessary complexity. It may be just too hard to use for most purposes.

Reaching for an example, I come to HAVE, the Hospital Availability Exchange. As I understand it, HAVE is a web service that makes waiting lines visible to people outside the hospital.

Imagine a scenario with an ambulance driver performing triage. He picks up the first patient and quickly decides “We’re going to need an MRI for this one.” MRI waits can be several days in some hospitals at some times. Using HAVE, the ambulance driver determines which of several hospitals within five miles has the shortest wait for an MRI.

Imagine someone had insisted that HAVE had to expose all the details. Perhaps have it include the patient scheduling, or diagnostic details. Letting anyone use such a HAVE would probably be a HIPPA violation, exposing the patient’s personally identifiable health information.

Instead, the group working on HAVE wisely limited it to some surface details. Those details are fully adequate to meet the needs of determining availability of service. Even with vigorous hacking, it is unable to reveal inappropriate information because HAVE does not include the detail.

By creating a limited protocol, the creators of HAVE created a useful protocol.

In the same way, advocates of building control protocols who want to be able to perform all functions with an enterprise function simply get thing wrong. In the same way, advocates of Power Grid protocols who want full CIM (Computer Information Models) for each house get it wrong. Such details would make the protocols to difficult and nuanced to use. They would inappropriately expose detailed inner process information to those either who do not know how to use that information, or who do not have sufficient expertise to use that information well. Either of these is a risk.

Enterprise protocols should stick to the surface. It is the nature of enterprise protocols to expose information beyond their domain. Those who know that domain should have enough respect for their own work to occult the details.

Service must trump Process

Today, in North America, very few designers using BIM do anything but structure. If they do design mechanical systems they keep it on the side. Because of this the Energy Model, when made, has little connection to the actual design. As the Mechanical systems have not really been fully designed, the mechanical contractor makes up something as he goes along. The controls contractor varies still further from the design, and creates tags for each sensor point that are not known to the model. This means that Commissioning can rarely be tied to the energy model.

In essence, there is no interface defined, although there is plenty of procedural information. To me this is a problem.

For a good look at a large complex system that defined interfaces (not procedures) across a multitude of systems, many of them proprietary, look to the European Union Seafood Safety System. It scales, and is successful, because it focused primarily on the interfaces, not the internal processes, of its composite parts. A single transaction for them might span a restaurant, a delivery company, a local retailer of seafood, a long distance trucking company, a port-town warehouse, dock operations, a fishing fleet management system, and PDA’s on a boat at sea. You cannot do that while focusing on the internal operations of each step in the supply chain.

My personal interests are in making each building a participant in an open market of energy sources that span a continent. ( www.gridwiseac.org ) At the same time, within a building (or campus) there might be mix of energy generation (PV, wind, Stirling Engine,..) and energy storage (Battery, Hydrogen, water pools, …) systems.

The complexity of such systems is impossible to manage, or orchestrate, or choreograph unless it is hidden behind abstract interfaces. If they are all tied into one tight control system, then we have created a realm wherein the producer of each system cannot be held accountable for performance. We also create a rigid system wherein individual system failures lead to cascading failures rather than simple degradation of overall performance. This means that I want abstract interfaces even between systems in the same building.

With these abstract interfaces in place, one could add new systems as new technologies become available. I can swap in substitute systems without re-programming the others. This intensifies competition between these large systems by reducing the friction on the transaction of switching from one to another in an existing facility. This competition is at the heart of what the new market structures

If we make these abstract interfaces discoverable, the we can easily imagine a competitive market of agents that can find and interact with these building systems as well as with the business processes (or life preferences, if in a home) of the building inhabitants. Those agents could interact with the power grid and live energy pricing on the basis of a single building. As the abstraction level grows, the agent could be located outside the building, to bid aggregate power use for an industrial combine, or for a portfolio of homes with either similar desires (I want all wind power. I want a carbon-neutral mix. I want the cheapest power available.) or complimentary power use patterns.