Southern California Edison envisions an advanced metering system that brings customer-usage data into the digital “central nervous system” of its power operations. This information backbone would enable dynamic pricing, demand response, efficient customer management, and rapid outage and theft detection. Customers would see and could react to their energy usage on a daily basis. It also would provide the utility with tools to react to emergency situations. Eventually, it could permit real-time feedback between customers and energy markets, and enable customer-owned distributed generation. This would streamline utility operations and reduce day-to-day operational costs.
Recently, SCE (Rosemead, California, U.S.) developed the functional requirements and specifications of a new advanced metering infrastructure (AMI) project. Although the pilot test is still in development, if the system is cost-effective and approved by the California Public Utilities Commission (CPUC), SCE will start deployment in 2008. The system envisioned will replace about 5 million meters and will cost approximately US$1.3 billion in capital funds with full deployment in 2012.
The AMI project will leverage commercially available components using open designs for both metering and communications, creating a flexible and sustainable technology platform. Open design facilitates the use of both existing and future technology developments in home connectivity, distribution grid intelligence and distributed generation. Keeping upgradeability in mind, the millions of meters in an AMI must be adaptable to new technologies, programs, rates, applications and security threats. Furthermore, the AMI must be technically and economically feasible for SCE to perform these upgrades at minimal costs.
The approach to achieve this openness and upgradeability follows a modern systems engineering approach for evaluating the benefits and risks inherent in deploying such a complex system. The increasing pace of innovation within AMI technologies presents opportunities and challenges. Equally important is the ability to balance cost, schedule and technical constraints with a thorough understanding of the maturity level of available technologies. SCE's systems engineering approach provides a structured framework for addressing these issues.
With the goal of an open design, SCE leveraged the results of prior open-architecture efforts, including EPRI's IntelliGrid Architecture project, the OpenAMI Task Force and the Interoperability Constitution of the U.S. Department of Energy's GridWise Architecture Council. These provided the initial framework and scope for the SCE requirements gathering process.
An important decision was adopting “use cases” to gather AMI system requirements. Use cases have become a proven method for collection and documentation of system requirements in the software industry (see the table). Both the IntelliGrid and OpenAMI projects were based on use cases, and IntelliGrid had provided a methodology developing them. SCE's use cases and requirements have been released so that other utilities, standards bodies and industry groups can benefit from the lessons learned.
To apply this approach, SCE engaged EnerNex Corp. and IBM as consulting system engineers responsible for assisting in use-case development, requirements capture, analysis and system architecture design. IBM brought its extensive expertise in large systems architecture development and integration. EnerNex, which has been a member of the EPRI IntelliGrid Architecture team since its inception, also developed the California Energy Commission's reference design for demand responsive infrastructure and was responsible for the formation of OpenAMI. EnerNex was in a good position to transfer those lessons learned to this AMI project.
To develop requirements based on use cases, SCE organized a series of workshops using cross-functional teams. Use cases place particular emphasis on how the metering system will actually be used rather than being constrained with existing product designs. The intent is to clearly define the desired requirements, leaving vendors free to provide innovative solutions. The requirements teams analyzed 18 separate use cases in 6 categories, representing 99 separate potential scenarios of how AMI might be used to improve service levels, lower the costs or both.
With the use cases finalized, the requirements were consolidated resolving any conflicts and ensuring consistency of terminology and language across all the requirements. The resulting consolidated requirement set was then prioritized and mapped to architectural components and functional areas. SCE's preliminary requirements for AMI was published on June 30, 2006.
SCE's systems engineering approach is use-case driven and focused on identifying the architecture components necessary to enable the system requirements. By mapping each requirement to a technology neutral or generic component, a set of required capabilities is described for each component and subcomponent. This yields a conceptual architecture view of the entire system describing how components will work together to deliver the value captured in the business case.
This process results in a series of engineering decisions that yield a platform-independent, preferred system design. SCE's preferred system design, represented in the conceptual architecture, serves as input into vendor evaluations, business-case estimates, integration and testing plans. It also provides a means to accelerate platform-specific AMI engineering and deployment tasks once a specific set of technologies has been selected.
The challenge in communicating the conceptual architecture for AMI lies in the complex collection of devices, data, networks, computer systems, protocols, organizational processes and people necessary to provide the operational benefits. To address this challenge, it is helpful to think of AMI as a “system of systems” working together to provide value to a common set of stakeholders.
SCE's systems engineering approach yields views of the AMI architecture at increasingly lower levels of abstraction by answering the following questions and describing the answers in a system of systems context.
Why? Requirements definition, the first step in the design process, answers the question, “Why are we investing in this project?” As the cross-functional teams developed the AMI functional and nonfunctional requirements through the use-case workshops, they identified the business value of each requirement. Business-case teams then investigated in detail to assign a dollar figure to each identified value statement. The result became SCE's conceptual business case for AMI.
What? Conceptual architecture answers the question, “What systems, subsystems and components do we need in order to meet SCE's requirements?” To provide these answers, the system architects translated the steps of each use case into a matrix of abstract message sequences passed between a set of “actors.” Eliminating duplicate messages and actors produced a well-defined set of logical interfaces and components.
How? Logical reference architecture determines how the AMI components are integrated into a logical architecture and what services must be provided to create a viable end-to-end solution to fulfill the goals. This view of the AMI architecture also provides a refined answer to the question, “How much value (costs versus benefits) does each alternative architecture and component yield, and what are their constraints and boundaries?”
With what? Platform-specific reference architecture determines: “With what standards, technologies and vendor solutions will SCE select to accomplish our AMI goals?” The outcome of this process is the selection of specific vendor solutions necessary to meet the requirements required to achieve a positive operational benefit. This is the lowest level of design abstraction prior to commencing detailed design and integration activities.
The success of the SCE AMI project has a great deal to do with three key principles on which the process was based:
Firstly, SCE has found that applying a disciplined systems engineering approach to developing its AMI has resulted in an architecture that is extensible and capable of being implemented using available technologies. This approach has produced requirements that reflect the needs of a wide base of stakeholders from both inside and outside SCE. The methodology allowed continuous involvement of the vendor community to ensure that they understood the requirements and provided valuable feedback to SCE to validate that implementation was feasible.
Secondly, nearly as important as the use of top-down systems design was the early commitment to an open architecture and transparent engagement with the rest of the power industry. Using the IntelliGrid architecture, GridWise principles and work products of other organizations such as OpenAMI provided a strong foundation and architecture upon which the SCE AMI system is based.
To show its commitment to open innovation, SCE has made its work products available to the industry through a variety of venues. SCE has published its regulatory filings, use cases, requirements, technology capability methodology, presentations from vendor and external advisory group meetings, and other documents on its website (www.SCE.com/ami) throughout the project and will continue to do so. SCE also has contracted with EPRI to merge the final use cases and requirements back into the overall IntelliGrid architectural model.
As another part of this external engagement, SCE and other early implementers of AMI systems joined together to form the UtilityAMI effort, a working group of the Utility Communications Architecture International Users Group (UCAIug). This group serves as the utility advisory organization to the OpenAMI organization that is working on the details of the technologies, best practices and technologies necessary to implement interoperable AMI systems. This group serves to further ensure technology transfer from SCE and other utility AMI projects.
Lastly, SCE has tried throughout the process to closely involve potential vendors and make use of their feedback. The architecture team revised and refined the requirements list as interviews with vendors restricted — or often expanded upon — SCE's ideas of what was feasible.
- REQUEST FOR PROPOSALS
In mid-December of 2006, SCE released a request for proposal (RFP) for the meters and communications system components necessary to implement the AMI system. Thanks to the systems engineering approach, this RFP will provide the vendor community with a clear and concise description of what SCE needs in its AMI system and will establish clear guidelines for evaluating the responses received. Then all that is left to do is to build it. That process will likely form the basis of a future article.
Jeff Gooding is a senior systems engineer in Southern California Edison's information technology department. He currently serves as the lead architect supporting SCE's AMI program, prior to which he supported software development projects for SCE's power procurement and generation business units. Jeff.Gooding@sce.com
Erich Gunther is the principal consultant and cofounder of EnerNex Corp., where he helps clients define their strategic direction in basic research and development, technology and product development. He has designed and developed solutions for various power-system problems to improve efficiency, operations and security for electric power systems. He is a registered professional engineer. email@example.com
Grant Gilchrist is a consulting engineer for EnerNex Corp. and a recognized expert in data communications for the electric power industry. He has worked extensively in the areas of utility communication architecture development, demand response and advanced customer metering, and in the design and development of embedded real-time software. Gilchrist is a registered professional engineer. firstname.lastname@example.org
Southern California Edison's Use Cases Billing and Customer Service Customer Interface Delivery B1 Multiple clients read demand and energy data C1 Customer reduces demand in response to pricing and/or grid event D1 Distribution operator curtails/limits customer load for grid management B2 Utility remotely limits or connects/ disconnects customer C2 Customer has access to and reads recent energy usage and cost at his or her site D2 Distribution operators optimize network based on data collected by the AMI system B3 Utility detects tampering or theft at customer site C3 Customer uses prepayment services D3 Customer provides distributed generation B4 Contract meter reading for other utilities C4 External clients use the AMI system to interact with customer devices D4 Distribution operator locates outage usingWHAT IS A USE CASE?
A use case is simply a story that includes various actors and the path they take to achieve a particular functional goal. A complete use case results in the documentation of multiple scenarios, each containing a sequence of steps that trace an end-to-end path. These sequential steps describe the functions that the proposed systems and processes must provide. This leads directly to the requirements for the given use case.
A use case may have many parts, but the following were chosen for this project:
The goal of the use case is usually its name. For example, “Utility remotely connects or disconnects customer.”
The narrative is a short text version of the story.
The actor is anything in the system that communicates. It may be a person, a device, a piece of software, an organization, or anything else that acts independently, and has goals and responsibilities. For example, an actor might be a customer or a meter.
The assumptions upon which the use case is based can constitute requirements in and of themselves.
The contracts and preconditions that exist between the actors. For example, “The customer agrees with the utility to limit demand on selected days in exchange for a lower tariff.”
The triggering event is what led to the scenario taking place.
The steps is a numbered list of events that tell the story in detail. Each step identifies an actor, what the actor is doing, what information is being passed, and to whom that information is sent. For example, “The operator sends a curtailment command to the meter.”