AWS を使用した公益事業用スマートメータリングへのアプリケーション統合

この投稿は、「Application integration in utility smart metering using AWS」を翻訳したものです。

はじめに

配電事業者は、情報および運用技術（IT/OT）アプリケーションを実装して、配電の商業活動と送配電網の運用・管理を行なっています。これらの IT/OT アプリケーションには、請求、カスタマーケア、スマートメータリング、高度配電管理システム（ADMS）、監視制御およびデータ収集（SCADA）、および停電管理システム（OMS）が含まれます。停電の特定と復旧、請求精算、顧客の加入・解約、メーターの交換、配電提供地域の需要予測などのビジネスプロセスを問題なく実行するには、電力会社はこれらのアプリケーション間でデータを統合する必要があります。その中でも、スマートメータリングシステムは、これらのプロセスに欠かせない主要なデータソースとなります。電力会社は、本格的なエンタープライズサービスバスを導入する代わりに、クラウドベースの統合サービスを活用できるようになりました。

このブログ記事では、スマートメーターシステムに関連するアプリケーション統合のユースケースとスマートメーターシステム（Advanced Metering Infrastructure、または単に AMI とも言います）とユーティリティ系のシステムを統合する場合に使用できる AWS サービスの概要を説明します。

このブログの想定読者は、従来のスマートメータリングソリューション (AMI 1.0) を導入していて、今後の選択肢のひとつとして AWS のクラウド基盤上で動作するスマートメータリングソリューションを検討、評価している配電事業者、または AWS にすでにシステムを実装しており、他のユーティリティシステムとの統合ポイントを拡張中の配電事業者を主として想定しています。さらにこの記事では、AWS のサーバーレスサービスと IoT サービスを活用する AMI 2.0 次世代スマートメータリングシステムに使用できるアーキテクチャについても説明します。

統合対象となるユーティリティのメータリング関連アプリケーション

スマートメータリングの導入と管理を成功させるには、電力会社はメーターデバイス本体、メーターデータ収集ネットワーク、ヘッドエンドシステム（HES）を含むスマートメータリングの中核となる「エコシステム」を実装する必要があります。また、いくつかの既存のユーティリティアプリケーションと統合する必要があります。

Meter-to-Cash (検針から入金まで）プロセスの主な統合:

メーターデータ管理システム（MDMS）— スマートメーターデータを処理できる既存のシステムでも、スマートメータリングエコシステムの一部としてインストールされた新しいシステムでもかまいません
託送収益管理（検針、請求、集金、接続管理）と顧客関係管理（CRM）を担う請求およびカスタマーケアシステム（託送CIS/CRM）
その他のコア AMI システムとは異なるタイプの HES（実装されている場合）

その他の統合対象:

スマートメーターの大量導入と継続的なメンテナンスを管理するための作業指示（ワークオーダー）管理と現地作業従業員（モバイルフィールドフォース）管理アプリケーション
位置情報システム（ GIS ）
ビジネスインテリジェンス（ BI ）ダッシュボード

レガシー AMI 導入のメータリング関連の統合ユースケース

スマートメータリングとユーティリティアプリケーションの統合に必要な AWS サービスを特定するには、以下のユースケースを参考にしてください。ユースケースは他にもあるかもしれませんが、最も一般的で適用可能な統合方法についての知見を得るには、まずはこれらで十分と考えます。

メーターデータ統合の主な利用例：

定期請求処理のための日次メーターデータ：MDMS との統合の主な使用例としては、スマートメーターの計量値を使用して消費者に請求するための「請求およびカスタマーケアシステム」との統合があげられます。MDMS は、消費者の請求日の設定に基づいて、該当日に請求が予定されているすべての消費者に対する API リクエストを送信します。MDMS は、リクエストを受けたすべての消費者に対する当該請求額決定の構成要素を請求およびカスタマーケアシステムに連携します。

請求およびカスタマーケアシステムは、Amazon API Gateway で設定された REST API の API リクエストを送信します。リクエストには、請求決定要素に紐づく消費者固有の識別番号またはメーター番号が含まれます（消費者は、毎月または隔月のサイクルに従って特定の日に請求されるものとします）。
Amazon API Gateway の API は、インテグレーションタイプが HTTP で MDMS API のエンドポイントとして設定されます。Amazon API Gateway には API のスロットリングレートを設定することもできます。これにより、請求およびカスタマーケアシステムから MDMS に送信される API リクエストの負荷をAmazon API Gateway で調整できます。
請求およびカスタマーケアからリクエストされた消費者リストから、MDMS は MDMS データベースから請求料金計算に必要な要素を抽出し、Amazon API Gateway に設定された API Gateway への API コールとして連携されます。Amazon API Gateway の API は、インテグレーションタイプが HTTP、エンドポイントが請求およびカスタマーケアシステム API として連携されます。MDMS は、Amazon API Gateway を介して請求料金計算に必要な要素を複数のバッチで請求およびカスタマーケアシステムに送信します。請求決定要素が複数のバッチで送信される理由は2つあります。(1) MDMSと請求およびカスタマーケアシステムへの負荷を最適化するために多数の消費者分を複数のバッチに分割すること、(2) MDMS データベースに最新の計量値がない場合、欠測している計量値は再試行によってMDMSによって取得され、この再試行により受信した計量値は請求およびカスタマーケアシステムに複数のバッチとして送信されます。
別の連携手法として、請求バッチ処理のユースケースの統合は、セキュアファイル転送プロトコル（SFTP）を介して交換されるファイルを介して行われることもあります。SFTP を使用する AWS Transfer Family は、セキュリティポリシーに従って MDMS 用のユーザー認証情報を使用してサーバーを作成するように設定できます。MDMS は、SFTP を使用して AWS Transfer Family の指定されたディレクトリに、あらかじめ定義された命名規則に従って複数のファイル (各ファイルには複数のメーターの請求要素を含む) を送信できます。送信したファイルは Amazon Simple Storage Service (Amazon S3) または Amazon Elastic File System (Amazon EFS) に保存できます。請求システムは、指定された場所からファイルを読み取り、その読み取りを処理して請求を行うことができます。

図１：メーターデータの代表的な利用例。オンプレミスとAWSのハイブリッドシナリオが示されていますが、すべてのシステムをAWSベースにすることも可能

メーターデータからデータレイクへ：キロワット（KW）、キロボルトアンペアリアクティブ（KVAR：キロバール）、電圧などのさまざまなタイプの計量値と同様に、複数のパラメータ、イベント/アラームを含んだメーターデータを分析すると、電力会社が顧客と電力網の両方の運用に関して洞察を得るのに役立ちます。このメーターデータは、さまざまな種類の計量をさまざまな頻度で収集し、数か月または数年にわたって蓄積すると、ペタバイト単位のデータになります。このデータを効率的に分析するために、電力会社はこれらのデータをデータレイクに蓄積します。データレイクでは、機械学習のユースケースを含む高度な分析を迅速に実行できます。詳細については、Meter Data Analytics（MDA）に関するブログと、MDA ソリューションの迅速な構築と導入に役立つ MDA Reference Architecture と Quick Start を参照してください。

メーターデータ統合のその他の使用事例

オフサイクルトランザクションのオンデマンド計量：新しい場所への転居などのオフサイクルトランザクションに対しては、請求およびカスタマーケアシステムはその処理をオンデマンド計量で対応します。消費者の入居済み申請が請求およびカスタマーケアシステムに記録されると、請求およびカスタマーケアシステムから MDMS に API リクエストが送信され、MDMS から HES へのAPIリクエストが開始され、スマートメーターからの計量が行われます。処理の応答は再び HES から MDMS へと戻り、さらに請求およびカスタマーケアシステムに戻ります。

請求およびカスタマーケアシステムは、Amazon API Gateway で設定された REST API の API リクエストを送信します。Amazon API Gateway は、開発者があらゆる規模で API を簡単に作成、公開、保守、監視、保護できるようにする完全マネージド型サービスです。
Amazon API Gateway では、API はインテグレーションタイプが HTTP、エンドポイントが MDMS API として設定されています。Amazon API Gateway には API のスロットリングレートを設定することもできます。これにより、請求およびカスタマーケアシステムから MDMS に送信される API リクエストの負荷を Amazon API Gateway で調整できます。
MDMS はリクエストを HES に送信してオンデマンド計量を要求し、HES からの応答は MDMS に送り返され、次に請求およびカスタマーケアシステムに送られます。

図2: その他のメーターデータ統合の使用事例。オンプレミスと AWS のハイブリッドシナリオが示されていますが、すべてのシステムを AWS ベースにすることも可能

停電および復旧アラーム：スマートメーターからの停電および復旧アラームは、電力会社による停電箇所特定プロセスに役立ちます。停電および復旧アラームは、スマートメーターによって HES に送信され、次に HES から MDMS に送信されます。MDMS はこれらを OMS（停電管理システム：Outage Management System）に送信し、OMS はアラームをグリッドレベルで停電と結び付けて、停電している消費者を特定します。

スマートメーターがメーター番号とアラーム日時とともに停電アラームを HES に送信すると、HES はこれを MDMS に送信します。HES と MDMS のアラームの統合方法は、アプリケーションによって異なります。
MDMS はこの停止アラームを Amazon Simple Queue Service (Amazon SQS) に送信できます。Amazon SQS は、何百万ものメッセージを処理できるサーバーレスのキューイングサービスであり、負荷を処理するために独自にスケールアップおよびスケールダウンできます。
OMS は Amazon SQS キューからメッセージを取得し、電気が失われている消費者を特定するなどの発生イベントに合わせてメッセージを処理します。

上記ユースケースに記載されている統合方法は一例ですが、実際の統合方法は設計段階で最終決定します。HES が複数あったり、請求システムとカスタマーケアシステムが連携する可能性もあるため、システム同士のポイントツーポイント（一対一）統合の代わりに統合レイヤアプローチという手法により統合にかかる労力を最小限に抑えることが重要です。特に統合レイヤが AWS のフルマネージド・サービスを採用している場合、運用とメンテナンスに必要な労力も削減できます。導入時には、複数の送信元システムと送信先システムでサポートできる共通のデータフォーマット（必須パラメータとオプションパラメータを含む）を定義することも重要です。統合アーキテクチャを定義する際に考慮すべきベストプラクティスには、次のようなものがあります。

疎結合サービス：疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、回復性（レジリエンシ）と俊敏性を高めます。キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーなどの統合サービスは疎結合であり、要件に基づいて実装することができます。これらの統合サービスをすべて必要とするアーキテクチャもあれば、これらのサービスを 1 つか 2 つ必要とするアーキテクチャもあります。設計方針として、例えば、この例のように実装時には2 つの統合サービスのみに限定することで、実装にかかる全体的な労力と時間を削減することが可能です。

イベント駆動型アーキテクチャ（Event-driven architecture）：イベント駆動型アーキテクチャは、イベントを使用して分離されたサービスを起動し、サービス間の通信を行います。これは、マイクロサービスで構築されたモダンアプリケーションでは一般的なアーキテクチャです。イベント駆動型アーキテクチャでは、イベントのポーリング、フィルタリング、ルーティングを行うコードを記述する必要はありません。代わりに、これらはイベントルーターによって処理され、イベントを自動的にフィルタリングしてプッシュします。

AWS Well-Architected Framework は、クラウドベースの実装のベストプラクティスを網羅しており、お客様と AWS パートナーがアーキテクチャを評価し、時間の経過とともに拡張可能な設計を実装するための一貫したアプローチを提供します。

AMI 2.0 向けの AWS ベースのサービス

アドバンスト・メータリング・インフラストラクチャ（AMI）またはスマート・メータリングは、エッジデバイス、クラウド、通信、業務における領域で技術の進歩とともに、過去 20 年間で進化してきました。AMI 2.0 と呼ばれる次世代のスマートメータリングシステムは、これらの進歩をベースにしています。新しいスマートメータリングを導入する際、アーキテクチャ上で検討、決定すべき重要な事項は、(1) ソリューションは回復性があり、数百万のエンドポイントまで自動的に拡張可能であること、(2) メータリングソリューションの保守と運用のオーバーヘッドが最小限に抑えられること、(3) メータリングおよびエネルギー関連の複数のアプリケーションをエッジ (メーター内またはメーターデバイスの後段) で管理および実行できるソリューションであることです。これにより、スマートメータリングソリューションを実行するために必要なインフラストラクチャの管理にかかる運用上のオーバーヘッドが削減され、メータリングの信頼性が向上し、エッジでの付加価値のあるメータリングサービスの実現が可能になります。これは、AWS のサーバーレスサービスと IoT サービスを使用することで実現できます。たとえば、AWS のサーバーレスサービスは自動的にスケールアップおよびスケールダウンされ、顧客によるインフラストラクチャのプロビジョニングは不要です。一方、AWS IoT サービスでは、自動診断、セキュリティパッチ、無線によるソフトウェア配布などの機能により、メータリング群の管理が大幅に簡単になります。

次の図は、AMI 2.0 アプリケーションとアプリケーション統合をサポートできる AWS サービスの概要を示しています。これをさらに強化して、顧客固有の要件に基づく他のユースケースにも対応できます。

図 3: AMI 2.0 向けの AWS サービス

スマートメーターは、メーターデータ (メーターの定期計量、深夜のメーター計量、アラーム、イベント) を MQTT、HTTPS、WSS 経由の MQTT、LoRaWAN 経由で AWS IoT Core に送信できます。AWS IoT Greengrass をスマートメーター (またはコンセントレータ) 上で利用して、異常検出やその他のアプリケーションなどを動作させて、エッジデバイスにインテリジェンスをもたらすことができます。
スマートメーターによって送信されたメーターデータは、AWS IoT Core によって受信されます。AWS IoT Core はサーバーレスサービスで、負荷に応じて自動的にスケールアップとスケールダウンが可能で、耐障害性があります。AWS IoT Device Defender は、AWS IoT Core に接続されたデバイスを監査および監視するためのセキュリティレイヤをもたらします。IoT デバイス群のクラウド構成を評価し、ルールベースおよび ML ベースの検出機能によってデバイスのアクティビティを継続的に監視し、監査違反または異常な動作が特定されるとアラームを発動し、ビルトインされた緩和アクションで問題に迅速に対処できるようにします。
データが AWS IoT Core で受信されると、ルールとアクションを定義してデータをさらに処理できます。ルールとアクションは、上記のアーキテクチャに示されているように 1 つ以上でもかまいません。このアーキテクチャでカバーされているユースケースは次のとおりです。
1. AWS IoT Core で受信したメッセージはすべて Amazon S3 バケットに送信され、保存され、分析とレポート用のデータレイクが構築されます。
2. 受信したメーターデータがアラーム (停電、低電圧など) の場合、ルールを適用してメッセージを Amazon SQS に送信できます。
3. AWS IoT Core で受信したすべてのメッセージは AWS Lambda に送信されます
AWS IoT Core で受信したすべてのメッセージは AWS Lambda 関数に送信され、この関数は必要に応じてデータ加工処理を実行し (KWh 指示値に乗率を適用するなど)、加工されたデータを Amazon DynamoDB に保存します。最新のメーターデータは Amazon DynamoDB に短期間保存されるため、その他のユーティリティアプリケーションがこの最新データに迅速にアクセスすることができます。Amazon DynamoDB は、あらゆる規模で高性能アプリケーションを実行できるように設計された、フルマネージド型のサーバーレスのキーバリュー型 NoSQL データベースです。Amazon DynamoDB には、組み込みセキュリティ、継続的バックアップ、自動マルチリージョンレプリケーション、インメモリキャッシュ、データエクスポートツールが備わっています。
スマートメーターの警告アラームを含む準リアルタイムのメッセージを Amazon SQS に送信できます。連携するアプリケーションが異なる場合があるため、アラームの種類ごとに異なるキューを定義する可能性があります。あるいは、連携するアプリケーションに基づいてメッセージキューを１つに統合することもできます。たとえば、OMS が使用するすべてのアラーム（停止/ Last Gasp、復旧、L1 障害、L2 障害など）をすべて１つのキューに送信できます。
AWS IoT Core で受信したすべてのメッセージは、オブジェクトの形式で Amazon S3 バケットに送信されます。メーターデータは、データのタイプに基づいて別々のバケットに保存できます。たとえば、あるバケットにはすべての定期計量値が、別のバケットにはすべての深夜計量値が保存されます。Amazon S3 は、分析を生成するためのソースとなるデータレイクの基盤となります。Amazon Athena を使用してデータレイク内のデータをクエリできます。データレイクは Amazon QuickSight のダッシュボードのデータソースになります。このデータレイクは、将来、AI/ML を使用した高度な分析を実行するためにさらに使用することができます。
スマートメーターから受信して永続レイヤに保存されたデータは、外部アプリケーションがさまざまな目的で必要とします。このデータを外部アプリケーションに提供する方法の 1 つは、REST API を使用することです。REST API は Amazon API Gateway で利用できるようになります。Amazon API Gateway には、インテグレーションタイプとして AWS Lambda 関数が指定できます。AWS Lambda 関数は Amazon DynamoDB（および必要に応じて Amazon S3）から適切なデータセットを取得し、その応答を Amazon API Gateway に返してさらに処理します。

まとめ

スマートメータリングのクラウドベースの実装を検討している配電事業者は、スマートメータリングソリューションと他のユーティリティシステム間のデータ連携に AWS Application Integration サービスを選択できます。AWS Application Integration サービスには、公益事業者がプロビジョニングや管理を行う必要がなく、負荷に応じて自動的にスケールアップやスケールダウンを行うサーバーレスサービスが含まれます。サーバーレスサービスには耐障害性が組み込まれているため、特にスマートメータリングに関連する重要なユースケースでは、統合サービスの実行に必要な信頼性レベルが得られます。サーバーレスサービスは使用量に基づいて請求され、アイドル状態のリソースについては請求されないため、多くの場合、配電事業者はコストを節約できます。

AMI 2.0 の観点から見ると、配電事業者は、AWS IoT、Amazon S3、Amazon Athena、Amazon QuickSight などのサービスを使用してスマートメータリングソリューションを開発、強化、実装する時間を短縮できるというメリットがあります。エッジレイヤとアップストリームレイヤの両方で、AWS IoT サービスで利用できるビルトインの統合機能により、開発とテストに必要な時間を大幅に短縮できます。

ルールが呼び出されたときに何をすべきかを指定する AWS IoT rule actions には、Amazon DynamoDB、AWS Lambda、Amazon SQS などの他の AWS サービスのほか、抽出、変換、ロードサービスである Amazon Kinesis Data Firehose、フルマネージドのメッセージングサービスである Amazon Simple Notification Service (Amazon SNS)、膨大な量の IoT データに対して高度な分析の実施、運用を簡単にできる完全マネージド型サービスである AWS IoT Analytics といったその他の AWS サービスとの事前構築済みの統合が含まれています。これらのサービスは、ユースケースに基づいて設定できます。さらに、AWS のサービスによって、スマートメータリングデータセットの上に負荷予測や高度な ML などの新しいユースケースを俊敏に実装できます。エッジ面では、AWS IoT Greengrass の使用はデバイスメーカー（スマートメーターまたはコンセントレーターメーカー）にとっても検討に値します。これは、AWS IoT Greengrass では、クラウドで作成、トレーニング、最適化されたモデルを使用して、デバイス上でローカルで ML 推論を簡単に実行できるためです。

スマートメータリング統合に関する AWS サポートの詳細については、この re: Invent セッションを視聴するか、AWS Power & Utilities のウェブサイトをご覧ください。

本ブログは、ソリューションアーキテクトの丹羽が翻訳しました。原文はこちらです。

AWS for Energyについて詳細はこちらをご覧ください。

Amazon Web Services ブログ