Raymond Kelley, Eister Electricity, LLC
Many utilities are considering or have already begun implementing an advanced metering infrastructure (AMI) to automate their metering and billing related business processes.
AMI brings a new level of automation possibilities that are above and beyond traditional AMR capabilities. For example, AMR is primarily focused on meter reading and meter data collection, whereas AMI also enables configuration and control capabilities. The enhanced capabilities provided by AMI can enable complete automation of manual metering related business processes.
AMI’s enhanced capabilities include remote activation and control of meters to accommodate:
“- disconnect and reconnect operations
“- reconfiguration of the meter to provide different billing or load survey determinants (i.e., time-of-use tiers, interval data size, interval data quantities, etc.)
“- adjustment of other measurement capabilities and monitoring thresholds (i.e., voltage, instrumentation profiling sustained outage duration, outage, etc.)
Some of these AMI capabilities may reach beyond the scope of the CIS into distribution automation systems and/or outage management systems. Utilities that take full advantage of the automation provided by AMI systems will streamline their CIS business processes and improve the bottom line. In most cases, full-scale AMI deployments require a significant investment, but planning ahead can save money and result in a better return on investment.
using web services to integrate
There are several challenges to consider when integrating an AMI system to CIS. First, there are no industry-wide standards that define the CIS to AMI interfaces described above. Secondly, the automation interfaces provided by an AMI system should be based upon standard protocols and technology that are universally supported. Finally, utilities have different business processes that require the AMI system to provide a versatile and adaptable interface for automation.
In the past, companies would have to purchase relatively expensive enterprise application integration (EAI) or messaging middleware to enable integration between various applications. In contrast, “web services” are based on the standard protocols and technology of the Internet and provide a low-cost solution for enabling integration between all applications. Consequently, over the past couple of years, web services have begun playing a major role in application integration and today most EAI and messaging middleware providers support web services. While web services remove many of the technology hurdles for integrating CIS and AMI applications, the design of the services provided in the interface is crucial to automation of business processes.
service design and business process management
For an AMI system to provide a versatile automation interface, the services should be designed with an appropriate level of granularity to become the building blocks needed to implement different utility business processes. The combination of services into a business process is typically referred to as business process management (BPM). BPM allows logically related actions to be defined, ordered and processed according to rules that govern the execution and handling of exceptions. BPM systems (BPMS) that provide extensive modeling tools and rule specification tools can be purchased for use across all utility systems. An AMI system at a minimum should provide basic BPM capabilities to define a business process as a sequence of AMI services with rules that govern their execution. The AMI system should not require a utility to purchase a BPMS to implement their AMI-related business processes. Any business process may have multiple actions that need to be performed by the AMI system in a specific order.
For example, “Customer Move In” business process might involve the following sequence of AMI services:
“- Create the customer to meter association
“- Reconfigure the meter for the customer’s specific billing determinants
“- Perform a remote “initial” meter read for billing
“- Remotely or virtually reconnect service to the meter
“- Assign the meter to data collection schedules for billing and monitoring
The AMI system should allow each step (service) in the business process to have basic rules that specify if the service is required to succeed for the business process to proceed. If a service is required to succeed, then a failure of this service will halt the operation of following services in the business process. The “sunny day” execution of an AMI business process is relatively straight forward to integrate with CIS. Complications arise in the integration when failures of the various steps in a business process occur and the integration has to provide a recovery path following a failure. To highlight this problem, a “Customer Move In” example is depicted in the chart. This example assumes that all steps (except Step 3) have a rule that requires their success in order to proceed with the business process execution. The rule at Step 3 allows the execution of the business process to continue independent of the success or failure of this step. In this example, assume that during the initial execution (Pass 1) Steps 1 and 2 succeed but Steps 3 and 4 fail, due to WAN communication problems. As depicted, this business process will proceed through the failure at Step 3 and terminate at Step 4 based upon the execution rules. The remaining service of this business process (Step 5) is not executed due to this failure. Following the termination of the business process, the AMI system should provide the overall status of the business process and more detailed status of each executed step (service).
To simplify CIS integration, the design of each service in a business process should be stateless, and the business process should be reentrant. Examine the failure at Step 4 in the “Customer Move In” business process depicted in the chart. When the WAN maintenance completes, then it should be possible for the CIS to resubmit the business process as previously defined without any modification (i.e. the business process is reentrant). This is shown in the chart as Pass 2. For this business process to be reentrant, Step 1 must succeed even though the customer to meter association has already been created during Pass 1. The AMI system service should not force the CIS to remember the state of this particular association. A stateless service abstracts the implementation details and requires the user of the service to specify only the desired state. In this case the desired state is to establish an association between the meter and customer. Therefore, the AMI system should take the necessary actions to implement the user specified state of the service. As shown, no action is required at Step 1 during Pass 2, since this service succeeded during Pass 1. Therefore, at the time of Pass 2 the current state of the meter to customer association in the AMI system is already the user’s desired state. Thus the “Customer Move In” business process can succeed without any modifications after the WAN failure is corrected because each step in the process is stateless, which enables the business process to be reentrant.
This article only provides a general overview of some AMI interface capabilities and attributes to look for when integrating to a CIS system. It should be clear that web services alone do not ensure easy integration. The design of the individual services should be granular enough to build upon, provide abstraction from the underlying implementation details, and facilitate simpler management of the process. Attention to these interface details in the planning stages can help utilities deploy AMI systems that will ease the integration to CIS, and provide for a more complete automation of existing business processes.
Raymond Kelley is development manager for software and systems integration at Elster Electricity, LLC. He is responsible for managing the development of the EnergyAxis System.