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

Abstract

【課題】診断ツールからのフレームを各制御装置へ一斉送信した後、各制御装置からの応答フレームを受信して診断ツールに中継するとともに、各制御装置がタイムアウトしないようにする装置を提供する。
【解決手段】ゲートウェイ装置１は、診断ツール２から複数のＥＣＵ３０に対する一斉送信を表す要求フレームを受信すると、要求フレームを複数のＥＣＵに一斉送信し、要求フレームの受信に応答して複数のＥＣＵから送信される応答フレームを受信すると、受信した応答フレームをバッファに保持させ、バッファに保持させた応答フレームを診断ツールへ中継する。更に応答フレームを送信したＥＣＵに、タイムアウトしないように待機を指示する待機指示フレームを送信する。
【選択図】図１１

Description

本発明は、ゲートウェイ装置に関するものである。

車両には、車両を制御する多数のＥＣＵが搭載されており、各ＥＣＵ間で様々なデータの送受信が行われるようになっている。また、車両には、ゲートウェイ装置を備え、このゲートウェイ装置に診断ツール等の外部機器を接続して各ＥＣＵと通信できるようになっているものもある。

上記したような診断ツールとＥＣＵの間の通信は、通常、相手側の物理アドレスを個別に指定する１対１の通信により行われる。また、診断ツールからゲートウェイ装置へ、全ＥＣＵへの一斉送信を表す機能アドレスをアドレス領域に指定したフレームが送信されると、ゲートウェイ装置が、このフレームを全ＥＣＵに一斉送信するようにしたものもある（例えば、特許文献１参照）。

特開２０１３−５１５６号公報

上記したような診断ツールとＥＣＵの間のフレームの送受信は、ＩＳＯ規格（例えば、ＩＳＯ１５７６５−２、ＩＳＯ１５７６５−４）に規定されたＣＡＮダイアグ通信の通信仕様に従って行われる。なお、ＣＡＮダイアグ通信では、１つのフレームで転送できるデータは一定バイト（例えば、７バイト）までとなっており、送信したいデータが一定バイトを越える場合には、複数回にわたりフレームを送信する必要がある。

上記ＩＳＯ規格において、送信したいデータが一定バイトを越えない場合、診断ツールＥＣＵとの間のフレームの送受信は、シングルフレーム（ＳＦ）を用いて行われる。

また、送信したいデータが一定バイトを越える場合、診断ツールＥＣＵとの間のフレームの送受信は、図１２に示すように、ファーストフレーム（ＦＦ）、コンゼクティブフレーム（ＣＦ）およびフローコントロールフレーム（ＦＣ）を用いて行われる。

ファーストフレーム（ＦＦ）は、マルチフレームの最初のフレームであり、コンゼクティブフレーム（ＣＦ）は、マルチフレームの２つ目以降のフレームである。また、フローコントロールフレーム（ＦＣ）は、相手側の機器から送信されるフレームの数や時間間隔等のフロー制御を行うためのフレームである。

例えば、ゲートウェイ装置は、診断ツールから、全ＥＣＵへの一斉送信を表す機能アドレスをアドレス領域に指定したシングルフレーム（ＳＦ）の機能アドレス要求フレームを受信すると、この機能アドレス要求フレームを各ＥＣＵ３０へ一斉送信する。

ＥＣＵは、このフレームを受信すると、このフレームに応答する応答データが一定バイトを超えるか否かを判定し、応答データが一定バイトを超える場合、応答フレームのファーストフレーム（ＦＦ）を診断ツール（受信者）へ送信する。

診断ツールは、ＥＣＵからの応答フレームのファーストフレーム（ＦＦ）を受信すると、ＥＣＵ（送信者）へフローコントロールフレーム（ＦＣ）を送信し、相手側の機器から送信されるフレームの数や時間間隔等のフロー制御を行う。

このように、診断ツール（受信者）からＥＣＵ（送信者）へフローコントロールフレーム（ＦＣ）を送信すると、それ以降、フローコントロールフレーム（ＦＣ）の指示にしたがって、ＥＣＵ（送信者）から応答フレームの２つ目以降のコンゼクティブフレーム（ＣＦ）が送信されるようになる。

しかし、ＥＣＵに対して機能アドレス要求フレームを送信した後、相手側の機器（ＥＣＵ）から送信される応答フレームのファーストフレーム（ＦＦ）についてはフレームの数や時間間隔等のフロー制御を行うことができない。

特に、ゲートウェイ装置が複数のＥＣＵに対して機能アドレス要求フレームを一斉送信するような場合、ゲートウェイ装置と診断ツールの間のデータ転送可能量は、ゲートウェイ装置と各ＥＣＵとの間のデータ転送可能量の合計量と比較して非常に少ないため、機能アドレス要求フレームを受信した複数のＥＣＵから無条件に集中して応答フレームが送信されると、ゲートウェイ装置は、多数のＥＣＵから送信されたフレームを取りこぼしてしまい、診断ツールに正確に中継することができなくなるといった問題が発生する。

また、上記ＩＳＯ規格において、送信者と受信者との間のフレームの送受信には各種時間規定がある。例えば、ＥＣＵが診断ツールへフレームを送信した後、規定時間を超えても診断ツールからのフレームをＥＣＵが受信できない場合、ＥＣＵはタイムアウトとなってエラーが発生してしまう。すなわち、従来のゲートウェイ装置は、診断ツールとＥＣＵの間のフレームの中継は行うが、診断ツールに代わってフロー制御のための各種フレームを送信するといったことは行わないので、規定時間を超えても診断ツールからのフレームを受信できないＥＣＵはタイムアウトとなってしてしまう。

上記したように、多数のＥＣＵから無条件に集中して応答フレームが送信されるような場合、これらのフレームを診断ツールに中継し、このフレームに応答して診断ツールより送信されるフレームを中継して、規定時間内に各ＥＣＵに受信させるのは困難となってしまう。

本発明は上記問題に鑑みたもので、診断ツールからのフレームを各制御装置へ一斉送信した後、各制御装置からの応答フレームを受信して診断ツールに中継できるようにするとともに、各制御装置がタイムアウトしないようにすることを目的とする。

上記目的を達成するため、請求項１に記載の発明は、診断ツールから複数の制御装置に対する一斉送信を表す要求フレームを受信すると、該要求フレームを複数の制御装置に一斉送信するフレーム一斉送信手段（Ｓ１０２）と、要求フレームの受信に応答して複数の制御装置から送信される応答フレームを受信すると、該受信した応答フレームを保持手段（１０）に保持させるフレーム保持手段（Ｓ２０２）と、保持手段に保持された応答フレームを診断ツールへ中継する中継手段（Ｓ５０４）と、応答フレームを送信した制御装置に、タイムアウトしないように待機を指示する待機指示フレームを送信する待機指示フレーム送信手段（Ｓ６０４）と、を備えたことを特徴としている。

このような構成によれば、診断ツールから複数の制御装置に対する一斉送信を表す要求フレームを受信すると、該要求フレームを複数の制御装置に一斉送信し、要求フレームの受信に応答して複数の制御装置から送信される応答フレームを受信すると、該受信した応答フレームを保持手段に保持させ、保持手段に保持された応答フレームを診断ツールへ中継するので、各制御装置からの応答フレームを受信して診断ツールに中継することができる。また、応答フレームを送信した制御装置に、タイムアウトしないように待機を指示する待機指示フレームを送信するので、各制御装置がタイムアウトしないようにすることもできる。

なお、この欄および特許請求の範囲で記載した各手段の括弧内の符号は、後述する実施形態に記載の具体的手段との対応関係を示すものである。

本発明の一実施形態に係るゲートウェイ装置の全体構成を示す図である。 診断ツールＥＣＵとの間のフレームについて説明するための図である。 フローコントロールフレームのフローステータスについて説明するための図である。 機能要求フレームの一斉送信と応答フレームの送信について説明するための図である。 ゲートウェイ装置のフローチャートである。 ゲートウェイ装置のフローチャートである。 ゲートウェイ装置のフローチャートである。 ゲートウェイ装置のフローチャートである。 ゲートウェイ装置のフローチャートである。 ゲートウェイ装置のフローチャートである。 フローコントロールフレームの代行送信のフレームの流れを示した図である。 診断ツールＥＣＵとの間のフレームの送受信について説明するための図である。

本発明の一実施形態に係るゲートウェイ装置の全体構成を図１に示す。本ゲートウェイ装置１は、第１バス側に接続された診断ツール２等の機器と、第２バス側に接続された複数の制御装置（以下、ＥＣＵと称す）３０とのフレームの中継を行うセントラルゲートウェイ装置（ＣＧＷ）として構成されている。第１バス側には、１系統のバスが用意されており、第２バス側には、１〜５チャンネル（ｃｈ）の５系統のバスが用意されている。第２バス側の５系統の各バスには、それぞれ１５個のＥＣＵ３０を接続することが可能となっている。すなわち、本ゲートウェイ装置１は、第１バス側に接続された診断ツール２等の外部機器と、５系統の各バスに接続された最大７５個のＥＣＵ３０とのフレームの中継を行うことが可能となっている。

本ゲートウェイ装置１は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ等を備えたコンピュータとして構成されており、ＣＰＵはＲＯＭに記憶されたプログラムに従って各種処理を実施する。また、本ゲートウェイ装置１は、第２バス側の各ＥＣＵ３０からの応答フレームを一時的に保持するバッファ１０を備えている。なお、本実施形態において、バッファ１０は各ＥＣＵ３０に割り当てられたＣＡＮＩＤ毎に設けられている。本ゲートウェイ装置１は、５系統の各バスに接続可能な合計７５個のＥＣＵ３０に対し、それぞれ１フレーム分の容量のバッファ１０を有している。すなわち、本ゲートウェイ装置１は、合計７５フレーム分の容量のバッファ１０を有している。

本実施形態において、診断ツール２と各ＥＣＵ３０との間のフレームの送受信は、ＩＳＯ規格（例えば、ＩＳＯ１５７６５−２、ＩＳＯ１５７６５−４）に規定されたＣＡＮダイアグ通信の通信仕様に従って行われるようになっている。なお、ＣＡＮダイアグ通信では、１つのフレームで転送できるデータは一定バイト（例えば、７バイト）までとなっており、送信したいデータが一定バイトを越えない場合には、シングルフレームで送信を行い、送信したいデータが一定バイトを越える場合には、複数のフレーム（マルチフレーム）で送信を行うようになっている。

上記ＩＳＯ規格に規定されているフローコントロールにおいて、診断ツール２とＥＣＵ３０との間のフレームのやり取りは、図２に示すように、シングルフレーム（ＳＦ）、ファーストフレーム（ＦＦ）、コンゼクティブフレーム（ＣＦ）およびフローコントロールフレーム（ＦＣ）を用いて行われる。

シングルフレーム（ＳＦ）は、送信するデータが１つのフレームに収まる場合に使用されるフレームである。また、ファーストフレーム（ＦＦ）は、マルチフレームの最初のフレームであり、コンゼクティブフレーム（ＣＦ）は、マルチフレームの２つ目以降のフレームである。なお、フローコントロールフレーム（ＦＣ）は、２つ目以降のコンゼクティブフレーム（ＣＦ）がある場合に使用される。

ここで、フローコントロールフレーム（ＦＣ）について説明する。図２に示すように、フローコントロールフレーム（ＦＣ）には、フレームの種別を示すＮ＿ＰＣＩタイプ、フローステータス（ＦＳ）、ブロックサイズ（ＢＳ）およびセパレーションタイム（Ｓｔｍｉｎ）が含まれる。

なお、ブロックサイズ（ＢＳ）は、連続フレームの受信可能最大数を送信者に伝えるために使用される。また、セパレーションタイム（Ｓｔｍｉｎ）は、フレームの送信間隔を送信者に伝えるために使用される。

また、図３に示すように、フローステータス（ＦＳ）には、Ｃｏｎｔｉｎｕｅ Ｔｏ Ｓｅｎｄ（ＣＴＳ）、Ｗａｉｔ（ＷＴ）およびＯｖｅｒｆｌｏｗ（ＯＶＦＬＷ）が設定される。

Ｃｏｎｔｉｎｕｅ Ｔｏ Ｓｅｎｄ（ＣＴＳ）は、フレームを受信する準備ができていることを示すものである。また、Ｗａｉｔ（ＷＴ）は、送信者に待機を継続させるものである。また、Ｏｖｅｒｆｌｏｗ（ＯＶＦＬＷ）は、送信者にエラーが発生したことを示すものである。

このように、診断ツール２からＥＣＵ３０へフローコントロールフレーム（ＦＣ）を送信すると、それ以降、フローコントロールフレーム（ＦＣ）の指示にしたがって、ＥＣＵ３０から応答フレームの２つ目以降のコンゼクティブフレーム（ＣＦ）が送信されるようになる。

本ゲートウェイ装置１は、診断ツール２から、特定のＥＣＵ３０の物理アドレスをアドレス領域に設定した要求フレームを受信すると、この要求フレームを特定のＥＣＵ３０へ個別に中継する。

また、図４に示すように、本ゲートウェイ装置１は、診断ツール２から、全ＥＣＵ３０への一斉送信を表す機能アドレスをアドレス領域に指定した機能アドレス要求フレームを受信すると、この機能アドレス要求フレームを各ＥＣＵ３０へ一斉送信する。このように、機能アドレス要求フレームを各ＥＣＵ３０へ一斉送信することで、要求フレームを特定のＥＣＵ３０へ個別に中継する場合と比較して、フレームの送信にかかる時間を大幅に短縮することが可能となる。

また、診断ツール２からの機能アドレス要求フレームを受信した各ＥＣＵ３０は、この機能アドレス要求フレームの受信に応答する応答フレームを同時に診断ツール２へ向けて送信するようになっている。

図５に、この処理のフローチャートを示す。本ゲートウェイ装置１は、定期的に図に示す処理を実施する。なお、機能アドレス要求フレームはシングルフレーム（ＳＦ）となっている。また、各図面のフローチャートにおける各制御ステップは、ゲートウェイ装置１が有する各種の機能実現手段を構成している。

まず、診断ツール２から、全ＥＣＵ３０へ一斉送信を表す機能アドレス要求フレームを受信したか否かを判定する（Ｓ１００）。ここで、機能アドレス要求フレームが受信されていない場合、Ｓ１００の判定はＮＯとなり、本処理を終了する。

また、診断ツール２からの機能アドレス要求フレームが受信されると、受信された機能アドレス要求フレームを全ＥＣＵ３０へ一斉送信し（Ｓ１０２）、本処理を終了する。

なお、機能アドレス要求フレームを受信した各ＥＣＵ３０は、それぞれ受信した機能アドレス要求フレームに応答する応答フレームを診断ツール２へ送信するようになっている。したがって、ゲートウェイ装置１には、機能アドレス要求フレームを受信した各ＥＣＵ３０から集中的に応答フレームが入力される。

なお、同一バスに接続された複数のＥＣＵ３０からのフレーム送信が同時に起こった場合には、周知のＣＡＮ調停により、ＣＡＮＩＤの値の小さいものが優先されるようになっている。すなわち、同一バスに接続された複数のＥＣＵ３０からは、ＣＡＮＩＤの値の小さいものから順番に集中的に応答フレームが入力される。

本ゲートウェイ装置１は、機能アドレス要求フレームを受信した各ＥＣＵ３０からの応答フレームを受信すると、受信した応答フレームをバッファ１０に書き込む処理を行う。

図６に、このフローチャートを示す。本ゲートウェイ装置１は、図５に示した処理と並行に図６に示す処理を定期的に実施する。

まず、ＥＣＵ３０から応答フレームを受信したか否かを判定する（Ｓ２００）。本実施形態では、応答フレームのファーストフレーム（ＦＦ）を受信したか否かを判定する。ここで、応答フレームのファーストフレーム（ＦＦ）が受信されない場合、Ｓ２００の判定はＮＯとなり、本処理を終了する。

また、機能アドレス要求フレームを受信した各ＥＣＵ３０から集中的に応答フレームのファーストフレーム（ＦＦ）が送信され、これらの応答フレームを受信すると、Ｓ２００の判定はＹＥＳとなり、受信した応答フレームを、順次、バッファ１０に書き込み（Ｓ２０２）、本処理を終了する。

このような処理を繰り返し実施して、機能アドレス要求フレームを受信した各ＥＣＵ３０から集中して入力される応答フレームのファーストフレーム（ＦＦ）がバッファ１０に保持される。

なお、本実施形態において、７５個のＥＣＵ３０より入力される応答フレームのファーストフレーム（ＦＦ）を保持するだけの容量（７５フレーム分）のバッファ１０が用意されており、最大７５個のＥＣＵ３０より集中して入力される応答フレームのファーストフレーム（ＦＦ）を保持することが可能となっている。

本ゲートウェイ装置１は、機能アドレス要求フレームを受信した各ＥＣＵ３０がタイムアウトしないよう、応答フレームを保持しているバッファ１０を監視する処理を行う。

図７に、このフローチャートを示す。本ゲートウェイ装置１は、図５、６に示した処理と並行に図７に示す処理を定期的に実施する。

まず、ＥＣＵ３０から応答フレームを受信したか否かを判定する（Ｓ３００）。本実施形態では、応答フレームのファーストフレーム（ＦＦ）を受信したか否かを判定する。ここで、ＥＣＵ３０から応答フレームのファーストフレーム（ＦＦ）が受信されない場合、あるいは、ＥＣＵ３０からシングルフレーム（ＳＦ）の応答フレームを受信した場合、Ｓ３００の判定はＮＯとなり、本処理を終了する。

また、機能アドレス要求フレームを受信した各ＥＣＵ３０から応答フレームのファーストフレーム（ＦＦ）を受信すると、カウンタのカウント値をリセットしてカウンタによる計時を開始する（Ｓ３０２）。なお、本ゲートウェイ装置１は、第２バス側に接続可能な各ＥＣＵ３０に対応するカウンタを有しており、機能アドレス要求フレームを受信した各ＥＣＵ３０からの応答フレームを受信すると、受信した各ＥＣＵ３０に対応するカウンタを用いて個別に計時を開始する。

次に、診断ツール２からのフローコントロールフレーム（ＦＣ）をＥＣＵ３０へ中継したか否かを判定する（Ｓ３０４）。本実施形態において、Ｓ２０２にて、各ＥＣＵ３０からの応答フレームのファーストフレーム（ＦＦ）をバッファ１０に保持させた後、バッファ１０から応答フレームのファーストフレーム（ＦＦ）を読み出して診断ツール２へ送信するようになっている。また、診断ツール２は、応答フレームのファーストフレーム（ＦＦ）を受信すると、応答フレームを送信したＥＣＵ３０に対してフローコントロールフレーム（ＦＣ）を送信するようになっている。ここでは、診断ツール２から応答フレームを送信したＥＣＵ３０に対するフローコントロールフレーム（ＦＣ）を中継したか否かを判定する。

ここで、診断ツール２から、応答フレームのファーストフレーム（ＦＦ）を送信したＥＣＵ３０に対するフローコントロールフレーム（ＦＣ）を中継していない場合、Ｓ３０４の判定はＮＯとなり、Ｓ３０４へ戻る。したがって、カウンタによる計時が継続される。

また、診断ツール２から応答フレームのファーストフレーム（ＦＦ）を送信したＥＣＵ３０に対するフローコントロールフレーム（ＦＣ）を中継すると、Ｓ３０４の判定はＹＥＳとなり、次に、カウンタによる計時を停止する（Ｓ３０６）。具体的には、カウンタのカウントアップを停止し、本処理を終了する。

また、上記したように、本ゲートウェイ装置１は、診断ツール２から特定のＥＣＵ３０へフローコントロールフレーム（ＦＣ）を受信すると、このフローコントロールフレーム（ＦＣ）を特定のＥＣＵ３０へ中継する処理を実施する。

図８に、このフローチャートを示す。本ゲートウェイ装置１は、図５〜７に示した処理と並行に図８に示す処理を定期的に実施する。

まず、診断ツール２から特定のＥＣＵ３０へのフローコントロール（ＦＣ）を受信したか否かを判定する（Ｓ４００）。ここで、診断ツール２からのフローコントロール（ＦＣ）を受信していない場合、Ｓ４００の判定はＮＯとなり、本処理を終了する。

また、診断ツール２から特定のＥＣＵ３０へのフローコントロール（ＦＣ）を受信すると、Ｓ４００の判定はＹＥＳとなり、このフローコントロール（ＦＣ）を特定のＥＣＵ３０へ中継し、本処理を終了する。

また、本ゲートウェイ装置１は、バッファ１０に書き込んた応答フレームを読み出して診断ツール２に送信する処理を実施する。

図９に、このフローチャートを示す。本ゲートウェイ装置１は、図５〜８に示した処理と並行に図９に示す処理を定期的に実施する。

まず、バッファ１０に保持された応答フレームのファーストフレーム（ＦＦ）を読み出す（Ｓ５００）。

次に、診断ツール２へ応答フレームを送信する際の優先度を決定する（Ｓ５０２）。本実施形態においては、上記したＩＳＯ規格等の法規に従って優先度を決定する。なお、ＩＳＯ１５０３１−４ ＯＢＤIIでは、ＣＡＮＩＤにより、応答フレームを送信する際の優先度が規定されている。ここでは、このＩＳＯ規格に従って優先度を決定する。

次に、Ｓ５０２にて決定された優先度に従ってバッファ１０から読み出した応答フレームを診断ツール２へ送信する（Ｓ５０４）。

次に、バッファ１０が空になったか否かを判定する（Ｓ５０６）。具体的には、バッファ１０保持された応答データが送信されたか否かを判定する。ここで、バッファ１０保持された応答データが未送信となっている場合、Ｓ５０６の判定はＮＯとなり、Ｓ５００へ戻る。このようにして、バッファ１０に保持された応答フレームが順次診断ツール２へ送信される。また、バッファ１０に保持された全ての応答フレームの送信が完了すると、Ｓ５０６の判定はＹＥＳとなり、本処理を終了する。

また、本ゲートウェイ装置１は、機能要求フレームを受信したＥＣＵ３０から診断ツール２への応答フレームを中継した後、ＥＣＵ３０が診断ツール２からのフローコントロールフレーム（ＦＣ）を規定時間内に受信できずにタイムアウトしないよう、このＥＣＵ３０にウェイトを指示する処理を実施する。

図１０に、このフローチャートを示す。本ゲートウェイ装置１は、図５〜９に示した処理と並行に図１０に示す処理を定期的に実施する。

まず、ウェイト送信判定処理を実施する（Ｓ６００）。本実施形態では、Ｓ３０２にて計時を開始するカウンタのカウント値を参照し、このカウント値に基づいてＥＣＵ３０がタイムアウトするか否かの判定処理と、バッファ１０に保持した応答フレーム（バッファデータ）の診断ツール２への送信が未完了であるか否かの判定処理を行う。

次に、ＥＣＵ３０がタイムアウトするか否かを判定する（Ｓ６０２）。ここで、Ｓ６００のウェイト送信判定処理において、ＥＣＵ３０がタイムアウトするという判定結果が得られた場合、Ｓ６０２の判定はＹＥＳとなり、次に、診断ツール２に代わって、フローコントロールフレーム（ＦＣ）のウェイトを代行送信する（Ｓ６０４）。具体的には、フローステータス（ＦＳ）をウェイト（ＷＴ）に指定したフローコントロールフレーム（ＦＣ）をＥＣＵ３０へ送信する。

なお、このフローステータス（ＦＳ）をウェイト（ＷＴ）に指定したフローコントロールフレーム（ＦＣ）を受信したＥＣＵ３０は一定期間、待機を継続し、タイムアウトしなくなる。ただし、一定期間を超えても、次のフローコントロールフレーム（ＦＣ）が受信されないとタイムアウトする。

次に、バッファ１０に保持された応答フレーム（バッファデータ）の診断ツール２への送信が完了したか否かを判定する（Ｓ６０６）。

ここで、バッファ１０に保持された応答フレーム（バッファデータ）の診断ツール２への送信が完了していない場合、Ｓ６０６の判定はＮＯとなり、Ｓ６００へ戻る。

また、Ｓ６００のウェイト送信判定処理において、ＥＣＵ３０がタイムアウトしないという判定結果が得られた場合、Ｓ６０２の判定はＮＯとなり、次に、バッファ１０に保持された応答フレーム（バッファデータ）の診断ツール２への送信が完了したか否かを判定する（Ｓ６０８）。

ここで、バッファ１０に保持された応答フレーム（バッファデータ）の診断ツール２への送信が完了していない場合、Ｓ６０８の判定はＮＯとなり、Ｓ６００へ戻る。

そして、バッファ１０に保持された応答フレーム（バッファデータ）の診断ツール２への送信が完了すると、Ｓ６０８の判定はＹＥＳとなり、本処理を終了する。

図１１に、診断ツール２、ゲートウェイ装置１およびＥＣＵ３０の間のフレームの流れを示す。機能アドレス要求フレームの一斉送信に応答してＥＣＵ３０から集中的に応答フレームのファーストフレーム（ＦＦ）がゲートウェイ装置１に送信されると、ゲートウェイ装置１は、バッファ１０に応答フレームのファーストフレーム（ＦＦ）を順次保持させる。

ゲートウェイ装置１は、バッファ１０に保持された応答フレームを診断ツール２へ速やかに送信することができない場合、応答フレームを送信したＥＣＵ３０がタイムアウトすることのないように、診断ツール２に代わって、応答フレームを送信したＥＣＵ３０へフローステータス（ＦＳ）をウェイト（ＷＴ）に指定したフローコントロールフレーム（ＦＣ）を代行送信する。

なお、フローステータス（ＦＳ）をウェイト（ＷＴ）に指定したフローコントロールフレーム（ＦＣ）を受信したＥＣＵ３０は、一定期間、待機を継続する。

また、ゲートウェイ装置１は、バッファ１０に保持された応答フレームをバッファ１０から読み出して診断ツール２へ送信するまで、一定期間毎にＥＣＵ３０へフローステータス（ＦＳ）をウェイト（ＷＴ）に指定したフローコントロールフレーム（ＦＣ）を代行送信する。

そして、ゲートウェイ装置１は、バッファ１０に保持された応答フレームを診断ツール２へ送信すると、フローステータス（ＦＳ）をウェイト（ＷＴ）に指定したフローコントロールフレーム（ＦＣ）の送信を中止する。

そして、診断ツール２からＥＣＵ３０へのフローコントロールフレーム（ＦＣ）を受信すると、このフローコントロールフレーム（ＦＣ）をＥＣＵ３０へ中継する。

ＥＣＵ３０は、このフローコントロールフレーム（ＦＣ）を受信すると、通常処理を開始し、診断ツール２からのフローコントロールフレーム（ＦＣ）に従ってコンゼクティブフレーム（ＣＦ）の送信を行う。

ゲートウェイ装置１は、このコンゼクティブフレーム（ＣＦ）を受信すると、このコンゼクティブフレーム（ＣＦ）を診断ツール２へ中継する。

また、ゲートウェイ装置１は、診断ツール２からこのコンゼクティブフレーム（ＣＦ）の受信に応答するコンゼクティブフレーム（ＣＦ）を受信すると、このコンゼクティブフレーム（ＣＦ）をＥＣＵ３０へ中継する。

上記した構成によれば、診断ツール２から複数のＥＣＵ３０に対する一斉送信を表す要求フレームを受信すると、該要求フレームを複数のＥＣＵ３０に一斉送信し、要求フレームの受信に応答して複数のＥＣＵ３０から送信される応答フレームを受信すると、該受信した応答フレームをバッファ１０に保持させ、バッファ１０に保持された応答フレームを診断ツール２へ中継するので、各ＥＣＵ３０からの応答フレームを受信して診断ツール２に中継することができる。また、応答フレームを送信したＥＣＵ３０に、タイムアウトしないように待機を指示する待機指示フレームを送信するので、各ＥＣＵ３０がタイムアウトしないようにすることもできる。

なお、待機指示フレームは、ウェイト（ＷＴ）をフローステータス（ＦＳ）に指定したフローコントロールフレーム（ＦＣ）とすることができる。

また、バッファ１０に保持された応答フレームを診断ツール２へ送信する際の優先度を特定し、この優先度に従ってバッファ１０に保持された応答フレームを診断ツール２へ送信することもできる。

また、要求フレームの受信に応答してＥＣＵ３０から送信される応答フレームを受信すると、該応答フレームを受信してからの時間を計測し、この計測された時間に基づいて応答フレームを送信したＥＣＵ３０がタイムアウトするか否かを判定し、応答フレームを送信したＥＣＵ３０がタイムアウトすると判定された場合、応答フレームを送信したＥＣＵ３０に待機指示フレームを送信するので、待機指示フレームを送信する必要のないＥＣＵ３０に待機指示フレームを送信してしまうといったことを防止することができる。

（第２実施形態）
上記第１実施形態では、診断ツール２へ応答フレームを送信する際の優先度をＩＳＯ規格等の法規に従って決定したが、このような法規に従いつつ、以下の条件を満たすように上記優先度を決定することもできる。

（１）ウェイト（ＷＴ）をフローステータス（ＦＳ）に指定したフローコントロールフレーム（ＦＣ）を送信しないとタイムアウトしてしまうと推定されるＥＣＵの優先度を高くするように上記優先度を決定する。

（２）診断ツール２から最も離れたバスに接続されているＥＣＵの優先度が高くなるように上記優先度を決定する。ここで、診断ツール２から最も離れたバスに接続されているＥＣＵは、例えば、診断ツール２から最も物理的に離れた場所に位置するＥＣＵとすることもでき、診断ツール２との間に介在するゲートウェイ数の最も多いＥＣＵとすることもできる。

（３）接続されているＥＣＵ数の最も多いバスに接続されているＥＣＵの優先度が高くなるように上記優先度を決定する。

（４）一番最初に応答フレームを送信したＥＣＵの優先度が高くなるように上記優先度を決定する。

（５）シングルフレーム（ＳＦ）よりもファーストフレーム（ＦＦ）を送信したＥＣＵの優先度が高くなるように上記優先度を決定する。

（６）ＣＡＮＩＤの若いＥＣＵの優先度が高くなるように上記優先度を決定する。

（７）バスチャンネルの若いバスに接続されているＥＣＵの優先度が高くなるように上記優先度を決定する。

（他の実施形態）
上記実施形態では、ゲートウェイ装置１として、５系統のバスの各々に１５個のＥＣＵを接続することが可能なセントラルゲートウェイを例に示したが、バスの系統の数や、１つのバスに接続可能なＥＣＵの数は、上記実施形態に示したものに限定されるものではない。

また、上記実施形態では、各ＥＣＵ３０に割り当てられたＣＡＮＩＤ毎にバッファ１０を設けたが、例えば、バス毎にバッファを設けて各バッファに応答フレームを保持させるようにしたり、大容量のバッファを設け、一元管理するようにこの大容量のバッファに応答フレームを保持させるようにすることもできる。

なお、上記実施形態における構成と特許請求の範囲の構成との対応関係について説明すると、Ｓ１０２がフレーム一斉送信手段に相当し、バッファ１０が保持手段に相当し、Ｓ２０２がフレーム保持手段に相当し、Ｓ５０４が中継手段に相当し、Ｓ６０４が待機指示フレーム送信手段に相当し、Ｓ５０２が優先度特定手段に相当し、Ｓ３０２が計時手段に相当し、Ｓ６０２がタイムアウト判定手段に相当する。

１ ゲートウェイ装置
２ 診断ツール
１０ バッファ
３０ ＥＣＵ

Claims (3)

1. 診断ツール（２）と、複数の制御装置（３０）との間のフレームを中継するゲートウェイ装置（１）であって、
   前記診断ツールから前記複数の制御装置に対する一斉送信を表す要求フレームを受信すると、該要求フレームを前記複数の制御装置に一斉送信するフレーム一斉送信手段（Ｓ１０２）と、
   前記要求フレームの受信に応答して前記複数の制御装置から送信される応答フレームを受信すると、該受信した応答フレームを保持手段（１０）に保持させるフレーム保持手段（Ｓ２０２）と、
   前記保持手段に保持された前記応答フレームを前記診断ツールへ中継する中継手段（Ｓ５０４）と、
   前記応答フレームを送信した前記制御装置に、タイムアウトしないように待機を指示する待機指示フレームを送信する待機指示フレーム送信手段（Ｓ６０４）と、を備えたことを特徴とするゲートウェイ装置。
2. 前記保持手段に保持された前記応答フレームを前記診断ツールへ送信する際の優先度を特定する優先度特定手段（Ｓ５０２）を備え、
   前記中継手段は、前記優先度特定手段により特定された優先度に従って前記保持手段に保持された前記応答フレームを前記診断ツールへ送信することを特徴とする請求項１に記載のゲートウェイ装置。
3. 前記要求フレームの受信に応答して前記制御装置から送信される応答フレームを受信すると、該応答フレームを受信してからの時間を計測する計時手段と、
   前記計時手段により計測された時間に基づいて前記応答フレームを送信した前記制御装置がタイムアウトするか否かを判定するタイムアウト判定手段（Ｓ６０２）と、を備え、
   前記待機指示フレーム送信手段は、前記タイムアウト判定手段により前記応答フレームを送信した前記制御装置がタイムアウトすると判定された場合、前記応答フレームを送信した前記制御装置に前記待機指示フレームを送信することを特徴とする請求項１または２に記載のゲートウェイ装置。

Images