(57)【要約】【課題】ＥＣＵに出力故障が生じた場合に、限られたリソースにて低コストで、その出力故障に対応した負荷の駆動をバックアップできるようにすることを目的とする。【解決手段】リカバリーＥＣＵ１５は、各ＥＣＵ２０，３０，４０，…に出力故障が生じた場合にその出力故障が生じた駆動対象の駆動を代行する。リカバリーＥＣＵ１５は、複数の駆動段毎に個別に汎用出力ドライバを備えておらず、駆動方式毎に共通の１つの汎用出力ドライバを備えている。各汎用出力ドライバからの駆動出力は、対応するチャンネル切替部により選択された何れか１つの駆動段に対して出力される。各ＥＣＵ２０，３０，４０，…は、出力故障が生じると、故障通知用フレームを送出する。制御部１７は、故障通知用フレームを受信すると、代行駆動すべき駆動段を判断し、動作させるべき汎用出力ドライバの選定、及びこれに対応したチャンネル切替部の制御を行う。【選択図】図１
2011213210.tif 000002
【特許請求の範囲】
【請求項１】
駆動方式の異なる一又は複数の駆動対象を駆動する電子制御装置である正規駆動用電子制御装置が、複数、通信線を介して相互にデータ通信可能に構成された制御システムにおいて、
前記通信線には、更に、前記駆動対象の駆動を前記電子制御装置に代わって行うことが可能に構成された電子制御装置である代行駆動用電子制御装置が接続され、該代行駆動用電子制御装置と前記各電子制御装置との間で前記通信線を介して相互にデータ通信可能に構成されており、
前記正規駆動用電子制御装置は、
前記駆動対象毎に、該各駆動対象を駆動するための駆動出力を該各駆動対象に対して行う駆動手段と、
前記駆動手段による前記駆動出力が正常に行われない故障状態であるか否かを前記駆動対象毎に判断可能な故障判断手段と、
前記故障判断手段により何れかの前記駆動対象について前記故障状態であると判断された場合にその旨の情報である故障情報を通信線へ送出する故障情報出力手段と、
を備え、
前記代行駆動用電子制御装置は、
前記各正規駆動用電子制御装置の前記各駆動対象のうち、前記駆動方式が同一のものを１つの共通仕様グループとして、該共通仕様グループ毎に該共通仕様グループの前記駆動対象の数よりも少ない数だけ設けられ、該共通仕様グループの前記駆動対象へ前記駆動出力を行うことが可能な駆動出力手段と、
前記各駆動出力手段からの駆動出力の出力先を、対応する前記共通仕様グループにおける前記駆動対象の何れかに選択的に切り替える出力切替手段と、
前記通信線を介して前記正規駆動用電子制御装置からの前記故障情報を受信する受信手段と、
前記受信手段により前記故障情報が受信された場合に、該故障情報に基づいて、前記故障状態である前記駆動対象及びその駆動方式を判断し、該判断した駆動方式に対応したものであって且つ該駆動対象へ前記駆動出力を行うことが可能な前記駆動出力手段に対して前記駆動出力を行わせると共に、該駆動出力が前記故障状態である前記駆動対象へ出力されるように前記出力切替手段を制御する、駆動出力制御手段と、
を備えていることを特徴とする制御システム。
【請求項２】
請求項１に記載の制御システムであって、
前記正規駆動用電子制御装置は、
前記駆動対象毎に、該駆動対象が前記故障状態となった場合に該駆動対象を前記代行駆動用電子制御装置によって駆動させるべき優先度を示す優先度情報が設定されており、
前記故障情報出力手段は、前記故障状態の前記駆動対象に対して設定されている前記優先度情報を含む前記故障情報を送出するよう構成されており、
前記代行駆動用電子制御装置は、
同一の駆動方式である前記駆動対象に対応した前記故障情報を、該駆動方式に対応した前記駆動出力手段の数よりも多く受信した場合に、該各故障情報に含まれている前記優先度情報を比較して前記各駆動対象の優先度を判断する第１優先度判断手段を備え、
前記駆動出力制御手段は、前記第１優先度判断手段による判断結果に基づき、前記優先度が高い前記駆動対象に対して優先的に前記駆動出力が行われるよう、対応する前記駆動出力手段から前記駆動出力を行わせると共に前記出力切替手段を制御する
ことを特徴とする制御システム。
【請求項３】
請求項２に記載の制御システムであって、
前記正規駆動用電子制御装置は、
前記駆動対象の動作に関連した情報である関連情報が入力される関連情報入力手段を備え、
１つの前記駆動対象に対し、前記関連情報の内容に応じて前記優先度の異なる複数の前記優先度情報が設定されている
ことを特徴とする制御システム。
【請求項４】
請求項２に記載の制御システムであって、
前記正規駆動用電子制御装置は、
前記駆動対象の動作に関連した情報である関連情報が入力される関連情報入力手段を備え、
前記故障情報出力手段は、前記故障状態の前記駆動対象に対応した前記関連情報を含む前記故障情報を送出するよう構成されており、
前記代行駆動用電子制御装置は、
同一の駆動方式である前記駆動対象に対応した前記故障情報を、該駆動方式に対応した前記駆動出力手段の数よりも多く受信した場合であって、前記第１優先度判断手段による判断の結果、優先度が同一の前記駆動対象が複数存在していることにより該複数の駆動対象の全てに前記駆動出力を行えない場合に、該各故障情報に含まれている前記関連情報を比較して、該関連情報に基づいて該複数の駆動対象の優先度を判断する第２優先度判断手段を備え、
前記駆動出力制御手段は、前記優先度情報が示す前記優先度が同一の前記駆動対象が複数存在している場合には、該複数の駆動対象については、前記第２優先度判断手段による判断結果が示す前記優先度に基づき、該優先度が高い前記駆動対象に対して優先的に前記駆動出力が行われるよう前記出力切替手段を制御する
ことを特徴とする制御システム。
【請求項５】
請求項２〜請求項４の何れか１項に記載の制御システムであって、
前記各正規駆動用電子制御装置及び前記代行駆動用電子制御装置は、マルチマスタ方式の通信方式にて、予め決められたフォーマットの通信フレームを送受信することにより相互にデータ通信を行うよう構成されており、
前記正規駆動用電子制御装置における前記故障情報出力手段は、前記故障情報を前記通信フレームにて送出すると共に、該通信フレーム内に格納される前記優先度情報として、前記優先度が高いほど値の小さい論理値を格納する
ことを特徴とする制御システム。
【請求項６】
請求項４に記載の制御システムであって、
前記各正規駆動用電子制御装置及び前記代行駆動用電子制御装置は、マルチマスタ方式の通信方式にて、予め決められたフォーマットの通信フレームを送受信することにより相互にデータ通信を行うよう構成されており、
前記正規駆動用電子制御装置における前記故障情報出力手段は、前記故障情報を前記通信フレームにて送出すると共に、該通信フレーム内に格納される前記優先度情報として、前記優先度が高いほど値の小さい論理値を格納し、前記関連情報として、前記関連情報に基づく優先度が高いほど値の小さい論理値を格納し、前記関連情報よりも先に前記優先度情報が送出されるように該通信フレームを生成する
ことを特徴とする制御システム。
【請求項７】
請求項１〜請求項６の何れか１項に記載の制御システムに用いられ、前記正規駆動用電子制御装置を構成する電子制御装置。
【請求項８】
請求項１〜請求項６の何れか１項に記載の制御システムに用いられ、前記代行駆動用電子制御装置を構成する電子制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、負荷の駆動を制御する電子制御装置、及び複数の電子制御装置が相互にデータ通信可能に接続されてなる制御システムに関する。
【背景技術】
【０００２】
従来より、この種の電子制御装置（以下「ＥＣＵ」という）として、車両に搭載され、車両における負荷の駆動を制御するよう構成されたものが知られている。例えば車両のワイパの駆動を制御するワイパＥＣＵにおいては、ユーザによりワイパを作動させるためのスイッチが操作されると、ワイパＥＣＵは、その操作内容に基づいてワイパを駆動するアクチュエータ（モータ）へ駆動信号を出力して、ワイパを駆動させる。
【０００３】
このようなＥＣＵでは、負荷への駆動電流等の出力を行う駆動回路（ドライバ等）に故障が生じるなどの何らかの原因により負荷への駆動出力を正常に行えなくなるような故障（以下「出力故障」ともいう）が生じ、負荷を正常に駆動できなくなるおそれがある。そこで従来、ＥＣＵに出力故障が生じた場合であってもその対象となる負荷を駆動できるようにする技術が種々提案されている。
【０００４】
例えば特許文献１には、ワイパＥＣＵによるワイパモータの駆動が正常に行えなくなった場合に他のＥＣＵが代わってワイパモータを駆動する技術が記載されている。
より具体的には、ワイパを駆動制御するためのＥＣＵを、制御プログラムに基づく制御演算を行うワイパＥＣＵと、このワイパＥＣＵと多重通信線を介して接続されると共にこのワイパＥＣＵから入力される制御信号に基づいてワイパモータへ電圧を出力してワイパモータを駆動する入出力ＥＣＵとに分けて構成する。更に、多重通信線には他のＥＣＵ（汎用制御装置）が接続されており、ワイパ制御とは異なる制御を実行する。
【０００５】
そして、ワイパＥＣＵは、自身が故障し得るか否かを予測し、故障し得ると予測した場合には、自身に記憶されているワイパ制御プログラムを他のＥＣＵに転送する。他のＥＣＵは、ワイパＥＣＵからワイパ制御プログラムが転送されて来たら、そのワイパ制御プログラムを自身の空きエリアに書き込み、ワイパＥＣＵに代わってワイパ制御を行う。以後、入出力ＥＣＵは、他のＥＣＵからの制御信号に基づいてワイパモータを駆動する。
【０００６】
また例えば、特許文献２には、駆動ユニット内のＣＰＵや駆動回路が故障した場合にバックアップ線を介して負荷を駆動する技術が記載されている。
より具体的には、ユーザ操作に応じたデータを通信ラインへ出力するコントロールユニットと、ＣＰＵ及び駆動回路を有すると共にコントロールユニットからのデータに基づいて負荷へ駆動電流を出力することにより負荷を駆動する駆動ユニットと、オプションユニットと、を備えている。このオプションユニットと駆動ユニットの間には、駆動ユニットの負荷をオプションユニットが直接駆動させるためのバックアップ線が接続されている。
【０００７】
そして、オプションユニットは、駆動ユニットの動作を監視し、駆動ユニットの異常を検知した場合は、その後、コントロールユニットから駆動ユニットへデータが出力されるとオプションユニットがこれを取り込み、そのデータに基づいて、バックアップ線を介して駆動ユニットの負荷を直接駆動する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−２９１９４３号公報
【特許文献２】特開２０００−１４８５１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、近年、車両に搭載されるＥＣＵや負荷の数は多岐に渡り、各ＥＣＵがそれぞれ一又は複数の負荷を駆動制御するよう構成されていると共に、各ＥＣＵは通信ラインを介して相互にデータ通信可能に接続されている。つまり、近年の車両においては、複数のＥＣＵが通信ラインを介して接続されてなる制御システムが構築されているのが一般的である。
【００１０】
そして、このような制御システムに対しても、上述した特許文献１，２に記載された技術を用いることで、ＥＣＵに異常が生じてもそのＥＣＵに代わって他のＥＣＵに負荷の駆動を代行させることが可能である。
【００１１】
しかしながら、複数のＥＣＵからなる制御システムに対して特許文献１に記載された技術を適用すると、ＥＣＵ毎に入出力ＥＣＵを持たせるか、或いは１つの入出力ＥＣＵによって各ＥＣＵからの制御入力を全て入力でき且つ各ＥＣＵの負荷を全て駆動可能とする必要がある。そのため、ＥＣＵの数が多いほど制御システムの規模、コストが大幅に増大し、現実的ではない。
【００１２】
しかも、バックアップ対象のＥＣＵが多いほど、その分、他のＥＣＵにおける、バックアップ対象ＥＣＵからの制御プログラムを記憶させるために確保しておくべき記憶領域が大きくなり、他のＥＣＵのメモリ容量や処理負荷の増大も招く。
【００１３】
また、特許文献２に記載された技術についても、複数の負荷をバックアップ対象とする場合、その分、バックアップ駆動用の駆動回路やバックアップ線が必要となり、オプションユニットの構成の複雑化・大型化・コストアップを招く。
【００１４】
本発明は上記課題に鑑みなされたものであり、複数のＥＣＵが通信ラインを介して接続されてなる制御システムにおいて、ＥＣＵに出力故障が生じた場合に、限られたリソースにて低コストで、その出力故障に対応した負荷の駆動をバックアップできるようにすることを目的とする。
【課題を解決するための手段】
【００１５】
上記課題を解決するためになされた請求項１に記載の発明は、駆動方式の異なる一又は複数の駆動対象を駆動する電子制御装置である正規駆動用電子制御装置が、複数、通信線を介して相互にデータ通信可能に構成された制御システムであって、前記通信線には、更に、前記駆動対象の駆動を前記電子制御装置に代わって行うことが可能に構成された電子制御装置である代行駆動用電子制御装置が接続され、該代行駆動用電子制御装置と前記各電子制御装置との間で前記通信線を介して相互にデータ通信可能に構成されている。
【００１６】
そして、前記正規駆動用電子制御装置は、前記駆動対象毎に、該各駆動対象を駆動するための駆動出力を該各駆動対象に対して行う駆動手段と、前記駆動手段による前記駆動出力が正常に行われない故障状態であるか否かを前記駆動対象毎に判断可能な故障判断手段と、前記故障判断手段により何れかの前記駆動対象について前記故障状態であると判断された場合にその旨の情報である故障情報を通信線へ送出する故障情報出力手段と、を備えている。
【００１７】
また、前記代行駆動用電子制御装置は、前記各正規駆動用電子制御装置の前記各駆動対象のうち、前記駆動方式が同一のものを１つの共通仕様グループとして、該共通仕様グループ毎に該共通仕様グループの前記駆動対象の数よりも少ない数だけ設けられ、該共通仕様グループの前記駆動対象へ前記駆動出力を行うことが可能な駆動出力手段と、前記各駆動出力手段からの駆動出力の出力先を、対応する前記共通仕様グループにおける前記駆動対象の何れかに選択的に切り替える出力切替手段と、前記通信線を介して前記正規駆動用電子制御装置からの前記故障情報を受信する受信手段と、前記受信手段により前記故障情報が受信された場合に、該故障情報に基づいて、前記故障状態である前記駆動対象及びその駆動方式を判断し、該判断した駆動方式に対応し且つ該駆動対象へ前記駆動出力を行うことが可能な前記駆動出力手段に対して前記駆動出力を行わせると共に、該駆動出力が前記故障状態である前記駆動対象へ出力されるように前記出力切替手段を制御する、駆動出力制御手段と、を備えている。
【００１８】
このように構成された制御システムでは、各正規駆動用電子制御装置がそれぞれ、駆動対象を持ち、駆動対象毎に駆動手段から駆動出力を行うことにより各駆動対象を駆動する。このような構成において、何らかの要因により、何れかの駆動対象に対して正常に駆動出力を行えないような故障が発生すると、その駆動対象については正常に駆動できなくなるため、故障情報出力手段が故障情報を送出する。
【００１９】
一方、上記故障が生じた場合に正規駆動用電子制御装置に代わって駆動対象を駆動する（代行駆動する）ために、代行駆動用電子制御装置が備えられている。この代行駆動用電子制御装置は、上記各駆動対象毎に個別に駆動出力手段を備えているのではなく、駆動方式が同一の共通仕様グループ毎に、その共通仕様グループの駆動対象の数よりも少ない駆動出力手段を備えている。
【００２０】
共通仕様グループ毎に駆動出力手段をいくつ設けるかは適宜決めることができ、例えばリソースを最小限に抑えたい場合には１つのみ設けるようにしてもよいし、例えば同じ駆動方式の駆動対象を同時に複数（例えば２つ）駆動できるように駆動出力手段も複数（例えば２つ）設けるようにしてもよい。
【００２１】
そして、共通仕様グループ毎の駆動出力手段の数は、対応する駆動対象の数よりも少ないため、出力切替手段を設け、駆動出力手段からの駆動出力の出力先を、対応する複数の駆動対象の何れかに選択的に切り替えできるようにしている。
【００２２】
従って、請求項１に記載の制御システムによれば、各正規駆動用電子制御装置において何れかの駆動対象への駆動出力が故障状態となった場合に、限られたリソースにて低コストで、その故障状態となった駆動対象を代行駆動することができる。
【００２３】
次に、請求項２に記載の発明は、請求項１に記載の制御システムであって、前記正規駆動用電子制御装置は、前記駆動対象毎に、該駆動対象が前記故障状態となった場合に該駆動対象を前記代行駆動用電子制御装置によって駆動させるべき優先度を示す優先度情報が設定されており、前記故障情報出力手段は、前記故障状態の前記駆動対象に対して設定されている前記優先度情報を含む前記故障情報を送出するよう構成されている。
【００２４】
そして、前記代行駆動用電子制御装置は、同一の駆動方式の前記駆動対象に対応した前記故障情報を、該駆動方式に対応した前記駆動出力手段の数よりも多く受信した場合に、該各故障情報に含まれている前記優先度情報を比較して前記各駆動対象の優先度を判断する第１優先度判断手段を備え、前記駆動出力制御手段は、前記第１優先度判断手段による判断結果に基づき、前記優先度が高い前記駆動対象に対して優先的に前記駆動出力が行われるよう、対応する前記駆動出力手段から前記駆動出力を行わせると共に前記出力切替手段を制御する。
【００２５】
このように構成された請求項２に記載の制御システムによれば、優先度の高い駆動対象ほど優先的に駆動出力手段からの駆動出力がなされて代行駆動されることになるため、故障発生に対して、必要性（優先度）に応じた適切な代行駆動が可能となる。そのため、例えば安全性に関わる駆動対象についてはその優先度を高く設定することで、故障が発生しても安全性を確実に確保できるようにすることが可能となる。
【００２６】
次に、請求項３に記載の発明は、請求項２に記載の制御システムであって、前記正規駆動用電子制御装置は、前記駆動対象の動作に関連した情報である関連情報が入力される関連情報入力手段を備え、１つの前記駆動対象に対し、前記関連情報の内容に応じて前記優先度の異なる複数の前記優先度情報が設定されている。
【００２７】
このように構成された請求項３に記載の制御システムによれば、１つの駆動対象に対して一律に１つの優先度が設定されているのではなく、関連情報を有する駆動対象については、関連情報の内容に応じて複数の優先度が設定されるため、関連情報が加味されたより適切な優先度を設定することが可能となる。
【００２８】
次に、請求項４に記載の発明は、請求項２に記載の制御システムであって、前記正規駆動用電子制御装置は、前記駆動対象の動作に関連した情報である関連情報が入力される関連情報入力手段を備え、前記故障情報出力手段は、前記故障状態の前記駆動対象に対応した前記関連情報を含む前記故障情報を送出するよう構成されている。
【００２９】
前記代行駆動用電子制御装置は、同一の駆動方式である前記駆動対象に対応した前記故障情報を該駆動方式に対応した前記駆動出力手段の数よりも多く受信した場合であって、前記第１優先度判断手段による判断の結果、優先度が同一の前記駆動対象が複数存在していることにより該複数の駆動対象の全てに前記駆動出力を行えない場合に、該各故障情報に含まれている前記関連情報を比較して、該関連情報に基づいて該複数の駆動対象の優先度を判断する第２優先度判断手段を備えている。
【００３０】
そして、前記駆動出力制御手段は、前記優先度情報が示す前記優先度が同一の前記駆動対象が複数存在している場合には、該複数の駆動対象については、前記第２優先度判断手段による判断結果が示す前記優先度に基づき、該優先度が高い前記駆動対象に対して優先的に前記駆動出力が行われるよう前記出力切替手段を制御する。
【００３１】
このように構成された請求項４に記載の制御システムによれば、正規駆動用電子制御装置からの故障情報には、優先度情報に加えて関連情報も含まれているため、代行駆動用電子制御装置では、優先度情報に基づく優先度が同一の駆動対象が複数存在している場合には、更に関連情報が示す優先度に基づいて、全体としての優先度を判断できる。そのため、関連情報をも加味した、より適切な優先度の判断結果に従って、代行駆動すべき駆動対象を決めることが可能となる。
【００３２】
次に、請求項５に記載の発明は、請求項２〜請求項４の何れか１項に記載の制御システムであって、前記各正規駆動用電子制御装置及び前記代行駆動用電子制御装置は、マルチマスタ方式の通信方式にて、予め決められたフォーマットの通信フレームを送受信することにより相互にデータ通信を行うよう構成されている。そして、前記正規駆動用電子制御装置における前記故障情報出力手段は、前記故障情報を前記通信フレームにて送出すると共に、該通信フレーム内に格納される前記優先度情報として、前記優先度が高いほど値の小さい論理値を格納する。
【００３３】
このように構成された請求項５に記載の制御システムによれば、複数の故障情報が同時に送出された場合に、優先度情報が格納されたフィールドにおいて調停（アービトレーション）が行われ、優先度の高い方が最終的に送信権を獲得することができるため、複数の故障情報（通信フレーム）の衝突が生じても、代行駆動用電子制御装置は、優先度の高い方を先に受信することが可能となり、優先度の高い駆動対象を迅速に代行駆動させることが可能となる。
【００３４】
次に、請求項６に記載の発明は、請求項４に記載の制御システムであって、前記各正規駆動用電子制御装置及び前記代行駆動用電子制御装置は、マルチマスタ方式の通信方式にて、予め決められたフォーマットの通信フレームを送受信することにより相互にデータ通信を行うよう構成されている。そして、前記正規駆動用電子制御装置における前記故障情報出力手段は、前記故障情報を前記通信フレームにて送出すると共に、該通信フレーム内に格納される前記優先度情報として、前記優先度が高いほど値の小さい論理値を格納し、前記関連情報として、前記関連情報に基づく優先度が高いほど値の小さい論理値を格納し、前記関連情報よりも先に前記優先度情報が送出されるように該通信フレームを生成する。
【００３５】
このように構成された請求項６に記載の制御システムによれば、複数の故障情報が同時に送出された場合に、各故障情報に含まれる優先度情報が同じ値であっても、更に、関連情報が格納されたフィールドにおいて調停（アービトレーション）が行われ、関連情報に基づく優先度の高い方が最終的に送信権を獲得することができる。そのため、請求項５に記載の発明と同様、複数の故障情報（通信フレーム）の衝突が生じても、代行駆動用電子制御装置は、優先度の高い方を先に受信することが可能となり、優先度の高い駆動対象を迅速に代行駆動させることが可能となる。
【００３６】
次に、請求項７に記載の発明は、請求項１〜請求項６の何れか１項に記載の制御システムに用いられ、前記正規駆動用電子制御装置を構成する電子制御装置である。
このように構成された電子制御装置によれば、請求項１〜請求項６の何れか１項に記載の制御システムを構成することができ、その場合、請求項１〜請求項６と同様の作用・効果を奏することが可能となる。
【００３７】
次に、請求項８に記載の発明は、請求項１〜請求項６の何れか１項に記載の制御システムに用いられ、前記代行駆動用電子制御装置を構成する電子制御装置である。
このように構成された電子制御装置によれば、請求項１〜請求項６の何れか１項に記載の制御システムを構成することができ、その場合、請求項１〜請求項６と同様の作用・効果を奏することが可能となる。
【図面の簡単な説明】
【００３８】
【図１】実施形態の車載制御システムの概略構成を表す構成図である。
【図２】実施形態の車載制御システムで用いられる登録用フレームを示す説明図である。
【図３】実施形態の車載制御システムで用いられる故障通知用フレーム（ａ）及びその衝突処理例（ｂ）を説明するための説明図である。
【図４】第１実施形態の車載制御システムにおいて設定されている安全レベルを示す説明図である。
【図５】第１実施形態の各ＥＣＵ（ボデーＥＣＵ等）で実行される故障通知処理を表すフローチャートである。
【図６】第１実施形態のリカバリーＥＣＵで実行される代行駆動処理を表すフローチャートである。
【図７】第２実施形態の車載制御システムにおいて設定されている安全レベルを示す説明図である。
【図８】第３実施形態の車載制御システムにおいて設定されている安全レベル及び故障関連ＩＤを示す説明図である。
【図９】第３実施形態の車載制御システムで用いられる故障通知用フレーム（ａ）及びその衝突処理例（ｂ）を説明するための説明図である。
【図１０】第３実施形態のリカバリーＥＣＵで実行される代行駆動処理における、新規代行不可時処理（ａ）及び代行切替処理（ｂ）を表すフローチャートである。
【発明を実施するための形態】
【００３９】
以下に、本発明の好適な実施形態を図面に基づいて説明する。
［第１実施形態］
図１は、本発明が適用された実施形態の車載制御システムの概略構成を表す構成図である。本実施形態の車載制御システムは、ボデーＥＣＵ２０、ワイパＥＣＵ３０、ブレーキＥＣＵ４０などの各種のＥＣＵが通信線１００によって接続され、この通信線１００を介して、予め決められた通信プロトコルに従って相互にデータ通信可能に構成されている。
【００４０】
ボデーＥＣＵ２０は、例えばドアロックモータやヘッドライト（何れも図示略）などの、車両におけるボデー系の各種負荷を駆動制御するＥＣＵであり、制御部２１と、駆動部２２と、通信インタフェース（ＩＦ）２３と、を備えている。
【００４１】
通信ＩＦ２３は、予め決められた通信プロトコルに従ってデータの送受信を行う。本実施形態の通信プロトコルでは、図２，図３に示すような通信フレーム（詳細は後述）によりデータ送受信を行うように設定されている。
【００４２】
駆動部２２は、制御部２１からの駆動指令に従って所望の負荷（駆動対象）へ駆動電流等を出力することにより負荷を駆動するものである。ボデーＥＣＵ２０は、上述したドアロックモータやヘッドライトを含む複数の負荷を駆動する。そのため、駆動部２２は、より詳しくは、駆動対象の負荷毎にそれぞれ駆動回路（ドライバ）を有しており、負荷毎に出力チャンネル（ｃｈ）が設定されている。つまり、負荷毎に個別にドライバが設けられている。
【００４３】
本実施形態では、例えば、ドアロックモータを駆動するためのドライバからの駆動電流の出力チャンネルがＡ１チャンネルとして設定されており、また、ヘッドライトを駆動するためのドライバからの駆動電流の出力チャンネルがＡ２チャンネルとして設定されている。Ａ３チャンネル以降の複数の出力チャンネルからも、それぞれ、対応するドライバからの駆動電流が対応する負荷へ出力される。
【００４４】
制御部２１は、駆動対象である各種負荷の駆動を制御し、駆動部２２へ駆動指令を出力する。制御部２１には、車両外部の照度を検出する照度センサ２４からの検出信号をはじめ、他の各種センサやスイッチ等からの信号が入力される。
【００４５】
そのため、ユーザが例えばドアをロックする旨の操作を行うと、制御部２１は、ドアロックモータを駆動させるための駆動指令を駆動部２２に出力する。すると、駆動部２２は、その駆動指令に従って対応するドライバを動作させ、ドアロックモータを駆動させる為の駆動出力（Ａ１チャンネル出力）を行う。また例えば、ユーザがヘッドライトを点灯させる旨の操作を行うと、制御部２１は、ヘッドライトを駆動（点灯）させるための駆動指令を駆動部２２に出力する。すると、駆動部２２は、その駆動指令に従って対応するドライバを動作させ、ヘッドライトを駆動させる為の駆動出力（Ａ２チャンネル出力）を行う。
【００４６】
そして、本実施形態では、各出力チャンネルからの駆動出力は、ＪＢ（Junction Box：ジャンクションボックス）１０へ入力され、ＪＢ１０内の各駆動段を介して駆動対象の負荷へ出力される。
【００４７】
ＪＢ１０は、車両各部へ電力や信号等を分配したり、リレーやヒューズなどの部品を集中配置したりするための周知の中継ボックスである。そして、上述した、ＪＢ１０内の各駆動段とは、リレーやヒューズなどの部品、或いはバスバーなどの電線中継部品などを意味する。
【００４８】
このような構成により、ボデーＥＣＵ２０の駆動部２２におけるＡ１チャンネルからの駆動出力、即ちドアロックモータ駆動用のドライバからの駆動電流は、ＪＢ１０においてボデー系第１駆動段１１ａに入力される。このボデー系第１駆動段１１ａは、本実施形態ではリレー（ドアロックリレー）である。そのため、このボデー系第１駆動段１１ａに駆動電流が入力されると、ドアロックリレーがＯＮし、このドアロックリレーからドアロックモータへ駆動電流が出力されることとなる。
【００４９】
また、ボデーＥＣＵ２０の駆動部２２におけるＡ２チャンネルからの駆動出力、即ちヘッドライト駆動用のドライバからの駆動電流は、ＪＢ１０においてボデー系第２駆動段１２ａに入力される。このボデー系第２駆動段１２ａは、本実施形態ではバスバーなどの電線中継部品である。そのため、このボデー系第２駆動段１２ａに駆動電流が入力されると、その駆動電流がそのままヘッドライトへ出力されることとなる。
【００５０】
また、駆動部２２のＡ３チャンネルからの駆動出力も、ＪＢ１０においてボデー系第３駆動段１３ａに入力され、このボデー系第３駆動段１３ａを介して対応する負荷へ駆動出力がなされることとなる。
【００５１】
ボデーＥＣＵ２０により駆動制御される各負荷の駆動方式（通電電流値・通電タイミングなど。チャンネル仕様ともいう。）は、負荷の種類毎に異なっている。例えば、ある負荷については、対応するドライバから所定電流値の電流の供給を受けて駆動するよう構成されており、別のある負荷については、対応するドライバから所定のＰＷＭ駆動電流の供給を受けて駆動するよう構成されている。
【００５２】
そして、本実施形態では、ボデーＥＣＵ２０からの各出力チャンネルのうち、少なくともＡ１チャンネル〜Ａ３チャンネルについては、それぞれ駆動方式が異なっており、Ａ１チャンネルからの駆動出力は所定の第１駆動方式に対応したものであり、Ａ２チャンネルからの駆動出力は所定の第２駆動方式に対応したものであり、Ａ３チャンネルからの駆動出力は所定の第３駆動方式に対応したものである。
【００５３】
また、ボデーＥＣＵ２０は、出力チャンネル毎に、駆動部２２からの駆動出力が正常に行われるか否か、延いては負荷を正常に駆動できるか否かを検出する、出力故障検出機能を備えている。
【００５４】
制御部２１は、ユーザ操作やセンサ入力等によって負荷を駆動すべき旨の負荷駆動入力があると、駆動対象の負荷を駆動すべく、駆動部２２内における対応するドライバへ駆動指令を出力する。そして、この駆動指令の出力後（及び出力前）、対応する出力チャンネルから駆動出力が正常に行える状態であるか、それとも正常に駆動出力を行えない出力故障が生じているかを判断する。
【００５５】
そして、例えばドライバを構成する半導体スイッチの故障などの種々の要因によって出力故障が生じていることを検出した場合には、その旨を示すデータ（後述する故障通知用フレーム。図３参照。）を通信線１００上へ送出する。
【００５６】
なお、ボデーＥＣＵ２０が出力チャンネルとしてＡ１〜Ａ３チャンネルの少なくとも３つを有していることや、出力チャンネル毎に駆動方式が異なっていることは、あくまでも一例に過ぎず、出力チャンネルの数や駆動対象の負荷の種類、駆動方式などは特に限定されるものではない。後述するワイパＥＣＵ３０やブレーキＥＣＵ４０についても同様である。
【００５７】
ワイパＥＣＵ３０は、例えばワイパモータ（図示略）などの、車両におけるワイパに対する各種駆動を制御するＥＣＵであり、ボデーＥＣＵ２０と同様、制御部３１と、駆動部３２と、通信ＩＦ３３と、を備えている。
【００５８】
ワイパＥＣＵ３０も、上述したワイパモータを含む複数の負荷を駆動するため、駆動部３２は、駆動対象の負荷毎にそれぞれドライバを有しており、負荷毎に出力チャンネルが設定されている。本実施形態では、例えば、ワイパモータを駆動するためのドライバからの駆動電流の出力チャンネルがＢ１チャンネルとして設定されている。Ｂ２チャンネル以降の複数の出力チャンネルからも、それぞれ、対応するドライバからの駆動電流が対応する負荷へ出力される。
【００５９】
制御部３１には、車両外部における降雨状況を検出するための雨滴センサ３４からの検出信号をはじめ、他の各種センサやスイッチ等からの信号が入力される。
そのため、ユーザが例えばワイパを作動させるための操作を行うと、制御部３１は、ワイパモータを駆動させるための駆動指令を駆動部３２に出力する。すると、駆動部３２は、その駆動指令に従って対応するドライバを動作させ、ワイパモータを駆動させる為の駆動出力（Ｂ１チャンネル出力）を行う。そして、このワイパＥＣＵ３０における各出力チャンネルからの駆動出力も、ＪＢ１０へ入力され、ＪＢ１０内の各駆動段を介して駆動対象の負荷へ出力される。
【００６０】
ワイパＥＣＵ３０の駆動部３２におけるＢ１チャンネルからの駆動出力、即ちワイパモータ駆動用のドライバからの駆動電流は、ＪＢ１０においてワイパ系第１駆動段１１ｂに入力される。このワイパ系第１駆動段１１ｂは、本実施形態ではリレー（ワイパリレー）である。そのため、このワイパ系第１駆動段１１ｂに駆動電流が入力されると、ワイパリレーがＯＮし、このワイパリレーからワイパモータへ駆動電流が出力されることとなる。
【００６１】
また、ワイパＥＣＵ３０の駆動部３２におけるＢ２以降の出力チャンネルからの駆動出力も、ＪＢ１０においてそれぞれ対応する駆動段（ワイパ系第２駆動段１２ｂ、ワイパ系第３駆動段１３ｂ、・・・）に入力され、これら駆動段を介して対応する負荷へ駆動出力がなされることとなる。
【００６２】
ワイパＥＣＵ３０により駆動制御される各負荷の駆動方式（チャンネル仕様）も、負荷の種類毎に異なっている。具体的には、ワイパＥＣＵ３０からの各出力チャンネルのうち、少なくともＢ１チャンネル〜Ｂ３チャンネルについては、それぞれ駆動方式が異なっており、Ｂ１チャンネルからの駆動出力は第１駆動方式に対応したものであり、Ｂ２チャンネルからの駆動出力は第２駆動方式に対応したものであり、Ｂ３チャンネルからの駆動出力は第３駆動方式に対応したものである。
【００６３】
更に、ワイパＥＣＵ３０は、ボデーＥＣＵ２０と同様、出力チャンネル毎に、駆動部３２からの駆動出力が正常に行われるか否か、延いては負荷を正常に駆動できるか否かを検出する、出力故障検出機能を備えており、出力故障が生じていることを検出した場合には、その旨を示すデータ（後述する故障通知用フレーム）を通信線１００上へ送出する。
【００６４】
ブレーキＥＣＵ４０は、車両におけるブレーキシステムの各種駆動を制御するＥＣＵであり、ボデーＥＣＵ２０と同様、制御部４１と、駆動部４２と、通信ＩＦ４３と、を備えている。
【００６５】
ブレーキＥＣＵ４０も、例えばストップライト（図示略）などの複数の負荷を駆動するため、駆動部４２は、駆動対象の負荷毎にそれぞれドライバを有しており、負荷毎に出力チャンネルが設定されている。本実施形態では、例えば、ストップライトを駆動（点灯）するためのドライバからの駆動電流の出力チャンネルがＣ２チャンネルとして設定されている。Ｃ１チャンネル及びＣ３チャンネル以降の複数の出力チャンネルからも、それぞれ、対応するドライバからの駆動電流が対応する負荷へ出力される。
【００６６】
制御部４１には、ユーザにより操作されるブレーキスイッチ（ＳＷ）４４からの操作信号をはじめ、他の各種センサやスイッチ等からの信号が入力される。
そのため、ユーザが例えば走行中の車両を減速・停止させるべくブレーキＳＷ４４を踏むと、制御部４１は、ストップライトを駆動させるための駆動指令を駆動部４２に出力する。すると、駆動部４２は、その駆動指令に従って対応するドライバを動作させ、ストップライトを駆動させる為の駆動出力（Ｃ２チャンネル出力）を行う。そして、このブレーキＥＣＵ４０における各出力チャンネルからの駆動出力も、ＪＢ１０へ入力され、ＪＢ１０内の各駆動段を介して駆動対象の負荷へ出力される。
【００６７】
ブレーキＥＣＵ４０の駆動部４２におけるＣ２チャンネルからの駆動出力、即ちストップライト駆動用のドライバからの駆動電流は、ＪＢ１０においてブレーキ系第２駆動段１２ｃに入力される。このブレーキ系第２駆動段１２ｃは、本実施形態ではバスバーなどの電線中継部品である。そのため、このブレーキ系第２駆動段１２ｃに駆動電流が入力されると、その駆動電流がそのままストップライトへ出力されることとなる。
【００６８】
また、ブレーキＥＣＵ４０の駆動部４２におけるＣ１及びＣ３以降の出力チャンネルからの駆動出力も、ＪＢ１０においてそれぞれ対応する駆動段（ブレーキ系第１駆動段１１ｃ、ブレーキ系第３駆動段１３ｃ、・・・）に入力され、これら駆動段を介して対応する負荷へ駆動出力がなされることとなる。
【００６９】
ブレーキＥＣＵ４０により駆動制御される各負荷の駆動方式（チャンネル仕様）も、負荷の種類毎に異なっている。具体的には、ブレーキＥＣＵ４０からの各出力チャンネルのうち、少なくともＣ１チャンネル〜Ｃ３チャンネルについては、それぞれ駆動方式が異なっており、Ｃ１チャンネルからの駆動出力は第１駆動方式に対応したものであり、Ｃ２チャンネルからの駆動出力は第２駆動方式に対応したものであり、Ｃ３チャンネルからの駆動出力は第３駆動方式に対応したものである。
【００７０】
更に、ブレーキＥＣＵ４０は、ボデーＥＣＵ２０やワイパＥＣＵ３０と同様、出力チャンネル毎に、駆動部４２からの駆動出力が正常に行われるか否か、延いては負荷を正常に駆動できるか否かを検出する、出力故障検出機能を備えており、出力故障が生じていることを検出した場合には、その旨を示すデータ（後述する故障通知用フレーム）を通信線１００上へ送出する。
【００７１】
そして、本実施形態の車載制御システムでは、上述した各ＥＣＵ２０，３０，４０・・・とは別に、リカバリーＥＣＵ１５が、ＪＢ１０内に設けられている。そして、このリカバリーＥＣＵ１５も、通信線１００を介して他の各ＥＣＵ２０，３０，４０・・・と相互にデータ通信可能に構成されている。
【００７２】
本実施形態の車載制御システムでは、ＥＣＵ相互間のデータ通信が、所定の通信プロトコルに従って行われる。本実施形態の通信プロトコルは、よく知られたＣＡＮと同様、マルチマスタ（ＣＳＭＡ／ＣＤ）方式であり、これにより応答性を確保している。
【００７３】
また、通信線１００のバスレベルについても、ＣＡＮと同様、「ドミナント」（優勢）と「レセッシブ」（劣勢）の２つのレベルがある。ドミナントは論理値０で、レセッシブは論理値１であり、ドミナントの方がレセッシブよりも優先度が高い。そのため、通信線１００に接続されている複数のノード（本例では複数のＥＣＵ）のうちいずれか１つでもドミナントを出力すると、通信線１００はドミナントレベルになる。
【００７４】
リカバリーＥＣＵ１５は、それ自身が専用の負荷を持っていてそれを自ら主体的に駆動制御する、というものではなく、他の各ＥＣＵ２０，３０，４０において出力故障が生じた場合に、その出力故障が生じた負荷を、その出力故障が生じたＥＣＵに代わって代行（バックアップ）駆動させるために設けられたものである。
【００７５】
このリカバリーＥＣＵ１５は、通信ＩＦ１６と、制御部１７と、複数の汎用出力ドライバ６１，６２，６３，・・・，６４と、複数のチャンネル切替部７１，７２，７３，・・・７４と、を備えている。このうち通信ＩＦ１６は、基本的には上述した各ＥＣＵ２０，３０，４０・・・の各通信ＩＦ２３，３３，４３・・・と同様の構成であり、上述した通信プロトコルに従ってデータの送受信を行う。
【００７６】
複数の汎用出力ドライバ６１，６２，６３，・・・，６４は、他の各ＥＣＵ２０，３０，４０の各負荷を駆動するためのドライバであり、上述した駆動方式の種類毎に１つずつ設けられている。
【００７７】
即ち、第１汎用出力ドライバ６１は、第１駆動方式に対応した駆動出力を行うドライバである。この第１汎用出力ドライバ６１からの駆動出力は、第１チャンネル切替部７１を介して、第１駆動方式の負荷（詳しくはＪＢ１０内の各第１駆動段１１ａ，１１ｂ，１１ｃ，・・・）のうち何れか１つに出力される。
【００７８】
第２汎用出力ドライバ６２は、第２駆動方式に対応した駆動出力を行うドライバである。この第２汎用出力ドライバ６２からの駆動出力は、第２チャンネル切替部７２を介して、第２駆動方式の負荷（詳しくはＪＢ１０内の各第２駆動段１２ａ，１２ｂ，１２ｃ，・・・）のうち何れか１つに出力される。
【００７９】
第３汎用出力ドライバ６３は、第３駆動方式に対応した駆動出力を行うドライバである。この第３汎用出力ドライバ６３からの駆動出力は、第３チャンネル切替部７３を介して、第３駆動方式の負荷（詳しくはＪＢ１０内の各第３駆動段１３ａ，１３ｂ，１３ｃ，・・・）のうち何れか１つに出力される。
【００８０】
第Ｎ汎用出力ドライバ６４（Ｎは任意の自然数であり、駆動方式の数に対応）は、第Ｎ駆動方式に対応した駆動出力を行うドライバである。この第Ｎ汎用出力ドライバ６４からの駆動出力は、第Ｎチャンネル切替部７４を介して、第Ｎ駆動方式の負荷のうち何れか１つに出力される。
【００８１】
各チャンネル切替部７１，７２，７３，・・・，７４は、対応する汎用出力ドライバからの駆動出力の出力先を、対応する駆動方式の負荷（駆動段）の何れか１つに選択的に切り替える。この切り替えは、制御部１７内の出力選択部５４からの選択指令に従って行われる。
【００８２】
即ち、例えば第１汎用出力ドライバ６１からの駆動出力（駆動電流）が入力される第１チャンネル切替部７１は、第１駆動方式の各第１駆動段１１ａ，１１ｂ，１１ｃ，・・・に対応した数の出力ポートを有し、各出力ポートがそれぞれ各第１駆動段１１ａ，１１ｂ，１１ｃ，・・・に接続されている。そして、第１汎用出力ドライバ６１から駆動出力がなされたとき、第１チャンネル切替部７１にて選択された何れか１つの第１駆動段へ、その第１汎用出力ドライバ６１からの駆動出力が出力される。
【００８３】
リカバリーＥＣＵ１５から第１駆動方式の各負荷（各第１駆動段）へ駆動電流を出力する構成としては、例えば、第１駆動方式の負荷（駆動段）と同じ数の第１汎用出力ドライバ６１を用意して、各第１汎用出力ドライバ６１と第１駆動方式の各第１駆動段とを一対一で接続する方法も考えられ、勿論そのように構成することも可能ではある。
【００８４】
しかし、各負荷の代行駆動のために、各負荷毎に汎用出力ドライバを個別に用意する方法は、代行駆動対象の負荷の数が多くなればなるほど、装置構成の複雑化、大型化、コストアップを招き、現実的ではない。
【００８５】
そこで本実施形態では、駆動方式毎に共通の（本例では１つの）汎用出力ドライバを用意して、その１つの汎用出力ドライバから何れか１つの負荷（駆動段）へ駆動電流を出力するようにしている。
【００８６】
制御部１７は、例えばフラッシュマイコンなどのＩＣにて構成されており、主として、記憶部５１と、故障部位判断部５２と、出力制御部５３と、出力選択部５４と、を備えている。
【００８７】
記憶部５１は、バックアップ対象のＥＣＵ２０，３０，４０，・・・毎の、出力チャンネルとそのチャンネル仕様（駆動方式）の対応関係（以下「チャンネル−仕様対応情報」ともいう）が記憶されたものである。このチャンネル−仕様対応情報は、車載制御システムが車両に搭載されて実際に使用される前迄に、例えば外部ツールを接続してリカバリーＥＣＵへ登録用フレームを送信することにより記憶される。或いは、バックアップ対象の各ＥＣＵ２０，３０，４０，・・・が自ら登録用フレームを送信することにより記憶させるよう構成してもよい。
【００８８】
記憶部５１にチャンネル−仕様対応情報を記憶させるための登録用フレームは、図２に示すように、ＳＯＦ（スタートオブフレーム）フィールドと、登録ＥＣＵフィールドと、登録チャンネルフィールドと、チャンネル仕様フィールドと、ＣＲＣ（巡回冗長検査）フィールドと、ＡＣＫ（アクノリッジ）フィールドと、ＥＯＦ（エンドオブフレーム）フィールドと、の７つのフィールドから構成されている。
【００８９】
ＳＯＦフィールドは、フレームの開始の合図、同期のためのフィールドであり、ＥＯＦフィールドは、フレームの終了を示すためのフィールドであり、ＣＲＣフィールドは、フレームの伝送誤りを検出するためのフィールドであり、ＡＣＫフィールドは、受信側において正常にフレームが受信されたか否かを送信側で確認するためのフィールドである。このＡＣＫフィールドは、送信時はレセッシブ（論理値１）であり、受信側は、フレームを正常に受信するとこのＡＣＫフィールドをドミナント（論理値０）に変換することにより応答を行う。
【００９０】
登録ＥＣＵフィールドは、登録するＥＣＵのＩＤである登録ＥＣＵ−ＩＤを送信するためのフィールドである。この登録ＥＣＵ−ＩＤは、例えば、ボデーＥＣＵ２０ならば「０１０１」、ワイパＥＣＵ３０ならば「００１０」などのように、ＥＣＵ毎に異なる値が設定される。
【００９１】
登録チャンネルフィールドは、登録する出力チャンネルの番号を示すＩＤである登録チャンネルＩＤを送信するためのフィールドである。この登録チャンネルＩＤは、例えば、Ａ２チャンネルならば「０００１００１０」、Ｂ３チャンネルならば「００１０００１１」、Ｃ１チャンネルならば「００１１０００１」、などのように、出力チャンネルの番号毎に異なる値が設定される。
【００９２】
チャンネル仕様フィールドは、登録する出力チャンネルのチャンネル仕様（駆動方式）を送信するためのフィールドである。このチャンネル仕様は、例えば、駆動方式が第１駆動方式ならば「０００１０１００」、のように、駆動方式毎に異なる値が設定される。
【００９３】
このように構成された登録用フレームが外部ツール等によって通信線１００上に送出され、リカバリーＥＣＵ１５にて受信されると、記憶部５１は、受信した登録用フレームに従い、登録対象のＥＣＵ名、登録すべき出力チャンネル、及びそのチャンネル仕様を対応付けてチャンネル−仕様対応情報として記憶する。
【００９４】
また、各ＥＣＵ２０，３０，４０，・・・は、既述の通り、出力故障検出機能を備えており、出力故障が生じた場合にはその旨を故障通知用フレームにて送出する。この故障通知用フレームは、図３（ａ）に示すように、ＳＯＦフィールドと、安全レベルフィールドと、故障ＥＣＵフィールドと、故障チャンネルフィールドと、ＣＲＣフィールドと、ＡＣＫフィールドと、ＥＯＦフィールドと、の７つのフィールドから構成されている。
【００９５】
安全レベルフィールドは、出力故障が発生した出力チャンネルの安全レベルを示すＩＤである安全レベルＩＤを送信するためのフィールドである。本実施形態では、出力故障の種類毎（出力チャンネル毎）に、図４に示すように安全レベルが予め設定されている。
【００９６】
ここでいう安全レベルとは、出力故障が生じた場合にそれを代行駆動すべき優先度を示すものであり、安全レベルが高いほど、代行駆動すべき優先度が高いことを意味する。例えば、ボデーＥＣＵ２０におけるＡ１チャンネルの出力故障（ドアロック出力故障）は安全レベルが「低」に設定されている。これは即ち、ドアロック故障は各種の出力故障の中でもバックアップ駆動の優先度が比較的低く、仮に故障したまま（即ちドアロックができない状態のまま）の状態が継続しても安全上大きな問題が生じるおそれが少ないということである。
【００９７】
一方、例えばブレーキＥＣＵ４０におけるＣ２チャンネルの出力故障（ストップライト出力故障）は安全レベルが「高」に設定されている。これは即ち、ストップライトの出力故障はバックアップ駆動の優先度が比較的高く、出来る限り迅速に（優先的に）バックアップ駆動をさせてストップライトを駆動（点灯）できるようにする必要があるということである。
【００９８】
安全レベルフィールドに設定される安全レベルＩＤは、安全レベルが高いほど小さい値が設定される。そのため、仮に異なるＥＣＵから同じタイミングで故障通知用フレームが送信された場合（フレーム衝突時）は、この安全レベルフィールドによって調停（アービトレーション）が行われる。
【００９９】
具体的には、図３（ｂ）に示すように、例えば出力故障が生じた２つの故障ノード（ＥＣＵ）Ａ，Ｂから同時に故障通知用フレームが送出された場合、各故障ノードは、１ビット毎に自身が送出したビットレベルと他の故障ノードが送出したビットレベル（即ちバス（通信線１００）上のレベル）を比較する。そして、ビットレベルが等しければ送信を継続するが、ビットレベルが異なっている場合、即ち自身はレセッシブであるがバス上はドミナントになっている場合は、調停に負けたものとして、直ちに送信を停止する。図３（ｂ）では、安全レベルフィールドにおける５ビット目で故障ノードＢが調停負けした例が示されている。調停に負けて送信を停止した故障ノードＢは、バスが送信可能な状態になるのを待って同じ故障通知用フレームを再送する。
【０１００】
故障ＥＣＵフィールドは、出力故障が生じたＥＣＵを示すＥＣＵのＩＤである故障ＥＣＵ−ＩＤを送信するためのフィールドであり、同一のＥＣＵならば既述の登録ＥＣＵ−ＩＤと同じである。
【０１０１】
故障チャンネルフィールドは、出力故障が生じた出力チャンネルの番号を示すＩＤである故障チャンネルＩＤを送信するためのフィールドであり、同一のチャンネル番号ならば既述の登録チャンネルＩＤと同じである。
【０１０２】
リカバリーＥＣＵ１５は、故障通知用フレームを受信した場合は、その内容を確認して、どの汎用出力ドライバを用いてどの駆動段へ駆動出力を行うべきか（即ちどのＥＣＵのどの故障チャンネルを代行駆動すべきか）を判断する。そして、代行駆動すべき故障チャンネルに対して駆動電流を出力することにより、代行駆動を行う。
【０１０３】
既述の通り、リカバリーＥＣＵ１５においては、記憶部５１に予め、チャンネル−仕様対応情報が記憶されている。そのため、故障通知用フレームを受信した場合、その故障通知用フレームの内容と、記憶部５１に記憶されているチャンネル−仕様対応情報とを照合することで、どの汎用出力ドライバから駆動電流を出力させればよいかがわかる。
【０１０４】
具体的には、リカバリーＥＣＵ１５において故障通知用フレームが受信されると、制御部１７において、故障部位判断部５２が、故障ＥＣＵ−ＩＤと故障チャンネルＩＤに基づき、記憶部５１内のチャンネル−仕様対応情報を参照して、代行駆動すべきＥＣＵの種類と、どの汎用出力ドライバを動作させるべきかを判断し、その判断結果を出力制御部５３及び出力選択部５４に伝える。
【０１０５】
例えば、故障ＥＣＵがワイパＥＣＵ３０で故障チャンネルがＢ１チャンネルである場合、チャンネル−仕様対応情報から、ワイパＥＣＵ３０のＢ１チャンネルの駆動方式は第１駆動方式であることが判断され、これにより第１汎用出力ドライバ６１を動作させるべきことが判断される。
【０１０６】
出力制御部５３は、故障部位判断部５２における上記判断結果に基づき、第１汎用出力ドライバを動作させる。また、出力選択部５４は、故障部位判断部５２における上記判断結果に基づき、第１汎用出力ドライバ６１からの駆動電流が入力される第１チャンネル切替部７１の出力先を、ワイパ系第１駆動段１１ｂに切り替える。
【０１０７】
但し、リカバリーＥＣＵ１５に故障通知用フレームが受信された時、同一の駆動方式において既に何れかの駆動段が代行駆動されている最中であることも予想される。その場合は、出力選択部５４が、既に代行駆動中の出力チャンネルの安全レベルと、新たに出力故障が通知された出力チャンネルの安全レベルとを比較する。そして、安全レベルが高い方を優先的に代行駆動させる。
【０１０８】
つまり、出力選択部５４は、受信された故障通知用フレームに含まれている安全レベルＩＤを取得する機能も備えており、同じ駆動方式について故障通知用フレームが重複して受信された場合、即ち同じ駆動方式において代行駆動すべき負荷が複数発生した場合は、各々の安全レベルを比較して、安全レベルの高い方から優先的に代行駆動させる。
【０１０９】
なお、出力故障が複数の出力チャンネルにおいて重複して生じた場合であっても、駆動方式が重複しなければ、各出力チャンネルを同時に代行駆動させることができる。
次に、各ＥＣＵ２０，３０，４０，・・・の各制御部２１，３１，４１において実行される故障通知処理、及びリカバリーＥＣＵ１５の制御部１７において実行される代行駆動処理について、図５及び図６を用いて説明する。
【０１１０】
まず、各ＥＣＵ２０，３０，４０，・・・の各制御部２１，３１，４１において実行される故障通知処理について、図５のフローチャートを用いて説明する。この故障通知処理は、一定周期で定期的に実行されるものであり、制御部は、まず、ユーザ操作やセンサ入力等による負荷駆動入力があるか否かを判断する（Ｓ１１０）。負荷駆動入力がない場合は（Ｓ１１０：ＮＯ）、新たに駆動させるべき負荷はないものとして、この故障通知処理を終了する。
【０１１１】
一方、ユーザ操作等による負荷駆動入力があった場合は（Ｓ１１０：ＹＥＳ）、その負荷駆動入力に応じた何れかの負荷を駆動すべく、制御部から対応する出力チャンネルのドライバに対して駆動指令が出力され、これによりドライバから負荷への駆動出力がなされることとなる。
【０１１２】
そこで、Ｓ１２０にて、その駆動指令に対する駆動出力が正常に行われているか否か、換言すれば、出力故障が生じているか否かを判断する。
そして、出力故障が生じていない場合は（Ｓ１２０：ＮＯ）、ユーザ操作やセンサ入力等による駆動停止入力があるか否かを判断する（Ｓ１７０）。この駆動停止入力とは、ユーザ操作やセンサ入力等による、現在駆動中の負荷の駆動を停止させるべき旨の入力信号である。
【０１１３】
駆動停止入力がない場合は（Ｓ１７０：ＮＯ）、再びＳ１２０に戻るが、駆動停止入力があった場合は（Ｓ１７０：ＹＥＳ）、その負荷駆動入力に応じた負荷の駆動を停止させるべく、制御部から対応する出力チャンネルのドライバへの駆動指令が停止される。そこで、Ｓ１８０にて、終了通知用フレームを通信線１００上へ送信し、この故障通知処理を終了する。終了通知用フレームは、図示は省略するが、駆動を停止すべきＥＣＵ名やチャンネル番号、チャンネル仕様などが含まれたものである。
【０１１４】
一方、Ｓ１２０にて、出力故障が生じていると判断された場合は、図３に示した故障通知用フレームを作成する（Ｓ１３０）。即ち、故障したチャンネルのチャンネル番号を取得すると共に故障した出力チャンネルの安全レベルを取得し、これらに基づき、上述した各種フィールドからなる故障通知用フレームを作成する。そして、その作成した故障通知用フレームを送信する（Ｓ１４０）。
【０１１５】
そして、故障通知用フレームの送信が完了したか否か、即ち調停に勝ったか否かを判断し（Ｓ１５０）、調停に負けて送信が完了しなかった場合は再びＳ１４０に戻って故障通知用フレームを送信（再送）する。調停に勝って送信が完了した場合は、ＡＣＫを受信したか否か判断し（Ｓ１６０）、受信しなかった場合は再びＳ１４０に戻って故障通知用フレームを送信（再送）するが、受信したならばこの故障通知処理を終了する。
【０１１６】
次に、リカバリーＥＣＵ１５の制御部１７において実行される代行駆動処理について、図６のフローチャートを用いて説明する。この代行駆動処理は、一定周期で繰り返し実行されるものであり、制御部１７は、まず、他の各ＥＣＵ２０，３０，４０，・・・からの故障通知用フレームを受信したか否か判断する（Ｓ２１０）。
【０１１７】
故障通知用フレームを受信しなかった場合は（Ｓ２１０：ＮＯ）、Ｓ２５０に進んで、終了通知用フレームを受信したか否か判断する。そして、終了通知用フレームを受信しなかった場合は（Ｓ２５０：ＮＯ）、この代行駆動処理を終了する。
【０１１８】
一方、故障通知用フレームを受信した場合は（Ｓ２１０：ＹＥＳ）、故障したチャンネル（以下「新規故障ｃｈ」ともいう）の駆動方式を確認する（Ｓ２２０）。そして、同じ駆動方式で既に代行駆動されているチャンネル（以下「代行中ｃｈ」ともいう）があるか否か判断し（Ｓ２３０）、同じ駆動方式での代行中ｃｈがない場合は、新規故障ｃｈの代行駆動を開始し（Ｓ２４０）、続くＳ２５０に進む。
【０１１９】
即ち、新規故障ｃｈに対応した汎用出力ドライバを動作させると共に、その汎用出力ドライバに対応したチャンネル切替部に対し、新規故障ｃｈに対応した駆動段へ駆動出力がなされるよう、出力先を切り替える。
【０１２０】
故障通知用フレームを受信した場合に、その新規故障ｃｈの駆動方式と同一の駆動方式で既に代行駆動されている代行中ｃｈがあった場合は（Ｓ２３０：ＹＥＳ）、新規故障ｃｈと代行中ｃｈの安全レベルを比較し、新規故障ｃｈの安全レベルの方が代行中ｃｈの安全レベルよりも高いか否か判断する（Ｓ２６０）。
【０１２１】
そして、新規故障ｃｈの安全レベルの方が高い場合は（Ｓ２６０：ＹＥＳ）、現在代行駆動されている最中の代行中ｃｈに対し、その代行駆動を中断して、待機フラグをセットする（Ｓ２７０）。そして、新規故障ｃｈに対する代行駆動を開始して（Ｓ２８０）、続くＳ２５０に進む。
【０１２２】
Ｓ２６０における安全レベルの比較の結果、新規故障ｃｈの安全レベルが代行中ｃｈの安全レベルより高くなかった場合は（Ｓ２６０：ＮＯ）、新規代行不可時処理を行った上でＳ２５０に進む。本実施形態の新規代行不可時処理は、Ｓ２９０の処理、即ち、新規故障ｃｈに対して待機フラグをセットすることである。
【０１２３】
何れかの出力チャンネルについて代行駆動が行われているときに、終了通知用フレームを受信した場合は（Ｓ２５０：ＹＥＳ）、その終了通知用フレームが、現在の代行中ｃｈに対してその代行駆動を終了すべき旨の終了通知であるか否か判断する（Ｓ３００）。そして、代行中ｃｈに対する終了通知ならば（Ｓ３００：ＹＥＳ）、代行中ｃｈの代行駆動を停止させる（Ｓ３１０）。
【０１２４】
そして、待機フラグがセットされているチャンネルがあるか否か判断し（Ｓ３２０）、待機フラグがセットされているチャンネルがなければこの代行駆動処理を終了するが、待機フラグがセットされているチャンネルがあった場合は、代行切替処理を行った上でこの代行駆動処理を終了する。本実施形態の代行切替処理は、Ｓ３３０の処理、即ち、待機フラグがセットされているチャンネルのうち、安全レベルが最も高いチャンネルに対して待機フラグをクリアしてその代行駆動を開始することである。
【０１２５】
終了通知用フレームを受信した場合に（Ｓ２５０：ＹＥＳ）、その終了通知用フレームが現在の代行中ｃｈに対する終了通知ではなかった場合は（Ｓ３００：ＮＯ）、終了通知対象のチャンネルにセットされている待機フラグをクリアして（Ｓ３４０）、この代行駆動処理を終了する。
【０１２６】
以上説明した本実施形態の制御システムによれば、各ＥＣＵ２０，３０，４０，・・・とは別にリカバリーＥＣＵ１５が備えられ、これにより各ＥＣＵ２０，３０，４０，・・・の駆動対象（負荷）を代行駆動することができる。
【０１２７】
そして、本実施形態では、リカバリーＥＣＵ１５において、代行駆動対象の駆動段毎に個別に汎用出力ドライバを設けるのではなく、駆動方式毎に１つずつ、汎用出力ドライバを設けている。つまり、同じ駆動方式の駆動段については、共通の１つの汎用出力ドライバによって代行駆動を行うようにしている。そのため、限られたリソースにて低コストで、出力故障が生じた出力チャンネルに対してその駆動対象（駆動段）を代行駆動することができる。
【０１２８】
また、各ＥＣＵ２０，３０，４０，・・・は、出力故障が生じた場合に故障通知用フレームを送出するが、その故障通知用フレームには、出力故障が生じた出力チャンネルに対応して設定された安全レベルも含まれている。
【０１２９】
そのため、同一駆動方式において出力故障が重複して発生した場合は、安全レベルが高い駆動対象ほど優先的に代行駆動されることになるため、出力故障発生に対して、必要性（優先度）に応じた適切な代行駆動が可能となる。
【０１３０】
［第２実施形態］
次に、第２実施形態の車載制御システムについて説明する。本実施形態の車載制御システムは、そのハードウェア構成自体は、基本的には図１に示した第１実施形態の車載制御システムと同じである。そして、本実施形態と第１実施形態とで異なるのは、次に述べる事項である。
【０１３１】
即ち、第１実施形態では、図４に示したように、安全レベルが「低」、「中」、「高」の３段階に設定されていたが、本実施形態では、安全レベルが、図７に示すように、低い方から順に「０」、「Ａ」、「Ｂ」、「Ｃ」の４段階に設定されている。
【０１３２】
また、第１実施形態では、出力故障の種類毎（出力チャンネル毎）に安全レベルが一意的に設定されていたが、本実施形態では、出力チャンネルに関連したスイッチやセンサ等からの入力情報（故障関連入力情報）がある場合には、その出力チャンネルについては、図７に示すように、その故障関連入力情報の内容毎に安全レベルが個別設定されている。
【０１３３】
即ち、図１に示すように、ボデーＥＣＵ２０には、照度センサ２４からの検出信号が入力される。ヘッドライトを正常に点灯させることができない故障（ヘッドライト出力故障）が生じた場合に、リカバリーＥＣＵ１５にてヘッドライトを代行駆動させる優先度は、車両外部の明るさにより異なり、例えば昼間の明るい時間帯であればヘッドライトを代行駆動させる優先度・必要性は低く、逆に、夜間であったりトンネル内などの暗い場所を走行している場合にはヘッドライトを代行駆動させる優先度・必要性は高くなる。
【０１３４】
そのため、ヘッドライト出力故障に対しては、図７に示すように、照度センサ２４による検出結果（故障関連入力情報）に応じて安全レベルが個別設定されている。具体的には、照度が「明」であれば安全レベルは「Ａ」であり、照度が「暗」であれば、安全レベルは、照度が「明」の場合の安全レベル「Ａ」よりも高い安全レベル「Ｂ」である。
【０１３５】
同様に、ワイパＥＣＵ３０についても、雨滴センサ３４からの検出信号が入力される。ワイパを正常に駆動せることができない故障（ワイパ出力故障）が生じた場合に、リカバリーＥＣＵ１５にてワイパを代行駆動させる優先度は、車両外部の降雨状況により異なり、例えば降雨が無い場合はワイパを代行駆動させる優先度・必要性は非常に低く、逆に、降雨が有る場合にはワイパを代行駆動させる優先度・必要性は非常に高くなる。
【０１３６】
そのため、ワイパ出力故障に対しては、図７に示すように、雨滴センサ３４による検出結果（故障関連入力情報）に応じて安全レベルが個別設定されている。具体的には、降雨「無し」であれば安全レベルは最も低い「０」であり、降雨「有り」であれば安全レベルは最も高い「Ｃ」である。
【０１３７】
このような構成により、本実施形態の車載制御システムでは、各ＥＣＵ２０，３０，４０，・・・は、図５に示した故障通知処理におけるＳ１３０の故障通知用フレームの作成を行う際、第１実施形態と同じように故障した出力チャンネルのチャンネル番号を取得すると共に故障した出力チャンネルの安全レベルを取得するが、この安全レベルを取得するにあたっては、センサからの検出信号などの対応する故障関連入力情報が存在する場合は、その検出結果も加味して、故障関連入力情報の内容毎に個別設定されている安全レベルを取得する。
【０１３８】
従って、本実施形態の車載制御システムによれば、１つの出力チャンネルに対して一律に１つの安全レベルが設定されているのではなく、故障関連入力情報が存在する出力チャンネルについては、故障関連入力情報の内容に応じて複数の安全レベルが設定されているため、故障関連入力情報が加味されたより適切な安全レベルを設定することが可能となる。そのため、出力故障が生じた場合、各ＥＣＵは、車両の実際の状態や周囲環境等に応じた安全レベルを送出することができ、これにより、リカバリーＥＣＵ１５は、実際の状況に応じたより適切な優先順位にて代行駆動を行うことができる。
【０１３９】
［第３実施形態］
次に、第３実施形態の車載制御システムについて説明する。本実施形態の車載制御システムも、そのハードウェア構成自体は、基本的には図１に示した第１実施形態の車載制御システムと同じである。そして、本実施形態と第１実施形態とで異なるのは、次に述べる事項である。
【０１４０】
即ち、ボデーＥＣＵ２０におけるＡ１チャンネルの出力故障（ドアロック出力故障）の安全レベルが、第１実施形態では図４に示したように「低」に設定されていたのに対し、本実施形態では、図８に示すように「中」に設定されている。
【０１４１】
つまり、第１駆動方式の各負荷の出力故障のうち、少なくともドアロック出力故障（Ａ１チャンネルの出力故障）とワイパ出力故障（Ｂ１チャンネルの出力故障）は、安全レベルが同一である。
【０１４２】
そのため、仮に、ドアロック出力故障とワイパ出力故障が重複して生じると、両者は駆動方式が同一（いずれも第１駆動方式）であることから、両者を同時にリカバリーＥＣＵ１５によって代行駆動することはできない。
【０１４３】
そこで本実施形態では、安全レベルが同一である場合にどちらを優先的に代行駆動させるべきかをリカバリーＥＣＵ１５が判断できるよう、各ＥＣＵ２０，３０，４０，・・・は、故障通知用フレームとして、図９（ａ）に示すように、安全レベルだけでなく更に故障関連入力情報に応じた故障関連ＩＤも加えたフレームを生成する。
【０１４４】
ここでいう故障関連入力情報は、第２実施形態で説明した故障関連入力情報と同じく、スイッチやセンサ等からの入力情報である。そして、例えばボデーＥＣＵ２０におけるヘッドライトを駆動させるＡ２チャンネルや、ワイパＥＣＵ３０におけるワイパモータを駆動させるＢ１チャンネルなどのように、対応する故障関連入力情報が存在する場合は、図８に示すように、その故障関連入力情報に応じた故障関連ＩＤが設定されている。
【０１４５】
例えば、ワイパ出力故障に対しては、安全レベル自体は「中」であるが、これに加えて更に、故障関連入力情報を示す故障関連ＩＤが、降雨状況に応じて設定されている。即ち、降雨「無し」の場合は「００・・・０１１」が設定され、降雨「有り」の場合は「００・・・０００」が設定されている。
【０１４６】
また例えば、ヘッドライト出力故障に対しては、周囲の照度に応じて故障関連ＩＤが設定されている。即ち、照度「明」の場合は「００・・・０１０」に設定され、照度「暗」の場合は「００・・・００１」に設定されている。
【０１４７】
なお、ドアロックモータを駆動させるＡ１チャンネルのように、故障関連入力情報が存在しない場合は、故障関連入力情報を示す故障関連ＩＤとして、規定の安全レベル（本例では「中」）に対応した値の数値「００・・・０１０」が設定されている。
【０１４８】
そのため、各ＥＣＵ２０，３０，４０，・・・は、出力故障が生じた場合には、図９（ａ）に示すような、故障関連ＩＤを含む故障通知用フレームを作成し、送信する。これにより、例えば図９（ｂ）に示すように、２つの故障ノードから同時に故障通知用フレームが送信され、しかも各々の安全レベルが同一であったとしても、安全レベルフィールドに続く故障関連入力情報フィールドにおいて調停がなされる。そして、故障関連ＩＤの数値が小さい方が調停勝ちとなり、逆に故障関連ＩＤの数値が大きい方は、やがて自身の出力レベルとバスレベルが異なることにより調停負けとなって送信を一旦停止し、後で再送することとなる。つまり、優先度の高いものほど故障慣例ＩＤの数値が小さくなるように設定されている。
【０１４９】
そして、このように構成された本実施形態の車載制御システムにおいて、リカバリーＥＣＵ１５の制御部１７が実行する代行駆動処理は、一部を除き、基本的には図６に示した第１実施形態の代行駆動処理と同じである。即ち、図６に示した第１実施形態の代行駆動処理と異なるのは、新規代行不可時処理（図６ではＳ２９０）と、代行切替処理（図６ではＳ３３０）であり、それ以外については図６の代行駆動処理と同じである。
【０１５０】
そこで、本実施形態の代行駆動処理について、第１実施形態の代行駆動処理と同じ部分については説明を省略し、第１実施形態と異なる上記２箇所（新規代行不可時処理及び代行切替処理）について図１０を用いて説明する。
【０１５１】
まず、図１０（ａ）は、本実施形態のリカバリーＥＣＵ１５における制御部１７が実行する代行駆動処理（図６参照）における、新規代行不可時処理を示すフローチャートである。新規故障ｃｈの安全レベルが代行中ｃｈの安全レベルよりも高くなかったことによってこの新規代行不可時処理に移行すると（図６のＳ２６０：ＮＯ）、本実施形態では、図１０（ａ）の処理が実行される。
【０１５２】
即ち、まず新規故障ｃｈと代行中ｃｈの安全レベルが同一であるか否かを判断する（Ｓ５１０）。そして、安全レベルが同一でなければ（Ｓ５１０：ＮＯ）、それは即ち、新規故障ｃｈの安全レベルが代行中ｃｈの安全レベルよりも低いということであるため、新規故障ｃｈに対して待機フラグをセットし（Ｓ５５０）、代行中ｃｈについては代行駆動をそのまま優先的に継続させる。
【０１５３】
一方、安全レベルが同一であった場合には（Ｓ５１０：ＹＥＳ）、故障関連入力情報に基づいて優先度を比較する（Ｓ５２０）。即ち、故障通知用フレームに含まれていた故障関連ＩＤに基づき、新規故障ｃｈと代行中ｃｈのどちらが優先度が高いかを判断する。そして、新規故障ｃｈの方が代行中ｃｈよりも優先度が高い（故障関連ＩＤの数値が小さい）場合は（Ｓ５２０：ＹＥＳ）、現在代行駆動されている代行中ｃｈに対し、その代行駆動を中断して待機フラグをセットする（Ｓ５３０）。そして、新規故障ｃｈの代行駆動を開始する（Ｓ５４０）。
【０１５４】
代行中ｃｈに対して新規故障ｃｈの優先度が高くなかった場合は（Ｓ５２０：ＮＯ）、新規故障ｃｈに対して待機フラグをセットし（Ｓ５５０）、代行中ｃｈの代行駆動を優先的に継続させる。
【０１５５】
次に、図１０（ｂ）は、本実施形態のリカバリーＥＣＵ１５における制御部１７が実行する代行駆動処理（図６参照）における代行切替処理を示すフローチャートである。代行中ｃｈの代行駆動が停止されたときに（Ｓ３１０）、待機フラグセット中のチャンネルが存在していたことによってこの代行切替処理に移行すると（図６のＳ３２０：ＹＥＳ）、本実施形態では、図１０（ｂ）の処理が実行される。
【０１５６】
即ち、まず待機フラグがセットされているチャンネルのうち、安全レベルが最も高いチャンネルを選択する（Ｓ６１０）。そして、選択されたチャンネル（安全レベル最高チャンネル）が複数存在するか否か判断し（Ｓ６２０）、複数存在しない場合、即ち安全レベル最高チャンネルが１つのみであった場合は（Ｓ６２０：ＮＯ）、その選択された１つのチャンネルを代行駆動対象のチャンネルに設定する（Ｓ６６０）。そして、その設定されたチャンネルに対し、待機フラグをクリアして代行駆動を開始する（Ｓ６５０）。
【０１５７】
一方、安全レベル最高チャンネルが複数選択された場合は（Ｓ６２０：ＹＥＳ）、故障関連入力情報に基づいて優先度を比較する（Ｓ６３０）。そして、故障通知用フレームに含まれていた故障関連ＩＤに基づき、優先度の最も高いチャンネルを選定して、そのチャンネルを、代行駆動対象のチャンネルに設定する（Ｓ６４０）。そして、その設定されたチャンネルに対し、待機フラグをクリアして代行駆動を開始する（Ｓ６５０）。
【０１５８】
このように構成された本実施形態の車載制御システムによれば、安全レベルの設定自体は第１実施形態と同じであるものの、安全レベルに加えて更に故障関連入力情報も、故障通知用フレームに含まれて送出される。そのため、リカバリーＥＣＵ１５は、同一の駆動方式について安全レベルが同一の故障通知用フレームが重複して受信されても、故障関連入力情報に基づいて、優先順位を適切に判断することができる。
【０１５９】
［変形例］
以上、本発明の実施の形態について説明したが、本発明の実施の形態は、上記実施形態に何ら限定されるものではなく、本発明の技術的範囲に属する限り種々の形態を採り得ることはいうまでもない。
【０１６０】
例えば、上記実施形態では、同一の駆動方式に対して汎用出力ドライバを１つ設けるようにしたが、複数の汎用出力ドライバを設け、同一の駆動方式の出力チャンネルに対して同時に複数の代行駆動を行えるようにしてもよい。このようにすることで、例えば同一の駆動方式において優先度の非常に高い出力チャンネルを同時に代行駆動する必要性がある場合に、それに対し適切且つ確実に対応することが可能となる。
【０１６１】
但し、汎用出力ドライバの数が増えると、その分、リソースやコスト等に影響が生じるため、汎用出力ドライバの数は、同一の駆動方式に対して必要最低限の数に抑えるのが好ましい。
【０１６２】
また、上記実施形態では、安全レベルを３段階（第１実施形態）或いは４段階（第２実施形態）に分けたが、このような分け方はあくまでも一例に過ぎない。
また、上記実施形態では、リカバリーＥＣＵ１５をＪＢ１０内に設けた例を示したが、これもあくまでも一例であり、リカバリーＥＣＵ１５をＪＢ１０とは別に設けるようにしてもよい。また、リカバリーＥＣＵ１５による代行駆動も、上記実施形態のようにＪＢ１０の各駆動段を介して行う方法に限らず、例えばリカバリーＥＣＵ１５から代行駆動対象の負荷へ直接配線して駆動出力を行うようにしてもよい。
【符号の説明】
【０１６３】
１０…ＪＢ、１１ａ…ボデー系第１駆動段、１１ｂ…ワイパ系第１駆動段、１１ｃ…ブレーキ系第１駆動段、１２ａ…ボデー系第２駆動段、１２ｂ…ワイパ系第２駆動段、１２ｃ…ブレーキ系第２駆動段、１３ａ…ボデー系第３駆動段、１３ｂ…ワイパ系第３駆動段、１３ｃ…ブレーキ系第３駆動段、１５…リカバリーＥＣＵ、１６，２３，３３，４３…通信ＩＦ、１７，２１，３１，４１…制御部、２０…ボデーＥＣＵ、２２，３２，４２…駆動部、２４…照度センサ、３０…ワイパＥＣＵ、３４…雨滴センサ、４０…ブレーキＥＣＵ、４４…ブレーキＳＷ、５１…記憶部、５２…故障部位判断部、５３…出力制御部、５４…出力選択部、６１…第１汎用出力ドライバ、６２…第２汎用ドライバ、６３…第３汎用ドライバ、６４…第Ｎ汎用ドライバ、７１…第１チャンネル切替部、７２…第２チャンネル切替部、７３…第３チャンネル切替部、７４…第Ｎチャンネル切替部、１００…通信線
【図１】
2011213210.tif 000003
【図２】
2011213210.tif 000004
【図３】
2011213210.tif 000005
【図４】
2011213210.tif 000006
【図５】
2011213210.tif 000007
【図６】
2011213210.tif 000008
【図７】
2011213210.tif 000009
【図８】
2011213210.tif 000010
【図９】
2011213210.tif 000011
【図１０】
2011213210.tif 000012