しかし、特許文献1に記載されたドライブレコーダのように所定以上の加速度の発生を契機として画像を格納するようにした場合、事故等の異常事態が実際には発生していないにもかかわらず画像が格納されるケースが多く、異常事態の検証負荷(例えば保険会社による検証負荷)を大きくする一因となっていた。すなわち、例えば、急ブレーキ、急加速、急ハンドル、道路の段差等によっても大きな加速度が発生してしまい、異常事態とは無関係の大量の画像のなかから有益な画像を探し出す必要があった。
そこで、本願発明では、例えば、異常事態の検証負荷を軽減すること等を可能ならしめるシステムおよびプログラム等を提供することを目的とする。
本願の発明の目的はこれに限定されず、本明細書および図面等に開示される構成の部分から奏する効果を得ることを目的とする構成についても分割出願・補正等により権利取得する意思を有する。例えば本明細書において「~できる」「~可能である」などと記載した箇所を「~が課題である」と読み替えた課題が本明細書には開示されている。課題はそれぞれ独立したものとして記載しているものであり、この課題を解決するための構成についても単独で分割出願・補正等により権利取得する意思を有する。課題が明細書の記載から黙示的に把握されるものであっても、本出願人は本明細書に記載の構成の一部を補正または分割出願にて特許請求の範囲とする意思を有する。またこれら独立の課題を組み合わせた課題も開示されている。
(1)所定以上の加速度が発生したときよりも低い頻度で成立しうる特定の条件が成立したことを契機として、撮像された画像を所定の記録領域に記録する機能を有する制御手段を備えることを特徴とする、車両に搭載可能なシステムとするとよい。
これによれば、所定以上の加速度が発生したときと比べて記録される画像が少なくなるので、異常事態の検証負荷を軽減すること等が可能となる。
なお、「所定以上の加速度が発生したとき」とは、例えば、車両等が通常に走行しているときに発生する加速度の範囲を超えたときとするとよい。例えば車両等が通常に走行しているときの加速度は、多少の上下幅があるものの正常の範囲内で上下していることが多い。しかし、例えば車両等が段差に乗り上げた時や急ブレーキ時には、加速度が一時的に(例えば一瞬)上昇することがある。このような場合に、所定以上の加速度が発生したと判断されうる。
特に、所定以上の加速度が発生した時に撮像された画像を記録する機能(ここでは加速度イベント記録機能という)を備えるとよく、「所定以上の加速度が発生したときよりも低い頻度で成立しうる特定の条件が成立したことを契機として、撮像された画像を所定の記録領域に記録する機能」は、この加速度イベント記録機能における記録条件である「所定以上の加速度」よりも低い頻度で成立しうる特定の条件が成立したことを契機として撮像された画像を所定の記録領域に記録する機能とすると特によい。また、加速度イベント記録機能によっての記録条件である「所定以上の加速度」は、ユーザ等の指示に基いて設定可能な構成とするとよく、特にこの場合、設定の中のデフォルトの設定である加速度よりも低い頻度で成立しうる特定の条件が成立したことを契機として撮像された画像を所定の記録領域に記録する機能とすると特によい。より望ましくは、設定可能な最も大きい加速度よりも低い頻度で成立しうる特定の条件が成立したことを契機として撮像された画像を所定の記録領域に記録する機能とするとよい。
「システム」は、車両以外の物体に搭載されるシステムであってもよい。車両以外の物体の例では、例えば、船舶や飛行機などに搭載されるシステムであってもよいが、特に車両に搭載されるシステムとするとよい。また、「システム」は、交通事故の瞬間などの画像を記録する、いわゆるドライブレコーダとするとよい。
「画像」は、静止画像であってもよいが、動画像とするとよい。動画像としては、例えば、一定時間間隔で撮影された一連の画像を、短い間隔で連続表示することによって得られる動きのある映像であってもよいし、完全に連続した映像であってもよい。
「加速度」は、例えば、加速度センサによって検知するものとするとよい。「加速度が発生したとき」としては、特に加速度が予め定められた値を超えたときとするとよい。この予め定められた値は設定することが可能なものとするとよく、正の値であってもよいし、負の値であってもよい。ただし、例えば車両等の物体が外部から衝撃を受けた場合に生じる加速度に設定されることが好ましく特に事故が起きたときに発生しうる加速度のレベルとするとよく、特に車両が他の物体に衝突したときに発生しうる加速度のレベルとするとよい。
「所定の記録領域」は、例えば、RAM等の記憶素子であってもよいし、メモリカード等の記憶媒体であってもよいが、記録速度が要求される場合には、RAM等の記憶素子であることが好ましい。また、これらの記憶領域は、システムに設けられていてもよいし、システムではない外部に設けられていてもよい。
所定の記録領域に対する記録は、例えば、連続的に画像を記録する常時記録であってもよいし、特定の条件が成立した時点の前後の所定の時間に画像を記録するイベント記録であってもよい。常時記録とイベント記録の双方を行う機能を備えるようにするとよく、例えば常時記録とイベント記録は異なる記録領域に記録するとよい。
所定の記録領域に記録される画像としては、例えば、車両等の物体どうしの接触事故、車両等の物体と人や動物との接触事故、車両等の物体と構造物との接触事故、などの例えば交通事故の他、隕石落下、洪水、地震等の天災に伴う事故、などの異常事態が映っている可能性のある画像を挙げることができる。
「特定の条件」としては、例えば、システムを搭載する例えば車両等の物体に異常事態が発生した可能性が高いことを示す条件、システムを搭載する例えば車両等の物体とは別の物体に異常事態が発生した可能性が高いことを示す条件などを挙げることができる。
「異常事態」としては、例えば、車両等の物体の例えば交通事故、水害・地震・隕石の落下等の天災に伴う事故、等を挙げることができる。また、「異常事態」における交通事故は、例えば、車両等の物体どうしの衝突事故、車両等の物体が構造物に激突する等の自損事故、車両等の物体が人などに衝突する人身事故等とするとよい。
(2)上記(1)のシステムにおいて、前記制御手段は、前記特定の条件として複数の条件が成立することにより前記所定以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るものとするとよい。
このようにすれば、例えば、複数の条件が成立することにより所定以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、例えば、異常事態の検証負荷を単独では必ずしも軽減できるとは言えない条件であっても、そのような条件が複数成立した場合には、加速度が発生したときに画像が記録される場合と比べて、異常事態の検証負荷を軽減することが可能な場合もある。なお、複数の条件のうち個々の条件が成立するタイミングは、或る程度近しいタイミング(所定時間以内)でなされていることが好ましい。
「複数の条件が成立」する例としては、例えば、所定以上の加速度が発生したことに加えて他の条件が成立したことや、所定以上の加速度が発生したときとは異なる複数の他の条件が成立したこと、などを挙げることができる。
複数の条件を構成する個々の条件は、例えば、特定の加速度が発生したこと(例えば、特定の大きさの衝撃を受けたときに発生する加速度が発生したこと)、システムを搭載する車両等の物体に事故を発生させ得る重量物が接近すること、異常な音(大きな衝突音、人の悲鳴など)が発生したこと、特定の加速度が発生した後に特定の時間内に車両等の物体が特定の時間以上停車したこと、特定の加速度が発生した後に特定の時間内に車両等の物体が減速(例えば微速まで減速)したこと、ユーザの身体の状態が通常の運転時とは異なる状態になったこと(ユーザの心拍数が所定値以上の心拍数となったこと、ユーザの呼吸数が所定値以上の呼吸数になったこと、ユーザの頭の位置が所定の領域から逸脱していること、など)、システムの作動中に当該システムのカメラの視界の所定割合以上の部分が何等かの物体で覆われたこと、事故への対応をサポートするサービスを行う事故サポートセンターへの連絡がなされたこと、車両の周囲に特定の車両等の物体(例えば、救急車、パトカーなどの緊急自動車)が停車すること、システムを搭載する車両等の物体が事故発生の可能性が高い場所を通過していること、システムを搭載する車両等の物体が事故発生の可能性が高い時間帯に運転されていること、などとするとよい。
ユーザは、例えば、車両の運転者でもよいし、運転者とは異なる者、例えば同乗者であってもよい。
ここで、上記の「車両等の物体に事故を発生させ得る重量物が接近すること」は、例えば、システムの撮像装置で撮像した画像を画像処理することで検知するとよい。また、マイクロ波センサ等の各種センサで検知することもできる。特に複数のカメラ等の映像に基づき生成されたアラウンドビュー画像のように、自車を上から見た画像を用いて車両位置と周辺の重量物との距離が所定の距離となったことを検出するとよい。上記の「車両等の物体に事故を発生させ得る重量物が接近すること」の「接近」は、特に車両と重量物との距離がゼロになったこととするとよい。「車両等の物体に事故を発生させ得る重量物」かは、特に車両周辺の物体の高さが所定以上であるか等によって判定するとよい。車両周辺の物体の高さが所定以上であるかはマイクロ波センサまたはカメラの少なくとも一方の映像に基いて検出するとよい。また、車両周辺の物体の高さの「所定」は、特に車高より高いこととするとよい。車高より低い物体は車の下を通過できるからである。
「異常な音が発生したこと」は、例えば、短くて大きな声が発生したこととすると特によい。
「短くて大きな声が発生したこと」は、例えば、車両等の物体に搭載したマイクで収集した音を解析することで検知することができる。大きくて短い声は、例えば、「ワッ」、「アッ」、「キャー」などの驚嘆や悲鳴の音声とするとよい。
また、上記の「特定の加速度が検知された後に特定の時間内に車両が停車したこと」や、上記の「特定の加速度が検知された後に特定の時間内に車両が減速したこと」を条件の1つとすることは、異常事態の検証負荷を軽減する上で有効である。事故発生直後には、現車確認や事故を起こした相手との交渉等のために減速して停車する場合が多いことに着目したものであり、これを検出するとよい。
「特定の時間内に車両が特定の時間以上停車」は、例えば、特定の平均速度以上の状態から3~5分以内に停車し、停車状態を5分以上継続することであるとよい。
「特定の時間内に車両が減速」は、例えば3~5分以内に車両が微速(例えば時速8km/h以下)まで減速することであるとよい。
車速は、例えば車速パルスを取得して算出するようにしてもよいが、GPSから取得するとよい。
また、上記の「ユーザの所定値以上の心拍数」、「ユーザの所定値以上の呼吸数」を条件の1つとすることは、異常事態の検証負荷を軽減する上で有効である。事故が発生すれば、ユーザは動揺して心拍数や呼吸数が上がることが多いことに着目したものであり、これを検出すると良い。
また、上記の「ユーザの頭の位置が所定の領域から逸脱していること」を条件の1つとすることは、異常事態の検証負荷を軽減する上で有効である。重大事故となれば、事故の衝撃によって体ごと大きく揺れたり意識を失ったりして、通常の運転中とは頭の位置が大きくずれたり、頭の位置を認識できなかったりすることが多いことに着目したものであり、これを検出すると良い。
(3)上記(1)または(2)のシステムにおいて、前記制御手段は、前記特定の条件として、前記所定以上の加速度の発生に加えて他の条件が成立することにより前記所定以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るものとするとよい。
このようにすれば、例えば、従来のセンサ(加速度センサ)を活用しつつ、異常事態の検証負荷を軽減すること等ができる。
「他の条件」としては、例えば、システムを搭載する車両に事故を発生させ得る重量物が接近すること、異常な音(大きな衝突音、人の悲鳴など)が発生したこと、特定の加速度が発生した後に特定の時間内に車両が停車したこと、特定の加速度が発生した後に特定の時間内に車両が減速(例えば微速まで減速)したこと、ユーザの身体の状態が通常の運転時とは異なる状態になったこと(ユーザの所定値以上の心拍数になったこと、ユーザの頭の位置が所定の領域から逸脱していること、など)、システムの作動中にこのシステムのカメラの視界の所定割合以上の部分が何等かの物体(例えば、展開したエアバッグ、事故の衝撃によって事故前の位置から移動した車内の物体、など)で覆われたこと、事故への対応をサポートするサービスを行う事故サポートセンターへの連絡がなされたこと、車両の周囲に特定の車両(例えば、救急車、パトカーなどの緊急自動車)が停車すること、システムを搭載する車両等の物体が事故発生の可能性が高い場所を通過していること、システムを搭載する車両等の物体が事故発生の可能性が高い時間帯に運転されていること、などとするとよい。
(4)上記(1)~(3)のいずれか1つのシステムにおいて、前記制御手段は、前記特定の条件として、ユーザから特定の情報を得ること、および、ユーザから特定の情報を得ることとは異なる他の条件が成立することにより前記所定以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るものとするとよい。
このようにすれば、例えば、ユーザから得た情報によって、異常事態の検証負荷をより確実に軽減すること等ができる。
「特定の情報」は、例えば、ユーザの特定の行為、ユーザの身体の特定の変化、などとするとよい。
(5)上記(1)~(4)のいずれか1つのシステムにおいて、前記制御手段は、ユーザに特定の行為を促す機能を有し、前記制御手段は、前記特定の条件として、前記特定の行為が行われたこと、および、前記特定の行為が行われたこととは異なる他の条件が成立したことを契機として前記所定の記録領域に画像を記録する機能を有するとよい。
これによれば、例えば、ユーザに対して特定の行為が促され、ユーザが特定の行為を実行すると、画像が記録される。よって、無駄な画像の記録がより一層抑制され、異常事態の検証負荷をより確実に軽減すること等ができる。
「特定の行為」としては、例えば、ユーザによる操作を受け付ける操作部材を操作することなどを挙げることができる。
「特定の行為を促す機能」としては、例えば、上記(2)~(4)のいずれか1つのシステムにおいて、複数の条件のうち1つの条件が成立した際に、ユーザに対して、操作部材の操作を、例えば、視覚的または聴覚的に促すことを挙げることができる。視覚的に促す機能としては、例えば、操作部材を光らせたり(例えば点滅するように光らせる等)、車両に設けられた表示装置に操作部材の操作を促す文言(例えば、「操作ボタンを押して下さい」、「操作ボタンを押しますか?」等の文言)を表示すること等を挙げることができる。聴覚的に促す機能としては、例えば、車両に設けられたスピーカを介して音声(例えば、「操作ボタンを押して下さい」、「操作ボタンを押しますか?」等の音声)で操作部材の操作を促すこと等を挙げることができる。その際、例えば、「○色(例えば赤色、黄色など)の操作ボタンを押して下さい」、「○色(例えば赤色、黄色など)のマルで囲まれているボタンを押して下さい」などの音声で操作部材の操作を促すとさらによい。
(6)上記(1)~(5)のいずれか1つのシステムにおいて、前記制御手段は、ユーザの身体の特定の変化を検知する機能を有し、前記制御手段は、前記特定の条件として、前記ユーザの身体の特定の変化が検知されたこと、および、前記ユーザの身体の特定の変化が検知されたこととは異なる他の条件が成立したことを契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、例えば、無駄な画像の記録がより一層抑制され、異常事態の検証負荷をより確実に軽減すること等ができる。事故等の異常事態が発生した際には、ユーザの身体の特定の変化が生じる可能性が高いことに着目したものであり、これを検出するとよい。
(7)上記(1)~(6)のいずれか1つのシステムにおいて、前記制御手段は、ユーザが所有するユーザ所有物と通信可能な通信機能を有し、前記制御手段は、前記特定の条件として、前記ユーザ所有物が特定の装置と通信すること、および、前記ユーザ所有物が前記特定の装置と通信することとは異なる他の条件が成立したことを契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、例えば、ユーザが携帯端末(例えばスマートフォン)等のユーザ所有物から特定の装置(例えば保険会社の電話機)に電話をした場合に、自動的に、画像(例えば異常事態の画像)を記録することができる。また、無駄な画像の記録がより一層抑制され、異常事態の検証負荷をより確実に軽減すること等ができる。
「ユーザ所有物」としては、例えば、ユーザ所有のスマートフォンや携帯電話、タブレット端末などを挙げることができる。そして、システムとユーザ所有物とは、例えば、Bluetooth(登録商標)によって予めペアリング等しておくことにより相互に通信可能な状態とすることができる。ユーザ所有物には、例えば、予め保険会社、警察署等の連絡先の電話番号(事故等の異常事態が発生した際に連絡する電話番号)を登録しておくとよい。システムは、ユーザ所有物の発信履歴を随時記録しておくとよい。
(8)上記(1)~(7)のいずれか1つのシステムにおいて、前記制御手段は、前記特定の条件として、前記所定以上の加速度の発生とは異なる単独の条件が成立することにより前記所定以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るものとするとよい。
これによれば、単独の条件の成立を契機として画像を記録することで、例えば、システムの部品点数を抑えつつ、異常事態の検証負荷を軽減することができる。
「単独の条件」は、例えば、車両に設けられた安全装置(例えばエアバッグ、アンチロック・ブレーキシステム、シートベルトのプリテンショナ装置など)の作動、車両に設けられた身体を保護する装置(例えばエアバッグ、シートベルトのプリテンショナ装置など)の作動、車両衝突時の車両の変化(例えば、車両の電位変化、車両の変形など)、ユーザの身体の特定の変化(例えば、ユーザの身体の異常、ユーザの姿勢の特定の変化)、運転ハンドルに取り付けられた所定のセンサが前記運転ハンドルから外れたこと、などを挙げることができる。ユーザの身体の異常としては、例えば、心拍の停止などとするとよい。
エアバッグの状態は、例えば、車両に搭載されたCAN(Controller Area Network)の通信内容を監視することで検知可能である。なお、CANの通信内容に基づき、例えば、エアバッグ展開、後突、エアバッグ系統異常、セーフィング、前突、側突などを検知可能である。また、エアバッグの状態は、エアバッグECUにアクセスすることにより検出してもよい。また、エアバッグの状態は、エアバッグの作動音の監視(例えば、100ms以下で150db~170dbといった大きな爆発音の監視)、エアバッグ作動に伴う空気圧の変化の監視、または、車両に搭載されたOBD(故障診断装置)、等によって検知するとよい。
上記「車両の電位変化」は、例えば、金属の車体は絶縁体であるタイヤの上にあるため常に帯電しており、何かの障害物に接触した際に車体の電位が変化することに着目したものであり、これを検出すると良い。
上記の「ユーザの心拍数が測定不能になったこと」は、事故が発生すれば心拍数を測定不能になることがある(死亡の場合等)ことに着目したものであり、これを検出すると良い。
(9)上記(1)~(8)のいずれか1つのシステムにおいて、前記制御手段は、安全手段の作動を契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、例えば、無駄な画像の記録がより一層抑制され、異常事態の検証負荷をさらに軽減することができる。
「安全手段」としては、例えば、エアバッグ、ABS(アンチロック・ブレーキシステム)、シートベルトのプリテンショナ装置等の安全装置や、ソフトウェアによって機能的に車両や身体の安全性を担保するものであってもよい。特に安全手段の作動は、安全手段そのものに(例えば上記エアバッグの)作動を検出する手段のいずれをも取り付けることなく行うようにするとよい。例えば、安全手段の作動を示す信号が出力される信号線に接続すること、または、画像を撮像する撮像手段によって撮像された映像を認識し、安全手段の動作を検出することで行うようにするとよい。
(10)上記(1)~(9)のいずれか1つのシステムにおいて、前記制御手段は、ユーザの身体を保護する手段の作動を契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、例えば、無駄な画像の記録がより一層抑制され、異常事態の検証負荷をさらに軽減することができる。異常事態が発生した際には、車両等の物体に設けられた身体を保護する手段が作動する可能性が高いことに着目したものであり、これを検出すると良い。
「身体を保護する手段」としては、例えば、エアバッグ、シートベルトのプリテンショナ装置や、ソフトウェアによって機能的に車両や身体の安全性を担保するものとするとよい。
(11)上記(1)~(10)のいずれか1つのシステムにおいて、前記制御手段は、当該システムが搭載された車両の電位の変化を契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、例えば、無駄な画像の記録がより一層抑制され、異常事態の検証負荷をさらに軽減することができる。異常事態が発生した際には、車両(例えば車体の金属部分)の電位変化が生じる可能性が高いからである。
(12)上記(1)~(11)のいずれか1つのシステムにおいて、前記制御手段は、特定の音の発生を契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、例えば、無駄な画像の記録がより一層抑制され、異常事態の検証負荷をさらに軽減することができる。異常事態が発生した際には、特定の音が生じる可能性が高いからである。
「特定の音」としては、例えば、車両の衝突音、人の悲鳴、緊急自動車のサイレン音、急ブレーキの音、などを挙げることができる。
(13)上記(1)~(12)のいずれか1つのシステムにおいて、ユーザによる操作を受け付ける操作部材を備え、前記制御手段は、前記特定の条件としてユーザによる前記操作部材の操作を契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、例えば、比較的簡単な構成で、異常事態の検証負荷をさらに軽減することができる。ユーザによる操作部材の操作を契機として画像を記録することで、ユーザの意思が反映されるからである。
「操作部材」としては、例えば、押しボタン、スイッチ、操作レバーなどを挙げることができる。
(14)上記(1)~(13)のいずれか1つのシステムにおいて、ユーザによる操作を受け付け可能な操作部材として、特定の大きさを有する操作部材を備え、前記制御手段は、前記操作部材の操作を契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、操作部材の操作が容易となる。例えば、異常事態発生時に焦っているときでも容易に操作することが可能となる。
「操作部材」の特定の大きさとしては、例えば、とっさに手を伸ばしたときに的確に操作を行える大きさとするとよい。
(15)上記(1)~(14)のいずれか1つのシステムにおいて、ユーザによる操作を受け付け可能な操作部材として、特定の位置に設けられる操作部材を備え、前記制御手段は、前記操作部材の操作を契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、操作部材の操作が容易となる。例えば、異常事態発生時に焦っているときでも容易に操作することが可能となる。
「操作部材」の特定の位置としては、例えば、とっさに手を伸ばしたときに的確に操作を行える位置とすることができる。
(16)上記(1)~(15)のいずれか1つのシステムにおいて、ユーザによる操作を受け付け可能な操作部材として、単一の操作部材を備え、前記制御手段は、前記単一の操作部材の操作を契機として前記所定の記録領域に画像を記録する機能を有するとよい。
このようにすれば、操作部材の操作が容易となる。例えば、異常事態発生時に焦っているときでも容易に操作することが可能となる。操作可能な部材が複数個設けられている場合には、ユーザはとっさのときにいずれの操作部材を操作すればよいか迷う可能性があるが、操作部材が、ユーザが操作可能な操作部材として単一の操作部材として設けられることで、迷うことなく操作部材を操作することができる。
(17)上記(1)~(16)のいずれか1つのシステムにおいて、ユーザによる操作を受け付け可能な操作部材として、制御手段により誤操作を判別することが可能な操作部材を備えるとよい。
このようにすれば、操作部材の誤操作がなされた場合に、例えば操作をキャンセルすることが可能となる。この場合、例えば、誤操作と判定された場合に、制御手段が自動的に操作をキャンセルするようにしてもよいし、制御手段がユーザに誤操作であったのかどうかを確認するようにしてもよい。
「誤操作」としては、例えば、誤った操作、いたずらによる操作を挙げることができる。
(18)上記(1)~(17)のいずれか1つのシステムにおいて、前記制御手段は、前記特定の条件として、外部から特定の情報を受けたことを契機として前記所定の記録領域に画像を記録する機能を有するとよい。
これによれば、例えば、外部から受けた特定の情報を契機として記録した画像が事故等の異常事態の画像であるのか否かの検証負荷をさらに軽減することができる。また、他の車両の事故を記録して、当該他の車両の事故の検証に役立てることができる。
「特定の情報」としては、例えば、他の車両等の物体の異常状態(例えば事故)の情報、パトカーや救急車などの緊急自動車が近くで停車したこと、などを挙げることができる。他の車両等の物体の異常事態の情報としては、例えば、他の車両等の物体の事故の発生場所や発生時刻などの情報を挙げることができる。他の車両等の物体の事故の情報は、例えば車両等の物体の外部のサーバ(例えば、保険会社や警察署のサーバ等)から送信されたものである。また、パトカーや救急車などの緊急自動車が近くで停車したことは、例えば、本システムを搭載する車両等の物体に設けられたマイクでパトカー等のサイレンの音を集音してその音を分析することにより認識するとよい。
また、「特定の情報」としては、例えば、本システムが搭載された車両とは異なる他の車両についての外部装置(例えばサーバ)からの問合せ情報を挙げることができる。「問い合わせ情報」としては、例えば、保険会社や警察署からの上記他の車両についての事故の情報(例えば、位置情報、時間情報など)を挙げることができる。この場合、例えば、制御手段は、所定の記録領域に既に常時録画されている画像の中から、問い合わせされた事故の情報に対応する事故の映像を検索し、検索によって発見された事故の映像を記録(イベント記録)してもよい。また、記録した情報を外部装置へ送信するとよい。
(19)上記(1)~(18)のいずれか1つのシステムにおいて、前記所定の記録領域に記録された画像を外部へ送信する送信手段を備えるとよい。
このようにすれば、画像を外部に送信することで、例えばメモリカードを持ち運ぶなどの手間が軽減される。
(20)上記(1)~(19)のいずれか1つのシステムにおいて、前記制御手段は、前記所定の記録領域に記録された画像を異常事態が映っている可能性でランク付けする機能を有するとよい。
このようにすれば、画像を異常事態が映っている可能性でランク付けすることで、無駄な画像の記録がより一層抑制され、異常事態の検証負荷をさらに軽減することができる。
例えば、異常事態が映っている可能性に関する画像のランクが所定のランクより高い場合に、その画像を保険会社のサーバ等に送信するようにしてもよい。このような、異常事態の検証負荷をさらに軽減することができるランクを、対応する画像とともに、または、対応する画像に埋め込んで、記録するようにするとよい。
(21)上記(1)~(20)のいずれか1つのシステムにおいて、前記制御手段は、異常事態が生じている可能性のある車両の情報を画像に記載する機能を有するとよい。
このようにすれば、異常事態の画像を容易に確認し、異常事態が生じた車両を容易に特定することができる。
「異常事態が生じている可能性のある車両」としては、例えば、本システムが搭載されている車両、本システムが搭載されている車両とは異なる他の車両を挙げることができる。
「異常事態が生じている可能性のある車両の情報」としては、例えば、車両ナンバー、車検証番号、車両の所有者の氏名等を挙げることができる。
「異常事態が生じている可能性のある車両の情報」は、例えばテロップのように画像に記載するとよい。
(22)上記(1)~(21)のいずれか1つのシステムにおいて、前記制御手段は、前記画像に異常事態が映っている確率を示す確率情報を前記画像に記載する機能を有するとよい。
このようにすれば、画像に異常事態が映っている確率を示す確率情報を参考にして、異常事態の画像か否かを容易に判定することができ、これにより、異常事態の検証負荷をさらに軽減することができる。
「異常事態が映っている確率を示す確率情報」は、例えばテロップのように画像に記載するとよい。
(23)上記(1)~(22)のいずれか1つのシステムにおいて、前記制御手段は、前記画像を静止画像の状態で記録する機能を有するとよい。
このようにすれば、異常事態の検証負荷をさらに軽減することができる。例えば、動画像であれば、早送りしたとしても比較的確認作業に時間がかかってしまうかもしれないが、静止画像であれば、複数の静止画像を同時に確認することが可能であるため、効率よく確認作業を行うことが可能となる。
(24)上記(1)~(23)のいずれか1つのシステムにおいて、前記制御手段は、前記システムの性能を複数のレベルで切り替える機能を有するとよい。
このようにすれば、例えば、個人向けの性能設定が可能な個人用モードと、業務用の性能設定が可能な業務用モードとの間で、システムの性能を切り替えることができる。したがって、システムのユーザが誰なのかに応じて、システムの性能を任意に設定することができる。例えば、個人向けの性能としては、平均的な(ミディアムな)性能に設定してもよい。また、法人向けの性能としては、映像の画質などを高画質に設定したり、外部への画像送信をLTE(Long Term Evolution)(登録商標)で行うようにしてもよい。
(25)上記(1)~(24)のいずれか1つのシステムにおいて、前記制御手段は、レベルを業種別に設定する機能を有するとよい。
このようにすれば、例えば、ユーザが警備会社である場合には、例えば映像の画質などを最高画質に設定(最高設定)したり、外部への画像送信をLTE(Long Term Evolution)(登録商標)で行うことができる。
(26)コンピュータに、(1)~(25)のいずれか1つのシステムとしての機能を実現させることを特徴とするプログラムとするとよい。
このようにすれば、プログラムを格納したコンピュータをシステムに搭載することで、上記のシステムを実現することができる。
上述した(1)から(26)に示した発明は、任意に組み合わせることができる。例えば、(1)に示した発明の全てまたは一部の構成に、(2)以降の少なくとも1つの発明の少なくとも一部の構成を加える構成としてもよい。特に、(1)に示した発明に、(2)以降の少なくとも1つの発明の少なくとも一部の構成を加えた発明とするとよい。また、(1)から(26)に示した発明から任意の構成を抽出し、抽出された構成を組み合わせてもよい。本願の出願人は、これらの構成を含む発明について権利を取得する意思を有する。また「~の場合」「~のとき」という記載があったとしてもその場合やそのときに限られる構成として記載はしているものではない。これらの場合やときでない構成についても開示しているものであり、権利取得する意思を有する。また順番を伴った記載になっている箇所もこの順番に限らない。一部の箇所を削除したり、順番を入れ替えた構成についても開示しているものであり、権利取得する意思を有する。
本発明によれば、例えば、異常事態の検証負荷を軽減すること等を可能ならしめるシステム等を提供することができる。
本願の発明の効果はこれに限定されず、本明細書および図面等に開示される構成の部分から奏する効果についても開示されており、当該効果を奏する構成についても分割出願・補正等により権利取得する意思を有する。例えば本明細書において「~できる」「~可能である」などと記載した箇所などは奏する効果を明示する記載であり、また「~できる」「~可能である」などといった記載がなくとも効果を示す部分が存在する。またこのような記載がなくとも当該構成よって把握される効果が存在する。
[システムの構成]
図1および図2を参照して、システムの構成の一例について説明する。「システム」は、車両以外の物体に搭載されるシステムであってもよい。車両以外の物体の例では、例えば、船舶や飛行機などに搭載されるシステムであってもよいが、特に車両に搭載されるシステムとするとよい。また、「システム」は、交通事故の瞬間などの画像を記録する、いわゆるドライブレコーダとするとよい。車両としては、例えば、運送用の車両(例えば、トラックやフォークリフト等)、営業用の車両(例えば、タクシーやバス等)および一般の車両等の車両全般のみならず、さらなる多用途に展開してもよい。本実施の形態では、車両に搭載可能なドライブレコーダについて説明する。
図1Aは、システム(ドライブレコーダ)を斜め後方から見た斜視図の一例である。図1Aに示すように、システム100の筐体の1つの側面に、SDカード挿入口114が設けられている。筐体の背面に、ディスプレイ113、および複数の操作部材(図1Aに示される例では、複数の操作ボタン112,115)が設けられている。筐体の上面にジョイントレール111が設けられている。図1Aには現れていないが、筐体の前面に撮像手段であるカメラのレンズが設けられている。図1Aに現れていない方の側面にDCジャックが設けられており、底面にスピーカおよびHD出力端子が設けられている。
レンズを含むカメラ(撮像手段)は、例えば車両の前方の画像を撮像する。DCジャックは、電源ケーブルを介してDC電源に接続するためのジャックである。SDカード挿入口114はSDカードを挿入するための挿入口である。スピーカは、音声等の音を出力する。HD出力端子は、ケーブルを介して他の情報機器に接続するための端子である。ジョイントレール111は、システム100を車両に搭載するためのジョイント部材を取り付けるためのものである。ディスプレイ113は種々の画像を表示する。操作ボタン112,115は、ユーザが操作することによってシステム100に種々の指令を入力するためのものである。
なお、この明細書において、ユーザとは、例えばシステムが搭載された車両等の運転者でもよいし、運転者とは異なる者、例えば同乗者であってもよい。
図1Bは、車両に搭載された状態のシステム100、フロントガラス122、ダッシュボード126等の一例を示す図である。図1Aに示される例では、システム100は、車両のフロントガラス122の上部であって左右方向中央付近のルームミラー121に隣接する助手席側の位置に配置されている。システム100は、両面テープ等の取り付け部材によりフロントガラス122に貼りつけて固定されている。システム100のDCジャックが電源ケーブル120を介してシガーソケット123に接続されている。車両等のアクセサリ電源がONにされると、例えばシガーソケット123からシステム100に電力が供給される。したがって、車両等のエンジンが切れているとき、シガーソケット123からはシステム100に電力が供給されない。
なお、図1Aに示されるように、システム100の一部の部材が、この部材の用途に応じて、フロントガラス122とは異なる位置に設けられていてもよい。図1Aに示される例では、例えば、操作部材の一つである操作ボタン124等がダッシュボード126に設けられている。
図2は、システム100のブロック図の一例である。システム100は、コントローラ130(制御手段の一例である)、カメラ141(撮像装置の一例である)、データベース145、GPS受信機140、SDカードリーダ142(記録手段の一例である)、加速度センサ144、加速度センサ144とは異なる種類の各種センサ150、スピーカ146、ディスプレイ113、操作ボタン112,115,124(図1B参照)、および通信回路149を備えている。なお、SDカードリーダ142は、読み書き機能を備えるものであり、厳密には「SDカードリーダライタ」と称するべきであるが、本明細書において、単に「SDカードリーダ」と称する。
スピーカ146およびディスプレイ113は、ユーザに種々の情報を知らせるための通知手段として機能する。スピーカ146は、コントローラ130の制御に基づいて、警報や種々の情報を音で出力する。ディスプレイ113は、コントローラ130の制御に基づいて、種々の情報を画像表示で出力する。操作ボタン112,115,124は、ユーザがシステム100(より具体的にはコントローラ130)に対して種々の指令を与える入力手段として機能する。
カメラ141は、画角内(視野内)の動画を撮像する撮像装置として機能する。カメラ141で撮像された動画は、画像データとしてコントローラ130に取り込まれる。カメラ141は、少なくとも車両前方を撮像できるものである。カメラ141は、全方位360°を撮像できる360°カメラであるとよく、全天球カメラ、半球カメラのいずれであってもよい。360°カメラであれば車両の周囲全方向を撮像できるとともに、車内の様子も撮像することができる。なお、カメラ141の数は1台であってもよいし、2台以上であってもよい。カメラ141は、車両の周囲の状況の他、車内のユーザ(運転者、同乗者)の様子も撮像できるとよい。
データベース145は、例えばコントローラ130に外付けした不揮発性メモリ(例えばEEPROM)に格納されている。データベース145には、例えば地図データが含まれる。
GPS受信機140は、コントローラ130の指示に基づいて現在時刻における自車の位置情報を検出する。位置情報は、GPS衛星からの信号に基づいて求められた時刻、自車の速度、経度、緯度、高度等を含む。コントローラ130は、これらの位置情報の履歴を記録する処理を行う。
SDカードリーダ142は、SDカード143を保持する媒体収容部として機能する。SDカード143は、着脱可能な記憶媒体として機能する。ユーザは、SDカード挿入口114(図1A参照)を通して、SDカードリーダ142にSDカード143を装着することができる。SDカードリーダ142は、コントローラ130からの制御に基づいて、SDカードリーダ142に保持されているSDカード143のデータを読み取り、またはSDカード143にデータを記憶させる。
加速度センサ144は、3軸(x軸、y軸、z軸)それぞれの方向の加速度および傾きを検出する3軸タイプのセンサが用いられる。加速度センサ144による計測値は、常時、コントローラ130に取り込まれる。コントローラ130は、例えば10msごとに3軸の加速度情報を取得する。
コントローラ130は、周知のCPU131、ROM132およびRAM133等のメモリ、タイマ134、その他の周辺回路等を有する。コントローラ130のROM132内に各種プログラムが記憶されている。コントローラ130はこれらのプログラムを実行することにより各種の機能を実現する。各種プログラムには、オペレーティングシステム(OS)、GPS情報処理プログラム、映像処理プログラム(例えば図3~図14に示されるフローチャート等)、通信処理プログラム等が含まれる。
コントローラ130はGPS情報処理プログラムを実行することにより、GPS受信機140で受信されたGPS情報を、SDカードリーダ142に保持されたSDカード143に保存することができる。コントローラ130は映像処理プログラムを実行することにより、カメラ141が撮像した映像を時刻と関連付けてSDカード143の所定の記録領域に記録することができる。コントローラ130は、SDカードリーダ142に保持されたSDカード143にアクセスする機能を持ち、SDカードリーダ142に保持されたSDカード143に、カメラ141で撮像された映像を記録する機能を持つ制御手段として機能する。
ディスプレイ113は、コントローラ130がアクセスするSDカード143の担う役割をユーザに知らせる通知手段として機能する。
通信回路149は、外部機器、例えばサーバ(例えば保険会社等のサーバ)、パソコン、スマートフォン、タブレット端末等と無線通信を行うための通信手段として機能する。コントローラ130は、通信処理プログラムを実行することにより、通信回路149を介して、外部機器に映像等の画像データを送信する機能を有する。通信回路149として、例えばWiFi規格、Bluetooth等の近距離無線通信の規格、LTE(Long Term Evolution)(いずれも登録商標)、4G等の移動通信システムの規格等に準拠した通信回路を用いるとよい。近距離無線通信の規格は、例えば構内で稼働する作業車両(フォークリフト等)と外部機器との通信に適用することができる。移動通信システムの規格は、例えば、より広範囲の領域内で移動する車両と外部機器との通信に適用することができる。
コントローラ130は、カメラ141から入力された画像データに基づいてSDカードリーダ142に保持されたSDカード143に画像の記録を行うことにより、上述した映像処理プログラムを実行する。より詳しくは、SDカード143は少なくとも2つの記録領域(第1の記録領域および第2の記録領域)に分けられており、第1の記録領域には、車両から給電を受けている限り常時記録される画像データ(以下「常時記録画像データ」と称する)が圧縮して記録される。また、第2の記録領域には、車両から給電を受けている時に特定の条件が成立したことを契機として記録される画像データ(以下「イベント記録画像データ」と称する)が記録される。なお、詳細は後述するが、コントローラ130は、常時記録画像データを記録する処理(後述の常時記録処理)と、イベント記録画像データを記録する処理(後述のイベント記録処理)とをマルチタスク処理として実行する。
なお、上述したとおり、このシステム100は、車両等のアクセサリ電源(以下「外部電源」と称する)がONにされると例えばシガーソケット123から電力が供給されない。そのため、このシステム100は、外部電源がONのときには充電され、外部電源がOFFのときにはコントローラ130および加速度センサ144にのみ電力を供給する機能を有する内蔵バッテリーを備える盗難防止付きのシステムとするとよい。この場合、コントローラ130は、盗難記録モードにおいて、加速度センサ144によって強い衝撃を検知すると、コントローラ130および加速度センサ144以外の他の部材(例えば、カメラ141、SDカードリーダ142、ディスプレイ113等)にも内蔵バッテリーから電力を供給し、例えば1分程度といった盗難等の不正行為を撮像するために必要な時間にわたって撮像し、この撮像データを記録する処理を実行する。そして、外部電源がONになると盗難防止モードを終了し、後述の図3~図14に示される処理を実行する。
なお、例えば常時記録画像データやイベント記録画像データの画像は、静止画像が連続する画像であってもよいし、動画像であってもよい。静止画像の場合、複数の静止画像を同時に確認することが可能であるため、効率よく確認作業を行うことが可能である。また、動画像は、例えば、一定時間間隔で撮影された一連の画像を、短い間隔で連続表示することによって得られる動きのある映像であってもよいし、完全に連続した映像であってもよい。
また、静止画像および動画像には、車両のデータ(例えば車検証番号、車台番号、所有者の氏名等)を付しておくとよい。また、操作ボタン124は単一のボタンとし、操作ボタン124以外のボタンを設けないようにするとよい。ユーザが操作可能な操作ボタンとして単一の操作ボタン124が設けられることで、交通事故等の緊急時に迷うことなく操作ボタン124を操作することができる。
次に、システムが備えるコントローラ130の制御処理について説明する。このコントローラ130により実行される制御処理については、第1の実施例、第2の実施例および第3の実施例に分けて説明する。なお、図1および図2に示されるシステムの構成については、第1の実施例、第2の実施例および第3の実施例で共通するため、以下では、コントローラ130により実行される制御処理についてのみ説明する。
第1の実施例は、例えば事故等の異常事態が自車両(システムが搭載された車両)等に発生した可能性があるときにイベント記録画像データを記録するイベント記録処理を、複数の条件が成立したときに行う場合の例であって、所定値以上の加速度の発生といった単独の条件が成立したときにイベント記録処理を行う場合と比べて、イベント記録処理を行う頻度が低くなりうる例である。
なお、この明細書(第1の実施例のみならず後述する第2の実施例および第3の実施例も含む)において、「所定値以上の加速度の発生」とは、例えば、車両等が通常に走行しているときに発生する加速度の範囲を超えたときが相当する。例えば車両等が通常に走行しているときの加速度は、多少の上下幅があるものの正常の範囲内で上下していることが多い。しかし、例えば車両等が段差に乗り上げた時や急ブレーキ時には、加速度が一時的に(例えば一瞬)上昇することがある。このような場合に、所定値以上の加速度が発生したと判断されうる。
第2の実施例は、例えば事故等の異常事態が自車両(システムが搭載された車両)等に発生した可能性があるときにイベント記録画像データを記録するイベント記録処理を、所定値以上の加速度の発生とは異なる単独の条件が成立したときに行う場合の例であって、所定値以上の加速度の発生といった単独の条件が成立したときにイベント記録処理を行う場合と比べて、イベント記録処理を行う頻度が低くなりうる例である。
第3の実施例は、例えば事故等の異常事態が他車両(システムが搭載された車両とは別の車両)等に発生した可能性があるときにイベント記録画像データを記録するイベント記録処理を行う場合の例である。
[第1の実施例]
先ず、図3を参照して、コントローラ130が実行する制御処理の第1の実施例について説明する。図3は、システム100のコントローラ130が実行する制御処理の第1の実施例を説明するためのフローチャートである。
コントローラ130は、外部電源がONであるか否かを判断し(ステップS101)、外部電源がONである場合(ステップS101のYES)に、ステップS103~ステップS109の処理を行う。なお、図3では示さないが、システム100に電力が供給されて外部電源がONになると、コントローラ130は、カメラ141から入力された画像データ(常時記録画像データ)をSDカード143の第1の記録領域に常に記録する常時記録処理を行う。この常時記録処理は、システム100に電力が供給されている限り記録し続ける処理であり、例えばステップS103~ステップS109等の処理と併行して行われる。
ステップS101において、システム100への電力の供給が開始されて外部電源がONになると(YESの場合)、コントローラ130は、加速度センサ144の検出値に基づいて、車両に所定値以上の加速度が発生したか否かを判断する(ステップS103)。
具体的には、コントローラ130は、所定値以上の加速度が発生した後(ステップS103のYES)、所定時間が経過するまで(ステップS105)、ユーザが特定の行為を行ったか否かを監視している(ステップS107)。ユーザが特定の行為を行ったか否かの監視は、例えば、ユーザが操作ボタン124を操作したか否かの監視とするとよい。操作ボタン124を操作するとシステムが画像データを記録することをユーザに周知しておけば、ユーザが操作ボタン124を操作したときにイベントが発生していることの信頼性が高くなる。
コントローラ130は、所定値以上の加速度が発生した後の所定時間内(ステップS105のYES)に、ユーザが特定の行為として例えばユーザが操作ボタン124を操作したと判断すると(ステップS107のYES)、イベント記録処理を行う(ステップS109)。このイベント記録処理は、例えば、SDカード143の第1の記録領域に記録される常時記録画像データを読み出して、所定値以上の加速度が発生したと判断された時点前後それぞれ所定時間(例えば前後20秒ずつ)の画像データを切り出して、イベント記録画像データとしてSDカード143の第2の記録領域に記録する処理等である。この場合、ステップS105で判断される所定時間(ユーザが操作ボタン124を操作したか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば20分以内といった、ユーザが操作ボタン124を操作するまである程度の時間を確保できる程度とするとよい。事故等の異常状態が発生したとき、ユーザは動揺すると考えられ、精神的に落ちつかなければ操作ボタン124を操作することに気付かない可能性があると考えられるからである。
また、コントローラ130は、所定値以上の加速度が発生していないとき(ステップS103のNO)は、ステップS101に戻る。また、コントローラ130は、所定値以上の加速度が発生したとしても、ユーザが特定の行為を行ったことを検知することなく、所定値以上の加速度の発生から所定時間を経過すると(ステップS105のNO)、ステップS101に戻る。
このようにすれば、所定値以上の加速度の発生の検知、および、ユーザが特定の行為を行ったことの検知、といった複数の条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、複数の条件のうち個々の条件が成立するタイミングが、或る程度近しいタイミング(上述のステップS105で説明した所定時間以内)でなされているので、複数の条件の関連性の高さが確保される。したがって、異常事態の検証負荷をより確実に軽減すること等が可能となる。
なお、ステップS107の処理を、例えばユーザが操作ボタン124を操作したことを検知する処理とした場合、操作ボタン124の操作を促す機能がシステムに設けられていることが好ましい。例えば、所定値以上の加速度の発生が検知された際に、「緊急時には操作ボタンを押してください。」等の音声によるアナウンスをスピーカから出力したり、表示装置にその旨の表示を行ったり、操作ボタン24を点灯や点滅させたり、またはこれらを組み合わせて行うようにするとよい。また、操作ボタン24は、目立つ態様でシステムに設けられていることが好ましい。例えば、操作ボタン24をダッシュボードの上に配置したり、操作ボタン24を運転席や助手席に座っている人から見やすい位置に配置したりするとよい。また、操作ボタン24を目立つ色(例えば、赤色、黄色、青色など)の操作ボタンとするとよい。また、操作ボタン24は、目立つように大きめの大きさ(非常ボタンのイメージで、例えば手の甲の大きさ程度)とするとよい。さらに、操作ボタンの数が多いと、ユーザが操作するときにいずれの操作ボタンを操作すればよいかユーザが迷う可能性があるため、操作ボタン24は、1つだけ設けられるようにするとよい。
また、操作ボタン24は、自車両や他車両に事故等の異常事態が発生したときの他、運転者、同乗者の身体に不具合が生じたときや、火災、冠水、隕石落下など、何らかの異常事態が発生したときに操作すると、システムから外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社、事故サポートセンターなど)や外部の特定の車両(例えば救急車やパトカー等)に対して通信が行われ、この通信によって相手側に異常事態の発生を報知する機能を有するとよい。
また、ステップS107の処理は、ユーザが操作ボタン124を操作したことを検知する処理に限られず、例えば、ユーザが所有する特定の装置(例えばスマートフォンやタブレットなど)から外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社、事故サポートセンターなど)に通信をしたことを検知する処理としてもよい。この場合、ステップS105で判断される所定時間(ユーザが所有する特定の装置から外部の特定の機関に通信を行ったか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば60分以内といった、ユーザが操作ボタン124を操作するまである程度の時間を確保できる程度とするとよい。事故等の異常状態が発生したとき、ユーザが事故の相手方と交渉する場合があることに鑑みると、相手方との交渉が落ち着いた後に外部の特定の機関と通信する可能性があると考えられるからである。
また、システムは、上記特定の機関への通信を行うことをユーザに促したり、或いは、上記特定の機関への通信を行うか否かをユーザに確認するようにしてもよい。例えば、事故への対応をサポートするサービスを行う事故サポートセンターへの通信(連絡)を行うか否かを、対話型UI(ユーザインターフェイス)によってシステムがユーザに確認してもよい。
具体的には、例えば、所定値以上の加速度が発生した後(ステップS103のYES)、所定時間が経過するまで(ステップS105)の間に、システムがユーザに対して、「事故サポートセンターへ通知しますか?」等の音声で確認を行ってもよい。この場合、システムは、ユーザによる「する/しない」等の返答を音声によって認識し、「する」という返答があった場合に、システムが事故サポートセンターへ連絡を行うようにするとよい。この連絡を行う際、念のために、システムは、ユーザとの音声会話を録音して、上記の連絡を行うとともに録音内容をボイスメッセージとして事故サポートセンターに送るようにするとよい。
また、例えば、所定値以上の加速度が発生した後(ステップS103のYES)、所定時間が経過するまで(ステップS105)の間に、システムがユーザに対して、「事故サポートセンターへ通知しますか?通知する場合は本体の通知ボタンを押してください。」等の音声で確認を行ってもよい。この場合、システムは、ユーザによる通知ボタンの操作があった場合に、システムが事故サポートセンターへ連絡を行うようにするとよい。
対話型UIによるシステムの音声ボリュームを調整する機能や、音声をオン、オフする機能を設けるとよい。これらの機能を設けることで、所定値以上の加速度が発生する(ステップS103のYES)度に音声が流れることを抑制したり、音声ボリュームを抑えることができる。
ステップS107の処理を、ユーザが所有する特定の装置(例えばスマートフォンやタブレットなど)から外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に通信をしたことを検知する処理とした場合、特定の機関の電話番号等をシステムに登録しておくとよい。また、システムとユーザが所有する特定の装置とは、例えば、Bluetooth(登録商標)によって予めペアリング等しておくことにより相互に通信可能な状態としておくとよい。また、ユーザが所有する特定の装置から外部の特定の機関に通信を行ったときの履歴(例えば日時や通信したときの会話の内容)を記録するようにするとなおよい。また、ユーザが所有する特定の装置の発信履歴を随時読み込んでおいて、特定の機関(保険会社等)へ連絡した時点に対して直近の加速度発生イベント(ステップS103のYES)について、イベント記録処理を行う(ステップS109)とよい。
[第1の実施例の効果等]
第1の実施例によれば、複数の条件(所定値以上の加速度の発生の検知およびユーザの特定の行為が行われたことの検知)が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得る。そのため、イベント記録処理(ステップS109)においてSDカード143に記録された画像データを、外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に提供することで、異常事態の検証負荷をより確実に軽減すること等が可能となる。
[第1の実施例の変形例1~変形例5]
次に、図4~図8を参照して、第1の実施例の変形例1~変形例5について説明する。第1の実施例の変形例1~変形例5が第1の実施例と異なる点は、図3に示されるシステム100のコントローラ130が実行する処理のうちの一部の処理である。
[第1の実施例の変形例1]
先ず、図4を参照して、第1の実施例の変形例1について説明する。図4は、システム100のコントローラ130が実行する制御処理の第1の実施例の変形例1を説明するためのフローチャートである。
第1の実施例の変形例1では、第1の実施例におけるS107の判断(ユーザが特定の行為を行ったか否かの判断)に代えて又は加えて、所定値以上の加速度が発生した後の所定時間以内(ステップS115のYES)に、ユーザから特定の情報を検知したか否かを判断する(ステップS117)。すなわち、所定値以上の加速度が発生したこと(ステップS113のYES)および所定値以上の加速度が発生した後の所定の時間内(ステップS115のYES)にユーザから特定の情報を検知した(ステップS117のYES)といった複数の条件を満たすと、イベント記録処理を行う(ステップS119)。なお、他の処理であるステップS111、S113およびS119の処理は、それぞれ、第1の実施例におけるステップS101、S103およびS109の処理と同様である。
具体的には、コントローラ130は、所定値以上の加速度が発生した後(ステップS113のYES)、所定時間が経過するまで(ステップS115)、ユーザから特定の情報を検知したか否かを監視している(ステップS117)。ユーザから特定の情報を検知したか否かの監視は、例えば、ユーザが大きな声(例えば所定のデシベル値以上の声)を発したか否かの監視とするとよい。これは事故等の異常状態が発生したとき、ユーザが大きな声を発する可能性が高いことに着目したものであり、通常時には検知される可能性が低いデジベル値の範囲を超えたとき(例えば通常時に検知される可能性がある最大デシベル値の例えば2倍以上のデシベル値が検知されたとき)、ユーザが大きな声を発したと判断される。この場合、ステップS115で判断される所定時間(ユーザが大きな声を発したか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば3秒以内といった比較的短い時間とするとよい。事故等の異常状態が発生したとき、比較的短い時間内にユーザが大きな声を発すると考えられるからである。
コントローラ130は、所定値以上の加速度が発生した後の所定時間内(ステップS115のYES)に、ユーザからの特定の情報として例えばユーザが大きな声を発したと判断すると(ステップS117のYES)、イベント記録処理を行う(ステップS119)。
また、コントローラ130は、所定値以上の加速度が発生していないとき(ステップS113のNO)は、ステップS111に戻る。また、コントローラ130は、所定値以上の加速度が発生したとしても、ユーザから特定の情報を検知することなく、所定値以上の加速度の発生から所定時間を経過すると(ステップS115のNO)は、ステップS111に戻る。
このようにすれば、所定値以上の加速度の発生の検知、および、ユーザからの特定の情報の検知、といった複数の条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、複数の条件のうち個々の条件が成立するタイミングが、或る程度近しいタイミング(上述のステップS115で説明した所定時間以内)でなされているので、複数の条件の関連性の高さが確保される。したがって、異常事態の検証負荷をより確実に軽減すること等が可能となる。
なお、ステップS117の処理は、ユーザが大きな声(例えば所定のデシベル値以上の声)を発したか否かを監視する処理に限られず、例えば、ユーザの身体に変化が生じたか否かを監視するようにしてもよい。ユーザの身体に変化が生じたか否かの監視は、システムが搭載される車両等の例えばハンドルにユーザの血流を測定できるセンサを設けてユーザの心拍数を検出し、検出された心拍数が所定の範囲外(例えば心拍数100以上、或いは測定不能)といった、例えば通常時に検出される心拍数の範囲を超えたことを検知したときに、ユーザの身体に変化が生じたと判断する処理としてもよい。この場合、通常時からユーザの心拍数を検知し、この検知結果にもとづいて例えば通常時に検出される心拍数の範囲を設定するようにするとよい。また、システムが搭載される例えば車両の車内等を撮像するカメラを備えて、このカメラが撮像するユーザの身体の状態が通常の運転時とは異なる状態になったこと(例えば、ユーザの頭の位置が所定の領域から所定時間(例えば5分以上といった、異常事態が発生していなければユーザの頭の位置が所定の領域に戻ると考えられる時間)以上にわたって逸脱していることなど)を検知する処理としてもよい。この場合、ステップS115で判断される所定時間(ユーザの身体に変化が生じたか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば電源がOFFになるまで(ステップS111においてNOと判断されるまで)の時間とするとよい。事故等の異常事態の発生直後は身体に影響がなかったとしても、ある程度の時間が経過した後に身体に影響が出てくる場合があるからである。
さらに、コントローラ130は、所定値以上の加速度が発生したことを検知してから例えば電源がOFFになるまでユーザの身体に変化が生じたか否かを監視するようにした場合、ユーザの身体異常を検知すると外部機関(例えば保険会社のサーバや警察署等)に自動送信するようにすると、事故を未然に防ぐことができる可能性もあり、なおよい。
[第1の実施例の変形例1の効果等]
第1の実施例の変形例1によれば、複数の条件(所定値以上の加速度の発生の検知およびユーザから特定の情報を取得したことの検知)が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得る。そのため、イベント記録処理(ステップS119)においてSDカード143に記録された画像データを、外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に提供することで、異常事態の検証負荷をより確実に軽減すること等が可能となる。
[第1の実施例の変形例2]
次に、図5を参照して、第1の実施例の変形例2について説明する。図5は、システム100のコントローラ130が実行する制御処理の第1の実施例の変形例2を説明するためのフローチャートである。
第1の実施例の変形例2では、第1の実施例におけるS107の判断(ユーザが特定の行為を行ったか否かの判断)に代えて又は加えて、所定値以上の加速度が発生した後の所定の時間内(ステップS125のYES)に、車両外部から特定の情報を検知したか否かを判断する(ステップS127)。すなわち、所定値以上の加速度が発生したこと(ステップS123のYES)および所定値以上の加速度が発生した後の所定の時間内に車両外部から特定の情報を検知したことといった複数の条件を満たすと、イベント記録処理を行う(ステップS129)。なお、他の処理であるステップS121、S123およびS129の処理は、それぞれ、第1の実施例におけるステップS101、S103およびS109の処理と同様である。
具体的には、コントローラ130は、所定値以上の加速度が発生した後(ステップS123のYES)、所定時間が経過するまで、車両外部からの特定の情報として、特定の音(例えば、特定の車両(例えば救急車やパトカー等の緊急自動車)のサイレンの音、通行人の大きな声、車両の衝突音など)を検知したか否かを監視しており(ステップS125、ステップS127)、所定値以上の加速度が発生した後の所定時間内(ステップS125のYES)に特定の音が検知されたと判断すると(ステップS127のYES)、イベント記録処理を行う(ステップS129)。この場合、ステップS125で判断される所定時間(特定の音を検知したか否かの監視時間)は、特定の音が例えば特定の車両のサイレンの音等であれば、所定値以上の加速度が発生したことを検知してから例えば40分以内といった、事故等の異常状態が発生してから特定の車両が到着するまでの時間を考慮した時間とするとよい。また、特定の音が例えば通行人の大きな声や車両の衝突音等であれば、所定値以上の加速度が発生したことを検知してから例えば3秒以内といった比較的短い時間とするとよい。
また、コントローラ130は、所定値以上の加速度が発生していないとき(ステップS123のNO)は、ステップS121に戻る。また、コントローラ130は、所定値以上の加速度が発生したとしてもその後の所定時間内に特定の音が検知されないとき(ステップS127のNO)は、ステップS121に戻る。
このようにすれば、所定値以上の加速度の発生の検知、および、例えば緊急自動車のサイレン音等の特定の音の検知、といった複数の条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、複数の条件のうち個々の条件が成立するタイミングが、或る程度近しいタイミング(上述のステップS125で説明した所定時間以内)でなされているので、複数の条件の関連性の高さが確保される。したがって、異常事態の検証負荷をより確実に軽減すること等が可能となる。
なお、ステップS127の処理は、車両外部からの特定の情報として、特定の音を検知したか否かを監視する処理に限られず、例えば、車両に障害物が接近したか否かを監視するようにしてもよい。車両に接近している障害物は、例えば風船等のようなものではなく、例えば重量物(人、車両など)のように事故等の異常事態となる物とすると良い。重量物であるか否かの判断は、システム100の撮像装置(例えばカメラ141等)で撮像された画像を画像処理することで検知すると良い。この場合、ステップS125で判断される所定時間(車両に障害物が接近したか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば3秒以内といった比較的短い時間とするとよい。
[第1の実施例の変形例2の効果]
第1の実施例の変形例2によれば、複数の条件(所定値以上の加速度の発生の検知および車両外部からの特定の情報の検知)が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得る。そのため、イベント記録処理(ステップS129)においてSDカード143に記録された画像データを、外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に提供することで、異常事態の検証負荷をより確実に軽減すること等が可能となる。
[第1の実施例の変形例3]
次に、図6を参照して、第1の実施例の変形例3について説明する。図6は、システム100のコントローラ130が実行する制御処理の第1の実施例の変形例3を説明するためのフローチャートである。
第1の実施例の変形例3では、第1の実施例におけるS107の判断(ユーザが特定の行為を行ったか否かの判断)に代えて又は加えて、所定値以上の加速度が発生した後の所定の時間内(ステップS135のYES)に、車両の変化を検知したか否かを判断する(ステップS137)。すなわち、所定値以上の加速度が発生したこと(ステップS133のYES)および所定値以上の加速度が発生した後の所定の時間内(ステップS135のYES)に車両の変化を検知したこと(ステップS137のYES)といった複数の条件を満たすと、イベント記録処理を行う(ステップS139)。なお、他の処理であるステップS131、S133およびS139の処理は、それぞれ、第1の実施例におけるステップS101、S103およびS109の処理と同様である。
具体的には、コントローラ130は、所定値以上の加速度が発生した後(ステップS133のYES)、所定時間が経過するまで(ステップS135)、車両の変化を検知したか否かを監視している(ステップS137)。車両の変化を検知したか否かの監視は、例えば、車両の電位変化を検知したか否かの監視とするとよい。これは、システムが搭載された例えば車両等が他の物体と接触するといったような異常事態が発生したとき、他の物体との接触により車両等の電位が変化している可能性が高いことに着目したものである。この場合、ステップS135で判断される所定時間(車両の変化を検知したか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば1秒以内といった比較的短い時間とするとよい。他の物体接触したとき、車両等の電位がただちに変化すると考えられるからである。
コントローラ130は、所定値以上の加速度が発生した後の所定時間内(ステップS135のYES)に、車両の変化として例えば車両の電位変化を検知したと判断すると(ステップS137のYES)、イベント記録処理を行う(ステップS139)。
また、コントローラ130は、所定値以上の加速度が発生していないとき(ステップS133のNO)は、ステップS131に戻る。また、コントローラ130は、所定値以上の加速度が発生したとしても、車両の変化を検知することなく、所定値以上の加速度の発生から所定時間を経過すると(ステップS135のNO)は、ステップS131に戻る。
このようにすれば、所定値以上の加速度の発生の検知、および、車両の変化の検知、といった複数の条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、複数の条件のうち個々の条件が成立するタイミングが、或る程度近しいタイミング(上述のステップS135で説明した所定時間以内)でなされているので、複数の条件の関連性の高さが確保される。したがって、異常事態の検証負荷をより確実に軽減すること等が可能となる。
なお、ステップS137の処理は、車両の変化を検知したか否かを監視する処理に限られず、例えば、車両の安全装置が作動したか否かを監視するようにしてもよい。車両の安全装置としては、例えば、エアバッグ装置、アンチロック・ブレーキシステム、シートベルトのプリテンショナ装置等を挙げることができる。この場合、ステップS135で判断される所定時間(車両の変化を検知したか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば3秒以内といった比較的短い時間とするとよい。
さらに、ステップS137の処理を、例えば、車両の走行速度が所定の平均走行速度(例えば40km/h以上)の状態から所定速度(例えば8km/h)以下になったか否か(移動速度の変化)を監視するようにしてもよい。また、ステップS137の処理を、例えば、車両の走行速度が特定の平均速度以上の状態から停車状態に遷移し、停車状態を所定時間以上(例えば5分以上)継続したか否かを監視するようにしてもよい。これは、事故等の異常事態が発生したとき、ユーザが車両等を停止させる可能性が高いことに鑑みたものである。この場合、ステップS135で判断される所定時間(車両の走行速度が所定速度以下またはゼロになったか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば10分以内、より好ましくは3~5分以内といった時間とするとよい。移動速度の変化は、例えば、GPSから得た情報や、車速センサから得た情報、ブレーキの検出結果などに基づいて監視するとよい。なお、上記の所定速度以下になったか否かの監視は、事故等の異常事態が発生したときにユーザが車両等を停止させる可能性が高いことに鑑みれば、走行速度がゼロになったか否かを監視するようにすることが好ましいが、速度センサの誤差を考慮し、所定速度(例えば8km/h)以下になったか否かを監視するようにするとよい。
また、ステップS137の処理を、車両の走行速度が特定の平均速度以上の状態から停車状態に遷移し、停車状態を所定時間以上(例えば3~5分以上)継続したか否かを監視するようにしてもよい。3~5分以上であれば、信号待ちの可能性を排除することが可能となる。
[第1の実施例の変形例3の効果]
第1の実施例の変形例3によれば、複数の条件(所定値以上の加速度の発生の検知および車両の変化の検知)が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得る。そのため、イベント記録処理(ステップS139)においてSDカード143に記録された画像データを、外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に提供することで、異常事態の検証負荷をより確実に軽減すること等が可能となる。
[第1の実施例の変形例4]
次に、図7を参照して、第1の実施例の変形例4について説明する。図7は、システム100のコントローラ130が実行する制御処理の第1の実施例の変形例4を説明するためのフローチャートである。
第1の実施例の変形例4では、第1の実施例におけるS107の判断(ユーザが特定の行為を行ったか否かの判断)に代えて又は加えて、所定値以上の加速度が発生した後の所定の時間内(ステップS145のYES)に、車両から特定の走行情報を検知したか否かを判断する(ステップS147)。すなわち、所定値以上の加速度が発生したこと(ステップS143のYES)および所定値以上の加速度が発生した後の所定の時間内(ステップS145のYES)に車両から特定の走行情報を検知したこと(ステップS147のYES)といった複数の条件を満たすと、イベント記録処理を行う(ステップS149)。なお、他の処理であるステップS141、S143およびS149の処理は、それぞれ、第1の実施例におけるステップS101、S103およびS109の処理と同様である。
具体的には、コントローラ130は、所定値以上の加速度が発生した後(ステップS143のYES)、所定時間が経過するまで(ステップS145)、車両からの特定の走行情報を検知したか否かを監視している(ステップS147)。車両からの特定の走行情報を検知したか否かの監視は、例えば、車両が事故多発エリアを走行していることが検知されたか否かの監視とするとよい。コントローラ130は、車両等が事故多発エリアを走行しているか否かを、例えばGPS受信機140によって取得できる車両等の走行エリアから検知することができる。事故多発エリアの情報は、例えば、あらかじめシステムに記憶させるようにしてもよいし、コントローラ130が外部(例えば保険会社や警察署等の外部機関のサーバ)から取得するようにしてもよい。
また、ステップS145で判断される所定時間(例えば車両からの特定の走行情報を検知したか否かの監視時間)は、所定値以上の加速度が発生したことを検知してから例えば10秒以内といった、例えばGPS受信機140によって取得できる車両等の走行エリアの検知に要する程度の時間とするとよい。
なお、上記では、所定値以上の加速度が発生した後(ステップS143のYES)、所定時間が経過するまで(ステップS145)、車両からの特定の走行情報を検知したか否かを監視している(ステップS147)が、これに代えて、車両からの特定の走行情報を検知している間、常に、所定値以上の加速度が発生したか否かを監視するようにしてもよい。
コントローラ130は、所定値以上の加速度が発生したこと(ステップS143のYES)、および、車両から特定の走行情報を検知したこと(ステップS147のYES)、の両方の条件を満たすと、イベント記録処理を行う(ステップS149)。
また、コントローラ130は、所定値以上の加速度が発生していないとき(ステップS143のNO)は、ステップS141に戻る。また、コントローラ130は、所定値以上の加速度が発生したとしても車両からの特定の走行情報を検知しなかったときや、車両からの特定の走行情報を検知したとしても所定値以上の加速度の発生を検知しなかったとき、ステップS141に戻る。
このようにすれば、所定値以上の加速度の発生の検知、および、車両が事故多発エリアを走行していることの検知、といった複数の条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、複数の条件のうち個々の条件が成立するタイミングが、或る程度近しいタイミング(上述のステップS145で説明した所定時間以内)でなされているので、複数の条件の関連性の高さが確保される。したがって、異常事態の検証負荷をより確実に軽減すること等が可能となる。
なお、ステップS147の処理は、車両が事故多発エリアを走行しているか否かを監視する処理に限られず、例えば、車両が事故多発時間帯(例えば16~18時頃)に走行しているか否かを監視するようにしてもよい。
[第1の実施例の変形例4の効果]
第1の実施例の変形例4によれば、複数の条件(所定値以上の加速度の発生の検知および車両の走行情報の検知)が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得る。そのため、イベント記録処理(ステップS149)においてSDカード143に記録された画像データを、外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に提供することで、異常事態の検証負荷をより確実に軽減すること等が可能となる。
[第1の実施例の変形例5]
次に、図8を参照して、第1の実施例の変形例5について説明する。図8は、システム100のコントローラ130が実行する制御処理の第1の実施例の変形例5を説明するためのフローチャートである。
第1の実施例の変形例5は、所定値以上の加速度の発生の検知という条件以外の複数の条件の成立を、イベント記録処理を行うための条件としたものである。すなわち、単独の条件が成立しただけでは、所定値以上の加速度が発生したときにイベント記録処理を行う従来と比べてイベント記録処理を行う頻度を低くすることができなかったとしても、複数の条件の成立をイベント記録処理の条件とすることで、従来よりもイベント記録処理を行う頻度を低くすることが可能となる点に着目したものである。なお、ステップS151、S159の処理は、それぞれ、第1の実施例におけるステップS101およびS109の処理と同様である。
例えば、コントローラ130は、電源がオンになった後(ステップS151のYES)、1つ目の条件としてユーザが特定の行為を行ったか否かを判断し(ステップS153)、ユーザが特定の行為を行ったと判断した後(ステップS153のYES)、所定時間が経過するまで(ステップS155)、2つ目の条件の成立すなわちユーザから特定の情報が検知されたか否かを監視している(ステップS157)。1つ目の条件であるユーザが特定の行為を行ったことおよび2つ目の条件であるユーザから特定の情報が検知されたことの両方の条件を所定時間以内に満たすと(ステップS153のYES且つステップS155のYES且つステップS157のYES)、イベント記録処理を行う(ステップS159)。
なお、ユーザが特定の行為を行ったか否かの判断(ステップS153)およびユーザから特定の情報が検知されたか否かの判断(ステップS157)の順序は、上述した順に限られず、例えば、ユーザから特定の情報が検知されたと判断した後、所定時間が経過するまで(ステップS155のYES)、ユーザから特定の情報が検知されたか否かを監視するようにしてもよい。
また、コントローラ130は、ユーザが特定の行為を行ったことおよびユーザから特定の情報が検知されたことの両方の条件を所定時間以内に満たさなければ(ステップ153のNO、ステップS155のNO)、ステップS151に戻る。また、ユーザが特定の行為を行ったことおよびユーザから特定の情報が検知されたことのうちいずれかの条件を満たし、且つこの条件を満たしてから所定時間が経過していなければ(ステップS155のNO)、ステップS153に戻る。
なお、ステップS155で判断される所定時間(2つ目の条件を満たしたか否かの監視時間)は、2つ目の条件によって異なる。例えば、2つ目の条件が例えばユーザが操作ボタン124を操作したことの検知である場合には、1つ目の条件が成立してから例えば20分以内といった、ユーザが操作ボタン124を操作するまである程度の時間を確保できる程度とするとよい。また、2つ目の条件が例えばユーザの心拍数が所定の範囲外(例えば心拍数100以上、或いは測定不能)となったことの検知である場合には、1つ目の条件が成立してから例えば外部電源がOFFになるまでの時間といった、ユーザの身体に影響が出てくる可能性があることを想定した時間とするとよい。また、2つ目の条件が例えば特定の音(例えば、特定の車両(例えば救急車やパトカー等の緊急自動車)のサイレンの音、通行人の大きな声、車両の衝突音など)の検知である場合には、1つ目の条件が成立してから例えば40分以内といった、事故等の異常状態が発生してから特定の車両が到着するまでの時間を考慮した時間とするとよい。また、2つ目の条件が例えば車両の電位変化を検知である場合には、他の物体接触したときは車両等の電位がただちに変化すると考えられることから、1つ目の条件が成立してから例えば1秒以内といった比較的短い時間とするとよい。また、2つ目の条件が例えば車両が事故多発エリアを走行していることの検知である場合には、1つ目の条件が成立してから例えば10秒以内といった、例えばGPS受信機140によって取得できる車両等の走行エリアの検知に要する程度の時間とするとよい。このように、ステップS155で判断される所定時間(2つ目の条件を満たしたか否かの監視時間)は、2つ目の条件が成立しうる時間にするとよい。
このようにすれば、ユーザが特定の行為を行ったことの検知、および、ユーザから特定の情報を取得したことの検知、といった複数の条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、複数の条件のうち個々の条件が成立するタイミングが、或る程度近しいタイミング(2つ目の条件によって異なる所定時間以内)でなされているので、複数の条件の関連性の高さが確保される。したがって、異常事態の検証負荷をより確実に軽減すること等が可能となる。
また、ステップS153で行われる処理およびステップS157で行われる処理の組み合わせは、ユーザが特定の行為を行ったことの検知およびユーザからの特定の情報の検知の組み合わせに限定されるものではない。例えば、上記の組み合わせとしては、ユーザが特定の行為を行ったことの検知および車両外部からの特定の情報の検知、ユーザが特定の行為を行ったことの検知および車両の変化の検知、ユーザが特定の行為を行ったことの検知および車両外部からの特定の情報の検知、ユーザから特定の情報を取得したことの検知および車両外部からの特定の情報の検知、ユーザからの特定の情報の検知および車両の変化の検知、ユーザからの特定の情報の検知および車両外部からの特定の情報の検知、車両外部からの特定の情報の検知および車両の変化の検知、車両外部からの特定の情報の検知および車両外部からの特定の情報の検知、ならびに、車両の変化の検知および車両外部からの特定の情報の検知等といったバリエーションを挙げることができる。
さらには、この第1の実施例の変形例5では、所定値以上の加速度の発生の検知という条件以外の複数の条件の成立を、イベント記録処理を行うための条件としているが、複数の条件は、2つの条件の成立に限られない。例えば、ユーザが特定の行為を行ったことの検知、ユーザからの特定の情報の検知、および、車両外部からの特定の情報の検知等といった3つ以上の条件が成立した場合であっても、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。この3つ以上の条件の組み合わせは、例えば、上述したユーザが特定の行為を行ったことの検知、ユーザからの特定の情報の検知、車両外部からの特定の情報の検知、車両の変化の検知、および、車両外部からの特定の情報の検知等の複数の条件のなかから任意の3つ以上の条件の組み合わせとするとよい。
[第1の実施例の変形例5の効果]
第1の実施例の変形例5によれば、所定値以上の加速度の発生の検知という条件以外の複数の条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得る。そのため、イベント記録処理(ステップS159)においてSDカード143に記録された画像データを、外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に提供することで、異常事態の検証負荷をより確実に軽減すること等が可能となる。とくに、単独の条件が成立しただけでは、所定値以上の加速度が発生したときにイベント記録処理を行う従来と比べてイベント記録処理を行う頻度を低くすることができなかったとしても、複数の条件の成立をイベント記録処理の条件とすることで、従来よりもイベント記録処理を行う頻度を低くすることが可能となる。ただし、単独の条件が成立しただけで従来よりもイベント記録処理を行う頻度が低くなる条件を、上記の複数の条件の一つとすることを排除するものではない。
[第1の実施例および第1の実施例の変形例1~5の効果等]
第1の実施例および第1の実施例の変形例1~5によれば、所定値以上の加速度が発生したときにイベント記録処理を行う従来と比べて、イベント記録処理を行う頻度を低くすることが可能となる。なお、複数の条件のうちの一つを所定値以上の加速度の発生とした場合には、従来から用いられている加速度センサを流用することができ、イベント記録画像データを記録するイベント記録処理を行う頻度を、低コストで低くすることが可能となる。
また、第1の実施例および第1の実施例の変形例1~変形例5のイベント記録処理(ステップS109、ステップS119、ステップS129、ステップS139、ステップS149、ステップS159)においてSDカード143に記録された画像データは、SDカード143を郵送等で外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に送るようにしてもよい。ただし、上記のイベント記録処理において記録された画像データを、外部の特定の機関に送信する処理をコントローラ130が行うようにすると、手間を煩わせることなくタイムリーに画像データを提供することが可能となる。
イベント記録処理において記録された画像データを、外部の特定の機関に送信する処理をコントローラ130が行うようにする場合、送信処理を行ってもよいか否かをシステムがユーザに確認してもよい。例えば、システムは、対話型UIにより、「記録した画像を送信しますか?」等の音声により確認を行うようにするとよい。システムは、ユーザによる「する/しない」等の返答を音声によって認識し、「する」という返答があった場合に、システムが保険会社や警察署等に画像を送信するとよい。
また、イベント記録処理において記録された画像データを、外部の特定の機関に送信する処理をコントローラ130が行うようにする場合、送信操作を行うようユーザに促すようにするとよい。例えば、システムは、対話型UIにより、「データ送信機能付きのドライブレコーダーを装着されていたら、操作ボタンを押して画像を送信してください」等の音声により送信操作を促すとよい。システムは、ユーザが送信ボタンを押した場合に、保険会社や警察署等に画像を送信するとよい。
また、イベント記録処理において記録された画像データを外部の特定の機関に送信する処理をコントローラ130が行うようにする場合、イベント記録を行う場合に適用される加速度センサ144の感度(所定値)と、イベント記録された画像を外部の特定の機関に送信する際に適用される加速度センサ144の感度(所定値)とを異なる値に設定するとよい。具体的には、例えば、画像を送信する際に適用される感度(所定値)を、イベント記録を行う際に適用される加速度センサ144の感度(所定値)よりも高く設定するとよい。さらには、画像を送信する際に適用される感度(所定値)を例えば1.5G程度、より好ましくは例えば3.0G以上(明らかな事故発生に相当する加速度)とし、イベント記録を行う際に適用される加速度センサ144の感度(所定値)を例えば1G程度に設定するとよい。このような設定とすることにより、画像がイベント記録される頻度よりも画像が送信される頻度を低くして、保険会社等における異常事態の検証負荷をより確実に軽減すること等が可能となる。
なお、第1の実施例および第1の実施例の変形例1~変形例5のイベント記録処理(ステップS109、ステップS119、ステップS129、ステップS139、ステップS149、ステップS159)は、それぞれ、例えば、SDカード143の第1の記録領域に記録される常時記録画像データを読み出して、最初のイベント発生時点(ステップS103,S113,S123,S133,S143,S153)前後それぞれ所定時間(例えば前後20秒ずつ)の画像データを切り出して、イベント記録画像データとしてSDカード143の第2の記録領域に記録する処理等である。
また、第1の実施例および第1の実施例の変形例1~変形例5のイベント記録処理(ステップS109、ステップS119、ステップS129、ステップS139、ステップS149、ステップS159)では、画像データをSDカード143に記録するようにしているが、これに限られず、システムのRAM133に記録してもよいし、SDカード143およびシステムのRAM133の両方に記録してもよい。さらには、システム外の記録領域に記録するようにしてもよい。
また、第1の実施例および第1の実施例の変形例1~変形例5のイベント記録処理(ステップS109、ステップS119、ステップS129、ステップS139、ステップS149、ステップS159)において画像データを記録する際に、記録するデータに異常事態が写っている可能性をランク付けするようにするとよい。
また、第1の実施例および第1の実施例の変形例1~変形例5において、システムは、個人向けの性能設定が可能な個人用モードと、業務用の性能設定が可能な業務用モードとの間で、システムの性能を切り替えることができる機能を備えているとよい。これにより、システムのユーザに応じてシステムの性能を任意に設定することができる。例えば、個人用モードに設定されると、映像の画質等を平均的な(ミディアムな)画質に設定したり、外部への画像送信を通常の回線等で行うようにし、業務用モードに設定されると、映像の画質等を高画質に設定したり、外部への画像送信をLTE(Long Term Evolution)(登録商標)等の高速回線で行うようにしてもよい。
また、第1の実施例および第1の実施例の変形例1~変形例5において、システムは、画像に異常事態が映っている確率を示す確率情報を画像に記載する機能を備えるようにするとよい。「異常事態が映っている確率を示す確率情報」は、例えばテロップのように画像に記載するとよい。また、車両が停車中で、且つ、所定値以上の加速度が発生した後に、ユーザが所定時間以上動かないことが検知されたときは、イベント記録を行い、記録した画像を外部に自動的に送信するとよい。また、イベント記録処理を行う条件がそろった後に、常時記録画像を事故後の状況(自分や相手方の態度、警察等の状況)の画像として外部(例えば警察署や保険会社等のサーバ)に送信するようにするとよい。
[第2の実施例]
次に、図9を参照して、コントローラ130が実行する制御処理の第2の実施例について説明する。図9は、システム100のコントローラ130が実行する制御処理の第2の実施例を説明するためのフローチャートである。
コントローラ130は、外部電源がONであるか否かを判断し(ステップS201)、外部電源がONである場合(ステップS201のYES)に、ステップS203~ステップS205の処理を行う。なお、図9では示さないが、システム100に電力が供給されて外部電源がONになると、コントローラ130は、カメラ141から入力された画像データ(常時記録画像データ)をSDカード143の第1の記録領域に常に記録する常時記録処理を行う。この常時記録処理は、システム100に電力が供給されている限り記録し続ける処理であるため、例えば後述するステップS203~ステップS205等の処理と併行して行われる。
ステップS201において、システム100への電力の供給が開始されて外部電源がONになると(YESの場合)、コントローラ130は、ユーザが特定の行為を行ったか否かを判断する(ステップS203)。
具体的には、コントローラ130は、ユーザによる特定の行為として、操作ボタン24(図1参照)の操作が検知されたか否かを、電源がONである限り常に監視する。コントローラ130は、操作ボタン24が操作されたと判断すると、(ステップS203のYES)、イベント記録処理を行う(ステップS205)。これは、ユーザが、事故等の異常事態が発生したときに操作ボタン24を操作すべきであると認識していれば、自らの意思で操作ボタン24が操作された場合には、異常事態が発生している可能性が高いことに鑑みたものである。
このようにすれば、操作ボタン24の操作の検知といった単独で信頼性の高い条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、単独の条件の成立を契機として画像を記録することで、例えば、システムの部品点数を抑えつつ、異常事態の検証負荷を軽減することができる。
なお、事故等の異常事態が発生したときに操作ボタン24の操作を促す機能をシステムに設けるようにするとよい。
また、操作ボタン24の誤操作が発生しうることに鑑みれば、操作ボタン24を操作したことをユーザがキャンセルすることができるようにするとよい。ユーザが操作ボタン24を操作した後にキャンセルした場合、イベント記録処理を行わないようにしてもよいし、イベント記録処理が行われた後に、記録された画像データを消去するようにしてもよい。
また、操作ボタン24の誤操作を判別する機能をシステムに設けるとよい。例えば、異常事態が発生したときはユーザが操作ボタン24を連打する可能性が高いことに鑑みて、所定時間以内に所定回数以上(例えば5秒以内に3回以上)操作ボタン24を連打したか否かで誤操作か否かを判別するようにするとよい。この場合、例えば、所定時間以内に所定回数以上操作ボタン24を連打すれば、その操作を正しい操作として認識し、所定時間以内に所定回数以上連打しなかった場合には、誤操作であると認識するようにするとよい。また、操作ボタン24を1回操作するとシステムが「事故等の異常事態が発生している場合には操作ボタンをもう一度押してください」等のアナウンスを流すようにするとよい。この場合、ユーザが所定時間以内(例えば10秒以内)に操作ボタン24をもう一度操作すればシステムが先の1回の操作を正しい操作として認識し、ユーザが所定時間以内に操作ボタン24を操作しなければシステムが先の1回の操作を誤操作として認識するようにするとよい。
また、ユーザによる特定の行為が行われたか否かを判断するステップS203の処理は、操作ボタン24(図1参照)の操作が検知されたか否かを判断する処理に限られず、例えば、ユーザが所有する特定の装置(例えばスマートフォンやタブレットなど)から外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に通信をしたことを検知する処理としてもよい。特定の機関の電話番号等をシステムに登録しておくとよい。また、ユーザが所有する特定の装置から外部の特定の機関に通信を行ったときの履歴(例えば日時や通信したときの会話の内容)を記録するようにするとなおよい。
[第2の実施例の効果等]
第2の実施例によれば、ユーザによる特定の行為といった単独の条件の成立を契機として画像を記録することで、例えば、システムの部品点数を抑えつつ、異常事態の検証負荷を軽減することが可能となる。
[第2の実施例の変形例1~変形例3]
次に、図10~図12を参照して、第2の実施例の変形例1~変形例3について説明する。第2の実施例の変形例1~変形例3が第2の実施例と異なる点は、図9に示されるシステムのコントローラが実行する処理のうちの一部の処理である。
[第2の実施例の変形例1]
先ず、図10を参照して、第2の実施例の変形例1について説明する。図10は、システム100のコントローラ130が実行する制御処理の第2の実施例の変形例1を説明するためのフローチャートである。
第2の実施例の変形例1では、第2の実施例におけるS203の判断(ユーザが特定の行為を行ったか否かの判断)に代えて、ユーザからの特定の情報を検知したか否かを判断する(ステップS213)。ユーザからの特定の情報を検知したという条件を満たすと、イベント記録処理を行う(ステップS215)。なお、他の処理であるステップS211およびS215の処理は、それぞれ、第2の実施例におけるステップS201およびS205の処理と同様である。
具体的には、コントローラ130は、電源がONになった後(ステップS211のYES)、ユーザからの特定の情報として、例えば、ユーザの身体に所定値以上の変化が生じたか否かを、電源がONである限り常に監視し(ステップS213)、ユーザの身体に所定値以上の変化が生じたと判断すると(ステップS213のYES)、イベント記録処理を行う(ステップS215)。
ユーザの身体に所定値以上の変化が生じたか否かの監視は、システムが搭載される車両等の例えばハンドルにユーザの血流を測定できるセンサを設けてユーザの心拍数を検出し、検出された心拍数が所定の範囲外(例えば心拍数100以上、或いは測定不能)となったことを検知する処理としてもよい。また、システムが搭載される例えば車両の車内等を撮像するカメラを備えて、当該カメラが撮像するユーザの身体の状態が通常の運転時とは異なる状態になったこと(例えば、ユーザの頭の位置が所定の領域から所定時間以上にわたって逸脱していることなど)を検知する処理としてもよい。
[第2の実施例の変形例1の効果等]
第2の実施例の変形例1によれば、ユーザからの特定の情報を検知といった単独で信頼性の高い条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、単独の条件の成立を契機として画像を記録することで、例えば、システムの部品点数を抑えつつ、異常事態の検証負荷を軽減することができる。さらには、ユーザの心拍数など、ユーザからの特定の情報を検知することをイベント記録処理の条件とすることで、ユーザの意識がない場合であっても、確実に画像を記録することが可能となる。
[第2の実施例の変形例2]
次に、図11を参照して、第2の実施例の変形例2について説明する。図11は、システム100のコントローラ130が実行する制御処理の第2の実施例の変形例2を説明するためのフローチャートである。
第2の実施例の変形例2では、第2の実施例におけるS203の判断(ユーザが特定の行為を行ったか否かの判断)に代えて、車両外部からの情報を検知したか否かを判断する(ステップS223)。車両外部からの情報を検知したという条件を満たすと、イベント記録処理を行う(ステップS225)。なお、他の処理であるステップS221およびS225の処理は、それぞれ、第2の実施例におけるステップS201およびS205の処理と同様である。
具体的には、コントローラ130は、電源がONになった後(ステップS221のYES)、車両外部からの情報として、例えば、車両に障害物が接近したか否かを、電源がONである限り常に監視し(ステップS223)、車両に接近してきた障害物との距離がゼロになった(すなわち衝突した)と判断すると(ステップS223のYES)、イベント記録処理を行う(ステップS225)。
車両に障害物が接近したか否かの監視は、例えば測距センサを車両に設け、当該測距センサにより何らかの物体が接近したか否かを判断する処理とするとよい。また、例えば、車両の周囲を撮像するカメラを車両に搭載しておき、そのカメラの撮像画像を解析する処理としてもよい。ただし、車両に接近している障害物は、例えば風船等のようなものではなく、例えば重量物であるか否かを判断するようにするとなおよい。重量物であるか否かの判断は、システム100の撮像装置(例えばカメラ141等)で撮像された画像を画像処理することで検知すると良い。また、例えば複数のカメラ等の映像に基づき生成されたアラウンドビュー画像のように、自車を上から見た画像を用いて車両位置と周辺の重量物との距離が所定の距離となったことを検出する構成としてもよい。「車両等の物体に事故を発生させ得る重量物」かは、特に車両周辺の物体の高さが所定以上であるかの条件も用いて判定するとよい。車両周辺の物体の高さが所定以上であるかはマイクロ波センサまたはカメラの少なくとも一方の映像に基いて検出するとよい。また、この車両周辺の物体の高さの「所定」は、特に車高より高いこととするとよい。車高より低い物体は車の下を通過できるからである。
[第2の実施例の変形例2の効果等]
第2の実施例の変形例2によれば、車両外部からの情報を検知したことといった単独で信頼性の高い条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、単独の条件の成立を契機として画像を記録することで、例えば、システムの部品点数を抑えつつ、異常事態の検証負荷を軽減することができる。
[第2の実施例の変形例3]
次に、図12を参照して、第2の実施例の変形例3について説明する。図12は、システム100のコントローラ130が実行する制御処理の第2の実施例の変形例3を説明するためのフローチャートである。
第2の実施例の変形例3では、第2の実施例におけるS203の判断(ユーザが特定の行為を行ったか否かの判断)に代えて、車両の変化を検知したか否かを判断する(ステップS233)。車両の変化を検知したという条件を満たすと、イベント記録処理を行う(ステップS235)。なお、他の処理であるステップS231およびS235の処理は、それぞれ、第2の実施例におけるステップS201およびS205の処理と同様である。
具体的には、コントローラ130は、電源がONになった後(ステップS231のYES)、車両の変化として、例えば、車両(例えば車体)の電位が所定値以上変化したか否かを、電源がONである限り常に監視し(ステップS233)、車両の電位が所定値以上変化したと判断すると(ステップS233のYES)、イベント記録処理を行う(ステップS235)。
車両の電位が変化したか否かの監視は、例えば、車体(例えば車両のボンネットやバンパー等)に電圧計を接続して、車体(例えばボンネットやバンパー等)の電位を測定するようにするとよい。
このようにすれば、車両の電位が変化するといった単独で信頼性の高い条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。具体的には、例えば、システムから画像を受け取った保険会社等でその画像が事故等の異常事態の画像であるのか否かの検証負荷を低減すること等ができる。また、単独の条件の成立を契機として画像を記録することで、例えば、システムの部品点数を抑えつつ、異常事態の検証負荷を軽減することができる。
なお、ステップS233の処理は、車両の電位が所定値以上変化したか否かを検知する処理に限られず、例えば、車両の変形を検知する処置としてもよい。また、ステアリングハンドルに所定のセンサを取り付けておき、そのセンサがステアリングハンドルから外れた(脱落した)ことを検知する処理としてもよい。さらには、車両の安全装置が作動したか否かを検知する処理としてもよい。車両の安全装置としては、例えば、エアバッグ、アンチロック・ブレーキシステム、シートベルトのプリテンショナ装置などを挙げることができる。また、システムの作動中にこのシステムのカメラ(車内を撮像するカメラ)の視界の所定割合以上の部分が何等かの物体(例えば、展開したエアバッグ、事故の衝撃によって事故前の位置から移動した車内の物体、など)で覆われたことを検知する処理としてもよい。この処理において視界が急激に白で覆われた場合には、カメラの視界が展開したエアバッグで覆われている可能性が高いため、視界が急激に白で覆われたか否かを判断するようにしてもよい。
エアバッグの状態は、例えば、車両に搭載されたCANの通信内容に監視することで検知可能である。なお、CAN(Controller Area Network)の通信内容に基づき、例えば、エアバッグ展開、後突、エアバッグ系統異常、セーフィング、前突、側突などを検知可能である。また、エアバッグの状態は、エアバッグECUにアクセスすることにより検出してもよい。また、エアバッグの状態は、エアバッグの作動音の監視(例えば、100ms以下で150db~170dbといった大きな爆発音の監視)、エアバッグ作動に伴う空気圧の変化の監視、または、車両に搭載されたOBD(故障診断装置)、等によって検知するとよい。
[第2の実施例の変形例3の効果等]
第2の実施例の変形例3によれば、車両の変化を検知したことを契機として画像を記録することで、例えば、システムの部品点数を抑えつつ、異常事態の検証負荷を軽減することが可能となる。
[第2の実施例および第2の実施例の変形例1~3の効果等]
第2の実施例および第2の実施例の変形例1~3によれば、所定値以上の加速度が発生したときにイベント記録処理を行う従来と比べて、イベント記録処理を行う頻度を低くすることが可能となる。
また、第2の実施例および第2の実施例の変形例1~変形例3のイベント記録処理(ステップS205、ステップS215、ステップS225、ステップS235)においてSDカード143に記録された画像データは、SDカード143を郵送等で外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に送るようにしてもよい。ただし、上記のイベント記録処理において記録された画像データを、外部の特定の機関に送信する処理をコントローラ130が行うようにすると、手間を煩わせることなくタイムリーに画像データを提供することが可能となる。
なお、第2の実施例および第2の実施例の変形例1~変形例3のイベント記録処理(ステップS205、ステップS215、ステップS225、ステップS235)は、それぞれ、例えば、SDカード143の第1の記録領域に記録される常時記録画像データを読み出して、イベント発生時点(ステップS203,S213,S223,S233)前後それぞれ所定時間(例えば前後20秒ずつ)の画像データを切り出して、イベント記録画像データとしてSDカード143の第2の記録領域に記録する処理等である。
また、第2の実施例および第2の実施例の変形例1~変形例3のイベント記録処理(ステップS205、ステップS215、ステップS225、ステップS235)では、画像データをSDカード143に記録するようにしているが、これに限られず、システムのRAM133に記録してもよいし、SDカード143およびシステムのRAM133の両方に記録してもよい。さらには、システム外の記録領域に記録するようにしてもよい。
また、第2の実施例および第2の実施例の変形例1~変形例3のイベント記録処理(ステップS205、ステップS215、ステップS225、ステップS235)において画像データを記録する際に、記録するデータに異常事態が写っている可能性をランク付けするようにするとよい。
また、第2の実施例および第2の実施例の変形例1~変形例3において、システムは、個人向けの性能設定が可能な個人用モードと、業務用の性能設定が可能な業務用モードとの間で、システムの性能を切り替えることができる機能を備えているとよい。これにより、システムのユーザに応じてシステムの性能を任意に設定することができる。例えば、個人用モードに設定されると、映像の画質等を平均的な(ミディアムな)画質に設定したり、外部への画像送信を通常の回線等で行うようにし、業務用モードに設定されると、映像の画質等を高画質に設定したり、外部への画像送信をLTE(Long Term Evolution)(登録商標)等の高速回線で行うようにしてもよい。
[第3の実施例]
次に、図13を参照して、コントローラ130が実行する制御処理の第3の実施例について説明する。図13は、システム100のコントローラ130が実行する制御処理の第3の実施例を説明するためのフローチャートである。第3の実施例は、他の車両の事故の可能性を検知した場合に、外部(例えば保険会社や警察署等の特定機関のサーバ等)にデータを提供するようにしたものである。
コントローラ130は、外部電源がONであるか否かを判断し(ステップS301)、外部電源がONである場合(ステップS301のYES)に、ステップS303~ステップS307の処理を行う。なお、図14では示さないが、システム100に電力が供給されて外部電源がONになると、コントローラ130は、カメラ141から入力された画像データ(常時記録画像データ)をSDカード143の第1の記録領域に常に記録する常時記録処理を行う。この常時記録処理は、システム100に電力が供給されている限り記録し続ける処理であるため、例えば後述するステップS303~ステップS307等の処理と併行して行われる。
ステップS301において、システム100への電力の供給が開始されて外部電源がONになると(YESの場合)、コントローラ130は、他の車両の事故発生の可能性があることを検知したか否かを判断する(ステップS303)。
具体的には、コントローラ130は、電源がONになった後(ステップS301のYES)、他の車両の事故の可能性を検知したか否かの判断として、例えば、操作ボタン24(図1参照)が操作されたか否かを、電源がONである限り常に監視し(ステップS303)、操作ボタン24が操作されたと判断すると(ステップS303のYES)、イベント記録処理を行う(ステップS305)。これは、ユーザが、事故等の異常事態が他車両に発生していることを見たときに操作ボタン24を操作すべきであると認識していれば、自らの意思で操作ボタン24が操作された場合には、他車両に異常事態が発生している可能性が高いことに鑑みたものである。
コントローラ130は、イベント記録処理(ステップS305)を行うと、その後、ステップS305で記録した情報(画像等)を外部の所定のサーバに送信する(ステップS307)。所定のサーバとしては、例えば、保険会社のサーバ、警察署のサーバなどを挙げることができる。
なお、ステップS303の処理は、操作ボタン24の操作がなされたか否かを検知する処理に限られず、例えば、ユーザが所有する特定の装置(例えばスマートフォンやタブレットなど)から外部の特定の機関(例えば、警察署、消防署、日本自動車連盟、保険会社など)に通信をしたことを検知する処理としてもよい。この場合、特定の機関の電話番号等をシステムに登録しておくとよい。また、ユーザが所有する特定の装置から外部の特定の機関に通信を行ったときの履歴(例えば日時や通信したときの会話の内容)を記録するようにするとなおよい。
また、ステップS303の処理を、特定の音(例えば、所定値以上の大きな音や、自動車の衝突音など)が検知されたか否かを検知する処理としてもよい。さらには、車両が事故多発エリアを走行しているときや、車両が事故多発時間帯に走行しているときには、イベント記録として常時記録するようにしてもよい。
なお、ステップS305で行われるイベント記録処理では、撮像の日時や場所の情報を、画像にラベリングするようにするとよい。このようなラベリングを行うことで画像の検索を行いやすくなる。
[第3の実施例の効果等]
第3の実施例によれば、他の車両に事故等の異常事態が発生した可能性があることを検知した場合に、外部(例えば保険会社や警察署等の特定機関のサーバ等)にデータを提供することにより、外部において、他の車両の事故(異常事態)の検証に貢献できるとともに、異常事態の検証負荷を軽減することが可能となる。また、第3実施例に係るシステムを搭載する車両が増加すれば、他の車両の事故の検証に寄与する有効なデータが多くなり、他の車両の事故の検証の正確性をより一層高めることができる。
また、第3の実施例のイベント記録処理(ステップS305)では、画像データをSDカード143に記録するようにしているが、これに限られず、システムのRAM133に記録してもよいし、SDカード143およびシステムのRAM133の両方に記録してもよい。さらには、システム外(例えば外部の特定の機関)の記録領域に記録するようにしてもよい。
なお、第3の実施例のイベント記録処理(ステップS305)は、例えば、SDカード143の第1の記録領域に記録される常時記録画像データを読み出して、イベント発生時点(ステップS303)前後それぞれ所定時間(例えば前後20秒ずつ)の画像データを切り出して、イベント記録画像データとしてSDカード143の第2の記録領域に記録する処理等である。
また、第3の実施例のイベント記録処理(ステップS305)において画像データを記録する際に、記録するデータに異常事態が写っている可能性をランク付けするようにするとよい。
[第3の実施例の変形例]
次に、図14を参照して、コントローラ130が実行する制御処理の第3の実施例の変形例について説明する。図14は、システム100のコントローラ130が実行する制御処理の第3の実施例の変形例を説明するためのフローチャートである。第3の実施例の変形例は、外部の特定の機関(例えば、警察署、消防署、保険会社など)のサーバ等から例えば日時と場所とを指定したデータの要求があったときに、該当するデータを上記外部の特定の機関に送信するようにしたものである。
具体的には、コントローラ130は、外部電源がONであるか否かを判断し(ステップS311)、外部電源がONである場合(ステップS311のYES)に、ステップS313~ステップS317の処理を行う。なお、図14では示さないが、システム100に電力が供給されると、コントローラ130は、カメラ141から入力された画像データ(常時記録画像データ)をSDカード143の第1の記録領域に常に記録する常時記録処理を行う。この常時記録処理は、システム100に電力が供給されている限り記録し続ける処理であるため、例えば後述するステップS313~ステップS317等の処理と併行して行われる。なお、コントローラ130は、常時記録処理において、撮像の日時および場所の情報を、画像にラベリングして記録するようにするとよい。このようなラベリングを行うことで画像の検索を行いやすくなる。
ステップS311において、システム100への電力の供給が開始されて外部電源がONになると(YESの場合)、コントローラ130は、例えば外部の特定の機関(例えば、警察署、消防署、保険会社など)のサーバ等から問い合わせがあったか否かを判断する(ステップS313)。
コントローラ130は、例えば外部の特定の機関(例えば、警察署、消防署、保険会社など)のサーバ等から問い合わせがあったことを判断すると(ステップS313のYES)、該当するデータがSDカード143の第1の記録領域に記録されているか否かを判断する(ステップS315)。例えば、ステップS313の問い合わせが例えば日時と場所とを指定したデータの要求であった場合、コントローラ130は、指定された日時と場所に該当するラベリングされたデータがSDカード143の第1の記録領域に記録されているか否かを検索する。「指定された日時と場所に該当する」とは、指定された日時および場所に一致している場合の他、時間は走行時間にして例えば4~5分の違い、場所は例えば1~2kmの違いがあってもよい。そして、例えば外部の特定の機関(例えば、警察署、消防署、保険会社等)のサーバ等からの問い合わせに該当するデータがSDカード143の第1の記録領域に記録されていれば(ステップS315のYES)、該当するデータを切り取って、問い合わせ元(例えば、警察署、消防署、保険会社等)のサーバ等に送信する。問い合わせに該当するデータがSDカード143の第1の記録領域に記録されていない場合には、上記の問い合わせを無視してもよいし、該当するデータが記録されていないことを示す情報を問い合わせ元に送信するようにしてもよい。
なお、コントローラ130は、常時記録処理において、撮像の日時および場所の情報に代えてまたは加えて、例えば他の車両の特徴的な形状や他の車両の色等の情報を画像にラベリングして記録するようにしてもよい。画像にラベリングされる情報量が多くなることで画像の検索が容易となる。他の車両の特徴的な形状や他の車両の色等の情報は、カメラ141で撮像された画像を解析することによって得ることが可能である。
[第3の実施例の変形例の効果等]
第3の実施例の変形例によれば、他の車両に事故等の異常事態が発生した可能性がある画像を読み出して外部の特定の機関に送信することで、他の車両の事故の検証に役立てることができる。問い合わせされた信頼性の高い条件が成立することにより、所定値以上の加速度が発生したときに画像が記録される場合よりも低い頻度で画像を記録し得るので、異常事態の検証負荷をより確実に軽減すること等が可能となる。
[第3の実施例および第3の実施例の変形例の効果等]
第3の実施例および第3の実施例の変形例によれば、他の車両に事故等の異常事態が発生した可能性があることを検知した場合に、外部(例えば保険会社や警察署等の特定機関のサーバ等)にデータを提供したり送信したりすることにより、外部において、他の車両の事故(異常事態)の検証に貢献できるとともに、異常事態の検証負荷を軽減することが可能となる。とくに、システムが搭載された自車両等において所定値以上の加速度が発生したときにイベント記録処理を行い、他社から画像等が提供されることなくイベント記録処理により記録された画像を用いて異常事態の検証を行う従来と比べて、異常事態の検証負荷を軽減することが可能となる。また、第3実施例または第3の実施例の変形例に係るシステムを搭載する車両が増加すれば、他の車両の事故の検証に寄与する有効なデータが多くなり、他の車両の事故の検証の正確性をより一層高めることができる。
また、第3の実施例および第3の実施例の変形例において、システムは、個人向けの性能設定が可能な個人用モードと、業務用の性能設定が可能な業務用モードとの間で、システムの性能を切り替えることができる機能を備えているとよい。これにより、システムのユーザに応じてシステムの性能を任意に設定することができる。例えば、個人用モードに設定されると、映像の画質等を平均的な(ミディアムな)画質に設定したり、外部への画像送信を通常の回線等で行うようにし、業務用モードに設定されると、映像の画質等を高画質に設定したり、外部への画像送信をLTE(Long Term Evolution)(登録商標)等の高速回線で行うようにしてもよい。
[その他の実施例]
各実施例の少なくともいずれか1つに記載のイベント記録に加え、従来と同様の所定以上の加速度が発生した時に撮像された画像を記録する機能(ここでは加速度イベント記録機能という)を備えるとよく、「所定以上の加速度が発生したときよりも低い頻度で成立しうる特定の条件が成立したことを契機として、撮像された画像を所定の記録領域に記録する機能」は、この加速度イベント記録機能における記録条件である「所定以上の加速度」よりも低い頻度で成立しうる特定の条件が成立したことを契機として撮像された画像を所定の記録領域に記録する機能とすると特によい。また、加速度イベント記録機能によっての記録条件である「所定以上の加速度」は、ユーザ等の指示に基いて設定可能な構成とするとよく、特にこの場合、設定の中のデフォルトの設定である加速度よりも低い頻度で成立しうる特定の条件が成立したことを契機として撮像された画像を所定の記録領域に記録する機能とすると特によい。より望ましくは、設定可能な最も大きい加速度よりも低い頻度で成立しうる特定の条件が成立したことを契機として撮像された画像を所定の記録領域に記録する機能とするとよい。
また、上述の各実施例および各変形例は例示であり、各実施例および各変形例で示した構成の部分的な置換または組み合わせが可能であることは言うまでもなく、また、各実施例および各変形例に記載の各構成要素は、任意に組み合わせるとよい。例えば、コントローラ130は、第1の実施例および第1の実施例の変形例1~5のうちのいずれかの処理と、第2の実施例および第2の実施例の変形例1~3のうちのいずれかの処理とを並行して(例えばマルチタスク等で)実行するようにしてもよい。例えば、コントローラ130は、複数の条件が成立したときのイベント記録処理(図3,図4,図5,図6,図7,図8)と、単独の条件が成立したときのイベント記録処理(図9,図10,図11,図12)とをマルチタスクで実行するようにしてもよい。この場合、複数の条件が成立したときのイベント記録処理(ステップS109、ステップS119、ステップS129、ステップS139、ステップS149、ステップS159)や、単独の条件が成立したときのイベント記録処理(ステップS205、ステップS215、ステップS225、ステップS235)において、事故の発生場所や発生時刻などの情報を画像データにラベリングして記録するようにするとよい。
また、そのイベントの種別を画像データに関連づけて記録するようにするとよい。イベントの種別は各図のイベント記録処理のステップ(ステップSxx9(xxは各図に記載の数値、以下同様))を行なうための条件のステップの内容を特定する情報とするとよい。例えば、各図のステップSxx3,図3から8のステップSxx5,ステップSxx7の条件を特定する情報(例えば条件の名称)とするとよい。例えば、図3であれば、イベント記録処理のステップS109を行なうための条件のステップであるS103,ステップS105,ステップS107の条件を特定する情報を記録するとよく、例えば種別を「所定値以上の加速度」かつ「所定時間以内」かつ「ユーザが特定の行為を行ったことを検知」という情報を画像データに関連付けて記録するようにするとよい。他の図のフローについても同様とするとよい。
なお、複数の条件が成立したときとは、例えば、単独の条件が成立しただけでは、所定値以上の加速度が発生したときにイベント記録処理を行う従来と比べてイベント記録処理を行う頻度を低くすることができなかったとしても、複数の条件の成立をイベント記録処理の条件とすることで、従来よりもイベント記録処理を行う頻度を低くすることが可能となる条件が成立したとき等とするとよい。また、上記の単独の条件が成立したときとは、例えば、所定値以上の加速度の発生とは異なる単独の条件であり、所定値以上の加速度が発生したときにイベント記録処理を行う従来と比べて、イベント記録処理を行う頻度を低くすることが可能となる条件が成立したとき等とするとよい。また、同様に、コントローラ130は、第1の実施例および第1の実施例の変形例1~5のうちのいずれかの処理と、第3の実施例または第3の実施例の変形例の処理とをマルチタスクで実行するようにしてもよい。これについて詳述すると、コントローラ130は、複数の条件が成立したときのイベント記録処理(ステップS109、ステップS119、ステップS129、ステップS139、ステップS149、ステップS159)と、例えば事故等の異常事態が他車両(システムが搭載された車両とは別の車両)等に発生した可能性があるときに外部のサーバに情報を送信する処理(ステップS307、ステップS317)とをマルチタスクで実行するようにしてもよい。この場合、複数の条件が成立したときのイベント記録処理(ステップS109、ステップS119、ステップS129、ステップS139、ステップS149、ステップS159)において、事故の発生場所や発生時刻などの情報を画像データにラベリングして記録したり、外部のサーバに情報を送信する処理(ステップS307、ステップS317)において、事故の発生場所や発生時刻などの情報を画像データにラベリングして送信したりするようにするとよい。さらに、同様に、第2の実施例および第2の実施例の変形例1~3のうちのいずれかの処理と、第3の実施例または第3の実施例の変形例の処理とをマルチタスクで実行するようにしてもよいし、第1の実施例および第1の実施例の変形例1~5うちのいずれかの処理と、第2の実施例および第2の実施例の変形例1~3のうちのいずれかの処理と、第3の実施例または第3の実施例の変形例の処理とをマルチタスクで実行するようにしてもよい。
また、課題を解決する手段に記載の発明や各構成要素を、各実施例および各変形例の各構成要素の組み合わせにさらに適用してもよい。複数の実施例および複数の変形例の同様の構成による同様の作用効果については実施例および変形例ごとには逐次言及しない。さらに、本発明は上述の実施例に制限されるものではない。例えば、種々の変更、改良、組み合わせ等が可能なことは当業者に自明であろう。