Integration abstrakter RTOS-Simulation in den Entwurf eingebetteter

Integration abstrakter RTOS-Simulation in den Entwurf
eingebetteter automobiler E/E-Systeme
Markus Becker, Henning Zabel, Wolfgang Müller
Ulrich Kiffmeier
Universität Paderborn, C-LAB
Fürstenallee 11
33102 Paderborn
{beckerm, henning, wolfgang}@c-lab.de
dSPACE GmbH
Technologiepark 25
33100 Paderborn
[email protected]
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 HerstellerZulieferer-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 20.000 entdeckte Fehler aufweisen, die häufig nach der Auslieferung durch teure SoftwareUpdates 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).
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.
OS und Framework 4%
andere Komponenten 6%
Handwerk 37%
Integrationsfehler 6%
kein Fehler 8%
Spezifikation 11%
PerformanceBeanstandungen 13%
Timing und Parallelität 15%
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 RTOSSimulation 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.
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 OfflineVerfahren, 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 InstructionSet-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 HostPC 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.
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 RTOSBibliothek 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.
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 HardwareTopologie 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.
Unser abstraktes RTOS-Modell ist als Erweiterung von SystemC realisiert [3]. SystemC ist eine Cbasierte 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 RTOSModell angerechnet werden.
Abbildung 5: Zeitannotierung segmentierter ECU-Software für die zeitgenaue RTOS-Simulation
Das RTOS-Modell sequentialisiert die Simulation der Prozesse gemäß der SchedulerImplementierung (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 RTOSSimulation 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.
Component development
System development
AUTOSAR SWC
development
Software
System
modeling architecture
System
integration
SWC code
segmentation
Execution time
estimation
System verification
Hardware
topology
Network
comm.
System
System integration
AUTOSAR RTE
segmentation
RTE execution time
estimation
Configuration
Abstract
RTOS simulation
e.g. component supplier,
component development depart.
e.g. car manufacturer,
system development depart.
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 SystemCSimulation 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.
AUTOSAR
IDE
System
Integration
segmented
ECU-Software
Component
Development
<DLL>
ECU
RTOS
Config
<XML>
Component
Library
Execution
Time Estimation
SWC A
Timing
Graph
Simulator
Config
<win32>
<XML>
<XML>
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>
Konfiguration eines
3
<class>sc_autosar_ecu</class>
Task-Scheduler, der in
4
...
einer benutzerdefinierten
5
<ecu_task_scheduler>
DLL implementiert ist.
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>
Konfiguration einer
11
...
periodischen RTOS12
</ecu_isr_scheduler>
Task, in der die Funktion
13
<ecu_task>
FuelsysSensorTask()
14
<identifier>FUELSYS_SENSOR_TASK_10MS</identifier>
15
<class>sc_autosar_ecu_task</class>
ausgeführt wird.
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>
Konfiguration eines auf22
...
23
<ecu_signal>
zuzeichnenden Signals.
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>
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 SchedulingEffekten 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. 217069)
gefördert.
Literatur
[1]
[2]
[3]
[4]
AUTOSAR Homepage. www.autosar.org
dSPACE Homepage. www.dspace.de
OSCI SystemC Homepage. www.systemc.org
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,
2002.
[5] D.Desmet, D.Verkest, and H.DeMan. Operating System based Software Generation for Systems-on-Chip. In
DAC'00: Design Automation Conference, 2000.
[6] A.Gerstlauer, H.Yu, and D.Gajski. RTOS Modeling for System Level Design. In DATE'03: Design,
Automation and Test in Europe, 2003.
[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, 2007.
[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):209--227,
December 2005.
[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, 2007. IEEE
Computer Society.
[10] Wietzke, Joachim: Embedded Systeme, embedded Probleme – Zunehmender Qualitätsverlust bei der
Entwicklung eingebetteter Systeme. In: Elektronik Automotive 1 (2007), S. 63–67
[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.