Bekannt ist die Sicherung von Personalisierungsdaten durch ein externes Diagno- segerät in der Werkstatt, das die Daten aus dem Steuergerät eines Fahrzeugs aus- liest und diese Daten in ein neu eingebautes Steuergerät oder in das mit aktualisier- ter Software versehene Steuergerät einbringt. Eine Konvertierung der Daten findet nicht statt.

Ein Transfer bzw. eine Portierung von Daten in verschiedene Fahrzeuge ist weder möglich noch vorgesehen."Unterschiedlich"sind zwei Steuergeräte dann, wenn sie nicht die gleiche Menge an Personalisierungsdaten (d. h. unterschiedlich viele Ein- stellmöglichkeiten) aufweisen oder die Steuergeräte gleiche Daten unterschiedlich interpretieren. In der Regel sind Steuergeräte mit unterschiedlichen Teilenummern beispielsweise als unterschiedlich zu betrachten. Vertraulichkeit der Daten oder Si- cherheits-Maßnahmen gegen einen missbräuchlichen Datenaustausch ist bzw. sind ebenfalls nicht vorgesehen. Die heutige Sicherheit basiert darauf, dass der Zugriff auf Fahrzeug und Diagnosegerät nicht für beliebige Personen möglich ist.

Die Portierung von Daten zwischen Fahrzeugen unterschiedlicher Serien ist eben- falls beim bekannten Stand der Technik weder vorgesehen noch möglich.

Die Aufgabe der Erfindung besteht insbesondere in der Angabe eines Verfahrens, bei dem die dem Fahrer aus einem ersten Fahrzeug bekannten Fahrzeug- Einstellungen möglichst originalgetreu in ein zweites Fahrzeug übertragen werden.

Diese Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst. Vor- teilhafte Ausgestaltungen sind Gegenstand der abhängigen Patentansprüche.

Gemäß eines ersten wichtigen Aspekts der Erfindung werden die die personenbe- zogene erste Einstellung angebenden ersten Personalisierungsdaten in einem ers- ten Schritt aus dem ersten Fahrzeug in modifizierter oder ursprünglicher Form ex- portiert. In einem zweiten Schritt werden die Daten in ein zweites Fahrzeug impor- tiert und auf der Basis der importierten Daten werden zweite Personalisierungsdaten gebildet eine personenbezogene Einstellung im zweiten Fahrzeug vorgenommen wird.

Hieran ist von Vorteil, dass der Typ und/oder die Ausstattung des ersten und des zweiten Fahrzeugs identisch oder aber auch unterschiedlich sein kann.

Der Begriff Personalisierungsdaten umfasst die Daten für Einstellungen im Fahr- zeug, die von oder für eine Person, die dieses Fahrzeug nutzt, gemacht werden können. Beispiele sind Sitzeinstellung, Radiolautstärke, Navigationsziellisten und Einstellungen von Alarmanlage und Entriegelung sowie heutige CKM (Car-Key- Memory) Daten. Personalisierungsdaten können darüber hinaus auch Regeln sein, die zum Setzen von Einstellungen oder zur Beeinflussung von Fahrzeugfunktionen verwendet werden ("aktive Daten"). Beispiel ist eine Regel die maschinell auswert- bar formalisiert, dass das Fahrzeug das Abblendlicht einschaltet, sobald die Ge- schwindigkeit 100km/h übersteigt. Ferner können Personalisierungsdaten auch im Fahrzeug ausführbare Programme sein, z. B. in Form von maschinenunabhängigem Java-Bytecode. Auch personenbezogene, in Software realisierte Dienste, wie eine automatische Sitzeinstellfunktion, fallen hierunter.

Nach einer vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die ers- ten Personalisierungsdaten in ein fahrzeugunabhängiges Datenformat konvertiert werden und im zweiten Fahrzeug unter Verwendung der Daten im fahrzeugunab- hängigen Datenformat die personenbezogenen Einstellungen vorgenommen wer- den.

Bei einer weiteren vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die ersten Personalisierungsdaten aus dem ersten Fahrzeug in einer Form expor- tiert werden, die den Typ des ersten Fahrzeugs erkennen lässt und im zweiten Fahrzeug unter Verwendung dieser Daten die personenbezogenen Einstellungen vorgenommen werden.

Jede der beiden Alternativen ermöglicht in vorteilhafter, flexibler Weise die Anpas- sung der die Einstellung im Quellfahrzeug bzw. im ersten Fahrzeug angebenden Daten in Daten, die im Zielfahrzeug eine Einstellung hervorrufen, die weitgehend originalgetreu ist bzw. beim Wechsel des Fahrzeugs einer Einstellung entspricht, die der Fahrer oder die Mitfahrer typischerweise erwarten.

Alternativ oder ergänzend ist bei einer anderen vorteilhaften Ausgestaltung der Er- findung ist vorgesehen, dass die in ursprünglicher oder modifizierter Form aus dem ersten Fahrzeug exportierten Personalisierungsdaten und/oder die in ein fahr- zeug unabhängiges Datenformat konvertierten ersten Personalisierungsdaten und/oder die ersten Personalisierungsdaten, die eine Form aufweisen, dass sie den Typ des ersten Fahrzeugs erkennen lassen, verschlüsselt und/oder signiert werden, wobei vorzugsweise eine Verschlüsselung und Signatur mit einem Public-Key- Verfahren durchgeführt wird.

Durch diese Maßnahmen kann sowohl die Vertraulichkeit der Personalisierungsda- ten als auch deren Unverfälschtheit sichergestellt werden. Vertrauliche Personalisie- rungsdaten können bspw. Namen, Telefonnummern und Adressen einer Telefon- oder Adress-Anwendung bzw. -Software sein.

Alternativ oder ergänzend ist bei einer bevorzugten Ausgestaltung der Erfindung vorgesehen, dass die ersten Personalisierungsdaten von mindestens einem ersten Steuergerät des ersten Fahrzeugs und/oder von einer im ersten Fahrzeug vorgese- henen ersten zentralen Datenbank vor deren Export abgerufen und die zweiten Per- sonalisierungsdaten, die auf der Basis der ersten Personalisierungsdaten gebildet worden sind, mindestens einem zweiten Steuergerät des zweiten Fahrzeugs

und/oder einer im zweiten Fahrzeug vorgesehenen zweiten zentralen Datenbank zugeführt werden bzw. wird.

Eine weitere vorteilhafte Ausgestaltung der Erfindung zeichnet sich dadurch aus, dass die zweiten Personalisierungsdaten aus den ersten Personalisierungsdaten unter Verwendung einer Tabelle, einer Matrix oder einer anderen Zuordnungsvor- schrift gebildet werden, insbesondere eine Tabelle, die die ggf. unterschiedlichen Fahrzeugtypen berücksichtigt.

Bei einer anderen Ausgestaltung der Erfindung ist vorgesehen, dass die ersten Per- sonalisierungsdaten mit weiteren Personalisierungsdaten zu einer Gruppe zusam- mengefasst und gemeinsam verschlüsselt und/oder signiert werden.

Nachfolgend wird im Detail der erfindungsgemäße Export-und der Import- Algorithmus, das Konvertierungs-und das Datenschutzverfahren, die Portierung, die Datensicherheit, der Datentransfer und die Vorteile der Erfindung anhand von Aus- führungsbeispielen näher beschrieben.

Zusammenfassend wird erfindungsgemäß ein Verfahren vorgeschlagen, das bevor- zugt Personalisierungsdaten im Fahrzeug abruft, von einem intern im Fahrzeug be- nutzten fahrzeugabhängigen Datenformat in ein portierbares, fahrzeugunabhängi- ges Format umwandelt und entsprechend der Sicherheitsrelevanz der Daten ihren Schutz sicherstellt. Ebenso kann das Verfahren Daten in diesem geschützten Ex- ternformat wieder in das fahrzeugabhängige, interne Format eines anderen Fahr- zeugs umwandeln und diesem Fahrzeug zur Verfügung stellen. Die Umwandlung erfolgt bevorzugt dabei so, dass die Daten dabei in einer Art auf das Zielfahrzeug angepasst werden, die der Einstellung im Quellfahrzeug möglichst originalgetreu entsprechen.

Der Exportalgorithmus weist die folgenden Schritte auf :

1. Abruf der Daten von den Steuergeräten oder von einer zentralen Datenbank im Fahrzeug 2. Konvertierung auf ein Externformat oder durch eine Tabelle im Zielfahrzeug und Kennzeichnung bzw. Attributierung der Daten mit einer Information zur weiteren Behandlung beim Import 3. ggf. Verschlüsselung und Signatur der Daten, abhängig vom Übertragungs- weg und von den Schutzanforderungen der betreffenden Daten ; vor der Ver- schlüsselung kann auch eine Gruppierung der Daten, z. B. nach dem Grad der Sicherheitsanforderungen erfolgen 4. Schreiben auf einen Datenträger bzw. Übergabe auf den Übertragungsweg Der Importalgorithmus hat die folgenden Schritte : 1. Lesen vom Datenträger (im Fall einer direkten Online-Verbindung zwischen Quell-und Zielfahrzeug als"Medium", fällt das Schreiben beim Zielfahrzeug und Lesen beim Quellfahrzeug zusammen) 2. ggf. Authentisierung, Entschlüsselung und Signaturprüfung 3. Konvertierung auf ein Internformat oder Konvertierung durch Tabelle 4. Übermittlung der Daten an die Steuergeräte bzw. auf eine zentrale Daten- bank im Fahrzeug, die die Einstellungen an die Steuergeräte propagiert (Ggf. werden einige Daten von der Datenbank nicht weiter an Steuergeräte propa- giert. Das trifft zu, wenn kein entsprechendes Steuergerät vorhanden ist, die Daten aber für zukünftigen Export erhalten bleiben sollen. Näheres siehe un- ten.) Im Folgenden wird ein bevorzugtes Konvertierungs-und Datenschutzverfahren der vorgenannten Schritte 2 und 3 durch Pseudo-Code näher beschrieben :

Ausgangpunkt ist eine Liste infernal-list der im Fahrzeug gespeicherten Personali- sierungsdaten, eine Funktion internal, die zu jedem Listenelement den zugehörigen Wert value, zugehörige Import-und Export-Konvertierungsfünktionen exp-konv (im Quellfahrzeug) und imp-konv (im Zielfahrzeug), Funktionen zur Sicherstellung der Datensicherheit beim Import-und Export exp-secure (im Quellfahrzeug) und imp- secure (im Zielfahrzeug) angibt. Die Funktionen zur Sicherstellung der Datensicher- heit erfordern-abhängig vom Algorithmus-weitere Parameter, wie Schlüssel und Passwörter, die im folgenden Code nicht wiedergegeben sind.

Der Daten-Export in Pseudo-Code : li=internal-list ; external-list= empty-list ; while not (li = empty list) do { in=internal (li. head) ; if not (in. exp-secure==nil or in. exp-konv==nil) then ext-element=in. exp-secure (in. exp-konv (in. value)) ; else throw missing-export-routine-exception ; li=li. tail ; external-list = append (extemal-list, ext-element) } head, tail, empty-list und append bezeichnen dabei die üblichen Listenoperationen : erstes Element der Liste, Liste ohne erstes Element, leere Liste und Anhängen ei- nes Elements an eine Liste.

Die Liste external-list wird durch den Algorithmus definiert und enthält alle ggf. durch Datenschutzmechanismen gesicherten und im Exportformat codierten Personalisie- rungsdaten. Sie kann in beliebiger (aber zwischen allen Fahrzeugen einheitlicher) Codierung (XML, TLV, ...) auf den Datenträger geschrieben werden.

Daten, für die keine spezifischen Konvertierungsfunktionen bereitstehen, werden unverändert exportiert. Näheres wird nachfolgend noch beschrieben.

Der Daten-Import im Pseudo-Code : li=external-list ; internal-list = empty-list ; while not (li = empty-list) do { in=internal (li. head) ; if not (in. imp-secure==nil or in. imp-konv==nil) then int-element=in. imp-konv (in. imp-secure (li. head)) ; else throw missing-import-routine-exception ; li=li. tail ; internal-list = append (internal-list, int-element) } Die Liste internal-list wird durch den Algorithmus um die Daten im Internformat des Zielfahrzeugs ergänzt (vgl. in. value im Export-Algorithmus).

Die tatsächlich angewendeten Datenschutzverfahren und Konvertierungen können von den konkreten Daten abhängen und die Verfahren damit selbstverständlich auch von den dargestellten Ausführungsbeispielen abweichen.

Alternativ können einzelne auf das Zielfahrzeug zu übertragene Einstellungen zu Gruppen zusammengefasst werden. Im Code kann das dadurch erreicht werden, dass die while-Schleife in zwei getrennte Schleifen, eine zur Konvertierung und eine für Sicherheitsfunktionen, aufgebrochen wird. Zwischen beiden Schleifen kann dann eine Umsortierung der Liste mit einer Zusammenfassung von Elementen erfolgen (z. B. nach Sicherheitsanforderungen). Funktion internal muss dann ebenfalls in zwei Funktionen aufgebrochen werden, eine, die die Konvertierungsfunktion für Listen- elemente angibt und eine, die Sicherheitsfunktionen für Listenelemente angibt.

Diese Alternative ermöglicht es, die Datensicherheitsmechanismen nicht spezifisch für jedes Datum zu machen, sondern einheitliche Mechanismen für Gruppen von Daten vorzusehen. Der Übersichtlichkeit halber wurde diese Möglichkeit im Code nicht dargestellt.

Durch die Nutzung von Listen ist eine Erweiterbarkeit um neue Personalisierungsda- ten gegeben. Listenelemente können auch hierarchisch aufgebaut sein.

Nochfolgend eine Anmerkung zum besseren Verständnis. Für eine einfacher ver- ständliche, aber schlecht erweiterbare Implementierung mit Arrays anstelle von Funktion internal und einer festen Zahl von durchnumerieren Elementen anstelle von Listen, würde eine Implementierung folgendermaßen aussehen : für den Daten-Export : for i=0 to n do external-array[i]=exp-secure[i](exp-konv[i](internal-array[i ])) ; für den Daten-Import : for i=0 to n do internal-arrayij=imp-konv (iJ (imp-secure [ij (external-array [i])) ; Im Folgenden wird die Portierung durch Ausführungsbeispiele näher beschrieben und zwar zunächst im Rahmen einer ersten Alternative in Form eines kontextunab- hängigen Austauschformats und dann im Rahmen einer zweiten Alternative in Form eines Austauschformats mit Kontextinformation.

Alternative 1 : kontextunabhängiges Austauschformat

Eine Möglichkeit zur Übertragung der Personalisierungsdaten besteht in der Konver- tierung der Einstell-Werte aus dem fahrzeug-oder steuergeräte-spezifischen Format des Quell-bzw. Export-Fahrzeugs in ein fahrzeugunabhängiges Format, mit an- schließender weiterer Konvertierung vom fahrzeugunabhängigen Format in das fahrzeugabhängige Format des Ziel-bzw. Import-Fahrzeugs beim Import. Im Rah- men dieses Ausführungsbeispiels wird vorgeschlagen, folgendermaßen vorzuge- hen.

Portierungsalgorithmus beim Export (Funktion exp-konv) : Folgende Fälle sind zu unterscheiden : 1. Reelwertiges Datum ist nicht im SI-Format : Falls der Einstellwert einen Wertebereich hat, der eine Teilmenge der reellen Zahlen ist und nicht in einer Einheit gemessen wird, die in ein SI-Format (internationales Standardformat) gemappt bzw. umgerechnet werden kann, muss der Wert in ein passendes Austauschformat umgerechnet werden, das für jedes Personalisierungs- datum spezifisch festzulegen ist.

Eine Möglichkeit hierfür ist die Umrechnung in eine allgemeingültige (= für alle Fahr- zeuge gültige) Exporteinheit. Beispiel :"Umdrehungen Stellmotor Sitz"umgerechnet in"Abstand Sitz zum Lenkrad".

Eine weitere Möglichkeit der Umrechnung in ein Austauschformat ist, aus dem ab- soluten Einstellwert abs einen Relativwert re/zu bilden : re/= (abs*100)/ (y-x), wobei das Intervall [x... y] den Wertebereich des Einstellwerts darstellt. Diese Möglichkeit ist anwendbar, wenn die Wertebereiche des Quell-und des Zielfahrzeugs den glei- chen Abstandsbegriff haben, z. B. dann wenn beide linear oder beide logarithmisch sind. Diese Konvertierung unterstützt die Transformation zwischen Wertebereichen mit unterschiedlicher diskreter Rasterung. Die Information über den Abstandsbegriff des Quellfahrzeugs, z. B. logarithmisch oder linear ist hier mit zu exportieren, ebenso die Information über die Ausdehnung des Wertebereichs. Diese Informationen sind beim Import entsprechend auszuwerten.

Der Wert wird dann jeweils sowohl im Originalformat als auch im Austauschformat dem Portierungsprofil hinzugefügt.

2. Reelwertiges Datum ist im SI-Format : Falls der Einstellwert einen Wertebereich hat, der eine Teilmenge der reellen Zahlen ist, und in einer Einheit ist, die in ein SI-Format gemappt werden kann, wird der Ein- stellwert in das SI-Format umgerechnet, bevor der Einstellwert oder die Einstellwer- te exportiert werden. In diesem Fall stellt also das SI-Format das Austauschformat dar.

Anzumerken zu 1. und 2. ist, dass es auch Einstellwerte geben kann, deren Werte- bereich aus n-Tupeln besteht, deren Komponenten reelle Zahlen sind. Es sei n eine natürliche Zahl. Dann hat ein n-Tupel n sogenannte Komponenten. Jede Kompo- nente ist ein bestimmter Wert. Beispielsweise hat ein 3-Tupel 3 Komponenten : die Komponente 0, die Komponente 1 und die Komponente 2. In diesem Fall sind die durch die n-Tupel dargestellten Werte ebenfalls in ein passendes Austauschformat (z. B. ein existierendes Standardformat) umzuwandeln, bevor sie exportiert werden.

Auch hier sind die Werte sowohl im Originalformat als auch im Austauschformat dem Portierungsprofil hinzuzufügen.

Anmerkung zu 1. und 2. : Ein Einstellwert mit einem Wertebereich, der eine Teil- menge der reellen Zahlen ist (oder dessen Wertebereich aus n-Tupeln besteht, de- ren Komponenten reelle Zahlen sind), wird mit"real"bezeichnet ; das Attribut Portie- rungstyp im Datenformat ist auf real zu setzen.

3. Datum ist nicht reelwertig : Für alle anderen Einstellwerte ist der Wert unverändert zu exportieren, d. h. dem Portierungsprofil hinzuzufügen. Das Attribut portierungstyp ist auf non-real zu set- zen.

4. Personalisierungsdaten aus vorherigen Importvorgängen : Weitere Personalisierungsdaten, die im Exportfahrzeug persistent gespeichert, aber nicht benutzt worden sind (Wert save von Attribut import-persistance beim vorher- gehenden Import, siehe unten) werden unverändert, d. h. mit allen ihren unveränder- ten Attributen exportiert.

5. Weitere Personalisierungsdaten : Wie oben angesprochen, können neben Einstellwerten auch weitere personalisierte Daten portiert werden, wie a) persönliche Daten wie z. B. Adressen, Termine, Musikstücke b) persönlich zugeordnete Software (Applikationen/Dienste wie Word oder auch Steuergeräte-Software, die z. B. als Sonderausstattung vom Kunden in einer besonders hochwertigen Version gekauft wurde) c) Berechtigungen, insbesondere hinsichtlich Nutzungsumfang, Nutzungsdau- er, Nutzungshäufigkeit, und Nutzungsübertragbarkeit, eine Software zu nut- zen, die z. B. schon im Fahrzeug vorhanden sein kann und mit der Portierung freigeschaltet wird oder aber aufgrund der Berechtigung von einem Server geladen werden kann.

Diese personalisierten Daten werden unverändert dem Portierungsprofil hinzuge- fügt. Im Fall a) kann auch eine Konvertierung in ein passendes Austauschformat erfolgen, z. B. in ein existierendes Standardformat. D. h. ein Format, das von mehre- ren Applikationen, die Daten des Typs a) verarbeiten können, unterstützt wird.

6. Regeln als Personalisierungsdaten Eine dynamische Form von Personalisierungen kann durch Regeln erreicht werden.

Eine Regel kann z. B. in folgender Notation erfasst werden :

IF Bedingung = TRUE> THEN <Aktionsliste> <Bedingung> ist ein Boolescher Ausdruck, der (aggregierte) Daten und Metadaten des Fahrzeugs, der Fahrzeugumgebung oder des Fahrers umfassen kann.

<Aktionliste> ist eine Liste von beliebigen Fahrzeug-Funktionen, die ausgeführt wird, sobald die Bedingung erfüllt ist. Abhängigkeiten zwischen Regeln sind ebenfalls möglich.

Beispiele : IF (Geschwindigkeit >= 100 km/h) THEN ChangeDisplayMode () IF (Urlaubsfahrt = TRUE) THEN DisableBusinessNumbers () IF (Fahrer müde AND Temperatur im Auto > 20 Grad) THEN SetAirCondition (On, 15 Grad, Max) ; Radio (On, Loud) Die Regeln können attributiert und exportiert werden. Beim Import muss überprüft werden, ob Regeln prinzipiell im Zielfahrzeug ausgewertet werden können. Falls nein, kann ein discard oder save erfolgen. Falls Regeln interpretiert werden können, ist zu prüfen, ob die Werte in der Bedingung im Zielfahrzeug vorhanden sind und ob die Funktionen der Funktionsliste vorhanden sind und sich mit den Parametern aus- führen lassen. Falls ja, können diese Regeln im Zielfahrzeug angewendet werden.

Falls nein, sind Abhängigkeiten zu anderen Regeln zu prüfen. Hier kann ebenfalls ein discard oder save erfolgen.

Regeln stellen ein mächtiges Konzept zur dynamischen Personalisierung dar und sind vergleichsweise einfach zu exportieren und in ein Zielfahrzeug zu übertragen.

Weitere Attribute der exportierten Personalisierungsdaten : Neben dem eigentlichen Personalisierungsdatum legt die Funktion exp-konv auch den Wert für das Attribut import-persistance mit ab, das zu jedem Personalisie- rungsdatum gehört. Der Wert save dieses Attributs gibt an, dass das Datum per- sistent gespeichert werden soll (z. B. in einem Filesystem oder einer Datenbank), wenn die zugehörige Fahrzeugfunktion im Zielfahrzeug nicht vorhanden ist. Dadurch

wird es möglich, Personalisierungsdaten auch über Fahrzeuge hinweg zu übertra- gen, die nicht alle möglichen Personalisierungsdaten unterstützen. Der Wert discard für das Attribut gibt an, dass das Personalisierungsdatum im Zielfahrzeug verworfen und nicht zum Re-Export gespeichert wird, falls die zugehörige Fahrzeugfunktion nicht im Zielfahrzeug vorhanden ist.

Anmerkung : Eine sinnvolle Voreinstellung für das Attribut import-persistance ist, allen Einstellwerten discard zuzuordnen. Allein den oben unter a), b) und c) be- schriebenen Daten wird save zugeordnet.

Ein weiteres Attribut, import-compatibility, das exp-konv zu dem Personalisierungs- datum ablegt, regelt die Behandlung des Datums für den Fall, dass im Importfahr- zeug eine veränderte Version der personalisierten Einstellung vorliegt, d. h., dass z. B. der exportierte Wert außerhalb des Wertebereichs des Importfahrzeugs für das betreffende Datum liegt. Das Attribut kann folgende drei Werte annehmen : autoAn- passen (tol), Anfrage und keine Aktion (im Folgenden erklärt). autoAnpassen (tol) : Ist ein importierter Wert nicht im Wertebereich des Zielfahrzeugs enthalten, so wird im Falle eines Wertebereichs, der eine Teilmenge der reellen Zahlen ist, der nächstgelegene Wert, d. h. nächster definierter Nachbar-in dem Falle, dass es mehrere gibt, wird einer ausgewählt, gesetzt, falls dieser sich nicht weiter als toi Einheiten vom eigentlich zu setzenden Wert unterscheidet. Unter- scheidet er sich stärker, wird eine Anfrage durchgeführt.

Anfrage : Liegt ein Wert nicht im Wertebereich, so werden dem Nutzer im Falle eines Wertebereichs mit definiertem Abstandsbegriff der nächstgelegene Wert-ansons- ten sämtliche zur Auswahl stehende Werte-angezeigt. Ein Wertebereich ohne Ab- standsbegriff wäre etwa der Wertebereich für die Alarmanlageneinstellung. Werte wären hier etwa an, aus, und nachts automatisch an. keine Aktion : Es wird nichts getan.

Anmerkung : Eine sinnvolle Voreinstellung für das Attribut import-compatibility ist, allen Einstellwerten, die vom Typ non-real sind, Anfrage zuzuordnen. Einstellwerten vom Typ real wird autoanpassen (tot) zugeordnet, wo jeweils passende Werte für tol

festzulegen sind. Weiteren Personalisierungsdaten, wie oben unter a), b) und c) beschrieben, wird autoAnpassen zugeordnet (siehe auch unten).

Zusammenfassend sind damit folgende Attribute mit einem exportierten Personal- sierungsdatum verknüpft : Portierungstyp (Werte : real, non-reao, import-persistance (Werte : save, discard), import-compatibility (Werte : autoAnpassen (tol), Anfrage, keine Aktion).

Portierungsalgorithmus beim Import (Funktion imp-konv) : Falls die Fahrzeugfunktion, zu der das Personalisierungsdatum gehört, im Zielfahr- zeug nicht vorhanden ist, wird diejenige Behandlung durchgeführt, die im Attribut import-persistenz angegeben ist, d. h. persistente Speicherung oder Verwerfen.

Ist die Fahrzeugfunktion, zu der das Personalisierungsdatum gehört, im Zielfahr- zeug vorhanden, wird folgendermaßen vorgegangen : 1. Reelwertiges Datum ist nicht im SI-Format : Bei einem Einstellwert vom Typ real, der nicht in einer SI-Einheit abgelegt war, wird der Originalwert gewählt, falls es sich im Zielfahrzeug um die gleiche Version (ins- besondere auch gleicher Wertebereich) der Fahrzeugfunktion handelt. Ansonsten wird das Austauschformat in das im Zielfahrzeug gültige Format umgerechnet, be- vor der Wert gesetzt wird. Falls hierbei zu einem Wert Informationen über den Ab- standsbegriff vorliegen, ist zu prüfen, ob diese mit dem Abstandsbegriff im Zielfahr- zeug kompatibel sind. D. h. es ist zu prüfen, ob es sich um den gleichen Abstands- begriff handelt. Handelt es sich nicht um den gleichen Abstandsbegriff, werden die Werte nicht gesetzt ; es findet keine weitere Aktion statt.

2. Reelwertiges Datum ist im SI-Format : Einstelldaten vom Typ real, die in einer SI-Einheit abgelegt waren, werden in die im Zielfahrzeug geltende Einheit umgerechnet, bevor sie gesetzt werden.

3. Datum ist nicht reelwertig : Für alle anderen Einstellwerte (Portierungstyp non-real) wird der im Portierungsprofil übertragene Wert unverändert übernommen.

Kann (egal in welchem der drei obigen Fälle) der Wert nicht übernommen werden, da der portierte Wert nicht einem gültigen Wert des Wertebereichs entspricht (ande- re Version der Fahrzeugfunktion im Zielfahrzeug), so ist diejenige Ausnahmebe- handlung durchzuführen, die im Attribut import-compatibility angegeben ist (siehe oben).

Aus Gründen der Benutzbarkeit kann, falls die Zahl der Rückfragen motiviert durch Attributwert Anfrage für import-compatibility, einen bestimmten Wert übersteigt der Import dieser Werte entfallen. In diesem Fall werden nur die übrigen Werte gesetzt und es wird eine Meldung der Art ausgegeben ("Import nicht von allen Werten mög- lich, Fahrzeugkonfiguration zu unterschiedlich").

4. Weitere Personalisierungsdaten : Bei weiteren Personalisierungsdaten, d. h. solche, die keine reinen Einstellwerte sind, die portiert wurden, wie a) persönliche Daten wie z. B. Adressen, Termine, Musikstücke b) persönlich zugeordnete Software c) Berechtigungen, eine Software zu nutzen wird beim Import geprüft, ob a) eine Softwareapplikation im Fahrzeug vorhanden ist, die die Daten verarbei- ten kann (z. B. Outlook). Dies entspricht der Prüfung des Vorhandenseins ei- ner Fahrzeugfunktion im Fall der Portierung eines Einstellwerts. Im positiven Fall werden die Daten an die entsprechende Softwareapplikation weitergelei- tet. Dies entspricht dem Setzen bzw. der Übernahme eines Einstellwerts. Im negativen Fall wird geprüft, ob eine Softwareapplikation vorhanden ist, die die Daten in einem Format verarbeiten kann, das zu dem Format, in dem die Daten vorliegen, kompatibel ist. In diesem Fall wird die Behandlung durchge-

führt, die zum Attribut import-incompatibility beschrieben worden ist, wobei autoAnpassen (tol) in diesem Fall bedeutet, dass die Daten in ein von der vorhandenen Applikation unterstütztes Format konvertiert werden, bevor sie an die entsprechende Applikation weitergeleitet werden (tol ist in diesem Fall zu ignorieren).

Alternativ können die Daten auch bereits beim Export in ein Standardformat umgewandelt werden, dass von mehreren Applikationen unterstützt wird, falls ein solches existiert. Ist keinerlei Applikation vorhanden, die die Daten verarbeiten kann, oder kann eine Konvertierung nicht durchgeführt werden, z. B. weil kein passender Konverter vorhanden ist, wird die Behandlung durchgeführt, die zum Attribut import-persistenz angegeben ist. b) die importierte Software systemverträglich ist, d. h. ob sie mit der Konfigurati- on im Zielfahrzeug kompatibel ist. Beispielsweise wird geprüft, ob eine ge- eignete Hardware und/oder ein geeignetes Betriebssystem vorhanden ist.

Dies entspricht der Prüfung des Vorhandenseins einer Fahrzeugfunktion im Fall der Portierung eines Einstellwerts. Im positiven Fall wird die Software an das entsprechende Steuergerät oder dergleichen weitergeleitet und instal- liert. Dies entspricht dem Setzen bzw. dem Übernehmen eines Einstellwerts.

Ist die importierte Software mit der Konfiguration im Zielfahrzeug nicht direkt kompatibel, weil z. B. zwar das Steuergerät vorhanden ist, jedoch die Soft- ware nicht für den Controller oder das Betriebssystem des Steuergeräts an- gepasst ist, so wird die Behandlung durchgeführt, die zum Attribut import- incompatibility angegeben ist. autoAnpassen (tol) bedeutet in diesem Fall, dass eine passende Version der Software, passend z. B. für die vorhandene Hardware und/oder das vorhandene Betriebssystem geladen wird, z. B. von einem Server ; tol ist in diesem Fall zu ignorieren. Diese Version wird dann an das entsprechende Steuergerät weitergeleitet und installiert. Ist die Soft- ware mit der Konfiguration im Zielfahrzeug gar nicht kompatibel, weil z. B. kein passendes Steuergerät im Zielfahrzeug vorhanden ist oder kann keine passende Softwareversion geladen werden, so ist die Behandlung durchzu- führen, die zum Attribut import-persistenz angegeben ist.

c) eine Softwareapplikation im Fahrzeug vorhanden ist, die die Berechtigungen verarbeiten kann, z. B. ein sogenannter Fahrzeug-Securitymanager. Dies entspricht der Prüfung des Vorhandenseins einer Fahrzeugfunktion im Fall der Portierung eines Einstellwerts. Im positiven Fall werden die Daten an die entsprechende Softwareapplikation weitergeleitet. Dies entspricht dem Set- zen bzw. dem Übernehmen eines Einstellwerts. Ist keinerlei Applikation vor- handen, die die Daten verarbeiten kann, wird die Behandlung durchgeführt, die zum Attribut import-persistenz angegeben ist. Ist eine Applikation vor- handen, die ein Berechtigungsformat verarbeiten kann, in die das importierte Berechtigungsformat umgewandelt werden kann, so wird analog wie bei der Behandlung der Import-Inkompatibilität im Fall a) vorgegangen.

5. Regeln als Personalisierungsdaten : Eine dynamische Form von Personalisierungen kann durch Regeln erreicht werden.

Eine Regel kann z. B. in folgender Notation erfasst werden : IF <Bedingung = TRUE> THEN <Aktionsliste> <Bedingung> ist ein Boolescher Ausdruck, der (aggregierte) Daten und Metadaten des Fahrzeugs, der Fahrzeugumgebung oder des Fahrers umfassen kann.

<Aktionliste> ist eine Liste von beliebigen Fahrzeug-Funktionen, die ausgeführt wird, sobald die Bedingung erfüllt ist. Abhängigkeiten zwischen Regeln sind ebenfalls möglich.

Beispiele : IF (Geschwindigkeit >= 100 km/h) THEN ChangeDisplayMode () IF (Urlaubsfahrt = TRUE) THEN DisableBusinessNumbers () IF (Fahrer müde AND Temperatur im Auto > 20 Grad) THEN SetAirCondition (On, 15 Grad, Max) ; Radio (On, Loud)

Die Regeln können attributiert und exportiert werden, wie die oben unter Punkt a) angesprochenen weiteren Personalisierungsdaten. Beim Import muss überprüft werden, ob Regeln prinzipiell im Zielfahrzeug ausgewertet werden können. Falls nein, kann ein discard oder save erfolgen. Falls Regeln interpretiert werden können, ist zu prüfen, ob die Werte in der Bedingung im Zielfahrzeug vorhanden sind und ob die Funktionen der Funktionsliste vorhanden sind und sich mit den Parametern aus- führen lassen. Falls ja, können diese Regeln im Zielfahrzeug angewendet werden.

Falls nein, sind Abhängigkeiten zu anderen Regeln zu prüfen. Hier kann ebenfalls ein discard oder save erfolgen.

Regeln stellen ein mächtiges Konzept zur dynamischen Personalisierung dar und sind vergleichsweise einfach zu exportieren und in ein Zielfahrzeug zu übertragen.

Das Problem des Import-Mismatch stellt sich ähnlich wie bei den Einstellwerten und kann wie beim Import beschrieben behandelt werden.

Alternative 2 zu Alternative 1 (kontextunabhängiges Austauschformat) : Austausch- format mit Kontextinformation Alternativ zur obigen kontextneutralen Abbildung von Einstellwerten besteht auch die Möglichkeit, eine Abbildungstabelle über Funktionen und Kontext (Fahrzeugtyp bzw. Steuergerät, etc. ) zu nutzen, die die Einstellwerte enthält. Z. B. kann eine ver- gleichbare Sitzposition über Fahrzeugtypen hinweg definiert werden oder eine ver- gleichbare Lautstärke über verschiedene Audioanlagen hinweg. Abhängig vom Wer- tetyp des Einstellwertes, können mehrere Vergleichswerte (z. B. Sitzpositionen, Lautstärken, etc. ) in der Tabelle hinterlegt sein, um eine Interpolation zu ermögli- chen. Diese Abbildungstabelle enthält die Obermenge aller Funktionen, die in einem beliebig ausgestatteten Fahrzeug personalisiert werden können und ist mit der da- zugehörigen Kontextinformation versehen. Diese Abbildungstabelle wird ggf. um neue Funktionen oder neuen Kontext erweitert und durch den Automobilhersteller gepflegt.

Die Abbildungstabelle wird folgendermaßen für den Export und Import genutzt : In Bezug auf die exp-konv Funktion werden neben den Einstellwerten die relevanten

Kontextinformationen mit exportiert. Danach kann entweder extern ein"Table- Lookup"in der Abbildungstabelle erfolgen, falls die Kontextinformation des Zielfahr- zeugs vorliegt, um die Einstellwerte im Zielfahrzeug zu beschreiben, oder dies er- folgt im Zielfahrzeug selber. Dazu muss eine aktuelle Abbildungstabelle beim Vor- gang imp-konv mit ins Fahrzeug übergeben werden. Im einfachsten Fall hat eine Funktion den gleichen Kontext und der Einstellwert kann direkt übernommen wer- den. Ansonsten (import-mismatch) ist der neue Einstellwert durch Table-Lookup zu identifizieren bzw. zu interpolieren. Alle anderen Aspekte des Exports und Imports können wie bereits beschrieben genutzt werden (Anfrage, discard, etc.).

Insbesondere betrifft das die Vorgehensweise, falls eine (automatische) Abbildung nicht möglich ist, weil z. B. eine neue personalisierbare Funktion im Zielfahrzeug vorhanden ist oder weil z. B. eine im Quellfahrzeug vorhandene personalisierbare Funktion im Zielfahrzeug fehlt.

Die Alternative 2 kann auch ergänzend zur Alternative 1 vorgesehen werden, d. h. beide Alternativen können zusammen als eine Variante der automatischen Anpas- sung für einzelne Personalisierungsdaten umgesetzt werden.

Sicherheitsanforderungen beim Austausch von Personalisierungsdaten : Die Sicherheitsanforderungen beim Austausch von Personalisierungsdaten umfas- sen erstens, dass die Vertraulichkeit dieser Daten gewährleistet ist, zweitens, dass sie nicht von Unberechtigten manipuliert werden können, und drittens die Überprü- fung der Berechtigung des Fahrzeugnutzers (Authentisierung).

Zur Definition der oben eingeführten Funktionen ex-secure und imp-secure, die die Sicherheitsanforderungen beim Export/Import umsetzen, werden folgende Unter- funktionen benutzt. Funktionen enc (key, data) und dec (key, data) ver-/entschlüsseln Daten data mit dem angegebenen Schlüssel key. Die Funktion auth-check prüft die Authentisierung. Sie kann z. B. in einer PIN-Eingabe (PIN = Personal Identification Number) bestehen. Eine Funktion sig-make (key, data) signiert data mit key und lie-

fert die Daten mit Signatur zurück. Eine Funktion sig-check (key, data) überprüft die Signatur von data mit key und gibt die Daten ohne Signatur zurück. Scheitert die Signaturprüfung, so wird eine Exception ausgegeben.

Der folgende Pseudo-Code definiert die Funktion exp-secure (x) : if auth-check=true then exp-secure= enc (enc-key, sig-make (sig-make-key, x)) else throw authentication-failed-exception ; Der folgende Pseudo-Code definiert die Funktion imp-secure (y) : if auth-check=true then imp-secure= sig-check (sig-check-key, dec (dec-key, y)) else throw authentication-failed-exception ; Durch die Kombination mit dem o. g. allgemeinen Export-/Import-Algorithmus ist die Authentisierung spezifisch für jedes Personalisierungsdatum. Alternativ kann die Authentisierung auch vor den Beginn des Export-/Imports gezogen werden, so dass nur ein Authentisierungsvorgang nötig ist. Darüber hinaus können, wie oben ange- sprochen, Personalisierungsdaten gruppiert werden, so dass ebenfalls eine "grobgranularere"bzw. zusammengefasste Authentisierung erreicht wird (analog zur bereits oben angesprochenen Verschlüsselung von Gruppen von Personalisie- rungsdaten).

Zur konkreten Realisierung existiert eine Vielzahl von Alternativen. Im Folgenden werden zwei konkrete Beispiele beschrieben.

Beispiel 1 : Asymmetrisches Verfahren und Public-Key-Infrastruktur :

Als Verfahren kann hier z. B. RSA eingesetzt werden. In diesem Fall erfolgt die Sig- natur mit dem"Private-Key"der exportierenden Entität (Fahrzeug oder Benutzer), die Verschlüsselung erfolgt mit dem"Public-Key"der Ziel-Entität (anderes Fahrzeug oder Benutzer).

Die Entschlüsselung erfolgt bei der Ziel-Entität mit dem"Private-Key"der Entität. Die Signaturprüfung erfolgt mit dem öffentlichen Schlüssel der Quell-Entität.

Der Schlüsselaustausch zwischen Quell-und Ziel-Entität erfolgt über eine Public- Key-Infrastruktur. Diese muss sowohl für die Quell-als auch für die Ziel-Entität über eine online Verbindung erreichbar sein.

Beispiel 2 : Globale Schlüssel Als Verfahren werden hier ein symmetrisches Verfahren zur Ver-und Entschlüsse- lung, z. B. DES, sowie ein asymmetrisches Verfahren für digitale Signaturen, z. B.

RSA, eingesetzt. Quell-und Ziel-Entitäten sind Fahrzeuge. Alle Fahrzeuge besitzen den gleichen symmetrischen Schlüssel sym-key für das symmetrische Verfahren und das gleiche Paar pub-key, priv-key für das asymmetrische Verfahren.

Beim Export wird das Personalisierungsdatum mit priv-key signiert (RSA) und mit sym-key verschlüsselt (DES). Beim Import wird das entsprechende Datum mit sym- key entschlüsselt (DES) und die Signatur wird mit pub-key überprüft (RSA).

Nachteil dieses Verfahrens ist die eingeschränkte Sicherheit durch global gleiche Schlüssel. Vorteil ist dass zum Datenaustausch keine Online-Verbindung, auch nicht beim ersten mal, wie beim Beispiel 1, nötig ist.

In beiden Beispielen kann die Authentisierung durch Eingabe einer PIN durch den Benutzer stattfinden.

Zur Speicherung von Schlüsseln, wie insbesondere im zweiten Beispiel, kann eine Smart Card eingesetzt werden. In diesem Fall erfolgt die Authentisierung gegenüber der Karte, z. B. durch PIN-Eingabe, und sämtliche Krypto-Algorithmen werden auf der Karte ausgeführt, so dass die Schlüssel die Karte nicht verlassen.

Im Folgenden werden Möglichkeiten zum Austausch der Personalisierungsdaten zwischen Fahrzeugen anhand von Fig. 1 näher beschrieben.

Im Fahrzeug 100 befinden sich personalisierte bzw. personalisierbare Funktionen 1, 2,3 usw., deren Personalisierungsdaten mit einem anderen Fahrzeug auszutau- schen sind. Bei den personalisierten Funktionen handelt es sich insbesondere um Komfortfunktionen, Audiofunktionen, Informationsfunktionen, Dienstefunktionen oder um geeignete Kombinationen dieser Funktionen.

Die personalisierten Funktionen bzw. deren Personalisierungsdaten werden über ein im Fahrzeug vorgesehenes Bussystem 4 von einer Koordinations-Einrichtung 5 aufgerufen und in der beschriebenen Weise zur Übertragung in das andere Fahr- zeug portiert. Die portierten Personalisierungsdaten werden über den Daten-Bus 4 an ein Interface 6 zwischen Fahrzeug und"Außenwelt"weitergeleitet. Die portierten Personalisierungsdaten werden bei dem in Figur 1 dargestellten Ausführungsbei- spiel von dem Interface 6 in einem Datenträger bzw. einem Speichermedium 7 ge- speichert. Die in Figur 1 dargestellte Anordnung ist bei dem Zielfahrzeug ebenfalls vorgesehen (nicht dargestellt) und die dem Zielfahrzeug über den Datenträger bzw. das Speichermedium 7 zugeführten, portierten Personalisierungsdaten werden in dem Zielfahrzeug bereitgestellt.

Die personalisierten Funktionen 1,2, 3 usw. können bspw. durch eine Software- Applikation auf einer Computer-bzw. PC-Plattform und/oder durch Steuergeräte, die eine entsprechende Soft-und Hardware aufweisen, bereitgestellt werden.

Bei der Koordinations-Einrichtung 5 handelt es sich bevorzugt um eine zentral oder dezentral realisierte Software-Applikation im Fahrzeug.

Bei dem Interface 6 handelt es sich bevorzugt um eine Bluetooth-, WLAN-oder Mo- bilfunk-Schnittstelle, wie eine GSM-, UMTS-oder sonstige Schnittstelle.

Bei dem Datenträger bzw. Speichermedium 7 handelt es sich um eine Speicherkar- te, ein PDA (Personal Digital Assistant), ein Handy, eine Internet-Plattform oder be- vorzugt um einen Dienst des Fahrzeugherstellers, wie BMW Online.

Weitere Vorteile der Erfindung : Durch das vorgeschlagene Verfahren ist es möglich, dem Kunden auf Basis von vorab eingestellten Präferenzen (z. B. in einem alten Fahrzeug, zu Hause oder durch einen Dienstleister) letztlich weltweit ein personalisiertes Fahrzeug anzubieten, das seinen Komfortansprüchen und Neigungen entspricht.

Dadurch kann der Nutzer direkt ohne aufwendige Voreinstellungen sein Hauptziel, "Fahren"vornehmen. Es entfällt für ihn der zeitaufwendige Einstellprozess im (ande- ren) Fahrzeug, was von besonderem Vorteil ist, wenn er sein Fahrzeug häufig wechselt. Dies trägt heute und insbesondere zukünftig, wenn immer mehr Funktio- nen im Fahrzeug einzustellen sind, zur Erhöhung des Kundennutzens bei. Gleich- zeitig erhöht es die Sicherheit beim Fahren, da der Fahrer weniger abgelenkt ist.

Vorteilhaft ist auch, dass das o. g. Verfahren so skalierbar und flexibel angelegt ist, dass bei Funktionserweiterung einiger oder aller Fahrzeugmodelle, die zum Kreis der potentiellen Fahrzeuge für die Portierung gehören, dies sehr einfach möglich ist, da die Profilinformation nur entsprechend ergänzt wird und somit vermieden wird, dass bereits beim Export eine Konvertierung auf das Zielfahrzeugmodell stattfinden muss.