Projektgruppe: Airbag Steuerung. Code-Generierung. Christoph Zobiegala. FB Informatik, Uni Dortmund

Transkript

1 Code-Generierung Christoph Zobiegala FB Informatik, Uni Dortmund - 1 -

2 Zusammenfassung Bei der Entwicklung von Steuergeräten im Automobilbereich kommt es heute früher oder später zu einem Bruch in der Toolkette. Meist werden halbformale Methoden und Werkzeuge zur Spezifikation und zur Simulation verwendet, allerdings muß die Applikationssoftware nach wie vor von Hand geschrieben werden, um die Anforderungen bezüglich Geschwindigkeit und Speicherverbrach zu erfüllen. Um dieses Problem zu lösen, entwickeln einige Firmen wie dspace (TargetLink) oder ETAS (ASCET-SD) Entwicklungsumgebungen, die in der Lage sind, abstrakte Beschreibungsmodelle in effizienten, serientauglichen Code für ein Echtzeit-Betriebssystem umzusetzen. Das Konzept des Codegenerators basiert auf einer intelligenten Umsetzung der in SimuLink/Stateflow-Model bzw. Statemate vorhandenen Elemente wie Activities, States, Events, Dataflows usw. in C-Code. Der in Statemate normalerweise vorhandene Scheduling-Mechanismus wird ausgeschnitten und durch das OSEK Betriebssystem ersetzt. Durch den Einsatz des Codegenerators kann ein durchgängiger Entwicklungsprozeß für Software von Seriensteuergeräten realisiert werden. Durch den Wegfall der Codierung von Hand wird die Interpretierbarkeit der Spezifikation vermindert, die Qualität der Software gesteigert und der Aufwand verringert

3 Einleitung Das Fahrzeug der Zukunft wird in zunehmendem Maße geprägt sein von elektronischen Systemen. Die Bandbreite reicht dabei vom Antriebs- und Fahrwerksbereich über die Karosserie bis hin zu den Informations- und Kommunikationssystemen. Bereits heute werden 30% der Wertschöpfung bei Fahrzeugen der gehobenen Mittelklasse durch Elektronik erreicht. Die Differenzierung von Mitbewerbern wird in Zukunft verstärkt über elektronische Systeme erfolgen. Aber nicht nur die Anzahl der Steuergeräte, auch denen Komplexität nimmt dramatische Dimensionen an. Während früher die Komplexität durch die Leistungs(un)fähigkeit der Mikrocontroller eingeschränkt war, wird in Zukunft mehr der Entwicklungsprozeß der limitierende Faktor sein. Aus diesem Grunde kommt dem Steuergeräteentwicklungsprozeß eine Schlüsselrolle in der Fahrzeugentwicklung zu. Wer diesen Prozeß beherrscht wird bessere Automobile in kürzerer Zeit auf den Markt bringen können. In kürzerer Zeit heißt, trotz wachsender Komplexität, schneller auf die Marktbedürfnisse reagieren zu können. Dies ist vor allem bei elektronischen Systemen sehr wichtig, um dem rasanten Fortschritt folgen zu können. Die vorliegende Seminararbeit beschäftigt sich mit der Verbesserung des Steuergeräteentwicklungsprozesses. Sie ist wie folgt gegliedert: am Anfang wird der klassische Entwicklungsprozeß beschrieben wie er auch heutzutage noch zu finden ist. Später wird gezeigt, wie dieser Prozeß unter Verwendung von CASE-Tools verbessert werden kann und wo noch Schwachpunkte existieren. Anschließend wird der ideale Entwicklungsprozeß vorgestellt, der ohne Bruch von der abstrakten Spezifikation bis hin zum Seriensteuergerätecode durchlaufen werden kann

4 1 Der klassische Entwicklungsprozeß Der Steuergeräteentwicklungsprozeß beschreibt den Weg von der Idee bis hin zum Seriensteuergerät. Diese Arbeit beschränkt sich nur auf die Software des Steuergeräts. Die Entwicklung der Hardware liegt nicht im Kerngeschäft der Automobilhersteller und wird meist vom Zuliefere durchgeführt. Im klassischen Prozeß wird die Entwicklung ohne die Verwendung von sogenannten CASE- Tools durchgeführt. Im ersten Schritt wird versucht, die Idee textuell durch ein Lastenheft zu formulieren. Man spricht hier auch von einer informellen Anforderungsspezifikation. Daß Problem ist, die Idee hinsichtlich des Verhaltens sowohl vollständig, als auch eindeutig zu formulieren. Gerade die Eindeutigkeit leidet unter der Verwendung der menschlichen Sprache, die inhärent mehrdeutig ist. Es gibt praktisch keine Möglichkeit zu überprüfen, ob das Lastenheft die Idee richtig beschreibt. Im nächsten Schritt bewährt dann das Lastenheft in Software umgesetzt. Dies geschieht entweder bei dem Automobilhersteller, in den meisten Fällen jedoch beim Zulieferer. Dazu werden konkrete Programmiersprachen verwendet. Während früher Assemblersprachen eingesetzt wurden, wird heutzutage fast ausschließlich in C programmiert. Ist das Lastenheft umgesetzt, beginnt für den Automobilhersteller die schwierige Aufgabe zu validieren, ob die Umsetzung richtig durchgeführt worden ist. Konkret heißt das, es muß überprüft werden, ob das Verhalten der Software der Beschreibung im Lastenheft und damit der Idee entspricht. Dabei kann man drei Fehlerklassen unterscheiden: Klasse 1: Das Verhalten war nicht eindeutig beschrieben. Der Programmierer hat den Text falsch interpretiert und umgesetzt. Klasse 2: Das Verhalten war nicht vollständig beschrieben. Der Programmierer hat versucht die fehlende Beschreibung nach seinen Vorstellungen zu programmieren. Klasse 3: Der Programmierer hat Programmierfehler gemacht. Das heißt, das Verhalten war richtig beschrieben und wurde auch richtig verstanden, aber falsch in der Programmiersprache umgesetzt. Lediglich für die dritte Fehlerart kann man den Programmierer verantwortlich machen. Die beiden ersten Fehlerarten gehen zur Lasten der Spezifikation. Die Frage nach denm Verantwortlichen ist jedoch zweitrangig. Vor dem Serienlauf sollten alle Fehler gefunden und beseitigt sein

5 Eine Grobvalidierung der Software gegenüber dem Lastenheft erfolgt üblicherweise auf dem PC. Zu diesem Zweck müssen auch diese Umgebungsmodelle per Hand in einer konkreten Programmiersprache codiert werden. Ferner muß der Code für die Eingabe von Stimuli und die Ausgabe und Aufzeichnung von Berechnungsergebnissen hinzugefügt werden. Die eigentliche Validierung erfolgt aber mit Hilfe eines Mustersteuergerätes unter Zuhilfenahme eines Versuchsträgers. Erst damit kann man das Verhalten am realem Prozeß erfahren. Hat man einen Fehler gefunden, dann beginnt ein langwirieger Zyklus: Der Fehler wird dem Zulieferer mitgeteilt, wobei unter Umständen auch das Lastenheft angepaßt werden muß. Der Zulieferer ändert die Software so ab, daß seiner Meinung nach der Fehler behoben ist. Der neue Softwarestand wird dann wieder zum Automobilhersteller geschickt, um erneut im Fahrzeug getestet zu werden. Natürlich muß auch wieder überprüft werden, ob der Fehler korrekt behoben worden ist. Diese äußerst langwierige und mühselige Zyklus wird oft durchlaufen. Am Ende der Evaluirungsphase wird versucht das Verhalten durch Verändern der Parameter optimal auf das Fahrzeug abzustimmen. Selbst in dieser Phase können noch Fehler aufgedeckt werden. Deren Änderung ist dann äußerst zeitraubend und kostspielig. Die Folgerung hieraus ist: In jeder Phase der Entwicklung können Fehler entstehen. Je später sie erkannt werden, um so teurer werden sie und zwar um den Faktor 10 x pro Phase. 2 CASE: Computer Aided Systems Engineering Der Problempunkt beim klassischen Entwicklungsprozeß liegt in der Umsetzung des Lastenheftes in ein konkretes Modell. Die Umsetzung ist langsam und schwierig, und das Modell orientiert sich meist an der verwendeten Programmiersprache und nicht am Problem. Wird die Umsetzung beim Zulieferer gemacht, kommt noch die Problematik der räumlichen Entfernung hinzu. Sie erschwert, trotz moderner Kommunikationsmittel, den Informationsaustausch zwischen dem Verfasser des Lastenheftes und dem Implementierer. Dadurch werden Fehler der ersten beiden Klassen zu spät erkannt. Genau an diesem Problempunkt wird durch die Verwendung von CASE Werkzeugen angesetzt. Es kommen derzeit mehrere Werkzeuge zum Einsatz. Zwei davon sind: Statemate undmatrixx. MatrixX wird zum Entwurf zeitkontinuierlicher, regelungstechnische Systeme verwendet. Statemate hingegen kommt bei der Entwicklung zustandsbasierter Modelle zum - 5 -

6 Einsatz. Für die meisten Steuergeräte müssen jedoch sowohl kontinuierliche als auch zustandsbasierte Modelle entwickelt werden. Man spricht dann von hybriden Modellen. In diesem Fall werden beide Werkzeuge kombiniert eingesetzt. 2.1 Abstrakte Modellierung Sowohl Statemate als auch MatrixX ermöglichen die Erstellung von abstrakten Modellen. Statt konkreter Programmiersprachen stehen hierzu abstrakte, graphische Beschreibungtechniken, wie Zustandsautomaten, Datenflußdiagramme zur Verfügung. Die Beschreibung erfolgt auf einer höheren Ebene und ist damit wesentlich problemorientierter. Das Lastenheft kann somit schneller in ein abstraktes Modell umgesetzt werden. Die Modellerstellung erfordert auch keine Programmierkenntnisse im herkömmlichen Sinne. Der Ersteller muß keine Kenntnisse über Speicherklassen, Zeiger, Parameterübergabe, u.s.w. haben. Eine entsprechende Kenntnis der oben genannten Programme muß allerdings vorausgesetzt werden. Trotz der graphischen Beschreibung sind die oben genannten Techniken als formal, oder zumindest semi-formal anzusehen. Das heißt, die Modelle haben weitestgehend eine formale, eindeutige Semantik. Im Gegensatz zu natürlichen Sprachen werden dadurch Fehlerarten der ersten Klasse automatisch vermieden. Das Verhalten ist exakt beschrieben und kann damit nicht mißinterpretiert werden. Auch Fehler der 2. Art werden reduziert, da alleine schon der Gebrauch semi-formaler Techniken eine strukturierte Vorgehensweise erzwingt. Vorausgesetzt muß dabei aber werden, daß die Idee auch korrekt in das abstrakte Modell umgesetzt worden ist. Auf die Validierungstechniken der Umsetzung wird später noch eingegangen. Das mit Hilfe eines CASE Werkzeugs erstellte Modell stellt somit, im Gegensatz zum Lastenheft eine semi-formale Spezifikation dar. Gibt man nun dieses Modell, anstatt des Lastenheftes, dem Zulieferer als Anforderungsspezifikation, so sind zumindest Fehler der 1. Klasse ausgeschlossen. Der Implementierer sollte diese Art der Spezifikation lesen können

7 2.2 Simulation Die oben genannten Werkzeuge unterstützen aber nicht nur die abstrakte, semi-formale Spezifikation des Lastenheftes, sondern auch die Validierung der erstellten Modelle gegenüber dem Lastenheft und letztendlich gegenüber der Idee. Denn obwohl auf einer höheren problemorientierten Ebene beschrieben wird, lassen sich Fehler bei der Umsetzung nicht vermeiden. Deshalb ist es wichtig, daß die Vollständigkeit und Korrektheit der CASE-Modelle gegenüber dem textuellen Lastenheft, respektive der Idee, beim Autohersteller getestet wird. Die Validierung erfolgt dabei grundsätzlich zweistufig: Wir beginnen mit der Simulation des Verhaltens auf einem PC oder einer Workstation. Zu diesem Zweck werden die erstellten graphischen Modelle interpretiert und schrittweise abgearbeitet. Neben den eigentlichen Steuerungs- und Regelungsmodellen müssen dazu auch mehr oder weniger komplexe Umgebungsmodelle zur Verfügung stehen. Auch diese werden mit Hilfe der CASE Werkzeuge abstrakt beschrieben. Werden durch die Simulation Fehler entdeckt, dann können die graphischen Modelle wesentlich schneller geändert und erneut getestet werden, ohne daß dabei der Zulieferer ins Spiel kommt. Später werden die Umgebungsmodelle teilweise durch echte Hardware ersetzt. Man spricht dann von Hardware in the Loop Simulation. Durch die Simulation werden nicht in erster Linie Umsetzungsfehler entdeckt, sondern meist Mehrdeutigkeiten und fehlende Festlegungen im Lastenheft. Oft werden auch Fehler in Lastenheft oder generelle Probleme der Idee entdeckt. Mit Hilfe der Simulation wird also eine Funktionsfindung und deren Absicherung erreicht. 2.3 Rapid Prototyping Durch Simulation am Rechner im Labor können natürlich nicht alle Fehler erkannt werden. Insbesondere bei dynamischen Systemen ist eine Abarbeitung in Echtzeit am realen Prozeß unumgänglich. Die Interpretation der Modelle erlaubt jedoch keine Abarbeitung in Echtzeit. Dazu müssen die graphischen Modelle in konkrete Programmiersprachen übersetzt werden und im ein Echtzeitbetriebssystem eingebettet werden. Auf geeigneten Rechnern können die übersetzten Modelle dann getestet werden. Dies erfolgt zuerst im Labor und dann in einem realen Versuchsträger. Diese Vorgehensweise nennt man Rapid Prototyping. Durch Rapid Prototyping kamen die zu entwickelnden Funktionalitäten schon in einer sehr frühen Phase im Fahrzeug "erlebt" werden. Die Validierung der erstellten Modelle kann sehr realitätsnah - 7 -

8 durchgeführt werden. Zusammen mit der abstrakten Beschreibung können sehr schnell alternative Ideen real erprobt werden, ohne daß der Zulieferer beteiligt ist. Dadurch ist gewährleistet, daß nur abgesicherte Modelle als Anforderungsspezifikation zum Zulieferer gelangen. Die Anzahl der Änderungsschleifen kann somit insgesamt deutlich reduziert werden. 2.4 Der CASE-basierte Entwicklungsprozeß Den CASE-basierten Prozeß kann man folgendermaßen beschreiben. Im Mittelpunkt stehen die mit Hilfe von CASE Werkzeugen erstellten abstrakten Modelle. Im Gegensatz zu konkreten Modellen können diese schneller und ohne detaillierte Programmierkenntnisse erstellt werden. Dies muß, mit entsprechender Unterstützung, in den Fachabteilungen der Autohersteller erfolgen. Mit Hilfe von Simulationen und Rapid Prototyping Techniken werden die erstellten Modelle dann validiert und abgesichert. Dadurch können Mehrdeutigkeiten und fehlende Beschreibungen im Lastenheft aufgezeigt werden. Erst die abgesicherten Modelle werden beim Zulieferer für die Seriensteuergeräte implementiert. Fehler der ersten beiden Arten sind bei diesem Prozeß nahezu ausgeschlossen. Was bleibt sind Fehler, die bei der Umsetzung der abstrakten Modelle in die Steuergerätesoftware entstanden sind. Sie müssen dann während der Applikationsphase mit dem Mustersteuergerät aufgespürt werden. Durch den CASE basierten Entwicklungsprozeß kann die Entwicklungszeit für Steuergeräte deutlich reduziert werden. Unnötige Korrekturschleifen, die durch schlecht abgesicherte, textuelle Lastenhefte verursacht werden, entfallen. Der Ingenieur erstellt aktiv die Verhaltensmodelle und behält dadurch das exakte Wissen über die Steuergerätefunktion. Nur so ist gewährleistet, daß der Autohersteller auf dem Gebiet der mechatronischen Systeme, das in Zukunft die Automobilwelt prägen wird, weiterhin führend sein kann. 3 Von der Spezifikation zum Targetcode Der in Kapitel 2 aufgezeigte Entwurfsprozeß hat noch einen großen Schwachpunkt: Die Handumsetzung der abstrakten Modelle in die konkrete Programmiersprache für das Seriensteuergerät. Die Gefahr einer fehlerhaften Codierung ist relativ groß. Aus diesem Grund muß das Verhalten des Seriencodes erneut gegenüber dem abstrakten Modell validiert werden. Da dies erst in einer relativ späten Entwicklungsphase erfolgt, sind die Kosten für eventuelle - 8 -

9 Fehler relativ hoch. Da die Änderungschleife außerdem über die Handumsetzung und den Zulieferer läuft, sind Änderungen in dieser Phase auch sehr zeitintensiv. Werden in diese Phase doch noch Konzeptfehler entdeckt, wird oft nur die konkrete Modellierung geändert. Dies führt dazu, daß Spezifikation und Implementierung auseinanderdriften. In diesem Prozeßschritt steckt also noch ein hohes Verbesserungspotential. Die beiden CASE-Tools Statemate und MatrixX können beide aus ihren abstrakten Modellen Programmcode erstellen. Die Größe und Performance des erzeugten Codes ist aber gerade ausreichend, um mit leistungsstarker Experimentalhardware für Rapid Prototyping eingesetzt werden zu können. Für die Seriencodegenerierung sind die heutigen Codegeneratoren dieser Systeme nicht geeignet. Eigens dafür gibt es ein CASE Werkzeug mit Namen ASCET-SD /1/ von der Firma ETAS und TargetLink der Firma dspace. ASCET-SD und TargetLink wurden speziell für den Entwurf von Steuergerätesoftware im Automobilbereich entwickelt. Ziel dieser Systeme ist es, den Entwicklungsprozeß von der Spezifikation bis zum Targetcode durchgängig zu unterstützen. Dies soll durch Codegeneratoren erreicht werden, die ganz spezifisch für verschiedene eingebettete Microcontroller entwickelt werden. Damit könnte ein wesentlicher Bruch im CASE Entwicklungsprozeß behoben werden. 3.1 ASCET-SD: Ein Überblick ASCET-SD Entwicklungsumgebung stellt dem Benutzer ein breites Spektrum an Anwendungen. Der gesamte Prozeß der Entwicklung von eingebetteten Systemen, von mehr Idee bis zum fertigen Code wird durchgehend unterstützt. Diese Kontinuität eliminiert das Bedürfnis zum Wechseln der Entwicklungsumgebung. Das Resultat: gesteigerte Produktivität, kürzere Zeit bis zur Markteinführung und verbesserte Softwarequalität. Die Unterstützung beschränkt sich nicht nur auf die Codeherstellueung sondern auch auf die den Prozeß umgebende Dateninfrastruktur z.b. verchiedene Dokumentenformate wie RTF, HTML, PostScript oder Meßformate wie ASCII, FAMOS, MDF. Dies gewährleistet eine leichte Integration von ASCET- SD in die Dateninfrastruktur des Prozesses Entwicklungsprozess - 9 -

10 ASCET-SD behauptet, umfassend die in den Entwicklungsprozeß zustande kommenden Phasen zu unterstützten. Die Spezifikation der Algorithmen, Daten und Werte, die automatischen Codegenerierung basierend auf der Spezifikation und Verifikation der generierten Software sind im Entwicklungsprozeß miteinander verzahnt. Die Schnittstelle zum Benutzer umfaßt individuell einstellbare Spezifikationseditoren, um die Bedürfnisse des Benutzers zu befriedigen aber auch die Handhabung zu erleichtern. Spezifikation, Code und Experimente sind durch die Benutzung von Datenbasen und strukturierten Bibliothekskonzepten leicht zu handhaben. Physikal Offline Simulation Model on model level Real Time Offline Simulation OS on code level Implemen Real Time tation Simulation on code level Real Time Execution on code level on target hardware Spezifikationssprache Die Spezifikation von eingebetteten Kontrolalgorithmen erfolgt bei ASCET-SD durch eine für Entwickler bekannte Form nämlich als Blockdiagramme, Zustandsautomaten, C-Code oder in einer ASCET-SD eigene Beschreibungssprache: EDSL (Embedded Software Description Language). Diese abstrakten Beschreibungstechniken erlauben ein hohes Grad an Wiederverwendbarkeit. In eingebetteten Kontrollsystemen ist die Beschreibung von zwei Verhalten erforderlich: des funktionalen und zeitlichen Verhaltens. Die Beschreibung diese Sachverhalte erfolgt in

11 ASCET-SD separat, so daß viele Algorithmen in verschiedenen Kontexten wiederverwendet werden können. Dies schadet in keinster Weise der Effizienz der Algorithmen. Ein spezielles Problem von eingebetteten Kontrollapplikationen ist die Sicherstellung der Konsistenz der Daten für Subroutinen. Um dieses Problem zu lösen hat ASCET-SD spezielle Features für Interprozeßkommunikation, welche die erstellten Algorithmen sicher und portierbar machen. Benutzerfreundliche Editoren, welche speziell auf die Erfordernisse der jeweiligen Applikationen angepaßt werden können werden benutzt um diese zu beschreiben. Alle diese Editoren werden per Maus und drag & drop gesteuert. Häufig können die Algorithmen durch graphische Blockdiagramme beschrieben werden. Datenfluß und somit auch die Verbindung von individuellen Blöcken wird in solchen Beschreibungen graphisch dargestellt. Die Visualisierung des Datenflusses wird in ASCET-SD durch die Blockdiagrammeditoren unterstützt was zur graphischen Beschreibung der Komponenten auf der physikalischen Ebene genutzt werden kann. Nicht alle Algorithmen der Kontrollsoftware sind der Kontrolle zuzuordnen wie z.b. Diagnostik und Speicherverwaltungsalgorithmen. Sie lassen sich unter Umständen besser textuell beschreiben. Um diesem Umstand gerecht zu werden, benutzt ASCET-SD die Beschreibungssprache EDSL. EDSL basiert auf der JAVA Syntax und unterstützt den objektorientierten Ansatz von ASCET-SD. Diese Vorgehensweise, Algorithmen in EDSL zu formulieren ist zielplatform- und implementationsunabhängig. Bei komplexeren Applikationen könnte es zweckmäßiger sein, sie als Zustandsautomat zu beschreiben. Im dem eigens zu diesem Zweck vorhandenen ASCET-SD Editor, kann der Benutzer graphisch Zustände und Zustandsübergänge definieren. Gewisse Kontrollsoftwarekomponenten können nicht bis auf die physikalische Ebene herunter abstrahiert werden. Für diese besonderen Fälle stellt die ASCET-SD Umgebung einen C-Code Editor zur Verfügung. Dieser Code kann für verschiedene Hardwareplattformen gesondert gespeichert werden Versuchsumgebung

12 Der Übergang von der Entwicklungs- in die Versuchsumgebung wird einfach durch betätigen des entsprechenden Buttons hergestellt. Durch ein einfaches Selektieren der Zielplattform wird das dazugehörige Compiler Toolset gestartet. Die generierte ausführbare Datei wird auf die Zielplattform geladen und eine Kommunikationsmöglichkeit wird etabliert. In der Versuchsumgebung überprüft man die auf Blockdiagrammen oder Zustandsautomaten basierende Spezifikation. Während des gesamten Ablaufs des Codes ist es möglich, Verbindung zur Spezifikation aufrecht zu erhalten. Es ist ebenfalls möglich, die interaktive Kontrolle des Experiments zu Nutzen d.h. die Reihenfolge des Programms zu beeinflussen. Der Ereignisgenerator erlaubt die Bestimmung der gerade ausgeführten Sequenz während der Datengenerator die Simulation des Inputs erlaubt auf Basis von definierten oder gemessenen Signalwerten. Das Beobachten des Verhaltens ist wesentlich für das Verifizieren und Validieren der Spezifikation. Hierbei wird man durch graphische Displays (Oszilloskop, Balkendiagramme u.s.w.) unterstützt. Diese Art der Anzeige ist nicht Teil des untersuchten Modells, kann aber interaktiv in der Versuchsumgebung passend zum untersuchten Model, kreiert und konfiguriert werden. Außerdem können Outputdaten zwecks weiterer Analysen in Echtzeit aufgezeichnet und in eine Datei gespeichert werden. Die unterstützten Dateiformate sind wie bereits erwähnt MDF, FAMOS, ASCII Implementationsebene Obwohl die Kontrollalgorithmen auf der physikalischen Ebene beschrieben sind, kann man sie leicht in eingebettete Software konvertieren. Wichtig hierbei ist der Übergang zur Festkommaarithmetik, welche bei den meisten Kontrollern Verwendung findet. Dabei sollten Overfloweffekte in die Überlegungen einbezogen werden. Bei ASCET-SD kann man für jede Variable den Wertebereich sowie die Darstellung einfach auswählen. In der Versuchsumgebung wird man dabei insofern unterstützt als das man interaktiv den Wertebereich und die Darstellung ändern und dabei die Auswirkungen direkt während der Ausführung verfolgen kann. ASCET-SD ist ebenfalls in der Lage, automatisch den passenden Datentyp zu berechnen. In der Versuchsumgebung kann man, wie bereits beschrieben, die Kontrollsoftware mit direktem Zugriff zur Spezifikation laufen lassen. Die in der Software enthaltenen Variablen

13 können angezeigt werden. Dadurch ist es möglich, das Verhalten auf der abstrakten Definitionsebene, wie auch das Verhalten des generierten Codes zu studieren ASCET-SD: Zusammenfassung ASCET-SD ist eine Entwicklungsumgebung für eingebettete Steuerungssysteme. Das funktionale Verhalten der Systeme wird mit Hilfe von graphischen Beschreibungstechniken spezifiziert. Im Mittelpunkt steht dabei ein Blockdiagrammeditor. Mit ihm lassen sich regelungstechnische Algorithmen intuitiv durch drag & drop Technik graphisch spezifizieren. Die zustandsbasierten Anteile können mit Hilfe von Zustandsautomaten beschrieben werden. Diese bestehen wie üblich aus Zuständen, Übergängen, Übergangsbedingungen und Aktionen, die beim Übergang ausgeführt werden. Sowohl Blockdiagramme, als auch Automaten können hierarchisch strukturiert werden. ASCET-SD folgt dem objekt-basierten Paradigma. Sowohl Blockdiagramme, als auch Automaten sind modular aufgebaute Komponenten mit einer sauber definierten Schnittstelle und einer gekapselten Funktionalität. Dies unterstützt die Wiederverwendung von Komponenten auf allen Ebenen. Eine konsequente Wiederverwendung von bewährten und getesteten Komponenten kann die Entwicklungszeit eines Systems deutlich reduzieren. ASCET-SD getestet ferner die Spezifikation von Echtzeitmechanismen wie Ereignisse, Unterbrechungen, Nachrichten oder Taskscheduling. Ein Projekt kann durch Tasks mit unterschiedlichen Aktivierungszeiten strukturiert werden. In den Tasks wiederum werden sequentiell einzelne Prozesse gestartet. Zur Validierung kann die Spezifikation in einer Experimentierumgebung auf dem PC ausgeführt werden. Das Verhalten des Systems kann dabei durch eine Reihe von Meßwerkzeugen beobachtet werden. Zur Ausführung in Echtzeit stehen Experimentalplattformen zur Verfügung. Diese sind fahrzeugtauglich und können für Rapid Prototyping im Fahrzeug verwendet werden. Bei der Codegenerierung für die Experimentalplattformen wird das Echtzeitbetriebssystem ERCOS dazugebunden. Alle Meß- und Kalibrierungsmöglichkeiten die während der Simulation auf dem PC zur Verfügung stehen, stehen auch für die Echtzeitausführung zur Verfügung. Der Programmablauf kann auch hier am graphischen Modell verfolgt werden

14 Mit Hilfe von sogenannten Target Integration Packages kann Code für bestimmte Zielsysteme erzeugt werden. Derzeit werden für zwei Microcontroller solche Packages angeboten: Für die 80 C16x Familie und die Embedded PowerPC Familie. DieTarget Integration Packages erzeugen aus der graphischen Beschreibung des Systems optimierten Code für den jeweiligen Controler. Ob der erzeugte Code tatsächlich hinsichtlich Größe und Laufzeit für Seriensteuergeräte geeignet ist, kann experimentell untersucht werden. 3.2 TargetLink Dieses Programm ist eine Sotwaretool für die Herstellung von Steuergerätesoftware. Sie generiert aus SimuLink/Stateflow-Modellen automatisch Code für Serien-Prozessoren. Im folgendem sollen die Schritte der Codegenerierung, von der abstrakten Modellierung in Simulink/Stateflow bis zum Targetcode dargelegt werden. 1. Die sich innerhalb des Modells befindlichen Kontrollersubsysteme, werden durch Kopien aus der TargetLink Blockbibliothek ersetzt. Diese Blockkopien enthalten Daten, die für dir Codegenerierung gebraucht werden. Nach dieser Ersetzung können Modifikationen erfolgen, die wenn nötig, bis zum Originalzustand zurückgesetzt werden können. 2. Skalieren der Parameter. Sind die Wertebereiche der Variablen bekannt, so werden sie manuell eingetragen. Ist es nicht der Fall, so kann durch off-line Simulationen dar min/max Bereich ermittelt werden und manuell oder automatisch gesetzt werden. 3. Zusätzliche Festkomma- und coderelevante Daten werden eingegeben. Beispiele hierfür: Spezifikation der Look-up Tabellen, Wertebereichinformationen für kalibrierbare Parameter. 4. Off-line Simulationen auf dem PC decken mögliche Probleme mit Festkommaarithmetik oder overflow Effekte. Die letztgenannten werden durch Simulationsläufe mit Fließkommazahlen aufgedeckt, indem man guckt, ob die min/max Signale mir den festgelegten Bereichen übereinstimmen. Um die Effekte der Festkommaarithmetik (Verlust der Genauigkeit, Größenordnung) zu überprüfen, generiert TargetLink ein Code, der innerhalb der Si

15 mulink Umgebung ablaufen kann. Die auf dem PC beobachteten Effekte, sind die gleichen wie sie auf der Zielhardware auftreten würden. (Software-in-the-Loop) 5. Zuletzt wird der C-Code generiert. Diese C-Code wird auf einem Zielprozessorevaluationsmodul zur Ausführung gebracht. Dazu generiert und sendet eine von TargetLink erzeugte Schnittstellenfunktion Kontrollersignale an die Applikation. Die Ausgabesignale werden an das Blockdiagramm gesendet. Diese Vorgehensweise wird als Prozessor-in-the- Loop bezeichnet. Die Besonderheiten von TargetLink sind: - Code-Generierung direkt aus Simulink/Stateflow - Automatische Erstellung von Report-Dateien (HTML) - Mögliche Anbindung an bereits vorhandenen Code - Zusammenfassung und Management aller Programmteile und Reglerfunktionen - Inter-Block-Optimiereung: Kombination von Blöcken für maximale Code-Effizienz Weitere Bestandteile dieses Werkzeugs sind TargetLink Optimisation Modules das optimierten Code für bestimmte Compiler/Controller Kombinationen liefert, das Target Simulation Module zu Code-Ausführung auf einer Evaluierungshardware sowie das ASPA2 Modul der Schnittstelle zum vorhandenen Applikationssystem. Es existieren bereits Prototypen von Produkten die mit Hilfe von TargetLink erstellt wurden. So endstand z.b. bei DaimlerChrysler ein Steuergerät zur Berechnung der Brems/Beschleunigungs-momente für ein Hybrid-Antriebskonzept. Die durch Simulink modellierten Algorithmen und Kennfelder wurden mit der automatische Fesatkomma- Codegenerierung von TargetLink in laufähigen Code umgesetzt, was die Entwicklungszeit und den Programmieraufwand deutlich reduzierte. 4 Eine abschließende Betrachtung Steuergeräte werden in den nächsten Jahren im Automobilbereich einer dominierende Rolle übernehmen. Die Durchgängigkeit bei der Entwicklung der Software für solche Systeme, von der abstrakten Spezifikation bis zum Seriencode wird erheblich zur Effizienzsteigerung beitragen. In den letzten Jahren wurden Anstrengungen unternommen, den Entwurfsprozeß von

16 einer ausschließlichen Handcodierung der Steuergeräte in Richtung abstrakte Modellierung zu verändern. Mit den oben genannten Werkzeugen scheint dieser Schritt, dank der automatischen Generierung von Targetcode, nun tatsächlich Realität zu werden. Die in der letzten Zeit diesbezüglich durchgeführten Projekte untersuchten die Auswirkungen auf den derzeitigen Entwicklungsprozeß. Die Ergebnisse zeigen, daß die Durchgängigkeit bis zum Seriencode für 16 Bit Microcontroller prinzipiell möglich ist. Insgesamt wird deutlich, daß insbesondere ASCET-SD zwar die späteren Phasen im Entwicklungsprozeß deutlich besser unterstützt als anderer Werkzeuge, aber in der frühen Phase und in der Analyse von Reglern Defizite aufweist. Solche Projekte, in denen die Unzulänglichkeiten der Werkzeuge aufgezeigt werden, können Einfluß auf die nächste Generation der Entwicklungsumgebungen nehmen, in denen diese Schwächen abstellt sind. [FuNa 97] [Stein 97] Fuchs, M. - Nazareth, D.: Prozeßinovation - Steuergeräteentwicklung (Ein BMW Experiment basierend auf ASCET-SD), VDI Bericht 1374, 1997 Steinhauer, S. - France, B. - Yerushalim, R.: SW Synthese für Embedded Anwendungen im KfZ- Bereich, 1997 [HKKM 99] Hanselmann, H. - Kiffmeier, U. - Köster, L. - Mayer, M.: Automatic Generation of Produktion Code for ECU, 1999 [dspace 99] Product Overviev ASCET-SD V 2.1, [Stand: ]