Fluid 4.0 – das öffentlich geförderte Projekt, in dem Wissenschaft, Gremien und Industrie aus den Bereichen Maschinen- und Anlagenbau, Komponentenlieferanten und Softwareherstellern gemeinsam aktuelle, digitale Herausforderungen mit Industrie-4.0-Technologien adressieren.
Technologisch liegt der Fokus dabei auf der Asset Administration Shell (AAS), die im Mittelpunkt der Entwicklung steht.
Ein branchenübergreifender Wissensaustausch im Rahmen von Manufacturing-X sowie Standardisierungsarbeiten innerhalb der Industrial Digital Twin Association (IDTA) und ECLASS sollen ebenso wie die Bereitstellung eigener Entwicklungen und der Dokumentation zu einer flächendeckenden Adoption in der Fluidtechnik sorgen und Ihren Anteil zur Wettbewerbsfähigkeit beitragen.
Die genutzten und entwickelten Technologien, wie die Asset Administration Shell (AAS), Data Spaces und der Fluid 4.0 Technologiestack, werden auf dieser Seite erklärt.
Basierend auf den Technologien hat sich für die Umsetzung der in Fluid 4.0 adressierten Use Cases nachfolgende skalierbare Referenzarchitektur als zielführend erwiesen – diese lässt sich im Grunde auf weitere Industriebereiche und Anwendungsfälle übertragen.
Wichtig anzumerken ist, dass die AAS nicht nur ein statischer Datencontainer ist, sondern je nach Use Case Daten dynamisch bereitstellt und Schnittstellen bietet, um bspw. das Ausführen von Methoden anzustoßen.
Durch standardisierte Strukturen und Zugriffskontrollen wird ein hersteller- und systemübergreifender Datenaustausch ermöglicht, der nach erfolgreicher Implementierung einfach, sicher und gewinnbringen ist.
Dabei sollen bestehende Standards, Protokolle und Strukturen nicht vollständig durch die AAS ersetzt werden. Vielmehr bildet der Fluid 4.0 Baukasten durch den überlegten Einsatz der AAS die Basis, um Mehrwerte zu erzeugen – mehr dazu in den Use Cases.
Die Technologie der Asset Administration Shell (AAS, dt. Verwaltungsschale) ist charakterisiert durch Open-Source-Spezifikationen, Software Development Kits (SDK), einfache Interfaces und eine Community, die den interoperablen Datenaustausch vorantreibt. Die Industrial Digital Twin Association e.V. (IDTA) ist das größte Gremium, welches AAS-Spezifikationen entwickelt und innerhalb dessen Wissen geteilt wird.
IEC 63278 definiert den Standard der AAS. Im Kontext der AAS sind folgende Bestandteile definiert:
Ein virtuelles oder physisches Produkt, eine Maschine oder einfach gesagt ein System-Of-Interest. Die Asset ID ist dabei die global eindeutige Identifikationsnummer des Assets.
Die digitale Repräsentation eines Assets, deswegen auch als „Digitaler Zwilling“ bezeichnet. Jede AAS besitzt eine eindeutige AAS-ID und ist über die Asset-ID mit einem Asset verknüpft. Sie referenziert beliebig viele Submodels, welche wiederum spezifische Informationen zu einem Aspekt (z. B. Datenblatt, Betriebsdaten, Befehle) beinhalten.
Man unterscheidet zwischen der AAS für einen Typ (z. B. Baureihe eines Produkts) und der AAS für eine Instanz (z. B. ein konkretes existierendes Produkt).
Dies sind die eigentlichen Daten-Container. Sie beinhalten strukturierte und semantisch annotierte Informationen, die für den jeweiligen Aspekt relevant sind. Dafür nutzen sie SubmodelElements, also kleine komposierbare Datenelemente.
Submodels sind eigenständige Gebilde und besitzen daher eine eindeutige Submodel-ID, über welche sie von einer oder mehreren AAS referenziert werden können.
Submodels existieren statisch – als JSON- oder XML-Datei – oder dynamisch – als manipulierbares Objekt in einer Runtime. Über das AAS Application Programming Interface (kurz: die AAS-API) bietet ein Server oder eine Runtime Zugriff auf das Submodel. So sind Client-Applikationen imstande, mit Submodels zu interagieren.
Ein strukturiertes Datenelement, wie z. B. Property, Range, File oder sogar eine Collection, welche wiederum andere SMEs beinhaltet. So lassen sich komplexe hierarchische Datenstrukturen aufbauen. Jedes SME ist dabei maschinenlesbar semantisch annotiert, damit die Bedeutung der Information eindeutig festgelegt ist.
Ein SMT dient als Vorlage für den Aufbau eines Submodels. Damit wird sichergestellt, dass beispielsweise Informationen zu den Kontaktdaten im zugehörigen Submodel immer gleichartig strukturiert sind. Nutzer wissen so vorab, wo die gesuchte Information zu finden ist. SMTs können bei der IDTA standardisiert werden.
Ein Service, beispielsweise ein PLC-Programm oder eine Anwendung, welcher Teil des Assets ist. Über den Asset-Service kann auf Daten des Assets zugegriffen werden.
Ein Service, beispielsweise ein Datenbankservice, der nicht physischer Teil des Assets ist, aber Daten beinhaltet, die dem Asset zuzuschreiben sind.
Eine gepackte Datei, die u.a. AAS und SM in einer JSON- oder XML-Datei sowie mögliche Dateianhänge beinhaltet. Sie dient ausschließlich dem Austausch statischer Informationen und ist daher für die Betrachtung eines Assets über den gesamten Lebenszyklus hinweg ungeeignet.
Die Informationen einer AAS und ihrer SMs können ausgetauscht werden – statisch als JSON, XML oder AASX (AAS Type 1) – oder durch den Zugriff auf einen Server mittels API (AAS Type 2).
Im Sprachgebrauch wird AAS oft als Sammelbegriff für die Technologien und Spezifikationen verwendet, also u.a. für die AASX-Datei, einen Server mit AAS-API, das Konzept der Asset Administration Shell im Allgemeinen usw.
Um den Datenaustausch und die Nutzung weiter zu automatisieren, ist es erforderlich, dass Informationen gleich interpretiert werden. Die AAS annotiert hierfür jede Information mit ihrer Semantik. Zur Definition der Semantik haben sich Referenzwörterbücher etabliert, z. B. ECLASS oder IEC CDD. Dadurch ist neben einem menschenlesbaren Namen in verschiedenen Sprachen auch die Referenz zu Einheiten und Ontologien möglich.
So ist gewährleistet, dass bei der Bereitstellung und dem Konsumieren von Informationen alle Parteien die Bedeutung kennen und verstehen.
Ein Data Space (dt. Datenraum) ist dadurch charakterisiert, dass es festgelegte Spezifikationen für Services rund um den Datenaustausch gibt. Erst dadurch wird ein unternehmens- und lieferkettenübergreifender, automatisierbarer Datenaustausch ermöglicht.
Dazu gehören u.a. technische Schnittstellen und Protokolle, Authentifizierungsmechanismen (Security) und ein Identitätsmanagement sowie die Möglichkeit, passende Produkte, Dienstleistungen und Unternehmen zu finden. Zur gezielten Suche hat sich die Nutzung einer Abfragesprache (engl. Query Language) etabliert.
Der Data Space Ansatz impliziert nicht, dass Daten zwangsläufig zentralisiert gehalten werden.
In gemeinsamer Zusammenarbeit innerhalb von Manufacturing-X wurden drei verschiedene, gleichwertige Ansätze für eine Data Space Teilhabe entwickelt, die sogenannten MX-Ports. Durch die in Fluid 4.0 betrachteten Use Cases und den starken technischen Aufbau auf der AAS wurde die MX-Port-Konfiguration „LEO“ aktiv umgesetzt.
Um die erzielten Erkenntnisse in feste Bestandteile zu überführen und zugleich eine Kompatibilität zu weiteren Aktivitäten in der Industrie zu gewährleisten, wurde in den sogenannten Manufacturing-X Topic Groups gemeinsam an themenspezifischen Schwerpunkten gearbeitet und Standardisierungsprozesse von Submodeltemplates innerhalb der IDTA angestoßen.
Um die Use Cases umzusetzen ist ein Fluid 4.0 Technologiestack als Baukasten entstanden, der die Referenzarchitektur implementiert.
Innerhalb der Manufacturing-X Aktivitäten wird ein Austausch zwischen Forschungsprojekten aus verschiedenen Branchen gefördert.
Zu bestimmten Schwerpunktthemen sind sogenannte Topic Groups initiiert wurden. Fluid 4.0 leistet zu folgenden Topic Groups einen Beitrag.
Eine Übersicht über alle Manufacturing-X Topic Groups und weitere Informationen finden sich unter:
Innerhalb der Industrial Digital Twin Association e.V. (IDTA) sind über hundert Unternehmen, Verbände und Forschungseinrichtungen aus verschiedenen Industriebereichen organisiert. Ziel ist es den Standard der Asset Administration Shell (AAS) und der dazugehörigen Submodels (SM), zu entwickeln, zu standardisieren und in die Anwendung zu bringen. Durch den strikten open-source Ansatz soll die Verbreitung beschleunigt werden.
Vier IDTA Submodel Working Groups wurden von verschiedenen Fluid 4.0 Projektpartnerinnen und Partnern gegründet, um die wichtigsten Ergebnisse zu standardisieren.
IDTA 02086
IDTA 02094
IDTA 02095
IDTA 02098
Darüber hinaus wurde in weiteren Submodel Working Groups aktiv mitgewirkt, um den Anforderungen der Fluidtechnik gerecht zu werden. Eine Übersicht über alle Submodel Templates, die in Arbeit sind oder veröffentlicht wurden, finden sich hier:
Unser Southbound Connector verbindet Anwendungen und Maschinen nahtlos nach IDTA‑Standards. Mit Eclipse BaSyx, MQTT und OPC UA ermöglicht er zuverlässiges Energiemonitoring, Submodell‑Updates und die Synchronisation digitaler Zwillinge. Er realisiert die Kommunikation zwischen dem Asset(-Service) und der AAS.
Entwickelt in Python auf Basis des BaSyx SDK und kompatibel mit SMT AID und AIMC für maximale Interoperabilität. Hieraus ist ein Teil der Python Bibliothek „AAS Standard Parser“ entstanden und steht zur Nutzung verfügbar:
Ergänzend zu unserer Southbound‑Integration haben wir einen leistungsfähigen Northbound Connector entwickelt, der die Kommunikation zwischen Anwendungen und dem AAS‑Server erheblich vereinfacht. Der Connector ist vollständig in Python implementiert und kapselt die komplexen REST‑Endpoints der AAS‑Serverlandschaft in klar strukturierte, einfach nutzbare Funktionen. Durch die verbesserte Kompatibilität auch zwischen verschiedenen AAS-Komponenten-Ausprägungen können Anwendungen schnell und zuverlässig auf Submodelle, Assets und Datenpunkte zugreifen, ohne sich mit den technischen Details der API beschäftigen zu müssen.
Der Northbound Connector bietet damit eine effiziente, robuste und entwicklerfreundliche Grundlage für die Integration moderner AAS‑basierter Lösungen. Hieraus ist die Python Bibliothek „AAS Http Client“ entstanden und steht zur Nutzung verfügbar.
Zusätzlich zu unseren Connectoren haben wir leistungsstarke Microservices und Bibliotheken entwickelt, die ebenfalls in Python auf Basis unserer Schnittstelle umgesetzt wurden. U.a. wird das automatisierte Auslesen von Maschinendaten, die kontinuierliche Aktualisierung relevanter Submodelle und die Bereitstellung stets aktueller digitaler Zwillinge innerhalb der AAS-Infrastruktur ermöglicht.
Darüber hinaus werden dadurch Maschinenwerte effizient in eine Time-Series-Datenbank überführt und schafft damit die Grundlage für detaillierte Analysen, Monitoring-Lösungen und datengetriebene Optimierungen. Sowohl der Connector als auch der Microservice lassen sich nahtlos integrieren, sind leicht skalierbar und unterstützen den durchgängigen Einsatz moderner, IDTA-konformer AAS-Architekturen.
