Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR LOADING SOFTWARE
Document Type and Number:
WIPO Patent Application WO/2002/010903
Kind Code:
A2
Abstract:
The invention relates to a method for loading software into a target device of a vehicle control system comprising a number of devices. The inventive method involves the following steps: subdividing the loading of a software module into partial tasks, namely into at least one control device task, one update device task and one receiving device task, and assigning an execution of the partial tasks to the target device, the devices and/or to a control station located outside of the vehicle control system. The control device task involves a processing and routing of control commands for loading the software module from outside of the vehicle control system. The update device task involves a control of the loading of the software module between the target device, the devices and/or the control station, and the receiving device task involves a provision of an interface for the software module to be loaded from outside the vehicle control system. The invention additionally relates to the use of this method, for example, in control systems of motor vehicles.

Inventors:
AMENDOLA SANDRO (DE)
AUGUSTIN LAWRENCE (DE)
SCHNEIDER SANDRA (DE)
UNRUH PETER (DE)
Application Number:
PCT/EP2001/008355
Publication Date:
February 07, 2002
Filing Date:
July 19, 2001
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
DAIMLER CHRYSLER AG (DE)
AMENDOLA SANDRO (DE)
AUGUSTIN LAWRENCE (DE)
SCHNEIDER SANDRA (DE)
UNRUH PETER (DE)
International Classes:
B60R16/02; G06F8/65; G06F9/44; G06F9/445; (IPC1-7): G06F9/00
Foreign References:
US5521588A1996-05-28
US5838251A1998-11-17
DE4334859A11994-12-01
DE19620885A11997-11-27
DE19850133A11999-05-27
DE19750365A11999-05-20
Attorney, Agent or Firm:
Weiss, Klaus (Intellectual Property Management FTP - C 106, Stuttgart, DE)
Download PDF:
Claims:
Patentansprüche
1. Verfahren zum Laden von Software in ein Zielgerät eines Fahrzeugsteuerungssystems mit mehreren Geräten, g e k e n n z e i c h n e t d u r c h die Schritte : Unterteilen des Ladens eines oder mehrerer Softwaremodule (ml, m2) in Teilaufgaben, nämlich wenigstens eine Kontroll gerätaufgabe, eine Updategerätaufgabe und eine Empfangsge rätaufgabe, und Zuweisen einer Durchführung der Teilaufgaben an das Zielge rät (10 ; D1), die Geräte (20 ; 40, D2) und/oder ein Leitgerät (30) außerhalb des Fahrzeugsteuerungssystems, wobei die Kontrollgerätaufgabe ein Verarbeiten und Weiterleiten von Steuerbefehlen für das Laden des Softwaremoduls (ml) von außerhalb des Fahrzeugsteuerungssystems enthält, die Updategerätaufgabe eine Steuerung des Ladens des Soft waremoduls (ml) zwischen dem Zielgerät (10, D1), den Geräten (20 ; 40, D2) und/oder dem Leitgerät (30) enthält und die Empfangsgerätaufgabe eine Bereitstellung einer Schnitt stelle für das von außerhalb des Fahrzeugsteuerungssystems zu ladende Softwaremodul (ml) enthält.
2. Verfahren zum Laden von Software nach Anspruch 1, g e k e n n z e i c h n e t d u r c h weiteres Unterteilen des Ladens des Softwaremoduls (ml) in eine Konfigurationsmanageraufgabe, die eine Überprüfung ent hält, ob das Fahrzeugsteuerungssystem die Anforderungen des zu ladenden Softwaremoduls (ml) bezüglich Hardware und Soft ware erfüllt und ob das zu ladende Softwaremodul (ml) die Anforderungen für den Betrieb des Fahrzeugsteuerungssystems erfüllt.
3. Verfahren zum Laden von Software nach Anspruch 2, d a d u r c h g e k e n n z e i c h n e t, d a s s die zu ladenden Softwaremodule (ml, m2) mit jeweils einer Versionszeile und einer Liste von Anforderungen versehen ist, wobei die Versionszeile eine Bezeichnung des zu laden den Softwaremoduls (ml, m2), eine Kennzeichnung des Zielge räts (D1), eine Kennzeichnung (1, e) für interne oder exter ne Verwendung des zu ladenden Softwaremoduls (ml) im Zielge rät (D1) sowie eine Versionsnummer (vl. l) des zu ladenden Softwaremoduls (ml) aufweist und die Liste der Anforderungen Kennzeichnungen von Geräten (D2), auf die ein Zugriff des zu ladenden Softwaremoduls (ml) vorgesehen ist, die Bezeichnun gen der in den Geräten (D2), auf die ein Zugriff vorgesehen ist, von dem zu ladenden Softwaremodul (ml) benötigten Soft waremodule (m9) und Versionsnummern (l. x) der benötigten Softwaremodule (m9) aufweist, und die Konfigurationsmanager aufgabe eine erste Prüfung, bei der die Anforderungen von im Zielgerät (D1) und in den Geräten (D2) vorhandenen Software modulen (m2, m9) an das zu ladende Softwaremodul (ml) unter Verwendung der Versionszeile des zu ladenden Softwaremoduls (ml) und Listen von Anforderungen der vorhandenen Software module (m2, m9) geprüft werden, und eine zweite Prüfung, bei der die Anforderungen des zu ladenden Softwaremoduls (ml) an die im Zielgerät (D1) und in den Geräten (D2) vorhandenen Softwaremodule unter Verwendung der Liste der Anforderungen des zu ladenden Softwaremoduls (ml) und von Versionszeilen der vorhandenen Softwaremodule (m2, m9) geprüft werden, um fasst.
4. Verfahren zum Laden von Software nach Anspruch 2 oder 3, d a d u r c h g e k e n n z e i c h n e t, d a s s die Konfigurationsmanageraufgabe von einem Gerät (20 ; 40) des Fahrzeugsteuerungssystems durchgeführt wird.
5. Verfahren zum Laden von Software nach Anspruch 2 oder 3, d a d u r c h g e k e n n z e i c h n e t, d a s s die Konfigurationsmanageraufgabe von dem Leitgerät außerhalb des Fahrzeugs durchgeführt wird.
6. Verfahren zum Laden von Software nach einem der vorste henden Ansprüche, g e k e n n z e i c h n e t d u r c h weiteres Unterteilen des Ladens des Softwaremoduls in eine Backupgerätaufgabe, die ein Sichern wenigstens eines Teils von im Zielgerät (10 ; D1) vorhandenen Softwaremodulen inner halb des Fahrzeugsteuerungssystems enthält.
7. Verfahren zum Laden von Software nach einem der vorste henden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, d a s s das Zuweisen der Durchführung der Teilaufgaben in Abhängigkeit der für die Teilaufgaben erforderlichen Rechen leistung, des für die Teilaufgaben erforderlichen Speicher platzes und/oder der im Zielgerät (10 ; D1) und in den Gerä ten (20 ; 40, D2) für die Speicherung von Daten erforderli chen Zeit erfolgt.
8. Verfahren zum Laden von Software nach einem der vorste henden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, d a s s eine Absicherung einer Datenübertragung durch kryptographi sche Verschlüsselung nur außerhalb des Fahrzeugsteuerungs systems erfolgt.
9. Fahrzeugsteuerungssystem zur Durchführung eines Verfah rens nach einem der vorstehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, d a s s zur Durchführung einer Konfigurationsmanageraufgabe, die ei ne Überprüfung enthält, ob das Fahrzeugsteuerungssystem die Anforderungen des zu ladenden Softwaremoduls (ml) bezüglich Hardware und Software erfüllt und ob das zu ladende Soft waremodul (ml) die Anforderungen für den Betrieb des Fahr zeugsteuerungssystems erfüllt, in einem jeweiligen Gerät (D1, D2) des Fahrzeugsteuerungssystems vorhandene Software module (ml, m2, m9) jeweils eine Versionszeile und eine Lis te von Anforderungen enthalten, wobei die Versionszeile eine Bezeichnung des vorhandenen Software moduls (ml, m9) eine Kennzeichnung (l, e) für interne oder externe Verwendung des vorhandenen Softwaremoduls (ml, m9) im jeweiligen Gerät (D1, D2) sowie eine Versionsnummer (v1. 0, v1. 4) des vorhandenen Softwaremoduls (ml, m9) auf weist und die Liste der Anforderungen Kennzeichnungen von Geräten, auf die ein Zugriff des vorhandenen Softwaremoduls vorgesehen ist, Bezeichnungen von Softwaremodulen, die in den Geräten, auf die ein Zugriff vorgesehen ist, von dem vorhandenen Softwaremodul benötigt werden, sowie Versionsnummern der be nötigten Softwaremodule aufweist.
10. Fahrzeugsteuerungssystem nach Anspruch 9, d a d u r c h g e k e n n z e i c h n e t, d a s s das Fahrzeugsteuerungssystem mit einem Leitgerät außerhalb des Fahrzeugsteuerungssystems zur Durchführung der Konfigu rationsmanageraufgabe betreibbar ist.
11. Fahrzeugsteuerungssystem nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass im Fahrzeugsteuerungssystem ein zur Durchführung der Konfi gurationsmanageraufgabe geeignetes Gerät (20 ; 40) vorgesehen ist.
Description:
Verfahren zum Laden von Software Die Erfindung betrifft ein Verfahren zum Laden von Software in ein Zielgerät eines Fahrzeugsteuerungssystems mit) mehre- ren Geräten, sowie ein Fahrzeugsteuerungssystem zur Durch- führung des Verfahrens.

Aus der Offenlegungsschrift DE 43 34 859 AI ist eine Ein- richtung zum Programmieren von elektronischen Steuergeräten in einem Kraftfahrzeug beschrieben, die zum Initialisieren der Steuergeräte am Fertigungsband vorgesehen ist. Die Steu- ergeräte stehen untereinander in Verbindung. Ein Steuergerät ist mit einem externen Programmiergerät kommunikationsfähig, wobei eine vorhandene Sende-/Empfangseinrichtung des Steuer- geräts, z. B. eine Infrarotschließanlage, für die Kommunika- tion genutzt wird.

Bei der Initialisierung von Geräten muss jedes zu program- mierende Gerät ausreichend Rechenleistung und ausreichend freien Speicher haben, um die bei der Programmierung anfal- lenden Aufgaben wahrnehmen zu können. Höhere Anforderungen als bei der Initialisierung gelten für das Einspielen neuer Softwareversionen, d. h. sogenannte Updates, aufgrund einer dann eventuell notwendigen Sicherung vorhandener Software und verringertem freien Speicherplatz durch Belegung mit Be- triebsdaten. Diese höheren Anforderungen sind beispielsweise durch höhere Rechenleistungen und größeren Speicher von Ge- raten eines Fahrzeugsteuersystems zu erfüllen. Andererseits besteht bei Fahrzeugsteuerungssystemen ein erheblicher Kos- tendruck, so dass insbesondere für eine Serienausstattung vorgesehene Geräte möglichst kostengünstig ausgeführt werden müssen. Das Laden von Software in Fahrzeugsteuerungssysteme hat sich bisher daher auf die Initialisierung bestimmter Ge- räte am Fertigungsband sowie auf ein Update spezieller, meist als Sonderausstattung vorgesehener Geräte, wie Naviga- tionssysteme, beschränkt, die über CD (Compact Disc) neue Datensätze erhalten.

Aus der Offenlegungsschrift DE 196 25 002 AI ist ein Fahr- zeugkommunikationssystem bekannt, bei dem Geräteeinheiten zum Senden, Empfangen, Erfassen und/oder Verarbeiten von Da- ten flexibel steuerbar verschiedenen Telematik-Applikationen zugeordnet werden können. Dadurch soll mit geringem Aufwand eine erhöhte Flexibilität bei der Durchführung von Telema- tik-Applikationen bereitgestellt werden, und es soll eine redundante Bestückung des Fahrzeugs mit identischen Geräten für unterschiedliche Telematik-Applikationen vermieden wer- den.

Der Erfindung liegt das technische Problem zugrunde, ein Verfahren zum Laden von Software in ein Zielgerät eines Fahrzeugsteuerungssystems und ein Fahrzeugsteuerungssystem zur Durchführung des Verfahrens bereitzustellen, die nur ge- ringe Anforderungen an die Leistungsfähigkeit des Zielgeräts stellen.

Erfindungsgemäß ist hierzu ein Verfahren zum Laden von Soft- ware mit den Merkmalen von Anspruch 1 sowie ein Fahr- zeugsteuerungssystem mit den Merkmalen von Anspruch 9 vorge- sehen.

Indem das Laden eines Softwaremoduls in Teilaufgaben unter- teilt wird und eine Durchführung der Teilaufgaben an ein Zielgerät, Geräte des Fahrzeugsteuerungssystems und/oder ein Leitgerät außerhalb des Fahrzeugsteuerungssystems zugewiesen wird, müssen nicht alle Aufgaben beim Laden des Softwaremo- duls von einem einzigen Gerät wahrgenommen werden. Dadurch kann die Last, beispielsweise bezüglich Rechenleistung und Speicherkapazität, gemäß der Leistungsfähigkeit der einzel- nen Geräte verteilt werden. Die meisten Geräte eines Fahr- zeugsteuerungssystems sind kein Bestandteil der Serienaus- stattung. Durch intelligente Verteilung der Teilaufgaben kann verhindert werden, dass die wenigen Seriengeräte aufge- rüstet und damit verteuert werden müssen, um ein Software- Update zu ermöglichen. Die Definition von Teilaufgaben ent- spricht der Definition logischer Geräte. Bei der Umsetzung des Verfahrens werden dann die Teilaufgaben oder die logi- schen Geräte den tatsächlich physikalisch vorhandenen Gerä- ten zugewiesen.

Die Teilaufgaben weisen eine Kontrollgerätaufgabe, die ein Verarbeiten und Weiterleiten von Steuerbefehlen für das La- den des Softwaremoduls von außerhalb der Fahrzeugsteuerungs- systems enthält, eine Updategerätaufgabe, die eine Steuerung des Ladens des Softwaremoduls zwischen dem Zielgerät, den Geräten und/oder dem Leitgerät enthält und eine Empfangsge- rätaufgabe auf, die eine Bereitstellung einer Schnittstelle für das von außerhalb des Fahrzeugsteuerungssystems zu la- dende Softwaremodul enthält. Ein Unterteilen in diese Teil- aufgaben ist für ein Fahrzeugsteuerungssystem besonders ge- eignet, da es spezielle, bei einem Fahrzeugsteuerungssystem vorliegende Randbedingungen berücksichtigt. So weisen Fahr- zeugsteuerungssysteme keine leistungsfähigen Zentralrechner auf, der generell die Hauptlast bei einem Ladevorgang über- nehmen könnte. Vielmehr unterscheiden sich verschiedene Aus- stattungsvarianten in Bezug auf die Leistungsfähigkeit der eingebauten Geräte erheblich, so dass erst eine variable Zu- weisung der Teilaufgaben das Laden der Software bei ver- schiedenen Ausstattungsvarianten ermöglicht. Aufgrund der großen Flexibilität des Verfahrens kann dieses auch über mehrere Modellzyklen eines Herstellers angewendet werden.

Das Vorsehen einer Kontrollgerätaufgabe ermöglicht es, ver- schiedene Geräte als Schnittstelle zur Außenwelt zu verwen- den, ohne das Verfahren zum Laden eines Softwaremoduls ver- ändern zu müssen. So kann das Laden eines bzw. mehrerer Softwaremodule beispielsweise von einem externen Diagnosege- rät oder auch von einer Eingabeeinrichtung im Fahrzeug selbst gesteuert werden. Damit kann für den Update von Steu- ergeräten vom Diagnoserechner aus und für den Update eines Navigationssystems vom Bediengerät im Fahrzeug aus dasselbe Verfahren zum Einsatz kommen. Die flexible Zuweisung der Durchführung der Updategerätaufgabe erlaubt es, auch wenig leistungsfähige Geräte im Fahrzeugsteuerungssystem mit neuen Softwaremodulen zu versehen, da die Steuerung des Ladens des Softwaremoduls einem leistungsfähigeren Gerät zugewiesen werden kann.

Das Vorsehen einer Empfangsgerätaufgabe erlaubt es, für ein Update verschiedener Geräte nur ein physikalisches Gerät zu verwenden. Auch kann das Verfahren unverändert angewendet werden wenn anstelle über eine beispielsweise in der Stan- dardausstattung vorgesehene Diagnoseschnittstelle Software über eine nur optional vorgesehene Mobilfunk-oder CD-Rom- Schnittstelle geladen werden soll. Bei Vorliegen unter- schiedlicher Datenübertragungsraten außerhalb des Fahr- zeugsteuerungssystems und im vernetzten Fahrzeugsteuerungs- system kann die Empfangsgerätaufgabe neben dem Empfangen der Daten auch eine Zwischenspeicherung der empfangenen Daten umfassen.

Vorteilhafte Ausgestaltungen der Erfindung sind in den Un- teransprüchen angegeben.

Die Definition einer Konfigurationsmanageraufgabe ermöglicht es, eine rechenintensive Kompatibilitätsprüfung beim Laden eines Softwaremoduls bei Fahrzeugsteuerungssystemen mit Standardausstattung auszulagern und beispielsweise einem Di- agnosegerät zu übertragen. Bei besser ausgestatteten Varian- ten kann dahingegen die Kompatibilitätsprüfung im Rahmen der Konfigurationsmanageraufgabe im Fahrzeug selbst durchgeführt werden, so beispielsweise beim Laden neuer Software für ein Navigationssystem durch den Kunden selbst.

Indem die Daten für das Konfigurationsmanagement in einer Versionszeile und einer Liste von Anforderungen direkt mit der Software mitgeführt werden, ist keine aufwendige zentra- le Datenhaltung erforderlich. Lediglich die Auswertung der mitgeführten Daten wird von dem Gerät zentral durchgeführt, dem die Durchführung der Konfigurationsmanageraufgabe zuge- wiesen wurde. Damit sind für eine Kompatibilitätsprüfung le- diglich so viele zentrale Anteile wie nötig vorgesehen, und das Verfahren ist dadurch in besonderer Weise für ein Fahr- zeugsteuerungssystem geeignet. Es ist außerdem ein Selbst- test der Softwarekonfiguration des Fahrzeugsteuerungssystems möglich.

Das Vorsehen einer Backupgerätaufgabe, die ein Sichern we- nigstens eines Teils von im Zielgerät vorhandenen Software- modulen innerhalb des Fahrzeugsteuerungssystems enthält, er- möglicht eine Sicherung vorhandener Software auch bei Soft- ware-Updates, die vom Kunden selbst, beispielsweise von CD- Rom ohne Verbindung mit einem externen Diagnosegerät, durch- geführt werden, aber beispielsweise auch bei einem Software- Update über Mobilfunk. Die flexible Zuweisung der Backupge- rätaufgabe erlaubt es, ein je nach Ausstattungsvariante hierfür besonders geeignetes Gerät auszuwählen.

Das Zuweisen der Durchführung der Teilaufgaben erfolgt in vorteilhafter Weise in Abhängigkeit der für die Teilaufgaben erforderlichen Rechenleistung, des für die Teilaufgaben er- forderlichen Speicherplatzes und/oder der im Zielgerät und in den Geräten des Fahrzeugsteuerungssystems für die Spei- cherung von Daten erforderlichen Zeit. Auf diese Weise kön- nen rechenintensive, speicherintensive beziehungsweise zeit- kritische Teilaufgaben dem dafür jeweils geeignetsten Gerät zugewiesen werden.

Indem eine Absicherung einer Datenübertragung durch kryp- tographische Verschlüsselung nur außerhalb der Fahrzeugsteu- erungssystem erfolgt, kann der Aufwand gegenüber einer soge- nannten End-To-End-Absicherung deutlich gesenkt werden, so dass Standardausstattungen von Fahrzeugsteuerungssystemen trotz der Möglichkeit, ein Update durchzuführen, einfacher ausgeführt werden können. Insbesondere wird innerhalb des Fahrzeugsteuerungssystems weniger Rechenleistung benötigt und allgemein sinkt der Verwaltungsaufwand, da weniger kryp- tographische Schlüssel verwaltet werden müssen.

Das der Erfindung zugrunde liegende technische Problem wird auch durch ein Fahrzeugsteuerungssystem mit den Merkmalen von Anspruch 9 gelöst. Bei einem solchen Fahrzeugsteuerungs- system werden die für die Durchführung einer Kompatibili- tätsprüfung im Rahmen einer Konfigurationsmanageraufgabe be- nötigten Daten mit der Software mitgeführt. Hierzu weisen die in den jeweiligen Geräten des Fahrzeugsteuerungssystems vorhandenen Softwaremodule jeweils eine Versionszeile und eine Liste von Anforderungen auf. Mit einem solchen Fahr- zeugsteuerungssystem kann eine Kompatibilitätsprüfung für ein zu ladendes Softwaremodul ohne aufwendige zentrale Da- tenhaltung durchgeführt werden, da die erforderlichen Daten an die Softwaremodule selbst angehängt sind. Ein solches Fahrzeugsteuerungssystem ist damit besonders gut geeignet, in verschiedenen Ausstattungsvarianten, einschließlich ein- facher Standardausstattungen, hergestellt zu werden.

Indem das Fahrzeugsteuerungssystem mit einem Leitgerät au- ßerhalb des Fahrzeugsteuerungssystem betreibbar ist, kann die Konfigurationsmanageraufgabe außerhalb des Fahrzeugsteu- erungssystems durchgeführt werden, wodurch die Anforderungen an die Geräte des Fahrzeugsteuerungssystems gesenkt werden.

Vorteilhaft ist aber auch, wenn im Fahrzeugsteuerungssystem ein zur Durchführung der Konfigurationsmanageraufgabe geeig- netes Gerät vorgesehen ist, da dann eine Kompatibilitätsprü- fung, nämlich ob das Fahrzeugsteuerungssystem die Anforde- rungen des zu ladenden Softwaremoduls bezüglich Hardware und Software erfüllt und ob das zu ladende Softwaremodul die An- forderungen für den Betrieb des Fahrzeugsteuerungssystems erfüllt, im Fahrzeug selbst durchgeführt werden kann. Dies ist beispielsweise bei Übertragung der Daten per Mobilfunk oder von CD-Rom vorteilhaft, wenn ein Update ohne Anschlie- ßen eines externen Geräts durchgeführt werden soll.

Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der beigefügten Zeichnung im Zusammenhang mit der folgenden Beschreibung. In der Zeichnung zeigt : Figur 1 zeigt eine schematische Darstellung einer ersten bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens und des erfindungsgemäßen Fahrzeugsteuerungssystems und Figur 2 eine schematische Darstellung der bei einer Weiteren bevorzugten Ausführungsform der Erfindung durchgeführten Prüfungen im Rahmen der Konfigurationsmanageraufgabe.

Figur 1 zeigt schematisch ein Fahrzeugsteuerungssystem gemäß einer bevorzugten Ausführungsform der Erfindung und verdeut- licht eine bevorzugte Ausführungsform des erfindungsgemäßen Verfahrens. Das Fahrzeugsteuerungssystem ist in der Figur 1 durch ein Zielgerät 10 und ein Gerät 1 20 angedeutet, die miteinander vernetzt sind. Im Sinne einer übersichtlichen Darstellung sind weitere Geräte des Fahrzeugsteuerungssys- tems nicht dargestellt. Ein Leitgerät außerhalb der Fahr- zeugsteuerungssystems ist durch einen Diagnosetester 30 dar- gestellt, der mit dem Fahrzeugsteuerungssystem in Verbindung steht. Bei der dargestellten Ausführungsform übernimmt der Diagnosetester 30 eine Kontrollgerätaufgabe, indem er Steu- erbefehle für das Laden eines Softwaremoduls von außerhalb des Fahrzeugsteuerungssystems verarbeitet und weiterleitet.

Der Diagnosetester 30 stellt damit die Schnittstelle zur Au- ßenwelt dar, über die ein Bediener das Laden des Softwaremo- duls anstößt und Rückmeldungen über den Fortgang des Verfah- rens erhält.

Das Softwaremodul soll in das Zielgerät 10 geladen werden.

Das Zielgerät 10 übernimmt sowohl eine Updategerätaufgabe, indem es den Ladevorgang des Softwaremoduls zwischen dem Zielgerät 10, dem Gerät 1 20 und dem Diagnosetester 30 steu- ert, als auch eine Empfangsgerätaufgabe, indem es eine Schnittstelle für das von außerhalb des Fahrzeugsteuerungs- systems, nämlich vom Diagnosetester 30, zu ladende Software- modul bereitstellt sowie eine Backupgerätaufgabe, indem es im Zielgerät 10 vorhandene Softwaremodule vor dem Einspielen des neuen Softwaremoduls sichert.

Das Gerät 1 20 übernimmt eine Konfigurationsmanageraufgabe, indem es überprüft, ob das Fahrzeugsteuerungssystem die An- forderungen des zu ladenden Softwaremoduls bezüglich Hard- ware und Software erfüllt und ob das zu ladende Softwaremo- dul die Anforderungen für den Betrieb des Fahrzeugsteue- rungssystems erfüllt.

Damit sind im vorliegendem Fall verschiedene Teilaufgaben des Ladevorgangs verschiedenen Geräten, nämlich dem Diagno- setester 30, dem Zielgerät 10 und dem Gerät 1 20 zugewiesen.

Mit anderen Worten sind dem Diagnosetester 30 die Aufgaben eines Kontrollgerätes, dem Zielgerät 10 die Aufgaben eines Zielgeräts, eines Updategeräts, eines Empfangsgeräts sowie eines Backupgeräts und dem Gerät 1 20 die Aufgaben eines Konfigurationsmanagers zugewiesen. Dadurch wird die Rechen- und Speicherlast des Update-Vorgangs entsprechend den Fähig- keiten der einzelnen Geräte verteilt.

Der Updatevorgang wird von dem Diagnosetester 30 mit einer Updateanfrage gestartet. Zusammen mit der Updateanfrage sen- det der Diagnosetester 30 Kontrolldaten zum Zielgerät 10. Im Rahmen der Updategerätaufgabe generiert das Zielgerät 10 aus diesen Kontrolldaten und aus seinem internen Status Konfigu- rationsdaten für das Konfigurationsmanagement.

Diese Konfigurationsdaten werden zum Gerät 1 20 gesendet, das dann im Rahmen der Konfigurationsmanageraufgabe prüft, ob die neue Konfiguration zum Gesamtsystem passt oder nicht, nämlich ob das zu ladende Softwaremodul die Anforderungen des Fahrzeugsteuerungssystems erfüllt und umgekehrt. Diese Information sendet das Gerät 1 20 zum Zielgerät 10. Im dar- gestellten Fall wurde das Prüfen der neuen Konfiguration mit positiven Ergebnis abgeschlossen, so dass das Gerät 1 20 die Information"Konfiguration OK"an das Zielgerät 10 sendet.

Das Zielgerät 10 überprüft weiter, ob sein interner Zustand einen Software-Update erlaubt und ob der für den Update- Vorgang erforderliche Speicherplatz im Zielgerät 10 vorhan- den ist. Im Rahmen der Updategerätaufgabe sendet das Zielge- rät 10 dann die Bestätigung"Konfiguration und Zustand OK", dass ein Update möglich ist, an den Diagnosetester 30.

Anhand der vom Diagnosetester 30 im Rahmen der Kontrollge- rätaufgabe zusammen mit der Update-Anfrage übersendeten Kon- trolldaten erkennt das Gerät 10, welche Teile der Software vor einem Einspielen des neuen Softwaremoduls gesichert wer- den müssen. Im Rahmen der Backupgerätaufgabe führt das Ziel- gerät 10 dann eine Sicherung der vorhandenen Software durch.

Diese Sicherung kann innerhalb des Fahrzeugsteuerungssystems beispielsweise im Zielgerät 10 selbst oder durch Auslagern auf ein anderes Geräts des Fahrzeugsteuerungssystems oder extern beispielsweise durch Sicherung im Diagnosetester au- ßerhalb des Fahrzeugsteuerungssystems erfolgen. Ausgelöst wird die Sicherung der vorhandenen Software durch eine er- neute Übertragung einer Updateanfrage und eines Sicherungs- befehls vom Diagnosetester 30. Nach Abschluß der Sicherung gibt das Zielgerät 10 die Meldung"Sicherung OK"an den Di- agnosetester 30 zurück.

Nach einer erfolgreichen Sicherung erhält das Zielgerät 10 im Rahmen der Updategerätaufgabe das neue Softwaremodul zu- sammen mit Prüfsumme, bspw. CRC, und Signatur. Das Zielgerät 10 führt eine Zwischenspeicherung des neuen Softwaremoduls durch und erfüllt dadurch eine Empfangsgerätaufgabe, indem es eine Schnittstelle zwischen dem Diagnosetester 30 außer- halb des Fahrzeugsteuerungssystems und dem Fahrzeugsteue- rungssystem selbst bereitstellt. Beispielsweise kann das neue Softwaremodul vom Diagnosetester 30 zum Zielgerät 10 mit einer anderen Datenübertragungsrate als im Fahrzeugsteu- erungssystem selbst, nämlich zwischen dem Zielgerät 10 und dem Gerät 1 20, verwendet wird, übertragen werden. Durch Zwischenspeichern des neuen Softwaremoduls werden die ankom- menden Daten gepuffert und können mit der im Fahrzeugsteue- rungssystem verwendeten Datenübertragungsrate weitergegeben werden.

Im Zielgerät 10 wird das neue Softwaremodul dekomprimiert, die Signatur wird überprüft und das neue Softwaremodul wird eingespeichert. Eine Prüfsumme, bspw. CRC, wird berechnet und überprüft. Darüber hinaus wird die erfolgreiche Instal- lation des neuen Softwaremoduls getestet.

Sind die Prüfungen der Signatur, der Prüfsumme und der In- stallation erfolgreich, erzeugt das Zielgerät 10 im Rahmen der Updategerätaufgabe Konfigurationsdaten und sendet diese an das Gerät 1 20, das im Rahmen der Konfigurationsmanager- aufgabe die neue, nun aktuelle Konfiguration speichert. Nach Speichern der Konfiguration sendet das Gerät 1 20 eine Bes- tätigung"Konfiguration OK".

Nach Erhalt dieser Bestätigung vom Gerät 1 20 gibt das Ziel- gerät die Installation des neuen Softwaremoduls frei. Das Zielgerät 10 kennzeichnet dazu das neue Softwaremodul als gültig und löscht die zuvor gespeicherte alte Software.

Abschließend gibt das Updategerät eine Bestätigung des er- folgreichen Software-Updates an das Kontrollgerät, im vor- liegendem Fall an den Diagnosetester 30 aus. Am Diagnosetes- ter 30 kann der erfolgreiche Abschluss des Updates dann für einen Bediener angezeigt werden.

Im folgenden wird anhand der Figur 2 ein bevorzugter Ablauf einer Konfigurationsprüfung bei einer weiteren Ausführungs- form des erfindungsgemäßen Verfahrens zum Laden von Software mit einem erfindungsgemäßen Fahrzeugsteuerungssystem erläu- tert. Jedes Softwaremodul ist eine Einheit von Software, die ausgetauscht bzw. neu eingespielt werden kann. Jedes Soft- waremodul weist eine Versionszeile auf, die die Bezeichnung des Zielgeräts, den Modulnamen, eine Kennzeichnung für loka- le oder externe Verwendung und die Versionsnummer sowie op- tional weitere Angaben enthält. Im Fall der zu ladenden Softwaremodule ml und m2 in der Figur 2 lautet die Bezeich- nung des Zielgeräts D1, das eine Softwaremodul trägt den Na- men ml, eine ausschließlich interne Verwendung ist durch den Buchstaben 1 angedeutet und das Softwaremodul ml hat sie Version vl. l. Die Versionszeile des Softwaremoduls ml lautet demnach Dl. ml 1 vl. l.

Das Softwaremodul ml führt auch eine Liste von Anforderungen an andere Softwaremodule mit sich. Die Liste von Anforderun- gen enthält Kennzeichnungen von Geräten, auf die ein Zugriff des zu ladenden Softwaremoduls ml vorgesehen ist, die Be- zeichnungen der in den Geräten, auf die ein Zugriff vorgese- hen ist, von dem zu ladenden Softwaremodul ml benötigten Softwaremodule, sowie Versionsnummer der benötigten Soft- waremodule. Im Fall des Softwaremoduls ml ist ein Zugriff auf ein Gerät D2 vorgesehen, in dem von dem zu ladenden Softwaremodul ml ein Softwaremodul m9 in der Version 1. x be- nötigt wird. Die Liste der Anforderungen des Softwaremoduls ml lautet demnach D2. m9 l. x.

Die in der Liste der Anforderungen enthaltenen Softwaremodu- le müssen in der angegebenen Version im Fahrzeugsteuerungs- system vorhanden sein. Die neu einzuspielenden Softwaremodu- le ml und m2 werden in die Konfigurationsprüfung in einem Gerät 40 eingecheckt. Das Gerät 40 liegt innerhalb des Fahr- zeugsteuerungssystems, die Konfigurationsprüfung könnte aber auch von einem außerhalb liegenden Gerät durchgeführt wer- den. Eine Kompatibilität des Softwaremoduls ml mit dem Fahr- zeugsteuerungssystem wird nun geprüft, indem in einer ersten Prüfung die Listen von Anforderungen der bereits im Fahr- zeugsteuerungssystem vorhandenen Softwaremodule geprüft wer- den. In der Darstellung der Figur 2 ist zu erkennen, dass die Liste der Anforderungen des Softwaremoduls m2 im Gerät D1 leer ist, das Modul m2 also keine Anforderungen z. B. an das Softwaremodul ml stellt. Das Softwaremodul ml wird vom Gerät D1 auch nicht für eine externe Verwendung zur Verfü- gung gestellt, was durch den Buchstaben 1 in der Versions- zeile des Moduls ml angedeutet ist. Damit haben weitere Softwaremodule auf anderen Geräten, im dargestellten Fall also das Modul m9 auf Gerät D2, keine Anforderungen an das Softwaremodul ml.

In einer zweiten Prüfung werden dann die Anforderungen des zu ladenden Softwaremoduls ml und m2 an die im Fahrzeugsteu- erungssystem vorhandenen Softwaremodule geprüft. Hierzu wird die Liste der Anforderungen des Softwaremoduls ml bzw. m2 herangezogen. Im Beispiel der Figur 2 benötigt das Software- modul ml gemäß seiner Liste von Anforderungen auf dem Gerät D2 ein Softwaremodul m9 in einer Version l. x, d. h. die zwei- te Ziffer der Versionsnummer ist beliebig. Im Rahmen der Konfigurationsmanageraufgabe vergleicht das Gerät 40 die Liste der Anforderungen des Softwaremoduls ml mit der Versi- onszeile des im Gerät D2 vorhandenen Softwaremoduls xl. Die Versionszeile des Softwaremoduls xl lautet D2 m9e v1. 4. In der Versionszeile ist die Bezeichnung des Softwaremoduls m9 sowie der Buchstabe e enthalten, der für eine externe Ver- wendung des Softwaremoduls m9 im Gerät D2 steht. Das Soft- waremodul m9 liegt im Gerät D2 in der Version v1. 4 vor. Ein Vergleich der Liste der Anforderungen D2. m9 1. x des Soft- waremoduls ml mit der Versionszeile m9 e v1. 4 des Software- moduls m9 ergibt, dass die Anforderungen des Softwaremoduls ml durch das Softwaremodul m9 erfüllt werden. Anschließend wird analog dazu m2 geprüft, auch hier werden alle Anforde- rungen erfüllt. Infolgedessen kann das Gerät 40 zum Ab- schluss der Konfigurationsprüfung eine Meldung"OK"ausge- ben, dass das neue Softwaremodul ml in das Gerät D1 einge- spielt werden kann.