Smartgrid Basics: The Demand Side Problem

Last week the Smartgrid-discuss group opened up within OASIS, introducing power grid technologies to the architects of e-commerce and internet security standards. Some of the latter are trying to understand the problem, and learn the jargon. I wrote this as the second of a series of posts introduce the issues in a simplified, almost cartoon form.

Building systems have traditionally been invisible and uncontrollable. They have been managed to reduce costs with no real focus on the service they are providing. They have grown up in sandboxes, using their own peculiar protocols. These protocols are deep and technology specific, and often without effective interface. These systems are operated, when they are operated by process specialists.

Building occupants rarely have a precise understanding of how these systems affect their business. They may know exactly what a too-hot or too-cold call costs. They know that tenant dissatisfaction may lead to un-renewed leases. They may suspect that under ventilation may lead to sleepy occupants, but can rarely put any exact price tag on that. This makes them conservative about making changes in building operations.

Demand Response (DR) is emerging a critical tool for dealing with peak load management. Peak loads are by far the most expensive and dirtiest electricity we have; their costs, on both bottom lines, swamping others. Demand response is moving from direct control to economic incentives, but underneath, today’s integrations are process centric rather than service oriented. Energy providers order or pay energy customers to turn off things on just a few days a year, to manage the peak. We encourage only the crudest, least effective energy savings, while denying the market the energy signals that would cause better.

At the commodity system level, DR is already moving to services and agents. Agents defend their own mission while responding to the outside world. Washing machines know not to respond to grid signals until they determine that the current laundry is not soaking in bleach. Refrigerators know not to respond if they have just finished a defrost cycle. These systems know and understand what services they provide and so are ready to be responsive. Building systems are not.

We will get larger DR when we talk to the building occupant. We will get better participation when the occupant remains in control. The occupant will not allow DR when the in-laws are coming for the weekend. The occupant knows the family overspent at Christmas and is willing to respond to any and all incentives. The access control system may know that only three people on the fourth floor came to work today. Human resources knows that the sales force is on a retreat. Together, they can choreograph far greater response from the building systems then ever will be permitted as an automatic response from control communications.

Demand Response must be about economic signals to a business entity. When thought of in this way, there is no need for different signals to Industry and to Business (and to home and to vehicle). The business may choose to automate this. The business may benefit from templates for response, whether developed by EPRI or by ASHRAE, which reduce the risk of considering participation. These choices and these templates are not part of the interface.

The interface should not does not concern itself with the underlying technology and control protocols. It should not be based upon BACnet, or OPC, or LON any number of other low level control system protocols. The interface must be one that enables business decisions. Control systems should offer up service interfaces for choreographed response. Whatever offer and counter offer DR requires, whether amount of load shed or maximum load used or time to respond must be in the interface, but no deep process.

The smartgrid to building/industry/home interface is about how the Service Oriented Building can respond to the Service Oriented Grid. Just as in other services, the underlying processes should be hidden.

If you want to join the public discussion at OASIS, send a message to smartgrid-discuss-subscribe@lists.oasis-open.org.

Whither Grid Standards

On last Friday’s phone call about advancing the OpenADR specification to a national and perhaps international standard, we agreed to continue the discussion in an open forum at the OASIS site (www.OASIS-Open.org). OASIS, or the Organization for the Advancement of Structured Information Standards, has long been the home for the underpinnings of e-commerce, for web security, and for service oriented architecture. OASIS is also home to a number of domain-specific standards, such as LegalXML, Open Office, and OpenDocs as well as the foundational web services registry UDDI (Universal Description, Discovery, and Integration).

OpenADR (Automated Demand Response) is a California developed specification developed for the regulated electricity providers in that state. Demand-Response (DR) refers to live negotiations between the grid and its end nodes (buildings) to reduce demand before a shortfall causes problems. DR is a very important first step on the road to transacted energy, and solves some big problems in the short term.

One effect pulling OpenADR to OASIS is a perception that it is largely an economic transaction. The end nodes of the power grid contain far too diverse a mix of systems for grid operators to control well. As Gale Horst, who works in the Whirlpool Corporation Research & Engineering Center, has observed, a washing machine cannot respond to a grid request to shed [electrical] load unless it determines that the grid unless it has determined that there is no bleach in its current load of laundry. Every system in a home or business has similar rules that matter within its own domain. For all but the smallest response, DR will require an economic incentive and decisions from the agents running all the systems.

Even before OpenADR began discussions within the OASIS framework, a number of standards potentially useful to the new intelligent grid were underway. oBIX created a specification normalizing the operations and reporting of control systems as web services. The WS-DD and WS-DP committee, standardizing web services for device discovery and device profiles, includes members not just from software and printer makers, but from a maker of electrical switch gear as well.

There may be several of what I call micro-specifications that come out of this. As far as I know, there is still no standard way to exchange scheduling via web services as there is ICALENDAR in email. Such a specification would be useful not only for transmitting schedules from OpenADR to building systems managed by oBIX, but also would be useful in forward pricing of power generally. It would also be useful in a number of other standards, such as BPEL (Business Process Execution Language).

Emergency signaling is an important area or work within OASIS. One critical area is standardization of location. These standards include addresses, geographic points, and geographic territories bounded within a closed polygon. DR specifically, and utilities in general need the same information. When a DR aggregator reports the commitments he has received up to the System Operator, the operator would like the information aggregated by territory. New standards for emergency communications anticipate buildings submitting alarms directly into 911 queues. Components of the power grid could do the same, notifying police to increase patrols in blackout areas and to send officers to direct traffic. It would be very useful for the power grid and for emergency response to use the same standards.

New business models will encourage a move from hierarchical command and control operations to symmetrical peer to peer negotiations on the power grid. Renewable energy sources will decrease reliability. Distributed generation will create more power sources not under the control of traditional utilities. Zero Net Energy buildings will make each end node both a buyer and seller of power. OASIS standards such as WSDM (Web Services Distributed Management) may find a place in the new grid.

The panoply of WS-Security standards, including federated identity management, would require more room than I have here – but OASIS is their home.

There is no replacement for the IEEE and IEC standards at the core of deep control; increasingly, we will have interactions that are more arms length and economic than that.

To join the smartgrid-discuss@lists.oasis-open.org list, send email to smartgrid-discuss-subscribe@lists.oasis-open.org. The list is open to all, and there is no commitment to join OASIS or participate in a technical committee implied. For a general discussion of applying e-commerce standards to new energy, you may be interested in reading http://www.oasis-open.org/resources/white-papers/blue/

The Sound of Breaking Glass

I love the sound of breaking glass
Deep into the night
I Iove the work on it can do
Oh a change of mind
Oh change of mind, sound of breaking glass
All around, sound of breaking glass
Nothing new, sound of breaking glass

Nick Lowe

Security in the built world is most critical at precisely those times when the demands for performance and interaction are greatest. Buildings may lose their communications with the outside world when partially destroyed. The power grid may require ad hoc reconfiguration when its communication lines are down.

The built world traditionally has found security in isolation. Building Control Systems are isolated in a mechanical room and not plugged to the internet. Fire system annunciators are often limited to one-way communications. Access is often all or nothing, with many systems secured only with the default account and password from the manufacturer.

If a system is all or nothing, then it has little need for nuanced identity management. In traditional building monitoring systems, pretty graphics sell the system, but operators look primarily at tables of values. Without service definitions, the systems rely on operator knowledge to put the pieces together. Without service definitions, monolithic security is the only choice.

Considering the requirements of using building systems for situation awareness during emergency response can lead to the wrong conclusions. The mind leaps to all-out conflagration, wherein all security should be cast aside to allow the fire department unfettered access. Yet emergency response also includes the arrest of the lurker on the third floor, and the minor spill of chemicals in the manufacturing wing, and the ambulance responding to the heart attack in the secured executive suite. In many scenarios, the responder will be granted limited access, for limited times, to only a portion the available sensors and surveillance cameras.

Power systems have different requirements for emergency security. The intelligent grid will both support and require reconfiguration more readily than it does today. Distributed generation raises the real possibility that both sides of a downed power line are hot, increasing safety risks during emergency repairs. Improper interactions with the downstream systems can incur liabilities for equipment damage, equipment not owned by the utility and not professionally monitored.

Infrastructure emergencies often coincide with reduced communications. Reduced communications can disable federated identity management, or even single provider single password checking. Many systems handle this problem with forward caching; user accounts and identity tokens (passwords, biometrics, et al.) at the access point. For example, a campus access control system might forward cache the keys of all residents of a dorm, enabling the door to make mostly correct decisions even when disconnected.

Forward caching fails at precisely those times when the emergency is greatest. During the night with four fires, the fire department from the next county responds to the building. After the great ice storm, line crews from three states away are restoring the substation. During the worst fire, the battery in the incident commander’s PDA fails, and he switches to an unregistered device. The tightest, best security fails when you need it most.

Medical systems define what is called a “Break Glass” incident. Break Glass might rely on a standard account and password, one that might never change. By using the Break Glass password, the system is alerted to log fully every action taken. Break Glass incidents also trigger an audit alert. Post incident audit might require, for example, an explanation of the event, as well as an administrative review of all changes made to the system.

I think both building systems and energy systems, including SCADA for Transmission and Distribution can make use of the practice of Breaking Glass.

An Evolutionary Composite Services Framework for Energy

Future energy systems must not only support interoperability on operational, e-commerce, and security levels, but they must do so against a background of innovation. New technologies will arrive from innovators who are not traditional energy participants; it must be easy for these innovators to introduce their products and easy to integrate these products into the intelligent grid.

New business models, especially support for distributed generation and the hybrid technologies such as the zero net energy building, will demand new interfaces. These business models require symmetry, with each participant both a buyer and a seller of energy. Cost effective local energy storage will create new interaction patterns that we cannot know until we create the incentives that encourage market adoption. One thing is certain, the interface between the intelligent grid and buildings and industry will be different tomorrow, than it is today, and different still in another year.

Electric cars will have a significant position in our society far before we have worked out the market mechanics. The market mechanisms will extend beyond the simplistic “all cars will charge only in the middle of the night” to support on-demand rapid charging and selling stored energy back to the local home, business, or utility. The final market must support social scenarios such as holiday travel and new businesses such as the renewable energy parking deck. Again, we will face rapidly evolving interfaces for the near future.

We can most easily meet these challenges by creating a composite framework that supports diversity. These services will support the different types of business interactions surrounding the intelligent grid. These include but are not limited to:

• E-Commerce services to define the two-way buying and selling of power
• Capability and Capacity services to negotiate how much power is available at what quality irrespective of the underlying technology.
• Weather and similar services provide situation awareness to buildings and grid operators. Weather is critical to predicting energy consumption as well as to predicting renewable energy generation capacity. Situation is awareness is just as important to building and industry participants in new energy as it is to central generation and transmission facilities.
• Tariff and Regulatory interfaces, whether for long transmission, or for carbon negotiations, will guide energy markets beyond mere electrons.
• Security Services to control operations and protect privacy.
• Safety Services to provide situation awareness to linesman responding in emergency and other scenarios.
• Operations Services, supporting either third party operation of site-based generation capacity, or site-generation as a forward deployed utility asset.

Each of these seven interfaces will evolve over time. A user of one service may care little about another. As services become the basis for system-to-system interactions, keeping each service separate simplifies interaction patterns so each can evolve rapidly.

Rapid evolution and deployment are critical to new energy plans, particularly if we are to meet ambitious goals for more renewable energy, more distributed generation, and more electric cars. E-commerce and Security services can be based upon existing IT standards. Operational Services, where appropriate, can be based upon existing standards for substation operations. Weather services can be developed in different venues through the work, perhaps, of NOAA (the National Oceanic and Atmospheric Administration). Composite services will speed the development and deployment of the smart grid.

Composite services will also disconnect the different business processes from changes in other areas. Each business process is concerned with only a single service on its partners. As that service definition evolves over time, newer system will need to interoperate with version-based diversity within domain, rather than in all domains.

Energy systems are big infrastructure. Big infrastructure lasts for a long time and touches many things. Scale introduces diversity if installation. Innovation introduces diversity of interaction. Long life introduces diversity of versions. An Evolutionary Composite Services Framework provides the best platform for providing function and performance despite these three sources of diversity.