DE19721786A1 - Verfahren zum Betreiben eines Datenverarbeitungsgerätes, insbesondere Automatisierungsgerätes - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren zum Betreiben eines Datenverarbeitungsgerätes, insbesondere Automatisierungsgeräts, mit flüchtigen und nichtflüchtigen Speichern, wobei System- und/oder Anwendersoftware von einem nicht flüchtigen in einen flüchtigen Speicher kopiert wird.

Aus dem Stand der Technik ist bekannt, daß bei einem Datenverarbeitungsgerät sowohl die System- als auch die Anwendersoftware in einem nicht flüchtigen Speicher abgelegt ist. Die Systemsoftware kann einerseits direkt aus dem nicht flüchtigen Speicher ablaufen oder andererseits von dem nicht flüchtigen Speicher in den flüchtigen Speicher kopiert werden und aus diesem ablaufen. Der Start der Systemsoftware aus dem nicht flüchtigen Speicher weist den Nachteil auf, daß entweder ein schneller und dadurch teurer nicht flüchtiger Speicher verwendet werden muß, oder daß die Systemleistung durch Einfügen von Waitstates her­ abgesetzt wird. Beim Start der Systemsoftware aus dem flüchtigen Speicher muß ein nicht flüchtiger Speicher in voller Größe der Systemsoftware zur Verfügung stehen, der aber nach dem Umkopieren der Systemsoftware nicht mehr benötigt wird.

Ferner ist bekannt, daß Anwendersoftware in dem nicht flüchtigen Speicher ablaufen kann oder direkt von einer Programmiereinheit über eine von der Systemsoftware gesteuerte Programmierschnittstelle in den flüchtigen Speicher geladen werden kann. Beim Ablauf der Anwendersoftware aus dem nicht flüchtigen Speicher tritt oftmals das Problem auf, daß Online-Änderungen der Anwendersoftware kaum oder nur mit einer beträchtlichen Erhöhung der Zykluszeit zu erreichen sind. Bei einem Ablauf der Anwendersoftware aus dem flüchtigen Speicher ist weiterhin bekannt, daß eine Speicherverwaltung jederzeit die benötigten Resourcen für Online-Änderungen zur Verfügung stellen kann. Sollen die geänderten Daten beim Wiedereinschalten des Datenverarbeitungsgeräts in ihrer geänderten Form zur Ver­ fügung gestellt werden, muß sichergestellt sein, daß sie zuvor im nicht flüchtigen Speicher abgelegt wurden, damit die vorherigen Online-Änderungen gesichert sind. Dies würde jedoch einen unnötig großen nicht flüchtigen Speicher erfordern, der während der Laufzeit des Datenverarbeitungsgeräts nicht benutzt würde.

Der Erfindung liegt das Problem zu Grunde, ein Verfahren zum Betreiben eines Datenver­ arbeitungsgeräts derart weiterzubilden, daß bei zumindest gleichbleibender Leistungsfähigkeit nicht flüchtige Speicherelemente mit einer minimalen Speicherkapazität eingesetzt werden können.

Das Problem wird erfindungsgemäß dadurch gelöst, daß die Systemsoftware in komprimier­ ter Form in dem nicht flüchtigen Speicher abgelegt und nach Reset in Abhängigkeit eines Merkerelementes entweder dekomprimiert und in den flüchtigen Speicher abgelegt oder ohne Dekomprimierung in den flüchtigen Speicher kopiert und dort gestartet wird und/oder daß der Anwendersoftware zugeordnete, Änderungen der Anwendersoftware enthaltende Dateien bzw. durch Beauftragung vom Programmiergerät vor Spannungsausfall komprimiert und in den nicht flüchtigen Speicher abgelegt und bei Spannungswiederkehr zur Regeneration der Dateien im flüchtigen Speichern dekomprimiert werden. Durch diese Verfahrensweise wird der Vorteil erreicht, das nicht flüchtige Speicher von geringer Speicherkapazität eingesetzt werden können. Ebenso kann die Leistungsfähigkeit und Funktionalität eines existierenden Datenverarbeitungsgeräts ohne schaltungsmäßige Veränderungen erweitert werden. Da die System- und Anwendersoftware erfindungsgemäß nicht aus dem nicht flüchtigen Speicher abläuft, können auch langsamere und damit kostengünstigere nicht flüchtige Speicher eingesetzt werden.

Bei einer besonderen Verfahrensweise ist vorgesehen, daß vor Dekomprimierung der Systemsoftware mittels einer Längenangabe eine CRC-Prüfsumme ermittelt, mit einer gespei­ cherten Prüfsumme verglichen und bei Übereinstimmung der Prüfsummen die Dekom­ primierung durchgeführt wird. Dadurch wird sichergestellt, daß die Daten mit sehr hoher Wahrscheinlichkeit korrekt übertragen wurden.

Es ist vorgesehen, daß das Merkerelement, die Längenangabe und die CRC-Prüfsumme in einem Bereich am Anfang der Systemsoftware-Datei (Header) in unkomprimierter Form im nicht flüchtigen Speicher abgelegt sind. Eine Dekomprimierung des Headers muß daher nicht erfolgen.

Vorzugsweise ist in dem Header im nicht flüchtigen Speicher eine Zieladresse im flüchtigen Speicher abgelegt, wohin die Systemsoftware wie Betriebssystem kopiert oder dekomprimiert abgelegt wird.

Auch ist vorgesehen, daß nach der Dekomprimierung oder dem Kopieren der Systemsoftwa­ re eine CRC-Prüfsumme ermittelt, mit einer in einem zweiten Header im Bereich am Anfang der Systemsoftware-Datei im flüchtigen Speicher verglichen und bei Übereinstimmung eine Start-Routine gestartet wird. Dadurch wird geprüft, ob die Datenübertragung fehlerfrei erfolgte.

Die CRC-Prüfsumme, die Länge der Systemsoftware-Datei im flüchtigen Speicher sowie eine Adresse der Startroutine sind wiederum in einem Bereich am Anfang der Systemsoftware- Datei im flüchtigen Speicher gespeichert.

Als besonders bevorzugter Komprimier-Algorithmus wird der LZW-Algorithmus verwendet.

Weitere Vorteile, Merkmale und Einzelheiten der Erfindung ergeben sich nicht nur aus den Ansprüchen, den diesen zu entnehmenden Merkmalen - für sich und/oder in Kombination -, sondern auch aus der nachfolgenden Beschreibung eines den Zeichnungen zu entnehmenden bevorzugten Ausführungsbeispiels.

Es zeigen:

Fig. 1 prinzipieller Aufbau eines Automatisierungsgeräts,

Fig. 2 Speicherbelegung des nicht flüchtigen Speichers,

Fig. 3 Aufbau eines ersten Headers im nicht flüchtigen Speicher und

Fig. 4 einen Aufbau eines zweiten Headers im flüchtigen Speicher.

In Fig. 1 ist der prinzipielle Aufbau eines Automatisierungsgerätes dargestellt, mit einem Bus 12, an dem ein Mikroprozessor 14, nicht flüchtige und flüchtige Speicher 16, 18 sowie ein oder mehrere Peripheriegeräte 20 angeschlossen sind.

Als nicht flüchtiger Speicher 16 werden vorzugsweise Flash-Memory-Bausteine eingesetzt, die beschrieben und gelesen werden können und im Gegensatz zu dem flüchtigen Speicher 18 ihre Inhalte auch dann behalten, wenn sie nicht mit Betriebsspannung versorgt werden. Andere nicht flüchtige Speicher wie EPROM und EEPROM sind ebenfalls einsetzbar. Als flüchtiger Speicher werden vorzugsweise SRAM's und/oder DRAM's eingesetzt.

In Fig. 2 ist die Speicherbelegung des nicht flüchtigen Speichers 16 dargestellt. Erfindungs­ gemäß ist vorgesehen, daß die Systemsoftware, wie Betriebssystem in einem Anfangsbereich 22 abgelegt ist. Im Anschluß an das Betriebssystem folgt ein freier Speicherbereich 24, dem sich ein Speicherbereich 26 mit einer Reset-Initialisierung und einem Dekomprimier-Algorith­ mus als ablauffähigem Code anschließt.

Insbesondere bei speicherprogrammierbaren Steuerungen bzw. Automatisierungsgeräten kann auch Anwendungssoftware in dem nicht flüchtigen Speicher in komprimierter Form abgelegt sein.

Fig. 3 zeigt den Aufbau eines ersten Headers 28 in einem Bereich am Anfang der Betriebs­ systemdatei, in dem nicht die eigentlichen Daten, sondern wichtige Strukturinformationen zur Datei gespeichert sind. So wird in einem Speicherbereich 30 durch die ersten vier Byte des ersten Headers 28 die CRC-Prüfsumme (Cyclical Redundancy Check) gespeichert. In einem Speicherbereich 32 des Headers ist die Länge des Betriebssystems im nicht flüchtigen Speicher ohne den Header selbst abgelegt. In einem weiteren Speicherbereich 34 ist das Merkerelement abgelegt. Es hat die Wertigkeit "EINS", wenn das Betriebssystem in kom­ primierter Form gespeichert ist und die Wertigkeit "Null", wenn das Betriebssystem in trans­ parenter, d. h. unveränderter Form gespeichert ist. Durch einen weiteren Speicherbereich 36 wird die Zieladresse im flüchtigen Speicher angegeben, an die das Betriebssystem kopiert oder dekomprimiert abzulegen ist. Abschließend beginnt die Ablage des Betriebssystems in komprimierter oder transparenter Form.

In Fig. 4 ist der Aufbau eines zweiten Headers 40 des im flüchtigen Speicher abgespeicherten Betriebssystems dargestellt. In einem Anfangsbereich 42 ist durch eine vier Byte Information die CRC-Prüfsumme abgelegt. In einem folgenden Speicherbereich 44 ist ebenfalls mit einer vier Byte-Information die Länge des Betriebssystems im flüchtigen Speicher ohne CRC- Prüfsumme und Längenangabe abgelegt. In einem Speicherbereich 46 ist durch eine 4- oder 6 Byte-Information eine Startadresse des Betriebssystems im flüchtigen Speicher angegeben. Schließlich folgt in einem Speicherbereich 49 die Ablage des Betriebssystems in trans­ parenter, d. h. nicht komprimierter Form.

Um erfindungsgemäß den Einsatz von nicht flüchtigen Speichern einer minimalen Speicher­ größe zu garantieren ist vorgesehen, daß das in komprimierter Form in den nicht flüchtigen Speicher abgelegte Betriebssystem bei Initialisierung in den flüchtigen Speicher geladen wird. Dazu ist vorgesehen, daß das im nicht flüchtigen Speicher komprimiert abgelegte Betriebs­ system in Abhängigkeit des Merkerelements, d. h. wenn das Merkerelement die Wertigkeit "EINS" aufweist, durch eine im nicht flüchtigen Speicher abgelegte nicht komprimierte Routine dekomprimiert und in den flüchtigen Speicher abgelegt wird. Vor der Dekomprimie­ rung des Betriebssystems wird mittels einer im Speicherbereich 32 des ersten Headers 28 abgelegten Längenangabe eine CRC-Prüfsumme ermittelt und mit der ebenfalls in dem Header 28 in dem Speicherbereich 30 abgelegten Prüfsumme verglichen. Stimmt die er­ mittelte Prüfsumme mit der abgelegten Prüfsumme überein, so wird mit der Dekomprimie­ rung fortgefahren. Dabei wird das Betriebssystem ohne den Header 28 dekomprimiert und an die in dem Speicherbereich 36 des Headers 28 abgelegte Zieladresse im flüchtigen Speicher dekomprimiert abgelegt.

Weist das Merkerelement die Wertigkeit "Null" auf, wird das Betriebssystem direkt, d. h. ohne Dekomprimierung und ohne Header in den flüchtigen Speicher kopiert.

Nach dem Dekomprimieren bzw. Kopieren des Betriebssystems wird wie zuvor beschrieben eine CRC-Prüfsumme ermittelt und mit einer in einem zweiten Header 40 im flüchtigen Speicher, der in dekomprimierter Form vorliegt, verglichen. Wenn die beiden Prüfsummen übereinstimmen, wird eine Start-Routine des Betriebssystems angesprungen, deren Adresse ebenfalls im Header 40 im Speicherbereich 46 abgelegt ist.

Wie schon zuvor erwähnt, kann die Anwendersoftware sowohl aus dem nicht flüchtigen Speicher 16 ablaufen oder direkt über die Peripherie-Einheit 20 mittels des Betriebssystems in den flüchtigen Speicher 18 geladen werden. Um eine komfortable Online-Änderung des Anwendungsprogramms zu ermöglichen, muß diese vorwiegend im flüchtigen Speicher 18 abgelegt sein.

Wird eine Anwendersoftware aus dem flüchtigen Speicher 18 betrieben, kann eine Spei­ cherverwaltung jederzeit die benötigten Speicherplätze zur Ablage von Online-Änderungen zur Verfügung stellen. Damit ein Online geändertes Anwenderprogramm auch bei Wiederein­ schaltung des Automatisierungsgeräts in der zuvor geänderten Version wieder zur Verfügung steht, muß dieses vor Ausschalten des Automatisierungsgeräts in den nicht flüchtigen Speicher abgelegt werden, damit alle vorherigen Änderungen und Variablen- Initialisierungen gespeichert werden. Insbesondere muß der gesamte Signalspeicher sowie der gesamte HEAP der Speicherverwaltung im nicht flüchtigen Speicher abgelegt werden.

Um möglichst nicht flüchtige Speicher mit einer geringen Speicherkapazität verwenden zu können, wird erfindungsgemäß vorgeschlagen, daß eine Komprimier-Routine bei Beauf­ tragung von einem Programmiergerät den Signalspeicher sowie den HEAP einer Speicher­ verwaltung komprimiert und in den nicht flüchtigen Speicher 16 abgelegt und sobald das Automatisierungsgerät wieder eingeschaltet wird, eine Dekomprimierroutine aktiviert wird, die den Signalspeicher und den gesamten HEAP der Speicherverwaltung aus dem nicht flüchtigen Speicher in den flüchtigen Speicher regeneriert. Sämtliche Online-Änderungen bleiben erhalten, so daß eine erneute Änderung des Anwenderprogramms bei Spannungsaus­ fall vermieden werden kann. Zusätzlich wird bei gleichzeitiger Minimierung des Hardware­ aufwands die Funktionalität des Automatisierungsgeräts erweitert.

Claims (7)

1. Verfahren zum Betreiben eines Datenverarbeitungsgeräts, insbesondere Automatisie­ rungsgeräts, mit flüchtigen und nichtflüchtigen Speichern, wobei System- und/oder Anwendersoftware von einem nicht flüchtigen in einen flüchtigen Speicher kopiert wird, dadurch gekennzeichnet, daß die Systemsoftware in komprimierter Form in dem nicht flüchtigen Speicher abgelegt und nach Reset in Abhängigkeit eines Merkerelements entweder dekom­ primiert und in den flüchtigen Speicher abgelegt oder ohne Dekomprimierung in den flüchtigen Speicher kopiert und dort gestartet wird und/oder daß der Anwender­ software zugeordnete, Änderungen der Anwendersoftware enthaltende Dateien vor Spannungsausfall komprimiert und in den nicht flüchtigen Speicher abgelegt und bei Spannungswiederkehr zur Regeneration der Dateien im flüchtigen Speicher dekom­ primiert werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß vor Dekomprimierung der System-Software mittels einer Längenangabe eine CRC-Prüfsumme ermittelt, mit einer gespeicherten Prüfsumme verglichen und bei Übereinstimmung der Prüfsummen die Dekomprimierung durchgeführt wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß das Merkerelement, die Längenangabe und die CRC-Prüfsumme in einem ersten Header in einem Bereich am Anfang der System-Software-Datei in unkomprimierter Form im nicht flüchtigen Speicher abgelegt sind.

4. Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß in dem ersten Header eine Zieladresse im flüchtigen Speicher abgelegt ist, an die die Systemsoftware kopiert oder dekomprimiert abgelegt wird.

5. Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß nach der Dekomprimierung oder dem Kopieren der Systemsoftware eine CRC- Prüfsumme ermittelt, mit einer in einem zweiten Header in einem Bereich am Anfang der Systemsoftware-Datei im flüchtigen Speicher verglichen und bei Übereinstimmung eine Start-Routine gestartet wird.

6. Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die CRC-Prüfsumme, die Länge der Systemsoftware-Datei im flüchtigen Spei­ cher sowie eine Adresse der Start-Routine in dem zweiten Header im flüchtigen Speicher gespeichert sind.

7. Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein Komprimier-Algorithmus wie LZW-Algorithmus verwendet wird.