WO2007042567A1 - System zur durchführung von softwareupdates in embedded systemen sowie ein verfahren dazu - Google Patents

System zur durchführung von softwareupdates in embedded systemen sowie ein verfahren dazu Download PDF

Info

Publication number
WO2007042567A1
WO2007042567A1 PCT/EP2006/067382 EP2006067382W WO2007042567A1 WO 2007042567 A1 WO2007042567 A1 WO 2007042567A1 EP 2006067382 W EP2006067382 W EP 2006067382W WO 2007042567 A1 WO2007042567 A1 WO 2007042567A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory area
memory
software
copy
area
Prior art date
Application number
PCT/EP2006/067382
Other languages
English (en)
French (fr)
Inventor
Michael Beutling
Jens Colberg
Kay Köster
Wolfgang Röhl
Harald Walter
Original Assignee
Siemens Aktiengesellschaft
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 Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2007042567A1 publication Critical patent/WO2007042567A1/de

Links

Classifications

    • 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
    • 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

Definitions

  • the present invention relates to a system for performing software updates in embedded systems, comprising a memory, a controller associated with the memory, and a bootloader, and a method thereto according to the preamble of claim 7.
  • Such a system and method for performing software updates in embedded systems is well known from the prior Tech ⁇ technology.
  • So-called embedded systems are a special kind of small computers that are used in certain products and usually take over control, monitoring or operating tasks there.
  • Some examples of such embedded systems are the ABS, ESP and engine electronics functions known in vehicles. Replace in aircraft they zen processes the mechanical control by electronic control ⁇ , and they are also used in mobile phones to manage these next call appointments and addresses.
  • Embedded systems are also used in ticket machines, baking machines and modern washing machines and much more. Embedded systems are self-contained systems Sys ⁇ who work independently and are not dependent on other systems.
  • the software of an embedded system is to be updated, that is to say a software update is to be carried out, then the outside system must be intervened in the self-contained system so that it loses its independence.
  • the embedded system is usually put into an operating state in which the user who must monitor the system to prevent malfunction or intervene if necessary. As part of the monitoring, for example, the user must ensure that the power supply or the data feed is not interrupted.
  • the object of the present invention is now to taping a fully automatic execution of software updates to rea ⁇ that a secure Fort ⁇ management in case of a failure of the independent operation of the respective EMBED guaranteed ded system.
  • the task is solved by a system for performing software updates in embedded systems in which the bootloader is written into the controller and in which the memory has a program memory area and a copy memory area whose memory size matches the software to be recorded is adjusted. With this design it is possible to safely transfer software to at least one of the two storage areas. to load them then from this memory area in the other memory area.
  • the software is especially safe when the boot loader is written to the start sector of the controller.
  • OTP module One Time Programmable
  • the bootloader is configured such that it knows only hardware for the connection of the program memory area. With this configuration, it is possible that the remainder of the circuit may change in the course of further development without adversely affecting the system according to the invention.
  • the above object is also achieved according to the invention by a method for carrying out software updates in embedded systems, in which the boot loader is written into the controller and the memory is subdivided into a program memory area and a copy memory area, whose memory size is assigned to the respective software to be adapted.
  • An advantage of the method according to the invention is that a software update when it is loaded is first written into the copy memory area and, after the download has been completed, the software update loaded into the copy memory area is written into the program memory area. This measure makes it possible for the embedded system to continue working with the old software in the program memory area during the loading process of the software update into the copy memory area. First after successful completion of the loading process, the new software is then written in the copy memory area in the program memory area, in which case the old software existing there will be overwritten.
  • the system and method of the present invention use a memory, such as a flash memory or EEPROM memory, as well as a microcontroller (.mu.C) and a custom bootloader written to the boot sector thereof.
  • the boot loader may be stored in a non-volatile storage area, e.g. B. an electronic OTP module containing a non-volatile memory (EEPROM), be stored.
  • the memory comprises egg ⁇ NEN first program storage area and a second Kopie- memory area which are respectively adapted to the size of the software or to the required for charging of a software update size. Due to the fact that by means of Bootloader takes over the writing, reading and deleting of data, it can be configured so that it only needs to know the hardware for the activation of the program memory area. The rest of the circuit may change as the development progresses.
  • the boot loader checks the contents of the program Speicherbe ⁇ Empire and copy storage area on its function ⁇ airworthiness. In practice, the two memory areas are checked in particular for their validity, for example
  • the Bootma ⁇ remains rodent in the boot state.
  • the boat Condition remains and än ⁇ changed up until a further review has validity for the implementation of a software update, for example, the operating software revealed.
  • the boot manager then exits the boot state and writes the software update to the copy memory area. If the transfer of the software update was successful, then the program storage area will be described with the updated data of the copy storage area. If then both memory areas (same chip) have a valid program, the software will be restarted.
  • the contents of the program memory area and the copy memory area are checked for validity each time they are started. If only the content (software) of the program memory area or the copy memory area is valid, the invalid content of the other memory area is overwritten with the valid software of the one memory area.
  • the boot loader manages the operating software (firmware). He ensures that it is always in a good condition.
  • the operating software and the boot loader ar ⁇ BEITEN closely together. This allows routines to be used by the bootloader to describe their own and other flash areas without having to swap out any software.
  • the ⁇ se ability of the boot loader is important as a flash memory when writing is not read capable.
  • a hardware ID can be implemented in the bootloader. This means you can identify the products software and hardware without additional effort.
  • a second download system can be implemented in the bootloader, which programmably programs environment parameters in the flash memory.
  • maximum limits of a control voltage or a pressure can be fixed and set captive. This is made possible by the fact that after the memory area has been deleted, this data is taken over again by the copy memory area or the program memory area.
  • the operating software remains universal and after the software update, important data can not be lost. Changing the data is only possible with additional tools. After a single setting, these data can no longer be changed without tools.
  • routines from the boot loader for managing other existing pages from the flash memory for data, such as a data logger, for adjustable parameters which are customized nen Kings ⁇ , etc ..
  • data such as a data logger
  • adjustable parameters which are customized nen Kings ⁇ , etc .
  • the system and method according to the invention can also be used in modern microcontrollers which have a subdivided or a plurality of internal flash memories.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

Ein System und ein Verfahren zur Durchführung von Softwareupdates in Embedded Systemen umfasst einen Speicher mit einem Programm-Speicherbereich und einem Kopie-Speicherbereich sowie einen, dem Speicher zugeordneten Controller, in den ein Bootloader geschrieben ist, wobei ein Softwareupdate zunächst in den Kopie-Speicherbereich geladen wird und erst nach erfolgreicher Ladung in den Programm-Speicherbereich geschrieben wird. Bei erfolgloser Ladung des Softwareupdates in den Kopie-Speicherbereich, wird dieser wieder mit der alten Software aus dem Programm-Speicherbereich überschrieben.

Description

Beschreibung
System zur Durchführung von Softwareupdates in Embedded Sys¬ temen sowie ein Verfahren dazu
Die vorliegende Erfindung betrifft ein System zur Durchführung von Softwareupdates in Embedded Systemen, mit einem Speicher, einem dem Speicher zugeordneten Controller und mit einem Bootloader sowie ein Verfahren dazu gemäß Oberbegriff von Anspruch 7.
Ein solches System und Verfahren zur Durchführung von Softwareupdates in Embedded Systemen ist aus dem Stand der Tech¬ nik allgemein bekannt. So genannte Embedded Systeme sind eine besondere Art von kleinen Computern, die in bestimmten Produkten eingesetzt werden und dort in der Regel Steuerungs-, Kontroll- oder Bedienaufgaben übernehmen. Einige Beispiele solcher Embedded Systeme sind die in Fahrzeugen bekannten ABS, ESP und Motorelektronikfunktionen. In Flugzeugen erset- zen sie die mechanische Steuerung durch elektronische Steuer¬ vorgänge, und sie werden auch in Mobiltelefonen eingesetzt, um mit diesen neben Anrufen auch Termine und Adressen zu verwalten. Embedded Systeme finden aber auch Anwendung in Fahrkartenautomaten, Backautomaten und modernen Waschmaschinen u.v.m.. Die Embedded Systeme sind in sich abgeschlossene Sys¬ teme, die selbstständig arbeiten und nicht auf andere Systeme angewiesen sind.
Falls die Software eines Embedded Systems aktualisiert werden soll, das heißt, ein Softwareupdate durchzuführen ist, muss von außen in das an sich abgeschlossene System eingegriffen werden, so dass es seine Unabhängigkeit verliert. Für die Durchführung eines Softwareupdates wird das Embedded System zumeist in einen Betriebszustand versetzt, bei dem der Anwen- der das System überwachen muss, um Fehlfunktionen zu unterbinden bzw. bei Bedarf einzugreifen. Im Rahmen der Überwachung ist zum Beispiel vom Anwender darauf zu achten, dass die Stromversorgung oder die Datenzufuhr nicht unterbrochen werden darf.
Wenn aus irgendeinem Grund die Aktualisierung der Software fehl schlägt, muss die alte Software wieder voll funktionsfä¬ hig und ohne Einschränkungen ihren alten Dienst aufnehmen. Zur Wahrung der Unabhängigkeit der Embedded Systeme kann eine Standardsoftware oder auch ein Notprogramm nicht genutzt wer¬ den, da nicht sicher gestellt ist, ob die Peripherie dazu kompatibel ist. Systeme und Verfahren des eingangs genannten Standes der Technik laden einen Bootloader in einen RAM, der dort gestartet wird. Bei einem Spannungsausfall kann dann das ganze System nicht mehr benutzt werden. Nur durch spezielle, aufwändige Verfahren kann dann die Software neu geladen werden .
Darüber hinaus gibt es auch Geräte, welche die alte Software auslagern, um sie bei einem gescheiterten Softwareupdate wieder zurückzuladen . Solche Geräte nutzen ein bereits vorhande¬ nes zusätzliches Speichermedium, zum Beispiel einen RAM oder eine Festplatte. Bei einem statischen RAM als Zwischenspei- eher fällt das System bei Spannungsverlust aus, da bei Span¬ nungsverlust der Zwischenspeicher seine Daten verliert. Ein zusätzliches Speichermedium, zum Beispiel eine Festplatte o- der eine Flash-Disk, als Zwischenspeicher, steht bei Embedded Systemen aber nicht zur Verfügung.
Darüber hinaus gibt es Systeme, welche zwei separate Speicher verwenden. Dies ist dann erforderlich, wenn ein Flash- Speicher eingesetzt wird, auf dem beim Programmieren kein Programm abgearbeitet werden kann. Durch die Wahl von zwei separaten Speichern ist es möglich, dass auf einem Speicher das Programm abläuft, während der andere Speicher programmiert werden kann. Durch ein Umschalten der Speicher nach einer erfolgreichen Aktualisierung der Software arbeitet das System mit der neuen aktualisierten Software, welche dann die alte Software überschreibt. Auch ein solches System und Ver¬ fahren zur Durchführung von Softwareupdates trägt die Gefahr, dass bei einer Unterbrechung des Flashvorgangs das betreffende Embedded System seine Unabhängigkeit verliert.
Der Nachteil der bekannten Systeme und Verfahren besteht also darin, dass es bisher nicht möglicht ist, ein selbstständiges Softwareupdate in einem Embedded System durchzuführen, welches die Unabhängigkeit des Embedded Systems nicht beein- flusst, keinen zusätzlichen Hardwareaufwand, zum Beispiel durch weitere Speicher, erfordert und darüber hinaus das betreffende Embedded System bei der Durchführung von Soft¬ wareupdates nicht beeinträchtigt, wenn Fehlfunktionen auftre¬ ten .
Die Aufgabe der vorliegenden Erfindung besteht nun darin, eine vollautomatische Durchführung von Softwareupdates zu rea¬ lisieren, die bei Vorliegen eines Fehlers eine sichere Fort¬ führung der unabhängigen Arbeitsweise des betreffenden Embed- ded Systems gewährleistet.
Die Aufgabe wird durch ein System zur Durchführung von Softwareupdates in Embedded Systemen gelöst, bei dem der Bootloa- der in den Controller geschrieben ist und bei dem der Spei- eher einen Programm-Speicherbereich und einen Kopie-Speicherbereich aufweist, deren Speichergröße an die aufzunehmende Software angepasst ist. Mit dieser Bauweise ist es möglich, Software sicher in wenigstens einen der beiden Speicherberei- che zu laden, um diese dann von diesem Speicherbereich in den jeweils anderen Speicherbereich zu schreiben.
Besonders sicher ist die Ladung der Software dann, wenn der Bootloader in den Startsektor des Controllers geschrieben ist .
Die Sicherheit beim Laden der Software wird ferner dadurch erhöht, dass der Bootloader in einen nicht-flüchtigen Spei- cherbereich, z. B. OTP-Baustein (OTP = One Time Programmable) geschrieben ist.
Schließlich ist von Vorteil, dass der Bootloader derart konfiguriert ist, dass dieser ausschließlich eine Hardware für die Anschaltung des Programm-Speicherbereichs kennt. Durch diese Konfiguration ist es möglich, dass sich der Rest der Schaltung im Zuge der Weiterentwicklung ändern kann, ohne dass das erfindungsgemäße System dadurch beeinträchtigt wird.
Die vorstehende Aufgabe wird erfindungsgemäß auch durch ein Verfahren zur Durchführung von Softwareupdates in Embedded Systemen gelöst, bei welchem der Bootloader in den Controller geschrieben wird und der Speicher in einen Programm-Speicherbereich und einen Kopie-Speicherbereich unterteilt wird, de- ren Speichergröße jeweils an die aufzunehmende Software ange- passt ist. Ein Vorteil des erfindungsgemäßen Verfahrens be¬ steht darin, dass ein Softwareupdate bei dessen Ladung zuerst in den Kopie-Speicherbereich geschrieben wird und nach Ab- schluss des Ladevorganges das in den Kopie-Speicherbereich geladene Softwareupdate in den Programm-Speicherbereich geschrieben wird. Durch diese Maßnahme ist es möglich, dass während des Ladevorgangs des Softwareupdates in den Kopie- Speicherbereich das Embedded System noch mit der alten Software im Programm-Speicherbereich weiter arbeiten kann. Erst nach erfolgreichem Abschluss des Ladevorgangs wird dann die neue Software im Kopie-Speicherbereich in den Programm- Speicherbereich geschrieben, wobei dabei dann die dort vorhandene alte Software überschrieben wird.
Ein praktischer Vorteil ergibt sich bei Produkten, die sehr lange im Feld eingesetzt werden sollen, und zwar länger als zehn Jahre. Üblicherweise gewährleisten Halbleiterhersteller zehn Jahre für die Datenerhaltung bei Flash- bzw. EEPROM- Speichern, das heißt, nach zehn Jahren müsste das System durch ein Neueinspielen der Daten aufgefrischt werden. Durch das beschriebene Verfahren kann das System diese Auffrischung selbstständig durchführen. Damit sind Systeme mit Flash- bzw. EEPROM-Speichern auch länger als zehn Jahre einsetzbar.
Weitere Vorteile der vorliegenden Erfindung ergeben sich aus den Merkmalen der Unteransprüche 8 bis 11.
Im Folgenden wird nun eine Ausführungsform des Systems und Verfahrens zur Durchführung von Softwareupdates in Embedded Systemen beschrieben.
Das System und das Verfahren der vorliegenden Erfindung verwenden einen Speicher, wie beispielsweise einen Flash-Spei- eher oder einen EEPROM-Speicher, sowie einen MikroController (μC) und einen in den Startsektor desselben geschriebenen, angepassten Bootloader. Zum Beispiel kann der Bootloader in einem nicht-flüchtigen Speicherbereich, z. B. einem elektronischen OTP-Baustein, der einen nicht flüchtigen Speicher (EEPROM) enthält, gespeichert sein. Der Speicher umfasst ei¬ nen ersten Programm-Speicherbereich und einen zweiten Kopie- Speicherbereich, die jeweils an die Größe der Software bzw. an die für einen Ladevorgang eines Softwareupdates benötigte Größe angepasst sind. Aufgrund der Tatsache, mittels dass der Bootloader das Schreiben, Lesen und Löschen von Daten übernimmt, kann er so konfiguriert sein, dass er nur die Hardware für die Anschaltung des Programm-Speicherbereichs kennen muss. Der Rest der Schaltung kann sich im Zuge der Entwick- lung verändern.
Der Bootloader überprüft den Inhalt des Programm-Speicherbe¬ reichs und des Kopie-Speicherbereichs auf seine Funktions¬ tüchtigkeit. In der Praxis werden die beiden Speicherbereiche insbesondere auf ihre Gültigkeit überprüft, zum Beispiel
Checksumme, Identifikation, Ergibt die Überprüfung, dass eine Gültigkeit nicht gegeben ist, verbleibt der Bootma¬ nager im Bootzustand. Der Bootzustand bleibt bestehen und än¬ dert sich erst, wenn eine weitere Überprüfung die Gültigkeit für die Durchführung eines Softwareupdates, zum Beispiel der Betriebssoftware, ergeben hat. Dann verlässt der Bootmanager den Bootzustand und schreibt das Softwareupdate in den Kopie- Speicherbereich. Falls die Übertragung des Softwareupdates erfolgreich war, wird anschließend der Programm-Speicherbe- reich mit den aktualisierten Daten des Kopie-Speicherbereichs beschrieben. Wenn dann beide Speicherbereiche (gleicher Chip) ein gültiges Programm besitzen, wird die Software neu gestartet.
In dem erfindungsgemäßen System und Verfahren wird bei jedem Start der Inhalt des Programm-Speicherbereichs und des Kopie- Speicherbereichs jeweils auf seine Gültigkeit überprüft. Ist nur der Inhalt (die Software) des Programm-Speicherbereichs oder des Kopie-Speicherbereichs gültig, wird der ungültige Inhalt des jeweils anderen Speicherbereichs mit der gültigen Software des einen Speicherbereichs überschrieben.
Auf diese Weise ist sicher gestellt, dass immer eine funk¬ tionsfähige Software im Speicher bleibt. Das Embedded System arbeitet während der Durchführung des Softwareupdates also mit der alten Software. Erst wenn das Softwareupdate in der Kopie vollständig und richtig übernommen ist, verändert der Bootloader den Programm-Speicherbereich so, dass die Software Indikationsparameter (z.B. Checksumme, Identifikation ...) ungültig werden. Es wird dann ein Neustart ausgelöst, weil der Programm-Speicherbereich kein gültiges Programm besitzt, und die Synchronisation der Daten vom Kopie-Speicherbereich zum Programm-Speicherbereich wird durchgeführt.
Für den Fall, dass bei einer solchen Durchführung eines Softwareupdates ein Fehler auftaucht oder die Durchführung unterbrochen worden ist, ist der Inhalt des Kopie-Speicherbereichs ungültig und synchronisiert ein neuer Bootvorgang den Kopie- Speicherbereich mit den Daten des Programm-Speicherbereichs.
Für den Fall, dass nach der Durchführung des Softwareupdates die Übertragung von dem Kopie-Speicherbereich zum Programm- Speicherbereich unterbrochen wird, was im Grunde nur durch einen Hardwarefehler oder durch eine Spannungsunterbrechung bzw. einen Reset möglich ist, wird der Übertragungsvorgang so lange wiederholt, bis der Programm-Speicherbereich beschrie¬ ben ist. Durch Abfrage der Softwareidentifikation kann ermittelt werden, ob die Durchführung des Softwareupdates erfolg- reich war.
Aufgrund der Tatsache, dass Zeitüberschreitungen beim Softwareupdate und beim Flashen immer zu einem Rücksetzen führen, wird immer gewährleistet, dass sich das System nicht in einer Endlosschleife verfängt.
Es ist denkbar, ein Time-out-System vorzusehen, mit welchem der Bootmanager selbstständig ein Update abbrechen kann. Der Bootloader verwaltet die Betriebssoftware (Firmware) . Er stellt sicher, dass sich diese immer in einem ordnungsgemäßen Zustand befindet. Die Betriebssoftware und der Bootloader ar¬ beiten eng zusammen. Damit können Routinen vom Bootloader für das Beschreiben des eigenen und anderer Flashbereiche genutzt werden, ohne dass eine Software ausgelagert werden muss. Die¬ se Fähigkeit des Bootloaders ist wichtig, da ein Flash- Speicher beim Beschreiben nicht lesefähig ist. Zudem kann in dem Bootloader eine Hardware-ID implementiert werden. Damit kann man ohne zusätzlichen Aufwand die Produkte Software- und hardwaremäßig identifizieren.
In einer Variante der vorliegenden Erfindung kann in den Bootloader ein zweites Downloadsystem implementiert werden, welches Umgebungsparameter unverlierbar im Flash-Speicher programmiert. So lassen sich Baugruppen für Systeme initiali¬ sieren. Diese Initialisierungen sind von der Umgebung der Baugruppe abhängig und dienen der Software zur korrekten Initialisierung bestimmter Prozesse. So können zum Beispiel maximale Grenzen einer Regelspannung oder eines Druckes fest und unverlierbar gesetzt werden. Dies wird dadurch möglich, dass nach dem Löschen des Speicherbereichs diese Daten von dem Kopie-Speicherbereich bzw. vom Programm-Speicherbereich wieder übernommen werden. Damit bleibt die Betriebssoftware universell und nach der Durchführung des Softwareupdates kön- nen keine wichtigen Daten verloren gehen. Eine Veränderung der Daten ist nur durch zusätzliche Tools möglich. Nach einem einmaligen Setzen sind diese Daten ohne Tools nicht mehr veränderbar .
Ferner ist es möglich, die Routinen vom Bootloader auch dafür zu nutzen, weitere vorhandene Seiten vom Flash-Speicher für Daten zu verwalten, zum Beispiel als Datenlogger, für einstellbare Parameter, welche individuell angepasst werden kön¬ nen, usw.. Mit dem erfindungsgemäßen System und Verfahren ist es möglich, ein eigenständiges Embedded System aufzubauen, welches selbst den Downloadvorgang überwacht, bei Bedarf abbricht und die Software wieder herstellt. Der Ausfall der Anlage auf¬ grund eines Bitkippers im Flash-Speicher kann durch ein internes Reset wieder behoben werden. Dabei sind keine zusätzlichen Speicherbausteine erforderlich. Der Hardware-Aufwand bleibt unverändert.
Das erfindungsgemäße System und Verfahren ist auch in modernen MikroControllern einsetzbar, welche einen unterteilten oder mehrere interne Flash-Speicher besitzen.

Claims

Patentansprüche
1. System zur Durchführung von Softwareupdates in Embedded Systemen, mit einem Speicher, einem dem Speicher zugeordneten Controller und mit einem Bootloader, dadurch gekennzeichnet, dass der Bootloader in den Controller geschrieben ist und dass der Speicher einen Programm-Speicherbereich und einen Kopie-Speicherbereich aufweist, deren Speichergröße an die aufzunehmende Software angepasst ist.
2. System nach Anspruch 1, dadurch gekennzeichnet, dass der Bootloader in den Startsektor des Controllers ge- schrieben ist.
3. System nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Bootloader in einen nicht-flüchtigen Speicherbereich geschrieben ist.
4. System nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Bootloader derart konfiguriert ist, dass dieser aus- schließlich eine Hardware für die Anschaltung des Programm- Speicherbereichs kennt.
5. System nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass in den Bootloader ein zweites Downloadsystem implementiert ist, welches Umgebungsparameter unverlierbar im Speicher programmiert .
6. System nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Speicher ein Flash-Speicher oder EEPROM-Speicher ist .
7. Verfahren zur Durchführung von Softwareupdates in Embedded Systemen, die einen Speicher, einen dem Speicher zugeordneten Controller und einen Bootloader umfassen, dadurch gekennzeichnet, dass der Bootloader in den Controller geschrieben wird und dass der Speicher in einen Programm-Speicherbereich und einen Kopie-Speicherbereich unterteilt wird, deren Speichergröße an die aufzunehmende Software angepasst ist.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass der Bootloader derart konfiguriert wird, dass dieser ausschließlich eine Hardware für die Anschaltung der Programm-Speicherbereichs kennt.
9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass ein Softwareupdate bei dessen Ladung zuerst in den Ko¬ pie-Speicherbereich geschrieben wird und nach Abschluss des Ladevorganges das in den Kopie-Speicherbereich geladene Soft¬ wareupdate in den Programm-Speicherbereich geschrieben wird.
10. Verfahren nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, dass bei jedem Start des Embedded Systems der Programmspei¬ cher-Bereich und der Kopie-Speicherbereich jeweils auf Gültigkeit überprüft werden und dass bei Vorliegen einer ungül¬ tigen Software im Programm-Speicherbereich oder im Kopie- Speicherbereich der die ungültige Software enthaltende Spei- cherbereich mit dem gültigen Inhalt des jeweils anderen der beiden Speicherbereiche überschrieben wird.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass nach Vorliegen eines gültigen Softwareupdates im Kopie- Speicherbereich der Inhalt des Programm-Speicherbereichs un¬ gültig wird und ein Neustart ausgelöst wird, dem die Über¬ schreibung der Software vom Kopie-Speicherbereich zum Pro- gramm-Speicherbereich folgt.
12. Verfahren nach einem der Ansprüche 7 bis 11, dadurch gekennzeichnet, dass bei Vorliegen eines Update-Fehlers oder einer Unterbre- chung des Ladung des Softwareupdates der Inhalt des Kopie- Speicherbereich ungültig wird und die Software im Programm- Speicherbereich gültig bleibt, wobei dann durch einen neuen Bootvorgang der Kopie-Speicherbereich mit der Software des Programm-Speicherbereichs überschrieben wird.
13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass bei einer Unterbrechung der Übertragung des Softwareupdates vom Kopie-Speicherbereich zum Programm-Speicherbereich der Übertragungsvorgang so lange wiederholt wird, bis der Programm-Speicherbereich beschrieben ist.
14. Verfahren nach einem der Ansprüche 7 bis 13, dadurch gekennzeichnet, dass in den Bootloader ein zweites Downloadsystem implementiert wird, welches Umgebungsparameter unverlierbar im Speicher programmiert .
15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass Umgebungsparameter ausgewählt werden, die von der Umgebung einer System-Baugruppe abhängig sind und von der Soft- wäre genutzt werden, um Prozesse zu initialisieren.
16. Verfahren nach Anspruch 14 oder 15, dadurch gekennzeichnet, dass die Umgebungsparameter ausgewählt sind aus der Gruppe bestehend aus der maximalen Grenze einer Regelspannung und der maximalen Grenze eines Druckes.
PCT/EP2006/067382 2005-10-14 2006-10-13 System zur durchführung von softwareupdates in embedded systemen sowie ein verfahren dazu WO2007042567A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200510050288 DE102005050288A1 (de) 2005-10-14 2005-10-14 System zur Durchführung von Softwareupdates in Embeddded Systemen sowie ein Verfahren dazu
DE102005050288.1 2005-10-14

Publications (1)

Publication Number Publication Date
WO2007042567A1 true WO2007042567A1 (de) 2007-04-19

Family

ID=37401118

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/067382 WO2007042567A1 (de) 2005-10-14 2006-10-13 System zur durchführung von softwareupdates in embedded systemen sowie ein verfahren dazu

Country Status (2)

Country Link
DE (1) DE102005050288A1 (de)
WO (1) WO2007042567A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102023876A (zh) * 2009-09-14 2011-04-20 漳州科能电器有限公司 一种可软件在线升级的嵌入式系统及在线升级方法
CN104156249A (zh) * 2014-08-18 2014-11-19 四川九成信息技术有限公司 嵌入式软件升级方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5701492A (en) * 1996-03-29 1997-12-23 Canon Kabushiki Kaisha Fail-safe flashing of EPROM
EP1052571A2 (de) * 1999-05-13 2000-11-15 ECI Telecom Ltd. Ein Verfahren und Gerät zum Herunterladen von Software in ein eingebettetes System
US20020083427A1 (en) * 2000-12-26 2002-06-27 Chen-Pang Li Embedded system capable of rapidly updating software and method for rapidly updating software of embedded system
EP1271311A2 (de) * 2001-06-30 2003-01-02 Samsung Electronics Co., Ltd. Aktualisierung von Software eines vernetzten Gerätes
US20030229752A1 (en) * 2002-04-01 2003-12-11 Sreekrishnan Venkiteswaran Updating flash memory

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5701492A (en) * 1996-03-29 1997-12-23 Canon Kabushiki Kaisha Fail-safe flashing of EPROM
EP1052571A2 (de) * 1999-05-13 2000-11-15 ECI Telecom Ltd. Ein Verfahren und Gerät zum Herunterladen von Software in ein eingebettetes System
US20020083427A1 (en) * 2000-12-26 2002-06-27 Chen-Pang Li Embedded system capable of rapidly updating software and method for rapidly updating software of embedded system
EP1271311A2 (de) * 2001-06-30 2003-01-02 Samsung Electronics Co., Ltd. Aktualisierung von Software eines vernetzten Gerätes
US20030229752A1 (en) * 2002-04-01 2003-12-11 Sreekrishnan Venkiteswaran Updating flash memory

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102023876A (zh) * 2009-09-14 2011-04-20 漳州科能电器有限公司 一种可软件在线升级的嵌入式系统及在线升级方法
CN102023876B (zh) * 2009-09-14 2013-04-17 漳州科能电器有限公司 一种可软件在线升级的嵌入式系统及在线升级方法
CN104156249A (zh) * 2014-08-18 2014-11-19 四川九成信息技术有限公司 嵌入式软件升级方法

Also Published As

Publication number Publication date
DE102005050288A1 (de) 2007-04-19

Similar Documents

Publication Publication Date Title
EP0721644B1 (de) Verfahren zur vollständigen neuprogrammierung eines löschbaren, nichtflüchtigen speichers
DE10040890C1 (de) System und Verfahren zum sicheren Hochtemperaturbetrieb eines Flash-Speichers
DE102005013285A1 (de) Verfahren zum Konfigurieren eines Steuergeräts und Steuergerät
EP2959377A1 (de) Datenladevorrichtung und datenladeverfahren zum laden von software in flugzeugsysteme
DE10308545A1 (de) Verfahren und Vorrichtung zum Aktualisieren eines verteilten Programms
DE102011075776A1 (de) Verfahren und System zum Aktualisieren eines gemeinsam genutzten Speichers
DE102017124188A1 (de) Verfahren und Vorrichtung zum Steuern eines Speichersystems zum Zwecke eines sicheren Herunterfahrens eines flüchtigen Speichers eines Hosts
DE102015207795A1 (de) Verfahren und Vorrichtung zum Aktualisieren von Software in einem Transportmittel
DE102010039021B4 (de) Verfahren zur Rekonfiguration von Softwareparametern in einem Mikrocontroller sowie Mikrocontroller und Steuergerät
WO2007042567A1 (de) System zur durchführung von softwareupdates in embedded systemen sowie ein verfahren dazu
EP2608037B1 (de) Verfahren zum Verwalten von Daten in einem Flash-Speicher, Fahrerassistenzeinrichtung und Kraftfahrzeug
WO2017125182A1 (de) Verfahren zum aktualisieren von software eines steuergerätes, vorzugsweise für ein kraftfahrzeug
DE102016106572A1 (de) Verfahren zum betreiben eines steuergeräts für ein fahrzeug, steuergerät, betriebssystem, kraftfahrzeug
DE10030990B4 (de) Verfahren zum Beschreiben und Löschen eines nichtflüchtigen Speicherbereichs
DE102006004599A1 (de) Endgerät und Verfahren zur Aktualisierung von Programmcode eines Endgeräts
DE10115630C2 (de) Steuerschaltung mit Datensicherung und Verfahren zur Datensicherung
EP1967920A1 (de) Verfahren zur Durchführung von Softwareupdates in FPGA-basierte Automatisierungsgeräte
DE102019000493A1 (de) Verfahren zur Aktualisierung einer jeweiligen Software mehrerer Steuergeräte eines Fahrzeugs
EP0715313B1 (de) Verfahren zur Programmierung eines elektrisch löschbaren, nichtflüchtigen Speichers in einem elektronischen Rechengerät sowie Steuergerät zur Verwendung bei dem Verfahren
EP2116911B1 (de) Automatisierungssystem und Verfahren zur Wiederherstellung der Betriebsfähigkeit eines Automatisierungssytems
DE102012218665B4 (de) Applikationssystem für Steuergeräte
EP2037360A2 (de) Steuergerät für einen Massenspeicher und Verfahren zum Bereitstellen von Daten für einen Startvorgang eines Computers
DE102016211772A1 (de) Verfahren und Vorrichtung zum Aktualisieren mehrerer Steuergeräte über einen gemeinsamen Feldbus
DE102012111179B4 (de) Computersystem, Verfahren zum Sichern von Systemeinstellungen und Verfahren zum Wiederherstellen von Systemeinstellungen
DE19708441A1 (de) Verfahren zum Schreiben und Lesen von für den Betrieb einer Fahrzeugkomponente relevanten Betriebsparametern in einen bzw. aus einem Schreib/Lese-Speicher

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06807246

Country of ref document: EP

Kind code of ref document: A1