Узнайте о моделях двойников и их определении в Azure Digital Twins

2025-05-21

Одной из ключевых особенностей Azure Digital Twins является возможность задавать собственный словарь и создавать граф цифровых двойников в самоопределяемых терминах вашего бизнеса. Эта возможность предоставляется с помощью пользовательских моделей. Вы можете рассматривать модели как существительные в описании вашего мира. Модели Azure Digital Twins представлены в языке определения цифрового двойника на основе JSON-LD (DTDL).

Модель похожа на класс на объектно-ориентированном языке программирования, определяя фигуру данных для одной конкретной концепции в реальной рабочей среде. Модели имеют имена (например, Room или TemperatureSensor) и содержат такие элементы, как свойства, компоненты и связи, описывающие этот тип сущности в вашей среде. Позже вы будете использовать эти модели для создания цифровых двойников , представляющих определенные сущности, соответствующие этому описанию типа.

Язык определения цифровых двойников (DTDL) для моделей

Модели для Azure Digital Twins определяются с помощью языка определения Цифровых двойников (DTDL).

Полное описание языка для DTDL версии 3 можно просмотреть в GitHub: описание языка DTDL версии 3. На этой странице содержатся справочные сведения о DTDL и примеры, которые помогут вам приступить к написанию собственных моделей DTDL.

DTDL основан на JSON-LD и не зависит от языка программирования. DTDL не является эксклюзивным для Azure Digital Twins. Он также используется для представления данных устройств в других службах Интернета вещей, таких как IoT Plug and Play.

Остальная часть этой статьи содержит сведения о том, как язык используется в Azure Digital Twins.

Поддерживаемые версии DTDL

Azure Digital Twins поддерживает DTDL версии 2 и 3 (сокращено в документации до версии 2 и 3 соответственно). V3 — это рекомендуемый вариант для моделирования в Azure Digital Twins на основе расширенных возможностей, в том числе:

Ослабление версии DTMI
Поддержка массива свойств
Увеличение ограничений для наследования моделей
Расширения функций
- Возможность декорировать пользовательские схемы интерфейса с семантическими типами (предоставляется расширением "Количественные типы")

Где эти функции рассматриваются в документации, они сопровождаются примечанием о том, что они доступны только в DTDL версии 3. Полный список различий между DTDL версии 2 и v3 см. в описании языка DTDL версии 3: изменения в версии 2.

Azure Digital Twins также поддерживает использование сочетания моделей версии 2 и версии 3 в одном экземпляре. При использовании моделей обеих версий следует учитывать следующие ограничения:

Интерфейс версии 2 не может расширять интерфейс версии 3 или иметь компонент с интерфейсом версии 3 в качестве своей схемы.
И наоборот, интерфейс версии 3 может расширить интерфейс версии 2, а интерфейс версии 3 может иметь компонент с интерфейсом версии 2 в качестве схемы.
Связи могут указывать в любом направлении от источника модели версии 2 до целевого объекта модели версии 3 или наоборот от источника модели версии 3 до целевого объекта модели версии 2.

Вы также можете перенести существующие модели версии 2 в версию 3. Инструкции по этому использованию см. в разделе "Преобразование моделей версии 2 в версию 3".

Замечание

В настоящее время Azure Digital Twins Explorer полностью поддерживает модели DTDL версии 2 и поддерживает ограниченные функциональные возможности для моделей DTDL версии 3.

Модели DTDL версии 3 можно просматривать на панели "Модели", а двойники, созданные с помощью моделей DTDL версии 3, можно просматривать и изменять (включая двойники со свойствами массива). Однако модели DTDL версии 3 не отображаются на панели "Граф модели", и их нельзя импортировать с помощью Azure Digital Twins Explorer. Чтобы импортировать модели DTDL версии 3 в экземпляр, используйте другой интерфейс разработчика, например API и пакеты SDK или Azure CLI.

Общие сведения о модели

Модели типов двойников можно писать в любом текстовом редакторе. Язык DTDL следует синтаксису JSON, поэтому следует хранить модели с расширением.json. Использование расширения JSON позволит многим текстовым редакторам программирования обеспечить простую проверку синтаксиса и выделение документов DTDL. Существует также расширение DTDL для Visual Studio Code.

Ниже приведены поля в интерфейсе модели:

Поле	Описание
`@id`	Идентификатор модели цифрового двойника (DTMI) для модели в формате`dtmi:<domain>:<unique-model-identifier>;<model-version-number>`. В DTDL v3 номер версии может быть опущен или структурирован как состоящий из двух частей номер версии (`<major>.<minor>`).
`@type`	Определяет тип описываемой информации. Тип интерфейса — `Interface`.
`@context`	Задает контекст документа JSON. Модели должны использовать `dtmi:dtdl:context;2` для DTDL v2 или `dtmi:dtdl:context;3` для DTDL v3. Модели DTDL версии 3 также могут называть дополнительные расширения функций в этом поле.
`displayName`	[необязательно] Предоставляет возможность определить понятное имя модели. Если вы не используете это поле, модель будет использовать его полное значение DTMI.
`contents`	Все оставшиеся данные интерфейса помещаются здесь в виде массива определений атрибутов. Каждый атрибут должен предоставить `@type` (`Property`, `Relationship`или `Component`) для идентификации типа сведений о интерфейсе, которые он описывает, а затем набор свойств, определяющих фактический атрибут. В следующем разделе подробно описаны атрибуты модели .

Ниже приведен пример базовой модели DTDL. Эта модель описывает Дом с одним свойством для идентификатора. Модель Home также определяет связь с моделью Floor, которая может использоваться для обозначения того, что дом-двойник связан с определёнными двойниками Floor.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;3",
  "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, которые поддерживаются в Azure Digital Twins. Интерфейс модели DTDL, используемый для Azure Digital Twins, может содержать ноль, один или несколько из следующих полей:

Свойство — это поля данных, представляющие состояние сущности (например, свойства во многих объектно-ориентированных языках программирования). Свойства имеют резервное хранилище и могут быть прочитаны в любое время. Дополнительные сведения см. в разделе "Свойства " ниже.
Связь — отношения позволяют представить, как цифровой двойник может быть связан с другими цифровыми двойниками. Связи могут представлять различные семантические значения, такие как contains ("пол содержит комнату"), cools ("HVAC охлаждает комнату"), isBilledTo ("компрессор оплачивается пользователем") и т. д. Связи позволяют решению предоставлять граф взаимосвязанных сущностей. Отношения также могут иметь собственные свойства. Дополнительные сведения см. в разделе "Связи " ниже.
Компонент — компоненты позволяют создавать интерфейс модели как сборку других интерфейсов, если требуется. Пример компонента — интерфейс frontCamera (и другой интерфейс компонента backCamera), используемый при определении модели для телефона. Сначала определите интерфейс для фронтальной камеры, как будто она была собственной моделью, а затем используйте его при определении телефона.

Используйте компонент, чтобы описать неотъемлемую часть вашего решения, которая не требует отдельной идентификации и не нуждается в создании, удалении или перестановке в графе сопоставлений самостоятельно. Если сущности должны иметь независимое существование в графе двойников, представляют их в виде отдельных цифровых двойников различных моделей, подключенных связями.

Подсказка

Компоненты также можно использовать для организации, чтобы группировать наборы связанных свойств в интерфейсе модели. В этой ситуации можно представить каждый компонент как пространство имен или папку внутри интерфейса.

Дополнительные сведения см. в разделе "Компоненты " ниже.

Описание языка DTDL версии 3 также определяет команды и телеметрию, но ни одно из них не используется в Azure Digital Twins. Команды не поддерживаются, а телеметрия, хотя она разрешена в определениях моделей, не имеет уникального варианта использования в модели azure Digital Twins. Вместо того чтобы использовать телеметрию DTDL, следует использовать свойства DTDL для хранения информации о состоянии двойника.

Замечание

Хотя нет необходимости определять поля телеметрии в моделях DTDL для хранения входящих данных устройства, Azure Digital Twins может выдавать события в виде телеметрии с помощью API SendTelemetry. Это активирует событие телеметрии Digital Twin Message, которое может быть получено обработчиком событий для выполнения действий с другими двойниками-дублерами или инициирования подчиненных служб.

Свойства

В этом разделе подробно описаны свойства моделей DTDL.

Подробные сведения о полях, которые могут отображаться как часть свойства, см. в описании языка DTDL версии 3.

Замечание

Атрибут writable DTDL для свойств в настоящее время не поддерживается в Azure Digital Twins. Его можно добавить в модель, но Azure Digital Twins не будет применять его. Дополнительные сведения см. в заметках DTDL для конкретной службы.

Схема

В соответствии с DTDL схема атрибутов свойств может быть стандартным примитивным типом ,integerdoublestring и другими booleanтипами, такими как dateTime и duration.

Помимо примитивных типов поля свойств могут иметь следующие сложные типы:

Object
Map
Enum
Array, только в DTDL версии 3. Array тип свойств не поддерживается в DTDL версии 2.

Они также могут быть семантическими типами, которые позволяют аннотировать значения с единицами. В DTDL версии 2 семантические типы поддерживаются в собственном коде; в DTDL версии 3 их можно включить с расширением компонента.

Пример базового свойства

Ниже приведен базовый пример свойства модели DTDL. В этом примере показано свойство ID дома.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;3",
  "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"
    }
  ]
}

Пример типа сложного объекта

Свойства могут быть сложными типами, включая Object тип.

В следующем примере показана другая версия модели Home с свойством адреса. address — это объект, с собственными полями для улицы, города, штата и zip.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;3",
  "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 версии 2

Семантические типы предназначены для выражения значения с единицей. Свойства Azure Digital Twins могут использовать любой из семантических типов, поддерживаемых DTDL.

В DTDL версии 2 семантические типы поддерживаются в собственном коде. Дополнительные сведения о семантических типах в DTDL версии 2 см. в разделе " Семантические типы" в описании языка DTDL версии 2. Дополнительные сведения о семантических типах в DTDL версии 3 см. в расширении функции "Количественные типы DTDL версии 3".

В следующем примере показана модель датчика DTDL версии 2 с свойствами семантического типа для влажности и температуры.

{
  "@id": "dtmi:com:adt:dtsample:v2sensor;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Sensor (v2 model)",
  "contents": [
    {
      "@type": ["Property", "Temperature"],
      "name": "Temperature",
      "schema": "double",
      "unit": "degreeFahrenheit"    
    },
    {
      "@type": ["Property", "Humidity"],
      "name": "Humidity",
      "schema": "double",
      "unit": "gramPerCubicMetre" 
    }
  ]
}

Это важно

Свойство должно быть первым элементом массива @type , за которым следует семантический тип. В противном случае поле может не отображаться в обозревателе Azure Digital Twins.

Отношения

В этом разделе подробно описаны связи в моделях DTDL.

Полный список полей, которые могут отображаться в рамках связи, см. в разделе "Связь" в описании языка DTDL версии 3.

Замечание

Атрибуты DTDL writable, minMultiplicity и maxMultiplicity для связей в настоящее время не поддерживаются в Azure Digital Twins. Их можно добавить в модель, но Azure Digital Twins не будет применять их. Дополнительные сведения см. в заметках DTDL для конкретной службы.

Пример базовых связей

Ниже приведен базовый пример связи для модели DTDL. В этом примере показана взаимосвязь в модели Home, которая позволяет подключаться к модели Floor.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;3",
  "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 не указано, процессор интерфейса цифрового двойника назначит свой.

Целевые и нецелевые отношения

Связи можно определить с целью или без нее. Целевой объект указывает, какие типы двойников могут достичь связи. Например, можно задать целевое указание, чтобы уточнить, что модель Home может иметь rel_has_floors связь только с двойниками, которые являются двойниками этажа.

Иногда может потребоваться установить связь без конкретной цели, чтобы связь могла связываться с множеством различных типов двойников.

Ниже приведен пример связи для модели DTDL, которая не имеет целевого объекта. В этом примере отношение служит для определения того, какие датчики могут быть в комнате, и это отношение может связывать любой тип.

{
  "@id": "dtmi:com:adt:dtsample:room;1",
  "@type": "Interface",
  "@context": [
    "dtmi:dtdl:context;3",
    "dtmi:dtdl:extension:quantitativeTypes;1"
  ],
  "displayName": "Room",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {
      "@type": ["Property", "Humidity"],
      "name": "humidity",
      "schema": "double",
      "unit": "gramPerCubicMetre"
    },
    {
      "@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 поле, в котором можно определить пользовательские свойства для описания состояния конкретной связи.

В следующем примере показана другая версия домашней модели, где rel_has_floors отношение имеет свойство, представляющее, когда связанный этаж был последним занят.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;3",
  "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 версии 3.

Базовый пример компонента

Ниже приведен базовый пример компонента в модели DTDL. В этом примере показана модель комнаты, которая использует модель термостата в качестве компонента.

[
  {
    "@id": "dtmi:com:adt:dtsample:room;1",
    "@type": "Interface",
    "@context": [
      "dtmi:dtdl:context;3",
      "dtmi:dtdl:extension:quantitativeTypes;1"
    ],
    "displayName": "Room",
    "extends": "dtmi:com:adt:dtsample:core;1",
    "contents": [
      {
        "@type": ["Property", "Humidity"],
        "name": "humidity",
        "schema": "double",
        "unit": "gramPerCubicMetre"
      },
      {
        "@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;3",
      "dtmi:dtdl:extension:quantitativeTypes;1"
    ],
    "@id": "dtmi:com:adt:dtsample:thermostat;1",
    "@type": "Interface",
    "displayName": "thermostat",
    "contents": [
      {
        "@type": ["Property", "Temperature"],
        "name": "temperature",
        "schema": "double",
        "unit": "degreeFahrenheit"
      }
    ]
  }
]

Если другим моделям в этом решении также требуется термостат, они могут ссылаться на ту же модель термостата в качестве компонента в своих собственных определениях, так же как это делает Комната.

Это важно

Интерфейс компонента (термостат в приведенном выше примере) должен быть определен в том же массиве, что и все интерфейсы, использующие его (Room в приведенном выше примере), чтобы найти ссылку на компонент.

Наследование модели

Иногда вам может потребоваться дальнейшая специализация модели. Например, может быть полезно иметь универсальную модель Комната, а также специализированные варианты Конференц-Зал и Тренажерный Зал. Для выражения специализации DTDL поддерживает наследование. Интерфейсы могут наследоваться от одного или нескольких других интерфейсов. Это можно сделать, добавив extends поле в модель.

Раздел extends — это имя интерфейса или массив имен интерфейсов (что позволяет расширению интерфейса наследовать от нескольких родительских моделей). Один родитель может служить базовой моделью для нескольких расширяющих интерфейсов.

Замечание

В DTDL версии 2 каждый extends может иметь в списке не более двух интерфейсов. В DTDL версии 3 нет ограничений на количество непосредственных значений для extends.

В DTDL версии 2 и v3 общее ограничение глубины иерархии extends равно 10.

Следующий пример повторно представляет модель Home из предыдущего примера DTDL в качестве подтипа более крупной "основной" модели. Родительская модель (Core) определяется сначала, а затем дочерняя модель (Главная) строится на ней с помощью extends.

{
    "@id": "dtmi:com:adt:dtsample:core;1",
    "@type": "Interface",
    "@context": "dtmi:dtdl:context;3",
    "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;3",
  "displayName": "Home",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {

В этом случае Core вносит идентификатор и имя в Home. Другие модели также могут расширить базовую модель, чтобы получить эти свойства. Ниже приведена модель комнаты, расширяющая тот же родительский интерфейс:

{
  "@id": "dtmi:com:adt:dtsample:room;1",
  "@type": "Interface",
  "@context": [
    "dtmi:dtdl:context;3",
    "dtmi:dtdl:extension:quantitativeTypes;1"
  ],
  "displayName": "Room",
  "extends": "dtmi:com:adt:dtsample:core;1",

После применения наследования интерфейс расширения предоставляет все свойства из всей цепочки наследования.

Расширяющий интерфейс не может изменять какие-либо определения родительских интерфейсов; он может добавляться только к ним. Он также не может переопределить возможность, уже определенную в любом из родительских интерфейсов (даже если эти возможности определены для того же значения). Например, если родительский интерфейс определяет double свойствоmass, то расширяющий интерфейс не может содержать объявление mass свойства, даже если оно также является double.

Расширения компонентов DTDL версии 3

DTDL v3 позволяет языковым расширениям, определяющим дополнительные классы метамоделей, которые можно использовать для создания более сложных моделей. В этом разделе описаны классы расширений функций , которые можно использовать для добавления неядерных функций в модели DTDL версии 3.

Каждое расширение функции определяется его описательом контекста, который является уникальным значением идентификатора модели цифрового двойника (DTMI ). Чтобы включить расширение функции в модели, добавьте описатель контекста расширения в поле модели @context (наряду с общим описателем контекста DTDL dtmi:dtdl:context;3). В одну модель можно добавить несколько расширений компонентов.

Ниже приведен пример того, как это @context поле может выглядеть с расширениями функций. Следующий фрагмент состоит из модели, которая использует расширение "Количественные типы" и расширение "Заметка".

  "@context": [
      "dtmi:dtdl:context;3",
      "dtmi:dtdl:extension:quantitativeTypes;1",
      "dtmi:dtdl:extension:annotation;1"
  ]

После того как вы добавите расширение функции в модель, у вас будет доступ к типам дополнений этого расширения внутри модели. Вы можете добавить дополнительные типы в поле @type элемента DTDL, чтобы предоставить элементу дополнительные возможности. Тип adjunct может добавлять дополнительные свойства в элемент.

Например, вот фрагмент модели, использующий расширение Аннотации. Это расширение имеет тип добавочный, который ValueAnnotation добавляется в приведенном ниже примере в элемент свойств. Добавление дополнения этого типа к элементу свойства позволяет элементу иметь дополнительное annotates поле, которое используется для указания другого свойства, аннотированного этим элементом.

{
  "@type": [ "Property", "ValueAnnotation" ],
  "name": "currentTempAccuracy",
  "annotates": "currentTemp",
  "schema": "double"
  },

В остальной части этого раздела подробно объясняется расширение аннотации и другие расширения функций DTDL версии 3.

Расширение аннотации

Расширение Заметки используется для добавления пользовательских метаданных в элемент свойства в модели DTDL версии 3. Его описатель контекста имеет значение dtmi:dtdl:extension:annotation;1.

Это расширение включает тип дополнения ValueAnnotation, который можно добавить в элемент свойства DTDL. Тип ValueAnnotation добавляет одно поле в элемент, annotatesкоторый позволяет назвать другое свойство, аннотированное текущим элементом.

Дополнительные сведения и примеры этого расширения см. в Описании языка версии 3 DTDL.

Расширение историзации

Расширение historization используется для обозначения свойства в модели DTDL версии 3 как то, что должно быть историзовано (т. е. историческая последовательность его значений должна быть записана вместе со временем, в котором изменяются значения). Его описатель контекста имеет значение dtmi:dtdl:extension:historization;1.

Это расширение включает в себя тип дополнения Historized, который можно добавить как сопутствующий тип к элементу свойства DTDL, чтобы указать, что служба должна сохранять исторические значения элемента и делать их доступными для запросов и аналитики. Тип Historized адъюнкт не добавляет поля в элемент.

Дополнительные сведения и примеры расширения историзации см. в разделе «Описание языка DTDL версии 3».

Переопределение расширения

Расширение переопределения используется для замены свойства в модели DTDL третьей версии значением экземпляра. Он используется в сочетании с расширением аннотации, а его контекстный указатель — dtmi:dtdl:extension:overriding;1.

Это расширение включает тип Override adjunct, который можно добавить в свойство DTDL, также совместно типизированное с ValueAnnotation (из расширения заметки). Тип Override добавляет одно поле в элемент overrides, что позволяет указать имя поля в аннотированном элементе для его переопределения значением текущего элемента.

Дополнительные сведения и примеры этого расширения см. в разделе "Переопределение расширения" в описании языка DTDL версии 3.

Расширение QuantitativeTypes

Расширение QuantitativeTypes используется для включения семантических типов, типов единиц и единиц в модели DTDL версии 3. Его описатель контекста имеет значение dtmi:dtdl:extension:quantitativeTypes;1.

Это расширение позволяет использовать многие семантические типы в качестве дополнительных типов, которые можно добавить в CommandRequest, Field, MapValue или свойство в DTDL версии 3. Семантические типы добавляют одно поле в элемент, который принимает допустимую единицу, unitсоответствующую семантическому типу.

Дополнительные сведения о расширении, включая примеры и полный список поддерживаемых семантических типов и единиц, см. в расширении QuantitativeTypes в описании языка DTDL версии 3.

Заметки по 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. Причиной этого требования является то, что API модели Azure Digital Twins могут получать объекты JSON, представляющие интерфейс или массив интерфейсов. В результате другие типы элементов DTDL не допускаются на верхнем уровне.
DTDL для Azure Digital Twins не должен определять какие-либо команды.
Azure Digital Twins допускает только один уровень вложения компонентов, что означает, что интерфейс, используемый в качестве компонента, не может иметь каких-либо компонентов.
Интерфейсы не могут быть определены встроенными в других интерфейсах DTDL; они должны быть определены как отдельные сущности верхнего уровня с собственными идентификаторами. Затем, когда другой интерфейс хочет включить этот интерфейс в качестве компонента или через наследование, он может ссылаться на его идентификатор.

Средства моделирования и рекомендации

В этом разделе описываются дополнительные рекомендации и рекомендации по моделированию.

Использование существующих отраслевых онтологий

Онтология — это набор моделей, которые комплексно описывают данный домен, например производство, строительные структуры, системы Интернета вещей, интеллектуальные города, энергетические сетки, веб-содержимое и многое другое.

Если ваше решение предназначено для определенной отрасли, которая использует любой стандарт моделирования, рассмотрите возможность начать с предварительно существующего набора моделей, предназначенных для вашей отрасли, вместо разработки моделей с нуля. Корпорация Майкрософт сотрудничала с экспертами по домену, чтобы создать модель DTDL на основе отраслевых стандартов, чтобы свести к минимуму повторное развертывание и поощрять согласованность и простоту в отраслевых решениях. Дополнительные сведения об этих онтологиях, в том числе о том, как их использовать и какие онтологии доступны сейчас, в разделе "Что такое онтология?".

Рассмотрим последствия запроса

При проектировании моделей для отражения сущностей в вашей среде может быть полезно изучить последствия запроса для разработки. Вы можете спроектировать свойства таким образом, чтобы избежать больших результирующих наборов, получаемых при обходе графа. Также может потребоваться моделировать такие связи, для которых нужно получить ответ с помощью одного запроса, как связи одного уровня.

Проверка моделей

После создания модели рекомендуется проверить модели в автономном режиме перед их отправкой в экземпляр Azure Digital Twins.

Чтобы помочь вам проверить модели, клиентская библиотека анализа DTDL на стороне клиента .NET предоставляется в NuGet: DTDLParser. Библиотеку синтаксического анализа можно использовать непосредственно в коде C#. Вы также можете просмотреть пример использования средства синтаксического анализа в DTDLParserResolveSample в GitHub.

Отправка и удаление моделей в массовом режиме

После завершения создания, расширения или выбора моделей необходимо передать их в экземпляр Azure Digital Twins, чтобы сделать их доступными для использования в решении.

Вы можете отправить множество моделей в одном вызове API с помощью API импорта заданий. API может одновременно принимать до предельного количества моделей в экземпляре Azure Digital Twins, и при необходимости автоматически переупорядочивает модели для устранения зависимостей между ними. Подробные инструкции и примеры, использующие этот API, см. в инструкциях массового импорта для моделей.

Альтернативой API импорта заданий является пример средства отправки моделей, который использует отдельные API модели для отправки нескольких файлов модели одновременно. В примере также реализовано автоматическое переупорядочивание для разрешения зависимостей моделей. В настоящее время он работает только с версией 2 DTDL.

Если вам нужно удалить все модели в экземпляре Azure Digital Twins одновременно, можно использовать пример удаления моделей. Это проект, содержащий рекурсивную логику для обработки зависимостей модели через процесс удаления. В настоящее время он работает только с версией 2 DTDL.

Или, если вы хотите очистить данные в экземпляре, удалив все модели вместе со всеми двойниками и связями, можно использовать API удаления заданий.

Визуализация моделей

После отправки моделей в экземпляр Azure Digital Twins можно использовать Azure Digital Twins Explorer для их просмотра. Обозреватель содержит список всех моделей в экземпляре, а также граф модели , иллюстрирующий связь между ними, включая все связи наследования и модели.

Замечание

Ниже приведен пример того, как выглядит граф модели:

Дополнительные сведения о модели в Azure Digital Twins Explorer см. в статье "Обзор моделей" и "Граф моделей".

Дальнейшие шаги

Узнайте о создании моделей на основе отраслевых онтологий: что такое онтология?
Более подробное руководство по управлению моделями с помощью операций API: управление моделями DTDL
Узнайте, как модели используются для создания цифровых двойников: цифровые двойники и граф двойников

Поделиться через

Узнайте о моделях двойников и их определении в Azure Digital Twins

Язык определения цифровых двойников (DTDL) для моделей

Поддерживаемые версии DTDL

Общие сведения о модели

Атрибуты модели

Свойства

Схема

Пример базового свойства

Пример типа сложного объекта

Пример семантического типа DTDL версии 2

Отношения

Пример базовых связей

Целевые и нецелевые отношения

Свойства связей

Компоненты

Базовый пример компонента

Наследование модели

Расширения компонентов DTDL версии 3

Расширение аннотации

Расширение историзации

Переопределение расширения

Расширение QuantitativeTypes

Заметки по DTDL, специфичные для службы

Средства моделирования и рекомендации

Использование существующих отраслевых онтологий

Рассмотрим последствия запроса

Проверка моделей

Отправка и удаление моделей в массовом режиме

Визуализация моделей

Дальнейшие шаги

Обратная связь

Дополнительные ресурсы