Eine der zentralen Herausforderungen in der Softwareentwicklung für automobile Steuergeräte ist sowohl die zunehmende Komplexität von Hard- und Software, als auch die der umgebenden Systeme. Moderne Fahrzeuge enthalten Dutzende bis Hunderte von Electronic Control Units (ECUs), die über Bussysteme wie CAN, LIN, FlexRay und Ethernet miteinander vernetzt sind und hochkomplexe Regelalgorithmen ausführen.
Insbesondere im Kontext des automatisierten Fahrens wird deutlich, dass die schiere Anzahl notwendiger Tests nicht mehr allein durch reale Testfahrten oder Hardware-in-the-Loop-(HiL)-Systeme bewältigt werden kann. Die Validierung durch „virtuelle Tests“ wird daher zunehmend zur unverzichtbaren Ergänzung klassischer Testmethoden. Durch die Einführung von virtuellen Steuergeräten ist es möglich, Steuergeräte-Software früher und intensiver zu testen, dadurch die Softwarequalität zu erhöhen und Sicherheitsrisiken bereits in einem frühen Stadium der Entwicklung zu identifizieren.
Ein virtuelles Steuergerät (vECU) ist ein Artefakt, das alle Softwarekomponenten enthält, um die wesentlichen Aspekte eines realen Steuergerätes zu simulieren. Die Software benötigt keine Steuergeräte-Hardware, sondern wird auf einer PC-basierten Simulationsplattform ausgeführt.
Präziser gefasst gilt: Ein vECU besteht aus C-Code, der entweder aus einem Regler-Modell generiert wurde, als Produktionscode aus der ECU-Softwareentwicklung stammt oder als vorab kompilierter Binärcode vorliegt. Es wird typischerweise zum Testen der ECU-Software eingesetzt – in diesem Fall ist das vECU das „System under Test“ (SUT). Daneben kann ein vECU auch zur Inputgenerierung für andere Steuergeräte eingesetzt werden, also als realistische Restbussimulation. So lässt sich bereits integrierte Software testen, bevor die Zielhardware verfügbar ist.
Da große Teile der Software im vECU bereits als Produktionscode vorliegen, ist deren spätere Überführung auf das reale ECU einfach zu realisieren. Virtuelle Steuergeräte lassen sich zudem leicht durch den Einsatz von Rechenleistung skalieren und beispielsweise in der Cloud ausführen – ein entscheidender Vorteil gegenüber physischen Testaufbauten.
Je nach Anwendung können vECUs mit verschiedener Realitätsnähe und damit einhergehender Komplexität zum Einsatz kommen. Eine Klassifizierungsmethode nach prostep ivip reicht von Level 0 bis Level 4:
Level 0 – Controller Model: Das einfachste vECU enthält nur das Regler-Modell selbst (z.B. als MATLAB/Simulink-Modell) oder den daraus generierten C-Code (z.B. als FMU). Es enthält keinen Produktionscode und keine Teile der Basissoftware. Dieser Typ eignet sich ausschließlich für Tests des Regelalgorithmus selbst.
Level 1 – Application Level: Das Level-1-vECU enthält den Produktionscode der Applikationssoftware. Die Softwarekomponenten werden durch spezifisch für das vECU erstellte Funktionen niedrigerer Schichten ergänzt (z.B. RTE und Betriebssystem in AUTOSAR). Das vECU kommuniziert auf Signalebene, ohne Bus- oder Netzwerkkommunikation. Es eignet sich für Tests von Applikationsfunktionalitäten über mehrere Komponenten hinweg.
Level 2 – Simulation BSW: Level-2-vECUs bieten zusätzlich simulierte Basissoftware-Funktionalitäten (BSW), die eigens für Simulationszwecke erstellt werden – etwa einen COM-Stack, NVRAM-Funktionalität oder Diagnosefunktionen. Im Gegensatz zu Level 1 können Level-2-vECUs auf Bus- oder Netzwerkebene kommunizieren (z.B. über simuliertes CAN oder Ethernet).
Level 3 – Production BSW: Level-3-vECUs enthalten neben dem Produktionscode der Applikation auch Produktionscode der Basissoftware. Sowohl Applikations- als auch Basissoftware müssen hardwareunabhängig sein. Im AUTOSAR-Kontext umfasst dies alles oberhalb des Microcontroller Abstraction Layer (MCAL), das Betriebssystem sowie hardwareunabhängige Teile komplexer Treiber. Dieser Level wird gegenwärtig am häufigsten eingesetzt.
Level 4 – Target Binary: Das Level-4-vECU enthält den für das reale Ziel-ECU kompilierten Produktionscode, einschließlich möglicher Hardwareabhängigkeiten. Zur Ausführung auf einer Simulationsplattform ist eine Befehlssatz-Simulation (Instruction Set Simulation) erforderlich. Für diesen vECU-Typ wird identischer Build-Prozess für Simulation und reales ECU genutzt – es sind keine Code-Änderungen erforderlich.
Um zu verstehen, was in einem vECU steckt, lohnt ein Blick auf das Schichtmodell eines realen ECUs. Am Beispiel der AUTOSAR Classic Platform gliedert sich die Software in folgende Schichten:
Die Applikationsschicht enthält den eigentlichen Regelalgorithmus und ist in den meisten Fällen das „System under Test“. Darunter liegt die Runtime Environment (RTE), die als Verbindungsschicht zwischen Applikation und Basissoftware fungiert und je nach Verteilung der Softwareteile auf verschiedene ECUs unterschiedlich generiert wird. Die Basissoftware (BSW) stellt Dienste für Buskommunikation, Speicher und Ein-/Ausgabe bereit. Hardwareabhängige Teile werden im Microcontroller Abstraction Layer (MCAL) gekapselt. Ist eine vollständige Entkopplung von Hardwareabhängigkeiten nicht möglich, kommen sogenannte Complex Drivers zum Einsatz, die Applikationssoftware direkt mit dem Mikrocontroller verbinden.
Für die Simulation müssen bestimmte Teile dieser Schichten ausgetauscht oder angepasst werden. So müssen etwa Hardwaretreiber für vECUs anders implementiert werden als die Treiber realer ECUs. Je nachdem, welche Schichten im vECU enthalten sind und in welcher Form (Produktionscode oder simulierte Ersatzimplementierung), ergibt sich das entsprechende vECU-Level.
Die Erstellung, Verwaltung und Inbetriebnahme von vECUs erfolgt mithilfe von Toolketten verschiedener Hersteller, wie z.B. dSPACE, Vector Informatik und Synopsys. Diese bieten Techniken zur Bussimulation (CAN, LIN, Ethernet), Unterstützung von AUTOSAR-Entwicklungen, Umgebungssimulation, Testautomatisierung und Continuous Integration. Die Tools lassen sich nahtlos in bestehende Werkzeugketten für die Steuergeräteentwicklung integrieren, sodass Tests auf derselben Plattform laufen und für das reale ECU wiederverwendet werden können. Auf der Standardisierungsseite spielen vor allem zwei Ansätze eine Rolle:
Das Functional Mock-up Interface (FMI) vereinfacht den Modellaustausch zwischen OEMs und Zulieferern über ein standardisiertes C-API. Ein FMU (Functional Mock-up Unit) ist eine komprimierte Datei mit XML-Beschreibung sowie Quellcode oder vorkompilierten Binaries. FMI ist gut geeignet für Level-0- und Level-1-vECUs. Für höhere Level stößt der Standard jedoch an Grenzen: Die aktuelle Version 2.0 unterstützt nur skalare Datentypen und bietet keine effiziente Möglichkeit zur Darstellung von Buskommunikation wie CAN, FlexRay oder Ethernet.
AUTOSAR standardisiert die Software-Architektur von ECUs und definiert eine klare Schnittstelle zwischen hardware-abhängigen und hardware-unabhängigen Codeteilen – insbesondere durch OS und MCAL. Diese Schnittstelle könnte als Basis für einen vECU-Standard dienen. AUTOSAR deckt dabei sowohl die Classic Platform als auch die Adaptive Platform (für dynamischere, zur Laufzeit konfigurierbare Architekturen) ab.
Der Einsatz von virtuellen Steuergeräten bietet messbare Vorteile entlang des gesamten Entwicklungsprozesses:
Frühe Fehlererkennung: Viele Softwarefehler, die bisher nur im Rahmen von HiL- und Fahrzeugtests sichtbar wurden, können bereits im Vorfeld identifiziert und korrigiert werden. Dies reduziert teure Spätfehler erheblich.
Skalierbarkeit: vECUs lassen sich durch den Einsatz zusätzlicher Rechenleistung leicht skalieren und in der Cloud ausführen – ideal für umfangreiche Regressionstests oder Lasttests.
Effizienz durch Wiederverwendung: Tests, die im SIL-Betrieb mit vECUs erstellt wurden, können in vielen Fällen direkt im späteren HiL-Betrieb mit dem realen ECU wiederverwendet werden.
Regulierungskonforme Archivierung: Ein vECU kann leicht archiviert und bei Bedarf wieder in Betrieb genommen werden – etwa um regulierungskonforme Tests nachzuweisen, beispielsweise nach ISO 26262 oder UN-ECE-Regularien.
Frühere Verfügbarkeit des Prüflings: Da kein reales ECU für die Tests benötigt wird, kann die Softwareentwicklung und -validierung unabhängig vom Hardwareliefertermin beginnen.
Virtuelle Steuergeräte sind kein Zukunftsthema mehr – sie sind heute ein entscheidender Bestandteil moderner, effizienter Steuergeräteentwicklung. Wer frühzeitig auf vECU-basierte Teststrategien setzt, profitiert von kürzeren Entwicklungszyklen, höherer Softwarequalität und einer robusteren Absicherung gegenüber regulatorischen Anforderungen.
Wenn Sie mehr über den möglichen Einsatz virtueller Steuergeräte in Ihrem Entwicklungsprozess erfahren möchten oder Beratung bei der Auswahl einer geeigneten Toolumgebung benötigen, stehen wir Ihnen gerne zur Verfügung. ITPower Solutions verfügt über langjährige Erfahrung im Bereich des Steuergerätetests, eine hohe Toolkompetenz bei führenden Anbietern und hilft Ihnen dabei, anspruchsvollste Testumgebungen zu realisieren und sicherheitskritische Tests effizient und regulierungskonform durchzuführen.
Ich bin Ihr vertrieblicher Ansprechpartner und berate Sie gerne zu allen Fragen rund um unsere Dienstleistungen und Produkte! Melden Sie sich oder vereinbaren Sie einfach einen Termin für ein kostenloses Beratungsgespräch.
Sebastian Stritz
E-Mail: sebastian.stritz@itpower.de
Telefon: +49 (0)30 6098501-17