次の方法で共有


IoT ワークロードでのオペレーショナル エクセレンス

IoT ソリューションの要件は複雑なので、持続可能なビジネス価値を促進するには、組織の運用能力が重要です。 このガイドでは、IoT ソリューションのコア要件に特に対処する IoT デバイスとサービスの運用面に焦点を当てます。

IoT ワークロードのオペレーショナル エクセレンスでは、ソリューションのすべてのハードウェアとソフトウェア コンポーネントを完全に可視化して制御する必要があります。 設計、開発、プロビジョニング、監視、サポート、メンテナンスの各プラクティスがすばやく行われ、運用上のリスクを高めることなく、ビジネス価値を提供する必要があります。

IoT ソリューションでは、デバイスの多様性とスケール、さまざまなネットワークの種類、地理的に分散された場所のため、クラウドとハイブリッドの共有責任モデルの多くの部分がクラウド プロバイダーの手を離れます。 クラウド サービスを利用すると、組織は IoT デバイスやネットワークを自力で、またはサード パーティを使って簡単に運用できるようになりますが、IoT ワークロードのこれらの重要な要素に対する運用上の責任は組織自体が負います。

オペレーショナル エクセレンスにより、IoT ソリューションで次のことを問題なく行うことができます。

  • さまざまなユーザーの役割をサポートします。
  • デバイス ライフサイクルのすべてのステージを管理します。
  • 変化に応じて効率的にスケーリングします。
  • 管理と監視に自動化を使用します。
  • 他のバックエンド システムと統合します。

IoT ワークロードでのオペレーショナル エクセレンスを評価する

Well-Architected フレームワークのオペレーショナル エクセレンスの柱の観点から IoT ワークロードを評価するには、Azure Well-Architected レビューで IoT ワークロードに関するオペレーショナル エクセレンスの質問に答えます。 評価によってご自分の IoT ソリューションのオペレーショナル エクセレンスに関する主要な推奨事項が明らかになったら、次のコンテンツを使って推奨事項を実装します。

設計原則

アーキテクチャの卓越性の 5 つの柱は、IoT ワークロードの設計手法を支えます。 これらの柱は、主要な IoT 設計領域全体において後続の設計上の決定に対する指針として機能します。 次の設計原則は、Azure Well-Architected フレームワーク - オペレーショナル エクセレンスの品質の柱を拡張します。

設計原則 考慮事項
継続的な運用とスケーリングを組み込む 自動化されたデバイス プロビジョニングの管理、他のバックエンド システムとの統合、ソリューション開発者、ソリューション管理者、オペレーターなどのさまざまな役割のサポート、新しい IoT デバイスの展開やより高いインジェスト スループットなどの変更に対応した効率的な適応とスケーリングが、IoT ソリューションで適切に行われるようにします。
ビルド プロセスとリリース プロセスを最適化する エンタープライズ IoT ソリューションが成功するには、単一のデバイスまたはデバイスのフリートの構成を確立して更新する戦略が必要です。 デバイスの構成には、デバイスのプロパティ、接続の設定、リレーションシップ、ファームウェアが含まれます。 IoT オペレーターには、デバイスの有効期間中にいつでもデバイスまたはデバイスのフリートの構成を更新できる、シンプルで信頼できるツールが必要です。
運用の正常性を理解する IoT ソリューションのログ、監視、アラート システムを使って、ソリューションが期待どおりに機能しているかどうかを判断し、ソリューションのライフサイクル全体の問題のトラブルシューティングを行います。
自動化と DevOps を使用する IoT デバイスは基本的に、特殊なハードウェアとソフトウェアを備えた小さなコンピューターです。 IoT デバイスは、限られたメモリやコンピューティング容量など、ハードウェアで制約されることがよくあります。 自動化と DevOps は、運用のダウンタイムが最小限になるよう、IoT デバイスとゲートウェイの OS とソフトウェアが適切にアップロードおよび展開されるようにするために不可欠です。 IoT デバイスのライフサイクルの監視と管理には、自動化と DevOps が欠かせません。

IoT アーキテクチャ レイヤー

オペレーショナル エクセレンスの設計原則は、IoT ワークロードが基本 IoT アーキテクチャ レイヤー全体の要件を満たすようにするための考慮事項の明確化に役立ちます。

IoT コア レイヤー (デバイスとゲートウェイ、デバイスの管理とモデリング、インジェストと通信) は、IoT 固有のソリューションを示します。 他のレイヤーと横断的なアクティビティは、他のワークロードにも共通であり、多くの場合共有されます。 DevOps の横断的アクティビティは、オペレーショナル エクセレンスの柱をサポートするために特に重要です。

IoT アーキテクチャのレイヤーと横断的なアクティビティを示す図。

デバイスとゲートウェイのレイヤー

このレイヤーは、エッジまたはオンプレミスに配置された物理または仮想デバイスとゲートウェイ ハードウェアを表します。

IoT のオペレーショナル エクセレンスの重要な要素は、IoT デバイスの計画、プロビジョニング、構成、監視、廃止を行う組織の能力です。 組織は、ビジネスと技術の要件を満たす IoT ハードウェアを選び、運用の信頼性を確保するための適切なテスト手順を定義する必要があります。

新しいハードウェアを使うグリーンフィールド プロジェクトでは、通常、デバイスの種類、ファームウェアと接続機能、技術的な仕様をより柔軟に決定できます。 地域の認定要件または CE、FCC、UL、PCI、FDA などの規制に準拠しているデバイスの選択が必要な場合があります。

ハードウェアが既に展開されているブラウンフィールド プロジェクトでは、通常、ハードウェアに関する制限がより多くなります。 プロトコルや ID の変換デバイスのような他の種類のハードウェアや、Bluetooth からメッセージ キュー テレメトリ転送 (MQTT) へのゲートウェイのような接続ゲートウェイを探すことが、必要になる場合があります。

Azure Certified Device プログラムの認定では、デバイスが Azure IoT Hub に接続でき、IoT Hub Device Provisioning Service (DPS) を介して安全にプロビジョニングできることが検証されます。 Azure Certified for IoT デバイス カタログは、認定パートナー ハードウェアの検索と選択に役立ちます。 デバイス カタログの検索とフィルター機能を使って、ソリューションの要件を満たすハードウェアを見つけることができます。

Azure IoT 認定ハードウェアで探す重要な機能は、Azure プラグ アンド プレイおよび Digital Twins Definition Language (DTDL) の互換性です。 これらの機能により、デバイスは Azure Digital Twins などのサービスとシームレスに統合されます。 Azure IoT Edge のシナリオでは、IIoT Edge Managed 認定を持つカタログ デバイスを見つけることが重要です。 この認定により、デバイスが IoT Edge ランタイムを実行できることが保証され、エッジ処理と分析ワークロードをサポートする IoT Edge モジュールの展開と管理が可能になります。

ソリューションの有効期間のメンテナンスとサポート契約をカバーするには、デバイスのコンポーネントとスペアを利用できる必要があります。 この要件を後で導入するとコストがかかる可能性があるため、プロジェクトを始める時点で、機器がタイムリーかつ確実に供給されるようにしておきます。 信頼できるベンダー チェーンを使用し、二重または複数の供給源を検討します。

インジェストと通信のレイヤー

組織のネットワーク運用チームは、通常、通信事業者と提携して、IoT ワークロードの通信ネットワーク テクノロジ スタックを処理します。 通信事業者と連携し、IoT ソリューションと運用の有線およびワイヤレス通信ネットワーク コンポーネントを設定して運用します。

容量のスケーリング

IoT クラウド ソリューションのインジェストとその他のバックエンド レイヤーを、予想内と予想外の容量ニーズに対応してスケーリングできるように構成します。 ソリューションが接続された製品と結び付けられている場合は、予想される負荷の変動を処理する必要があります。 負荷は、営業やプロモーションなどのマーケティング イニシアティブ、または休日などの季節イベントの影響を受ける場合があります。 予期しないイベントも含め、イベントの前にさまざまな負荷をテストして、IoT ソリューションがスケーリングできることを確認する必要があります。

Azure には、ビジネスの成長に合わせて容量の要件を満たすための複数のオプションが用意されています。 IoT ソリューションの容量計画とスケーリングは、IoT Central または IoT Hub のどちらに基づくソリューションを構築するかによって異なります。

  • IoT Central はマネージド アプリケーション プラットフォームであり、IoT のシナリオをすばやく判断して、ビジネスの機会を評価するために使用できます。 IoT Central はほとんどのインフラストラクチャ要素を処理しますが、データが格納されるのは 30 日間だけです。 ほとんどの IoT ソリューションでは他のサービスにデータをエクスポートするので、ソリューションの評価では、それらの他のサービスが予想内と予想外の容量のニーズを処理できることを確認することに注目する必要があります。

  • IoT Hub ベースのソリューションでは、取り込まれるメッセージの数の増加に対応したスケールアップと、リージョンの需要を処理するためのスケールアウトは、お客様の責任になります。 デバイスが IoT Hub に送信するメッセージの数と持続的なスループットを把握することは、予測される需要をサポートするための適切な IoT Hub レベルを選ぶうえで重要です。

    システムは、IoT Hub メッセージの上限に近づいたら、IoT Hub を次の容量ユニットに自動的にスケールアップできる必要があります。 Azure Stream Analytics、Azure Cosmos DB、Azure Data Explorer など、IoT ソリューションのすべてのバックエンド サービスは、ソリューションのデータ フローのどこにもボトルネックがないようにスケーラビリティをサポートする必要があります。

また、エッジ デバイスの容量のニーズと要件についても計画する必要があります。 IoT Edge で管理するのがリアルタイム オペレーティング システム (RTOS) ベースのデバイスでも、もっと大きいコンピューティング デバイスでも、コンピューティングとメモリのサイズ設定が特定のユース ケースに適していることを確認します。

デバイス管理とモデリングのレイヤー

一元化されたデバイス管理ソリューションを実装して、IoT デバイスのライフサイクルを管理、監視、運用し、IoT ソリューションの全体的な構成を管理します。 デバイス フリートの管理で運用チームを支援するため、統合 UI の実装を検討します。

デバイス プロビジョニング

リモート デバイス プロビジョニング戦略を定義して、人間の介入を必要とせずに、現場でゼロタッチの Just-In-Time プロビジョニングを行えるようにします。

IoT デバイスのリモート プロビジョニングでは、Azure IoT Hub Device Provisioning Service (DPS) を使って、リモート デバイスの IoT Hub への接続と構成を行うことができます。 DPS を使用うと、工場で情報をハード コーディングすることなくゼロタッチ プロビジョニングを行うことができ、複数の IoT ハブ間にデバイスを負荷分散できます。

DPS では対称キーの構成証明がサポートされていますが、運用環境では、X.509 証明書または TPM 構成証明メカニズムを使う必要があります。 X.509 証明書を使う場合は、ルート証明書またはルート証明書によって署名された中間証明書を DPS に展開して、現場のデバイスがサービスで適切に認証され、正しい IoT ハブに割り当てられるようにする必要があります。

IoT ソリューションのライフサイクルの一部には、現場でのデバイスの再プロビジョニングや IoT ハブ間でのデバイスの移動が含まれます。 DPS を使うと、IoT デバイスが新しいプロビジョニング要求を送信するときに予想される動作を決定する再プロビジョニング ポリシーを構成できます。 デバイスは、再起動時にプロビジョニング要求を送信するようにプログラミングし、必要に応じて手動でプロビジョニングをトリガーする方法を実装する必要があります。 このメカニズムにより、デバイスは、起動するたびに DPS に接続し、適切な IoT ハブにリダイレクトされるようになります。

デバイスの構成と更新の管理

デバイスまたはデバイス フリートの構成を更新する戦略を策定します。 デバイスの構成には、デバイスのプロパティ、ファームウェア、接続の設定、リレーションシップが含まれます。 IoT オペレーターには、デバイスの有効期間中にいつでもデバイスまたはデバイス フリートの構成を更新できる、シンプルで信頼できるツールが必要です。

IoT ソリューションの規模とデバイスの構成の具体的な使用は、構成管理戦略の設計に影響します。 この戦略を可能な限り自動化し、構成を効率的に設定および更新できるようにすることが重要です。

構成管理戦略では、次のことをサポートする必要があります。

  • 現場に配置された IoT デバイスと IoT Edge デバイスのインベントリ。
  • デバイスのグループ化による段階的な更新のロールアウト。
  • テストとロールバックをサポートするための回復性のある更新。
  • 既存または新規デバイスの自動更新。
  • 更新された状態のレポートとアラート。

これらの構成管理要件をサポートする Azure の機能には、IoT Hub の自動デバイス管理、IoT Edge の自動展開、IoT Hub のスケジュールされたジョブ、Device Update for IoT Hub などがあります。

  • 既存または新規のデバイスと IoT Edge デバイスの構成 (プロパティ、アプリケーション固有の設定、リレーションシップなど) の継続的な更新には、IoT Hub の自動デバイス管理または IoT Edge の自動展開を使います。 どちらの機能でも、デバイスのフリートまたは特定のグループの構成展開を自動化する、効率がよく安全で信頼性の高い方法が提供されます。 これらのサービスは、タグに基づいてすべての新規および既存の対象デバイスとその構成を継続的に監視し、デバイスの構成が常に指定されたものであることを確認します。 これらの機能の主な違いは、自動デバイス管理は IoT Edge 以外のデバイスにのみ適用され、IoT Edge の自動展開は IoT Edge デバイスにのみ適用されるということです。

  • 1 回限りのスケジュールまたは定期的なスケジュールに基づいて既存のデバイスまたは IoT Edge デバイスの構成を更新するには、IoT Hub のスケジュールされたジョブを使います。 この機能は、スケジュールされた時刻にデバイスのフリートまたは特定のグループに構成の更新を提供する、効率的で安全で信頼性の高い方法です。

  • 既存のデバイスまたは IoT Edge デバイスのファームウェア、アプリケーション、またはパッケージの更新プログラムを無線 (OTA) で更新するには、Device Update for IoT Hub を使います。 このサービスは、デバイスのフリートまたは特定のグループを更新するための、安全でセキュリティ保護された信頼性の高い方法です。

IoT デバイスを手動で更新する方法を用意するのはよいことです。 ルート証明書の変更や接続の問題により、ローカル コンピューターに物理的に接続して、または Bluetoothなどのローカル接続プロトコルを使って、デバイスを手動で更新することが必要になる場合があります。

デバイス管理について詳しくは、以下をご覧ください。

管理ユーザー インターフェイス

ソリューション オペレーターと管理者には、デバイスのプロビジョニング、ユーザーの追加と削除、IoT デバイスへのコマンドの送信、デバイスの更新の管理など、IoT ソリューションと対話するためのインターフェイスが必要です。

IoT Central に組み込まれた使いやすい管理インターフェイスを使うと、オペレーターと管理者は、業界の知識の追加と、ソリューションの評価に集中できます。

IoT Hub や Azure Digital Twins などのプラットフォーム サービスを使ってエンタープライズ ソリューションを構築する場合は、IoT Hub REST APIAzure Digital Twins REST API.で公開されている REST API を使って、カスタム管理 UI を作成できます。

統合レイヤー

一般的な IoT ソリューションは、インジェスト、ルーティング、データ ストレージ、データ処理などの複数のコンポーネントで構成されます。 IoT ソリューションのデータ フロー全体を文書化して、十分に理解することが重要です。 ソリューションのさまざまな部分が期待どおりに動作し、組織の技術と運用の要件を満たしていることを確認するための、テスト手順を用意します。 IoT ソリューションに接続したデバイスの機能を大規模に識別し、バックエンド サービスと簡単に統合するための自動化を実装します。

IoT アプリケーションのバックエンドとフロントエンドのサービスをサポートする他の Azure サービスやサード パーティ サービスとの信頼できる統合を構成してテストします。 IoT の実装を成功させるには、IoT Hub や DPS などの IoT サービスを他の Azure サービスやサード パーティ サービスと統合する必要があります。

たとえば、DPS はカスタム コードと Azure Functions を使ってカスタム割り当てポリシーをサポートするので、Azure 関数で DPS と IoT Hub からのトラフィックが許可されるのを確認することが重要です。 もう 1 つの例は、メッセージ ルーティングやファイル アップロードなどの機能を有効にするための、IoT Hub とバックエンド サービスの間の統合です。 IoT Hub はそれらの Azure サービスに対する認証を適切に行う必要があります。 それらの資格情報の手動管理を不要にするには、マネージド ID を使う必要があります。

DevOps レイヤー

DevOps には、ロールとユーザーの管理、メトリックの収集、監視、自動化が含まれます。

ロールとユーザーの管理

ソリューション設計フェーズの早い段階での重要な決定事項は、ソリューションの実装と管理を行うロールの定義です。 大規模な IoT ソリューションの開発、管理、運用を担当するロールと、それらのロールへのユーザーの割り当てを決定します。

理想的には、ソリューションでは、Microsoft Entra ID などの一元的 ID プロバイダーを信頼し、新しいデバイスの作成とプロビジョニング、現場のハードウェアへのコマンドの送信、更新プログラムの展開、ユーザーのアクセス許可の変更などの管理または運用のアクティビティを、それらのロールの適切なユーザーのみが実行できるようにする必要があります。

IoT Hub ベースのソリューションでは、Microsoft Entra ID を使って、デバイス ID の作成やダイレクト メソッドの呼び出しなど、IoT Hub サービス API への要求を認証できます。 ソリューションのオペレーターと管理者向けに、Microsoft Entra ID に対してユーザーを認証し、それらのユーザーに代わって IoT ソリューションのバックエンドへの API 要求を実行するカスタム管理 UI を開発できます。

IoT Edge Metrics Collector

Azure IoT Edge の IoT Edge モジュール マーケットプレースには、IoT Edge Metrics Collector という、すぐに使用できる IoT Edge モジュールがあります。 メトリックを収集して Azure Monitor に送信するには、このモジュールを IoT Edge の展開に追加します。 このオープンソース モジュールのコードは、Linux x64、ARM32、Arm64 バージョン 1809 をサポートするマルチアーキテクチャの Docker コンテナー イメージです。

Metrics Collector モジュールは、Prometheus データ モデルを使ってメトリックを出力できるすべてのモジュールからログを収集できます。 組み込みのメトリックを使うと、既定でワークロードの広範な可視化が有効になりますが、カスタム モジュールを使って、監視ソリューションを強化するシナリオ固有のメトリックを出力することもできます。

Metrics Collector モジュールからクラウドにメトリックを送信するには、2 つのオプションがあります。

  • メトリックを Log Analytics に送信します。 収集されたメトリックは、InsightsMetrics という固定のネイティブ テーブルを使用して、指定された Log Analytics ワークスペースに取り込まれます。

  • メトリックを IoT Hub に送信します。 収集されたメトリックを UTF-8 でエンコードされた JSON device-to-cloud メッセージとしてエッジ ハブ モジュール経由で送信するように、コレクター モジュールを構成できます。 このオプションを使うと、IoT Hub エンドポイントへの外部アクセスのみが許可されている、ロックダウンされた IoT Edge デバイスを監視できるようになります。

AllowedMetricsBlockedMetrics の構成オプションは、メトリック セレクターのスペースまたはコンマ区切りの一覧です。 メトリックはリストと照合されて、いずれかのリストの 1 つ以上のメトリックと一致した場合、含められるか、または除外されます。

Azure Monitor ブックを使うことで、IoT Edge デバイスから収集されたメトリックを視覚的に調べることができます。 キュレーション ブックでは、Log Analytics ワークスペースに取り込まれる IoT Edge ランタイムからの組み込みメトリックが使われます。 これらのビューでは、ワークロード モジュールのメトリック インストルメンテーションは必要ではありません。

Azure portal には、IoT Edge デバイス用のキュレーション監視ブックがパブリック テンプレートとして用意されています。 ブックにアクセスするには、Azure portal の IoT Hub または IoT Central のページから、[監視] セクションの [ブック] ページに移動します。

Azure portal の IoT Edge 監視ブックを示すアニメーション。

監視

IoT ソリューションのログ、監視、アラート システムを使って、ソリューションが期待どおりに機能しているかどうかを判断し、問題のトラブルシューティングと軽減を行います。 監視とログは、デバイスまたはシステムが、エラー状態か、正しく構成されているか、正確なデータを生成しているか、定義されたサービス レベル目標を満たしているかどうかを判断するのに役立ちます。

IoT のログと監視システムは、標準的な基幹業務アプリケーションのものより複雑になる可能性があります。 この複雑さの原因は、IoT ソリューションは次の範囲に及ぶことが多いためです。

  • 環境と相互作用する物理センサー。
  • データ シェイプやプロトコル変換などのアクティビティを実行するエッジ上のアプリケーション。
  • オンプレミスのゲートウェイ、ファイアウォール、スイッチなどのインフラストラクチャ コンポーネント。
  • インジェストとメッセージングのサービス。
  • 永続化メカニズム。
  • 分析情報とレポートのアプリケーション。
  • クラウド内で独立して動作し、スケーリングするサブシステム。

次に示す簡略化したログと監視のアーキテクチャは、一般的な IoT ソリューション コンポーネントと、推奨されるテクノロジの使用方法の例です。

ログと監視のシステムの例を示す図。

重要なアプリケーションとビジネス プロセスが Azure リソースに依存している場合は、それらのリソースの可用性とパフォーマンスを監視する必要があります。 Azure Monitor を使って、次の監視アクティビティを実行できます。

IoT Hub の監視

Azure リソースからのデータの監視」で説明されているように、Azure IoT Hub は他の Azure リソースと同じ種類の監視データを収集します。 Azure portal の各 IoT ハブの [概要] ページには、使われているメッセージの数やハブに接続されているデバイスの数など、いくつかの使用状況メトリックを示すグラフが含まれます。 [概要] ページの情報は役に立ちますが、IoT ハブに使用できる監視データの量はごくわずかです。

いくつかの監視データは自動的に収集され、IoT ハブを作成するとすぐに分析に使用できるようになります。 他の種類のデータ収集を構成できます。 IoT Hub によって作成されるメトリックとログについて詳しくは、「Azure IoT Hub の監視データのリファレンス」をご覧ください。

更新プログラムを監視する

他の展開や更新プログラムと同様に、展開とデバイスの更新状態を監視する必要があります。 DevOps には、最新のソフトウェア更新プログラムを一貫して提供する方法があります。 Device Update for IoT Hub では、互換性のある更新プログラムの最新版がインストールされているデバイスの数を測定して、コンプライアンスが監視されます。 互換性がある更新プログラムの最新版がインストールされている場合、デバイスは準拠しています。

モニターの構成

他の展開や更新プログラムと同様に、デバイスの構成または更新プログラムの展開の状態を監視して警告する必要があります。 各 Azure IoT 構成サービスは、ログとメトリックを収集して Azure Monitor に格納します。 このデータを使って、構成の展開または更新プログラムが作成、完了、または失敗したときに通知を送信する Azure Monitor アラートを作成できます。

各 Azure IoT 構成サービスによって提供される監視データが十分でない場合は、Azure IoT Hub サービス API によって詳細なビューが提供されます。

自動化と DevOps を監視する

DPS、IoT Hub、IoT Edge では、継続的インテグレーションと継続的デプロイ (CI/CD) の状態または自動化スクリプトの出力を監視するための重要な入力である継続的メトリックと状態の更新が提供されます。 Log Analytics ワークスペースでこれらのメトリックを収集して分析し、アラートを定義できます。

監視の詳細については、以下に関するページを参照してください。

自動化

IoT デバイスは基本的に、特殊なハードウェアとソフトウェアを備えた小さなコンピューターです。 IoT デバイスは、限られたメモリやコンピューティング容量など、ハードウェアで制約されることがよくあります。 自動化と DevOps により、運用のダウンタイムを最小限に抑えるため、IoT デバイスとゲートウェイ ソフトウェアの適切なアップロードと展開が確実に行われます。 自動化と DevOps は、IoT ソリューションとデバイスの開発、展開、運用のライフサイクル全体を監視および管理するために不可欠です。

成熟した DevOps 実装の重要な利点は、機敏性つまりビジネス ニーズの変化をすばやく検出して対応する能力です。 アジャイル ソフトウェア開発、展開、テスト、統合、運用のために DevOps で自動化を使うには、次の推奨事項のようにします。

  • CI/CD DevOps の原則とプロセスを使って生産性を向上させ、シームレスで迅速な開発サイクルを作成します。

  • アプリケーション ソフトウェアの変更をコードとしてのインフラストラクチャ (IaC) 環境に展開し、展開されたソフトウェアの継続的な運用を自動化および管理します。

  • 開発からテスト、展開、IT 運用まで、IoT アプリケーション ソフトウェアのライフサイクルを自動化します。

  • IoT Hub と IoT Edge で DevOps のツールとプロセスを使って、エッジ ソフトウェアのライフサイクルを自動化します。 IoT Edge を使って、IoT アプリケーション ソフトウェアをデバイスに展開します。

  • オペレーターに、可視性と分析情報の取得、共同作業、制御、信頼できる IoT ソリューションの維持のためのツールを提供します。

  • 部門横断的なチームを設けて、ソリューションを継続的に提供します。 デバイス ベンダーと機能横断型ソリューション開発者は、協力して IoT ソリューションの開発と展開を行う必要があります。

  • ビジネス モデルと展開モデルを進化させ、さまざまなビジネス モデルとパイロット検証、展開、機能強化の可能性を生み出します。

デバイスのライフサイクルを自動化する

接続された IoT Edge デバイスには、展開、中断と修正、廃止のライフサイクルがあります。 組織でシステム ライフサイクル全体を通じて機会を活用し、継続的に少しずつイノベーションを追加するには、接続されたデバイスを利用するのが最適です。

IoT ソリューションでは、ハードウェアにインストールされたソフトウェア プログラムによってシステムの機能が定義されます。 何千ものデバイスが、IoT Hub などの 1 つのクラウド エンドポイントに接続される可能性があります。 構成またはソフトウェアの変更を、すべてのデバイスに配布する必要があります。 システムの機能を変更するには、ハードウェアを変更したりローカル環境で介入したりするのではなく、ソフトウェアを更新します。

IoT システムに自動化と DevOps を実装するときは、デバイス ライフサイクルの各フェーズで、自動化と DevOps の特定の要件に従います。 次の表では、デバイス ライフサイクルの 3 つのフェーズをサポートする Azure IoT の機能について説明します。

使用開始

期待される回答 コード スニペットで利用できるプラットフォーム機能
DPS 以外のデバイスの登録 デバイスの一括更新
デバイス プロビジョニング ゼロ タッチ デバイス プロビジョニングを提供するために必要な DPS 構成
デバイスの証明書とトークンの管理 Shared Access Signature (SAS) を使用して IoT Hub へのアクセスを制御する
デバイス証明書のライフサイクル管理 DPS と DigiCert を使用した CA 証明書のライフサイクル管理
デバイスの初期構成 デバイス ツインとデバイスのモジュール

使用中

期待される回答 コード スニペットで利用できるプラットフォーム機能
大規模な継続的デバイス構成管理 デバイス ツインとデバイスのモジュール
IoT Edge モジュール用の CI/CD パイプライン Azure IoT Edge デバイスに対する継続的インテグレーションと継続的配置 (CI/CD)
デバイスの再プロビジョニング DPS デバイスの再プロビジョニング
変更または期限切れの場合の SAS キーの生成 Shared Access Signature (SAS) を使用して IoT Hub へのアクセスを制御する
ログとデバイスの診断 IoT Hub 用の事前構成済み Azure ブック
Azure IoT Edge の監視診断 IoT Edge デバイスのログとメトリックの収集と転送
OTA デバイスの更新 Device Update for IoT Hub

使用終了

期待される回答 コード スニペットで利用できるプラットフォーム機能
デバイスの登録を解除する DPS からのデバイスの登録解除
デバイス固有の構成の削除 デバイス ツインとデバイスのモジュール
デバイスの交換 使用開始と同じ

次のステップ