Die Absicherung von Steuergerätecode durch eine Software-in-the-Loop (SIL)-Simulation ist im Automotive-Bereich heute fester Bestandteil der Steuergeräteentwicklung. Wurden vor einigen Jahren eher Teilsysteme getestet, gewinnt heute die Simulation des Gesamtsystems zunehmend an Bedeutung. Ein Grund dafür: die immer stärkere Vernetzung und die damit verbundenen Abhängigkeiten der Steuergeräte untereinander. Insbesondere für Original Equipment Manufacturer (OEMs) sind Gesamtsimulationen wichtig – Zulieferer stellen typischerweise die dafür benötigten virtuellen Steuergeräte (V-ECUs) bereit. Bei der Zusammenarbeit stellt sich OEMs in der Praxis häufig die Frage: Was muss ich tun, um vom Zulieferer die passende V-ECU für die Gesamtsimulation zu erhalten?
Die Lösung: Ein Standard für V-ECUs muss her
Beim Austausch einfacher V-ECUs in frühen Entwicklungsphasen schafft der Functional-Mock-up-Interface (FMI)-Standard Abhilfe – für komplexere V-ECUs, insbesondere solche mit Busanbindung, reicht dieser jedoch nicht aus. Um auch hier den effizienten Austausch zwischen den Partnern zu ermöglichen, wird in dem Projekt FMI Layered Standard Network Communication mit Hochdruck an einem neuen Standard gearbeitet. Die Vorteile für die Absicherung liegen auf der Hand:
- Geringere Integrationskosten durch bessere Interoperabilität von Tools und Testplattformen
- Effizientere Zusammenarbeit dank erheblich reduziertem Abstimmungsaufwand zwischen OEMs und Zulieferern
Lesen Sie hier alles zum aktuellen Entwicklungsstand des Standards und wie dSPACE ihn zukünftig unterstützen wird.
FMI 3.0 und das Layered-Standard-Konzept
Der FMI-Standard ist im Bereich der Simulationsmodelle bereits stark verbreitet und erleichtert die Zusammenarbeit zwischen OEMs und Zulieferern erheblich. In der Version 3.0 wurde durch die Ergänzung einiger Features die Basis dafür geschaffen, ihn künftig auch für komplexere V-ECUs einsetzen zu können, darunter:
- Die sogenannten Clock-Variablen, die das Auslösen von Events ermöglichen
- Terminals, mit denen sich Input/Output-Variablen gruppieren lassen
- Das Layered-Standard-Konzept
Letzteres erlaubt die Erweiterung des bestehenden FMI-Standards um neue Features, ohne dabei den ursprünglichen Standard zu ändern.
FMI Layered Standard Network Communication
Seit Mitte 2022 unterstützt dSPACE die Aktivitäten im Bereich FMI Layered Standard Network Communication maßgeblich und bringt seine langjährige Erfahrung im Bereich der Bussimulation mit ein. Stets im Fokus dabei: die Akzeptanz des neuen Standards durch alle Beteiligten, also OEMs, Zulieferer und Tool-Lieferanten.
Kürzlich hat das Projekt einen ersten wichtigen Meilenstein erreicht: das sogenannte „Alpha“-Release, die erste Version des Standards für die CAN-Bussimulation. Dieser Schritt war deshalb so wichtig, weil auf dieser Basis nun V-ECUs zwischen den Entwicklungspartnern ausgetauscht und getestet werden können. An weiteren Bussen wie LIN, Ethernet und FlexRay wird gearbeitet, so dass auch hier in Kürze erste Versionen zur Verfügung stehen.
Die Arbeitsergebnisse sind transparent und für jeden online einsehbar.
Für jede V-ECU die passende Schnittstelle
Eine Voraussetzung für die Akzeptanz eines Standards ist seine Anwendbarkeit für relevante Anwendungsfälle. Bei V-ECUs können diese sehr unterschiedlich ausfallen, typischerweise sind sie vom Level der V-ECU abhängig. Erfolgt eine Einteilung der V-ECU-Level von 0 bis 4 wie im prostep-ivip-Whitepaper Requirements for the Standardization of V-ECUs, so wird eine Busanbindung beispielsweise ab Level 2 relevant.
Während Level-0- und -1-V-ECUs auch bislang schon auf Basis von FMI erstellt und ausgetauscht werden konnten, wird ab Level 2 der neue Standard FMI Layered Standard Network Communication benötigt. Dabei gilt: Egal welche Art von V-ECUs mit Busanbindung erstellt oder ausgetauscht werden sollen – der neue Standard bietet zukünftig eine passende, standardisierte Schnittstelle.
Gut zu wissen
Das Level einer V-ECU gibt Auskunft über ihren Entwicklungsstand. Für die Simulation gilt dabei: Je weiter die Entwicklung der V-ECU fortgeschritten ist, desto mehr Details müssen berücksichtigt werden.
- Level 0 und 1: In frühen Phasen der Entwicklung steht die Absicherung einzelner Applikationskomponenten im Vordergrund. Die genaue Art der Übertragung von Signalen zwischen V-ECUs ist nebensächlich und meist noch nicht vollständig spezifiziert.
- Ab Level 2: Die Buskommunikation und die Integration der V-ECU in eine Gesamtsimulation gewinnen an Bedeutung. Ab hier muss Basissoftware für die Buskommunikation in die V-ECU integriert werden. Für die leichtere Integration und schnellere Erstellung der V-ECU wird in früheren Entwicklungsphasen meist eine vereinfachte Basissoftware eingesetzt, die nur das Communication (COM) Module umfasst.
- Level 3: Diese V-ECUs kommen dem realen Steuergerät sehr nah und unterscheiden sich im Idealfall nur durch die hardwareabhängigen Treibermodule. Sämtliche darüberliegende Basissoftware ist hier Teil des Testgegenstandes und wird daher vollständig in die V-ECU integriert.
Physical Signal Abstraction
Kommt bei Level-2-V-ECUs eine vereinfachte Basissoftware zum Einsatz, die nur das Communication (COM) Module umfasst, spricht man umgangssprachlich vom sogenannten „High Cut“, da nur die obere Schicht der Software in die V-ECU aufgenommen wird. Für die Erstellung derartiger V-ECUs sieht der FMI Layered Standard Network Communication die sogenannte Physical Signal Abstraction als Schnittstelle vor. Bei dieser Schnittstelle stehen die Übertragung der einzelnen Bussignale und der Zeitpunkt der Übertragung im Vordergrund.
Network Abstraction
Bei Level-3-V-ECUs wird in der Regel die gesamte Basissoftware oberhalb des Controller Area Network (CAN) Driver Modules in die V-ECU integriert. Der Schnitt in der Software erfolgt also sehr tief, üblicherweise in den hardwareabhängigen Treiber-Modulen, was als „Low Cut“ bezeichnet wird. Auch hierfür definiert der neue Layered-Standard mit der Network Abstraction eine passende Schnittstelle. Die Übertragung findet hier nicht auf Ebene der Bussignale, sondern auf Basis der zugehörigen Frames/PDUs (Protocol Data Units) statt.
Sein volles Potenzial entwickelt die Network Abstraction in Verbindung mit einer zusätzlichen Bussimulation. Diese erlaubt es, auch das Zeitverhalten und die Priorisierung von Busnachrichten sowie Fehlerzustände bei der Übertragung von Frames/PDUs mitzusimulieren. Die integrierte Basissoftware lässt sich so sehr realitätsnah testen.
Besonders komfortabel ist es hierbei für den Anwender, wenn die Simulationsplattform die Bussimulation als fest integriertes Feature direkt mitliefert. Hier kommt VEOS ins Spiel: Die dSPACE Plattform für PC-basierte Simulation bringt die benötigte Bussimulation bereits mit und erleichtert Anwendern den Aufbau des Simulationssystems damit erheblich.
Welche Schnittstelle ist die Richtige für meinen Anwendungsfall?
Eine Bussimulation auf Ebene der Physical Signal Abstraction eignet sich besonders in diesen Fällen:
- Level-2-V-ECUs in frühen Phasen
- Die weiteren Simulationssteilnehmer stellen Netzwerksignale ausschließlich in Form von physikalischen Signalen zur Verfügung.
- Ein Schnitt innerhalb der V-ECU auf Höhe des Communication (COM) Modules ist möglich und die Granularität der Simulation ist akzeptabel.
Bei einer Bussimulation auf Ebene der Network Abstraction werden Netzwerksignale auf Basis der zugehörigen Frames ausgetauscht. Ein Schnitt der Basissoftware kann somit ab der Ebene des PDU-Router (PduR)-Moduls bis hinunter zur Hardware-Ebene erfolgen. Diese Ebene eignet sich daher in folgenden Fällen:
- Level-2- und -3-V-ECUs, die Basissoftware unterhalb des COM-Modules enthalten
- Andere Simulationsteilnehmer, z. B. Restbusmodelle, stellen Busnachrichten auf Basis von Frames/PDUs bereit.
- Die Simulation des Busverhaltens ist gewünscht bzw. notwendig.
Erstellung und Simulation von V-ECUs mit dSPACE
Der neue Layered-Standard spielt auch bei dSPACE eine zentrale Rolle, insbesondere im Bereich der SIL-Simulation. Aktuell wird die Unterstützung des Standards durch dSPACE Tools schrittweise umgesetzt – zunächst für SystemDesk, das dSPACE Tool für die Generierung von V-ECUs, und für VEOS, die Plattform für PC-basierte Simulation.
Anwender, die bereits mit den Tools arbeiten, können diese in gewohnter Form weiter nutzen und sich über zusätzliche Features freuen:
SystemDesk
MCAL-Module für die Bustreiber lassen sich zukünftig auch in V-ECUs integrieren, wenn diese anschließend als FMU (*.fmu) exportiert werden sollen. Das war bislang nur bei V-ECUs in Zusammenhang mit dem dSPACE-eigenen *.vecu-Format möglich. Somit können V-ECUs auf Basis von FMI3 und der Network Abstraction des Layered-Standards erstellt werden.
VEOS
Die Simulationsplattform wird FMUs mit FMI Layered Standard Network Communication auf Basis der Network Abstraction beim Import automatisch erkennen. Bus Terminals zeigt VEOS dabei nicht als Variablen bzw. Ports, sondern wie gewohnt als Bus Controller an. Restbussimulationen in Form von Bus Simulation Container (BSC) können weiterhin direkt mit V-ECUs verbunden werden. Auch die Simulation des Busverhaltens wird VEOS wie gewohnt unterstützen.
Wie geht es weiter?
Mit dem Alpha-Release des Layered-Standards für CAN hat die FMI-Arbeitsgruppe einen ersten wichtigen Meilenstein erreicht. Neben der eigentlichen Spezifikation sind bereits erste Demos, eine C-API sowie eine HowTo-Dokumentation für die Erstellung von FMUs mit CAN-Bus verfügbar und öffentlich zugänglich. Aktuell werden Cross-Checks durchgeführt, um die Austauschbarkeit zwischen Toolherstellern sicherzustellen und letzte Unstimmigkeiten in der Spezifikation zu beseitigen.
Parallel arbeitet die Gruppe an der Spezifikation für weitere Busse wie FlexRay – für LIN liegt bereits ein erster Entwurf vor. Da die Grundprinzipien bei allen Bustypen gleich sind, kann die Arbeitsgruppe auf die Erkenntnisse aus der CAN-Spezifikation zurückgreifen, was den Prozess erheblich beschleunigt. Auch dSPACE wird sich hier weiterhin stark engagieren.
Was die dSPACE Tools betrifft, ist die Implementierung und Unterstützung des Layered-Standards in vollem Gange: SystemDesk und VEOS werden mit CAN den Anfang machen, weitere dSPACE Tools und auch die Unterstützung weiterer Busse werden folgen.
Über die Autoren
Markus Süvern
Team Lead, Production Software & SIL Simulation, dSPACE GmbH
Christian Becker
Product Manager, Production Software & SIL Simulation, dSPACE GmbH
