DOI 10.1007/s00450-007-0028-y

R E G U L Ä R E B E I T R Ä G E

Informatik Forsch. Entw. (2007) 22: 45–57

Das AutoMoDe-Projekt

Modellbasierte Entwicklung softwareintensiver Systeme im Automobil

Andreas Bauer · Manfred Broy · Jan Romberg · Bernhard Schatz · Peter Braun ·Ulrich Freund · Nuria Mata · Robert Sandner · Pierre Mai · Dirk Ziegenbein

Eingegangen: 20 Oktober 2006 / Angenommen: 27 April 2007 / Online veroffentlicht: 6 Juni 2007© Springer-Verlag 2007

Zusammenfassung Die Entwicklung eingebetteter Soft-ware fur Automobile ist inharent komplex und vereint ver-schiedene Entwicklungsphasen, mehrere fachliche Diszipli-nen, sowie verschiedene Akteure in beteiligten Unterneh-men. Der AutoMoDe-Ansatz zur Entwicklung automotiverSoftware beschreibt Systeme auf verschiedenen Abstrakti-onsebenen und definiert schrittweise Ubergange zwischendiesen Ebenen. Neben der Definition geeigneter Ebenen

Dieses Projekt wurde vom Bundesministerium fur Bildung und For-schung (BMBF) unter dem Kennzeichen 01ISC08 gefordert

A. Bauer (�) · M. Broy · J. Romberg · B. SchatzSoftware&Systems Engineering, Institut fur Informatik,Technische Universitat Munchen,Boltzmannstr. 3,85748 Garching b. Munchen, Deutschlande-mail: baueran@in.tum.de

P. BraunValidas AG,Lichtenbergstr. 8,85748 Garching b. Munchen, Deutschland

U. Freund · N. MataETAS GmbH,Borsigstr. 14,70469 Stuttgart, Deutschland

R. SandnerBMW AG,80788 Munchen, Deutschland

P. MaiPMSF IT Consulting,Ludwig-Thoma-Str. 11,87724 Ottobeuren, Deutschland

D. ZiegenbeinRobert Bosch GmbH,Postfach 30 02 40, 70442 Stuttgart, Deutschland

werden zur Modellierung von Echtzeitsystemen ein ein-heitliches Berechnungsmodell sowie domanenspezifischeBeschreibungstechniken verwendet. Automatisierte Anbin-dungen fur Analyse und Synthese komplexer Software-systeme mit dem Ziel eines konsistenzbetonten Entwick-lungsprozesses wurden realisiert. Die beschriebenen Tech-niken wurden in den Werkzeugprototypen AutoFocus in-tegriert und im Zusammenspiel mit einer Werkzeugkettedemonstriert.

Schlusselworter Automotive Software Engineering ·Eingebette Software · Synchrone Sprachen · AutoMoDe

Abstract Development of embedded automotive softwareis inherently complex and involves different stakeholders,phases, and disciplines. The AutoMoDe approach to au-tomotive software development defines distinct levels ofabstraction for integrated development, and defines step-wise transitions between the levels. Along with the defin-ition of suitable abstraction levels, to support modelingof real-time systems, a homogeneous operational modelalong with domain-specific notations are used. Automatedbackend functionalities for analysis and synthesis of com-plex software systems, with the goal of a consistent de-velopment process, were devised. The techniques describedhave been integrated into the tool prototype AutoFocusand have been demonstrated by the construction of a toolchain.

Keywords Automotive software engineering · embeddedsoftware · synchronous languages · AutoMoDe

CR subject classification D.2.2

1 3

46 Bauer et al.

1 Einleitung

Die steigende Anzahl von Funktionalitaten, die von ein-gebetteten Systemen im Automobilbereich zur Verfugunggestellt werden, sowie die wachsende Tendenz, Funktio-nalitaten zu interoperierenden Netzwerken zu integrieren,erhoht die Komplexitat softwareintensiver Systeme im Au-tomobil. Die vorherrschende Verwendung von etablierten,stark an konkreten Implementierungsmechanismen sowiean Subsystemen orientierten Ansatzen zur Entwicklung die-ser Systeme fuhrt zu einem steigenden Problemdruck, ins-besondere in Bezug auf Integration und Qualitatssicherung.

Die Komplexitat stellt somit hohe Anforderungen an eineEntwicklungsmethodik. Zum einen soll die Interoperabilitatvon Funktionen bereits in fruhen Stadien der Entwicklungevaluiert werden konnen. Hierzu ist eine explizite Modellie-rung der Abhangigkeiten zwischen Funktionen, der Schnitt-stellen zwischen Modulen, sowie eine Festlegung der Ver-haltenssemantik notwendig. Des weiteren sollen Funktions-module zunachst unabhangig von der physischen Verteilungmodelliert werden konnen, um Freiheitsgrade im Entwurfbezuglich des Mappings von Funktionen auf Steuergerate zuerhalten. Diese Freiheitsgrade konnen dann spater im De-ployment, z.B. spezifisch nach unterschiedlichen Ausstat-tungsumfangen, kostenoptimal ausgenutzt werden. Schließ-lich soll durch geeignete methodische Vorgaben und wohl-definierte Schnittstellen- und Moduldefinitionen ein hoherWieder- und Mehrfachverwendungsgrad erreicht werden.Uber die genannten Punkte hinaus stellt sich mit dem Zu-sammenwachsen der Anwendungsgebiete diskreter Ereig-nissysteme und synchroner zeitgesteuerter Systeme die Auf-gabe, einen einheitlichen Modellierungsansatz fur beide Ar-ten eingebetteter Software zur Verfugung zu stellen, umbeide Aspekte eines eingebetteten Systems in Kombinationbeschreiben, analysieren, und bis hin zu einer Implementie-rung entwickeln zu konnen.

In diesem Artikel werden die Ergebnisse des AutoMoDe-Projektes vorgestellt, die von den Projektpartnern BMWAG, Robert Bosch GmbH, ETAS GmbH, Technische Uni-versitat Munchen, sowie Validas AG im Zeitraum Ok-tober 2003 bis Marz 2006 erzielt wurden. Der vorge-stellte Ansatz wird durch das AutoFocus-Werkzeug [9]unterstutzt. AutoFocus bietet grafische und textuelle Be-schreibungstechniken fur verschiedene Abstraktionsebenen.Damit ist die Modellierung von Struktur und Verhaltenvon Software durchgangig moglich. Zusatzlich existie-ren verschiedene Anbindungen zur Konsistenzanalyse, zurformalen Verifikation, zur Testfallgenerierung [8], sowiezur Code-Generierung. Um die praktische Umsetzung derKonzepte zu uberprufen wurde eine Werkzeugkette be-stehend aus etablierten Werkzeugen der ETAS aufgebaut.Anhand dieser konnte gezeigt werden, dass Modelle, mo-delliert mit dem AutoMoDe-Ansatz, in effiziente Imple-

mentierungen fur eingebettete Hardware umgesetzt werdenkonnen.

Abschnitt 2 diskutiert verwandte Arbeiten zu den in Au-toMoDe geleisteten Beitragen. In Abschn. 3 wird ein kurzerUberblick des AutoMoDe-Ansatzes und der betrachtetenAbstraktionsebenen gegeben. Abschnitt 4 erlautert kurz dasAutoFocus zugrunde liegende Berechnungsmodell, bevorim darauffolgenden Abschn. 5 die eingesetzten AutoFocus-Notationen beschrieben werden. Das Beispiel der Modellie-rung einer Antischlupfregelung in Abschn. 6 dient dazu dieErgebnisse zu veranschaulichen und deren praktische Um-setzung zu uberprufen. Der Ubergang zur Implementierungist Gegenstand des Abschn. 7, bevor dieser Artikel mit einerZusammenfassung endet.

2 Verwandte Ansatze und Beitrage von AutoMoDe

Der Beitrag von AutoMoDe kann in zwei Teilaspekte auf-gespalten werden: Zum einen wurde als Ergebnis des Pro-jekts ein methodisches Rahmenkonzept fur die Entwicklungautomotiver Softwaresysteme definiert. Zum anderen wur-den technische Beitrage in den Bereichen Modellierungs-sprachen und deren semantischer Fundierung, Transformati-onssprachen fur Software-Modellierungswerkzeuge, sowieverteilte Implementierung synchroner Datenflusssprachendurch das Projekt eingebracht.

Es existieren eine Reihe von verwandten Methodenfur modellbasierten Entwurf automotiver Softwaresysteme(siehe z.B. [1, 11, 20, 21, 28]). Neben Unterschieden imDetail verwenden die meisten der zitierten Ansatze eineAnzahl von definierten Abstraktionsebenen sowie verschie-dene unterstutzende Werkzeuge und Notationen mit demZiel einer inkrementellen Entwurfsmethodik fur automobileSoftware. Durch die Verwendung heterogener Notationenund Werkzeuge im Stadium des Entwurfs gelingt jedochtypischerweise keine enge Kopplung von Syntax- und Se-mantikkonzepten uber Werkzeug-, Notations-, sowie Pha-sengrenzen hinweg: verschiedene Werkzeuge realisieren un-terschiedliche und zum Teil nicht kompatible Semantiken,die oftmals keine formale Fundierung aufweisen, wie diesz.B. bei diversen UML-basierten Werkzeugen der Fall ist(siehe z.B. [2, 14]). AutoMoDe verwendet dagegen ein ein-heitliches und semantisch fundiertes Domanenmodell, dasdurch das AutoFocus-Werkzeug unterstutzt wird. Durch dieHomogenitat des Domanenmodells konnen neuartige tech-nische Beitrage wie die semantikerhaltende Transformationvon Modellen durch Transformationssprachen eingebrachtwerden. Die semantische Fundierung von mechatronischenSystemen allgemein steht z.B. auch in der Arbeit [15] imVordergrund. Im Gegensatz zum hier vorgestellten Ansatzwerden dort jedoch kontinuierliche Modelle eingesetzt, dieweniger abstrakt sind als Modelle in AutoMoDe, welches

1 3

Das AutoMoDe-Projekt 47

z.B. Zeit und konkrete Signallaufzeiten abstrahiert (sieheAbschn. 4).

Von allen genannten Ansatzen stutzt sich AutoMoDe imSpeziellen auf Vorgangerprojekte Automotive [28] sowieEAST-EEA [1]. Dabei wurden verschiedene Defizite derVorganger adressiert: im Vergleich zu Automotive, dass aufder UML 1.x-Notation basierte, wird in AutoMoDe mit derAutoFocus-Notation ein explizites Modell fur Komponen-ten und ihre (nachrichtenbasierten)Schnittstellen eingefuhrt,sowie Unterstutzung zur Modellierung regelungstechnischerAlgorithmen auf Basis diskreter, feingranularer multiratenClocks (vgl. Abschn. 4). AutoFocus ist in wesentlichenKonzepten eng verwandt zu der Komponentendarstellungin UML 2.0, so dass die weiterfuhrende Moglichkeit einerUML-standardkonformen Darstellung nicht als kritisch an-gesehen wird. Als Vorteil gegenuber einer rein standardbe-zogenen Darstellung konnen die Arbeiten mit AutoFocusjedoch auf ein unzweideutiges und fur die Domane geeig-netes semantisches Modell abgestutzt werden. Im Vergleichsowohl mit dem Automotive-Projekt als auch mit EAST-EEA wurde in AutoMoDe ein starkerer Schwerpunkt auf dieModellierung und Erhaltung von Verhaltenseigenschafteneingebetteter Systeme gelegt. Mit dem gleichzeitigen Startder AUTOSAR-Entwicklungspartnerschaft [24] konnte Au-toMoDe zudem von den technischen Ergebnissen her auf die“Virtual Functional Bus”-Architektur von AUTOSAR abge-stimmt werden.

Gegenuber regelungstechnisch motivierten Werkzeugenwie Matlab/Simulink [19] oder ASCET [12] sowie ausanderen Anwendungsgebieten (z.B. Telekommunikation)stammenden Ansatzen wie UML 2.0 Komponentendia-grammen bietet der AutoFocus-gestutzte Ansatz den Vor-teil von domanenspezifische Konzepten wie z.B. Betriebs-modus, Funktion, oder Periode.

In diesem Artikel wird unter anderem die explizite Mo-dellierung von Betriebsmodi als ein Mittel der grobgranula-ren Dekomposition eingebetteter Systeme als Ergebnis desAutoMoDe-Projekts beschrieben. Diese Idee wurde auchvon anderen Autoren beschrieben, so z.B. [18]. Zusatzlichzur reinen Verwendung einer neuen Notation setzt unserAnsatz Modi uber mehrere Abstraktionsebenen hinweg ein,und untersucht speziell Transformationen zwischen ver-schiedenen strukturierten, jeweils auf einen Einsatzzweckhin optimierte Modus-Hierarchien.

Die Idee, zeit- und ereignisgesteuerte Takte als Bool-esche Ausdrucke (Clocks) zu definieren, sowie ein flan-kierendes Verfahren zur Inferenz und Uberprufung vonClocks, stammt aus dem Gebiet der synchronen Daten-flusssprachen [6]. Im Vergleich zu den in [6] beschriebenenAnsatzen, unterscheidet sich das im Projekt AutoMoDe ent-worfene Inferenzverfahren, durch erhohte Skalierbarkeit beieiner fur die Praxis ausreichenden Ausdrucksmachtigkeitder Modellierungssprache.

3 Uberblick

Der AutoMoDe-Ansatz vereint verschiedene Aspekte einermodellbasierten, durchgangigen Entwicklungsmethodik:

Domanenmodell: In AutoMoDe wurde ein integriertes Do-manenmodell zur Entwicklung softwareintensiver einge-betteter Systeme im Automobilbereich definiert.

Notationen: Das Domanenmodell integriert Modellierkon-zepte, die in der Entwicklersicht durch eine Anzahl vonproblemorientierten grafischen und textuellen Notationenreprasentiert werden. Dabei bieten unterschiedliche Dia-gramme, zum Beispiel fur Verhalten und Struktur, jeweilsalternative Sichten auf ein integriertes Modell.

Abstraktionsebenen und Transformationsschritte: Um denAnsatz insgesamt zu strukturieren, werden verschiedeneAbstraktionsebenen eingefuhrt. Formalisierte Transfor-mationsschritte dienen dem Ubergang zwischen Abstrak-tionsebenen sowie der Umformung von Modellen aufgleicher Ebene mit dem Ziel der Erhaltung wesentlicherEigenschaften.

Werkzeugkette: Der AutoMoDe-Ansatz wird durch eineWerkzeugkette unterstutzt (siehe Abb. 1), die Editieren,Analyse, sowie Transformation von Modellen auf ver-schiedenen Abstraktionsebenen zulasst.

Die AutoMoDe-Entwurfsmethodik basiert stark auf einerGliederung der Modellierungsartefakte in domanenspezifischeAbstraktionsebenen ahnlich zu der in [1] vorgeschlagenen(siehe Abb. 2).

Fur die Beschreibung der Modelle auf den abstrakterenModellierungsebenen wird das AutoFocus-Werkzeug ver-wendet. Neben dem Editieren und Validieren von Modellenunterstutzt AutoFocus verschiedene Arten von Modell-transformationen, die im Detail im folgenden Abschnitt undin [5] beschrieben werden. Fur die konkreteren und starkerimplementierungsbezogenen Abstraktionsebenen schließt

Abb. 1 AutoMoDe-Werkzeugkette

1 3

48 Bauer et al.

Abb. 2 AutoMoDe-Abstraktionsebenen

die AutoMoDe-Werkzeugkette die kommerziellen Werk-zeuge ASCET [12], RTA OSEK Planner [17], sowie IN-TECRIO [13] mit ein. Die letztgenannten Werkzeuge zurimplementierungsbezogenen Entwicklung und Synthese au-tomotiver Softwaresysteme sind in dieser Domane praktischetabliert.Functional analysis architecture (FAA). Die abstraktesteder betrachteten Ebenen ist die Functional Analysis Ar-chitecture. Sie ist eine fahrzeugweite und bzgl. der Struk-tur und der funktionalen Abhangigkeiten vollstandige Be-schreibung. Ubergreifendes Ziel der Beschreibung aufFAA-Ebene ist vor allem die Identifikation wesentlicherAbhangigkeiten und eventueller Konflikte zwischen Funk-tionalitaten, sowie die Konzeptvalidierung anhand von un-vollstandigen oder prototypischen Verhaltensbeschreibun-gen. Der Begriff der Funktionalitat bezeichnet eine be-nutzersichtbare Elementarfunktion auf FAA-Ebene. DieBeschreibung auf FAA-Ebene konzentriert sich dabei aufKernelemente der eigentlichen Systemanwendung bzw. desRegelalgorithmus: Im Sinne der Anwendung untergeord-nete Schichten wie z.B. Sensor- und Aktuatorvorverabei-tung, Diagnosefunktionalitaten, sowie Systemuberwachungund Plausibilisierung werden nicht betrachtet. Auf FAA-Ebene werden die Funktionalitaten unabhangig von Rea-lisierungsentscheidungen in Hardware oder Software be-trachtet. Systeme sind auf FAA-Ebene typischerweise nachfunktionalen Gesichtspunkten und somit vor allem nachSichtbarkeit durch den Benutzer gruppiert. Als Beispielfur eine solche Gruppierung kann man unter dem Begriff,,Langsdynamiksteuerung“ alle diejenigen Funktionalitatenversammeln, die einen Einfluss auf die (durch den Benutzerwahrgenommene) Langsdynamik eines Fahrzeuges haben,also z.B. die Vortriebs-/Motorsteuerung, die Steuerung derBremse, sowie moglicherweise eine Antischlupfregelung.Ein und dieselbe Komponente kann dabei mehrfach in ver-

schiedenen Kontexten ohne weitere Einschrankung vorkom-men (als Typ bzw. Referenz).

FAA-Darstellungen sind typischerweise strukturorien-tiert: wahrend die Strukturierung in Funktionalitaten undAbhangigkeiten bzw. Datenflusse essentiell fur die FAA-Modellierung ist, spielt das Verhalten der Einzelfunktiona-litaten eine untergeordnete Rolle. Somit wird die FAA inAutoFocus primar durch die in Abschn. 5 beschriebenenSystemstrukturdiagramme (SSDs) reprasentiert, und in un-tergeordneter Weise durch die AutoFocus-Notationen furdetailliertes Verhalten. Mit AutoFocus konnen vielfaltige,FAA-bezogene Konsistenzbedingungen uberpruft und durch-gesetzt werden.Functional design architecture (FDA). Die functional de-sign architecture stellt bereits eine bzgl. der Struktur unddes Verhaltens vollstandige Beschreibung von Software-Systemen im Automobil dar. Der methodische Schwer-punkt liegt dabei auf einer Verifikation des Softwarever-haltens sowie auf der Identifikation gemeinsamer und wie-derverwendbarer Softwarekomponenten. Gegenuber derFAA steht eine starker realisierungsorientierte und weni-ger nutzerorientierte Strukturierung des Systems im Vor-dergrund. So kann z.B. die obengenannte nutzerbezo-gene FAA-Strukturierung von Fahrdynamikfunktionen in,,Langsdynamiksteuerung“ und ,,Querdynamiksteuerung“auf FDA-Ebene durch eine starker technische, organisatori-sche, sowie wiederverwendungsbezogene Strukturierung er-setzt werden. Bezuglich der Vielfachheit von Komponentengilt, dass auf der FDA-Ebene eine Minimierung des wieder-holten Auftretens einer gegebenen Komponente angestrebtwird. Der methodische Nutzen ist dabei, dass durch dieZusammenfassung identischer Funktionalitaten in einmaligauftretenden Komponenten Potenziale fur Mehrfachverwen-dung aufgedeckt werden konnen, die sich beim Ubergangvon einer funktionsorientierten Strukturierung (FAA) hin zueiner an der Realisierung orientierten Struktur ergeben. EinBeispiel fur ein derartiges Potenzial ist z.B. die zunachsthaufig mehrfach eingeplante Vorverarbeitung und Aufberei-tung von Sensorsignalen, die in der spateren Realisierungan einer Stelle aufbereitet werden sollten, um anschließendverteilt kommuniziert und verwendet zu werden.

FDA-Komponenten werden in AutoFocus durch Kom-ponenten in Systemstrukturdiagrammen beschrieben: siekonnen somit wiederum hierarchisch durch andere Kom-ponenten aufgebaut sein, und sind uber typisierte, gerich-tete Kanale und Konnektoren miteinander verbunden. DieVerhaltensdarstellung ist in AutoFocus mit den in Ab-schn. 5 beschriebenen Notationen zur Verhaltensdarstellungmoglich. Die Uberprufung FDA-spezifischer Konsistenzbe-dingungen wie z.B. Struktur- oder Verhaltensvollstandigkeitkann ebenfalls durch AutoFocus vorgenommen werden.Hierbei wird auf syntaktischer Ebene die Vollstandigkeit derFDA-Modelle uberpruft.

1 3

Das AutoMoDe-Projekt 49

Logical/technical architecture (LA/TA). Die detailliertesteAutoMoDe-Abstraktionsebene gliedert sich in Logical Ar-chitecture und Technical Architecture. In der LA werdendie Software-Komponenten in so genannte Cluster grup-piert: dabei reprasentiert ein Cluster eine kleinste verteilbareEinheit, z.B. im Sinne eines Tasks oder einer Routine. AlsStrukturierungskriterium treten somit noch starker als in derFDA technische Eigenschaften wie gemeinsame Aktivie-rungsfrequenz, Prioritat und Kritikalitat in den Vordergrund.Technische Informationen wie z.B. Takte/Perioden oder Im-plementierungstypen mussen auf der Logical Architecturevollstandig spezifiziert sein. Die technical architecture (TA)reprasentiert alle fur die Zuordnung von logischen Clusternzu technischen Ressourcen relevanten Konzepte, wie z.B.Steuergerate, Busse und Slots bzw. Nachrichten der Kom-munikationsmedien. Die eigentliche Zuordnung von Clu-stern zu Steuergeraten bzw. Datenflussen zu Kommunika-tionsmedien erfolgt in der hier nicht weiter behandeltenoperational architecture (OA), die dem aus den implemen-tierungsorientierten Werkzeugen synthetisierten HW/SW-System entspricht.

Die LA kann auszugsweise in AutoFocus modelliertwerden: zu diesem Zweck sind vor allem die Model-lierungskonzepte Clocks (fur heterogene Aktivierungs-frequenzen) sowie Implementierungstypen hilfreich. Invollstandiger Auspragung konnen LA und TA in ASCET,INTECRIO, sowie RTA OSEK Planner modelliert werden.

4 Berechnungsmodell

Das dem AutoMoDe-Projekt zugrundeliegende Berechungs-modell von AutoFocus verwendet eine nachrichtenba-sierte, taktsynchrone Semantik mit uniformem, system-weitem Takt [10]. Dabei werden Rechenschritte inner-halb eines Taktes nicht weiter zeitlich aufgelost. Modellein AutoFocus werden als Netzwerke von Komponentenbzw. Blocken definiert, die Nachrichten mit der Umge-bung und untereinander uber explizite Schnittstellen (Nach-richtenports) sowie Konnektoren zwischen Schnittstellen(Nachrichtenkanale) austauschen. Nachrichten besitzen imabstrakten Modell einen Zeitstempel in Bezug auf denglobalen Takt. Dieses datenflussorientierte Berechnungsmo-dell unterstutzt einen hohen Grad an Modularitat dadurch,dass Komponentenschnittstellen vollstandig und explizitdurch syntaktische Konstrukte abgebildet werden. Das Be-rechnungsmodell verringert den Grad an Komplexitat inEchtzeitsystemen: Das Nachrichtenparadigma mit diskre-ter Zeitbasis abstrahiert von Implementierungsdetails wiedetailliertem Timing, kausaler Abfolge interner Berech-nungsschritte, und verwendeten Kommunikationsmedien.

Beispiele fur solche Implementierungsdetails beinhal-ten die Reihenfolge der Ankunft von Implementierungs-

nachrichten mit demselben logischen Zeitstempel, oder diegenaue Dauer des Datentranfers auf einem Kommunika-tionsmedium. Somit werden Echtzeitintervalle der Imple-mentierung durch logische Zeitintervalle abstrahiert. Dasnachrichtenorientierte, zeitdiskrete Paradigma kann sowohlperiodische als auch sporadische Berechnungen abbilden,wie es z.B. fur die Modellierung von zeitgesteuertem undereignisgesteuertem Verhalten notwendig ist.

Um die heterogenen (a) periodischen Takte bzw. Fre-quenzen typischer Automotive-Anwendungen komforta-bel modellieren zu konnen, werden in AutoFocus so ge-nannten Clocks [7] verwendet. Jeder Nachrichtenstrom inAutoFocus ist mit einer Clock assoziiert: Die Clock istdabei ein Boolescher Ausdruck, welcher die Anwesenheitbzw. Abwesenheit einer Nachricht eines Nachrichtenstromsbeschreibt. Zur Laufzeit evaluiert der Ausdruck zu logischwahr, wenn der Nachrichtenstrom eine Nachricht enthalt.

Mit expliziten Sampling-Operatoren zwischen Kompo-nenten bzw. Clustern kann ein Datenfluss von einer Clockauf eine andere uberfuhrt werden. Mit Hilfe von strukturelluber den Elementaroperatoren der Sprache definierten Re-geln ist es dann moglich, fur jedes AutoFocus-KonstruktVorbedingungen sowie Inferenzregeln bezuglich der Clocksanzugeben. Das AutoFocus-Werkzeug kann sowohl dieKorrektheit des Designs in Bezug auf die Clocks (Erfullungaller Vorbedingungen) uberprufen, als auch auf samtlicheinterne und ausgabeseitige Clocks eines Systems schließen(Anwendung der Inferenzregeln).

5 AutoFocus-Notationen

AutoFocus bietet eine Anzahl von verschiedenen Notatio-nen, die sich bei der Modellierung eingebetteter Systemebewahrt haben. Diese werden im Folgenden beschrieben.Systemstrukturdiagramme (SSD). Systemstrukturdiagram-me bieten eine architekturbezogene Gesamtsicht auf einSoftware-System und werden fur die AbstraktionsebenenFAA und FDA verwendet. Dabei werden Schnittstellen,Kommunikationsabhangigkeiten und hierarchische Dekom-position hinsichtlich der Funktionsarchitektur (FAA) bzw.der Softwarearchitektur (FDA) beschrieben. Dabei wirddas System als Netzwerk von reaktiven Komponenten mittaktweiser Berechnung – einschließlich einer Eingabe- undeiner Ausgabeinteraktion – beschrieben, die Nachrichtenund Signale uber gerichtete Kanale untereinander austau-schen. Komponenten sind entweder atomar, oder setzen sichhierarchisch aus Subkomponenten, die in einem eigenenSSD spezifiziert sind, zusammen. Durch die taktweise In-teraktion von Komponenten bietet deren architektonischeModularitat bereits auf hoher Abstraktionsebene ,,Soll-bruchstellen“ fur die spatere Partitionierung, ohne diesekonkret vorwegzunehmen.

1 3

50 Bauer et al.

Abbildung 3 zeigt ein typisches SSD fur die Darstel-lung der in Abschn. 6 beschriebenen Antischlupfregelung.Das SSD ist Teil eines Gesamtsystems. Die nicht ei-ner Komponente zugeordneten Ports definieren dabei dieSchnittstelle des Systemausschnitts zum Restsystem. EinZiel der FAA-Modellierung ist die Identifikation eventu-eller Konflikte zwischen Funktionalitaten. Durch die kon-sequent an funktionalen Gesichtspunkten orientierte Struk-turierung existiert im FAA-Modell in diesem Fall eineeindeutige, hier durch VehicleMotionCoordinatorreprasentierte Stelle im Modell, an der ein moglicher Koor-dinationsbedarf zwischen den (funktional eng verwandten)Anfragen DesiredThrottlePositionDriver undEngineIntervention offensichtlich wird.

Im Gegensatz zu den mit SSDs modellierten Funktiona-litaten auf FAA-Ebene mussen SSD-modellierte Software-komponenten auf FDA-Ebene ein definiertes Verhalten auf-weisen. Verhaltensspezifikationen atomarer Softwarekom-ponenten sind in Form von Datenflussdiagrammen (DFDs)mit algorithmischen Datenfluss, mode transition diagrams(MTDs) mit am Betriebsmodus orientierter dekomponier-ter Darstellung, sowie mit state transition diagrams (STDs)fur eine automatenorientierte, ereignisgesteuerte Darstel-lung moglich.Datenflussdiagramme (DFD). Obwohl ahnlich in der Struk-tur zu SSDs, beschreiben Datenflussdiagramme den algo-rithmischen Datenfluss im Zuge des Berechnungsschrittesvon Komponenten. DFDs werden typischerweise auf allenAbstraktionsebenen eingesetzt. Auf FAA-Ebene uberwiegendabei prototypische Verhaltensbeschreibungen. DFDs sindaus atomaren oder hierarchischen Blocken aufgebaut, dieahnlich zu SSDs uber gerichtete und typisierte Kanale ver-

Abb. 3 Beispiel fur ein SSD auf FAA-Ebene

bunden sind. Das Verhalten von atomaren Blocken kannentweder durch ein Mode Transition Diagram (MTD, siehefolgende Abschnitte), ein State Transition Diagram (STD,siehe [9]), oder durch einen textuellen Ausdruck in der Ba-sissprache von AutoFocus [16] gegeben sein. HierarchischeBlocke werden wiederum durch DFDs definiert.

In Abb. 4 ist als Beispiel fur ein DFD ein Algorithmuszur Erkennung von Radschlupf bei Fahrzeugen abgebildet.So ist zum Beispiel der Block Difference durch denAusdruck ReferenceSpeed - WheelSpeed definiert,wobei ReferenceSpeed und WheelSpeed die Ein-gangsports des Blocks bezeichnen (in der grafischen Dar-stellung nicht gezeigt). Durch diesen Mechanismus ist esmoglich, Blockbibliotheken fur diskrete Steuerungs- undRegelalgorithmen aufzubauen, ahnlich zu kommerziellenWerkzeugen.

Da ein Berechnungsschritt innerhalb eines Taktes in-nerhalb von Komponenten gekapselt ist, abstrahiert einDFD von den detaillierten zeitlichen Aspekten der Teil-berechnungen, ahnlich zu synchronen Sprachen [6]. ImAutoFocus-Werkzeug wird die Verwendung von synchro-ner Kommunikation von einer Kausalitatsprufung begleitet,die Modelle mit unverzogerten Schleifen ablehnt, da diesenicht implementierbar sind. Die Modellierung ,,gleichzei-tiger“ Aktionen im Modell auf FAA-, FDA- und LA-Ebene stellen eine Abstraktion von moglichen sequenzi-ell geordneten, zeitbehafteten Berechnungen und Nach-richtentransfers auf der Ebene der OA dar. Die Berech-nungen einer Komponente werden taktweise beobachtet:dieser Takt definiert somit implizit die maximale Zeitfur die Summe sequenzieller Berechnungen auf der OA-Ebene.

1 3

Das AutoMoDe-Projekt 51

Abb. 4 Beispiel fur ein DFD zur Radschlupferkennung

Mode-Transition-Diagramme (MTD). Die gegenuber [9] inAutoFocus neu eingefuhrten Mode Transition Diagramswerden auf allen Abstraktionsebenen dazu verwendet, zwi-schen alternativen Betriebsmodi oder Konfigurationen einerKomponente zur Laufzeit hin- und herzuschalten. MTDsbestehen aus Modi und Transitionen zwischen Modi. Da-bei ist die grafische Darstellung ahnlich der eines endlichenAutomaten: Knoten des Graphen entsprechen Modi, Kan-ten entsprechen Transitionen. Jede Transition ist mit einemBooleschen Ausdruck beschriftet, der sich auf die Eingangs-ports der durch das MSD definierten Komponente bezieht.Bei der Ausfuhrung wird in einem gegebenen Systemschrittder Modus uber eine Transition gewechselt, falls die Aus-wertung der Booleschen Bedingung logisch wahr ergibt. Je-dem Modus ist dabei ein untergeordnetes Verhalten in Formeines SSD oder DFD zugeordnet.

Das Verhalten der Komponente zu einem bestimmtenZeitpunkt wird durch das mit dem aktiven Betriebsmodusassoziierten untergeordneten SSD oder DFD definiert. Un-tergeordnete Diagramme konnen beliebig tief hierarchischverfeinert sein. Abhangig vom Modus eines MTDs konnenso unterschiedliche, den Modus zugeordnete DFDs, als Be-rechnungsvorschrift einer Komponente aktiviert sein. Siestellen ein wichtiges und bislang in der Anwendung wenigetabliertes Mittel der Fein- und Grobdekomposition von ein-gebetteten Systemen dar.

Abbildung 5 zeigt ein Beispiel aus einer AutoMoDe-Fallstudie fur die Modellierung von Betriebszustanden

Abb. 5 Beispiel fur ein MTD mit Betriebsmodi einer Motorsteuerung

einer Motorsteuerung. Dabei wird zwischen den ModiPowerDown (ausgeschalteter Zustand), PowerUp (Hoch-lauf der Steuerung) sowie RunMTD (betriebsfahiger Zu-stand) unterschieden und je nach Wertbelegung der Boo-leschen Eingange PowerUpComplete (Beendigung derHochlaufphase) und IgnitionOn (Stellung des Zund-schlosses) zwischen den Modi umgeschaltet.Cluster-Communication-Diagramme (CCD). Cluster Com-munication Diagrams werden auf der obersten Hierarchie-ebene der LA verwendet und zeigen eine an der Verteilbar-keit orientierte Sicht auf die Software-Komponenten. Clu-ster sind die kleinsten verteilbaren Einheiten des Software-Systems, d.h. ein Cluster wird nie auf mehrere Taskseiner Applikation verteilt. Die Partitionierung der FDA-Komponenten in Cluster kann sich dabei beispielsweise anden Clocks orientieren. Je nach Scheduling-Strategie sindan bestimmten Clustergrenzen Verzogerungen im Modellerforderlich: durch geeignete Restrukturierung konnen andiesen Stellen z.B. die durch die SSD-Strukturierung einge-brachten Verzogerungen ausgenutzt werden.

Die grafische Notation fur CCDs entspricht der vonDFDs. Auf CCDs gelten jedoch weitere Einschrankungen:Cluster konnen keine Subcluster enthalten. Ausserdem wer-den die durch die gewahlte Scheduling-Strategie erforder-lichen Verzogerungen zwischen Clustern auf den CCDsuberpruft und durchgesetzt.

Auf der LA-Ebene werden Implementierungstypen ein-gefuhrt. Diese bilden plattformbezogene Eigenschaften desModells in Bezug auf die Implementierung ab. Ein Imple-mentierungstyp ist die konkrete Realisierung eines abstrak-ten Typs, so wie z.B. Int8 die 8-bit-Realisierung des ab-strakten Typs Integer darstellt. Die durch den Ubergangauf Implementierungstypen eingebrachten Anderungen desVerhaltens konnen in AutoFocus simuliert werden.Implementierung von CCDs als kommunizierende Echt-zeittasks. CCDs konnen durch kommunizierende, von ei-nem Echtzeitbetriebssystem gesteuerte Tasks implemen-tiert werden. Typische Implementierungsplattformen imAutomobil verwenden zum Teil praemptives Scheduling.Damit stellen sich einige technische Herausforderungenfur die semantikerhaltende Implementierung von determi-nistischen, logisch gezeiteten Modellen, wie sie in derCCD-Beschreibung inharent sind. In [23] ist ein Verfah-ren beschrieben, wie CCDs mit beliebigen Multiraten aufder Basis von praemptivem Scheduling mit fest vergebe-nen Prioritaten implementiert werden konnen. Die Me-thode basiert auf einer ratenmonotonen Abbildung von mitClocks versehenen Clustern zu priorisierten Echtzeittasks.Dabei wird der Cluster mit der kleinsten Deadline oderPeriode auf die Task mit der hochsten Prioritat abgebil-det. Kommunikation zwischen Clustern muss in bestimm-ten Fallen durch doppelt gepufferte Interprozesskommu-nikation (IPC) [22] abgesichert werden, um die Semantik

1 3

52 Bauer et al.

des Modells in der Implementierung zu erhalten. Die aufder Implementierungsebene auftretenden Verzogerungenwerden dabei auf Modellebene durch die logisch gezeite-ten Verzogerungen an den Clustergrenzen abgebildet. Inder Methodik aus [23] wird gezeigt, dass unverzogerteKommunikation auf Modellebene nur in speziellen Situa-tionen durch Inter-Task-Kommunikation realisiert werdenkann: Dies ist ein Grund fur die oben beschriebenen Ein-schrankungen an CCDs.

6 Beispiel: Antischlupfregelung

Am Beispiel einer Antischlupfregelung (traction control sy-stem/TCS) wird nun der AutoMoDe-Ansatz zur schrittwei-sen Entwicklung automotiver Software beschrieben.

Die Antischlupfregelung sorgt dafur, dass die Rader beimBeschleunigen nicht durchdrehen. Beim Anfahren mit zuviel Gas oder bei schlechtem Fahrbahnuntergrund konneneinzelne Rader durchdrehen. Die Antischlupfregelung ver-gleicht die Raddrehzahlen der Antriebsrader mit der Fahr-zeuggeschwindigkeit. Raddrehzahlen, die einer Fahrzeug-geschwindigkeit uber der tatsachlichen Fahrzeuggeschwin-digkeit entsprachen, deuten auf Schlupf des entsprechendenRads hin. Die Ursache fur diesen Schlupf ist wahrscheinlichein zu hohes Antriebsdrehmoment in Relation zum Fahr-

Abb. 6 DFD der Komponente StabilityIntervention

bahnuntergrund. Im Fall von Schlupf wird ublicherweiseeine der folgenden Aktionen ausgefuhrt:

1. Wenn nur eines der beiden Antriebsradern Schlupf hat,wird das zu schnelle Rad abgebremst.

2. Falls beide Antriebsrader Schlupf haben, wird das An-triebsdrehmoment reduziert. Im Fall eines Ottomotorsmit ,,elektronischem Gaspedal“ kann die Leistungsredu-zierung durch die im Beispiel verwendete Anpassung derDrosselklappenstellung herbeigefuhrt werden.

Ublicherweise interagiert die Antischlupfregelung eng mitdem Antiblockiersystem (ABS). Sowohl das TCS, wie auchdas ABS verwenden die Raddrehzahlen und bremsen ein-zelne Rader getrennt ab.

Das TCS-Modell. Das Verhalten der StabilityInter-vention-Komponente aus Abb. 3 ist als DFD definiert(siehe Abb. 6). Das DFD enthalt die notwendigen Kom-ponenten fur die allgemeine Stabilitatskontrolle und dieFahrdynamik-Eingriffe.Neben der Kern-KomponenteTra-ction_Control ist die StabilityIntervention-Komponente unterteilt in eine Referenzgeschwindigkeits-bestimmung, die Antischlupfregelung, der Brems-Schlupf-Regelung, der Brems-Verzogerungsregelung und einer Ko-ordinierung der einzelnen Bremsanforderungen. Das Ergeb-nis der Koordinierung der Bremsanforderungen dient als

1 3

Das AutoMoDe-Projekt 53

Druckvorgabe fur die einzelnen Radbremszylinder. Die Ab-bildung zeigt zudem schematisch die Ausfuhrungsfrequenzder verschiedenen Komponenten, die durch Clocks der ent-sprechenden Kanale spezifiziert wurde (in der Abbildungsind die Clocks nicht zu sehen).

Abbildung Abb. 7 zeigt die hierarchische Dekomposi-tion der Traction_Control-Komponente (vgl. Abb. 6).Basierend auf den Radgeschwindigkeitssignalen wird eineReferenzgeschwindigkeit errechnet und mit den einzel-nen Radgeschwindigkeiten verglichen. Der daraus ermit-telte Radschlupf wird mit der Referenzgeschwindigkeitnormalisiert. Fur jedes Antriebsrad (im Beispiel die Hin-terrader) wird bestimmt, ob der Wert uber dem Grenzwert(AboveLambda2) oder unter dem Grenzwert (Below-Lambda1) liegt. Auf Basis dieser Klassifikation wird be-stimmt, ob eine Leistungsanpassung des Motors uber dieDrosselklappe erfolgen soll.

Abbildung Abb. 4 zeigt schematisch die Radschlupfer-kennung (WheelSlip), wie sie konkret in den Kompo-nenten TCS_Compute_WheelSlip_RX vorgenommenwird. Auf deren Basis wird die oben beschriebene Klassi-fikation, wie in Abb. 8 gezeigt, definiert. Die Komponentezur Regelung eines Eingriffs in die Motorsteuerung ausAbb. 7 beeinflusst die Stellung der Drosselklappe, falls der

Abb. 7 DFD der Komponente Traction_Control

Abb. 8 DFD der Komponente SlipClassification_RX

Schlupf beider Antriebsrader außerhalb der Grenzwerteist.

Der Umfang der Drosselklappenkorrektur wird in derDrosselklappensteuerung (ThrottleControl)bestimmt.Diese ist Teil der Powertrain-Komponente, die obenrechts in der Abb. 3 zu sehen ist. Die Ansteuerung der Dros-selklappe ist ein Regelungssystem. Dieses besteht aus einemPID-Regler, der den Drosselklappenstellmotor ansteuert.

Entsprechend der zeitlichen Auflosung der Sensorenund Aktuatoren werden Teile der Regelung mit unter-schiedlichen Frequenzen ausgefuhrt. Im Beispiel lauft dieRadgeschwindigkeits- und die Referenzgeschwindigkeits-bestimmung in 6 ms Tasks, wahrend die Antischlupfrege-lung in einer 12 ms Task lauft. Die Drosselklappenansteue-rung erfolgt im 1 ms Raster (vgl. Abb. 6). In AutoFocuswerden die verschiedenen Ausfuhrungsraster durch ver-schiedene Clocks beschrieben. In ASCET bzw. INTECRIOwerden Cluster mit unterschiedlichen Ausfuhrungsrasternauf Tasks abgebildet. Dabei wird jede Task mit einem derClock entsprechenden Ausfuhrungsraster versehen.

7 Ubergang nach ASCET/INTECRIO

Die abstrakte Modellierung basierend auf Nachrichten-stromen und diskreter Zeit in AutoFocus und die Va-lidierung der Regelungsalgorithmen auf FDA- und LA-Ebene ist nur ein Aspekt bei der Entwicklung automo-tiver Software. Um die Eigenschaften der Modelle aufden abstrakten Ebenen zu erhalten, ist es notwendig, dassdie Ubersetzung in echtzeitfahige Systeme die Semantikder Modelle erhalt. Die Synthese eines echtzeitfahigenExecutables aus ASCET besteht aus Tasks, die ihrerseitsvoid(void)-Routinen aufrufen (d.h. keine Ruckgabe-oder Funktionsargumente auf dem Stack). Diese ent-sprechen dem Prozess-Konzept in ASCET. Kommuni-kation zwischen ASCET-Prozessen und -Tasks erfolgtentweder uber Inter-Prozess-Kommunikationsnachrichten(IPC-Nachrichten) oder uber globale Variablen. ASCET-Module gruppieren Prozesse und Nachrichten. Modulekonnen wiederum in einem ASCET-Projekt zusammenge-fasst werden.Das Verhalten von ASCET-Prozessen kann zum einen durchZustandsmaschinen, mit Hilfe der C ahnlichen SpracheESDL, mittels C-Code oder in Form von Blockdiagrammenerfolgen. Die AutoMoDe-Werkzeugkette verwendet in er-ster Linie Blockdiagramme, da so die AutoFocus-Modelleauf die naturlichste Weise dargestellt werden konnen. JedesASCET-Blockdiagramm besteht aus elementaren Operato-ren, Variablen und einer totalen Ordnung von Zuweisungenbezuglich eines Prozesses, die durch sogenannte ,,SequenceCalls“ angegeben wird. ASCET-Blockdiagramme sind inihrer Semantik sehr ahnlich zu imperativen Programmier-

1 3

54 Bauer et al.

Abb. 9 Eigenschaften des atomaren Blocks ConstLambda2

sprachen. Ihre Syntax und Semantik unterscheidet sichdaher von AutoFocus-DFDs.

Die AutoMoDe-Werkzeugkette wurde entwickelt, umAutoFocus-Modelle in echtzeitfahige Software zu uber-setzen. Die Kette besteht aus einem AutoFocus-Pluginund den ETAS Werkzeugen ASCET [12], RTA-OSEK [17]und INTECRIO [13] (siehe Abb. 1). Das Plugin uberfuhrtCluster eines AutoFocus-Modell in ASCET-Moduleund -Prozesse. Mit dem ASCET-Codegenerator wird dannC-Code fur die Cluster erzeugt. Anschließend werden dieCluster auf ein ,,Rapid Development System“ uberfuhrt. DieIntegration auf der Zielplattform umfasst die Festlegung ei-nes Betriebssystem-Schedules. Dieses wird aus den Clocksder AutoFocus-Modelle abgeleitet. Zusatzlich mussen diehardware-spezifischen Schnittstellen manuell hinzugefugtwerden. Im Folgenden werden der Reihe nach die verschie-denen Transformationsschritte beschrieben.Modulidentifizierung und Sequenzialisierung. Der Auto-MoDe-Ubersetzungsalgorithmus transformiert CCD-Clus-ter in ASCET-Module, wobei jedes Modul einen ASCET-Prozess beinhaltet. Wie in Abschn. 5 beschrieben ist, ent-sprechen die Cluster den ,,kleinsten verteilbaren Einheiten“.Jeder Cluster wird durch eine Verhaltensbeschreibung inAutoFocus, wie beispielsweise einem moglicherweise hier-archischen DFD, definiert.

Jeder Cluster entspricht einem flachen Blockdiagrammin ASCET1. Aus den hierarchisch strukturierten DFDswerden die atomaren AutoFOCUS-Blocke in eine Anzahlvon Operatoren, Verbindungen, IPC-Nachrichten und denentsprechenden Ausfuhrungssequenznummern in ASCETubersetzt. Die Sequenzialisierung kann dabei direkt aus derkausalen Ordnung, die der AutoFocus-Semantik zugrundeliegt, abgeleitet werden.

Als ein einfaches Beispiel einer Blockdiagrammuber-setzung wird die Grenzwertuberprufung in der KomponenteSlipClassification_RX betrachtet (vgl. Abb. 8). RXsteht dabei fur RL (Rear Left) oder RR (Rear Right). DieKomponente uberpruft, ob der tatsachliche Schlupf uberdem Grenzwert lambda2 liegt. Der Block ConstLamb-da2 stellt die Konstante lambda2 zur Verfugung und istdurch einen einfachen textuellen Ausdruck definiert (vgl.Abb. 9). Der Block AboveLambda2 liefert das Ergeb-nis des Vergleichs von Lambda2 und WheelSlip. DieSelector-Funktion wheel_slip wird benotigt, da der Typ

1 Die Ubersetzung der Hierarchie ist technisch zwar moglich, wurdeaber in der aktuellen Werkzeugkette nicht verwirklicht.

Abb. 10 Eigenschaften des atomaren Blocks AboveLambda2

Abb. 11 ASCET-Blockdiagramm fur AboveLambda2

WheelSlip als ein ,,Wrapper“-Datentyp in AutoFocusrealisiert ist: data WheelSlip = MakeWheelSlip(wheel_slip:Float). Abbildung Abb. 11 zeigt dieUbersetzung dieser beiden Blocke in ein ASCET-Blockdiagramm.

Die vollstandige Ubersetzung in das ASCET-Blockdia-gramm des Clusters SlipClassification_RX ausAbb. 8 wird in Abb. 12 gezeigt. Das DFD zum SlipClas-sification_RX-Cluster wird in ein Blockdiagrammmit drei Ausfuhrungsschritten innerhalb eines Prozessesubersetzt. Die Anzahl der notwendigen ASCET-Prozesse istabhangig von der Anzahl der Clocks, die dem AutoFocus-Modell zugrunde liegen. Im Beispiel von SlipClassi-fication_RX enthalt das Modell nur eine Clock. Daherwird fur die Ubersetzung ein ASCET-Prozess benotigt. DieZuweisung von Ausfuhrungsreihenfolgen folgt den Kau-salitaten, die inharent in einem DFD festgelegt sind. ImBeispiel werden drei Ausfuhrungsschritte benotigt. Zuerstwird der Variable NegWheelSlip als Teil des Ausdrucksdes IF-Anweisung bestimmt (/5/process). Anschlie-ßend werden BelowLambda1 und AboveLambda2 be-stimmt (/7/process and /8/process).

Die Ubersetzung ist optimiert, so dass nur eine mini-male Anzahl von internen Hilfsvariablen, die die Kanalereprasentieren, benotigt wird. Im Beispiel wird die in-

Abb. 12 ASCET-Blockdiagramm SlipClassification_RX

1 3

Das AutoMoDe-Projekt 55

terne Variable NegWheelSlip eingefuhrt. Diese Varia-ble speichert das Ergebnis des WheelSlip-DFD-Blocksund wird fur die Berechnung von BelowLambda1 undAboveLambda2 benotigt.

Jeder externe Port eines Clusters wird in eine IPC-Nachricht ubersetzt. Im Beispiel wird der Cluster Slip-Classification_RX in das Modul aus Abb. 13 uber-setzt. CCDs werden noch nicht explizit durch die grafischenAutoFocus-Editoren unterstutzt. Daher entsprechen Clu-ster speziellen AutoFocus-Komponenten, die durch denStereotype � cluster � markiert wurden (dieser istin den Abbildungen nicht sichtbar). Im Beispiel werdeneine ,,Receive“-IPC-Nachricht fur den Wert von ,,wheelslip“ und zwei ,,Send“-IPC-Nachrichten des ASCET-Typslogic benotigt.

Der Algorithmus fur die Erstellung einer Clusterungwird ebenso wie weitere Modelltransformationen in Auto-Focus mit Hilfe der sogenannten operation definitionlanguage (ODL) [25] angegeben. ODL ist eine logikba-sierte Sprache, basierend auf Funktionen und Pradikaten,die fur die Definition von Konsistenzchecks und Trans-formationen benutzt werden kann. Ein ODL-Ausdruckkann Benutzerinteraktionen beinhalten. Zum Beispiel fragtder Clusterungs-Algorithmus den Benutzer nach einerClock und einer Teilmenge von Komponenten, die die-sen Clock benutzen. Basierend auf diesen Informationentransformiert der Algorithmus das AutoFocus-Modell, sodass anschließend die CCD-Cluster enthalten sind und

Abb. 13 ASCET-Modul SlipClassification_RL

Abb. 14 ASCET-Module, die drei AutoFocus-Clustern entsprechen

Kommunikationsbeziehungen entsprechend umstrukturiertwurden.Cluster-Definition. Bei der Ubersetzung fur die ClusterVehicleData, Traction_Control und Compu-te_ReferenceSpeed werden drei ASCET-Module(siehe Abb. 14) erzeugt. Im Beispiel sind zudem die Kon-nektoren zwischen den ASCET-Modulen angeben. DieseKonnektoren reprasentieren ASCET-Nachrichten.

Im nachsten Verfeinerungsschritt wird die Gruppierungvon ASCET-Modulen in Projekte angegeben. Module, diein einem Projekt gruppiert wurden, werden auf einer ECUausgefuhrt. Die Gruppierung von Modulen zu Projektenfolgt daher der Abbildung von Clustern auf der LA-Ebeneauf ECUs der TA-Ebene. Ist eine entsprechende Abbil-dung vorgegeben, so kann die Verteilung der Module aufASCET-Projekte automatisiert werden. Die AutoMoDe-Werkzeugkette betrachtet jedoch diese Abbildung nicht.Software-System-Konstruktion. Nachdem alle ASCET-Mo-dule in ASCET-Projekte gruppiert wurden, wird der ASCET-Code-Generator benutzt, um C-Code als Eingabe fur IN-TECRIO zu generieren. Fur jeden Cluster, also fur jedesASCET-Modul, wird dazu C-Code und eine Beschrei-bung im SCOOP-IX-Format generiert. Zusammengenom-men reprasentieren diese ein INTECRIO-Modul (nicht zuverwechseln mit einem ASCET-Modul). Fur die Software-System-Konstruktion in INTECRIO werden alle Clusterals INTECRIO-Module in INTECRIO importiert. An-schließend konnten diese weiter mit den INTECRIO-Funktionalitaten geclustert werden. Das Ergebnis allerClustering-Schritte ist in Abb. 15 zu sehen. Dabei sindSensor- und Aktuator-Module am linken und rechten Randdes INTECRIO-Diagramms abgebildet. Die Ports am Randdes Diagramms stellen die Schnittstelle der Module zu denI/O-Boards des ES 1000 Rapid-Prototyping-Systems dar.Target-Integration. Das ETAS-Rapid-Development-SystemES 1000 ist eine VME-Bus-basierte Prototyping-Hardware.Fur das Beispiel der Antischlupfregelung wurde ein Micro-prozessor-Board (ES 1135), ein A/D-Konverter-Board (ES1303) und ein PWM-Board (ES 1330) eingesetzt. DieSoftware-Schnittstelle des A/D-Konverter-Boards in Formeines INTECRIO-Moduls ist die Grundlage fur die Anbin-dung der PWM-Signale an den Drosselklappenstellmotorund die Bremszylinderansteuerung.OS-Konfiguration. Auf der Ebene der AutoFocus-Modellebesteht die Antischlupfregelung aus Nachrichtenstromen,die mit unterschiedlichen Clocks getaktet sind. Aus dermodellbasierten Sicht lauft die Komponente fur die Dros-selklappenansteuerung sechs mal so schnell wie die Kom-ponente fur das Antiblockiersystem und zwolf mal soschnell wie die Komponente fur die Antischlupfregelung.Dieses auf Clocks basierende Modell wird in ein echt-zeitfahiges System ubersetzt. Dabei wird die Drossel-klappenansteuerung im 1 ms Raster ausgefuhrt. Aus der

1 3

56 Bauer et al.

Abb. 15 Die Antischlupfregelung in INTECRIO

Kombination mit den Clocks des AutoFocus-Modells er-geben sich dann also Tasks im 1 ms, 6 ms und 12 msRaster. Die Prozesse der INTECRIO-Module der einzel-nen Komponenten werden dann den entsprechenden Taskszugeordnet.

Wie in Abschn. 5 besprochen, beschreibt [4] ein ,,correct-by-construction“-Verfahren zur Umsetzung von zeitsyn-chronen AutoFocus-Modellen basierend auf einem raten-monotonen Scheduling. Der Ansatz nutzt die oben be-schriebene Doppel-Puffer-Technik fur die Kommunikationvon niederfrequenten zu hochfrequenten Tasks. Fur dieAnalyse dieser Default-Konfiguration kann die Planner-Funktionalitat des Werkzeugs RTA-OSEK [17] eingesetztwerden, das auf in [27] beschriebenen Algorithmen basiert.

Im dem Fall, dass der einfache ratenmonotone top-downAnsatz aus [4] nicht ausreicht, konnen die Algorithmenaus [3] eingesetzt werden, um bottom-up sicherzustellen,dass ein Multi-Clock-System ordnungsgemaß durch ein ge-gebenes Scheduling umgesetzt wurde. Die Grundidee derAlgorithmen ist die Uberprufung, dass alle Signale im ent-sprechenden Zyklus gelesen werden und keine schreibendeKomponente durch eine lesende Komponente uberholt wird.Uber den Gebrauch derartiger Checkalgorithmen hinaus istes derzeit die gangige Praxis, dass Scheduling-Analysen aufder Messung der Ausfuhrungszeiten beruhen [26].

8 Zusammenfassung und Ausblick

Der hier abschließend vorgestellte AutoMoDe-Ansatz zurmodellbasierten Entwicklung softwareintensiver Systemeim Automobil basiert auf einem integrierten Domanenmo-

dell mit alternativen Sichten, Notationen und einem ein-heitlichen Berechnungsmodell. Der Entwicklungsprozessfur Automotive-Software wird dabei auf verschiedenenAbstraktionsebenen unterstutzt, die jeweils fur gegebenemethodische Zwecke und Entwicklungsphasen maßge-schneidert sind. Gegenuber vorausgegangenen Arbeitenim AutoFocus-Umfeld wurden spezifisch fur die DomaneAutomotive neue Beschreibungstechniken eingefuhrt, ins-besondere zur Darstellung von regelungstechnischem Da-tenfluss, zur expliziten Modellierung von Betriebsmodi,sowie zur Unterstutzung spater Entwicklungsphasen inHinblick auf eine Implementierung von Modellen alsEchtzeitsysteme.

Als wichtige methodische Erganzung zu den reinen No-tationen wurden in diesem Artikel eine Reihe von Trans-formationen innerhalb sowie zwischen Abstraktionsebenendiskutiert. Einige der angesprochenen Transformationensind bereits im AutoFocus2-Werkzeugprototypen imple-mentiert und automatisiert, wie z.B. die im vorigen Ab-schnitt beschriebene Sequenzialisierung von Modellen, dieUbersetzung nach ASCET, oder die OS-Konfiguration. An-dere hingegen, wie die Modulidentifizierung oder Cluster-Definition verlangen ein großeres Maß an Benutzerinter-aktion, da hier bewusst Freiheitsgrade ausgenutzt werdenkonnen, die aus der konkreten Anwendung heraus mo-tiviert sind. Dank der ODL ist es jedoch moglich, auchsolche Schritte bei z.B. haufig wiederkehrenden Ablaufenzu automatisieren.

Die in AutoMoDe entwickelten Konzepte wurden daruberhinaus in vielen Punkten mit den aktuellen Entwicklun-gen der AUTOSAR-Entwicklungspartnerschaft [24] abge-stimmt, im Hinblick auf eine bessere Ubertragbarkeit von

1 3

Das AutoMoDe-Projekt 57

Ergebnissen in die Praxis mit der anstehenden Einfuhrungvon AUTOSAR in die Serienentwicklung bei den beteilig-ten Industriepartnern.

Der hier beschriebene Ansatz wurde mit einer umfang-reichen Fallstudie aus dem Bereich der Fahrdynamiksteue-rung abschließend erprobt und auf allen Abstraktionsebe-nen validiert. Im Ergebnis entstand auf konkreter Imple-mentierungsebene ein Demonstrator, der die im abstraktenModell definierte Funktionalitat des Softwaresystems alskonkrete Echtzeitanwendung mit physikalischen Sensorenund Aktuatoren umsetzt. Somit konnte gezeigt werden, dassin AutoMoDe durch einen phasenubergreifenden, homo-genen Ansatz unter Einsatz von Transformationstechnikenund Konsistenzprufungen auch anspruchsvolle Softwarean-wendungen effektiv, konsistent, und mit engem Bezug zukommerziell etablierten Werkzeugketten entwickelt werdenkonnen.

Literatur

1. Das Projekt EAST-EEA – Eine middlewarebasierte Softwarear-chitektur fur vernetzte Kfz-Steuergerate. In: VDI-Kongress Elek-tronik im Kraftfahrzeug. Number 1789 in VDI Berichte. Baden-Baden, 2003

2. Amalio N, Polack F (2003) Comparison of formalisation approa-ches of UML class constructs in Z and Object-Z. In: ZB 2003.volume 2651 of LNCS. Springer

3. Baleani M, Ferrari A, Mangeruca L, Sangiovanni-Vincentelli AL,Freund U, Schlenker E, Wolff HJ (2005) Correct by construc-tion transformations across design environments for model-basedembedded software development. In: DATE 05

4. Bauer A, Romberg J (2004) Model-based deployment in automo-tive embedded software. In: MOMPES 2004

5. Bauer A, Romberg J, Schatz B (2005) Integrierte Entwick-lung von Automotive-Software mit AutoFocus. Informatik ForschEntw 19(4):194–205

6. Benveniste A, Caspi P, Edwards S, Halbwachs N, Guernic PL,Simone RD (2003) The Synchronous Languages Twelve YearsLater. Proc IEEE 91(1):64–83

7. Benveniste A, Caspi P, Guernic PL, Halbwachs N (1993) Data-Flow Synchronous Languages. In: REX School/Symposiumpp 1–45

8. Braun P, Lotzbeyer H, Schatz B, Slotosch O (2000) Consistentintegration of formal methods. In: TACAS 2000 number LNCS2280. Springer

9. Broy M, Huber F, Schatz B (1999) AutoFocus – Ein Werk-zeugprototyp zur Entwicklung eingebetteter Systeme. InformatikForsch Entw 14(3):121–134

10. Broy M, Stølen K (2001) Specification and Development of In-teractive Systems: Focus on Streams, Interfaces, and Refinement.Springer

11. Damm W (2006) Embedded system development for automotiveapplications: trends and challenges. In: EMSOFT. ACM. ed byMin SL, Yi W

12. ETAS GmbH (2001) ASCET-SD Benutzerhandbuch13. ETAS GmbH (2005) INTECRIO User Guide V 1.014. France R, Evans A, Lano K, Rumpe B (1998) The UML as a for-

mal modeling notation. Comput Stand Interf 19(7):325–33415. Giese H, Burmester S, Schafer W, Oberschelp O (2004) Modular

design and verification of component-based mechatronic systemswith online-reconfiguration. In: FSE-12. ACM

16. Huber F, Schatz B, Einert G (1997) Consistent Graphical Specifi-cation of Distributed Systems. In: FME’97, LNCS 1313. Springer

17. LiveDevices York (2005) RTA-OSEK User Guide V 4.018. Maraninchi F, Raymond Y (2003) Mode-automata: a new

domain-specific construct for the development of safe criticalsystems. Sci Comput Program 46(3):219–254

19. The MathWorks Inc. (2000) Using Simulink20. Muller-Glaser KD, Frick G, Sax E, Kuhl M (2004) Multipa-

radigm Modeling in Embedded Systems Design. IEEE TransControl Syst Technol 12(2):279–292, March

21. Mutz M, Huhn M, Goltz U, Kromke C (2003) Model based sy-stem development in automotive. In: SAE World Congress

22. Poledna S, Mocken T, Scheimann J, Beck T (1995) Ercos: Anoperationg system for automotive applications. In: SAE WorldCongress

23. Romberg J (2006) Synthesis of distributed systems from synchro-nous dataflow programs. PhD thesis TU-Munchen

24. Scharnhorst T, Heinecke H, Schnelle KP, Fennel H, Bortolazzi J,Lundh L, Heitkamper P, Leflour J, Mate J, Nishikawa K (2005)Autosar – challenges and achievements. In: Elektronik im Kraft-fahrzeug 2005. VDI, October

25. Schatz B, Braun P, Huber F, Wisspeintner A (2005) Checking andtransforming models with AutoFocus. In: ECBS 2005. IEEE

26. Schauffele J Zurawka T (2003) Automotive Software Enginee-ring. Vieweg Verlag, Wiesbaden

27. Tindell K, Clark J (1994) Holistic schedulability analysis for dis-tributed hard real-time systems. Eur J 40:117–134

28. von der Beeck M, Braun P, Rappl M, Schroder C (2003) Au-tomotive UML. In: Selic B, Martin G, Lavagno L (eds), UMLfor Real: Design of Embedded Real-Time Systems, number ISBN1-4020-7501-4. Kluwer Academic Publishers

1 3