Do you choose Incrementalism or Markets?

The Grid doesn’t get better because we keep on relying on central planning to make it better. Any efforts developed exclusively by the current stakeholders and run through the utilities commissions will predictable and incrementalist. There is one (at least) that is not. The GridWise Architectural Council is trying to create open interoperable protocols to enable vibrant markets to develop, ones that are not driven by or yoked to the lumbering old style utilities companies.

GridWise looks to transform the production, delivery, and consumption of energy by adopting an open standards-based architecture across the entire power grid. GridWise makes no assumptions that future power markets will look as they do now. GridWise applies the latest approaches of Information Technology to the problem of grid modernization, and envisions a future in which the electric power grid is an information-rich, transactive network of decentralized economic agents. GridWise anticipates that opening up the interfaces to each business activity of the Grid will open electric power markets to innovation and create more choice and product differentiation for consumers.

Most folks are not going to live off the Grid, in my opinion. They might live what I call “near grid”. This means end points, whether homes or businesses, take responsibility for their own reliability. This will co-develop with approaches to storage, whether fancy batteries, chemical reactions, or even the water storage tank forty feet in the air I grew up with on the ranch. Live power pricing will drive storage development better than any number of central government programs; better storage will make responsiveness to price signals easier. From there, every means of alternate energy, no matter how unreliable, become another way to charge the storage. Sites will have multiple generation strategies depending upon their location, winds, sun coverage, thermal posture….

OBIX will package underlying control systems as services. Service definitions make meaningful statements of security and policy possible. Service definitions of each system will enable ad hoc discovery and control by software agents.

These agents may live at the home, the office, or at the hosting site of the 3^rd party energy and maintenance manager. These agents will read live meter readings and live energy prices. There will be a competitive marketplace for the software used by these agents. The best will expand building amenity and responsiveness as well as reducing the costs of energy and maintenance.

Stovepipe Processes and Construction

The NBIMS * list has hosted a conversation on the stages of BIM and how its business deliverables are different from those of CAD. Much of the conversation has focused on stovepipes in the process that reduce deliverables to the lowest common denominator. The discussion originated in how people should estimate time for each of the mileposts in the traditional drawing delivery process. This turned out to be the wrong question.

Early adopters of Building Modeling began creating virtual buildings for the benefits of increased coordination and enhanced visualization. One practitioner noted that over time, he grew to realize that the power of an integrated 3D database went far beyond his initial understanding. Today, it is common to find Owners, Contractors, Subcontractors, and Consulting Engineers around a conference room table in an interactive design exercise; parametric objects are manipulated real time in 3D. This approach leads to consensus building, and, because of the multi-disciplinary buy-in and participation, results in a better working relationship throughout the entire design and construction continuum. Multiple design iterations and 3D visualization are produced for the same fee.

Narratives such as this call into question the traditional mileposts, however hallowed they may be by practice and business process. The traditional deliverable for each milepost is drawings, what one participant derided as “mere black lines on paper.” Another countered that static snapshots will always still be needed to understand building spaces, proportions, intended flow, and relationships between materials....

Every system has its own internal logic and language. “Drafting” is one type of system that has process and tools to support the design and documentation of architecture. “BIM” is another system that has its own internal logic and language for the design and documentation of architecture. “BIM” is a newly designed and evolving system, and will require its own appropriate language, one that articulates the properties of its system.

As I pondered the discussion, I extended it beyond design to construction and the hand-over of data to maintenance and operations. As those hand-offs move beyond “black lines on white paper”, and the exchanges extend beyond those between the designer and the owner, we need new ways to track and measure these exchanges of information. How do we specify and contract for Construction Services to be performed out of the BIM?

• The bidding documents should be BIM. One of the great opportunities for cost reduction is the delivery of a full and accurate bid package, one that requires less fudge factor. This opportunity is lost if the contractor is bidding and building out of the “black lines on paper”.
• The contractor should modify the BIM as the work progresses. All change orders should originate in the BIM. Most firms we work with are willing to walk rather than earn the [too small] payment for delivering as-builts. Building from the BIM, and Change Orders through the BIM is a potential solution.
• Of course, these as-builts should now look like COBIE.

All of this causes wild swings in potential liability—much of it back to the designer.

These changes require new business models, and new standard contracts. They may require educating local contractors about the new process beginning with the initial programming when the decision to use BIM is made.

How would you establish the guidelines and standards for this interaction?

*NBIMS, the National Building Information Model Standard, is a standard for life-cycle data modeling for design, construction, and operation of buildings. NBIMS includes as one of its aspects a standard for Building Modeling to replace CAD as the standard for design and for exchanging information to guide the construction of a building.

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.