DE102011075776A1

DE102011075776A1 - Verfahren und System zum Aktualisieren eines gemeinsam genutzten Speichers

Info

Publication number: DE102011075776A1
Application number: DE102011075776A
Authority: DE
Inventors: Antoni Ferre Fabregas; Jose Gabriel Fernandez Banares; David Gamez Alari; Stanislav Lincer
Original assignee: Lear Corp
Current assignee: Lear Corp
Priority date: 2010-06-09
Filing date: 2011-05-13
Publication date: 2011-12-15
Also published as: US20110307668A1; CN102279807A; CN102279807B; US8539472B2

Abstract

Es werden ein Verfahren und ein System zum Aktualisieren eines gemeinsam genutzten Speichers oder einer anderen Speicherposition angegeben, wobei mehrere Einheiten einen im gleichen Speicher gespeicherten Code verwenden, um eine oder mehrere Operationsfunktionen zu unterstützen. Der gemeinsam genutzte Speicher kann derart aktualisiert werden, dass der Code, der den derzeit gespeicherten Code ersetzen soll, verwendet werden kann, bevor er den derzeit in dem gemeinsam genutzten Speicher geschriebenen Code ersetzt.

Description

Die vorliegende Patentanmeldung ist mit der gleichzeitig eingereichten US-Patentanmeldung Nr. 12/796,833 mit dem Titel „Shared Memory Architecture” vom 9. Juni 2010 verwandt, die hier vollständig unter Bezugnahme eingeschlossen ist.
Die vorliegende Erfindung betrifft Verfahren und Systeme zum Aktualisieren eines gemeinsam genutzten Speichers wie er etwa in einem Fahrzeug verwendet wird.
In einer gemeinsam genutzten Architektur muss unter Umständen der in den gemeinsam genutzten Speicherblock geschriebene Code aktualisiert oder auf andere Weise ersetzt werden, während die Softwarefunktion in dem gemeinsam genutzten Speicherblock verwendet wird. Dies kann zum Beispiel dann der Fall sein, wenn der Code Protokolländerungen zum Beheben von Betriebsfehlern usw. unterstützen soll.
Die vorliegende Erfindung wird durch die beigefügten Ansprüche definiert. Die Merkmale der Erfindung werden durch die folgende ausführliche Beschreibung mit Bezug auf die Figuren verdeutlicht.
1 zeigt ein Fahrzeug-Steuersystem gemäß einem nicht-einschränkenden Aspekt der Erfindung.
2 ist ein Flussdiagramm zu einem Verfahren zum Aktualisieren eines gemeinsam genutzten Speicherblocks gemäß einem nicht-einschränkenden Aspekt der vorliegenden Erfindung.
1 zeigt ein Fahrzeug-Steuersystem 10 gemäß einem nicht-einschränkenden Aspekt der vorliegenden Erfindung. Das Fahrzeug-Steuersystem 10 kann in einem Fahrzeug (nicht gezeigt) enthalten sein, das eine Anzahl von Fahrzeug-Subsystemen (nicht gezeigt) umfasst, die durch eine oder mehrere Fahrzeug-Subsystem-Steuereinrichtungen 12, 14, 16 gesteuert werden, wobei es sich um Informations- und Unterhaltungs-, Sicherheits-(Passivöffnungs-/Funkschließ-), Beleuchtungs-, Heizungs-, Klimaanlagen- und Motorsteuerungs-Subsysteme handeln kann. Der Betrieb, die Aktualisierung, die Interaktion und die Steuerung der Fahrzeug-Subsysteme können durch Kommunikationen angewiesen werden, die in Übereinstimmung mit Befehlen aus einer Master-Steuereinrichtung 20 über einen Fahrzeugbus 18 übertragen werden. Das hier beschriebene Fahrzeug-Steuersystem 10 stellt lediglich eine beispielhafte Umgebung dar, in der die Erfindung angewendet werden kann. Die Erfindung kann auch auf andere Anwendungen als in Fahrzeugen angewendet werden.
Die hier beschriebene Fahrzeug-Umgebung ist eine Umgebung, in der es erforderlich sein kann, einen Speicher 22 mit einem gemeinsam genutzten Speicherblock 24 periodisch zu aktualisieren. Die Fahrzeug-Umgebung ist weiterhin eine Umgebung, in der die Steuereinrichtungen 12, 14, 16 unter Umständen über einen Kommunikationsbus 18 und/oder drahtlos mit anderen Steuereinrichtungen 12, 14, 16 kommunizieren. In der beispielhaften Umgebung ist die Steuereinrichtung 16 eine Batterieüberwachungssystem(BMS)-Steuereinrichtung 16. Die BMS-Steuereinrichtung 16 ist konfiguriert, um in Verbindung mit der Hardware eines BMS (nicht gezeigt) betrieben zu werden, die zum Beispiel verwendet werden kann, um den Stromfluss und die Batterietemperatur zu messen und eine Anzahl von Operationen in Bezug auf eine Fahrzeugbatterie auszuführen. Die US-Patentanmeldung Nr. 12/486,847 mit dem Titel „Battery Monitoring System”, die hier vollständig unter Bezugnahme eingeschlossen ist, beschreibt ein derartiges Batterieüberwachungssystem.
Zusätzlich zu dem gemeinsam genutzten Speicherblock 24 umfasst der Speicher 22 der BMS-Steuereinrichtung 16 einen Starter-Speicherblock 28 und einen Anwendungs-Speicherblock 30. Obwohl hier nicht gezeigt, kann der Speicher 22 ein nicht-flüchtiger Speicher wie etwa ein RAM sein, der in Verbindung mit dem Starter, der Anwendung und den gemeinsam genutzten Speicherblöcken 24, 28, 30, die flüchtig oder nicht-flüchtig sein können, verwendet werden kann. Der Anwendungs-Speicherblock 30 speichert Code oder Daten, die mit einer Anwendung assoziiert sind. Die Anwendung kann eine Operation zum Ausführen verschiedener mit dem Batterieüberwachungssystem assoziierten Funktionen sein, die etwa das Messen und Berichten eines Stromflusses zu einer oder mehreren anderen Steuereinrichtungen (der Master ist ebenfalls als eine Steuereinrichtung zu betrachten) umfassen. Der Starter-Speicherblock 28 speichert Code, der mit einem Starter assoziiert ist. Der Starter kann konfiguriert sein, um das Starten oder Initialisieren des Batterieüberwachungssystems zu leisten, wobei er Treiber 32 lädt und/oder andere Operationen ausführt, die die Anwendung benötigt, um die gewünschten Funktionen zu erfüllen.
Die hier gezeigte BMS-Steuereinrichtung 16 umfasst eine CPU 34. Die CPU 34 kann konfiguriert sein, um Operationen in Übereinstimmung mit aus dem Speicher 22 gelesenen Befehlen auszuführen, wobei die Operationen zum Beispiel mit dem Starter und der Anwendung assoziiert sind. Die CPU 34 kann auch konfiguriert sein, um Code in den Speicher 22 zu schreiben, und unterstützt auf diese Weise die weiter unten ausführlicher beschriebenen Operationen. Die CPU 34 interagiert mit den Treibern 32, die verwendet werden, um mit den Hardware-Komponenten des Batterieüberwachungssystems wie etwa mit den Hardware-Komponenten zum Unterstützen der Kommunikationen mit den anderen Steuereinrichtungen 12, 14 über den Fahrzeugbus 18 zu interagieren.
Die zwischen der BMS-Steuereinrichtung 16 und einer oder mehreren der anderen Steuereinrichtungen 12, 14 ausgeführten Kommunikationen können in Übereinstimmung mit einem in dem gemeinsam genutzten Speicherblock 24 gespeicherten Kommunikationscode angewiesen und/oder ausgeführt werden. Der Kommunikationscode kann in dem gemeinsam genutzten Speicherblock 24 gespeichert sein und kann durch den Starter und die Anwendung verwendet werden, wenn Operationen in Zusammenhang mit der Kommunikation ausgeführt werden (optional kann der gemeinsam genutzte Speicher 24 durch andere in der BMS-Steuereinrichtung 16 ausgeführte Anwendungen und/oder Funktionen verwendet werden). Die Verwendung des gemeinsam genutzten Speichers 24 kann vorteilhaft sein, wenn das Volumen des für die Kommunikationen benötigten Kommunikationscodes größer ist. Indem der Kommunikationscode gemeinsam genutzt werden kann und keine separaten Sätze des Kommunikationscodes für den Starter und die Anwendung gespeichert werden müssen, kann das Gesamtvolumen des Kommunikationscodes für die Unterstützung des Starters, der Anwendung und anderer von der Kommunikation abhängiger Elemente (sofern vorhanden) reduziert werden.
2 ist ein Flussdiagramm 50 zu einem Verfahren zum Aktualisieren eines gemeinsam genutzten Speicherblocks gemäß einem nicht-einschränkenden Aspekt der vorliegenden Erfindung. Mit diesem Verfahren kann ein gemeinsam genutzter Speicherblock aktualisiert werden, ohne dass dabei die durch den gemeinsam genutzten Speicherblock unterstützten Operationen verloren gehen und/oder indem eine Operation in Übereinstimmung mit einem neuen Code ermöglicht wird, bevor der neue Code in den gemeinsam genutzten Speicherblock geschrieben wird. Wenn in diesem Fall der gemeinsam genutzte Speicherblock 24 verwendet wird, um den durch den Starter und die Anwendung benötigten Kommunikationscode zu speichern, wird gemäß wenigstens einem nicht-einschränkenden Aspekt des Verfahrens der Erfindung ermöglicht, dass der gemeinsam genutzte Speicherblock 24 aktualisiert wird, ohne dass dabei die Kommunikationsfähigkeit verloren geht. Auch wenn die vorstehende Beschreibung beispielhaft auf die Konfiguration von 1 Bezug nimmt, ist das Verfahren der vorliegenden Erfindung nicht auf Fahrzeug-Steuereinrichtungen oder die oben beschriebene BMS-Steuereinrichtung 16 beschränkt.
In Block 52 wird ein Reset ausgeführt, wenn die BMS-Steuereinrichtung 16 neu gestartet oder auf andere Weise initialisiert wird, weil der Starter neue Treiber laden, Ports identifizieren und/oder andere Funktionen ausführen muss, bevor der Betrieb der Anwendung aktiviert wird (die Funktion des Starters kann natürlich auch in Abhängigkeit von der verwendeten Steuereinrichtung und/oder Anwendung sowie von der Hardware und/oder den damit assoziierten Funktionen variieren). In Block 54 führt die CPU die Operationen des Starters in Übereinstimmung mit einem aus dem Starter-Speicherblock gelesenen Code aus.
In Block 56 wird das Vorhandensein des gemeinsam genutzten Codes, d. h also des in den gemeinsam genutzten Speicherblock geschriebenen Kommunikationscodes, geprüft. Wenn der gemeinsam genutzte Code erfasst wird, wird in Block 58 geprüft, ob der Anwendungscode (Code) korrekt in dem Anwendung-Speicherblock 30 gespeichert ist oder ein korrektes Upgrade-Kennwort gesetzt wurde. Der Anwendungscode kann als korrekt gespeichert betrachtet werden, wenn der gesamte mit der Anwendung assoziierte Code in den Anwendungs-Speicherblock 30 geschrieben wurde, sodass die Anwendung vollständig ausgeführt werden kann, und/oder wenn das Kennwort korrekt für eine annehmbare Verwendung des gespeicherten Codes aktualisiert wurde und dementsprechend der Code wieder verwendet werden kann, wenn er zuvor nicht unbrauchbar gemacht wurde. Die korrekt gespeicherte Anwendung kann dann in Block 62 ausgeführt werden. In Block 64 wird geprüft, ob zum Beispiel von der Master-Steuereinrichtung 20 ein Befehl zum Löschen, Upgraden oder andersartigen Ändern des Speichers empfangen wurde, um zum Beispiel den in dem gemeinsam genutzten Speicherblock 22 gespeicherten Kommunikationscode zu aktualisieren. Wenn kein derartiger Befehl empfangen wird, wird die Anwendung weiter ausgeführt.
Wenn ein Befehl zum Aktualisieren des Codes empfangen wird, wird der Anwendungs-Speicherblock des Speichers unbrauchbar gemacht oder als nicht in Verbindung mit einem Upgrade zu einem in Block 66 gesetzten Kennwort verwendbar gekennzeichnet. Durch das Unbrauchbarmachen wird die Anwendung außer Funktion gesetzt, sodass der Anwendungscode erneut in den Anwendungs-Speicherblock 30 geschrieben werden muss, um die Anwendung erneut funktionsfähig zu machen. In dem Kennwort-Upgrade wird einfach die mit dem Code assoziierte Bezeichnung geändert, sodass der Code später verwendet werden kann, ohne erneut geladen werden zu müssen, sofern der Code bis dahin nicht überschrieben wurde. In Block 68 wird ein Reset oder eine Rückkehr zu Block 52 implementiert. Danach wird zu Block 56 zurückgekehrt, in dem erneut geprüft wird, ob der gemeinsam genutzte Code korrekt in dem gemeinsam genutzten Speicherblock 22 gespeichert ist. Sofern kein Fehler zu einer Störung des gemeinsam genutzten Codes geführt hat, sollte der gemeinsam genutzte Code korrekt gespeichert sein und wird der Anwendungscode erneut in Block 58 geprüft.
Bei einem Unbrauchbarmachen wird der Anwendungscode nicht korrekt gespeichert und wird in Block 74 ein Bootloader ausgeführt. Optional kann der Bootloaer betrieben werden, ohne den Code unbrauchbar zu machen, etwa indem ein Zugriffscode oder eine andere Autorisierungsoption gesetzt wird. Zum Beispiel kann der Bootloader das Aktualisieren des gemeinsam genutzten Codes durch Kommunikationen mit einem autorisierten Master bestätigen. Der Bootloader kann eine Operation oder Reihe von Ereignissen sein, die in Übereinstimmung mit einem entsprechenden in dem Starter-Speicherblock 28 gespeicherten Code implementiert werden. Wenn der in dem Block 64 registrierte Befehl durch die Master-Steuereinrichtung 20 gesendet wurde, um den Kommunikationscode des gemeinsam genutzten Speicherblocks 22 zu aktualisieren, beginnt der Bootloader damit, einen neuen Kommunikationscode zu empfangen, damit dieser anstelle des alten Kommunikationscodes in Block 76 geladen wird. Anstatt den neuen Kommunikationscode direkt in dem gemeinsam genutzten Speicherblock 22 zu speichern, erfordert der Block 78, dass der neue Kommunikationscode in dem Anwendungs-Speicherblock gespeichert wird.
Der neue Kommunikationscode kann an einer temporären Speicherposition oder einem Block des Anwendungs-Speicherblocks 30 gespeichert werden. Optional kann Code zum Kopieren des neuen Kommunikationscodes von dem temporären Speicherblock 30 zu dem gemeinsam genutzten Block 24 in dem heruntergeladenen Code enthalten sein. Der temporäre Speicherblock kann einer Position des Anwendungs-Speicherblocks 30 entsprechen, die in Block 66 unbrauchbar gemacht wurde. Optional kann ein Teil des Anwendungs-Speicherblocks 30 mit einer dem temporären Block entsprechenden Größe unbrauchbar gemacht werden, anstatt den gesamten Anwendungs-Speicherblock unbrauchbar zu machen. Durch ein derartiges teilweises Unbrauchbarmachen kann die für das erneute Laden des Anwendungscodes in den Anwendungs-Speicherblock 30 benötigte Zeitdauer verkürzt werden, weil die erneut zu ladenden Teile auf die dem temporären Speicherblock entsprechenden Teile beschränkt werden können. In Block 80 wird bestimmt, ob der neue Kommunikationscode weiterhin von der Master-Steuereinrichtung 20 und/oder von einer anderen mit dem Fahrzeugbus 18 verbundenen oder mit der BMS-Steuereinrichtung kommunizierenden Steuereinrichtung empfangen wird.
Nachdem der gesamte neue Kommunikationscode empfangen wurde, wird in Block 82 geprüft, ob der in dem temporären Speicherblock gespeicherte neue Kommunikationscode gültig ist. Die Gültigkeit des neuen Kommunikationscodes kann zum Beispiel durch eine Prüfsummenoperation geprüft werden, in der eine Prüfsumme des neuen Kommunikationscodes mit einem gewünschten Prüfsummenwert verglichen und als gültig bestimmt wird, wenn die Werte übereinstimmen. Diese Prüfung kann auf der Versionsnummer des neuen Kommunikationscodes beruhen, wobei der gemeinsam genutzte Code nur überschrieben werden kann, wenn die Versionsnummer größer als die aktuelle Versionsnummer ist. Optional kann die Prüfung das Vergleichen eines Kennworts oder einer Quellenangabe umfassen, um sicherzustellen, dass der über den vorhandenen gemeinsam genutzten Code zu schreibende Code durch die Partei autorisiert wurde, die für das Schreiben des bestehenden Kommunikationscodes in den gemeinsam genutzten Speicherblock 22 verantwortlich ist. Wenn der Code nicht gültig ist, wird der Code in Block 84 abgelehnt und wird der Prozess wiederholt. Wenn der Code gültig ist, wird mit Block 88 fortgeschritten, in dem geprüft wird, ob der neue Code in den gemeinsam genutzten Speicherblock 22 kopiert werden soll.
Wenn ein Schreiben des neuen Codes in den gemeinsam genutzten Speicherblock 22 autorisiert wird, wird in Block 90 ein Wartebefehl zu der Master-Steuereinrichtung 20 und/oder der/den anderen Steuereinrichtung(en) kommuniziert. Die Wartemeldung gibt an, dass die BMS-Steuereinrichtung 16 keine Anforderungen verarbeiten kann, bis der neue Kommunikationscode in den gemeinsam genutzten Speicherblock 20 kopiert wurde. Das Kopieren des neuen Codes in den gemeinsam genutzten Speicherblock 22 wird in Block 92 durchgeführt und entspricht dem Kopieren des Codes von dem temporären Speicherblock über den derzeit in dem gemeinsam genutzten Speicherblock 22 gespeicherten Code. Weil der gemeinsam genutzte Speichercode während der Kopieroperation geschrieben wird, können die Kommunikation oder die anderen durch den gemeinsam genutzten Speicherblock 22 unterstützten Operationen während des Kopierens nicht ausgeführt werden. Deshalb werden die Wartebefehle in Übereinstimmung mit dem in dem temporären Speicherblock gespeicherten Kommunikationscode ausgegeben. Die Wartemeldungen können mit regelmäßigen Intervallen ausgegeben werden und/oder können eine bis zum Abschluss des Kopierens erwartete Zeitperiode angeben.
Sobald die Kopieroperation abgeschlossen ist, kehrt die Steuerung der Kommunikationsoperationen in Block 94 zu dem in dem gemeinsam genutzten Speicherblock 22 gespeicherten Code zurück und schreibt dann in Block 96 einen Anwendungscode zurück in den Awendungs-Speicherblock. Optional kann eine Fertigmeldung zu der Master-Steuereinrichtung gegeben werden, nachdem das Kopieren des gemeinsam genutzten Codes abgeschlossen ist. Die Master-Steuereinrichtung kann den Anwendungscode bereitstellen, wobei es sich um denselben oder einen neuen Anwendungscode handeln kann und optional auch nur ein Teil des Anwendungscodes in Entsprechung zu dem temporären Speicherblock ersetzt werden kann. Der Block 98 überwacht, ob der Anwendungscode weiterhin empfangen und/oder in den Anwendungs-Speicherblock geschrieben wird, bevor in Block 100 ein Reset implementiert wird.
In Block 56 wird erneut geprüft, ob der gemeinsam genutzte Speichercode korrekt in dem gemeinsam genutzten Speicherblock gespeichert wurde. Nach dem Kopieren von Block 92 wird diese Prüfung in Bezug auf den neu geschriebenen Kommunikationscode vorgenommen. Falls ein Fehler aufgetreten ist und der neue Code falsch in den gemeinsam genutzten Speicherblock 22 geschrieben wurde oder ein anderes Ereignis zu einem Reset geführt hat, wird in Block 102 geprüft, ob der neue Kommunikationscode korrekt in dem temporären Speicherblock gespeichert wurde. Wenn der Reset vor dem Schreiben der Anwendungsdaten in Block 96 aufgetreten ist, kann der neue Kommunikationscode korrekt in dem temporären Speicherblock gespeichert werden und kann ein weiterer Versuch zum Kopieren des Kommunikationscodes aus dem temporären Speicherblock zu dem gemeinsam genutzten Speicherblock in Block 104 durchgeführt werden. Wenn der temporäre Speicherblock keine korrekte Kopie des gemeinsam genutzten Codes enthält, weil aus einem anderen Grund ein Fehler aufgetreten ist, oder nach Block 96, kann in Block 106 ein Notfahrbetrieb implementiert werden. Der Notfahrbetrieb kann in einer Fahrzeugumgebung automatisch einen gewissen Umfang an Standardfunktionen implementieren, um den Fahrzeugbetrieb in einem eingeschränkten Umfang fortzuführen.
Wie weiter oben beschrieben, betrifft ein nicht-einschränkender Aspekt der vorliegenden Erfindung eine Verminderung der Gesamtgröße des nicht-flüchtigen Speichers für ECU-Einrichtungen, die einen gemeinsam genutzten Speicher verwenden, sodass der Kommunikationscode aktualisiert werden kann, ohne dass die Programmierstrategie verkompliziert wird oder die Programmierzeit verlängert wird, und ein korrekter Upgrade der Kommunikationssoftware sichergestellt werden kann (nur neue Version und nur validierte Version). Gemäß einem nicht-einschränkenden Aspekt der vorliegenden Erfindung wird eine Möglichkeit zum Programmieren einer ECU über einen Kommunikationskanal vorgesehen. Das bedeutet, dass auch eine Kommunikationssoftware in dem Bootloader implementiert werden muss.
Vorstehend wurden verschiedene Ausführungsformen der vorliegenden Erfindung beschrieben, wobei jedoch zu beachten ist, das die hier beschriebenen Ausführungsformen lediglich beispielhaft für die Erfindung sind, die auch auf andere Weise realisiert werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu, wobei einige Teile vergrößert oder verkleinert dargestellt sein können, um die Details bestimmter Komponenten zu verdeutlichen. Die hier beschriebenen Details des Aufbaus und der Funktion sind also nicht einschränkend, sondern lediglich als repräsentative Basis für die Ansprüche und/oder als repräsentative Basis für den Fachmann, der die vorliegende Erfindung realisieren möchte, zu verstehen. Die Merkmale der verschiedenen Ausführungsformen können miteinander kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
Es wurden verschiedene beispielhafte Ausführungsformen beschrieben, wobei die Erfindung jedoch nicht auf die hier beschriebenen Ausführungsformen beschränkt ist. Die Beschreibung ist beispielhaft und nicht einschränkend aufzufassen, wobei verschiedene Änderungen an den beschriebenen Ausführungsformen vorgenommen werden können, ohne dass deshalb der Erfindungsumfang verlassen wird. Weiterhin können die Merkmale der verschiedenen Ausführungsformen miteinander kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.

Claims

Verfahren zum Aktualisieren eines derzeit geschriebenen Kommunikationscodes durch einen neuen Kommunikationscode für die Verwendung mit einem Batterieüberwachungssystem (BMS) einschließlich einer Anwendung, die betrieben werden kann, um den Stromfluss zu einer Fahrzeugbatterie zu messen, und eines Starters, der betrieben werden kann, um durch die Anwendung verwendete Treiber zu aktivieren, wobei der Starter und die Anwendung Kommunikationsfunktionen in Übereinstimmung mit einem in einen gemeinsam genutzten Speicherblock geschriebenen Kommunikationscode implementieren, wobei das Verfahren umfasst: Schreiben des neuen Kommunikationscodes in einen Anwendungs-Speicherblock, der einen Anwendungscode zum Ausführen der Anwendung enthält, wobei die Anwendung nicht betrieben werden kann, während der neue Kommunikationscode in den Anwendungs-Speicherblock geschrieben wird, Ausführen von Kommunikationen auf der Basis des zuvor in den gemeinsam genutzten Speicherblock geschriebenen Kommunikationscodes, während der neue Kommunikationscode in den Anwendungs-Speicherblock geschrieben wird, Kopieren des neuen Kommunikationscodes aus dem Anwendungs-Speicherblock in den gemeinsam genutzten Speicherblock, wobei die durch den in den gemeinsam genutzten Speicherblock geschriebenen Code unterstützten Kommunikationen nicht ausgeführt werden können, während der neue Kommunikationscode in den gemeinsam genutzten Speicherblock geschrieben wird, Ausführen von Kommunikationen auf der Basis des in den Anwendungs-Speicherblock geschriebenen neuen Kommunikationscodes, während der neue Kommunikationscode in den gemeinsam genutzten Speicherblock kopiert wird, und danach Ausführen von weiteren Kommunikationen auf der Basis des in den gemeinsam genutzten Speicherblock geschriebenen neuen Kommunikationscodes, und Schreiben des Anwendungscodes in den Anwendungs-Speicherblock, nachdem das Kopieren des neuen Kommunikationscodes in den gemeinsam genutzten Speicherblock abgeschlossen ist, wobei die Anwendung betrieben werden kann, nachdem der Anwendungscode vollständig in den Anwendungs-Speicherblock geschrieben wurde.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der neue Kommunikationscode überschrieben wird, wenn der Anwendungscode in den Anwendungs-Speicherblock geschrieben wird.
Verfahren nach Anspruch 1, weiterhin gekennzeichnet durch das Empfangen des in den Anwendungs-Speicherblock zu schreibenden neuen Kommunikationscodes durch Kommunikationen, die auf der Basis des derzeit in den ersten Speicher geschriebenen Kommunikationscodes ausgeführt werden.
Verfahren nach Anspruch 1, weiterhin gekennzeichnet durch das Validieren des in den Anwendungs-Speicherblock geschriebenen neuen Kommunikationscodes durch eine Prüfsummen-Operation vor dem Kopieren des neuen Kommunikationscodes in den gemeinsam genutzten Speicherblock.
Verfahren nach Anspruch 1, weiterhin gekennzeichnet durch das Prüfen, ob eine dem neuen Kommunikationscode zugewiesene Versionsnummer ein autorisiertes Update zu einer dem derzeit geschriebenen Kommunikationscode zugewiesenen Versionsnummer ist, bevor der neue Kommunikationscode in den gemeinsam genutzten Speicherblock geschrieben wird.
Verfahren nach Anspruch 1, weiterhin gekennzeichnet durch das periodische Ausgeben eines Befehls, der einen Wartestatus angibt, während der neue Kommunikationscode aus dem Anwendungs-Speicherblock zu dem gemeinsam genutzten Speicherblock kopiert wird.
Steuereinrichtung, die umfasst: eine CPU (34), die betrieben werden kann, um einen Code auszuführen und dadurch Operationen der Steuereinrichtung (16) in Übereinstimmung mit Befehlen zu ermöglichen, die gelesenen werden aus: (i) einem Starter-Speicherblock (28), in dem ein Code für die Ausführung eines Starters gespeichert ist, (ii) einem Anwendungs-Speicherblock (30), in dem ein Code für die Ausführung einer Anwendung gespeichert ist, (iii) einem gemeinsam genutzten Speicherblock (24), in dem ein gemeinsam durch den Starter und die Anwendung genutzter Kommunikationscode gespeichert ist.
Steuereinrichtung nach Anspruch 7, dadurch gekennzeichnet, dass der gemeinsam genutzte Speicherblock (24) den Code speichert, der durch den Starter und die Anwendung benötigt wird, um eine Kommunikation zu ermöglichen, in der Daten über ein Fahrzeug-Netzwerk (18) mit einer damit verbundenen Master- und/oder Fahrzeug-Steuereinrichtung (20) ausgetauscht werden.
Steuereinrichtung nach Anspruch 8, dadurch gekennzeichnet, dass der Starter betrieben werden kann, um einen Bootloader auszuführen, der eine Aktualisierung des gemeinsam genutzten Speicherblocks (24) ohne eine Unterbrechung der Kommunikation ermöglicht.
Steuereinrichtung nach Anspruch 9, dadurch gekennzeichnet, dass der Bootloader betrieben werden kann, um eine Aktualisierung eines in dem gemeinsam genutzten Teil gespeicherten ersten Codesatzes durch einen zweiten Codesatz zu bewerkstelligen und um den zweiten Codesatz zu einem temporären Teil des Anwendungs-Speicherblocks (30) zu schreiben, bevor er in den gemeinsam genutzten Speicherblock (24) kopiert wird.
Steuereinrichtung nach Anspruch 10, dadurch gekennzeichnet, dass der Bootloader weiterhin betrieben werden kann, um Kommunikationen in Übereinstimmung mit dem in dem Anwendungs-Speicherblock (30) gespeicherten zweiten Codesatz auszuführen, während der zweite Codesatz aus dem Anwendungs-Speicherblock (30) zu dem gemeinsam genutzten Teil des Starter-Speicherblocks (28) kopiert wird.
Steuereinrichtung nach Anspruch 11, dadurch gekennzeichnet, dass wenigstens ein Teil der Kommunikationen, die ausgeführt werden, während der zweite Codesatz in den gemeinsam genutzten Teil kopiert wird, das periodische Senden einer Meldung, die einen Wartestatus angibt, an einen Master umfasst.
Steuereinrichtung nach Anspruch 10, dadurch gekennzeichnet, dass die Anwendung nicht weiter betrieben werden kann, sobald mit dem Schreiben des zweiten Codesatzes in den Anwendungs-Speicherblock (30) begonnen wird.
Steuereinrichtung nach Anspruch 10, dadurch gekennzeichnet, dass der Bootloader weiterhin betrieben werden kann, um einen mit der Anwendung assoziierten Code über den in dem Anwendungs-Speicherblock (30) gespeicherten zweiten Codesatz zu schreiben, nachdem das Kopieren des zweiten Codesatzes zu dem gemeinsam genutzten Teil des Starter-Speicherblocks (28) abgeschlossen ist.
Steuereinrichtung nach Anspruch 10, dadurch gekennzeichnet, dass der Bootloader weiterhin betrieben werden kann, um ein Kopieren des zweiten Codesatzes in den gemeinsam genutzten Speicherblock (24) zu verhindern, wenn eine Prüfsumme des zweiten Codesatzes nicht mit einem Prüfsummenwert übereinstimmt.
Steuereinrichtung nach Anspruch 7, dadurch gekennzeichnet, dass der gemeinsam genutzte Speicherblock (24) an einer fixen Position in dem Starter-Speicherblock (28) gespeichert wird.
Verfahren zum Aktualisieren eines gemeinsam genutzten Speicherblocks, das verwendet wird, um einen gemeinsam genutzten Code an einer fixen Speicherposition zu speichern, um Kommunikationen eines ersten Programms und eines zweiten Programms zu unterstützen, wobei das Verfahren umfasst: Schreiben des gemeinsam genutzten Codes in einen temporären Speicherblock, der dem ersten oder dem zweiten Programm zugewiesen ist, wobei das erste oder das zweite Programm nicht betrieben werden kann, während der neue gemeinsam genutzte Code in dem temporären Speicherblock gespeichert wird, Kopieren des neuen gemeinsam genutzten Codes aus dem temporären Speicherblock in den gemeinsam genutzten Speicherblock, und Ausführen der gemeinsam genutzten Funktionen in Übereinstimmung mit dem in dem temporären Speicherblock gespeicherten neuen gemeinsam genutzten Code, während der neue gemeinsam genutzte Code zu dem gemeinsam genutzten Speicherblock kopiert wird.
Verfahren nach Anspruch 17, weiterhin gekennzeichnet durch das Ausführen wenigstens eines Teils der gemeinsam genutzten Funktionen, während der neue gemeinsam genutzte Code zu dem gemeinsam genutzten Speicherblock kopiert wird, einschließlich des periodischen Sendens einer Meldung, die einen Wartestatus angibt, zu einem Client.
Verfahren nach Anspruch 17, weiterhin gekennzeichnet durch das Verhindern des Kopierens des neuen gemeinsam genutzten Codes zu dem gemeinsam genutzten Speicherblock, wenn die Prüfsumme des in dem temporären Speicherblock gespeicherten gemeinsam genutzten Codes nicht einem Prüfsummenwert entspricht.
Verfahren nach Anspruch 17, weiterhin gekennzeichnet durch das Schreiben eines Codes, der mit einem der nicht betreibbar werdenden Programme assoziiert ist, über den in dem temporären Speicherblock geschriebenen neuen gemeinsam genutzten Code, nachdem das Kopieren des neuen gemeinsam genutzten Codes zu dem gemeinsam genutzten Speicherblock abgeschlossen ist, woraufhin das eine Programm wieder betrieben werden kann.