(57)【要約】【課題】通信異常診断の精度を高めること。【解決手段】エンジンＥＣＵがタイムスタンプＴを載せたテスト信号を診断対象のＥＣＵに送信する（Ｓ１３０）。テスト信号の返信である対応信号を受信したかを判断する（Ｓ１４０）。受信していないと（Ｓ１４０ＮＯ）タイムアウトしたかを判断する（Ｓ１５０）。タイムアウトしていないと（Ｓ１５０ＮＯ）Ｓ１４０に戻る。対応信号を受信すると（Ｓ１４０ＹＥＳ）直前のテスト信号のタイムスタンプＴと対応信号のタイムスタンプＴとが一致するかを判断する（Ｓ１６０）。一致しないと（Ｓ１６０ＮＯ）Ｓ１４０に戻る。タイムアウトすると（Ｓ１５０ＹＥＳ）エラーカウンタＥに１を足す（Ｓ１７０）。テスト信号送信の度にタイムスタンプＴを１増やす（Ｓ１２０）。タイムスタンプＴが規定回数になると（Ｓ１７５）Ｅ／Ｔに基づいて通信異常を診断する（Ｓ１８０〜Ｓ１９０）。【選択図】図３
2011040886.tif 000002
【特許請求の範囲】
【請求項１】
通信装置から所定周期で送信されてくる制御データ信号の監視をする診断装置であって、
当該診断装置との通信異常が疑われる通信装置を前記監視に基づいて検出すると、互いに識別できる複数のテスト信号を、前記通信異常が疑われる通信装置に送信するテスト信号送信手段と、
前記テスト信号送信手段によって送信された複数のテスト信号の何れに対応するかが識別できる対応信号であって、前記テスト信号の送信先の通信装置から送信されてくるべき対応信号それぞれについて、対応する前記テスト信号の送信時から所定時間以内に受信したかを判定する判定手段と、
前記判定手段の複数の判定結果に基づいて、前記テスト信号の送信先の通信装置との通信異常を診断する診断手段とを備える
ことを特徴とする診断装置。
【請求項２】
通信装置から所定周期で送信されてくる制御データ信号の監視をする診断装置であって、
当該診断装置との通信異常が疑われる通信装置を前記監視に基づいて検出すると、前記制御データ信号を送信する通信装置に、診断の開始を予告する開始信号を送信する開始信号送信手段と、
前記開始信号に対する返信を受信した場合、互いに識別できる複数のテスト信号をその返信元の通信装置に送信するテスト信号送信手段と、
前記テスト信号送信手段によって送信された複数のテスト信号の何れに対応するかが識別できる対応信号であって、前記テスト信号の送信先の通信装置から送信されてくるべき対応信号それぞれについて、対応する前記テスト信号の送信時から所定時間以内に受信したかを判定する判定手段と、
前記判定手段の複数の判定結果に基づいて、前記テスト信号の送信先の通信装置との通信異常を診断する診断手段とを備える
ことを特徴とする診断装置。
【請求項３】
前記開始信号送信手段は、前記開始信号を複数回送信する
ことを特徴とする請求項２の診断装置。
【請求項４】
前記診断手段による診断が終了すると、その終了を通知するための終了信号を、前記開始信号の送信先の通信装置に送信する終了信号送信手段を備える
ことを特徴とする請求項２又は請求項３の診断装置。
【請求項５】
前記テスト信号送信手段が前記テスト信号を１つ送信することと、前記判定手段がその送信されたテスト信号に対応する対応信号について判定することとは、交互に行われる
ことを特徴とする請求項１〜請求項４何れかの診断装置。
【請求項６】
前記診断手段は、前記テスト信号の送信先の通信装置との通信異常を診断する際に、その通信装置から送信されてくるべき対応信号全てについての前記判定手段の判定結果を用いる
ことを特徴とする請求項１〜請求項５何れかの診断装置。
【請求項７】
前記診断手段は、前記対応信号を前記所定時間以内に受信しなかった回数を、前記テスト信号送信手段が前記テスト信号を送信した回数で割った値に基づいて、前記通信異常を診断する
ことを特徴とする請求項６の診断装置。
【請求項８】
所定周期で制御データ信号を送信する通信装置と、その制御データ信号の監視をする診断装置とを備える診断システムであって、
前記診断装置は、当該診断装置との通信異常が疑われる通信装置を前記監視に基づいて検出すると、互いに識別できる複数のテスト信号を、前記通信異常が疑われる通信装置に送信するテスト信号送信手段を備え、
前記通信装置は、前記テスト信号送信手段によって送信されたテスト信号を受信すると、そのテスト信号に対応していることが識別できる対応信号を前記診断装置に返信する返信手段を備え、
前記診断装置は、
前記返信手段によって返信されるべき前記対応信号それぞれについて、対応する前記テスト信号の送信時から所定時間以内に受信したかを判定する判定手段と、
前記判定手段の複数の判定結果に基づいて、前記テスト信号の送信先の通信装置との通信異常を診断する診断手段とを備える
ことを特徴とする診断システム。
【請求項９】
前記通信装置は、前記テスト信号を初めに受信してから、前記診断装置による診断が終わったと見なせるまでの間、前記制御データ信号の送信周期を前記所定周期よりも長くする延長手段を備える
ことを特徴とする請求項８の診断システム。
【請求項１０】
所定周期で制御データ信号を送信する通信装置と、その制御データ信号の監視をする診断装置とを備える診断システムであって、
前記診断装置は、当該診断装置との通信異常を疑われる通信装置を前記監視に基づいて検出すると、前記制御データ信号を送信する通信装置に、診断の開始を予告する開始信号を送信する開始信号送信手段を備え、
前記通信装置は、
前記開始信号を初めに受信すると、前記制御データ信号の送信周期を前記所定周期よりも長くする延長手段と、
前記開始信号を受信すると、前記診断装置に返信する開始信号返信手段とを備え、
前記診断装置は、前記開始信号に対する返信を受信した場合、互いに識別できる複数のテスト信号をその返信元の通信装置に送信するテスト信号送信手段を備え、
前記通信装置は、前記テスト信号送信手段によって送信されたテスト信号を受信すると、そのテスト信号に対応していることが識別できる対応信号を前記診断装置に返信するテスト信号返信手段を備え、
前記診断装置は、
前記テスト信号返信手段によって返信されるべき前記対応信号それぞれについて、対応する前記テスト信号の送信時から所定時間以内に受信したかを判定する判定手段と、
前記判定手段の複数の判定結果に基づいて、前記テスト信号の送信先の通信装置との通信異常を診断する診断手段とを備える
ことを特徴とする診断システム。
【請求項１１】
前記診断装置は、前記診断手段による診断が終了すると、その終了を通知するための終了信号を、前記開始信号の送信先の通信装置に送信する終了信号送信手段を備え、
前記延長手段は、前記終了信号を受信すると、前記制御データ信号の送信周期を前記所定周期に戻す
ことを特徴とする請求項１０の診断システム。
【請求項１２】
前記開始信号送信手段は、前記開始信号を複数回送信する
ことを特徴とする請求項１０又は請求項１１の診断システム。
【請求項１３】
前記テスト信号送信手段が前記テスト信号を１つ送信することと、前記判定手段がその送信されたテスト信号に対応する対応信号について判定することとは、交互に行われる
ことを特徴とする請求項８〜請求項１２何れかの診断システム。
【請求項１４】
前記診断手段は、前記テスト信号の送信先の通信装置との通信異常を診断する際に、その通信装置から送信されてくるべき対応信号全てについての前記判定手段の判定結果を用いる
ことを特徴とする請求項８〜請求項１３何れかの診断システム。
【請求項１５】
前記診断手段は、前記対応信号を所定時間以内に受信しなかった回数を、前記テスト信号送信手段が前記テスト信号を送信した回数で割った値に基づいて、前記通信異常を診断する
ことを特徴とする請求項１４の診断システム。
【発明の詳細な説明】
【技術分野】
【０００１】
診断装置および診断システムに関する。
【背景技術】
【０００２】
通信装置は、１つの自動車に多数用いられており、互いに通信するようになっている。自動車に用いられる場合、事故防止のため、フェイルセーフ性能が高いことが求められる。そこで、通信のフェイルセーフ性能を高めるための既存の技術を紹介する。
【０００３】
自動車の場合、エンジン等を制御するＥＣＵが、通信装置となる。自動車内ＬＡＮの通信プロトコルとして用いられているＣＡＮ（Controller Area Network）では、通信ラインが二本使用される。よって、もし一本のラインが断線した場合でも、残ったラインで通信できる。ただしその場合は、通信速度が低速になってしまう。そうすると、必要な通信速度が確保できたり、できなかったりして、通信が不安定になる。
【０００４】
ところで、断線した場合に断線箇所を特定できれば、その後の対処において都合が良い。それを実現する技術は以下の通りである。元々、通信バスの両端に接続されたＥＣＵのみが、終端抵抗を備えている。この構成は、二線式通信ラインによる高速通信に必須である。そして断線箇所特定のために、この終端抵抗を、スイッチと共に全ＥＣＵに備えさせる。そして、断線が生じていないときは、終端のＥＣＵの終端抵抗のみがスイッチ短絡によって機能するようになっている。一方、終端のＥＣＵに挟まれた他のＥＣＵの終端抵抗は、スイッチ開放によって機能しないようになっている。よって、断線が生じていないときは、従来と変わらない通信ができる。そして断線が生じると、各ＥＣＵは、順番に終端抵抗のスイッチを短絡させ、次のＥＣＵが短絡させたら開放させる。つまり、終端抵抗が機能しているＥＣＵを暫定的に交代させていく。そうすると、暫定的な終端のＥＣＵの間に断線箇所がなければ、その暫定的な終端のＥＣＵ及びそれらＥＣＵに挟まれたＥＣＵの間では、高速通信ができる。それに対して、暫定的な終端のＥＣＵの間に断線箇所があれば、高速通信ができない。この差を利用することで、断線箇所を特定できる（特許文献１）。
【０００５】
ところで、上記の技術では、通信バスの断線は検出できても、通信バスとＥＣＵとをつなぐ接続線の断線を検出することはできない。そこで、過渡現象による電圧の挙動が、接続線の断線の有無で変わることを利用して、ＥＣＵの通常モードと省電力モードとの切り換えによって、接続線の断線を検出する技術がある（特許文献２）。
【０００６】
また、テスト信号による断線の判定において、誤判定を防ぐ技術がある（特許文献３）。この誤判定について説明する。断線の影響を受けたＥＣＵは、送信権について正常に判定できなくなり、送信権がないのにテスト信号を送信することが考えられる。そうすると、断線の影響を受けていないＥＣＵの送信するテスト信号と衝突してしまう。そうすると、断線の影響を受けていないにも関わらずテスト信号が正常に送信できないＥＣＵが現れる。そして、そのＥＣＵは、断線の影響を受けたと誤判定される。
【０００７】
そこで、テスト信号を送信完了できなかった場合、テスト信号よりも優先度の高い特別信号を送信する。そうすれば、テスト信号が送信できなかったのは、上記衝突等が原因であり、断線ではないと改めて判定し直すことができる。
【０００８】
この他、二線式通信ラインによる通信システムにおいて、断線検出に関する技術を２つ紹介する。１つ目は、通話用の通信装置（電話の中継局など）において、通話品質を落とさずに、断線を検出する技術である（特許文献４）。具体的には、通話中でなければ断線検出のためのテスト信号を出力する一方で、通話中はテスト信号を出力しない。よって、テスト信号によって通話品質が落ちることがなくなる。なお、通話中に生じた断線の検出は、通話終了後に送信するテスト信号によって行う。これは、通話中に断線が生じればユーザが通話を終了する、ということを前提としたものである。つまり、ユーザの一般的な挙動を、断線検出に利用している点に特徴がある。
【０００９】
２つ目は、電力を節約しつつ、断線を検出する技術である（特許文献５）。この技術においては、メッセージが伝送されていない間は、通信装置間に電流が流れていない状態に保たれており、断線検出は行われない。そして、メッセージの伝送を開始した後に、メッセージに対する返信の有無で断線を検出する。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００３−３０４２６５号公報
【特許文献２】特開２００７−３２９６７１号公報
【特許文献３】特開２００８−２７９９４７号公報
【特許文献４】特開平６−３１５１７６号公報
【特許文献５】特開平６−０５４０３３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上記の技術の課題は、異常診断の精度が高くないことである。二線式通信ラインは、一箇所断線しても通信できるのが長所である。しかし逆に、異常を診断するのが難しくなるという短所もはらむことになる。先述した従来技術は、基準となる通信速度でのテスト信号の送受信が、可能か不可能かで診断をしている。しかし、一本が断線しているにも関わらず、たまたま、所定の通信速度を超えて送受信が成功してしまうことがある。そうすると、ほとんどの場合に通信速度が確保できず異常と診断すべきところを、正常と誤診してしまう。また、一線式通信ライン等、他の通信媒体の場合においても、断線以外の理由（外乱等）によって通信が不安定になると、従来技術では診断が難しいことがあった。本発明はこの課題に鑑み、通信異常診断の精度を高めることを目的とする。
【課題を解決するための手段】
【００１２】
この課題を解決するための請求項１の発明は、通信装置から所定周期で送信されてくる制御データ信号の監視をする診断装置である。そして、テスト信号送信手段と判定手段と診断手段とを備えることを特徴とする。
【００１３】
送信手段は、通信異常が疑われる通信装置を前記監視に基づいて検出すると、互いに識別できる複数のテスト信号を、通信異常が疑われる通信装置に送信する。判定手段は、テスト信号送信手段によって送信された複数のテスト信号の何れに対応するかが識別できる対応信号であって、テスト信号の送信先の通信装置から送信されてくるべき対応信号それぞれについて、対応するテスト信号の送信時から所定時間以内に受信したかを判定する。診断手段は、判定手段の複数の判定結果に基づいて、テスト信号の送信先の通信装置との通信異常を診断する。
【００１４】
この発明によれば、通信異常診断の精度を高めることができる。理由を述べる。「テスト信号を送信してから、そのテスト信号に対応する対応信号を受信するまでの時間が、所定時間以内かを判定すること」は、「通信異常が疑われる通信装置との間で、信号が所定時間以内に往復できるかを判定すること」になる。つまり、必要な通信速度が確保できるのかを判定することになる。そして、この判定結果を複数用いて、通信異常を診断する。よって、診断に偶然性が入りにくくなり、診断の精度が上がることになる。なお、診断の基となる判定結果は、判定手段による判定結果の全てでなくても良く、抜粋された一部でも良い。また、複数のテスト信号は、例えば１つずつ送信されることが考えられる。
【００１５】
ところで、次のようにしても当初の課題を解決することができる。請求項２の発明は、請求項１と同様に、通信装置から所定周期で送信されてくる制御データ信号の監視をする診断装置である。そして、開始信号送信手段とテスト信号送信手段と判定手段と診断手段とを備えることを特徴とする。
【００１６】
開始信号送信手段は、当該診断装置との通信異常が疑われる通信装置を前記監視に基づいて検出すると、制御データ信号を送信する通信装置に、診断の開始を予告する開始信号を送信する。そして、テスト信号送信手段は、開始信号に対する返信を受信した場合、互いに識別できる複数のテスト信号をその返信元の通信装置に送信する。判定手段と診断手段との動作は、請求項１と同じなので説明を省く。
【００１７】
この発明によれば、請求項１と同じ理由で、同じ効果が得られる。さらに、テスト信号の前に開始信号を送信するので、通信異常が疑われる通信装置、更にはその他の通信装置は、テスト信号のための準備ができる。例えば、制御データ信号の送信周期を長くしたり、送信を止めたりできる。また、通信異常の疑いが検出されていない通信装置も診断対象に加えるので、通信異常を発見する可能性が高くなる。
【００１８】
なお、開始信号に対する返信が全く無かった通信装置については、テスト信号の送信先に加えて診断対象としてもよいが、直ちに通信異常であると診断すると共にテスト信号の送信先から外すこともできる。そうすれば、無駄なテスト信号の送信をせずに済む。
【００１９】
ただし、上記のように開始信号に対する返信が無かったことを根拠として通信異常であると診断する場合において、開始信号が１回しか送信されないとすると、たまたま開始信号の受信や返信に失敗して、テスト信号の送信先から外されてしまう通信装置が現れ得る。しかし、このような通信装置は、本来はテスト信号の送信先に加えて診断すべきだった可能性が考えられる。そこで次のようにすると良い。
【００２０】
請求項３の診断装置が備える開始信号送信手段は、開始信号を複数回送信することを特徴とする。この発明によれば、テスト信号の送信先とすべき通信装置を、誤って送信先から外してしまう可能性が少なくなる。なぜなら、複数の開始信号に対して１回でも返信すれば、テスト信号の送信先から外されないようにすることができるからである。
【００２１】
ところで、先述したテスト信号のための準備を行った場合、診断が終われば元に戻した方が良い。そのためには診断が終わったことを通信装置が把握する必要がある。そこで次のようにすると良い。
【００２２】
請求項４の診断装置は、診断手段による診断が終了すると、その終了を通知するための終了信号を、開始信号の送信先の通信装置に送信する終了信号送信手段を備えることを特徴とする。
【００２３】
この発明によれば、診断の終了を通知できるので、通信装置は、それをトリガとして通常の通信状態に復帰できる。例えば、制御データ信号の送信周期を長くしたり、送信を止めたりしていたのを元に戻すことができる。
【００２４】
ところで、一度にたくさんのテスト信号を送信し、更にそれに対応する対応信号を受信しようとすると、通信ラインの負荷が上がってしまう。そこで次のようにすると良い。
請求項５の診断装置は、送信手段がテスト信号を１つ送信することと、判定手段がその送信されたテスト信号に対応する対応信号について判定することとは、交互に行われることを特徴とする。この発明によれば、診断による通信ラインの影響を小さくできる。なぜなら、テスト信号の送信、並びに対応信号の受信および判定を交互に行うので、一度に大量の信号が送信されることがないからである。よって、通信ラインの空きが大きくなくても、テストを実行できることになる。
【００２５】
ところで上記発明においては、一部の判定結果は、診断に用いられない場合もある。そうすると、送信手段と判定手段との一部の動作が無駄になる上、診断の精度も落ちる場合がある。そこで次のようにすると良い。
【００２６】
請求項６の診断装置では、診断手段は、テスト信号の送信先の通信装置との通信異常を診断する際に、その通信装置から送信されてくるべき対応信号全てについての判定手段の判定結果を用いることを特徴とする。この発明によれば、送信手段と判定手段との動作を無駄にせず、診断の精度も上がることになる。
【００２７】
ところで上記発明は、具体的には次のようにすると良い。請求項７の診断装置では、診断手段は、対応信号を所定時間以内に受信しなかった回数を、送信手段がテスト信号を送信した回数で割った値に基づいて、通信異常を診断することを特徴とする。
【００２８】
請求項８、請求項１０〜請求項１５の発明は、上記発明を、通信装置を含んだシステムとしたものである。ただし、請求項１０及び請求項１１の診断システムにおける通信装置は、延長手段を備える。この延長手段は、請求項２及び請求項３での作用効果の説明で例示した内容を、構成として明記したものである。
【００２９】
また、請求項９の診断システムは、対応する請求項が請求項１〜請求項７には無いが、通信装置が請求項１１と同様な延長手段を備えることを特徴とする。
【図面の簡単な説明】
【００３０】
【図１】通信システムのブロック構成図。
【図２】監視処理のフローチャート。
【図３】第一診断処理のフローチャート。
【図４】返信処理のフローチャート。
【図５】信号のタイムチャート。
【図６】第二診断処理のフローチャート。
【図７】開始応答処理のフローチャート。
【図８】終了処理のフローチャート。
【図９】終了応答処理のフローチャート。
【図１０】信号のタイムチャート。
【発明を実施するための形態】
【００３１】
本発明の実施例を説明する。
【実施例１】
【００３２】
図１は、本発明が適用された自動車用通信システム１のブロック構成図である。自動車用通信システム１は、自動車に搭載されるものであり、エンジンＥＣＵ１０・ＡＢＳ／ＥＣＵ２０・エアコンＥＣＵ３０を備える。ここで、エンジンＥＣＵ１０はエンジンを、ＡＢＳ／ＥＣＵ２０はＡＢＳを、エアコンＥＣＵ３０はエアコンをそれぞれ制御する電子制御ユニット(ＥＣＵ：Electronic Control Unit)である。
【００３３】
そして、各ＥＣＵは、ＣＰＵ、通信ドライバ及びメモリを備える。具体的には図１に示すように、エンジンＥＣＵ１０はＣＰＵ１１と通信ドライバ１２とを、ＡＢＳ／ＥＣＵ２０はＣＰＵ２１と通信ドライバ２２とを、エアコンＥＣＵ３０はＣＰＵ３１と通信ドライバ３２とを備える。なおメモリについては、図示を省略している。
【００３４】
ＣＰＵは、各種センサ（図示せず）や他のＥＣＵ等から送られてくる信号（センサ信号や制御データ信号等）に基づき、制御対象（エンジンやＡＢＳ装置などを制御するアクチュエータ）を制御するための演算を行い、制御対象に演算結果としての指令信号を送ったり、他のＥＣＵに対し通信ドライバおよび通信バスを介してデータを送ったりする。
【００３５】
また、通信ドライバは、ＣＰＵが演算したデータを他のＥＣＵに送るために、ＣＰＵのデータを通信バスに送出するタイミング等を制御したり、通信バスに載っている通信データであって、当該通信ドライバの所属するＥＣＵ宛ての通信データを受信し、ＣＰＵへその受信データを渡したりする通信制御回路として機能している。
【００３６】
また、この自動車用通信システム１では、エンジンＥＣＵ１０が終端抵抗１３を、エアコンＥＣＵ３０が終端抵抗３３を備える。そして、各ＥＣＵは、ＣＰＵ及び通信ドライバの働きにより、ＣＡＮ−Ｈライン１００とＣＡＮ−Ｌライン２００とから成る二線式通信ラインを介して、ＣＡＮプロトコルによって相互に通信できるようになっている。なお、実際の自動車には、図１に示す３つのＥＣＵ以外にも様々なＥＣＵが搭載され、ＣＡＮの接続線にて接続されるのが一般的であるが、本実施例では説明を簡略にするために、３つのＥＣＵからなる自動車用通信システム１を例示している。
【００３７】
そして、この自動車用通信システム１において、エンジンＥＣＵ１０は、他のＥＣＵ（ＡＢＳ／ＥＣＵ２０及びエアコンＥＣＵ３０）によって送信される通常制御用データフレーム（制御データ信号）に基づき、通信異常が疑われる状態を検出する診断装置として機能する。この通常制御用データフレームは、それぞれに送信周期（例えば１０ｍｓ毎）が定められている。なお、このような定期送信に加え、イベント時にも送信されるものであってもよい。
【００３８】
図２は、診断装置としてのエンジンＥＣＵ１０（具体的にはＣＰＵ１１）が実行する監視処理を示すフローチャートである。この処理は、通常時（各ＥＣＵが通常制御用データフレームを周期的に送信する状態）において繰り返し実行されるものである。
【００３９】
エンジンＥＣＵ１０は、この監視処理を開始すると、まず、通常制御用データフレームを最後に受信した時点からの経過時間を取得する（Ｓ１０）。具体的には、エンジンＥＣＵ１０は、通常制御用データフレームを受信する度にカウントが「０」にリセットされるフリーランタイマを用いて、上記経過時間を取得する。ここで、通常制御用データフレームの種類数は、通信対象のＥＣＵの数と同じか、或いはそれより多くあり、経過時間を測定する対象は、通常制御用データフレームの種類それぞれについてである。つまりフリーランタイマは、通常制御用データフレームの種類毎に用意されており、それぞれ異なる所定時間が設定されている。
【００４０】
一方この監視処理は、各ＥＣＵを対象とした処理が同時並行で実行されるものである。つまり、フリーランタイマを、測定対象の通常制御用データフレームの送信元となるＥＣＵ別にグループ化して、そのグループ化されたフリーランタイマの集合それぞれを監視対象とした監視処理を別々に走らせるのである。ただし「集合」と言っても、属するフリーランタイマが１つのものもあり得る。
【００４１】
そして、監視対象としている集合に属する何れか１つのフリーランタイマに示された時間が、所定時間を経過しているかを判断する（Ｓ２０）。何れも所定時間を経過していないと判断すれば（Ｓ２０ＮＯ）、Ｓ１０に戻る。一方、何れか１つでも所定時間を経過していると判断すると（Ｓ２０ＹＥＳ）、第一診断処理を実行する（Ｓ１０００）。第一診断処理を説明する前に、上記所定時間について説明する。
【００４２】
この所定時間は、通常制御用データフレームの本来の周期よりも、当然、長く設定される。その一方で、問題（エンジンのエミッション悪化による法規違反など）が生じる一歩手前を検出できるように定められる。例えば、周期が１０ｍｓの通常制御用データフレームの場合に、４周期に渡って受信できないと問題となるとき、３周期分の時間（３０ｍｓ）を所定時間として定める。このようにすることで、問題が生じる一歩手前で、後述する第一診断処理を開始することができる。
【００４３】
ところで、上記のような現象が起こる原因として、二線式通信ラインに特有なものとしては、背景技術で説明した断線が挙げられる。例えば図１に示すように、ＣＡＮ−Ｌライン２００が、ＡＢＳ／ＥＣＵ２０とエアコンＥＣＵ３０との間で断線したとする。そうなったとしても、ＣＡＮ−Ｈライン１００があるので、通信が全くできなくなる訳ではない。しかし、通信速度が低下して通信が不安定になる。具体的には、あるＥＣＵから送信されてくる通常制御用データフレームの受信間隔が、本来の周期よりも長くなったり不規則になったりする。そうすると、上記のように、本来の周期の３倍（３周期分の時間）かかって、エンジンＥＣＵ１０に通常制御用データフレームが到達することが起きるのである。
【００４４】
ここから、第一診断処理を説明する。図３は、第一診断処理を示すフローチャートである。この処理は、先述したように、フリーランタイマのカウント時間が所定時間に達したことをトリガとして、診断装置としてのエンジンＥＣＵ１０が主体となって実行するものである。診断対象の装置は、所定時間以上に渡って受信できなかった通常制御用データフレームの送信元のＥＣＵである。
【００４５】
まず、タイムスタンプＴ、エラーカウンタＥそれぞれをリセットし、初期値「０」に設定する（Ｓ１１０）。これら変数の使い方は、追って説明していく。次に、タイムスタンプＴに１を足す（Ｓ１２０）。そして、タイムスタンプＴを載せたテスト信号を診断対象のＥＣＵに送信する（Ｓ１３０）。このテスト信号は、フレームに付加されるＩＤによって、テスト信号であることと、診断対象のＥＣＵ宛てのフレームであることとが識別できるようになっている。更に、データ・フィールドにおいて、タイムスタンプＴ値が識別できるようになっている。
【００４６】
ここで図４に移り、返信処理を説明する。この処理は、エンジンＥＣＵ１０以外のＥＣＵ（ＡＢＳ／ＥＣＵ２０・エアコンＥＣＵ３０）に備えられたＣＰＵが、テスト信号を受信することをトリガにして、実行するものである。より詳しく言うと、ＡＢＳ／ＥＣＵ２０及びエアコンＥＣＵ３０に備えられたＣＰＵは、通常制御用データフレームを受信するために定常的に実行している処理において、受信したデータが通常制御用データフレームなのか、テスト信号なのかをＩＤに基づいて識別している。そして、テスト信号であると識別したら、その定常的な処理を中断して、返信処理に移行する。
【００４７】
テスト信号を受信したＥＣＵ（診断対象のＥＣＵ）は、この返信処理を開始すると、まず、通常制御用データフレームの送信周期を長くする（Ｓ２１０）。長くする目的は、バス負荷を下げて通信ラインの空きを確保することであり、どの程度長くするかは、ＥＣＵ毎に予め決められている。例えば、安全に関わるＡＢＳ／ＥＣＵ２０はほとんど（或いは全く）長くしない。それに対して、一時的に制御が不十分になっても大きな問題が生じないエアコンＥＣＵ３０は、相応に長くするようになっている。送信周期を長くする目的は、テスト信号および次で説明する対応信号の送信のためにバス負荷を低くすることである。このようにして、通常制御用データフレームの送受信を用いた通常の制御と並行して診断のための通信を行うことにより自動車の走行中においても診断を可能にし、いち早く異常を発見できるようにすることで、フェイルセーフ機能を従来よりも高めている。
【００４８】
そして、受信したタイムスタンプＴを載せた対応信号をエンジンＥＣＵ１０に返信する（Ｓ２２０）。この対応信号は、ＩＤによって、テスト信号の返信であることと、エンジンＥＣＵ１０宛てのフレームであることとが識別できるようになっている。更に、データ・フィールドにおいて、タイムスタンプＴ値が識別できるようになっている。
【００４９】
図３に戻る。エンジンＥＣＵ１０は、診断対象のＥＣＵからの対応信号を受信したかを判断する（Ｓ１４０）。受信していないと判断すると（Ｓ１４０ＮＯ）、直前のＳ１３０を起点としてタイムアウトしたかを判断する（Ｓ１５０）。タイムアウトしていないと判断すると（Ｓ１５０ＮＯ）、Ｓ１４０に戻る。そして、対応信号を受信したと判断すると（Ｓ１４０ＹＥＳ）、直前に送信したテスト信号に載せたタイムスタンプＴと、受信した対応信号に載っているタイムスタンプＴとが一致するかを判断する（Ｓ１６０）。一致しないと判断すると（Ｓ１６０ＮＯ）、Ｓ１４０に戻る。そして、タイムアウトしたと判断すると（Ｓ１５０ＹＥＳ）、エラーカウンタＥに１を足して（Ｓ１７０）、Ｓ１７５に進む。一方、タイムスタンプＴが一致したと判断しても（Ｓ１６０ＹＥＳ）、Ｓ１７５に進む（エラーカウンタＥは変えない）。
【００５０】
Ｓ１７５に進むと、Ｓ１２０で計算したタイムスタンプＴが規定回数以上かを判断する（Ｓ１７５）。ここで、規定回数とは、テスト信号を送信する回数として定められたものであり、通信の成功割合を算出する際の分母となる。すなわち、例えば通信が３０％成功すれば合格であるとしても、３／１０と３０／１００とでは、同じ３０％でも後者の方（規定回数が多い方）が信頼度が高いと言えるが、診断の迅速性という面では規定回数が少ない方が好ましい。そこで、この規定回数は、テストの信頼度及び迅速性のバランスを取って設定される。そして、規定回数未満であると判断すると（Ｓ１７５ＮＯ）、Ｓ１２０に戻る。
【００５１】
図４に移る。診断対象のＥＣＵは、一度、対応信号を返信した（Ｓ２２０）後、テスト信号を再び受信したかを判断する（Ｓ２３０）。受信していないと判断すると（Ｓ２３０ＮＯ）、直前のテスト信号の受信時を起点として、タイムアウトしたかを判断する（Ｓ２４０）。具体的には、各ＥＣＵの返信処理の中で、受信信号がテスト信号であると判断する度に、フリーランタイマをリセットしカウントを開始する。この目的は、エンジンＥＣＵ１０によるテスト信号の送信が終わり次第、通常制御用データフレームの送信周期を元に戻すステップ（後述のＳ２５０）に進むことである。当然、最後のテスト信号（規定回数と一致するタイムスタンプＴが載ったテスト信号）を受信すれば、直ちにＳ２５０に進めばよいのだが、通信バスの異常などにより常に受信できるとは限らない。そこで例えば、規定回数分のテスト信号全てが送信されるために費やされ得る最長時間を、Ｓ２４０のタイムアウト時間の固定値として採用することが考えられるが、このようにすると待ち過ぎになってしまい、通常の通信状態に復帰するのが遅れてしまうことが考えられる。
【００５２】
そこで、本実施例の自動車用通信システム１では、診断対象のＥＣＵがテスト信号を最後に受信してから、最後のテスト信号がエンジンＥＣＵ１０によって送信されるまでの時間の推測結果を、Ｓ２４０のタイムアウト時間として採用している。その推測は、診断対象のＥＣＵが最後に受信したテスト信号に載っているタイムスタンプＴと、第一診断処理におけるテスト信号の送信間隔の最大値とを用いて、例えば次式のようにすることができる。
（タイムスタンプＴの規定回数−最後に受信したテスト信号のタイムスタンプＴ）×Ｓ１５０でのタイムアウト時間＋α（誤差等に対応するための時間）…＜１＞
変数は「最後に受信したテスト信号のタイムスタンプＴ」だけであり、テスト信号を受信する度に、タイムアウト時間が短縮されていくことになる。そして、タイムアウトを式＜１＞に基づいて判定すれば、タイムアウト後には既に第一診断処理のＳ１７５でＹＥＳと進んでいるはずなので、エンジンＥＣＵ１０によるテスト信号の送信が終わったと見なせる。特に、最後のテスト信号を受信した後は、直ぐにＳ２５０に進むことができる。例えば「タイムスタンプＴの規定回数＝１０、最後に受信したテスト信号のタイムスタンプＴ＝５」であれば「５×Ｓ１５０でのタイムアウト時間＋α」がＳ２４０でのタイムアウト時間になる。また、「タイムスタンプＴの規定回数＝最後に受信したテスト信号のタイムスタンプＴ＝１０」であれば「α」がＳ２４０でのタイムアウト時間になる。
【００５３】
そして、タイムアウトしていないと判断すると（Ｓ２４０ＮＯ）、Ｓ２３０に戻る。一方、テスト信号を受信したと判断すると（Ｓ２３０ＹＥＳ）、Ｓ２２０に戻る。そして、タイムアウトしたと判断すると（Ｓ２４０ＹＥＳ）、通常制御用データフレームの送信周期を元に戻して（Ｓ２５０）、この処理を終える。
【００５４】
なお、これまでに説明したテスト信号および対応信号の送受信は、通信が不安定の場合、全てが正常に行われるとは限らない。通信速度が遅くなって、エンジンＥＣＵ１０によるテスト信号送信から対応信号受信までの時間が長くなると、タイムアウトによって、失敗と見なされる。また、テスト信号が診断対象のＥＣＵに全く届かなければ、診断対象のＥＣＵは返信処理を実行することがない。この場合は当然、エンジンＥＣＵ１０は対応信号の受信が全くできないことになる。
【００５５】
図３に戻る。エンジンＥＣＵ１０は、タイムスタンプＴが規定回数以上であると判断すると（Ｓ１７５ＹＥＳ）、Ｅ／Ｔ（エラーカウンタＥをタイムスタンプＴで割った値：通信失敗割合を示す値）が閾値Ｆ（通信失敗割合の閾値）以上かを判断する（Ｓ１８０）。なお閾値Ｆは、各ＥＣＵが担う機能の重要度に基づいて、ＥＣＵ毎に定められている。安全に関わるＡＢＳ／ＥＣＵ２０の場合は厳しく（例えば５０％）、そうでないエアコンＥＣＵ３０は甘く（例えば７０％）設定される。
【００５６】
Ｅ／Ｔが閾値Ｆ未満であると判断すると（Ｓ１８０ＮＯ）、診断対象のＥＣＵの通信状態は正常であるという診断を確定させて（Ｓ１８５）、この処理を終える。一方、Ｅ／Ｔが閾値Ｆ以上であると判断すると（Ｓ１８０ＹＥＳ）、診断対象のＥＣＵの通信異常を確定させる（Ｓ１９０）。そして、フェイル情報（通信異常に関する情報）を、異常と診断されたＥＣＵと関係のある通信装置（図示しないものも含む）に送信して（Ｓ１９５）、この処理を終える。
【００５７】
図５は、第一診断処理と、エアコンＥＣＵ３０による返信処理とによる信号のタイムチャートを示した図である。タイムスタンプＴ＝１及びタイムスタンプＴ＝３の場合は、テスト信号および対応信号の送受信が成功している。それに対してタイムスタンプＴ＝２の場合は、エアコンＥＣＵ３０がテスト信号の受信を失敗したことにより、対応信号の送受信ができていない。よって、タイムスタンプＴ＝２でタイムアウトした後に、エラーカウンタＥが１増えている。もしタイムスタンプＴの規定回数が３ならば、Ｅ／Ｔ＝１／３となり、この値が診断に用いられる。
【００５８】
効果を述べる。実施例１の自動車用通信システム１においては、精度の高い診断結果を得ることができる。なぜなら、自動車用通信システム１においては、テスト信号の送信と、直前に送信したテスト信号に対応している対応信号の受信とが所定時間以内に成功するかを、つまり信号が所定時間以内に往復できるかを、複数回に渡り判定するからである。「信号が所定時間以内に往復できるか」ということは「必要な速度を満たす通信ができるか」ということである。このことを複数回に渡り判定すれば、従来よりも高精度な診断結果が得られる。つまり、１回だけの判定では通信線が異常でも偶然成功してしまう可能性もはらむが、複数回に渡り判定することでその偶然性を抑制できるためである。
【００５９】
そして、エンジンＥＣＵ１０はエンジンを制御するので、このような診断の精度は重要である。なぜなら、通信異常が検出できないと、エミッション悪化につながる事態を検出できない場合があるからである。エミッション悪化につながる理由は、エンジンＥＣＵ１０と他のＥＣＵ（エアコンＥＣＵ３０等）との間で送受信される通常制御用データフレームは対になっているものがあり、この対の関係が保たれることを前提にして、エンジンを制御しているからである。自動車用通信システム１では、このような関係が満たされているかを異常診断の基準としているので、このようなエミッション悪化につながる事態を、高精度で検出できることになる。
【実施例２】
【００６０】
実施例１との違いだけを説明する。実施例２では、エンジンＥＣＵ１０が、第一診断処理に加えて、第二診断処理を実行する（具体的には、監視処理で「Ｓ２０ＹＥＳ」と進むと、第二診断処理を開始する。そして、第二診断処理の一部として、第一診断処理を実行する）。また、ＡＢＳ／ＥＣＵ２０とエアコンＥＣＵ３０とが、返信処理に加えて、開始応答処理と終了応答処理とを実行する。なお、第一診断処理や返信処理の一部に変更がある（後述）。
【００６１】
図６は、第二診断処理を示すフローチャートである。エンジンＥＣＵ１０は、この第二診断処理を開始すると、まず、開始信号を他のＥＣＵ（ＡＢＳ／ＥＣＵ２０及びエアコンＥＣＵ３０）に送信する（Ｓ３１０）。開始信号とは、テスト信号の送信を予告するためのものであり、タイムスタンプＴは載せない信号である。また、フレームに付加されるＩＤによって、開始信号であることと、同じ通信ラインに接続されたＥＣＵ全てに宛てたものであることとが識別できるようになっており、さらに通常制御用データフレームと区別できるようになっている。
【００６２】
図７に移る。図７は、ＡＢＳ／ＥＣＵ２０とエアコンＥＣＵ３０とが実行する開始応答処理を示したフローチャートである。この処理は、開始信号の受信がトリガとなる。開始信号を受信したＥＣＵは、この開始応答処理を開始すると、まず、通常制御用データフレームの送信周期を長くする（Ｓ４１０）（つまり、実施例１の返信処理のＳ２１０と同じことをする）。そして、開始ＯＫ信号をエンジンＥＣＵ１０に返信して（Ｓ４２０）、この処理を終える。この開始ＯＫ信号は、フレームに付加されるＩＤによって、開始信号の返信であることと、エンジンＥＣＵ１０宛てであることが識別でき、通常制御用データフレームと区別できるようになっている。
【００６３】
図６に戻る。エンジンＥＣＵ１０は、他のＥＣＵそれぞれから、開始ＯＫ信号の返信が少なくとも一回は来たかを判断する（Ｓ３２０）。一回も来ていないＥＣＵがあると判断すると（Ｓ３２０ＮＯ）、第二診断処理の開始時を起点としてタイムアウトしたかを判断する（Ｓ３３０）。具体的には、第二診断処理を開始した時にフリーランタイマのカウンタをリセットし、所定時間が経つまでに、開始信号の送信先から開始ＯＫ信号を受信したか否かに基づいて、タイムアウトを判定する。
【００６４】
タイムアウトしていないと判断すると（Ｓ３３０ＮＯ）、Ｓ３１０に戻って開始信号を送信する。よって、正常に送受信されれば、Ｓ３３０ＮＯの度に開始応答処理が実行される。
【００６５】
一方、タイムアウトしたと判断すると（Ｓ３３０ＹＥＳ）、返信のないＥＣＵの通信異常を確定させて（Ｓ３４０）、実施例１で説明した第一診断処理を実行する（Ｓ１０００）。また、他のＥＣＵそれぞれから開始ＯＫ信号の返信が少なくとも一回は来たと判断しても（Ｓ３２０ＹＥＳ）、第一診断処理を実行する（Ｓ１０００）。
【００６６】
なお実施例２では、第一診断処理でのテスト信号の送信先は、開始ＯＫ信号の返信をしてきたＥＣＵ全てである。つまり、通信が不安定になっているＥＣＵだけではなく、他のＥＣＵも診断対象に加え、それぞれを対象とした第一診断処理を並行して実行する。このようにすることで、異常発見の確率が上がると共に、テスト信号のためのバス負荷低減を複数のＥＣＵが協働して実行できるようになる。なぜなら、開始信号を受信したＥＣＵ全てが、Ｓ４１０によって通常制御用データフレームの送信周期を長くすることができるからである。（実施例１においては、診断対象のＥＣＵのみによって、テスト信号のためのバス負荷低減を実現する必要がある。よってこの点に関しては、実施例２の方が、設計自由度が大きいと言える。）
一方、第一診断処理によるテスト信号を受信したＥＣＵは、実施例１で説明した返信処理を実行する。ただし、Ｓ２１０及びＳ２５０を省く。なぜなら、これらのステップは、開始応答処理または終了応答処理（図９参照）で実行されるからである。それ以外は同じである。
【００６７】
そして、全ての対象ＥＣＵについての第一診断処理を終えると、エンジンＥＣＵ１０は終了処理を実行する（Ｓ５０００）。図８は、終了処理を示したフローチャートである。エンジンＥＣＵ１０は、この終了処理を開始すると、まず、第一診断処理で診断対象としていたＥＣＵ全てに終了信号を送信する（Ｓ５１０）。終了信号とは、テスト信号の送信が終わったことを示す信号である。
【００６８】
図９に移る。図９は、ＡＢＳ／ＥＣＵ２０とエアコンＥＣＵ３０とが実行する終了応答処理を示したフローチャートである。この処理は、終了信号の受信がトリガとなる。
終了信号を受信したＥＣＵは、この終了応答処理を開始すると、まず、終了ＯＫ信号をエンジンＥＣＵ１０に返信する（Ｓ６１０）。この終了ＯＫ信号は、フレームに付加されるＩＤによって、終了信号の返信であることと、エンジンＥＣＵ１０宛てであることとが識別でき、通常制御用データフレームと区別できるようになっている。そして、通常制御用データフレームの送信周期を元に戻して（Ｓ６２０）（つまり、実施例１の返信処理のＳ２５０と同じことをして）、この処理を終える。
【００６９】
図８に戻る。エンジンＥＣＵ１０は、終了信号の送信先のＥＣＵそれぞれから、少なくとも一回は終了ＯＫ信号の返信を受信したかを判断する（Ｓ５２０）。受信していないと判断すると（Ｓ５２０ＮＯ）、終了処理の処理開始時を起点としてタイムアウトしたかを判断する（Ｓ５３０）。なお、タイムアウトの判断は、先述した処理と同様にフリーランタイマを用いて行うことができる。
【００７０】
そして、タイムアウトしていないと判断すると（Ｓ５３０ＮＯ）、Ｓ５１０に戻って、終了信号を送信する。よって、正常に通信ができれば、Ｓ５３０ＮＯの度に終了応答処理が実行される。
【００７１】
一方、終了信号の送信先のＥＣＵそれぞれから、一回は終了ＯＫ信号の返信を受信したと判断すると（Ｓ５２０ＹＥＳ）、この処理を終える。一方、タイムアウトしたと判断すると（Ｓ５３０ＹＥＳ）、返信がなかったＥＣＵについて、通信異常を確定させる（Ｓ５４０）。なお、この確定は、第一診断処理における正常という診断（Ｓ１８５）を覆すこともあり得る。しかし、通信失敗割合が閾値未満であることを根拠として正常と診断したのだから、ここで異常と診断されることは希と考えられるが、診断中のバス負荷調整のための開始信号／終了信号の送受信のついでに異常診断を行う。そして、正常という診断を覆したＥＣＵについて（つまり、Ｓ１９５でフェイル情報を送信したものを除いて）、フェイル情報を送信して（Ｓ５５０）、この処理を終える。
【００７２】
図１０は、実施例２でのタイムチャートである。図に示すように、テスト信号および対応信号に加えて、開始信号および開始ＯＫ信号の返信、並びに終了信号および終了ＯＫ信号の返信が送受信される。図に示すように、開始信号と終了信号とについては、送信先のＥＣＵ全てから返信が来るか、或いはタイムアウトまで連続して送信し続ける。
【００７３】
以上説明した実施例２の自動車用通信システム１によれば、実施例１で述べた効果に加え、次のような効果が得られる。ある１つのＥＣＵの通信状態を診断開始のトリガとしていても、全ＥＣＵを対象に診断をするので、実施例１では見過ごされたかも知れない異常を発見できる場合がある。また、開始信号によって、通信が正常にできるＥＣＵにバス負荷を下げさせることができるので、バス負荷が原因でテスト信号が送受信できないということを避けやすくなる。
【００７４】
なお、第一診断処理におけるタイムスタンプＴの規定回数（Ｓ１７５参照）やタイムアウト時間（Ｓ１５０参照）は、対象とするＥＣＵ毎に変えると良い。つまり、どれだけ慎重を期して診断したいかに応じてタイムスタンプＴを決めたり、どれだけの通信速度が確保されるべきかに応じてタイムアウト時間を決めたりすると良い。先述した実施例においては、エアコンＥＣＵ３０よりもＡＢＳ／ＥＣＵ２０の方が、タイムスタンプＴの規定回数は多く、タイムアウト時間は短く設定されるべきである。
【００７５】
変形例として、ＦｌｅｘＲａｙ（登録商標）やＬＩＮ等、他の通信プロトコルに適用しても良い。なおＬＩＮは一線式通信ラインを用いるものであるが、通信不調の原因は通信ラインの断線に限らず、外乱等も考えられるので、本発明の適用は有用である。また、特定の通信装置だけではなく、複数の通信装置が異常診断の主体となるような構成でも良い。
【００７６】
また、第一診断処理で、タイムスタンプＴが一致しない（Ｓ１６０ＮＯ）と判断した後に、Ｓ１７０に進んでも良い。このようにすれば、タイムアウトを待たずに次のテスト信号の送信に進むことができる。また、Ｓ１８０でＥ／Ｔを算出する際、一部のタイムスタンプＴについての結果を除外しても良い。例えば、物理的な限界を超えた速度で返信が来た場合は、タイムスタンプＴが一致していても正常とは判定できないので、除外することが考えられる。
【００７７】
また、実施例１における第一診断処理、又は実施例２における第二診断処理の開始トリガは、所定時間（例えば３０ｍｓ）に渡って通常制御用データフレームが受信できないことであった。よって、この方法だと、例えば２９ｍｓ間隔で度々受信する場合、診断を開始することがない。しかし本来の周期が１０ｍｓであるのに、２９ｍｓ間隔で頻繁に受信するのは異常が疑われる状態である可能性がある。よって、放置しておくのは望ましくなく、診断をした方が良いと考えられる。そこで、単に所定時間に達したか否かで決めるのではなく、受信間隔のバラツキ（標準偏差など）等を考慮したトリガを採用しても良い。
【００７８】
実施例と特許請求の範囲との対応を説明する。Ｓ１２０／Ｓ１３０／Ｓ１７５がテスト信号送信手段、Ｓ１４０〜Ｓ１６０が判定手段、Ｓ１７０／Ｓ１８０〜Ｓ１９０が診断手段、Ｓ２２０がテスト信号返信手段、Ｓ２１０／Ｓ２５０／Ｓ４１０／Ｓ６２０が延長手段、Ｓ３１０が開始信号送信手段、Ｓ４２０が開始信号返信手段、Ｓ５１０が終了信号送信手段、Ｓ６１０が終了信号返信手段、のソフトウェアに相当する。また、エンジンＥＣＵ１０が診断装置、ＡＢＳ／ＥＣＵ２０とエアコンＥＣＵ３０とが通信装置に相当する。また、通常制御用データフレームが制御データ信号に相当する。
【符号の説明】
【００７９】
１…自動車用通信システム、１０…エンジンＥＣＵ、２０…ＡＢＳ／ＥＣＵ、３０…エアコンＥＣＵ、１１・２１・３１…ＣＰＵ、１２・２２・３２…通信ドライバ、１３・３３…終端抵抗、１００…ＣＡＮ−Ｈライン、２００…ＣＡＮ−Ｌライン
【図１】
2011040886.tif 000003
【図２】
2011040886.tif 000004
【図３】
2011040886.tif 000005
【図４】
2011040886.tif 000006
【図５】
2011040886.tif 000007
【図６】
2011040886.tif 000008
【図７】
2011040886.tif 000009
【図８】
2011040886.tif 000010
【図９】
2011040886.tif 000011
【図１０】
2011040886.tif 000012