It’s not Use Cases, it’s Interaction Patterns

The NIST B2G efforts so far have annoyed me like an itch I cannot quite scratch. The B2G (Building to Grid) group is trying to collect applications and use cases, to create the desiderata for the new interface standards. These are the traditional ways to characterize known systems. Certainly even distinguishing the two can be a strain, although practitioners may prefer one over the other. And yet there is that annoying itch…

This morning over coffee I realized that it is because we should be talking service instead of procedure.

One of the truisms of Service Oriented Architecture (SOA), is that it is nearly impossible to implement a SOA in a Procedure Oriented Enterprise (POE). (POA is the "antonym" of SOA, only discovered after SOA existed, in a manner similar to the term Analog Watch only being discovered once we had digital watches). It is easy, relatively, to implement SOA in an organization in which each department and each departmental system knows what its purpose is, and what its effective business metrics are. Such a well understood business can be referred to as the SOE.

A standard SOA talking point is the virtual company assembled entirely from the Services provided by others. Virtual companies are almost inherently SOEs. Many of the new markets I can imagine seem more like virtual companies than they do like the process-oriented companies that make up today’s energy markets. We should be thinking service.

We need to focus on interaction patterns, the approach at the heart of service integration in the e-commerce side of web 2.0. To enable the new markets that most of us hope can arise from these efforts, we need to shift from thinking in terms of request-response and buyer-seller-shipper interaction scenarios. The patterns we must document here go beyond simple bilateral interactions, to include multilateral, competing, atomic, causally related, and routed interactions, and should allow for any number of long-running business processes.

The new smart grid, and the new economies of Zero Net Energy Buildings (ZNE) will involve the discovery of and interaction with services. These service will be involved in energy generation, storage, and conversion. These services will be diverse and multi-party. These interactions will not be procedural.

Now that I have my head on straight, I hope to submit interaction patterns required for new energy markets soon. But I thought I would give everyone a heads up on what I think is the real task.

Ontological requirements of the service oriented grid

We will be unable to scale out the integration of the power grid on a continental scale, to support the diversity of systems currently installed using process oriented integration. We must support even more diversity, from technological innovation as well as from business innovation to achieve the new markets in energy today’s challenges require.

While simple demand-response capable systems provide great aggregate value to the grid, the small-scale benefits they offer seldom make a compelling interest to the home or commercial building occupant. This limits new energy scenarios to small advantages that can be achieved by static regulation. If we enforce participation through regulation, we will only harvest the lowest of hanging fruit and encourage cheating and “malicious compliance.” To do more, we must increase the value proposition for building and home owners. This means either decreasing the costs of integration, offering more value for integration-capable systems, or both.

Service oriented coordination is opens up new avenues for energy re-allocation and conservation in the home and business. Service orientation solves the diversity of systems challenges while providing the building owner/operator with new means of controlling power use. A key challenge to establishing such services is common semantics to enable conversations about energy use and system performance. If properly defined, these semantics enable the owner to recapture investments in performance and interactivity through non-operations business processes, reducing the barriers to adoption.

The energy grid itself must acknowledge its roles as a service provider in the systems architecture of each building owner and operator. To be a full participant, business negotiations between building and grid must beyond availability and burn rate to a fuller model of cost, and scarcity, and projected reliability. To create discoverable markets in power, power source semantics must be mappable to ontologies of value that are relevant to the energy purchaser. In other words, we must move beyond mere price signals of demand-response. The integration client must be able to decide whether to make or buy based upon projected quality and reliability. Markets that allow the building to discover and negotiate with power sources must also enable the building to negotiate for which kind of energy sources.

 Electric cars and their batteries are popularly cited as a solution to problems of peak shaving and energy demand smoothing. Wholesale adoption of electric cars would instead increase peak demand volatility in many scenarios. To achieve the hoped-for benefits of electric cars, drivers, automobile producers, and the power grid must develop a common vocabulary for use in the acquisition, storage and use of power. This semantics will be critical to the e-commerce underpinnings of electric car adoption.

 To achieve full realization of the potential benefits from the new energy technologies, we must move beyond process oriented interactions to service orientations that accept diversity and enable technical as well as business innovation. These approaches will require the development of ontologies around building-based and grid-based services so that each can be full participants in enterprise and consumer interactions.

Connecting the Services to Value

There is a fundamental disconnect concerning the systems that manage building performance between what the system integrator can do and what the owner asks for. 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. Our construction processes deliver diverse technical systems each discussed using concrete physical attributes whose effects are understood only by those with 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. This is ineffective in defining success after commissioning and into long term operations and maintenance.

New demands that buildings interact dynamically with entities other than the owner and operator will demand better. The provisioning of services will be managed over the lifecycle of the building rather than merely for procedural completeness at building turnover. Three of these external scenarios are emergency management, remote analytics (to support knowledge-based maintenance and operations), and interactive negotiations with power providers.

By formalizing new semantics to enable discussion of building services and their quality, we can create a common basis for discussing service between all actors over the life of the building. The semantics will also provide the groundwork for buildings to interact with actors external to themselves.

As Adam Werbach writes, the new sustainability is about how to harmonize human culture with our relationship to the living world. Building performance, and building value, includes occupant health, and worker productivity, and not mere energy performance. , then energy performance, as well as other values such as occupant health and worker productivity

As I have noted before in this blog, we will be able to recognize success when building owners adopt these semantics to express their own concepts of value in buildings. Tomorrow’s leasing agent will use the semantics of building service performance to distinguish his properties from others on the market. Commercial real estate brokers will incorporate these measures into the CIE (Commercial Information Exchange); the measures will be reflected in commercial real estate prices.

At that point, no regulation or moral suasion will be needed at that point to drive better buildings.

Busy day on the Standards Front

Today was consumed with what is either standards minutia or very big stuff. I am too tired to write of anything else, so let me explain what’s afoot.

Scheduling

Building system schedules today are too involved, and require too much process information. If I want to meet at 9:30 tomorrow morning, I want the room air-conditioned and ready to go by 9:30. I don’t want to learn about heat times, cool times, warm-up times. Be ready. By 9:30.

The enterprise standard for scheduling was developed years ago for use in email and its name is vCalendar or vCal. vCAL can not only schedule that meeting tomorrow, but can schedule it every two weeks, or on the second Thursday of every month, or even every two weeks except in a month that has three Tuesdays. vCAL has all the flexibility one could want.

vCAL was refreshed for internet transmission and stand-alone download into the internet calendar standard, or iCalendar. When you book airline tickets and it says “click here to add to your calendar”, you are using iCalendar. Apple muddied the water by writing the program iCal to use ICAL, but it us really the stand-alone version of vCal.

In early 2001, an attempt was begun to define iCalendar in XML, xCalender. As far as I can tell this project stalled out in 2002. oBIX has been meeting for some months to integrate xCal into scheduling system scheduling.

Today, I received the suggestion that I look at hCAL instead. hCalendar (short for HTML iCalendar) is a Microformat standard for displaying a semantic (X)HTML representation of iCalendar-format calendar information about an event. hCAL is designed for display, but it has a socket in which to nestle additional XML information. This seems nicely pre-adapted for oBIX, as well as DR (demand response) events. hCal was designed to allow parsing tools to extract the details of the event, and display them using some other website, index or search them, or to load them into a calendar or diary program.

Today, I am trying to get oBIX to make decisions as to how to use viCal, to share that decision with OpenADR, and to move on.