Einsatz von Cloud-Technologien und -ressourcen in der Co-Simulation

Sowohl die zunehmende Volatilität der Rohstoff- und Energiemärkte als auch die intensivere politisch geforderte Sektorenkopplung und die Ausprägung cross-industrieller Netzwerke erfordern bei Fragestellungen der Systemintegration und dem Design sowie der Optimierung von Prozessen (Bruns et al. 2021), insbesondere im verfahrenstechnischen Bereich, einen integralen Ansatz, der gleichzeitig die verteilte und multidisziplinäre Entwicklung der beteiligten Teilsysteme ermöglicht.

Unter verfahrenstechnischer Systemintegration wird dabei allgemein die Komposition eines komplexen Gesamtsystems aus mehreren technischen Teilsystemen verstanden (Abb. 1). Häufig geht dem realen Bau einer verfahrenstechnischen Anlage die mathematische Modellierung und Simulation des Gesamtsystems voraus, um einen bestimmungsgemäßen Betrieb innerhalb der Betriebsparameter im Vorfeld sicherzustellen.

Bei der mathematischen Modellierung des Gesamtsystems ist die Berücksichtigung externer, geschlossener Modelle (sogenannte Black-Box-Modelle) für das Gesamtsystem von entscheidender Bedeutung, da Lieferanten oftmals die physikalisch detaillierten Wirkmechanismen ihrer Komponenten nicht offenlegen (Schutz des geistigen Eigentums). Zur Analyse derartig gekoppelter Modelle existieren zwei unterschiedliche Ansätze.

Einerseits können die Systemintegrierenden eine multidisziplinäre Modellierungssprache verwenden und mit Hilfe geeigneter Werkzeuge, wie z. B. Modelica (Modelica Association 2018) oder Advanced Continuous Simulation Language (ACSL) (Mitchell und Gauthier 1976), ein monolithisches Gesamtmodell erstellen, in dem die unterschiedlichen Domänen in einer einheitlichen abstrakten Form zusammengeführt werden. Die resultierenden mathematischen Strukturen – in der Regel differentiell-algebraische Gleichungssysteme – werden anschließend durch entsprechende Algorithmen simultan zur Lösung gebracht. Zwar erlauben entsprechende Werkzeuge eine ergonomische und effiziente Modellierung des Gesamtsystems, jedoch können geschlossene Modelle nur bedingt berücksichtigt werden, da ihre systeminternen physikalischen Mechanismen in der Regel unbekannt sind oder nicht zur Verfügung gestellt werden.

Der ursprünglich iterative und sequenzielle Prozess der Systemintegration kann auf diese Weise parallelisiert und somit insbesondere unter Nutzung von Cloud-Ressourcen erheblich effizienter und skalierbarer (Die Skalierbarkeit ist das Maß dafür wie gut das System auf Veränderungen reagiert, indem es Ressourcen hinzufügt oder entfernt, um den Anforderungen gerecht zu werden) gestaltet werden, da jedes Subsystem in unterschiedlichen Ausprägungen simultan in verschiedenen Prozesskonzeptvarianten untersucht werden kann. Im vorliegenden Artikel wird beschrieben, wie eine solche Lösung unter Einsatz von Cloud-Technologien und -Ressourcen zu einem skalierbaren System ausgebaut wurde. Dabei werden sowohl Privacy-Aspekte der beteiligten Akteure als auch eine optimale Ausnutzung lokaler und in der Cloud verfügbarer Ressourcen unter Berücksichtigung von Performance- und Kostenaspekten betrachtet. Der Einsatz der ausgewählten Technologien erlaubt es, eine Vielzahl an Berechnungen parallelisiert durchzuführen und so komplexe Parameterräume durch entsprechende Variationsrechnungen gleichzeitig in kürzester Zeit abzutasten. So können mögliche Betriebszustände und Optima effizient ermittelt werden.

Bei der Systemintegration ist häufig die zeitabhängige Dynamik der Systeme – z. B. bei Start- oder Shut-Down-Prozessen – von besonderem Interesse (Deerberg et al. 2003). Daher ist die Anwendung instationärer Modelle erforderlich. Auf verteilte Parameter und damit auf die Berücksichtigung raumabhängiger Effekte wird aufgrund der resultierenden Rechenkomplexität und der damit verbundenen Laufzeiten der entsprechenden Simulationswerkzeuge in der Regel zunächst verzichtet.

Aus diesem Grund konzentriert sich die modellbasierte Systemintegration oftmals im ersten Schritt auf transiente Modelle mit konzentrierten Parametern, welche im Allgemeinen als differentiell-algebraisches Systeme (DAE System) formuliert sind (Deerberg et al. 2003). Diese Systeme können in allgemein impliziter Form geschrieben werden als:

Dabei sind x und F Vektoren, t die Zeit x repräsentiert den systeminternen Zustand. Oft liegen diese Systeme als quasilinear implizites System (QI-System) in der folgenden Form vor:

Die Matrix B ist in vielen praktischen Fällen dünn besetzt und in der Regel singulär. Liegt ein gekoppeltes, multidisziplinäres, monolithisches Gesamtsystem vor, so kann dieses entsprechend in seine monodisziplinären Subsysteme zerlegt werden:

Hierbei sind die Vektoren x_i die internen Zustandsvektoren, u_i die Eingangsvektoren sowie y_i die Ausgangsvektoren des jeweiligen Subsystems i. Die Funktionen f_i und g_i sind meist nichtlineare Vektorfunktionen.

Werden alle relevanten Subsysteme in einem monolithischen Modell formuliert und anschließend mit Hilfe eines entsprechenden Solvers ausgewertet, spricht man von einer starken Kopplung (Busch 2012). Dieses Vorgehen wird häufig bei der klassischen Systemintegration eingesetzt.

Aufgrund der Stabilität dieser hoch optimierten Solver ist diese Form der Kopplung auch bei der Integration unterschiedlich steifer Subsysteme numerisch sehr stabil, da z. B. die Schrittweiten der der Steifheit der jeweiligen Subsysteme angepasst werden. Ohne Nutzung von sogenannten Sparse-Algorithmen steigt die Komplexität quadratisch mit der Anzahl der Gleichungen.

Gemäß Abb. 3 wird im Referenzsystem als zentrales Element M₁ ein ideal durchmischter Rührkesselreaktor verwendet, der kontinuierlich betrieben wird. Die Kinetik im Reaktor wird von einer chemischen Reaktion erster Ordnung dominiert. Der Reaktor wird durch einen Mantel gekühlt. Das Kühlmedium wird dabei über die Pumpe M₃ im Kreis geführt und aus dem Vorlagebehälter M₄ entnommen, nach der Aufheizung im Reaktormantel in dem Wärmeübertrager M₂ heruntergekühlt und anschließend wieder in den Behälter gepumpt. Mit Hilfe des PID-Reglers M₆ soll der Volumenstrom im gesamten Kühlkreislauf so eingestellt werden, dass die Reaktortemperatur, die über das PT 100 Widerstandsthermometer (DIN EN 60751:2009-05) ermittelt wird, auf einem definierten Niveau gehalten wird.

Diese Art der Reaktionsführung wird häufig im großtechnischen Kontext beispielsweise in der Pharmaindustrie eingesetzt. Gerade die korrekte Temperaturführung ist hier in der Regel entscheidend für die Qualität der Produkte. Oftmals werden die Rührkessel dann auch in Kaskaden betrieben, um den Umsatz zu optimieren. Die transiente Simulation eines solchen Systems wird in der Verfahrenstechnik unter anderem angewendet, um das Zusammenspiel und die zeitabhängige Dynamik der beteiligten Teilsysteme zu untersuchen und zu optimieren.

Die gemessenen Temperaturen sowie die Sollwerte und Stellsignale werden gemäß DIN IEC 60381‑1 (DIN IEC 60381-1:1985-11) über die entsprechenden Transmitter M₅ und M₇ auf einen Bereich von 4,0 bis 20,0 mA abgebildet. Die Sollwertvorgabe des Systemeingangs In₃ soll nach t = 200 s einen diskreten Sprung von 390,0 K auf 420,0 K aufweisen, um so die Sprungantwort und das Verhalten des Systems bei Beteiligung einer diskreten Variablen zu untersuchen. Die Simulation des Referenzsystems, bestehend aus 12 gekoppelten Subsystemen mit insgesamt 54 Differentialgleichungen, einer Differenzengleichung und fünf algebraischen Gleichungen, soll im Zeitfenster [0 s, 300 s] durchgeführt werden.

Die Herleitungen sowie die theoretischen Grundlagen beteiligten Teilmodelle mit Benennung entsprechender weiterführender Literaturstellen sind bei Wack (2022) uu finden.

Häufig entstehen durch entsprechende Variationen in der Systemintegrationsaufgabe komplexe Szenarienräume. Werden beispielsweise D_in unterschiedliche Eduktvariationen (z. B. variierende Einsatzmengen und Feedströme) mit D_out verschiedenen Szenarien für die Produktmärkte (z. B. variierende Erlöse für das Produkt) kombiniert und dazu D_S verschiedene Varianten für einen Anlagenverbund untersucht, welche jeweils mit D_CE unterschiedlichen Szenarien für die Investitionskosten (CAPEX „Capital Expenditures“) und D_OE Szenarien für die Betriebskosten (OPEX „Operational Expenditures“) betrachtet werden, so entstehen in Summe D Varianten mit:

Je engmaschiger dieser Szenarienraum abgetastet wird, also je größer D_i ist, umso genauer kann der Korridor ermittelt werden, in dem ein Anlagenkonzept wirtschaftlich betrieben werden kann. Schon bei D_i = 10 entstehen in Summe 100.000 Variationen. Bei einer Rechenzeit von 10 min benötigte die komplette Berechnung aller Varianten bei sequenzieller Bearbeitung ca. 394 Tage.

Das in Abschn. 2 beschrieben Waveformrelaxations-Verfahren wurde als Python-Package implementiert und steht unter https://​pypi.​org/​project/​simunetcore (Wack 2023) öffentlich zur Verfügung. Es bildet den sogenannten simunet-core und bietet die Möglichkeit, beliebige eigene Modelle zu erstellen, diese zu Systemen zu verschalten und wie beschrieben mittels Gauss-Seidel- oder Jacobi-Verfahren zu lösen. Die beispielhafte Anwendung ist unter https://​simunet.​org/​getting-started (Fraunhofer UMSICHT 2023) veranschaulicht.

Darauf aufbauend wurde im Rahmen des Großforschungsprojektes Carbon2Chem® (Deerberg et al. 2018) eine Simulationsplattform entwickelt, um eine ergonomische Benutzeroberfläche und ein skalierbares Compute-Backend zu schaffen. Die webbasierte Plattform besteht aus einer Modellregistrierung, einem Fließbildeditor, Komponenten zur Konfiguration und Durchführung einzelner Simulationen und zur Visualisierung der Berechnungsergebnisse. Für das „Abtasten“ ganzer Parameterräume wurde zusätzlich ein Szenario-Manager implementiert, der es erlaubt, komfortabel Wertebereiche oder -listen für ausgewählte Parameter anzulegen und die Berechnung der sich daraus kombinatorisch ergebenden Varianten durchzuführen. Die Visualisierungskomponente wurde entsprechend erweitert, um den Vergleich einzelner Varianten ergonomisch und effizient zu ermöglichen. Das Frontend ist durchgängig webbasiert und kommuniziert mit entsprechenden Microservices im Backend.

Bei der Umsetzung wurde a priori der Cloud-native Ansatz verfolgt (Abb. 4). Alle Komponenten werden als Container in einer Private Cloud auf einem lokalen Kubernetes Cluster unter Verwendung gängiger DevOPs Methoden und Tools über eine CI/CD Pipeline bereitgestellt und betrieben. Der Einsatz einer Private Cloud war zunächst durch die projektspezifischen Anforderungen vorgegeben.

Alternativ könnten einzelne oder alle Komponenten auch in beliebigen Public Clouds betrieben werden, sofern Kubernetes zur Container-Orchestrierung verfügbar ist. Die definierten Systeme sowie die Simulationsergebnisse werden in einem S3-kompatiblen (Simple Storage Service) Objektspeicher abgelegt. Für die Kommunikation zwischen den Microservices werden sowohl dedizierte REST-Aufrufe (Representational State Transfer) zur Übertragung synchroner Kommandos als auch Events (Apache Kafka als Event-Streaming-Plattform) zum asynchronen Datenaustausch verwendet. Die konsequente Verwendung von gängigen Datenformaten, hier vor allem JSON (JavaScript Object Notation), Kommunikationsprotokollen und Backend-Komponenten ermöglicht jederzeit den Betrieb der Plattform in unterschiedlichen Clouds sowie in hybriden bzw. Multi-Cloud Konstellationen. Entscheidend für die konkrete Wahl des Ansatzes sind vor allem zugrundeliegende Compliance-Anforderungen.

Eine besondere Bedeutung kommt den Aufrufen der jeweiligen Teilmodelle (bzw. deren numerische Implementierung) durch die zentrale Waveformrelaxation zu. Wie eingangs beschrieben, werden einzelne Modelle häufig von Akteuren bereitgestellt, die keine detaillierte Einsicht in die numerische Umsetzung ihres Modells, und damit in die zugrunde liegenden physikalischen Details, gewähren. Daher erlaubt es der simunet-Core, einzelne Modelleaufzurufen.

Bei den Varianten 2.), 3.) und 4.) trägt derjenige, der das Modell bereitstellt, die alleinige Verantwortung für die Sicherheit, die korrekte Ausführung und die ggf. erforderliche Skalierung der numerischen Lösung (Abb. 4). Vorausgesetzt wird lediglich, dass die Ein- und Ausgabedaten der Aufrufe im JSON-Format übergeben werden. Zur Absicherung steht ein verbindliches JSON-Schema zur Verfügung, das jederzeit eine syntaktische Prüfung erlaubt. Der grundsätzliche Aufbau ist in Abb. 5 dargestellt.

Grundsätzlich ist beim Einsatz von Remote-Modellen aufgrund von Latenzen, Bandbreitenlimitierungen und Protokoll-Overhead mit Performance-Einbußen zu rechnen. Zudem hängt die reine Laufzeit einer Modellberechnung neben der spezifischen numerischen Implementierung von den remote verfügbaren Rechenressourcen ab. Diese Einbußen müssen jedoch in Kauf genommen werden, wenn Black-Box-Modelle ermöglicht werden sollen.

Insbesondere bei den oben beschriebenen Szenariorechnungen ist eine derartige Architektur notwendig, da hier durch die Kombination mehrerer Parameter mit jeweils mehreren Werten schnell eine sehr große Anzahl von Varianten entsteht, die eine entsprechend große Anzahl an Modellberechnungen erfordern. Beispielhaft werden für das gegebene Referenzsystem von den zahlreichen Modellparametern nur drei in jeweils 10 Schritten variiert, daraus ergeben sich insgesamt \(D=\prod _{i}D_{i}=10\cdot 10\cdot 10=1000\) Varianten.

Soll ein solcher Parameterraum berechnet werden, generiert der Szenario-Manager alle notwendigen Varianten (Eingabedaten) und sendet diese an einen oder mehrere simunet-Kernel. Diese werden typischerweise lokal in Form mehrerer Container (Waveform-Worker) bereitgestellt, von denen jeder wiederum durch Multiprocessing mehrere Simulationsrechnungen gleichzeitig durchführen kann. In der hier betrachteten Referenzarchitektur stehen 64 Waveform-Worker mit jeweils 16 Prozessen zur Verfügung, so dass maximal 1024 Berechnungen gleichzeitig durchgeführt werden können.

Für das Referenzsystem wurde die maximale Iterationstiefe auf m_max = 15 festgelegt, so dass ein Makrozeitschritt nach maximal 15 Iterationen beendet wird. Für jede Iteration werden N_mod = 12 Modellberechnungen aufgerufen. Diese Aufrufe erfolgen im Jacobi Modus parallel, im Gauss-Seidel Modus sequenziell. Der Adaptionsmechanismus (Abb. 2) zerlegt das Zeitfenster der Gesamtsimulation t = [0 s, 300 s] abhängig von der Parameterkonstellation in bis zu N_t = 100 Makrozeitschritte. Die Anzahl der Aufrufe für eine Variante beträgt also im Worst-Case:

Für eine Berechnung eines Szenarios mit 1000 Varianten bedeutet dies dann bis zu 18.000.000 Modellberechnungen. Es ist leicht zu erkennen, dass für eine effiziente Berechnung eines Szenarios dieser Größenordnung eine parallele Abarbeitung der Einzelberechnungen zwingend erforderlich ist.

Das eingangs beschrieben Referenzsystem wurde in simunet modelliert und mit Jacobi-Basisschritten simuliert. Der Simulationszeitraum beträgt 360 s und es werden insgesamt 1000 Zeitschritte berechnet.

Die zwölf verwendeten Modelle werden als Function as a Service beim Cloud-Anbieter AWS betrieben. Dies entspricht der im Abschn. 5 beschrieben Variante 4. Die Varianten 1 bis 3 hängen bezüglich ihrer Performanz sehr stark von der Implementierung des jeweiligen Backends ab. Daher wird im Weiteren lediglich Variante 4 untersucht, da diese Variante ein reproduzierbares und nachvollziehbares Benchmark zulässt.

Die Berechnung des Referenzsystems benötigt circa 50 s. Es sind insgesamt 40 Segmentberechnungen und 416 Iterationen erforderlich, jedes verwendete Modell wurde also 416-mal aufgerufen. Daraus ergeben sich in Summe circa 5000 Funktionsaufrufe für eine einzelne Berechnung.

Sollten nun drei Parameter in jeweils 10 Schritten variiert werden, so ergeben sich nach (11) insgesamt 1000 Berechnungen, mit in Summe circa 5 Mio. Funktionsaufrufen. Müssten diese Berechnungen sequenziell ausgeführt werden, so würde die Gesamtrechenzeit mindestens 1000 ⋅ 50 s ≈ 14 h betragen.

In nächsten Schritt wurde mit Hilfe des Szenarienmanagers sukzessive die Anzahl der Varianten erhöht und die Gesamtrechenzeit ermittelt. Abb. 6 zeigt die Ergebnisse dieser Untersuchung.

Im Bereich von 1 bis 100 Varianten bleibt die Gesamtrechenzeit in etwa konstant bei circa 50 s. Danach steigt sie auf bis zu 245 s bei 1000 Varianten an. Nähere Untersuchungen haben ergeben, dass dieser Effekt durch eine Bandbreitenlimitierung zwischen der Private Cloud und AWS zustande kommt. Selbst die Rechenzeit von ca. 4 min bei 1000 Varianten bedeutet jedoch gerade einmal einen Faktor 5 bezogen auf eine einzelne Berechnung.

Bei ausreichender Bandbreite zwischen allen beteiligten Instanzen ist somit davon auszugehen, dass sich die Gesamtrechenzeit für n Varianten näherungsweise von O (n) bei sequenzieller Berechnung auf ≈ O (1) reduziert und ebenso keine Limitierung bei der Anzahl gleichzeitiger Rechnungen zu erwarten ist.

Die notwendige Rechenzeit für ein Modell hängt stark von den verfügbaren Ressourcen ab. Bei remote betriebenen Modellen in der AWS-Cloud beispielsweise, wird über die Zuweisung von Speicher ebenfalls die Anzahl der verwendeten virtuellen Prozessoren vorgegeben. Mittels verfügbarer Tools des Anbieters lassen sich darüber die Laufzeit und/oder die Kosten pro Aufruf optimieren (Amazon Web Services 2023) Die Ausführung der Funktionen auf ARM (Acorn RISC Machines) – anstatt x86-Prozessoren führt laut Anbieter zu einem Laufzeit- und Kostenvorteil von bis zu 34 % (Amazon Web Services 2021).

Die Positionierung der einzelnen Systemkomponenten in derselben Cloud würde die beschriebene Bandbreitenlimitierung weitestgehend aufheben und Latenzen minimieren. Hier sind lediglich Compliance-Vorgaben der beschränkende Faktor, da innerhalb der Simulationsplattform und in den Waveform-Workern alle Informationen über die Verschaltung der Modelle, Stoffdaten, Regelalgorithmen, Kosten usw. hinterlegt sind. Dieses spezifische Wissen darf häufig nicht in öffentlichen Clouds gehandhabt werden.

Die zunehmende Komplexität verfahrenstechnischer Gesamtsysteme im Zuge der vermehrten cross-industriellen Kopplung stellt sehr hohe Anforderungen an die Systemintegration und damit an die mathematische Modellierung und computergestützte Simulation solcher Systeme. Dabei sind die algorithmisch effizientesten Ansätze häufig aufgrund der vielen beteiligten Mitwirkenden und deren nachvollziehbarem Anspruch, ihre Daten sowie ihr Wissen über Prozessdetails und damit ihr geistiges Eigentum zu schützen, nicht einsetzbar. Weiterhin erschweren diese Algorithmen ein effizientes paralleles Arbeiten. Sie führen häufig zu einem zeitaufwändigen iterativ-sequenziellen Vorgehen. Das Prinzip der Co-Simulation bietet hier eine Möglichkeit, diesen Anforderungen gerecht zu werden und eine verteilte und simultane Entwicklung der Submodule unter Wahrung des jeweiligen Fachwissens zu ermöglichen.

Die vorgestellte Implementierung einer Co-Simulationsplattform, die auf etablierten Cloud-Technologien basiert, ermöglicht den Einsatz von Black-Box-Modellen, die von verschiedenen Akteuren bereitgestellt werden können. Jeder Anbieter kann seine spezifischen Modelle an verschiedenen Standorten, in der Regel in seiner bevorzugten Cloud (Private oder Public), betreiben. Mit Hilfe des Szenario-Managers können umfangreiche Parametervariationen orchestriert werden. Das vorgestellte System bietet die Möglichkeit, die Berechnungen parallel auszuführen und die Ergebnisse zentral zu aggregieren. Auch hier ist der Einsatz von Cloud-Technologie, insbesondere die elastische Skalierbarkeit von „Function as a Service“-Lösungen, hervorragend geeignet, um die Rechenzeit bei einem hohen Maß an Kostenkontrolle zu reduzieren. Beliebig viele Varianten eines Szenarios können parallel berechnet werden und die Gesamtrechenzeit des Szenarios liegt in derselben Größenordnung wie die Rechenzeit der langsamsten Variante. Limitiert wird dies gegebenenfalls durch Bandbreitenbeschränkungen und/oder zu knapp bemessenen Ressourcen auf der remote-Seite.