AUTOSAR und Echtzeit. Andreas Weinmann

Transkript

1 Seminar Sommersemester 2013: Automobile Systeme in der Automatisierung Prof. Dr. Dieter Zöbel, Universität Koblenz-Landau, FB Informatik AUTOSAR und Echtzeit Andreas Weinmann Eingereicht: / Fertiggestellt: Zusammenfassung Die Automobilindustrie hat im Jahr 2003 AUTOSAR (AUTomotive Open System ARchitecture) ins Leben gerufen. Ziel ist eine Senkung der Komplexität und Kosten im Software- sowie Hardware-Entwicklungsprozess für Automobile. Die Modellierung von zeitlichen Anforderungen nimmt in der Automobilindustrie eine stetig wichtigere Stellung ein. Die vorliegende Arbeit vermittelt einen Einblick in den Bereich der Timing-Modellierung mit AUTOSAR. Dabei wird auf die Projekte TIMMO und TIMMO-2-USE sowie die im AUTOSAR Standard integrierte Timing-Erweiterung TIMEX eingegangen. Der Fokus dieser Arbeit liegt dabei auf der Timing-Modellierung mit TIMEX. Schlüsselwörter AUTOSAR TIMEX, TIMMO, TIMMO-2-USE, AUTOSAR Timing 1 Einleitung Die Automobilindustrie besteht aus einer Vielzahl von Automobilherstellern, die jeweils viele verschiedene Plattformen anbieten, sowie aus vielen Zulieferern (Abb. 1). Mit dem Wunsch nach einfacher Austauschbarkeit und Produktivitätssteigerung innerhalb dieser Industrie wurde AUTOSAR ins Leben gerufen. AUTOSAR ermöglicht dies durch eine einheitliche Spezifikation einer Software-Architektur. Der Konkurrenzkampf wird damit auf die Implementierungsebene verschoben. Da Anwendungen innerhalb eines Automobils oft Echtzeitanwendungen sind und somit zeitliche Anforderungen an das System stellen, ist es unumgänglich diese Anforderungen mit in den Entwicklungsprozess zu integrieren. Durch die verteilte Entwicklung der Software für ein Automobil, ist eine einheitliche Formulierung von zeitlichen Anforderungen nötig. Die Integration von Timing-Modellierung in den AUTOSAR Standard ermöglicht dies. Im Folgenden wird zuerst kurz AUTOSAR im Allgemeinen vorgestellt und daraufhin wird auf die verschiedenen Möglichkeiten zur Modellierung von zeitlichen Anforderungen innerhalb von AUTOSAR genauer eingegangen. Universität Koblenz-Landau, Institut für Informatik andyw@uni-koblenz.de

2 2 A. Weinmann Abb. 1 Austauschbarkeit mittels AUTOSAR ( info/magazine/2007/vol 0071/vol gif) 2 AUTOSAR AUTOSAR, kurz für Automotive Open System Architecture, bietet eine offene und standardisierte Software-Architektur, die gemeinsam von einer Allianz aus Automobilherstellern und Zulieferern entworfen wurde. Die Basis von AUTOSAR ist ein Komponentenmodell sowie eine Drei-Schichten-Software-Architektur. Ziel von AUTOSAR ist es, mittels standardisierter Interfaces, auf allen Schichten der Software-Architektur eine korrekte Kommunikation zwischen verschiedenen Komponenten verschiedener Hersteller innerhalb eines Automobilsoftwaresystems zu ermöglichen. Dazu bietet AUTO- SAR ein standardisiertes, auf XML basierendes Datenaustauschformat. Des Weiteren definiert AUTOSAR eine Methodologie, die während des kompletten Software- Erstellungsprozess die Entwickler unterstützt. [2][4] Die Software-Architektur (Abb. 2) besteht aus der Anwendungssoftwareschicht, der Laufzeitumgebung sowie Basis-Software-Modulen. Wie in Abb. 2 zu sehen, stellt die Laufzeitumgebung (RTE) eine Schicht zwischen der Hardware unabhängigen Anwendungsschicht (AUTOSAR Software) sowie den Hardware abhängigen Basis-Software- Modulen (Basis Software) dar und ermöglicht die Kommunikation zwischen diesen beiden Schichten. Mittels dieser Architektur ist es möglich, Anwendungssoftware zu erstellen, ohne auf die darunterliegenden Hardwareelemente Rücksicht zu nehmen, da jegliche Kommunikation mit der Hardware über die Laufzeitumgebung stattfindet. Durch die standardisierten Interfaces kann eine Anwendungssoftware sehr einfach ersetzt werden. Im gleichen Zuge ist es ebenso einfach möglich, Hardwarekomponenten auszutauschen, ohne dass Anpassungen an den Anwendungen nötig sind. Dies ermöglicht die verteilte Entwicklung von Teilsystemen, die später zu einem Komplettsystem kombiniert werden. Einzelne Zulieferer können ihre Systeme für alle Automobilhersteller anbieten und Automobilhersteller können Zuliefersysteme einfach austauschen. [2][4]

3 AUTOSAR und Echtzeit 3 Abb. 2 AUTOSAR Software-Architektur [1] 3 Timing Modellierung Die immer weiter steigende Funktionalität in aktuellen Automobilen führt zu einem rasanten Anstieg der in einem Automobil verbauten Elektronik und Softwarekomponenten. Dies hat zur Folge, dass sich immer größere Wirkketten bilden. Da gerade in einem Automobil viele Anwendungen Echtzeitanwendungen sind, ist es essentiell, dass zeitliche Anforderungen an die Ausführung gestellt werden. Eine Modellierung von zeitlichen Anforderungen, im Folgenden auch als Timing bezeichnet, ist somit unumgänglich. Die Kernelemente bei der Modellierung und Analyse von Timing lassen sich in drei Teile aufteilen. Zum einen das Timing der Softwareausführung, also wie lange eine Software benötigt, um zu einem Ergebnis zu kommen. Des Weiteren das Zeitverhalten von Events, das die Häufigkeit des Auftretens eines Ereignisses beschreibt. Das dritte Kernelement ist das Timing von Abhängigkeiten und Wirkketten. Dies beschreibt die Dauer, bis ein gewünschtes Ereignis auftritt.[5] Im Folgenden werden verschiedene Projekte zur Timing Modellierung mit AUTO- SAR vorgestellt, zuerst wird auf das TIMMO Projekt 1 eingegangen. Darauf folgt eine kurze Vorstellung des Nachfolgeprojekts TIMMO-2-USE 2. Im Anschluss daran wird

4 4 A. Weinmann ausführlich auf die, mit der AUTOSAR Version 4.0 in den AUTOSAR Standard integrierte AUTOSAR Timing Extension 3, kurz AUTOSAR TIMEX, eingegangen. 3.1 TIMMO-Projekt Das von dem Information Technology for European Advancement (ITEA2) geförderte TIMMO (TIMing MOdel) Projekt, bietet eine Timing-Erweiterung für AU- TOSAR. Dazu kombiniert TIMMO AUTOSAR mit EAST-ADL2 4 und ermöglicht somit ein Timing-Konstrukt auf Metamodell-Ebene. TIMMO bietet einen formalen und standardisierten Ansatz zur Erfassung und zum Umgang mit Timing. Dazu definiert TIMMO die Sprache TADL 5 sowie eine Methodologie. [4][8] Abb. 3 TIMMO Event Chain Element [4] TADL Die Kernelemente von TADL sind Event Constraints sowie Event Chains. Mittels Event Constraints kann in TADL das Zeitverhalten von Events spezifiziert werden. Event Chains (Abb.3) erlauben die Angabe von Zeitinformationen für Wirkketten über mehrere Komponenten. Dabei besteht ein Event Chain Element aus der Dauer T, der Abtastperiode Tr in der Daten gelesen werden, der Abtastperiode Tw in der Daten geschrieben werden und die Verzögerung d zwischen Stimulus und Reaktion. Hiermit ist es möglich verschiedene End-to-End Constraints zu modellieren. Zum einen ein Reaction Constraint, der die Reaktionszeit zwischen Eingabe und Ausgabe beschreibt, oder ein Age Constraint, der das Alter von Daten definiert. In Abb. 4 ist beispielhaft die Anwendung von Event Chains auf ein Bremssystem zu sehen. [4][5][6][8] TIMMO Methodologie Die Methodologie von TIMMO ermöglicht eine semantische, präzise Beschreibung zeitlicher Anforderungen. Dazu dient SPEM 6 als Metamodell. SPEM dient auch AUTO- SAR als Metamodell und ist eine Teilmenge von UML zur Modellierung von Prozessen Electronics Architecture and Software Technology - Architecture Description Language 5 Timing Augmented Description Language 6 Software Process Engineering Meta-model

5 AUTOSAR und Echtzeit 5 Abb. 4 TIMMO Event Chain Beispiel: Die Betätigung des Bremspedals löst ein Event aus. Dieses Event ist der Stimulus der EventChain A, die Reaktion entspricht dem Event das beim Breake Controller ankommt. EventChain B ist analog zu EventChain A [5] und Prozessfamilien. Fokus der TIMMO Methodologie liegt auf der Timing-Analyse während der Entwicklung. Dazu wird ein Top-Down-Ansatz verwendet, der Zeitbudgets auf das darunterliegende Abstraktionslevel aufteilt. Das Hauptanliegen von TIMMO ist hierbei die Timing-Analyse auf jedem Abstraktionslevel, um das Timing schon in frühen Entwicklungsstadien zu beschreiben. [6][8] 3.2 TIMMO-2-USE TIMMO-2-USE ist der Nachfolger des ITEA2 TIMMO Projekts. Schwerpunkt liegt bei TIMMO-2-USE ausschließlich auf der Formulierung und Behandlung von Timing- Anforderungen. Dazu wurde im Rahmen des Projekts die Sprache TADL2 entwickelt, die eine Redefinition von TADL ist. Ziel des TIMMO-2-USE Projekts ist das Lösen praxisnaher Anwendungsfälle der Industrie. Dazu wurde eine Methodologie entwickelt, die spezifische Probleme im Zusammenhang mit Timing in einem Automobil-System löst. [6][8] TIMMO-2-USE Methodologie Die TIMMO-2-USE Methodologie basiert auf dem Generic Methodology Pattern (GMP) (Abb. 5). Das GMP besteht aus sechs Aufgaben und ist die Basis für jeden Schritt in einem Abstraktionslevel. Im ersten Schritt (Create Solution) wird die Architektur ohne Timing-Information beschrieben. Daraufhin werden im zweiten Schritt (Attach Timing Requirements to Solution) die Timing-Anforderungen der Architektur beschrieben und zur Architektur hinzugefügt. Im dritten Schritt (Create Timing Model) wird ein formalisiertes Modell für die Berechnung der Timing-Charakteristiken der Architektur beschrieben. Dieses Modell wird im vierten Schritt (Analyze Timing Model) analysiert und evaluiert. Im fünften Schritt (Verify Solution against Timing Requirements) wird das Timing-Modell mit den Timing-Anforderungen aus dem zweiten Schritt überprüft. Im letzten Schritt (Specify and Validate Timing Requirements) werden die Timing-Anforderungen für den nächsten Entwicklungsschritt beschrieben. Alle praktischen Anwendungsfälle in TIMMO-2-USE werden auf diese Methodologie abgebildet. [6][8]

6 6 A. Weinmann Abb. 5 Ablauf des Generic Methodology Pattern [8] TIMMO-2-USE Anwendungsfälle Wie zuvor schon beschrieben, ist das Ziel von TIMMO-2-USE das Lösen praxisnaher Anwendungsfälle. Beispiele dieser Anwendungsfälle sind das Zeitbudget, Synchronitätsbedingungen oder Probabilistische Zeitbedingungen weitere Anwendungsfälle sind unter [8] zu finden. Die praktischen Anwendungsfälle werden auf die Methodologie abgebildet. Dies sieht man in Abb. 6 beispielhaft am Anwendungsfall Zeitbudget. Mittels des GMP wird aus dem Zeitbudget des höheren Levels das aktuelle Zeitbudget bestimmt. [6][8] 3.3 AUTOSAR TIMEX Mit dem Release 4.0 von Autosar ist die TIMing EXtension teil des AUTOSAR Standards. TIMEX bietet ein formales Timing-Modell und damit die Basis für zeitliche Anforderungen, Abhängigkeiten sowie Timing-Garantien. Um die verschiedenen Entwicklungsphasen, die durch die AUTOSAR Methodologie vorgegeben sind zu unterstützen stellt die Timing Erweiterung fünf verschiedene Sichten auf das Timing zur Verfügung: VfbTiming (Virtual Functional Bus Timing) SwcTiming (Software Component Timing) SystemTiming BswModuleTiming (Basic Software Modules Timing) EcuTiming (Electronic Controll Unit Timing) In der VfbTiming-Sicht werden Softwarekomponenten auf logischer Ebene zusammengefasst betrachtet. Die SwcTiming Sicht betrachtet das Timing von konkreten Softwarekomponenten. In der SystemTiming-Sicht wird das Timing von spezifischen Systemen definiert. Die BswModuleTiming Sicht behandelt das Timing der Basis-Software und die EcuTiming-Sicht betrachtet das Timing einzelner elektronischer Kontrolleinheiten.

7 AUTOSAR und Echtzeit 7 Abb. 6 Durchlauf des Generic Methodology Pattern für den Anwendungsfall Zeitbudget[6] Somit ist es möglich Timing auf allen Ebenen zu definieren, eine Rückverfolgbarkeit über alle Ebenen hinweg ist allerdings nicht möglich. In Abb. 7 werden beispielhaft, anhand des BMW-Aktiv-Lenksystems, zwei verschiedene Sichten auf das Timing dargestellt. In diesem Beispiel darf die Gesamtdauer des Lenkvorgangs 30 ms nicht überschreiten. Dies beschreibt somit die Anforderung an das VfbTiming, also die logische Zusammenfassung aller beteiligten Komponenten. T1 bis T5 beschreiben das Timing der einzelnen Systeme (SystemTiming). Die Zeit aller Systeme zusammen muss also kleiner als 30 ms sein, um den Anforderungen der darüberliegenden Sicht zu genügen. [9][10] AUTOSAR TIMEX Konzept Kernelemente der AUTOSAR TIMEX-Spezifikation sind Timing Descriptions und Timing Constraints. Dabei unterteilen sich die Timing Descriptions in Events und Event Chains zur Beschreibung von zeitlichen Anforderungen. Die Timing Constraints werden auf Events und Event Chains angewandt und stellen Bedingungen an diese. Dieses Konzept kann auf die in 3.3 beschriebenen Sichten angewendet werden (Abb. 8). Im Folgenden werden zuerst Events und Event Chains vorgestellt, darauf folgen die verschiedenen Timing Constraints, die in AUTOSAR TIMEX integriert sind. [2] [10] Events Events verweisen auf Stellen im AUTOSAR Modell, an denen Aktionen auftreten. Events werden benutzt, um das Lesen der Daten von einer Software-Komponente sowie das Schreiben von Daten zu einer Software-Komponente zu spezifizieren. Je nach

8 8 A. Weinmann Abb. 7 TIMEX Sichten am Beispiel der BMW Aktivlenkung. T1 bis T5 entsprechen den zeitlichen Anforderungen auf SystemTiming Sicht, die 30ms stehen für die maximale Zeit die alle Systeme zusammen in Anspruch nehmen dürfen (VfbTiming) [9] Abb. 8 TIMEX Diagramm. Wichtige Bereiche sind Gelb markiert. TIMEX Sichten als Spezialisierung der Timing Extension [10] AUTOSAR Sicht stehen hierbei vordefinierte Typen zur Verfügung (Abb. 9). So wird beispielsweise auf VfbTiming-Sicht das Aufrufen von Services und die Antwort dieser

9 AUTOSAR und Echtzeit 9 durch ein Event dargestellt. Auf EcuTiming und BswModuleTiming Sicht stellt ein Event die Aufrufe von Basis Software Modulen und deren Antwort dar. [2][10] Abb. 9 TIMEX Event leitet von TimingDescription ab und besitzt eine Auftrittsbeschreibung. TIMEX bietet Spezialisierungen für die verschiedenen Sichten [10] Event Chain Event Chains spezifizieren die Beziehungen zwischen Events. Dabei entspricht das eine Event dem Stimulus und das andere Event der Reaktion. Event Chains können auch aus mehreren Event Chains bestehen, sogenannten Segmenten (Abb. 10). Jedoch muss gewährleistet werden, dass immer ein Pfad vom initialen Stimulus zur letzten Reaktion der Verkettung existiert. [10] Abb. 10 Beispielhafte Darstellung einer Event Chain, hier als end-to-end timing chain markiert, sowie mehrerer Segmente markiert als timing chain segments [10]

10 10 A. Weinmann Event Triggering Constraint Dieser Constraint wird auf ein Event angewendet und bestimmt dessen Auftreten. Mögliche Arten sind dabei periodisches, sporadisches, nach einem konkreten Muster, nach einem Häufigkeitsmuster oder auch beliebiges Auftreten. [10] Latency Timing Constraint Der Latency Timing Constraint wird auf Event Chains angewendet und definiert die Zeit zwischen Stimulus und Reaktion. Dabei ist es möglich eine minimale, maximale sowie eine nominale Zeit zu bestimmen. [10] Age Constraint Um das Alter von Daten zu spezifizieren, kann im Falle, dass der Sender der Daten bekannt ist, mittels eines Latency Timing Constraint das Alter definiert werden. Wenn jedoch der Sender der Daten unbekannt ist, bietet der Age Constraint die Möglichkeit, das Alter der Daten zu definieren. Im Gegensatz zum Latency Timing Constraint wird der Age Constraint auf die Daten eines Events angewandt. Der Age Constraint ermöglicht es, ein minimales sowie maximales Alter zu bestimmen. [10] Synchronization Timing Constraint Im Falle zweier korrelierender Event Chains ist es nötig, das Zeitverhalten beider Event Chains zu synchronisieren. Dies ermöglicht der Synchronization Timing Constraint. Dieser wird auf zwei Event Chains angewendet und erlaubt es, eine Tole- ranzzeit festzulegen. Dabei kann entweder das Auftreten der zwei Stimuli oder der zwei Reaktionen mit einem Constraintversehen werden. [10] Offset Timing Constraint Um die zeitliche Differenz zwischen dem Auftreten zweier Events zu beschränken, bietet TIMEX den Offset Timing Constraint. Dieser erlaubt es, eine minimale sowie maximale Zeit zwischen zwei Events zu definieren. [10] Execution Order Constraint Mittels des Execution Order Constraint ist es möglich, die Ausführungsreihenfolge zu bestimmen. Dabei wird dieser Constraint auf sogenannte Executable Entities (auch Runnable Entities genannt) angewendet. Dies sind einzelne ausführbare Elemente, die je nach Sicht den jeweils kleinsten Komponenten entsprechen. [10] Execution Time Constraint Der Execution Time Constraint wird ebenfalls auf Executable Entities angewendet und ermöglicht die maximale und minimale Zeit für die Ausführung einer Executable Entities festzulegen.[10] AUTOSAR TIMEX Konzept Beispiel Im Folgenden werden die vorgestellten Elemente von AUTOSAR TIMEX anhand eines abstrakten Beispiels verdeutlicht. Abb. 11 zeigt dazu ein System bestehend aus ausführbaren Elementen (in Abb. 11 als RE gekennzeichnet), Software- Komponenten (in Abb. 11 als SWS gekennzeichnet) sowie zusammengefasste

11 AUTOSAR und Echtzeit 11 Abb. 11 Beispielhafte Darstellung der Timing Descriptions und Timing Constraints an einem abstrakten System [3] Software-Komponenten (in Abb. 11 als CSWS gekennzeichnet). Die rote Linie stellt einen möglichen Durchlauf durch das System dar. Mit grünen Kreisen sind beispielhaft Positionen, an denen Events auftreten markiert. Nun ist es möglich, diese Events mit Event Constraints zu belegen, wie zum Beispiel den periodischen Event Trigger Constraint (ETC 1), der in Abb. 11 auf das Event 1 angewandt wird. Ein Beispiel für einen Constraint, der auf eine Event Chain angewendet wird, ist in Abb. 11 zu sehen. Hier wird ein Latency Constraints (LC 1) auf die Event Chain 1 angewendet und bestimmt die maximale Zeit die zwischen dem Auftreten von Event 1 bis zum Auftreten von Event 2 auf z.b. 30 ms vergehen darf. Constraints, die auf die einzelnen ausführbaren Elemente angewandt werden, sind beispielhaft am Execution Time Constraint (ExecutionTC), der auf die RE 2 angewendet wird, zu sehen sowie am Execution Order Constraint (EOC), der die Ausführungsreihenfolge von RE 2 und RE 3 festlegt. In Abb. 12 sieht man einen zusätzlichen, parallelen Durchlauf durch das System. Dieser Durchlauf ist mit der Event Chain 2 versehen. Um nun die Synchronität der beiden Event Chains als Bedingung zu setzen, wird ein Synchronization Timing Constraint (STC) auf Event Chain 1 und Event Chain 2 angewendet. Dabei ist es möglich zu definieren, ob die Stimuli, sprich Event 1 und Event 3, synchron auftreten müssen oder die Reaktionen der beiden Event Chains, also Event 2 und Event 4. Mittels der vorgestellten Timing Descriptions und Timing Constraints ist es nun möglich Komponenten in AUTOSAR um zeitliche Anforderungen zu erweitern. Eine Validierung dieser Anforderungen muss dann auf Implementationsebene erfolgen. [2][3][10]

12 12 A. Weinmann Abb. 12 Beispielhafte Darstellung des Synchronization Timing Constraint angewendet auf zwei Event Chains [3] 4 Fazit und Ausblick Timing-Modellierung ist unumgänglich in der modernen Automobilindustrie, somit ist ein standardisierter Ansatz nötig. AUTOSAR TIMEX ist durch die Integration in den AUTOSAR Standard ein großer Schritt in die richtige Richtung. Allerdings gibt es noch einiges an Verbesserungspotential, so fehlt die Rückverfolgbarkeit von Timing Anforderungen über alle Abstraktionslevel hinweg. Ebenso fehlt probabilistisches Timing für die Realisierung von Anwendungen, bei denen ein gelegentliches nicht Erreichen der zeitlichen Anforderungen tolerabel ist. Auch die, aufgrund der mehreren vorhandenen Zeitbasen innerhalb eines Automobils entstehende Desynchronisation der CPUs auf Implementationsebene muss durch die Modellierung dieser verschiedenen Zeitbasen berücksichtigt werden. Trotzdem bietet AUTOSAR dank TIMEX eine gute Basis für die Modellierung von Timing. TIMMO-2-USE ist zwar in diesen Aspekten schon weiter, jedoch ist für AUTOSAR TIMEX, durch die Integration von TIMEX in den AUTOSAR Standard, eine höhere Akzeptanz zu erwarten. Ob sich AUTOSAR TIMEX durchsetzt, hängt jedoch ausschlaggebend von der Tool-Unterstützung ab. Literatur 1. AUTOSAR: AUTOSAR Website Letzter Aufruf: Marie-Agnès Peraldi-Frati,Hans Blom, Daniel Karlsson and Stefan Kuntz (2012): Timing modeling with AUTOSAR: current state and future directions, Proceedings of the Conference on Design, Automation and Test in Europe, EDA Consortium, Dresden 3. Stefan Kuntz (2012): Timing Modelling with AUTOSAR Current State and Future Directions Präsentation, DATE12 Letzter Aufruf: Kay Klobedanz, Christoph Kuznik, Andreas Thuy and Wolfgang Mueller (2010): Timing Modeling and Analysis for AUTOSAR-Based Software Development - A Case Study, Pro-

13 AUTOSAR und Echtzeit 13 ceedings of the Conference on Design, Automation and Test in Europe, European Design and Automation Association, Dresden 5. M. Jersak, K. Richter (2010): Zeit für AUTOSAR, In Elektronik automotive S45-49_Zeit_fuer_Autosar.pdf Letzter Aufruf: M.-A. Peraldi-Frati, D. Karlsson, A. Hamann, S. Kuntz, J. Nordlander (2012): The TIMMO- 2-USE project: Time modeling and analysis to use. In ERTS2012 International Congres on Embedded Real Time Software and Systems 7. TIMMO Brochure Letzter Aufruf: TIMMO-2-USE Brochure Letzter Aufruf: O. Scheickl, C. Ainhauser, P. Gliwa (2012): Tool support for seamless system development based on AUTOSAR timing extensions. In ERTS2012 International Congres on Embedded Real Time Software and Systems 10. Specification of Timing Extensions Letzter Aufruf: