Phoenix Contact Blockchain beim Engineering

Engineering-Daten von Maschinen und Anlagen entstehen heute verteilt sowie in Kollaboration über Unternehmensgrenzen hinweg. Genau an diesen Grenzen scheitert meist ein verbindliches Änderungsmanagement. Ein blockchain-basierter Ansatz zeigt einen durch die Unternehmen selbst bestimmten Ausweg.

Bei Industrie 4.0 geht es nicht mehr nur um den physischen Lebenszyklus einer Anlage sowie der in ihr verbauten Komponenten, sondern zunehmend auch um digitale Repräsentanzen dieser Assets. Doch während sich die physischen Bauteile zu einem definierten Zeitpunkt stets nur an einem Ort und im Zugriff eines Partners der Lieferkette befinden, können ihre digitalen Pendants – zum Beispiel Pläne, Zeichnungen, Protokolle, Fotos vom Einbauort oder Konfigurations- und Parametrierdaten – bei mehreren Partnern, Kunden und Lieferanten gleichzeitig sowie in unterschiedlichen Versionsständen vorliegen. In den meisten Fällen handelt es sich dabei nicht um einen Fehler, sondern um eine gewünschte parallele Vorgehensweise. Dadurch entwickelt sich aus digitaler Sicht ein Wertschöpfungsnetz, das Hersteller, Kunden und Endanwender auf verschiedenen Wegen verbindet (Bild 1).

Aus der aufwendigen digitalen Wertschöpfung durch die beteiligten Partner resultieren darüber hinaus hohe Sicherheitsanforderungen an die erzeugten Assets. Beispielsweise müssen die Einstelldaten eines Geräts am Einbauort verfügbar sein, denn sind sie lokal vorhanden, kann dies unter anderem die Servicezeiten verkürzen. Allerdings sind derartige Informationen in der Regel vertraulich und sollten daher lediglich für die vom Besitzer benannten Adressaten lesbar sein. Im Problemfall müssen sich Versionsstände zudem in verbindlicher Form über Unternehmensgrenzen hinweg zurückverfolgen lassen. Aspekte wie Auditier-, Nichtabstreit- und Zurechenbarkeit gehören in diesem Zusammenhang zu den weiteren wünschenswerten Eigenschaften.

Vernetzt, aber digital unabhängig

Ein Lifecycle-Management wird auf Systemebene üblicherweise so abgebildet: Es wird ein IT-System etabliert, das als Single Source of Truth eine zentrale Anlaufstelle darstellt und die Versionsstände in sicherer Form verwaltet. Dieser Ansatz erfordert ein netzwerkweites Vertrauen in die Unbestechlichkeit des Systems und lässt sich innerhalb eines einzelnen Unternehmens sinnvoll umsetzen. In einem digitalen Wertschöpfungsnetzwerk, das sich aus mehreren Unternehmen zusammensetzt, zeigt sich eine solche zentrale Vertrauensstelle aus Sicht der jeweiligen Partner allerdings als ungünstig. Denn die Steuerung der Verfügbarkeit, Vertraulichkeit und Verbindlichkeit liegt nicht mehr in der eigenen Hand. Vielmehr sind Lösungen gesucht, die die digitale Unabhängigkeit der Partner bewahren und gleichzeitig ein vernetztes Arbeiten an digitalen Assets erlauben.

Ein unternehmensübergreifendes Lifecycle-Management lässt sich auch ohne zentrale Vertrauensstelle realisieren, wenn einige etablierte Vorgehensweisen und Konventionen neu gedacht werden. Als Grundlage dafür dienen dezentral generierbare Benutzeridentitäten, kryptografisch gesicherte Freigabeinformationen sowie inhaltsadressierte Datenstrukturen, die wiederum vorteilhafte Arten von dezentralen Arbeitsabläufen ermöglichen.

Benutzerkennungen sollen stets eindeutig und authentifizierbar sein. Während eine zentrale Vergabestelle die Eindeutigkeit zum Beispiel per Datenbank garantieren kann, umfasst die im Folgenden beschriebene dezentrale Vergabe in einem multizentrischen Netzwerk einen probabilistischen Anteil. Um eine Kennung zu erzeugen, generiert jeder Teilnehmer im eigenen IT-System zufällig ein asymmetrisches Schlüsselpaar, das einen privaten und einen öffentlichen Schlüssel kombiniert. Aus dem öffentlichen Schlüssel wird dann eine Kennung abgeleitet (Bild 2).

Verteilte Transaktionssysteme wie Blockchains machen sich den Umstand zunutze, dass sich eine digitale Signatur, die mittels des privaten Schlüssels zu einer Kennung erstellt wird, von jedem Netzwerkteilnehmer ohne weitere Informationen überprüfen lässt. Mithilfe dieser Validierung kann man anschließend entscheiden, ob ein Teilnehmer Inhalte unter einer Kennung verändern darf. Durch eine solche Art der Benutzerkennung können ferner Inhalte vor der Übertragung für eine Kennung vertraulich gesichert und nur durch den ursprünglichen Erzeuger der Kennung empfangen werden.

Der wesentliche Unterschied zu traditionellen Benutzerkennungen liegt darin, dass es sich bei der Kennung um eine rein zufällige, nichtsprechende Zeichenkette handelt. Die Wahrscheinlichkeit, dass zwei Parteien unabhängig voneinander die gleiche Benutzerkennung generieren, ist aufgrund der Größe der Kennung äußerst gering. Als besondere Eigenschaft erweist sich, dass der Besitzer einer Kennung über die digitale Signatur auch gegenüber einem fremden System immer belegen kann, dass er tatsächlich der Besitzer ist.

Versionierung ableiten

Im Lebenszyklus entstehen unterschiedliche Stände von digitalen Inhalten. Klassischerweise erfolgt die Kennzeichnung der Stände durch eine sprechende oder zufällig gewählte Versionskennung. Unternehmensübergreifend führt dieses Verfahren in der Regel zu Verwirrung, denn unter derselben Versionsnummer – zum Beispiel 1.0.1 – können in verschiedenen IT-Systemen unterschiedliche Inhalte gespeichert sein. Außerdem ist es möglich, dass exakt identische Stände abweichende Versionsnummern tragen.

Einen Ausweg bietet die inhaltsbasierte Adressierung. Die Versionskennzeichnung vergibt hier nicht der Anwender oder das IT-System, sondern sie wird deterministisch mittels einer mathematischen Einwegfunktion aus dem Inhalt selbst abgeleitet. Beginnend bei einzelnen Dateien lassen sich so ebenfalls rekursive Strukturen (Ordner und Änderungsstände mit Freigabeinformationen) durch eine einmalige Versionskennung identifizieren. Jede Änderung einer referenzierten Datei, eines Ordners oder Änderungsstandes bewirken wiederum, dass sich die Versionskennung anpasst.

Inhaltsadressierende Netzwerke können derartige Datenobjekte auch ohne zentrale Stelle verteilen, da sich die Erzeugung der Versionskennung wiederholen lässt und auf jedem Netzwerkteilnehmer gleich ist. Da die abgeleiteten Versionskennungen nichtsprechend sind, wird eine für den Menschen lesbare Bezeichnung benötigt. Diese zustandsbehaftete, modifizierbare Zuordnung – beispielsweise die Art der Freigabe – lässt sich unter Nutzung einer dezentralen Benutzerkennung in einer Blockchain speichern (Bild 3).

Änderungen übernehmen

Im dezentralen Netzwerk sind Freigaben stets mit genau einer dezentralen Benutzerkennung und einem Änderungsstatus verknüpft, weil sie so durch das gesamte Netzwerk validierbar sind. Daher lassen sich Änderungen zwischen mehreren Netzwerkteilnehmern lediglich durch einen aktiven Vorgang übernehmen, weil sich die Auswirkungen erst bei der Übernahme prüfen lassen.

 

Der Betreiber eines Geräts gibt beispielsweise unter seiner Benutzerkennung einen Änderungsstand frei. Im Wartungsfall wird das Serviceunternehmen auf diesem Stand eine Modifikation vornehmen, unter der eigenen Benutzerkennung freigeben und anschließend dem Betreiber zur Übernahme vorschlagen (Bild 4). Der Betreiber kontrolliert die Änderung, fordert gegebenenfalls eine Nachbesserung an und gibt die Änderung abschließend unter eigenem Namen frei.