Automatisierte Vertragsprozesse in Wertschöpfungsnetzwerken der Industrie 4.0
Der intelligenten Vernetzung von Maschinen und Prozessen in der Industrie unter Verwendung neuster Technologien – oder kurz Industrie 4.0 – wird das Potenzial zugeschrieben, die nächste industrielle Revolution darzustellen. Sie ist somit stark technologiegetrieben. Populäre Betrachtungsbereiche sind Produktions- und Logistikprozesse, zum Beispiel im Bereich automatisierter Produktionssysteme oder im Transportwesen. Bei näherer Betrachtung lassen sich hierbei Prozesse identifizieren, die in beiden Bereichen von höchster Relevanz sind: Der Abschluss und die Durchführung von vertragsrelevanten Vorgängen. Auf der einen Seite besteht der Wunsch, repetitive Prozesse, wie standardmäßig durchgeführte Vertragsverhandlungen, zu digitalisieren und zu automatisieren. Auf der anderen Seite ist auch die korrekte und rechtlich konforme Durchführung eines Vertrages von hoher Bedeutung. Das Digitalisieren von Vertragskomponenten zur autonomen Vertragsparameterverhandlung ist hierbei sicherlich eine kleinere Herausforderung als die Entwicklung einer Software, welche die eigenen Interessen und Verhandlungsstrategien realisieren kann. Auf rechtlicher Seite muss darüber hinaus zwangsläufig eine Beurteilung automatischer Willenserklärungen und Nachweisbarkeit erfolgen.
In der Realität genügt es daher im Allgemeinen nicht, Verträge lediglich zu digitalisieren. Es müssen darüber hinaus Möglichkeiten geschaffen werden, während oder nach einer Vertragsdurchführung die an einen Vertrag geknüpften Bedingungen und Klauseln einer automatisierten Prüfung zu unterziehen. Beispielsweise ist im Logistikumfeld ein Standgeldprozess bei etwaigen Verzögerungen in einem Transportprozess automatisiert durchzuführen und entsprechende Kosten zu aggregieren. Weiterführende Fragestellungen beschäftigen sich sogar mit Vertrauensfragen, insbesondere, wie Vertrauen automatisiert anhand eines Vertrauensprofils bewertet werden kann. Hieraus können geeignete (digitale) Verhandlungspartner ausfindig gemacht werden.
Das vom Bundesministerium für Wirtschaft und Klimaschutz geförderte Forschungsprojekt und Pilotvorhaben "Industrie 4.0 Recht-Testbed" verfolgt als digitales Experimentierfeld das Ziel einer rechtskonformen Gestaltung und exemplarischen Durchführung automatisierter Vertragsprozesse in Wertschöpfungsnetzwerken [1]. Wenn Maschinen jedoch autonom miteinander kommunizieren und rechtlich relevante Entscheidungen treffen, werden neue Rechtsfragen von hoher Komplexität aufgeworfen. Deren Beantwortung ist hierbei von ebenso großer Relevanz wie das Ergreifen technologiegetriebener Maßnahmen zur Durchsetzung rechtlicher Forderungen und Rahmenbedingungen.
Dieser Artikel bietet einen tieferen Einblick in Konzeption und Architektur des Experimentierfelds und damit einhergehende interessante Lösungsstrategien.
Digitalisierung von Verträgen
Die Anforderungen an digitalisierte Verträge sind auf mehreren Ebenen zu finden, allen voran die natürlichsprachliche Repräsentation zur Lesbarkeit außerhalb der maschinell verarbeitenden Prozesse. Zur Realisierung der maschinellen Verarbeitbarkeit ist eine Modellierung der wichtigen Vertragsgegenstände vorzunehmen, d. h. geeignete und zum Verhandlungszweck ausgewählte Parameter müssen maschinenlesbar sein. Letztlich werden darüber hinaus ausführbare Code-Elemente benötigt, die auf Grundlage des Vertrages verschiedene Prozesse ermöglichen.
Insgesamt entsteht dabei ein Dreiklang aus statischen und dynamischen vertragsrelevanten Komponenten mitsamt einer geeigneten Logik, die es zu realisieren gilt. Diese Komponenten führen zu einem sogenannten "Smart Legal Contract Template", d. h. einer templatebasierten (digitalen) Vertragsstruktur, die alle beschriebenen Elemente enthält und implementiert. Über geeignete Schnittstellen können hierbei Daten für externe Anwendungen zur Verfügung gestellt werden. Ebenso können extern ausgeführte Ereignisse in den Vertragskontext eingebracht werden, um die verschiedenen Prozesse der Vertragsdurchführung zu registrieren und einer etwaigen Prüfung zu unterziehen. Die Implementierung dieser Konzepte erfolgt in diesem Fall durch Open-Source-Software-Tools des Accord-Projektes [2]. Der statische Vertragsteil besteht hierbei aus einem mit Variablen angereicherten, natürlichsprachlichen Vertragstext, der auf einem, in dem Forschungsprojekt ausgearbeiteten, Mustervertrag basiert. Ein kurzer Auszug aus einem Vertrag mit ausgezeichneten Variablen ist in dem folgenden Beispiel gegeben.
Transportauftrag
zwischen
"Versender GmbH"
– nachfolgend „Versender“ genannt –
vertreten durch {{#with Versender}}{{vertreter}}({{partei}}){{/with}}
und
"Transport GmbH"
– nachfolgend „Frachtführer“ genannt –
vertreten durch {{#with Frachtfuehrer}}{{vertreter}}({{partei}}){{/with}}
Versender und Frachtführer einzeln im Folgenden bezeichnet als die „Partei“,
gemeinsam im Folgenden bezeichnet als die „Parteien“.
Empfänger ist: {{#with Empfaenger}}{{vertreter}}({{#with partei}}{{partyId}}{{/with}}){{/with}}
Schiedsrichter ist: {{#optional Schiedsrichter}}{{vertreter}}({{#optional partei}}{{partyId}}{{/optional}}){{else}}Kein Schiedsrichter{{/optional}}
…Die Variablen eines solchen Vertrages können verschiedene Ausprägungen aufweisen. Darunter Personas und Rollen, aber auch vertragsinhaltliche Parameter. Für die Realisierung einer autonomen Vertragsverhandlung ist es notwendig, zwischen verhandelbaren und nicht verhandelbaren Parametern zu unterscheiden. Dies funktioniert durch ein zum Vertragstext korrespondierendes Modell, welches in maschinenlesbarer Form zur Verfügung steht. Wie im zweiten Codebeispiel zu sehen ist, besteht das Modell sowohl aus typisierten Variablen als auch Annotationen, in denen weitere Informationen eines verhandelbaren Parameters gegeben sind. Darunter sind beispielsweise Bezeichner, Beschreibung und Wertebereiche zu finden.
…
o PostalAddress ladeAdresse
o Integer ladeNummer
o String transportgutSpezifikation
o PostalAddress lieferAdresse
@Negotiator("Standgeld","Das Standgeld, das pro vom Versender verschuldeten Standtag an den Frachtführer zu entrichten ist", "[100.0, 500.0, 10.0]")
o MonetaryAmount standgeld
…Das Modell eines zugrundeliegenden Vertrages definiert den dynamischen Vertragsanteil. Die Dynamik zeigt sich dabei in der variablen Parameterbelegung, beispielsweise auf Grundlage der Ergebnisse einer autonomen Vertragsverhandlung.
Zur vollständigen Darstellung eines digitalisierten Vertrages fehlt noch die Logik, durch welche das Modell eine funktionale Signifikanz erlangt. Das Hinzufügen von komplexer Funktionalität zu einem Modell wird durch die Sprache Ergo aus dem Accord-Projekt ermöglicht [3]. Die Anwendungsszenarien von Ergo sind vielfältig und reichen vom Prüfen verschiedener Vertragszustände über das Auslösen von Ereignissen bis zur Validierung der Vertragsparameter.
In einem digitalen Experimentierfeld zur Erprobung von Verhandlung und Ausführung von (digitalen) Verträgen ist hiermit ein zentrales Element bereits praktikabel umgesetzt. Das gesamte Vertragsbeispiel kann im öffentlich verfügbaren GitLab Repository des Projektes eingesehen werden [4].
Autonome Vertragsverhandlungen durch Softwareagenten
Um ein Smart Legal Contract Template als tatsächlichen Vertrag – im Folgenden als Smart Legal Contract (SLC) bezeichnet – instanzieren zu können, muss zunächst eine Einigung auf konkrete Vertragsparameter erfolgen. Die Anforderung dabei ist, eine Verhandlung vollständig autonom durchführen zu können, sodass bis auf eine vorhergehende Konfiguration der Rahmenbedingungen keine weitere Intervention eines Benutzers notwendig ist. Zur Lösung der Anforderung existieren seit einigen Jahren geeignete und agentenbasierte Frameworks wie Genius bzw. GeniusWeb oder JADE [5]. Das "Industrie 4.0 Recht-Testbed" setzt im Kern auf GeniusWeb. Dies bietet den Vorteil, dass bereits einige Verhandlungsprotokolle und Agentenstrategien implementiert sind, die ohne tiefgreifende Modifikationen nutzbar gemacht werden können. Um Softwareagenten effektiv verhandeln zu lassen, sind einige Grundkonzepte zu erforschen. Zunächst benötigt jede Verhandlung eine Art Regelwerk, das die Einhaltung der Verhandlungsrahmenbedingungen sicherstellt. Zur Simplifizierung sei hier illustrativ eine bilaterale Verhandlung zugrunde gelegt, bei der sich zwei Verhandlungspartner auf einen Satz von Vertragsparametern zu einigen versuchen. Der Verhandlungsablauf wird durch ein Protokoll orchestriert, im einfachsten Falle in Form eines Round-Robin-Ansatzes, d. h. die Softwareagenten geben im Wechsel ihre Angebote ab, bis es zu einer Einigung kommt oder die Verhandlung ohne Ergebnis abgebrochen wird.
Die Mentalität des jeweiligen Softwareagenten kann grob beeinflusst werden und lässt die gesamte Spanne zwischen vollkommener Passivität ("Ja-Sager") und übermäßiger Aggressivität zu. Letzteres Extremum beharrt auf den eigenen Forderungen und weicht von diesen nicht ab. Nähert sich der Verhandlungspartner nicht dem eigenen Angebot an, wird die Verhandlung nach Erreichen spezifisch konfigurierter Grenzen (Verhandlungsschritte oder Verhandlungsdauer) ergebnislos abgebrochen. Ein eingehendes Angebot wird in der Regel ein Gegenangebot oder eine Akzeptanz/Ablehnung zur Folge haben. Die Bewertung der etwaigen Lücke zwischen Ist-Angebot und gewünschtem Ziel erfolgt neben weiteren Bedingungen durch die konfigurierte Mentalität des Softwareagenten.
Die automatisierte Berechnung von Gegenangeboten erfolgt durch den Einsatz verschiedener Algorithmen. Gegeben ist dabei ein Satz verhandelbarer Parameter mit entsprechenden Wertebereichen, z. B. Intervalle oder diskrete Werte. Zusätzlich zu der Angabe von Werten, werden obere und untere Grenzen, sowie Schrittweiten für eine Verhandlung konfiguriert. Hiermit lassen sich Parameter entsprechend aufbereiten, sodass ein erster Rahmen für eine Verhandlung gegeben ist. Dieser Parametersatz wird allgemein mitsamt seinen Ausprägungen als Verhandlungsdomäne bezeichnet. Vor der Durchführung einer Vertragsverhandlung haben sich beide partizipierenden Softwareagenten auf die Domäne zu einigen. Hierdurch wird sichergestellt, dass eine Verhandlung auch kontextunabhängig durchgeführt wird und Angebote, sowie etwaige Gegenangebote keine ungewollte Grenzüberschreitung zeigen können.
Zusätzlich zu der Verhandlungsdomäne ist ein Präferenzprofil anzugeben, durch welches die Gewichtung der Domänenparameter bestimmt wird. Insgesamt sind dadurch alle zur Verhandlung notwendigen Informationen gegeben, d. h. die zu verhandelnden Werte inklusive ihrer individuellen Gewichtung. Ausgehend von einem eingehenden Angebot, der Verhandlungsdomäne und dem Präferenzprofil ist es dem Softwareagenten möglich, mit beliebigen Methoden zu einem Gegenangebot zu gelangen. Vor allem die Frameworks Genius/GeniusWeb haben bereits etliche Methoden implementiert, die out-of-the-box zur Verfügung stehen. Es können allerdings auch beliebige andere Methoden selbst implementiert werden, beispielsweise unter Verwendung geeigneter KI-Methoden oder evolutionärer Algorithmen. Die denkbare Bandbreite zur Individualisierung des Verhaltens während einer Verhandlung ist hinreichend groß. Hier spielen die eigenen Anforderungen und unternehmensspezifischen Umstände eine wesentliche Rolle.
Vertragsschluss und Vertragsbündel
Kommt es bei der Verhandlung der Softwareagenten zu einer Einigung, ist aus rechtlicher Sicht eine vorgeschriebene Choreographie durchzuführen, der sogenannte Vertragsschluss. Einfach ausgedrückt ist eine Unterzeichnung beider Parteien und gegenseitiges Sichten des unterzeichneten Dokumentes notwendig (s. Abb. 1).
Für das digitale Vertragsdokument wird eine eigens dafür vorgesehene Datenstruktur eingeführt, das Vertragsbündel. Diese Datenstruktur wird durch ein JSON Web Token realisiert und kapselt den gesamten digitalen Vertrag, d. h. den natürlichsprachlichen Vertragstext, das Modell, das definierte Verhalten und selbstverständlich die ausgehandelten Vertragsparameter. Zusätzlich enthält dieses – wie gefordert – die digitale Signatur des Vertragsabschließers der jeweiligen Partei. Nach beidseitiger Prüfung und Bestätigung des Verhandlungsergebnisses muss der Vorgang nachvollziehbar und revisionssicher persistiert werden. Die Anforderungen an dieses Persistenz-System legen den Einsatz einer modernen Blockchain-Technologie nahe. Anstelle eines spezifischen Frameworks wie Hyperledger Fabric oder Tendermint nutzbar einzubinden, ist es ein wichtiges Architekturziel, zumindest beide genannten Lösungen dynamisch austauschbar zu machen [6]. Der Einsatz einer Blockchain-Technologie bietet mehrere Vorteile, allen voran die interne Integration in das Accord-Projekt. Hierdurch ist es möglich, in direkter Weise von den SLC’s ausgehend mit einer Blockchain zu interagieren. Der Integrationsaufwand für andere Zugriffsanforderungen sinkt demnach für die Entwicklung des eigentlichen Systems. Ein weiterer Vorteil der Blockchain-Technologie ergibt sich aus der revisionssicheren Persistenz von transaktionalen und vertragsrelevanten Ereignissen im Ablauf der Vertragsdurchführungsprozesse.
Qualitative Anforderungen an das Experimentierfeld
Die bisher eingeführten Grundkonzepte und ausgewählten technischen Komponenten basieren auf architektonischen Entscheidungsprozessen. Denen liegen qualitative Anforderungen zugrunde, die in diesem Abschnitt kurz diskutiert werden, um einen Kontext für die Architekturentscheidungen bei einem solchen System zu geben.
Grundlegende Voraussetzung für vertragsrelevante Prozesse ist ein hohes Maß an Sicherheit und dabei vor allem die Kernmerkmale Vertraulichkeit, Integrität, Nichtbestreitbarkeit, Authentizität und Verantwortlichkeit. Es müssen hohe Sicherheitsstandards für sensible Daten und Vorgänge eingesetzt werden und es ist sicherzustellen, dass Anwender nur Daten sehen können, für welche sie autorisiert sind. Interne Vorgänge im System dürfen sich hierbei nicht gegenseitig beeinflussen. Alle Kommunikationswege sind mittels geeigneter Protokolle abzusichern. Ferner ist es wichtig, dass sensible Daten (z. B. Vertragsdaten) kompromitierfrei dokumentiert werden. Die Rechtsverbindlichkeit wird letztlich entsprechend der Erkenntnisse des Projektes technisch unterstützt und sichergestellt.
Ein weiteres Hauptmerkmal ist die funktionale Eignung, weshalb sicherzustellen ist, dass die angebotene Funktionalität korrekt umgesetzt wird. Definierte Toleranzen und Genauigkeiten der Darstellung werden hierzu anhand der funktionalen Anforderungen umgesetzt und ausführlich getestet. Hier ist demnach vor allem die funktionale Korrektheit zu betrachten.
Die Verfügbarkeit als spezifisches Merkmal der Zuverlässigkeit ist ebenfalls eines der Hauptziele qualitativer Art. Hier ist zu beachten, dass nicht nur die Komponentenverfügbarkeit ein wichtiges Merkmal dieser Dimension ist, sondern auch die aktive Sicherstellung von Parallelität. Hierdurch werden parallele Experimentierprozesse betrachtet, die korrekt und störungsfrei ablaufen müssen. Das System selbst sowie "externe Fremdsysteme" müssen allgemein die gleichen Verfügbarkeitsvorgaben erfüllen.
Zusätzlich zu den qualitativen Anforderungen wird mit Architekturprinzipien gearbeitet, die weitere (weiche) Aspekte berücksichtigen, sodass Querschnittskonzepte oder grundlegende Entscheidungen entsprechend organisiert sind. Hierzu gehört beispielsweise die einfache Austauschbarkeit verschiedener Technologien zur Unterstützung der Evaluation gesetzter Forschungsfragen – Stichwort Blockchain-Technologie. Ebenso soll ein modularer Aufbau des Gesamtsystems die Flexibilität im Deployment erhöhen. In der Implementierungsphase ist tatsächlich ein Shift vorgenommen worden, der von einem Deployment-Monolithen auf einer virtuellen Maschine zu einem Kubernetes-Cluster als neue Zielinfrastruktur geführt hat. Dies stellt die Architekturentwicklung vor neue Herausforderungen, die zukünftig weiter bewältigt werden müssen, an dieser Stelle jedoch nicht weiter thematisiert werden sollen.
Lösungsstrategien zur Architekturentwicklung
Ein wesentliches Ziel des Systems ist eine juristische Nachvollziehbarkeit zu ermöglichen. Dies ist vor allem dann von Bedeutung, sollte es zu einem Disput kommen, der manuell durch Juristen zu prüfen ist. Es ist daher nicht nur bei Reports oder anderen Extrakten auf eine geeignete Fachterminologie zu achten. Um dieser Anforderung von Beginn an gerecht zu werden, ist eine domänengetriebene Modellierungsmethode zum Erarbeiten einer branchenüblichen Fachterminologie zum Einsatz gekommen (Domain-Driven Design [7]). Für jene Modellierungsmethode existieren geeignete Architekturmuster, die in dem Umfeld erfahrungsgemäß häufig eingesetzt werden und die Modellierung weiter unterstützen. Im Hinblick auf die gesetzten Ziele und Qualitätsanforderungen kommt, wie Abb. 2 verdeutlicht, zur Strukturierung dieses Systems ein hexagonales Architekturmuster zum Einsatz. Dieses hat gleich mehrere Vorteile, jedoch im gleichen Zug eine höhere Komplexität bei der Implementierung. Die Idee dabei ist es, das Domänenmodell im Kern zu modellieren, da dies erfahrungsgemäß seltener grundlegenden Änderungen unterworfen ist. Um das Modell herum werden verschiedene Services realisiert. Fremdsysteme oder weitere Komponenten können mit Hilfe dieses Musters über Ports angesprochen werden. Daher wird dieses Muster oft als Ports-&-Adapter-Muster bezeichnet. Es sind dabei primäre und sekundäre Ports zu unterscheiden, wobei erstere für extern motivierte Interaktionen bspw. ausgehend von einer Benutzeroberfläche zu nutzen sind. Sekundäre Ports führen etwa zu Adaptern, welche für die Persistenz verantwortlich sind. Insgesamt ist hier davon auszugehen, dass Abhängigkeiten lediglich in Richtung Domänenmodell zeigen, jedoch nicht von innen heraus Abhängigkeiten aufgebaut werden. Dies hat den Vorteil einer vereinfachten Austauschbarkeit der realisierten Adapter. Ein populärer Ansatz bei der Implementierung ist die Einbindung von Adaptern über das Dependency-Injection-Entwurfsmuster. Vor allem bei der Verwendung von Frameworks wie Spring Boot oder Quarkus ist diese Art des Musters mit minimalem Aufwand implementierbar, sodass in den Adaptern realisierte Technologien auf einfache Art und Weise austauschbar gemacht werden [8]. Durch die geschickte Definition der Ports sind insgesamt stabile Schnittstellen möglich, die einen Kontrakt für die Interaktion festschreiben und somit zur Zielerreichung beitragen.
Grundlegende Architektur des Experimentierfelds
Anhand der definierten Ziele und Prinzipien mitsamt den Vorüberlegungen von Stilen und Mustern ist es möglich, einen ersten Entwurf zur Systemstrukturierung auszuarbeiten. Dabei besteht der erste Modellierungsschritt in einem vorbereitenden Workshop, dem sogenannten Event Storming [9]. Im Rahmen des Workshops entsteht eine erste Version der Sprache, die bei der Modellierung verwendet wird und branchenüblichen Standards entsprechen sollte. Je nach Zeitaufwand und Tiefe der Betrachtung können bereits erste Modelle im Kontext des Domain-driven Design entworfen werden. Eine vereinfachte Modellierungsversion ist in Abb. 3 zu finden.
In dieser ersten Version ist noch keine Aufteilung nach einzelnen Domänen vorgenommen, sondern lediglich die Identifikation einzelner Kontexte erfolgt. Das Modell enthält jedoch bereits alle bisher diskutierten Bestandteile, darunter
- das Vertragssystem zur Verarbeitung von Smart Legal Contracts,
- ein Verhandlungssystem zur Realisierung der autonomen Vertragsverhandlung inklusive der Softwareagenten in stark abstrahierter Form,
- ein Vertragsdurchführungssystem zur Orchestrierung der Prozessschritte eines zugrundeliegenden Vertrags und letztlich auch
- ein Blockchain-System, das repräsentativ für verschiedene Blockchain-Technologien steht.
Legt man dem System ein monolithisches Gebilde zugrunde, so lässt sich bereits eine erste Strukturierung vornehmen, die auf das hexagonale Architekturmuster abgebildet werden kann. Eine abstrahierte Form der Darstellung ist in Abb. 4 zu finden. Die darin modellierte Domäne ist modular aufgebaut, sodass eine möglichst lose Kopplung zwischen den Modulen erreicht wird, die ein späteres Slicing in eine verteilte Architektur erleichtert. Erreicht wird das vorrangig durch eine Objektorchestrierung durch einzelne Services, d. h. es bestehen zwischen den Modulen keine direkten Abhängigkeiten. Dies ist vor allem dann wichtig, wenn das System auf eine Kubernetes-Infrastruktur deployt und entsprechend aufbereitet wird. Die einzelnen Module werden allgemein angereichert durch eine Schicht von modulbezogenen Services, die aufgrund einer hohen Kohäsion eng auf die Zuständigkeiten der bezogenen Module spezialisiert sind. Die Ports und Adapter des zugrundeliegenden Architekturmusters sind besonders ausgezeichnet. Abgebildet sind jedoch nur sekundäre Ports, da in diesem System lediglich ein primärer Port für den Zugriff über eine Weboberfläche existiert. Die logische Interoperabilitätsschicht dient der Ansprache von Kommunikationsendpunkten, in diesem Fall über HTTP REST. Die entsprechenden Ports haben ebenfalls eine Implementierung direkt im System, die allerdings in der Interoperabilitätsschicht logisch zu verorten ist.
Insgesamt wird durch den Einsatz dieses Architekturmusters das Ziel erreicht, wenige, aber klare Abhängigkeiten in das Innere des Systems aufzubauen. Die Gesamtarchitektur ist dabei klar strukturiert und leicht verständlich. Eine spätere Umorientierung auf eine verteilte Architektur ist hierbei mit wenig Aufwand möglich. Aktionen auf und innerhalb der Kerndomäne werden ausschließlich über Services orchestriert, d. h. es gibt zentrale Steuerungspunkte, an denen zuvor definierte Domänenereignisse ausgeführt werden können. Dies spiegelt in direkter Weise Konzepte des Domain-driven Designs wider, in denen Domain Events ausgeführt werden, die im Allgemeinen Prozessstrukturen der zugrundeliegenden Domäne abbilden können.
Ein erstes Slicing und die Umgestaltung der monolithischen Grobkomponentenarchitektur (Abb. 4) kann, wie in Abb. 5 zu sehen ist, vorgenommen werden. Der Ansatz einer microservice-basierten Architektur sorgt hierbei für eine bessere Erreichung qualitativer Ziele. Ein weiterer Vorteil ergibt sich aus der Konkretisierung des Deployment-Modells auf einer Kubernetes-Infrastruktur. Einzelne Module können durch gezielte Wahl der Replikate eine signifikant verbesserte Verfügbarkeit aufweisen. Die einfache Skalierung der entsprechenden Module im Cluster reduziert etwaige Engpässe bei der Durchführung von Experimenten, welche zum Teil mit erheblichen Laufzeiten versehen sind.
Die Darstellung weist darüber hinaus ein fehlendes Persistenzkonzept auf, welches in diesem System im Gesamten vernachlässigt wird. Aufgrund verschiedener Umstände ist eine benutzerinduzierte Persistenz nicht in direkter Weise angedacht. Lediglich das Sichern von Experimenten über geeignete Export- und Importfunktionalitäten wird in einem zukünftigen Release bereitgestellt.
Szenarien und Anwendungsbezug
Zur Entwicklungszeit des Systems werden zwei zentrale Anwendungsfälle aus den Bereichen Transport und Produktion betrachtet. Einen Kontext erhalten diese Anwendungsfälle durch umfangreich gestaltete Szenarien, etwa einem Warentransport von einer versendenden zu einer empfangenden Partei. Einem Szenario liegt dabei stets ein wohldefinierter Prozess zugrunde, durch welchen konkrete Abläufe abgebildet werden. Ein vollumfängliches Szenario besteht hierbei aus verschiedenen Experimenten und damit einhergehenden Prozessen. Zunächst wird bezugnehmend auf den Fall des Warentransportes zwischen dem Versender und dem Logistikdienstleister als Frachtführer ein Transportvertrag ausgehandelt und insbesondere der Prozess des Vertragsschlusses durchgeführt. Die anschließende Leistungserbringung, d. h. das Abholen und Transportieren der Waren, ist Teil der Vertragsdurchführung. Dieser Prozess kann sowohl automatisiert als Experiment ausgeführt werden als auch mit einem späteren Release interaktiv gestaltet sein. Dadurch besteht die Möglichkeit, cyber-physische Systeme oder in der physischen Welt stattfindende Prozessschritte in das Experimentierfeld zu integrieren. Zum Schutz gegen das Vorleistungsrisiko soll im späteren Verlauf der Experimente die Möglichkeit bestehen, eine automatisierte Zahlung zu veranlassen und somit die Gegenleistung zu erbringen.
Die Szenarien können letztlich auch Leistungsstörungen in Form von Störfällen abbilden, die eine höhere Variation in den Experimenten ermöglichen. Denkbar sind beispielsweise Situationen, in denen durch Verzögerungen eine Standgeldberechnung notwendig wird. Auch weniger komplexe Störfälle sind denkbar, etwa Beschädigungen an den Waren oder das Nichteinhalten von vereinbarten Fristen. Allen denkbaren Fällen ist jedoch gemein, dass genau geprüft werden kann, wie sich ein zuvor entwickelter Smart Legal Contract verhält, bevor dieser in einem realen System eingesetzt wird. Die lückenlose Dokumentation aller Transaktionen und Interaktionen in Form von Ereignissen ist im Experimentierfeld durch den Einsatz einer Blockchain-Technologie zu jeder Zeit sichergestellt.
Fazit
Auf dem Weg zu automatisierten Vertragsprozessen in Wertschöpfungsnetzwerken eignet sich das in diesem Artikel präsentierte Experimentierfeld ausgezeichnet, um erste Erfahrungen mit der Thematik zu sammeln und eigene Entwicklungen voranzutreiben. So können perspektivisch eigene Softwareagenten mit Hilfe geeigneter Blaupausen entwickelt und in einer Vertragsverhandlung auf Herz und Nieren geprüft werden. Ebenso ist es zukünftig möglich, eigene Smart Legal Contracts zu entwickeln und deren korrekte Ausführung zu bewerten. Das weiterhin in der Entwicklung befindliche Reportangebot des Experimentierfelds wird dabei Einblicke in die Prozessdetails geben und den Analysten und Entwicklern weitere Hinweise zu den Prozessabläufen liefern. Je nach digitalem Reifegrad ist eine (partielle) Nutzung des Experimentierfelds für viele Unternehmen interessant, um erste Schritte oder einen weiteren Schritt in Richtung Digitalisierung zu gehen.
- Industrie 4.0 Recht-Testbed
- Accord Projekt
- Ergo
- GitLab: Recht-Testbed
- Genius, GeniusWeb, JADE
- Hyperledger Fabric, Tendermint
- Domain-driven Design-Referenz
- Spring Boot, Quarkus
- Introducing Event Storming
