シナリオ: TargetおよびcontentRootを使用した間接デバイス・データのルーティング
ゲートウェイ・アダプタのインバウンド・ルートでtargetおよびcontentRootを使用して、異なるネストされた構造を持つペイロードをルーティングするために、ゲートウェイおよび2つの間接的に接続されたデバイスを作成します。
このシナリオを使用して、1つのゲートウェイ、テレメトリが$.dataの下にネストされている間接的に接続されたHVACデバイス、およびテレメトリが$.telemetryの下にネストされている間接的に接続された圧縮機を作成します。ゲートウェイ・アダプタは、ターゲット・デバイスを解決し、各インバウンド・ルートで正しいコンテンツ・ルートを選択します。
その他の概念については、Indirectly Connected Devices FAQを参照してください。直接的および間接的に接続されたデバイス、非構造化テレメトリ、コマンド、およびローミングを含む一般的なゲートウェイワークフローについては、Create Digital Twins for Indirectly Connected Devices Using a Gatewayを参照してください。
タスク
- デジタル・ツイン・モデルの作成。
- デジタル・ツイン・アダプタを作成します。
- ゲートウェイおよびデバイス・インスタンスを作成します。
- 受信および拒否された遠隔測定データを送信します。
- デジタル・ツイン・インスタンスのコンテンツを取得します。
このシナリオの例を、gateway-model.json、hvac-model.json、compressor-model.json、gateway-envelope.json、gateway-routes.json、hvac-envelope.json、hvac-routes.json、compressor-envelope.jsonおよびcompressor-routes.jsonとして保存します。
ステップ1: デジタル・ツイン・モデルの作成
シナリオのデバイス・タイプごとに、ゲートウェイ用のデジタル・ツイン・モデルとデジタル・ツイン・モデルを1つ作成します。これらのデバイスは構造化データを生成します。
gateway-model.json、hvac-model.jsonおよびcompressor-model.jsonの各ファイルを使用します。
{
"@context": [
"dtmi:dtdl:context;3",
"dtmi:dtdl:extension:historization;1"
],
"@id": "dtmi:com:oracle:example:icd:contentroot:gateway;1",
"@type": "Interface",
"displayName": "Gateway Content Root",
"description": "Gateway model for route-level contentRoot coverage",
"contents": [
{
"@type": ["Telemetry", "Historized"],
"name": "cpuUtilization",
"schema": "integer"
},
{
"@type": ["Telemetry", "Historized"],
"name": "memoryUtilization",
"schema": "integer"
},
{
"@type": ["Telemetry", "Historized"],
"name": "storageUtilization",
"schema": "integer"
},
{
"@type": ["Property", "Historized"],
"name": "firmwareVersion",
"schema": "string"
}
]
}{
"@context": [
"dtmi:dtdl:context;3",
"dtmi:dtdl:extension:historization;1"
],
"@id": "dtmi:com:oracle:example:icd:contentroot:hvac;1",
"@type": "Interface",
"displayName": "HVAC Content Root Case 1",
"description": "Indirect device model for payloads nested under $.data",
"contents": [
{
"@type": ["Telemetry", "Historized"],
"name": "temperature",
"schema": "integer"
},
{
"@type": ["Telemetry", "Historized"],
"name": "humidity",
"schema": "integer"
}
]
}{
"@context": [
"dtmi:dtdl:context;3",
"dtmi:dtdl:extension:historization;1"
],
"@id": "dtmi:com:oracle:example:icd:contentroot:compressor;1",
"@type": "Interface",
"displayName": "Compressor Content Root Case 2",
"description": "Indirect device model for payloads nested under $.telemetry",
"contents": [
{
"@type": ["Telemetry", "Historized"],
"name": "pressure",
"schema": "integer"
},
{
"@type": ["Telemetry", "Historized"],
"name": "vibration",
"schema": "double"
}
]
}保存したモデル・ファイルをアップロードする場合、または仕様を直接貼り付ける場合は、コンソールを使用します。
- 「IoTドメイン」リスト・ページで、操作するドメインを開きます。IoTドメイン・リスト・ページの検索に関するヘルプが必要な場合は、IoTドメインのリストまたは新しいIoTドメインの作成を参照してください。
- 「デジタル・ツイン・モデル」タブを選択し、「作成」を選択します。
- 名前と説明(オプション)を入力します。機密情報を入力しないでください。
- 「仕様のアップロード」または「仕様の貼付け」を選択し、このシナリオのサンプル・ファイルの1つを使用します。
- オプション: タグを追加します。
- 「作成」を選択します。
仕様をアップロードまたは貼り付ける場合は、次のいずれかのファイルを使用します。
IoTドメインに各デジタル・ツイン・モデルを作成するには、oci iot digital-twin-model createコマンドを使用します。
ゲートウェイ・モデルの作成
oci iot digital-twin-model create --iot-domain-id <iot-domain-OCID> --spec file://gateway-model.jsonHVACモデルの作成
oci iot digital-twin-model create --iot-domain-id <iot-domain-OCID> --spec file://hvac-model.jsonコンプレッサ・モデルの作成
oci iot digital-twin-model create --iot-domain-id <iot-domain-OCID> --spec file://compressor-model.jsonサンプル・モデル・ファイル
gateway-model.json、hvac-model.jsonおよびcompressor-model.jsonを使用します。CreateDigitalTwinModel操作を実行して、IoTドメインにデジタル・ツイン・モデルを作成します。
APIをコールするときに、ダウンロード可能なデジタル・ツイン・モデル・ファイルに表示されるものと同じDTDLペイロードを使用します。
ステップ2: デジタルツインアダプタを作成する
ゲートウェイ用にデジタルツインアダプタを1つ作成し、間接的に接続されたデバイスタイプごとにアダプタを1つ作成します。gateway-envelope.json、gateway-routes.json、hvac-envelope.json、hvac-routes.json、compressor-envelope.jsonおよびcompressor-routes.jsonの各ファイルを使用します。
ゲートウェイアダプタパターンの選択
転送されたデバイス・メッセージで一貫したデバイス識別およびペイロード規則が1つ使用されている場合は、インバウンド・エンベロープでtargetを解決します。エンベロープ・レベルのtargetがデバイスに解決されると、サービスはゲートウェイのインバウンド・ルートを評価せずにメッセージを委任します。存在しないかnullに解決されると、サービスはインバウンド・ルートを評価します。
ゲートウェイが異なるデバイス・ファミリ、エンドポイントまたはペイロード構造を処理する場合は、インバウンド・ルートでtargetを解決します。エンベロープは共通メタデータをマップできますが、各ルートは、そのメッセージに適したtargetおよびcontentRootを定義します。
このシナリオでは、HVACデータが$.dataの下にネストされ、圧縮機データが$.telemetryの下にネストされ、フォールバック・ルートがゲートウェイに属するテレメトリをマップするため、ルート・レベルのターゲティングを使用します。
ターゲットおよびcontentRootによるルート
ゲートウェイ・エンベロープは、共通のtimeObservedメタデータをマップします。targetは定義されないため、サービスはインバウンド・ルートを順番に評価し、一致する最初のルートのみを処理します。
- HVACルートは、
targetをendpoint(2)から解決し、$.dataの下のオブジェクトをそのデバイスのアダプタに委任します。 - コンプレッサー・ルートは、
targetをendpoint(2)から解決し、$.telemetryの下のオブジェクトをそのデバイスのアダプタに委任します。 - 最後のデフォルト・ルートには
targetがありません。これは、ゲートウェイに属するテレメトリにpayloadMappingを適用します。
エンベロープ・レベルのtargetがNULL以外の値に解決される場合、サービスはエンベロープ・レベルのcontentRootを使用してメッセージを委任し、インバウンド・ルートを評価しません。ルート・レベルのtargetがnullに解決されると、そのcontentRootは無視されます。そのルートにもpayloadMappingがある場合、かわりにマッピングが現在のデジタル・ツインに適用されます。
エンベロープとインバウンド・ルートの両方にtargetを定義しないでください。contentRootをtargetでのみ定義し、targetとpayloadMappingを同じルートで結合しないようにします。
ゲートウェイ・エンベロープがtimeObservedを解決すると、ターゲット・アダプタはその値を継承します。ターゲット・アダプタによって解決されるnull以外のtimeObservedは、継承された値をオーバーライドします。
受信ペイロードをターゲット・デジタル・ツイン・モデルにマップする必要がある場合は、デジタル・ツイン・アダプタを使用します。デバイスが非構造化データを送信する場合、デジタル・ツイン・アダプタは必要ありません。データを変更せずに渡すことができます。
- 「IoTドメイン」リスト・ページで、操作するドメインを開きます。
- 「デジタル・ツイン・アダプタ」タブを選択し、「作成」を選択します。
- 「名前」およびオプションで「説明」を入力します。機密情報を入力しないでください。
- マッピングするペイロードと一致するデジタル・ツイン・モデルを選択します。
- 「インバウンド・エンベロープおよびルートの指定」をオンにして、エンベロープJSONをアップロードまたは貼り付け、アダプタのJSONをルーティングします。
- オプション: タグを追加します。
- 「作成」を選択します。
ゲートウェイ・ファイルを使用してゲートウェイ・アダプタを作成します。
ゲートウェイエンベロープ.json{ "referenceEndpoint": "/gateway/gateway-reference", "referencePayload": { "dataFormat": "JSON", "data": { "time": 1773768299143534, "cpuUtil": 30, "memUtil": 25, "diskUtil": 20, "firmware": "Oracle Linux 9.1" } }, "envelopeMapping": { "timeObserved": "$.time" } }ゲートウェイルート.json[ { "condition": "${endpoint(1) == \"hvac\"}", "contentRoot": "$.data", "target": "${endpoint(2)}" }, { "condition": "${endpoint(1) == \"compressor\"}", "contentRoot": "$.telemetry", "target": "${endpoint(2)}" }, { "condition": "*", "payloadMapping": { "$.cpuUtilization": "$.cpuUtil", "$.memoryUtilization": "$.memUtil", "$.storageUtilization": "$.diskUtil", "$.firmwareVersion": "$.firmware" } } ]一致するデバイス・ファイルを使用して、HVACアダプタおよび圧縮機アダプタを作成します。
hvac-envelope.json{ "referenceEndpoint": "/hvac/icd-case1-reference", "referencePayload": { "dataFormat": "JSON", "data": { "time": 1773768299143535, "temperature": 75, "humidity": 65 } }, "envelopeMapping": { "timeObserved": "$.time" } }hvac-routes.json[ { "condition": "*", "payloadMapping": { "$.temperature": "$.temperature", "$.humidity": "$.humidity" } } ]コンプレッサーエンベロープ.json{ "referenceEndpoint": "/compressor/icd-case2-reference", "referencePayload": { "dataFormat": "JSON", "data": { "time": 1773768299143536, "pressure": 101, "vibration": 0.42 } }, "envelopeMapping": { "timeObserved": "$.time" } }コンプレッサールート.json[ { "condition": "*", "payloadMapping": { "$.pressure": "$.pressure", "$.vibration": "$.vibration" } } ]IoTドメインに各アダプタを作成するには、oci iot digital-twin-adapter createコマンドを使用します。
ゲートウェイ・アダプタの作成
このコマンドを使用して、ゲートウェイのデジタル・ツイン・モデルを関連付け、エンベロープおよびルート・ファイルを指定します。
oci iot digital-twin-adapter create \ --iot-domain-id <iot-domain-OCID> \ --digital-twin-model-spec-uri "dtmi:com:oracle:example:icd:contentroot:gateway;1" \ --inbound-envelope file://gateway-envelope.json \ --inbound-routes file://gateway-routes.jsonゲートウェイエンベロープ.json{ "referenceEndpoint": "/gateway/gateway-reference", "referencePayload": { "dataFormat": "JSON", "data": { "time": 1773768299143534, "cpuUtil": 30, "memUtil": 25, "diskUtil": 20, "firmware": "Oracle Linux 9.1" } }, "envelopeMapping": { "timeObserved": "$.time" } }ゲートウェイルート.json[ { "condition": "${endpoint(1) == \"hvac\"}", "contentRoot": "$.data", "target": "${endpoint(2)}" }, { "condition": "${endpoint(1) == \"compressor\"}", "contentRoot": "$.telemetry", "target": "${endpoint(2)}" }, { "condition": "*", "payloadMapping": { "$.cpuUtilization": "$.cpuUtil", "$.memoryUtilization": "$.memUtil", "$.storageUtilization": "$.diskUtil", "$.firmwareVersion": "$.firmware" } } ]HVACアダプタを作成します
oci iot digital-twin-adapter create \ --iot-domain-id <iot-domain-OCID> \ --digital-twin-model-spec-uri "dtmi:com:oracle:example:icd:contentroot:hvac;1" \ --inbound-envelope file://hvac-envelope.json \ --inbound-routes file://hvac-routes.jsonhvac-envelope.json{ "referenceEndpoint": "/hvac/icd-case1-reference", "referencePayload": { "dataFormat": "JSON", "data": { "time": 1773768299143535, "temperature": 75, "humidity": 65 } }, "envelopeMapping": { "timeObserved": "$.time" } }hvac-routes.json[ { "condition": "*", "payloadMapping": { "$.temperature": "$.temperature", "$.humidity": "$.humidity" } } ]コンプレッサ・アダプタの作成
oci iot digital-twin-adapter create \ --iot-domain-id <iot-domain-OCID> \ --digital-twin-model-spec-uri "dtmi:com:oracle:example:icd:contentroot:compressor;1" \ --inbound-envelope file://compressor-envelope.json \ --inbound-routes file://compressor-routes.jsonコンプレッサーエンベロープ.json{ "referenceEndpoint": "/compressor/icd-case2-reference", "referencePayload": { "dataFormat": "JSON", "data": { "time": 1773768299143536, "pressure": 101, "vibration": 0.42 } }, "envelopeMapping": { "timeObserved": "$.time" } }コンプレッサールート.json[ { "condition": "*", "payloadMapping": { "$.pressure": "$.pressure", "$.vibration": "$.vibration" } } ]CLIからのファイルの参照の詳細は、「複雑な入力のためのJSONファイルの使用」を参照してください。
CreateDigitalTwinAdapter操作を実行して、IoTドメインにデジタル・ツイン・アダプタを作成します。
ダウンロード可能なファイルに示されているものと同じインバウンド・エンベロープおよびインバウンド・ルート・ペイロードを使用します。
ステップ3: ゲートウェイおよびデバイス・インスタンスの作成
最初にゲートウェイを作成して、間接的に接続されたデバイスを作成するときにゲートウェイを再利用できるようにします。
コンソールを使用してゲートウェイを作成し、複数のデバイスをゲートウェイに関連付けます。
コンソールには、IoTドメインのゲートウェイを作成する2つの方法があります。「デジタル・ツイン・インスタンス」タブからゲートウェイを作成するには、デジタル・ツイン・インスタンスの作成時にゲートウェイ・タイプを選択します。または、「ゲートウェイ」タブを選択してゲートウェイを作成できます。
- 「IoTドメイン」リスト・ページで、操作するIoTドメインを開きます。
- 「ゲートウェイ」タブを選択し、「作成」を選択して、間接デバイスで使用できるようにゲートウェイを作成します。
- 「IoTドメイン」ページで、「デジタル・ツイン・インスタンス」タブを選択し、「作成」を選択して、間接的に接続されたHVACインスタンスと間接的に接続されたコンプレッサー・インスタンスを作成します。
- ゲートウェイ・インスタンスに対して、認証IDを選択します。
- 間接的に接続されたインスタンスの場合、デバイス認証資格証明を追加するのではなく、1つ以上の既存のゲートウェイを選択します。
- オプション: タグを追加します。
- デジタル・ツイン・インスタンスのサマリーを確認し、「作成」を選択します。
デジタル・ツイン・インスタンスを作成した後、「ゲートウェイの詳細」ページを使用して、ゲートウェイに依存し、ゲートウェイに関連付けられているデバイスを表示します。- IoTドメイン・ページで「ゲートウェイの詳細」を検索するには、「ゲートウェイ」タブを選択してゲートウェイ・リストを表示し、ゲートウェイを選択してゲートウェイの詳細ページに移動します。
- 「デジタル・ツイン・インスタンス」タブでは、タイプで検索して、IoTドメインの様々なデジタル・ツイン・インスタンス・タイプを表示できます。
- デジタル・ツイン・インスタンスの詳細ページから、直接的および間接的に接続されたデバイスを表示します。
設定の完全なリストは、「デジタル・ツイン・インスタンスの作成」、「デジタル・ツイン・インスタンスのリスト」および「デジタル・ツインのインスタンスの詳細の取得」を参照してください。
oci iot digital-twin-instance createコマンドを使用して、最初にゲートウェイを作成してから、間接的に接続された2つのデバイス・インスタンスを作成します。
ゲートウェイ・インスタンスの作成
oci iot digital-twin-instance create \ --iot-domain-id <iot-domain-OCID> \ --connectivity-type GATEWAY \ --display-name "Gateway Content Root" \ --auth-id <certificate-or-secret-OCID> \ --digital-twin-adapter-id <gateway-adapter-OCID> \ --external-key gateway1間接的に接続されたHVACインスタンスの作成
oci iot digital-twin-instance create \ --iot-domain-id <iot-domain-OCID> \ --connectivity-type INDIRECT \ --display-name "HVAC Content Root Case 1" \ --gateways '["<gateway-instance-OCID>"]' \ --digital-twin-adapter-id <hvac-adapter-OCID> \ --external-key hvac1間接的に接続されたコンプレッサ・インスタンスの作成
oci iot digital-twin-instance create \ --iot-domain-id <iot-domain-OCID> \ --connectivity-type INDIRECT \ --display-name "Compressor Content Root Case 2" \ --gateways '["<gateway-instance-OCID>"]' \ --digital-twin-adapter-id <compressor-adapter-OCID> \ --external-key compressor1CreateDigitalTwinInstance操作を実行して、ゲートウェイ・インスタンスと2つの間接的に接続されたインスタンスを作成します。
間接的に接続されたインスタンスを作成する場合は、リクエストにゲートウェイ・アソシエーションが含まれていることを確認してください。
ステップ4: Telemetryデータの送信
認証IDオプション:
- デジタル・ツイン・インスタンスのテストでは、シークレットOCIDを認証IDとして使用する場合は、デバイス・ユーザー名を外部キーとして使用し、プレーン・テキストのシークレット・コンテンツをデバイス・パスワードとして使用します。手順については、シークレットの作成時にステップ7を参照し、すでに作成されているシークレットについては、シークレットのコンテンツの取得を参照してください。
本番のデジタル・ツイン・インスタンスでは、認証IDとしてボールト・シークレットのかわりにmTLS証明書OCIDを使用します。mTLS証明書を使用する場合は、証明書詳細の共通名を外部キーとして使用する必要があります:
--external-key <common-name-from-certificate-details>
- TLSを介したMQTTを使用して、ポート
8883の<domain-short-id>.device.iot.<region>.oci.oraclecloud.comに接続します。 - ゲートウェイは、この例のすべてのメッセージをパブリッシュするため、ゲートウェイ外部キー
gateway1として認証します。
デフォルト・ルートを介したゲートウェイ・テレメトリの送信:
mqttx pub \ -h '<domain-short-id>.device.iot.<region>.oci.oraclecloud.com' \ -p 8883 \ -l mqtts \ -t 'gateway/gateway1' \ -m '{ "time": 1773768299143534, "cpuUtil": 30, "memUtil": 25, "diskUtil": 20, "firmware": "Oracle Linux 9.1" }' \ -u gateway1 \ -P '<secret-contents>'デフォルト・ルートは、ゲートウェイ・ペイロードを
cpuUtilization、memoryUtilization、storageUtilizationおよびfirmwareVersionにマップします。Send HVAC telemetry Nested under
$.data:mqttx pub \ -h '<domain-short-id>.device.iot.<region>.oci.oraclecloud.com' \ -p 8883 \ -l mqtts \ -t 'hvac/hvac1' \ -m '{ "time": 1773768299143535, "data": { "temperature": 75, "humidity": 65 } }' \ -u gateway1 \ -P '<secret-contents>'$.telemetryの下にネストされた圧縮機テレメトリを送信する:mqttx pub \ -h '<domain-short-id>.device.iot.<region>.oci.oraclecloud.com' \ -p 8883 \ -l mqtts \ -t 'compressor/compressor1' \ -m '{ "time": 1773768299143536, "telemetry": { "pressure": 101, "vibration": 0.42 } }' \ -u gateway1 \ -P '<secret-contents>'これらのメッセージを使用して、各ルートが構成済の
contentRootを強制的に適用することを確認します。選択したネストされたオブジェクトが欠落しているため、これらのテスト・メッセージは拒否されます。$.dataではなく$.telemetryでHVACメッセージを送信します:mqttx pub \ -h '<domain-short-id>.device.iot.<region>.oci.oraclecloud.com' \ -p 8883 \ -l mqtts \ -t 'hvac/hvac1' \ -m '{ "time": 1773768299143537, "telemetry": { "temperature": 76, "humidity": 66 } }' \ -u gateway1 \ -P '<secret-contents>'$.telemetryのかわりに$.dataを使用して圧縮プログラム・メッセージを送信します:mqttx pub \ -h '<domain-short-id>.device.iot.<region>.oci.oraclecloud.com' \ -p 8883 \ -l mqtts \ -t 'compressor/compressor1' \ -m '{ "time": 1773768299143538, "data": { "pressure": 102, "vibration": 0.52 } }' \ -u gateway1 \ -P '<secret-contents>'
オプションのステップ5: デジタル・ツイン・インスタンスのコンテンツの取得
最新のスナップショット・コンテンツを取得して、受け入れられた各ペイロードが予期されるデジタル・ツイン・インスタンスにマッピングされたことを確認します。
- IoTドメインを開き、「デジタル・ツイン・インスタンス」タブを選択します。
- ゲートウェイ、HVACまたは圧縮機のデジタル・ツイン・インスタンスを選択します。
- 「データ」タブを選択して、最新のスナップショット・データを表示します。
oci iot digital-twin-instance get-contentコマンドを使用して、マップされたフィールドを確認します。
ゲートウェイ・フィールドの検証:
cpuUtilization、memoryUtilization、storageUtilizationおよびfirmwareVersion。oci iot digital-twin-instance get-content --digital-twin-instance-id <gateway-instance-OCID>HVACフィールドの検証:
temperatureおよびhumidity。oci iot digital-twin-instance get-content --digital-twin-instance-id <hvac-instance-OCID>コンプレッサー・フィールドの検証:
pressureおよびvibration。oci iot digital-twin-instance get-content --digital-twin-instance-id <compressor-instance-OCID>GetDigitalTwinInstanceContent操作を実行して、デジタル・ツイン・インスタンスからコンテンツを取得します。
デジタル・ツイン・インスタンスに適した接続タイプの選択
デジタル・ツイン・インスタンスに使用する接続タイプを決定する方法:
直接に接続済
- 使用条件
- デバイスは、単独でIoTドメインに接続します。
- 必須のパラメータ
- 認証IDは、テストにはシークレットを使用し、本番にはmTLS証明書を使用します。
- オプションの入力
- デバイス・ペイロードに構造化データが含まれていて、受信する形式でデータを送信するようにデバイスをプログラミングできない場合は、デジタル・ツイン・アダプタを使用して、使用する形式にデータを変換します。この場合、デジタル・ツイン・インスタンスには、データを構造化するデジタル・ツイン・モデルと、使用する形式にデータを変換するデジタル・ツイン・アダプタが関連付けられています。
- 次は使用しません
- ゲートウェイの関連付け。
Gateway
- 使用条件
- 1つのデバイスは、データやコマンドを自身や他のデバイスに転送します。
- 必要なパラメータ
- 認証ID、ゲートウェイ・アダプタおよび外部キー。
- 推奨フォローアップ
- ゲートウェイを変更または削除する前に、ゲートウェイの詳細ページを確認して、ゲートウェイに依存するデバイスの数を確認します。
- しない
- ゲートウェイ・インスタンスを別のゲートウェイ・インスタンスに関連付けます。
間接的に接続
- 使用条件
- 別のデバイス(通常はゲートウェイ)は、デバイスの代わりにテレメトリデータを送信し、コマンドを受信します。
- 必須
- 1つ以上のゲートウェイ・アソシエーション。
- オプション
- デジタル・ツイン・アダプタ。デバイスが構造化テレメトリを使用し、ゲートウェイが転送した後もペイロード・マッピングが必要になります。
- 次は使用しません
- 間接的に接続されたデジタル・ツイン・インスタンスの認証ID。
未接続
- 使用条件
- 認証やデータなしでIoTデジタル・ツイン・インスタンスをテストします。
- 必須
- このデジタル・ツイン・インスタンスで認証を使用したり、データを送受信したりしないでください。
- オプション
- テスト時には、デジタル・ツイン・インスタンスのデジタル・ツイン関係を設定できます。
- 次は使用しません
- 接続されていないデジタル・ツイン・インスタンスの認証ID。
FAQ
- ゲートウェイのインバウンド・ルートはいつ評価されますか。
- サービスがインバウンド・ルートを評価するのは、ゲートウェイ・エンベロープの
target式がないか、nullに解決された場合のみです。エンベロープ・レベルのターゲットがnull以外の値に解決された場合、メッセージは即時に委任され、インバウンド・ルートは評価されません。 - ルート・レベルのターゲティングではなくエンベロープ・レベルのターゲティングを使用する必要があるのはどのような場合ですか。
- 転送されたデバイス・メッセージが1つの一貫性のあるデバイス識別およびペイロード規則に従っている場合は、エンベロープ・レベルのターゲティングを使用します。デバイス・ファミリで異なるターゲット式、コンテンツ・ルート、エンドポイント条件またはペイロード・マッピングが必要な場合、ルート・レベルのターゲット指定を使用します。
- ルート・レベルの
targetは何を識別しますか。 - これは、ゲートウェイに関連付けられたデジタル・ツイン・インスタンスの外部キーに解決される必要があるJQ式です。このシナリオでは、
${endpoint(2)}はhvac1またはcompressor1に解決されます。 targetは受信エンドポイントを変更しますか。- 番号
target式は、間接的に接続されたデジタル・ツインとそのアダプタを解決しますが、エンドポイントはリライトしません。ターゲット・アダプタは元のエンドポイントを受信し、独自のインバウンド・ルートを評価します。 - ターゲット・アダプタに複数のインバウンド・ルートを設定できますか。
- はい。ターゲット・アダプタでは、ワイルドカード・ルートを含む条件ベースのルートを使用できます。元のエンドポイントは保持されるため、アダプタが直接および間接的に接続されたデバイスによって共有される場合は、ルート条件を慎重に設計してください。
- ルート・レベルの
contentRootはいつ使用されますか。 - このルートの
targetがnull以外の値に解決される場合にのみ使用されます。サービスは、選択したオブジェクトをターゲットデバイスのアダプタに委任します。HVACルートは$.dataを選択し、圧縮ルートは$.telemetryを選択します。 - ルートの
targetがnullに解決されるとどうなりますか。 - ルートの
contentRootは無視されます。ルートにpayloadMappingも含まれている場合、マッピングは現在のデジタル・ツイン・インスタンスに適用されます。デフォルトルートでは、ゲートウェイテレメトリにこの動作が使用されます。 - ゲートウェイは、独自のテレメトリをどのように処理できますか。
targetが存在しないゲートウェイ・ルートまたはnullに解決されるゲートウェイ・ルートを定義し、payloadMappingを使用してデータをゲートウェイのデジタル・ツインにマップします。ゲートウェイテレメトリおよび間接的に接続されたデバイステレメトリでは、個別のエンドポイントを使用して、各ルートが明確な状態になるようにできます。- ターゲット外部キーはエンドポイントではなくメッセージから取得できますか。
- はい。ターゲット式は、受信JSONメッセージの最上位レベルのデバイス・キーなど、共有エンベロープ・フィールドから外部キーを解決できます。これは、クライアントが各デバイス・キーをエンドポイントに配置するのではなく、安定したトピックを使用する場合に役立ちます。
- 1つのデジタル・ツイン・モデルに複数のアダプタを使用できますか。
- はい。デバイスで異なるデータ構造を使用する場合は、同じモデルに対して複数のアダプタを作成できます。各デジタル・ツイン・インスタンスは、受信データと一致するアダプタに関連付けられます。
- 直接および間接的に接続されたデバイスはアダプタを共有できますか。
- はい。ペイロード構造とエンドポイント・ルーティング要件に互換性がある場合です。アダプタは通常、接続トポロジではなく、受信データの構造を表します。
- アダプタは、エンベロープ・マッピング・セクションをいくつ定義できますか。
- アダプタには、1つの
envelopeMappingセクションがあります。アダプタが間接的に接続された複数のデバイス・タイプまたはペイロード構造をルーティングする必要がある場合は、ルート・レベルのtargetおよびcontentRoot値を使用します。 timeObservedは委任後にどのように処理されますか。- ターゲット・アダプタは、ゲートウェイ・エンベロープによって解決されたnull以外の
timeObserved値を継承します。ターゲット・アダプタが独自の非NULL値を解決すると、その値は継承されたタイムスタンプをオーバーライドします。 - なぜcontent-rootテスト・メッセージが拒否されるのですか。
- HVACルートは
$.dataを委任するため、$.telemetryのみを含むペイロードは、予期されるHVACデータを提供しません。コンプレッサー・ルートは$.telemetryを委任するため、$.dataのみを含むペイロードは、予期されるコンプレッサー・データを提供しません。
次のステップ
コマンド、非構造化テレメトリ、ローミングなどの追加のゲートウェイワークフローについては、Create Digital Twins for Indirectly Connected Devices Using a Gatewayを参照してください。
このシナリオの作成に使用されたリソースを削除します。