COLBERG, Jens (Ernst-Thälmann-Str. 79, Bindow, 15754, DE)
KÖSTER, Kay (Karl-Marx-Str. 7, Fredersdorf, 15370, DE)
RÖHL, Wolfgang (Im Rehgrund 43 A, Berlin, 13503, DE)
WALTER, Harald (Köppenzeile 102, Berlin, 12557, DE)
BEUTLING, Michael (Päwesinerweg 41a, Berlin, 13581, DE)
COLBERG, Jens (Ernst-Thälmann-Str. 79, Bindow, 15754, DE)
KÖSTER, Kay (Karl-Marx-Str. 7, Fredersdorf, 15370, DE)
RÖHL, Wolfgang (Im Rehgrund 43 A, Berlin, 13503, DE)
WALTER, Harald (Köppenzeile 102, Berlin, 12557, DE)
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. |
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.