Nothing Special   »   [go: up one dir, main page]

JP2010011093A - 分散システム - Google Patents

分散システム Download PDF

Info

Publication number
JP2010011093A
JP2010011093A JP2008168052A JP2008168052A JP2010011093A JP 2010011093 A JP2010011093 A JP 2010011093A JP 2008168052 A JP2008168052 A JP 2008168052A JP 2008168052 A JP2008168052 A JP 2008168052A JP 2010011093 A JP2010011093 A JP 2010011093A
Authority
JP
Japan
Prior art keywords
failure
node
fault
monitoring
identification
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
JP2008168052A
Other languages
English (en)
Inventor
Masahiro Matsubara
正裕 松原
Kohei Sakurai
康平 櫻井
Kotaro Shimamura
光太郎 島村
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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2008168052A priority Critical patent/JP2010011093A/ja
Priority to US12/457,329 priority patent/US20100039944A1/en
Publication of JP2010011093A publication Critical patent/JP2010011093A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/417Bus networks with decentralised control with deterministic access, e.g. token passing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40241Flexray
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/4026Bus for use in automation systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

【課題】
分散システムでは、障害を高信頼に特定し、また障害発生状況に関する認識をノード間で一致させるために、ノード間での相互監視を用いて障害特定を行う。この処理は通信サイクルに同期して実施されるが、毎通信サイクルほど頻繁に障害特定を行う必要のないシステムでは、障害特定の頻度を下げ、単位時間あたりのCPU処理負荷や通信帯域の消費を減らしたい。
【解決手段】
複数ノードがネットワークを介して接続される分散システムは、複数ノードの各々は、他ノードに対する障害監視を行う障害監視部と、ネットワークを介して、他ノードの障害を検知するためのデータを送受信する送受信部と、データに基づいて、どのノードに障害があるかを特定する障害特定部を備え、障害監視部は監視対象期間としてノード間で同期した1ないし複数の通信サイクルを取ることができる。
【選択図】図1

Description

本発明は、ネットワークにより結合された複数の装置が協調動作して、高信頼な制御を行う分散システムに関する。
近年、自動車の運転快適性や安全性の向上を目指して、機械的な結合ではなく、電子制
御により、運転者のアクセル,ステアリング,ブレーキなどの操作を車両の駆動力,操舵力,制動力発生機構などに反映させる車両制御システムの開発が行われている。建機など他の機器でも同様な電子制御の適用が進められている。これらシステムでは、機器に分散配置した複数の電子制御装置(ECU:Electronic Control Unit)がネットワークを介してデータをやり取りして協調動作を行う。この際、同一ネットワーク内のあるECUに障害が発生した際に、各ECUが障害発生箇所を正確に特定し、障害内容に応じた適切なバックアップ制御を行うことが、フェールセーフ上必要不可欠となる。上記課題を解決するために、システムを構成する各ノード(ECUなどの処理主体)がネットワーク内の他ノードの状態を監視する技術がある(特許文献1参照)。
特開2000−47894号公報
特許文献1によれば、データベースアプリケーションの稼動状態などに関する監視情報を各ノードで相互に共有するための特別なノード(共有ディスク)が必要になり、この共有ディスクが故障するとシステム内の障害ノード監視を継続することができなくなってしまう。また、共有ディスクを設けることにより、システムのコストが増加することが懸念される。
その課題を解決するために、以下のような方法が考えられる。あるノードのある項目について、各ノードが単独で障害を検出するための監視を行い、その障害監視結果を、ネットワークを通してノード間で交換し、各ノードに集約された障害監視結果から多数決などにより、最終的な障害の特定を行う。これらの処理は通信サイクルに同期して実施する。また、上記の障害監視,障害監視結果交換,障害特定の各処理を、パイプライン的に実行し、毎通信サイクルにて障害特定を可能にする。
しかしシステムによっては、毎通信サイクルでの障害特定が頻度過剰な場合もある。そこで本発明の目的は、障害監視と通信の周期を別々に設定できるようにすることで、障害監視のためのCPU(Central Processing Unit)処理負荷や通信帯域を低減し、または障害監視の周期設定の自由度を上げることができる分散システムを提供することにある。
上記課題を達成するために、本発明では複数のノードがネットワークを介して接続される分散システムにおいて、前記複数のノードの各々は、他ノードに対する障害監視を行う障害監視部と、前記ネットワークを介して、他ノードの障害を検知するためのデータを送受信する送受信部と、前記データに基づいて、どのノードに障害があるかを特定する障害特定部を備え、前記障害監視部は、監視対象期間としてノード間で同期した通信サイクルを取ることができることを特徴とするものである。
更に、本発明の分散システムにおいて、前記送受信部は、前記障害監視部の監視結果を送受信データに含め、その送受信を、前記監視結果が対象とする次の監視対象期間にて分散して行うことを特徴とするものである。
更に、本発明の分散システムにおいて、前記障害特定部は、障害特定を、前記データに含まれる前記障害監視部の監視結果が対象とする次の監視対象期間にて分散して行うことを特徴とするものである。
更に、本発明の分散システムにおいて、前記障害監視部は稼動中に、前記監視対象期間を監視対象ノードごとに可変とすることができることを特徴とするものである。
本発明によれば、障害監視のためのCPU処理負荷や通信帯域が低く、または障害監視の周期設定の自由度が高い分散システムを提供することが実現できる。
以下、本発明の一実施例を図面を用いて説明する。
図1は、分散システムの構成図である。
分散システムは、複数のノード10(10−1,10―2,…,10−n)からなり、これらは、ネットワーク100を介して接続される。ここで、ノードとは、ネットワークを介して情報通信可能な処理装置であり、CPUを含む各種の電子制御装置,アクチュエータとそのドライバ,センサ等が含まれる。ネットワーク100は多重通信可能な通信ネットワークであり、あるノードから当該ネットワークに接続された他の全てのノードに対して、同一内容を同時に送信するブロードキャスト送信が可能である。通信プロトコルとしては、FlexRayやTTCAN(time-triggered CAN)などを用いることができる。
各ノードi(iはノード番号,i=1〜n)は、CPU11−i,主メモリ12−i,I/F13−i、及び、記憶装置14−iとからなり、これらは内部通信線等により接続されている。又、I/F13−iは、ネットワーク100と接続されている。
記憶装置14−iは、障害監視部141−i,送受信処理部142−i,障害特定部143−i、及び、カウンタ部144−i等のプログラム、並びに、障害特定結果145−iを格納する。障害特定結果145−iは、後述の監視結果集約表,障害特定結果表,エラーカウンタを含む。
CPU11−iは、これらのプログラムを主メモリ12−iに読み込み、実行することにより、処理を行う。本稿で説明するプログラムやデータは、予め記憶装置に格納しておいてもよいし、CD−ROM等の記憶媒体から入力してもよいし、ネットワーク経由で他の装置からダウンロードしてもよい。又、当該プログラムにより実現される機能を、専用のハードウェアにより実現してもよい。
以下では、プログラムを主体として記載するが、実際の主体はCPUがプログラムに従って視処理している。
障害監視部141−iは、他ノードに対する障害監視(MON)を行う。送受信処理部142−iは、ネットワーク100を介して、他ノードの障害を検知するためのデータを送受信する。障害特定部143−iは、他ノードの障害を検知するためのデータに基づいて、どのノードに障害があるかの障害特定(ID)を行う。カウンタ部144−iは、障害があると特定されたノードのエラーの数を、ノード毎,エラー箇所(エラー項目)毎,後述の障害特定条件毎にカウントする。
図2は、ノード間相互監視による障害特定処理のフロー図を示す。これらの処理は、各ノードが、ネットワーク100を介して互いに通信しながら同期を取ることにより行う。
まずステップ21にて、障害監視部141−iは、他ノードに対する障害監視を行い、受信データの内容や受信時の状況から、送信ノードについての障害有無を自ノード単独で判断する障害監視処理(以下、MON)を行う。障害監視の対象項目(以下、障害監視項目)は、複数設定してもよい。例えば「受信異常」という項目では、未受信や誤り検出符号による受信データ異常を発見するなど、データ受信にエラーのあるときに異常ありとする。「通番異常」という項目では、送信ノードはアプリケーションが通信サイクル毎にインクリメントする通番を送受信データに付加し、受信ノードが通番のインクリメントを確認し、インクリメントされていないときに異常ありとする。通番は送信ノードのアプリケーション異常を確認するための番号である。「自己診断異常」という項目では、各ノードが自ノードの異常有無について自ら診断した結果(以下、自己診断結果)を、他ノードに対して送信し、受信ノードが自己診断結果から、送信ノードについての異常を検知する。これら複数の障害監視項目のうち、いずれかの項目で異常があれば、それら項目を1つに統合した障害監視項目で「異常あり」としてもよい。
障害監視処理は、p(p=1,2,3,..)通信サイクルを対象期間の1単位として実施される。p通信サイクルの障害監視期間は、ノード間で同期が取られる。同期の取り方は、あるノードが障害監視処理の開始を通信にて宣言してもよい。また、通信サイクル数から監視期間を求めてもよい。例えば最初の障害監視を通信サイクル0から開始すると決めておくならば、(通信サイクル数)÷ pで余りのない通信サイクル数のとき、各障害監視期間の始まりとわかる。障害監視処理期間を複数通信サイクルにすることで、以降の処理の頻度を低減することができ、1通信サイクルあたりの通信帯域や各ノードのCPU処理負荷を低減することができる。
次にステップ22にて、送受信処理部142−iは、ステップ21で得られた障害監視結果を、各ノード間で交換する、障害監視結果交換処理(以下、EXD)を行う。各ノードは自ノードにて出した結果を含む、全ノードからの障害監視結果を保持することになる。集約した障害監視結果は、障害特定結果145−iに監視結果集約表として持つ。
障害監視結果交換処理は、1通信サイクルで行ってもよいし、複数の通信サイクルに分けて行ってもよい。複数の通信サイクルに分けると、1通信サイクルあたりに必要な通信帯域と、各ノードのCPUによる受信データ処理負荷を低減することができる。
次にステップ23にて、障害特定部143−iは、ステップ22で各ノードに集約された障害監視結果から、各ノード・各障害監視項目について異常有無を特定する、障害特定処理(以下、ID)を行う。障害特定結果は、障害特定結果145−iに障害特定結果表として持つ。
障害特定方法の一つとして、多数決主体の方法がある。これは、異常有無の多数決を取り、あるノード・障害監視項目に対して障害を検出したノード数が、「<障害特定条件1>閾値以上ならば、被検出ノードに異常あり」と判断し、「<障害特定条件2>閾値未満ならば、障害を検出したノードに異常あり」と判断する。閾値は通常、集約された障害監視結果の半数である。
尚、障害特定条件1で障害を検出しなかったノードや、障害特定条件2の被検出ノードについては、異常なしと判断する。以下では、障害特定条件1に合致した場合には多数派異常、障害特定条件2に合致した場合には少数派異常と呼ぶ。
障害特定方法としてはこのほか、1ノードでも障害を検出したら、被検出ノード・障害監視項目について「異常あり」と判断する方法もある。
障害特定処理は、1通信サイクルのうちに行ってもよいし、複数の通信サイクルに分けて行ってもよい。複数の通信サイクルに分けると、1通信サイクルあたりの各ノードのCPU処理負荷を低減することができる。
次にステップ24にて、各ノードが障害特定結果利用処理を行う。カウンタ部144−iは、ステップ23で「異常あり」と判定された場合、障害特定の対象ノード・監視項目のエラー数を示すエラーカウンタ値をインクリメントする。逆に「異常なし」と判定された場合、当該カウンタ値をデクリメントする。尚、デクリメントに限らず、リセットしてもよいし、何もしなくてもよい。デクリメント,リセット,何もしない、の選択は事前に設定する。また、エラーカウンタは障害特定条件ごとに用意してもよい。この場合、エラーカウンタをデクリメントもしくはリセットするのは、どの障害特定条件にも合致しないときである。
そして、カウンタ部144−iは、エラー数が指定の閾値以上となった場合、障害発生の事実を制御アプリケーションに通知する。通知手段の1つには、障害特定の対象ノード・監視項目に対応するノード障害フラグを立てる方法がある。アプリケーションはノード障害フラグを参照することにより、障害発生状況を知ることができる。また、ノード障害フラグを立てた後、制御アプリケーションに対して割込みを掛けるか、コールバック関数を呼ぶことにより、通知が即座になされるようにしてもよい。エラーカウンタを障害特定条件で分けるとき、ノード障害フラグも障害特定条件で分ける。
障害特定処理を複数通信サイクルに分ける場合、障害特定結果利用処理を行う時機としては、全ての障害特定処理が終わってからでもよいし、一部の障害特定処理が終わればその結果を逐次利用してもよい。全ノードで障害発生状況に対する認識や、それに伴う状態遷移を一致させたいならば、前者を取るべきである。
以上の処理により、障害発生を高信頼に特定し、障害発生状況に関する認識をノード間で一致化させることができる。その際に、各処理を複数の通信サイクルに分散して実施することで、1通信サイクルあたりのCPU処理負荷や必要な通信帯域を抑えることができる。
そして、図2の処理を繰り返し実行する際は、各処理を並列に行ってもよい。図2の処理を1回実行する機会(以下、障害特定ラウンド)として、複数の障害特定ラウンドを平行して行うようにすればよい。
図3と図4は、4ノードのシステムにおける、図2の処理フローに基づいたノード間相互監視による障害特定の並列処理の一例である。
図3では、障害特定ラウンド1として、通信サイクルi〜i+1で障害監視(MON)を行い(r=2)、障害監視結果交換(EXD)と障害特定(ID)は通信サイクルi+2〜i+3に分散して実施している。この際、各ノードは通信サイクルi+2ではノード1〜2について、通信サイクルi+3ではノード3〜4について監視結果を交換(EXD)し、その監視結果から障害特定(ID)している。このように、図3は障害監視結果交換(EXD)と障害特定(ID)の処理を、対象ノードごとに分割し、通信サイクル間で分散している。
各ノードは障害特定ラウンド1を実施する一方で、障害特定ラウンド2以降を実施している。通信サイクルi+2〜i+3では、障害特定ラウンド1の障害監視結果交換(EXD)を実施すると同時に、障害監視結果交換(EXD)の受信データ内容やデータ受信状況から、障害特定ラウンド2の障害監視(MON)を実施している。同様に、障害特定ラウンド2の障害監視結果交換(EXD)と同時に、障害特定ラウンド3の障害監視(MON)を実施している。障害特定(ID)はその合間になされている。以下同様に、このような処理を繰り返す。障害特定(ID)結果の利用は、ノード1〜2から先に行ってもよいし、ノード3〜4の結果が出てから全ノード分を利用してもよい。
図4では、障害特定ラウンド1として、通信サイクルi〜i+1で障害監視(MON)を行い、障害監視結果交換(EXD)は通信サイクルi+2〜i+3に、障害特定(ID)は通信サイクルi+3〜i+4に分散して実施している。この際、通信サイクルi+2ではノード1〜2が、通信サイクルi+3ではノード3〜4が、障害監視(MON)結果を送信している。障害特定(ID)は、通信サイクルi+3ではノード1〜2について、通信サイクルi+4ではノード3〜4について為されている。このように、図3と異なる点は、障害監視結果交換(EXD)の処理を、送信ノードごとに分割し、通信サイクル間で分散している点である。
各ノードは障害特定ラウンド1を実施する一方で、障害特定ラウンド2以降を実施している。通信サイクルi+2〜i+3では、障害特定ラウンド1の障害監視結果交換(EXD)を実施すると同時に、障害監視結果交換(EXD)の受信データ内容やデータ受信状況から、障害特定ラウンド2の障害監視(MON)を実施している。障害特定ラウンド2と障害特定ラウンド3の関係も同様であり、以下このような処理を繰り返す。
図3や図4のように、図2のノード間相互監視による障害特定処理を、パイプライン的に実施することで、すべての時間(通信サイクル)が障害監視(MON)の対象となり、また障害特定(ID)を一定間隔で継続的に行うことができる。
図3と図4ではノード数4(n=4)を想定しているが、ノード数に制限はない。また、図3と図4では障害監視(MON)の対象期間を2通信サイクルに、障害監視結果交換(EXD)、障害特定(ID)の各処理を2通信サイクルに分けて行っているが、これらを1通信サイクルとしても、より長い通信サイクルとしてもよい。各処理に掛かる通信サイクル数を短くすれば、障害特定(ID)までに掛かる時間(通信サイクル数)は短くなるが、CPU処理負荷や消費する通信帯域が相対的に増大する。逆に各処理に掛かる通信サイクル数を長くすれば、障害特定(ID)までに掛かる時間(通信サイクル数)は長くなるが、CPU処理負荷や消費する通信帯域が相対的に減少する。
例えば、図3でノード数を6とする場合、最初の障害特定ラウンドでは通信サイクルi+2にてノード1〜3を対象に、通信サイクルi+3にてノード4〜6を対象に、障害監視結果交換(EXD)と障害特定(ID)を実施してもよい。もしくは通信サイクルi+4にてノード5〜6を対象とする障害監視結果交換(EXD)と障害特定(ID)を追加してもよい。
障害監視結果交換(EXD)と障害特定(ID)の通信サイクル間における分散(以下、時間軸処理分散)のさせ方は、各通信サイクルにてCPU処理負荷や通信量が均等になるようにするのが、CPU処理能力や通信帯域といったリソースの面から制御アプリケーションに対する影響が相対的に小さくなり、好ましいと考えられる。図3と図4は、このような均等な分散の一例である。
時間軸処理分散のさせ方として、図3と図4では障害監視対象ノードごと、障害特定対象ノードごと、送信ノードごと、などのように分けているが、各ノードが各通信サイクルにて処理の一部ずつを行うのであれば、どのような分け方をしてもよい。例えば図4にて、各ノードは通信サイクルi+2にてノード1とノード2から受信する障害監視結果から、多数決を取るための集計を行うなど、障害特定(ID)の一部を行い、通信サイクルi+3にてノード3とノード4から受信する障害監視結果から、障害特定(ID)の残りの処理を行い、障害特定処理を完了させてもよい。このようにすれば、障害特定処理の完了までに掛かる通信サイクル数が、図4より1つ短くなる。
図5は、ノード間相互監視による障害特定処理の動作例を示す。処理フローは図2に基づき、時間軸処理分散や処理パイプライン化は、図3に則っており、ノード数は4とする。ここでは、障害監視項目として各種の項目を1つに統合している。尚、障害特定処理(ID)は、各ノードの送受信終了後、通信サイクルの最後に行われるものとする。
送信データは、1監視対象ノードについて異常有無を示すビットを2ノード分持つ。但し、自ノード分の領域には、自ノードについての診断結果が入っている。偶数サイクルではノード1〜2について、奇数サイクルではノード3〜4についての異常有無が入るとする。
また送信データには、各ノードが持つエラーカウンタの値が1ノード分入る。通信サイクルi〜i+1ではノード1がノード2について、ノード2がノード3について、ノード3がノード4について、ノード4がノード1についてのエラーカウンタ値を送信している。これが通信サイクルi+2〜i+3ではノード1がノード4について、ノード2がノード1について、ノード3がノード2について、ノード4がノード2についてのエラーカウンタ値を送信するようになり、対象ノードをローテーションさせている。また、エラーカウンタは多数派異常と少数派異常とで分かれており、偶数サイクルでは多数派異常数(EC)が、奇数サイクルでは少数派異常数(FC)が送信されている。
エラーカウンタ値を受信したノードは、障害特定結果利用処理において、障害特定(ID)の結果をエラーカウンタに反映する前に、受信したエラーカウンタ値を利用して、エラーカウンタのノード間同期を取る。これは、ノード間相互監視による障害特定処理を行っても、ノード間でエラーカウンタ値がずれてしまう場合があるためである。その理由は、自ノード診断によるリセットや、一時的な通信不能などによる。エラーカウンタ同期の方法は例えば、受信したカウンタ値が自ノードの持つカウンタ値と異なっており、連続して受信した2つのカウンタ値の差が一定値(例えば±1)以内であれば、後に受信したカウンタ値に自ノードのカウンタ値を合わせる、とすればよい。
送信データは内容の一部のみが表示されている。送信データは上記データのほかに、通番や制御データなど含みうる。
通信サイクルi(iは偶数とする)では、ノード1〜4は順にスロット1〜4にて、障害特定ラウンドk−1のノード1〜2に関する障害監視結果を送信し(EXD,501−0〜504−0)、他ノードから受信した分と自ノードで出した結果とを保持する(521−0〜524−0、2進数表示)。その中には「異常あり」とするデータがなく、各ノードも正常受信をしているため、障害特定ラウンドk−1のノード1〜2に関する障害特定(ID)では異常は見つからず、ノード障害フラグはどのノードについても立っていない(551−0〜554−0、2進数表示)。また、各ノードは障害特定ラウンドkの障害監視(MON)にて障害を検出していない(511−0〜514−0、2進数表示)。各ノードのエラーカウンタ値は、ノード3の多数派異常について2であり、それ以外は0となっており、通信サイクルi−1から変化がない(541−0〜544−0)。
ただし、通信サイクルiの終わりにて、ノード3がCPU障害を起こしている。これにより、ノード3が次の通信サイクルi+1にて送信する通番をインクリメントできない障害が発生したとする(通番は図のデータには表記されていない)。
通信サイクルi+1では、障害特定ラウンドk−1のノード3〜4に関する障害監視結果を送信し(501−1〜504−1)、各ノードが保持する(521−1〜524−1)。通信サイクルiと同様に、障害特定ラウンドk−1のノード3〜4に関する障害特定(ID)では異常は見つからず、エラーカウンタ(541−0〜544−0)とノード障害フラグ(551−1〜554−1)は通信サイクルiと変わらない。しかし、障害特定ラウンドkのノード3〜4に関する障害監視(MON)にて、ノード1,2,4はノード3の通番異常から、ノード3について障害を検出する(511−1,512−1,514−1)。ノード3は自ノードの異常を検出できない(513−1)。
通信サイクルi+2ではノード1〜2に関して、通信サイクルi+3ではノード3〜4に関して、それぞれ障害特定ラウンドkの障害特定結果交換(EXD)と障害特定(ID)、および障害特定ラウンドk+1の障害特定(MON)がなされる。通信サイクルi+2では、通信サイクルiと同様に異常は検出されない。それに対し通信サイクルi+3では、障害特定ラウンドkの障害特定結果交換(EXD)で、通信サイクルi+1におけるノード3の障害検出が交換され(501−3〜504−3,521−3〜524−3)、各ノードの障害特定(ID)にてノード3の多数派異常が特定される(531−3〜534−3)。これにより、各ノードが持つノード3の多数派異常に関するエラーカウンタ値がインクリメントされ、3になる(541−3〜544−3)。このシステムでは、障害のアプリケーション通知の閾値を3としており、各ノードが持つノード3の多数派異常に関するノード障害通知フラグが立つ(551−3〜554−3)。
以上により、各ノードにてノード3のCPU障害が特定され、対応するノード障害フラグによりアプリケーションに通知されることが分かる。このように、図2のノード間相互監視による障害特定処理は、通信サイクルに同期してパイプライン的に実行することが可能であり、また時間軸処理分散により、通信サイクルあたりのCPU処理負荷や通信量は、時間軸処理分散をしないときより減少していることがわかる。上記では多数派異常を扱ったが、少数派異常についても同様である。
図6は、ノード間相互監視による障害特定処理のフロー図を示す。
ステップ21の障害監視処理(MON)とステップ22の障害監視結果交換処理(図6ではEXD1とする)の内容は、図2と同様である。
次にステップ61にて、障害特定部142−iは、相互監視に参加しているノードのうち、自ノード以外の1つを自ノードが障害特定の責任を持つノードとして、障害特定処理(以下、ID1)を行う。対象とするノードは、各ノードで重複がないようにし、通信サイクル毎にローテーションする。これにより、障害特定処理の負荷をノード間で分散して低減する。
次にステップ62にて、送受信処理部142−iは、ステップ61で得られた1ノードについての障害特定結果を、各ノード間で交換する、障害特定結果交換処理(EXD2)を行う。これにより各ノードは、自ノードによる処理分を含む全ノードについての障害特定結果を保持することになる。この集約された障害特定結果を利用して、ステップ63では障害特定処理(ID2)として、最終的な障害特定結果の確定を行う。
次のステップ24は、図2の障害特定結果利用処理と同様である。
尚、障害特定条件1による判定は1ノードを対象に障害特定処理(ID1)にて行い、障害特定条件2による判定は全ノードを対象に障害特定処理(ID2)にて行えばよい。もしくは、障害特定処理(ID2)では1ノードを対象に障害特定条件2による判定を行い、その結果をノード間で交換(障害特定結果交換処理、EXD3)してもよい。
また、障害特定処理(ID1)で対象とするノードは1つに限定せず、2つ以上でもよい。
図7と図8は、4ノードのシステムにおける、図6の処理フローに基づいたノード間相互監視による障害特定の並列処理の一例である。
図7では、障害特定ラウンド1として、通信サイクルi〜i+1で障害監視(MON)を行い、障害監視結果交換(EXD1)と障害特定(ID1)は通信サイクルi+2〜i+3に、障害特定結果交換(EXD2)と障害特定(ID2)は通信サイクルi+4〜i+5に分散して実施している。この際、各ノードは通信サイクルi+2ではノード1〜2について、通信サイクルi+3ではノード3〜4について監視結果交換(EXD1)と障害特定(ID1)をしている。また、各ノードは通信サイクルi+4では全ノードについて障害特定結果交換(EXD2)と障害特定(ID2)をしている。このように、図7は障害監視結果交換(EXD1),障害特定(ID1)の各処理を、対象ノードごとに分割して、通信サイクル間で分散している。
各ノードは障害特定ラウンド1を実施する一方で、障害特定ラウンド2以降を実施している。通信サイクルi+2〜i+3では、障害特定ラウンド1の障害監視結果交換(EXD1)を実施すると同時に、その受信データ内容やデータ受信状況から、障害特定ラウンド2の障害監視(MON)を実施している。また通信サイクルi+4では、障害特定ラウンド1の障害特定結果交換(EXD2)を実施すると同時に、障害特定ラウンド2のノード1〜2に関する障害監視結果交換(EXD1)を行い、その受信データ内容やデータ受信状況から、障害特定ラウンド3の障害監視(MON)をも実施している。障害特定ラウンド2以降の関係も同様であり、以下このような処理を繰り返す。
図8では、障害特定ラウンド1として、通信サイクルi〜i+1で障害監視(MON)を行い、障害監視結果交換(EXD1)と障害特定(ID1)は通信サイクルi+2〜i+3に、障害特定結果交換(EXD2)と障害特定(ID2)は通信サイクルi+4〜i+5に分散して実施している。この際、各ノードは通信サイクルi+2と通信サイクルi+3では監視結果交換(EXD1)と障害特定(ID1)の処理をそれぞれ半々行っている。半々とは、通信サイクルi+2で監視結果交換(EXD1)では障害監視結果の半分を送信し、障害特定(ID1)では多数決など障害特定のために行う障害監視結果の集計などの処理を、監視結果交換(EXD1)で得たデータ分だけ途中まで進める。そして、通信サイクルi+3で残りの処理を行う。また、各ノードは通信サイクルi+4では多数派異常について、通信サイクルi+5では少数派異常について、障害特定結果交換(EXD2)と障害特定(ID2)をしている。このようにして、図7は障害監視結果交換(EXD1),障害特定結果交換(EXD2),障害特定(ID1,ID2)の各処理を、通信サイクル間で分散している。
各ノードは障害特定ラウンド1を実施する一方で、障害特定ラウンド2以降を実施している。通信サイクルi+2〜i+3では、障害特定ラウンド1の障害監視結果交換(EXD1)を実施すると同時に、障害特定ラウンド2の障害監視(MON)を実施している。また通信サイクルi+4〜i+5では、障害特定ラウンド1の障害特定結果交換(EXD2)を実施すると同時に、障害特定ラウンド2の障害監視結果交換(EXD1)を行い、さらに障害特定ラウンド3の障害監視(MON)をも実施している。障害特定ラウンド2以降の関係も同様であり、以下このような処理を繰り返す。
図9−1及び図9−2は、ノード間相互監視による障害特定処理の動作例を示す。処理フローは図6に基づき、時間軸処理分散や処理パイプライン化は、図8に則っている。ノード数や障害監視項目などの諸条件は図5と同じである。
また障害特定(ID1)結果は、エラーカウンタ値に反映して、すなわち障害特定(ID1)結果に応じて増減して送信され、エラーカウンタ同期のためのカウンタ値送信と兼ねて、障害特定結果交換(EXD2)としている。エラーカウンタ値を受信したノードは、エラーカウンタの同期方法として例えば、(1)受信したカウンタ値と自ノードの持つカウンタ値との差が一定値(例えば±1)であるとき、受信したカウンタ値に、(2)前記条件((1))に合致せず、連続して受信した2つのカウンタ値の差が一定値(例えば±1)であれば、後に受信したカウンタ値に、自ノードのカウンタ値を合わせるとすればよい。
もちろん、このように障害特定(ID1)結果をエラーカウンタ値に反映するということをせず、送信データに障害特定(ID1)結果専用の領域を設けても良い。
通信サイクルi〜i+1(iは偶数とする)では、ノード1〜4は順にスロット1〜4にて、障害特定ラウンドk−1の障害監視結果を送信し(EXD1,901−0〜904−0,901−1〜904−1)、他ノードから受信した分と自ノードで出した結果とを保持する(921−0〜924−0,921−1〜924−1)。通信サイクルiでは、ノード1〜2はノード1〜2について、ノード3〜4はノード3〜4についての障害監視結果を送信し、通信サイクルi+1では各ノードそれぞれの残りのデータを送信している。その中には「異常あり」とするデータがなく、各ノードも正常受信をしているため、通信サイクルi〜i+1で分割して実施され、通信サイクルi+1で結果が得られる障害特定ラウンドk−1に関する障害特定(ID)では異常は見つからず(931−1〜934−1、括弧内の数値は担当ノード番号)、ノード障害フラグはどのノードについても立っていない(951−0〜954−0,951−1〜954−1)。障害特定ラウンドk−2の障害特定結果交換(EXD2)と障害特定(ID2)も実施されるが、各ノードのエラーカウンタ値は、ノード3の多数派異常について2、それ以外は0となっており、通信サイクルi−1から変化がない(941−0〜944−0,941−1〜944−1)。
また、障害特定ラウンドk−1の障害監視結果交換(EXD1)と平行して行われる障害特定ラウンドkの障害監視(MON)にて、各ノードは通信サイクルiでは障害を検出していない(911−0〜914−0)が、通信サイクルiの終わりにおけるノード3のCPU障害により、ノード3は通番異常を来たし、通信サイクルi+1にてノード1,2,4がノード3について障害を検出する(911−1〜914−1)。
通信サイクルi+2〜i+3では、障害特定ラウンドkの障害監視結果交換(EXD1,901−2〜904−2,901−3〜904−3)を障害特定ラウンドk−1と同様に行う。これにより、通信サイクルi+1でのノード3の障害検出を含む障害監視結果が各ノードに集約される(921−2〜924−2,921−3〜924−3)。障害特定ラウンドkの障害特定(ID1)も障害特定ラウンドk−1と同様に行われ、通信サイクルi+3にてノード3の多数派異常を、ノード3を担当しているノード1が特定する(931−3〜934−3)。一方、平行して行われる障害特定ラウンドk+1の障害監視(MON)では、どのノードでも障害は検出されていない(911−2〜914−2,911−3〜914−3)。また、障害特定ラウンドk−1の障害特定結果交換(EXD2),障害特定(ID2)も平行して行われるが、エラーカウンタ(941−2〜944−2,941−3〜944−3)やノード障害フラグ(951−2〜954−2,951−3〜954−3)に変化はない。
通信サイクルi+4〜i+5では、障害特定ラウンドk+2の障害監視(MON)や障害特定ラウンドk+1の障害監視結果交換(EXD1)と平行して、障害特定ラウンドkの障害特定結果交換(EXD2)、障害特定(ID2)が為される。これにより、ノード1によるノード3の多数派異常特定が他ノードに送信され(901−4)、各ノードがノード3の多数派異常を認識し、通信サイクルi+5にて対応するエラーカウンタ値をインクリメントして3とする(941−5〜944−5)。これにより、各ノードにてノード3の多数派異常に対応するノード障害フラグが立つ(951−5〜954−5)。
以上により、各ノードにてノード3のCPU障害が特定され、対応するノード障害フラグによりアプリケーションに通知されることが分かる。このように、図6のノード間相互監視による障害特定処理は、通信サイクルに同期してパイプライン的に実行することが可能であり、また時間軸処理分散により、通信サイクルあたりのCPU処理負荷や通信量は、時間軸処理分散をしないときより減少していることがわかる。上記では多数派異常を扱ったが、少数派異常についても同様である。
上記では、障害監視処理(MON)の対象期間(通信サイクル)や、障害監視結果交換(EXD,EXD1)、障害特定(ID,ID1,ID2)を分割して実行する期間(通信サイクル)は一定であったが、これらの期間をシステム稼動中に変更することもできる。言い換えると、相互監視による障害特定の実行周期を可変とすることもできる。
図10と図11は、図3の相互監視による障害特定の並列処理について、システム稼動中に障害監視処理(MON)、障害監視結果交換(EXD)、障害特定処理(ID)の実行周期を途中で変更する一例である。
障害特定の実行周期変更の仕方の1つとして、あるノードにて障害が発生している場合に、そのノードに対する障害特定に係る各処理の実行周期を短くするという方法を挙げることができる。障害が発生しているノードは、短周期で障害特定を行わなければならないという考えに基づく。実行周期変更の判断材料としては、エラーカウンタ値が指定値以上になること、を利用することができる。エラーカウンタは同期手段が提供されているので、実行周期変更のタイミングをノード間で一致化させることができるからである。
図10は、ノード1の障害特定周期を変更する例である。通信サイクルi〜i+3までは図3と同じである。しかし、通信サイクルi+2のノード1に対する障害特定(ID)にて、ノード1のエラーカウンタ値が指定値以上となり、ノード1に対する障害特定の実行周期を従来の2から1に短縮することに決定したとする。すると、通信サイクルi+4以降は、ノード1に対する障害監視(MON)の対象期間(通信サイクル)を1に短縮し、ノード1についての障害監視結果交換(EXD)と障害特定(ID)も障害監視(MON)の次の1サイクルにて実行されるようになる。この際も、ノード1についての障害監視結果交換(EXD)は、全ノードについての障害監視(MON)と平行して実施されることになる。このように、ノード1についての障害特定(ID)は毎サイクルにてパイプライン的になされることになる。
図11は、ノード3の障害特定周期を変更する例である。通信サイクルi〜i+3までは図3と同じである。しかし、通信サイクルi+3のノード3に対する障害特定(ID)にて、ノード3のエラーカウンタ値が指定値以上となり、ノード3に対する障害特定の実行周期を従来の2から1に短縮することに決定したとする。すると、通信サイクルi+4以降は、ノード3に対する障害監視(MON)の対象期間(通信サイクル)を1に短縮し、ノード3についての障害監視結果交換(EXD)と障害特定(ID)も障害監視(MON)の次の1サイクルにて実行されるようになる。また、通信サイクルi+2〜i+3におけるノード3についての障害監視(MON)に対応する障害監視結果交換(EXD)と障害特定(ID)は、実行周期短縮前には通信サイクルi+5にて実施される予定だったのが、繰り上がって通信サイクルi+4にて実施される。代わりに通信サイクルi+5では、通信サイクルi+4におけるノード3についての障害監視(MON)に対応する障害監視結果交換(EXD)と障害特定(ID)が実施される。通信サイクルi+6以降は、同様に1つ前の通信サイクル分の障害監視(MON)に対応する障害監視結果交換(EXD)と障害特定(ID)が実施され、ノード3については毎サイクルにて障害特定(ID)がなされることになる。
障害監視結果交換(EXD)が3サイクル以上に渡る場合でも、障害特定の実行周期変更の際には図11と同様に、障害監視結果交換(EXD)や障害特定(ID)の各処理が繰り上がって実施される。
図10と図11においては、エラーカウンタ値のノード間同期が通信障害等により為されず、一部ノードで障害特定の実行周期変更がなされなくても、障害特定に係る各処理には実行周期変更前後で実効性で大きな差異がない。実行周期変更がなされず、障害監視結果を従来より短周期で送信できていないノードについては、上記の障害特定方法では異常ありと判定されることがないためである。また、当該ノードのエラーカウンタ値が他ノードとずれることがあっても、エラーカウンタ同期手段により、数通信サイクルのうちにエラーカウンタ値の同期が取れるためである。
図12−1及び図12−2は、ノード間相互監視による障害特定処理の動作例を示す。処理フローは図2に基づき、時間軸処理分散や処理パイプライン化は、図11に則っている。障害監視項目などの諸条件は図5と同じであるが、送信データにて障害監視結果のビットはノード1〜4まで毎サイクル備えている点が異なる。ただし、障害監視結果を利用するか否かは、障害特定の実行周期に依存しており、必ず利用して障害特定(ID)を行う、というわけではない。
通信サイクルi〜i+3までは、図5と同じほぼ同じ内容である。異なるのは、ノード3の多数派異常に関するエラーカウンタ値の初期値が、全ノードで0であり(1241−0〜1244−0,1241−1〜1244−1,1241−2〜1244−2)、通信サイクルi+3にてノード3の多数派異常が各ノードで特定される(1231−3〜1234−3)と、それに対応するエラーカウンタ値が1にインクリメントされる(1241−3〜1244−3)点である。また、通信サイクルi+1〜i+3にてノード3はCPU異常を来たしており、これらがノード3の通番異常を招いている。これにより、通信サイクルi+2〜i+4でも障害監視(MON)でノード3の障害をノード1,2,4が検出している(1211−2〜1214−2,1211−3〜1214−3,1211−4〜1214−4)。
通信サイクルi+3にて、ノード3の多数派異常に関するエラーカウンタ値が1になると、各ノードで、ノード3に対する障害特定周期が2から1に変更される。これに伴い、通信サイクルi+2〜i+3にて検出されたノード3の障害(両通信サイクルでORが取られ、1つの障害と見なされる)(1211−2〜1214−2,1211−3〜1214−3)は、通信サイクルi+4での障害監視結果交換(EXD)に、通信サイクルi+4にて検出されたノード3の障害(1211−4〜1214−4)は、通信サイクルi+5での障害監視結果交換(EXD)に利用される。通信サイクルi〜i+1の障害特定ラウンドを1とすると、通信サイクルi+2〜i+3からはラウンド2、通信サイクルi+4からはラウンド3となり、それぞれの障害特定(ID)が通信サイクルi+3(1231−3〜1234−3),i+4(1231−4〜1234−4),i+5(1231−5〜1234−5)でなされ、各ノードのノード3の多数派異常に対応するエラーカウンタ値をインクリメントし(1241−3〜1244−3,1241−4〜1244−4,1241−5〜1244−5)、通信サイクルi+5にてカウンタ値が3となって、ノード3の多数派異常に対応するノード障害フラグが立つ(1245−1〜1245−5)。
以上により、各ノードにてノード3のCPU障害が特定され、対応するノード障害フラグによりアプリケーションに通知されることが分かる。このように、図2のノード間相互監視による障害特定処理は、障害特定の実行周期をシステム稼動中に変更することが可能であることわかる。上記では図2のフローと、多数派異常を扱ったが、図6のフローや少数派異常についても同様である。
分散システムを応用した制御システムは、自動車や建機、FA(Factory Automation)などの幅広い工業分野で活用されており、それらの分散型制御システムに本発明を適用することで、システムの信頼性を高く維持しつつ、かつ、バックアップ制御により可用性を高めることができる。
また、本発明は特別な装置の追加を行うことなく、低コストに制御システムを実施できる。
分散システムの構成図。
ノード間相互監視による障害特定処理のフロー図。 障害特定処理のパイプライン的処理例。 障害特定処理のパイプライン的処理例。 障害特定処理の動作例。 障害特定処理をノード間で分散した障害特定処理のフロー図。 障害特定処理をノード間で分散したパイプライン的処理例。 障害特定処理をノード間で分散したパイプライン的処理例。 障害特定処理の動作例。 障害特定処理の動作例。 実行周期可変な障害特定処理のパイプライン的処理例。 実行周期可変な障害特定処理のパイプライン的処理例。 実行周期可変な障害特定処理の動作例。 実行周期可変な障害特定処理の動作例。
符号の説明
10 ノード
11 CPU
12 メインメモリ
13 I/F
14 記憶装置
100 ネットワーク

Claims (4)

  1. 複数のノードがネットワークを介して接続される分散システムにおいて、
    前記複数のノードの各々は、
    他ノードに対する障害監視を行う障害監視部と、
    前記ネットワークを介して、他ノードの障害を検知するためのデータを送受信する送受信部と、
    前記データに基づいて、どのノードに障害があるかを特定する障害特定部を備え、
    前記障害監視部は、監視対象期間としてノード間で同期した通信サイクルを取ることができること特徴とする分散システム。
  2. 請求項1の分散システムにおいて、
    前記送受信部は、前記障害監視部の監視結果を送受信データに含め、その送受信を、前期監視結果が対象とする次の監視対象期間にて分散して行うことを特徴とする分散システム。
  3. 請求項1の分散システムにおいて、
    前記障害特定部は、障害特定を、前記データに含まれる前記障害監視部の監視結果が対象とする次の監視対象期間にて分散して行うことを特徴とする分散システム。
  4. 請求項1の分散システムにおいて、前記障害監視部は稼動中に、前記監視対象期間を監視対象ノードごとに可変とすることができることを特徴とする分散システム。
JP2008168052A 2008-06-27 2008-06-27 分散システム Pending JP2010011093A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008168052A JP2010011093A (ja) 2008-06-27 2008-06-27 分散システム
US12/457,329 US20100039944A1 (en) 2008-06-27 2009-06-08 Distributed system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008168052A JP2010011093A (ja) 2008-06-27 2008-06-27 分散システム

Publications (1)

Publication Number Publication Date
JP2010011093A true JP2010011093A (ja) 2010-01-14

Family

ID=41591044

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008168052A Pending JP2010011093A (ja) 2008-06-27 2008-06-27 分散システム

Country Status (2)

Country Link
US (1) US20100039944A1 (ja)
JP (1) JP2010011093A (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015026230A (ja) * 2013-07-26 2015-02-05 Necエンジニアリング株式会社 通信システム及び通信装置、並びにファームウェア稼動異常復旧制御方法
JP2016148271A (ja) * 2015-02-12 2016-08-18 いすゞ自動車株式会社 車両用の制御装置及び車両の自己診断方法
JP2017034324A (ja) * 2015-07-29 2017-02-09 株式会社日立製作所 分散型制御装置
WO2023281595A1 (ja) * 2021-07-05 2023-01-12 日本電信電話株式会社 障害推定装置、方法およびプログラム

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014058210A (ja) * 2012-09-18 2014-04-03 Hitachi Automotive Systems Ltd 車両制御装置および車両制御システム
US8953436B2 (en) * 2012-09-20 2015-02-10 Broadcom Corporation Automotive neural network
JP6196150B2 (ja) * 2013-12-26 2017-09-13 株式会社東芝 無線通信装置、無線通信システム、及び無線通信方法
WO2017023259A1 (en) * 2015-07-31 2017-02-09 AppDynamics, Inc. Quorum based distributed anomaly detection and repair
CN116449809B (zh) * 2023-06-16 2023-09-05 成都瀚辰光翼生物工程有限公司 一种故障处理方法、装置、电子设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005047488A (ja) * 2003-07-16 2005-02-24 Denso Corp 車両用制御装置
JP2007126127A (ja) * 2005-10-03 2007-05-24 Hitachi Ltd 車両制御システム
JP2007158534A (ja) * 2005-12-01 2007-06-21 Toyota Motor Corp 通信システム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4342083A (en) * 1980-02-05 1982-07-27 The Bendix Corporation Communication system for a multiple-computer system
DE3229411A1 (de) * 1981-08-06 1983-03-03 Nissan Motor Co., Ltd., Yokohama, Kanagawa Elektronische vorrichtung mit selbstueberwachung fuer ein kraftfahrzeug
US4805107A (en) * 1987-04-15 1989-02-14 Allied-Signal Inc. Task scheduler for a fault tolerant multiple node processing system
US5959969A (en) * 1997-08-13 1999-09-28 Mci Communications Corporation Method for initiating a distributed restoration process
JP4457581B2 (ja) * 2003-05-28 2010-04-28 日本電気株式会社 耐障害システム、プログラム並列実行方法、耐障害システムの障害検出装置およびプログラム
WO2008036921A2 (en) * 2006-09-21 2008-03-27 Impact Technologies, Llc Systems and methods for predicting failure of electronic systems and assessing level of degradation and remaining useful life
US8156219B2 (en) * 2007-08-03 2012-04-10 At&T Intellectual Property I, L.P. System and method of health monitoring and fault monitoring in a network system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005047488A (ja) * 2003-07-16 2005-02-24 Denso Corp 車両用制御装置
JP2007126127A (ja) * 2005-10-03 2007-05-24 Hitachi Ltd 車両制御システム
JP2007158534A (ja) * 2005-12-01 2007-06-21 Toyota Motor Corp 通信システム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015026230A (ja) * 2013-07-26 2015-02-05 Necエンジニアリング株式会社 通信システム及び通信装置、並びにファームウェア稼動異常復旧制御方法
JP2016148271A (ja) * 2015-02-12 2016-08-18 いすゞ自動車株式会社 車両用の制御装置及び車両の自己診断方法
JP2017034324A (ja) * 2015-07-29 2017-02-09 株式会社日立製作所 分散型制御装置
WO2023281595A1 (ja) * 2021-07-05 2023-01-12 日本電信電話株式会社 障害推定装置、方法およびプログラム

Also Published As

Publication number Publication date
US20100039944A1 (en) 2010-02-18

Similar Documents

Publication Publication Date Title
JP2010011093A (ja) 分散システム
JP4871687B2 (ja) 車両制御システム
US7372859B2 (en) Self-checking pair on a braided ring network
US7246186B2 (en) Mobius time-triggered communication
US20060253726A1 (en) Fault-tolerant architecture for a distributed control system
US20090040934A1 (en) Distributed System
Kimm et al. Integrated fault tolerant system for automotive bus networks
JP5303617B2 (ja) 車両制御システム
JP2020021341A (ja) 冗長化システム
US8041993B2 (en) Distributed control system
US6145008A (en) Conflict free time-triggered method and apparatus for the transmission of messages in a distributed real-time computer system
US9952919B2 (en) Semantic deduplication
US9323629B2 (en) Method for managing path failures of OSEK networks
JP6745106B2 (ja) ゲートウェイ装置およびセンサネットワークシステム
JP2007299120A (ja) 二重化プログラマブルコントローラの等値化方式
Shaheen et al. A comparison of emerging time-triggered protocols for automotive X-by-wire control networks
JP2008022078A (ja) 通信ネットワークシステム及びそのスタートアップ方法
JP2008512021A (ja) 2つの通信コントローラを使用する分散通信システムおよびそのような通信システムを動作させる方法
CN101729349A (zh) 一种基于rrpp的主环通道连通性检测方法及装置
Hall et al. FlexRay BRAIN fusion a FlexRay-based braided ring availability integrity network
GB2377024A (en) Fault tolerant measurment data outputting system
JP6402428B2 (ja) 多重通信装置
US11652663B1 (en) Controller area network braided ring
CN110661663B (zh) 一种接口状态同步方法及装置
Driscoll et al. Maximizing fault tolerance in a low-s WaP data network

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100325

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100630

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100706

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20101102