Amazon Web Services ブログ

AWS Summit Japan 2024 – インダストリー Village /鉄道ブース開催報告ブログ(後編)

2024年6月20日、21日の二日間に開催された AWS Summit Japan では、 AWS Village と称する AWS のサービスやインダストリーソリューションを扱う 90 以上の AWS 展示と、50 以上のお客様事例展示が一堂に会した展示エリアが設けられました。

今年は鉄道関連の事例とソリューション展示が行われ、お客様事例として東海旅客鉄道株式会社（以下、 JR 東海）様と東海交通機械株式会社（以下 CKK ）様から鉄道機械設備の保全における活用事例と、 AWS から AWS IoT SiteWise および Amazon Bedrock を使った鉄道機械設備のモニタリングソリューションの紹介を行いました。
本投稿では前編後編の2部構成としており、このブログでは後編として、 AWS ブースで展示した内容を紹介します。前編の JR 東海様、 CKK 様から展示いただいた模様についてはこちらをご参照ください。

AWS ブース

AWS のブースでは「クラウドで進化する鉄道機械保守」のテーマで、鉄道機械設備のリモートメンテナンスのソリューション展示を行いました。本ソリューションは以下の2つのポイントをに分けてご紹介していきます。

  • ポイント1： AWS IoT SiteWise を使用した鉄道設備の大規模データ管理
  • ポイント2： Amazon Bedrock を使って過去の対応記録から推奨エラー対応方法を生成

本ソリューションが機械設備保守業務の効率化や高度化に取り組まれている皆様のご参考になれば幸いです。

ポイント1： AWS IoT SiteWise を使用した鉄道設備の大規模データ管理

鉄道保全の現場では、転轍機や融雪装置などの従来の鉄道機械に加えて、ホームドアやエレベーターなど様々な機械設備があります。それらの設備は路線全体に点在しており、地理的にも広大な範囲に及びます。また、日本においては生産年齢人口が減少傾向にあり、保全業務の担い手確保が難しくなってくることが予想されます。これらを背景として、鉄道保全業務の効率化・高度化の必然性は高まってきております。効率化・高度化の一つの方向性として膨大な鉄道設備データを収集しリモートで集中管理することが有効です。 AWS IoT SiteWise を利用して路線全体に広域に配置されている鉄道設備群の大規模なデータを効率的に管理・モニタリングする方法についてご紹介いたします。

AWSの構成

今回の展示では全線で9駅を対象とした設備監視システムを構築しました。58の駅構造物に分解されて、それぞれに延べ223の機会設備が配置されていることを想定しております。 AWS IoT SiteWise で各機械設備のデータを取得し、取得したデータを Grafana で可視化しております。223もの機械設備の様々なセンサーデータをどのように管理すると効率的で高度な監視を実現出来るでしょうか。データモデルに着目して述べていきたいと思います。

駅設備データ構造のモデル化

駅の構造に着目すると、駅構内にホームやコンコースがあり、ホームやコンコースには空調機やエレベータなどの設備が配置されており、各設備に温度や回転数を計測するセンサーが付随しています。設備のモニタリングを行うためには、これらのセンサーデータを収集する必要があります。この時考慮すべき事項として、同種の設備が無数にあるため、各駅を起点とした階層構造と対応付けて設備データを管理する必要があります。このように各駅を起点とした階層構造をデータモデルとして管理する仕組みが必要なのです。 AWS IoT SiteWise のアセットモデル作成機能を利用して大量の設備を効率的に管理することができます。

アセットモデルの作成

AWS IoT Sitewise を利用して次のような流れでアセットモデルを作成しました。詳細な手順は「産業アセットのモデル化」を参照ください。

  1. アセットモデルを作成
    1. 駅、駅構造物、各機械設備の3階層で計10個のアセットモデルを作成しました。
  2. データプロパティを定義
    1. それぞれのモデル毎のデータプロパティを定義します。今回、空調機の例のように静的なデータ（属性）や設備から取得するデータ（測定）に加えて、変換・メトリクスのプロパティタイプを利用して、監視のために必要な測定値の評価や計算を行ってます。これらのプロパティを利用することでより高度な設備監視が可能となります。
  3. アセットの作成
    1. アセットモデルから各機械設備等のアセットを作成します。この時にアセット間の親子関係を関連付けることができます。親アセットは間r年するアセットのデータにアクセスし集計することができます。今回、各駅をルートとして駅構造物、各機械設備を子アセットとして関連付けております。例えば、美濃大垣駅-改札外コンコース-空調機01,02といったアセットが親子関係になっております。

このように実際の駅の構成を抽象化し、アセットモデルとして定義することで、効率的に設備データを管理することができます。また、監視の要件に合わせて、取得したデータを評価・計算することにより難しい作り込みを必要とせずに簡単に高度な監視も実現することができます。

ポイント2： Amazon Bedrock を使って過去の対応記録から推奨エラー対応方法を生成

AWS IoT SiteWise を使うことの利点の一つとしてリアルタイムアラート機能があります。機器から送られてくるデータに対してあらかじめモデルで定義された閾値を越えた場合に、アラートが発砲するという機能で、このAWS IoT SiteWise アラーム機能は AWS IoT Events と連動することによって提供されています。この機能の活用によりほぼリアルタイムで機器の異常を検知し異常状態に気づくことができます。しかし実際に現場で異常が発生した際は、実は検知したあとの作業の方が労力がかかるケースがほとんどです。そこで今回の展示では、異常を検知したあとの作業に対し少しでもお手伝いできることはないかというところからアイディアを想起させて実装してみました。

実装内容（やったこと）

機器に異常が発生した場合、行う作業の一つとして過去の対応履歴や対策/対応マニュアルなどを探して確認することがあると思います。そういった業務に対し少しでも省力化につながる仕組みとして、過去の蓄積文書を元にした推奨対応策の作成を生成 AI の活用により自動生成し、異常検知の通知メールの中に AI 推奨対応策として入れ込んでメール送信を行うという仕組みを実装してみました。生成 AI のユースケースの一つである RAG ( Retrieval-Augmented Generation ) と呼ばれる検索拡張生成の仕組みをチャットから使うのではなく、エラー情報をインプットとして活用するという試みをしました。

AWSの構成と動作の詳細

構成は図のようになっており、異常が発生した場合の処理の流れは次のようになります。

  1. センサーデータがリアルタイムで AWS IoT SiteWise に格納されます。
  2. 格納されたデータに対し設定された閾値で評価され違反しているかを判定します。今回の展示では場合は、エラーコードを検出する文字列判定、設定温度と外気温 (15分平均の温度) の温度差が5度以上かどうかの数値判定、といったものを例として仕込みました。
  3. 上記の閾値に違反し異常を検出すると AWS IoT Events によって AWS Lambda に転送されます。
  4. AWS Lambda によってエラーコードから大枠の事象を特定しプロンプト文を作成します。
  5. そして Amazon SQS を経由し RAG が実装された AWS Lambda に転送します。
  6. Amazon SQS から渡されたエラー情報を元に AWS Lambda で RAG を実行します。RAG とは関連情報の検索を行い抜粋された文章を元に生成 AI が文章を作成する仕組みです。ここでは例えば、エラーコードから空調機の冷媒液の漏洩が発生という情報が Amazon SQS から渡され、「空調機の冷媒液漏洩発生時の対処方法」という文言で関連文章内を検索します。そして検索に引っかかった文章を元に LLM (Large Language Model) に「空調機の冷媒液漏洩発生時の対処方法を教えてください」と問いかけることで AI 推奨の対処方法を生成します。ちなみに今回の展示の RAG で使った LLM は Amazon Bedrock の Claude 3 Haiku で、ドキュメント検索のインデックス DB には Amazon Kendra を使いデータソースは Amazon S3 になります。Amazon S3 に格納されているドキュメントは国土交通省、 JR 総研、日本学術振興会などが公開している PDF 文章です。Claude 3 Haiku を選んだ背景としては、リアルタイムの異常時対応という想定のため、日本語の精度が高い Claude 3 の中でも一番レスポンスが早いということで選択しました。
  7. 最後にメールを作成します。Amazon Bedrock の Claude 3 Haiku で出力された文章に加えて、Amazon Kendra から出力された Amazon S3 に格納されたドキュメントを参照できるように一定時間だけ有効な署名付きURLを発行し、参考ドキュメントとしてメールに記載しています。このメールを Amazon SNS で配信します。

展示でのデモ

当日の展示では、意図的に故障データを流せる RaspberryPI (「彦原-新幹線コンコース-空調機 01 」を模擬) を用意し、そこでスクリプトを実行すると異常データが飛ぶという仕掛けを用意しました。実際に実行すると、 Grafana ダッシュボードはほぼリアルタイムで反映され異常となります。

ダッシュボード上が異常となると同時に裏側では AWS IoT Events が動き RAG が実行されております。数十秒で RAG とメール送信の処理が完了し、アラート通知と過去の対応記録から類推された AI 推奨のエラー対応方法が記載されたメールを受信します。下図は実際にその時に受信したメール画面になります。

もし発生した異常への対応方法が記載された適切なドキュメントが見当たらなければ、情報がないことを明示したメールが届きます。下図は実際に受信したメール画面になります。

このように生成 AI の課題の一つであるハルシネーション (生成 AI がユーザーの質問に対して、事実とは異なる情報を利用して回答を生成すること) を抑えることが RAG によって可能になります。

今回私たちの方には適切なドキュメント等を持っていなかったため、公開されている情報から引っ張ってきましたが、適切な自社のマニュアルや対応履歴のドキュメントがあるとより正確で役立つ情報が配信できるソリューションになると考えられます。

以上、 AWS Village の鉄道関連展示における AWS ブースで展示した内容について紹介させていただきました。 本投稿では2024年6月20日、21日の二日間に開催された AWS Summit Japan にて展示された、東海旅客鉄道株式会社（以下、 JR 東海）様と東海交通機械株式会社（以下 CKK ）様から鉄道機械設備の保全における活用(前編)と、 AWS から AWS IoT SiteWise および Amazon Bedrock を使った鉄道機械設備のモニタリングソリューション(後編)の2つの展示内容について2部構成で紹介させていただきました。本投稿が機械設備保守業務の効率化や高度化に取り組まれている皆様のご参考になれば幸いです。

著者

技術統括本部 ソリューションアーキテクト 岩永 昌寛

カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネージャー 西部 信博

技術統括本部 ソリューションアーキテクト 宮﨑 知洋