ツイン モデルについて、および Azure Digital Twins で定義する方法について説明します。

Azure Digital Twins の重要な特性は、独自のボキャブラリを定義し、ビジネスの自己定義用語でツイン グラフを構築できることです。 この機能は、ユーザー提供のモデルを通じて提供されます。 モデルは、世界を説明するための名詞と考えることができます。 Azure Digital Twins のモデルは、JSON-LD ベースの Digital Twin Definition language (DTDL) で表現されます。

モデルは、オブジェクト指向プログラミング言語のクラスに似ており、実際の作業環境における 1 つの特定の概念のデータ シェイプを定義します。 モデルには名前 (Room や TemperatureSensor など) があり、プロパティ、テレメトリ、環境内でこの型のエンティティに何ができるかを説明するリレーションシップなどの要素が含まれています。 後で、これらのモデルを使用して、この型の説明と一致する特定のエンティティを表すデジタル ツインを作成します。

モデル用の Digital Twin Definition Language (DTDL)

Azure Digital Twins のモデルは、Digital Twins Definition Language (DTDL) を使用して定義されます。

DTDL の完全な言語仕様については、GitHub: Digital Twins Definition Language (DTDL) - Version 2 を参照してください。 このページには、独自の DTDL モデルを作成し始める際に役立つ詳細な DTDL リファレンスと例が含まれています。

DTDL は JSON-LD に基づいており、プログラミング言語に依存しません。 DTDL は Azure Digital Twins 専用ではなく、IoT プラグ アンド プレイなどの他の IoT サービスのデバイス データを表すためにも使用されます。 Azure Digital Twins は DTDL バージョン 2 を使用します (Azure Digital Twins での DTDL バージョン 1 の使用は非推奨となりました)。

この記事の残りの部分では、Azure Digital Twins で言語を使用する方法について説明します。

Azure Digital Twins DTDL の実装の仕様

DTDL を使用するすべてのサービスで、DTDL の機能がまったく同じに実装されるわけではありません。 いくつかの DTDL 機能は Azure Digital Twins で現在サポートされていません。次に例を示します。

  • DTDL コマンド
  • プロパティまたはリレーションシップの writable 属性。 この属性は DTDL 仕様に従って設定できますが、Azure Digital Twins では使用しません。 代わりに、これらの属性は常に、Azure Digital Twins サービスに対する一般的な書き込みアクセス許可を持つ外部クライアントによって書き込み可能として扱われます。
  • リレーションシップの minMultiplicitymaxMultiplicity プロパティ。 これらの属性は DTDL 仕様に従って設定できますが、値は Azure Digital Twins によって適用されません。

DTDL モデルに Azure Digital Twins との互換性を与えるには、これらの要件も満たす必要があります。

  • モデルの最上位レベルの DTDL 要素は、すべて "Interface" 型である必要があります。 この要件の理由は、Azure Digital Twins モデル API で、インターフェイスまたはインターフェイスの配列のいずれかを表す、JSON オブジェクトを受け取ることができるためです。 その結果、最上位レベルでは他の DTDL 要素型を使用できません。
  • Azure Digital Twins の DTDL では、"コマンド" を定義しないでください。
  • Azure Digital Twins では、単一レベルのコンポーネントの入れ子のみを許可します。これは、コンポーネントとして使用されているインターフェイス自体にはコンポーネントを含められないことを意味します。
  • インターフェイスは、他の DTDL インターフェイスの内部にインラインで定義することはできません。それらは、独自の ID を備えた個別の最上位レベルのエンティティとして定義する必要があります。 その後、別のインターフェイスがそのインターフェイスをコンポーネントとして含めるか、継承を通じて含めようとする場合は、その ID を参照できます。

モデルの概要

モデルの要素

モデル定義内では、最上位レベルのコード項目はインターフェイスです。 この種類によって、モデル全体がカプセル化され、モデルの残りの部分はインターフェイス内で定義されます。

DTDL モデルのインターフェイスには、以下の各フィールドをゼロ個、1 個、または複数個、含めることができます。

  • Property - プロパティは、エンティティの状態を表すデータ フィールドです (多くのオブジェクト指向プログラミング言語のプロパティと同様)。 プロパティはバッキング ストレージを備えていて、いつでも読み取ることができます。 詳細については、以下の「プロパティとテレメトリ」を参照してください。

  • Telemetry - テレメトリ フィールドは測定値またはイベントを表し、多くの場合、デバイスのセンサーの読み取りを説明するために使用されます。 プロパティとは異なり、テレメトリはデジタル ツインに格納されません。これは、発生時に処理される必要がある一連の期限付きデータ イベントです。 詳細については、以下の「プロパティとテレメトリ」を参照してください。

  • Relationship - リレーションシップを使用すると、あるデジタル ツインと他のデジタル ツインの関係性を表すことができます。 リレーションシップは、さまざまなセマンティックな意味を表す可能性があります。たとえば、contains ("フロアに部屋が含まれる")、cools ("hvac によって部屋が冷やされる")、isBilledTo ("コンプレッサーがユーザーに請求される") などです。 リレーションシップにより、ソリューションは相互に関連するエンティティのグラフを提供できます。 リレーションシップには、独自のプロパティを含めることもできます。 詳細については、以下の「リレーションシップ」を参照してください。

  • Component - コンポーネントを使用すると、必要に応じてモデル インターフェイスを他のインターフェイスの組み合わせとして構築できます。 コンポーネントの例として、"電話" のモデルの定義に使用される frontCamera インターフェイス (およびもう 1 つのコンポーネント インターフェイスである backCamera) があります。 まず、frontCamera のインターフェイスを独自のモデルであるかのように定義します。その後、Phone を定義するときに、それを参照します。

    コンポーネントを使用するのは、ソリューションの不可欠な要素でありながら、個別の ID を必要とせず、ツイン グラフで独立して作成、削除、および再配置する必要がないものを記述する場合です。 エンティティがツイン グラフ内で独立した存在になるようにするには、それらを異なるモデルの個別のデジタル ツインとして表現し、「リレーションシップ」で接続します。

    ヒント

    コンポーネントは、モデル インターフェイス内の関連するプロパティをグループ化するために、組織に使用することもできます。 この状況では、各コンポーネントをインターフェイス内の名前空間または "フォルダー" と考えることができます。

    詳細については、以下の「コンポーネント」を参照してください。

注意

DTDL の仕様では、Commands も定義されています。これは、デジタル ツインに対して実行できるメソッドです (リセット コマンドや、ファンをオンまたはオフに切り替えるためのコマンドなど)。 ただし、"Azure Digital Twins では現在、コマンドがサポートされていません"。

モデル コード

ツインの型モデルは、任意のテキスト エディターで記述できます。 DTDL 言語は、JSON 構文に従います。そのため、モデルは json という拡張子で保存する必要があります。 JSON 拡張子を使用すると、多くのプログラミング テキスト エディターで、DTDL ドキュメントの基本的な構文チェックと強調表示ができるようになります。 また、Visual Studio Code では、DTDL 拡張子も使用できます。

モデルのフィールドは次のとおりです。

フィールド 説明
@id モデルの識別子。 dtmi:<domain>:<unique-model-identifier>;<model-version-number> の形式でなければなりません。
@type 記述されている情報の種類を識別します。 インターフェイスの場合、型は Interface です。
@context JSON ドキュメントのコンテキストを設定します。 モデルは dtmi:dtdl:context;2 を使用する必要があります。
displayName [省略可能] モデルのわかりやすい名前を定義するオプションを提供します。 このフィールドを使用しない場合、モデルはそれの完全な DTMI 値を使用します。
contents 残りのすべてのインターフェイス データは、属性定義の配列としてここに配置されます。 各属性には、それが表現するインターフェイス情報の種類を識別するための @type (PropertyTelemetryRelationship、または Component) と、実際の属性を定義する一連のプロパティ (たとえば、Property を定義するための name および schema) を指定する必要があります。

モデル例

このセクションでは、DTDL インターフェイスとして記述された基本的なモデルの例を示します。

このモデルでは、ID に 1 つのプロパティを持つ Home が記述されています。 また、Home モデルは、Floor モデルとのリレーションシップも定義します。これは、Home ツインが特定の Floor ツインに接続されていることを示すために使用できます。

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "contents": [
    {
      "@type": "Property",
      "name": "id",
      "schema": "string"     
    },    
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1"
    }
  ]
}

プロパティとテレメトリ

このセクションでは、DTDL モデルのプロパティテレメトリについて詳しく説明します。

プロパティの一部として表示される可能性があるフィールドの包括的な一覧については、DTDL v2 仕様の「プロパティ」を参照してください。テレメトリの一部として表示される可能性があるフィールドの包括的な一覧については、DTDL v2 仕様の「テレメトリ」を参照してください。

注意

プロパティの writable DTDL 属性は、Azure Digital Twins で現在サポートされていません。 これはモデルに追加できますが、Azure Digital Twins によって適用されることはありません。 詳細については、「Azure Digital Twins DTDL の実装の仕様」を参照してください。

プロパティとテレメトリの違い

Azure Digital Twins の DTDL のプロパティとテレメトリを概念的に区別するためのガイダンスを次に示します。

  • プロパティには、バッキング ストレージがあることが想定されています。これは、プロパティをいつでも読み取って、その値を取得できることを意味します。 プロパティが書き込み可能であれば、プロパティに値を格納することもできます。
  • テレメトリは、イベントのストリームに似たものであり、存続期間の短い一連のデータ メッセージです。 イベントのリッスンおよびその発生時に実行するアクションを設定していないと、後でイベントをトレースできません。 後でそこに戻って読み取ることはできません。
    • C# の用語では、テレメトリは C# イベントに似ています。
    • IoT の用語では、テレメトリは通常、デバイスによって送信される 1 つの測定値です。

テレメトリは、IoT デバイスで多く使用されます。多くのデバイスには、生成される測定値を格納する能力もその必要性もないためです。 代わりに、"テレメトリ" イベントのストリームとして送信されます。 この場合、テレメトリ フィールドの最新の値について、いつでもデバイスに対してクエリを実行できるわけではありません。 デバイスからのメッセージをリッスンし、メッセージが到着したときにアクションを実行する必要があります。

そのため、Azure Digital Twins でモデルを設計する際は、ほとんどの場合プロパティを使用して、ツインをモデル化することになると考えられます。 こうすることで、バッキング ストレージが得られ、データ フィールドの読み取りとクエリを行うことができます。

多くの場合、テレメトリとプロパティは連携して、デバイスからのデータのイングレスを処理します。 通常はイングレス関数を使用してデバイスからテレメトリまたはプロパティのイベントを読み取り、それに応じて Azure Digital Twins でプロパティを設定します。

Azure Digital Twins API からテレメトリ イベントを発行することもできます。 他のテレメトリと同様に、これは存続期間の短いイベントであり、リスナーによる処理が必要です。

スキーマ

DTDL によると、プロパティおよびテレメトリ属性のスキーマは、標準プリミティブ型の integerdoublestring、および boolean と、dateTimeduration などのその他の型にすることができます。

プリミティブ型のほか、プロパティおよびテレメトリ フィールドは、これらの複合型を含むことができます。

  • Object
  • Map
  • Enum
  • (テレメトリのみ) Array

また、セマンティック型にすることもできます。この型を使用すると、値に単位の注釈を付けることができます。

基本的なプロパティとテレメトリの例

DTDL モデルのプロパティの基本的な例を次に示します。 この例では、Home の ID プロパティを示しています。

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "contents": [
    {
      "@type": "Property",
      "name": "id",
      "schema": "string"     
    },    
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1"
    }
  ]
}

DTDL モデルのテレメトリ フィールドの基本的な例を次に示します。 この例では、センサーの温度テレメトリを示しています。

{
  "@id": "dtmi:com:adt:dtsample:sensor;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Sensor",
  "contents": [
    {
    "@type": "Telemetry",
    "name": "Temperature",
    "schema": "double"      
    },
    {
      "@type": "Property",
      "name": "humidity",
      "schema": "double"      
    }
  ]
}

複合 (オブジェクト) 型の例

プロパティとテレメトリは、Object 型などの複合型にすることができます。

次の例は、アドレスのプロパティを持つ Home モデルの別のバージョンを示しています。 address はオブジェクトであり、番地、市区町村、都道府県、および郵便番号の独自のフィールドを持っています。

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {
      "@type": "Property",
      "name": "address",
      "schema": {
        "@type": "Object",
        "fields": [
          {
            "name": "street",
            "schema": "string"
          },
          {
            "name": "city",
            "schema": "string"
          },
          {
            "name": "state",
            "schema": "string"
          },
          {
            "name": "zip",
            "schema": "string"
          }
        ]
      }
    },
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1",
      "properties": [
        {
          "@type": "Property",
          "name": "lastOccupied",
          "schema": "dateTime"
        }
      ]
    }
  ]
}

セマンティック型の例

セマンティック型を使用すると、値を単位付きで表現できます。 プロパティとテレメトリは、DTDL でサポートされているセマンティック型で表すことができます。 DTDL のセマンティック型とサポートされている値の詳細については、「DTDL v2 仕様のセマンティック型」に関する記事を参照してください。

次の例は、温度のセマンティック型テレメトリと湿度のセマンティック型プロパティを持つセンサー モデルを示しています。

{
  "@id": "dtmi:com:adt:dtsample:sensor;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Sensor",
  "contents": [
    {
      "@type": ["Telemetry", "Temperature"],
      "name": "temperature",
      "unit": "degreeFahrenheit",
      "schema": "double"      
    },
    {
      "@type": ["Property", "Humidity"],
      "name": "humidity",
      "unit": "gramPerCubicMetre",
      "schema": "double"        
    }
  ]
}

リレーションシップ

このセクションでは、DTDL モデルのリレーションシップについて詳しく説明します。

リレーションシップの一部として表示される可能性のあるフィールドの包括的な一覧については、DTDL v2 仕様の「リレーションシップ」を参照してください。

注意

リレーションシップの writableminMultiplicity、および maxMultiplicity DTDL 属性は、Azure Digital Twins で現時点ではサポートされていません。 これらはモデルに追加できますが、Azure Digital Twins によって適用されません。 詳細については、「Azure Digital Twins DTDL の実装の仕様」を参照してください。

基本的なリレーションシップの例

DTDL モデルのリレーションシップの基本的な例を次に示します。 この例では、Floor モデルへの接続を可能にする Home モデルのリレーションシップを示します。

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "contents": [
    {
      "@type": "Property",
      "name": "id",
      "schema": "string"     
    },    
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1"
    }
  ]
}

注意

リレーションシップについては、@id はオプションのフィールドです。 @id が指定されていない場合、デジタル ツイン インターフェイス プロセッサは 1 を割り当てます。

対象および対象外のリレーションシップ

リレーションシップは、ターゲットを指定するか、指定せずに定義することができます。 ターゲットは、リレーションシップが到達できるツインの種類を指定します。 たとえば、Home モデルが Floor ツインであるツインとのみ rel_has_floors リレーションシップを持つことができるように指定するターゲットを含めることができます。

場合によっては、特定のターゲットなしでリレーションシップを定義して、リレーションシップがさまざまな種類のツインに接続できるようにする必要がある場合があります。

ターゲットを持たない DTDL モデルのリレーションシップの例を次に示します。 この例では、リレーションシップは Room に含まれる可能性があるセンサーを定義するためのものであり、リレーションシップは任意の種類に接続できます。

{
  "@id": "dtmi:com:adt:dtsample:room;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Room",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {
      "@type": ["Property", "Humidity"],
      "name": "humidity",
      "unit": "gramPerCubicMetre",
      "schema": "double"
    },
    {
      "@type": "Component",
      "name": "thermostat",
      "schema": "dtmi:com:adt:dtsample:thermostat;1"
    },
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:room:rel_has_sensors;1",
      "name": "rel_has_sensors",
      "displayName": "Room has sensors"
    }
  ]
},

リレーションシップのプロパティ

DTDL を使用すると、リレーションシップに独自のプロパティを含めることもできます。 DTDL モデル内でリレーションシップを定義する際に、リレーションシップに独自の properties フィールドを含めることができます。このフィールドで、リレーションシップ固有の状態を記述するカスタム プロパティを定義できます。

次の例は、別のバージョンの Home モデルを示しています。rel_has_floors リレーションシップには、関連する Floor が最後に占有された時間を表すプロパティがあります。

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {
      "@type": "Property",
      "name": "address",
      "schema": {
        "@type": "Object",
        "fields": [
          {
            "name": "street",
            "schema": "string"
          },
          {
            "name": "city",
            "schema": "string"
          },
          {
            "name": "state",
            "schema": "string"
          },
          {
            "name": "zip",
            "schema": "string"
          }
        ]
      }
    },
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1",
      "properties": [
        {
          "@type": "Property",
          "name": "lastOccupied",
          "schema": "dateTime"
        }
      ]
    }
  ]
}

Components

このセクションでは、DTDL モデルのコンポーネントについて詳しく説明します。

コンポーネントの一部として表示される可能性のあるフィールドの包括的な一覧については、DTDL v2 仕様の「コンポーネント」を参照してください。

基本的なコンポーネントの例

DTDL モデルのコンポーネントの基本的な例を次に示します。 この例では、コンポーネントとしてサーモスタット モデルを使用する Room モデルを示します。

[
  {
    "@id": "dtmi:com:adt:dtsample:room;1",
    "@type": "Interface",
    "@context": "dtmi:dtdl:context;2",
    "displayName": "Room",
    "extends": "dtmi:com:adt:dtsample:core;1",
    "contents": [
      {
        "@type": ["Property", "Humidity"],
        "name": "humidity",
        "unit": "gramPerCubicMetre",
        "schema": "double"
      },
      {
        "@type": "Component",
        "name": "thermostat",
        "schema": "dtmi:com:adt:dtsample:thermostat;1"
      },
      {
        "@type": "Relationship",
        "@id": "dtmi:com:adt:dtsample:room:rel_has_sensors;1",
        "name": "rel_has_sensors",
        "displayName": "Room has sensors"
      }
    ]
  },
  {
    "@context": "dtmi:dtdl:context;2",
    "@id": "dtmi:com:adt:dtsample:thermostat;1",
    "@type": "Interface",
    "displayName": "thermostat",
    "contents": [
      {
        "@type": ["Property", "Temperature"],
        "name": "temperature",
        "unit": "degreeFahrenheit",
        "schema": "double"
      }
    ]
  }
]

このソリューション内の他のモデルにもサーモスタットが含まれている必要がある場合は、Room の場合と同様に、独自の定義でコンポーネントと同じサーモスタット モデルを参照することができます。

重要

コンポーネントの参照が見つかるようにするには、コンポーネント インターフェイス (上記の例ではサーモスタット) を、それを使用するすべてのインターフェイス (上の例では Room) と同じ配列で定義する必要があります。

モデルの継承

場合によっては、モデルをさらに特殊化したい場合があります。 たとえば、汎用的なモデル Room と、特殊化したバリアント ConferenceRoom および Gym を作成すると便利な場合があります。 特殊化を表現するため、DTDL では "継承" がサポートされています。 インターフェイスは、1 つ以上の他のインターフェイスから継承できます。 これを行うには、モデルに extends フィールドを追加します。

extends セクションは、インターフェイス名、またはインターフェイス名の配列です (拡張インターフェイスで複数の親モデルを継承できます)。 1 つの親は、複数の拡張インターフェイスの基本モデルとして機能できます。

次の例では、Home モデルを前の DTDL 例からより大きな「コア」モデルのサブタイプとして再イメージ化しています。 親モデル (Core) が先に定義され、次に extends を使用してその上に子モデル (Home) が構築されます。

{
    "@id": "dtmi:com:adt:dtsample:core;1",
    "@type": "Interface",
    "@context": "dtmi:dtdl:context;2",
    "displayName": "Core",
    "contents": [
        {
            "@type": "Property",
            "name": "id",
            "schema": "string"
        },
        {
            "@type": "Property",
            "name": "name",
            "schema": "string"
        }
    ]
}
{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {

この場合、Core は ID と名前を Home に提供します。 他のモデルでは、Core モデルを拡張してこれらのプロパティを取得することもできます。 同じ親インターフェイスを拡張する Room モデルを次に示します。

{
  "@id": "dtmi:com:adt:dtsample:room;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Room",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {

継承が適用されると、拡張インターフェイスは継承チェーン全体のすべてのプロパティを公開します。

拡張インターフェイスでは、親インターフェイスの定義は変更できません。定義の追加のみ行うことができます。 また、いずれかの親インターフェイスで既に定義されている機能を再定義することもできません (機能が同じになるように定義される場合でも)。 たとえば、親インターフェイスで double のプロパティ mass が定義されている場合、拡張インターフェイスに mass の宣言を含めることはできません (それが同様に double である場合でも)。

モデリングのベスト プラクティス

このセクションでは、モデリングに関するその他の考慮事項と推奨事項について説明します。

DTDL 業界標準オントロジを使用する

ソリューションが、(スマート ビルディング、スマート シティ、エネルギー グリッドなど) 特定の既存の業界に対するものである場合、モデルをゼロから設計するのではなく、業界の既存のモデル セットから始めることを検討してください。 Microsoft は、各分野の専門家と提携して業界標準に基づく DTDL モデル セットを作成することで、再発明を最小限に抑え、業界ソリューション全体で一貫性とシンプルさが促進されるようにしました。 これらのオントロジの詳細 (使用方法や現在提供されているオントロジなど) については、「オントロジとは」を参照してください。

クエリの影響を考慮する

環境内のエンティティを反映するようにモデルを設計するときには、先を考えること、および設計に対するクエリの影響を考慮することが有益です。 グラフのトラバーサルから大きな結果セットが生成されない方法で、プロパティを設計することができます。 また、1 つのクエリで回答される必要があるリレーションシップを、単一レベルのリレーションシップとしてモデル化することもできます。

モデルを検証する

ヒント

モデルの作成後、モデルは、Azure Digital Twins インスタンスにアップロードする前に、オフラインで検証することが推奨されます。

言語に依存しない DTDL 検証ツールのサンプルがあります。これにより、モデル ドキュメントを検証して、インスタンスにアップロードする前に DTDL が正しいことを確認できます。

DTDL 検証ツールのサンプルは、NuGet でクライアント側ライブラリとして提供されている .NET DTDL パーサー ライブラリに基づいて構築されています。Microsoft.Azure.DigitalTwins.Parser. また、このライブラリを直接使用し、自分独自の検証ソリューションを設計することもできます。

バージョン 4.0.8 のパーサー ライブラリは、Azure Digital Twins との互換性のために現在推奨されているバージョンです。

使用例を含む検証ツールのサンプルとパーサー ライブラリの詳細については、モデルの解析と検証に関するページを参照してください。

モデリング ツール

モデルとオントロジをさらに簡単に処理できるように、いくつかのサンプルが用意されています。 それらは、こちらのリポジトリ (Digital Twins Definition Language (DTDL) のツール) にあります。

このセクションでは、サンプルの現在のセットについて詳しく説明します。

モデルのアップローダー

モデルの作成、拡張、または選択が完了したら、それらをお使いのソリューションで使用できるように、Azure Digital Twins インスタンスにアップロードできます。 これは、Azure Digital Twins の API と SDKaz dt の CLI コマンド、または Azure Digital Twins Explorer を使用して実行できます。

ただし、アップロードするモデルが多数ある場合 (またはモデルに多数の相互依存性があり、それにより個々のアップロードの順序付けが複雑になる場合)、Azure Digital Twins のモデル アップローダーのサンプルを使用して、多数のモデルを一度にアップロードできます。 サンプルで示されている手順に従って、このプロジェクトを構成し、独自のインスタンスにモデルをアップロードするために使用します。

モデルのビジュアライザー

Azure Digital Twins インスタンスにモデルをアップロードした後、Azure Digital Twins Model Visualizer を使用して、Azure Digital Twins インスタンスでモデルを表示できます。これには、継承やモデルのリレーションシップも含まれます。 このサンプルは、現在ドラフト状態です。 弊社は、デジタル ツインの開発コミュニティに対して、このサンプルを拡張して寄与するように奨励しています。

次のステップ