(57)【要約】【課題】  車両用制御装置において、他の装置からの特定の要求に対して速やかに応答することと、処理負荷を低減することとを両立させる。【解決手段】  車両のエンジンを制御すると共に、通信ラインを介して接続された他の装置から受信した要求に対して応答データを送信するエンジンＥＣＵは、受信した要求が、車外のダイアグスキャンツールから送信される各種要求のうちの特定の要求である法規サービス要求か否かを判定し（Ｓ１７０，Ｓ１８０）、その判定結果と、エンジン制御処理負荷及び通信ラインの混雑度とに応じて、応答データの１フレーム目の送信を開始するまでの待ち時間及び各フレームの送信間隔を決定する送信待ち時間ＷＴと、各フレームのデータサイズＤＳと、その数だけフレームを送信すると一定時間だけ送信を中断することとなる連続送信フレーム数ＦＮとを設定するように構成されている（Ｓ１９０〜Ｓ２４０）。【選択図】  図１
2005047488.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載された機器を制御すると共に、通信ラインを介して接続された他の装置からの要求を受信すると、その受信した要求（以下、受信要求という）に対して応答データを送信する車両用制御装置において、
前記受信要求が特定の要求（以下、特定要求という）であるか否かを判定する判定手段と、
該判定手段の判定結果に基づいて、前記受信要求が前記特定要求でない場合よりも、前記受信要求が前記特定要求であった場合の方が、前記受信要求に対する応答性が高くなるように、前記応答データを送信する送信処理の実施条件を変更する変更手段と、
を備えていることを特徴とする車両用制御装置。
【請求項２】
請求項１に記載の車両用制御装置において、
前記変更手段は、前記送信処理の実施条件を、前記機器を制御するための処理負荷に応じても変更するように構成されていること、
を特徴とする車両用制御装置。
【請求項３】
請求項１又は請求項２に記載の車両用制御装置において、
前記変更手段は、前記送信処理の実施条件を、前記通信ラインの混雑度合いに応じても変更するように構成されていること、
を特徴とする車両用制御装置。
【請求項４】
請求項１ないし請求項３の何れか１項に記載の車両用制御装置において、
前記変更手段は、前記送信処理の実施条件として、他の装置からの要求を受信してから、該受信要求に対する応答データの送信を開始するまでの待ち時間を変更すること、
を特徴とする車両用制御装置。
【請求項５】
請求項１ないし請求項４の何れか１項に記載の車両用制御装置において、
当該装置は、前記応答データを複数のフレームに分けて間欠的に送信するように構成されており、
前記変更手段は、前記送信処理の実施条件として、前記各フレームの送信間隔を変更すること、
を特徴とする車両用制御装置。
【請求項６】
請求項１ないし請求項５の何れか１項に記載の車両用制御装置において、
当該装置は、前記応答データを複数のフレームに分けて間欠的に送信するように構成されており、
前記変更手段は、前記送信処理の実施条件として、前記各フレームのデータサイズを変更すること、
を特徴とする車両用制御装置。
【請求項７】
請求項１ないし請求項６の何れか１項に記載の車両用制御装置において、
当該装置は、前記応答データを複数のフレームに分けて間欠的に送信すると共に、所定数のフレームを送信する毎に一定時間フレームの送信を休止するように構成されており、
前記変更手段は、前記送信処理の実施条件として、前記所定数を変更すること、
を特徴とする車両用制御装置。
【請求項８】
請求項１ないし請求項７の何れか１項に記載の車両用制御装置において、
前記特定要求に対する応答データの送信が全て完了する前に、他の要求が受信された場合、その今回受信された他の要求が前記判定手段により前記特定要求ではないと判定されたならば、該他の要求に対する応答をキャンセルする応答キャンセル手段を備えていること、
を特徴とする車両用制御装置。
【請求項９】
請求項１ないし請求項８の何れか１項に記載の車両用制御装置において、
前記判定手段は、前記受信要求に含まれている情報のうち、該受信要求の送信元を表す送信元情報と、該受信要求の内容を表す識別情報との、少なくとも何れか一方に基づいて、その受信要求が前記特定要求であるか否かを判定すること、
を特徴とする車両用制御装置。
【請求項１０】
請求項１ないし請求項９の何れか１項に記載の車両用制御装置において、
前記要求を受信すると、前記通信ラインの混雑度が特定の度合いよりも大きいか否かを判定する混雑度判定手段を備え、
該混雑度判定手段により前記通信ラインの混雑度が特定の度合いよりも大きいと判定された場合に、前記判定手段及び前記変更手段が動作するように構成されていること、
を特徴とする車両用制御装置。
【請求項１１】
車両に搭載された機器を制御すると共に、通信ラインを介して接続された他の装置からの要求を受信すると、その受信した要求に対して応答データを送信する車両用制御装置において、
前記要求を受信すると、前記通信ラインの混雑度が特定の度合いよりも大きいか否かを判定する混雑度判定処理を行い、
該混雑度判定処理により前記通信ラインの混雑度が特定の度合いよりも大きいと判定した場合には、更に、前記受信した要求（以下、受信要求という）が特定の要求（以下、特定要求という）であるか否かを判定する要求判定処理を行い、
該要求判定処理により前記受信要求が前記特定要求であると判定した場合には、前記受信要求が前記特定要求でないと判定した場合よりも、前記受信要求に対する応答性が高くなるように、前記応答データを送信する送信処理の実施条件を設定するように構成されていること、
を特徴とする車両用制御装置。
【請求項１２】
請求項１１に記載の車両用制御装置において、
前記混雑度判定処理により前記通信ラインの混雑度が特定の度合いよりも大きくないと判定した場合には、前記要求判定処理を行うことなく、前記送信処理の実施条件を、前記要求判定処理により前記受信要求が前記特定要求であると判定した場合の実施条件と同じ条件に設定するように構成されていること、
を特徴とする車両用制御装置。
【請求項１３】
請求項１ないし請求項１２の何れか１項に記載の車両用制御装置において、
前記特定要求は、前記車両を診断するための診断装置から送信される要求であること、
を特徴とする車両用制御装置。
【請求項１４】
請求項１ないし請求項１２の何れか１項に記載の車両用制御装置において、
前記特定要求は、車両外部から送信される要求であること、
を特徴とする車両用制御装置。
【請求項１５】
請求項１ないし請求項１４の何れか１項に記載の車両用制御装置において、
当該装置は、前記車両のエンジンを制御する装置であること、
を特徴とする車両用制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載されたエンジン等の機器を制御する車両用制御装置に関し、特に、他の装置と通信ラインを介して通信を行う車両用制御装置に関するものである。
【背景技術】
【０００２】
従来より、自動車においては、複数の電子制御装置（以下、ＥＣＵという）を通信ラインで接続すると共に、その各ＥＣＵが通信によりデータをやり取りして車両に搭載された各種機器を制御する、といった車両内ＬＡＮが採用されている。更に、この種の車両内ＬＡＮとしては、各ＥＣＵが他のＥＣＵからの要求を受信すると該要求に対する応答データを送信する、といった通信手順を採るものがある。
【０００３】
また、こうした車両内ＬＡＮの通信ラインには、車両の整備工場などにおいて、車両の状態を診断するための診断装置（いわゆるダイアグスキャンツール）が接続され、例えばエンジンを制御するＥＣＵ（以下、エンジンＥＣＵという）に対しては、その診断装置から、現在のエンジン状態（エンジン水温やエンジン回転数など）を表すデータや故障箇所を表すデータなどの出力要求が送信される。そして、エンジンＥＣＵは、診断装置から送信されて来る要求を受信すると、その要求に応じた当該ＥＣＵ内のデータを、応答データとして返送するようになっている。
【０００４】
このような診断装置とＥＣＵとの通信は、ダイアグ通信と呼ばれている。そして、こうしたダイアグ通信における特定の要求に関しては、例えばＥＣＵがその要求を受けてから応答データの送信を開始するまでの時間等、その要求に対するＥＣＵの応答特性が法規（例えばＩＳＯ：１５０３１−５やＩＳＯ：１５７６５−４）で定められている。
【０００５】
また、従来より、車両のＥＣＵは、他の装置からの全ての要求に対して、同じタイミングで応答データを送信するように構成されていた。
一方、車両に搭載された制御ユニットが、通信ラインで接続された通信ユニットを介して、車両外部の管理センタ側へ診断結果を送信するシステムにおいて、制御ユニットは、機器の制御に要する処理負荷が所定以上大きいと考えられる期間中は、診断結果を出力する要求があっても、その要求に対応しないようにする、という技術もある（例えば、特許文献１参照）。
【特許文献１】特開平１１−２０１８７２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ここで、上記従来の車両用ＥＣＵでは、車両内の他のＥＣＵからの要求に対しても、診断装置からの特定の要求に対する応答性と同じ応答性（即ち、前述の法規で定められた応答特性を満たす応答性）で応答データを送信することとなるため、処理負荷が過大になってしまう可能性がある。
【０００７】
例えば、エンジンＥＣＵでは、エンジンの高回転数時やエンジン始動時など、制御対象機器としてのエンジンを制御するための処理負荷が大きいときに、他のＥＣＵからの要求を受信した場合には、その要求に対して、診断装置からの特定の要求と全く同じ応答性で応答データを送信するための大きな処理負荷が更に加わることにより、エンジン制御の処理抜けなどが起こる可能性がある。このため、より高性能な演算処理装置（いわゆるＣＰＵ）が必要になってしまう。
【０００８】
また、上記特許文献１に記載の技術では、処理負荷を低減することはできても、特定の要求に対して速やかに応答することと、処理負荷を低減することとを両立させることはできない。
【０００９】
そこで本発明は、車両用制御装置において、他の装置からの特定の要求に対して速やかに応答することと、処理負荷を低減することとを、両立させることを目的としている。
【課題を解決するための手段】
【００１０】
上記目的を達成するためになされた請求項１に記載の車両用制御装置は、車両に搭載された機器を制御すると共に、通信ラインを介して接続された他の装置からの要求を受信すると、その受信した要求（受信要求）に対して応答データを送信するが、特に、受信要求が特定の要求（特定要求）であるか否かを判定する判定手段と、変更手段とを備えている。そして、変更手段は、判定手段の判定結果に基づいて、受信要求が特定の要求（特定要求）でない場合よりも特定要求であった場合の方が、その受信要求に対する応答性が高くなるように、応答データを送信する送信処理の実施条件を変更する。
【００１１】
このような請求項１の車両用制御装置によれば、他の装置からの特定の要求に対して速やかに応答することと、処理負荷を低減することとを、両立させることができる。即ち、特定要求に対しては、高い応答性で応答データを送信することができ、また、特定要求でない要求に対しては、特定要求に対してよりも低い応答性で応答データを送信することとなり、応答データ送信のための処理負荷が低減され、その結果、機器の制御に支障をきたすことが回避される。
【００１２】
次に、請求項２に記載の車両用制御装置では、請求項１の車両用制御装置において、変更手段は、前記送信処理の実施条件を、機器を制御するための処理負荷（以下、制御処理負荷という）に応じても変更するように構成されている。
【００１３】
このような請求項２の車両用制御装置によれば、制御処理負荷が大きい場合ほど受信要求に対する応答性が低くなるように、前記送信処理の実施条件を変更することにより、制御処理負荷が大きい場合ほど応答データを送信するための処理負荷を低減させることができ、機器の制御に支障が生じることを一層確実に回避することができる。換言すれば、機器の制御に影響を与えないように通信を行うことができるようになる。
【００１４】
尚、送信処理の実施条件を制御処理負荷に応じて（詳しくは、制御処理負荷が大きい場合ほど受信要求に対する応答性が低くなるように）変更することは、特定要求に対して応答する際と、特定要求以外の要求に対して応答する際との、両方の場合に実施するようにしても良いし、何れか一方の場合にのみ実施するように構成しても良い。
【００１５】
次に、請求項３に記載の車両用制御装置では、請求項１，２の車両用制御装置において、変更手段は、前記送信処理の実施条件を、通信ラインの混雑度合いに応じても変更するように構成されている。
【００１６】
このような請求項３の車両用制御装置によれば、通信ラインの混雑度合いが大きい場合ほど受信要求に対する応答性が低くなるように、前記送信処理の実施条件を変更することにより、通信ラインの混雑度を過剰にしてしまうことを防止することができる。
【００１７】
尚、送信処理の実施条件を通信ラインの混雑度合いに応じて（詳しくは、通信ラインの混雑度合いが大きい場合ほど受信要求に対する応答性が低くなるように）変更することは、特定要求に対して応答する際と、特定要求以外の要求に対して応答する際との、両方の場合に実施するようにしても良いし、何れか一方の場合にのみ実施するようにしても良い。
【００１８】
ところで、変更手段が変更する前記送信処理の実施条件としては、請求項４に記載のように、他の装置からの要求を受信してから、該受信要求に対する応答データの送信を開始するまでの待ち時間が考えられる。
【００１９】
つまり、この場合には、待ち時間が短いほど、受信要求に対する応答性が高いということであり、例えば受信要求が特定要求でない場合よりも特定要求であった場合の方が、上記待ち時間が短くなる。また、受信要求が特定要求でない場合には、上記待ち時間が長くなり、処理負荷に余裕を持たせることができる。そして、この待ち時間を変更する構成は、特定要求を受信してから規定時間以内に必ず応答データの送信を開始しなければならない制約がある場合に有効である。
【００２０】
また、応答データを複数のフレームに分けて間欠的に送信するのであれば、請求項５に記載のように、変更手段は、前記送信処理の実施条件として、応答データの各フレームの送信間隔を変更するように構成することもできる。
【００２１】
つまり、この場合には、各フレームの送信間隔が短いほど、応答データの全て（即ち、全てのフレーム）を送信し終えるまでの時間が短くなり、受信要求に対する応答性が高くなる。そして、例えば受信要求が特定要求でない場合より特定要求であった場合の方が、１フレーム毎の送信間隔が短く設定されて、応答データの全てを送信し終えるまでの時間が短くなる。また、受信要求が特定要求でない場合には、１フレーム毎の送信間隔が長く設定されるため、応答データ送信のための処理負荷が低減される。このため、請求項５の構成は、特定要求を受信してからある時間以内に必ず応答データの全てを送信し終えなければならない制約がある場合に有効である。
【００２２】
また更に、応答データを複数のフレームに分けて間欠的に送信するのであれば、請求項６に記載のように、変更手段は、前記送信処理の実施条件として、応答データの各フレームのデータサイズを変更するように構成することもできる。
【００２３】
つまり、この場合には、各フレームのデータサイズが大きいほど、応答データの全てを送信し終えるまでの時間が短くなり、受信要求に対する応答性が高くなる。そして、例えば受信要求が特定要求でない場合より特定要求であった場合の方が、１フレーム毎のデータサイズが大きく設定されて、応答データの全てを送信し終えるまでの時間が短くなる。また、受信要求が特定要求でない場合には、１フレーム毎のデータサイズが小さく設定されるため、応答データ送信のための処理負荷が低減される。このため、請求項６の構成も、特定要求を受信してからある時間以内に必ず応答データの全てを送信し終えなければならない制約がある場合に有効である。
【００２４】
一方また、応答データを複数のフレームに分けて間欠的に送信すると共に、所定数ＦＮのフレームを送信する毎に一定時間フレームの送信を休止するのであれば、請求項７に記載のように、変更手段は、前記送信処理の実施条件として、上記所定数ＦＮを変更するように構成することもできる。
【００２５】
つまり、この場合には、上記所定数ＦＮ（即ち、連続で送信するフレーム数）が大きいほど、応答データの全てを送信し終えるまでの時間が短くなり、受信要求に対する応答性が高くなる。そして、例えば受信要求が特定要求でない場合より特定要求であった場合の方が、上記所定数ＦＮが大きく設定されて、応答データの全てを送信し終えるまでの時間が短くなる。また、受信要求が特定要求でない場合には、上記所定数ＦＮが小さく設定されるため、応答データ送信のための処理負荷が低減される。このため、請求項７の構成も、特定要求を受信してからある時間以内に必ず応答データの全てを送信し終えなければならない制約がある場合に有効である。
【００２６】
次に、請求項８に記載の車両用制御装置では、請求項１〜７の車両用制御装置において、応答キャンセル手段を備えている。そして、この応答キャンセル手段は、特定要求に対する応答データの送信が全て完了する前に、他の要求が受信された場合、その今回受信された他の要求が判定手段により特定要求ではないと判定されたならば、該他の要求に対する応答をキャンセルする。つまり、特定要求に対して応答している最中に、特定要求ではない要求を受けた場合には、その今回受信の要求に対して応答するのをキャンセルするようにしている。
【００２７】
そして、このような請求項８の車両用制御装置によれば、応答データを送信するための処理負荷をむやみに増加させることなく、優先度の高い特定要求に対して確実に応答することができる。
【００２８】
一方、判定手段は、請求項９に記載の如く、受信要求に含まれている情報のうち、該受信要求の送信元を表す送信元情報と、該受信要求の内容を表す識別情報との、少なくとも何れか一方に基づいて、その受信要求が特定要求であるか否かを判定するように構成することができる。
【００２９】
尚、例えば、特定の装置から送信される全ての要求を特定要求とするシステムの場合、受信要求が特定要求であるか否かは、送信元情報からのみ判定することができる。また、２つ以上の装置が同じ内容の要求を送信するが、その内の１つの装置から送信される要求だけを特定要求とするシステムの場合には、送信元情報と内容の識別情報との両方から、受信要求が特定要求であるか否かを判定することができる。
【００３０】
次に、請求項１０の車両用制御装置では、請求項１〜９の車両用制御装置において、他の装置からの要求を受信すると、混雑度判定手段が、通信ラインの混雑度が特定の度合いよりも大きいか否かを判定する。そして、この車両用制御装置では、混雑度判定手段により通信ラインの混雑度が特定の度合いよりも大きいと判定された場合に、判定手段及び変更手段が動作するようになっている。
【００３１】
このような車両用制御装置によれば、要求を受信すると、まず、通信ラインの混雑度を判定し、通信ラインの混雑度が特定の度合いよりも大きい“混雑度大”の場合にだけ、受信要求が特定要求か否かに応じて応答性を差別化することとなるため、必要以上に送信データの応答性を下げることがない。
【００３２】
つまり、通信ラインが混雑していない場合（混雑度が特定の度合いよりも大きくない場合）には、受信要求の種別に拘わらず、全ての応答データを、高い応答性で送信することができる。そして、その結果、通信ラインに接続された各装置での制御性を向上させることができる。
【００３３】
一方、請求項１１の車両用制御装置も、車両に搭載された機器を制御すると共に、通信ラインを介して接続された他の装置からの要求を受信すると、その受信した要求（受信要求）に対して応答データを送信するが、特に、要求を受信すると、通信ラインの混雑度が特定の度合いよりも大きいか否かを判定する混雑度判定処理を行う。
【００３４】
そして、この車両用制御装置は、混雑度判定処理によって通信ラインの混雑度が特定の度合いよりも大きいと判定した場合に、更に、今回受信した要求（受信要求）が特定の要求（特定要求）であるか否かを判定する要求判定処理を行い、その要求判定処理によって受信要求が特定要求であると判定した場合には、受信要求が特定要求でないと判定した場合よりも、受信要求に対する応答性が高くなるように、応答データを送信する送信処理の実施条件を設定するように構成されている。尚、送信処理の実施条件としては、前述したように、応答データの送信を開始するまでの待ち時間や、応答データの各フレームの送信間隔や、応答データの各フレームのデータサイズや、上記所定数ＦＮなどが考えられる。
【００３５】
このような車両用制御装置によっても、請求項１の車両用制御装置と同じ効果が得られる上に、請求項１０の装置と同様に、要求を受信すると、まず、通信ラインの混雑度を判定し、“混雑度大”の場合にだけ、受信要求が特定要求か否かに応じて応答性を差別化することとなるため、必要以上に送信データの応答性を下げることがない。
【００３６】
特に、請求項１２に記載の如く、混雑度判定処理によって通信ラインの混雑度が特定の度合いよりも大きくないと判定した場合には、要求判定処理を行うことなく、送信処理の実施条件を、要求判定処理により受信要求が特定要求であると判定した場合の実施条件と同じ条件に設定するように構成すれば、通信ラインの混雑度が特定の度合いよりも大きくない“混雑度小”の場合には、受信要求が特定要求以外の要求であっても、特定要求に対する応答性と同じ応答性で応答データを送信することとなり、受信要求の種別に拘わらず、全ての応答データを、高い応答性で送信することができる。よって、通信ラインに接続された各装置での制御性を向上させることができる。
【００３７】
尚、通信ラインの混雑度が特定の度合いよりも大きいか否かは、例えば、通信ライン上に流れている一定時間当たりのデータ量を混雑度として検出し、そのデータ量が特定の度合いとしての規定値よりも大きければ、混雑度が特定の度合いよりも大きいと判定するように構成することができる。
【００３８】
一方、特定要求としては、請求項１３に記載の如く、車両を診断するための診断装置から送信される要求とすることが考えられる。
また、特定要求としては、請求項１４に記載の如く、車両外部から送信される要求とすることも考えられる。尚、この場合、通信ラインに接続されている他の装置が、車両外部からの要求を受信して通信ラインに送出し、その送出された要求を、本車両用制御装置が受信することとなる。
【００３９】
一方更に、本発明（請求項１〜１４）の車両用制御装置が、請求項１５に記載の如く車両のエンジンを制御する装置であれば、エンジンを制御するための各種処理に支障をきたすことなく、他の装置からの特定の要求に対して速やかに応答することができるようになる。
【発明を実施するための最良の形態】
【００４０】
以下に、本発明が適用された実施形態の車両用エンジンＥＣＵについて、図面と共に説明する。
まず図１に示すように、本実施形態のエンジンＥＣＵ１は、車両内ＬＡＮの１つのノードとなっており、自動変速機の変速制御を行うＥＣＴ・ＥＣＵ２、車両の走行安定性を向上させるための制御を行う姿勢制御ＥＣＵ３、及び自車両を先行車両に一定の車間距離で追従させたり、一定速度で走行させるための制御を行う車間制御ＥＣＵ４と、制御系通信ライン８を介して接続されている。
【００４１】
また、その制御系通信ライン８は、ゲートウェイＥＣＵ７に接続されており、更に、そのゲートウェイＥＣＵ７は、ナビゲーション装置を制御するナビＥＣＵ５とマルチメディア系通信ライン９を介して接続されていると共に、ドアのロック・アンロックやパワーウィンドウ等を制御するボデーＥＣＵ６とボデー系通信ライン１０を介して接続されている。
【００４２】
そして、この車両内ＬＡＮでは、ゲートウェイＥＣＵ７を介して、異なる通信ライン８〜１０の各々に接続されたＥＣＵ同士も通信ができるようになっている。つまり、ゲートウェイＥＣＵ７は、各通信ライン８〜１０間でのデータを中継する。
【００４３】
また、ナビＥＣＵ５には、車両外部の車両情報管理センター１１との間でアンテナ１２を介して無線通信を行うための通信部１３が接続されている。そして、ナビＥＣＵ５は、上記アンテナ１２及び通信部１３により、車両情報管理センター１１と交信して、最新の道路状況などの様々な情報を得たり、自車位置などを報告している。尚、符号１４は、車両情報管理センター１１側のアンテナである。
【００４４】
そして、この車両内ＬＡＮでは、各ＥＣＵ１〜６が、他のＥＣＵからの要求を受信すると該要求に対する応答データを送信する、といった通信手順で情報をやり取りして、各自の制御対象機器を制御する。尚、本実施形態では、通信プロトコルとして、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）プロトコルが用いられている。
【００４５】
そして更に、制御系通信ライン８には、車両外部の装置であって、車両の整備工場などにおいて車両の状態を診断するためのダイアグスキャンツール１５（診断装置に相当）が接続されるようになっている。
【００４６】
次に、エンジンＥＣＵ１が他のＥＣＵ２〜６又はダイアグスキャンツール１５からの要求に対して応答データを送信する際の動作概要について、図２を用い説明する。
図２に示すように、エンジンＥＣＵ１は、他のＥＣＵ２〜６又はダイアグスキャンツール１５からの要求を受信すると、その要求（受信要求）に対する応答データを、複数のフレームに分けて間欠的に送信すると共に、フレームを連続送信フレーム数ＦＮ（請求項７に記載の所定数に相当）だけ送信する毎に、一定時間フレームの送信を休止（中断）するようになっている。尚、図２における連続送信待ち時間とは、フレームの送信を一時中断する上記一定時間のことである。また、そのようなフレーム送信の一時中断は、応答データのフレーム総数が連続送信フレーム数ＦＮよりも多い場合に発生する。
【００４７】
そして、本実施形態のエンジンＥＣＵ１では、要求を受信してから最初のフレーム（１フレーム目）の送信を開始するまでの待ち時間（つまり、応答データの送信を開始するまでの待ち時間であり、図２における１フレーム目用送信待ち時間）と、各フレームの送信間隔（図２における２フレーム目用送信待ち時間，３フレーム目用送信待ち時間，…）とが、送信待ち時間ＷＴというパラーメータとして可変になっている。そして更に、各フレームのデータサイズＤＳと、上記連続送信フレーム数ＦＮとの各々も、可変になっている。
【００４８】
次に、エンジンＥＣＵ１が他のＥＣＵ２〜６又はダイアグスキャンツール１５からの要求に対して応答データを送信するために実行する処理の内容について、図３〜図７を用い説明する。尚、以下に説明する各処理は、実際には、エンジンＥＣＵ１に搭載されたマイコン（マイクロコンピュータ）１ａが、エンジンを制御するための制御処理と並行して実行するものである。
【００４９】
まず図３に示すように、エンジンＥＣＵ１では、他のＥＣＵ２〜６又はダイアグスキャンツール１５からの要求を受信すると、送受信部が要求受信通知を発生する。すると、マイコン１ａは、図４の要求受信時処理を実行する。
【００５０】
また、エンジンＥＣＵ１では、互いにずれた４ｍｓ毎の各タイミングで、トリガとしてのタイミング通知Ａとタイミング通知Ｂとがそれぞれ発生する。
そして、マイコン１ａは、タイミング通知Ａが発生する毎に、図６のフレーム送信処理を実行して、送信すべき応答データのフレームがある場合には、送受信部に対して送信要求を出力する。すると、送受信部は、その１フレーム分を送信することとなる。そして更に、マイコン１ａは、タイミング通知Ｂが発生する毎に、図７のエンジン処理負荷・通信ラインの監視処理を実行する。
【００５１】
尚、送受信部の機能、及びタイミング通知Ａ，Ｂの各々を４ｍｓ毎に発生する機能も、マイコン１ａのソフトウェア処理によって実現されている。
次に、図４に示すように、エンジンＥＣＵ１が他のＥＣＵ２〜６又はダイアグスキャンツール１５からの要求を受信して、当該エンジンＥＣＵ１のマイコン１ａが要求受信時処理の実行を開始すると、まずＳ１１０にて、前回要求の応答中であるか否か（即ち、前回受信した要求に対する応答データの全フレームの送信が未だ完了していない状態であるか否か）を判定する。
【００５２】
そして、前回要求の応答中であれば（Ｓ１１０：ＹＥＳ）、Ｓ１２０に進み、現在応答中の前回要求が法規サービス要求であるか否かを判定する。
ここで、法規サービス要求とは、ダイアグスキャンツール１５から送信される各種要求のうちの一部であり、それを受信してから応答データの送信を開始するまでの時間や、その応答データの送信を完了するまでの所要時間が法規（例えばＩＳＯ：１５０３１−５やＩＳＯ：１５７６５−４）で定められている特定の要求であり、速やかに応答する必要がある。一例を挙げると、本実施形態では、エンジン水温，エンジン回転数，車速，及びバッテリ電圧などの現在のエンジン状態を表すデータの出力を求める要求や、エンジンＥＣＵ１での故障検出処理の検出結果データ（つまり、故障箇所を表すデータ）の出力を求める要求が、法規サービス要求となっている。
【００５３】
また、上記Ｓ１２０では、受信した要求に含まれている情報のうち、その要求の送信元を表す通信ＩＤ（送信元情報に相当）と、その要求の内容（種別）を表す内容識別コード（識別情報に相当）とから、その要求が特定要求としての法規サービス要求であるか否かを判定する。つまり、通信ＩＤがダイアグスキャンツール１５を示し、且つ、上記内容識別コードが法規サービス要求の内容を示すものであったならば、その要求が法規サービス要求であると判定するようになっている。
【００５４】
そして、上記Ｓ１２０にて、前回要求が法規サービス要求であると判定したならば（Ｓ１２０：ＹＥＳ）、Ｓ１３０に進んで、今回要求（今回受信した要求）が法規サービス要求であるか否かを、上記Ｓ１２０と同様の手順で判定し、今回要求が法規サービス要求でなければ（Ｓ１３０：ＮＯ）、Ｓ１４０に移行して、今回要求に対して応答するのをキャンセルし、そのまま当該要求受信時処理を終了する。
【００５５】
また、上記Ｓ１２０で前回要求が法規サービス要求ではないと判定した場合（Ｓ１２０：ＮＯ）、あるいは、上記Ｓ１３０で今回要求が法規サービス要求であると判定した場合（Ｓ１３０：ＹＥＳ）には、Ｓ１５０に移行して、前回要求に対する応答をキャンセル（即ち、未送信分の応答データの送信を中止）して、Ｓ１６０に進む。一方、上記Ｓ１１０で前回要求の応答中ではないと判定した場合（Ｓ１１０：ＮＯ）には、そのままＳ１６０に進む、つまり、今回要求に対して応答する場合にはＳ１６０へ進むこととなる。
【００５６】
そして、Ｓ１６０では、前述した可変の各パラメータを初期化する。即ち、送信待ち時間ＷＴを０ｍｓに初期化し、応答データの１フレームのデータサイズＤＳを８バイトに初期化し、連続送信フレーム数ＦＮを０に初期化する。尚、本実施形態において、連続送信フレーム数ＦＮ＝０とは、連続送信フレーム数ＦＮが無限大（無制限）という意味であり、換言すれば、前述したフレーム送信の一時中断を行わないという意味である。
【００５７】
次にＳ１７０にて、今回要求の送信元である要求元がダイアグスキャンツール１５であるか否かを判定し、要求元がダイアグスキャンツール１５であれば（Ｓ１７０：ＹＥＳ）、Ｓ１８０に進む。尚、Ｓ１７０では、今回要求に含まれている通信ＩＤがダイアグスキャンツール１５の通信ＩＤであれば、要求元がダイアグスキャンツール１５であると判定する。
【００５８】
そして、Ｓ１８０では、今回要求に含まれている内容識別コードから、その今回要求の要求内容が法規サービス要求であるか否かを判定し、法規サービス要求であると判定した場合には（Ｓ１８０：ＹＥＳ）、Ｓ１９０に進んで、通信処理負荷低減レベルをレベル０に設定する。
【００５９】
尚、通信処理負荷低減レベルとは、応答データを送信するための処理負荷を低減させる段階のことであり、そのレベルの数字が大きいほど、受信要求に対する応答性を低下させて応答データ送信用の処理負荷を大きく低減させることを意味している。
【００６０】
また、上記Ｓ１７０で要求元（今回要求の送信元）がダイアグスキャンツール１５ではないと判定した場合（Ｓ１７０：ＮＯ）、あるいは、上記Ｓ１８０で今回要求の要求内容が法規サービス要求ではないと判定した場合（Ｓ１８０：ＮＯ）には、Ｓ２００に移行する。尚、Ｓ１８０で否定判定される要求（即ち、ダイアグスキャンツール１５から送信されるが法規サービス要求ではない要求）としては、例えば、アクチュエータの強制駆動要求や、エンジンＥＣＵ１の不揮発性メモリに記憶されているデータの書き換え要求などがある。
【００６１】
Ｓ２００では、制御対象機器としてのエンジンを制御するための処理負荷（以下、エンジン制御処理負荷という）が大きい（高い）か否かを判定する。
尚、エンジン制御処理負荷が大きいと判定する条件としては、例えば、エンジン回転数が所定値以上である高回転時、エンジン始動時、変速機の変速時、車両の高速走行時、急加速時などであり、本実施形態では、下記の表１に示す６つの条件のうち、当てはまる項目の点数を足した数値が判定値（例えば５）以上であったら、エンジン制御処理負荷が大きいと判定するようになっている。また、下記表１に記載の条件項目に限らず、例えば、エンジン制御に関連する様々な種類の制御処理のうち、並行して実行される制御処理の数を判定条件としても良い。
【００６２】
【表１】
2005047488.tif 000003
【００６３】
上記Ｓ２００にて、エンジン制御処理負荷が大きくないと判定した場合には（Ｓ２００：ＮＯ）、Ｓ２１０に進んで、当該エンジンＥＣＵ１が接続されている通信ライン８の混雑度が大きい（つまり、通信ライン８が混雑している）か否かを判定する。尚、マイコン１ａは、通信ライン８上に一定時間流れているフレーム数を常時数えており、そのフレーム数がある閾値以上である場合に、混雑度が大きいと判定する。
【００６４】
そして、このＳ２１０で通信ライン８の混雑度が大きくないと判定した場合には（Ｓ２１０：ＮＯ）、Ｓ２２０に進んで、通信処理負荷低減レベルをレベル１に設定する。
また、上記Ｓ２００でエンジン制御処理負荷が大きいと判定した場合（Ｓ２００：ＹＥＳ）、あるいは、上記Ｓ２１０で通信ライン８の混雑度が大きいと判定した場合には（Ｓ２１０：ＹＥＳ）、Ｓ２３０に移行して、通信処理負荷低減レベルをレベル２に設定する。
【００６５】
そして、上記Ｓ１９０，Ｓ２２０，及びＳ２３０の何れかで通信処理負荷低減レベルを設定したならば、Ｓ２４０に移行して、後述する図５の通信処理負荷低減処理を実行する。そして、続くＳ２５０にて、今回要求に対する応答データを作成すると共に、その応答データの１フレーム目（１つ目の送信フレーム）を、現在設定されているデータサイズＤＳで送信フレーム記憶部にセットし、その後、当該要求受信時処理を終了する。尚、送信フレーム記憶部は、マイコン１ａ内のＲＡＭ（図示省略）に設定されている。また、作成される応答データには、要求された実質的な内容の他に、本エンジンＥＣＵ１の通信ＩＤや誤り訂正用の冗長符号など、通信プロトコルに則った付属情報も含まれる。
【００６６】
次に、図５に示すように、上記要求受信時処理（図４）のＳ２４０で通信処理負荷低減処理の実行が開始されると、まずＳ３１０にて、現在設定されている通信処理負荷低減レベルと、今回要求に含まれている通信ＩＤとに応じて、送信待ち時間ＷＴを設定する。
【００６７】
具体的には、図５におけるＳ３１０の枠内に示すように、通信処理負荷低減レベルがレベル０である場合（即ち、今回要求が法規サービス要求である場合）には、送信待ち時間ＷＴを０ｍｓに設定する。
【００６８】
また、通信処理負荷低減レベルがレベル１である場合には、今回要求の通信ＩＤに応じて、その通信ＩＤが制御系通信ライン８に接続された車両制御系の他のＥＣＵ２〜４又はダイアグスキャンツール１５のＩＤであれば、送信待ち時間ＷＴを２０ｍｓに設定し、その通信ＩＤがダイアグスキャンツール１５のＩＤでもなく且つ車両制御系の他のＥＣＵ２〜４のＩＤでもなければ、送信待ち時間ＷＴを２０ｍｓよりも長い時間（この例では５０ｍｓ）に設定する。
【００６９】
また同様に、通信処理負荷低減レベルがレベル２である場合には、今回要求の通信ＩＤに応じて、その通信ＩＤが車両制御系の他のＥＣＵ２〜４又はダイアグスキャンツール１５のＩＤであれば、送信待ち時間ＷＴを５０ｍｓに設定し、その通信ＩＤがダイアグスキャンツール１５のＩＤでもなく且つ車両制御系の他のＥＣＵ２〜４のＩＤでもなければ、送信待ち時間ＷＴを５０ｍｓよりも更に長い時間（この例では１００ｍｓ）に設定する。
【００７０】
つまり、通信処理負荷低減レベルがレベル０に設定される法規サービス要求については、それを受信してから応答データの送信を開始するまでの時間が例えば５０ｍｓ以内といった具合に法規で定められており、ダイアグスキャンツール１５へ応答データを最短時間で送る必要があるため、送信待ち時間ＷＴを０に設定しているが、法規サービス要求以外の要求については、送信待ち時間ＷＴを０以外に設定して処理負荷を落とすようにしている。また、車両制御系の他のＥＣＵ２〜４からの要求に対してよりも、ナビＥＣＵ５からの要求（車両情報管理センター１１からの無線での要求も含む）やボデーＥＣＵ６からの要求に対しての方が、送信待ち時間ＷＴを長い時間に設定しているのは、元々、制御系通信ライン８に接続された装置と比べて、マルチメディア系通信ライン９やボデー系通信ライン１０に接続された装置の方が通信処理速度が遅いため、待ち時間ＷＴを長くしても問題が無いからである。
【００７１】
次に、続くＳ３２０にて、現在設定されている通信処理負荷低減レベルに応じて、１フレーム当たりに送信するデータサイズＤＳを設定する。
具体的には、図５におけるＳ３２０の枠内に示すように、通信処理負荷低減レベルがレベル０である場合には、データサイズＤＳを初期値と同じ８バイトに設定するが、通信処理負荷低減レベルがレベル１である場合には、データサイズＤＳを初期値よりも小さい値（この例では６バイト）に設定する。また、通信処理負荷低減レベルがレベル２である場合には、データサイズＤＳを更に小さい値（この例では４バイト）に設定する。
【００７２】
そして更に、続くＳ３３０にて、現在設定されている通信処理負荷低減レベルに応じて、連続送信フレーム数ＦＮを設定する。
具体的には、図５におけるＳ３３０の枠内に示すように、通信処理負荷低減レベルがレベル０である場合には、連続送信フレーム数ＦＮを初期値と同じ０（＝無制限）に設定するが、通信処理負荷低減レベルがレベル１である場合には、連続送信フレーム数ＦＮを０ではない自然数（この例では５０）に設定する。また、通信処理負荷低減レベルがレベル２である場合には、連続送信フレーム数ＦＮを５０よりも小さい２５に設定する。
【００７３】
つまり、通信処理負荷低減レベルがレベル０に設定される法規サービス要求については、応答データの送信を完了するまでの所要時間が法規で定められているため、データサイズＤＳをできるだけ大きい値に設定すると共に、連続送信フレーム数ＦＮを０にして、フレーム送信の一時中断を行わないようにしているが、法規サービス要求以外の要求については、通信処理負荷低減レベルの値が大きい場合ほど、データサイズＤＳを小さい値に設定すると共に、連続送信フレーム数ＦＮを０以外の小さい値に設定して、応答データを送信するための処理負荷を大きく低減するようにしている。
【００７４】
次に、続くＳ３４０にて、送信間隔カウンタｔに、現在設定されている送信待ち時間ＷＴの値をセットする。尚、送信間隔カウンタｔは、要求を受信してから応答データの１フレーム目の送信を開始するまでの待ち時間と、各フレームの送信間隔とを計時するためのカウンタであり、後述する図７のエンジン処理負荷・通信ラインの監視処理におけるＳ６００で減算される。
【００７５】
そして更に、続くＳ３５０にて、連続送信フレーム数カウンタｆと、連続送信待ち時間カウンタｆｔとの各々に、初期値としての０をセットし、その後、当該通信処理負荷低減処理を終了する。尚、連続送信フレーム数カウンタｆは、送信したフレームの数を計数するためのカウンタであり、後述する図６のフレーム送信処理におけるＳ４４５でカウントアップされる。また、連続送信待ち時間カウンタｆｔは、図２に示した連続送信待ち時間（フレームを連続送信フレーム数ＦＮだけ送信する毎に、フレームの送信を一時休止する時間）を計時するためのカウンタであり、後述する図７のエンジン処理負荷・通信ラインの監視処理におけるＳ６１０で減算される。
【００７６】
次に、図６に示すように、エンジンＥＣＵ１において、前述した４ｍｓ毎のタイミング通知Ａに伴いマイコン１ａがフレーム送信処理の実行を開始すると、まずＳ４１０にて、応答データの１フレーム分である送信フレームが送信フレーム記憶部にセットされているか否かを判定する。
【００７７】
そして、送信フレームがセットされていなければ（Ｓ４１０：ＮＯ）、そのまま当該フレーム送信処理を終了するが、送信フレームがセットされていれば（Ｓ４１０：ＹＥＳ）、Ｓ４２０に進んで、現在設定されている連続送信フレーム数ＦＮが０であるか否かを判定し、ＦＮ＝０であれば（Ｓ４２０：ＹＥＳ）、Ｓ４３０に進む。
【００７８】
Ｓ４３０では、送信間隔カウンタｔの値が０であるか否かを判定し、０でなければ（Ｓ４３０：ＮＯ）、そのまま当該フレーム送信処理を終了するが、送信間隔カウンタｔの値が０であれば（Ｓ４３０：ＹＥＳ）、Ｓ４４０に進んで、送信フレーム記憶部にセットされている送信フレーム（１フレーム）を送信するための処理を行う。つまり、このＳ４４０では、送受信部としての処理に対する送信要求を出力する。すると、送受信部としての処理が起動されて、送信フレーム記憶部にセットされている１フレームが送信される。
【００７９】
そして、続くＳ４４３にて、現在設定されている連続送信フレーム数ＦＮが０であるか否かを再び判定し、ＦＮ＝０であれば（Ｓ４４３：ＹＥＳ）、そのままＳ４５０に移行するが、ＦＮ＝０でなければ（Ｓ４４３：ＮＯ）、Ｓ４４５にて連続送信フレーム数カウンタｆを１カウントアップした後、Ｓ４５０に進む。
【００８０】
Ｓ４５０では、送信間隔カウンタｔに、現在設定されている送信待ち時間ＷＴをセットする。そして、続くＳ４６０にて、次の送信フレーム（即ち、応答データの次の１フレーム）を、現在設定されているデータサイズＤＳで送信フレーム記憶部にセットした後、当該フレーム送信処理を終了する。
【００８１】
一方、上記Ｓ４２０にて、現在設定されている連続送信フレーム数ＦＮが０ではないと判定した場合には（Ｓ４２０：ＮＯ）、Ｓ４７０に移行する。
Ｓ４７０では、連続送信待ち時間カウンタｆｔの値が０であるか否かを判定し、０でなければ（Ｓ４７０：ＮＯ）、そのまま当該フレーム送信処理を終了するが、連続送信待ち時間カウンタｆｔの値が０であれば（Ｓ４７０：ＹＥＳ）、続くＳ４８０にて、連続送信フレーム数カウンタｆの値が、現在設定されている連続送信フレーム数ＦＮ未満であるか否かを判定する。そして、連続送信フレーム数カウンタｆの値が連続送信フレーム数ＦＮ未満であれば（Ｓ４８０：ＹＥＳ）、前述のＳ４３０へ移行する。
【００８２】
また、上記Ｓ４８０にて、連続送信フレーム数カウンタｆの値が連続送信フレーム数ＦＮ未満ではない（ｆ≧ＦＮ）と否定判定した場合には（Ｓ４８０：ＮＯ）、Ｓ５００に移行して、連続送信待ち時間カウンタｆｔに一定の連続送信待ち時間（この例では７５ｍｓ）をセットする。そして、続くＳ５０５にて、連続送信フレーム数カウンタｆに０をセットし、その後、当該フレーム送信処理を終了する。
【００８３】
次に、図７に示すように、エンジンＥＣＵ１において、前述した４ｍｓ毎のタイミング通知Ｂに伴いマイコン１ａがエンジン処理負荷・通信ラインの監視処理の実行を開始すると、まずＳ５１０にて、図６のＳ４１０と同様に、送信フレームが送信フレーム記憶部にセットされているか否かを判定する。
【００８４】
そして、送信フレームがセットされていなければ（Ｓ５１０：ＮＯ）、そのまま当該エンジン処理負荷・通信ラインの監視処理を終了するが、送信フレームがセットされていれば（Ｓ５１０：ＹＥＳ）、Ｓ５２０に進む。
【００８５】
Ｓ５２０では、現在設定されている通信処理負荷低減レベルがレベル０であるか否かを判定し、レベル０であれば（Ｓ５２０：ＹＥＳ）、そのまま当該エンジン処理負荷・通信ラインの監視処理を終了するが、レベル０でなければ（Ｓ５２０：ＮＯ）、Ｓ５３０に進み、図４のＳ２００と同じ手順で、エンジン制御処理負荷が大きいか否かを判定する。
【００８６】
ここで、エンジン制御処理負荷が大きくないと判定した場合には（Ｓ５３０：ＮＯ）、Ｓ５４０に進み、図４のＳ２１０と同じ手順で、通信ライン８の混雑度が大きいか否かを判定する。
【００８７】
そして、このＳ５４０で通信ライン８の混雑度が大きくないと判定した場合には（Ｓ５４０：ＮＯ）、Ｓ５５０に進んで、通信処理負荷低減レベルをレベル１に設定する。また、上記Ｓ５３０でエンジン制御処理負荷が大きいと判定した場合（Ｓ５３０：ＹＥＳ）、あるいは、上記Ｓ５４０で通信ライン８の混雑度が大きいと判定した場合には（Ｓ５４０：ＹＥＳ）、Ｓ５６０に移行して、通信処理負荷低減レベルをレベル２に設定する。
【００８８】
つまり、Ｓ５３０〜Ｓ５６０では、図４のＳ２００〜Ｓ２３０と同じ処理を行っている。
そして、上記Ｓ５５０とＳ５６０との何れかで通信処理負荷低減レベルを設定し直したならば、Ｓ５７０に移行して、図５の通信処理負荷低減処理とほぼ同様の通信処理負荷低減処理を実行する。尚、このＳ５７０で実行される通信処理負荷低減処理は、図５の通信処理負荷低減処理からＳ３４０とＳ３５０の各処理を削除した処理である。
【００８９】
次に、続くＳ５８０にて、連続送信待ち時間カウンタｆｔの値が０であるか否かを判定し、０であれば（Ｓ５８０：ＹＥＳ）、Ｓ５９０に進んで、送信間隔カウンタｔの値が０であるか否かを判定する。
【００９０】
そして、送信間隔カウンタｔの値が０であれば（Ｓ５９０：ＹＥＳ）、そのまま当該エンジン処理負荷・通信ラインの監視処理を終了するが、送信間隔カウンタｔの値が０でなければ（Ｓ５９０：ＮＯ）、Ｓ６００に進んで、送信間隔カウンタｔの値から本処理の実行周期である４ｍｓに相当する値を減算し、その後、本処理を終了する。
【００９１】
また、上記Ｓ５８０にて、連続送信待ち時間カウンタｆｔの値が０ではないと判定した場合には（Ｓ５８０：ＮＯ）、Ｓ６１０に移行して、連続送信待ち時間カウンタｆｔの値から本処理の実行周期である４ｍｓに相当する値を減算し、その後、本処理を終了する。
【００９２】
このような本実施形態のエンジンＥＣＵ１では、他の装置（他のＥＣＵ２〜６又はダイアグスキャンツール１５）からの要求を受信すると、図４の要求受信時処理が実行され、その要求受信時処理中で今回要求に対して応答すると判断された場合（つまり、Ｓ１４０の処理を行うことなくＳ１６０へ進んだ場合）には、図４のＳ２４０で実行される図５のＳ３４０及びＳ３５０により、送信間隔カウンタｔに送信待ち時間ＷＴの値がセットされると共に、連続送信フレーム数カウンタｆと連続送信待ち時間カウンタｆｔとの各々に０がセットされ、更に、図４のＳ２５０にて、今回要求に対する応答データの１フレーム目がデータサイズＤＳで送信フレーム記憶部にセットされる。
【００９３】
ここで、連続送信フレーム数ＦＮが０以外の値に設定されている（つまり、通信処理負荷低減レベルがレベル０以外に設定されている）とすると、４ｍｓ毎の図７の処理では、Ｓ５８０で肯定判定されて、Ｓ５９０及びＳ６００の処理により、送信間隔カウンタｔの値が４ｍｓ毎に０になるまで減算されていくこととなる。
【００９４】
そして、４ｍｓ毎の図６の処理では、Ｓ４１０：ＹＥＳ→Ｓ４２０：ＮＯ→Ｓ４７０：ＹＥＳ→Ｓ４８０：ＹＥＳ→Ｓ４３０の順に処理が進み、Ｓ４３０にて送信間隔カウンタｔの値が０になっていると判定されたときに、送信フレーム記憶部にセットされている１フレームの送信（Ｓ４４０）と、連続送信フレーム数カウンタｆの１カウントアップ（Ｓ４４５）とが行われ、更に、次のフレームを送信するための準備として、送信間隔カウンタｔへの送信待ち時間ＷＴの再セット（Ｓ４５０）と、次の送信フレームのデータサイズＤＳでの送信フレーム記憶部へのセット（Ｓ４６０）とが行われる。
【００９５】
このため、他の装置からの要求が受信されてから図６におけるＳ４４０の処理が最初に実行されたときに、応答データの１フレーム目が送信されるが、その１フレーム目の送信は、図２に示したように、他の装置からの要求が受信されてから、ほぼ送信待ち時間ＷＴが経過した時点で行われることとなる。
【００９６】
また以後は、図７におけるＳ５９０及びＳ６００の処理と、図６におけるＳ４１０，Ｓ４２０，Ｓ４７０，Ｓ４８０，及びＳ４３０〜Ｓ４６０の処理とが繰り返されることにより、応答データの２フレーム目からＦＮフレーム目までが、送信待ち時間ＷＴ毎に順次送信されることとなる。
【００９７】
そして、ＦＮ番目のフレームが送信されると、次回の図６の処理では、Ｓ４８０で否定判定されて、Ｓ５００及びＳ５０５の処理により、連続送信待ち時間カウンタｆｔに連続送信待ち時間（＝７５ｍｓ）がセットされると共に、連続送信フレーム数カウンタｆが０にリセットされる。
【００９８】
すると、その後、図７の処理では、Ｓ５８０で否定判定されて、Ｓ６１０の処理により、連続送信待ち時間カウンタｆｔの値が４ｍｓ毎に０になるまで減算されていくこととなる。そして、図６の処理では、連続送信待ち時間カウンタｆｔの値が０になるまでの間、Ｓ４１０：ＹＥＳ→Ｓ４２０：ＮＯ→Ｓ４７０：ＮＯ→終了の順に処理が進むこととなり、フレームの送信が実施されなくなる。
【００９９】
このため、図２に示したように、ＦＮ番目のフレームが送信された後は、連続送信待ち時間カウンタｆｔによって計時される連続送信待ち時間が経過するまで、フレームの送信が休止される。
【０１００】
そして、連続送信待ち時間が経過して連続送信待ち時間カウンタｆｔの値が０になると、図６の処理では、再び、Ｓ４１０：ＹＥＳ→Ｓ４２０：ＮＯ→Ｓ４７０：ＹＥＳ→Ｓ４８０：ＹＥＳ→Ｓ４３０の順に処理が進むこととなり、また、図７の処理では、再びＳ５８０で肯定判定されて、Ｓ５９０及びＳ６００の処理により送信間隔カウンタｔの値が４ｍｓ毎に０になるまで減算されていくこととなる。
【０１０１】
よって、図２に示すように、連続送信待ち時間が経過してから更に送信待ち時間ＷＴが経過すると、図６におけるＳ４４０の処理により、（ＦＮ＋１）番目のフレームが送信される。
【０１０２】
そして以後は、再び送信待ち時間ＷＴ毎に応答データの各フレームが順次送信されることとなり、こうした処理の繰り返しにより、フレームを連続送信フレーム数ＦＮだけ送信する毎に、連続送信待ち時間だけフレームの送信を中断する、という動作が行われることとなる。尚、応答データの総フレーム数が連続送信フレーム数ＦＮ以下であれば、図６のＳ４８０で否定判定される前に応答データの送信が完了するため、連続送信待ち時間だけフレームの送信を中断する事象は起こらない。
【０１０３】
また、連続送信フレーム数ＦＮが０に設定されている場合（つまり、通信処理負荷低減レベルがレベル０に設定されている場合）には、図６のＳ４２０で肯定判定されるため、同図６におけるＳ４７０〜Ｓ５０５の処理が行われない。このため、フレーム送信の一時中断をすることなく、図６のＳ４３０で送信間隔カウンタｔの値が０になっていると判定される毎に、各フレームが順番に送信されることとなる。
【０１０４】
そして、通信処理負荷低減レベルがレベル０の場合には、送信待ち時間ＷＴが０ｍｓに設定されると共に、図７のＳ５３０以降がスキップされるため、送信間隔カウンタｔの値は０のままになる。
【０１０５】
よって、この場合には、図６の処理が実行される４ｍｓ毎に、各フレームが順次送信されることとなり、その結果、１フレーム目の送信を開始するまでの待ち時間が４ｍｓ未満となり、各フレームの送信間隔が４ｍｓとなる。
【０１０６】
以上のような本実施形態のエンジンＥＣＵ１では、全ての要求に対して同じ応答性で応答するのではなく、図４のＳ１７０〜Ｓ２４０及びそのＳ２４０で実行される図５のＳ３１０〜Ｓ３３０の処理により、法規サービス要求以外の要求に応答する場合（即ち、通信処理負荷低減レベルがレベル１又はレベル２に設定された場合）よりも、法規サービス要求に対して応答する際（即ち、通信処理負荷低減レベルがレベル０に設定された場合）の方が、その要求に対する応答性が高くなるように、１フレーム目の送信を開始するまでの時間と各フレームの送信間隔と決める送信待ち時間ＷＴを小さい値に設定すると共に、１フレーム当たりのデータサイズＤＳを大きい値に設定し、更に、連続送信フレーム数ＦＮを大きい値（本実施形態では無制限）に設定するようにしている。
【０１０７】
このため、本実施形態のエンジンＥＣＵ１によれば、法規サービス要求に対して速やかに応答することと、マイコン１ａの処理負荷を低減することとを、両立させることができる。即ち、法規サービス要求に対しては、高い応答性で応答データを送信することができ、また、法規サービス要求以外の要求に対しては、法規サービス要求に対してよりも低い応答性で応答データを送信することとなり、応答データ送信のための処理負荷が低減され、その結果、エンジンの制御に支障をきたすことが回避されて、高性能なマイコンを用いずに済む。
【０１０８】
しかも、本実施形態のエンジンＥＣＵ１では、図４のＳ２００〜Ｓ２４０及びそのＳ２４０で実行される図５のＳ３１０〜Ｓ３３０の処理と、図７のＳ５２０〜Ｓ５７０の処理とにより、法規サービス要求以外の要求に応答する場合には、エンジン制御処理負荷と、通信ライン８の混雑度と、要求の送信元とに応じて、エンジン制御処理負荷が大きい場合ほど、また、通信ライン８の混雑度が大きい場合ほど、また、要求の送信元が低い通信処理速度の装置である場合ほど、受信要求に対する応答性が低くなるように、送信待ち時間ＷＴを大きい値に設定するようにしている。そして更に、法規サービス要求以外の要求に応答する場合には、エンジン制御処理負荷と通信ライン８の混雑度とに応じて、エンジン制御処理負荷が大きい場合ほど、また、通信ライン８の混雑度が大きい場合ほど、受信要求に対する応答性が低くなるように、１フレーム当たりのデータサイズＤＳと連続送信フレーム数ＦＮとを小さい値に設定するようにしている。
【０１０９】
特に、本実施形態では、図７のＳ５２０〜Ｓ５７０の処理が４ｍｓ毎に実行されるため、応答データの各フレームを送信している応答期間中でも、送信待ち時間ＷＴ（この場合は送信間隔）とデータサイズＤＳと連続送信フレーム数ＦＮとが、エンジン制御処理負荷と通信ライン８の混雑度とに応じて適宜変更されることとなる。
【０１１０】
このため、応答データを送信するための処理負荷を車両の状況に応じて適切に低減させて、エンジンの制御に支障が生じることを一層確実に回避することができると共に、通信ライン８の混雑度を過剰にしてしまうことを防止することができる。
【０１１１】
また更に、本実施形態のＥＣＵ１では、ある要求に対して応答している期間中に別の要求を受信した場合に（Ｓ１１０：ＹＥＳ）、そのとき応答中の要求が法規サービス要求であり（Ｓ１２０：ＹＥＳ）、且つ、今回受信した要求が法規サービス要求以外の要求であると判定したならば（Ｓ１３０：ＮＯ）、今回受信した要求に対して応答するのをキャンセルするようにしている（Ｓ１４０）。また、そうでなければ（Ｓ１２０：ＮＯ又はＳ１３０：ＹＥＳ）、未送信分の応答データの送信を中止して、今回受信した新たな要求に対して応答を開始するようにしている（Ｓ１５０）。
【０１１２】
このため、応答データを送信するための処理負荷をむやみに増加させることなく、優先度の高い法規サービス要求に対して確実に応答することができる。
尚、本実施形態では、図４のＳ１２０，Ｓ１３０，Ｓ１７０及びＳ１８０が、判定手段としての処理に相当し、図４のＳ１９０〜Ｓ２４０と、そのＳ２４０で実行される図５のＳ３１０〜Ｓ３３０と、図７のＳ５２０〜Ｓ５７０とが、変更手段としての処理に相当している。また、図４のＳ１４０が、応答キャンセル手段としての処理に相当している。
【０１１３】
以上、本発明の一実施形態について説明したが、本発明は、種々の形態を採り得ることは言うまでもない。
例えば、上記実施形態では、法規サービス要求以外の要求に応答する場合には、通信処理負荷低減レベルを必ずレベル１かレベル２に設定して、法規サービス要求に応答する場合よりも応答性を低下させるようにしていたが、次に述べる「第１変形例」又は「第２変形例」のように変形しても良い。
【０１１４】
［第１変形例］
まず、第１変形例では、マイコン１ａが、図４の要求受信時処理に代えて、図８の要求受信時処理を実行する。
【０１１５】
そして、図８の要求受信時処理では、図４の要求受信時処理と比較すると、Ｓ１６０とＳ１７０との間に、Ｓ１６５が追加されている。
具体的には、Ｓ１６０の処理を行った後、Ｓ１６５に進んで、通信ライン８が混雑度大の状態である（つまり、通信ライン８が混雑している）か否かを判定する。尚、既述したように、マイコン１ａは、通信ライン８上に流れている一定時間当たりのフレーム数を常時数えており、その一定時間当たりのフレーム数が予め定められた閾値Ｎ１以上である場合に、混雑度が特定の度合いよりも大きい混雑度大の状態であると判定する。
【０１１６】
そして、このＳ１６５で通信ライン８が混雑度大の状態であると判定した場合には（Ｓ１６５：ＹＥＳ）、Ｓ１７０へ進むが、このＳ１６５で通信ライン８が混雑度大の状態ではないと判定した場合には（Ｓ１６５：ＮＯ）、Ｓ１７０，Ｓ１８０の判定を行うことなく、そのままＳ１９０に移行して、通信処理負荷低減レベルをレベル０に設定する。
【０１１７】
つまり、この第１変形例では、通信ライン８が混雑していない場合には、あえて通信負荷を下げる必要がないという考えから、要求を受信した際に、まず、通信ライン８の混雑度を判定し（Ｓ１６５）、通信ライン８が混雑度大の場合にだけ（Ｓ１６０：ＹＥＳ）、今回要求が特定要求としての法規サービス要求か否かを判定し（Ｓ１７０，Ｓ１８０）、その判定結果に応じて、今回要求に対する応答性を差別化するようにしており、特に、通信ライン８が混雑度大でない場合には（Ｓ１６５：ＮＯ）、今回要求が法規サービス要求であるか否かに拘わらず、通信処理負荷低減レベルを一律レベル０に設定し（Ｓ１９０）、これにより、法規サービス要求以外の要求に対しても、法規サービス要求に対する応答性と同じ応答性で応答データを送信できるようにしている。
【０１１８】
よって、このような第１変形例によれば、通信ライン８が混雑していない場合には、必要以上に送信データの応答性を下げることがなく、全てのデータを高い応答性で送信することができるため、通信ラインに接続された各ＥＣＵでの制御性を向上させることができる。
【０１１９】
尚、この第１変形例の場合、図８のＳ２１０では、通信ライン８上に流れている一定時間当たりのフレーム数が、上記Ｓ１６５での閾値Ｎ１よりも大きい第２の閾値Ｎ２以上であるか否かを判定し、その閾値Ｎ２以上の場合に、混雑度が大きいと判定するように構成すれば良い。つまり、図８の第１変形例において、Ｓ２１０へ進むのは、通信ライン８上に流れている一定時間当たりのフレーム数が閾値Ｎ１以上となっている場合であるため、一定時間当たりのフレーム数が、その閾値Ｎ１よりも更に大きい第２の閾値Ｎ２以上か否かで、通信処理負荷低減レベルをレベル１又はレベル２に設定するのである。
【０１２０】
［第２変形例］
次に、第２変形例では、第１変形例と比較すると、マイコン１ａが、図８の要求受信時処理に代えて、図９の要求受信時処理を実行する。
【０１２１】
そして、図９の要求受信時処理では、図８の要求受信時処理と比較すると、Ｓ２００、Ｓ２１０及びＳ２３０が削除されている。
具体的には、Ｓ１６５で通信ライン８が混雑度大の状態ではないと判定した場合には（Ｓ１６５：ＮＯ）、第１変形例と同様に、Ｓ１７０，Ｓ１８０の判定を行うことなく、そのままＳ１９０に移行して、通信処理負荷低減レベルをレベル０に設定する。
【０１２２】
また、Ｓ１６５で通信ライン８が混雑度大の状態であると判定した場合には（Ｓ１６５：ＹＥＳ）、Ｓ１７０に進んで、今回要求の送信元である要求元がダイアグスキャンツール１５であるか否かを判定し、要求元がダイアグスキャンツール１５であれば（Ｓ１７０：ＹＥＳ）、次のＳ１８０にて、今回要求に含まれている内容識別コードから、その今回要求の要求内容が法規サービス要求であるか否かを判定する。そして、法規サービス要求であると判定した場合にも（Ｓ１８０：ＹＥＳ）、Ｓ１９０に進んで、通信処理負荷低減レベルをレベル０に設定する。
【０１２３】
一方、上記Ｓ１７０で要求元がダイアグスキャンツール１５ではないと判定した場合（Ｓ１７０：ＮＯ）、あるいは、上記Ｓ１８０で今回要求の要求内容が法規サービス要求ではないと判定した場合（Ｓ１８０：ＮＯ）には、Ｓ２２０に移行して、通信処理負荷低減レベルをレベル１に設定する。
【０１２４】
つまり、この第２変形例においても、第１変形例と同様に、要求を受信した際に、まず、通信ライン８の混雑度を判定し（Ｓ１６５）、通信ライン８が混雑度大の場合にだけ（Ｓ１６０：ＹＥＳ）、今回要求が法規サービス要求か否かを判定して（Ｓ１７０，Ｓ１８０）、今回要求に対する応答性を差別化するようにしているが、通信ライン８が混雑していない場合（Ｓ１６５：ＮＯ）、あるいは、通信ラインが混雑しているが今回要求が法規サービス要求であった場合（ＳＳ１８０：ＹＥＳ）には、通信処理負荷低減レベルをレベル０に設定し、通信ラインが混雑しており且つ今回要求が法規サービス要求以外であった場合には（Ｓ１７０：ＮＯ又はＳ１８０：ＮＯ）には、通信処理負荷低減レベルをレベル１に設定する、といった具合に、通信処理負荷低減レベルをレベル０とレベル１との２通りのみに設定するようにしている。
【０１２５】
そして、このような第２変形例によっても、第１変形例と同様に、通信ライン８が混雑していない場合には、要求の種別を区別することなく、全ての要求に対する応答データを高い応答性で送信することができるため、通信ラインに接続された各ＥＣＵでの制御性を向上させることができる。
【０１２６】
尚、この第２変形例では、通信処理負荷低減レベルをレベル０とレベル１との２通りのみに設定しているが、例えば、通信ライン８の混雑度を、Ｓ１６５で混雑度大であると判定される度合いよりも大きい範囲において、大、中、小の３段階に分け、Ｓ２２０では、通信処理負荷低減レベルを、そのときの通信ライン８の混雑度に応じたレベル（大：レベル２、中：レベル１、小：レベル０）に設定するように構成しても良い。つまり、この場合、図８に示した第１変形例の要求受信時処理からＳ２００を削除したものと同様の変形例となる。
【０１２７】
また、上記第１変形例（図８）及び第２変形例（図９）では、Ｓ１６５の処理が、混雑度判定手段又は混雑度判定処理に相当しており、Ｓ１７０及びＳ１８０の処理が、要求判定処理に相当している。
【０１２８】
一方、上記実施形態及び各変形例では、通信ライン８の混雑度を、通信ライン８上に流れている一定時間当たりのフレーム数で判断していたが、通信ライン８の混雑度として扱う物理量としては、通信ライン８上に流れている一定時間当たりのデータ量に相当するものであれば良く、例えば一定時間当たりのビット数でも良い。
【０１２９】
また例えば、上記実施形態及び各変形例では、１フレーム目の送信を開始するまでの待ち時間（即ち、応答データの送信を開始するまでの待ち時間）と、各フレームの送信間隔とが、送信待ち時間ＷＴという共通のパラメータで決定されるように構成されていたが、１フレーム目の送信を開始するまでの待ち時間と各フレームの送信間隔とを、別々に可変設定するように構成しても良い。
【０１３０】
また、上記実施形態及び各変形例では、応答データを送信する送信処理の実施条件として、１フレーム目の送信を開始するまでの待ち時間と、各フレームの送信間隔と、１フレーム当たりのデータサイズＤＳと、連続送信フレーム数ＦＮとを、変更するようにしたが、それらの内の何れかを変更するように構成したり、他の条件（例えば、連続送信待ち時間）を変更するように構成しても良い。
【０１３１】
また、上記実施形態において、法規サービス要求に対して応答する場合にも、エンジン制御処理負荷と通信ライン８の混雑度との両方又は一方に応じて、１フレーム目の送信を開始するまでの待ち時間と、各フレームの送信間隔と、データサイズＤＳと、連続送信フレーム数ＦＮとの、少なくとも何れか１つを変更するように構成しても良い。
【０１３２】
また、上記実施形態及び各変形例では、車両に接続されたダイアグスキャンツール１５から送信される各種要求のうちの一部（エンジン状態を表すデータの出力を求める要求や、故障検出処理の検出結果データの出力を求める要求など）が、それを受信してから応答データの送信を開始するまでの時間や、その応答データの送信を完了するまでの所要時間が法規で定められている法規サービス要求となっており、そのダイアグスキャンツール１５から送信される法規サービス要求に対して、車両の各種ＥＣＵが応答する形態であったが、例えば、図１０に示すように、そのようなダイアグスキャンツールを車両に接続することなく、車両の外部からとして例えば車両情報管理センター１１から上記の法規サービス要求が送信される車両制御システムであっても良い。
【０１３３】
つまり、ダイアグスキャンツールを車両に接続して故障検出処理の検出結果データ（いわゆるダイアグコード）などを読み出すのでなく、車両外部としてのセンター（この例では車両情報管理センター１１）と車両との間で、アンテナ１２，１４を介した無線通信により、法規サービス要求の受信とそれに対する応答とを実施するシステムであっても良い。
【０１３４】
尚、この場合、車両情報管理センター１１から無線送信される要求は、ナビＥＣＵ５が、アンテナ１２及び通信部１３によって受信することとなる。そして、ナビＥＣＵ５は、その受信した要求に、車両情報管理センター１１の通信ＩＤと、その要求の内容を表す内容識別コードとを付加して通信ライン９へ送出する。すると、その車両情報管理センター１１からの要求は、通信ライン９→ゲートウェイＥＣＵ７→通信ライン８を経由して、エンジンＥＣＵ１に受信されることとなる。つまり、ナビＥＣＵ５は、車両情報管理センター１１から受信した要求を、当該ナビＥＣＵ５自身が出す要求とは区別して、通信ライン９へ送出するのである。
【０１３５】
そして、この場合、エンジンＥＣＵ１のマイコン１ａは、前述した実施形態又は各変形例の説明において、「ダイアグスキャンツール１５」を「車両情報管理センター１１」に読み替えた内容の処理を実行すれば良い。また、車両情報管理センター１１からの要求に対するエンジンＥＣＵ１からの応答データは、「エンジンＥＣＵ１→通信ライン８→ゲートウェイＥＣＵ７→通信ライン９→ナビＥＣＵ５→アンテナ１２及び通信部１３→車両情報管理センター１１」の順序で、車両情報センター１１へと無線送信されるように構成すれば良い。
【０１３６】
一方、本発明は、エンジン以外の機器を制御するＥＣＵに対しても同様に適用することができる。
【図面の簡単な説明】
【０１３７】
【図１】実施形態のエンジンＥＣＵが１つのノードとなる車両内ＬＡＮの構成を表す構成図である。
【図２】エンジンＥＣＵが他のＥＣＵ又はダイアグスキャンツールからの要求に対して応答データを送信する際の動作概要を表す説明図である。
【図３】エンジンＥＣＵが他のＥＣＵ又はダイアグスキャンツールからの要求に対して応答する際の処理の流れを示す図である。
【図４】エンジンＥＣＵで実行される要求受信時処理を表すフローチャートである。
【図５】図４のＳ２４０で実行される通信処理負荷低減処理を表すフローチャートである。
【図６】エンジンＥＣＵで実行されるフレーム送信処理を表すフローチャートである。
【図７】エンジンＥＣＵで実行されるエンジン処理負荷・通信ラインの監視処理を表すフローチャートである。
【図８】第１変形例の要求受信時処理を表すフローチャートである。
【図９】第２変形例の要求受信時処理を表すフローチャートである。
【図１０】他の変形例の構成を表す構成図である。
【符号の説明】
【０１３８】
１…エンジンＥＣＵ、１ａ…マイコン、２…ＥＣＴ・ＥＣＵ、３…姿勢制御ＥＣＵ、４…車間制御ＥＣＵ、５…ナビＥＣＵ、６…ボデーＥＣＵ、７…ゲートウェイＥＣＵ、８…制御系通信ライン、９…マルチメディア系通信ライン、１０…ボデー系通信ライン、１１…車両情報管理センター、１２，１４…アンテナ、１３…通信部、１５…ダイアグスキャンツール（診断装置）
【図１】
2005047488.tif 000004
【図２】
2005047488.tif 000005
【図３】
2005047488.tif 000006
【図４】
2005047488.tif 000007
【図５】
2005047488.tif 000008
【図６】
2005047488.tif 000009
【図７】
2005047488.tif 000010
【図８】
2005047488.tif 000011
【図９】
2005047488.tif 000012
【図１０】
2005047488.tif 000013