Design

Information Stewardship

A design firm came on to campus the other day to begin conversations on the new School of Information and Library Science (SILS). Library Science has been one of the more interesting areas of IT in the last few years, as they are positioning themselves as the side of Information Technology (IT) not concerned with the bits and bytes, nor with the collection of data, but with delivery of information.

The Art of the Librarian has always been about the delivery of the right information in the right format at the right time. Google delivers vast amounts of references at your fingertips, each information set and document only a click away. Little Billy in the second grade asks the school Librarian for a book about frogs and his handed a book with lots of pictures and small words. Nine years later, William, now taking AP Biology, asks the school Librarian for a book about frogs and gets an entirely different set of volumes. Librarians know that context determines the correct information.

The design firm knows a little something about its audience, and they presented a pitch that the project use new approaches based information stewardship. New approaches can be a difficult sell to someone who has one chance once to build a building. Even so, it seems to me the Information Stewardship is a good line to take with Librarians.

Information Stewardship appears include keeping all design information on-line and electronically readable. All commissioning information will also be kept on line. Making a statement that speaks to me, the firm also asked that they have access to live operating data for at least a year, to make sure that the building delivers the energy and performance goals that are specified in the design.

This last point is particularly important. One of the worst failings of first generation LEEDS Green Buildings was their long term performance. Platinum building performance was never verified. Innovative designed were never adequately explained to maintenance and operations personnel. At last, that nettlesome vibration is solved putting a brick on the damper. At last, that noise in the duct is blocked by shoving a file cabinet in front of the oversized return. A year after delivery, the performance is poor.

Regular readers will recognize the goals of this project as being similar to those of the National Building Information Model Standard (NBIMS), now known as buildSmart. It is interesting that the design firm professed no awareness of NBIMS, and in particular, no awareness of the Common Operations Building Information Exchange (COBIE) which specifies the hand-off of information from design and construction to operations.

SILS has recently begun offering concentrations in Bioinformatics. There is some discussion about adding a concentration in Business Informatics. Perhaps, with the aid of Building Information Stewardship, we can begin the development of Building Informatics. If so, this could be the missing piece in developing the abstractions needed to develop truly responsive buildings for the transacted energy grid.

Is anyone else as confused as I about the differences between Informatics, Infomatics, and Analytics? They seem to be used interchangeably, but in different conversations. Please post if you can define the distinctions.

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.