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

[アーティクル]
02/28/2023

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)」のバージョン 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 で言語を使用する方法について説明します。

モデルの概要

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

モデルインターフェイス内のフィールドを次に示します。

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

基本的な 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"
    }
  ]
}

モデル属性

モデルに関する主な情報は、モデルインターフェイスの contents セクション内で定義する属性によって提供されます。 DTDL で使用できる属性を次に示します。 DTDL モデルのインターフェイスには、以下の各フィールドをゼロ個、1 個、または複数個、含めることができます。

Property - プロパティは、エンティティの状態を表すデータフィールドです (多くのオブジェクト指向プログラミング言語のプロパティと同様)。プロパティはバッキングストレージを備えていて、いつでも読み取ることができます。詳細については、以下の「プロパティとテレメトリ」を参照してください。
Telemetry - テレメトリフィールドは測定値またはイベントを表し、多くの場合、デバイスのセンサーの読み取りを説明するために使用されます。プロパティとは異なり、テレメトリはデジタルツインに格納されません。これは、発生時に処理される必要がある一連の期限付きデータイベントです。詳細については、以下の「プロパティとテレメトリ」を参照してください。
Relationship - リレーションシップを使用すると、あるデジタルツインと他のデジタルツインの関係性を表すことができます。リレーションシップは、さまざまなセマンティックな意味を表す可能性があります。たとえば、contains ("フロアに部屋が含まれる")、cools ("hvac によって部屋が冷やされる")、isBilledTo ("コンプレッサーがユーザーに請求される") などです。リレーションシップにより、ソリューションは相互に関連するエンティティのグラフを提供できます。リレーションシップには、独自のプロパティを含めることもできます。詳細については、以下の「リレーションシップ」を参照してください。
Component - コンポーネントを使用すると、必要に応じてモデルインターフェイスを他のインターフェイスの組み合わせとして構築できます。コンポーネントの例として、"電話" のモデルの定義に使用される frontCamera インターフェイス (およびもう 1 つのコンポーネントインターフェイスである backCamera) があります。まず、frontCamera のインターフェイスを独自のモデルであるかのように定義します。その後、Phone を定義するときに、それを参照します。

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

ヒント

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

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

注意

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

プロパティとテレメトリ

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

プロパティの一部として表示される可能性のあるフィールドに関する包括的な情報については、DTDL V2 リファレンスのプロパティに関するページを参照してください。テレメトリの一部として表示される可能性のあるフィールドに関する包括的な情報については、DTDL V2 リファレンスのテレメトリに関するページを参照してください。

注意

プロパティの writable DTDL 属性は、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 によると、プロパティおよびテレメトリ属性のスキーマは、標準プリミティブ型の integer、double、string、および boolean と、dateTime、duration などのその他の型にすることができます。

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

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"        
    }
  ]
}

Note

"Property" または "Telemetry" は、@type 配列の最初の要素でなければならず、その後にセマンティック型が続きます。そうしないと、Azure Digital Twins Explorer にフィールドが表示されない可能性があります。

リレーションシップ

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

リレーションシップの一部として表示される可能性のあるフィールドの包括的な一覧については、DTDL V2 リファレンスのリレーションシップに関するページを参照してください。

Note

リレーションシップの writable、minMultiplicity、および maxMultiplicity DTDL 属性は、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 に関する注意事項

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

DTDL コマンド
プロパティまたはリレーションシップの writable 属性。この属性は DTDL 仕様に従って設定できますが、Azure Digital Twins では使用しません。代わりに、これらの属性は常に、Azure Digital Twins サービスに対する一般的な書き込みアクセス許可を持つ外部クライアントによって書き込み可能として扱われます。
リレーションシップの minMultiplicity と maxMultiplicity プロパティ。これらの属性は 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 業界標準オントロジを使用する

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

クエリの影響を考慮する

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

モデルを検証する

ヒント

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

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

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

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

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

モデルを一括でアップロードおよび削除する

モデルの作成、拡張、または選択が完了したら、それらをお使いのソリューションで使用できるように、Azure Digital Twins インスタンスにアップロードする必要があります。

Jobs API を使用して、1 つの API 呼び出しで多数のモデルをアップロードできます。 API は、インスタンス内のモデルの数に対する Azure Digital Twins の制限まで同時に受け入れることができ、必要に応じてモデルの順序を自動的に変更して、それらの間の依存関係を解決できます。この API を使用する詳細な手順と例については、「モデルの一括インポート手順」を参照してください。

Jobs API の代わりに、モデルアップローダーサンプルがあります。このサンプルでは、個々のモデル API を使用して複数のモデルファイルを一度にアップロードします。このサンプルでは、モデルの依存関係を解決するための自動並べ替えも実装されています。

Azure Digital Twins インスタンス内のすべてのモデルを一度に削除する必要がある場合は、 Model deleter サンプルを使用できます。これは、削除プロセスを通じてモデルの依存関係を処理するための再帰的なロジックを含むプロジェクトです。

モデルの視覚化

Azure Digital Twins インスタンスにモデルをアップロードすると、 Azure Digital Twins Explorer を使用してモデルを表示できるようになります。エクスプローラーには、インスタンス内のすべてのモデルの一覧と、継承やモデルのリレーションシップなど、相互の関係を示す モデルグラフ が含まれています。

モデルグラフがどのように見えるかの例を次に示します。

Azure Digital Twins Explorer でのモデルエクスペリエンスの詳細については、「モデルとモデルグラフの参照」を参照してください。

次のステップ

業界標準のオントロジに基づいてモデルを作成する方法について学習してください。オントロジとは?
API 操作によるモデルの管理について詳しく学習してください。DTDL モデルを管理する
「デジタルツインとツイングラフ」でモデルを使用してデジタルツインを作成する方法について確認する

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

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

モデルの概要

モデル属性

プロパティとテレメトリ

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

スキーマ

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

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

セマンティック型の例

リレーションシップ

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

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

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

Components

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

モデルの継承

サービス固有の DTDL に関する注意事項

モデリングツールとベストプラクティス

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

クエリの影響を考慮する

モデルを検証する

モデルを一括でアップロードおよび削除する

モデルの視覚化

次のステップ

その他のリソース

その他のリソース

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

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

モデルの概要

モデル属性

プロパティとテレメトリ

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

スキーマ

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

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

セマンティック型の例

リレーションシップ

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

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

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

Components

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

モデルの継承

サービス固有の DTDL に関する注意事項

モデリング ツールとベスト プラクティス

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

クエリの影響を考慮する

モデルを検証する

モデルを一括でアップロードおよび削除する

モデルの視覚化

次のステップ

その他のリソース

その他のリソース

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

モデリングツールとベストプラクティス