JP5700426B2

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

Info

Publication number: JP5700426B2
Application number: JP2011072457A
Authority: JP
Inventors: 信貴川口
Original assignee: Daihatsu Motor Co Ltd
Current assignee: Daihatsu Motor Co Ltd
Priority date: 2011-03-29
Filing date: 2011-03-29
Publication date: 2015-04-15
Anticipated expiration: 2031-03-29
Also published as: JP2012209676A

Description

この発明は、車内の各ノードを通信バスで接続してネットワークが構築され、各ノードが定期的に発生する定期フレームおよび不定期に発生するイベントフレームを前記通信バスを介してやり取りする車両用ネットワークシステムに関し、詳しくは、通信バスの負荷状態の監視に関する。

近年、車両（自動車）の制御の分野においては、車内の各種制御のＥＣＵや、センサ、スイッチ等の状態監視のＥＣＵのネットワーク化が進んでいる。

そして、この種の車両が搭載する車両用ネットワークシステムは、ＣＡＮ（ＣｏｎｔｒｏｌｌｅｒＡｒｅａＮｅｔｗｏｒｋ）やＬＩＮ（ＬｏｃａｌＩｎｔｅｒｃｏｎｎｅｃｔＮｅｔｗｏｒｋ）に代表されるシリアル通信プロトコルのネットワークで形成され、このネットワークは、例えばＣＡＮのライン型のネットワークの場合、車内の各ＥＣＵのノードを通信バスに接続して構築される。

図４は上記ＣＡＮの車両用ネットワークシステムの一例を示し、Ａノード１００ａ、Ｂノード１００ｂ、Ｃノード１００ｃ、…が通信バス２００に接続されて車内のネットワークが構築される。各ノード１００ａ〜１００ｃはそれぞれマスタノードであり、マイクロコンピュータ構成のＥＣＵにより形成される。

そして、各ノード１００ａ〜１００ｃ、…は、異なるＩＤ（識別子）が割り当てられ、定期的に発生する定期フレームおよび、スイッチのオン、オフ等によって不定期に発生するイベントフレームに送信側のＩＤを付して送信する。また、各ノード１００ａ〜１００ｃ、…は、受信すべきフレームのＩＤがレジスタに登録され、このレジスタの登録されたＩＤを参照して通信バス２００の該当するＩＤの定期フレーム、イベントフレームを取り込んで受信する。

図５は例えばＡノード１００ａのメッセージバッファ１０１および登録されたＩＤを保持する不揮発性のレジスタ１０２を示し、レジスタ１０２にＩＤ＝２０、３０が登録されているとすると、ＩＤ＝２０の定期フレーム、イベントフレームは受信されてメッセージバッファ１０１の例えば＃１のバッファ領域に保持され、ＩＤ＝３０の定期フレーム、イベントフレームは受信されてメッセージバッファ１０１の例えば＃２のバッファ領域に保持されるが、ＩＤ＝２５の定期フレーム、イベントフレームは受信されず、メッセージバッファ１０１の＃１〜＃３２の３２個または＃１〜＃６４の６４個のバッファのいずれにも保持されない。そして、ノードによっては、メッセージバッファ１０１のほとんどのバッファが空き状態になっている。

ところで、このような車両用ネットワークシステムにおいては、各ノードＩ００ａ〜１００ｃ、…のプログラム更新等がノード間の通信状況によらず支障なく行えるようにするため、通信バス２００のバス負荷が設定されたしきい値（例えば負荷量１００％に対して３０％）を越えないように設定される。

しかし、例えばいずれかのノードに何らかの異常や故障が発生し、当該ノードのイベントフレームが連続または頻発して通信バス２００を占有する事態が生じると、通信バスのバス負荷が大きくなって前記しきい値を越える事態が発生する。この状態に気づかずに使用すると、ノード間の走行に重要なやり取りが困難になったり、前記のプログラム更新が行えなくなったりする。このような不都合は、近年、例えばＣＡＮのネットワークにつながるＥＣＵ等が多くなってきたことから、問題となってきている。

そこで、ＣＡＮのネットワークと通信プロトコルあるいは通信速度が異なる第２のネットワークとをゲートウェイノードにより中継するように構成されたＣＡＮの車両用ネットワークシステムにおいて、比較的処理負荷が小さく処理能力に余裕のあるゲートウェイノード（ＥＣＵ）にＣＡＮの通信バス（ＣＡＮバス）のバス負荷状態を監視するバス監視機能を備え、その監視結果に基づき、ＣＡＮの通信バスのバス負荷が増加したときに、ゲートウェイノードが一時的にデータを間引くなどしてバス負荷を小さくするよう調整し、ＣＡＮの車両用ネットワークシステムに支障が生じないようにすることが提案されている（例えば、特許文献１参照）。

特開２００６−２８７７３８号公報

特許文献１の車両用ネットワークシステムの場合、ネットワークにバス監視機能を備えた高機能で高価なゲートウェイノードを備える必要があり、高価になる。

そして、とくに前記の第２のネットワークが設けられず、例えばＣＡＮの単一のネットワークで構築される従来の車両用ネットワークシステムの場合、ゲートウェイノードを備えておらず、安価で低機能なＥＣＵで形成されるネットワークの汎用のノードでは、ゲートウェイノードのように、ネットワークの各ノードがやり取りする定期フレーム及びイベントフレームのすべてを監視して通信バスのバス負荷状態を監視することは困難である。

本発明は、車両用ネットワークシステムにおいて、ゲートウェイノードを備えることなく、安価に通信バスのバス負荷を監視できるようにすることを目的とする。

上記した目的を達成するために、本発明の車両用ネットワークシステムは、車内の各ノードを通信バスで接続してネットワークが構築され、各ノードが定期的に発生する定期フレームおよび不定期に発生するイベントフレームを前記通信バスを介してやり取りする車両用ネットワークシステムであって、前記ネットワークの所定のノードが前記通信バスの負荷状態を監視するバス負荷監視手段を備え、前記バス負荷監視手段は、前記定期フレームに基づく前記通信バスの定期負荷を予め記憶した記憶手段と、前記通信バスの前記イベントフレームを検出して前記イベントフレームに基づく前記通信バスの不定期負荷を算出する算出手段と、前記記憶手段が記憶している前記定期負荷と前記算出手段が算出した前記不定期負荷とから前記通信バスの負荷状態を監視する監視処理手段とを備えたことを特徴としている（請求項１）。

請求項１に記載の発明によれば、ネットワークのメッセージバッファに空きが多い所定のノードがバス負荷監視手段を備える。

そして、ネットワークの各ノードがやり取りする定期フレームは決まっているので、そのやり取りを監視することなく、バス負荷監視手段の記憶手段に、定期フレームに基づく通信バスのバス負荷を定期負荷として予め記憶する。

一方、各ノードがやり取りするイベントフレームは予測できないので、そのやり取りを実際に監視し、その監視結果に基づき、イベントフレームに基づく通信バスの不定期負荷のみを前記バス負荷監視手段の算出手段によって算出する。

そして、前記バス負荷監視手段の監視処理手段により、記憶手段が記憶している定期負荷と算出手段が算出した不定期負荷とから通信バスの負荷状態を監視する。

この場合、各ノードがやり取りするイベントフレームのみを監視して通信バスの負荷状態を監視することができるので、例えばＣＡＮの単一のネットワークで構築され、ゲートウェイノードを備えていない車両用ネットワークシステムであっても、安価な汎用のＥＣＵで形成されるネットワークの所定のノードにより、通信バスのバス負荷状態を監視することができ、低コスト化を図ることができる。

本発明の車両用ネットワークシステムの一実施形態のブロック図である。図１の所定のノードの詳細なブロック図である。図２の所定のノードの動作説明用のフローチャートである。従来の車両用ネットワークシステムの一例のブロック図である。図４の各ノードのフレーム受信の説明図である。

つぎに、本発明をより詳細に説明するため、本発明の一実施形態について、図１〜図３を参照して詳述する。

図１は本実施形態の車両用ネットワークシステムである車両（自動車）１のＣＡＮシステムを示し、このＣＡＮシステムは図４の従来構成と同様、車内の各ノード２ａ、２ｂ、２ｃ、…が通信バス３に接続された単位のネットワークで構築されている。各ノード２ａ〜２ｃ、…は、いずれもゲートウェイノードではなく、安価なマイクロコンピュータ構成のＥＣＵにより形成された汎用のノードであり、いずれもマスタノードとして動作する。なお、各ノード２ａ〜２ｃ、…のＥＣＵは、具体的には、車内のエンジン制御やブレーキ制御等の各制御のＥＣＵおよび、各センサのＥＣＵである。

そして、各ノード２ａ〜２ｃ、…は、図４のノード１００ａ〜１００ｃ、…と同様、異なるＩＤ（識別子）が割り当てられ、定期的に発生する定期フレームおよび不定期に発生するイベントフレームに送信側のＩＤを付して送信する。また、各ノード２ａ〜２ｃ、…は、少なくとも受信して処理すべきイベントフレームのＩＤが後述するレジスタ２１に登録され、このレジスタ２１の登録されたＩＤを参照して通信バス３の該当するＩＤの定期フレーム、イベントフレームを後述するメッセージバッファ２２に取り込んで受信する。各ノード２ａ〜２ｃ、…のメッセージバッファ２２は図５のメッセージバッファ１０１と同様、＃１〜＃３２の３２個または＃１〜＃６４の６４個のバッファ領域を有し、例えば舵角センサのノード等は多くのバッファ領域が空きになっている。また、各ノード２ａ〜２ｃ、…間の空きを確保してプログラム更新等が支障なく行えるようにするため、通信バス３のバス負荷が設定されたしきい値（例えば７０％の負荷量）を越えないように設定される。

そこで、舵角センサのノード等のメッセージバッファ２２に空きが多いノードが、本発明の所定のノードに予め設定される。図１ではノード２ａが所定のノードである。

図２は所定のノード２ａの一部の構成を示し、不揮発性のレジスタ２１、メッセージバッファ２２を備えるとともに、設定されたバス負荷監視プログラムを実行して形成される後述のバス負荷監視手段２３の不揮発性の記憶手段２４、算出手段２５、監視処理手段２６を備える。

レジスタ２１は、当該ノード２ａが取り込んで受信すべき１または複数のＩＤを通常処理用のＩＤとして保持するとともに、これらのＩＤを含むシステムの全ＩＤを受信監視用のＩＤとし保持する。受信監視用の各ＩＤは、簡単には送信側のノードのＩＤであってもよいが、本実施形態ではより詳しくノード間のフレームのやり取りを分類して監視するため、送信側と受信側のノードのＩＤを組み合わせたＩＤとし、これらのＩＤの別にやり取りするフレームを分類する。具体的には、説明を簡単にするため通信バス３に接続されるノードをノード２ａ〜２ｃの３個とし、ノード２ａ〜２ｃのＩＤをＩＤ＝ａ、ｂ、ｃとすると、最大で、ＩＤ＝（送信側ＩＤ、受信側ＩＤ）＝（ａ、ｂ）、（ａ、ｃ）、（ｂ、ａ）、（ｂ、ｃ）、（ｃ、ａ）、（ｃ、ｂ）の６通りのＩＤの組合せの別に分類する。なお、実際には、送信側の各ＩＤのノードから送信されたイベントフレームを受信するノードが限られることにより、ＩＤの組合せ数は前記の最大よりは少なくなる。

メッセージバッファ２２は、レジスタ２１に登録して設定された所定の１または複数のバッファ領域に、当該ノード２ａが取り込んで受信すべき各ＩＤの定期フレーム、イベントフレームを取り込んで受信し、残りの空きの各バッファ領域に、設定された期間Ｔ０に通信バス３に発生した各ＩＤのイベントフレームを、送信側と受信側のＩＤの組み合わせの別に取り込んで受信する。なお、各ＩＤのバッファ領域は定期フレームやイベントフレームの負荷量（情報量）より大きい容量に設定されている。また、所定の期間Ｔ０は例えば１〜数秒でありその間に数十フレームが通信バス３を介してやり取りされる。

記憶手段２４は、各期間Ｔ０にやり取りが予定される送信側と受信側のＩＤの組合せの別に定期フレームの大きさ（負荷量）が予め設定されて記憶する。なお、各期間Ｔ０にやり取りが予定される送信側のＩＤと受信側のＩＤはプログラム上既知であり、前記組合せの別の各ＩＤの定期フレームの負荷は、ノードの組合せ毎に個別に設定してもよいが、簡単には通信バス３の定期フレームによる平均負荷量をＩＤの個数で割って設定される。

算出手段２５は、前記期間Ｔ０にメッセージバッファ２２の各バッファ領域に取り込まれた送信側と受信側の組合せの別の各ＩＤのイベントフレームの負荷量から、各ＩＤ毎に、通信バス３のイベントフレームを検出してイベントフレームに基づく通信バス３の前記期間Ｔ０の不定期負荷を算出する。

監視処理手段２６は、記憶手段２４が記憶している定期負荷と算出手段２５が算出した不定期負荷を加算して各期間Ｔ０の通信バス３の負荷総量及び、送信側と受信側の組合せの別の各ＩＤ毎の個別負荷量を算出し、負荷総量および個別負荷量から期間Ｔ０の周期で通信バス３の負荷状態を監視する。

そして、いずれかのノード２ａ〜２ｃ、…に何らかの異常や故障が発生し、そのノードの送信が連続または頻発して通信バス３の負荷総量が設定されたしきい値を超えると、監視処理手段２６は、送信側と受信側の組合せの別の各ＩＤ毎の個別負荷から、設定された個別しきい値を超えているＩＤを検出し、このＩＤの組合せに基づいて異常や故障が発生たノードを特定して内部の不揮発性のメモリ等に異常情報として記憶保持するとともにフェールセーフ処理を実行し、例えば車両のメータ表示パネルの警告ランプを点灯（又は点滅）してドライバに異常や故障の発生を報知し、また、通信バス３の他のノード２ｂ、２ｃ、…に対して、車両１の走行に関連する重要情報以外の通信停止を連絡して通信バス３の負荷の軽減を図る。

図３は所定のノード２ａの前記バス負荷監視プログラムの実行に基づく通信バスのバス負荷監視処理の手順を示し、このバス負荷監視処理は車両１のイグニッション（以下、ＩＧという）キーやＩＧスイッチやドライバによってオン操作され、例えばエンジンが始動されると開始され、その後、ＩＧキーやＩＧスイッチがドライバによってオフ操作されるまで、略前記所定の期間Ｔ０の周期でくり返される。

そして、図３のステップＳ１〜Ｓ１６に示すように、まず、イベントフレームの全ＩＤがレジスタから読み出され、メッセージバッファ２２の＃１〜＃３２（＃６４）の各バッファ領域に、ノード２ａが受信すべき各ＩＤおよび監視すべき各ＩＤが設定された後（ステップＳ１）、監視処理手段２６の所定の期間Ｔ０のタイマーがＴ０＝０に初期リセットされて所定の期間Ｔ０の計時を開始する（ステップＳ２）、そして、記憶手段２４に保持されている送信側のＩＤと受信側のＩＤとを組合せたＩＤ毎の定期フレームの負荷の大きさが監視処理手段２６に読み出される（ステップＳ３）。

さらに、説明を簡単にするため前記したように通信バス３に接続されるノードをノード２ａ〜２ｃの３個とし、所定のノード２ａを含む各ノード２ａ〜２ｃのＩＤをＩＤ＝ａ、ｂ、ｃとすると、最大で、ＩＤ＝（送信側、受信側）＝（ａ、ｂ）、（ａ、ｃ）、（ｂ、ａ）、（ｂ、ｃ）、（ｃ、ａ）、（ｃ、ｂ）の６通りのＩＤの組合せの別の分類に基づき、例えば、ＩＤ＝ａのノード２ａにａイベントフレームが発生すると（ステップＳ４のＹＥＳ）、レジスタ２１に登録されているノード２ａを送信側とするＩＤの組合せ、例えばＩＤ＝（ａ、ｂ）、（ａ、ｃ）に該当する通信バファのａイベントフレームがメッセージバッファ２２の対応するバッファ領域に書き込まれ、書き込まれた各ＩＤのａイベントフレームの情報量から算出手段２５がａイベントフレームの最新の負荷量（情報量）をＩＤ毎に算出する（ステップＳ５）。同様に、ＩＤ＝ｂのノード２ｂから送信されるｂイベントフレームが発生すると（ステップＳ６のＹＥＳ）、レジスタ２１に登録されているノード２ｂを送信側とするＩＤの組合せ、例えばＩＤ＝（ｂ、ａ）、（ｂ、ｃ）に該当するｂイベントフレームがメッセージバッファ２２の対応するバッファ領域に書き込まれ、書き込まれた各ＩＤのｂイベントフレームの情報量から算出手段２５がｂイベントフレームの最新の負荷量（情報量）をＩＤ毎に算出する（ステップＳ７）。同様に、ＩＤ＝ｃのノード２ｃから送信されるｃイベントフレームが発生すると（ステップＳ８のＹＥＳ）、レジスタ２１に登録されているノード２ｃを送信側とするＩＤの組合せ、例えばＩＤ＝（ｃ、ａ）、（ｃ、ｂ）に該当するｃイベントフレームがメッセージバッファ２２の対応するバッファ領域に書き込まれ、書き込まれた各ＩＤのｃイベントフレームの情報量から算出手段２５がｃイベントフレームの最新の負荷量（情報量）をＩＤ毎に算出する（ステップＳ９）。送信側のＩＤが同じでも受信側のＩＤが異なる場合は、同じ内容のフレームでも受信側のＩＤの数だけ送信がくり返されて負荷量が増えるからである。

つぎに、算出手段２５により、各ＩＤ毎のイベントフレームの最新の負荷量を加算して通信バス３のイベントフレームの負荷総量（不定期負荷）が算出される（ステップＳ１０）。

そして、イベントフレームについての通信バス３上の各ＩＤ毎の負荷量および負荷総量の算出を、所定の期間Ｔ０内にくり返し（ステップＳ１１のＮＯ）、所定の期間Ｔ０が経過するとタイマを停止し、監視処理手段２６により、所定の期間Ｔ０における定期負荷と不定期負荷とを加算した負荷から、通信バス３の単位時間（例えば１秒）当たりの負荷総量を算出する（ステップＳ１２）。

そして、算出した負荷総量が設定されたしきい値（例えば３０％）内であれば、監視処理手段２６は、いずれのノード２ａ〜２ｃにも異常や故障が発生しておらず正常であると判断し（ステップＳ１３のＹＥＳ）、何もせずにステップＳ２に戻って次の所定の期間Ｔ０の監視を行なう。

一方、通信バス３の負荷総量が前記の設定されたしきい値を超えると、監視処理手段２６は、いずれかのノード２ａ〜２ｃに何らかの異常や故障が発生し、当該ノードのイベントフレームが連続または頻発して通信バス２００を占有する事態が生じていると判断し（ステップＳ１３）、所定の期間Ｔ０のＩＤ別の単位時間の負荷量（個別負荷量）とそれぞれの設定されたしきい値（個別しきい値）とを比較し、個別しきい値を上回ったＩＤから異常や故障が発生しているノードを特定し（ステップＳ１４）、そのノードに異常（故障）が発生している旨を通知するイベントフレームを送信し、異常（故障）が発生している特定のノードに、異常が発生している旨を通知し（ステップＳ１５）、そのノードの外部からの通信停止等を可能にする。さらに、フェールセーフ処理を実行し、残りのノードに対しても車両１の走行に関連する重要な情報のフレーム以外の送信の禁止を通知し（ステップＳ１６）、通信バス３の空き容量を極力確保する。

以上説明したように、本実施形態の場合、車両１の車両用ネットワークシステムのネットワークのメッセージバッファ２２に空きが多い所定のノード２ａがバス負荷監視手段２３を備える。

そして、ネットワークの各ノード２ａ〜２ｃ、…がやり取りする定期フレームは決まっているので、そのやり取りを監視することなく、バス負荷監視手段２３の記憶手段２４に定期フレームに基づく通信バス３のバス負荷を定期負荷として予め記憶する。

一方、各ノード２ａ〜２ｃ、…がやり取りするイベントフレームは予測できないので、そのやり取りをバス負荷監視手段２３により実際に監視し、その監視結果に基づき、イベントフレームに基づく通信バスの不定期負荷のみを算出手段２５によって算出する。

そして、バス負荷監視手段２３の監視処理手段２６により、記憶手段２４が記憶している定期負荷と算出手段２５が算出した不定期負荷とから通信バス３の負荷状態を監視することができる。さらに、監視結果に基づいて、異常や故障が発生しているノードを特定し、そのノードに対して異常が発生している旨を通知することができる。また、各ノード２ａ〜２ｃ、…に対して、車両１の走行に関連する重要な情報のフレーム以外の送信を禁止し、通信バス３の空き容量を極力確保し、プログラム更新等に支障が生じないようにするとともに、ノード間のやり取りを極力維持するようにしてバス負荷の異常に基づくシステムの致命的危機を予防し回避することも可能にする。

そして、ＣＡＮの単一のネットワークで構築され、ゲートウェイノードを備えていない本実施形態の車両用ネットワークシステムにおいて、安価な汎用の各ノード２ａ〜２ｃ、…がやり取りするイベントフレームのみを監視して通信バス３の負荷状態を安価に監視することができ、低コスト化を図ることができる。

また、監視結果に基づき、異常や故障が発生しているノードを特定し、そのノードが送信したイベントフレーム等から、容易にソフトウェアのバグを追跡して迅速に不具合の原因を調査し、復旧等することができる。

そして、本発明は上記した実施形態に限定されるものではなく、その趣旨を逸脱しない限りにおいて上述したもの以外に種々の変更を行なうことが可能であり、例えば、バス負荷監視手段の構成等は図２の構成に限るものではなく、通信バスに接続されるノードの個数等もどのようであってもよい。

そして、前記実施形態では、ＣＡＮのネットワークで構築された車両用ネットワークシステムに適用して説明したが、ＬＩＮのネットワークで構築された車両用ネットワークシステム等にも同様にして本発明を適用することができ、本発明は、種々の車両の車両用ネットワークシステムに適用することができる。

１車両
２ａ〜２ｃノード
３通信バス
２３バス負荷監視手段
２４記憶手段
２５算出手段
２６監視処理手段

Claims

車内の各ノードを通信バスで接続してネットワークが構築され、各ノードが定期的に発生する定期フレームおよび不定期に発生するイベントフレームを前記通信バスを介してやり取りする車両用ネットワークシステムであって、
前記ネットワークの所定のノードが前記通信バスの負荷状態を監視するバス負荷監視手段を備え、
前記バス負荷監視手段は、
前記定期フレームに基づく前記通信バスの定期負荷を予め記憶した記憶手段と、
前記通信バスの前記イベントフレームを検出して前記イベントフレームに基づく前記通信バスの不定期負荷を算出する算出手段と、
前記記憶手段が記憶している前記定期負荷と前記算出手段が算出した前記不定期負荷とから前記通信バスの負荷状態を監視する監視処理手段とを備えたことを特徴とする車両用ネットワークシステム。