The Advanced Meter Infrastructure ES bundle uses enterprise services to communicate between SAP backend systems and a metering system platform that is connected to smart meters, allowing information to flow back and forth between the call center, customer service department or backend office of a utility, and a customer’s electric meter. This ES bundle provides enterprise services that allow utilities to automate time-consuming and expensive manual tasks such as disconnecting/reconnecting a meter, uploading profile data from a meter, and uploading discrete meter readings.

SAP for Utilities now provides a way to communicate with an AMI through the Advanced Meter Infrastructure ES bundle. This ES bundle provides enterprise services that allow information to flow back and forth between the meters, the metering system platform (also known as the AMI), and SAP back-end systems. Using these enterprise services, utility companies can disconnect and reconnect customers, as well as uploading profile data from the AMI into SAP ERP 6.0. 
The SAP backend systems communicate with SAP NetWeaver Process Integration (SAP NetWeaver PI, formerly called XI, using the enterprise services in this ES bundle. Depending on the metering system platform in question, SAP NetWeaver Process Integration formats the XML message to transfer the data from the SAP backend systems to the metering system platform and back again.
In the case of a regulated electricity market (as in most U.S. states except Texas), a single utility would own the entire system landscape, including both the technical processes and the commercial processes shown in Figure 1. In a deregulated market (as in most of Europe), this infrastructure would be run by multiple businesses such as a power supplier, distributor, and meter reading company (see the Market Communication ES bundle for details on market role based approach to handling the complexity of deregulated utilities). This ES bundle’s enterprise services are the link between the technical and the commercial processes.

 

Figure 1. SAP AMI Integration for Utilities – Deregulated Market (click to enlarge)

Figure 2. SAP AMI Integration for Utilities – Regulated Market (click to enlarge)

For details on Service Operations, Business Objects and Process Components, see the ES Workplace.

 

How To Use This ES Bundle

This section will explore use cases for the Advanced Meter Infrastructure ES bundle. Each use case will show how different outcomes can be achieved by using the enterprise services in different combinations. While these examples illustrate a few of the ways that this ES bundle could be used, the intention is to show the flexibility and reusability of these business objects and enterprise services operations so that you will have a clearer understanding of how to best deploy them in your own environment. This wiki is also a space for you to share knowledge and collaborate with others who are implementing the Advanced Meter Infrastructure ES bundle.

 

Use Case 1: Device Initialization Process

Before a smart meter can be used, it must be initialized to set up a bidirectional communication between the smart meter, the MDUS, and SAP for Utilities.

The process starts when a clerk enters a goods receipt for the smart meter in SAP for Utilities, which also creates the device’s master data. At this point, SAP for Utilities sends a request to the MDUS system asking it to create a representation for the device in its system. This request is sent using the Request Utilities Device Smart Meter Creation enterprise service, whose business object is Utilities Device. The MDUS sends back a confirmation message, using the Change Based on Utilities Device Smart Meter Creation Confirmation enterprise service operation.

Later, when the smart meter is physically installed at the customer site, the MDUS system sends a notification back to SAP for Utilities using the Change Based on Utilities Device Smart Meter Registered Notification, telling SAP for Utilities that this meter has been registered within a specific AMI system and that it can now be used for subsequent processes.

Next, in SAP for Utilities, a clerk technically installs the smart meter. This process, with which users of SAP for Utilities will be familiar, involves assigning a measurement task to a device. A Utilities Measurement Task indicates why types of measurements should be taken using this device (for example, measuring consumption, energy, volume, or power periodically as indicated). It associates the physical meter with this measurement task, which can also be regarded as a logical representation of the meter’s function. Technical installation also includes configuring the meter in SAP for Utilities, specifying how many registers there are, for example, for measuring energy use during different time blocks, such as daytime and night time usage. Performing this task in SAP for Utilities invokes a request to the MDUS, which is executed by the Request Utilities Device Smart Meter Register Creation enterprise service operation. The MDUS then sends back a confirmation, using the Change Based on Utilities Device Smart Meter Register Creation Confirmation service operation.

If discrete meter readings are collected instead of interval data, SAP for Utilities sends out a request to the MDUS to collect meter readings. Alternatively it is possible to enter meter readings manually (the prerequisite for doing so is the activation of a BAdI) and provide them to MDUS. (For more information, see use case 3).

The device has now been both physically and technically installed; the final step is to install it from a billing perspective. At this point, the customer has a contract with you and the point of delivery has been assigned to this customer. SAP for Utilities informs the MDUS that the point of delivery (the customer premises) has been associated with this particular meter. SAP for Utilities communicates this information by invoking the Notify of Smart Meter Utilities Measurement Task Point Of Delivery Assigned enterprise service operation.

Note: If multiple devices or measurement tasks are involved, this triggers the corresponding bulk services.

The following table summarizes the steps in this use case and the associated Enterprise Services:

 

Use Case 2: Change Technical Master Data

In use case 1, we set up the smart meter so that it is functioning, reading consumption information for billing the customer. But even after a meter is installed, a company may decide that they want to change how they measure their customers’ consumption. For example, it may be that initially, total consumption by day was being measured. Now, however, they want to measure usage in two segments: daytime usage and nighttime usage. These segments are called registers and the registers are an attribute of the business object Utilities Device.

To change the number of registers, first the change is made in SAP for Utilities, which invokes the enterprise service Request Utilities Device Smart Meter Register Change is invoked. The MDUS makes the corresponding change in its metering infrastructure and then sends back a confirmation message: Change Based on Utilities Device Smart Meter Register Change Confirmation.

Please note: If multiple devices or measurement tasks are involved, this triggers the corresponding bulk services.

The following table summarizes the steps in this use case and the associated enterprise services:

 

Use Case 3: Discrete Meter Reading Process

To bill customers for consumption, you have to find out how much energy they have used. Discrete meter readings are required at specific points in time, for example business-related points in time such as the billing cycle or tariff changes, and technical points in time, such as device installation, device removal, and so on.

The discrete meter reading process can be executed in one of two ways:

1. If the meter reading originates from MDUS (remote meter reading, main use case): SAP requests meter reading results from MDUS.
2. If the meter reading originates from SAP (manual meter reading with entry in SAP, special use case for device installation/removal): SAP sends meter readings to MDUS.

Use Case 3a: SAP Requests Meter Readings from MDUS

In this use case, the utility company sends out a bulk request to read all the meters in a particular group (defined according to your setup) as of a given date, which can be a past or future date.

SAP for Utilities sends out this request to the MDUS by invoking the enterprise service Request Smart Meter Meter Reading Document Creation as Bulk. MDUS then acknowledges the request (perhaps the next day) by invoking Change Based on Smart Meter Meter Reading Document Creation Confirmation as Bulk enterprise service operation. However, this confirmation message is not simply an acknowledgment of the request; it also includes application level details, such as the fact that a particular point of delivery is not known to the MDUS. In other words, the MDUS is saying, I will read all the meters except for this one and the one for which I have no information. (In the optimum case, all meters are known to the MDUS and no such exceptions occur.)
The MDUS then reads the meters according to the date the read was requested: either as soon as possible (for a present or past date) or on the specified date (in the case of a future date). The MDUS sends the meter readings to SAP for Utilities by invoking the Create Meter Reading Document Result as Bulk enterprise service operation, which uses the Meter Reading Documentbusiness object. After SAP for Utilities has uploaded the meter reading documents, it sends a confirmation message back to the MDUS, invoking the Confirm Meter Reading Document Result Creation as Bulk enterprise service operation.

The following table summarizes the steps in this use case and the associated enterprise services:

 

If  the request for meter reading (“Meter Reading Order” in SAP’s terminology) is cancelled in SAP, a meter reading is no longer required. SAP informs MDUS about this cancellation:

 

Use Case 3b: Sending Meter Reading Results from SAP to MDUS

Supported for SAP ERP 6.0 EhP5 SP09, SAP ERP 6.0 EhP6 SP05 and all higher releases and support packages.

Generally smart meters are read remotely following the process steps in use case 3. There are some situations where AMI head end systems are not able to capture discrete meter reading results and forward them to MDUS. These are:

• Installation of smart meters
• Replacement of smart meters
• Removal of smart meters

In such cases, meter reading results manually taken by the service technician are entered in IS-U and then sent to MDUS. As soon as a meter reading result is communicated to MDUS, changes or cancellations of the meter reading result also have to be communicated to MDUS to keep data consistent between SAP and MDUS.
The main reason for providing these meter reading results to MDUS is that VEE processing takes place in MDUS. The meter reading result for device installation in particular is quite important for validation of subsequent meter reading results by MDUS.
As a prerequisite for this use case, BAdIs ISU_AMI_ATTR_MR and ISU_AMI_SEND_MR have to be activated.
In the first steps, a meter reading result is entered in SAP and communicated to MDUS:

 

To keep the data in SAP for Utilities and MDUS synchronized, changes of meter reading results in SAP for Utilities have to be communicated if they have previously been sent to the MDUS.

 

The installation / removal / replacement of a device can also be cancelled in SAP for Utilities. In this case, the previously sent meter reading results related to the device transaction are obsolete and cancelled in SAP for Utilities. To ensure that data remains consistent, SAP for Utilities sends a cancellation request to MDUS:

 

Use Case 4: Reading One Customer’s Meter: On Demand Read

A utilities customer is moving out (or changing suppliers), so this transition requires reading that customer’s meter on a certain date. This use case is very similar to use case 3, but it simply handles one customer versus a larger number.

SAP for Utilities sends out a request to read the customer’s meter on a given date to the MDUS by invoking the enterprise service Request Smart Meter Meter Reading Document Creation. MDUS then acknowledges the request by invoking Change based on Smart Meter Meter Reading Document Creation Confirmation enterprise service operation, either confirming that it will read the meter as scheduled or that it can’t read the meter in question because it doesn’t have POD data.

The MDUS then reads the meter on the date the read was requested: either as soon as possible (for a present or past date, since it is presumed that the MDUS has readings for past dates already stored) or on the specified date (in the case of a future date). The MDUS sends the meter reading to SAP for Utilities by invoking the Create Meter Reading Document Result enterprise service operation, which uses the Meter Reading Document business object. After SAP for Utilities has uploaded the meter reading document, it sends a confirmation message back to the MDUS, invoking the Confirm Meter Reading Document Result Creation enterprise service operation

The following table summarizes the steps in this use case and the associated enterprise services:

 

Use Case 5: Uploading Usage Data to SAP EDM

The services provided in this use case offer an updated set of enterprise services and improved underlying functionality, capable of processing interval usage data in a run-time-optimized way.

To create a bill in SAP ERP 6.0, information about utilities usage must be uploaded from the meter into SAP ERP 6.0. Live meters are able to collect usage data at regular intervals, for example every 15 minutes. This data is then uploaded to the AMI system usually once per day. Since bills are typically created monthly, the profile data is uploaded to SAP ERP 6.0 at least once a month. In the past, uploading profile data from the metering system platform into SAP for Utilities required a labor-intensive custom integration. Now, using enterprise services, the process is eased considerably. Furthermore, the uploading process can be monitored allowing navigation into the corresponding XML messages.

Profile data uploads are triggered on a regular schedule in order to produce a bill. The AMI system sends profle data as bulks to the SAP NetWeaver Process Integration, which then sends it to SAP backend systems by invoking the enterprise service Create Utilities Time Series Item As Bulk. All the profile data is then uploaded into SAP ERP 6.0, where it can be used to create the customer’s bill. As confirmation that the data was received, SAP ERP 6.0 in turn triggers the Confirm Utilities Time Series Item Creation As Bulk service operation, which is sent to SAP NetWeaver PI. PI then formats an XML message that sends a confirmation to the AMI system.

Related enterprise services can be used on an as-needed basis.

The following table summarizes the steps for performing an initial upload of prifile data and the associated enterprise services:

The following table summarizes the steps for performing a follow-up upload of profile data and the associated enterprise services.

 

Use Case 6a: Remotely Disconnecting and Reconnecting a Meter

This use case explains how a utility could use the AMI ES bundle to remotely disconnect a customer who has not paid his or her bill. It also explains how the services in this bundle can be used to remotely reconnect a customer once the bill has been paid.

A utility would employ the enterprise services in the Advanced Meter Infrastructure ES bundle to disconnect a meter only after following a defined process of trying to get the customer to pay the delinquent bill. The process begins when a utility sends a customer a regular monthly bill. If the customer does not pay the bill in a timely fashion, he or she will end up on a list of delinquent customers. As a result, the following process steps could be performed: escalating the bill to dunning level 1, which entails sending mail to the sales manager and a reminder to the customer. If the customer still does not pay the bill, the process moves to dunning level 2, which requires calling the customer and perhaps taking other measures such as load reduction.

Table 1. Sample Collection Strategy and Related Activities

If the customer still does not pay, the collection strategy escalates to dunning level 3 and the call center begins the disconnection process.

A call center employee logs onto SAP for Utilities. The employee then fills out and submits a disconnection document (see Figure 2) that details the ID of the meter to be disconnected and the date when service will end. This triggers the enterprise service Request Utilities Connection Status Change Request. The request is sent from SAP for Utilities to SAP NetWeaver PI. PI then formats an XML message with these details and sends it to the MDUS system. The MDUS system then transmits a message to the meter to switch itself off, using a communications technique such as GSM, GPRS, or broadband over power lines. The AMI system then sends an XML message back to SAP NetWeaver PI, which triggers the Change Utilities Connection Status Change Request based on Confirmation enterprise service operation, which confirms to SAP for Utilities that the meter has in fact been disconnected.

 

 

 

 

Figure 3. Disconnection screen (click to enlarge)

Reconnection

To reconnect service, the customer contacts the utility and pays the bill. The agent then fills out a reconnection form in SAP for Utilities (see Figure 3), which also triggers the Request Utilities Connection Status Change Request enterprise service operation, this time with a parameter that states that the meter should be reconnected. Power is remotely restored to the customer, and the meter sends back a message that triggers the Change Utilities Connection Status Change Request based on Confirmation enterprise service operation, which confirms the processing of the reconnection to the SAP backend system.

The following table summarizes the steps involved in disconnecting or reconnecting a customer and the associated enterprise services:

 

 

 

 

 

 

 

 

 

 
Figure 4. Reconnection screen (click to enlarge)

Use Case 6b: Manually Disconnecting and Reconnecting a Smart Meter

Communication of the disconnection status for manual disconnection and reconnection is supported for SAP ERP 6.0 EhP5 SP09, SAP ERP 6.0 EhP6 SP05 and all higher releases and support packages.

In contrast to Use Case 6a, the smart meter is not disconnected or reconnected remotely. Instead, a service technician disconnects and reconnects the smart meter manually. The change of disconnection status is sent to the external MDUS system so that MDUS can observe the disconnection status in VEE processing. If the disconnection status is not connected to MDUS, MDUS does not know the correct status and is not able to perform VEE processing.
Use Case 6b works similarly to 6a, and involves the following process steps:

 

Use Case 7: External Profile Calculation

To create a bill in SAP ERP 6.0, information about utilities usage must be uploaded from the meter to SAP ERP 6.0. For live meters registered in an AMI system, usage data is collected every 15 minutes. This data is then uploaded – usually once per day – to the AMI system. Since bills are typically created monthly, this profile data is then uploaded to SAP ERP 6.0 at least once a month. This profile data is used to bill customers on the basis of accurate and flexible time-of-use rates. A time-of-use rate allows you to record different price blocks per day (for example on, off, and critical peak times). SAP for Utilities supports two approaches for the time-of-use-based billing process. One approach uploads all profile data to the SAP for Utilities Energy Data Repository. The billing process accesses the profile data in the repository and performs actions such as the aggregation of profile values to retrieve the total consumption within a time-of-use block. The necessary services required for this process are listed in use case 8: Event Management. The second approach does not upload the profile data to SAP for Utilities. In this case, the data is kept in the external meter data repository and is accessed using an enterprise service. This service performs the requested action, such as an aggregation, directly in the external meter data repository and only returns the results to SAP for Utilities. The subsequent billing process catches the data and prepares a billing document.

The following table summarizes the steps in this use case and in the associated enterprise services.

 

Use Case 8: Event Management

Smart meters are able to communicate with an AMI Head End system and share information about their current status, as well as inform the head end system about events that have occurred (such as an outage or a meter malfunction). Selected events are forwarded from the head end to SAP for Utilities, where the event data is analyzed and follow-up actions are created. For example, in the case of a meter malfunction, SAP for Utilities can create a workforce order to repair the meter.

The following table summarizes the steps in this use case and in the associated enterprise services.

 

Use Case 9: Text Messaging to AMI Device

Modern smart meter devices are capable of receiving and displaying text messages sent out by SAP for Utilities. This feature allows the Utility to communicate in a new way for customers. For example, the Utility is able to inform the customer about the progress of inquiries or send out a dunning notice.

The following table summarizes the steps in this use case and in the associated enterprise services.

 

Certified Partner Applications implementing this ES Bundle

Certified Partner Applications for AMI

Source: