Wenn man von Industrie 4.0 redet, geht es immer um Geräte / Devices.
Geräte werden vernetzt – Geräte werden in die Cloud gehängt – Geräte senden Daten – Geräte führen Aktionen aus
Zu Industrie 4.0 gehört sicherlich noch mehr, jedoch es geht immer um Geräte. Aber woher weiß man eigentlich, um was für ein Geräte es sich handelt? Was kann dieses Gerät? Welche Daten sendet das Gerät? Welchen Zustand hat das Gerät?
Was wir brauchen ist eine Spezifikation, die Antworten auf genau jene Fragen hat. Und hier kommt das Device Capability Model, kurz DCM, zum Einsatz.
Was ist nun genau das Device Capability Model?
Es ist eine Beschreibung von Fähigkeiten, Eigenschaften und Daten, welche ein Gerät oder dessen digitale Repräsentation – der Digital Twin – übermitteln kann. Dadurch ist es möglich, IoT-Lösungen zu entwickeln, die für unterschiedliche, heterogene Geräte funktionieren, auch ohne vorab alle verwendeten Gerätearten zu kennen.
Stellt ein Gerät ein Device Capability Model bereit, ist es bereits möglich, ohne manuelle Konfiguration, dieses mit IoT Central zu verknüpfen oder dieses mit einem Azure IoT Hub zu verbinden. Hierbei spricht man auch von IoT Plug & Play – Geräte verwenden und Daten empfangen ohne weitere händische Arbeit.
Das Device Capability Model wird mit Hilfe der Digital Twin Definition Language beschrieben, diese wiederum basiert auf JSON-LD (Serialisierung für verlinkte Daten).
Digital Twin Definition Language
DTDL ist ein von Microsoft entworfener, offener Standard, um die Semantik der Geräte von IoT Plattformen und Lösungen abbilden zu können.
In den nächsten Abschnitten wird darauf eingegangen, wie uns Digital Twin Definition Language hilft, in einem Device Capability Model, Lösungen und Geräte abzubilden.
Wichtig zu wissen: aktuell sieht Microsoft noch potenzielle Breaking Changes vor!
Es gibt bereits eine Version 2. Die DTDL Version 2 wird bisher nur von Azure Digital Twins genutzt. Azure IoT Hub und Azure IoT Central unterstützten aktuell nur die Preview Version 1 (jedoch wird hier auch auf Version 2 umgestellt).
Aufbau von Version 2
Grundsätzlich setzt sich die Digital Twin Definition Language aus fünf Metaklassen zusammen. Mit diesen Klassen lassen sich Eigenschaften und Fähigkeiten eines Gerätes beschreiben. Aus den folgenden Metaklassen leitet sich das Verhalten eines Gerätes ab: Telemetry
, Property
, Command
, Relationship
, Component
.
Metaklassen sind in Interfaces definiert. Durch ihre Wiederverwendbarkeit können sie als Schema in anderen Interfaces mehrfach genutzt werden. Der Inhalt eines Interfaces lässt sich aus unterschiedlichen Metaklassen und Interfaces zusammensetzen.
Mittels Schemata kann die Semantik von Telemetry
– und Property
-Klassen festgestellt werden. Es gibt primitive Datentypen (string
, boolean
, double
, …) und komplexe Typen (Array
, Map
, Enum
, …).
Zusätzlich bietet die DTDL auch die Möglichkeit die Semantik der Daten zu beschreiben, d.h. es gibt so genannte Typannotationen. Dadurch können sich mathematische Funktionen oder auch Benutzeroberflächen, nicht nur auf das Schema, sondern auch auf die Semantik der Daten beziehen. Beispielweise kann eine Property
die semantisch als Länge annotiert ist, auch als jene betrachtet werden. Dabei wird die Property
mit dem Semantischen Typ Length
annotiert, das Schema der Länge könnte ein double
sein und die Einheit millimetre
. Somit ist auch klar definiert wie man diese Eigenschaft umrechnen kann und wie diese für NutzerInnen dargestellt werden sollte.
Telemetry
Hierbei handelt es sich um Daten, welche der Digital Twin sendet. Es spielt keine Rolle, ob die Daten regelmäßig gesendet werden oder nicht.
Pflichtfelder: @type
, name
, schema
Beispiel: Memory Usage wird als Semantischer Typ DataRate
in der Einheit bytePerSecond
angegeben und im Datentyp double
übermittelt.
{ "@type": [ "Telemetry", "DataRate" ], "name": "mem_usage", "schema": "double", "unit": "bytePerSecond" }
Property
Diese Metaklasse gibt den Status bestimmter Eigenschaften des Digital Twins an. Neben einer read-only Property
, kann es auch änderbare Eigenschaften geben. Standardmäßig sind Eigenschaften nicht veränderbar.
Plichtfelder: @type
, name
, schema
Beispiel: Die erste, nicht beschreibbare Property
stellt den Hersteller des Gerätes bereit. Der zweite ist der maximale Feuchtigkeitswert, welcher veränderbar ist.
{ "@type": "Property", "name": "manufacturer", "schema": "string" }, { "@type": "Property", "name": "setMaxHumidity", "writable": true, "schema": "double" }
Command
Mit Hilfe der Command
-Klasse lassen sich Befehle oder Funktionen auf einem Digital Twin ausführen. Mittels der Felder request
und response
wird definiert welche Payloads der Command
verwendet.
Achtung: Aktuell werden
Commands
noch nicht von Azure Digital Twins unterstützt – Spezifikationsanforderungen einsehen
Plichtfelder: @type
, name
Beispiel: Der Befehl startet eine Messung, welche als Eingabeparameter ein Startdatum benötigt. Die Antwort des Befehls liefert einen double
Wert zurück.
{ "@type": "Command", "name": "measuring", "request": { "name": "startMeasuring", "displayName": "Start measuring sequence", "description": "Requested time to start the measuring process.", "schema": "dateTime" }, "response": { "name": "measuredValue", "schema": "double" } }
Relationship
Stellen semantische Verbindungen zwischen einem oder mehreren anderen Digital Twins, dar. Dadurch könnten IoT Lösungen durch einen visuellen Graph darstellt werden. Wodurch die Verbindungen zwischen verbundenen Entitäten aufgezeigt werden kann.
Pflichtfelder: @type
, name
Beispiel: Ein Kühlschrank Gerät hat eine Verbindung zu einer Lichtschranke.
{ "@id": "dtmi:example:ait:fridge;1", "@context": "dtmi:dtdl:context;2", "@type": "Interface", "displayName": "AIT Fridge", "contents": [ { "@type": "Property", "name": "doorState", "schema": "boolean" }, { "@type": "Relationship", "name": "contains", "target": "dtmi:example:ait:light-barrier;1" } ] }
Component
Um Baugruppen innerhalb eines Models abzubilden, ist die Component
Klasse da.
Pflichtfelder: @type
, name
, schema
Beispiel: Die integrale Komponente Kamin gehört zu dem Haus dazu und muss nicht eigenständig verwaltet werden.
{ "@id": "dtmi:ait:house;1", "@type": "Interface", "@context": "dtmi:dtdl:context;2", "displayName": "House", "contents": [ { "@type": "Component", "name": "chimney", "schema": "dtmi:ait:Chimney;1" } ] }, { "@id": "dtmi:ait:Chimney;1", "@type": "Interface", "@context": "dtmi:dtdl:context;2" }
Man nutzt diese Metaklasse, um einen integralen Teil der Lösung zu beschreiben, welcher aber keine eigenständige Identität braucht. Und mit dieser muss beispielsweise nicht unabhängig im Digital Twin Graph gearbeitet werden.
Nützlich kann auch sein die Component
Klasse zur Strukturierung zu nutzen. Zusammengehörige Eigenschaften können innerhalb eines Interfaces gruppiert werden.
Die komplette Spezifikation und auch die nächsten Versionen der Digital Twin Definition Language sind auf GitHub zu finden.
Hilfreiche Tipps
- Visual Studio Code Azure IoT Tools Extension
- Nuget Paket Digital Twin Parser
- Validierungsbeispiel für Digital Twin Definition Language
- Guide, für IoT Plug & Play
- Mittels Visual Studio Code ein Device Capability Model validieren
- Azure Digital Twin SDK und deren Verwendung
Potentielle Be- & Einschränkungen
- IoT Plug & Play befindet sich noch in der Preview Phase, ggfs. läuft man in vorgegebene Limits
- Azure Digital Twin kann noch nicht mit
Commands
umgehen - Es ist offiziell kommuniziert, dass noch weitere Breaking Changes durchgeführt werden
Fazit
Ob als Gerätehersteller oder als Entwickler von IoT Lösungen ist es eine gute Sache sich auf einen gemeinsamen Standard zu beziehen. Da in der IoT Welt prinzipiell alles möglich ist, wird es keine feste Liste an vorkonfigurierten Geräten geben. Durch ein Device Capability Model ist die Variabilität von Fähigkeiten und Eigenschaften sehr schön abzubilden. Aktuell ist noch recht wenig dokumentiert und man ist ab und zu auf die eigene Interpretation des Device Capability Models angewiesen. Sobald auch offiziell ein Release vorhanden ist, steht der Integration nichts mehr im Weg. Jedoch lohnt es sich bereits heute, sich mit der Digital Twin Definition Language und dem Device Capability Model auseinanderzusetzen, um immer eine Nasenlänge voraus zu sein.
Haben Sie bereits Erfahrung mit Device Capability Models gemacht? Dann teilen Sie gerne Ihre Meinung darüber. Wollen Sie gerne wissen, wie Sie am besten Ihre Geräte verwalten? Mit AIT Smart Edge – ein Baukasten, welcher Themen wie die Verwaltung von Nutzern, Rechten und Edge Devices oder das Ausrollen und Konfigurieren von Edge Workloads in einer Mehr-Mandanten-Umgebung besitzt – setzen wir auf das Device Capability Model.
Sprechen Sie uns an und wir zeigen Ihnen wie AIT Smart Edge und das Device Capability Model Ihr Weg in die Zukunft ist.
Mit AIT Smart Edge schaffen wir eine Plattform, die es uns, einfach und flexible, ermöglicht jegliche Arten an Geräten zu verwalten – jetzt in das Interview rein hören.