Grid Interop Coming up

I submitted an abstract for a talk at Grid Interop today. I have been near academia too long. Abstracts bring out the most pompous side of my writing. Even so, I am sharing this abstraction with you.

Business Innovation and Service Abstractions

True Scalability and interoperability require abstraction and security. Most control systems today expose name/value tag pairs as their interface. This poses two problems. Interaction with exposed tag pairs requires a deep understanding of the underlying systems. Secure interaction with sets of tag pairs can only practically be exposed as monolithic yes/no decisions for the entire set.

The smart grid will require integration with smart buildings and their associated power capabilities. We will need to develop abstract models for system interaction to enable such large-scale system integrations. These abstract models will hide underlying system detail while exposing the diversity of systems for orchestration.

None of this will happen without mature security models. Significant segments of people and businesses will not give up autonomy over their private resources to any third party. System abstractions will make building systems appear as printer drivers do, exposing themselves to owner agents able to negotiate with the intelligent grid.

A service can abstract the operations of each system. This service defines the mission of the internal operations each system. Each building system should defend its mission. Systems that are quite different in complexity and technology can provide the same service. Owners and integrators will be able to compare different systems as to how safe, effective, and economic their operation is without changing the higher level integration.

Services enable security, and security enables allowing the tenant or owner to interact with building systems. Agents can be restricted to which services they interact with, and what performance they request using understandable business rules. This level of abstraction will support internal tenants or third party service managers to safely and effectively interact with the building systems.

Service oriented architectures and integrations make possible large scale interactions. Service discovery enables ad hoc interactions. Services hide implementation details. Service oriented architecture to will enable orchestration of building systems including site-oriented energy generation and storage. New business models will take advantage of these new interactions to drive energy use reduction through innovation.

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.

Lurkers – Time to Give Back

As you probably know, BLOGS are generally interactive. It is the interaction with visitors that keeps the blogger able to produce. And I’m feeling something of an echo chamber, here.

I’m pleased that more than a hundred of you are subscribers. I didn’t expect that I would be getting more than 400 visitors a month so soon, many of whom visit several times a week, a few daily. (Sorry about last week, daily visitors; I was busy…) But I am feeling a lack of feedback…

Why are you subscribing? What did you hope I would talk about that I haven’t yet? What have I missed the mark on?

If you are here, you must share some part of the vision. What nut do we need to crack to get things moving? What problem do we share that prevents us from getting there?

Sign in. Create a dumb alias with a non-working email. Comment anonymously. Now would be a good time.

Thanks

tc

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.