|
|
|
|
Use Cases Can Provide an Effective Roadmap Toward AMI Deployment
By Will McNamara, Principal Consultant, KEMA
|
|
|
Three months ago, Jim Rogers, Chairman, CEO and President of Duke Energy, appeared before the U.S. Senate Energy and Natural Resources Subcommittee on Energy. Rogers told the committee, “Imagine a day when smart technologies and appliances will be able to make decisions about when to operate and could even ‘learn’ how to combine efficiency, cost, comfort, and convenience for customers. Imagine a future when these vehicles can charge at night while demand is lower, and send electricity back to the grid during the day when demand is high, offering yet another source of offsetting the need for new power plants.”
Rogers characterized these broad industry advances as the ‘Utility of the Future” (UoF), and stated that the time is now for the industry to embrace new technology solutions. “I believe that through the proper architecture, the potential for energy savings will bring with it a transformation in how we continue to meet the needs of an increasingly electrified economy ... and I don’t believe we can wait,” Rogers said.
Since Rogers’ congressional presentation, Duke Energy has begun to plan for implementing an AMI system that will support its broad UoF initiatives, and KEMA has provided project management support for Duke’s Use Case process. KEMA also previously employed Use Cases as part of a consulting engagement with the California ISO’s Market Redesign and Technology Upgrade (MRTU) project. In that project, KEMA conducted extensive Use Case analysis to describe interfaces between CAISO's existing legacy systems and future market systems and applications. The purpose of the analysis was to prepare detailed technical specifications and formulate a transition plan to the new system.
Of course, Use Cases have been around for decades, but only recently have they begun to emerge for AMI. In general, the objective of the Use Case process is to create a list of requirements for the necessary components (also referred to as “Actors”) within a utility AMI system. Upon reviewing the requirements list, technology vendors will have a better understanding of the specific utility’s needs and how it envisions using its AMI system. Typically, the requirements developed by utilities utilizing the Use Case process do not specify technology. Rather, given the rapid pace of technology development and the need for subsequent upgrades, it is a much better strategy to leave the door open to new solutions that vendors might provide.
This article will provide an overview of the standard elements of a Use Case process that most utilities follow. This article will also provide instructions for other utilities either planning or in the process of developing Use Cases to support their AMI business cases.
|
|
|
What Is a Use Case, Anyway?
Although used in the software industry since the 1980s, the Use Case is a relatively new resource tool for specifying AMI system requirements. Nevertheless, standards related to AMI Use Cases have quickly developed. Put simply, AMI Use Cases specifically outline how utilities intend to implement and use nascent AMI technologies in their own developing infrastructure.
The challenge of Use Cases is that most utilities have had to chart their own courses to determine their technology needs. Given that so few utilities have fully deployed new AMI technologies across their service territories and inherent differences exist among utility systems, there is rarely a single “road map” that utilities can follow. Rather, most utilities find that the blank page of possible solutions creates a rather daunting challenge.
Consequently, Use Cases can serve as an integral tool to help facilitate the deployment-planning process by forcing utilities to determine how they will use the system they are creating. They also provide the specific steps utilities can take to improve their operational efficiencies, not only related to metering processes but also to distribution automation.
The key components commonly included in a Use Case are as follows:
Use Case description: This section typically describes all aspects of the Use Case, and lists possible impacts on other functional areas.
A list of acronyms used in the Use Case and a definition of all referenced Actors. By definition, an “Actor” is anything in the AMI system that communicates with other components or conducts a particular activity.
Identification of assumptions that form the basis of the Use Case. For instance, does the Use Case assume the existence of systems, architecture, communications capability, etc.?
A requirements list created by the Use Case. Requirements are typically categorized into “functional” and “non-functional” areas. Functional requirements place specific functions on an Actor (for instance, "The Meter shall support interval data collection for energy consumption") and address what the system “must do.” Non-functional requirements specify how a system should operate and include things such as reliability, security, usability, expandability, scalability, compatibility, safety, performance, etc. Non-functional requirements can be thought of as something that an Actor “must be."
Scenarios: A Use Case typically includes a set of primary and secondary scenarios, which describe a specific process within the AMI system from the point of view of a given Actor. An example of a common primary scenario would be “the customer requests routine electric service connect.” Accordingly, within the scenario, specific steps are identified demonstrating how the new AMI system supports remote connection of electric service. Primary scenarios also identify triggering events (what initiates the process), the pre-conditions that should be in place before the scenario process commences, and the post-conditions (status after the primary scenario is completed). Alternate scenarios follow a similar step-by step format but address those instances in which a primary scenario cannot be completed for some reason.
A Use Case commonly will include activity diagram charts that visually demonstrate the interface between Actors participating in the process, the information exchange between those Actors, and databases where data is stored either temporarily or permanently before being retrieved by an Actor for analysis.
It should be noted that Actors and requirements are rarely linked to just one Use Case. Rather, a final step that a utility working group should take is to resolve inconsistencies or redundancies among Actors and requirements. Use Cases can vary in scope, format, and length, but they tend to arrive at requirements lists that are similarly formatted.
Involving the entire utility organization is vital to ensuring a positive Use Case experience. It is essential to use cross-functional teams and gain participation of diverse utility groups such as Customer Billing, Transmission & Distribution, Distributed Generation Systems, Regulatory, Market & ISO Integration, and Engineering & Construction.
|
|
|
Duke Energy’s Experience
Duke Energy serves approximately 3.9 million customers in five states: North Carolina, South Carolina, Ohio, Indiana, and Kentucky. Duke intends to ultimately replace all the meters in its service territory with AMI technology capable of supporting not only end-user services (e.g., remote connect / disconnect, demand response, and prepayment services, etc.), but also broader substation and distribution system automation capability (e.g., enhanced power outage management, curtailing / limiting customer load for grid management, and substation power quality).
Duke’s first step was to develop an internal business case that justified the UoF project to internal management. The core team that developed this business case focused on the highest value items first, and then continued to move out in value until it had encompassed nearly all Duke operating departments. Upon receiving internal approval for the UoF project, Duke began to develop Use Cases in early 2007. In total, Duke Energy has prepared 17 Use Cases with the project management oversight of KEMA. Each Use Case has addressed a specific business or operational process that will be enabled by AMI. The company recently completed its system requirements, based on the data gathered through the Use Case process, and plans to begin testing technology solutions with select vendors this summer.
Matt Smith, director of Duke’s Utility of the Future project, has been very pleased with the Use Case process and the way it has enabled the company to design its architecture. “Using the process to better understand and develop the requirements for our Utility of the Future project helped us focus on the most important components for our energy delivery system,” Smith said. “The Use Case format also facilitated getting our internal subject matter experts involved in the process of defining our system requirements.
Further, Smith believes that Duke's development initiatives were greatly influenced by the Use Case process. “As we progressed in defining the requirements on our system, we were able to continually update our development initiatives with the latest, most detailed requirements in an organized and methodical fashion,” Smith said.
KEMA has observed that Duke’s experience with Use Cases has been greatly enhanced by the participation of a broad base of internal experts within the company. Smith concurs with this observation and underscores the importance of having cross-functional utility departments involved from the conception through implementation of a planned AMI system. “The work performed by other utilities gave us a good idea of which departments should participate in the Use Case process,” Smith said. “Once we started inviting departments from across the company, our project team started receiving unsolicited requests to participate from many other departments once they realized the broad scope of the Use Case process. One item that has been very important to Duke Energy has been to involve operating departments beyond just metering personnel. We have included support functions, such as HR and Legal, which has also added an additional layer of detail to the Use Cases.”
|
|
|
Lessons Learned
Clearly, implementing an AMI system is a complicated process. However, Use Cases appear to be a valuable tool for clarifying critical components of the AMI system. The most critical step is to define functional requirements for an AMI system by combining both hardware and software requirements. System attributes will then dictate cost and capacity of the system.
While standardization is desirable, it is fairly clear from Use Cases that it is not viable to impose a “one size fits all” approach. Each utility will have its own unique needs related to metering and substation automation.
However, some common denominators are clearly emerging. For instance, while AMI systems have different conceptual architectures, most all include automated upgraded residential and C&I meters, an underlying communications network, and a head-end system. In addition, while AMI systems at minimum address meter retrofits and related billing process improvements, most utilities use the upgrade opportunity to address outage management issues and strategies to reduce strain on the electric grid. Following that, most utilities begin addressing the functions under which the AMI meter, or other key communications elements, can serve as the “gateway” to the customer. This entails an array of potential uses including “smart home” services that could either be provided by the utility or a third party.
Moreover, executive sponsorship needs to be visible and demonstrated early in the process. Encouraging sub-teams to work together is also important, and it has been KEMA’s observation that including diverse and cross-functional teams within a utility’s operation in the Use Case process, from conception to implementation, is a critical element for success.
For more information, contact: will.mcnamara@kema.com
|
|
|
|
|
|
|
|
|
