(57)【要約】【課題】運用系のアプリケーションの動作状態が不明であっても、当該アプリケーションと競合しないように他のアプリケーションを円滑に起動することを目的とする。【解決手段】情報処理装置の第１のアプリケーションの起動を要求する起動要求を受け付け、前記起動要求に応じて、前記第１のアプリケーションに対応する第２のアプリケーションを実行する他の情報処理装置のオペレーティングシステムの停止を検出した場合に、前記第１のアプリケーションを起動させる。【選択図】図３
2013156963.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを制御する制御プログラムにおいて、
情報処理装置に、
該情報処理装置の第１のアプリケーションの起動を要求する起動要求を受け付け、
前記起動要求に応じて、前記第１のアプリケーションに対応する第２のアプリケーションを実行する他の情報処理装置のオペレーティングシステムの停止を検出した場合に、前記第１のアプリケーションを起動させる、
ことを実行させることを特徴とする制御プログラム。
【請求項２】
前記制御プログラムはさらに、
前記情報処理装置に、
前記オペレーションシステムの停止を検出できなかった場合、前記オペレーティングシステムを停止させる停止手段に前記オペレーションシステムを停止させてから前記第１のアプリケーションを起動させる
ことを実行させることを特徴とする請求項１記載の制御プログラム。
【請求項３】
前記起動要求は、前記第１のアプリケーションの起動を強制的に起動する旨の情報を含む、
ことを実行させることを特徴とする請求項１または２記載の制御プログラム。
【請求項４】
アプリケーションを制御する制御方法において、
情報処理装置が、
該情報処理装置の第１のアプリケーションの起動を要求する起動要求を受け付け、
前記起動要求に応じて、前記第１のアプリケーションに対応する第２のアプリケーションを実行する他の情報処理装置のオペレーティングシステムの停止を検出した場合、前記第１のアプリケーションを起動させる、
ことを特徴とする制御方法。
【請求項５】
アプリケーションを制御する情報処理装置において、
該情報処理装置の第１のアプリケーションの起動を要求する起動要求を受け付ける受付手段と、
前記第１のアプリケーションに対応する第２のアプリケーションを実行する他の情報処理装置のオペレーティングシステムを監視する監視手段と、
前記起動要求を受け付けた場合、前記オペレーティングシステムが停止しているか否かを前記監視手段に問合わせる問合わせ手段と、
前記オペレーティングシステムの停止を検出した場合、前記第１のアプリケーションを起動させる起動手段と、
を備えたことを特徴とする情報処理装置。
【請求項６】
第１のアプリケーションを実行する第１の情報処理装置と、前記第１のアプリケーションに対応する第２のアプリケーションを実行する第２の情報処理装置と、管理装置を備えた制御システムにおいて、
前記管理装置は、
前記第１のアプリケーションを起動する起動要求を前記第１の情報処理装置に対して送信する起動要求手段を備え、
前記第１の情報処理装置は、
前記起動要求手段からの前記起動要求を受け付ける受付手段と、
前記第２の情報処理装置のオペレーティングシステムの監視を行う監視手段と、
前記起動要求を受け付けた場合、前記オペレーティングシステムが停止しているか否かを前記監視手段に問合わせる問合わせ手段と、
問い合わせの結果、前記オペレーティングシステムの停止を検出できなかった場合、前記オペレーティングシステムの停止を要求する停止要求手段と、
前記停止要求手段からの要求に応じて、前記オペレーティングシステムを停止させる要求を前記第２の情報処理装置に送信する送信手段と、
前記オペレーティングシステムの停止を検出した場合、前記第１のアプリケーションを起動させる起動手段と、
を備え、
前記第２の情報処理装置は、
前記送信手段が送信した要求に応じて、前記オペレーティングシステムを停止させる停止手段と、
前記オペレーティングシステムを停止させた場合、前記オペレーティングシステムの停止を前記第１の情報処理装置に通知する通知手段と、
を備えたことを特徴とする制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、運用、予備システムを有する制御システムに関する。
【背景技術】
【０００２】
従来、情報処理装置を用いてアプリケーションの制御を行うシステムが存在する。従来のシステムにおいては、運用中に稼働させるシステム（運用系、現用系などと呼ばれる。本明細書では以後、運用系と記載する）に、加え、予備のシステム（以下、待機系と記載する）を備えるシステムが存在する。
【０００３】
このようなシステムによれば、稼働中の運用系のアプリケーションに異常が発生した場合、待機系のアプリケーションに切り替えることで、待機系のアプリケーションを用いて運用を継続させることが可能である。
【０００４】
運用系、待機系の情報処理装置は、アプリケーションの起動や停止の制御を行うためのプログラム（以下、管理プロクラムと記載する）を備えており、運用系および待機系で実行されるアプリケーションの動作状態を、互いに確認することが可能である。例えば、運用系のアプリケーションに異常が発生した場合、運用系の管理プログラムは、異常が発生した運用系のアプリケーションを停止させる。一方、運用系のアプリケーションの異常を確認した待機系の管理プログラムは、異常が発生したアプリケーションの予備である待機系のアプリケーションを起動する。このようなアプリケーションの状態の相互監視により、アプリケーションの異常によりシステムが停止してから復旧するまでの時間を削減することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１１９９２
【発明の概要】
【発明が解決しようとする課題】
【０００６】
異常により運用系を停止させて待機系に切り替えた場合、その待機系は新たな運用系となり、停止させた運用系をメンテナンスして正常動作する状態にした後で新たな待機系として運用することがある。このような運用において、新たな待機系とするシステムのメンテナンス中に現在の運用系の管理プログラムに異常が発生し、現在の運用系の管理プログラムが停止すると、アプリケーションの動作状態の相互監視ができないために、現在の運用系のアプリケーションの動作状態は不確かなものとなる。
【０００７】
現在の運用系のアプリケーションの動作状態が不確かな状態で、新たに待機系として設定されたシステムのアプリケーションを起動してしまうと、現在の運用系のアプリケーションとの間で競合が発生する（同時に動作する）恐れがある。運用系のアプリケーションと、待機系のアプリケーションとが同時に動作する状態が生ずると、運用系のアプリケーションと待機系のアプリケーションとが同じデータに対して同時にアクセスすることによるデータ破壊など、システムにとって重大な障害を引き起こす可能性がある。
ここで、運用系の動作状態とは無関係に、運用系全体を強制停止させることで、競合を回避することもできるが、その強制停止によって運用系で動作中の他の正常なアプリケーションも停止させられてしまう。強制停止を避けるためには、アプリケーションの動作状態が確認できるまで待機系のアプリケーションは起動ができない。
【０００８】
以上のように、運用系のアプリケーションの動作状態が不明な場合には、運用系から待機系への切り替えを円滑に行うことができない。
【０００９】
本発明の一側面としては、運用系のアプリケーションの動作状態が不明であっても、当該アプリケーションと競合しないように他のアプリケーションを円滑に起動することを目的とする。
【課題を解決するための手段】
【００１０】
１つの案では、アプリケーションを制御する制御プログラムは、情報処理装置に、該情報処理装置の第１のアプリケーションの起動を要求する起動要求を受け付け、前記起動要求に応じて、前記第１のアプリケーションに対応する第２のアプリケーションを実行する他の情報処理装置のオペレーティングシステムの停止を検出した場合に、前記第１のアプリケーションを起動させる。
【発明の効果】
【００１１】
本発明の一態様によれば、オペレーティングシステム上で動作するアプリケーションの起動状態が不明であっても、当該アプリケーションと競合しないように他のアプリケーションの起動を行うことができる。それにより、アプリケーション間の競合を回避することも可能となる。
【発明を実施するための形態】
【００１２】
本発明を実現する実施例について説明をする。図１は、本実施例の制御システム１００の構成図である。本実施例の制御システムは、情報処理装置としてのノード１０１ａ、１０１ｂを備えている。ノード１０１ａ、１０１ｂは、一方が運用系、他方が待機系となる。ノード１０１ａ、１０１ｂは、例えば、それぞれがアプリケーションを実行するサーバ装置とすることもできる。図１においては、ノードは１０１ａ、１０１ｂの２つであるが、制御システム１００は３つ以上のノードを備えたり、待機系を複数備える態様であってもよい。本実施例においては、２つのノードを備えるものとし、ノード１０１ａが運用系、ノード１０１ｂが待機系とする。
【００１３】
ノード１０１ａ、１０１ｂは、ノード１０１ａが備えるアダプタ２０７ａ、ノード１０１ｂが備えるアダプタ２０７ｂおよびネットワーク１２０によって相互に接続される。また、ノード１０１ａ、ノード１０１ｂは、ノード１０１ａが備えるアダプタ２０８ａ、ノード１０１ｂが備えるアダプタ２０８ｂおよびネットワーク１３０によって接続される。
【００１４】
ノード１０１ａ、１０１ｂは、それぞれ強制停止装置２０４ａ、２０４ｂを備える。強制停止装置２０４ａ、２０４ｂは、それぞれノード１０１ａ、１０１ｂの動作を強制的に停止させることが可能な装置であり、例えば、マネジメントボードと呼ばれる制御装置を用いて実現することが可能である。強制停止装置２０４ａと、２０４ｂとは、ネットワーク１４０を介して接続される。
【００１５】
また、制御システム１００は、ノード１０１ａ、１０１ｂと通信経路１２０によって接続される共有記憶装置１５０を備えても良い。例えば、ノード１０１ａ、１０１ｂが実行するアプリケーションが、データベースの制御を実行する場合、そのデータベースは共有記憶装置１５０に記憶されれば良い。共有記憶装置１５０は、例えば、複数のＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）を備えたストレージ装置とすることもできる。
【００１６】
また、制御システム１００は、図１に示すように、ネットワーク１２０を介してノード１０１ａ、１０１ｂと接続できる管理端末１１０を備えても良い。この場合、例えば、システム管理者が管理端末１１０を用いて、ノード１０１ａ、１０１ｂに対してアプリケーションの実行開始や、停止の要求を行うことが可能である。
【００１７】
図２に、ノード１０１ａの構成図の１例を示す。図２に、ノード１０１ａは、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１ａ、メモリ２０２ａ、ＨＤＤ２０３ａ、強制停止装置２０４ａ、アダプタ２０７ａ、２０８ａを備え、それぞれはバスによって相互に通信可能に接続されている。ＣＰＵ２０１ａは、ノード１０１ａの制御を行う。メモリ２０２ａ、ＨＤＤ２０３ａは、例えば、ノード１０１ａを制御するための情報、ＣＰＵ２０１ａが実行するプログラム、制御システム１００に関する情報を記憶することが可能である。尚、ＨＤＤ２０３ａが、半導体記憶装置などのＨＤＤとは異なる種類の記憶装置であっても構わない。強制停止装置２０４ａは、強制停止装置２０４ａの動作を実現するためのＣＰＵ２０５ａ、メモリ２０６ａを備えており、動作の概要については上述の通りである。アダプタ２０７ａ、２０８ａは、ネットワーク１２０、１３０を介して、例えばノード１０１ａと、１０１ｂとを接続する接続部である。また、制御システム１００が管理端末１１０を有する場合、アダプタ２０７ａ、２０８ａは、ネットワーク１２０、１３０を介して、ノード１０１ａ、１０１ｂを管理端末１１０とも接続する。アダプタ２０７ａ、２０８ａには、例えばＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）を用いることが可能である。また、ノード１０１ａは、図２に示すように、ノード１０１ａに対する命令を実行するための入力装置２０９ａ、ノード１０１ａや制御システム１００の動作状態を出力する出力装置２１０ａを備えても良い。入力装置２０９ａとしては、例えばキーボードやマウスを利用することができる。また、出力装置２１０ａとしては、例えばディスプレイやプリンタを利用することができる。
【００１８】
尚、ノード１０１ｂのハードウェア構成は、ノード１０１ａと基本的に同様のため、説明を省略する。また、上記のネットワーク１２０、１３０、１４０はたとえば物理的に１つの通信回線を用いて実現されるものであっても、それぞれが個別の通信回線を用いるものであっても構わない。
【００１９】
また、管理端末１１０、ノード１０１ａ、１０１ｂを接続するネットワークを新たに設けることも可能である。
〔ソフトウェア構成図〕
図３は、制御システム１００のソフトウェアの構成を示す図である。
【００２０】
ノード１０１ａで実行されるソフトウェアは、例えば、図３に示す、アプリケーション３０１ａ、管理プログラム３０２ａ、ＯＳ監視プログラム３０３ａ、ＯＳ３０４ａ、強制停止機構（強制停止プログラム）３０５ａである。
【００２１】
アプリケーション３０１ａは、ノード１０１ａで実行されるアプリケーションである。管理プログラム３０２ａは、例えばアプリケーション３０１ａの起動や停止の処理、アプリケーション３０１ａの監視を行う。ＯＳ３０４ａは、ノード１０１ａ全体の制御を行う。ＯＳ監視プログラム３０３ａは、自ノードのＯＳ３０４ａと他ノードのＯＳ３０４ｂの実行状態を監視する。強制停止機構３０５ａは、ノード１０１ａを強制的に停止させるための手段である。アプリケーション３０１ａ、管理プログラム３０２ａ、ＯＳ３０４ａ、ＯＳ監視プログラム３０３ａは、例えば、メモリ２０２ａにロードされ、ＣＰＵ２０１ａによって実行されるプログラムである。また、強制停止機構３０５ａは、例えば、強制停止装置２０４ａが、強制停止装置２０４ａのＣＰＵ２０５ａ、メモリ２０６ａを用いて実行されるプログラムであってよい。尚、ノード１０１ｂのソフトウェアの構成はノード１０１ａと同様である。図３においては、ノード１０１ａの３０１ａ〜３０５ａに対応するノード１０１ｂの各部を、３０１ｂ〜３０５ｂと呼ぶこととする。
【００２２】
アプリケーション用通信経路３１０は、アプリケーション３０１ａと３０１ｂとを接続するネットワークである。アプリケーション用通信経路３１０は、例えば図１に示すネットワーク１２０を用いて実現する。ハートビート通信経路３２０は、ノード１０１ａ、１０１ｂが、互いの動作状態に関する情報（例えば、アプリケーションの動作状態を示す情報など）や、命令を送受信する通信経路である。ハートビート通信経路３２０は、例えば図１に示すネットワーク１３０を用いて実現する。強制停止用通信経路３３０は、強制停止装置２０４ａ、２０４ｂを接続するための通信経路である。強制停止用通信経路３３０は、例えば図１に示すネットワーク１４０を用いて実現することが可能である。図１、図２に示すノード１０１ａ、１０１ｂの接続の態様は、制御システム１００の態様の一例である。本発明を実現する上で、図１、図２の態様に限定されない。例えば、ハートビート用通信経路３２０として図１のネットワーク１３０を用い、強制停止用通信経路３３０として図１のネットワーク１４０を用いることで、ネットワーク障害によるリスクを軽減させることが可能である。同様に、管理端末１１０と共有記憶装置１５０には、通信経路１２０とは別の通信経路をそれぞれ用意し、ノード１０１ａ、１０１ｂに個別に接続することが望ましい。
〔アプリケーション起動動作の説明〕
次に、図３、図４を用いて、待機系のアプリケーション３０１ｂを起動する手順について説明する。本手順では、運用系の管理プログラム３０２ａが停止しており、アプリケーション３０１ａの動作状況が不明な場合であっても、アプリケーション３０１ａと、アプリケーション３０１ｂが同時に動作する状態を発生させることなく、アプリケーション３０１ｂを起動させる。図４は、アプリケーション３０１ｂを起動する場合の、制御システム１００の手順を示すフローチャートである。
【００２３】
まず、運用管理者が、アプリケーション３０１ｂの起動を管理プログラム３０２ｂに対して要求する（Ｓ４０１）。この起動の要求（以下、起動要求と記載する）は、例えば、システムの運用管理者が、管理端末１１０や、ノード１０１ｂの入力装置２０９ｂなどを用いて実行する。この起動要求には、アプリケーション３０１ｂの起動の要求に加え、強制起動を要求するか否かの情報も含めることができる。例えば、運用管理者は、アプリケーション３０１ａが機能せず、業務を待機系で再開する場合に、アプリケーション３０１ａの動作状態を確認することなく早急にアプリケーション３０１ｂを起動することを要求する。この場合、運用管理者は、その起動要求時に強制起動も合わせて要求する。起動要求は、例えば、管理端末１１０や、ノード１０１ｂの入力装置２０９ａを用いて入力するコマンドであっても良い。また、管理端末１１０やノード１０１ｂに実装されるＧＵＩ（Ｇｒａｐｈｙｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を用いて、起動要求を発行するようにしても良い。なお、起動要求に対して強制起動の要求を後で行うこともできる。
【００２４】
起動要求を受信した管理プログラム３０２ｂは、アプリケーション３０１ａが動作しているかを判定する（Ｓ４０２）。アプリケーション３０１ａが動作中であるかの判定は、例えば、管理プログラム３０２ｂが、前述のようにハートビート通信経路３２０を介して管理プログラム３０２ａから受信したアプリケーション３０１ａの動作状態を示す情報をメモリ２０２ｂ、あるいはＨＤＤ２０３ｂに記憶し、その記憶した情報に基づいて判定することが可能である。なお、ハートビートを用いた通信は定期的に行うようにしてもよい。
【００２５】
アプリケーション３０１ａの動作状態を示す情報は、例えば、図５に示すアプリケーション情報４００とすることができる。この例では、アプリケーション３０１ａの識別情報（ここでは、３０１ａ）と、アプリケーション３０１ａの動作状態との組とする例を示している。本実施例を実現する上で、アプリケーション情報４００の態様は図５の態様に限定されない。例えば、ノード１０１ａが複数のアプリケーション３０１ａ（１）〜（ｎ）を実行している場合は、図６に示すアプリケーション情報５００のようにアプリケーションごとに動作状態の情報を記憶しても良い。他の方法としては、例えば、起動要求を受けて、管理プログラム３０２ｂが、管理プログラム３０２ａに、ハートビート通信経路３２０を介してアプリケーション３０１ａの動作状態を問い合わせ、その応答内容に基づいて動作状態を確認することとしても良い。なお、図５、図６において、アプリケーションの動作状態として「停止」と記載しているが、アプリケーションが実際に停止していることの情報を得られた場合だけでなく、ハートビートが受信できずに、アプリケーションが動作中であることが確認できないとい場合にもこの動作状態として「停止」が記憶される。
【００２６】
さて、図４の説明に戻ると、アプリケーション３０１ａが動作していると判定した場合、管理プログラム３０２ｂは、アプリケーション３０１ａの停止を管理プロクラム３０２ａに対して要求する（Ｓ４０３）（以下、停止要求と記載する）。停止要求を管理プログラム３０２ｂから受けた管理プログラム３０２ａは、停止要求に応じて、アプリケーション３０１ａを停止させる。アプリケーション３０１ａの停止が完了した後、管理プログラム３０２ａは、管理プログラム３０２ｂに対して、アプリケーション３０１ａが停止した旨の情報を送信する。アプリケーション３０１ａが停止した旨の情報を管理プログラム３０２ｂが受信した場合、管理プログラム３０２ｂはアプリケーション３０１ｂの起動を行う（ステップＳ４０９）。尚、このときに、管理プログラム３０２ｂはアプリケーション３０１ａが停止した旨の情報に基づいてメモリ２０２ｂに記憶したアプリケーション情報４００あるいは５００を更新しても良い。
【００２７】
一方、アプリケーション３０１ａが動作中であると確認できなかった場合（アプリケーションの動作状態が「停止」として記憶されている場合、「異常」として記憶されている場合など）、管理プログラム３０２ｂは、管理プログラム３０２ａが動作中であるかを判定する（Ｓ４０４）。管理プログラム３０２ａが動作中であるかの判定は、例えば、管理プログラム３０２ｂが、管理プログラム３０２ａの動作状態の情報をメモリ２０２ｂ、あるいはＨＤＤ２０３ｂに記憶し、記憶した情報に基づいて動作状態を判定するようにしても良い。図７に示す管理プログラム情報６００は、管理プログラム３０２ａと、管理プログラム３０２ａの動作状態とを関連付けて記憶した情報の一例である。なお、図７において、管理プログラムの動作状態として「停止」と記載しているが、管理プログラムが実際に停止していることの情報をハートビートにより得られた場合だけでなく、ハートビートが受信できずに、管理プログラムが動作中であることが確認できないとい場合にもこの動作状態として「停止」が記憶される。
【００２８】
本実施例を実現する上で、管理プログラム情報６００の態様は図７の態様に限定されない。また、起動要求を受けて、管理プログラム３０２ｂが、管理プログラム３０２ａに、ハートビート通信経路３２０を介して管理プログラム３０２ａの最新の動作状態を問い合わせることでも確認可能である。管理プログラム３０２ａが動作中であると判定した場合、管理プログラム３０２ｂはステップＳ４０３の処理を実行する。
【００２９】
一方、管理プログラム３０２ａが動作中であると判定しなかった場合（管理プログラム３０２ａの動作状態が「停止」と検出された場合、「異常」と検出された場合など）、管理プログラム３０２ｂは、起動要求が強制起動であるかを判定する（Ｓ４０５）。起動要求が強制起動でないと判定した場合、管理プログラム３０２ｂは、起動要求に基づく処理を終了する。この場合は、例えば、管理プログラム３０２ａの起動が確認された後に、ステップＳ４０２から処理を再実行しても良い。
【００３０】
一方、起動要求が強制起動であると判定した場合、管理プログラム３０２ｂは、ＯＳ３０４ａが停止中であるかを確認する（Ｓ４０６）。そのために、管理プログラム３０２ｂは、ＯＳ３０４ａが停止中であるかを確認する要求をＯＳ監視プログラム３０３ｂに対して送信する。要求を受けたＯＳ監視プログラム３０３ｂは、ＯＳ３０４ａが停止中であるかを判定する。ＯＳ３０４ａが停止中であるかの判定は、例えば、図８に示すような、ＯＳ情報７００をメモリ２０２ｂ、あるいはＨＤＤ２０３ｂに記憶し、記憶した情報を管理プログラム３０２ｂが参照して、ＯＳ３０４ａの動作状態を判定するようにしても良い。一例として図８に示すＯＳ情報７００は、ＯＳ３０４ａと、ＯＳ３０４ａの動作状態とを関連付けて記憶した情報である。図８に示すＯＳ情報７００は、ＯＳ３０４ａの動作状態を確認する情報の一形態であり、本発明を実現する上で、ＯＳ情報７００の態様は図８の態様に限定されるものではない。他の方法としては、例えば、起動要求を受けて、ＯＳ監視プログラム３０３ｂがＯＳ監視プログラム３０３ａに、ハートビート通信経路３２０を介してＯＳ３０４ａの動作状態を問い合わせる。そして、その応答内容（停止中か、動作中か、異常か）を、ＯＳ監視プログラム３０３ｂが管理プログラム３０２ｂに通知することで、ＯＳ３０４ａの動作状態を確認するようにしても良い。ＯＳ３０４ａが停止中であることが確認できた場合、管理プログラム３０２ｂはステップＳ４０９の処理を実行する。つまり、管理プログラム３０２ｂは、ＯＳ３０４ａが停止している場合、ノード１０１ａが停止しているため、アプリケーション３０１ａも停止しているとみなすことができる。
【００３１】
一方、ＯＳ３０４ａが停止中であると判定しなかった場合（動作中または異常の場合）、管理プログラム３０２ｂは、ノード１０１ａを強制停止する（Ｓ４０７）。
【００３２】
ここで、Ｓ４０７におけるノード１０１ａを強制停止する手順の１例について詳細に説明する。管理プログラム３０２ｂは、強制停止装置２０４ｂに、ノード１０１ａを強制停止させる旨の要求を送信する。ノード１０１ａを強制停止させる旨の要求を受けた強制停止装置２０４ｂは、強制停止用通信経路３３０を介して、強制停止装置２０４ａに、ノード１０１ａを停止させる旨の要求を送信する。ノード１０１ａを停止させる旨の要求を受けた強制停止装置２０４ａは、ノード１０１ａを停止させる。ノード１０１ａを停止させる方法は、例えば、強制停止装置２０４ａがＯＳ３０４ａにカーネルパニックを発生させることで、ＯＳ３０４ａを停止させ、ノード１０１ａを停止させる方法である。また例えば、強制停止装置２０４ａがノード１０１ａの電源を制御する機能を有し、強制停止させる旨の要求に応じて、ノード１０１ａの電源を停止することにより、ノード１０１ａを停止させても良い。
【００３３】
ノード１０１ａの停止によるＯＳ３０４ａの停止を検知した場合、強制停止装置２０４ａは、ＯＳ３０４ａが停止した旨の情報を、強制停止用通信経路３３０を介して強制停止装置２０４ｂに送信する。ＯＳ３０４ａが停止した旨の情報を受信した強制停止装置２０４ｂは、ＯＳ３０４ａが停止した旨の情報を管理プログラム３０２ｂに送信する。またこのときに、強制停止装置２０４ｂは、ＯＳ３０４ａが停止した旨の情報をＯＳ監視プログラム３０３ｂに送信し、ＯＳ監視プログラム３０３ｂはＯＳ３０４ａが停止した旨の情報に基づいて、ＯＳ情報７００を更新しても良い。また、ＯＳ３０４ａの停止を検知できなかった場合、強制停止装置２０４ａは、強制停止用通信経路３３０を介して、ＯＳ３０４ａが停止できなかった旨の情報を強制停止装置２０４ｂに送信しても良い。
【００３４】
管理プログラム３０２ｂは、ノード１０１ａが停止したかを判定する（Ｓ４０８）。ノード１０１ａが停止したと判定した場合、ステップＳ４０９に進む。ノード１０１ａが停止したと判定した場合とは、例えば、管理プログラム３０２ｂが強制停止装置２０４ｂからＯＳ３０４ａが停止した旨の情報を受信した場合である。
【００３５】
一方、ノード１０１ａが停止したことを検知しなかった場合、管理プログラム３０２ｂは起動要求に基づく処理を終了する。ノード１０１ａの停止を検知しなかった場合とは、例えば、ＯＳ３０４ａが停止できなかった旨の情報を強制停止装置２０４ｂから受信した場合である。または、ステップＳ４０８でノード１０１ａの停止要求を送信してから所定の時間を経過しても、ＯＳ３０４が停止した旨の情報を、管理プログラム３０２ｂが強制停止装置２０４ｂから受信できなかった場合である。この場合、例えば、所定の時間経過後に、管理プログラム３０２ｂは起動要求に基づく処理を再実行しても良い。また、ノード１０１ａの停止を検知できなかった場合、ステップＳ４０６〜Ｓ４０８の処理を所定の回数実行し、それでも尚、ノード１０１ａを停止できない場合に管理プログラム３０２ｂは起動要求に基づく処理を終了しても良い。
【００３６】
ステップＳ４０９では、管理プログラム３０２ｂは、アプリケーション３０１ｂの起動を実行する。ステップＳ４０９を実行する場合、アプリケーション３０１ａが停止しているため、アプリケーション３０１ａと、アプリケーション３０１ｂとが同時に起動する状態は発生しない。アプリケーション３０１ｂの起動を確認した後、管理プログラム３０２ｂは、起動要求に基づく処理を終了する。終了の際に、管理プログラム３０２ｂは、ノード１０１ａ以外のノードに、アプリケーション３０１ｂが起動した旨の情報を、ハートビート通信経路３２０を介して送信しても良い。
【００３７】
以上の手順により、例えば、運用系のノード１０１ａあるいはアプリケーション３０１ａに異常が発生した場合に、待機系のアプリケーション３０１ｂを起動することができる。本実施例によれば、管理プログラム３０２ａが、停止状態や異常状態である場合にもアプリケーション３０１ａと、アプリケーション３０１ｂとが同時に動作する状態を発生させることなくアプリケーション３０１ｂを起動することが可能である。したがって、例えばアプリケーション３０１ａとアプリケーション３０１ｂとが同時に動作し、共有記憶装置１５０に記憶されたデータに対する同時アクセスによって発生するデータ破壊などを抑止することが可能である。また、本実施例によれば、ＯＳ３０４ａが停止中であることを確認できればノード１０１ａを強制停止させない。これは、ＯＳ３０４ａが停止していれば、その上で動作するアプリケーション３０１ａも動作していないことになるからであり、そのような場合にはアプリケーション３０１ｂを起動してもアプリケーション３０１ａとアプリケーション３０１ｂが同時に動作することがないためである。このような処理によって、ノードを強制停止させる機会を低減させ、その強制停止からのシステム復旧に要する作業およびその時間を軽減することができる。
【００３８】
本実施例においては、制御システム１００が、運用系のノード１０１ａと、待機系のノード１０１ｂの２つのノードを備える態様を用いて説明したが、本発明は３つ以上のノードを備える制御システムにおいても実現可能である。例えば、ノード１０１ａと、ｎ個のノード１０１ｂ（１）〜１０１ｂ（ｎ）とを備える制御システムにおいては、図４の各動作ステップにおける、動作状態を示す情報の送受信を、ノード１０１ａが、ノード１０１ｂ（１）〜１０１ｂ（ｎ）のそれぞれに対して実行すれば良い。また、その場合に、ノード１つにつき管理プログラムとＯＳそれぞれが１つずつ備わるならば、ノード１０１ａ、１０１ｂ（１）〜１０１ｂ（ｎ）のそれぞれが、管理プログラム情報６００、ＯＳ情報７００をメモリ２０２ｂ、あるいはＨＤＤ２０３ｂに記憶しても良い。また、例えば図９に示すノード情報８００のような、動作状態を示す情報をメモリ２０２ｂ、あるいはＨＤＤ２０３ｂに記憶しても良い。
【図面の簡単な説明】
【００３９】
【図１】制御システム１００の構成図を示す。
【図２】ノード１０１ａのハードウェア構成図を示す。
【図３】制御システム１００の機能構成図を示す。
【図４】アプリケーション３０１ｂを起動する場合の、手順を示すフローチャートである。
【図５】アプリケーション情報４００を示す。
【図６】アプリケーション情報５００を示す。
【図７】管理プログラム情報６００を示す。
【図８】ＯＳ情報７００を示す。
【図９】ノード情報８００を示す。
【符号の説明】
【００４０】
１００  制御システム
１０１ａ  ノード
１０１ｂ  ノード
１０１ｂ（１）〜（ｎ）  ノード
１１０  管理端末
１２０  ネットワーク
１３０  ネットワーク
１４０  ネットワーク
１５０  共有記憶装置
２０１ａ  ＣＰＵ
２０２ａ  メモリ
２０３ａ  ＨＤＤ
２０４ａ  強制停止装置
２０４ｂ  強制停止装置
２０５ａ  ＣＰＵ
２０６ａ  メモリ
２０７ａ  アダプタ
２０７ｂ  アダプタ
２０８ａ  アダプタ
２０８ｂ  アダプタ
２０９ａ  入力装置
２１０ａ  出力装置
３０１ａ  アプリケーション
３０１ｂ  アプリケーション
３０２ａ  管理プログラム
３０２ｂ  管理プログラム
３０３ａ  ＯＳ監視プログラム
３０３ｂ  ＯＳ監視プログラム
３０４ａ  ＯＳ
３０４ｂ  ＯＳ
３０５ａ  強制停止機構
３０５ｂ  強制停止機構
３１０  アプリケーション用通信経路
３２０  ハートビート通信経路
３３０  強制停止用通信経路
４００  アプリケーション情報
５００  アプリケーション情報
６００  管理プログラム情報
７００  ＯＳ情報
８００  ノード情報
【図１】
2013156963.tif 000003
【図２】
2013156963.tif 000004
【図３】
2013156963.tif 000005
【図４】
2013156963.tif 000006
【図５】
2013156963.tif 000007
【図６】
2013156963.tif 000008
【図７】
2013156963.tif 000009
【図８】
2013156963.tif 000010
【図９】
2013156963.tif 000011