New Daedalus

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.

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.

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 vixhCal, to share that decision with OpenADR, and to move on.

The University of North Carolina’s Enterprise Building Management System (EBMS) is an innovative open system for managing energy use and operating building systems. It hides the diverse brands and control protocols of the buildings, keeping each safely contained in its own building sandbox. All communication with these systems is by web services, the basis for modern internet e-Commerce. All systems communicate primarily with a central system that programs each building.

In many ways, rather than doing things a new way, we have perfected the old. Instead of many consoles, one for each bran, we have one. Rather than specifying a single brand of building system for compatibility, we can select the one that performance requirements and competitive bidding indicate. Because all data is now normalized and kept in an standard database (it happens to be MSSQL), we can use standard tools for reporting and OLAP.

But we didn’t change that much. They say you go to war with the army you have, and not the army you want. And you go to bid with the technology you have, and the specs you have, not the technology you want. Push the technology and business processes too hard, and no one bids. Someone told one of our executives that XML was a fad, so we were forbidden to even mention it in our bidding documents. The entire building controls industry still has a poor concept of security, so allowing open access to systems is still a problem.

All things considered, EBMS is a remarkable project, one that pushed the state of the art. But it could have been better.

We should have pushed the performance abstractions down to the Local Gateways (EBLG). Rather than shedding load centrally, we could have been able to send a command to each building “LoadShedLevel3”. We could have submitted a web services request to the building, “StayInOccupiedMode” “8:30pm”. We could require the facility system integrator to define these contracts t comply with performance expectations. This would have prepared each building to have enterprise interactions beyond central monitoring and operation.

This would have defined a realm wherein enterprise programmers with enterprise skills (and not building skills) could operate the buildings. Building gateways would become building agents, and maintain responsibility for performance.

Today the EBMS is REST, meaning simple URLs define all interactions. SOAP would have let us better prepare. Transactions may need various levels of security. Today we encryption and firewalls. I want signatures, and roles-based security, and delegation. I want guaranteed delivery and non-repudiation. I want to be able to store decisions and authorization to run contracts, with signatures, in a business process (BPEL). When the business process arrives, I want the pre-authorized contract to be issued.

In short, I want enterprise interactions.

I was part of a round-table on Demand-Response in data centers last week. Demand-Response is the strategy used by the power companies to trim peak load, the load that degrades into brown outs on a hot summer day. Demand-Response can include options from forward agreements to get a better price to live bidding to give up power, depending on the regulatory and market environment.

Missing from much of the discussion it was any real focus on marshalling and allocating all the resources available to solve business problems. As a government employee, I felt right at home: cost, cost, cost, when the discussion should have been value, value, value.

Modern management practices in the data center are concerned with optimizing the conversion of compute cycles into raw business process. In the world of blades and virtual machines (VM), concerns with servers are replaced with business process throughput, and trading schedules to improve service levels.

Concomitant with this is the most efficient direct conversion of electricity to heat ever devised. Heat disposal becomes paramount. Support infrastructure, whether additional cooling capacity or electrical capacity is rarely managed at all. Corporate resources are thrown away because excess energy is treated as a waste stream.

The best data center management is always trading off business resources to meet business service level agreements (SLAs). If transactions through the middle tier supporting sales transaction take longer than, say, three seconds, customer will begin to abandon transactions. Using blade servers, a new VM is quickly provisioned to supply the needed compute power. If there is no payroll this week, transactions supporting human resources can be delayed, a VM shutdown, and a new VM provisioned for sales transactions. The modern data center is managed for business process delivery, not for computation.

Under this model, Demand-Response is simply a new business cost, a new service trade-off. Demand-Response is simply a further management of the same business process in the same way as everything else. Based upon cost, some business processes are slowed down, or even transferred to another data center in another part of the grid.

I guess what I am arguing is that if you manage your data center properly, Demand-Response is just another business event, and not a unique one. Oh, and make sure your back-up data center is on a different grid.