Tom Ashbrook, NPR’s On Point host, interviews and presses guest, Nathan Lewis, Director of Caltech’s Joint Center for Artificial Photosynthesis (JCAP) to describe what the clean energy generation market would possibly look like in 2035, if the goal were met. The JCAP center was awarded a $122 million DOE grant, last summer, to establish an energy innovation hub. One of its key research objectives is to derive liquid fuels from sun light in the form of either hydrogen or methanol.

Steven Mufson, energy correspondent for the Washington Post, provides counterpoint by the touching on the political barriers, lack of consumer incentives to induce change and power of the “cheap energy” soundbite card frequently played by politicians, as the means to re-energize the U.S. economy — or, to stall change within the multi-trillion dollar energy industry. David Cash, newly appointed Under Secretary for Policy serving within Massachusetts Energy and Environmental Affairs Office, then calls in to discuss Massachusetts’ clean energy market growth.

Key points raised during the show are:

Cheap energy storage technology is essential (“He who cannot store will not have power after four.”)

In beginning to gain an understanding of the Zigbee Smart Energy (SE) security framework, it’s helpful to draw analogies with the existing Internet security model: SEP uses certificates similar to SSL certificates and digital keys similar to those used in provisioning VPN connections. The implementations are quite different – due to the unique characteristics of the embedded devices — but conceptually the usage is very similar when compared to the Internet security model.

Certicom, a wholly own subsidiary of RIM, is the name of the company that registers, generates and validates Zigbee Smart Energy digital certificates. Certicom’s role within the Zigbee ecosystem is similar to Verisign’s role in the securing Internet-based transactions; They are “the” trusted registration agent for authenticating Zigbee Smart Energy messages. The certificates provided by Certicom are used for both data encryption and authentication.

The method of certificate authentication and construction is slightly different than the Internet security model. Unlike the Internet, where a web browser connects with Verisign to validate the digital certificate it download from a website, in the SEP security world the public key is piggy-backed with the certificate and encrypted. It’s referred to as an implicit certificate. The entire certificate is also encrypted differently using an algorithm called Elliptic Curve Cryptography (ECC) that’s embedded device-friendly. Since each device has a copy of the public key installed within its own unique certificate, this can be used to authenticate the SEP message or payload. The authentication is not actually done certificate-against-certificate but during link key establishment with a node’s immediate neighbor.

Zigbee secures the networks using two types of keys: link keys and network keys. Network keys are used to encrypt the SEP data (i.e. customer specific data) or payload that’s traversing the Zigbee network. Whereas the network key encrypts the payload, the link key encrypts the entire message being exchanged between neighboring devices. And for every pair of neighboring Zigbee device connections a unique link key is derived and used to encrypt the traffic. A Zigbee device attempting to establish an initial communication link to a neighboring device will fail if the certificate is invalid. Zigbee devices processing SEP messages will also not route packets that cannot be authenticated against its own certificate.

To support interoperability with any SE certified Zigbee device, the bridge between the utility’s backend provisioning system and a SE HAN (Home Area Network) is through the HAN’s trust center. In most cases, the trust center function will be embedded in the software that drives the in-home device provided by the utility. For any Zigbee device to attach itself to a SE HAN it must first contact the trust center. This done using a well known address (i.e. 0x00000000.) The device will only be able to establish communication with the trust center if it contains a valid certificate that’s honored by the utility. Otherwise its attempts to connect to the network will timeout or be rejected.

Hence, if you independently purchase a Google PowerMeter-enabled device that’s Zigbee SE certified it’s not guaranteed to start communicating with your utility-provided Zigbee equipment. It has to, at a minimum, contain a digital certificate that’s honored by your utility. Particular to Google PowerMeter – if you wish to also monitor your energy usage using a Google PowerMeter account – is the requirement for the device to register over the Internet with Google’s PowerMeter servers. Google solved this problem by providing a utility version of Google PowerMeter that uses a non-public API.

This leads to asking how other devices or services can potentially inter-operate with the utility’s SE HAN. The SEP specification anticipated this need and allows for the publishing of rate information, informational messages and supports a user confirmation capability upon sending of a message. It does not support sharing of any of the data being monitored with devices outside of the secure HAN. And a device outside of the SE HAN cannot send data with the exception of the message confirmation receipt.

The common usage scenario to demonstrate how this capability would be deployed is through the use of a home energy gateway. The energy gateway after fetching the latest rate tier or informational message from the utility-provided device relays the information, over the home WIFI network, to mobile devices such as an Android-based tablet or Apple iPad. The energy gateway does not have to be provided by the utility. But it does need to be supported by the utility and support Zigbee.

An SEP 2.0 energy gateway because SEP 2.0 standardizes the messaging and rate tier information using a RESTful approach, can potentially support a large ecosystem of third party applications running on WIFI enabled mobile devices. Through a client software partner program, an energy gateway vendor could administrate and track on-going interoperability with those applications. The household members or small business owner simply downloads the client application through either the Android Market Place or Apple App Store.

The energy gateway could also support features where it uses utility-provided information to notify future “smart appliances” that are Zigbee-enabled but not connected to the highly secure SE HAN. Providing the smart appliance with the ability to indicate simply whether its a low, normal or high demand rate period.

How the energy gateway market will evolve is unknown. We do know, however, that SEP 2.0 can open up the number of different methods for utilities to process Program Opt-out transactions and more.

If you wish to learn more about Zigbee Smart Energy digital certificates, please follow this link. Other resources: Digi, Ember.

Introduction

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?

OpenADR

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.

Summary

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.

Cisco recently completed the acquisition of LineSider Technologies at the end of December. And, for whatever reason, it’s interesting that EMC didn’t acquire them earlier. I worked closely with LineSider when at 3COM and involved in rebuilding the 3COM partner program. It was clear to me, LineSider’s business policy approach to automating network provisioning had great potential.

In 2009, when cloud computing market trials were in the midst of identifying the infrastructure build-out related issues, I decided to blog about cloud computing’s future impact on the technology industry. There were numerous skeptics at that time about the entire concept but, from my perspective, automating the provisioning would be the second most important technology to get right after virtualization. The industry was, however, tending to focus on defining and solving potential security concerns at that time.

In retrospect, I should have focused my blog strictly on automated provisioning and titled it differently which would have grab any CFO’s attention: How to Eliminate Margin Robbing Variable Costs Associated with Change Management in Cloud-based Services. Below is excerpt of that blog and here is the link to the original blog posted on Infrastructure 2.0:

Why It’s Important to Look under the Hood of your IaaS Provider’s Solution

Utilizing a business rule driven networking service provisioning engine is simply the best method for eliminating, margin robbing, variable costs associated with change management because it essentially obsoletes the task of network provisioning as we know it. An IaaS business, therefore, is likely to have the greatest ROI for both the provider and its tenants, when it’s based on a multi-tenant, business rule driven, automated network services provisioning platform.

An automated network service provisioning engine at a minimum for cloud-based computing: 1) should be purpose built for multi-tenant deployments and 2) make available to tenants a portal for closely monitor and conveniently provision changes to their virtual enterprise. The latter is about ensuring that enterprises can continue to maintain a high degree of business agility within their IT infrastructure. The former is about the technology underpinnings of an IaaS provider’s solution and sheds light on their ability to scale the service. If the automated network provisioning engine was not designed from the ground-up to be a multi-tenant platform nor capable of supporting easily configured customer-specific portals for monitoring and provisioning it’s not likely to scale to meet the business needs.

If you’re a CIO who is considering migrating IT services to a cloud-based virtual enterprise and want to add some thunder to the solution, then make sure the tenant portal meets your needs and it offers business rule driven provisioning. Otherwise, your cloud-based virtual enterprise initiative will become grounded — leaving you in a fog.

As compared to the importance of server virtualization technology which is considered “the” enabling technology for cloud computing, automated network service provisioning when business rule driven, drives out variable costs, improves efficiency and ultimately can become the face of the business by virtue of its portal capabilities. Its value is equally important as the value that virtualization technology contributes to the enablement of the IaaS market.