JP2008078769A - 通信システム - Google Patents

Abstract

【課題】受信待ちのタイムアウト時間に関して、適切な時間を設定できるようにする。
【解決手段】複数のＥＣＵが車内ＬＡＮに接続されてなる本発明の通信システムでは、遠隔操作受付ＥＣＵが、照合ＥＣＵやボデーＥＣＵ等のスレーブＥＣＵと通信し、ドアのロック／アンロック等の遠隔操作に係る処理を、他のＥＣＵと協働して実現する。スレーブＥＣＵは、遠隔操作受付ＥＣＵから要求データを受信すると、要求データにて要求された処理（ドアのロック／アンロック処理等）が完了するまでの最大実行時間を表す情報を格納した受付応答データを、処理の実行結果を表す完了応答データを送信する前に、要求元ＥＣＵに送信する。一方、遠隔操作受付ＥＣＵは、受付応答データを受信すると、このデータが示す最大実行時間の情報に基づき、要求した処理の最大実行時間に対応する時間を、完了応答データに関する受信待ち動作のタイムアウト時間に設定する（Ｓ２５０）。
【選択図】図５

Description

本発明は、ネットワークに、複数の電子制御装置が接続された通信システムであって、これら複数の電子制御装置の内、少なくとも一つの電子制御装置が、ネットワーク内の他の電子制御装置と通信し、この電子制御装置と協働して、一連の処理を実現する通信システムに関する。

従来、通信システムとしては、複数の電子制御装置をネットワークに接続してなるシステムであって、複数の電子制御装置を連携動作させ、車両制御を実現するようにした車内ＬＡＮシステムが知られている。

この種の通信システムにおいては、要求信号を受信したノードが、要求信号を送信してきたノードに対し、要求信号に対する応答信号を送信することにより、各ノード間で情報交換が行われ、一連の処理が実現される。

また、この種の通信システムにおいては、応答信号が要求信号送信元のノードに届かなかった時のために、要求信号送信元のノードにて、応答信号の受信待ち動作についてのタイムアウト処理を行うのが一般的である。

この他、タイムアウト時間の設定方法としては、ネットワークトラフィックや、要求信号受信側ノードの処理負荷に応じて、適切なタイムアウト時間を設定するために、前回の要求信号の送信時に、応答信号の受信に成功したか否かを記録しておき、次回の要求信号の送信時には、前回、応答信号の受信に成功したか否かにより、タイムアウト時間を変更する方法が知られている（例えば、特許文献１参照）。

受信待ち動作に関してタイムアウト時間を設定する場合には、タイムアウト時間を冗長に設定すると、タイムアウト時間が経過するまでエラー処理を実行することができないため、応答信号の受信に失敗した際、これらの処理を迅速に実行することができなくなる。一方、タイムアウト時間を短く設定しすぎると、タイムアウト時間が経過するまでに、応答信号の受信が間に合わず、要求信号送信元のノードにて、無駄なエラー処理が頻繁に実行されてしまう。上述の設定方法は、この種の問題を解消するためのものである。
特開２００２−２６９０８号公報

ところで、自動車分野では、車両制御にかかる機能を細分化して、細分化した各機能を個別の電子制御装置にて実現するようにし、汎用的な機能を実現する電子制御装置については、電子制御装置を、車種に拠らず共通化することが行われている。

しかしながら、このようにして電子制御装置を共通化し、電子制御装置の組み合わせを車種に応じて変更して、車内ＬＡＮシステムを構成する場合には、要求信号送信元の電子制御装置が同一の電子制御装置でも、要求信号受信側の電子制御装置が同一でない車内ＬＡＮシステムが構築される。

従って、要求信号送信元の電子制御装置を、車種に拠らず共通化する場合には、この電子制御装置と組み合わせられる電子制御装置の内、応答信号の送信に最も時間を要する電子制御装置に合わせて、受信待ち動作のタイムアウト時間を設定する必要がある。このため、要求信号送信元の電子制御装置を、車種に拠らず共通化する場合には、タイムアウト時間が長くなりがちで、エラー処理を迅速に実行することができないといった問題があった。

また、要求信号受信側の電子制御装置を、複数種類の要求信号を受付可能な構成にし、この電子制御装置に複数種類の処理を実行させる場合には、処理毎に、処理が完了するまでの時間が異なるため、要求信号を送信しても、その要求信号の応答信号として、要求信号受信側の電子制御装置から、処理の実行結果を表す応答信号が送信されてくるまでの時間が、処理毎に大きく異なり、要求信号送信元の電子制御装置に、タイムアウト時間として適切な時間を設定するのが難しいといった問題があった。

即ち、処理が完了するまでの時間が最も長い処理に合わせて、タイムアウト時間を設定すると、エラー処理を迅速に実行することができないといった問題があった。
本発明は、こうした問題に鑑みなされたものであり、要求信号受信側の電子制御装置の処理動作に合わせて、受信待ち動作のタイムアウト時間に関し、適切な時間を設定することが可能な通信システムを提供することを目的とする。

かかる目的を達成するためになされた請求項１記載の通信システムは、ネットワークに、複数の電子制御装置が接続され、これらの電子制御装置の内、少なくとも一つの電子制御装置Ａが、ネットワーク内の他の電子制御装置Ｂと通信し、この電子制御装置Ｂと協働して、一連の処理を実現するものである。

この通信システムにおいて、電子制御装置Ｂは、電子制御装置Ａから、処理の実行を要求する要求信号を受信すると、受付応答手段により、要求信号にて要求された処理が完了するまでの所要時間を表す情報、を格納した応答信号であって、要求が受け付けられたことを示す受付応答信号を、要求信号の送信元装置に送信する。

また、要求信号を受信すると、処理実行手段にて、要求信号にて要求された処理を実行し、この処理が完了すると、完了応答手段にて、要求信号に対応する処理が完了したことを示す応答信号であって、処理の実行結果を表す情報を格納した完了応答信号を、要求信号の送信元装置に送信する。

一方、電子制御装置Ａは、イベントの発生に応じ、要求手段にて、発生したイベントに対応した処理の実行を要求する要求信号を、その処理を実行可能な電子制御装置Ｂに送信し、受信処理手段にて、この要求信号に対応する完了応答信号を、電子制御装置Ｂから受信し、この完了応答信号に基づき、イベントに対応する処理を実行する。また、完了応答信号の受信に際しては、電子制御装置Ｂから受信した受付応答信号に格納された所要時間を表す情報に基づき、タイムアウト時間設定手段にて、受信処理手段に対し、対応する完了応答信号の受信待ち動作についてのタイムアウト時間を設定する。

即ち、この通信システムでは、要求信号送信元の電子制御装置Ａが、要求信号受信側の電子制御装置Ｂから、要求に対応した処理の実行に要する時間の予測値を取得し、この時間に基づいて、受信待ち動作についてのタイムアウト時間を設定する。

従って、この通信システムによれば、要求信号送信先の電子制御装置Ｂの種類に拘わらず、要求信号送信先の電子制御装置Ｂの処理動作（処理内容）に合わせて、適切にタイムアウト時間を設定することができる。また、この通信システムによれば、要求信号送信先の電子制御装置Ｂが実行する処理毎に、個別に適切なタイムアウト時間を設定することができる。結果、この通信システムによれば、処理の実行結果を電子制御装置Ｂから取得することができない場合に、電子制御装置Ａにて、エラー処理を迅速に実行することができる。また、タイムアウト時間が短すぎることにより、電子制御装置Ａにて、無駄なエラー処理が頻繁に行われてしまうのを防止することができる。

尚、要求信号送信元の電子制御装置Ａは、タイムアウト時間設定手段により設定されたタイムアウト時間が経過するまでの期間に、要求信号に対応する完了応答信号を受信することができなかった場合、各種のエラー処理を実行する構成にすることができる。具体的に、エラー処理としては、完了応答信号の取得を再試行する手順を含むリトライ処理を挙げることができる（請求項２）。

タイムアウト時間設定手段により設定されたタイムアウト時間が経過するまでの期間に、要求信号に対応する完了応答信号を受信することができなかった場合、完了応答信号の取得を再試行する手順を含むリトライ処理を実行するように、受信処理手段を構成すれば、要求信号送信元の電子制御装置では、ノイズ等の影響を受けて、要求信号送信先の電子制御装置から応答信号を受信することができなかった場合、迅速に、完了応答信号の取得を再試行することができる。

具体的に、リトライ処理として、受信処理手段は、タイムアウト時間設定手段により設定されたタイムアウト時間が経過するまでの期間に、要求信号に対応する完了応答信号を受信することができなかった場合、完了応答信号に対応する要求信号を送信した送信先の電子制御装置Ｂに、この要求信号に対応する再要求信号を、送信する構成にされるとよい。また、これに対応して、電子制御装置Ｂは、電子制御装置Ａから、再要求信号を受信すると、処理実行手段が上記再要求信号に対応する要求信号の受信の際に実行を開始した処理、の実行結果を表す情報を格納した完了応答信号を、リトライ応答手段にて、再要求信号の送信元装置に、送信する構成にされるとよい（請求項３）。

この他、再要求時には、上記所要時間を表す情報を格納した受付応答信号を電子制御装置Ａ−Ｂ間で授受することなく、完了応答信号のみを授受するようにしてもよいが、要求信号に対応する処理が未完了の場合には、再度、受付応答信号を送信するように、電子制御装置Ｂを構成すると、好ましい。

即ち、リトライ応答手段は、再要求信号を受信した時点で、この再要求信号に対応する要求信号の受信の際に処理実行手段が実行を開始した処理が処理実行手段にて完了していない場合、完了応答信号の送信に先駆けて、要求信号に対応する処理が完了するまでの所要時間を表す情報、を格納した受付応答信号を、再要求信号の送信元装置に送信する構成にされるとよい（請求項４）。

初回の要求信号の受信時に、要求信号送信元の電子制御装置Ａに通知する所要時間は、予測値であるため、要求信号受信側の電子制御装置Ｂにて、処理の実行が捗らない場合には、要求信号送信元の電子制御装置Ａに通知した所要時間を越えて、要求信号に対応した処理が電子制御装置Ｂで実行されることになる。

この際、再要求信号送信元の電子制御装置Ａに、処理の完了までに要する所要時間を、受付応答信号により再度通知すれば、電子制御装置Ａでは、リトライ処理時においても、タイムアウト時間設定手段により、完了応答信号の受信待ち動作に対して、適切なタイムアウト時間を設定することができる。従って、このように通信システムを構成すれば、リトライ処理によっても完了応答信号を受信することができない場合に、再度、迅速にエラー処理（リトライ処理）を実行することができる。

また、タイムアウト時間設定手段は、要求手段による要求信号の送信後、送信先の電子制御装置Ｂから受付応答信号を受信することができない場合、デフォルトのタイムアウト時間を、受信処理手段に対し設定する構成にされてもよいが、受付応答信号を受信することができなかった場合には、要求信号そのものが、要求信号送信先の電子制御装置Ｂにて受信されていない可能性があるので、タイムアウト時間設定手段は、次のように構成されるのが好ましい。

即ち、タイムアウト時間設定手段は、要求手段による要求信号の送信後、所定時間内に、送信先の電子制御装置Ｂから受付応答信号を受信することができなかった場合、その時点で（上記所定時間が経過した時点で）、受信処理手段に、リトライ処理を開始させる構成にされるとよい（請求項５）。このように、電子制御装置Ａを構成すれば、迅速に、要求信号に対応する処理の実行結果を、電子制御装置Ｂから取得することができて、以後の処理を迅速に行うことができる。

また、電子制御装置Ｂが、再要求信号に対応する処理が処理実行手段にて完了していない場合、上記処理が完了するまでの所要時間を表す情報を格納した受付応答信号を、再要求信号の送信元装置に送信する構成にされている場合には、タイムアウト時間設定手段を、次のように構成するとよい。

即ち、タイムアウト時間設定手段は、受信処理手段による再要求信号の送信後、完了応答信号の受信が成功していない状態で、所定時間内に、送信先の電子制御装置Ｂから受付応答信号を受信することができなかった場合、上記所定時間が経過した時点で、受信処理手段に、再度、リトライ処理を実行させる構成にされるとよい。

電子制御装置Ｂにて再要求信号に対応する処理が完了している場合には、再要求信号に対応する処理が完了していない場合に受付応答信号が送信されてくる時期と、同時期に、電子制御装置Ｂから完了応答信号が送信されてくるので、受付応答信号の受信待ち動作を適当な時間行っても、受付応答信号又は完了応答信号を受信することができなかった場合には、再要求信号が電子制御装置Ｂで受け付けられていない可能性が高い。

従って、本発明のようにタイムアウト時間設定手段を構成すれば、再要求信号が電子制御装置Ｂで受け付けられていない場合に、再度、迅速に、リトライ処理を実行することができる。よって、本発明によれば、電子制御装置Ａ−Ｂ間の通信が、ノイズ等で妨害される場合であっても、リトライ処理を効率的に行って、迅速に、要求した処理の実行結果を、電子制御装置Ｂから取得することができる。

以下、本発明の実施例について、図面と共に説明する。図１は、本発明が適用された通信システム１の構成を表すブロック図である。
図１に示すように、本実施例の通信システム１は、ネットワークＮＴ（車内ＬＡＮ）に、複数の電子制御装置（以下、「ＥＣＵ」ともいう。）が接続されてなる。

具体的に、この通信システム１は、遠隔操作受付用の電子制御装置（以下、「遠隔操作受付ＥＣＵ」という。）１０と、ユーザ認証に係る照合機能を有した電子制御装置（以下、「照合ＥＣＵ」という。）２０と、車両ドアのロック／アンロック制御や、パワーウィンドウの制御、ハザードを含むライトのオン／オフ制御を行うボデー制御用の電子制御装置（以下、「ボデーＥＣＵ」という。）３０と、がネットワークＮＴに接続されてなる。

遠隔操作受付ＥＣＵ１０には、ユーザが携帯するユーザ端末４０と無線通信可能な無線通信装置１５が接続されており、遠隔操作受付ＥＣＵ１０は、無線通信装置１５を介して、ユーザ端末４０から、ボデー系（ドア系、ライト系、パワーウィンドウ系等）に対する遠隔操作信号を受信すると、遠隔操作信号に含まれる送信元ユーザ端末４０の端末ＩＤを、照合ＥＣＵ２０に送信して、照合ＥＣＵ２０に、この端末ＩＤを、正当なユーザ端末の端末ＩＤと照合させ、両端末ＩＤが一致するか否かを判断させる。

また、遠隔操作受付ＥＣＵ１０は、この照合結果に基づいて、遠隔操作信号の送信元ユーザ端末４０が正当なユーザ端末であると認められると、受信した遠隔操作信号に対応する処理を実現するために、ボデーＥＣＵ３０に対し、遠隔操作信号に対応する処理の実行を要求する要求データを、ネットワークＮＴを介して送信し、ボデーＥＣＵ３０に、遠隔操作信号に対応する処理を実行させる。そして、この処理結果を、無線通信装置１５を介して、ユーザ端末４０に送信する。

尚、ボデーＥＣＵ３０には、車両ドアのロック／アンロック機構を備えたドア装置３１、車両窓の自動開閉機構を備えたパワーウィンドウ装置３３、及び、ライトの点灯装置３５が接続されており、ボデーＥＣＵ３０は、遠隔操作受付ＥＣＵ１０や、図示しない他のＥＣＵからの要求に従って、これらの装置３１，３３，３５を制御し、車両ドアをロック／アンロックしたり、窓を開閉したり、ライトをオン／オフ等する。

このようにして、本実施例の通信システム１では、遠隔操作受付ＥＣＵ１０が、ネットワークＮＴ内の照合ＥＣＵ２０及びボデーＥＣＵ３０と通信し、これらのＥＣＵ２０，３０と協働して、遠隔操作に係る一連の処理を実現する。

ところで、本実施例の通信システム１は、遠隔操作に係る一連の処理を複数のＥＣＵ１０，２０，３０により協働して実現する際に実行する通信処理、に特徴を有する。
図２は、本実施例の通信システム１で行われる通信処理の形態を示したラダーチャートであり、図３は、この通信の際に、送受信される要求データ、受付応答データ、完了応答データの構成を表す説明図である。具体的に、図３（ａ）は、要求データの構成を表す図であり、図３（ｂ）は、受付応答データの構成を表す図であり、図３（ｃ）は、完了応答データの構成を表す図である。

本実施例では、通信処理において、各種処理の実行を他ＥＣＵに要求する要求元ＥＣＵとしてのマスタＥＣＵ（具体的には、遠隔操作受付ＥＣＵ１０）が、要求先ＥＣＵとしてのスレーブＥＣＵ（具体的には、照合ＥＣＵ２０やボデーＥＣＵ３０）に対し、図３（ａ）に示す要求データを、ネットワークＮＴ経由で送信する。

本実施例において、マスタＥＣＵ−スレーブＥＣＵ間で送受信される通信データは、８バイトのデータであり、要求データは、その上位６バイトにおいて、サービス識別情報、データ識別情報、コマンド情報、指示対象情報、要求同期カウンタを有する。

サービス識別情報は、サービス（処理）の系統を表す情報であり、例えば、ボデーＥＣＵ３０に対し車両ドアに関連する処理の実行を要求する場合には、要求データにおいて、サービス識別情報として「ドア系」を表すコードが記述される。その他、窓の開閉に関連する処理の実行を要求する場合には、サービス識別情報として「パワーウィンドウ系」を表すコードが記述され、ライトに関連する処理の実行を要求する場合には、サービス識別情報として「ライト系」を表すコードが記述される。

また、照合ＥＣＵ２０に対し照合処理の実行を要求する場合には、要求データにおいて、サービス識別情報として「照合系」を表すコードが記述される。
また、データ識別情報は、当該通信データが、要求データ、受付応答データ、及び、完了応答データのいずれに該当するものであるのかを示す情報であり、要求データにおいては、データ識別情報として、当該通信データが要求データであることを示すコードが記述される。

その他、コマンド情報は、サービス（処理）の具体的な内容を示す情報であり、例えば、ボデーＥＣＵ３０に対し車両ドアのアンロック（解錠）処理の実行を要求する場合には、要求データにおいて、サービス識別情報として「ドア系」を表すコードが記述され、コマンド情報として「アンロック」を表すコードが記述される。一方、ボデーＥＣＵ３０に対し車両ドアのロック（施錠）処理の実行を要求する場合には、要求データにおいて、コマンド情報として「ロック」を表すコードが記述される（図８参照）。

また、ボデーＥＣＵ３０に対し窓の閉鎖処理の実行を要求する場合には、サービス識別情報として「パワーウィンドウ系」を表すコードが記述されると共に、コマンド情報として「全閉」を表すコードが記述される。その他、ボデーＥＣＵ３０に対し窓の開放処理の実行を要求する場合には、コマンド情報として「開放」を表すコードが記述される。

また、指示対象情報は、サービス（処理）を及ぼす対象を指示する情報であり、ボデーＥＣＵ３０に対し車両ドアのロック／アンロック処理の実行を要求する場合には、指示対象情報として、「車両ドア」を表すコードが記述され、ボデーＥＣＵ３０に対し窓の開閉処理の実行を要求する場合には、指示対象情報として、開閉する窓の位置を表すコードが記述される。

例えば、運転席（Ｄ席）側の窓について開閉処理の実行を要求する場合には、指示対象情報として、「Ｄ席」を表すコードが記述される。また、助手席（Ｐ席）側の窓について開閉処理の実行を要求する場合には、指示対象情報として、「Ｐ席」を表すコードが記述され、後部右側席（ＲＲ席）側の窓について開閉処理の実行を要求する場合には、指示対象情報として、「ＲＲ席」を表すコードが記述され、後部左側席（ＲＬ席）側の窓について開閉処理の実行を要求する場合には、指示対象情報として、「ＲＬ席」を表すコードが記述される（図８参照）。

この他、要求同期カウンタは、要求データの識別情報であり、要求データが生成される度に、その要求データに対しては、ユニークな値が要求同期カウンタとして記述される。尚、この要求同期カウンタは、受付応答データ及び完了応答データと、要求データとの対応関係を採るためのものであり、更には、要求データが再送されたものであるかを、スレーブＥＣＵに把握させるためのものである。即ち、本実施例において、再送される要求データには、要求同期カウンタとして、前回送信された要求データと同一の値が記述される。

このような構成の要求データを、マスタＥＣＵが、スレーブＥＣＵに送信すると、スレーブＥＣＵからマスタＥＣＵには、通常、図３（ｂ）に示す受付応答データが送信される。マスタＥＣＵは、この受付応答データを受信すると、受信した受付応答データに基づき、スレーブＥＣＵから引き続き送信される予定の完了応答データの受信待ち動作に関して、タイムアウト時間Ｔ１を設定する。

図３（ｂ）に示すように、受付応答データは、上述したサービス識別情報、データ識別情報、コマンド情報、指示対象情報、要求同期カウンタを有すると共に、最大実行時間情報を有する。

この受付応答データにおいては、データ識別情報として、当該通信データが受付応答データであることを示すコードが記述され、サービス識別情報、コマンド情報、指示対象情報、及び、要求同期カウンタとして、当該受付応答データに対応する要求データと同一の値が記述される。また、この受付応答データにおいては、最大実行時間情報として、サービス識別情報、コマンド情報、及び指示対象情報にて特定される処理に関して、その処理の実行に要する時間が記述される。

即ち、マスタＥＣＵは、受付応答データを受信すると、受信した受付応答データが有する最大実行時間情報に基づき、スレーブＥＣＵから送信される予定の完了応答データの受信待ち動作に関して、タイムアウト時間Ｔ１を設定する。

また、この処理を終えると、マスタＥＣＵは、タイムアウト時間Ｔ１が経過するか、図３（ｃ）に示す構成の完了応答データを、スレーブＥＣＵから受信するまで待機する。そして、完了応答データを受信すると、完了応答データが示す処理の実行結果に基づき、遠隔操作の実行結果を、遠隔操作元のユーザ端末４０に、無線通信装置１５を介して送信する。

尚、図３（ｃ）に示すように、完了応答データは、要求データ及び受付応答データと同様、サービス識別情報、データ識別情報、コマンド情報、指示対象情報、要求同期カウンタを有する他、実行成否情報及び補助情報を有する。

この完了応答データにおいては、データ識別情報として、当該通信データが完了応答データであることを示すコードが記述され、サービス識別情報、コマンド情報、指示対象情報、及び、要求同期カウンタとして、当該完了応答データに対応する要求データと同一の値が記述される。また、この完了応答データにおいては、実行成否情報として、要求データの送信によりスレーブＥＣＵにて実行された処理の実行結果であって、処理の成功を表す値、又は、処理の失敗を表す値が記述される。また、補助情報として、処理の実行結果に関する詳細な情報が記述される。

即ち、マスタＥＣＵは、完了応答データを受信すると、完了応答データが有する実行成否情報及び補助情報に基づき、遠隔操作の実行結果を、遠隔操作元のユーザ端末４０に、無線通信装置１５を介して送信する。

尚、完了応答データを、タイムアウト時間Ｔ１内に受信することができなかった場合の処理等、マスタＥＣＵ（遠隔操作受付ＥＣＵ１０）、及び、スレーブＥＣＵ（照合ＥＣＵ２０、ボデーＥＣＵ３０）が実行する処理の具体的な内容については、図４〜図１０を用いて、以下に詳細に説明する。

まず、遠隔操作受付ＥＣＵ１０が実行する遠隔操作受付処理について説明する。図４は、遠隔操作受付ＥＣＵ１０が繰返し実行する遠隔操作受付処理を表すフローチャートである。この遠隔操作受付処理は、遠隔操作受付ＥＣＵ１０が有するプログラムに基づき、遠隔操作受付ＥＣＵ１０内の図示しないマイクロコンピュータが実行する。

遠隔操作受付処理を開始すると、遠隔操作受付ＥＣＵ１０は、無線通信装置１５を介して外部のユーザ端末４０から、遠隔操作信号を受信するまで待機し（Ｓ１１０）、遠隔操作信号を受信すると（Ｓ１１０でＹｅｓ）、Ｓ１２０に移行する。

また、Ｓ１２０に移行すると、遠隔操作受付ＥＣＵ１０は、遠隔操作に係る要求データの送信先（即ち、要求先）として、照合ＥＣＵ２０を設定し、この要求先の照合ＥＣＵ２０に対して、遠隔操作信号送信元のユーザ端末４０の端末ＩＤを、正当なユーザ端末の端末ＩＤと照合するように要求する要求データを生成する（Ｓ１３０）。

具体的には、サービス識別情報として、「照合系」を表すコードを記述し、データ識別情報として、「要求データ」を表すコードを記述し、コマンド情報として、「照合」を表すコードを記述し、指示対象情報として、遠隔操作信号送信元ユーザ端末４０の端末ＩＤを記述した要求データを生成する。また、この際には、要求データに、要求同期カウンタとして、ユニークな値を記述する。

このようにして、要求データを生成すると、遠隔操作受付ＥＣＵ１０は、Ｓ１４０に移行し、図５に示す通信処理を実行することにより、生成した要求データを、要求先の照合ＥＣＵ２０に、ネットワークＮＴを介して送信し、照合ＥＣＵ２０に、遠隔操作信号送信元のユーザ端末４０の端末ＩＤを、正当なユーザ端末の端末ＩＤと照合させる。

また、Ｓ１４０での通信処理を終えると、遠隔操作受付ＥＣＵ１０は、その通信結果に基づき、遠隔操作信号送信元のユーザ端末４０が、正当なユーザ端末であるか否かを判断する（Ｓ１５０）。尚、Ｓ１４０の通信処理にて受信した完了応答データの実行成否情報が、「成功」を示す場合には、遠隔操作信号送信元ユーザ端末４０の端末ＩＤが、正当なユーザ端末の端末ＩＤと一致したことを意味するので、この場合には、遠隔操作信号送信元のユーザ端末４０が、正当なユーザ端末であると判断する。

一方、完了応答データの実行成否情報が「失敗」を示す場合や、完了応答データを照合ＥＣＵ２０から受信することができなかった場合には、遠隔操作信号送信元のユーザ端末４０が、正当なユーザ端末ではないと判断する。

Ｓ１５０で、遠隔操作信号送信元のユーザ端末４０が、正当なユーザ端末ではないと判断すると、遠隔操作受付ＥＣＵ１０は、認証に失敗した旨のエラー情報を、無線通信装置１５を介して、遠隔操作信号送信元のユーザ端末４０に送信し（Ｓ１５５）、当該遠隔操作受付処理を一旦終了する。その後、次の遠隔操作信号を受信するまで待機する（Ｓ１１０）。

この他、Ｓ１５０で、遠隔操作信号送信元のユーザ端末４０が、正当なユーザ端末であると判断すると、遠隔操作受付ＥＣＵ１０は、Ｓ１６０に移行し、遠隔操作に係る要求データの送信先（要求先）として、上記照合ＥＣＵ２０の代わりに、ボデーＥＣＵ３０を設定し、この要求先のボデーＥＣＵ３０に、遠隔操作信号に対応する処理（ボデー制御）の実行を要求するための要求データを生成する（Ｓ１７０）。

例えば、車両ドアのアンロック操作がユーザ端末４０でなされて、それに対応する遠隔操作信号をユーザ端末４０から受信した場合には、サービス識別情報として、「ドア系」を表すコードを記述し、データ識別情報として、「要求データ」を表すコードを記述し、コマンド情報として、「アンロック」を表すコードを記述し、指示対象情報として、「車両ドア」を表すコードを記述し、要求同期カウンタとして、ユニークな値を記述した要求データを生成する。

その他、運転席側の窓の開放操作がユーザ端末４０でなされて、それに対応する遠隔操作信号をユーザ端末４０から受信した場合には、サービス識別情報として、「パワーウィンドウ系」を表すコードを記述し、データ識別情報として、「要求データ」を表すコードを記述し、コマンド情報として、「開放」を表すコードを記述し、指示対象情報として、「Ｄ席」を表すコードを記述し、要求同期カウンタとして、ユニークな値を記述した要求データを生成する。

また、このようにして要求データを生成すると、遠隔操作受付ＥＣＵ１０は、図５に示す通信処理を実行することにより（Ｓ１８０）、Ｓ１７０で生成した要求データを、要求先のボデーＥＣＵ３０に、ネットワークＮＴを介して送信し、ボデーＥＣＵ３０に、遠隔操作信号に対応した処理（ボデー制御）を実行させる。

また、Ｓ１８０での処理を終えると、遠隔操作受付ＥＣＵ１０は、その通信結果に基づき、要求した処理（ボデー制御）がボデーＥＣＵ３０において成功したか否かを判断する（Ｓ１９０）。具体的に、Ｓ１８０で受信した完了応答データの実行成否情報が「成功」を示す場合には、要求した処理が成功したと判断する。一方、受信した完了応答データの実行成否情報が「失敗」を示す場合や、完了応答データをボデーＥＣＵ３０から受信することができなかった場合には、ボデーＥＣＵ３０において要求した処理が失敗したと判断する。

Ｓ１９０で、要求した処理がボデーＥＣＵ３０において失敗したと判断すると判断すると（Ｓ１９０でＮｏ）、遠隔操作受付ＥＣＵ１０は、遠隔操作に失敗した旨のエラー情報を、無線通信装置１５を介して、遠隔操作信号送信元のユーザ端末４０に送信し（Ｓ１９５）、その後、当該遠隔操作受付処理を一旦終了する。

この他、Ｓ１９０で、要求した処理がボデーＥＣＵ３０において成功したと判断すると判断すると、遠隔操作受付ＥＣＵ１０は、Ｓ２００に移行し、遠隔操作に成功した旨の情報と、成功した遠隔操作の内容を示す情報とを、無線通信装置１５を介して、遠隔操作信号送信元のユーザ端末４０に送信する。その後、当該遠隔操作受付処理を一旦終了する。

続いて、Ｓ１４０及びＳ１８０で実行される通信処理について説明する。図５は、遠隔操作受付ＥＣＵ１０が実行する通信処理を表すフローチャートである。この通信処理は、遠隔操作受付ＥＣＵ１０が有するプログラムに基づき、遠隔操作受付ＥＣＵ１０内の図示しないマイクロコンピュータが実行する。

図５に示す通信処理を開始すると、遠隔操作受付ＥＣＵ１０は、予め生成された要求データを、予め設定された要求先ＥＣＵに、ネットワークＮＴを介して送信する（Ｓ２１０）。即ち、Ｓ１４０で当該通信処理を実行する場合には、Ｓ１３０で生成された要求データを、Ｓ１２０で要求先ＥＣＵに設定された照合ＥＣＵ２０に送信する。一方、Ｓ１８０で当該通信処理を実行する場合には、Ｓ１７０で生成された要求データを、Ｓ１６０で要求先ＥＣＵに設定されたボデーＥＣＵ３０に送信する。

また、Ｓ２１０での処理を終えると、遠隔操作受付ＥＣＵ１０は、Ｓ２２０に移行し、Ｓ２１０の処理実行後、所定時間Ｔ０が経過したか否かを判断する。尚、この時間Ｔ０については、設計段階で、予め固定値（例えば、４秒程度）に設定する。具体的には、受付応答データを適切に受信することができる程度に、必要十分な時間に設定する。

Ｓ２２０において、所定時間Ｔ０が経過したと判断すると（Ｓ２２０でＹｅｓ）、遠隔操作受付ＥＣＵ１０は、Ｓ３００に移行し、所定時間Ｔ０が経過していないと判断すると（Ｓ２２０でＮｏ）、Ｓ２３０に移行する。

また、Ｓ２３０に移行すると、遠隔操作受付ＥＣＵ１０は、Ｓ２１０で送信した要求データに対応する完了応答データを、ネットワークＮＴを介して要求先ＥＣＵから受信したか否かを判断し（Ｓ２３０）、完了応答データを要求先ＥＣＵから受信したと判断すると（Ｓ２３０でＹｅｓ）、Ｓ２８０に移行し、完了応答データを要求先ＥＣＵから受信していないと判断すると（Ｓ２３０でＮｏ）、Ｓ２４０に移行する。

また、Ｓ２４０に移行すると、遠隔操作受付ＥＣＵ１０は、Ｓ２１０で送信した要求データに対応する受付応答データを、ネットワークＮＴを介して要求先ＥＣＵから受信したか否かを判断し、受付応答データを要求先ＥＣＵから受信していないと判断すると（Ｓ２４０でＮｏ）、Ｓ２２０に移行して、所定時間Ｔ０が経過するか、要求データに対応する受付応答データ又は完了応答データを受信するまで待機する。

一方、受付応答データを要求先ＥＣＵから受信したと判断すると（Ｓ２４０でＹｅｓ）、遠隔操作受付ＥＣＵ１０は、Ｓ２５０に移行し、受信した受付応答データが有する最大実行時間情報に基づき、この最大実行時間情報が表す値に、一定時間αを加算した値を、完了応答データの受信待ち動作についてのタイムアウト時間Ｔ１に設定する。

Ｔ１＝最大実行時間＋α
尚、時間αは、ゼロ以上で任意の値に設定することができる。但し、この時間αは、タイムアウト時間Ｔ１を、要求先ＥＣＵから通知された最大実行時間よりも若干余裕をもって設定するためのものであるので、必要以上に大きな値に設定しないようにする。

また、Ｓ２５０での処理を終了すると、遠隔操作受付ＥＣＵ１０は、Ｓ２５０でタイムアウト時間Ｔ１を設定した時点から、このタイムアウト時間Ｔ１が経過したか否かを判断し（Ｓ２６０）、タイムアウト時間Ｔ１が経過したと判断すると（Ｓ２６０でＹｅｓ）、Ｓ３００に移行し、タイムアウト時間Ｔ１が経過していないと判断すると（Ｓ２６０でＮｏ）、要求先ＥＣＵから、Ｓ２１０で送信した要求データに対応する完了応答データを、ネットワークＮＴを介して受信したか否かを判断する（Ｓ２７０）。そして、要求先ＥＣＵから完了応答データを受信していないと判断すると（Ｓ２７０でＮｏ）、タイムアウト時間Ｔ１が経過するか、完了応答データを受信するまで待機する。

この他、要求先ＥＣＵから完了応答データを受信したと判断すると（Ｓ２７０でＹｅｓ）、遠隔操作受付ＥＣＵ１０は、完了応答データが示す実行成否情報及び補助情報を、返値として出力し、これらの情報を遠隔操作受付処理タスクに提供する（Ｓ２８０）。その後、当該通信処理を終了する。

また、Ｓ３００に移行すると、遠隔操作受付ＥＣＵ１０は、図６に示すリトライ処理を実行する。図６は、遠隔操作受付ＥＣＵ１０が実行するリトライ処理を表すフローチャートである。

リトライ処理を開始すると、遠隔操作受付ＥＣＵ１０は、まずＳ３１０にて、リトライ回数を表すパラメータｎを、ゼロに初期化する。その後、Ｓ３２０に移行し、Ｓ２１０で送信した要求データと同一の要求データを、要求先ＥＣＵに再送信する。そして、再送信後には、Ｓ３３０にて、パラメータｎを１加算する（ｎ←ｎ＋１）。

また、この処理を終えると、遠隔操作受付ＥＣＵ１０は、Ｓ３２０での再送信後、所定時間Ｔ０が経過するか、Ｓ３２０で送信した要求データに対応する完了応答データを、ネットワークＮＴを介して要求先ＥＣＵから受信するか、Ｓ３２０で送信した要求データに対応する受付応答データを、ネットワークＮＴを介して要求先ＥＣＵから受信するまで待機し（Ｓ３４０〜Ｓ３６０）、所定時間Ｔ０が経過したと判断すると（Ｓ３４０でＹｅｓ）、Ｓ４１０に移行し、完了応答データを要求先ＥＣＵから受信したと判断すると（Ｓ３５０でＹｅｓ）、Ｓ４００に移行し、受付応答データを要求先ＥＣＵから受信したと判断すると（Ｓ３６０でＹｅｓ）、Ｓ３７０に移行する。

また、Ｓ３７０に移行すると、遠隔操作受付ＥＣＵ１０は、受信した受付応答データが有する最大実行時間情報に基づき、この最大実行時間情報が表す値に、一定時間αを加算した値を、完了応答データの受信待ち動作についてのタイムアウト時間Ｔ１に設定する。

そして、この処理を終了すると、遠隔操作受付ＥＣＵ１０は、Ｓ３７０でタイムアウト時間Ｔ１を設定した時点から、このタイムアウト時間Ｔ１が経過するか、Ｓ３２０で送信した要求データに対応する完了応答データを、ネットワークＮＴを介して要求先ＥＣＵから受信するまで待機し（Ｓ３８０〜Ｓ３９０）、タイムアウト時間Ｔ１が経過したと判断すると（Ｓ３８０でＹｅｓ）、Ｓ４１０に移行し、完了応答データを要求先ＥＣＵから受信したと判断すると（Ｓ３９０でＹｅｓ）、Ｓ４００に移行する。

また、Ｓ４００に移行すると、遠隔操作受付ＥＣＵ１０は、受信した完了応答データが示す実行成否情報及び補助情報を、返値として出力し、これらの情報を遠隔操作受付処理タスクに提供する。その後、当該リトライ処理を終了する。また、Ｓ３００で、このリトライ処理を終えると、上記通信処理を終了する。

一方、Ｓ４１０に移行すると、遠隔操作受付ＥＣＵ１０は、リトライ回数を表すパラメータｎの値が、予め定められたリトライ回数の上限値（例えば、値２）未満であるか否かを判断し、パラメータｎの値が、上限値未満であると判断すると（Ｓ４１０でＹｅｓ）、Ｓ３２０に移行して、再び、要求データを再送信する。そして、パラメータｎの値を１加算し（Ｓ３３０）、Ｓ３４０以降の処理を実行する。

また、リトライ回数が上限値以上であると判断すると（Ｓ４１０でＮｏ）、遠隔操作受付ＥＣＵ１０は、通信失敗の旨のエラー情報を、返値として出力し、これらの情報を遠隔操作受付処理タスクに提供する（Ｓ４２０）。その後、当該リトライ処理を終了する。また、Ｓ３００で、このリトライ処理を終えると、遠隔操作受付ＥＣＵ１０は、上記通信処理を終了する。

続いて、マスタＥＣＵから送信される要求データを受信するスレーブＥＣＵ（具体的には、照合ＥＣＵ２０及びボデーＥＣＵ３０）が実行する要求受付処理について説明する。図７は、スレーブＥＣＵが繰返し実行する要求受付処理を表すフローチャートである。この要求受付処理は、スレーブＥＣＵが有するプログラムに基づき、スレーブＥＣＵ内の図示しないマイクロコンピュータが実行する。

要求受付処理を開始すると、スレーブＥＣＵは、まず、マスタＥＣＵ（遠隔操作受付ＥＣＵ１０）から、要求データを受信するまで待機し（Ｓ５１０）、要求データを受信すると（Ｓ５１０でＹｅｓ）、受信した要求データが受付可能な要求データであるか否かを判断する（Ｓ５２０）。即ち、受信した要求データが示すサービス識別情報及びコマンド情報並びに指示対象情報に基づき、自装置にて要求データに対応する処理を実行可能か否か判断する。

そして、受信した要求データが受付可能な要求データではないと判断すると（Ｓ５２０でＮｏ）、スレーブＥＣＵは、実行失敗の旨の情報を記した完了応答データを生成する（Ｓ５３０）。

具体的に、Ｓ５３０では、データ識別情報として、「完了応答データ」を表すコードを記し、サービス識別情報、コマンド情報、指示対象情報、及び、要求同期カウンタとして、受信した要求データと同一のコードを記し、実行成否情報として、「失敗」を表すコードを記し、補助情報として、要求受付不可を表すコードを記した完了応答データを生成する。そして、このような構成の完了応答データを生成すると、生成した完了応答データを、要求元のマスタＥＣＵに、ネットワークＮＴを介して送信する（Ｓ５３５）。その後、当該要求受付処理を一旦終了し、次の要求データを受信するまで待機する（Ｓ５１０）。

一方、スレーブＥＣＵは、Ｓ５２０にて、受信した要求データが受付可能な要求データであると判断すると（Ｓ５２０でＹｅｓ）、Ｓ５４０に移行し、受信した要求データに記された要求同期カウンタと同一値の要求同期カウンタを有する処理実行履歴データを、当該スレーブＥＣＵのＲＡＭが記憶する実行履歴ファイル（図９参照）内で検索する。

当該スレーブＥＣＵが記憶する実行履歴ファイルは、対応する処理が完了し、対応する完了応答データが送信されている要求データ毎に、その要求データに対応する処理実行履歴データが格納されてなるものである。この実行履歴ファイルが有する処理実行履歴データは、図９に示すように、当該処理実行履歴データの登録時刻と、完了応答データの送信内容を表す情報とを有する。具体的に、処理実行履歴データは、完了応答データの送信内容を表す情報として、送信された完了応答データに記された各情報（実行成否情報、補助情報、要求同期カウンタ等）を有する。

Ｓ５４０での検索結果に基づき、受信した要求データに記された要求同期カウンタと同一値の要求同期カウンタを有する処理実行履歴データが実行履歴ファイル内に存在すると判断すると（Ｓ５５０）、スレーブＥＣＵは、その処理実行履歴データに基づいて、完了応答データを生成し（Ｓ５６０）、生成した完了応答データを、要求元のマスタＥＣＵに、ネットワークＮＴを介して送信する（Ｓ５６５）。尚、処理実行履歴データには、既に前回送信した完了応答データの内容が記述されているので、Ｓ５６０〜Ｓ５６５では、処理実行履歴データの内容に基づき、前回送信した完了応答データと同内容の完了応答データを、要求元のマスタＥＣＵに送信する。また、Ｓ５６５での処理を終えると、スレーブＥＣＵは、当該要求受付処理を一旦終了し、次の要求データを受信するまで待機する（Ｓ５１０）。

この他、スレーブＥＣＵは、Ｓ５５０において、受信した要求データに記された要求同期カウンタと同一値の要求同期カウンタを有する処理実行履歴データが実行履歴ファイル内に存在しないと判断すると（Ｓ５５０でＮｏ）、Ｓ５７０に移行し、受信した要求データに対応する処理が既に開始されているか否かを判断する。尚、この判断は、後述する実行管理テーブル内に、受信した要求データに記された要求同期カウンタと同一値の要求同期カウンタが記された実行管理データが存在するか否かを判断することにより行われる。

Ｓ５７０において、対応する処理が未だ実行開始されていないと判断すると（Ｓ５７０でＮｏ）、スレーブＥＣＵは、自装置のＲＯＭが記憶する処理時間テーブルから、受信した要求データにより実行を要求された処理についての処理時間情報を取得する（Ｓ５８０）。尚、図８は、処理時間テーブルの構成を示した図であり、具体的には、ボデーＥＣＵ３０が有する処理時間テーブルの構成を示した図である。

図８に示すように、処理時間テーブルは、要求データに基づいて実行可能な処理の種類毎に、その処理の実行に要する時間が、処理時間Ｔｃとして、記述されてなるものである。換言すると、処理時間テーブルは、受付可能な要求データに記述されるサービス、コマンド及び指示対象の組合せ毎に、その組合せに対応する処理の実行に要する時間が、処理時間Ｔｃとして、記述されてなるものである。

例えば、ボデーＥＣＵ３０は、遠隔操作受付ＥＣＵ１０から、要求データとして、車両ドアのアンロック処理を要求するデータを受信すると、その要求データに、サービス識別情報として記述された「ドア系」を表すコード、コマンド情報として記述された「アンロック」を表すコード、指示対象情報として記述された「車両ドア」を表すコードに基づき、対応する処理時間情報として、図８に示す処理時間情報の内、最上段から２段目の処理時間情報（「２秒」との値）を取得する。

Ｓ５８０において、上述のようにして、処理時間テーブルから処理時間情報を取得すると、スレーブＥＣＵは、Ｓ５８３に移行し、取得した処理時間情報が示す値Ｔｃを、最大実行時間情報として記した受付応答データを生成する。具体的には、サービス識別情報、コマンド情報、指示対象情報、要求同期カウンタとして、Ｓ５１０で受信した要求データと同一値を記述し、Ｓ５８０で取得した処理時間情報が示す値Ｔｃを、最大実行時間情報として記した受付応答データを生成する。

そして、この処理を終えると、スレーブＥＣＵは、要求データにより要求された処理の実行を開始すると共に（Ｓ５８７）、生成した受付応答データを、要求元のマスタＥＣＵに送信する（Ｓ６００）。例えば、Ｓ５８７では、要求データにより車両ドアのアンロック処理の実行を要求された場合、当該スレーブＥＣＵにて、車両ドアのアンロック処理を実行し、ドア装置３１を制御して、車両ドアをアンロックする。

尚、要求データにより要求された処理の実行を開始する際には、実行を開始する処理に対して、処理ＩＤを割り当てて、この処理ＩＤと処理を実行する原因となった要求データの受信内容を表す情報とを記述したレコードを、当該スレーブＥＣＵのＲＡＭが記憶する実行管理テーブルに登録する。レコードに記述される要求データの受信内容を表す情報としては、要求データが有する各情報の他、要求データの送信元ＥＣＵの情報が含まれる。

また、Ｓ６００にて、受付応答データを要求元のマスタＥＣＵに送信すると、スレーブＥＣＵは、Ｓ５８７で実行を開始した処理の実行を継続した状態で、当該要求受付処理を一旦終了し、次の要求データを受信するまで待機する。

一方、スレーブＥＣＵは、Ｓ５７０にて、受信した要求データに対応する処理が既に開始されていると判断すると（Ｓ５７０でＹｅｓ）、Ｓ５９０に移行し、当該スレーブＥＣＵのＲＯＭが記憶する処理時間テーブルから、受信した要求データにより実行を要求された処理についての処理時間情報を取得する。

また、処理時間テーブルから処理時間情報を取得すると、スレーブＥＣＵは、Ｓ５９３に移行し、取得した処理時間情報が示す値Ｔｃと、実行中の処理の進行度ｒ（ｒは、０以上１未満の値）とに基づいて、その処理が完了するまでの残り処理時間Ｔｒを導出する（Ｔｒ＝Ｔｃ・（１−ｒ））。

そして、導出した残り処理時間Ｔｒを最大実行時間情報として記した受付応答データを、生成する（Ｓ５９７）。具体的に、Ｓ５９７では、サービス識別情報、コマンド情報、指示対象情報、要求同期カウンタとして、Ｓ５１０で受信した要求データと同一値を記述し、Ｓ５９３で導出した残り処理時間Ｔｒを、最大実行時間情報として記述してなる受付応答データを生成する。

そして、この処理を終えると、スレーブＥＣＵは、Ｓ６００に移行し、上記生成した受付応答データを、要求元のマスタＥＣＵに送信し、その後、当該要求受付処理を一旦終了する。

続いて、スレーブＥＣＵが、完了応答データを送信するために実行する応答制御処理について説明する。図９は、スレーブＥＣＵが繰返し実行する応答制御処理を表すフローチャートである。

応答制御処理を開始すると、スレーブＥＣＵは、要求データにより実行を要求された処理であって、実行を開始した各処理の経過を監視し、処理終了のタイミングを検出する（Ｓ６１０）。即ち、ここでは、要求データにより実行を要求された処理であって、実行を開始した各処理の実行経過を監視し、監視対象の各処理のいずれかが、実行状態から実行終了状態に遷移するまで待機する。

そして、監視対象の各処理のいずれかが、実行状態から実行終了状態に遷移すると（Ｓ６１０でＹｅｓ）、スレーブＥＣＵは、Ｓ６２０に移行し、実行終了状態に遷移した処理の実行結果を記した完了応答データを生成する。

具体的には、実行終了状態に遷移した処理に関しての実行管理データを、実行管理テーブルから読み出し、この実行管理データが示す要求データの受信内容に基づき、サービス識別情報、コマンド情報、指示対象情報、及び、要求同期カウンタとして、要求データと同一値を記した完了応答データを生成すると共に、実行終了状態に遷移した処理の実行結果に基づき、この完了応答データに、処理の実行に成功したか否かを表す実行成否情報及び補助情報を記す。

また、このようにして、Ｓ６２０での処理を終えると、スレーブＥＣＵは、Ｓ６３０に移行し、Ｓ６２０で生成した完了応答データを、要求元（実行管理データが示す要求データ送信元）のマスタＥＣＵに送信する。尚、完了応答データの送信時には、上記読み出した実行管理データを、実行管理テーブルから消去する。

また、Ｓ６３０での処理を終えると、スレーブＥＣＵは、Ｓ６４０に移行し、送信した完了応答データの送信内容と、現在時刻とを記述した処理実行履歴データを生成し、これを、上述の実行履歴ファイルに登録する。その後、当該応答制御処理を一旦終了し、新しく、監視対象の処理のいずれかが、実行状態から実行終了状態に遷移するまで待機する（Ｓ６１０）。尚、実行履歴ファイルに登録された処理実行履歴データは、その登録時刻から所定時間経過後に、スレーブＥＣＵの動作により、実行履歴ファイルから消去される。

以上、マスタＥＣＵ及びスレーブＥＣＵの動作について説明したが、このような通信手法により、本実施例のマスタＥＣＵでは、スレーブＥＣＵに対して処理の実行を要求した際、その処理の実行結果を表す完了応答データについての受信待ち動作を、スレーブＥＣＵから通知された最大実行時間に対応する期間、実行する。そして、この期間内に完了応答データを受信することができなかった場合には、リトライ処理を行って、完了応答データの取得を再試行する。また、完了応答データに先駆けて送信されてくる受付応答データを、所定時間Ｔ０内に受信することができなかった場合にも、同様に、リトライ処理を行う。

例えば、マスタＥＣＵから送信された要求データが、ノイズ等の影響によりスレーブＥＣＵで受信されなかった場合や、スレーブＥＣＵから送信された受付応答データが、ノイズ等の影響により、マスタＥＣＵで受信されなかった場合には、図１０（ａ）に示すように、要求データの送信時点から所定時間Ｔ０経過後、マスタＥＣＵから要求データが再送信される（リトライ処理）。

また別例として、図１０（ｂ）に示すように、マスタＥＣＵ−スレーブＥＣＵ間で、要求データ及び受付応答データの授受が成功したにも拘わらず、スレーブＥＣＵで、マスタＥＣＵから要求された処理の実行が捗らず、スレーブＥＣＵからマスタＥＣＵに通知された最大実行時間よりも大きく超えて、上記処理の実行が継続され、マスタＥＣＵが、タイムアウト時間Ｔ１内に、完了応答データを受信することができなかった場合には、受付応答データの受信時点から時間Ｔ１の経過後に、マスタＥＣＵから要求データが再送信される（リトライ処理）。尚、スレーブＥＣＵは、マスタＥＣＵから再送信された要求データを受信すると、実行中の処理に関して、残り処理時間Ｔｒを導出して、この残り処理時間Ｔｒを最大実行時間情報として記した受付応答データを、マスタＥＣＵに送信する。そして、マスタＥＣＵでは、この受付応答データに記された最大実行時間情報に対応する時間がタイムアウト時間Ｔ１として設定される。そして、この時間Ｔ１が経過するまでの期間、マスタＥＣＵでは、完了応答データの受信待ち動作が行われる。

また別例として、図１０（ｃ）に示すように、マスタＥＣＵ−スレーブＥＣＵ間で、要求データ及ぶ受付応答データの授受が成功し、スレーブＥＣＵからは、完了応答データが送信されたにも拘わらず、ノイズ等の影響により、完了応答データが、マスタＥＣＵで受信されなかった場合には、タイムアウト時間Ｔ１の経過後に、マスタＥＣＵから要求データが再送信される（リトライ処理）。この際には、スレーブＥＣＵにて、既に要求された処理が完了しているので、スレーブＥＣＵからは、受付応答データに代えて、直ちに完了応答データが送信される。

また別例として、図１０（ｄ）に示すように、マスタＥＣＵ−スレーブＥＣＵ間で、要求データ及ぶ受付応答データの授受が成功し、スレーブＥＣＵからは、完了応答データが送信されたにも拘わらず、ノイズ等の影響により、完了応答データが、マスタＥＣＵにて受信されなかった場合であって、リトライ処理の際においても、ノイズ等の影響により、完了応答データが、マスタＥＣＵにて受信されなかった場合には、初回のリトライ処理の実行時点から、所定時間Ｔ０後に、再度、要求データが再送信される（二度目のリトライ処理）。

尚、リトライ処理時に、所定時間Ｔ０のみしか、受付応答データ及び完了応答データの受信待ちをしないのは、所定時間Ｔ０内に受付応答データ及び完了応答データのいずれも受信することができなかった場合には、通信データの伝送過程で問題が生じている可能性が高く、これ以上待機しても、完了応答データを受信できる可能性が低いためである。

即ち、要求データに対応する処理が完了している場合には、処理待ちによって完了応答データの送信に時間がかかるといったことがなく、受付応答データの受信待ち時間と同程度の時間で完了応答データを受信することができるため、所定時間Ｔ０内に受付応答データ及び完了応答データのいずれも受信することができなかった場合、マスタＥＣＵにおいては、二度目のリトライ処理を行う。

尚、所定時間Ｔ０については、受付応答データを適切に受信することができる程度に、必要十分な時間に設定すべきと上述したが、この時間Ｔ０については、完了応答データの再送信時に、完了応答データを適切に受信することができる程度に設定する必要もある。但し、この時間Ｔ０については、あまり長い時間を設定すると、タイムアウト時間Ｔ１を設定する意味がなくなってしまうので、これを考慮して、時間を設定する必要がある。

以上、本実施例の通信システム１について説明したが、本実施例の通信システム１では、遠隔操作受付ＥＣＵ１０が、ネットワークＮＴ内の他のＥＣＵである照合ＥＣＵ２０やボデーＥＣＵ３０と通信し、これらのＥＣＵ２０，３０と協働して、遠隔操作に係る一連の処理を実現する。具体的に、照合ＥＣＵ２０やボデーＥＣＵ３０は、遠隔操作受付ＥＣＵ１０から、要求データを受信すると、要求データにより要求された処理が完了するまでの所要時間を表す最大実行時間情報、を格納した応答データであって、要求が受け付けられたことを示す受付応答データを、要求元の遠隔操作受付ＥＣＵ１０に送信する。

一方、本実施例の通信システム１では、遠隔操作信号がユーザ端末４０から入力されると、遠隔操作受付ＥＣＵ１０が、遠隔操作に対する処理を実現するために、照合ＥＣＵ２０やボデーＥＣＵ３０に対して要求データを送信する。そして、遠隔操作受付ＥＣＵ１０は、この際照合ＥＣＵ２０やボデーＥＣＵ３０から送信されてくる受付応答データが示す最大実行時間情報に基づき、照合ＥＣＵ２０やボデーＥＣＵ３０で要求した処理が完了した後に送信されてくる処理の実行結果を表す完了応答データの受信待ち動作に関して、タイムアウト時間を設定する。

そして、タイムアウト時間内に、完了応答データを受信できた場合には、遠隔操作に係る処理の実行結果を、ユーザ端末４０に送信し、タイムアウト時間内に、完了応答データを受信することができなかった場合には、リトライ処理を実行する。

従って、この通信システム１によれば、スレーブＥＣＵに実行させる処理毎に、その処理についての完了応答データの受信待ち動作に関して、適切なタイムアウト時間を設定することができる。例えば、処理完了までに時間を要する（換言すると完了応答データの送信までに時間を要する）パワーウィンドウ系のサービスに合わせて、各サービスに共通するタイムアウト時間を設定する場合には、処理完了までの時間が短いドア系のサービスを要求する際、冗長にタイムアウト時間を設定することになり、リトライ処理の実行までに時間を要することになるが、本実施例によれば、要求する処理毎に、適切なタイムアウト時間を設定することができるので、リトライ処理の実行までに要する時間を短縮することができる。

また、本実施例の通信システム１では、スレーブＥＣＵに対して処理の実行を要求するマスタＥＣＵが、要求された処理を実行するスレーブＥＣＵから処理の実行時間に係る最大実行時間情報を取得するので、マスタＥＣＵとスレーブＥＣＵとの組合せが異なる場合においても、マスタＥＣＵでは、スレーブＥＣＵでの処理内容や処理能力に合わせて、適切なタイムアウト時間を設定することができる。

従って、本実施例の手法で、車内ＬＡＮシステムを構成すれば、ＥＣＵを機能毎に細分化して、細分化した各機能を個別の電子ＥＣＵにて実現するようにし、遠隔操作受付ＥＣＵ１０のような汎用的な機能を実現するＥＣＵについては、ＥＣＵを車種に拠らず共通化する場合に、ＥＣＵの組合せを考慮して、予め、マスタＥＣＵに対し、処理結果待ち動作のタイムアウト時間を設定する必要がなく、マスタＥＣＵにおいては、スレーブＥＣＵの種類によらず、常時、適切にタイムアウト時間を設定することができる。

その他、本実施例では、マスタＥＣＵから再送信された要求データを、スレーブＥＣＵが受信した時点で、要求データに対応する処理がスレーブＥＣＵで完了していない場合、この処理に関して、残り処理時間Ｔｒを算出し、この時間Ｔｒを最大実行時間情報として格納した受付応答データを、要求元のマスタＥＣＵに送信するようにした。従って、本実施零によれば、リトライ処理時においても、マスタＥＣＵで、完了応答データの受信待ち動作に関して、適切なタイムアウト時間を設定することができる。よって、本実施例の通信システム１によれば、リトライ処理によっても完了応答データを受信することができない場合に、再度、迅速にリトライ処理を実行することができる。

また、本実施例では、要求データの送信後、受付応答データを所定時間Ｔ０内に受信することができなかった場合には、その後、完了応答データの受信待機をすることなく、直ちにリトライ処理を実行するようにした。また、リトライ処理による要求データの再送信後、スレーブＥＣＵから所定時間Ｔ０内に、何ら応答がない場合、リトライ処理を再度直ちに行うようにした。従って、本実施例によれば、リトライ処理を効率的に行って、迅速に、要求した処理の実行結果を、スレーブＥＣＵから取得することができる。

尚、本発明の受付応答手段は、Ｓ５８０，Ｓ５８３，Ｓ６００の処理にて実現され、処理実行手段は、Ｓ５８７の処理にて実現され、完了応答手段は、応答制御処理（図９参照）にて実現されている。また、要求手段は、Ｓ１２０〜Ｓ１３０，Ｓ１６０〜Ｓ１７０，Ｓ２１０の処理にて実現され、受信処理手段は、Ｓ２６０〜Ｓ３００，Ｓ２００等の処理にて実現され、タイムアウト時間設定手段は、Ｓ２２０〜Ｓ２５０，Ｓ３４０〜Ｓ３７０の処理にて実現されている。また、リトライ応答手段は、Ｓ５４０〜Ｓ５７０，Ｓ５９０〜Ｓ６００の処理及び応答制御処理にて実現されている。

また、本発明の通信システムは、上記実施例に限定されるものではなく、種々の態様を採ることができる。
例えば、上記実施例では、窓の開閉処理の要求を遠隔操作受付ＥＣＵ１０から受けた場合に、窓の現在の開度を考慮せずに、処理時間テーブルに基づいて、受付応答データにより、最大実行時間情報を、ボデーＥＣＵ３０から遠隔操作受付ＥＣＵ１０に通知するようにしたが、窓の開閉に要する時間は、開閉開始時点での窓の開度に依存するため、ボデーＥＣＵ２０については、窓の開度を考慮して、受付応答データに記述する最大実行時間を算出する構成にされてもよい。

また、上記実施例では、現在実行中の処理に対応する要求データを、マスタＥＣＵから受信した場合に、スレーブＥＣＵが、残り処理時間Ｔｒを導出して、導出した残り処理時間Ｔｒを、最大実行時間情報として受付応答データに記述するが、スレーブＥＣＵは、現在実行中の処理に対応する要求データを、マスタＥＣＵから受信した場合にも、実行中でない処理についての要求データを、マスタＥＣＵから受信した場合と同様に、処理時間テーブルから読み出した処理時間Ｔｃを、最大実行時間情報として受付応答データに記述する構成にされてもよい。

その他、上記実施例では、遠隔操作受付ＥＣＵ１０、照合ＥＣＵ２０、ボデーＥＣＵ３０により協働して、遠隔操作に係る処理を実現するシステムに、本発明を適用した例を示したが、本発明の通信システムは、このようなＥＣＵの組合せに限定されるものではないことは、言うまでもない。

本実施例の通信システム１の構成を表すブロック図である。 本実施例の通信形態を示したラダーチャートである。 通信の際に、送受信される要求データ（ａ）、受付応答データ（ｂ）、完了応答データ（ｃ）の構成を示した説明図である。 遠隔操作受付ＥＣＵ１０が実行する遠隔操作受付処理を表すフローチャートである。 遠隔操作受付ＥＣＵ１０が実行する通信処理を表すフローチャートである。 遠隔操作受付ＥＣＵ１０が実行するリトライ処理を表すフローチャートである。 スレーブＥＣＵが実行する要求受付処理を表すフローチャートである。 処理時間テーブルの構成を表す図である。 スレーブＥＣＵが実行する応答制御処理を表すフローチャートである。 本実施例の通信形態を示したラダーチャートである。

符号の説明

１…通信システム、１０…遠隔操作受付ＥＣＵ、１５…無線通信装置、２０…照合ＥＣＵ、３０…ボデーＥＣＵ、３１…ドア装置、３３…パワーウィンドウ装置、３５…点灯装置、４０…ユーザ端末、ＮＴ…ネットワーク

Claims (6)

1. ネットワークに、複数の電子制御装置が接続され、前記複数の電子制御装置の内、少なくとも一つの電子制御装置Ａが、ネットワーク内の他の電子制御装置Ｂと通信し、前記他の電子制御装置Ｂと協働して、一連の処理を実現する通信システムであって、
   前記電子制御装置Ｂは、
   前記電子制御装置Ａから、処理の実行を要求する要求信号を受信すると、前記受信した要求信号にて要求された処理が完了するまでの所要時間を表す情報、を格納した応答信号であって、前記要求が受け付けられたことを示す受付応答信号を、前記要求信号の送信元装置に送信する受付応答手段と、
   前記電子制御装置Ａから、処理の実行を要求する要求信号を受信すると、前記受信した要求信号にて要求された処理を実行する処理実行手段と、
   前記処理実行手段にて前記要求信号に対応する処理が完了すると、前記要求信号に対応する処理が完了したことを示す応答信号であって、処理の実行結果を表す情報を格納した完了応答信号を、前記要求信号の送信元装置に送信する完了応答手段と、
   を備え、
   前記電子制御装置Ａは、
   イベントの発生に応じて、前記発生したイベントに対応した処理の実行を要求する要求信号を、その処理を実行可能な前記電子制御装置Ｂに送信する要求手段と、
   前記要求手段により送信された要求信号に対応する完了応答信号を、前記電子制御装置Ｂから受信して、前記受信した完了応答信号に基づき、前記イベントに対応する処理を実行する受信処理手段と、
   前記電子制御装置Ｂから受付応答信号を受信すると、前記受信した受付応答信号に格納された前記所要時間を表す情報に基づき、前記受信処理手段に対し、前記受信した受付応答信号に対応する完了応答信号の受信待ち動作についてのタイムアウト時間を設定するタイムアウト時間設定手段と、
   を備えることを特徴とする通信システム。
2. 前記受信処理手段は、前記タイムアウト時間設定手段により設定されたタイムアウト時間が経過するまでの期間に、前記要求信号に対応する完了応答信号を受信することができなかった場合、前記完了応答信号の取得を再試行する手順を含むリトライ処理を実行する構成にされていることを特徴とする請求項１記載の通信システム。
3. 前記受信処理手段は、前記タイムアウト時間設定手段により設定されたタイムアウト時間が経過するまでの期間に、前記要求信号に対応する完了応答信号を受信することができなかった場合、前記リトライ処理として、前記完了応答信号に対応する要求信号を送信した送信先の前記電子制御装置Ｂに、この要求信号に対応する再要求信号を、送信する構成にされ、
   前記電子制御装置Ｂは、
   前記電子制御装置Ａから、再要求信号を受信すると、この再要求信号に対応する要求信号の受信の際に前記処理実行手段が実行を開始した処理の実行結果を表す情報を格納した完了応答信号を、前記再要求信号の送信元装置に、送信するリトライ応答手段、
   を備えることを特徴とする請求項２記載の通信システム。
4. 前記リトライ応答手段は、前記再要求信号を受信した時点で、この再要求信号に対応する要求信号の受信の際に前記処理実行手段が実行を開始した処理が前記処理実行手段にて完了していない場合、前記完了応答信号の送信に先駆けて、前記要求信号に対応する処理が完了するまでの所要時間を表す情報、を格納した受付応答信号を、前記再要求信号の送信元装置に送信する構成にされていることを特徴とする請求項３記載の通信システム。
5. 前記タイムアウト時間設定手段は、前記要求手段による要求信号の送信後、所定時間内に、送信先の前記電子制御装置Ｂから受付応答信号を受信することができなかった場合、前記受信処理手段に、前記所定時間が経過した時点で、前記リトライ処理を開始させる構成にされていることを特徴とする請求項２〜請求項４のいずれかに記載の通信システム。
6. 前記タイムアウト時間設定手段は、前記受信処理手段による再要求信号の送信後、前記完了応答信号の受信が成功していない状態で、所定時間内に、送信先の前記電子制御装置Ｂから受付応答信号を受信することができなかった場合、前記所定時間が経過した時点で、前記受信処理手段に、再度、前記リトライ処理を実行させる構成にされていることを特徴とする請求項４記載の通信システム。

Images