- IT

Telematikmoderierter Software-Download in Kfz-Steuergeräte
Dipl.-Ing. (FH) Cornelia Heinisch, MSc – STZ Softwaretechnik Esslingen
Dr. Martin Simons – DaimlerChrysler RIC/TA Esslingen
Cornelia.Heinisch@stz-softwaretechnik.de – Martin.Simons@daimlerchrysler.com
1. Abstract
Die in diesem Beitrag vorgestellte Software-Architektur für einen telematikmoderierten Software-Download erlaubt es, die Steuergeräte eines Kraftfahrzeugs nicht über einen extern
anzuschließenden Tester zu reprogrammieren, sondern durch eine Software-Komponente,
die sich in einem Telematiksteuergerät befindet. Diese Software-Komponente wird für die
Reprogrammierung jedes einzelnen Steuergerätes speziell konfiguriert. Gesteuert – in
anderen Worten „moderiert“ – wird der Download von Software in Kfz-Steuergeräte durch ein
Telematiksteuergerät wie z.B. die Head Unit. Eine Konfigurationsverwaltung, die anteilig im
Fahrzeug und in der fahrzeugexternen Infrastruktur realisiert wird, stellt sicher, dass nur
Updates durchgeführt werden können, die zu einer konsistenten, gültigen und funktionsfähigen Fahrzeugkonfiguration führen. Die Software-Architektur für den telematikmoderierten
Software-Download erlaubt den Download der Flashware-Module in das Fahrzeug über
beliebige drahtgebundene oder drahtlose Übertragungsmedien wie z.B. GSM, GPRS, WLAN, UMTS oder Bluetooth als auch über Datenträger wie eine CD-Rom oder ein USB
Memory Stick.
2. Einleitung
Software-Download in ein Kraftfahrzeug dient zum Installieren neuer Software als auch zur
Aktualisierung bestehender Software – sei es zur Fehlerbeseitigung oder zur Anpassung der
Funktion an den Stand der Technik. Der Software-Download – oder die Möglichkeit der
Reprogrammierung von Steuergeräten – wird künftig in allen Fahrzeugdomänen (Chassis,
Motorraum, Komfort & Karosserie und Telematik) zum Einsatz kommen. Jedes Steuergerät,
das einen Flashspeicher besitzt und über ein Fahrzeug-Subnetz erreichbar ist, soll im Feld
reprogrammierbar sein. Die zunehmende Anzahl der reprogrammierbaren Steuergeräte ist
die Antwort auf das steigende Software-Volumen im Kraftfahrzeug. Das Software-Volumen
heutiger Oberklassen-Fahrzeuge hat bereits die 10 MByte Grenze überschritten und wird
vermutlich bis 2010 die 1GByte Grenze überschreiten [1]. Ohne die Möglichkeit einer Reprogrammierung können Software-Fehler nur durch einen Hardwaretausch behoben werden.
Unter der optimistischen Annahme, dass sich in 1000 Zeilen Programmcode nur 8 Entwicklungsfehler1 und 0,4 Restfehler befinden2, erhält man für das heutige Software-Volumen
im Fahrzeug von ca. 10.000.000 Zeilen Programmcode [2] immerhin noch 80.000 Entwicklungsfehler und 4000 Restfehler [1]. Unter Betrachtung dieser Statistik ist die Notwendigkeit
von Software-Updates im Kraftfahrzeug außer Frage gestellt (siehe hierzu auch [3 - 6]).
Die Aufmerksamkeit ist deshalb auf die Beantwortung folgender Fragestellungen zu richten:
•
•
1
2
Wie kann ein einheitliches Konzept für die Reprogrammierung von Steuergeräten in den
unterschiedlichen Fahrzeugdomänen aussehen?
Wie kann sichergestellt werden, dass nach der Reprogrammierung eines Steuergerätes
eine gültige und funktionsfähige Fahrzeugkonfiguration vorliegt?
Unter Entwicklungsfehler werden hierbei Entwurfsfehler und unter Restfehler Codierfehler
verstanden.
Das entspricht dem höchsten Reifegrad des Capability Maturity Models.
Die hier vorgestellte Architektur für einen telematikmoderierten Software-Download gibt Antworten auf beide Fragestellungen. Bevor auf die Beschreibung der Architektur eingegangen
wird, werden in Kapitel 3 die Grundlagen für die Reprogrammierung von Steuergeräten
behandelt und in Kapitel 4 die Besonderheiten bei der Verwaltung von Software für ein
Fahrzeug vorgestellt.
3. Reprogrammierung von Steuergeräten
Zur Reprogrammierung von Steuergeräten wird heute das KWP2000-Protokoll [7] eingesetzt.
Das KWP2000-Protokoll, das herkömmlich zur Diagnose von Steuergeräten eingesetzt
wurde, enthält einige KWP2000-Services, die für die Reprogrammierung von Steuergeräten
verwendet werden. Steuergeräte, die flashbar und über ein Fahrzeugsubnetz erreichbar
sind, integrieren einen sogenannten Flashloader. Der Flashloader interpretiert die KWP2000Nachrichten, die zur Reprogrammierung an das Steuergerät gesandt werden, und führt die
entsprechenden Aktionen wie zum Beispiel das Löschen oder das Beschreiben des Flashspeichers aus. In Bild 3-1 repräsentiert die Download-Steuerung im Steuergerät den Flashloader. Zur Reprogrammierung eines Steuergerätes wird der sogenannte E-Tester oder
Werkstatt-Tester an den Diagnosestecker des Fahrzeugs angeschlossen. Der WerkstattTester sendet KWP2000-Request-Kommandos, die über ein oder mehrere Gateways zu
demjenigen Steuergerät weitergeleitet werden, das reprogrammiert werden soll. Das Steuergerät antwortet zu jedem Request mit einer KWP2000-Response-Nachricht, die angibt, ob
der empfangene Request erfolgreich ausgeführt werden konnte.
E-Tester
Diagnosestecker
Gateway
Fahrzeugsubnetz
KWP2000-Request
KWP2000-Request
KWP2000-Response
KWP2000-Response
Steuergerät
: Flashware
: Download-Steuerung
Bild 3-1 Reprogrammierung von Steuergeräten
Der E-Tester muss innerhalb der Download-Steuerung Informationen aus verschiedenen
Beschreibungs-Dokumenten extrahieren, um ein spezielles Steuergerät reprogrammieren zu
können. Hierbei handelt es sich beispielsweise um folgende Informationen:
•
•
•
•
•
•
•
Einteilung der Flashware eines Steuergerätes in Segmente,
Security-Klasse der Flashware,
Checksumme und Signatur der Flashware,
Sachnummer und Versionsnummer der Flashware,
Beschreibung des eigentlichen Ablaufs zur Reprogrammierung3,
Beschreibung der zu verwendenden KWP2000-Nachrichten inklusive der Übergabe- und
Ergebnis-Parameter,
Seed-And-Key-Algorithmus [7] für die Entriegelung des Steuergerätes.
Die wesentlichen Aufgaben des Flashloader in einem Steuergerät sind:
•
•
•
•
3
Löschen des Flashspeichers,
Beschreiben des Flashspeichers,
Entgegennahme der Flashware über ein Fahrzeug-Subnetz (zum Beispiel CAN, MOST,
LIN, TT-CAN, FlexRay, etc.),
Kommunikation mit einer Tester-Einheit über KWP2000,
Steuergeräte von unterschiedlichen Zulieferern können unterschiedliche Flashloader in den
Steuergeräten verwenden, die für die Reprogrammierung einen individuellen Ablauf verwenden.
•
•
Implementieren von Security-Funktionen (Seed-and-Key-Algorithmus, Signaturprüfung,
Checksummenberechnung),
Überwachen der Reprogrammierung.
Soll der E-Tester durch eine Software-Komponente ersetzt werden, die sich in einem
Telematiksteuergerät befindet, so muss sich diese Komponente gegenüber dem Flashloader
in einem speziellen Steuergerät genau gleich wie ein E-Tester verhalten, da die einzelnen
Steuergeräte und insbesondere die integrierten Flashloader für einen telematikmoderierten
Software-Download nicht modifiziert werden sollen.
4. Konfigurationsverwaltung für Fahrzeug-Software
Die Konfigurationsverwaltung von Software ist eine Disziplin des Software-Engineerings, die
folgende Aktivitäten umfasst [8]:
•
•
•
•
•
•
Identifikation von Bausteinen, die der Konfigurationsverwaltung unterliegen.
Bereitstellung und Verwaltung von Versionen (Entwicklungs-Basisständen), die von
anderen Entwicklern genutzt werden können.
Verwaltung von Versionen (Releases), die an den Kunden ausgeliefert werden.
Verwaltung von parallelen Entwicklungen (Branches).
Verwaltung von Software-Varianten.
Verwaltung von Änderungen eines Bausteins, welcher der Konfigurationsverwaltung
unterliegt.
All diese Aktivitäten der Konfigurationsverwaltung sind auch bei der Erstellung und Distribution von Fahrzeug-Software vorzufinden und werden in Zukunft in Folge der Möglichkeit
der getrennten Handhabung von Hard- und Software durch den Einsatz von Flashspeichern
sowie das Flashen von Steuergeräten in der Entwicklung, Produktion und Außenorganisation
[9] noch mehr an Bedeutung gewinnen. Bei der Konfigurationsverwaltung kommt allerdings
erschwerend hinzu, dass die Abhängigkeiten von Funktionen auf den verschiedenen Steuergeräten gegenwärtig nicht ausreichend beschrieben sind. Damit ist es aktuell nicht möglich,
Basisstände oder Releases für Fahrzeugfunktionen oder einzelne Steuergeräte zu definieren. Durch die Vernetzung der Fahrzeugfunktionen und die hohen Sicherheitsanforderungen
erscheint es derzeit beinahe unmöglich, Teilfunktionen zu separieren und diese einer
getrennten Entwicklung und Konfigurationsverwaltung zu unterziehen. Ist eine Separierung
nicht möglich, da die Abhängigkeiten untereinander nicht ausreichend beschrieben und/oder
auflösbar sind, so bleibt nur eine Möglichkeit – die gesamte Software für ein Fahrzeug in
einer speziellen Ausstattung muss einem einzigen Basisstand zugeordnet werden. Dieser
Basisstand, der komplett mit allen Einzelfunktionen getestet und abgenommen werden
muss, kann schließlich in einem Release für das Flashen der Steuergeräte am Band oder in
der Außenorganisation freigegeben werden.
Bild 4-1 zeigt die Zusammenhänge zwischen Baureihen, Ausstattungen, Steuergeräten,
Software-Releases und Flashware-Modulen. In einer Baureihe existieren mehrere Ausstattungen. Eine Ausstattung gibt an, welche Steuergeräte in einem Fahrzeug mit dieser
Ausstattung zu verbauen sind und welche Software-Releases auf diesen Steuergeräten
installiert werden können. Ein Software-Release gibt eindeutig an, welche Version von
welchem Flashware-Modul zum Einsatz kommt. Für ein individuelles Fahrzeug muss damit
festgehalten werden, zu welcher Baureihe das Fahrzeug gehört, welche Ausstattung gewählt
wurde, und welches Software-Release in den Steuergeräten installiert wurde. Für jede
Flashware muss zusätzlich noch angegeben werden, auf welchem Steuergerät diese zu
installieren ist. Eine solch starre Zuordnung von Software-Releases zu einer Ausstattungsvariante bedeutet allerdings, dass durch das Hinzufügen einer Funktion zu einer Flashware
auch automatisch ein neues Software-Release erzeugt werden muss, welches die neue
Version der Flashware beinhaltet.
Baureihe
A
Baureihe
B
Baureihe
N
.
..
Ausstattung
N
Ausstattung
B
Ausstattung
A
.
..
Steuergerät
1
Steuergerät
2
...
SW-Release
n
SW-Release
2
Steuergerät
n
SW-Release
1
Flashware A
V2.0
Flashware B
V1.0
..
.
...
Flashware N
V3.0
Bild 4-1 Zuordnung von Software-Releases zu einer Ausstatung einer Baureihe
Komponenten, die neue Dienste realisieren (wie zum Beispiel Nearest- oder CheapestServices, etc.) und keinen Einfluss auf die zentralen Fahrfunktionen haben, können vom
Fahrzeugnutzer dynamisch zu jeder Zeit in das Fahrzeug geladen und auf einer speziell
abgesicherten Diensteplattform installiert werden. Die Releases für diese ladbaren Dienste
sollen jedoch unabhängig von dem Software-Release einer Ausstattung eines Fahrzeugs
gehandhabt werden. Die Diensteplattform selbst und ausgewählte Basiskomponenten4
werden jedoch dem Software-Release einer Ausstattung zugeordnet (siehe Bild 4-2). Ein
Software-Release für eine Ausstattung eines Fahrzeugs umfasst also mehrere FlashwareModule und eine Diensteplattform mit ihren Basiskomponenten.
Baureihe
A
Baureihe
B
Baureihe
N
.
..
Ausstattung
N
Ausstattung
B
Ausstattung
A
Steuergerät
1
Steuergerät
2
...
Steuergerät
n
Diensteplattform
Basiskomponente A
Basiskomponente B
Flashware A
V2.0
...
SW-Release
n
SW-Release
2
SW-Release
1
Flashware B
V1.0
..
...
.
Flashware N
V3.0
Basiskomponente N
Bild 4-2 Integration einer Diensteplattform für dynamisch nachladbare Dienste
4
Basiskomponenten realisieren hierbei zum Beispiel Zugriffe auf Fahrzeugsubnetze.
Auf der Diensteplattform können beliebige Komponenten vom Fahrzeugnutzer installiert
werden, die Dienste wie Nearest-Services, Cheapest-Services, Fahrtenbuch, etc. realisieren,
solange die neuen Dienste nur Fahrzeugdienste benötigen, die von den Basiskomponenten
angeboten werden. Soll jedoch eine Komponente installiert werden, die eine Basiskomponente benötigt, die nicht auf der Diensteplattform angeboten wird, so muss das Fahrzeug auf
ein Software-Release aktualisiert werden, das den entsprechenden Basisdienst anbietet.
5. Telematikmoderierter Software-Download
Steuergeräte müssen künftig in der Entwicklung – zum Beispiel auf Versuchsfahrten – am
Band während der Fertigung und in der Werkstatt reprogrammiert werden können. Bislang
ist dies nur unter Verwendung des E-Testers (einer speziellen Hard- und Software) möglich.
Ist die Komponente (fortan als Flashware-Reprogramming-Controller bezeichnet), die eine
Reprogrammierung eines Steuergerätes durchführen kann, in einem Steuergerät im Fahrzeug integriert, so erreicht man eine weitaus größere Flexibilität – die Reprogrammierung
von Steuergeräten kann auch ohne das Vorhandensein eines E-Testers an einem beliebigen
Ort zu einem beliebigen Zeitpunkt durchgeführt werden. Der Flashware-ReprogrammingController befindet sich in diesem Artikel in der Head-Unit. Damit "moderiert" ein Telematiksteuergerät – die Head-Unit – den Download von Software in beliebige Kfz-Steuergeräte.
Bedingt durch die vergleichsweisen großen Speicher, performanten Prozessoren und die
Nähe zu externen Schnittstellen (wie GSM oder CD-ROM) zum Bezug der Flashware, macht
es durchaus Sinn, den Flashware-Reprogramming-Controller in ein Telematiksteuergerät zu
integrieren. Konzeptuell ist dies aber keinesfalls erforderlich – die Integration kann in jedes
beliebige andere Steuergerät erfolgen, sofern Performance und Speicher ausreichend sind
und die Flashware über ein Fahrzeug-Subnetz oder direkt über eine externe Schnittstelle
bezogen werden kann.
Die Software-Architektur für den telematikmoderierten Software-Download erlaubt den
Download der Flashware-Module in das Fahrzeug über beliebige Übertragungswege und
-medien. Sowohl drahtgebundene als auch beliebige drahtlose Übertragungsmedien wie
GSM, GPRS, W-LAN, UMTS oder Bluetooth sind denkbar, genauso wie eine CD-ROM oder
ein USB Memory Stick (siehe Bild 5-1).
GSM, GPRS, UMTS
Bluetooth, W-LAN
drahtgebunden
Internet
Flashware-Server mit
Konfigurationsverwaltung
Portable Übertragungsmedien CD-ROM,
Memory-Stick
beliebige Übertragungswege und -medien
Bild 5-1 Bezug von Flashware über beliebige Übertragungswege und -medien
Nachdem die Flashware mit den zusätzlichen Daten zur Konfiguration des Flashablaufs in
das Fahrzeug transferiert worden ist, übernimmt der Flashware-Reprogramming-Controller
die Reprogrammierung des Steuergerätes, für das die Flashware bestimmt ist. Auch in der
Werkstatt kann der integrierte Flashware-Reprogramming-Controller vorteilhaft eingesetzt
werden: Das Fahrzeug bezieht zum Beispiel über W-LAN die neue Flashware und führt dann
eigenständig den Update auf ein neues Software-Release durch. Der E-Tester steht damit
für andere Aufgaben wie zum Beispiel die Diagnose von Fahrzeugen zur Verfügung.
5.1. Systemarchitektur
Für den telematikmoderierten Software-Download sind Software-Komponenten zu entwickeln, die im Fahrzeug ablaufen, und Software-Komponenten, die in der fahrzeugexternen
Infrastruktur ablaufen. Die Komponenten, die im Fahrzeug ablaufen, befinden sich auf einer
Diensteplattform – einem OSGi-Service-Gateway [10 - 14] – hier in der Head-Unit. Ein OSGiService-Gateway bietet unter anderem Dienste an, die den Lebenszyklus einer Komponente
verwalten. Durch den Einsatz eines OSGi-Service-Gateways kann die Entwicklung von
wiederverwendbaren Software-Komponenten vereinfacht und beschleunigt werden.
Bild 5-2 zeigt eine schematische Systemarchitektur für einen telematikmoderierten SoftwareDownload. Die Übertragung der Flashware erfolgt in diesem Beispiel über eine Luftschnittstelle.
Infrastruktur
Flashbare Steuergeräte mit Flashloader
FlashwareReprogrammingController /
Installations- und
Konfigurationsüberwachung
VPN
GSM/
Konfigurationsverwaltung /
Steuerung einer
Baureihenaktualisierung
BaureihenDatenbank
FlashwareDatenbank
GPRS/
UMTS/
W-LAN
Bild 5-2 Schematische Systemarchitektur für den telematikmoderierten SW-Download
Ein VPN (Virtual Private Network), das die Kommunikation zwischen Fahrzeug und Infrastruktur kapselt, sorgt dafür, dass die Kommunikation über die Luftschnittstelle so sicher wie
eine drahtgebundene Kommunikation mit dem E-Tester ist. Eine zusätzliche Verbindungsverwaltung (connection management), die im Fahrzeug und in der Infrastruktur integriert ist,
sorgt dafür, dass die Kommunikation zwischen den Komponenten im Fahrzeug und in der
Infrastruktur vollkommen transparent abläuft. Dass über eine Luftschnittstelle kommuniziert
wird, ist für die Komponenten verborgen.
5.2. Konfigurierbare
Komponente
zur
Steuerung
der
Reprogrammierung
Der Flashware-Reprogramming-Controller ersetzt den E-Tester bei der Reprogrammierung
von Steuergeräten. Entsprechend muss der Flashware-Reprogramming-Controller Konfigurations-Informationen aus Beschreibungs-Dokumenten extrahieren und die erforderlichen
KWP2000-Nachrichten an das Steuergerät senden, das reprogrammiert werden soll (siehe
Kapitel 3). Da Steuergeräte an beliebigen Fahrzeug-Subnetzen durch den FlashwareReprogramming-Controller neu geflasht werden sollen, ist konzeptuell eine Möglichkeit
vorzusehen, die es erlaubt, KWP2000-Nachrichten über beliebige Fahrzeug-Subnetze zu
transportieren. Bild 5-3 zeigt Bundles (Komponenten, die von einem OSGi-Service-Gateway
verwaltet werden können), die für den telematikmoderierten Software-Download eingesetzt
werden.
OSGi-Service-Gateway
KWP2000
CAN-TPProxy
MOST-TPProxy
...
FlexRay-TPProxy
...
FlexRay-TP
Bundles
Flashware-Reprogramming-Controller
Java Virtual Machine
Operating-System
ISO-TP
MOST-TP
CAN-Driver
MOST-Driver
FlexRay-Driver
Bild 5-3 Schichteneinteilung in der Head-Unit für einen telematikmoderierten SW-Download
Der Flashware-Reprogramming-Controller interpretiert hierbei die Konfigurationsinformation
für einen konkreten Flashvorgang, stellt die Parameter für die KWP2000-Nachrichten zusammen, die an das zu programmierende Steuergerät gesendet werden müssen, und interpretiert die Response-Nachrichten, die vom Steuergerät als Antwort zurückgesandt werden.
Das KWP2000-Bundle bietet alle KWP2000-Services an, die für die Reprogrammierung von
Steuergeräten benötigt werden. Die Bundles CAN-TP-Proxy, MOST-TP-Proxy, FlexRayProxy, etc. bieten dem KWP2000-Bundle eine einheitliche Schnittstelle, um KWP2000Nachrichten synchron über ein Fahrzeug-Subnetz zu versenden. Die Proxys übernehmen
die Anpassung auf die unterschiedlichen Transportprotokolle5 und leiten die Aufrufe über das
Java Native Interface an die entsprechenden Transportprotokoll-Implementierungen im Betriebssystem weiter. Je nach Fahrzeug-Architektur können unterschiedliche TP-Proxys integriert werden. Kann ein Zugriff auf ein Fahrzeug-Subnetz auch über ein Gateway erfolgen,
so kann auf ein TP-Proxy im Service-Gateway verzichtet werden.
Die restlichen Komponenten des telematikmoderierten Software-Downloads sind Bestandteil
der Konfigurationsverwaltung und werden im nächsten Kapitel vorgestellt.
5.3. Konfigurationsverwaltung
Die Konfigurationsverwaltung, die in der Architektur für den telematikmoderierten SoftwareDownload zum Einsatz kommt, wird anteilig im Fahrzeug und im in der fahrzeugexternen
Infrastruktur realisiert (siehe Bild 5-2). Hierbei wird im Fahrzeug von einer Installations- bzw.
Konfigurations-Überwachung und in der Infrastruktur von der eigentlichen Konfigurationsverwaltung und von einer zentralen Steuerung, die ein Release-Update einer ganzen Baureihe ermöglicht, gesprochen. Bild 5-4 zeigt eine stark vereinfachte Kollaboration zur
Installation eines neuen Software-Releases in einem speziellen Fahrzeug X. Aktuell ist auf
dem Fahrzeug X das Software-Release A installiert. Es soll eine Aktualisierung auf das
Software-Release B erfolgen. Software-Release A und Software-Release B unterscheiden
sich lediglich in der Version des Flashware-Moduls Y. Alle Objekte bis auf das Objekt vom
Typ VehicleReleaseInstallationController befinden sich in der Infrastruktur.
Nachdem sich das Objekt vom Typ BackendReleaseInstallationController die Versionslisten
für die einzelnen Releases besorgt hat, wird eine Differenzbildung in Nachricht 7 durchgeführt. Es wird eine Aktualisierungs-Anfrage in Nachricht 8 an das Fahrzeug gestellt. Das
5
Der Einfachheit halber wird hier von MOST-TP gesprochen und nicht von benötigten F-Blocks und
NetServices. Da der MOST-TP-Proxy diese MOST-Spezifikas kapselt, ist die vereinfachte Sichtweise ausreichend.
Objekt vom Typ VehicleReleaseInstallationController, das sich im Fahrzeug X befindet,
nimmt diese Nachricht entgegen und sendet erst dann die Nachricht 9 zurück, wenn sich das
Fahrzeug in einem Zustand befindet, in dem eine Reprogrammierung von Steuergeräten
möglich ist. Das Objekt vom Typ BackendReleaseInstallationController besorgt sich die neue
Flashware aus dem FlashwareRepository (Nachricht 10, 11) und sendet diese zum Fahrzeug
(Nachricht 12). Konnte der Update erfolgreich ausgeführt werden, so sendet das Objekt vom
Typ VehicleReleaseInstallationController eine entsprechende Bestätigung zurück (Nachricht
13). In der letzten Nachricht wird dem Objekt X vom Typ Fahrzeug mitgeteilt, dass die
Aktualisierung erfolgreich war.
:FlashwareRepository
11: Flashware Y V 2.0
7: Differenzbildung
10: Anfrage Flashware Y V2.0
8: Aktualisierungs-Anfrage
:BackendReleaseInstallationController
:VehicleReleaseInstallationController
9: Start Aktualisierung
12: Update Flashware Y V2.0
13: Installation OK
2: Update
von A nach B
14: Update
erfolgreich
6: Flashware-Liste
5: Anfrage Flashware-Liste
B:SoftwareRelease
4: Flashware-Liste
A:SoftwareRelease
1: Installation Release B
X:Fahrzeug
3: Anfrage Flashware-Liste
Bild 5-4 Vereinfachte Kollaboration zur Installation eines neuen Software-Releases
Das Objekt vom Typ VehicleReleaseInstallationController wird als Bundle auf dem OSGiService-Gateway im Fahrzeug installiert. Zusätzlich sind für die Installations- und Konfigurationsüberwachung im Fahrzeug noch folgende Bundles vorgesehen: VehicleConfiguration-Controller und für jedes installierte Flashware-Modul ein Flashware-ProxyBundle. Bild 5-5 zeigt alle Bundles, die für einen telematikmoderierten Software-Download
auf dem OSGi-Service-Gateway im Fahrzeug installiert sind6.
...
Flashware
Proxy N
Flashware
Proxy B
Flashware
Proxy A
OSGi-Service-Gateway
Flashware-ReprogrammingController
VehicleReleaseInstallationController
VehicleConfigurationController
KWP2000
CAN-TPProxy
MOST-TPProxy
Bild 5-5 Bundles auf dem OSGi-Service-Gateway im Fahrzeug
6
In diesem Beispiel sind nur 2 TP-Proxys integriert. Steuergeräte an anderen Fahrzeug-Subnetzen
können über Gateways erreicht werden.
Der Vehicle-Release-Installation-Controller kommuniziert hierbei mit dem Backend-ReleaseInstallation-Controller in der Infrastruktur, wie in der Kollaboration in Bild 5-4 zu sehen ist.
Der Vehicle-Configuration-Controller wird vom Vehicle-Release-Installation-Controller über
die Aktualisierungs-Anfrage informiert und bestimmt, ob eine Aktualisierung der FahrzeugSoftware im aktuellen Zustand durchgeführt werden kann. Erteilt der Vehicle-ConfigurationController die Erlaubnis für die Aktualisierung, so kann das Fahrzeug nicht mehr gestartet
werden, bis wieder eine gültige Konfiguration vorliegt.
Die Flashware-Proxys haben zwei unterschiedliche Bedeutungen:
•
•
Bei einem vollständig installierten Release einer Fahrzeug-Software stellen diese
Bundles die Stellvertreter für die Flashware-Module dar, die in den einzelnen Steuergeräten installiert sind. Der Vehicle-Configuration-Controller kann von diesen Proxys die
Sachnummern der installierten Flashware-Module abfragen und verifizieren, ob die
Sachnummernkombination von allen installierten Flashware-Modulen ein gültiges
Software-Release für dieses Fahrzeug ergibt. Die Proxys können hierzu über die
KWP2000-Komponente die Sachnummern von den Flashware-Modulen in den
Steuergeräten direkt abfragen oder diese zwischenspeichern.
Bei einem Aktualisierungsvorgang beinhaltet ein Flashware-Proxy-Bundle die Flashware,
die zu installieren ist, und die zugehörige Konfigurationsinformation. Sobald ein
Flashware-Proxy-Bundle auf dem Service-Gateway des Fahrzeugs installiert wird,
beginnt dieses nach einer Rückfrage beim Vehicle-Release-Installation-Controller mit der
Installation der Flashware, wobei diese und die zugehörige Konfigurationsinformation an
den Flashware-Reprogramming-Controller übergeben wird. Ist die Installation erfolgreich
abgeschlossen, löscht das Flashware-Proxy-Bundle die Flashware und nicht mehr
benötigte Konfigurationsinformationen und stellt fortan den Repräsentanten für das
installierte Flashware-Modul im Service-Gateway dar.
6. Ausblick und Zusammenfassung
Eine erhebliche Vereinfachung des eigentlichen Flashvorgangs kann erreicht werden, wenn
in allen Steuergeräten standardisierte Flashloader zum Einsatz kommen. Die Spezifikationen
für einen Standard-Flashloader werden in der Hersteller Initiative Software (HIS) [18] erarbeitet. Ein weiteres Potential für Standardisierungen bieten die Basiskomponenten, die auf
dem OSGi-Service-Gateway ablaufen und zum Beispiel Zugriffe auf Fahrzeugdaten ermöglichen. Die Standardisierung dieser Basisdienste würde einen herstellerübergreifenden Einsatz von Zusatzdiensten möglich machen und könnte richtungsweisenden Einfluss auf den
Gedanken „Software als Produkt“ [15 - 17] mit sich bringen.
In diesem Beitrag wurde empfohlen, für die gesamte Fahrzeug-Software funktionsfähige
Releases auszuweisen, da sich heute noch keine triviale Möglichkeit abzeichnet, wie alle
Abhängigkeiten zwischen den einzelnen Flashware-Modulen (sowohl statische als auch
dynamische) beschrieben werden können. Die Architektur für den telematikmoderierten
Software-Download ermöglicht ein Release-Update von Fahrzeug-Software ohne Verwendung eines externen Testers. Die Flashware und zugehörige Konfigurationsinformation kann
über eine beliebige Kommunikations-Schnittstelle in Form eines OSGi-Bundles in das
Fahrzeug geladen werden. In einem überwachten Installationsvorgang wird die Flashware
dann in das individuelle Steuergerät übertragen. Eine Konfigurationsverwaltung, die anteilig
im Fahrzeug und in der fahrzeugexternen Infrastruktur realisiert wird, stellt sicher, dass nur
Updates durchgeführt werden können, die zu einer konsistenten, gültigen und funktionsfähigen Fahrzeugkonfiguration führen.
7. Danksagung
Wir danken den Kollegen der Mercedes-Benz PKW Entwicklung und des Centers für
Diagnose und Flash-Technologien. Des Weiteren geht unser Dank an Herrn Prof. Dr.
Wolfgang Rosenstiel von der Universität Tübingen für die wissenschaftliche Betreuung und
an Herrn Prof. Dr. Joachim Goll von der Fachhochschule Esslingen – Hochschule für
Technik für seine Unterstützung und fachliche Beratung.
8. Literatur
[1]
H.-E. Schurk, „Spiel ohne Grenzen oder am Band mit unbegrenzten Möglichkeiten?
Einführung in die Thematik Flashen“, Software-Flashen im Kfz, Stuttgart, Jan. 2003
[2]
DaimlerChrysler Hightech Report, „Programme für mehr Intelligenz im Auto“, 1/2002
[3]
DaimlerChrysler Hightech Report, „Innovation im Augenblick – Flashen in Produktion
und Service“, 2/2002
[4]
W. Herrmann, „Software-Update für BMW-Fahrzeuge“, Software-Flashen im Kfz,
Stuttgart, Jan. 2003
[5]
M. Faulbacher, „Updateprogrammierung entlang der Prozesskette aus Sicht eines
Automobilherstellers“, Software-Flashen im Kfz, Stuttgart, Jan. 2003
[6]
H. Alminger, „Downloading software during development, end of line and on the
aftermarket, experiences from Volvo Cars“, Software-Flashen im Kfz, Stuttgart, Jan.
2003
[7]
ISO 14230: „Road vehicles – Diagnostic systems – Keyword Protocol 2000 – Part 3:
Application Layer“
[8]
Standard: IEEE 1042, „A guide to Software Configuration Managment“.
[9]
T. Kühner, S. Kreuser, „Prozessicheres Flashen in der Entwicklung, der Produktion und
der Außenorganisation bei DaimlerChrysler“, Software-Flashen im Kfz, Stuttgart, Jan.
2003
[10] H.-U. Michel, „Open Services Gateway Initiative (OSGi) – Standardisierung einer
offenen Infotainment-Plattform“, Telematik im Kraftfahrzeug, VDI-Berichte 1728, 27 –
39, 2002
[11] S. Schwarze, „Was sind Vorteile einer OSGi-Lösung für Hersteller und Service
Provider?“, Embedded World Conference, Nürnberg, 2003
[12] M. Wagner, „Hardware- und Softwarevoraussetzungen für OSGi in Embedded
Systemen“, Embedded World Conference, Nürnberg, 2003
[13] K. Hackbarth, „Offene Plattformen für Infotainment- und Telematik-Systeme“,
Embedded World Conference, Nürnberg, 2003
[14] V. Fricke, „Embedded Java und OSGi – Neue Technologien im Fahrzeug der Zukunft“,
Embedded World Conference, Nürnberg, 2003
[15] U. Schrey, „Software als Produkt“, Automotive Electronics ATZ MTZ, März 2003
[16] H. Fennel, S. Stölzl, „Software-Funktionen auf dem Weg zu eigenständigen Produkten
im Automobil“, Automotive Electronics ATZ MTZ, März 2003
[17] A. Saad, „Software im Automobil – Ausgangslage, Zielsetzung und Aufgabe der BMW
Car IT“, Automotive Electronics ATZ MTZ, März 2003
[18] G. Wagner, H. Merkle, J. Bortolazzi, D. Marx, K. Lange, „Herstellerinitiative Software“,
Automotive Electronics ATZ MTZ, März 2003