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

Статья
01/04/2024

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

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

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

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

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

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

Далее в этой статье вы узнаете, как используется этот язык в 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 Обозреватель полностью поддерживает модели DTDL версии 2 и поддерживает ограниченные функциональные возможности для моделей DTDL версии 3. В Обозреватель Azure Digital Twins модели DTDL версии 3 можно просматривать на панели "Модели", а двойники, созданные с помощью моделей DTDL версии 3, можно просматривать и изменять (включая модели с свойствами массива). Однако модели DTDL версии 3 не отображаются на панели "Граф моделей", и их нельзя импортировать с помощью Azure Digital Twins Обозреватель. Чтобы импортировать модели DTDL версии 3 в экземпляр, используйте другой интерфейс разработчика, например API и пакеты SDK или Azure CLI.

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

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

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

Поле	Description
`@id`	Идентификатор модели цифрового двойника (DTMI) для модели в формате `dtmi:<domain>:<unique-model-identifier>;<model-version-number>`. В DTDL версии 3 номер версии может быть опущен или структурирован как номер версии с двумя частью (`<major>.<minor>`).
`@type`	Определяет вид описываемой информации. Для интерфейса используется `Interface`тип .
`@context`	Задает контекст для документа JSON. Модели должны использоваться `dtmi:dtdl:context;2` для DTDL версии 2 или `dtmi:dtdl:context;3` для DTDL версии 3. Модели 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 cools room"), isBilledTo ("закомпрессор выставляется пользователю") и т. д. Связи позволяют решению предоставлять граф взаимосвязанных сущностей. Связи также могут иметь собственные свойства. Для получения дополнительной информации см. нижеприведенный раздел Связи.
Компонент — компоненты при необходимости используются для построения интерфейса модели посредством компоновки других интерфейсов. Пример компонента — интерфейс Камера (и другой интерфейс компонента Камера), используемый при определении модели для телефона. Сначала определите интерфейс для компонента frontCamera (Фронтальная камера) как для отдельной модели, а затем создайте ссылку на него при определении объекта Phone (Телефон).

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

Совет

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

Для получения дополнительной информации см. нижеприведенный раздел Компоненты.

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

Примечание.

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

Свойства

В этом разделе подробно описаны свойства моделей 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 объекта Home.

{
  "@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 — это объект со своими собственными полями для улицы, города, штата и почтового индекса.

{
  "@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.

Примечание.

Атрибуты writableDTDL minMultiplicityи maxMultiplicity DTDL для связей в настоящее время не поддерживаются в 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, то обработчик интерфейса цифрового двойника назначит его.

Целевые и нецелевые связи

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

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

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

{
  "@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 поле, в котором можно определить пользовательские свойства для описания состояния конкретной связи.

В следующем примере показана другая версия модели Home, в которой отношение 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. В этом примере показана модель Room, в которой модель термостата используется как компонент.

[
  {
    "@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.

Важно!

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

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

В некоторых случаях может потребоваться дальнейшая специализация модели. Например, вы можете определить общую модель Room (Помещение) и ее специализированные варианты ConferenceRoom (Конференц-зал) и Gym (Спортивный зал). На случай, если необходимо выразить специализацию, DTDL поддерживает наследование. Интерфейсы могут наследовать от одного или нескольких других интерфейсов. Это можно сделать, добавив поле extends в модель.

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

Примечание.

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

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

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

{
    "@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. Другие модели также могут расширять модель Core, чтобы получить эти свойства. Ниже приведена модель Room, расширяющая тот же родительский интерфейс.

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

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

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

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

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

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

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

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

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

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

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

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

Расширение заметки

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

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

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

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

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

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

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

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

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

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

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

Расширение QuantitativeTypes

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

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

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

Заметки 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 Обозреватель для их просмотра. Обозреватель содержит список всех моделей в экземпляре, а также граф модели, иллюстрирующий связь между ними, включая все связи наследования и модели.

Примечание.

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

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

Следующие шаги

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

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

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

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

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

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

Свойства

Схема

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

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

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

Связи

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

Целевые и нецелевые связи

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

Компоненты

Пример простого компонента

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

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

Расширение заметки

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

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

Расширение QuantitativeTypes

Заметки DTDL для конкретной службы

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

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

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

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

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

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

Следующие шаги

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