IoT Hub デバイスの再プロビジョニングの概念

IoT ソリューションのライフサイクル中に、デバイスを IoT ハブ間で移動することはよくあります。 この移動の理由として、次のようなシナリオが挙げられます。

• 位置情報/geo 待機時間: デバイスが異なる場所の間を移動するときは、より近い IoT Hub にデバイスを移行することにより、ネットワーク待機時間が改善されます。

• マルチ テナンシー: デバイスは同じ IoT ソリューション内で使用され、新しい顧客または顧客サイトに再割り当てされる可能性があります。 この新しい顧客には、別の IoT ハブを使用してサービスが提供される可能性があります。

• ソリューションの変更: デバイスは、新しい IoT ソリューションまたは更新された IoT ソリューションに移動される場合があります。 この再割り当てでは、その他のバックエンド コンポーネントに接続されている新しい IoT ハブと通信するためにそのデバイスを必要とする可能性があります。

• 検疫: ソリューションの変更と同様です。 正常に動作していないデバイス、セキュリティ侵害を受けたデバイス、または古いデバイスは、更新してコンプライアンスが確保された状態に戻す操作のみが可能な IoT ハブに再割り当てされることがあります。 デバイスが適切に機能するようになったら、そのメインのハブに再び移行されます。

Device Provisioning Service 内の再プロビジョニングのサポートでは、これらのニーズに対処します。 デバイスは、デバイスの登録エントリで構成された再プロビジョニング ポリシーに基づいて、新しい IoT Hub に自動的に再割り当てされる場合があります。

デバイスの状態データ

デバイスの状態データは、デバイス ツインとデバイスの機能で構成されています。 このデータは Device Provisioning Service インスタンスおよびデバイスが割り当てられている IoT Hub に格納されます。

デバイスが Device Provisioning Service インスタンスで最初にプロビジョニングされる場合、次の手順が実行されます。

1. デバイスによって Device Provisioning Service インスタンスにプロビジョニング要求が送信されます。 サービス インスタンスでは、登録エントリに基づいてデバイス ID が認証され、デバイスの状態データの初期構成が作成されます。 サービス インスタンスによって、デバイスが登録の構成に基づいて IoT Hub に割り当てられ、IoT Hub 割り当てがそのデバイスに返されます。

2. プロビジョニング サービス インスタンスによって、任意のデバイスの初期状態のデータをコピーしたものが割り当てられた IoT Hub に提供されます。 デバイスが割り当てられた IoT Hub に接続され、操作を開始します。

時間の経過とともに、IoT Hub 上のデバイスの状態データは、デバイスの操作とバックエンドの操作によって更新される可能性があります。 Device Provisioning Service インスタンスに格納されているデバイスの初期状態の情報は、変更されずに保持されます。 この変更されていないデバイスの状態データが初期構成です。

シナリオに応じて、デバイスが IoT Hub 間で移動されるときに、前の IoT Hub で更新されたデバイスの状態を新しい IoT Hub に移行することが必要な場合もあります。 この移行は、Device Provisioning Service でポリシーを再プロビジョニングすることによってサポートされます。

再プロビジョニング ポリシー

シナリオに応じて、再起動時にデバイスからプロビジョニング サービス インスタンスに要求が送信される可能性があります。 また、オンデマンドでプロビジョニングを手動でトリガーする方法もサポートしています。 登録エントリの再プロビジョニング ポリシーによって、Device Provisioning Service インスタンスでこれらのプロビジョニング要求を処理する方法が決まります。 また、このポリシーによって、再プロビジョニング中にデバイスの状態データを移行する必要があるかどうかも決まります。 同じポリシーを個別の登録と登録グループに利用できます。

• データの再プロビジョニングと移行: このポリシーは新しい登録エントリの既定値です。 このポリシーは、登録エントリに関連付けられているデバイスが新しい要求 (1) を送信するときに処理されます。 登録エントリの構成に応じて、デバイスは別の IoT ハブに再割り当てされる可能性があります。 デバイスの割り当て先の IoT ハブが変更されると、最初の IoT ハブへのデバイスの登録は削除されます。 最初の IoT Hub から更新されたデバイスの状態情報は、新しい IoT Hub (2) に移行されます。 移行中、デバイスの状態は "割り当てています" と報告されます。

  

• 再プロビジョニングして初期構成にリセット: このポリシーは、登録エントリに関連付けられているデバイスが新しいプロビジョニング要求を送信したときにアクションを実行します (1)。 登録エントリの構成に応じて、デバイスは別の IoT ハブに再割り当てされる可能性があります。 デバイスの割り当て先の IoT ハブが変更されると、最初の IoT ハブへのデバイスの登録は削除されます。 プロビジョニング サービス インスタンスが、デバイスがプロビジョニングされたときに受け取った初期構成のデータは、新しい IoT Hub (2) に提供されます。 移行中、デバイスの状態は "割り当てています" と報告されます。

  このポリシーは、IoT Hub を変更せずにファクトリ リセットに使用されることが多いです。

  

• 再プロビジョニングしない: デバイスは別のハブに再プロビジョニングされることはありません。 このポリシーは、下位互換性を管理するために提供されます。

ソリューションを設計し、再プロビジョニング ロジックを定義する場合、いくつかの点を考慮する必要があります。 次に例を示します。

• 予想されるデバイスの再起動の頻度
• DPS のクォータと制限
• フリートでの予想されるデプロイ時間 (段階的なロールアウトの場合とすべて一括の場合)
• クライアント コードに実装された再試行機能。Azure アーキテクチャ センターの再試行の一般的なガイダンスを参照してください

下位互換性を管理する

2018 年 9 月より前は、IoT Hub へのデバイスの割り当てには固定の動作がありました。 デバイスがプロビジョニング プロセスから戻された場合、同じ IoT Hub に戻るように割り当てられるだけです。

この動作の依存関係を取得するソリューションの場合、プロビジョニング サービスには下位互換性が含まれます。 この動作は現在、次の条件に従ってデバイスに対して保持されます。

1. デバイスは、Device Provisioning Service のネイティブな再プロビジョニング サポートが利用可能になる前の API バージョンに接続されます。 以下の API の表を参照してください。

2. デバイスに対する登録エントリには、再プロビジョニングのポリシー セットがありません。

この互換性によって、以前にデプロイしたデバイスで、初期テスト時に存在したのと同じ動作が確実に行われるようになります。 前の動作を保持するには、再プロビジョニング ポリシーをこれらの登録に保存しないでください。 再プロビジョニング ポリシーが設定されると、再プロビジョニング ポリシーは動作より優先されます。 再プロビジョニング ポリシーが優先されることを許可することによって、顧客はデバイスの再イメージ化することなく、デバイスの動作を更新できます。

次のフロー チャートは、動作が存在するときを示しています。

以下の表は、Device Provisioning Service のネイティブな再プロビジョニング サポートが利用可能になる前の API バージョンを示しています。

次のステップ

• デバイスを再プロビジョニングする方法