JPH10510376A - 状態転移可能な同期化方法 - Google Patents

Abstract

(57)【要約】 この発明は、動作中のコンピュータ内のソフトウェアの置き換えに関係し、特に、旧ソフトウェア内のプロセスから新ソフトウェア内のプロセスの間の状態の転移の同期化に関する。旧ソフトウェアおよび新ソフトウェアで実行するプロセスの間の状態転移の同期化は、次のステップを含む。すなわち、来るべき停止のために旧ソフトウェア内の旧静的プロセスを準備し、それを状態転移のために作動させることと、引継のために新ソフトウェア内の新静的プロセスを準備し、旧静的プロセス内の全ての資源オブジェクトを新静的プロセスに転送すること、全てのサービスを除去することを旧ソフトウェアに命令し、前記旧静的プロセスを終結することと、新静的プロセスに引継を履行させ、前記新静的プロセスが、以前に旧静的プロセスが請求した全ての資源オブジェクトの唯一の所有者である事を指示することとを含む。

Description

【発明の詳細な説明】 状態転移可能な同期化方法 発明が属する技術の分野 この発明は、操作コンピュータシステムでのソフトウェアの置き換えに関し、 特に、旧ソフトウェア内のプロセスから新ソフトウェア内のプロセスへの間の状 態転移の同期化に関する。 先行技術の説明 コンピュータソフトウェアの一面は、ユーザへ適切な機能性を提供し続け、ソ フトウェアを最適化し、ソフトウェアの寿命を通じて起こる誤りと不一致を訂正 するために、改訂、追加、および／または削除により、それを定期的に更新しな ければならないことである。ソフトウェアに新しい機能が追加されれば、新ソフ トウェアの機能をユーザに提供するために、出来るだけ早く旧ソフトウェアを新 バージョンに置き換えることが望ましい。 スタンドアロン処理システムやバッチ処理システムのような、あるタイプの計 算機システムにおいて、あるバージョンから他のバージョンへソフトウェアを取 り替えることは、僅かな問題しか生じない。典型的に、活動が少なく保守の人員 がすぐに利用可能である一日のある時間に、コンピュータシステムが単に運転停 止する。それから旧ソフトウエアが単純に除去されそのソフトウェアの新バージ ョンに置き換えられる。その後、計算機システムは再始動され、今後の全てのデ ータ処理はこのソフトウェアの新バージョンで行われる。この手順は、もちろん 、新ソフトウェアがオフラインシステム上で適切にデバッグされテストされて、 コンピュータシステム全体を停止し再始動させることを要する不当な割込みなし に、新ソフトウェアが目的の機能を適切に遂行することに、ソフトウェア職員と 操作管理者が確信を有するまでになっていることを仮定している。 他のタイプの計算機システム、現代の蓄積プログラム制御（ＳＰＣ）通信交換 機システム（業界では一般に単に「交換機」と呼ばれている）のようなものにお いては、ソフトウェアの新バージョンのテストも、システム内のソフトウェアの 取り替えも、スタンドアロン処理システムやバッチ処理システムでのように簡単 ではない。例えば、ソフトウェアの新バージョンは、実際の動作処理の呼び出し へ配置されなければテストできない。このソフトウェアが実際の動作の条件の下 で適切に機能するか、また新しい部分が動作しているＳＰＣ交換機システムの一 部を形成する他の全てのソフトウェアブロックと適当にインタフェイスするかど うかを決定するために、このソフトウェアを動作中にテストしなければならない 。更に、通信交換機システムは実質上決して非動作状態にはならない。理想的に は、通信交換機は、コミュニティ内の通信サービスの継続的な需要の故に、中断 無く絶えず走っている。すなわち、昼も夜も休み時間もシステムを通じて処理さ れる通信トラヒックの連続的な流れがあり、交換機の操作への何らかの割り込み は通信トラヒックの望ましくない混乱に終わる。こうした混乱は、システムのユ ーザや顧客の承認に対してばかりでなく、システムの動作とその有効性に対して も大きな損害になることがある。 通信交換機システムのこれらのリアルタイム要件は、交換機で処理中の既存の 通信トラヒックを混乱させずにする誤り訂正すなわち交換台での「バグ直し」を 含むソフトウェアの置き換えと、新機能性か改良機能性を含むソフトウェアかそ の部分のテストの両方に、厳しい制約を課する。それゆえ、伝統的な「エディッ ト−コンパイル−リンク−ロード−ラン」のアプローチを使用しているシステム の中に、ソフトウェアのコンポーネントまたはユニットを組み込むことは、望ま しいことではない。 通信交換機のような動作中のコンピュータシステムに関連したもう一つの問題 は、旧ソフトウェア内のプロセスから新ソフトウェア内のプロセスへの間の状態 の転送であり、特にその同期化である。あるプロセスは資源オブジェクトを使用 するか含んでなり、資源オブジェクトはハードウェア資源上または内部データ構 造上の情報を取り扱うオブジェクトタイプである。この発明の文脈では、状態転 移は資源オブジェクトの状態の転送であると理解すべきである。資源オブジェク トの状態は、配分または非配分（allocation or deallocation）を特徴とする。 旧ソフトウェア内の工程から新ソフトウェアへの状態の転送は、資源オブジェク トの状態がいくつかのトランザクションにより使用され、生存し得るから、シス テムのユーザまたは顧客にとって必須のものである。プロセスの状態は時間と共 に変化するので、あらかじめこれらのプロセスの状態を新ソフトウェアに組み込 むことは不可能であり、従って、もしそれが生存しようとしているならば、旧ソ フトウェアから新ソフトウェアへ、その置き換えの間に転送されなければならな い。好ましいのは、使用不能時間の必要なしに、システムの動作中に、ソフトウ ェアの新旧バージョンの間の状態の転送と一緒にソフトウェアを修正または拡大 する能力を提供する方法である。 動作中のコンピュータシステムに新しいソフトウェアを組み込む事に関連する 問題を解決する試みがなされてきた。例えば、今日使用されているいくつかの進 歩したオンライン動作可能システムで、スタンドアロンまたはバッチ方式で動作 しないものは、スタンドアロンまたはバッチシステムに使用される方法とは明ら かに異なった方法で、古いソフトウェアの置き換え問題を解決する。 しかしながら、こうしたシステムは、スタンドアロンシステムでよりも遙かに 明快にではあるが、やはり手作業でシステムを置き換えていて、個別ユーザまた はユーザグループがソフトウェアの新または改バージョン使用して処理するか否 かを積極的に選択する必要がある。このオプションは、個別ユーザＩＤの下で作 動するプロセスに利用されるソフトウェアの連結をユーザが修正することで実行 される。このオプションは、通常数週間または数ヶ月の所定期間内、ユーザが利 用可能であり、この間にソフトウェアは各先行レベルで不一致のない作動に成功 してから、連結構造のいくつかのレベルを上へ移動する。連結の最上レベルに達 したら、ソフトウェアは「動作可能」と宣言され、旧バージョンはもはやシステ ムのユーザが使用不可能になる。新ソフトウェアをシステムに挿入することは、 種々のレベルへのソフトウェアの上への移動と同様に、計算機構成管理の工程、 すなわち報告し、承認し、各レベルでのソフトウェアバージョンを追跡し、承認 した変更を実施する手作業工程により制御される。 バッチシステムまたはスタンドアロンシステム上のソフトウェア更新で用いた 方法と同様に、こうした方法でシステムに、新または改ソフトウェアを組み込む ことの欠点は良く知られている。それは大部分手作業の、複雑で時間を消費する 労働集約的なシステムである。ユーザにとって新規のソフトウェアで、少しずつ 、 制限されたオンラインで使用しながら、エラーが増殖せず、またはすぐに進行中 の動作に影響しないようにする手段が何もないある新しいソフトウェアにより、 システムが作動するか否か、どんな場合に作動するかの制御を、このシステムは 放置している。新または改ソフトウェアへのアクセスの制御方法は、このソフト ウェアを実行する個別のユーザに直接に結合し限定されている。 更に、この方法は、ソフトウェアの旧バージョンから新バージョンへ状態を転 送する手段を何も提供しない。こうして、旧ソフトウェアから新ソフトウェアへ の状態転移が失われ、もちろんこれはユーザに否定的な仕方で影響し得る。 動作中のコンピュータシステムの更新に関連する問題の少なくともいくつかを 解決するために他の試みが行われてきた。例えば、テレフォンアクティボラゲー ト・エル・エム・エリクソンの米国特許出願第０７／９０７，２９４号には、操 作的コンピュータシステムにおけるソフトウェアの置き換えの方法が開示されて いる。この方法により通信交換機の実際の操作中に、システムを通して進行中の 通信トラヒックを混乱させることなく、ソフトウェアをテストし、変更すること ができる。しかしながら、この方法は、ソフトウェアの旧バージョンから新バー ジョンへの状態の転送に向けられていない。この方法は、そうした状態転移の必 要を認めるが、旧ソフトウェアから新ソフトウェアへのデータ転送を同期させる 手段を何も記述していない。 従って、システムを通じて進行中のトラヒックを混乱させることなく、通信交 換機の実際の操作中に、旧ソフトウェアから新ソフトウェアへのプロセスの状態 転移を含むソフトウェアのテストと変更が出来ることは、通信産業界内で非常に 有用なことであろう。この発明は、そうした方法を提供する。 発明の要約 ＳＰＣ通信交換機システムのような計算機システムの動的振舞いは、一連の並 列的な、比較的独立したトランザクション（「スレッド」または「イベントの連 鎖」とも呼ばれる）として本質的に記述される。ここで、全てのトランザクショ ンは、関連する多数の活動から構成されている。あるトランザクションは、典型 的に、システムの外部ユーザに見えて、機能的に有用な仕事を成し遂げる。通信 交換機システムでは、典型的なトランザクションは、呼び出し（発呼）である。 この発明による状態転移付きの順調な変更技法を用いたオンラインソフトウェ ア置き換えは、同時に新旧両方のソフトウェアバージョンを記憶できるメモリと 一緒に、トランザクション指向のソフトウェアを使用する。新バージョンへ状態 を転送する順調な変更は、進行中のトランザクション、すなわち「旧トラヒック 」を、旧ソフトウェアバージョンを使用して完了まで走らせることにより達成さ れる。ソフトウェアの変更が既に始まってからスタートするトランザクション、 すなわち「新トラヒック」は、新ソフトウェアバージョンを使って、徐々にコン トロールされた仕方で走らされる。旧バージョンから新バージョンへ転送される べき状態を含むプロセスは、ソフトウェア変更のはじめには、旧ソフトウェアの 制御下にある。種々の同期信号により、新ソフトウェアは旧ソフトウェアの制御 下にあるプロセスの状態へ「必要ベースで」アクセスできるので、新ソフトウェ アのテストが妨害無く進行しさえすれば、結局は更新された状態を含むプロセス の所有者になる。 この発明の状態転移による順調なソフトウェア変更により充足された基本的要 件は、ユーザ妨害が最小ないし皆無であることと、高レベルのシステム信頼性を 含む。この発明の基本的性格は、次の事実を含む。（１）一つのソフトウェアバ ージョンだけが各特定のトランザクションを制御する、すなわち、トランザクシ ョンの開始から終了まで新または旧ソフトウェアバージョンを使用するので、ト ランザクション（すなわち呼び出し）の間に、システムの個別ユーザは、最小の 妨害しか経験しないか、または全く経験しない。（２）変更の間、両方のソフト ウェアバージョンが平行して使用されるので、ソフトウェア変更のために個別ユ ーザが利用不可能を経験することはない。（３）ソフトウェアの新旧バージョン の間の制御された状態転移のために旧ソフトウエア内のプロセスの状態が一つも 失われない。 システムにより処置され転送されなければならないプロセスの状態は、この文 脈内で二種類に分けられる。（１）トランザクションの間に生成され使用され、 またトランザクション完了後に削除される動的プロセス。（２）いくつかのトラ ンザクションに使用され生き残る静的プロセス。例えば、テレコムシステムにお いて、システムに接続された加入者番号またはある加入者が使用する短縮番号に ついての状態を含むプロセス。 妨害最小を要求されるオンラインソフトウェア置き換えに関連する決定的問題 は、旧ソフトウェアバージョンの状態が新ソフトウェアバージョンに転移されな ければならないことである。旧および新ソフトウェアの両方がソフトウェア変更 の間に平行して作動しているので、明らかに動的プロセスの転移の必要が全く無 い。すなわち、プロセスがスタートしたソフトウェアバージョン内で、プロセス が完了する。しかしながら、例えば新しい呼び出しをいずれのバージョン内で実 行するかを制御可能にするために、選択ポイントが備えられて、トラヒックを適 当なソフトウェアバージョンに向ける。 この発明は、システムのアップグレードの間にどのソフトウェアが使用される べきかを識別する機構を提供する。通常のトラヒックテストの他に、トラヒック は選択ポイントでも識別されなければならず、それからソフトウェアの新バージ ョンに向けられ、これは通常の（実際の）トラヒックを実行する前にテストされ なければならない。 他の面では、この発明の方法は、また、ソフトウェアの旧バージョン内の静的 プロセスの状態転移を新バージョンに同期させる手段を提供する。この発明によ る旧、新ソフトウェアで実行されるプロセスの間の状態転移の同期化は、下記の 操作を含んでなる。 停止準備（PropareShutdown）は、旧ソフトウェアすなわちシステムアップグ レードにより置き換えられるソフトウェア内で宣言される静的プロセスの最初の 操作である。この操作は、置き換えられるソフトウェアの来るべき終了に対して アプリケーションを準備する。停止準備信号を受け取った後に、旧ソフトウェア 内の静的プロセスは、資源オブジェクト（状態）の転送のための特定アプリケー ション向インターフェイスを公示すなわち作動させる。資源オブジェクトは、そ の主目的がハードウェア資源または内部データ構造上の情報の取り扱いであるオ ブジェクトのタイプである。すなわち、資源オブジェクトの転送と共に、そうし た情報の状態が転送される。 この最初の操作の完了後に、新ソフトウェア内のアプリケーションのための静 的プロセスがスタートし、この新静的プロセスがテストトラヒックと共に呼び出 され、旧静的プロセスが所有する状態転移のためのインターフェイスを通じて、 旧静的状態から必要な資源を得る。新ソフトウェア上の妨害なしにテストトラヒ ックが走れば、ソフトウェアの新バージョンにより通常トラヒックが実行される が、状態転移のためのインターフェイスは、やはり旧静的プロセスが所有してい る。 この通常トラヒックも何の妨害もなく進行すれば、新ソフトウェア内の静的プ ロセスに引継信号（Takeover signal）が加えられる。この操作により、新ソフ トウェアが全ての残りの資源の制御を旧ソフトウェアから獲得するが、それは旧 静的プロセスが所有する状態転移のためのインターフェイスを通じてである。 その後、停止履行（CommitShutdown）の操作が旧静的プロセスに適用される。 それからアプリケーションが、停止準備操作で公示すなわち活性化した状態転移 のためのそのインターフェイスを除去する。 最後に、引継履行（CommitTakeover）の操作がソフトウェアの新バージョンに 適用される。新静的プロセスは、新ソフトウェアが履行されたことを知らされる 。旧ソフトウェアシステム部分に依存しているプロセスは、終結される。 ソフトウェアが適正に機能しない場合は、アップグレードの手順が引き戻しさ れ得る。引継の操作よりも前に引き戻しが行われた場合は、ユーザへの何の妨害 もなしにこの引き戻しを遂行できる。引き戻しは、引継履行操作をソフトウェア の新バージョンの代わりにソフトウェアの旧バージョンに適用することにより行 われる。 図面の簡単な説明 この発明と更にその目的のより良い理解のために、以下の説明を添付図面と共 に、これから参照することができる。 第１図は、一般的な通信システムを示す。 第２図は、一般的な通信システムにおけるシステムアーキテクチャを示す。 第３図は、旧ソフトウェアから新ソフトウェアへの再指示処理のための例示的 な手順を図解するブロック図である。 第４図は、この発明による引き戻しなしのシステムアップグレードの間の同期 化を示す。 第５図は、この発明による引き戻し付きのシステムアップグレードの間の同期 化を示す。 第６図は、システムアップグレードの間の同期化と状態転移を示す。 第７ａ図から第７ｎ図までは、順調なシステムアップグレード方法が資源サー バーに適用された実例を示す。 好ましい実施例 この発明による状態の変更を含む新旧ソフトウェアの置き換え方法は、一例と して、ＳＰＣ通信交換機システム（以下に「交換機」という）で使用できよう。 交換機２、分散プロセッサ４、アプリケーションソフトウェア６、データベース ８、電話１０、を含む一般的な通信システムが、第１図に描かれている。交換機 ２は、一台またはそれ以上のプロセッサ４に接続されている。プロセッサ４はま た、アプリケーションソフトウェア６、データベース８、に周知のように接続さ れている。 そうしたシステムにこの発明を如何に応用できるかを充分に理解するために、 第２図に示すシステムアーキテクチャをこれから説明する。 この構造体の最も基礎的な要素は、オペレーティングシステムであり、そこに 最も基礎的な機能が組み込まれている。この発明によるオペレーティングシステ ムは、例えば、システムアップグレードと呼ばれる機能を含んでなる。このシス テムアップグレード機能は、例えばＣ＋＋のようなオブジェクト指向プログラミ ングで実現されるが、この発明の方法によって使用されている。このシステムア ップグレード機能は、「コンピュータ操作中のソフトウェア変更のためのシステ ム」と題するテレホンアクティーボラゲート・エル・エム・エリクソンの米国特 許出願第０７／９０７，２９４号に一層詳しく説明されているので、ここに引用 し本明細書に組み入れる。オペレーティングシステムに加えて、アプリケーショ ンシステムがあり、この例では二つの部分、すなわち、通信システム内で交信に 使用される規格である＃７信号方式のような、全てのソフトウェアアプリケーシ ョンに共通な部分（ＡＰＰ）と、ＩＳＤＮ、ＰＯＴＳ、ＧＳＭ、ＶＬＬなどのよ うな各アプリケーションのための特定のソフトウェアに分けられる。 最もしばしば置き換えられアップグレードされるソフトウェアは、例えば上記 の通信システムでは、ＩＳＤＮ、ＧＳＭなどのアプリケーションソフトウェアで ある。この発明の説明においては、ソフトウエアの置き換えまたはアップグレー ドは、全アプリケーションソフトウェアの置き換えからその一部分の置き換えま でのあらゆる物であり得ると理解すべきである。 この発明による方法によれば、ソフトウェアの新バージョンはアップグレード 中に旧バージョンと共存している。この方法では、通常のトラヒックがソフトウ ェアの旧バージョン上で走っているときに、新ソフトウェアをテストトラヒック でテストできる。新ソフトウェアに関連し得る故障が起きた場合は、アップグレ ードが引き戻されて、新ソフトウェアは除去される。システムアップグレード中 の引き戻しは、システムアップグレードソフトウェア内で内部的に検出された異 常により開始される。故障管理は引き戻しを強制することができ、保守技術者も アップグレードを中止して、これにより引き戻しをする可能性を与えられている 。 上記のように、一回にソフトウェアの一部だけを置き換えることが典型的であ る。置き換えるべきソフトウェアは、変更ユニットと呼ばれる。第３図において 変更されてないソフトウェアユニット２０が、指示点と呼ばれるアドレス機構２ ２を通じて、旧変更ユニット１２と新変更ユニット１４に結合している。変更さ れてないインターフェイス１６と１８が、旧変更ユニット１２と新変更ユニット １４をアドレス機構２２へリンクしている。第３図は、旧ソフトウェアバージョ ン内の変更すなわち旧変更ユニット１２があり、また、新ソフトウェア内の変更 すなわち新変更ユニット１４がある場合を図解する。新変更ユニット１４は、定 義により、変更されてないソフトウェア２０の既存のインターフェイス１８に適 合したインターフェイス１６を有するように選ばれている。これは、変更されて ないソフトウェアが、新旧両ソフトウェアバージョン（変更ユニット）と協働出 来ることを意味している。 この発明のこの側面、すなわち、トランザクションの動的指示または再指示は 、指示点の導入および使用により、容易になる。これらの指示点は、トランザク ションを特定の仕方で管理し得る分散システム上の場所から構成される。第３図 に図解されたようなアドレシング機構２２は、指示点の実施と、それによりシス テムのトランザクションが新または旧トランザクションに個別に指示される手段 を 示す。これらの指示点は、三つの異なった方法で操作できる。第１に、システム が処理するトラヒックに関連した機能名を分析することにより、これらをトリガ できる。この操作方法により、必要な処理の遂行に要求される特別な機能の新ま たは旧ソフトウェアバージョンへ、トラヒックを指示できる。第２にトランザグ ションは、ソフトウェアをリンクする実行時間の結果として供給された情報に基 づいて、プログラムの新または旧ソフトウェアバージョンを実行するように指示 され得る。 これから同期化の２つの異なった場合を説明するが、その一つは引き戻しなし でつまり成功したアップグレードを意味し、もう一つはシステムのアップグレー ド中に引き戻しが始まる場合である。引き戻しがない第１の場合は第４図に示し 、引き戻し付きの第２の場合は第５図に示す。図面において、プロセスはコーナ ーをカットした長方形で記号的に示されている。一つの資源はひとつまたはそれ 以上の資源オブジェクトを有し得る。資源オブジェクトの例はタイムスロット、 音声プロンプティング装置などである。 第４図はソフトウェアの旧バージョンが、ソフトウェアの新バージョンに置き 換えられた時の引き戻しなしのシステムアップグレード中の同期化の種々の段階 を示す。 段階１の間に旧ソフトウェア内の旧静的プロセスは、新ソフトウェアがロード され新静的プロセスがスタートする以前に、停止準備信号（PrepareShutdown si gnal）により呼び出される。旧ソフトウェア内の静的プロセスはこの信号により 、その来るべき終結と除去を知り状態の転送を準備する。旧静的プロセスは、資 源オブジェクトの状態の転送のために、アプリケーション定義インタフェイスを 公示（publish）すなわち作動させる。公示とは、プロセスが他のプロセスと交 信する仕方の定義を意味する。このインタフェイスは、のちに資源オブジェクト の割り当てのために、ソフトウェアの新バージョン内の静的プロセスによって呼 び出される。旧静的プロセスは、隣接する諸プロセス、たとえばディストリビュ ータプロセスに、来るべき終結を通知し、上記した米国特許出願第０７／９０７ ，２９４号に従って経路指示が冗長な代案に対してなされるようにする。段階１ の間、全てのトラヒックは、ソフトウェアの旧バージョンによって普通に取り 扱われる。この第１段階は、新ソフトウェアがロードされた時に終わりになる。 第２段階において、新ソフトウェア内の静的プロセスが、最初のスタートとは 異なった状態でスタートする。代わって、静的プロセスは、ソフトウェアの新旧 バージョンそれぞれの中での新旧静的手順の間の状態の転送があることを示すよ うな仕方でスタートしなければならない。この段階の間に妨害なしにテストトラ フィックが進行すれば、新静的プロセスはテストトラヒックとこれに続く正常な （生きている）トラフィックを受け取る。テストトラヒック中の状態転移の同期 化は、システムアップグレード中の状態転移を説明する第６図に関連して一層詳 細に説明される。この第２段階中に通常トラヒックは第１にソフトウェアの旧バ ージョンによって、ソフトウェアの新バージョンによって取り扱われるテストト ラヒックと同時的に取り扱われる。それからテストトラヒックが終わった後に始 まる「新」トラヒックが、新ソフトウェアによって取り扱われる。「新」トラヒ ックすなわちテストトラヒックの終結に先立つ通常トラヒックは、それが終結す るまでソフトウェアの旧バージョンにより取り扱われる。 この例は引き戻しなしのシステムアップグレードを説明しているので、テスト トラヒックおよびこれに続いて実行される正常のトラヒックも何の妨害も無しに 進行する。したがって第３段階においては、新ソフトウェア内の静的プロセスが 、引継信号（Takeover signal ）により、旧ソフトウェア内の静的プロセスの全 ての資源オブジェクトを要求するように命令される。これは、新ソフトウェア内 に宣言された、静的プロセス上のシステムアップグレード機能により導入された 最初の操作である。状態転移のために公示すなわち活性化されたアプリケーショ ン定義インタフェイスは、資源オブジェクトの制御を転送するため、また全ての 資源オブジェクトを引継するために、この新静的プロセスによって呼び出される 。この第３段階中に、旧トラヒックの残部は別として、ほとんど全てのトラヒッ クは新ソフトウェアにより取り扱われる。 第４段階において、旧プロセスは停止履行信号（CommitShutdown signal ）に より全ての仕事を除去すること、すなわち旧プロセスが利用できる資源オブジェ クトはもはや何もないようにすることを命令される。この停止履行信号が旧プロ セスに適用されるべき時期に関して、２つの異なった基準が使用可能である。第 １にこの信号は、旧ソフトウェアによって取り扱われる全ての旧トラヒックが終 結したときに旧プロセスに適用できる。これにより、取り扱うべきトラヒックが もはや無くなるまで旧ソフトウェアのサービスが取り去られないので、進行中の トラヒックがシステムアップグレードの間に妨害されることがない。第２にこの 信号は、システムアップグレードが開始された時から出発してある時間が経過し た後に、旧プロセスに適用され得る。これはしばしば遙かに速いアップグレード 手順を与えるが、いくつかのトラヒック（呼び出し）が失われる危険もある。サ ービスが除去された後に、資源の転送に使用されたインタフェイスが撤去される 。停止履行信号が与えられた後に、全てのトラヒックはソフトウェアの新バージ ョンにより取り扱われる。 この後、第５段階において旧ソフトウェアはブロックされ除去されて、第６段 階において、以前に旧プロセスから要求された資源オブジェクトの唯一の所有者 は新プロセスである。これは引継履行信号（CommitTakeover signal ）により、 新プロセスに指示される。この信号は、システムアップグレード機能が履行され 静的プロセスがアップグレードを維持時に送信される。 第５図は、ソフトウェアの旧バージョンがソフトウェアの新バージョンに置き 換えられる時に引き戻しが生じたシステムアップグレード中の種々の段階と同期 化を示す。この場合と第４図と比較したこの場合のおもな相異は、引継履行信号 の受け手である。この場合では、旧ソフトウェア内で実行している静的プロセス は、資源オブジェクトの受け手であり所有者である。引き戻しは、操作および保 守の技術者により開始されたり、または自動的に実行されたりする。 システムアップグレード中の引き戻しは、第４図に関連して上記したように、 旧静的プロセスに適用される停止履行信号に先立つ任意の時期に実行できる。ど の段階でアップグレード手順が引き戻しされるかによって、結果は異なる。第５ 図に関して、引き戻しの２つの異なる場合を説明する。 第１の場合は、矢印引継履行（CommitTakeover）１で示され、引き戻しは第２ 段階すなわち新静的プロセスが引継信号を受け取る以前に実行される。第２段階 中に、最初にテストトラヒックが、それから通常トラヒックが、新静的手順によ り取り扱われる。テストトラヒックの期間に、新ソフトウェアによる問題が起こ れば、自動的にまたはアップグレード技術者により、引継履行信号が旧静的プロ セスに適用されることにより、引き戻しが開始される。この瞬間に旧静的プロセ スはまだ全ての資源オブジェクトの所有者であるので、引き戻しにより旧静的プ ロセスの状態が一つも失われない。起こりうる唯一のことは、テストトラヒック が停止することである。テストトラヒック中の時間は、ユーザがいかなる形でも 影響されないので、引き戻しを遂行するのに最も一般的でまた最も適切な時期で ある。引き戻しはまた段階２のやや後の方で、すなわち新ソフトウェアが通常の トラヒックを実行し始める時期にも、実現できる。この時期に引き戻しを実行し ても、やはり引き戻しのために旧静的プロセスの状態が一つも失われない。もし 新ソフトウエアに厳しい問題があれば、進行中の通常のトラヒックの実行に問題 があり得るが、しかし新ソフトウェアは通常のトラフィックをその終結まで取り 扱うことを試みる。引き戻しの後に、すなわち引継履行信号が旧静的プロセスに 適用された後に始まる全ての通常のトラヒックは、旧ソフトウェアにより取り扱 われる。 第２の場合は、矢印引継履行（CommitTakeover）２で示され、引き戻しは引継 信号が新静的プロセスに適用された後、すなわち段階４に実行される。上記のよ うに、引継信号の後は、新ソフトウェアが全ての資源オブジェクトを制御する。 旧静的プロセスに接種履行信号を適用することにより、引き戻しが可能であるが 、しかし引継信号と引継履行信号の間の時間に変化した新しい静的プロセス中の 状態が失われる。 引継履行信号が旧静的プロセスに適用された後でも引き戻しをすることが可能 であるが、しかし旧ソフトウェアが先に出発しなければならないので全ての状態 が失われる。 第６図に関して、システムアップグレード中の状態転移が説明される。上記し た第１段階で活性化すなわち公示された状態転移インタフェイスが、アプリケー ションによって特定され、新静的プロセスが旧プロセスから資源オブジェクトの 制御を協同し転送できるようにしなければならない。第６図および以下の説明に おいて、このインタフェイス内の以下の一般的な操作が使用される。 ゲットリソース（GetResource）は、特定の資源オブジェクトの制御を旧静的 プロセスから新静的プロセスへ転送する操作である。この操作は、旧静的プロセ スに制御されている特定の資源オブジェクトを新静的プロセスが必要とする時に 呼び出される。 ゲットエニイリソース（GetAnyResource）は、任意の資源オブジェクトの制御 を旧静的プロセスから新静的プロセスへ転送する操作である。この操作は旧静的 プロセスに制御されている任意の資源オブジェクトを新静的プロセスが必要とす る時に、呼び出される。 ゲットオールリソース（GetAllResource）は旧静的プロセスの中に残っている 全ての資源オブジェクトの状態情報の制御を新静的プロセス転送する操作である 。この操作は新静的プロセスが引継信号を受け取った後にだけ、実行できる。 システムアップグレード中の同期化および状態転移が、第６図に関連して、こ れから一層詳細に説明される。ここで、アップグレード手順は８段階に分けられ る。 アップグレード手順が開始する前に、旧ソフトウェア上でトラヒックが通常の ように走る。第１段階で、旧静的プロセスはシステムアップグレードによる来る べき終結を停止準備操作で知らされ、その後にアプリケーションが状態転移のた めのインタフェイスを作動させすなわち公示して、続くシステムアップグレード を可能にするのは前述の通りである。それから、第２段階で、新ソフトウェア内 のアプリケーションのための静的プロセスが開始する。この段階で、活性化すな わち公示されるポートネームは旧ソフトウエアのためのものと同一である。 その後新ソフトウエアは、第３段階でテストトラヒックを受け入れ準備完了す る。テストトラヒックはコンピュータで生成することもできるし、操作および保 守の技術者によって遂行される「生の」 トラヒックであってもよい。テストト ラヒック期間中に新ソフトウエアは、ソフトウェアの旧バージョンの静的プロセ スに所有される資源オブジェクトを必要とする。新静的プロセスは、状態転移の ためのインタフェイスを通して、ゲットエニイリソース操作により、旧静的プロ セスから必要な資源オブジェクトを獲得する。新静的プロセスが資源オブジェク トにアクセスした後も、資源オブジェクトはなお旧静的プロセスに所有されてい る。 もしテストトラヒック期間が妨害なしに進行すれば、新静的プロセスは通常の トラヒックにより、第４段階で呼び出され、そして状態転移のためのインタフェ イスを通して、ゲットリソース操作またはゲットエニイリソース操作により、旧 静的プロセスから必要な資源オブジェクトを獲得する。新ソフトウェアにより新 トラヒックが取り扱われるこの期間中に、新静的プロセスに請求されてはいるが 、なお、旧静的プロセスに所有されている資源オブジェクトの状態が変わり得る 。この変化は、旧静的プロセスが、これら資源オブジェクトの所有者であるので 、そこに送り返されるが、もし、これがなされなければ、引き戻しが必要になっ た場合に、この更新された状態の情報が失われる。この段階の後には、状態情報 を失う危険なしに引き戻しすることはもはや不可能である。 第５段階で、新静的状態は、システムアップグレード機能の引継により、呼び 出される。一方これはゲットオールリソース操作を作動させる。この新静的プロ セスは、今や旧静的プロセスから全ての資源オブジェクトの制御を獲得する。第 ６段階で、旧静的プロセスは停止履行操作により呼び出され、アプリケーション は第１段階で、作動されたすなわち公示されたインタフェイスを除去する。この 後、第７段階で、システムアップグレード機能により、旧静的プロセスが、終結 される。最後の第８段階で、新静的プロセスは、システムアップグレードにより 、新ソフトウェアが履行されたことを知らされる。旧ソフトウェアシステム部分 に従うプロセスは、終結される。 順調なシステムアップグレード方法を資源サーバ上に適応した実際的な例を第 ７ａ図から第７ｎ図までと共に、以下に説明する。資源サーバは、プール資源（ pool resource ）の配分および非配分を制御する静的プロセスである。プール資 源は、相互に均等な資源オブジェクトである。すなわちたとえばＤＴＭＦ受信機 、経路またはエコーキャンセラ内のチャンネルのように、プール内の全ての資源 オブジェクトは相互に変更できる。第７図において、Ｒはプール資源を表現する オブジェクトである。もし資源が遊休していれば、第７ａ図の左側の様にそれは 明るい背景を有している。もし資源が配分されていれば、第７ａ図の右側の様に それは陰影をつけている。資源サーバに制御されていない資源は、第７ｃ図の右 側部分にあるように点線で描かれている。 システムアップグレード（System Upgrade）を作動させる前に、資源の配分 （allocation）および非配分（deallocation）が通常の方法で第７ａ図のように 実行される。もし要求された資源を割り当てることができなければ要求プロセス は資源不足について通知される。この振る舞いはたとえ進行中のシステムアップ グレードがあり、状態転移のためのインタフェイスを通して配分が行われても変 化しない。 資源サーバに適応された順調なシステムアップグレード方法が第６図と共に説 明された８段階に対応して説明される。 第７ｂ図に示す様にアプリケーションはシステムアップグレードによる終結に っいて通知される。上記したように資源サーバは停止準備信号を受け取った後に 状態転移のためのインタフェイスを公示する。その後第７ｃ図に示すように新資 源サーバが第２段階でスタートする。新資源サーバ内の資源は第７ｃ図に示すよ うに資源サーバにより制御されない資源である。旧資源サーバはなお従来通り資 源の配分および非配分の呼び出しを実行する。 第３段階で第７ｄ図に示すように、テストトラヒックは新資源サーバと反対の 経路を取り、一方通常のトラヒックは旧資源サーバと反対の経路を取っている。 新資源サーバに要求された資源の制御は、ゲットリソース操作により状態転移の ためのインタフェイスを通じてフェッチされる。第７ｅ図に示すように第７ｄ図 のテストトラヒックにより要求された資源は、新資源サーバ内に割り当てられる 。 テストトラヒックが新資源サーバにより成功的に取り扱われた後に、第４段階 で第７ｆ図に示すように、通常トラヒックが新資源サーバに反対に向けられる。 資源の制御は、ゲットエニイリソース操作により、状態転移のためのインタフェ イスを通して、必要な時にフェッチされる。第４段階には２つの可能性がある。 第７ｇ図と第７ｈ図に示すように、資源は新資源サーバから配分され非配分され る。第７ｇ図に右下のコーナに資源が配分され第７ｈ図で元に戻る。もう一つの 場合は、旧資源サーバにより第３段階の初期に資源が配分されそれから新資源サ ーバにより非配分された場合である。この場合新資源サーバは第７ｉ図に示され たゲットリソース操作により状態転移用インタフェイスを通してこの特定の資源 の制御を要求する。左上コーナーの資源は、第７ｂ図の第１段階で旧資源サーバ 内に保存され、第４段階で新資源サーバへ返される。資源の制御はゲットリソー ス操作により状態転移用インタフェイスを通じて要求される。 第５段階で、第７ｊ図と第７ｋ図のように、残りの全ての資源の制御が状態転 移用インタフェイスを通じてフェッチされる。新資源サーバは引継操作でシステ ムアップグレード機能により呼び出される。また、残りの資源は、第７ｊ図のゲ ットオールリソース操作で、状態転移用インタフェイスを通じてフェッチされる 。ゲットオール操作の後に、新資源サーバは全ての資源をコントロールするが、 これは第７ｋ図に左下コーナの資源の新資源サーバへの転送により示されている 。 第７ｌ図に示す第６段階において、第６図と共に前記したように、旧資源サー バ停止履行操作でシステムアップグレードから呼び出される。第７ｍ図に示す第 ７段階において、旧資源サーバはシステムアップグレード機能により終結させら れる。最後の第８段階において、旧ソフトウェアシステム部分に依存する動的プ ロセスは、システムアップグレード機能引継履行により終結させられる。 これまでの説明により、この発明の方法は明らかになったと思われる。図示さ れ説明された方法は好ましいものとして特徴付けられてきたが、以下の特許請求 の範囲に定義されたこの発明の精神と範囲から離れることなく、種々の変更と修 正がここでなされ得ることは、おのずから明らかである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＢＲ，ＣＡ，ＣＮ，Ｆ Ｉ，ＪＰ，ＫＲ，ＭＸ，ＮＯ，ＳＧ，ＵＳ (72)発明者 マルクストロム，ウルフ スウェーデン国 エス − 113 46 ス トックホルム，バナディスベーゲン 32

Claims (1)

1. 【特許請求の範囲】 １．進行中の活動を妨害せずに、ソフトウェアの旧バージョンを新バージョン で置き換え中に、旧バージョン中に宣言された旧静的プロセスから、新バージョ ン中に宣言された新静的プロセスへ、資源オブジェクトの状態転移を可能にする 同期化方法であって、 来るべき停止のために旧ソフトウェア内の旧静的状態を準備し状態転移のため それを作動させるステップと、 引継のために新ソフトウェア内の新静的プロセスを準備し旧静的プロセス内の 全ての資源オブジェクトを新静的プロセスへ転送するステップと、 旧静的プロセスに全てのサービスを除去することを命令し、静的プロセスを終 結するステップと、 新静的プロセスに引継を履行させ、新静的プロセスが、以前旧静的プロセスか ら請求された全ての資源オブジェクトの唯一の所有者である事を指示するステッ プを含む、前記同期化方法。 ２．停止のために旧静的状態を準備する前記ステップは、状態転移用インター フェイスを作動させることすなわち公示することを含んでいる請求の範囲第１に よる同期化方法。 ３．引継のために新静的プロセスを準備するステップは、新静的プロセスがテ ストデータを受け取る期間中に新静的プロセスに要求される旧静的プロセス内の ある資源オブジェクトを、状態転移用インターフェイスを通じて配分または非配 分する事を含む請求の範囲第２による同期化方法。 ４．新ソフトウェアによるテストデータの成功した処理に応答して、全ての資 源オブジェクトが前記旧静的プロセスから前記新静的プロセスへ転送される請求 の範囲第３による同期化方法。 ５．新ソフトウェアによるテストデータの不成功な処理に応答して、前記新ソ フトウェアが除去され、前記資源オブジェクトが前記旧ソフトウェアに制御され たまま残る請求の範囲３による同期化方法。 ６．進行中の活動を妨害せずに、通信システム中でソフトウェアの旧バージョ ンを新バージョンに置き換える方法であって、 来るべき停止のために旧ソフトウェア内の前記旧静的プロセスを準備し、それ を前記状態転移のため作動させるステップと、 前記旧ソフトウェアが通常トラヒックを処理している間に、新ソフトウェアを 前記通信システムにロードするステップと、 前記旧ソフトウェア上の前記通常のトラヒックの処理と平行して、テストトラ ヒックにより前記新ソフトウェアをテストするステップと、 前記旧ソフトウェアによる前記旧通常トラヒックと平行して、前記新ソフトウ ェアにより新通常トラヒックを処理するステップと、 引継すべき前記新ソフトウェア内の前記新静的プロセスを準備し、前記旧静的 プロセス内の全ての資源オブジェクトを前記新静的プロセスに転送するステップ と、 全てのサービスを取り去るように前記旧静的プロセスに命令し、前記旧静的プ ロセスを終結するステップと、 前記新静的プロセスに引継を履行させ、以前に前記旧静的プロセスから請求さ れた全ての前記資源オブジェクトの唯一の所有者は、新静的プロセスであること を指示するステップを含んでいる、前記方法。 ７．停止のために前記旧静的プロセスを準備するステップは、状態転移用イン ターフェイスを作動させることすなわち公示することを含む請求の範囲６による 前記方法。 ８．前記新ソフトウェアをテストする前記ステップは、テストトラヒックの期 間中に新静的プロセスに要求された、旧静的プロセス内の一定の資源オブジェク トを、状態転移用インターフェイスを通して、配分および非配分する事を含む請 求の範囲６または７による前記方法。 ９．新ソフトウェアによるテストトラヒックの成功した処理に応答して、全て の資源オブジェクトが旧静的プロセスから新静的プロセスに転送される請求の範 囲８による方法。 10．新ソフトウェアによるテストトラヒックの不成功な処理に応答して、新ソ フトウェアが除去され、資源オブジェクトが旧ソフトウェアに制御されたまま残 る請求の範囲８による方法。