Selbstkonfiguration und Selbstheilung in AUTOSAR · Zusammenfassung Mit dem Einzug der Elektronik...

Universitat AugsburgLehrstuhl fur Systemnahe Informatik und Kommunikationssysteme

Diplomarbeitim Studiengang

”Diplom Informatik“

Selbstkonfiguration und Selbstheilungin AUTOSAR

Markus Helbig

28. September 2006

Erstgutachter: Prof. Dr. Theo UngererZweitgutachter: Prof. Dr. Bernhard Bauer

Betreuer: Dr. Wolfgang Trumler

Copyright c© Lehrstuhl fur Systemnahe Informatik und KommunikationssystemeProf. Dr. Theo UngererInstitut fur InformatikUniversitat AugsburgD-86135 Augsburg, Germanyhttp://www.Informatik.Uni-Augsburg.DE— all rights reserved —

Zusammenfassung

Mit dem Einzug der Elektronik in moderne Autos sind diese so sicher und komfortabelwie nie zuvor. Doch hat sich die Elektronik auch zu einer der haufigsten Pannenursa-chen entwickelt. Daher ist es notwendig an diesem Punkt anzusetzen und Verbesserungenvorzunehmen. In der heutigen Softwareforschung fallt in diesem Zusammenhang immerwieder der Begriff des

”Organic Computing“ und damit verbunden die sogenannten

Selbst-X-Eigenschaften. Ziel dieser Arbeit ist es, eine Architektur mit den FahigkeitenSelbstkonfiguration und Selbstheilung zu entwickeln. Hierbei wird auf der bereits beste-henden AUTomotive Open System ARchitecture aufgebaut, die einige der notwendigenVoraussetzungen zur Verfugung stellt. Zudem soll uber eine Evaluierung der Algorith-men der Frage nachgegangen werden, ob ein Einsatz in solch einem System uberhauptsinnvoll ist und zu Verbesserungen fuhrt. Hierzu wird ein Simulator in Java entwickelt.

Danksagung

Mein besonderer Dank gilt meinem Betreuer Herrn Dr. Wolfgang Trumler fur die her-vorragende Unterstutzung bei dieser Arbeit. Ohne seine Bereitschaft zu zahlreichen Dis-kussionen, seine Vorschlage und seine Kritik, ware diese Arbeit nicht moglich gewesen.Ebenso mochte ich Herrn Prof. Dr. Theo Ungerer fur die Ermoglichung dieser Diplom-arbeit danken. Weiterhin danke ich meinem Zweitgutachter Herrn Prof. Dr. BernhardBauer.

Egling, im September 2006 Markus Helbig

v

Inhaltsverzeichnis

1. Einleitung 1

2. Grundlagen 32.1. Bussysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1. CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2. FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3. MOST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.4. Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Organic Ubiquitous Middleware . . . . . . . . . . . . . . . . . . . . . . . 62.3. OSEK-OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4. AUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.1. Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.3. Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5. Steuergerate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Organic Middleware fur Automotive 173.1. Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4. Konfigurationsbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . 223.5. Metrik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6. Selbstkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.6.1. Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6.2. Optimierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6.3. Schwierigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.7. Selbstheilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.7.1. Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.7.2. Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4. Simulator 374.1. Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2. Benutzeroberflache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3. Batchmodus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

vii

viii Inhaltsverzeichnis

5. Evaluation 455.1. Evaluationsmethodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2. Selbstkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.1. Standardkonfigurationen . . . . . . . . . . . . . . . . . . . . . . . 465.2.2. Zusatzkonfigurationen . . . . . . . . . . . . . . . . . . . . . . . . 485.2.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3. Selbstheilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3.1. Ausfall von Rechenknoten . . . . . . . . . . . . . . . . . . . . . . 505.3.2. Ausfall von Diensten . . . . . . . . . . . . . . . . . . . . . . . . . 545.3.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.4. Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6. Zusammenfassung und Ausblick 59

Literaturverzeichnis 61

Abbildungsverzeichnis 63

A. XML-Schemadefintion der Konfiguration 65

B. Abkurzungen 69

C. Erklarung des Verfassers 71

1. Einleitung

Elektronik bewegt im Auto viel ... [7].

Im Vergleich zu fruheren Jahren hat sich die Bedeutung der Elektronik in modernenAutomobilen stark erhoht. Dieser Entwicklung stehen aber große Teile der Offentlich-keit eher skeptisch gegenuber. Viele befurchten, dass damit ein erhohtes Pannenrisikoeinhergeht. Und das nicht ohne Grund. Laut ADAC Pannenstatistik aus dem Jahr 2005war das Versagen der Elektronik mit 35% die haufigste Ursache fur ein Liegenbleibendes Fahrzeugs [7]. Dennoch geht der Trend (richtigerweise) dazu, noch mehr Elektronik- teilweise ist von bis zu 100 Netzteilnehmern die Rede [11] - in die Autos zu integrieren.Nur so lasst sich der Wunsch nach komfortableren, sichereren und umweltschonenderenAutos erfullen.

Der Großteil der heute verbauten Elektronik stammt nicht mehr aus der Hand der Au-tomobilhersteller sondern von Drittzulieferern wie Siemens VDO oder BOSCH. Um dieQualitat und Zuverlassigkeit zu erhohen, werden seit Jahren Standardisierungsmaßnah-men vorangetrieben. Ein Ergebnis hiervon ist AUTomotive Open System ARchitecture(AUTOSAR). Hierbei handelt es sich um eine Partnerschaft aus den großten Automo-bilherstellern sowie Zulieferern, die es sich zum Ziel gesetzt haben, ein standardisiertesFramework fur jegliche Software im Auto bereitzustellen.

AUTOSAR ist aber weit davon entfernt alle Moglichkeiten des heutigen Wissensstandsauszuschopfen. So sind etwa die Steuergerate immer noch monolithische Bausteine, dennAktuatorik, Sensorik, Sollwertgeber und Recheneinheit bilden eine Gesamtheit. Es be-steht folglich die Gefahr, dass bei Ausfall eines Teilbausteins die Gesamtkomponenteersetzt werden muss, was zu unnotigen Kosten und zu langen Reparaturzeiten fuhrt.Das bisherige System wird auch nicht der standigen Weiterentwicklung der Controllergerecht. Die Entwicklungszyklen der Controller sind deutlich kurzer als die Lebensdauereines Automobils, so dass oft nach wenigen Jahren bereits bessere und schnellere Con-troller als Ersatzteile zur Verfugung stehen wurden.

Vorteilhafter ist es also die Bausteine in Einzelkomponenten aufzuspalten. Dadurch wirdzwar einerseits die Anzahl der Netzteilnehmer im Automobil erhoht, andererseits erge-ben sich aber neue Moglichkeiten. Zunachst reduziert sich die Zahl der notwendigenController pro Fahrzeug, da nicht fur jede Funktionalitat ein eigener Controller notwen-

1

2 1. Einleitung

dig ist und eine Einheit somit auch mehrere Dienste ubernehmen kann. Ebenso wirdes moglich, Einzelkomponenten bei Bedarf zu ersetzen. Damit konnen Controller nundurch ihre meist leistungsfahigeren Nachfolger ersetzt werden. Dank der bereits in AU-TOSAR vorhandenen Abstraktion zur Hardware kann theoretisch sogar jeder beliebigeController eingesetzt werden.

In einem weiteren Schritt sollen dem hiermit geschaffenen verteilten System die Prinzi-pien des Organic Computing beigebracht werden. Genauer gesagt sollen also die Selbst-X-Eigenschaften, wie Selbstkonfiguration, Selbstheilung und Selbstoptimierung, imple-mentiert werden. Der Begriff der Selbstkonfiguration beschreibt die Moglichkeit, dass einSystem durch Kooperation der einzelnen Netzteilnehmer bestimmen kann, wer welcheAufgaben ubernimmt. Die Selbstheilung durch Rekonfiguration erhalt bei Ausfallen dieFunktionalitat des Systems, sofern die notwendigen Ressourcen noch vorhanden sind.Fur eine ausgeglichene Verteilung der Dienste und der damit verbundenen Last sorgtdie Selbstoptimierung. Diese Moglichkeiten werden aus sicherheitstechnischen Grundenallerdings nur fur die nicht sicherheitsrelevanten Systeme des Autos in Betracht gezo-gen. Auch in Zukunft wird es also beim Ausfall, zum Beispiel des ABS, notwendig sein,in der Werkstatt vorzufahren. Dagegen konnen aber Komfortsysteme, wie beispielswei-se Navigationssystem, Fensterheber, usw., durch den Einsatz von Selbst-X am Lebenerhalten werden. Sollte dies aufgrund fehlender Ressourcen beziehungsweise Ersatzfunk-tionalitat nicht mehr moglich sein, werden je nach festgelegter Prioritat die einzelnenDienste heruntergefahren. Dieser Vorgang wird als graceful Degredation bezeichnet. Eskann beispielsweise auf das Fensterhebersystem zu Gunsten der Klimaanlage verzichtetwerden.

Die vorliegende Arbeit beschaftigt sich damit, die beschriebenen Aspekte fur AUTOSARverfugbar zu machen. Einleitend wird eine Einfuhrung in die benotigten Grundlagen inKapitel 2 gegeben, wobei insbesondere aktuelle Bussysteme, eine organische Middlewaresowie der Aufbau heutiger Steuergerate erlautert werden. In Kapitel 3 wird die neu ent-wickelte Architektur fur AUTOSAR mit organischen Eigenschaften vorgestellt. Ebensowerden darin die notwendigen Algorithmen beschrieben. Weiterer Bestandteil der Arbeitist ein Simulator (Kapitel 4), der die beiden genannten Selbst-X-Eigenschaften - Konfi-guration und Heilung - implementiert. Eine Evaluation der Algorithmen findet sich inKapitel 5. Kapitel 6 schließt die Arbeit mit einer Zusammenfassung und einem Ausblickab.

2. Grundlagen

Das folgende Kapitel beschaftigt sich mit den fur diese Arbeit notwendigen Grundlagen.Zunachst wird die Kommunikation im Automobil anhand der verbreiteten Bussystemebeschrieben.

Danach soll auf die vom Lehrstuhl fur Systemnahe Informatik und Kommunikationssys-teme der Universitat Augsburg entworfene

”Organic Ubiquitous Middleware“ eingegan-

gen werden, die die gewunschten Selbst-X-Eigenschaften bereitstellt.

Anschließend wird OSEK-OS, die Grundlage von AUTOSAR, vorgestellt. Der darauffolgende Abschnitt beschaftigt sich mit AUTOSAR selbst. Zum Abschluss wird ein Ein-blick in den Aufbau, die Funktionsweise und die Vielfaltigkeit der heutigen Steuergerateim Automobil gegeben.

2.1. Bussysteme

Die Kommunikation im Auto wird heute durch ein oder mehrere Bussysteme bewaltigt.Ein Bussystem beschreibt im Wesentlichen eine Datenverbindung, an die mehr als zweiTeilnehmer angeschloßen werden konnen. Grundsatzlich hort jeder auf dem BUS, jedeNachricht und entscheidet selbst, ob er diese verarbeitet oder nicht.

Einige Vorteile eines Bussystems, welche auch in [8] zu finden sind:

• Fur jedes Gerat ist lediglich ein Anschluss an den BUS notwendig

• Jeder kann mit jedem kommunizieren

• Moglichkeiten zur redundanten Auslegung und damit Erhohung der Ausfallsicher-heit

• Monitoring des gesamten Netzes moglich

• Standardisierte Kommunikationsprotokolle fuhren zu erhohter Austauschbarkeit

• Verschiedene Topologien des Netzwerks moglich - Reihe, Stern, Baum, vermaschtesNetz, ...

3

4 2. Grundlagen

In der Automobilindustrie kommen derzeit verschiedenste Bussysteme aufgrund der un-terschiedlichen Anforderungen zum Einsatz. Nachfolgend werden die drei wichtigstenund leistungsfahigsten Bussysteme Controller Area Network (CAN), FlexRay und Me-dia Oriented System Transport (MOST) vorgestellt. Am Ende findet sich noch ein kurzerVergleich dieser Systeme hinsichtlich ihrer Fahigkeiten.

2.1.1. CAN

Der Controller Area Network BUS [18] gehort zu den sogenannten Feldbussen. CANwurde 1983 von BOSCH entwickelt und zwei Jahre spater in Zusammenarbeit mit Intelvorgestellt. Ziel von BOSCH war es, die Steuergerate im Auto miteinander zu vernetzen.Dies sollte die damaligen Kabelbaume reduzieren und so unter anderem zu Gewicht-seinsparungen fuhren. Allerdings befinden sich heute wiederum bis zu 3,8 km Kabel [10]in Autos der Oberklasse.

Der CAN BUS ist in der Lage bis zu 32 Knoten pro Teilnetz zu verwalten. Hierbeikommen je nach Buslange Ubertragungsgeschwindigkeiten von 10 kB bis zu 1 MBit zuStande. Als Kommunikationsleitung dienen Twisted Pair Kabel, wie sie ebenfalls furEthernet Netzwerke verwendet werden. Im Fall einer Storung kann CAN auf eine Ein-drahtleitung zuruckgreifen. Das Versenden von Nachrichten erfolgt, sofern der BUS freiist, oder die Prioritat hoch genug ist. Die verschickten Nachrichten kann jeder Teil-nehmer mithoren und bei Bedarf verarbeiten. Deshalb kennen Knoten im Wesentlichenzwei verschiedene Betriebsmodi: Senden und Empfangen. Um eine moglichst fehlerfreieKommunikation zu ermoglichen, kommen altbewahrte Methoden zum Einsatz, wie CRC,Bitstuffing oder Monitoring.

2.1.2. FlexRay

FlexRay [9] ist ein relativ neuer BUS, der im Jahr 1999 von BMW und Daimler-Benzspezifiziert wurde. Die ersten Implementierungen erschienen im Jahr 2003 und sind heu-te bereits im BMW X5 zu finden. Die Entwicklung fand im Hinblick auf die X-by-WireSysteme statt. Hierbei wird mechanische Funktionalitat durch elektronische Weg ersetztbeziehungsweise unterstutzt. Ein Beispiel hierfur ist Steer-by-Wire. FlexRay ermoglichtsowohl synchrone als auch asynchrone Ubertragung bei Geschwindigkeiten von bis zu 10MBit. Ebenso zeichnet sich FlexRay durch eine hohe Fehlertoleranz und die Existenzeiner globalen Zeit aus.

2.1. Bussysteme 5

2.1.3. MOST

Ein ebenfalls von BMW und Daimler entwickeltes Bussystem ist MOST [14], welches imJahr 1998 vorgestellt wurde. Ziel dieser Entwicklung war es, im Auto eine Hochgeschwin-digkeitskommunikation fur Multimedia-Anwendungen wie Audio, Video und Internet zuschaffen. Derzeit werden Geschwindigkeiten von 24,8 MBit bei synchroner sowie 14,4MBit bei asynchroner Kommunikation erreicht. Als Medium wird hierfur ein PlasticOptic Fibre Kabel verwendet. Da es sich bei den hierfur vorgesehenen Anwendungenum zeitkritische Funktionalitat handelt, ist der MOST BUS echtzeitfahig gestaltet wor-den. MOST bietet ebenso Kompatibilitat zur PC-Industrie.

2.1.4. Vergleich

CAN MOST FlexRay

Anwendung Soft-Real-Time-Systeme

MultimediaTelematik

Hard-Real-Time-Systeme

Bandbreite 10 kB - 1 MBit bis zu 24,8 MBit bis zu 10 MBit

Knotenanzahl 32 1 k.A. k.A.

Nachrichtenubertragung asynchron synchronasynchron

synchronasynchron

Buszugriff CSMA/CA TDMCSMA/CA

TDMAFTDMA

Fehlererkennung CRC 15 Bit CRC 4 Byte CRC 24 Bit

Medium elektrisch optischelektrisch

optischelektrisch

Redundanz nicht unterstutzt nicht unterstutzt 2 Kanale

Tabelle 2.1.: Vergleich der Bussysteme

Zusammenfassend ist anzumerken, dass jeder BUS seine Vor- und Nachteile mit sichbringt. Vorzuziehen ist daher eine Kombination der verschiedenen Systeme. Fur die heu-te immer mehr Einzug haltenden Multimediasysteme ist sicherlich der MOST BUS ambesten geeignet, da er die hochsten Durchsatzraten hat, was fur Echtzeitanwendungenwie Video und Audio dringend notwendig ist. Fur die restlichen nicht sicherheitskriti-schen Anwendungen bietet FlexRay die besten Moglichkeiten.

1pro Teilnetz

6 2. Grundlagen

2.2. Organic Ubiquitous Middleware

Am Lehrstuhl fur Systemnahe Informatik und Kommunikationssysteme der UniversitatAugsburg wird bereits seit Jahren eine Middleware fur den Einsatz im Organic und Ubi-quitous Computing Bereich entwickelt. Derzeit ist diese Middleware in der Lage Selbst-konfiguration, Selbstheilung und Selbstoptimierung durchzufuhren. Ziel von AMUN (Au-tonomic Middleware for Ubiquitous eNvironments) ist der Einsatz in einer Ansammlungheterogener Rechenknoten mit unterschiedlichen Anforderungen hinsichtlich Rechenleis-tung, Energieverbrauch und Speicher. Im Wesentlichen besteht diese Middleware ausvier Bausteinen wie in 2.1 zu sehen ist. Diese Komponenten werden nun genauer vor-gestellt. Fur ausfuhrliche Informationen zur Organic Ubiquitous Middleware siehe [24].Eine Anwendung zu AMUN ist das Smart Doorplate Projekt, naheres hierzu in [25].

!"#$%&"'#()*+#,-.%&/0-.-,"#

!"#$%&"'()"#*+&"

,$"()-%./+)&0"#

12)34%(354(%)4#62"2" '(&47%(354(%)4#62"2"

8#+(./4#)'()"#*+&"

12)34%(354(%)4#62"2" '(&47%(354(%)4#62"2"

8#+(./4#)94(("&)4#

!"#$%&"!"#$%&"!"#$%&"

!"#$%&":#4;<!"#$%&"'()"#*+&"

1#3+(%&5+(+3"#

!<.)"754(%)4#

!"=*>94(*%32#+)%4(!"#$%&"

!"=*>1/)%7%?+)%4(!"#$%&"

54(%)4#'(*4#7+)%4(:44=

5")#%&.

!"=*>:#4)"&)%4(!"#$%&"

1$".23%45-2&6"#

+72,(%.,0(.%2(#87"7" 9.&(:%.,0(.%2(#87"7"

;#-.45(#2<(.."&2(#

+72,(%.,0(.%2(#87"7" 9.&(:%.,0(.%2(#87"7"

=>;?;#-.45(#2<(.."&2(#

?55@%&-2%(.!"#$%&"4

!*42":0(.%2(#

!"@AB>!"#$%&"4

C-4%&!"#$%&"4

0(.%2(#9.A(#:-2%(.'((@

!*42":0(.%2(#9.A(#:-2%(.'((@

Abbildung 2.1.: Architektur der Autonomic Middleware fur Ubiquitous eNvironments

Service Schicht

Es gibt drei Arten von Diensten:

• Die sogenannten Basisdienste stellen die Verwaltung der Applikationsdienste sowiederen Auffinden zur Verfugung.

• Des Weiteren gibt es die Applikationsdienste, die die Funktionalitat der Softwareimplementieren. Ein wichtiger Punkt hierbei ist, dass ein Umdenken in der Softwa-

2.3. OSEK-OS 7

reentwicklung notwendig ist, weggehend von den bisher bekannten monolithischenSoftwaresystemen hin zu einer Komposition von Diensten. Diese Dienste konnenbei Bedarf auf andere Knoten verlagert werden und sind nur dann knotengebun-den, wenn es keinen weiteren mit den entsprechend benotigten Ressourcen gibt.

• Am wichtigsten sind die Selbst-X-Dienste, welche in AMUN fur die Selbstkonfigu-ration, Selbstheilung und Selbstoptimierung zustandig sind.

Event Dispatcher

Die Kommunikation ist rein nachrichtenbasiert. Dienste registrieren sich als Listener furall diejenigen Nachrichtentypen, welche fur sie relevant sind. Hierfur existiert eine ent-sprechende Nachrichtentypisierung. Der Event Dispatcher sorgt nach der Registrierungfur die ordnungsgemaße Zustellung. Ebenso erledigt er die Weiterleitung vom und zumTransport Connector.

Transport Connector

Hierbei handelt es sich um eine Trennung zur darunterliegenden Kommunikationsinfra-struktur. Letztlich ist diese Schicht fur die Zustellung von Nachrichten in Richtung deranderen Teilnehmer des Netzes sowie zum Event Dispatcher hin zustandig. Durch dieAbstraktion ist es moglich, je nach verwendetem Kommunikationsprotokoll eigene Im-plementierungen des Transport Connectors zu verwenden.

Organic Manager

Diese Komponente ist fur das Sammeln entsprechender Informationen uber den eigenenZustand sowie den Zustand anderer teilnehmender Knoten verantwortlich. Beispielswei-se sammelt der System Monitor Informationen uber die Lasten der eigenen Dienste, diefur den Selbstoptimierungsmechanismus benotigt werden.

2.3. OSEK-OS

Offene Systeme und deren Schnittstellen fur die Elektronik im Kraftfahrzeug, kurzOSEK, ist ein Standardisierungs-Gremium bestehend aus einigen Kfz-Herstellern, Zulie-ferern und Softwareherstellern. Das OSEK Operation System (OSEK-OS) ist der wich-tigste Standard der daraus entstanden ist. Es handelt sich hierbei um ein Betriebssystem,das vorwiegend im Automobilbereich in eingebetteten Echtzeitsystemen eingesetzt wird.

8 2. Grundlagen

Seit 1997 wird dieser Standard fur die Serienfertigung von Steuergeraten verwendet. Ei-ne detaillierte Beschreibung des OSEK Betriebssystems findet sich in [17].

Durch die Einfuhrung einer Schnittstelle zwischen Applikation und Betriebssystem istes moglich die Software zu portieren und wieder zu verwenden. Portabilitat ist dahin-gehend zu verstehen, dass die darunter liegende Hardware ausgetauscht werden kann.Bei der Verwendung des OSEK-OS ist zu beachten, dass dieses jeweils den Bedurfnissendes Benutzers entsprechend zusammen mit der Applikation kompiliert wird. Notwendigist dies, da die Konfiguration statisch erfolgt, d.h. die Anzahl an Aufgaben, Ressourcenund Diensten wird vom Benutzer statisch festgelegt. Hierbei handelt es sich auch umden großten Nachteil des Betriebssystems, denn jede Anderung zieht ein Neukompilierennach sich.

Dennoch hat das OSEK-OS eine weitreichende Verbreitung gefunden und ist heute Stan-dard in der Steuergerateentwicklung. Ziel ist es OSEK-OS in der Zukunft durch AUTO-SAR zu ersetzen.

2.4. AUTOSAR

AUTomotive Open System ARchitecture ist ebenfalls ein Zusammenschluss verschiede-ner Automobilhersteller - wie zum Beispiel BMW, DaimlerChrysler und Ford - sowieZulieferern - wie BOSCH und Siemens VDO. Das Ziel ist die Schaffung eines Standardsfur die Entwicklung von Softwarekomponenten fur den Automobilbereich. Ende 2006soll der Standard soweit abgeschlossen sein, dass mit der Serienproduktion begonnenwerden kann. Die Zulieferer mussen daher bereits ab Anfang 2007 AUTOSAR konformeSteuergerate liefern [15] um Autos mit dem neuen Standard fertigen zu konnen.

Zu den gewunschten Eigenschaften gehoren nach [5]:

• Implementierung und Standardisierung von Basisfunktionen

• Skalierbarkeit hinsichtlich verschiedener Fahrzeugtypen

• Moglichkeiten zur redundanten Auslegung

• Einbettung von Modulen anderer Hersteller

• Wartbarkeit wahrend des gesamten Produktlebenszykluses

• Software Updates und Upgrades wahrend des gesamten Fahrzeuglebens

2.4. AUTOSAR 9

Um diese Ziele zu erreichen werden in [5] folgende Losungen vorgeschlagen:

• Standardisierung des Austauschformats, womit die Kompatibilitat untereinandererreicht wird

• Basic Software, hierdurch wird die Software Qualitat gesteigert

• Microcontroller Abstraction, so dass Microcontroller ohne notwendige Anderungenin daruber liegenden Schichten ausgetauscht werden konnen

• Runtime Environment, das zu einer einheitlichen Kommunikation sowie der Moglich-keit der Verlegung von Funktionen betragt

• Standardisierung von Schnittstellen, um Probleme zwischen Produkten verschie-dener Hersteller zu vermeiden

Wie dies umgesetzt werden soll, wird in den folgenden Abschnitten vorgestellt. Fur einengenauen Einblick beziehungsweise detaillierte Beschreibungen siehe [5] und [4].

2.4.1. Konzept

AUTOSAR besteht aus verschiedenen Teilkonzepten: der Software, der Kommunikati-onsebene und den sogenannten Grundfunktionalitaten, welche die Hardware bereitstellt.Diese Konzepte werden im Folgenden in der abstrakten Form eingehend betrachtet.Ebenso gehort zu AUTOSAR eine Methodik, wie die Konfiguration und Zuteilung derSoftware zu den einzelnen Electronic Control Units (ECUs) ablaufen soll, siehe Abschnitt2.4.3.

AUTOSAR Software Component

Ein wichtiges Designkonzept in AUTOSAR ist die Teilung in Applikation und Infra-struktur. Eine Applikation besteht aus miteinander kommunizierenden AUTOSAR Soft-warekomponenten. Jede dieser Softwarekomponenten beinhaltet Teilfunktionalitat derGesamtanwendung. Eine Instanz einer solchen Komponente ist an jeweils genau eineHardware gebunden. Eine AUTOSAR SW-C wird als Objektcode oder Quellcode zu-sammen mit einer Softwarebeschreibung geliefert. Die Beschreibung umfasst unter an-derem, wie die jeweilige Infrastruktur konfiguriert werden muss. AUTOSAR sieht vor,dass eine SW-C als Objektcode verbreitet werden kann, was allerdings den Nachteil hat,dass diese stark hardwareabhangig ist. Eine Implementierung als Quellcode ist dage-gen unabhangig von der zugrunde liegenden Hardware. Auch muss nicht die gesamtebenotigte Funktionalitat auf derselben Hardwarekomponente zur Verfugung stehen, dadiese aufgrund der Kommunikationsmoglichkeiten von anderen Hardwarekomponentenuber das Netzwerk bereitgestellt werden kann. Somit ist der Quellcode unabhangig von

10 2. Grundlagen

der verwendeten Netzwerktechnologie. Sensor und Aktuator Software sind Spezialformender AUTOSAR SW-C.

Virtual Functional BUS

Hinter dem Begriff Virtual Functional BUS (VFB) verbirgt sich die gesamte Kommuni-kationsfahigkeit auf einem sehr abstrakten Level. Komponenten in AUTOSAR besitzenjeweils fest definierte Ports, die der Interaktion untereinander dienen. Ein Port ist eindeu-tig zu einer Instanz einer Komponente gebunden, andererseits ist es aber moglich, dasses mehrere Instanzen einer Komponente gibt. Dynamische Instanzierung wird derzeitnicht unterstutzt. Die Mehrfachinstanzierung dient unter anderem der Ausfallsicherheit.Fur die Kommunikation stehen im Wesentlichen zwei Muster zur Verfugung. Zum einendas Client-Server Pattern, bei dem ein oder mehrere Clients die Informationen anfor-dern und der jeweils anbietende Server antwortet. Zum anderen das Sender-ReceiverPattern, mit dem Nachrichten von einem an viele gesendet werden. Es wird ein asyn-chroner Modus angenommen, d.h. der Sender blockiert seine Befehlsausfuhrung auchdann nicht, wenn eine Antwort zuruck erwartet wird, wie es im Fall einer synchronenKommunikation geschehen wurde.

Basic Software

Diese stellt die Funktionalitat einer ECU zur Verfugung. Die Hardwarezugriffe erfolgenuber diese Schicht. Alles was hier nicht angeboten wird, steht im Normalfall nicht zurVerfugung, sondern muss uber spezielle Schnittstellen angesprochen werden. Im Fall derVerwendung solcher Spezialfunktionen wird die Verlegung von Diensten evtl. unmoglich.

2.4.2. Architektur

Eine Steuergerate-Einheit in einem AUTOSAR Auto wird wie Abbildung 2.2 aussehen.Die im vorhergehenden Abschnitt vorgestellte Gliederung in Schichten, wird hier nocheinmal verfeinert und konkret umgesetzt. Von oben nach unten gesehen finden sich dieSoftware Schicht (enthalt die SW-Cs), das Runtime Environment (RTE) (implementiertden VFB), die Basic Software, sowie darunter die zugrunde liegende Hardware. Wie inder Abbildung ebenfalls gut zu sehen ist, beruht alles auf Zwischenschaltung von einheit-lichen Schnittstellen, welche die Unabhangigkeit der einzelnen Bestandteile voneinanderund damit auch die Verlegbarkeit garantieren.

AUTOSAR Software

In dieser Ebene befinden sich die Softwarekomponenten. Dies kann zum einen die not-wendige Software fur die vorhandenen Aktuatoren beziehungsweise Sensoren sein, sowiedie Anwendungssoftware des gesamten Steuergerats.

2.4. AUTOSAR 11

Abbildung 2.2.: Schematischer Uberblick der AUTOSAR ECU Software Architektur

RunTime Environment

Das RTE implementiert die VFB Funktionalitat fur die jeweils verwendete Hardware. Sieist zustandig sowohl fur die interne Kommunikation als auch fur die Verstandigung mitanderen Komponenten innerhalb desselben Steuergerats. Sie stellt unabhangig vom ver-wendeten BUS und den jeweiligen Softwarekomponenten eine einheitliche Kommunikati-onsschnittstelle bereit. Hauptaufgabe besteht darin, die Befehle an die darunterliegendeBasic Software weiterzugeben.

AUTOSAR Basic Software

Wie in der Basic Software Schicht in Abbildung 2.2 zu sehen ist, besteht diese wiederumaus mehreren Teilen.

• Operating System: Das Betriebssystem AUTOSAR OS basiert auf dem bereitsvorgestellten OSEK-OS

• Services: Stellt Sytemdienste wie zum Beispiel Diagnose Protokolle, NVRAM,Flash und Speicher Management bereit

• Communication: I/O Management, Network Management

• Microcontroller Abstraction: Kein direkter Microcontroller Zugriff, dadurch un-abhangig vom jeweiligen Controller

12 2. Grundlagen

• Complex Device Drivers: Falls benotigt, ist hier der direkte Zugriff zu speziellenFunktionen des Controllers moglich

ECU Hardware

Dieser Bestandteil umfasst die verwendete Hardware wie Prozessoren, Aktuatoren undSensoren als.

2.4.3. Vorgehensmodell

AUTOSAR stellt ebenfalls eine Vorgehensmethodik zum Erstellen der Software bereit.Hierbei handelt es sich um eine Kette von Schritten, welche in einer ausfuhrbaren ECUKomponente endet. Zur Visualisierung siehe Abbildung 2.3.

Abbildung 2.3.: AUTOSAR Vorgehen bei der Softwareerstellung [5]

Alle Beschreibungsdokumente liegen in XML vor. Am Anfang steht die Auswahl derHardware- und Softwarebestandteile sowie die Festlegung notwendiger Bedingungen.Hierfur stehen jeweils entsprechende Vorlagen zur Verfugung.

Der nachfolgende Schritt befasst sich mit der Zuweisung der Softwarekomponenten zuden Hardwarekomponenten. Es erfolgt eine Auswertung der benotigten und der vonder Hardware zur Verfugung gestellten Ressourcen. Anhand dieser wird das Mappingdurchgefuhrt. Die vorliegende Beschreibung (System Configuration Description) enthaltdie Beschreibung des Systems, wie unter anderem Topologie, BUS Mapping und welcheSoftware auf welche ECU kommt.

Die nun folgenden Schritte mussen jeweils fur jede ECU einzeln durchgefuhrt werden. An-schließend wird die ECU Information einzeln aus der System-Konfigurationsbeschreibungextrahiert, die fur eine detaillierte Beschreibung der ECU verwendet wird (Schritt: Con-figure ECU).

2.5. Steuergerate 13

Zuletzt wird aus den so gesammelten beziehungsweise generierten Informationen einECU Executable erzeugt. Hierbei wird typischerweise der Code fur beispielsweise dieRTE und die Basic Software generiert. Ebenso wird der vorliegende Sourcecode der Soft-warekomponente kompiliert. Sollte dieser schon als Objektcode vorliegen, dann entfalltdas Kompilieren. Anschließend werden die Einzelbestandteile in eine ausfuhrbare Kom-ponente zusammengefasst. Eine ausfuhrlichere Beschreibung dieses Vorgehens findet sichin Kapitel 3 in [5].

2.5. Steuergerate

In den heutigen Autos beruht jegliche Funktionalitat auf sogenannten Steuergeraten.Die Anzahl dieser variiert je nach Ausstattung sehr stark. Beispielsweise befinden sichim VW Phaeton 64 Steuergerate [10]. In Fahrzeugen der Unter- und Mittelklasse sindbis zu 40 davon zu finden. Steuergerate sind sowohl fur den eigentlichen Zweck - dasFahren - als auch fur die Sicherheits- und Komfortsysteme notwendig. Einen Uberblickuber die gangigsten Steuergerate und deren Aufteilung in die verschiedenen Kategorienbietet Abbildung 2.4.

Die derzeitigen Steuergerate sind meist monolithische Bausteine, d.h. es ist in der Regelnicht moglich, Einzelteile, wie zum Beispiel die Aktuatorik, auszutauschen. Hierdurchentsteht ein unnotiger Kostenaufwand bei Reparaturen. Ebenso spielt hier die Lebens-dauer eines Fahrzeugs eine wichtige Rolle. Derzeit wird mit 12 Jahren gerechnet. Autoswerden heutzutage sehr lange genutzt, die Elektronik wandelt sich dagegen deutlichschneller. So geschieht es haufig, dass ein Controller schon nicht mehr verfugbar ist,oder die verbauten Typen mussen lange Zeit auf Lager gehalten werden.

Ein Steuergerat besteht im Wesentlichen aus einer Controllereinheit und, je nach zuerfullender Aufgabe, einer Anzahl von Aktuatoren, Sensoren und Sollwertgebern. Aktua-toren sind beispielsweise Zundkerzen oder Anzeigeeinheiten, wie der Bildschirm des Navi-gationssystems. Sensoren konnen beispielsweise Drehzahlmesser oder Temperaturfuhlersein. Typische Sollwertgeber sind zum Beispiel das Gaspedal oder der Drehregler desRadios zur Einstellung der gewunschten Frequenz. Abbildung 2.5 zeigt ein Motorsteu-ergerat eines Ottomotors mit den jeweils vorhandenen Gerateteilen fur die RubrikenAktuator, Sensor und Sollwertgeber.

Die Steuergerate kommunizieren untereinander uber einen BUS. Daruber werden jegli-che Informationen wie z. B. zum Betriebszustand ausgetauscht. Ebenso werden externeDiagnose Tools an den jeweiligen BUS angeschlossen, um aktuelle Fahrzeuginformatio-nen auszulesen. Meist wird je nach Kategorie ein anderer BUS eingesetzt, vgl. Abbildung2.6. Diese Abbildung zeigt auch sehr schon die Vernetzung und Anzahl der Gerate.

14 2. Grundlagen

Abbildung 2.4.: Einteilung der Steuergerate nach [20]

Abbildung 2.5.: Motorsteuergerat [20]

2.5. Steuergerate 15

Mär

z 20

06

Intr

anet

: http

://vu

eb00

01.p

cd.

daim

ler-

benz

.com

/info

_por

tal/i

ndex

.php

8784

1EP

/ESC

S21

1 M

OP

FK

om

biin

stru

me

nt

(KI)

Ele

ktro

nis

che

s Z

ün

dsc

hlo

ss (

EZ

S)

Ma

nte

lro

hrm

od

ul (

MR

SM

)

Ze

ntr

ale

s G

ate

way

(Z

GW

)

Au

dio

ga

tew

ay (

AG

W)

Air

ba

g A

RM

AD

A

SA

M/S

RB

-Fa

hre

r

SA

M/S

RB

-Hin

ten

SA

M/S

RB

-Be

ifah

rer

Klim

atis

ieru

ng

sau

tom

atik

(K

LA

)

Sitz

he

izu

ng

/Sitz

be

lüft

un

g/L

en

kra

dh

eiz

un

g

Mu

ltifu

nkt

ion

sste

ue

rge

rät

(MS

S)

An

hä

ng

ers

teu

erg

erä

t (A

AG

)

Sitz

vers

tellu

ng

mit

Me

mo

ry F

ah

rer

(SS

G-F

)

Sitz

vers

tellu

ng

mit

Me

mo

ry B

eifa

hre

r (S

SG

-BF

)

Sta

nd

he

izu

ng

(S

TH

)

Pa

rktr

on

icsy

ste

m (

PT

S)

Tü

rste

ue

rge

rät

vorn

e F

ah

rers

eite

(T

SG

-F)

Tü

rste

ue

rge

rät

vorn

e B

eifa

hre

rse

ite (

TS

G-B

F)

Tü

rste

ue

rge

rät

hin

ten

lin

ks (

TS

G-H

L)

Tü

rste

ue

rge

rät

hin

ten

re

chts

(T

SG

-HR

)

Da

chb

ed

ien

ein

he

it (D

BE

)

Un

tere

s B

ed

ien

Fe

ld (

UB

F)

Ob

ere

s B

ed

ien

Fe

ld (

OB

F)

Re

ifen

dru

ckko

ntr

olle

(T

PM

1)

Rü

ckw

an

dtü

rste

ue

rge

rät

(RW

T)

Pu

mp

e F

ah

rdyn

am

isch

er

Sitz

(P

FD

S)

Fa

hrd

yna

mis

che

r S

itz li

nks

(F

DS

)

Fa

hrd

yna

mis

che

r S

itz r

ech

ts (

FD

S)

Au

tom

atis

che

r L

ad

eb

od

en

(A

LB

)

Rü

ckw

an

dtü

rsch

ließ

un

g (

RW

TS

)

Ko

mb

iinst

rum

en

t (K

I)

Ele

ktro

nis

che

s Z

ün

dsc

hlo

ss (

EZ

S)

Ma

nte

lro

hrm

od

ul (

MR

SM

)

Ze

ntr

ale

s G

ate

way

(Z

GW

)

Mo

tore

lekt

ron

ik (

ME

)

Mo

tore

lekt

ron

ik (

CN

G/C

R)

Ele

ktro

nis

che

s-W

äh

lhe

be

l-M

od

ul (

EW

M)

Ele

ktro

nis

che

-Ge

trie

be

-Ste

ue

run

g (

NA

G-2

)

Se

mia

ktiv

e L

uft

fed

eru

ng

(S

LF

)

Dis

tro

nic

(D

TR

)

Rev

ers

ible

r G

urt

stra

ffer

vorn

e li

nks

Rev

ers

ible

r G

urt

stra

ffer

vorn

e r

ech

ts

Hyd

rau

like

inh

eit

(AB

R)

Hin

tera

chsn

ive

au

reg

ulie

run

g (

HN

R)

Au

dio

ga

tew

ay (

AG

W)

CD

-We

chsl

er

(CD

-C)

Be

die

nte

il (C

OM

AN

D)

TV

-Ko

mb

itun

er

Sp

rach

be

die

nun

g (

SB

S)

Nav

iga

tion

sre

chn

er

Un

ive

rsa

l Ha

nd

y In

terf

ace

(U

HI)

55

MO

ST-

RIN

G

16151413121110987654321

30 3129282726252423222120191817

3836 39 4037 41353433324321

4746454443425

Se

rie

na

uss

tatt

un

g

So

nd

era

uss

tatt

un

g

DY

NA

MIC

S-C

AN

Ze

ntr

ale

s G

ate

way

(Z

GW

)

Le

uch

twe

iten

reg

ulie

run

g M

ast

er

(XA

LWA

)

Le

uch

twe

iten

reg

ulie

run

g S

lave

(X

ALW

A)

DIA

GN

OS

E-C

AN

4 54 55

Hyd

rau

like

inh

eit

(AB

R)

Dre

hra

ten

sen

sor

40 53

CA

N-C

Ma

nte

lro

hrm

od

ul (

MR

SM

)

SA

M/S

RB

-Hin

ten

Re

ifen

dru

ckko

ntr

olle

(T

PM

1)

Mo

tore

lekt

ron

ik (

ME

)

Mo

tore

lekt

ron

ik (

CN

G/C

R)

33322583

16

15

14

13

12

11

10

9

8

7

6

5

43

2

1

30

29

28

27

26

25

24

23

22

21

20

19

18

17

38

36

39

40

37

41

35

34

33

3247

46

45

44

43 4252

51

50

49

48

53

54

55

Ele

ktro

nis

che

s Z

ün

dsc

hlo

ss (

EZ

S)

Klim

atis

ieru

ng

sau

tom

atik

(K

LA

)

Tü

rste

ue

rge

rät

vorn

e F

ah

rers

eite

(T

SG

-F)

Tü

rste

ue

rge

rät

vorn

e B

eifa

hre

rse

ite (

TS

G-B

F)

Tü

rste

ue

rge

rät

hin

ten

lin

ks (

TS

G-H

L)

Tü

rste

ue

rge

rät

hin

ten

re

chts

(T

SG

-HR

)

Key

less

Go

He

ckm

od

ul

Key

less

Go

KG

In

ne

nra

um

Mo

du

l

Key

less

Go

KG

Mo

du

l hin

ten

lin

ks

Key

less

Go

KG

Mo

du

l hin

ten

re

chts

Ele

ktri

sch

e L

en

kun

gsv

err

ieg

elu

ng

(E

LV)

52511810 5049482 212019

31

Abbildung 2.6.: Steuergerate der Mercedes E-Klasse [6]

16 2. Grundlagen

3. Organic Middleware fur Automotive

Ein heute vielbenutztes Schlagwort in der Softwareentwicklung und der dazugehori-gen Forschung ist

”Organic Computing“. Hinter diesem Begriff steht nach [19] das

selbststandige Verhalten autonomer Systeme, welche Umgebungsbewusstsein besitzen.Zudem ist ihr Verhalten zielgerichtet. Hierbei spielt der Begriff der Selbst-X-Eigenschafteine wichtige Rolle. Typische Selbst-X-Eigenschaften sind Selbstkonfiguration, Selbstop-timierung, Selbstheilung sowie Selbstorganisation.

Zweck dieser Arbeit ist es, die bereits vorhandene AUTOSAR Architektur mit organi-schen Eigenschaften zu versehen. Dabei werden beispielhaft die Selbstkonfiguration unddie Selbstheilung betrachtet.

Zuerst werden die Ziele und damit verbundenen Vorteile der”Organic Middleware fur

Automotive“ vorgestellt. Anschließend geht es darum, die dafur notwendige Architekturvorzustellen. Ebenso bietet der neue Ansatz eine entsprechende Methode, um Softwarehierfur zu generieren. Weitere Abschnitte beschreiben das verwendete Konfigurations-schema, die Metrik zur Bewertung sowie letztendlich die Algorithmen zur Selbstkonfi-guration und Selbstheilung.

3.1. Ziel

Zuerst werden einige mogliche Szenarien - mit nun moglichen Losungen - betrachtet, wiesie heute im Automoblibereich in Zusammenhang mit der Elektronik durchaus ublichsind. Daran folgend werden die sich daraus ergebenden Ziele, welche die

”Organic Midd-

leware fur Automotive“ mit sich bringen soll, definiert.

Szenario 1: Sollte an einem heißen Sommertag die Aktuatorik der Fensterheber ausfal-len, so ist dies sehr unangenehm. Die Aktuatorik selbst kann jedoch in diesem Fall nichtdurch andere Bausteine ersetzt werden. Besitzt das Auto aber eine Klimaanlage, so istdies zu verschmerzen. Dieser Aspekt wird durch Priorisierung der Dienste dargestellt.Ist dagegen nun der Bedienhebel fur den Fensterheber defekt, so ware der Fensterhe-bermechanismus an sich noch zu gebrauchen. Es muss lediglich der Befehl zum Senkenbeziehungsweise Heben der Scheiben von einem anderen Schalter kommen. Hier ware esdurch den Selbstheilungsmechanismus moglich, die Funktionalitat des Signalgebens zuverlegen, beispielsweise einen Schalter des Radios dafur zu nutzen.

17

18 3. Organic Middleware fur Automotive

Szenario 2: Angenommen, dass die Softwarekomponente fur die Klimaanlage eines Fahr-zeugs auf einem Steuergerat lauft und der Prozessor auf diesem Gerat nun derart defektist, dass Rechenoperationen fehlerhaft ausgefuhrt werden, so kann es zu einer fehlerhaf-ten Berechnung der Beluftungsstarke kommen. Wenn es nun moglich ware, die Softwareauf einen anderen Controller zu verlagern, liese sich dies vermeiden. Noch einfacherware, wenn die Klimaanlagensoftware in Einzelmodulen vorlage. So musste nur das Mo-dul, welches von dem Fehler direkt betroffen ist, verlegt werden. Dadurch wurde dieKlimaanlage immer - ausgenommen wahrend der Zeit, die fur die Heilung benotigt wird- erhalten bleiben.

Aus diesen Beispielen und unzahligen weiteren Moglichkeiten ergeben sich folgende Ziele,welche von der

”Organic Middleware fur Automotive“ erfullt werden sollten, um einen

reibungslosen Ablauf zu gewahren und um im Fehlerfall moglichst viel der Funktiona-litat aufrecht zu erhalten.

• Unabhangigkeit von der HardwareFur die laufende Software soll es unerheblich sein welcher Controllertyp verwendetwird. Dies wird durch die bereits in AUTOSAR vorhandene Microcontroller Ab-straction erledigt. Vorteil hiervon ist, dass ein defekter Controller jederzeit durcheinen anderen ersetzt werden kann. Somit sind die Hersteller nicht mehr dazu ge-zwungen, Controller viele Jahre vorratig zu halten, um Ersatzteile wahrend derLebensdauer eines Autos bereit zu haben.

• Moglichkeit der Verlegung von SoftwarekomponentenDie Softwarekomponenten sollen auf jedem Knoten im Netz laufen und zum Bei-spiel aus Performancegrunden auch jederzeit auf einen anderen verlagert werdenkonnen. Die Moglichkeit hierzu ist ansatzweise bereits in AUTOSAR durch dieFunktionalitat der RTE verwirklicht.

• Monolithische Bausteine splittenWie zu sehen war, sind Steuergerate heutzutage monolithische Bausteine, welcheAktuatorik, Sensorik und Recheneinheit in sich vereinen. Um die in den Szenari-en beschriebenen Losungsmoglichkeiten zu haben, ist es notwendig diesen Ansatzfallen zu lassen und Einzelkomponenten zu verbauen. In einem Auto der Zukunftsind also Controller-, Aktuator- und Sensorbausteine vorhanden. Um mit ande-ren Komponenten zu kommunizieren, die fur die Erfullung der Aufgabe benotigtwerden, besitzen diese einen Buszugang.

• Software in Einzelmodule splittenEng verbunden mit dem vorherigen Ziel ist, dass auch die Software in Einzelmodulenin das Auto gepackt wird. So kann beispielsweise die Software zur Steuerung des

3.2. Architektur 19

Audiosystems in die Module”Radio“,

”CD“ und

”Verkehrsfunk“ aufgeteilt werden.

In Zukunft werden diese Aufgaben somit von einer Zusammensetzung verschiede-ner Dienste erfullt. Vorteil hiervon ist, dass die Module uber das Rechenknoten-netzwerk verteilt werden konnen und so im Falle eines Defekts zum Beispiel dasModul

”Verkehrsfunk“ durch Verlegung zulasten der CD-Funktion aufrechterhal-

ten werden kann.

• Selbst-XFur die Umsetzung ist der Einsatz von Selbst-X-Eigenschaften, wie Selbstkon-figuration, Selbstheilung, Selbstoptimierung und Selbtsorganisation wichtig. Wiebereits erwahnt, werden in dieser Arbeit nur die beiden ersten dieser Eigenschaf-ten naher betrachtet. Grundsatzlich ist es aber moglich, jede weitere Eigenschafthinzuzufugen.

3.2. Architektur

Zur Verwirklichung der genannten Ziele ist es notwendig die bereits vorliegende AU-TOSAR Architektur weiter aufzuspalten. Hierzu wird eine Aufteilung in drei moglicheBausteine vorgenommen.

• AktuatorbausteinEin solcher Baustein, zum Beispiel der Fensterheber, besitzt einen Buszugang, umBefehle zu empfangen beziehungsweise zu senden. Sollwertgeber werden ebenfallsmit den Aktuatoren abgehandelt.

• SensorbausteinHierbei handelt es sich um einen analog zum Aktuator gefertigten Baustein. Dieserdient zur Abfrage von Informationen - beispielsweise Temperatur - zum derzeitigenZustand im Auto.

• ControllerbausteinUm Software uberhaupt ausfuhren zu konnen, sind Rechenbausteine notwendig.Auf diesen Knoten befinden sich Softwaremodule sowie die Selbst-X-Dienste.

Die Architektur eines Rechenknotens ist in Abbildung 3.1 zu sehen. Es sind einige Ge-meinsamkeiten mit AUTOSAR zu erkennen.

Die in AUTOSAR als SW-C bezeichneten Komponenten finden sich hier als Service wie-der. Ein Dienst ist beispielsweise die

”Geblasesteuerung“ der Klimaanlage. Ein Controller

ist mittlerweile auch in der Lage, je nach verfugbaren Kapazitaten mehrere Dienste zuerbringen. Diese kommunizieren untereinander uber das Runtime Environment.


BUS

ECU

Self-X

Controller

CommunicationDriver

Microcontroller Abstraction

Runtime Environment

Service

Abbildung 3.1.: Architektur eines Controller Knoten

Das hier verwendete Runtime Environment ubernimmt noch weitere Funktionen. UmDienste auf jeden beliebigen Knoten verlagern zu konnen, ist es notwendig, dass jederden entsprechenden Code versteht. Das Runtime Environment kann somit mit der Vir-tual Machine einer Java Runtime verglichen werden. Es ware aber auch moglich dasRuntime Environment ahnlich der Common Language Runtime aus .NET zu gestalten.Ein weiterer Funktionsbestandteil des Runtime Environment wird nachfolgend behan-delt.

Der Nachrichtenaustausch erfolgt uber den BUS. Grundsatzlich hat jeder Knoten dieMoglichkeit, jede Nachricht mitzuhoren. Anhand der Typisierung der Nachricht wirdjeder fur sich entscheiden, ob die Nachricht relevant ist und sie dementsprechend ver-arbeiten. Dies geschieht in dem Runtime Environment, welches sozusagen die Aufgabedes AMUN - Event Dispatchers mitubernimmt. Der Typ der Nachricht wird anhandder in 2.5 vorgestellten Kategorien vorgenommen. Eine Nachricht innerhalb des Navi-gationssystems konnte von folgendem Typ sein: car.navigation.card. Dies fuhrt zu einereindeutigen Identifikation, fur denjenigen, der diese Nachricht verarbeiten muss.

In der”Organic Middleware fur Automotive“ kommen noch spezielle Dienste zum Ein-

satz. Dies sind die mit Self-X bezeichneten Komponenten. Jede der Selbst-X Eigen-

3.2. Architektur 21

schaften wird als Dienst implementiert und ist auf jedem Rechenknoten vorhanden.Aktuatorik und Sensorik benotigen diese nicht. Aufgrund der Verbindung zum Run-time Environment kann so jede Information, die den Knoten erreicht beziehungsweiseverlasst, mitgehort werden. Hierdurch wissen die Dienste jeweils uber den Systemzu-stand Bescheid. Ebenso fallen Monitoring-Dienste in diese Kategorie. Sie werden zumeinen zum Erkennen von Ausfallen einzelner Softwaredienste, Aktuatoren oder Sensorenbenotigt. Zum anderen ist das Vorhandensein von Monitoring-Diensten notwendig furdie Selbstoptimierung, um den derzeitigen Betriebszustand analysieren zu konnen.

Die Komponenten Communication Driver, Microcontroller Abstraction und ECU ent-sprechen den in AUTOSAR vorliegenden Bestandteilen.

Aktuator und Sensor Bausteine unterscheiden sich insofern, als dass diese keine Spezi-aldienste besitzen. Ebenso wird im Regelfall jeweils nur ein Softwaremodul, welches diegesamte Funktionalitat implementiert, vorhanden sein.

Das Netzwerk eines Autos mit dieser Architektur wird aussehen, wie in Abbildung 3.2dargestellt. Es wird eine festgelegte Anzahl von Controller Knoten geben. Ebenso wer-den die vorhandenen Sensoren und Aktuatoren (beinhalten die Sollwertgeber) an denBUS beziehungsweise je nach Notwendigkeit an mehrere Bussysteme angeschlossen sein.

ECU

Self-X

Controller

CommunicationDriver


Runtime Environment

Service

ECU

Sensor

CommunicationDriver


Runtime Environment

Sensor Service

ECU

Actuator

CommunicationDriver


Runtime Environment

Actuator Service

ECU

Sensor

CommunicationDriver


Runtime Environment

Sensor Service

ECU

Actuator

CommunicationDriver


Runtime Environment

Actuator Service

BUS

ECU

Self-X

Controller

CommunicationDriver


Runtime Environment

Service

...

... ...

Abbildung 3.2.: Netzwerkstruktur im Auto


3.3. Vorgehen

Ebenso wie die in 2.4.3 beschriebene Methode zur Generierung ist auch hier eine Abfol-ge von notwendigen Schritten festgelegt. Begonnen wird wiederum mit einer Systembe-schreibung in XML - siehe 3.4. Allerdings ist es nun nicht mehr notig, jeden einzelnenHardwarebaustein fur sich abzuarbeiten und je nach Hardware die entsprechenden Exe-cutables zu generieren.

Es ist lediglich notwendig, die Beschreibung einem Knoten zu ubergeben. Dieser wirdfur die Verteilung im Netz sorgen. Anschließend wird eine Selbstkonfiguration durch-gefuhrt. Dank des Runtime Environment sind die Softwaremodule unabhangig von derzugrunde liegenden Hardware, so dass jeder Dienst auf jedem Knoten gestartet werdenkann, sofern dieser die benotigten Ressourcen bereitstellt. Hierfur ist zum Beispiel eineArt Pool notig, welcher den Code bereitstellt. Der bereitgestellte Codepool sollte redun-dant ausgelegt sein. Sollte es sich um interpretierbaren Objektcode handeln, wird dieserbeispielsweise durch einen Classloader geladen. Im Fall von notwendigen Verlegungenbesteht die Moglichkeit, den Code aus dem Pool zu laden oder diesen vom entsprechen-den Knoten - demjenigen, der diesen Dienst zuvor ausgefuhrt hat - anzufordern.

Die von AUTOSAR bekannte Vorgehenskette wurde stark verkurzt. Zusatzlich entfallendie Iterationen fur die einzelnen Hardwarekomponenten.

3.4. Konfigurationsbeschreibung

Wie in AUTOSAR werden die Konfigurationen in XML realisiert. Dies bringt den Vorteileiner recht einfachen Verteilungsmoglichkeit mit sich und zudem lasst sich XML relativeinfach serialisieren. Dank einer Vielzahl von moglichen Parsern ist auch das Einlesenkein Problem. Beschrieben werden muss sowohl jegliche im Auto verwendete Hardware,wie Controller, Aktuatoren, Sensoren und Sollwertgeber, als auch die Software oder ge-nauer die Dienste, die in dieser Form vorliegen. Das verwendete Konfigurationsschemafindet sich in Anhang A.

Alle Komponenten haben gemeinsam, dass sie Ressourcen zur Verfugung stellen oderbenotigen. Eine Ressource kann zum Beispiel die CPU sein. Fur eine feingranularere Be-schreibung wird eine Ressource mit Values versehen. Diese benotigen eine Einheit, umVergleiche zu ermoglichen, was wiederum fur die Bewertung notwendig ist. Listing 3.1zeigt beispielhaft die Beschreibung eines Fensterhebers, welcher zur Aktuatorik zahlt.Analog hierzu sind die Beschreibungen der Controller, Sensoren und Sollwertgeber.

3.4. Konfigurationsbeschreibung 23

Zur Minimalbeschreibung gehoren hierbei folgende Elemente:

• idIm Gesamtsystem eindeutiger Identifier der Komponente

• nameDient der Beschreibung beziehungsweise Zuordnung der Komponente zu einer Ka-tegorie

• classDie implementierende Klasse der Komponente, welche aus dem Codepool geladenwird

Listing 3.1: Beispiel einer Aktuator Beschreibung

<actuator id=”w i ndow l i f t b a c k l e f t ” name=”windowl i f t ” c l a s s=”de . uau .s i k . ac tuator . impl . WindowLift”><r e s ou r c e name=”motor”>

<value name=”speed” un i t=”ro t a t i on / s”>5</value><value name=” l i f t i n g f o r c e ” un i t=”gramm”>500</value>

</resource></actuator>

Ein weiterer Punkt der Beschreibungen betrifft die Dienste. Die Minimalbeschreibungwird hierbei um das Attribut amount erweitert, welches die Anzahl notwendiger Dienst-leister angibt. Zudem wird das Attribut priority hinzugefugt. Hiermit wird die Wich-tigkeit des Dienstes festgelegt. Dienste konnen zwingend notwendig sein, oder aber beievtl. nicht mehr genugend verfugbaren Kapazitaten kann auf sie verzichtet werden. Dafurkann beispielsweise eine Skala von 0 - 10 vorgesehen werden.

Da die vorgesehenen Controllerknoten nun keinerlei Hardware Verbindung mit den evtl.notwendigen Aktuator-, Sensor- oder Sollwertgeberkomponenten haben, ist es notig, inder Beschreibung der Software notwendige Abhangigkeiten (dependency) zu solchen fest-zulegen. Somit wird sichergestellt, dass ein Dienst nur dann erfullbar ist, wenn auch diedazu notwendigen Komponenten im Auto vorhanden sind.

Abhangigkeiten konnen auch zu anderen Diensten moglich sein, um eventuelle Ersatz-dienste zu definieren. Beispielsweise ist es bei funktionierender Klimaanlage nicht not-wendig, dass der Fensterheberdienst erbracht werden kann. Die dependency wird eben-falls mit den hier gleichbedeutenden Attributen amount und priority versehen. Ein not-wendiges Spezialattribut ist type, um festzulegen, von welcher Art die Abhangigkeit ist.


Listing 3.2: Beispiel eines Dienstes

<s e r v i c e id=”w indow l i f t e r s ” amount=”1” name=”WindowLiftSystem”p r i o r i t y =”2” c l a s s=”de . uau . s i k . s e r v i c e . impl . WindowLift”>

<r e s ou r c e name=”cpu”><value name=”frequency ” un i t=”quantiSpeed”>10</value>

</resource><r e s ou r c e name=”ram”>

<value name=”s i z e ” un i t=”kB”>512</value></resource><r e s ou r c e name=”programSize”>

<value name=”s i z e ” un i t=”kB”>100</value></resource>

<dependency type=”actuator ” amount=”1” p r i o r i t y=”1”>window l i f t b a c k l e f t </dependency>

. . .<dependency type=”senso r ” amount=”4” p r i o r i t y=”1”>push button</

dependency><dependency type=”s e r v i c e ” p r i o r i t y=”1”>a i r c ond i t i on </dependency

></s e rv i c e >

In dem fur diese Arbeit entstandenen Simulator werden nur Dienste und Controllerbetrachtet. Ebenso wird vereinfachend angenommen, dass ein Dienst immer nur voneinem Knoten erbracht wird. Des Weiteren werden keinerlei Abhangigkeiten gepruftund auch das Finden von Ersatzkomponenten, bei Ausfall von Teilen der Aktuatorik,Sollwertgebern oder der Sensorik, entfallt.

3.5. Metrik

Fur die Entscheidung, welche Dienste auf welchen Knoten am Besten erbracht werdenkonnen, ist eine Große notwendig, genannt Dienstgute oder Quality of Service. Hierbeiwird anhand von ubergebenen Eingabewerten ein Wert fur die Dienstgute errechnet.Zur Berechnung werden die benotigten Ressourcen (req) eines Dienstes und die derzeitverfugbaren Ressourcen (av) eines Knotens, sowie die maximal bereitgestellten Ressour-cen (max ) herangezogen. Wie in der Konfigurationsbeschreibung zu sehen ist, enthaltjede Ressource eine Menge von Werten (Values).

Um eine moglichst gleichmaßige Verteilung der Dienste auf die vorhandenen Knoten zuerreichen, ist es notig zu wissen, wie sehr ein Dienst einen Knoten belastet. Dadurchkann jeder Knoten fur sich optimal ausgelastet werden. Zur Verdeutlichung nachfolgendein kleines Beispiel.

3.5. Metrik 25

Beispiel 1: Gegeben sei die Ressource CPU mit Vreq = 40, zwei Knoten (N1 und N2)mit V1max = V1av = 100 sowie V2max = V2av = 200. Wie zu sehen ist, wurde Knoten N2

mit dem betrachteten Dienst sicherlich weniger ausgelastet werden. Knoten N1 hingegenwurde eine Belastung von knapp der Halfte erfahren. Nun stellt sich die Frage, was besserist. Soll Knoten N2 diesen und noch viele andere Dienste erbringen und Knoten N1 evtl.leer ausgehen? Oder soll Knoten N1 diesen Dienst erbringen, um so eine gleichmaßigereVerteilung zu bekommen? Die nachfolgend beschriebene Metrik entscheidet sich fur denzweiten Fall. Sollte Knoten N2 im ersten Fall ausfallen, ware dies wesentlich schlimmer,da nun sehr viel mehr Dienste neu verteilt werden mussten.

0 Vreq

Vav

Vmax

0 Vreq

Vav

Vmax

0 Vreq

Vav

Vmax

- +

Abbildung 3.3.: Metrik

Gesondert zu betrachten ist der Fall, dass die verfugbaren Ressourcen unter den angefor-derten liegen. Fur die moglichen Werte ergeben sich drei Falle, welche grafisch in Abbil-dung 3.3 dargestellt sind. Fur die Berechnung fallen die beiden unteren Falle zusammenzu Vav < Vreq. Formel 3.1 beschreibt diese beiden Falle und liefert den gewunschten Ef-fekt der optimalen Belastungsaussage. Dieser Wert wird pro enthaltenem Value (Anzahlm, Laufindex j) einer Ressource (Anzahl n, Laufindex i) berechnet.

bj =

{1− Vav−Vreq

Vmaxfalls Vav ≥ Vreq

Vav−Vreq

Vmaxansonsten

(3.1)

Fur Beispiel 1 ergeben sich mit der Metrik nun folgende Werte: Knoten N1 mit b = 0.6und Knoten N2 erlangt b = 0.2. Die Entscheidung wird somit zu Gunsten Knoten N1

ausfallen.


Die Bewertung einer Ressource erfolgt durch Aufsummieren der Werte aller Values. An-schließend wird durch die Anzahl der enthaltenen Values geteilt und mit einem konstan-ten Faktor multipliziert, da die Werte sonst recht klein waren. Der verwendete Faktorwird in der Regel 100 sein, so dass eine Aussage in Prozent fur die Auslastung vorliegt.Formel 3.2 legt dies dar.

qosi = c ∗ 1

m

m∑j=0

bj (3.2)

Letztendlich muss fur die Bewertung eines Dienstes noch eine Aufsummierung aller er-rechneten Werte fur die vorhandenen Ressourcen erfolgen, wie in Formel 3.3 dargestellt.

qos =1

n

n∑i=0

qosi (3.3)

Diese Metrik sorgt im Fall von Vreq ≥ Vav fur eine moglichst gleichmaßige Verteilung derDienste, d.h. die Knoten entscheiden sich fur den Dienst mit der hoheren Dienstgute, indiesem Fall im Bereich von 0 bis 100. Falls Vreq < Vav werden die Dienste derart bewer-tet, dass derjenige Knoten, welcher den Dienst besser bewertet, diesen auch erbringenwird, und somit moglichst wenig Uberlastung im System geschaffen wird. Es wird eben-falls auf die hochste gebotene Quality of Service geachtet. Allerdings handelt es sich hierausschließlich um negative Werte, also kleiner null.

3.6. Selbstkonfiguration

Eine Selbstkonfiguration hat zum Ziel, eine vorgegebene Aufgabe selbststandig zu erfullen.Zweck hier ist eine ordentliche Verteilung der Dienste. Der betrachtete Algorithmus er-reicht dies durch Kooperation der Netzteilnehmer, siehe auch [12]. Somit sind alle amErfolg beteiligt.

Zum Verstandnis sei hier ein Beispiel aus der realen Welt erwahnt:

Zur Durchfuhrung eines Festes gibt es verschiedene Aufgaben zu verteilen. Nur beiErfullung aller Aufgaben kann das Fest stattfinden. Einige der zu erledigenden Din-ge erfordern Spezialkenntnisse, die nur wenige Personen haben. Manche Mitarbeiter des

3.6. Selbstkonfiguration 27

Organisationskomitees haben vielfaltige Fahigkeiten und konnen deshalb mehrere Auf-gaben erledigen.

Jeder Teilnehmer am Bewerbungsverfahren erhalt eine Liste der zu erledigenden Auf-gaben und entscheidet fur sich selbst, welche er wie gut erfullen kann beziehungsweisewelche er gerne erfullen mochte. Bei Menschen ist jedoch zu beachten, dass neben ob-jektiven auch subjektive Kriterien zur Entscheidung herangezogen werden.

Anschließend beginnt die Aufteilung; jeder Bewerber verkundet durch lautes Rufen wel-che Aufgaben er ubernehmen mochte. Sollte nun jemand der Meinung sein, er konnedies besser, so wird er versuchen den anderen zu uberstimmen.

Durch das offentliche Ausrufen hat jeder die Moglichkeit mitzuprotokollieren, wer wasmacht. Zuletzt kann durch einen Vergleich der Listen sichergestellt werden, dass jederdieselben Informationen besitzt. Sollte es nun eine Aufgabe geben, fur die keiner qualifi-ziert ist, so wird das Fest nicht stattfinden. Andererseits wird es sicher auch vorkommen,dass es Mitarbeiter gibt, die keine Aufgabe zugewiesen bekommen, da zu viele Personenanwesend sind oder es kann auch vorkommen, dass einige mehrere Aufgaben uberneh-men mussen, um fur ein erfolgreiches Fest zu sorgen.

Wie in diesem Beispiel zu sehen ist, sind drei Phasen notwendig, um zum Ziel zu gelan-gen.

1. Verteilung der KonfigurationJeder Netzteilnehmer erhalt die Konfigurationsbeschreibung und bewertet diese.

2. Aushandlung der DiensteverteilungJeder Knoten bewirbt sich fur die von ihm erfullbaren Dienste und entscheidetzusammen mit den anderen, wer letztlich der Erbringer sein wird. Dies wird solangedurchgefuhrt bis alle Dienste verteilt sind.

3. Verifizierung der KonfigurationenUm Inkonsistenzen zu vermeiden, vergleichen die Knoten ihre gesammelten Infor-mationen und korrigieren diese bei Bedarf.

3.6.1. Algorithmus

Die eben erlauterten drei Schritte des Vorgehens werden nun anhand von Pseudocodenaher beschrieben.


Verteilung der Konfiguration

Nach der Initialisierung des Netzwerks sind die einzelnen Knoten in einem passiven Zu-stand und warten darauf die Konfiguration zu erhalten. Die Konfiguration liegt im XMLFormat vor. Einem Knoten wird mitgeteilt, dass er die Konfiguration einlesen soll undanschließend wird sie an alle Teilnehmer im Netz per Broadcast verteilt.

Nach Erhalt dieser Konfiguration beginnen die Knoten mit der Abarbeitung, welche inAlgorithmus 1 dargestellt ist. Die Knoten befinden sich nun in einem aktiven Zustand.Fur jeden in der Konfiguration enthaltenen Dienst wird zuerst uberpruft, ob die eige-nen Ressourcen eine Erfullung des Dienstes erlauben. Sollte dies nicht der Fall sein, sowerden diese in einer speziellen Liste abgelegt, welche als undoables bezeichnet wird.

Fur den Fall, dass einer Erfullung nichts im Wege steht, wird die zugehorige Dienstguteberechnet, und der Dienst in der doables Liste abgelegt. Das Einfugen in diese Liste er-folgt entsprechend der aufsteigenden Sortierung der Quality of Service Werte. Dadurchwird ein Knoten beim Abarbeiten dieser Liste immer mit dem von ihm am hochstenbewerteten Dienst beginnen.

Algorithmus 1 Initialisieren der Konfiguration

for all Service service in configuration.services doif isProvidable(service) then

qos ← calculateQoS(service);doables.add((qos,service));

elseundoables.add(service);

end ifend for

Nach der Abarbeitung der Konfiguration hat jeder Knoten zwei Listen, in denen er dieInformationen zu den Diensten gespeichert hat. Zum einen die Dienste, die er selbst aufkeinen Fall erfullen kann und zum anderen die Dienste, um die er sich bewerben wird.

Aushandlung der Diensteverteilung

Nun beginnt das eigentlich kooperative Verhalten der Knoten. Sollte der Knoten nochDienste in seiner doables Liste haben, so wird er den ersten Dienst, welcher die personlichhochste Dienstgute hat, aus der Liste herausnehmen. Wurde zwischenzeitlich noch keinErbringer fur den Dienst gefunden, oder der Knoten kann eine hohere Quality of Ser-vice bieten, so wird der Service zur Ausfuhrung markiert. Dementsprechend werden dieRessourcen reduziert und das Netzwerk wird hiervon in Kenntnis gesetzt.


Selbstverstandlich wird an dieser Stelle die Dienstgute noch einmal neu berechnet, dasich die verfugbaren Ressourcen im Laufe der Aushandlung durch Belegung von Diens-ten andert.

In der Nachricht vom Typ PROVIDE CALLOUT zur Bewerbung eines Dienstes wer-den neben dem Dienstnamen noch weitere Informationen wie die Dienstgute und dieeigene ID mitgeschickt. Des Weiteren werden zusatzlich noch drei Kriterien zu einer ein-deutigen Entscheidungsfindung angehangt. Die Notwendigkeit hiervon, wird im Rahmender Beschreibung des Algorithmus 3 erlautert.

Jeder Knoten bewirbt sich in solch einem Durchlauf (Algorithmus 2) um maximal einenDienst, damit die anderen auch die Chance haben, selbst Bewerbungen abzugeben. An-sonsten ware eine gleichmaßige Verteilung nicht moglich.

Algorithmus 2 Abarbeiten der doables Liste

while ! doables.isEmpty() doservice ← doables.removeFirstElement();if !service.isProvided() OR canDoBetter(service) then

qos ← calculateQoS(service);provide(service); {Ressourcen belegen}notifyProvidingService(qos,service);return service;

end ifend while

Um die Konfiguration mit Informationen von anderen Knoten zu vervollstandigen, wech-seln die Knoten ihren Modus und horen auf eingehende Nachrichten aus dem Netzwerk(Algorithmus 3). Dies geschieht im Wechsel mit der Bewerbung um Dienste. Wahrendder Aushandlung erhalt jeder Knoten die Bewerbungsnachrichten seiner Mitbewerber,die dann entsprechend verarbeitet werden mussen.

Sollten noch keine Informationen uber die Erbringung eines Dienstes vorliegen, so wirdsie in die Konfiguration eingetragen. Damit ist wieder ein Stuck mehr der Konfigurationerfullt.

Sollte der Dienst bereits von dem Knoten selbst oder einem anderen erbracht werden,so wird die neu erhaltene Information mit der bereits vorliegenden verglichen. Ist dieeigene besser, wird an dieser Stelle nichts weiter unternommen.

Ist das Gegenteil der Fall, muss anhand der vorhandenen Informationen unterschiedenwerden, wer der Erbringer ist. Ist es nicht der aktuelle Knoten selbst, so wird die Konfi-


guration vervollstandigt. Fur den Fall, dass der Knoten selbst gerade Erbringer ist unddie eigene Information schlechter ist, wird der Knoten den Dienst von seinen zu star-tenden Diensten entfernen und die entsprechenden Ressourcen wieder freigeben. DieserVorgang wird Uberschreibung genannt. Ziel ist es, die Anzahl der Uberschreibungen sogering wie moglich zu halten, um ein unnotig hohes Nachrichtenaufkommen zu vermei-den.

Algorithmus 3 Verarbeiten einer PROVIDE CALLOUT Nachricht

if ! service.isProvided() thenconfiguration.setProvider(provider,service);undoables.remove(service);

elseif ownInformationWorse(service) then

if weAreProvider(service) thenremove(service); {Ressourcen wieder freigeben}

end ifconfiguration.setProvider(provider,service);

end ifend if

Wichtig ist noch zu klaren, wann eine Information schlechter eingestuft wird. Hierfurwerden folgende Kriterien nach der beschrieben Reihenfolge zu Grunde gelegt. Sollte ineinem der Kriterien Gleichheit bestehen, so wird das darauf folgende Kriterium uber-pruft.

1. Quality of ServiceDer Knoten, der die bessere Dienstgute aufweist, wird den Dienst erbringen.

2. Anzahl der laufenden DiensteDer am wenigsten ausgelastete Knoten gewinnt die Aushandlung.

3. Anzahl zum Starten markierter DiensteSollten schon etliche Dienste zum Starten markiert sein, fuhrt dies zu einer deut-lichen Belastung. Deshalb bekommt der Knoten mit der geringeren Anzahl denZuschlag.

4. Anzahl noch machbarer DiensteHat ein Knoten noch die Moglichkeit sich um sehr viele Dienste zu bewerben, wirder dem Knoten, der weniger Dienste in seiner doables Liste hat, nachgeben.

5. ID des KnotenSollte bis hierhin noch keine Entscheidung gefallen sein, so entscheidet die eindeu-tige ID des Knoten. Es ist moglich dahingehend zu entscheiden, dass sowohl die


hohere als auch die niedrigere ID gewinnen kann. Im Rahmen dieser Arbeit wirdder kleineren ID Vorrang eingeraumt.

Verifizierung der Konfigurationen

Nach erfolgter Aushandlung ist noch sicherzustellen, dass jeder Knoten die gleichen In-formationen hat. Auftreten konnen Unterschiede in den Konfigurationen durch Verlustvon Nachrichten oder verstummelte Nachrichten. Der Knoten, der als erstes feststellt,dass seine Konfiguration vollstandig ist, wird diese nach einer festgelegten Timeout-Zeitzur Uberprufung per Broadcast im Netzwerk verteilen.

Sollten Inkonsistenzen vorliegen, sind diese zu beheben. Ansonsten kann es vorkomm-men, dass Dienste gar nicht oder mehrfach gestartet werden.

Algorithmus 4 Verifizieren einer Konfiguration

sendOwnConfig ← false;if configuration.hashCode() != verify configuration.hashCode() then

for all Service service in verify config.services doif ownInformationWorse(service) then

if weAreProvider(service) thenremove(service); {Ressourcen wieder freigeben}

end ifconfiguration.setProvider(provider,service);

elsesendOwnConfig ← true;

end ifend forif sendOwnConfig then

sendConfigurationConflict(configuration);end if

end if

Zur schnelleren Uberprufung wird der Hashwert der Konfigurationen uberpruft. Solltedieser unterschiedlich sein, so ist jeder einzelne Dienst zu uberprufen. Auch hier werdenwieder die genannten Kriterien zu den Diensten verglichen, um so in jedem Knoten diebeste Information zu rekonstruieren. Falls ein Fehler in der Konfiguration festgestelltwurde, wird die eigene Konfiguration - mit eventuellen Verbesserungen - wiederum zurVerifizierung per Broadcast an die anderen Knoten versandt. Dieses Vorgehen stellt Al-gorithmus 4 dar.


Nach erfolgter Verifikation ist nun sichergestellt, dass jeder Knoten uber jeden Dienstdieselben Informationen besitzt. Anschließend kann jeder Knoten die markierten Dienstestarten, und der Betrieb kann aufgenommen werden.

Bei Hinzufugen neuer Hardware kann selbstverstandlich jederzeit eine Neukonfiguration- komplett oder teilweise - durchgefuhrt werden.

3.6.2. Optimierungen

Im Rahmen des Testens der Algorithmen mittels des Simulators ist aufgefallen, dassteilweise noch erhebliches Optimierungspotential besteht. Insbesondere ist es gelungendie Anzahl der notwendigen Uberschreibungen wesentlich zu senken. Zur Optimierungwerden folgende funf Punkte verwendet.

Startzeitpunkt nach Erhalt der Konfiguration

Nach Erhalt der Konfiguration wird der Knoten zuerst alle Dienste bewerten, um soseine Praferenzen fur die Bewerbungsreihenfolge festzulegen. Anschließend wird ohneOptimierung ein zufallsgenerierter Zeitpunkt innerhalb eines festgelegten Intervalls zumStarten der Bewerbungsphase errechnet. In einem Netzwerk sind allerdings die Signal-laufzeiten nicht zu vernachlassigen, wodurch die Konfiguration nicht jeden Knoten zumselben Zeitpunkt erreicht. Dies bringt die Gefahr mit sich, dass Knoten, die eine gerin-ge Dienstgute bieten, fruher mit dem Ausrufen beginnen, und dadurch die Anzahl anUberschreibungen wiederum unnotig erhoht wird.

Um den Zeitpunkt des Konfigurationserhalts moglichst gleichzusetzen, wird deshalb derZeitstempel der Nachricht mit der aktuellen Zeit verrechnet. Vorraussetzung hierfur istnaturlich eine Zeitsynchronisation der Knoten. Moglichkeiten hierzu finden sich in [22].Knoten, die die Nachricht sehr fruh erhalten, werden somit zu einer langeren Wartezeitgezwungen. Dagegen werden Knoten, welche die Nachricht sehr spat erhalten, um sofruher mit den Callouts beginnen.

Weiterhin wird der Beginn der Bewerbungsphase, je nach maximal zu bietender Qualityof Service, nach vorne oder hinten verschoben. Je hoher der Wert desto fruher wird ge-startet. Dementsprechend wird bei einer kleinen Dienstgute langer gewartet. Es werdensomit tendenziell Dienste mit einer hohen Dienstgute angeboten, wodurch es seltener zuUberschreibungen kommt.


Neubewertung der Dienste

Eine bereits in [12] vorgeschlagene Verbesserung ist, dass bei jedem Abarbeitungsvorgangder doables Liste die Dienste neu bewertet werden, und nicht die bei der Initialisierungbestimmte Dienstgute herangezogen wird. Dieses Verfahren wirkt sich sehr positiv aufdie Anzahl der notwendigen Uberschreibungen aus. Denn so konnen zu jedem Zeitpunktdie tatsachlich verfugbaren Kapazitaten betrachtet werden, was einen sehr großen Un-terschied machen kann. Hierzu das folgende Beispiel.

Beispiel 1: Dienst S benotigt 50 Einheiten der Ressource R. Die Hardware stellt hierfur100 bereit. Bei der Initialisierung wird der Dienst mit QoS = 50 bewertet. Nachdemnun bereits Dienste zum Starten markiert wurden, verbleiben von R noch 20 Einheiten.Eine Neubewertung ergibt fur S einen Wert von −30. Die Neubewertung fuhrt also dazu,dass der Dienst nach Moglichkeit nicht mehr auf diesem Knoten ausgefuhrt werden wird.Nach der ursprunglichen Bewertung ware hier allerdings sehr wahrscheinlich eine andereEntscheidung getroffen worden.

Zeitpunkt des nachsten Callouts

Ebenfalls bereits in der AMUN Middleware erfolgreich getestet wurde folgende Opti-mierung, die den Zeitpunkt des nachsten Callouts betrachtet. Standardmaßig wurdenach einem zufallsgenerierten Zeitintervall mit stets gleicher maximaler Obergrenze dernachste Callout statt finden. Um unnotige Nachrichten und damit verbundene Uber-schreibungen zu vermeiden, ist es aber sinnvoll, die anzubietende Dienstgute mit derzuletzt erhaltenen zu vergleichen. Hierfur wird nachfolgende Formel 3.4 verwendet.

next callout =QoSlast received

QoSbest providable

∗ def timeout (3.4)

Um den Nutzen zu verdeutlichen, wiederum ein kleines Beispiel.

Beispiel 2: Die zuletzt empfangene Dienstgute - diese wird als derzeit gangige angeboteneDienstgute angesehen - sei QoSlast received = 40. Falls der Knoten eine hohere Dienstgutevon QoSbest providable = 70 anbieten kann, so ergibt sich ein nachster Callout Zeitpunktvon current time + 1142, unter der Annahme, dass def timeout = 2000 gilt. Sollte le-diglich eine Gute von QoSprovidable = 10 moglich sein, wird der nachste Callout zur Zeitcurrent time + 8000 stattfinden. Als Folge bewerben sich schlechte Knoten tendenziellspater als gute Knoten.


Leeren der doables Liste

Es ware nun moglich, dass ein Knoten aufgrund einer schlechten Dienstgute selten odergar nicht zum Bewerben um Dienste kommt. So wurde er sich mit dem Aufsammeln vonInformationen begnugen und letztendlich entscheiden, dass er eine vollstandige Konfigu-ration hat. Dennoch kann dieser geeignet sein, den ein oder anderen Dienst zu erbringen.Von daher ist es notwendig, dass er die Moglichkeit bekommt, seine doables Liste abzu-arbeiten. Deshalb wird vor dem Entscheiden auf Vollstandigkeit der Konfiguration dafurgesorgt, dass auf jeden Fall die Liste der erbringbaren Dienste durchlaufen worden ist.

Verbesserungspotential

Betrachtet werden muss aber auch das Merkmal Dienstgute. Es stellt sich die Frage obeine Dienstgute von 0.2345 eine signifikante Verbesserung im Vergleich zu 0.2344 bringt.Es wurde festgelegt, dass ein Dienst genau dann besser erbracht werden kann, wenn dieQuality of Service um 10% besser ist, als die gerade gebotene. Selbstverstandlich kannhierbei je nach Anwendung ein anderer Wert sinnvoller sein beziehungsweise fur bessereResultate sorgen.

3.6.3. Schwierigkeiten

Mogliche Probleme konnen auftreten, falls Knoten kurzeitig keine Nachrichten erhalten,weil sie beispielsweise vom Netz getrennt waren. Ebenso konnen verstummelte Nachrich-ten Schwierigkeiten mit sich bringen.

Auswirkungen hiervon sind beispielsweise Knoten, die sich noch in der Bewerbungsphasebefinden - das restliche Netzwerk aber schon beim Verifizieren ist - eine Verifikations-nachricht erhalten. Es ware nun moglich, das gesamte Netz zuruckzusetzen und vonneuem zu beginnen, um so ein optimales Ergebnis zu erzielen. Der Nachteil hiervon istallerdings eine drastische Erhohung der Nachrichtenmenge sowie der Zeit, in der die Kon-figuration abgeschlossen werden kann. Deshalb wird in diesem Fall der Knoten lediglichanhand der erhaltenen Nachricht seine Konfiguration vervollstandigen. Den hierdurchevtl. entstehenden Nachteil einer ungunstigen Lastverteilung wird die Selbstoptimie-rung ausgleichen.

Die weiteren verschiedenen Moglichkeiten werden an dieser Stelle nicht detaillierter be-trachtet. Grundsatzlich ist in solchen Fallen immer ein Kompromiss zwischen geringerNachrichtenanzahl und erzielter Belastung der Knoten zu ziehen. Das vollstandige Sys-tem soll jedoch auch die Fahigkeit der Selbstoptimierung haben. Von daher ist es oftgunstiger zu Gunsten der Nachrichtenanzahl zu entscheiden.

3.7. Selbstheilung 35

3.7. Selbstheilung

Die Selbstheilung erfolgt durch Rekonfiguration, d.h. die zu heilenden Dienste werdenerneut in die Konfiguration gegeben. Ein wesentlicher Aspekt der Selbstheilung ist selbst-verstandlich das Erkennen, dass eine solche notwendig ist. Hierzu konnen verschiedeneMoglichkeiten eingesetzt werden.

MonitoringDurch Monitoring bietet sich die Moglichkeit, in bestimmten Zeitintervallen denAusfall zu erkennen. Beispielsweise konnte ein Monitor alle ihm bekannten Dienste- auch Sensorik und Aktuatorik - durch einen Ping regelmaßig danach abfragen,ob diese noch am Leben sind. Im Optimalfall wird so der Ausfall erkannt, be-vor er dem Benutzer auffallen kann. Ebenso besteht die Moglichkeit, dass jedeKomponente sich selbststandig in bestimmten Zeitintervallen meldet. Dies wirdals Leasverfahren bezeichnet.

Erkennen bei VerwendungSpatestens in dem Augenblick, in dem ein Dienst verwendet werden soll und die-ser nicht antwortet beziehungsweise die gewunschte Aktion nicht ausgefuhrt wird,stellt das System fest, dass dieser Dienst wohl nicht mehr erbracht wird. Diese Me-thode hat naturlich den Nachteil, dass in dem Augenblick der Dienstanforderungdie Selbstheilung erst in Aktion treten kann. Dadurch ergeben sich unliebsameVerzogerungen bei der Benutzung.

Besser ist also die Dienste durch Monitore zu uberwachen, was in der Regel sowiesogeschehen wird, um aktuelle Informationen uber die Performance zu erhalten. Diesegesammelten Informationen konnen dann ebenfalls fur Selbstoptimierungsmechanismenverwendet werden.

Durch Rekonfiguration werden all diejenigen Dienste, welche als ausgefallen erkannt wer-den, erneut an alle teilnehmenden Knoten verteilt. Jeder Knoten beginnt nun wieder mitden in 3.6 beschriebenen Aktionen. Im Anschluss daran werden die Diensten wieder ge-startet, sofern nicht durch Controllerausfall, die Konfiguration unerfullbar wurde. ImOptimalfall lauft das System wieder wie bisher weiter.

Bei der Selbstheilung sind noch verschiedene andere Aspekte relevant. Sollten Diensteaufgrund fehlender Controllerressourcen nicht mehr erbracht werden konnen, so ist an-hand der Konfigurationsbeschreibung nachzusehen ob diese evtl. durch andere Diensteersetzt werden konnen. In diesem Fall und auch dann wenn keine Erfullung mehr moglichist, ist der Benutzer - in diesem Fall der Fahrer - davon in Kenntnis zu setzen.

Weiterhin konnte die Nichterfullbarkeit auch aufgrund eines ausgefallenen Sensors oderAktuators zu Stande kommen. Sollte es nun moglich sein zum Beispiel einen Schalter


im Auto durch einen anderen zu ersetzen, muss ebenfalls eine Mitteilung an den Fahrererfolgen, die erklart, wie in Zukunft die Funktion genutzt werden kann. Solche Mitteilun-gen stellen aufgrund der Vernetzung kein Problem dar. Es reicht aus, eine entsprechendtypisierte Nachricht zu versenden, welche beispielsweise vom Display als auszugebendeMeldung an den Benutzer interpretiert wird.

3.7.1. Algorithmus

Der hierzu gehorende Algorithmus 5 ist denkbar einfach. Die Knoten erhalten eine Nach-richt vom Typ SERVICE HEALING MESSAGE, diese enthalt die neu zu konfigu-rierenden beziehungsweise ausgefallenen Dienste. Da die derzeit vorhandenen Konfigu-rationen der Knoten noch veraltete Informationen haben, wird fur jeden der enthaltenenDienste die derzeitige Information zuruckgesetzt. Anschließend wird lediglich der Selbst-konfigurationsprozess mit eben nur noch einer Teilkonfiguration neu angestoßen.

Algorithmus 5 Selbtsheilungsprozess

for all Service service in killed services doconfiguration.resetService(service);

end forredoConfiguration(killed services);

3.7.2. Optimierung

Eine Moglichkeit der Optimierung stellen die bereits erwahnten Verfahren bei der Selbst-konfiguration dar, siehe 3.6.2.

Durch entsprechenden Timeouts soll dafur gesorgt werden, dass nahezu jeder Knotenmit der Selbstheilung zum gleichen Zeitpunkt beginnt. Hierfur wird die aktuelle Zeitmit dem in der Nachricht enthaltenem Timestamp verrechnet, und der Startzeitpunktfur den ersten Callout entsprechend gesetzt.

Weiterhin ist es auch hier wiederum notwendig, dass derjenige Knoten welcher aufgrundder errechneten Dienstgute am besten geeignet ist, mit den Callouts beginnt. Hierfurwerden alle Dienste bewertet. Anhand der erhaltenen Quality of Service wird der Start-zeitpunkt nach vorne beziehungsweise hinten verschoben. Somit kann sicher gestellt wer-den, dass auch der beste Knoten den Dienst erbringen wird.

4. Simulator

Zur Evaluierung und Visualisierung der Algorithmen wurde ein Simulator entwickelt.Dieser lasst sich mit grafischer Oberflache bedienen, uber die auch der Ablauf verfolgtwerden kann. Um eine leichtere und effizientere Auswertung zu ermoglichen, kann derSimulator ebenfalls vollstandig im Batchmodus betrieben werden.

Geschrieben wurde der Simulator in Java Version 5 [21], weshalb er auf jeder Platt-form verwendet werden kann. Es sind ansonsten keine weiteren Voraussetzungen zurVerwendung notwendig. Fur das Logging wurde das von der Apache Foundation entwi-ckelte Log4J Framework [2] verwendet. Ebenso wurde der Xerces XML Parser [3] fur dieAbwicklung des Einlesens der Konfigurationen eingebunden. Die grafische Oberflachewurde in Netbeans [16] entwickelt. Daher ist ein weiteres Framework swing-layout not-wendig. Diese zusatzlichen Frameworks sind Bestandteil des Simulators, so dass diesenicht selbststandig eingebunden werden mussen.

4.1. Modell

Zur Vereinfachung der Implementierung wurde die Architektur aus 3.2 auf ein wenigerkomplexes Modell abgebildet, welches Abbildung 4.1 zeigt. Fur die Evaluierung hat diesallerdings keinerlei Nachteile, da die Grundfunktionalitat erhalten bleibt.

Das verwendete Modell hat im Wesentlichen folgende Bestandteile:

• ConfigurationDiese enthalt die im Netzwerk vorhandenen Dienste sowie die Hardware. JederKnoten legt hiervon eine eigene Kopie an.

• NodeDiese Klasse reprasentiert einen Controller, Sensor oder Aktuator. Innerhalb die-ser ist die Funktionalitat folgender Bestandteile enthalten: Runtime Environment,Communication Driver, Microcontroller Abstraction.

• ServiceIm Simulator wird die Klasse lediglich als Informationstrager verwendet, um denDiensterbringer und dazu notwendige Informationen zu speichern. Die Semantik

37

38 4. Simulator

1

1

1

1

1

*

*1

Abbildung 4.1.: Vereinfachtes Modell

der jeweiligen Dienste ist fur die Auswertungs- bzw. fur die Simulationszweckeunerheblich.

• ServiceManagerEr enthalt die gesamten Selbstkonfigurations- und Selbstheilungsalgorithmen undentspricht somit der Self-X Komponente. Die Entscheidungsfindung der Erbrin-gung eines Dienstes sowie die in 3.6 und 3.7 beschriebenen Algorithmen sind darinimplementiert. Jeder Controller erzeugt mit Erhalt der Konfigurationsbeschrei-bung seine eigene Instanz des ServiceManagers.

• BUSDie Kommunikation lauft uber eine Singleton Instanz dieser Klasse. Sie ist furdie Verteilung der Nachrichten zustandig. Innerhalb der Auswertung findet hierauch das Zahlen der verschiedenen Nachrichtentypen statt. Eine Einschleusungvon Ubetragungsfehlern findet in der vorliegenden Version des Simulators nichtstatt. Eine Implementierung von Fehlern, wurde hierin Platz finden.

• MessageDa es sich hierbei um ein nachrichtenbasiertes System handelt, ist dies naturlich einwichtiger Bestandteil des Gesamtsystems. Derzeit sind folgende Nachrichtentypenim Simulator implementiert.

1. INIT CONFIGURATION MESSAGEDieser Nachrichtentyp enthalt die Konfigurationsbeschreibung und dient derInitialverteilung im gesamten Netzwerk.

4.2. Benutzeroberflache 39

2. SERVICE PROVIDE CALLOUT MESSAGEHiermit kundigt ein Knoten an, dass er einen bestimmten Dienst erbringenmochte. Bestandteil der Nachricht ist der zu erbringende Dienst selbst, sowiedie weiteren Entscheidungskriterien.

3. VERIFY CONFIGURATION MESSAGEBringt ein Knoten, welcher eine erfullte Konfiguration hat, diese Nachricht inUmlauf, so konnen alle anderen uberprufen, ob sie dieselben Informationengesammelt haben. Sollte es sich in so einem Fall ergeben, dass ein Knoten derMeinung ist, er selbst hat eine bessere Konfiguration fur den einen oder an-deren Dienst, so sendet er per Broadcast erneut seine gesamte Konfigurationzur Verifizierung.

4. SERVICE HEALING MESSAGEFur den Fall, dass der Ausfall eines Controllers und das damit verbundeneWegfallen von Diensten oder der direkte Ausfall von Diensten erkannt wird,wird eine Nachricht mit den wieder neu zu erbringenden Diensten verschickt.

4.2. Benutzeroberflache

Nach dem Starten des Simulators bekommt der Benutzer die in Abbildung 4.2 zu sehen-de Oberflache prasentiert. Es besteht nun die Moglichkeit, Hardware sowie Dienste auseiner XML Datei zu laden. Dabei konnen auch getrennte Hardware- bzw. Dienstedateienverwendet werden. Wie die XML Dateien auszusehen haben, wurde in 3.4 beschrieben.Weiterhin kann der Benutzer an dieser Stelle ein Logging Fenster offnen, welches dengesamten Informations- und Debugoutput des Simulators wiedergibt.

Ebenso konnen an dieser Stelle verschiedene Einstellungen zu den moglichen Optimie-rungen des Algorithmus im Preferences-Dialog vorgenommen werden.

• First Callout TimingHierdurch wird erreicht, dass derjenige Knoten mit den Callouts beginnt, welcherdie hochste Dienstgute erbringen kann. Es spielt dabei keine Rolle, um welchenDienst es sich handelt. Zusatzlich wird dafur gesorgt, dass jeder Knoten zum selbenZeitpunkt mit der Auswertung der erhaltenen Konfiguration beginnt.

• Next Callout TimingAnhand der zuletzt erhaltenen und der selbst am besten zu erbringenden Dienstguteberechnet jeder Knoten den Zeitpunkt fur den nachsten Callout. Je besser der Kno-ten im Verhaltnis zu den anderen ist, desto fruher kann er einen Callout starten.Damit soll vermieden werden, dass Knoten welche bereits an den Grenzen ihrerRessourcen sind, sich spater beziehungsweise gar nicht mehr um weitere Dienstebewerben.

40 4. Simulator

Abbildung 4.2.: Hauptfenster des Simulators mit Preferences-Dialog

• Can Do BetterLediglich wenn ein Knoten besser als 10% des bereits erbringenden Dienstleistersist, wird er sich um diesen Dienst bewerben.

• Doables EmptyJeder Knoten muss seine Liste der moglichen zu erbringenden Dienste abgearbeitethaben, bevor er in die Verifikationsphase eintreten kann.

Nach erfolgter Einstellung geht es mit einem Klick auf Show Network weiter. Abbildung4.3 zeigt ein solches Netzwerk, welches allerdings in der Simulation schon fortgeschrittenist.

Die Knoten werden durch nummerierte Felder visualisiert, die je nach Zustand ihre Farbeandern. Beim Uberfahren mit der Maus werden innerhalb eines Tooltip-Feldes aktuelleInformationen zum Knoten gezeigt. Durch Klicken auf den Knoten werden detailiertereInformationen angezeigt. In diesem Dialog ist es weiterhin moglich, Details zu den ein-zelnen Ressourcen anzusehen.

In dem Detaildialog lassen sich die Dienste mit einem Rechtsklick auf diese nach ab-geschlossener Konfiguration zum Absturz bringen, um so den Selbstheilungsprozess inGang zu setzen. Der Ausfall eines Knotens kann durch einen Rechtsklick auf den Knotensimuliert werden.

4.2. Benutzeroberflache 41

Abbildung 4.3.: Netzwerk mit Simulationsfortschritt

Mogliche Zustande der Knoten sind:

INITDer Knoten wartet auf Erhalt der Konfigurationsbeschreibung.

PROVIDINGJe nach erfulltem Anteil andert sich die Intensitat des Blaus. Der Kno-ten ist zum einen dabei erhaltene Informationen zu speichern und be-wirbt sich zum anderen selbst um mogliche Dienste.

VERIFYDer Knoten ist entweder selbst derjenige, der eine Verifikationsnachrichtversendet hat, oder er hat eine solche zur Uberprufung erhalten.

VERIFY CONFLICTBei der Verifikation wurde ein Konflikt entdeckt.

RUNNINGDie Konfiguration ist vollstandig und zum Starten markierte Dienstewerden ausgefuhrt. Sollten keine Dienste auf diesem Knoten laufen,entfallt das Zahnrad.

KILLEDDieser Controller ist nicht mehr funktionsfahig.

42 4. Simulator

UNDOABLESEs sind unerfullbare Dienste in der Konfiguration, die weder vom Kno-ten selbst noch von anderen Knoten im Netzwerk erfullbar sind. Mitanderen Worten, es liegt eine nicht erfullbare Konfiguration vor.

In der Toolbar befinden sich zur Bedienung des Simulators folgende Buttons.

PLAY/ PAUSE/ STOPHierdurch wird der Simulationsablauf gestartet bzw. fortge-setzt, unterbrochen oder gestoppt.

CHECK CONFIGURATIONDie gerade vorliegenden Konfigurationen in den einzelnen Knoten wer-den auf Konsistenz uberpruft. Sollten sie nicht gleich sein, wird der ersteauftretende Unterschied angezeigt.

SHOW MESSAGE STATISTICHier kann die aktuelle Statistik der bereits verschickten Nachrichteneingesehen werden.

4.3. Batchmodus

Zur effizienteren Auswertung ist es moglich den Simulator im Batchmodus zu betreiben.Hierzu ist ein Aufruf der folgenden Art notwendig:

java -jar SelfXforAUTOSAR.jar eval config 10 10.xml

Eine Beispielkonfiguration zu einer automatischen Auswertung sieht wie in 4.1 aus. Dabeiwerden die zu benutzenden Input- bzw. Outputdateien festgelegt, die zu verwendendenOptimierungen sowie das, was evaluiert werden soll.

Listing 4.1: eval config 10 10.xml

. . .<entry key=”schema− f i l e ” va lue=”re sou r c e /xml/aom . xsd”/><entry key=”hardware− f i l e ” va lue=”re sou r c e /hw10 . xml”/><entry key=”s e rv i c e− f i l e ” va lue=”re sou r c e / s e r v i c e s 1 0 . xml”/><entry key=”eval− f i l e ” va lue=”s t a t s / hw10 s10 con f ig . txt”/>

<entry key=”runs ” value=”100”/>

<entry key=”can−do−bette r−t o l e r an c e ” value=”true”/><entry key=”i n i t−wait−t imes ” value=”true”/><entry key=”qos−wait−t imes ” value=”true”/>

4.3. Batchmodus 43

<entry key=”prov idab le s−complete ” value=”true”/>

<entry key=”eval−c on f i g ” value=”true”/><entry key=”eval−hea l i ng ” value=” f a l s e ”/><entry key=”k i l l −c o n t r o l l e r ” va lue=” f a l s e ”/><entry key=”k i l l −s e r v i c e s ” value=” f a l s e ”/>. . .

Des Weiteren besteht die Moglichkeit eine festgelegte Anzahl von Beispielkonfigurationenfur die Hardware, sowie fur die Dienste zu generieren.

java -jar SelfXforAUTOSAR.jar –gen-hardware/–gen-services

44 4. Simulator

5. Evaluation

Um zu zeigen, dass sich die entwickelten Algorithmen auch in der Praxis bewahren,wurden sie mit Hilfe des Simulators evaluiert. Die Auswertung erfolgt in zwei Teilen.Zunachst wird die Selbstkonfiguration und anschließend die Selbstheilung betrachtet.

5.1. Evaluationsmethodik

Fur jeden Auswertungsschritt wurden 100 Simulationslaufe durchgefuhrt, um so einedeutlichere Aussage treffen zu konnen. Als Hardwarekonfigurationen wurden jeweils 10,25, 50 und 100 Knoten herangezogen. Fur einen spateren Einsatz in Automobilen sindsicherlich Werte zwischen 25 und 50 als realistisch anzusehen. Deshalb sind weitergehen-de Analysen fur 25 und 50 durchgefuhrt worden.

Die einzelnen Controller Knoten bestehen aus einer Mischung von homogenen sowie he-terogenen Typen. In den Konfigurationen sind ca. 60% gleichartige Controller enthalten.Die restlichen verbleibenden 40% werden durch unterschiedliche Controller - bezogen aufdie bereitgestellten Ressourcen - aufgefullt. Gleiches gilt fur die Dienste.

Die Dienstekonfigurationen sind derart ausgelegt, dass ein Dienst ca. 60% eines Knotensauslasten wurde. Auch hier wurde wiederum eine Mischung homogener sowie hetero-gener Dienste verwendet. Fur jeden Teilbereich der Evaluation wurden zuerst folgendeKonfigurationen verwendet 10 Knoten - 10 Dienste, 25 - 25, 50 - 50 und 100 - 100. Diesewerden fortan als Standardkonfigrationen bezeichnet. Des Weiteren folgen 25 - 50, 25 -100, 50 - 100 und 50 - 200. Bei den letzteren ist zu beachten, dass die einzelnen Dienstenicht mehr zu 60% sondern zu ca. 30% bzw. ca. 15% Auslastung je Knoten fuhren. Da-durch wird die Gesamtlast eines Knotens weiterhin bei ca. 60% gehalten.

Um eine Aussage uber den Nutzen und die Fahigkeiten der Algorithmen zu bekommen,ist die Anzahl der verschickten Nachrichten interessant. Das Zahlen der Nachrichten er-folgt direkt im Kommunikationsmedium. Selbstverstandlich gibt es hier ein rechnerischesOptimum. Dieses ergibt sich aus einer Nachricht zum Versenden der Konfiguration, einerNachricht zur Mitteilung, dass die Konfiguration erfullt ist, sowie pro Dienst (Anzahlm) wiederum eine Bewerbungsnachricht. Somit liegt das Optimum bei 2 + m. Weiterhinwird in die Betrachtung der suboptimale Fall einbezogen. Hierbei sind 1 + m + n Nach-

45

46 5. Evaluation

richten notwendig, da im ungunstigsten Fall die Knoten (Anzahl n) gleichzeitig fertigwerden und jeder eine Nachricht zur Verifizierung versendet. Der optimal case und dersuboptimal case sind jeweils rot eingezeichnet.

Alle Simulationslaufe verwenden die gesamte Palette an Optimierungen, welche in 3.6.2und 3.7.2 vorgestellt wurden. Damit werden optimale Ergebnisse erzielt.

5.2. Selbstkonfiguration

5.2.1. Standardkonfigurationen

Zunachst wird die Selbstkonfiguration in den vier genannten Standardkonfigurationenuntersucht (Abbildungen: 5.1, 5.2, 5.3 und 5.4). Wie jeweils zu sehen ist, befindet sich dienotwendige Anzahl an Nachrichten jeweils innerhalb der rot gekennzeichneten Grenzenbeziehungsweise deutlich am Optimum. Im Schnitt werden pro zu erfullendem Dienstjeweils 1,2 Nachrichten benotigt. Damit zeigt sich, dass die Algorithmen skalieren, dadieses Ergebnis unabhangig von den Konfigurationen erreicht wird.

Bei vorangegangenen Tests ist aufgefallen, dass die Nachrichtenanzahl steigt, wenn dieDienste die Knoten weniger auslasten. Die Erklarung hierfur ist, dass in diesen Fallendie Knoten mehrere Moglichkeiten haben, eine großere Anzahl an Diensten zu erbringen.

Fur jede Konfiguration ist jeweils die Abweichung der erreichten Dienstgute zum Er-wartungswert - hier 60% - zu sehen. Dargestellt wird die Abweichung der minimalenund maximalen Dienstgute vom Optimum, die fur einen der zu erbringenden Dienstevorliegt. Ebenso wird die Abweichung der durchschnittlichen Dienstgute dargestellt.

0 20 40 60 80 100

05

1015

2025

30

10 Knoten − 10 Diensten

Simulationen

Nac

hric

hten

Nachrichten gesamtOhne ÜberschreibungVerifikations Nachrichten

0 20 40 60 80 100

−30

−20

−10

010

20

Erreichte Dienstgüte

Simulationen

QoS

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

*

*

*****

*

**

*****

*

**

*

****

***

**

*

***

**

*

*

**

**

*

*

*

*

******

*

*

*

*

*

**

*

*

*

*

*

*

**

***

*

**

*

*

*

*

*

*

*****

*

***

*

*

*

*

*

*

**

*

*

*

**

*

Maximale QoSDurchschnittliche QoSMinimale QoS

Abbildung 5.1.: Selbstkonfiguration bei 10 Knoten und 10 Diensten


0 20 40 60 80 100

010

2030

4050

6070


Simulationen

Nac

hric

hten


0 20 40 60 80 100

−15

0−

100

−50

0


SimulationenQ

oS


**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

*

*

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

**

*

*



0 20 40 60 80 100

020

4060

8010

012

0


Simulationen

Nac

hric

hten


0 20 40 60 80 100

−60

−40

−20

020


Simulationen

QoS


****

***

*

******

***

**

*

***

**

*

*******

********

*

****

*******

****

*********

**

*

***

****

****

****

****

****

*****

***



0 20 40 60 80 100

050

100

150

200


Simulationen

Nac

hric

hten


0 20 40 60 80 100

−60

−40

−20

020


Simulationen

QoS


**

*

***

***

********

******

*****

*****

****

***

*

*****

*****

*

*****

***

**

******

********

*****

*

*****

****

*****

****



48 5. Evaluation

Wie zu sehen ist, liegt bei den Standardkonfigurationen die durchschnittliche Quality ofService bis auf wenige Ausreißer jeweils im optimalen Bereich. Somit ist bereits bei derSelbstkonfiguration eine gute Lastverteilung im Netzwerk erreicht worden. Dies fuhrtdazu, dass die Selbstoptimierung nicht sofort einschreiten muss.

Die Standardkonfigurationen zeigen insgesamt ein hervorragendes Verhalten. Die Anzahlder notwendigen Nachrichte bewegt sich, bis auf wenige Ausreißer, am rechnerischen Op-timum.

5.2.2. Zusatzkonfigurationen

Als nachstes werden die zusatzlichen Konfigurationen betrachtet, die in der Realitat si-cher haufig vorliegen (Abbildungen: 5.5, 5.6, 5.7 und 5.8). Heutzutage sind beispielsweisein der E-Klasse 55 Steuergerate zu finden [6]. Auch diese Konfigurationen liegen stets imoptimalen Bereich. Die durchschnittlich benotigte Anzahl an Nachrichten betragt hier1,1, also etwas besser als in den Standardfallen, was an der hoheren Anzahl von Dienstenim Vergleich zu der Knotenanzahl liegt.

0 20 40 60 80 100

020

4060

8010

0


Simulationen

Nac

hric

hten


0 20 40 60 80 100

−30

0−

200

−10

00


Simulationen

QoS


*

*

*

*

*

*

**

*

*

*

**

**

*

*

*

*

*

***

*

*

*

*

*

*

*

*

*

*

***

*

**

**

*

*

*

**

*

*

*

*

*

*

*

**********

*

*

*

*

*

****

****

*

**

***

*

*

*

**

***

**

*

*

*

*

*

*

**



Im Gegensatz zu den Standardkonfigurationen sind allerdings nun Abstriche bei dererreichten Dienstgute hinzunehmen. Grund hierfur ist die Vielzahl von Moglichkeiten,die die einzelnen Knoten nun haben, um eine Auswahl an zu erbringenden Dienstenzu wahlen. Es werden daher meist negative Werte fur die Minima erreicht, woraus einehohere Abweichung ins Negative resultiert.


0 20 40 60 80 100

050

100

150


Simulationen

Nac

hric

hten


0 20 40 60 80 100

−80

−60

−40

−20

020

40


SimulationenQ

oS

xxxxxxxxx

xxxx

xxxx

xxxxxx

xxxxxx

xxxxxx

xxxxxxx

xxxxxxxx

xxxxxxxxx

xxxxx

xxx

xxxxxxx

xxxxxxx

xxxxx

xxxx

xxxxxx

xxx

***

*

*

*

*

*

**

**

*

**

*

*

*

*

*

**

**

**

***

*

*

*

*****

*

*

***

*

**

*

*

*

*

*

***

**

*

*

***

*

**

*

*

*****

*

*

*

*

*

*

*

*

*

**

**

*

*

*****

*

*

*

*

**

*

**



0 20 40 60 80 100

050

100

150


Simulationen

Nac

hric

hten


0 20 40 60 80 100

−60

−40

−20

020

40


Simulationen

QoS

xxxx

xxxxx

xxx

xxxxxx

xxxxx

xxxxxxxx

xxxxxxxxx

xxxx

xxxxxxxxxxxxxxx

xxxx

xxxxx

xxxxxx

xxx

xxxxx

xxx

xxxx

xxxxxxxxx

xx

*

*

***

******

*

***

*

**

****

***

*

***

**

***

*

*****

***

***

*

*

*

******

*

**

**

*

**

***

******

****

*

***

****

***

*

**

*****

****

*



0 20 40 60 80 100

050

100

150

200

250

300


Simulationen

Nac

hric

hten


0 20 40 60 80 100

−80

−60

−40

−20

020

40


Simulationen

QoS

xxxx

xxxxxxxx

xxxxxxxxx

xxxxxxxxxx

xxx

xxx

xxxxxxxxx

xxxxxxxx

xxxxx

xxxxx

xxxxxxx

xxxxxxx

xxx

xxxxxx

xxxxxxxx

xxxx

x

*

*

*

*

********************

*

*************

*

*

***********

******

*

***

*

************

******

****************

**

**



50 5. Evaluation

5.2.3. Fazit

Im Ergebnis ist zu sehen, dass die Selbstkonfiguration ihre Aufgabe hervorragend erfullt.Die notwendige Nachrichtenanzahl bewegt sich, bis auf seltene Ausreißer am Optimum.Ebenso zeigt sich, dass eine deutlich hohere Anzahl von Diensten, im Vergleich zurAnzahl der Knoten, zu einer Senkung der Anzahl von Nachrichten fuhrt.

5.3. Selbstheilung

Dass eine Selbstheilung notwendig ist, kann durch Monitoring oder bei Benutzung desDienstes erkannt werden. In der Simulation ist das Erkennen relativ einfach, da Dienstebeziehungsweise. Knoten manuell zum Absturz gebracht werden. Ein Erkennen ist somitnicht notwendig.

Untersucht werden zwei Arten von Ausfallen: das Ausfallen von Rechenknoten oder dasWegfallen von Diensten. Des Weiteren wird wiederum gezahlt, wie viele Nachrichtennotwendig sind, um den Defekt zu beheben. Wie bei der Selbstkonfiguration werden dievier Standardkonfigurationen, sowie anschließend die vier Zusatzkonfigurationen mit 25- 50, 25 - 100, 50 - 100 und 50 - 200 betrachtet.

5.3.1. Ausfall von Rechenknoten

Pro Simulationslauf ist es moglich, dass bis zu 40% der Knoten ausfallen konnen. Dieswird durch einen zufallig generierten Wert erreicht. Es kann nun vorkommen, dass Con-troller absturzen, die keinerlei Dienste am Laufen hatten. In solchen Fallen ist nichts zutun. Grafisch wirkt sich das so aus, dass die Anzahl der Nachrichten unter dem Optimumliegt.

0 20 40 60 80 100

05

1015

20

Simulationen

Nac

hric

hten

Nachrichten gesamtOhne ÜberschreibungDienste nicht erfüllbar

x xx

x x x xx x x xx x x x x x x xx

Abbildung 5.9.: Selbstheilung nach Knotenausfallen bei 10 Knoten und 10 Diensten


0 20 40 60 80 100

010

2030

4050

60

Simulationen

Nac

hric

hten



0 20 40 60 80 100

020

6010

014

0

Simulationen

Nac

hric

hten



0 20 40 60 80 100

050

100

150

200

Simulationen

Nac

hric

hten



52 5. Evaluation

Zu beachten ist auch der Fall, dass ein Knoten welcher in dem gerade vorliegenden Netzeinzigartig war, wegfallt. Als Folge kann die Konfiguration nicht mehr erfullt werden,falls der Knoten Dienste erbracht hat. In den Grafiken wird dies durch ein magentafarbenes Kreuz dargestellt.

In allen vier Standardkonfigurationen ist deutlich zu sehen, dass die benotigte Nach-richtenanzahl sich nahe am Optimum bewegt (Abbildungen: 5.9, 5.10, 5.11 und 5.12).Auffallig ist auch, dass nur noch sehr wenige meist nur ein bis zwei Uberschreibungennotwendig sind. Bei der Konfiguration 10 - 10 ist recht haufig ein sozusagen einzigarti-ger Knoten ausgefallen, was aber nicht weiter verwunderlich ist. In einem derart kleinenNetzwerk ist die Wahrscheinlichkeit hierfur recht groß.

Im nachsten Schritt werden die der Realitat naher kommenden Konfigurationen betrach-tet (Abbildungen: 5.13, 5.15, 5.15 und 5.16). Auch hier gibt es keinerlei Uberraschungen.Wiederum bewegen sich die Nachrichten am Optimum, teils deutlich besser als vorher.

0 20 40 60 80 100

010

3050

70

Simulationen

Nac

hric

hten


x

x


Das Netzwerk mit 25 Knoten (Abbildungen: 5.13 und 5.14), das ungefahr einem Klein-bis Mittelklassewagen entsprechen durfte, zeigt ein extrem positives Verhalten. Maximalwaren zwei Uberschreibungen notwendig. Ebenso verlauft die Nachrichtenlinie fast exaktauf dem Optimum.

Die Simulationen mit 50 Knoten (Abbildungen: 5.15 und 5.16) zeigen ebenfalls deutlich,dass sie sehr nahe am Optimum mit der Anzahl versendeter Nachrichten sind. Genauwie mit 25 Knoten ist zu sehen, dass eine hohere Anzahl an Diensten diesen Effekt nochverstarkt.


0 20 40 60 80 100

020

4060

8012

0

Simulationen

Nac

hric

hten


x x


0 20 40 60 80 100

020

6010

0

Simulationen

Nac

hric

hten



0 20 40 60 80 100

050

100

150

Simulationen

Nac

hric

hten



54 5. Evaluation

5.3.2. Ausfall von Diensten

Zuletzt soll noch der Ausfall von Diensten betrachtet werden. Standardmaßig wurdenbei der automatischen Evaluation bis zu 40% der Dienste zum Absturz gebracht. Furdie Zusatzkonfigurationen wird deshalb noch ein weiterer Fall untersucht, in dem bis zu60% ausfallen konnen. Auf diese Weise soll das Verhalten bei etwas großeren Mengen anDiensten getestet werden.

0 20 40 60 80 100

05

1015

2025

Simulationen

Nac

hric

hten

Nachrichten gesamtOhne Überschreibung

Abbildung 5.17.: Selbstheilung nach Dienstausfallen bei 10 Knoten und 10 Diensten

0 20 40 60 80 100

010

2030

4050

60

Simulationen

Nac

hric

hten



Auch hier ist in den Standardkonfigurationen (Abbildungen: 5.17, 5.18, 5.19 und 5.20)wiederum die Nachrichtenzahl deutlich am Optimum. Ebenfalls ist zu erkennen, dassgroßere Netzwerke besser sind. In Zahlen ausgedruckt wurden pro Dienst 3,4, 2,5, 2,2und 2,1 Nachrichten benotigt. Die Selbstheilung ist also etwas schlechter als die Selbst-


konfiguration, was aber, wie in den nachfolgenden Spezialkonfigurationen zu sehen seinwird, mit der zu konfigurierenden Zahl an Diensten zusammenhangt.

0 20 40 60 80 100

020

4060

8012

0

Simulationen

Nac

hric

hten



0 20 40 60 80 100

050

100

150

200

Simulationen

Nac

hric

hten



Abbildungen 5.21, 5.22 und 5.23 zeigen, dass wiederum mit steigender Anzahl an Diens-ten im System die notwendigen Nachrichten pro Dienst sinken. Fur die Ausfallquote von40% ergeben sich 1,75 und 1,45 Nachrichten pro Service. Die Erhohung der Ausfallquoteauf 60% bringt eine Verbesserung auf 1,39, was nur unwesentlich besser ist.

In den Abbildungen 5.24, 5.26 und 5.25 ist ein ahnliches Verhalten wie im Netzwerk mit25 Knoten zu sehen. Die Zahlen hierfur sind 1,61, 1,39 und 1,59. Auch hier bringt dieErhohung der Ausfallquote nicht sehr viel Verbesserung mit sich.

56 5. Evaluation

0 20 40 60 80 100

010

3050

70

Simulationen

Nac

hric

hten



0 20 40 60 80 100

020

4060

80

Simulationen

Nac

hric

hten



0 20 40 60 80 100

020

4060

80

Simulationen

Nac

hric

hten


Abbildung 5.23.: Selbstheilung nach Dienstausfallen bei 25 Knoten und 100 Dienstenbei 60% Ausfallwahrscheinlichkeit


0 20 40 60 80 100

020

6010

014

0

Simulationen

Nac

hric

hten



0 20 40 60 80 100

050

100

150

Simulationen

Nac

hric

hten


Abbildung 5.25.: Selbstheilung nach Dienstausfallen bei 50 Knoten und 100 Dienstenbei 60 % Ausfallwahrscheinlichkeit

0 20 40 60 80 100

050

100

150

Simulationen

Nac

hric

hten



58 5. Evaluation

5.3.3. Fazit

Die Auswertung der Selbstheilung legt deutlich dar, dass die Algorithmen optimal ihrenZweck erfullen. Dass die Nachrichten pro Dienst wahrend der Selbstheilungsphase hoherliegen ist relativ leicht zu erklaren. Es wird viele Knoten geben, die sich um diese we-nigen Dienste bemuhen konnen. Von daher wird sich das Nachrichtenaufkommen ganzselbstverstandlich erhohen.

5.4. Resultat

Sowohl die Evaluation der Selbstkonfiguration als auch der Selbstheilung hat gezeigt,dass die entwickelten Algorithmen ihren Zweck hervorragend erfullen. Dadurch ist esmoglich, derartige Netze problemlos mit den Fahigkeiten Selbstkonfiguration sowie Selbst-heilung zu versehen. Weiterhin ist zu sehen, dass eine große Anzahl von Diensten imVergleich zur Knotenanzahl zu einer Verbesserung fuhrt. In der Auswertung wurde imMittel stets die optimale Anzahl an Nachrichten nahezu erreicht. Ebenso wurde durchdie entwickelte Metrik bereits bei der Konfiguration eine ausgeglichene Lastverteilungauf die Knoten erreicht. Dies ist an der jeweils erreichten Dienstgute zu sehen.

6. Zusammenfassung und Ausblick

Ziel dieser Arbeit war es, die Fahigkeiten der Selbstkonfiguration und Selbstheilungfur AUTOSAR verfugbar zu machen. Hierfur wurde ein Vorschlag zur Erweiterung vonAUTOSAR entwickelt. Dazu wurde eine Aufsplittung der Architektur in Einzelmodulevorgenommen.

Des Weiteren wurde eine Metrik entwickelt, welche eine bestmogliche Verteilung derDienste auf die Knoten bringt und andererseits dafur sorgt, dass bereits bei der Kon-figuration die Quality of Service, und die damit verbundene Last der Knoten im Opti-malbereich liegt.

Ebenso wurde die Konfigurationsbeschreibung, welche bereits aus vorhergehenden Ar-beiten am Lehrstuhl bekannt war, um die Beschreibungsmoglichkeit von Abhangigkeitenzu anderen Komponenten erweitert.

Im Rahmen dieser Arbeit wurden die Algorithmen auf ihre Tauglichkeit hin untersucht.Die Ergebnisse sind hervorragend und zeigen, dass ein Einsatz auf jeden Fall von Nutzenist. Speziell die Konfigurationen, die vergleichbar mit heutigen Automobilen - bezogenauf die Anzahl Steuergerate - sind, haben ein hervorragendes Verhalten gezeigt.

Zur Untersuchung wurde ein Simulator in Java entwickelt, welcher die vorgeschlageneArchitektur einer

”Organic Middleware fur Automotive“ auf ein entsprechend einfaches

Modell abbildet. Eine Erweiterung des Simulators um weitere Selbst-X-Eigenschaftenist moglich. Ebenso kann der Simulator um die Fahigkeit der Einschleusung von Netz-werkfehlern erweitert werden.

Einer der nachsten notwendigen Schritte ist sicherlich, weitere Selbst-X-Eigenschaften,wie die Selbstoptimierung, zu implementieren. Entsprechende Moglichkeiten hierfur sindin [23] zu finden. Auf diese kann bei realem Einsatz nicht verzichtet werden. Vor allemkann hierdurch eine noch bessere und gleichmaßigere Lastverteilung wahrend des Be-triebs erreicht werden.

Die nun vorliegende Architektur bietet hervorragendes Einsparpotential bei den War-tungskosten im Automobilbereich. Von nun an ist eine aufwendige Ersatzteillagerung aufJahre - gerade was die verwendeten Controller Chips anbelangt - nicht mehr notwendig.

59

60 6. Zusammenfassung und Ausblick

Literaturverzeichnis

[1] 7er Forum: Forum zum 7er BMW. http://www.7-forum.com/modelle/e65/

galerie technik.php, Abruf: 10.08.06

[2] Apache Foundation: Log4J Framework. http://logging.apache.org, Abruf:10.08.06

[3] Apache Foundation: Xerces XML Parser. http://xml.apache.org, Abruf:10.08.06

[4] AUTOSAR GbR: AUTOSAR. http://www.autosar.org. Version: 07 2006,Abruf: 15.07.2006

[5] AUTOSAR GbR: Technical Overview / AUTOSAR GbR. Version: 2006. http://www.autosar.org. – technischer Bericht

[6] Daimler Chrysler Customer Assistance: Vernetzung E-Klasse. per EMail05.08.06,

[7] Dehen, W. : So viel Sicherheit gab es noch nie. In: ADAC Motorwelt 07 (2006),S. 24

[8] Dohmke, T. : Bussysteme im Automobil CAN, FlexRay und MOST, TechnischeUniversitat Berlin, Diplomarbeit, 2002

[9] FlexRay Consortium GbR: FlexRay Communications System Protocol Speci-fication Version 2.1 / FlexRay. 2005. – technischer Bericht

[10] Goltz, P. D. U.: Reaktive Systeme - Entwurf und Programmierung. http://www.ips.cs.tu-bs.de/ws03-04/reaktive-systeme/Folien1.pdf

[11] Gunther, U. : Im Auto wachst die Zahl der Netzteilnehmer. http://www.bics.

be.schule.de/son/verkehr/presse/2001 2/v5012 04.htm, Abruf: 15.07.2006

[12] Klaus, R. : Selbstkonfiguration in einem dienstbasierten Peer-to-Peer Netzwerk,Universitat Augsburg, Diplomarbeit, 2006

[13] Koch, B. : Zuverlassige Software furs Auto. In: Fraunhofer Magazin 04 (2004), S.24–25

61

http://www.7-forum.com/modelle/e65/galerie_technik.php

http://www.7-forum.com/modelle/e65/galerie_technik.php

http://logging.apache.org

http://xml.apache.org

http://www.autosar.org



http://www.ips.cs.tu-bs.de/ws03-04/reaktive-systeme/Folien1.pdf

http://www.ips.cs.tu-bs.de/ws03-04/reaktive-systeme/Folien1.pdf

http://www.bics.be.schule.de/son/verkehr/presse/2001_2/v5012_04.htm

http://www.bics.be.schule.de/son/verkehr/presse/2001_2/v5012_04.htm

62 Literaturverzeichnis

[14] MOST Corporation: MOST Specification / MOST Corporation. 2005. – tech-nischer Bericht

[15] Muller, D. J.-V. : Der Weg zu AUTOSAR. In: AUTOMOTIVE 11-12.2005(2005), S. 35–39

[16] NetBeans: NetBeans IDE. http://www.netbeans.org, Abruf: 10.08.06

[17] OSEK: OSEK/VDX - Operation System / OSEK. Version: 2005. http:

//osek-vdx.org (2.2.3). – technischer Bericht

[18] Robert Bosch GmbH: CAN Specification / Robert Bosch GmbH. 1991. – tech-nischer Bericht

[19] Ruhr-Universitat Bochum - Institut fur Neuroinformatik: OrganicComputing. http://www.organic-computing.org/whatis/, Abruf: 10.09.2006

[20] Schauffele, J. ; Zurawka, T. : Automotive Software Engineering. Vieweg Verlag,2004

[21] Sun: Java Development Kit. http://java.sun.com, Abruf: 10.08.06

[22] Tanenbaum, A. ; Steen, M. van: Verteilte Systeme - Grundlagen und Paradigmen.Pearson Studium, 2003

[23] Thiemann, T. : Selbstorganisation der Knoten einer Peer-to-peer-Middleware mit-tels Botenstoffen, Universitat Augsburg, Diplomarbeit, 2005

[24] Trumler, W. : Organic Ubiquitous Middleware, Universitat Augsburg, Diss., Juli2006

[25] Trumler, W. ; Bagci, F. ; Petzold, J. ; Ungerer, T. : AMUN - autonomicmiddleware for ubiquitous environments applied to the smart doorplate project. In:Advanced Engineering Informatics, 2005

http://www.netbeans.org

http://osek-vdx.org

http://osek-vdx.org

http://www.organic-computing.org/whatis/

http://java.sun.com

Abbildungsverzeichnis

2.1. Architektur der Autonomic Middleware fur Ubiquitous eNvironments . . 62.2. Schematischer Uberblick der AUTOSAR ECU Software Architektur . . . 112.3. AUTOSAR Vorgehen bei der Softwareerstellung . . . . . . . . . . . . . . 122.4. Einteilung der Steuergerate . . . . . . . . . . . . . . . . . . . . . . . . . 142.5. Motorsteuergerat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6. Steuergerate der Mercedes E-Klasse . . . . . . . . . . . . . . . . . . . . . 15

3.1. Architektur eines Controller Knoten . . . . . . . . . . . . . . . . . . . . . 203.2. Netzwerkstruktur im Auto . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3. Metrik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1. Vereinfachtes Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2. Hauptfenster des Simulators mit Preferences-Dialog . . . . . . . . . . . . 404.3. Netzwerk mit Simulationsfortschritt . . . . . . . . . . . . . . . . . . . . . 41

5.1. Selbstkonfiguration bei 10 Knoten und 10 Diensten . . . . . . . . . . . . 465.2. Selbstkonfiguration bei 25 Knoten und 25 Diensten . . . . . . . . . . . . 475.3. Selbstkonfiguration bei 50 Knoten und 50 Diensten . . . . . . . . . . . . 475.4. Selbstkonfiguration bei 100 Knoten und 100 Diensten . . . . . . . . . . . 475.5. Selbstkonfiguration bei 25 Knoten und 50 Diensten . . . . . . . . . . . . 485.6. Selbstkonfiguration bei 25 Knoten und 100 Diensten . . . . . . . . . . . 495.7. Selbstkonfiguration bei 50 Knoten und 100 Diensten . . . . . . . . . . . 495.8. Selbstkonfiguration bei 50 Knoten und 200 Diensten . . . . . . . . . . . 495.9. Selbstheilung nach Knotenausfallen bei 10 Knoten und 10 Diensten . . . 505.10. Selbstheilung nach Knotenausfallen bei 25 Knoten und 25 Diensten . . . 515.11. Selbstheilung nach Knotenausfallen bei 50 Knoten und 50 Diensten . . . 515.12. Selbstheilung nach Knotenausfallen bei 100 Knoten und 100 Diensten . . 515.13. Selbstheilung nach Knotenausfallen bei 25 Knoten und 50 Diensten . . . 525.14. Selbstheilung nach Knotenausfallen bei 25 Knoten und 100 Diensten . . 535.15. Selbstheilung nach Knotenausfallen bei 50 Knoten und 100 Diensten . . 535.16. Selbstheilung nach Knotenausfallen bei 50 Knoten und 200 Diensten . . 535.17. Selbstheilung nach Dienstausfallen bei 10 Knoten und 10 Diensten . . . 545.18. Selbstheilung nach Dienstausfallen bei 25 Knoten und 25 Diensten . . . 545.19. Selbstheilung nach Dienstausfallen bei 50 Knoten und 50 Diensten . . . 555.20. Selbstheilung nach Dienstausfallen bei 100 Knoten und 100 Diensten . . 55

63

64 Abbildungsverzeichnis

5.21. Selbstheilung nach Dienstausfallen bei 25 Knoten und 50 Diensten . . . 565.22. Selbstheilung nach Dienstausfallen bei 25 Knoten und 100 Diensten . . . 565.23. Selbstheilung nach Dienstausfallen bei 25 Knoten und 100 Diensten bei

60% Ausfallwahrscheinlichkeit . . . . . . . . . . . . . . . . . . . . . . . . 565.24. Selbstheilung nach Dienstausfallen bei 50 Knoten und 100 Diensten . . . 575.25. Selbstheilung nach Dienstausfallen bei 50 Knoten und 100 Diensten bei

60 % Ausfallwahrscheinlichkeit . . . . . . . . . . . . . . . . . . . . . . . 575.26. Selbstheilung nach Dienstausfallen bei 50 Knoten und 200 Diensten . . . 57

A. XML-Schemadefintion derKonfiguration

Listing A.1: eval config 10 10.xml

<?xml ve r s i on =”1.0” encoding=”UTF−8” ?><xsd : schema xmlns : xsd=”http ://www.w3 . org /2001/XMLSchema”>

<xsd : element name=”con f i gu r a t i on ” type=”con f i gu r a t i on ”/><xsd : complexType name=”con f i gu r a t i on”>

<xsd : sequence><xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”

ac tua to r s ” type=”ac tuato r s ”/><xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”

s en so r s ” type=”s en so r s ”/><xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”

c o n t r o l l e r s ” type=”c o n t r o l l e r s ”/><xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”

s e r v i c e s ” type=”s e r v i c e s ”/></xsd : sequence>

</xsd : complexType><xsd : complexType name=”ac tuato r s”>


actuator ” type=”actuator”/></xsd : sequence>

</xsd : complexType><xsd : complexType name=”actuator”>


re sou r c e ” type=”re sou r c e ”/></xsd : sequence><xsd : a t t r i bu t e name=”c l a s s ” type=”xsd : s t r i n g ”/><xsd : a t t r i bu t e name=”id ” type=”xsd : s t r i n g ” use=”requ i r ed”/><xsd : a t t r i bu t e name=”name” type=”xsd : s t r i n g ” use=”requ i r ed

”/></xsd : complexType><xsd : complexType name=”re sou r c e”>

<xsd : sequence>

65

66 A. XML-Schemadefintion der Konfiguration

<xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”value ” type=”value”/>

</xsd : sequence><xsd : a t t r i bu t e name=”name” type=”xsd : s t r i n g ”/>

</xsd : complexType><xsd : complexType name=”value”>

<xsd : simpleContent><xsd : ex tens i on base=”xsd : s t r i n g”>

<xsd : a t t r i bu t e name=”name” type=”xsd : s t r i n g ” use=”requ i r ed”/>

<xsd : a t t r i bu t e name=”uni t ” type=”xsd : s t r i n g ” use=”requ i r ed”/>

</xsd : extens ion></xsd : simpleContent>

</xsd : complexType><xsd : complexType name=”s en so r s”>


senso r ” type=”senso r”/></xsd : sequence>

</xsd : complexType><xsd : complexType name=”senso r”>

<xsd : sequence><xsd : element name=”re tu rnva l ” type=”re tu rnva l ”/><xsd : element name=”re sou r c e ” type=”re sou r c e ”/>

</xsd : sequence><xsd : a t t r i bu t e name=”c l a s s ” type=”xsd : s t r i n g ”/><xsd : a t t r i bu t e name=”id ” type=”xsd : s t r i n g ” use=”requ i r ed”/><xsd : a t t r i bu t e name=”name” type=”xsd : s t r i n g ” use=”requ i r ed

”/></xsd : complexType><xsd : complexType name=”re tu rnva l”>


<xsd : a t t r i bu t e name=”name” type=”xsd : s t r i n g ” use=”requ i r ed”/>


</xsd : complexType><xsd : complexType name=”c o n t r o l l e r s ”>


c o n t r o l l e r ” type=”c o n t r o l l e r ”/></xsd : sequence>

67

</xsd : complexType><xsd : complexType name=”c o n t r o l l e r ”>


re sou r c e ” type=”re sou r c e ”/></xsd : sequence><xsd : a t t r i bu t e name=”c l a s s ” type=”xsd : s t r i n g ”/><xsd : a t t r i bu t e name=”id ” type=”xsd : s t r i n g ” use=”requ i r ed”/><xsd : a t t r i bu t e name=”name” type=”xsd : s t r i n g ” use=”requ i r ed

”/></xsd : complexType><xsd : complexType name=”s e r v i c e s ”>


s e r v i c e ” type=”s e r v i c e ”/></xsd : sequence>

</xsd : complexType><xsd : complexType name=”s e r v i c e ”>


re sou r c e ” type=”re sou r c e ”/><xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”

dependency” type=”dependency”/></xsd : sequence><xsd : a t t r i bu t e name=”c l a s s ” type=”xsd : s t r i n g ”/><xsd : a t t r i bu t e name=”id ” type=”xsd : s t r i n g ” use=”requ i r ed”/><xsd : a t t r i bu t e name=”name” type=”xsd : s t r i n g ” use=”requ i r ed

”/><xsd : a t t r i bu t e name=”p r i o r i t y ” type=”xsd : i n t ” d e f au l t=”1”/><xsd : a t t r i bu t e name=”amount” type=”xsd : i n t ” d e f au l t=”1”/>

</xsd : complexType><xsd : complexType name=”dependency”>


<xsd : a t t r i bu t e name=”type” type=”xsd : s t r i n g ” use=”requ i r ed”/>

<xsd : a t t r i bu t e name=”amount” type=”xsd : i n t ” d e f au l t=”1”/>

<xsd : a t t r i bu t e name=”p r i o r i t y ” type=”xsd : i n t ” use=”requ i r ed”/>


</xsd : complexType></xsd : schema>

68 A. XML-Schemadefintion der Konfiguration

B. Abkurzungen

ABS Anti Blockier System

AUTOSAR AUTomotive Open System Architecture

AMUN Autonomic Middleware for Ubiquitous eNvironments

BUS Bidirectional Universal Switch

CAN Controller Area Network

CLR Common Language Runtime

CPU Central Processing Unit

CRC Cyclic Redundancy Check

CSMA/CA Carrier Sense Multiple Access / Collision Avoidance

EBV Elektronische Bremskraftverteilung

ECU Electronic Control Unit

EEPROM Electrically Eraseable Programmable Read Only Memory

ESP Elektronisches Stabilitatsprogramm

FTDMA Frequency Time Division Multiple Access

JRE Java Runtime Environment

JVM Java Virtual Machine

MOST Media Oriented System Transport

OEM Original Equipment Manufacturer

OS Operating System

OSEK Offene Systeme und deren Schnittstellen fur die Elektronik im Kraftfahrzeug

RAM Random Access Memory

69

70 B. Abkurzungen

ROM Read-Only-Memory

RTE AUTOSAR Runtime Environment

Self-X Self-configuring, healing, optimizing, protecting, organization

TDM Time Division Multiplex

TDMA Time Division Multiple Access

TTCAN Time Triggered CAN

VFB Virtual Functional Bus

C. Erklarung des Verfassers

Hiermit erklare ich, MARKUS HELBIG, dass ich die vorliegende Arbeit selbstandigverfasst und keine anderen Hilfsmittel als die angegebenen verwendet habe.

Die Stellen der Arbeit, die anderen Werken dem Wortlaut oder dem Sinn nach entnom-men sind, wurden in jedem Fall unter Angabe der Quelle kenntlich gemacht.

Egling, den 28. September 2006

71

Selbstkonfiguration und Selbstheilung in AUTOSAR · Zusammenfassung Mit dem Einzug der Elektronik...

Documents

Transcript of Selbstkonfiguration und Selbstheilung in AUTOSAR · Zusammenfassung Mit dem Einzug der Elektronik...