EP1639603A2 - Verfahren zur durchführung eines software-updates eines elektronischen steuergerätes durch eine flash-programmierung über eine serielle schnittstelle und ein entsprechender zustandsautomat - Google Patents

Verfahren zur durchführung eines software-updates eines elektronischen steuergerätes durch eine flash-programmierung über eine serielle schnittstelle und ein entsprechender zustandsautomat

Info

Publication number
EP1639603A2
EP1639603A2 EP04738775A EP04738775A EP1639603A2 EP 1639603 A2 EP1639603 A2 EP 1639603A2 EP 04738775 A EP04738775 A EP 04738775A EP 04738775 A EP04738775 A EP 04738775A EP 1639603 A2 EP1639603 A2 EP 1639603A2
Authority
EP
European Patent Office
Prior art keywords
flash
programming
memory
segment
boot block
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
EP04738775A
Other languages
English (en)
French (fr)
Inventor
Thomas Zurawka
Joerg Schaeuffele
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.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP1639603A2 publication Critical patent/EP1639603A2/de
Withdrawn legal-status Critical Current

Links

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
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading

Definitions

  • the present invention relates to a method for carrying out a software update of an electronic control unit by means of flash programming via a serial interface.
  • Control units too.
  • This memory technology enables software updates of the control units by reprogramming the corresponding flash memory of the control units via serial interfaces.
  • the serial interface can be, for example, a central off-board diagnostic interface of a vehicle, via which the flash memory of an electronic device can be used with a so-called flash programming tool Control unit of the vehicle is reprogrammed.
  • a software update is therefore possible without removing the corresponding electronic control unit from the vehicle, which leads to considerable cost savings compared to replacing or removing a control unit.
  • high safety and reliability requirements must be met, particularly in the service of vehicles and in the area of safety-relevant electronic control units.
  • flash programming a distinction must therefore be made between the steps of deleting and programming flash segments. It must also be noted that it is not possible to run a program from one flash segment at the same time as another flash segment of the same flash module is being reprogrammed.
  • the program parts for controlling the programming sequence for a flash component must therefore, at least temporarily while the flash programming is being carried out, in another memory module, for example in another flash module or in a free RAM (random access memory) area of the control device be outsourced.
  • flash programming via a so-called off-board diagnostic interface can always take a relatively long time. It is to be expected that the programming process will be terminated at any time due to any faults that may occur. Such faults are, for example, the failure of the voltage supply of a vehicle or the flash programming tool, impermissible reaction of other control devices in the network, interruption of the communication link between the electronic control device to be programmed and the flash programming tool used for this, or an operating error. A failed authentication and signature check can also lead to the termination of flash programming. It is therefore necessary to be able to guarantee the availability or an immediate restart of the flash programming at any time.
  • a method for performing a software update of a control device by a flash Programming of a multi-segment flash memory of the control device is provided via a serial interface, with requirements to be made of the flash programming being specified in a first step of the method, so that a sequence of the
  • Flash programming is specified by a state machine that defines states and transitions of the software of the control device, and ultimately availability, security and reliability requirements of each state and each transition of the state machine are checked.
  • different operating states are preferably first specified for the software of the control device.
  • a distinction is preferably made between an “initial state”, a “normal state” and a “software update” state.
  • the transitions between the mentioned operating states and the transition conditions are defined.
  • memory blocks of the software of the control device relevant for the flash programming are subdivided into programmable and non-programmable memory blocks and software components to be reprogrammed are correspondingly assigned to the control blocks.
  • the memory blocks of the software are preferably each assigned to a memory of the control unit, in particular a programmable memory block to a segment of the flash memory or a non-programmable memory block to a ROM (read-only memory) of the electronic control unit.
  • a memory of the control unit in particular a programmable memory block to a segment of the flash memory or a non-programmable memory block to a ROM (read-only memory) of the electronic control unit.
  • ROM read-only memory
  • the program status is often already programmed during control unit production, while the data status is later programmed, for example, vehicle-specifically at the end of the production of a vehicle. Because of this, in a further preferred embodiment of the method according to the invention, the so-called boot block, the program status and the data status are stored in each segment of the flash memory of the control device. That means different
  • All program parts of the control unit which are required for communication between the control unit and a flash programming tool via the off-board diagnostic interface during flash programming, must be together with corresponding flash programming routines, a so-called flash loader in the ROM of the electronic control unit or in another other flash segment.
  • the program parts required for communication between the control unit and the flash programming tool are subdivided into programmable and non-programmable parts, namely a basic scope stored in the ROM hereinafter referred to as a start-up block, and a basic scope stored in the flash, hereinafter referred to as a boot block designated.
  • Start-up and boot block together the a 'flash programming via an off-board diagnostic interface necessary software functionality a microcontroller of the control unit.
  • a division into start-up and boot blocks makes sense for various reasons.
  • the boot block itself can be reprogrammed if it is stored in the flash memory as described. Furthermore, in
  • Boot block the current status of flash programming can be saved so that it can be restarted, for example, after the flash programming has been canceled.
  • the unchangeable basic functionality of the start-up block and an identifier for a hardware variant of the electronic control unit can be stored in the cheaper and non-reprogrammable ROM of the control unit.
  • the program and data status are each stored in a different segment of the flash memory.
  • a flash programming tool triggers a transition of a microcontroller of the control device into the "software update" operating state.
  • additional safety measures are required for use in production and service. Accordingly, for reasons of liability, for example, it is necessary to prevent unauthorized flash programming or flash programming with manipulated program or data status as far as possible. At least such flash programming should be recognized and proven. Flash programming access is therefore usually secured using two different encryption methods. On the one hand, there is an authentication, which corresponds to a check of the actual access authorization and after one
  • Plausibility check is carried out.
  • a digital key is used to check whether a user of the flash programming tool is even authorized to carry out a software update.
  • a second encryption method is a so-called signature check. The data consistency of a new program or data status to be programmed is checked.
  • a flash programming tool uses a further digital key to check whether the program or data status to be re-programmed matches the control unit hardware and whether the program or data status to be re-programmed, for example after delivery by the vehicle manufacturer to the Service organization has been tampered with.
  • the actual deletion and programming of the corresponding segments of the flash memory should only be made possible or released after a successful conclusion in the aforementioned test. The release is carried out by the boot block described above.
  • the signature of a microcontroller of the control unit is calculated on the basis of the program and data status actually programmed in the flash memory in order to avoid errors during the To be able to recognize programming.
  • this calculated signature is stored in the flash memory itself.
  • special memory structures a so-called Program status and data status logistics as part of the program and data status stored in flash memory. Only after a successful signature check does the boot block release the activation of the new program, such as a driving program.
  • the availability requirement of the flash programming is preferably also specified in the method according to the invention. Since flash programming via the off-board diagnostic interface can take a relatively long time despite the optimization measures already described, the programming process can generally be terminated at any time due to malfunctions. Such faults are, for example, a failure of a voltage supply to a vehicle or a flash programming tool, impermissible reactions of other interference devices in the network, interruptions in the communication link between the electronic control unit and the flash programming tool used, or operating errors. Failed authentication and signature checks also usually lead to the flash programming being aborted. For a design of the flash programming process, it is therefore important to ensure the availability of flash programming under all conceivable circumstances. This means, for example, that a restart of the programming process is guaranteed at all times after an abort in all situations. For this purpose, in a further preferred embodiment of the method according to the invention, the state machine executes the flash programming in
  • Operating state specifiable sub-states, transitions between these and transition conditions specified.
  • the sub-states can be the sub-state "Abort / error message” or Act “completion / success report”.
  • sub-states for authentication and signature verification can preferably be specified, as well as sub-states for deleting and programming segments of the flash memory.
  • the present invention comprises a computer program consisting of program code elements, by means of which, when the program code elements are executed on a computer or on a computer system, automatically predefined availability, security and
  • the present invention relates to a method for flash programming a boot block described above.
  • a method is provided for carrying out flash programming of a boot block providing the software functionality required for carrying out the flash programming.
  • the boot block is stored in a first segment of a flash memory.
  • the old boot block to be reprogrammed is copied into a free RAM area. This means that the still active old boot block must be transferred to another memory module of the control unit during flash programming, which means that the boot block must be relocatable.
  • the old boot block is then activated in RAM and in Flash memory, where it is stored in a first segment, deactivated.
  • the new boot block is buffered in a second segment of the flash memory. This step includes deleting the second segment of the flash memory and programming the new one
  • Boot blocks in the second segment of the flash memory and a signature check for the new boot block in the second segment of the flash memory After an abort during these procedural steps, the flash programming can be started again with the valid, old boot block in the first segment of the flash memory.
  • the new boot block is ultimately programmed by copying the second segment of the flash memory into the first segment of the flash memory. This step comprises deleting the first flash segment, programming the new boot block into the first flash segment by copying the second flash segment into the first flash segment and a signature check for the new boot block in the first flash -Segment. After a break during this
  • a boot block is always marked in the flash memory as a boot block valid for a restart of the flash programming.
  • This validation marker itself must be stored in the flash memory so that it cannot be restarted with this information.
  • the new boot block is then activated in the first segment of the flash memory and at the same time the old boot block is deactivated in RAM.
  • FIG. 1 shows a schematic representation of a specification of memory blocks of a control device relevant for flash programming according to an embodiment of the method according to the invention
  • FIG. 2 shows a schematic representation of a specification of security requirements and measures according to a further embodiment of the method according to the invention
  • FIG. 3 shows a schematic representation of states and transitions of a boot block in the case of flash programming of the program and data status of an electronic control unit
  • Figure 4 is a schematic representation of the sequence of an embodiment of a method according to the invention for performing flash programming of a boot block.
  • FIG. 1 shows an allocation of memory blocks of software of a control device for carrying out a software update of a control device by means of flash programming.
  • a control device 1 with a microcontroller 2 is shown.
  • the microcontroller 2 has a microprocessor 3 and three different memories, namely a ROM (read-only memory) 4, a flash memory 5 and a RAM (random access memory) 6.
  • Control unit 1 has a serial interface 7 for coupling to an off-board diagnostic interface 8, via which a flash programming tool can be connected.
  • a memory allocation of memory blocks of the software of the control device 1 relevant for the flash programming is shown.
  • the memory blocks are subdivided into programmable and non-programmable memory blocks and software components to be reprogrammed are assigned to the memory blocks accordingly.
  • the start-up block 9 and the boot block 10 together provide the software functionality of the microcontroller 2 necessary for flash programming via the off-board diagnostic interface 8.
  • the division into start-up block 9 and boot block 10 makes sense for various reasons.
  • the boot block 10 itself, which in the case shown here is stored in a segment A of the flash memory 11, can thus be reprogrammed.
  • the current status of the flash programming can be stored captively in boot block 10, so that, for example, a restart is possible after an abort.
  • the unchangeable basic functionality of the start-up block 9, on the other hand, can be stored in the cheaper and non-reprogrammable ROM 12.
  • the program status is stored in a further segment of the flash memory, a flash segment B, and the data status is stored in a flash segment C.
  • Microcontrollers 2 performed plausibility check 14, which must be carried out before a transition to the "software update" operating state, a check is carried out with respect to the actual access authorization.
  • This step is referred to as authentication 15.
  • a digital key is used to check whether a user of the flash programming tool 13 is authorized to carry out a software update.
  • the data consistency of the program or data status to be newly programmed is checked.
  • This step is also called signature verification.
  • the flash programming tool 13 uses a further digital key to check whether the program or data status to be newly programmed matches the control unit hardware and whether the program or data status to be newly programmed has been manipulated inadmissibly since it was delivered.
  • the signature is calculated by the microcontroller 2 on the basis of the program and data status actually programmed in the flash memory in order to be able to recognize errors during the programming.
  • this calculated signature check is itself stored in the flash memory.
  • special memory structures, so-called program status and data status logistics, are stored in the flash memory as part of the program and data status. Only after a successful signature check 19 does the boot block give the Activation of the new program such as a driving program freely.
  • Figure 3 shows a schematic representation of the state and transitions of a boot block in a flash programming of program and data status.
  • step 21 the programming process is immediately terminated with the simultaneous output of an error message F.
  • step 22 the user of the connected flash programming tool is authenticated. There is also an abort with an error message F if an error is detected in step 23.
  • a signature check 24 is then carried out, which is accompanied by a check of the data consistency via hardware
  • a detected error 25 is also signaled here with an abort and an accompanying error message F.
  • the flash segment in which the program status is stored is erased.
  • the new program status is then programmed in a step 27 and a signature check 28 is carried out for the new program status.
  • the same steps are carried out in steps 29, 30, 31 with regard to the flash programming of the data status. If an error is detected during the signature check for the program status or for the data status, then there is an abort with an accompanying error message F. If, on the other hand, no errors are detected, a transition takes place in a step 32 of the microcontroller in the operating state "initial state" by a reset.
  • FIG. 4 describes the method steps in flash programming a boot block.
  • the active boot block "A” must be swapped to another memory chip of the microcontroller during flash programming, i.e. Boot block "A” must be relocatable. This can be done, for example, by copying boot block "A” into a free RAM area during flash programming.
  • the boot block "A” is then executed from the RAM. A restart of the programming sequence must be possible even after the flash programming of the boot block has failed. An error-free boot block is sufficient to maintain availability after a termination.
  • the old boot block "A" is copied into a free RAM area.
  • the old boot block is activated in RAM, which is identified by the marking "A", and deactivated in the flash memory.
  • the new boot block is buffered in a flash segment C. Flash segment C is first deleted, the new boot block is programmed in flash segment C and a signature check is carried out for the new boot block in flash segment C. After a break during this
  • Process steps can be restarted with the valid, old boot block in flash segment A.
  • the new boot block is programmed, which is done by copying flash segment C to flash segment A.
  • This step includes deleting flash segment A, programming the new boot block in flash segment A by copying flash segment C to A, and a signature check for the new boot block in flash segment A.
  • the flash programming can be started again with the valid, new boot block in flash segment C.
  • the valid boot block in the flash memory must be marked. This validation marker itself must be stored captively in the flash memory so that it can be restarted with this information.

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zur Durchführung eines Software-Updates eines Steuergerätes durch eine Flash-Programmierung eines mehrere Segmente aufweisende Flash-Speichers des Steuergerätes über eine serielle Schnittstelle, wobei an die Flash-Programmierung zu stellende Anforderung festgelegt, ein Ablauf der Flash-Programmierung durch ein Zustände und Übergänge der Software definierenden Zustandsautomaten spezifiziert und Verfügbarkeits-, Sicherheits- und Zuverlässigkeitsanforderungen eines jeden Zustands und eines jeden Übergangs des Zustandsautomaten überprüft werden. Ferner umfasst die Erfindung einen entsprechend Zustandsautomaten und ein Computerprogramm zur automatischen Überprüfung der Verfügbarkeits-, Sicherheits- und Zulässigkeitsanforderung.

Description

Verfahren zur Durchführung eines Software-Updates eines elektronischen Steuergerätes durch eine Flash- Programmierung über eine serielle Schnittstelle und ein entsprechender Zustandsautoπtat
Die vorliegende Erfindung betrifft ein Verfahren zur Durchführung eines Software-Updates eines elektronischen Steuergerätes durch eine Flash-Programmierung über eine serielle Schnittstelle.
Stand der Technik
Der Einsatz eines sogenannten Flash als Speichertechnologie für Programm- und Datenstand nimmt in elektronischen
Steuergeräten zu. Diese Speichertechnologie ermöglicht ein Software-Update der Steuergeräte durch eine Neuprogrammierung des entsprechenden Flash-Speichers der Steuergeräte über serielle Schnittstellen. Bei der seriellen Schnittstelle kann es sich dabei bspw. um eine zentrale Off-Board-Diagnoseschnittstelle eines Fahrzeugs handeln, über welche mit einem sog. Flash- Programmierwerkzeug der Flash-Speicher eines elektronischen Steuergerätes des Fahrzeuges neu programmiert wird. Somit ist ein Software-Update ohne Ausbau des entsprechenden elektronischen Steuergerätes aus dem Fahrzeug möglich, was zu erheblichen Kosteneinsparungen gegenüber einem Steuergeräteaustausch bzw. -ausbaus führt. Bei der beschriebenen Art der Flash-Programmierung sind insbesondere im Service der Fahrzeuge sowie im Bereich sicherheitsrelevanter elektronischer Steuergeräte hohe Sicherheits- und Zuverlässigkeitsanforderungen zu erfüllen.
Mit den derzeit eingesetzten Flash-Technologien können nur ganze Flash-Bereiche eines Flash-Speichers gelöscht oder neu programmiert werden. Dabei wird eine kleinste, physikalisch zusammengehörende, geschlossen lösch- oder programmierbare Speichereinheit des Flash-Speichers als Segment bezeichnet. Bei einer Flash-Programmierung sind deshalb die Schritte Löschen und Programmieren von Flash- Segmenten zu unterscheiden. Dabei muß ferner beachtet werden, daß es nicht möglich ist gleichzeitig aus einem Flash-Segment ein Programm auszuführen, während ein anderes Flash-Segment des gleichen Flash-Bausteins neu programmiert wird. Die Programmteile zur Steuerung des Programmierablaufs für ein Flash-Bauteil müssen deshalb, zumindest temporär während der Durchführung der Flash- Programmierung, in einen anderen Speicherbaustein, bspw. in einen anderen Flash-Baustein oder einen freien RAM (Random Access Memory) -Bereich des Steuergerätes ausgelagert werden.
Wegen der begrenzten Übertragungsleistung der Off-Board- Diagnoseschnittstelle kommt es bei großen Flash-Speichern von elektronischen Steuergeräten zu recht langen Flash- ProgrammierZeiten. Deshalb besteht in der Produktion und im Service häufig die Anforderung, die Flash-Programmierzeiten zu verkürzen.
Ferner ist bei einer Flash-Programmierung aus Haftungsgründen stets zu beachten, daß eine nicht autorisierte Flash-Programmierung oder eine Flash- Programmierung mit einem manipulierten Programm- oder Datenstand möglichst zu verhindern ist. Letztlich ist zu beachten, daß eine Flash-Programmierung über eine genannte Off-Board-Diagnoseschnittstelle stets ein verhältnismäßig lange Zeitspanne in Anspruch nehmen kann. Dabei ist mit Abbruchen des Programmierablaufs durch evtl. auftretende Störungen jederzeit zu rechnen. Derartige Störungen sind etwa der Ausfall der Spannungsversorgung eines Fahrzeuges oder des Flash-Programmierwerkzeuges, unzulässige Reaktion anderer Steuergeräte im Netzwerk, Unterbrechung der Kommunikations erbindung zwischen dem zu programmierenden elektronischen Steuergerät und dem dazu eingesetzten Flash- Programmierwerkzeug oder ein Bedienfehler. Auch eine fehlgeschlagende Authentisierung und Signaturprüfung können zum Abbruch einer Flash-Programmierung führen. Deshalb ist es nötig die Verfügbarkeit bzw. einen sofortigen Neustart der Flash-Programmierung jederzeit gewähren zu können.
Vorteile der Erfindung
Es wird ein erfindungsgemäßes Verfahren gemäß Anspruch 1 und ein entsprechender Zustandsautomat gemäß Anspruch 8 vorgestellt. Weitere Vorteile und bevorzugte Ausführungsformen werden in den entsprechenden Unteransprüchen aufgeführt.
Gemäß Anspruch 1 wird ein Verfahren zur Durchführung eines Software-Updates eines Steuergerätes durch eine Flash- Programmierung eines mehrere Segmente aufweisenden Flashspeichers des Steuergerätes über eine serielle Schnittstelle bereitgestellt, wobei in einem ersten Schritt des Verfahrens an die Flash-Programmierung zu stellende Anforderungen festgelegt werden, so daß ein Ablauf der
Flash-Programmierung durch einen Zustände und Übergänge der Software des Steuergerätes definierenden Zustandsautomaten spezifiziert und letztlich Verfügbarkeits-, Sicherheitsund Zuverlässigkeitsanforderungen eines jeden Zustandes und eines jeden Übergangs des Zustandsautomatischen überprüft werden.
Vorzugsweise werden bei Festlegen von an die Flash- Programmierung zu stellende Anforderungen zunächst für die Software des Steuergerätes verschiedene Betriebszustände spezifiziert. Dabei wird vorzugsweise unterschieden zwischen einem "Anfangszustand", einem "Normalzustand" und einem Zustand "Software-Update". Ferner werden die Übergänge zwischen den genannten Betriebszuständen und die Übergangsbedingungen definiert. Bei einer weiteren bevorzugten Ausführungsform des Verfahrens werden für die Flash-Programmierung relevante Speicherblöcke der Software des Steuergerätes in programmierbare und nicht programmierbare Speicherblöcke unterteilt und neu zu programmierende Komponenten der Software den Steuerblöcken entsprechend zugeordnet. Weiterhin vorzugsweise werden die Speicherblöcke der Software jeweils einem Speicher des Steuergerätes, insbesondere ein programmierbarer Speicherblock einem Segment des Flash-Speichers bzw. ein nicht programmierbarer Speicherblock einem ROM (Read-Only- Memory) des elektronischen Steuergerätes zugeordnet. Aufgrund der begrenzten Übertragungsleistung der Off-Board- Diagnoseschnittstelle kommt es bei großen Flash-Speichern zu recht langen Flash-ProgrammierZeiten. Deshalb ist es wünschenswert, die Flash-Programmierzeiten zu verkürzen, was bspw. durch eine Verringerung der neu zu programmierenden Flash-Segmente möglich ist. Dies wird vorzugsweise durch die Flash-Programmierung einzelner Software-Funktionen oder durch eine getrennte Flash- Programmierung für den Programm- und Datenstand des elektronischen Steuergerätes erreicht. Dabei wird häufig der Programmstand bereits bei der Steuergeräteproduktion programmiert, während der Datenstand später bspw. fahrzeugspezifisch am Ende der Produktion eines Fahrzeuges programmiert wird. Aufgrund dessen werden in einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens jeweils in Segmenten des Flash-Speichers des Steuergerätes der sog. Boot-Block, der Programm- und er Datenstand abgelegt. Das bedeutet, daß verschiedene
Softwarefunktionen, sowie Programm- und Datenstand in verschiedenen Flash-Segmenten abgelegt werden. Alle Programmteile des Steuergerätes, die für eine Kommunikation zwischen dem Steuergerät und einem Flash- Programmierwerkzeug über die Off-Board- Diagnoseschnittstelle während einer Flash-Programmierung erforderlich sind, müssen dabei zusammen mit entsprechenden Flash-Programmierroutinen, einem sog. Flash-Loader im ROM des elektronischen Steuergeräts oder in einem anderen weiteren Flash-Segment abgelegt werden. Die für die Kommunikation zwischen Steuergerät und Flash- Programmierwerkzeug erforderlichen Programmteile werden unterteilt in programmierbare und nicht programmierbare Anteile, nämlich einen im ROM abgelegten Basisumfang im folgenden als Start-up-Block bezeichnet, und einen im Flash abgelegten Basisumfang, im folgenden als Boot-Block bezeichnet. Start-up- und Boot-Block zusammen stellen die für eine' Flash-Programmierung über eine Off-Board- Diagnoseschnittstelle notwendige Software-Funktionalität eines MikroControllers des Steuergerätes zur Verfügung. Eine Aufteilung in Start-up- und Boot-Block ist aus verschiedenen Gründen sinnvoll. So kann der Boot-Block selbst, falls er, wie beschrieben, im Flash-Speicher abgelegt wird, neu programmiert werden. Ferner kann im
Boot-Block, der aktuelle Status einer Flash-Programmierung unverlierbar abgespeichert werden, so daß bspw. nach einem Abbruch der Flash-Programmierung ein Wiederaufsetzen möglich ist. Die unveränderbare Basisfunktionalität des Start-up-Blocks und eine Kennung für eine Hardwarevariante des elektronischen Steuergerätes können hingegen im kostengünstigeren und nicht neu programmierbaren ROM des Steuergerätes abgelegt werden. Erfindungsgemäß wird ferner der Programm- und der Datenstand jeweils in einem anderen Segment des Flash-Speichers abgelegt.
In einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens werden Sicherheits-, Zuverlässigkeits- und Verfügbarkeitsanforderungen der durchzuführenden Flash-Programmierung spezifiziert. Ein Übergang eines MikroControllers des Steuergerätes in den Betriebszustand "Software-Update" wird von einem Flash- Programmierwerkzeug angestoßen. Neben evtl. notwendig Plausibilitätsprüfungen, wie etwa bei Motorsteuergeräten die Prüfung auf einen Motorstillstand, die vor einem Beenden eines Fahrprogramms und einem Übergang in den Betriebszustand "Software-Update" durchgeführt werden müssen, sind bei einem Einsatz in Produktion und im Service weitere Sicherheitsmaßnahmen erforderlich. Demnach ist es bspw. aus Haftungsgründen erforderlich, eine nicht autorisierte Flash-Programmierung oder Flash-Programmierung mit manipuliertem Programm- oder Datenstand möglichst zu verhindern. Zumindest sollten derartige Flash- Programmierungen erkannt und nachgewiesen werden können. Daher wird ein Flash-Programmierzugriff in der Regel über zwei unterschiedliche Verschlüsselungsverfahren abgesichert. Zum Einen handelt es sich dabei um eine Authentisierung, was einer Prüfung der eigentlichen Zugriffsberechtigung entspricht und nach einer
Plausibilitätsprüfung durchgeführt wird. Dabei wird anhand eines digitalen Schlüssels überprüft, ob ein Anwender des Flash-Programmierwerkzeuges überhaupt berechtigt ist, ein Software-Update durchzuführen. Ein zweites Verschlüsselungsverfahren ist eine sog. Signaturprüfung. Hierbei wird die Datenkonsistenz eines neu zu programmierenden Programm- oder Datenstands überprüft.
Bei der Signaturprüfung wird von einem Flash- Programmierwerkzeug anhand eines weiteren digitalen Schlüssels überprüft, ob der neu zu programmierende Programm- oder Datenstand zur Steuergeräte-Hardware paßt und ob der neu zu programmierende Programm- oder Datenstand bspw. nach der Auslieferung durch den Fahrzeughersteller an die Service-Organisation unzulässig manipuliert wurde. Erst nach einem erfolgreichen Abschluß bei der genannten Prüfung soll das eigentliche Löschen und Programmieren der entsprechenden Segmente des Flash-Speichers ermöglicht bzw. freigegeben werden. Die Freigabe erfolgt dabei durch den vorstehend beschriebenen Boot-Block. Bei der Spezifizierung des Sicherheits- und Zuverlässigkeitsanforderung der Flash- Programmierung ist auch zu beachten, daß nach der Flash- Programmierung die Signatur eines Mikrocontrollers des Steuergerätes auf Basis des tatsächlich in den Flash- Speicher programmierten Programm- und Datenstands berechnet wird, um Fehler während der Programmierung erkennen zu können. Nach einer erfolgreichen Signaturprüfung wird diese berechnete Signatur selbst im Flash-Speicher abgelegt. Dazu werden besondere Speicherstrukturen, eine sog. Programmstands- und Datenstandslogistik als Teil des Programm- und des Datenstands im Flash-Speicher abgelegt. Nur nach einer erfolgreichen Signaturprüfung gibt der Boot- Block die Aktivierung des neuen Programms wie bspw. eines Fahrprogramms frei.
Ferner wird bei dem erfindungsgemäßen Verfahren vorzugsweise auch die Verfügbarkeitsanforderung der Flash- Programmierung spezifiziert. Da die Flash-Programmierung über die Off-Board-Diagnoseschnittstelle trotz bereits beschriebener Optimierungsmaßnahmen eine verhältnismäßig lange Zeitspanne in Anspruch nehmen kann, ist generell mit Abbruchen des Programmierablaufs durch Störungen jederzeit zu rechnen. Derartige Störungen sind etwa ein Ausfall einer Spannungsversorgung eines Fahrzeuges oder eines Flash- Programmierwerkzeugs, unzulässige Reaktionen anderer Störgeräte im Netzwerk, Unterbrechungen der Kommunikationsverbindung zwischen dem elektronischen Steuergerät und dem eingesetzten Flash-Programmierwerkzeug oder Bedienfehler. Auch fehlgeschlagene Authentisierung und Signaturprüfungen führen in der Regel zu einem Abbruch der Flash-Programmierung. Für einen Entwurf des Ablaufs der Flash-Programmierung ist es deshalb wichtig, die Verfügbarkeit der Flash-Programmierung unter allen denkbaren Umständen zu gewährleisten. Dies bedeutet bspw., daß nach einem Abbruch in allen Situationen jederzeit ein Neustart des Programmierablaufs gewährleistet wird. Dazu wird in einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens durch den Zustandsautomaten bei Durchführung der Flash-Programmierung im
Betriebszustand "Software-Update" einnehmbare Subzustände, Übergänge zwischen diesen und Übergangsbedingungen spezifiziert. Als Subzustände kann es sich dabei um den Subzustand "Abbruch/Fehlermeldung" oder "Abschluß/Erfolgsmeldung" handeln. Ferner können vorzugsweise Subzustände für Authentisierung und Signaturprüfung spezifiziert werden sowie Subzustände für das Löschen und Programmieren von Segmenten des Flash- Speichers. Weiter ist es wünschenswert eine Spezifikation von Subzuständen für eine Auslagerung und eine Flash- Programmierung des Boot-Blocks vorzunehmen. Eine Spezifikation von Übergängen zwischen den genannten Subzuständen und entsprechender Übergangsbedingungen wird erfindungsgemäß ebenfalls vorgenommen.
Ferner umfaß die vorliegende Erfindung ein Computerprogramm bestehend aus Programmcodeelementen, durch welches bei Ausführung der Programmcodeelemente auf einem Computer oder auf einem Computersystem automatisch vordefinierte Verfügbarkeits-, Sicherheits- und
Zuverlässigkeitsanforderungen eines- jeden Zustands und eines jeden Übergangs eines vorstehend beschriebenen Zustandsautomaten überprüft werden.
Letztlich betrifft die vorliegende Erfindung ein Verfahren zur Flash-Programmierung eines vorstehend beschriebenen Boot-Blocks. Es wird ein Verfahren zur Durchführung einer Flash-Programmierung eines für die Durchführung der Flash- Programmierung notwendige Software-Funktionalität bereitstellenden Boot-Blocks bereitgestellt. Der Boot-Block ist dabei in einem ersten Segment eines Flash-Speichers abgelegt. In einem ersten Schritt wird der neu zu programmierende alte Boot-Block in einen freien RAM-Bereich kopiert. D.h. der noch aktive alte Boot-Block muß während der Flash-Programmierung in einen anderen Speicherbaustein des Steuergerätes ausgelagert werden, was bedeutet daß der Boot-Block relokatierbar sein muß. In einem zweiten Schritt wird sodann der alte Boot-Block im RAM aktiviert und im Flash-Speicher, wo er in einem ersten Segment abgelegt ist, deaktiviert. Weiterhin wird der neue Boot-Block in einem zweiten Segment des Flash-Speichers zwischenabgelegt. Dieser Schritt umfaßt dabei das Löschen des zweiten Segmentes des Flash-Speichers, Programmieren des neuen
Boot-Blocks in das zweite Segment des Flash-Speichers und eine Signaturprüfung für den neuen Boot-Block in dem zweiten Segment des Flash-Speichers. Nach einem Abbruch während dieser Verfahrensschritte kann mit dem gültigen, alten Boot-Block in dem ersten Segment des Flash-Speichers die Flash-Programmierung erneut gestartet werden. In einem weiteren Schritt des erfindungsgemäßen Verfahrens wird letztlich der neue Boot-Block programmiert durch Kopieren des zweiten Segmentes des Flash-Speichers in das erste Segment des Flash-Speichers. Dieser Schritt umfaßt dabei das Löschen des ersten Flash-Segmentes, Programmieren des neuen Boot-Blocks in das erste Flash-Segment durch Kopieren des zweiten Flash-Segmentes in das erste Flash-Segment und eine Signaturprüfung für den neuen Boot-Block in dem ersten Flash-Segment. Nach einem Abbruch während dieser
Verfahrensschritte kann mit dem gültigen, neuen Boot-Block in dem zweiten Flash-Segment die Flash-Programmierung erneut gestartet werden. Vorzugsweise wird im Flash- Speicher immer ein Boot-Block als für einen Neustart der Flash-Programmierung gültiger Boot-Block markiert. Diese Gültigkeitsmarkierung selbst muß dabei unverlierbar im Flash-Speicher abgelegt werden, so daß mit dieser Information ein Wiederaufsetzen möglich ist. In einem letzten Schritt des erfindungsgemäßen Verfahrens wird sodann der neue Boot-Block im ersten Segment des Flash- Speichers aktiviert und gleichzeitig der alte Boot-Block im RAM deaktiviert. Weiter Vorteile und bevorzugte Ausführungsformen der Erfindung werden anhand der folgenden Figuren näher erläutert :
Figur 1 schematische Darstellung einer Spezifikation von für eine Flash-Programmierung relevanten Speicherblöcken eines Steuergerätes gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens;
Figur 2 schematische Darstellung einer Spezifikation von Sicherheitsanforderungen und -maßnahmen gemäß einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens;
Figur 3 schematische Darstellung von Zuständen und Übergängen eines Boot-Blocks bei einer Flash- Programmierung von Programm- und Datenstand eines elektronischen Steuergerätes;
Figur 4 schematische Darstellung des Ablaufs einer Ausführungsform eines erfindungsgemäßen Verfahrens zur Durchführung einer Flash- Programmierung eines Boot-Blocks.
Figur 1 zeigt eine Zuordnung von Speicherblöcken einer Software eines Steuergerätes für eine Durchführung eines Software-Updates eines Steuergerätes durch eine Flash- Programmierung. Gezeigt ist ein Steuergerät 1 mit einem MikroController 2. Der MikroController 2 verfügt über einen Mikroprozessor 3 und drei verschiedene Speicher nämlich einen ROM (Read-Only-Memory) 4, einen Flash-Speicher 5 und einen RAM (Random Access Memory) 6. Ferner weist das Steuergerät 1 eine serielle Schnittstelle 7 zur Ankopplung an eine Off-Board-Diagnoseschnittstelle 8 auf, über welche ein Flash-Programmierwerkzeug angeschlossen werden kann. Im unteren Teil von Figur 1 ist eine Speicherzuteilung von für die Flash-Programmierung relevanten Speicherblöcken der Software des Steuergerätes 1 dargestellt. Dabei werden die Speicherblöcke in programmierbare und nicht programmierbare Speicherblöcke unterteilt und neu zu programmierende Komponenten der Software den Speicherblöcken entsprechend zugeordnet. Programmteile des Mikrocontrollers 2, die für eine Kommunikation zwischen dem MikroController 2 und einem Flash-Programmierwerkzeug über die Off-Board- Diagnoseschnittstelle 8 während der Flash-Programmierung erforderlich sind, werden unterteilt in einen sog. Start- up-Block 9 und einen sog. Boot-Block 10. Der Start-up-Block 9 und der Boot-Block 10 stellen zusammen die für die Flash- Programmierung über die Off-Board-Diagnoseschnittstelle 8 notwendige Softwarefunktionalität des Mikrocontrollers 2 zur Verfügung. Die Aufteilung in Start-up-Block 9 und Boot- Block 10 ist aus verschiedenen Gründen sinnvoll. So kann der Boot-Block 10 selbst, der im hier dargestellten Fall in einem Segment A des Flash-Speichers 11 abgelegt ist, neu programmiert werden. Außerdem kann im Boot-Block 10 der aktuelle Status der Flash-Programmierung unverlierbar abgespeichert werden, so daß bspw. nach einem Abbruch ein Wiederaufsetzen möglich ist. Die unveränderbare Basisfunktionalität des Start-up-Blocks 9 kann dagegen im kostengünstigeren und nicht neu programmierbaren ROM 12 abgelegt werden. In einem weiteren Segment des Flash- Speichers, einem Flash-Segment B wird der Programmstand abgelegt und in einem Flash-Segment C der Datenstand.
In Figur 2 ist eine Spezifikation von
Sicherheitsanforderungen bei Durchführung einer Flash- Programmierung dargestellt. Gezeigt ist ein möglicher Ablauf einer Kommunikation zwischen einem Flash- Programmierwerkzeug 13 und einem MikroController 2 eines Steuergerätes. Nach einer durch Anfrage seitens des Flash- Programmierwerkzeugs 13 und Rückmeldung des
Mikrocontrollers 2 durchgeführten Plausibilitätsprüfung 14, die vor einem Übergang in den Betriebszustand "Software- Update" durchgeführt werden muß, wird eine Prüfung bzgl. der eigentlichen Zugriffberechtigung durchgeführt. Dieser Schritt wird als Authentisierung 15 bezeichnet. Dabei wird anhand eines digitalen Schlüssels überprüft, ob ein Anwender des Flash-Programmierwerkzeugs 13 berechtigt ist, ein Software-Update vorzunehmen. In einem weiteren Prüfungsschritt 16 wird die Datenkonsistenz des neu zu programmierenden Programm- oder Datenstands überprüft. Dieser Schritt wird auch als Signaturprüfung bezeichnet. Hierbei wird vom Flash-Programmierwerkzeug 13 anhand eines weiteren digitalen Schlüssels überprüft, ob der neu zu programmierende Programm- oder Datenstand zur Steuergerätehardware paßt und ob der neu zu programmierende Programm- oder Datenstand seit seiner Auslieferung unzulässig manipuliert wurde. Erst nach einem erfolgreichen Abschluß bei der Prüfung werden die Flash-Segmente in einem Schritt 17 gelöscht und anschließend in einem Schritt 18 die entsprechenden Flash-Segmente programmiert. Nach der Flash-Programmierung wird die Signatur vom Mikrocontroller 2 auf Basis des tatsächlich im Flash-Speicher programmmierten Programm- und Dätenstands berechnet, um Fehler während der Programmierung erkennen zu können. Nach erfolgreicher Signaturprüfung 19 wird diese berechnete Signaturprüfung selbst im Flash-Speicher abgelegt. Dazu werden besondere Speicherstrukturen, sog. Programmstandsund Datenstandslogistik als Teil des Programm- und des Datenstands im Flash-Speicher abgelegt. Nur nach einer erfolgreichen Signaturprüfung 19 gibt der Boot-Block die Aktivierung des neuen Programms wie bspw. eines Fahrprogramms frei.
Figur 3 zeigt in schematischer Darstellung Zustand und Übergänge eines Boot-Blocks bei einer Flash-Programmierung von Programm- und Datenstand. Zunächst wird in einem Schritt 20 bei Ankopplung eines Flash-Programmierwerkzeugs an den MikroController über eine Off-Board- Diagnoseschnittstelle das Steuergerät identifiziert und ein Übergang des Mikrocontrollers in dem Betriebszustand
"Software-Update" initiiert. Wird hierbei in einem Schritt 21 ein Fehler erkannt, so kommt es sofort zu einem Abbruch des Programmiervorgangs mit gleichzeitiger Ausgabe einer Fehlermeldung F. In einem weiteren Schritt 22 wird eine Authentisierung des Benutzers des angekoppelten Flash- Programmierwerkzeuges vorgenommen. Auch hier kommt es zu einem Abbruch mit einer Fehlermeldung F, falls in einem Schritt 23 ein Fehler erkannt wird. Im Anschluß daran wird eine Signaturprüfung 24 vorgenommen, was einhergeht mit einer Prüfung der Datenkonsistenz über Hardware-
/Programmstands-/ Datenstands-Logistik. Ein erkannter Fehler 25 wird auch hier mit einem Abbruch und einhergehender Fehlermeldung F signalisiert. Nach Durchführung dieser Schritte kommt es zu einem Löschen 26 des Flash-Segmentes, in welchem der Programmstand abgelegt ist, daraufhin wird in eine Schritt 27 der neue Programmstand programmiert und eine Signaturprüfung 28 für den neuen Programmstand durchgeführt. Die gleichen Schritte werden in den Schritten 29, 30, 31 bzgl. der Flash- Programmierung des Datenstandes vorgenommen. Wird bei der Signaturprüfung für Programmstand bzw. für Datenstand ein Fehler erkannt, so erfolgt auch hier ein Abbruch mit einer einhergehenden Fehlermeldung F. Werden demgegenüber keine Fehler erkannt, so erfolgt in einem Schritt 32 ein Übergang des Mikrocontrollers in dem Betriebszustand "Anfangszustand" durch ein Reset.
Figur 4 beschreibt die Verfahrensschritte bei einer Flash- Programmierung eines Boot-Blocks. Zunächst muß der aktive Boot-Block "A" während der Flash-Programmierung in einen anderen Speicherbaustein des Mikrocontrollers ausgelagert werden, d.h. Boot-Block "A" muß relokatierbar sein. Dies kann bspw. durch ein Kopieren des Boot-Blocks "A" in ein während der Flash-Programmierung freien RAM-Bereich erfolgen. Anschließend wird dann der Boot-Block "A" aus dem RAM ausgeführt. Auch nach einer fehlgeschlagenen Flash- Programmierung des Boot-Blocks muß ein Neustart des Programmierablaufs möglich sein. Zur Erhaltung der Verfügbarkeit nach einem Abbruch ist ein fehlerfreier Boot- Block ausreichend. In einem ersten Schritt des Verfahrens wird der alte Boot-Block "A" in einen freien RAM-Bereich kopiert. In einem zweiten Schritt wird der alte Boot-Block im RAM aktiviert, was durch die Markierung "A" kenntlich gemacht ist, und im Flash-Speicher deaktiviert. Der neue Boot-Block wird in einem Flash-Segment C zwischenabgelegt. Dabei wird das Flash-Segment C zunächst gelöscht, der neue Boot-Block in Flash-Segment C programmiert und eine Signaturprüfung für den neuen Boot-Block im Flash-Segment C durchgeführt. Nach einem Abbruch während dieser
Verfahrensschritte kann mit dem gültigen, alten Boot-Block im Flash-Segment A die Flash-Programmierung erneut gestartet werden. In einem dritten Schritt wird der neue Boot-Block programmiert, was durch ein Kopieren von Flash- Segment C nach Flash-Segment A durchgeführt wird. Dieser Schritt umfaßt das Löschen des Flash-Segments A, das Programmieren des neuen Boot-Blocks in Flash-Segment A durch Kopieren des Flash-Segments C nach A und einer Signaturprüfung für den neuen Boot-Block in Flash-Segment A. Nach einem Abbruch während dieser Verfahrensschritte kann mit dem gültigen, neuen Boot-Block in Flash-Segment C die Flash-Programmierung erneut gestartet werden. Der jeweils gültige Boot-Block im Flash-Speicher muß markiert werden. Diese Gültigkeitsmarkierung selbst muß unverlierbar im Flash-Speicher abgelegt werden, so daß mit dieser Information ein Wiederaufsetzen möglich ist.

Claims

Ansprüche
1. Verfahren zur Durchführung eines Software-Updates eines Steuergerätes durch eine Flash-Programmierung eines mehrere Segmente aufweisenden Flash-Speichers des Steuergerätes über eine serielle Schnittstelle, das mindestens die folgenden Schritte aufweist:
a) Festlegen von an die Flash-Programmierung zu stellende Anforderungen;
b) Festlegen eines Ablaufs der Flash-Programmierung durch einen Zustände und Übergänge der Software definierenden
Zustandsautomaten;
c) Überprüfen von Verfügbarkeits-, Sicherheits- und Zuverlässigkeitsanforderungen eines jeden Zustands und eines jeden Übergangs des Zustandsautomaten.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß für die Software des Steuergerätes verschiedene Betriebszustände, insbesondere ein "Anfangszustand", ein "Normalzustand" und ein "Software-Update", Übergänge zwischen den Betriebszuständen und Übergangsbedingungen spezifiziert werden.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß für Flash-Programmierung relevante Speicherblöcke der Software des Steuergerätes in programmierbare und nicht programmierbare Speicherblöcke unterteilt werden und neu zu programmierende Komponenten der Software den Speicherblöcken entsprechend zugeordnet werden.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß die Speicherblöcke der Software jeweils einem Speicher des
Steuergerätes, insbesondere ein programmierbarer Speicherblock mindestens einem Segment des Flash-Speichers, bzw. ein nicht programmierbarer Speicherblock einem ROM des Steuergerätes zugeordnet werden.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß jeweils in Segmenten des Flash- Speichers des Steuergerätes ein für die Durchführung der Flash-Programmierung notwendige Software-Funktionalität bereitstellender Boot-Block, ein Programm- und ein
Datenstand und in einem ROM des Steuergerätes ein für die Durchführung der Flash-Programmierung notwendige Software- Funktionalität bereitstellender Start-up-Block abgelegt werden.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß Sicherheits-, Zuverlässigkeitsund Verfügbarkeitsanforderungen der Flash-Programmierung spezifiziert werden.
7. Verfahren nach einem der Ansprüche 2 bis 6, dadurch gekennzeichnet, daß durch den Zustandsautomaten bei Durchführung der Flash-Programmierung im Betriebszustand "Software-Update" einnehmbare Subzustände, Übergänge zwischen diesen und Übergangsbedingungen spezifiziert werden.
8. Zustandsautomat zur Durchführung eines Software- Updates eines Steuergerätes durch eine Flash- Programmierung, der alle bei Durchführung des Software- Updates einnehmbare Subzustände der Software des Steuergerätes, Übergänge zwischen diesen und Übergangsbedingungen definiert und bei Auftreten einer Störung während der Durchführung des Software-Updates ein dauerhaftes, unverlierbares Abspeichern eines zuletzt gültigen oder fehlerfrei durchlaufenen Zustandes spezifiziert .
9. Zustandsautomat nach Anspruch 8, dadurch gekennzeichnet daß als Subzustände "Abbruch/Fehlermeldung", "Abschluß/Erfolgsmeldung", Subzustände für eine Authentisierung und Signaturprüfung, Subzustände für Löschen und Programmieren von Segmenten des Flash-Speichers spezifiziert sind.
10. Computerprogramm, bestehend aus Programmcodeelementen durch welches bei Ausführen der Programmcodeelemente auf einem Computer oder auf einem Computersystem automatisch vordefinierte Verfügbarkeits-, Sicherheits- und
Zuverlässigkeitsanforderungen eines jeden Zustands und eines jeden Übergangs eines Zustandsautomaten gemäß Anspruch 8 oder 9 überprüft werden.
11. Verfahren zur Durchführung einer Flash-Programmierung eines für die Durchführung der Flash-Programmierung notwendige Software-Funktionalität bereitstellender, in einem ersten Segment (Flash-Segment A) eines Flash- Speichers abgelegten Boot-Blocks,
wobei das Verfahren mindestens die folgenden Schritte aufweist:
a) Kopieren des neu zu programmierenden, alten Boot- Blocks in einen freien Bereich eines zweiten Speichers (RAM) ;
b) Aktivieren des alten Boot-Blocks in dem zweiten Speicher (RAM) und Deaktivieren des alten Boot-Blocks im Flash-Speicher;
c) Zwischenablegen eines neuen Boot-Blocks in einem zweiten Segment (Flash-Segment C) des Flash-Speichers;
d) Programmieren des neuen Boot-Blocks durch Kopieren des zweiten Segments (Flash-Segment C) nach dem ersten Segment (Flash-Segment A) ;
e) Aktivieren des neuen Boot-Blocks in dem ersten Segment (Flash-Segment A) und Deaktivieren des alten Boot-Blocks in dem zweiten Speicher (RAM) .
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß im Flash-Speicher immer ein Boot-Block als für einen Neustart der Flash-Programmierung gültiger Boot-Block markiert wird.
EP04738775A 2003-06-24 2004-06-24 Verfahren zur durchführung eines software-updates eines elektronischen steuergerätes durch eine flash-programmierung über eine serielle schnittstelle und ein entsprechender zustandsautomat Withdrawn EP1639603A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10328241 2003-06-24
PCT/DE2004/001326 WO2005004160A2 (de) 2003-06-24 2004-06-24 Verfahren zur durchführung eines software-updates eines elektronischen steuergerätes durch eine flash-programmierung über eine serielle schnittstelle und ein entsprechender zustandsautomat

Publications (1)

Publication Number Publication Date
EP1639603A2 true EP1639603A2 (de) 2006-03-29

Family

ID=33559737

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04738775A Withdrawn EP1639603A2 (de) 2003-06-24 2004-06-24 Verfahren zur durchführung eines software-updates eines elektronischen steuergerätes durch eine flash-programmierung über eine serielle schnittstelle und ein entsprechender zustandsautomat

Country Status (5)

Country Link
US (1) US20060248172A1 (de)
EP (1) EP1639603A2 (de)
JP (1) JP2007507016A (de)
DE (1) DE112004001633D2 (de)
WO (1) WO2005004160A2 (de)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002232426A1 (en) * 2000-11-17 2002-05-27 Biftone Corporation System and method for updating and distributing information
US7409685B2 (en) 2002-04-12 2008-08-05 Hewlett-Packard Development Company, L.P. Initialization and update of software and/or firmware in electronic devices
US8479189B2 (en) 2000-11-17 2013-07-02 Hewlett-Packard Development Company, L.P. Pattern detection preprocessor in an electronic device update generation system
US8555273B1 (en) 2003-09-17 2013-10-08 Palm. Inc. Network for updating electronic devices
US7904895B1 (en) 2004-04-21 2011-03-08 Hewlett-Packard Develpment Company, L.P. Firmware update in electronic devices employing update agent in a flash memory card
US7366589B2 (en) * 2004-05-13 2008-04-29 General Motors Corporation Method and system for remote reflash
US8526940B1 (en) 2004-08-17 2013-09-03 Palm, Inc. Centralized rules repository for smart phone customer care
US20070185624A1 (en) * 2006-02-07 2007-08-09 General Motors Corporation Method for remote reprogramming of vehicle flash memory
WO2007146710A2 (en) 2006-06-08 2007-12-21 Hewlett-Packard Development Company, L.P. Device management in a network
US8752044B2 (en) 2006-07-27 2014-06-10 Qualcomm Incorporated User experience and dependency management in a mobile device
DE102007039809A1 (de) * 2007-08-23 2009-02-26 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Bordnetz zur Aktualisierung der Software in mindestens einem Steuergerät eines Kraftfahrzeugs mit einem USB-Speicherstick
US8397228B2 (en) * 2007-11-14 2013-03-12 Continental Automotive Systems, Inc. Systems and methods for updating device software
US9652755B2 (en) * 2009-08-11 2017-05-16 Silver Spring Networks, Inc. Method and system for securely updating field upgradeable units
US8881134B2 (en) * 2010-04-29 2014-11-04 International Business Machines Corporation Updating elements in data storage facility using predefined state machine over extended time period
CN102073522A (zh) * 2011-01-13 2011-05-25 深圳市科陆电子科技股份有限公司 面向嵌入式系统的应用程序在线自我更新方法
CN102591692B (zh) * 2012-01-11 2015-07-29 株洲南车时代电气股份有限公司 一种电力机车微机控制柜控制软件升级更新方法
CN103631607B (zh) * 2012-08-21 2016-10-05 广州汽车集团股份有限公司 一种车载ecu软件刷新防错方法及系统
US20140058532A1 (en) * 2012-08-23 2014-02-27 GM Global Technology Operations LLC Method for partial flashing of ecus
JP5702829B2 (ja) * 2013-05-23 2015-04-15 本田技研工業株式会社 中継装置
CN104702631B (zh) * 2013-12-04 2018-04-10 航天信息股份有限公司 一种客户端软件的升级方法和系统
JP6281535B2 (ja) * 2015-07-23 2018-02-21 株式会社デンソー 中継装置、ｅｃｕ、及び、車載システム
DE102015214382A1 (de) 2015-07-29 2017-02-02 Robert Bosch Gmbh Verfahren und Vorrichtung zum Aktualisieren eines Steuergerätes mit einem Bootmanager, einem Hypervisor und mindestens einem unter dem Hypervisor betriebenen Gastsystem
US9959125B2 (en) * 2015-08-05 2018-05-01 Samsung Electronics Co., Ltd. Field update of boot loader using regular device firmware update procedure
US10402561B2 (en) * 2015-10-01 2019-09-03 Samsung Electronics Co., Ltd. Apparatus and method for protection of critical embedded system components via hardware-isolated secure element-based monitor
DE102016201769A1 (de) 2016-01-20 2017-07-20 Robert Bosch Gmbh Verfahren zum Aktualisieren von Software eines Steuergerätes, vorzugsweise für ein Kraftfahrzeug
DE102016200711A1 (de) 2016-01-20 2017-07-20 Robert Bosch Gmbh Verfahren zum Aktualisieren von Software eines Steuergerätes, vorzugsweise für ein Kraftfahrzeug
KR102068228B1 (ko) * 2016-04-12 2020-01-21 가드녹스 사이버 테크놀로지스 엘티디. 보안 록다운을 구현하도록 구성되는 관련 디바이스 및 그 사용 방법을 갖는 특별히 프로그래밍된 컴퓨터 시스템
DE102016221108A1 (de) * 2016-10-26 2018-04-26 Volkswagen Aktiengesellschaft Verfahren zum Aktualisieren einer Software eines Steuergeräts eines Fahrzeugs
FR3077399A1 (fr) * 2018-01-29 2019-08-02 Psa Automobiles Sa Dispositif et procede pour eviter l’obsolescence des calculateurs a logiciel telechargeable utilisant une memoire a duree de retention limitee

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5838981A (en) * 1995-10-05 1998-11-17 Ricoh Company, Ltd. Data communication apparatus with a program renewal function
US5701492A (en) * 1996-03-29 1997-12-23 Canon Kabushiki Kaisha Fail-safe flashing of EPROM
JP2001056787A (ja) * 1999-08-20 2001-02-27 Fujitsu General Ltd メモリ書込装置およびその書込方法
US6718407B2 (en) * 1999-09-30 2004-04-06 Intel Corporation Multiplexer selecting one of input/output data from a low pin count interface and a program information to update a firmware device from a communication interface
JP2001209543A (ja) * 2000-01-28 2001-08-03 Nec Ic Microcomput Syst Ltd フラッシュ・マイコンにおけるプログラム書き換え方法
US6442067B1 (en) * 2000-05-23 2002-08-27 Compaq Information Technologies Group, L.P. Recovery ROM for array controllers
EP1260907A1 (de) * 2001-10-16 2002-11-27 Siemens Schweiz AG Verfahren zur persistenten Speicherung von Daten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
US20060248172A1 (en) 2006-11-02
DE112004001633D2 (de) 2006-06-22
WO2005004160A3 (de) 2006-03-16
WO2005004160A2 (de) 2005-01-13
JP2007507016A (ja) 2007-03-22

Similar Documents

Publication Publication Date Title
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
DE19580589C2 (de) Verfahren zum Aktualisieren und Wiederherstellen von Systemdateien
WO2017013134A1 (de) Verfahren und system zur firmware-aktualisierung einer steuereinrichtung zur prozesssteuerung
DE102009020389A1 (de) System zur Aktualisierung von Firmware und Verfahren dazu, und Verfahren zum Erzeugen von Firmware
EP1903436B1 (de) Computersystem und Verfahren zum Aktualisieren von Programmcode
EP1346881A2 (de) Verfahren und Vorrichtung zum Übernehmen von Daten
DE102011075776A1 (de) Verfahren und System zum Aktualisieren eines gemeinsam genutzten Speichers
DE4235193A1 (de) Netzwerksystem und zugehoeriges softwareverwaltungsverfahren
EP2705410A1 (de) Verfahren und system zum bereitstellen von gerätespezifischen betreiberdaten für ein automatisierungsgerät einer automatisierungsanlage
DE60205162T2 (de) Verfahren zur Verwaltung eines Netzwerkgerätes, Verwaltungssystem und Netzwerkgerät
DE19839680B4 (de) Verfahren und Vorrichtung zur Veränderung des Speicherinhalts von Steuergeräten
WO2003003200A1 (de) Verfahren zum übertragen von software-modulen
DE102011102425A1 (de) Simultanes Softwareupdate
EP3128383A1 (de) Feldgerät
EP1804144A1 (de) Überprüfung des Steuerprogramms eines Steuergerätes für eine Maschine
WO2017050557A1 (de) System und verfahren zur verteilung und/oder aktualisierung von software in vernetzten steuereinrichtungen eines fahrzeugs
WO2005022382A2 (de) Verfahren zur installation einer programmkomponente
DE10234063A1 (de) Verfahren zum variantenspezifischen Programmieren eines Programm- und Datenspeichers eines Steuergeräts, insbesondere eines Steuergeräts eines Kraftfahrzeugs
DE102006038428A1 (de) Verfahren zur Programmierung eines Steuergerätes eines Kraftfahrzeugs
EP2628706A1 (de) Gewerbliches Fahrzeug, insbesondere Gabelstapler oder Flurförderzeug, mit einem fahrzeugseitig fest angebrachten Datenspeicher in Zuordnung zu einer parametrierbaren elektronischen Steueranordnung
DE69916682T2 (de) Verfahren zum Entriegeln des Zugriffs auf einen Rechner von einem Fernladungssystem einer Datei
DE102010016257A1 (de) Generisches Firmware-Fileformat
DE102019103985A1 (de) System und Verfahren zur Übertragung eines Betriebssoftware-Updates auf ein sicherheitsgerichtetes Gerät
DE102006030979A1 (de) Anordnung und Verfahren zum Laden von Daten in einen Speicher
EP3811203A1 (de) Verfahren zum aktualisieren von software auf einem zielgerät

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 PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL HR LT LV MK

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 9/445 20060101AFI20060331BHEP

PUAK Availability of information related to the publication of the international search report

Free format text: ORIGINAL CODE: 0009015

DAX Request for extension of the european patent (deleted)
17P Request for examination filed

Effective date: 20060918

RBV Designated contracting states (corrected)

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

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090106