DE10037397A1 - Verfahren zum Laden von Software - Google Patents

Abstract

Die Erfindung betrifft ein Verfahren zum Laden von Software in ein Zielgerät eines Fahrzeugsteuerungssystems mit mehreren Geräten. DOLLAR A Erfindungsgemäß sind folgende Schritte vorgesehen: Unterteilen des Ladens eines Softwaremoduls in Teilaufgaben, nämlich wenigstens eine Kontrollgerätaufgabe, eine Updategerätaufgabe und eine Empfangsgerätaufgabe, und Zuweisen einer Durchführung der Teilaufgaben an das Zielgerät, die Geräte und/oder ein Leitgerät außerhalb des Fahrzeugsteuerungssystems, wobei die Kontrollgerätaufgabe ein Verarbeiten und Weiterleiten von Steuerbefehlen für das Laden des Softwaremoduls von außerhalb des Fahrzeugsteuerungssystems enthält, die Updategerätaufgabe eine Steuerung des Ladens des Softwaremoduls zwischen dem Zielgerät, den Geräten und/oder dem Leitgerät enthält und die Empfangsgerätaufgabe eine Bereitstellung einer Schnittstelle für das von außerhalb des Fahrzeugsteuerungssystems zu ladende Softwaremodul enthält. DOLLAR A Verwendung z. B. in Steuerungssystemen von Kraftfahrzeugen.

Description

Die Erfindung betrifft ein Verfahren zum Laden von Software in ein Zielgerät eines Fahrzeugsteuerungssystems mit mehreren Ge­ räten, sowie ein Fahrzeugsteuerungssystem zur Durchführung des Verfahrens.

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

Bei der Initialisierung von Geräten muss jedes zu programmie­ rende Gerät ausreichend Rechenleistung und ausreichend freien Speicher haben, um die bei der Programmierung anfallenden Auf­ gaben wahrnehmen zu können. Höhere Anforderungen als bei der Initialisierung gelten für das Einspielen neuer Softwareversio­ nen, d. h. sogenannte Updates, aufgrund einer dann eventuell notwendigen Sicherung vorhandener Software und verringertem freien Speicherplatz durch Belegung mit Betriebsdaten. Diese höheren Anforderungen sind beispielsweise durch höhere Rechen­ leistungen und größeren Speicher von Geräten eines Fahrzeug­ steuersystems zu erfüllen. Andererseits besteht bei Fahrzeug­ steuerungssystemen ein erheblicher Kostendruck, so dass insbe­ sondere 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 In­ itialisierung bestimmter Geräte am Fertigungsband sowie auf ein Update spezieller, meist als Sonderausstattung vorgesehener Ge­ räte, wie Navigationssysteme, beschränkt, die über CD (Compact Disc) neue Datensätze erhalten.

Aus der Offenlegungsschrift DE 196 25 002 A1 ist ein Fahrzeug­ kommunikationssystem bekannt, bei dem Geräteeinheiten zum Sen­ den, Empfangen, Erfassen und/oder Verarbeiten von Daten flexi­ bel steuerbar verschiedenen Telematik-Applikationen zugeordnet werden können. Dadurch soll mit geringem Aufwand eine erhöhte Flexibilität bei der Durchführung von Telematik-Applikationen bereitgestellt werden, und es soll eine redundante Bestückung des Fahrzeugs mit identischen Geräten für unterschiedliche Te­ lematik-Applikationen vermieden werden.

Der Erfindung liegt das technische Problem zugrunde, ein Ver­ fahren zum Laden von Software in ein Zielgerät eines Fahrzeug­ steuerungssystems und ein Fahrzeugsteuerungssystem zur Durch­ führung des Verfahrens bereitzustellen, die nur geringe Anfor­ derungen an die Leistungsfähigkeit des Zielgeräts stellen.

Erfindungsgemäß ist hierzu ein Verfahren zum Laden von Software mit den Merkmalen von Anspruch 1 sowie ein Fahrzeugsteuerungs­ system mit den Merkmalen von Anspruch 9 vorgesehen.

Indem das Laden eines Softwaremoduls in Teilaufgaben unterteilt 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 Softwaremoduls von einem einzigen Gerät wahrgenommen werden. Dadurch kann die Last, bei­ spielsweise bezüglich Rechenleistung und Speicherkapazität, ge­ mäß der Leistungsfähigkeit der einzelnen Geräte verteilt wer­ den. Die meisten Geräte eines Fahrzeugsteuerungssystems sind kein Bestandteil der Serienausstattung. Durch intelligente Ver­ teilung der Teilaufgaben kann verhindert werden, dass die weni­ gen Seriengeräte aufgerüstet und damit verteuert werden müssen, um ein Software-Update zu ermöglichen. Die Definition von Tei­ laufgaben entspricht der Definition logischer Geräte. Bei der Umsetzung des Verfahrens werden dann die Teilaufgaben oder die logischen Geräte den tatsächlich physikalisch vorhandenen Gerä­ ten zugewiesen.

Die Teilaufgaben weisen eine Kontrollgerätaufgabe, die ein Ver­ arbeiten und Weiterleiten von Steuerbefehlen für das Laden des Softwaremoduls von außerhalb der Fahrzeugsteuerungssystems ent­ hä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 Empfangsgerätaufgabe auf, die eine Bereitstellung einer Schnittstelle für das von außerhalb des Fahrzeugsteuerungssystems zu ladende Softwaremodul enthält. Ein Unterteilen in diese Teilaufgaben ist für ein Fahrzeug­ steuerungssystem besonders geeignet, da es spezielle, bei einem Fahrzeugsteuerungssystem vorliegende Randbedingungen berück­ sichtigt. So weisen Fahrzeugsteuerungssysteme keine leistungs­ fähigen Zentralrechner auf, der generell die Hauptlast bei ei­ nem Ladevorgang übernehmen könnte. Vielmehr unterscheiden sich verschiedene Ausstattungsvarianten in Bezug auf die Leistungs­ fähigkeit der eingebauten Geräte erheblich, so dass erst eine variable Zuweisung der Teilaufgaben das Laden der Software bei verschiedenen Ausstattungsvarianten ermöglicht. Aufgrund der großen Flexibilität des Verfahrens kann dieses auch über mehre­ re Modellzyklen eines Herstellers angewendet werden.

Das Vorsehen einer Kontrollgerätaufgabe ermöglicht es, ver­ schiedene Geräte als Schnittstelle zur Außenwelt zu verwenden, ohne das Verfahren zum Laden eines Softwaremoduls verändern zu müssen. So kann das Laden eines bzw. mehrerer Softwaremodule beispielsweise von einem externen Diagnosegerät oder auch von einer Eingabeeinrichtung im Fahrzeug selbst gesteuert werden. Damit kann für den Update von Steuergeräten vom Diagnoserechner aus und für den Update eines Navigationssystems vom Bediengerät im Fahrzeug aus dasselbe Verfahren zum Einsatz kommen. Die fle­ xible Zuweisung der Durchführung der Updategerätaufgabe erlaubt es, auch wenig leistungsfähige Geräte im Fahrzeugsteuerungssy­ stem 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 Up­ date verschiedener Geräte nur ein physikalisches Gerät zu ver­ wenden. Auch kann das Verfahren unverändert angewendet werden wenn anstelle über eine beispielsweise in der Standardausstat­ tung vorgesehene Diagnoseschnittstelle Software über eine nur optional vorgesehene Mobilfunk- oder CD-Rom-Schnittstelle gela­ den werden soll. Bei Vorliegen unterschiedlicher Datenübertra­ gungsraten außerhalb des Fahrzeugsteuerungssystems und im ver­ netzten Fahrzeugsteuerungssystem kann die Empfangsgerätaufgabe neben dem Empfangen der Daten auch eine Zwischenspeicherung der empfangenen Daten umfassen.

Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteran­ sprüchen angegeben.

Die Definition einer Konfigurationsmanageraufgabe ermöglicht es, eine rechenintensive Kompatibilitätsprüfung beim Laden ei­ nes Softwaremoduls bei Fahrzeugsteuerungssystemen mit Standar­ dausstattung auszulagern und beispielsweise einem Diagnosegerät zu übertragen. Bei besser ausgestatteten Varianten kann dahin­ gegen die Kompatibilitätsprüfung im Rahmen der Konfigurations­ manageraufgabe im Fahrzeug selbst durchgeführt werden, so bei­ spielsweise beim Laden neuer Software für ein Navigationssystem durch den Kunden selbst.

Indem die Daten für das Konfigurationsmanagement in einer Ver­ sionszeile und einer Liste von Anforderungen direkt mit der Software mitgeführt werden, ist keine aufwendige zentrale Da­ tenhaltung erforderlich. Lediglich die Auswertung der mitge­ führten Daten wird von dem Gerät zentral durchgeführt, dem die Durchführung der Konfigurationsmanageraufgabe zugewiesen wurde.

Damit sind für eine Kompatibilitätsprüfung lediglich so viele zentrale Anteile wie nötig vorgesehen, und das Verfahren ist dadurch in besonderer Weise für ein Fahrzeugsteuerungssystem geeignet. Es ist außerdem ein Selbsttest der Softwarekonfigura­ tion des Fahrzeugsteuerungssystems möglich.

Das Vorsehen einer Backupgerätaufgabe, die ein Sichern wenig­ stens eines Teils von im Zielgerät vorhandenen Softwaremodulen innerhalb des Fahrzeugsteuerungssystems enthält, ermöglicht ei­ ne Sicherung vorhandener Software auch bei Software-Updates, die vom Kunden selbst, beispielsweise von CD-Rom ohne Verbin­ dung mit einem externen Diagnosegerät, durchgeführt werden, aber beispielsweise auch bei einem Software-Update über Mobil­ funk. Die flexible Zuweisung der Backupgerätaufgabe erlaubt es, ein je nach Ausstattungsvariante hierfür besonders geeignetes Gerät auszuwählen.

Das Zuweisen der Durchführung der Teilaufgaben erfolgt in vor­ teilhafter Weise in Abhängigkeit der für die Teilaufgaben er­ forderlichen Rechenleistung, des für die Teilaufgaben erforder­ lichen Speicherplatzes und/oder der im Zielgerät und in den Ge­ räten des Fahrzeugsteuerungssystems für die Speicherung von Da­ ten erforderlichen Zeit. Auf diese Weise können rechenintensi­ ve, speicherintensive beziehungsweise zeitkritische Teilaufga­ ben dem dafür jeweils geeignetsten Gerät zugewiesen werden.

Indem eine Absicherung einer Datenübertragung durch kryptogra­ phische Verschlüsselung nur außerhalb der Fahrzeugsteuerungssy­ stem erfolgt, kann der Aufwand gegenüber einer sogenannten End- To-End-Absicherung deutlich gesenkt werden, so dass Standar­ dausstattungen von Fahrzeugsteuerungssystemen trotz der Mög­ lichkeit, ein Update durchzuführen, einfacher ausgeführt werden können. Insbesondere wird innerhalb des Fahrzeugsteuerungssy­ stems weniger Rechenleistung benötigt und allgemein sinkt der Verwaltungsaufwand, da weniger kryptographische Schlüssel ver­ waltet 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 Fahrzeugsteuerungssystem werden die für die Durchführung einer Kompatibilitätsprüfung im Rahmen einer Konfigurationsmanageraufgabe benötigten Daten mit der Software mitgeführt. Hierzu weisen die in den jeweiligen Geräten des Fahrzeugsteuerungssystems vorhandenen Softwaremodu­ le jeweils eine Versionszeile und eine Liste von Anforderungen auf. Mit einem solchen Fahrzeugsteuerungssystem kann eine Kom­ patibilitätsprüfung für ein zu ladendes Softwaremodul ohne auf­ wendige zentrale Datenhaltung durchgeführt werden, da die er­ forderlichen Daten an die Softwaremodule selbst angehängt sind. Ein solches Fahrzeugsteuerungssystem ist damit besonders gut geeignet, in verschiedenen Ausstattungsvarianten, einschließ­ lich einfacher Standardausstattungen, hergestellt zu werden.

Indem das Fahrzeugsteuerungssystem mit einem Leitgerät außer­ halb des Fahrzeugsteuerungssystem betreibbar ist, kann die Kon­ figurationsmanageraufgabe außerhalb des Fahrzeugsteuerungssy­ stems durchgeführt werden, wodurch die Anforderungen an die Ge­ räte des Fahrzeugsteuerungssystems gesenkt werden.

Vorteilhaft ist aber auch, wenn im Fahrzeugsteuerungssystem ein zur Durchführung der Konfigurationsmanageraufgabe geeignetes Gerät vorgesehen ist, da dann eine Kompatibilitätsprüfung, näm­ lich ob das Fahrzeugsteuerungssystem die Anforderungen des zu ladenden Softwaremoduls bezüglich Hardware und Software erfüllt und ob das zu ladende Softwaremodul die Anforderungen 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 vorteil­ haft, 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 Be­ schreibung. In der Zeichnung zeigt

Fig. 1 zeigt eine schematische Darstellung einer ersten bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens und des erfindungsgemäßen Fahrzeugsteuerungssystems und

Fig. 2 eine schematische Darstellung der bei einer weiteren bevorzugten Ausführungsform der Erfindung durchgeführten Prüfungen im Rahmen der Konfigurati­ onsmanageraufgabe.

Fig. 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 Fig. 1 durch ein Zielgerät 10 und ein Gerät I 20 angedeutet, die mit­ einander vernetzt sind. Im Sinne einer übersichtlichen Darstel­ lung sind weitere Geräte des Fahrzeugsteuerungssystems nicht dargestellt. Ein Leitgerät außerhalb der Fahrzeugsteuerungssy­ stems ist durch einen Diagnosetester 30 dargestellt, der mit dem Fahrzeugsteuerungssystem in Verbindung steht. Bei der dar­ gestellten Ausführungsform übernimmt der Diagnosetester 30 eine Kontrollgerätaufgabe, indem er Steuerbefehle für das Laden ei­ nes Softwaremoduls von außerhalb des Fahrzeugsteuerungssystems verarbeitet und weiterleitet. Der Diagnosetester 30 stellt da­ mit die Schnittstelle zur Außenwelt dar, über die ein Bediener das Laden des Softwaremoduls anstößt und Rückmeldungen über den Fortgang des Verfahrens 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 I 20 und dem Diagnosetester 30 steuert, als auch eine Empfangsgerätaufgabe, indem es eine Schnittstelle für das von außerhalb des Fahrzeugsteuerungssystems, nämlich vom Diagnose­ tester 30, zu ladende Softwaremodul bereitstellt sowie eine Backupgerätaufgabe, indem es im Zielgerät 10 vorhandene Softwa­ remodule vor dem Einspielen des neuen Softwaremoduls sichert.

Das Gerät I 20 übernimmt eine Konfigurationsmanageraufgabe, in­ dem es überprüft, ob das Fahrzeugsteuerungssystem die Anforde­ rungen des zu ladenden Softwaremoduls bezüglich Hardware und Software erfüllt und ob das zu ladende Softwaremodul die Anfor­ derungen für den Betrieb des Fahrzeugsteuerungssystems erfüllt.

Damit sind im vorliegendem Fall verschiedene Teilaufgaben des Ladevorgangs verschiedenen Geräten, nämlich dem Diagnosetester 30, dem Zielgerät 10 und dem Gerät I 20 zugewiesen. Mit anderen Worten sind dem Diagnosetester 30 die Aufgaben eines Kontroll­ gerätes, dem Zielgerät 10 die Aufgaben eines Zielgeräts, eines Updategeräts, eines Empfangsgeräts sowie eines Backupgeräts und dem Gerät I 20 die Aufgaben eines Konfigurationsmanagers zuge­ wiesen. Dadurch wird die Rechen- und Speicherlast des Update-Vorgangs entsprechend den Fähigkeiten der einzelnen Ge­ räte verteilt.

Der Updatevorgang wird von dem Diagnosetester 30 mit einer Up­ dateanfrage gestartet. Zusammen mit der Updateanfrage sendet 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 Konfigurationsda­ ten für das Konfigurationsmanagement.

Diese Konfigurationsdaten werden zum Gerät I 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 Fahrzeug­ steuerungssystems erfüllt und umgekehrt. Diese Information sen­ det das Gerät I 20 zum Zielgerät 10. Im dargestellten Fall wur­ de das Prüfen der neuen Konfiguration mit positiven Ergebnis abgeschlossen, so dass das Gerät I 20 die Information "Konfigu­ ration OK" an das Zielgerät 10 sendet.

Das Zielgerät 10 überprüft weiter, ob sein interner Zustand ei­ nen Software-Update erlaubt und ob der für den Update-Vorgang erforderliche Speicherplatz im Zielgerät 10 vorhanden ist. Im Rahmen der Updategerätaufgabe sendet das Zielgerä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 werden müs­ sen. Im Rahmen der Backupgerätaufgabe führt das Zielgerät 10 dann eine Sicherung der vorhandenen Software durch. Diese Si­ cherung kann innerhalb des Fahrzeugsteuerungssystems beispiels­ weise im Zielgerät 10 selbst oder durch Auslagern auf ein ande­ res Geräts des Fahrzeugsteuerungssystems oder extern beispiels­ weise durch Sicherung im Diagnosetester außerhalb des Fahrzeug­ steuerungssystems erfolgen. Ausgelöst wird die Sicherung der vorhandenen Software durch eine erneute Übertragung einer Upda­ teanfrage und eines Sicherungsbefehls vom Diagnosetester 30. Nach Abschluß der Sicherung gibt das Zielgerät 10 die Meldung "Sicherung OK" an den Diagnosetester 30 zurück.

Nach einer erfolgreichen Sicherung erhält das Zielgerät 10 im Rahmen der Updategerätaufgabe das neue Softwaremodul zusammen mit Prüfsumme, bspw. CRC, und Signatur. Das Zielgerät 10 führt eine Zwischenspeicherung des neuen Softwaremoduls durch und er­ füllt dadurch eine Empfangsgerätaufgabe, indem es eine Schnitt­ stelle zwischen dem Diagnosetester 30 außerhalb des Fahrzeug­ steuerungssystems und dem Fahrzeugsteuerungssystem selbst be­ reitstellt. Beispielsweise kann das neue Softwaremodul vom Dia­ gnosetester 30 zum Zielgerät 10 mit einer anderen Datenübertra­ gungsrate als im Fahrzeugsteuerungssystem selbst, nämlich zwi­ schen dem Zielgerät 10 und dem Gerät I 20, verwendet wird, übertragen werden. Durch Zwischenspeichern des neuen Software­ moduls werden die ankommenden Daten gepuffert und können mit der im Fahrzeugsteuerungssystem verwendeten Datenübertragungs­ rate weitergegeben werden.

Im Zielgerät 10 wird das neue Softwaremodul dekomprimiert, die Signatur wird überprüft und das neue Softwaremodul wird einge­ speichert. Eine Prüfsumme, bspw. CRC, wird berechnet und über­ prüft. Darüber hinaus wird die erfolgreiche Installation des neuen Softwaremoduls getestet.

Sind die Prüfungen der Signatur, der Prüfsumme und der Instal­ lation erfolgreich, erzeugt das Zielgerät 10 im Rahmen der Up­ dategerätaufgabe Konfigurationsdaten und sendet diese an das Gerät I 20, das im Rahmen der Konfigurationsmanageraufgabe die neue, nun aktuelle Konfiguration speichert. Nach Speichern der Konfiguration sendet das Gerät I 20 eine Bestätigung "Konfigu­ ration OK".

Nach Erhalt dieser Bestätigung vom Gerät I 20 gibt das Zielge­ rät die Installation des neuen Softwaremoduls frei. Das Zielge­ rä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 erfolg­ reichen Software-Updates an das Kontrollgerät, im vorliegendem Fall an den Diagnosetester 30 aus. Am Diagnosetester 30 kann der erfolgreiche Abschluss des Updates dann für einen Bediener angezeigt werden.

Im folgenden wird anhand der Fig. 2 ein bevorzugter Ablauf ei­ ner Konfigurationsprüfung bei einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens zum Laden von Software mit ei­ nem erfindungsgemäßen Fahrzeugsteuerungssystem erläutert. Jedes Softwaremodul ist eine Einheit von Software, die ausgetauscht bzw. neu eingespielt werden kann. Jedes Softwaremodul weist ei­ ne Versionszeile auf, die die Bezeichnung des Zielgeräts, den Modulnamen, eine Kennzeichnung für lokale oder externe Verwen­ dung und die Versionsnummer sowie optional weitere Angaben ent­ hält. Im Fall der zu ladenden Softwaremodule m1 und m2 in der Fig. 2 lautet die Bezeichnung des Zielgeräts D1, das eine Softwaremodul trägt den Namen m1, eine ausschließlich interne Verwendung ist durch den Buchstaben l angedeutet und das Soft­ waremodul m1 hat sie Version v1.1. Die Versionszeile des Soft­ waremoduls m1 lautet demnach D1.m1 1 v1.1.

Das Softwaremodul m1 führt auch eine Liste von Anforderungen an andere Softwaremodule mit sich. Die Liste von Anforderungen enthält Kennzeichnungen von Geräten, auf die ein Zugriff des zu ladenden Softwaremoduls m1 vorgesehen ist, die Bezeichnungen der in den Geräten, auf die ein Zugriff vorgesehen ist, von dem zu ladenden Softwaremodul m1 benötigten Softwaremodule, sowie Versionsnummer der benötigten Softwaremodule. Im Fall des Soft­ waremoduls m1 ist ein Zugriff auf ein Gerät D2 vorgesehen, in dem von dem zu ladenden Softwaremodul m1 ein Softwaremodul m9 in der Version 1.x benötigt wird. Die Liste der Anforderungen des Softwaremoduls m1 lautet demnach D2.m9 1.x.

Die in der Liste der Anforderungen enthaltenen Softwaremodule müssen in der angegebenen Version im Fahrzeugsteuerungssystem vorhanden sein. Die neu einzuspielenden Softwaremodule m1 und m2 werden in die Konfigurationsprüfung in einem Gerät 40 einge­ checkt. Das Gerät 40 liegt innerhalb des Fahrzeugsteuerungssy­ stems, die Konfigurationsprüfung könnte aber auch von einem au­ ßerhalb liegenden Gerät durchgeführt werden. Eine Kompatibili­ tät des Softwaremoduls m1 mit dem Fahrzeugsteuerungssystem wird nun geprüft, indem in einer ersten Prüfung die Listen von An­ forderungen der bereits im Fahrzeugsteuerungssystem vorhandenen Softwaremodule geprüft werden. In der Darstellung der Fig. 2 ist zu erkennen, dass die Liste der Anforderungen des Software­ moduls m2 im Gerät D1 leer ist, das Modul m2 also keine Anfor­ derungen z. B. an das Softwaremodul m1 stellt. Das Softwaremodul m1 wird vom Gerät D1 auch nicht für eine externe Verwendung zur Verfügung gestellt, was durch den Buchstaben l in der Versions­ zeile des Moduls m1 angedeutet ist. Damit haben weitere Softwa­ remodule auf anderen Geräten, im dargestellten Fall also das Modul m9 auf Gerät D2, keine Anforderungen an das Softwaremodul m1.

In einer zweiten Prüfung werden dann die Anforderungen des zu ladenden Softwaremoduls m1 und m2 an die im Fahrzeugsteuerungs­ system vorhandenen Softwaremodule geprüft. Hierzu wird die Li­ ste der Anforderungen des Softwaremoduls m1 bzw. m2 herangezo­ gen. Im Beispiel der Fig. 2 benötigt das Softwaremodul m1 ge­ mäß seiner Liste von Anforderungen auf dem Gerät D2 ein Softwa­ remodul m9 in einer Version 1.x, d. h. die zweite Ziffer der Versionsnummer ist beliebig. Im Rahmen der Konfigurationsmana­ geraufgabe vergleicht das Gerät 40 die Liste der Anforderungen des Softwaremoduls m1 mit der Versionszeile des im Gerät D2 vorhandenen Softwaremoduls x1. Die Versionszeile des Software­ moduls x1 lautet D2 m9e v1.4. In der Versionszeile ist die Be­ zeichnung des Softwaremoduls m9 sowie der Buchstabe e enthal­ ten, der für eine externe Verwendung des Softwaremoduls m9 im Gerät D2 steht. Das Softwaremodul m9 liegt im Gerät D2 in der Version v1.4 vor. Ein Vergleich der Liste der Anforderungen D2.m9 1.x des Softwaremoduls m1 mit der Versionszeile m9e v1.4 des Softwaremoduls m9 ergibt, dass die Anforderungen des Soft­ waremoduls m1 durch das Softwaremodul m9 erfüllt werden. An­ schließend wird analog dazu m2 geprüft, auch hier werden alle Anforderungen erfüllt. Infolgedessen kann das Gerät 40 zum Ab­ schluss der Konfigurationsprüfung eine Meldung "OK" ausgeben, dass das neue Softwaremodul m1 in das Gerät D1 eingespielt wer­ den kann.

Claims (11)

1. Verfahren zum Laden von Software in ein Zielgerät eines Fahrzeugsteuerungssystems mit mehreren Geräten, gekennzeichnet durch die Schritte:
Unterteilen des Ladens eines oder mehrerer Softwaremodule (m1, m2) in Teilaufgaben, nämlich wenigstens eine Kontrollgerätauf­ gabe, eine Updategerätaufgabe und eine Empfangsgerätaufgabe, und
Zuweisen einer Durchführung der Teilaufgaben an das Zielgerä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 (m1) von außer­ halb des Fahrzeugsteuerungssystems enthält,
die Updategerätaufgabe eine Steuerung des Ladens des Software­ moduls (m1) 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 Schnittstel­ le für das von außerhalb des Fahrzeugsteuerungssystems zu la­ dende Softwaremodul (m1) enthält.

2. Verfahren zum Laden von Software nach Anspruch 1, gekennzeichnet durch weiteres Unterteilen des Ladens des Softwaremoduls (m1) in eine Konfigurationsmanageraufgabe, die eine Überprüfung enthält, ob das Fahrzeugsteuerungssystem die Anforderungen des zu ladenden Softwaremoduls (m1) bezüglich Hardware und Software erfüllt und ob das zu ladende Softwaremodul (m1) die Anforderungen für den Betrieb des Fahrzeugsteuerungssystems erfüllt.

3. Verfahren zum Laden von Software nach Anspruch 2, dadurch gekennzeichnet, dass die zu ladenden Softwaremodule (m1, m2) mit jeweils einer Ver­ sionszeile und einer Liste von Anforderungen versehen ist, wo­ bei die Versionszeile eine Bezeichnung des zu ladenden Softwa­ remoduls (m1, m2), eine Kennzeichnung des Zielgeräts (D1), eine Kennzeichnung (l, e) für interne oder externe Verwendung des zu ladenden Softwaremoduls (m1) im Zielgerät (D1) sowie eine Ver­ sionsnummer (v1.1) des zu ladenden Softwaremoduls (m1) aufweist und die Liste der Anforderungen Kennzeichnungen von Geräten (D2), auf die ein Zugriff des zu ladenden Softwaremoduls (m1) vorgesehen ist, die Bezeichnungen der in den Geräten (D2), auf die ein Zugriff vorgesehen ist, von dem zu ladenden Softwaremo­ dul (m1) benötigten Softwaremodule (m9) und Versionsnummern (1.x) der benötigten Softwaremodule (m9) aufweist, und die Kon­ figurationsmanageraufgabe eine erste Prüfung, bei der die An­ forderungen von im Zielgerät (D1) und in den Geräten (D2) vor­ handenen Softwaremodulen (m2, m9) an das zu ladende Softwaremo­ dul (m1) unter Verwendung der Versionszeile des zu ladenden Softwaremoduls (m1) und Listen von Anforderungen der vorhande­ nen Softwaremodule (m2, m9) geprüft werden, und eine zweite Prüfung, bei der die Anforderungen des zu ladenden Softwaremo­ duls (m1) an die im Zielgerät (D1) und in den Geräten (D2) vor­ handenen Softwaremodule unter Verwendung der Liste der Anforde­ rungen des zu ladenden Softwaremoduls (m1) und von Versionszei­ len der vorhandenen Softwaremodule (m2, m9) geprüft werden, um­ fasst.

4. Verfahren zum Laden von Software nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die Konfigurationsmanageraufgabe von einem Gerät (20; 40) des Fahrzeugsteuerungssystems durchgeführt wird.

5. Verfahren zum Laden von Software nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die Konfigurationsmanageraufgabe von dem Leitgerät außerhalb des Fahrzeugs durchgeführt wird.

6. Verfahren zum Laden von Software nach einem der vorstehenden Ansprüche, gekennzeichnet durch weiteres Unterteilen des Ladens des Softwaremoduls in eine Backupgerätaufgabe, die ein Sichern wenigstens eines Teils von im Zielgerät (10; D1) vorhandenen Softwaremodulen innerhalb des Fahrzeugsteuerungssystems enthält.

7. Verfahren zum Laden von Software nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Zuweisen der Durchführung der Teilaufgaben in Abhängigkeit der für die Teilaufgaben erforderlichen Rechenleistung, des für die Teilaufgaben erforderlichen Speicherplatzes und/oder der im Zielgerät (10; D1) und in den Geräten (20; 40, D2) für die Speicherung von Daten erforderlichen Zeit erfolgt.

8. Verfahren zum Laden von Software nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine Absicherung einer Datenübertragung durch kryptographische Verschlüsselung nur außerhalb des Fahrzeugsteuerungssystems er­ folgt.

9. Fahrzeugsteuerungssystem zur Durchführung eines Verfahrens nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass
zur Durchführung einer Konfigurationsmanageraufgabe, die eine Überprüfung enthält, ob das Fahrzeugsteuerungssystem die Anfor­ derungen des zu ladenden Softwaremoduls (m1) bezüglich Hardware und Software erfüllt und ob das zu ladende Softwaremodul (m1) die Anforderungen für den Betrieb des Fahrzeugsteuerungssystems erfüllt, in einem jeweiligen Gerät (D1, D2) des Fahrzeugsteue­ rungssystems vorhandene Softwaremodule (m1, m2, m9) jeweils ei­ ne Versionszeile und eine Liste von Anforderungen enthalten, wobei
die Versionszeile eine Bezeichnung des vorhandenen Softwaremo­ duls (m1, m9) eine Kennzeichnung (l, e) für interne oder exter­ ne Verwendung des vorhandenen Softwaremoduls (m1, m9) im jewei­ ligen Gerät (D1, D2) sowie eine Versionsnummer (v1.0, v1.4) des vorhandenen Softwaremoduls (m1, m9) aufweist 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 benötigten Software­ module aufweist.

10. Fahrzeugsteuerungssystem nach Anspruch 9, dadurch gekennzeichnet, dass das Fahrzeugsteuerungssystem mit einem Leitgerät außerhalb des Fahrzeugsteuerungssystems zur Durchführung der Konfigurations­ manageraufgabe betreibbar ist.

11. Fahrzeugsteuerungssystem nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass im Fahrzeugsteuerungssystem ein zur Durchführung der Konfigura­ tionsmanageraufgabe geeignetes Gerät (20; 40) vorgesehen ist.