When the smart grid concept began to take hold in 2007, the automation of demand response was typically the first example used to characterize the extent of change possible within the energy industry. Now that over thirty-four million smart meters have been deployed, I thought I’d revisit the topic of demand response from a technical perspective, particularly standardization activities.
The advancement of demand response solutions is driven by three business models: deployed as an independent power aggregator serving commercial entities, ISO ancillary service or enabling a utility to better manage their peak period usage. For the first two demand response scenarios, the infrastructure and technology selected is constrained only by the ISO’s inter-connection guidelines leaving the how aspects of the implementation open-ended. Implementing a demand response solution that involves smart meters requires following a more comprehensive set of standards.
Zigbee Smart Energy 2.0 Profile
NIST oversees the standards which define interoperability between smart grid devices and services. The messaging standards currently in place that services communication between the utility and a premise are ANSI C.12-18 and ANSI C.12-19 (a.k.a .AMI). And the premise services are delivered over a highly secure Zigbee-based network. The Zigbee Smart Energy Profile defines a full life-cycle services framework for deploying premise-based smart grid applications. The Zigbee Smart Energy Profile specification defines the security model, device commissioning and multiple messaging sets for managing devices.
Smart Energy Profile (SEP) 1.1 supports demand response services through its consumer price response features. ANSI C.12-19 is used to propagate the pricing information to the smart meters and a Zigbee-enabled energy service portal, located within the premise, extracts that information from the smart meter. The energy service portal (ESP) then oversees the load management based on a set of home owner defined options but no load specific information is reported back to the utility, that’s directly associated with the price response decisions.
The Zigbee alliance, as a result of ongoing NIST standards development discussions, agreed to re-tool the Smart Energy profile to support a more unified device messaging methodology that streamlined communication with devices outside of the physical Zigbee network. Smart Energy Profile 2.0 which I’d like to encourage to be also thought of as a services framework does just that. The messaging between devices under SEP 2.0 is URI-based, IPv6 friendly and includes a set of schemata for defining data exchange.
The initial concept behind Zigbee was to provide a highly reliable wireless communications medium for low powered embedded devices. The standards focused heavily on power management (i.e. minimizing battery drain), limiting CPU resource requirements and minimizing memory usage across all aspects of the Zigbee communication and services framework. The digital certificate implementation and encryption methods used within the Smart Energy Profile are good examples of adhering to these design principles. Please refer to my Zigbee Security and Certificate article for more detailed information.
In keeping with the initial design principles of Zigbee an efficient method was needed to transport the larger URI-based messages over the Zigbee network. SEP 2.0 uses the recently adopted Efficient XML Interchange (EXI) standard for serializing the XML messages. Constrained Application Protocol (CoAP) may optionally be used to reduce the bandwidth consumption of RESTful messages when traversing the Zigbee network. For Smart Energy 2.0 application developers, the EXI and optional CoAP support changes will be transparent except for the implementation of the new SEP 2.0 URI messaging requirements. These new features will be provided through the chip vendor’s Zigbee software stack.
In 2011, upon the availability of SEP 2.0 devices, the smart grid ecosystem could be kicked into high gear. While not a seamless network integration, SEP 2.0 offers a generalized messaging framework for simplifying the integration of energy related applications with a broader set of consumer devices such as Android tablets and iPADs. This assumes the availability of home energy gateways that maintain security and provide Ipv6-to-IPv4 services.
The broadband infrastructure market appears to be showing greater interest in offering Ipv6 services, too. If Comcast’s Ipv6 technical trial results are encouraging and gateway vendors can be convinced to implement native dual-stacks – as Comcast is attempting to promote – this will further simplify the deployment of Internet-based services that inter-operate with SEP 2.0 applications. Providing another positive market enabler for SEP 2.0-based applications.
SEP 2.0 applications, unlike SEP 1.1, are not as tightly tethered to AMI. In contrast to the looser coupling of SEP 2.0 to AMI, a number of utilities are settling on a dual network smart grid model where authentication, control and monitoring information are carried exclusively over their private AMI-based networks and Internet connectivity is strictly for account reporting. Are the changes in SEP 2.0 going to change this trend?
An example of a possible evolutionary path is supporting the Internet-based service that California’s Lawrence Berkeley National Lab Demand Response Research Center (DRRC.) has developed. The standard known as OpenADR provides an automated demand response service. The initiative is funded by the California Energy Commission (CEC) Public Interest Energy Research (PIER) program, in collaboration with California Investor Owned Utilities.
OpenADR defines a set of standards whose scope spans from the ISO down to the consumer. The broad scope of OpenADR, I find, also makes it bit of a challenge to grasp initially. OpenADR is both an industry initiative and a set of standards that support market-wide load control, price response and demand bidding services. Over the last year, three events occurred that were significant in enabling the adoption of OpenADR to move beyond California’s state boundaries:
- OpenADR donated the specification to OASIS. The specification is being incorporated into the OASIS Energy Interoperation (EI) specification.
- Formation of the OpenADR Alliance. Their mission is to facilitate compliance through development of an ecosystem providing OpenADR testing tools and certification programs.
- Honeywell acquired Akuacom who are leading the OpenADR client development program. The client program consists of over sixty vendors.
The OpenADR infrastructure is based on a client-server architecture. A Demand Response Automation Server (DRAS) is installed at either the utility or a power aggregator and a client system is installed at the premise. The client system polls the DRAS to determine what actions, if any, it must take to shed load at the premise. This approach was taken to preserve the Internet network access control at the premise.
The bringing together of SEP 2.0 and OpenADR client support is an interesting topic to explore. For example, having a standardized demand response service that targets small and medium businesses (SMB) and warehouses using Zigbee-enabled multi-zoned temperature and lighting systems could be a target market of mutual interest.
Harmonizing the inter-operation of SEP 2.0 Demand Response and Load Control, Messaging and Pricing clusters with the features of the OpenADR client, as defined under OASIS EI, could be path to these new markets. SEP 1.1 because of underlying technology differences would be seen as too much of a challenge.
IPSO Smart Objects
The IPSO Alliance is taking a slightly different approach to bringing the worlds of wireless sensor networks and the smart grid together. They created the marketing moniker Smart Objects for referring to embedded wireless devices in general. And to accomplish the end goal of providing reliable and diverse device interoperability, the IPSO alliance is fostering a highly collaborated set of standards that are platform and network infrastructure neutral. The organizational connection between OpenADR and IPSO is through OASIS.
The IPSO Alliance members are diligently discussing how to best converge on a set of best-of-breed: standards for routing Ipv6 over wireless sensor networks, defining well a structured information model for all-the-Internet-things, unifying the serialization methods for XML and HTTP, and implementing an efficient security and commissioning model.
These standardization activities will ultimately lead to the creation of highly vibrant and diverse automated demand response market. OpenADR are fostering the expansion of automated demand response using web technologies within the regulated electricity transmission and distribution markets. The wireless sensor network market alliances, highly experienced in serving the unregulated industrial and consumer markets, are tackling the end delivery model.
General: EIA Peak Demand Information, OpenADR Organization
Specifications: OpenADR Version 1.0, OASIS Energy Interoperation Version 1.0, DRAS Client