Steuergeräteprogrammierung

Transkript

1 50lA UTOMOTIVE Steuergeräteprogrammierung mittels Model Based Design Die IAV kann im Bereich Prototyping und Vorentwicklung in der Fahrzeugelektronik bereits auf eine mehr als zehnjährige Erfahrung zurückblicken. Um Kundenanforderungen gerecht zu werden, müssen im Bereich Fahrzeugelektronik zunehmend komplexere Systeme in immer kürzeren Zeitabständen in ein Fahrzeug integriert werden. Um auf der Grundlage von fertigen Lösungen sehr schnell mit automotive-tauglichen Steuergeräten ins Fahrzeug zu kommen, hat die IAV die modulare Steuergerätereihe UCU (Universal Control Unit) entwickelt. Je nach Projektanforderung und Anwendung können drei verschiedene Basisboards mit drei CPU-Modulen und unterschiedlicher Rechenleistung kombiniert werden. Die IAV UCUs werden sowohl bei Prototypen als auch für die Funktionsentwicklung von Seriensoftware (A-Muster Steuergeräte) eingesetzt. Bei diesen Anwendungen ist es Um neue Ideen möglichst schnell auf einem fahrzeugtauglichen Steuergerät seriennah umzusetzen, nutzt die Firma IAV Model Based Design auf der Basis von MATLAB und Simulink sowie die automatische Code-Generierung aus Simulink mit den eigenen Universalsteuergeräten. Welche Vorteile sich dabei ergeben, zeigt dieser Beitrag. wichtig, neue Ideen möglichst schnell auf einem fahrzeugtauglichen Steuergerät seriennah umzusetzen. Dies erfolgt mittels Model Based Design sowie der Automatischen Code-Generierung aus Simulink. Diese durchgängige Entwicklungsplattform verleiht die nötige Flexibilität bis in die Schlussphase der Projekte. Die Wiederverwendbarkeit ausgetesteter Softwaremodule ermöglicht es zudem, sich sehr schnell auf die eigentlichen Anforderungen des Kunden zu konzentrieren. Target Integration in MATLAB/Simulink Ein Baustein für die zügige Entwicklung neuer Fahrzeugelektroniksysteme ist die Modularität der Universalsteuergeräte. Die drei Baseboard-Varianten, die im Wesentlichen die Ansteuerung der Aktoren und die Versorgung beinhalten, können wahlweise mit den derzeit verfügbaren Prozessoren C167, MPC555 oder Tricore als CPU-Module

2 SOFTWAREl AUTOMOTIVE l51 kombiniert werden. Projektspezifisch wird so das passende System hinsichtlich Hardwareumgebung sowie geforderter Rechenart und Rechenleistung zusammengestellt. Der zweite Baustein für die Umsetzung der elektronischen Steuerung ist das Softwaredesign inklusive Hardwareimplementierung. Die Funktionsentwicklung erfolgt mit modellbasierter Entwicklung in Simulink. Für die Programmierung aller Prozessoren wird MATLAB und Simulink als Entwicklungsumgebung eingesetzt, der benötigte C-Code wird durch automatische Code-Generierung mit dem Real- Time Workshop (RTW) direkt aus den Simulink-Modellen gewonnen. Im Vergleich zur konventionellen Programmierung in C hat die Verwendung der automatischen Code- Generierung folgende Vorteile: Funktionsentwicklung und Programmierung können in einem Schritt durchgeführt werden. Die Software kann modulweise oder auch mittels Software-in-the-Loop-Tests vollständig durch Simulation getestet werden. Das Simulink-Modell dient als Dokumentation für die Steuergerätesoftware. Das Erstellen und die Verwaltung einer Softwarebibliothek (Simulink-Module und selbst erstellte S-Function Blöcke) ist sehr einfach. Die Mehrfachverwendung von Modulen aus einer Bibliothek vereinfacht eine große Testtiefe. Bild 1: OSEK-Integration in Simulink: Die einzelnen Tasks werden als Function-Call Subsystem in Simulink dargestellt. Die Wartbarkeit bzw. Erweiterbarkeit von Simulink- Modellen ist erheblich einfacher als von C-Code Programmen. Um all die genannten Vorteile nutzen zu können ist es notwendig, den Code-Generierungsprozess mit dem Real- Time Workshop bzw. RTW Embedded Coder an die jeweiligen Steuergeräte/Prozessoren zu adaptieren. Die Applikationsparameter werden direkt in MATLAB angelegt, User C-Code wird direkt ins Simulink-Modell eingebunden, nach der Code-Generierung mittels RTW wird automatisch der entsprechende Compiler aufgerufen und zum Schluss erfolgt ein automatischer Download auf das Steuergerät über den CAN-Bus. Die Auswahl der CPU hängt von den Anforderungen des jeweiligen Projektes ab. Im Folgenden sind die Target-Integration für die unterschiedlichen Prozessoren kurz beschrieben: Die C167 CPU wird vorwiegend für die Entwicklung von Seriensoftware eingesetzt, um die Funktionsentwicklung auf einer CPU durchzuführen, die auch in Serie eingesetzt werden kann. Bei diesem Target (IAV UCU C167 Target) erfolgt die Task-Steuerung durch den automatisch generierten Scheduler des RTW, dessen zyklischer Aufruf in ein eigenes Basisprogramm für den C167 integriert ist. Für Anwendungen mit großer Rechenleistung kommt der MPC555 zum Einsatz. Dies Target (IAV UCU MPC555 Target) setzt auf dem Embedded Target for Motorola MPC555 von Mathworks auf. Der TriCore wird immer dann eingesetzt, wenn große Anforderungen an die Peripherie gestellt werden (z. B. viele hoch auflösende PWM-Signale). Für diesen Prozessor stehen zwei Target Integrationen zur Auswahl: Beim IAV UCU TriCore Target wird die Tasksteuerung durch einen selbst entwickelten Scheduler realisiert. Das IAV UCU TriCore OSEK Target basiert auf dem ERCOSEK der Firma ETAS. Einbindung des OSEK in MATLAB/Simulink Bei komplexen Steuergeräteprogrammen ist es vorteilhaft, ein Betriebssystem (OSEK) einzusetzen, um die Rechenleistung der CPU optimal auszunutzen. Die Hauptaufgabe eines OSEK ist die Task-Steuerung. Zum Beispiel können Tasks mit hoher Priorität andere Tasks mit kleinerer Priorität unterbrechen, um unterschiedliche Zykluszeiten zu realisieren. Damit auch bei der Verwendung eines OSEK die ge-

3 52lA UTOMOTIVE Bild 2: CAN-Schnittstelle in Simulink: Neben den entsprechenden Variablen (aus Datenbasis) liefert dieser Block Informationen über neu empfangene Daten oder Timeout eines bestimmten CAN-Identifier. Bild 3: Mathematisches Modell der Steuergeräteumgebung in einem Configurable Subsystem, das für die Code-Generierung inaktiviert werden kann. samte Entwicklung in MATLAB/Simulink erfolgt, wurde das Task Scheduling des OSEK mittels S-Funktion in Simulink integriert (Bild 1). Die S-Function dient somit als integrierter OSEK-Konfigurator. Integration der UCU-Hardware-I/Os in Simulink Zusätzlich zur Funktionsentwicklung ist es notwendig, die Hardware der UCU I/Os (z. B. digital I/O, analog I/O, CAN I/O oder PWM I/O) aus Simulink anzusprechen. Zu diesem Zweck wurde für die IAV Universal Steuergeräte mit unterschiedlichen CPUs ein einheitlicher HAL (Hardware Abstraction Layer) entwikkelt. Die Integration der HAL-Aufrufe (API s) in Simulink erfolgt durch unterschiedliche S-Functions mit den dazugehörigen TLC- Scripten, die die Art der Codegenierung mit dem RTW steuern. Der CANin Block (Bild 2) z. B. konfiguriert sich automatisch, indem eine Vector-Datenbasis geladen und der gewünschte Identifier ausgelesen wird. In der Simulation werden die Simulations-Inputdaten (z. B. von mathematischen Modellen oder einem Joystick) des Blockes an die Ausgänge kopiert oder reale CAN-Daten gelesen. Als CAN- Bus Interface dient wahlweise eine Vector CANCardX oder ein IAV CAN <-> USB Adapter. Bei der Code-Generierung entsteht ein API-Aufruf zum Lesen der CAN-Daten. Sind aktuelle Daten eingetroffen, dann erfolgt eine Decodierung der CAN-Daten entsprechend den Vorgaben aus der Vector CAN-Datenbasis. Solch eine flexible Code-Generierung ist mit dem TLC-Script des RTW möglich, da der generierte C-Code abhängig von den Vorgaben aus der Vector-Datenbasis generisch erstellt wird. Software-in-the-Loop Der große Vorteil der Softwareentwick-lung in Simulink ist die einfache Simulation der Funktionsmodule. Um die Simulationskette zu schließen ist es oftmals notwendig, ein mathematisches Modell der Steuergeräteumgebung zu erstellen (Bild 3). Die Ausgangssignale des Modells werden z. B. über die UCU Hardware S-Function Blöcke (z. B. CANin oder ADCin) mittels der Kopierfunktion im Simulationsmode (Bild 5) an die Funktionsmodule übergeben. Damit bei der Code-Generierung kein überflüssiger Simulations-Code entsteht, sind alle Simulationsmodule jeweils in ein Configurable Subsystem eingebettet. Hier existieren für jedes Modell zwei Blöcke mit gleicher Anzahl von Einund Ausgängen (Bild 3).

4 SOFTWAREl AUTOMOTIVE l53 Block 1 (Modell_sim) dient zur Simulation und enthält somit ein mathematisches Modell der Simulationsumgebung (z. B. mathematisches Modell einer Gleichstrom- Maschine). Block 2 (Modell_code) ist bei der Code-Generierung aktiv. Die Inputs sind auf Terminator Blöcke geführt und die Outputs sind mit Ground Blöcken verbunden. Dadurch entsteht auf dem Steuergerät kein überflüssiger Simulations-Code. Eine Umschaltung zwischen Simulations-Block und Code-Generierungs-Block erfolgt über den Parameter Block choise. Dadurch ist es möglich, mit einem Simulink-Modell sowohl umfangreiche Simulationen durchzuführen als auch auf Knopfdruck (Ctrl B) Steuergeräte zu programmieren. Bild 4: MATLAB Application Interface Applikation mittels CCP über den CAN-Bus Bei Rapid-Prototyping-Steuergeräten ist das CAN Calibration Protokoll (CCP) zum Applizieren weit verbreitet. Bei der MPC555 CPU kommt das CCP Modul von The MathWorks zum Einsatz. Die IAV Basisprogramme für C167 CPU und TriCore CPU enthalten selbst erstellte CCP-Module. Hierbei befinden sich die Referenz-Anwendungssparameter wahlweise im EEPROM oder Flash. Beim Start des Steuergerätes wird eine Kopie der Parameter ins RAM kopiert. Über das CCP lassen sich die einzelnen Parameter anpassen. Ist eine optimale Einstellung gefunden, dann lässt sich bei der EEPROM Version der aktuelle RAM-Datensatz über einen CCP-Befehl als neuer Referenzdatensatz ins EEPROM speichern und über eine Checksumme sichern. Damit die MAT- LAB/Simulink Tool-Kette eine solche CCP-Applikationsschnittstelle durchgängig unterstützt, wurde ein Zusatzprogramm MATLAB Application Interface erstellt. In diesem Tool werden alle Anwendungsparameter (für MATLAB/ Simulink und zusätzlichen C-Code) angelegt (Bild 4). Das Anwendungstool hat folgende Funktionalitäten: Um die Applikationsparameter im MAT- LAB/Simulink anzulegen, erzeugt das Programm eine *.m Datei, in der die Eigenschaften der Applikationsparameter beschrieben sind. Über eine Verknüpfung des Simulink Modells mit der *.m Datei lässt sich der Applikationsparameter direkt in Simulink-Blöck-en verwenden (Bild 5). Zusätzlich wird eine *.h Datei erzeugt, in der die Applikationsparameter angelegt werden, da diese in MAT- LAB/Simulink als ImportedExtern deklariert werden. Die Verknüpfung der *.h Datei erfolgt über den User-Code-Block Parameter File (Bild 1).

5 54lA UTOMOTIVE Bild 5: Anzeige von Blockparametern mittels CCP Zum Online-Applizieren besitzt das Applikationsprogramm eine CCP-Schnittstelle. Dadurch lassen sich aktuelle Parameter auf ein Steuergerät speichern oder ein Datensatz aus einem Steuergerät lesen, um diese Parameter über eine neue *.m Datei in MATLAB/Simulink zur Simulation zu übertragen. Durch die durchgängige Toolkette ist es einfach möglich, in Simulink-Modellen und bei der automatischen Code-Generierung mit Applikationsparametern (Einzelwerte und Matrizen z. B. für Kennlinien) zu arbeiten. Des Weiteren ist ein einfacher Austausch von Datensätzen zwischen einer Simulation in Simulink und dem Steuergerät möglich. Aufgrund der Verwendung einer genormten Applikationsschnittstelle können weitere Applikationstools wie z. B. INKA von ETAS und CANap von Vector eingesetzt werden. Nutzung des CCP Treibers als Debug-Schnittstelle Bei der Integration und dem Debugging der Software auf dem Steuergerät ist es oftmals sehr hilfreich, wenn der Entwickler sich online den Wert bestimmter Variable ansehen kann. Durch eine entsprechende Parametrierung generiert der RTW für jeden Simulink-Blockausgang ein eigenes Element in der globalen Block-I/O Struktur. Um online den Wert aus dem Steuergerät auszulesen sind folgende Schritte notwendig: Ermitteln des vom RTW generierten Namen und Datentyp der Variablen für den Blockausgang im Source-Code. die Adresse der Variablen aus der Map Datei des Compilers lesen. mittels CCP-Protokoll den Wert der Variablen aus dem Steuergerät zyklisch lesen. All diese Schritte wurden in einer speziellen S-Function umgesetzt. Diese S-Function (CCP Debug) wird in das Simulink Modell eingefügt (Bild 1) und unterstützt dann den Entwickler automatisch beim Debuggen des Steuergerätes. Während der Simulation kann der Entwickler auf jeden (nicht virtuellen) Block klicken. Daraufhin öffnet sich ein Dialog (Bild 5), in dem alle Variablen, die zu diesem Block gehören, angezeigt werden. Im Hintergrund holt sich die S-Function die Adressen der darzustellenden Variablen aus der Map Datei und liest die aktuellen Werte zyklisch mittels CAN- CardX oder IAV CAN<->USB Adapter über das CCP Protokoll vom Steuergerät. Wenn der Block Parameter enthält, lassen sich diese online verändern (Bild 5). Somit ist es möglich, selbst beim Debuggen MATLAB/Simulink als vollständige Entwicklungsumgebung zu nutzen. Der Funktions-Softwareentwickler denkt während der gesamten Entwicklung in den grafischen Simulink-Strukturen. Durch diese Erweiterung hat er jetzt die Möglichkeit durch Klicken auf einen beliebigen Block nachzusehen, ob die Block Eingangs- /Ausgangs- und Internen Variablen auf dem Steuergerät im Fahrzeug den erwarteten Wert haben. Ausblick Die Verwendung von MATLAB/Simulink zur Steuergeräteprogrammierung hat sich bei IAV bereits in vielen Kundenprojekten bewährt. Die offenen Schnittstellen von MATLAB/Simulink haben es ermöglicht, eine durchgängige ToolKette aufzusetzen, wodurch die gesamte Softwareentwick-lung (Multitasking Design, Programmierung, Kompilieren, Download, Applikation und Debugging) in der Simulink Oberfläche erfolgen kann. Gerade im Rapid Prototyping Bereich ist die IAV mit dieser Tool-Kette in der Lage, sehr flexibel auf unterschiedlichste Kundenanforderung zu reagieren. Durch einen hohen Automatisierungsgrad bei der Softwareentwicklung (z. B. automatische Code-Generierung aus einer CAN-Datenbasis und die Verwendung von umfangreichen Bibliotheken) werden Softwarefehler minimiert und Entwicklungszeiten verkürzt. Die Tool-Kette wird fortwährend weiterentwickelt. In einem nächsten Schritt ist die Integration des OSEK Target für die C167 und die MPC555 CPU vorgesehen, um die Portierbarkeit der Simulink Modelle auf unterschiedliche Steuergeräte zu verbessern. Auch das Applikationssystem wird in Zukunft für alle Prozessoren angeglichen. Eine zusätzliche grafische Online-Ausgabe von Debug-Daten in der Simulink-Umgebung wird bei zukünftigen Projekten den Entwicklern die Fehlersuche erheblich erleichtern. (oe) Weitere Informationen zu den hier beschriebenen Tools erhalten Sie von der Firma The Mathworks. Bernd Jahrsau und Martin Richter entwickeln Elektronik-Systeme im Geschäftsfeld Automobilelektronik der IAV GmbH The