|Ultimately, IP is the foundation of interoperability|
Back to Network & Interoperability Index
3. Business Case
6. Next Steps
- There are lots of standards in building/home automation; too many to be interoperable
- There is currently no standard way to access historical billing information or real-time metering data, which would be extremely helpful to developers of web-based billing and energy-analysis services for consumers.
- Communications standards and specifications have historically failed to gain widespread product adoption due to the variety of this market space at all levels. Industry-facing efforts include the specifications developed by the ZigBee and HomePlug Alliance alliances, standards such as BACnet, LONWorks, and X-10.
- Because it is still early in the communication standards game, HAN vendors have their own expensive gateways that support multiple protocols. There is ZigBee Smart Energy Profile for energy-related communications and commands (that’s one communication chip), ZigBee Home Automation Profile or Z-Wave for home automation and remote control (chip two), and Wi-Fi, of course (chip three). The trouble is, pretty soon, you have an expensive dedicated energy management gateway costing hundreds of dollars.
- 6LoWPAN - ;IPv6 over Low power Wireless Personal Area Networks - The name of a working group in the internet area of the IETF. The 6lowpan group has defined encapsulation and header compression mechanisms that allow IPv6 packets to be sent to and received from over IEEE 802.15.4 based networks. IPv4 and IPv6 are the work horses for data delivery for local-area networks, metropolitan area networks, and wide-area networks such as the Internet. Likewise, IEEE 802.15.4 devices provide sensing communication-ability in the wireless domain. The inherent natures of the two networks though, is different.
- AMI-SEC TF - Advanced Metering Infrastructure Security Task Force within the UCAIug - Charged with developing security guidelines, recommendations, and best practices for AMI system elements. It is in the process of producing technical specifications that may be used by utilities to assess and procure security related functionality. In addition to utility use, this specification will be used by the OpenAMI task force as part of the AMI/DR Reference Design specification, and by vendors to produce compliant and compatible security technologies. Ultimately the AMI-SEC body of work will provide additional assurance not previously available within the utility industry.
- ANSI Meter Standards – Years ago, data formats, data structures and communications protocols for electricity meters were all proprietary.
- As a first step, utility companies wanted a compatible communication protocol between ANSI meters so they were not restricted to a single electricity meter vendor. To meet this requirement, ANSI standards were created that describe meter data formats and structures (C12.19), and provide a simple optical point-to point communications protocol (C12.18) that allowed them to communicate with ANSI standard meters.
- It wasn’t long before users wanted to be able to send and receive ANSI tables remotely. To address that need, C12.18 was adapted to create C12.21. ANSI Standard C12.21-1999 specified a new version of C12.18 that was modified for telephone modems. This protocol was still strictly point-to-point communication and session oriented. Minor modifications were made to account for longer communication timeouts and for security since it could no longer be assumed that a person would be standing directly in front of the meter.
- C12.18 described every detail of the physical attributes for optical communication ports (dimensions, LED wavelength, etc.). This standard was needed to build meters with a compatible communication interface. When C12.21 was created to implement point-to-point communication between meters, the intent was to use it with already existing modems.
- Although C12.21 is a meter communications standard and not a modem standard, some general attributes regarding modems were incorporated into the C12.21 standard. For example, initialization and dial strings were specified, but connector specification and electrical characteristics were not. The format and structure of the communications packets that carry C12.21 requests and responses are described in detail in the standard, but below a certain point, the detail stops. In the language of communications standards, the C12.21 protocol is more abstract than C12.18 because it deliberately omits the lower layer details.
- ANSI C12.22 - A number of proprietary protocols are available today to use the internet to send and receive meter data. ANSI C12.22 is the designation of a new standard to allow the transport of ANSI C12.19 table data over networked connections
- C12.22 is more abstract than C12.21 because it omits even more of the underlying protocol details. C12.22 is intended for use over already existing communication networks just as C12.21 is intended to for use with already existing modems.
- Examples of communication networks covered by C12.22 include TCP/IP over Ethernet, SMS over GSM, or UDP/IP over PPP over serial port. Just as HTTP provides a common application layer that all web browsers can use, C12.22 provides a common application layer that all meters can use.
- There are two different models of implementation addressed by the standard:
- Meters with an integrated network connection . The model for meters with an integrated network connection only specifies the application layer protocol. It may implement any kind of lower layer protocols.
- Meters with a separate communications module (CM) The model for meters with a separate CM has the meter on one side and the target network on the other side of the CM. The interface between the CM and the meter is explicitly and completely defined down to the physical layer. The interface on the network side of the CM is only defined at the application layer since the underlying network is not dictated by the standard. This allows for communication modules to be interchangeable without dictating the network on which the module is used
- Unlike C12.18 or C12.21 that only provide session-oriented communications, C12.22 provides for both session and sessionless communications. In a session, both ends keep track of what they have done so far in the connection. For example, after providing a password, subsequent read requests are granted or denied based on that password. In sessionless communications, neither side needs to keep this kind of information because each transaction is independent of the previous ones. In a sessionless communication, for example, a read request also includes the encrypted password. Sessionless communication has the advantage of requiring less complex handling on both sides of the communication link and fewer packets exchanged if communications sessions tend to be short.
- Currently a RFC for transporting C12.22 data using TCP and UDP transport over IP networks is in draft stage.
- HAN – Home Area Network - It is used for communication between digital devices typically deployed in the home, usually a small number of personal computers and accessories, such as printers and mobile computing devices.
- HomePlug - The brand name for a power line communication standard IEEE P1901.
- OASIS – Organization for the Advancement of Structured Information Standards - A not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets
- Open AMI - The OpenAMI Task Force is an international, industry-wide initiative whose sole objective is to rapidly develop a recommended open, standards-based information/data model, reference design and interoperability guidelines for Advanced Metering networks and Demand Response solutions
- OpenSG - Open Smart Grid (OpenSG) Subcommittee of the (UCAIUG),
- Residential Gateway - A home networking device, used as a gateway to connect devices in the home to the Internet or other WAN. It is an umbrella term, used to cover multi-function networking computer appliances used in homes, which may combine a DSL modem or cable modem, a network switch, providing LAN switching, a consumer-grade router, and a wireless access point. In the past, such functions were provided by separate devices, but by technological convergence, they have often merged into a single device.
- Sessionless Communication - Neither side needs to keep this kind of information because each transaction is independent of the previous ones. In a session, both ends keep track of what they have done so far in the connection. For example, after providing a password, subsequent read requests are granted or denied based on that password.
- SEP - ZigBee Energy Profile (PDF) – Zigbee offers utilities a global open standard for implementing secure, easy-to-use wireless home area networks for managing energy. In addition, product manufacturers now have a standards-based technology that they can implement to access to a burgeoning marketplace for green products without worrying about interoperability. Utilities can use the standard in applications such as advanced metering, demand response, load control, pricing, and customer messaging programs. The standard provides communication and control for devices such as in-home displays, programmable communicating thermostats, water heaters, lighting, smart appliances, plug-in hybrid electric vehicles, plus energy service portals and energy management systems.
- SEP 2.0 - Zigbee Smart Energy Profile 2.0 - Define an IP-based protocol to monitor, control, inform and automate the delivery and use of energy and water. It is an enhancement of the ZigBee Smart Energy version 1 specifications adding services for plug-in electric vehicle (PEV) charging, installation, configuration and firmware download, prepay services, user information and messaging, load control, demand response and common information and application profile interfaces for wired and wireless networks.
As amended by NIST, the Smart Energy Profile 2.0 specification will remove the dependency on IEEE 802.15.4. Device manufacturers will be able to implement any MAC/PHY, such as IEEE 802.15.4(x) and IEEE P1901, under an IP layer based on 6LoWPAN.
The upgrade of meters have been installed using Smart Energy Profile version 1.0, an early and inadequate standard to SEP 2.0 will be painful at best and impossible at worst. On April 1, 2011, following recommendations from the U.S. Smart Grid Interoperability Panel (SGIP) Task Force on Home Area Networks, the NIST governing board has recommended the creation of a new, fast tracked Priority Action Plan (PAP) to address requirements for developing a migration strategy from Smart Energy Profile (SEP) 1.0/1.x to SEP 2.0.
This new PAP will generate requirements hand-in-hand with the ZigBee Alliance. Because of the urgency of this issue, the PAP process must be expedited and completed in approximately three months. The outcome will be requirements and guidelines for regulators, technologists, vendors, and utilities on how to handle the transition from SEP 1 to SEP 2 in several scenarios in a technology-independent way. The ZigBee Alliance will make the technology-specific recommendations based on those requirements
- SGIP - Smart Grid Interoperability Panel - Established to provide an open process for stakeholders to participate in providing input and cooperating with NIST in the ongoing coordination, acceleration and harmonization of standards development for the Smart Grid.
- UCAIug. - Utility Communication Architecture (UCA) International Users Group
- ZigBee - (Wikipedia) The brand name for a low-power wireless standard built on the IEEE 802.15.4 standard. The technology defined by the ZigBee specification is intended to be simpler and less expensive than other WPANs, such as Bluetooth. ZigBee is targeted at radio-frequency (RF) applications that require a low data rate, long battery life, and secure networking.
3. Business Case
- Utility Networks Best Practices
- Develop common info models based on IEC
- Use ANSI metering standards
- AMI-SEC, OpenHAN security specifications
- Coordinate with SAE on PEV integration standards development (electrical and comms – UL, NFPA 70, DR Signaling
- Develop common info models based on IEC
- Consumer Networks Best Practices
- ZigBee/HomePlug Smart Energy Profile for home
- BACNet and/or OpenADR (depending on successful standardization) for industrial / commercial
- Use or create Internet Protocol variants
- Support de-facto industry efforts like U-SNAP
- ZigBee/HomePlug Smart Energy Profile for home
|Smart Appliance Communication|
- See my Standards for Standards Blog Article
- Common Pricing Model Standard - The need for a common pricing model crosses all domains that use price. Price is more than a simple number; it carries market context, and information such as quantity, units, time for use, and characteristics including source type and potentially carbon characteristics. A common and interoperable pricing model is a key to Dynamic Pricing in all its forms, and energy markets and trading including forward markets.
- Complex Tariff Structures and Content - To fully understand a price one needs to fully understand thousands of pages of tariffs for each jurisdiction. Driving toward simplified tariffs or (at minimum) machine-readable descriptions of tariffs would lead to more efficient markets. For example, the machine-readable tags for end user license agreements have simplified licensing decisions; a similar markup language for tariffs would allow better decisions in markets without implicit knowledge beyond price.
- Gateway definition between utility and premise. Although EPRI and others have been studying the idea of a “consumer portal” for several years now, the technological shape of the gateway between the utility and each customer has never been well-defined. For instance, consider a system using ANSI C12 over the WAN and distribution LAN, and the ZigBee Smart Energy profile on customer premises. There is no specification that clearly defines how the functions of these two technologies should be mapped to one another. For instance, which object or message on the HAN implements a demand response event expressed in ANSI C12?
- Metering Standards – There is substantial overlap without uniformity between metering models in use including ANSI C12.19, IEC 61850, IEC 61968, SEP 1, SEP2, COSEM/DLMS. Current protocols support primarily unidirectional relationships between the AMI head end and the meter. Other applications both within and external to customer premises seek to interact with the “meter” in near real-time on an as needed basis. The primary goal of standards activities, should therefore, be the coercion of at least a subset of these models into cleanly nested complexity levels with common semantics for each shared subset.
- Meter Security is not Standardized- Currently each AMI standard has its own distinct set of cyber security protocols and capabilities making sharing of information exceedingly complex and limited by the least common denominator. How to infuse a common set of cross-cutting requirements into advanced meter standards to facilitate exchange of confidential and authentic information across standards needs to be determined.
- ANSI C12.22 Mixes Layers- A common theme raised in the NIST workshops was that ANSI C12.22 mixes the roles of various communications layers for functionality beyond what is traditionally the application layer. Extremely detailed knowledge of the standard is required to recognize where the boundaries exist for the application layer and, perhaps, where it replicates the functions of lower layer functionalities.
- ANSI C12.22 Too Flexible -. The ANSI C12.22 standard permits so much. flexibility in implementation that even Metering Systems that support ANSI C12.22 typically only support meters from the same vendor. Furthermore, using a metering standard, ANSI C12.22, as the only means of interoperability means that there are few non-meter devices that can use these networks. Most commonly cited are the availability of segmentation and message routing capabilities. As is the common case in open SDO standards processes, there is often a need for implementation agreements done in a user forum that can constrain some of the flexibilities that the standard expresses and what users need. While ANSI C12.19 is an extremely flexible revenue metering model, it leaves so large a set of degrees of freedom available that a consumer of this information needs to be fairly complex to resolve simple meter information such a total KWH. ANSI C12.19 2008 has a mechanism by which table choices can be described, termed Exchange Data Language (EDL). This can be used to constrain oft utilized information into a well known form.
- Proprietary Networks - Radio frequency mesh networks like those provided by smart meter makers Itron, Elster, Landis+Gyr and others – as well as the Internet protocol (IP)-based system from startup Silver Spring Networks – are coming under indirect criticism for their lack of openness by companies like Trilliant, which provide communications based on the ZigBee standard, or SmartSynch, which uses cellular networks from providers like AT&T
- Robustness - At the same time, Eka Systems, which has developed its own smart meter data communications and networking technology, says that companies like Silver Spring Networks that have built IP networking systems are settling on a standard that, while open, will lead to problems with increasingly complex data communications needs to come in the future.
- SEP Issues
- Lack of Backward Compatibility between SEP 1.0 and SEP 2.0
- SEP 2.0 Still in Development, originally due out May 2010
- SEP 1.0 built into existing meters, not activate due to security concerns March 2011
- SGIP forms 90-day emergency PAP 18 to address SEP 1.0 vs. 2.0 compatibility issues
- Develop and standardize a pricing model – NIST plans to work with IEEE, IEC, OASIS, ASHRAE, NAESB and other relevant SDOs to develop an approach for developing a common pricing model to traverse the entire value chain. The model must include price, currency, delivery time, and product definition.
- Translate ANSI C12.19 into the form of the common semantic model NIST should work with NEMA to take on this task. The objective is to allow the lossless translation from the common form to the various syntactic representations prevalent in each Domain. Details will include the representation of the Decade/Table/Element model, as well as, the table-independent representation of key measurements of a revenue meter.
- Extend ANSIC12.19 and ANSI C12.22 to support common cyber security requirements – NIST should complete a common set of cyber security requirements through its Cyber Security Task Group. When complete NIST should engage NEMA in a normalization activity to capture results into ANSI C12.22 and C12.19 so that they have the capabilities to satisfy the requirements.
- Define a conformance classification for ANSI C12.22 to constrain its scope – NIST should work with NEMA to define, in their conformance testing standard C12.23, a set of conformance classifications that permit the varied capabilities of C12.22 to be selected and specified. Then work with UCAIug to define an implementation agreement to select subsets of ANSI C12.22 for use when integrating with other Smart Grid standard protocols.
- Design one or more standard meter profiles using ANSI C12.19 Exchange Data Language – NIST should work with NEMA to utilize EDL to represent one or more meter profiles with distinct information locations and formats to simplify client access to commonly shared information.
- ZigBee Alliance and HomePlug PowerLine Alliance should continue to develop a common application layer across their respective wireless and broadband-over-power line technologies
- In August 2011, The HomePlug Alliance, Wi-Fi Alliance, HomeGrid Forum and ZigBee Alliance announced they have agreed to create a Consortium for SEP 2 Interoperability. The new consortium will enable organizations whose technologies support communications over Internet Protocol (IP) to certify SEP 2 according to a consistent test plan. Recognizing that the vision of interoperable SEP 2 devices across the network will only be realized with consistent certification and interoperability testing, the Consortium is being structured as an open organization. This cooperation among alliances builds on the work of many industries to bring smart grid benefits to consumers.
The joint certification and testing program is intended to certify wireless and wired devices that support IP-based smart energy applications and end user equipment such as thermostats, appliances and gateways. It will cover devices that operate on one or more underlying connectivity technologies and provide utilities, product vendors and consumers with assurance that devices and applications are interoperable.
- Need to select some proven leaders – at least for the primary point of interoperability to the building
- Need to agree on an information model easily translated to inside the building protocols
- Extension of the interoperability and certification efforts may even include joint work with other alliances to meet market needs. As an example, in August of 2008 the ZigBee and HomePlug alliances announced a joint effort on harmonization
- HomePlug Powerline Alliance
- Wi-Fi Alliance
- Z-Wave Alliance
- ZigBee Alliance
- Electric Energy Online - An Overview of ANSI C12.22
- C1222.net - This site features access to open source code to support development of advanced metering and energy management solutions compliant with the ANSI C12.22 standard for transport of meter-based data over a network.
- CEPro Home Automation: Has Anything Changed in 15 Years? We're still banking on utilities to jump-start the home automation industry and a "real" standard is "just around the corner."