STAG – Brückenbau zwischen Produktion und IT-Welt

Moderne Produktionsanlagen verarbeiten enorme Mengen an Prozessdaten, die sich auf Produktionslinien beziehen, und beinhalten unter anderem Daten von Sensoren, Maschinen und Logistiksystemen. Um die Digitalisierung voranzutreiben, müssen die Daten mithilfe verschiedener IT-Systeme aus unterschiedlichen Gründen überwacht, analysiert und visualisiert werden. Viele Datenquellen bieten jedoch keine einfache, gemeinsame Schnittstelle für den Zugriff auf die Daten.

Insbesondere bei der Digitalisierung einer Produktionsanlage stammen die Daten oft von Maschinen und Sensorsystemen, die unterschiedliche Kommunikationsprotokolle verwenden [1]. Daher ist die Integration von Betriebsdatenquellen in größere IT-Lösungen, einschließlich ERP– oder MES-Lösungen, nicht selten schwierig und langwierig. Oft müssen die Datenquellen manuell mit jeder einzelnen IT-Lösung integriert, kontrolliert und gepflegt werden.

Mit dem Ziel, die Digitalisierung zu erleichtern und die Lücke zwischen Shopfloor- und IT-Systemen zu schließen, konzentriert sich unsere Arbeit auf die folgenden Forschungsfragen:

• Wie lassen sich unterschiedliche Protokolle und Datenmodelle in der Produktion automatisiert abbilden und übersetzen?
• Wie kann die Übersetzung von Protokollen verallgemeinert werden, um sie auf mehrere Standards zu erweitern?
• Wie lässt sich dieses Übersetzung in einer modularen und anpassungsfähigen Systemarchitektur umsetzen?

Die modulare und erweiterbare STAG-Softwarelösung adressiert die oben skizzierten Herausforderungen. Sie überbrückt die Lücke zwischen den Kommunikationsprotokollen in der Fertigung (z. B. Modbus [2], IO-Link [3]) und den Datenmodellen der meist IP-basierten Protokolle, die in der IT-Welt verwendet werden, einschließlich Open Platform Communications Unified Architecture (OPC UA) [4] oder MQTT [5]. Der Kern von STAG ist eine modulare Architektur, die auf einem internen Informationsmodell basiert, das als intermediäres Abbildungsmodell zwischen verschiedenen Technologien dient.

Gegenwärtiger Stand

Es gibt viele Ansätze, die sich mit der Datenmodellierung und der Interoperabilität von IT-Systemen in den Betrieben befassen. Die Industrial Digital Twin Association (IDTA) zum Beispiel konzentriert sich auf die Definition und Entwicklung von Standards für Digitale Zwillinge. Mit der Asset Administration Shell (AAS) [6] hat die IDTA eine einheitliche digitale Zugriffsschicht für verschiedene Anlageninformationen definiert. IDTA 02008-1-1 [7] definiert ein eigenes Submodell für Zeitreihendaten.

Basierend auf dem Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0) [8] empfehlen Drath u. a. [9] OPC UA als die geeignete Technologie für die Implementierung von laufzeitrelevanten Informationen einschließlich AAS-Sensorwerten. OPC UA bietet Interoperabilität mit der IT-Welt und ist mit seinem integrierten Datenmodell in der Lage, ein breites Spektrum an Informationen zu modellieren und abzubilden. Allerdings ist OPC UA auch ein komplexer Kommunikations-Stack.

Um die Integration von speziellen Technologien zu standardisieren, hat die OPC Foundation eine Reihe von Mapping Companion Standards definiert. Zum Beispiel ist das IO-Link Mapping [10] ein Companion Standard, der die OPC UA Namespace Definitionen für die IO-Link Device Deskriptoren spezifiziert. Die OPC UA Standards unterstützen jedoch nur das Mapping und Modeling und erlauben keine vollständige Implementierung.

Um einen digitalen Sensorzwilling erfolgreich einzurichten und zu betreiben, reicht es nicht aus, die entsprechenden Schnittstellen zu entwerfen. Man muss auch die technologische Lücke zwischen den Kommunikationsprotokollen und den Bussen sowohl auf Shopfloor- als auch auf IT-Ebene schließen. Ifm ist als Pionier im Bereich von IO-Link sowie als führender Sensoranbieter [11] bekannt. Neben Sensoren bietet Ifm auch eigene IO-Link-Gateways [12] an, die IO-Link-Daten in PROFIBUS-, EtherCAT- oder IP-basierte Kommunikation via MQTT übersetzen. Eine direkte Übersetzung in OPC UA ist bisher nicht verfügbar. Die Baumer Group, ein weiterer großer Anbieter von Sensoren, vertreibt ähnliche Gateways und bietet teilweise Unterstützung für OPC UA [13]. Allerdings unterstützen die Gateways meist nur eine Sensortechnologie, in diesem Fall IO Link.

Es gibt auch eine Reihe von Unternehmen, die sich ausschließlich auf die Entwicklung und den Vertrieb von Gateways konzentrieren und keine eigenen Sensoren entwickeln. Ein Beispiel hierfür ist die Wachendorff Prozesstechnik GmbH & Co KG, die eine breite Palette verschiedener Protokollkonverter vertreibt [14]. Im Gegensatz zur STAG ist jedoch für jede Kombination von Technologien ein eigenes Gateway erforderlich. Mit verschiedenen 1-zu-1-Protokolladaptern verfügt HMS über ein ähnliches Produktportfolio [15]. Das bedeutet aber auch, dass unterschiedliche Geräte für unterschiedliche Protokolle benötigt werden.

Darüber hinaus verkaufen einige OPC UA SDK-Anbieter wie Softing oder Matrikon ihre eigenen OPC UA Gateways, die die Integration bestehender Systeme in die OPC UA Welt vereinfachen sollen. Diese Technologien haben gemeinsam, dass sie den Datenaustausch zwischen dem Shopfloor und der IT-Welt unterstützen. Die Kehrseite der Medaille ist, dass beide auf ein einziges Kommunikationsprotokoll beschränkt sind.

Ein weiterer Ansatz für die Dateninteroperabilität und -integration wird von Unternehmen vorgeschlagen, die als Dienstleister für digitale Integrationslösungen fungieren. Einige Unternehmen schaffen etwa ihren eigenen digitalen Marktplatz für Docker-basierte Anwendungen. Andere Systeme ermöglichen es Maschinenherstellern, verschiedene Maschinendaten und Kontrollpunkte einfach in die IT-Landschaft einzubinden.

Obwohl verschiedene kommerzielle Lösungen existieren, die die Integration einzelner Technologien und Sensoren in IT-Systeme unterstützen, ist weiterhin Forschung zur Verallgemeinerung und Prozessvereinfachung notwendig, um der Plug-and-Produce (PnP) Vision näherzukommen [16]. OpenPNP [17], zum Beispiel, integriert verschiedene OPC UA Datenquellen zur Laufzeit. Im Gegensatz dazu konzentrieren sich Endeley u. a. [18] auf den Zugriff auf Legacy-Sensoren, die keine IP-basierte Schnittstelle haben.

Die Autoren konnten ihren Ansatz validieren, indem sie die serielle Kommunikation mit einer SPS und anderen I2C-basierten Sensoren im OPC UA-Datenmodell abbildeten. Es fehlt jedoch eine allgemeine Unterstützung verschiedener Sensoren und Technologien, die in der Fertigung eingesetzt werden. In [19] stellen Pena u. a. ein konfigurierbares Modbus – OPC UA Gateway vor, das Modbus-Variablen auf der Grundlage von Benutzerspezifikationen auf OPC UA Variablen abbildet. Der Ansatz ist jedoch nur auf Modbus beschränkt.

Systemarchitektur

Die STAG-Systemarchitektur ist auf Modularität und Erweiterbarkeit ausgelegt. Die Architektur kann in drei Hauptteile unterteilt werden: STAG Core, Technology Adapters und Data Consumers. Alle Komponenten werden, wie in Bild 1 dargestellt, vom System Runner verwaltet. Unser Ansatz basiert auf der klaren Trennung der 3 Bereiche: 1) Zugriff auf Datenpunkte in der Fertigung, 2) Bereitstellung von Schnittstellen und Daten für die IT und 3) Abbildung von Funktionalitäten zwischen diesen Bereichen. Auf diese Weise ermöglicht die STAG-Architektur die gleichzeitige Nutzung verschiedener OT- und IT-Technologien, ohne dass bestehende Systemkonfigurationen geändert werden müssen.

Der STAG Core enthält das Informationsmodell und bieten Schnittstellen für die Implementierungen von Technology-Adaptern und Data-Consumer-Adaptern. Diese Module stellen sicher, dass die modellierten Elemente, die von den Technology-Adaptern erstellt werden, korrekt aufgebaut sind und dass keine doppelten Entitäten innerhalb des Modells existieren. Dies geschieht durch die Technology Adapter-Schnittstelle und den Technology Manager, der die modellierten Entitäten im Model Manager registriert. Diese Entitäten werden dann im Information Repository gespeichert. Sobald eine Änderung im Information Repository erfolgt, sendet der Model-Manager über einen internen Ereignismechanismus Benachrichtigungen an alle Datenverbraucher, dass entweder eine neue Entität hinzugefügt oder eine bestehende entfernt wurde. Das Data Consumer Adapter Interface greift auf die modellierten Entitäten in einheitlicher Weise zu, ohne die darauf bezogenen Technology-Adapter zu kennen.

Technology Adapter sind wichtig für die Erstellung von Entitäten innerhalb des Informationsmodells und bei der Abwicklung aller technologie-spezifischen Aufgaben, die für den Datenzugriff benötigt werden. Jeder Adapter muss das TechnologyAdapter Interface implementieren, welches einen standardisierten Weg zur Erstellung von Geräteabstraktionen innerhalb des Information Model über das Builder-Muster [20 ] bietet. Es bietet auch einen Mechanismus zum Hinzufügen und Entfernen von Geräteabstraktionen aus dem internen Information Repository.

Data Consumer stellen die Verbindung zu IT-Lösungen her, indem sie Server-Endpunkte bereitstellen und die aus den Abstraktionen des Information Model stammenden Daten zugänglich machen. Sie sind für die Durchführung der entsprechenden Datenzuordnungen verantwortlich und ermöglichen den Benutzern die Interaktion mit den modellierten Entitäten. Jeder Verbraucher muss dase Data Consumer Adapter Interfaceimplementieren, welches den oben erwähnten Ereignismechanismus enthält, um die Implementierungen zu benachrichtigen, sobald eine neue Geräteabstraktion erstellt oder eine bestehende durch einen der Technologieadapter entfernt wurde.

Alle Module werden durch den System Runner orchestriert. Er startet und stoppt die registrierten Technology Adapter- und Data Consumer -Plugins über ihre jeweiligen Schnittstellen, verbindet sie mit dem Kern und konfiguriert ihre gemeinsamen Protokollierungsfunktionen. Alle Ausnahmen, die von den Plugins ausgelöst werden, werden ausgewertet und entsprechend behandelt, um ein reibungsloses Funktionieren des gesamten Systems zu gewährleisten. Jedes Plugin, das auf einen nicht behebbaren Fehler stößt, wird vom System Runner angehalten und aus dem System entfernt. Auf diese Weise wird sichergestellt, dass das Information Repository konsistent bleibt, während nicht verfügbare Geräte automatisch aus dem System entfernt werden. Der System Runner versucht dann, das Plugin neu zu starten und die vorherigen Verbindungen wiederherzustellen.

STAG-Informationsmodell

Die Grundlage des STAG-Projekts ist die interne Datenabstraktion, das sogenannte Information Model. Es definiert die grundlegenden Elemente, die die logische Struktur einer Entität, die Arten von Eingabe-/Ausgabedatenpunkten sowie deren Werte beschreiben. Mit Entität meinen wir Sensoren oder Maschinen. In Bild 2 werden die grundlegenden Elemente des STAG-Information Model in Form eines UML-Klassendiagramms dargestellt. Wir haben das Modell nach dem Prinzip „Komposition über Vererbung“ [21 ] entworfen, welches es uns ermöglicht, die Struktur der modellierten Entitäten von ihren Eigenschaften zu entkoppeln. 

Jede modellierte Entität (z. B. ein Sensor oder eine Maschine) wird als Device-Klasse dargestellt. Sie fungiert als Container für alle anderen Klassen, wobei der Modus die relevanten Attribute und Funktionalitäten in Form von DeviceElement-Entitäten enthält. Sowohl die Device- als auch die DeviceElement-Klasse übernehmen bestimmte Attribute der NamedElement-Klasse, die allgemeine Informationen wie Name, eindeutiger Bezeichner und Beschreibung des genannten Elements enthält. Die drei Klassen (Device, DeviceElement und NamedElement) sind die einzigen Klassen, die das Vererbungsprinzip nutzen, um Code wiederzuverwenden.

Alle anderen Klassen wurden, wie oben erwähnt, nach dem Paradigma „Komposition über Vererbung“ modelliert. DieKlasse DeviceElement ist ein Container, der eine der folgenden Klassen enthalten kann: eine DeviceElementGroup, eine Metric, eine WritableMetric, eine ObservableMetric oder eine Function. Jede dieser Klassen modelliert eine bestimmte Funktionalität.

Die Klasse DeviceElementGroup dient der logischen Gruppierung anderer DeviceElement-Instanzen. Sie enthält immer mindestens eine DeviceElement-Instanz. Da DeviceElementGroup nur DeviceElement-Instanzen enthält, die ihrerseits eine DeviceElementGroup referenzieren, können wir verschachtelte Gruppen von Elementen innerhalb einer Gruppe erstellen. Dieser Modellierungsansatz ermöglicht es den Benutzern, Elemente auf eine granularere Weise zu gruppieren.

Die Metric-Klasse dient der Modellierung eines einzelnen, lesbaren Entity-Attributs eines bestimmten Typs (z. B. ein Temperaturwert, der als Fließkomma dargestellt wird) und wird durch zwei zusätzliche Klassen erweitert: WritableMetric und ObservableMetric. Die Basisfunktionalität von Metric ist für beide Klassen durch Komposition verfügbar. So können WritableMetric und ObservableMetric weiterhin zum Lesen von Entitätsattributen verwendet werden. Die Klasse WritableMetric ermöglicht es dem Benutzer, ein einzelnes lesbares Entitätsattribut mit neuen Werten zu versehen (z. B. eine vom Benutzer definierte Bezeichnung, die als menschenlesbare Zeichenkette dargestellt wird). Die ObservableMetric-Klasse ist als Datenquelle für das Observer-Muster [20 ] konzipiert und informiert alle registrierten Objekte, wenn das Attribut einen neuen Wert erhält.

Die Klasse Function wird zur Modellierung von Entitätsattributen verwendet, die Eingabewerte verwenden können, um eine Aktion durchzuführen und optional ein Ergebnis zurückzugeben, sobald die Operation abgeschlossen ist. Die Function-Klasse kann ähnlich wie WritableMetric verwendet werden, da sie es dem Benutzer ermöglicht, die Attribute der modellierten Entität zu ändern. Allerdings erlauben WritableMetric-Instanzen nur die Änderung eines einzelnen Wertes durch einen anderen einzelnen Wert desselben Datentyps, wohingegen Function-Instanzen mehrere Werte als Eingaben verwenden können, um jede gewünschte Operation auszuführen.

Die Klassen Device, DeviceElement und DeviceElementGroup werden verwendet, um die Struktur darzustellen, die sich während der gesamten Lebensdauer der modellierten Einheit nicht ändert. Daher modellieren die drei Klassen statische Informationen. Im Gegensatz dazu werden Klassen Metric, WritableMetric, ObservableMetric und Function verwendet, um Attribute und Funktionalitäten mit dynamischen Informationen darzustellen. Die durch die Metriken repräsentierten Werte ändern sich regelmäßig während der Lebensdauer einer Entität oder können während der Laufzeit geändert werden. Um die statischen Informationen bestehender Entitäten zu ändern, muss eine neue Entität mit der gleichen ID erstellt und als aktualisierter Wert registriert werden. Der Model Manager entfernt dann die alte Entität aus dem Modell und registriert die neue Entität über den Ereignismechanismus.

Implementierung und Anwendungsfälle

Das STAG-System befindet sich seit 2018 in der Entwicklung. Basis war die Entwicklung eines Industrie 4.0-Evaluierungskits unter Verwendung des Lightweight Machine to Machine (LwM2M) Protokolls und der OPC UA Technologien für unterbrechungsfreie Retrofitsensorik im Projekt NIKI 4.0. In den Folgeprojekten AMELI 4.0 und ParsiFAL 4.0 haben wir die Implementierungen der LwM2M- und OPC UA-Technologien für spezifische Anwendungsfälle weiter verfeinert und Anforderungen an das System als Ganzes gesammelt. Schließlich legten wir die grundlegende Arbeitsarchitektur für das STAG-System fest und überarbeiteten die bestehende LwM2M- und OPC UA-Implementierungen, um sie an den modularen Ansatz anzupassen.

Die erste Anwendung und Evaluierung des STAG-Systems startete im Rahmen eines Projekts, das Fahrzeugprüfstände als Digitale Zwillinge in eine cloudbasierte virtuelle Testplattform  integriert. Mit STAG haben wir nicht nur die Kommunikationsschnittstellen und das Datenmapping in OPC UA realisiert, sondern auch die Erweiterbarkeit des Systems demonstriert. Für den Fahrzeugprüfstand haben wir einen speziellen Technologieadapter implementiert, der das Simple Object Access Protocol (SOAP) [22] für die Kommunikation nutzt.

Aufgrund des STAG Ansatzes war lediglich ein Adapter für die SOAP-Technologie erforderlich, da das Mapping für die bestehende OPC-UA-Schnittstelle keine Änderungen benötigte. Als zweites Anwendungsbeispiel haben wir einen universellen Modbus-Technologieadapter implementiert, der zur Abfrage von Sensorinformationen eines Wasserstoffgenerators verwendet wird. Beide Technologieadapter können parallel betrieben werden. Die Daten, die die beide Adapter bereitstellen, werden über die zentrale OPC-UA-Schnittstelle der STAG an einen cloudbasierten virtuellen Prüfstand übertragen.

Um die Funktionen von STAG hervorzuheben und zu demonstrieren, haben wir einen Demonstrator entwickelt, in den verschiedene Industriesensoren integriert sind. Wie in Bild 3 dargestellt, verwenden wir einen TCC501 Temperaturtransmitter, einen IO-Link-basierten Sensor von ifm, einen BA EE660 Sensor für niedrige Luftgeschwindigkeit von E+E Elektronik und einen S-Light-01 Umgebungslichtsensor von Seed Studio. Sowohl der Luftgeschwindigkeits- als auch der Umgebungslichtsensor wurde für die Modbus-Kommunikation über die RS-485-Schnittstelle konfiguriert. Diese Sensoren sind im Falle von IO-Link über Ethernet und den ifm AL1304 IO-Link Master und im Falle von Modbus über ein Twisted-Pair-Kabel mit unserem STAG verbunden. Zur Visualisierung der Sensorinformationen verwenden wir den UA Expert OPC UA Client von Unified Automation.

Der Demonstrator zeigt einen IO-Link Technology Adapter, der parallel zum Modbus Technology Adapter arbeitet, um Daten integriert über die OPC UA Schnittstelle zu liefern. Der IO-Link Technology Adapter verwendet die IODD (IO-Link Device Descriptor) Dateien, um Information Model Device Instanzen zu erstellen und die IoT Core Schnittstelle [23] von ifm, um die Prozessdaten zu erhalten und sie als Metric und Function Instanzen, dazustellen. Der Modbus Technology Adapter verwendet unsere benutzerdefinierten, auf JSON (JavaScript Object Notation) [24] basierenden Deskriptoren zur Definition der Register und ihrer Decoder, um Geräteinstanzen zu erstellen. Die gesamte technologische Komplexität jedes Adapters ist gekapselt, um leicht verständliche OPC UA Nodes zu erzeugen (Bild 4).

Die verschiedenen Anwendungsfälle zeigen die signifikante Aufwandsreduzierung bei der Integration neuer Sensoren, die mit STAG im Vergleich zu einem manuellen und individuellen Implementierungsansatz erreicht werden kann. Im Falle von Modbus und SOAP müssen lediglich sensorspezifische Konfigurationsdateien mit wenigen Codezeilen angegeben werden. Diese Konfigurationsdateien bilden Adressen, IDs und URLs auf Datenvariablen des STAG-internen Datenmodells ab.

Im Gegensatz dazu erfordert eine manuelle Implementierung die Implementierung von technologie- und sensorspezifischem Code vom Kommunikationsadapter über Datenparser bis hin zur Implementierung eines OPC UA Servers oder einer MQTT Datenquelle. Selbst bei Verwendung von Bibliotheken wird die Implementierung mehrere hundert Zeilen Code erfordern. Im Falle von IO-Link ist der Implementierungsaufwand noch geringer.

Die IODDs sollten für STAG zugänglich sein und die Kommunikation mit dem IO-Master muss konfiguriert werden. Neu angeschlossene Sensoren werden automatisch erkannt und sind direkt über die OPC-UA-Schnittstelle erreichbar.

Daten aus dem Betrieb besser zugänglich machen

Mit STAG haben wir eine erweiterbare und modulare Gateway-Technologie entwickelt und implementiert, die die Lücke zwischen den Sensoren in der Fertigung und dem IT-System mit Softwarelösungen schließt, die die Daten analysieren und verarbeiten. Dedizierte Technologieadapter bieten mehrere Kommunikationstechnologien auf dem Shopfloor an und bilden die Daten auf das internen STAG-Informationsmodell ab.

Anschließend können verschiedene Data Consumer eingesetzt werden, um Daten in IT-Protokollen wie OPC UA und MQTT abzubilden. Auf diese Weise macht STAG Daten aus dem Fertigungsbereich für IT-Systeme verfügbar. Wir haben STAG im Rahmen verschiedener Forschungsprojekte entwickelt und in mehreren Anwendungsfällen demonstriert, wobei die deutliche Reduzierung des Implementierungsaufwands gezeigt werden konnte.

Das könnte Sie auch interessieren

Lernfabriken für die Zukunft der Fertigung in Brasilien Förderung der Industrie durch Technologie und Kompetenzentwicklung

Fertigungsunternehmen in Entwicklungsländern stehen vor der Herausforderung, Produktivitätslücken zu schließen und gleichzeitig Industrie-4.0-Technologien einzuführen. Lernfabriken sind ein hilfreicher Ansatz, um diesen Herausforderungen zu begegnen. Ein Beispiel hierfür ist die Lernfabrik „Fábrica do Futuro“ in São Paulo, Brasilien, die Studierende einbindet, die Kompetenzentwicklung fördert und mit der Industrie in der angewandten Forschung zusammenarbeitet.

Serious Gaming und die Energiewende Kollaborativ Wissen erzeugen und interaktiv komplexe Zusammenhänge begreifen Janine Gondolf , Gert Mehlmann, Jörn Hartung, Bernd Schweinshaut, Anne Bauer

Die Vermittlung der Komplexität und Vielschichtigkeit der Energiewende an ein breites Publikum ist eine Herausforderung. Dieser Beitrag zeigt auf, wie interaktive Serious Games auf einem Multitouch-Tisch dazu beitragen können, Zusammenhänge erfahrbar und begreifbar zu machen. Spiele und Tisch wurden in verschiedenen Gesprächskontexten eingesetzt. Diese werden hier in drei Fallvignetten dargestellt, die auf teilnehmender Beobachtung der unterschiedlichen Einsätze, situierter und gemeinsamer Reflexion basieren. Die Vignetten zeigen, wie Interaktion epistemische Prozesse anstoßen, Perspektivwechsel ermöglichen und kollektives Denken fördern kann, das für gesamtgesellschaftliche Zukunftsgestaltung notwendig ist.

Industry 4.0 Science | 42. Jahrgang | 2026 | Ausgabe 2 | Seite 62-69 | DOI 10.30844/I4SD.26.2.62

Digitale Zwillinge in Produktion und Logistik erleben Die fischertechnik® Lernfabrik 4.0 als Entwicklungsplattform für mögliche Ausbaustufen Deike Gliem , Sigrid Wenzel , Jan Schickram, Tareq Albeesh

Die fischertechnik® Lernfabrik 4.0 hat sich als geeignete Experimentierumgebung zur Erprobung Digitaler Zwillinge erwiesen. Abhängig vom angestrebten Reifegrad reichen die Funktionen eines Digitalen Zwillings von der reinen Zustandsüberwachung über Prognosen bis hin zur operativen Steuerung von Produktions- und Logistiksystemen. Zur systematischen Einordnung dieser Funktionen wird in diesem Beitrag ein Reifegradmodell vorgestellt, das als Orientierungsrahmen für den Aufbau eines Digitalen Zwillings dient. Darauf aufbauend werden ausgewählte Anwendungsfälle in einer Test- und Entwicklungsumgebung umgesetzt, die auf einer Systemarchitektur mit mehrstufiger Schichtlogik basiert. Anhand erster Umsetzungen werden Einsatzzwecke, relevante Methoden sowie typische Herausforderungen und Potenziale für den Transfer in reale Fabrikumgebungen aufgezeigt.

Industry 4.0 Science | 42. Jahrgang | 2026 | Ausgabe 2 | Seite 30-37 | DOI 10.30844/I4SD.26.2.30

Angewandte KI für die menschenzentrierte Montage Ein ethisch fundierter Ansatz zur Gestaltung von Arbeitsplätzen Tadele Belay Tuli , Michael Jonek , Sascha Niethammer, Henning Vogler, Martin Manns

Künstliche Intelligenz (KI) kann die Montage verbessern, indem sie menschliche Bewegungen vorhersagt und den Arbeitsplatz entsprechend gestaltet. Mithilfe probabilistischer Modelle wie der Gaußschen Mischmodelle (GMMs) antizipieren KI-Systeme die Bewegungen des Bedieners, um die Koordination mit Robotern zu verbessern. Diese Vorhersagesysteme werfen jedoch ethische Bedenken hinsichtlich Sicherheit, Fairness und Datenschutz gemäß EU AI Act auf. Dieser Artikel stellt eine Methode vor, die probabilistische Bewegungsmodellierung mit ethischer Bewertung mittels Z-Inspection® integriert. Eine Fallstudie unter Verwendung des Werkerassistenzsystem zeigt, wie multimodale Sensorik (Bewegung, Blick) und interpretierbare Modelle eine vorausschauende Unterstützung ermöglichen. Der Ansatz geht von der ethischen Bewertung zu einer ethisch informierten Arbeitsgestaltung über und liefert übertragbare Prinzipien sowie eine konfigurierbare Bewertungsmatrix.

Industry 4.0 Science | 42. Jahrgang | 2026 | Ausgabe 1 | Seite 60-68 | DOI 10.30844/I4SD.26.1.60

Produktionssteuerung im All Ein KI-gestützter Ansatz für die Industrie im Orbit Dominik Augenstein, Lara Jovic

Eine Produktion im Weltraum, beispielsweise von Halbleitern, bietet viele Vorteile für Unternehmen. Gleichzeitig sorgen hohe Transportkosten dafür, dass genau abgewogen werden muss, welche Produktionsmaterialien man ins Weltall transportiert. Die Anwendung sogenannter Kalman-Filter ermöglicht dabei eine (Echt-Zeit) Steuerung von der Erde aus und damit eine kosteneffiziente Art der Weltraumproduktion. Mittels Machine Learning kann dieser Ansatz auch bei sehr komplexen Produktionssystemen Anwendung finden.

Industry 4.0 Science | 41. Jahrgang | 2025 | Ausgabe 6 | Seite 22-29

Quiz: Produktion im Weltraum Testen Sie jetzt Ihr Wissen!

Schwerelos produzieren – nur Science-Fiction oder bereits Realität? Dank neuer Raumfahrttechnologien entstehen heute erste Produktionsprozesse im All, die Materialien und Strukturen ermöglichen, die auf der Erde kaum herstellbar sind. Von ultrapuren Fasern bis zum 3D-Druck von Organen: Die Schwerelosigkeit eröffnet Industrien völlig neue Perspektiven – und bringt die Raumfertigung näher an die Gegenwart, als viele denken.