JP2006253921A

JP2006253921A - 車両用ネットワークシステム

Info

Publication number: JP2006253921A
Application number: JP2005065792A
Authority: JP
Inventors: Homare Maehara; 誉前原
Original assignee: Denso Ten Ltd
Current assignee: Denso Ten Ltd
Priority date: 2005-03-09
Filing date: 2005-03-09
Publication date: 2006-09-21

Abstract

【課題】一貫性があり、正確で確実な故障ノードの判定を行い得る車両用ネットワークシステムを提供すること。
【解決手段】車載機器を制御する複数の制御装置を、バスを介して接続し、各制御装置が前記バスを介して互いにデータを送受信するように構成された車両用ネットワークシステムにおいて、前記制御装置のうち少なくとも一つの制御装置は、当該制御装置に接続された前記車載機器を制御して他の前記制御装置へのデータの送受信と、他の制御装置の故障判定とを兼用する、ことを特徴としている。
【選択図】図１

Description

本発明は、車載機器の制御等を行う複数のノードを、ネットワークを介して接続した車両用ネットワークシステムに関する。詳しくは、所定のノードを故障判定マスターノードとして設定した車両用ネットワークシステムに関する。

従来から、主として自動車の車両用ネットワークとしてＣＡＮ（Controller Area Network）と呼ばれる通信プロトコルが採用されている（例えば、以下の非特許文献１及び２
）。ＣＡＮは、ＩＳＯ（International Organization for Standardization）で国際的に標準化されたシリアル通信プロトコルである。最近では、その高い性能と信頼性とから車内ＬＡＮ以外にも、船舶、医療機器等多方面で採用されている。

このようなＣＡＮを利用した車両用ネットワークシステムとして、非特許文献１に記載されているように、自動車のハードウェアを制御する複数のＥＣＵ（Electric Control Unit）がＣＡＮバスを介して接続される例がある。ＥＣＵの例として、エンジンやトラン
スミッション等を制御するエンジン系のＥＣＵや、ＶＩＣＳナビなどを制御する情報系のＥＣＵなどがある。

ＣＡＮプロトコルの特徴は、（１）バスが空いているときに、すべてのノード（ＥＣＵ）がメッセージ（以下、「フレーム」と称す。ＣＡＮプロトコルにおける通信単位である）の送信を始めることができるマルチマスタ方式が採用され、（２）バスに早くアクセスしたノードがフレームの送信権を得、（３）同時に複数のノードが送信を始めると、優先順位の高い識別子（ＩＤ）のフレームを送信するノードが送信権を得る、等が上げられる。ここで、ＩＤは、送信フレームに付加されるものであるが、フレームの送り先を示すものではなく、ＣＡＮバスにアクセスする際の優先順位を示すものである。

このようなマルチマスタ通信において、フレームを送信するノードはバスの通信状態や負荷に関係なくノードを構成するデバイス毎の周期にて送信を行う。また、自動車のスイッチ入力情報やエンジンの回転数など値の変化に応じてイベント送信を行うノードは、バスの通信状態等に関係なく発生したイベントに応じてフレームの送信が行われる。そして、同時にフレームが送信されると上述したＩＤにより調停（アービトレーション）が行われ、送信権を獲得したフレームが優先される。

一方、このような車両用ネットワークを利用した通信システムにおいて、特定のノードが正常動作できなくなった場合、他のノードからのフレームを送受信することができず、車載機器を正常に動作させることができない。

そこで、従来は、かかる車両用ネットワークシステムで、ダイアグマスタＥＣＵを別途設け、他のＥＣＵの動作状態を監視して異常動作をしているＥＣＵを検出するようにしたものがある（例えば、以下の特許文献１）。
「ＣＡＮ入門書」 www.renesas.com 「ＣＡＮとは？」 www.toyo.co.jp/car/CAN/CAN_General.htm 特開２００４−１７６７６号公報

しかしながら、ＣＡＮプロトコルなど優先度を設けてバスの調停を行うプロトコルによ
るネットワークを利用した通信システムでは、故障したノードを特定することが困難であるという問題点がある。例えば、故障によりあるノードがフレームを送信し続ける場合を考える。この場合、送信し続けられたフレームにより正常動作を行うノードからのフレームは正しく送信することができない。更に、ＣＡＮプロトコルのようにＩＤに優先度が割り当てられていると、送信し続けられたフレームのＩＤにより、通信を阻害されるフレームは変化してしまう場合がある。

例えば、図９の例で説明する。図９は、バス２０に複数のノード（ＥＣＵ）Ａ１０１〜ノードＥ１０５が接続され、各ノード間でフレームの送受信を行う車両用ネットワークシステムの例である。ここで、ノードＣ１０３は故障ノードであって、ノードＡ１０１にフレームを送信し続けている。かかる場合に、ノードＣ１０３からのフレームには最も優先度の高い「００１」が割り当てられていると、例えば、ノードＢ１０２から同時にフレームが送信されても、ノードＣ１０３からのフレームにバス２０の送信権が与えられてしまう。従って、ノードＢ１０２は正常に動作しているにも拘わらず、ノードＡ１０１はノードＣ１０３ではなく、ノードＢ１０２を異常状態と誤判定してしまう。かかる状況は、ノードＤ１０４やノードＥ１０５でも発生する。

また、ノードＣ１０３の優先度が「２００」の場合、その優先度より高いフレームを送信するノードＢ１０２やノードＤ１０４はノードＣ１０３からのフレームと同時にフレームを送信しても、ノードＡ１０１にフレームを送信することができる。しかし、ノードＥ１０５からのフレームはノードＣ１０３と同時に送信された場合、優先度が低いため、ノードＡ１０１に送信することができない。従って、ノードＡ１０１はノードＣ１０３ではなく、ノードＥ１０５を異常と誤判定する。

更に、異常状態であるノードからのフレームより高優先度と低優先度の２つのフレームを送信するノードは、あるノードでは正常、別のノードでは異常と判定される場合がある。

例えば、図９に示すように、ノードＥ１０５は、ノードＣ１０３より高優先度（「１１１」）と低優先度（「３００」）のフレームを送信し、ノードＡ１０１はこのうち低優先度のフレーム、ノードＢ１０２は高優先度のフレームを受信するように設定されている場合を考える。この場合、ノードＥ１０５が「１１１」の優先度を有するフレームを送信すると、ノードＢ１０２は受信することができるが、ノードＡ１０１は受信することができない。従って、ノードＡ１０１はノードＥ１０５を異常状態、ノードＢ１０２はノードＥ１０５を正常状態と判定する。

このように、優先度によりバスの調停が行われるネットワークでは、異常ノードの判定がばらばらで、しかも異常状態であるノードの特定が困難である、という問題点がある。

そこで、本発明は上記問題点に鑑みてなされたもので、その目的は、一貫性があり、正確で確実な故障ノードの判定を行い得る車両用ネットワークシステムを提供することにある。

上記目的を達成するために、本発明は、車載機器を制御する複数の制御装置を、バスを介して接続し、各制御装置が前記バスを介して互いにデータを送受信するように構成された車両用ネットワークシステムにおいて、前記制御装置のうち少なくとも一つの制御装置は、当該制御装置に接続された前記車載機器を制御して他の前記制御装置へのデータの送受信と、他の制御装置の故障判定とを兼用する、ことを特徴としている。これにより、例えば、一貫性のある正確で確実な故障ノードの判定を行い得る車両用ネットワークシステ
ムを提供することができる。

また、本発明は前記車両用ネットワークシステムにおいて、前記故障判定を兼用する制御装置は、電源供給後の一定時間他の制御装置から受信したデータに基づいて前記バス上に存在する前記他の制御装置を判定する、ことを特徴としている。これにより、例えば、バス上に存在する制御装置を随時判定するため、本車両用ネットワークシステムで制御装置の追加、削除を容易に行い得る。

更に、本発明は前記車両用ネットワークシステムにおいて、前記故障判定を兼用する制御装置は、電源供給後に一定回数他の制御装置から受信したデータに基づいて前記バス上に存在する前記他の制御装置を判定する、ことを特徴としている。これにより、例えば、上記同様制御装置の追加、削除を容易に行うことができる。

更に、本発明は前記車両用ネットワークシステムにおいて、前記故障判定を兼用する制御装置は、電源供給後の一定時間に一定回数他の制御装置から受信したデータに基づいて前記バス上に存在する前記他の制御装置を判定する、ことを特徴としている。

更に、本発明は前記車両用ネットワークシステムにおいて、前記故障判定を兼用する制御装置には、さらに不揮発性メモリを備え、前記故障判定を兼用する制御装置は、前記存在制御装置の判定結果を前記不揮発性メモリに記憶することを特徴としている。これにより、例えば、前回の存在ノード判定を照合して異常ノードの判定を行うことができる。

更に、前記車両用ネットワークシステムにおいて、前記制御装置は、前記存在制御装置の判定結果に基づいて前記他の制御装置の故障判定を行う、ことを特徴としている。これにより、例えば、故障判定の処理が存在ノード判定処理に基づいて行われるため、容易に故障ノードである制御装置を特定することができる。

更に、前記車両用ネットワークシステムにおいて、前記制御装置は、前記故障判定の結果を前記バス上の前記他の制御装置に送信する、ことを特徴としている。これにより、例えば、他の制御装置は故障対象の制御装置に関する情報を共有することができる。

更に、前記車両用ネットワークシステムにおいて、前記制御装置は、前記バス上に存在する前記他の制御装置の判定結果に基づいて、前記他の制御装置の組合せの中から最も優先度の低い識別子を有するデータとは異なる優先度の識別子を有するデータを受信したときは、当該データを送信した前記他の制御装置を故障した制御装置と判定する、ことを特徴としている。これにより、例えば、マルチマスタ方式を採用する車両用ネットワークシステムにおいても、一貫性のある正確で確実な故障判定を行い得る。

また、上記目的を達成するために本発明は、車載機器を制御する複数の制御装置を、バスを介して接続し、各制御装置が前記バスを介して互いにデータを送受信するように構成された車両用ネットワークシステムにおいて、前記制御装置のうち少なくとも一つの制御装置は、当該制御装置に接続された前記車載機器を制御して他の制御装置へのデータの送受信と、前記他の制御装置の故障判定とを兼用し、前記故障判定の結果を前記他の制御装置に送信する、ことを特徴としている。これにより、例えば、他の制御装置は故障した制御装置の情報を共有することができ、安定した車両状態を保つよう制御することも可能となる。

本発明によれば、マルチマスタ方式を採用する車両用ネットワークシステムにおいて、所定のノードを他のノードと同様に車載機器を制御して他のノードにデータの送受信を行
うと共に、故障判定マスターノードとして兼用するようにした。そして、故障判定の際に存在ノードを判定し、その判定結果に基づいて故障判定を行うようにしたため、一貫性のある正確で確実な故障ノードの判定を行うことができる。

本発明を実施するための最良の形態について、以下図面を参照しながら説明する。図１は、本発明が適用される車両用ネットワークシステム１の一例である。

図１に示すように、本車両用ネットワークシステム１は、複数のノードＡ１０乃至ノードＧ２６、及びバス２０とから構成され、各ノードＡ１０等はバス２０を介して互いに接続される。ここで、ノードＡ１０は故障判定マスターノードとして、他のノードＢ２１乃至ノードＧ２６の故障判定を行う。また、ノードＥ２４乃至ノードＧ２６は被制御対象の車載機器を制御する制御装置（ＥＣＵ）であり、ノードＢ２１乃至ノード２３Ｄは車載機器のセンサである。

また、バス２０上では本実施例においてＣＡＮプロトコルによる通信が行われる。そのため、ノードＡ１０乃至ノードＧ２６は、このＣＡＮプロトコルによる通信が行われるよう内部にコントローラを備える。

図２は、故障判定マスターノードの機能を有するノードＡ１０の構成を示す。ノードＡは、ＣＡＮプロトコルによる通信を行うためのコントローラ１１と、コントローラ１１等の制御を行うＣＰＵ１２と、ＣＰＵ１２で実行された故障診断プログラム１２２の実行結果を格納するためのＥＥＰＲＯＭ１３とから構成される。また、ノードＡ１０は、車載機器である被制御ハードウェア１５と接続され、この被制御ハードウェア１５を制御するＥＣＵとしての機能も有する。

ノードＡ１０のコントローラ１１はバッファ１１０を備え、各ノードＢ２１等からバス２０を介して受信したメッセージを記憶し、各ノードＢ２１等へ送信するメッセージを記憶する。

ＣＡＮプロトコルでは、かかるメッセージを一通信単位であるフレームとして送受信を行う。そして、このフレーム内に優先度を示すＩＤが付加される。例えば、図１にてノードＢ２１からのフレームに「００２」、ノードＣ２２からのフレームに「００３」、ノードＤ２３からのフレームに「００４」等のＩＤが付加されるものとする。そして、ノードＡ１０のコントローラ１１には、かかるＩＤが受信されるように予め設定される（図２参照）。前述したように、ＣＡＮプロトコルではマルチマスタ方式を採用するため、バス２０が空いているときには先にバス２０にアクセスしたノードからのフレームに送信権が与えられ、同時にフレームを送信したときはＩＤによる優先度の高いフレームが優先される。従って、ノードＢ２１とノードＣ２２とで同時にノードＡ１０にフレームを送信したときは優先度の高いノードＢ２１からのフレームに送信権が与えられる。

また、ＣＰＵ１２は通常処理プログラム１２１と本発明に係る故障診断プログラム１２２とを実行する。通常処理プログラム１２１は、例えば、他のノードＢ２１等とＣＡＮによるフレームの送受信を行うためのプログラムであったり、かかる送受信を行うため被制御ハードウェア１５からの情報を読み出したり、逆に情報を出力したりするためのプログラムである。一方、故障診断プログラム１２２は、どのノードＢ２１等が故障しているかの判定を行うプログラムである。尚、これらのプログラムは図示しないＲＯＭ等の記憶手段に格納され、処理の際にＣＰＵ１２が読み出すことで実行される。

ノードＡ１０が、故障判定マスターノードとしても機能するには、すべてのノードＢ２
１等に対する故障判定を行う必要性から、すべてのノードＢ２１等からのフレームを受信するようにしなければならない。つまり、ノードＡ１０は、本来の他のノードからのフレームの受信の他、故障判定のため他のすべてのノードからのフレームを受信するように設定される。例えば、図２に示す例では、ノードＡ１０のコントローラ１１には、更にノードＦ２５からのフレーム（ＩＤ「００６」）と、ノードＧ２６からのフレーム（ＩＤ「００７」）とを受信するよう設定される。かかる設定は、例えば、図示しないＲＯＭ等の記憶手段に格納されたプログラム（通常処理プログラム１２１でもよい）内でかかるＩＤを受信するようプログラムを作成する（又は書き換える）ことで実現される。

そして、ＣＰＵ１２は故障判定マスターノードとして機能するときは、故障診断プログラム１２２をＲＯＭ等の記憶手段から読み出して、バス２０に接続された全てのノードＢ２１等からのメッセージに対して実行できるようにしておく。

つまり、図２に示すよう、ＣＰＵ１２は通常時、通常処理プログラム１２１を実行してＩＤ「００２」乃至「００５」（ノードＢ２１乃至ノードＥ２４）に対する処理を行い、故障判定時には故障診断プログラム１２２を実行してＩＤ「００２」乃至「００５」のみならずＩＤ「００６」と「００７」（ノードＦ２５とノードＧ２６）に対する処理を行う。

このようにノードＡ１０は、被制御ハードウェア１５を制御して他のノードＢ２１等との間で情報のやりとりを行うとともに、他のノードＢ２１等の故障判定を行うことで、本来のノード（ＥＣＵ）としての機能と故障判定マスターノードとしての機能とを兼用している。このように通常の動作と故障判定の動作とをあるノードが兼用するため、別途故障判定のためだけにノードを構成する場合と比較して、コストの削減を図ることができる。なお、本実施例においてノードＡ１０はエンジンＥＣＵとして動作するとともに故障判定マスターノードとして動作する。

図３は、この故障診断プログラム１２２の一部である存在ノード判定処理のフローチャートを示す。この処理を実行することでＣＰＵ１２は、バス２０に接続された存在ノードの判定を行う。なお、図３以降に種々の処理のフローチャートを示すが、故障診断プログラム１２２の一部であっても、また別プログラムであってもよい。別プログラムの場合はかかるすべてのプログラムを総称して故障診断プログラム１２２としている。

本判定処理が開始されると（Ｓ１０）、ＣＰＵ１２はイグニッションオン後（ＩＧＯＮ後）一定時間経過したか否か判定する（Ｓ１１）。例えば、ＩＧＯＮを示すフレームを他ノードから受信したり、被制御ハードウェア１５からのＩＧＯＮを示す信号等を受信した後、図示しないタイマーにより一定時間経過しかた否かで判定する。

一定時間経過しないと（ＮＯ）、ＣＰＵ１２は受信ＩＤの受信履歴処理を行う（Ｓ１３）。例えば、故障判定マスターノードＡ１０で受信したフレームのＩＤの履歴をＲＡＭ等のメモリに記憶する。そして、一定時間経過するまで処理を繰り返す（Ｓ１１からＳ１３へのループ）。

一定時間経過後（Ｓ１１でＹＥＳ）、ＣＰＵ１２は受信ＩＤ履歴より存在ノードの判定を行う（Ｓ１２）。ＣＡＮプロトコルでは、受信ＩＤには、そのフレームを送信したノードの情報も含まれるからである。ここでＣＰＵ１２は、存在ノードの判定結果をＥＥＰＲＯＭ１３に格納する。前回の存在ノードの判定結果を利用することができるからである。例えば、今回の処理での存在ノードと前回の処理での存在ノードとを比較して、異常ノードを確定することもできる。そして、存在ノード判定処理が終了する（Ｓ１４）。

図４は、図３と同様に存在ノード判定処理の一例を示すフローチャートであるが、一定時間経過ではなく、フレームを一定回数受信したか否か（Ｓ２１）で判定が行われる点が異なる。この場合も、一定回数フレームを受信しないと（ＮＯ）、一定回数受信するまで受信ＩＤの履歴処理を行い（Ｓ２３からＳ２１へのループ）、一定回数受信したとき（Ｓ２１でＹＥＳ）、履歴ＩＤから存在ノードを判定する。この場合でも、存在ノードの判定結果（Ｓ２２）はＣＰＵ１２によってＥＥＰＲＯＭ１３に格納される。尚、一定回数フレームを受信したか否かは、例えば、バッファ１１０に蓄積されたフレームをＣＰＵ１２によってカウントすることで実行される。

図５は、図３等と同様に存在ノード判定処理の一例であるが、図３と図４とを組み合わせた処理である。ＩＧＯＮ後、一定時間経過せず（Ｓ３１でＮＯ）、かつ、一定回数経過しないと（Ｓ３２でＮＯ）、ＣＰＵ１２は受信ＩＤの履歴を取得する。そして、一定時間経過（Ｓ３１でＹＥＳ）又は一定回数経過（Ｓ３２でＹＥＳ）で、受信ＩＤ履歴より存在ノードの判定を行う（Ｓ３３）。ＥＥＰＲＯＭ１３に存在ノード判定結果が格納されるのは前述の例と同様である。

このように、一定時間等存在ノードの検出を行うことにより、バス２０上に存在するノードを随時判定することができ、本車両用ネットワークシステム１において各ノードを設定した後でも、ノードの追加や削除を容易に行うことができる。

図６は、存在ノード判定処理を用いた故障判定処理のフローチャートである。図３乃至図５に示す存在ノード判定処理で得られた結果を基にこの故障判定処理が行われる。まず、ＣＰＵ１２は本処理を実行するためのプログラム（故障診断プログラム１２２の一部でもよいし、別プログラムでもよい）をＲＯＭ等の記憶手段から読み出すことで処理が開始される（Ｓ４０）。

次いで、ＣＰＵ１２は存在ノード判定に基づく異常判定対象ノードを決定する（Ｓ４１）。つまり、ＣＰＵ１２は存在ノード判定処理（図３乃至図５）で得られた存在ノードを異常判定対象のノードとして対象ノードを決定する。実際には、ＣＰＵ１２は、ＥＥＰＲＯＭ１３に記憶された今回の存在ノードを読み出すことになる。例えば、存在ノード判定処理（図３乃至図５）で存在ノードがノードＢ２１乃至ノードＧ２６と判定したとき、異常判定対象ノードはこのノードＢ２１乃至ノードＧ２６となる。

次いで、ＣＰＵ１２は、異常パターンと一致するか否か判断する（Ｓ４２）。つまり、所定のノードの組合せから本来最も優先度の低いフレームを出力するノードとは異なるノードがあるか否かを判定する。

例えば、ノードＢ２１乃至ノードＤ２３の３つのノードの組合せを考える。それぞれノードＡ１０に対して「００２」「００３」「００４」のＩＤを有するフレームを送信するものとする。勿論、これらＩＤを有するフレームは故障判定マスターノードであるノードＡ１０で受信されるようノードＡ１０に設定される。

この場合、ノードＣ２２が故障ノードでフレームを送信し続けている場合、ノードＢ２１とノードＣ２２から同時に「００２」「００３」のＩＤを有するフレームを送信すると、ノードＢ２１は優先度が高いためバス２０の送信権を獲得してかかるＩＤのフレームをノードＡ１０に送信することができる。しかし、ノードＤ２３はＩＤ「００４」のフレームを送信し続け、ノードＢ２１からはいずれ送信しないことになるため、ノードＡ１０は、ノードＢ２１からのフレームに続きノードＣ２２からのＩＤ「００３」のフレームを受信する。そして、ノードＤ２３がＩＤ「００４」のフレームを送信しても、ノードＣ２２からのＩＤ「００３」のフレームの方が優先度は高く、しかもノードＣ２２からフレーム
を送信し続けているため、ノードＤ２３からのＩＤ「００４」のフレームをノードＡ１０は受信することができない。従って、故障判定マスターノードであるノードＡ１０は、本来最も低い優先度のフレームを出力するノードはノードＤ２３であるが、受信したフレームのうちノードＣ２２を最も低い優先度のフレームを出力するノードと判定する。つまり、ノードＡ１０は組合せの中から本来最も優先度の低いフレームを出力するノード（ノードＤ２３）とは異なる、ノードＣ２２があると判定する。

かかるノードＣ２２は、ノードの組合せの中では本来最も低い優先度とはならないはずである。ノードＡ１０は、故障ノードがフレームを送信し続けているために、本来受信するはずの最も低い優先度のフレームを受信できない。従って、この組合せの中で受信したフレームのＩＤが本来の最も低い優先度のフレームと異なるか否かを判断することで、故障ノードを判定するのである。

このような組合せは予め故障判定マスターであるノードＡ１０で設定（例えば、本処理のためのプログラムに格納）されており、すべての組合せで実行することで処理が実行される。そして、ＣＰＵ１２はこのノードを異常ノードとして確定し（Ｓ４３）、故障判定処理が終了する（Ｓ４４）。

一方、異常パターンと一致しない場合（Ｓ４２でＮＯ）は、異常ノードが存在しないため、異常ノードの確定を行うことなく処理が終了する（Ｓ４４）。

このように、マルチマスタ方式の通信プロトコルを採用している車両用ネットワークシステム１において、バス２０上に存在するノードの判定結果に基づいて、ノードの組合せの中から最も優先度の低い識別子を有するフレームとは異なる優先度の識別子を有するフレームを受信したときは、当該フレームを送信したノードを故障したノードと判定するようにしている。従って、故障ノードの判定がばらばらにならず一貫性のある正確で確実な故障判定を行うことができる。

以上のようにして、故障判定マスターであるノードＡ１０が故障ノードの判定を行うと、その結果を他のノードＢ２１乃至ノードＧ２６に送信する。この場合も、フレームとして送信することになるが、その優先度はバス２０に接続された各ノードＢ２１等の送信するフレームの中で最も高いものに設定する。故障ノードが存在しても必ず他のノードに故障結果を示すデータ（フレーム）を出力させるためである。

図７は、このような判定結果を受信した後の各ノードＢ２１等が行う処理の一例である。本処理が開始されると（Ｓ５０）、各ノードＢ２１等は（各ノード内のＣＰＵは）、故障判定マスターノードＡ１０からの判定結果を受信し（Ｓ５１）、判定結果に基づいて異常処置を行う（Ｓ５２）。異常処置とは、故障ノードによって他のノードからフレームを受信しなくとも、車両を正常動作させるようにする処置である。例えば、ノードＣ２２が故障ノードの場合、ノードＣ２２によって送信されなかったノードＤ２３等からのメッセージの値をデフォルト値に設定してノードＤ２３等からフレームを受信しなくても正常動作させるようにする。つまり、故障判定結果を通知することで他のノードは故障ノードを認識することができ、故障ノードによって受信できないフレームがあっても正常動作を行うことができる。

図８は、図７と略同様であるが、自己判定結果とを比較して異常処置等を行う処理の一例である。即ち、本処理が開始されると（Ｓ６０）、各ノードＢ２１等は故障判定結果を受信し（Ｓ６１）、次いで、故障判定マスターノードＡ１０の判定結果と自己判定結果とを比較する（Ｓ６２）。例えば、自己判定結果として各ノードＢ２１等において受信したフレームのＩＤから、本来受信すべきＩＤのフレームが受信できないと、受信できないＩ
Ｄを有するフレームを送信するノードを故障判定ノードと判定する。

故障判定マスターノードＡ１０の判定結果と自己判定結果とが一致すれば（Ｓ６２でＹＥＳ）、当該ノードを故障判定ノードとして確定し、前述した異常処置を行う（Ｓ６３）。そして、処理が終了する（Ｓ６４）。

一方、故障判定マスターノードＡ１０の判定結果と自己判定結果とが一致しないとき（Ｓ６２でＮＯ）、暫定処置を行い（Ｓ６５）、処理が終了する（Ｓ６４）。ここで、暫定処置とは、故障判定マスターノードＡ１０で判定した故障ノードや自己判定で判定した故障ノードを一時異常とする処置である。例えば、これら一時異常のノードに対して前述した異常処置を行うようにしてもよいし、故障判定マスターノードＡ１０の結果のみ異常処置を行うようにしてもよいし、更に一時異常のノードに対して何ら処置を行わないようにしてもよい。このように、自己判定結果との照合により、より確実な異常判定を行うことができる。

上述した例では、ノードＡ１０が故障判定マスターノードとして故障判定を行うものとして説明した。勿論、ノードＢ２１が故障判定マスターノードでもよいし、ノードＣ２２でもよい。バス２０に接続された少なくとも一つのノードが故障判定を行うようにすればよい。この場合に、かかるノードには図３乃至図６に示す処理を実行するための故障診断プログラム１２２がＲＯＭ等の記憶手段に格納され、更に他のすべてのノードからのフレームを受信するように設定されている必要がある。

また、上述した例では、ノードＢ２１乃至ノードＤ２３を車載機器のセンサとして説明した。勿論、他のノードＥ２４等と同様に車載機器を制御する制御装置であってもよい。

更に、上述した例では、存在ノードの判定処理をイグニッションオン後に行うものとして説明した。車両の電源供給後であれば、必ずしもイグニッションオン後に拘泥する必要はない。この場合でも上述した例と同様の作用効果を奏する。

更に、上述の例では、バス２０の通信プロトコルとして、ＣＡＮの例で説明した。勿論、それ以外にも、前述したマルチマスタ方式による通信プロトコルであれば、種々のものであってもよい。この場合でも同様の作用効果を奏する。

本発明が適用される車両用ネットワークシステムの例を示す図である。故障判定マスターノードの構成例を示す図である。存在ノード判定処理の動作を示すフローチャートである。存在ノード判定処理の動作を示すフローチャートである。存在ノード判定処理の動作を示すフローチャートである。故障ノード判定処理の動作を示すフローチャートである。故障ノード判定結果受信後の処理の動作を示すフローチャートである。故障ノード判定結果受信後の処理の動作を示すフローチャートである。故障ノードが発生したときの各ノードにおける受信状態を説明するための図である。

符号の説明

１車両用ネットワークシステム、１０故障判定マスターノード、１１コントローラ、１２ＣＰＵ、１３ＥＥＰＲＯＭ、１５被制御ハードウェア、２０バス、２１〜２６ノードＢ〜ノードＧ、１２１通常処理プログラム、１２２故障診断プログラム

Claims

車載機器を制御する複数の制御装置を、バスを介して接続し、各制御装置が前記バスを介して互いにデータを送受信するように構成された車両用ネットワークシステムにおいて、
前記制御装置のうち少なくとも一つの制御装置は、当該制御装置に接続された前記車載機器を制御して他の前記制御装置へのデータの送受信と、他の制御装置の故障判定とを兼用する、ことを特徴とする車両用ネットワークシステム。
請求項１記載の車両用ネットワークシステムにおいて、
前記故障判定を兼用する制御装置は、電源供給後の一定時間他の制御装置から受信したデータに基づいて前記バス上に存在する前記他の制御装置を判定する、ことを特徴とする車両用ネットワークシステム。
請求項１記載の車両用ネットワークシステムにおいて、
前記故障判定を兼用する制御装置は、電源供給後に一定回数他の制御装置から受信したデータに基づいて前記バス上に存在する前記他の制御装置を判定する、ことを特徴とする車両用ネットワークシステム。
請求項１記載の車両用ネットワークシステムにおいて、
前記故障判定を兼用する制御装置は、電源供給後の一定時間に一定回数他の制御装置から受信したデータに基づいて前記バス上に存在する前記他の制御装置を判定する、ことを特徴とする車両用ネットワークシステム。
請求項２乃至４記載の車両用ネットワークシステムにおいて、
前記故障判定を兼用する制御装置には、さらに不揮発性メモリを備え、
前記故障判定を兼用する制御装置は、前記存在制御装置の判定結果を前記不揮発性メモリに記憶する、ことを特徴とする車両用ネットワークシステム。
請求項２乃至４記載の車両用ネットワークシステムにおいて、
前記制御装置は、前記存在制御装置の判定結果に基づいて前記他の制御装置の故障判定を行う、ことを特徴とする車両用ネットワークシステム。
請求項６記載の車両用ネットワークシステムにおいて、
前記制御装置は、前記故障判定の結果を前記バス上の前記他の制御装置に送信する、ことを特徴とする車両用ネットワークシステム。
請求項６記載の車両用ネットワークシステムにおいて、
前記制御装置は、前記バス上に存在する前記他の制御装置の判定結果に基づいて、前記他の制御装置の組合せの中から最も優先度の低い識別子を有するデータとは異なる優先度の識別子を有するデータを受信したときは、当該データを送信した前記他の制御装置を故障した制御装置と判定する、ことを特徴とする車両用ネットワークシステム。
車載機器を制御する複数の制御装置を、バスを介して接続し、各制御装置が前記バスを介して互いにデータを送受信するように構成された車両用ネットワークシステムにおいて、
前記制御装置のうち少なくとも一つの制御装置は、当該制御装置に接続された前記車載機器を制御して他の制御装置へのデータの送受信と、前記他の制御装置の故障判定とを兼用し、前記故障判定の結果を前記他の制御装置に送信する、ことを特徴とする車両用ネットワークシステム。