Der Requirement Twin von Brownfield-Industrieumgebungen

AutomationML als Datenmodellierungssprache des Requirement Twin

Der grundlegende Ansatz innerhalb der Initiative Industrie 4.0 besteht in der Vernetzung und virtuellen Repräsentation von Assets als Voraussetzung für deren Koordination und Kooperation. Im Kontext der Asset Administration Shell (AAS) ist der Datenaustausch zwischen verschiedenen IT-Systemen entscheidend. Die Plattform Industrie 4.0 beschreibt die Technologien, die während den verschiedenen Phasen des Lebenszyklus eines Assets eingesetzt werden sollen, anhand des Referenzarchitekturmodells Industrie 4.0 (RAMI 4.0). Ein Asset kann neben einem Produkt auch eine Anlage oder ein Objekt in einer bestehenden Industrieumgebung (Brownfieldentität) darstellen. Das Modell ermöglicht die Repräsentation aller relevanten Merkmale hinsichtlich Architektur, Lebenszyklus, Wertschöpfung und Hierarchie eines Assets. Die Unified Modelling Language (UML), ein technologieneutrales Format, wird für den Entwurf der AAS verwendet. Dieses Format wird serialisiert und als Schemadaten in Extensible Markup Language (XML), JavaScript Object Notation (JSON) oder Resource Description Framework (RDF) gespeichert [1, 2].

Im Rahmen der AAS stehen für die Abbildung eines Assets in den verschiedenen Lebenszyklusphasen diverse Formate zur Verfügung, wie z. B. Automation Markup Language (AutomationML/AML), Extensible Markup Language (XML), JavaScript Object Notation (JSON), Resource Description Framework (RDF) und Open Platform Communications – Unified Architecture (OPC UA) [3]. Bild 1 zeigt die Verwendung der verschiedenen Formate im Kontext des RAMI 4.0. Die Repräsentation der AAS erfolgt dabei mittels AML und OPC UA. Die in der Entwicklung verwendeten Informationsmodelle werden durch AML standardisiert. In dieser Phase wird das Teilen wichtiger allgemeiner und individueller Asset-Merkmale ermöglicht. Der Standard für die in der Produktion verwendeten Informationsmodelle ist OPC UA. Dieser bietet Zugang zu allen administrativen Daten und teilt Informationen aus der industriellen Tätigkeit. Die erzeugten Daten können in einem Format gespeichert und mittels XML und JSON gemeinsam genutzt werden. Die Informationen werden über RDF abgebildet, wodurch die Vorteile semantischer Technologien ausgeschöpft werden können [1].

Bild 1

AutomationML als Modellierungssprache des Requirement Twins im Kontext des RAMI4.0 (Quelle: Tobias Federl i. A. an [1])

Die Entwicklung eines Requirements Twin, der als Digitaler Zwilling von Industrieumgebungen fungiert, dient der optimierten Integration von verfahrenstechnischen Anlagen. Durch die Ausführung des Requirement Twins als informationstechnisches Modell, welches mit Informationen über die bei einer Anlagenintegration auftretenden Anforderungen angereichert werden kann, stellt es ein digitales Anforderungsmodel zur Verwendung in der Entwicklung einer Anlage dar. AutomationML als AAS-Repräsentation erfüllt den notwendigen Umfang für die Entwicklung eines Requirement Twins. Die objektorientierte Modellierungssprache AutomationML nutzt die Auszeichnungssprache XML, um die verfügbaren Informationen darzustellen. Die in einer AAS enthaltenen Informationen können mit AML strukturiert und verarbeitet werden. [4]

Der Requirement Twin im Überblick

Der Requirement Twin stellt eine datentechnische Beschreibung einer Industrieumgebung dar, die als Basis für eine multidimensional-optimierte Integration einer verfahrenstechnischen Anlage dient. Dieser wird als „Single Source of Truth” für anschließende Prozesse im einheitlichen maschinenlesbaren und -interpretierbaren Datenaustauschformat AutomationML definiert. Dadurch wird ein durchgängiges Umsetzungsmanagement im Rahmen des Anforderungsmanagements ermöglicht. Bild 2 zeigt die Struktur eines Requirement Twin auf Basis von AutomationML im Überblick. Infolge eines Forschungsprojekts bei der Siemens AG wurde der Requirement Twin entwickelt, mit dem vorrangigen Ziel, die Effizienz und Präzision bei der Integration von Anlagen erheblich zu steigern. Dieses neuartige Instrument repräsentiert einen bedeutsamen Fortschritt im Bereich der Anlagentechnik und verspricht, sowohl die Leistungsfähigkeit als auch die Verlässlichkeit von Anlagen in diversen industriellen Kontexten zu erhöhen.

Bild 2

Struktur des Requirement Twins auf Basis von AutomationML

Der Requirement Twin basiert auf analysierten Merkmalen zur Beschreibung von Entitäten einer Industrieumgebung. Diese werden mithilfe von Bedingungen in AutomationML zur Abbildung von Anforderungen aufbereitet. Die Merkmale werden ohne Wertedefinition und somit standardisiert in einer Brownfield-Merkmalsbibliothek angelegt. Durch diesen Umstand können diese unabhängig von einem spezifischen Projekt verwendet werden. Die Wertdefinition eines Merkmals erfolgt erst bei der Zuweisung zu einer Entität des projektspezifischen Browfields. Die Brownfield-Merkmalsbibliothek beinhaltet sowohl generische als auch spezifische Merkmale sowie Anforderungsmerkmale. Diese dienen zur vollständigen und anforderungsgerechten Beschreibung einer Brownfield-Entität

AutomationML greift als Sprache auf das CAEX-Format zurück. Das darin etablierte Bibliothekskonzept bietet neben der Bibliothek für Merkmale auch eine Bibliothek für Rollenklassen und Schnittstellenklassen. Innerhalb dieser Bibliotheken sind für eine projektunabhängige Verwendung eine standardisierte Brownfield-Rollenklassenbibliothek und eine Brownfield-Schnittstellenklassenbibliothek enthalten. Durch die Brownfield-Rollenklassenbibliothek wird eine Maschineninterpretierbarkeit der Entitäten eines Requirement Twins ermöglicht. Obwohl die Entitäten in dieser Bibliothek auf ihren Typ abstrahiert vorliegen, können den Rollen der Entitäten sowohl generische als auch spezifische Merkmale sowie Anforderungsmerkmale zugewiesen werden. Dies schafft eine einheitliche und standardisierte Basis für die Beschreibung und Kommunikation von Entitäten eines Brownfields in AutomationML, welche sich flexibel auf die Kundenanforderungen anpassen lässt. [5]

Um den Aufbau einer funktionalen Stückliste einer Anlage und des Brownfields mithilfe der hierarschichen Modellierungsstruktur von AutomationML abzubilden, ist es notwendig, die von AutomationML vorgegebene Bibliothek AutomationMLBaseRoleClassLib zu erweitern [5]. Mithilfe dieser Erweiterung und der vorgebenen Rollenklassen aus der AutomationMLBaseRoleClassLib können die einzelnen Ebenen funktionaler Stücklisten in einer hierarchischen Struktur abgebildet werden. Die Abbildung erfolgt durch die Anwendung von Regeln zur Verwendung von Referenzen auf die Rollenklassen. Dies ermöglicht eine datentechnische Beschreibung der Entitäten sowohl für die anforderungsgerechte kundenspezifische Anlage als auch for das anforderungsgerechte Brownfield sowie deren Beziehungen untereinander. Das Datenmodell der Anlage zeigt dabei einen Lösungsansatz auf, bei dem kundenspezifische Anpassungskonstruktionen (Custom Order Engineering – COE) konsistent in der Anlagenstückliste verortet werden.

Stücklisten als Datenmodelle von AutomationML

Die aus Anforderungen an die Anlagenintegration in eine bestehende Industrieumgebung resultierenden kundenspezifischen Anpassungen (COE-Komponenten) bedeuten häufig einen hohen Kosten- und Zeitaufwand [6]. Um COE-Komponenten zu vermeiden, welche stets der Anlage zugeordnet werden, müssen diese mit bestehenden Varianten synchronisiert und konsistent in der Stückliste der Anlage verortet werden können. Dafür wird die Stücklistenterminologie erweitert. Bereits etablierte Stücklistenansätze wie die Varianten- bzw. 150 %-Stückliste berücksichtigen verschiedene Ausprägungen eines Produkts [7]. Wird die funktionale Struktur zusätzlich um COE-Objekte angereichert entsteht eine 200 %-Stückliste. COE-Objekte stellen eine weitere Ausprägung von Varianten dar und fungieren so als Template mit spezifizierten Attributen, jedoch ohne Wertdefinition. Entspricht keine vorhandene Variante den gestellten Kundenanforderungen, muss eine Neukonstruktion angestoßen werden. Sollten diese COE-Objekte anschließend für zukünftige Projekte „wiederverwertbar“ klassifiziert werden, so werden diese COE-Objekte als neue Variante in die 200 %-Stückliste integriert. Die Entscheidung über diese Maßnahme obliegt den Produkt- bzw. den Anlagen-Verantwortlichen.

Um neue COE-Objekte als Varianten zur Verfügung zu stellen, erfolgt die datentechnische Modellierung an einer Referenzanlage als SystemUnitClass einer SystemUnitClassLibrary. Diese Bibliothek ermöglicht die Erstellung von Spezifikationen herstellerspezifischer Produkte bzw. Anlagen. Zur Modellierung wird die Semantik bereits existierender und neu zu definierender Rollen aus der AutomationMLBaseRoleClassLib verwendet. Durch die Verwendung von Rollenklassen aus dieser erweiterten AutomationMLBaseRoleClassLib bietet dieses Bibliothekskonzept die Möglichkeit der Abbildung von funktionalen Stücklisten [5].

Dabei erhält jedes Element der hierarchischen Struktur dessen funktionale Stücklistenbedeutung. Bild 3 zeigt die Rollenzuweisungsregeln einer funktionalen 200 %-Stückliste, um diese in einer hierarchischen Struktur abbilden zu können. Dabei wird die oberste Strukturebene einer Anlage stets mit einer Referenz auf die RoleClass „Resource“ in eine hierarchische Struktur überführt. Die funktionalen Baugruppen einer 200 %-Stückliste werden differenziert betrachtet. Besitzt eine funktionale Baugruppe ausschließlich Komponenten und/oder weitere funktionale Unterbaugruppen, so wird die Baugruppe in der hierarchischen Struktur auf die RoleClass „ProductStructure“ referenziert, um diese als solche identifizierbar zu machen. Die untergeordneten Datenobjekte, welche Komponenten aus der Stückliste repräsentieren, werden auf die RoleClass „Product“ referenziert. Besteht eine funktionale Baugruppe aus Varianten, COE-Komponenten und weiteren Baugruppen, wobei die letzteren beiden nicht enthalten sein müssen, so wird diese Baugruppenausprägung mithilfe der RoleClass „VariableProductStructure“ in der hierarchischen Struktur abgebildet. Die Varianten und COE-Komponenten werden in der hierarchischen Struktur auf die RoleClasses „Variant“ bzw. „COE“ referenziert. Sie werden aber zugleich auch der Rolle „Product“ zugeordnet.

Bild 3

Rollenzuweisungsregeln zur Abbildung einer funktionalen Struktur einer Anlagenstückliste auf eine hierarchische Struktur

Die Architektur des Datenmodells der 100 %-Stückliste einer Anlage folgt aus der optimiert kundenspezifischen Instanziierung des Datenmodells der 200 %-Stückliste einer Anlage (Bild 4). Bei der Instanziierung eines 200 %-Stücklisten-Datenmodells wird die konkrete 100 %-Ausprägung des Datenmodells der Anlage festgelegt. Da dies die vollständig beschriebene, in das Brownfield zu integrierende, verfahrenstechnische Anlage darstellt, wird das Datenmodell der 100 %-Stückliste im Gegensatz zum Datenmodell der 200 %-Stückliste in der AutomationML-Methode in deren InstanceHierarchy modelliert. Die InstanceHierarchy ist eine hierarchische Struktur in AutomationML, die verschiedene Instanzen von Komponenten und Geräten repräsentiert, um deren Beziehungen und Verbindungen klar darzustellen [5]. Im Rahmen der Instanziierung werden die Varianten als Komponenten der Anlage ausgewählt, die den geforderten Kundenanforderungen genügen. Im Datenmodell entspricht dieser Vorgang einem Auswahlprozess der auf die RoleClasses „Variant“ oder „COE“ referenzierenden InternalElements. Das ausgewählte InternalElement als Repräsentation einer vorliegenden Variante durchläuft anschließend einen Änderungsprozess der Rolle. Die Referenz wird dabei zu einer Referenz auf die RoleClass „Product“ im 100 %-Stücklisten-Datenmodell geändert. Folglich wird in diesem Änderungsprozess ebenfalls die Rolle des InternalElements der übergeordneten Baugruppe eines 200 %-Stücklisten-Datenmodells angepasst. Baugruppen mit einer Referenz zu der Rollenklasse „VariableProductStructure“ werden dabei auf eine Referenz zu der Rollenklasse „ProductStructure“ transformiert. Wird von den Projektverantwortlichen entschieden, dass das neu entwickelte COE-Objekt auch in weiteren Projekten wiederverwendet werden soll, wird dieses Objekt als Variante in das 200 %-Stücklisten-Datenmodell aufgenommen. Dabei wird in dem InternalElement nicht länger auf die RoleC-lass „COE“ referenziert, sondern nun auf die RoleClass „Variant“ und „Product“.

Bild 4

Die Stückliste der verfahrenstechnischen Anlage als Datenmodell mittels AutomationML

In der IT-Architektur eines Brownfield-Datenmodells werden die Entitäten eines Brownfields zunächst als „einfache“ Stückliste betrachtet, in welcher jede Entität mit all ihren Informationen untereinander aufgelistet werden. Je nach Ausprägung der zu integrierenden Anlage werden die Projektbeteiligten aufgefordert eine Auswahl der Infrastruktur-Schnittstellen zwischen Integrationsumgebung und Anlage zu treffen. Um z. B. den Anschluss einer Anlage an einen geeigneten Stromkreis zu gewährleisten und dabei die Anforderung minimaler Kabellängen zu erfüllen, ist es erforderlich, die zugrunde liegenden datentechnische Ausprägung der Infrastruktur in der Brownfield-Stückliste zu berücksichtigen. Hierzu wird die Funktional Substituierbare Schnittstelle (FSS) eingeführt. Diese kategorisiert funktional Schnittstellen des Brownfields nach den Anforderungen der Anlage. Die FSS ist von der Anlage abhängig, da unterschiedliche Anlagen jeweils spezifische Schnittstellen und technische Anforderungen aufweisen. Wenn beispielsweise zwei Anschlussmöglichkeiten zur Energieversorgung im Brownfield vorhanden sind, die beide eine adäquate Energieversorgung für die Anlage sicherstellen, so können diese in einer FSS zusammengefasst werden.

Eine nachfolgende Optimierung, z. B. nach dem kürzesten Kabel-Weg, legt die zu wählende Anschlussmöglichkeit anforderungsgerecht fest. Um eine verfahrenstechnische Anlage effizient in ein Brownfield zu integrieren, ist es notwendig, die funktionale Stückliste des Brownfields in Form eines hierarchischen Datenmodells abzubilden. Damit die hierarchischen Strukturelemente eindeutig den Elementen der Stückliste zugeordnet werden können, müssen analog zu dem Datenmodell der 200 %-Stückliste Referenzen zu RoleClass-Elementen aufgebaut werden, in denen die Semantik der Stücklistenelemente hinterlegt ist. Die zu referenzierenden Rollen sind in der erweiterten AutomationML BaseRoleClassLib festgelegt. Die Zuweisung zu RoleClass-Elementen unterliegt dem Zweck der Standardisierung der Rollenzuweisungsregeln. Bild 5 zeigt die Rollenzuweisungsregeln für eine funktionale Brownfield-Stückliste, um diese in einer hierarchischen Struktur abbilden zu können.

Bild 5

Rollenzuweisungsregeln zur Abbildung einer funktionalen Struktur einer Brownfieldstückliste in einer hierarchischen Struktur

In Bild 6 wird die Struktur eines modellierten Brownfields in der Instance-Hierarchy von AutomationML dargestellt. Die oberste Hierarchieebene, das gesamte Brownfield, verweist auf die RoleClass „BrownfieldStructure“. Durch diese Rollenzuweisung wird die automatische Identifikation der nachfolgenden hierarchischen Struktur in Form einer Brownfield-Stückliste ermöglicht. Diese muss in der nachfolgenden Hierarchieebene ein Datenobjekt mit einer Referenz zu der RoleClass „Brownfieldentity“ besitzen, um eine Struktur darzustellen. Dies ist eine Minimalanforderung an das Datenmodell. Wird bei einem verschachtelten Datenobjekt eine Referenz zu der RoleClass „Brownfieldentity“ aufgebaut, so wird dies als Entität des Brownfields identifiziert. Kann eine analagenspezifische FSS gebildet werden, so ist diese auf die RoleClass „FSSStructure“ zu referenzieren. Diese muss wiederum als Minimalanforderung zwei Datenobjekte besitzen, welche jeweils eine Referenz auf die RoleClass „Brownfieldentity“ aufweisen.

Bild 6

Die Stückliste des Brownfields als Datenmodell mittels AutomationML

Durch die Zuweisung von Rollen aus der Bibliothek für Brownfieldentitäten zu jedem Objekt in der neu definierten Hierarchiestruktur des Brownfield-Datenmodells werden sowohl generische als auch spezifische Merkmale und Anforderungsmerkmale den Datenobjekten in Form von Attributen zugeordnet. Eine erneute Zuweisung der Attribute ist somit nicht notwendig. Zuweisungen von Entitäten-spezifischen Merkmalen in Form von Attributen sind auf jeder Hierarchieebene möglich. Hier erfolgt die Wertedefinition der Merkmale im Brownfield-Datenmodell, das nun die bestehende Industrieumgebung vollständig anforderungsgerecht beschreibt.

Zusammenfassung und Ausblick

Die Implementierung der beschriebenen Methode ermöglicht die Ablösung der verteilt und unvollständig vorliegende Datenlage über das Brownfield und reduziert den Einsatz von COE-Komponenten im Schnittstellenbereich bei der physischen Integration von verfahrenstechnischen Anlagen. Der Requirement Twin stellt eine standardisierte „Hülle“ dar, die von den Verantwortlichen eines Anlagenprojektes laufend mit projektspezifischen Informationen angereichert wird. Dabei wird von einer vollständigen Datenlage über das Brownfield ausgegangen. In weiteren Untersuchungen müssen Methoden entwickelt werden, um unbekannte Informationen über ein Brownfield zu erfassen und zu analysieren. Aufbauend auf der entwickelten Methode bietet die semantische Definition der Anlagenkomponenten und der Aufbau einer Anlagen-Merkmals- und Anlagen-Schnittstellenbibliothek einen weiteren Anknüpfpunkt. Durch die Nutzung des Requirement Twins für die Beschreibung von verfahrenstechnischen Anlagen lässt sich eine vollständig durchgängige datentechnische Beschreibung eines Anlagenintegrations-projektes in ein Brownfield realisieren und ein integriertes Datenmanagement erreichen. Das Datenmodell kann dann weiterführend als „Single Source of Truth“ bei der Erstellung von 3D-CAD-Modellen (digitales Abbild der Anlage) dienen. Es besteht weiterhin Potenzial bei der Automatisierung von Entscheidungsprozessen. Auf Grundlage des maschinenlesbaren und maschineninterpretierbaren Requirement Twins lässt sich dessen Datenmodell auslesen und unter Verwendung von Methoden der künstlichen Intelligenz automatisierte Entscheidungsstrukturen aufbauen. Dabei können multidimensionale Optimierungsaspekte, wie z. B. die Nachhaltigkeit, technische Funktionalität oder die Errichtungsdauer berücksichtigt werden. Diese können dann unter einer Gewichtung der Aspekte dazu genutzt werden, Anpassungen und Veränderungen im Datenmodell der Brownfield- Industrieumgebung vorzunehmen, eine Variantenauswahl bei den Anlagenkomponenten zu treffen oder eine neue COE-Komponente anzustoßen. Die vorgestellte Methode ist nicht ausschließlich für den Bereich der Verfahrenstechnik relevant. Ihre Anwendungspotenziale erstrecken sich auch auf andere Branchen. Ein Beispiel ist die Automobilindustrie, wo sie für die Integration von Komponenten wie einem Motor in eine Autokarosserie genutzt werden könnte.