JP2015202839A - 車載ネットワークシステム及び車載中継装置 - Google Patents

Abstract

【課題】車載制御装置がフレーム通信間隔をネットワークに接続された外部装置に通信する仕組みの場合に、ネットワークが高負荷となった場合でもフレーム消失を防止できる車載ネットワークシステム及び車載中継装置を提供する。
【解決手段】ＧＷ３は、ＥＣＵ５からＦＣを受信した際に、診断ツール１０からのデータが送信キュー１２に有る場合は、ＦＣのＳＴｍｉｎを０から１０に書換えて診断ツール１０へ送信する。これにより、診断ツール１０はＣＦの送信間隔を大きく変更するようになるので、ＥＣＵ５は、診断ツール１０からのＣＦを確実に受信することができる。
【選択図】図６

Description

本発明は、ネットワーク同士を車載中継装置により接続した車載ネットワークシステム及びその車載中継装置に関する。

例えば、車載ネットワークシステムのダイアグ通信では、ＩＳＯ（International Organization for Standardization）１５７６５の規定により、ネットワークに接続された外部装置からのフレーム送信の最小間隔（ＳＴｍｉｎ）をＥＣＵ（Electronic Control Unit）が指定する仕組み（フローコントロールで通知）を規定しているが（特許文献１参照）、ＳＴｍｉｎ値には十分なマージンが確保されていないことが多く、ＩＳＯ１５７６５の運用としてＳＴｍｉｎ＝０（＝０ｍｓ）の場合もある。これは、フレーム送信間隔が長くなると、それだけ通信時間が長くなり、特に外部装置からＥＣＵに大量のデータを送信する場合は、その影響が顕著となるからである。

特表２００５−５３４２６７号公報

ところで、外部装置からＥＣＵに大量にデータを送信する一例として、外部装置としての診断ツールによりＥＣＵのプログラムを書換えるリプログ実行時に、診断ツールからＥＣＵに大量のデータを連続して送信することにより、ＥＣＵが診断ツールから大量のデータを短時間で受信する場合がある。このような状態でネットワークが高負荷となると、ダイアグフレームは制御フレームより優先度が低く運用されているため、ダイアグフレームの未受信（フレーム消失）が発生し、ＥＣＵがデータを受信できなくて通信遅延が発生するようになる。このような通信遅延は、診断ツールからＥＣＵに通常のダイアグフレームの送信時にネットワークの負荷が一時的に極めて高くなった場合でも生じる。

本発明は上記事情に鑑みてなされたもので、その目的は、車載制御装置がフレーム通信間隔をネットワークに接続された外部装置に通信する仕組みの場合に、ネットワークが高負荷となった場合でもフレーム消失を防止できる車載ネットワークシステム及び車載中継装置を提供することにある。

請求項１の発明によれば、車載制御装置は、外部装置からファーストフレームを受信すると、通信性能を示すフローコントロールを送信する。車載中継装置は、通信負荷判断手段により車載制御装置側のネットワークの通信負荷を判断しており、車載制御装置からフローコントロールを受信した場合に通信負荷が高いときは、フローコントロールが示す通信性能を低下させるように書換えて外部装置へ送信する。これにより、外部装置が例えばリプログのために大量のコンセキュティブフレームを車載制御装置に送信する際にネットワークの通信負荷が高くなったり、外部装置から通常のコンセキュティブフレームを車載制御装置に送信する際にネットワークの通信負荷が一時的に極めて高くなったりした場合は、外部装置はコンセキュティブフレームの送信間隔を大きくして送信するので、車載制御装置は、外部装置からのコンセキュティブフレームを確実に受信することができる。

第１実施形態における車載ネットワークシステムを示すブロック図 送信キューを示す模式図 診断ツールとＥＣＵとの間の通信手順を示す図 フローコントロールのパラメータを示す図 従来の診断ツールとＧＷとＥＣＵとの間の通信手順を示す図 本発明の診断ツールとＧＷとＥＣＵとの間の通信手順を示す図 ＦＣ受信処理を示すフローチャート 第２実施形態におけるＦＣ受信処理を示すフローチャート

（第１実施形態）
以下、本発明の第１実施形態について図１から図７を参照して説明する。
図１に示すように、車載ネットワークシステムは、車両１に搭載されたネットワークＡ〜Ｃから構成されている。
ネットワークＡは、バス２、ゲートウェイ装置（以下、ＧＷ）３（車載中継装置、通信負荷判断手段に相当）により構成されており、バス２にノードとしてのＧＷ３が接続されている。
ネットワークＢは、バス４、複数のＥＣＵ５（車載制御装置に相当）、ＧＷ３、ＧＷ６により構成されており、バス４にノードとしてのＥＣＵ５、ＧＷ３、ＧＷ６が接続されている。

ネットワークＣは、バス７、複数のＥＣＵ８、ＧＷ６により構成されており、バス７にノードとしてのＥＣＵ８、ＧＷ６が接続されている。
ＧＷ３、６は、図示しないＣＰＵ、ＲＯＭ、ＲＡＭ、ＬＡＮコントローラを備えて構成されている。ＣＰＵは、ＲＯＭに記憶されたプログラムに従って各種処理を実行する。ＬＡＮコントローラは、各ネットワークＡ〜Ｃの各通信プロトコルに規定されたデータフォーマットに従ってデータの中継を行う。

ＧＷ３は、ネットワークＡの通信プロトコルとネットワークＢの通信プロトコルとを整合させた状態でデータの中継を行う。ＧＷ６は、ネットワークＢの通信プロトコルとネットワークＣの通信プロトコルとを整合させた状態でデータの中継を行う。
ネットワークＡ〜Ｃの通信プロトコルは同一の場合もあるし、互いに異なっている場合もある。本実施形態では、ネットワークＡ，Ｂの通信プロトコルはＣＡＮ（controller area network）通信プロトコル、ネットワークＣの通信プロトコルはＬＩＮ（Local Interconnect Network）通信プロトコルである。本発明が対象とするネットワークはＣＡＮ通信プロトコルであることから、ネットワークＡ，Ｂが対象となる。

ＧＷ３は、ネットワークＡ〜Ｃに対応して例えばファーストインファーストアウト（ＦＩＦＯ）方式のダイアグフレーム用送信キューを有している。このダイアグフレーム用送信キューは送信データを一時的に記憶するバッファからなり、バスが利用可能（バスアイドル状態）であれば記憶しているデータの内、古いデータから順に送信する。この場合、ネットワークＡは通信負荷が高くなることはないことから、図２（ａ）に示すように診断ツール接続バスダイアグフレーム用送信キュー１１は一つのバッファから構成されている。これに対して、図２（ｂ）に示すようにネットワークＢに対応するＥＣＵ接続バスダイアグフレーム用送信キュー１２は、ネットワークＢの通信負荷が高くなることを見込んで複数のバッファから構成されている。送信キューの送信動作は、マルチマスタ・プロトコル及びＣＳＭＡ／ＣＤ（Carrier Sense Multiple Access/Collision Detection）機能を備えたハードウェアによりバスアイドル状態では連続的に行われる。尚、図２（ｂ）に示すＥＣＵ接続バスダイアグフレーム用送信キュー１２は模式的に示したものであり、実際のバッファ数とは異なる。また、診断ツール接続バスダイアグフレーム用送信キュー１１を複数のバッファから構成してもよい。

ＥＣＵ５，８は、図示しないＣＰＵ、ＲＯＭ、ＲＡＭ、ＬＡＮコントローラを備えて構成されている。ＣＰＵは、ＲＯＭに記憶されたプログラムに従って各種処理を実行する。ＬＡＮコントローラは、各ネットワークＡ〜Ｃの各通信プロトコルに規定されたデータフォーマットに従ってデータの送受信を行う。

ＣＡＮ通信プロトコルのネットワークＡ，ＢのノードとなるＧＷ３、ＥＣＵ５にはＬＡＮコントローラとしてＣＡＮコントローラが搭載されている。ＣＡＮ通信プロトコルのネットワークＢ及びＬＩＮ通信プロトコルのネットワークＣのノードとなるＧＷ６にはＬＡＮコントローラとしてＣＡＮコントローラ及びＬＩＮトランシーバが搭載され、ネットワークＣのノードとなるＥＣＵ８にはＬＡＮコントローラとしてＬＩＮトランシーバが搭載されている。

ネットワークＡの末端には診断ツール接続コネクタ９が接続されており、その診断ツール接続コネクタ９に診断ツール１０（外部装置に相当）が接続可能となっている。診断ツール１０にはＬＡＮコントローラとしてＣＡＮコントローラが搭載されており、診断ツール１０が診断ツール接続コネクタ９に接続された状態では診断ツール１０はネットワークＡのノードを構成する。診断ツール１０は、各ＥＣＵ５，８から故障診断等のための各種情報を収集するためのものである。

ＣＡＮ通信プロトコルの診断インターフェースは、ＩＳＯ１５７６５（フレームに関する規定）、ＩＳＯ１４２２９（メッセージに関する規定）に基づいている。
ＩＳＯ１５７６５の規定では、図３に示すようにデータ送信側となる診断ツール１０とデータ受信側となるＥＣＵ５との間の通信が行われる。

（１）診断ツール１０が送信開始を送信する（Ｆｉｒｓｔ Ｆｒａｍｅ（以下、ＦＦ））。
（２）ＥＣＵ５は、自分自身の受信性能を送信する（Ｆｌｏｗ Ｃｏｎｔｒｏｌ（以下、ＦＣ））。つまり、その後にデータ送信側から送られてくる送信データに対し、自分はどれだけの間隔で受信できるかをデータ送信側に伝えるのである。
（３）診断ツール１０は、受信した受信性能に従って残りのデータを送信する（ＣｏｎｓｅｃｕｔｉｖｅＦｒａｍｅ（以下、ＣＦ））。

上記（２）で説明したように、ＩＳＯ１５７６５では、データ受信側は、自分の受信性能をデータ送信側にＦＣで送信することが規定されている。
ＦＣは、図４に示すようにＦＳ、ＢＳ、ＳＴｍｉｎの３つのパラメータから構成されている。本発明は、それらのパラメータの内、ＳＴｍｉｎに関することから、ＳＴｍｉｎについて説明する。

ＳＴｍｉｎはデータ送信側が送信するＣＦの間隔を規定するもので、ＣＦ−ＣＦ間を規定以上空ければデータ受信側が受信可能であることを規定している。例えば、ＳＴｍｉｎが例えば１００の場合は、ＣＦとＣＦとの間を１００ｍｓ以上空ければデータ受信側が受信可能であることを示している。しかし、フレーム送信間隔が長くなると、それだけ通信時間が長くなり、特に大量にデータを通信する場合はその影響が顕著となることから、ＳＴｍｉｎ＝０（＝０ｍｓ）に設定しているのが一般的である。

次に、図５を参照して、診断ツール１０、ＧＷ３、ＥＣＵ５間の信号の流れについて説明する。尚、ＥＣＵ５にはＦＣのＳＴｍｉｎとして０が設定されているものとする。
まず、診断ツール１０からＧＷ３を介してＥＣＵ５へＦＦが送信されると、ＥＣＵ５からＧＷ３を介してＦＣ（ＳＴｍｉｎ＝０）が診断ツール１０へ送信される。

診断ツール１０は、ＦＣを受信すると、ＣＦ＃１、＃２、＃３……＃ｎを順次送信する。この場合、ＳＴｍｉｎ＝０であることから、診断ツール１０は、バスアイドル状態ではＣＦを連続的に送信する。そして、ＣＦ＃ｎの送信が完了すると、１ブロックのデータ送信が終了する。

以上のようにして、診断ツール１０からＥＣＵ５へのデータ送信が繰り返されることで、１セグメントのデータの送信が完了する。
ところで、例えば診断ツール１０によりＥＣＵ５のプログラムを書換えるリプログ実行時は、ＥＣＵ５が大量の送信データを短時間で受信する状況が発生する。このような場合に、ネットワークＢが高負荷となると、ダイアグフレームは制御フレームより優先度が低く運用されているため、図５に示すようにダイアグフレームの未受信（フレーム消失）が発生し、ＥＣＵ５が送信データを受信できなくて通信遅延が発生するようになる。このような通信遅延は、診断ツール１０からＥＣＵ５に通常のダイアグフレームの送信時にネットワークＢの負荷が一時的に極めて高くなった場合でも生じる。

そこで、本実施形態では、ＧＷ３は、例えば、ＥＣＵ５から診断ツール１０に対してＣＦを中継する際に、ネットワークＢの通信負荷が高い場合は、ＥＣＵ５から受信したＦＣのＳＴｍｉｎを通信性能が低下するように書換えて診断ツール１０へ送信するようになっている。

即ち、ＧＷ３は、ＥＣＵ５からＦＣを受信すると、図７に示すように、受信したＦＳが０かを判断する（Ｓ１０１）。ＥＣＵ５が正常に受信可能な場合は、ＦＳは０であるので（Ｓ１０１：０）、受信したＢＳが１以外かを判断する（Ｓ１０２）。ＢＳが１の場合は（Ｓ１０２：１）、１ブロック（データ）を受信可能なハンドシェーク通信である。ハンドシェーク通信では、上述したネットワークＢの通信負荷変動による課題は生じないことから、ＥＣＵ接続バスダイアグフレーム用送信キュー（以下、送信キュー）１２を確認する（Ｓ１０３）。送信キュー１２に未送信データが無い場合は（Ｓ１０４：データ無）、ＦＣを送信する（Ｓ１０５）。つまり、ＥＣＵ５が診断ツール１０からのＣＦを遅滞なく受信可能な場合は、ＧＷ３はＦＣの中継を行うだけである。

これに対して、バスが高負荷となると、送信キュー１２にＣＦが有るとして送信データが有るようになるので（Ｓ１０４：データ有）、ＥＣＵ５から受信したＦＣのＳＴｍｉｎに１０（＝１０ｍｓ）を加算して診断ツール１０へ送信する（Ｓ１０６）。つまり、ＳＴｍｉｎを受信性能が低下するように書換えてＦＣを送信するのである。

診断ツール１０は、ＧＷ３からＦＣを受信すると、ＳＴｍｉｎ＝１０であることから、ＣＦの送信間隔を１０ｍｓに変更して送信する。これにより、図６に示すように診断ツール１０からＣＦの送信間隔が１０ｍｓとなるので、ＥＣＵ５は、ネットワークＢの通信負荷が高くなった場合であっても、診断ツール１０からのＣＦを確実に受信することができる。

このようにして送信キュー１２の送信データの滞留が解消されると、ＧＷ３は、送信キュー１２に未送信データが無くなることから（Ｓ１０４：データ無）、ＥＣＵ５から受信したＦＣをそのまま診断ツール１０へ送信するようになる（Ｓ１０５）。すると、診断ツール１０は、ＣＦをＳＴｍｉｎ＝０、つまり連続的に送信するようになる。この場合、ＧＷ３の送信キュー１２には空の状態で診断ツール１０からの送信データが記憶されるようになるので、送信キュー１２に記憶されたデータは直ちにＥＣＵ５へ送信されるようになる。

このような実施形態によれば、次のような効果を奏することができる。
ＧＷ３は、ＥＣＵ５からＦＣを受信した際に、送信キュー１２に送信データが有る場合は、ＦＣのＳＴｍｉｎを通信性能が低下するように書換えて診断ツール１０へ送信するので、診断ツール１０はＣＦの送信間隔を大きく変更するようになり、この結果、ＥＣＵ５は診断ツール１０からのＣＦを確実に受信することができる。
送信キュー１２のデータの有無でネットワークＢの通信負荷を判断するようにしたので、特別な手段を用いることなくネットワークＢの通信負荷を容易に判断することができる。

（第２実施形態）
本発明の第２実施形態について図８を参照して説明する。この第２実施形態は、送信キュー１２の空き容量に応じてＳＴｍｉｎを段階的に変更することに特徴を有する。尚、図８に示すフローチャートについて、図７に示すフローチャートと同一のステップには同一ステップ番号を付して説明を省略する。

ＧＷ３は、図８に示すように、送信キュー１２に未送信データが有る場合は（Ｓ１０４：データ有）、空き容量に応じた値をＳＴｍｉｎに段階的に設定する（Ｓ２０１）。具体的には、送信キュー１２の空きが無い場合はネットワークＢの通信負荷が極めて高くなったとしてＳＴｍｉｎに１２７（最大）（＝１２７ｍｓ）に設定する。空きが１〜２個となった場合はネットワークＢの通信負荷が高くなったとしてＳＴｍｉｎに２０（＝２０ｍｓ）を設定する。空きが３個以上となった場合はネットワークＢの通信負荷が比較的高くなったとしてＳＴｍｉｎに１０（＝１０ｍｓ）を設定する。つまり、ＳＴｍｉｎを受信性能が低下するように書換えてＦＣを送信するのである。

診断ツール１０は、ＧＷ３からＦＣを受信した場合は、ＦＣのＳＴｍｉｎが示す送信間隔でＣＦを送信する。これにより、ＥＣＵ５は、ネットワークＢの通信負荷が高くなった場合であっても診断ツール１０からのＣＦを確実に受信することができる。

（その他の実施形態）
本発明は、上記実施形態に限定されることなく、次のように変形または拡張したり、各変形例を上記実施形態と組合せたり、各変形例を組合せるようにしてもよい。
第１実施形態において、送信キュー１２に送信データが有ると判断する条件として、送信データが所定個数の場合としてもよい。
送信キュー１２にデータが無い場合はＳＴｍｉｎに１０を加算するようにしたが、空き個数に応じて加算する値を変更するようにしてもよい。

診断ツール１０のＣＦの送信間隔が大きくなるように変更されたにも拘わらず、ネットワークＢの通信負荷が高いためへ送信キュー１２にデータが滞留する状態が解消されない場合は、ＳＴｍｉｎにさらに１０加算して２０としてもよいし、１０ずつ順に加算するようにしてもよい。つまり、未送信データの有無に基づいてＳＴｍｉｎを動的に変化させるようにしてもよい。
第２実施形態において、ＳＴｍｉｎの変更値は一例であり、設定可能な数値であれば任意に変更可能である。
空き個数に応じてＳＴｍｉｎを３段階に設定したが、４段階以上に設定してもよい。

ＳＴｍｉｎの変更値は一例であり、設定可能な数値であれば任意な変更値としてもよい。
ＧＷ３の機能をＥＣＵ５が有するように構成してもよい。
ネットワークシステムの構成は一例であり、診断ツールとＥＣＵとがＣＡＮ通信プロトコルで通信可能であればどのような構成を採用してもよい。
外部装置として書換ツールをネットワークに接続するようにしてもよい。

図面中、３はゲートウェイ（車載中継装置、通信負荷判断手段）、５はＥＣＵ（車載制御装置）、１０は診断ツール（外部装置）である。

Claims (5)

1. ネットワークのノードを構成する車載制御装置（５）と、
   前記ネットワーク同士を接続するノードとして設けられ、一方のネットワークから受信した信号を通信プロトコルを整合させた状態で他方のネットワークへ送信する車載中継装置（３）と、
   前記ネットワークに接続されることによりノードとして設けられ、前記車載中継装置と通信する外部装置（１０）と、を備え、
   前記車載制御装置は、ＣＡＮ（controller area network）通信プロトコルのＩＳＯ（International Organization for Standardization）１５７６５で規定されているファーストフレームを受信したときは、自分に設定されている受信性能を示すフローコントロールを前記外部装置へ送信してから、当該外部装置からコンセキュティブフレームを受信し、
   前記外部装置は、前記ネットワークに接続された状態でファーストフレームを送信してから、前記フローコントロールを受信した場合は、当該フローコントロールが示す受信性能に応じた送信間隔で前記コンセキュティブフレームを順に送信する車載ネットワークシステムにおいて、
   前記車載中継装置は、前記車載制御装置側のネットワークの通信負荷を判断する通信負荷判断手段（３）を備え、前記車載制御装置から前記フローコントロールを受信した場合に前記通信負荷判断手段がネットワークの通信負荷は高いと判断したときは、前記フローコントロールが示す受信性能を低下させるように書換えて前記外部装置へ送信することを特徴とする車載ネットワークシステム。
2. 前記車載中継装置は、前記外部装置からの送信データを一時的に記憶するファーストインファーストアウト方式の送信キューを備え、
   前記通信負荷判断手段は、前記送信キューの送信データの滞留状態に基づいて前記ネットワークの通信負荷を判断することを特徴とする請求項１記載の車載ネットワークシステム。
3. 前記通信負荷判断手段は、前記送信キューに送信データが有る場合は、前記ネットワークの通信負荷は高いと判断することを特徴とする請求項２記載の車載ネットワークシステム。
4. 前記通信負荷判断手段は、前記送信キューの空き容量に基づいて、前記ネットワークの通信負荷を段階的に判断することを特徴とする請求項２記載の車載ネットワークシステム。
5. 請求項１から４のいずれか一項に記載の車載ネットワークシステムで用いられることを特徴とする車載中継装置。

Images