Warum benötigt man eigentlich SiL-Tests und eine V-ECU? Fehlerhaftes Fahrzeugverhalten gefährdet Menschenleben, der Rückruf von Fahrzeugen kostet Geld und schadet dem Image. Bei immer stärker vernetzten Funktionen der Fahrzeuge ist es deshalb umso wichtiger, sie vor Auslieferung umfangreich zu testen. Die adaptive Geschwindigkeitsregelung (ACC) dient im Folgenden als vereinfachtes Beispiel, bei dem die Regelung unabhängig von der Streckenführung eine vorgegebene Geschwindigkeit halten soll. Dazu kommuniziert das ACC-Steuergerät über einen CAN-Bus mit dem Motorsteuergerät und gibt Motormomente vor. Kommt es nun zu einem Bremseingriff des Fahrers, sendet das Bremsensteuergerät die Bremsnachricht sowohl an das ACC- als auch an das Motorsteuergerät. Das ACC-Steuergerät schaltet die automatische Geschwindigkeitsregelung daraufhin aus.

Aufbau der beteiligten ECUs und eines vergleichbaren Software-in-the-Loop-Simulationssystems SiL für V-ECU

Bild 1a: Aufbau der beteiligten ECUs und eines vergleichbaren Software-in-the-Loop-Simulationssystems. dSPACE

Man kann sich nun folgende Fehlersituation vorstellen: Besteht während der Bremssituation eine Überlastung des CAN-Busses, empfängt das ACC-Steuergerät die Bremsnachricht nicht und sendet deshalb weiterhin Motormomentvorgaben an das Motorsteuergerät. Durch einen Software-Fehler im Motorsteuergerät wird weiterhin diese Vorgabe umgesetzt – der Motor beschleunigt gegen die Bremseinwirkung des Fahrers, und es kommt zu einer Gefahrensituation.

Fehler dieser Art lassen sich bereits im Rahmen einer SIL-Absicherung finden. Hierbei wird der Produktiv-Code der abzusichernden Funktionen ohne Verwendung von Hardware-Prototypen getestet. Zum Einsatz kommen Tests, wie sie auch im HiL-Betrieb (HiL: Hardware-in-the-Loop) von Prototyp-Steuergeräten Anwendung finden. Im Unterschied zu reinen Funktionstests einzelner Steuergeräte-Funktionen können im SIL-Betrieb auch Fehler gefunden werden, die erst durch die Vernetzung mehrerer Steuergeräte auftreten, wie es im Beispiel durch die Kombination von Busüberlast und fehlerhaftem Code auf dem Motorsteuergerät der Fall ist. Voraussetzung hierfür ist, dass die Steuergeräte-Software bereits vorliegt. In Form eines virtuellen Steuergeräts (V-ECU) kann sie dann als Testobjekt in unterschiedlich komplexen Tests dienen.

Bild 1a: Aufbau der beteiligten ECUs und eines vergleichbaren Software-in-the-Loop-Simulationssystems SiL V-ECU

Bild 1b: Aufbau der beteiligten ECUs und eines vergleichbaren Software-in-the-Loop-Simulationssystems. dSPACE

Will man exakt diesen Fehlerfall im SIL-Kontext nachstellen, kann man die Überlastung des Busses PC-basiert simulieren. Dafür ist jeweils die Software des Motor- und des ACC-Steuergeräts erforderlich, die als V-ECUs an der Simulation beteiligt sind. Beide müssen in der Lage sein, über einen virtuellen CAN-Bus miteinander zu kommunizieren. Außerdem muss eine Simulationsumgebung vorliegen, die sowohl die Ausführung der Steuergeräte-Software übernimmt, als auch das Verhalten des CAN-Busses simuliert (siehe Bild 1b).

In diesem Beispiel bestehen sowohl die V-ECU für das ACC als auch die V-ECU für das Motorsteuergerät aus mehreren Teilen. Zum einen enthalten sie den Code der Applikationsschicht, also die Implementierung der eigentlichen Funktion. Zum anderen enthalten sie Basissoftware wie insbesondere den COM-Stack, der die Übersetzung der signalbasierten Kommunikation in CAN-Nachrichten übernimmt. Beide Anteile werden mit einem Betriebssystem kombiniert, das für die Ausführung auf einem Simulator (im Gegensatz zur Zielplattform) gedacht ist.

Eckdaten

Wie muss eine zu testende virtuelle ECU (V-ECU) eigentlich aussehe, damit die Tests so realitätsnah wie möglich sind? Zur Beantwortung dieser Frage beleuchtet dSPACE exemplarische Einsatzgebiete von V-ECUs in der SIL-Absicherung. Daran wird deutlich, dass V-ECUs je nach Testziel unterschiedliche Inhalte und Detailgrade benötigen. Die Autoren klassifizieren solche Ausbaustufen und geben Anregungen, wie sich die eigenen Testziele in dieser Klassifikation verorten lassen.

Die Überlastung des CAN-Busses löst den eingangs genannten Fehler aus, aber die eigentliche Fehlerursache liegt im Motorsteuergerät. Daher ließe er sich auch finden, wenn die Anteile der Buskommunikation – also der COM-Stack und die Kommunikationsmatrix des Busnetzwerks – nicht in die V-ECU integriert werden. Die V-ECUs könnten auf Signalebene statt auf Busebene miteinander verbunden werden. In diesem Fall wäre es möglich, den Verlust des Signals des Bremsensteuergeräts direkt am ACC-Steuergerät einzuspeisen und so den Fehler im Motorsteuergerät zu provozieren. Dieser Testaufbau ist bereits mit V-ECUs möglich, die lediglich die relevanten Funktionalitäten der Applikationsschicht enthalten; ein COM-Stack ist hierfür nicht erforderlich.

Bereits an diesem Beispiel wird deutlich, dass Inhalte der V-ECU flexibel sind. Dabei hängt es stark vom eigentlichen Testfall ab, wie der Testaufbau aussieht und welche Komplexität einer V-ECU nötig oder sinnvoll ist, um bestimmte Fehlerfälle zu finden. Eine strukturierte Übersicht hilft hier bei der Entscheidungsfindung. Daher steht nun exemplarisch die Klassifizierung der Testziele an, um daraus abzuleiten, welche V-ECU-Inhalte nötig sind, um diese Ziele zu erreichen.

Testziele und V-ECU-Aufbau

Konkrete Testziele hängen insbesondere von der Phase des Entwicklungsprozesses ab, in der die Tests stattfinden sollen. SiL-Tests mit virtuellen Steuergeräten liegen inhaltlich zwischen MiL-Tests (Model-in-the-Loop), wie sie in der Funktionsentwicklung üblich sind, und späteren HiL-Tests mit prototypischen oder fertigen Steuergeräten.

MiL-Tests in der Funktionsentwicklung erfolgen oft auf Basis von Matlab/Simulink oder TargetLink. Hier sind sowohl Open- als auch Closed-Loop-Tests möglich, bei denen die Funktionsmodelle mit (einfachen) Umgebungsmodellen integriert werden. Bei einer MiL-Simulation wird noch kein Seriencode abgesichert, sondern lediglich das Funktionsmodell. Im Gegensatz dazu steht die SiL-Simulation. Hier ist der Testgegenstand der tatsächliche Seriencode der entwickelten Funktion, wie er später auf dem Steuergerät zum Einsatz kommen soll. SiL-Simulationen für den Seriencode einzelner Funktionen oder einzelner Autosar-Software-Komponenten sind beispielsweise bereits direkt mit TargetLink möglich. Auch auf einer Simulationsplattform wie dSPACE VEOS lassen sich solche V-ECUs ausführen, die lediglich einzelne Funktionen oder Autosar-Software-Komponenten enthalten. Vorteile dabei sind, dass die Simulation mit VEOS oftmals schneller ist und zudem sowohl andere Artefakte (etwa komplexere Umgebungsmodelle in Form von FMUs, Functional Mock-up Units) als auch bestehende Werkzeuge (etwa Experimentiersoftware oder bestehende Testskripte) wiederverwendet werden können.

Bild 2: Software-Schichten einer V-ECU. Applikationsschicht (hellblau), RTE (horizontaler Balken), Betriebssystem (vertikaler Balken) und weitere Basissoftware (blau: generiert, rot: Produktiv-Code) SiL.

Bild 2: Software-Schichten einer V-ECU. Applikationsschicht (hellblau), RTE (horizontaler Balken), Betriebssystem (vertikaler Balken) und weitere Basissoftware (blau: generiert, rot: Produktiv-Code). dSPACE

Erhöht sich die Komplexität der zu testenden Funktion, beispielsweise durch Kombination mehrerer Teilfunktionen oder Autosar-Software-Komponenten oder durch Vervollständigung der Applikationsschicht, kann ein virtuelles Steuergerät für die gesamte benötigte Funktionalität erzeugt werden. Im Fall von Autosar sind dafür nur der Code der Software-Komponenten sowie die Beschreibung der Komponenten selbst und ihrer Verschaltung (in Form einer ARXML-Datei) erforderlich. Daraus lassen sich automatisiert eine Laufzeitumgebung (Runtime Environment, RTE) und ein Autosar-Betriebssystem sowie gegebenenfalls weitere Basissoftware-Module zur Nutzung in der Simulation generieren.

Für Funktionen, die nicht nach Autosar entwickelt wurden, ist ein ähnliches Vorgehen möglich. Diese Art von V-ECUs kommuniziert nach außen auf Signalebene direkt aus der RTE. Die Signale können etwa mit Umgebungsmodellen oder anderen V-ECUs verbunden oder direkt zur Stimulation und Messung genutzt werden. Aufgrund der fehlenden Basissoftware ist hier keine Restbussimulation möglich. Diese V-ECUs können gut für einen relativ frühen Integrationstest der Applikationssoftware zum Einsatz kommen sowie für Testfälle, die über einzelne Komponenten hinausgehen, aber keine hohen Abhängigkeiten in die Basissoftware haben.

Weitere Tests mit der V-ECU

Wenn die Ingenieure mit der V-ECU weitergehende Tests durchführen wollen, etwa eine Restbussimulation wie im beschriebenen Beispiel oder realistische Diagnosetests, sind in der V-ECU Basissoftware-Anteile für die relevanten Funktionen erforderlich. Diese Anteile müssen nicht notwendigerweise als vollständige produktive Basissoftware vorliegen, sondern es können auch ausgewählte Module sein, die zum Zweck der virtuellen Absicherung generiert werden. In diesem Fall muss identifiziert werden, welche Basissoftware-Funktionalitäten in der V-ECU benötigt werden und wie sich die V-ECU am einfachsten erzeugen lässt. Hierfür können folgende Fragen als Leitlinie dienen:

  • Liegen die benötigten Basissoftware-Module als Seriencode vor oder sollen sie zum Zweck der Simulation generiert werden?
  • Falls Seriencode zum Einsatz kommen soll, wie hoch sind Abhängigkeiten in andere Module? Ist es möglich, relativ einfach einen Freischnitt der benötigten Module zu erzeugen?
  • Falls die Basissoftware-Module zum Zweck der Simulation generiert werden sollen, wie kann das möglichst aufwandsarm geschehen?

Für den letzten Fall lässt sich mit dSPACE SystemDesk beispielsweise die Konfiguration bestimmter Module automatisch aus der ARXML-Beschreibung der Applikationssoftware ableiten. Für einige Module bietet SystemDesk einen Codegenerator, der aus dieser Konfiguration Basissoftware-Code zum Zweck der virtuellen Absicherung generiert. Es kann auch ein Codegenerator eines beliebigen anderen Herstellers zum Einsatz kommen, um aus der manuell oder von SystemDesk erzeugten Konfiguration den Code für die benötigten Basissoftware-Module zu generieren. So unterstützt SystemDesk dabei, schnell und automatisiert zu einer V-ECU mit den benötigten Inhalten zu kommen.

V-ECU aus dem ECU-Code erzeugen

Schlussendlich ist es auch möglich, eine V-ECU aus dem fast vollständigen Steuergeräte-Code zu erzeugen. Das ist sinnvoll, wenn der Code schon vollständig vorliegt. Zu diesem Zeitpunkt können Tests am HiL erfolgen, jedoch sind zusätzliche reine Software-Tests oft empfehlenswert. Vorteile sind die schnelle Durchführung, Reproduzierbarkeit auf Entwickler-PCs samt der Möglichkeit des Debuggings sowie die bessere Skalierbarkeit etwa durch den Einsatz auf Cluster-Systemen oder in der Cloud, wo viele Tests parallel ausgeführt werden können. Für diese Art der V-ECUs gilt es, die hardwareabhängigen Anteile des Codes zu ersetzen, um die V-ECU auf einem PC-System ausführen zu können. In gängigen Software-Architekturen müssen die Verantwortlichen dafür die Treiber der Mikrocontroller-Abstraktionsschicht (Microcontroller Abstraction Layer, MCAL) und das Betriebssystem der Zielplattform entfernen und durch entsprechende MCAL-Module sowie ein Betriebssystem für die Simulationsplattform ersetzen.

V-ECUs dieser Art sind relativ einfach zu erzeugen, wenn die Autosar-Architektur eingehalten wird sowie oberhalb der MCAL-Schicht keine Hardwareabhängigkeiten im Code vorhanden sind und dabei gleichzeitig nicht viel Code als Complex Device Driver vorliegt oder dieser weggelassen oder auf andere Schnittstellen abgebildet werden kann.

Noch einen Schritt weiter geht die Instruction Set Simulation (ISS). Hier wird das fertige Kompilat für die Zielplattform – das fertige Steuergerät – genutzt und von einem Instruction Set Simulator ausgeführt. Hier werden die hardwareabhängigen Anteile beibehalten, da der Simulator auf der Ebene der Prozessorinstruktionen der zugrunde liegenden Prozessorarchitektur mit der V-ECU interagiert. Darüber lassen sich auch Tests abbilden, die von der Hardware abhängen.

Klassifizierung von V-ECUs SiL

Tabelle 1: Klassifizierung von V-ECUs. dSPACE

Um zu entscheiden, welche Inhalte eine V-ECU haben muss, spielen die Schnittstellen der anderen Bestandteile der Simulation ebenfalls eine Rolle, da diese Abhängigkeiten zu den Schnittstellen der V-ECU haben. Hat die V-ECU nur Schnittstellen auf Signalebene, kann sie nur auf dieser Ebene mit Umgebungsmodellen verbunden oder mit Stimuli versorgt werden. Zur Einspeisung aufgezeichneter Busdaten benötigt die V-ECU eine Busschnittstelle. Ähnlich verhält es sich mit Sensor- und I/O-Daten. Wird Basissoftware eingebunden, müssen die Daten im entsprechend erwarteten Format vorliegen, beispielsweise als Spannungswerte (in Volt) anstatt als Temperaturwerte.

Unterstützung

Ob und mit welchen Inhalten können V-ECUs den Ingenieuren helfen, und wie können sie einen weiteren Schritt zur virtuellen Absicherung mittels Software-in-the-Loop in Ihrer Prozesskette verankern? Welche Stakeholder, Werkzeugketten und Artefakte beteiligt sein müssen? Antworten darauf erhalten Interessenten in einem Gespräch mit dSPACE.

dSPACE bietet außerdem eine passende Werkzeugunterstützung bei der Erstellung und Simulation von V-ECUs. Mit SystemDesk können V-ECUs der verschiedenen Ausbaustufen erzeugt werden – sowohl für Autosar-Steuergeräte (Classic und Adaptive) als auch für nicht auf Autosar basierende Steuergeräte. SystemDesk bietet für die unterschiedlichen Inhaltsstufen dedizierte Unterstützung an, um die Erstellung der V-ECUs möglichst aufwandsarm zu gestalten.

Mit der Simulationsplattform dSPACE VEOS lassen sich diese V-ECUs auf dem PC zusammen mit Umgebungsmodellen simulieren, beispielsweise basierend auf Simulink oder dem FMI- Standard (Functional-Mock-up-Interface). VEOS läuft auf herkömmlichen Windows-Systemen und ist in der Lage, sowohl Steuergeräte-Software in Form von virtuellen Steuergeräten als auch Umgebungsmodelle zu simulieren. Zudem besteht die Möglichkeit, Bussysteme und ihr Verhalten (für CAN, CAN FD, LIN und Ethernet) sehr detailliert zu simulieren. Hierzu kommt die Simulation mit den üblichen Testautomatisierungs- und Experimentierwerkzeugen zum Einsatz, die auch an HiL-Prüfständen Anwendung finden, etwa über die standardisierten Testautomatisierungsschnittstellen der ASAM XIL.

Fazit

SiL-Absicherung nimmt im Test der Steuergeräte-Software eine immer größere Bedeutung ein – und dafür sind virtuelle Steuergeräte als Testobjekte erforderlich. Im Unterschied zu HiL-Tests ist ein rein virtuelles Steuergerät jedoch flexibel gestaltbar. Je nach Testziel und Phase des Entwicklungsprozesses besteht die Möglichkeit, virtuelle Steuergeräte auf unterschiedlichen Abstraktionsstufen und mit unterschiedlichen Inhalten zu erzeugen. Deshalb ist es wichtig, sich vorab über die Testziele und die dafür benötigten Artefakte klar zu werden. Die unterschiedlichen Klassifizierungen der V-ECUs bieten dabei eine Einstiegshilfe, um die Möglichkeiten und Randbedingungen besser einschätzen zu können.