JP2015192396A - 通信システム及び通信装置 - Google Patents

Abstract

【課題】 他の情報の送受信を妨げることを抑制して故障診断を行うことができる技術を提案する。【解決手段】 Ｓ５にて車載装置１の診断状態を判定し、「待機」と判断されたときには、Ｓ６にて、前回の診断から所定時間経過したか否かを判断する。所定時間が経過していれば、Ｓ７にて、過去一定期間の受信パケット数が所定値以下であるか否かを判断する。受信パケット数が所定値以下であれば、Ｓ８にて応答要求パケットを組み立て、Ｓ１１にて生成したパケットをブロードキャスト通信により外部に送信する。Ｓ５にて「応答送信予約」と判断されたときには、Ｓ１２にて、過去一定期間の受信パケット数が所定値以下であるか否かを判断し、所定値以下であれば（Ｓ１２：ＹＥＳ）、Ｓ１４にて、応答パケットを組み立て、Ｓ１１にて、生成したパケットをブロードキャスト通信により外部に送信する。【選択図】図３

Description

本発明は、車車間通信又は路車間通信などの無線通信が可能な通信手段を備える第１の通信装置と、上記通信手段を備える第２の通信装置と、を含む通信システムに関する。

近年、車車間通信又は路車間通信を用いて外部の車両の走行状態や道路状況に関する情報を取得する技術が提案されている（例えば、特許文献１参照）。

特開２００９−９３３４３号公報

自車両に備えられた通信装置が電波を正しく出力できているか否か、即ち送信機能が正常か否かを確認する方法として、周辺の通信装置に応答要求をブロードキャスト送信し、周辺の通信装置からの応答を受信できた場合に、自車両の通信装置の送信機能が正常であると判断する方法がある。

しかしながら、車車間通信にてこの方法を実施すると、周辺に存在する通信装置の密度によっては大量の応答が発生して本来すべき通信を妨害してしまう可能性がある。
本発明の目的は、他の情報の送受信を妨げることを抑制して故障診断を行うことができる通信システム及び当該通信システムを構成する通信装置を提案することである。

上述した問題を解決するためになされた請求項１に記載の発明は、無線通信が可能な通信手段（１１）を備える第１の通信装置（１）と、上記通信手段を備える第２の通信装置（１）と、を含む通信システムである。

この通信システムは、第１送信手段（２１、Ｓ８、Ｓ１０、Ｓ１１）と、第２送信手段（２１、Ｓ１１、Ｓ１４、Ｓ８２）と、故障判定手段（２１、Ｓ３０、Ｓ３１、Ｓ１１３、Ｓ１１４）と、混雑度判定手段（２１、Ｓ７、Ｓ１２、Ｓ７１、Ｓ７２）と、を有している。

第１送信手段は、第１の通信装置に備えられており、少なくとも該第１の通信装置を特定可能な情報を含む第１の信号を、他の通信装置に送信する。
第２送信手段は、第１の信号を受信した他の通信装置である第２の通信装置に備えられており、第１の信号を受信したときに、第２の信号を第１の通信装置に送信する。

故障判定手段は、第１の通信装置に備えられており、第２の信号の受信状況に応じて、第１の通信装置に備えられる通信手段が故障しているか否かを判定する。
混雑度判定手段は、第１の通信装置に備えられた通信手段と、第２の通信装置に備えられた通信手段と、のうちの少なくともいずれか一方における通信の混雑度を判定する。

そして、上記第１送信手段による第１の信号の送信と、上記第２送信手段による第２の信号の送信と、のうちの少なくともいずれか一方は、混雑度判定手段により判定された混雑度が所定の閾値以下のときに実行されることを特徴とする。

このように構成された通信システムでは、通信の混雑度が所定の閾値以下である場合に故障の判定を行うための通信を行う。従って、その通信によって他の情報の送受信、例えば車両の衝突防止のために必要な情報を取得するためのデータの送受信を妨げてしまうことを抑制できる。

このような通信システムにおいて、上述した第１の通信装置は、例えば車両（１０１）や路側機（１０３）に搭載されて用いられるものとすることができ、上述した第２の通信装置は、例えば車両に搭載されて用いられるものとすることができる。

なお、上述した第１の信号は、上記第１の通信装置に対する応答信号の送信を要求する応答要求信号であり、上述した第２の信号は、上記応答要求信号に対する応答信号であるように構成されていてもよい。

このように構成された通信システムでは、第１の通信装置が応答要求信号を送信したときに第２の通信装置が応答信号を送信するため、故障診断が必要でないタイミングにおける故障診断のための通信量の増加を抑制できる。

また、上述した通信システムは、第２送信手段が上記第２の信号を送信してから、所定の時間が経過したか否かを判定する経過判定手段（２１、Ｓ９６）を備え、上記第２送信手段は、経過判定手段により所定の時間が経過したと判定され、かつ、上記第１の信号を受信したときに、第２の信号を第１の通信装置に送信するように構成されていてもよい。

このように構成された通信システムでは、故障判定手段による故障判定の判断材料となる第２の信号の送信が、所定の時間間隔を空けて実行される。よって、故障診断のための通信量の増加を抑制できる。

また請求項９に記載の発明は、請求項１から請求項８のいずれか１項に記載の通信システムを構成する第１の通信装置の機能を有する通信装置である。この通信装置は、請求項１から請求項８のいずれか１項に記載の通信システムを構成することができる。

また請求項１０に記載の発明は、請求項１から請求項８のいずれか１項に記載の通信システムを構成する第２の通信装置の機能を有する通信装置である。この通信装置は、請求項１から請求項８のいずれか１項に記載の通信システムを構成することができる。

また、本発明は、第１の通信システム、又は第２の通信システムを構成する各手段としてコンピュータを機能させるためのプログラムや、故障診断方法など、種々の形態で実現することができる。

なお、この欄及び特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

第１実施形態の通信システムの概略構成を示すブロック図である。 第１実施形態の診断状態の遷移を説明する図である。 第１実施形態の送信処理を説明するフローチャートである。 第１実施形態の受信処理を説明するフローチャートである。 第２実施形態の受信処理を説明するフローチャートである。 第３実施形態の受信処理を説明するフローチャートである。 第１実施形態と第４実施形態の混雑度の判定方法を説明する図である。 第４実施形態の送信処理を説明するフローチャートである。 第４実施形態の受信処理を説明するフローチャートである。 第５実施形態の診断状態の遷移を説明する図である。 第５実施形態の送信処理を説明するフローチャートである。 第５実施形態の受信処理を説明するフローチャートである。 第６実施形態の送信処理を説明するフローチャートである。 第６実施形態の受信処理を説明するフローチャートである。 その他の実施形態の通信システムの概略構成を示すブロック図である。

以下に本発明の実施形態を図面と共に説明する。なお本発明は、以下の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態をとり得ることはいうまでもない。

［第１実施形態］
（１）全体構成
本実施形態の通信システムは、複数の車載装置１（本発明における第１の通信装置及び第２の通信装置の一例）にて構成されるものであり、通信の混雑度に応じて通信機能の故障診断を実行するものである。混雑度とは、通信の負荷の度合を示すものであって、ネットワークトラフィックの指標となる値である。

車載装置１は、図１に示すように、車両１０１に搭載して用いられるものであり、複数の車載装置１にて通信機能の故障診断を実行するものである。なお以下の説明において、車載装置１を端末と記載する場合がある。自端末とはある処理を実行している主体となる車載装置１であり、送信元端末、送信先端末などは、あるデータ（パケット）の送信元又は送信先の車載装置１である。

車載装置１は、無線通信機１１と、位置特定装置１３と、制御装置１５と、を有している。
無線通信機１１は、制御装置１５にて生成したパケット信号を、アンテナ１７を介して自端末（車載装置１）の周辺の電波の届く通信エリア内に存在する不特定多数の他端末（車載装置１）へ、周期的に無線送信する車車間通信が可能な装置である。また本実施形態では、自端末と他端末とは同様の構成であり、無線通信機１１は他端末からパケット信号を受信することも可能である。

位置特定装置１３は、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）用の人工衛星からの信号を、図示しないＧＰＳアンテナを介して受信し、車載装置１の位置を特定する。なおＧＰＳ信号からは時刻情報も取得される。この位置特定装置１３が、本発明における位置特定手段の一例である。

制御装置１５は、ＣＰＵ２１、ＲＯＭ２３、ＲＡＭ２５、不揮発性メモリ２７、図示しないＩ／Ｏ及びこれらを接続するバスライン等からなる周知のマイクロコンピュータを中心に構成される。ＣＰＵ２１は、ＲＯＭ２３又は不揮発性メモリ２７に記憶されたプログラム等に従い車載装置１を統括制御する。このＣＰＵ２１が、本発明における第１送信手段、第２送信手段、故障判定手段、混雑度判定手段の一例である。

不揮発性メモリ２７により構成される記憶領域上には、失敗カウンタが設けられる。この失敗カウンタは通信の状態が不良であった場合にカウントアップするカウンタであって、所定値を超えたときに無線通信機１１が故障であると診断される。

また後述するＣＰＵ２１による処理にて記憶される失敗カウンタ以外の情報は、ＲＡＭ２５又は不揮発性メモリ２７のいずれかに記憶される。以下、単にメモリと記載する場合は、ＲＡＭ２５又は不揮発性メモリ２７のいずれか又は両方を意味する。

（２）診断の状態遷移
本実施形態の車載装置１は、無線機能（無線通信機１１）の故障診断を実現するために、図２に示すように状態を遷移させる。車載装置１は、初期状態３１からまず待機状態３３に遷移する。車載装置１は、自端末の故障診断を行うために、他端末に対して応答要求を送信し、応答待ち状態３５に遷移する。他端末から応答を受信するか、一定時間応答がなければ、待機状態３３に遷移する。これらの状態は、例えばメモリ上にフラグを立てることで管理できる。

また、他端末が故障診断を行うために自端末に応答要求を送信し、自端末がそれを受信すると、応答送信予約状態３７に遷移する。自端末が応答送信を行うか、応答要求を送信した他端末以外の第３の他端末により応答送信が行われると、自端末は待機状態３３に遷移する。

なお、待機状態３３、応答待ち状態３５、応答送信予約状態３７のいずれにおいても、その他のイベント、つまり故障診断以外の処理は、上述した状態の影響を受けることなく実行可能である。

（３）制御装置１５のＣＰＵ２１による処理
（３−１）送信処理
制御装置１５のＣＰＵ２１が実行する送信処理について、図３に示すフローチャートに基づいて説明する。この送信処理は、所定の時間間隔（例えば１００ｍｓ）にて繰り返し実行される。

（送信処理開始時の処理）
送信処理開始時には、まず以下のＳ１〜Ｓ５を実行する。
Ｓ１では、ＣＰＵ２１は、自端末（車載装置１）の位置を位置特定装置１３により特定する。

Ｓ２では、ＣＰＵ２１は、自端末の搭載された車両の状態情報を取得する。状態情報とは、例えば車内ＣＡＮから取得される様々な情報であって、例としてブレーキやウインカに対する操作やそれらの動作の状態、車速などを示す情報が挙げられる。

Ｓ３では、ＣＰＵ２１は、（例えばＧＰＳ衛星の時刻に同期した）リアルタイムクロックから時刻を取得する。
Ｓ４では、ＣＰＵ２１は、端末ＩＤを生成する。端末ＩＤを定期的に更新することで、プライバシー保護機能を向上させる。

Ｓ５では、ＣＰＵ２１は、車載装置１の診断状態を判定する。図２にて説明したように、診断状態は、「待機」，「応答待ち」，「応答送信予約」のいずれかとなる。待機とは、診断を要求する状態でも診断を要求された状態でもない状態である。応答待ちとは、診断を他の車載装置１に要求している状態である。応答送信予約とは、他の車載装置１から診断を要求された状態である。それぞれの場合について以下に説明する。

（待機時の送信処理）
Ｓ５にて「待機」と判断されたときには、処理がＳ６に移行する。
Ｓ６では、ＣＰＵ２１は、前回の診断から所定時間経過したか否かを判断する。前回の診断の時刻は、例えば、応答要求パケットを送信した時刻（後述するＳ８で組み立てた応答要求パケットをＳ１１にて送信した時刻）や、応答パケットを受信した時刻（後述するＳ３７でＹＥＳと判定された時刻）、失敗カウンタを更新した時刻（後述するＳ２８、Ｓ３８の処理を実行した時刻）などとすることができる。所定時間は、例えば一週間、一か月といった比較的長い時間とすることができる。

上記Ｓ６にて、所定時間が経過していれば（Ｓ６：ＹＥＳ）、処理がＳ７に移行する。一方、所定時間が経過していなければ（Ｓ６：ＮＯ）、処理がＳ１０に移行する。
Ｓ７では、ＣＰＵ２１は、過去一定期間の受信パケット数が所定値以下であるか否かを判断する。この処理の目的は、車載装置１のように車車間通信を行う装置が搭載された車両が周囲に少なく、通信の混雑度が過大でないことを検知することである。つまり、この受信パケット数が、混雑度のパラメータとなる。

過去一定期間の受信パケット数は、後述する受信処理のＳ２２にてカウントされる。一定期間とは、例えば３０秒とすることができる。
上記Ｓ７にて、過去一定期間の受信パケット数が所定値以下であれば（Ｓ７：ＹＥＳ）、処理がＳ８に移行する。一方、所定値以下でなければ（Ｓ７：ＮＯ）、処理がＳ１０に移行する。

Ｓ８では、ＣＰＵ２１は、応答要求パケットを組み立てる。応答要求パケットのメッセージは、Ｓ４にて生成したＩＤである送信元端末ＩＤ、Ｓ１にて特定した位置の位置情報、Ｓ２にて取得した状態情報などにより構成される。このＳ８後、処理がＳ９に移行する。

Ｓ９では、ＣＰＵ２１は、車載装置１の診断状態を「応答待ち」に遷移させる。その後、処理がＳ１１に移行する。
Ｓ１０では、ＣＰＵ２１は、通常パケットを組み立てる。通常パケットは応答要求パケットとはパケットの種別が異なる。通常パケットのメッセージは応答要求パケットと同様に、送信元端末ＩＤ、位置情報、状態情報などにより構成される。このＳ１０の後、処理がＳ１１に移行する。

Ｓ１１では、ＣＰＵ２１は、生成したパケットをブロードキャスト通信により外部に送信する。その後、送信処理を終了する。
（応答待ち時の送信処理）
Ｓ５にて「応答待ち」と判断されたときには、ＣＰＵ２１は、上述したＳ１０にて通常パケットを組み立てる処理を行い、次にＳ１１にてその通常パケットを外部に送信する。

（応答送信予約時の送信処理）
Ｓ５にて「応答送信予約」と判断されたときには、処理がＳ１２に移行する。
Ｓ１２では、ＣＰＵ２１は、過去一定期間の受信パケット数が所定値以下であるか否かを判断する。過去一定期間の受信パケット数が所定値以下でなければ（Ｓ１２：ＮＯ）、処理がＳ１３に移行する。一方、所定値以下であれば（Ｓ１２：ＹＥＳ）、処理がＳ１４に移行する。

Ｓ１３では、ＣＰＵ２１は、車載装置１の診断状態を「待機」に遷移させる。その後、処理がＳ１０に移行し、ＣＰＵ２１は通常パケットを組み立てて送信する。
Ｓ１４では、ＣＰＵ２１は、応答パケットを組み立てる。応答パケットは、通常パケット及び応答要求パケットとはパケットの種別が異なる。応答パケットのメッセージは、Ｓ４にて生成したＩＤである送信元端末ＩＤ、後述するＳ３３にてメモリに記憶した送信先
端末ＩＤ（応答要求の送信元の端末ＩＤ）、Ｓ１にて特定した位置の位置情報、Ｓ２にて取得した状態情報などにより構成される。このＳ１４の後、処理がＳ１５に移行する。

Ｓ１５では、ＣＰＵ２１は、車載装置１の診断状態を「待機」に遷移させる。その後、処理がＳ１１に移行する。
（３−２）受信処理
制御装置１５のＣＰＵ２１が実行する受信処理について、図４に示すフローチャートに基づいて説明する。この受信処理は、所定のイベントが発生したときに実行される。イベントとしては、前回の受信処理開始からカウントするタイマーが満了したこと（一例として１ｓのタイマー満了）や、無線パケットを受信したことなどが挙げられる。

（受信処理開始時の処理）
受信処理開始時には、まず以下のＳ２１〜Ｓ２３を実行する。
Ｓ２１では、ＣＰＵ２１は、無線通信によりパケットを受信したか否かを判断する。パケットを受信していれば（Ｓ２１：ＹＥＳ）、処理がＳ２２に移行する。一方、パケットを受信していなければ（Ｓ２１：ＮＯ）、処理がＳ２５に移行する。

Ｓ２２では、ＣＰＵ２１は、過去一定期間の受信パケット数を更新する。その後、処理がＳ２３に移行する。
Ｓ２３では、ＣＰＵ２１は、Ｓ２１にて受信したと判断された対象となるパケットの種別を判断する。パケットの種別は、「通常パケット」（図中では通常と表記），「応答要求パケット」（図中では応答要求と表記），「応答パケット」（図中では応答と表記）のいずれかとなる。それぞれの場合について以下に説明する。

なお「通常パケット」を受信した場合の処理は、「応答要求パケット」，「応答パケット」を受信した場合にも実行される。「応答要求パケット」，「応答パケット」を受信した場合は、まず、所定の処理が実行され、その後に「通常パケット」を受信したときの処理と同様の処理が実行される。

（通常パケット受信時の処理）
Ｓ２３にて「通常パケット」と判断されたときには、処理がＳ２４に移行する。
Ｓ２４では、ＣＰＵ２１は共通受信処理を開始する。この処理は、受信したパケットに含まれる車両の位置情報や状態情報に基づいて、車両の走行についての制御や乗員への情報通知などが実行される。例えば、他の車両との衝突回避のための制御や、車両の周辺の交通状況の通知などが行われる。共通受信処理を開始した後、処理がＳ２５に移行する。

Ｓ２５では、ＣＰＵ２１は、車載装置１の診断状態を判断する。ここでは、「応答待ち」であるか否かを判断する。診断状態が「応答待ち」であれば、処理がＳ２６に移行する。その他の状態であれば、処理がＳ３０に移行する。なお「応答待ち」とは、上述したＳ８にて組み立てた応答要求パケットをＳ１１にて送信した後であって、未だ応答パケットを受信していない状態である。

Ｓ２６では、ＣＰＵ２１は、ＧＰＳ衛星から送信された信号から時刻を取得する。その後、処理がＳ２７に移行する。
Ｓ２７では、ＣＰＵ２１は、現状態で（即ち、応答要求パケットをＳ１１にて送信して応答待ち状態となってから現時刻まで）所定時間が経過したか否かを判断する。所定時間とは、例えば１ｓとすることができる。所定時間が経過していれば（Ｓ２７：ＹＥＳ）、処理がＳ２８に移行する。一方、所定時間が経過していなければ（Ｓ２７：ＮＯ）、処理がＳ３０に移行する。

Ｓ２８では、ＣＰＵ２１は、失敗カウンタに「１」を加算する。その後、処理がＳ２９に移行する。
Ｓ２９では、ＣＰＵ２１は、車載装置１の診断状態を「待機」に遷移させる。その後、Ｓ３０に移行する。

Ｓ３０では、ＣＰＵ２１は、失敗カウンタが所定値以上であるか否かを判断する。失敗カウンタが所定値以上であれば（Ｓ３０：ＹＥＳ）、処理がＳ３１に移行する。一方、失敗カウンタが所定値以上でなければ（Ｓ３０：ＮＯ）、受信処理を終了する。

Ｓ３１では、ＣＰＵ２１は、通信機能（無線通信機１１）について故障と判定して、車内に設けられたディスプレイやスピーカを用いて乗員に故障であることを通知する。その後、受信処理を終了する。

（応答要求パケット受信時の処理）
Ｓ２３にて「応答要求パケット」と判断されたときには、処理がＳ３２に移行する。
Ｓ３２では、ＣＰＵ２１は、車載装置１の診断状態を判断する。ここでは、「待機」であるか否かを判断する。診断状態が「待機」であれば、処理がＳ３３に移行する。診断状態がその他の状態であれば、処理がＳ２４に移行する。つまり、診断状態が「待機」でなければ、応答要求パケットを受信しても応答しない、ということになる。このＳ３２の後、処理がＳ３３に移行する。

Ｓ３３では、ＣＰＵ２１は、受信した応答要求パケットから端末ＩＤを読出し、メモリに保存する。ここで保存される端末ＩＤは、故障診断をするために応答要求パケットを送信した送信元の端末ＩＤである。この端末ＩＤは、Ｓ１４にて、応答パケットに含まれる送信先端末ＩＤとして利用されるほか、後述するＳ４０にて重複した応答の送信を抑制するために利用される。このＳ３３の後、処理がＳ３４に移行する。

Ｓ３４では、ＣＰＵ２１は、車載装置１の診断状態を「応答送信予約」に遷移させる。その後、処理がＳ２４に移行する。
（応答パケット受信時の処理）
Ｓ２３にて「応答パケット」と判断されたときには、処理がＳ３５に移行する。

Ｓ３５では、ＣＰＵ２１は、受信した応答パケットから、送信先端末ＩＤを読出す。この送信先端末ＩＤは、応答パケットを送信すべき宛先の端末のＩＤとして、送信元の端末がパケットに含めた情報である。このＳ３５の後、処理がＳ３６に移行する。

Ｓ３６では、ＣＰＵ２１は、車載装置１の診断状態を判定する。診断状態が「待機」であれば、処理がＳ２４に移行する。診断状態が「応答待ち」であれば、処理がＳ３７に移行する。診断状態が「応答送信予約」であれば、処理がＳ４０に移行する。

Ｓ３７では、ＣＰＵ２１は、Ｓ３５にて読み出した送信先端末ＩＤが、自端末の端末ＩＤと一致するか否かを判断する。自端末の端末ＩＤとは、過去にＳ４にて生成したものである。読み出した端末ＩＤが自端末の端末ＩＤと一致すれば（Ｓ３７：ＹＥＳ）、処理がＳ３８に移行する。一方、一致しなければ（Ｓ３７：ＮＯ）、処理がＳ２４に移行する。

Ｓ３８では、ＣＰＵ２１は、失敗カウンタから「１」を減算する。減算後のカウンタ値が０以下となる場合は、値を０とする。その後、処理がＳ３９に移行する。
Ｓ３９では、ＣＰＵ２１は、車載装置１の診断状態を「待機」に遷移させる。その後、処理がＳ２４に移行する。

Ｓ４０では、ＣＰＵ２１は、Ｓ３５にて読み出した送信先端末ＩＤが、Ｓ３３にてメモリに保存した端末ＩＤと一致するか否かを判断する。読み出した端末ＩＤがメモリに保存した端末ＩＤと一致すれば（Ｓ４０：ＹＥＳ）、処理がＳ４１に移行する。一方、一致しなければ（Ｓ４０：ＮＯ）、処理がＳ２４に移行する。

Ｓ４１では、ＣＰＵ２１は、車載装置１の診断状態を「待機」に遷移させる。Ｓ４０にてＹＥＳと判断されるということは、送信先端末ＩＤにより特定される端末及び自端末で以外の他の端末が、既に応答パケットを送信しているということである。よって、Ｓ４１の状態遷移により、自端末による応答パケットの送信が行われなくなり、重複した応答パケットの送信を抑制できる。このＳ４１の後、処理がＳ２４に移行する。

（４）効果
上述したように、本実施形態の通信システムは、車車間通信又が可能な無線通信機１１（通信手段）を備え、車両１０１に搭載されて用いられる車載装置１（第１の通信装置及び第２の通信装置）を含む通信システムである。

車載装置１の制御装置１５のＣＰＵ２１は、車載装置１を特定可能な情報（送信元端末ＩＤ）を含む応答要求パケット（第１の信号、応答要求信号）を、車両１０１の外部の車載装置（他の通信装置）に送信する（Ｓ８、Ｓ１１）。

また、応答要求パケットを受信した車載装置１（第２の通信装置）のＣＰＵ２１は、応答要求パケットを受信したときに、応答パケット（第２の信号、応答信号）を送信元の車載装置１（第１の通信装置）に送信する（Ｓ１４、Ｓ１１）。

また、ＣＰＵ２１は、応答パケットの受信状況に応じて、車載装置１に備えられる無線通信機１１が故障しているか否かを判定する（Ｓ３０、Ｓ３１）。より具体的にはＳ２５〜Ｓ２８にて無線通信機１１にて応答パケットを受信できないことと、Ｓ３５〜Ｓ３８にて応答パケットを受信できたことと、に基づいて故障の判定を行う。

そして本実施形態では、ＣＰＵ２１は、無線通信機１１の混雑度を判定し（Ｓ７、Ｓ１２）、混雑度が所定の閾値以下のときに、応答要求パケット及び応答パケットの送信が実行される。混雑度は、過去の一定期間の受信パケット数によって定まるパラメータである。

このように構成された本実施形態の通信システムでは、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信、例えば車両１０１の衝突防止のために必要な情報である車両の状態情報などを取得するためのデータの送受信を妨げてしまうことを抑制できる。

例えば、応答パケットには送信先端末（故障診断を行う車載装置１）の端末ＩＤ情報が付加されているため、その分、通信量が増加してしまうが、本実施形態では通信が混雑しているときにはその通信量の増加を抑制することができる。

換言すると、通信混雑時には端末ＩＤ情報を送らない（通常パケットを送信する）ため、通信量が増加しない。なお厳密にはパケット種別情報を送る必要があるが、通常はその枠が予め用意されているため、それによる通信量の増加はない。

また、応答パケットは所定時間ごとに送信される応答要求パケットを受信したときにのみ送信されるため、故障診断が必要でないタイミングにおける故障診断のための通信量の増加を抑制できる。

また本実施形態では、所定時間内に受信した無線パケットの数が多いほど混雑度を高く判定している。そのため、車載装置１の密度に応じた適切な混雑度の判断を行うことができる。

なお、本実施形態では応答要求パケット及び応答パケットのいずれを送信する際にも混雑度を判定して送信の可否を判断する構成を例示したが、いずれか一方についてのみ混雑度を判定して送信の可否を判断する構成であってもよい。

また、本実施形態では、応答パケットを受信できたこと、及び受信できなかったこと、の両方を勘案して故障を判断する構成を例示したが、いずれか一方のみに基づいて判断してもよい。例えば、応答要求パケットの送信回数に対して応答パケットを受信した割合や、受信しなかった割合をカウントして、その値に基づいて故障を判断することが考えられる。

［第２実施形態］
第２実施形態の車載装置１は、第１実施形態の車載装置１と同様のハードウェア構成であるが、制御装置１５（ＣＰＵ２１）により実行される処理の内容が相違する。本実施形態では、応答パケットを受信したときに、送信元の端末が自端末に近ければ、通信機能が良好であるという判断にその情報を用いない。

（１）制御装置１５のＣＰＵ２１による処理
本実施形態では、送信処理は第１実施形態と同様である。以下、受信処理について図５に示すフローチャートに基づいて説明する。なお、図４のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。

まず、Ｓ３５にてＣＰＵ２１が受信した応答パケットから送信先端末ＩＤを読出した後、本実施形態では処理がＳ５１に移行する。
Ｓ５１では、ＣＰＵ２１は、受信した応答パケットから、端末位置を示す位置情報を読出す。この位置情報は、応答パケットを組み立てた送信元の端末（車載装置１）の位置を示す情報である。このＳ５１の後、処理がＳ３６に移行する。

また、Ｓ３７にて、ＣＰＵ２１がＳ３５にて読み出した送信先端末ＩＤが自端末の端末ＩＤと一致すると判断したときに、処理がＳ５２に移行する。
Ｓ５２では、ＣＰＵ２１は自端末位置を特定する。この処理は図３のＳ１と同様の処理である。その後、処理がＳ５３に移行する。

Ｓ５３では、ＣＰＵ２１は、自端末と、Ｓ５１で読み出した送信元端末と、の間の距離が所定値以上であるか否かを判定する。所定値とは、例えば１００ｍとすることができる。端末間の距離が１００ｍ以上であれば（Ｓ５３：ＹＥＳ）、処理がＳ３８に移行する。一方、端末間の距離が１００ｍ以上でなければ（Ｓ５３：ＮＯ）、Ｓ３８の処理を実行せず、処理がＳ３９に移行する。

（２）効果
本実施形態の通信システムは、第１実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。

また本実施形態においては、応答パケットの送信先端末である車載装置１の位置を特定する位置特定装置１３の特定した位置（Ｓ５２）と、応答パケットに含まれる送信元端末
である車載装置１の位置を示す情報（Ｓ５１）と、から、送信先端末と送信元端末との間隔を判断する（Ｓ５３）。

そして、送信先端末の制御装置１５のＣＰＵ２１は、応答パケットを受信できたこと、及び受信できなかったことに基づいて故障を判断するが、送信先端末の無線通信機１１が当該送信先端末の位置から所定の距離以上離れた位置から送信された応答パケットを受信したときに、応答パケットを受信できたこととして無線通信機１１の故障を判定する。

従って、応答パケットを受信できる範囲が近距離に限られる場合は無線通信機１１が故障であると診断できるため、無線通信機１１の故障診断をより高度に実行することができる。

［第３実施形態］
第３実施形態の車載装置１は、第１実施形態の車載装置１と同様のハードウェア構成であるが、制御装置１５（ＣＰＵ２１）により実行される処理の内容が相違する。本実施形態では、応答要求パケットを受信したときに、送信元の端末が自端末に近ければ、応答パケットを送信しない。

（１）制御装置１５のＣＰＵ２１による処理
本実施形態では、送信処理は第１実施形態と同様である。以下、受信処理について図６に示すフローチャートに基づいて説明する。なお、図４のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。

まず、Ｓ３３にてＣＰＵ２１が受信した応答要求パケットから端末ＩＤを読出し、メモリに保存した後、本実施形態では処理がＳ６１に移行する。
Ｓ６１では、ＣＰＵ２１は、受信した応答要求パケットから、端末位置を示す位置情報を読出す。この位置情報は、応答要求パケットを組み立てた送信元の端末（車載装置１）の位置を示す情報である。このＳ６１の後、処理がＳ６２に移行する。

Ｓ６２では、ＣＰＵ２１は、自端末と、Ｓ６１で読み出した送信元端末と、の間の距離が所定値以上であるか否かを判定する。所定値とは、例えば１００ｍとすることができる。端末間の距離が１００ｍ以上であれば（Ｓ６２：ＹＥＳ）、処理がＳ３４に移行する。一方、端末間の距離が１００ｍ以上でなければ（Ｓ６２：ＮＯ）、Ｓ３４の処理を実行せず、処理がＳ２４に移行する。

（２）効果
本実施形態の通信システムは、第１実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。

また本実施形態においては、応答要求パケットに含まれる送信元端末の位置を示す情報と、応答要求パケットを受信した端末の位置と、から、送信先端末と送信元端末との距離を判断し、所定の距離以上離れた位置から送信された応答要求パケットを受信したとき（Ｓ６２：ＹＥＳ）、応答パケットを応答要求パケットの送信元の端末に送信する。

従って、応答パケットは所定の距離以上離れた位置から送信されているため、遠方からのパケットの受信を確認でき、無線通信機１１の故障診断をより高度に実行することができる。

［第４実施形態］
第４実施形態の車載装置１は、第１実施形態の車載装置１と同様のハードウェア構成であるが、制御装置１５（ＣＰＵ２１）により実行される処理の内容が相違する。本実施形態では、無線通信の混雑度を判断するにあたって、一定期間における受信パケット数ではなく、無線帯域使用率（通信チャネルの使用割合）から混雑度を判定する。

（１）混雑度の判定方法
図７を用いて、第１実施形態との相違を説明する。
第１実施形態では、図７の上段に示すように、パケット数を判断することで通信チャネル（周波数帯域）の混雑度を判断している。つまり、単位時間Ｔ０において受信したパケット数が多いほど混雑しており、単位時間Ｔ０において受信したパケット数がしきい値Ｔｈ＿ｎを超えたときには、混雑と判断され、故障診断は実行されない。

一方、第４実施形態では、図７の下段に示すように、通信チャネルの使用割合で混雑度を判定する。例えば、パケット長が可変の場合には、長時間通信チャネルを占有する可能性があり、このような場合において、端末ｉが電波を出す時間ｔｉが長ければ混雑しているといえる。単位時間Ｔ０におけるチャネルの使用率は（Σｔｉ／Ｔ０）×１００（％）で示され、この使用率がしきい値Ｔｈ＿ｔを超えたときには、混雑と判断される。

（２）制御装置１５のＣＰＵ２１による処理
本実施形態の具体的な処理を図８及び図９に示すフローチャートに基づいて説明する。なお、図４及び図５のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。

図８のフローチャートにおいては、Ｓ６にて、前回の診断から所定時間が経過していれば（Ｓ６：ＹＥＳ）、処理がＳ７１に移行する。
Ｓ７１では、ＣＰＵ２１は、チャネル使用率が所定値以下であるか否かを判断する。チャネル使用率が所定値以下であれば（Ｓ７１：ＹＥＳ）、処理がＳ８に移行する。一方、チャネル使用率が所定値以下でなければ（Ｓ７１：ＮＯ）、処理がＳ１０に移行する。

またＳ５にて「応答送信予約」と判断されたときには、処理がＳ７２に移行する。
Ｓ７２では、ＣＰＵ２１は、チャネル使用率が所定値以下であるか否かを判断する。チャネル使用率が所定値以下でなければ（Ｓ７２：ＮＯ）、処理がＳ１３に移行する。一方、チャネル使用率が所定値以下であれば（Ｓ７２：ＹＥＳ）、処理がＳ１４に移行する。

図９のフローチャートにおいては、図５と比較して、Ｓ２２の処理を実行しない点においてのみ相違する。よって説明を割愛する。
（３）効果
本実施形態の通信システムは、第１実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。

また本実施形態では、無線帯域使用率が高い場合ほど混雑度を高く判定しているため、車載装置１の密度に応じた適切な混雑度の判断を行うことができる。
なお、本実施形態においては、さらに受信信号強度が一定以上の端末が自端末の周辺に存在するか否かを判断し、そのような端末が存在することを条件に、故障診断を実施するように（Ｓ８、Ｓ１４に処理が移行するように）構成されていてもよい。信号強度が低いと通信の確実性が低下するためである。

［第５実施形態］
第５実施形態の車載装置１は、第１実施形態の車載装置１と同様のハードウェア構成で
あるが、制御装置１５（ＣＰＵ２１）により実行される処理の内容が相違する。本実施形態のＣＰＵ２１が、本発明における経過判定手段の一例である。

本実施形態では、故障の判定を行う側の車載装置１から、故障判定のためのトリガとなる信号（応答要求パケット）を送信しない。
また不揮発性メモリ２７により構成される記憶領域上には、失敗カウンタの他に、応答受信カウンタが設けられる。応答受信カウンタは、過去の一定期間内に応答パケットを受信した回数をカウントするカウンタである。

（１）診断の状態遷移
車載装置１は、図１０に示すように、初期状態４１からまず待機状態４３に遷移する。車載装置１は、前回の応答から所定の時間が経過したときに、所定の端末に対して応答送信する（応答パケットを送信する）応答送信予約状態４５に遷移する。自端末が応答送信を行うか、所定の端末以外の第３の他端末により応答送信が行われると、自端末は待機状態４３に遷移する。

なお本実施形態において、応答送信は応答要求をトリガとするものではないため、厳密には応答ではないが、説明の便宜上、応答と記載する。また、前回の応答とは、最後に応答パケットの送信を行ったこと、或いは応答パケットの送信をするために応答送信予約状態になったことを意味する。

（２）制御装置１５のＣＰＵ２１による処理
（２−１）送信処理
制御装置１５のＣＰＵ２１が実行する送信処理について、図１１に示すフローチャートに基づいて説明する。なお、図３のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。

本実施形態では、Ｓ４にて端末ＩＤを生成した後、処理がＳ８１に移行する。
Ｓ８１では、ＣＰＵ２１は、車載装置１の診断状態を判定する。図１０にて説明したように、診断状態は、「待機」，「応答送信予約」のいずれかとなる。ここで「待機」と判断されたときには、処理がＳ１０に移行する。一方、「応答送信予約」と判断されたときは、処理がＳ１２に移行する。

またＳ１２にて過去一定期間の受信パケット数が所定値以下であれば（Ｓ１２：ＹＥＳ）、処理がＳ８２に移行する。
Ｓ８２では、ＣＰＵ２１は、応答パケットを組み立てる。第１実施形態のＳ１４にて組み立てる応答パケットのメッセージには応答要求の送信元の端末ＩＤが含まれる構成であったが、本実施形態ではその送信元の端末ＩＤに変えて、後述するＳ９７にて通常パケットから読出しメモリに記憶された、その通常パケットの送信元の端末ＩＤが含まれる。

（２−２）受信処理
制御装置１５のＣＰＵ２１が実行する受信処理について、図１２に示すフローチャートに基づいて説明する。この受信処理は、所定のイベントが発生したときに実行される。イベントとしては、前回の受信処理開始からカウントするタイマーが満了したこと（一例として１ｓのタイマー満了）や、無線パケットを受信したことなどが挙げられる。

（受信処理開始時の処理）
受信処理開始時には、まず以下のＳ９１〜Ｓ９４を実行する。
Ｓ９１では、ＣＰＵ２１は、無線通信によりパケットを受信したか否かを判断する。パケットを受信していれば（Ｓ９１：ＹＥＳ）、処理がＳ９２に移行する。一方、パケット
を受信していなければ（Ｓ９１：ＮＯ）、処理がＳ１０７に移行する。

Ｓ９２では、ＣＰＵ２１は、過去一定期間の受信パケット数を更新する。その後、処理がＳ９３に移行する。
Ｓ９３では、ＣＰＵ２１は、ＧＰＳ衛星から送信された信号から時刻を取得する。その後、処理がＳ９４に移行する。

Ｓ９４では、ＣＰＵ２１は、Ｓ９１にて受信したと判断された対象となるパケットの種別を判断する。パケットの種別は、「通常パケット」（図中では通常と表記），「応答パケット」（図中では応答と表記）のいずれかとなる。それぞれの場合について以下に説明する。なお、Ｓ１０７以降の処理は共通であるため、共通の処理については別途説明する。

（通常パケット受信時の処理）
Ｓ９４にて「通常パケット」と判断されたときには、処理がＳ９５に移行する。
Ｓ９５では、ＣＰＵ２１は、車載装置１の診断状態を判定する。診断状態が「待機」であれば、処理がＳ９６に移行する。診断状態が「応答送信予約」であれば、処理がＳ１００に移行する。

Ｓ９６では、ＣＰＵ２１は、現在時刻が次回応答時刻を過ぎたか否かを判断する。次回応答時刻は、後述するＳ９９にて設定される。次回応答時刻を過ぎていれば（Ｓ９６：ＹＥＳ）、処理がＳ９７に移行する。一方、次回応答時刻を過ぎていなければ（Ｓ９６：ＮＯ）、処理がＳ１００に移行する。

Ｓ９７では、ＣＰＵ２１は、受信した通常パケットから端末ＩＤを読出し、メモリに保存する。ここで保存される端末ＩＤは、通常パケットを送信した送信元の端末ＩＤである。この送信元の端末が、故障診断を実行する端末である。またこの端末ＩＤは、Ｓ８２にて、応答パケットに含まれる送信先端末ＩＤとして利用されるほか、後述するＳ１０５にて重複した応答の送信を抑制するために利用される。このＳ９７の後、処理がＳ９８に移行する。

Ｓ９８では、ＣＰＵ２１は、車載装置１の診断状態を「応答送信予約」に遷移させる。その後、処理がＳ９９に移行する。
Ｓ９９では、ＣＰＵ２１は、現在の時刻に対して所定の最低間隔を加え、さらにランダム時間を加えた時刻を、次回応答時刻としてメモリに記録する。最低間隔とは例えば１ｈとすることができる。最低間隔を長く設定する場合には、次回応答時刻は不揮発性メモリ２７に記録するとよい。このＳ９９の後、処理がＳ１００に移行する。

Ｓ１００では、ＣＰＵ２１は共通受信処理を開始する。この処理は、受信したパケットに含まれる車両の位置情報や状態情報に基づいて、車両に走行についての処理や乗員への情報通知などが実行される。例えば、他の車両との衝突回避のための制御や、車両の周辺の交通状況の通知などが行われる。共通受信処理を開始した後、処理がＳ１０７に移行する。

（応答パケット受信時の処理）
Ｓ９４にて「応答パケット」と判断されたときには、処理がＳ１０１に移行する。
Ｓ１０１では、ＣＰＵ２１は、受信した応答パケットから、送信先端末ＩＤを読出す。この送信先端末ＩＤは、応答パケットを送信すべき宛先の端末のＩＤとして、送信元の端末（車載装置１）がパケットに含めた情報である。このＳ１０１の後、処理がＳ１０２に移行する。

Ｓ１０２では、ＣＰＵ２１は、Ｓ１０１にて読み出した送信先端末ＩＤが、自端末の端末ＩＤと一致するか否かを判断する。自端末の端末ＩＤとは、過去にＳ４にて生成したものである。読み出した端末ＩＤが自端末の端末ＩＤと一致すれば（Ｓ１０２：ＹＥＳ）、処理がＳ１０３に移行する。一方、一致しなければ（Ｓ１０２：ＮＯ）、処理がＳ１０４に移行する。

Ｓ１０３では、ＣＰＵ２１は、過去の一定期間内に受信した応答パケットであって送信先端末ＩＤが自端末の端末ＩＤと一致する応答パケットの数に、応答受信カウンタを更新する。その後、処理がＳ１００に移行する。

Ｓ１０４では、ＣＰＵ２１は、車載装置１の診断状態を判定する。診断状態が「待機」であれば、処理がＳ１００に移行する。診断状態が「応答送信予約」であれば、処理がＳ１０５に移行する。

Ｓ１０５では、ＣＰＵ２１は、Ｓ１０１にて読み出した送信先端末ＩＤが、Ｓ９７にてメモリに保存した端末ＩＤと一致するか否かを判断する。読み出した端末ＩＤがメモリに保存した端末ＩＤと一致すれば（Ｓ１０５：ＹＥＳ）、処理がＳ１０６に移行する。一方、一致しなければ（Ｓ１０５：ＮＯ）、処理がＳ１００に移行する。

Ｓ１０６では、ＣＰＵ２１は、車載装置１の診断状態を「待機」に遷移させる。Ｓ１０５にてＹＥＳと判断されるということは、送信先端末ＩＤを有する車載装置１及び自端末である車載装置１以外の他の車載装置１が、既に応答パケットを送信しているということである。よって、Ｓ１０６の状態遷移により、自端末による応答パケットの送信が行われなくなり、重複した応答パケットの送信を抑制できる。このＳ１０６の後、処理がＳ１００に移行する。

（共通の処理）
Ｓ１０７では、ＣＰＵ２１は、現在時刻が次回判定時刻を過ぎたか否かを判断する。次回判定時刻は、後述するＳ１１２にて設定される。次回判定時刻を過ぎていれば（Ｓ１０７：ＹＥＳ）、処理がＳ１０８に移行する。一方、次回判定時刻を過ぎていなければ（Ｓ１０７：ＮＯ）、受信処理を終了する。

Ｓ１０８では、ＣＰＵ２１は、過去の一定期間の受信パケット数が上限値と下限値（０以上）で指定された所定値範囲であるか否かを判断する。この処理の目的は、車載装置１のように車車間通信を行う装置が搭載された車両が周囲に少ないこと、即ち通信の混雑度が過大でないことを検知することである。過去の一定期間の受信パケット数は、Ｓ９２にてカウントされている。なお過去の一定期間のパケット数が下限値より小さければ、周囲に車車間通信が可能な装置が存在しないため故障診断に適する状況でないこととなる。

このＳ１０８にて、過去の一定期間の受信パケット数が所定値範囲であれば（Ｓ１０８：ＹＥＳ）、処理がＳ１０９に移行する。一方、所定値範囲でなければ（Ｓ１０８：ＮＯ）、受信処理を終了する。

Ｓ１０９では、ＣＰＵ２１は、応答受信カウンタが所定値以上であるか否かを判断する。応答受信カウンタが所定値以上であれば（Ｓ１０９：ＹＥＳ）、処理がＳ１１０に移行する。一方、応答受信カウンタが所定値以上でなければ（Ｓ１０９：ＮＯ）、処理がＳ１１１に移行する。

Ｓ１１０では、ＣＰＵ２１は、失敗カウンタから「１」を減算する。減算後のカウンタ
値が０以下となる場合は、値を０とする。その後、処理がＳ１１２に移行する。
Ｓ１１１では、ＣＰＵ２１は、失敗カウンタに「１」を加算する。その後、処理がＳ１１２に移行する。

Ｓ１１２では、ＣＰＵ２１は、現在の時刻に対して所定の判定間隔を加えた時刻を、次回判定時刻としてメモリに記録する。判定間隔とは例えば１ｈとすることができる。判定間隔を長く設定する場合には、次回判定時刻は不揮発性メモリ２７に記録するとよい。このＳ１１２の後、処理がＳ１１３に移行する。

Ｓ１１３では、ＣＰＵ２１は、失敗カウンタが所定値以上であるか否かを判断する。失敗カウンタが所定値以上であれば（Ｓ１１３：ＹＥＳ）、処理がＳ１１４に移行する。一方、失敗カウンタが所定値以上でなければ（Ｓ１１３：ＮＯ）、受信処理を終了する。

Ｓ１１４では、ＣＰＵ２１は、通信機能（無線通信機１１）について故障と判定して、車内に設けられたディスプレイやスピーカを用いて乗員に故障であることを通知する。その後、受信処理を終了する。

（３）効果
本実施形態の通信システムは、第１実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。

また本実施形態では、制御装置１５のＣＰＵ２１は応答要求パケットの送信を実行せず、応答パケットを送信してから次回応答時刻を経過したか否か（所定の時間が経過したか否か）を判定し、次回応答時刻の経過後であって（Ｓ９６：ＹＥＳ）、通常パケットを受信したとき（Ｓ９４：ＹＥＳ）に、応答パケットを通常パケットの送信元端末に送信する。

従って、応答要求パケットを送信しなくとも、応答パケットの送信元の端末である車載装置１にて適宜時間間隔を空けて応答パケットを送信することができる。
［第６実施形態］
第６実施形態の車載装置１は、第１実施形態の車載装置１と同様のハードウェア構成であるが、制御装置１５（ＣＰＵ２１）により実行される処理の内容が相違する。本実施形態では、他の端末（車載装置１）が自端末を中心とした所定の範囲内に存在するときに、応答要求パケットを送信する。本実施形態のＣＰＵ２１が、本発明における存在判定手段の一例である。

（１）制御装置１５のＣＰＵ２１による処理
本実施形態の送信処理について、図１３に示すフローチャートに基づいて説明する。なお、図４のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。

本処理では、Ｓ７にて過去一定期間の受信パケット数が所定値以下と判断されたときに、処理がＳ１２１に移行する。
Ｓ１２１では、ＣＰＵ２１は、他の端末が、自端末を中心とした所定の範囲内に存在するか否かを判定する。ここでは、過去の一定期間の間に実行された後述するＳ１２２にて読み出したパケットの送信元端末の位置と、Ｓ１にて特定した自端末の位置と、から所定の範囲内に端末が存在するか否かを判定する。

このＳ１２１にて、所定の範囲内に他の端末が存在するとき（Ｓ１２１：ＹＥＳ）、処
理がＳ８に移行し、応答要求パケットを組み立てる。一方、所定の範囲内に他の端末が存在しないとき（Ｓ１２１：ＮＯ）、処理がＳ１０に移行する。

次に、本実施形態の受信処理について、図１４に示すフローチャートに基づいて説明する。なお、図５のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。

本処理では、Ｓ２４の後、Ｓ１２２に移行する。
Ｓ１２２では、ＣＰＵ２１は、受信したパケットから送信元の端末の位置情報を読出し、メモリに一定期間記憶する。その後、処理がＳ２５に移行する。

（２）効果
本実施形態の通信システムは、第１実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。

また本実施形態においては、自端末を中心とした所定の範囲内に他の端末が存在するときに応答要求パケットを組み立てて送信する。
従って、応答要求パケットを受信可能である車載装置１が周辺に存在しない場合にもかかわらず応答要求パケットを送信してしまうことを抑制でき、応答パケットが受信されないことで故障と判断してしまったり、距離が遠いことにより通信の確実性が低下してしまったりすることを抑制でき、故障診断の信頼性を向上させることができる。

なお、本実施形態では受信したパケットから送信元端末の位置を読み出すことで他端末の存在を判断する構成を例示したが、それ以外の手法で他端末を検出し、所定範囲に存在するか否かを判断するように構成されていてもよい。

例えば、単に他端末からのパケットを受信したことにより所定範囲内（この場合には通信可能範囲）の他端末の存在を検出してもよいし、別の第３の端末から、他端末の存在情報を入手することで他端末の存在を検出してもよい。

［その他の実施形態］
以上本発明の実施形態について説明したが、本発明は、上記各実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態をとり得ることはいうまでもない。

例えば、上記各実施形態においては、プログラムを除き同様のハードウェア構成を有する複数の車載装置１によってなる通信システムの構成を例示したが、必要な機能を満たしていれば、一部が異なる装置であってもよい。例えば、図１５に示すように、路側機１０３に車載装置１と同様のハードウェアを有する通信装置１０５が搭載されており、通信装置１０５が車載装置１と同様の動作を実行することで故障診断を実現する構成であってもよい。この場合、路車間通信を行う装置により本発明が実現される。また、路側機に備えられる通信装置同士や、車両以外の移動体（一例として歩行者）が有する通信装置により本発明が実現されてもよい。

また、一方の車載装置が応答要求パケットを送信する機能、応答パケットを受信して故障を診断する機能、を有しており、他方の車載装置が応答要求パケットを受信して応答パケットを送信する機能、を有する構成であってもよい。その場合は、上述した一方の車載装置の無線通信機の故障診断を実現することができる。

また上記各実施形態では、通信の混雑度を判定するためにパケット受信数や無線帯域使用率を用いる構成を例示したが、ネットワークトラフィックの状態を測定又は推定できる、上記以外の方法を用いて混雑度を判定する構成としてもよい。例えば、トラフィックの混雑状況を測定する他の測定装置からトラフィックの混雑状況の情報を取得し、その情報に基づいて混雑度を判定するように構成されていてもよいし、混雑度として直接利用できる情報を取得する構成であってもよい。

また上記各実施形態では、車車間通信を実行可能な車載装置１同士で直接的に通信を行う構成を例示したが、間接的に通信を行うものであってもよい。例えば、車載装置１が道路沿いに配置される路側機と路車間通信を行っており、路側機を介して車両間の通信が実現される構成であってもよい。また通信の方式や送信されるデータの構成も特に限定されず、様々なものを採用することができる。

また、上述した車載装置が備える各手段としての機能は、プログラムにより、無線通信装置を有するコンピュータ、又は無線通信装置と接続可能なコンピュータに実現させることができる。

上記プログラムは、コンピュータによる処理に適した命令の順番付けられた列からなるものであって、コンピュータに組み込まれるＲＯＭやＲＡＭなどに記憶され、これらからコンピュータにロードされて用いられてもよいし、各種記録媒体や通信回線を介してコンピュータにロードされ用いられるものであってもよい。

記録媒体としては、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の光ディスク、磁気ディスク、半導体製メモリ等が挙げられる。
また制御装置は、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などのプログラマブルロジックデバイスや、ディスクリート回路であってもよい。

１…車載装置、１１…無線通信機、１３…位置特定装置、１５…制御装置、２１…ＣＰＵ、１０１…車両、１０３…路側機、１０５…通信装置

Claims (10)

1. 無線通信が可能な通信手段（１１）を備える第１の通信装置（１）と、前記通信手段を備える第２の通信装置（１）と、を含む通信システムであって、
   前記第１の通信装置に備えられ、少なくとも該第１の通信装置を特定可能な情報を含む第１の信号を、他の通信装置に送信する第１送信手段（２１、Ｓ８、Ｓ１０、Ｓ１１）と、
   前記第１の信号を受信した前記他の通信装置である前記第２の通信装置に備えられ、前記第１の信号を受信したときに、第２の信号を前記第１の通信装置に送信する第２送信手段（２１、Ｓ１４、Ｓ８２、Ｓ１１）と、
   前記第１の通信装置に備えられ、前記第２の信号の受信状況に応じて、前記第１の通信装置に備えられる前記通信手段が故障しているか否かを判定する故障判定手段（２１、Ｓ３０、Ｓ３１、Ｓ１１３、Ｓ１１４）と、
   前記第１の通信装置に備えられた前記通信手段と、前記第２の通信装置に備えられた前記通信手段と、のうちの少なくともいずれか一方における通信の混雑度を判定する混雑度判定手段（２１、Ｓ７、Ｓ１２、Ｓ７１、Ｓ７２）と、を有し、
   前記第１送信手段による前記第１の信号の送信と、前記第２送信手段による前記第２の信号の送信と、のうちの少なくともいずれか一方は、前記混雑度判定手段により判定された混雑度が所定の閾値以下のときに実行される
   ことを特徴とする通信システム。
2. 前記第１の信号は、前記第１の通信装置に対する応答信号の送信を要求する応答要求信号であり、
   前記第２の信号は、前記応答要求信号に対する応答信号である
   ことを特徴とする請求項２に記載の通信システム。
3. 前記第２の通信装置に備えられ、前記第２送信手段が前記第２の信号を送信してから、所定の時間が経過したか否かを判定する経過判定手段（２１、Ｓ９６）を有し、
   前記第２送信手段は、前記経過判定手段により所定の時間が経過したと判定され（Ｓ９６：ＹＥＳ）、かつ、前記第１の信号を受信したとき（Ｓ９４：ＹＥＳ）に、前記第２の信号を前記第１の通信装置に送信する
   ことを特徴とする請求項２に記載の通信システム。
4. 前記混雑度判定手段は、所定時間内に受信した無線パケットの数が多いほど、又は、無線帯域使用率が高いほど、前記混雑度を高く判定する
   ことを特徴とする請求項１から請求項３のいずれか１項に記載の通信システム。
5. 前記第１の通信装置に備えられ、該第１の通信装置を中心とした所定の範囲内に、他の通信装置が存在するか否かを判定する存在判定手段（２１、Ｓ１２１、Ｓ１２２）を備え、
   前記第１送信手段は、前記存在判定手段により前記所定の範囲内に前記他の通信装置が存在すると判定されているとき（Ｓ１２１：ＹＥＳ）に、前記応答要求信号を送信する
   ことを特徴とする請求項２、請求項２を引用する請求項３、請求項２を引用する請求項４のいずれか１項に記載の通信システム。
6. 前記故障判定手段は、前記第１の通信装置に備えられる前記通信手段が前記第２の信号を受信できたこと（Ｓ３７：ＹＥＳ）及び／又は受信できないこと（Ｓ２７：ＹＥＳ）に基づいて前記通信手段の故障を判定する
   ことを特徴とする請求項１から請求項５のいずれか１項に記載の通信システム。
7. 前記第１の通信装置及び前記第２の通信装置は、自らの位置を特定する位置特定手段（１３）を備え、
   前記第２の信号には、前記第２の通信装置の位置を示す情報が含まれており、
   前記故障判定手段は、前記第１の通信装置に備えられる前記通信手段が前記第１の通信装置の位置から所定の距離以上離れた位置から送信された前記第２の信号を受信したとき（Ｓ５３：ＹＥＳ）に、前記第２の信号を受信できたとして前記通信手段の故障を判定する
   ことを特徴とする請求項６に記載の通信システム。
8. 前記第１の通信装置及び前記第２の通信装置は、自らの位置を特定する位置特定手段（１３）を備え、
   前記第１の信号には、前記第１の通信装置の位置を示す情報が含まれており、
   前記第２送信手段は、前記第２の通信装置に備えられる前記通信手段が前記第２の通信装置の位置から所定の距離以上離れた位置から送信された前記第１の信号を受信したとき（Ｓ６２：ＹＥＳ）に、前記第２の信号を前記第１の通信装置に送信する
   ことを特徴とする請求項６に記載の通信システム。
9. 請求項１から請求項８のいずれか１項に記載の通信システムを構成する前記第１の通信装置の機能を有する通信装置。
10. 請求項１から請求項８のいずれか１項に記載の通信システムを構成する前記第２の通信装置の機能を有する通信装置。

Images