Guida alla modellazione Plug and Play IoT
Plug and Play IoT è basato su un modello di dispositivo che viene usato dal dispositivo per descrivere le rispettive funzionalità a un'applicazione abilitata per Plug and Play IoT. Questo modello è strutturato come un set di interfacce che definiscono quanto segue:
- Proprietà che rappresentano lo stato di sola lettura e di scrittura di un dispositivo o di un'altra entità. Ad esempio, il numero di serie del dispositivo può essere una proprietà di sola lettura, mentre la temperatura di destinazione di un termostato può essere una proprietà scrivibile.
- Telemetria campi che definiscono i dati generati da un dispositivo, siano essi un normale flusso di letture di sensori, un errore occasionale o un messaggio informativo.
- Comandi che descrivono una funzione o un'operazione che può essere eseguita su un dispositivo. Ad esempio, un comando può riavviare un gateway o scattare una foto usando una fotocamera remota.
Per altre informazioni su come Plug and Play IoT utilizza i modelli di dispositivo, vedere Guida per sviluppatori di dispositivi Plug and Play IoT e Guida per sviluppatori di servizi Plug and Play IoT.
Per definire un modello, usare DTDL (Digital Twins Definition Language). DTDL utilizza una variante JSON denominata JSON-LD. Il frammento di codice seguente mostra il modello per un dispositivo termostato che:
- Dispone di un ID modello univoco:
dtmi:com:example:Thermostat;1. - Invia i dati di telemetria sulla temperatura.
- Dispone di una proprietà scrivibile per impostare la temperatura di destinazione.
- Dispone di una proprietà di sola lettura per segnalare la temperatura massima dall'ultimo riavvio.
- Risponde a un comando che richiede temperature massime, minime e medie in un periodo di tempo.
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:Thermostat;1",
"@type": "Interface",
"displayName": "Thermostat",
"description": "Reports current temperature and provides desired temperature control.",
"contents": [
{
"@type": [
"Telemetry",
"Temperature"
],
"name": "temperature",
"displayName": "Temperature",
"description": "Temperature in degrees Celsius.",
"schema": "double",
"unit": "degreeCelsius"
},
{
"@type": [
"Property",
"Temperature"
],
"name": "targetTemperature",
"schema": "double",
"displayName": "Target Temperature",
"description": "Allows to remotely specify the desired target temperature.",
"unit": "degreeCelsius",
"writable": true
},
{
"@type": [
"Property",
"Temperature"
],
"name": "maxTempSinceLastReboot",
"schema": "double",
"unit": "degreeCelsius",
"displayName": "Max temperature since last reboot.",
"description": "Returns the max temperature since last device reboot."
},
{
"@type": "Command",
"name": "getMaxMinReport",
"displayName": "Get Max-Min report.",
"description": "This command returns the max, min and average temperature from the specified time to the current time.",
"request": {
"name": "since",
"displayName": "Since",
"description": "Period to return the max-min report.",
"schema": "dateTime"
},
"response": {
"name": "tempReport",
"displayName": "Temperature Report",
"schema": {
"@type": "Object",
"fields": [
{
"name": "maxTemp",
"displayName": "Max temperature",
"schema": "double"
},
{
"name": "minTemp",
"displayName": "Min temperature",
"schema": "double"
},
{
"name": "avgTemp",
"displayName": "Average Temperature",
"schema": "double"
},
{
"name": "startTime",
"displayName": "Start Time",
"schema": "dateTime"
},
{
"name": "endTime",
"displayName": "End Time",
"schema": "dateTime"
}
]
}
}
}
]
}
Il modello termostato presenta un'unica interfaccia. Negli esempi successivi di questo articolo, vengono illustrati modelli più complessi che utilizzano componenti ed ereditarietà.
Il presente articolo descrive come progettare e creare modelli personalizzati e illustra argomenti quali i tipi di dati, la struttura del modello e gli strumenti.
Per altre informazioni, vedere la specifica del linguaggio di definizione di Gemelli digitali.
Nota
IoT Central supporta attualmente DTDL v2 con un'estensione IoT Central.
Struttura del modello
Le proprietà, i dati di telemetria e i comandi vengono raggruppati in interfacce. Questa sezione illustra come utilizzare le interfacce per descrivere modelli semplici e complessi tramite componenti e ereditarietà.
ID modello
Ciascuna interfaccia dispone di un identificatore univoco del modello gemello digitale (DTMI). I modelli complessi utilizzano il DTMI per identificare i componenti. Le applicazioni possono usare i DTMI inviati dai dispositivi per individuare le definizioni di modello in un repository.
I DTMI devono usare la convenzione di denominazione seguente:
- Il prefisso DTMI è
dtmi:. - Il suffisso DTMI corrisponde al numero di versione per il modello, ad esempio
;2. - Il corpo del DTMI esegue il mapping alla cartella e al file nel repository del modello in cui è archiviato quest'ultimo. Il numero di versione fa parte del nome del file.
Ad esempio, il modello identificato dal DTMI dtmi:com:Example:Thermostat;2 viene archiviato nel file dtmi/com/example/thermostat-2.json.
Il frammento di codice seguente mostra la struttura di una definizione di interfaccia con il relativo DTMI univoco:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:Thermostat;2",
"@type": "Interface",
"displayName": "Thermostat",
"description": "Reports current temperature and provides desired temperature control.",
"contents": [
...
]
}
Nessun componente
Un modello semplice, ad esempio il termostato mostrato in precedenza, non utilizza componenti incorporati o a catena. I dati di telemetria, le proprietà e i comandi vengono definiti nel nodo contents dell'interfaccia.
L'esempio seguente mostra parte di un modello semplice che non utilizza componenti:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:Thermostat;1",
"@type": "Interface",
"displayName": "Thermostat",
"description": "Reports current temperature and provides desired temperature control.",
"contents": [
{
"@type": [
"Telemetry",
"Temperature"
],
"name": "temperature",
"displayName": "Temperature",
"description": "Temperature in degrees Celsius.",
"schema": "double",
"unit": "degreeCelsius"
},
{
"@type": [
"Property",
...
Strumenti quali Azure IoT Explorer e finestra di progettazione dei modelli di dispositivo IoT Central etichettano un'interfaccia autonoma, come il termostato, come componente predefinito.
Lo screenshot seguente mostra come il modello viene visualizzato nello strumento Azure IoT Explorer:
Lo screenshot seguente mostra come il modello viene visualizzato come componente predefinito nella finestra di progettazione dei modelli di dispositivo IoT Central. Per visualizzare il DTMI del modello, selezionare Visualizza identità:
L'ID modello viene archiviato in una proprietà del dispositivo gemello, come illustrato nello screenshot seguente:
Un modello DTDL senza componenti rappresenta una semplificazione utile per un dispositivo o un modulo IoT Edge con un singolo set di dati di telemetria, proprietà e comandi. Un modello che non utilizza componenti semplifica la migrazione di un dispositivo o un modulo esistente come dispositivo o modulo Plug and Play IoT. Si crea un modello DTDL, che descrive il dispositivo o il modulo effettivo senza la necessità di definire alcun componente.
Suggerimento
Un modulo può rappresentare un modulo di dispositivo o un modulo IoT Edge.
Riutilizzo
Esistono due modi per riutilizzare le definizioni di interfaccia.
- Usare più componenti in un modello per fare riferimento ad altre definizioni di interfaccia.
- Utilizzare l'ereditarietà per estendere le definizioni di interfaccia esistenti.
Più componenti
I componenti consentono di compilare un'interfaccia del modello come assembly di altre interfacce.
Ad esempio, l'interfaccia Termostato è definita come modello. È possibile incorporare questa interfaccia come uno o più componenti, quando si definisce il modello controller temperatura. Nell'esempio seguente, questi componenti vengono chiamati thermostat1 e thermostat2.
Per un modello DTDL con più componenti, sono disponibili due o più sezioni del componente. Ogni sezione ha @type impostato su Component e si riferisce esplicitamente a uno schema, come mostrato nel seguente frammento di codice:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:TemperatureController;1",
"@type": "Interface",
"displayName": "Temperature Controller",
"description": "Device with two thermostats and remote reboot.",
"contents": [
{
"@type": [
"Telemetry",
"DataSize"
],
"name": "workingSet",
"displayName": "Working Set",
"description": "Current working set of the device memory in KiB.",
"schema": "double",
"unit": "kibibyte"
},
{
"@type": "Property",
"name": "serialNumber",
"displayName": "Serial Number",
"description": "Serial number of the device.",
"schema": "string"
},
{
"@type": "Command",
"name": "reboot",
"displayName": "Reboot",
"description": "Reboots the device after waiting the number of seconds specified.",
"request": {
"name": "delay",
"displayName": "Delay",
"description": "Number of seconds to wait before rebooting the device.",
"schema": "integer"
}
},
{
"@type" : "Component",
"schema": "dtmi:com:example:Thermostat;1",
"name": "thermostat1",
"displayName": "Thermostat One",
"description": "Thermostat One of Two."
},
{
"@type" : "Component",
"schema": "dtmi:com:example:Thermostat;1",
"name": "thermostat2",
"displayName": "Thermostat Two",
"description": "Thermostat Two of Two."
},
{
"@type": "Component",
"schema": "dtmi:azure:DeviceManagement:DeviceInformation;1",
"name": "deviceInformation",
"displayName": "Device Information interface",
"description": "Optional interface with basic device hardware information."
}
]
}
Questo modello include tre componenti definiti nella sezione contenuto: due componenti Thermostat e un componente DeviceInformation. La sezione contenuto include anche le definizioni di proprietà, telemetria e comando.
Gli screenshot seguenti illustrano come viene visualizzato questo modello all'interno di IoT Central. Le definizioni di proprietà, telemetria e comando nel controller di temperatura vengono visualizzate nel Componente predefinito di primo livello. Le definizioni di proprietà, telemetria e comando di ciascun termostato vengono visualizzate nelle definizioni del componente:
Per informazioni su come scrivere codice del dispositivo che interagisce con i componenti, vedere Guida per sviluppatori di dispositivi Plug and Play IoT.
Per informazioni su come scrivere codice del servizio che interagisce con i componenti in un dispositivo, vedere Guida per sviluppatori di servizi Plug and Play IoT.
Ereditarietà
L'ereditarietà consente di riutilizzare le funzionalità in un'interfaccia di base per estendere le funzionalità di un'interfaccia. Ad esempio, diversi modelli di dispositivo possono condividere funzionalità comuni, come un numero di serie:
Il frammento di codice seguente mostra un modello DTML che utilizza la parola chiave extends per definire la relazione di ereditarietà illustrata nel diagramma precedente:
[
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:Thermostat;1",
"@type": "Interface",
"contents": [
{
"@type": "Telemetry",
"name": "temperature",
"schema": "double",
"unit": "degreeCelsius"
},
{
"@type": "Property",
"name": "targetTemperature",
"schema": "double",
"unit": "degreeCelsius",
"writable": true
}
],
"extends": [
"dtmi:com:example:baseDevice;1"
]
},
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:baseDevice;1",
"@type": "Interface",
"contents": [
{
"@type": "Property",
"name": "SerialNumber",
"schema": "double",
"writable": false
}
]
}
]
Lo screenshot seguente mostra questo modello nell'ambiente del modello di dispositivo IoT Central:
Quando si scrive codice lato servizio o dispositivo, il codice non deve eseguire alcuna operazione speciale per la gestione delle interfacce ereditate. Nell'esempio illustrato in questa sezione, il codice del dispositivo segnala il numero di serie come se fosse parte dell'interfaccia del termostato.
Suggerimenti
È possibile combinare componenti e ereditarietà durante la creazione di un modello. Il diagramma seguente mostra un modello thermostat che eredita da un'interfaccia baseDevice. L'interfaccia baseDevice dispone di un componente che eredita da un'altra interfaccia:
Il frammento di codice seguente mostra un modello DTML che utilizza le parole chiave extends e component per definire la relazione di ereditarietà e l'utilizzo dei componenti illustrati nel diagramma precedente:
[
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:Thermostat;1",
"@type": "Interface",
"contents": [
{
"@type": "Telemetry",
"name": "temperature",
"schema": "double",
"unit": "degreeCelsius"
},
{
"@type": "Property",
"name": "targetTemperature",
"schema": "double",
"unit": "degreeCelsius",
"writable": true
}
],
"extends": [
"dtmi:com:example:baseDevice;1"
]
},
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:baseDevice;1",
"@type": "Interface",
"contents": [
{
"@type": "Property",
"name": "SerialNumber",
"schema": "double",
"writable": false
},
{
"@type" : "Component",
"schema": "dtmi:com:example:baseComponent;1",
"name": "baseComponent"
}
]
}
]
Tipo di dati
Usare i tipi di dati per definire i dati di telemetria, le proprietà e i parametri di comando. I tipi di dati possono essere primitivi o complessi. I tipi di dati complessi utilizzano tipi primitivi o altri tipi complessi. La profondità massima per i tipi complessi è di cinque livelli.
Tipi primitivi
La tabella seguente illustra il set di tipi primitivi che è possibile usare:
| Tipo primitivo | Descrizione |
|---|---|
boolean |
Valore booleano |
date |
Data completa, come definita nella sezione 5.6 di RFC 3339 |
dateTime |
Data e ora definite in RFC 3339 |
double |
Virgola mobile IEEE a 8 byte |
duration |
Durata in formato ISO 8601 |
float |
Virgola mobile IEEE a 4 byte |
integer |
Intero con segno a 4 byte |
long |
Intero con segno a 8 byte |
string |
Stringa UTF8 |
time |
Tempo pieno come definito nella sezione 5.6 di RFC 3339 |
Il frammento di codice seguente mostra una definizione di telemetria di esempio che utilizza il tipo double nel campo schema:
{
"@type": "Telemetry",
"name": "temperature",
"displayName": "Temperature",
"schema": "double"
}
Tipi di dati complessi
I tipi di dati complessi sono una matrice, un'enumerazione, una mappa, un oggetto o uno dei tipi geospaziali.
Matrici
Una matrice è un tipo di dati indicizzabile in cui tutti gli elementi sono dello stesso tipo. Il tipo di elemento può essere primitivo o complesso.
Il frammento di codice seguente mostra una definizione di telemetria di esempio che utilizza il tipo Array nel campo schema. Gli elementi della matrice sono booleani:
{
"@type": "Telemetry",
"name": "ledState",
"schema": {
"@type": "Array",
"elementSchema": "boolean"
}
}
Enumerazioni
Un'enumerazione descrive un tipo con un set di etichette denominate che eseguono il mapping ai valori. I valori possono essere numeri interi o stringhe, ma le etichette sono sempre stringhe.
Il frammento di codice seguente mostra una definizione di telemetria di esempio che utilizza il tipo Enum nel campo schema. I valori nell'enumerazione sono numeri interi:
{
"@type": "Telemetry",
"name": "state",
"schema": {
"@type": "Enum",
"valueSchema": "integer",
"enumValues": [
{
"name": "offline",
"displayName": "Offline",
"enumValue": 1
},
{
"name": "online",
"displayName": "Online",
"enumValue": 2
}
]
}
}
Mappe
Una mappa è un tipo con coppie chiave-valore in cui tutti i valori sono dello stesso tipo. La chiave in una mappa deve essere una stringa. I valori di una mappa possono essere di qualsiasi tipo, incluso un altro tipo complesso.
Il frammento di codice seguente mostra una definizione di proprietà di esempio che utilizza il tipo Map nel campo schema. I valori nella mappa sono stringhe:
{
"@type": "Property",
"name": "modules",
"writable": true,
"schema": {
"@type": "Map",
"mapKey": {
"name": "moduleName",
"schema": "string"
},
"mapValue": {
"name": "moduleState",
"schema": "string"
}
}
}
Oggetti
Un tipo di oggetto è costituito da campi denominati. I tipi dei campi in una mappa oggetti possono essere primitivi o complessi.
Il frammento di codice seguente mostra una definizione di telemetria di esempio che utilizza il tipo Object nel campo schema. I campi nell'oggetto sono i tipi dateTime, duration e string:
{
"@type": "Telemetry",
"name": "monitor",
"schema": {
"@type": "Object",
"fields": [
{
"name": "start",
"schema": "dateTime"
},
{
"name": "interval",
"schema": "duration"
},
{
"name": "status",
"schema": "string"
}
]
}
}
Tipi geospaziali
DTDL fornisce un set di tipi geospaziali, basati su GeoJSON, per la modellazione di strutture di dati geografiche: point, multiPoint lineString, multiLineString, polygon e multiPolygon. Questi tipi sono strutture nidificate predefinite di matrici, oggetti ed enumerazioni.
Il frammento di codice seguente mostra una definizione di telemetria di esempio che utilizza il tipo point nel campo schema:
{
"@type": "Telemetry",
"name": "location",
"schema": "point"
}
Poiché i tipi geospaziali sono basati su matrici, non possono essere attualmente usati nelle definizioni delle proprietà.
Tipi semantici
Il tipo di dati di una proprietà o di una definizione di telemetria specifica il formato dei dati che un dispositivo scambia con un servizio. Il tipo semantico fornisce informazioni sui dati di telemetria e sulle proprietà che un'applicazione può utilizzare per determinare come elaborare o visualizzare un valore. Ciascun tipo semantico ha una o più unità associate. Ad esempio, Celsius e Fahrenheit sono le unità per il tipo semantico di temperatura. I dashboard e le analisi di IoT Central possono utilizzare le informazioni sul tipo semantico per determinare come tracciare i dati di telemetria o i valori delle proprietà e le unità di visualizzazione. Per informazioni su come usare il parser del modello per leggere i tipi semantici, vedere Informazioni sul parser del modello Gemelli digitali.
Il frammento di codice seguente mostra una definizione di telemetria di esempio che include informazioni sul tipo semantico. Il tipo semantico Temperature viene aggiunto alla matrice @type e il valoreunit, degreeCelsius è una delle unità valide per il tipo semantico:
{
"@type": [
"Telemetry",
"Temperature"
],
"name": "temperature",
"schema": "double",
"unit": "degreeCelsius"
}
Localizzazione
Le applicazioni, come IoT Central, utilizzano le informazioni contenute nel modello per creare dinamicamente un'interfaccia utente intorno ai dati scambiati con un dispositivo IoT Plug and Play. Ad esempio, i riquadri di un dashboard possono visualizzare nomi e descrizioni per dati di telemetria, proprietà e comandi.
I campi facoltativi description e displayName nel modello contengono stringhe destinate all'uso in un'interfaccia utente. Questi campi possono contenere stringhe localizzate, che un'applicazione può utilizzare per eseguire il rendering di un'interfaccia utente localizzata.
Il frammento di codice seguente mostra una definizione di telemetria della temperatura di esempio che include stringhe localizzate:
{
"@type": [
"Telemetry",
"Temperature"
],
"description": {
"en": "Temperature in degrees Celsius.",
"it": "Temperatura in gradi Celsius."
},
"displayName": {
"en": "Temperature",
"it": "Temperatura"
},
"name": "temperature",
"schema": "double",
"unit": "degreeCelsius"
}
L'aggiunta di stringhe localizzate è facoltativa. Nell'esempio seguente è presente un solo linguaggio predefinito:
{
"@type": [
"Telemetry",
"Temperature"
],
"description": "Temperature in degrees Celsius.",
"displayName": "Temperature",
"name": "temperature",
"schema": "double",
"unit": "degreeCelsius"
}
Ciclo di vita e strumenti
Le quattro fasi del ciclo di vita per un modello di dispositivo sono autore, pubblicazione, utilizzo e versione:
Autore
I modelli di dispositivo DTML sono documenti JSON che è possibile creare in un editor di testo. Tuttavia, in IoT Central è possibile utilizzare l'ambiente GUI del modello di dispositivo per creare un modello DTML. In IoT Central è possibile:
- Creare interfacce che definiscono proprietà, dati di telemetria e comandi.
- Usare i componenti per assemblare più interfacce.
- Definire le relazioni di ereditarietà tra le interfacce.
- Importare ed esportare i file di modello DTML.
Per altre informazioni, vedere Definire un nuovo tipo di dispositivo IoT nell'applicazione Azure IoT Central.
È disponibile un'estensione di creazione DTDL per VS Code che supporta sia DTDL v2 che DTDL v3.
Per installare l'estensione DTDL per VS Code, passare all'editor DTDL per Visual Studio Code. È anche possibile cercare DTDL nella visualizzazione Estensioni in VS Code.
Dopo aver installato l'estensione, usarla per creare i file di modello DTDL all'interno di VS Code:
L'estensione fornisce la convalida della sintassi nei file del modello DTDL, evidenziando gli errori come illustrato nello screenshot seguente:
Usare IntelliSense e completamento automatico quando si modificano i modelli DTDL:
Creare una nuova interfaccia DTDL. Il comando DTDL: Create Interface crea un file JSON con una nuova interfaccia. L'interfaccia include esempi di dati di telemetria, proprietà e definizioni di comando.
Utilizzo
Le applicazioni, ad esempio IoT Central, utilizzano modelli di dispositivo. In IoT Central, un modello fa parte del modello di dispositivo che descrive le funzionalità di quest'ultimo. IoT Central usa il modello di dispositivo per creare dinamicamente un'interfaccia utente per il dispositivo, inclusi dashboard e analisi.
Nota
IoT Central definisce alcune estensioni per il linguaggio DTDL. Per altre informazioni, vedere Estensione IoT Central.
Una soluzione personalizzata può usare il parser del modello Gemelli digitali per comprendere le funzionalità di un dispositivo che implementa il modello. Per ulteriori informazioni, consultare Usare i modelli Plug and Play IoT in una soluzione IoT.
Versione
Per garantire che i dispositivi e le soluzioni lato server che utilizzano modelli continuino a funzionare, i modelli pubblicati non sono modificabili.
DTMI include un numero di versione che è possibile usare per creare più versioni di un modello. I dispositivi e le soluzioni lato server possono utilizzare la versione specifica per cui sono stati progettati.
IoT Central implementa più regole di controllo delle versioni per i modelli di dispositivo. Se si esegue la versione di un modello di dispositivo e il relativo modello in IoT Central, è possibile eseguire la migrazione dei dispositivi dalle versioni precedenti a quelle successive. Tuttavia, i dispositivi migrati non possono utilizzare nuove funzionalità senza un aggiornamento del firmware. Per altre informazioni, vedere Modificare un modello di dispositivo.
Pubblicazione
A partire da febbraio 2024, il programma Azure Certified Device è stato ritirato. Pertanto, Microsoft non accetta più consegne di modelli DTDL al repository di modelli plug and play di Azure IoT.
Se si vuole configurare il proprio repository di modelli, è possibile usare il repository degli strumenti dei modelli Plug and Play Azure IoT. Questo repository include il codice per lo strumento dell'interfaccia della riga di comando dmr-client in grado di convalidare, importare ed espandere i modelli DTDL. Questo strumento consente anche di indicizzare i repository dei modelli che seguono le convenzioni del repository del modello di dispositivo.
Limiti e vincoli
L'elenco seguente riepiloga alcuni vincoli chiave e limiti per i modelli:
- Attualmente, la profondità massima per matrici, mappe e oggetti è di cinque livelli.
- Non è possibile utilizzare matrici nelle definizioni delle proprietà.
- È possibile estendere le interfacce a una profondità di 10 livelli.
- Un'interfaccia può estendere al massimo altre due.
- Un componente non può contenerne un altro.
Informazioni sul parser del modello Gemelli digitali
Il linguaggio DTDL (Digital Twins Definition Language) è descritto nella specifica DTDL. Gli utenti possono usare il pacchetto NuGet del parser del modello gemelli digitali per convalidare ed eseguire query su un modello DTDL v2 o v3. Il modello DTDL può essere definito in più file.
Installare il parser del modello DTDL
Il parser è disponibile in NuGet.org con ID: DTDLParser. Per installare il parser, usare qualsiasi gestione pacchetti NuGet compatibile, ad esempio quella di Visual Studio o dell'interfaccia della riga di comando dotnet.
dotnet add package DTDLParser
Nota
Al momento della redazione di questo documento, la versione del parser è 1.0.52.
Usare il parser per convalidare ed esaminare un modello
DTDLParser è una libreria che si può usare per:
- Determinare se uno o più modelli sono validi in base alle specifiche della lingua v2 o v3.
- Identificare errori di modellazione specifici.
- Esaminare il contenuto del modello.
Un modello può essere composto da una o più interfacce descritte nei file JSON. È possibile usare il parser per caricare tutti i file che definiscono un modello e quindi convalidare tutti i file nel loro insieme, inclusi eventuali riferimenti tra i file.
Il repository DTDLParser per .NET include gli esempi seguenti che illustrano l'uso del parser:
- DTDLParserResolveSample mostra come analizzare un'interfaccia con riferimenti esterni, risolvere le dipendenze usando il client
Azure.IoT.ModelsRepository. - DTDLParserJSInteropSample illustra come usare il parser DTDL da JavaScript in esecuzione nel browser, tramite .NET JSInterop.
Il repository DTDLParser per .NET include anche una raccolta di esercitazioni che illustrano come utilizzare il parser per convalidare ed esaminare i modelli.
L'API del parser del modello consente a molti scenari di automatizzare o convalidare le attività che dipendono dai modelli DTDL. Ad esempio, è possibile creare dinamicamente un'interfaccia utente dalle informazioni nel modello.
Passaggi successivi
Dopo aver appreso la modellazione dei dispositivi, è possibile consultare le seguenti risorse: