Qué usuarios de OSConfig deben saber sobre las cadenas de herramientas "normales deseadas o notificadas" frente a las cadenas de herramientas "mejoradas de DTDL".

Al leer documentos de OSConfig y probar escenarios a través de distintas herramientas, puede resultar útil comprender que en el ecosistema de Azure IoT hay dos perspectivas para describir el contenido del gemelo.

Perspectiva 1: Deseado o notificado sin formato

Las propiedades deseadas y notificadas constituyen el modelo de objetos de IoT Hub principal. La mayoría de las herramientas y servicios usan esta perspectiva deseada o notificada sin formato. Por ejemplo:

• El servicio de consulta de IoT Hub
• El servicio de configuraciones de IoT Hub
• Los az iot hub module-twin comandos
• Las vistas gemelas de IoT Hub en el Azure Portal
• Vistas gemelas sin formato en IoT Explorer

La perspectiva deseada o notificada sin formato podría describirse como un documento JSON donde:

1. El estado real (como la configuración o el estado actual) se notifica mediante código en el dispositivo en la properties.reported sección .
2. Estado deseado (como los valores de configuración del administrador), si los hay, los agrega las herramientas de administración en la nube en la properties.desired sección .
3. Si se especificó algún estado deseado desde el lado de la nube, el código responsable en el dispositivo reconoce lo mismo a través de propiedades adicionales en la properties.reported sección .

En el ejemplo siguiente se muestra un extracto simplificado del módulo gemelo OSConfig de un dispositivo en IoT Hub:

1. El agente OSConfig del dispositivo siempre informa del nombre de host actual como properties.reported.HostName.name
2. Además, el administrador quería asegurarse de un valor específico, por lo que en el lado de la nube rellenaba properties.desired.HostName.desiredName
3. En respuesta a properties.desired.HostName.desiredName que el administrador rellena el agente de OSConfig en el dispositivo confirma la recepción del mismo que properties.reported.HostName.desiredName.

Perspectiva 2: Modelado mejorado del lenguaje de definición de gemelos digitales (DTDL)

DTDL (junto con patrones relacionados, como Azure IoT Plug and Play [PnP]) permite a las aplicaciones y servicios anticipar, validar y contextualizar mejor el contenido gemelo más allá de JSON sin formato. Entre las herramientas y los servicios que usan esta perspectiva mejorada de DTDL se incluyen las siguientes:

• Vistas de "Plug and Play" en IoT Explorer
• El servicio Azure Digital Twins

Una vista mejorada de DTDL del contenido gemelo anterior podría describirse como:

• Este dispositivo o módulo tiene un componente denominado HostName que implementa la interfaz OSConfig HostName .

• Dentro del componente o interfaz hostName, hay una propiedad de solo lectura Cuyo valor debe ser una cadena.

• También dentro del componente HostName, hay una propiedad grabable denominada desiredName cuyo valor debe ser una cadena.

  ¹ En el contexto de DTDL tal como se aplica a los agentes de dispositivos como OSConfig, "solo lectura" significa que el dispositivo notifica la propiedad, no establecida (directamente) por el administrador en la nube.
  ² En el contexto de DTDL tal y como se aplica a los agentes de dispositivo como OSConfig, "writeable" significa que el administrador puede establecer la propiedad en la nube y que, cuando el dispositivo recibe esto, habrá una confirmación.

La captura de pantalla siguiente de IoT Explorer es un ejemplo de una herramienta mediante DTDL. En este ejemplo, IoT Explorer permite al administrador saber que desiredName está disponible para establecerse en HostName. Es posible que el administrador no haya sabido que se trata de una opción, especialmente si la properties.desired sección del gemelo subyacente está en blanco de forma predeterminada.

¿Qué perspectiva describe la documentación de OSConfig?

En la documentación de referencia de OSConfig, se describe de forma predeterminada la perspectiva deseada o notificada sin formato. Cuando se aplica contexto adicional para las herramientas mejoradas de DTDL, esa información se incluye entre paréntesis.

Por ejemplo, en CommandRunner: commandArguments (establecido por admin), los valores posibles de action se describen como "1 (reinicio), 2 (apagado), 3 (RunCommand) o 4 (refreshCommandStatus)". En una experiencia deseada o notificada sin formato, como az iot hub module-twin show vería los valores numéricos. En una experiencia mejorada de DTDL, como las vistas de IoT Plug and Play de IoT Explorer, verá las etiquetas ("reinicio", etc.)

Cómo (o una herramienta que estoy usando, como IoT Explorer) encontrar los modelos DTDL de OSConfig más recientes (DTMI)?

En IoT Explorer, en Inicio > IoT Plug and Play Configuración, elija Agregar un repositorio configurable, con la siguiente ruta de acceso: raw.githubusercontent.com/Azure/azure-osconfig/main. Consulte la captura de pantalla siguiente para obtener un ejemplo.

Si desea inspeccionar los modelos directamente, en lugar de cargarlos en IoT Explorer, el URI es: https://github.com/Azure/azure-osconfig/tree/main/dtmi/osconfig.

Nota

¿Por qué no se encuentran los modelos en https://devicemodels.azure.com?

Las versiones anteriores de los modelos OSConfig se publicaron en https://devicemodels.azure.com, pero (a partir de esta escritura) no es posible publicar versiones más recientes allí. En su lugar, se debe usar la dirección de GitHub anterior.

Pasos siguientes

Para obtener información general sobre los escenarios y funcionalidades de OSConfig, consulte:

• ¿Qué es OSconfig para IoT?

Para obtener ejemplos prácticos específicos, consulte:

• Creación de un entorno de laboratorio de OSConfig (con Azure IoT) en 5 minutos
• Inicio rápido: Consulta de ejemplos para empezar a trabajar con OSConfig y Azure IoT
• ¿Qué puedo aprovisionar y administrar?