JP4867896B2 - 情報処理システム - Google Patents

Description

本発明は、複数のＯＳが同時に作動する情報処理システムに関する。

近年、複数のＯＳ（オペレーションシステム）を有する情報処理システムについての研究開発、実用化が進められている。

これに関連し、プロセッサ（中央処理装置）からチャネルを介するコンピュータ入出力（Ｉ／Ｏ）システムの制御装置への論理経路の設定に関し、特に、ダイナミックスイッチが１つ以上のチャネルと１つ以上の制御装置の間に配置されるプロセッサ、チャネル及び制御装置の間の論理チャネル経路の設定に関する発明が開示されている（例えば、特許文献１参照）。

当該文献には、マスターオペレーティングシステム（マスターＯＳ）の故障を検出すると直ちに、引き受けの通知を１以上のプロセッサの他の全てのプロセッサに知らせることによって、１以上のプロセッサの内のもう１つのプロセッサの新たなマスターオペレーティングシステムにマスターオペレーティングシステムの責任を引き受けさせ、１以上のプロセッサの他の全てのプロセッサの各々から構成状況を取得することによって、新たなマスターオペレーティングシステムに新たな経路制御テーブルを初期設定させることについて記載されている。

なお、マスターシステムが故障した場合、実行中のいかなる他のシステムも、故障を検出すると直ちにマスターシステムの責任を引き受けるものとしている。
特許第２５６６７２８号公報

しかしながら、上記特許文献１に記載の技術においては、１つのＯＳによる監視結果に基づいてマスターＯＳの故障を検知しているため、監視精度が低くなる可能性がある。

本発明はこのような課題を解決するためのものであり、マスターＯＳの異常を的確に検知すると共に、マスターＯＳの異常時における処理をより適切に行なうことが可能な情報処理システムを提供することを、主たる目的とする。

上記目的を達成するための本発明の一態様は、
複数のＯＳを監視するマスターＯＳを有する情報処理システムであって、
前記複数のＯＳは、それぞれ前記マスターＯＳの動作状況を監視することを特徴とする、情報処理システムである。

この本発明の一態様によれば、複数のＯＳによりマスターＯＳの動作状況が監視されるため、マスターＯＳの異常を的確に検知することができる。また、マスターＯＳの故障時にエラーログを記憶したりユーザーに通知する等の処理を効率的に行なうことができるため、マスターＯＳの異常時における処理をより適切に行なうことができる。

本発明の一態様において、
前記複数のＯＳの全てが前記マスターＯＳの異常を検知した場合に、前記複数のＯＳのうち少なくとも一部が異常時処理を行なうことを特徴とするものとしてもよい。

また、本発明の一態様において、
前記複数のＯＳのうち所定数以上のＯＳが前記マスターＯＳの異常を検知した場合に、前記複数のＯＳのうち少なくとも一部が異常時処理を行なうことを特徴とするものとしてもよい。

また、本発明の一態様において、
前記異常時処理は、前記複数のＯＳのうち少なくとも一部が前記マスターＯＳを代行する処理を含むものとしてもよい。

本発明によれば、マスターＯＳの異常を的確に検知すると共に、マスターＯＳの異常時における処理をより適切に行なうことが可能な情報処理システムを提供することができる。

以下、本発明を実施するための最良の形態について、添付図面を参照しながら実施例を挙げて説明する。

以下、本発明の一実施例に係る情報処理システム１について説明する。

［構成］
図１は、本発明の一実施例に係る情報処理システム１の全体構成の一例を示す図である。情報処理システム１は、主要な構成として、マルチコアプロセッサ１０と、マスターＯＳ２０と、スレーブＯＳ３０Ａ、３０Ｂ…（以下略）と、共有メモリ４０と、異常ログ書き込み用メモリ５０と、を備える。なお、スレーブＯＳは１つであってもよいし、３つ以上であってもよい。以下、必要に応じて「各スレーブＯＳ」等と表記する。

マルチコアプロセッサ１０は、コア０、コア１、…コアｎを有する。各コアは、従来のＣＰＵ（Central Processing Unit）に相当する機能を有する機能単位である。すなわち、ＡＬＵ（論理演算ユニット）や制御装置、レジスタ、クロックジェネレータ等から構成される。マルチコアプロセッサ１０は、単チップとして構成されてもよいし、複数のチップの集合であっても構わない。

マスターＯＳ２０は、各スレーブＯＳの監視を専門に行なうためのＯＳであり、スレーブＯＳの監視を定期的に行なっている。マスターＯＳ２０としては、動作信頼性の比較的高いＯＳが選択される。

各スレーブＯＳは、担当するアプリケーションプログラムの実行を制御する。各スレーブＯＳとしては、例えば汎用的な大規模ＯＳが選択される。また、各スレーブＯＳは、それぞれマスターＯＳ２０の動作状況を監視する。

ここで、情報処理システム１が車載システムに適用された場合について述べる。この場合、各スレーブＯＳは、例えば、ナビゲーション機能を担当するＯＳ、通信処理を担当するＯＳ、携帯連携アプリケーションを担当するＯＳ、画像処理を担当するＯＳ、ユーザーインターフェース（ＧＵＩ；Graphical User Interface、ＶＵＩ；Voice User Interface）を担当するＯＳ等が該当する。このように担当ＯＳを分散することにより、処理速度の向上を図ることができ、一部のＯＳに異常が発生した時でも他のＯＳによる機能を維持させることができる。

共有メモリ４０は、読み書き可能な記憶媒体であれば如何なるものを用いてもよいが、例えば、ＤＲＡＭ（Dynamic Random Access Memory）等を用いることができる。

異常ログ書き込み用メモリ５０は、電源をオフにしても消去されない記憶媒体、例えばＨＤＤ（Hard Disk Drive）が用いられる。なお、異常ログ書き込み用メモリ５０は、共有メモリ４０と同一のハードウエアであっても構わない。

［相互監視処理］
図２は、情報処理システム１において各ＯＳが互いの動作状況を監視し合う様子を概念的に示す図である。以下、本図に即して本実施例の情報処理システム１の特徴的な相互監視について説明する。なお、本図においてアプリケーションプログラムの図示を省略した。

マスターＯＳ２０による各スレーブＯＳの監視（図中、（１）、（３）で示す）は、例えば周知のウォッチドッグシステムを利用して行なう。すなわち、共有メモリ４０その他の記憶媒体に、各スレーブＯＳに対応するＷＤＣ（ウォッチドッグカウンタ；以下略）を設定する。そして、各スレーブＯＳは定期的に（例えば、所定時間毎に）、ＷＤＣに対してインクリメント信号を送出する。

マスターＯＳ２０は定期的にＷＤＣを監視し、各スレーブＯＳの動作状況が正常であるか否かを判定する。すなわち、一定周期を経過してＷＤＣにインクリメント信号を送出しなかったスレーブＯＳがあれば、当該スレーブＯＳがハングアップなどの異常状態であると判定し、当該スレーブＯＳを停止及び再起動、或いは縮退運転を行なう等の処理を行なう。そして、異常状態となったスレーブＯＳに関して、その異常状態となった原因について、収集可能な限りの情報を異常ログ書き込み用メモリ５０に記憶させる。

なお、ウォッチドッグシステムを利用するものに限らず、他の如何なる手法により各スレーブＯＳの動作状況を監視してもよい。例えば、各スレーブＯＳが自己の異常を検知するためのモジュールを備え、ＩＰＩ信号（コア間割り込み信号）やＮＭＩ信号（マスクできない割り込み信号）等のコア間送受信信号の授受により、マスターＯＳ２０に異常発生を通知してもよい。すなわち、各スレーブＯＳを実行しているコアから、マスターＯＳ２０を実行しているコアに上記の信号が送信されることにより、マスターＯＳ２０が各スレーブＯＳが異常状態となったことを認識する。

また、各スレーブＯＳが行なう情報通信量を監視してもよい。すなわち、各スレーブＯＳが通常行なう範囲の、単位時間あたりの情報通信量を逸脱した場合に、当該スレーブＯＳが異常状態であると判定する。異常状態となったスレーブＯＳは、普段の情報通信量に比して極めて大量の情報を入出力したり、情報通信が途絶えたりすることが想定されるからである。

一方、本実施例において、各スレーブＯＳは、それぞれマスターＯＳ２０の動作状況を監視する。各スレーブＯＳによるマスターＯＳ２０の監視（図中、（２）、（４）で示す）は、例えば上記の如くウォッチドッグシステムを利用して行なってもよいし、ＩＰＩ信号（コア間割り込み信号）やＮＭＩ信号（マスクできない割り込み信号）等のコア間送受信信号の授受により、マスターＯＳ２０から各スレーブＯＳに異常発生を通知してもよい。

各スレーブＯＳは、マスターＯＳ２０の異常状態を検知すると、共有メモリ４０に予めスレーブＯＳ毎に設定されている所定アドレスに、マスターＯＳ異常フラグを立てる（図中、（５）、（７）で示す）。自己が立てたフラグに関する情報は、例えばコア内のレジスタ等に保持される。なお、スレーブＯＳ毎に設定されている所定アドレスは、他のスレーブＯＳからの書き込み等が禁止される。

また、各スレーブＯＳは、他のスレーブＯＳがマスターＯＳ異常フラグを立てたか否かを、共有メモリ４０を参照して定期的に監視する（図中、（６）、（８）で示す）。そして、自己がマスターＯＳ異常フラグを既に立てており、且つ他の全てのスレーブＯＳが同様にマスターＯＳ異常フラグを立てていることを検知した場合に、マスターＯＳ２０が異常状態にあると判断し、マスターＯＳの異常時処理を行なう。

なお、必ずしも「自己がマスターＯＳ異常フラグを既に立てており、且つ他の全てのスレーブＯＳが同様にマスターＯＳ異常フラグを立てている場合」にマスターＯＳ２０が異常状態にあると判断する必要はなく、例えば、「自己がマスターＯＳ異常フラグを既に立てており、且つ所定数以上の他のスレーブＯＳがマスターＯＳ異常フラグを立てている」場合にマスターＯＳ２０が異常状態にあると判断してもよい。

係る処理により、単独のＯＳ等による監視結果に基づいてマスターＯＳの故障を検知する場合に比して、監視精度を高めることができる。すなわち、マスターＯＳの異常を的確に検知することができる。

マスターＯＳの異常時処理は、まず、各スレーブＯＳが、マスターＯＳ２０の異常状態となった原因について、収集可能な限りの情報を異常ログ書き込み用メモリ５０に記憶させる（図中、（９）、（１０）で示す）。そして、例えば画像表示やユーザーインターフェースを担当するＯＳによりユーザーに対して異常状態に関する通知がされ、システム全体のシャットダウンが行なわれる。なお、これに限らず、スレーブＯＳのうち一つがマスターＯＳ２０の機能を代行する処理を行なってもよい。

ここで、異常ログ書き込み用メモリ５０は電源をオフにしても消去されない記憶媒体が用いられるため、異常状態となった原因についての情報を書き込むのに在る程度の時間が必要となるのが通常である。反面、前述の如く車載装置に適用された場合、安全面を考慮して、システム全体を速やかにシャットダウンすることが求められる。

これに対し、本実施例の情報処理システム１では、複数のスレーブＯＳにより異常状態となった原因についての情報が書き込まれるため、限られた時間内で多くの情報を残すことができる。また、例えば、ユーザーへの通知を行なうスレーブＯＳは上記の書き込みを行なわない等の役割分担を予め設定しておくことにより、異常状態に関する情報を残しつつ異常時のシャットダウン等を更に効率的に行なうことができる。

従って、マスターＯＳの異常を的確に検知すると共に、マスターＯＳの異常時における処理をより適切に行なうことができる。

以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

例えば、マルチコアプロセッサ１０、共有メモリ４０と、異常ログ書き込み用メモリ５０等のハードウエア構成については、あくまで本発明の機能を実現するための装置の一例であり、如何なる変更も許容される。また、「マスターＯＳ」や「スレーブＯＳ」等の称呼は、あくまで便宜的なものである。

本発明は、自動車製造業や自動車部品製造業等に利用可能である。

本発明の一実施例に係る情報処理システム１の全体構成の一例を示す図である。 情報処理システム１において各ＯＳが互いの動作状況を監視し合う様子を概念的に示す図である。

符号の説明

１ 情報処理システム
１０ マルチコアプロセッサ
２０ マスターＯＳ
３０Ａ、３０Ｂ スレーブＯＳ
４０ 共有メモリ
５０ 異常ログ書き込み用メモリ

Claims (3)

1. 担当するアプリケーションプログラムの実行を制御する複数のＯＳと、
   前記複数のＯＳを監視するマスターＯＳと、
   を有する情報処理システムであって、
   前記複数のＯＳは、それぞれ前記マスターＯＳの動作状況を監視し、該監視の結果、前記マスターＯＳの異常時処理を行う際には、前記複数のＯＳのうち少なくとも一部が前記マスターＯＳの異常状態となった原因について収集可能な情報を不揮発性メモリに格納することを特徴とする、
   情報処理システム。
2. 前記複数のＯＳのうち所定数以上のＯＳが前記マスターＯＳの異常を検知した場合に、前記複数のＯＳのうち少なくとも一部が異常時処理を行なうことを特徴とする、
   請求項１に記載の情報処理システム。
3. 前記異常時処理は、前記複数のＯＳのうち少なくとも一部が前記マスターＯＳを代行する処理を含む、
   請求項１又は２に記載の情報処理システム。

Images