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

通信システム及び通信装置 Download PDF

Info

Publication number
JP2015192396A
JP2015192396A JP2014069763A JP2014069763A JP2015192396A JP 2015192396 A JP2015192396 A JP 2015192396A JP 2014069763 A JP2014069763 A JP 2014069763A JP 2014069763 A JP2014069763 A JP 2014069763A JP 2015192396 A JP2015192396 A JP 2015192396A
Authority
JP
Japan
Prior art keywords
communication
communication device
signal
response
transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2014069763A
Other languages
English (en)
Other versions
JP6075319B2 (ja
Inventor
淳一郎 舩橋
Junichiro Funabashi
淳一郎 舩橋
伊藤 敏之
Toshiyuki Ito
敏之 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Denso Corp
Original Assignee
Denso Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Denso Corp filed Critical Denso Corp
Priority to JP2014069763A priority Critical patent/JP6075319B2/ja
Priority to US14/658,570 priority patent/US9985854B2/en
Publication of JP2015192396A publication Critical patent/JP2015192396A/ja
Application granted granted Critical
Publication of JP6075319B2 publication Critical patent/JP6075319B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • H04W4/046
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/029Location-based management or tracking services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882Utilisation of link capacity

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)

Abstract

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

Description

本発明は、車車間通信又は路車間通信などの無線通信が可能な通信手段を備える第1の通信装置と、上記通信手段を備える第2の通信装置と、を含む通信システムに関する。
近年、車車間通信又は路車間通信を用いて外部の車両の走行状態や道路状況に関する情報を取得する技術が提案されている(例えば、特許文献1参照)。
特開2009−93343号公報
自車両に備えられた通信装置が電波を正しく出力できているか否か、即ち送信機能が正常か否かを確認する方法として、周辺の通信装置に応答要求をブロードキャスト送信し、周辺の通信装置からの応答を受信できた場合に、自車両の通信装置の送信機能が正常であると判断する方法がある。
しかしながら、車車間通信にてこの方法を実施すると、周辺に存在する通信装置の密度によっては大量の応答が発生して本来すべき通信を妨害してしまう可能性がある。
本発明の目的は、他の情報の送受信を妨げることを抑制して故障診断を行うことができる通信システム及び当該通信システムを構成する通信装置を提案することである。
上述した問題を解決するためになされた請求項1に記載の発明は、無線通信が可能な通信手段(11)を備える第1の通信装置(1)と、上記通信手段を備える第2の通信装置(1)と、を含む通信システムである。
この通信システムは、第1送信手段(21、S8、S10、S11)と、第2送信手段(21、S11、S14、S82)と、故障判定手段(21、S30、S31、S113、S114)と、混雑度判定手段(21、S7、S12、S71、S72)と、を有している。
第1送信手段は、第1の通信装置に備えられており、少なくとも該第1の通信装置を特定可能な情報を含む第1の信号を、他の通信装置に送信する。
第2送信手段は、第1の信号を受信した他の通信装置である第2の通信装置に備えられており、第1の信号を受信したときに、第2の信号を第1の通信装置に送信する。
故障判定手段は、第1の通信装置に備えられており、第2の信号の受信状況に応じて、第1の通信装置に備えられる通信手段が故障しているか否かを判定する。
混雑度判定手段は、第1の通信装置に備えられた通信手段と、第2の通信装置に備えられた通信手段と、のうちの少なくともいずれか一方における通信の混雑度を判定する。
そして、上記第1送信手段による第1の信号の送信と、上記第2送信手段による第2の信号の送信と、のうちの少なくともいずれか一方は、混雑度判定手段により判定された混雑度が所定の閾値以下のときに実行されることを特徴とする。
このように構成された通信システムでは、通信の混雑度が所定の閾値以下である場合に故障の判定を行うための通信を行う。従って、その通信によって他の情報の送受信、例えば車両の衝突防止のために必要な情報を取得するためのデータの送受信を妨げてしまうことを抑制できる。
このような通信システムにおいて、上述した第1の通信装置は、例えば車両(101)や路側機(103)に搭載されて用いられるものとすることができ、上述した第2の通信装置は、例えば車両に搭載されて用いられるものとすることができる。
なお、上述した第1の信号は、上記第1の通信装置に対する応答信号の送信を要求する応答要求信号であり、上述した第2の信号は、上記応答要求信号に対する応答信号であるように構成されていてもよい。
このように構成された通信システムでは、第1の通信装置が応答要求信号を送信したときに第2の通信装置が応答信号を送信するため、故障診断が必要でないタイミングにおける故障診断のための通信量の増加を抑制できる。
また、上述した通信システムは、第2送信手段が上記第2の信号を送信してから、所定の時間が経過したか否かを判定する経過判定手段(21、S96)を備え、上記第2送信手段は、経過判定手段により所定の時間が経過したと判定され、かつ、上記第1の信号を受信したときに、第2の信号を第1の通信装置に送信するように構成されていてもよい。
このように構成された通信システムでは、故障判定手段による故障判定の判断材料となる第2の信号の送信が、所定の時間間隔を空けて実行される。よって、故障診断のための通信量の増加を抑制できる。
また請求項9に記載の発明は、請求項1から請求項8のいずれか1項に記載の通信システムを構成する第1の通信装置の機能を有する通信装置である。この通信装置は、請求項1から請求項8のいずれか1項に記載の通信システムを構成することができる。
また請求項10に記載の発明は、請求項1から請求項8のいずれか1項に記載の通信システムを構成する第2の通信装置の機能を有する通信装置である。この通信装置は、請求項1から請求項8のいずれか1項に記載の通信システムを構成することができる。
また、本発明は、第1の通信システム、又は第2の通信システムを構成する各手段としてコンピュータを機能させるためのプログラムや、故障診断方法など、種々の形態で実現することができる。
なお、この欄及び特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
第1実施形態の通信システムの概略構成を示すブロック図である。 第1実施形態の診断状態の遷移を説明する図である。 第1実施形態の送信処理を説明するフローチャートである。 第1実施形態の受信処理を説明するフローチャートである。 第2実施形態の受信処理を説明するフローチャートである。 第3実施形態の受信処理を説明するフローチャートである。 第1実施形態と第4実施形態の混雑度の判定方法を説明する図である。 第4実施形態の送信処理を説明するフローチャートである。 第4実施形態の受信処理を説明するフローチャートである。 第5実施形態の診断状態の遷移を説明する図である。 第5実施形態の送信処理を説明するフローチャートである。 第5実施形態の受信処理を説明するフローチャートである。 第6実施形態の送信処理を説明するフローチャートである。 第6実施形態の受信処理を説明するフローチャートである。 その他の実施形態の通信システムの概略構成を示すブロック図である。
以下に本発明の実施形態を図面と共に説明する。なお本発明は、以下の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態をとり得ることはいうまでもない。
[第1実施形態]
(1)全体構成
本実施形態の通信システムは、複数の車載装置1(本発明における第1の通信装置及び第2の通信装置の一例)にて構成されるものであり、通信の混雑度に応じて通信機能の故障診断を実行するものである。混雑度とは、通信の負荷の度合を示すものであって、ネットワークトラフィックの指標となる値である。
車載装置1は、図1に示すように、車両101に搭載して用いられるものであり、複数の車載装置1にて通信機能の故障診断を実行するものである。なお以下の説明において、車載装置1を端末と記載する場合がある。自端末とはある処理を実行している主体となる車載装置1であり、送信元端末、送信先端末などは、あるデータ(パケット)の送信元又は送信先の車載装置1である。
車載装置1は、無線通信機11と、位置特定装置13と、制御装置15と、を有している。
無線通信機11は、制御装置15にて生成したパケット信号を、アンテナ17を介して自端末(車載装置1)の周辺の電波の届く通信エリア内に存在する不特定多数の他端末(車載装置1)へ、周期的に無線送信する車車間通信が可能な装置である。また本実施形態では、自端末と他端末とは同様の構成であり、無線通信機11は他端末からパケット信号を受信することも可能である。
位置特定装置13は、GPS(Global Positioning System)用の人工衛星からの信号を、図示しないGPSアンテナを介して受信し、車載装置1の位置を特定する。なおGPS信号からは時刻情報も取得される。この位置特定装置13が、本発明における位置特定手段の一例である。
制御装置15は、CPU21、ROM23、RAM25、不揮発性メモリ27、図示しないI/O及びこれらを接続するバスライン等からなる周知のマイクロコンピュータを中心に構成される。CPU21は、ROM23又は不揮発性メモリ27に記憶されたプログラム等に従い車載装置1を統括制御する。このCPU21が、本発明における第1送信手段、第2送信手段、故障判定手段、混雑度判定手段の一例である。
不揮発性メモリ27により構成される記憶領域上には、失敗カウンタが設けられる。この失敗カウンタは通信の状態が不良であった場合にカウントアップするカウンタであって、所定値を超えたときに無線通信機11が故障であると診断される。
また後述するCPU21による処理にて記憶される失敗カウンタ以外の情報は、RAM25又は不揮発性メモリ27のいずれかに記憶される。以下、単にメモリと記載する場合は、RAM25又は不揮発性メモリ27のいずれか又は両方を意味する。
(2)診断の状態遷移
本実施形態の車載装置1は、無線機能(無線通信機11)の故障診断を実現するために、図2に示すように状態を遷移させる。車載装置1は、初期状態31からまず待機状態33に遷移する。車載装置1は、自端末の故障診断を行うために、他端末に対して応答要求を送信し、応答待ち状態35に遷移する。他端末から応答を受信するか、一定時間応答がなければ、待機状態33に遷移する。これらの状態は、例えばメモリ上にフラグを立てることで管理できる。
また、他端末が故障診断を行うために自端末に応答要求を送信し、自端末がそれを受信すると、応答送信予約状態37に遷移する。自端末が応答送信を行うか、応答要求を送信した他端末以外の第3の他端末により応答送信が行われると、自端末は待機状態33に遷移する。
なお、待機状態33、応答待ち状態35、応答送信予約状態37のいずれにおいても、その他のイベント、つまり故障診断以外の処理は、上述した状態の影響を受けることなく実行可能である。
(3)制御装置15のCPU21による処理
(3−1)送信処理
制御装置15のCPU21が実行する送信処理について、図3に示すフローチャートに基づいて説明する。この送信処理は、所定の時間間隔(例えば100ms)にて繰り返し実行される。
(送信処理開始時の処理)
送信処理開始時には、まず以下のS1〜S5を実行する。
S1では、CPU21は、自端末(車載装置1)の位置を位置特定装置13により特定する。
S2では、CPU21は、自端末の搭載された車両の状態情報を取得する。状態情報とは、例えば車内CANから取得される様々な情報であって、例としてブレーキやウインカに対する操作やそれらの動作の状態、車速などを示す情報が挙げられる。
S3では、CPU21は、(例えばGPS衛星の時刻に同期した)リアルタイムクロックから時刻を取得する。
S4では、CPU21は、端末IDを生成する。端末IDを定期的に更新することで、プライバシー保護機能を向上させる。
S5では、CPU21は、車載装置1の診断状態を判定する。図2にて説明したように、診断状態は、「待機」,「応答待ち」,「応答送信予約」のいずれかとなる。待機とは、診断を要求する状態でも診断を要求された状態でもない状態である。応答待ちとは、診断を他の車載装置1に要求している状態である。応答送信予約とは、他の車載装置1から診断を要求された状態である。それぞれの場合について以下に説明する。
(待機時の送信処理)
S5にて「待機」と判断されたときには、処理がS6に移行する。
S6では、CPU21は、前回の診断から所定時間経過したか否かを判断する。前回の診断の時刻は、例えば、応答要求パケットを送信した時刻(後述するS8で組み立てた応答要求パケットをS11にて送信した時刻)や、応答パケットを受信した時刻(後述するS37でYESと判定された時刻)、失敗カウンタを更新した時刻(後述するS28、S38の処理を実行した時刻)などとすることができる。所定時間は、例えば一週間、一か月といった比較的長い時間とすることができる。
上記S6にて、所定時間が経過していれば(S6:YES)、処理がS7に移行する。一方、所定時間が経過していなければ(S6:NO)、処理がS10に移行する。
S7では、CPU21は、過去一定期間の受信パケット数が所定値以下であるか否かを判断する。この処理の目的は、車載装置1のように車車間通信を行う装置が搭載された車両が周囲に少なく、通信の混雑度が過大でないことを検知することである。つまり、この受信パケット数が、混雑度のパラメータとなる。
過去一定期間の受信パケット数は、後述する受信処理のS22にてカウントされる。一定期間とは、例えば30秒とすることができる。
上記S7にて、過去一定期間の受信パケット数が所定値以下であれば(S7:YES)、処理がS8に移行する。一方、所定値以下でなければ(S7:NO)、処理がS10に移行する。
S8では、CPU21は、応答要求パケットを組み立てる。応答要求パケットのメッセージは、S4にて生成したIDである送信元端末ID、S1にて特定した位置の位置情報、S2にて取得した状態情報などにより構成される。このS8後、処理がS9に移行する。
S9では、CPU21は、車載装置1の診断状態を「応答待ち」に遷移させる。その後、処理がS11に移行する。
S10では、CPU21は、通常パケットを組み立てる。通常パケットは応答要求パケットとはパケットの種別が異なる。通常パケットのメッセージは応答要求パケットと同様に、送信元端末ID、位置情報、状態情報などにより構成される。このS10の後、処理がS11に移行する。
S11では、CPU21は、生成したパケットをブロードキャスト通信により外部に送信する。その後、送信処理を終了する。
(応答待ち時の送信処理)
S5にて「応答待ち」と判断されたときには、CPU21は、上述したS10にて通常パケットを組み立てる処理を行い、次にS11にてその通常パケットを外部に送信する。
(応答送信予約時の送信処理)
S5にて「応答送信予約」と判断されたときには、処理がS12に移行する。
S12では、CPU21は、過去一定期間の受信パケット数が所定値以下であるか否かを判断する。過去一定期間の受信パケット数が所定値以下でなければ(S12:NO)、処理がS13に移行する。一方、所定値以下であれば(S12:YES)、処理がS14に移行する。
S13では、CPU21は、車載装置1の診断状態を「待機」に遷移させる。その後、処理がS10に移行し、CPU21は通常パケットを組み立てて送信する。
S14では、CPU21は、応答パケットを組み立てる。応答パケットは、通常パケット及び応答要求パケットとはパケットの種別が異なる。応答パケットのメッセージは、S4にて生成したIDである送信元端末ID、後述するS33にてメモリに記憶した送信先
端末ID(応答要求の送信元の端末ID)、S1にて特定した位置の位置情報、S2にて取得した状態情報などにより構成される。このS14の後、処理がS15に移行する。
S15では、CPU21は、車載装置1の診断状態を「待機」に遷移させる。その後、処理がS11に移行する。
(3−2)受信処理
制御装置15のCPU21が実行する受信処理について、図4に示すフローチャートに基づいて説明する。この受信処理は、所定のイベントが発生したときに実行される。イベントとしては、前回の受信処理開始からカウントするタイマーが満了したこと(一例として1sのタイマー満了)や、無線パケットを受信したことなどが挙げられる。
(受信処理開始時の処理)
受信処理開始時には、まず以下のS21〜S23を実行する。
S21では、CPU21は、無線通信によりパケットを受信したか否かを判断する。パケットを受信していれば(S21:YES)、処理がS22に移行する。一方、パケットを受信していなければ(S21:NO)、処理がS25に移行する。
S22では、CPU21は、過去一定期間の受信パケット数を更新する。その後、処理がS23に移行する。
S23では、CPU21は、S21にて受信したと判断された対象となるパケットの種別を判断する。パケットの種別は、「通常パケット」(図中では通常と表記),「応答要求パケット」(図中では応答要求と表記),「応答パケット」(図中では応答と表記)のいずれかとなる。それぞれの場合について以下に説明する。
なお「通常パケット」を受信した場合の処理は、「応答要求パケット」,「応答パケット」を受信した場合にも実行される。「応答要求パケット」,「応答パケット」を受信した場合は、まず、所定の処理が実行され、その後に「通常パケット」を受信したときの処理と同様の処理が実行される。
(通常パケット受信時の処理)
S23にて「通常パケット」と判断されたときには、処理がS24に移行する。
S24では、CPU21は共通受信処理を開始する。この処理は、受信したパケットに含まれる車両の位置情報や状態情報に基づいて、車両の走行についての制御や乗員への情報通知などが実行される。例えば、他の車両との衝突回避のための制御や、車両の周辺の交通状況の通知などが行われる。共通受信処理を開始した後、処理がS25に移行する。
S25では、CPU21は、車載装置1の診断状態を判断する。ここでは、「応答待ち」であるか否かを判断する。診断状態が「応答待ち」であれば、処理がS26に移行する。その他の状態であれば、処理がS30に移行する。なお「応答待ち」とは、上述したS8にて組み立てた応答要求パケットをS11にて送信した後であって、未だ応答パケットを受信していない状態である。
S26では、CPU21は、GPS衛星から送信された信号から時刻を取得する。その後、処理がS27に移行する。
S27では、CPU21は、現状態で(即ち、応答要求パケットをS11にて送信して応答待ち状態となってから現時刻まで)所定時間が経過したか否かを判断する。所定時間とは、例えば1sとすることができる。所定時間が経過していれば(S27:YES)、処理がS28に移行する。一方、所定時間が経過していなければ(S27:NO)、処理がS30に移行する。
S28では、CPU21は、失敗カウンタに「1」を加算する。その後、処理がS29に移行する。
S29では、CPU21は、車載装置1の診断状態を「待機」に遷移させる。その後、S30に移行する。
S30では、CPU21は、失敗カウンタが所定値以上であるか否かを判断する。失敗カウンタが所定値以上であれば(S30:YES)、処理がS31に移行する。一方、失敗カウンタが所定値以上でなければ(S30:NO)、受信処理を終了する。
S31では、CPU21は、通信機能(無線通信機11)について故障と判定して、車内に設けられたディスプレイやスピーカを用いて乗員に故障であることを通知する。その後、受信処理を終了する。
(応答要求パケット受信時の処理)
S23にて「応答要求パケット」と判断されたときには、処理がS32に移行する。
S32では、CPU21は、車載装置1の診断状態を判断する。ここでは、「待機」であるか否かを判断する。診断状態が「待機」であれば、処理がS33に移行する。診断状態がその他の状態であれば、処理がS24に移行する。つまり、診断状態が「待機」でなければ、応答要求パケットを受信しても応答しない、ということになる。このS32の後、処理がS33に移行する。
S33では、CPU21は、受信した応答要求パケットから端末IDを読出し、メモリに保存する。ここで保存される端末IDは、故障診断をするために応答要求パケットを送信した送信元の端末IDである。この端末IDは、S14にて、応答パケットに含まれる送信先端末IDとして利用されるほか、後述するS40にて重複した応答の送信を抑制するために利用される。このS33の後、処理がS34に移行する。
S34では、CPU21は、車載装置1の診断状態を「応答送信予約」に遷移させる。その後、処理がS24に移行する。
(応答パケット受信時の処理)
S23にて「応答パケット」と判断されたときには、処理がS35に移行する。
S35では、CPU21は、受信した応答パケットから、送信先端末IDを読出す。この送信先端末IDは、応答パケットを送信すべき宛先の端末のIDとして、送信元の端末がパケットに含めた情報である。このS35の後、処理がS36に移行する。
S36では、CPU21は、車載装置1の診断状態を判定する。診断状態が「待機」であれば、処理がS24に移行する。診断状態が「応答待ち」であれば、処理がS37に移行する。診断状態が「応答送信予約」であれば、処理がS40に移行する。
S37では、CPU21は、S35にて読み出した送信先端末IDが、自端末の端末IDと一致するか否かを判断する。自端末の端末IDとは、過去にS4にて生成したものである。読み出した端末IDが自端末の端末IDと一致すれば(S37:YES)、処理がS38に移行する。一方、一致しなければ(S37:NO)、処理がS24に移行する。
S38では、CPU21は、失敗カウンタから「1」を減算する。減算後のカウンタ値が0以下となる場合は、値を0とする。その後、処理がS39に移行する。
S39では、CPU21は、車載装置1の診断状態を「待機」に遷移させる。その後、処理がS24に移行する。
S40では、CPU21は、S35にて読み出した送信先端末IDが、S33にてメモリに保存した端末IDと一致するか否かを判断する。読み出した端末IDがメモリに保存した端末IDと一致すれば(S40:YES)、処理がS41に移行する。一方、一致しなければ(S40:NO)、処理がS24に移行する。
S41では、CPU21は、車載装置1の診断状態を「待機」に遷移させる。S40にてYESと判断されるということは、送信先端末IDにより特定される端末及び自端末で以外の他の端末が、既に応答パケットを送信しているということである。よって、S41の状態遷移により、自端末による応答パケットの送信が行われなくなり、重複した応答パケットの送信を抑制できる。このS41の後、処理がS24に移行する。
(4)効果
上述したように、本実施形態の通信システムは、車車間通信又が可能な無線通信機11(通信手段)を備え、車両101に搭載されて用いられる車載装置1(第1の通信装置及び第2の通信装置)を含む通信システムである。
車載装置1の制御装置15のCPU21は、車載装置1を特定可能な情報(送信元端末ID)を含む応答要求パケット(第1の信号、応答要求信号)を、車両101の外部の車載装置(他の通信装置)に送信する(S8、S11)。
また、応答要求パケットを受信した車載装置1(第2の通信装置)のCPU21は、応答要求パケットを受信したときに、応答パケット(第2の信号、応答信号)を送信元の車載装置1(第1の通信装置)に送信する(S14、S11)。
また、CPU21は、応答パケットの受信状況に応じて、車載装置1に備えられる無線通信機11が故障しているか否かを判定する(S30、S31)。より具体的にはS25〜S28にて無線通信機11にて応答パケットを受信できないことと、S35〜S38にて応答パケットを受信できたことと、に基づいて故障の判定を行う。
そして本実施形態では、CPU21は、無線通信機11の混雑度を判定し(S7、S12)、混雑度が所定の閾値以下のときに、応答要求パケット及び応答パケットの送信が実行される。混雑度は、過去の一定期間の受信パケット数によって定まるパラメータである。
このように構成された本実施形態の通信システムでは、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信、例えば車両101の衝突防止のために必要な情報である車両の状態情報などを取得するためのデータの送受信を妨げてしまうことを抑制できる。
例えば、応答パケットには送信先端末(故障診断を行う車載装置1)の端末ID情報が付加されているため、その分、通信量が増加してしまうが、本実施形態では通信が混雑しているときにはその通信量の増加を抑制することができる。
換言すると、通信混雑時には端末ID情報を送らない(通常パケットを送信する)ため、通信量が増加しない。なお厳密にはパケット種別情報を送る必要があるが、通常はその枠が予め用意されているため、それによる通信量の増加はない。
また、応答パケットは所定時間ごとに送信される応答要求パケットを受信したときにのみ送信されるため、故障診断が必要でないタイミングにおける故障診断のための通信量の増加を抑制できる。
また本実施形態では、所定時間内に受信した無線パケットの数が多いほど混雑度を高く判定している。そのため、車載装置1の密度に応じた適切な混雑度の判断を行うことができる。
なお、本実施形態では応答要求パケット及び応答パケットのいずれを送信する際にも混雑度を判定して送信の可否を判断する構成を例示したが、いずれか一方についてのみ混雑度を判定して送信の可否を判断する構成であってもよい。
また、本実施形態では、応答パケットを受信できたこと、及び受信できなかったこと、の両方を勘案して故障を判断する構成を例示したが、いずれか一方のみに基づいて判断してもよい。例えば、応答要求パケットの送信回数に対して応答パケットを受信した割合や、受信しなかった割合をカウントして、その値に基づいて故障を判断することが考えられる。
[第2実施形態]
第2実施形態の車載装置1は、第1実施形態の車載装置1と同様のハードウェア構成であるが、制御装置15(CPU21)により実行される処理の内容が相違する。本実施形態では、応答パケットを受信したときに、送信元の端末が自端末に近ければ、通信機能が良好であるという判断にその情報を用いない。
(1)制御装置15のCPU21による処理
本実施形態では、送信処理は第1実施形態と同様である。以下、受信処理について図5に示すフローチャートに基づいて説明する。なお、図4のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。
まず、S35にてCPU21が受信した応答パケットから送信先端末IDを読出した後、本実施形態では処理がS51に移行する。
S51では、CPU21は、受信した応答パケットから、端末位置を示す位置情報を読出す。この位置情報は、応答パケットを組み立てた送信元の端末(車載装置1)の位置を示す情報である。このS51の後、処理がS36に移行する。
また、S37にて、CPU21がS35にて読み出した送信先端末IDが自端末の端末IDと一致すると判断したときに、処理がS52に移行する。
S52では、CPU21は自端末位置を特定する。この処理は図3のS1と同様の処理である。その後、処理がS53に移行する。
S53では、CPU21は、自端末と、S51で読み出した送信元端末と、の間の距離が所定値以上であるか否かを判定する。所定値とは、例えば100mとすることができる。端末間の距離が100m以上であれば(S53:YES)、処理がS38に移行する。一方、端末間の距離が100m以上でなければ(S53:NO)、S38の処理を実行せず、処理がS39に移行する。
(2)効果
本実施形態の通信システムは、第1実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。
また本実施形態においては、応答パケットの送信先端末である車載装置1の位置を特定する位置特定装置13の特定した位置(S52)と、応答パケットに含まれる送信元端末
である車載装置1の位置を示す情報(S51)と、から、送信先端末と送信元端末との間隔を判断する(S53)。
そして、送信先端末の制御装置15のCPU21は、応答パケットを受信できたこと、及び受信できなかったことに基づいて故障を判断するが、送信先端末の無線通信機11が当該送信先端末の位置から所定の距離以上離れた位置から送信された応答パケットを受信したときに、応答パケットを受信できたこととして無線通信機11の故障を判定する。
従って、応答パケットを受信できる範囲が近距離に限られる場合は無線通信機11が故障であると診断できるため、無線通信機11の故障診断をより高度に実行することができる。
[第3実施形態]
第3実施形態の車載装置1は、第1実施形態の車載装置1と同様のハードウェア構成であるが、制御装置15(CPU21)により実行される処理の内容が相違する。本実施形態では、応答要求パケットを受信したときに、送信元の端末が自端末に近ければ、応答パケットを送信しない。
(1)制御装置15のCPU21による処理
本実施形態では、送信処理は第1実施形態と同様である。以下、受信処理について図6に示すフローチャートに基づいて説明する。なお、図4のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。
まず、S33にてCPU21が受信した応答要求パケットから端末IDを読出し、メモリに保存した後、本実施形態では処理がS61に移行する。
S61では、CPU21は、受信した応答要求パケットから、端末位置を示す位置情報を読出す。この位置情報は、応答要求パケットを組み立てた送信元の端末(車載装置1)の位置を示す情報である。このS61の後、処理がS62に移行する。
S62では、CPU21は、自端末と、S61で読み出した送信元端末と、の間の距離が所定値以上であるか否かを判定する。所定値とは、例えば100mとすることができる。端末間の距離が100m以上であれば(S62:YES)、処理がS34に移行する。一方、端末間の距離が100m以上でなければ(S62:NO)、S34の処理を実行せず、処理がS24に移行する。
(2)効果
本実施形態の通信システムは、第1実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。
また本実施形態においては、応答要求パケットに含まれる送信元端末の位置を示す情報と、応答要求パケットを受信した端末の位置と、から、送信先端末と送信元端末との距離を判断し、所定の距離以上離れた位置から送信された応答要求パケットを受信したとき(S62:YES)、応答パケットを応答要求パケットの送信元の端末に送信する。
従って、応答パケットは所定の距離以上離れた位置から送信されているため、遠方からのパケットの受信を確認でき、無線通信機11の故障診断をより高度に実行することができる。
[第4実施形態]
第4実施形態の車載装置1は、第1実施形態の車載装置1と同様のハードウェア構成であるが、制御装置15(CPU21)により実行される処理の内容が相違する。本実施形態では、無線通信の混雑度を判断するにあたって、一定期間における受信パケット数ではなく、無線帯域使用率(通信チャネルの使用割合)から混雑度を判定する。
(1)混雑度の判定方法
図7を用いて、第1実施形態との相違を説明する。
第1実施形態では、図7の上段に示すように、パケット数を判断することで通信チャネル(周波数帯域)の混雑度を判断している。つまり、単位時間T0において受信したパケット数が多いほど混雑しており、単位時間T0において受信したパケット数がしきい値Th_nを超えたときには、混雑と判断され、故障診断は実行されない。
一方、第4実施形態では、図7の下段に示すように、通信チャネルの使用割合で混雑度を判定する。例えば、パケット長が可変の場合には、長時間通信チャネルを占有する可能性があり、このような場合において、端末iが電波を出す時間tiが長ければ混雑しているといえる。単位時間T0におけるチャネルの使用率は(Σti/T0)×100(%)で示され、この使用率がしきい値Th_tを超えたときには、混雑と判断される。
(2)制御装置15のCPU21による処理
本実施形態の具体的な処理を図8及び図9に示すフローチャートに基づいて説明する。なお、図4及び図5のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。
図8のフローチャートにおいては、S6にて、前回の診断から所定時間が経過していれば(S6:YES)、処理がS71に移行する。
S71では、CPU21は、チャネル使用率が所定値以下であるか否かを判断する。チャネル使用率が所定値以下であれば(S71:YES)、処理がS8に移行する。一方、チャネル使用率が所定値以下でなければ(S71:NO)、処理がS10に移行する。
またS5にて「応答送信予約」と判断されたときには、処理がS72に移行する。
S72では、CPU21は、チャネル使用率が所定値以下であるか否かを判断する。チャネル使用率が所定値以下でなければ(S72:NO)、処理がS13に移行する。一方、チャネル使用率が所定値以下であれば(S72:YES)、処理がS14に移行する。
図9のフローチャートにおいては、図5と比較して、S22の処理を実行しない点においてのみ相違する。よって説明を割愛する。
(3)効果
本実施形態の通信システムは、第1実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。
また本実施形態では、無線帯域使用率が高い場合ほど混雑度を高く判定しているため、車載装置1の密度に応じた適切な混雑度の判断を行うことができる。
なお、本実施形態においては、さらに受信信号強度が一定以上の端末が自端末の周辺に存在するか否かを判断し、そのような端末が存在することを条件に、故障診断を実施するように(S8、S14に処理が移行するように)構成されていてもよい。信号強度が低いと通信の確実性が低下するためである。
[第5実施形態]
第5実施形態の車載装置1は、第1実施形態の車載装置1と同様のハードウェア構成で
あるが、制御装置15(CPU21)により実行される処理の内容が相違する。本実施形態のCPU21が、本発明における経過判定手段の一例である。
本実施形態では、故障の判定を行う側の車載装置1から、故障判定のためのトリガとなる信号(応答要求パケット)を送信しない。
また不揮発性メモリ27により構成される記憶領域上には、失敗カウンタの他に、応答受信カウンタが設けられる。応答受信カウンタは、過去の一定期間内に応答パケットを受信した回数をカウントするカウンタである。
(1)診断の状態遷移
車載装置1は、図10に示すように、初期状態41からまず待機状態43に遷移する。車載装置1は、前回の応答から所定の時間が経過したときに、所定の端末に対して応答送信する(応答パケットを送信する)応答送信予約状態45に遷移する。自端末が応答送信を行うか、所定の端末以外の第3の他端末により応答送信が行われると、自端末は待機状態43に遷移する。
なお本実施形態において、応答送信は応答要求をトリガとするものではないため、厳密には応答ではないが、説明の便宜上、応答と記載する。また、前回の応答とは、最後に応答パケットの送信を行ったこと、或いは応答パケットの送信をするために応答送信予約状態になったことを意味する。
(2)制御装置15のCPU21による処理
(2−1)送信処理
制御装置15のCPU21が実行する送信処理について、図11に示すフローチャートに基づいて説明する。なお、図3のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。
本実施形態では、S4にて端末IDを生成した後、処理がS81に移行する。
S81では、CPU21は、車載装置1の診断状態を判定する。図10にて説明したように、診断状態は、「待機」,「応答送信予約」のいずれかとなる。ここで「待機」と判断されたときには、処理がS10に移行する。一方、「応答送信予約」と判断されたときは、処理がS12に移行する。
またS12にて過去一定期間の受信パケット数が所定値以下であれば(S12:YES)、処理がS82に移行する。
S82では、CPU21は、応答パケットを組み立てる。第1実施形態のS14にて組み立てる応答パケットのメッセージには応答要求の送信元の端末IDが含まれる構成であったが、本実施形態ではその送信元の端末IDに変えて、後述するS97にて通常パケットから読出しメモリに記憶された、その通常パケットの送信元の端末IDが含まれる。
(2−2)受信処理
制御装置15のCPU21が実行する受信処理について、図12に示すフローチャートに基づいて説明する。この受信処理は、所定のイベントが発生したときに実行される。イベントとしては、前回の受信処理開始からカウントするタイマーが満了したこと(一例として1sのタイマー満了)や、無線パケットを受信したことなどが挙げられる。
(受信処理開始時の処理)
受信処理開始時には、まず以下のS91〜S94を実行する。
S91では、CPU21は、無線通信によりパケットを受信したか否かを判断する。パケットを受信していれば(S91:YES)、処理がS92に移行する。一方、パケット
を受信していなければ(S91:NO)、処理がS107に移行する。
S92では、CPU21は、過去一定期間の受信パケット数を更新する。その後、処理がS93に移行する。
S93では、CPU21は、GPS衛星から送信された信号から時刻を取得する。その後、処理がS94に移行する。
S94では、CPU21は、S91にて受信したと判断された対象となるパケットの種別を判断する。パケットの種別は、「通常パケット」(図中では通常と表記),「応答パケット」(図中では応答と表記)のいずれかとなる。それぞれの場合について以下に説明する。なお、S107以降の処理は共通であるため、共通の処理については別途説明する。
(通常パケット受信時の処理)
S94にて「通常パケット」と判断されたときには、処理がS95に移行する。
S95では、CPU21は、車載装置1の診断状態を判定する。診断状態が「待機」であれば、処理がS96に移行する。診断状態が「応答送信予約」であれば、処理がS100に移行する。
S96では、CPU21は、現在時刻が次回応答時刻を過ぎたか否かを判断する。次回応答時刻は、後述するS99にて設定される。次回応答時刻を過ぎていれば(S96:YES)、処理がS97に移行する。一方、次回応答時刻を過ぎていなければ(S96:NO)、処理がS100に移行する。
S97では、CPU21は、受信した通常パケットから端末IDを読出し、メモリに保存する。ここで保存される端末IDは、通常パケットを送信した送信元の端末IDである。この送信元の端末が、故障診断を実行する端末である。またこの端末IDは、S82にて、応答パケットに含まれる送信先端末IDとして利用されるほか、後述するS105にて重複した応答の送信を抑制するために利用される。このS97の後、処理がS98に移行する。
S98では、CPU21は、車載装置1の診断状態を「応答送信予約」に遷移させる。その後、処理がS99に移行する。
S99では、CPU21は、現在の時刻に対して所定の最低間隔を加え、さらにランダム時間を加えた時刻を、次回応答時刻としてメモリに記録する。最低間隔とは例えば1hとすることができる。最低間隔を長く設定する場合には、次回応答時刻は不揮発性メモリ27に記録するとよい。このS99の後、処理がS100に移行する。
S100では、CPU21は共通受信処理を開始する。この処理は、受信したパケットに含まれる車両の位置情報や状態情報に基づいて、車両に走行についての処理や乗員への情報通知などが実行される。例えば、他の車両との衝突回避のための制御や、車両の周辺の交通状況の通知などが行われる。共通受信処理を開始した後、処理がS107に移行する。
(応答パケット受信時の処理)
S94にて「応答パケット」と判断されたときには、処理がS101に移行する。
S101では、CPU21は、受信した応答パケットから、送信先端末IDを読出す。この送信先端末IDは、応答パケットを送信すべき宛先の端末のIDとして、送信元の端末(車載装置1)がパケットに含めた情報である。このS101の後、処理がS102に移行する。
S102では、CPU21は、S101にて読み出した送信先端末IDが、自端末の端末IDと一致するか否かを判断する。自端末の端末IDとは、過去にS4にて生成したものである。読み出した端末IDが自端末の端末IDと一致すれば(S102:YES)、処理がS103に移行する。一方、一致しなければ(S102:NO)、処理がS104に移行する。
S103では、CPU21は、過去の一定期間内に受信した応答パケットであって送信先端末IDが自端末の端末IDと一致する応答パケットの数に、応答受信カウンタを更新する。その後、処理がS100に移行する。
S104では、CPU21は、車載装置1の診断状態を判定する。診断状態が「待機」であれば、処理がS100に移行する。診断状態が「応答送信予約」であれば、処理がS105に移行する。
S105では、CPU21は、S101にて読み出した送信先端末IDが、S97にてメモリに保存した端末IDと一致するか否かを判断する。読み出した端末IDがメモリに保存した端末IDと一致すれば(S105:YES)、処理がS106に移行する。一方、一致しなければ(S105:NO)、処理がS100に移行する。
S106では、CPU21は、車載装置1の診断状態を「待機」に遷移させる。S105にてYESと判断されるということは、送信先端末IDを有する車載装置1及び自端末である車載装置1以外の他の車載装置1が、既に応答パケットを送信しているということである。よって、S106の状態遷移により、自端末による応答パケットの送信が行われなくなり、重複した応答パケットの送信を抑制できる。このS106の後、処理がS100に移行する。
(共通の処理)
S107では、CPU21は、現在時刻が次回判定時刻を過ぎたか否かを判断する。次回判定時刻は、後述するS112にて設定される。次回判定時刻を過ぎていれば(S107:YES)、処理がS108に移行する。一方、次回判定時刻を過ぎていなければ(S107:NO)、受信処理を終了する。
S108では、CPU21は、過去の一定期間の受信パケット数が上限値と下限値(0以上)で指定された所定値範囲であるか否かを判断する。この処理の目的は、車載装置1のように車車間通信を行う装置が搭載された車両が周囲に少ないこと、即ち通信の混雑度が過大でないことを検知することである。過去の一定期間の受信パケット数は、S92にてカウントされている。なお過去の一定期間のパケット数が下限値より小さければ、周囲に車車間通信が可能な装置が存在しないため故障診断に適する状況でないこととなる。
このS108にて、過去の一定期間の受信パケット数が所定値範囲であれば(S108:YES)、処理がS109に移行する。一方、所定値範囲でなければ(S108:NO)、受信処理を終了する。
S109では、CPU21は、応答受信カウンタが所定値以上であるか否かを判断する。応答受信カウンタが所定値以上であれば(S109:YES)、処理がS110に移行する。一方、応答受信カウンタが所定値以上でなければ(S109:NO)、処理がS111に移行する。
S110では、CPU21は、失敗カウンタから「1」を減算する。減算後のカウンタ
値が0以下となる場合は、値を0とする。その後、処理がS112に移行する。
S111では、CPU21は、失敗カウンタに「1」を加算する。その後、処理がS112に移行する。
S112では、CPU21は、現在の時刻に対して所定の判定間隔を加えた時刻を、次回判定時刻としてメモリに記録する。判定間隔とは例えば1hとすることができる。判定間隔を長く設定する場合には、次回判定時刻は不揮発性メモリ27に記録するとよい。このS112の後、処理がS113に移行する。
S113では、CPU21は、失敗カウンタが所定値以上であるか否かを判断する。失敗カウンタが所定値以上であれば(S113:YES)、処理がS114に移行する。一方、失敗カウンタが所定値以上でなければ(S113:NO)、受信処理を終了する。
S114では、CPU21は、通信機能(無線通信機11)について故障と判定して、車内に設けられたディスプレイやスピーカを用いて乗員に故障であることを通知する。その後、受信処理を終了する。
(3)効果
本実施形態の通信システムは、第1実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。
また本実施形態では、制御装置15のCPU21は応答要求パケットの送信を実行せず、応答パケットを送信してから次回応答時刻を経過したか否か(所定の時間が経過したか否か)を判定し、次回応答時刻の経過後であって(S96:YES)、通常パケットを受信したとき(S94:YES)に、応答パケットを通常パケットの送信元端末に送信する。
従って、応答要求パケットを送信しなくとも、応答パケットの送信元の端末である車載装置1にて適宜時間間隔を空けて応答パケットを送信することができる。
[第6実施形態]
第6実施形態の車載装置1は、第1実施形態の車載装置1と同様のハードウェア構成であるが、制御装置15(CPU21)により実行される処理の内容が相違する。本実施形態では、他の端末(車載装置1)が自端末を中心とした所定の範囲内に存在するときに、応答要求パケットを送信する。本実施形態のCPU21が、本発明における存在判定手段の一例である。
(1)制御装置15のCPU21による処理
本実施形態の送信処理について、図13に示すフローチャートに基づいて説明する。なお、図4のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。
本処理では、S7にて過去一定期間の受信パケット数が所定値以下と判断されたときに、処理がS121に移行する。
S121では、CPU21は、他の端末が、自端末を中心とした所定の範囲内に存在するか否かを判定する。ここでは、過去の一定期間の間に実行された後述するS122にて読み出したパケットの送信元端末の位置と、S1にて特定した自端末の位置と、から所定の範囲内に端末が存在するか否かを判定する。
このS121にて、所定の範囲内に他の端末が存在するとき(S121:YES)、処
理がS8に移行し、応答要求パケットを組み立てる。一方、所定の範囲内に他の端末が存在しないとき(S121:NO)、処理がS10に移行する。
次に、本実施形態の受信処理について、図14に示すフローチャートに基づいて説明する。なお、図5のフローチャートと同様の処理を実行する点については同一の符号を用いて説明を割愛し、相違する部分のみ説明する。
本処理では、S24の後、S122に移行する。
S122では、CPU21は、受信したパケットから送信元の端末の位置情報を読出し、メモリに一定期間記憶する。その後、処理がS25に移行する。
(2)効果
本実施形態の通信システムは、第1実施形態の通信システムと同様に、通信の混雑度が所定の閾値以下である場合に故障の判定を行うため、他の情報の送受信を妨げてしまうことを抑制できる。
また本実施形態においては、自端末を中心とした所定の範囲内に他の端末が存在するときに応答要求パケットを組み立てて送信する。
従って、応答要求パケットを受信可能である車載装置1が周辺に存在しない場合にもかかわらず応答要求パケットを送信してしまうことを抑制でき、応答パケットが受信されないことで故障と判断してしまったり、距離が遠いことにより通信の確実性が低下してしまったりすることを抑制でき、故障診断の信頼性を向上させることができる。
なお、本実施形態では受信したパケットから送信元端末の位置を読み出すことで他端末の存在を判断する構成を例示したが、それ以外の手法で他端末を検出し、所定範囲に存在するか否かを判断するように構成されていてもよい。
例えば、単に他端末からのパケットを受信したことにより所定範囲内(この場合には通信可能範囲)の他端末の存在を検出してもよいし、別の第3の端末から、他端末の存在情報を入手することで他端末の存在を検出してもよい。
[その他の実施形態]
以上本発明の実施形態について説明したが、本発明は、上記各実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態をとり得ることはいうまでもない。
例えば、上記各実施形態においては、プログラムを除き同様のハードウェア構成を有する複数の車載装置1によってなる通信システムの構成を例示したが、必要な機能を満たしていれば、一部が異なる装置であってもよい。例えば、図15に示すように、路側機103に車載装置1と同様のハードウェアを有する通信装置105が搭載されており、通信装置105が車載装置1と同様の動作を実行することで故障診断を実現する構成であってもよい。この場合、路車間通信を行う装置により本発明が実現される。また、路側機に備えられる通信装置同士や、車両以外の移動体(一例として歩行者)が有する通信装置により本発明が実現されてもよい。
また、一方の車載装置が応答要求パケットを送信する機能、応答パケットを受信して故障を診断する機能、を有しており、他方の車載装置が応答要求パケットを受信して応答パケットを送信する機能、を有する構成であってもよい。その場合は、上述した一方の車載装置の無線通信機の故障診断を実現することができる。
また上記各実施形態では、通信の混雑度を判定するためにパケット受信数や無線帯域使用率を用いる構成を例示したが、ネットワークトラフィックの状態を測定又は推定できる、上記以外の方法を用いて混雑度を判定する構成としてもよい。例えば、トラフィックの混雑状況を測定する他の測定装置からトラフィックの混雑状況の情報を取得し、その情報に基づいて混雑度を判定するように構成されていてもよいし、混雑度として直接利用できる情報を取得する構成であってもよい。
また上記各実施形態では、車車間通信を実行可能な車載装置1同士で直接的に通信を行う構成を例示したが、間接的に通信を行うものであってもよい。例えば、車載装置1が道路沿いに配置される路側機と路車間通信を行っており、路側機を介して車両間の通信が実現される構成であってもよい。また通信の方式や送信されるデータの構成も特に限定されず、様々なものを採用することができる。
また、上述した車載装置が備える各手段としての機能は、プログラムにより、無線通信装置を有するコンピュータ、又は無線通信装置と接続可能なコンピュータに実現させることができる。
上記プログラムは、コンピュータによる処理に適した命令の順番付けられた列からなるものであって、コンピュータに組み込まれるROMやRAMなどに記憶され、これらからコンピュータにロードされて用いられてもよいし、各種記録媒体や通信回線を介してコンピュータにロードされ用いられるものであってもよい。
記録媒体としては、CD−ROMやDVD−ROM等の光ディスク、磁気ディスク、半導体製メモリ等が挙げられる。
また制御装置は、ASIC(Application Specific Integrated Circuits)、FPGA(Field Programmable Gate Array)などのプログラマブルロジックデバイスや、ディスクリート回路であってもよい。
1…車載装置、11…無線通信機、13…位置特定装置、15…制御装置、21…CPU、101…車両、103…路側機、105…通信装置

Claims (10)

  1. 無線通信が可能な通信手段(11)を備える第1の通信装置(1)と、前記通信手段を備える第2の通信装置(1)と、を含む通信システムであって、
    前記第1の通信装置に備えられ、少なくとも該第1の通信装置を特定可能な情報を含む第1の信号を、他の通信装置に送信する第1送信手段(21、S8、S10、S11)と、
    前記第1の信号を受信した前記他の通信装置である前記第2の通信装置に備えられ、前記第1の信号を受信したときに、第2の信号を前記第1の通信装置に送信する第2送信手段(21、S14、S82、S11)と、
    前記第1の通信装置に備えられ、前記第2の信号の受信状況に応じて、前記第1の通信装置に備えられる前記通信手段が故障しているか否かを判定する故障判定手段(21、S30、S31、S113、S114)と、
    前記第1の通信装置に備えられた前記通信手段と、前記第2の通信装置に備えられた前記通信手段と、のうちの少なくともいずれか一方における通信の混雑度を判定する混雑度判定手段(21、S7、S12、S71、S72)と、を有し、
    前記第1送信手段による前記第1の信号の送信と、前記第2送信手段による前記第2の信号の送信と、のうちの少なくともいずれか一方は、前記混雑度判定手段により判定された混雑度が所定の閾値以下のときに実行される
    ことを特徴とする通信システム。
  2. 前記第1の信号は、前記第1の通信装置に対する応答信号の送信を要求する応答要求信号であり、
    前記第2の信号は、前記応答要求信号に対する応答信号である
    ことを特徴とする請求項2に記載の通信システム。
  3. 前記第2の通信装置に備えられ、前記第2送信手段が前記第2の信号を送信してから、所定の時間が経過したか否かを判定する経過判定手段(21、S96)を有し、
    前記第2送信手段は、前記経過判定手段により所定の時間が経過したと判定され(S96:YES)、かつ、前記第1の信号を受信したとき(S94:YES)に、前記第2の信号を前記第1の通信装置に送信する
    ことを特徴とする請求項2に記載の通信システム。
  4. 前記混雑度判定手段は、所定時間内に受信した無線パケットの数が多いほど、又は、無線帯域使用率が高いほど、前記混雑度を高く判定する
    ことを特徴とする請求項1から請求項3のいずれか1項に記載の通信システム。
  5. 前記第1の通信装置に備えられ、該第1の通信装置を中心とした所定の範囲内に、他の通信装置が存在するか否かを判定する存在判定手段(21、S121、S122)を備え、
    前記第1送信手段は、前記存在判定手段により前記所定の範囲内に前記他の通信装置が存在すると判定されているとき(S121:YES)に、前記応答要求信号を送信する
    ことを特徴とする請求項2、請求項2を引用する請求項3、請求項2を引用する請求項4のいずれか1項に記載の通信システム。
  6. 前記故障判定手段は、前記第1の通信装置に備えられる前記通信手段が前記第2の信号を受信できたこと(S37:YES)及び/又は受信できないこと(S27:YES)に基づいて前記通信手段の故障を判定する
    ことを特徴とする請求項1から請求項5のいずれか1項に記載の通信システム。
  7. 前記第1の通信装置及び前記第2の通信装置は、自らの位置を特定する位置特定手段(13)を備え、
    前記第2の信号には、前記第2の通信装置の位置を示す情報が含まれており、
    前記故障判定手段は、前記第1の通信装置に備えられる前記通信手段が前記第1の通信装置の位置から所定の距離以上離れた位置から送信された前記第2の信号を受信したとき(S53:YES)に、前記第2の信号を受信できたとして前記通信手段の故障を判定する
    ことを特徴とする請求項6に記載の通信システム。
  8. 前記第1の通信装置及び前記第2の通信装置は、自らの位置を特定する位置特定手段(13)を備え、
    前記第1の信号には、前記第1の通信装置の位置を示す情報が含まれており、
    前記第2送信手段は、前記第2の通信装置に備えられる前記通信手段が前記第2の通信装置の位置から所定の距離以上離れた位置から送信された前記第1の信号を受信したとき(S62:YES)に、前記第2の信号を前記第1の通信装置に送信する
    ことを特徴とする請求項6に記載の通信システム。
  9. 請求項1から請求項8のいずれか1項に記載の通信システムを構成する前記第1の通信装置の機能を有する通信装置。
  10. 請求項1から請求項8のいずれか1項に記載の通信システムを構成する前記第2の通信装置の機能を有する通信装置。
JP2014069763A 2014-03-28 2014-03-28 通信システム Expired - Fee Related JP6075319B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014069763A JP6075319B2 (ja) 2014-03-28 2014-03-28 通信システム
US14/658,570 US9985854B2 (en) 2014-03-28 2015-03-16 Communication system and communication apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014069763A JP6075319B2 (ja) 2014-03-28 2014-03-28 通信システム

Publications (2)

Publication Number Publication Date
JP2015192396A true JP2015192396A (ja) 2015-11-02
JP6075319B2 JP6075319B2 (ja) 2017-02-08

Family

ID=54191912

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014069763A Expired - Fee Related JP6075319B2 (ja) 2014-03-28 2014-03-28 通信システム

Country Status (2)

Country Link
US (1) US9985854B2 (ja)
JP (1) JP6075319B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3226589A1 (en) 2016-03-30 2017-10-04 Panasonic Intellectual Property Management Co., Ltd. Terminal device and method for use in terminal device
JP2020190808A (ja) * 2019-05-20 2020-11-26 ルネサスエレクトロニクス株式会社 無線通信装置および無線通信システム

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6075319B2 (ja) * 2014-03-28 2017-02-08 株式会社デンソー 通信システム
KR102173999B1 (ko) * 2014-07-17 2020-11-04 주식회사 만도 차량 통신 제어장치 및 방법
US10187818B2 (en) * 2015-10-16 2019-01-22 Toshiba Memory Corporation Communication apparatus and communication method
CN106375943A (zh) * 2016-09-30 2017-02-01 安徽江淮汽车股份有限公司 一种车载故障诊断的系统及方法
CN106934877A (zh) * 2017-05-11 2017-07-07 华晨汽车集团控股有限公司 汽车信息记录装置
WO2018218404A1 (zh) * 2017-05-27 2018-12-06 深圳市乃斯网络科技有限公司 智能交通拥堵播放方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08331227A (ja) * 1995-06-05 1996-12-13 Nec Corp 無線ポート試験方法
JP2002290310A (ja) * 2001-03-23 2002-10-04 Clarion Co Ltd 無線通信システム
JP2007329667A (ja) * 2006-06-07 2007-12-20 Denso Corp 通信装置、及びプログラム
JP2010134865A (ja) * 2008-12-08 2010-06-17 Toyota Motor Corp 運転支援装置
WO2012124685A1 (ja) * 2011-03-14 2012-09-20 日本電気株式会社 無線通信機、無線通信システム、輻輳制御方法および記録媒体

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4550402A (en) * 1983-12-22 1985-10-29 Ford Motor Company Data communication system
US6426944B1 (en) * 1998-12-30 2002-07-30 At&T Corp Method and apparatus for controlling data messages across a fast packet network
US7961621B2 (en) * 2005-10-11 2011-06-14 Cisco Technology, Inc. Methods and devices for backward congestion notification
JP4619965B2 (ja) 2006-02-27 2011-01-26 京セラ株式会社 基地局装置及び基地局試験方法
JP4949185B2 (ja) 2007-10-05 2012-06-06 株式会社日本自動車部品総合研究所 運転支援情報提示装置、プログラム、及び運転支援情報提示方法
JP4571235B2 (ja) * 2008-11-28 2010-10-27 パナソニック株式会社 経路制御装置、経路異常予測装置、方法、およびプログラム
US8325602B2 (en) * 2008-12-18 2012-12-04 Cisco Technology, Inc. Method and system to manage network traffic congestion in networks with link layer flow control
JP5524002B2 (ja) * 2010-09-21 2014-06-18 株式会社東芝 ブロードキャスト無線伝送における無線通信システム及び移動無線通信装置
CN103069855A (zh) 2010-12-28 2013-04-24 三洋电机株式会社 终端装置
US20120323690A1 (en) * 2011-06-15 2012-12-20 Joseph Michael Systems and methods for monitoring, managing, and facilitating location- and/or other criteria-dependent targeted communications and/or transactions
US20140309876A1 (en) * 2013-04-15 2014-10-16 Flextronics Ap, Llc Universal vehicle voice command system
JP6244816B2 (ja) * 2013-03-26 2017-12-13 日本電気株式会社 データ収集管理システム、データ収集管理方法、端末及び管理装置
JP6075319B2 (ja) * 2014-03-28 2017-02-08 株式会社デンソー 通信システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08331227A (ja) * 1995-06-05 1996-12-13 Nec Corp 無線ポート試験方法
JP2002290310A (ja) * 2001-03-23 2002-10-04 Clarion Co Ltd 無線通信システム
JP2007329667A (ja) * 2006-06-07 2007-12-20 Denso Corp 通信装置、及びプログラム
JP2010134865A (ja) * 2008-12-08 2010-06-17 Toyota Motor Corp 運転支援装置
WO2012124685A1 (ja) * 2011-03-14 2012-09-20 日本電気株式会社 無線通信機、無線通信システム、輻輳制御方法および記録媒体

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3226589A1 (en) 2016-03-30 2017-10-04 Panasonic Intellectual Property Management Co., Ltd. Terminal device and method for use in terminal device
US9949157B2 (en) 2016-03-30 2018-04-17 Panasonic Intellectual Property Management Co., Ltd. Terminal device and method for use in terminal device
JP2020190808A (ja) * 2019-05-20 2020-11-26 ルネサスエレクトロニクス株式会社 無線通信装置および無線通信システム
JP7165622B2 (ja) 2019-05-20 2022-11-04 ルネサスエレクトロニクス株式会社 無線通信装置および無線通信システム

Also Published As

Publication number Publication date
US9985854B2 (en) 2018-05-29
JP6075319B2 (ja) 2017-02-08
US20150281023A1 (en) 2015-10-01

Similar Documents

Publication Publication Date Title
JP6075319B2 (ja) 通信システム
AU2021221470B2 (en) A tracking and theft-recovery system for mobile assets
JP6595885B2 (ja) 不正対処方法及び電子制御ユニット
US20210168564A1 (en) Methods, devices, systems, and computer-readable storage mediums for location positioning
US9013333B2 (en) Methods and systems related to time triggered geofencing
WO2016116991A1 (ja) 車載機、車載機診断システム
US10885773B2 (en) Technique for collecting information related to traffic accidents
JP5387055B2 (ja) 移動体通信機、通信システム、送信電力制御方法およびプログラム
US20100198459A1 (en) In-vehicle communications apparatus
US9888358B2 (en) Vehicular communication terminal
JP6398759B2 (ja) 車両用通信機
CN110505254B (zh) 一种车辆编队行驶的通信方法、系统和终端
KR102281655B1 (ko) 차량용 무선 통신 관리 시스템 및 그 제어방법
CN108141758B (zh) 无连接的数据传输
CN116325873A (zh) 电波图更新装置、以及通信质量确定装置
JP5386974B2 (ja) 車載無線通信装置およびキャリアセンス方法
JPWO2019229941A1 (ja) 通信制御装置及び端末装置
JP5649813B2 (ja) 衝突防止装置、衝突防止方法、衝突防止プログラム、および衝突防止システム
JP2015052843A (ja) 事故情報収集システム、撮像情報送信装置、及び事故情報収集装置
US20210289326A1 (en) Methods and systems for transmitting basic safety messages
JP2010250667A (ja) 通信機及び携帯電話
JP2021030783A (ja) 故障通報装置、及び故障通報方法
JP5353858B2 (ja) 無線通信装置
JP7085374B2 (ja) サービス提供システムおよび車両用装置
JP7131979B2 (ja) 通信制御システム、情報提供サーバ及びユーザ装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151026

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160126

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160129

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160323

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20160426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160715

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20160726

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160920

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161118

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20161213

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20161226

R151 Written notification of patent or utility model registration

Ref document number: 6075319

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees