Elektroniknet Logo

Einsatz von modellbasierten Entwicklungswerkzeugen

FlexRay-Projekte leicht gemacht


Fortsetzung des Artikels von Teil 1

Restbussimulation

Die Restbussimulation ist eine Methode zum Test eines vernetzten Systems, das nur teilweise real vorliegt. Fehlende Busteilnehmer (der Restbus) werden auf einem Simulator virtuell nachgebildet. Hierzu werden Ersatzmodelle verwendet, deren Resultate vom Simulator an die realen Knoten verschickt werden. Grundlage der Restbussimulation ist eine vorliegende Kommunikationsmatrix.

Je nach Testvorhaben kommen verschiedene Varianten dieser Methode zum Einsatz, beispielsweise eine statische oder dynamische Restbussimulation. Bezogen auf den Inhalt von Botschaften wird unter statischer Restbussimulation das Erzeugen von synthetischen Botschaften unabhängig von der simulierten Umgebung verstanden. Dieses kann angewendet werden, wenn ein reales Steuergerät den Inhalt der empfangenen Botschaften nicht auf Plausibilität prüft. Bei der Restbussimulation müssen hier bereits das korrekte Zeitverhalten sowie ggf. interne Prüfmechanismen (z.B. Alive-Counter, Prüfsummen) berücksichtigt werden. Im dynamischen Fall, d.h. für Steuergeräte-Funktionen mit Plausibilitäts-Checks, müssen die Botschaftssignale jedoch mit aktuellen Werten aus dem Echtzeit-Modell (z.B. in MATLAB/Simulink) versehen werden.

Dynamische Restbussimulation meint gelegentlich auch, dass ein vorliegendes Ersatzmodell nachträglich um weitere Signale aus der Kommunikationsmatrix ergänzt werden kann. Dies erfordert jedoch eine Rekonfiguration der Controller in der Restbussimulation. Ein Werkzeug mit schnellen Reaktionszeiten erlaubt jedoch, weitere Signale effizient zu berücksichtigen.

Modellgenerierung

Die Simulink-Konfigurationsdatei enthält Angaben über die im Konfigurationswerkzeug selektierten Signale und Frames. Für diese Elemente werden in einem Generierungsschritt zugeordnete Blöcke aus dem Blockset in ein Simulink-Modell übernommen und parametriert. Die Kom-munikations-Blöcke werden so gruppiert, dass die Zuordnung zu den ECUs erhalten bleibt (Bild 3). Letztlich wird auf diese Weise eine signalbasierte Block-Schnittstelle (unter Simulink) geschaffen. Diese kann von einem Anwender herangezogen werden, um ein Regler- bzw. Restbusmodell zu ergänzen. Zum Umfang des generierten Modells gehören ferner Blöcke für die verwendeten FlexRay-Controller, die Tasks und die Synchronisationseinstellungen. Speziell für die dynamischen Frames werden noch Trigger-Blöcke bereitgestellt, mit denen das Versenden dieser Frames angestoßen werden kann. Basisfunktionen wie die Abfrage des Controller-Status, die Behandlung von Controller-Interrupts, die Möglichkeit zum Controller-Reset und Fehlerbehandlungsroutinen für den Kommunikations-Code runden den Leistungsumfangs des Blocksets ab.

Für die dSPACE-Hardware wird ein spezieller Service generiert, der eine Synchronisation der Zyklen für die Buskommunikation und die Task-Aktivierung bietet. Zeitliche Abweichungen, insbesondere in der Initialisierungsphase, können hart (abrupt) oder weich (inkrementell) korrigiert werden.

Schließlich ist auch auf die Unterstützung des „Network Managements“ (NM) nach den Vorgaben von AUTOSAR hinzuweisen. Sind in einer Netzwerkbeschreibung derartige NM-Frames spezifiziert, so können diese von einer dSPACE-Hardware empfangen und gesendet werden. Nach Auswahl von NM-Frames im Konfigurationswerkzeug werden automatisch Blöcke unter Simulink angelegt, mit denen die definierten NM-Signale verarbeitet werden können. Auch die zeitlichen Anforderungen der NM-Frames sind im Rahmen der FlexRay-Unterstützung von dSPACE berücksichtigt.

64ah0803.jpg
Bild 3. Generiertes Beispielmodell. Die Simulink-Blöcke für statische Signale der ausgewählten ECU sind hervorgehoben.

Auf dSPACE-Hardware abgestimmt

Damit sind alle Vorraussetzungen für eine einfache und effiziente Modellierung unter MATLAB/Simulink geschaffen. Dazu trägt auch der „one click“-Build-Prozess mit einer automatischen Code-Generierung und Code-Integration bis zum fertig ausführbaren Programm für die Echtzeit-Hardware bei.
Das Werkzeugangebot von dSPACE befindet sich derzeit in der Einführungsphase für den Aufbau von Testplätzen für FlexRay-Steuergeräte. Hier liegt das Hauptaugenmerk auf der hochwertigen Unterstützung für die Restbussimulation. Anschließend erfolgt die Konsolidierung der vorgestellten Leistungsmerkmale, um die übrigen Einsatzszenarien vollständig zu erschließen.

Autoren

Dipl.-Inform. Joachim Stroop

ist seit 2001 Produktmanager für „System and Function Design Tools“ und in dieser Position verantwortlich für FlexRay-Produkte bei der dSPACE GmbH.
jstroop@dspace.de

stroop-joachim.jpg

Dr. Ralf Stolpe

arbeitet seit 2000 bei dSPACE und ist Gruppenleiter für Multiprozessor- und verteilte Systeme. Er ist verantwortlich für die Entwicklung von Werkzeugen für FlexRay.
rstolpe@dspace.de

stolpe-ralf.jpg

  1. FlexRay-Projekte leicht gemacht
  2. Restbussimulation
  3. Konfigurieren Schritt für Schritt