JP5472276B2 - 車両用通信制御装置 - Google Patents

Description

本発明は、インターネットプロトコル（ＩＰ）ベースのネットワークに接続された外部ツールと、車内のローカルエリアネットワーク（ＬＡＮ）に接続された車載ＥＣＵとの間でメッセージの送受信を行うことを可能とすべく、両ネットワーク間に介在してメッセージの中継を行う車両用通信制御装置に関する。

従来、車両に搭載された電子制御システムと、外部ツールとしての診断ツールとを通信可能に接続し、電子制御システムから異常データ（ダイアグコード）などを読みだすことなどが行われている。すなわち、電子制御システムには、外部ツールを接続するためのインターフェースが設けられている。そして、外部ツールは、例えば特許文献１に記載されるように、ＣＡＮプロトコルに従って電子制御システムとメッセージの送受信を行って、ダイアグコードなどの必要なデータを電子制御システムから読み出す。

また、例えば特許文献２，３などに記載されるように、外部ツールとして、プログラム書換ツールを電子制御システムに接続し、フラッシュＲＯＭなどに記憶された制御プログラムの書き換えを行う場合もある。

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

近年、車両に搭載される電子制御システムの数が増加していることに加え、それぞれの電子制御システムの機能数の増加や、記憶容量の増大等のため、外部ツールとの間でやり取りされるデータ量も今後飛躍的に増加することが予想される。このため、コンピュータネットワークと同様の通信規格（インターネットプロトコル：ＩＰ)を用いて、車載電子制御システムと外部ツールとの通信をより効率的に行うことが検討されている。

具体的には、ＩＰベースのネットワークを利用して、車両に搭載された車載電子制御システムと外部ツールとが通信を行うための規格（Diagnostics over Internet protocol : DoIP）が、ＩＳＯ１３４００として検討されている。このＤｏＩＰでは、外部ツールが、ＩＰベースのネットワークであるイーサネット（登録商標、以下同様）を介して、車両内のローカルエリアネットワーク（ＬＡＮ）に存在する車載ＥＣＵと通信を行う。車内ＬＡＮでは、ＣＡＮやＬＩＮなどの通信プロトコルが用いられており、車両内外のネットワークの通信プロトコルが異なる。このため、車両内外の両ネットワーク間に介在してメッセージの中継を行う車両用通信制御装置（ＤｏＩＰゲートウェイ）が設けられる。

ここで、ＤｏＩＰがサポートされている場合、車両外のネットワークに同時に複数の外部ツールを接続することが可能となる。そのため、複数の外部ツールが、同じ車載ＥＣＵに対して、同時期に、それぞれ所定の操作を要求するメッセージを送信することが起こりえる。そして、ＤｏＩＰゲートウェイが、それぞれのメッセージをそのまま車載ＥＣＵにゲートウェイさせてしまうと、それぞれの外部ツールからのメッセージの種別によっては、車載ＥＣＵでの動作に干渉を生じてしまう可能性が生じる。

例えば、外部ツールＡが車載ＥＣＵに対して制御プログラム及びデータの書き換えを実行するためのメッセージを送信し、別の外部ツールＢが、外部ツールＡとは異なるデータの書き込みを要求するメッセージを送信したとする。この場合、車載ＥＣＵが、両方のメッセージに応じた操作を同時期に行なってしまうと、外部ツールＡにより書き換えられた制御プログラムが、外部ツールＢにより書き込まれたデータに基づく制御を行なってしまい、適切な制御を行いえない事態が生じる可能性がある。

また、別の例として、外部ツールＡが車載ＥＣＵに対して制御プログラムやデータの書き換えを実行するためのメッセージを送信しているときに、同じ車載ＥＣＵに対して、外部ツールＢからリセットを要求するメッセージが送信されたとする。この場合、車載ＥＣＵにおいて、外部ツールＡによる制御プログラムやデータの書き換え処理途中で、車載ＥＣＵがリセットされてしまい、書き換え処理を正常に行いえない事態が生じる可能性がある。

さらに、別の例として、外部ツールＡが、車載電子制御システムの故障診断を行うため、車載ＥＣＵが異常検出時に保存している、データ１とデータ２とを取得するためのメッセージを送信したとする。なお、データ１とデータ２とは、相互に関連するものであって、両データの内容から、車載電子制御システムの故障や不具合が正しく判別できるものである。その際、別の外部ツールＢが同じ車載ＥＣＵと通信中であり、外部ツールＢは、必要なデータを取得後、車載ＥＣＵに対して保存しているデータの消去を要求するメッセージを送信したとする。この場合、外部ツールＡによる一連のデータの取得処理の途中で、外部ツールＢからのメッセージに応じて、データ消去が行われたとすると、外部ツールＡは、例えばデータ消去前のデータ１と、データ消去後のデータ２とを取得することが起こりえる。すると、これらのデータ１とデータ２との間には整合性が無くなってしまうので、これらのデータに基づいて、故障診断を正しく行うことができなくなってしまう。さらに、外部ツールＡが取得した整合性の無い一連のデータから、車載ＥＣＵになんらかの故障が生じていると誤判断されてしまう可能性も生じる。

本発明は、上述した点に鑑みてなされたもので、複数の外部ツールが車両外のネットワークに接続された場合であっても、それら複数の外部ツールからのメッセージにより、車載ＥＣＵでの動作の干渉を回避することが可能な車両用通信制御装置を提供することを目的とする。

上記目的を達成するために、請求項１に記載の車両用通信制御装置は、インターネットプロトコル（ＩＰ）ベースのネットワークに接続された外部ツールと、車内のローカルエリアネットワーク（ＬＡＮ）に接続された車載ＥＣＵとの間でメッセージの送受信を行うことを可能とすべく、両ネットワーク間に介在してメッセージの中継を行うものであって、
外部ツールからメッセージを受信したとき、そのメッセージを受信すべき車載ＥＣＵに向けて、当該メッセージを転送する転送手段と、
転送手段が、外部ツールとして、第１の外部ツールからのメッセージを車載ＥＣＵに転送したとき、第１の外部ツールからのメッセージに起因する車載ＥＣＵとの通信が終了するまで、メッセージの種別を記憶しておく記憶手段と、
第１の外部ツールと通信中の車載ＥＣＵに対して、第１の外部ツールとは異なる第２の外部ツールからのメッセージを受信したとき、その受信したメッセージの種別と、記憶手段に記憶しているメッセージの種別とに基づいて、それぞれのメッセージにより車載ＥＣＵにおける動作が干渉を生じるか否かを判定する干渉判定手段と、を備え、
転送手段は、干渉判定手段によって干渉が生じないと判定された場合に、第２の外部ツールからのメッセージを車載ＥＣＵに転送することを特徴とする。

このように、請求項１に記載の通信制御装置は、第１の外部ツールからメッセージを受信し、それを車載ＥＣＵに転送することによって通信が開始されると、その転送したメッセージの種別を、通信終了まで記憶する記憶手段を備えている。このため、後に、第２の外部ツールから同じ車載ＥＣＵに向けられたメッセージを受信したときに、両メッセージにより車載ＥＣＵにおける動作が干渉を生じるか否かを判定手段において判定することができる。そして、転送手段は、車載ＥＣＵにおける動作が干渉を生じないとの判定がなされた場合に、第２の外部ツールからのメッセージを車載ＥＣＵに転送するので、車載ＥＣＵにおける動作の干渉を回避することが可能となる。さらに、例えば、車載ＥＣＵがある外部ツールと通信中である場合には、別の外部ツールとの通信を一律に禁止する場合に比較して、車載ＥＣＵにおける動作干渉が生じない限り、外部ツールからのメッセージを車載ＥＣＵに転送するので、外部ツールとの通信を効率的に行なわせることが可能となる。

請求項２に記載したように、干渉判定手段によって干渉が生じると判定されたとき、第２の外部ツールに向けて、メッセージの受信を否認する旨の応答メッセージを送信する否認応答手段を備えるようにしても良い。これにより、第２の外部ツールの作業者は、第２の外部ツールからのメッセージの受信が否認されたことを把握でき、例えば、他の外部ツールとの通信終了を待って、再度、第２の外部ツールから同じメッセージを送信させる等の処置を取ることが可能となる。

また、請求項３に記載したように、干渉判定手段によって干渉が生じると判定されたとき、第２の外部ツールからのメッセージを保存する保存手段を備え、保存手段に保存されたメッセージに対して、車載ＥＣＵにおける動作が干渉を生じる、第１の外部ツールからのメッセージに起因する通信が終了し、干渉判定手段における判定結果が干渉を生じないとの判定結果に変化したとき、転送手段は、保存手段に保存されたメッセージを車載ＥＣＵに転送するようにしても良い。このようにすれば、車載ＥＣＵにおける動作の干渉が生じない状態となったとき、自動的に第２の外部ツールからのメッセージが車載ＥＣＵに転送される。従って、再度、第２の外部ツールから同じメッセージを送信するための手間を省くことができる。

請求項４に記載したように、車載ＥＣＵが第１の外部ツールと通信中であって、第２の外部ツールからのメッセージが保存手段に保存されている状態において、第１及び第２の外部ツールとは異なる第３の外部ツールから車載ＥＣＵへのメッセージを受信したとき、第３の外部ツールからのメッセージと、車載ＥＣＵと通信中の第１の外部ツールからのメッセージとは、車載ＥＣＵにおける動作が干渉を生じるものではないと干渉判定手段によって判定されたならば、第３の外部ツールからのメッセージと、保存手段に保存されている、第２の外部ツールからのメッセージとが、車載ＥＣＵにおける動作が干渉を生じるものであっても、転送手段は、第３の外部ツールからのメッセージを車載ＥＣＵに転送するようにしても良い。この場合、第２の外部ツールからのメッセージは、車載ＥＣＵへの転送が保留されており、第３の外部ツールからのメッセージを車載ＥＣＵに転送しても、車載ＥＣＵにおける動作干渉を生じないためである。

請求項５に記載したように、記憶手段は、第１の外部ツールからのメッセージを車載ＥＣＵに転送してから、第１の外部ツールから新たなメッセージを受信することなく、所定時間経過すると、当該メッセージに起因する通信が終了したとみなして、記憶しているメッセージの種別を消去するようにしても良い。このように、第１の外部ツールからのメッセージの転送から、新たなメッセージを受信することなく、所定時間が経過した場合には、そのメッセージに起因する通信は終了したとみなすことができる。そして、通信終了と判断したときに、記憶手段に記憶されたメッセージの種別を消去することにより、新たにメッセージを受信した場合に、すみやかに車載ＥＣＵへ転送することができる。

請求項６に記載したように、転送手段は、車載ＥＣＵへ転送された第１の外部ツールからのメッセージに対する、当該車載ＥＣＵからの応答メッセージが受信されたとき、その応答メッセージを第１の外部ツールへ転送するものであり、車載ＥＣＵからの応答メッセージの内容を解読する解読手段を備え、応答メッセージの内容が、第１外部ツールからのメッセージに応答しない旨を示す否定応答であった場合、記憶手段は、記憶しているメッセージの種別を消去することが好ましい。車載ＥＣＵから否定応答メッセージが送信されると、その時点で、車載ＥＣＵと第１外部ツールとの通信は終了するとみなすことができるためである。

請求項７に記載したように、転送手段は、車載ＥＣＵへ転送された第１の外部ツールからのメッセージに対する、当該車載ＥＣＵからの応答メッセージが受信されたとき、その応答メッセージを第１の外部ツールへ転送するものであり、車載ＥＣＵからの応答メッセージの内容を解読する解読手段を備え、応答メッセージの内容が、第１外部ツールからのメッセージに応答する旨を示す肯定応答であった場合、転送手段による応答メッセージの転送から、第１の外部ツールから新たなメッセージを受信することなく、所定時間経過すると、記憶手段は、当該メッセージに起因する通信が終了したとみなして、記憶しているメッセージの種別を消去するようにしても良い。このように、所定時間の計時開始は、車載ＥＣＵから第１の外部ツールへの応答メッセージが送信されたときとしても良い。

請求項８に記載したように、記憶手段は、記憶しているメッセージの種別とは異なる種別のメッセージを第１の外部ツールから受信したとき、種別を記憶しているメッセージに起因する通信は終了したとみなして、その記憶しているメッセージの種別に代えて、新たに受信したメッセージの種別を記憶することが好ましい。記憶しているメッセージの種別とは異なる種別のメッセージを第１の外部ツールから受信した場合、その受信した種別のメッセージに起因する通信が開始されるためである。

請求項９に記載したように、車載ＥＣＵにおける動作が干渉を生じるメッセージの種別の組み合わせは、予め定義され、その定義情報を記憶した定義情報記憶手段を備え、干渉判定手段は、その定義情報を参照して、車載ＥＣＵにおける動作が干渉を生じるものであるか否かを判定することが好ましい。外部ツールと車載ＥＣＵとの間で送受信されるメッセージの種別は予め判明しており、いずれのメッセージの種別の組み合わせが、車載ＥＣＵにおいて動作干渉を生じるかは事前に特定できるためである。

通信制御装置としてのＤｏＩＰゲートウェイを介して通信が行われるシステム全体の構成を示す構成図である。 ＤｏＩＰゲートウェイの各機能を機能ブロックとして表したブロック図である。 干渉定義情報テーブルの一例を示す図である。 通信状態管理部が管理する通信状態情報の構成の一例を示す図である。 ＤｏＩＰゲートウェイにおいて、ツール１〜ｎからの要求メッセージを受信したときに実行される干渉判定処理を示すフローチャートである。 通信状態情報の更新処理を示すフローチャートである。 図５及び図６のフローチャートに示す処理を実行することにより、どのようにしてＥＣＵ１〜ｍの動作干渉の防止が図り得るかについて説明するための説明図である。 第２実施形態において、メッセージ保留機能を実現するために必要な、通信状態情報の構成の一例を示す図である。 第２実施形態における、干渉判定処理を示すフローチャートである。 図９のフローチャートのステップＳ９０６における干渉情報設定処理の詳細を示すフローチャートである。 第２実施形態における、通信状態情報の更新処理を示すフローチャートである。

（第１実施形態）
以下、本発明の第１実施形態による車両用通信制御装置について、図面を参照しつつ説明する。なお、以下の本実施形態の説明では、車両用通信制御装置が、ＤｏＩＰゲートウェイとして具現化されている。

図１は、ＤｏＩＰゲートウェイ１０１を介して通信が行われるシステム全体の構成を示している。本システムにおいて、ＤｏＩＰゲートウェイ１０１は、車両内に設置され、車両内のローカルエリアネットワーク（ＬＡＮ）に接続されている。この車内ＬＡＮには、少なくとも１つの車載ＥＣＵ１０２（ＥＣＵ１〜ｍ）が接続されている。従って、ＤｏＩＰゲートウェイ１０１は、車内ＬＡＮを介して車載ＥＣＵ１０２と通信を行うことができる。なお、車内ＬＡＮの通信プロトコルには、ＣＡＮやＬＩＮなどが用いられる。

また、ＤｏＩＰゲートウェイ１０１は、ＩＰベースのネットワークとしてのイーサネットを介して、少なくとも１つの車両外部のツール１０３（ツール１〜ｎ）と接続されている。なお、イーサネットとＤｏＩＰゲートウェイ１０１とを接続する際、その接続は有線にて行なっても良いし、無線にて行なっても良い。

イーサネットにおいては、通信プロトコルとして、ＩＳＯ１３４００に規定されたＤｏＩＰ(Diagnostics on Internet protocol)が用いられる。一方、車載ＬＡＮでは、上述したように、通信プロトコルとしてＣＡＮやＬＩＮが用いられる。このように車両内外のネットワークにおける通信プロトコルが異なるので、ＤｏＩＰゲートウェイ１０１が、外部ツール１０３から車載ＥＣＵ１０２へ、又は車載ＥＣＵ１０２から外部ツール１０３へメッセージを転送する際には、メッセージのプロトコル変換を行う。このようなプロトコル変換を伴うメッセージの転送を、以下、ゲートウェイと呼ぶ。

外部ツール１０３は、車載ＥＣＵ１０２との間でのメッセージのやり取りを通じて、車載ＥＣＵ１０２からダイアグコードを読み出したり、内部データを読みだしたり、車載ＥＣＵ１０２をリセットしたりするものである。また、外部ツール１０３は、車載ＥＣＵ１０２における制御プログラムを更新するために制御プログラムの書き換えを行ったり、データの書き込みや消去を行ったりすることもある。このような外部ツール１０３は、車載ＥＣＵ１０２と、ＤｏＩＰ通信を行い得るハードウェア又はソフトウェアにより構成される。

次に、図２を参照して、ＤｏＩＰゲートウェイ１０１が有する機能について説明する。なお、図２においては、ＤｏＩＰゲートウェイ１０１の各機能を機能ブロックとして表している。

図２に示すように、ＤｏＩＰゲートウェイ１０１は、イーサネットを介しての通信を実現するために、イーサネット通信部２０１及びイーサネット通信部２０１に対する送受信メッセージを格納するためのバッファ２０３を有している。また、ＤｏＩＰゲートウェイ１０１は、車内ＬＡＮを介しての通信を実現するために、ローカルネットワーク通信部２０２及び車両内の送受信メッセージを格納するバッファ２０４を有している。さらに、ＤｏＩＰゲートウェイ１０１は、イーサネット用のバッファ２０３と車内ＬＡＮ用のバッファ２０４との間に、ゲートウェイ機能を実現するためのゲートウェイ処理部２０５を有している。

ゲートウェイ処理部２０５には、ＤｏＩＰメッセージを受信及び送信するためのＩＰメッセージ受信処理部２０６及びＩＰメッセージ送信処理部２０７が設けられている。これらＩＰメッセージ受信処理部２０６及びＩＰメッセージ送信処理部２０７は、イーサネット用のバッファ２０３との間で、受信メッセージ及び送信メッセージの受け渡しを行う。さらに、ゲートウェイ処理部２０５には、車内ＬＡＮ上におけるメッセージを送受信するための車内メッセージ受信処理部２０８と車内メッセージ送信処理部２０９とが設けられている。これら車内メッセージ受信処理部２０８及び車内メッセージ送信処理部２０９は、車内ＬＡＮ用のバッファ２０４との間で、受信メッセージ及び送信メッセージの受け渡しを行う。

ＩＰメッセージ受信処理部２０６と車内メッセージ送信処理部２０９との間に車外→車内ゲートウェイ処理部２１０が設けられている。また、ＩＰメッセージ送信処理部２０７と車内メッセージ受信処理部２０８との間に車内→車外ゲートウェイ処理部２１１が設けられている。これらの車外→車内ゲートウェイ処理部２１０及び車内→車外ゲートウェイ処理部２１１は、外部ツール１０３からの要求メッセージを車載ＥＣＵ１０２にゲートウェイしたり、車載ＥＣＵ１０２からの応答メッセージを外部ツール１０３にゲートウェイしたりするために必要な、通信プロトコルの変換とアドレスの変換を行うものである。

ＩＰメッセージ受信処理部２０６と車外→車内ゲートウェイ処理部２１０との間に、さらに干渉判定部２１２が設けられている。この干渉判定部２１２は、複数の外部ツール１０３（ツール１〜ｎ）が、車載ＥＣＵ１０２の同じＥＣU１〜ｍに対して、同時期に、要求メッセージを送信してきた場合に、それらの要求メッセージによりＥＣＵ１〜ｍでの動作が干渉を生じるか否かを判定するものである。その判定の結果、動作干渉が生じないと判定したときには、干渉判定部２１２は、要求メッセージを車外→車内ゲートウェイ処理部２１０に渡して、送信先ＥＣＵ１〜ｍへゲートウェイさせる。一方、干渉が生じると判定したときには、干渉判定部２１２は、後に受信した要求メッセージを車外→車内ゲートウェイ処理部２１０に出力せず、送信先ＥＣＵ１〜ｍへのゲートウェイを行わせない。

この場合、図２には示していないが、干渉判定部２１２は、応答メッセージ出力部に対して、受信を否認する旨の否定応答メッセージの出力指示を行う。この否定応答メッセージがイーサネット通信部２０１を介して、要求メッセージを送信したツール１〜ｎに送信されることにより、ツール１〜ｎの作業者は、そのツール１〜ｎからの要求メッセージの受信が否認されたことを把握でき、例えば、他のツール１〜ｎとの通信終了を待って、再度、ツール１〜ｎから同じ要求メッセージを送信させる等の処置を取ることが可能となる。なお、干渉判定部２１２は、送信先ＥＣＵ１〜ｍにおける動作干渉が生じないと判定した場合、応答メッセージ出力部に対して、要求メッセージの受信を承認した旨を示す肯定応答メッセージの出力指示を行う。

干渉判定部２１２は、上述した干渉判定を行う際、干渉定義情報記憶部２１３に記憶された干渉定義情報テーブル、及び通信状態管理部２１４に保存されている、車載ＥＣＵ１０２としての各ＥＣＵ１〜ｍと外部ツール１０３としての各ツール１〜ｎとの通信状態に関する情報（以下、通信状態情報）を参照する。

干渉定義情報テーブルとは、先に受信した要求メッセージの種別に対する、後に受信した要求メッセージの種別の組み合わせが、送信先ＥＣＵ１〜ｍでの動作干渉を生じる組み合わせであるかどうかに関する情報をまとめたものである。各ツール１〜ｎから各送信先ＥＣＵ１〜ｍへ送信される要求メッセージの種別は予め判明しており、いずれの要求メッセージの種別の組み合わせが、送信先ＥＣＵ１〜ｍでの動作干渉を生じるかは事前に特定できるためである。

図３に、干渉定義情報テーブルの一例を示す。この干渉定義情報テーブルには、ＤｏＩＰゲートウェイ１０１に接続されている各ＥＣＵ１〜ｍがサポートする全てのダイアグ要求メッセージの種別が登録されている。干渉定義情報デーブルにおいては、先に受信されて、通信中となっている要求メッセージの種別が前回要求の種別となり、後に受信された要求メッセージの種別が今回要求の種別となる。そして、前回要求の種別に対する今回要求の種別に応じて、「許可」か「禁止」の状態が定められている。なお、禁止状態は、後に受信された要求メッセージが、先に受信され通信中の要求メッセージに対して、送信先ＥＣＵ１〜ｍでの動作干渉を引き起こすものであることを意味する。

ここで、干渉とは、典型的には、「発明が解決しようとする課題」の欄に説明したいくつかのケースのように、ＥＣＵ１〜ｍが正常な動作を行い得なくなったり、正しいデータをＥＣＵ１〜ｍから取得できなくなったりする状況の発生を意味するものである。ただし、干渉の定義は、車両の機能及び車内ＬＡＮのトポロジーにより変わるものであり、車両安全とデータの保全性を考慮して要求メッセージの実行可否を決める必要がある。例えば、ツール１が、セキュリティ関連処理として、ＥＣＵ１のセキュリティ解除を要求するメッセージを送信し、ＥＣＵ１がセキュリティを解除したとする。その場合、ツール２が、同じＥＣＵ１に対してＥＣＵ内部データの取得を要求するメッセージを送信したとする。ＥＣＵ１やツール１，２にとっては、この二つの要求は特に問題なく同時に実行できる。しかし、この場合、ツール２が、ツール１によるセキュリティ解除状態に便乗して、本来取得できないＥＣＵ内部データを取得できてしまう危険性が存在する。そのため、図３に示す干渉定義情報テーブルでは、このようなケースをＥＣＵ１〜ｍにて動作干渉が生じるものとみなし、あるツール１がＥＣＵ１とセキュリティ関連の処理を実施するための通信を行なっている場合、他のツール２によるＥＣＵ内部データ取得処理を禁止している。

なお、図３における「セッション移行」とは、ツール１〜ｎが、ＥＣＵ１〜ｍに対して要求可能なメッセージの種別の範囲を切り替えることを意味する。例えば、あるツール１〜ｎでは、セッション移行を要求するメッセージを送信することができないように設定される。その場合、そのツール１〜ｎは、異常データの取得等、制限された要求メッセージに対する応答メッセージしかＥＣＵ１〜ｍから取得することができなくなる（制限範囲外の要求メッセージに対しては、ＥＣＵ１〜ｍは応答しない）。一方、別のツール１〜ｎでは、セッション移行を要求するメッセージを送信可能に設定される。ＥＣＵ１〜ｍにセッション移行要求メッセージを送信することにより、ＥＣＵ１〜ｍは、全ての要求メッセージを受け付けて、応答メッセージを送信する状態に移行する。この際、要求可能なメッセージの範囲を３段階以上に設定することももちろん可能である。

このようなセッション移行要求は、セキュリティ解除要求とセットで用いられることが多い。セキュリティ解除要求には、通常、暗証番号による認証が必要である。このため、セキュリティが解除された状態のときにのみ、セッション移行を許可するようにすることで、権限を有する作業者のみに、データの書き込み等の重要な処理の実行を認めることが可能になるためである。

次に、通信状態管理部２１４が管理する通信状態情報について説明する。

図１に示すように、イーサネットには、外部ツール１０３として、複数のツール１〜ｎが接続され、車内ＬＡＮにも、車載ＥＣＵ１０２として、複数のＥＣＵ１〜ｍが接続される場合がある。このため、ＤｏＩＰゲートウェイ１０１は、複数のツール１〜ｎから同時期に、同じＥＣＵ１〜ｍに向けられた要求メッセージを受信する場合がある。このようなツール１〜ｎとＥＣＵ１〜ｍとの間のN対M通信における干渉判定のため、通信状態管理部２１４は、以下に述べる情報を通信状態情報として管理する。

まず、通信状態管理部２１４は、図４の左側に示すように、ＥＣＵ１〜ｍごとに、「送信先ＥＣＵの通信状態」を持つ。この通信状態は、該当するＥＣＵ１〜ｍが、少なくとも１つのツール１〜ｎと通信中であるか否かを示すものである。図４に示す例では、ＯＮ又はＯＦＦにより、該当するＥＣＵ１〜ｍが通信中か、通信中ではないかが示されている。

そして、ＥＣＵ１〜ｍの通信状態がＯＮとなっている場合、通信状態管理部２１４は、図４の右側に示すように、そのＥＣＵ１〜ｍと通信している全てのツール１〜ｎに関して、ツール１〜ｎごとに送信元情報、受信メッセージの種別情報、及び通信状態カウンタを持つ。

受信メッセージ種別情報は、図３において説明したように、干渉有無の判定根拠となる情報である。通信状態カウンタは、ツール１〜ｎからの要求メッセージが送信先ＥＣＵ１〜ｍに転送されて通信が開始されると、その通信開始からの経過時間をカウントするものである。すなわち、通信状態カウンタは、各ツール１〜ｎとの通信開始からの経過時間を示す情報となる。この通信状態カウンタによってカウントされた経過時間に基づいて、ツール１〜ｎとＥＣＵ１〜ｍとの通信が進行しているか、通信が終了したかが判定される。そのため、ツール１〜ｎから新たな要求メッセージを受信したとき、対応する通信状態カウンタをリセットした上で、通信状態カウンタによるカウントアップ開始する。そして、所定時間内に同じツール１〜ｎから同じＥＣＵ１〜ｍへの要求メッセージを受信しない場合、通信状態カウンタはタイムアウトして停止状態になる。そして、通信状態カウンタが停止状態となっているツール１〜ｎの情報（送信元情報、受信メッセージ種別情報）は、通信状態情報から削除される。通信開始から所定時間が経過した場合、ツール１〜ｎからの要求メッセージに起因する通信は終了したものとみなすことができるためである。

次に、ＤｏＩＰゲートウェイ１０１において、ツール１〜ｎからの要求メッセージを受信したときに実行される干渉判定処理について、図５のフローチャートに従って詳細に説明する。

まず、ステップＳ５０１では、いずれかのツール１〜ｎから要求メッセージを受信したとき、その要求メッセージのヘッダ、ペイロード、メッセージ長などが、ＩＳＯ１３４００−２に規定されるプロトコルを満足するものであるかが判定される。受信した要求メッセージにプロトコルの異常が存在する場合、ステップＳ５０６に進んで、否定応答メッセージを送信する。一方、要求メッセージのチェックが正常に完了した場合には、ステップＳ５０２の処理に進む。

ステップＳ５０２では、要求メッセージの送信先となるＥＣＵ１〜ｍの通信状態を、上述した「送信先ＥＣＵの通信状態」に基づいて判定する。この判定処理において、要求メッセージの送信先ＥＣＵ１〜ｍの通信状態がＯＦＦと判定された場合、ステップＳ５０９の処理に進み、送信先ＥＣＵ１〜ｍの通信状態をＯＮに変化させる。そして、続くステップＳ５１０において、通信状態情報として、要求メッセージを発したツール１〜ｎを示す送信元情報、及び要求メッセージの種別情報を記憶する。

一方、ステップＳ５０２の判定処理において、送信先ＥＣＵ１〜ｍの通信状態がＯＮと判定された場合、ステップＳ５０３の処理に進む。この場合、送信先ＥＣＵ１〜ｍは、少なくとも１つのツール１〜ｎと通信中である。従って、ステップＳ５０３〜Ｓ５０５において、今回の要求メッセージの種別が、通信中の要求メッセージ（前回の要求メッセージ）の種別に対して、送信先ＥＣＵ１〜ｍでの動作干渉を生じるものであるか否かを、通信中の全てのツール１〜ｎについて順番に判定していく。そのため、まず、ステップＳ５０３では、この動作干渉の判定が、通信中のすべての送信元としてのツール１〜ｎに関してなされたか否かが判定される。この判定処理において、通信中のすべての送信元としてのツール１〜ｎに関して動作干渉の判定が完了していないと判定された場合、ステップＳ５０４の処理に進み、完了したと判定された場合、ステップＳ５０７の処理に進む。

ステップＳ５０４では、動作干渉の判定が未完了の１つのツール１〜ｎを対象として、今回、受信した要求メッセージの送信元であるツール１〜ｎが、その判定対象となっているツール１〜ｎと異なるか否かを判定する。ツール１〜ｎが同じであれば、動作干渉を生じるような要求メッセージを発することはない。従って、ステップＳ５０４にて「Ｎｏ」と判定された場合には、ステップＳ５０３の処理に戻る。一方、要求メッセージの送信元が異なる場合、ステップＳ５０４の判定結果は「Ｙｅｓ」となり、ステップＳ５０５の処理に進む。

ステップＳ５０５では、上述した干渉定義情報テーブルを参照して、受信した要求メッセージの種別と、判定対象のツール１〜ｎからの要求メッセージの種別とに基づき、送信先ＥＣＵ１〜ｍでの動作干渉が生じるか否かを判定する。この判定処理において、動作干渉が生じると判定された場合には、ステップＳ５０６に進み、要求メッセージの受信を否認する否定応答メッセージを送信する。つまり、送信先ＥＣＵ１〜ｍと通信中のツール１〜ｎの中で、今回、受信した要求メッセージと送信先ＥＣＵ１〜ｍでの動作干渉が生じる要求メッセージを送信したツール１〜ｎが１つでも存在する場合には、今回の要求メッセージの受信が行われず、その要求メッセージを送信したツール１〜ｎに否定応答メッセージが返送される。一方、動作干渉は生じないと判定された場合には、ステップＳ５０３の処理に戻り、まだ動作干渉の判定が完了していないツール１〜ｎが残されているかを判定する。

ステップＳ５０６において否定応答メッセージが送信されることなく、ステップＳ５０３において、動作干渉の判定が、通信中のすべてのツール１〜ｎに関してなされたと判定されると、ステップＳ５０７の処理に進んで、今回、受信した要求メッセージの送信元であるツール１〜ｎの情報が、送信元情報として記憶済みのものであるか否かが判定される。すなわち、今回の要求メッセージを発したツール１〜ｎが、以前に別の要求メッセージを送信先ＥＣＵ１〜ｍに送信して、通信状態情報に登録済みのものであるか否かが判定される。

このステップＳ５０７における判定結果が「Ｙｅｓ」となった場合、ツール１〜ｎを示す送信元情報は、既に通信状態情報に記憶されているので、ステップＳ５０８に進み、受信した要求メッセージの種別に基づき、通信状態情報における要求メッセージの種別情報を更新する。新たに受信した要求メッセージに起因する通信が、送信先ＥＣＵ１〜ｍとツール１〜ｎとの間で開始されるので、その後に受信される要求メッセージとの間で、動作干渉判定を行うことに備えるためである。一方、ステップＳ５０７における判定結果が「Ｎｏ」となった場合には、ステップＳ５１０に進んで、通信状態情報に、要求メッセージを発した新たなツール１〜ｎを示す送信元情報、及びその要求メッセージの種別情報を記憶する。

続くステップＳ５１１では、ステップＳ５０８にて更新した、あるいはステップＳ５１０において記憶した要求メッセージに対応付けられた通信状態カウンタをリセットし、新たなカウントを開始させる。そして、ステップＳ５１２では、要求メッセージを、送信先ＥＣＵ１〜ｍにゲートウェイし、ステップＳ５１３では、要求メッセージを送信したツール１〜ｎに対して、要求メッセージの受信を承認したことを示す肯定応答メッセージを送信する。

次に、通信状態情報の更新処理について、図６のフローチャートに基づいて説明する。なお、図６のフローチャートに示す処理は、所定期間が経過するごとに定期的に実行される。

まず、ステップＳ６０１では、通信状態がＯＮとなっているすべてのＥＣＵ１〜ｍに関して、ステップＳ６０２以降に示す処理が実行されたか否かを判定する。このステップＳ６０１において、通信中の全ＥＣＵ１〜ｍについて処理が完了していないと判定されると、まだ処理が完了していないＥＣＵ１〜ｍの中の１つを対象として、ステップＳ６０２以降の処理が実行される。このように、通信中のＥＣＵ１〜ｍについて、１つずつ順番にステップＳ６０２以降の処理を実行した結果、ステップＳ６０１において、通信中の全ＥＣＵ１〜ｍについて処理が完了したと判定されると、図６のフローチャートに示す処理が終了する。

ステップＳ６０２では、処理対象となっている１つのＥＣＵ１〜ｍの通信状態情報に含まれる、すべての通信状態カウンタの判定がまだ完了していないかどうかを判定する。処理対象である送信先ＥＣＵ１〜ｍの通信状態情報に含まれるすべての通信状態カウンタに関して、まだ判定が完了していないと判定された場合には、ステップＳ６０３に進んで、判定未完了の通信状態カウンタを対象として、判定処理を行う。具体的には、ステップＳ６０３の判定処理では、通信状態カウンタによってカウントされた通信開始からの経過時間が予め定めた所定時間に達したか否かが判定される。

通信状態カウンタは、上述したように、同じツール１〜ｎから別の要求メッセージを受信したときにリセットされ、新たにカウントを開始する（図５のフローチャートのステップＳ５１１参照）。従って、通信状態カウンタがカウントする経過時間が所定時間に達するのは、同じツール１〜ｎから、新たな要求メッセージを受信することなく、前回の要求メッセージを受信してから所定時間が経過した場合である。そして、本実施形態では、所定時間が、ツール１〜ｎからの要求メッセージに起因して、ツール１〜ｎとＥＣＵ１〜ｍとの間で行われる通信に必要な時間以上の時間に設定されている。

このため、ステップＳ６０３において、通信状態カウンタがカウントする経過時間が所定時間に達したと判定された場合、その通信状態カウンタに対応するツール１〜ｎとの通信は終了しているとみなすことができる。そのため、ステップＳ６０４の処理に進んで、そのツール１〜ｎを示す送信元情報と、要求メッセージの種別情報とを通信状態情報から消去する。さらに、ステップＳ６０５において、通信状態カウンタによってカウントされた経過時間を消去するとともに、通信状態カウンタのカウント動作を停止させる。

上述したＳ６０３〜Ｓ６０５の処理を実行することにより、いずれ、ステップＳ６０２において、処理対象となっている１つのＥＣＵ１〜ｍの通信状態情報に含まれる、すべての通信状態カウンタの判定が完了したと判定されるようになる。すると、ステップＳ６０６の処理に進み、判定対象のＥＣＵ１〜ｍの通信状態情報における、すべての通信状態カウンタがカウント動作を停止しているか否かが判定される。すべての通信状態カウンタがカウント動作を停止している場合、処理対象となっているＥＣＵ１〜ｍはいずれのツール１〜ｎとも通信していないとみなせるので、ステップＳ６０７において、そのＥＣＵ１〜ｍの通信状態をＯＦＦに設定する。その後、通信中のＥＣＵ１〜ｍで、まだ未処理のＥＣＵ１〜ｍが残されていないかどうかを確認するために、再びステップＳ６０１の処理が実行される。

このような図６のフローチャートに示す処理を実行することにより、通信状態情報には、各ＥＣＵ１〜ｍと実際に通信中のツール１〜ｎに関する情報のみが記憶されるよう、通信状態情報を正しく更新することができる。

次に、上述した図５及び図６のフローチャートに示す処理を実行することにより、どのようにしてＥＣＵ１〜ｍの動作干渉の防止が図り得るかについて、図７に示した例を参照しつつ説明する。なお、図７には、ツール１〜３が、同じＥＣＵ１〜ｍと同時期に（通信期間が重複するように）通信を行う例が示されている。

時刻Ｔ１において、ツール1から異常データ取得要求メッセージを受信すると、ＤｏＩＰゲートウェイ１０１は、その要求メッセージを送信したツール１の送信元情報と、要求メッセージの種別情報を記憶した上で、送信先ＥＣＵ（対象ＥＣＵ）１〜ｍに要求メッセージをゲートウェイする。同時に、ツール１に対応する通信状態カウンタに、経過時間のカウントを開始させる。

その後、時刻Ｔ２において、ツール２から異常データ取得要求メッセージを受信すると、ＤｏＩＰゲートウェイ１０１は、干渉定義情報テーブルを参照し、ツール２からの要求メッセージが、通信中のツール１からの要求メッセージに対し、送信先ＥＣＵ１〜ｍでの動作干渉を生じるものであるか否か、両要求メッセージの種別に基づいて判定する。この場合、両要求メッセージの種別は、ともに異常データ取得要求であり、送信先ＥＣＵ１〜ｍでの動作干渉を発生させるものではない。このため、ツール２の送信元情報と、要求メッセージの種別情報を記憶した上で、送信先ＥＣＵ（対象ＥＣＵ）１〜ｍに要求メッセージをゲートウェイする。同時に、ツール２に対応する通信状態カウンタにより、経過時間のカウントを開始させる。

そして、時刻Ｔ３において、ツール３からデータクリア要求メッセージを受信すると、ＤｏＩＰゲートウェイ１０１は、そのツール３からの要求メッセージが、ツール１及びツール２からの要求メッセージに対し、送信先ＥＣＵ１〜ｍでの動作干渉を生じるものであるか否かを判定する。干渉定義情報テーブルを参照すると、データクリア要求は、異常データ取得要求に対して、ＥＣＵ１〜ｍでの動作干渉を生じるものであることが分かる。そのため、ＤｏＩＰゲートウェイ１０１は、ツール３からの要求メッセージを送信先ＥＣＵ１〜ｍにゲートウェイせず、ツール３に対して、要求メッセージの受信を否認する旨の否定応答メッセージを送信する。

時刻Ｔ４において、再度、ツール１から異常データ取得要求メッセージを受信したとき、通信中のツール２からの異常データ要求メッセージとの間で、ＥＣＵ１〜ｍでの動作干渉は生じないため、ＤｏＩＰゲートウェイ１０１は、通信状態情報の要求メッセージの種別情報を更新した上で、その要求メッセージをＥＣＵ１〜ｍにゲートウェイする。さらに、通信状態情報の通信状態カウンタをリセットして、新たに経過時間のカウントを開始させる。

時刻Ｔ５において、ツール２から内部データ取得要求メッセージを受信すると、通信中のツール１からの異常データ取得要求メッセージとの間で、ＥＣＵ１〜ｍでの動作干渉は生じないため、ＤｏＩＰゲートウェイ１０１は、通信状態情報の要求メッセージの種別情報を更新（異常データ取得要求→ＥＣＵ内部データ取得要求）した上で、その要求メッセージを送信先ＥＣＵ１〜ｍにゲートウェイする。さらに、通信状態情報の通信状態カウンタをリセットして、新たに経過時間のカウントを開始させる。

そして、時刻Ｔ６において、ツール１に対応する通信状態カウンタがカウントする経過時間が所定時間に達したことに応じて、通信状態情報から、ツール１の送信元情報、及び要求メッセージの種別情報を消去する。さらにツール１に対応する通信状態カウンタがカウントした経過時間も消去するとともに、その通信状態カウンタのカウント動作を停止させる。

時刻Ｔ７において、ツール３からデータクリア要求メッセージを受信すると、その際に、通信中なのはツール２のみである。そのため、ＤｏＩＰゲートウェイ１０１は、ツール３からの要求メッセージが、ツール２からの要求メッセージとの間で、ＥＣＵ１〜ｍでの動作干渉を生じるものであるか否かを判定する。干渉定義情報テーブルを参照すると、データクリア要求は、内部データ取得要求に対して、ＥＣＵ１〜ｍでの動作干渉を生じるものではないので、ＤｏＩＰゲートウェイ１０１は、ツール３の送信元情報及び要求メッセージの種別情報を記憶した上で、ツール３からの要求メッセージを送信先ＥＣＵ１〜ｍにゲートウェイする。同時に、ツール３に対応する通信状態カウンタにより、経過時間のカウントを開始させる。

このように、本実施形態によるＤｏＩＰゲートウェイ１０１では、いずれかのツール１〜ｎから要求メッセージを受信し、それを送信先ＥＣＵ１〜ｍにゲートウェイして通信が開始されると、そのツール１〜ｎの送信元情報及び要求メッセージの種別情報を、その要求メッセージによる通信が終了するまで、通信状態情報として記憶している。このため、後に、別のツール１〜ｎから同じ送信先ＥＣＵ１〜ｍに向けられた要求メッセージを受信したときに、両要求メッセージにより送信先ＥＣＵ１〜ｍでの動作が干渉を生じるか否かを判定することが可能となる。そして、ＤｏＩＰゲートウェイ１０１は、送信先ＥＣＵ１〜ｍにおいて動作干渉が生じないと判定した場合にのみ、その別のツール１〜ｎからの要求メッセージを送信先ＥＣＵ１〜ｍにゲートウェイするので、送信先ＥＣＵ１〜ｍでの動作干渉を回避することが可能となる。さらに、例えば、送信先ＥＣＵ１〜ｍがあるツール１〜ｎと通信中である場合には、別のツール１〜ｎとの通信を一律に禁止する場合に比較して、送信先ＥＣＵ１〜ｍでの動作干渉が生じない限り、別のツールからの要求メッセージを送信先ＥＣＵ１〜ｍに転送するので、複数のツール１〜ｎとの通信を効率的に行なわせることが可能となる。

（第２実施形態）
次に、本発明の第２実施形態による車両用通信制御装置について、図面を参照しつつ説明する。なお、第２実施形態による車両用通信制御装置も、ＤｏＩＰゲートウェイとして実現され、そのＤｏＩＰゲートウェイが適用されるシステムの構成は、第１実施形態と同様である。また、ＤｏＩＰゲートウェイ１０１自体の機能構成も、第１実施例とほぼ共通しているので、説明を省略する。

第１実施形態では、後に受信した要求メッセージが、先に受信して通信が開始されている要求メッセージに対し、ＥＣＵ１〜ｍでの動作干渉が生じると判定された場合、後の要求メッセージの受信を否認し、否定応答メッセージを送信するものであった。

それに対して、第２実施形態では、動作干渉が生じると判定された場合に、後に受信した要求メッセージを、ＤｏＩＰゲートウェイ１０１が一時的に保存しておき、動作干渉を生じる要求メッセージの通信がすべて終了した後に、その一時的に保存している要求メッセージを送信先ＥＣＵ１〜ｍにゲートウェイするメッセージ保留機能を備えることを特徴としている。このようなメッセージ保留機能を備えることにより、送信先ＥＣＵ１〜ｍでの動作干渉が生じない状態となったとき、自動的に要求メッセージを送信先ＥＣＵ１〜ｍに転送することができる。従って、再度、ツール１〜ｎから同じ要求メッセージを送信するための手間を省くことができる。

図８は、本実施形態によるメッセージ保留機能を実現するために必要な、通信状態情報の構成の一例を示す図である。図８に示す通信状態情報は、図４に示す通信状態情報に対して、送信元である各ツール１〜ｎごとに、「干渉状態」を示す属性が追加されている。

後に受信した要求メッセージが、先に受信して通信が開始されている要求メッセージに対して、送信先ＥＣＵ１〜ｍでの動作干渉が生じないと判定された場合には、その「干渉状態」には何も設定されない。この場合、第１実施形態の場合と同様に、通信状態情報には、後に受信した要求メッセージに関する送信元情報及び要求メッセージの種別情報が記憶されるとともに、通信状態カウンタによる経時時間のカウントが開始される。

一方、送信先ＥＣＵ１〜ｍでの動作干渉が生じると判定された場合には、通信状態情報に、要求メッセージに関する送信元情報及び種別情報を記憶するが、「干渉状態」に保留状態を設定する。この際、要求メッセージは、送信先ＥＣＵ１〜ｍにゲートウェイされず、ＤｏＩＰゲートウェイ１０１にて一時的に保存される。そのため、通信状態カウンタによる経過時間のカウントは開始されない。

図８に示すような構成の通信状態情報を用いて、メッセージ保留機能がいかにして実現されるかについて、図９のフローチャートに基づいて説明する。なお、図９のフローチャートは、本実施形態における、ツール１〜ｎからの要求メッセージを受信したときに実行される干渉判定処理を示している。

図９のフローチャートのステップＳ９０１〜Ｓ９０５までの処理は、図５のフローチャートのステップＳ５０１〜Ｓ５０５の処理と同様である。

しかし、図９のフローチャートでは、ステップＳ９０５において、送信先ＥＣＵ１〜ｍにて動作干渉が生じると判定された場合、ステップＳ９０６の処理に進んで、後に受信された要求メッセージに関して、干渉情報設定処理を実行してから、ステップＳ９１４の処理に進み、要求メッセージの受信を承認する旨の肯定応答メッセージを送信する。なお、図９のフローチャートにおけるその他のステップの処理も、図５のフローチャートの処理と同様であるため、説明を省略する。

図１０は、図９のフローチャートのステップＳ９０６における干渉情報設定処理の詳細を示すフローチャートである。

まず、ステップＳ１００１では、図９のフローチャートのステップＳ９０５において、送信先ＥＣＵ１〜ｍでの動作干渉が生じるとの判定の根拠となった、通信状態情報に登録済みの要求メッセージを対象とし、その干渉情報を参照して、その要求メッセージの送信が保留状態であるか否かを判定する。動作干渉が生じるとの判定の根拠となった要求メッセージが送信保留中であれば、その要求メッセージによる通信は行われていないので、今回、受信した要求メッセージを送信先ＥＣＵ１〜ｍにゲートウェイしても、実際に動作干渉が生じることはない。そのため、ステップＳ１００１において、要求メッセージの送信が保留状態にあると判定されると、ステップＳ１００２にて、図９のフローチャートのステップＳ９０３からの処理を引き続き実施するようにする。一方、ステップＳ１００１において、要求メッセージの送信が保留されておらず、通信中であると判定されると、ステップＳ１００３の処理に進む。

ステップＳ１００３では、受信した要求メッセージに関する送信元情報が、通信状態情報に登録済みであるか否かを判定する。すなわち、受信した要求メッセージが、通信状態情報に送信元情報が記憶されていない、新規のツール１〜ｎから送信されたものであるか否かを判定する。このＳ１００３において、送信元情報が、通信状態情報に登録されていないと判定されると、ステップＳ１００４の処理に進み、送信元情報と要求メッセージの種別情報を通信状態情報に新たに追加記憶する。一方、受信した要求メッセージに関する送信元情報が登録済みであると判定されると、ステップＳ１００５の処理に進む。

ステップＳ１００５では、通信状態情報におけるメッセージ種別情報を、今回受信した要求メッセージの種別に更新する。そして、ステップＳ１００６において、対応する通信状態カウンタをクリアするとともに、そのカウント動作を停止したままとする。

ステップＳ１００７では、受信した要求メッセージを、ＤｏＩＰゲートウェイ１０１内のメモリに一時的に保存しておく。そして、ステップＳ１００８では、通信状態情報の干渉状態に、保留状態を設定する。

このようにして、送信先ＥＣＵ１〜ｍにて動作干渉が生じると判定された要求メッセージに関して、通信状態情報に、送信元情報、要求メッセージの種別情報、さらには、干渉情報が記録されるのである。

次に、本実施形態における、通信状態情報の更新処理について、図１１のフローチャートに基づいて説明する。なお、図１１のフローチャートのステップＳ１１０１〜Ｓ１１０７までの処理は、図６のフローチャートのステップＳ６０１〜Ｓ６０７までの処理と同様であるため、説明を省略する。

図１１のフローチャートでは、ステップＳ１１０２からステップＳ１１０６に移行するまでの間に、ステップＳ１１０８〜Ｓ１１１２の処理が挿入されている点が、図６のフローチャートと異なっている。この挿入されたステップＳ１１０８〜Ｓ１１１２の処理は、送信が保留されている要求メッセージに関して、動作干渉が生じるとの判定の根拠となった要求メッセージによる通信が終了したときに、その保留中の要求メッセージを送信先ＥＣＵ１〜ｍにゲートウェイさせるためのものである。

ここで、ステップＳ１１０８〜Ｓ１１１２の処理は、ステップＳ１１０２において、処理対象となっている１つのＥＣＵ１〜ｍの通信状態情報に含まれる、すべての通信状態カウンタの判定が完了したと判定されたときに実行される。このタイミングでは、各々のツール１〜ｎに関して、通信状態カウンタによる経過時間に基づき、まだ通信中であるか、通信が終了したかの判定が完了している。従って、動作干渉が発生するとの判定根拠となった要求メッセージによる通信が終了したと判定された場合に、送信を保留している要求メッセージの転送を即座に実施することが可能となる。

ステップＳ１１０８では、処理対象となっているＥＣＵ１〜ｍの通信状態情報における干渉状態を参照して、送信が保留されている要求メッセージがあるか否かを判定する。そのような要求メッセージがない場合には、ステップＳ１１０９〜Ｓ１１１２の処理をスキップして、直接、ステップＳ１１０６の処理に移行する。一方、送信が保留されている要求メッセージがある場合には、ステップＳ１１０９の処理に進む。ステップＳ１１０９では、通信状態情報を参照し、送信を保留している要求メッセージと動作干渉を引き起こす要求メッセージが通信を終了して、もはや動作干渉を生じる虞がなくなったか否かを判定する。この判定処理において、動作干渉を生じる虞があると判定されると、ステップＳ１１０８の処理に戻り、他に送信が保留中の要求メッセージがあるか否かが判定され、一方、動作干渉を生じる虞はないと判定されると、ステップＳ１１１０の処理に進む。

ステップＳ１１１０では、送信が保留されている要求メッセージに対応する通信状態カウンタをリセットするとともに、通信状態カウンタによるカウンタ動作を開始させる。続くステップＳ１１１１において、通信状態情報の干渉状態に設定されている保留状態をクリアする。そして、ステップＳ１１１２において、送信が保留されていた要求メッセージを送信先ＥＣＵ１〜ｍにゲートウェイさせる。

なお、一つのＥＣＵ１〜ｍに同時に複数のメッセージを送信できないため、送信が保留されていた一つのメッセージの転送を完了した後は、さらに当該ＥＣＵ１〜ｍに対する要求メッセージの送信保留状態判定を行なうことなく、ステップＳ１１０６の処理に移行する。

以上、本発明の好ましい実施形態について説明したが、本発明は上述した実施形態になんら制限されることなく、本発明の主旨を逸脱しない範囲において、種々変形して実施することができる。

例えば、上述した各実施形態では、通信状態カウンタが、ツール１〜ｎからＥＣＵ１〜ｍに要求メッセージが転送されてからの経過時間をカウントし、その経過時間が所定時間に達したときに、要求メッセージに起因する通信が終了したものとみなすようにしていた。

しかしながら、ＤｏＩＰゲートウェイ１０１に、ＥＣＵ１〜ｍからツール１〜ｎに向けて送信される応答メッセージの解読機能を持たせ、ツール１〜ｎからの要求メッセージに対して、ＥＣＵ１〜ｍから、その要求メッセージに応答する旨の肯定応答メッセージがＤｏＩＰゲートウェイ１０１にて受信され、その肯定応答メッセージをツール１〜ｎに転送したとき、通信状態カウンタに、その転送した時点からの経過時間をカウントさせるようにしても良い。この場合も、当該ツール１〜ｎから新たなメッセージを受信することなく、通信状態カウンタによりカウントされる経過時間が所定時間に達したときに、要求メッセージに起因する通信が終了したとみなすことができる。

また、ＥＣＵ１〜ｍからの応答メッセージの内容が、ツール１〜ｎからの要求メッセージに対する否定応答であった場合に、ＤｏＩＰゲートウェイ１０１は、通信状態情報における、その要求メッセージを送信したツール１〜ｎに関する送信元情報及び要求メッセージの種別情報を消去するとともに、通信状態カウンタによるカウント処理を停止させるようにしても良い。

ＤｏＩＰゲートウェイ１０１は、ツール１〜ｎからの要求メッセージをＥＣＵ１〜ｍに転送した時点で、そのツール１〜ｎを示す送信元情報、転送したメッセージの種別情報を記憶しており、さらに、通信状態カウンタにカウント動作を開始させている。しかし、上述したように、要求メッセージを受け取ったＥＣＵ１〜ｍから否定応答メッセージが送信された場合、その時点で、ツール１〜ｎとＥＣＵ１〜ｍ間の通信は終了する。そのため、ＥＣＵ１〜ｍからの応答メッセージの内容が否定応答を示すものであった場合には、通信終了とみなして、ＤｏＩＰゲートウェイが、上述したような処理を行うことが好ましい。これにより、通信状態情報として正しい情報のみが記憶されるようになり、その後の要求メッセージの受信に影響を及ぼさないようにすることができる。

なお、ＥＣＵ１〜ｍは、自身がサポートしていない種別の要求メッセージを受信したとき、要求メッセージの内容に誤り等があり、その内容を認識できないとき、ツール１〜ｎが上述したセッション移行を行うことなく、制限範囲外の要求メッセージを送信してきたときなど、要求メッセージに応答しない旨を否定応答メッセージによりツール１〜ｎに伝える。

１０１…ＤｏＩＰゲートウェイ（通信制御装置）
２０１…イーサネット通信部
２０２…ローカルネットワーク通信部
２０３，２０４…バッファ
２０５…ゲートウェイ処理部
２１２…干渉判定部
２１３…干渉定義情報記憶部
２１４…通信状態管理部

Claims (9)

1. インターネットプロトコル（ＩＰ）ベースのネットワークに接続された外部ツールと、車内のローカルエリアネットワーク（ＬＡＮ）に接続された車載ＥＣＵとの間でメッセージの送受信を行うことを可能とすべく、両ネットワーク間に介在して前記メッセージの中継を行う車両用通信制御装置であって、
   前記外部ツールからメッセージを受信したとき、そのメッセージを受信すべき車載ＥＣＵに向けて、当該メッセージを転送する転送手段と、
   前記転送手段が、前記外部ツールとして、第１の外部ツールからのメッセージを前記車載ＥＣＵに転送したとき、前記第１の外部ツールからのメッセージに起因する前記車載ＥＣＵとの通信が終了するまで、前記メッセージの種別を記憶しておく記憶手段と、
   前記第１の外部ツールと通信中の車載ＥＣＵに対して、前記第１の外部ツールとは異なる第２の外部ツールからのメッセージを受信したとき、その受信したメッセージの種別と、前記記憶手段に記憶しているメッセージの種別とに基づいて、それぞれのメッセージにより前記車載ＥＣＵにおける動作が干渉を生じるか否かを判定する干渉判定手段と、を備え、
   前記転送手段は、前記干渉判定手段によって干渉が生じないと判定された場合に、前記第２の外部ツールからのメッセージを前記車載ＥＣＵに転送することを特徴とする車両用通信制御装置。
2. 前記干渉判定手段によって干渉が生じると判定されたとき、前記第２の外部ツールに向けて、前記メッセージの受信を否認する旨の応答メッセージを送信する否認応答手段を備えることを特徴とする請求項１に記載の車両用通信制御装置。
3. 前記干渉判定手段によって干渉が生じると判定されたとき、前記第２の外部ツールからのメッセージを保存する保存手段を備え、
   前記保存手段に保存されたメッセージに対して、前記車載ＥＣＵにおける動作が干渉を生じる、前記第１の外部ツールからのメッセージに起因する通信が終了し、前記干渉判定手段における判定結果が干渉を生じないとの判定結果に変化したとき、前記転送手段は、前記保存手段に保存されたメッセージを前記車載ＥＣＵに転送することを特徴とする請求項１に記載の車両用通信制御装置。
4. 前記車載ＥＣＵが前記第１の外部ツールと通信中であって、前記第２の外部ツールからのメッセージが前記保存手段に保存されている状態において、前記第１及び第２の外部ツールとは異なる第３の外部ツールから前記車載ＥＣＵへのメッセージを受信したとき、前記第３の外部ツールからのメッセージと、前記車載ＥＣＵと通信中の前記第１の外部ツールからのメッセージとは、前記車載ＥＣＵにおける動作が干渉を生じるものではないと前記干渉判定手段によって判定されたならば、前記第３の外部ツールからのメッセージと、前記保存手段に保存されている、前記第２の外部ツールからのメッセージとが、前記車載ＥＣＵにおける動作が干渉を生じるものであっても、前記転送手段は、前記第３の外部ツールからのメッセージを前記車載ＥＣＵに転送することを特徴とする請求項３に記載の車両用通信制御装置。
5. 前記記憶手段は、前記第１の外部ツールからのメッセージを前記車載ＥＣＵに転送してから、前記第１の外部ツールから新たなメッセージを受信することなく、所定時間経過すると、当該メッセージに起因する通信が終了したとみなして、記憶しているメッセージの種別を消去することを特徴とする請求項１乃至４のいずれかに記載の車両用通信制御装置。
6. 前記転送手段は、前記車載ＥＣＵへ転送された前記第１の外部ツールからのメッセージに対する、当該車載ＥＣＵからの応答メッセージが受信されたとき、その応答メッセージを前記第１の外部ツールへ転送するものであり、
   前記車載ＥＣＵからの応答メッセージの内容を解読する解読手段を備え、
   前記応答メッセージの内容が、前記第１外部ツールからのメッセージに応答しない旨を示す否定応答であった場合、前記記憶手段は、記憶しているメッセージの種別を消去することを特徴とする請求項５に記載の車両用通信制御装置。
7. 前記転送手段は、前記車載ＥＣＵへ転送された前記第１の外部ツールからのメッセージに対する、当該車載ＥＣＵからの応答メッセージが受信されたとき、その応答メッセージを前記第１の外部ツールへ転送するものであり、
   前記車載ＥＣＵからの応答メッセージの内容を解読する解読手段を備え、
   前記応答メッセージの内容が、前記第１外部ツールからのメッセージに応答する旨を示す肯定応答であった場合、前記転送手段による応答メッセージの転送から、前記第１の外部ツールから新たなメッセージを受信することなく、所定時間経過すると、前記記憶手段は、当該メッセージに起因する通信が終了したとみなして、記憶しているメッセージの種別を消去することを特徴とする請求項１乃至４のいずれかに記載の車両用通信制御装置。
8. 前記記憶手段は、記憶しているメッセージの種別とは異なる種別のメッセージを前記第１の外部ツールから受信したとき、種別を記憶しているメッセージに起因する通信は終了したとみなして、その記憶しているメッセージの種別に代えて、新たに受信したメッセージの種別を記憶することを特徴とする請求項１乃至７のいずれかに記載の車両用通信制御装置。
9. 前記車載ＥＣＵにおける動作が干渉を生じるメッセージの種別の組み合わせは、予め定義され、その定義情報を記憶した定義情報記憶手段を備え、
   前記干渉判定手段は、前記定義情報を参照して、前記車載ＥＣＵにおける動作が干渉を生じるものであるか否かを判定することを特徴とする請求項１乃至８のいずれかに記載の車両用通信制御装置。

Images