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

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

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

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

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

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

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

デバイスの状態データ

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

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

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

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

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

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

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

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

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

  

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

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

  

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

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

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

下位互換性を管理する

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

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

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

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

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

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

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

次のステップ

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