(57)【要約】【課題】外部からのデータ取得要求が頻繁に行われる場合であっても、極力、車載ＥＣＵの本来の制御処理に支障が生じることを防止可能な電子制御システムを提供する。【解決手段】データ送信元ＥＣＵとして指定されるＥＣＵ−Ａ１０は、自身の処理負荷を計測し、その計測された処理負荷が第１のレベルを超えた場合に、同じデータを保有している他のＥＣＵ−Ｂ２０に、応答信号の代理送信を依頼する。従って、ＥＣＵ−Ａ１０において、処理負荷が増大する事態の発生を回避することが可能となる。また、ＥＣＵ−Ｂ２０が応答信号を代理送信する場合には、データ送信元ＥＣＵとして指定されたＥＣＵ−Ａ１０のＩＤを付加した応答信号を作成する。従って、ＯＢＤ２ユーザデバイス６０が指定したデータ送信元ＥＣＵとは異なる他のＥＣＵが応答信号を送信しても、ＯＢＤ２ユーザデバイス６０に、指定のデータ送信元ＥＣＵからの応答信号と認識させることができる。【選択図】図１６
2013233904.tif 000002
【特許請求の範囲】
【請求項１】
それぞれ固有のＩＤが付与され、ネットワーク接続された複数のＥＣＵ（１０、２０、３０）を有し、それら複数のＥＣＵの中の少なくとも１つのＥＣＵは、前記ネットワークに接続された外部装置（６０）から、前記ＩＤを用いてデータ送信元ＥＣＵが指定された、データの送信を要求する要求信号を受信したとき、その要求信号に応じて、当該ＥＣＵが保有しているデータを含む応答信号を前記外部装置に送信する電子制御システムであって、
前記データ送信元ＥＣＵとして指定されるＥＣＵは、
自身の処理負荷を計測する計測手段（Ｓ１３０）と、
前記計測手段によって計測された処理負荷が所定の第１のレベルを超えた場合に、同じデータを保有している他のＥＣＵに対して、代理として応答信号の送信を行うよう依頼する依頼手段（Ｓ１４０、Ｓ１７０、Ｓ２００）と、備え、
前記他のＥＣＵは、代理として前記外部装置に前記応答信号を送信する際に、前記データ送信元ＥＣＵとして指定されたＥＣＵのＩＤを付加した応答信号を作成して、前記外部装置に向けて送信する送信制御手段（Ｓ３８０、Ｓ３９０）を備えることを特徴とする電子制御システム。
【請求項２】
前記データ送信元ＥＣＵとして指定されるＥＣＵは、最初に、前記外部装置から要求信号を受信したとき、自身で応答信号を送信するとともに、処理負荷が所定の第１レベルを超えた場合に、前記依頼手段が、前記他のＥＣＵに対して応答信号の代理送信を依頼するものであって、
前記外部装置からの次回以降の要求信号に対して、前記他のＥＣＵが、代理として応答信号を送信することを特徴とする請求項１に記載の電子制御システム。
【請求項３】
前記他のＥＣＵも、自身の処理負荷を計測する計測手段（Ｓ３３０）を備え、
前記他のＥＣＵは、前記依頼手段から代理で応答信号の送信を行うよう依頼を受けたとき、前記計測手段によって計測される処理負荷が所定のレベル以下である場合に、その依頼を受諾し、所定のレベルを超えている場合には、依頼を拒否することを特徴とする請求項１又は２に記載の電子制御システム。
【請求項４】
前記データ送信元ＥＣＵとして指定されるＥＣＵ以外に、前記外部装置に送信すべきデータと同じデータを保有しているＥＣＵが複数ある場合であって、代理送信を依頼した他のＥＣＵが、その依頼を拒否した場合には、前記データ送信元ＥＣＵとして指定されたＥＣＵ、もしくは代理送信の依頼を拒否したＥＣＵが、同じデータを保有している別のＥＣＵに、さらに代理送信を依頼することを特徴とする請求項３に記載の電子制御システム。
【請求項５】
前記データ送信元ＥＣＵとして指定されるＥＣＵは、前記同じデータを保有している複数のＥＣＵごとに、代理送信を依頼したときの受諾、拒否の実績を記録しておき、受諾確率の高い順に、代理送信の依頼を行うことを特徴とする請求項３又は４に記載の電子制御システム。
【請求項６】
前記外部装置に送信すべきデータと同じデータを保有しているＥＣＵが複数ある場合、それら同じデータを保有している複数のＥＣＵがそれぞれ自身の処理負荷を計測する処理負荷計測手段（Ｓ３３０）を有し、
前記データ送信元ＥＣＵとして指定されるＥＣＵは、前記同じデータを保有している複数のＥＣＵから、それぞれの処理負荷を取得し、最も処理負荷の低いＥＣＵに対して、代理送信の依頼を行うことを特徴とする請求項３に記載の電子制御システム。
【請求項７】
前記他のＥＣＵが、代理送信の依頼を受託した後に、前記データ送信元ＥＣＵとして指定されたＥＣＵの処理負荷が所定の第２レベルよりも低下したとき、もしくは、前記他のＥＣＵの処理負荷が所定レベル以上に増加したとき、前記他のＥＣＵによる代理送信がキャンセルされ、前記データ送信元ＥＣＵとして指定されたＥＣＵが応答信号を送信することを特徴とする請求項３乃至６のいずれかに記載の電子制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク接続された複数のＥＣＵを有し、それら複数のＥＣＵの中の少なくとも１つのＥＣＵが、外部装置から、データの送信を要求する要求信号を受信したとき、その要求信号に応じて、当該ＥＣＵが保有しているデータを含む応答信号を外部装置に送信する電子制御システムに関する。
【背景技術】
【０００２】
例えば、特許文献１には、車両に搭載された複数の電子制御装置と、それら複数の電子制御装置に外部接続用コネクタを介して接続され、当該複数の電子制御装置の入出力データを診断する車両診断装置とからなる車両診断システムが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１−２４７７４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
近年、車両に装備されている故障診断用コネクタであるＯＢＤ２コネクタに、スマートフォンなどの携帯型情報端末を接続して、車両に関する様々なデータを車載ＥＣＵから取得して表示する技術が普及しつつある。
【０００５】
このような、車両に関するデータを取得する携帯型情報端末（以下、ＯＢＤ２ユーザデバイスと呼ぶ）が使用されることで、車載ＥＣＵにデータ取得要求が行われた場合、車載ＥＣＵはそのデータ取得要求に対して応答する必要が生じる。このため、ＯＢＤ２ユーザデバイスによって頻繁にデータ取得要求が出されると、その受信及び応答処理のために車載ＥＣＵの処理負荷が増加し、本来、車載ＥＣＵが実施すべき制御処理に支障をきたす虞が生じる。
【０００６】
本発明は、このような点に鑑みてなされたもので、外部からのデータ取得要求が頻繁に行われる場合であっても、極力、車載ＥＣＵの本来の制御処理に支障が生じることを防止することが可能な電子制御システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した目的を達成するために、請求項１に記載の電子制御システムは、それぞれ固有のＩＤが付与され、ネットワーク接続された複数のＥＣＵ（１０、２０、３０）を有し、それら複数のＥＣＵの中の少なくとも１つのＥＣＵは、前記ネットワークに接続された外部装置（６０）から、前記ＩＤを用いてデータ送信元ＥＣＵが指定された、データの送信を要求する要求信号を受信したとき、その要求信号に応じて、当該ＥＣＵが保有しているデータを含む応答信号を前記外部装置に送信するものであって、
前記データ送信元ＥＣＵとして指定されるＥＣＵは、
自身の処理負荷を計測する計測手段（Ｓ１３０）と、
前記計測手段によって計測された処理負荷が所定の第１のレベルを超えた場合に、同じデータを保有している他のＥＣＵに対して、代理として応答信号の送信を行うよう依頼する依頼手段（Ｓ１４０、Ｓ１７０、Ｓ２００）と、備え、
前記他のＥＣＵは、代理として前記外部装置に前記応答信号を送信する際に、前記データ送信元ＥＣＵとして指定されたＥＣＵのＩＤを付加した応答信号を作成して、前記外部装置に向けて送信する送信制御手段（Ｓ３８０、Ｓ３９０）を備えることを特徴とする。
【０００８】
上記のように、データ送信元ＥＣＵとして指定されるＥＣＵは、自身の処理負荷を計測し、その計測された処理負荷が第１のレベルを超えた場合に、同じデータを保有している他のＥＣＵに、応答信号の代理送信を依頼する。従って、データ送信元ＥＣＵとして指定されたＥＣＵにおいて、外部装置からのデータ送信要求に応えるために、処理負荷が増大する事態の発生を回避することが可能となる。また、他のＥＣＵが応答信号を代理送信する場合には、データ送信元ＥＣＵとして指定されたＥＣＵのＩＤを付加した応答信号を作成する。従って、外部装置が指定したデータ送信元ＥＣＵとは異なる他のＥＣＵが応答信号を送信しても、外部装置には、指定したデータ送信元ＥＣＵからの応答信号と認識させることが可能となる。
【０００９】
なお、上記括弧内の参照番号は、本発明の理解を容易にすべく、後述する実施形態における具体的な構成との対応関係の一例を示すものにすぎず、なんら本発明の範囲を制限することを意図したものではない。
【００１０】
また、上述した特徴以外の本発明の特徴に関しては、後述する実施形態の説明及び添付図面から明らかになる。
【図面の簡単な説明】
【００１１】
【図１】実施形態に係る電子制御システムの構成を示す構成図である。
【図２】各ＥＣＵ及びＯＢＤ２ユーザデバイス間での通信に用いられるＣＡＮフレームのフォーマットを示す図である。
【図３】定義されたＣＡＮ−ＩＤの一覧を示す図である。
【図４】ＥＣＵ−Ａが、ＯＢＤ２ユーザデバイスによってデータ送信元ＥＣＵとして指定された場合に、そのＥＣＵ−Ａが他のＥＣＵに向けて送信するＣＡＮフレームの一例を示す図である。
【図５】ＥＣＵ−Ｂが、ＥＣＵ−Ａから代理送信の依頼を受けた場合に、そのＥＣＵ−Ｂが他のＥＣＵに向けて送信するＣＡＮフレームの一例を示す図である。
【図６】ＯＢＤ２ユーザデバイスが、ＥＣＵ−Ａにデータ送信要求（データモニタ要求）を行う場合に送信するＣＡＮフレームの一例を示す図である。
【図７】ＥＣＵ−Ａが、ＯＢＤ２ユーザデバイスからデータ送信要求を受けて、その応答信号をＯＢＤ２ユーザデバイスに返送する場合のＣＡＮフレームの一例を示す図である。
【図８】各ＥＣＵが保有するデータに関する情報をまとめたテーブルである。
【図９】ＥＣＵ−Ａが、ＯＢＤ２ユーザデバイスからデータの送信を要求する信号（ＣＡＮフレーム）を受信したときに、割り込みにより実行される処理を示すフローチャートである。
【図１０】ＥＣＵ間において、センサ検出値や演算値を送信するために、ＥＣＵ−Ａにおいて定期的に繰り返し実行される処理を示すフローチャートである。
【図１１】代理送信を依頼した他のＥＣＵからの定期送信信号を受信したときに、ＥＣＵ−Ａにおいて、割り込みにより実行される処理を示すフローチャートである。
【図１２】ＥＣＵ−Ａからの定期送信信号を受信したときに、ＥＣＵ−Ｂにおいて、割り込みにより実行される処理を示すフローチャートである。
【図１３】ＥＣＵ間において、センサ検出値や演算値を送信するために、ＥＣＵ−Ｂにおいて、定期的に繰り返し実行される処理を示すフローチャートである。
【図１４】ＥＣＵ−Ｂが、ＯＢＤ２ユーザデバイスからデータの送信を要求する信号（ＣＡＮフレーム）を受信したときに、割り込みにより実行する処理を示すフローチャートである
【図１５】ＯＢＤ２ユーザデバイスから最初にデータ送信要求信号が出力されたときに、ＥＣＵ−Ａが行う処理を示す説明図である。
【図１６】ＯＢＤ２ユーザデバイスから２回目以降のデータ送信要求信号が出力されたときに、ＥＣＵ−Bが行う処理を示す説明図である。
【図１７】処理負荷が、平準化される様子を概念的に示す説明図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態に係る電子制御システムについて、図面を参照しつつ説明する。
【００１３】
図１に示すように、本実施形態による電子制御システムは、ネットワーク接続された複数のＥＣＵ（ＥＣＵ−Ａ１０、ＥＣＵ−Ｂ２０，ＥＣＵ−Ｃ３０，…）を有している。例えば、電子制御システムは、車両の駆動力を制御するために適用可能なものであって、その場合、各ＥＣＵ（ＥＣＵ−Ａ１０、ＥＣＵ−Ｂ２０，ＥＣＵ−Ｃ３０）は、エンジンの燃料噴射量、点火時期、バルブタイミング、スロットル開度、トランスミッションのギヤ位置などをそれぞれ制御する。
【００１４】
各ＥＣＵ（ＥＣＵ−Ａ１０、ＥＣＵ−Ｂ２０，ＥＣＵ−Ｃ３０）は、データの共有化や協調制御を行うため、車両に設けられたローカルエリアネットワーク（車内ＬＡＮ）４０を介して相互に通信可能に接続されている。この相互通信においては、通信プロトコルとして、例えばＣＡＮプロトコルが用いられる。
【００１５】
車内ＬＡＮ４０には、故障診断用コネクタであるＯＢＤ２コネクタ５０が設けられている。このＯＢＤ２コネクタは、例えば車両が不調となったとき、ディーラー等において、ダイアグ装置を接続するために設けられている。このダイアグ装置を用いて、ダイアグコードなどの内部データを各ＥＣＵ（ＥＣＵ−Ａ１０、ＥＣＵ−Ｂ２０，ＥＣＵ−Ｃ３０）から読み出すことにより、車両の正常、異常の判断や、異常部位の特定を容易に行うことができる。
【００１６】
ただし、近年では、スマートフォンやタブレットＰＣなどの携帯型情報端末のアプリケーションとして、ＯＢＤ２コネクタ５０を介して車両の様々なデータ（エンジン回転数、空気流量、アクセル開度、燃料噴射量など）を取得し、それをそのままもしくは加工して表示するものがある。このようなアプリケーションをインストールした携帯型情報端末（以下、ＯＢＤ２ユーザデバイス）６０が、ＯＢＤ２コネクタ５０に有線もしくは無線にて接続され、特定のＥＣＵに対してデータ送信要求を頻繁に行うと、そのＥＣＵにおいて、本来実施されるべき制御処理に支障が生じる虞がある。
【００１７】
そのため、本実施形態では、データ送信要求対象となったＥＣＵ（データ送信元ＥＣＵとして指定されたＥＣＵ）における処理負荷を計測し、その処理負荷が所定の第１レベルを超えた場合には、送信すべき同じデータを保有している他のＥＣＵが、代理して応答することを可能としたものである。この点については、後に詳細に説明する。
【００１８】
図２は、各ＥＣＵ（（ＥＣＵ−Ａ１０、ＥＣＵ−Ｂ２０，ＥＣＵ−Ｃ３０）及びＯＢＤ２ユーザデバイス６０間での通信に用いられるＣＡＮフレームのフォーマットの一例を示す図である。このＣＡＮフレームでは、その先頭に、送信元を識別するとともに送信先を特定するためのＣＡＮ−ＩＤを記録するためのＣＡＮ−ＩＤ部が設けられている。
【００１９】
このＣＡＮ−ＩＤに関して、以下に詳しく説明する。本実施形態では、例えば図３に示すように、ＣＡＮ−ＩＤが定義されている。例えば、ＣＡＮ−ＩＤが「７Ｅ０」の場合、送信元はＯＢＤ２ユーザデバイス６０であり、送信先はＥＣＵ−Ａ１０であることを意味し、「７Ｅ１」の場合、送信元はＯＢＤ２ユーザデバイス６０であり、送信先はＥＣＵ−Ｂ２０であることを意味し、「７Ｅ２」の場合、送信元はＯＢＤ２ユーザデバイス６０であり、送信先はＥＣＵ−Ｃ３０であることを意味する。また、ＣＡＮ−ＩＤが「７Ｅ８」の場合、送信元はＥＣＵ−Ａ１０であり、送信先はＯＢＤ２ユーザデバイス６０であることを意味し、「７Ｅ９」の場合、送信元はＥＣＵ−Ｂ２０であり、送信先はＯＢＤ２ユーザデバイス６０であることを意味し、「７ＥＡ」の場合、送信元はＥＣＵ−Ｃ３０であり、送信先はＯＢＤ２ユーザデバイス６０であることを意味する。
【００２０】
なお、各ＥＣＵ（ＥＣＵ−Ａ１０、ＥＣＵ−Ｂ２０，ＥＣＵ−Ｃ３０）間の通信においては、送信先ＥＣＵとして、自身以外のＥＣＵを一括して指定することが可能なように、ＣＡＮ−ＩＤが定められている。例えば、電子制御システムが、ＥＣＵ−Ａ１０、ＥＣＵ−Ｂ２０、及びＥＣＵ−Ｃ３０からなる場合、ＣＡＮ−ＩＤとして「１２０」を用いるケースでは、送信元はＥＣＵ−Ａ１０、送信先はその他のＥＣＵ−Ｂ２０及びＥＣＵ−Ｃ３０となる。同様に、ＣＡＮ−ＩＤとして「１２１」を用いるケースでは、送信元はＥＣＵ−Ｂ２０、送信先はＥＣＵ−Ａ１０及びＥＣＵ−Ｃ３０となり、「１２２」を用いるケースでは、送信元はＥＣＵ−Ｃ３０、送信先はＥＣＵ−Ａ１０及びＥＣＵ−Ｂ２０となる。
【００２１】
再び図２を参照すると、ＣＡＮフレームでは、先頭のＣＡＮ−ＩＤ部に続いて、ＤＡＴＡ部が定められている。このＤＡＴＡ部には、他のＥＣＵとの共用等のため、図示しない各種のセンサにて検出された検出値や、各ＥＣＵでの演算値が格納されたり、他のＥＣＵへの代理送信の依頼や、その依頼に対する受諾・拒否の回答などが格納されたりする。さらに、ＯＢＤ２ユーザデバイス６０とＥＣＵ間で通信されるＣＡＮフレームの場合、ＤＡＴＡ部には、要求するサービス内容や、要求データ名などが格納されたり、その要求に応答するデータが格納されたりする。
【００２２】
図４から図７は、ＣＡＮフレームのＤＡＴＡ部に格納される各種の情報の例を示している。まず、図４は、ＥＣＵ−Ａ１０が、ＯＢＤ２ユーザデバイス６０によってデータ送信元ＥＣＵとして指定された場合に、そのＥＣＵ−Ａ１０が他のＥＣＵに向けて送信するＣＡＮフレームの一例を示している。なお、各ＥＣＵ間においては、所定時間毎に、ＣＡＮフレームを作成して、相互に通信を行なっている。
【００２３】
図４に示すように、ＥＣＵ−Ａ１０から他のＥＣＵに送信されるＣＡＮフレームには、回転数、空気流量、アクセル開度などのセンサ検出値、演算値などが格納される。さらに、データ送信元ＥＣＵとして指定されたＥＣＵ−Ａ１０は、自身の処理負荷に応じて、他のＥＣＵに、ＯＢＤ２ユーザデバイス６０への応答信号の代理送信を依頼する場合があり、そのような代理送信を依頼するために必要な情報も格納される。具体的には、代理送信の依頼の有無を示す代理要求情報フラグＢ、要求データ名Ｃ、及び代理送信の依頼先のＥＣＵを示すＣＡＮ−ＩＤ情報Ｄなどが格納される。なお、ＣＡＮ−ＩＤ情報Ｄには、送信元を示すＩＤが用いられ、例えばＥＣＵ−Ｂ２０に代理送信を依頼する場合には、ＣＡＮ−ＩＤ情報Ｄとして「１２１」を格納する。
【００２４】
図５は、ＥＣＵ−Ｂ２０が、ＥＣＵ−Ａ１０から代理送信の依頼を受けた場合に、そのＥＣＵ−Ｂ２０が他のＥＣＵに向けて送信するＣＡＮフレームの一例を示している。図５に示すように、ＥＣＵ−Ｂ２０は、代理送信の依頼を受諾するか拒否するかを示す代理受諾フラグＸ、要求データ名Ｃ、及び代理送信の依頼元のＥＣＵ（ＥＣＵ−Ａ１０）を示すＣＡＮ−ＩＤ情報Ｙなどが格納される。
【００２５】
このような、図４及び図５に示すＣＡＮフレームが、ＥＣＵ−Ａ１０とＥＣＵ−Ｂ２０との間でやり取りされることにより、代理送信の依頼要求、及びその依頼要求が受諾されたか否かをそれぞれ認識することができる。
【００２６】
図６は、ＯＢＤ２ユーザデバイス６０が、ＥＣＵ−Ａ１０にデータ送信要求（データモニタ要求）を行う場合に送信するＣＡＮフレームの一例を示している。この場合、図６に示すように、ＣＡＮ−ＩＤ部には、送信元がＯＢＤ２ユーザデバイス６０であり、送信先がＥＣＵ−Ａ１０であることを示す「７Ｅ０」が格納される。そして、ＤＡＴＡ部においては、要求するサービス内容を示すサービス番号と、要求データ名とが格納される。なお、図示のサービス番号「０１」は、データモニタ（データ送信要求）を意味する。また、要求データ名は、１つのみである場合に限られず、複数の要求データ名が格納される場合もある。
【００２７】
図７は、ＥＣＵ−Ａ１０が、ＯＢＤ２ユーザデバイス６０からデータ送信要求を受けて、その応答信号をＯＢＤ２ユーザデバイス６０に返送する場合のＣＡＮフレームの一例を示している。なお、ＥＣＵ−Ｂ２０が代理送信を行う場合にも、図７に示す各情報を含むＣＡＮフレームを送信する。
【００２８】
図７に示すように、ＣＡＮ−ＩＤ部には、送信元がＥＣＵ−Ａ１０であり、送信先がＯＢＤ２ユーザデバイス６０であることを示す「７Ｅ８」が格納される。そして、ＤＡＴＡ部においては、要求されたデータを送信することを示すサービス番号（図示の例では「４１」）と、要求データ名、及びそのデータの値とが格納される。
【００２９】
ここで、本実施形態に係る電子制御システムにおいて、各ＥＣＵ（ＥＣＵ−Ａ１０、ＥＣＵ−Ｂ２０，ＥＣＵ−Ｃ３０）が保有するデータは、図８に一例として示すように、予め定められており、各ＥＣＵ及びＯＢＤ２ユーザデバイス６０それぞれにおいて既知である。従って、ＯＢＤ２ユーザデバイス６０は、所望のデータの取得希望がある場合、そのデータを保有しているＥＣＵをＣＡＮ−ＩＤにより指定して、上述したＣＡＮフレームを送信することが可能である。
【００３０】
また、ＯＢＤ２ユーザデバイス６０からデータ送信要求を受けたＥＣＵは、自身の処理負荷が大きいときに、図８に示すテーブルを参照して、同じデータを保有している他のＥＣＵを検索することが可能であり、その検索したＥＣＵに代理送信の依頼を行うことができる。なお、本実施形態においては、同じデータを保有するＥＣＵが複数ある場合、代理送信を依頼するＥＣＵは、図８に示すテーブルからランダムに選択される。また、同じデータを保有するとは、要求されたデータが複数である場合には、その複数のデータのすべてを保有していることを意味する
次に、ＥＣＵ−Ａ１０が、ＯＢＤ２ユーザデバイス６０によってデータ送信元ＥＣＵとして指定された場合に、そのＥＣＵ−Ａ１０において実行される具体的な処理について、図９〜図１１のフローチャートを用いて説明する。
【００３１】
図９のフローチャートは、ＥＣＵ−Ａ１０が、ＯＢＤ２ユーザデバイス６０からデータの送信を要求する信号（ＣＡＮフレーム）を受信したときに、割り込みにより実行される処理を示している。この場合、ＥＣＵ−Ａ１０は、まず、ステップＳ１００において、他のＥＣＵが代理送信の実行中であるときにＯＮとなる代理応答中フラグＡを参照する。このとき、代理応答中フラグＡがＯＮとなっていれば、ＥＣＵ―Ａ１０が、データの送信要求信号に対して応答する必要はないので、そのまま処理を終了する。一方、代理応答中フラグＡがＯＦＦとなっている場合には、ステップＳ１１０に進んで、要求されたデータを含む応答信号を作成して送信する。これにより、最初に、ＯＢＤ２ユーザデバイス６０からデータの送信要求信号が受信された場合に、遅滞なく、応答信号を送信することができる。
【００３２】
そして、ＯＢＤ２ユーザデバイス６０からデータ送信要求を受けたことにより、図９のフローチャートに示す処理が実行されたのであるから、ＯＢＤ２コネクタ５０にはＯＢＤ２ユーザデバイス６０が接続され、今後、繰り返しデータ送信要求信号を受ける可能性がある。そのため、ステップＳ１２０では、代理要求情報フラグＢの状態を、代理送信の必要性があることを示す「ＲＥＱ」に設定する。
【００３３】
次に、図１０のフローチャートについて説明する。図１０のフローチャートは、ＥＣＵ間において、センサ検出値や演算値を送信するために、ＥＣＵ−Ａ１０において定期的に繰り返し実行されるものである。
【００３４】
まず、ステップＳ１３０では、例えば、アイドルタスクによるインクリメントカウンタ値を処理負荷値とみなして、そのインクリメントカウンタ値により処理負荷を算出する。ただし、処理負荷の算出はこのような例に限られず、例えば、ＥＣＵ−Ａ１０におけるＣＰＵの使用率から処理負荷を算出しても良い。
【００３５】
続くステップＳ１４０では、ステップＳ１３０で算出した処理負荷が、所定の第１レベルを超えているか否かにより、処理負荷が大きいか否かを判定する。処理負荷が大きいと判定された場合には、ステップＳ１５０の処理に進み、処理負荷が大きくないと判定された場合には、ステップＳ１６０の処理に進む。
【００３６】
ステップＳ１５０では、代理要求情報フラグＢの状態が、代理送信の必要性があることを示す「ＲＥＱ」に設定されているか否かを判定する。この判定処理において「ＹＥＳ」と判定された場合、ＥＣＵ−Ａ１０の処理負荷が大きく、かつ、今後、繰り返しデータ送信要求信号を受ける可能性があるので、ステップＳ１７０に進み、図８に示すテーブルを参照して、代理送信を依頼するＥＣＵを検索して決定する。一方、ステップＳ１５０の判定処理において「ＮＯ」と判定された場合には、ＥＣＵ−Ａ１０の処理負荷は大きいが、現在のところ、データ送信要求信号を受ける可能性がないので、ステップＳ１８０に進んで、代理要求情報フラグＢの状態を、代理送信の必要性がないことを示す「ＮＯＮＥ」に設定する。
【００３７】
ステップＳ１６０では、代理応答中フラグＡがＯＦＦであるか否かを判定する。代理応答中フラグＡがＯＦＦではない、すなわち代理応答中フラグＡがＯＮと判定された場合、ステップＳ１９０の処理に進む。この場合、他のＥＣＵが代理送信を実行中であるが、その代理送信の依頼元のＥＣＵ−Ａ１０の処理負荷が低下しており、ＥＣＵ−Ａ１０にて応答信号の作成及び送信を行いうる状況になったといえる。そのため、ステップＳ１９０では、代理要求情報フラグＢの状態を、代理送信の依頼の取り消しを示す「ＣＡＮＣＥＬ」に設定する。さらに、「ＣＡＮＣＥＬ」に設定された代理要求情報フラグＢを含むＣＡＮフレームが、後述するステップＳ２００において代理送信の依頼先ＥＣＵに送信されることにより、代理送信が終了するので、代理応答中フラグＡをＯＦＦに設定する。
【００３８】
一方、ステップＳ１６０において、代理応答中フラグＡがＯＦＦであると判定された場合には、ステップＳ１８０の処理に進む。これにより、図９のフローチャートのステップＳ１２０の処理により、代理要求情報フラグＢの状態が、代理送信の必要性があることを示す「ＲＥＱ」に設定されていたとしても、ＥＣＵ−Ａ１０の処理負荷が低いため、代理送信の必要性がないことを示す「ＮＯＮＥ」に再設定することができる。
【００３９】
ステップＳ２００では、ＥＣＵ−Ａ１０は、定期送信信号として、図４に示すような各種の情報を格納したＣＡＮフレームを、他のＥＣＵに向けて送信する。そして、ステップＳ２１０では、他のＥＣＵへの送信が完了したため、代理要求情報フラグＢの状態を、初期状態である「ＮＯＮＥ」に設定する。
【００４０】
なお、上述したステップＳ１４０において、ＥＣＵ−Ａ１０の処理負荷のレベルを判定する際、代理送信が必要であると判定するための処理負荷のレベル（第１のレベル）と、実行中の代理送信の取り消しを判定するための処理負荷のレベル（第２のレベル）とは、同一のレベルであっても良いが、第１のレベルよりも第２のレベルの方を低くしても良い。このように、第１のレベルと第２のレベルとを異ならせることにより、代理送信の依頼と取り消しが頻繁に繰り返されることを防止することができる。
【００４１】
次に、図１１のフローチャートについて説明する。図１１のフローチャートは、代理送信を依頼した他のＥＣＵからの定期送信信号を受信したときに、割り込みにより実行される処理を示している。
【００４２】
まず、ステップＳ２２０では、他のＥＣＵから受信した定期送信信号（ＣＡＮフレーム）に含まれる代理受諾フラグＸを参照する。この代理受諾フラグＸがＯＮであれば、代理送信の依頼が受諾されたことを意味し、ＯＦＦであれば、代理送信の依頼が拒否されたことを意味する。そして、ステップＳ２２０において、代理受諾フラグＸがＯＮと判定された場合には、ステップＳ２３０に進んで、代理応答中フラグＡをＯＮに設定する。この代理応答中フラグＡがＯＮとなっている間は、ＥＣＵ−Ａ１０ではなく他のＥＣＵが、ＯＢＤ２ユーザデバイス６０からのデータ送信要求に応じて応答信号を送信する。
【００４３】
一方、ステップＳ２２０において、代理受諾フラグＸがＯＦＦと判定された場合には、ステップＳ２４０に進んで、代理応答中フラグＡをＯＦＦに設定する。代理応答中フラグＡがＯＦＦとなっている間は、たとえ自身の処理負荷のレベルが高くても、ＥＣＵ−Ａ１０は、ＯＢＤ２ユーザデバイス６０からデータ送信要求信号を受信した場合、その応答信号を作成し、返送する。
【００４４】
なお、他のＥＣＵによって代理送信の依頼が拒否された場合には、代理要求情報フラグＢの状態を、再び、代理送信の必要性があることを示す「ＲＥＱ」に設定し、次回の定期送信処理において、代理送信を拒否したＥＣＵ以外のＥＣＵに対して、代理送信の依頼を行うようにしても良い。
【００４５】
次に、ＥＣＵ−Ａ１０から代理送信の依頼を受けた、あるいは既にその依頼を受諾している他のＥＣＵ（例えば、ＥＣＵ−Ｂ２０）において実行される処理について、図１２〜図１４のフローチャートを用いて説明する。
【００４６】
まず、図１２のフローチャートは、ＥＣＵ−Ａ１０からの定期送信信号を受信したときに、割り込みにより実行される処理を示している。この場合、ＥＣＵ−Ｂ２０は、ステップＳ３００において、受信した定期送信信号に含まれる代理要求情報フラグＢを参照する。そして、代理要求情報フラグＢの状態が、「ＲＥＱ」の場合、ステップＳ３１０に進んで、一旦、代理受諾フラグＸをＯＮに設定する。また、代理要求情報フラグＢの状態が「ＣＡＮＣＥＬ」である場合には、ステップＳ３２０に進んで、代理受諾フラグＸをＯＦＦに設定する。代理要求情報フラグＢの状態が「ＮＯＮＥ」である場合には、代理受諾フラグＸに関する設定を行うことなく、そのまま図１２のフローチャートに示す処理を終了する。
【００４７】
次に、図１３のフローチャートについて説明する。図１３のフローチャートは、ＥＣＵ間において、センサ検出値や演算値を送信するために、ＥＣＵ−Ｂ２０において定期的に繰り返し実行されるものである。
【００４８】
まず、ステップＳ３３０において、ＥＣＵ−Ｂ２０の処理負荷が算出される。この処理負荷の算出は、図１０のフローチャートのステップＳ１３０の処理と同様に行われる。続くステップＳ３４０では、ステップＳ３３０で算出した処理負荷が、所定のレベルを超えているか否かにより、処理負荷が大きいか否かを判定する。処理負荷が大きいと判定された場合には、ステップＳ３５０の処理に進み、代理受諾フラグＸをＯＦＦに設定する。これにより、図１２のフローチャートのステップＳ３１０において、代理受諾フラグＸがＯＮに設定された場合であっても、ＥＣＵ−Ｂ２０の処理負荷が大きいときには、代理受諾フラグＸがＯＦＦに再設定される。さらに、一旦、ＥＣＵ−Ａからの代理送信の依頼を受諾した後であっても、定期送信処理時に、ＥＣＵ−Ｂ２０の処理負荷が大きくなっていると、代理受諾フラグＸがＯＦＦに設定され、代理送信の受諾が取り消される。
【００４９】
そして、ステップＳ３６０では、ＥＣＵ−Ｂ２０は、上述したように設定された代理受諾フラグＸを含み、かつ、図５に示すような各種の情報を格納したＣＡＮフレームを、定期送信信号として、他のＥＣＵに向けて送信する。ＥＣＵ−Ａ１０が、この定期送信信号を受信して、代理受諾フラグＸを参照することにより、ＥＣＵ−Ｂ２０が代理送信の依頼を受諾したか拒否したか、あるいは受諾済みの代理送信の取り消しを行ったかなどを認識することができる。
【００５０】
次に、図１４のフローチャートについて説明する。図１４のフローチャートは、ＥＣＵ−Ｂ２０が、ＯＢＤ２ユーザデバイス６０からデータの送信を要求する信号（ＣＡＮフレーム）を受信したときに、割り込みにより実行される処理を示している。なお、ＥＣＵ−Ｂ２０は、車内ＬＡＮ４０に接続されているので、ＯＢＤ２ユーザデバイス６０からＥＣＵ−Ａ１０に向けられた信号であっても、受信可能である。
【００５１】
まず、ステップＳ３７０では、代理受諾フラグＸがＯＮに設定されているか否かを判定する。このとき、代理受諾フラグＸがＯＮに設定されていると判定されると、ＥＣＵ−Ｂ２０が、ＯＢＤ２ユーザデバイス６０からのデータ要求信号に応答する必要があるので、ステップＳ３８０の処理に進む。ステップＳ３８０では、ＯＢＤ２ユーザデバイス６０への応答信号としてのＣＡＮフレームにおいて、ＣＡＮ−ＩＤの書換えを行う。つまり、ＥＣＵ−Ｂ２０が、ＯＢＤ２ユーザデバイス６０に信号を送信する場合には、通常、ＣＡＮ−ＩＤは「７Ｅ９」が用いられる。しかしながら、ＥＣＵ−Ｂ２０が、ＥＣＵ−Ａ１０に代わって応答信号を送信する場合には、ＣＡＮ−ＩＤを、ＥＣＵ−Ａ１０であることを示す「７Ｅ８」に書き換えるのである。これにより、ＯＢＤ２ユーザデバイス６０は、応答信号を受信したとき、データ送信要求信号に対する正当な応答信号であると認識し、受信処理を行うことになる。換言すると、もし、ＣＡＮ−ＩＤとして、ＥＣＵ−Ｂ２０であることを示す「７Ｅ９」をそのまま使用してしまうと、ＯＢＤ２ユーザデバイス６０は、自身のデータ送信要求信号に応答するものではないと判断する。この結果、例えば、自身のデータ送信要求に対して未回答であるため、繰り返しＥＣＵ−Ａ１０に対してデータ送信を要求することになってしまったりする。
【００５２】
そして、ステップＳ３９０では、書き換えたＣＡＮ−ＩＤを含むＣＡＮフレームを、応答信号として、代理送信する。
【００５３】
ＥＣＵ−Ａ１０及びＥＣＵ−Ｂ２０が、上述したような処理を行うことにより、ＯＢＤ２ユーザデバイス６０から最初にデータ送信要求信号が出力されたときには、図１５に示すように、ＥＣＵ−Ａ１０が応答信号を作成して返送する。しかしながら、その際、自身の処理負荷が大きい場合には、他のＥＣＵに対して、応答信号の代理送信を依頼する。その依頼が受諾された場合には、図１６に示すように、２回目以降のデータ送信要求信号に対する応答信号は、他のＥＣＵ（ＥＣＵ−Ｂ２０）によって作成され返送される。従って、図１７に示すように、ＥＣＵ−Ａ１０よりも処理負荷の低い他のＥＣＵに、データ送信要求信号に対する応答処理、すなわち、データ送信要求信号の受信処理及び応答信号の作成及び送信処理を移管することで、ＥＣＵ−Ａ１０が本来処理すべき制御処理に支障が生じることを極力回避することができる。
【００５４】
以上、本発明の好ましい実施形態について説明したが、本発明は、上述した実施形態になんら制限されることなく、本発明の主旨を逸脱しない範囲において、種々変形して実施することが可能である。
【００５５】
例えば、上述した実施形態では、ＯＢＤ２ユーザデバイスからのデータ送信要求信号を受信したときに、他のＥＣＵに対して代理送信を依頼したが、予め、要求されるデータの種類ごとに、各ＥＣＵの処理負荷に応じて、応答信号を代理送信するＥＣＵを決定しておいても良い。なお、各ＥＣＵの処理負荷は常に一定ではないので、代理送信するＥＣＵは、定期的に更新されることが好ましい。
【００５６】
また、上述した実施形態では、データ送信元ＥＣＵとして指定されたＥＣＵが、代理送信を依頼するＥＣＵを、同じデータを保有するＥＣＵの中からランダムに決定した。しかしながら、定期送信されるデータに各ＥＣＵの処理負荷情報を含ませておき、データ送信元ＥＣＵとして指定されたＥＣＵが代理送信を依頼する際に、同じデータを保有するＥＣＵの中で処理負荷が最も低いＥＣＵを選択するようにしても良い。あるいは、データ送信元ＥＣＵとして指定されたＥＣＵが、同じデータを保有している複数のＥＣＵごとに、代理送信を依頼したときの受諾、拒否の実績を記録しておき、受諾確率の高い順に、代理送信の依頼を行うようにしても良い。
【００５７】
さらに、上述した実施形態において、代理送信の依頼が拒否された場合、その代理送信を依頼したＥＣＵが、さらに別のＥＣＵに代理送信の依頼を行う旨の説明を行ったが、代理送信の依頼を拒否するＥＣＵが、他のＥＣＵに代理送信の依頼を行うようにすることも可能である。
【符号の説明】
【００５８】
１０  ＥＣＵ−Ａ
２０  ＥＣＵ−Ｂ
３０  ＥＣＵ−Ｃ
４０  車内ＬＡＮ
５０  ＯＢＤ２コネクタ
６０  ＯＢＤ２ユーザデバイス
【図１】
2013233904.tif 000003
【図２】
2013233904.tif 000004
【図３】
2013233904.tif 000005
【図４】
2013233904.tif 000006
【図５】
2013233904.tif 000007
【図６】
2013233904.tif 000008
【図７】
2013233904.tif 000009
【図８】
2013233904.tif 000010
【図９】
2013233904.tif 000011
【図１０】
2013233904.tif 000012
【図１１】
2013233904.tif 000013
【図１２】
2013233904.tif 000014
【図１３】
2013233904.tif 000015
【図１４】
2013233904.tif 000016
【図１５】
2013233904.tif 000017
【図１６】
2013233904.tif 000018
【図１７】
2013233904.tif 000019