1 Virtuelle Inbetriebnahme im Maschinen- und Anlagenbau

Im Maschinen- und Anlagenbau entstehen heute zunehmend Simulationsmodelle von Produktionsanlagen, um die Produktentwicklung, die Produktionsplanung, den Produktionsanlauf, den Produktionsbetrieb und die Auftragsabwicklung [1] mit auf die Anforderungen der jeweiligen Lebenszyklusphase abgestimmten Methoden und Werkzeuge zu unterstützen. Dieses umfassende Netzwerk an simulationsbasierten Methoden und Werkzeugen entlang des Lebenszyklus einer Produktionsanlage wird unter dem Oberbegriff der Digitalen Fabrik zusammengefasst [2]. In [3] werden Simulationsmodelle als expliziter Produkt- und Anlagenbestandteil gesehen: „Simulationen werden integraler Bestandteil im gesamten Lebenszyklus, von der Planung über Design und Implementierung bis zum Betrieb und Service und erweitern damit bestehende Wertschöpfungsketten, schaffen neue Wertschöpfungsnetzwerke und ermöglichen neue Geschäftsmodelle“. In diesem Kontext steigt die Notwendigkeit zum Austausch und zur Wiederverwendung von Simulationsmodellen.

Zur Erfüllung der hohen und kontinuierlich wachsenden Anforderungen an Leistung, Qualität und Kosten der Automatisierungslösung bei steigendem Automatisierungsgrad ist der Einsatz von virtuellen Methoden und Werkzeugen heute bereits im Entwicklungsprozess („Digital Engineering“) von industriellen Produktionsanlagen unabdingbar. Von zentraler Bedeutung für den Maschinen- und Anlagenbau ist die Methode der Virtuellen Inbetriebnahme (VIBN), welche in den letzten Jahren vermehrt zur Anwendung kommt [4]. Die VIBN bezeichnet den der realen Inbetriebnahme (IBN) vorgelagerten Gesamttest des Automatisierungssystems mithilfe eines Simulationsmodells der Anlage [5]. Ein Simulationsmodell wird in diesem Beitrag als Digitaler Zwilling bezeichnet. Der Digitale Zwilling der Anlage ist aus virtuellen Komponenten und Baugruppen aufgebaut, welche die realen Hardwareprodukte mit ihren Schnittstellen und Parametern abbilden. Die Digitalen Zwillinge der eingesetzten Komponenten und Baugruppen enthalten die für eine VIBN wesentlichen Verhaltensmerkmale der realen Systeme. Für eine Hardware-in-the-Loop Simulation (HiLS) wird das Verhalten der Komponenten beispielsweise so nachgebildet, dass am Feldbus kein Unterschied zum Verhalten der realen Komponenten vorliegt. Bei der HiLS kann damit mittels industriellem Feldbus die reale Steuerungshardware in Betrieb genommen werden. Die VIBN ermöglicht es dem Maschinen- und Anlagenbau, die Entwicklungs- und Inbetriebnahmeprozesse signifikant zu beschleunigen, die Qualität zu erhöhen und Inbetriebnahmekosten zu senken. Die Strukturierung eines Simulationsmodells in Komponenten- und Baugruppenmodelle bildet die Basis für den Austausch und die Wiederverwendung von Modellteilen. Die Bereitstellung von Simulationsmodellen verspricht neben der massiven Reduzierung der Modellierungszeiten für die VIBN eine gleichzeitige Qualitätssteigerung aufgrund der Verwendung optimierter und validierter (Teil-) Modelle, beispielsweise direkt vom Komponentenhersteller.

Die Hersteller von Simulationswerkzeugen zur VIBN haben auf Basis der dargestellten Potentiale der komponentenbasierten Strukturierung die Notwendigkeit von Integrationsschnittstellen zur Einbeziehung von (Teil-)Modellen Dritter erkannt. Integrationsschnittstellen bieten die Möglichkeit, spezifische Teilmodelle in das Anlagenmodell zu integrieren. Bei einer Kopplung einzelner Module oder Teilmodelle zu einem Gesamtmodell wird in der Literatur auch der Begriff der Modellkopplung verwendet [6]. Die Aufteilung des Gesamtmodells in mechatronische Module anhand der Komponenten- und Baugruppengrenzen führt zu validierten Teilmodellen, die sich in einem Baukasten ablegen und in späteren Simulationsprojekten wiederverwenden lassen. Der modulare Aufbau bildet zusätzlich die Basis für eine vollautomatische Generierung von kundenindividuellen Anlagenmodellen im Engineering aus der Kommissionierungsliste [7].

Zur ganzheitlichen Simulation von virtuellen Maschinen und Anlagen müssen Modelle aus unterschiedlichen Fachdisziplinen miteinander gekoppelt und aufeinander abgestimmt werden. Bei der Kopplung von Modellen zu einem interdisziplinären Gesamtmodell spricht man von einer mechatronischen Systemsimulation. Bei der HiLS interagiert das Gesamtmodell mit den über die reale Kommunikationsperipherie ausgetauschten Steuerungssignalen. Das Gesamtmodell des Produktionssystems ist dabei aus unterschiedlichen Modellen zusammengesetzt:

  • Steuerungstechnische Modelle (z. B. Feldbuskomponenten, Sensoren und Aktoren)

  • Kinematische Modelle (z. B. Maschinen- und Roboterkinematiken)

  • Geometrische Modelle (z. B. 3D-Kollisionserkennung und Arbeitsraumanalyse)

  • Mechanische Modelle (z. B. Strukturmechanik und Dynamik)

  • Prozessmodelle (z. B. Materialabtrag und Zerspanung)

  • Materialflußmodelle (z. B. Handlings- und Fördereinrichtungen)

Die Verhaltensmodelle von Feldbuskomponenten, wie beispielsweise von Antrieben, werden heute vom Toolhersteller oder einem Simulationsspezialisten erstellt. Dabei wird das Verhalten abstrahiert und kann nur an das reale, charakteristische Verhalten (Rampen, Betriebsarten, etc.) angenähert werden. Die Bereitstellung von digitalen Abbildern der realen Feldbusteilnehmer direkt vom Komponentenhersteller hat dagegen den Vorteil, dass die einzelnen Komponenten bis hin zur realen Firmware und Parametrierung originalgetreu abgebildet werden können. Zusätzlich werden weitere Möglichkeiten zur vereinfachten Parametrierung der Komponentenmodelle direkt aus den Engineering-Werkzeugen des Komponentenherstellers geschaffen. Anwender können somit bereits in einer frühen Entwicklungsphase die virtuellen Anlagen prüfen, unterschiedliche Komponenten gegeneinander vergleichen sowie das spätere Verhalten der realen Maschine analysieren (z. B. Betriebsarten, Rampen). Weiter stehen erstmals realistische Digitale Zwillinge zur Verfügung, welche für Serviceanwendungen, Vorabprüfung von Firmwareupdates etc. genutzt werden können. Die steigende Aussagekraft des virtuellen Modells der Anlage führt, wie in Abb. 11.1 dargestellt, zur Erhöhung des erreichbaren Konkretisierungsgrads im Rahmen der VIBN und damit zur Reduzierung der Aufwände bei der realen Inbetriebnahme der Anlage.

Abb. 11.1
figure 1

Begrenzter Konkretisierungsgrad bei der HILS in Anlehnung an [8]

Full size image

Zunehmend suchen Komponentenhersteller deshalb nach Lösungen zur Bereitstellung Digitaler Zwillinge ihrer Hardwareprodukte, um ihren Kunden eine VIBN von Automatisierungskonzepten und -lösungen zu ermöglichen.

2 Plattform für Bereitstellung, Pflege und Austausch von Simulationsmodellen

Das im Folgenden betrachtete und in Abb. 11.2 dargestellte TwinStore Konzept [9] beschreibt die plattformbasierte Bereitstellung, die Pflege und den Austausch von Simulationsmodellen. Zielsetzung ist die Bereitstellung von bereits implementierten und validierten Simulationsmodellen direkt vom Komponentenhersteller oder Simulationsspezialisten (Provider) für den Einsatz in Simulationsprojekten des Maschinen- und Anlagenbauers oder Systemintegrators. Abb. 11.2 fasst den Weg des Digitalen Zwillings von der Bereitstellung von Modellbibliotheken der Provider (in Form von TwinStore Packages) in der TwinStore-Plattform über die Verwendung der Modelle im Rahmen des digitalen Engineerings bis in die Betriebsphase, beispielsweise zur Schulung des Betreiberpersonals oder für Servicefälle in der Betriebsphase, zusammen.

Abb. 11.2
figure 2

TwinStore Plattform für die Bereitstellung von Simulationsmodellen

Full size image

Dabei ist die Zielsetzung, dass Komponentenhersteller zukünftig neben den realen Komponenten auch deren digitale Abbildungen zur Verfügung stellen [1, 3] (siehe Abb. 11.2). Neben der Reduzierung der Modellierungszeiten und der Steigerung der Modellqualität wird durch die Bereitstellung der Digitalen Zwillinge wird eine neue Feedback-Möglichkeit zwischen Komponentenherstellern und deren Kunden geschaffen. Aus dem digitalen Produktkatalog kann der kundenspezifische Digitale Zwilling anhand der Bestellnummern der eingesetzten Komponenten zielgerichtet projektiert werden. Der Anwender wird befähigt mit einem Digitalen Zwilling der Komponente gefahrlos zu experimentieren und unterschiedliche Realisierungskonzepte zu prüfen. Aus einer Produktfamilie kann in virtuellen Testläufen die für den kundenspezifischen Anwendungsfall ideale Komponentenvariante identifiziert werden. Die Verfügbarkeit des Digitalen Zwillings entwickelt sich für den Komponentenhersteller zu einem entscheidenden Verkaufsargument seiner realen Hardwarekomponenten.

Ferner bieten Simulationsspezialisten zunehmend Bibliotheken zur Abbildung spezifischer, hochspezialisierter (Prozess-)Simulationen.

Dem Maschinen- und Anlagenbauer sowie Systemintegrator bieten sich mit dem offenen Bibliothekskonzept und dem Austausch von Simulationsmodellen neue Möglichkeiten, da er dem Anlagenbetreiber ein Simulationsmodell der kundenindividuellen Produktionsanlage für Schulungen des Betreiberpersonals oder betriebsbegleitende Untersuchungen zur Verfügung stellen kann. Die plattformbasierte Bereitstellung Digitaler Zwillinge bildet die Basis für neue Geschäftsprozesse und -modelle auch über den Entwicklungsprozess hinaus.

Abb. 11.3 stellt verschiedene Wege zu einem Komponentenmodell in Form eines TwinStore Package dar.

Abb. 11.3
figure 3

Wege zur Erstellung von TwinStore Packages zum Einsatz in einer Simulationsplattform für das digitale Engineering

Full size image

Zur Erstellung eines Komponentenmodells werden je nach Komponententyp verschiedene digitale Eingangs-Daten und -Informationen herangezogen. Diese digitalen Informationen können CAD-Daten im Dateiformat des eingesetzten CAD-Werkzeugs sowie die Komponentenfirmware, die entweder direkt im Quellcode vorliegt oder im Modellierungsprozess nachgebildet werden muss, sein.

Das Komponentenmodell besteht aus einem Verhaltensmodell und kann durch ein Geometriemodell ergänzt werden. Zur Erstellung des Verhaltensmodells greift der Modellierer auf vorhandene Black-Box-Bausteinbibliotheken (meist bereitgestellte Toolbibliotheken) zurück und bildet im Blockschaltbild das Verhalten der Komponente ab. Darüber hinaus können eigene Black-Box-Bausteine erstellt werden, indem das Black-Box-Verhalten mithilfe einer Programmiersprache beschrieben wird. Hierbei besteht auch die Möglichkeit, vorhandene Teile der originalen Komponentenfirmware in den Digitalen Zwilling zu integrieren. Dieser Ansatz wird von einigen Tools über proprietäre Schnittstellen realisiert, etwa das ISG-virtuos SDK C++ . Darüber hinaus verwendet das „Functional Mock-up Interface“ (FMI) [10] einen Blockansatz zur Standardisierung der Architektur von Black-Box-Teilmodellen, die über deren Ein- und Ausgänge (E/A) in ein Gesamtmodell integriert werden können.

Bei der Erstellung eines Verhaltensmodells zum Einsatz bei einer VIBN ist das Komponentenverhalten so abzubilden, dass die diskreten Ein-/Ausgabewerte der Steuerung über den digitalen Feldbus im Modell erzeugt werden, um die Steuerungstechnik auf das richtige Verhalten zu prüfen (siehe Abb. 11.4). Daran bemisst sich die bei der Modellbildung zu wählende Modellkomplexität respektive Modelltiefe (Level of Detail). Das Hauptinteresse bei der VIBN von Maschinen und Anlagen ist im Besonderen nicht auf eine optimierte Gesamtauslegung, sondern auf die eingesetzte Steuerungstechnik gerichtet. Industrielle Steuerungssysteme sind mit der Sensorik und Aktorik der Maschinen über einen digitalen Feldbus verbunden und enthalten, insbesondere in den maschinenspezifischen Softwareteilen, unvermeidbare Programmier- und Parametrierfehler im Steuerungsprogramm, die mittels der VIBN identifiziert und behoben werden sollen.

Abb. 11.4
figure 4

Verhaltensmodellierung einer Komponente

Full size image

Für einen durchgängigen Einsatz von Komponentenmodellen über den vollständigen digitalen Entwicklungsprozess und die Schulung des Betreiberpersonals bis in die Betriebsphase müssen die Verhaltensmodelle in unterschiedlichen Detaillierungsstufen, vom einfachen Model-in-the-Loop Modell bis hin zum echtzeitfähigen Hardware-in-the-Loop Modell, bereitgestellt werden. Die Herausforderung ist die Gestaltung eines optimalen Simulationsmodells für die einzelnen Teststufen, in der passenden Ausprägung, Modellgenauigkeit und Modelltiefe.

3 Packages und Bibliotheken

TwinStore Packages

Vom Provider von Simulationsmodellen werden Modellbibliotheken in Form von TwinStore Packages (TSP) bereitgestellt. Ein TSP trägt die Dateiendung .tsp und ist ein gewöhnlicher ZIP-Container.

Der Container enthält zum einen eine Meta-Datei im JSON (JavaScript Object Notation) Format mit allgemeinen Informationen zum TSP. Zum anderen finden sich im Container die Dokumentation zum Funktionsumfang und zum Einsatz des Modells in Simulationsprojekten, das Verhaltensmodell in Form einer Black-Box Beschreibung anhand von Ein-, Ausgängen und Parametriermöglichkeiten, die Geometrieinformationen mit der Kopplung ans Verhaltensmodell sowie dem eigentlichen Modellcode in Form einer DLL (Dynamic Link Library) für die Simulation unter Windows oder .sys für die Simulation unter Echtzeitbedingungen in der Beckhoff TwinCAT Echtzeiterweiterung. Modellcodes für weitere (Echtzeit-)Plattformen, wie beispielsweise B&R Automation Runtime und RTLinux, sind ebenfalls realisierbar.

Nach Erstellung der Komponentenmodelle werden Schutz- und Verschlüsselungsmechanismen verwendet, um das Know-how des Komponentenherstellers oder Simulationsspezialisten zu schützen. Der Anwender sieht im bereitgestellten (Teil-)Modell ausschließlich das Black-Box-Modell und damit dessen Ein- und Ausgangssignale sowie die Parametrierung des Komponentenmodells. Der schützenswerte Modellaufbau und Modellcode bleiben dem Anwender verborgen.

Im TwinStore Package Manager kann der Provider das TSP auf die Plattform laden und seine Bibliotheken verwalten. Neben Änderungen an bestehenden TSP enthält der TwinStore Package Manager eine Versionsverwaltung sowie Möglichkeiten zur individuellen Rechte- und Lizenzvergabe. Mit diesem Rechtemanagement ist gewährleistet, dass ein einzelnes TSP individuell zum Download freigeschaltet werden kann und die Regeln und Richtlinien für eine Nutzung über eine Lizenz durch den Provider festgelegt werden können.

Zur nahtlosen Einbindung von TSPs in Simulationsprojekte ist eine Integrationsschnittstelle im jeweiligen Simulationswerkzeug zur VIBN notwendig. Die Projektierung des Maschinen- oder Anlagenmodells erfolgt dann vollständig komponentenbasiert. Der Digitale Zwilling steht somit direkt zur Verwendung im Rahmen einer VIBN zur Verfügung.

Für den Provider von Simulationsmodellen entstehen neue digitale Geschäftsmodelle bei der Bereitstellung der digitalen Abbildungen seiner realen Hardwarekomponenten in Form von TSPs im TwinStore. Es ist abzusehen, dass die Verfügbarkeit eines Digitalen Zwillings zukünftig ein zentrales Verkaufsargument beim Vertrieb von Hardwarekomponenten darstellen wird.

Für den Anwender reduzieren sich die Modellierungszeiten durch die Einbindung vorgefertigter Simulationsmodelle. Einen Mehrwert stellt die detailliertere Simulation durch die Verwendung realitätsnaher Modelle zur Abbildung z. B. irregulärer Betriebsarten, dynamischer Parametrierung und des originalen Echtzeitverhaltens dar. Der Digitale Zwilling einer realen Hardwarekomponente soll sich exakt wie das reale System am Feldbus verhalten.

TwinStore Bibliotheken

Aus den digitalen Produktkatalogen der anbietenden Unternehmen kann ein Kunde den Digitalen Zwilling seiner kundenspezifischen Anlage zusammenstellen. Für jedes Simulationsmodell ist eine umfangreiche Dokumentation hinterlegt, über die sich der Kunde über die im Modell abgebildete Funktionalität informieren kann. Der TwinStore agiert als ein digitaler Marktplatz, über den der Digitale Zwilling bezogen werden kann. Die nahtlose Integration in Tools zur VIBN ermöglicht eine direkte Verwendung des zusammengestellten Simulationsmodells. Grundsätzlich unterscheidet der TwinStore zwischen drei Bibliotheksarten (Behaviour-Lib, Component- Lib und Platform-Lib), die im Weiteren mit exemplarischen Beispielen aus dem TwinStore erläutert werden:

In der Behaviour-Lib werden Simulationsbibliotheken zur Modellbildung im Blockschaltbild-Editor zur Verfügung gestellt. Diese Art von Bibliotheken enthalten ausschließlich Modellblöcke für den Blockschaltbild-basierten Modellierungsansatz. Unter anderem umfasst diese Bibliotheksart Modelle von Feldbuskomponenten ohne grafische Repräsentanz.

Im TwinStore stehen zahlreiche Antriebsmodelle zur Verwendung in einer HiLS zur Verfügung. Im Simulationsmodell werden die üblichen Steuer- und Statusbits für die Steuerung der abgebildeten Statemachine verwendet. Mit dem Simulationsmodell können gängige Funktionen wie u. a. das Positionieren (Fahrauftrag), Positionieren mit Reversieren, Schleifenfahrt, Handfahrt, usw. abgebildet werden. Dabei werden die einzelnen Phasen, wie z. B. Bremse öffnen, Startverzögerung, Beschleunigen, Fahrt mit konstanter Geschwindigkeit, Bremsen, Stoppverzögerung und Bremse schließen, abgebildet und können über eine Parametermaske konfiguriert werden.

Ein Beispiel ist das von der ISG bereitgestellte Modell eines Siemens Motorstarters SIRIUS 3RM1x. Der Digitale Zwilling bildet den Funktionsumfang des realen Geräts vollständig ab. Abb. 11.5 zeigt ein Einsatzbeispiel. Die Ein- und Ausgänge des Bausteins sind mit Signalen der Steuerung über Peripherie-E/As (Peripheral Ports) verbunden. Der Motorstarter gibt über den Ausgang IW_velocity die Geschwindigkeit an einen Physikbaustein, der einen Motor für ein Förderband simuliert.

Abb. 11.5
figure 5

Konfigurationsbeispiel eines Digitalen Zwillings aus der Behaviour-Lib

Full size image

In der Component-Lib werden virtuelle Komponentenmodelle bestehend aus einem Blockschaltbild- und einem Geometriemodell zur Verfügung gestellt. Diese Art von Bibliotheken enthalten damit neben einem Black-Box Bausteinmodell im Blockschaltbild zusätzlich ein verknüpftes Geometriemodell.

Der TwinStore enthält bereits Bibliotheken mit verschiedenen virtuellen Baugruppen, beispielsweise für Robotersysteme, Antriebstechnik, Fördertechnik, Greifsysteme und Sensorik. In unterschiedlichen Baugruppen-Bibliotheken wurden einzelne Baugruppen abgebildet, die sich zu einem individuellen Anlagenkonzept per Drag-and-drop im 3D projektieren lassen. Bei der 3D-Projektierung entsteht das Simulationsmodell, welches ohne weiteren Modellierungsaufwand zur VIBN eingesetzt werden kann.

Beispiele der Component-Lib sind die in Abb. 11.6 dargestellten 3D-Komponentenmodelle zur Projektierung einer Roboterzelle. Robotermodelle bestehen dabei aus einer 3D-Visualisierung und einem hinterlegten Kinematikmodell, welches auf Basis der im Datenblatt des Roboterherstellers zur Verfügung gestellten Informationen parametriert ist. Das Komponentenmodell bietet Schnittstellen wie z. B. zur Kopplung mit einem Greifermodell. Hierfür ist im TwinStore beispielsweise das Simulationsmodell des Zimmer Greifers GEH6000IL-Gripper inklusive der Feldbusschnittstellen der Komponentenfirmware (Logik-Modell) und dem Physikmodell hinterlegt. Das Physikmodell ermöglicht eine Anbindung an individuelle Kinematiken sowie an ein Materialflussmodell zur Simulation von Handhabungsaufgaben.

Abb. 11.6
figure 6

Projektierung der virtuellen Anlage aus TwinStore Packages

Full size image

Ein Beispiel für das Simulationsmodell eines photoelektrischen Sensors ist der Digitale Zwilling der Komponente WTB4SC-3P2262A00 von SICK. Dieses besteht aus den Kommunikationsschnittstellen, der Komponentenfirmware (Logikmodell) und dem Physikmodell. Für die Simulation der Komponentenfirmware wurde ein besonderer Wert auf die Möglichkeit zur Übernahme der Komponentenparametrierung aus den Engineering-Tools des Komponentenherstellers gelegt. Das Physikmodell berücksichtigt Sensor-relevante Einflussgrößen wie z. B. Glanzgrad, Winkellage, Farbe, Transparenz, der Detektions- und Hintergrundobjekte und bietet eine Schnittstelle zur Kopplung mit einem Materialflussmodell.

Die Platform-Lib stellt Online-Schnittstellen für die Anbindung und Kopplung weiterer Softwarewerkzeuge zur Verfügung. Beispiele sind vorgefertigte Schnittstellenlösungen zur Anbindung von virtuellen Steuerungen, z. B. Software-in-the-Loop Simulation (SiLS), und von spezialisierten Simulationswerkzeugen.

Im TwinStore sind mittlerweile eine Vielzahl von Schnittstellen, beispielsweise zur Anbindung von Siemens PLCSimAdvanced, Siemens Sinumerik One, KUKA OfficeLite und Fanuc RoboGuide, verfügbar.

Die im TwinStore verfügbaren Bibliotheken in der Behaviour-Lib, Component-Lib und Platform-Lib werden sukzessive weiter ausgebaut. Die erläuterten Komponentenmodelle liegen als TSP vor und wurden im Simulationswerkzeug ISG-virtuos umgesetzt. Für die Erstellung der Modelle ist sowohl der Blockschaltbild-Ansatz als auch die Programmierung von Black-Box Bausteinen möglich. Im Blockschaltbild kommen verfügbare ISG-virtuos Toolbibliotheken zum Einsatz. Für die Integration der Komponentenfirmware wird die ISG-virtuos C++ SDK Schnittstelle zur Erstellung eigener Echtzeitmodelle eingesetzt.

4 Zusammenfassung und Ausblick

Die Digitale Fabrik verfolgt die Vision der Verfügbarkeit eines Digitalen Zwillings der realen Maschine oder Anlage samt maßgeschneiderten digitalen Werkzeugen und Methoden über den gesamten Lebenszyklus. Der in diesem Beitrag vorgestellte TwinStore bildet eine digitale Austauschplattform für Simulationsmodelle, auf der Komponentenhersteller Digitale Zwillinge direkt zur Verfügung stellen und vertreiben können.

Die weitere Ausgestaltung der Austauschplattform TwinStore erfolgt im Rahmen der TwinStore Community. In der TwinStore Community engagieren sich Komponentenhersteller, Simulationsspezialisten, Maschinen- und Anlagenbauer, Systemintegratoren und Anwender einer VIBN. Neben der Ausgestaltung der TwinStore Plattform wird der Umfang der verfügbaren Bibliotheken sukzessive weiter ausgebaut. Im Rahmen der Zusammenarbeit erfolgt die Normierung und Standardisierung von Simulationsmodellen in TwinStore Packages. Derzeit wird in der Community an „Best Practice“ Anwendungen gearbeitet, die einen Einsatz validierter Komponentenmodelle aus dem TwinStore in komplexen VIBN aufzeigen. Zudem wird die Erarbeitung eines Zertifizierungsvorgehens und damit einer Qualitätssicherung für geprüfte Simulationsmodelle vorangetrieben. Hierbei wird die Identifikation von Qualitätskriterien sowie die systematische, automatisierte Bewertung der Qualität von TSP untersucht [4]. Daneben wird ein digitales Geschäftsmodell für den Austausch von TSP erarbeitet.