Application integration in utility smart metering using AWS

Introduction

Power distribution utilities implement information and operational technology (IT/OT) applications to manage power distribution commercial activities and grid operations. These IT/OT applications include billing, customer care, smart metering, advanced distribution management systems (ADMS), supervisory control and data acquisition (SCADA), and outage management systems (OMS). In order to successfully run business processes – such as outage identification and restoration, billing adjustments, customer move-ins/move-outs, meter swaps, distribution grid demand forecasting, and more – utilities have to integrate data between these applications. Among these, the smart metering system is a major source of data, which is essential to these processes. Utilities can now leverage cloud-based integration services rather than implementing a full-fledged enterprise service bus.

This blog post gives an overview of sample use cases related to smart metering integration and AWS services that can be used to integrate utility systems with smart metering (also known as advanced metering infrastructure or AMI) implementations.

The primary audience for this blog post is power distribution utilities that are implementing legacy smart metering solutions (AMI 1.0) and evaluating running on AWS as an option, or those that have implemented on AWS already and are in the process of expanding integration points with other utility systems. This post also covers an architecture that can be used for the upcoming AMI 2.0 generation of smart metering systems, which leverage AWS serverless and IoT services.

Utilities’ metering-related applications to be integrated

To successfully deploy and manage smart metering, utilities must implement a core smart metering “ecosystem,” which includes the meters themselves, the meter data collection network, and the head-end system (HES). They must also integrate with several existing utility applications:

Primary integrations for meter to cash processes:

• Meter data management system (MDMS) – This could be an existing one capable of handling smart meter data, or a new one installed as part of the smart metering ecosystem.
• Billing and customer care systems (CIS/CRM) to handle revenue management (metering, billing, collection, connection management) and customer relationship management.
• Other HES, if any implemented, of types different from the core AMI system.

Additional integrations:

• Work order management and mobile field force app to manage the mass smart meter rollout and ongoing maintenance.
• Geographical information systems.
• Business intelligence dashboards.

Metering-related integration use cases for legacy AMI implementations

In order to identify the AWS services required for smart metering integrations with utility applications, consider the following use cases. There can certainly be more use cases, but these will suffice to provide insights into the most common and applicable integration methods.

Primary meter data integration uses:

Daily meter data for routine billing: A key use case for an MDMS integration is with billing and customer care systems in order to bill consumers using smart meter reads. Based on the billing date of consumers, the MDMS sends an API request for all consumers scheduled to be billed on a given day. The MDMS responds back to the billing and customer care system with the billing determinants for all consumers for whom a request is received.

1. The billing and customer care system sends an API request to a REST API configured in Amazon API Gateway. The request will contain consumer unique identification numbers or meter numbers for which billing determinants are needed (consumers scheduled to be billed on specific days as per a monthly/bimonthly cycle).
2. Amazon API Gateway will have an API configured with the integration type as HTTP, and the endpoint as the MDMS API. Amazon API Gateway can also be configured with a throttling rate for the API so that the API request load coming from the billing and customer care system to the MDMS can be throttled by Amazon API Gateway.
3. For those sets of consumers requested by billing and customer care, the MDMS extracts the billing determinants from the MDMS database and responds back as an API call to the API gateway configured on Amazon API Gateway. Amazon API Gateway will have an API configured with integration type as HTTP, and the endpoint as the billing and customer care system API. The MDMS sends the billing determinants through Amazon API Gateway to billing and customer care in multiple batches. The billing determinants are sent in multiple batches due to two reasons: (1) large number of consumers are split into multiple batches to optimize loading on the MDMS and billing and customer care system and (2) where latest reads are not available in the MDMS database, missing reads are obtained by the MDMS through retries, and reads received through successful retries are sent as multiple batches to the billing and customer care system.
4. Alternatively, integration for a batch billing use case also happen through files exchanged over Secure File Transfer Protocol (SFTP). AWS Transfer Family using SFTP can be configured to create a server with user credentials for the MDMS along security policies. The MDMS can send multiple files with a predefined naming convention (with each file containing the billing determinants of multiple meters) to the specified directory in AWS Transfer Family using SFTP, which in turn can be stored in Amazon Simple Storage Service (Amazon S3) or Amazon Elastic File System (Amazon EFS). The billing system can read files from the specified location and process the reads for billing.

Figure 1: Primary meter data integration uses cases. A hybrid on-premises / AWS scenario is shown, but all systems can be AWS based

Meter data to data lake: When analyzed, meter data, which includes different types of reads such as kilowatt (KW), kilovolt-ampere reactive (KVAR), and voltage as well as multiple parameters and events/alarms, can help utilities build both customer and grid operational insights. This meter data, with different types of reads captured at different frequencies, when accumulated over months and years, runs into petabytes of data. To efficiently analyze this data, utilities can send the data to a data lake, which then gives the agility to run advanced analytics including ML use cases on it.  For more on this, refer to our blog on Meter Data Analytics (MDA) and the MDA Reference Architecture and Quick Start to help quickly build and deploy MDA solutions.

Additional meter data integration uses case examples

On-demand read for off-cycle transactions: Off-cycle transactions like for moving into a new place involve on-demand read, which is initiated by the billing and customer care system. Once the consumer request for a move in is recorded in the billing and customer care system, an API request is placed from the billing and customer system on the MDMS, which then initiates an API request to the HES to get the reading from the smart meter. The response again flows back from the HES to the MDMS to the billing and customer care system.

1. The billing and customer care system sends an API request to a REST API configured in Amazon API Gateway. Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale.
2. Amazon API Gateway will have an API configured with the integration type as HTTP and the endpoint as the MDMS API. Amazon API Gateway can also be configured with a throttling rate for the API so that the API request load coming from the billing and customer care system to the MDMS can be throttled by Amazon API Gateway.
3. The MDMS sends the request to the HES for an on-demand read, and the response from the HES is sent back to MDMS and then to the billing and customer care system.

Figure 2: Additional meter data integration uses case examples. A hybrid on-premises/AWS scenario is shown, but all systems can be AWS based.

Outage and restore alarms: Outage and restore alarms from smart meters help in utilities’ outage identification process. Outage and restore alarms are sent by smart meters to the HES and then from the HES to the MDMS. The MDMS sends these to the OMS, which corelates the alarms with grid-level outages to identify consumers whose lights are out.

1. When a smart meter sends an outage alarm to the HES with the meter number and alarm date and time, the HES sends this to the MDMS. The integration method between the HES and MDMS for alarms varies based on the applications.
2. The MDMS can send this outage alarm to an Amazon Simple Queue Service (Amazon SQS) Amazon SQS is a serverless queuing service that can handle millions of messages and scales up and down on its own to handle the load.
3. The OMS can pull messages from the Amazon SQS queue and process the messages for use cases like identifying consumers whose lights are out.

The integration methods mentioned with the use cases are examples, and the exact methods can be finalized during the design phase. Since there can be more than one HES, and the billing and customer care system involved, it is important that the integration effort is minimized by using the integration layer approach instead of point-to-point integration. This will also reduce operational and maintenance overhead, especially if the integration layer employs services that are fully managed by AWS. During implementation, it is also important to define a common data format (with mandatory and optional parameters) that can be supported by multiple source and destination systems. Some of the best practices that should be considered while defining the integration architecture are:

Loosely coupled services: Loose coupling helps isolate the behavior of a component from other components that depend on it, increasing resiliency and agility. Integration services such as queuing systems, streaming systems, workflows, and load balancers are loosely coupled and can be implemented based on requirement. While some architectures need all of these integration services, some might need one or two of these services. Implementation can be limited only to those two services, thus reducing the overall efforts and time for implementation.

Event-driven architecture: An event-driven architecture uses events to launch and communicate between decoupled services and is common in modern applications built with microservices. In an event driven architecture, you don’t have to write code to poll, filter and route events. Instead, this is handled by the event router to automatically filter and push events.

The AWS Well-Architected Framework covers best practices of cloud-based implementation and provides a consistent approach for customers and AWS Partners to evaluate architectures and implement designs that can scale over time.

AWS-based services for AMI 2.0

Advanced metering infrastructure (AMI) or smart metering has evolved over the past two decades with advancement in technology at edge devices, in the cloud, and in the communications and enterprise layers. The next generation of smart metering systems, dubbed AMI 2.0, will take advantage of these advancements. When rolling out new smart metering, important architectural decision considerations are (1) the solution should be resilient and automatically scale to multiple millions of endpoints, (2) the solution should minimize the overhead to maintain and operate metering solutions, (3) the solution should allow for the ability to manage and run multiple metering- and energy-related applications at the edge (in-meter or behind the meter devices). This will reduce the operational overheads of managing the infrastructure required to run smart metering solutions, improve metering reliability, and enable value-added metering services at the edge. This can be achieved by using AWS serverless and IoT services. For instance, serverless services on AWS scale up and down automatically and need no infrastructure provisioning by customers, while AWS IoT services can significantly ease the management of the metering fleet with capabilities such as automated health, security patching, and over-the-air software distribution.

The following diagram gives an overview of AWS services that can support AMI 2.0 applications and the application integration. This can further be enhanced to address additional use cases based on customer-specific requirements.

Figure 3: AWS services for AMI 2.0

1. Smart meters can send meter data (interval meter reads, midnight meter reads, alarms, and events) to AWS IoT Core over MQTT, HTTPS, MQTT over WSS, and LoRaWAN. AWS IoT Greengrass can be used at a smart meter (or concentrator) to bring intelligence to edge devices, such as for anomaly detection or other applications.
2. The meter data sent by smart meters will be received by AWS IoT Core. AWS IoT Core is a serverless service and can automatically scale and up and down based on the load, and is fault tolerant. AWS IoT Device Defender brings in the security layer for auditing and monitoring devices connected to AWS IoT Core. It assesses the cloud configuration of your IoT device fleet, provides ongoing monitoring of device activities via rule-based and ML-based detection capabilities, initiates an alarm when an audit violation or behavior anomaly is identified, and empowers you to address issues quickly with built-in mitigation actions.
3. Once the data is received in AWS IoT Core, rules and actions can be defined to further process the data. The rules and actions can be one or more as depicted in the architecture above. A few use cases covered in the architecture are:
   1. All messages received in AWS IoT Core will be sent to Amazon S3 buckets for storage and to build a data lake for analytics and reporting.
   2. If the meter data received is an alarm (such as an outage, under voltage, etc.), then the rule can be applied to send the message to Amazon SQS.
   3. All messages received in AWS IoT Core will be sent to an AWS Lambda
4. All messages received in AWS IoT Core will be sent to an AWS Lambda function, which will then apply transformation where required (such as applying multiplying factor to KWh consumption), and then store the transformed data in Amazon DynamoDB. The meter data can be stored in Amazon DynamoDB for a shorter duration to facilitate faster access to the latest data for external utility applications. Amazon DynamoDB is a fully managed, serverless, key-value NoSQL database designed to run high-performance applications at any scale. Amazon DynamoDB offers built-in security, continuous backups, automated multi-Region replication, in-memory caching, and data export tools.
5. The near-real-time messages with smart meter alarms can be sent to Amazon SQS. There can be different queues for different types of alarms since the consuming application might be different. Alternatively, the message queues can be consolidated based on the consuming applications. For example, all alarms consumed by an OMS – such as outage/ last gasp, restore, L1 outage, L2 outage – can all be sent to one queue.
6. All messages received on AWS IoT Core will be sent to an Amazon S3 bucket in the form of objects. The meter data can be kept in separate buckets based on the type of data, such as all interval reads in one bucket or all midnight reads in another bucket. Amazon S3 will provide a foundation for a data lake, which can be the source to generate analytics. Amazon Athena can be used to query the data in a data lake, which will then be the data source for dashboards in Amazon QuickSight. The data lake can further be used in the future to run advanced analytics using AI/ML.
7. The data received from smart meters and stored in the persistence layer will be needed by external applications for multiple purposes. One of the methods to provide this data to external applications is using REST APIs. The REST APIs can be made available on Amazon API Gateway, which will have an AWS Lambda function as an integration type. The AWS Lambda function will retrieve the appropriate dataset from Amazon DynamoDB (and Amazon S3 where required), and give the response back to Amazon API Gateway for further processing.

Conclusion

Power distribution utilities that are considering cloud-based implementation of smart metering can opt for AWS Application Integration services for the exchange of data between smart metering solutions and other utility systems. AWS Application Integration services include serverless services that utilities do not have to provision or manage and that scale up and down automatically based on load. Serverless services have fault tolerance built in, which gives reliability levels needed to run integration services, especially for critical use cases related to smart metering. Power distribution utilities can also potentially save costs since serverless services are billed based on usage and never billed for idle resources.

In the context of AMI 2.0, power distribution utilities can benefit by reducing the time to develop, enhance, and implement smart metering solutions using services such as AWS IoT, Amazon S3, Amazon Athena, and Amazon QuickSight. The prebuilt integrations available in AWS IoT services, at both the edge layer and also the upstream layer, significantly reduce the time required for development and testing.

The AWS IoT rule actions, which specify what to do when a rule is invoked, include prebuilt integrations with other AWS services such as Amazon DynamoDB, AWS Lambda, and Amazon SQS as well as others including Amazon Kinesis Data Firehose, an extract, transform, and load service; Amazon Simple Notification Service (Amazon SNS), a fully managed messaging service; and AWS IoT Analytics, a fully managed service that makes it easy to run and operationalize sophisticated analytics on massive volumes of IoT data. These services can be configured based on the use case. Additionally, AWS services bring in agility to implement new use cases such as load forecasting or advanced ML on top of the smart metering dataset. On the edge side, AWS IoT Greengrass can be considered by device manufacturers (smart meter or concentrator manufacturers) as well since AWS IoT Greengrass makes it easy to perform ML inference locally on devices using models that are created, trained, and optimized in the cloud.

For more information on AWS support for smart metering integration, watch this re:Invent session or visit the AWS Power & Utilities website.