Effizienteres Engineering von Anlagen
Das Potenzial des digitalen Zwillings
Fortsetzung des Artikels von Teil 1
Software-Management setzt sich aus fünf Schritten zusammen
Bild 4 gewährt einen tieferen Blick in den Use Case Softwaremanagement im Rahmen des SPS-Engineerings. Dabei geht es um den umfangreichsten der eingangs erwähnten vier Use Cases. Kern des Use Cases ist das Speichern, Verwalten, Versionieren und Beziehen von Software in AAS-Strukturen. Dazu liegen hier alle Software-AAS in einem eigenen AAS-Repository. Sämtliche Software-AAS umfassen das Teilmodell »Software Nameplate« [4]. Dieses Teilmodell eignet sich einerseits zur Darstellung aller relevanten Informationen über eine Software. Andererseits lässt sich die Software selbst entweder als Datei oder als Verweis auf eine Bezugsquelle im Teilmodell ablegen.
Im Rahmen des SPS-Engineerings setzt sich das Softwaremanagement aus fünf Schritten zusammen:
➔ Die AAS für das SPS-Engineering-Projekt mit Software-Nameplates wird erstellt und im Software-AAS-Repository gespeichert.
➔ Die AAS des SPS-Engineering-Projekts wird danach in der Anlagen-AAS referenziert.
➔ Werden im Laufe des SPS-Engineerings Softwarebibliotheken benötigt, lassen sich diese direkt aus dem AAS-Software-Repository beziehen.
➔ Anschließend erfolgt die Referenzierung der AAS der genutzten Softwarebibliotheken in der AAS des SPS-Engineering-Projekts.
➔ Am Ende des SPS-Engineerings wird das Software-Release des SPS-Engineering-Projekts im Software-Nameplate der AAS des SPS-Engineering-Projekts archiviert.
Informationen aus vorherigen Projekten lassen sich wiederverwenden
Bild 5 zeigt die drei Engineering- Use-Cases während des SPS-Engineerings. In Use Case a sollen im SPS-Engineering die Engineering-Daten aus vorherigen SPS-Engineering-Projekten verwendet werden, um Teile des SPS-Engineering-Projekts automatisch zu generieren. Informationen aus Schalt- oder Bestückungsplänen könnten beispielsweise genutzt werden, damit sich im SPS-Engineering-Projekt Variablen, Ein-/Ausgangszuweisungen oder Feldbuskonfigurationen automatisch erstellen lassen. In Use Case b geht es darum, Informationen aus den in den Komponenten-AAS enthaltenen Daten im SPS-Engineering wiederzuverwenden. So könnten beispielsweise komplexere Feldgeräte die Informationen, die zu ihrer Integration in die Anlagen-AAS erforderlich sind, in ihrer AAS bereithalten. Oder Feldgeräte, die über ein Kommunikationssystem angeschlossen sind, stellen in ihrer AAS die Konfiguration ihrer Kommunikations-schnittstelle zur Verfügung.
In Use Case c werden die Engineering-Daten aus dem SPS-Engineering wieder in der AAS abgelegt. Davon ist der vorher erläuterte Use Case zum Softwaremanagement abzugrenzen, in dem das eigentliche SPS-Engineering-Projekt in der AAS abgelegt wird. Use Case c thematisiert die Speicherung der Informationen aus dem SPS-Engineering in den entsprechenden Teilmodellen. Die Konfiguration eines OPC-UA-Servers lässt sich beispielsweise im Rahmen des SPS-Engineerings in der AAS archivieren, sodass sie später zur Einstellung überlagerter Systeme (HMI, SCADA, MES) erneut genutzt werden kann.
AAS ergänzt vorhandene Standards wie AutomationML und OPC UA
Der umfangreiche Use Case Softwaremanagement ermöglicht das Speichern, Verwalten, Versionieren und Beziehen von Software. In AAS-Software-Repositorys lassen sich komplexe Beziehungen zwischen Softwaremodulen und in ihnen verwendeten Softwaremodulen versionsgenau darstellen. Der Use Case ließe sich schon heute mit vorhandenen Teilmodellen – etwa »Hierachical Structures« und vor allem »Software Nameplate« – umsetzen. Die drei Engineering-Use-Cases erfordern noch mehr Standardisierung in Form von Teilmodellen zum Abbilden von Engineering-Daten aus dem SPS-Engineering. Als entscheidend für die drei Use Cases erweist sich, die AAS als Integrationstechnologie für das Anlagen-Engineering zu etablieren und im Kontext bereits akzeptierter Integrationstechnologien zu positionieren. Das Diskussionspapier von AutomationML e.V., Industrial Digital Twin Association (IDTA), OPC Foundation und VDMA [5] tut dies, indem es die AAS im Kontext mit AutomationML und OPC UA einordnet - zwei ähnlichen und seit Langem eingesetzten Technologien für die Informationsmodellierung und das integrierte Anlagen-Engineering. Das Diskussionspapier zeigt, dass die AAS diese verbreiteten Standards nicht ersetzt, sondern ergänzt.
Der Autor
Dr. Andreas Würger
ist Technology Manager PLCnext Technology in der Business Area Industry Management and Automation bei Phoenix Contact Electronics in Bad Pyrmont.
- Das Potenzial des digitalen Zwillings
- Software-Management setzt sich aus fünf Schritten zusammen
Lesen Sie mehr zum Thema
