guida alla modellazione di Plug and Play IoT

  • Articolo

Al centro di Plug and Play IoT, è un modello di dispositivo che descrive le funzionalità di un dispositivo a un'applicazione Plug and Play IoT abilitata. Questo modello è strutturato come un set di interfacce che definiscono:

  • 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.
  • Campi di telemetria che definiscono i dati generati da un dispositivo, indipendentemente dal fatto che i dati siano un flusso regolare di letture dei 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 usa i modelli di dispositivo, vedere Plug and Play IoT guida per sviluppatori di dispositivi e guida per sviluppatori di servizi Plug and Play IoT.

Per definire un modello, usare DTDL (Digital Twins Definition Language). DTDL usa una variante JSON denominata JSON-LD. Il frammento di codice seguente mostra il modello per un dispositivo termostato che:

  • Ha 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 ha un'unica interfaccia. Negli esempi successivi di questo articolo vengono illustrati modelli più complessi che usano componenti ed ereditarietà.

Questo articolo descrive come progettare e creare modelli personalizzati e illustra argomenti come 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 descrive come usare le interfacce per descrivere modelli semplici e complessi usando componenti e ereditarietà.

ID modello

Ogni interfaccia ha un identificatore univoco del modello di gemelli digitali (DTMI). I modelli complessi usano DTMI per identificare i componenti. Le applicazioni possono usare le DTMI inviate dai dispositivi per individuare le definizioni di modello in un repository.

Le DTMI devono usare la convenzione di denominazione seguente:

  • Il prefisso DTMI è dtmi:.
  • Il suffisso DTMI è il numero di versione per il modello, ;2ad esempio .
  • Il corpo del DTMI esegue il mapping alla cartella e al file nel repository del modello in cui è archiviato il modello. 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 usa componenti incorporati o a catena. I dati di telemetria, le proprietà e i comandi vengono definiti nel contents nodo dell'interfaccia.

L'esempio seguente mostra parte di un modello semplice che non usa 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 come Azure IoT Explorer e Progettazione 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:

Screenshot che mostra il componente predefinito 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. Selezionare Visualizza identità per visualizzare il DTMI del modello:

Screenshot che mostra il modello Thermostat nello strumento di progettazione modelli di dispositivo IoT Central.

L'ID modello viene archiviato in una proprietà del dispositivo gemello come illustrato nello screenshot seguente:

Screenshot dello strumento Azure IoT Explorer che mostra l'ID modello in una proprietà del gemello digitale.

Un modello DTDL senza componenti è 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 usa 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ò essere 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.
  • Usare 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 Thermostat è definita come modello. È possibile incorporare questa interfaccia come uno o più componenti quando si definisce il modello Temperature Controller. 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 è @type impostata su Component e fa riferimento in modo esplicito a uno schema, come illustrato nel frammento di codice seguente:

{
  "@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 Thermostat componenti e un DeviceInformation componente. La sezione contenuto include anche le definizioni di proprietà, telemetria e comando.

Gli screenshot seguenti illustrano come viene visualizzato questo modello in 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 per ogni termostato vengono visualizzate nelle definizioni dei componenti:

Screenshot che mostra il modello di dispositivo temperature controller in IoT Central.

Screenshot che mostra i componenti del termostato nel modello di dispositivo del controller di temperatura in IoT Central.

Per informazioni su come scrivere codice del dispositivo che interagisce con i componenti, vedere Plug and Play IoT guida per sviluppatori di dispositivi.

Per informazioni su come scrivere codice del servizio che interagisce con i componenti in un dispositivo, vedere Plug and Play IoT guida per sviluppatori di servizi.

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, ad esempio un numero di serie:

Diagramma che mostra un esempio di ereditarietà in un modello di dispositivo. Un'interfaccia Thermostat e un'interfaccia del controller di flusso condividono entrambe le funzionalità di un'interfaccia di base.

Il frammento di codice seguente mostra un modello DTML che usa la extends parola chiave 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:

Screenshot che mostra l'ereditarietà dell'interfaccia in IoT Central.

Quando si scrive codice lato servizio o dispositivo, il codice non deve eseguire alcuna operazione speciale per gestire le interfacce ereditate. Nell'esempio illustrato in questa sezione il codice del dispositivo segnala il numero di serie come se fa parte dell'interfaccia del termostato.

Suggerimenti

È possibile combinare componenti e ereditarietà quando si crea un modello. Il diagramma seguente mostra un thermostat modello che eredita da un'interfaccia baseDevice . L'interfaccia baseDevice ha un componente che eredita da un'altra interfaccia:

Diagramma che mostra un modello che usa sia componenti che ereditarietà.

Il frammento di codice seguente mostra un modello DTML che usa le extends parole chiave 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 dati di telemetria, proprietà e parametri di comando. I tipi di dati possono essere primitivi o complessi. I tipi di dati complessi usano primitive 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 definita nella sezione 5.6 di RFC 3339
dateTime Data e ora definite in RFC 3339
double Oggetto I edizione Enterprise E a virgola mobile a 8 byte
duration Durata in formato ISO 8601
float Oggetto I edizione Enterprise E a virgola mobile 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 usa il double tipo nel schema campo :

{
  "@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 un tipo primitivo o complesso.

Il frammento di codice seguente mostra una definizione di telemetria di esempio che usa il Array tipo nel schema campo . 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 usa il Enum tipo nel schema campo . 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 hanno lo 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 usa il Map tipo nel schema campo . 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 tipi primitivi o complessi.

Il frammento di codice seguente mostra una definizione di telemetria di esempio che usa il Object tipo nel schema campo . I campi nell'oggetto sono dateTime, duratione string tipi:

{
  "@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, multiPointlineString, 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 usa il point tipo nel schema campo :

{
  "@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ò usare per determinare come elaborare o visualizzare un valore. Ogni tipo semantico ha una o più unità associate. Ad esempio, celsius e fahrenheit sono unità per il tipo semantico di temperatura. I dashboard e le analisi di IoT Central possono usare 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 di gemelli digitali.

Il frammento di codice seguente mostra una definizione di telemetria di esempio che include informazioni sul tipo semantico. Il tipo Temperature semantico viene aggiunto alla @type matrice e il unit valore degreeCelsius è una delle unità valide per il tipo semantico:

{
  "@type": [
    "Telemetry",
    "Temperature"
  ],
  "name": "temperature",
  "schema": "double",
  "unit": "degreeCelsius"
}

Localizzazione

Le applicazioni, ad esempio IoT Central, usano le informazioni nel modello per creare dinamicamente un'interfaccia utente intorno ai dati scambiati con un dispositivo Plug and Play IoT. Ad esempio, i riquadri in 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ò usare 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 una sola lingua predefinita:

{
  "@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, uso e versione:

Autore

I modelli di dispositivo DTML sono documenti JSON che è possibile creare in un editor di testo. Tuttavia, in IoT Central è possibile usare 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 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.

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 file di modello DTDL in VS Code:

  • L'estensione fornisce la convalida della sintassi nei file del modello DTDL, evidenziando gli errori come illustrato nello screenshot seguente:

    Screenshot che mostra la convalida del modello DTDL in VS Code.

  • Usare intellisense e completamento automatico quando si modificano i modelli DTDL:

    Screenshot che mostra intellisense per i modelli DTDL in VS Code.

  • 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, usano modelli di dispositivo. In IoT Central un modello fa parte del modello di dispositivo che descrive le funzionalità del dispositivo. 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 di gemelli digitali per comprendere le funzionalità di un dispositivo che implementa il modello. Per altre informazioni, vedere Usare modelli Plug and Play IoT in una soluzione IoT.

Versione

Per garantire che i dispositivi e le soluzioni lato server che usano 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 usare la versione specifica che sono state progettate per l'uso.

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 alle versioni successive. Tuttavia, i dispositivi migrati non possono usare nuove funzionalità senza un aggiornamento del firmware. Per altre informazioni, vedere Modificare un modello di dispositivo.

Pagina

A partire da febbraio 2024, il programma Azure Certified Device è stato ritirato. Pertanto, Microsoft non accetta più invii di modelli DTDL alrepository di modelli plug and play IoT di Azure.

Se si vuole configurare il proprio repository di modelli, è possibile usare il repository degli strumenti dei modelli plug and play di Azure IoT. Questo repository include il codice per lo strumento dell'interfaccia della dmr-client riga di comando in grado di convalidare, importare ed espandere 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 usare matrici nelle definizioni delle proprietà.
  • È possibile estendere le interfacce a una profondità di 10 livelli.
  • Un'interfaccia può estendersi al massimo due altre interfacce.
  • Un componente non può contenere un altro componente.

Passaggi successivi

Dopo aver appreso la modellazione dei dispositivi, ecco alcune altre risorse: