AWS のデジタルツイン：L3 Predictive デジタルツインを使用した「行動」の予測

1.仮想センサー

EV の例では、共通の課題は、バッテリーの現在の充電状態を考慮して車両の航続距離を推定することです。ドライバーにとって、これは重要な情報です。立ち往生した場合には、通常、EV を最寄りの充電ステーションに牽引する必要があるからです。ただし、航続距離を予測することは、バッテリーの充電状態、バッテリーの放電特性、バッテリーの性能に影響を与える周囲温度を考慮したモデル、また、予想される今後の運転プロファイルに関するいくつかの仮定（たとえば、平坦または山岳地帯、穏やかなまたは、急速な加速)を実装する必要があるため、簡単ではありません。L2 Informative ブログでは、組み込みコントローラーに簡単にハードコーディングできる航続距離の非常に大まかな計算を使用しました。以下の L3 Predictive の例では、L1 Descriptive ブログの中で、単純な計算を AWS パートナーである Maplesoft社 によって提供されている EV シミュレーションモデルの拡張に置き換えました。今回のモデルには、上記の主要な入力要素に基づいて推定範囲を計算する仮想センサーが組み込まれています。仮想センサーベースの車両範囲は、以下の Grafana ダッシュボードに表示されます。

2. 異常検知

産業用機器の場合、一般的なユースケースは、機器が基準性能を下回っているときを検出することです。このタイプの異常検出は、多くの場合、しきい値超過（たとえば、温度が 100°C を超える）などの単純なルール、またはより複雑な統計的工程管理メソッドを使用して、制御システムに直接インテグレーションされます。ルールベースのアプローチのこれらのタイプは、L2 Informative のユースケースに組み込まれます。実際には、EV のような複雑なシステムで基準値を下回るパフォーマンスを検出することは困難です。これは、単一のコンポーネントの期待されるパフォーマンスがシステム全体の動作に依存するためです。たとえば、EV の場合、一定速度で運転する場合と比較して、急加速時のバッテリーの放電ははるかに大きくなると予想されます。バッテリーの放電率に単純なルールベースのしきい値を使用しても機能しません。これは、システムがすべての急加速が異常なバッテリーイベントであると見なすためです。過去 15 年間で、履歴データストリームに基づいて通常の動作を最初に特徴づけることによる異常検出、そしてリアルタイムのデータストリームの常時監視に基づいた機械学習の使用が増えています。Amazon Lookout for Equipment は、このタイプの異常検出を実行するために、監視ありおよび監視なしの機械学習メソッドを展開するマネージドサービスです。次の図は、Grafana ダッシュボードのスクリーンショットを示しており、異常な動作が検出されたために「バッテリーの確認」ライトが点灯していることを示しています。異常の詳細を理解するために、AWSマネジメントコンソールで Amazon Lookout for Equipment  の出力を調べます。ダッシュボードには、調査した時間枠で検出されたすべての異常が表示されます。これには、「Check Battery」ライトが赤に変わる原因となった異常も含まれます。Grafana ダッシュボードに表示される異常を選択すると、モデルがトレーニングされた 4 つのセンサーがすべて異常な動作を示していることがわかります。Amazon Lookout for Equipment ダッシュボードには、この異常に対する各センサーの相対的な寄与がパーセントで表示されます。バッテリー電圧とバッテリーの充電状態の異常な動作は、この異常の主要な指標です。

これは、合成データセットに異常を導入してモデルをトレーニングした方法と一致しています。最初に、図に示されている 4 つのセンサーで教師なし Amazon Lookout for Equipment モデルのトレーニングのために、通常の操作期間を使用しました。その後、上記の Amazon Lookout for Equipment ダッシュボードに表示されている新しいデータセットでこのモデルを評価しました。ここでは、手動で障害を引き起こしました。具体的には、データにエネルギー損失係数を導入し、他のセンサーにも影響を与える充電状態をわずかに低下しやすくしました。車へのさらなる損傷を回避するために、この異常を十分に早期に検出するルールベースのシステムを設計することは困難です。特に、そのような動作が以前に観察されたことがない場合はなおさらです。ただし、Amazon Lookout for Equipment は最初にいくつかの異常な期間を検出し、特定の時点以降、残りの時間全体にわたって異常にフラグを立てます。もちろん、異常に対する各センサーの寄与を Grafana ダッシュボードに表示することもできます。

3. 故障予測

産業機器のもう 1 つの一般的なユースケースは、メンテナンスを事前に計画およびスケジュールするために、コンポーネントの寿命を予測することです。故障予測用のモデルの開発は非常に困難な場合があり、通常、さまざまな異なる動作条件下での特定の機器の故障パターンのカスタム分析が必要です。このユースケースでは、AWS は、機械学習モデルのトレーニング、構築、デプロイを支援するフルマネージドサービスである Amazon SageMaker を提供しています。次のセクションでは、ソリューションアーキテクチャについて説明するときに、Amazon SageMaker を AWS IoT TwinMaker と統合する方法を示します。

この例では、残りの耐用年数（RUL）で手動でラベル付けされた合成バッテリーセンサーデータセットを作成しました。より具体的には、合成バッテリーモデルでエネルギー損失係数を計算して、異なる RUL を持つバッテリーのデータセットを作成し、手動で大きなエネルギー損失を短い RUL に関連付けました。実生活では、そのようなラベル付けされたデータセットは、寿命に達したバッテリーのデータを分析するエンジニアによって作成される可能性があります。XGBoost アルゴリズムを使用して、入力としてのセンサーデータの 2 分間のバッチに基づいて RUL を予測しました。モデルは、これらのバッチから派生した特徴量を入力として受け取ります。たとえば、移動平均を使用してセンサーデータを平滑化し、2 分間のバッチの開始と終了の間でセンサーデータを比較しました。なお、予測にローリングウィンドウを使用することで、2 分未満の粒度で予測を行うことができます。この例では、バッテリーの残存有効期間がダッシュボード内の Check Battery エリアの下部に表示されます。この車両は、バッテリーの異常が切迫していることが予測される悲惨な状況です。

4. アーキテクチャ

L3 Predictive DT ユースケースのソリューションアーキテクチャは、L2 Informative DT 用に開発されたソリューションに基づいて構築されており、以下に示されています。アーキテクチャのコアは、AWS Lambda 関数を使用して実際の電気自動車のデータストリームを表す合成データを取り込むことに重点を置いています。AWS IoT SiteWise を使用して、車両速度、液面レベル、バッテリー温度、タイヤ圧、シートベルトとトランスミッションのステータス、バッテリーの充電、および追加のパラメーターを含む車両データが収集および保存されます。過去のメンテナンスデータと今後の定期メンテナンスアクティビティは AWS IoT Core で生成され、Amazon Timestream に保存されます。AWS IoT TwinMaker は、複数のデータソースからのデータにアクセスするために使用されます。AWS IoT SiteWise に保存されている時系列データには、組み込みの AWS IoT SiteWise コネクタを介してアクセスし、メンテナンスデータには Timestream のカスタムデータコネクタを介してアクセスします。

L3 仮想センサーアプリケーションでは、コアアーキテクチャを拡張して AWS Glue を使用し、Amazon Kinesis Data Analytics のカスタムコネクタとして AWS IoT TwinMaker Flink ライブラリを使用して Maplesoft 社の EV モデルを統合しました。異常検出では、最初にセンサーデータをオフライントレーニングのために S3 にエクスポートしました（図には示されていません）。トレーニングされたモデルは、Amazon Lookout for Equipment を介して利用可能になり、スケジューラーを介してセンサーデータのバッチの予測を可能にします。Lambda 関数は、モデルのデータを準備し、それらの予測を処理します。次に、これらの予測を AWS IoT SiteWise にフィードバックし、そこから AWS IoT TwinMaker に転送され、Grafana ダッシュボードに表示されます。障害予測のために、最初にセンサーデータをトレーニング用に S3 にエクスポートし、Amazon SageMaker GroundTruth を使用してラベルを付けました。次に、Amazon SageMaker トレーニングジョブを使用してモデルをトレーニングし、結果のモデルの推論エンドポイントをデプロイしました。次に、バッチ推論のためにスケジューラーによってトリガーされる Lambda 関数内にエンドポイントを配置しました。結果の予測を AWS IoT SiteWise にフィードバックし、そこから AWS IoT TwinMaker に転送され、Grafana ダッシュボードに表示されます。

5. L3 デジタルツインの運用化：データ、モデル、および主要な課題

過去 20 年間で、機械学習、物理ベースのモデル、およびハイブリッドモデルを使用した予測モデリング手法の進歩により、予測の信頼性が向上し、運用上有用になりました。ただし、私たちの経験では、モデルをビジネスで使用するための運用方法が不十分なため、ほとんどの予測作業は依然として失敗しています。

たとえば、仮想センサーの場合、重要なタスクは、統合されたデータパイプラインとモデリングワークフローで検証済みモデルを開発およびデプロイすることです。クラウドアーキテクチャの観点からは、上記の EV の例に示すように、これらのワークフローは簡単に実装できます。より大きな課題は運用面にあります。まず、複雑な機器の仮想センサーモデルの構築と検証には、数年かかる場合があります。仮想センサーは、センサーでは測定できない値によく使用されるため、定義上、実際の検証データはありません。その結果、検証は、モデルを固定するための限られた検証データに対して、いくつかの非常に高価なセンサーまたは目視検査を使用して、プロトタイプハードウェアで実験する研究所で行われることがよくあります。次に、一度展開されると、仮想センサーは、データパイプラインが堅牢で、モデルに必要なデータを提供する場合にのみ機能します。これは当たり前のことのように聞こえますが、運用上は困難な場合があります。現実世界のセンサーの読み取り値が低い、データのドロップアウト、誤ってタグ付けされたデータ、データタグのサイト間のばらつき、およびオーバーホール中に制御システムタグに加えられた変更は、多くの場合、仮想センサーをうまく機能させない原因になります。質の高いデータと一貫性のあるデータを保証することは、基本的にビジネス運営の課題です。組織は、機器に取り組んでいる技術者のための基準、品質チェック手順、およびトレーニングプログラムを定義する必要があります。テクノロジーは、データ収集における不十分な運用慣行を克服することはできません。

異常検出と障害予測により、データの課題はさらに大きくなります。エンジニアリングリーダーは、自社がデータの金鉱に座っていると信じ、データサイエンスチームが達成していない理由を疑問視するようになります。実際には、これらのデータパイプラインは確かに堅牢ですが、まったく異なるアプリケーション用に作成されています。たとえば、規制やパフォーマンスの監視のためのデータパイプラインは、異常の検出や障害の予測に必ずしも適しているとは限りません。異常検出アルゴリズムはデータ内のパターンを検索するため、センサーの誤読、データのドロップアウト、データのタグ付けの問題などの問題により、予測モデルが役に立たなくなる可能性がありますが、同じデータを他のユースケースで受け入れられる可能性があります。もう1つの一般的な課題は、完全に自動化されていると考えられているデータパイプラインが実際にはそうではないことです。人間の判断を必要とする文書化されていない手動データ修正は、通常、ワークフローがスケーリングのために自動化され、機能しないことが判明した場合にはじめてわかります。最後に、産業アセットの場合、故障予測モデルは、機器の実際の状態を最も直接的に観察できるため、手動で収集された検査データに依存しています。私たちの経験では、検査データの収集、解釈、保存、統合に関する運用プロセスは、障害モデルをサポートするのに十分な堅牢性を備えていません。たとえば、検査データは、収集されてから数か月後、機器がすでに故障してからかなり経ってから、システムに表示されます。または、検査データは、誤って書き込まれた検査データレコードに添付された、または間違った機器に関連付けられた手書きのメモで構成されています。誤ったデータが提供されると、最良の予測モデルでさえ失敗します。

L3 Predictive デジタルツインの場合、エンジニアリングチームが自分たちでデジタルツインを構築しているのと同時に、デジタルツインのデータニーズをサポートするためのビジネスオペレーションを開発および検証することをお客様に推奨します。データ収集から予測に至るまでのエンドツーエンドのワークフローの考え方を持ち、予測に基づいて行動することは、成功のために重要です。

まとめ

このブログでは、仮想センサー、異常検出、および障害予測のユースケースをウォークスルーすることにより、L3 Predictive レベルについて説明しました。また、L3 デジタルツインのデータニーズをサポートするために必要なビジネスプロセスを実装する際の運用上の課題についても説明しました。以前のブログでは、L1 Descriptive レベルと L2 Informative レベルについて説明しました。将来のブログでは、EV のユースケースを拡張して L4 Living デジタルツインのデモを行います。AWS では、4 つのデジタルツインレベルすべてでデジタルツインの旅に出るお客様と協力できることをうれしく思います。また、ウェブサイトで新しい AWS IoT TwinMaker サービスの詳細を学ぶことをお勧めします。

著者について

	Adam Rasheed 博士は、AWS の自律コンピューティングの責任者であり、自律システムの HPC-ML ワークフローの新しい市場を開発しています。彼は、航空、エネルギー、石油およびガス、再生可能エネルギー業界でのデジタルツインの開発を含む、産業分野とデジタル分野の両方にまたがる中期ステージの開発で 25 年以上の経験があります。Rasheed 博士はカリフォルニア工科大学で博士号を取得しました。そこでは、実験的な超高速大気熱力学（軌道再突入加熱）を研究しました。MIT Technology Review Magazine によって「世界のトップ 35 イノベーター」の 1 人として認められ、航空学における初期のキャリア貢献に対して業界賞である AIAA ローレンススペリー賞も受賞しました。彼は、産業分析、運用最適化、人工リフト、パルスデトネーション、超音波、衝撃波誘起混合、宇宙医学、およびイノベーションに関連する 32 以上の特許と 125 以上の技術出版物を発行しています。
	Seibou Gounteni は、Amazon Web Services（AWS）の IoT のスペシャリストソリューションアーキテクトです。彼は、お客様が AWS プラットフォーム機能の深さと幅を使用してスケーラブルで非常に革新的なソリューションを設計、開発、運用し、測定可能なビジネス成果を提供するのを支援します。Seibou は、デジタルプラットフォーム、スマート製造、エネルギー管理、産業自動化、さまざまな業界の IT/OT システムで 10 年以上の経験を持つ計装エンジニアです。
	David Sauerwein 博士は、AWS Professional Services のデータサイエンティストであり、お客様が AWS クラウドで AI/ML ジャーニーに出られるようにしています。デビッドは、予測、デジタルツイン、量子計算に焦点を当てています。彼は量子情報理論の博士号を取得しています。

このブログはソリューションアーキテクトの戸塚智哉が翻訳しました。