Integration abstrakter RTOS-Simulation in den Entwurf eingebetteter automobiler E/E-Systeme

Transkript

1 Integration abstrakter RTOS-Simulation in den Entwurf eingebetteter automobiler E/E-Systeme Markus Becker, Henning Zabel, Wolfgang Müller Universität Paderborn, C-LAB Fürstenallee Paderborn {beckerm, henning, Ulrich Kiffmeier dspace GmbH Technologiepark Paderborn Zusammenfassung Die steigende Komplexität eingebetteter Systeme im Automobilbereich erfordert neue Entwurfsmethodiken und Werkzeuge, um die Qualität zu sichern und Entwicklungskosten zu beherrschen. Die frühzeitige Analyse von Timing-Fehlern in sicherheitskritischen Echtzeitanwendungen ist problematisch, da konventionelle, exakte Simulationsmodelle erst in späteren Entwurfsphasen zur Verfügung stehen. Mit abstrakten RTOS-Modellen können effiziente und trotzdem hinreichend zeitgenaue Simulationen durchgeführt werden, die den verfügbaren Informationen individueller Entwurfsphasen angepasst werden können. Wir untersuchen die Integration abstrakter RTOS-Simulation in den AUTOSAR-basierten Entwurfsprozess. Unter Berücksichtigung der in der Automobilbranche üblichen Hersteller- Zulieferer-Beziehung haben wir eine konfigurierbare Simulation in die Werkzeugkette der AUTOSAR-Entwicklungsumgebung dspace SystemDesk prototypisch integriert. Unsere Simulation analysiert das Zeitverhalten mit einem Fehler von maximal 8%. Dabei ist die Simulation deutlich schneller als Echtzeitausführung und lediglich um den Faktor 10 langsamer als eine rein funktionale Simulation (Nullzeitsimulation). 1 Einleitung Die Wertschöpfung durch zusätzliche Sicherheits- und Komfortfunktionen in Fahrzeugen, wie beispielsweise Antiblockiersystem (ABS), elektronisches Stabilitätsprogramm (ESP) oder Fahrerassistenzsysteme, ist für Automobilhersteller von entscheidender wirtschaftlicher Bedeutung. Zunehmende Auflagen zum Umweltschutz erfordern immer aufwändigere Steuerelektronik für effizientere Antriebe zur Abgasminderung. Automobilhersteller sind daher bestrebt, die Sicherheit, den Komfort und die Umweltverträglichkeit von Fahrzeugen mit Hilfe innovativer E/E-Systeme (Electrical/Electronic) zu verbessern. Dadurch hat die Komplexität eingebetteter Systeme im Automobilbereich stark zugenommen. Die Aufwendungen für die Softwareentwicklung eines Fahrzeugs sind im Verhältnis zu den gesamten Entwicklungskosten überproportional gestiegen. Einem Artikel der Fachzeitschrift Elektronik Automotive [10] zufolge ist gleichzeitig ein teilweiser Qualitätsverlust bei der Entwicklung eingebetteter Systeme zu beobachten. So ist es nicht selten, dass einzelne Systeme bis zu entdeckte Fehler aufweisen, die häufig nach der Auslieferung durch teure Software- Updates behoben werden müssen. Allein 15% aller Systeme wiesen dabei Fehler auf, die auf Timing- und Parallelitätsprobleme zurück zu führen sind (siehe Abbildung 1).

2 Industrie und Wissenschaft versuchen, die steigende Komplexität mit modellbasiertem Entwurf, rechnergestützten Entwicklungswerkzeugen und Standardisierungsinitiativen zu beherrschen. Beispiele hierfür sind die AUTOSAR-Initiative (Automotive Open System Architecture) [1] und das Systemintegrationswerkzeug SystemDesk der dspace GmbH [2]. Entscheidend ist hierbei, den Ressourcenaufwand für Fehlersuche und -beseitigung durch einen strukturierten Entwicklungsprozess zu minimieren, indem Fehler möglichst vermieden oder frühzeitig entdeckt werden. So können mehr Ressourcen auf die Entwicklung von Innovationen verwendet werden. Hersteller können ihren Wettbewerbsvorteil durch geringere Entwicklungskosten und kürzere Markteinführungszeiten erhöhen. Handwerk 37% OS und Framework 4% andere Komponenten 6% Integrationsfehler 6% kein Fehler 8% Spezifikation 11% Timing und Parallelität 15% Performance- Beanstandungen 13% Abbildung 1: Fehlerstatistik elektronischer Systeme in Fahrzeugen (Quelle: [10]) Offline-Simulationen, das heißt rein virtuelle Simulationsmodelle ohne Anbindung an reale Hardware, ermöglichen eine frühe Verifikation von Systementwürfen. Instruction-Set-Simulatoren (ISS) [4] können hierbei Eigenschaften zyklengenau abbilden, erfordern jedoch exakte Informationen über alle Systemkomponenten. In der Praxis stehen diese dem Entwickler aufgrund des Schutzes von geistigem Eigentum oder branchenüblichen Prozessen nur teilweise zur Verfügung. Zudem ist der Anpassungsaufwand neuer Zielplattformen hoch und die Simulation langsam. Gängige Entwurfswerkzeuge beschränken sich daher oft auf rein funktionale Simulationen ohne Ausführungszeiten, die geringere Kenntnisse über die Zielplattform erfordern aber keine Timing-Fehler analysieren. Diese frühzeitig zu erkennen, ist besonders bei dem Entwurf sicherheitskritischer Echtzeitsysteme im Automobilbereich von hohem Interesse. Abstrakte Modelle bieten einen Kompromiss zwischen Simulationsgenauigkeit und Detailgrad des Modells. So kann praxisnah und bedarfsgerecht in den Phasen spezieller Entwurfsprozesse simuliert werden. Wir stellen ein System zur schnellen abstrakten RTOS-Simulation (Real Time Operating System) und dessen Integration in die AUTOSAR-basierte Werkzeugkette vor. Unter Berücksichtigung der in der Automobilbranche üblichen Hersteller-Zulieferer-Beziehung haben wir eine konfigurierbare Simulation in die Werkzeugkette der AUTOSAR-Entwicklungsumgebung SystemDesk von dspace prototypisch integriert. Unsere Simulation analysiert das Zeitverhalten mit einem Fehler von maximal 8% und ist dabei verglichen mit der realen Laufzeit des Systems deutlich schneller und lediglich um den Faktor 10 langsamer als eine rein funktionale Simulation (Nullzeitsimulation). Der Rest des Artikels gliedert sich wie folgt. Abschnitt 2 beschreibt den Stand der Technik in der Offline-Simulation. Abschnitt 3 beschreibt unseren Ansatz zur Integration abstrakter RTOS- Simulation mit Zeitverhalten in die Entwurfsmethodik von AUTOSAR. In Abschnitt 4 folgt eine Evaluierung der abstrakten RTOS-Simulation anhand der AUTOSAR-Werkzeugkette von dspace SystemDesk. In Abschnitt 5 fassen wir unsere Ergebnisse zusammen und geben einen Ausblick für weitere Verbesserungen.

3 2 Offline-Simulation Offline-Simulationen sind rein virtuelle Simulationsmodelle, die auf die Integration realer Systemkomponenten, bspw. Evaluierungshardware, verzichten. So kann das Verhalten eines Systementwurfs, zeitlich entkoppelt von Realzeit, an einem leistungsfähigen Host-PC überprüft werden. Verglichen mit der Simulation durch Hardware-Prototypen ist der Aufwand dabei verhältnismäßig gering. Die Instruction-Set-Simulation (ISS) bildet zurzeit das genaueste Offline- Verfahren, indem die Zielplattform detailgetreu an einem Host-PC nachgebildet wird und dadurch der Original-Produktionscode für die Zielplattform realistisch simuliert werden kann. Durch exakte Pipeline- und Cache-Modelle kann die ISS nicht nur funktionale Eigenschaften, sondern auch das Zeitverhalten zyklengenau simulieren. So können Ausführungszeiten und Unterbrechungseffekte analysiert werden. Timing-Probleme, wie etwa Zeitüberschreitungen durch zu hohe Antwortzeiten oder Ein- bzw. Ausgabefehler durch Jitter-Effekte, können bereits in der Offline-Simulation entdeckt werden (siehe Abbildung 2 links). Instruction-Set-Simulation Nullzeitsimulation Abbildung 2: Präzises Prozess-Scheduling mit Ausführungszeiten und Unterbrechungen in der Instruction- Set-Simulation gegenüber vereinfachter Nullzeitsimulation ohne Ausführungszeiten Trotz der hohen Genauigkeit der ISS ist diese für den Praxiseinsatz nur bedingt tauglich. Der hohe Detailgrad der Simulationsmodelle erfordert Kenntnisse, die dem Entwickler, aufgrund des Schutzes geistigen Eigentums, oder aber des rasanten Technologiefortschritts nicht oder nur unvollständig zur Verfügung stehen. Darüber hinaus ist der Zeit- und Kostenaufwand für die Anpassung der Modelle für neue Zielplattformen groß. In vielen Entwicklungswerkzeugen hat sich daher die vereinfachende Offline-Simulation mit so genannter Nullzeitannahme durchgesetzt. Dabei wird der Simulations-Code unter Verwendung des Host-Compilers für den Host-PC übersetzt und direkt durch diesen ausgeführt. Durch die Unterschiede zwischen Host- und Zielplattform, wie beispielsweise Befehlssatz der CPU, verwendeter Compiler, verfügbare Ressourcen oder spezielle Peripherie, lassen sich dabei keine Rückschlüsse auf das Zeitverhalten der Zielplattform am Host- PC ziehen. Grob vereinfachend werden daher zwar Zeitpunkte, wie die Aktivierung von Prozessen oder das Auftreten externer Ereignisse, in der korrekten Reihenfolge abgebildet, die Ausführungszeiten der Prozesse werden aber durch Null idealisiert (siehe Abbildung 2 rechts). Der Simulationsaufwand kann durch diese Abstraktion erheblich reduziert werden, jedoch müssen auch Einschränkungen in der Analysierbarkeit von Scheduling-Effekten gegenüber der ISS in Kauf genommen werden. Ein Beispiel für Nullzeitsimulation ist die integrierte Offline-Simulation in dspace SystemDesk.

4 Ein weiteres Konzept zur Offline-Simulation stellen abstrakte Simulationsmodelle dar. Anstatt Systementwürfe möglichst genau am Host-PC abzubilden, konzentrieren sich abstrakte Modelle auf die Simulation des Verhaltens. Dabei wird durch Abstraktion einzelner Systemkomponenten der Modellierungsaufwand reduziert und die Simulationsgeschwindigkeit erhöht. Neben Ansätzen zur abstrakten Bus-Modellierung, wie etwa dem Transaction-Level-Modelling (TLM), gewinnen auch abstrakte RTOS-Modelle zunehmend an Bedeutung. Diese simulieren das Verhalten konkreter Echtzeitbetriebssysteme, wie beispielsweise das Prozess-Scheduling, und stellen die Programmierschnittstelle des Betriebssystems (Application Programming Interface, API) für den zu simulierenden Anwendungs-Code bereit. Die darunter liegende Hardware und hardwarenahe Systemsoftware werden abstrahiert. Durch Anreicherung der RTOS-Modelle mit zuvor gewonnnen Informationen, wie beispielsweise Ausführungszeiten, oder durch Integration stochastischer Modelle, lassen sich hinreichend genaue Zeitanalysen durchführen. Die Beschleunigung von RTOS-Simulationen sind seit einigen Jahren Untersuchungsgegenstand im Bereich des Entwurfs von Systems-on-Chip und eingebetteten Systemen [5]. In den letzten Jahren wurden abstrakte Konzepte zur zeitannotierten Simulation von Scheduling-Effekten eingeführt. Gerstlauer et al. [6] haben diese Konzepte auf Basis von SpecC umgesetzt. Andere Ansätze, wie der von Huss et al. [7], verwenden SystemC und erlauben die Implementierung eigener Scheduler. Im Gegensatz zu kanonischen RTOS-Modellen haben Posadas et al. [8] ein RTOS-Modell für die API des POSIX-Standards vorgestellt. Destro et al. [9] haben wiederum abstrakte Schnittstellen nach POSIX abgebildet. Unsere abstrakte RTOS-Bibliothek ist in SystemC implementiert [3] und basiert auf dem kanonischen RTOS-Modell von Gerstlauer et al. [6]. Hinsichtlich der Unterbrechbarkeit der Zeitintervalle werden diese um die Konzepte von Posadas et al. [8] erweitert. Unsere RTOS- Bibliothek bietet darüber hinaus die Möglichkeit zur getrennten Modellierung von Task- und Interrupt-Scheduling. Dadurch erreichen wir eine funktional korrekte Simulation des hardwareabhängigen Interrupt-Scheduling [11] und somit eine erhöhte Genauigkeit. Andere Ansätze beschränken sich darauf, Interrupts als hoch priorisierte Tasks abzubilden, wodurch das hardwareabhängige Scheduling aber nur unzureichend modelliert wird. In diesem Artikel zeigen wir, dass unsere RTOS-Simulationsbibliothek effizient für den industriellen Entwurf automobiler Softwaresysteme eingesetzt und in den AUTOSAR-basierten Entwurfsprozess einfach integriert werden kann. Die Automatisierung der Integration kann mittels einer XML-Beschreibung vollzogen werden. 3 Abstrakte RTOS-Simulation im AUTOSAR-Entwurf AUTOSAR [1] ist eine Standardisierungsinitiative für den Systementwurf im Automobilbau. Sie setzt sich aus Herstellern und Zulieferern der Automobilindustrie, wie beispielsweise BMW, Bosch, Continental, Daimler oder Volkswagen, zusammen. AUTOSAR existiert seit 2003 und die Mitgliederzahl ist mittlerweile auf über 100 Industriepartner angestiegen. Ziel ist es, die steigende Komplexität eingebetteter Systeme im Automobil zu beherrschen, sodass die Qualität gesichert und die Entwicklungskosten gesenkt werden können.

5 Abbildung 3: Entwurfsmethodik von AUTOSAR (Quelle: [1]) Die Kernkonzepte von AUTOSAR sind zum einen eine Entwurfsmethodik, die ein Metamodell zur unabhängigen Beschreibung einer komponentenbasierten Softwarearchitektur, einer Hardware- Topologie und einer Netzwerkkommunikation definiert. Diese werden in einem Systemintegrationsschritt auf die Konfigurationen vernetzter Steuergeräte (Electronic Control Unit, ECU) abgebildet (siehe Abbildung 3). Zum anderen umfasst AUTOSAR eine Referenzarchitektur für die ECU-Software (siehe Abbildung 4). Diese spezifiziert durch die RTE-Middleware (Runtime-Environment) eine Abstraktionsschicht, wodurch Anwendung und hardwarenahe Systemsoftware getrennt werden. Abbildung 4: Referenzarchitektur für AUTOSAR-ECUs (Quelle: [1]) Dadurch wird eine Integration von Softwarebausteinen (Software Component, SWC) in ein System erleichtert und die Portabilität der SWCs zwischen verschiedenen Zielplattformen erhöht. Durch standardisierte Schnittstellen werden sowohl Module der ECU-Basissoftware (BSW) als auch Anwendungskomponenten austauschbar und wieder verwendbar. Durch diese Eigenschaft unterstützt AUTOSAR besonders den in der Automobilbranche üblichen Prozess zwischen Zulieferer und Automobilhersteller. Dabei ist es üblich, dass ein Automobilhersteller generische COTS-Module (Components-Off-the-Shelf) von Zulieferern einkauft, um auf dieser Basis ein eigenes Produkt zu integrieren.

6 Unser abstraktes RTOS-Modell ist als Erweiterung von SystemC realisiert [3]. SystemC ist eine C- basierte Beschreibungssprache zur Co-Simulation von kombinierten HW/SW-Systemen. Die freie Implementierung der Open SystemC Initiative (OSCI) existiert als eine Klassenbibliothek mit einem Simulationskern für C++. Das abstrakte RTOS-Modell bietet Module zur Modellierung von CPU, Scheduler, Tasks, Interrupt-Service-Routinen (ISR), Events und Semaphoren. Durch Spezialisierung können die Module für eine Betriebssystemimplementierung angepasst werden. Für die Integration in AUTOSAR haben wir eine Teilmenge von AUTOSAR-OS auf das abstrakte RTOS-Modell abgebildet und kontrollieren die Simulation der ECU-Software durch Prozesse des RTOS-Modells. Zur zeitgenauen Simulation bildet die Funktion CONSUME_CPU_TIME() des RTOS-Modells den Zeitverbrauch der ECU-Software auf SystemC wait()-statements ab. Um den Zeitverbrauch der unterschiedlichen Ausführungspfade zu modellieren, wird die Software zunächst auf Ebene linearer Basisblöcke segmentiert. Abbildung 5 zeigt das Prinzip der Segmentierung und Zeitannotierung der ECU-Software am Beispiel einer Funktion in C-Code. Jeder Ausführungszweig des C-Codes wird dazu mit einem unterscheidbaren Makro instrumentiert, das wir Checkpoint-Makro nennen. Die resultierenden Teilpfade zwischen den Checkpoints werden im Maschinen-Code durch lineare Code-Segmente realisiert, die keine Sprünge enthalten. Abgesehen von dem Einfluss durch Pipelines und Caches weisen sie daher ein deterministisches Zeitverhalten auf und können für die jeweilige Zielplattform durch Messungen oder Analysen ermittelt werden. Die Checkpoint-Makros spannen einen gerichteten Graphen über den C-Code auf, wobei jeder Knoten einem Checkpoint und jede Kante der Ausführung eines linearen Maschinen-Code-Segmentes zwischen zwei Checkpoints entspricht. Die Kanten im Graph werden mit zuvor ermittelten Kosten für den Zeitverbrauch der Maschinen-Code-Segmente annotiert. So können die Kosten der Ausführungszweige für die zeitgenaue RTOS-Simulation zur Laufzeit feingranular akkumuliert und durch Aufruf von CONSUME_CPU_TIME() für die Abbildung der Prozesslaufzeiten im RTOS- Modell angerechnet werden. Abbildung 5: Zeitannotierung segmentierter ECU-Software für die zeitgenaue RTOS-Simulation

7 Das RTOS-Modell sequentialisiert die Simulation der Prozesse gemäß der Scheduler- Implementierung (siehe Abbildung 6). Im Fall von AUTOSAR-OS handelt es sich dabei um einen präemptiven Prioritäten-Scheduler mit statischer Prioritätenzuweisung. Der Scheduler überprüft innerhalb eines Aufrufs von CONSUME_CPU_TIME(), ob während des Inkrementierens der Simulationszeit eine Unterbrechung durch die Aktivierung eines höher priorisierten Prozesses, beispielsweise einer ISR, stattfindet. An dieser Stelle wird zwar das Zeitintervall geteilt, nicht aber die Ausführung des aktuellen Code-Segmentes unterbrochen. Dadurch wird eine performante Simulation möglich, wobei das Zeitverhalten der Prozesse im Schedule korrekt abgebildet wird. Durch Modellierung der Kommunikationspunkte in eigenen Code-Segmenten garantieren wir die richtige Reihenfolge der Datenzugriffe und stellen somit eine funktional korrekte Simulation sicher. In AUTOSAR wird jede Art von Kommunikation über das Runtime-Environment realisiert. Segmente starten oder enden in unserer Simulation daher spätestens an dieser Schnittstelle. Priority Periodic Task A Periodic Task B Time split interval RTOS Schedule Time Abbildung 6: Prozesssequentialisierung paralleler Prozesse durch das RTOS-Modell Für die zeitgenaue Verifikation von AUTOSAR-Systementwürfen mittels abstrakter RTOS- Simulation schlagen wir eine Erweiterung des Entwurfsprozesses vor (siehe Abbildung 7). Dabei unterstützen wir unabhängige Softwarekomponenten- und Systementwicklung, indem der Komponenten-Code eigenständig segmentiert und analysiert wird. So kann der Komponentenentwickler die Ausführungszeiten seiner Komponenten für verschiedene Zielplattformen bereitstellen. Diese können von Systementwicklern für die zeitgenaue Verifikation des Systementwurfs mit einer abstrakten RTOS-Simulation verwendet werden. Die gewonnenen Kenntnisse über das Zeitverhalten unterstützen den Systementwickler für eine iterative Entwurfsraumexploration. So können bereits frühzeitig und mit geringem Aufwand die Auswirkungen von Entwurfsentscheidungen auf die Timing-Eigenschaften des Systems evaluiert werden.

8 Component development System development System verification AUTOSAR SWC development System modeling Software architecture Hardware topology Network comm. SWC code segmentation System integration System Execution time estimation System integration AUTOSAR RTE segmentation RTE execution time estimation Configuration e.g. component supplier, component development depart. e.g. car manufacturer, system development depart. Abstract RTOS simulation Abbildung 7: Entwurfsraumexploration im erweiterten AUTOSAR-Entwurf mit abstrakter RTOS-Simulation 4 Implementierung und Evaluierung Für die Evaluierung der Methodik haben wir unsere abstrakte RTOS-Bibliothek prototypisch in die Werkzeugkette der AUTOSAR-Entwicklungsumgebung (Integrated Development Environment, IDE) dspace SystemDesk integriert. Dazu haben wir unsere abstrakte RTOS-Bibliothek zu einer konkreten AUTOSAR-ECU-Bibliothek erweitert. Auf dieser Basis haben wir eine SystemC- Simulation für Windows mit einer XML-Konfigurationsschnittstelle implementiert. Die Checkpoints zur Instrumentierung der ECU-Software haben wir mit der Code- Überdeckungsanalyse von dspace TargetLink platziert. Die segmentierte ECU-Software laden wir als DLL (Dynamic Link Library) in unsere RTOS-Simulation. Die Ausführungszeiten haben wir durch Messungen auf einem Infineon C167-Evaluierungsboard ermittelt. Abbildung 8 zeigt unsere prototypische Werkzeugkette für die zeitgenaue RTOS-Simulation.

9 AUTOSAR IDE System Integration Component Development ECU RTOS Config <XML> segmented ECU-Software <DLL> Component Library Execution Time Estimation SWC A Timing Graph <XML> Config <XML> Simulator <win32> SWC B Timing Graph <XML> SystemC RTOS model ECU model <libraries> Abbildung 8: Prototypische Integration der abstrakten RTOS-Simulation in eine AUTOSAR-IDE Zur Evaluierung unserer prototypischen Werkzeugkette verwenden wir das AUTOSAR-Modell eines fehlertoleranten Einspritzreglers für einen Verbrennungsmotor ( Fuelsys-ECU ). Abbildung 9 zeigt einen Auszug aus der dazugehörigen XML-Konfiguration für unsere Simulation. Die Ergebnisse zeigen, dass wir das Zeitverhalten der ECU-Software mit einem maximalen Fehler von 8% abbilden können. Die zeitgenaue Simulation von 100 Sekunden Simulationszeit benötigt auf einem Intel Core-2-Duo mit 3 GHz und 3 GB RAM 16 Sekunden Realzeit. Die funktionale Nullzeitsimulation mit dspace SystemDesk benötigt für das gleiche Modell 2 Sekunden. 1 <ecu> 2 <identifier>fuelsys_ecu</identifier> 3 <class>sc_autosar_ecu</class> <ecu_task_scheduler> 6 <identifier>task_scheduler</identifier> 7 <class>sc_autosar_ecu_scheduler</class> 8 <library>sc_autosar_ecu_model.dll</library> 9 </ecu_task_scheduler> 10 <ecu_isr_scheduler> </ecu_isr_scheduler> 13 <ecu_task> 14 <identifier>fuelsys_sensor_task_10ms</identifier> 15 <class>sc_autosar_ecu_task</class> 16 <library>sc_autosar_ecu_model.dll</library> 17 <has_scheduler>task_scheduler</has_scheduler> 18 <period>10ms</period> 19 <priority>2</priority> 20 <task_code>fuelsys_ecu.dll::fuelsyssensortask()</task_code> 21 </ecu_task> <ecu_signal> 24 <identifier>engine_model_fuel_rate</identifier> 25 <class>sc_autosar_ecu_signal</class> 26 <library>sc_autosar_ecu_model.dll</library> 27 <datatype>uint16</datatype> Konfiguration eines Task-Scheduler, der in einer benutzerdefinierten DLL implementiert ist. Konfiguration einer periodischen RTOS- Task, in der die Funktion FuelsysSensorTask() ausgeführt wird. Konfiguration eines aufzuzeichnenden Signals.

10 28 <has_tracer>vcd_signal_tracer</has_tracer> 29 <address>0x00ad518c</address> 30 </ecu_signal> 31 </ecu> Abbildung 9: Auszug aus der Konfiguration für das Simulationsmodell Fuelsys-ECU 5 Zusammenfassung und Ausblick In diesem Artikel stellten wir ein Verfahren zur effizienten Offline-Simulation von Scheduling- Effekten in Echtzeitsystemen und dessen Integration in den Entwurf von AUTOSAR vor. Anhand einer prototypischen Anbindung an die AUTOSAR-Werkzeugkette von dspace haben wir unseren Ansatz evaluiert. Durch Instrumentierung der simulierten ECU-Software mit Zeitannotationen können wir eine AUTOSAR-ECU zeitgenau simulieren. Die Integration der ECU-Software in unser abstraktes RTOS-Modell wird durch eine XML-Konfiguration automatisiert. Unsere Ergebnisse haben gezeigt, dass die abstrakte RTOS-Simulation deutlich schneller ist als die Echtzeitausführung des Systems bei einer Ungenauigkeit von maximal 8%. Dabei sind wir lediglich um den Faktor 10 langsamer als eine Nullzeitsimulation. Jüngste Ergebnisse haben gezeigt, dass die Genauigkeit durchschnittlich auf bis zu 2% gesteigert werden kann. Weitere momentane Arbeiten betrachten die effiziente Simulation von FlexRay-Netzwerken auf der Basis von TLM-Abstraktionen. Danksagungen Die beschriebenen Arbeiten wurden durch das BMBF im Rahmen des ITEA2-Projektes TIMMO (ID 01IS07002) und durch die EU im Rahmen von COCONUT (Grant Agreement No ) gefördert. Literatur [1] AUTOSAR Homepage. [2] dspace Homepage. [3] OSCI SystemC Homepage. [4] A.Nohl, G.Braun, O.Schliebusch, R.Leupers, H.Meyr, and A.Hoffmann.. A Universal Technique for Fast and Flexible Instruction-Set Architecture Simulation. In DAC'02: Proceedings of Design Automation Conference, [5] D.Desmet, D.Verkest, and H.DeMan. Operating System based Software Generation for Systems-on-Chip. In DAC'00: Design Automation Conference, [6] A.Gerstlauer, H.Yu, and D.Gajski. RTOS Modeling for System Level Design. In DATE'03: Design, Automation and Test in Europe, [7] S.A. Huss and S.Klaus. Assessment of Real-Time Operating Systems Characteristics in Embedded Systems Design by SystemC Models of RTOS Services. In DVCon 07: Design and Verification Conference and Exhibitation, San Jose, CA, [8] H.Posadas, J.A. Adamez, E.Villar, F.Blasco, and F.Escuder. RTOS modeling in SystemC for real-time embedded SW simulation: A POSIX Model. Design Automation for Embedded Systems, 10(4): , December [9] P.Destro, F.Fummi, and G.Pravadelli. A Smooth Refinement Flow for Co-Designing HW and SW Threads. In DATE'07: Proceedings of Design, Automation and Test in Europe, New York, NY, USA, IEEE Computer Society. [10] Wietzke, Joachim: Embedded Systeme, embedded Probleme Zunehmender Qualitätsverlust bei der Entwicklung eingebetteter Systeme. In: Elektronik Automotive 1 (2007), S [11] H. Zabel, W. Mueller, A. Gerstlauer. Accurate RTOS Modelling and Analysis with SystemC. In: W. Ecker, W. Mueller, R. Doemer (eds.) "Hardware Dependent Software - Principles and Practice", Springer Verlag, Dordrecht, January 2009.