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.

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. erich@enernex.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. grant@enernex.com

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.”