Treating Systems like Components

We tend to over integrate systems. In particular, we over-integrate building systems in high performance buildings. Because they all use similar signals, and have similar digital processing, the highest standard seems to be to integrate many systems as if they were a single system.

Each system should drive its own, and only its own, internal processes. Each system has a mission, a service it must perform for the enterprise that owns or inhabits the building. That mission drives the technologies chosen to compose the system.

The mission and the technologies drive the internal processes of each system. Because these processes are hard to do, and harder to do well, practitioners tend to think they are the most important part. Actually, no one cares, or should care, about the processes except from the inside.

Users and beneficiaries care only about the results of that process, what we call the service, and the requirements of that process, whether we call them inputs or call them costs.

The best way to integrate systems into a performant building is to ignore the processes, and to integrate the systems. The inputs must have clean interfaces so we can orchestrate the service provision. We must catalogue and understand the costs in resources and in waste. Thereafter, we should ignore the processes internal to each system during integration.

In business processes, bookkeeping is critical to any business. Accountants devise the processes for bookkeeping to make sure they accurately reflect the needs of the organization and that they produce accurate descriptions of business performance. Finance has to assume that the bookkeeping was done well, that the financial statements were well designed, and uses them to support higher level processes within the enterprise. Finance suffers if it focuses back on the Point of Sale.

Chris Martin, my friend who started his career in the Back Island microgrid, has recently examined the “energy financials” of systems in many research buildings. At UNC, we have central provision of steam and chilled water. Each building pulls its heating and cooling from the central distribution loops. It is an unfortunate truth that every building consumes heat in the form of steam, even in summer, and every building consumes cooling, in the form of chilled water, even in winter.

We have skilled staff who examine the energy-using systems in these buildings, and work hard to optimize them. This work is imbued with the deep processes of each system, and with the logic of the processes. Chris recently embarked on a different approach.

Chris began examining the “Energy Financials” of each building. As we work to break down silos between business processes, we are seeing for the first time, time sequenced data on energy use by each of the systems. In this analysis, the processes are hidden. All we have is the requirements and output from each system. The removes clutter and lets one see higher order interactions.

What Chris recognized is that the Chilled Water and the Steam consumption lay nicely on top of each other. For some months of the year, they could cancel each other out. During winter or summer, one fits entirely inside the other. This insight replaces fiendishly clever interactions with a simple one.

Chris is proposing a simple heat pump, or chiller, if you will, connecting the two systems. It will pump heat from whichever system is dominant for the season to the other one. It may enable some buildings to leave the steam distribution entirely. Payback on the small investment looks like it will range from 1.3 to 1.5 years, with a positive cash flow thereafter.

This is the advantage of hiding the processes, and looking only at the services and costs. The complexity of the problems you or someone else has already worked goes away. The opportunity for new solutions can be seen in the newer simplified set of facts. Chris Martin is demonstrating the advantage of approaching performance and efficiency of embedded building systems from the perspective of service oriented architecture.

Cool.

Would you use SVG or XAML?

We are currently in the middle of a multi-million dollar energy management project at the University of North Carolina. There are many aspects of it, including creating generic web-service gateways to a variety of underlying low-level protocols (BACnet, LON, Sigma, KNX) and aggregating them up to a central monitoring system we call the Enterprise Building Management System (EBMS).

All interaction with EBMS is through secured web pages developed with open source code. These incorporate into graphics generated from a number of sources including AutoCAD DWG files as well as a number of control panel widgets. All use AJAX calls against the EBMS server and the building gateways to display interactive data and allow building operation.

The RFP/Specification calls for Scalable Vector Graphics (SVG) as the primary format for for “EBMS Dynamic Color Graphics”… in no uncertain terms, the spirit of the specification Application has been that the system graphics would be in an open, XML based, vector format. When we all started this project, the only format meeting those qualifications was SVG. Recently the vendor came back to me and pleaded to be able to use XAML.

In the years since the project started, Opera has gained good native SVG rendering, but almost no SVG behaviors. Firefox support OK SVG rendering, but does not support islands of XML/SVG inside a larger page, and offers little support for SVG behaviors. The major plug-in for SVG with good support of behaviors was from Adobe who has abandoned it since they bought Flash. Corel, who supported it as the project began, has virtually erased all references to the effort. SVG is getting some small traction as SVG Mobile in the mobile phone industry.

If we switch from SVG, this leaves XAML as our Scalable Vector-based XML graphics format. Yeah, its dancing with Redmond, but it at least seems to have some tools, and support for open coding frameworks. The Linux community appears to have already released a Silverlight [XAML] plug-in beta, and Microsoft is set to release this week an official Linux plug-in.

Microsoft has, despite requests, not released the XAML specification to W3. This is explained alternately as Redmond==Evil or as not wanting to put a boat anchor on innovations until a couple iterations are up. Both accusations probably have some truth.

So, would you let the Integrator switch from SVG to XAML? How would you approach integrating graphics from diverse sources including CAD into the one you favor? If the answer is SVG, what are your favorite tools for interactivity?

Can you afford to not require building models?

Many of the best builders use ephemeral models today. Contractors generate their own building models. They create these models are created prior to the bid, to address the inadequacies planning using he traditional building system drawings. When he wins the project, the contractor will use this model throughout the construction process. This model is then discarded, as it is not specified as part of the project deliverables, and could create additional liability. It would be far better, and far more efficient, is these models were based upon the designer’s models, and were included as project deliverables at building turn-over.

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, for example, should 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.

This 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, 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, then 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 humour, as “no sparks”.

This persistent design model would become the basis of maintenance and operations decisions. Maintenance staff would have ready access to design and commissioning documents keyed with the same systems identifications. Field notes and best practices discovered for one system could be made automatically available to all similar systems using the information model. acts necessary to support innovative systems would be available to maintenance and operations throughout the life of the building.

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