FlexRay-Projekte leicht gemacht Einsatz von modellbasierten Entwicklungswerkzeugen

Transkript

1 Sonderdruck aus Mai FlexRay-Projekte leicht gemacht Einsatz von modellbasierten Entwicklungswerkzeugen Mit den Erfahrungen aus ersten FlexRay-Projekten bietet dspace jetzt neue Entwicklungswerkzeuge für FlexRay an, die auf Standards ausgerichtet sind und sich nahtlos in bestehenden Umgebungen verwenden lassen. Ein Projektteam in der Automobilindustrie, das in diesen Tagen mit der Durchführung eines FlexRay-Projekts beauftragt wird, Von Joachim Stroop und Dr. Ralf Stolpe kann in der Regel auf ein langjähriges Methodenwissen zur Entwicklung von vernetzten Systemen zurückgreifen. Das arbeitsteilige Zusammenspiel von Herstellern und Zulieferern von der systemweiten Festlegung einer Kommunikationsmatrix über die Entwicklung und den Test von Komponenten bis hin zum Verbundtest der Steuergeräte ist auf der Grundlage des CAN-Protokolls gut eingeführt und durch Werkzeuge unterstützt. Zur Absicherung der Projektplanung für das FlexRay-Projekt muss jedoch auch auf die Besonderheiten eingegangen werden, die sich mit FlexRay

2 Systemsimulation IIII Bussysteme I Bild 1. Arbeitsablauf von einer Netzwerkbeschreibung hin zu einer Simulation auf einer dspace-hardware. ( als einem neuartigen Busprotokoll ergeben. Hier ist die zeitgesteuerte Aktivierung von Kommunikation und zugeordneten Anwendungen zu nennen, für die spezielle Entwicklungsmethoden notwendig sind. Zusätzlich müssen die vielfältigen Konfigurationsmöglichkeiten von FlexRay auf das vorliegende Projekt konkretisiert Und letztlich sind neben FlexRay noch weitere neue Standards zu berücksichtigen, hier insbesondere FIBEX ( und auch AUTOSAR ( org). Idealerweise sollten daher Entwicklungswerkzeuge zur Projektunterstützung herangezogen werden, die sich bewährt haben und zugleich auf die Besonderheiten von FlexRay abgestimmt sind. Sie sollten ferner einen hohen Bedienkomfort aufweisen, der eine Konzentration auf die eigentliche Entwicklungsaufgabe ermöglicht und die Komplexität von FlexRay so weit wie möglich abschirmt. Diese Herausforderung beantwortet dspace mit einem überarbeiteten Werkzeugangebot aus einer Hand als integraler Bestandteil eines etablierten Werkzeugkonzepts. Die Einsatzszenarien und die Leistungsmerkmale werden im Folgenden dargestellt. Anwendungs-szenarien für die Simulation Das Werkzeugangebot von dspace zur Unterstützung von FlexRay ist auf unterschiedliche Anwendungsgebiete zugeschnitten. Dazu zählt das Rapid Control Prototyping (RCP) als Methode zur Entwicklung und Absicherung von Funktionsmodellen elektronischer Regler. Die Funktionsmodelle werden auf Prototyping-Systemen simuliert. Diese Systeme treten an die Stelle von neu zu entwickelnden oder zu modifizierenden Steuergeräten (Electronic Control Units ECUs). Als Ergebnis dieser Methode erhält man Aussagen über das funktionale Verhalten der Regler und über das zeitlich korrekte Zusammenspiel mit der Buskommunikation. Ein weiteres Anwendungsgebiet ist der Test eines ECU-Netzwerks im Rahmen einer Restbussimulation. Real vorhandene ECUs werden zusammen mit Ersatzmodellen für virtuell nachgebildete ECUs sowie von Umgebungsmodellen in einer Simulationsumgebung getestet. Es kann zwischen statischer und dynamischer Restbussimulation unterschieden Für beide Anwendungsgebiete kommen die Systeme von dspace zum Einsatz von der MicroAutoBox bis hin zu den verschiedenen Varianten der Hardware-in-the-Loop-Simulatoren. Diese Systeme sind mit Steckplätzen für IP-Module ausgestattet, die einen FlexRay-Kommunikations-Controller tragen. Die Modellierung erfolgt jeweils mit Hilfe von MAT- LAB/Simulink in Verbindung mit Real-Time Interface Blocksets von dspace, über die der Zugriff auf die angeschlossenen Bussysteme sowie auf weitere externe Peripherie erfolgt. Die Modelle werden in einer Simulation auf der Hardware ausgeführt. Modellausführung und Buszugriff erfolgen synchronisiert und unter Echtzeit- Bedingungen. Die Ergebnisse können in einer Experimentierumgebung visualisiert Die Anwendung der Software- Werkzeuge von dspace für FlexRay folgt der Methodologie, die innerhalb von AUTOSAR spezifiziert wird, hier jedoch angepasst für einen modellbasierten Ablauf (Bild 1). Für die Systemkonfiguration wird eine vollständig beschriebene Kommunikationsmatrix für einen FlexRay-Bus im FIBEX- Format als gegeben vorausgesetzt. Auf der Grundlage dieser Beschreibung erfolgt eine Konfiguration für jeweils eine dspace-hardware, d.h., es wird eine Auswahl von Signalen bzw. Frames für eine Simulation auf der Hardware getroffen. Diese Konfiguration wird automatisch in ein MAT- LAB/Simulink-Modell überführt, das schließlich mit dem eigentlichen Funktionsmodell verknüpft werden kann, um zu einer ausführbaren Simulation zu gelangen. Konfiguration und Generierung sind im dspace FlexRay Configuration Tool ( Konfigurationswerkzeug ) zusammengefasst (Bild 2). Dieses Werkzeug wird durch das RTI FlexRay Configuration Blockset ergänzt. Blöcke dieser Bibliothek werden auf der Grundlage der gewählten Konfiguration automatisch vorbelegt und stehen für eine applikationsspezifische Modellierung unter MATLAB/Simulink zur Verfügung.

3 I Bild 2. FlexRay Configuration Tool von dspace mit allen Darstellungs- und Konfigurationssichten. Konfigurieren Schritt für Schritt FIBEX-Import Das Konfigurationswerkzeug liest die Netzwerkbeschreibung aus einer FIBEX-Datei. Zusätzlich zur Validierung einer solchen Datei gegen das FIBEX-Schema werden Plausibilitätsprüfungen durchgeführt, die sicherstellen, dass später auf Basis der importierten Daten Code generiert werden kann. Nicht relevante Angaben werden ignoriert. Die Struktur der Netzwerkbeschreibung wird in einer Baumdarstellung angezeigt. Parameter zu ausgewählten Elementen werden in einer weiteren tabellarischen Ansicht visualisiert. Verschiedene Filter und Darstellungsoptionen sowie Suchmasken erleichtern den Umgang auch mit sehr großen Beschreibungen. Signal- und Frame-Auswahl Durch Markieren von Elementen aus der Baumdarstellung erfolgt eine Auswahl von Signalen und Frames, für die später Blöcke aus dem RTI FlexRay Configuration Blockset erstellt Die gewählten Objekte sind somit in der Simulation verwendbar. Je nach Einsatzszenario bietet es sich an, eine Selektion auf unterschiedlichen Ebenen vorzunehmen, wobei beliebige Kombinationen unterstützt Für das Rapid Control Prototyping kann es ausreichen, nur einzelne Signale bzw. Frames zu berücksichtigen, die zur Modellierung und Simulation eines Reglers notwendig sind. Im Rahmen einer Restbussimulation wird man eher ganze ECU- Einträge selektieren und damit alle zugeordneten Signale bzw. Frames aufnehmen. Um die Bedienung zu vereinfachen, können alle Frames, die an eine reale ECU gesendet werden sollen, automatisch identifiziert und für eine Simulation konfiguriert Es können sowohl Sende- als auch Empfangs-Frames verwendet Die dspace-hardware wird durch das Werkzeug zu einem vollwertigen aktiven Teilnehmer an einem FlexRay- Bus. Oft reicht es jedoch, Signale und Frames lediglich zu lesen. Dafür ist eine spezielle Monitoring-Ansicht vor- 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 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 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 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.

4 Bussysteme IIII Systemsimulation gesehen, in der die ausgewählten Objekte gesammelt Task-Konfiguration Um eine Synchronisation mit der zeitgesteuerten Übertragung von Frames auf dem Bus zu erzielen, kann die Simulation auf der dspace-hardware ebenfalls nach einem zeitgesteuerten Schema durchgeführt Das schließt eigenständige Kommunikationsroutinen ein, die als Sende- bzw. Empfangs-Tasks für die Verarbeitung der FlexRay-Frames angelegt Eine Sende-Task packt Signale in Frames und kopiert diese in den Puffer eines FlexRay- Controllers. Eine Empfangs-Task implementiert den umgekehrten Signalpfad. Die Aktivierungszeitpunkte dieser Tasks sind an die Kommunikationszeitpunkte der zugeordneten Frames gebunden, die durch Festlegungen zum Base Cycle, zur Cycle Repetition und zum Offset im Detail spezifiziert Zur Vereinfachung bietet das Konfigurationswerkzeug eine automatische Erzeugung und Konfiguration von Kommunikations-Tasks auf der Grundlage einer vorgenommenen Auswahl von Signalen und Frames an. Dieser Ansatz erfordert nur einen einzigen Mausklick und ist immer dann geeignet, wenn die Anforderungen an die zeitliche Synchronisation weniger anspruchsvoll sind, beispielsweise im Fall einer einfachen statischen Restbussimulation. Für weitergehende Einsatzszenarien können alle benötigten Angaben auch manuell erfolgen. Zur Unterstützung während der Eingabe werden Konsistenzprüfungen angeboten, die eine ungültige Konfiguration ausschließen. Beispielsweise wird verhindert, dass eine Kommunikations-Task aus der Simulation heraus auf einen Puffer des FlexRay-Controllers zugreift, während zeitgleich ein Datentransport für diesen Puffer auf dem Bus ausgeführt wird. Die Simulationsmodelle werden in so genannten Applikations-Tasks ausgeführt. Diese lassen sich ebenfalls nach den zuvor beschriebenen Mechanismen konfigurieren. Je nach Anforderung können sehr detaillierte Ausführungsmuster modelliert werden bis hin zum schnellen in cycle response. Darunter wird das Einlesen eines Frames als Eingabe für eine Berechnung und das Versenden von Resultaten auf Basis der neu berechneten Werte innerhalb eines Zyklus verstanden. Mit der Festlegung der Task-Konfiguration sind die Benutzereingaben abgeschlossen. Das Resultat kann als Projekt gespeichert und später wieder aufgerufen Es soll betont werden, dass es trotz der umfangreichen Leistungsmerkmale des Konfigurationswerkzeugs möglich ist, eine grundlegende Konfiguration mit wenigen Eingaben durchzuführen ebenso wie die anschließenden Generierungsschritte, auf die jetzt eingegangen wird. Kommunikations-Code I Bild 3. Generiertes Beispielmodell. Die Simulink-Blöcke für statische Signale der ausgewählten ECU sind hervorgehoben. Der FlexRay-Kommunikations-Stack auf der dspace-hardware wird anwendungsspezifisch generiert. Hierzu wird zum einen der Code zur Konfiguration eines FlexRay-Controllers (so genannter CHI Code ) erzeugt. Dabei handelt es sich um einen Satz von Registereinstellungen, die dem Controller das gewünschte Kommunikationsverhalten aufprägen. Zum anderen wird der eigentliche Code für die Kommunikations-Tasks generiert, der als Treiber für den Zugriff auf den Pufferspeicher des Controllers genutzt wird. Das Konfigurationswerkzeug minimiert automatisch die Anzahl der benötigten FlexRay-Controller. Im Allgemeinen werden die vorhandenen Controller einer dspace-hardware aufgefüllt, d.h., den Puffern werden Frames zugewiesen, bis sie vollständig belegt sind und ein weiterer Controller benötigt wird. Als Sonderfall ist das korrekte Startup- und Synchronisationsverhalten zu beachten. Das FlexRay- Protokoll sieht pro Zyklus nur einen Slot für einen Startup- bzw. für einen Synchronisations- Frame vor. Wenn im Rahmen einer Restbussimulation mehrere solcher Frames versendet werden sollen, so ist eine entsprechende Anzahl von FlexRay-Controllern notwendig. Blockset Beim RTI FlexRay Configuration Blockset handelt es sich um eine Bibliothek von Simulink-Blöcken. Eine Besonderheit dieser Bibliothek ist die Zweiteilung der Menge der Blöcke. Der eine Teil kann wie gewöhnlich von einem Anwender in ein Modell gezogen und manuell parametriert Bei dem anderen Teil erfolgt die-

5 Bussysteme IIII Systemsimulation ser Schritt automatisch auf der Grundlage einer generierten Konfigurationsdatei. 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 Kommunikations- 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 Reglerbzw. 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 Schließlich ist auch auf die Unterstützung des Network Managements (NM) nach den Vorgaben von AUTO- SAR hinzuweisen. Sind in einer Netzwerkbeschreibung derartige NM- Frames spezifiziert, so können diese von einer dspace-hardware empfangen und gesendet 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. 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 dspa- CE 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. jk 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. 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.

6 07/2006