Vokabular von Verwaltungsschalen
March 21, 2021
6 min.
Industrie 4.0
In dem vorherigen Beitrag wurde die Verwaltungsschale als digitaler Zwilling der Plattform Industrie 4.0 vorgestellt. Ziel des Beitrags war es, die allgemeine Struktur einer Verwaltungsschale und den Zusammenhang zwischen Teilmodellen und Properties zu erläutern. Dieser Beitrag beschäftigt sich mit der Identifikation von Verwaltungsschalen und dem Einfluss von „online-Wörterbüchern“.
Anwendungsbeispiele
Das Ziel einer einzelnen Verwaltungsschale ist es, Informationen zu einem dazugehörigen Asset bereitzustellen. Verschiedene Instanzen können Informationen von einer Verwaltungsschale anfordern. Im Folgenden werden zwei Beispiele erläutert, die sich auf die Grafik unterhalb beziehen. Als beispielhaftes Asset wird, wie bereits im vorherigen Beitrag auch, eine Glühbirne verwendet.
• Eine mögliche Instanz ist eine Management-Applikation (Applikation = App). Diese kann sich bspw. über den aktuellen Zustand des Assets erkundigen. Bei dem Beispiel einer Glühbirne, kann eine solche Anwendung eine App sein, die dem Nutzer anzeigt, welche Glühbirnen aktuell in Betrieb sind. Dafür muss die App alle Verwaltungsschalen im Netzwerk scannen und nachschauen, ob die Verwaltungsschalen Teilmodelle mit entsprechenden Properties unterstützen. Findet die App solche Verwaltungsschalen, fordert diese die entsprechenden Informationen an.
• Eine weitere Instanz kann eine zweite Verwaltungsschale sein. In der Grafik ist dies anhand zweier Glühbirnen-Verwaltungsschalen dargestellt. Ein Beispiel für eine Kommunikation wäre, wenn die Verwaltungsschalen miteinander kommunizieren um die Lichtstärke aufeinander abzustimmen. Dafür müssten die Verwaltungsschalen nachschauen, ob die jeweils andere Verwaltungsschale über ein entsprechendes Teilmodell mit entsprechenden Properties verfügt.
Identifizierung von Verwaltungsschalen, Teilmodellen und Elementen
Die beiden Beispiele haben gemeinsame Aspekte. In beiden Fällen werden von der Verwaltungsschale Informationen abgerufen. Dieser Vorgang kann mit dem Versenden von Briefen oder Paketen verglichen werden. Soll ein Paket zu einer bestimmten Adresse verschickt werden, so muss der Absender dafür die Anschrift des Empfängers kennen. Die Anschrift folgt den Regeln einer klar definierten Notation: Name, Straße, Postleitzahl & Stadt, Land. Durch diese klare Notation ist es nahezu unmöglich, dass ein Paket versehentlich beim falschen Empfänger landet. Ähnlich ist es bei einer Verwaltungsschale. Damit Informationen an eine Verwaltungsschale geschickt werden können muss, laut der Spezifikation AAS in Detail, jede Verwaltungsschale verpflichtend ein global einzigartiges Attribut zur Identifizierung haben [1].
Im vorherigen Beitrag wurde die Struktur einer Verwaltungsschale lediglich in Teilmodelle und Properties unterteilt. Wie dort bereits erwähnt, ist der Aufbau einer Verwaltungsschale aber sehr viel komplexer. Das Attribut zur Identifizierung ist nicht, wie ein Property, einem Teilmodell zugeordnet. Das Attribut gehört direkt zur Verwaltungsschale.
Verwaltungsschalen
Laut der Spezifikation AAS in Detail, muss eine Verwaltungsschale anhand einer IRI (Internationalized Resource Identifier) zu identifizieren sein. Nun ist die Begrifflichkeit IRI nicht jedem geläufig und eine Erklärung würde einen ganzen Beitrag zur Folge haben. Daher kürze ich das Thema IRI an dieser Stelle mit Folgender Aussage ab: Eine Verwaltungsschale muss anhand einer IRI identifiziert werden können. Typischerweise wird hierfür eine URL (Uniform Resource Locator) genutzt. Denn jede URL, ist automatisch eine IRI [2].
Einer URL begegnet man, wissentlich oder unwissentlich, jeden Tag mehrfach. Ein Beispiel für eine URL findet man oben in der Browserzeile. Dort sollte gerade http://www.tecislava.com/blog/das-vokabular-von-verwaltungsschalen stehen. Dies ist die URL, unter der man diesen Beitrag findet. Eine Verwaltungsschale sollte ebenso eine URL haben unter der man diese abrufen kann. Das Attribut zur Identifizierung ist also (in den meisten Fällen) eine URL. Wenn jede Verwaltungsschale eine eigene URL erhält, werden damit auch zwei Fliegen mit einer Klappe geschlagen. Eine weitere Anforderung an das Identifizierungs-Attribut ist nämlich, dass es global einzigartig sein muss. Wenn jede Verwaltungsschale eine eigene URL bekommt, ist dies dadurch bereits gewährleistet. Hier kann nochmal das Beispiel http://www.tecislava.com/blog/das-vokabular-von-verwaltungsschalen genutzt werden. Es kann nicht passieren, dass eine zweite Website unter diesem Link veröffentlicht wird. Eine Duplizierung ist ausgeschlossen.
Um diesen Absatz zusammenzufassen: Jede Verwaltungsschale muss ein Identifizierungs-Attribut haben, welches global einzigartig ist. In den meisten Fällen kommt dies durch die Nutzung einer URL zustande.
Teilmodelle
Wie der UML-Darstellung zu entnehmen ist, müssen Teilmodelle ebenfalls ein Attribut zur Identifizierung unterstützen. Dieses Attribut kann, wie bei der Verwaltungsschale auch, eine IRI sein. Neben dem Identifizierungs-Attribut kann ein Teilmodell außerdem auf eine Semantik referenzieren. Auf eine Semantik zu referenzieren bedeutet, dass der Inhalt und die Struktur des Teilmodells (die Semantik) nicht beliebig zustande gekommen ist. Die Semantik eines Teilmodells liegt an einem öffentlich zugänglichen Ort im Internet. Das Teilmodell einer Verwaltungsschale verweist dann auf diese Semantik. Wenn man dies weniger kryptisch ausdrücken möchte, könnte man die vermenschlichte Aussage treffen:
„Ich bin eine Verwaltungsschale und unterstütze das Teilmodell mit der Bezeichnung Zustandsinformationen. Dieses Teilmodell wurde nicht von mir selber definiert, sondern ist für jeden öffentlich einsehbar im Internet einzusehen“.
Was bringt es einer Verwaltungsschale auf eine Semantik zu referenzieren? Zur Erläuterung dienen die zuvor definierten Anwendungsbeispiele:
In dem ersten Beispiel durchsucht eine App eine Verwaltungsschale nach den aktuellen Zustandsinformationen. Damit die Anwendung nach diesen Elementen suchen kann, muss zuerst überprüft werden, ob die Verwaltungsschale ein entsprechendes Teilmodell unterstützt. Die App würde also nach einem Teilmodell „Zustandsinformationen“ suchen. Wenn die beiden Instanzen (App und Verwaltungsschale) von zwei unterschiedlichen Herstellern sind, muss dennoch garantiert sein, dass beide Hersteller das gleiche Verständnis über Zustandsinformationen haben. In dem vorherigen Beitrag wurde bereits thematisiert, dass die Verwaltungsschale eine technologie- und herstellerunabhängige Lösung ist. Genauso muss es auch bei Teilmodellen sein. Wenn jeder Hersteller seine eigenen Teilmodelle definiert, können keine selbstorganisierenden und herstellerübergreifenden Systeme funktionieren. Teilmodelle sollten also in einem herstellerneutralen Verzeichnis abgelegt sein. Die Verwaltungsschalen referenzieren dann auf die Semantik dieser öffentlich verfügbaren Teilmodelle.
Elemente
Bevor sich dieser Abschnitt mit der Identifizierung und dem referenzieren von Elementen befasst, möchte ich nochmal kurz das Thema Elemente und Properties aufgreifen. Dies wurde zwar im vorherigen Beitrag bereites erläutert, jedoch kann es hier schnell zu Verwechslungen kommen. Ein Teilmodell besteht aus einer beliebigen Anzahl von Elementen. Ein Property ist ein mögliches, und zugleich das am häufigsten verwendete, Element. Weitere mögliche Elemente sind beispielsweise Dateien.
Elemente benötigen im Gegensatz zu Teilmodellen und Verwaltungsschalen kein eigenes Attribut zur Identifizierung. Die Spezifikation AAS in Detail empfiehlt es jedoch, auf eine Semantik zu referenzieren. Eine solche Referenz kann ebenfalls eine URL sein. Es kann aber auch eine so genannte IRDI sein. IRDI steht für International Registration Data Identifier. Im Gegensatz zu URLs ist eine IRDI kein Weblink. IRDIs und URLs haben jedoch gemeinsam, dass beide global einzigartige Zeichenreihenfolgen sind. Bei einer IRDI steckt jedoch keine Technologie, wie es bei der URL mit dem Internet der Fall ist, dahinter (Wer sich für den Aufbau von IRDIs interessiert, findet unten in den Referenzen einen Link zu einer Erläuterung). IRDIs sind also global einzigartige Zeichenreihenfolgen die auf einen Eintrag in einer Datenbank verweisen. Beispielhafte Datenbanken, die mit IRDIs arbeiten, sind ECLASS oder das IEC CDD. Die beiden aufgezählten Datenbanken können als „online-Wörterbücher“ interpretiert werden. Sucht man in den Datenbanken nach einer bestimmten IRDI, findet man dahinter einen Eintrag der ein Merkmal beschreibt.
Hier zwei Beispiele zu IRDIs und den jeweiligen Einträgen:
• ECLASS:
o Name: Herstellername
o IRDI: 0173-1#02-AAO236#002
o Hier geht es zum ECLASS-Eintrag
• IEC CDD
o Name: Herstellername
o IRDI: 0112/2///62683#ACE102#001
o Hier geht es zum IEC CDD-Eintrag
Zusammenfassung & Ausblick
Dieser Beitrag befasste sich mit der Identifizierung von Verwaltungsschalen und der Identifizierung der dazugehörigen Inhalte. Jede Verwaltungsschale muss zur Identifizierung eine globale eindeutige ID haben. Mit Hilfe dieser ID kann jede Verwaltungsschale aufgefunden und angesprochen werden. Die Inhalte einer Verwaltungsschale müssen ebenfalls identifizierbar sein und sollten auf einen herstellerunabhängigen Semantik-Pool referenzieren. Durch diese Referenzen kann gewährleistet werden, dass alle Hersteller und Anwender das gleiche Verständnis über Informationen haben. Wo steht diese Thematik heute?
Die Plattform Industrie 4.0 hat neben der Spezifikation der Verwaltungsschale inzwischen auch erste Teilmodelle veröffentlicht. Beispielsweise das „digitale Typenschild“. Properties in diesem Teilmodell verweisen mit Hilfe von IRDIs auf ECLASS-Einträge. In der Theorie gibt es also keine technologischen Hürden mehr. Verwaltungsschalen können für Assets implementiert werden und es gibt die Möglichkeit öffentliche Teilmodelle zu kreieren. Diese können auf herstellerunabhängige Semantikpools referenzieren.
Das Teilmodell „digitales Typenschild“ ist natürlich ein verhältnismäßig leichtes Thema. Es gibt schon seit vielen Jahren Normen, die vorschreiben, welche Informationen auf einer physischen Maschine sichtbar sein müssen (Herstellername, Seriennummer, Jahr der Herstellung…) [3]. Diese Informationen sind logischerweise auch schon länger in digitalen Datenbanken wie ECLASS oder IEC CDD definiert. Schwieriger wird es, wenn Teilmodelle zu spezifischeren Themen modelliert werden müssen. Wenn es ein Teilmodell geben soll, dass die aktuellen Betriebsparameter einer Maschine angibt ist es vorstellbar, dass es ein Property „Gehäusetemperatur“ geben kann. Es ist zu erwarten, dass unterschiedliche Hersteller nicht das gleiche Verständnis über eine Gehäusetemperatur haben. Wo wird eine Gehäusetemperatur gemessen? Was ist überhaupt ein Gehäuse? . . .
Die Modellierung von Informationen ist ein Thema, welches bereits seit vielen Jahren in verschiedenen Technologien und Wirtschaftszweigen diskutiert wird. Datenbanken wie ECLASS und IEC CDD ermöglichen es, ein gemeinsames Verständnis über Informationen zu erlangen. Die Integration dieses gemeinsamen Verständnisses in reale Prozesse, ist eines der Hauptthemen von Industrie 4.0.
