Diese Seite wurde maschinell übersetzt.
Füllen Sie bitte eine 1-Minuten-Befragung zur Qualität dieser Übersetzung aus.
Entwicklung und Test von SOA-Anwendungen für Fahrzeugbetriebssysteme mithilfe von Model-Based Design
Von Wei Min, ZEEKR Intelligent Technology Holding Limited
„Wir verfeinern und erweitern unseren Workflow auf Basis von Model-Based Design mit MATLAB, Simulink, System Composer und Embedded Coder. Dieser Workflow hat seinen Wert bereits unter Beweis gestellt, indem er die Entwicklung beschleunigt und die Herausforderungen minimiert, die mit dem manuellen Schreiben von Code einhergehen.“
Die Automobilindustrie durchläuft einen tiefgreifenden Wandel, da sich Fahrzeuge von traditionellen mechanischen Systemen zu Software-Defined Vehicles (SDVs) weiterentwickeln. Dieser Wandel erfordert neue Ansätze in der Softwareentwicklung, wobei sich die serviceorientierte Architektur (SOA) als bevorzugtes Paradigma für die Entwicklung flexibler, skalierbarer Automobilanwendungen herauskristallisiert. Bei ZEEKR haben wir diesen Wandel aktiv mitgestaltet, indem wir einen umfassenden Workflow auf Basis des Model-Based Designs für die Entwicklung von SOA-Anwendungen etabliert haben, die auf unserem fahrzeuginternen Betriebssystem laufen.
Die traditionelle Entwicklung von Automobilsoftware mittels Model-Based Design konzentrierte sich hauptsächlich auf AUTOSAR® Classic-Plattformimplementierungen, bei denen Softwarekomponenten (SW-Cs) über standardisierte Laufzeitumgebungsschnittstellen (RTE) interagieren. Allerdings führt SOA neue Kommunikationsmuster wie Client-Server-Aufrufe und nachrichtenbasierte Interaktionen ein, was erhebliche Anpassungen der etablierten Entwicklungspraktiken erfordert. Die Herausforderung besteht nicht nur in der Modellierung dieser neuen Kommunikationsmuster, sondern auch in der Bewältigung der erhöhten Komplexität von Softwarearchitekturen in einer nicht für AUTOSAR standardisierten Umgebung.
Unsere Gruppe bei ZEEKR hat diese Herausforderungen mit einem Workflow auf Basis des Model-Based Designs für die SOA-Anwendungsentwicklung angegangen. Dieser Artikel beschreibt drei Schlüsselbereiche dieses Workflows:
- Modellierung des SOA-Verhaltens mithilfe der Client-Server-Schnittstellenfunktionen von Simulink®
- Wartung komplexer Softwarearchitekturen durch kundenspezifische Tools auf Basis von System Composer™
- Implementierung effektiver Verifizierungs- und Validierungsverfahren für SOA-Anwendungen
Unsere Erfahrung zeigt, wie Ingenieure mithilfe von Model-Based Design den Übergang von traditionellen eingebetteten Systemen zu modernen SOA-basierten Softwarearchitekturen für SDVs beschleunigen können.
Modellierung serviceorientierter Anwendungen in Simulink
SOA führt neue Kommunikationsmuster ein, die sich grundlegend von denen traditioneller eingebetteter Systeme unterscheiden. Klassische AUTOSAR-Anwendungen kommunizieren über einfache RTE-Schnittstellen, die eng gekoppelte, statisch definierte Interaktionen zwischen Softwarekomponenten ermöglichen. Im Gegensatz dazu sind SOA-Kommunikationsmuster – wie etwa Remote Procedure Calls und nachrichtenbasierte Interaktionen – flexibler und ausgefeilter. Sie ermöglichen außerdem die Entkopplung von Hardware und Software sowie dem hierarchischen Entwurf von Software. Um diese Muster optimal zu nutzen, verfolgen wir einen Entwicklungs-Workflow, der auf Model-Based Design basiert und die Modellierung der SOA-Anwendungen in Simulink sowie die Generierung von C++ Code mit Embedded Coder®, Erstellung von Middleware-Integrationscode mit einem von uns entwickelten Wrapper-Generator und Zusammenführung von Anwendungs- und Integrationscode zu bereitstellbaren Anwendungspaketen umfasst. Dieser automatisierte Workflow benötigt keinen handgeschriebenen C++ Code. Der automatisch generierte Wrapper-Code verbindet den Anwendungscode, den wir aus unseren Simulink-Modellen generiert haben, mit der Laufzeitumgebung ZEEKR ARK OS.
Ein typisches SOA-Modell in unserem Workflow umfasst Serviceanbieter und Clients, die beide in Simulink modelliert werden (Abbildung 1). Diese Struktur erfasst wesentliche SOA-Verhaltensweisen: entkoppelte Serviceaufrufe, expliziter Nachrichtenaustausch und eine klare Trennung zwischen Kommunikation und Berechnung. Es ermöglicht uns, SOA-Konzepte in Simulink klar auszudrücken und diese Modelle für den Einsatz in einer verteilten, serviceorientierten Umgebung vorzubereiten.
Abbildung 1. Ein einfacher Client und Server, modelliert in Simulink. Der Client umfasst einen Empfängerblock, der periodisch durch ein Steuersignal („Step“) ausgelöst wird, und einen Senderblock.
Unsere Einsatzszenarien umfassen sowohl zentrale als auch verteilte Rechenumgebungen (Abbildung 2). Die in Simulink modellierten serviceorientierten Anwendungen laufen auf einer zentralen Hochleistungsrecheneinheit. Die klassischen AUTOSAR-Komponenten – ebenfalls in Simulink entwickelt – werden hingegen auf einem Mikrocontroller ausgeführt und interagieren direkt mit den Fahrzeugaktuatoren. Diese gemischte Bereitstellung spiegelt den breiteren Trend hin zu zentralisierten Domänenarchitekturen wider, bei denen Domänencontroller die Verarbeitung auf hoher Ebene übernehmen, während Edge-Knoten die Steuerung auf niedriger Ebene durchführen. Mit Simulink können wir beide Aspekte dieser Architektur unterstützen, indem wir eine einheitliche Entwicklungsumgebung nutzen, um heterogene Automobilsysteme zu modellieren, zu simulieren und Code zu generieren.
Abbildung 2. Eine in Simulink entwickelte, praxisnahe Klimaanlagenanwendung, die eine auf einem zentralen Prozessorknoten bereitgestellte SOA-Software mit einem auf einem Mikrocontroller laufenden AUTOSAR Classic SW-C zur Ansteuerung des Aktuators kombiniert.
Verwaltung komplexer Softwarearchitekturen mit System Composer
Mit zunehmendem Umfang und steigender Komplexität serviceorientierter Anwendungen wird die Verwaltung ihrer Struktur zu einer entscheidenden Herausforderung. Da mehrere Dienste über mehrere Softwareeinheiten hinweg interagieren, reicht es nicht mehr aus, jedes Modell isoliert zu betrachten. Stattdessen benötigen wir eine klare architektonische Darstellung, wie Softwarekomponenten zueinander in Beziehung stehen, einschließlich ihrer Gruppierung, ihrer Kommunikation und ihres Einsatzortes. Viele kommerziell erhältliche Softwarearchitektur-Tools für die Automobilindustrie, einschließlich AUTOSAR-Autorentools, setzen oft eine AUTOSAR-basierte Umgebung voraus und unterstützen nicht die Flexibilität, servicebasierte Kommunikationsmodelle für kundenspezifische Betriebssysteme einzusetzen. Um den Anforderungen unseres SOA-Frameworks und des fahrzeuginternen Betriebssystems gerecht zu werden, haben wir unsere eigene Architekturmodellierungsumgebung entwickelt. SOA Model Composer – oder SOMOC – baut auf den modellbasierten Systementwicklungsfunktionen und Architekturelementen von System Composer sowie den objektorientierten Programmierfunktionen von MATLAB® auf. Zur Vereinfachung der Bedienung haben wir eine benutzerdefinierte Benutzeroberfläche mit MATLAB und App Designer erstellt (Abbildung 3).
Abbildung 3. Die SOMOC-Benutzeroberfläche, einschließlich der Architekturbaumansicht (links) und der Komponenten-Composer-Oberfläche (rechts).
SOMOC unterstützt einen strukturierten Ansatz zur Definition und Verwaltung von SOAs auf vier Schlüsselebenen: Systemarchitektur, Prozess, Softwarekomponente und Servicedefinition (Abbildung 4). Diese hierarchische Organisation nutzt die Referenzkomponentenfunktionen von System Composer, um eine klare Rückverfolgbarkeit von übergeordneten Systemen bis hin zu einzelnen Diensten herzustellen.
Abbildung 4. Komponentenhierarchie in SOMOC, die Architektur-, Prozess-, Software- und Serviceebenen aufzeigt.
SOMOC erweitert die Architekturmodelle um benutzerdefinierte Profile und Stereotypen, die SOA-spezifische Metadaten wie Dienstkennungen, Namensräume und Versionsinformationen erfassen. Die Systemarchitekten von ZEEKR verwenden SOMOC, um funktionale Anforderungen (importiert aus während des Systemdesigns generierten ARXML-Dateien) in einsetzbare Architekturen zu übersetzen, indem sie Prozessgrenzen, Serviceschnittstellen und Softwarekomponenten definieren. Aus diesen Architekturmodellen generiert SOMOC automatisch Simulink-Shellmodelle mit konsistenten Schnittstellen und bietet Entwicklern so einen zuverlässigen Ausgangspunkt für die Implementierung interner Verhaltensweisen oder Logik (Abbildung 5). Diese Automatisierung standardisiert den Workflow von der Architektur bis zur Implementierung, hält die Schnittstellen synchronisiert und bietet unseren Teams während der gesamten Entwicklung einen gemeinsamen Bezugspunkt.
Abbildung 5. Im Rahmen des SOMOC-Frameworks werden verschiedene Schichten entworfen und getestet.
Multilevel-Tests für SOA-Anwendungen
Bei ZEEKR validieren wir unsere serviceorientierten Anwendungen durch eine Kombination aus Modell- und Code-Level-Tests. Wir beginnen mit Unit- und Modelltests in Simulink mit Simulink Test™, wobei wir Test-Harnische verwenden, um einzelne Komponenten zu isolieren und Service-Interaktionen zu überprüfen (Abbildung 6). Für jedes Modell können die Ingenieure die Kommunikation mit entsprechenden Komponenten simulieren – beispielsweise mit einem simulierten Provider für ein Consumer-Modell – und die erwarteten Reaktionen und das Schnittstellenverhalten überprüfen. Diese Validierung in der frühen Phase hilft dabei, Logikfehler oder Schnittstelleninkompatibilitäten zu erkennen, bevor Code generiert wird.
Abbildung 6. Die Testsequenz eines Testsystems, die im Testsequenz-Editor angezeigt wird.
Nach der Generierung des Anwendungscodes und dessen Integration in unser Fahrzeugbetriebssystem führen wir Laufzeittests mit unserem Service Verification Toolkit (SVT) durch, einem schlanken Plugin innerhalb von Visual Studio Code (Abbildung 7). SVT ermöglicht es Teams, Service-Schnittstellendefinitionen aus ARXML-Dateien zu importieren und anschließend sowohl Methoden- als auch Themenschnittstellen zu testen, indem die Servicekommunikation auf Anwendungsebene simuliert wird. Es kann entweder als Konsument oder als Anbieter fungieren – Methodenanfragen senden, Antworten verarbeiten, Themendaten veröffentlichen oder Nachrichten abonnieren. SVT zeigt die über die Serviceschnittstellen ausgetauschten Werte an und hilft Ingenieuren so zu bestätigen, dass sich die bereitgestellte Anwendung in verschiedenen Interaktionsszenarien korrekt verhält.
Abbildung 7. Das SVT-Plugin in Visual Studio Code.
Ausblick
Während wir weiterhin neue serviceorientierte Anwendungen für unseren Fahrzeugeinsatz entwickeln, verfeinern und erweitern wir auch unseren Workflow auf Basis des Model-Based Designs mit MATLAB, Simulink, System Composer und Embedded Coder. Dieser Workflow hat seinen Wert bereits unter Beweis gestellt, indem er die Entwicklung beschleunigt und die Herausforderungen minimiert, die mit dem manuellen Schreiben von Code einhergehen. Mit der Möglichkeit, die Architekturmodellierung, Servicemodellierung, Simulation, Codegenerierung und Tests von serviceorientierten und AUTOSAR-basierten Anwendungen in einer einzigen Umgebung durchzuführen, verfügen wir über eine skalierbare Softwaregrundlage zur Unterstützung der SDV-Entwicklung, die die Automobillandschaft weiterhin grundlegend verändert.
Veröffentlicht 2025
