JP2013030988A - ゲートウェイ装置 - Google Patents

Abstract

【課題】ネットワークに接続される機器でタイムアウトの期間を個別に延長することなく、タイムアウトによる応答メッセージの取りこぼしを防止する。
【解決手段】診断ツール２からＥＣＵへの要求メッセージを受信すると、当該要求メッセージをＥＣＵへ中継するとともに、規定時間（タイムアウト時間）を延長して待機するように指示する待機要求コードを要求メッセージの送信元装置である診断ツール２へ送信する。
【選択図】図２

Description

本発明は、複数のネットワーク間のデータ中継を行うゲートウェイ装置に関するものである。

従来、車両においては、車両に搭載された各種装置間をネットワークで接続し、このネットワークを介して予め定められた通信規格に従ったデータの授受が行われるようになっている（例えば、特許文献１参照）。

特開２００５−４７４８８号公報

上記したようなネットワークに接続された装置間のデータの授受においては、データの送信要求を行ってから規格時間が経過しても応答が得られない場合、タイムアウトして処理を終了するように通信プロトコルで規定されている。

例えば、ＣＡＮ通信プロトコルにおけるダイアグ通信では、診断ツールからゲートウェイ装置を介して診断対象の制御装置に対して要求メッセージを送信してから、この診断対象の制御装置から規定時間（１００ミリ秒）以内に要求メッセージに応答する応答メッセージが受信されないと、診断ツールは診断対象の制御装置が要求メッセージを受信できなかったものと判断するようになっている。

しかし、近年、通信プロトコルの多様化に伴ってプロトコル変換を行うゲートウェイの数が増加し、ネットワーク構成が複雑化してきており、例えば、複数のゲートウェイを介して要求メッセージおよび応答メッセージが中継されるようになってきている。このようにネットワーク構成が複雑になると、通信プロトコルに規定されているタイムアウトの期間内に応答メッセージを受信することが困難になってしまう。

そこで、従来、診断ツールでは、タイムアウトの期間を超過しないように、各車両のネットワーク構成を考慮した上で、診断装置側で、診断対象の制御装置毎、車両毎に必要に応じてタイムアウトの期間を個別に延長するようにしている。しかし、このような構成では、ネットワークに接続される機器のバリエーションが多くなってしまうといった問題が生じる。また、診断対象の制御装置についても、高い処理能力が要求されるといった問題もある。

本発明は上記問題に鑑みたもので、ネットワークに接続される機器でタイムアウトの期間を個別に延長することなく、タイムアウトによる応答メッセージの取りこぼしを防止することを目的とする。

上記目的を達成するため、請求項１に記載の発明は、複数のネットワーク間のデータ中継を行うゲートウェイ装置であって、前記ネットワークの少なくとも１つは、当該ネットワークに接続された送信元装置から異なるネットワークに接続された送信先装置に対して要求メッセージが送信された場合、当該要求メッセージを送信してから規定時間以内に前記要求メッセージに応答する応答メッセージが受信されないと送信元装置がタイムアウトするように規定されており、前記送信元装置から前記送信先装置への要求メッセージを受信すると、当該要求メッセージを前記送信先装置へ中継するとともに、前記規定時間を延長して待機するように指示する待機要求コードを前記要求メッセージの送信元装置へ送信する待機要求送信手段を備えたことを特徴としている。

このような構成によれば、送信元装置から前記送信先装置への要求メッセージを受信すると、当該要求メッセージを前記送信先装置へ中継するとともに、前記規定時間を延長して待機するように指示する待機要求コードが前記要求メッセージの送信元装置へ送信されるので、ネットワークに接続される機器でタイムアウトの期間を個別に延長することなく、タイムアウトによる応答メッセージの取りこぼしを防止することができる。

また、請求項２に記載の発明は、データ中継に異常があったか否かを判定する異常判定手段と、前記異常判定手段により前記データ中継に異常があったと判定された場合、前記データ中継に異常があったことを前記送信元装置へ通知する通知手段と、を備えたことを特徴としている。

このような構成によれば、データ中継に異常があったと判定された場合、前記データ中継に異常があったことが前記送信元装置へ通知されるので、送信元装置はデータ中継に異常があったことを認識することができる。

また、請求項３に記載の発明は、前記要求メッセージ、前記応答メッセージおよび前記待機要求コードの少なくとも１つの中継履歴を学習し、当該中継履歴の学習結果を記憶媒体に記憶させる中継履歴学習手段と、前記記憶媒体に記憶された中継履歴の学習結果に基づいて前記待機要求コードを送信する必要があるか否かを判定する待機要求コード送信判定手段と、を備え、前記待機要求送信手段は、前記待機要求コード送信判定手段により前記待機要求コードを送信する必要があると判定された場合に、前記待機要求コードを前記要求メッセージの送信元装置へ送信することを特徴としている。

このような構成によれば、要求メッセージ、前記応答メッセージおよび前記待機要求コードの少なくとも１つの中継履歴を学習し、当該中継履歴の学習結果を記憶媒体に記憶させ、記憶媒体に記憶された中継履歴の学習結果に基づいて前記待機要求コードを送信する必要があるか否かを判定し、待機要求コードを送信する必要があると判定された場合に、前記待機要求コードを前記要求メッセージの送信元装置へ送信するので、例えば、待機要求コードを送信する必要もないのに待機要求コードを送信元装置へ送信して応答性を低下させてしまうといったことを防止することができる。

また、請求項４に記載の発明のように、要求メッセージを中継してから前記応答メッセージを受信するまでの時間を計測し、要求メッセージを中継してから前記応答メッセージを受信するまでの時間を前記応答メッセージの中継履歴として学習することもできる。

本発明の一実施形態に係るゲートウェイ装置を用いて構成された車載用ＬＡＮシステムの例を示す図である。 診断ツール２からＥＣＵ４ａへ要求メッセージが送信された場合の診断ツール、ゲートウェイ、ＥＣＵ間の信号の流れを示す図である。 待機要求コードのフレームフォーマットについて説明するための図である。 ゲートウェイのフローチャートである。 中継履歴の学習結果の例を示す図である。

本発明の一実施形態に係るゲートウェイ装置を用いて構成された車載用ＬＡＮシステムの例を図１に示す。車載用ＬＡＮシステムは、ゲートウェイ装置１ａ、１ｂ、ＥＣＵ３ａ、３ｂ、４ａ、４ｂ、５ａ、５ｃおよびバスＡ、Ｂ、Ｃにより構成されている。

バスＡには、ＥＣＵ３ａ、３ｂおよび診断ツール２が接続され、バスＢには、ＥＣＵ４ａ、４ｂが接続され、バスＣには、ＥＣＵ５ａ、５ｂが接続されている。

また、バスＡに接続されたネットワーク、バスＢに接続されたネットワーク、バスＣに接続されたネットワークとで、通信プロトコルが異なっている。本実施形態では、バスＡの通信プロトコルはＣＡＮ通信プロトコル、バスＢの通信プロトコルはＣＡＮ通信プロトコル、バスＣの通信プロトコルはＦｌｅｘＲａｙ通信プロトコルとなっている。

ゲートウェイ装置１ａ、１ｂは、それぞれ、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＬＡＮコントローラ（いずれも図示せず）を備えている。ＣＰＵは、ＲＯＭに記憶されたプログラムに従って各種処理を実施する。ゲートウェイ装置１ａとゲートウェイ装置１ｂは同一構成となっている。ＬＡＮコントローラは、各バスＡ〜Ｃの各通信プロトコルに規定されたデータフォーマットに従ってデータの送受信を行う。

ゲートウェイ装置１ａは、バスＡの通信プロトコルとバスＢの通信プロトコルのプロトコル変換を行ってデータの中継を行い、ゲートウェイ装置１ｂは、バスＢの通信プロトコルとバスＣの通信プロトコルのプロトコル変換を行ってデータの中継を行う。

また、バスＡには、各ＥＣＵから故障診断等のための各種情報を収集する診断ツール２が接続されている。

ＣＡＮ通信プロトコルでは、ネットワークに接続された送信元装置、例えば、診断ツール２から異なるネットワークに接続された送信先装置、例えば、ＥＣＵ４ａに対して要求メッセージが送信された場合、当該要求メッセージを送信してから規定時間（１００ミリ秒）以内に要求メッセージに応答する応答メッセージが受信されないと送信元装置がタイムアウトするように規定されている。したがって、送信元装置は、要求メッセージを送信してから規定時間以内に要求メッセージに応答する応答メッセージが受信されない場合、要求メッセージが送信先装置により受理されなかったものとして処理を行うようになっている。

本実施形態におけるゲートウェイ１ａは、例えば、診断ツール２からＥＣＵ４ａに対して要求メッセージを中継する際に、上記規定時間（１００ミリ秒）を延長して、５秒間待機するように指示する待機要求コードを診断ツール２へ送信する処理を行う。

図２に、診断ツール２からＥＣＵ４ａへ要求メッセージが送信された場合の診断ツール２、ゲートウェイ１ａ、ＥＣＵ４ａ間の信号の流れを示す。次に、図２を参照して、要求メッセージが送信された場合の診断ツール２、ゲートウェイ１ａ、ＥＣＵ４ａ間の信号の流れについて説明する。

まず、診断ツール２からゲートウェイ１ａへファーストフレーム（ＦＦ）が送信されると、ゲートウェイ１ａから診断ツール２へフローコントロール（ＦＣ）が送信される。診断ツール２は、このフローコントロール（ＦＣ）を受信すると、コンゼクティブフレーム（ＣＦ）＃１、＃２、＃３を順次送信する。そして、コンゼクティブフレーム（ＣＦ）＃３の送信が完了すると、要求メッセージの送信が終了する。

ゲートウェイ１ａは、診断ツール２からの要求メッセージの受信を完了すると、受信した要求メッセージをＥＣＵ４ａへ中継するとともに、規定時間（１００ミリ秒）を延長して、５秒間待機するように指示する待機要求コードを診断ツール２へ送信する。具体的には、診断ツール２からの要求メッセージの受信を完了すると、直ちにＣＡＮ通信プロトコルのダイアグ通信で規定されているＮＲＣ０ｘ７８コードを待機要求コードとして診断ツール２へ送信するとともに、ゲートウェイ１ａからＥＣＵ４ａへファーストフレーム（ＦＦ）が送信され、ＥＣＵ４ａからゲートウェイ１ａへフローコントロール（ＦＣ）が送信されると、ゲートウェイ１ａからＥＣＵ４ａへコンゼクティブフレーム（ＣＦ）＃１、＃２、＃３が順次送信される。このように、診断ツール２とゲートウェイ１ａとの間で各種フレームの送受信が行われ、要求メッセージの中継が完了する。

ＥＣＵ４ａは、要求メッセージの受信が完了すると、この要求メッセージに応答する応答メッセージを診断ツール２へ送信する。具体的には、ＥＣＵ４ａからゲートウェイ１ａへファーストフレーム（ＦＦ）が送信され、ゲートウェイ１ａからＥＣＵ４ａへフローコントロール（ＦＣ）が送信されると、ＥＣＵ４ａからゲートウェイ１ａへコンゼクティブフレーム（ＣＦ）＃１、＃２、＃３が順次送信される。このように、ＥＣＵ４ａとゲートウェイ１ａとの間で各種フレームの送受信が行われ、応答メッセージの送信が終了する。

ゲートウェイ１ａは、ＥＣＵ４ａからの応答メッセージの受信を完了すると、受信した応答メッセージを診断ツール２へ中継する。具体的には、ゲートウェイ１ａから診断ツール２へファーストフレーム（ＦＦ）が送信され、診断ツール２からゲートウェイ１ａへフローコントロール（ＦＣ）が送信されると、ゲートウェイ１ａから診断ツール２へコンゼクティブフレーム（ＣＦ）＃１、＃２、＃３が順次送信される。このように、診断ツール２とゲートウェイ１ａとの間で各種フレームの送受信が行われ、応答メッセージの中継が完了する。

なお、診断ツール２は、タイマを用いて要求メッセージの送信開始時から応答メッセージを受信するまでの時間を計測し、通常、１００ミリ秒が経過しても応答メッセージが受信されない場合は、タイムアウトする。ただし、待機要求コードを受信した場合は、タイマをリセットするとともに、規定時間（タイムアウト時間）を１００ミリ秒から５秒に変更する。したがって、多数のゲートウェイを介して接続されたＥＣＵにデータを中継し、診断ツール２が規定時間（タイムアウト時間）内に応答メッセージを受信できないような状況でも、ゲートウェイ１ａから診断ツール２へ待機要求コードが送信され、診断ツール２側で規定時間（タイムアウト時間）が延長された場合、診断ツール２はタイムアウトすることなく、応答メッセージを受信することが可能となる。

図３に、ＮＲＣ０ｘ７８コードのフレームフォーマットを示す。本実施形態においては、図に示すフレームフォーマットのＮＲＣ０ｘ７８コードを待機要求コードとして送信元装置へ送信する。

次に、診断ツール２とＥＣＵ５ａとの間のデータ中継を行う場合のゲートウェイ１ａの処理について説明する。図４に、この場合のゲートウェイ１ａのフローチャートを示す。ゲートウェイ１ａは、定期的に図４に示す処理を実施する。

まず、要求メッセージを受信したか否かを判定する（Ｓ１００）。要求メッセージが受信されない場合、Ｓ１００の判定はＮＯとなり、Ｓ１００の判定処理を繰り返し実施する。

ここで、診断ツール２からＥＣＵ５ａへ送信される要求メッセージを受信すると、Ｓ１００の判定はＹＥＳとなり、この要求メッセージをＥＣＵ５ａへと中継する（Ｓ１０２）。具体的には、バスＡのＣＡＮ通信プロトコルからバスＢのＬＩＮ通信プロトコルへとプロトコル変換してゲートウェイ１ｂを介してＥＣＵ５ａへと要求メッセージを中継する。

次に、時間計測を開始する（Ｓ１０４）。具体的には、タイマをリセットして時間計測を開始する。

次に、後述する中継履歴に基づいて待機要求コードを送信する必要があるか否かを判定する（Ｓ１０６）。ここでは、待機要求コードを送信する必要があるものとする。この場合、Ｓ１０６の判定はＹＥＳとなり、次に、待機要求コードを送信する（Ｓ１０８）。具体的には、ＣＡＮ通信プロトコルのダイアグ通信で規定されているＮＲＣ０ｘ７８コードを待機要求コードとして診断ツール２へ送信する。

次に、一定期間内に待機要求コードを受信したか否かを判定する（Ｓ１１０）。ここで、Ｓ１０２にて中継した要求メッセージがゲートウェイ１ｂによりＥＣＵ５ａへ中継され、このとき、ゲートウェイ１ｂから診断ツール２へ待機要求コードが送信され、この待機要求コードを受信すると、Ｓ１１０の判定はＹＥＳとなり、計測時間をメモリに記憶する（Ｓ１１２）。具体的には、待機要求コードを受信した時点のタイマの値をメモリに記憶させる。

次に、待機要求コードを診断ツール２へ中継し（Ｓ１１４）、Ｓ１１０の判定へ戻り、再度、待機要求コードを受信したか否かの判定ステップへ戻る。

また、一定期間が経過しても待機要求コードが受信されない場合、Ｓ１１０の判定はＮＯとなり、次に、ＥＣＵから応答メッセージを受信したか否かを判定する（Ｓ１１６）。

ここで、要求メッセージを受信したＥＣＵ５ａから応答メッセージが送信され、この応答メッセージを受信すると、Ｓ１１６の判定はＹＥＳとなり、次に、計測時間を記憶させる（Ｓ１１８）。具体的には、応答メッセージを受信した時点のタイマの値をメモリに記憶させる。

次に、応答メッセージを診断ツール２へ中継する（Ｓ１２０）。具体的には、バスＢのＬＩＮ通信プロトコルからバスＡのＣＡＮ通信プロトコルへとプロトコル変換してゲートウェイ１ｂを介して診断ツール２へと応答メッセージを中継する。

次に、中継履歴を学習し（Ｓ１２２）、本処理を終了する。また、ＥＣＵ５ａから応答メッセージが受信されない場合、Ｓ１１６の判定はＮＯとなり、次に、診断ツール２へエラーを通知する（Ｓ１２４）。具体的には、ＣＡＮ通信プロトコルのダイアグ通信で規定されているエラーコードを診断ツール２へ送信し、中継履歴を学習し（Ｓ１２２）、本処理を終了する。

図５に、中継履歴の学習結果の例を示す。図に示すように、送信先ＥＣＵ毎に、ゲートウェイの数、応答時間および正常または異常を表す情報（正常／異常）が中継履歴としてメモリに記憶されている。

ゲートウェイの数は、待機要求コードを受信した数として特定することができる。また、応答時間は、要求メッセージを中継してから応答メッセージを受信するまでの時間である。

また、本実施形態では、応答時間が規定時間（１００ミリ秒）と比較して短い場合、Ｓ１０６の判定において、待機要求コードを送信する必要がないと判定し、応答時間が規定時間（１００ミリ秒）よりも長い場合は、待機要求コードを送信する必要があると判定する。

また、要求メッセージの中継先が異常と判定されたＥＣＵの場合、Ｓ１０６の判定において、待機要求コードを送信する必要がないと判定し、要求メッセージの中継先が正常と判定されたＥＣＵの場合、待機要求コードを送信する必要があると判定する。

上記した構成によれば、送信元装置から前記送信先装置への要求メッセージを受信すると、当該要求メッセージを前記送信先装置へ中継するとともに、前記規定時間を延長して待機するように指示する待機要求コードが前記要求メッセージの送信元装置へ送信されるので、ネットワークに接続される機器でタイムアウトの期間を個別に延長することなく、タイムアウトによる応答メッセージの取りこぼしを防止することができる。

また、データ中継に異常があったと判定された場合、前記データ中継に異常があったことが前記送信元装置へ通知されるので、送信元装置はデータ中継に異常があったことを認識することができる。

また、要求メッセージ、前記応答メッセージおよび前記待機要求コードの少なくとも１つの中継履歴を学習し、当該中継履歴の学習結果を記憶媒体に記憶させ、記憶媒体に記憶された中継履歴の学習結果に基づいて前記待機要求コードを送信する必要があるか否かを判定し、待機要求コードを送信する必要があると判定された場合に、前記待機要求コードを前記要求メッセージの送信元装置へ送信するので、例えば、待機要求コードを送信する必要もないのに待機要求コードを送信元装置へ送信して応答性を低下させてしまうといったことを防止することができる。また、診断ツールは、ゲートウェイから中継履歴を取得して、ゲートウェイから各ＥＣＵまでの応答時間を認識したり、あるいは、ゲートウェイと各ＥＣＵとの間のゲートウェイの数等を認識したりすることが可能である。

なお、本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づいて種々なる形態で実施することができる。

例えば、上記実施形態では、要求メッセージ、応答メッセージおよび待機要求コードの中継履歴を学習したが、必ずしも要求メッセージ、応答メッセージおよび待機要求コードの中継履歴を学習する必要はなく、要求メッセージ、応答メッセージおよび待機要求コードの少なくとも１つの中継履歴を学習するようにしてもよい。

また、上記実施形態では、診断ツール２を送信元装置とし、ＥＣＵを送信先装置をとしてデータを中継する例を示したが、診断ツール２、ＥＣＵ以外の装置を送信元装置、送信先装置とすることもできる。

なお、上記実施形態における構成と特許請求の範囲の構成との対応関係について説明すると、Ｓ１０８が待機要求送信手段に相当し、１１６が異常判定手段に相当し、Ｓ１２４が通知手段に相当し、Ｓ１２２が中継履歴学習手段に相当し、Ｓ１０６が待機要求コード送信判定手段に相当し、Ｓ１０４、Ｓ１１８が計測手段に相当する。

１ａ、１ｂ ゲートウェイ
２ 診断ツール
３ａ、３ｂ ＥＣＵ
４ａ、４ｂ ＥＣＵ
５ａ、５ｂ ＥＣＵ

Claims (4)

1. 複数のネットワーク間のデータ中継を行うゲートウェイ装置であって、
   前記ネットワークの少なくとも１つは、当該ネットワークに接続された送信元装置から異なるネットワークに接続された送信先装置に対して要求メッセージが送信された場合、当該要求メッセージを送信してから規定時間以内に前記要求メッセージに応答する応答メッセージが受信されないと前記送信元装置がタイムアウトするように規定されており、
   前記送信元装置から前記送信先装置への要求メッセージを受信すると、当該要求メッセージを前記送信先装置へ中継するとともに、前記規定時間を延長して待機するように指示する待機要求コードを前記要求メッセージの送信元装置へ送信する待機要求送信手段を備えたことを特徴とするゲートウェイ装置。
2. 前記データ中継に異常があったか否かを判定する異常判定手段と、
   前記異常判定手段により前記データ中継に異常があったと判定された場合、前記データ中継に異常があったことを前記送信元装置へ通知する通知手段と、を備えたことを特徴とする請求項１に記載のゲートウェイ装置。
3. 前記要求メッセージ、前記応答メッセージおよび前記待機要求コードの少なくとも１つの中継履歴を学習し、当該中継履歴の学習結果を記憶媒体に記憶させる中継履歴学習手段と、
   前記記憶媒体に記憶された中継履歴の学習結果に基づいて前記待機要求コードを送信する必要があるか否かを判定する待機要求コード送信判定手段と、を備え、
   前記待機要求送信手段は、前記待機要求コード送信判定手段により前記待機要求コードを送信する必要があると判定された場合に、前記待機要求コードを前記要求メッセージの送信元装置へ送信することを特徴とする請求項１または２に記載のゲートウェイ装置。
4. 前記要求メッセージを中継してから前記応答メッセージを受信するまでの時間を計測する計測手段を備え、
   前記中継履歴学習手段は、前記要求メッセージを中継してから前記応答メッセージを受信するまでの時間を前記応答メッセージの中継履歴として学習することを特徴とする請求項３に記載のゲートウェイ装置。

Images