Für die Erstellung von Fahrzeugapplikationen werden, wie bereits im oberen Bild dargestellt, verschiedene Prozesse durchlaufen. Diese Aneinanderreihung wird als Arbeitsablauf (engl. Workflow) bezeichnet. Nachfolgend wird dieser im Bezug auf unser System näher beschrieben.
Angelehnt an das V-Modell werden im Vorfeld die Systemanforderungen und die Systemarchitektur bestimmt. Diese sind durch unser Modellfahrzeug, die Hardwareauswahl und die Rahmenbedingungen (z.B. Schnittstellen) vorgegeben. Aufbauend auf diesen Hintergrund setzt sich der Workflow zur Funktionsentwicklung zusammen.
Der erste Schritt ist die Erstellung eines Modells auf Grundlage fahrdynamischer Eigenschaften und Parameter des Fahrzeuges mit Hilfe von Matlab Simulink. Dieses Modell kann in einem zweiten Schritt unabhängig von der Zielplattform simuliert werden. Hierdurch ergibt sich der Vorteil der Aufgabenteilung der Entwickler für die Applikations- und Steuergeräteprogrammierung. Zudem kann das entworfene Modell auf unterschiedliche Systemreaktionen geprüft und mit aufgezeichneten Sensorwerten plausibilisiert werden (siehe Software in the Loop).
Fortführend schließt sich die Portierung der Funktion bei einem erfolgreich geprüften Modell an. Hierfür wird das Subsystem in Matlab Simulink mit Hilfe von Real-Time-Workshop in C-Code übersetzt. Damit der generierte Programmcode auf dem Mikrocontroller lauffähig ist, müssen die spezifizierten Ein- und Ausgänge des Subsystems mit der Peripherie des Mikrocontrollers und folglich der Sensorik/Aktorik verknüpft werden. Ferner ist ein Rahmenprogramm notwendig, welches den generierten Programmcode anbindet und in einer definierten Abfolge unter Berücksichtung des Zeitverhaltens abarbeitet. Dies durchläuft den Prozess (vergleiche Bild) der embedded Softwareentwicklung.
Im Detail:
Der durch den Real-Time-Workshop generierte C-Code erstellt verschiedene C-Module (Header + Source Code). Die Namensgebung leitet sich aus dem gewählten Namen des Simulink Subsystems ab. (z.B. Steuergeraet).
Wichtige Dateien sind hierbei:
- Steuergeraet.c (enthält gesamte Funktion des Modells)
- Steuergeraet.h (Struturen/Definitionen der Eingangs-/Ausgangsvariablen, …)
- Steuergeraet_data.c (wird durch Konstanten (z.B. Const-Block) erzeugt)
Zunächst ist es ratsam die in der Datei Steuergeraet.c vorhandene Funktion
Steuergeraet_initialize(1);
einmalig auszuführen. Diese initialisiert deklarierte Variablen mit den Startwerten.
Die allgemeine Programmabfolge sieht das Einlesen (Holen der Eingangswerte über festgelegte Schnittstellen, z.B. CAN, UART, SPI, ..), Verarbeitung (Simulink-Modell) und die Ausgabe (Ansteuern der Aktorik, z.B. Servomotoren) vor.
Die einmalige Abarbeitung des übersetzten Modells erfolgt durch die Funktion
Steuergeraet_step();
ebenfalls in der Datei Steuergeraet.c aufzufinden.
Damit diese Abfolge in festen Zyklen ausgeführt werden kann, sollte ein Timer auf dem Mikrocontroller dafür verwendet werden.
Insgesamt entfällt also der größte Programmieraufwand auf die Anbindung der Datenkommunikation/Peripherie.
Anschließend wird die entwickelte Fahrzeugfunktion im Hinblick auf die gesamte Fahrzeugelektronik/Hardwareumgebung integriert und mit Messfahrten bestätigt, bzw. das Auftreten unerwartete Fehler aufgedeckt. Dies umfasst den letzten Punkt des Workflows der “Testfahrt/Verifikation”. Aufgezeichnete Messdaten können fortführend an diesem Prozess wieder dem Matlab Simulink Modell zugeführt werden, um aufgetretene Fehler detaillierter zu untersuchen und entsprechende Verbesserungen durchzuführen.
Der Workflow beginnt von vorn!
One Trackback
[...] eines Arm7 Controllers Wie auch schon in anderen Artikeln erwähnt, wird der gesamte Funktionsumfang des Fahrzeuges durch ein Matlab Simulink-Modell [...]