Der virtuelle Zwilling im digitalen Anlagenbau - Notwendige Standards für den Austausch von Simulationsmodellen über Gewerkegrenzen hinweg

Mike Barth, Guido Sand

Simulation wird branchenübergreifend als wichtiges und etabliertes Werkzeug für moderne Engineering-Prozesse betrachtet. Insbesondere die Automatisierung komplexer Produktionsanlagen verwendet Modellierungs- und Simulationstechniken in verschiedenen Projektphasen, um sowohl die Anlage, aber auch das Produkt in bestmöglicher Qualität zu entwickeln. Die jüngsten Trends rund um die Digitalisierung von Produktionsanlagen bestärken die Relevanz von virtuellen Engineering-Szenarien. Dieser Beitrag beschreibt die Notwendigkeit von domänen- und werkzeugübergreifenden Standards für die Modellierung von mechatronischen Anlagen und Maschinen im Rahmen eines digitalen Zwillings.

Die Entwicklungen rund um das Zukunftsprojekt Industrie 4.0 verändern nicht ausschließlich die Produktion, sondern ebenfalls die Engineering-Prozesse zur Konzeption, Entwicklung und Inbetriebnahme der produzierenden Anlagen. In diesem Zusammenhang trägt der Einsatz von Simulationstechniken dazu bei, dass aufkommende Fragestellungen frühzeitiger, zuverlässiger und mit geringerem Risiko beantwortet werden können. Diese über alle Gewerke hinweg gültige Aussage gewinnt auch im Engineering von Automatisierungssystemen für industrielle Anlagen zunehmend an Relevanz. Aus diesem Anlass hat der im Themenfeld CACE (Computer Aided Control Engineering) arbeitende GMA Fachausschuss 6.11 bereits im Jahr 2013 sein Kernarbeitsgebiet auf das simulationsgestützte Engineering von automatisierten Systemen fokussiert. Nach einer ersten Konsolidierung der möglichen Use-Cases, sowohl in der Prozess- als auch der Montage- und Fertigungsindustrie, wurden offene Fragestellungen und damit ein Bedarf zur Definitionsbildung im Bereich der eingesetzten Methoden, der angewendeten Modelle sowie der verwendeten Begriffe identifiziert. Diese Definitionen wurden auf der „Automation 2015“ [1] erstmals zur Diskussion gestellt und in Form der VDI/VDE Richtlinie 3693 (Blatt 1) [2] im August 2016 veröffentlicht. Damit wurde ein erster Schritt in Richtung der Standardisierung von virtuellen Engineering Methoden getan. Die weiterführenden Diskussionen zeigen, in Kombination mit einer in 2015 durchgeführten Umfrage zur Nutzung von Simulation [3], dass die durchgehende Integration virtueller Methoden in Unternehmen nach wie vor ein beachtliches Problem darstellt. So sind weder effiziente Vorgehensmodelle für die Einführung simulationsgestützter Engineering-Prozesse noch Auswahlkriterien für notwendige Hardund Softwarekomponenten bekannt. Eine Zusammenfassung der bislang herausgearbeiteten Aspekte hinsichtlich des Einsatzes von Simulation liefern folgende Erkenntnisse [3]:
Simulationsmodelle von Geräten und/oder Modulen werden zukünftig von den jeweiligen Lieferanten erstellt und als Teil des realen Produkts ausgeliefert.
Simulation wird ein noch bedeutender, integraler Bestandteil des Engineerings von industriellen Anlagen. Dabei werden Modelle durchgängiger – über Gewerkegrenzen und Projektphasen hinweg – angewendet.
Ein abgestimmtes Set verschiedener Simulationsmodelle ist in eine durchgängig wachsende digitale Anlage integriert und ermöglicht damit, ausgerichtet auf den jeweiligen Anwendungsfall, eine passende Modellierungstiefe.
Alle drei genannten Aspekte erfordern jedoch einen Austausch von Simulationsmodellen – sowohl zwischen Unternehmen als auch zwischen unterschiedlichen Gewerken.
 

Herausforderungen für den Austausch von Simulationsmodellen

Die Gründe für den Austausch von Simulationsmodellen sind naheliegend. Als Beispiel ist es zwingend notwendig, dass Anlagenbauunternehmen die zu projektierenden Anlagen virtuell abbilden, um verschiedene technische Fragestellungen, aber auch Testszenarien vor dem tatsächlichen Bau bzw. vor der realen Inbetriebnahme zu klären. Hierfür ist es notwendig, dass die Simulationsmodelle der verwendeten Geräte (z. B. Antriebe) und Subsysteme (z. B. Roboter) vorliegen. Jedoch sind die Anwendungsgebiete von Simulationsmodellen genau wie die hierfür angewendeten Simulationswerkzeuge äußerst heterogen. So werden Modelle im Anlagenbau mithilfe von drei wesentlichen Charakteristika strukturiert:
• Modellierungsart: objektorientierte Aufbau- (z. B. Modelica) und signalflussorientierte Ablaufmodelle (z. B. Matlab & Simulink)
• Modelltyp: E/A-Modell, Gerätemodell und Prozessmodell
• Modellaspekt: Kinematikmodell (mit/ohne 3D CAD) und Dynamikmodell


Bild 1: Beispielhafte Modellsichten auf einen Elektromotor.

Darüber hinaus existieren Spezialwerkzeuge für die ausschnittsweise Detailsimulation von Anlagenelementen, wie beispielsweise die Finite Elemente (FE) Simulation oder die Computational Fluid Dynamics (CFD) Simulation. Am Beispiel des in Bild 1 dargestellten Elektroantriebs kann ein einzelnes System aus unterschiedlichen technischen Sichten modelliert werden, um damit unterschiedliche technische Fragestellungen zu untersuchen. Hersteller von Elektromotoren verwenden dahingehend im Engineering ihrer Produkte unterschiedliche Modelle, Modellierungsarten und Werkzeuge aus den Bereichen Mechanik, Elektro-, Thermo-, CFDoder Regelungstechniksimulation. Möchte oder muss ein solches Unternehmen den digitalen Zwilling für sein Produkt liefern, stellt sich die Frage, welches Simulationsmodell dies betrifft bzw. welche Aspekte in den digitalen Zwilling einfließen sollen. Die Herausforderung besteht darin, möglichst die Modellaspekte zu integrieren, die im späteren Engineering notwendig sind.
Durch die Verwendung von Simulationen werden aktuell gängige Gerätespezifikationen in den Hintergrund rücken. Die Simulationsmodelle der Geräte sind deren Spezifikation und gleichzeitig deren Dokumentation. Jedoch stehen die Hersteller, wie zuvor beschrieben, vor mehreren Fragestellungen:
• Welche Modellierungstiefe muss der jeweilige Geräte-/Modulhersteller wählen? Wie werden Modelle unterschiedlicher Tiefe sinnvoll verknüpft?
• Welche Aspekte müssen abgebildet werden? Möglich sind sowohl das elektrische, mechanische als auch das informationstechnische Verhalten.
• Wie schützt der Lieferant sein Know-how? Werden die Modelle als Black-Box in einem kompilierten Zustand geliefert, sodass lediglich die Schnittstellen nach außen sichtbar sind? Oder werden nicht-kompilierte Modelle geliefert, die jedoch mithilfe von Verschlüsselungstechnologien vor zu tiefen Einblicken geschützt sind? Oder ist beides der Fall?
• Werden die Modelle unabhängig von einem bestimmten Simulationswerkzeug, d. h. herstellerneutral angewendet werden können?
Diese Fragestellungen sind bislang nicht abschließend beantwortet. Es scheint jedoch nicht zielführend, ein mechatronisches Gesamtmodell einer Anlage anzustreben, welches alle denkbaren Aspekte abdeckt. Vielversprechender sind sogenannte Co-Simulationen, welche es erlauben, unterschiedliche Werkzeuge zu koppeln, wobei es möglich ist, dass unterschiedliche Aspekte in den jeweiligen Werkzeugen fokussiert werden. Denkbar ist die Kopplung einer Mechanik-Simulation mit einer Elektro-Simulation. Voraussetzung für die Kopplung von Modellen ist entweder die Vernetzung von Simulationswerkzeugen über definierte Schnittstellen oder die Zusammenführung unterschiedlicher Modelle in einer Simulationsumgebung. Letzteres erfordert standardisierte Modellierungsformate, welche Herstellerübergreifend von mehreren Werkzeugen implementiert werden.
 

Austausch von kompilierten Black-Box-Modellen

Ein erster Schritt in Richtung standardisierter Modellierungsschnittstellen ist der sogenannte Functional Mock-up Interface (FMI) Standard [4]. Dieser wurde aus den zuvor genannten Argumenten für den Modellaustausch und die Co-Simulation zwischen Automotiv-OEMs entwickelt und gewinnt zunehmend an Akzeptanz. In Bild 2 sind die defi nierten Schnittstellen eines kompilierten Black-Box-Modells (Modellaustausch) dargestellt. Die Black-Box beinhaltet sowohl defi nierte Datentypen (Real, Integer, Boolean, String) für die Ein- (u) und Ausgänge (y) als auch Schnittstellen für die Übergabe von Parametern (p).
Die Definition kann dahingehend als Black-Box bezeichnet werden, als dass es sich um kompilierte Dateien (unter Windows in Form einer DLL – Dynamic Link Library) handelt, die einen gewissen Know-How-Schutz in Kombination mit dem Schutz vor ungewollten Änderungen ermöglichen. Der Entwickler des Modells kann selbst entscheiden, welche Variablen extern sichtbar sind und welche nicht. Das Modell selbst wird als Functional Mock-up Unit (FMU) bezeichnet und kann als ZIP-Datei ausgetauscht werden. Der FMI-Standard gewinnt zunehmend an Bedeutung und wird bereits von über 90 Werkzeugen unterstützt. Somit ist eine Integration der Modelle in unterschiedliche Simulationswerkzeuge möglich, ohne auf spezifi sche Hersteller limitiert zu sein. Durch den off enen Standard haben jedoch alle Hersteller von Simulationswerkzeugen die Möglichkeit, eine FMU-Schnittstelle – sowohl für den Import als auch für den Export – zu implementieren.


Bild 2: Darstellung eines Blackbox- Modells (FMU) gemäß der FMI-Spezifikation [4].

 

Polymorphismus der digitalen Anlage

Auch wenn mit dem FMI Standard ein erster wesentlicher technischer Schritt hin zu einem digitalen Anlagenzwilling erfolgt ist, stellt das mechatronische „Welt-Modell“ einer Anlage weiterhin zahlreiche Herausforderungen an Hard- und Software sowie die gewählte Modellierungsart und -tiefe. Eine mögliche Herangehensweise an diese Thematik kann aus der objektorientierten Softwareentwicklung stammen: der Polymorphismus. Hierunter werden Mehrfachausprägungen einer Funktion hinsichtlich ihrer zu verarbeitenden Datentypen verstanden. In einer statischen Version muss bereits beim Kompilieren des Programms entschieden werden, welche Ausprägung der Funktion aufgerufen wird, wogegen in einer dynamischen (auch „spät“ genannten) Version erst zu Laufzeit des Programms entschieden wird, welche Ausprägung instanziiert wird. Für den Aufbau eines digitalen Anlagenzwillings können polymorphe Modelle von Geräteherstellern oder Modullieferanten verwendet werden, die in ihrer jeweiligen Ausprägung unterschiedliche Aspekte wiedergeben. In Bild 3 ist hierzu ein beispielhafter Ausschnitt einer Montageanlage dargestellt. Für das Förderband existieren die Ausprägungen:
• Materialfluss: Modellierung für die Logistiksimulationen
• Steuerung: Modellierung für die Inbetriebnahme der Automatisierungstechnik
• 3D-Geometrie: Modellierung für die Konstruktion der Montageanlage
Die aufgelisteten Ausprägungen können beliebig erweitert werden. Darüber hinaus ist es im Zuge der erläuterten Co-Simulation nicht nur möglich, die unterschiedlichen Anlagenbereichsmodelle (Förderband, Robotik, Bearbeitung, Verpackung etc.) miteinander zu verbinden – durch den Einsatz standardisierter Modellformate wie dem beschriebenen FMI-Standard können mehrere Ausprägungen eines Anlagenteils (z. B. des Fließbands) in ein Modell einfließen.
 

Erste Umsetzungen der digitalen Anlage

Im Labor für Automatisierungstechnik der Hochschule Pforzheim werden die zuvor erläuterten Aspekte der digitalen Anlage bereits prototypisch umgesetzt und validiert. Als Co-Simulationsumgebungen werden derzeit Siemens NX (3D-Physik-Simulation), Dymola (Modelica) und Matlab&Simulink eingesetzt, wobei die beiden letztgenannten Umgebungen den FMI-Standard bereits unterstützen. Die Simulation der Modelle im FMI-Standard (als kompilierte Functional Mock-up Units) wird hierbei mit der QTronic FMI Engine [5] unter Linux erreicht. Die Linux-Umsetzung ermöglicht den Einsatz auf eingebetteten Systemen, wie beispielsweise dem Siemens IoT2000 Device, welches die Vorteile von Mikrocontrollern mit einem industrietauglichen Einsatzfeld verbindet und so direkt in der Anlage eingesetzt werden kann. Das IoT2000 Device ist auf Basis von C++ (Eclipse) frei programmierbar und kann entweder als Simulationsumgebung oder als Orchestrierung für die Auswahl der FMI-Ausprägungen eingesetzt werden. Durch eine für 2017 angekündigte Profinet-Schnittstelle des IoT2000 werden künftig auch Hardware-inthe- Loop Anwendungen verfolgt werden.
 


Bild 3: Beispielhafte polymorphe Ausprägungen eines Förderbandmodells.

Fazit und Ausblick

Erste prototypische Umsetzungen eines digitalen Anlagenzwillings sind technisch möglich, sie sind jedoch nach wie vor mit einem hohen manuellen Aufwand für die Umsetzung verbunden. So müssen nicht nur passende Modellschnittstellen eingehalten werden, sondern auch unterschiedliche Kommunikationsformen zwischen den Modellen im Rahmen einer Co-Simulation (TCP, Shared Memory, OPC UA, Feldbustechnologien) – insbesondere beim Einsatz von Hardware-in-the-Loop-Technologien – eingesetzt werden.
Um eine Effizienzsteigerung zu erreichen, muss eine verbreitete und unter den Simulationswerkzeugentwicklern akzeptierte Form der Datenintegration bestehen. Neben der technischen Umsetzung bedarf es jedoch ebenfalls der Definition der Polymorphie für Geräte und Anlagenmodule. Es muss für Lieferanten eine verbindliche Form der Modellausprägungen geben, die als virtueller Zwilling – parallel mit dem echten Gerät/Modul – ausgeliefert wird. Dies wird erst möglich werden, wenn es einen akzeptierten Datenaustausch-Standard gibt, da erst dann die notwendige Unabhängigkeit von Simulationswerkzeugen herrscht. In seinen künftigen Arbeiten widmet sich der GMA Fachausschuss 6.11 der Definition von Standards für den Simulationsdatenaustausch in Kombination mit der Definition von akzeptierten Modellausprägungen.

Schlüsselwörter:

Simulation, digitaler Zwilling, Modellaustausch,

Literatur:

[1] Barth, M.; Puntel Schmidt, P.; Hoernicke, M.; Oppelt, M.; Wolf, G.; Hundt, L.; Stern, O.: Methoden und Modelle der Virtuellen Inbetriebnahme. In: Tagungsband – Kongress Automation (2015) 11, S. 107- 120.
[2] VDI-Richtlinie 3693 Blatt 1: Virtuelle Inbetriebnahme – Modellarten und Glossar. 2016.
[3] Oppelt, M.; Wolf, G.; Barth, M.; Urbas, L.: Simulation im Lebenszyklus einer Prozessanlage. In: ATP - Automatisierungstechnische Praxis 57 (2015) 10, S. 38-50.
[4] FMI-Standard. URL: https:// www.fmi-standard.org/, Abrufdatum 02.12.2016.
[5] QTronic-FMI. URL: https:// www.qtronic.de/de/index_ news_14_3_FMUSDK.html, Abrufdatum 05.12.2016. [6] Siemens IOT2000. URL: http:// www.siemens.com/press/ de/pressemitteilungen/?- press=/de/pressemitteilungen/ 2016/digitalfactory/ pr2016030168dfde.htm&- content[]=DF, Abrufdatum 02.12.2016.