Von der Funktion zum serienreifen Steuergerät - dSPACE

ENTWICKLUNGSWERKZEUGESoftware-EntwicklungVon der Funktionzum serienreifenSteuergerätWie können neue Standards die Weiterentwicklung von Entwicklungswerkzeugenfördern und die Zusammenführung von bisher völlig getrennten Werkzeugenermöglichen? Welchen Einfluss nehmen Echtzeitbetriebssystem-Standards wieOSEK/VDX auf die hardwarenahe Codegenerierung? Diese und viele andere Fragenstellen sich heute die Entwickler von Steuergeräten, die sich mit neuen Methodender Software-Entwicklung auf diesem Gebiet beschäftigen. Wie die dSPACE GmbHdie vollständige Integration eines Echtzeitbetriebssystems in den Codegenerierungsprozessverfolgt wird hier anhand eines Gesamtüberblicks beschrieben.2 Automotive Electronics

1 EinleitungDie Software-Entwicklung für Steuergerätewird in zunehmendem Maße mitmodellbasierenden Entwicklungstoolswie MATLAB/Simulink/Stateflow von TheMathWorks durchgeführt. Steht die Spezifikationunter Zuhilfenahme dieser Toolsfest, beginnt die Arbeit der Codierung. Diegrafisch beschriebenen Funktionen müssennun in C-Code umgewandelt undzusammen mit einem Echtzeitbetriebssystemauf der Steuer-gerätehardwareimplementiert werden.2 TargetLink für die Codegenerierungnach MaßEin Seriencodegenerator wie beispielsweiseTargetLink von dSPACE löst das anstehendeCodierproblem. TargetLink ergänztdie Simulink-Umgebung um eine Codegenerierungin Serienqualität und ist in derLage, portablen ANSI-C-Code sowie auchprozessor- und compilerspezifischen Codezu generieren.TargetLink kann sowohl ein unverändertesSimulink-Modell vollautomatisch –also mit wohlüberlegten Standardeinstellungen– in eine optimale Echtzeitimplementierungumsetzen, als auch umfangreichezusätzliche Optionen anbieten, dieeine exakte Anpassung an spezielle Anforderungenerlauben. Dabei ist zu beachten:Ein Simulink-Modell kennt ursprünglichkeine Tasks, sondern ist aus anderenObjekten aufgebaut, die der Codegeneratorauf Betriebssystemeinheiten abbildenmuss. Für die automatische Codegenerierungaus Simulink für Echtzeitbetriebssystemeergeben sich daher zwei wesentlicheZiele:◆ Die Abbildung von etablierten Simulink-Modellierungskonzepten auf verfügbareBetriebssystemobjekte.◆ Die Schaffung neuer Spezifikationsmöglichkeitenauf Modellebene für wichtigeBetriebssystemeigenschaften.Eine leistungsfähige Codegenerierungkann die technischen Hürden zwischender Modellierung und der Implementierungauf Basis eines Echtzeitbetriebssystemssignifikant abbauen. Doch welcheRolle spielt dabei der OSEK/VDX-Betriebssystemstandardin Bezug auf TargetLink?Unter OSEK/VDX sind offene Systeme undderen Schnittstellen für die Elektronik imKraftfahrzeug/Vehicle Distributed eXecutive.dSPACE erweitert in der nächsten Versionvon TargetLink den Anwendungsbereichder Codegenerierung um die Unterstützungvon OSEK/VDX-konformenBetriebssystemen. Die Gründe hierfür sind:◆ Der OSEK/VDX-Standard definiert eineeinheitliche Betriebssystemfunktionalitätund eine einheitliche Programmierschnittstelleder Betriebssystemdienste.Damit ist es einem Codegenerator möglich,auch den Anschluss an diese Softwareschichtzu automatisieren. Dies istbei proprietären Echtzeitbetriebssystemennur über zusätzliche manuelle Programmierungmöglich.◆ OSEK/VDX hat eine weite Verbreitunginnerhalb der Automobilindustrie gefundenund es existiert inzwischen eine Reihehocheffizienter, kommerzieller Betriebssysteme,die diesem Standard genügen. Folglichmöchten die Anwender auch eineautomatische Anbindung für die Codegenerierungan ihr OSEK/VDX-konformesEchtzeitbetriebssystem.3 OSEK/VDX: Konzepte undZieleDer OSEK/VDX-Betriebssystemstandardbeschreibt ein statisches Echtzeitbetriebssystem,dessen Objekte (Tasks, Events,Messages, Ressourcen, etc.) alle zur Compile-Zeitangelegt werden. Diese Betriebssystem-Objektewerden in einer speziellenBeschreibungssprache (OIL: OSEK/VDXImplementation Language) definiert. Zueinem Objekt gehören bestimmte OIL-Attribute wie beispielsweise die Prioritäteiner Task. Zusätzlich zu den Standard-Attributen können Hersteller vonOSEK/VDX-konformen Betriebssystemenweitere Attribute definieren und so zumBeispiel ihr Betriebssystem auf bestimmteMikrocontroller anpassen.3.1 Ziele von OSEK/VDXZiel des OSEK/VDX-Betriebssystemstandardsist es, die Wiederverwendbarkeitund Portierbarkeit von Anwendungs-Softwarezu verbessern. Um dieses Ziel zu erreichen,wurden von den OSEK/VDX-ArbeitsgruppenSchnittstellen in den BereichenEchzeitbetriebssystem, Kommunikationund Netzwerk-Management spezifiziert.Es soll hier nur auf den Bereich Echtzeitbetriebssystemeingegangen werden.OSEK/VDX selbst ist also kein Betriebssystem,sondern ein Standard, der dieSchnittstellen und das Verhalten einesOSEK/VDX-konformen Betriebssystems,im Folgenden OSEK/VDX-Betriebssystemgenannt, definiert. Die Vorteile desOSEK/VDX-Standards sind:◆ Verkürzung der Entwicklungszeit◆ Erhöhte Software-Qualität durch Wiederverwendungbereits getesteter Software-Module◆ Optimale Speicherausnutzung durchSkalierbarkeitDie AutorenDr. Ing. Lutz Köster istGruppenleiter der Software-Entwicklungbei derdSPACE GmbH, Paderborn.Dr. Ing. Rainer Otterbachist Leiter Produktmanagementbei der dSPACEGmbH, Paderborn.Dipl.-Ing. (FH) GüntherGruhn ist TechnischerRedakteur bei der dSPA-CE GmbH, Paderborn.SummaryFunctionDesign to ProductionECUIs it possible to map operatingsystem functionalities whileduring function design for anelectronic control unit (ECU)?How can new standards promotethe further development ofdevelopment tools and enablecompletely separate tools to bebrought together? What effectare real-time operating systemstandards such as OSEK/VDXhaving on hardware-relatedcode generation? These andmany other questions todayface the developers of ECUs asthey investigate new methodsof software development fortheir field. The following overviewgives an account of howdSPACE GmbH is striving forcomplete integration of a realtimeoperating system in thecode generation process.Sonderausgabe von ATZ und MTZ und AUTOMOTIVE ENGINEERING PARTNERS3

ENTWICKLUNGSWERKZEUGESoftware-Entwicklung4.1 Die Schritte vom Simulink-Modell zurausführbaren TaskBild 1: Typisches Simulink/Stateflow-Diagramm◆ Wiederverwendung von Software inanderen Umgebungen.3.2 Die Skalierbarkeit innerhalbvon OSEK/VDXUnterschiedliche Anwendungen erfordernunterschiedliche Betriebssystemfunktionalitäten.Um keine Steuergeräte-Ressourcen zu verschwenden, ist es notwendig,das Betriebssystem zu skalieren,also dessen Umfang an die Anwendunganzupassen.Um dieses Ziel zu erreichen, sieht derOSEK/VDX-Standard zwei Stufen für eineschrittweise Fokussierung der Anwenderbedürfnissevor:◆ Mit einer Entscheidung für einebestimmte der vier vordefinierten Conformanceklassen,die unterschiedliche Funktionsumfängebeschreiben.◆ Mit individuellen Einträgen in die OIL-Datei. Diese statische Definition derBetriebssystemobjekte erlaubt die Generierungeines Betriebssystemkerns mitdem System-Generator des Betriebssystemherstellers,der genau nur die Funktionenenthält, die für die jeweiligeAnwendung benötigt werden.Der OSEK/VDX-Betriebssystemstandarddefiniert als wichtigste Objekte:◆ Tasks, die als Software-Einheiten dieeinzelnen Funktionen der Steuergeräte-Software beinhalten.◆ Counter, Alarme und Events, um wiederkehrendeEreignisse zu verarbeiten oderTasks zu synchronisieren.◆ Eine Message-basierende Inter-Task-Kommunikation für den Datenaustauschsowohl zwischen Tasks auf demselbenSteuergerät als auch zwischen Tasks, diesich auf verschiedenen Steuergerätenbefinden.◆ Verriegelungsmechanismen (Ressourcen),um den gemeinsamen Zugriff vonverschiedenen Tasks oder Interrupt ServiceRoutinen (ISR) auf kritische Bereiche zuregeln.4 Modellierung von Echtzeit-Anwendungen in Simulink/TargetLinkEine Anwendung, die auf einem Echtzeitbetriebssystembasiert, ist in unterschiedlicheSoftware-Einheiten aufgeteilt. Diesesogenannten Tasks fassen Software-Abschnitte mit gemeinsamen Echtzeitanforderungenwie Timing, Priorität etc.zusammen. Sie werden vom Echtzeitbetriebssystemperiodisch zu definierten Zeitenaufgerufen oder durch aperiodischeHard- oder Software-Ereignisse aktiviert.4.1 Die Schritte vom Simulink-Modell zur ausführbaren TaskSimulink nutzt zur hierarchischen Strukturierungdes Modells sogenannte Subsysteme,die zu einer gewissen Funktionalitätgehörende Basisblöcke zusammenfassen.Diese Basisblöcke werden entwederzyklisch mit einer bestimmten Abtastrateoder ereignisgetrieben abgearbeitet.Bild 1 zeigt ein typisches Simulink/StateflowDiagramm, das periodische undereignisgetriebene Modellteile enthält.Um dieses Modell als OSEK/VDX-Echtzeitanwendungzu implementieren, bedarf esmehrerer Schritte.4.2 Periodische TasksIm Beispiel von Bild 1 würde TargetLinkdas 10ms- und 100ms-Subsystem jeweilsals separate Task (A und B) implementieren.Die zugehörigen C-Funktionen werdenautomatisch durch entsprechendeSchlüsselwörter im Code als Task gekennzeichnet.Zusätzlich wird das Betriebssystemdurch die Vorgaben von TargetLinkso konfiguriert, dass diese Tasks automatischin der korrekten Periodendauer aufgerufenwerden. Hierfür werden OSEK-Alarme definiert, geeigneten Timern zugeordnetund in einer speziellen Startup-Routine durch entsprechende Betriebssystemaufrufeinitialisiert.4.3 Aperiodische TasksEreignisgesteuerte Funktionen werden inSimulink durch getriggerte Subsystememodelliert. Ihre Triggerung wird entwederdurch bestimmte Bedingungen ausgelöst,die im Steuergerätecode selbst ausgewertetwerden (FC_System in Bild 1), oderdurch externe Ereignisse wie zum BeispielHardware-Interrupts.Die intern getriggerten Systeme werdenvon TargetLink entweder als C-Funktionen,die nach Auswertung der Trigger-Bedingung direkt aufgerufen werden,implementiert oder optional – wie in Bild 1– als separate Task D, die nach Auswertungder Trigger-Bedingung durch entsprechendeBetriebssystemfunktionenaktiviert wird.Extern getriggerte Systeme sind solche,deren Triggerung nicht durch Steuergerätecodeausgelöst wird, sondern zum Beispieldurch einen Hardware-Interrupt(Crankshaft in Bild 1). Für die Simulationkönnen diese externen Triggerquellen mitSimulink-Blöcken nachgebildet (Chart inBild 1) werden. Seriencode soll für dieseBlöcke allerdings nicht generiert werden.Der Wirkungsbereich des Codegenerators4 Automotive Electronics

umfasst daher nur den im Bild 1 gestricheltenBereich. TargetLink implementiertextern getriggerte Systeme standardmäßigals Tasks und stellt dafür Aktivierungsfunktionenzur Verfügung, die derAnwender den Triggerquellen zuordnenmuss.4.4 Vermeiden von Task-Overhead4.4 Vermeiden von Task-OverheadEin Steuergerät enthält üblicherweise einegrößere Anzahl von Funktionalitäten(zum Beispiel Drosselklappenregelung,Leerlaufregelung, Abgasrückführung etc.),die häufig von verschiedenen Teams entwickeltund sinnvollerweise als getrennteSubsysteme dargestellt werden. Jedes dieserFeatures kann wiederum Teile enthalten,die zum Beispiel im 10ms-Raster odersynchron zur Kurbelwelle abgearbeitetwerden müssen. TargetLink kann, soferngewünscht, alle periodischen Subsystemegleicher Abtastrate zu gemeinsamenTasks zusammenfassen. Getriggerte Subsystememit gemeinsamer Triggerquellewerden ebenfalls zusammengefasst.Dabei spielt es keine Rolle, wie die Subsystemeim Modell verteilt sind. Die Zusammenfassungdieser verteilten Einzelsystemegleicher Periodizität oder Eventzugehörigkeit– häufig Prozesse genannt –hilft Task-Overhead zu sparen.Neben der automatischen Taskpartitionierungkann der Anwender diese auchgezielt selbst spezifizieren. Ein spezieller„Taskblock“, Bild 2, der in das Simulinkmodelleingefügt wird, erlaubt es demAnwender, ein Simulink-Subsystem expliziteiner schon existierenden oder einerneu anzulegenden Task zuzuordnen.4.5 OSEK/VDX konforme TaskkonfigurationMit der Aktivierung des Taskblocks (Doppelklick)gelangt man in den Taskblock-Dialog. Eine Liste zeigt hier die schon imGesamtsystem vorhandenen Tasks an.Das aktuelle Subsystem kann einer dieserTasks zugeordnet werden oder es kanneine neue Task kreiert werden. Dazu gibtes Menüeinträge für alle von OSEK vorgeschriebenenAttribute wie Priorität,Anzahl der Aktivierungen, Unterbrechbarkeit,benutzte Ressourcen oder zugehörigeEvents. Darüber hinaus können für eineReihe von kommerziellen OSEK-Betriebssystemenauch die nicht standardisierten,herstellerspezifischen Optionen direkt ausder TargetLink-Umgebung eingestelltwerden.Bild 2: Taskblock-Dialog4.6 Inter-Task-Kommunikationund OIL-DateiDer nächste wichtige Schritt ist die Umsetzungder Datenverbindungen zwischenden Tasks. Betriebssysteme bieten üblicherweiseDienste zum geschütztenDatenaustausch zwischen Tasks an.OSEK/VDX definiert dafür sogenannteMessages, die allerdings für den Datenverkehrzwischen Tasks auf demselben Steuergerätnicht immer die effizientesteLösung darstellen.Daher kann TargetLink auch automatischden jeweils effizientesten Weg des Datenaustauschs,der abhängig von den Taskeinstellungenist, implementieren (globaleVariablen mit lokalen Kopien oderohne lokale Kopien, Interrupt-Sperre, Ressourcen-Belegungetc.).Mit den Einstellungsdaten der Taskkonfigurationund den Einstellungsdatender Inter-Task-Kommunikation wird vonTargetLink eine Offline-Beschreibung dergesamten Anwendung in Form einer OIL-Datei generiert, Bild 3. Mit den hierin enthaltenenInformationen kann der System-Generator des Betriebssystemherstellerseinen optimal angepassten Echtzeitkernerzeugen.5 OSEK/VDX-Konfigurationund verschiedene WerkzeugeEin typisches Steuergeräteprogrammbesteht aus mehreren C-Quelldateien, vonSonderausgabe von ATZ und MTZ und AUTOMOTIVE ENGINEERING PARTNERS5

ENTWICKLUNGSWERKZEUGESoftware-Entwicklung4.6 Inter-Task-Kommunikationund OIL-Datei5 OSEK/VDX-Konfiguration und verschiedeneWerkzeugeBild 3: Beispiel einer OIL-DateiBild 4: Zusammenspiel der Entwicklungswerkzeugedenen einige beispielsweise von Target-Link erzeugt, andere von Handprogrammiererngeliefert werden. Eine gemeinsameOIL-Beschreibung dient als Eingabe fürden System-Generator, der das Betriebssystemoptimal konfiguriert. Der so angepassteEchtzeitkern wird zusammen mitden anderen Modulen zum endgültigenausführbaren Programm verbunden, Bild4.5.1 Konsistenz durch einegemeinsame OIL-DatenbasisZur Erzeugung der textuellen OIL-Dateigibt es verschiedene Möglichkeiten. Zumeinen sollten die Eigenschaften der ausdem Simulink-Modell stammendenBetriebssystemobjekte sinnvollerweisedirekt auf Modellebene spezifiziert sowiedie zugehörigen OIL-Abschnitte automatischgeneriert werden können. Zum anderenliefern die meisten OSEK/VDX-Betriebssystem-Anbieter komfortable grafischeTools zur Konfiguration der OIL-Datei. Deren Nutzung ist sicherlich für diehandgeschriebenen Programmteile sinnvoll.Für ein nahtloses Zusammenspiel beiderWerkzeuge benutzt TargetLink eineexterne OIL-Datei als Datenbasis für dieBetriebssystemeinstellungen, aus derimportiert und in die exportiert werdenkann. Simulink-Komponenten (zum BeispielSubsysteme) können OSEK/VDX-Objekten (zum Beispiel Tasks) zugewiesenwerden, die bereits in der Datenbasis existieren,oder es können neue Einträgeangelegt werden. Der Anwender kann freientscheiden, welches das für ihn geeignetsteTool zum Spezifizieren der Attribute ist.Die Verwendung der gemeinsamen,externen OIL-Datenbasis gewährleistetKonsistenz – Änderungen, die in einemTool vorgenommen werden, werden alsoautomatisch vom anderen übernommen.6 Simulation von OSEK-AnwendungenEine der großen Stärken von Simulink ist,dass das Verhalten eines entworfenenSteuergeräts direkt auf dem PC simuliertwerden kann. Für den Test des Steuergerätealgorithmuswird häufig ein Streckenmodellbenutzt, um den Regelkreis zuschließen, Bild 5.Während der Entwurfsphase wird diesesModell von Simulink Block für Block inhöchster Fließkomma-Genauigkeit simuliert.Die gleiche Anordnung kann in derTargetLink-Umgebung benutzt werden,um in der Implementierungsphase denautomatisch generierten Seriencode zutesten und beispielsweise die Quantisierungseffekteeiner Festkomma-Implementierungzu untersuchen.In diesem Simulationsmodus wirdanstelle der originalen Simulink-Blöcke('Controller'-Subsystem aus Bild 5), dergenerierte C-Code in die Simulation eingebettet(Software-in-the-Loop). Dieser Codewird entweder auf dem Entwicklungs-PC,im Nachfolgenden Host-PC genannt, ausgeführt(Production Code Host Mode) oderals spezielle Option auf einem realenMicrocontroller Board (Production CodeTarget Mode). In beiden Fällen wird dasStreckenmodell, das die Teststimulierzeugt, von Simulink auf dem Host-PCberechnet.Da in diesen Simulationsmodi der gleicheCode benutzt wird, der nachher auchauf dem Steuergerät läuft, bekommt derAnwender schon in der Simulationsphaseexakt die gleichen Berechnungsergebnissewie in der späteren realen Applikation.Das gilt insbesondere für den 'ProductionCode Target Mode', da hier der endgültigeSeriencode-Compiler zum Übersetzen desC-Programmes benutzt wird und so auchdessen Effekte berücksichtigt werden.Der in der Simulation verwendete Seriencodeenthält im Falle einer OSEK-Anwendung Betriebssystemaufrufe,deren Funktion in der Simulation nachgebildetwerden muss. Dazu bietet Target-Link folgende zwei Möglichkeiten.◆ Simulation mit spezieller OSEK Nachbildung:TargetLink stellt für die Simulationein vereinfachtes OSEK-Betriebssystemzur Verfügung, das alle im generiertenSeriencode aufgerufenen Betriebssystem-6 Automotive Electronics

6 Simulation von OSEK-AnwendungenBild 5: Fließkomma-SimulationBild 6: ProductionCode Target-Simulationmit OSEK/VDX-Betriebssystemfunktionen abbildet. Diese 'OSEK-Nachbildung'ist auf die Anforderungen dieser'Software-in-the-Loop'-Simulation zugeschnittenund nutzt auf diese Weise dieVereinfachungen aus, die sich aus der speziellenNicht-Echtzeit-Simulationsumgebungergeben.◆ Simulation mit echtem OSEK Betriebssystem:Das Ziel des Entwicklers ist es, schonin der Simulationsphase möglichst vieleder später verwendeten Software-Bausteineund deren Zusammenspiel zu testen.Dazu wird in der 'Production Code TargetSimulation' das endgültige (kommerzielle)OSEK-Betriebssystem des späteren Steuergerätesverwendet und der generierteCode ('Controller'-Subsystem aus Bild 5)zusammen mit diesem OSEK-Betriebssystemauf einem Mikrocontroller-Boardimplementiert. Gegenüber der späterenEchtzeitausführung werden für die SimulationModifikationen vorgenommen.Da der Fortschritt der Simulation auchvon Modellteilen abhängt, die auf demHost-PC gerechnet werden (Streckenmodell),und daher nicht Echtzeit entspricht,muss die Zielhardware von ihren Echtzeit-Eingängen – Hardware-Timern und Hardware-Interrupts– abgetrennt werden.Diese Stimuli werden vom Host-PC (Simulink)entsprechend der aktuellen Simulationszeitgeliefert, Bild 6. Dazu wird anstelledes 'Controller'-Subsystems in Simulinkein Programmteil (S-Funktion) eingesetzt,das die Schnittstelle zum Microcontroller-Board bedient.7 Spezifische Codegenerierungfür kommerzielle OSEK/VDX-BetriebssystemeOSEK/VDX lässt eine ausreichende Flexibilitätzu, um die Eigenschaften der verschiedenenMikrocontroller optimal auszunutzen.Deshalb können bestimmteSonderausgabe von ATZ und MTZ und AUTOMOTIVE ENGINEERING PARTNERS7

ENTWICKLUNGSWERKZEUGESoftware-EntwicklungFunktionen in verschiedenen OSEK-Betriebssystemen unterschiedliche Benutzerschnittstellenhaben. Beispiele hierfürsind:◆ API-Funktionen für Counter, welchenicht in OSEK/VDX festgelegt sind◆ Unterschiede bei den OIL-Attributen.Viele sind schon im OSEK/VDX-Standarddefiniert, jedoch können zusätzlich beliebigviele Attribute vom Hersteller definiertwerden.TargetLink benutzt, sofern es nötig ist,auch die vom jeweiligen Betriebssystemherstellerzusätzlich zum Standard angebotenenBetriebssystemfunktionen, umeffizienten und lesbaren Code zu erzeugen.Der Anwender erhält die Möglichkeit,auch diese Attribute in der TargetLink-Umgebung einzustellen.Möchte ein Anwender sein Programmvon einem OSEK/VDX-Betriebssystem aufein anderes übertragen, ersetzt TargetLinkautomatisch die betriebssystemspezifischenFunktionsaufrufe und OIL-Attribute.Das erhöht die Portierbarkeit und dieWiederverwendbarkeit. Nicht zuletztführen die Kooperationen zwischenOSEK/VDX-Anbietern und dSPACE zueinem optimalen Zusammenspiel zwischenden einzelnen OSEK/VDX-Betriebssystemenund TargetLink.8 ZusammenfassungEine ständig wachsende Anzahl vonAnwendern in automotiven Entwicklungsbereichennutzt MATLAB/Simulink/Stateflowals Spezifikationsbasis fürden gesamten Entwicklungszyklus elektronischerSteuergeräte.Möglich wird dies auch durch den Einsatzvon TargetLink, einem Codegenerator,der aus Simulink-Modellen automatischseriencodetauglichen C-Code generierenkann. Für die Implementierung der vollständigenSteuergeräte-Software ist derAnschluss an ein Echtzeitbetriebssystemund dabei besonders an den weit verbreitetenStandard OSEK/VDX von großerBedeutung. TargetLink wird in seinernächsten Version die Modellierungskonzeptevon Simulink noch umfassender,und wenn gewünscht, auch vollautomatischauf OSEK/VDX-Funktionalität abbildenkönnen. Funktionsentwickler werdenweiterhin in ihrer vertrauten Umgebungarbeiten und sich trotzdem die OSEK/VDX-Dienste und Eigenschaften im Modellnutzbar machen können.Literaturhinweise[1] Köster, L., Thomsen, T, Stracke, R.: ConnectingSimulink to OSEK/VDX: Automatic Code Generationfor Real-Time Operating Systems with Target-Link, SAE Technical Paper 2001-01-0024, März2001[2] OSEK/VDX Operating System, Version 2.1 revision1, November 2000[3] OSEK/VDX System Generation OIL: OSEKImplementation Language, Version 2.2, Juli 2000[4] OSEK/VDX Communication, Version 2.2.2,Dezember 2000[5] TargetLink Production Code Generation Guide,dSPACE GmbH, Mai 2000[6] Simulink User’s Guide, The MathWorks, Nattick,MA USA 1999[7] Hanselmann, H., Kiffmeier, U., Köster, L.,Meyer, M.: Automatic Generation of ProductionQuality Code for ECUs, SAE Technical Paper 1999-01-1168, März 19998 Automotive Electronics