Przewodnik modelowania technologii IoT Plug and Play

Podstawowym elementem usługi IoT Plug and Play jest model urządzenia opisujący możliwości urządzenia w aplikacji IoT Plug and Play. Ten model jest ustrukturyzowany jako zestaw interfejsów, które definiują:

• Właściwości reprezentujące stan tylko do odczytu lub zapisywalny urządzenia lub innej jednostki. Na przykład numer seryjny urządzenia może być właściwością tylko do odczytu, a temperatura docelowa termostatu może być właściwością zapisywalną.
• Pola telemetryczne definiujące dane emitowane przez urządzenie, niezależnie od tego, czy dane są zwykłym strumieniem odczytów czujników, okazjonalnym błędem, czy komunikatem informacyjnym.
• Polecenia opisujące funkcję lub operację, którą można wykonać na urządzeniu. Na przykład polecenie może ponownie uruchomić bramę lub zrobić zdjęcie przy użyciu aparatu zdalnego.

Aby dowiedzieć się więcej o sposobie korzystania z modeli urządzeń przez usługę IoT Plug and Play, zobacz Przewodnik dewelopera dotyczący technologii IoT Plug and Play oraz Przewodnik dla deweloperów usługi IoT Plug and Play.

Aby zdefiniować model, należy użyć języka Digital Twins Definition Language (DTDL). Język DTDL używa wariantu JSON o nazwie JSON-LD. Poniższy fragment kodu przedstawia model urządzenia termostatu, który:

• Ma unikatowy identyfikator modelu: dtmi:com:example:Thermostat;1.
• Wysyła dane telemetryczne temperatury.
• Ma właściwość zapisywalną, aby ustawić temperaturę docelową.
• Ma właściwość tylko do odczytu, aby zgłosić maksymalną temperaturę od ostatniego ponownego uruchomienia.
• Odpowiada na polecenie, które żąda maksymalnej, minimalnej i średniej temperatury w danym okresie.

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

Model termostatu ma jeden interfejs. W kolejnych przykładach w tym artykule przedstawiono bardziej złożone modele korzystające ze składników i dziedziczenia.

W tym artykule opisano sposób projektowania i tworzenia własnych modeli oraz opisano tematy, takie jak typy danych, struktura modelu i narzędzia.

Aby dowiedzieć się więcej, zobacz specyfikację języka definicji usługi Digital Twins.

Uwaga

Usługa IoT Central obecnie obsługuje język DTDL w wersji 2 z rozszerzeniem usługi IoT Central.

Struktura modelu

Właściwości, dane telemetryczne i polecenia są grupowane w interfejsy. W tej sekcji opisano sposób używania interfejsów do opisywania prostych i złożonych modeli przy użyciu składników i dziedziczenia.

Identyfikatory modeli

Każdy interfejs ma unikatowy identyfikator modelu cyfrowej reprezentacji bliźniaczej (DTMI). Złożone modele używają interfejsów DTMI do identyfikowania składników. Aplikacje mogą używać identyfikatorów DTMI wysyłanych przez urządzenia do lokalizowania definicji modelu w repozytorium.

Interfejsy DTMI powinny używać następującej konwencji nazewnictwa:

• Prefiks DTMI to dtmi:.
• Sufiks DTMI to numer wersji modelu, taki jak ;2.
• Treść jednostki DTMI jest mapowana na folder i plik w repozytorium modelu, w którym jest przechowywany model. Numer wersji jest częścią nazwy pliku.

Na przykład model zidentyfikowany przez usługę DTMI dtmi:com:Example:Thermostat;2 jest przechowywany w pliku dtmi/com/example/thermostat-2.json .

Poniższy fragment kodu przedstawia konspekt definicji interfejsu z unikatowym kodem DTMI:

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

Brak składników

Prosty model, taki jak pokazany wcześniej termostat, nie używa osadzonych ani kaskadowych składników. Telemetria, właściwości i polecenia są definiowane w węźle contents interfejsu.

Poniższy przykład przedstawia część prostego modelu, który nie używa składników:

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

Narzędzia, takie jak Azure IoT Explorer i projektant szablonu urządzenia usługi IoT Central, etykietą autonomicznego interfejsu, takiego jak termostat jako składnik domyślny.

Poniższy zrzut ekranu przedstawia sposób wyświetlania modelu w narzędziu Azure IoT Explorer:

Poniższy zrzut ekranu przedstawia sposób wyświetlania modelu jako składnika domyślnego w projektancie szablonów urządzeń usługi IoT Central. Wybierz pozycję Wyświetl tożsamość , aby wyświetlić jednostki DTMI modelu:

Identyfikator modelu jest przechowywany we właściwości bliźniaczej reprezentacji urządzenia, jak pokazano na poniższym zrzucie ekranu:

Model DTDL bez składników jest przydatnym uproszczeniem dla urządzenia lub modułu usługi IoT Edge z pojedynczym zestawem danych telemetrycznych, właściwości i poleceń. Model, który nie korzysta ze składników, ułatwia migrowanie istniejącego urządzenia lub modułu jako urządzenia lub modułu usługi IoT Plug and Play — tworzysz model DTDL opisujący rzeczywiste urządzenie lub moduł bez konieczności definiowania żadnych składników.

Napiwek

Moduł może być modułem urządzenia lub modułem usługi IoT Edge.

Ponowne użycie

Istnieją dwa sposoby ponownego użycia definicji interfejsu.

• Używanie wielu składników w modelu do odwołowania się do innych definicji interfejsu.
• Użyj dziedziczenia, aby rozszerzyć istniejące definicje interfejsu.

Wiele składników

Składniki umożliwiają tworzenie interfejsu modelu jako zestawu innych interfejsów.

Na przykład interfejs termostatu jest definiowany jako model. Ten interfejs można dołączyć jako co najmniej jeden składnik podczas definiowania modelu kontrolera temperatury. W poniższym przykładzie te składniki są wywoływane thermostat1 i thermostat2.

W przypadku modelu DTDL z wieloma składnikami istnieją co najmniej dwie sekcje składowe. Każda sekcja ma @type ustawioną wartość Component i jawnie odwołuje się do schematu, jak pokazano w poniższym fragmencie kodu:

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

Ten model ma trzy składniki zdefiniowane w sekcji zawartości — dwa Thermostat składniki i DeviceInformation składnik. Sekcja zawartości zawiera również definicje właściwości, telemetrii i poleceń.

Na poniższych zrzutach ekranu przedstawiono sposób wyświetlania tego modelu w usłudze IoT Central. Właściwości, telemetrii i definicje poleceń w kontrolerze temperatury są wyświetlane w składniku domyślnym najwyższego poziomu. Definicje właściwości, telemetrii i poleceń dla każdego termostatu są wyświetlane w definicjach składników:

Aby dowiedzieć się, jak napisać kod urządzenia, który współdziała ze składnikami, zobacz Przewodnik dewelopera urządzeń IoT Plug and Play.

Aby dowiedzieć się, jak napisać kod usługi, który współdziała ze składnikami na urządzeniu, zobacz Przewodnik dewelopera usługi IoT Plug and Play.

Dziedziczenie

Dziedziczenie umożliwia ponowne użycie funkcji w interfejsach podstawowych w celu rozszerzenia możliwości interfejsu. Na przykład kilka modeli urządzeń może współdzielić typowe możliwości, takie jak numer seryjny:

Poniższy fragment kodu przedstawia model DTML, który używa słowa kluczowego extends do zdefiniowania relacji dziedziczenia pokazanej na poprzednim diagramie:

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

Poniższy zrzut ekranu przedstawia ten model w środowisku szablonu urządzenia usługi IoT Central:

Podczas pisania kodu po stronie urządzenia lub usługi kod nie musi wykonywać żadnych specjalnych czynności w celu obsługi odziedziczonych interfejsów. W przykładzie przedstawionym w tej sekcji kod urządzenia raportuje numer seryjny tak, jakby był częścią interfejsu termostatu.

Wskazówki

Składniki i dziedziczenie można łączyć podczas tworzenia modelu. Na poniższym diagramie przedstawiono thermostat model dziedziczący z interfejsu baseDevice . Interfejs baseDevice ma składnik, który sam dziedziczy z innego interfejsu:

Poniższy fragment kodu przedstawia model DTML, który używa extends słów kluczowych i component do zdefiniowania relacji dziedziczenia i użycia składnika pokazanego na poprzednim diagramie:

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

Typy danych

Użyj typów danych, aby zdefiniować dane telemetryczne, właściwości i parametry polecenia. Typy danych mogą być pierwotne lub złożone. Złożone typy danych używają typów pierwotnych lub innych typów złożonych. Maksymalna głębokość dla typów złożonych wynosi pięć poziomów.

Typy pierwotne

W poniższej tabeli przedstawiono zestaw typów pierwotnych, których można użyć:

Typ pierwotny	opis
boolean	Wartość logiczna
date	Pełna data zdefiniowana w sekcji 5.6 RFC 3339
dateTime	Data-godzina zdefiniowana w dokumencie RFC 3339
double	Zmiennoprzecinkowa IEEE 8-bajtowa
duration	Czas trwania w formacie ISO 8601
float	Zmiennoprzecinkowa IEEE 4-bajtowa
integer	Podpisana liczba całkowita 4-bajtowa
long	Podpisana liczba całkowita 8-bajtowa
string	Ciąg UTF8
time	Pełny czas zdefiniowany w sekcji 5.6 RFC 3339

Poniższy fragment kodu przedstawia przykładową definicję telemetrii, która używa double typu w schema polu:

{
  "@type": "Telemetry",
  "name": "temperature",
  "displayName": "Temperature",
  "schema": "double"
}

Złożone typy danych

Złożone typy danych to jedna z tablic, wyliczenia, mapy, obiektu lub jednego z typów geoprzestrzennych.

Tablice

Tablica jest indeksowalnym typem danych, w którym wszystkie elementy są tego samego typu. Typ elementu może być typem pierwotnym lub złożonym.

Poniższy fragment kodu przedstawia przykładową definicję telemetrii, która używa Array typu w schema polu. Elementy tablicy są wartościami logicznymi:

{
  "@type": "Telemetry",
  "name": "ledState",
  "schema": {
    "@type": "Array",
    "elementSchema": "boolean"
  }
}

Wyliczenia

Wyliczenie opisuje typ z zestawem nazwanych etykiet mapujących na wartości. Wartości mogą być liczbami całkowitymi lub ciągami, ale etykiety są zawsze ciągami.

Poniższy fragment kodu przedstawia przykładową definicję telemetrii, która używa Enum typu w schema polu. Wartości w wyliczenia są liczbami całkowitymi:

{
  "@type": "Telemetry",
  "name": "state",
  "schema": {
    "@type": "Enum",
    "valueSchema": "integer",
    "enumValues": [
      {
        "name": "offline",
        "displayName": "Offline",
        "enumValue": 1
      },
      {
        "name": "online",
        "displayName": "Online",
        "enumValue": 2
      }
    ]
  }
}

Maps

Mapa jest typem z parami klucz-wartość, w których wszystkie wartości mają ten sam typ. Klucz na mapie musi być ciągiem. Wartości na mapie mogą być dowolnym typem, w tym innym typem złożonym.

Poniższy fragment kodu przedstawia przykładową definicję właściwości, która używa Map typu w schema polu. Wartości na mapie to ciągi:

{
  "@type": "Property",
  "name": "modules",
  "writable": true,
  "schema": {
    "@type": "Map",
    "mapKey": {
      "name": "moduleName",
      "schema": "string"
    },
    "mapValue": {
      "name": "moduleState",
      "schema": "string"
    }
  }
}

Obiekty

Typ obiektu składa się z nazwanych pól. Typy pól na mapie obiektów mogą być typami pierwotnymi lub złożonymi.

Poniższy fragment kodu przedstawia przykładową definicję telemetrii, która używa Object typu w schema polu. Pola w obiekcie to dateTime, durationi string typy:

{
  "@type": "Telemetry",
  "name": "monitor",
  "schema": {
    "@type": "Object",
    "fields": [
      {
        "name": "start",
        "schema": "dateTime"
      },
      {
        "name": "interval",
        "schema": "duration"
      },
      {
        "name": "status",
        "schema": "string"
      }
    ]
  }
}

Typy geoprzestrzenne

Język DTDL udostępnia zestaw typów geoprzestrzennych opartych na formacie GeoJSON na potrzeby modelowania struktur danych geograficznych: point, , lineStringmultiPoint, multiLineString, polygoni multiPolygon. Te typy to wstępnie zdefiniowane zagnieżdżone struktury tablic, obiektów i wyliczenia.

Poniższy fragment kodu przedstawia przykładową definicję telemetrii, która używa point typu w schema polu:

{
  "@type": "Telemetry",
  "name": "location",
  "schema": "point"
}

Ponieważ typy geoprzestrzenne są oparte na tablicy, nie można ich obecnie używać w definicjach właściwości.

Typy semantyczne

Typ danych właściwości lub definicji telemetrii określa format danych wymienianych przez urządzenie z usługą. Typ semantyczny zawiera informacje o telemetrii i właściwościach, których aplikacja może użyć do określenia sposobu przetwarzania lub wyświetlania wartości. Każdy typ semantyczny ma co najmniej jedną skojarzona jednostka. Na przykład stopnie Celsjusza i fahrenheit są jednostkami typu semantycznego temperatury. Pulpity nawigacyjne i analiza usługi IoT Central mogą używać informacji o typie semantycznym do określania sposobu kreślenia danych telemetrycznych lub wartości właściwości i jednostek wyświetlania. Aby dowiedzieć się, jak używać analizatora modeli do odczytywania typów semantycznych, zobacz Omówienie analizatora modelu usługi Digital Twins.

Poniższy fragment kodu przedstawia przykładową definicję telemetrii, która zawiera informacje o typie semantycznym. Typ Temperature semantyczny jest dodawany do @type tablicy, a unit wartość degreeCelsius jest jedną z prawidłowych jednostek dla typu semantycznego:

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

Lokalizacja

Aplikacje, takie jak IoT Central, używają informacji w modelu do dynamicznego tworzenia interfejsu użytkownika wokół danych wymienianych za pomocą urządzenia IoT Plug and Play. Na przykład kafelki na pulpicie nawigacyjnym mogą wyświetlać nazwy i opisy telemetrii, właściwości i poleceń.

Opcjonalne description i displayName pola w modelu przechowują ciągi przeznaczone do użycia w interfejsie użytkownika. Te pola mogą przechowywać zlokalizowane ciągi, których aplikacja może używać do renderowania zlokalizowanego interfejsu użytkownika.

Poniższy fragment kodu przedstawia przykładową definicję telemetrii temperatury obejmującą zlokalizowane ciągi:

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

Dodawanie zlokalizowanych ciągów jest opcjonalne. W poniższym przykładzie jest dostępny tylko jeden, domyślny język:

{
  "@type": [
    "Telemetry",
    "Temperature"
  ],
  "description": "Temperature in degrees Celsius.",
  "displayName": "Temperature",
  "name": "temperature",
  "schema": "double",
  "unit": "degreeCelsius"
}

Cykl życia i narzędzia

Cztery etapy cyklu życia modelu urządzenia to tworzenie, publikowanie, używanie i wersja:

Autor

Modele urządzeń DTML to dokumenty JSON, które można utworzyć w edytorze tekstów. Jednak w usłudze IoT Central można użyć środowiska graficznego interfejsu użytkownika szablonu urządzenia do utworzenia modelu DTML. W usłudze IoT Central możesz wykonywać następujące czynności:

• Tworzenie interfejsów definiujących właściwości, dane telemetryczne i polecenia.
• Używanie składników do łączenia wielu interfejsów.
• Definiowanie relacji dziedziczenia między interfejsami.
• Importowanie i eksportowanie plików modelu DTML.

Aby dowiedzieć się więcej, zobacz Definiowanie nowego typu urządzenia IoT w aplikacji usługi Azure IoT Central.

Istnieje rozszerzenie tworzenia DTDL dla programu VS Code, które obsługuje zarówno dtDL v2, jak i DTDL v3.

Aby zainstalować rozszerzenie DTDL dla programu VS Code, przejdź do edytora DTDL dla programu Visual Studio Code. Możesz również wyszukać kod DTDL w widoku Rozszerzenia w programie VS Code.

Po zainstalowaniu rozszerzenia użyj go, aby ułatwić tworzenie plików modelu DTDL w programie VS Code:

• Rozszerzenie zapewnia walidację składni w plikach modelu DTDL z wyróżnionymi błędami, jak pokazano na poniższym zrzucie ekranu:

  

• Użyj funkcji IntelliSense i autouzupełniania podczas edytowania modeli DTDL:

  

• Utwórz nowy interfejs DTDL. DtDL : Create Interface polecenie tworzy plik JSON z nowym interfejsem. Interfejs zawiera przykładowe definicje telemetrii, właściwości i poleceń.

Używanie

Aplikacje, takie jak IoT Central, używają modeli urządzeń. W usłudze IoT Central model jest częścią szablonu urządzenia, który opisuje możliwości urządzenia. Usługa IoT Central używa szablonu urządzenia do dynamicznego tworzenia interfejsu użytkownika dla urządzenia, w tym pulpitów nawigacyjnych i analiz.

Uwaga

Usługa IoT Central definiuje niektóre rozszerzenia języka DTDL. Aby dowiedzieć się więcej, zobacz Rozszerzenie usługi IoT Central.

Rozwiązanie niestandardowe może użyć analizatora modelu usługi Digital Twins, aby zrozumieć możliwości urządzenia, które implementuje model. Aby dowiedzieć się więcej, zobacz Używanie modeli IoT Plug and Play w rozwiązaniu IoT.

Wersja

Aby zapewnić, że urządzenia i rozwiązania po stronie serwera korzystające z modeli nadal działają, opublikowane modele są niezmienne.

DtMI zawiera numer wersji, którego można użyć do utworzenia wielu wersji modelu. Urządzenia i rozwiązania po stronie serwera mogą używać określonej wersji, z której zostały zaprojektowane.

Usługa IoT Central implementuje więcej reguł przechowywania wersji dla modeli urządzeń. Jeśli wersjonujesz szablon urządzenia i jego model w usłudze IoT Central, możesz migrować urządzenia z poprzednich wersji do nowszych wersji. Jednak zmigrowane urządzenia nie mogą korzystać z nowych funkcji bez uaktualnienia oprogramowania układowego. Aby dowiedzieć się więcej, zobacz Edytowanie szablonu urządzenia.

Publikowanie

Od lutego 2024 r. program Azure Certified Device Program zostanie wycofany. W związku z tym firma Microsoft nie akceptuje już przesyłania modeli DTDL do repozytorium modeli wtyczek i odtwarzania usługi Azure IoT.

Jeśli chcesz skonfigurować własne repozytorium modeli, możesz użyć repozytorium narzędzi modeli plug and play usługi Azure IoT. To repozytorium zawiera kod narzędzia interfejsu dmr-client wiersza polecenia, który może weryfikować, importować i rozszerzać modele DTDL. To narzędzie umożliwia również indeksowanie repozytoriów modeli, które są zgodne z konwencjami repozytorium modeli urządzeń.

Limity i ograniczenia

Poniższa lista zawiera podsumowanie niektórych kluczowych ograniczeń i limitów dotyczących modeli:

• Obecnie maksymalna głębokość tablic, map i obiektów wynosi pięć poziomów.
• Nie można używać tablic w definicjach właściwości.
• Interfejsy można rozszerzyć na głębokość 10 poziomów.
• Interfejs może rozszerzać co najwyżej dwa inne interfejsy.
• Składnik nie może zawierać innego składnika.

Omówienie analizatora modelu usługi Digital Twins

Język dtDL (Digital Twins Definition Language) został opisany w specyfikacji DTDL. Użytkownicy mogą używać pakietu NuGet analizatora modeli usługi Digital Twins do weryfikowania i wykonywania zapytań względem modelu DTDL w wersji 2 lub 3. Model DTDL można zdefiniować w wielu plikach.

Instalowanie analizatora modelu DTDL

Analizator jest dostępny w NuGet.org o identyfikatorze DTDLParser. Aby zainstalować analizator, użyj dowolnego zgodnego menedżera pakietów NuGet, takiego jak ten w programie Visual Studio lub w interfejsie dotnet wiersza polecenia.

dotnet add package DTDLParser

Uwaga

W momencie zapisu wersja analizatora to 1.0.52.

Używanie analizatora do weryfikowania i sprawdzania modelu

DtDLParser to biblioteka, której można użyć do:

• Ustal, czy co najmniej jeden model jest prawidłowy zgodnie ze specyfikacjami języka v2 lub v3.
• Zidentyfikuj określone błędy modelowania.
• Sprawdź zawartość modelu.

Model może składać się z co najmniej jednego interfejsu opisanego w plikach JSON. Za pomocą analizatora można załadować wszystkie pliki definiujące model, a następnie zweryfikować wszystkie pliki jako całość, w tym wszystkie odwołania między plikami.

Repozytorium DTDLParser dla platformy .NET zawiera następujące przykłady ilustrujące użycie analizatora:

• DTDLParserResolveSample pokazuje, jak analizować interfejs z odwołaniami zewnętrznymi, rozpoznawać zależności przy użyciu Azure.IoT.ModelsRepository klienta.
• DtDLParserJSInteropSample pokazuje, jak używać analizatora DTDL z języka JavaScript uruchomionego w przeglądarce przy użyciu platformy .NET JSInterop.

Analizator DTDLParser dla platformy .NET zawiera również kolekcję samouczków , które pokazują, jak używać analizatora do weryfikowania i sprawdzania modeli.

Interfejs API analizatora modelu umożliwia automatyzowanie lub weryfikowanie zadań zależnych od modeli DTDL. Na przykład możesz dynamicznie tworzyć interfejs użytkownika na podstawie informacji w modelu.

Następne kroki

Teraz, gdy już wiesz już o modelowaniu urządzeń, oto kilka dodatkowych zasobów:

• Język definicji cyfrowych reprezentacji bliźniaczych (DTLD, Digital Twins Definition Language)
• Repozytoria modelu