Información sobre los modelos gemelos y su definición en Azure Digital Twins

  • Artículo
  • 18 minutos para leer

Una característica clave de Azure Digital Twins es la capacidad de definir su propio vocabulario y crear el grafo de gemelos en los términos de la empresa definidos de manera automática. Esta funcionalidad la ofrecen los modelos proporcionados por el usuario. Puede considerar los modelos como los nombres de una descripción de su mundo. Los modelos de Azure Digital Twins se representan mediante el lenguaje de definición de gemelos digitales (DTDL) , que se basa en JSON-LD.

Un modelo es similar a una clase en un lenguaje de programación orientado a objetos, el que define una forma de datos para un concepto determinado en el entorno de trabajo real. Los modelos tienen nombres (como Sala o SensorDeTemperatura) y contienen elementos como propiedades, telemetría/eventos y comandos que describen lo que puede hacer este tipo de entidad en el entorno. Más adelante usará estos modelos para crear gemelos digitales que representen entidades específicas que cumplan con esta descripción de tipo.

Lenguaje de definición de gemelos digitales (DTDL) para modelos

Los modelos de Azure Digital Twins se definen con el lenguaje de definición de gemelos digitales (DTDL).

Puede ver las especificaciones del lenguaje completas de DTDL en GitHub: Lenguaje de definición de gemelos digitales (DTDL), versión 2. En esta página se incluyen referencias y ejemplos de DTDL detallados para ayudarle a empezar a escribir sus propios modelos de DTDL.

DTDL se basa en JSON-LD y es independiente del lenguaje de programación. DTDL no es exclusivo de Azure Digital Twins, sino que también se usa para presentar datos de dispositivo en otros servicios de IoT, como IoT Plug and Play. Azure Digital Twins usa la versión 2 de DTDL (el uso de DTDL versión 1 con Azure Digital Twins ahora está en desuso).

En el resto de este artículo se resume el uso del lenguaje en Azure Digital Twins.

Detalles específicos de la implementación de DTDL de Azure Digital Twins

No todos los servicios que usan DTDL implementan las mismas características exactas de DTDL. Por ejemplo, IoT Plug and Play no usa las características de DTDL que son para los grafos, mientras que Azure Digital Twins no implementa actualmente comandos de DTDL.

Para que un modelo de DTDL sea compatible con Azure Digital Twins, tiene que cumplir estos requisitos:

  • Todos los elementos de DTDL de nivel superior de un modelo deben ser de tipo interfaz. El motivo para este requisito es que las API del modelo de Azure Digital Twins pueden recibir objetos JSON que representan una interfaz o una matriz de interfaces. Como resultado, no se permite ningún otro tipo de elemento de DTDL en el nivel superior.
  • DTDL para Azure Digital Twins no debe definir ningún comando.
  • Azure Digital Twins solo permite un único nivel de anidamiento de componentes; es decir, una interfaz que se usa como componente no puede tener ningún componente en sí.
  • Las interfaces no pueden ser definidas insertadas en línea dentro de otras interfaces de DTDL, sino que deben definirse como entidades independientes de nivel superior con sus propios identificadores. A continuación, cuando otra interfaz quiere incluir esa interfaz como componente o a través de la herencia, puede hacer referencia a su identificador.

Azure Digital Twins tampoco observa el atributo writable en las propiedades ni relaciones. Aunque este atributo puede establecerse según las especificaciones de DTDL, Azure Digital Twins no usa el valor. En su lugar, estos atributos siempre se tratan como grabables por parte de los clientes externos que tienen permisos de escritura generales en el servicio Azure Digital Twins.

Introducción al modelo

Elementos de un modelo

Dentro de una definición de modelo, el elemento de código de nivel superior es una interfaz. Este tipo encapsula todo el modelo y el resto del modelo se define dentro de la interfaz.

Una interfaz de modelo de DTDL puede contener cero, uno o varios de los campos siguientes:

  • Propiedad: las propiedades son campos de datos que representan el estado de una entidad (como las propiedades de muchos lenguajes de programación orientados a objetos). Las propiedades tienen almacenamiento de seguridad y se pueden leer en cualquier momento. Para más información, consulte la sección Propiedades y telemetría a continuación.

  • Telemetría: los campos de telemetría representan medidas o eventos y a menudo se usan para describir las lecturas de los sensores del dispositivo. A diferencia de las propiedades, la telemetría no se almacena en un gemelo digital; es una serie de eventos de datos con límites temporales, que deben administrarse a medida que se producen. Para más información, consulte la sección Propiedades y telemetría a continuación.

  • Relación: las relaciones permiten representar cómo un gemelo digital puede estar implicado con otros gemelos digitales. Las relaciones pueden representar distintos significados semánticos, como contains ("floor contains room"), cools ("hvac cools room"), isBilledTo ("compressor is billed to user"), y así sucesivamente. Las relaciones permiten que la solución proporcione un grafo de las entidades interrelacionadas. Las relaciones también pueden tener propiedades propias. Para obtener más información, consulte Relaciones a continuación.

  • Componente: los componentes permiten compilar la interfaz de modelo como un ensamblado de otras interfaces, si lo desea. Un ejemplo de componente es una interfaz cámaraFrontal (y otra interfaz de componente cámaraPosterior) que se usa para definir un modelo para un teléfono. Primero defina una interfaz para cámaraFrontal como si fuera su propio modelo y, luego, puede hacer referencia a ella al definir el Teléfono.

    Use un componente para describir algo que es una parte integral de la solución, pero no necesita una identidad independiente y no es necesario crearla, eliminarla ni reorganizarla en el grafo de gemelos de forma independiente. Si quiere que las entidades tengan existencias independientes en el grafo de gemelos, represéntelas como gemelos digitales independientes de distintos modelos conectadas por relaciones.

    Sugerencia

    Los componentes también se pueden usar para la organización, a fin de agrupar conjuntos de propiedades relacionadas dentro de una interfaz de modelo. En esta situación, puede considerar cada componente como un espacio de nombres o "carpeta" dentro de la interfaz.

    Para más información, consulte la sección Componentes a continuación.

Nota

La especificación de DTDL también define comandos, que son métodos que se pueden ejecutar en un gemelo digital (como un comando de restablecimiento o un comando para encender o apagar un ventilador). Sin embargo, en este momento no se admiten comandos en Azure Digital Twins.

Código del modelo

Los modelos de tipo gemelo se pueden escribir en cualquier editor de texto. El lenguaje DTDL sigue la sintaxis JSON, por lo que debe almacenar los modelos con la extensión .json. El uso de la extensión JSON permitirá que muchos editores de texto de programación proporcionen comprobación de sintaxis básica y resaltado para los documentos de DTDL. También hay una extensión de DTDL disponible para Visual Studio Code.

Los campos del modelo son los siguientes:

Campo Descripción
@id Identificador del modelo. Debe tener el formato dtmi:<domain>:<unique-model-identifier>;<model-version-number>.
@type Identifica el tipo de información que se describe. En el caso de una interfaz, el tipo es Interfaz.
@context Establece el contexto del documento JSON. Los modelos deben usar dtmi:dtdl:context;2.
displayName [opcional] Le da la opción de definir un nombre descriptivo para el modelo.
contents Todos los datos restantes de la interfaz se colocan aquí, como una matriz de definiciones de atributo. Cada atributo debe especificar un valor de @type (property, telemetry, command, relationship o component) para identificar el tipo de información de la interfaz que describe y, después, un conjunto de propiedades que definen el atributo real (por ejemplo, name y schema para definir property).

Ejemplo del modelo

Esta sección contiene un ejemplo de un modelo básico, escrito como si fuera una interfaz de DTDL.

Este modelo describe un modelo Home, con un valor de property como identificador. El modelo Home también define relationship con un modelo Floor, que se puede usar para indicar que un gemelo de Home está conectado a determinados gemelos de 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"
    }
  ]
}

Propiedades y telemetría

En esta sección se explican con mayor detalle las propiedades y la telemetría de los modelos de DTDL.

Para obtener una lista completa de los campos que pueden aparecer como parte de una propiedad, consulte Propiedad en la especificación dtdl v2. Para obtener una lista completa de los campos que pueden aparecer como parte de la telemetría, consulte Telemetría en la especificación dtdl v2.

Diferencia entre propiedades y telemetría

A continuación se ofrecen instrucciones para distinguir entre propiedades y telemetría de DTDL en Azure Digital Twins.

  • Se espera que las propiedades tengan almacenamiento auxiliar, lo que significa que puede leer una propiedad en cualquier momento y recuperar su valor. Si la propiedad es de escritura, también puede almacenar un valor en ella.
  • La telemetría es más similar a un flujo de eventos; es un conjunto de mensajes de datos que tienen una duración breve. Si no configura la escucha del evento y las acciones que deben realizarse cuando tiene lugar, no hay ningún seguimiento del evento en un momento posterior. No puede volver y leerlo más tarde.
    • En términos de C#, la telemetría es como un evento de C#.
    • En términos de IoT, la telemetría suele ser una medida única que envía un dispositivo.

La telemetría se usa a menudo con dispositivos de IoT, ya que muchos dispositivos no son capaces de almacenar los valores de medida que generan, o no les interesa hacerlo. En su lugar, los envían como un flujo de eventos de "telemetría". En este caso, no puede consultar al dispositivo en cualquier momento el valor más reciente del campo de telemetría. Tendrá que escuchar los mensajes desde el dispositivo y tomar medidas a medida que lleguen los mensajes.

Como consecuencia, al diseñar un modelo en Azure Digital Twins, es probable que use propiedades en la mayoría de los casos para modelar los gemelos. De esta manera, puede tener el almacenamiento auxiliar, y la capacidad de leer y consultar los campos de datos.

La telemetría y las propiedades a menudo funcionan en conjunto para controlar la entrada de datos desde dispositivos. Como toda la entrada a Azure Digital Twins se realiza a través de las API, normalmente usará la función de entrada para leer los eventos de telemetría o propiedad de los dispositivos, y establecer una propiedad en Azure Digital Twins en respuesta.

También puede publicar un evento de telemetría desde la API de Azure Digital Twins. Como con otros tipos de telemetría, es un evento de corta duración que requiere un agente de escucha para el control.

Schema

Según DTDL, el esquema de los atributos propiedad y telemetría puede ser de tipos primitivos estándar (integer, double, string y boolean) y de otros tipos como dateTime y duration.

Además de los tipos primitivos, los campos de propiedad y telemetría pueden tener estos tipos complejos:

  • Object
  • Map
  • Enum
  • (solo telemetría) Array

También pueden ser tipos semánticos, que permiten anotar valores con unidades.

Ejemplos básicos de propiedad y telemetría

Este es un ejemplo básico de propiedad en un modelo de DTDL. En este ejemplo se muestra la propiedad ID de un elemento Home.

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

Este es un ejemplo básico de un campo de telemetría en un modelo de DTDL. En este ejemplo se muestra la telemetría de temperatura en un 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"      
    }
  ]
}

Ejemplo de tipo complejo (objeto)

Tanto las propiedades como la telemetría pueden ser de tipos complejos, como un tipo Object.

En el ejemplo siguiente se muestra otra versión del modelo Home, con una propiedad para su dirección. address es un objeto, con sus propios campos para la calle, la ciudad, el estado y el código postal.

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

Ejemplo de tipo semántico

Los tipos semánticos permiten expresar con una unidad. Las propiedades y la telemetría se pueden representar con cualquier tipo semántico compatible con DTDL. Para más información no solo sobre los tipos semánticos de DTDL, sino también sobre los valores se admiten, consulte la sección sobre tipos semánticos en la especificación de la versión 2 de DTDL.

En el ejemplo siguiente se muestra un modelo Sensor con telemetría de tipo semántico para Temperature y una propiedad de tipo semántico para Humedad.

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

Relaciones

En esta sección se explican con mayor detalle las relaciones en los modelos de DTDL.

Para obtener una lista completa de los campos que pueden aparecer como parte de una relación, consulte Relación en la especificación DTDL v2.

Ejemplo básico de relación

Este es un ejemplo básico de una relación en un modelo de DTDL. En este ejemplo se muestra una relación en un modelo Home que le permite conectarse a un 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

En las relaciones, @id es un campo opcional. Si no se proporciona el valor de @id, el procesador de la interfaz de gemelo digital asignará uno.

Relaciones con y sin destino

Las relaciones se pueden definir con o sin un destino. Los destinos especifica los tipos de gemelos a los que puede acceder la relación. Por ejemplo, puede incluir un destino para especificar que un modelo Home solo puede tener una relación rel_has_floors con gemelos de Floor.

A veces, es posible que quiera definir una relación sin un destino concreto, con el fin de que esta pueda conectarse a muchos tipos diferentes de gemelos.

Este es un ejemplo de una relación en un modelo de DTDL que no tiene un destino. En este ejemplo, la relación se usa para definir qué sensores podría tener el modelo Sala y la relación puede conectarse a cualquier 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"
    }
  ]
},

Propiedades de las relaciones

DTDL también permite que las relaciones tengan propiedades propias. Al definir una relación dentro de un modelo de DTDL, la relación puede tener su propio campo properties donde puede definir propiedades personalizadas para describir el estado específico de la relación.

En el siguiente ejemplo se muestra otra versión del modelo Home, en el que la relación rel_has_floors tiene una propiedad que representa cuándo fue la última vez que se ocupó el modelo Floor relacionado.

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

En esta sección se explican con mayor detalle los componentes en los modelos de DTDL.

Para obtener una lista completa de los campos que pueden aparecer como parte de un componente, consulte Componente en la especificación DTDL v2.

Ejemplo de componente básico

Este es un ejemplo básico de un componente en un modelo de DTDL. En este ejemplo se muestra un modelo Room que usa un modelo de termostato como 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"
      }
    ]
  }
]

Si otros modelos de esta solución también deben contener un termostato, pueden hacer referencia al mismo modelo de termostato que un componente en sus propias definiciones, al igual que hace Room.

Importante

La interfaz del componente (el termostato en el ejemplo anterior) debe definirse en la misma matriz que cualquier interfaz que lo use (Room en el ejemplo anterior) para que se pueda encontrar la referencia del componente.

Herencia de modelo

En algunas ocasiones, puede que quiera especializar aún más un modelo. Por ejemplo, podría resultar útil tener un modelo genérico Sala y las variantes especializadas SalaDeConferencias y Gimnasio. Para expresar la especialización, DTDL admite la herencia. Las interfaces pueden heredar de una o varias interfaces. Para ello, tiene que agregar un campo extends al modelo.

La sección extends es un nombre de interfaz o una matriz de nombres de interfaz (lo que permite que la interfaz de extensión herede de varios modelos primarios). Un único elemento primario puede servir como modelo base para varias interfaces de extensión.

En el ejemplo siguiente se recrea el modelo Home del ejemplo de DTDL anterior como subtipo de un modelo "central" mayor. Primero se define el modelo (Core) y, después, el modelo secundario (Home) se basa en él mediante 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": [
    {

En este caso, Core aporta un identificador y un nombre a Home. Otros modelos también pueden extender el modelo Core para obtener también estas propiedades. Este es un modelo Room que extiende la misma interfaz primaria:

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

Una vez que se aplica la herencia, la interfaz de extensión expone todas las propiedades de toda la cadena de herencia.

La interfaz de extensión no puede cambiar ninguna de las definiciones de las interfaces primarias; solo puede agregar a ellas. Tampoco puede volver a definir una funcionalidad que ya esté definida en ninguna de sus interfaces primarias (incluso si las funcionalidades están definidas para ser iguales). Por ejemplo, si una interfaz primaria define una propiedad double masa, la interfaz de extensión no puede contener una declaración de masa, incluso si también es double.

Procedimientos recomendados para la creación de modelos

Al diseñar modelos para que reflejen las entidades de su entorno, puede resultar útil realizar una búsqueda anticipada y considerar las implicaciones de consulta del diseño. Si lo desea, puede diseñar las propiedades de forma que se evite que grandes conjuntos de resultados atraviesen un grafo. También puede crear modelos de relaciones que será preciso que se respondan en una consulta individual como relaciones de nivel único.

Validación de modelos

Sugerencia

Después de crear un modelo, se recomienda validar los modelos sin conexión antes de cargarlos en la instancia de Azure Digital Twins.

Hay un ejemplo de validador de DTDL disponible para todos los lenguajes que sirve para validar los documentos del modelo para garantizar que DTDL sea correcto antes de cargarlo en la instancia.

El ejemplo de validador de DTDL se basa en una biblioteca de analizador de DTDL de .NET, que está disponible en NuGet como una biblioteca de cliente: Microsoft.Azure.DigitalTwins.Parser. También puede usar la biblioteca directamente para diseñar su propia solución de validación. Al usar la biblioteca del analizador, asegúrese de usar una versión que sea compatible con la versión de Azure Digital Twins que se está ejecutando. Actualmente, se trata de la versión 3.12.4.

Puede obtener más información sobre el ejemplo del validador y la biblioteca del analizador, incluidos ejemplos de uso, en Análisis y validación de modelos.

Herramientas de creación de modelos

Hay varios ejemplos disponibles para que sea aún más fácil usar modelos y ontologías. Se encuentran en este repositorio: Herramientas para el Lenguaje de definición de Digital Twins (DTDL).

En esta sección se describe con más detalle el conjunto de ejemplos actual.

Usuario de carga del modelo

Una vez que haya terminado de crear, extender o seleccionar los modelos, puede cargarlos en la instancia de Azure Digital Twins para que estén disponibles para su uso en la solución. Para ello, puede usar las API de Azure Digital Twins, según se describe en Administración de modelos de Azure Digital Twins.

Sin embargo, si tiene muchos modelos para cargar, o si estos tienen muchas interdependencias que dificultarían la ordenación de las cargas individuales, puede usar el ejemplo del usuario de carga de modelos de Azure Digital Twins para cargar muchos modelos a la vez. Siga las instrucciones que se proporcionan con el ejemplo para configurar y usar este proyecto para cargar modelos en su propia instancia.

Visualizador de modelos

Una vez que cargue los modelos en la instancia de Azure Digital Twins, podrá verlos en dicha instancia, incluidas todas las relaciones de herencia y modelo, mediante el visualizador de modelos de Azure Digital Twins. Este ejemplo se encuentra actualmente en un estado de borrador. Se recomienda que la comunidad de desarrollo de gemelos digitales extienda y contribuya con este ejemplo.

Pasos siguientes