One bus, one wire may not be a good idea.

“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

Invisible and Uncontrollable

Recently a reader posed the question, why integrate building systems. He wrote that the primary mission of a building systems is the economic provision of healthful and comfortable space. It is usually run in set and forget mode - and has no interaction with the business processes of the tenants. They remain invisible and uncontrollable unless they break.

Building control systems extend way beyond HVAC. Access control systems should interact with human resources. Intrusion Detection systems should interact with the catering schedule. Medical gas distribution systems should interact with patient care and surgical scheduling systems.

Traditionally we have talked about HVAC first, because of the easy tie between HVAC and energy use, and between energy use and money. Because traditional business models keep the building ignorant of market prices for energy, anything beyond static energy analysis is not rewarded. Because of the lack of standards and insufficient abstraction, there has been no way for business processes to integrate with HVAC. This old-school model is what we find in most buildings today. And within it, the value of integration is limited.

The value of integration can be found in new business models that it enables; these will develop in tandem with the abstract protocols that enable them. Dynamic power grid pricing will create incentives for building responsiveness. Four dollar a gallon energy prices will create incentives for accounting for business decisions that affect when the building is operated. HIPAA compliance requirements will require improved interactions between medical processes and physical access to record storage....and these are not issues that fit neatly into the old business models.

In the future, invisible and uncontrollable will not be good enough.

What Good is LEED Certification?

It’s time to acknowledge that LEED standards, as they exist today, increase cost without increasing value. Without committing to fundamental reform of the building development process, Green points from LEED have little if any effect on the overall project. LEED gives points producing the symptoms of a good development process. Most designers, and most owners, opt to produce the symptoms, and leave the flawed processes intact.

The Leadership in Energy and Environmental Design (LEED) Green Building Rating System is the accepted benchmark for the design, construction, and operation of high performance green buildings. LEED promotes a whole-building approach to sustainability by recognizing performance in five key areas of human and environmental health: sustainable site development, water savings, energy efficiency, materials selection, and indoor environmental quality. A project is a viable candidate for LEED certification if it can meet all prerequisites and achieve the minimum number of points to earn the Certified level of LEED project certification. Projects are awarded Certified, Silver, Gold, or Platinum certification.

Unfortunately, LEED can reward those with existing bad processes more than it can acknowledge existing good ones. If you made bad decisions in the past, you get extra points for not making them again. It is too easy to greenwash a project by adding an energy modeling component that has no intrinsic tie to the construction documents. The routinely incomplete documentation of building systems means that the actual wiring and operations is dependent upon the creativity of the subcontractor rather than the Green design. With incomplete system documents, commissioning is a demanding but ultimately futile function. Innovations in system design are lost in normal maintenance and operations due to the inaccessibility or incompleteness of the documents handed over.

To achieve the results LEED aims for requires not just gaming symptoms, but rather an actual commitment to good processes, for the planning, design, construction, and operation of capital assets. The foundation for these good processes must be a non-transient base of information that is accessible throughout the entire building life-cycle. All process audit functions, whether energy modeling, code compliance checking, or even commissioning must be based directly on that information base. If we used such a process, most of the LEED points would fall automatically from the process, with little extra effort necessary.

When we score LEED points without examining the underlying process, we are summing nonsense. Here are some specifics:

  • At UNC, buildable lots are identified and cleared five to ten years before construction starts. Every clear lot is, as on most campuses, used as a parking lot. Today, we get green points because under LEED, siting buildings on brown fields, such as parking lots, is a best practice.
  • We specify, for reasons that are primarily historical and regulatory, CAD-based designs. To get green points, we require that the designer acquire an energy model. That model has no intrinsic link to the CAD design, and there is no way to determine if value engineering removes the features modeled.
  • Building systems are drafted as crude schematics, with no provable links to actual wiring and control tags. This creates building monitoring systems that cannot be linked back to the design, nor to the energy model. This makes commissioning more arduous and less effective.
  • Practitioners in retro-commissioning, that is the process of re-visiting a building possibly years after initial construction and examining system operations are unanimous; nothing would be worse that returning the building to its initial design state. Even in new buildings with high LEED ratings, the control systems were only partially designed at best.

Without a design process that actually includes the mechanical systems and their controls, there is no underlying operational model for the building. Without an underlying model, ongoing system maintenance is based upon guesses. Without live performance metrics, including instant access to energy metering, linked to that model, than building system operations are based upon experience and guesswork. When the system is green and non-traditional, you can eliminate experience, leaving only guesswork. to operate the building, and to tell if the building is being tuned into or falling out of control.

The solution to these problems is an integrated data model for the building whose life extends as long as the life of the building. The data model starts with the capture of the design intents. Building designs should be models, not drawings, and should be standards-based. The energy model would then run directly off the building model and could be compared to the design goals. Changes to the design, especially during value engineering when many innovative features are eliminated, could be automatically reflected in updated energy models.

The electronic building model should be available electronically to each bidder and used throughout the construction process. The increased accuracy of the bid package and reduction in change orders during construction would reduce costs and result in as-built models that match the initial design. These accurate designs, delivered to the owner, would include full identification of the internal systems, their components, and their performance expectations.

With delivery of the as-built models, using system identifications consistent with the initial design documents, building commissioning becomes validation of performance to the design. In the case of energy systems, commissioning becomes validation to and alignment with the energy model. This, at last, becomes a significant improvement over the traditional standard, described, only half in jest, as “no sparks”.

Under this business model, LEED credit would become relevant. Each LEED point is no longer a game-able item separate from the actual business process, but an intrinsic metric of the quality of the process. Facts necessary to support innovative systems would be available to maintenance and operations throughout the life of the building. Those would be green points worth earning.

Note: I know of and am watching eagerly the development of ASHRAE standard G189P. I think the observations here are aligned with its intent, It will offer some improved structure that will lead to measurable sustainable performance.

Still Waiting. . .(part 2)

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.

Dear xxxxxxx,

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, you will have our full and complete attention.

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.

tc

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.