役割と操作

IoT ソリューションの開発フェーズは、製造時間、出荷、通関業務などの実際的な生産条件のために、数週間または数か月にわたる場合があります。さらに、さまざまな存在が関与している場合、複数の役割にまたがる活動にわたることがあります。 このトピックでは、各フェーズに関連するさまざまな役割と操作を詳しく説明し、フローを流れ図で示します。

プロビジョニングでは、構成証明メカニズムの有効化に固有の、デバイスの製造元に対する要件もあります。 製造操作は、自動プロビジョニング フェーズのタイミングとは無関係に生じる場合もあります。特に、自動プロビジョニングが既に確立された後で新しいデバイスが調達される際に発生します。

一連のクイック スタートが左側の目次に用意されており、ハンズオン エクスペリエンスによる自動プロビジョニングの説明に役立ちます。 学習プロセスを簡易にする目的で、物理デバイスの加入および登録をシミュレートするために、ソフトウェアが使用されます。 一部のクイック スタートでは、クイック スタートのシミュレーションとしての性質のために、複数の役割に対する操作を、存在しない役割に対する操作も含めて、実行する必要があります。

役割 操作 説明
メーカー ID と登録 URL をエンコードする 使用される構成証明メカニズムに基づいて、製造元は、デバイスの ID 情報と Device Provisioning Service の登録 URL をエンコードします。

クイック スタート: デバイスがシミュレートされるため、製造元の役割はありません。 この情報の取得方法の詳細については、開発者の役割を参照してください。この情報は、サンプル登録アプリケーションのコーディングで使用されます。
デバイス ID を指定する 製造元は、デバイス ID 情報の作成者として、情報をオペレーター (または指定されたエージェント) に通知するか、API を通じて Device Provisioning Service への加入操作を直接行う責任があります。

クイック スタート: デバイスがシミュレートされるため、製造元の役割はありません。 デバイス ID を取得する方法の詳細については、オペレーターの役割を参照してください。デバイス ID は、シミュレートされているデバイスを Device Provisioning Service インスタンスに加入させるために使用されます。
Operator 自動プロビジョニングを構成する この操作は、自動プロビジョニングの第 1 フェーズに対応します。

クイック スタート: オペレーターの役割として、Azure サブスクリプション内の Device Provisioning Service および IoT Hub のインスタンスを構成します。
デバイス ID を加入させる この操作は、自動プロビジョニングの第 2 フェーズに対応します。

クイック スタート: オペレーターの役割として、シミュレートされたデバイスを Device Provisioning Service インスタンスに加入させます。 デバイス ID は、クイック スタートでシミュレートされている構成証明方法 (TPM または X.509) によって決定されます。 構成証明の詳細については、開発者の役割を参照してください。
Device Provisioning Service、
IoT Hub
<すべての操作> 物理デバイスによる運用実装でも、シミュレートされたデバイスによるクイック スタートでも、これらの役割は、Azure サブスクリプションで構成する IoT サービスを通じて実行されます。 IoT サービスのプロビジョニングでは、物理デバイスとシミュレートされたデバイスとの区別がないため、役割/操作は、まったく同じように機能します。
開発者 登録ソフトウェアをビルド/デプロイする この操作は、自動プロビジョニングの第 3 フェーズに対応します。 開発者は、適切な SDK を使用して、登録ソフトウェアをビルドし、デバイスにデプロイします。

クイック スタート: ビルドするサンプル登録アプリケーションが、実際のデバイスをシミュレートします。プラットフォームと言語は選択することができ、ワークステーション上で実行されます (物理デバイスにデプロイするのではなく)。 登録アプリケーションは、物理デバイスにデプロイされるアプリケーションと同じ操作をします。 構成証明方法 (TPM または X.509 証明書) と、Device Provisioning Service インスタンスの登録 URL および "ID スコープ" を指定します。 デバイス ID は、指定した以下の方法に基づいて、実行時の SDK 構成証明ロジックによって決められます。
  • TPM 構成証明 - 開発ワークステーションが TPM シミュレーター アプリケーションを実行します。 実行されると、デバイス ID の加入に使用される TPM の "保証キー" と "登録 ID" を展開するために別のアプリケーションが使用されます。 SDK の構成証明ロジックも、登録中にシミュレーターを使用し、認証および加入の検証に対して、署名された SAS トークンを提示します。
  • X509 構成証明 - 証明書を生成するために、ツールを使用します。 生成されたら、加入で使用するために必要な証明書ファイルを作成します。 SDK の構成証明ロジックも、登録中に証明書を使用し、認証および加入の検証に対して提示します。
機器 起動して登録する この操作は、自動プロビジョニングの第 3 フェーズに対応し、開発者によってビルドされたデバイス登録ソフトウェアによって実行されます。 詳細については、開発者の役割を参照してください。 最初のブートで、以下のことが実行されます。
  1. アプリケーションは、開発中に指定されたグローバル URL およびサービス "ID スコープ" ごとに Device Provisioning Service インスタンスに接続します。
  2. 接続すると、デバイスは加入時に指定された構成証明方法と ID で認証されます。
  3. 認証されると、プロビジョニング サービス インスタンスによって指定された IoT Hub インスタンスにデバイスが登録されます。
  4. 登録が正常に実行されると、一意のデバイス ID と IoT Hub エンドポイントが登録アプリケーションに返されます。これらは、IoT Hub との通信に使用されます。
  5. そこから、デバイスは構成用に初期デバイス ツイン状態を入手して、テレメトリ データの報告プロセスを開始することができます。
クイック スタート: デバイスはシミュレートされるため、登録ソフトウェアは開発ワークステーション上で実行されます。

次の図は、デバイスの自動プロビジョニング中の役割と操作の流れをまとめたものです。

Auto-provisioning sequence for a device

Note

必要に応じて、製造元も Device Provisioning Service API を使用して (オペレーター経由ではなく)、"デバイス ID の加入" 操作を実行することができます。 この流れなどの詳細については、ビデオ「Zero touch device registration with Azure IoT (ゼロ タッチでの Azure IoT へのデバイスの登録)」(41:00 のマーカーから) を参照してください。

役割と Azure アカウント

各役割の Azure アカウントへのマップ方法はシナリオによって異なり、関わってくるシナリオの数は少なくありません。 以下の一般的なパターンでは、役割が Azure アカウントに通常どのようにマップされるかに関して大まかな考え方を理解できます。

チップの製造元によるセキュリティ サービスの提供

このシナリオでは、製造元は、第 1 レベルの顧客のセキュリティを管理します。 このシナリオは、これらの第 1 レベルの顧客は詳細なセキュリティを管理する必要がないため、これらの顧客により適している可能性があります。

この製造元は、ハードウェア セキュリティ モジュール (HSM) にセキュリティを導入します。 このセキュリティには、DPS インスタンスと登録グループを設定済みの潜在顧客の製造元取得のキー、証明書などが含まれます。 製造元は、このセキュリティ情報をその顧客用にも生成できます。

このシナリオでは、次の 2 つの Azure アカウントが関連する可能性があります。

  • アカウント #1: オペレーターと開発者の役割間である程度共有されている場合があります。 このパーティは、製造元から HSM チップを購入します。 これらのチップは、アカウント #1 に関連付けられている DPS インスタンスを指します。 DPS 登録により、このパーティは DPS におけるデバイスの登録設定を再構成することにより、デバイスを複数の第 2 レベルの顧客にリースできます。 また、このパーティは、デバイス テレメトリなどにアクセスためのインターフェイスとして IoT ハブをエンドユーザー バックエンド システム用に割り当てることもできます。後者の場合、2 番目のアカウントは必要ないかもしれません。

  • アカウント #2: エンドユーザー、第 2 レベルの顧客は、独自の IoT ハブを持っていない場合があります。 アカウント #1 に関連付けられたパーティは、このアカウントで、リースされたデバイスによって適切なハブをポイントするだけです。 この構成では、Azure アカウント間で DPS と IoT ハブをリンクする必要があります。このためには、Azure Resource Manager テンプレートを使用します。

オールインワン OEM

製造元は、1 つの製造元アカウントのみが必要となる "オールインワン OEM" になることができます。 製造元は、セキュリティとプロビジョニングをエンド ツー エンドで処理します。

製造元は、デバイスを購入した顧客にクラウドベースのアプリケーションを提供できます。 このアプリケーションは、製造元によって割り当てられた IoT ハブとやり取りします。

自動販売機やコーヒー メーカーは、このシナリオの代表例です。

次のステップ

自動プロビジョニングの各クイック スタートを実行する際に、この記事を参照の起点としてお気に入りに登録しておくと便利です。

まず、自分に適した管理ツールでの「自動プロビジョニングをセットアップする」クイック スタートを実行します。このクイック スタートでは、"サービスの構成" フェーズを実行できます。

次に、お使いのデバイス構成証明メカニズムや好みの Device Provisioning Service SDK と言語に適した「デバイスのプロビジョニング」クイックスタートに進みます。 このクイック スタートでは、"デバイスの加入" と "デバイスの登録および構成" フェーズについて具体的に説明しています。

デバイス構成証明メカニズム クイックスタート
対称キー シミュレートされた対称キーのデバイスをプロビジョニングする
X.509 証明書 シミュレートされた X.509 デバイスをプロビジョニングする
シミュレート済みのトラステッド プラットフォーム モジュール (TPM) シミュレートされた TPM デバイスをプロビジョニングする