Saiba mais sobre modelos duplos e como defini-los no Azure Digital Twins

Uma característica fundamental do Azure Digital Twins é a capacidade de definir o seu próprio vocabulário e criar o seu gráfico duplo nos termos autodefinidos da sua empresa. Esta capacidade é fornecida através de modelos fornecidos pelo utilizador. Pode considerar os modelos como os substantivos numa descrição do seu mundo. Os modelos do Azure Digital Twins estão representados na Linguagem DTDL (Digital Twin Definition Language) baseada em JSON-LD.

Um modelo é semelhante a uma classe numa linguagem de programação orientada para objetos, definindo uma forma de dados para um conceito específico no seu ambiente de trabalho real. Os modelos têm nomes (como Room ou TemperatureSensor) e contêm elementos como propriedades, telemetria e relações que descrevem o que faz este tipo de entidade no seu ambiente. Mais tarde, irá utilizar estes modelos para criar duplos digitais que representam entidades específicas que cumprem este tipo de descrição.

Digital Twin Definition Language (DTDL) para modelos

Os modelos do Azure Digital Twins são definidos com a Linguagem de Definição do Digital Twins (DTDL).

Pode ver as especificações de idioma completas para DTDL no GitHub: Digital Twins Definition Language (DTDL) – Referência da Versão 2. Esta página inclui referência detalhada do DTDL e exemplos para o ajudar a começar a escrever os seus próprios modelos DTDL.

A DTDL tem como base JSON-LD e é independente de linguagens de programação. O DTDL não é exclusivo do Azure Digital Twins, mas também é utilizado para representar dados de dispositivos noutros serviços IoT, como o IoT Plug and Play. O Azure Digital Twins utiliza a versão 2 do DTDL (a utilização da versão 1 do DTDL com o Azure Digital Twins foi preterida).

O resto deste artigo resume como o idioma é utilizado no Azure Digital Twins.

Descrição geral do modelo

Os modelos de tipo duplo podem ser escritos em qualquer editor de texto. A linguagem DTDL segue a sintaxe JSON, pelo que deve armazenar modelos com a extensão .json. A utilização da extensão JSON permitirá que muitos editores de texto de programação forneçam verificação e realce básicos de sintaxe para os seus documentos DTDL. Também existe uma extensão DTDL disponível para o Visual Studio Code.

Eis os campos numa interface de modelo:

Campo Descrição
@id Um Identificador de Modelo de Duplo Digital (DTMI) para o modelo. Tem de estar no formato dtmi:<domain>:<unique-model-identifier>;<model-version-number>.
@type Identifica o tipo de informação que está a ser descrita. Para uma interface, o tipo é Interface.
@context Define o contexto do documento JSON. Os modelos devem utilizar dtmi:dtdl:context;2.
displayName [opcional] Dá-lhe a opção de definir um nome amigável para o modelo. Se não utilizar este campo, o modelo utilizará o respetivo valor DTMI completo.
contents Todos os dados restantes da interface são colocados aqui, como uma matriz de definições de atributos. Cada atributo tem de fornecer um @type (, , TelemetryRelationshipou Component) para identificar o tipo de informações de interface que descreve e, em seguida, um conjunto de propriedades que definem o atributoProperty real. A secção seguinte descreve os atributos do modelo em detalhe.

Eis um exemplo de um modelo DTDL básico. Este modelo descreve uma Home Page, com uma propriedade para um ID. O modelo Home Page também define uma relação com um modelo Floor, que pode ser utilizado para indicar que um duplo Base está ligado a determinados duplos 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"
    }
  ]
}

Atributos de modelo

As principais informações sobre um modelo são fornecidas pelos respetivos atributos, que são definidos na contents secção da interface de modelo. Eis os atributos disponíveis no DTDL. Uma interface de modelo DTDL pode conter zero, um ou muitos dos seguintes campos:

  • Propriedade – as propriedades são campos de dados que representam o estado de uma entidade (como as propriedades em muitas linguagens de programação orientadas para objetos). As propriedades têm armazenamento de cópia de segurança e podem ser lidas em qualquer altura. Para obter mais informações, veja Propriedades e telemetria abaixo.

  • Telemetria – os campos de telemetria representam medidas ou eventos e são frequentemente utilizados para descrever leituras de sensores de dispositivos. Ao contrário das propriedades, a telemetria não é armazenada num duplo digital; É uma série de eventos de dados vinculados ao tempo que têm de ser processados à medida que ocorrem. Para obter mais informações, veja Propriedades e telemetria abaixo.

  • Relação – as relações permitem-lhe representar como um duplo digital pode ser envolvido com outros duplos digitais. As relações podem representar diferentes significados semânticos, tais como contains ("o piso contém sala"), cools ("sala de refrigeração hvac"), isBilledTo ("o compressor é faturado ao utilizador"), etc. As relações permitem que a solução forneça um gráfico de entidades interrelacionadas. As relações também podem ter propriedades próprias. Para obter mais informações, veja Relações abaixo.

  • Componente – os componentes permitem-lhe criar a interface de modelo como uma assemblagem de outras interfaces, se quiser. Um exemplo de um componente é uma interface frontCamera (e outra interface de componente backCamera) que são utilizadas na definição de um modelo para um telemóvel. Primeiro, defina uma interface para frontCamera como se fosse o seu próprio modelo e, em seguida, faça referência ao definir Telemóvel.

    Utilize um componente para descrever algo que é parte integrante da sua solução, mas não precisa de uma identidade separada e não precisa de ser criado, eliminado ou reorganizado no gráfico duplo de forma independente. Se quiser que as entidades tenham existências independentes no gráfico duplo, represente-as como duplos digitais separados de diferentes modelos, ligados por relações.

    Dica

    Os componentes também podem ser utilizados para a organização, para agrupar conjuntos de propriedades relacionadas numa interface de modelo. Nesta situação, pode considerar cada componente como um espaço de nomes ou "pasta" dentro da interface.

    Para obter mais informações, veja Componentes abaixo.

Nota

A especificação para DTDL também define Comandos, que são métodos que podem ser executados num duplo digital (como um comando de reposição ou um comando para ativar ou desativar um ventilador). No entanto, os comandos não são atualmente suportados no Azure Digital Twins.

Propriedades e telemetria

Esta secção aborda mais detalhadamente as propriedades e a telemetria nos modelos DTDL.

Para obter informações abrangentes sobre os campos que podem aparecer como parte de uma propriedade, veja Propriedade na Referência DTDL V2. Para obter informações abrangentes sobre os campos que podem aparecer como parte da telemetria, veja Telemetria na Referência DTDL V2.

Nota

O writable atributo DTDL para propriedades não é atualmente suportado no Azure Digital Twins. Pode ser adicionado ao modelo, mas o Azure Digital Twins não o vai impor. Para obter mais informações, veja Notas DTDL específicas do serviço.

Diferença entre propriedades e telemetria

Eis algumas orientações sobre a distinção conceptual entre as propriedades DTDL e a telemetria no Azure Digital Twins.

  • Espera-se que as propriedades tenham armazenamento de cópia de segurança, o que significa que pode ler uma propriedade em qualquer altura e obter o respetivo valor. Se a propriedade for gravável, também pode armazenar um valor na propriedade.
  • A telemetria é mais semelhante a um fluxo de eventos; é um conjunto de mensagens de dados que têm uma vida útil curta. Se não configurar a escuta do evento e as ações a realizar quando tal acontece, não haverá rastreio do evento mais tarde. Não pode voltar a fazê-lo e lê-lo mais tarde.
    • Em termos C#, a telemetria é como um evento C#.
    • Em termos de IoT, a telemetria é normalmente uma única medida enviada por um dispositivo.

A telemetria é frequentemente utilizada com dispositivos IoT, porque muitos dispositivos não podem, ou não estão interessados, armazenar os valores de medição que geram. Em vez disso, enviam-nos como uma transmissão de eventos de "telemetria". Neste caso, não pode consultar o dispositivo em qualquer altura para obter o valor mais recente do campo de telemetria. Terá de ouvir as mensagens do dispositivo e tomar medidas à medida que as mensagens chegam.

Como resultado, ao conceber um modelo no Azure Digital Twins, provavelmente utilizará propriedades na maioria dos casos para modelar os seus duplos. Fazê-lo permite-lhe ter o armazenamento de cópias de segurança e a capacidade de ler e consultar os campos de dados.

Muitas vezes, a telemetria e as propriedades funcionam em conjunto para processar a entrada de dados de dispositivos. Muitas vezes, irá utilizar uma função de entrada para ler telemetria ou eventos de propriedade a partir de dispositivos e definir uma propriedade no Azure Digital Twins em resposta.

Também pode publicar um evento de telemetria a partir da API do Azure Digital Twins. Tal como acontece com outras telemetrias, é um evento de curta duração que requer um serviço de escuta para processar.

Esquema

De acordo com o DTDL, o esquema para atributos de propriedade e telemetria pode ser de tipos primitivos padrão —integer, double, stringe — e booleanoutros tipos, como dateTime e duration.

Além dos tipos primitivos, os campos de propriedade e telemetria podem ter estes tipos complexos:

  • Object
  • Map
  • Enum
  • (apenas telemetria) Array

Também podem ser tipos semânticos, que lhe permitem anotar valores com unidades.

Exemplos básicos de propriedades e telemetria

Eis um exemplo básico de uma propriedade num modelo DTDL. Este exemplo mostra a propriedade ID de uma Home Page.

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

Eis um exemplo básico de um campo de telemetria num modelo DTDL. Este exemplo mostra a telemetria de Temperatura num Sensor.

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

Exemplo de tipo complexo (objeto)

As propriedades e a telemetria podem ser de tipos complexos, incluindo um Object tipo.

O exemplo seguinte mostra outra versão do modelo Home Page, com uma propriedade para o respetivo endereço. address é um objeto, com os seus próprios campos para rua, cidade, estado e zip.

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

Exemplo de tipo semântico

Os tipos semânticos permitem expressar um valor com uma unidade. As propriedades e a telemetria podem ser representadas com qualquer um dos tipos semânticos suportados pelo DTDL. Para obter mais informações sobre tipos semânticos no DTDL e quais os valores suportados, veja Semântica types in the DTDL V2 Reference (Tipos semânticos na Referência DTDL V2).

O exemplo seguinte mostra um modelo sensor com uma telemetria de tipo semântico para Temperatura e uma propriedade de tipo semântico para Humidade.

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

Nota

"Propriedade" ou "Telemetria" tem de ser o primeiro elemento da @type matriz, seguido do tipo semântico. Caso contrário, o campo poderá não estar visível no Explorador do Azure Digital Twins.

Relações

Esta secção aborda mais detalhadamente as relações nos modelos DTDL.

Para obter uma lista abrangente dos campos que podem aparecer como parte de uma relação, veja Relationship in the DTDL V2 Reference (Relação na Referência do DTDL V2).

Nota

Os writableatributos , minMultiplicitye maxMultiplicity DTDL para relações não são atualmente suportados no Azure Digital Twins. Podem ser adicionados ao modelo, mas o Azure Digital Twins não os irá impor. Para obter mais informações, veja Notas DTDL específicas do serviço.

Exemplo de relação básica

Eis um exemplo básico de uma relação num modelo DTDL. Este exemplo mostra uma relação num modelo Home Page que lhe permite ligar a um modelo 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"
    }
  ]
}

Nota

Para relações, @id é um campo opcional. Se não @id for fornecido, o processador da interface de duplo digital irá atribuir um.

Relações direcionadas e não direcionadas

As relações podem ser definidas com ou sem um destino. Um destino especifica os tipos de duplos que a relação pode alcançar. Por exemplo, pode incluir um destino para especificar que um modelo Home Page só pode ter uma rel_has_floors relação com duplos duplos que sejam Duplos do piso.

Por vezes, poderá querer definir uma relação sem um destino específico, para que a relação se possa ligar a muitos tipos diferentes de duplos.

Eis um exemplo de uma relação num modelo DTDL que não tem um destino. Neste exemplo, a relação é para definir os sensores que uma Sala pode ter e a relação pode ligar-se a qualquer tipo.

{
  "@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"
    }
  ]
},

Propriedades das relações

O DTDL também permite que as relações tenham propriedades próprias. Ao definir uma relação num modelo DTDL, a relação pode ter o seu próprio properties campo, onde pode definir propriedades personalizadas para descrever o estado específico da relação.

O exemplo seguinte mostra outra versão do modelo Home Page, em que a rel_has_floors relação tem uma propriedade que representa quando o Piso relacionado foi ocupado pela última vez.

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

Componentes

Esta secção aborda mais detalhadamente os componentes nos modelos DTDL.

Para obter uma lista abrangente dos campos que podem aparecer como parte de um componente, veja Component in the DTDL V2 Reference (Componente na Referência DTDL V2).

Exemplo de componente básico

Eis um exemplo básico de um componente num modelo DTDL. Este exemplo mostra um modelo de Sala que utiliza um modelo termóstato como um componente.

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

Se outros modelos nesta solução também tiverem um termóstato, podem referenciar o mesmo modelo de termóstato como um componente nas suas próprias definições, tal como o Room.

Importante

A interface de componente (termóstato no exemplo acima) tem de ser definida na mesma matriz que qualquer interface que a utilize (Sala no exemplo acima) para que a referência do componente seja encontrada.

Herança de modelos

Por vezes, poderá querer especializar ainda mais um modelo. Por exemplo, pode ser útil ter uma Sala de modelos genérico e variantes especializadas ConferenceRoom e Gym. Para expressar especialização, o DTDL suporta a herança. As interfaces podem herdar de uma ou mais interfaces. Pode fazê-lo ao adicionar um extends campo ao modelo.

A extends secção é um nome de interface ou uma matriz de nomes de interface (permitindo que a interface de expansão herda de vários modelos principais). Um único elemento principal pode servir de modelo base para várias interfaces de expansão.

O exemplo seguinte recria o modelo Home Page do exemplo DTDL anterior como um subtipo de um modelo "core" maior. O modelo principal (Core) é definido primeiro e, em seguida, o modelo subordinado (Home) baseia-se no mesmo com extends.

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

Neste caso, o Core contribui com um ID e o nome para Home Page. Outros modelos também podem expandir o modelo Core para obter estas propriedades. Eis um modelo de Sala que expande a mesma interface principal:

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

Uma vez aplicada a herança, a interface de expansão expõe todas as propriedades de toda a cadeia de herança.

A interface de expansão não pode alterar nenhuma das definições das interfaces principais; só pode adicioná-las. Também não pode redefinir uma capacidade já definida em nenhuma das respetivas interfaces principais (mesmo que as capacidades estejam definidas para serem as mesmas). Por exemplo, se uma interface principal definir uma double propriedade mass, a interface de expansão não pode conter uma declaração de mass, mesmo que seja também uma double.

Notas DTDL específicas do serviço

Nem todos os serviços que utilizam DTDL implementam exatamente as mesmas funcionalidades do DTDL. Existem algumas funcionalidades de DTDL que o Azure Digital Twins não suporta atualmente, incluindo:

  • Comandos DTDL
  • O writable atributo em propriedades ou relações. Embora este atributo possa ser definido de acordo com as especificações de DTDL, o valor não é utilizado pelo Azure Digital Twins. Em vez disso, estes atributos são sempre tratados como graváveis por clientes externos que têm permissões de escrita gerais para o serviço Azure Digital Twins.
  • As minMultiplicity propriedades e maxMultiplicity nas relações. Embora estes atributos possam ser definidos de acordo com as especificações de DTDL, os valores não são impostos pelo Azure Digital Twins.

Para que um modelo DTDL seja compatível com o Azure Digital Twins, também tem de cumprir estes requisitos:

  • Todos os elementos DTDL de nível superior num modelo têm de ser do tipo Interface. O motivo deste requisito é que as APIs de modelo do Azure Digital Twins podem receber objetos JSON que representam uma interface ou uma matriz de interfaces. Como resultado, não são permitidos outros tipos de elementos DTDL no nível superior.
  • O DTDL para o Azure Digital Twins não pode definir nenhum comando.
  • O Azure Digital Twins permite apenas um único nível de aninhamento de componentes, o que significa que uma interface que está a ser utilizada como componente não pode ter nenhum componente em si.
  • As interfaces não podem ser definidas inline noutras interfaces DTDL; têm de ser definidas como entidades de nível superior separadas com os seus próprios IDs. Em seguida, quando outra interface quiser incluir essa interface como um componente ou através da herança, pode referenciar o respetivo ID.

Ferramentas de modelação e melhores práticas

Esta secção descreve considerações e recomendações adicionais para modelação.

Utilizar as toologias padrão da indústria DTDL

Se a sua solução for para um determinado setor estabelecido (como edifícios inteligentes, cidades inteligentes ou redes energéticas), considere começar com um conjunto de modelos pré-existente para a sua indústria em vez de conceber os seus modelos de raiz. A Microsoft estabeleceu uma parceria com especialistas em domínios para criar conjuntos de modelos DTDL com base nos padrões da indústria, para ajudar a minimizar a reinvenção e incentivar a consistência e simplicidade em todas as soluções do setor. Pode ler mais sobre estas onologias, incluindo como utilizá-las e que toologias estão disponíveis agora, em O que é uma ontologia?.

Considerar as implicações da consulta

Ao conceber modelos para refletir as entidades no seu ambiente, pode ser útil olhar para o futuro e considerar as implicações da consulta da sua estrutura. Poderá querer estruturar propriedades de uma forma que evite grandes conjuntos de resultados do percurso de grafos. Também pode querer modelar relações que terão de ser respondidas numa única consulta como relações de nível único.

Validar modelos

Dica

Depois de criar um modelo, é recomendado validar os modelos offline antes de os carregar para a instância do Azure Digital Twins.

Existe um exemplo de Validador de DTDL agnóstico de linguagem para validar documentos de modelo para se certificar de que o DTDL está correto antes de o carregar para a instância.

O exemplo de validador DTDL baseia-se numa biblioteca de analisador .NET DTDL, que está disponível no NuGet como uma biblioteca do lado do cliente: Microsoft.Azure.DigitalTwins.Parser. Também pode utilizar a biblioteca diretamente para criar a sua própria solução de validação.

A versão 4.0.8 da biblioteca de analisador é a versão atualmente recomendada para compatibilidade com o Azure Digital Twins.

Pode saber mais sobre o exemplo de validador e a biblioteca de analisador, incluindo exemplos de utilização, em Analisar e validar modelos.

Carregar e eliminar modelos em massa

Eis dois projetos de exemplo que podem simplificar a gestão de vários modelos ao mesmo tempo:

  • Carregador de modelos: quando terminar de criar, expandir ou selecionar os seus modelos, tem de os carregar para a instância do Azure Digital Twins para os disponibilizar para utilização na sua solução. Se tiver muitos modelos para carregar ou se tiverem muitas interdependências que tornariam a ordenação de carregamentos individuais complicada, pode utilizar este exemplo de carregador de modelos para carregar muitos modelos ao mesmo tempo.
  • Eliminação de modelos: este exemplo pode ser utilizado para eliminar todos os modelos numa instância do Azure Digital Twins ao mesmo tempo. Contém lógica recursiva para processar dependências de modelos através do processo de eliminação.

Visualizar modelos

Depois de carregar modelos para a sua instância do Azure Digital Twins, pode utilizar o Explorador do Azure Digital Twins para os ver. O explorador contém uma lista de todos os modelos na instância, bem como um gráfico de modelo que ilustra como se relacionam entre si, incluindo qualquer herança e relações de modelo.

Eis um exemplo do aspeto que um gráfico de modelo poderá ter:

Captura de ecrã do Explorador do Azure Digital Twins. O painel Model Graph está realçado.

Para obter mais informações sobre a experiência de modelo no Explorador do Azure Digital Twins, veja Explorar modelos e o Model Graph.

Passos seguintes