CarMaker in der AWS-Cloud

Die ADAS-Absicherung stößt an die Grenze der Skalierbarkeit. Jede neue Funktion, Sensorkonfiguration oder gesetzliche Anforderung vervielfacht die Anzahl der zu testenden Fahrszenarien – und jedes Szenario muss möglicherweise mit zahlreichen Parametervariationen durchgespielt werden. Auf einem lokalen Rechner werden diese Testläufe nacheinander ausgeführt, sodass die Durchlaufzeit mit der Größe des Testdatensatzes sofort zunimmt. Ingenieur*innen müssen warten, die Hardware läuft stundenlang mit voller Auslastung und der Rückstau im Absicherungsprozess steigt.

Doch nicht nur die eigentliche Rechenleistung führt zu einem Engpass, es handelt sich auch um ein Workflow-Problem. Die manuelle Umgebungserstellung, Versionsabweichungen zwischen den Rechnern, uneinheitliche Tool-Installationen und wiederholte manuelle Konfigurationen führen zu Verzögerungen und Risiken. Somit erhalten zwei Ingenieur*innen, die denselben Test auf unterschiedlich konfigurierten Rechnern durchführen, möglicherweise keine vergleichbaren Ergebnisse. Das eigentliche Ziel besteht daher nicht nur darin, mehr Rechenleistung bereitzustellen. Es geht auch darum, die Definition, das Starten, die Nachverfolgung und Messung von Simulationen neu zu gestalten, damit sie von Beginn an wiederholbar und skalierbar sind.

In dem in diesem Artikel verwendeten Beispiel ist CarMaker weit mehr als nur eine Anwendung, auf die remote zugegriffen werden kann. Es wird eine integrierte virtuelle Entwicklungsumgebung vorgestellt, die aus vier eng miteinander verzahnten kontrollierten und standardisierten Ebenen besteht. Die Benutzerzugriffsebene bietet eine einheitliche Web-Benutzeroberfläche für die Zusammenarbeit zwischen verschiedenen Nutzerrollen. Die Umgebungsebene stellt standardisierte, vorgefertigte Maschinen-Images bereit, sodass alle im Entwicklungsteam mit der gleichen CarMaker-Installation arbeiten. Die Ausführungsebene führt die eigentlichen Simulationen durch, entweder interaktiv oder in parallelen Batches. Schließlich werden auf der Ergebnisebene die Ergebnisse und die wichtigsten Kennzahlen zu Kontroll- und Analysezwecken erfasst. Da diese Ebenen klar voneinander getrennt sind, kann jede einzelne Ebene unabhängig weiterentwickelt werden, während der Gesamtworkflow unverändert bleibt.

Das System baut auf dem Everything-as-Code-Prinzip (EaC) auf. Jede Ressource – ganz gleich ob Netzwerk, Server, Container-Image, Berechtigung oder Rechenflotte – wird dabei im Code beschrieben und bei Ausführung eines Workflows automatisch bereitgestellt. Nach Abschluss des Prozesses wird sie wieder freigegeben. Da es keinen Leerlauf gibt, werden die Kosten niedrig gehalten und Abweichungen, die durch die Nutzung von langjährig manuell gewarteten Servern auftreten, vermieden. Diese Umgebung ermöglicht die nahtlose Integration von CarMaker und spiegelt die im modernen Software-Engineering übliche Nutzung wider.

Im Mittelpunkt der Architektur steht ein Streamlit-Web-Frontend, das als Docker-Container gepackt und auf einer Amazon-EC2-Instanz gehostet wird – die einzige Schnittstelle für Nutzende. Dahinter befindet sich eine Ebene für Continuous Integration and Delivery (CI/CD), die folgende Elemente kombiniert: GitHub Quellcode-Repository, AWS CodePipeline für die Orchestrierung, AWS CodeBuild für die Erstellung von Container-Images, Amazon ECR als Image-Registry und AWS CloudFormation für die Bereitstellung der Infrastruktur. Wenn Nutzende eine Aktion anfordern, löst das Frontend die entsprechende Pipeline aus, die die notwendigen Elemente aufbaut und bei Bedarf bereitstellt.

Zwei Rechenumgebungen übernehmen die eigentliche Simulationsarbeit: Eine interaktive EC2-GUI-Instanz ermöglicht Ingenieur*innen über das Remote-Desktop-Streaming NICE DCV eine vollumfängliche grafische CarMaker-Sitzung in der Cloud. Eine AWS-Batch-Flotte führt die Befehlszeilenschnittstelle für CarMaker gleichzeitig auf vielen Instanzen aus und ermöglicht so eine hochskalierte parallele Ausführung. Unterstützt werden diese Rechenumgebungen durch Speicher- und Konfigurationsdienste, wie beispielsweise Amazon S3 Buckets in denen Pipeline-Artefakte und CarMaker-Assets gespeichert werden, oder Amazon DynamoDB-Tabellen, die beispielsweise Simulationsläufe nachverfolgen können. Alle Elemente befinden sich in einer einzigen virtuellen privaten Cloud (VPC) mit öffentlichen Teilnetzen und einem Internet-Gateway, die die Ebenen sicher miteinander verbindet.

Die Entwicklungsumgebung besteht aus vier unabhängigen Pipelines, die jeweils einen anerkannten Software-Engineering-Workflow abbilden und auf einer gemeinsamen Basis aufbauen:

1. Frontend-Pipeline: Diese Pipeline ist für die Generierung und Bereitstellung der Weboberfläche selbst verantwortlich, über die Nutzende alle anderen Workflows auswählen und auslösen können.
2. AMI-Pipeline: Diese Pipeline erstellt die standardisierten Umgebungen. Mithilfe des EC2 Image Builder wird CarMaker ausgehend von einem einfachen Amazon Linux-Image zusammen mit den erforderlichen Projektdateien und der aus S3 abgerufenen Lizenzkonfiguration installiert. Das Ergebnis wird als wiederverwendbares Amazon Machine Image (AMI) gespeichert. Umgebungen werden somit zu versionierten Artefakten und sind keine manuell zusammengestellten, instabilen Systeme mehr: Ein Image kann bei Bedarf mehrfach identisch ausgeführt werden werden.
3. EC2-GUI-Pipeline: Diese Pipeline stellt Ingenieur*innen einen interaktiven CarMaker-Desktop in der Cloud zur Verfügung und entkoppelt CarMaker vom physischen Arbeitsplatz: Dieselbe standardisierte Sitzung kann bei Bedarf jederzeit gestartet, genutzt und beendet werden, was die feste, lokale Installation durch eine konsistente, bedarfsgesteuerte Remote-Lösung ersetzt.
4. Batch-Pipeline: Diese Pipeline ermöglicht eine skalierbare Ausführung und bildet somit das Herzstück der Leistungsfähigkeit. Anstatt Szenarien nacheinander auf einem Rechner auszuführen, wird die Arbeit parallel auf viele Instanzen verteilt und lässt sich entsprechend der Anzahl der verfügbaren CarMaker-Lizenzen skalieren. Die Durchlaufzeit verkürzt sich dadurch von der Länge der gesamten Warteschlange auf etwa die Länge eines einzelnen Testlaufs.

Zwei weitere Ansätze machen die Entwicklungsumgebung zu einer echten Plattform und nicht nur zu einem isolierten Tool. Der erste ist die änderungsgesteuerte Regression. Da das gesamte System über Code definiert ist und über Pipelines gesteuert wird, können Funktions-, Modell- oder Szenarienänderungen automatisch die entsprechenden Simulationen triggern. Die Absicherung wird dadurch zu einem CI-Prozess – einem festen, automatisierten Bestandteil der Entwicklung – und ist kein manueller Schritt mehr, der nebenbei durchgeführt werden muss. Sobald sich etwas verändert erhalten Ingenieurteams eine schnelle, zuverlässige Rückmeldung.

Der zweite Ansatz Nachvollziehbarkeit. Das Prinzip ist einfach: Was nicht gemessen werden kann, lässt sich auch nicht skalieren. Das Frontend umfasst ein Amazon-natives CloudWatch-Dashboard, das in KPI-Bereiche für alle Simulationen unterteilt ist: Bremsverhalten, Überschlagverhalten sowie Fahrverhalten und Stabilität. Für eine umfassendere Betrachtung können KPI-Datensätze in Amazon QuickSight exportiert werden. Hier werden die Ergebnisse über S3 abgefragt, CSV-Datensätze zu Ausführung und Ergebnissen veröffentlicht und die zugehörigen Glue- und Athena-Tabellen automatisch erstellt. Kennzahlen wie die Anzahl der Testläufe pro Woche sind im Simulations-Workflow inkludiert, sodass Teams den Durchsatz überblicken, Engpässe erkennen und fundierte Entscheidungen darüber treffen können, wo eine Skalierung möglich ist.

Heute setzen Entwicklungsorganisationen nicht nur eine einzige, einheitliche Toolkette ein, und die vorgestellte Entwicklungsumgebung erfordert dies auch nicht. In dieser Umgebung bleibt CarMaker der Kern der Simulation, während die umgebenden Ebenen, mit beispielsweise Anwendungs- und Softwarecode, Modellen aus Tools wie Simulink oder modellbasierte Designs, CI/CD-Automatisierung und -Orchestrierung sowie Cloud-Betrieb auf AWS, je nach Team variieren können. Durch diese bewusste Trennung kann die Einführung schrittweise erfolgen, wodurch eine prozessstörende, disruptive Migration vermieden wird. Teams können in ihrem eigenen Tempo auf den Cloud-Workflow umsteigen und dabei weiterhin die speziellen Tools nutzen, die sie bereits anwenden.

Das hier vorgestellte Beispiel basiert auf zwei sich ergänzenden Nutzerrollen und kombiniert bewusst eine breite Palette von AWS-Diensten, um zu veranschaulichen, wie diese jeweils mit CarMaker interagieren können. Die Nutzerrolle der Cloud-Entwicklerin verfügt über Erfahrung in der Entwicklung von Cloud-Systemen und ist für die Umsetzung des vorgestellten Anwendungsbeispiels verantwortlich. Dabei stellt sie das Fundament und die Pipelines bereit und bringt die Umgebung auf AWS zum Laufen. Um das Beispiel zu implementieren, muss diese Person die betreffenden AWS-Dienste verstehen und wissen, wie sie miteinander verzahnt sind.

Dem gegenüber steht der CarMaker-Nutzer, der die Entwicklungsumgebung täglich anwendet. Dieser Ingenieur öffnet das Web-Frontend, um eine CarMaker-Sitzung remote zu starten oder eine große Menge an Szenarien zur parallelen Ausführung einzuchecken, ohne sich um die zugrunde liegende Infrastruktur kümmern zu müssen. Durch die Rollen-Trennung bleibt die Anwendung für den Simulationsingenieur einfach, während das Team insgesamt die volle Kontrolle darüber behält, wie Ressourcen erstellt und verwaltet werden.

Insgesamt veranschaulicht dieser beispielhafte Prozess, wie CarMaker als cloudnative, bedarfsorientierte Entwicklungsplattform funktionieren kann. Eine einzige Weboberfläche steuert vier automatisierte Pipelines, die das Frontend aufbauen, versionierte Umgebungen generieren, interaktive Remote-Sitzungen starten und parallele Batch-Simulationen im großen Stil ausführen – alles über Code definiert und nur wenn nötig bereitgestellt. Änderungsgesteuerte Regression und integrierte Nachvollziehbarkeit machen die Simulation zu einem messbaren und durchgängigen Bestandteil des Entwicklungsprozesses. Das Konzept zeigt, dass sich intensive ADAS-Validierung mit AWS flexibel skalieren lässt und dabei reproduzierbar, messbar und verwaltbar bleibt. Dadurch wird die Skalierungsgrenze überwunden, die das herkömmliche Arbeitsplatz-Modell einschränkt.

Zwei Hinweise sind zu beachten. Erstens handelt es sich hierbei um ein Anwendungsbeispiel und nicht um ein fertiges Produkt. Es dient dazu, die Konzepte zu veranschaulichen und die beteiligten AWS-Dienste vorzustellen. Teams sollten ihre eigene Implementierung vor dem Einsatz in der Produktion entwickeln und optimieren. Zweitens ist das Beispiel auf IPGLock für die elektronische Lizenzverwaltung von CarMaker angewiesen, das innerhalb der Ziel-VPC eingerichtet und ausgeführt werden muss. Dabei ist für jede ausgeführte CarMaker-Instanz eine Lizenz erforderlich, egal ob sie interaktiv oder im parallelen Batch-Betrieb läuft.

Wenn Sie sich für Cloud-Lösungen interessieren, lohnt es sich auch die VIRTO zu entdecken.