DE19803697C2 - Verfahren zum Aufrüsten eines Softwaresystems und Vorrichtung zur Durchführung des Verfahrens - Google Patents

Description

Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung das Aufrüsten eines auf einer Datenverarbeitungsvorrichtung betriebenen Softwaresystems und insbesondere betrifft die vorliegende Erfindung das Aufrüsten eines Softwaresystems um eine Vielzahl von Softwaresystemversionen.

Software- und computergesteuerte Anwendungen haben oft ein hohes Komplexitätsniveau. Trotzdem verlangt die Entwicklung von neuen Systemen und Softwareversionen oder Freigaben (Release) eine ständige Anpassung eines softwaregesteuerten Systems an diese neuesten Standards. Die Anpassung eines Systems an einen neuen Softwarestandard wird in einem sogenannten Upgrade (Aufrüsten) ausgeführt, was in einem komplexen System einen beträchtlichen Zeitaufwand erfordern kann. Allgemein besteht ein Upgrade aus dem Ändern oder Aktualisieren von Teilen des Softwaresystems, indem beispielsweise Programmdateien oder Konfigurationsdateien durch neuere ersetzt werden und/oder das Ausführen von Aktualisierungsprogrammen, um die Implementierung von Änderungen zu vervollständigen. Insbesondere wenn ein Software- oder Betriebssystem von einer älteren Version zu einer neueren oder kürzlich freigegebenen Version aufgerüstet wird, wird allgemein eine kurze Stillstandszeit von Teilen der Datenverarbeitungsvorrichtung oder des gesamten Systems bewirkt. Während einer solchen Stillstandszeit wird eine Verarbeitung oder ein Dateizugriff unterbrochen.

Ein Bediener eines softwaregesteuerten Computersystems kann auswählen, ob das System jedes Mal aufgerüstet werden soll, wenn eine neue Softwareversion erhältlich wird, oder er kann auswählen, insbesondere in solchen Fällen, wo ein Upgrade (Aufrüsten) teuer oder zeitaufwendig ist, das System weniger oft aufzurüsten, als neue Freigaben bzw. Upgrades des Softwaresystems entwickelt werden.

Im letzteren Fall kann ein Upgrade des Softwaresystems auf eine erwünschte Version aus einer Vielzahl von einzelnen Upgrade-Betriebsvorgängen bestehen, die in einer Sequenz ausgeführt werden. Da jedes Upgrade eine kurze Stillstandszeit bewirkt, kann, falls eine Vielzahl von einzelnen Upgrades in einer Abfolge ausgeführt wird, die Gesamt-Auszeit des Upgrade-Betriebsvorgangs auf die gewünschte Softwaresystemversion lang werden, da die Stillstandszeiten für jeden Aufrüstschritt addiert werden. Da während der Stillstandszeiten der Betrieb des Systems für die entsprechende Zeitperiode angehalten wird, sind sie unerwünscht, auch wenn sie kurz sind. Beispielsweise können bei Echtzeitanwendungen, wie in einem Telekommunikationsnetzwerk, während einer Stillstandszeit Teilnehmer nicht bedient werden, und es ist offensichtlich, daß die Anzahl oder Dauer von Stillstandszeiten minimal gehalten werden sollte.

Weiter beinhaltet das Aufrüsten eines Systems über eine Vielzahl von aufeinander folgend freigegebenen Softwaresystemversionen auch ein Wiederholen von ähnlichen oder identischen Aktivitäten bei jeden Aktualisierungsschritt, was die von einem Bediener benötigte Zeit und damit die Kosten erhöht.

Ein allgemein bekanntes Verfahren, die Gesamtstillstandszeit während eines Upgrade-Prozesses zu vermindern, ist es, einen speziell zugeschnittenes Upgrade für ein Aufrüsten des Softwaresystems von einer gegenwärtigen Softwareversion auf eine erwünschte Softwareversion zu entwickeln, anstelle eines sequentiellen Aufrüstens des Systems mit einzelnen Upgrades. Solche direkten Upgrades erlauben es, daß System direkt in einem einzigen Schritt aufzurüsten, anstatt in einer Serie von Schritten und erlauben, die Anzahl von Stillstandszeiten zu einer einzigen Stillstandszeit zu reduzieren. Direkte Upgrades müssen jedoch zusätzlich zu regulären Upgrades entwickelt werden und das Entwickeln von direkten Upgrades schließt ein Redesign von bereits existierenden Upgrades sowie ein Verschmelzen dieser Upgrades ein, um einen zugeschnittenen Einschritt-Upgrade zu entwickeln, was ineffizient ist. Darüber hinaus muß eine Vielzahl von direkten Upgrades entwickelt werden, einer für jeden möglichen Upgrade-Pfad, d. h. von einer beliebigen Softwaresystemversion zu einer beliebigen anderen Softwaresystemversion. Aus diesen Gründen sind Schritt für Schritt Upgrades und direkte Upgrades unpraktisch und teuer, und alternative Verfahren sind erforderlich.

Die EP 0 848 341 A2 beschreibt ein Fern-Upgraden von Software über ein Netzwerk. Die Software eines World Wide Web Browsers kann aktualisiert oder rekonfiguriert werden, indem eine alte Software ersetzende neue Software von einem Server über das Netzwerk heruntergeladen wird, und über die in einem Flash- Speicher gespeicherte alte Software geschrieben wird. Währenddessen werden Daten der Umgebung der zur aktualisierenden Software in einem ROM gespeichert.

Es ist Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung zum flexiblen Aufrüsten eines Softwaresystems bei reduzierten Kosten bereitzustellen.

Diese Aufgabe der Erfindung wird verfahrensmäßig und vorrichtungsmäßig durch die Merkmale der Ansprüche 1 bzw. 11 gelöst.

Das erfindungsgemäße Verfahren erlaubt es, für einzelne Upgrades identische Upgrade-Tasks (Aufrüst-Aufgabe) zu einem Upgrade-Rahmen zusammenzufassen, und erlaubt es dann, eine Vielzahl von Upgrade-Inhalten in einer Abfolge auszuführen, wobei jeder der Upgrade-Inhalte einem einzelnen Upgrade von einer bestimmten Softwareversion zu einer anderen entspricht, wodurch es möglich ist, das System von einer beliebigen gegenwärtigen Version zu einer beliebigen erwünschten neueren Softwareversion in einem einzigen Upgrade-Betriebsvorgang aufzurüsten. Das erfindungsgemäße Verfahren erlaubt es somit, gewöhnliche Upgrades für ein Softwaresystem zu einem Ein- Schritt Upgrade-Betriebsvorgang zu kombinieren, ohne das Erfordernis einer Doppelentwicklung.

Die erfindungsgemäße Vorrichtung erlaubt es, ein Softwaresystem mit einer Vielzahl von Upgrade-Inhalten aufzurüsten, wobei mit jedem der Upgrade-Inhalte das Softwaresystem von einer Softwaresystemversion zu einer nachfolgend freigegebenen Softwaresystemversion zu aktualisieren.

Dabei kann das System in einer Echtzeitumgebung arbeiten.

Vorteilhafterweise kann die Aktualisierung mit einer einzigen Stillstandszeit ausgeführt werden, indem ein Quellsystem, ein Zielsystem verwendet werden, und eine Schaltvorrichtung, um Kommunikationsverbindungen zwischen dem Quellsystem und dem Zielsystem umzuschalten.

Das erfindungsgemäße Verfahren erlaubt es vorteilhaft, ein Softwaresystem auf einer in einer Echtzeitumgebung arbeitenden Datenverarbeitungsvorrichtung aufzurüsten. Das Quellsystem arbeitet dabei basierend auf einer Softwaresystemversion vor dem Aktualisierungsprozeß und das Zielsystem ist dazu vorgesehen, mit dem aufgerüsteten Softwaresystem zu arbeiten, was es erlaubt, daß das Softwaresystem auf dem Zielsystem auf die erwünschte Softwaresystemversion aufgerüstet wird, während das Quellsystem immer noch mit der Softwaresystemversion vor dem Upgrade-Betriebsvorgang arbeitet. Auf vorteilhaft Weise können so Kommunikationsverbindungen von dem Quellsystem zu dem Zielsystem in einem Schritt umgeschaltet werden, nachdem die Upgrade-Inhalte ausgeführt wurden. Somit kann ein Softwaresystem mit einer einzigen Stillstandszeit aktualisiert werden.

Das erfindungsgemäße Verfahren erlaubt es weiter vorteilhaft, statische Daten zu aktualisieren, wobei statische Daten Datenbankinhalte oder beliebige andere Daten vor dem Aufrüstprozeß sind, und/oder ein aufrüsten von dynamischen Daten, die Ereignissen entsprechen, die auftreten, während der Upgrade-Vorgang ausgeführt wird. Dies bringt insbesondere in einer Echtzeitumgebung Vorteile.

Jeder Upgrade-Inhalt kann zumindest statische Tasks enthalten, um statische Daten zu aktualisieren. Ein Upgrade- Inhalt kann auch dynamische Tasks beinhalten, um dynamische Daten zu aktualisieren. Die statischen Tasks jedes Upgrade- Inhalts werden aufeinanderfolgend auf die statischen Daten angewendet, und die dynamischen Daten werden aufeinanderfolgend durch dynamische Tasks jedes Upgrade- Inhalts verarbeitet, und die aktualisierten dynamischen Daten werden in die statischen Daten eingeführt, nachdem der Upgrade der statischen Daten vervollständigt worden ist. Dies stellt sicher, daß Ereignisse, die während des Aufrüstens auftreten, auf geeignete Weise an die neue Softwaresystemversion angepaßt werden und auf die statischen Daten angewendet werden können, beispielsweise auf Datenbankinhalte. Der Upgrade-Rahmen kann auch Tasks beinhalten, um die dynamischen Daten zwischen dynamischen Tasks von aufeinanderfolgenden Upgrade-Inhalten weiterzuleiten. Dieses erlaubt die in einer Echtzeitumgebung ständig auftretenden Ereignisse an einen nachfolgenden Upgrade-Inhalt zu liefern, nachdem sie durch einen vorhergehenden Upgrade-Inhalt verarbeitet worden sind.

Der Upgrade-Rahmen kann zumindest enthalten, Datenbanken oder Inhalte von Datenspeichervorrichtungen von dem Quellsystem zu dem Zielsystem zu transferieren, sowie ein Initialisieren des Aufzeichnens von dynamischen Daten in einer Ereignisdatei. Dies erlaubt, Tasks der Upgrade-Inhalte auf ein Minimum zu reduzieren.

Der Upgrade-Prozeß kann nach der Ausführung von jedem einzelnen Upgrade-Inhalt angehalten werden, was eine größere Flexibilität erlaubt, beispielsweise wenn ein zwischenzeitliches Testen des Systems während des Upgrades erwünscht ist.

Andere Vorteile der Erfindung ergeben sich aus weiteren abhängigen Ansprüchen.

Die Erfindung ist in ihrer Ganzheit besser zu verstehen, wenn sie zusammen mit den begleitenden Zeichnungen gesehen wird, in denen:

Fig. 1 eine schematische Zeichnung zeigt, die das Verfahren in Übereinstimmung mit der Erfindung veranschaulicht;

Fig. 2 ein Zeit/Flußdiagramm zeigt, das das Verfahren gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht;

Fig. 3 ein Ausführungsbeispiel des Verfahrens gemäß der Erfindung in einem Flußdiagramm veranschaulicht;

Fig. 4 die Anwendung von Tasks für statische Daten gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht;

Fig. 5 den Informationsfluß mit Bezug auf die Ereignisdatei veranschaulicht, sowie dynamische Tasks von einzelnen Upgrade-Inhalten gemäß einem Ausführungsbeispiel der Erfindung;

Fig. 6 ein Zeitdiagramm des aktiven Zustands von Upgrade Tasks in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht; und

Fig. 7 ein Ausführungsbeispiel einer Vorrichtung gemäß der Erfindung zeigt.

Im folgenden werden bevorzugt Ausführungsbeispiele der Erfindung mit Bezug auf die Figuren beschrieben.

Fig. 1 zeigt eine veranschaulichende Zeichnung des erfindungsgemäßen Verfahrens.

Im Beispiel von Fig. 1 wird ein Softwaresystem mit zwei Upgrades aktualisiert. Das Softwaresystem arbeitet auf einer Datenverarbeitungsvorrichtung. Das Softwaresystem kann beispielsweise eine Anwendung, ein Daten- oder Datenbank- Manager oder ein Betriebssystem sein. Jeder Aktualisierungsschritt erlaubt ein Aufrüsten des Softwaresystems von einer ersten Softwaresystemversion einer nachfolgend freigegebenen zweiten Softwaresystemversion, die vorzugsweise die nach der ersten Softwaresystemversion freigegebene Softwaresystemversion ist, es kann jedoch irgendeine beliebige andere nachfolgend freigegebene Softwaresystemversion sein.

Bei dem Verfahren gemäß der Erfindung wird der Upgrade-Betriebsvorgang in einen Upgrade-Rahmen und Upgrade-Inhalte unterteilt, wobei der Upgrade-Rahmen Tasks beinhaltet, die für jede der Vielzahl von Softwaresystem-Upgrades identisch sind, und die Upgrade- Inhalte Tasks beinhalten, die für die jeweiligen Softwaresystem-Upgrades spezifisch sind. Im vorliegenden Beispiel werden zwei Upgrade-Inhalte bereitgestellt.

In Fig. 1 stellt der gestrichelt markierte Teil den Upgrade- Rahmen für Upgrade-Inhalt 1 und Upgrade-Inhalt 2 dar, welche die spezifischen Aktivitäten der zwei Software-Upgrades des gezeigten Beispiels darstellen. Allgemein kann eine beliebige Anzahl von Upgrade-Inhalten vorgesehen sein, auch wenn im vorliegenden Beispiel nur zwei gezeigt sind.

Ein erster Teil des Upgrade-Rahmens besteht aus Upgrade- Tasks, die in einer anfänglichen Phase des Upgrade- Betriebsvorgangs ausgeführt werden sollen, bevor die Upgrade- Inhalte ausgeführt werden. Ein zweiter Teil des Upgrade- Rahmens besteht aus Upgrade-Tasks, die in einer Abschlußphase des Upgrade-Betriebsvorgangs ausgeführt werden sollen.

Zwischen den zwei die Upgrade-Inhalte 1 und 2 veranschaulichenden Kästen ist ein optionaler Teil des Upgrade-Rahmens gezeigt, der vorgesehen werden kann, um einen Datentransfer oder eine Kommunikation zwischen jeweiligen Upgrade-Inhalten durchzuführen. Dieser Teil des Upgrade- Rahmens beinhaltet beispielsweise Tasks für allgemeine Kommunikationsaufgaben. Dieser Teil des Upgrade-Rahmens ist mit einer gestrichelten Linie gezeichnet, um zu veranschaulichen, daß dieser Teil optional ist.

Im folgenden werden die Schritte für ein Durchführen des Upgrade-Betriebsvorgangs in Übereinstimmung mit dem Ausführungsbeispiel von Fig. 1 beschrieben.

Wie bereits ausgeführt, müssen für jeden beliebigen Upgrade- Schritt eine Anzahl von identischen Tasks ausgeführt werden, und im Falle, daß ein Upgrade über mehrere Softwaresystemversionen erwünscht ist, werden diese identischen Tasks in Übereinstimmung mit der Erfindung im Upgrade-Rahmen ausgeführt, wohingegen die Tasks für ein Durchführen der tatsächlichen Upgrade-Schritte in einer Abfolge ausgeführt werden, ohne die oben erwähnten identischen Tasks auszuführen.

Im vorliegenden Beispiel wird daher eine Anzahl von Upgrade- Rahmen-Tasks ausgeführt werden, allgemein gesagt, um die Datenverarbeitungsvorrichtung für das tatsächliche Aufrüsten vorzubereiten. Folgend wird der Upgrade-Inhalt 1 ausgeführt werden, der das System von der Softwaresystemversion V0 auf die Version V1 aufrüstet. Danach wird der Upgrade-Inhalt 2 ausgeführt, der das Softwaresystem von Version V1 zu Version V2 aufrüstet. Nachdem dieser Upgrade-Schritt beendet ist, werden wiederum Tasks des Upgrade-Rahmens ausgeführt, wobei diese Tasks wiederum für jeden Upgrade-Schritt identisch sind. Es wird darauf hingewiesen, daß Softwaresystemversion V0 eine beliebige anfängliche Softwaresystemversion bezeichnet.

Im Beispiel sei angenommen, daß die Datenverarbeitungsvorrichtung anfänglich, d. h. vor dem Upgrade-Betriebsvorgang mit einer Softwaresystemversion V0 arbeitet. Es ist weiter angenommen, daß die Softwaresystemversion V1 und eine Softwaresystemversion V2 wie auch entsprechende Upgrades bereits freigegeben worden sind. Die Upgrades bezüglich der Softwaresystemfreigabe V1 dient damit für ein Aufrüsten des Systems von Softwaresystemversion V0 auf Softwaresystemversion V1 und der Upgrade entsprechend zur Systemfreigabe V2 dient für ein Aufrüsten des Systems von Softwaresystemversion V1 auf Softwaresystemversion V2.

Es wird weiter angenommen, daß ein Upgrade von Softwaresystemversion V0 auf Softwaresystemversion V2 erwünscht ist.

Im Beispiel von Fig. 1 wird gemäß der Erfindung zuerst der erste Teil des Upgrade-Rahmens ausgeführt. Dies kann die Installation von temporärer Software für den Upgrade- Betriebsvorgang beinhalten, das Anbringen und Konfigurieren von zusätzlicher Hardware oder Servern. Dieser erste Teil des Upgrade-Rahmens kann auch die Replikation von Datenbanken oder beliebigen anderen Daten oder Dateien in Speichern der Datenverarbeitungsvorrichtung beinhalten. Die Daten oder Datenbanken können beispielsweise Daten bezüglich zu Anwendungen, Systembestandteilen beinhalten, oder können Teilnehmerdaten, beispielsweise eines Telefonnetzwerkes beinhalten, das durch das System betrieben wird.

Im folgenden wird ein Upgrade-Inhalt 1 ausgeführt, der das Softwaresystem von der Softwaresystemversion V0 auf die Softwaresystemversion V1 aufrüstet. Ein Upgrade-Inhalt beinhaltet allgemein Tasks für ein Ändern oder Einführen von Daten bezüglich Systemfunktionen oder ähnlichem, die neuerlich bereit gestellt werden, oder in der Softwaresystemversion V1 eine geänderte Funktion haben. Ein Upgrade-Inhalt kann auch Tasks für ein Ändern von Daten beinhalten oder der Struktur von Datenbanken oder anderen in der Datenverarbeitungsvorrichtung gespeicherten Daten.

Nach diesen spezifischen Tasks des Upgrade-Inhalts 1 wird Upgrade-Inhalt 2 ausgeführt. Dies sind wiederum spezifische Tasks, nun spezifisch für den Upgrade-Inhalt 2. Daten von Systemfunktionen oder ähnlichem, die neuerlich bereitgestellt werden, oder in der Softwaresystemfunktion V2 eine geänderte Funktion haben, können eingeführt oder geändert werden.

Falls nach dem Upgrade-Inhalt 1 und vor Upgrade-Inhalt 2 Tasks des Upgrade-Rahmens ausgeführt werden, können diese den Datenfluß zwischen Upgrade-Inhalt 1 und Upgrade-Inhalt 2 regeln. Dies kann ein Zwischenspeichern oder Puffern von Daten oder ähnlichem beinhalten.

Nachfolgend zu Upgrade-Inhalt 2 werden Tasks eines zweiten Teils des Upgrade-Rahmens ausgeführt. Dies beinhaltet allgemein das Entfernen von temporärer Software, das Abkoppeln von temporärer Hardware, usw. Es beinhaltet auch ein Wiederaufnehmen von Betriebsvorgängen, nun in Übereinstimmung mit der neuen Softwaresystemversion, die im vorliegenden Fall Version V2 ist.

Mit dem oben ausgeführten erfindungsgemäßen Verfahren kann ein beliebiger gewünschter Upgrade-Betriebsvorgang von einer beliebigen Softwaresystemversion zu einer anderen beliebigen Softwaresystemversion auf bequeme Weise zusammengestellt werden, und ohne ein Wiederholen von identischen Tasks für jeden einzelnen Upgrade-Schritt, bzw. ohne direkte Upgrades von einer bestimmten Softwaresystemversion zu einer anderen, beispielsweise eine von einem Kunden gewünschte, Softwaresystemversion zu entwickeln.

Fig. 2 zeigt ein Zeit/Flußdiagramm, das ein weiteres Ausführungsbeispiel des Verfahrens gemäß der Erfindung veranschaulicht.

Das Beispiel von Fig. 2 veranschaulicht, wie das erfindungsgemäße Verfahren auf ein Aufrüsten von Softwaresystemen auf Datenverarbeitungsvorrichtungen angewendet werden kann, die in einer Echtzeitumgebung arbeiten. Eine Echtzeitumgebung kann hier eine beliebige Umgebung sein, in der Betriebsvorgänge in Übereinstimmung mit auftretenden Ereignissen ausgeführt werden müssen. Dies kann eine unmittelbare Reaktion des Systems auf ein Ereignis beinhalten, beispielsweise eine Verarbeitung von Daten innerhalb von Millisekunden oder Sekunden, oder kann eine Reaktion des Systems innerhalb eines gewissen Zeitrahmens beinhalten, wobei dieser Zeitrahmen Minuten oder sogar Tage dauern kann. Ereignisse können beispielsweise eine Übertragung von Daten von Sensoren, einem Benutzer, angeschlossenen Geräten usw. sein.

Die Echtzeitanwendung des Ausführungsbeispiels aus Fig. 2 kann beispielsweise der Betrieb eines mobilen Kommunikationsnetzwerks sein. Somit kann ein Echtzeiterfordernis beispielsweise das Reagieren auf eine Leitungsanforderung sein, was einen kurzen erlaubten Zeitrahmen beinhaltet, oder ein Aktualisieren von Benutzerdaten, was eine weniger strikte Zeitanforderung haben kann.

Wie im einführenden Abschnitt ausgeführt, bewirkt ein Upgrade-Betriebsvorgang allgemein eine kurze Stillstandszeit des Systems, was insbesondere im Fall von Echtzeitanwendungen unerwünscht ist, da dies das System für diese Zeitperiode betriebsunfähig macht.

In Echtzeitanwendungen ist es wahrscheinlich, daß auch während des Aufrüstens Ereignisse eintreten. Diese Ereignisse können Nachrichten, Aktionen oder andere Formen von Informationen sein. Im vorliegenden Ausführungsbeispiel kann ein Ereignis eine Leitungsanforderung sein, eine Anforderung für die Zuweisung von Zeitschlitzen auf einem Träger für einen bestimmten Kanal, ein Ändern von Benutzerinformation oder ähnliches sein. Um den Verlust von Ereignissen zu verhindern, die während des Aufrüstens auftreten, werden alle solche Ereignisse vorzugsweise in einer Ereignisdatei aufgezeichnet. Diese Datei wird vorzugsweise ebenfalls aufgerüstet und in das System einbezogen, wenn die Ausführung der Upgrade-Inhalte beendet ist.

Der Upgrade-Betriebsvorgang der Software des vorliegenden Beispiels, z. B. eines Telekommunikationsnetzwerks, kann vorteilhafterweise unter Verwendung von zwei Datenverarbeitungsvorrichtungen ausgeführt werden, wobei eine Vorrichtung so lange wie möglich betriebsfähig gehalten wird, während der Upgrade-Betriebsvorgang und die andere Vorrichtung den Betrieb übernimmt, wenn der Upgrade- Betriebsvorgang beendet ist.

Im gezeigten Ausführungsbeispiel sind zwei Vorrichtungen für ein Ausführen des Upgrade-Betriebsvorgangs bereitgestellt. Dies ist ein Quellsystem SPU und ein Zielsystem TPU. Das Quellsystem enthält eine gegenwärtig aktive Datenverarbeitungsvorrichtung, die mit der Softwaresystemversion, beispielsweise V0 vor dem Upgrade- Betriebsvorgang arbeitet. Das Quellsystem bedient Funktionen in Verbindung mit der Echtzeitumgebung. Wie vorher ausgeführt, könnte das Softwaresystem ein Datenmanager, eine Anwendung oder sogar ein Betriebssystem sein.

Das Zielsystem TPU besteht aus einer Datenverarbeitungsvorrichtung, die anfänglich nicht betriebsfähig sein muß. Das Zielsystem TPU ist dafür vorgesehen, mit dem aufgerüsteten Softwaresystem zu arbeiten, was in dem gezeigten Ausführungsbeispiel eine Softwaresystemversion V2 sei. Da das Zielsystem noch nicht in der Echtzeitumgebung arbeitet, kann die aktualisierte Softwaresystemversion auf dem Zielsystem installiert werden, während das Quellsystem SPU betriebsfähig gehalten wird. Nachdem das Softwaresystem auf dem Zielsystem TPU von der Version V0 auf Version V2 aktualisiert worden ist oder auf dem Zielsystem installiert worden ist, werden Betriebsvorgänge von dem Quellsystem SPU zu dem Zielsystem TPU übergewechselt, welches von diesem Zeitpunkt an Funktionen und Dienste des Telekommunikationssystems ausführt. Wiederum steht die Version V0 für eine beliebige anfängliche Softwaresystemversion.

Somit können neue Eigenschaften der Softwaresystemversion V2, beispielsweise ein neuer Teilnehmerdienst zu dem Stand-by Telekommunikationsnetzwerk hinzugefügt werden, das auf dem Zielsystem installiert wird, ohne den Betrieb des Quellsystems zu unterbrechen.

Falls das Softwaresystem ein Datenmanager oder ähnliches ist, kann ein passendes Betriebssystem, beispielsweise das Betriebssystem des Quellsystems bereits auf dem Zielsystem installiert sein. Darüber hinaus kann für die neue Softwaresystemversion erforderliche Hardware ebenfalls auf dem Zielsystem vorinstalliert sein. Allgemein kann das Zielsystem in einem beliebigen Anfangszustand sein.

Das Vorgehen für ein Aufrüsten des Softwaresystems gemäß dem vorliegenden Ausführungsbeispiel im Falle eines Telekommunikationsnetzwerkes wird nun detailliert beschrieben.

Wie in Fig. 2 angedeutet und mit Bezug auf Fig. 1 beschrieben, ist das Aufrüsten in Übereinstimmung mit der Erfindung in einen ersten Teil eines Upgrade-Rahmens unterteilt, gefolgt von Upgrade-Inhalten und dann gefolgt von einem zweiten Teil des Upgrade-Rahmens.

Wiederum besteht der Upgrade-Rahmen aus Tasks, die für alle Upgrade-Schritte, die auszuführen sind, identisch sind. Im vorliegenden Fall ist die erste Aufgabe des Upgrade-Rahmens die Installation der gegenwärtigen Version V0 des Softwaresystems. Somit wird in einem ersten Schritt des Upgrade-Rahmens im vorliegenden Ausführungsbeispiel die Systemkonfiguration von dem Quellsystem SPU zu dem Zielsystem TPU, beispielsweise in einer Neuinstallation der Softwaresystemversion V0 übertragen. In anderen Ausführungsbeispielen kann die Softwaresystemversion V0 jedoch bereits auf dem Zielsystem TPU installiert sein.

Danach kann in weiteren Tasks des Upgrade-Rahmens die Installierung allgemeiner Software für den Upgrade- Betriebsvorgang auf dem Zielsystem TPU durchgeführt werden, z. B., um ein Ändern von Systemfunktionen oder Teilnehmerdiensten vorzubereiten, wie dies in den einzelnen Upgrade-Inhalten bestimmt ist. Falls notwendig, kann zusätzliche Hardware hinzugefügt und konfiguriert werden, beispielsweise Festplatten. Auch temporäre Software, beispielsweise Backup-Servers oder ähnliches kann installiert werden.

In einem nächsten Schritt des Upgrade-Rahmens werden Daten aus Speichern des Quellsystems oder Datenbankinhalte oder irgendwelche anderen Daten von des Quellsystems SPU zu dem Zielsystem TPU kopiert. Die Daten oder Datenbanken können beispielsweise Teilnehmerdaten, Netzwerkkonfigurationsdaten oder ähnliches enthalten.

Die kopierten Daten und anderen Daten auf dem Zielsystem TPU werden daher einen Zustand des Telekommunikationsnetzwerks zu einem bestimmten Zeitpunkt, zu dem sie von dem Quellsystem zum Zielsystem kopiert wurden, repräsentieren. Folglich müssen alle weiteren Änderungen oder Ereignisse, die an dem Quellsystem nach diesem Zeitpunkt auftreten, beispielsweise in einer Ereignisdatei aufgezeichnet werden, um in der Lage zu sein, sie während und zum Ende des Upgrade- Betriebsvorgangs zu berücksichtigen. Daher werden, wenn die Datenbanken zum Zielsystem kopiert werden, alle Ereignisse am Quellsystem in einer Ereignisdatei aufgezeichnet. Diese Ereignisdatei kann im Quellsystem oder im Zielsystem angeordnet sein.

Es wird darauf hingewiesen, daß das Quellsystem immer noch betriebsfähig ist.

In Fig. 2 wird der Aufzeichnungsprozeß begonnen, bevor die Datenbanken zum Zielsystem kopiert werden. In anderen Ausführungsbeispielen könnte jedoch das Aufzeichnen zur gleichen Zeit oder nachdem die Datenbanken kopiert worden sind gestartet werden, beispielsweise in Abhängigkeit vom Softwaresystem. Natürlich muß sichergestellt werden, daß keines der aufzuzeichnenden Ereignisse verloren geht.

Nach dem Kopieren des Systemzustands des Quellsystems SPU zum Zielsystem TPU ist das Zielsystem nunmehr für das tatsächliche Aufrüsten vorbereitet, d. h. die Ausführung der Upgrade-Inhalte. Im folgenden werden, während das Quellsystem SPU immer noch betriebsfähig ist, einzelne Upgrade-Inhalte auf dem Zielsystem TPU ausgeführt.

Im vorliegenden Beispiel wird zuerst ein Upgrade-Inhalt für ein Aufrüsten des Softwaresystems von Version V0 auf V1 ausgeführt. Dies kann ein Ändern von Systemfunktionen wie auch ein Aufrüsten der Datenbank oder anderer Daten, d. h. der vom Quellsystem hinüberkopierten statischen Daten beinhalten. Weiter beinhaltet dies ein Aufrüsten der in der Ereignisdatei aufgezeichneten Ereignisse, der sogenannten dynamischen Daten. Verfahren zum Aufrüsten von dynamischen Daten wie auch von statischen Daten sind dem Fachmann allgemein bekannt. Der Upgrade-Inhalt kann die Definition von Datenbanken, Tabellen oder anderen Daten, die für eine Replikation konfiguriert werden müssen, beinhalten, ein Beginn einer Funktionsänderung auf dem Zielsystem, unter Verwendung der Quellsystemdatenbank, und er kann weiter ein Einfügen der Datenbankänderungen beinhalten, die im Quellsystem während des Datenbank-Upgrades auf dem Zielsystem aufgezeichnet wurden, wie auch ein Ausführen von Shell-Scripts, Tabellendefinitionen und ähnlichem, welches für ein Aufrüsten des Softwaresystems von Version V0 auf Version V1 benötigt wird. Der Upgrade-Inhalt kann auch Schritte beinhalten, um zu definieren, welche Ereignisse in der Ereignisdatei aufgezeichnet werden sollen.

Nach dem Upgrade-Inhalt 1 beendet worden ist, wird Upgrade- Inhalt 2 d. h. das Aufrüsten des Softwaresystems von Version V1 auf V2 ausgeführt. Wiederum beinhaltet dies das Aufrüsten der statischen Daten, der Datenbank oder anderen Daten, die vom Quellsystem überkopiert wurden, Funktionsänderungen wie auch beim Aufrüsten der in der Ereignisdatei aufgezeichneten Ereignisse, welche vorhergehend durch den Upgrade-Inhalt 1 verarbeitet worden sind, und es kann weitere Tasks beinhalten, wie schon zuvor Upgrade-Inhalt 1.

Zu diesem Zeitpunkt ist das Quellsystem immer noch in einem betriebsfähigen Zustand.

Nachdem die Tasks der zwei Upgrade-Inhalte beendet worden sind, wird der zweite Teil des Upgrade-Rahmens durchgeführt. Das Softwaresystem auf dem Zielsystem wurde auf die erwünschte Softwaresystemversion V2 aufgerüstet, das Zielsystem TPU arbeitet jedoch noch nicht in der Echtzeitumgebung des Telekommunikationsnetzwerks des vorliegenden Ausführungsbeispiels. Der Betrieb wird immer noch vom Quellsystem SPU durchgeführt, unter Verwendung der Softwaresystemversion V0 vor den Upgrade-Betriebsvorgängen. Daher umfaßt der zweite Teil des Upgrade-Rahmens Tasks, um alle Kommunikationsverbindungen oder Leitungen vom Quellsystem auf das Zielsystem umzuschalten, was eine einzige kurze Stillstandszeit des gesamten Upgrade-Betriebsvorgangs zur Folge hat. Nach einem Umschalten der Kommunikationsverbindungen ist das Zielsystem TPU in der Echtzeitumgebung betriebsfähig, das Quellsystem SPU arbeitet nicht mehr. Darüber hinaus können im zweiten Teil des Upgrade-Rahmens Tasks enthalten sein, um temporäre Software, Hardware und andere upgrade-spezifische Konfigurationen vom Zielsystem TPU zu entfernen.

In anderen Ausführungsbeispielen kann der oben beschriebene Upgrade-Betriebsvorgang auch mit einem einzelnen System ausgeführt werden, dann tritt beispielsweise die Replikation der statischen Daten intern statt. In diesem Fall jedoch könnte es sein, daß das System nicht wie im obigen Beispiel während des gesamten Aufrüstens betriebsfähig ist, obwohl alle Ereignisse immer noch in der Ereignisdatei aufgezeichnet werden, kann es sein, daß sie nicht alle in Echtzeit während des Upgrades abgearbeitet werden können.

Im folgenden wird mit Bezug auf das Flußdiagramm von Fig. 3 ein anderes Ausführungsbeispiel des erfindungsgemäßen Upgrade-Verfahrens beschrieben.

Im Beispiel von Fig. 3 ist der Upgrade-Betriebsvorgang wiederum in einen Upgrade-Rahmen und Upgrade-Inhalte unterteilt, wie es vorher ausgeführt worden ist. Eine beliebige Anzahl von Upgrade-Inhalten kann ausgeführt werden, somit kann das Softwaresystem um eine beliebige Anzahl von Versionen aufgerüstet werden. Es wird angenommen, daß das Betriebssystem eines Telekommunikationssystems aufgerüstet wird. Somit wird der Upgrade-Betriebsvorgang im vorliegenden Beispiel in einer Echtzeitumgebung ausgeführt und Ereignisse wie Leitungsanforderungen oder ähnliches werden zufällig auftreten. Diese Ereignisse stellen die dynamischen Daten dar, die in der Ereignisdatei aufgezeichnet werden, wie dies vorher ausgeführt wurde. Neben dynamischen Daten werden Daten aufgerüstet, die während des Upgrade-Betriebsvorgangs keinen Änderungen unterzogen sind, beispielsweise Datenbanken oder andre Daten, was die statischen Daten darstellt.

In Fig. 3 werden in einem Schritt S31 nach der Initialisierung des Upgrade-Betriebsvorgangs Tasks eines ersten Teils des Upgrade-Rahmens ausgeführt. Dies kann ein Laden oder Replizieren einer Datenbank und die Installation von temporärer Software, Hardware und ähnliches beinhalten, wie vorhergehend ausgeführt. In einem Schritt S32 wird ein Zähler mit n = 1 initialisiert. Der Zähler ermöglicht eine Auswahl eines bestimmten Upgrade-Inhalts zur Ausführung. Dieses vervollständigt den ersten Teil des Upgrade-Rahmens.

Während des Aufrüstens müssen alle Upgrade-Inhalte auf die statischen Daten wie auch auf die dynamischen Daten angewendet werden, wie vorher mit Bezug auf Fig. 3 ausgeführt. Somit umfaßt jeder Upgrade-Inhalt statische Tasks für ein Aufrüsten von statischen Daten wie auch dynamische Tasks für ein Aufrüsten von dynamischen Daten. Daher wird in einem Schritt S33 ein Upgrade-Inhalt 1 für die dynamischen Daten der Ereignisdatei ausgeführt. Der Upgrade-Inhalt für dynamische Daten kann beispielsweise Tasks für ein Anpassen des Formats oder der Inhalte der dynamischen Daten auf die neue Softwaresystemversion beinhalten und kann ein Definieren der aufzuzeichnenden Daten beinhalten. In einem Schritt S34 wird der Upgrade-Inhalt für statische Daten auf die Datenbanken und/oder upzugradenden Daten angewendet. Dies kann ein Definieren von Datenbanktabellen beinhalten, die für eine Replikation konfiguriert werden müssen und ein Beginnen einer Funktionsänderung auf dem Zielsystem TPU unter Verwendung der Datenbanken oder Daten des Quellsystems SPU.

Wie zuvor ausgeführt, können die Schritte S33 und S34 auch Funktionsänderungen für die Datenbank, ein Verarbeiten der Ereignisdatei mit Upgrade-Tasks für dynamische Daten und ähnliches beinhalten. Es wird darauf hingewiesen, daß der Ausführungszeitpunkt der Schritte S33 und S34 beliebig ist, sie können zur gleichen Zeit ausgeführt werden, oder in einer Abfolge.

In einem Schritt S35 wird überprüft, ob ein Bediener eine Unterbrechungsanforderung eingegeben hat oder ob der letzte Upgrade-Inhalt ausgeführt worden ist. Im Falle der Nein- Alternative wird in einem Schritt S36 n um 1 erhöht und der Ablauf kehrt zu den Schritten S33 und S34 zurück, in denen nun Upgrade-Inhalt 2 auf die dynamischen Daten wie auch auf die statischen Daten angewendet wird. Folgend wird im Schritt S36 wiederum überprüft, ob eine Unterbrechungsanforderung durch einen Bediener eingegeben worden ist, oder ob der letzte bereitgestellte Upgrade-Inhalt ausgeführt worden ist.

Auf analoge Weise werden die statischen Tasks von allen folgenden Upgrade-Inhalten aufeinanderfolgend auf die statischen Daten angewendet und die dynamischen Daten der Ereignisdatei werden aufeinanderfolgend durch dynamische Tasks von allen Upgrade-Inhalten verarbeitet. Im Falle der Ja-Alternative im Schritt S35 schreitet der Ablauf zu einem zweiten Teil des Upgrade-Rahmens fort. In diesem Fall ist entweder der letzte Upgrade-Inhalt ausgeführt worden, oder der Upgrade-Betriebsvorgang wurde durch einen Bediener angehalten, um Systemtests oder ähnliches durchzuführen.

In einem Schritt S37 wird die Ereignisdatei aufeinanderfolgend durch dynamische Tasks von jedem Upgrade- Inhalt verarbeitet, auf die statischen Daten, beispielsweise die Datenbank angewendet. Dies kann auf eine einer Echtzeitverarbeitung von Ereignissen analoge Weise durchgeführt werden. Nunmehr wurde die Datenbank oder anderen Speicherinhalte der statischen Daten auf die erwünschte Softwaresystemversion aufgerüstet, indem die aufgerüsteten aufgezeichneten Ereignisse der Ereignisdatei eingefügt wurden. Somit stellen die statischen Daten die Datenbank oder Daten in Übereinstimmung mit der neuen Softwaresystemversion und in Übereinstimmung mit allen während des Aufrüstens aufgetretenen Ereignissen dar.

Nun können, wie dies mit Bezug auf das vorhergehende Ausführungsbeispiel von Fig. 2 beschrieben wurde, in dem zweiten Teil des Upgrade-Rahmens Kommunikationsverbindungen auf geeignete Weise umgeschaltet oder eingerichtet werden und in einem Schritt S38 kann temporäre Software, Hardware, und ähnliches entfernt werden.

Fig. 4 veranschaulicht die Anwendung von statischen Tasks einer beliebigen Anzahl von Upgrade-Inhalten auf statische Daten in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung.

In Fig. 4 wird wiederum angenommen, daß ein in einer Echtzeitumgebung arbeitendes System aufgerüstet wird. Eine Datenbank DB wurde zu einem bestimmten Zeitpunkt repliziert, und stellt die statischen Daten dar. Es können jedoch irgendwelche Arten von Daten die statischen Daten darstellen.

Der Pfeil auf der linken Seite von Fig. 4, bezeichnet mit t, indiziert die Zeit während des Aufrüstens. Upgrade-Inhalte S1, S2, ..., Sn für ein Aufrüsten von statischen Daten sind veranschaulicht. Jeder der Upgrade-Inhalte für statische Daten wird in einer Sequenz auf die statischen Daten angewendet, in diesem Fall die Datenbank. Wie dies veranschaulicht ist, wird jeder Upgrade-Inhalt unabhängig von den anderen auf die Datenbank angewendet. Das heißt, die statischen Daten der Datenbank werden unter Verwendung der statischen Tasks eines Upgrade-Inhaltes S1 aufgerüstet und nachdem der Upgrade-Inhalt S1 ausgeführt worden ist, werden die statischen Daten der Datenbank unter Verwendung der statischen Tasks eines Upgrade-Inhaltes S2 aufgerüstet. Auf eine analoge Weise kann eine beliebige Anzahl von Upgrade- Inhalten, bis zu einem Upgrade-Inhalt Sn auf die Datenbank angewendet werden, nachdem die vorhergehenden beendet worden sind, wodurch die Datenbank Version um Version aufgerüstet wird. Die Upgrade-Inhalte werden vorzugsweise in der Reihenfolge ihrer Freigabe abgearbeitet, d. h. eine Softwaresystemversion entsprechend einem Upgrade-Inhalt S1 wurde freigegeben, bevor die Softwaresystemversion entsprechend eines Upgrade-Inhaltes S2 freigegeben wurde, etc. Eine spätere Freigabe bezieht sich auf eine neuere Softwaresystemversion.

Fig. 5 veranschaulicht den Informationsfluß bezüglich der Ereignisdatei und dynamische Tasks von einzelnen Upgrade- Inhalten in Übereinstimmung mit einem weiteren Ausführungsbeispiel der Erfindung. Es wird wieder angenommen, daß das System in einer Echtzeitumgebung arbeitet.

Im vorhergehenden Ausführungsbeispiel wurde gezeigt, daß statische Daten aufeinanderfolgend mit statischen Tasks von Upgrade-Inhalten, die in einer bestimmten Reihenfolge in jeweiligen Zeitfenstern ausgeführt werden, aufgerüstet werden kann. Für dynamische Daten, d. h. die in einer Ereignisdatei aufgezeichneten Ereignisse, ist das Vorgehen anders. Da angenommen wird, daß das System in einer Echtzeitumgebung arbeitet, werden Ereignisse kontinuierlich während des gesamten Upgrades auftreten und in der Ereignisdatei aufgezeichnet werden. Dieses hat zur Folge, daß dynamische Daten der gesamten Ereignisdatei, die während des Upgrades aufgezeichnet wurde, aufeinanderfolgend durch die dynamischen Tasks der einzelnen Upgrade-Inhalte verarbeitet werden müssen, bis der Upgrade-Betriebsvorgang endet.

Fig. 5 zeigt, daß die Ereignisdatei zuerst durch eine dynamische Task D1 eines ersten Upgrade-Inhalts abgearbeitet wird. Die aktualisierten Ereignisse werden dann durch dynamische Tasks D2 eines zweiten Upgrade-Inhalts bearbeitet und nachfolgend durch eine beliebige Anzahl von Upgrade- Inhalten für dynamische Daten bis zu einem letzten Upgrade- Inhalt Dn. Diese Verarbeitung der Ereignisdatei ist ein kontinuierlicher Betriebsvorgang während des gesamten Upgrade-Betriebsvorgangs, da alle zu irgendeiner Zeit während des Aufrüstens aufgezeichnete Ereignisse von allen Upgrade- Inhalten für dynamische Daten D1-Dn verarbeitet werden müssen. Beim Ende des Aufrüstens, wenn keine weiteren weiteren Ereignisse in der Ereignisdatei aufgezeichnet sind, wird die aktualisierte Ereignisdatei auf die statischen Daten angewendet, beispielsweise auf die Datenbank, die vorhergehend durch die statischen Tasks von allen einzelnen Upgrade-Inhalten für statische Daten aufgerüstet worden ist.

Der Upgrade-Rahmen kann auch Schnittstellentasks für dynamische Daten zwischen einzelnen Upgrade-Inhalten bereitstellen, wie dies mit Bezug auf das erste Ausführungsbeispiel von Fig. 1 ausgeführt worden ist.

In Fig. 4 und Fig. 5 wurde die Ausführung von statischen Tasks und dynamischen Tasks erklärt. Fig. 6 veranschaulicht ein Zeitdiagramm in Übereinstimmung mit einem weiteren Ausführungsbeispiel der Erfindung.

In Fig. 6 werden die tatsächlichen Ausführungszeiten von jeder einzelnen Upgrade-Task veranschaulicht. Der mit t bezeichnete Pfeil indiziert die Zeit während eines Aufrüstens. Mit S1, S2 und Sn bezeichnete Kästen stehen für statische Tasks einer Vielzahl von Upgrade-Inhalten. Die länglichen mit D1, D2 und Dn bezeichneten Kästen veranschaulichen entsprechende dynamische Tasks der Vielzahl von Upgrade-Inhalten. Es ist angenommen, daß die Numerierung der Upgrade-Tasks die Freigabezeit der entsprechenden Softwaresystemversionen reflektiert, beispielsweise entspricht die dynamische Task D1 einer Softwaresystemversion, die vor einer Softwaresystemversion mit zugehörigen dynamischen Tasks D2 freigeben worden ist.

Da die Datenbank während des Upgrades statisch oder invariabel ist, können die statischen Tasks der Upgrade- Inhalte in einer zeitlichen Abfolge angewendet werden, wie dies mit Bezug auf Fig. 4 beschrieben wurde. Im Gegensatz dazu muß die gesamte während des gesamten Aufrüstens aufgezeichnete Ereignisdatei durch die dynamischen Tasks von allen Upgrade-Inhalten verarbeitet werden. Daher müssen dynamische Tasks, nachdem sie in Entsprechung der Ausführung eines bestimmten Upgrade-Inhaltes gestartet worden sind, kontinuierlich neue in der Ereignisdatei aufgezeichnete Ereignisse verarbeiten, bis das Aufrüsten vervollständigt worden ist. Somit verbleiben dynamische Tasks eines bestimmten Upgrade-Inhalts aktiv und verarbeiten kontinuierlich Ereignisse der Ereignisdatei, die durch dynamische Tasks eines vorhergehenden Upgrade-Inhaltes verarbeitet worden sind.

Nachdem das Aufzeichnen von Ereignissen gestoppt worden ist, was normalerweise dann vorliegt, wenn alle Upgrade-Inhalte ausgeführt worden sind, und bevor das aufgerüstete Softwaresystem in Betrieb genommen wird, kann die aufgerüstete Ereignisdatei in die Datenbank eingefügt werden, wobei die Datenbank vorhergehend durch die statischen Tasks von allen Upgrade-Inhalten aufgerüstet worden ist.

Fig. 7 zeigt ein Auführungsbeispiel eines Systems in Übereinstimmung mit der Erfindung. Es wird angenommen, daß das System Teil eines Telekommunikationsnetzwerkes ist.

Das in Fig. 7 gezeigte System dient einem Aufrüsten eines Softwaresystems, das in einer Echtzeitumgebung arbeitet, mit einer Vielzahl von Upgrade-Inhalten, wobei jeder der Upgrade- Inhalte das Softwaresystem von einer Softwaresystemversion auf eine nachfolgend freigegebene Softwaresystemversion aufrüstet.

Das System umfaßt: ein Quellsystem SPU mit einer Zentralverarbeitungseinheit CPU, eine Datenbankspeichervorrichtung DB, beispielsweise um Teilnehmerdaten und Statusinformation bezüglich des Netzwerkzustands zu speichern, und eine Ereignisdatei EM für ein Aufzeichnen von Ereignissen, die während des Aufrüstens auftreten, beispielsweise Teilnehmerdaten, Rufanforderungen und ähnliches, wie dies mit Bezug auf vorhergehende Ausführungsbeispiele ausgeführt wurde. Das Quellsystem SPU umfaßt Kommunikationsleitungen zu einer Vielzahl von externen Vorrichtungen ED1-EDn, beispielsweise n Kommunikationsleitungen. Im Falle, daß das Quellsystem ein Mobiltelefonnetzwerk betreibt, können die Vorrichtungen Mobiltelefone oder Knoten des Netzwerks sein. Die Quellsystem verarbeitet Ereignisse in Echtzeit, beispielsweise Rufanforderungen und Teilnehmerdaten in einem Telefonnetzwerk. Das Quell-System SPU arbeitet basierend auf einem Softwaresystem vor dem Upgrade.

Das System umfaßt weiter ein Zielsystem TPU, die ebenfalls mit einer zentralen Datenverarbeitungseinheit CPU und einer Datenbankspeichervorrichtung DB ausgerüstet ist. Die Datenbankspeichervorrichtung des Zielsystems TPU ist dazu angeordnet, eine Kopie der Datenbankinhalte des Quellsystems SPU vor dem Upgrade zu empfangen. Weiter ist das Zielsystem mit dem Quellsystem SPU verbunden, um die Datenbankinhalte vor dem Aufrüstens zu empfangen, sowie Ereignisdateiinhalte während des Aufrüstens.

Während des Aufrüstens wählt das Zielsystem TPU die Vielzahl von Upgrade-Inhalten aus, wobei jeder der Upgrade-Inhalte Upgrade-Tasks enthält, die spezifisch für das entsprechende Softwaresystem-Upgrade sind, wobei die Upgrade-Inhalte in der Reihenfolge der Freigabe der entsprechenden Softwaresystemversionen ausgeführt werden. Da das Aufrüsten statische und dynamische Daten betrifft, umfaßt das Zielsystem TPU eine Upgrade-Vorrichtung, um statische Daten zu aktualisieren, wobei die statischen Daten Datenbanken und Speicherinhalte vor dem aufrüsten sind, und umfaßt weiter eine Upgrade-Vorrichtung um dynamische Daten aufzurüsten, die Ereignissen entsprechen, die in der Ereignisdatei EM aufgezeichnet sind.

Das System umfaßt weiter eine Schaltvorrichtung, die mit dem Quellsystem SPU und dem Zielsystem TPU und den externen Vorrichtungen verbunden ist. Nachdem die Ausführung der Upgrade-Inhalte beendet worden ist, schaltet die Schaltvorrichtung die Kommunikationsleitungen zwischen dem Quellsystem SPU und der Vielzahl von externen Vorrichtungen zu dem Zielsystem TPU um. Somit übernimmt das Zielsystem TPU die Betriebsvorgänge von dem Quellsystem SPU, unter einer Verarbeitung mit dem aufgerüsteten Softwaresystem.

Claims (13)

1. Verfahren zum Aufrüsten eines Software Systems auf einer Datenverarbeitungsvorrichtung um eine Vielzahl von Softwaresystemversionen, unter Verwendung von Upgrades für ein Aufrüsten des Software Systems von einer Software System Version auf eine nachfolgend freigegebene Softwaresystemversion, umfassend:
Ausführen von Tasks eines ersten Teils eines Upgrade-Rahmens, wobei der Upgrade-Rahmen Tasks umfaßt, die für die Vielzahl von Softwaresystem-Upgrades identisch sind, einschließlich beispielsweise eines Kopierens von statischen Daten von einem Quellsystem (SPU) zu einem Zielsystem (TPU) und/oder eines Aufzeichnens von dynamischen Daten in einer Ereignisdatei;
Ausführen einer Vielzahl von Upgrade-Inhalten, wobei jeder der Upgrade-Inhalte Tasks beinhaltet, die für das entsprechende Softwaresystem-Upgrade spezifisch sind, wobei die Upgrade-Inhalte in der Reihenfolge der Freigabe der entsprechenden Softwaresystemversion ausgeführt werden;
Ausführen von Tasks eines zweiten Teils des Upgrade-Rahmens, einschließlich beispielsweise eines Umschaltens von Kommunikationsverbindungen von dem Quellsystem zu dem Zielsystem.

2. Verfahren zum Aufrüsten eines Softwaresystems nach Anspruch 1, dadurch gekennzeichnet, daß die Datenverarbeitungsvorrichtung in einer Echtzeitumgebung arbeitet.

3. Verfahren zum Aufrüsten eines Softwaresystems nach den Ansprüchen 1 oder 2, gekennzeichnet durch ein Aufrüsten von statischen Daten, wobei die statischen Daten Datenbank und/oder Speicherinhalte vor dem Aufrüsten darstellen und/oder Aufrüsten von dynamischen Daten, die während des Upgrade-Betriebsvorgangs auftretenden Ereignissen entsprechen und die dynamischen Daten in einer Ereignisdatei aufgezeichnet werden.

4. Verfahren zum Aufrüsten eines Softwaresystems nach Anspruch 3, dadurch gekennzeichnet, daß
die Datenverarbeitungsvorrichtung zumindest ein Quellsystem (SPU) beinhaltet, das basierend auf einer Softwaresystemversion vor dem Upgrade-Betriebsvorgang arbeitet, und ein Zielsystem (TPU) um mit dem aufgerüsteten Softwaresystem zu arbeiten;
der erste Teil des Upgrade-Rahmens zumindest ein Kopieren von statischen Daten von dem Quellsystem (SPU) zu dem Zielsystem (TPU) und/oder ein Beginnen eines Aufzeichnens von dynamischen Daten in der Ereignisdatei beinhaltet; und
der zweite Teil des Upgrade-Rahmens zumindest den Vorgang eines Umschaltens von Kommunikationsverbindungen von dem Quellsystem zu der Zielsystem beinhaltet.

5. Verfahren zum Aufrüsten eines Softwaresystems nach den Ansprüchen 3 oder 4, dadurch gekennzeichnet, daß
jeder Upgrade-Inhalt statische Tasks für ein Aufrüsten von statischen Daten und/oder dynamische Tasks für ein Aufrüsten von dynamischen Daten beinhaltet;
die statischen Tasks von jedem Upgrade-Inhalt aufeinanderfolgend auf die statischen Daten angewendet werden;
die dynamischen Daten der Ereignisdatei aufeinanderfolgend durch dynamische Tasks von jedem Upgrade-Inhalt verarbeitet werden; und
die aufgerüsteten dynamischen Daten auf die statischen Daten angewendet werden, nachdem der Upgrade der statischen Daten beendet worden ist.

6. Verfahren zum Aufrüsten eines Softwaresystems nach einem der Ansprüche 3-5, dadurch gekennzeichnet, daß der Upgrade-Rahmen Tasks für ein Weiterleiten von dynamischen Daten zwischen dynamischen Tasks von aufeinanderfolgenden Upgrade-Inhalten umfaßt.

7. Verfahren zum Aufrüsten eines Softwaresystems nach einem der Ansprüche 3-6, dadurch gekennzeichnet, daß jeder Upgrade-Inhalt umfaßt, Ereignisse zu definieren, die in der Ereignisdatei aufzuzeichnen sind.

8. Verfahren zum Aufrüsten eines Softwaresystems nach einem der Ansprüche 3-7, dadurch gekennzeichnet, daß jeder Upgrade-Inhalt umfaßt:
ein Definieren von Datenbanktabellen, die für eine Replikation zu Konfigurieren sind; und
ein Start einer Funktionsänderung auf dem Zielsystem TPU unter Verwendung von Datenbanken des Quellsystems (SPU).

9. Verfahren zum Aufrüsten eines Softwaresystems nach einem der Ansprüche 1-8, dadurch gekennzeichnet, daß der Upgrade-Betriebsvorgang nach jedem Upgrade-Inhalt abgehalten werden kann.

10. Verfahren zum Aufrüsten eines Softwaresystems nach einem der Ansprüche 1-9, dadurch gekennzeichnet, daß das Softwaresystem ein Betriebssystem und die Datenverarbeitungsvorrichtung zumindest Funktionen in einem Telekommunikationsnetzwerk ausführt.

11. Vorrichtung zum Aufrüsten eines Softwaresystems mit einer Vielzahl von Upgrade-Inhalten, wobei jeder der Upgrade-Inhalte das Softwaresystem von einer Softwaresystemversion auf eine nachfolgend freigegebene Softwaresystemsversion aufrüstet, umfassend:
ein Quellsystem (SPU) mit einer zentralen Datenverarbeitungsvorrichtung CPU, eine Datenbankspeichervorrichtung (DB), eine Ereignisdatei (EM) für ein Aufzeichnen von während des Upgrade- Betriebsvorgang auftretenden Ereignissen, Kommunikationsleitungen zu einer Vielzahl von externen Vorrichtungen (ED1-EDn) und das Quellsystem (SPU) basierend auf einer Softwaresystemversion vor dem Upgrade-Betriebsvorgang arbeitet;
ein Zielsystem (TPU) mit einer zentralen Verarbeitungsvorrichtung (CPU) und einer Datenbankspeichervorrichtung (DB) und Verbindungsleitungen zu dem Quellsystem (SPU), die Datenbankinhalte vor dem Upgrade und Inhalte der Ereignisdatei während des Aufrüstens empfängt, und die die Vielzahl von Upgrade-Inhalten ausführt, wobei jeder der Upgrade-Inhalte Upgrade-Tasks beinhaltet, die für den entsprechenden Softwaresystem-Upgrade spezifisch sind, wobei die Upgrade-Inhalte in der Reihenfolge der Freigabe der entsprechenden Softwaresystemversionen ausgeführt werden; und
eine Schaltvorrichtung, um die Kommunikationsleitungen zwischen em Quellsystem (SPU) und der Vielzahl von externen Vorrichtungen zu dem Zielsystem (TPU) umzuschalten.

12. Vorrichtung zum Aufrüsten eines Softwaresystems nach Anspruch 11, dadurch gekennzeichnet, daß das System in einer Echtzeitumgebung arbeitet.

13. Vorrichtung zum Aufrüsten eines Softwaresystems nach Anspruch 11, dadurch gekennzeichnet, daß das Zielsystem (TPU) eine Upgrade-Vorrichtung einschließt, um statische Daten aufzurüsten, wobei die statischen Daten Datenbanken und Speicherinhalte vor dem Upgrade sind und/oder eine Upgrade-Vorrichtung, um dynamischen Daten aufzurüsten, die in der Ereignisdatei (EM) aufgezeichneten Ereignissen entsprechen.