Upload
others
View
8
Download
1
Embed Size (px)
Citation preview
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]
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.
20 3. Organic Middleware fur Automotive
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
Microcontroller Abstraction
Runtime Environment
Service
ECU
Sensor
CommunicationDriver
Microcontroller Abstraction
Runtime Environment
Sensor Service
ECU
Actuator
CommunicationDriver
Microcontroller Abstraction
Runtime Environment
Actuator Service
ECU
Sensor
CommunicationDriver
Microcontroller Abstraction
Runtime Environment
Sensor Service
ECU
Actuator
CommunicationDriver
Microcontroller Abstraction
Runtime Environment
Actuator Service
BUS
ECU
Self-X
Controller
CommunicationDriver
Microcontroller Abstraction
Runtime Environment
Service
...
... ...
Abbildung 3.2.: Netzwerkstruktur im Auto
22 3. Organic Middleware fur Automotive
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.
24 3. Organic Middleware fur Automotive
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.
26 3. Organic Middleware fur Automotive
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.
28 3. Organic Middleware fur Automotive
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.
3.6. Selbstkonfiguration 29
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-
30 3. Organic Middleware fur Automotive
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
3.6. Selbstkonfiguration 31
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.
32 3. Organic Middleware fur Automotive
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.
3.6. Selbstkonfiguration 33
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.
34 3. Organic Middleware fur Automotive
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
36 3. Organic Middleware fur Automotive
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
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
5.2. Selbstkonfiguration 47
0 20 40 60 80 100
010
2030
4050
6070
25 Knoten − 25 Diensten
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungVerifikations Nachrichten
0 20 40 60 80 100
−15
0−
100
−50
0
Erreichte Dienstgüte
SimulationenQ
oS
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
*
*
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
**
*
*
Maximale QoSDurchschnittliche QoSMinimale QoS
Abbildung 5.2.: Selbstkonfiguration bei 25 Knoten und 25 Diensten
0 20 40 60 80 100
020
4060
8010
012
0
50 Knoten − 50 Diensten
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungVerifikations Nachrichten
0 20 40 60 80 100
−60
−40
−20
020
Erreichte Dienstgüte
Simulationen
QoS
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
****
***
*
******
***
**
*
***
**
*
*******
********
*
****
*******
****
*********
**
*
***
****
****
****
****
****
*****
***
Maximale QoSDurchschnittliche QoSMinimale QoS
Abbildung 5.3.: Selbstkonfiguration bei 50 Knoten und 50 Diensten
0 20 40 60 80 100
050
100
150
200
100 Knoten − 100 Diensten
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungVerifikations Nachrichten
0 20 40 60 80 100
−60
−40
−20
020
Erreichte Dienstgüte
Simulationen
QoS
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
**
*
***
***
********
******
*****
*****
****
***
*
*****
*****
*
*****
***
**
******
********
*****
*
*****
****
*****
****
Maximale QoSDurchschnittliche QoSMinimale QoS
Abbildung 5.4.: Selbstkonfiguration bei 100 Knoten und 100 Diensten
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
25 Knoten − 50 Diensten
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungVerifikations Nachrichten
0 20 40 60 80 100
−30
0−
200
−10
00
Erreichte Dienstgüte
Simulationen
QoS
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
*
*
*
*
*
*
**
*
*
*
**
**
*
*
*
*
*
***
*
*
*
*
*
*
*
*
*
*
***
*
**
**
*
*
*
**
*
*
*
*
*
*
*
**********
*
*
*
*
*
****
****
*
**
***
*
*
*
**
***
**
*
*
*
*
*
*
**
Maximale QoSDurchschnittliche QoSMinimale QoS
Abbildung 5.5.: Selbstkonfiguration bei 25 Knoten und 50 Diensten
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.
5.2. Selbstkonfiguration 49
0 20 40 60 80 100
050
100
150
25 Knoten − 100 Diensten
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungVerifikations Nachrichten
0 20 40 60 80 100
−80
−60
−40
−20
020
40
Erreichte Dienstgüte
SimulationenQ
oS
xxxxxxxxx
xxxx
xxxx
xxxxxx
xxxxxx
xxxxxx
xxxxxxx
xxxxxxxx
xxxxxxxxx
xxxxx
xxx
xxxxxxx
xxxxxxx
xxxxx
xxxx
xxxxxx
xxx
***
*
*
*
*
*
**
**
*
**
*
*
*
*
*
**
**
**
***
*
*
*
*****
*
*
***
*
**
*
*
*
*
*
***
**
*
*
***
*
**
*
*
*****
*
*
*
*
*
*
*
*
*
**
**
*
*
*****
*
*
*
*
**
*
**
Maximale QoSDurchschnittliche QoSMinimale QoS
Abbildung 5.6.: Selbstkonfiguration bei 25 Knoten und 100 Diensten
0 20 40 60 80 100
050
100
150
50 Knoten − 100 Diensten
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungVerifikations Nachrichten
0 20 40 60 80 100
−60
−40
−20
020
40
Erreichte Dienstgüte
Simulationen
QoS
xxxx
xxxxx
xxx
xxxxxx
xxxxx
xxxxxxxx
xxxxxxxxx
xxxx
xxxxxxxxxxxxxxx
xxxx
xxxxx
xxxxxx
xxx
xxxxx
xxx
xxxx
xxxxxxxxx
xx
*
*
***
******
*
***
*
**
****
***
*
***
**
***
*
*****
***
***
*
*
*
******
*
**
**
*
**
***
******
****
*
***
****
***
*
**
*****
****
*
Maximale QoSDurchschnittliche QoSMinimale QoS
Abbildung 5.7.: Selbstkonfiguration bei 50 Knoten und 100 Diensten
0 20 40 60 80 100
050
100
150
200
250
300
50 Knoten − 200 Diensten
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungVerifikations Nachrichten
0 20 40 60 80 100
−80
−60
−40
−20
020
40
Erreichte Dienstgüte
Simulationen
QoS
xxxx
xxxxxxxx
xxxxxxxxx
xxxxxxxxxx
xxx
xxx
xxxxxxxxx
xxxxxxxx
xxxxx
xxxxx
xxxxxxx
xxxxxxx
xxx
xxxxxx
xxxxxxxx
xxxx
x
*
*
*
*
********************
*
*************
*
*
***********
******
*
***
*
************
******
****************
**
**
Maximale QoSDurchschnittliche QoSMinimale QoS
Abbildung 5.8.: Selbstkonfiguration bei 50 Knoten und 200 Diensten
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
5.3. Selbstheilung 51
0 20 40 60 80 100
010
2030
4050
60
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungDienste nicht erfüllbar
Abbildung 5.10.: Selbstheilung nach Knotenausfallen bei 25 Knoten und 25 Diensten
0 20 40 60 80 100
020
6010
014
0
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungDienste nicht erfüllbar
Abbildung 5.11.: Selbstheilung nach Knotenausfallen bei 50 Knoten und 50 Diensten
0 20 40 60 80 100
050
100
150
200
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungDienste nicht erfüllbar
Abbildung 5.12.: Selbstheilung nach Knotenausfallen bei 100 Knoten und 100 Diensten
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
Nachrichten gesamtOhne ÜberschreibungDienste nicht erfüllbar
x
x
Abbildung 5.13.: Selbstheilung nach Knotenausfallen bei 25 Knoten und 50 Diensten
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.
5.3. Selbstheilung 53
0 20 40 60 80 100
020
4060
8012
0
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungDienste nicht erfüllbar
x x
Abbildung 5.14.: Selbstheilung nach Knotenausfallen bei 25 Knoten und 100 Diensten
0 20 40 60 80 100
020
6010
0
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungDienste nicht erfüllbar
Abbildung 5.15.: Selbstheilung nach Knotenausfallen bei 50 Knoten und 100 Diensten
0 20 40 60 80 100
050
100
150
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne ÜberschreibungDienste nicht erfüllbar
Abbildung 5.16.: Selbstheilung nach Knotenausfallen bei 50 Knoten und 200 Diensten
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
Nachrichten gesamtOhne Überschreibung
Abbildung 5.18.: Selbstheilung nach Dienstausfallen bei 25 Knoten und 25 Diensten
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-
5.3. Selbstheilung 55
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
Nachrichten gesamtOhne Überschreibung
Abbildung 5.19.: Selbstheilung nach Dienstausfallen bei 50 Knoten und 50 Diensten
0 20 40 60 80 100
050
100
150
200
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne Überschreibung
Abbildung 5.20.: Selbstheilung nach Dienstausfallen bei 100 Knoten und 100 Diensten
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
Nachrichten gesamtOhne Überschreibung
Abbildung 5.21.: Selbstheilung nach Dienstausfallen bei 25 Knoten und 50 Diensten
0 20 40 60 80 100
020
4060
80
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne Überschreibung
Abbildung 5.22.: Selbstheilung nach Dienstausfallen bei 25 Knoten und 100 Diensten
0 20 40 60 80 100
020
4060
80
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne Überschreibung
Abbildung 5.23.: Selbstheilung nach Dienstausfallen bei 25 Knoten und 100 Dienstenbei 60% Ausfallwahrscheinlichkeit
5.3. Selbstheilung 57
0 20 40 60 80 100
020
6010
014
0
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne Überschreibung
Abbildung 5.24.: Selbstheilung nach Dienstausfallen bei 50 Knoten und 100 Diensten
0 20 40 60 80 100
050
100
150
Simulationen
Nac
hric
hten
Nachrichten gesamtOhne Überschreibung
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
Nachrichten gesamtOhne Überschreibung
Abbildung 5.26.: Selbstheilung nach Dienstausfallen bei 50 Knoten und 200 Diensten
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
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
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
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”>
<xsd : sequence><xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”
actuator ” type=”actuator”/></xsd : sequence>
</xsd : complexType><xsd : complexType name=”actuator”>
<xsd : sequence><xsd : element maxOccurs=”unbounded” minOccurs=”0” 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 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”>
<xsd : sequence><xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”
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 : 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 : extens ion></xsd : simpleContent>
</xsd : complexType><xsd : complexType name=”c o n t r o l l e r s ”>
<xsd : sequence><xsd : element maxOccurs=”unbounded” minOccurs=”1” name=”
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 ”>
<xsd : sequence><xsd : element maxOccurs=”unbounded” minOccurs=”0” 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=”s e r v i c e s ”>
<xsd : sequence><xsd : element maxOccurs=”unbounded” minOccurs=”1” name=”
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 ”>
<xsd : sequence><xsd : element maxOccurs=”unbounded” minOccurs=”0” name=”
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 : simpleContent><xsd : ex tens i on base=”xsd : s t r i n g”>
<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 : extens ion></xsd : simpleContent>
</xsd : complexType></xsd : schema>
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