JP5335552B2 - 情報処理装置、その制御方法、及びコンピュータプログラム - Google Patents

Description

本発明は、情報処理装置、その制御方法、及びコンピュータプログラムに関する。

高機能でかつ高速な処理を求められる組み込み機器においては、そのすべての機能を同一のＣＰＵ上で駆動するとシステムが巨大化してしまうため、メンテナンス性やパフォーマンスへ影響が出ることがある。一方で、ＬＳＩの集積化が進み、ワンチップに複数のＣＰＵを搭載することは容易になってきている。したがって、組み込み機器開発において、複数のＣＰＵを備えたチップ上で複数のサブシステムを駆動し、それぞれのサブシステムがシステムで要求される処理を機能ごとに行うシステム開発手法が有用な手法となっている。このような複数のサブシステムを備えるシステムにおいては障害発生時にその障害検出が難しいといわれている。別々のＣＰＵにて駆動するサブシステムは、一方のサブシステムが停止しても他方のサブシステムは動作を続けることが可能なため、一部のサブシステムがダウンしてもシステム全体の障害として発見できないことがあるためである。そこで、サブシステムの障害検出方法として、サブシステム間のコマンド応答の有無で障害の発生を検出する方式が広く取られている。

例えば、特許文献１に記載の技術では、一つサブシステムが別のサブシステムに対してコマンドを発行し、そのコマンドの返答がタイムアウトとなった場合にサブシステムが停止状態であると判断する。特許文献２に記載の技術では、共有メモリを用いてサブシステムの障害検知を行う。サブシステム間の共有メモリ上にカウンタを配置し、一つサブシステムがカウンタを更新することを別のサブシステムが監視し、このカウンタの更新がない場合にサブシステムが停止状態と判断する。

一般に、サブシステムで発生する障害には、ＣＰＵやメモリなどのデバイス不良によるデバイス障害と、サブシステム内部のソフトウェアのバグによるデッドロックなどのシステム動作停止とがある。デバイス障害が発生した場合には、ユーザに通知するなどの対応が必要であるのに対して、システム動作停止が発生した場合には、ソフトウェアのリカバリー処理によって復旧が可能である。そのため、サブシステムにおいてどのような障害が発生したかを、他のサブシステムにおいて検出できることが望ましい。

しかしながら、コマンドを使用して障害を検出する方法では、サブシステム内部でソフトウェアの一部がデッドロックを起こして停止していることを検出することができない。コマンド処理が割り込み処理とタスク処理との複合処理であり、コマンドの失敗がどのレイヤの失敗か判別ができない場合があるからである。また、タスクの一部がデッドロックなどで停止している場合でも、コマンド処理にかかわるタスクが優先的に実行され、コマンドが成功してしまう場合もある。また、既存のカウンタを用いた障害検出方法では、ひとつのカウンタを用いて、そのカウンタの更新を確認することでサブシステム全体の障害検出を行っている。この方法では、サブシステム内部でソフトウェアの一部がデッドロックを起こして停止していることを検出することができない場合がある。カウンタを更新するタスクがデッドロック発生タスクよりも高い優先度で実行されている場合に、デッドロックを起こしたタスクに依存せず正常にカウント処理を行うからである。

特開平５−１８１７６０号公報 特開昭５５−１３８１４９号公報

そこで、本発明は、サブシステムで発生した障害を正確に検出する技術を提供することを目的とする。

上記課題に鑑みて、本発明に係る情報処理装置は、第１のサブシステム及び第２のサブシステムを備える情報処理装置であって、前記第１のサブシステムは、前記第１のサブシステムが実行する処理タスクよりも高い優先度で第１のソフトウェアカウンタを更新する第１の更新手段と、前記処理タスクよりも低い優先度で第２のソフトウェアカウンタを更新する第２の更新手段とを有し、前記第２のサブシステムは、前記第１のソフトウェアカウンタ及び前記第２のソフトウェアカウンタが更新されたか否かを確認する確認手段と、前記第１のソフトウェアカウンタ及び前記第２のソフトウェアカウンタの少なくともいずれかが更新されていない場合に、前記第１のサブシステムにおいて障害が発生したと判定する判定手段とを有することを特徴とする。

本発明により、サブシステムで発生した障害を正確に検出することができる。

実施形態に係る情報処理装置１００の構成の一例を説明するブロック図。 実施形態における通信用サブシステム１１０の動作の一例を説明するフローチャート。 実施形態におけるアプリケーション用サブシステム１２０の動作の一例を説明するフローチャート。 第１の実施形態における正常時の情報処理装置１００におけるシーケンス図の一例。 第１の実施形態におけるソフトウェア障害発生時の情報処理装置１００のシーケンス図の一例。 第１の実施形態におけるハードウェア障害発生時の情報処理装置１００のシーケンス図の一例。 第１の実施形態におけるエラー発生時の情報処理装置１００のシーケンス図の一例。 第２の実施形態における処理正常終了時の情報処理装置１００のシーケンス図の一例。 第２の実施形態における処理エラー終了時の情報処理装置１００のシーケンス図の一例。

添付の図面を参照しつつ、本発明の実施形態について以下に説明する。

＜第１の実施形態＞
本発明は、一般に、複数のサブシステムと、これらのサブシステムで共用されるメモリとを含む情報処理装置に適用できる。本実施形態においては、そのような情報処理装置として、ＴＣＰ／ＩＰ以下の処理を通信用サブシステム１１０で処理し、アプリケーション用サブシステム１２０の処理負担を軽減する情報処理装置１００を扱う。

〔情報処理装置１００の構成図〕
図１を用いて、本実施形態に係る情報処理装置１００の構成について説明する。情報処理装置１００は、通信用サブシステム１１０、アプリケーション用サブシステム１２０、共有メモリ１３０、ユーザ・インタフェース１４１、通信インタフェース１４２、サブシステム間通信回路１４３を備える。図１においては簡略化のために、第１のサブシステムである通信用サブシステム１１０と第２のサブシステムであるアプリケーション用サブシステム１２０とだけを記載しているが、サブシステムの個数は２個以上であってもかまわない。また、本実施形態では、通信用サブシステム１１０の障害をアプリケーション用サブシステム１２０で監視する形態について説明するが、障害の監視は他のサブシステム（不図示）で行われてもよいし、複数のサブシステムの障害が監視されてもよい。

通信用サブシステム１１０は、ＴＣＰ／ＩＰや通信ドライバなどの処理を行い、ＣＰＵ１１１、占有メモリ１１２、実行部１１３を含む。通信用サブシステム１１０は、他のサブシステムから通信処理の要求があった場合に、通信インタフェース１４２を用いて通信機能を提供する。アプリケーション用サブシステム１２０は、ＳＭＢやメール・アプリケーションなどのネットワーク・アプリケーションを実行し、ＣＰＵ１２１、占有メモリ１２２、確認部１２３、および監視部１２４を含む。アプリケーション用サブシステム１２０は、ＴＣＰ／ＩＰ以下の通信処理を通信用サブシステム１１０にオフロードする。共有メモリ１３０は、通信用サブシステム１１０とアプリケーション用サブシステム１２０とで共用されるメモリであり、サブシステムで共有されるコンピュータプログラムやデータ、一時ファイルなどを記憶するＲＡＭやＲＯＭを含む。共有メモリ１３０は、第１のカウンタであるカウンタＨ１３１、第２のカウンタであるカウンタＬ１３２、および第３のカウンタであるカウンタＭ１３３を含む。カウンタＭ１３３は処理タスク１１６によって用いられるが、本実施形態においては使用されない。

ユーザ・インタフェース１４１は、ユーザからの入力の取得やユーザへの結果の出力を行い、例えば、ディスプレイ、キーボード、ポインティングデバイスなどを含む。通信インタフェース１４２は、ネットワーク１６０を介して接続される他の装置１５０とのＴＣＰ／ＩＰのパケット通信を行う。ネットワーク１６０は、有線ＬＡＮ、無線ＬＡＮ、インターネットなど、どのような形態であってもかまわない。サブシステム間通信回路１４３は、サブシステム間の通信機能を提供する。例えば、各サブシステムは、サブシステム間通信回路１４３を用いて双方向にイベント情報などを通知する。

通信用サブシステム１１０についてさらに詳細に説明する。ＣＰＵ１１１は、通信用サブシステム１１０が占有して使用するＣＰＵであり、通信用サブシステム１１０全体の制御を司る。占有メモリ１１２は、通信用サブシステム１１０が占有して使用するメモリであり、通信用サブシステム１１０のみが用いるコンピュータプログラムやデータなどを記憶するＲＡＭやＲＯＭを含む。実行部１１３は、第１のカウンタ・タスクであるカウンタ・タスクＨ１１４、第２のカウンタ・タスクであるカウンタ・タスクＬ１１５、および所定の処理を実行する処理タスク１１６を実行する。カウンタ・タスクＨ１１４は、カウンタＨ１３１を更新する第１の更新処理を実行する。カウンタ・タスクＬ１１５は、カウンタＬ１３２を更新する第２の更新処理を実行する。カウンタの更新は、通常はカウント値を順次増加させるが、カウンタが更新されたことを認識できればどのようなものであってもかまわない。処理タスク１１６は、通信用サブシステム１１０で処理されるＴＣＰ／ＩＰに関する処理、例えば通信インタフェース１４２に対する送信命令などを行う。処理タスク１１６は複数存在してもよい。

実行部１１３は、カウンタ・タスクＨ１１４とカウンタ・タスクＬ１１５とをそれぞれ定期的に起動する。例えば、実行部１１３は、システム・クロックが一定期間経過するごとにこれらのカウンタ・タスクを起動する。実行部１１３は、起動されたタスクを優先度に従って実行する。実行部１１３は、あるタスクを実行中に、実行中のタスクよりも優先度が高いタスクが起動された場合に、当該起動されたタスクに実行権を移して処理を実行する。この場合に、もともと実行中であったタスクは処理が中断される。一方、実行部１１３は、あるタスクの実行中に、実行中のタスクよりも優先度が低いタスクが起動された場合に、当該起動されたタスクには実行権を移さずに、実行中のタスクの処理を継続する。この場合に、起動されたタスクは実行中のタスクの処理が終了するまで待ち状態となる。実行中のタスクの終了後に起動されたタスクは実行される。カウンタ・タスクＨ１１４は、処理タスク１１６よりも高い優先度を有し、カウンタ・タスクＬ１１５は、処理タスク１１６よりも低い優先度を有する。例えば、カウンタ・タスクＨ１１４に通信用サブシステム１１０内のタスクの最高の優先度を設定し、カウンタ・タスクＬ１１５に通信用サブシステム１１０内のタスクの最低の優先度を設定する。

アプリケーション用サブシステム１２０についてさらに詳細に説明する。ＣＰＵ１２１は、アプリケーション用サブシステム１２０が占有して使用するＣＰＵであり、アプリケーション用サブシステム１２０全体の制御を司る。占有メモリ１２２は、アプリケーション用サブシステム１２０が占有して使用するメモリであり、アプリケーション用サブシステム１２０のみが用いるコンピュータプログラムやデータなどを記憶するＲＡＭやＲＯＭを含む。確認部１２３は、共有メモリ１３０のカウンタが更新されているか否かを定期的に確認する。監視部１２４は、確認部１２３の確認結果に基づいて、通信用サブシステム１１０の障害を検知する。これについての詳細は後述する。

〔通信用サブシステム１１０の動作〕
図２のフローチャートを用いて通信用サブシステム１１０の動作について説明する。このフローチャートは、コンピュータで読み取り可能な記録媒体である占有メモリ１１２に記憶されたコンピュータプログラムをＣＰＵ１１１が実行することにより処理される。

Ｓ２０１で、実行部１１３は、処理タスク１１６の実行が指示されたか否かを判定する。実行が指示されていない場合（Ｓ２０１において「ＮＯ」）に、処理はＳ２０１を繰り返し、実行部１１３は処理タスク１１６の実行が指示されるのを待つ。実行が指示された場合（Ｓ２０１において「ＹＥＳ」）に、Ｓ２０２で、実行部１１３は指示された処理タスク１１６を起動して、実行を開始する。

Ｓ２０３で、実行部１１３は、カウンタ・タスクＨ１１４を起動するタイミングであるか否かを判定する。起動するタイミングである場合（Ｓ２０３において「ＹＥＳ」）に処理はＳ２０４に移行し、起動するタイミングでない場合（Ｓ２０３において「ＮＯ」）には処理はＳ２０５に移行する。Ｓ２０４で、実行部１１３は、カウンタ・タスクＨ１１４を起動する。カウンタ・タスクＨ１１４は処理タスク１１６よりも高い優先度を有するため、たとえ処理タスク１１６が実行中であったとしても、直ちに実行され、カウンタＨ１３１が更新される。

Ｓ２０５で、実行部１１３は、カウンタ・タスクＬ１１５を起動するタイミングであるか否かを判定する。起動するタイミングでない場合（Ｓ２０５において「ＮＯ」）に、処理はＳ２０３に戻る。起動するタイミングである場合（Ｓ２０５において「ＹＥＳ」）に、実行部１１３はカウンタ・タスクＬ１１５を起動し、処理はＳ２０６に移行する。
Ｓ２０６で、実行部１１３は、処理タスク１１６が実行中であるか否かを判定する。実行中である場合（Ｓ２０６において「ＹＥＳ」）は、処理タスク１１６よりも優先度が低いカウンタ・タスクＬ１１５は実行されずに待ち状態となる。そこで、処理はＳ２０３に戻り、カウンタ・タスクＨ１１４の更新タイミングであるか否かを判定する。実行中でない場合（Ｓ２０６において「ＮＯ」）は、カウンタ・タスクＬ１１５が実行され、カウンタＬ１３２が更新される。その後、処理はＳ２０１に戻り、新たな処理タスク１１６の実行が指示されるのを待つ。なお、Ｓ２０５において、すでに起動されているカウンタ・タスクＬ１１５が存在する場合には、新たなカウンタ・タスクＬ１１５を起動しなくてもよい。

以上のように、処理タスク１１６が実行中か否かに関わらず、通信用サブシステム１１０がタスクを実行可能な状態であれば、カウンタ・タスクＨ１１４によりカウンタＨ１３１が必ず更新される。一方、処理タスク１１６が実行中の場合には、カウンタ・タスクＬ１１５は実行されず、カウンタＬ１３２は更新されない。

〔アプリケーション用サブシステム１２０の動作〕
図３のフローチャートを用いてアプリケーション用サブシステム１２０の動作について説明する。このフローチャートは、コンピュータで読み取り可能な記録媒体である占有メモリ１２２に記憶されたコンピュータプログラムをＣＰＵ１２１が実行することにより処理される。簡略化のために通信用サブシステム１１０の監視に関連する動作のみを説明する。

Ｓ３０１で、確認部１２３は、カウンタＬ１３２を確認するタイミングであるか否かを判定する。確認するタイミングでない場合（Ｓ３０１において「ＮＯ」）に、処理はＳ３０１を繰り返す。確認するタイミングである場合（Ｓ３０１において「ＹＥＳ」）に、Ｓ３０２で、確認部１２３はカウンタＬ１３２が更新されているか否かを確認する。カウンタＬ１３２が更新されている場合（Ｓ３０２において「ＹＥＳ」）に、処理はＳ３０１に戻る。カウンタＬ１３２が更新されていない場合（Ｓ３０２において「ＮＯ」）に、Ｓ３０３で、確認部１２３はカウンタＨ１３１が更新されているか否かを確認する。カウンタＨ１３１が更新されている場合（Ｓ３０３において「ＹＥＳ」）に処理はＳ３０４に移行し、カウンタＨ１３１が更新されていない場合（Ｓ３０３において「ＮＯ」）に処理はＳ３０５に移行する。

Ｓ３０４で、監視部１２４は、通信用サブシステム１１０においてソフトウェア障害が発生していることを検出する。ここで、ソフトウェア障害とは、処理タスク１１６において発生し得るデッドロックや無限ループのような、サブシステムにおける実行権を不当に占有する状態をいう。ソフトウェア障害が発生している場合には、障害が修復されるまでの間は、障害の発生している処理タスク１１６よりも優先度が同じか低いタスクは一切実行されない。したがって、カウンタＨ１３１が更新されているがカウンタＬ１３２が更新されていない場合に、監視部１２４は通信用サブシステム１１０においてソフトウェア障害が発生していると判定する。

一方、Ｓ３０５で、監視部１２４は、通信用サブシステム１１０においてハードウェア障害が発生していることを検出する。ここで、ハードウェア障害とは、ＣＰＵ障害やメモリ障害のようなデバイス障害により、サブシステムにおいてタスクを一切実行できない例外状態をいう。カウンタ・タスクＨ１１４は処理タスク１１６よりも高い優先度を有するため、たとえサブシステムにおいてソフトウェア障害が発生している場合であっても、カウンタ・タスクＨ１１４は必ず実行される。したがって、カウンタＨ１３１が更新されていない場合に、監視部１２４は通信用サブシステム１１０においてハードウェア障害が発生していると判定する。

なお、カウンタＬ１３２が更新されている場合にはカウンタＨ１３１も必ず更新されているため、確認部１２３はカウンタＬ１３２だけを定期的に確認すればよい。また、確認部１２３は、カウンタを複数回確認しても更新されていない場合に、カウンタが更新されていないと判定してもよい。

〔正常時の情報処理装置１００のシーケンス〕
図４のシーケンス図を用いて正常時の情報処理装置１００全体の動作について説明する。処理タスク１１６は、通信用サブシステム１１０が他の装置１５０への伝送処理を行う処理であるとする。処理タスク１１６の処理は、以下の実施例においても同様とする。

Ｓ４０１で、実行部１１３は処理タスク１１６を開始する。Ｓ４０２で、実行部１１３はカウンタ・タスクＨ１１４を起動する。カウンタ・タスクＨ１１４は処理タスク１１６よりも優先度が高いため、実行権がカウンタ・タスクＨ１１４に移り、処理タスク１１６の処理は中断され、Ｓ４０３でカウンタＨ１３１が更新される。Ｓ４０４で、実行部１１３は処理タスク１１６の処理を再開する。Ｓ４０５で、実行部１１３はカウンタ・タスクＬ１１５を起動するが、これよりも優先度の高い処理タスク１１６が実行中であるため、カウンタ・タスクＬ１１５はすぐには実行されずに待ち状態となる。処理タスク１１６は、通信インタフェース１４２に伝送処理命令を発行し、Ｓ４０６で通信インタフェースは伝送処理を行う。処理タスク１１６の処理が終了した後に、Ｓ４０７で、実行権がカウンタ・タスクＬ１１５に移り、実行部１１３はカウンタ・タスクＬ１１５を実行してカウンタＬ１３２を更新する。Ｓ４０８で、確認部１２３はカウンタＬ１３２が更新されているか否かを判定する。カウンタＬ１３２が更新されている場合には、当然ながらカウンタＨ１３１も更新されているため、確認部１２３はカウンタＨ１３１の更新を確認する必要はない。この場合には、監視部１２４は、通信用サブシステム１１０に障害が発生していないと判定する。

〔ソフトウェア障害発生時の情報処理装置１００のシーケンス〕
図５のシーケンス図を用いてソフトウェア障害発生時の情報処理装置１００全体の動作について説明する。Ｓ５０１で、実行部１１３は処理タスク１１６を開始する。Ｓ５０２で、処理タスク１１６でデッドロックが発生したとする。この場合、デッドロックが解消されるまでは、実行中の処理タスク１１６より同じか低い優先度を有する処理タスク１１６には実行権は移らないため、これらの処理が実行されることはない。Ｓ５０３で、実行部１１３はカウンタ・タスクＨ１１４を起動する。カウンタ・タスクＨ１１４は処理タスク１１６よりも優先度が高いため、デッドロックが発生している場合でも、実行権がカウンタ・タスクＨ１１４に移り、処理タスク１１６の処理は中断され、Ｓ５０４でカウンタＨ１３１が更新される。Ｓ５０５で、実行部１１３は処理タスク１１６の処理を再開する。Ｓ５０６で、実行部１１３はカウンタ・タスクＬ１１５を起動するが、これよりも優先度の高い処理タスク１１６が実行中であるため、カウンタ・タスクＬ１１５はすぐには実行されずに待ち状態となる。カウンタ・タスクＬ１１５はデッドロックが解消されるまでは実行されない。

Ｓ５０７で、確認部１２３はカウンタＬ１３２が更新されているか否かを判定する。カウンタＬ１３２が更新されていないため、Ｓ５０８で、確認部１２３はカウンタＨ１３１が更新されているか否かを確認する。カウンタＨ１３１は更新されているため、監視部１２４は、通信用サブシステム１１０においてソフトウェア障害が発生したと判定する。そこで、Ｓ５０９で、監視部１２４は通信用サブシステム１１０に対して、デッドロックのリカバリー処理を行う。デッドロックのリカバリー処理として、ソフトウェアの再起動を行う。デッドロックが解消された処理タスク１１６は処理を継続し、Ｓ５１０で通信インタフェース１４２は伝送処理を行う。処理タスク１１６の処理が終了した後に、Ｓ４０７で、実行権がカウンタ・タスクＬ１１５に移り、実行部１１３はカウンタ・タスクＬ１１５を実行してカウンタＬ１３２を更新する。

〔ハードウェア障害発生時の情報処理装置１００のシーケンス〕
図６のシーケンス図を用いてハードウェア障害発生時の情報処理装置１００全体の動作について説明する。

Ｓ６０１で、実行部１１３は処理タスク１１６を開始する。Ｓ６０２で、通信用サブシステム１１０のＣＰＵ１１１がＣＰＵ障害を発生したとする。したがって、ＣＰＵ障害が解消されるまでの間は、通信用サブシステム１１０に含まれるタスクのすべてが実行されない。Ｓ６０３で、確認部１２３はカウンタＬ１３２が更新されているか否かを確認する。カウンタＬ１３２は更新されていないため、Ｓ６０４で、確認部１２３はカウンタＨ１３１が更新されているか否かを確認する。カウンタＨ１３１も更新されていないため、監視部１２４は通信用サブシステム１１０でハードウェア障害が発生したと判定する。そこで、Ｓ６０５で、監視部１２４は、ユーザ・インタフェース１４１に対して障害通知命令を発行する。そして、Ｓ６０６で、ユーザ・インタフェースは情報処理装置１００のユーザに対して通信用サブシステム１１０においてハードウェア障害が発生したことを通知する。

〔エラー発生時の情報処理装置１００のシーケンス〕
図７のシーケンス図を用いてエラー発生時の情報処理装置１００の動作について説明する。図４を用いて上述したシーケンスと同様の処理は同一の参照符号を付して説明を省略する。Ｓ７０１で、通信インタフェース１４２において、エラーが発生したとする。そのため、Ｓ７０２で、通信インタフェース１４２は監視部１２４に対してイベント・エラー通知を行う。Ｓ７０３で、監視部１２４は、カウンタＬ１３２が更新されていることから通信用サブシステム１１０において障害は発生していないと判定し、通常のイベント・エラーに対するリカバリー処理を行う。

以上のように、本実施形態によれば、アプリケーション用サブシステム１２０は、通信用サブシステム１１０で発生した障害を正確に検出することが出来る。さらに、発生した障害の種類が、ソフトウェア障害であるのかハードウェア障害であるのかも合わせて検出することが可能となる。したがって、発生した障害の種類に応じた（適した）対応（リカバリー処理、ユーザ通知）を行うことができる。

＜第２の実施形態＞
本実施形態は、第１の実施形態で説明した情報処理装置１００において、処理タスク１１６もカウンタを更新する場合について説明する。本実施形態における情報処理装置１００の構成図は第１の実施形態で用いた図１と同様であるため、説明を省略する。ただし、本実施形態では、第１の実施形態で用いなかったカウンタＭ１３３を用いる。処理タスク１１６は、自己の処理が正常に終了した場合に、カウンタＭ１３３を更新する第３の更新処理を実行する。確認部１２３はさらに、カウンタＭ１３３が更新されているか否かを確認する。通信用サブシステム１１０およびアプリケーション用サブシステム１２０の動作は第１の実施形態と同様のため、フローチャートによる説明は省略し、異なる部分のみを以下にシーケンス図を用いて説明する。

〔処理正常終了時の情報処理装置１００のシーケンス〕
図８のシーケンス図を用いて処理正常終了時の情報処理装置１００の動作について説明する。図４を用いて上述したシーケンスと同様の処理は同一の参照符号を付して説明を省略する。Ｓ８０１で、処理が再開された処理タスク１１６は、処理が正常に終了した場合に、カウンタＭ１３３を更新する。Ｓ８０２で、確認部１２３は、カウンタＭ１３３が更新されているか否かを確認する。この場合はカウンタＭ１３３が更新されているため、監視部１２４は処理タスク１１６が正常に終了したと判定する。なお、確認部１２３は、カウンタＭ１３３が更新されているか否かを確認するために、処理タスク１１６が開始される前のカウンタＭ１３３のカウント値を確認しておく。

〔処理エラー終了時の情報処理装置１００におけるシーケンス〕
図９のシーケンス図を用いて処理エラー終了時の情報処理装置１００の動作について説明する。図４を用いて上述したシーケンスと同様の処理は同一の参照符号を付して説明を省略する。Ｓ９０１で、処理が再開された処理タスク１１６は、エラーにより処理が終了したとする。この場合、カウンタＭ１３３は更新されない。Ｓ９０２で、確認部１２３は、カウンタＭ１３３が更新されているか否かを確認する。この場合はカウンタＭ１３３が更新されていないため、監視部１２４は処理タスク１１６が正常に終了していないと判定する。さらに、カウンタＬ１３２は更新されているため、監視部１２４は、通信用サブシステム１１０において障害は発生していないと判定する。そこで、Ｓ９０３で、監視部１２４は、処理タスク１１６がエラーにより処理が終了したと判定して、エラー回復処理を実行する。

以上のように、本実施形態によれば、アプリケーション用サブシステム１２０は、通信用サブシステム１１０で発生したエラーを検出することが出来る。
さらに、アプリケーション用サブシステム１２０は、そのエラーがソフトウェア障害によって発生したものであるか否かを判定することが出来る。

＜第３の実施形態＞
本実施形態は、第１の実施形態で説明した情報処理装置１００において、複数の処理タスク１１６がそれぞれのカウンタを更新する場合について説明する。本実施形態における情報処理装置１００の構成図は第１の実施形態で用いた図１と同様であるため、説明を省略する。

本実施形態では、通信用サブシステム１１０は複数の処理タスク１１６を有し、これらの処理タスク１１６は種々の優先度を有する。さらに、共有メモリ１３０は、処理タスク１１６ごとに対応するカウンタを有する。つまり、共有メモリ１３０はタスク別カウンタを有する。処理タスク１１６は、処理が終了した場合に、関連付けられたタスク別カウンタを更新する。ここで、処理は正常に終了していても、エラーで終了していても、処理タスク１１６はタスク別カウンタを更新する。さらに、確認部１２３はさらに、タスク別カウンタが更新されているか否かを確認する。

確認部１２３が更新されていないタスク別カウンタを確認したとする。その場合に、監視部１２４は、更新されていないタスク別カウンタの優先度を確認する。監視部１２４は、更新されていないタスク別カウンタの優先度のうちで、最も優先度の高い処理タスク１１６でソフトウェア障害が発生していると判定する。なぜなら、ある優先度の処理タスク１１６でソフトウェア障害が発生した場合は、その優先度以下の処理タスク１１６には実行権が移らずに、それらのタスク別カウンタも更新されないからである。

以上のように、本実施形態によれば、アプリケーション用サブシステム１２０は、通信用サブシステムでソフトウェア障害が発生した場合に、どの優先度の処理タスク１１６でソフトウェア障害が発生したかを特定することが可能となる。

Claims (11)

1. 第１のサブシステム及び第２のサブシステムを備える情報処理装置であって、
   前記第１のサブシステムは、
   前記第１のサブシステムが実行する処理タスクよりも高い優先度で第１のソフトウェアカウンタを更新する第１の更新手段と、
   前記処理タスクよりも低い優先度で第２のソフトウェアカウンタを更新する第２の更新手段とを有し、
   前記第２のサブシステムは、
   前記第１のソフトウェアカウンタ及び前記第２のソフトウェアカウンタが更新されたか否かを確認する確認手段と、
   前記第１のソフトウェアカウンタ及び前記第２のソフトウェアカウンタの少なくともいずれかが更新されていない場合に、前記第１のサブシステムにおいて障害が発生したと判定する判定手段と
   を有することを特徴とする情報処理装置。
2. 前記判定手段は、前記第１のソフトウェアカウンタが更新されたが前記第２のソフトウェアカウンタが更新されていない場合に、前記第１のサブシステムにおいてソフトウェア障害が発生したと判定することを特徴とする請求項１に記載の情報処理装置。
3. 前記ソフトウェア障害は、前記第１のサブシステムで実行中の処理タスクで発生したデッドロックと無限ループとの少なくともいずれかを含むことを特徴とする請求項２に記載の情報処理装置。
4. 前記判定手段は、前記第１のソフトウェアカウンタが更新されていない場合に、前記第１のサブシステムにおいてハードウェア障害が発生したと判定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記ハードウェア障害は、前記第１のサブシステムで発生したＣＰＵ障害とメモリ障害との少なくともいずれかを含むことを特徴とする請求項４に記載の情報処理装置。
6. 前記判定手段は、前記第２のソフトウェアカウンタが更新された場合に、前記第１のサブシステムにおいてソフトウェア障害とハードウェア障害とのいずれも発生していないと判定することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記第１のソフトウェアカウンタ及び前記第２のソフトウェアカウンタは、前記第１のサブシステム及び前記第２のサブシステムで共有されるメモリが有することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記情報処理装置は、第３のソフトウェアカウンタをさらに有し、
   前記第１のサブシステムは、前記処理タスクが正常に終了した場合に前記第３のソフトウェアカウンタを更新する第３の更新手段を有し、
   前記確認手段は、前記第３のソフトウェアカウンタが更新されたか否かを確認し、
   前記判定手段は、前記第３のソフトウェアカウンタが更新されていないと判定された場合に、前記処理タスクが正常に終了しなかったと判定する
   ことを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 前記処理タスクは、異なる優先度を有する複数の処理タスクを含み、
   前記情報処理装置は、前記複数の処理タスクのそれぞれに対応するタスク別ソフトウェアカウンタをさらに有し、
   前記複数の処理タスクのそれぞれは、処理が終了した場合に前記対応するタスク別ソフトウェアカウンタを更新し、
   前記確認手段は、前記タスク別ソフトウェアカウンタが更新されたか否かを確認し、
   前記判定手段は、前記タスク別ソフトウェアカウンタが更新されていない場合に、更新されていない前記タスク別ソフトウェアカウンタに基づいて、ソフトウェア障害が発生した処理タスクの優先度を特定することを特徴とする請求項１乃至８のいずれか１項に記載の情報処理装置。
10. 第１のサブシステム及び第２のサブシステムを備える情報処理装置の制御方法であって、
    前記第１のサブシステムは、
    処理タスクを実行する工程と、
    前記処理タスクよりも高い優先度で第１のソフトウェアカウンタを更新する第１の更新工程と、
    前記処理タスクよりも低い優先度で第２のソフトウェアカウンタを更新する第２の更新工程とを実行し、
    前記第２のサブシステムは、
    前記第１のソフトウェアカウンタ及び前記第２のソフトウェアカウンタが更新されたか否かを判定する工程と、
    前記第１のソフトウェアカウンタ及び前記第２のソフトウェアカウンタの少なくともいずれかが更新されていない場合に、前記第１のサブシステムにおいて障害が発生したと判定する工程とを実行することを特徴とする制御方法。
11. コンピュータを請求項１乃至９のいずれか１項に記載の情報処理装置の各手段として機能させるためのコンピュータプログラム。

Images