編集

IoT Edge* 鉄道メンテナンス*および安全システム*

Azure Blob Storage
Azure Cosmos DB
Azure IoT
Azure IoT Edge
Azure IoT Hub

このアーティクル*では、Microsoft と大手鉄道会社とのコラボレーション*による、モノのインターネット* (IoT*) の列車メンテナンス*および安全ソリューション*について説明します。

アーキテクチャ

線路脇のバンガローにある IoT Edge モジュールを示すソリューション アーキテクチャの図。Edge モジュールは、機械学習を使用して故障リスクを特定します。アラート ハンドラー モジュールは、画像データを Azure Blob Storage にアップロードします。Azure Edge Hub は、関連するメタデータとメッセージを、Azure IoT Hub を介して Azure Cosmos DB ストレージにアップロードします。

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

  1. 線路脇の建物 に備わるネットワーク*接続ストレージ (NAS) のイメージ* ファイル サーバー*により、処理や分類が行われた列車の車輪の画像が提供されます。 各車輪の 3 枚の写真をつなぎ合わせて 1 つの画像が作成されます。
  2. IoT Edge* ポーリング* モジュール*は、処理対象の新しい画像があることを IoT Edge* デバイスにアラート*します。
  3. IoT Edge* ML* モジュール*では、サードパーティの ML* モデル*が画像*を処理し、検査が必要な車輪の領域を特定します。
  4. IoT Edge* アラート* ハンドラー*は、すべての画像*を Azure Blob Storage* にアップロード*する際に潜在欠陥の画像*から開始し、その後画像*の BLOB* URI* を返します。
  5. IoT Edge* ハブ* モジュール*は、画像 URI* を機器や車台番号、車軸、timestamp*、検出機能が備わる場所などの画像* メタデータ*に関連付けます。 当該モジュール*では、メタデータ*とアラート*を Azure IoT Hub* にアップロード*します。
  6. IoT Hub* は、Event Hubs* および Azure Functions* を介して、Azure Cosmos DB* データベース*にメタデータ*を送信します。
  7. Azure Cosmos DB* データベース*は、画像*メタデータ*と Azure Blob Storage* に保存されている画像の URI* とを関連付けます。 このシステム*では Azure Cosmos DB* のデータ*を用いて、欠陥認識、傾向分析、予測メンテナンス*、ML* モデル*の再トレーニングを行うことができます。

コンポーネント

この事例では、カスタム産業用オートメーションのカード*とグラフィックス プロセッシング ユニット* (GPU*) がパフォーマンス*を目指し装備されたサーバー* クラス*のハードウェアを使用して、Azure IoT Edge* デバイスを線路脇の建物に配置します。

IoT Edge は、次の 3 つのコンポーネントで構成されます。

  • IoT Edge "モジュール" は、Azure、サードパーティ、またはカスタム コンポーネントを実行できるコンテナーです。

    IoT Edge* ML* モジュール*では、Azure Machine Learning*、サードパーティの ML* モデル*、またはカスタム コード*をサポート*します。 現在のソリューションでは、Cogniac と呼ばれるサードパーティのオープンソース ML モデルを使用して、列車の車輪データをスコア付けし、潜在的欠陥を認識します。 ML ソフトウェアは、高信頼度と低信頼度の故障画像の過去のサンプルを使用して、ML モデルを再トレーニングします。

  • "IoT エージェント" と "IoT Edge ハブ" で構成される IoT Edge "ランタイム" は、IoT Edge デバイス上で実行され、デプロイされたモジュールを管理および調整します。

  • クラウドベース*のインターフェイスにより、リモート監視*と管理が可能になります。

このシステム*では、次の Azure クラウド* コンポーネント*も使用されます:

  • Azure IoT Hub* は、IoT Edge モジュールにおいてセキュアなクラウドとの双方向通信、管理、モニター*を可能にします。

  • Azure Blob Storage* は、クラウド*向けのオブジェクト* ストレージです。 Blob Storage は、この例の画像データのような大量の非構造化データを格納するために最適化されています。

  • Azure Cosmos DB* は、応答時間*が短く、高可用性*とスケーラビリティ*を備えたフルマネージド* NoSQL* データベース* サービス*です。

代替

  • IoT Edge* アーキテクチャ*には複数のモジュール*を使用していますが、ソリューション*のパフォーマンス*要件*や開発チームの構造によっては、単一のモジュール*に凝縮することができます。

  • 鉄道会社が所有しているのは推論システムだけであり、ML モデルの生成はサードパーティ ベンダーに依存しています。 ML モジュールのブラックボックスの性質により、依存関係のリスクが生じます。 ソリューションの長期的なメンテナンスでは、サードパーティが資産を管理および共有する方法を理解する必要があります。 このシステム*では、ML* アセット*が使用できない場合、今後エンゲージメント*にプレースホルダー* ML* モジュール*を使用できる可能性があります。

シナリオの詳細

Azure IoT Edge* は、データ処理*およびデータストレージを有効にする*ものです。 エッジ*でのワークロード*処理によって、クラウド*接続とリソース*との依存関係*を減らしながら、高速かつ一貫性のある応答を実現することができます。

機械学習* (Machine Learning*) とビジネス ロジック*をデータ ソース*の近くに配置することで、デバイス*はローカル*の変更や重要なイベント*により迅速に対応できるようになります。 デバイスは、オフラインでも、接続が制限されている場合でも確実に動作できます。

エッジ コンピューティング*では、人工知能* (AI*) や機械学習 (ML*) モデル*を組み込み、インテリジェント エッジ* デバイスおよびネットワーク*を作成できます。 境界ネットワーク*では、クラウド*に送信*するデータ*を決定することができます。つまり、緊急性の高い重要なデータを最優先にすることができます。

当該の鉄道会社は、以下を可能にし安全性と効率性の向上を図るため、Azure IoT Edge* 使用を希望しました:

  • 欠陥のあるコンポーネント*をプロアクティブに識別。
  • メンテナンス* および修復に関する予測スケジューリング。
  • 解析*と予測*を継続的に改善。

IoT Edge* ソリューション*のパイロット* プロジェクト*は、列車車輪の正常性*解析*システム*となっています。 同システム*では、4,000 台以上の検出器が同社所有の列車から得た車輪データ*に対し、モニター*やデータ ストリーム*を継続的に行います。 検出機能:

  • 線路上の機器の熱とエネルギーを測定します。
  • 車輪のベアリングにある目につかない欠陥や車輪の亀裂をリッスン*します。
  • 欠落している、または正しく配置されていないパーツ*を特定します。

Azure IoT Edge* モジュール*は、凖リアルタイム*で連続ストリーミング*のデータ*を処理および実行します。 IoT Edge モジュールは、線路脇のバンガローにあるサーバー クラスのハードウェア上で実行され、他のワークロードの将来の並列デプロイを可能にします。 IoT Edge* ベース*のソリューション*:

  • リスクのある機器を識別します。
  • 修復の緊急度を判定します。
  • アラートを生成します。
  • 保存用の Azure クラウド*にデータ*を送信*します。

車輪正常性*解析*システム*では、列車の脱線を起こしかねない機器故障の可能性を早期発見することができます。 同社は保存されたデータから傾向をつかみ、規範的なメンテナンス* スケジュール*を通知することができます。

考えられるユース ケース

このソリューション*は、輸送、通信、製造という各種業界に最適です。 当該製品では、次のシナリオ*に重点を置いています:

  • アップタイム* 99% 以上維持の必要がある通信ネットワーク*。
  • ファクトリ*での生産品質制御*、機器の修復、予測メンテナンス*。
  • 待機時間*がほぼ、またはまったくない、リアルタイム*でのストリーミング* データ*処理が必要な輸送安全システム*。
  • スケジュール*の通知*やアラート*をタイムリーに発する必要がある交通システム*。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

この例には、いくつかの考慮事項があてはまります。

Operations

デプロイされたソリューションには、サービス プリンシパルを追加するためのアクセス許可を持つ Azure サブスクリプションと、Azure リソースを作成する機能が必要です。 詳細については、コンテナー レジストリとサービス プリンシパルに関する記事をご覧ください。

Azure Pipelines ワークフローは、組み込みの Azure IoT Edge タスクによって、IoT Edge ソリューションを構築、テスト、デプロイ、アーカイブします。 この鉄道会社では、継続的インテグレーション/継続的デプロイ (CI/CD) システムをオンプレミスでホストしています。 次の図は、デプロイの DevOps アーキテクチャを示しています。

DevOps アーキテクチャの図。

  1. 第1 の CI* パイプライン*では、Git リポジトリ*へのコード プッシュ*によって IoT Edge* モジュール*のビルド*がトリガー*され、Azure Container Registry* にモジュール* イメージ*が登録されます。

  2. CI* パイプライン*が完了すると CD* パイプライン*がトリガー*されます。そこから配置マニフェスト*が生成され、モジュール*が IoT Edge* デバイスに配置されます。

デプロイには、開発、QA、運用の 3 つの環境があります。 開発から QA、QA から運用へのモジュールの昇格では、自動と手動の両方のゲート チェックがサポートされています。

ソリューションの構築とデプロイでは、以下も使用されます。

  • Azure CLI
  • コンテナー モジュールをビルドおよびデプロイするための Docker CE または Moby
  • 開発用に、Docker*、Azure IoT*、関連する言語*拡張機能*を備えた Visual Studio* または Visual Studio Code*。

パフォーマンス

  • このシステムでは、99% のアップタイムと、オンプレミスでの 24 時間以内のメッセージ配信が必要です。 バンガローと Azure 間の接続のラストマイルのサービス品質 (QoS) によって、エッジからのデータの QoS が決まります。 ローカル* インターネット サービス* プロバイダー* (ISP*) が接続のラストマイルを管理していますが、通知*やデータ*の一括アップロード*に必要な QoS* をサポート*していない場合があります。

  • このシステムには、車輪のカメラおよびバッキング データ ストアとのインターフェイスがないため、カメラ システムや画像サーバーの障害に関するアラートを生成するための制御や機能はありません。

  • このソリューションは、会社と連邦規制機関が決定した既存の手動検査要件に代わるものではありません。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

セキュリティと監視は、IoT Edge システムの考慮事項です。 この例の場合は次のとおりです。

  • 同社の既存のサードパーティ* エンタープライズ ソリューション*が、システム* モニタリングに対応しました。
  • 線路脇の建物に対する物理的セキュリティ*とネットワーク セキュリティ*は対策済みです。
  • 既定では*、IoT Edge* からクラウド*への接続をセキュリティで保護しています。

次のステップ

GitHub* プロジェクト*:

ソリューション*学習リソース*: