図1は、本発明に係るドライブレコーダを用いた交通情報システムの一実施形態を示すブロック図である。
図1に示すように、本実施形態の交通情報システムは、ドライブレコーダ1と、携帯電話端末2と、電子制御ユニット3(以下、ECU[Electric Control Unit]3と呼ぶ)と、車載センサ4と、携帯電話回線5と、サーバ6と、を有して成る。
ドライブレコーダ1は、交通事故発生時や危険運転時などに車両の運転状況データ(映像データや走行データなど)を記録する手段である。なお、ドライブレコーダ1の構成及び動作については、後ほど詳細に説明する。
携帯電話端末2は、車両の運転者(または同乗者)によって車室内に持ち込まれるものであり、携帯電話回線5を介して無線による通話や通信を行う基本的な機能のほかに、ドライブレコーダ1との間で有線または無線による相互通信を行う付加機能を備えている。なお、ドライブレコーダ1と携帯電話端末2との連携動作については後ほど詳述する。
ECU3は、車両に搭載されて車両各部の動作を制御する手段であり、ECU3からドライブレコーダ1には、車両の運転状況データを構成する要素として、車両各部の動作状態データ(ランプ類(ヘッドランプ、テールランプ、ウィンカランプ、ハザードランプなど)の点灯状態データ、ドアロックの開閉状態データ、サイドミラーの開閉状態データ、ワイパーの駆動状態データ、パワーウィンドウの駆動状態データ、エアバックの駆動状態データ、ABS[Antilock Brake System]の駆動状態データなど)が伝達される。
車載センサ4は、車両に搭載されて車両各部や車両周辺の状況を検出する手段であり、車両の前後/左右方向に生じる加速度を検出する加速度センサ、車両の鉛直軸周りの回転速度(車両の自転速度)を検出するヨーレートセンサ、車両の走行速度を検出する車速センサ、車輪(タイヤ)の回転速度を検出する車輪速センサ、ステアリングの操舵角を検出する操舵角センサ、ステアリングの操舵トルクを検出する操舵トルクセンサ、ブレーキペダルの踏み込み度合いを検出するブレーキペダルセンサ、車両各部の油圧を検出する油圧センサ、タイヤの空気圧を検出する空気圧センサ、車外気温や車内気温を検出する温度センサ、周囲の明るさを検出する照度センサ、路面状態を検出する路面センサ、車両前後の車間距離を検出する車間距離センサ、車両周辺の障害物を検出する障害物センサ(コーナセンサ)、及び、車両に生じた衝突を検出する衝突センサなどを挙げることができる。なお、車載センサ4からドライブレコーダ1には、車両の運転状況データを構成する要素として、上記の各種検出データが伝達される。
携帯電話回線5は、携帯電話端末2が接続される公衆回線であり、通信事業者によって提供される。
サーバ6は、携帯電話回線5を介して携帯電話端末2との間で通信を行う手段であり、警察や保険会社などに設置される。
次に、ドライブレコーダ1の構成及び動作について詳述する。図1に示したように、ドライブレコーダ1は、制御部101と、撮像部102と、GPS[Global Positioning System]受信部103と、加速度センサ104と、インタフェイス部105と、リアルタイムクロック106(以下、RTC[Real Time Clock]106と呼ぶ)と、記憶部107と、通信部108と、操作部109と、警告部110と、を有して成る。
制御部101は、ドライブレコーダ1を構成する上記の各機能部102〜110を統括的に制御する手段であり、CPU[Central Processing Unit]のほかに、ROM[Read Only Memory]やRAM[Random Access Memory]などの記憶手段(いずれも不図示)を有して成る。上記のROMは、CPUによって実行されるプログラムなどの格納領域として使用される。また、上記のRAMは、CPUの作業領域として使用されるほか、車両の運転状況データを所定時間分(数秒〜数分)だけ一時的に格納しておくバッファ領域としても使用される。なお、制御部101の動作については、後ほど詳細に説明する。
撮像部102は、車両周辺(少なくとも車両の前方)を常に動画撮影するカメラ部と、得られた映像データに所定の画像処理(アナログ/デジタル変換処理、ノイズ除去処理、色補正処理、画像圧縮処理など)を施して制御部101に出力する画像処理部と、を有して成る(いずれも図示せず)。なお、カメラ部を構成する光電変換素子としては、CCD[Charge Coupled Devices]やCMOS[Complementary Metal Oxide Semiconductor]を用いればよい。また、撮像部102は、車両前方の様子を適切に動画撮影することが可能であって、かつ、運転者の視界を妨げることのない位置(バックミラーの裏面など)に取り付けることが望ましい。このように、車両の運転状況データを構成する要素として、車両周辺を動画撮影した映像データを含めることにより、交通事故の原因究明を迅速かつ適切に行うことが可能となる。
なお、本実施形態では、車両周辺を常に動画撮影する構成を例に挙げたが、本発明の構成はこれに限定されるものではなく、例えば、所定のインターバルで間欠的に動画撮影、ないしは、静止画撮影を行う構成としても構わない。このような構成とすることにより、制御部101に搭載されるRAMや記憶部107の記憶容量を抑えることが可能となる。
GPS受信部103は、GPS衛星からの衛星信号を利用して車両の現在位置(緯度、経度、高度)を示す車両位置データを制御部101に出力する手段である。このように、車両の運転状況データを構成する要素として、車両位置データを含めることにより、交通事故の発生に至る走行経路を事後解析することが可能となる。
加速度センサ104は、互いに直交する3軸方向(X軸方向(=車両の進行方向)、Y軸方向(=車両の左右方向)、Z軸方向(=車両の上下方向))の加速度を各々検出し、これを加速度データとして制御部101に出力する手段である。なお、加速度データの検出方式としては、ピエゾ抵抗方式や静電容量方式を用いることができる。このように、車両の運転状況データを構成する要素として、車両の加速度を示す加速度データを含めることにより、交通事故時に生じた車両の衝撃を事後解析することが可能となる。
インタフェイス部105は、車両に搭載されたECU3から入力される車両各部の動作状態データや車載センサ4から入力される各種の検出データを制御部101に出力する手段である。このように、車両の運転状況データを構成する要素として、ドライブレコーダ1本体で得られる情報だけでなく、ドライブレコーダ1の外部(ECU3や車載センサ4など、車両自体に搭載されている既存の装備)で得られる情報を含めることにより、ドライブレコーダ1の大型化やコストアップを招くことなく、多くの運転状況データを収集することが可能となる。
RTC106は、日付と時刻に関する時刻データを生成して制御部101に出力する手段である。このように、車両の運転状況データを構成する要素として、日付と時刻を含めることにより、交通事故の発生に至る時間経過を事後解析することが可能となる。
上記したように、本実施形態のドライブレコーダ1において、撮像部102、GPS受信部103、加速度センサ104、インタフェイス部105、並びに、RTC106は、いずれも、車両の運転状況データを時系列的に収集するデータ収集部として機能する。ただし、本発明の構成はこれに限定されるものではなく、例えば、ドライブレコーダ1本体に搭載したGPS受信部103や加速度センサ104をドライブレコーダ1に外部接続しても構わないし、逆に、ドライブレコーダ1の外部に設けられた車載センサ4の一部をドライブレコーダ1本体に組み込んでも構わない。
記憶部107は、所定のトリガ条件(詳細は後述)が満足されたときに、制御部101でバッファされている運転状況データを不揮発的に格納する手段であり、フラッシュメモリやEEPROM[Electrically Erasable and Programmable Read Only Memory]などの半導体メモリ、若しくは、ハードディスクドライブなど大容量記憶デバイスを用いることができる。なお、記憶部107は、運転状況データの可搬性を優先してドライブレコーダ1に着脱可能な構成としてもよいし、逆に、運転状況データの改竄防止を優先して着脱不能な構成としてもよい。また、記憶部107に格納される運転状況データの内容についても、上記に限定されるものではなく、事後解析の充実を優先して制御部101に入力されるデータを全て格納する構成としてもよいし、逆に、記憶部107の容量縮小を優先して制御部101に入力されるデータの一部のみを格納する構成としてもよい。また、運転状況データの不正コピー等を防止すべく、記憶部107は、上述の運転状況データを暗号化して格納する構成としてもよい。
通信部108は、携帯電話端末2との間で有線または無線による相互通信を行う手段である。なお、ドライブレコーダ1と携帯電話端末2との間を有線接続する場合には、USB通信ポートやUART[Universal Asynchronous Receiver Transmitter]通信ポートなどを用いればよい。また、ドライブレコーダ1と携帯電話端末2との間を無線接続する場合には、赤外線通信ポート(IrDA[Infrared Data Association]通信ポート)やワイヤレスLAN[Local Area Network]通信ポート(Wi−Fi通信ポート)、またはBluetooth(登録商標)通信ポートなどを用いればよい。すなわち、通信部108は、携帯電話端末2に搭載されている汎用の通信ポートを介して、携帯電話端末2との相互通信を行う構成とされている。このような構成であれば、携帯電話端末2側にハードウェアの追加や変更を要求することなく、ドライブレコーダ1と携帯電話端末2との相互通信を実現することが可能となる。
操作部109は、ユーザ操作を受け付ける手段であり、ボタンやスイッチ、タッチパネルなどを用いて構成される。
警告部110は、制御部101からの指示に基づき、運転者に対して危険な運転を控えるように警告を発する手段である。なお、上記の警告については、音声や映像(若しくはその組み合わせ)によって行えばよい。このような警告を発する構成であれば、運転者は常に安全運転を心掛けるようになるので、交通事故の抑制に寄与することが可能となる。なお、制御部101は、車両の急発進、急ハンドル、急ブレーキ、急シフトチェンジ、夜間の無灯火、方向指示器の操作を伴わない車線変更、蛇行、周囲の車両や建造物との急接近などを検知したときに、警告部110に対して上記の警告を発するように指示を送る。また、警告部110は、交通事故に関する情報の共有サービスを提供する際に、運転者への注意喚起手段としても用いられるが、これについては後述する。
次に、制御部101による運転状況データの格納動作について詳細に説明する。制御部101は、加速度センサ104で検出された車両の加速度が所定の閾値を超えたとき(車両に対して所定の閾値を超える衝撃が加わったとき)や、操作部104で所定のユーザ操作(交通事故通報ボタンの押下など)が受け付けられたとき、通信部108を介して携帯電話端末2からの要求を受け付けたとき、若しくは、警告部110による警告が必要と判定されたときに、所定のトリガ条件(不揮発格納条件)が満足されたと判定し、記憶部107を制御して運転状況データを格納する。ここで、記憶部107に格納される運転状況データは、上記のトリガ条件が満足されたタイミング前後の所定期間(数秒間〜数分間)に、制御部101のRAMで一時格納される運転状況データである。
このように、ドライブレコーダ1を車両に搭載しておけば、自責の交通事故や危険運転が記録されてしまうことを嫌い、運転者は常に安全運転を心掛けるようになるので、交通事故の抑制に寄与することが可能となる。また、万一、過失責任のない運転者が交通事故に巻き込まれてしまった場合には、ドライブレコーダ1に記録された運転状況データを事後解析することにより、運転者の正当性を立証することも可能となる。
次に、制御部101によるドライブレコーダ1と携帯電話端末2との連携動作について詳細に説明する。
先にも述べた通り、本実施形態のドライブレコーダ1は、携帯電話端末2との間で有線または無線による相互通信を行う通信部108を有して成り、制御部101は、通信部108を制御することにより、携帯電話端末2との間で、先述の運転状況データやドライブレコーダ1の動作設定を行うための動作設定データ(例えば、現在の運転状況データに基づいて交通事故や危険運転が生じたか否かを判定するためのトリガ条件や、制御部101で実行されるファームウェア)を送受信する構成とされている。
このような構成とすることにより、パーソナルコンピュータに比べて圧倒的に普及率の高い携帯電話端末2を用いて、ドライブレコーダ1に記録された運転状況データの閲覧や動作設定の確認/変更を行うことができるので、ユーザにとって利便性の高いドライブレコーダ1を提供することが可能となる。
例えば、運転者が交通事故に遭遇した場合、運転者は、自身の携帯電話端末2を用いてドライブレコーダ1に記憶された運転状況データを遅滞なく閲覧することができるので、警察や保険会社に対して迅速かつ正確に現在の状況を通報することが可能となる。
また、相手方の存在する交通事故に巻き込まれた場合であっても、ドライブレコーダ1に記録された運転状況データをその場で閲覧しながら、双方の過失割合を示談交渉することができるので、相手方の一方的な主張に言い負かされて不利を余儀なくされる心配がなくなる。また、過失割合の大きい相手方にとっては、不当な賠償請求が困難となるので、交通マナーの向上や、当たり屋による偽装交通事故の抑制に貢献することも可能となる。
また、本実施形態のドライブレコーダ1において、制御部101は、上述のトリガ条件が満足されたと判定した際に、記憶部107を制御して運転状況データを格納するとともに、通信部108を制御して携帯電話端末2に運転状況データを自動送信する構成とされている。このような構成とすることにより、運転者の操作を何ら要することなく、ドライブレコーダ1に記録された運転状況データが自動的に携帯電話端末2へと送られるので、その閲覧を容易に行うことが可能となる。
また、本実施形態の携帯電話端末2は、ドライブレコーダ1から運転状況データを受信したときに、これを携帯電話回線5経由で所定のサーバ6に転送する転送機能部(図示せず)を有して成る構成とされている。このような構成とすることにより、交通事故が生じたときには、携帯電話端末2が自ら警察や保険会社に交通事故の状況を通報する形となるので、運転者が意識不明の重体や茫然自失の状態に陥っている場合であっても、その通報を遅滞なく完了することが可能となる。また、運転状況データの改竄防止にも繋がる。
また、本実施形態の携帯電話端末2は、所定のユーザ操作を受け付けたときに、ドライブレコーダ1に運転状況データの送信を要求する送信要求機能部(図示せず)を有して成る構成とされている。このような構成とすることにより、携帯電話端末2をあたかもドライブレコーダ1のリモートコントローラのように用いることが可能となる。
また、本実施形態の携帯電話端末2は、サーバ6からの要求に応じて、ドライブレコーダ1に運転状況データの送信を要求する送信要求機能部(図示せず)を有して成る構成とされている。
例えば、ある地点で交通事故が生じたことを認識したサーバ6は、事故現場近傍の基地局エリア内に存在する不特定多数の携帯電話端末2に対して、事故発生時刻と事故現場の位置情報を送信するとともに、各々に連携するドライブレコーダ1で記録された運転状況データを転送するように要求する。この転送要求を受け取った携帯電話端末2は、ドライブレコーダ1に運転状況データの送信を要求し、ドライブレコーダ1から受信した運転状況データを携帯電話回線5経由でサーバ6に転送する。
このような交通情報システムを構築すれば、サーバ6の情報収集能力を高めて、交通事故の事後解析をより正確に実施することが可能となる。
ただし、携帯電話端末2の転送機能部は、上記の転送に先立ち、運転状況データに含まれる時刻データ及び車両位置データと、サーバ6から受信した事故発生時刻及び事故現場の位置情報とを解析し、交通事故の事後解析に際してドライブレコーダ1に記録された運転状況データが有用である可能性が高いと判定した場合、言い換えれば、ドライブレコーダ1に交通事故の様子が記録されている可能性が高いと判定した場合に限り、これをサーバ6に転送する構成としておくことが望ましい。このような構成とすることにより、携帯電話回線5の不必要な通信トラフィックを削減するとともに、交通事故の事後解析を円滑化することが可能となる。
また、携帯電話端末2の送信要求機能部や転送機能部は、ドライブレコーダ1との連携や上記交通情報システムの構築にのみ必要となる特殊な機能部である。そこで、これらの機能部を実現する手段としては、これに必要なハードウェアを追加するのではなく、携帯電話端末2に所定のプログラムをインストールし、これを実行する演算処理部(不図示)をソフトウェア的に送信要求機能部や転送機能部として機能させることが望ましい。このような構成とすることにより、携帯電話端末2側にハードウェアの追加や変更を要求することなく、ドライブレコーダ1と携帯電話端末2との連携や上記交通システムの構築を実現することが可能となる。
なお、上述したドライブレコーダ1は、トリガ条件が満たされたときに、運転状況データが記憶部107へ不揮発的に格納される仕様(以下、便宜的に「条件付格納仕様」と称する)といえる。また、条件付格納仕様のドライブレコーダ1において実行される動作の概要は、図2のフローチャートに示す通りとなる。
すなわちドライブレコーダ1は、運転状況データを収集してバッファ(制御部101のRAM等)へ一時的に格納する動作(ステップS11)、トリガ条件が満足されたかを監視する動作(ステップS12)、および携帯電話端末2から運転状況データの送信要求があったかを監視する動作(ステップS13)を、継続的に実行する。
そして、ドライブレコーダ1は、トリガ条件が満足された場合には(ステップS12のY)、バッファに格納されている運転状況データを記憶部107へ不揮発的に格納するとともに(ステップS14)、運転状況データを携帯電話端末2へ送信する(ステップS15)。また、ドライブレコーダ1は、携帯電話端末2から運転状況データの送信要求があった場合には(ステップS13のY)、運転状況データを携帯電話端末2へ送信する(ステップS15)。当該送信がなされた後は、ステップS11の処理に戻る。
以上に説明した「条件付格納仕様」のドライブレコーダ1によれば、運転状況データを効率よく(トリガ条件が満たされたときにだけ)、記憶部107へ格納することが可能である。そのため、運転状況データの記録のための処理負担や、記憶部107の記憶容量の増大を極力抑えることが可能である。
一方、ドライブレコーダ1の仕様を、運転状況データが記憶部107に(つまり不揮発的に)常時継続的に格納される仕様(以下、便宜的に「常時格納仕様」と称する)とすれば、何らかの原因による運転状況データの記録漏れを、極力防止することが可能である。そのため、ドライブレコーダ1が「条件付格納仕様」である場合に比べて、事故原因などに関する事後解析がより容易となる。
例えば、人や自転車などが車両にごく軽く接触したときには、その時に車両が受ける衝撃が小さ過ぎて、トリガ条件が満たされない(加速度センサの検出値が所定閾値を越えない)可能性がある。この場合、条件付格納仕様のドライブレコーダ1によれば、当該接触が発生した時点での運転状況データが記憶部107には格納されない。そのため、通常、当該運転状況データを事後的に確認することは難しくなる。
しかしながら、常時格納仕様のドライブレコーダ1によれば、当該接触が発生した時点での運転状況データも記憶部107に格納されるため、当該運転状況データを事後的に確認することが可能となる。その結果、当該運転状況データを事故原因などの事後解析に役立てることが可能となる。なお、例えば各種センサの故障等が発生した場合には、トリガ条件の判定に異常が生じる(よって、実質的にはトリガ条件が満たされていても、トリガ条件が満たされたと判定されなくなる)可能性も否めない。このような事態となっても、常時格納仕様のドライブレコーダ1によれば、運転状況データの記録漏れを未然に防ぐことが可能である。
ドライブレコーダ1を常時格納仕様とする場合には、運転状況データが常時継続的に収集されて、バッファ(制御部101のRAM等)へ一時的に格納されるようにするとともに、トリガ条件が満足されたか否かに関わらず、一時的に格納された運転状況データの全てが、記憶部107に転送されて格納されるようにすれば良い。また、ドライブレコーダ1を常時格納仕様とするにあたり、常時継続的に収集された運転状況データが、バッファを介さずに、記憶部107へ直接格納されるようにしても構わない。いずれのようにしても、ドライブレコーダ1の動作中において(例えば、ドライブレコーダ1の電源スイッチがオンの状態において)、運転状況データは常時継続的に収集された上で、記憶部107へ不揮発的に格納される。
なお、運転状況データの記憶部107への格納処理においては、例えば記憶部107における運転状況データの格納領域が飽和した段階で、最も古いデータの格納領域に、新たなデータが上書きされるようになっていても良い。このようにすれば、運転状況データの格納領域の不足が回避されるとともに、重要度の高い新たなデータを、優先的に残すことが可能となる。
また、常時格納仕様のドライブレコーダ1では、運転状況データの記憶部107への格納動作は、基本的に常時継続的に実行されることになるが、念のために当該動作を停止させる手段(例えば、動作を停止させるためのスイッチ)が設けられていても構わない。また、一部の種類の運転状況データのみが記憶部107へ常時格納されるようにしても構わない。
例えば、各運転状況データのうち、撮像部102によって取得された映像データのみが記憶部107へ常時継続的に格納されるようにし、他の運転状況データについては、トリガ条件が満たされた場合にだけ記憶部107へ格納されるようにしても構わない。このような構成によれば、トリガ条件が満たされなかった場合等における、映像の撮り逃しが防止されるとともに、記憶部107へのデータ格納に係る処理負担の増大等を極力抑えることが可能となる。
なお、撮像部102は、車両周辺の映像データの代わりに、或いは車両周辺の映像データに加えて、車両の内部の映像データを取得するようになっていても良い。このようにすれば、車両内部の映像データを記憶部107に格納させることが可能となる。その結果、例えば、タクシーの車内において運転手と客の間でトラブルが発生したような場合であっても、この状況を事後的に確認することが可能となる。また、撮像部102においては、車両の内部や外部に複数のカメラ部(撮像装置)が設置されるようにし、車両の周辺や内部の映像が、様々な位置や角度から取得可能となっていても良い。
また、常時格納仕様のドライブレコーダ1において実行される動作の概要は、図3のフローチャートに示す通りとなる。
すなわち、ドライブレコーダ1は、運転状況データを収集して記憶部107へ不揮発的に格納する動作(ステップS21)、トリガ条件が満足されたかを監視する動作(ステップS22)、および携帯電話端末2から運転状況データの送信要求があったかを監視する動作(ステップS23)を、継続的に実行する。
そして、ドライブレコーダ1は、トリガ条件が満足された場合(ステップS22のY)や、携帯電話端末2から運転状況データの送信要求があった場合(ステップS23のY)には、運転状況データを携帯電話端末2へ送信する(ステップS24)。当該送信がなされた後は、ステップS21の処理に戻る。
なお、ドライブレコーダ1の仕様は、例えば、ユーザの指示(操作部109の操作等)に応じて、条件付格納仕様と常時格納仕様のいずれにも設定可能(切替可能)となっていても構わない。このようにすれば、ドライブレコーダ1の利便性をより向上させることが可能である。また、ドライブレコーダ1において扱われる運転状況データとしては、以上までに具体的に示したものの他、運転に関わる状況(例えば、車両が運転されているか否か、どのように運転されているか等)を示す種々のデータを採用することが可能である。
以上に説明した通り、常時格納仕様のドライブレコーダ1は、車両の運転状況データを収集して不揮発的に格納する機能部(データ収集格納部)と、携帯電話端末2との間で、有線または無線による相互通信を行う機能部(通信部)と、これらの各機能部を統括的に制御する機能部(制御部)と、を有して成り、制御部は、携帯電話端末2との間で運転状況データや動作設定データを送受信するように、通信部を制御するとともに、運転状況データを常時継続的に収集して格納するように、データ収集格納部を制御する。
そのため、当該ドライブレコーダ1によれば、携帯電話端末2を用いて、運転状況データの閲覧や動作設定の確認/変更を行い得るようにすることが容易となるため、このようにして、ユーザにとっての利便性を向上させ得るものとなっている。また、運転状況データは常時継続的に収集されて不揮発的に格納されるから、運転状況データの記録漏れを極力回避することが可能となっている。
次に、サーバ6を主体とした交通事故に関する情報の共有サービスについて、図4を参照しながら詳述する。図4に示したように、上記機能を主体的に実現するサーバ6は、通信部61と、情報管理部62と、情報解析部63と、情報格納部64と、を有して成る。
通信部61は、携帯電話回線5を介して携帯電話端末2との通信を行うとともに、その他の回線7(専用回線やインターネットなど)を介して交通センターサーバ8、警察サーバ9、及び、保険会社サーバ10との通信を行う。
情報管理部62は、交通事故を起こした車両に搭載されているドライブレコーダ1から携帯電話端末2を介して転送されてくる運転状況データや、この運転状況データを解析して生成される交通事故データ(交通事故の発生地点や発生時刻など)、及び、複数の交通事故データを累積的に解析して生成される交通事故累積データ(交通事故の多発地点や多発時間帯など)を管理(取得、解析、格納、送信を含む)する。
情報解析部63は、交通事故を起こした車両に搭載されているドライブレコーダ1から携帯電話端末2を介して転送されてくる運転状況データを解析して、上記の交通事故データを生成する。また、情報解析部63は、複数の交通事故データを累積的に解析して、上記の交通事故累積データを生成する。
情報格納部64は、上記の運転状況データ、交通事故データ、及び、交通事故累積データを不揮発的に格納する。
なお、サーバ6は、交通センターサーバ8、警察サーバ9、及び、保険会社サーバ10と連携して、交通事故に関する情報(上記の運転状況データ、交通事故データ、及び、交通事故累積データを含む)を相互に利用可能な構成とすることが望ましい。このような構成とすることにより、交通事故に関する情報の充実化(把握している交通事故の母数増)やサーバ能力の分散化を実現することが可能となる。
上記構成から成るサーバ6は、携帯電話端末2からの要求に応じて、最新の交通事故累積データを送信する。携帯電話端末2は、サーバ6からの受信内容をドライブレコーダ1に転送する。このとき、ドライブレコーダ1と携帯電話端末2との通信が不可能な場合には、携帯電話端末2の不揮発性記憶部にサーバ6からの受信内容が一旦格納され、ドライブレコーダ1との通信が可能となったときに、改めて携帯電話端末2から最新の交通事故累積データがドライブレコーダ1に転送される。
携帯電話端末2からの転送を受けたドライブレコーダ1において、制御部101は、記憶部107に格納されている古い交通事故累積データを更新し、以後、最新の交通事故累積データに基づいて、運転者に対する注意喚起を行うように警告部110を制御する。例えば、交通事故累積データとして、事故多発地点に関する情報が含まれている場合には、その事故多発地点に近付いている車両の運転者に対して注意喚起が行われる。この注意喚起としては、事故多発地点である旨を音声で報知してもよいし、或いは、車両に別途搭載されているカーナビゲーションシステムのモニタを流用し、地図画面に事故多発地点を示すマーキング(アイコン表示など)を行ってもよい。
なお、交通事故累積データには、事故多発地点に関する情報のほかにも、事故多発時間帯や事故原因などの付随情報を含めておくことが望ましい。例えば、ある事故多発地点の付随情報として、「出会い頭の衝突が多い」というフラグが立てられていた場合には、上記の注意喚起として、周囲の安全確認を徹底すべきである旨の警告を事前に行うことが可能となり、また、「カーブでの速度超過によるセンターラインオーバー」というフラグが立てられていた場合には、上記の注意喚起として、カーブ進入時は十分に減速すべきである旨の警告を事前に行うことが可能となる。ただし、このような付随情報を含めるためには、交通事故を起こした車両に搭載されているドライブレコーダ1からの運転状況データを解析するだけでは不十分であることが多いため、先にも述べたように、交通センターサーバ8、警察サーバ9、及び、保険会社サーバ10と連携して、交通事故に関する情報を相互に利用可能な構成としておくことが望ましい。
このように、サーバ6を主体として、交通事故に関する情報の共有サービスを提供する交通情報システムであれば、交通事故を未然に防止する手段として、ドライブレコーダ1を積極的に活用することができるので、ドライブレコーダ購入のインセンティブとなり、延いては、交通安全の促進に大きく寄与することが可能となる。
なお、上記では、携帯電話端末2からの要求に応じて、サーバ6から最新の交通事故累積データを送信する構成を例に挙げて説明を行ったが、本発明の構成はこれに限定されるものではなく、例えば、交通事故に関する情報の共有サービス提供先として事前登録されている携帯電話端末2に対して、サーバ6から定期的(例えば毎月1回)に最新の交通事故累積データを送信する構成としてもよい。このような構成であれば、ドライブレコーダ1に格納されている交通事故累積データを常に最新の内容に維持することが可能となる。
また、上記では、携帯電話端末2に対して交通事故累積データを送信する構成を例に挙げて説明を行ったが、本発明の構成はこれに限定されるものではなく、例えば、交通事故を起こした車両からサーバ6に運転状況データが転送された時点で、事故発生地点近傍の基地局エリア内に存在する不特定多数の携帯電話端末2に対して、上記の運転状況データのうち、少なくとも事故発生地点の位置情報を速やかに送信する構成としてもよい。このような構成とすることにより、事故発生地点に近付いている車両の運転者は、自車の進路上で交通事故が発生したことをほぼリアルタイムに知ることができるので、迂回ルートを探索するなどして、交通渋滞や二次的な交通事故を未然に回避することが可能となる。
次に、サーバ6を主体とした燃費向上運転の判定サービスについて、図5と図6を参照しながら詳述する。図5は、運転状況の一例を示すタイムチャートであり、横軸は時間、縦軸は車両の速度を表している。また、図6は、図5の運転状況下で記録される運転状況データの一例を示すデータテーブルであり、特に、燃費向上運転の判定サービスに必要なパラメータ(図6では、日時(ti)、車両の位置(P(ti)、速度V(ti)、加速度A(ti)、及び、エンジンの回転数R(ti)、ただし、i=0〜14)が記載されている。
なお、図6に記載されている一連のパラメータについては、ドライブレコーダ1が先述の「条件付格納仕様」であるか「常時格納仕様」であるかに依ることなく、エンジンが始動されてから停止されるまでの間(すなわち、ドライブレコーダ1が駆動されている間)に収集された全ての計測値が破棄されることなく不揮発性の記憶部107に格納される。一方、交通事故の事後解析に必要な運転状況データについては、先述したように、事故発生タイミングの前後数秒〜数分間に収集されたデータのみが不揮発性の記憶部107に格納され、それよりも古いデータは順次破棄される。このように、運転状況データのうち、燃費向上運転の判定サービスに必要なパラメータについては、その計測値を長期間(例えば24時間)にわたって保持しなければならないが、燃費向上運転の判定サービスに必要なパラメータには、撮像部102で収集される撮像データが含まれていないため、記憶部107の記憶容量を不要に圧迫する心配はない。
時刻t0においてエンジンが始動されると、ドライブレコーダ1による運転状況データの収集及び格納が開始される。なお、運転状況データを収集する時間間隔は、分析精度とデータ容量とのバランスを考えて、適切な値(例えば0.5秒毎)に設定すればよい。時刻t0〜時刻t1は、アイドリング期間である。時刻t1〜時刻t2は、加速走行期間である。時刻t2〜時刻t3は、定速走行期間である。時刻t3〜時刻t4は、減速走行期間である。そして、時刻t4においてエンジンが停止されると、ドライブレコーダ1による運転状況の収集及び格納が終了される。
時刻t5において再びエンジンが始動されると、ドライブレコーダ1による運転状況データの収集及び格納が再開される。時刻t5〜時刻t6は、アイドリング期間である。時刻t6〜t7は、加速走行期間である。時刻t7〜時刻t8は、定速走行期間である。時刻t8〜t10は、加速走行期間である。時刻t10〜時刻t11は、定速走行期間である。時刻t11〜時刻t14は、減速走行期間である。そして、時刻t14においてエンジンが停止されると、ドライブレコーダ1による運転状況の収集及び格納が終了される。
その後、運転者が携帯電話端末2を用いて運転状況データの転送操作を行うと、記憶部107に格納されている運転状況データが携帯電話端末2経由でサーバ6に転送される。サーバ6では、携帯電話端末2から受信した運転状況データの解析が行われ、運転内容の燃費向上性に関する判定処理が行われた後に、その判定結果が携帯電話端末2に送信される。なお、上記の判定結果は、電子メールの本文に記載してもよいし、或いは、判定結果が記載されているURL[Uniform Resource Locator]を通知してもよい。
上記した燃費向上性に関する判定について、より具体的に説明する。不必要に燃料を浪費する運転操作の一例としては、速度の上げ過ぎ、急激な加速、急激な減速、及び、回転数の上げ過ぎ(空ぶかしを含む)など(以下、これらをまとめて「非効率運転」と呼ぶ)を挙げることができる。そこで、サーバ6は、1回の走行時間(図5及び図6では、時刻t0時刻t4と時刻t5〜時刻t14との合算時間)のうち、上記の非効率運転を行っている時間が占める割合を算出し、その算出値に基づいて、運転者に対する燃費向上運転の啓発や提案を行う構成とされている。
すなわち、サーバ6では、燃費向上性に関する判定に際して、速度V(ti)が所定の上限値Vthを上回っていないか、加速度A(ti)が所定の上限値Ath+を上回っていないか、加速度A(ti)が所定の下限値Ath−を下回っていないか、及び、回転数R(ti)が所定の上限値Rthを上回っていないかがチェックされ、上記に該当した判定項目が一つでもあれば、その時刻tiに非効率運転が行われていたと判定される。
図5及び図6に例示した運転状況に即して具体的に説明する。ただし、説明を簡単とするため、以下の説明では、回転数R(ti)を不問とし、速度V(ti)と加速度A(ti)に基づいて、燃費向上性に関する判定を行うものとする。
速度超過の判定に関しては、速度V(t9)〜速度V(t12)が所定の上限値Vthを上回っていると判定され、時刻t9〜時刻t12が非効率運転期間(速度超過期間)としてカウントされる。また、急加速の判定に関しては、加速度A(t6)〜加速度A(t7)が所定の上限値Ath+を上回っていると判定され、時刻t6〜時刻t7が非効率運転期間(急加速期間)としてカウントされる。また、急減速の判定に関しては、加速度A(t11)〜加速度A(t13)が所定の下限値Ath−を下回っていると判定され、時刻t11〜時刻t13が非効率運転期間(急減速期間)としてカウントされる。ただし、時刻t11〜時刻t12は、速度超過期間であり、かつ、急減速期間であるため、重複したカウントが行われることはない。
上記判定処理の終了後、サーバ6では、運転者に通知すべき判定結果のデータ作成が行われる。なお、判定結果の通知内容としては、例えば、1回の走行に占める非効率運転の割合に基づいて燃費向上運転の達成度を点数表示してもよいし、或いは、運転内容の内訳(例えば、燃費向上運転期間:A%、アイドリング期間:B%、非効率運転期間C%(速度超過期間:a%、急加速期間:b%、急減速期間:c%))を表示してもよい。また、今回の走行中で最も燃費の悪化を招いたと思われる運転操作(例えば速度超過)を指摘して、これを改めるようにアドバイスを表示することも有効である。なお、当然のことながら、サーバ6から受信した燃費向上運転の判定結果を運転者に報知するための手段としては、携帯電話端末2に搭載されている表示部(液晶表示パネルなど)を流用すればよい。
このように、サーバ6を主体として、燃費向上運転の判定サービスを提供する交通情報システムであれば、運転者が燃費向上運転を習得・実践・継続するための補助的手段として、ドライブレコーダ1を積極的に活用することができるので、ドライブレコーダ購入のインセンティブとなり、延いては、環境保全の促進に大きく寄与することが可能となる。
また、運転状況データの詳細な解析をドライブレコーダ1側ではなくサーバ6側で行う構成であれば、ドライブレコーダ1の情報処理能力を不要に高める必要がないので、装置の大型化やコストアップを招かずに済む。
なお、サーバ6は燃費向上運転の判定結果を累積的に格納しておく構成とすればよい。このような構成とすることにより、1回の走行毎に燃費向上運転の達成度を前回走行時と比較したり、或いは、燃費向上運転の達成度を所定の集計期間に亘って平均化するなどして、より継続的な分析を行うことができるようになるので、燃費向上運転の技量がどのように推移しているかを報知し、運転者のモチベーションを高めることが可能となる。
また、図5及び図6の例示においては、時刻t0〜時刻t1、及び、時刻t5〜時刻t6がいずれもアイドリング期間であり、速度V(ti)及び加速度A(ti)は共にゼロ値であるため、上記の判断項目に照らせば、これらの期間が非効率運転期間としてカウントされることはない。ただし、アイドリング期間が長過ぎる場合には、不必要に燃料を浪費することになるため、これを非効率運転として判定するように、燃費向上性に関する判定のアルゴリズムを適宜変更しても構わない。
また、上記では、説明を簡単にするために、回転数R(ti)を不問としたほか、その他の判定項目についても特段の言及は行わなかったが、燃費向上性に関する判定をより詳しく行うためには、例えば、速度V(ti)の揺らぎ(加速/減速の繰り返し)が生じているか否かを判定項目に加えることが望ましい。
また、速度V(ti)の上限値Vth、加速度A(ti)の上限値Ath+及び下限値Ath−、並びに、回転数R(ti)の上限値Rthについては、平地走行時と坂道走行時との違い、ないしは、一般道走行時と高速道走行時との違いなど、走行状態を考慮に入れて適宜調整することが望ましい。このような閾値の調整を行う場合には、ドライブレコーダ1からサーバ6に転送される運転状況データとして、車両の位置P(ti)に関する情報を含めておく必要がある。
また、上記では、ドライブレコーダ1で収集される運転状況データのうち、燃費向上運転の判定サービスに必要なパラメータとして、日時(ti)、車両の位置(P(ti)、速度V(ti)、加速度A(ti)、及び、エンジンの回転数R(ti)を選定し、これらのパラメータを時刻t0〜時刻t4、及び、時刻t5〜時刻t14にわたって継続的に計測・格納した上で、その格納内容を全てドライブレコーダ1からサーバ6に転送する構成を例に挙げて説明を行ったが、本発明の構成はこれに限定されるものではなく、記憶部107の容量削減や携帯電話端末2の通信データ削減(延いては通信費用の削減)を優先するのであれば、図6中のハッチング部分で示したように、エンジンの始動時と停止時、及び、非効率運転時にのみ、上記のパラメータを記憶部107に格納し、その格納内容をサーバ6に転送する構成にするとよい。このような構成を採用する場合には、ドライブレコーダ1側で非効率運転の判定(速度超過判定、急加速判定、急減速判定、回転数超過判定など)を行わねばならないが、そのためには各パラメータと所定の閾値を比較すれば足りるので、ドライブレコーダ1の情報処理能力を不必要に高める必要はない。
次に、記憶部107で不揮発的に格納された運転状況データの上書き禁止操作について詳細に説明する。
本実施形態のドライブレコーダ1では、記憶部107の容量に応じて、不揮発的に記憶しておける運転状況データのファイル数に上限値(例えば、センサトリガによる記憶ファイル数10件と、マニュアル操作トリガによる記憶ファイル数10件)があり、不揮発的に記憶されている運転状況データのファイル数が上限値に達した後、さらに新たな運転状況データのファイルを不揮発的に記憶する場合には、最も古い運転状況データのファイルが上書きされる。この点については、従前のドライブレコーダと同様である。
ただし、本実施形態のドライブレコーダ1では、不揮発的に記憶された運転状況データの各ファイル毎に、「上書許可属性」と「上書禁止属性」のいずれかを付与することが可能とされている。なお、記憶部107へ不揮発的に記憶された運転状況データの各ファイルには、デフォルト属性として「上書許可属性」が付与される。従って、意図的に「上書禁止属性」を付与しない限り、その運転状況データは、いずれ新たなファイルに上書きされて利用することができなくなる。一方、意図的に「上書禁止属性」が付与されたファイルについては、新たなファイルによる上書き対象から除外されるため、そのファイルが記憶部107に格納されている最も古いファイルであったとしても、新たなファイルによって上書きされることはないので、ユーザがそのファイルを意図的に削除しない限り、いつでも運転状況データの内容を確認することが可能となる。
例えば、自動車の運転中に軽微な接触事故が発生したため、念のためにマニュアル操作で運転状況データを不揮発的に記憶したが、その時点では、自己にも相手にも特段の問題がない様子であったため、不揮発的に記憶された運転状況データを確認して交渉することはしなかったものの、後日、自車の破損を発見したので相手に補償を求めたくなった場合や、逆に、相手から補償を求められる場合もあり得る。このような場合、事故発生時点で念のために格納しておいた運転状況データのファイルに「上書禁止属性」を付与しておけば、以後、その格納ファイルが上書きによって消失することはないので、後日、必要に応じて事故発生時の運転状況データを確認することが可能となり、延いては、相手との間で適切な交渉を行うことが可能となる。
図7は、不揮発的に格納された運転状況データの上書禁止操作を示すフローチャートである。
まず、ステップS31では、先に説明した所定のトリガ条件が満足されたか否かの判定が行われる。ここで、所定のトリガ条件が満足されたと判定された場合(例えば、車両に過大な衝撃が生じた場合や、ユーザによる運転状況データのマニュアル格納操作が行われた場合)には、フローが続くステップS32に進められる。一方、所定のトリガ条件が満足されたと判定されなかった場合には、フローがステップS31に戻されて、上記のトリガ条件判定処理が継続される。
ステップS31において、所定のトリガ条件が満足されたと判定された場合、ステップS32では、その時点で収集されている運転状況データが記憶部107へ不揮発的に格納される。このとき、運転状況データの格納ファイルには、デフォルト属性として「上書許可属性」が付与される。なお、「上書許可属性」については、必ずしも積極的にそのような専用のフラグを設けておく必要はなく、「上書禁止属性」が付与されていないことをもって、「上書き許可属性」が付与されていると見なすことができる。
続くステップS33では、上書き禁止操作の受付けに関するメッセージの報知が行われる。この報知としては、例えば、「ただいま、運転状況データを格納しました。この格納ファイルの上書きを禁止したい場合には、本体の上書き禁止ボタンを押して下さい。」といった音声アナウンスを行うマイクを設けてもよいし、或いは、上書き禁止操作の受付タイミングである旨を報知するためのランプを設けておき、これを点灯ないし点滅させる構成としてもよい。このような報知を行う構成であれば、ユーザは、運転状況データが不揮発的に格納された時点で遅滞なく、その格納ファイルに「上書禁止属性」を付与するか否かを判断することが可能となる。
ただし、ステップS33におけるメッセージの報知は、必ずしも必須のステップではなく、例えば、運転状況データの格納処理中に点灯ないし点滅されるランプがドライブレコーダ1に設けられている場合には、その点灯ないし点滅をもって上記の報知に代えてもよいし、或いは、全く上記の報知を行わなくても構わない。このような構成とすることにより、ドライブレコーダ1の本体には、何ら構成要素を追加せずに済む。
続くステップS34では、ユーザが上書き禁止操作を行ったか否かの判定が行われる。ここで、ユーザが上書き禁止操作を行ったと判定された場合には、フローがステップS35に進められる。一方、ユーザが上書き禁止操作を行ったと判定されなかった場合には、フローがステップS36に進められる。
なお、上記の上書き禁止操作としては、例えば、上書き禁止操作専用ボタンの押下を検出してもよいし、或いは、運転状況データの格納処理中におけるマニュアル格納用ボタンの押下を検出してもよい。
後者の構成について、例えば、車両に過大な衝撃が生じたり、或いは、ユーザがマニュアル格納用ボタンを押下すると、ステップS31において、所定のトリガ条件が満足されたと判定され、ステップS32において、その時点で収集されている運転状況データが記憶部107に格納されるが、その格納処理が行われている最中に、ステップS34において、ユーザがマニュアル格納用ボタンを押下したことが検出された場合には、これを上書き禁止操作として認識すればよい。このような構成とすることにより、ドライブレコーダ1の本体には、何ら構成要素を追加することなく、制御部101を動作させるためのソフトウェアを一部書き換えるだけで、上書き禁止操作を受け付けることが可能となる。
ステップS34において、ユーザが上書き禁止操作を行ったと判定された場合、ステップS35では、記憶部107に格納された運転状況データのファイルに「上書禁止属性」が付与されて、一連のフローが終了される。このような「上書禁止属性」が付与されたファイルについては、新たなファイルによる上書き対象から除外されるため、ユーザがそのファイルを意図的に削除しない限り、いつでも運転状況データの内容を確認することが可能となる。
一方、ステップS34において、ユーザが上書き禁止操作を行ったと判定されなかった場合、ステップS36では上書き禁止操作の受付終了条件が満足されたか否かの判定が行われる。ここで、所定の受付終了条件が満足されたと判定された場合には、記憶部107に格納された運転状況データのファイルに「上書禁止属性」が付与されることなく、デフォルト属性である「上書許可属性」が付与されたまま一連のフローが終了される。一方、所定の受付終了条件が満足されたと判定されなかった場合には、フローがステップS34に戻されて、ユーザによる上書き禁止操作の有無判定が継続される。
なお、上記の受付終了条件としては、例えば、ステップS31とは別に、所定のトリガ条件が満足されたか否か、すなわち、別の運転状況データを不揮発的に格納する必要が生じたか否かを検出すればよい。この場合、一の運転状況データが不揮発的に格納されてから、別の運転状況データを不揮発的に格納する必要が生じるまでは、直近の運転状況データに「上書禁止属性」を付与することが可能である。
また、上記の受付終了条件としては、例えば、ステップS31でトリガ条件が満足されてから所定時間(例えば数分〜数時間)が経過したか否かを検出してもよい。この場合、一の運転状況データが不揮発的に格納されてから、所定時間が経過するまでは、その運転状況データに「上書禁止属性」を付与することが可能である。
また、上記の受付終了条件としては、例えば、ドライブレコーダ1への電力供給が遮断されたか否かを検出してもよい。この場合、一の運転状況データが不揮発的に格納されてから、ドライブレコーダ1への電力供給が遮断されるまで、一般には、車両が停止されてイグニッションキーがオフとされるまでは、その運転状況データに「上書禁止属性」を付与することが可能である。
また、上記の受付終了条件としては、例えば、ステップS32における記憶部107への格納処理が完了したか否かを検出してもよい。この場合、一の運転状況データに「上書禁止属性」を付与することができるタイミングは、記憶部107への格納処理中に限定される。なお、この受付終了条件を採用する場合には、運転状況データの格納処理中に点灯されるランプをドライブレコーダ1に設けておき、当該ランプの点灯をもってステップS33におけるメッセージの報知とすることが望ましい。
なお、本発明の構成は、上記実施形態のほか、発明の主旨を逸脱しない範囲で種々の変更を加えることが可能である。すなわち、上記実施形態は、全ての点で例示であって、制限的なものではないと考えられるべきであり、本発明の技術的範囲は、上記実施形態の説明ではなく、特許請求の範囲によって示されるものであり、特許請求の範囲と均等の意味及び範囲内に属する全ての変更が含まれると理解されるべきである。例えば、運転状況データに「上書き禁止属性」を付与するタイミングについては、記録画像を再生するときでも構わない。