(57)【特許請求の範囲】
【請求項１】
第１車両で用いられ、車車間通信を実施する機能を備える第１車両側装置と、第２車両で用いられ、車車間通信を実施する機能を備える第２車両側装置と、前記第１車両の運行状態を管理するセンター（３）と、を備え、
前記第１車両側装置は、
前記第１車両の走行状態を示す第１車両情報を取得する第１車両情報取得部（１５０）と、
前記第１車両の現在の連続運転時間を特定する連続運転時間特定部（１４１）と、
前記連続運転時間特定部が特定している前記連続運転時間に応じて定まる情報であって、前記連続運転時間の長さを直接的又は間接的に示す運転時間関連情報、及び、前記第１車両情報取得部が取得している前記第１車両情報を、車車間通信によって逐次送信する送信処理部（１５３）と、を備え、
前記第２車両側装置は、
前記第１車両側装置から送信される前記運転時間関連情報及び前記第１車両情報を受信する受信処理部（２４４）と、
前記受信処理部が受信した前記運転時間関連情報を前記第２車両のドライバに報知する報知処理部（２５２）と、
前記第２車両の走行状態を示す第２車両情報を取得する第２車両情報取得部（２４０）と、
前記第２車両情報取得部が取得した前記第２車両情報と、前記受信処理部が取得した前記第１車両情報とに基づき、前記第２車両のドライバが前記第１車両の挙動に起因して通常と異なる運転操作を実施したか否かを判定する通報判定部（２５３）と、
前記通報判定部によって前記第２車両のドライバが前記第１車両の挙動に起因して通常と異なる運転操作を実施したと判定された場合に、前記第１車両についての情報を前記センターに通報する通報処理部（２５４）と、を備えることを特徴とする運転支援システム。
【請求項２】
請求項１において、
前記第２車両側装置は、
前記受信処理部が受信した前記運転時間関連情報を前記第２車両のドライバに報知するべきか否かを判定する報知判定部（２５１）を備え、
前記報知処理部は、前記報知判定部によって前記運転時間関連情報を報知するべきであると判定された場合に、前記運転時間関連情報を前記第２車両のドライバに報知することを特徴とする運転支援システム。
【請求項３】
請求項１又は２において、
前記通報処理部は、前記第２車両のドライバが前記第１車両の挙動に起因して実施した運転操作の内容を示す前記第２車両情報を、前記第１車両についての情報と対応付けて前記センターに送信することを特徴とする運転支援システム。
【請求項４】
請求項１から３の何れか１項において、
前記送信処理部は、前記運転時間関連情報として、前記第１車両のドライバが連続的に運転操作を実施してもよい時間の上限値である上限時間から現在の前記連続運転時間を差し引いた時間である残余時間を送信するものであって、
前記通報処理部は、前記第１車両の前記残余時間が、所定の残余通報閾値以下となっている場合に、前記センターに対して、前記第１車両側装置から受信している前記運転時間関連情報を前記センターに通報することを特徴とする運転支援システム。
【請求項５】
請求項１から４の何れか１項において、
前記送信処理部は、前記運転時間関連情報として、前記第１車両の前記連続運転時間を送信するものであって、
前記通報処理部は、前記第１車両の前記連続運転時間が、所定の連続運転用通報閾値以上となっている場合に、前記センターに対して、前記第１車両側装置から受信している前記運転時間関連情報を前記センターに通報することを特徴とする運転支援システム。
【請求項６】
車両で用いられ、
前記車両の走行状態を示す第２車両情報を取得する第２車両情報取得部（２４０）と、
他車両から車車間通信によって送信される、当該他車両の現在の連続運転時間の長さを直接的又は間接的に示す運転時間関連情報、及び、当該他車両の走行状態を示す第１車両情報を受信する受信処理部（２４４）と、
前記受信処理部が受信した前記運転時間関連情報を前記車両のドライバに報知する報知処理部（２５２）と、
前記第２車両情報取得部が取得した前記第２車両情報と、前記受信処理部が取得した前記第１車両情報とに基づき、前記車両のドライバが前記他車両の挙動に起因して通常と異なる運転操作を実施したか否かを判定する通報判定部（２５３）と、
前記通報判定部によって前記車両のドライバが前記他車両の挙動に起因して通常と異なる運転操作を実施したと判定された場合に、前記他車両についての情報をセンターに通報する通報処理部（２５４）と、を備えることを特徴とする運転支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両のドライバに対して、より安全な運転操作を実施するために有用な情報を提供する運転支援システム、情報送信装置、及び、運転支援装置に関する。
【背景技術】
【０００２】
近年、複数の車両のそれぞれが互いに無線通信を実施する車車間通信システムが提案されている。また、そのような車車間通信システムで用いられる装置として、車車間通信によって他車両から送信される情報に基づいて、ドライバの運転操作を支援する装置（つまり運転支援装置）がある。
【０００３】
例えば特許文献１には、第１車両で用いられる第１車両側装置と、当該第１車両の後続車に相当する第２車両で用いられる第２車両側装置とを含む運転支援システムが開示されている。この特許文献１に開示の運転支援システムにおいて第１車両側装置は、赤外線通信によって、第１車両のドライバの運転操作を示す挙動情報を送信し、第２車両側装置は、第１車両側装置から送信される挙動情報に基づいた警告を第２車両のドライバに行う。
【０００４】
ここでの挙動情報とは、ステアリング操作，ブレーキ操作，アクセル操作，車速，加減速度，方向指示器出力などといった、瞬間的或いは相対的に短い時間で実施される運転操作の内容を示す情報である。
【０００５】
特許文献１に開示の構成によれば、後続車に相当する第２車両のドライバは、先行車に相当する第１車両が、これからどのような挙動を実際にするのかを認識することができる。
【０００６】
なお、第１車両の挙動情報が有用となる車両は、第１車両の後続車に限らない。第１車両の前方や側方、斜め後方に位置している車両、すなわち、第１車両の周辺に存在する車両（以降、周辺車両）にとっても、第１車両の挙動情報は有用である。便宜上、以降において第２車両は、第１車両にとっての周辺車両に該当する車両とする。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平７−４４８００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
一般的に、ドライバは、運転操作を相対的に長い時間連続して実施していると疲れてくる。ドライバは、疲労状態となると注意力が低下し、周辺車両の存在を見落とたり、周辺車両の挙動を確認しないまま車線変更や減速などの運転操作を実施したりしてしまう恐れが高まる。
【０００９】
したがって、第２車両のドライバにとっては、第１車両の挙動情報だけでなく、第１車両のドライバの疲労度がどの程度であるかを示す情報もまた、より安全な運転操作を実施するために有用な情報と言える。仮に第１車両のドライバが疲労状態であることを第２車両のドライバが認識できれば、第２車両のドライバは、第１車両との車間距離を一般的な適正値よりも長めに確保するなどといった対策を講ずることができるためである。
【００１０】
しかしながら、特許文献１の構成においては、第２車両のドライバは第１車両のドライバの疲労度を認識することができない。
【００１１】
本発明は、この事情に基づいて成されたものであり、その目的とするところは、第１車両のドライバの疲労度を、当該第１車両の周辺を走行している第２車両のドライバが認識可能な運転支援システム、情報送信装置、及び、運転支援装置を提供することにある。
【課題を解決するための手段】
【００１２】
その目的を達成するための運転支援システムの発明は、第１車両で用いられ、車車間通信を実施する機能を備える第１車両側装置と、第２車両で用いられ、車車間通信を実施する機能を備える第２車両側装置と、第１車両の運行状態を管理するセンター（３）と、を含む運転支援システムであって、第１車両側装置は、第１車両の走行状態を示す第１車両情報を取得する第１車両情報取得部（１５０）と、第１車両の現在の連続運転時間を特定する連続運転時間特定部（１４１）と、連続運転時間特定部が特定している連続運転時間に応じて定まる情報であって、連続運転時間の長さを直接的又は間接的に示す運転時間関連情報、及び、第１車両情報取得部が取得している第１車両情報を、車車間通信によって逐次送信する送信処理部（１５３）と、を備え、第２車両側装置は、第１車両側装置から送信される運転時間関連情報及び第１車両情報を受信する受信処理部（２４４）と、受信処理部が受信した運転時間関連情報を第２車両のドライバに報知する報知処理部（２５２）と、第２車両の走行状態を示す第２車両情報を取得する第２車両情報取得部（２４０）と、第２車両情報取得部が取得した第２車両情報と、受信処理部が取得した第１車両情報とに基づき、第２車両のドライバが第１車両の挙動に起因して通常と異なる運転操作を実施したか否かを判定する通報判定部（２５３）と、通報判定部によって第２車両のドライバが第１車両の挙動に起因して通常と異なる運転操作を実施したと判定された場合に、第１車両についての情報をセンターに通報する通報処理部（２５４）と、を備えることを特徴とする。
【００１３】
以上の構成では、第１車両側装置は、第１車両Ｍ１の連続走行時間を直接的又は間接的に示す運転時間関連情報を車車間通信によって送信し、第２車両側装置は、第１車両側装置が送信した運転時間関連情報を受信する。そして、第１車両の運転時間関連情報を第２車両のドライバに対して報知する。
【００１４】
このような態様によれば、第２車両が、第１車両が車車間通信可能な範囲内に存在する場合、第２車両のドライバは、第１車両の運転時間関連情報を認識することができる。運転時間関連情報は、連続運転時間の直接的又は間接的に示す情報であるため、第２車両のドライバは、運転時間関連情報を認識することで、第１車両の連続運転時間の長さを直接的に又は間接的に認識することが出来る。
【００１５】
一般的に、連続運転時間が長ければ長いほど、ドライバの疲労度は高まっている可能性が高くなる。すなわち、第２車両のドライバは、第１車両の連続運転時間の長さから、第１車両のドライバの疲労度を推定できる。つまり、以上の構成によれば、第１車両のドライバの疲労度を、第２車両のドライバが認識することができる。
【００１６】
また、上記目的を達成するための情報送信装置の発明は、車両で用いられ、他車両と車車間通信を実施する車車間通信部（１５）と、車両の現在の連続運転時間を特定する連続運転時間特定部（１４１）と、を備え、車車間通信部は、連続運転時間特定部が特定している連続運転時間に応じて定まる情報であって、連続運転時間の長さを直接的又は間接的に示す運転時間関連情報を逐次送信することを特徴とする。
【００１７】
この情報送信装置は、上述の運転支援システムの発明を構成する第１車両側装置に相当する装置である。つまり、この情報送信装置を車両で用いることによって、前述の運転支援システムを実現することができ、上述した運転支援システムの効果を奏することができる。
【００１８】
さらに、上記目的を達成するための運転支援装置の発明は、車両で用いられ、車両の走行状態を示す第２車両情報を取得する第２車両情報取得部（２４０）と、他車両から車車間通信によって送信される、当該他車両の現在の連続運転時間の長さを直接的又は間接的に示す運転時間関連情報、及び、当該他車両の走行状態を示す第１車両情報を受信する受信処理部（２４４）と、受信処理部が受信した運転時間関連情報を車両のドライバに報知する報知処理部（２５２）と、第２車両情報取得部が取得した第２車両情報と、受信処理部が取得した第１車両情報とに基づき、車両のドライバが他車両の挙動に起因して通常と異なる運転操作を実施したか否かを判定する通報判定部（２５３）と、通報判定部によって車両のドライバが他車両の挙動に起因して通常と異なる運転操作を実施したと判定された場合に、他車両についての情報をセンターに通報する通報処理部（２５４）と、を備えることを特徴とする。
【００１９】
この運転支援装置は、上述の運転支援システムの発明を構成する第２車両側装置に相当する装置である。つまり、この運転支援装置を車両で用いることによって、前述の運転支援システムを実現することができ、上述した運転支援システムの効果を奏することができる。
【００２０】
なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
【図面の簡単な説明】
【００２１】
【図１】運転支援システム１００の概略的な構成を説明するための図である。
【図２】第１車両側装置１の概略的な構成を示すブロック図である。
【図３】運行管理部１４の概略的な構成を示すブロック図である。
【図４】車車間通信制御部１５の概略的な構成を示すブロック図である。
【図５】データ生成部１５２が運転時間パケットを生成する処理について説明するためのフローチャートである。
【図６】運行管理部１４が実施する運転時間管理処理のフローチャートである。
【図７】第２車両側装置２の概略的な構成を示すブロック図である。
【図８】車車間通信制御部２４の概略的な構成を示すブロック図である。
【図９】送信処理部２４３が実施する送信関連処理のフローチャートである。
【図１０】受信処理部２４４が実施する受信関連処理のフローチャートである。
【図１１】報知制御部２５の概略的な構成を示すブロック図である。
【図１２】通報判定部２５３が実施する通報要否判定処理のフローチャートである。
【図１３】通報処理部２５４が実施する通報処理のフローチャートである。
【発明を実施するための形態】
【００２２】
以下、本発明の実施形態について図を用いて説明する。図１は、本実施形態に係る運転支援システム１００の概略的な構成の一例を示す図である。運転支援システム１００は、図１に示すように、第１車両Ｍ１に搭載されている第１車両側装置１と、第２車両Ｍ２に搭載されている第２車両側装置２と、各車両の外部に設けられ、広域通信網に接続しているセンター３と、を備える。
【００２３】
ここでの広域通信網とは、携帯電話網やインターネット等の、電気通信事業者によって提供される公衆通信ネットワークを指す。また、第１車両Ｍ１とは、以降で述べる第１車両側装置１が搭載されている車両であり、第２車両Ｍ２とは、以降で述べる第２車両側装置２が搭載されている車両である。第１車両側装置１が請求項に記載の情報送信装置に相当し、第２車両側装置２が請求項に記載の運転支援装置に相当する。
【００２４】
＜全体の概要＞
第１車両側装置１及び第２車両側装置２は、予め割り当てられた周波数帯の電波を用いて、広域通信網を介さない無線通信（いわゆる車車間通信）を実施するように構成されている。車車間通信に用いられる周波数帯は、適宜設計されれば良い。例えば車車間通信は、７６０ＭＨｚ帯の電波を用いて実現されればよい。もちろん、その他、車車間通信は２．４ＧＨｚ、５．９ＧＨｚ帯などの電波を用いて実現されてもよい。
【００２５】
また、第１車両側装置１及び第２車両側装置２のそれぞれは、センター３と広域通信網を介した通信を実施可能に構成されている。センター３は、第１車両Ｍ１の運行状態（例えば現在位置や走行経路など）を管理する運行管理事業者によって運用される設備である。
【００２６】
第１車両Ｍ１は、センター３によって運行状態を管理されている。便宜上、ここでは一例として第１車両Ｍ１は、長距離用のトラックや、観光バスなどといった、１回のトリップが比較的長距離となる傾向が強い（つまり長距離移動用の）業務用車両とする。第１車両Ｍ１は、流通や観光などといった事業を実施する所定の会社又は団体等に所属している。なお、ここでのトリップとは、出発地を出発してから目的地に到達するまでの一連の走行を指す。
【００２７】
第２車両Ｍ２は、第１車両Ｍ１と車車間通信が実施できる範囲に存在する車両である。車車間通信ができる範囲は適宜設計されればよく、数十ｍ〜数百ｍに設計される場合が多い。例えば第２車両Ｍ２としては、乗用車などを想定すれば良い。もちろん、第２車両Ｍ２も、長距離用トラックなどの業務用車両であってもよい。
【００２８】
第１車両Ｍ１、第２車両Ｍ２は、ガソリンエンジンやディーゼルエンジンを駆動源とする車（以降、エンジン車）であってもよいし、電気自動車であっても良い。また、モーターとエンジンの両方を駆動源として備えるハイブリッド車であってもよい。ここでは一例として各車両はエンジン車とする。
【００２９】
なお、図１では第１車両Ｍ１、及び第２車両Ｍ２が四輪自動車である態様を図示しているが、各車両は、二輪自動車や三輪自動車等であってもよい。第１車両Ｍ１、第２車両Ｍ２は、道路上を走行する車両であればよい。さらに、図１において、第１車両Ｍ１を１つしか示していないが、第２車両Ｍ２の周辺に第１車両Ｍ１は複数存在してもよい。同様に、第１車両Ｍ１の周辺に第２車両Ｍ２は複数存在してもよい。つまり、第１車両Ｍ１、第２車両Ｍ２はそれぞれ複数存在してもよい。以降、第１車両側装置１、第２車両側装置２、センター３の順に説明する。
【００３０】
＜第１車両側装置１について＞
まずは第１車両側装置１の構成及び作動について述べる。第１車両側装置１は図２に示すように、車載センサ１１、ＧＮＳＳ用アンテナ１２Ａ、ＧＮＳＳ受信機１２、広域通信用アンテナ１３Ａ、広域通信制御部１３、運行管理部１４、車車間通信用アンテナ１５Ａ、及び車車間通信制御部１５を備える。
【００３１】
車載センサ１１、ＧＮＳＳ受信機１２、広域通信制御部１３、運行管理部１４、及び車車間通信制御部１５のそれぞれは、第１車両Ｍ１に構築されているローカルエリアネットワーク（以降、ＬＡＮ：Local Area Network）１０に接続している。
【００３２】
車載センサ１１は、第１車両Ｍ１の走行に関する種々の状態量を検出するための種々のセンサである。車両の走行に関する状態量とは、例えば、走行速度、ヨーレート、操舵角、加速度、シフト位置などである。つまり、走行速度を検出する速度センサや、ヨーレートを検出するヨーレートセンサ、操舵角を検出する操舵角センサ、第１車両Ｍ１に作用する加速度を検出する加速度センサ、シフトポジションセンサ等が、車載センサ１１に含まれる。
【００３３】
車載センサ１１は、第１車両Ｍ１の走行状態を示す状態量の検出値を、ＬＡＮ１０を介して運行管理部１４や車車間通信制御部１５に逐次提供する。なお、車載センサ１１に含まれるセンサは上述したものに限らない。また、上述した全てのセンサを備えている必要もない。車載センサ１１の種類は適宜設計されればよい。
【００３４】
ＧＮＳＳ用アンテナ１２Ａは、ＧＮＳＳ（Global Navigation Satellite System）で用いられる衛星（ＧＮＳＳ衛星とする）から送信される電波を受信するためのアンテナである。ＧＮＳＳ用アンテナ１２Ａは、ＧＮＳＳ受信機１２と通信可能に接続されており、受信した電波に対応する電気信号をＧＮＳＳ受信機１２に提供する。
【００３５】
ＧＮＳＳ受信機１２は、ＧＮＳＳ用アンテナ１２Ａを介して、ＧＮＳＳ衛星から送信された信号を受信することで、ＧＮＳＳ受信機１２の現在位置を示す情報を取得する。ＧＮＳＳ受信機１２が取得した現在位置は、例えば、緯度、経度で表されれば良い。ＧＮＳＳ受信機１２が取得した位置情報は逐次（例えば１００ミリ秒毎に）運行管理部１４や車車間通信制御部１５に提供される。
【００３６】
広域通信用アンテナ１３Ａは、第１車両側装置１が広域通信網を介してセンター３と通信するためのアンテナである。広域通信用アンテナ１３Ａは、広域通信制御部１３と相互通信可能に接続されている。
【００３７】
広域通信制御部１３は、広域通信用アンテナ１３Ａ及び広域通信網を介してセンター３と通信を実施する。例えば運行管理部１４から入力されたベースバンド帯のデータを変調して、センター３に送信する。また、センター３から送信されたデータを広域通信網及び広域通信用アンテナ１３Ａを介して受信する。
【００３８】
運行管理部１４は、通常のコンピュータとして構成されており、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えている。ＲＯＭには、通常のコンピュータを運行管理部１４として機能させるためのプログラム（以降、運行管理プログラム）や、後述する連続運転時間の上限値等が格納されている。
【００３９】
この運行管理部１４は、ＣＰＵが上述の運行管理プログラムを実行することによって実現される機能ブロックとして、図３に示すように、連続運転時間特定部１４１、上限時間読出部１４２、残余時間算出部１４３、及び運行情報生成部１４４を備える。なお、運行管理部１４が備える機能の一部又は全部は、一つあるいは複数のＩＣ等によりハードウェア的に実現してもよい。
【００４０】
連続運転時間特定部１４１、上限時間読出部１４２、残余時間算出部１４３は、運行管理部１４が、後述する運転時間管理処理を実施するための機能ブロックである。運行時間管理処理は、第１車両Ｍ１の走行が開始されてからの経過時間に相当する連続運転時間、及び、連続運転が許容される上限値から現在の連続運転時間を指し引いた時間（以降、残余時間）等を取得するための処理である。これら連続運転時間特定部１４１、上限時間読出部１４２、及び残余時間算出部１４３の詳細については、別途後述する。
【００４１】
なお、連続運転時間及び残余時間のそれぞれが請求項に記載の運転時間関連情報に相当する。連続運転時間及び残余時間は何れも、第１車両Ｍ１のドライバの疲労度合いの指標として機能する情報である。つまり、或る車両（ここでは第１車両Ｍ１）の運転時間関連情報とは、その車両のドライバの疲労度合いの指標として機能する情報に相当する。便宜上、連続運転時間及び残余時間を区別しない場合には、それぞれの総称として運転時間関連情報と記載する。
【００４２】
運行情報生成部１４４は、車載センサ１１及びＧＮＳＳ受信機１２から入力される情報に基づいて、第１車両Ｍ１の運行状態を示す運行情報を、所定の報告間隔で生成する。報告間隔とは、センター３に対して第１車両Ｍ１の運行情報を送信する間隔である。報告間隔は適宜設計されれば良く、例えば１０秒などとすればよい。
【００４３】
運行情報は、例えば、第１車両Ｍ１の現在位置を示す位置情報、連続運転時間、前回運行情報を送信してからの現在までにサンプリングされた走行速度、加速度、操舵角等の時系列データとすればよい。運行情報生成部１４４は、運行情報を生成すると、その生成した運行情報を広域通信制御部１３に出力し、センター３に向けて送信させる。
【００４４】
車車間通信用アンテナ１５Ａは、車車間通信に用いられる周波数帯の電波を送受信するためのアンテナである。車車間通信用アンテナ１５Ａは車車間通信制御部１５と相互通信可能に接続されている。
【００４５】
車車間通信制御部１５は、車車間通信用アンテナ１５Ａと接続されてあって、第２車両Ｍ２と車車間通信を実施する。車車間通信制御部１５は、細かい部材として、図４に示すように、ＬＡＮインターフェース部１５０、データ格納部１５１、データ生成部１５２、送信処理部１５３、及び受信処理部１５４を備える。データ生成部１５２、送信処理部１５３、及び受信処理部１５４のそれぞれは、ＣＰＵが所定のプログラムを実行することで（換言すればソフトウェア的に）実現されても良いし、１つ又は複数のＩＣを用いてハードウェア的に実現されても良い。また、ＣＰＵによるソフトウェアの実行と、ハードウェア部材の両方を用いて実現されてもよい。
【００４６】
ＬＡＮインターフェース部１５０は、ＬＡＮ１０を介して他の部材と通信するためのインターフェースである。例えばＬＡＮインターフェース部１５０は、車載センサ１１の検出結果を取得したり、ＧＮＳＳ受信機１２の検出結果を取得したりする。車載センサ１１の検出結果や、ＧＮＳＳ受信機１２の検出結果は、第１車両Ｍ１の現在の走行状態を示す情報（以降、車両情報）に相当する。つまり、ＬＡＮインターフェース部１５０が請求項に記載の第１車両情報取得部に相当する。
【００４７】
データ格納部１５１は、ＲＡＭといった書き換え可能な記憶媒体を用いて実現されるメモリ領域と、ＲＯＭやフラッシュメモリといった不揮発性の記憶媒体を用いて実現されるストレージ領域を備える。
【００４８】
メモリ領域には、データ生成部１５２や受信処理部１５４から入力されるデータが一時的に保存される。また、メモリ領域には、後述する車両情報パケットや運転時間パケットをデータ生成部１５２が生成するためのデータも保存される。車両情報パケットを生成するためのデータとは、ＬＡＮインターフェース部１５０が取得した車載センサ１１の検出結果を示すデータや、ＧＮＳＳ受信機１２が検出する位置情報などである。運転時間パケットを生成するためのデータとは、運行管理部１４から提供される連続運転時間及び残余時間である。
【００４９】
データ生成部１５２は、車車間通信によって送信するデータとしての通信パケットを生成する。具体的には、データ生成部１５２は、車両情報パケット、及び、運転時間パケットを、予め定められているデータフォーマットに準拠するように生成する。
【００５０】
車両情報パケットは、第１車両Ｍ１の車両情報を示す通信パケットである。例えば車両情報パケットは、第１車両Ｍ１の現在位置、進行方向、走行速度、加速度、シフトポジションなどを含む通信パケットとすればよい。車両情報パケットは、車載センサ１１やＧＮＳＳ受信機１２から入力され、データ格納部１５１に蓄積されているデータに基づいて生成されればよい。第１車両Ｍ１の車両情報が請求項に記載の第１車両情報に相当する。
【００５１】
また、運転時間パケットは、例えば連続運転時間及び残余時間を含む通信パケットである。運転時間パケットは、運行管理部１４から提供されてデータ格納部１５１に格納されている連続運転時間及び残余時間に基づいて生成されれば良い。
【００５２】
例えば運転時間パケットの生成は、図５に示す手順で実行すればよい。ステップＳ１０１でメモリ領域に格納されている現在の（換言すれば最新の）連続運転時間を取得し、ステップＳ１０２に移る。ステップＳ１０２では、現在の残余時間を取得し、ステップＳ１０３に移る。ステップＳ１０３では、ステップＳ１０１で取得した連続運転時間と、ステップＳ１０２で取得した残余時間を含む運転時間パケットを、所定のデータフォーマットに準拠するように生成してフローを終了する。
【００５３】
データ生成部１５２は、車両情報パケット及び運転時間パケットを、それぞれ所定の時間間隔（例えば１００ミリ秒）で生成し、生成した通信パケットを送信処理部１５３に出力する。
【００５４】
送信処理部１５３は、データ生成部１５２から入力されたベースバンド帯のデータに対して周知の符号化や変調処理、デジタルアナログ変換処理等を施して得られる変調信号を、車車間通信用アンテナ１５Ａに出力する。車車間通信用アンテナ１５Ａに出力された変調信号は、当該車車間通信用アンテナ１５Ａから電波となって放射される。つまり、送信処理部１５３は、車車間通信における信号送信を実行する部材である。
【００５５】
受信処理部１５４は、車車間通信用アンテナ１５Ａが受信した電波に対応する電気信号（つまり受信信号）を取得する。そして、当該受信信号に対して、周知のアナログ・デジタル変換や復調処理、復号化等を施すことで受信信号に含まれるデータ（以降、受信データ）を抽出する。受信データは、データ格納部１５１のメモリ領域に格納される。車車間通信制御部１５が請求項に記載の車車間通信部に相当する。
【００５６】
＜運転時間管理処理＞
次に、図６に示すフローチャートを用いて運行管理部１４が実施する運転時間管理処理について説明する。図６に示すフローチャートは、例えば第１車両Ｍ１のイグニッション電源がオンとなっている間、一定時間（例えば６０秒）毎に開始されればよい。
【００５７】
まず、ステップＳ１１１では連続運転時間特定部１４１が第１車両Ｍ１の走行が開始されてからの経過時間に相当する連続運転時間を特定し、ステップＳ１１２に移る。連続運転時間特定部１４１が連続運転時間を特定する方法は適宜設計されれば良い。
【００５８】
ここでは一例として連続運転時間特定部１４１は、第１車両Ｍ１の走行が開始されたか否かを判定し、走行が開始されたと判定した場合にはその時点の時刻を走行開始時刻として運行管理部１４が備えるＲＡＭに登録する。そして、ステップＳ１１１では、現在時刻からＲＡＭに登録しておいた走行開始時刻を差し引くことで連続運転時間を算出するものとする。連続運転時間特定部１４１が算出した最新の連続運転時間はＲＡＭに保存されるとともに、車車間通信制御部１５に提供される。
【００５９】
第１車両Ｍ１の走行が開始されたか否かの判断基準は、適宜設計されればよい。本実施形態では一例として連続運転時間特定部１４１は、イグニッション電源がオンとなった時点を第１車両Ｍ１の走行開始時点と見なすものとする。
【００６０】
なお、他の態様として、イグニッション電源がオンとなってから初めてシフトポジションが駐車ポジションから駆動力を駆動輪に伝達するポジション（つまり、走行可能なポジション）にシフトされた時点を、走行開始時点と見なしても良い。その場合、イグニッション電源がオンとなってから初めてシフトポジションが駐車ポジションから走行可能なポジションに移った時点が、連続走行時間の起算時点となる。また、走行開始時点の入力はドライバによって実施されてもよい。例えば、目的地までの一連の走行を開始する旨を入力するためのボタンを設けておき、当該ボタンを介して一連の走行を開始することを示すドライバ操作を受け付ければよい。
【００６１】
また、より好ましい態様として、連続運転時間特定部１４１は次のように作動してもよい。すなわち、走行開始時刻の登録後において停車状態（駐車状態を含む）が所定の中断認定時間（例えば１０分）以上保持されていることを検出した場合には、その停車時間をＲＡＭに登録していく。そして、ＲＡＭに登録されている停車時間の合計値が所定のリセット時間（例えば３０分）を超過した場合には、いったん連続運転時間を０に戻す。
【００６２】
なお、運行管理部１４がフラッシュメモリ等の書き換え可能であって不揮発性の記憶媒体を備えている場合には、走行開始時刻や停車時間は、当該書き換え可能であって不揮発性の記憶媒体に保存されることが好ましい。パーキングエリア等での休憩時においてイグニッション電源をオフにする場合であっても、連続運転時間の計測を継続するためである。或いは、イグニッション電源がオフとなった後も、少なくともリセット時間が経過するまでは、ＲＡＭのデータが保持されるように車載バッテリー等から電力が供給されることが好ましい。
【００６３】
停車状態であるか否かは、走行速度や、シフトポジション、パーキングブレーキのオンオフ状態、ＧＮＳＳ受信機１２の検出結果などを用いて判定することができる。例えば走行速度が０ｋｍ／ｈとみなすことができる所定の範囲に収まっている場合には停車していると判定すればよい。
【００６４】
ところで、本実施形態では連続運転時間特定部１４１は、運転時間管理処理のステップＳ１１１に移った時に連続運転時間を算出（換言すれば更新）する態様とするが、これに限らない。他の態様として、連続運転時間特定部１４１は、走行の開始を検出してからの経過時間を逐次計測し続けるものであってもよい。そのような態様における連続運転時間特定部１４１は、連続運転時間を示す変数を、時間の経過に伴って増加させていくことで、連続運転時間を保持すればよい。連続運転時間特定部１４１による連続運転時間の計測は、信号待ち等に由来する一時的な（例えば１０分未満の）停車状態となっている間も継続されることが好ましい。
【００６５】
ステップＳ１１２では、上限時間読出部１４２が、運行管理部１４が備えるＲＯＭにアクセスし、予め設定されている上限時間を読み出してステップＳ１１３に移る。ここでの上限時間とは、連続運転が許容される上限値である。上限時間は適宜設定されればよい。
【００６６】
例えば上限時間は、国土交通省等の行政機関が規定する、労働としての運転時間の上限値（例えば４時間）としてもよいし、第１車両Ｍ１を所有する会社の内部規定として定められている時間としてもよい。当然、会社内部の規定によって定められる上限時間は、行政機関が定める上限値よりも短い時間となっていることが好ましい。
【００６７】
また、上限時間は、広域通信網を介してセンター３から情報伝送されてもよい。その場合には、広域通信制御部１３がセンター３から送信された上限時間を受信し、運行管理部１４へ転送する。運行管理部１４は、そのセンター３から送信されてきた上限時間を、書き換え可能なメモリ（例えばＲＡＭ）に格納する。
【００６８】
ステップＳ１１３では残余時間算出部１４３が、上限時間読出部１４２が読み出した上限時間から、連続運転時間特定部１４１が特定した現在の連続運転時間を差し引いた時間（以降、残余時間）を算出する。残余時間は、当該第１車両Ｍ１のドライバがそのまま運転を継続することが許容される残り時間に相当する。残余時間は、上限時間から現在の連続運転時間を減算した値であるため、連続運転時間を間接的に示す情報と言える。
【００６９】
ステップＳ１１３において残余時間算出部１４３が算出した残余時間は、連続運転時間特定部１４１が算出した連続運転時間と同様に、運行管理部１４が備えるＲＡＭに格納されるとともに、車車間通信制御部１５に提供される。ステップＳ１１３での処理が完了すると、図６に示すフローは終了となる。
【００７０】
＜第２車両側装置２について＞
次に、第２車両側装置２の構成及び作動について述べる。第２車両側装置２は図７に示すように、車載センサ２１、ＧＮＳＳ用アンテナ２２Ａ、ＧＮＳＳ受信機２２、広域通信用アンテナ２３Ａ、広域通信制御部２３、車車間通信用アンテナ２４Ａ、車車間通信制御部２４、報知制御部２５、ディスプレイ２６、スピーカ２７、及び入力装置２８を備える。
【００７１】
車載センサ２１、ＧＮＳＳ受信機２２、広域通信制御部２３、報知制御部２５、車車間通信制御部２４、ディスプレイ２６、スピーカ２７、及び入力装置２８のそれぞれは、第２車両Ｍ２に構築されているＬＡＮ２０に接続している。これにより、例えば報知制御部２５は、ＬＡＮ２０を介して、車載センサ２１やＧＮＳＳ受信機２２から種々のデータが入力されるとともに、広域通信制御部２３、車車間通信制御部２４、ディスプレイ２６、スピーカ２７のそれぞれに対して所定のデータを提供できる。
【００７２】
車載センサ２１、ＧＮＳＳ用アンテナ２２Ａ、ＧＮＳＳ受信機２２、広域通信用アンテナ２３Ａ、広域通信制御部２３、車車間通信用アンテナ２４Ａのそれぞれは、第１車両側装置１が備える同一名称の部材に対応する部材であるため、その詳細な説明は省略する。
【００７３】
ディスプレイ２６やスピーカ２７は、周知のディスプレイやスピーカである。ディスプレイ２６は、第２車両Ｍ２のドライバが、運転中において視認しやすい位置に配置されていることが好ましい。なお、ディスプレイ２６はヘッドアップディスプレイでもよい。
【００７４】
入力装置２８は、報知制御部２５に対するユーザの指示操作を受け付けるための装置である。例えば入力装置２８は、ディスプレイ２６と一体になったタッチパネルとすればよい。他の態様として、入力装置２８は、メカニカルなスイッチ等であってもよいし、図示しないマイクを備えた音声認識装置であってもよい。また、入力装置２８として、それら複数種類の装置を備えていても良い。
【００７５】
車車間通信制御部２４もまた、第１車両側装置１が備える車車間通信制御部１５に対応する部材であって、車車間通信用アンテナ２４Ａを介して第１車両Ｍ１と車車間通信を実施する。つまり、車車間通信制御部２４もまた、図８に示すようにＬＡＮインターフェース部２４０、データ格納部２４１、データ生成部２４２、送信処理部２４３、及び受信処理部２４４を備える。
【００７６】
車車間通信制御部２４が備える各部材は、第１車両側装置１の車車間通信制御部１５が備える同一名称の部材に対応するものであって、同様の機能を備えている。ただし、第２車両側装置２は、運転時間パケットを送信する必要はないため、車車間通信制御部２４のデータ生成部２４２は、運転時間パケットを生成しない。
【００７７】
より具体的に、送信処理部２４３は、第２車両Ｍ２のイグニッション電源がオンとなっている間、図９に示す送信関連処理を逐次（例えば１０ミリ秒毎）実施する。まず、ステップＳ２１１では車両情報パケットの送信タイミングであるか否かを判定する。そして、送信タイミングである場合にはステップＳ２１１が肯定判定されてステップＳ２１２に移る。一方、送信タイミングではない場合にはステップＳ２１１が否定判定されて本フローを終了する。例えば送信処理部２４３は、車両情報パケットを前回送信させてから一定時間（例えば１００ミリ秒）以上経過している場合に、送信タイミングになっていると判定すればよい。
【００７８】
ステップＳ２１２では車載センサ２１やＧＮＳＳ受信機２２から入力されているデータに基づいて第２車両Ｍ２の車両情報を示す車両情報パケットを生成してステップＳ２１３に移る。第２車両Ｍ２の車両情報が請求項に記載の第２車両情報に相当する。
【００７９】
ステップＳ２１３では、ステップＳ２１２で生成した車両情報パケットを車車間通信用アンテナ２４Ａから送信させてステップＳ２１４に移る。ステップＳ２１４では、今回送信した車両情報パケットの元となった車両情報をデータ格納部２４１に保存して本フローを終了する。
【００８０】
また、受信処理部２４４は、第２車両Ｍ２のイグニッション電源がオンとなっている間、図１０に示す受信関連処理を逐次実施する。まず、ステップＳ２２１では車車間通信の規格に則ったデータ（以降、車車間通信データ）を受信したか否かを判定する。車車間通信データとは、例えば他車両（ここでは第１車両Ｍ１）から送信された車両情報パケットや運転時間パケットなどである。車車間通信データを受信した場合にはステップＳ２２１が肯定判定されてステップＳ２２２に移る。一方、車車間通信データを受信していない場合にはステップＳ２２１が否定判定されて本フローを終了する。ステップＳ２２２ではステップＳ２２１で受信した車車間通信データに示される情報をデータ格納部２４１に保存して本フローを終了する。
【００８１】
つまり、第２車両側装置２の車車間通信制御部２４は、車両情報パケットを送信した場合には、その送信した車両情報パケットの元となった車両情報をデータ格納部２４１に保存する。また、第１車両Ｍ１から送信されてきた車両情報パケットや、運転時間パケットを受信した場合には、その受信した種々の通信パケットに示される情報をデータ格納部２４１に格納する。具体的には、第１車両Ｍ１の車両情報や、運転時間関連情報を保存する。
【００８２】
また、車車間通信制御部２４は、報知制御部２５から所定の情報の提供を要求された場合には、その要求された情報を提供する。例えば車車間通信制御部２４は、報知制御部２５から運転時間関連情報を要求された場合には、その運転時間関連情報を報知制御部２５に提供する。
【００８３】
なお、データ格納部２４１において運転時間関連情報は、その情報の送信元の車両情報と対応付けて保存されているものとする。つまり、データ格納部２４１において第１車両Ｍ１の運転時間関連情報は、第１車両Ｍ１の車両情報と対応付けて保存されているものとする。そして、車車間通信制御部２４は、報知制御部２５から第１車両Ｍ１の運転時間関連情報を要求された場合には、その運転時間関連情報と対応付けられている第１車両Ｍ１の車両情報も報知制御部２５に提供する。なお、ＬＡＮインターフェース部２４０が請求項に記載の第２車両情報取得部に相当する。
【００８４】
報知制御部２５は、通常のコンピュータとして構成されており、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えている。ＲＯＭには、通常のコンピュータを報知制御部２５として機能させるためのプログラム（以降、報知プログラム）や種々の設定データが格納されている。
【００８５】
この報知制御部２５は、ＣＰＵが報知プログラムを実行することによって実現される機能ブロックとして、図１１に示すように、報知判定部２５１、報知処理部２５２、通報判定部２５３、及び通報処理部２５４を備える。なお、運行管理部１４が備える機能の一部又は全部は、一つあるいは複数のＩＣ等によりハードウェア的に実現してもよい。
【００８６】
報知判定部２５１は、第１車両Ｍ１のドライバ（以降、第１ドライバ）の運転時間関連情報について、第２車両Ｍ２のドライバ（以降、第２ドライバ）に報知する処理（以降、報知処理）すべきか否かを判定する機能ブロックである。なお、報知処理自体は後述する報知処理部２５２によって実施される。
【００８７】
この報知判定部２５１は、当該判定のために、逐次（例えば１００ミリ秒毎に）車車間通信制御部２４から第１車両Ｍ１の最新の連続運転時間及び残余時間を取得する。そして、第１車両Ｍ１の連続運転時間が、所定の報知用規定時間を超過しているか否かを判定する。第１車両Ｍ１の連続運転時間が所定の報知用規定時間を超過している場合には、報知処理部２５２に対して、第１車両Ｍ１を対象とする報知処理を実行するように要求する。
【００８８】
ここでの報知用規定時間とは、第１ドライバの連続運転時間について、第２ドライバに報知すべきか否かを判定するための時間である。報知用規定時間は、第１ドライバの疲労度が高まっていることが想定される連続運転時間に対応する値とすることが好ましい。例えば、報知用規定時間は前述の上限時間に応じた値とすればよい。例えば報知用規定時間は上限時間から０．５時間減算した値などとすればよい。
【００８９】
また、報知判定部２５１は、残余時間を用いて、第１車両Ｍ１を対象とする報知処理が必要か否かを判定してもよい。具体的には、残余時間が所定の残余閾値以下となっている場合に、報知処理部２５２に対して、第１車両Ｍ１を対象とする報知処理を実行するように要求する。残余閾値は適宜設計されればよく、例えば０．５時間などとすればよい。
【００９０】
報知処理部２５２は、報知判定部２５１からの要求に基づき、ディスプレイ２６やスピーカ２７といった、第２ドライバに対して情報を提示するデバイス（以降、情報提示装置）と協働し、第２ドライバに対して第１ドライバの連続運転時間や残余時間を報知するための処理（以降、報知処理）を行う。
【００９１】
例えば報知処理部２５２は、第１車両Ｍ１の連続運転時間や残余時間といった運転時間関連情報を示す画像やテキストをディスプレイ２６に表示する。尚、報知処理部２５２は、第２ドライバが、第２車両Ｍ２の周辺に存在する車両のうち、何れの車両に対応する運転時間関連情報が表示されているかを認識可能な態様で、第１車両Ｍ１の運転時間関連情報を提示するものとする。例えば報知処理部２５２は、第２車両Ｍ２と第１車両Ｍ１の位置関係を示す画像であって、かつ、第１車両Ｍ１の近傍に第１車両Ｍ１の運転時間関連情報を配置した画像をディスプレイ２６に表示すればよい。
【００９２】
また、報知処理部２５２は、第２車両Ｍ２と第１車両Ｍ１の位置関係を示す情報と、第１車両Ｍ１の運転時間関連情報と、を含む音声メッセージを、スピーカ２７から出力させても良い。このような態様によっても、ディスプレイ２６を用いた報知処理と同様の効果を奏する。
【００９３】
通報判定部２５３は、第１車両Ｍ１の挙動に起因して、所定の危険回避行動を第２ドライバが実施したか否かを判定する。ここでの危険回避行動とは、急な減速操作やハンドル操作などである。そして、通報判定部２５３は、第１車両Ｍ１の挙動に起因する危険回避行動を第２ドライバが実施したと判定した場合には、通報処理部２５４に対して、第１車両Ｍ１の挙動についてセンター３に通報する処理（以降、通報処理）を実施するように要求する。便宜上、通報処理が必要か否かを判定するための一連の処理を、通報要否判定処理と称する。この通報判定部２５３の作動については別途後述する。
【００９４】
通報処理部２５４は、通報判定部２５３からの要求に基づき、第１車両Ｍ１を対象とする通報処理を実施する。この通報処理の詳細については別途後述する。
【００９５】
＜通報要否判定処理について＞
次に、通報判定部２５３が実施する通報要否判定処理について図１２に示すフローチャートを用いて説明する。図１２に示すフローチャートは、第２車両Ｍ２のイグニッション電源がオンとなっている間、逐次実施されればよい。
【００９６】
まず、ステップＳ２３１では車載センサ２１から第２車両Ｍ２の挙動を示すデータ（つまり車両情報）を取得し、第２ドライバによって急な運転操作が実施されたか否かを判定する。例えば、ヨーレートが所定のしきい値以上となっている場合、又は、減速の度合いが所定の閾値以上となっている場合に急な運転操作が実施されたと判定する。つまり、ステップＳ２３１では第２車両Ｍ２の車両情報に基づいて、急なハンドル操作、又は、急な減速操作が実施されたか否かを判定する。
【００９７】
急な運転操作が実施されている場合にはステップＳ２３１が肯定判定されてステップＳ２３２に移る。一方、急な運転操作が実施されていない場合にはステップＳ２３１が否定判定されて本フローを終了する。
【００９８】
ステップＳ２３２では、第１車両Ｍ１の車両情報を車車間通信制御部２４から取得してステップＳ２３３に移る。なお、ステップＳ２３２では第１車両Ｍ１の車両情報として、現在から一定時間以内における複数時点の車両情報を取得することが好ましい。ここでの一定時間とは、第１車両Ｍ１の挙動と第２ドライバによる急な運転操作との因果関係が推定できる程度の時間とすればよく、例えば５秒程度とすればよい。
【００９９】
ステップＳ２３３では、ステップＳ２３２で取得した第１車両Ｍ１の車両情報を解析して、第１車両Ｍ１が、第２ドライバの急な運転操作を誘引する挙動を行っていたか否かを判定する。換言すればこのステップＳ２３３では、ステップＳ２３１で検出した第２ドライバによる急な運転操作の原因が、第１車両Ｍ１にあるか否かを判定する。
【０１００】
例えば、第１車両Ｍ１が第２車両Ｍ２の前方を走行する車両である場合であって、かつ、現在から一定時間以内に急ブレーキを実施している場合に、第２ドライバによる急な運転操作の原因は第１車両Ｍ１にあると判定すればよい。なお、第１車両Ｍ１と第２車両Ｍ２の位置関係は、第１車両Ｍ１及び第２車両Ｍ２のそれぞれの位置情報及び進行方向から判定すれば良い。
【０１０１】
また、現在から一定時間以内に、第１車両Ｍ１が第２車両Ｍ２の前方に、急に進路変更してきている場合にも、第２ドライバによる急な運転操作の原因は第１車両Ｍ１にあると判定してもよい。一定時間以内に第１車両Ｍ１が第２車両Ｍ２の前方に進路変更してきたか否かは、一定時間以内における第２車両Ｍ２に対する第１車両Ｍ１の相対位置の時間変化から判定すればよい。第２車両Ｍ２に対する第１車両Ｍ１の相対位置は、それぞれの位置情報から算出することができる。
【０１０２】
また、第１車両Ｍ１が実施した進路変更が、急な進路変更に該当するか否かは、進路変更に要した時間や、進路変更後における第１車両Ｍ１と第２車両Ｍ２との車間距離、進路変更開始の一定時間前から第１車両Ｍ１が方向指示器を動作させていたか否か、などを総合的に鑑みて判断されれば良い。つまり、第１車両Ｍ１が実施した進路変更が、急な進路変更に該当すると判断するための条件は適宜設計されれば良い。
【０１０３】
このステップＳ２３３において、ステップＳ２３１で検出した急な運転操作の原因が第１車両Ｍ１にあると判定した場合にはステップＳ２３４に移る。一方、ステップＳ２３１で検出した急な運転操作の原因は第１車両Ｍ１ではないと判定した場合にはステップＳ２３３が否定判定されて本フローを終了する。この場合、通報判定部２５３は第１車両Ｍ１を対象とする通報処理は不要であると判定したことを意味する。
【０１０４】
ステップＳ２３４では、第１車両Ｍ１を対象とする通報処理を実施するように通報処理部２５４に要求して本フローを終了する。この場合、通報判定部２５３は第１車両Ｍ１を対象とする通報処理が必要であると判定したことを意味する。
【０１０５】
＜通報処理＞
次に、図１３に示すフローチャートを用いて、通報処理部２５４が実施する通報処理について説明する。図１３に示すフローチャートは、通報判定部２５３から通報処理の要求を受けた時に開始される。
【０１０６】
まず、ステップＳ２４１では、車車間通信制御部２４から第２車両Ｍ２の車両情報を取得してステップＳ２４２に移る。ステップＳ２４２では、車車間通信制御部２４から第１車両Ｍ１の車両情報を取得して、ステップＳ２４３に移る。なお、ここで取得する第１車両Ｍ１の車両情報は、急な運転操作の原因となった挙動を示す車両情報であることが好ましい。
【０１０７】
ステップＳ２４３では、第１車両Ｍ１の運転時間関連情報を車車間通信制御部２４から取得してステップＳ２４４に移る。なお、ステップＳ２４１〜Ｓ２４３における種々の情報の取得元は、通報判定部２５３であっても良い。通報判定部２５３は、通報要否判定処理の過程において、車車間通信制御部２４から同様の情報を取得済みであるためである。
【０１０８】
ステップＳ２４４では、ステップＳ２４１〜Ｓ２４３で取得した第１車両Ｍ１の車両情報、第１車両Ｍ１の運転時間関連情報、第２車両Ｍ２の車両情報を含む通報用データを生成して、ステップＳ２４５に移る。
【０１０９】
ステップＳ２４５は、通報用データの送信先を示す情報（以降、通報先情報）を取得してステップＳ２４６に移る。ここでの通報先情報とは、例えば広域通信網におけるセンター３のアドレスである。なお、通報先情報は、センター３を特定するものであればよく、例えば、電話番号や会社名などであっても良い。仮に通報先情報として電話番号や会社名などを取得した場合には、当該情報を検索キーとした検索を行い、広域通信網におけるセンター３のアドレスを取得すれば良い。
【０１１０】
通報先情報の取得方法は適宜設計されれば良い。例えば、通報先情報は、入力装置２８に対するユーザ操作に基づいて取得してもよい。具体的には、ユーザに対して通報先情報を入力するように促す入力画面をディスプレイ２６に表示し、ユーザによる通報先情報の入力操作を受け付ける。入力画面には、ユーザが、入力中の通報先情報を表示する入力フォームと、入力内容を確定させる確定ボタンが含まれていればよい。
【０１１１】
そして、通報先情報の入力が完了したことを示すユーザ操作が行われたことを検出した場合に、ユーザによって入力されている文字列等を通知先情報として取得すればよい。なお、前提として第１車両Ｍ１のボディの背面部や側面部等、正面部には、第１車両Ｍ１の通報先情報が記載されているものとする。
【０１１２】
もちろん、通報先情報の取得方法は、上述した方法に限らない。第２車両Ｍ２が、車両外部を撮影するカメラを備えている場合には、当該カメラが撮影した画像データに対して周知の画像認識処理を施すことによって、第１車両Ｍ１のボディに記載されている通知先情報を取得してもよい。
【０１１３】
また、第１車両側装置１は、通報先情報を含む運転時間パケットを送信する態様としてもよい。そのような態様によれば、報知制御部２５は、ユーザに対する通報先情報の入力の要求や、カメラの撮影画像に対する画像認識処理を実施することなく、通報先情報を取得することができる。
【０１１４】
ステップＳ２４６では、ステップＳ２４４で生成した通報用データと、ステップＳ２４５で取得した通報先情報を広域通信制御部２３に出力し、通報先情報に示す宛先に、通報用データを送信するように要求する。つまり、通報用データをセンター３に向けて送信させる。
【０１１５】
なお、以上では、通報用データは第２車両Ｍ２の車両情報を含むものとしたが、これに限らない。例えば、通報用データは、第１車両Ｍ１についての情報だけを含むデータとしてもよい。
【０１１６】
また、通報用データの内容は、第１車両Ｍ１の車両ＩＤだけであってもよい。車両ＩＤは、車車間通信を実施する通信端末（換言すれば車両）毎に割り当てられる識別情報である。第１車両Ｍ１の車両ＩＤは、第１車両Ｍ１から車車間通信で送信される通信パケットにおいて送信元アドレスとして含まれている。
【０１１７】
そのような態様によってもセンター３は、通報用データに含まれる車両ＩＤに基づいて、急な運転操作を誘引する運転を実施した第１車両Ｍ１を特定することができる。なお、その場合の前提として、センター３は、管理対象とする車両毎の車両ＩＤを保持しているものとする。
【０１１８】
＜センター３について＞
センター３は、広域通信網に接続しており、第１車両Ｍ１及び第２車両Ｍ２と広域通信網を介して相互通信可能に構成されている。センター３は、１つのサーバ装置からなるものであってもよいし、複数のサーバ装置がクラウドコンピューティング技術によって協働して実現されるものであってもよい。
【０１１９】
センター３は、第１車両Ｍ１から送信されてくる運行情報に基づいて第１車両Ｍ１の運行状態を管理する。なお、第１車両Ｍ１から送信されてくる運行情報は、例えばデータベース３１に時系列順に保存していけばよい。データベース３１は、書き換え可能な記憶媒介を用いて実現されれば良い。データベース３１には、第１車両Ｍ１を運転しているドライバが誰であるかといった、センター３が管理する車両とそのドライバとの対応関係を示すデータ（いわゆる配車情報）も格納されている。
【０１２０】
また、センター３は、第２車両Ｍ２から第１車両Ｍ１に対する通報情報を受信した場合には、当該通報情報に基づいて、第１ドライバの運転操作が適切であるか否かを判定する。適切であるか否かの判断基準は、所定の社内規定に準じればよい。
【０１２１】
このような態様によれば、センター３は、第１車両Ｍ１が適切な運行状態を保持しているか否かを判断できる。換言すれば第１ドライバが適切な運転操作を実施しているか否かを判定することができる。また、通知用データには第１ドライバの運転時間関連情報も含まれているため、第１ドライバが適切な運転操作を実施していないと判定した場合には、第１ドライバの連続運転時間と不適切な運転操作との因果関係を検証することもできる。
【０１２２】
＜実施形態のまとめ＞
以上の構成では、第１車両側装置１は、第１車両Ｍ１（換言すれば第１ドライバ）の連続運転時間及び残余時間を含む運転時間パケットを、車車間通信によって逐次送信する。したがって、第２車両側装置２は、第１車両Ｍ１から送信された運転時間パケットを受信することで、第１ドライバの連続運転時間及び残余時間を取得することができる。そして、連続運転時間が所定の報知用規定時間以上である場合、或いは、残余時間が所定の残余閾値以下となっている場合には、第１ドライバの運転時間関連情報を第２ドライバに報知する。
【０１２３】
このような構成において、仮に運転時間関連情報として連続運転時間を報知する場合には、第２ドライバは、第１ドライバの連続運転時間が報知用規定時間以上であるか否かを認識することができる。また、上記構成において、仮に運転時間関連情報として残余時間を報知する場合には、第２ドライバは、第１ドライバの残余時間が所定の残余閾値以下となるほど、第１ドライバは運転を連続的に実施していることを認識することができる。
【０１２４】
一般的に、連続運転時間が長ければ長いほど、ドライバの疲労度は高まっている可能性が高くなる。すなわち、連続運転時間や残余時間は、ドライバの疲労度を推定するための指標として機能する。
【０１２５】
そのため、第２ドライバは、第１ドライバの連続運転時間や残余時間といった運転時間関連情報を知ることで、第１ドライバの疲労度を推定することができる。その結果、第２ドライバは、第１ドライバの疲労度が高まっていると推定した場合には、第１車両Ｍ１との車間距離を一般的に言われている適正値よりも長めにとる等の処置を講ずることができる。つまり、第１ドライバの運転時間関連情報を、防衛運転のための参考情報として利用することが出来る。
【０１２６】
また、本実施形態では、第１車両Ｍ１の運転時間関連情報を第２ドライバに報知する場合には、第２車両Ｍ２に対する第１車両Ｍ１の相対位置を示す情報とともに、第２ドライバに対して当該第１車両Ｍ１の運転時間関連情報を報知する。
【０１２７】
当然、第２車両Ｍ２の周辺に複数の他車両が存在する状況も想定される。そのような状況においても、上記構成によれば、第２ドライバは、第２車両側装置２から報知されている運転関連情報が、第２車両Ｍ２の周辺に存在する複数の車両のうち、何れの車両についての情報なのかが認識することができる。換言すれば、第２ドライバは、第２車両Ｍ２の周辺に存在する複数の車両のうち、連続運転時間が相対的に長い車両を認識することができる。
【０１２８】
なお、第２車両Ｍ２の周辺に第１車両側装置１を搭載している複数の車両（つまり第１車両）が存在している場合には、第２車両側装置２は、複数の第１車両側装置１のそれぞれに対して、上述した動作（例えば報知の要否判定等）を実施すればよい。
【０１２９】
さらに、上述した実施形態では、通報判定部２５３が、第１車両Ｍ１の挙動に起因して所定の危険回避行動を第２ドライバが実施したと判定した場合には、通報処理部２５４が広域通信制御部２３と協働して、通報用データをセンター３に送信する。ここでの通報用データとは、第２ドライバが危険回避行動を実施した時点又は直前における、第１車両Ｍ１の運転時間関連情報及び車両情報、並びに第２車両Ｍ２の車両情報である。
【０１３０】
このような態様によれば、第１車両Ｍ１を管理／所有する会社は、第１車両Ｍ１の運転操作が適切に行われているか否かを判断するための情報を収集することができる。また、第１ドライバとしての役割を担う従業員に対して、より安全な運転操作を心がけるように、働きかけることができる。
【０１３１】
つまり、会社が管理／所有する業務用車両に第１車両側装置１を搭載することで、会社にとっては、安全運行に対するルール維持のための仕組みとして活用できる。また、そうした安全運転への取り組みを社会的にアピールすることもできる。
【０１３２】
なお、以上では危険回避行動の一例として、急な減速操作や急なハンドル操作などを想定した通報要否判定処理について例示したが、これに限らない。急な減速操作や急なハンドル操作といった、急な運転操作に限らず、通常と異なる運転操作を検出した場合に、ステップＳ２３１を肯定判定する態様としてもよい。
【０１３３】
ここでの通常と異なる運転操作とは、例えば高速道路上での減速操作など、交通ルールとして推奨されていない運転操作とすればよい。また、仮に第２車両側装置２が、第２ドライバの運転操作の履歴から第２ドライバによる運転操作の特性を学習する機能（便宜上、運転特性学習機能とする）を備えている場合には、運転特性学習機能が学習している第２ドライバの運転特性に基づいて、第２ドライバが通常と異なる操作を実施したか否かを判定しても良い。なお、ドライバの運転特性を学習する方法は、例えば特許第５０３６６２０号に開示の方法など、周知の方法を援用すればよい。
【０１３４】
もちろん、トラックやバスのドライバにとっては、上限時間以上の連続運転などを回避することが出来て、労働環境の改善につながる。
【０１３５】
以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。
【０１３６】
なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。
【０１３７】
＜変形例１＞
以上では、連続運転時間が所定の報知用規定時間以上となっている場合や、残余時間が所定の残余閾値以下となっている場合に、第１車両Ｍ１の運転時間関連情報を第２ドライバに報知する態様を例示したが、これに限らない。第１車両Ｍ１からの運転時間パケットを受信している場合には、当該第１ドライバの運転時間関連情報を、無条件で第２ドライバに報知しても良い。
【０１３８】
＜変形例２＞
上述の実施形態では、運転時間パケットとして、連続運転時間及び残余時間の両方を含むデータを送信する態様を例示したがこれに限らない。運転時間パケットは、運転時間関連情報を含んでいればよい。つまり、連続運転時間と残余時間の少なくとも何れか一方を含んでいればよい。また、運転時間パケットは、第１車両Ｍ１に設定されている上限時間を含んでいても良い。
【０１３９】
＜変形例３＞
上述した実施形態では、第１車両の挙動に起因する急ブレーキ等の急な運転操作を検出した場合に、通報処理を実施する態様を例示したが、これに限らない。例えば、第１車両Ｍ１から通知された残余時間が、所定の残余通報閾値以下となっている場合に、通報処理を実施してもよい。ここで用いる残余通報閾値は、０であってもよいし、負の値であっても良い。例えば、−１５分程度とすればよい。つまり、残余通報閾値の具体的な値は、適宜設計されればよい。
【０１４０】
また、第１車両Ｍ１から通知された連続運転時間が、所定の連続運転用通報閾値以上となっている場合に、通報処理を実施してもよい。連続運転用通報閾値は、行政機関が規定する、労働としての運転時間の上限値としてもよいし、当該上限値に所定の裕度を加えた値としてもよい。つまり、連続運転用通報閾値の具体的な値は、適宜設計されればよい。
【０１４１】
なお、この変形例３において、第２車両Ｍ２の周辺が渋滞中である場合には、種々の通報閾値を用いた通報の要否判定はキャンセルされてもよい。また、渋滞中である場合には、通報閾値として、渋滞中でない場合に用いる値よりも長い値を適用してもよい。
【０１４２】
＜変形例４＞
上述した実施形態では、第１車両Ｍ１がセンター３に運行状態を管理される車両としたが、これに限らない。第１車両Ｍ１はセンター３にその運行状態を管理されている必要はない。
【０１４３】
その場合、第１車両側装置１は、運行情報を外部に送信する必要はないため、広域通信制御部１３及び広域通信用アンテナ１３Ａを備えている必要はない。つまり、第１車両側装置１において、広域通信制御部１３及び広域通信用アンテナ１３Ａは必須要素ではない。
【０１４４】
＜変形例５＞
上述した実施形態では、第２車両側装置２が通報処理を実施する態様を例示したが、これに限らない。必ずしも第２車両側装置２は通報処理を実施する機能を備えている必要はない。通報処理を実施する機能とは、広域通信制御部２３、広域通信用アンテナ２３Ａ、通報判定部２５３、及び通報処理部２５４である。つまり、第２車両側装置２において、広域通信制御部２３、広域通信用アンテナ２３Ａ、通報判定部２５３、及び通報処理部２５４は必須要素ではない。
【０１４５】
＜変形例６＞
以上では、第１車両側装置１は車両に搭載されている態様を例示したが、これに限らない。第１車両側装置１は車両に持ち込まれる携帯型の装置であってもよい。第２車両側装置２も同様である。また、第１車両側装置１と第２車両側装置２の両方の機能を備える装置があってもよい。
【０１４６】
＜変形例７＞
なお、上述した実施形態では車車間通信の態様として、各車両が広域通信網を介さずに直接的に無線通信を実施する態様を例示したが、これに限らない。車車間通信は、広域通信網を介して実施してもよい。ただし、その場合には、各車両の位置情報を用いて、或る車両が送信した通信パケットを受信する車両はその送信元に相当する車両の周辺に存在する車両に限定されるように、或る車両が送信した通信パケットの配信先は、車車間通信システムを管理する管理センターによって制御されるものとする。
【０１４７】
つまり、車車間通信は、或る車両が送信したデータを受信可能な車両が、送信元車両の周辺に存在する車両に限定される通信であればよい。送信元車両の周辺とは、送信元車両からの距離が最大でも数百メートル程度となる範囲を指す。なお、上述した車車間通信には、道路沿いに設けられた路側機を介して車両同士が無線通信を実施する態様も含まれる。
【符号の説明】
【０１４８】
１００  運転支援システム、Ｍ１  第１車両、Ｍ２  第２車両、１  第１車両側装置（情報送信装置）、２  第２車両側装置（運転支援装置）、１１・２１  車載センサ、１２・２２  ＧＮＳＳ受信機、１２Ａ・２２Ａ  ＧＮＳＳ用アンテナ、１３・２３  広域通信制御部、１３Ａ・２３Ａ  広域通信用アンテナ、１４  運行管理部、１５・２４  車車間通信制御部、１５Ａ・２４Ａ  車車間通信用アンテナ、２５  報知制御部、２６  ディスプレイ、２７  スピーカ、２８  入力装置、１４１  連続運転時間特定部、１４２  上限時間読出部、１４３  残余時間算出部、１４４  運行情報生成部、１５０・２４０  ＬＡＮインターフェース部、１５１・２４１  データ格納部、１５２・２４２  データ生成部、１５３・２４３  送信処理部、１５４・２４４  受信処理部、２５１  報知判定部、２５２  報知処理部、２５３  通報判定部、２５４  通報処理部
【図１】
0006471675.tif 000002
【図２】
0006471675.tif 000003
【図３】
0006471675.tif 000004
【図４】
0006471675.tif 000005
【図５】
0006471675.tif 000006
【図６】
0006471675.tif 000007
【図７】
0006471675.tif 000008
【図８】
0006471675.tif 000009
【図９】
0006471675.tif 000010
【図１０】
0006471675.tif 000011
【図１１】
0006471675.tif 000012
【図１２】
0006471675.tif 000013
【図１３】
0006471675.tif 000014