Surfaces – the kind of Abstractions I like best

My personal interests are in making each building a participant in an open market of energy sources that span a continent. (www.gridwiseac.org\) At the same time, within a building (or campus) there might be mix of energy generation (PV, wind, Stirling Engine,..) and energy storage (Battery, Hydrogen, water pools, …) systems.

The complexity of such systems is impossible to manage, or orchestrate, or choreograph unless it is hidden behind abstract interfaces. If they are all tied into one tight control system, then we have created a realm wherein the producer of each system cannot be held accountable for performance. We also create a rigid system wherein individual system failures lead to cascading failures rather than simple degradation of overall performance. This means that I want abstract interfaces even between systems in the same building.

With these abstract interfaces in place, one could add new systems as new technologies become available. I can swap in substitute systems without re-programming the others. This intensifies competition between these large systems by reducing the friction on the transaction of switching from one to another in an existing facility.

If we make these abstract interfaces discoverable, the we can easily imagine a competitive market of agents that can find and interact with these building systems as well as with the business processes (or life preferences, if in a home) of the building inhabitants. Those agents could interact with the power grid and live energy pricing on the basis of a single building. As the abstraction level grows, the agent could be located outside the building, to bid aggregate power use for an industrial combine, or for a portfolio of homes with either similar desires (I want all wind power. I want a carbon-neutral mix. I want the cheapest power available.) or complimentary power use patterns.

In other words, I want to place Intelligent Buildings as fully actualized agents on an Intelligent Grid. To do that, I hope to leverage Building Intelligence (NBIMS) to discover abstract interfaces to the point-by-point complexity of the underlying control systems. Rather than create these abstract interfaces from scratch, I had hoped that the pre-existing interfaces between the Building Model and Energy Models would be a good starting point. By doing so, I hope to avoid the complexity of introducing Yet Another Acronym and Yet Another Interface, thereby avoid increasing complexity.

Abstract interfaces that hide rather than reveal complexity are the key. Here is an example from within oBIX discussions. When we discussed abstract interfaces for scheduling, each control system developer quickly claimed that “scheduling systems are quite complex, and there are no agreed standards.” Spirited discussions ensued about factoring how long it takes to air condition a room in advance. Should we factor in humidity. and on. and on. But there is already a standard for scheduling. We each receive ICAL invitations to each NBIMS event. It is a W3 specification. Our own systems know how to adjust for where we are in the world, including such local oddities as when Daylight Savings Time begins. Each of us considers whether we have to drive to the meeting, or fly, or simply be near a phone. Those details are not the concern of the interface but of each of us and the complex systems we represent. I want to simply invite the conference room or class room to an event on a certain date, with a certain number of attendees anticipated.

If these questions are answered correctly, they expand the value of capital assets by extending their ability to provide services and amenities to the owners and tenants, not merely to avoid costs. An Energy Model consists of Envelope, Weather, and System Operations. An abstract interface that works for energy modeling could be re-usable in tuning System Operations in response to Weather Predictions to improve quality of service provided. It becomes the basis for external system analytics to enable predictive maintenance and thereby economically provide enhanced reliability.

Adding Service Orientation to Large Semantic Projects

NBIMS, oBIX, and GridWise are large semantic projects that are hard to plug into.

I am more and more convinced that the proper concern of the systems architect is surfaces. Tell me what the interface is. Tell me how I plug into it. Tell me what I get out of it.

I think that this is what a lot of the “Open “ movements get wrong. They may provide me with all of the code to do something, but with no way to get information in or out. “Well you could write that” is not an answer for someone who also has a day job.

NBIMS has as a significant effect, if not a goal, the preservation of information over the life of a capital asset, from the earliest gleam in the eye of the initial request to the final destruction of the asset. Each snippet of information has some cost to get, and some value based upon each use. By converting each of these snippets into multi-use, we are increasing its value without increasing its cost.

The hand-off has to be in surfaces. There is significant value in each of the proprietary engines that create, say, a structural building model. Every consumer of that BM derives great benefit from a free and lively competition amongst the proprietary engine makers, to the extent they can expose the results of those engines on the surface.

This is all a long way of saying that what is not apparent to the developer of a standard of interest to the NBIMS is how to define the surface. I was taught on my last call that something called the IDM is where surfaces are defined. I still have not found the “So you want to propose an IDM” document, the one that encourages the definition of that surface. This document will be critical in bringing the whole list of standards that comes from Deke’s inquiry into the fold.

I talked to someone else who will remain nameless who wanted to bring a standard that will increase the value of a BIM by exposing it to a variety of societal and economic actors. His conversations never mentioned the IDM, nor demonstrated the way to go.

Modern systems work is defining Service Oriented Architectures, interacting with surfaces. People construct large virtual corporations around a unique choreography of external services. Components of a virtual corporation have diverging proprietary interests which make them expose only the defined surface.

And every CIO is now wondering, what does my SOA Governance look like. Whether my virtual corporation is built of internal or external services, the political as well as technical task of managing the surface interactions becomes important. A quick (although Google will reveal hundreds more) search reveals this intro to SOA Governance

http://www-128.ibm.com/developerworks/webservices/library/ws-soa-govern/

I think that at some level, NBIMS, and GridWIse AC, and oBIX need to think of thenselves as SOA Governance organizations, perhaps orchestrated by BPEL-like work flows. I think that the design/bid/construction/purchase can be thought of as a lot of a long-running transactions. I think that the structures that define the surfaces enable “optional services” that enhance the project, whether they be energy models, code reviews, or post-COBIE performance analytics. I believe we should consider whether they become transactional (I’ll have my web service call your web service) rather than static piles of data in a standard format. 

I will write of GridWise AC and oBIX later, but most points translate across directly.

My proposed model for NBIMS is not a model of coexistence between a lot of data sets. It is a model of abstract interactions between services. This moves NBIMS from cost and mistake avoidance to heightened service provision. This makes Building Intelligence the enabler of Intelligent Buildings, interacting with the Intelligent Grid, negotiating with external Asset Management organizations.

Many have said, the chief barrier to implementing Service Oriented Architectures in an Organization is if the Organization itself is Procedure Oriented. The nimbleness, agility, and best practices that an SOA defines cannot be achieved if procedure trumps all; the Procedure Oriented Enterprise can only achieve a Procedure Oriented Architecture. I think we have all suffered under those in our professional lives. Service Oriented Architectures demand Service Oriented Enterprises as a precursor.

Procedures are necessary. But if we cast these large initiatives as Services, we can more easily leverage IT governance best practices while knowing how to define the process for surfaces that support plugging in new services to the capital asset. This will make it easier to bring groups to the table. This will make buildingSmart an easier sell.

Can we cast NBIM an orchestration of long-running services?

It’s not your system

I was in the middle of a running discussion on how to get people to understand why NBIMS is important a couple weeks ago. By happy chance I came across this article during the discussion, directed to programmers, on the subject “You are not your user! I found this passage particularly apt:

It's Not Your Software
Contrast the folly and the cunning in software design to understand why you are not your application's user.

http://www.ftponline.com/channels/arch/2007_04/todonnell/

It expressed some of my concerns much better than I did, but in a different domain.

Getting to the real heart of the issue, Platt asked how many in the audience drive a car with a stick shift, and it looked as if nearly every person in the auditorium raised a hand. Guessing that at least three quarters of the audience thought that a manual transmission controlled with a stick shift—something that is harder to learn, harder to use, but gives you better control—is a good trade-off, Platt contrasted this result against the roughly 12 to 14 percent of automobiles sold in the U.S. that come with stick shifts.

"Six out of eight think something that's harder to use but gives you better control is a good trade-off; only one out of eight of the general populace thinks that's a good trade-off. Normal people do not drive stick shifts," Platt said emphatically. "Why? Because they don't care about the driving process in and of itself. It's a means to an end. They don't want to drive somewhere; they want to be somewhere."

Following an outburst of laughter from the audience, Platt evoked a loud round of applause by punctuating the theme: "It's an important distinction. You think your users want to use your software. They do not want to use your software. They want to have used your software."

In this case, the participants in the conversation were domain experts in IT can construction. They understood what they were up to. They seemed not to understand that what motivated them was never going to motivate a wider audience.

The real audience for NBIMS is the enterprise developer, someone who, while technical, does not want to know anything about the deeper IFC. Until NBIMS finds a way to make itself accessible to the enterprise developer, it will remain an interesting side-show.

The next week, I headed off to Dallas, and to the GridWise IT symposium. There I found the same issues. I even used Platt’s audience participation game, and found similar numbers of manual transmission aficionados in the audience.

There I pointed out that none of the avid consumers, totally committed to efficiency and economy was likely to surface. If they wanted to expand the market for their ideas on improving the Power Grid, they were going to have to translate it into some combination of three things: Autonomy, Self Image, and Cool. Find a way to enhance these, or appear to enhance these, for the consumer and the battle is done. Fail to do so, and the technical substance is wasted.

The same argument could be made about Building Systems, and oBIX. In fact, I will be at Connectivity Week in three weeks. I probably shall.

Intelligent Grids need Intelligent Buildings

Two weeks ago I participated in a symposium sponsored by the Pacific Northwest National Labs (PNNL) for the GridWise Architectural Council (GridWise AC). It is a fascinating conference, and one with more chance of meeting green and environmental and conservation goals than just many other initiatives hosted by folks who wear their hearts on their sleeves. It was also grounded in good economic theory and humble enough that it might just succeed.

GridWise AC is trying to create the structures to enable rapid innovation in the power grid. The first principle of GridWise is that while the folks in the room are smart (and they were – this was no small part of the fun), they are not the only smart folks in the world. To actually address the needs of the future grid while moving to new models of energy production, we must create structures that encourage innovation. To encourage innovation, we must create means of realizing value propositions for new energy usage patterns and for non-traditional power sources.

Current market structures are a boat anchor on innovation. If you invent a gizmo that talks to the power grid and somehow saves energy in the house, today, you can only sell it to around 30 customers – all big power companies. Each of them will be required to run an extensive pilot before they can get anything through their local Utilities Commission. This means your initial sale will have to be, say, 50,000 units warranted for 10 years. Then after a year installing those units, the power company can propose a rate structure for them The Utilities Commission may nix the whole project, or ask for more research.

GridWise AC makes no assumptions about the structure of the future markets for power. It does not assume that consumers will interact with monolithic power companies. It hopes to enable power users to adopt their own technologies, to let innovators sell product directly, and to attain a higher quality power while it does this.

If we pull this off correctly, there will be whole new industries around the now nimble market. As each home or business can buy from whatever power generator they please, different power sources will get different prices based upon what consumers want. You may have an in-home agent running on your PC, and talking to your home systems. You may have someone else, talking to your home over your internet connection and buying power for you. In either case, you will be buying the power which meets your wants, whether they be driven by economy, or reliability or a whole range of green concerns that might range far beyond the simple “Zero Carbon”.

I am fascinated by the technologies and markets this will engender. Somehow there will have to be a continent-wide NASDAQ of power. Instead of balance sheets, there will be an ontology of power generation to enable our computerized agents to execute our will. Who will audit these systems, both the transactions and the greenliness. Who will develop the interfaces that make playing in this area safe for the non-technical?

As an intelligent building guy, I feel that all of this is helped along by abstract discoverable interfaces to the home and office embedded systems. By policy, I must say that oBIX is the way. Whether that is true or not, I know that it will be a protocol that is able to talk to the building systems, but is itself higher up, where human interactions can occur.

It should be fun.