Beschreibung
Integrieren einer Maschine in ein bestehendes Distributed Ledger Netzwerk
Die Erfindung betrifft ein System bestehend aus einer Mehr zahl von vernetzten und mittels eines Managementsystems ver walteten Maschinen, wobei die Maschinen und das Management system jeweils Knoten eines Distributed Ledger Netzwerkes bilden, sowie ein Verfahren zum Integrieren einer Maschine in ein bestehendes Distributed Ledger Netzwerkes.
In der industriellen Automatisierung gewinnt die sogenannte Maschinen-zu-Maschinen-Kommunikation oder Machine-to-Machine- Kommunikation, kurz M2M-Kommunikation, vor allem im Zusammen hang mit den Entwicklungen in sogenannten Industrie-4.0- Szenarien immer mehr an Bedeutung. Dabei tauschen Maschinen insbesondere selbst initiiert untereinander Fähigkeiten aus und handeln vielfach aufgrund ihrer Fähigkeiten ein Kollabo rationsmodell aus. Insbesondere im Rahmen von Smart Manufac turing, d.h. Fertigung unter Einbeziehung intelligenter auto nom oder teilautonom handelnder Maschinen, ist die M2M- Kollaboration die Basis für Fertigungsanlagen der Zukunft.
Für M2M-Kollaborations-Szenarien wie beispielsweise im Umfeld von Smart Mobility, z.B. E-Charging oder Smart Parking, wer den bereits über Distributed Legder Netzwerke verwaltete und ausführbare Smart Contracts verwendet. Dafür kann bislang für eine Blockchain-Technologieplattform, die beispielsweise für ein E-Charging-System von Betreibern und Anwendern gemeinsam genutzt wird, in der zugehörigen Programmiersprache der Plattform ein Smart Contract eingebracht oder genutzt werden. Beispielsweise nutzt die Plattform Ethereum für ihre Smart Contracts die Programmiersprache Solidity. Die Plattform Hy- perledger Fabric nutzt für die dort Chaincode genannten Smart Contracts die Programmiersprachen Go oder NodeJS.
Bislang gibt es keinen Standard für Smart Contracts. Somit besteht der Bedarf, den Einsatz von Smart Contracts für Ma schinen im Industrieumfeld zu vereinfachen.
Diese Aufgabe wird durch die Merkmale der unabhängigen An sprüche gelöst. Vorteilhafte Ausgestaltungen sind in den ab hängigen Ansprüchen angegeben.
Die Erfindung betrifft ein System bestehend aus einer Mehr zahl von vernetzten und mittels eines Managementsystems ver walteten Maschinen, wobei die Maschinen und das Management system jeweils als Knoten oder Clients eines Knotens eines Distributed Ledger Netzwerkes interagieren, wobei die Maschi nen jeweils Maschineneigenschaften als Datensatz hinterlegt auf einem jeweiligen Speicher der jeweiligen Maschine aufwei sen, wobei die Maschinen jeweils ferner einen jeweiligen nor malisierten Smart Contract auf demselben oder einem weiteren Speicher aufweisen, wobei das Managementsystem einen Integra- tions-Contract aufweist, wobei der Integrations-Contract aus gebildet ist jeweilige normalisierte Smart Contracts auf vor herige, im Distributed Ledger Netzwerk bereits verfügbare Smart Contracts abzugleichen und in das Distributed Ledger Netzwerk zu transformieren, und wobei ein transformierter Smart Contract ausgebildet ist, ein Kollaborationsmodell zwi schen den vernetzten Maschinen zu regeln und in dem Distribu ted Ledger Netzwerk computerimplementiert ausgeführt zu wer den.
Das erfindungsgemäße System basiert somit auf einem System aus vernetzten Maschinen, wobei ein Managementsystem, bei spielsweise ein Managementsystem von IoT-Geräten, die ver netzten Maschinen verwaltet. Das Managementsystem kann dabei zentral oder auf mehrere der Maschinen dezentral verteilt ausgebildet sein. Beispielsweise sind die Maschinen verschie dene Komponenten eines Anlagensystems, beispielsweise Robo ter, Werkzeugmaschinen, Fertigungsmaschinen, AGVs (Autonomous Guided Vehicles), usw.. Solche oder ähnliche sogenannte IoT- (Internet of Things)-Geräte sollen innerhalb einer Anlage
flexibel Information betreffend einen optimierten Einsatz der jeweiligen Maschine oder eine optimierte Auslastung bei Ver gleich mehrerer Maschinen miteinander ermöglichen. Dafür wer den Maschineneigenschaften auf den jeweiligen Maschinen hin terlegt, wobei die Eigenschaften als Datensatz hinterlegt auf einem jeweiligen Speicher vorliegen, so dass der Austausch von relevanten Informationen insbesondere direkt zwischen den vernetzten Maschinen erfolgen kann.
Zusätzlich sind die Maschinen nun in einem Distributed Ledger Netzwerk miteinander verbunden, d.h. die Maschinen bilden je weils entweder selbst einen Knoten in dem Distributed Ledger Netzwerk, oder interagieren als Client eines bestimmten exis tierenden Knotens im DLT Netzwerk. Beispielsweise handelt es sich um ein Blockchain-Netzwerk. Die Maschinen weisen ferner einen normalisierten Smart-Contract auf, vorteilhafterweise auf demselben Speicher, auf dem auch die Maschineneigenschaf ten hinterlegt sind. Alternativ könnte ein weiterer Speicher zum Einsatz kommen.
Als normalisierter Smart-Contract im Sinne der vorliegenden Anmeldung wird ein Smart-Contract verstanden, der beispiels weise in einer normalisierten oder standardisierten Beschrei bungssprache oder Sprache hinterlegt ist. Dabei ist nicht zwingenderweise nur eine Sprache als Standard vorgesehen. Insbesondere können mehrere Standards existieren, die für das Format des Smart Contract in Frage kommen, und der normali sierte Smart Contract in einer dieser Standards formatiert sein.
Der normalisierte Smart Contract könnte auch zu einem stan dardisierten Smart Contract erhoben werden.
Das Management-System der vernetzten Maschinen weist einen Integrations-Contract auf. Dessen Funktionsweise besteht zum einen darin, die normalisierten Smart Contracts, die von ei ner Maschine mitgebracht werden, auf schon im Distributed- Ledger-Netzwerk vorhandene Smart Contract zu überprüfen. Da-
bei findet ein Abgleich statt, ob der Smart Contract bereits bekannt ist. Zudem besteht die Funktionsweise des Integrati- ons-Contracts darin, einen von einer Maschine mitgebrachten normalisierten Smart Contract in das Distributed Ledger Netz werk zu transformieren. Der Schritt des Transformierens könn te auch als Konvertieren bezeichnet werden. Damit wird der Schritt bezeichnet, den normalisierten Smart Contract in eine für Maschinen ausführbare Form zu bringen. Im einfachsten Fall kann darunter auch nur das Aufrufen des Codes zu Zwecken der Ausführung fallen.
Der transformierte und damit ausführbare Smart Contract re gelt dann ein Kollaborationsmodell zwischen den vernetzten Maschinen. Vorteilhafterweise werden im Smart Contract Bedin gungen abgebildet, unter welchen eine Nutzung der Maschine möglich ist. Beispielsweise werden dabei Nutzungsbedingungen wie Pay-per-Use-Bedingungen vorgeschlagen, die von anderen Maschinen im Netzwerk angenommen werden können.
Der transformierte Smart Contract wird dann in dem Distribu ted Ledger Netzwerk computerimplementiert ausgeführt. Bei spielsweise spezifiziert er, was bei einer Transaktion zu prüfen ist oder welche Folgeaktivitäten zu initiieren sind. Ferner können beispielsweise durch den Smart Contract Pro gramme automatisiert ausgeführt werden. Smart Contracts füh ren dabei eine im Programm-Code hinterlegte Logik aus, die Abhängigkeiten zwischen kollaborierenden Maschinen be schreibt. Beispielsweise sind dort Bedingungen hinterlegt, welche von einem Kollaborationspartner, also einer der Ma schinen im Netzwerk, erfüllt oder nachgewiesen werden müssen, damit Aktionen auf der anderen Maschine, die beispielsweise den Smart Contract vorgibt, gestartet oder ausgeführt werden.
Auf vorteilhafte Weise wird mit dem vorgeschlagenen System die vollständige Automatisierung der Integration von neuen oder externen Maschinen in ein Netzwerk, beispielsweise ein Betreibernetzwerk, von Maschinen, insbesondere eine Anlage oder Fabrik, ermöglicht. Vorteilhafterweise wird eine In-
tegration eines auf ein Distributed Ledger Netzwerk bezogenen Informationsmodells ermöglichen. In Distributed Ledger Netz werken oder Blockchain-Netzwerken wird die Integration oder das Onboarding von Smart-Contracts flexibel und unabhängig von konkreten, im Maschinennetzwerk verwendeten Smart Contract-Sprachen oder Formaten, ermöglicht. Insbesondere wird vorteilhaft ein vorhandenes Maschinennetzwerk innerhalb einer IoT-Anlage zusätzlich um die Möglichkeit ergänzt, in telligente automatisierte Verträge zwischen den Maschinen aufzusetzen und zu nutzen.
Gemäß einer Ausgestaltung umfasst das Kollaborationsmodell Geschäftsbedingungen zum Durchführen von Arbeitsschritten und/ oder Nutzungsbedingungen und/ oder Statusänderungen je nach durchgeführtem Arbeitsschritt. Beispielsweise wird die Art eines Abrechnungsmodells für Leistungen der Maschine spe zifiziert, beispielsweise ein Pay-per-Use-Modell oder ein pay-per-part-Modell oder ein pay-per-time-Modell. Dabei kann ferner festgelegt sein, für welchen Betrag, beispielsweise Betrag an Token, welche Art der Leistung der Maschine er bracht werden kann. Beispielsweise ist festgelegt, welche Art der Leistung in welchem Umfang erbracht werden kann. Bei spielsweise können für einen bestimmten Betrag an Token eine bestimmte Anzahl an Schrauben verschraubt oder Löchern ge bohrt oder Nieten gestanzt werden. Die Token repräsentieren dabei in dem Distributed Ledger Netzwerk beispielsweise einen gewissen Nutzen oder Wert. Das DLT-Netzwerk verwendet bei spielsweise eine oder evtl, mehrere bestimmte Token- Definitionen und setzt diese einheitlich ein.
Zudem legt das Kollaborationsmodell beispielsweise ferner fest, welche Statusänderungen der Smart Contract veranlasst. Je nach Erfüllung von Bedingungen wie durchgeführten Arbeits schritten wird durch den Smart Contract eine Änderung des Status ausgelöst, beispielsweise wird der Status aller an ei nem Smart Contract beteiligten Maschinen derart aktualisiert, dass durchgeführte Schritte wie die durchgeführte Leistung oder die durchgeführte Bezahlung dokumentiert sind. Insbeson-
dere erfolgt eine Übertragung von Tokens. Es ist ferner denk bar, dass der Smart Contract eine Giralgeldtransaktion aus löst, wenn er über ein entsprechendes Konto verfügen kann. Beispielsweise kann mittels des aktualisierten Status ferner für andere Maschinen im Netzwerk ersichtlich werden, dass ei ne Maschine für einen bestimmten Nutzungszeitraum belegt oder nicht verfügbar ist.
Gemäß einer Ausgestaltung liegen die Maschineneigenschaften in einem standardisierten, insbesondere mittels der Modul- Type-Package-Methode austauschbaren, Format vor. Der jeweili ge normalisierte Smart Contract liegt im gleichen standardi sierten Format vor. Dies ermöglicht vorteilhaft ein besonders einfaches Abarbeiten der Informationen, die von der Maschine geliefert werden, d.h. der Maschineneigenschaften einerseits und der Smart Contract-Bedingungen andererseits. Beispiels weise können sich somit vorteilhafterweise Argumente des Smart Contracts an standardisierten Attributen des Verzeich nisses mit den Maschineneigenschaften orientieren. Beispiels weise sind in einem Merkmal-Repository der Maschine Attribute gelistet, welche als Argument dem Smart Contract übergeben werden können. Der Smart Contract „versteht" somit diese Ar gumente ohne weitere Konvertierung oder Transformation.
Vorteilhafter Weise kann ein in dem System aus vernetzten Ma schinen bereits bestehendes oder installiertes Aushandeln von Fähigkeiten somit direkt auch für das Ausführen von Smart Contracts zwischen kollaborierenden Maschinen benutzt werden. Dabei wird das Konzept des Module Type Package, kurz MTP, ge nutzt, welches durch eine funktionale Beschreibung, bei spielsweise aus Engineering-Daten einer Automatisierung, er zeugt wird. Durch den Einsatz eines solchen Beschreibungs standards werden Eigenschaften von Anlagenkomponenten oder Schnittstellen oder Zustandsbeschreibungen normiert übermit telt. Durch die Ausweitung des MTP-Konzepts auf in einem Dis- tributed Ledger Netzwerk ausführbare Smart Contracts als neu es Segment (Facette) wird deren Einbindung in ein Maschinen netzwerk ermöglicht.
Gemäß einer Ausgestaltung ist als standardisiertes Format Au tomation Markup-Language oder mindestens ein ausführbares Code-Format, insbesondere Solidity oder Hyperledger Fabric Chaincode, insbesondere NodeJS oder Go, vorgesehen. In einer vorteilhaften Variante wird somit ein generalisierter Smart Contract in dem Automation Markup-Language-Format, kurz AML- Format, eingesetzt. Dieser wird mit Hilfe einer Normalisie rungsfunktion anschließend auf einem Knoten des Distributed Ledger Netzwerkes in eine ausführbare Form gebracht. Bei spielsweise liegt der Smart Contract in AML vor und wird mit tels einer Normalisierungsfunktion in das Code-Format Solidi ty gebracht. Nutzen dann unterschiedliche kollaborierende Ma schinen innerhalb des Maschinennetzwerkes beispielsweise Ethereum als Distributed Ledger Plattform und möchten somit Smart Contracts in der Programmiersprache Solidity ausführen, so können sie die Information des Smart Contracts, der von einer Maschine in AML-Code mitgebracht wird, konvertieren o- der transformieren und dann in Solidity ausführen.
In einer alternativen vorteilhaften Variante ist der Smart Contract in mindestens einem ausführbaren Code-Format, bei spielsweise in mehreren ausführbaren Code-Formaten, vorgese hen. Beispielsweise wird er quasi doppelt im Speicher hinter legt, beispielsweise einmal als Solidity-Code und einmal als Hyperledger Fabric Chaincode. Somit ist ein auf verschiedenen Plattformen ausführbares Code-Format direkt auf der Maschine verfügbar. Das Anwenden einer Normalisierungsfunktion besteht dann vorteilhafterweise lediglich noch in den Schritt des Aufrufens. Die konkreten, in ausführbarem Code-Format hinter legten Smart Contracts sind dann flexibel auf verschiedenen Plattformen wie beispielsweise Ethereum oder Hyperledger Fabric einsetzbar. Beispielsweise kann eine Maschine so fle xibel in verschiedenen Anlagen in ein bestehendes Distributed Ledger Netzwerk integriert werden. Dies kann insbesondere an Schnittstellen zwischen verschiedenen Anlagen verschiedener Hersteller, beispielsweise bei in Logistik-Schritten einge setzten Maschinen, sinnvoll sein.
Gemäß einer Ausgestaltung beschreibt der Smart Contract ein dynamisches Model für logische Verknüpfungen zwischen den Ma schinen. Ein solches dynamisches Model, welches logische Ab hängigkeiten der Maschinen und der von den jeweiligen Maschi nen ausgeführten Ausführungsschritte oder Ausführungsaufga ben, beschreibt, liegt beispielsweise in einem Programm-Code vor. Beispielsweise beschreibt der Smart Contract automatisch auszuführende Schritte oder Statusänderungen und insbesondere Transaktionen, welche in dem Distributed Ledger Netzwerk zu erfassen sind, je nach Meldungen oder Status-Meldungen der beteiligten Maschinen.
Die Erfindung betrifft ferner ein Verfahren zum Integrieren einer Maschine in ein bestehendes Distributed Ledger Netz werk, wobei
- die zu integrierende Maschine sich mit einem aus einer Mehrzahl von vernetzten und mittels eines Managementsystems verwalteten Maschinen bestehenden Maschinennetzwerk vernetzt,
- wobei die Maschinen jeweils als Knoten oder Client eines Knotens in einem Distributed Ledger Netzwerk mitwirken,
- wobei die Maschinen jeweils Maschineneigenschaften als Da tensatz hinterlegt auf einem jeweiligen Speicher der jeweili gen Maschine aufweisen und im Maschinennetzwerk austauschen,
- wobei die Maschinen jeweils ferner einen jeweiligen norma lisierten Smart Contract auf demselben oder einem weiteren Speicher aufweisen und mittels des Distributed Ledger Netz werkes austauschen,
- wobei das Managementsystem einen Integrations-Contract auf weist,
- wobei die zu integrierenden Maschinen den jeweiligen norma lisierten Smart Contract dem Managementsystem bereitstellt und das Managementsystem den jeweiligen normalisierten Smart Contract auf vorherige, im Distributed Ledger Netzwerk be reits verfügbare Smart Contracts abgleicht und je nach Ver fügbarkeit den jeweiligen normalisierten Smart Contract in das Distributed Ledger Netzwerk transformiert und wobei ein transformierter Smart Contract ein Kollaborationsmodell zwi-
sehen den vernetzten Maschinen regelt und in dem Distributed Ledger Netzwerk computerimplementiert ausgeführt wird.
Damit basiert auch dieser Aspekt der Erfindung auf einem ver netzten Maschinennetzwerk, bei dem Maschineneigenschaften ausgetauscht werden und nun zusätzlich Smart Contracts mitei nander ausgetauscht werden und ein Smart Contract einer neu en, zu integrierenden Maschine im Distributed Ledger Netzwerk integriert wird. Beispielsweise werden die Schritte, dass Ma schineneigenschaften ausgetauscht werden, und dass jeweilige normalisierte Smart Contracts ausgetauscht werden, zeitlich gleichzeitig ausgeführt. Ebenso ist es vorstellbar, dass be reits Maschineneigenschaften ausgetauscht wurden, um potenti ell erfolgsversprechend kollaborierende Maschinen zu identi fizieren und erst in einem nachgelagerten Schritt Smart Contracts ausgetauscht werden.
Insbesondere erfolgt das Vernetzen einer neu aufzunehmenden und integrierenden Maschine in das Maschinen-Netzwerk zeit lich vorgelagert oder in einem Schritt gemeinsam mit dem Übertragen von Maschineneigenschaften und/oder Smart Contracts.
Um einen unkontrollierten Austausch oder eine unkontrollierte Übernahme von Smart Contracts, die immer auch das Ausführen von in dem Smart Contract hinterlegten Programmen bedeuten kann, zu verhindern, wird der normalisierte Smart Contract einer Maschine durch das Management-System des Maschinen- Netzwerkes überprüft. Dabei wird abgeglichen, ob der Smart Contract bereits bekannt ist oder im Distributed Ledger Netz werk bereits verfügbar ist. Da der zu überprüfende Smart Contract in normalisierter oder standardisierter Form vor liegt, ist der auf einfache Weise mit bereits vorhandenen ebenfalls normalisiert oder standardisiert hinterlegten Smart Contracts vergleichbar.
Gemäß einer Ausgestaltung umfasst das Abgleichen den Schritt, dass im Falle eines bereits verfügbaren Smart Contracts be-
treffend gleiche Kollaborationspartner oder das gleiche Kol laborationsmodell der bereits verfügbare Smart Contract über schrieben wird. Der bereits verfügbare Smart Contract wird durch den normalisierten Smart Contract der zu integrierenden Maschine überschrieben. Somit ist vorteilhafterweise immer ein aktueller Smart Contract hinterlegt, was beispielsweise durch Verwendung einer Versionskennung erkennbar gemacht wer den kann.
Gemäß einer Ausgestaltung umfasst das Abgleichen den Schritt, dass im Falle eines bereits verfügbaren Smart Contracts be treffend gleiche Kollaborationspartner oder das gleiche Kol laborationsmodell der jeweilige normalisierte Smart Contract unter Aufführung einer neuen Versionskennung hinterlegt wird. Es ist eine Historie anlegbar und es können im Nachhinein verschiedene Versionsstände nachverfolgt werden. Durch die Kollaborationspartner können insbesondere Maschinentypen festgelegt sein. Alternativ können auch Maschinen-Identitäten oder Maschinen-IDs hinterlegt sein, die als Teilnehmer am Smart Contract in Frage kommen.
Gemäß einer Ausgestaltung umfasst das Abgleichen den Schritt, dass im Falle eines bereits verfügbaren Smart Contracts be treffend gleiche Kollaborationspartner oder das gleiche Kol laborationsmodell der jeweilige normalisierte Smart Contract nicht oder nur unter bestimmten Voraussetzungen hinterlegt wird.
Beispielsweise handelt es sich in dem Fall, in dem ein frühe rer Smart Contract überschrieben wird, um einen Smart Contract einer anderen, später zu integrierenden Maschine, die die gleichen Bedingungen anbietet und dazu das Kollabora tionsmodell im nun zu integrierenden Smart Contract abgefasst hat. Ebenso ist es denkbar, dass es sich um einen Smart Contract der gleichen Maschine handelt, die sich früher schon einmal vernetzt hat.
Die Voraussetzungen, unter welchen ein neuer Smart Contract installiert oder deployed werden darf, kann auf vorteilhafte Weise im Distributed Ledger Netzwerk festgelegt sein. Bei spielsweise können in Betriebsbestimmungen, sogenannten Stan dard Operating Procedures, Voraussetzungen vorgesehen sein, die erfüllt sein müssen, damit ein zu integrierender Smart Contract hinterlegt wird. Es ist ferner denkbar, dass in ei nem bereits integrierten und installierten Smart Contract zu künftige Integrationen bestimmter Smart Contracts nicht er laubt werden.
Gemäß einer Ausgestaltung umfasst das Abgleichen den Schritt, dass im Falle einer fehlenden Verfügbarkeit der jeweilige verfügbare Smart Contract hinterlegt wird. Beispielsweise muss dann nicht befürchtet werden, dass Bedingungen aus dem zu integrierenden Smart Contract mit Bedingungen früherer Smart Contracts in dem Distributed Ledger Netzwerk kollidie ren.
Gemäß einer Ausgestaltung weist der normalisierte Smart Contract ein zugehöriges Interface zur Beschreibung von Me thoden auf und die Methoden beschreiben Kollaborationsoptio nen zwischen den Maschinen. Der Smart Contract und ein zuge höriges Interface sind beispielsweise miteinander verknüpft im MTP hinterlegt.
Dem Interface kommt dabei die Funktion zu, die Methoden und deren Argumente, die zum Ausführen bestimmter Transaktionen zur Erfüllung eines Vertrags erforderlich sind, zu beschrei ben. Beispielsweise können Methoden aufgerufen werden, wie „Transfer-Token", d.h. die Ausführung einer Funktion, welche zur Übertragung von Token in dem Distributed Ledger Netzwerk führt. Durch den Transfer der Token wird insbesondere eine virtuelle Währung oder ein virtuelles Tauschmittel, der dem Wert der Leistung im Netzwerk entspricht, übertragen.
Gemäß einer Ausgestaltung beschreibt das Interface ferner Ar gumente, die als Eingabe für die Methoden verwendet werden.
Es ist zusätzlich zur Methode, die aufgerufen wird, auch ein Argument zu übergeben, beispielsweise ein Betrag von zu über tragenden Token oder ein Adressat, der in der Methode abge bildet ist. Beispielsweise wird zusätzlich eine Kontext-ID oder eine Fahrzeug-ID übermittelt. Als Methode sind ver schiedenste Funktionen vorstellbar, die für das Ausführen des Betriebes zur Befolgung der Vorgaben aus dem Smart Contract denkbar sind. Dabei beschreiben sie Kollaborationsoptionen zwischen den Maschinen, indem sie beschreiben, welche Funkti onen von einem der beteiligten Maschinen im Rahmen der Aus führung des Smart Contracts aufrufbar sein sollen. Beispiels weise ist auch die Methode denkbar, die einen Bericht über eine erfüllte Aufgabe erstellen. Beispielsweise ist ein Argu ment eine Statusänderung.
Gemäß einer Ausgestaltung sind die Argumente standardisiert auf der Maschine hinterlegt und entsprechend insbesondere standardisierten Attributen der Maschineneigenschaften.
Gemäß einer Ausgestaltung beschreiben die Maschineneigen schaften Fähigkeiten einer jeweiligen Maschine und sind der art standardisiert hinterlegt, dass andere Maschinen Informa tionen zu den Fähigkeiten verarbeiten können. Vorteilhafter weise findet so ein Aushandeln von Fertigungsschritten oder Prozessketten autonom zwischen den Maschinen statt. Alterna tiv kann neben einer autonomen und selbstständigen Aushand lung unter den Maschinen das standardisierte Format auch von einem Managementsystem verwendet werden, welches die Verstän digung der Maschinen untereinander überwacht oder übernimmt.
Gemäß einer Ausgestaltung wird der Smart Contract beim Trans formieren mittels einer Normalisierungsfunktion in eine Form gebracht, die alle DLT-Netzwerkteilnehmer verstehen, oder die zum DLT-Netzwerk passt. Insbesondere wird der Smart Contract so auch in eine durch die Maschine aufrufbare Form gebracht. Je weniger normalisiert der Smart Contract vorliegt, desto aufwendiger ist die Normalisierungsfunktion zu gestalten. Für bereits in ausführbaren Code hinterlegte Smart Contracts kann
die Normalisierungsfunktion einfacher ausgebildet sein und sich auf ein Aufrufen des Codes beschränken. Wird ein genera lisierter normalisierter Smart Contract verwendet, so umfasst die Normalisierungsfunktion das Konvertieren in die aufrufba re Form.
Auf vorteilhafte Weise können in sogenannten intelligenten Maschinen oder Maschinen in Cyber-Physical Systems somit Au tomatisierungsprodukte vorgesehen sein, die die beschriebenen normalisierten Smart Contracts einerseits mitbringen und be reitstellen und andererseits in einem Distributed Ledger Netzwerk der Maschinen integrieren. Besonders vorteilhaft werden dafür schon vorhandene Maschinenbeschreibungs- Repositories genutzt.
Somit werden Maschinen automatisiert in Maschinennetzwerke einer Anlage, die beispielweise über ein Kommunikationsnetz werk kommunizieren, und zugleich beispielweise in aus den gleichen Teilnehmern bestehende Maschinen-Blockchain- Netzwerken integriert. Insbesondere wird die Basis des Modul Type Package-Konzepts genutzt, das für den Austausch von Ma schineneigenschaften sowie von Smart Contracts für die Teil habe an einem Distributed Ledger-Netzwerk, insbesondere Block-Chain-Netzwerk, eingesetzt wird.
Die Erfindung betrifft ferner ein Computer-Programmprodukt mit einem Computer-Programm, das Mittel zur Durchführung des Verfahrens nach einem der oben beschriebenen Ausgestaltungen aufweist, wenn das Computer-Programm auf einer programmge steuerten Einrichtung zur Ausführung gebracht wird. Insbeson dere wird das Computer-Programm verteilt im Maschinennetzwerk und/ oder Distributed-Ledger-Netzwerk zur Ausführung ge bracht.
Die Erfindung wird nachfolgend anhand von Ausführungsbeispie len mit Hilfe der Figuren näher erläutert. Es zeigen:
Fig. 1 Eine schematische Darstellung eines Maschinennetzwer kes und eines Maschinen-Blockchain-Netzwerkes gemäß einem ersten Ausführungsbeispiel der Erfindung;
Fig. 2 Eine schematische Darstellung eines Verfahrens zur Integration eines Smart Contracts einer Maschine in ein Blockchain-Netzwerk gemäß einem zweiten Ausfüh rungsbeispiel der Erfindung.
In der Figur 1 sind zur Veranschaulichung eines Maschinen- Netzwerkes in einer Fabrik fünf Roboter 10, 11, 12, 13, 15 und ein AGV 14 gezeigt. Aus Darstellungsgründen wurde die An zahl auf sechs Maschinen beschränkt, wobei Ausführungsbei spiele mit wesentlich mehr Maschinen, beispielsweise mehreren 100 Maschinen, vorstellbar sind. Die Roboter 10, 11, 12, 13, 15 sind für die Zwecke dieses ersten Ausführungsbeispiels als Greifarmroboter gezeigt. Ebenso sind andere Maschinen, die für eine Kollaboration in einem industriellen Automatisie rungsnetzwerk vorstellbar sind, sowie andere Roboter, bei spielsweise Parallelkinematiken oder andere serielle Kinema tiken, insbesondere mit beliebig vielen Freiheitsgraden, vor teilhat einsetzbar.
Im ersten Ausführungsbeispiel sollen die Roboter 10, 11, 12, 13, 15 miteinander Zusammenwirken, um mit verteilten Aufgaben ein Fertigungsteil zusammenzusetzen, beispielsweise ein printed Circuit board. Dafür tauschen die Roboter 10, 11, 12, 13, 15 Informationen über ihre jeweiligen Maschineneigen schaften untereinander aus.
Es ist zudem gemäß dem ersten Ausführungsbeispiel ein soge nanntes AGV 14, autonomes guided vehicle, also ein autonom in der Anlage umherfährendes Transport-Gerät im Einsatz. Das AGV 14 führt ein von den Robotern zu bearbeitendes Werkstück mit sich und transportiert es insbesondere zu den verschiedenen Robotern, die verschiedenen Fertigungsstationen angehören.
Beispielshalber ist in Figur 1 für den Roboter 10 veranschau licht, dass er einen Datensatz zu seinen Maschineneigenschaf ten 21 mitbringt, d.h. auf seinem Speicher hinterlegt hat, und beispielsweise von sich aus oder auf Anfrage im Maschi nennetzwerk bekannt gibt. Es folgt eine sogenannte skill- basierte Planung von Fertigungsschritten, wobei die Planung zentral durch die Instanz des Managementsystems erfolgen kann oder ebenso dezentral, verteilt auf den Robotern. Beispiels weise ist in dem Netzwerk eine Teilaufgabe der Gesamtferti gungsaufgabe zu erledigen und es wird anhand von Maschinenei genschaften, die die Auslastung der einzelnen Maschine be treffen, entschieden, welcher Roboter die Teilaufgabe über nimmt. Ebenso kann die Entscheidung anhand einer Angabe zur Schnelligkeit, mit der einer der Roboter die Teilaufgabe ab arbeiten kann, getroffen werden.
Gemäß dem ersten Ausführungsbeispiel der Erfindung soll die Fertigungsanlage zusätzlich Blockchain-basiert arbeiten kön nen. Dafür sollen die einzelnen Roboter 10, 11, 12, 13, 15 sowie das AGV 14 jeweils Knoten K0, Kl, K2, K3, K4, K5 eines Blockchain-Netzwerkes bilden. D. h. die Maschinen sollen je weils am Blockchain Netzwerk teilhaben können, insbesondere durch Übermitteln von Transaktionen in das Blockchain Netz werk und/ oder Speichern der Blockchain Datenbank.
Beispielsweise handelt es sich um eine private Blockchain Struktur oder eine sogenannte Konsortium Blockchain Struktur, bei der die Teilnahme am Blockchain Netzwerk auf die Teilneh mer des Fertigungsnetzwerkes beschränkt ist. Im industriellen Umfeld werden beispielsweise private Blockchains eingesetzt, bei welchen das Konsensus-Verfahren innerhalb eines Konsorti ums stattfindet, dessen Mitglieder beispielsweise einander oder einer Verwaltungsinstanz bekannt sind oder ein bestimm tes Vertrauensniveau erfüllen. Beispielsweise können nur Kno ten in Blockchain Netzwerk teilnehmen, die im Kommunikations netzwerk der Fertigungsanlage authentifiziert wurden.
Das Blockchain Netzwerk innerhalb der Fertigungsanlage bietet bekannte Vorteile wie eine dezentral verfügbare Datenhaltung, manipulationsgeschützt hinterlegte Transaktionen und nachver folgbare Transaktionsketten. Überdies wird das Blockchain Netzwerk gemäß dem ersten Ausführungsbeispiel derart genutzt, dass Smart Contracts, die Kollaborationsmodelle zwischen den Robotern abbilden, gegenseitig bekannt gemacht werden und ausgeführt werden. Es entsteht damit auf besonders vorteil hafte Weise eine Synergie von einem Kommunikationsnetzwerk mit Austausch von Maschineneigenschaften sowie einem Block chain Netzwerk zum Ausführen von Smart Contracts, die die Zu sammenarbeit der Roboter mit ihren jeweiligen Eigenschaften und Kollaborationsbedingungen erst voll-autonom ermöglicht.
Figur 1 veranschaulicht wiederum für den Roboter 10, dass er neben den Maschineneigenschaften 21 auch einen Smart Contract 22 auf seinem Speicher hinterlegt hat. Die Maschineneigen schaften 21 und der Smart Contract 22 sind der Übersichtlich keit halber nur für den Roboter 10 abgebildet, können aber vorteilhaft bei allen Robotern oder allgemein gesprochen bei autonom oder zumindest flexibel innerhalb einer Anlage ein- setzbaren Maschinen vorhanden sein.
Beispielshalber sind in der Fertigungsanlage zwei Fräsroboter 12, 13 im Kommunikationsnetzwerk integriert. Beispielsweise wurden beide Roboter über eine Maschinen-ID authentifiziert und mithilfe von kryptografischen Verfahren über die Kommuni kationsverbindung authentifiziert. Beide Roboter sind dafür beispielsweise mit kryptographischen Schlüsseln ausgestattet. Beide Fräsroboter übermitteln beispielsweise ihre jeweilige Eigenschaft, ein spezifisches Fräsverfahren durchführen zu können. Beispielsweise wird diese Information an das AGV 14 gesendet, welches ein zu fräsendes Teil mit sich führt. Bei spielsweise obliegt es dem AGV, einen der beiden Fräsroboter 12, 13 auszuwählen. Neben den Maschineneigenschaften, die zu den beiden Fräsrobotern vorliegen, liegen auch Informationen zu einem von dem jeweiligen Fräsroboter angebotenen Kollabo rationsmodell vor.
Das Kollaborationsmodell beschreibt dabei, zu welchen Bedin gungen, insbesondere zu welchem virtuellen Preis, das Fräs verfahren durchgeführt werden kann. Beispielsweise repräsen tiert der virtuelle Preis eine Auslastung des jeweiligen Fräsroboter. Der Preis für ein Fräsverfahren von einem auf grund seiner räumlichen Lage in der Anlage häufig frequen tierten Roboters ist beispielsweise höher als ein weniger frequentierte Roboter. Dies kann beispielsweise wiederum in die zentrale oder dezentrale Planung für das Fertigungsver fahren eingehen, beispielsweise indem das Verfahren auf Kos teneffizienz hin optimiert wird.
Anhand des Smart Contracts wird einerseits die Information verfügbar gemacht, zu welchen Konditionen eine Kollaboration mit einem jeweiligen Roboter durchführbar ist. Diese Informa tion ist in der Blockchain gespeichert und kann somit bei spielsweise von dem AGV 14 abgefragt werden. Überdies kann ferner in dem Blockchain Netzwerk die Kollaboration Block- chain-unterstützt über die Smart Contracts abgewickelt wer den. Als Bestandteil der Kollaboration ist beispielsweise auch geregelt, welche Aktionen nach Beendigung der Teilaufga be durch einen Fräsroboter angestoßen werden, beispielsweise wie ein digitaler Zwilling eines Werkstücks angepasst wird oder welche Transaktionen betreffend eine Bezahlung der Leis tung in der Blockchain gesichert hinterlegt werden.
Die Smart Contracts bilden als ausführbare Logik somit die Basis, den gesamten Ablauf beispielsweise einer Fertigung, der aufgrund der Maschineneigenschaften und Kollaborationsmo delle geplant oder festgelegt wird, zu begleiten oder zu do kumentieren und durch Sicherung von konsistenten Datensätzen in der Blockchain zu unterstützen.
In der Anlage kann vorteilhafterweise ein Managementsystem 100 als zentrale Instanz vorgesehen sein, das insbesondere überall dort in den Fertigungsprozess eingreift, wo nicht au tonome Maschinen beteiligt sind. Überdies kann das Manage-
mentsystem übergeordnete Aufgaben oder Koordinierungsaufgaben mit weiteren Fabrikeinheiten oder Logistikeinheiten wahrneh men. Beispielsweise koordiniert das Managementsystem 100 den Beitritt und die Authentifizierung von Maschinen zum Maschi nennetzwerk. Ferner weist das Managementsystem einen Integra- tions-Contract 20 auf, der auch als Onboarding Smart Contract bezeichnet werden kann. Dafür interagiert auch das Manage mentsystem als Knoten
Die Funktionsweise des Integrations-Contracts 20 wird anhand von Figur 2 und einem zweiten Ausführungsbeispiel näher er läutert. In einem ersten Schritt S10 vernetzt sich ein Robo ter 10 mit zugehörigem Smart Contract 22 mit dem Blockchain Netzwerk. Dafür durchläuft er beispielsweise vorab einen Au thentifizierungsprozess, um als ein teilnehmender Knoten in dem Blockchain Netzwerk agieren zu können. Dieser Schritt stellt insbesondere einen Schritt innerhalb eines Onboarding- Prozesses dar. In einem zweiten Schritt S20 stellt der Robo ter 10 seinen normalisierten Smart Contract 22 dem Blockchain Netzwerk bereit. Dabei wird der normalisierte Smart Contract 22 beispielsweise als Transaktion im Netzwerk veröffentlicht und die Transaktion beispielsweise mit dem im Netzwerk ver einbarten Konsensmechanismus validiert.
Der normalisierte Smart Contract 22 wird in einem dritten Schritt S30 vor dem Einsatz im Blockchain Netzwerk mit im Blockchain Netzwerk vorhandenen Smart Contracts abgeglichen. Ziel ist dabei, den neu aufzunehmenden Smart Contract auf Verträglichkeit mit bereits gültigen Smart Contract und auf Unbedenklichkeit hin zu überprüfen. Für diesen Überprüfungs vorgang ist der Integrations-Contract 20 vorgesehen. Der In- tegrations-Contract 20 kann zentral auf dem Managementsystem hinterlegt sein.
Generell kann das Management System 100 auch als dezentrale Instanz vorgesehen sein, die beispielsweise über einige Kno ten verteilt ist. Es ist dabei sicherzustellen, dass zumin dest ein festlegbarer Anteil der Knoten, die Aufgaben des de-
zentralen Managementsystems wahrnehmen, dauerhafter Bestand teil des Netzwerkes sind.
Somit kann der Integrations-Contract 20 ebenso dezentral im Blockchain Netzwerk, zumindest auf denjenigen Knoten, die das Managementsystem bilden, und insbesondere auf allen teilneh menden Knoten hinterlegt sein.
In Szenarien, in welchen aufgrund der Systemstruktur des Ma schinennetzwerkes bereits eine zentrale Einheit vorhanden ist, kann diese vorteilhaft zusätzlich für die Aufgabe des Smart Contract Onboardings genutzt werden.
Die Prüfung des normalisierten Smart Contracts 22 kann erge ben, dass der gleiche Smart Contract bereits zu einem frühe ren Zeitpunkt im Blockchain Netzwerk hinterlegt wurde. Für diesen Fall kann beispielsweise ein vierter Schritt S41 des Überschreibens des alten Smart Contracts oder ein Hinterlegen des neuen Smart Contracts mit gleicher Kennung und neuer Ver sionsnummer folgen.
In einem alternativen vierten Schritt S42 erfolgt das Hinter legen eingeschränkt, beispielsweise nur, wenn die Option auf eine Ablösung in den Betriebsbestimmungen, den sogenannten SOPs, vorgesehen ist. Beispielsweise soll verhindert werden, dass durch das Einbinden des neuen Smart Contracts ungewollt Rückwirkungen auf vorhandene Kollaborationen entstehen. Zu gleich soll aber auch ermöglicht werden, dass bereits etab lierte Kollaborationen bei Bedarf auf einen aktuelleren Smart Contract umstellen können.
Beispielsweise leistet ein neuer Smart Contract, der von dem AGV 14 in einer Anlage neu etabliert werden soll, eine besse re Fehlerbehebung. Andere AGVs der Anlage, die unter den gleichen Bedingungen eingesetzt werden sollen wie das neue zu integrierende AGV 14, die also das gleiche Kollaborationsmo dell anbieten, sollen ebenfalls den neuen Smart Contract nut zen können. Für manche Anlagen, insbesondere kontinuierliche
Prozesse, soll ein Umsteigen auf den neueren Smart Contract beispielsweise nur während einer planned downtime Phase, also einer zu Zwecken von Updates oder sonstigen Wartungen in der Anlage vorgesehenen Ausfallzeit, vorgenommen werden können.
Die Prüfung kann ferner ergeben, dass ein normalisierter Smart Contract 22 unbekannt ist.
Es kann daher auch der weitere alternative vierte Schritt S43 vorgesehen sein, dass der normalisierte Smart Contract 22 neu angelegt wird. Insbesondere kann das Managementsystem bei un bekannten Smart Contracts verfügbare Informationen auf be stimmte Anforderungen hin untersuchen, z.B. auf Vetrauenswür- digkeit der Headerinformationen oder Code-Konsistenz.
Es schließt sich an die verschiedenen alternativen Schritte der fünfte Schritt S50 der Transformation des normalisierten Smart Contracts 22 an, der zu einem in dem Blockchain- Netzwerk ausführbaren Code führt. Beispielsweise ist der nor malisierte Smart Contract 22 des AGVs 14 eine aktualisierte Version eines Smart Contracts, der Regeln zum Übernehmen von Transportvorgängen von Werkstücken durch das AGV abbildet.
Das AGV 14 lässt diesen über den Onboarding Contract des Ma nagementsystems im System deployen.
Das AGV 14 nutzt beispielsweise das Module Type Package Ver fahren, um Maschineneigenschaften 21 wie beispielsweise eine in Abhängigkeit vom Batterieladezustand verbleibende Be triebslaufzeit anzugeben. Ebenfalls im MTP hinterlegt ist der normalisierte Smart Contract 22, der vorteilhafterweise in der gleichen standardisierten Sprache wie die Maschineneigen schaften 21, beispielsweise in AML (automation markup langu- age), hinterlegt ist. So wird vorteilhafterweise ein gemein sames standardisiertes Format in einem ebenfalls gemeinsam verwendeten standardisierten Austauschverfahren (MTP) für die Handhabung der Maschineneigenschaften 21 und des Smart Contracts 22 eingesetzt.
Das Managementsystem 100 wendet auf den normalisierten Smart Contract 22 eine Normalisierungsfunktion an und wandelt ihn in einen ausführbaren Smart Contract Code um. Je nach Block- chain-Platform wird Code in den Programmiersprachen Solidity, NodeJS oder Go etc. zur Ausführung gebracht.
Es wird somit insgesamt in den verschiedenen vorgestellten Ausprägungen eine industrietaugliche Transformation von Smart Contracts, die zwischen Maschinen für eine vereinfachte Kol- laboration der Maschinen untereinander eingesetzt werden, be- reitgestellt .
Obwohl die Erfindung im Detail durch die Ausführungsbeispiele näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und ande re Variationen und Kombinationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.