JP2008015704A - マルチプロセッサシステム - Google Patents

マルチプロセッサシステム Download PDF

Info

Publication number
JP2008015704A
JP2008015704A JP2006184874A JP2006184874A JP2008015704A JP 2008015704 A JP2008015704 A JP 2008015704A JP 2006184874 A JP2006184874 A JP 2006184874A JP 2006184874 A JP2006184874 A JP 2006184874A JP 2008015704 A JP2008015704 A JP 2008015704A
Authority
JP
Japan
Prior art keywords
processor element
multiprocessor system
processor
failure
priority
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2006184874A
Other languages
English (en)
Inventor
Hiromasa Takahashi
宏政 高橋
Takashi Chiba
隆 千葉
Shunsuke Kamijo
俊介 上條
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2006184874A priority Critical patent/JP2008015704A/ja
Priority to PCT/JP2007/000394 priority patent/WO2008004330A1/ja
Publication of JP2008015704A publication Critical patent/JP2008015704A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023Failover techniques
    • G06F11/2028Failover techniques eliminating a faulty processor or activating a spare
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2051Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant in regular structures

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

【課題】低価格で信頼性の高いマルチプロセッサシステムを提供する。
【解決手段】各プロセッサエレメント(PE0〜PE3)は、それぞれ対応するアプリケーションを実行する。各アプリケーションの優先度は、アプリケーション優先度テーブル26において定義されている。各プロセッサエレメント(PE0〜PE3)は、それぞれ定期的に生存情報をPE状態テーブル25に書き込む。各プロセッサエレメント(PE0〜PE3)は、それぞれ定期的にPE状態テーブル25に書き込まれている生存情報を参照し、他のプロセッサエレメントの状態を監視する。優先度の高いアプリケーションを実行しているプロセッサエレメント(PE0)が故障すると、そのアプリケーションは、優先度の低いアプリケーションを実行しているプロセッサエレメント(PE3)によって引き継がれる。
【選択図】図3

Description

本発明は、複数のプロセッサエレメントを備えるマルチプロセッサシステムに係わり、特に、組込み型マルチプロセッサシステムの信頼性を向上させる技術に係わる。
従来より、高い信頼性を必要とするサーバシステムとして、正常動作時に処理を実行する現用系プロセッサ、及び現用系プロセッサに障害が発生したときにその処理を引き継ぐ予備系プロセッサ(ホットスタンバイ用プロセッサ)を備える構成が実用化されている。ここで、予備系プロセッサは、現用系プロセッサが正常に動作している期間は、電源は投入されているが、実質的な処理は行っていない。そして、このようなサーバシステムは、例えば、複数のクラスタ(現用系プロセッサおよび予備系プロセッサを含むサブシステム)を備え、クラスタ間を接続する通信パス、不揮発性のストレージシステム、各クラスタを監視/制御するサービスプロセッサ(SVP)を利用して全プロセッサにより共用可能なファイル装置を提供する。そして、障害発生時における現用系から予備系への切替えは、ホットスタンバイ機能により、数秒程度で自動的に行われる。なお、ホットスタンバイ機能を提供するサーバシステムは、例えば、特許文献1〜3に記載されている。
上述のようなサーバシステムにおける故障の検出方法としては、例えば、各プロセッサ内に故障検出回路を内蔵することによってハードウェア故障を検出する構成、サービスプロセッサ(SVP)を用いて各プロセッサの動作を監視する構成が知られている。この場合、サービスプロセッサは、現用系における故障を検出すると、ソフトウェアおよびハードウェアの構成を変更する。また、特許文献4には、複数のプロセッサを備える計算機システムにおいて、各プロセッサにそれぞれ複数のOSを搭載し、OS間で他のOSの故障を監視する方法が記載されている。
なお、関連する技術として、特許文献5には、複数の系から構成されるコンピュータシステムにおいて各系に対して予め優先度を設定しておき、ある系において障害が検出されたときに、その系の優先度に対応する時間が経過した時点でリセット処理を行う技術が記載されている。
ところで、様々な分野において組込みシステムが広く普及してきている。組込みシステムは、制御すべき対象の装置に内蔵される情報処理システムであって、1または複数のプロセッサを用いてその装置の動作を制御する。そして、近年では、高い信頼性を必要とする組込みシステム(例えば、航空機や自動車に組み込まれる制御システム等)が要求されている。
組込みシステムの信頼性を高める技術としては、例えば、3重化されたシステムが並列に処理を実行し、多数決原理に従って最も確からしい処理結果を選択する構成が知られている。この構成においては、特定のシステムが他の2つのシステムとは異なる処理結果を繰り返し出力したときに、その特定のシステムが切り離される。また、他の技術として、現用系システムの出力を他のシステムのプロセッサが監視し、その出力値が予め決められた範囲を逸脱したときに現用系システムを停止する構成も知られている。
特開平1−99141号 特開平1−216459号 特開平2−71347号 特開2002−259155号 特開2006−11992号
組込みシステムの信頼性を高める方法として、上述したサーバシステムに適用されている技術を組込みシステムに導入する構成が考えられる。しかし、サーバシステムに適用されている技術においては、現用系プロセッサの他に、正常動作時に実質的に処理を実行しない予備系プロセッサおよび/または各プロセッサを監視するサービスプロセッサを設ける必要がある。このため、この方法を導入すると、価格の上昇、実装面積の増加、消費電力の増加、重量の増加を招くこととなり、組込みシステムとしては不適切である。また、既存のサーバシステムに適用されているホットスタンバイ機能では、現用系から予備系への切替え時間が数秒程度であり、組込みシステムにおいて重要なリアルタイム性を保障できないおそれがある。なお、制御対象装置の動作を制御する組込みシステムにおいては、故障の発生から数ミリ秒(長くても、数百ミリ秒)以内に復帰処理が要求されることが多い。
OS間で相互に故障を監視する構成では、各プロセッサの負荷が重くなり、本来の処理に影響が及ぶおそれがある。なお、組込みシステムにおいて使用されるプロセッサは、一般に、小型化/低コスト化を実現するためにその処理能力が低い場合が多い。
多数決動作を導入するためにシステムを3重化する構成では、リアルタイム性は確保できるが、低コスト化を図ることは困難である。また、低コスト化を図るために3重化システムを2重化システムにすると、故障を検出することは可能であるが、どちらのシステムにおいて故障が発生したのかを判断できず、代替動作を行うことができないことがある。
本発明の課題は、低価格で信頼性の高いマルチプロセッサシステムを提供することである。
本発明のマルチプロセッサシステムは、複数のプロセッサエレメントを備える構成であり、各プロセッサエレメントにより実行される処理の優先度を管理する管理手段と、各プロセッサエレメントの状態を監視する監視手段と、第1の処理を実行している第1のプロセッサエレメントにおいて故障が検出されたときに、前記管理手段の処理優先度情報を参照し、前記第1の処理よりも優先度の低い第2の処理を実行している第2のプロセッサエレメントに前記第1の処理を実行させる切替え手段、を有する。
上記構成のマルチプロセッサシステムにおいては、あるプロセッサエレメントが故障したときに、その故障したプロセッサエレメントにより実行されていた処理の優先度が高ければ(あるいは、その処理の優先度が最低でなければ)、以降、その処理は他のプロセッサエレメントにより実行される。従って、システムの信頼性が向上する。
上記マルチプロセッサシステムにおいて、監視手段を各プロセッサエレメントにそれぞれ設け、各プロセッサエレメントがそれぞれ他のプロセッサエレメントの状態を監視するようにしてもよい。この構成によれば、プロセッサエレメントの状態を監視するための専用プロセッサは不要である。
また、上記マルチプロセッサシステムにおいて、所定の時間間隔で予め決められた規則に従って生存情報を生成し、各プロセッサエレメントが参照可能なメモリ領域にその生存情報を書き込む生存情報生成手段を各プロセッサエレメントにそれぞれ設けるようにしてもよい。この場合、監視手段は、所定の時間間隔で前記メモリ領域を参照することによりプロセッサエレメントの状態を監視する。この構成によれば、簡単な手順で他のプロセッサエレメントの故障を検出することができる。
本発明によれば、低価格で信頼性の高いマルチプロセッサシステムを提供することができる。
図1は、本発明の概念を説明する図である。なお、図1においては、説明を簡単にするためにプロセッサエレメント(PE)を2つだけ備える構成を示しているが、マルチプロセッサシステムを構成するプロセッサエレメントの数は特に限定されるものではない。
プロセッサエレメント1A、1Bは、それぞれ与えられたアプリケーション(または、タスク)を実行する。ここで、各アプリケーションには、それぞれ優先度が設定されている。図1に示す例では、プロセッサエレメント1Aにより実行されるアプリケーションの優先度が高く、プロセッサエレメント1Bにより実行されるアプリケーションの優先度が低いものとする。すなわち、プロセッサエレメント1Aは、優先度の高い処理を実行するプロセッサエレメント(高優先プロセッサエレメント)であり、プロセッサエレメント1Bは、優先度の低い処理を実行するプロセッサエレメント(低優先プロセッサエレメント)である。
記憶領域2は、各プロセッサエレメント1A、1Bの状態を管理するPE状態テーブル3を保持する。ここで、記憶領域2は、各プロセッサエレメント1A、1Bからアクセス可能であり、例えば、プロセッサエレメント1A、1Bのメインメモリである。なお、PE状態テーブル3には、各プロセッサエレメントについての生存情報および自己申告情報などが格納される。
本発明に係るマルチプロセッサシステムの基本動作は、以下の通りである。
(1)各プロセッサエレメントは、それぞれ所定の時間間隔ごとに、生存情報を生成してPE状態テーブル3に書き込む。ここで、「所定の時間間隔」は、プロセッサエレメントの故障を検出するために要する時間、および故障発生時にプロセッサエレメントを切り替えるための時間の要求値に応じて決定されるものであり、例えば、数ミリ秒〜数百ミリ秒である。また、生存情報は、各プロセッサエレメントにおいて予め決められた規則に従って生成される。すなわち、プロセッサエレメントが正常に動作している期間は、PE状態テーブル3において、そのプロセッサエレメントにより生成される生存情報は予め決められた規則に従って更新される。一方、あるプロセッサエレメントが故障すると、PE状態テーブル3において、そのプロセッサエレメントに対応する生存情報は不適切な値となる。なお、以下の説明において、生存情報を生成して記憶領域2に書き込む動作を「生存通知」と呼ぶことがある。
(2)各プロセッサエレメントは、自己の故障を検出したときには、その故障を他のプロセッサエレメントに通知する。以下の説明では、この動作のことを「自己申告」と呼ぶものとする。自己申告は、自己の故障を検出したプロセッサエレメントがPE状態テーブル3にその旨を書き込むことにより実現される。なお、自己申告を高速で行う場合には、プロセッサエレメント間の通信のために設けられているPE間通信パスを利用して自己申告情報を他のプロセッサエレメントに送信するようにしてもよい。
(3)各プロセッサエレメントは、それぞれ所定の時間間隔ごとに、PE状態テーブル3を参照し、他のプロセッサエレメントの状態をチェックする。以下の説明では、この動作のことを「生存監視」と呼ぶことがある。そして、PE状態テーブルにおいてあるプロについての生存情報が不適切であることが検出されると、そのプロセッサエレメントは故障していると判断される。また、自己申告をしているプロセッサエレメントが検出された場合も、そのプロセッサエレメントは故障していると判断される。さらに、PE間通信パスを介して自己申告が行われる場合は、生存監視とは無関係に、自己申告信号を受信した時点で故障の発生が検出される。このように、本発明のマルチプロセッサシステムでは、あるプロセッサエレメントにおいて故障が発生すると、他の1または複数のプロセッサエレメントによりその故障が検出される。
(4)低優先プロセッサエレメントが高優先プロセッサエレメントの故障を検出した場合は、以下の動作が行われる。
(4−1)故障を検出したプロセッサエレメントは、故障した高優先プロセッサエレメントの動作を停止するとともに、その高優先プロセッサエレメントをリセットする。
(4−2)故障した高優先プロセッサエレメントは、マルチプロセッサシステムの共用資源および他のプロセッサエレメントから切り離される。具体的には、例えば、メモリバス、PE間通信パス、I/Oバス等のアクセスパスが切断される。
(4−3)低優先プロセッサエレメントの動作をいったん停止した後、故障した高優先プロセッサエレメントで実行されていたアプリケーションをその低優先プロセッサエレメントに実行させる(代替実行)。
(5)高優先プロセッサエレメントが低優先プロセッサエレメントの故障を検出した場合は、以下の動作が行われる。
(5−1)故障を検出したプロセッサエレメントは、故障した低優先プロセッサエレメントの動作を停止するとともに、その低優先プロセッサエレメントをリセットする。
(5−2)故障した低優先プロセッサエレメントは、マルチプロセッサシステムの共用資源および他のプロセッサエレメントから切り離される。具体的には、例えば、メモリバス、PE間通信パス、I/Oバス等のアクセスパスが切断される。この後、故障した低優先プロセッサエレメントで実行されていたアプリケーションは終了する。
このように、本発明のマルチプロセッサシステムにおいては、優先度の高い処理を実行しているプロセッサエレメントが故障した場合には、優先度の低い処理を実行しているプロセッサエレメントがその高優先処理を引き継いで実行する。よって、高優先処理は、その高優先処理を実行していたプロセッサエレメントが故障しても、継続して実行される。そして、この故障回復機能は、待機プロセッサエレメント(すなわち、現用系プロセッサが正常に動作している期間は、実質的な処理を行わないプロセッサ)を設けることなく実現される。すなわち、本発明によれば、待機プロセッサエレメントを設けることなく、実質的にホットスタンバイ機能が提供される。
また、各プロセッサエレメントの状態はそれぞれ他のプロセッサエレメントにより監視されるので、システムの動作を監視するための専用プロセッサを設ける必要はない。
なお、LSIチップ上に形成される記憶領域にPE状態テーブル3を設けると共に、PE間通信パスを介して自己申告を行う構成を導入すれば、故障検出および代替動作による故障回復の高速化を図ることができる。
図2は、組込みシステムについて説明する図である。本発明の実施形態のマルチプロセッサシステム11は、特に限定されるものではないが、例えば、制御対象装置10に組み込まれて使用される。制御対象装置10は、複数の装置エレメント12−1〜12−nを備える。そして、各装置エレメント12−1〜12−nの動作は、マルチプロセッサシステム11が複数のアプリケーションを並列に実行することにより制御される。ここで、マルチプロセッサシステム11は、図1を参照しながら説明した機能を備えている。なお、マルチプロセッサシステム11は、任意のプロセッサエレメントにおいて故障が発生したときに、その故障内容を表示装置13に表示するようにしてもよい。
図3は、実施形態のマルチプロセッサシステムのハードウェア構成を示す図である。ここでは、実施形態のマルチプロセッサシステムは、4個のプロセッサエレメント(PE0〜PE3)を備えるものとする。また、図3に示す例では、4個のプロセッサエレメントが1つのチップ上に形成されているが、本発明のマルチプロセッサシステムは、マルチチップ型であってもよい。なお、この実施例では、マルチプロセッサシステムは、自動車の安全運転支援装置に組み込まれているものとする。
実施形態のマルチプロセッサシステムは、プロセッサエレメント(PE0〜PE3)21、共有メモリ22、不揮発性メモリ23、動的構成制御ユニット24を備える。プロセッサエレメント(PE0〜PE3)21は、互いに並列にアプリケーションを実行する。この実施例では、プロセッサエレメント(PE0)は前方監視処理を実行し、プロセッサエレメント(PE1)は側方監視処理を実行し、プロセッサエレメント(PE2)はナイトビジョン処理を実行し、プロセッサエレメント(PE3)はドライバー監視処理を実行するものとする。また、プロセッサエレメント間は、PE間通信パス30により互いに接続されている。
共有メモリ(外部メモリ)22は、各プロセッサエレメント21からアクセス可能な記憶領域であり、OSおよびアプリケーションプログラムが格納されている。また、共有メモリ22において、PE状態テーブル25およびアプリケーション優先度テーブル26が作成される。PE状態テーブル25は、各プロセッサエレメント(PE0〜PE3)21の状態を表す情報が書き込まれる。また、アプリケーション優先度テーブル26は、各プロセッサエレメント(PE0〜PE3)21により実行されるアプリケーションの優先度を表す情報を保持する。この実施例では、前方監視処理の優先度が最も高く、側方監視処理の優先度が2番目に高く、ナイトビジョン処理の優先度が3番目に高く、ドライバー管理処理の優先度は最も低いものとする。なお、各プロセッサエレメント21と共有メモリ22との間は、メモリバスとしてのクロスバ(XB)27により接続されている。
なお、各プロセッサエレメント内にPE状態テーブル25およびアプリケーション優先度テーブル26を設けるようにしてもよい。この場合、これらのテーブルにより保持される情報は、例えば、PE間通信パス30を介して送受信される。
不揮発性メモリ23は、例えばフラッシュメモリであり、各種設定値および構成制御テーブル28が格納される。構成制御テーブル28は、アプリケーション優先度テーブル26を含んで構成される。なお、各プロセッサエレメント21と不揮発性メモリ23との間は、I/Oバス29により接続されている。
各プロセッサエレメント21とクロスバ27との間には、それぞれスイッチ31が設けられている。また、各プロセッサエレメント21とI/Oバス29との間には、それぞれスイッチ32が設けられている。さらに、各プロセッサエレメント21とPE間通信パス30との間には、それぞれスイッチ33が設けられている。
動的構成制御ユニット24は、PE間通信パス30に接続されており、任意のプロセッサエレメントからのコマンドに従って、対応するプロセッサエレメントが備えるスイッチ31〜33を制御する。例えば、プロセッサエレメント(PE0)の故障が検出されたときは、動的構成制御ユニット24は、そのプロセッサエレメント(PE0)のスイッチ31〜33をオフ状態に制御する。これにより、故障したプロセッサエレメントは、マルチプロセッサシステムの共有資源および他のプロセッサエレメントから切り離される。
図4は、動的構成制御ユニット24の実施例を示す図である。動的構成制御ユニット24は、PE間通信パス30を介して制御パケットを受信する。動的構成制御ユニット24宛ての制御パケットは、ID、コマンド、PE番号を含む。「ID」は、制御パケットの宛先として動的構成制御ユニット24を識別する。コマンドは「切断」を指示する。「PE番号」は、故障したプロセッサエレメントを識別する。なお、この制御パケットは、他のプロセッサエレメントの故障を検出したプロセッサエレメントにより生成される。
ID保持部41には、動的構成制御ユニット24を識別するIDが保持されている。比較器42は、制御パケットに格納されているIDとID保持部41に保持されているIDとを比較する。そして、比較器42は、それら1組のIDが互いに一致すると、入力レジスタ43に対してEnable信号を与える。
入力レジスタ43には、制御パケットから抽出されたコマンドおよびPE番号が書き込まれる。そして、比較器42からEnable信号が与えられると、入力レジスタ43に保持されているコマンド及びPE番号はデコーダ44に送られる。デコーダ44は、コマンド及びPE番号を解析し、対応する制御信号をスイッチ制御回路45〜47に送る。スイッチ制御回路45は、制御パケットに格納されているPE番号に対応するプロセッサエレメントのスイッチ31をオフ状態に制御する信号を生成する。同様に、スイッチ制御回路46、47は、それぞれ、制御パケットに格納されているPE番号に対応するプロセッサエレメントのスイッチ32、33をオフ状態に制御する信号を生成する。
上記構成の動的構成制御ユニット24は、例えば、「PE番号=PE0」を含む制御パケットを受信すると、プロセッサエレメント(PW0)が備えるスイッチ31〜33をオフ状態に制御する信号を生成する。そうすると、プロセッサエレメント(PW0)が備えるスイッチ31〜33はオフ状態に制御される。この結果、プロセッサエレメント(PE0)は、クロスバ27、I/Oバス29、PE間通信パス30から切り離される。
図5は、実施形態のマルチプロセッサシステムのソフトウェア構成を示す図である。図5に示すように、各プロセッサエレメント上でリアルタイムOSが動作する。このリアルタイムOSは、PE間通信機能を備えているものとする。また、リアルタイムOS上でアプリケーションA〜Dが動作する。ここで、アプリケーションA〜Dは、図3に示す例では、それぞれ前方監視処理、側方監視処理、ナイトビジョン処理、ドライバー監視処理に相当する。さらに、実施形態のマルチプロセッサシステムには、状態マネージャ(M#0〜M#3)が実装されている。状態マネージャ(M#0〜M#3)は、後で詳しく説明するが、故障検出処理および故障回復処理を実行する。
次に、実施形態のマルチプロセッサシステムの動作を説明する。なお、ここでは、マルチプロセッサシステムの初期状態において、前方監視処理がプロセッサエレメント(PE0)により実行され、側方監視処理がプロセッサエレメント(PE1)により実行され、ナイトビジョン処理がプロセッサエレメント(PE2)により実行され、ドライバー監視処理がプロセッサエレメント(PE3)により実行されるものとする。また、前方監視処理の優先度が最も高く、側方監視処理の優先度が2番目に高く、ナイトビジョン処理の優先度が3番目に高く、ドライバー管理処理の優先度は最も低いものとする。そして、各アプリケーションの状態を表す情報は、図6(a)に示すように、アプリケーション優先度テーブル26に書き込まれている。
<生存通知>
各プロセッサエレメント(PE0〜PE3)は、それぞれ、状態マネージャプログラム(M#0〜M#3)を実行する。これにより、各プロセッサエレメント(PE0〜PE3)は、所定の時間間隔で生存通知を行う。生存通知を実行する時間間隔は、例えば、数ミリ秒〜数百ミリ秒程度である。また、生存通知は、各プロセッサエレメント(PE0〜PE3)によりそれぞれ生成される生存情報をPE状態テーブル25に書き込むことにより実現される。
図7は、PE状態テーブル25の実施例である。PE状態テーブル25は、生存通知が行われる時間間隔と同じ間隔で生成される。ここで、図7(a)は、時刻TにおけるPE状態テーブルを示し、図7(b)は、時刻T+taにおけるPE状態テーブルを示している。なお「ta」は、生存通知が行われる時間間隔に相当する。
生存情報は、各プロセッサエレメントにおいて、予め決められた規則に従って生成される。生存情報を生成する規則は、特に限定されるものではないが、この実施例では「新たに生成する生存情報=前回の生存情報+1」である。この場合、プロセッサエレメントが正常に動作しているものとすると、時刻Tにおける生存情報と時刻T+taにおける生存情報との差分は「1」になる。図7に示す例では、プロセッサエレメント(PE1〜PE3)の生存情報は、それぞれ「1」だけインクリメントされている。しかし、故障したプロセッサエレメントは、生存通知を行うことができない(或いは、不適切な生存情報を生成する)。この場合、時刻Tにおける生存情報と時刻T+taにおける生存情報との差分は「1」にはならない。図7に示す例では、プロセッサエレメント(PE0)の生存情報は、時刻T〜T+taにおいて「a」のまま変化していない。
<自己申告>
各プロセッサエレメント(PE0〜PE3)は、それぞれ、自己の故障を検出する機能を備えている。この機能は、各プロセッサエレメントに内蔵されるチェック回路により実現され、例えば、共有メモリのECCエラー、内蔵メモリのパリティエラー、不正命令の実行に伴うエラー、バスのパリティエラー、バスエラー等を検出することができる。
プロセッサエレメントは、自己の故障を検出すると、その故障を申告する。故障の申告は、自己の故障を検出したプロセッサエレメントがPE状態テーブル25に故障フラグを書き込むことにより実現される。あるいは、自己の故障を検出したプロセッサエレメントが例外処理ルーチンを起動し、PE間通信パス30を利用して他のプロセッサエレメントに通知を行うようにしてもよい。
<生存監視>
各プロセッサエレメント(PE0〜PE3)は、それぞれ、所定の時間間隔で生存監視を行う。生存監視を実行する時間間隔は、生存通知の時間間隔と同じであってもよいし、異なっていてもよい。この実施例では、生存通知および生存監視の時間間隔は互いに同じであり、生存通知が実行された後の所定のタイミングで対応する生存監視が行われるものとする。
生存監視は、各プロセッサエレメント(PE0〜PE3)がそれぞれPE状態テーブル25を参照することにより実現される。具体的には、たとえば、各プロセッサエレメント(PE0〜PE3)は、最新のPE状態テーブルおよび1つ前に生成されたPE状態テーブルを読み出し、対応する生存情報を比較する。このとき、プロセッサエレメント(PE0)は、プロセッサエレメント(PE1〜PE3)について生存情報をチェックする。同様に、プロセッサエレメント(PE1)はプロセッサエレメント(PE0、PE2、PE3)について生存情報をチェックし、プロセッサエレメント(PE2)はプロセッサエレメント(PE0、PE1、PE3)について生存情報をチェックし、プロセッサエレメント(PE3)はプロセッサエレメント(PE0〜PE2)について生存情報をチェックする。
図7に示す実施例では、プロセッサエレメント(PE1〜PE3)の生存情報は、時刻T〜T+taにおいて、それぞれ「1」だけインクリメントされている。この場合、プロセッサエレメント(PE1〜PE3)は「正常」である判断される。これに対して、プロセッサエレメント(PE0)の生存情報は、時刻T〜T+taにおいて変化していない。この場合、プロセッサエレメント(PE0)は「故障」と判断される。なお、プロセッサエレメント(PE0)の故障は、プロセッサエレメント(PE1〜PE3)により検出される。
各プロセッサエレメント(PE0〜PE3)は、PE状態テーブル25の生存情報を参照する際に、自己申告情報も参照する。自己申告情報は、基本的に、最新のPE状態テーブルを参照する。
なお、上述の例では、連続する2つのPE状態テーブルに書き込まれている生存情報を比較することよりプロセッサエレメントの状態をチェックしているが、3以上のPE状態テーブルに書き込まれている生存情報に基づいてプロセッサエレメントの状態を判断するようにしてもよい。また、上述の例では、生存情報は前回の生存情報をインクリメントすることにより生成されているが、本発明はこの規則に限定されるものではない。即ち、例えば、各プロセッサエレメントがそれぞれ有するタイマが生成する時刻情報を生存通知タイミング毎にPE状態テーブル25に書き込むようにしてもよい。さらに、各プロセッサエレメント内にPE状態テーブル25を設ける構成を導入すれば、生存監視の高速化を図ることができる。
<故障の検出および回復>
図3に示すマルチプロセッサシステムにおいて、プロセッサエレメント(PE0)が故障したものとする。そうすると、図7に示すように、PE状態テーブル25において、プロセッサエレメント(PE0)の「生存情報」は更新されなくなる。
プロセッサエレメント(PE1〜PE3)は、それぞれ、上述した生存監視を実行することにより、プロセッサエレメント(PE0)の故障を検出することができる。そして、プロセッサエレメント(PE1〜PE3)は、プロセッサエレメント(PE0)の故障を検出すると、下記の回復処理を行う。ただし、回復処理は、基本的に、最も優先度の低いアプリケーションを実行しているプロセッサエレメント(ここでは、PE3)により実行されることが好ましい。したがって、以下の説明では、プロセッサエレメント(PE3)によって回復処理が実行されるものとする。
プロセッサエレメント(PE3)は、故障したプロセッサエレメント(PE0)をリセットする。これにより、プロセッサエレメント(PE0)の動作は停止する。ここで、リセット信号は、例えば、PE間通信パス30を介して送信される。また、プロセッサエレメント(PE3)は、制御パケットを生成して動的構成制御ユニット24に送信する。この制御パケットには、故障したプロセッサエレメントを識別する情報として「PE番号=PE0」が格納されている。そうすると、動的構成制御ユニット24は、プロセッサエレメント(PE0)が備えるスイッチ31〜33をオフ状態に制御する。この結果、故障したプロセッサエレメント(PE0)は、クロスバ27、I/Oバス29、PE間通信パス30から切り離される。
続いて、プロセッサエレメント(PE3)は、アプリケーション優先度テーブル26を参照し、プロセッサエレメント(PE0)により実行されていたアプリケーションの優先度とプロセッサエレメント(PE3)が実行しているアプリケーションの優先度とを比較する。ここでは、プロセッサエレメント(PE3)が実行しているアプリケーションの優先度の方が低い。この場合、プロセッサエレメント(PE3)は「ドライバー監視処理」を停止し、故障したプロセッサエレメント(PE0)によって実行されていた「前方監視処理」を実行する。このとき、プロセッサエレメント(PE3)は、次に実行すべきアプリケーションとして「前方監視処理」を指定し、その後、自分自身をリセットする。これにより、アプリケーションを実行すべきプロセッサエレメントの切替えが実現される。あるいは、リアルタイムOSのタスクスイッチ機構を利用して、プロセッサエレメント(PE0)により実行されていた処理をプロセッサエレメント(PE3)に実行させることも可能である。
この後、アプリケーション優先度テーブル26は、プロセッサエレメント(PE3)またはOSからの通知により、図6(b)に示す状態に更新される。
上述のように、優先度の高い処理を実行していたプロセッサエレメントが故障した場合には、優先度の低い処理を実行していたプロセッサエレメントがその高優先処理を引き継いで実行する。したがって、優先度の高い処理(実際には、最も優先度の低い処理以外の処理)は、プロセッサエレメントが故障しても、継続して実行されるので、信頼性の高いマルチプロセッサシステムが実現される。また、待機プロセッサエレメントおよび故障監視のための専用プロセッサを備える必要がないので、マルチプロセッサシステムの低コスト化を図ることができる。
なお、生存情報を利用して故障を検出する場合の手順を説明したが、あるプロセッサエレメントにより申告された故障を他のプロセッサエレメントが検出した場合も同様の手順でアプリケーションの引継ぎが行われる。
図8は、状態マネージャの処理を示すフローチャートである。なお、状態マネージャは各プロセッサエレメントにおいてそれぞれ動作する。また、ここでは、自己申告は、PE間通信パス30を介して行われるものとする。
ステップS1では、自分自身の故障をチェックする。自分自身の故障は、例えば、プロセッサエレメントに内蔵されているチェック回路から状態マネージャへの割込み信号(回復不能例外)により通知される。自分自身の故障を検出すると、PE間通信パス30を介して他のプロセッサエレメントに対して故障の申告を行う。ステップS2では、他のプロセッサエレメントからの故障の申告をチェックする。そして、他のプロセッサエレメントから故障の申告を受信した場合には、代替実行処理ルーチンに進む。
ステップS11〜S15は、生存監視による故障検出処理ルーチンである。ステップS11は、所定の時間間隔を計時する処理である。すなわち、故障検出処理ルーチンは、所定の時間間隔で実行される。ステップS12では、生存通知が実行される。生存通知は、上述したように、生存情報を生成してPE状態テーブル25に書き込むことにより実現される。ステップS13では、PE状態テーブル25を読み出す。
ステップS14〜S15では、各プロセッサエレメントについて最新のPE状態テーブルの生存情報と前回のPE状態テーブルの生存情報と比較し、各プロセッサエレメントが正常であるのか故障しているのかを判断する。一実施例としては、比較される1組の生存情報が互いに一致していたときに、プロセッサエレメントが故障していると判断される。そして、故障が検出されたときは、代替実行処理ルーチンに進む。
ステップS21〜S27は、代替実行処理ルーチンである。この代替実行処理ルーチンは、生存監視により他のプロセッサエレメントの故障を検出したとき、および他のプロセッサエレメントから故障の申告を受信したときに実行される。
ステップS21では、故障したプロセッサエレメントを識別するPE番号を検出する。ステップS22では、まず、故障したプロセッサエレメントをリセットして停止する。さらに、その故障したプロセッサエレメントを他のプロセッサエレメントから切り離す。この場合、故障したプロセッサエレメントを識別するPE番号が動的構成制御ユニット24に送信される。そうすると、動的構成制御ユニット24は、故障したプロセッサエレメントが備えるスイッチ31〜33をオフ状態に制御する。この結果、故障したプロセッサエレメントは、クロスバ、I/Oバス、PE間通信パスから切り離される。
ステップS23〜S24では、アプリケーション優先度テーブル26を参照し、故障したプロセッサエレメントが実行していたアプリケーションの優先度を確認する。そして、故障したプロセッサエレメントが実行していたアプリケーションの優先度が最も低かった場合にはステップS27に進み、そうでない場合にはステップS25に進む。
ステップS25では、故障したプロセッサエレメントにより実行されていたアプリケーションを、その故障したプロセッサエレメントから引き継いで実行する。そして、ステップS26において、アプリケーション優先度テーブル26を更新する。例えば、図3に示すマルチプロセッサシステムにおいてプロセッサエレメント(PE0)が故障した場合には、アプリケーション優先度テーブル26は、図6(a)に示す状態から図6(b)に示す状態へ更新される。
なお、故障したプロセッサエレメントが実行していたアプリケーションの優先度が最も低かった場合には、そのアプリケーションは他のプロセッサエレメントに引き継がれることはなく、そのまま終了する。ただし、ステップS27においてアプリケーション優先度テーブル26の更新は行われる。
このように、故障したプロセッサエレメントにより実行されていたアプリケーションよりも優先度の低いアプリケーションが存在する場合には、その故障したプロセッサエレメントにより実行されていたアプリケーションは、他のプロセッサエレメントに引き継がれて実行される。なお、代替実行処理ルーチンは、例えば、最も優先度の低いアプリケーションを実行しているプロセッサエレメント、正常に動作しているプロセッサエレメントの中で一番小さいPE番号を持ったプロセッサエレメント、あるいは最初に故障を検出したプロセッサエレメントにより実行される。ただし、最も優先度の低いアプリケーションを実行しているプロセッサエレメントが故障したときは、代替実行処理ルーチンは、たとえば、正常に動作しているプロセッサエレメントの中で一番小さいPE番号を持ったプロセッサエレメント、または最初に故障を検出したプロセッサエレメントにより実行される。
なお、図8に示す実施例1の故障検出において、自己故障検出と生存監視による故障検出とをそれぞれ含む構成に限定されない。
図9は、他の実施形態の状態マネージャの処理を示すフローチャートである。なお、図8および図9に示す手順において、故障検出処理ルーチンは互いに同じであるが、代替実行処理ルーチンは異なっている。
図9に示すフローチャートは、特殊な条件下で発生するソフトウェアエラー(プログラムのバグを含む)を考慮して、図8に示すフローチャートを改良したものである。すなわち、特殊な条件下で発生するソフトウェアエラーは、プロセッサエレメントを再ブートすると、以降、発生しなくなることがある。そこで、図9に示すフローチャートでは、故障が検出されたプロセッサエレメントを再ブートする手順が導入されている。
ステップS31では、再ブート履歴を参照し、故障したプロセッサエレメントが既に再ブートされているか否かをチェックする。再ブートされていなければ、ステップS32において、故障したプロセッサエレメントを再ブートする。ステップS33では、再ブートされたプロセッサエレメントは、再ブート前に実行していたアプリケーションと同じアプリケーションを再実行する。ステップS34では、再ブートを行った旨を表す再ブート履歴に書き込む。なお、故障したプロセッサエレメントが既に再ブートされていた場合(ステップS31:Yes)には、ステップS22に進む。
このように、図9に示す手順では、あるプロセッサエレメントにおいて故障が検出されると、そのプロセッサエレメントを再ブートした後に、アプリケーションの実行を再開させる。この結果、故障が検出されなくなれば、いずれのアプリケーションも停止することなく継続して実行される。ただし、再ブートしてもなお故障が検出されたときは、ステップS22以降の処理が実行される。このとき、ステップS35においては、故障したプロセッサエレメントが実行していたアプリケーションを引き継ぐべきプロセッサエレメントが再ブートされ、その後、そのアプリケーションが実行される。
故障したプロセッサエレメントを再ブートした後のステップS33におけるアプリケーションの再実行としては、下記の2通りの方法が考えられる。
(1)故障したプロセッサエレメントは、再ブート前に実行していたアプリケーションを再び実行する。
(2)故障したプロセッサエレメントは、他のプロセッサエレメントにより実行されている最も優先度の低いアプリケーションを実行する。また、最も優先度の低いアプリケーションを実行していたプロセッサエレメントは、再ブート前にその故障したプロセッサエレメントにより実行されていたアプリケーションを実行する。この手順によれば、再ブートされたプロセッサエレメントにおいて再び故障が検出されたときは、そのプロセッサエレメントを切り離すだけでよく、代替動作は不要となる。
なお、実施形態のマルチプロセッサシステムにおいて、各プロセッサエレメントがアクセス可能な複数のメモリが設けられている場合には、メモリに係わる故障が検出されたプロセッサエレメントを停止させた後に、故障と判定されたメモリ以外のメモリを使用して他のプロセッサエレメントを再ブートするようにしてもよい。
なお、図9に示す実施例2の故障検出において、自己故障検出と生存監視による故障検出とをそれぞれ含む構成に限定されない。
(付記1)複数のプロセッサエレメントを備えるマルチプロセッサシステムであって、
各プロセッサエレメントにより実行される処理の優先度を管理する管理手段と、
各プロセッサエレメントの状態を監視する監視手段と、
第1の処理を実行している第1のプロセッサエレメントにおいて故障が検出されたときに、前記管理手段の処理優先度情報を参照し、前記第1の処理よりも優先度の低い第2の処理を実行している第2のプロセッサエレメントに前記第1の処理を実行させる切替え手段と、
を有するマルチプロセッサシステム。
(付記2)付記1に記載のマルチプロセッサシステムであって、
前記監視手段は、各プロセッサエレメントに設けられ、それぞれ他のプロセッサエレメントの状態を監視する
ことを特徴とするマルチプロセッサシステム。
(付記3)付記2に記載のマルチプロセッサシステムであって、
各プロセッサエレメントに設けられ、それぞれ所定の時間間隔で予め決められた規則に従って生存情報を生成し、各プロセッサエレメントが参照可能なメモリ領域にその生存情報を書き込む生存情報生成手段をさらに備え、
前記監視手段は、所定の時間間隔で前記メモリ領域を参照することによりプロセッサエレメントの状態を監視する
ことを特徴とするマルチプロセッサシステム。
(付記4)付記3に記載のマルチプロセッサシステムであって、
前記生存情報が書き込まれるメモリ領域が各プロセッサエレメント内にそれぞれ設けられる
ことを特徴とするマルチプロセッサシステム。
(付記5)付記1に記載のマルチプロセッサシステムであって、
各プロセッサエレメントに設けられ、当該プロセッサエレメントの故障を検出して他のプロセッサエレメントに申告する申告手段をさらに備え、
前記監視手段は、前記申告手段による申告に基づいてプロセッサエレメントの故障を検出する
ことを特徴とするマルチプロセッサシステム。
(付記6)付記5に記載のマルチプロセッサシステムであって、
前記申告手段により生成される申告データは、共有メモリを介することなく、プロセッサエレメント間通信パスを介して送信される
ことを特徴とするマルチプロセッサシステム。
(付記7)付記5に記載のマルチプロセッサシステムであって、
前記申告手段は、メモリのECCエラー、メモリまたはバスのパリティエラー、不正な命令の実行、不正な記憶領域のアクセスを検出したときに、プロセッサエレメントの故障を申告する
ことを特徴とするマルチプロセッサシステム。
(付記8)付記1に記載のマルチプロセッサシステムであって、
前記切替え手段は、故障が検出された第1のプロセッサエレメントを停止し、その第1のプロセッサエレメントが実行していた第1の処理を、前記第2のプロセッサエレメントに実行させる
ことを特徴とするマルチプロセッサシステム。
(付記9)付記8に記載のマルチプロセッサシステムであって、
前記第1のプロセッサエレメントの故障が検出されたときに前記第2のプロセッサエレメントにより実行されていた前記第2の処理は、動作中のプロセッサエレメントにより実行されている複数の処理の中で最も優先度が低い
ことを特徴とするマルチプロセッサシステム。
(付記10)付記1に記載のマルチプロセッサシステムであって、
前記切替え手段は、故障が検出された第1のプロセッサエレメントが実行している第1の処理よりも優先度の低い処理が存在しない場合には、その第1のプロセッサエレメントの処理を停止してその第1の処理を終了する
ことを特徴とするマルチプロセッサシステム。
(付記11)付記1に記載のマルチプロセッサシステムであって、
故障が検出された第1のプロセッサエレメントを再ブートする再ブート手段をさらに備える
ことを特徴とするマルチプロセッサシステム。
(付記12)付記11に記載のマルチプロセッサシステムであって、
前記切替え手段は、前記再ブート手段による再ブートの後に、前記第1の処理を前記第2のプロセッサエレメントに実行させるとともに、前記第2の処理を前記第1のプロセッサエレメントに実行させる
ことを特徴とするマルチプロセッサシステム。
(付記13)付記1に記載のマルチプロセッサシステムであって、
各プロセッサエレメントとメモリバスとの間、各プロセッサエレメントとプロセッサエレメント間通信パスとの間、および各プロセッサエレメントとI/Oバスとの間にそれぞれ設けられるスイッチと、
前記切替え手段からの指示に応じて前記スイッチを制御する構成制御手段をさらに備える
ことを特徴とするマルチプロセッサシステム。
(付記14)付記13に記載のマルチプロセッサシステムであって、
前記切替え手段から前記構成制御手段への指示は、前記プロセッサエレメント間通信パスを介して送信される
ことを特徴とするマルチプロセッサシステム。
(付記15)付記1に記載のマルチプロセッサシステムであって、
プロセッサエレメントの故障により停止した処理に係わる情報を表示する表示手段をさらに備える
ことを特徴とするマルチプロセッサシステム。
(付記16)付記1に記載のマルチプロセッサシステムであって、
プロセッサエレメントの故障により停止した処理に係わる情報を格納する不揮発性メモリをさらに備える
ことを特徴とするマルチプロセッサシステム。
(付記17)付記1に記載のマルチプロセッサシステムであって、
各プロセッサエレメントがアクセス可能な複数のメモリと、
メモリに係わる故障が検出されたプロセッサエレメントを停止させた後に、故障と判定されたメモリ以外のメモリを使用して他のプロセッサエレメントを再ブートする再ブート手段をさらに備える
ことを特徴とするマルチプロセッサシステム。
(付記18)付記1に記載のマルチプロセッサシステムであって、
前記監視手段および切替え手段の動作を記述したプログラムを搭載する
ことを特徴とするマルチプロセッサシステム。
(付記19)複数のプロセッサエレメントを備えるマルチプロセッサシステムにおける故障発生時の回復方法であって、
各プロセッサエレメントの状態を監視し、
第1の処理を実行している第1のプロセッサエレメントにおいて故障が検出されたときに、前記第1の処理よりも優先度の低い第2の処理を実行している第2のプロセッサエレメントに前記第1の処理を実行させる、
ことを特徴とするマルチプロセッサシステムにおける故障発生時の回復方法。
本発明の概念を説明する図である。 組込みシステムについて説明する図である。 実施形態のマルチプロセッサシステムのハードウェア構成を示す図である。 動的構成制御ユニットの実施例である。 実施形態のマルチプロセッサシステムのソフトウェア構成を示す図である。 アプリケーション優先度テーブルの実施例である。 PE状態テーブルの実施例である。 状態マネージャの処理を示すフローチャート(実施例1)である。 状態マネージャの処理を示すフローチャート(実施例2)である。
符号の説明
1A、1B プロセッサエレメント
2 記憶領域
3 PE状態テーブル
10 制御対象装置
11 マルチプロセッサシステム
13 表示装置
21 プロセッサエレメント
22 共有メモリ
23 不揮発性メモリ
24 動的構成制御ユニット
25 PE状態テーブル
26 アプリケーション優先度テーブル
27 クロスバ
29 I/Oバス
30 PE間通信パス
31〜33 スイッチ

Claims (10)

  1. 複数のプロセッサエレメントを備えるマルチプロセッサシステムであって、
    各プロセッサエレメントにより実行される処理の優先度を管理する管理手段と、
    各プロセッサエレメントの状態を監視する監視手段と、
    第1の処理を実行している第1のプロセッサエレメントにおいて故障が検出されたときに、前記管理手段の処理優先度情報を参照し、前記第1の処理よりも優先度の低い第2の処理を実行している第2のプロセッサエレメントに前記第1の処理を実行させる切替え手段と、
    を有するマルチプロセッサシステム。
  2. 請求項1に記載のマルチプロセッサシステムであって、
    前記監視手段は、各プロセッサエレメントに設けられ、それぞれ他のプロセッサエレメントの状態を監視する
    ことを特徴とするマルチプロセッサシステム。
  3. 請求項2に記載のマルチプロセッサシステムであって、
    各プロセッサエレメントに設けられ、それぞれ所定の時間間隔で予め決められた規則に従って生存情報を生成し、各プロセッサエレメントが参照可能なメモリ領域にその生存情報を書き込む生存情報生成手段をさらに備え、
    前記監視手段は、所定の時間間隔で前記メモリ領域を参照することによりプロセッサエレメントの状態を監視する
    ことを特徴とするマルチプロセッサシステム。
  4. 請求項1に記載のマルチプロセッサシステムであって、
    各プロセッサエレメントに設けられ、当該プロセッサエレメントの故障を検出して他のプロセッサエレメントに申告する申告手段をさらに備え、
    前記監視手段は、前記申告手段による申告に基づいてプロセッサエレメントの故障を検出する
    ことを特徴とするマルチプロセッサシステム。
  5. 請求項1に記載のマルチプロセッサシステムであって、
    前記切替え手段は、故障が検出された第1のプロセッサエレメントを停止し、その第1のプロセッサエレメントが実行していた第1の処理を、前記第2のプロセッサエレメントに実行させる
    ことを特徴とするマルチプロセッサシステム。
  6. 請求項5に記載のマルチプロセッサシステムであって、
    前記第1のプロセッサエレメントの故障が検出されたときに前記第2のプロセッサエレメントにより実行されていた前記第2の処理は、動作中のプロセッサエレメントにより実行されている複数の処理の中で最も優先度が低い
    ことを特徴とするマルチプロセッサシステム。
  7. 請求項1に記載のマルチプロセッサシステムであって、
    故障が検出された第1のプロセッサエレメントを再ブートする再ブート手段をさらに備える
    ことを特徴とするマルチプロセッサシステム。
  8. 請求項7に記載のマルチプロセッサシステムであって、
    前記切替え手段は、前記再ブート手段による再ブートの後に、前記第1の処理を前記第2のプロセッサエレメントに実行させるとともに、前記第2の処理を前記第1のプロセッサエレメントに実行させる
    ことを特徴とするマルチプロセッサシステム。
  9. 請求項1に記載のマルチプロセッサシステムであって、
    各プロセッサエレメントとメモリバスとの間、各プロセッサエレメントとプロセッサエレメント間通信パスとの間、および各プロセッサエレメントとI/Oバスとの間にそれぞれ設けられるスイッチと、
    前記切替え手段からの指示に応じて前記スイッチを制御する構成制御手段をさらに備える
    ことを特徴とするマルチプロセッサシステム。
  10. 複数のプロセッサエレメントを備えるマルチプロセッサシステムにおける故障発生時の回復方法であって、
    各プロセッサエレメントの状態を監視し、
    第1の処理を実行している第1のプロセッサエレメントにおいて故障が検出されたときに、前記第1の処理よりも優先度の低い第2の処理を実行している第2のプロセッサエレメントに前記第1の処理を実行させる、
    ことを特徴とするマルチプロセッサシステムにおける故障発生時の回復方法。
JP2006184874A 2006-07-04 2006-07-04 マルチプロセッサシステム Pending JP2008015704A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006184874A JP2008015704A (ja) 2006-07-04 2006-07-04 マルチプロセッサシステム
PCT/JP2007/000394 WO2008004330A1 (fr) 2006-07-04 2007-04-11 Système à processeurs multiples

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006184874A JP2008015704A (ja) 2006-07-04 2006-07-04 マルチプロセッサシステム

Publications (1)

Publication Number Publication Date
JP2008015704A true JP2008015704A (ja) 2008-01-24

Family

ID=38894305

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006184874A Pending JP2008015704A (ja) 2006-07-04 2006-07-04 マルチプロセッサシステム

Country Status (2)

Country Link
JP (1) JP2008015704A (ja)
WO (1) WO2008004330A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245372A (ja) * 2008-03-31 2009-10-22 Fujitsu Fip Corp 分散制御方法
CN101608599A (zh) * 2008-06-16 2009-12-23 诺德克斯能源有限公司 用于控制风力发电机组的方法
CN101608600A (zh) * 2008-06-16 2009-12-23 诺德克斯能源有限公司 用于控制风能发电站的方法
JP2013225208A (ja) * 2012-04-20 2013-10-31 Toyota Motor Corp 情報処理装置、情報処理方法、及びプログラム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5596322B2 (ja) * 2009-09-18 2014-09-24 エヌイーシーコンピュータテクノ株式会社 多重化サービスプロセッサ、多重化サービスプロセッサの障害処理方法、およびプログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5810258A (ja) * 1981-07-13 1983-01-20 Hitachi Ltd 計算機システムの構成制御装置
JPH05204689A (ja) * 1992-01-30 1993-08-13 Toshiba Corp 制御装置
JP3296378B2 (ja) * 1993-08-27 2002-06-24 株式会社東芝 コンピュータバックアップシステム
JP3294741B2 (ja) * 1995-08-23 2002-06-24 富士通株式会社 自己修復装置
JPH11184825A (ja) * 1997-12-19 1999-07-09 Mitsubishi Electric Corp クラスタシステム

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245372A (ja) * 2008-03-31 2009-10-22 Fujitsu Fip Corp 分散制御方法
CN101608599A (zh) * 2008-06-16 2009-12-23 诺德克斯能源有限公司 用于控制风力发电机组的方法
EP2136076A2 (de) * 2008-06-16 2009-12-23 Nordex Energy GmbH Verfahren zur Steuerung eines Windparks
CN101608600A (zh) * 2008-06-16 2009-12-23 诺德克斯能源有限公司 用于控制风能发电站的方法
EP2136076A3 (de) * 2008-06-16 2013-02-20 Nordex Energy GmbH Verfahren zur Steuerung eines Windparks
CN101608600B (zh) * 2008-06-16 2014-05-07 诺德克斯能源有限公司 用于控制风能发电站的方法
CN101608599B (zh) * 2008-06-16 2014-05-07 诺德克斯能源有限公司 用于控制风力发电机组的方法
JP2013225208A (ja) * 2012-04-20 2013-10-31 Toyota Motor Corp 情報処理装置、情報処理方法、及びプログラム
CN104246711A (zh) * 2012-04-20 2014-12-24 丰田自动车株式会社 信息处理装置、信息处理方法和存储有用于执行该信息处理方法的程序的存储介质

Also Published As

Publication number Publication date
WO2008004330A1 (fr) 2008-01-10

Similar Documents

Publication Publication Date Title
US7426657B2 (en) System and method for predictive processor failure recovery
US8713350B2 (en) Handling errors in a data processing system
US8667315B2 (en) Synchronization control apparatus, information processing apparatus, and synchronization management method for managing synchronization between a first processor and a second processor
US8839032B2 (en) Managing errors in a data processing system
JP4330547B2 (ja) 情報処理システムの制御方法、情報処理システム、情報処理システムの制御プログラム、冗長構成制御装置
US20170147422A1 (en) External software fault detection system for distributed multi-cpu architecture
US8555110B2 (en) Apparatus, method, and program configured to embed a standby unit based on an abnormality of an active unit
KR101581608B1 (ko) 프로세서 시스템
WO2018095107A1 (zh) 一种bios程序的异常处理方法及装置
JP6130520B2 (ja) 多重系システムおよび多重系システム管理方法
US20110145634A1 (en) Apparatus, a recovery method and a program thereof
JP2008015704A (ja) マルチプロセッサシステム
JP4886558B2 (ja) 情報処理装置
JP4655718B2 (ja) コンピュータシステム及びその制御方法
US10360115B2 (en) Monitoring device, fault-tolerant system, and control method
US20030177224A1 (en) Clustered/fail-over remote hardware management system
JP4867896B2 (ja) 情報処理システム
JP7212510B2 (ja) 電源管理装置、電源管理方法、及び電源管理プログラム
JP6654662B2 (ja) サーバ装置およびサーバシステム
JP2015106226A (ja) 二重化システム
CN108415788B (zh) 用于对无响应处理电路作出响应的数据处理设备和方法
JPWO2014112039A1 (ja) 情報処理装置、情報処理装置制御方法及び情報処理装置制御プログラム
JPH1078896A (ja) 産業用電子計算機
JP2002318643A (ja) 情報処理装置
JP2009252009A (ja) コンピュータ管理システム、コンピュータシステムの管理方法、及びコンピュータシステムの管理プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090319

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090428

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090901