Understanding Advanced Meter Infrastructure

An advanced metering infrastructure is a communication network consisting of measurement devices and systems. An infrastructure of this nature is characterized by intensive interaction between the different market participants. These market participants can occupy different roles in the market. They exchange information according to these roles. The related information and data exchange processes virtually take place in real time.

Companies in the energy industry, associations, and government organizations choose an advanced metering infrastructure with the aim of increasing efficiency and optimizing grid usage as a result of improved evaluation options on the consumer side.

Advanced Metering Infrastructure (AMI) refers to systems that measure, collect and analyze energy usage from advanced devices (smart meters in electricity, gas and water) through various communication media either on request or on a predefined schedule. This infrastructure includes:

• Software
• Hardware
• Communication
• Customer associated systems
• Meter Data Management (MDM)

A smart meter generally refers to a type of advanced meter (usually electricity) that tracks consumption in more detail than a conventional meter and which may also communicate that information via a network back to the local utility for monitoring and billing purposes. Typical capabilities of an electric smart meter include the following:

• Ability to measure electricity, record consumption and meter event information electronically
• Ability to detect tampering
• Ability to detect outages
• Ability to perform remote connection and disconnection
• Monitoring of quality of supply
• Demand limiting
• Communication interface to devices

A smart grid delivers electricity from suppliers to consumers using digital technology to save energy, reduce cost, and increase reliability. It can be described as a digital upgrade of distribution and long-distance transmission grids to both optimize current operations, as well as open up new markets for alternative energy production.

You can use SAP Utilities as a customer information and billing system together with other SAP applications as part of an advanced metering infrastructure. The SAP system can communicate with other systems and exchange data.

The following diagram illustrates how the SAP applications are integrated in an advanced metering infrastructure.

The AMI system landscape illustrated is subdivided into three large areas:

On the left-hand side, the AMI systems, on the right-hand side, the SAP system as a back-office system, and in the middle, the MDUS system as an interface between the two.

The AMI systems on the left-hand side include devices with advanced metering capabilities, advanced metering systems (AMS), and other devices and systems, such as data concentrators. Advanced metering systems measure, gather, and analyze energy consumption data from AMI devices and transmit commands and data to these devices.

MDUS in the middle stands for Meter Data Unification & Synchronization and describes systems that unite the interfaces between different advanced metering systems and synchronize the data and processes in these systems with those in the back-office systems.

You can use the SAP system on the right-hand side to run the usual back-office processes, as well as processes and functions specific to an advanced metering infrastructure. Communication between the SAP applications and the MDUS system takes place using enterprise services.

Processes can only run fully if all the devices and systems in the advanced metering infrastructure meet the technical requirements and support the required capabilities. For this reason, the SAP Utilities processes are only possible if the required capabilities are supported both by the advanced metering system and by the device.

AMI Integration for Utilities delivers specific enterprise services to support standard utility processes that eliminate manual labor, lower total cost of ownership, and differentiate your services. These enterprise services can integrate process-centric energy and business data across different systems. These include Automated Meter Reading (AMR) systems, Meter Data Management (MDM) systems, and Customer Information Systems (CIS). For example, you can:

• Remotely perform automatic connects, disconnects, and vendor switches electronically
• Read meters remotely – eliminating issues of premises access, travel time, and errors
• Offer billing services based on actual consumption data and meter reading
• Quickly identify faults and restore service via real-time readings of on-premises conditions
• Automatically interpret and implement curtailment and disconnection or reconnection orders

In the SAP Note 1754249, you can find more information related to the enterprise services used for SAP AMI Integration for Utilities: 1754249 - Frequently Asked Questions about AMI Integration with MDUS systems - SAP for Me.

Additionally, you can find AMI-related content in the SAP Help:

• SAP AMI Integration for Utilities: SAP Help Portal
• AMI Uses Cases S4HANA.pdf

In an advanced metering infrastructure, Master Data Exchange (MDE) is automatically enabled between the SAP back end and a Meter Data Unification and Synchronization system (MDUS system). Information related to certain activities involving the device will be transmitted to the MDUS system.

This involves activities such as:

• Creation of the device
• Creation of a device info record
• Installation of the device
• Removal of the device
• Replacement of the device
• Reversal of a device installation/removal/replacement
• Modification of a device
• Point of Delivery Change
• Change of the logical register number
• Updating the relevant AMS system of a device (inbound method)

The replication, notification, and creation of advanced meter-related master data are carried out by dedicated enterprise services. One of these actions may result in several services being called; each service is triggered within a specific Business Add-In that receives all the necessary information. Each service call is logged in a dedicated table which enables you to verify the success of the operation and also to identify the source of any errors.

An advanced meter is a device for measuring energy consumption as well as for managing and evaluating the measured data. An advanced meter can send and receive data and commands.

Depending on the role of your organization in the market and on whether you use the Plant Maintenance (PM) component from logistics, you map advanced meters in SAP Utilities either as devices or as device information records.

• Mapping advanced meters as devices

  If your organization communicates using the entire advanced metering infrastructure and you use the Plant Maintenance (PM) component, you map advanced meters as devices.

  A device corresponds to a piece of equipment in Plant Maintenance (PM). As soon as you create a device in SAP Utilities, the system simultaneously creates a piece of equipment in PM. This equipment is uniquely identified in the system by means of an equipment number and the combination of serial number and material number.

• Mapping advanced meters as device information records

  If you use SAP Utilities primarily as a customer information and billing system, or if you do not require the connection to Plant Maintenance (PM), you should enter advanced meters in the system as device information records. With device information records, you only manage device data that is required for the billing functions.

  In contrast to conventional meters, advanced meters have several technical features.

  An advanced meter is based on a special device category (meter, remote meter, counter, corrector, and other).

As opposed to device categories for conventional devices, the device category for advanced meters also has the following attributes:

• Advanced meter indicator:

  The advanced meter indicator ensures that devices or device information records created later for this device category are advanced meters.

  If a device category consists of multiple basic device categories, this setting ensures that any devices created later for this device category have an advanced meter.

• Determination group for advanced metering system:

  This determination group is used in the device or device information record to determine the relevant advanced metering system.

• Determination group for advanced meter capability group:

  This determination group is used in the device or device information record to determine the relevant advanced meter capability group.

  For more information on determination groups, see Customizing for SAP Utilities under Advanced Metering Infrastructure→Basic Settings→Define Advanced Meter Capabilities.

• If you have activated the business function Advanced Metering Infrastructure 2 (ISU_AMI_2), the device category has the following additional attribute for devices that can receive messages. The message attribute determination group is used in the device or device info record to determine the relevant message attribute. The attributes mentioned are displayed in the device category on the AMI Data tab page.

Advanced meters also have the following attributes in the SAP system:

• AMI device status

  When you create an advanced meter, the system assigns a special AMI device status to the device or the device information record. This status shows that the device is not disconnected.

• Advanced meter is active or inactive

  This attribute shows whether the device is installed and allocated to an advanced metering system.

• Advanced metering system (AMS) to which the advanced meter is connected

  Utilities topology will drive the type and number of advanced meter network technologies that would be utilized. The Advanced Meter System (AMS) provides the ability to define the different types of networks in the SAP AMI solution.

Advanced Meter System (AMS) will be defined on all the AMI enterprise services which provide the ability to route the service to the correct AMI network system.

• Advanced meter capability group (AMCG)

  Collection of advanced meter capabilities

• Activation Group for AMI Capabilities (AMICAG)

The Change AMI Activation Group App (or transaction EAMICAG) is provided to manage the ability to turn on and off capabilities of the smart meter. Configuration is required to define the different activation groups.

It is also possible to add additional tabs to store against the device, this was provided via the BADI ISU_DM_DEVICE. This could be utilized to capture the firmware of device and any additional details required.

With the BADI and BRF+, it is possible to provide business logic to ensure that the valid firmware version is entered.

Advanced meters can be used differently according to the expansion stage of the advanced metering infrastructure:

• As classical devices that display discrete measurement values:

  The meter reading process differs from the usual meter reading process in the following ways: You cannot change or delete AMI meter reading orders or enter, change, or delete AMI meter reading results. You can use the Business Add-In for defining attributes/settings in the dialog (ISU_AMI_ATTR_MR) to override this restriction. You have activated the business function Advanced Metering Infrastructure (ISU_AMI_1).

• As interval meters that measure and send profile values at regular intervals:

  You can upload this consumption data to SAP EDM periodically and manage it here using profiles. To upload profile data from an external system (such as the MDUS System) to the IS-U System, you have done the following: Activated the business functions Advanced Metering Infrastructure 1, 2 and 3 (ISU_AMI_1, ISU_AMI_2 and ISU_AMI_3); replicated device master data (for example, using the mass activity for AMI device synchronization EAMISYNC) to align the IS-U entries and entries from external systems; replicated profile headers using the transaction Profile Synchronization for AMI (EAMIPROFSYNC).

• In their full scope as an advanced meter that can send interval data and receive commands:

  Business processes in the SAP system can process all types of measurement data.

  

• The table MR Document is enhanced with the field, AMS.
• This field is filled with the corresponding information in the device during meter reading order creation.
• The new field, TRANSSTAT is appended to the table, EABL.
• The new field, TRANSDATE is appended to the table, EABL.
• The new field, TRANSTIME is appended to the table, EABL.
• All these fields are visible in the transactions:
  • Display Meter Reading Order
  • Display Meter Reading Result
• These fields are also visible in the entry screens of the meter reading area.

The AMS field ensures the correct and efficient routing of the meter reading request via the exchange infrastructure.

The TRANSTAT field stores additional information about the status of the executed transmission procedures (services) and meter reading orders.

The TRANSDATE and TRANSTIME fields are used to store the information about the moment when the transmission procedures (services) ends successfully.

Two different services are used to send meter read requests to the MDUS:

• The individual meter read request service is used when a meter read order is created:
  • Using a specific meter/installation as the selection criterion; and
  • The meter has only one activated non-interval register (activated means not marked as "do not read").
• The bulk meter read request service is used when meter read orders are created:
  • Using meter read units (MRUs) as selection criteria; or
  • The individual meter has more than one activated non-interval register.

The timing of the calling of the service proxy (and thus sending of request messages to the MDUS) depends upon how the meter read orders are created.

• The system calls the service proxy immediately if individual installations/meters are used in the selection criteria for meter read order creation.
• The system does not call the service proxy immediately when meter read units (MRUs) are used in the selection criteria for meter read order creation. In this case, one of the following processes must be initiated in order to send the request messages to the MDUS: Meter Reading Order Output App (EL35 mass dispatch) and Execute Order Output App (EL16 mass parallel dispatch).

The sending of the meter readings back to SAP for Utilities is a proxy implementation, which calls a class method on the SAP for Utilities side.

A confirmation message is always sent to the MDUS regardless of whether the read posts successfully into SAP.

• If the read does post successfully, SAP sends a positive confirmation.
• If the read does not post successfully, SAP sends a negative confirmation.
• The payload/content of the message indicates whether the confirmation is positive or negative.

The process of sending the confirmation message to the MDUS is carried out in a BAdI within SAP although the customer can affect the within BAdI whether/when this confirmation should be sent.

• If MR orders are cancelled with transaction EL37 on IS-U side and the concerning MRR was already sent to the AMS, a cancellation message to the MDUS is sent.
• MDUS then suppresses the ‘send meter readings’ service, which means a previously sent meter reading request is cancelled by sending a corresponding cancel request.
• The sending of the cancellation message is suppressed if the meter read request was never sent from SAP to the MDUS in the first place, or if SAP has already received the results.
• The corresponding confirmation message is sent by the MDUS, which confirms that the request has been cancelled successfully or informs about errors which have occurred.

The direct deletion will be retained, but, in future, the deleted meter reading orders (EABL and EABLG) shall be temporarily stored in a new data base EABLC and EABLGC.

At the moment when a successful confirmation from the MDUS arrives, the data records shall be deleted in EABLC and EABLGC.

In case of negative confirmation, the transmission status of the data records EABLC shall be maintained accordingly.

Furthermore, to guarantee the trace back of processes and to reproduce and explain complex data constellations, it's necessary to log the data transfer between SAP for Utilities and AMS.

For interval meters, SAP for Utilities offers two alternatives to get usage of a Time-of-Use billing:

• Alternative 1 – The Interval meter readings are stored in an external system (MDUS)

  For the aggregation of interval values, SAP for Utilities sends requests to MDUS in order to execute a formula remotely. This formula is executed on the level of the MDUS and performs elementary actions like the aggregation or determination of a peak demand value. The results of the formula execution are submitted back to SAP for Utilities and used to influence the billing schema execution.

  In the case of externally stored profile values, the formula interface is represented in SAP, whereas the formula algorithm is implemented in the MDUS system.

  Only the basic information of a formula like the input and output parameters are available in the SAP for Utilities system.

  Time of use blocks are defined in the SAP for Utilities and assigned to a MDUS formula. Formula parameters can be used in order to influence the formula execution. The parameters can be assigned to fixed values or they are determined dynamically based on the available customer data in the SAP for Utilities system. The disadvantage of this approach is that the billing process is separated into two parts. The first part prepares the MDUS requests and sends out the web service requests, and the second part is the traditional billing process based on the results send from the MDUS. The request process is designed as an asynchronous process.

  This means that the MDUS can plan and schedule the execution of the formulas and return the result values at their own convenience. Once the requested values are received by SAP for Utilities, the values are assigned to operand values of the billing. The billing itself is than carried out likewise a common RTP billing. The separation of billing process into two parts has a significant impact on online processes like bill correction or a move-out bill. These processes cannot be executed as usual because the aggregation requests must be answered before the execution.

  The advantage of this approach is that all measurement data is stored and kept only in the MDUS system! Only aggregates are stored in SAP for Utilities.

• Alternative 2 – The Interval meter readings are stored in the SAP for Utilities Energy Data Repository (SAP EDM).

  To bill a customer, the interval reading values must be aggregated according to the definition of the time-of-use buckets. If for example a time-of-use bucket is defined for all weekdays starting from 8:00 am till 6:30 pm, the consumption for exactly this time period must be extracted from the interval meter reading data and aggregated accordingly.

  For the aggregation of interval values, SAP for Utilities executes during the billing process so-called Time-of-Use formulas. The formula performs elementary actions like the consumption aggregation or determination of a peak demand value for a given time-of-use bucket. The results are returned by the formula and influence the execution of the billing schema.

  • The formula interface and the algorithm is implemented in SAP and executed synchronously whenever a billing run is performed for a customer.
  • The Time of Use blocks are defined in the SAP for Utilities and assigned to a Time-of-Use formula. Formula parameters can be used in order to influence the formula execution. The parameters can be assigned to fixed values, or they are determined dynamically based on the available customer data in the SAP for Utilities system.
  • The advantage of this approach is that the billing process is executed as it is usually. There is no external request nor an additional asynchronous execution step. During the billing process, the Time-of-Use formulas are called directly, and the result values of the formula are assigned to RTP operands.
  • The disadvantage is that the interval values must be transferred into the SAP EDM, which might be lead to a high data volume in the system. Nevertheless, the interval data is only necessary for billing purposes and can be deleted after a short retention period. The original interval data is still available in the MDUS. The upload process of interval data into SAP for Utilities has been significantly improved.

One of the objectives of AMI enabling is enhancing customer service and reducing cost associated with customer service. A large cost factor in customer service is the so-called "truck rolls" when a service crew needs to be dispatched to a customer site. One of the various reasons for this is to verify a presumed outage. This cost can be reduced dramatically when the technology in place with AMI is utilized to allow, for example, the call center agent or the end customers themselves to make better decisions on the necessity of such truck rolls. An example of this is checking the status of the installation to check if there is an outage or not.

• On-Demand Status functionality is introduced to remotely check current device status.
• On-Demand Status is the functionality to remotely request the current overall operational state of the meter whenever required.
• On-Demand Status gives information on current overall operational state of the meter.
• On-Demand request of meter status (sometimes referred to as a "ping") determines whether the meter is measuring the commodity (electricity, gas, water, etc.) and whether this commodity is available to the end customer.
• On-Demand Status also informs about the communication state between the meter and MDUS (Meter Data Unification & Synchronization System).
• On-Demand Status also sends information as to whether the device is connected or not.
• Additional data can be sent by the device or MDUS, for example power quality data.
• This functionality is available in SAP S/4HANA Utilities as well as CX solutions.

For remote connection and disconnection processes, AMI provide additional functionality. You can select an advanced meter for remote disconnection or reconnection and trigger the disconnection or reconnection, either immediately or on a planned date. No service order is generated, and a service person does not need to show up at the premise. A Customer Service Representative agrees on a final payment with the customer so that the meter won’t be disconnected, or the Customer Service Representative informs the customer about the date of the disconnection.

Remote disconnections and reconnections can also be carried out on:

• non-AMI devices that are controlled by AMI devices (such as breakers)
• AMI devices without remote disconnection and reconnection capability, which are controlled by AMI devices (such as breakers)

In these cases, these devices inherit the capability for remote disconnection and reconnection, and the system displays these devices as remote disconnection and reconnection capable. Disconnection processes can be triggered upon customer request or by dunning processes. Reconnection processes can be triggered on customer request or by payment and clearing processes.

The disconnection and reconnection feature is available if you have implemented the corresponding Business Add-In, Disconnect/Reconnect for AMI (ISU_AMI_DISCONNECT), and you have also implemented a service to request the remote disconnection of the device. However, if you have activated the Business Function Advanced Metering Infrastructure 2 (ISU_AMI_2), the above-mentioned setting is not necessary. In this case, disconnection/reconnection via services is carried out automatically.

Event messages can originate from meters, concentrators, the head end, or the MDUS system; they should result in automatic follow-up actions in the SAP system. These follow-up actions depend on the triggering event type: A meter error might – for example – result in a service order. Utility companies have to be able to flexibly configure these follow-up actions.

The SAP AMI Event Management functionality allows utilities to flexibly define business rules controlling how the SAP system reacts on messages triggered by all types of events. As a result, various different types of actions can be triggered. Predefined action types are:

• Create notification
• Create service order
• Create compatible unit order
• Create customer contact (and thus a customer interaction record in SAP CRM)
• Create a case in Business Process Exception Management BPEM
• Start a workflow, for example to notify user.

Based on these action types, utility companies are able to define their own individual actions to trigger follow-up processes. Utilities can also define their own action types if they need to run follow-up processes in other systems. As the AMI Event Management is based on the SAP NetWeaver Business Rules Framework BRFplus that allow customers to define their own rules, actions and action types.

For each event type, a corresponding BRFplus function is defined in the Customizing. Processing an event executes the corresponding function based on the specific event parameters (including additional attributes).

The processed BRFplus function typically returns one or more results. For example, the default configuration processing event type, ‘Missing Meter Reading’, leads to the creation of a service notification if the value of additional attribute ‘Duration’ is at least one day.

The execution of a BRFplus function - more precisely, the processing of a ruleset within a function - can be intentionally interrupted. In this case, the event is in an ‘Interrupted’ state and processing can be resumed later by reprocessing the event.

If errors occur during the processing of an event, any changes made during processing are rolled back and the event is stored in an ‘Error’ state. A typical example for an error would be that no business partner could be determined for the equipment number, that invalid parameters were passed to a BRFplus expression such as ‘Create Service Order’, or that a BRFplus ruleset was open by the user in ‘Edit’ mode and therefore cannot be processed. Events in an ‘Error’ state can be reprocessed, typically after the problem causing the error has been resolved.

Events in the ‘New’, ‘Interrupted’, and ‘Error’ states can be canceled. After an event has been canceled, it can no longer be processed.

SAP AMI Function provides Monitor AMI Events App (or transaction EAMIEVTMON01) is provided to select, filter and view events. It also provides the ability to view the events from the smart meter.

Once the smart meters have been installed, it is important to monitor the status of the smart meter. Monitoring the status of the smart meter will provide the ability to determine when and what functions need to be turned on and off. Defining user status for the smart meter will provide the ability to monitor the status of the smart meter.

If you have activated Business Function Advanced Metering Infrastructure 2 (ISU_AMI_2), you can monitor the data exchange with the Monitor AMI Communication app.

You can use this monitor to display the formatted data from the Log for Service Communication in AMI Environment and Messages for Service Communication tables, and confirm incorrect entries.

SAP Cloud for Energy is SAP's energy and water data management solution in the cloud, based on the SAP Business Technology Platform (SAP BTP).

The following are the main features:

• Central repository for large volumes of measurement data in the cloud
• APIs based on standard for the energy industry (CIM - Common Information Model)
• Services with which applications can manage and access measurement data for their business processes as well as calculate billing determinants
• Integration to SAP S/4HANA Utilities or SAP Utilities as part of SAP ERP (ECC)

In addition, SAP Cloud for Energy provides an infrastructure that allows SAP customers and partners to create their own cloud applications to support new business models.

SAP Cloud for Energy consists of the following building blocks:

• Energy Data Services
• Integration to SAP S/4HANA Utilities or SAP Utilities as part of SAP ERP (ECC) (referred to as SAP Utilities throughout the rest of the guide)

Energy Data Services is SAP Cloud for Energy's core component that provides interfaces (APIs) to manage measurement data and related meter master data and store it in the cloud, as well as calculate billing determinants to enable standard billing of various rates and charges. The Energy Data Services API is based on the Common Information Model (CIM), which is a standard for energy markets.

Incoming measurement data is automatically validated and can be monitored using various apps.

The predefined integration connects your SAP Utilities system to SAP Cloud for Energy and enables the replication of meter master data from the SAP Utilities system to SAP Cloud for Energy using existing enterprise services. During the replication, the integration component maps the data to the CIM objects in SAP Cloud for Energy.

To enable time-of-use billing in your SAP Utilities system on the basis of measurement data stored in SAP Cloud for Energy, you can replicate profile header data from the SAP Utilities system to SAP Cloud for Energy using existing enterprise services, and you can request and receive billing determinants from SAP Cloud for Energy.

You can also manage meter reading time series with SAP Cloud for Energy and use this data as the basis for your business processes in SAP Utilities, such as billing or device installations/removals. In such an integration scenario, you can request meter readings from SAP Cloud for Energy when there is a specific meter reading reason.

This is the basic usage scenario which comprises only the core component of SAP Cloud for Energy: Energy Data Services.

In this usage scenario, the following types of data are managed:

• Measurement data
• Meter master data

As measurement data is always connected to measuring devices, Energy Data Services also stores meter master data. You ingest the data using the Energy Data Services API.

• Everything you need to know as a cloud administrator to set up and run SAP Cloud for Energy: Overview: SAP Help Portal
• Onboarding for SAP Cloud for Energy: Onboarding: SAP Help Portal
• What you need to know about the Energy Data Services API: Energy Data Services API: SAP Help Portal
• Ingest meter master data
• Ingest measurement data
• What you need to know about the Billing Integration API: Billing Integration API: SAP Help Portal

You have an SAP S/4HANA Utilities or SAP Utilities as part of SAP ERP (ECC) system (referred to as SAP Utilities throughout the rest of this document), and you want to store and manage the measurement data in the cloud.

This usage scenario comprises both components of SAP Cloud for Energy: Energy Data Services and the integration to SAP Utilities. In this usage scenario, the SAP Utilities system is the leading system for all technical master data. Measurement data can come from any data source.

SAP Cloud for Energy offers the following integration scenarios:

In this usage scenario, the following data is managed:

• Measurement data
• Meter master data

  As measurement data is always connected to measuring devices, Energy Data Services also stores meter master data.

• Profile header data

  This is only relevant for the integration scenario where you request billing determinants from SAP Cloud for Energy for time-of-use billing in SAP Utilities.

  As time series measurement data is connected to profile headers in the SAP Utilities system, Energy Data Services also stores profile header data in the ReadingProfile.

You replicate meter master data and profile header data using existing enterprise services of SAP AMI Integration for Utilities.

You ingest measurement data using the Energy Data Services API.

• Everything you need to know as a cloud administrator to set up and run SAP Cloud for Energy: SAP Cloud for Energy Administration Guide: Overview SAP Help Portal
• Onboarding for SAP Cloud for Energy: Onboarding: SAP Help Portal
• Set up the integration between SAP Utilities and SAP Cloud for Energy: Connecting to SAP Utilities (Relevant for Integration Scenarios): SAP Help Portal
• What you need to know about the Energy Data Services API: Energy Data Services API: SAP Help Portal
• Initial load of meter master data from SAP Utilities to SAP Cloud for Energy using the AMI Device Synchronization (transaction EAMISYNC)
• Optional - Initial load of profile header data from SAP Utilities to SAP Cloud for Energy using the Profile Synchronization (transaction EAMIPROFSYNC)
• Measurement data ingestion using the Energy Data Services API:Measurement Data Ingestion: SAP Help Portal

You can find more information about SAP Cloud for Energy in SAP Help: SAP Cloud for Energy: SAP Help Portal