IoT プラグアンドプレイモデリングガイド

[アーティクル]
09/12/2024

IoT プラグアンドプレイの中核となるのは、デバイスの機能を IoT プラグアンドプレイ対応アプリケーションに説明するデバイス モデルです。このモデルは、次の内容を定義するインターフェイスのセットとして構成されます。

デバイスまたは他のエンティティの読み取り専用および書き込み可能な状態を表す プロパティ。たとえば、デバイスのシリアル番号は読み取り専用のプロパティであり、サーモスタットでの目標温度は書き込み可能なプロパティとなります。
デバイスによって出力されるデータを定義する "テレメトリ" フィールド。このデータはセンサー読み取り値の通常のストリーム、偶発的なエラー、または情報メッセージのいずれかです。
デバイス上で実行できる関数または操作を記述した "コマンド"。たとえば、コマンドでは、ゲートウェイを再起動したり、リモートカメラを使用して写真を撮影したりすることが可能です。

IoT プラグアンドプレイがデバイスモデルをどのように使用するかについての詳細は、「IoT プラグアンドプレイデバイス開発者ガイド」と「IoT プラグアンドプレイサービス開発者ガイド」を参照してください。

モデルを定義するには、Digital Twins Definition Language (DTDL) を使用します。 DTDL が使用する JSON バリアントを JSON-LD と呼びます。次のスニペットは、以下のようなサーモスタットデバイスのモデルを示しています。

一意のモデル ID: dtmi:com:example:Thermostat;1 がある。
温度テレメトリを送信する。
ターゲット温度を設定するための書き込み可能プロパティがある。
前回の再起動以降の最高温度を報告する読み取り専用プロパティがある。
一定期間の最高、最低、および平均の温度を要求するコマンドに応答する。

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:com:example:Thermostat;1",
  "@type": "Interface",
  "displayName": "Thermostat",
  "description": "Reports current temperature and provides desired temperature control.",
  "contents": [
    {
      "@type": [
        "Telemetry",
        "Temperature"
      ],
      "name": "temperature",
      "displayName": "Temperature",
      "description": "Temperature in degrees Celsius.",
      "schema": "double",
      "unit": "degreeCelsius"
    },
    {
      "@type": [
        "Property",
        "Temperature"
      ],
      "name": "targetTemperature",
      "schema": "double",
      "displayName": "Target Temperature",
      "description": "Allows to remotely specify the desired target temperature.",
      "unit": "degreeCelsius",
      "writable": true
    },
    {
      "@type": [
        "Property",
        "Temperature"
      ],
      "name": "maxTempSinceLastReboot",
      "schema": "double",
      "unit": "degreeCelsius",
      "displayName": "Max temperature since last reboot.",
      "description": "Returns the max temperature since last device reboot."
    },
    {
      "@type": "Command",
      "name": "getMaxMinReport",
      "displayName": "Get Max-Min report.",
      "description": "This command returns the max, min and average temperature from the specified time to the current time.",
      "request": {
        "name": "since",
        "displayName": "Since",
        "description": "Period to return the max-min report.",
        "schema": "dateTime"
      },
      "response": {
        "name": "tempReport",
        "displayName": "Temperature Report",
        "schema": {
          "@type": "Object",
          "fields": [
            {
              "name": "maxTemp",
              "displayName": "Max temperature",
              "schema": "double"
            },
            {
              "name": "minTemp",
              "displayName": "Min temperature",
              "schema": "double"
            },
            {
              "name": "avgTemp",
              "displayName": "Average Temperature",
              "schema": "double"
            },
            {
              "name": "startTime",
              "displayName": "Start Time",
              "schema": "dateTime"
            },
            {
              "name": "endTime",
              "displayName": "End Time",
              "schema": "dateTime"
            }
          ]
        }
      }
    }
  ]
}

サーモスタットモデルには 1 つのインターフェイスがあります。この記事の後の例で示している、より複雑なモデルでは、コンポーネントと継承を使用しています。

この記事では独自のモデルを設計および作成する方法と、データ型、モデル構造、ツールなどのトピックについて説明しています。

詳しくは、Digital Twins Definition Language の仕様をご覧ください。

Note

現在、IoT Central では、IoT Central 拡張機能を備えた DTDL v2 がサポートされています。

モデル構造

プロパティ、テレメトリ、コマンドがインターフェイスにグループ化されています。このセクションでは、インターフェイスを使用して、単純および複雑な各モデルをコンポーネントと継承を使って記述する方法について説明します。

モデル ID

すべてのインターフェイスには、一意のデジタルツインモデル識別子 (DTMI) があります。複雑なモデルでは、DTMI を使用してコンポーネントを識別します。アプリケーションは、デバイスが送信してリポジトリ内のモデル定義を見つけるための DTMI を使用できます。

DTMI では、次の名前付け規則を使う必要があります。

DTMI プレフィックスは dtmi: である。
DTMI サフィックスは、モデルのバージョン番号 (例: ;2) である。
DTMI の本文は、モデルが格納されているモデルリポジトリ内のフォルダーとファイルにマップされている。バージョン番号はファイル名の一部です。

たとえば、DTMI dtmi:com:Example:Thermostat;2 によって識別されるモデルは dtmi/com/example/thermostat-2.json ファイルに格納されます。

次のスニペットは、一意の DTMI によるインターフェイス定義の概要を示しています。

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:com:example:Thermostat;2",
  "@type": "Interface",
  "displayName": "Thermostat",
  "description": "Reports current temperature and provides desired temperature control.",
  "contents": [
    ...
  ]
}

コンポーネントなし

単純なモデル (先ほど示したサーモスタットなど) では、埋め込みおよびカスケードコンポーネントを使用しません。テレメトリ、プロパティ、コマンドがインターフェイスの contents ノードで定義されます。

次の例は、コンポーネントを使用しない単純なモデルの一部を示しています。

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:com:example:Thermostat;1",
  "@type": "Interface",
  "displayName": "Thermostat",
  "description": "Reports current temperature and provides desired temperature control.",
  "contents": [
    {
      "@type": [
        "Telemetry",
        "Temperature"
      ],
      "name": "temperature",
      "displayName": "Temperature",
      "description": "Temperature in degrees Celsius.",
      "schema": "double",
      "unit": "degreeCelsius"
    },
    {
      "@type": [
        "Property",
...

Azure IoT Explorer や IoT Central デバイステンプレートデザイナーなどのツールは、サーモスタットのようなスタンドアロンインターフェイスに既定のコンポーネントのラベルを付けます。

次のスクリーンショットは、Azure IoT Explorer ツールでモデルがどのように表示されるかを示しています。

Azure IoT エクスプローラーツールの既定のコンポーネントを示すスクリーンショット。

次のスクリーンショットは、IoT Central デバイステンプレートデザイナーでモデルが既定のコンポーネントとして表示される様子を示しています。 [ID の表示] を選択して、モデルの DTMI を表示します。

IoT Central デバイステンプレートデザイナーツールのサーモスタットモデルを示すスクリーンショット。

モデル ID は、次のスクリーンショットに示すように、デバイスツインのプロパティに格納されます。

デジタルツインプロパティのモデル ID を示す Azure IoT Explorer ツールのスクリーンショット。

コンポーネントのない DTDL モデルは、1 つのセットのテレメトリ、プロパティ、およびコマンドを持つデバイスまたは IoT Edge モジュール用に簡略化されたモデルです。コンポーネントを使用しないモデルでは、既存のデバイスまたはモジュールを IoT プラグアンドプレイデバイスまたはモジュールに簡単に移行することができます。コンポーネントを定義することなく、実際のデバイスまたはモジュールを記述する DTDL モデルを作成します。

ヒント

モジュールは、デバイスモジュールまたは IoT Edge モジュールが可能です。

再利用

インターフェイス定義を再利用するには、2 つの方法があります。

モデル内で複数のコンポーネントを使用して、他のインターフェイス定義を参照します。
継承を使用して、既存のインターフェイス定義を拡張します。

複数のコンポーネント

コンポーネントを使用すると、他のインターフェイスのアセンブリとしてモデルインターフェイスを作成できます。

たとえば、Thermostat インターフェイスがモデルとして定義されているとします。 Temperature Controller モデルを定義するときに、このインターフェイスを 1 つ以上のコンポーネントとして組み込むことができます。次の例では、これらのコンポーネントを thermostat1 および thermostat2 と呼んでいます。

複数のコンポーネントを持つ DTDL モデルの場合は、2 つ以上のコンポーネントセクションがあります。次のスニペットに示すように、各セクションでは @type に Component が設定され、スキーマを明示的に参照しています。

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:com:example:TemperatureController;1",
  "@type": "Interface",
  "displayName": "Temperature Controller",
  "description": "Device with two thermostats and remote reboot.",
  "contents": [
    {
      "@type": [
        "Telemetry",
        "DataSize"
      ],
      "name": "workingSet",
      "displayName": "Working Set",
      "description": "Current working set of the device memory in KiB.",
      "schema": "double",
      "unit": "kibibyte"
    },
    {
      "@type": "Property",
      "name": "serialNumber",
      "displayName": "Serial Number",
      "description": "Serial number of the device.",
      "schema": "string"
    },
    {
      "@type": "Command",
      "name": "reboot",
      "displayName": "Reboot",
      "description": "Reboots the device after waiting the number of seconds specified.",
      "request": {
        "name": "delay",
        "displayName": "Delay",
        "description": "Number of seconds to wait before rebooting the device.",
        "schema": "integer"
      }
    },
    {
      "@type" : "Component",
      "schema": "dtmi:com:example:Thermostat;1",
      "name": "thermostat1",
      "displayName": "Thermostat One",
      "description": "Thermostat One of Two."
    },
    {
      "@type" : "Component",
      "schema": "dtmi:com:example:Thermostat;1",
      "name": "thermostat2",
      "displayName": "Thermostat Two",
      "description": "Thermostat Two of Two."
    },
    {
      "@type": "Component",
      "schema": "dtmi:azure:DeviceManagement:DeviceInformation;1",
      "name": "deviceInformation",
      "displayName": "Device Information interface",
      "description": "Optional interface with basic device hardware information."
    }
  ]
}

このモデルでは、contents セクションに 3 つのコンポーネントが定義されています (2 つの Thermostat コンポーネントと 1 つの DeviceInformation コンポーネント)。コンテンツセクションには、プロパティ、テレメトリ、およびコマンドの定義も含まれています。

次のスクリーンショットは、このモデルが IoT Central でどのように表示されるかを示しています。気温コントローラーのプロパティ、テレメトリ、およびコマンドの定義は、最上位の既定のコンポーネントに表示されます。各サーモスタットのプロパティ、テレメトリ、およびコマンドの定義は、コンポーネント定義に表示されます。

IoT Central での温度コントローラーデバイステンプレートを示すスクリーンショット。

IoT Central での温度コントローラーデバイステンプレートのサーモスタットコンポーネントを示すスクリーンショット。

コンポーネントと対話するデバイスコードを記述する方法については、「IoT プラグアンドプレイデバイス開発者ガイド」を参照してください。

デバイス上のコンポーネントと対話するサービスコードを記述する方法については、「IoT プラグアンドプレイサービス開発者ガイド」を参照してください。

継承

継承を使用すると、基底インターフェイスの機能を再利用して、インターフェイスの機能を拡張できます。たとえば、いくつかのデバイスモデルがシリアル番号などの一般的な機能を共有できます。

デバイスモデルでの継承の例を示す図。サーモスタットインターフェイスとフローコントローラーインターフェイスはどちらも、基本インターフェイスから機能を共有します。

次のスニペットは、上の図で示した継承関係を、extends キーワードを使用して定義する DTML モデルを示しています。

[
  {
    "@context": "dtmi:dtdl:context;2",
    "@id": "dtmi:com:example:Thermostat;1",
    "@type": "Interface",
    "contents": [
      {
        "@type": "Telemetry",
        "name": "temperature",
        "schema": "double",
        "unit": "degreeCelsius"
      },
      {
        "@type": "Property",
        "name": "targetTemperature",
        "schema": "double",
        "unit": "degreeCelsius",
        "writable": true
      }
    ],
    "extends": [
      "dtmi:com:example:baseDevice;1"
    ]
  },
  {
    "@context": "dtmi:dtdl:context;2",
    "@id": "dtmi:com:example:baseDevice;1",
    "@type": "Interface",
    "contents": [
      {
        "@type": "Property",
        "name": "SerialNumber",
        "schema": "double",
        "writable": false
      }
    ]
  }
]

次のスクリーンショットは、IoT Central デバイステンプレート環境におけるこのモデルを示しています。

IoT Central でのインターフェイス継承を示すスクリーンショット。

デバイスまたはサービス側コードを記述するとき、継承されたインターフェイスを操作するために特別なことをする必要はありません。このセクションで示している例では、デバイスコードにより、シリアル番号がサーモスタットインターフェイスの一部であるかのように報告されます。

ヒント

モデルを作成するときに、コンポーネントと継承を組み合わせることができます。次の図では、thermostat モデルが baseDevice インターフェイスから継承している様子を示しています。 baseDevice インターフェイスのコンポーネントは、それ自体が別のインターフェイスから継承しています。

コンポーネントと継承の両方を使用するモデルを示す図。

次のスニペットは、上の図で示した継承関係とコンポーネントの使用方法を、extends と component のキーワードを使って定義する DTML モデルを示しています。

[
  {
    "@context": "dtmi:dtdl:context;2",
    "@id": "dtmi:com:example:Thermostat;1",
    "@type": "Interface",
    "contents": [
      {
        "@type": "Telemetry",
        "name": "temperature",
        "schema": "double",
        "unit": "degreeCelsius"
      },
      {
        "@type": "Property",
        "name": "targetTemperature",
        "schema": "double",
        "unit": "degreeCelsius",
        "writable": true
      }
    ],
    "extends": [
      "dtmi:com:example:baseDevice;1"
    ]
  },
  {
    "@context": "dtmi:dtdl:context;2",
    "@id": "dtmi:com:example:baseDevice;1",
    "@type": "Interface",
    "contents": [
      {
        "@type": "Property",
        "name": "SerialNumber",
        "schema": "double",
        "writable": false
      },
      {
        "@type" : "Component",
        "schema": "dtmi:com:example:baseComponent;1",
        "name": "baseComponent"
      }
    ]
  }
]

データ型

データ型を使用して、テレメトリ、プロパティ、およびコマンドパラメーターを定義します。データ型には、プリミティブと複合があります。複合データ型は、プリミティブ、または他の複合型を使用します。複合型の最大深度は 5 レベルです。

プリミティブ型

次の表は、使用できる一連のプリミティブ型を示しています。

プリミティブ型	説明
`boolean`	ブール値
`date`	RFC 3339 のセクション 5.6 で定義されている完全な日付
`dateTime`	RFC 3339 で定義されている日付/時刻
`double`	IEEE 8 バイトの浮動小数点
`duration`	ISO 8601 形式の期間
`float`	IEEE 4 バイトの浮動小数点
`integer`	4 バイトの符号付き整数
`long`	8 バイトの符号付き整数
`string`	UTF8 文字列
`time`	RFC 3339 のセクション 5.6 で定義されている完全な時刻

次のスニペットは、schema フィールドで double 型を使用するテレメトリ定義の例を示しています。

{
  "@type": "Telemetry",
  "name": "temperature",
  "displayName": "Temperature",
  "schema": "double"
}

複合データ型

複合データ型は配列、列挙、マップ、オブジェクトのうちのいずれか、あるいは地理空間型のうちのいずれかです。

配列

配列はインデックス可能なデータ型であり、すべての要素が同じ型です。要素型は、プリミティブまたは複合のいずれかの型にできます。

次のスニペットは、schema フィールドで Array 型を使用するテレメトリ定義の例を示しています。配列の要素はブール値です。

{
  "@type": "Telemetry",
  "name": "ledState",
  "schema": {
    "@type": "Array",
    "elementSchema": "boolean"
  }
}

列挙

列挙は、値にマップする名前付きラベルのセットを持つ型を表します。値は整数にも文字列にもできますが、ラベルは常に文字列です。

次のスニペットは、schema フィールドで Enum 型を使用するテレメトリ定義の例を示しています。列挙の中の値は整数です。

{
  "@type": "Telemetry",
  "name": "state",
  "schema": {
    "@type": "Enum",
    "valueSchema": "integer",
    "enumValues": [
      {
        "name": "offline",
        "displayName": "Offline",
        "enumValue": 1
      },
      {
        "name": "online",
        "displayName": "Online",
        "enumValue": 2
      }
    ]
  }
}

Maps

マップとは、キーと値のペアを持つ型で、値の型はすべて同じです。マップの中のキーは、文字列でなければなりません。マップの中の値は、あらゆる型 (別の複合型を含む) にできます。

次のスニペットは、schema フィールドで Map 型を使用するプロパティ定義の例を示しています。マップの中の値は文字列です。

{
  "@type": "Property",
  "name": "modules",
  "writable": true,
  "schema": {
    "@type": "Map",
    "mapKey": {
      "name": "moduleName",
      "schema": "string"
    },
    "mapValue": {
      "name": "moduleState",
      "schema": "string"
    }
  }
}

Objects

オブジェクト型は、名前付きフィールドで構成されています。オブジェクトマップの中のフィールドの型は、プリミティブと複合のいずれかにできます。

次のスニペットは、schema フィールドで Object 型を使用するテレメトリ定義の例を示しています。オブジェクトの中のフィールドは dateTime、duration、および string の型です。

{
  "@type": "Telemetry",
  "name": "monitor",
  "schema": {
    "@type": "Object",
    "fields": [
      {
        "name": "start",
        "schema": "dateTime"
      },
      {
        "name": "interval",
        "schema": "duration"
      },
      {
        "name": "status",
        "schema": "string"
      }
    ]
  }
}

地理空間型

DTDL が提供する、GeoJSON に基づいた、地理空間データ構造をモデル化するための一連の地理空間型は point、multiPoint、lineString、multiLineString、polygon、multiPolygon などです。これらの型は、事前定義された、入れ子構造の配列、オブジェクト、列挙です。

次のスニペットは、schema フィールドで point 型を使用するテレメトリ定義の例を示しています。

{
  "@type": "Telemetry",
  "name": "location",
  "schema": "point"
}

地理空間型は配列ベースであるため、現在、プロパティ定義では使用できません。

セマンティック型

プロパティまたはテレメトリ定義のデータ型は、デバイスがサービスと交換するデータの形式を指定します。セマンティック型は、アプリケーションが値を処理または表示する方法を決定するために使用できるテレメトリとプロパティに関する情報を提供します。それぞれのセマンティック型には 1 つ以上の単位が関連付けられています。たとえば、摂氏と華氏は、温度のセマンティック型の単位です。 IoT Central のダッシュボードと分析では、セマンティック型情報を使用して、テレメトリまたはプロパティ値をプロットする方法と単位の表示方法を決定することができます。モデルパーサーを使ってセマンティック型を読み取る方法については、「Digital Twins モデルパーサーについて理解する」をご覧ください。

次のスニペットは、セマンティック型情報を含むテレメトリ定義の例を示しています。セマンティック型 Temperature は @type 配列に追加されており、unit の値である degreeCelsius はセマンティック型の有効な単位の 1 つです。

{
  "@type": [
    "Telemetry",
    "Temperature"
  ],
  "name": "temperature",
  "schema": "double",
  "unit": "degreeCelsius"
}

ローカリゼーション

IoT Central などのアプリケーションは、モデルの情報を使って、IoT プラグアンドプレイデバイスと交換されるデータに関する UI を動的に作成します。たとえば、ダッシュボード上のタイルには、テレメトリ、プロパティ、コマンドの名前と説明を表示できます。

モデルの中のオプションの description および displayName フィールドで保持される文字列は、UI で使用することが目的です。これらのフィールドで保持できるローカライズされた文字列を、アプリケーションが使用してローカライズされた UI を表示できます。

次のスニペットは、ローカライズされた文字列を含む温度テレメトリ定義の例を示しています。

{
  "@type": [
    "Telemetry",
    "Temperature"
  ],
  "description": {
    "en": "Temperature in degrees Celsius.",
    "it": "Temperatura in gradi Celsius."
  },
  "displayName": {
    "en": "Temperature",
    "it": "Temperatura"
  },
  "name": "temperature",
  "schema": "double",
  "unit": "degreeCelsius"
}

ローカライズされた文字列の追加は省略可能です。次の例には、1 つの既定の言語のみがあります。

{
  "@type": [
    "Telemetry",
    "Temperature"
  ],
  "description": "Temperature in degrees Celsius.",
  "displayName": "Temperature",
  "name": "temperature",
  "schema": "double",
  "unit": "degreeCelsius"
}

ライフサイクルとツール

デバイスモデルの 4 つのライフサイクルステージは、作成、公開、使用、バージョン管理です。

作成者

DTML デバイスモデルは、テキストエディターで作成できる JSON ドキュメントです。ただし、IoT Central では、デバイステンプレート GUI 環境を使用して DTML モデルを作成できます。 IoT Central では、次のことができます。

プロパティ、テレメトリ、コマンドを定義するインターフェイスを作成する。
コンポーネントを使用して複数のインターフェイスをまとめて組み立てる。
インターフェイス間の継承関係を定義する。
DTML モデルファイルをインポートおよびエクスポートする。

詳しくは、「Azure IoT Central アプリケーションで新しい IoT デバイスの種類を定義する」を参照してください。

DTDL v2 と DTDL v3 の両方をサポートする VS Code 用の DTDL オーサリング拡張機能があります。

VS Code に DTDL 拡張機能をインストールするには、「Visual Studio Code 用の DTDL エディター」を参照してください。 VS Code の [拡張機能] ビューで DTDL を検索することもできます。

拡張機能をインストールした後、それを使って VS Code で DTDL モデルファイルを作成します。

拡張機能により、DTDL モデルファイルでの構文の検証が提供され、次のスクリーンショットに示すように誤りが強調表示されます。
IntelliSense とオートコンプリートは、DTDL モデルの編集中に利用します。
新しい DTDL インターフェイスを作成します。 DTDL: Create Interface を使用すると、新しいインターフェイスを含む JSON ファイルが作成されます。インターフェイスには、テレメトリ、プロパティ、コマンド定義の例が含められます。

使用

IoT Central などのアプリケーションは、デバイスモデルを使用します。 IoT Central では、モデルはデバイスの機能を記述しているデバイステンプレートの一部です。 IoT Central は、デバイステンプレートを使用して、ダッシュボードや分析を含むデバイスの UI を動的にビルドします。

Note

IoT Central では、DTDL 言語に対するいくつかの拡張機能が定義されています。詳細については、IoT Central 拡張機能に関する記事を参照してください。

カスタムソリューションで Digital Twins モデルパーサーを使って、モデルを実装するデバイスの機能を理解できます。詳しくは、「IoT ソリューションで IoT プラグアンドプレイを使用する」をご覧ください。

Version

モデルを使用するデバイスとサーバー側ソリューションが動作し続けるようにするために、公開されたモデルは変更できません。

DTMI にはバージョン番号が含まれており、これを使用して、モデルの複数のバージョンを作成することができます。デバイスとサーバー側ソリューションは、使用するように設計されている特定のバージョンを使用できます。

IoT Central は、デバイスモデルに関して、より多くのバージョン管理ルールを実装しています。 IoT Central でデバイステンプレートとそのモデルをバージョン管理すると、デバイスを以前のバージョンから新しいバージョンに移行できます。ただし、移行したデバイスは、ファームウェアをアップグレードしないと、新しい機能を使用することができません。詳細については、デバイステンプレートの編集に関するページを参照してください。

公開

2024 年 2 月の時点で、Azure Certified Device プログラムは廃止されました。そのため、Microsoft は、Azure IoT プラグアンドプレイモデルリポジトリへの DTDL モデルの送信を受け入れなくなりました。

独自のモデルリポジトリを設定する場合は、Azure IoT プラグアンドプレイモデルツールリポジトリを使用できます。このリポジトリには、DTDL モデルを検証、インポート、拡張できる dmr-client CLI ツールのコードが含まれています。このツールを使うと、デバイスモデルリポジトリの規則に従ってモデルリポジトリにインデックスを付けることもできます。

制限および制約

次の一覧では、モデルに対するいくつかの重要な制約と制限をまとめています。

現在、配列、マップ、およびオブジェクトの最大深度は 5 レベルです。
プロパティ定義で配列を使用することはできません。
インターフェイスは 10 レベルの深度まで拡張できます。
インターフェイスは、最大で 2 つの、他のインターフェイスまで拡張できます。
コンポーネントが他のコンポーネントを含むことはできません。

Digital Twins モデルパーサーについて理解する

Digital Twins Definition Language (DTDL) については、DTDL の仕様に関する記事で説明されています。ユーザーは、Digital Twins モデルパーサー NuGet パッケージを使用して、DTDL v2 または v3 モデルを検証し、クエリを実行できます。 DTDL モデルは、複数のファイルで定義できます。

DTDL モデルパーサーをインストールする

このパーサーは、NuGet.org で DTDLParser という ID と共に使用できます。パーサーをインストールするには、Visual Studio や dotnet CLI などで互換性のある NuGet パッケージマネージャーを使用してください。

dotnet add package DTDLParser

Note

この記事の執筆時点では、パーサーのバージョンは 1.0.52 です。

パーサーを使用してモデルを検証および検査する

DTDLParser は、次の用途に使用できるライブラリです。

言語 v2 または v3 の仕様に従って、1 つ以上のモデルが有効かどうかを判断します。
特定のモデリングエラーを特定します。
モデルの内容を検査します。

1 つのモデルは、JSON ファイルに記述されている 1 つ以上のインターフェイスで構成されている場合があります。パーサーを使用すると、モデルを定義するすべてのファイルを読み込んでから、ファイル間の参照を含めたすべてのファイルを全体的に検証することができます。

DTDLParser for .NET リポジトリには、パーサーの使用方法を示す次のサンプルが含まれています。

DTDLParserResolveSample は、外部参照を使用してインターフェイスを解析し、Azure.IoT.ModelsRepository クライアントを使用して依存関係を解決する方法を示します。
DTDLParserJSInteropSample は、.NET JSInterop を使用して、ブラウザーで実行されている JavaScript の DTDL パーサーを使用する方法を示します。

DTDLParser for .NET リポジトリには、パーサーを使用してモデルを検証および検査する方法を示すチュートリアルのコレクションも含まれています。

モデルパーサー API を使うと、DTDL モデルに依存するタスクを自動化または検証する多くのシナリオが可能になります。たとえば、モデル内の情報から UI を動的に構築できます。

次のステップ

ここでは、デバイスのモデリングについて説明しました。その他のリソースを次に示します。

次の方法で共有

IoT プラグアンドプレイモデリングガイド

モデル構造

モデル ID

コンポーネントなし

再利用

複数のコンポーネント

継承

ヒント

データ型

プリミティブ型

複合データ型

配列

列挙

Maps

Objects

地理空間型

セマンティック型

ローカリゼーション

ライフサイクルとツール

作成者

使用

Version

公開

制限および制約

Digital Twins モデルパーサーについて理解する

DTDL モデルパーサーをインストールする

パーサーを使用してモデルを検証および検査する

次のステップ

フィードバック

その他のリソース

次の方法で共有

IoT プラグ アンド プレイ モデリング ガイド

モデル構造

モデル ID

コンポーネントなし

再利用

複数のコンポーネント

継承

ヒント

データ型

プリミティブ型

複合データ型

配列

列挙

Maps

Objects

地理空間型

セマンティック型

ローカリゼーション

ライフサイクルとツール

作成者

使用

Version

公開

制限および制約

Digital Twins モデル パーサーについて理解する

DTDL モデル パーサーをインストールする

パーサーを使用してモデルを検証および検査する

次のステップ

フィードバック

その他のリソース

IoT プラグアンドプレイモデリングガイド

Digital Twins モデルパーサーについて理解する

DTDL モデルパーサーをインストールする