DE19833963A1

DE19833963A1 - Verfahren zum Austauschen einer Ladedatei in einem Programmspeicher

Info

Publication number: DE19833963A1
Application number: DE19833963A
Authority: DE
Inventors: Andreas Lindenthal
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 1998-07-28
Filing date: 1998-07-28
Publication date: 1999-12-02

Abstract

Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Austauschen einer Ladedatei in einem Programmspeicher, der einen Arbeitsbereich und einen Rückfallbereich aufweist. Im Arbeitsbereich ist ein anwendungsspezifischer Programm-Code und im Rückfallbereich eine Ladedatei zum Laden einer neuen Version des Programm-Codes in den Arbeitsbereich oder zum Laden einer neuen Version der Ladedatei in den Rückfallbereich gespeichert. Die Erfindung gewährleistet die Funktionsfähigkeit der Ladedatei im Programmspeicher auch dann noch, wenn zuvor ein Versuch, die aktuelle Version der Ladedatei gegen eine neue Version auszutauschen, aufgrund einer Störung vorzeitig abgebrochen werden mußte. Die jederzeitige Funktionsfähigkeit der Ladedatei wird erfindungsgemäß dadurch sichergestellt, daß eine neue Version der Ladedatei zunächst zusätzlich neben die zu ersetzende Ladedatei in dem Programmspeicher gespeichert wird. Erst nachdem der Speichervorgang für die neue Version der Ladedatei erfolgreich abgeschlossen ist, wird die neue Version im Programmspeicher als gültig erklärt.

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Austauschen einer Ladedatei in einem Programmspeicher, der einen Arbeitsbereich und einen Rückfallbereich aufweist, wobei im Arbeitsbereich ein anwendungsspezifischer Programmcode und im Rückfallbereich die Ladedatei zum Laden einer neuen Version des Programmcodes in den Arbeitsbereich oder zum Laden einer neuen Version der Ladedatei in den Rückfallbereich gespeichert ist.

Eine bekannte Möglichkeit zum Austauschen eines Programm- Codes, der in einem PROM (programmable read only memory) gespeichert ist, besteht darin, das bisherige PROM manuell durch ein neues PROM auszutauschen, wobei in dem neuen PROM eine neue Version des Programm-Codes gespeichert ist.

Ein derartiger manueller PROM-Tausch erfordert zunächst die Außerbetriebnahme einer Baugruppe in einem System, auf der das auszutauschende PROM angeordnet ist, das Abschalten der Spannungsversorgung der Baugruppe und das Ziehen der Baugruppe aus einem Schaltschrank, um nach folgend das PROM mit der alten Programmversion aus seinem Sockel zu hebeln und das PROM mit der neuen Programmversion in den Sockel einzustecken. Abschließend wird die Baugruppe wieder in den Schaltschrank gesteckt, die Spannungsversorgung der Baugruppe eingeschaltet und die Baugruppe im System durch eine Neukonfiguration wieder in Betrieb genommen.

Diese manuellen Eingriffe sind nur von entsprechend geschultem Personal durchzuführen, weshalb der manuelle PROM- Tausch insbesondere bei häufigen Wechseln des Programm-Codes sehr zeitaufwendig und teuer ist.

Eine weitere Möglichkeit zum Austauschen von Programm-Codes in PROMs bietet das Laden einer neuen Version des Programm- Codes aus einer externen Datei in das PROM (Download), wobei der aktuell in dem PROM befindliche Programm-Code überschrieben wird. Die Software zum Durchführen dieses Downloads (Ladedatei) kann neben dem anwendungsspezifischen Programm-Code ebenfalls in dem PROM abgespeichert sein. Ein solcher Download-Vorgang erfolgt solange problemlos, wie die Ladedatei intakt ist und der Download-Vorgang nicht aufgrund von Störungen, wie z. B. einem Spannungsausfall oder einem Reset auf der Baugruppe auf der das PROM steckt, abgebrochen werden muß, bevor er ordnungsgemäß beendet werden konnte.

Solange die Ladedatei funktionsfähig ist, kann ein abgebrochener Download-Vorgang für einen anwendungsspezifischen Programm-Code jederzeit beliebig oft wiederholt werden, bis er erfolgreich beendet werden kann, so daß schließlich eine funktionsfähige neue Version des Programm-Codes im PROM abgespeichert ist.

Die Ladedatei ist üblicherweise nicht nur in der Lage, eine neue Version des anwendungsspezifischen Programm-Codes in den PROM zu laden, sondern sie ist ggf. auch in der Lage, eine neue Version von sich selbst in den PROM zu laden. Wenn jedoch ein Versuch der Ladedatei, sich selbst durch eine neue Version zu ersetzen, z. B. aufgrund einer der oben genannten Störungen abgebrochen werden muß, so hat dies zur Folge, daß anschließend weder die alte, zu ersetzende, noch die neue Version der Ladedatei mehr funktionsfähig sind.

Dies ist damit zu begründen, daß während des Download- Vorganges für die neue Version der Ladedatei die alte Version der Ladedatei im PROM zumindest teilweise überschrieben und damit zerstört wurde. Zudem ist, wenn der Download-Vorgang für die neue Version der Ladedatei aufgrund einer Störung vorzeitig abgebrochen worden ist, die neue Version nicht vollständig in den PROM übertragen worden und damit auch nicht funktionsfähig.

Insgesamt läßt sich somit festhalten, daß nach einem vorzeitigen Abbruch eines Download-Vorganges für eine Ladedatei keine einzige gültige Version einer Ladedatei mehr im PROM zur Verfügung steht. Es kann dann weder ein anwendungsspezifischer Programm-Code noch eine neue Version einer Ladedatei per Download in den PROM übertragen werden. Eine Neuinstallation der Ladedatei bzw. des anwendungsspezifischen Programm-Codes ist dann nur noch durch den eingangs beschriebenen zeitaufwendigen und teuren manuellen PROM-Tausch möglich.

Es ist daher die Aufgabe der Erfindung, ein Verfahren bereitzustellen, welches die Funktionsfähigkeit einer Ladedatei in einem Programmspeicher auch dann noch gewährleistet, nachdem ein Versuch, die aktuelle Version einer Ladedatei gegen eine neue Version auszutauschen, vor seiner Vollendung aufgrund einer Störung abgebrochen werden mußte.

Diese Aufgabe wird durch die in dem Patentanspruch 1 angegebenen Verfahrensschritte gelöst.

Gemäß der vorliegenden Erfindung wird die Aufgabe insbesondere dadurch gelöst, daß eine alte, zu ersetzende Ladedatei nicht sofort durch eine neue Version überschrieben wird, sondern daß die neue Version der Ladedatei zusätzlich neben der zu ersetzenden Ladedatei in dem Programmspeicher gespeichert wird. Erst nachdem dieser Speichervorgang erfolgreich abgeschlossen ist, wird die alte Ladedatei für ungültig und die neue Version der Ladedatei für gültig erklärt.

Mit diesem Austauschverfahren wird bei intakter Baugruppenhardware sichergestellt, daß im PROM jederzeit eine funktionsfähige und gültige ("alte" oder "neue") Version der Ladedatei zur Verfügung steht. Dies gilt insbesondere auch dann, wenn der Speichervorgang der neuen Version der Ladedatei neben die alte Version der Ladedatei in den PROM aufgrund einer Störung, wie z. B. einem Spannungsausfall oder einem Reset auf der Baugruppe, abgebrochen werden mußte. Bei dem erfindungsgemäßen Austauschverfahren bleibt die alte Version der Ladedatei von dem Auftreten einer solchen Störung unberührt und damit funktionstüchtig. Mit der nach wie vor funktionsfähigen alten Version der Ladedatei können deshalb auch nach dem Auftreten einer Störung entweder eine neue Version des anwendungsspezifischen Programm-Codes oder eine neue Version der Ladedatei in den Programmspeicher geladen werden.

Aufgrund des erfindungsgemäßen Verfahrens ist auch nach dem Auftreten einer der genannten Störungen während eines Download-Vorganges für die Ladedatei ein zeitaufwendiger und teurer manueller Austausch des PROMs nicht erforderlich. Die schnelle, bequeme und kostengünstige Möglichkeit zum Austausch von sowohl anwendungsspezifischem Programm-Code wie auch von Ladedateien bleibt somit erhalten.

Gemäß einer vorteilhaften Weiterbildung des Verfahrens, werden neue Versionen des Programm-Codes oder der Ladedatei zunächst in eine externe Datei geschrieben und nachfolgend aus dieser in den Programmspeicher geladen. Auf diese Weise wird eine klare physikalische Trennung zwischen der aktuellen Version der Software im Programmspeicher und der neuen Version gewährleistet. Die Zwischenspeicherung der neuen Versionen in der externen Datei ermöglicht deren Übertragung in den Programmspeicher zu einem beliebig definierbaren am besten geeigneten Zeitpunkt. Zudem können in der externen Datei noch kleine Änderungen der Version vorgenommen werden, bevor sie in den Programmspeicher geladen werden.

Die Zwischenspeicherung der neuen Versionen des Programm- Codes oder der Ladedatei in der externen Datei bietet darüber hinaus den Vorteil, daß die Austauschvorgänge von alten Versionen durch neue Versionen automatisiert werden können.

Gemäß einer weiteren vorteilhaften Ausgestaltung sieht das erfindungsgemäße Verfahren vor, die jeweiligen Versionen in der externen Datei und im Programmspeicher regelmäßig miteinander mit Hilfe einer externen Überwachungssoftware zu vergleichen. Ergibt dieser Vergleich, daß in der externen Datei eine neue Version des Programm-Codes oder der Ladedatei vorhanden ist, so kann daraufhin der erfindungsgemäße Austauschvorgang automatisch eingeleitet werden.

Es ist weiterhin von Vorteil, wenn das Verfahren in einem Flash-EPROM (FEPROM) als Programmspeicher ausgeführt wird. FEPROMs bieten im Unterschied zu normalen EEPROMs den Vorteil, daß ihr Speicherinhalt nicht nur als Ganzes, sondern auch partiell gelöscht werden kann. Bei dem erfindungsgemäßen Verfahren ist dies insbesondere von Vorteil, da der anwendungsspezifische Programm-Code in einem separaten Arbeitsbereich und die Ladedatei in einem separaten Rückfallbereich des Programmspeichers abgespeichert ist. Diese Speicherbereiche können dann, wenn der Programmspeicher als FEPROM ausgebildet ist, einzeln gelöscht werden.

Vorzugsweise ist der Speicherbereich, in dem der anwendungsspezifische Programm-Code gespeichert ist, patchbar, so daß auf diese Weise Fehler im dort gespeicherten Programm-Code korrigierbar sind.

Schließlich ist es von Vorteil, in dem Programmspeicher neben dem Arbeits- und Rückfallbereich noch einen Basisbereich vorzusehen, in dem eine Logikdatei gespeichert ist, welche entscheidet, ob auf den Programm-Code oder die Ladedatei zugegriffen wird. Diese Entscheidungen sind insbesondere während der Inbetriebnahme der Baugruppe, auf der der Programmspeicher angeordnet ist, von Bedeutung.

Unter Bezugnahme auf die beigefügten Zeichnungen erfolgt nachfolgend eine detaillierte Beschreibung eines Ausführungsbeispiels der Erfindung. Dabei zeigen:

Fig. 1 die Strukturierung eines Programmspeichers mit dem das erfindungsgemäße Verfahren ausführbar ist; und

Fig. 2 ein Flußdiagramm, das den Ablauf des erfindungsgemäßen Verfahrens darstellt.

Bei dem bevorzugten Ausführungsbeispiel der Erfindung ist der Programmspeicher auf einer Baugruppe als FEPROM ausgebildet und wie in Fig. 1 dargestellt strukturiert. Demnach ist der Speicherbereich des FEPROMs in drei Teilbereiche unterteilt, die als Basisbereich, Rückfallbereich und als Arbeitsbereich bezeichnet werden. Der Basisbereich dient zur Speicherung einer Logikdatei, der Rückfallbereich zur Speicherung einer Ladedatei sowie einer neuen Version der Ladedatei, und der Arbeitsbereich dient zur Speicherung eines anwendungsspezifischen Programm-Codes.

Auf die Logikdatei im Basisbereich wird insbesondere während der Inbetriebnahme der Baugruppe zugegriffen. Sie entscheidet dann, ob nachfolgend entweder das Programm im Rückfallbereich oder im Arbeitsbereich ausgeführt werden soll. Ist im Arbeitsbereich zunächst kein Programm-Code vorhanden, so verweist die Logikdatei auf den Rückfallbereich, um mit Hilfe der dort gespeicherten gültigen Ladedatei einen anwendungsspezifischen Programm-Code in den Arbeitsbereich zu laden. Ist andererseits bereits ein gültiger anwendungsspezifischer Programm-Code im Arbeitsbereich vorhanden, so wird dieser immer bevorzugt gegenüber der Ladedatei im Rückfallbereich ausgeführt.

Die Ladedatei im Rückfallbereich dient sowohl zum Laden einer neuen Version des anwendungsspezifischen Programm-Codes in den Arbeitsbereich wie auch zum Laden einer neuen Version der Ladedatei (von sich selbst) in den Rückfallbereich. Weil die neue Version der Ladedatei zusätzlich neben der zu ersetzenden Ladedatei in dem Rückfallbereich des FEPROMs gespeichert wird, empfiehlt es sich, diesen gemäß Fig. 1 in zwei Teilbereiche zu unterteilen.

Fig. 2 zeigt das erfindungsgemäße Verfahren zum Austauschen einer Ladedatei in einem Programmspeicher. Hierbei überprüft eine externe Überwachungssoftware gemäß Schritt 110 zunächst, ob eine Version der Ladedatei in einer externen Datei verschieden ist zu der Version der Ladedatei in dem FEPROM. Wird in Schritt 110 keine Abweichung der beiden Versionen der Ladedatei festgestellt, so geht das Verfahren zu Schritt 150 über und überprüft die Versionen des anwendungsspezifischen Programm-Codes in der externen Datei und in dem FEPROM hinsichtlich ihrer Identität.

Wird auch bei dem anwendungsspezifischen Programm-Code keine Abweichung seiner Versionen festgestellt, so springt die Überwachungssoftware wieder zu Schritt 110 zurück. Sowohl die Versionen der Ladedatei wie auch die Versionen des anwendungsspezifischen Programm-Codes werden also permanent auf Veränderungen hin überwacht.

Wird jedoch in Schritt 110 eine Abweichung der Version der Ladedatei in der externen Datei von ihrer Version im FEPROM festgestellt, so wird gemäß Schritt 120 die neue Version der Ladedatei aus der externen Datei zusätzlich neben der zu ersetzenden Ladedatei in dem Rückfallbereich des FEPROMs gespeichert. Dann erfolgt eine Überprüfung, ob der Speichervorgang erfolgreich war (Schritt 130). Erst nachdem festgestellt worden ist, daß dieser Speichervorgang erfolgreich abgeschlossen wurde, wird die neue Version der Ladedatei im Rückfallbereich gemäß Schritt 140 als gültig erklärt.

Wenn andererseits, z. B. aufgrund eines Spannungsausfalls oder eines Resets auf der Baugruppe, der Speichervorgang der neuen Ladedatei in den FEPROM abgebrochen werden mußte, bevor er vollständig abgeschlossen werden konnte, so wird dies in Schritt 130 festgestellt und der Schritt 120 zur Speicherung der neuen Version der Ladedatei in den Rückfallbereich des FEPROMs wiederholt, nachdem die Störung beseitigt wurde.

Nach erfolgreichem Abschluß des Schrittes 140 wird von der externen Überwachungssoftware gemäß Schritt 150 erneut überprüft, ob die Versionen des anwendungsspezifischen Programm-Codes in der externen Ladedatei und im Arbeitsbereich des FEPROMs identisch sind. Wird nun eine Abweichung festgestellt, so wird gemäß Schritt 160 der Programm-Code im Arbeitsbereich des FEPROMs mit einer neuen Version aus der externen Datei überschrieben. Wird das Überschreiben gemäß Schritt 160 erfolgreich abgeschlossen, so daß die neue Version des Programm-Codes funktionsfähig im FEPROM abgespeichert ist, so fährt die Überwachungssoftware mit Schritt 110 fort.

Muß andererseits Schritt 160 aufgrund einer aufgetretenen Störung, wie z. B. eines Spannungsausfalls oder eines Resets auf der Baugruppe, abgebrochen werden, bevor die neuen Version des anwendungsspezifischen Programm-Codes vollständig im Arbeitsbereich des FEPROMs abgespeichert ist, so wird dies in Schritt 170 erkannt. Schritt 160 wird daraufhin solange wiederholt, bis schließlich eine funktionsfähige neue Version des anwendungsspezifischen Programm-Codes im Arbeitsbereich des FEPROMs gespeichert ist.

Abschließend sei nochmals darauf hingewiesen, daß bei dem erfindungsgemäßen Verfahren sichergestellt ist, daß zu jeder Zeit eine gültige Version der Ladedatei im Rückfallbereich des FEPROMs vorhanden ist. Erst durch die Existenz dieser Ladedatei wird eine Wiederholung der Schritte 120 und 160 nach vorhergehendem störungsbedingtem Abbruch ermöglicht.

Claims

1. Verfahren zum Austauschen einer Ladedatei in einem Programmspeicher, der einen Arbeitsbereich und einen Rückfallbereich aufweist, wobei im Arbeitsbereich ein anwendungsspezifischer Programmcode und im Rückfallbereich die Ladedatei zum Laden einer neuen Version des Programmcodes in den Arbeitsbereich oder zum Laden einer neuen Version der Ladedatei in den Rückfallbereich gespeichert ist, mit folgenden Schritten:

a) Überprüfen, ob die Ladedatei im Rückfallbereich durch eine neue Version ersetzt werden soll (Schritt 110); und wenn die Ladedatei ersetzt werden soll:
- - Speichern der neuen Version der Ladedatei zusätzlich zu der zu ersetzenden Ladedatei in den Rückfallbereich (Schritt 120);
- - Erklären der neuen Version der Ladedatei im Rückfallbereich als gültig, nachdem der Speichervorgang der neuen Version der Ladedatei abgeschlossen ist (Schritte 130, 140);
b) Überprüfen, ob der Programmcode im Arbeitsbereich durch eine neue Version ersetzt werden soll (Schritt 150), und wenn der Programmcode ersetzt werden soll:
- - Überschreiben des zu ersetzenden Programmcodes mit der neuen Version (Schritt 160).

2. Verfahren nach Anspruch 1, dadurch gekenn zeichnet, daß die neuen Versionen des Programmcodes oder der Ladedatei aus einer externen Datei in den Programmspeicher geladen werden.

3. Verfahren nach Anspruch 2, dadurch gekenn zeichnet, daß der Schritt (110) des Überprüfens, ob die Ladedatei ersetzt werden soll, folgenden Schritt umfaßt:
Feststellen des Vorhandenseins einer neuen Version der Ladedatei in der externen Datei und Vergleichen der neuen Version mit der im Programmspeicher zu ersetzenden Version durch eine externe Überwachungssoftware.

4. Verfahren nach Anspruch 2 oder 3, dadurch ge kennzeichnet, daß der Schritt (150) des Überprüfens, ob der Programmcode ersetzt werden soll, folgenden Schritt umfaßt:
Feststellen des Vorhandenseins einer neuen Version des Programmcodes in der externen Datei und Vergleichen der neuen Version mit der im Programmspeicher zu ersetzenden Version durch die externe Überwachungssoftware.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß das Verfahren in einem Flash-EPROM (FEPROM) als Programmspeicher ausgeführt wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß es weiterhin folgenden Schritt aufweist:
Patchen des Arbeitsbereiches, um Fehler im dort gespeicherten Programmcode zu korrigieren.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß der Programmspeicher einen Basisbereich aufweist, in dem eine Logikdatei gespeichert ist, welche entscheidet, ob auf den Programmcode oder die Ladedatei zugegriffen wird.