JP2008305317A - マルチプロセッサシステム及びその制御方法 - Google Patents

Abstract

【課題】本発明は、担当すべき制御がそれぞれに割り当てられた複数のプロセッサにおいて特定のプロセッサに異常が発生しても、特定のプロセッサに割り当てられた制御を継続的に処理することができる、マルチプロセッサシステムの提供を目的とする。
【解決手段】担当すべき制御がそれぞれに割り当てられた複数のプロセッサコア０，１，２，３を有する、マルチプロセッサシステムであって、プロセッサコア１，２，３より優先度の高い制御が割り当てられたプロセッサコア０で発生した異常を検出する監視プロセッサ２０を備え、プロセッサコア０以外のプロセッサコア１，２，３のいずれかに、監視プロセッサ２０によって異常が検出されたプロセッサコア０に割り当てられていた制御を代替させることを特徴とする、マルチプロセッサシステム。
【選択図】図１

Description

本発明は、担当すべき制御がそれぞれに割り当てられた複数のプロセッサを有する、マルチプロセッサシステム及びその制御方法に関する。

従来技術として、複数のプロセッサで構成するマルチプロセッサシステムが知られている（例えば、特許文献１参照）。特許文献１に開示のマルチプロセッサシステムは、プログラムを実行して情報処理を行う通常モードと当該通常モードに指定されたプロセッサと同一のプログラムを実行して当該通常モードに指定されたプロセッサの実行状態と自身の実行状態とを比較し両者が不一致のときに異常信号を発生する監視モードとをそれぞれが有する３つ以上のプロセッサを備えるものである。そして、これらプロセッサの中の一つが前記通常モードに指定され、残りの複数のプロセッサのそれぞれが前記監視モードに指定されている。前記監視モードに指定されたプロセッサの夫々が前記異常信号を発生したときは、前記通常モードに指定されたプロセッサをシステムから切り離し、前記監視モードに指定された複数のプロセッサの一つを前記通常モードに残りを前記監視モードにそれぞれ指定して、システムを再構築するものである。一方、前記監視モードに指定されたプロセッサの一つが前記異常信号を発生したときは、当該プロセッサをシステムから切り離し、残りのプロセッサをそれぞれのモードに指定して、システムを再起動するものである。
特公平６−３００６９号公報

しかしながら、通常モードに指定されたプロセッサと監視モードに指定されたプロセッサとは互いに同一のプログラムを実行する必要がある上述の従来技術では、プロセッサ毎に担当すべき制御が割り当てられたマルチプロセッサシステムの場合、同一のプログラムを必ずしも実行させることはできないため、当該システムのプロセッサの異常発生に対しては対処することができない。また、上述の従来技術では、例えば他の制御に比べ重要な制御が割り当てられたプロセッサに異常が発生した場合、その重要な制御に係るプロセッサが切り離されないようにする何らかの対策が必要である。

そこで、本発明は、担当すべき制御がそれぞれに割り当てられた複数のプロセッサにおいて特定のプロセッサに異常が発生しても、特定のプロセッサに割り当てられた制御を継続的に処理することができる、マルチプロセッサシステム及びその制御方法の提供を目的とする。

上記目的を達成するため、第１の発明は、
担当すべき制御がそれぞれに割り当てられた複数のプロセッサを有する、マルチプロセッサシステムであって、
前記複数のプロセッサのうち特定のプロセッサで発生した異常を検出する異常検出手段と、
前記異常検出手段の検出結果に基づいて、前記複数のプロセッサのうち前記特定のプロセッサ以外の他のプロセッサのいずれかに、前記特定のプロセッサに割り当てられた特定制御を代替させる指令手段とを備えることを特徴とする。

第２の発明は、第１の発明に係るマルチプロセッサシステムであって、
前記特定のプロセッサのハードウェアの異常の有無を診断する異常診断手段を備え、
前記異常診断手段の診断結果に基づいて、前記指令手段により前記特定制御に代替したプロセッサに前記特定制御の代替がされる前に割り当てられていた制御が、前記特定のプロセッサに割り当てられるか否かが判断されることを特徴とする。

第３の発明は、第１又は第２の発明に係るマルチプロセッサシステムであって、
前記指令手段は、規定の優先順位に従って、前記特定制御を代替させるプロセッサを決定することを特徴とする。

第４の発明は、第１から第３のいずれかの発明に係るマルチプロセッサシステムであって、前記指令手段は、ＯＳとそのＯＳ上で動作するアプリケーションプログラムを代替させることを特徴とする。

第５の発明は、第１から第４のいずれかの発明に係るマルチプロセッサシステムであって、前記複数のプロセッサは、マルチコアプロセッサ内のプロセッサコアであることを特徴とする。

また、上記目標を達成するため、第６の発明は、
担当すべき制御がそれぞれに割り当てられた複数のプロセッサを有するマルチプロセッサシステムの制御方法であって、
前記複数のプロセッサのうち特定のプロセッサで発生した異常を検出する異常検出ステップと、
前記異常が検出された場合、前記複数のプロセッサのうち前記特定のプロセッサ以外の他のプロセッサのいずれかに、前記特定のプロセッサに割り当てられた特定制御を代替する代替ステップとを備えることを特徴とする。

第７の発明は、第６の発明に係るマルチプロセッサシステムの制御方法であって、
前記特定のプロセッサのハードウェアの異常の有無を診断する異常診断ステップと、
前記ハードウェアの異常がないと診断された場合、前記特定制御に代替したプロセッサが前記特定制御に代替する前に割り当てられていた制御を前記特定のプロセッサに割り当てる割り当てステップとを備えることを特徴とする。

本発明によれば、担当すべき制御がそれぞれに割り当てられた複数のプロセッサにおいて特定のプロセッサに異常が発生しても、特定のプロセッサに割り当てられた制御を継続的に処理することができる。

以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。図１は、本発明に係るマルチプロセッサシステムの一実施形態であるマルチコアシステム１００の概略構成図である。マルチコアシステム１００は、プロセッサコアを複数有するマルチコアプロセッサ１０を有している。マルチコアプロセッサ１０は、例えば図１に示されるように、プロセッサコア０，１，２，３の４つのプロセッサコアを内蔵する。コア０，１，２，３のそれぞれによって、互いに独立に又は連携して、ＯＳ（Operating System）やそのＯＳ上で動作するアプリケーションプログラムなどのプログラムが処理される。コア０，１，２，３のそれぞれは、プログラムの実行を指示する割り込みが発生すると、そのプログラムをＲＯＭやハードディスクなどの記憶媒体からＲＡＭなどの作業領域に読み込んで実行する。

各コアには、担当すべき制御がそれぞれに割り当てられている。また、各コアが担当する制御にはそれぞれ優先度が付与されている。一番高い優先度の制御（最優先度制御）が少なくとも一つのコアに割り当てられ、最優先度制御より低い優先度の制御がそれ以外のコアに割り当てられている。例えば、マルチコアシステム１００が車両用システムとして適用される場合、コア０には一番優先度の高い制御として「車両制御」が割り当てられ、コア１，２，３には車両制御より優先度の低い制御として「情報制御」が割り当てられる。もちろん、コア１，２，３に割り当てられる情報制御のそれぞれにも優先度が付与されてよい。

車両制御とは、例えば動く／曲がる／止まるなどといった車両の基本動作機能を制御する主制御又はその主制御に関連する補助制御である。より具体的な車両制御の例として、エンジンを制御するエンジン制御、操舵動作を制御する操舵制御、制動動作を制御する制動制御、それらの制御を補助する補助制御などが挙げられる。一方、情報制御とは、例えば車両の基本動作以外の付加機能を制御する付加制御である。より具体的な情報制御の例として、ナビゲーション制御、オーディオビジュアル制御、車外との通信制御などが挙げられる。

各コアは、互いに独立に又は連携して、ＯＳやそのＯＳ上で動作する上述の車両制御や情報制御を実現するアプリケーションプログラムなどのプログラムを処理する。各コアによって処理されるＯＳの具体例として、車両制御用ＯＳとしてのリアルタイムＯＳ（以下、「ＲＴ−ＯＳ」という）や情報制御用ＯＳとしてのマルチメディアＯＳ（以下、「ＭＭ−ＯＳ」という）などが挙げられる。

ＲＴ−ＯＳは、処理をリアルタイムに実行することを重視するため、バッチ処理やＴＳＳ（Time Sharing System）などの機能が優れたＯＳである。車両制御用アプリケーションプログラムでは制御応答性や安全性の確保などの観点から所定の処理をリアルタイムに実行する必要があるため、要求されるリアルタイム性を実現できるＲＴ−ＯＳが車両制御に使用されると好ましい。ＲＴ−ＯＳの具体例として、ＯＳＥＣ、ＩＴＲＯＮなどが挙げられる。

ＭＭ−ＯＳは、ＭＰＥＧのＣｏｄｅｃ等の圧縮／伸張処理、ＧＵＩ（Graphical User Interface）等のユーザインターフェース処理、セキュリティ管理を含むインターネット接続処理などのマルチメディア処理がＲＴ−ＯＳに比べ優れたＯＳである。要求されるマルチメディア処理を実現できるＭＭ−ＯＳが情報制御に使用されると好ましい。ＭＭ−ＯＳの具体例として、Ｌｉｎｕｘ（登録商標）、ＱＮＸ（登録商標）などが挙げられる。

また、マルチコアシステム１００は、図１に示されるように、最優先度制御である車両制御が割り当てられたコアの異常を検出する手段として、マルチコアプロセッサ１０と独立に、監視プロセッサ２０を備える。監視プロセッサ２０は、シングルコアプロセッサでもマルチコアプロセッサでもよい。例えば、コア０に車両制御が割り当てられた場合、監視プロセッサ２０は、コア０に発生したハードウェア又はソフトウェアの異常を検出する。もちろん、コア１，２，３に発生したハードウェア又はソフトウェアの異常も検出してもよい。監視プロセッサ２０に内蔵のコアは、例えばコア間通信によって、コア０の異常を検出する。監視プロセッサ２０は、コア０と通信確認を定期的に行うことによって、コア０自体やコア０によって処理されるプログラムが正常に動作しているか否かを監視することができる。また、監視プロセッサ２０は、コア０に異常が発生したことを知らせる異常通知信号の受信によってコア０の異常を検出してもよいし、ウォッチドッグパルスの検出によってコア０の異常を検出してもよい。

なお、監視プロセッサ２０は、マルチコアプロセッサ１０を内蔵する電子制御装置に含まれるものでもよいし、マルチコアプロセッサ１０を内蔵する電子制御装置と異なる電子制御装置に含まれるものでもよい。

図２は、監視プロセッサ２０がコア０の異常を検出した後の流れを説明するための模式図である。図２（ａ）は、異常発生前の状態を示した図である。コア０は、車両制御用ＯＳを作動させ、その車両制御用ＯＳ上で車両制御用アプリケーションプログラム（ＡＰＬ）０ａを処理する車両制御コアである。コア１，２，３は、情報制御用ＯＳを作動させ、その情報制御用ＯＳ上で情報制御用アプリケーションプログラム（ＡＰＬ）１ａ，２ａ，３ａをそれぞれ処理する情報制御コアである。

最優先制御である車両制御が割り当てられたコア０に異常が発生すると、その異常を検出した監視プロセッサ２０は、図２（ｂ）に示されるように、３つのコア１，２，３で動作している情報制御用ＯＳをそのうちの２つのコア２，３で動作させるように、レジストリや設定ファイルの書き換えを行って情報制御用ＯＳのコンフィギュレーションを変更させる。そして、監視プロセッサ２０は、異常が検出されたコア０によって処理されていた車両制御用ＡＰＬ０ａの処理をコア１によって継続させるため、コア１のＯＳを情報制御用ＯＳから車両制御用ＯＳに入れ替える。つまり、監視プロセッサ２０は、コア１に車両制御用ＯＳをロードして起動させ、コア１による車両制御用ＯＳ上で車両制御用ＡＰＬ０ａを動作させる。一方、コア１によって処理されていた情報制御用ＡＰＬ１ａは、情報制御用ＡＰＬ２ａ，３ａと同様に、コア２，３による情報制御用ＯＳ上で処理される。

監視プロセッサ２０は、コア０の異常の状態を診断し、コア０にハードウェア的な異常が検出されない場合には、図２（ｃ）に示されるように、２つのコア２，３で動作している情報制御用ＯＳを３つのコア０，２，３で動作させるように、情報制御用ＯＳのコンフィギュレーションを変更させる。そして、監視プロセッサ２０は、コア２，３によって動作する情報制御用ＯＳ上で処理されていた情報制御用ＡＰＬ１ａの処理をコア０によって継続させるため、コア０に情報制御用ＯＳをロードして起動させる。

次に、監視プロセッサ２０がコア０の異常を検出した場合の詳細な動作について、図３，４に従って説明する。

図３は、動作異常が検出されたコアが「正常」と診断される場合を示したシーケンス図である。監視プロセッサ２０は、各コアの動作をコア間通信によって監視する。コア０に異常動作が発生した場合、監視プロセッサ２０は、その異常動作を検出し（ステップ１０）、異常動作が検出されたコアが優先度の高い制御を処理するコアであるか否かを判断する（ステップ１２）。異常動作が検出されたコアが優先度の高い制御を処理するコアであると判断した場合（この場合、コア０）、監視プロセッサ２０は、情報制御コアとして動作していた３つのコアのうち、１つを車両制御コアとして動作させ残りの２つを情報制御コアとして動作させるコンフィギュレーションに変更するように、規定の優先度に従って、コア２，３に指示する。優先度は、コア毎に予め付与されていてもよいし、各コアの処理負荷に応じて決められてもよい。例えば、処理負荷が大きいほど優先度を高くするとした場合、処理負荷が一番低いコアを車両制御コアとして動作させ残りの２つを情報制御コアとして動作させるようにしてもよい。

その一方で、監視プロセッサ２０は、コア１に対しては、車両制御用ＯＳで再起動するようにブートの指示をする。当該ブート指示を受けたコア１は、車両用制御用ＯＳをＲＯＭ等の記憶媒体からＲＡＭにロードした後に、メモリの初期化等の初期設定の完了後、ブートの完了通知を監視プロセッサ２０に送信する。これによって、コア０による車両制御用ＯＳ上で処理されていた車両制御用ＡＰＬは、コア１による車両制御用ＯＳ上で処理を継続することができる。

さらに、コア０の異常動作を検出した監視プロセッサ２０は、コア０の障害情報として、異常の発生原因の解析に有用なレジスタ等の情報を取得する（ステップ１４）。障害情報の取得が完了した監視プロセッサ２０は、コア０のハードウェアの故障を診断可能なテストプログラムをロードしそのプログラムを開始させることによって、コア０のハードウェアの故障診断を実行する（ステップ１６）。このテストプログラムは、コアのハードウェアの故障診断に適切なプログラムであれば、その種類を問わない。故障診断の結果に基づきコア０にハードウェア上の異常がないと判断した監視プロセッサ２０は（ステップ１８）、リセットやノイズなどの何らかの理由により制御を継続しても支障のない一時的な異常を検出したものとみなして、コア０を通常動作させても問題ないと判断し、コア０に対して、情報制御用ＯＳで再起動するようにブートの指示をする。当該ブートの指示を受けたコア０は、情報制御用ＯＳをＲＯＭ等の記憶媒体からＲＡＭにロードした後に、メモリの初期化等の初期設定の完了後、ブートの完了通知を監視プロセッサ２０に送信する。これによって、コア１による情報制御用ＯＳ上で処理されていた情報制御用ＡＰＬは、コア０による情報制御用ＯＳ上で処理を継続することができる。

ブートの完了通知をコア０から受けた監視プロセッサ２０は、コア０，２，３の３コアで情報制御用ＯＳを動作させるコンフィギュレーションに変更するようにコア２，３に対して指示する。また、監視プロセッサ２０は、ステップ１４で得た障害情報を記憶装置３０に保存する。記憶装置３０に障害情報を保存する以降の流れについては後述する。

図４は、動作異常が検出されたコアが「異常」と診断される場合を示したシーケンス図である。ステップ１８までは、図３と同様のため、説明を省略する。ステップ１８において、監視プロセッサ２０は、故障診断の結果に基づきコア０にハードウェア上の異常があると判断した場合には、コア０の復旧は不可能であると判断し、ステップ１４で取得した障害情報を記憶装置３０に保存する。したがって、図４によれば、ハードウェアの異常が認められたコア０を復旧させないようにすることができるとともに、コア０による車両制御用ＯＳ上で処理されていた車両制御用ＡＰＬは、コア１による車両制御用ＯＳ上で処理を継続することができる。

このように、上述の実施例によれば、車両制御を処理するコアに動作異常が発見されても、情報制御を処理するコアにその車両制御を代替させることによって、情報制御より優先度の高い車両制御を継続的に実行し、安全に復旧させることができる。

次に、上述の障害情報の記憶装置３０への保存について説明する。図５は、マルチコアシステム１００を変形したマルチコアシステム２００の概略構成図である。マルチコアシステム２００の監視プロセッサ２０は、コアの動作異常が検出された場合に、コアの障害情報を異常履歴として記憶装置３０に保存する。記憶装置３０に保存された障害情報を参照することによって、コアの異常の発生原因の解析がしやすくなる。また、通信装置４０を介して障害情報を無線又は有線で送信可能にする構成を設けることによって、解析場所（例えば、センター５０）が離れていても、障害情報を容易に取得することができる。

したがって、上述の図３、図４に示されるように、監視プロセッサ２０は、ステップ１４において取得された障害情報を記憶装置３０に保存する。また、障害情報を取得した監視プロセッサ２０は、通信装置４０を介して、コアに異常動作が発生したことを知らせる障害通知をセンター５０に送信する（ステップ２０）。この障害通知を受信したセンター５０は障害情報の取得要求をする。その取得要求を受信した監視プロセッサ２０は、記憶装置３０に保存した障害情報を取得し（ステップ２２）、通信装置４０を介して、その障害情報をセンター５０に送信する（ステップ２４）。

以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。

例えば、上述の実施例では、コア０，１，２，３のそれぞれは、マルチコアプロセッサに内蔵のプロセッサコアとして説明したが、互いにコア間通信が可能な複数のシングルコアプロセッサでもよい。また、コアの数が４つ以上の場合も同様である。また、車両制御用ＯＳ及びそのＯＳ上で動作する車両制御用ＡＰＬが２つ以上のコアで処理される構成において、そのうちの一つのコアに故障が検知された場合であっても、その故障コアによって処理されていた車両制御用ＡＰＬを、その故障コア以外の車両制御コアで処理を継続させてもよいし、他の情報制御コアで処理を継続させてもよい。

本発明に係るマルチプロセッサシステムの一実施形態であるマルチコアシステム１００の概略構成図である。 監視プロセッサ２０がコア０の異常を検出した後の流れを説明するための模式図である。 動作異常が検出されたコアが「正常」と診断される場合を示したシーケンス図である。 動作異常が検出されたコアが「異常」と診断される場合を示したシーケンス図である。 マルチコアシステム１００を変形したマルチコアシステム２００の概略構成図である。

符号の説明

０，１，２，３ プロセッサコア
１０ マルチコアプロセッサ
３０ 記憶装置
４０ 通信装置
５０ センター
１００，２００ マルチコアシステム

Claims (7)

1. 担当すべき制御がそれぞれに割り当てられた複数のプロセッサを有する、マルチプロセッサシステムであって、
   前記複数のプロセッサのうち特定のプロセッサで発生した異常を検出する異常検出手段と、
   前記異常検出手段の検出結果に基づいて、前記複数のプロセッサのうち前記特定のプロセッサ以外の他のプロセッサのいずれかに、前記特定のプロセッサに割り当てられた特定制御を代替させる指令手段とを備えることを特徴とする、マルチプロセッサシステム。
2. 前記特定のプロセッサのハードウェアの異常の有無を診断する異常診断手段を備え、
   前記異常診断手段の診断結果に基づいて、前記指令手段により前記特定制御に代替したプロセッサに前記特定制御の代替がされる前に割り当てられていた制御が、前記特定のプロセッサに割り当てられるか否かが判断される、請求項１に記載のマルチプロセッサシステム。
3. 前記指令手段は、規定の優先順位に従って、前記特定制御を代替させるプロセッサを決定する、請求項１又は２に記載のマルチプロセッサシステム。
4. 前記指令手段は、ＯＳとそのＯＳ上で動作するアプリケーションプログラムを代替させる、請求項１から３のいずれかに記載のマルチプロセッサシステム。
5. 前記複数のプロセッサは、マルチコアプロセッサ内のプロセッサコアである、請求項１から４のいずれかに記載のマルチプロセッサシステム。
   
6. 担当すべき制御がそれぞれに割り当てられた複数のプロセッサを有するマルチプロセッサシステムの制御方法であって、
   前記複数のプロセッサのうち特定のプロセッサで発生した異常を検出する異常検出ステップと、
   前記異常が検出された場合、前記複数のプロセッサのうち前記特定のプロセッサ以外の他のプロセッサのいずれかに、前記特定のプロセッサに割り当てられた特定制御を代替する代替ステップとを備えることを特徴とする、マルチプロセッサシステムの制御方法。
7. 前記特定のプロセッサのハードウェアの異常の有無を診断する異常診断ステップと、
   前記ハードウェアの異常がないと診断された場合、前記特定制御に代替したプロセッサが前記特定制御に代替する前に割り当てられていた制御を前記特定のプロセッサに割り当てる割り当てステップとを備える、請求項６に記載のマルチプロセッサシステムの制御方法。

Images