Effizienteres Engineering von Anlagen
Das Potenzial des digitalen Zwillings
Wie lässt sich das Digital-Twin-Konzept nutzen, um das integrierte Produktionsanlagen-Engineering voranzutreiben und dessen Effizienz zu erhöhen? Zur Beantwortung der Frage wird die Entwicklung des digitalen Anlagenzwillings über den Anlagenlebenszyklus und speziell des SPS-Engineerings beschrieben.
Der digitale Zwilling ist seit Jahren eines der Trendthemen in der Automatisierungstechnik (Bild 1). Gemäß der Definition des Begriffs »digitaler Zwilling« aus der Publikation »Die Rolle der Industrie-4.0-›Verwaltungsschale‹ und des ›digitalen Zwillings‹ im Lebenszyklus einer Anlage: Navigationshilfe, Begriffsbestimmung und Abgrenzung« [1] handelt es sich um die Verwaltungsschale eines Assets (Asset Administration Shell, AAS).
Ein Asset kann dabei eine Einzelkomponente, ein Feldgerät, eine ganze Anlage, eine Software oder alles andere sein, was für die Organisation einen Wert hat. Zu den Use Cases der AAS, die derzeit am meisten diskutiert werden, gehören:
➔ das digitale Typenschild (Digital Nameplate)
➔ die papierlose Dokumentation, indem entsprechende digitale Unterlagen in der AAS abgelegt werden
➔ die Bereitstellung technischer Produktmerkmale in der AAS
➔ die Verfügbarmachung des CO2-Fußabdrucks in der AAS
➔ Darüber hinaus haben digitale Zwillinge das Potenzial, das durchgängige, integrierte Anlagen-Engineering in der industriellen Fertigung voranzubringen und so die Effizienz des Engineerings von Produktionsanlagen allgemein zu steigern. In diesem Zusammenhang sind die folgenden Use Cases zu nennen:
➔ Management von (Automatisierungs-)Softwaremodulen auf Basis von AAS
➔ Beziehen und Wiederverwendung von Engineering-Daten, die sich in der Anlagen-AAS befinden
➔ Nutzung von Engineering-relevanten Daten aus den AAS der Komponenten
➔ Speicherung der beim SPS-Engineering erzeugten Engineering-Daten in der AAS, sodass sie sich in anderen Engineering-Werkzeugen erneut einsetzen lassen.
Informationen liegen in Teilmodellen vor
Die AAS-Technologie wird von der IDTA (Industrial Digital Twin Association) als unternehmensübergreifendes Technologiekonsortium betreut und vorangetrieben. Das allgemeine AAS-Metamodell ist mittlerweile in die IEC-Norm 63278-1:2023 [2] überführt worden. Unterschieden wird in Anlehnung an eine Klassen-Objekt-Beziehung zwischen Typ- und Instanz-AAS. Eine Typ-AAS repräsentiert den Typ eines Assets. Die Instanz-AAS steht für ein konkret existierendes Asset. Sie wird bei der Herstellung des Assets generiert und unter Um- ständen von einer Typ-AAS abgeleitet. Die eigentlich in den AAS enthaltenen Informationen liegen in den Teilmodellen (Submodels) vor. Stand Juni 2024 listet die IDTA bislang 85 vordefinierte, also veröffentlichte und in Ausarbeitung befindliche Teilmodelle auf. Diese decken beispielsweise die oben genannten Basis-Use-Cases ab. Auf der Grundlage des vordefinierten Submodels »Hierarchical Structures« werden die hierarchischen Strukturen der AAS außerdem als Liste von Referenzen auf unterlagerte AAS umgesetzt. Das Hosten der AAS erfolgt in AAS-Repositorys auf AAS-Servern. Der Zugriff auf die AAS eines AAS- Servers geschieht über dessen REST-API.
Sicherheitsmechanismen wie etwa ein feingranulares Rechtemanagement sind bereits in die AAS-Technologie integriert. Einzelgeräte und Komponenten verfügen produktionsseitig über einen QR-Code [3], der auf die AAS verlinkt.
Anlagen-AAS-Struktur an einem Beispiel
Bild 2 visualisiert auf der linken Bildhälfte eine beispielhafte Anlagenstruktur, die aus einem SCADA-/HMI-System, dem SPS-Engineering, einer Steuerung sowie nicht näher festgelegten unterlagerten Feldgeräten besteht. Die Anlagenstruktur ist mit AAS-Repositorys verbunden. Bild 2 stellt auf der rechten Bildhälfte dar, wie eine Anlagen-AAS-Struktur zur exemplarischen Anlage unter Nutzung der oben beschriebenen Teilmodelle und Standards aufgebaut werden könnte. Die Anlagen-AAS sowie alle AAS von Hardwarekomponenten umfassen die vier Teilmodelle Nameplate, Handover Documentation, Technical Data und PCF (Product Carbon Footprint), um die eingangs aufgeführten vier Basis-Use-Cases zu erfüllen.
Die Engineering-Daten der Anlage – etwa Schalt- und Rohrpläne, Konstruktions-zeichnungen oder Konfigurationsdateien – befinden sich in der Anlagen-AAS; hier beispielsweise im Teilmodell »ElectricAndFluidPlan«. Sämtliche unterlagerten Komponenten der Anlage sind im Teilmodell »Hierarchical Structures« referenziert. Die AAS der Steuerung umfasst das Teilmodell »AssetInterfaceDescription«, in dem die Konfigurationen aller Kommunikationsschnittstellen definiert werden. Ferner verfügt die Steuerungs-AAS über zwei »Hierarchical- Structures«-Teilmodelle. Das eine Modell dient der Referenzierung der AAS der unterlagerten Hardware, etwa der gesteckten I/O-Module. Das andere Teilmodell wird zur Referenzierung der AAS der genutzten Software eingesetzt, etwa des SPS-Engineering-Projekts oder der Controller-Firmware. Die AAS von Software umfassen das Teilmodell »Software Nameplate« sowie optional das Teilmodell »Hierarchical Structures«, in dem Softwareabhängigkeiten – wie etwa die verwendeten Bibliotheken – referenziert werden.
Engineering-Daten werden über den gesamten Anlagenlebenszyklus hinzugefügt
Bild 3 veranschaulicht, wie eine Anlagen-AAS mit unterlagerter Komponenten-AAS-Hierarchie über den Lebenszyklus der Anlage entsteht und mit der realen Welt interagiert. Am Anfang der Anlagenplanung bildet sich gegebenenfalls eine Typ-AAS der Anlage. Dies hängt davon ab, ob es sich um einen Serienanlagenbau oder eine Individualanlage handelt. In jedem Fall generiert sich bei der Anlagenplanung eine Instanz-AAS. Ab diesem Zeitpunkt werden der Anlagen-AAS über die Planungs- und die nachfolgenden Phasen immer neue Engineering-Daten hinzugefügt, etwa Schalt- oder Rohrpläne. Gleiches gilt über den gesamten Anlagenlebenszyklus für Lebenszyklusdaten wie Prüfprotokolle oder Dokumentationsunterlagen. Während der Konstruktionsphase ist nicht festgelegt, ob eine Instanziierung sämtlicher Komponenten stattfindet, bevor das SPS-Engineering beginnt. In jedem Fall wird die Steuerung vor der Inbetriebnahme instanziiert.
- Das Potenzial des digitalen Zwillings
- Software-Management setzt sich aus fünf Schritten zusammen
Lesen Sie mehr zum Thema
