Professional Documents
Culture Documents
Table of Contents
Smart Grid Ready Framework: Introduction Framework Definition Component Overview Real Time Grid Management Multi-Process Interoperability Consumer Engagement Tools for Deployment of Smart Grid Devices Adaptive, Service Oriented Architecture (SOA) Conclusion Smart Grid Ready Checklist 1 2 2 2 4 5 6 6 8 9
Moving to Smart Grid demands re-engineering of a utilitys business and the IT systems that drive it.
New information and automation and is needed to drive realtime operations and consumer interaction.
The transition must show early success and not disrupt operations or customers.
Despite these challenges, the transition to Smart Grid is underway and utilities cannot wait for the dust to settle before they begin deploying management systems that will drive operations in the immediate future. Implementing systems within a Smart Grid Ready design framework can insulate utilities from complexity and risk in this fluid environment, and ensure utilities can adapt to meet the challenges or seize opportunities as the grid takes shape. This paper will outline the key components of the Framework; discuss the requirements for, and respective benefits accrued, from each component.
But Smart Grid is a moving target: Utilities cant afford IT investments that leave them marooned outside the Grid down the road.
Systems built to a Smart Grid Ready Framework can ensure value is delivered as expected.
Framework Definition
The Smart Grid Ready Framework is a strategic application blueprint that helps ensure Grid management implementations deliver business value as expected. The Framework is defined by five components: Support for real-time Grid management Support for process interoperability and data exchange within and between enterprises Support for Web-based consumer engagement Inclusion of tools to manage deployment, operation and maintenance of AMI, HAN, and other Smart Grid systems Designed to Service-Oriented Architecture (SOA) standards
The Framework defines key components to support changing Smart Grid requirements.
Utilities can use the framework as a topdown primer for evaluating, planning and deploying the IT systems that will power their transition to Smart Grid. Today these systems include Grid sensors, Advanced Metering Infrastructure (AMI) networks and devices, in-home (HAN) devices and networks, Meter Data Management (MDM) systems, and Smart Grid Management applications. Together, these form the foundation for utility-specific applications such as Advanced Metering, Customer Service, Demand Response, Consumer Engagement or Distribution Grid Automation. Implementing systems within a Smart Grid Ready framework can: Speed migration to AMI and Smart Grid management Ensure current and future Smart Grid technologies meet business expectations Insulate utilities from implementation complexity Minimize duplicate systems and application silos Enable systems to incrementally evolve without disruption Allow utilities / consumer collaboration to save energy
The Framework provides an evaluation and planning primer for Smart Grid Management Systems.
Smart Grid Ready speeds migration and insulates utilities and customers from complexity and disruption in transition.
Component Overview
1. Real-Time Grid Management
The need for a real-time infrastructure is a pervasive theme within the Energy Independence and Security Act of 2007 and Department of Energy specs for Smart Grid. This is driven by requirements for realtime monitoring and control of the distribution grid, time-based energy pricing and two-way consumer/supplier participation in the process. Effective adoption of Smart Grid and the processes that make it run must be based on a robust platform that can handle event-driven distribution of information and execution of business process in a way that is consistent, reliable and auditable.
Realtime infrastructure is a pervasive theme within EISA and DOE specs for Smart Grid.
Key functional attributes are: Continuous validation and processing of meter interval, sensor and other data Real-time handling of alerts, exceptions, messages and network events On-demand, bi-directional exchange of current, consistent information between systems and users Support for just-in-time operations between dependent systems and processes Online provisioning of newly installed meters, HAN devices, distribution switches and other hardware Smart Grid Real-time Applications In a Smart Grid context, AMI collection and recording of meter interval data is necessary but insufficient. Providing data based on monthly, even daily estimates is not useful. Interval data must be validated continuously and made immediately available for any use as it is received. In addition, exceptions, alerts or messages required to invoke action must be processed on-demand. In the new world, Demand Response requires the marriage of time-based rates with real-time consumer usage patterns so informed choices are made about how to optimize supply, cost and usage. Dispatchable time-ofuse or critical peak pricing are event-driven processes requiring a real-time infrastructure. Soon, real-time control commands and receipt verification of home and commercial devices must be supported. Todays Real-time Challenges Future capabilities not withstanding, timing is everything, especially with a utilitys first Smart Grid step: meter-to-cash applications. These deployments link meter installation, provisioning, interval data validation, billing and customer service processes in a dependent fashion. Just-in-time events must be handled and current data must be available at the precise time required by each process. If billing is based on stale data, or todays service logistics are executed on yesterdays status, the process will be inefficient and invariably generate complaints from customers. With a real-time infrastructure, outage alarms can be received and power restoration checked immediately. Service can be enabled while a customer is on the phone. Meters (and other devices) can be provisioned while service crews are in the area to handle problems, and cutover when ready. Scalability for Real-time Processing Real-time Smart Grid management must be designed to handle extreme loads. Systems must be able to accommodate growth from thousands to millions of Grid devices and data pointsand potentially billions of pieces of dynamic data. Advanced Metering networks, MDM solutions and their dependent applications should be designed to validate and process these data on a continuous basis, rather than with a batch approach. Finally, vendor systems should carry an independent benchmark to validate capability to handle multi-million meter deployments. eMeter Corporation 2009
Advanced Metering (AMI) and Grid management systems will generate extreme network and processing loads.
AMI and MDM solutions should be independently benchmarked to handle multi-million meter deployments.
2. Multi-Process Interoperability
To effectively manage operations, improve customer interaction and increase energy efficiency in a Smart Grid context, utilities must extend their IT systems to support process interoperability and data exchange within and between enterprises. Interoperability Within the Enterprise Today, many of a utilitys IT systems are monolithic applications designed to manage single discrete processes (e.g.: Billing, Service Logistics, Call Center, Asset Management, etc). Process interoperability is driven by manual or periodic batch data exchange and synchronization. To manage events and exchange data across systems within the enterprise in an end-to-end flow, feeding each dependent process at the optimal time, utilities must re-engineer toward a more real-time, integrated view. For example, when deploying initial AMI Meter-to-Cash applications, systems should be extensible beyond the stovepipe process of collecting interval data and feeding the billing system. Deployment should be easily extended to incorporate processes such as asset lifecycle management, service requests and incident resolution. A Smart Grid ready infrastructure should also support availability of current data from multiple systems to complete real-time call center processes such as new accounts, turn on service or customer moves all while the customer is on the phone. The system should be extensible to migrate this process to a Web-based self service model. Interoperability Between Enterprises In an extended enterprise model in which several companies are involved in energy distribution, process execution must span company boundaries and access to data must be managed to each entitys authorized view. Beyond traditional utilities, participating entities can include aggregators, retailers, distributors, market operators, service providers and consumers. For example, a merged utility may need to support multiple operational models serving customers and regulatory bodies in multiple states, provinces or countries. A Meter Operator may have to deliver data from a common source to distribution companies, energy retailers and to a market settlement agencyeach with differing requirements.
Utilities must extend their IT systems for interoperability within and between enterprises.
Meter-to-Cash deployments should be extensible beyond a stovepipe data collection and billing process.
Integrating current data from multiple systems to support customer service is required.
These applications require interoperability between multiple legacy A single platform should support process flows CIS, asset management, logistics systems and potentially multiple unique to each company AMI/smart meter infrastructures, each with differing process flows with customized data views and data models. With state-of the-art deployments, an MDM system for entitled users. is the core component to enable this integration. Integration should be enabled without disruption or changes to in-place application logic. A single platform should support multiple instances of customized process flow and provide the data management, audit trail and access control to deliver appropriate, authorized views of information created by the overall system. This includes automated aggregation eMeter Corporation 2009 Whitepaper: Smart Grid Ready 4
of information from multiple operational systems to provide consistent datasets for planning, pricing, forecasting and other analytics. Incremental Deployment Finally, multi-process systems should be configurable for modular deployment: Allowing a tailored implementation to meet the functional requirements of a pilot, but scaling in-place to add new capabilities. This will enable the utility to think big while starting small, demonstrate early success and then scale fast.
Systems should be designed for incremental deployment, a.k.a think big, start small, and scale fast.
3. Consumer Engagement
One of the key tenets of Smart Grid is to empower consumer interaction for optimal energy management. Consumer Engagement defines the system characteristics that educate, inform and encourage sustained, proactive behavior to optimize power demand and save energy. Early attempts to communicate with consumers about their energy consumption have come in the form of tips or energy analysis presented on individual monthly bills. However, these steps fail to effectively tie usage and behavior to cost or environmental impact in a meaningful manner that builds understanding or encourages conservation. Consumer Engagement will leverage the Web as a focal point for engaging the consumer more deeply, and represent a critical next phase in Smart Grid deployment. To better encourage behavior changes, consumers need to be clearly and simply shown the connection between usage, cost and environmental impact. They must have immediate access to answers for their questions regarding their options to minimize/optimize their energy usage to reduce costs. There are six key requirements for consumer engagement: Real-time visibility of the relationship between usage, cost and environmental impact. Clear and simple, cross-platform access to power usage education, trusted tips and FAQs. Integrated promotion of conservation options with expert opinion and peer recommendations. Immediate notification of usage and cost changes to allow users to better manage their bills. Support for Web communities to encourage conservation and best practices. Aggregation and presentation of PUC and ratepayer reporting on cost reductions and load demand shift.
Consumer Engagement enables utilities / consumer collaboration to save energy.
The next generation will leverage the web as a focal point and engage the consumer more deeply.
Presenting timely usage data allows consumers to associate the cost of their bill with their usage of individual appliances or heating/cooling systems. Time-of-use rate plans can be applied to show the savings benefits of behavior change. Real-time delivery of alerts allows users to respond appropriately to Grid events such as peaks, rolling eMeter Corporation 2009 Whitepaper: Smart Grid Ready 5
brownouts or extreme weather events, and the impact of actions can be linked on an individual, or community level. Peer comparison and advice from the local community and respected experts motivates changes in consumption patterns, which are supported by actionable information and reinforced with immediate feedback. Users are familiar with and trust peer rating social tools such as eBays user seller ratings, and tools such as these will be invaluable in encouraging trust in peers for recommendations. In addition, integrated communications with users across a wide variety of media including printed bills, mail, web, mobile phone and community events are key to influencing behavior. A Consumer Engagement site should integrate all and become the focal point for consumer-utility collaboration to save energy.
Smart Grid requires deployment of millions of devices without disruption to utility operations.
SOA is the systems foundation to support iterative BPR. For ongoing operations, it enables the real-time processing, interoperability and scalability for Smart Grid management. SOA removes dependencies that paralyze traditional monolithic business systems. With an SOA, application processes can be more easily coupled and decoupled, and required information flows freely within and across reengineered systems. Equally important, SOA environments can be extended with new capabilities without retrofit. An effective SOA should break the hardwired connections between business process, data, applications and infrastructure to allow: Change in process and data flow between applications Integration of wholly new application function Integration of SOA based solutions into non-SOA environments Incremental addition of processing capacity System fault tolerance if individual components fail
SOA breaks hardwired system connections to allow change without retooling applications.
Although there are many specific instantiations of an SOA, all have common attributes: Interfaces that insulate process from physical infrastructure: This provides a common way of expressing processes that operate across different systems. For example, with an SOA interface layer, one service can be implemented to perform device reads and bound to many device types. The service does not have to be recreated for each device type, or updated as infrastructure changes. Many solutions promote the importance of SOA compliant interfaces. Although these are a necessary component, by themselves they are insufficient to achieve the full benefit of SOA. Interface-only implementations merely wrap monolithic code in a more maintainable interface. Complete architectures go beyond this to support full process interoperability and re-engineering. They provide the ability to delegate service execution to multiple applications and to manage that delegation in the context of an endto-end process. They allow changes to these flows without re-tooling in-place applications. To accomplish this, more is required: Applicationindependent business process rules: Providing a mechanism to create and manage business rules that is separate or abstracted from application logic enables change in process flow within and between systems without having to rewrite applications each time a business process changes. In addition, process interoperability can be supported. Requests for service can be published to applications and replies fielded to kick off other processes according to specified rules.
An interface layer should mask differences or changes in physical infrastructure.
Applicationindependent data exchange: A common repository where data and events are collected and managed can act as the central hub to provide a consistent view of data between applications. The repository performs data transformation and mapping services to ensure the common data representation can meet the unique format requirements of each application served. In addition, a complete history must be maintained to provide an audit trail for original source data versions, changes and event processing. Realtime messaging for interprocess communication: Provides a common standards-based backbone for real-time information flow between systems. This component is essential to enabling interoperability as well as scaling to manage the high data and event traffic Smart Grid management will drive. The messaging platform should be independent from the application layer it supports, enabling loose coupling (and re-coupling) of applications. To guarantee message transfer for the full spectrum of data interchange, it should support synchronous and asynchronous messaging, and request/reply or publish/subscribe interactions. Finally, it should be implemented in a distributed fashion to avoid introduction of a single point of failure and enable modular addition of capacity. Integration with nonSOA systems Recognizing the majority of utilities in-place systems are not today SOA-compliant, it is critical that the introduction of SOA systems allows for coexistence. Interfaces to legacy systems should support interactions mandated by a wide range of legacy application and data models. This includes translating data into types and formats that legacy systems can use without having to make extensive changes to the legacy systems. For example, filtering and converting outage alarms to look like phone messages that legacy outage management systems can handle; and delivering these via the right interface.
A common data store should manage a consistent view of data for exchange between applications.
A distributed implementation should provide for fault tolerance and modular addition of capacity.
Conclusion
When implementing Smart Grid management systems, successful utilities will first seek to achieve greater flexibility and efficiency for existing, discrete operations. Typically this involves automating existing monthly metering processes with AMI infrastructure. This will lay the foundation for more real-time operations and integration of end-to-end processes within and outside the enterprise. But before this effort is complete, they will be required to integrate entirely new advanced applications, and evolve in-step with a fluid regulatory environment. Building to a Smart Grid ready framework can ensure required capabilities are supported and systems evolution can take place seamlessly, without disruption to existing operations and customer service.
Utilities will evolve to Smart Grid. Building to the proper systems framework ensures that requirements can be met and changes take place seamlessly.
Y/N
Y/N