New Daedalus

Even with today’s rising energy costs, most things do not cost very much. This is a good thing. Food, as a percentage of income, is still at historic lows. In real dollars, gasoline is just where it was at the birth of the modern car in 1908. For most people, switching to a more fuel efficient car will not pay back the initial capital outlay in the next five years. Local energy generation just doesn’t pay back its installation cost quickly enough.

A penny saved may be a penny earned, but today, everyone leaves their pennies by the cash register. Gas prices do not come down because no one wants to make a left turn against traffic to get a better deal. (See also many articles on the front page of Knowledge Problem this week. The New York Times recently indicated that a load in the washing machine might cost $0.53. Who is going to personally manage that? Who is going to miss their $4 coffee on the way to work to reset when the dishwasher runs for this type of gain?

Life cycle does more than lifestyle to determine energy usage. Homes with small children have different energy profiles than empty nesters. Life-cycle trumps life style in energy use except in the most extreme cases. Extreme energy savings are not ever going to be a mass phenomenon. People would rather get to the beach an hour earlier, and get the complaining kids out of the car and in bed on time than they would drive for greater mileage on the trip. These facts are not likely to change.

Well, if we are not going to manage our devices, our systems, and our energy, who will? There are only two answers: someone else and the systems themselves.

Few people want someone else to manage their power, because few people want to relinquish autonomy over their home to someone else. Service is a possibility here. Services like Sensus could remotely monitor my heating and cooling for peak performance, and let me know when and what maintenance is needed. If I approve it, they could even schedule the maintenance themselves, and verify post-repair performance before I pay for it.

This leaves the devices managing themselves. There are a lot of devices, with a lot of features. If we are going to let these devices manage themselves, they need an economic interface, too.

I could ask my dishwasher to run itself, and manage its own budget for the month. I could also set service standards that the dishes always be clean before dinner the next day. This leads to a relatively simple and consistent user interface.

I could tell my solar panel to sell to the grid whenever the price is above a certain amount, and to store any excess energy. The grid might consistently outbid the dishwasher—and that’s OK. If so, the dishwasher would still run only at night.

I could tell my whole-house storage system to buy power at any price until it has four hours on hand. Thereafter it might buy whenever energy is below a target price. I could even let it take bids from the household systems and devices, or from the neighbor. This system would, of course, need to charge an appropriate mark-up based upon its inefficiency of storage.

If we develop the right sort of abstract business interface between the power grid and our buildings, it can also be used between buildings, or within buildings. Most throw-away cell phones have more computing power than it took to go to the moon. Surely, our embedded systems can do a little day trading…

Notes on SmartGrid Domain Experts Workgroup, NIST, August 5, 2008
NIST (National Institute for Standards and Technology) started by making a strong claim for ownership in this area, citing Title XIII, 1305 of EISA 2007. NIST set out an aggressive agenda including a preliminary report at GridWeek on 9/24 and a NIST workshop on developing standards at Grid Interop in Atlanta November 11-13.

NIST wants to have in place tight working relationships with the target SDO’s (Standards Development Organizations) in place before 2009. NIST and the GridWise Architectural Council are working together to direct the standards direction toward e-commerce and interactions with building operations and with the building occupants. Some of these standards will be e-commerce focused, some will be looking to the Building Information Models, and to the energy models they support. I am excited that this might push these design approaches into continuing use during operations.

B2G Breakout (Building to Grid)

We quickly agreed that goal of the SmartGrid standardization efforts is to design the information exchange and informational interoperability to enable healthy markets to emerge around energy use in buildings. Success was defined as enabling buildings to trade their energy.

The group was in violent agreement that we needed to work on business to business interactions, and not on machine to machine interactions. Services inside the building would be coordinated by the business processes of the occupants. Grid messages would go to the business agent of the occupants. Interactions, including pricing and bidding, would be between the grid agents and the building agents.

But market development for what? The problems that need solving quickly include real time pricing and automated demand response. The solutions should encourage the development of distributed generation and local energy storage. The Pricing Models and Buying Models for Energy should also work inside microgrids such as the building or neighborhood.

We spent a considerable time defining the characteristics of live pricing. There was intense interest in moving beyond static prices to curves, i.e., if the prices move like this tomorrow, I will commit to energy consumption in a curve that looks like that. Automated contract execution and on-line exchange of tariffs are both desired.

One thing that everyone agreed is that automated metering infrastructure would never meet its potential unless full live real-time access to all meter information is made available from *both* sides of the meter should be the standard. Parties could then collect the data in accord with the schedule that made sense to them.

This has been about the business exchange – soon I will write about the attributes of these transactions and product differentiation on the grid.

Peter Carbone, Vice President of SOA for Nortel, gave a nice high level talk at the OASIS conference on the challenges facing a company learning to dance in the world of SOA and mash-ups. Nortel, of course, grew up with rigid account control and vertical integration in a regulated environment. As markets for building systems are still characterized by rigid account control and vertical integration, and the power grid is still vertically integrated, regulated, and almost complete account control, there are some useful lessons.

Infrastructure convergence was the enabling and driving change for telecommunications. Provisioning telecommunications was long the most difficult task. Over the last decade, the diverse communication infrastructure converged to a single packet-based infrastructure with resulting dramatic simplification of security and reliability. The questions move from “What low level communications do you need” to “What interactive services do you need?”

This evolution changed how Nortel had to think about and market their services. Before the change, Nortel sold vertically integrated applications that were inflexible. As the core technologies converged, Nortel was forced to decompose advanced services into core functions and then plug them back into the new architecture.

Fortunately, decomposing integrated services into core functions looks a lot like defining a service for service oriented architecture. Fundamental telecommunications functions can now be built into enterprise applications without requiring exotic skills are deep domain knowledge.

Skills-based routing and deployment was one example. Peter discussed a SAP integration with critical system causing expensive downtime, emergency part ordering, and synchronizing communication with an outside expert so that the repair personnel, the piece of equipment, and, via telecommunications and real-time identification of the expert on call, the expert’s telepresence were synchronized.

In a similar vein, he discussed abstracting the GPS function from the cell phone to block access in the security system when the phone was in a forbidden zone. Peter gave many more examples and you can find his slides on the OASIS conference site.

So what can building systems and the power grid learn from this?

Well, the owners expect the systems to just run, and are annoyed when they are expected to learn terms like BACnet or LON (or any other control protocol). We need to decompose advanced services to discover the core functions, from the owner’s and the tenant’s perspective, and present them as interfaces that can be plugged back into the enterprise.

As Peter summed up the C-Level response: “I just spent $100 Million fixing my processes, you had better be compatible.”

Building services that can present themselves as that can interact with SAP, or with PeopleSoft will have an advantage. The services that know how to display themselves on Google Earth will know how to request the nearest technician.

Likewise, Grid requests that present themselves to ERP services will find faster acceptance. Grid requests that describe grid pricing as shapes that can be pinned to Google Earth will enable the enterprise to come up with multi-site responses that may be different from any single site.

No one cares about the old vertical applications. Enterprise interactions are everything.

This is why the Building Service Performance Group at ONTOLOG (just goggle it) is meeting tomorrow.

Building service performance is not handled well during building design because there is currently no accepted way for owners and designers to discuss the services desired and the performance expected for each service in simple general terms. Construction processes deliver diverse technical systems each discussed using concrete physical attributes whose effects are understood through a deep domain knowledge not often common to either owner or designer, or even to different contractors. This leads to specifying materials and processes rather than results, is ineffective in defining success after commissioning into long term operations and maintenance.

New demands that buildings interact dynamically with entities other than the owner and operator will soon require that provisioning of services be managed over the lifecycle of the building rather than merely for procedural completeness at building turnover. These external entities include power provision and emergency management. The transacted power grid will expect buildings to negotiate with remote, local, and internal energy suppliers to meet the needs of the occupants. Emergency Management will expect buildings to respond to environmental alerts, i.e., tornado warnings, to provide situational awareness after an event.

Over at ONTOLOG, several of us are formalizing new semantics to enable discussion of building services and their quality. These words will provide a common basis for discussing service between all actors over the life of the building. They will also provide the groundwork for buildings to interact with actors external to themselves.

If we do this right, these semantics will become the basis for interacting with BIM. Each area of knowledge and practice within the Building Information Model (BIM) has a formal interface to other areas of the BIM. This interface allows information to flow both ways. Information flows into an area to define goals and constraints. Information flows out of an area to provide results and requirements. This allows for multiple processes within each area. During design, the goal is to let the owner participate in decision earlier in the process. Imagine the following scenario.

During design, a six story building is designated as commercial space on the ground floor, a restaurant on the second, and office space for the next 4 floors. Quality indicators for all three types of space rely on the Effective Ventilation Index (EVI). Commercial Comfort Index is defined based upon room temperature, humidity, occupancy, and EVI. The standard for a strip mall is 1.0. The lessee, a high end store, requests that a CCI of 1.2 be provided, and documented by the underlying systems, and that it be done at a watts/square foot no worse than industry standard. The restaurant is divided into seating area, which uses the standard CCI and the catering area, in which a higher EVI is required by regulation. In the seating, the CCI must take into account the higher density of sitting customers as compared to the retail space downstairs. Office space is quite competitive and the local market has high vacancy rates. The owner wishes to promise Office Worker Alertness index greater if 0.8 (prevailing standard is 0.64) to achieve reduced vacancy in the prevailing market.

I shared this vision with Bo, a seasoned real estate professional who remains one of my more skeptical audiences. He vigorously objected. To Bo, a developer might choose to distinguish itself though having many more air turns per hour than the competition. They would still want to discuss the value in the same terms, but would not wish to be held to the same engineered standard of comfort. Bo vigorously objected to a mathematical standard for the comfort index….

This threw me for a loop. Then I recalled some spirited discussions from the Business Process Execution Language (BPEL) groups. BPEL is the language for passing a work flow or business process around using web services. There have been spirited discussions about BPEL, including conversations that claim that BPEL is not useful because business process is the proprietary advantage of any business, and so therefore real business process will never be passed around. This seemed to align with Bo’s comments.

Let me reprise semantics and ontology how I use these words. Semantics are the words used to describe things. When similar things get the same name, we are making semantic decisions. As people, semantics let us discuss the services provided by a system, and to compare and contrast how well those services are provided. To systems, semantics create a basis for interoperability and the creation of Services. Ontology, or meaning, is a way to discuss a value of the services; ontologies are variable. Crudely, accounting is a semantic system; cost accounting and financial accounting are different ontologies built upon common accounting semantics.

If we take this model, than I agree with Bo. The concrete basis for value in building services require a common semantic framework. At the highest level of abstraction, these services slide into ontology, where the building operator defines value. The building operator, or even the building designer, must be able to define value, to define the construction of the top level semantics.

And that is the swing between building service semantics and building service ontology.

I had a very nice conversation with Bob Smith of Tall Trees yesterday about building services. Bob is one of my co-conspirators launching the Building Service Performance ONTOLOG group. Bob had just submitted the laundry list of check-offs developed by the City of Irvine for its construction process to the ONTOLOG discussion.

I was both happy and disturbed to receive this document. These check-offs clearly drive the contracting process, They are also inherently backward looking, enshrining the best practices of yesterday as we move forward. The best practices of yesterday are better than the normal practices of today, but can be the enemy of better practices going forward. They trade innovation for good enough.

The ONTOLOG (just google it) project is to define an ontology of Building Service Performance. The problem we are trying to resolve is that while people want specific services from their buildings, we always specify technologies or systems, which is something quite different. Buildings may be providing alert students, productive office workers, or regulated environments to store labile chemicals. By discussing the services rather than the systems, we can

• Allow earlier discussion of / decisions on building goals in keeping with buildingSmart approaches
• Move conversations about building performance to the business level where commercial building owners will get interested (we want to provide healthy office space metrics in the upper quartile while staying within energy use goals).
• Commissioning then gets re-defined in terms of service performance effectiveness rather than in terms of system operations, a much more useful measurement.
• Commissioning numbers that look like B are simple enough to get built in to the sales and leasing processes for commercial buildings, enabling owners to monetize improved performance.

Check off lists such as Bob provided are the opposite of this approach. Nonetheless, I agreed to try to dig up two other documents that are contrary to the goals and thinking of the new group.

One such document is the original list of nearly 50 vertical control system markets that we came up with as oBIX was launching. These systems are specified in buildings now, but only rarely with any sort performance or business deliverable tied to them.

The other document I am trying to come up with is a comprehensive list of ICC (International Codes Council) domains. It struck us during conversation that many of the ICC areas deal with avoiding the failure to perform these services. While we are trying to twist these services around into a new ontology, a list of all the services which must not fail to be provided would be useful.

I have found neither list yet. If you think you have one, please send it along.