EP1346881A2 - Verfahren und Vorrichtung zum Übernehmen von Daten - Google Patents

Verfahren und Vorrichtung zum Übernehmen von Daten Download PDF

Info

Publication number
EP1346881A2
EP1346881A2 EP03003020A EP03003020A EP1346881A2 EP 1346881 A2 EP1346881 A2 EP 1346881A2 EP 03003020 A EP03003020 A EP 03003020A EP 03003020 A EP03003020 A EP 03003020A EP 1346881 A2 EP1346881 A2 EP 1346881A2
Authority
EP
European Patent Office
Prior art keywords
control unit
data transfer
program data
die
der
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03003020A
Other languages
English (en)
French (fr)
Other versions
EP1346881A3 (de
Inventor
Andreas Fritz
Bernd Oeffinger
Michael Sorg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Daimler AG
Original Assignee
DaimlerChrysler AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by DaimlerChrysler AG filed Critical DaimlerChrysler AG
Publication of EP1346881A2 publication Critical patent/EP1346881A2/de
Publication of EP1346881A3 publication Critical patent/EP1346881A3/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories

Definitions

  • the invention relates to a method and a device for Transfer of data (software download) by a control unit, in particular a control device in a motor vehicle, wherein the safe operation of the vehicle should be guaranteed.
  • the transfer of program data by a control unit is also called flashing.
  • the flashing of control units offers the particular advantage that defective ECUs not necessarily have to be replaced.
  • By introducing the flash option for ECUs there are problems regarding the safety of derived from the control unit program data and in terms of Security of the program data transfer process itself The first safety problem follows, for example.
  • DE 10008974 A1 discloses a method for ensuring the data integrity of a software for a control unit of a Motor vehicle.
  • This program data which with a Signature provided in the controller on authenticity checked before the data is accepted.
  • the procedure merely ensures that no data is unauthorized in the control unit be programmed. It deals with the Question of the security of the software itself.
  • DE 19921845 A1 discloses a method for programming of program data in a control device in a motor vehicle. This is done by a diagnostic test device on the control unit queried which program version is available in the control unit and the program version, if necessary, by a new version replaced. The procedure ensures that only appropriate Program data are programmed into the control unit.
  • the invention has for its object a method and a Device for transferring program data by means of To provide control unit in a motor vehicle, which the Avoid disadvantages of the prior art and in particular the safe operation of the motor vehicle automatically guarantee.
  • the invention is based on the idea that the control devices themselves can verify the existence of the situations necessary for ensuring their functionality when transferring program data. These conditions are referred to below as program data transfer situations. These program data transfer situations are conditions that are specified by a classification of the different ECUs into safety classes. The classification of the control units into safety classes depends on the operating status of the control unit or the vehicle in which a flash operation may be performed. If a control unit is divided into one of these safety classes, this precisely describes in which operating states a control device may allow a flash process and in which operating states the control device must reject a flash process. This is followed by the tests to be performed by the ECU before a flash process. Was the controller the flash request communicated.
  • control unit So submitted a program data transfer request to the controller, so this controller must check depending on its safety class, whether it is in a state in which it may allow a flash process or not. On the basis of this decision, the control unit then changes into a program data transfer state, the state "flashing" in order to be able to carry out the flash process, or it responds to the flash request with an error message. If the control unit changes into its program data transfer state, the program data are transmitted from a data transfer point, which provides the program data, to the control unit, and the control unit accepts the program data.
  • the existence of the program data transfer situations specified by the safety classification of the control unit is checked by the control unit.
  • the transmitter of the program data that is a data transfer point
  • the program data transfer situations to be checked by the control unit and the data transfer point preferably match.
  • the determination of which program data transfer situations must be able to be carried out preferably by querying the safety class classification of the control unit.
  • the safety class arrangement of the control unit can be stored in the control unit.
  • the control unit queries the test result of the program transfer point. This query can also replace at least parts of the check as to whether the program data transfer situations existing for the control unit exist.
  • the software download may be rejected by the control unit and / or the software is not provided by the data transfer point. If the predetermined program data transfer situations do not exist, the program data to be transferred can be buffered by the data transfer point until the appropriate situation is actively brought about by the control unit and / or occurred. Subsequently, the software download can be carried out. During the software download, the control unit and / or the data transfer point ensure that the given program data transfer situations remain. For example, the start of the engine can be prevented. If there is a communication connection between the control unit and a tester and / or a data transfer control center during the software download, the program data transfer state is preferably left by the control unit only when a data transfer completion command issued by the center has been received by the control unit.
  • program data transfer situations which besides the requirement for authenticity and integrity the program data to be transferred, ie program data independent situations.
  • authenticity will be the security understood that the program data from a Authorized source.
  • the integrity of the data means that the data is unadulterated and / or error free from Control unit to be adopted.
  • An authenticity check of the program data from the Control unit or performed by the data transfer point e.g. that disclosed in DE 10008974 A1 Method.
  • the authenticity check of the program data becomes doing so by checking a signature by means of a public key, with a key pair to encrypt and decrypt the program data, consisting of a secret and the public key is used and the program data is signed with the secret key were.
  • the public key is preferred in the Control device, e.g. deposited within the boot sector.
  • FIG. 1 shows the structure of a data transfer system according to the invention and the cooperation of the components of the system for carrying out the method according to the invention.
  • the illustrated control unit 50 could, for example, be divided into the safety class two or three of the table shown in FIG. 2, since the program data transfer process is monitored and controlled by a program data transfer control center 10.
  • the acquisition of the program data by the control unit is preferably initiated by the delivery of a program data transfer request 11 from the program data transfer point 9 to the control unit.
  • the program data transfer point may be outside the vehicle.
  • the communication can be carried out, for example, via a radio link or by means of optical transmission.
  • the program data transfer point can also be pronounced as a vehicle component.
  • the communication is then performed eg via a vehicle data bus.
  • the program data to be transferred can be read from an external source, eg from a compact disc, from the program data transfer point.
  • the control unit Upon receipt of the program data transfer request, the control unit starts checking whether the program data transfer situations 31-35 prescribed for its safety class exist.
  • the safety class 1 of the control unit for example, stored in the program data memory 2 of the control unit and to determine which program data transfer situations must exist, be read 20.
  • the assignment of the safety classes to the program data transfer situations can be carried out, for example, by linking via a table, such as the table described in FIG. 2. This has the advantage that a software, which is used to control the tests for different types of control units can be used.
  • the control unit is equipped with means for checking 6 the predetermined program data transfer situations. Preferred embodiments of these agents are listed in the table in FIG.
  • 104 checks the program data transfer point the existence of the program data transfer situations 31,33 and 35. Only after the existence of these program data transfer situations, the program data transfer point provides the program data for transmission ready.
  • the characteristics of the specification of which program data transfer situations must exist can be determined by the program data transfer point, for example by querying the safety class of the control unit stored in the control unit. Furthermore, a query of the program data transfer situation test results 103 of the program data transfer point is provided. After the controller has determined that all predetermined program data transfer situations exist, the transition of the controller takes place in the program transfer state. The means provided in the control unit for the acquisition of the program data 3 can now take over the program data from the program data transfer point 7. After the program data transfer, an authenticity check 4 of the acquired program data is preferably carried out before this is passed on to the program data memory 2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Programmable Controllers (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)

Abstract

Vorgeschlagen wird ein Verfahren zum Übernehmen von Programmdaten durch ein Steuergerät (50) in einem Kraftfahrzeug, wobei die Programmdaten von einer Datenübergabestelle (9) bereit gestellt werden, mit den Schritten, Abgeben einer Programmdatenübernahmeanfrage an das Steuergerät (50), Übergehen des Steuergerätes in einen Programmdatenübernahmezustand, Übertragen der Programmdaten an das Steuergerät (50) und Übernehmen der Programmdaten durch das Steuergerät (50), wobei vor dem Übergehen des Steuergerätes (50) in den Programmdatenübernahmezustand, von dem Steuergerät (50) geprüft wird, ob für das Steuergerät vorgegebene Programmdatenübernahmesituationen (31-35) bestehen. Das Verfahren eignet sich insbesondere zum Flashen von Steuergerätesoftware in Kraftfahrzeugen. <IMAGE>

Description

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Übernehmen von Daten (Software-Download) durch ein Steuergerät, insbesondere ein Steuergerät in einem Kraftfahrzeug, wobei der sichere Betrieb des Fahrzeuges gewährleistet werden soll. Das Übernehmen von Programmdaten durch ein Steuergerät wird auch als Flashen bezeichnet. Das Flashen von Steuergeräten bietet insbesondere den Vorteil, dass defekte Steuergeräte nicht in jedem Fall ausgetauscht werden müssen. Durch die Realisierung von Steuergeräten, welche durch Flashen neue Software oder Daten übernehmen können, wurde die Möglichkeit geschaffen defekte Steuergeräte durch einen Softwareupdate zu reparieren oder neue Funktionalitäten in einem Steuergerät zu implementieren, ohne das Steuergerät austauschen zu müssen. Durch die Einführung der Flashmöglichkeit für Steuergeräte ergeben sich jedoch Probleme hinsichtlich der Sicherheit der vom Steuergerät übernommenen Programmdaten und hinsichtlich der Sicherheit des Programmdatenübernahmeprozesses selbst. Aus dem erstgenanten Sicherheitsproblem folgt z.B. die Frage, wie man verhindern kann, dass ein Unbefugter eine manipulierte Software in ein Steuergerät einbringt und dem Fahrzeugnutzer damit Schaden zufügt. Bezüglich der Sicherheit des Programmdatenübernahmeprozesses ist die Frage, in welchem Zustand ein Steuergerät sich befinden darf, um einen Flashvorgang zu akzeptieren. Z.B. darf ein Steuergerät während des Fahrzeugbetriebes in Abhängigkeit von seiner Funktionalität nicht in jedem Fall einen Flashvorgang erlauben.
Bei einem Flashprozess können Fehler auftreten, die je nach Funktionalität eines Steuergerätes unterschiedliche Folgen haben. Fällt durch das Flashen eine bestimmte Funktionalität eines Steuergerätes aus, so kann dies im schlimmsten Fall die Sicherheit der Insassen beeinflussen. Deshalb muss beim Flashen von Software in Fahrzeug-Steuergeräte, über eine Kommunikationsstrecke oder über einen Datenträger, sicher gestellt sein, dass sich aus dem Flashen heraus keine Gefährdung ergibt.
Die DE 10008974 A1 offenbart ein Verfahren zur Sicherstellung der Datenintegrität einer Software für ein Steuergerät eines Kraftfahrzeuges. Dabei werden Programmdaten, welche mit einer Signatur versehen sind im Steuergerät auf Authentizität überprüft, bevor die Daten akzeptiert werden. Das Verfahren stellt lediglich sicher, dass keine Daten durch Unbefugte in das Steuergerät einprogrammiert werden. Es befasst sich mit der Frage der Sicherheit der Software selbst.
Die DE 19921845 A1 offenbart ein Verfahren zum Einprogrammieren von Programmdaten in ein Steuergerät in einem Kraftfahrzeug. Dabei wird von einer Diagnosetestvorrichtung am Steuergerät abgefragt, welche Programmversion im Steuergerät vorhanden ist und die Programmversion gegebenen falls durch eine neue Version ersetzt. Das Verfahren stellt sicher, dass nur passende Programmdaten in das Steuergerät einprogrammiert werden.
Nachteilig bei den Verfahren zum Übernehmen von Daten in ein Steuergerät, gemäß Stand der Technik, sind die folgende Einschränkungen:
  • Während dem Flashen wird kein sicherer Fahrzeugzustand automatisch gewährleistet. Die Verfahren eignen sich daher nicht zum Flashen von Programmdaten außerhalb einer Werkstatt, insbesondere während des Fahrzeugbetriebes.
  • Die Verfahren garantieren nicht, dass die Funktionsfähigkeit des geflashten Steuergerätes erhalten bleibt.
  • Es wird keine Aussage getroffen in welchem Betriebszustand sich ein Steuergerät bzw. das Fahrzeug für die Durchführung des Flashvorganges befinden muss. Es wird nicht berücksichtigt, dass ein Steuergerät einen Flashprozess ablehnen muss, wenn es sich in einem Zustand befindet, in dem die Ausführung des Flashprozesses die Sicherheit des Fahrers bzw. des Fahrzeuges gefährden könnte.
  • Es erfolgt keine automatische Differenzierung der Steuergeräte hinsichtlich deren Sicherheitsrelevanz. Hierdurch entstehen für das Flashen aller Steuergeräte die gleichen Aufwände. Da auch sicherheitsunkritische Steuergeräte mit dem gleich hohen Aufwand, wie sicherheitskritische Steuergeräte behandelt werden entstehen vermeidbare Kosten.
Der Erfindung liegt die Aufgabe zugrunde ein Verfahren und eine Vorrichtung zur Übernahme von Programmdaten durch ein Steuergerät in einem Kraftfahrzeug bereitzustellen, welche die Nachteile des Standes der Technik vermeiden und insbesondere den sicheren Betrieb des Kraftfahrzeuges automatisch gewährleisten.
Erfindungsgemäß wird die Aufgabe durch das Verfahren und die Vorrichtung gemäß den unabhängigen Ansprüchen gelöst. Besondere Ausführungsformen sind Gegenstand der abhängigen Ansprüche.
Der Erfindung liegt der Gedanke zugrunde, dass von den Steuergeräte selbst das Bestehen der zur Sicherstellung ihrer Funktionalität notwendigen Situationen bei der Übernahme von Programmdaten überprüft werden kann. Diese Bedingungen werden nachfolgend als Programmdatenübernahmesituationen bezeichnet. Bei diesen Programmdatenübernahmesituationen handelt es sich um Bedingungen, welche durch eine Einteilung der unterschiedlichen Steuergeräte in Sicherheitsklassen (Safety-Klassen) vorgegeben werden.
Die Einteilung der Steuergeräte in Safety-Klassen richtet sich nach dem Betriebszustand des Steuergerätes bzw. des Fahrzeuges, in welchem ein Flashvorgang vorgenommen werden darf. Wird ein Steuergerät in eine dieser Safety-Klassen eingeteilt, ist dadurch präzise beschrieben in welchen Betriebszuständen ein Steuergerät einen Flashprozess erlauben darf und in welchen Betriebszuständen das Steuergerät einen Flashprozess ablehnen muss. Hieraus folgen die vor einem Flashprozess vom Steuergerät durchzuführenden Prüfungen. Wurde dem Steuergerät der Flashwunsch mitgeteilt. also eine Programmdatenübernahmeanfrage an das Steuergerät abgegeben, so muss dieses Steuergerät in Abhängigkeit von seiner Safety-Klasse überprüfen, ob es sich in einem Zustand befindet in dem es einen Flashprozess zulassen darf oder nicht. Aufgrund dieser Entscheidung wechselt das Steuergerät dann in eine Programmdatenübernahmezustand, den Zustand "Flashen", um den Flashprozess durchführen zu können, oder es beantwortet den Flashwunsch mit einer Fehlermeldung. Wechselt das Steuergerät in seinen Programmdatenübernahmezustand, so werden die Programmdaten von einer Datenübergabestelle, welche die Programmdaten bereit stellt, an das Steuergerät übertragen und das Steuergerät übernimmt die Programmdaten.
Vor der Durchführung eines Software-Downloads wird das Bestehen der durch die Safety-Klasseneinteilung des Steuergerätes vorgegebenen Programmdatenübernahmesituationen vom Steuergerät geprüft. Bevorzugt werden auch vom Sender der Programmdaten, also einer Datenübergabestelle, das Bestehen von für das betroffene Steuergerät vorgegebenen Programmdatenübernahmesituationen geprüft. Die vom Steuergerät und der Datenübergabestelle zu prüfenden Programmdatenübernahmesituationen stimmen dabei bevorzugt überein. Die Feststellung, welche Programmdatenübernahmesituationen bestehen müssen kann dabei bevorzugt durch Abfrage der Safety-Klasseneinordnung des Steuergerätes vorgenommen werden. Z.B. kann die Safety-Klasseneinordnung des Steuergerätes im Steuergerät abgespeichert sein.
In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird vom Steuergerät das Prüfungsergebnis der Programmübergabestelle abgefragt. Diese Abfrage kann auch zumindest Teile der Prüfung, ob die für das Steuergerät bestehenden Programmdatenübernahmesituationen bestehen ersetzen. Dadurch ergibt sich in vorteilhafter Weise ein Einsparungspotential bei der technischen Ausstattung des Steuergeräts.
Stimmen eine oder mehrere Anforderungen an die der Saftey-Klasseneinordnung entsprechenden Programmdatenübernahmesituationen nicht mit der momentanen Situation überein, so kann der Software-Download vom Steuergerät abgelehnt werden und/oder die Software wird nicht von der Datenübergabestelle bereit gestellt. Wenn die vorgegebenen Programmdatenübernahmesituationen nicht bestehen, können die zu übernehmenden Programmdaten von der Datenübergabestelle so lange zwischengespeichert werden, bis die passende Situation aktiv durch das Steuergerät herbei geführt ist und/oder eingetreten ist. Anschließend kann der Software-Download durchgeführt werden. Während des Software-Downloads wird vom Steuergerät und/oder von der Datenübergabestelle sicher gestellt, dass die vorgegebenen Programmdatenübernahmesituationen bestehen bleiben. Z.B. kann der Start des Motors verhindert werden. Besteht während des Software-Downloads eine Kommunikationsverbindung zwischen dem Steuergerät und einem Tester und/oder einer Datenübernahmekontrollzentrale (Zentrale), so wird der Programmdatenübernahmezustand vom Steuergerät bevorzugt erst verlassen, wenn ein, von der Zentrale abgegebener, Datenübernahmebeendigungsbefehl vom Steuergerät empfangen wurde.
Für die Festlegung der Safety-Klassen werden bevorzugt die folgenden Einflussfaktoren auf die Programmdatenübernahmesituationen berücksichtigt:
  • Datenübertragungsweg (Flashwege), z.B. Flashen über eine Funkverbindung (Luftschnittstelle),
  • Fahrzeugzustände, z.B. ob das Fahrzeug momentan in Betrieb ist,
  • Art der Flashdaten,
  • Initialisierung eines zu übernehmenden Steuergeräteprogramms (Flashware) und
  • Steuergeräteprogrammsicherungsmöglichkeiten (Backupmöglichkeiten) der mit den zu übernehmenden Programmdaten zu überschreibenden und/oder zu ergänzenden alten Programmdaten.
Insbesondere sind dies Programmdatenübernahmesituationen, welche neben der Anforderung auf Authentizität und Integrität der zu übernehmenden Programmdaten bestehen, also programmdatenunabhängige Situationen. Unter Authentizität wird die Sicherheit verstanden, dass die Programmdaten von einer autorisierten Quelle stammen. Die Integrität der Daten bedeutet, dass die Daten unverfälscht und/oder fehlerfrei vom Steuergerät übernommen werden. Zur Sicherung der Integrität und Authentizität sind zusätzlich zum erfindungsgemäßen Verfahren die bekannten Verfahren aus dem Stand der Technik anwendbar. Bevorzugt wird ein Authentizitätsprüfen der Programmdaten vom Steuergerät oder von der Datenübergabestelle durchgeführt. Hierzu eignet sich z.B. das in der DE 10008974 A1 offenbarte Verfahren. Das Authentizitätsprüfen der Programmdaten wird dabei durch Überprüfen einer Signatur mittels eines öffentlichen Schlüssels durchgeführt, wobei ein Schlüsselpaar zum Ver- und Entschlüsseln der Programmdaten, bestehend aus einem geheimen und dem öffentlichen Schlüssel verwendet wird und die Programmdaten mit dem geheimen Schlüssel signiert wurden. Der öffentliche Schlüssel wird dabei bevorzugt im Steuergerät, z.B. innerhalb des Boot-Sektors hinterlegt.
Durch das erfindungsgemäße Verfahren und die Vorrichtungen zur Durchführung des Verfahrens werden die Nachteile des Standes der Technik vermieden. Insbesondere werden folgende Vorteile realisiert:
  • Der Software Download in ein Steuergerät ist ohne Gefährdung von Personen und Gütern, z.B. über eine Kommunikationsstrecke oder einen Datenträger möglich.
  • Die Erfindung ermöglicht das sichere Flashen von Software auch außerhalb einer Werkstatt, d.h. während des Fahrzeugeinsatzes.
  • Aufwendige Flashverfahren werden nur für sicherheitskritische Steuergeräte verwendet. Daraus ergeben sich Kosteneinsparungspotentiale.
Die vorliegende Erfindung und bevorzugte Ausführungsformen der Erfindung werden nachfolgend anhand von einer Figur und Tabellen beschrieben.
  • Fig. 1 zeigt den prinzipiellen Aufbau eines erfindungsgemäßen Datenübergabesystems und wie die Komponenten des Systems, zur Durchführung des erfindungsgemäßen Verfahrens zusammen arbeiten.
  • Fig. 2 zeigt eine Tabelle in der die Programmübernahmesituationen angegeben sind, welche zur Programmdatenübernahme eines Steuergerätes, in Abhängigkeit von dessen Sicherheitsklasse, bestehen müssen.
  • Fig. 3 zeigt eine Tabelle in der Anforderungen an die Steuergeräte in Abhängigkeit von deren Sicherheitsklasse angegeben sind.
    • In Fig. 1 wird der Aufbau eines erfindungsgemäßen Datenübergabesystems und die Zusammenarbeit der Komponenten des Systems, zur Durchführung des erfindungsgemäßen Verfahrens dargestellt. Das dargestellte Steuergerät 50 könnte z.B. in die Safety-Klasse zwei oder drei der in Figur 2 dargestellten Tabelle eingeteilt sein, da der Programmdatenübernahmeprozess von einer Programmdatenübernahmekontrollzentrale 10 überwacht und kontrolliert 8 wird. Die Übernahme der Programmdaten durch das Steuergerät wird bevorzugt durch die Abgabe einer Programmdatenübernahmeanfrage 11 von der Programmdatenübergabestelle 9 an das Steuergerät initiiert. Die Programmdatenübergabestelle kann sich außerhalb des Fahrzeuges befinden. Dann kann die Kommunikation z.B. über eine Funkverbindung oder mittels optischer Übertragung durchgeführt werden. Die Programmdatenübergabestelle kann auch als Fahrzeugbauteil ausgeprägt sein. Die Kommunikation wird dann z.B. über einen Fahrzeugdatenbus geführt. Die zu übernehmenden Programmdaten können von einer externen Quelle, z.B. von einer Compactdisc, von der Programmdatenübergabestelle gelesen werden. Nach Erhalt der Programmdatenübernahmeanfrage beginnt das Steuergerät mit der Prüfung, ob die für seine Safety-Klasse vorgegebenen Programmdatenübernahmesituationen 31-35 bestehen. Hierzu kann die Safety-Klasse 1 des Steuergerätes, z.B. im Programmdatenspeicher 2 des Steuergerätes abgelegt sein und zur Feststellung, welche Programmdatenübernahmesituationen bestehen müssen, ausgelesen 20 werden. Die Zuordnung der Safety-Klassen zu den Programmdatenübernahmesituationen kann z.B. durch Verknüpfung über eine Tabelle, wie die in Fig. 2 beschriebene Tabelle, vorgenommen werden. Das hat den Vorteil, dass eine Software, welche zur Steuerung der Prüfungen eingesetzt wird für Steuergeräte verschiedenen Typs verwendet werden kann. Zur Prüfung 102 der Programmdatenübernahmesituationen ist das Steuergerät mit Mitteln zur Überprüfung 6 der vorgegebenen Programmdatenübernahmesituationen ausgestattet. Bevorzugte Ausprägungen dieser Mittel sind in der Tabelle in Figur 3 aufgeführt. In der dargestellten Ausführungsform wird weiterhin überprüft, ob die Programmdatenübernahmesituation "Kommunikationsverbindung mit Tester oder Datenübernahmekontrollzentrale" 101 besteht. Eine derartige Kommunikationsverbindung ist Voraussetzung für den Übergang des Steuergerätes in den Programmübernahmezustand 5, z.B. im Falle eines sicherheitskritischen Steuergerätes. Auch die Programmdatenübergabestelle 9 ist mit Mitteln zur Prüfung vorgegebener Programmdatenübernahmesituationen ausgestattet 61. Im dargestellten Ausführungsbeispiel überprüft 104 die Programmdatenübergabestelle das Bestehen der Programmdatenübernahmesituationen 31,33 und 35. Erst nach der Feststellung des Bestehens dieser Programmdatenübernahmesituationen stellt die Programmdatenübergabestelle die Programmdaten zur Übertragung bereit. Die Ausprägungen der Vorgabe, welche Programmdatenübernahmesituationen bestehen müssen, kann die Programmdatenübergabestelle z.B. durch Abfrage der im Steuergerät gespeicherten Safety-Klasse des Steuergeräts feststellen. Weiterhin ist eine Abfrage der Programmdatenübernahmesituationsprüfungsergebnisse 103 der Programmdatenübergabestelle vorgesehen.
    Nachdem das Steuergerät festgestellt hat, dass alle vorgegebenen Programmdatenübernahmesituationen bestehen, erfolgt der Übergang des Steuergeräts in den Programmübernahmezustand. Die im Steuergerät vorgesehenen Mittel zur Übernahme der Programmdaten 3 können jetzt die Programmdaten von der Programmdatenübergabestelle übernehmen 7. Nach der Programmdatenübernahme wird bevorzugt eine Authentizitätsprüfung 4 der übernommenen Programmdaten durchgeführt, bevor dies an den Programmdatenspeicher 2 weiter gegeben 40 werden.
    In Fig. 2 ist eine Tabelle dargestellt, in der die Programmübernahmesituationen angegeben sind, welche zur Programmdatenübernahme eines Steuergerätes, in Abhängigkeit von dessen Sicherheitsklasse, bestehen müssen. Die Steuergeräte werden, abhängig von den Folgen, die eine Steuergerätefehlfunktion auf die Fahrsicherheit des Fahrzeugs haben kann, in Safety-Klassen eingeteilt. Zunächst werden Steuergeräte unterschieden, deren Funktionalität kritisch für die Betriebssicherheit des Fahrzeuges ist, und solche Steuergeräte, deren Funktionalität unkritisch für die Betriebssicherheit ist. Aus Sicherheitstechnischer Sicht ist es nicht entscheidend, ob die Folgen einer Steuergerätefehlfunktion nicht oder nur schwer kontrollierbar sind. Daher lassen sich Steuergeräte in Bezug auf den Flashprozess in zwei Typen einteilen:
    • Steuergeräte, bei denen unter keinen Umständen ein durch Flashen verursachter Fehler toleriert werden darf, weil die Sicherheit der Insassen oder Unbeteiligter davon betroffen sein kann und
    • Steuergeräte, bei denen ein durch Flashen verursachter Fehler keine "ernsten" Folgen für die Fahrsicherheit hat und deshalb temporär toleriert werden kann.
    Hinzu kommen noch die Steuergeräte, die gar nicht geflasht werden dürfen. Diese Unterteilung in drei Oberklassen wird für die beiden Fälle "kritisch für die Betriebssicherheit" und "nicht kritisch für die Betriebssicherheit" noch weiter verfeinert. Für die Oberklasse der für die Betriebssicherheit kritischen Steuergeräte werden drei verschiedene Safety-Klassen definiert, die sich hauptsächlich durch den Flashweg und somit die Möglichkeit der Überwachung des Flashvorganges unterscheiden. Die für die Betriebssicherheit nicht kritischen Steuergeräte können in zwei Safety-Klassen eingeteilt werden. Hier ist für den Anwender von Interesse, ob das Steuergerät nach dem Flashprozess noch funktionstüchtig ist oder nicht. Insgesamt ergeben sich daraus fünf Safety-Klassen SK1 bis SK5, zuzüglich der Safety-Klasse null SK0, welche Steuergeräte umfasst, die keinen Software-Download zulassen.
    Nachfolgend werden zunächst die Programmdatenübernahmesituationen, welche für Steuergeräte in den unterschiedlichen Safety-klassen bestehen können im einzelnen aufgeführt. Anschließend werden die Safety-Klassen hinsichtlich der Vorgaben, welche Programmdatenübernahmesituationen für ein in die jeweilige Safety-Klasse eingeordnetes Steuergerät erfüllen muss, erläutert.
    Die neuen Flashdaten können über verschiedene Schnittstellen in das Fahrzeug und somit in das zu flashende Steuergerät gelangen. Diese Datenübertragungswege werden nachfolgend als Flashwege bezeichnet. Die im folgenden aufgelisteten Flashwege beschrieben dabei den Ort an dem sich das Fahrzeug für den Flashprozess befinden muss, die Person, die den Flashprozess steuert, und die Übertragungseigenschaften des Kanals auf dem die Flashdaten in das Fahrzeug gelangen. Der Ort und die Person sind dabei miteinander verknüpft. Wird der Flashprozess in einer Werkstatt durchgeführt, so handelt es sich bei der Person, die den Flashprozess steuert um einen für den Flashprozess speziell geschulten Mitarbeiter. Dieser weiß aufgrund seiner Qualifikation, wie im Fehlerfall mit der aufgetretenen Situation umzugehen ist. Es ist daher davon auszugehen, dass dem Fahrzeugnutzer nach dem in der Werkstatt durchgeführten Flashprozesses ein vollständig funktionsfähiges Fahrzeug übergeben wird. Findet der Flashprozess außerhalb einer Werkstatt statt, kann man nicht davon ausgehen, dass die Person, die den Flashprozess steuert, weiß, wie mit einem Fehlerfall richtig umzugehen ist. In diesem Fall kann man deshalb nicht davon ausgehen, dass das Fahrzeug nach einem fehlerhaften Flashprozess weiterhin vollständig funktionsfähig ist. Die Qualität der aus den Flashwegen resultierenden unterschiedlichen Übertragungswege für die Flashdaten spielt für die Klassifizierung der verschiedenen Wege keine Rolle. Entscheidend für die Sicherheit des Flashprozesses auf den unterschiedlichen Wegen ist nicht die Häufigkeit, mit der ein Fehler auftritt, sondern die Möglichkeiten des Flashenden einen Fehler zu erkennen, darauf zu reagieren und das Steuergerät bzw. das Fahrzeug wieder in einen sicheren und funktionsfähigen Zustand zu versetzen. So besteht bei der Durchführung des Flashvorganges in einer Werkstatt als letzte Maßnahme die Möglichkeit ein defektes Steuergerät gegen ein neues funktionsfähiges Auszutauschen. Diese Möglichkeit besitzt der Fahrzeugnutzer, der den Flashvorgang außerhalb einer Werkstatt durchführt, nicht. Hier besteht die Gefahr, dass dieser trotz einer Fehlermeldung und einer eindringlichen Warnung versucht, das Fahrzeug mit dem fehlerhaften Steuergerät zu betreiben. Im Folgenden werden die drei Flashwege W1 bis W3 klassifiziert.
    • Flashweg eins (W1): Flashen über einen Tester
      Wird der Flashprozess mit Hilfe eines Testers durchgeführt, muss sich das Fahrzeug zwingend in einer Werkstatt befinden, da nur dort der Zugriff auf einen Tester möglich ist. Der Flashprozess wird auf diesem Weg von geschultem Fachpersonal durchgeführt oder es besteht eine kurzfristige Zugriffsmöglichkeit auf geschultes Fachpersonal, sodass eventuell auftretende Fehler im Verlaufe des Flashvorgangs erkannt und behoben werden können. Als letzte Maßnahme kann im Fehlerfall das defekte Steuergerät in der Werkstatt auch ausgetauscht werden, um somit die sichere Funktionsfähigkeit des Steuergerätes und damit des Fahrzeuges garantieren zu können. Ein Gefährdung des Fahrzeugnutzers nach dem Werkstattaufenthalt ist daher mit hoher Wahrscheinlichkeit auszuschließen.
    • Flashweg zwei (W2): Autarkes Flashen mit einer CD im Fahrzeug
      Für den Weg drei muss sich das Fahrzeug nicht in einer Werkstatt befinden. Stattdessen besitzt der Fahrzeugnutzer eine CD auf der die Flashdaten sowie die Informationen zum Flashvorgang gespeichert sind. Diese CD wird durch den Fahrzeugbenutzer in ein Laufwerk im Fahrzeug eingelegt. Der Flashprozess wird auf Weg zwei nicht von geschultem Fachpersonal ausgeführt, sondern von dem Fahrzeugbesitzer selbst ausgelöst. Es kann daher nicht davon ausgegangen werden, dass während dem Flashvorgang auftretende Fehler erkannt oder gar korrigiert werden können. Der Fahrzeugnutzer besitzt nicht die Möglichkeit das Steuergerät in jedem Fall wieder in einen funktionsfähigen Zustand zu versetzten. Auch steht dem Fahrzeugnutzer nicht die Möglichkeit offen, den Fehlerfall durch den Austausch des Steuergerätes zu beheben. Eine Gefährdung des Fahrzeugnutzers durch ein, durch den Flashprozess unbrauchbar gewordenes, Steuergerät ist daher für diesen Flashweg nicht auszuschließen.
    • Flashweg drei (W3): Flashen über die Luftschnittstelle
      Dieser Weg kann auch verwendet werden, wenn sich das Fahrzeug nicht in einer Werkstatt befindet. Die Flashdaten werden auf Initiative einer Zentrale oder des Fahrzeugnutzers über die Luftschnittstelle in das Fahrzeug geladen. Auch die Daten über den Flashjob gelangen auf diese Weise in das Fahrzeug. Der Flashvorgang wird auf der Fahrzeugseite nicht von geschultem Fachpersonal durchgeführt, sondern vom Fahrzeugnutzer selbst. Fehler Im Fahrzeug können daher unerkannt bleiben und somit nicht behoben werden. Ebenso wie bei Flashweg drei besitzt der Fahrzeugnutzer im Fehlerfalle nicht generell die Möglichkeit den Fehler zu beheben und das Steuergerät damit in einen funktionsfähigen Zustand zu bringen. Auf Seiten der Zentrale kann der Flashvorgang von einem zentralen Server-System automatisch oder von einem Mitarbeiter der Zentrale unterstützt und überwacht werden. In beiden Fällen können Fehler während des Flashvorganges durch geeignete Diagnose-Tools in der Zentrale erkannt werden. Die Möglichkeiten den Fehler zu beheben sind allerdings durch das Übertragungsmedium sehr eingeschränkt. So kann der, in der Werkstatt als letzte Maßnahme dargestellte, Austausch des fehlerhaften Steuergerätes nicht direkt durchgeführt werden. Die Zentrale kann lediglich von sich aus einen Service-Techniker zum Fahrzeug rufen, der dann das Problem behebt. Eine Gefährdung des Fahrzeugnutzers kann allerdings nicht vollständig ausgeschlossen werden, da dieser, trotz des fehlerhaften Steuergerätes und einer eventuellen Warnung seitens der Zentrale, versuchen kann das Fahrzeug in Betrieb zu nehmen.Ein Fahrzeug kann sich während des Flashprozesses in verschiedenen Zuständen befinden, die unterschiedliche Auswirkungen auf die Möglichkeit des Flashens haben. Den Steuergeräten muss es daher möglich sein, den Fahrzeugzustand zu erkennen und/oder von einem anderen Steuergerät auszulesen. Das Steuergerät wechselt abhängig von diesen Information in einen Datenübernahmezustand oder verweigert die Datenübernahme. Im Folgenden werden die vier Fahrzeugzustände Z1 bis Z4 klassifiziert.
    • Fahrzeugzustand eins (Z1): An das Fahrzeug ist ein Tester angeschlossen In diesem Fahrzeugzustand ist ein Tester an das Fahrzeug angeschlossen, der den Software-Download mit entsprechenden Diagnose-Tools überwachen kann. Ob in diesem Zustand der Motor des Fahrzeuges angeschaltet ist oder nicht, ist nicht relevant, da es sich bei dem Testdurchführenden um geschultes Fachpersonal handelt, das über Gefahren und Risiken ausreichend informiert ist. Weiterhin kann es an dieser Stelle zu Diagnoseoder Initialisierungszwecken auch notwendig sein, dass der Motor läuft. Da dem das Flashen Durchführenden alle vorhandenen Diagnosetools auf dem Tester zur Verfügung stehen, kann man davon ausgehen, dass Fehler, die beim Flashen auftreten, durch das Fachpersonal in der Werkstatt erkannt werden und entsprechende Gegenmaßnahmen ergriffen werden können. Kommt das Fahrzeug aus der Werkstatt, kann der Fahrzeugführer davon ausgehen, dass alle Flashprozesse ordnungsgemäß und fehlerfrei durchgeführt wurden. Dieser Fahrzeugzustand ist mit dem Flashwege W1 verknüpft.
    • Fahrzeugzustand zwei (Z2): Der Motor des Fahrzeuges läuft Ist der Motor des Fahrzeuges an, so wird sich das Fahrzeug im Normalfall auch in Bewegung befinden. Dementsprechend muss sich zumindest ein Fahrer im Fahrzeug befinden. Dieser kann, eingeschränkt durch die notwendige Konzentration auf den Verkehr, den Flashprozess überwachen. Der Fahrzeugführer ist allerdings im Gegensatz zu dem Fachpersonal einer Werkstatt nicht für das Flashen ausgebildet. Weiterhin stehen in Fahrzeugzustand zwei nicht die durch den Tester gelieferten Diagnosedaten zur Verfügung. Eventuelle Fehler beim Flashen können daher unerkannt bleiben oder durch den Fahrzeugnutzer nicht behoben werden. Es kann demnach nicht sicher von einem erfolgreichen Flashen ausgegangen werden. Wird das gerade im Flashprozess befindliche Steuergerät für den Fahrbetrieb des Fahrzeugs benötigt, so kann der Ausfall des Steuergeräts unvorhersehbare Folgen haben. Deshalb ist Fahrzeugzustand zwei als besonders kritisch einzuschätzen. In diesem Zustand ist auch zu berücksichtigen, dass das Fahrzeugnetz bereits durch die für das Fahren des Fahrzeugs erforderliche Kommunikation belastet ist und das Flashen eines Steuergerätes eine weitere Netzlast erzeugt. Die für den sicheren Betrieb des Fahrzeugs notwendige Datenkommunikation muss in diesem Zustand Vorrang vor der durch den Flashprozess verursachten Datenkommunikation haben. Dementsprechend müssen die Steuergeräte bzw. das Fahrzeugnetzwerk die Möglichkeiten haben, die Datenkommunikation mit unterschiedlichen Prioritäten zu belegen.
    • Fahrzeugzustand drei(Z3): Der Motor des Fahrzeuges ist aus und die Zündung ist an
      Ist der Motor des Fahrzeuges aus, die Zündung des Fahrzeuges allerdings angeschaltet, so hat zwar eine Person die Zündung des Fahrzeuges eingeschaltet, dass diese Person den gesamten Verlauf des Flashvorganges im Fahrzeug beobachtet, kann jedoch nicht angenommen werden. Die Überwachung des Flashprozesses ist damit nicht über den gesamten Zeitraum hinweg sicher gewährleistet. Im Gegensatz zu den Angestellten einer Werkstatt ist der Fahrzeugführer nicht speziell für das Durchführen eines Flashprozesses ausgebildet. Er besitzt keinen Tester, über den er Diagnosedaten des Steuergerätes auslesen kann. Es kann daher zu unerkannten Fehlern während des Flashprozesses kommen. Werden Fehler durch den Flashenden erkannt, so ist nicht sichergestellt, dass dieser richtig auf den Fehler reagieren kann. Im Fahrzeugzustand drei kann nicht von einem erfolgreichen Flashprozess ausgegangen werden.
    • Fahrzeugzustand vier (Z4): Der Motor des Fahrzeuges ist aus und die Zündung ist aus
      In diesem Fahrzeugzustand, wenn sowohl Motor als auch Zündung aus sind, kann nicht davon ausgegangen werden, dass zur Überwachung des Downloads sich der Fahrzeugnutzer im Fahrzeug aufhält. Vielmehr ist besonders bei einem Download über die Luftschnittstelle (W3) davon auszugehen, dass das Flashen des Steuergerätes ohne Einwirkung des Fahrzeugbesitzers durchgeführt wird. Fehler, die während des Flashprozesses entstehen, werden hierdurch sehr wahrscheinlich unentdeckt bleiben. Weiterhin ist nicht sichergestellt, dass Fehler, die vom Fahrzeugbesitzer entdeckt werden, von diesem behoben werden können. Von einem erfolgreichen Flashprozess kann in diesem Zustand ebenfalls nicht ausgegangen werden. Da zum Flashen einer neuen Flashware bei einer Kombination dieses Zustandes mit dem Flashweg Luftschnittstelle (W3) der Flashprozess gestartet werden kann, ohne physikalischen Zugang zum Fahrzeug zu besitzen, muss der Flashprozess in dieser Kombination durch zusätzliche Maßnahmen abgesichert werden. Nach dem Übertragen einer Flashware kann es die Notwendigkeit geben, dass die Flashware, bevor sie einsatzfähig ist, initialisiert bzw. konfiguriert werden muss. Wird diese Initialisierung bei den entsprechenden Steuergeräten nicht korrekt ausgeführt, kann die korrekte Funktionsweise des geflashten Steuergerätes nicht gewährleistet werden. Das zu flashende Steuergerät muss vor dem Flashvorgang feststellen können, welchen Initialisierungsvorgang die neue Flashware benötigt. Dies ist notwendig, damit das Steuergerät in Abhängigkeit von seiner Safety-Klasse entscheiden kann, ob es einen Flashprozess zulässt oder nicht. Erst wenn diese Entscheidung getroffen werden konnte, darf das Steuergerät in den Zustand "Flashen" übergehen. Die möglichen Steuergeräteinitialisierungsmöglichkeiten können in die folgenden drei Initialisierungsmöglichkeiten I1 bis I3 eingeteilt werden:
    • Initialisierung eins (I1): manuelle Initialisierung
      Diese Initialisierungsmöglichkeit beschriebt den Fall, dass nach einem Flashvorgang das Steuergerät manuell Initialisiert werden muss. Dazu muss es am Fahrzeug jemanden geben, der den Flashprozess überwacht und die Initialisierung durchführen kann. Hierzu gibt das Steuergerät Anweisungen über die durchzuführenden manuellen Initialisierungsmaßnahmen und der Flashende muss diese gewissenhaft und korrekt ausführen. Werden diese Initialisierungsmaßnahmen nicht korrekt ausgeführt, so kann es in diesen Steuergeräten zu Fehlfunktionen kommen, deren Folgen nicht einschätzbar sind.
    • Initialisierung zwei (I2): automatische Initialisierung
      Bei dieser Initialisierungsmöglichkeit kann sich ein geflashtes Steuergerät nach dem Flashvorgang selbstständig, automatisch initialisieren. Daher bedarf es keiner direkten Überwachung durch den Flashenden am Fahrzeug. Es müssen lediglich die durch die Initialisierung möglicherweise erzeugten Fehlermeldungen bearbeitet werden. Die notwendigen Initialisierungsschritte führt ein Steuergerät automatisch direkt nach dem erfolgreichen Flashprozess durch. Hierzu ist keine Interaktion mit dem Fahrzeugnutzer erforderlich.
    • Initialisierung drei (I3): keine Initialisierung
      Durch diese Initialisierungsmöglichkeit wird der Fall beschrieben, dass nach einem Flashprozess kein Initialisierungsvorgang für das Steuergerät mehr notwendig ist. Ein Steuergerät kann demnach direkt nach dem Flashprozess, ohne dass weiter Schritt notwendig sind, verwendet werden. Die Backup-Möglichkeit für die Flashware eines Steuergerätes ist eine weitere Programmdatenübernahmesituation, welche für die Safety-Klasseneinteilung berücksichtigt wird. In Abhängigkeit von den gegebenen Möglichkeiten zum Erstellen eines Backups können Fehler während des Flashprozesses Fahrzeug intern behoben werden oder nicht. Ein Steuergerät muss dabei entscheiden können, welche Möglichkeit ein Backup anzulegen es besitzt.
      Die folgenden Steuergeräteprogrammsicherungsmöglichkeiten (Backup) B1 bis B4 werden für die Safety-Klasseneinteilung berücksichtigt:
    • Backup eins (B1): Backup intern auf dem Steuergerät möglich Ist einem Steuergerät diese Möglichkeit gegeben, so besitzt es ausreichend freien Speicherplatz, um die bisher gespeicherte Version der Flashware zu Backup-Zwecken zwischenzuspeichern. Dabei muss das Gerät die vorhandene Flashware im freien Speicher ablegen können und dieses Backup im Fehlerfall wieder einspielen können. Bei einer internen Sicherung der bereits eingespielten Flashware kann davon ausgegangen werden, dass der alte Zustand des Steuergerätes nach einem fehlerhaften Flashprozess wieder hergestellt werden kann. Wenn ein Rückspielen der Flashware erforderlich ist und es dabei zu einem Fehler kommt, deutet dies auf einen Fehler in der Hardware des Steuergerätes hin und das Steuergerät muss ausgetauscht werden.
    • Backup zwei (B2): Backup auf einem externen Steuergerät
      In diesem Fall besitzt das zu flashende Steuergeräte nicht ausreichend Speicherplatz, um ein Backup der aktuell eingespielten Flashware im eigenen Speicher abzulegen. Aus diesem Grund wird das Backup über das interne Fahrzeug-Netzwerk in ein anderes Steuergerät (Backup-Gerät) eingespielt. Das Backup-Gerät muss hierzu in der Lage sein, die Flashware des zu flashenden Steuergerätes über das interne Fahrzeugnetzwerk zwischenzuspeichern und die Flashware auf Anforderung hin wieder in das ursprüngliche Steuergerät zurückzuspielen. Das Backup-Gerät muss in der Lage sein, unabhängig davon ob das Backup gebraucht wurde oder nicht, die in seinem Speicher abgelegten Dateien wieder zu löschen. Bei dieser Backup-Möglichkeit hängt die Wiederherstellbarkeit des Originalzustandes an der Fehlerbehandlung des internen Fahrzeug-Netzwerkes. Wird durch entsprechende Mechanismen sichergestellt, dass die über das interne Fahrzeug-Netzwerk übertragene Flashware fehlerfrei in dem zweiten Steuergerät gespeichert werden kann und aus diesem auch wieder fehlerfrei in das ursprüngliche Steuergerät eingespielt werden kann, besteht auch auf dieser Backup-Stufe die Möglichkeit den alten Zustand des geflashten Steuergerätes nach einem Fehler wieder herzustellen. Ist die fehlerfreie Übertragung über das interne Fahrzeug-Netzwerk nicht gewährleistet, so kann in dieser Backup-Stufe nicht davon ausgegangen werden, dass der alte Zustand des geflashten Gerätes wieder herstellbar ist. Weiterhin ist die Wiederherstellbarkeit des ursprünglichen Zustandes des geflashten Steuergerätes abhängig von der Zuverlässigkeit des externen Steuergerätes, auf dem das Backup abgelegt wird. Kommt es zu einem unerkannten Fehler aufgrund einer Beschädigung des externen Steuergerätes, so ist das Wiederherstellen des Originalzustandes ebenfalls nicht mehr möglich. Um das Backup wieder in das Steuergerät zurückspielen zu können, muss das Backup mit Sicherheitsmechanismen abgesichert werden. Für derartige Sicherheitsmechanismen kann. z.B. ein asymmetrisches Verschlüsselungsverfahren verwendet werden. Würde man ein Einspielen des Backups ohne Sicherheitsmechanismen zulassen, würde man eine Hintertür für Angreifer öffnen, falls nicht andere Maßnahmen für die Absicherung des Backups getroffen werden.
    • Backup drei (B3): Pufferung der Flashdaten auf einem externen Steuergerät
      Hierbei handelt es sich nicht um ein Backup im eigentlichen Sinne, sondern um eine Vorverarbeitung der Flashware in einem Steuergerät, dass über genügend Speicherplatz verfügt, um die Flashware zwischenzuspeichern. Das Steuergerät, welches die Flashware zwischenspeichert, muss in der Lage sein, die Flashware nach dem Flashen hinsichtlich Authentizität und Integrität zu testen. Erst wenn diese Tests positiv verlaufen sind, darf das zwischenspeichernde Steuergerät die Flashware an das Zielsteuergerät weitergeben. Dieses überschreibt direkt den Speicherplatz, der die alte Flashware beinhaltet, mit der neuen Flashware. Schlägt einer dieser Tests trotz der vorherigen Prüfung in dem zwischenspeichernden Steuergerät fehl, so kann der ursprüngliche Zustand des Steuergerätes nicht wiederhergestellt werden. Aus diesem Grund muss der Übertragungskanal zwischen beiden Steuergeräten bestmöglich abgesichert sein, um durch diesen Mechanismus eine fehlerfreie Einspielung der Flashware zu garantieren. Kann die Sicherheit des Übertragungskanals nicht garantiert werden, so wäre das Zwischenspeichern der Flashware auf einem zweiten Steuergerät hinfällig. Auch hier ist die Zuverlässigkeit des zwischenspeichernden Steuergerätes ausschlaggebend für die Funktionalität dieses Backup-Ansatzes. Ist dieses Steuergerät nicht in der Lage die Flashware fehlerfrei abzulegen und wird ein Fehler nicht bemerkt, so ist auch in diesem Fall die fehlerfreie Einspielung der Flashware nicht gewährleistet.
    • Backup vier (B4): Backup nicht möglich
      Die letzte Backup-Klasse beschreibt den Fall, dass der Speicher des zu flashenden Gerätes zu klein ist, um ein Backup der aktuell eingespielten Flashware anlegen zu können. Weiterhin gibt es keine Möglichkeit auf einem anderen Gerät ein Backup anzulegen (B2) oder ein anderes Gerät als Zwischenspeicher zu verwenden (B3). Wenn nicht die Möglichkeit besteht ein Backup der aktuell eingespielten Flashware anzulegen, kann bei einem fehlerhaften Flashprozess der ursprüngliche Zustand des Steuergerätes nicht mehr hergestellt werden. Das Steuergerät ist in diesem Fall durch den Flashprozess nicht mehr einsatzfähig. Die nachfolgend beschriebenen Safety-Klassen SK0 bis SK5 sind aufwärtskompatibel, d.h. wird ein Steuergerät in eine niedrigere Safety-Klasse (größere Zahl -> kleinere Sicherheitserfordernis) eingeteilt, so können die möglichen Flashprozesse der höheren Safety-Klassen auch zugelassen werden. Ein Steuergerät in Safety-Klasse SK5 kann daher, mit Hilfe der durch die Safety-Klasse beschriebenen fünf verschiedenen Flashprozesse geflasht werden. Die Art der Flashdaten wird für die Einteilung der Steuergeräte in die Safety-Klassen in diesem Ausführungsbeispiel nicht berücksichtigt. Dies liegt daran, dass zum einen die Flashdaten keinen Einfluss in Bezug auf die Betriebssicherheit haben. Sowohl ein Teil des Betriebssystems, als auch eine Applikation oder Parameter können im Fehlerfall die Betriebssicherheit des Fahrzeuges beeinflussen. Zum anderen werden in diesem Ausführungsbeispiel Steuergeräte als ganzes betrachtet, ohne eine Unterscheidung nach ihren einzelnen Funktionalitäten. Würden einzelne Funktionalitäten des Steuergerätes betrachtet werden, so könnte es vorkommen, dass ein Steuergerät in verschiedene Safety-Klassen eingeteilt werden müsste. Dieses Gerät müsste dann in Abhängigkeit der durch den Flashvorgang veränderten Funktionalität entscheiden, ob es den Flashvorgang im aktuellen Zustand zulässt oder nicht.Die nachfolgend aufgeführten sechs Safety-Klassen SK0 bis SK5 werden bevorzugt für die einzelnen Steuergeräte vorgesehen:
    • Safety-Klasse null (SK0)
      Dieser Klasse werden Steuergerät zugeordnet, die aufgrund ihrer technischen Gegebenheiten oder anderer Anforderungen nicht flashbar sind. Derartige Steuergeräte kommen für den Einsatz des erfindungsgemäßen Verfahrens nicht in Frage.
    • Safety-Klasse eins (SK1)
      Dieser Klasse werden Steuergeräte zugeordnet, die bezüglich der Betriebssicherheit hochkritisch sind. Für diese Steuergeräte ist ein Flashen nur in einer Werkstatt zugelassen. Nach dem Flashen und vor dem eigentlichen Fahrzeugbetrieb werden umfangreiche Tests und Diagnosen von geschultem Personal durchgeführt, um die Fehlerwahrscheinlichkeit so klein wie möglich zu halten. Werden bei diesen Tests Fehler entdeckt, so kann das Fachpersonal entsprechend reagieren und den Fehler beheben. Die korrekte Durchführung einer manuellen Initialisierung in der Werkstatt ist gewährleistet, so dass diese Art der Initialisierung nur in dieser Safety-Klasse zugelassen ist. Steuergeräte, die dieser Safety-Klasse zugeordnet sind, dürfen nur dann in den Zustand "Flashen" übergehen, wenn in der Werkstatt ein Tester an das Fahrzeug angeschlossen ist. Ob der Motor in diesem Zustand läuft oder nicht, ist in diesem Fall nachgeordnet. Ein Backup ist möglich, wird aber nicht gefordert, weil durch organisatorische Maßnahmen gewährleistet wird, dass ein Fahrzeug nicht in Betrieb genommen wird, ohne das entsprechende Gerät ausführlich getestet zu haben. Außerdem besteht in der Werkstatt die Möglichkeit im Notfall eine alte, funktionsfähige Version der Flashware in das Steuergerät einzuspielen oder das Steuergerät im Falle eines größeren Defektes komplett durch ein neues zu ersetzten. Den Zustand "Flashen" dürfen die Steuergeräte nur dann verlassen, wenn ihnen dieses über den entsprechenden Befehl des Testers mitgeteilt wurde.
    • Safety-Klasse zwei (SK2)
      Dieser Klasse werden Steuergeräte zugeordnet, die bezüglich der Betriebssicherheit kritisch sind. In dieser Safety-Klasse wird der Flashvorgang über die Luftschnittstelle durchgeführt und von einer Zentrale überwacht. Ein Flashprozess ist auch außerhalb einer Werkstatt zugelassen. Dabei darf sich das Fahrzeug allerdings nicht in Bewegung befinden. Dies wird durch die Forderung, dass der Motor nicht an sein darf, erreicht. Durch die Überwachung des Flashvorganges über die Luftschnittstelle kann auch in dieser Safety-Klasse von einer minimierten Fehlerwahrscheinlichkeit ausgegangen werden. Wird ein Fehler entdeckt, so sind die Eingriffsmöglichkeiten der Zentrale auf Grund der Entfernung zum geflashten Fahrzeug jedoch begrenzt. Aus diesem Grund wird in dieser Klasse entweder das Anlegen eines Backups gefordert, das bei Ausfall der Verbindung über die Luftschnittstelle automatisiert wieder eingespielt wird. Andererseits kann auf das Anlegen eines Backups verzichtet werden, wenn durch den Zustand "Flashen" des Steuergerätes ein Motorstart verhindert wird. Solange wie die Zentrale dann den Zustand "Flashen" des Steuergerätes nicht beendet, darf eine Inbetriebnahme des Fahrzeuges nicht mehr möglich sein. Wie aus dem letzten Abschnitt hervorgeht, dürfen Steuergerät in dieser Safety-Klasse nur mit einer Online-Verbindung über die Luftschnittstelle geflasht werden. Entscheidend in dieser Safety-Klasse ist die Möglichkeit der Überwachung des Flashvorganges durch die Zentrale über die Luftschnittstelle. Den Zustand "Flashen" verlassen die Steuergeräte, wenn ihnen über die Luftschnittstelle der Befehl hierzu erteilt wird. Wird die Verbindung über die Luftschnittstelle unterbrochen, so wird versucht das Backup wiedereinzuspielen, um daraufhin den Zustand "Flashen" verlassen zu können. Existiert kein Backup oder kann dieses nicht eingespielt werden, so verweilt das Steuergerät in dem Zustand solange bis es über die Luftschnittstelle oder einen zur Fehlerbehebung angeschlossenen Tester eine korrekte Flashware erhält. Als Initialisierungsvariante für das geflashte Steuergerät ist in dieser Safety-Klasse nur die automatische oder keine zugelassen, da ein Fehler bei der manuellen Initialisierung die Funktionalität des Steuergerätes gefährden kann. Dieses darf nicht zugelassen werden, da sich in dieser Safety-Klasse Steuergeräte befinden, die für die Betriebssicherheit des Fahrzeuges wichtig sind. Dass vor dem Flashvorgang kein Backup angelegt wird, kann nur zugelassen werden, wenn es dem Steuergerät möglich ist den Motorstart zu verhindern, bis das Steuergerät von der Zentrale wieder freigeschaltet wurde.
    • Safety-Klasse drei (SK3)
      Dieser Klasse werden Steuergeräte zugeordnet, die bezüglich der Betriebssicherheit kritisch sind. In dieser Safety-Klasse werden die Steuergerät vom Fahrzeugnutzer ohne Überwachung durch eine Zentrale durchgeführt. Ein Flashprozess ist auch außerhalb einer Werkstatt zugelassen. Das Fahrzeug darf sich nicht in Bewegung befinden. Diese Forderung wird dadurch erfüllt, dass der Motor während eines Flashvorganges in dieser Safety-Klasse nicht angeschaltet sein darf. In dieser Safety-Klasse führt der Fahrzeugnutzer den Flashvorgang mit Hilfe einer in ein Laufwerk im Fahrzeug eingelegten CD selbstständig aus. Es besteht in dieser Klasse keine Zugriffsmöglichkeit auf geschultes Personal. Da die Test- und Diagnosemöglichkeiten nach einem solchen Flashvorgang begrenzt sind und nicht durch organisatorische Maßnahmen gewährleistet werden können, muss ein Backup vorgesehen werden, damit im Fehlerfall das Gerät wieder in den Zustand vor dem Flashen versetzt werden kann. Dabei ist hier nur ein internes Backup zugelassen. In dieser Safety-Klasse sind ebenso wie in SK2 nur die Initialisierungsklassen automatische Initialisierung (I2) oder keine Initialisierung (I3) zugelassen. Ein Fehler bei einer manuellen Initialisierung kann zu einer Gefährdung der korrekten Funktionalität des Steuergerätes, führen, die in dieser Safety-Klasse nicht akzeptiert werden kann. Der Zustand "Flashen" wird von den Steuergeräten in dieser Safety-Klasse entweder nach erfolgreicher Durchführung des Flashvorganges oder erfolgreicher Wiederherstellung des Ursprungszustandes durch das Wiedereinspielen des Backups verlassen. Die Zuordnung von Geräten zu der Safety-Klasse SK3 schließt ein Flashen in der Werkstatt jedoch nicht aus.
    • Safety-Klasse vier (SK4)
      Dieser Klasse werden Steuergeräte zugeordnet, die bezüglich der Betriebssicherheit nicht sensibel sind. Diese Steuergeräte unterliegen allerdings der Forderung, dass durch einen Flashvorgang kein Steuergeräteausfall verursacht werden darf. Für diese Steuergeräte ist ein Download außerhalb einer Werkstatt sowohl in beiden Ruhezuständen (Z3, Z4) als auch im Fahrbetrieb (Z2) zugelassen. Um die Gerätefunktionalität nach einem Flashprozess zu garantieren, muss entweder ein internes Backup(B1), ein externes Backup (B2) oder eine Zwischenspeicherung der Flashdaten (B3) vorgesehen werden, damit im Fehlerfall das Steuergerät in den Zustand vor dem Flashen versetzt werden kann oder im Falle von B3 in diesem Zustand bleibt. Dabei wird vorausgesetzt, dass die Verbindung zwischen dem geflashten Steuergerät und dem externen Backupgerät fehlerfrei funktioniert. Ein Einschränkung auf lediglich das interne Backup (B1) wie in der SK3, ist an dieser Stelle nicht notwendig, da die Funktionalität des Steuergerätes bezüglich der Betriebssicherheit nicht sensibel ist. Die Forderung, dass die Funktionalität des Steuergerätes garantiert werden soll, hat für die Sicherheit der Insassen nicht den gleichen Stellenwert, wie bei einem Steuergerät, das für die Betriebssicherheit ausschlaggebend ist. An dieser Stelle könnten auch die Backupmöglichkeiten B2 und B3 zugelassen werden. Eine manuelle Initialisierung des geflashten Steuergerätes kann in dieser Safety-Klasse nicht zugelassen werden, da die korrekte Durchführung der Initialisierung nicht' gewährleistet werden kann. Fehler während des Initialisierungsvorganges können zu Funktionsfehlern im Steuergerät führen, was der Forderung dieser Safety-Klasse, die Funktionalität des Steuergerätes nach dem Flashvorgang zu garantieren, wiedersprechen würde. Der Zustand "Flashen" wird von den Steuergeräten in dieser Safety-Klasse entweder nach erfolgreicher Durchführung des Flashvorganges oder erfolgreicher Wiederherstellung des Ursprungszustandes durch das Wiedereinspielen des Backups verlassen. Für die Datenübertragung außerhalb einer Werkstatt können alle Flashwege verwendet werden, für die kein Tester benötigt wird. Auf die Überwachung des Flashvorganges auf der Luftschnittstelle kann in dieser Safety-Klasse verzichtet werden. Die Zuordnung von Geräten zu der Safety-Klasse SK4 schließt ein Flashen in der Werkstatt jedoch nicht aus.
    • Safety-Klasse fünf (SK5)
      Dieser Klasse werden Steuergeräte zugeordnet, die bezüglich der Betriebssicherheit nicht sensibel sind und deren Funktionalität nach einem Flashvorgang nicht garantiert werden muss. Für diese Steuergeräte ist ein Flashen außerhalb einer Werkstatt sowohl in den beiden Ruhezuständen (Z3, Z4) als auch im Fahrbetrieb (Z2) zugelassen. Da in dieser Safety-Klasse nicht gefordert wird, dass man das Steuergerät nach einem Flashprozess im Fehlerfall wieder in einen funktionsfähigen Zustand versetzten muss, ist das Anlegen eines Backups nicht erforderlich. In dieser Safety-Klasse gibt es keine speziellen Anforderungen an den Initialisierungsvorgang, da hier keine Forderungen an die Funktionalität des Steuergerätes gestellt werden. Eine manuelle Initialisierung kann demnach ohne den Forderungen der Safety-Klasse zu wiedersprechen zugelassen werden. Den Zustand "Flashen" kann ein Steuergerät dieser Safety-Klasse jederzeit wieder verlassen. Für die Datenübertragung außerhalb einer Werkstatt können alle Flashwege verwendet werden, für die kein Tester benötigt wird. Auf die Überwachung des Flashvorganges auf der Luftschnittstelle kann in dieser Safety-Klasse verzichtet werden. Die Zuordnung von Geräten zu der Safety-Klasse SK5 schließt ein Download in der Werkstatt jedoch nicht aus. Fig. 3 zeigt eine Tabelle in der Anforderungen an die technische Ausführung der Steuergeräte in Abhängigkeit von deren Sicherheitsklasse angegeben sind. Im Rahmen dieser technischen Ausführungen der Steuergeräte werden auch die Ausprägungen der in einem erfindungsgemäßen Steuergerät vorgesehenen Mittel zur Prüfung der vorgegebenen Programmdatenübernahmesituationen spezifiziert.
      Die einzelnen Safety-Klassen unterscheiden sich in den Anforderungen, die sie an das jeweilige Steuergerät in der entsprechenden Klasse stellen. In der dargestellten Tabelle sind die Anforderungen aus den nachfolgend angeführten Anforderungen A1 bis A20, aufgelistet, die ein Steuergerät erfüllen muss, wenn es in eine bestimmte Safety-Klasse eingeteilt werden soll. Dabei sind nur die Anforderungen aufgelistet, die zwingend erforderlich sind. So ist es zum Beispiel in der Safety-Klasse SK5 nicht unbedingt notwendig, dass ein Steuergerät ein Backup anlegen kann. Die Anforderung A10 ist in der Tabelle daher nicht mit aufgeführt. Erfüllt ein Steuergerät jedoch diese Anforderung so ist dies kein Hinderungsgrund das Steuergerät in die Safety-Klasse SK5 einzuteilen. Wird ein Steuergerät in eine dieser Safety-Klassen eingeteilt, so müssen mindestens die in der Tabelle gestellten Anforderungen durch das Steuergerät erfüllt werden. Kann ein Steuergerät diese Anforderungen nicht erfüllen, so muss es in eine andere Safety-Klasse mit geringeren Anforderungen eingeteilt werden.Die für in die beschriebenen Safety-Klassen eingeordneten Steuergeräte, in Abhängigkeit von deren Safety-Klasse, gemäß der Tabelle geforderten Anforderungen, sind die folgenden:
    • Anforderung eins (A1): Zustand "Flashen"
      Jedes der erfindungsgemäßen Steuergerät muss einen Betriebszustand "Flashen" besitzen, in den es nur gelangt, wenn die durch die Safety-Klasse vorgeschriebenen Rahmenbedingungen erfüllt sind. Der Zustand "Flashen" wird ebenfalls nur dann verlassen, wenn die durch die Safety-Klasse vorgeschriebenen Bedingungen erfüllt sind.
    • Anforderung zwei (A2): Tester angeschlossen
      Das Steuergerät muss eindeutig feststellen können, ob ein Tester an das interne Fahrzeugnetzwerk angeschlossen ist oder nicht. Diese Information muss bei der Übertragung über das interne Netzwerk derart abgesichert sein, dass eine Verfälschung dieser Information von außen unmöglich ist. Wäre dies nicht der Fall, könnte einem Steuergerät, an das der Tester nicht direkt angeschlossen wird, ein angeschlossener Tester gemeldet werden, ohne dass wirklich ein Tester angeschlossen wäre.
    • Anforderung drei (A3): Autarkes Flashen von einer CD
      Das Steuergerät muss in der Lage sein Flashware von einer CD zu lesen und diese korrekt in seinen Flashspeicher zu schreiben. Dabei darf es keine Rolle spielen, ob die CD in einem dem Steuergerät eigenen CD-Laufwerk eingelegt ist oder in dem CD-Laufwerk eines externen Steuergerätes eingelegt ist. In beiden Fällen muss das geflashte Steuergerät in der Lage sein ohne die Verbindung zum Tester selbständig einen Flashprozess durchzuführen.
    • Anforderung vier (A4): Flashen über die Luftschnittstelle Das Steuergerät muss in der Lage sein die Flashware, die über die Luftschnittstelle in das Fahrzeug geladen wird, korrekt in seinen Flashspeicher zu schreiben. Ob die Verbindung zur Luftschnittstelle im Gerät selber oder in einem externen Gerät implementiert ist darf dabei keine Rolle spielen. Das Steuergerät muss den Flashvorgang unabhängig von einer Verbindung zum Tester selbständig durchführen können.
    • Anforderung fünf (A5): Motor aus
      Das Steuergerät muss über das interne Fahrzeugnetzwerk oder seine eigene Funktion feststellen können, ob der Motor des Fahrzeuges läuft oder nicht. Bei einer Übermittlung dieser Information über das interne Fahrzeugnetzwerk muss diese Kommunikation gegen Manipulation von außen derart gesichert sein, dass hier keine gezielte Fehlinformation von dem Gerät akzeptiert werden darf. Dies ist besonders wichtig in den Safety-Klassen SK2 und SK3, da der Motor in diesen Klassen unter keinen Umständen laufen darf, weil dann die Sicherheit der Insassen gefährdet sein kein. Die Übertragung über das interne Fahrzeugnetzwerk muss an dieser Stelle ausreichend gesichert werden, weil ansonsten die Intension des Safety-Klassen-Konzeptes ausgehebelt würde.
    • Anforderung sechs (A6): Zündung aus
      Das Steuergerät muss über das interne Fahrzeugnetzwerk oder seine eigene Funktion feststellen können, ob die Zündung des Fahrzeuges an ist oder nicht. Wird diese Information über das interne Fahrzeugnetzwerk übertragen, so muss diese Übertragung gegen Manipulation von außen gesichert werden, da ansonsten die im Safety-Klassen-Konzept gemachten Festlegungen ausgehebelt werden könnten.
    • Anforderung sieben (A7): Verhindern Motor an
      Das Steuergerät muss in der Lage einen Motorstart zu verhindern, solange es noch geflasht wird, und/oder noch kein sicherer Betriebszustand erreicht wurde. Dies ist vor allem für Steuergeräte wichtig, deren Funktionalität kritisch für die Betriebssicherheit des Fahrzeuges ist.
    • Anforderung acht (A8): Flashdaten
      Das Steuergerät muss vor einem Flashen bestimmen können, welche Daten im internen Flashspeicher überschrieben werden bzw. welche Bereiche des Flashspeichers neu belegt werden. Dies ist notwendig, damit das Steuergerät die für das Anlegen eines Backups notwendigen Informationen bestimmen kann.
    • Anforderung neun (A9): internes Backup
      Das Steuergerät muss ein internes Backup anlegen können. Hierzu muss es zunächst bestimmen können, ob im eigenen Flashspeicher für das interne Backup noch ausreichend Platz zur Verfügung steht. Hierzu benötigt das Steuergerät die Informationen, die aus der Anforderung A8 gewonnen werden. Nur mit der Information, von welchen Daten ein Backup angelegt werden muss bzw. wie viel neuer Speicher durch das Flashen belegt wird, kann das Steuergerät über das Anlegen eines internen Backups entscheiden. Neben der Entscheidung über die Möglichkeit des Anlegens eines internen Backups, muss das Gerät in der Lage sein, ein internes Backup anzulegen und dieses im Fehlerfall auch wieder zurückzuspielen.
    • Anforderung zehn (A10): externes Backup
      Das Steuergerät muss in der Lage sein, ein Backup auf einem externen Gerät anzulegen. Hierzu muss es anhand der durch die Anforderung A8 gewonnen Informationen die Daten bestimmen, von denen ein Backup angelegt werden muss. Des weiteren muss ein externes Steuergerät mit ausreichend Ressourcen zur Verfügung stehen, welches das Backup in seinem Speicher anlegen kann. Bei dieser Form des Backups spielt auch die Sicherheit und Fehlertoleranz des internen Fahrzeugnetzwerkes eine Rolle. Nur durch eine sichere und fehlerfreie Übertragung kann garantiert werden, dass das Backup im Fehlerfall wieder zurückgespielt werden kann. Das Steuergerät muss dabei auf die Funktionsfähigkeit des externen Steuergerätes vertrauen und kann nur beschränkt durch eigenen Maßnahmen zum Erfolg des Backups beitragen.
    • Anforderung elf (A11): Pufferung der Daten auf einem externen Steuergerät (Zielgerät)
      Das Steuergerät muss feststellen können, ob die Daten auf einem anderen Steuergerät zwischen gespeichert worden sind. Weiterhin muss es feststellen können, ob dieses Steuergerät die notwendigen Prüfungen hinsichtlich Integrität und/oder Authentizität der Programmdaten durchgeführt hat. Erst dann darf das Steuergerät den Download der Flashdaten zulassen. Dabei spielt auch hier die Sicherheit des internen Fahrzeugnetzes eine entscheidende Rolle. Kann sich das Steuergerät nicht auf die Authentizität des zwischenspeichernden Steuergerätes verlassen, darf es den Download in einer der Safety-Klassen (SK2 od. SK4) , die ein Backup vorschreiben, nicht zulassen.
    • Anforderung zwölf (A12): Pufferung der Daten auf einem externen Steuergerät (Zwischengerät)
      Das Steuergerät, welches zur Pufferung der Flashdaten zum Download herangezogen wird, muss vor der Weiterleitung der Flashdaten vorgeschriebenen Prüfungen hinsichtlich Authentizität und/oder Integrität an der Flashware vornehmen. Dies bedeutet vor allem, dass für das zwischenspeichernde Steuergerät die gleichen hinsichtlich Authentizität und/oder Integrität gelten, wie für das Zielgerät. Weiterhin müssen dem Zwischengerät auch geheime Informationen, wie zum Beispiel kryptografische Schlüssel, des Zielgerätes bekannt sein. Wäre dies nicht der Fall könnte das Zwischengerät zum Beispiel keine Signaturprüfung durchführen. Auf diese Forderung kann für den Fall verzichtet werden, wenn dem Einspielen der Software in den Zwischenspeicher eine kryptographische Authentisierung einer Zentrale am zwischenspeichernden Steuergerät zwingend vorgeschaltet ist. In diesem Fall kann durch die vorgelagerte Authentisierung von einer vertrauenswürdigen Quelle ausgegangen werden. Ein Test auf technische Übertragungsfehler sollte allerdings trotzdem auf dem zwischenspeichernden Steuergerät vorgesehen'werden, damit ein solcher Fehler nicht zu einem fehlerhaften Flashprozess führen kann, der das geflashte Steuergerät in einen undefinierten Zustand versetzt.
    • Anforderung dreizehn (A13): Automatisches Wiedereinspielen eines Backups
      Das Steuergerät muss in der Lage sein im Fehlerfall ein vorher angelegtes Backup automatisiert wieder einzuspielen. Die vorher eingespielten Daten müssen ebenfalls automatisch wieder gelöscht werden.
    • Anforderung vierzehn (A14): Löschen eines Backups
      Das Steuergerät auf dem ein Backup angelegt wird, sei es intern, extern oder als Zwischenspeicher, muss in der Lage sein das eingespielte Backup wieder zu löschen. Hierzu bedarf es bei einem erfolgreich durchgeführten Flashvorgang der Information des geflashten Steuergerätes. War ein Flashvorgang nicht erfolgreich, darf das Backup erst nach erfolgreichem Wiedereinspielen in das geflashte Steuergerät gelöscht werden.
    • Anforderung fünfzehn (A15): Erkennen des Initialisierungsverfahrens
      Ein Steuergerät muss vor der Durchführung eines Flashvorganges bestimmen können, welches Initialisierungsverfahren die eingespielte Flashware nach der Einspielung benötigt. Anhand dieser Information kann das Steuergerät entscheiden, ob es den Flashvorgang zulassen darf oder nicht.
    • Anforderung sechzehn (A16): manuelle Initialisierung
      Bedarf ein Steuergerät nach einem Flashvorgang einer manuellen Initialisierung, müssen die zur Initialisierung notwendigen Schritte dem Flashenden in einer Anzeigekomponente im Fahrzeug ausreichend detailliert dargestellt werden. Dabei kann das Weiterschalten von einem Initialisierungsschritt zum nächsten entweder vom Steuergerät automatisch oder durch manuelle Bestätigung durch den Anwender geschehen. Die Kommunikation zwischen der Anzeigekomponente und dem geflashten Steuergerät muss dabei derart abgesichert sein, dass hier keine fehlerhaften Informationen fehlerhafte Informationen übermittelt, ist auch der Erfolg der manuellen Initialisierung gefährdet. Den Zustand "Flashen" darf dieses Steuergerät erst verlassen, wenn die manuelle Initialisierung vollständig durchgeführt wurde. Der Initialisierungsvorgang muss dementsprechend in den Flashprozess integriert werden.
    • Anforderung siebzehn (A17): automatische Initialisierung
      Ein Steuergerät, dass eine automatische Initialisierung bietet, muss diese ohne weiteren Zwischenschritt direkt nach Beendigung des eigentlichen Flashvorganges durchführen. Dabei muss diese Initialisierung auf jeden Fall beendet werden können. So darf z.B. das Ausschalten der Zündung keine Auswirkung auf die Fortführung des Initialisierungsvorganges haben. Den Zustand "Flashen" darf dieses Steuergerät erst verlassen, wenn die automatische Initialisierung vollständig durchgeführt wurde. Der Initialisierungsvorgang muss dementsprechend in den Flashprozess integriert werden.
    • Anforderung achtzehn (A18): Anzeige von Fehlermeldungen Kommt es während des Flashprozesses zu Fehlern, so müssen die daraus resultierenden Fehlermeldungen auf einer Anzeigekomponente im Fahrzeug so lange angezeigt werden, bis sie an der Anzeigekomponente durch den Fahrzeugnutzer bestätigt werden. Dabei darf ein vorübergehender Stromausfall oder andere Zustandsänderungen des Steuergerätes die Anzeige der Fehlermeldung nicht beeinflussen. Die Kommunikation zwischen der Anzeigekomponente und dem geflashten Steuergerät muss derart abgesichert sein, dass hier keine fehlerhaften Informationen übermittelt werden können. Ein fehlerhafte Informationsübermittlung kann an dieser Stelle die Information an den Flashenden über den aufgetretenen Fehler unterbinden. Den Zustand "Flashen" darf das Steuergerät erst verlassen, wenn der Fahrzeugnutzer die Fehlermeldung durch eine entsprechende manuelle Handlung bestätigt hat. Das Anzeigen der Fehlermeldung auf der Anzeigekomponente muss dementsprechend in den Flashprozess integriert werden.
    Hierzu 3 Seiten Figuren Bezugszeichenliste
    1
    Sicherheitsklasseneinordnung
    2
    Programmdatenspeicher
    3
    Mittel zum Übernehmen von Programmdaten
    4
    Authentizitätsprüfung
    5
    Übergang in Programmdatenübernahmezustand
    6
    Mittel zur Prüfung vorgegebener Programmdatenübernahmesituationen im Steuergerät
    7
    Programmdatenübernahme
    8
    Kontrolle der Programmdatenübernahme durch Tester oder Datenübernahmekontrollzentrale
    9
    Programmdatenübergabestelle
    10
    Datenübernahmekontrollzentrale
    11
    Programmdatenübernahmeanfrage
    20
    Abfrage der Sicherheitsklasseneinordnung
    31, 32, 33, 34, 35
    Programmdatenübernahmesituationen
    40
    Programmdatenweitergabe
    50
    Steuergerät
    61
    Mittel zur Prüfung vorgegebener Programmdatenübernahmesituationen in der Programmdatenübergabestelle
    101
    Prüfung der Programmdatenübernahmesituationen "Kommunikationsverbindung mit Tester oder Datenübernahmekontrollzentrale"
    102
    Prüfung der Programmdatenübernahmesituätionen durch das Steuergerät
    103
    Abfrage der Programmdatenübernahmesituationsprüfungsergebnisse der Programmdatenübergabestelle
    104
    Prüfung der Programmdatenübernahmesituationen durch die Datenübergabestelle

    Claims (13)

    1. Verfahren zum Übernehmen von Programmdaten durch ein Steuergerät in einem Kraftfahrzeug, wobei die Programmdaten von einer Datenübergabestelle bereit gestellt werden, mit den Schritten,
      Abgeben einer Programmdatenübernahmeanfrage an das Steuergerät,
      Übertragen der Programmdaten an das Steuergerät, und
      Übernehmen der Programmdaten durch das Steuergerät,
      dadurch gekennzeichnet, dass das Steuergerät erst dann in einen Programmdatenübernahmezustand, in welchem die Programmdaten durch das Steuergerät übernommen werden, übergeht, nachdem von dem Steuergerät geprüft wurde, ob für das Steuergerät vorgegebene programmdatenunabhängige Programmdatenübernahmesituationen bestehen.
    2. Verfahren nach Anspruch 1
      dadurch gekennzeichnet, dass von der Datenübergabestelle geprüft wird, ob für das Steuergerät vorgegebene Programmdatenübernahmesituationen bestehen bevor die Programmdaten bereit gestellt werden.
    3. Verfahren nach Anspruch 1 und 2
      dadurch gekennzeichnet, dass das Prüfen durch das Steuergerät, ob die für das Steuergerät vorgegebenen Programmdatenübernahmesituationen bestehen, eine Abfrage des Prüfungsergebnisses der Datenübergabestelle beinhaltet.
    4. Verfahren nach mindestens einem der Ansprüche 1 bis 3
      dadurch gekennzeichnet, dass vom Steuergerät und/oder der Datenübergabestelle, durch Abfrage einer Sicherheitsklasseneinordnung des Steuergerätes, festgestellt wird, welche Programmdatenübernahmesituationen für das Steuergerät bestehen müssen.
    5. Verfahren nach mindestens einem der Ansprüche 1 bis 4
      dadurch gekennzeichnet, dass die Programmdatehübernahmesituationen vom Fahrzeugzustand und/oder dem Datenübertragungsweg und/oder Steuergeräteprogramminitialisierungsmöglichkeiten und/oder Steuergeräteprogrammsicherungsmöglichkeiten und/oder der Art der zu übernehmenden Daten abhängen.
    6. Verfahren nach mindestens einem der Ansprüche 1 bis 5
      dadurch gekennzeichnet, dass als Programmdatenübernahmezustand vom Steuergerät und/oder der Datenübergabestelle geprüft wird, ob der Motor des Kraftfahrzeuges in Betrieb ist und/oder eine Kommunikationsverbindung zwischen dem Steuergerät und einem Tester und/oder einer Datenübernahmekontrollzentrale besteht.
    7. Verfahren nach Anspruch 6
      dadurch gekennzeichnet, dass während sich das Steuergerät im Datenübernahmezustand befindet der Start des Motors des Kraftfahrzeuges vom Steuergerät oder von der . Datenübergabestelle verhindert wird und/oder der Datenübernahmezustand durch das Steuergerät nur nach Empfang eines Datenübernahmebeendigungsbefehls von dem Tester oder der Datenübernahmekontrollzentrale wieder verlassen wird.
    8. Verfahren nach mindestens einem der Ansprüche 1 bis 7
      dadurch gekennzeichnet, dass die Datenübergabestelle die Programmdaten zwischenspeichert bis die vorgegebenen Programmdatenübernahmesituationen des Steuergerätes, für welches die Programmdaten bestimmt sind, bestehen.
    9. Verfahren nach mindestens einem der Ansprüche 1 bis 8
      dadurch gekennzeichnet, dass die Datenübergabestelle als Fahrzeugbauteil ausgeprägt ist, wobei die Datenübergabestelle die Programmdaten von einer externen Quelle übernimmt.
    10. Verfahren nach mindestens einem der Ansprüche 1 bis 9
      dadurch gekennzeichnet, dass ein Authentizitätsprüfen der Programmdaten vom Steuergerät oder von der Datenübergabestelle durchgeführt wird.
    11. Verfahren nach Anspruch 10
      dadurch gekennzeichnet, dass das Authentizitätsprüfen der Programmdaten durch überprüfen einer Signatur mittels eines öffentlichen Schlüssels durchgeführt wird, wobei ein Schlüsselpaar zum Ver- und Entschlüsseln der Programmdaten, bestehend aus einem geheimen und dem öffentlichen Schlüssel verwendet wird und die Programmdaten mit dem geheimen Schlüssel signiert wurden.
    12. Steuergerät für eine Komponente eines Kraftfahrzeuges mit,
      Mitteln zum Übernehmen von Programmdaten von einer Datenübergabestelle
      dadurch gekennzeichnet, dass Mittel zur Überprüfung vorgegebener Programmdatenübernahmesituationen im Steuergerät vorgesehen sind.
    13. Datenübergabesystem zur Übertragung von Programmdaten an ein Steuergerät in einem Kraftfahrzeug mit
      einer Datenübergabestelle und
      einem Steuergerät mit Mitteln zum Übernehmen von Programmdaten von der Datenübergabestelle
      dadurch gekennzeichnet, dass Mittel zur Überprüfung vorgegebener Programmdatenübernahmesituationen im Steuergerät und in der Datenübergabestelle vorgesehen sind, wobei die Mittel zur Überprüfung vorgegebener Programmdatenübernahmesituationen im Steuergerät eingerichtet sind, um die Prüfungsergebnisse, der Überprüfung vorgegebener Programmdatenübernahmesituationen in der Datenübergabestelle, abzufragen.
    EP03003020A 2002-03-23 2003-02-12 Verfahren und Vorrichtung zum Übernehmen von Daten Withdrawn EP1346881A3 (de)

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    DE10213165A DE10213165B3 (de) 2002-03-23 2002-03-23 Verfahren und Vorrichtung zum Übernehmen von Daten
    DE10213165 2002-03-23

    Publications (2)

    Publication Number Publication Date
    EP1346881A2 true EP1346881A2 (de) 2003-09-24
    EP1346881A3 EP1346881A3 (de) 2004-04-28

    Family

    ID=27771521

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP03003020A Withdrawn EP1346881A3 (de) 2002-03-23 2003-02-12 Verfahren und Vorrichtung zum Übernehmen von Daten

    Country Status (4)

    Country Link
    US (1) US6859718B2 (de)
    EP (1) EP1346881A3 (de)
    JP (1) JP2004005506A (de)
    DE (1) DE10213165B3 (de)

    Cited By (6)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    EP1869550A1 (de) * 2005-04-04 2007-12-26 Volvo Lastvagnar Ab Anordnung und verfahren zum programmieren von kraftfahrzeugen
    WO2010054920A1 (de) * 2008-11-11 2010-05-20 Continental Automotive Gmbh Vorrichtung zum steuern einer fahrzeugfunktion und verfahren zum aktualisieren eines steuergerätes
    EP2423887A1 (de) * 2010-08-26 2012-02-29 OBD Tuning GmbH Portable Vorrichtung zur Veränderung von Betriebsparameterwerten und/oder Firmware von elektronischen Steuerungseinrichtungen von Kraftfahrzeugen
    DE102013013621A1 (de) * 2013-08-15 2015-02-19 Bayerische Motoren Werke Aktiengesellschaft Sicherheitskonformer Kanalwechsel in intelligenten Transportsvstemen
    FR3083635A1 (fr) * 2018-07-04 2020-01-10 Psa Automobiles Sa Procede de controle a distance de l’etat du contact d’un vehicule.
    US10703309B2 (en) 2013-02-08 2020-07-07 Bayerische Motoren Werke Aktiengesellschaft Method and device for connecting a diagnostic unit to a control unit in a motor vehicle

    Families Citing this family (106)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US7343413B2 (en) 2000-03-21 2008-03-11 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
    US8380854B2 (en) 2000-03-21 2013-02-19 F5 Networks, Inc. Simplified method for processing multiple connections from the same client
    EP1590917B1 (de) * 2003-01-28 2010-12-15 Cellport Systems, Inc. Ein System und ein Verfahren zum Steuern des Zugriffs von Anwendungen auf geschützte Mittel innerhalb eines sicheren Fahrzeugtelematiksystems
    DE10316951A1 (de) * 2003-04-12 2004-10-21 Daimlerchrysler Ag Verfahren zur Überprüfung der Datenintegrität von Software in Steuergeräten
    DE10331874A1 (de) * 2003-07-14 2005-03-03 Robert Bosch Gmbh Fernprogrammieren eines programmgesteuerten Geräts
    US20050142509A1 (en) * 2003-12-29 2005-06-30 Kim Young S. Burner assembly for gas burners of radiant heating type
    DE102004005680A1 (de) * 2004-02-05 2005-08-25 Bayerische Motoren Werke Ag Vorrichtung und Verfahren zur Ansteuerung von Steuergeräten in einem Bordnetz eines Kraftfahrzeuges
    SE0400480L (sv) * 2004-02-26 2005-08-27 Movimento Ab Fordonsinterface
    FR2875920B1 (fr) * 2004-09-27 2007-01-05 Peugeot Citroen Automobiles Sa Procede de mise en oeuvre d'un logiciel telecharge dans un calculateur
    US8856370B2 (en) * 2004-11-05 2014-10-07 International Business Machines Corporation Concurrent flashing of data processing units in hierarchical networks
    US7706895B2 (en) 2005-02-25 2010-04-27 Rockwell Automation Technologies, Inc. Reliable messaging instruction
    JP2006285849A (ja) * 2005-04-04 2006-10-19 Xanavi Informatics Corp ナビゲーション装置
    US7233830B1 (en) 2005-05-31 2007-06-19 Rockwell Automation Technologies, Inc. Application and service management for industrial control devices
    JP2007011734A (ja) * 2005-06-30 2007-01-18 Denso Corp 車載制御装置
    EP1760618A1 (de) * 2005-08-30 2007-03-07 Fujitsu Siemens Computers GmbH Verfahren, Datenverarbeitungsvorrichtung und Computerprogrammprodukt zur Authentifizierung und Durchführung einer Wartungsfunktion
    DE102006056220B4 (de) * 2006-11-29 2011-12-15 Günter Fendt Verfahren zum Benachrichtigen von Kfz-Benutzern bei außerplanmäßigen amFahrzeug anstehenden Inspektionsarbeiten
    DE102007045255B4 (de) * 2007-09-21 2021-11-18 Volkswagen Ag Verfahren zur Herstellung eines Diagnosesystems, insbesondere für ein Kraftfahrzeug
    JP2009087107A (ja) * 2007-10-01 2009-04-23 Hitachi Ltd 車両用制御システム
    DE102007062675A1 (de) * 2007-12-24 2009-07-02 Magna Powertrain Ag & Co Kg Verfahren zur Ansteuerung einer Baueinheit
    US8806053B1 (en) * 2008-04-29 2014-08-12 F5 Networks, Inc. Methods and systems for optimizing network traffic using preemptive acknowledgment signals
    US8566444B1 (en) 2008-10-30 2013-10-22 F5 Networks, Inc. Methods and system for simultaneous multiple rules checking
    US8452599B2 (en) 2009-06-10 2013-05-28 Toyota Motor Engineering & Manufacturing North America, Inc. Method and system for extracting messages
    US10157280B2 (en) 2009-09-23 2018-12-18 F5 Networks, Inc. System and method for identifying security breach attempts of a website
    US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
    US9313047B2 (en) 2009-11-06 2016-04-12 F5 Networks, Inc. Handling high throughput and low latency network data packets in a traffic management device
    US8868961B1 (en) 2009-11-06 2014-10-21 F5 Networks, Inc. Methods for acquiring hyper transport timing and devices thereof
    US8237792B2 (en) 2009-12-18 2012-08-07 Toyota Motor Engineering & Manufacturing North America, Inc. Method and system for describing and organizing image data
    US9639688B2 (en) * 2010-05-27 2017-05-02 Ford Global Technologies, Llc Methods and systems for implementing and enforcing security and resource policies for a vehicle
    US9141625B1 (en) 2010-06-22 2015-09-22 F5 Networks, Inc. Methods for preserving flow state during virtual machine migration and devices thereof
    US10015286B1 (en) 2010-06-23 2018-07-03 F5 Networks, Inc. System and method for proxying HTTP single sign on across network domains
    US8908545B1 (en) 2010-07-08 2014-12-09 F5 Networks, Inc. System and method for handling TCP performance in network access with driver initiated application tunnel
    US8347100B1 (en) 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
    US8424621B2 (en) 2010-07-23 2013-04-23 Toyota Motor Engineering & Manufacturing North America, Inc. Omni traction wheel system and methods of operating the same
    US8732697B2 (en) 2010-08-04 2014-05-20 Premkumar Jonnala System, method and apparatus for managing applications on a device
    US9083760B1 (en) 2010-08-09 2015-07-14 F5 Networks, Inc. Dynamic cloning and reservation of detached idle connections
    US8630174B1 (en) 2010-09-14 2014-01-14 F5 Networks, Inc. System and method for post shaping TCP packetization
    US8886981B1 (en) 2010-09-15 2014-11-11 F5 Networks, Inc. Systems and methods for idle driven scheduling
    US8463909B1 (en) 2010-09-15 2013-06-11 F5 Networks, Inc. Systems and methods for managing server resources
    US8804504B1 (en) 2010-09-16 2014-08-12 F5 Networks, Inc. System and method for reducing CPU load in processing PPP packets on a SSL-VPN tunneling device
    US8959571B2 (en) 2010-10-29 2015-02-17 F5 Networks, Inc. Automated policy builder
    EP2633667B1 (de) 2010-10-29 2017-09-06 F5 Networks, Inc System und verfahren zur on-the-fly-protokollkonvertierung bei der ermittlung von richtliniendurchsetzungsinformationen
    US8725325B1 (en) * 2010-12-10 2014-05-13 Cybertran International Inc. Method of controlling emergency braking in fixed guideway transportation system using dynamic block control
    US8627467B2 (en) 2011-01-14 2014-01-07 F5 Networks, Inc. System and method for selectively storing web objects in a cache memory based on policy decisions
    US10135831B2 (en) 2011-01-28 2018-11-20 F5 Networks, Inc. System and method for combining an access control system with a traffic management system
    US9452735B2 (en) 2011-02-10 2016-09-27 Ford Global Technologies, Llc System and method for controlling a restricted mode in a vehicle
    US10145960B2 (en) 2011-02-24 2018-12-04 Ford Global Technologies, Llc System and method for cell phone restriction
    US8880289B2 (en) * 2011-03-17 2014-11-04 Toyota Motor Engineering & Manufacturing North America, Inc. Vehicle maneuver application interface
    US8522320B2 (en) 2011-04-01 2013-08-27 Ford Global Technologies, Llc Methods and systems for authenticating one or more users of a vehicle communications and information system
    US8938224B2 (en) 2011-05-12 2015-01-20 Ford Global Technologies, Llc System and method for automatically enabling a car mode in a personal communication device
    US8788113B2 (en) 2011-06-13 2014-07-22 Ford Global Technologies, Llc Vehicle driver advisory system and method
    US9246819B1 (en) 2011-06-20 2016-01-26 F5 Networks, Inc. System and method for performing message-based load balancing
    US10097993B2 (en) 2011-07-25 2018-10-09 Ford Global Technologies, Llc Method and apparatus for remote authentication
    US8849519B2 (en) 2011-08-09 2014-09-30 Ford Global Technologies, Llc Method and apparatus for vehicle hardware theft prevention
    DE102011117376A1 (de) 2011-10-28 2012-05-16 Daimler Ag Verfahren zum Übernehmen von Programmdaten per Telematik in ein Steuergerät eines Kraftfahrzeugs mit automatischem Abnahmetest
    US9270766B2 (en) 2011-12-30 2016-02-23 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
    US8855847B2 (en) 2012-01-20 2014-10-07 Toyota Motor Engineering & Manufacturing North America, Inc. Intelligent navigation system
    DE102012001047A1 (de) * 2012-01-20 2013-07-25 Daimler Ag Verfahren zur Aktualisierung von Daten, Funktionen und/oder Konfigurationseinstellungen eines Kraftfahrzeugsteuergeräts
    US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
    US9172753B1 (en) 2012-02-20 2015-10-27 F5 Networks, Inc. Methods for optimizing HTTP header based authentication and devices thereof
    US9231879B1 (en) 2012-02-20 2016-01-05 F5 Networks, Inc. Methods for policy-based network traffic queue management and devices thereof
    WO2013163648A2 (en) 2012-04-27 2013-10-31 F5 Networks, Inc. Methods for optimizing service of content requests and devices thereof
    US9569403B2 (en) 2012-05-03 2017-02-14 Ford Global Technologies, Llc Methods and systems for authenticating one or more users of a vehicle communications and information system
    DE102012010723A1 (de) 2012-05-30 2012-11-29 Daimler Ag Diagnoseverfahren und Diagnoseeinrichtung für ein Kraftfahrzeug
    DE102012023648B4 (de) * 2012-12-03 2016-09-15 Audi Ag Verfahren und System zum Aktualisieren von einem Steuergerät eines Kraftwagens
    DE102012023647B4 (de) * 2012-12-03 2016-09-22 Audi Ag Verfahren und System zum Aktualisieren eines Steuergeräts eines Kraftwagens
    US8866604B2 (en) 2013-02-14 2014-10-21 Ford Global Technologies, Llc System and method for a human machine interface
    US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
    US9688246B2 (en) 2013-02-25 2017-06-27 Ford Global Technologies, Llc Method and apparatus for in-vehicle alarm activation and response handling
    US8947221B2 (en) 2013-02-26 2015-02-03 Ford Global Technologies, Llc Method and apparatus for tracking device connection and state change
    US9141583B2 (en) 2013-03-13 2015-09-22 Ford Global Technologies, Llc Method and system for supervising information communication based on occupant and vehicle environment
    US9002536B2 (en) 2013-03-14 2015-04-07 Ford Global Technologies, Llc Key fob security copy to a mobile phone
    US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
    US10015143B1 (en) 2014-06-05 2018-07-03 F5 Networks, Inc. Methods for securing one or more license entitlement grants and devices thereof
    US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
    US10122630B1 (en) 2014-08-15 2018-11-06 F5 Networks, Inc. Methods for network traffic presteering and devices thereof
    US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
    US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
    US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
    US10249123B2 (en) 2015-04-09 2019-04-02 Ford Global Technologies, Llc Systems and methods for mobile phone key fob management
    US11350254B1 (en) 2015-05-05 2022-05-31 F5, Inc. Methods for enforcing compliance policies and devices thereof
    US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
    FR3041789B1 (fr) * 2015-09-29 2018-03-23 Psa Automobiles Sa. Procede de mise a jour de composants d'un vehicule
    US11757946B1 (en) 2015-12-22 2023-09-12 F5, Inc. Methods for analyzing network traffic and enforcing network policies and devices thereof
    US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
    US11178150B1 (en) 2016-01-20 2021-11-16 F5 Networks, Inc. Methods for enforcing access control list based on managed application and devices thereof
    US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
    JP6365572B2 (ja) 2016-03-14 2018-08-01 トヨタ自動車株式会社 車両用のソフトウェア管理システム、管理サーバ及び車両
    US10417839B2 (en) 2016-05-25 2019-09-17 Navigation Research Company System and method for vehicle assessment and uses thereof
    US10791088B1 (en) 2016-06-17 2020-09-29 F5 Networks, Inc. Methods for disaggregating subscribers via DHCP address translation and devices thereof
    US11063758B1 (en) 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
    US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
    US11496438B1 (en) 2017-02-07 2022-11-08 F5, Inc. Methods for improved network security using asymmetric traffic delivery and devices thereof
    US10791119B1 (en) 2017-03-14 2020-09-29 F5 Networks, Inc. Methods for temporal password injection and devices thereof
    US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
    US10931662B1 (en) 2017-04-10 2021-02-23 F5 Networks, Inc. Methods for ephemeral authentication screening and devices thereof
    US10972453B1 (en) 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
    US11343237B1 (en) 2017-05-12 2022-05-24 F5, Inc. Methods for managing a federated identity environment using security and access control data and devices thereof
    US11122042B1 (en) 2017-05-12 2021-09-14 F5 Networks, Inc. Methods for dynamically managing user access control and devices thereof
    US20190014026A1 (en) * 2017-07-05 2019-01-10 Ford Global Technologies, Llc Method and apparatus for ignition state monitoring
    US11122083B1 (en) 2017-09-08 2021-09-14 F5 Networks, Inc. Methods for managing network connections based on DNS data and network policies and devices thereof
    DE102017216965A1 (de) * 2017-09-25 2019-03-28 Siemens Aktiengesellschaft Installation von Software auf einem Datenverarbeitungssystem eines Fahrzeugs
    US11658995B1 (en) 2018-03-20 2023-05-23 F5, Inc. Methods for dynamically mitigating network attacks and devices thereof
    DE102019202681A1 (de) * 2018-03-29 2019-10-02 Robert Bosch Gmbh Steuergerät
    US11044200B1 (en) 2018-07-06 2021-06-22 F5 Networks, Inc. Methods for service stitching using a packet header and devices thereof
    DE102022211577A1 (de) 2022-11-02 2024-05-02 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Zuweisen von Software-Paketen
    DE102022211574A1 (de) 2022-11-02 2024-05-02 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Zuweisen von Software-Paketen

    Citations (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE19921845A1 (de) 1999-05-11 2000-11-23 Bosch Gmbh Robert Diagnosetestvorrichtung für Kraftfahrzeuge mit programmierbaren Steuergeräten
    DE10008974A1 (de) 2000-02-25 2001-09-06 Bayerische Motoren Werke Ag Signaturverfahren

    Family Cites Families (8)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE4013727C2 (de) * 1990-04-28 1999-03-11 Bayerische Motoren Werke Ag Steuervorrichtung für technische Anlagen und Maschinen
    DE4218804A1 (de) * 1992-06-06 1993-12-09 Vdo Schindling Einrichtung zur Darstellung, Aufbereitung und Speicherung von Informationen in einem Kraftfahrzeug
    DE19620885A1 (de) * 1996-05-23 1997-11-27 Bayerische Motoren Werke Ag Verfahren zum Aktualisieren von Daten und/oder Parametern eines Steuergeräts in einem Fahrzeug
    DE19625619C2 (de) * 1996-06-26 1998-04-16 Siemens Ag Verfahren zum Abspeichern von Daten in einem Kraftfahrzeug
    US6487717B1 (en) * 1999-01-15 2002-11-26 Cummins, Inc. System and method for transmission of application software to an embedded vehicle computer
    FR2805365B1 (fr) * 2000-02-22 2002-11-29 Peugeot Citroen Automobiles Sa Systeme de reprogrammation a distance d'au moins un calculateur d'un systeme informatique embarque a bord d'un vehicule automobile
    DE10037397A1 (de) * 2000-08-01 2002-02-14 Daimler Chrysler Ag Verfahren zum Laden von Software
    DE10038096A1 (de) * 2000-08-04 2002-02-14 Bosch Gmbh Robert Verfahren und System zur Übertragung von Daten

    Patent Citations (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE19921845A1 (de) 1999-05-11 2000-11-23 Bosch Gmbh Robert Diagnosetestvorrichtung für Kraftfahrzeuge mit programmierbaren Steuergeräten
    DE10008974A1 (de) 2000-02-25 2001-09-06 Bayerische Motoren Werke Ag Signaturverfahren

    Cited By (9)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    EP1869550A1 (de) * 2005-04-04 2007-12-26 Volvo Lastvagnar Ab Anordnung und verfahren zum programmieren von kraftfahrzeugen
    WO2010054920A1 (de) * 2008-11-11 2010-05-20 Continental Automotive Gmbh Vorrichtung zum steuern einer fahrzeugfunktion und verfahren zum aktualisieren eines steuergerätes
    EP2423887A1 (de) * 2010-08-26 2012-02-29 OBD Tuning GmbH Portable Vorrichtung zur Veränderung von Betriebsparameterwerten und/oder Firmware von elektronischen Steuerungseinrichtungen von Kraftfahrzeugen
    WO2012025244A1 (de) * 2010-08-26 2012-03-01 Obd Tuning Gmbh Portable vorrichtung zur veränderung von betriebsparameterwerten und/oder firmware von elektronischen steuerungseinrichtungen von kraftfahrzeugen
    US20130261839A1 (en) * 2010-08-26 2013-10-03 Obd Tuning Gmbh Portable device for changing operating parameter values and/or firmware of electronic control units of motor vehicles
    US10703309B2 (en) 2013-02-08 2020-07-07 Bayerische Motoren Werke Aktiengesellschaft Method and device for connecting a diagnostic unit to a control unit in a motor vehicle
    DE102013013621A1 (de) * 2013-08-15 2015-02-19 Bayerische Motoren Werke Aktiengesellschaft Sicherheitskonformer Kanalwechsel in intelligenten Transportsvstemen
    US10147322B2 (en) 2013-08-15 2018-12-04 Bayerische Motoren Werke Aktiengesellschaft Safety-compliant multiple occupancy of a channel in intelligent transportation systems
    FR3083635A1 (fr) * 2018-07-04 2020-01-10 Psa Automobiles Sa Procede de controle a distance de l’etat du contact d’un vehicule.

    Also Published As

    Publication number Publication date
    US6859718B2 (en) 2005-02-22
    JP2004005506A (ja) 2004-01-08
    DE10213165B3 (de) 2004-01-29
    EP1346881A3 (de) 2004-04-28
    US20030225485A1 (en) 2003-12-04

    Similar Documents

    Publication Publication Date Title
    DE10213165B3 (de) Verfahren und Vorrichtung zum Übernehmen von Daten
    DE10131395B4 (de) Verfahren zum Übertragen von Software- Modulen
    EP2959377B1 (de) Datenladevorrichtung und datenladeverfahren zum laden von software in flugzeugsysteme
    EP1639603A2 (de) Verfahren zur durchführung eines software-updates eines elektronischen steuergerätes durch eine flash-programmierung über eine serielle schnittstelle und ein entsprechender zustandsautomat
    EP0522332A1 (de) Rechner für den Leitstand einer Maschine, insbesondere eine Druckmaschine
    DE102004042002A1 (de) Verbesserte Reparaturverifikation für elektronische Fahrzeugsysteme
    DE19720285A1 (de) Verfahren zur manipulationssicheren Konfigurierung eines Kfz-Steuergerätes sowie Steuergerät
    DE102008035557A1 (de) Verfahren zum Einbringen von Daten, insbesondere eine Ablaufsteuerung, in mindestens ein erstes und ein zweites Steuergerät eines Kraftfahrzeugs
    DE60008872T2 (de) Verfahren und vorrichtung zur automatischen reintegration eines moduls in ein rechnersystem
    DE102011117376A1 (de) Verfahren zum Übernehmen von Programmdaten per Telematik in ein Steuergerät eines Kraftfahrzeugs mit automatischem Abnahmetest
    EP1293082A2 (de) Verfahren zum behandeln von einem fehlerhaften gerät in einem fahrzeugkommunikationsnetz
    DE19623145B4 (de) Verfahren zum Betreiben eines Steuergerätes mit einer über eine Programmiervorrichtung programmierbaren Speichereinrichtung
    EP3483033A1 (de) Verfahren und onboard-steuereinheit zum steuern und/oder überwachen von komponenten eines schienenfahrzeugs
    DE10007610B4 (de) Verfahren zur Programmierung eines Steuergerätes für ein Kraftfahrzeug
    DE102007036094A1 (de) Verfahren zur Diebstahlsicherung eines elektronischen Gerätes in einem Kraftfahrzeug und Diebstahlschutzvorrichtung für ein solches Gerät
    WO2000068746A1 (de) Einrichtung zum überwachen von betriebsparametern an eine elektrische oder elektronische steuerungseinrichting aufweisenden anlagen
    EP0945799B1 (de) Verfahren und Einrichtung zum Verhindern der Einlagerung nicht mehr aktueller Datentelegramme aus einer Datenvorverarbeitung in die Speicher eines Rechners
    DE19741959A1 (de) System zur Verarbeitung von Ereignissen in technischen Prozessen mit einem verteilten Datenverarbeitungssystem
    DE102018208832A1 (de) Verfahren zum Eindämmen eines Angriffs auf ein Steuergerät
    EP4144003B1 (de) Verfahren zum erzeugen einer softwarekomponente für eine elektronische recheneinrichtung eines kraftfahrzeugs, computerprogrammprodukt, computerlesbares speichermedium sowie kraftfahrzeugexternes aktualisierungssystem
    LU501035B1 (de) Verfahren und System zum Absichern des Austausches von Daten in einem Netzwerksystem für industrielle Steuerungen
    DE102017216965A1 (de) Installation von Software auf einem Datenverarbeitungssystem eines Fahrzeugs
    DE3239434C1 (de) Einrichtung zum Überwachen der Funktionsfähigkeit eines Mehr-Rechnersystems
    EP0952523A1 (de) Funktionseinheit für eine speicherprogrammierbare Steuerung mit Redundanzfunktion
    DE112021007689T5 (de) Steuervorrichtung

    Legal Events

    Date Code Title Description
    PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

    Free format text: ORIGINAL CODE: 0009012

    AK Designated contracting states

    Kind code of ref document: A2

    Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR

    AX Request for extension of the european patent

    Extension state: AL LT LV MK RO

    PUAL Search report despatched

    Free format text: ORIGINAL CODE: 0009013

    AK Designated contracting states

    Kind code of ref document: A3

    Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR

    AX Request for extension of the european patent

    Extension state: AL LT LV MK RO

    RIC1 Information provided on ipc code assigned before grant

    Ipc: 7B 60R 16/02 B

    Ipc: 7H 04L 29/08 B

    Ipc: 7G 06F 9/445 A

    17P Request for examination filed

    Effective date: 20040324

    17Q First examination report despatched

    Effective date: 20040707

    AKX Designation fees paid

    Designated state(s): DE FR GB IT

    GRAP Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOSNIGR1

    RTI1 Title (correction)

    Free format text: METHOD FOR THE RECEPTION OF DATA

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

    18W Application withdrawn

    Effective date: 20051015