JP2012003408A - ドライブレコーダ - Google Patents

Abstract

【課題】ドライブレコーダの映像データを身近な再生機器で再生確認できるようにする。
【解決手段】本発明に係るドライブレコーダ６００は、映像データを含む車両の運転状況データを収集するデータ収集部（例えば、カメラ６１０）と；ユーザ要求に応じて、前記映像データをリムーバブルメディア７３０に出力する際のデータ圧縮方式、ファイルフォーマット、及び、出力先のフォルダ階層を指定する制御部６６０と；を有する。
【選択図】図１６

Description

本発明は、交通事故発生時や危険運転時などに車両の運転状況データ（映像データや走行データなど）を記録するドライブレコーダに関するものである。

近年、交通事故の抑制や事後解析に貢献し得る手段として、車両にドライブレコーダを搭載するケースが増えてきている。なお、ドライブレコーダに関連する従来技術の一例としては、特許文献１を挙げることができる。

特開２００８−５２２３０号公報

上記従来のドライブレコーダを車両に搭載しておけば、自責の交通事故や危険運転が記録されてしまうことを嫌い、運転者は常に安全運転を心掛けるようになるので、交通事故の抑制に寄与することが可能となる。また、万一、過失責任のない運転者が交通事故に巻き込まれてしまった場合には、ドライブレコーダに記録された運転状況データを事後解析することにより、運転者の正当性を立証することも可能となる。

また、ドライブレコーダに記録された運転状況データのうち、特に、カメラで撮影された映像データを事故現場で直ちに再生し、事故発生時の状況を確認することができれば、ドライブレコーダの利便性ないし有効性を向上することができる。例えば、事故発生時に記録された映像データをその場で再生することにより、当事者間で双方の主張の真偽を確認したり、警察の事情聴取に対して適切に事故発生時の状況を伝えることが可能となる。また、事故発生直後に再生された映像データであれば、その内容を改竄する時間的な余裕がなく、証拠としての価値が高いものとなる。

なお、アナログビデオ出力端子を備えたドライブレコーダであれば、アナログビデオ入力端子を備えた再生機器（カーナビゲーションシステムやポータブルテレビなど）に映像データや音声データを出力することができるので、事故発生時に記録された映像データや音声データをその場で確認することが可能である。しかしながら、このようなドライブレコーダでは、映像の現場確認手段として選択可能な再生機器が非常に限定されており、必ずしもユーザにとって利便性が高いとは言えなかった。

また、一般的なドライブレコーダには、パーソナルコンピュータでの事後解析を目的として、事故発生時に記録された運転状況データを所定規格のリムーバブルメディア（ＳＤカードなど）に書き出す機能が備えられている。一方、ユーザの身近に存在する再生機器（ＰＮＤ［Portable Navigation Device］、ポータブルメディアプレーヤ、携帯電話機など）には、リムーバブルメディアに記録された種々のデータを取り扱うことが可能な機種も多く存在する。従って、運転状況データが記録されたリムーバブルメディアをドライブレコーダから上記の再生機器に移し、リムーバブルメディアに記録されている運転状況データを再生機器で再生することができれば、映像データを事故現場で確認する機会が大幅に増大する。

しかし、従来のドライブレコーダは、事故発生時の運転状況データとして、映像データや音声データと共に、車両の加速度データやＧＰＳ［Global Positioning System］データ、車速データ、現在時刻データなど、種々のデータを含む独自フォーマットのファイルを作成し、これをリムーバブルメディアに書き出す構成とされていた。そのため、リムーバブルメディアに記録されている運転状況データは、専用の解析ソフトがインストールされたパーソナルコンピュータでしか読み出すことができず、ユーザの身近に存在する再生機器では、その内容を読み出すことができなかった。

本発明は、本願の発明者が見い出した上記の問題点に鑑み、ユーザの身近に存在する再生機器を用いて運転状況データを確認することが可能なドライブレコーダを提供することを目的とする。

上記の目的を達成するために、本発明に係るドライブレコーダは、映像データを含む車両の運転状況データを収集するデータ収集部と；ユーザ要求に応じて、前記映像データをリムーバブルメディアに出力する際のデータ圧縮方式、ファイルフォーマット、及び、出力先のフォルダ階層を指定する制御部と；を有する構成（第１の構成）とされている。

なお、上記第１の構成から成るドライブレコーダにおいて、前記制御部は、前記映像データを前記リムーバブルメディアに出力する際、前記映像データとこれに同期した音声データを１つのファイルに統合して出力する構成（第２の構成）にするとよい。

また、上記第１または第２の構成から成るドライブレコーダにおいて、前記制御部は、前記映像データを前記リムーバブルメディアに出力する際、車両の加速度データ、ＧＰＳデータ、及び、車速データなどの運転状況データを別ファイルとして出力する構成（第３の構成）にするとよい。

また、上記第１または第２の構成から成るドライブレコーダにおいて、前記制御部は、前記映像データを前記リムーバブルメディアに出力する際、車両の加速度データ、ＧＰＳデータ、及び、車速データなどの運転状況データを文字情報の形で前記映像データに埋め込んで出力する構成（第４の構成）にするとよい。

また、上記第１〜第４いずれかの構成から成るドライブレコーダにおいて、前記データ圧縮方式の選択肢には、Ｍｏｔｉｏｎ−ＪＰＥＧ、ＭＰＥＧ−２、及び、ＭＰＥＧ４が含まれている構成（第５の構成）にするとよい。

また、上記第１〜第５いずれかの構成から成るドライブレコーダにおいて、前記ファイルフォーマットの選択肢には、独自フォーマット、ＡＶＩフォーマット、ＷＭＡフォーマット、及び、ＭＰＥＧフォーマットが含まれている構成（第６の構成）にするとよい。

また、上記第１〜第６いずれかの構成から成るドライブレコーダにおいて、前記制御部は、前記リムーバブルメディアに格納されたデータ記録方式指定プログラムの形で前記ユーザ要求を受け付ける構成（第７の構成）にするとよい。

また、本発明に係るドライブレコーダ運用システムは、上記第７の構成から成るドライブレコーダと；種々の再生機器に対応した前記データ記録方式指定プログラムを格納するサーバと；ユーザ要求に応じて、ネットワークを介して前記サーバから前記データ記録方式指定プログラムを取得し、これを前記リムーバブルメディアに記録するクライアント端末と；を有する構成（第８の構成）とされている。

本発明に係るドライブレコーダであれば、ユーザの身近に存在する再生機器を用いて運転状況データを確認することが可能となる。

本発明に係るドライブレコーダを用いた交通情報システムの一実施形態を示すブロック図 ドライブレコーダ（条件付格納仕様）で実行される動作のフローチャート ドライブレコーダ（常時格納仕様）で実行される動作のフローチャート 交通事故に関する情報の共有サービスを説明するための模式図 運転状況の一例を示すタイムチャート 運転状況データの一例を示すテーブル 不揮発的に格納された運転状況データの上書禁止操作を示すフローチャート 本発明に係るドライブレコーダのシステムブロック図 バスインタフェイス回路の一構成例（シリアル入出力）を示す回路図 インタフェイス電圧ＶＤＤ１、ＶＤＤ２の設定範囲を示す図 加速度データＧ（ｔ）を示すタイムチャート 絶対差分値｜Ｘ（ｔ）｜を示すタイムチャート 移動平均値Ｙ１（ｔ）、Ｙ２（ｔ）を示すタイムチャート 絶対移動平均差分値｜Ｙ（ｔ）｜を示すタイムチャート 移動平均値Ｙ１（ｔ）、Ｙ２（ｔ）の算出手法を説明するための模式図 移動平均期間の設定根拠を説明するためのタイムチャート トリガ判定回路の一構成例を示すブロック図 トリガ判定動作を説明するためのフローチャート データ記録方式の切替機能を備えたドライブレコーダの一構成例を示すブロック図 データ記録方式の一例を示すテーブル 運転挙動データが重畳された再生映像の一例を示す模式図

（ドライブレコーダを用いた交通情報システム）
図１は、本発明に係るドライブレコーダを用いた交通情報システムの一実施形態を示すブロック図である。

図１に示すように、本実施形態の交通情報システムは、ドライブレコーダ１と、携帯電話端末２と、電子制御ユニット３（以下、ＥＣＵ［Electric Control Unit］３と呼ぶ）と、車載センサ４と、携帯電話回線５と、サーバ６と、を有して成る。

ドライブレコーダ１は、交通事故発生時や危険運転時などに車両の運転状況データ（映像データや走行データなど）を記録する手段である。なお、ドライブレコーダ１の構成及び動作については、後ほど詳細に説明する。

携帯電話端末２は、車両の運転者（または同乗者）によって車室内に持ち込まれるものであり、携帯電話回線５を介して無線による通話や通信を行う基本的な機能のほかに、ドライブレコーダ１との間で有線または無線による相互通信を行う付加機能を備えている。なお、ドライブレコーダ１と携帯電話端末２との連携動作については後ほど詳述する。

ＥＣＵ３は、車両に搭載されて車両各部の動作を制御する手段であり、ＥＣＵ３からドライブレコーダ１には、車両の運転状況データを構成する要素として、車両各部の動作状態データ（ランプ類（ヘッドランプ、テールランプ、ウィンカランプ、ハザードランプなど）の点灯状態データ、ドアロックの開閉状態データ、サイドミラーの開閉状態データ、ワイパーの駆動状態データ、パワーウィンドウの駆動状態データ、エアバックの駆動状態データ、ＡＢＳ［Antilock Brake System］の駆動状態データなど）が伝達される。

車載センサ４は、車両に搭載されて車両各部や車両周辺の状況を検出する手段であり、車両の前後／左右方向に生じる加速度を検出する加速度センサ、車両の鉛直軸周りの回転速度（車両の自転速度）を検出するヨーレートセンサ、車両の走行速度を検出する車速センサ、車輪（タイヤ）の回転速度を検出する車輪速センサ、ステアリングの操舵角を検出する操舵角センサ、ステアリングの操舵トルクを検出する操舵トルクセンサ、ブレーキペダルの踏み込み度合いを検出するブレーキペダルセンサ、車両各部の油圧を検出する油圧センサ、タイヤの空気圧を検出する空気圧センサ、車外気温や車内気温を検出する温度センサ、周囲の明るさを検出する照度センサ、路面状態を検出する路面センサ、車両前後の車間距離を検出する車間距離センサ、車両周辺の障害物を検出する障害物センサ（コーナセンサ）、及び、車両に生じた衝突を検出する衝突センサなどを挙げることができる。なお、車載センサ４からドライブレコーダ１には、車両の運転状況データを構成する要素として、上記の各種検出データが伝達される。

携帯電話回線５は、携帯電話端末２が接続される公衆回線であり、通信事業者によって提供される。

サーバ６は、携帯電話回線５を介して携帯電話端末２との間で通信を行う手段であり、警察や保険会社などに設置される。

（ドライブレコーダの構成及び動作）
次に、ドライブレコーダ１の構成及び動作について詳述する。図１に示したように、ドライブレコーダ１は、制御部１０１と、撮像部１０２と、ＧＰＳ［Global Positioning System］受信部１０３と、加速度センサ１０４と、インタフェイス部１０５と、リアルタイムクロック１０６（以下、ＲＴＣ［Real Time Clock］１０６と呼ぶ）と、記憶部１０７と、通信部１０８と、操作部１０９と、警告部１１０と、を有して成る。

制御部１０１は、ドライブレコーダ１を構成する上記の各機能部１０２〜１１０を統括的に制御する手段であり、ＣＰＵ［Central Processing Unit］のほかに、ＲＯＭ［Read Only Memory］やＲＡＭ［Random Access Memory］などの記憶手段（いずれも不図示）を有して成る。上記のＲＯＭは、ＣＰＵによって実行されるプログラムなどの格納領域として使用される。また、上記のＲＡＭは、ＣＰＵの作業領域として使用されるほか、車両の運転状況データを所定時間分（数秒〜数分）だけ一時的に格納しておくバッファ領域としても使用される。なお、制御部１０１の動作については、後ほど詳細に説明する。

撮像部１０２は、車両周辺（少なくとも車両の前方）を常に動画撮影するカメラ部と、得られた映像データに所定の画像処理（アナログ／デジタル変換処理、ノイズ除去処理、色補正処理、画像圧縮処理など）を施して制御部１０１に出力する画像処理部と、を有して成る（いずれも図示せず）。なお、カメラ部を構成する光電変換素子としては、ＣＣＤ［Charge Coupled Devices］やＣＭＯＳ［Complementary Metal Oxide Semiconductor］を用いればよい。また、撮像部１０２は、車両前方の様子を適切に動画撮影することが可能であって、かつ、運転者の視界を妨げることのない位置（バックミラーの裏面など）に取り付けることが望ましい。このように、車両の運転状況データを構成する要素として、車両周辺を動画撮影した映像データを含めることにより、交通事故の原因究明を迅速かつ適切に行うことが可能となる。

なお、本実施形態では、車両周辺を常に動画撮影する構成を例に挙げたが、本発明の構成はこれに限定されるものではなく、例えば、所定のインターバルで間欠的に動画撮影、ないしは、静止画撮影を行う構成としても構わない。このような構成とすることにより、制御部１０１に搭載されるＲＡＭや記憶部１０７の記憶容量を抑えることが可能となる。

ＧＰＳ受信部１０３は、ＧＰＳ衛星からの衛星信号を利用して車両の現在位置（緯度、経度、高度）を示す車両位置データを制御部１０１に出力する手段である。このように、車両の運転状況データを構成する要素として、車両位置データを含めることにより、交通事故の発生に至る走行経路を事後解析することが可能となる。

加速度センサ１０４は、互いに直交する３軸方向（Ｘ軸方向（＝車両の進行方向）、Ｙ軸方向（＝車両の左右方向）、Ｚ軸方向（＝車両の上下方向））の加速度を各々検出し、これを加速度データとして制御部１０１に出力する手段である。なお、加速度データの検出方式としては、ピエゾ抵抗方式や静電容量方式を用いることができる。このように、車両の運転状況データを構成する要素として、車両の加速度を示す加速度データを含めることにより、交通事故時に生じた車両の衝撃を事後解析することが可能となる。

インタフェイス部１０５は、車両に搭載されたＥＣＵ３から入力される車両各部の動作状態データや車載センサ４から入力される各種の検出データを制御部１０１に出力する手段である。このように、車両の運転状況データを構成する要素として、ドライブレコーダ１本体で得られる情報だけでなく、ドライブレコーダ１の外部（ＥＣＵ３や車載センサ４など、車両自体に搭載されている既存の装備）で得られる情報を含めることにより、ドライブレコーダ１の大型化やコストアップを招くことなく、多くの運転状況データを収集することが可能となる。

ＲＴＣ１０６は、日付と時刻に関する時刻データを生成して制御部１０１に出力する手段である。このように、車両の運転状況データを構成する要素として、日付と時刻を含めることにより、交通事故の発生に至る時間経過を事後解析することが可能となる。

上記したように、本実施形態のドライブレコーダ１において、撮像部１０２、ＧＰＳ受信部１０３、加速度センサ１０４、インタフェイス部１０５、並びに、ＲＴＣ１０６は、いずれも、車両の運転状況データを時系列的に収集するデータ収集部として機能する。ただし、本発明の構成はこれに限定されるものではなく、例えば、ドライブレコーダ１本体に搭載したＧＰＳ受信部１０３や加速度センサ１０４をドライブレコーダ１に外部接続しても構わないし、逆に、ドライブレコーダ１の外部に設けられた車載センサ４の一部をドライブレコーダ１本体に組み込んでも構わない。

記憶部１０７は、所定のトリガ条件（詳細は後述）が満足されたときに、制御部１０１でバッファされている運転状況データを不揮発的に格納する手段であり、フラッシュメモリやＥＥＰＲＯＭ［Electrically Erasable and Programmable Read Only Memory］などの半導体メモリ、若しくは、ハードディスクドライブなど大容量記憶デバイスを用いることができる。なお、記憶部１０７は、運転状況データの可搬性を優先してドライブレコーダ１に着脱可能な構成としてもよいし、逆に、運転状況データの改竄防止を優先して着脱不能な構成としてもよい。また、記憶部１０７に格納される運転状況データの内容についても、上記に限定されるものではなく、事後解析の充実を優先して制御部１０１に入力されるデータを全て格納する構成としてもよいし、逆に、記憶部１０７の容量縮小を優先して制御部１０１に入力されるデータの一部のみを格納する構成としてもよい。また、運転状況データの不正コピー等を防止すべく、記憶部１０７は、上述の運転状況データを暗号化して格納する構成としてもよい。

通信部１０８は、携帯電話端末２との間で有線または無線による相互通信を行う手段である。なお、ドライブレコーダ１と携帯電話端末２との間を有線接続する場合には、ＵＳＢ通信ポートやＵＡＲＴ［Universal Asynchronous Receiver Transmitter］通信ポートなどを用いればよい。また、ドライブレコーダ１と携帯電話端末２との間を無線接続する場合には、赤外線通信ポート（ＩｒＤＡ［Infrared Data Association］通信ポート）やワイヤレスＬＡＮ［Local Area Network］通信ポート（Ｗｉ−Ｆｉ通信ポート）、またはBluetooth（登録商標）通信ポートなどを用いればよい。すなわち、通信部１０８は、携帯電話端末２に搭載されている汎用の通信ポートを介して、携帯電話端末２との相互通信を行う構成とされている。このような構成であれば、携帯電話端末２側にハードウェアの追加や変更を要求することなく、ドライブレコーダ１と携帯電話端末２との相互通信を実現することが可能となる。

操作部１０９は、ユーザ操作を受け付ける手段であり、ボタンやスイッチ、タッチパネルなどを用いて構成される。

警告部１１０は、制御部１０１からの指示に基づき、運転者に対して危険な運転を控えるように警告を発する手段である。なお、上記の警告については、音声や映像（若しくはその組み合わせ）によって行えばよい。このような警告を発する構成であれば、運転者は常に安全運転を心掛けるようになるので、交通事故の抑制に寄与することが可能となる。なお、制御部１０１は、車両の急発進、急ハンドル、急ブレーキ、急シフトチェンジ、夜間の無灯火、方向指示器の操作を伴わない車線変更、蛇行、周囲の車両や建造物との急接近などを検知したときに、警告部１１０に対して上記の警告を発するように指示を送る。また、警告部１１０は、交通事故に関する情報の共有サービスを提供する際に、運転者への注意喚起手段としても用いられるが、これについては後述する。

（運転状況データの格納動作）
次に、制御部１０１による運転状況データの格納動作について詳細に説明する。制御部１０１は、加速度センサ１０４で検出された車両の加速度が所定の閾値を超えたとき（車両に対して所定の閾値を超える衝撃が加わったとき）や、操作部１０４で所定のユーザ操作（交通事故通報ボタンの押下など）が受け付けられたとき、通信部１０８を介して携帯電話端末２からの要求を受け付けたとき、若しくは、警告部１１０による警告が必要と判定されたときに、所定のトリガ条件（不揮発格納条件）が満足されたと判定し、記憶部１０７を制御して運転状況データを格納する。ここで、記憶部１０７に格納される運転状況データは、上記のトリガ条件が満足されたタイミング前後の所定期間（数秒間〜数分間）に、制御部１０１のＲＡＭで一時格納される運転状況データである。

このように、ドライブレコーダ１を車両に搭載しておけば、自責の交通事故や危険運転が記録されてしまうことを嫌い、運転者は常に安全運転を心掛けるようになるので、交通事故の抑制に寄与することが可能となる。また、万一、過失責任のない運転者が交通事故に巻き込まれてしまった場合には、ドライブレコーダ１に記録された運転状況データを事後解析することにより、運転者の正当性を立証することも可能となる。

（ドライブレコーダと携帯電話端末との連携動作）
次に、制御部１０１によるドライブレコーダ１と携帯電話端末２との連携動作について詳細に説明する。

先にも述べた通り、本実施形態のドライブレコーダ１は、携帯電話端末２との間で有線または無線による相互通信を行う通信部１０８を有して成り、制御部１０１は、通信部１０８を制御することにより、携帯電話端末２との間で、先述の運転状況データやドライブレコーダ１の動作設定を行うための動作設定データ（例えば、現在の運転状況データに基づいて交通事故や危険運転が生じたか否かを判定するためのトリガ条件や、制御部１０１で実行されるファームウェア）を送受信する構成とされている。

このような構成とすることにより、パーソナルコンピュータに比べて圧倒的に普及率の高い携帯電話端末２を用いて、ドライブレコーダ１に記録された運転状況データの閲覧や動作設定の確認／変更を行うことができるので、ユーザにとって利便性の高いドライブレコーダ１を提供することが可能となる。

例えば、運転者が交通事故に遭遇した場合、運転者は、自身の携帯電話端末２を用いてドライブレコーダ１に記憶された運転状況データを遅滞なく閲覧することができるので、警察や保険会社に対して迅速かつ正確に現在の状況を通報することが可能となる。

また、相手方の存在する交通事故に巻き込まれた場合であっても、ドライブレコーダ１に記録された運転状況データをその場で閲覧しながら、双方の過失割合を示談交渉することができるので、相手方の一方的な主張に言い負かされて不利を余儀なくされる心配がなくなる。また、過失割合の大きい相手方にとっては、不当な賠償請求が困難となるので、交通マナーの向上や、当たり屋による偽装交通事故の抑制に貢献することも可能となる。

また、本実施形態のドライブレコーダ１において、制御部１０１は、上述のトリガ条件が満足されたと判定した際に、記憶部１０７を制御して運転状況データを格納するとともに、通信部１０８を制御して携帯電話端末２に運転状況データを自動送信する構成とされている。このような構成とすることにより、運転者の操作を何ら要することなく、ドライブレコーダ１に記録された運転状況データが自動的に携帯電話端末２へと送られるので、その閲覧を容易に行うことが可能となる。

また、本実施形態の携帯電話端末２は、ドライブレコーダ１から運転状況データを受信したときに、これを携帯電話回線５経由で所定のサーバ６に転送する転送機能部（図示せず）を有して成る構成とされている。このような構成とすることにより、交通事故が生じたときには、携帯電話端末２が自ら警察や保険会社に交通事故の状況を通報する形となるので、運転者が意識不明の重体や茫然自失の状態に陥っている場合であっても、その通報を遅滞なく完了することが可能となる。また、運転状況データの改竄防止にも繋がる。

また、本実施形態の携帯電話端末２は、所定のユーザ操作を受け付けたときに、ドライブレコーダ１に運転状況データの送信を要求する送信要求機能部（図示せず）を有して成る構成とされている。このような構成とすることにより、携帯電話端末２をあたかもドライブレコーダ１のリモートコントローラのように用いることが可能となる。

また、本実施形態の携帯電話端末２は、サーバ６からの要求に応じて、ドライブレコーダ１に運転状況データの送信を要求する送信要求機能部（図示せず）を有して成る構成とされている。

例えば、ある地点で交通事故が生じたことを認識したサーバ６は、事故現場近傍の基地局エリア内に存在する不特定多数の携帯電話端末２に対して、事故発生時刻と事故現場の位置情報を送信するとともに、各々に連携するドライブレコーダ１で記録された運転状況データを転送するように要求する。この転送要求を受け取った携帯電話端末２は、ドライブレコーダ１に運転状況データの送信を要求し、ドライブレコーダ１から受信した運転状況データを携帯電話回線５経由でサーバ６に転送する。

このような交通情報システムを構築すれば、サーバ６の情報収集能力を高めて、交通事故の事後解析をより正確に実施することが可能となる。

ただし、携帯電話端末２の転送機能部は、上記の転送に先立ち、運転状況データに含まれる時刻データ及び車両位置データと、サーバ６から受信した事故発生時刻及び事故現場の位置情報とを解析し、交通事故の事後解析に際してドライブレコーダ１に記録された運転状況データが有用である可能性が高いと判定した場合、言い換えれば、ドライブレコーダ１に交通事故の様子が記録されている可能性が高いと判定した場合に限り、これをサーバ６に転送する構成としておくことが望ましい。このような構成とすることにより、携帯電話回線５の不必要な通信トラフィックを削減するとともに、交通事故の事後解析を円滑化することが可能となる。

また、携帯電話端末２の送信要求機能部や転送機能部は、ドライブレコーダ１との連携や上記交通情報システムの構築にのみ必要となる特殊な機能部である。そこで、これらの機能部を実現する手段としては、これに必要なハードウェアを追加するのではなく、携帯電話端末２に所定のプログラムをインストールし、これを実行する演算処理部（不図示）をソフトウェア的に送信要求機能部や転送機能部として機能させることが望ましい。このような構成とすることにより、携帯電話端末２側にハードウェアの追加や変更を要求することなく、ドライブレコーダ１と携帯電話端末２との連携や上記交通システムの構築を実現することが可能となる。

（運転状況データの格納動作に関する変形例）
なお、上述したドライブレコーダ１は、トリガ条件が満たされたときに、運転状況データが記憶部１０７へ不揮発的に格納される仕様（以下、便宜的に「条件付格納仕様」と称する）といえる。また、条件付格納仕様のドライブレコーダ１において実行される動作の概要は、図２のフローチャートに示す通りとなる。

すなわちドライブレコーダ１は、運転状況データを収集してバッファ（制御部１０１のＲＡＭ等）へ一時的に格納する動作（ステップＳ１１）、トリガ条件が満足されたかを監視する動作（ステップＳ１２）、および携帯電話端末２から運転状況データの送信要求があったかを監視する動作（ステップＳ１３）を、継続的に実行する。

そして、ドライブレコーダ１は、トリガ条件が満足された場合には（ステップＳ１２のＹ）、バッファに格納されている運転状況データを記憶部１０７へ不揮発的に格納するとともに（ステップＳ１４）、運転状況データを携帯電話端末２へ送信する（ステップＳ１５）。また、ドライブレコーダ１は、携帯電話端末２から運転状況データの送信要求があった場合には（ステップＳ１３のＹ）、運転状況データを携帯電話端末２へ送信する（ステップＳ１５）。当該送信がなされた後は、ステップＳ１１の処理に戻る。

以上に説明した「条件付格納仕様」のドライブレコーダ１によれば、運転状況データを効率よく（トリガ条件が満たされたときにだけ）、記憶部１０７へ格納することが可能である。そのため、運転状況データの記録のための処理負担や、記憶部１０７の記憶容量の増大を極力抑えることが可能である。

一方、ドライブレコーダ１の仕様を、運転状況データが記憶部１０７に（つまり不揮発的に）常時継続的に格納される仕様（以下、便宜的に「常時格納仕様」と称する）とすれば、何らかの原因による運転状況データの記録漏れを、極力防止することが可能である。そのため、ドライブレコーダ１が「条件付格納仕様」である場合に比べて、事故原因などに関する事後解析がより容易となる。

例えば、人や自転車などが車両にごく軽く接触したときには、その時に車両が受ける衝撃が小さ過ぎて、トリガ条件が満たされない（加速度センサの検出値が所定閾値を越えない）可能性がある。この場合、条件付格納仕様のドライブレコーダ１によれば、当該接触が発生した時点での運転状況データが記憶部１０７には格納されない。そのため、通常、当該運転状況データを事後的に確認することは難しくなる。

しかしながら、常時格納仕様のドライブレコーダ１によれば、当該接触が発生した時点での運転状況データも記憶部１０７に格納されるため、当該運転状況データを事後的に確認することが可能となる。その結果、当該運転状況データを事故原因などの事後解析に役立てることが可能となる。なお、例えば各種センサの故障等が発生した場合には、トリガ条件の判定に異常が生じる（よって、実質的にはトリガ条件が満たされていても、トリガ条件が満たされたと判定されなくなる）可能性も否めない。このような事態となっても、常時格納仕様のドライブレコーダ１によれば、運転状況データの記録漏れを未然に防ぐことが可能である。

ドライブレコーダ１を常時格納仕様とする場合には、運転状況データが常時継続的に収集されて、バッファ（制御部１０１のＲＡＭ等）へ一時的に格納されるようにするとともに、トリガ条件が満足されたか否かに関わらず、一時的に格納された運転状況データの全てが、記憶部１０７に転送されて格納されるようにすれば良い。また、ドライブレコーダ１を常時格納仕様とするにあたり、常時継続的に収集された運転状況データが、バッファを介さずに、記憶部１０７へ直接格納されるようにしても構わない。いずれのようにしても、ドライブレコーダ１の動作中において（例えば、ドライブレコーダ１の電源スイッチがオンの状態において）、運転状況データは常時継続的に収集された上で、記憶部１０７へ不揮発的に格納される。

なお、運転状況データの記憶部１０７への格納処理においては、例えば記憶部１０７における運転状況データの格納領域が飽和した段階で、最も古いデータの格納領域に、新たなデータが上書きされるようになっていても良い。このようにすれば、運転状況データの格納領域の不足が回避されるとともに、重要度の高い新たなデータを、優先的に残すことが可能となる。

また、常時格納仕様のドライブレコーダ１では、運転状況データの記憶部１０７への格納動作は、基本的に常時継続的に実行されることになるが、念のために当該動作を停止させる手段（例えば、動作を停止させるためのスイッチ）が設けられていても構わない。また、一部の種類の運転状況データのみが記憶部１０７へ常時格納されるようにしても構わない。

例えば、各運転状況データのうち、撮像部１０２によって取得された映像データのみが記憶部１０７へ常時継続的に格納されるようにし、他の運転状況データについては、トリガ条件が満たされた場合にだけ記憶部１０７へ格納されるようにしても構わない。このような構成によれば、トリガ条件が満たされなかった場合等における、映像の撮り逃しが防止されるとともに、記憶部１０７へのデータ格納に係る処理負担の増大等を極力抑えることが可能となる。

なお、撮像部１０２は、車両周辺の映像データの代わりに、或いは車両周辺の映像データに加えて、車両の内部の映像データを取得するようになっていても良い。このようにすれば、車両内部の映像データを記憶部１０７に格納させることが可能となる。その結果、例えば、タクシーの車内において運転手と客の間でトラブルが発生したような場合であっても、この状況を事後的に確認することが可能となる。また、撮像部１０２においては、車両の内部や外部に複数のカメラ部（撮像装置）が設置されるようにし、車両の周辺や内部の映像が、様々な位置や角度から取得可能となっていても良い。

また、常時格納仕様のドライブレコーダ１において実行される動作の概要は、図３のフローチャートに示す通りとなる。

すなわち、ドライブレコーダ１は、運転状況データを収集して記憶部１０７へ不揮発的に格納する動作（ステップＳ２１）、トリガ条件が満足されたかを監視する動作（ステップＳ２２）、および携帯電話端末２から運転状況データの送信要求があったかを監視する動作（ステップＳ２３）を、継続的に実行する。

そして、ドライブレコーダ１は、トリガ条件が満足された場合（ステップＳ２２のＹ）や、携帯電話端末２から運転状況データの送信要求があった場合（ステップＳ２３のＹ）には、運転状況データを携帯電話端末２へ送信する（ステップＳ２４）。当該送信がなされた後は、ステップＳ２１の処理に戻る。

なお、ドライブレコーダ１の仕様は、例えば、ユーザの指示（操作部１０９の操作等）に応じて、条件付格納仕様と常時格納仕様のいずれにも設定可能（切替可能）となっていても構わない。このようにすれば、ドライブレコーダ１の利便性をより向上させることが可能である。また、ドライブレコーダ１において扱われる運転状況データとしては、以上までに具体的に示したものの他、運転に関わる状況（例えば、車両が運転されているか否か、どのように運転されているか等）を示す種々のデータを採用することが可能である。

以上に説明した通り、常時格納仕様のドライブレコーダ１は、車両の運転状況データを収集して不揮発的に格納する機能部（データ収集格納部）と、携帯電話端末２との間で、有線または無線による相互通信を行う機能部（通信部）と、これらの各機能部を統括的に制御する機能部（制御部）と、を有して成り、制御部は、携帯電話端末２との間で運転状況データや動作設定データを送受信するように、通信部を制御するとともに、運転状況データを常時継続的に収集して格納するように、データ収集格納部を制御する。

そのため、当該ドライブレコーダ１によれば、携帯電話端末２を用いて、運転状況データの閲覧や動作設定の確認／変更を行い得るようにすることが容易となるため、このようにして、ユーザにとっての利便性を向上させ得るものとなっている。また、運転状況データは常時継続的に収集されて不揮発的に格納されるから、運転状況データの記録漏れを極力回避することが可能となっている。

（交通事故に関する情報の共有サービス）
次に、サーバ６を主体とした交通事故に関する情報の共有サービスについて、図４を参照しながら詳述する。図４に示したように、上記機能を主体的に実現するサーバ６は、通信部６１と、情報管理部６２と、情報解析部６３と、情報格納部６４と、を有して成る。

通信部６１は、携帯電話回線５を介して携帯電話端末２との通信を行うとともに、その他の回線７（専用回線やインターネットなど）を介して交通センターサーバ８、警察サーバ９、及び、保険会社サーバ１０との通信を行う。

情報管理部６２は、交通事故を起こした車両に搭載されているドライブレコーダ１から携帯電話端末２を介して転送されてくる運転状況データや、この運転状況データを解析して生成される交通事故データ（交通事故の発生地点や発生時刻など）、及び、複数の交通事故データを累積的に解析して生成される交通事故累積データ（交通事故の多発地点や多発時間帯など）を管理（取得、解析、格納、送信を含む）する。

情報解析部６３は、交通事故を起こした車両に搭載されているドライブレコーダ１から携帯電話端末２を介して転送されてくる運転状況データを解析して、上記の交通事故データを生成する。また、情報解析部６３は、複数の交通事故データを累積的に解析して、上記の交通事故累積データを生成する。

情報格納部６４は、上記の運転状況データ、交通事故データ、及び、交通事故累積データを不揮発的に格納する。

なお、サーバ６は、交通センターサーバ８、警察サーバ９、及び、保険会社サーバ１０と連携して、交通事故に関する情報（上記の運転状況データ、交通事故データ、及び、交通事故累積データを含む）を相互に利用可能な構成とすることが望ましい。このような構成とすることにより、交通事故に関する情報の充実化（把握している交通事故の母数増）やサーバ能力の分散化を実現することが可能となる。

上記構成から成るサーバ６は、携帯電話端末２からの要求に応じて、最新の交通事故累積データを送信する。携帯電話端末２は、サーバ６からの受信内容をドライブレコーダ１に転送する。このとき、ドライブレコーダ１と携帯電話端末２との通信が不可能な場合には、携帯電話端末２の不揮発性記憶部にサーバ６からの受信内容が一旦格納され、ドライブレコーダ１との通信が可能となったときに、改めて携帯電話端末２から最新の交通事故累積データがドライブレコーダ１に転送される。

携帯電話端末２からの転送を受けたドライブレコーダ１において、制御部１０１は、記憶部１０７に格納されている古い交通事故累積データを更新し、以後、最新の交通事故累積データに基づいて、運転者に対する注意喚起を行うように警告部１１０を制御する。例えば、交通事故累積データとして、事故多発地点に関する情報が含まれている場合には、その事故多発地点に近付いている車両の運転者に対して注意喚起が行われる。この注意喚起としては、事故多発地点である旨を音声で報知してもよいし、或いは、車両に別途搭載されているカーナビゲーションシステムのモニタを流用し、地図画面に事故多発地点を示すマーキング（アイコン表示など）を行ってもよい。

なお、交通事故累積データには、事故多発地点に関する情報のほかにも、事故多発時間帯や事故原因などの付随情報を含めておくことが望ましい。例えば、ある事故多発地点の付随情報として、「出会い頭の衝突が多い」というフラグが立てられていた場合には、上記の注意喚起として、周囲の安全確認を徹底すべきである旨の警告を事前に行うことが可能となり、また、「カーブでの速度超過によるセンターラインオーバー」というフラグが立てられていた場合には、上記の注意喚起として、カーブ進入時は十分に減速すべきである旨の警告を事前に行うことが可能となる。ただし、このような付随情報を含めるためには、交通事故を起こした車両に搭載されているドライブレコーダ１からの運転状況データを解析するだけでは不十分であることが多いため、先にも述べたように、交通センターサーバ８、警察サーバ９、及び、保険会社サーバ１０と連携して、交通事故に関する情報を相互に利用可能な構成としておくことが望ましい。

このように、サーバ６を主体として、交通事故に関する情報の共有サービスを提供する交通情報システムであれば、交通事故を未然に防止する手段として、ドライブレコーダ１を積極的に活用することができるので、ドライブレコーダ購入のインセンティブとなり、延いては、交通安全の促進に大きく寄与することが可能となる。

なお、上記では、携帯電話端末２からの要求に応じて、サーバ６から最新の交通事故累積データを送信する構成を例に挙げて説明を行ったが、本発明の構成はこれに限定されるものではなく、例えば、交通事故に関する情報の共有サービス提供先として事前登録されている携帯電話端末２に対して、サーバ６から定期的（例えば毎月１回）に最新の交通事故累積データを送信する構成としてもよい。このような構成であれば、ドライブレコーダ１に格納されている交通事故累積データを常に最新の内容に維持することが可能となる。

また、上記では、携帯電話端末２に対して交通事故累積データを送信する構成を例に挙げて説明を行ったが、本発明の構成はこれに限定されるものではなく、例えば、交通事故を起こした車両からサーバ６に運転状況データが転送された時点で、事故発生地点近傍の基地局エリア内に存在する不特定多数の携帯電話端末２に対して、上記の運転状況データのうち、少なくとも事故発生地点の位置情報を速やかに送信する構成としてもよい。このような構成とすることにより、事故発生地点に近付いている車両の運転者は、自車の進路上で交通事故が発生したことをほぼリアルタイムに知ることができるので、迂回ルートを探索するなどして、交通渋滞や二次的な交通事故を未然に回避することが可能となる。

（燃費向上運転の判定サービス）
次に、サーバ６を主体とした燃費向上運転の判定サービスについて、図５と図６を参照しながら詳述する。図５は、運転状況の一例を示すタイムチャートであり、横軸は時間、縦軸は車両の速度を表している。また、図６は、図５の運転状況下で記録される運転状況データの一例を示すデータテーブルであり、特に、燃費向上運転の判定サービスに必要なパラメータ（図６では、日時（ｔｉ）、車両の位置（Ｐ（ｔｉ）、速度Ｖ（ｔｉ）、加速度Ａ（ｔｉ）、及び、エンジンの回転数Ｒ（ｔｉ）、ただし、ｉ＝０〜１４）が記載されている。

なお、図６に記載されている一連のパラメータについては、ドライブレコーダ１が先述の「条件付格納仕様」であるか「常時格納仕様」であるかに依ることなく、エンジンが始動されてから停止されるまでの間（すなわち、ドライブレコーダ１が駆動されている間）に収集された全ての計測値が破棄されることなく不揮発性の記憶部１０７に格納される。一方、交通事故の事後解析に必要な運転状況データについては、先述したように、事故発生タイミングの前後数秒〜数分間に収集されたデータのみが不揮発性の記憶部１０７に格納され、それよりも古いデータは順次破棄される。このように、運転状況データのうち、燃費向上運転の判定サービスに必要なパラメータについては、その計測値を長期間（例えば２４時間）にわたって保持しなければならないが、燃費向上運転の判定サービスに必要なパラメータには、撮像部１０２で収集される撮像データが含まれていないため、記憶部１０７の記憶容量を不要に圧迫する心配はない。

時刻ｔ０においてエンジンが始動されると、ドライブレコーダ１による運転状況データの収集及び格納が開始される。なお、運転状況データを収集する時間間隔は、分析精度とデータ容量とのバランスを考えて、適切な値（例えば０．５秒毎）に設定すればよい。時刻ｔ０〜時刻ｔ１は、アイドリング期間である。時刻ｔ１〜時刻ｔ２は、加速走行期間である。時刻ｔ２〜時刻ｔ３は、定速走行期間である。時刻ｔ３〜時刻ｔ４は、減速走行期間である。そして、時刻ｔ４においてエンジンが停止されると、ドライブレコーダ１による運転状況の収集及び格納が終了される。

時刻ｔ５において再びエンジンが始動されると、ドライブレコーダ１による運転状況データの収集及び格納が再開される。時刻ｔ５〜時刻ｔ６は、アイドリング期間である。時刻ｔ６〜ｔ７は、加速走行期間である。時刻ｔ７〜時刻ｔ８は、定速走行期間である。時刻ｔ８〜ｔ１０は、加速走行期間である。時刻ｔ１０〜時刻ｔ１１は、定速走行期間である。時刻ｔ１１〜時刻ｔ１４は、減速走行期間である。そして、時刻ｔ１４においてエンジンが停止されると、ドライブレコーダ１による運転状況の収集及び格納が終了される。

その後、運転者が携帯電話端末２を用いて運転状況データの転送操作を行うと、記憶部１０７に格納されている運転状況データが携帯電話端末２経由でサーバ６に転送される。サーバ６では、携帯電話端末２から受信した運転状況データの解析が行われ、運転内容の燃費向上性に関する判定処理が行われた後に、その判定結果が携帯電話端末２に送信される。なお、上記の判定結果は、電子メールの本文に記載してもよいし、或いは、判定結果が記載されているＵＲＬ［Uniform Resource Locator］を通知してもよい。

上記した燃費向上性に関する判定について、より具体的に説明する。不必要に燃料を浪費する運転操作の一例としては、速度の上げ過ぎ、急激な加速、急激な減速、及び、回転数の上げ過ぎ（空ぶかしを含む）など（以下、これらをまとめて「非効率運転」と呼ぶ）を挙げることができる。そこで、サーバ６は、１回の走行時間（図５及び図６では、時刻ｔ０時刻ｔ４と時刻ｔ５〜時刻ｔ１４との合算時間）のうち、上記の非効率運転を行っている時間が占める割合を算出し、その算出値に基づいて、運転者に対する燃費向上運転の啓発や提案を行う構成とされている。

すなわち、サーバ６では、燃費向上性に関する判定に際して、速度Ｖ（ｔｉ）が所定の上限値Ｖｔｈを上回っていないか、加速度Ａ（ｔｉ）が所定の上限値Ａｔｈ＋を上回っていないか、加速度Ａ（ｔｉ）が所定の下限値Ａｔｈ−を下回っていないか、及び、回転数Ｒ（ｔｉ）が所定の上限値Ｒｔｈを上回っていないかがチェックされ、上記に該当した判定項目が一つでもあれば、その時刻ｔｉに非効率運転が行われていたと判定される。

図５及び図６に例示した運転状況に即して具体的に説明する。ただし、説明を簡単とするため、以下の説明では、回転数Ｒ（ｔｉ）を不問とし、速度Ｖ（ｔｉ）と加速度Ａ（ｔｉ）に基づいて、燃費向上性に関する判定を行うものとする。

速度超過の判定に関しては、速度Ｖ（ｔ９）〜速度Ｖ（ｔ１２）が所定の上限値Ｖｔｈを上回っていると判定され、時刻ｔ９〜時刻ｔ１２が非効率運転期間（速度超過期間）としてカウントされる。また、急加速の判定に関しては、加速度Ａ（ｔ６）〜加速度Ａ（ｔ７）が所定の上限値Ａｔｈ＋を上回っていると判定され、時刻ｔ６〜時刻ｔ７が非効率運転期間（急加速期間）としてカウントされる。また、急減速の判定に関しては、加速度Ａ（ｔ１１）〜加速度Ａ（ｔ１３）が所定の下限値Ａｔｈ−を下回っていると判定され、時刻ｔ１１〜時刻ｔ１３が非効率運転期間（急減速期間）としてカウントされる。ただし、時刻ｔ１１〜時刻ｔ１２は、速度超過期間であり、かつ、急減速期間であるため、重複したカウントが行われることはない。

上記判定処理の終了後、サーバ６では、運転者に通知すべき判定結果のデータ作成が行われる。なお、判定結果の通知内容としては、例えば、１回の走行に占める非効率運転の割合に基づいて燃費向上運転の達成度を点数表示してもよいし、或いは、運転内容の内訳（例えば、燃費向上運転期間：Ａ％、アイドリング期間：Ｂ％、非効率運転期間Ｃ％（速度超過期間：ａ％、急加速期間：ｂ％、急減速期間：ｃ％））を表示してもよい。また、今回の走行中で最も燃費の悪化を招いたと思われる運転操作（例えば速度超過）を指摘して、これを改めるようにアドバイスを表示することも有効である。なお、当然のことながら、サーバ６から受信した燃費向上運転の判定結果を運転者に報知するための手段としては、携帯電話端末２に搭載されている表示部（液晶表示パネルなど）を流用すればよい。

このように、サーバ６を主体として、燃費向上運転の判定サービスを提供する交通情報システムであれば、運転者が燃費向上運転を習得・実践・継続するための補助的手段として、ドライブレコーダ１を積極的に活用することができるので、ドライブレコーダ購入のインセンティブとなり、延いては、環境保全の促進に大きく寄与することが可能となる。

また、運転状況データの詳細な解析をドライブレコーダ１側ではなくサーバ６側で行う構成であれば、ドライブレコーダ１の情報処理能力を不要に高める必要がないので、装置の大型化やコストアップを招かずに済む。

なお、サーバ６は燃費向上運転の判定結果を累積的に格納しておく構成とすればよい。このような構成とすることにより、１回の走行毎に燃費向上運転の達成度を前回走行時と比較したり、或いは、燃費向上運転の達成度を所定の集計期間に亘って平均化するなどして、より継続的な分析を行うことができるようになるので、燃費向上運転の技量がどのように推移しているかを報知し、運転者のモチベーションを高めることが可能となる。

また、図５及び図６の例示においては、時刻ｔ０〜時刻ｔ１、及び、時刻ｔ５〜時刻ｔ６がいずれもアイドリング期間であり、速度Ｖ（ｔｉ）及び加速度Ａ（ｔｉ）は共にゼロ値であるため、上記の判断項目に照らせば、これらの期間が非効率運転期間としてカウントされることはない。ただし、アイドリング期間が長過ぎる場合には、不必要に燃料を浪費することになるため、これを非効率運転として判定するように、燃費向上性に関する判定のアルゴリズムを適宜変更しても構わない。

また、上記では、説明を簡単にするために、回転数Ｒ（ｔｉ）を不問としたほか、その他の判定項目についても特段の言及は行わなかったが、燃費向上性に関する判定をより詳しく行うためには、例えば、速度Ｖ（ｔｉ）の揺らぎ（加速／減速の繰り返し）が生じているか否かを判定項目に加えることが望ましい。

また、速度Ｖ（ｔｉ）の上限値Ｖｔｈ、加速度Ａ（ｔｉ）の上限値Ａｔｈ＋及び下限値Ａｔｈ−、並びに、回転数Ｒ（ｔｉ）の上限値Ｒｔｈについては、平地走行時と坂道走行時との違い、ないしは、一般道走行時と高速道走行時との違いなど、走行状態を考慮に入れて適宜調整することが望ましい。このような閾値の調整を行う場合には、ドライブレコーダ１からサーバ６に転送される運転状況データとして、車両の位置Ｐ（ｔｉ）に関する情報を含めておく必要がある。

また、上記では、ドライブレコーダ１で収集される運転状況データのうち、燃費向上運転の判定サービスに必要なパラメータとして、日時（ｔｉ）、車両の位置（Ｐ（ｔｉ）、速度Ｖ（ｔｉ）、加速度Ａ（ｔｉ）、及び、エンジンの回転数Ｒ（ｔｉ）を選定し、これらのパラメータを時刻ｔ０〜時刻ｔ４、及び、時刻ｔ５〜時刻ｔ１４にわたって継続的に計測・格納した上で、その格納内容を全てドライブレコーダ１からサーバ６に転送する構成を例に挙げて説明を行ったが、本発明の構成はこれに限定されるものではなく、記憶部１０７の容量削減や携帯電話端末２の通信データ削減（延いては通信費用の削減）を優先するのであれば、図６中のハッチング部分で示したように、エンジンの始動時と停止時、及び、非効率運転時にのみ、上記のパラメータを記憶部１０７に格納し、その格納内容をサーバ６に転送する構成にするとよい。このような構成を採用する場合には、ドライブレコーダ１側で非効率運転の判定（速度超過判定、急加速判定、急減速判定、回転数超過判定など）を行わねばならないが、そのためには各パラメータと所定の閾値を比較すれば足りるので、ドライブレコーダ１の情報処理能力を不必要に高める必要はない。

（運転状況データの上書き禁止操作）
次に、記憶部１０７で不揮発的に格納された運転状況データの上書き禁止操作について詳細に説明する。

本実施形態のドライブレコーダ１では、記憶部１０７の容量に応じて、不揮発的に記憶しておける運転状況データのファイル数に上限値（例えば、センサトリガによる記憶ファイル数１０件と、マニュアル操作トリガによる記憶ファイル数１０件）があり、不揮発的に記憶されている運転状況データのファイル数が上限値に達した後、さらに新たな運転状況データのファイルを不揮発的に記憶する場合には、最も古い運転状況データのファイルが上書きされる。この点については、従前のドライブレコーダと同様である。

ただし、本実施形態のドライブレコーダ１では、不揮発的に記憶された運転状況データの各ファイル毎に、「上書許可属性」と「上書禁止属性」のいずれかを付与することが可能とされている。なお、記憶部１０７へ不揮発的に記憶された運転状況データの各ファイルには、デフォルト属性として「上書許可属性」が付与される。従って、意図的に「上書禁止属性」を付与しない限り、その運転状況データは、いずれ新たなファイルに上書きされて利用することができなくなる。一方、意図的に「上書禁止属性」が付与されたファイルについては、新たなファイルによる上書き対象から除外されるため、そのファイルが記憶部１０７に格納されている最も古いファイルであったとしても、新たなファイルによって上書きされることはないので、ユーザがそのファイルを意図的に削除しない限り、いつでも運転状況データの内容を確認することが可能となる。

例えば、自動車の運転中に軽微な接触事故が発生したため、念のためにマニュアル操作で運転状況データを不揮発的に記憶したが、その時点では、自己にも相手にも特段の問題がない様子であったため、不揮発的に記憶された運転状況データを確認して交渉することはしなかったものの、後日、自車の破損を発見したので相手に補償を求めたくなった場合や、逆に、相手から補償を求められる場合もあり得る。このような場合、事故発生時点で念のために格納しておいた運転状況データのファイルに「上書禁止属性」を付与しておけば、以後、その格納ファイルが上書きによって消失することはないので、後日、必要に応じて事故発生時の運転状況データを確認することが可能となり、延いては、相手との間で適切な交渉を行うことが可能となる。

図７は、不揮発的に格納された運転状況データの上書禁止操作を示すフローチャートである。

まず、ステップＳ３１では、先に説明した所定のトリガ条件が満足されたか否かの判定が行われる。ここで、所定のトリガ条件が満足されたと判定された場合（例えば、車両に過大な衝撃が生じた場合や、ユーザによる運転状況データのマニュアル格納操作が行われた場合）には、フローが続くステップＳ３２に進められる。一方、所定のトリガ条件が満足されたと判定されなかった場合には、フローがステップＳ３１に戻されて、上記のトリガ条件判定処理が継続される。

ステップＳ３１において、所定のトリガ条件が満足されたと判定された場合、ステップＳ３２では、その時点で収集されている運転状況データが記憶部１０７へ不揮発的に格納される。このとき、運転状況データの格納ファイルには、デフォルト属性として「上書許可属性」が付与される。なお、「上書許可属性」については、必ずしも積極的にそのような専用のフラグを設けておく必要はなく、「上書禁止属性」が付与されていないことをもって、「上書き許可属性」が付与されていると見なすことができる。

続くステップＳ３３では、上書き禁止操作の受付けに関するメッセージの報知が行われる。この報知としては、例えば、「ただいま、運転状況データを格納しました。この格納ファイルの上書きを禁止したい場合には、本体の上書き禁止ボタンを押して下さい。」といった音声アナウンスを行うマイクを設けてもよいし、或いは、上書き禁止操作の受付タイミングである旨を報知するためのランプを設けておき、これを点灯ないし点滅させる構成としてもよい。このような報知を行う構成であれば、ユーザは、運転状況データが不揮発的に格納された時点で遅滞なく、その格納ファイルに「上書禁止属性」を付与するか否かを判断することが可能となる。

ただし、ステップＳ３３におけるメッセージの報知は、必ずしも必須のステップではなく、例えば、運転状況データの格納処理中に点灯ないし点滅されるランプがドライブレコーダ１に設けられている場合には、その点灯ないし点滅をもって上記の報知に代えてもよいし、或いは、全く上記の報知を行わなくても構わない。このような構成とすることにより、ドライブレコーダ１の本体には、何ら構成要素を追加せずに済む。

続くステップＳ３４では、ユーザが上書き禁止操作を行ったか否かの判定が行われる。ここで、ユーザが上書き禁止操作を行ったと判定された場合には、フローがステップＳ３５に進められる。一方、ユーザが上書き禁止操作を行ったと判定されなかった場合には、フローがステップＳ３６に進められる。

なお、上記の上書き禁止操作としては、例えば、上書き禁止操作専用ボタンの押下を検出してもよいし、或いは、運転状況データの格納処理中におけるマニュアル格納用ボタンの押下を検出してもよい。

後者の構成について、例えば、車両に過大な衝撃が生じたり、或いは、ユーザがマニュアル格納用ボタンを押下すると、ステップＳ３１において、所定のトリガ条件が満足されたと判定され、ステップＳ３２において、その時点で収集されている運転状況データが記憶部１０７に格納されるが、その格納処理が行われている最中に、ステップＳ３４において、ユーザがマニュアル格納用ボタンを押下したことが検出された場合には、これを上書き禁止操作として認識すればよい。このような構成とすることにより、ドライブレコーダ１の本体には、何ら構成要素を追加することなく、制御部１０１を動作させるためのソフトウェアを一部書き換えるだけで、上書き禁止操作を受け付けることが可能となる。

ステップＳ３４において、ユーザが上書き禁止操作を行ったと判定された場合、ステップＳ３５では、記憶部１０７に格納された運転状況データのファイルに「上書禁止属性」が付与されて、一連のフローが終了される。このような「上書禁止属性」が付与されたファイルについては、新たなファイルによる上書き対象から除外されるため、ユーザがそのファイルを意図的に削除しない限り、いつでも運転状況データの内容を確認することが可能となる。

一方、ステップＳ３４において、ユーザが上書き禁止操作を行ったと判定されなかった場合、ステップＳ３６では上書き禁止操作の受付終了条件が満足されたか否かの判定が行われる。ここで、所定の受付終了条件が満足されたと判定された場合には、記憶部１０７に格納された運転状況データのファイルに「上書禁止属性」が付与されることなく、デフォルト属性である「上書許可属性」が付与されたまま一連のフローが終了される。一方、所定の受付終了条件が満足されたと判定されなかった場合には、フローがステップＳ３４に戻されて、ユーザによる上書き禁止操作の有無判定が継続される。

なお、上記の受付終了条件としては、例えば、ステップＳ３１とは別に、所定のトリガ条件が満足されたか否か、すなわち、別の運転状況データを不揮発的に格納する必要が生じたか否かを検出すればよい。この場合、一の運転状況データが不揮発的に格納されてから、別の運転状況データを不揮発的に格納する必要が生じるまでは、直近の運転状況データに「上書禁止属性」を付与することが可能である。

また、上記の受付終了条件としては、例えば、ステップＳ３１でトリガ条件が満足されてから所定時間（例えば数分〜数時間）が経過したか否かを検出してもよい。この場合、一の運転状況データが不揮発的に格納されてから、所定時間が経過するまでは、その運転状況データに「上書禁止属性」を付与することが可能である。

また、上記の受付終了条件としては、例えば、ドライブレコーダ１への電力供給が遮断されたか否かを検出してもよい。この場合、一の運転状況データが不揮発的に格納されてから、ドライブレコーダ１への電力供給が遮断されるまで、一般には、車両が停止されてイグニッションキーがオフとされるまでは、その運転状況データに「上書禁止属性」を付与することが可能である。

また、上記の受付終了条件としては、例えば、ステップＳ３２における記憶部１０７への格納処理が完了したか否かを検出してもよい。この場合、一の運転状況データに「上書禁止属性」を付与することができるタイミングは、記憶部１０７への格納処理中に限定される。なお、この受付終了条件を採用する場合には、運転状況データの格納処理中に点灯されるランプをドライブレコーダ１に設けておき、当該ランプの点灯をもってステップＳ３３におけるメッセージの報知とすることが望ましい。

なお、運転状況データに「上書き禁止属性」を付与するタイミングについては、記録画像を再生するときでも構わない。

（ドライブレコーダのシステム構成）
図８は、本発明に係るドライブレコーダのシステムブロック図である。本構成例のドライブレコーダは、交通事故発生時や危険運転時などに車両の運転状況データ（映像データや走行データなど）を記録する手段として用いられるものであり、画像音声処理ＬＳＩ２００と、カメラ２０１と、リアルタイムクロック２０２（以下では、ＲＴＣ［Real Time Clock］２０２と呼ぶ）と、ＥＥＰＲＯＭ２０３と、加速度センサ２０４と、ＧＰＳ［Global Positioning System］モジュール２０５と、スピーカ２０６と、マイク２０７と、オーディオコーデック２０８と、基本プログラム格納メモリ２０９と、テレビモニタ２１０と、ＳＤカード２１１と、拡張プログラム格納メモリ２１２と、オプションカメラ２１３と、画像処理ＩＣ２１４と、ＩｒＤＡ［Infrared Data Association］コントローラＩＣ２１５と、ＩｒＤＡモジュール２１６と、を有して成る。

また、本構成例のドライブレコーダは、その電源系として、降圧レギュレータ（電源ＩＣ）２２０と、ダイオード２２１〜２２３と、抵抗２２４と、二次電池２２５と、降圧レギュレータ（ＬＤＯ［Low DropOut］レギュレータ）２３０〜２３２と、を有して成る。

画像音声処理ＬＳＩ２００は、ドライブレコーダ全体の動作を統括的に制御するためのコントローラである。なお、画像音声処理ＬＳＩ２００には、車両に搭載されているＥＣＵ［Electric Control Unit］（不図示）から車両各部の動作状態データ（ランプ類（ヘッドランプ、テールランプ、ウィンカランプ、ハザードランプなど）の点灯状態データ、ドアロックの開閉状態データ、サイドミラーの開閉状態データ、ワイパーの駆動状態データ、パワーウィンドウの駆動状態データ、エアバックの駆動状態データ、ＡＢＳ［Antilock Brake System］の駆動状態データなど）が伝達される。

また、車両には、車両各部や車両周辺の状況を検出する種々の車載センサ（不図示）が搭載されており、画像処理ＬＳＩ２００には、これらの車載センサで得られる各種検出データも伝達される。なお、車載センサの一例としては、車両の前後／左右方向に生じる加速度を検出する加速度センサ、車両の鉛直軸周りの回転速度（車両の自転速度）を検出するヨーレートセンサ、車両の走行速度を検出する車速センサ、車輪（タイヤ）の回転速度を検出する車輪速センサ、ステアリングの操舵角を検出する操舵角センサ、ステアリングの操舵トルクを検出する操舵トルクセンサ、ブレーキペダルの踏み込み度合いを検出するブレーキペダルセンサ、車両各部の油圧を検出する油圧センサ、タイヤの空気圧を検出する空気圧センサ、車外気温や車内気温を検出する温度センサ、周囲の明るさを検出する照度センサ、路面状態を検出する路面センサ、車両前後の車間距離を検出する車間距離センサ、車両周辺の障害物を検出する障害物センサ（コーナセンサ）、及び、車両に生じた衝突を検出する衝突センサなどを挙げることができる。

カメラ２０１は、車両周辺（主に車両前方）を撮影する外部デバイス（２．８Ｖ駆動）であり、２線式シリアルバスＩ２Ｃ＃１を介して、画像音声処理ＬＳＩ２００と接続されている。カメラ２０１を構成する光電変換素子としては、ＣＣＤ［Charge Coupled Devices］やＣＭＯＳ［Complementary Metal Oxide Semiconductor］を用いればよい。カメラ２０１は、車両前方の様子を適切に動画撮影することが可能であって、かつ、運転者の視界を妨げることのない位置（バックミラーの裏面など）に取り付けることが望ましい。カメラ２０１で生成される撮像データは、専用のデータバスを介して画像音声処理ＬＳＩ２００に出力される。このように、車両の運転状況データを構成する要素として、車両周辺を動画撮影した映像データを含めることにより、交通事故の原因究明を迅速かつ適切に行うことが可能となる。

ＲＴＣ２０２は、日付と時刻に関する時刻データを生成して画像音声処理ＬＳＩ２００に出力する外部デバイス（３．３Ｖ駆動）であり、２線式シリアルバスＩ２Ｃ＃２を介して、画像音声処理ＬＳＩ２００と接続されている。このように、車両の運転状況データを構成する要素として、日付と時刻を含めることにより、交通事故の発生に至る時間経過を事後解析することが可能となる。

ＥＥＰＲＯＭ２０３は、所定のトリガ条件が満足されたときに、画像音声処理ＬＳＩ２００でバッファされている運転状況データを不揮発的に格納する外部デバイス（３．３Ｖ駆動）であり、２線式シリアルバスＩ２Ｃ＃２を介して、画像音声処理ＬＳＩ２００と接続されている。

例えば、画像音声処理ＬＳＩ２００は、加速度センサ２０４で検出された車両の加速度変化が所定の閾値を超えたとき（車両に対して所定の閾値を超える衝撃が加わったとき）に、所定のトリガ条件が満足されたと判定し、ＥＥＰＲＯＭ２０３へのアクセスを行い、運転状況データを格納する。ここで、ＥＥＰＲＯＭ２０３に格納される運転状況データは上記のトリガ条件が満足されたタイミング前後の所定期間（数秒間〜数分間）に、画像音声処理ＬＳＩ２００で一時格納される運転状況データである。

２線式シリアルバスＩ２Ｃ＃１は、抵抗Ｒ１を介して、第１インタフェイス電圧ＶＤＤ１（２．８Ｖ）の印加端にプルアップされており、２線式シリアルバスＩ２Ｃ＃２は、抵抗Ｒ２を介して、第２インタフェイス電圧ＶＤＤ２（３．３Ｖ）の印加端にプルアップされている。

このように、画像音声処理ＬＳＩ２００は、接続する外部デバイスの電源電圧に合わせて２系統のシリアルバスを有している。ただし、画像音声処理ＬＳＩ２００の内部において、２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２は１系統として取り扱われる。このような構成とすることにより、電源電圧の異なる複数の外部デバイスを接続する場合であっても、各々の電源電圧に基づいて適切なグループ分けを行い、各グループ（上記では、２．８Ｖ駆動のグループと３．３Ｖ駆動のグループ）を別系統のシリアルバスに接続することにより、ハイレベル電圧の差に起因する電力浪費やノイズ耐性劣化を防ぐことが可能となる。また、上記した構成を採用することにより、画像音声処理ＬＳＩ２００の設計（部品選定、外部デバイスを動作保証範囲内のインタフェイス電圧で使いこなすための電源周りの安定化など）や、ＰＣＢの設計、品質評価の負担を低減することも可能となる。

なお、画像音声処理ＬＳＩ２００は、装置外部に接続された２系統の２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２を装置内部で同一のバスとして取り扱うためのバスインタフェイス回路を内蔵しているが、その構成及び動作については、後ほど詳細に説明する。

加速度センサ２０４は、互いに直交する３軸方向（Ｘ軸方向（＝車両の進行方向）、Ｙ軸方向（＝車両の左右方向）、Ｚ軸方向（＝車両の上下方向））の加速度を各々検出し、これを加速度データとして画像音声処理ＬＳＩ２００に出力する手段である。なお、加速度データの検出方式としては、ピエゾ抵抗方式や静電容量方式を用いることができる。このように、車両の運転状況データを構成する要素として、車両の加速度を示す加速度データを含めることにより、交通事故時に生じた車両の衝撃を事後解析することができる。

ＧＰＳモジュール２０５は、ＧＰＳ衛星からの衛星信号を利用して車両の現在位置（緯度、経度、高度）を検出し、これを車両位置データとして画像音声処理ＬＳＩ２００に出力する手段である。なお、画像音声処理ＬＳＩ２００とＧＰＳモジュール２０５の間は、ＵＡＲＴ［Universal Asynchronous Receiver Transmitter］通信ポートを介して有線で接続されている。このように、車両の運転状況データを構成する要素として、車両位置データを含めることにより、交通事故の発生に至る走行経路を事後解析することができる。

スピーカ２０６及びマイク２０７は、オーディオコーデック２０８を介して、画像音声処理ＬＳＩ２００に接続されている。スピーカ２０６は、例えば、画像音声処理ＬＳＩ２００からの指示に基づいて、運転者に危険な運転を控えるように警告を発する手段として用いられる。なお、上記の警告については、スピーカ２０６による音声のほか、テレビモニタ２１０による映像（若しくはそれらの組み合わせ）によって行えばよい。このような警告を発する構成であれば、運転者は常に安全運転を心掛けるようになるので、交通事故の抑制に寄与することができる。なお、画像音声処理ＬＳＩ２００は、車両の急発進、急ハンドル、急ブレーキ、急シフトチェンジ、夜間の無灯火、方向指示器の操作を伴わない車線変更、蛇行、周囲の車両や建造物との急接近などを検知したときに、スピーカ２０６やテレビモニタ２１０に対して上記の警告を発するように指示を送る。マイク２０７は、例えば、運転者からの音声指示を受け取る手段として用いられる。

基本プログラム格納メモリ２０９は、画像音声処理ＬＳＩ２００の基本動作を実現するためのプログラムやデータを格納する手段であり、例えば、フラッシュメモリ（２Ｍｂｉｔ）などを用いることができる。

テレビモニタ２１０は、例えば、カメラ２０１で得られる車両の周辺映像や、テレビジョン放送の番組映像、或いは、カーナビゲーションシステムの地図情報を表示するための手段であり、液晶ディスプレイなどを用いることができる。

ＳＤメモリ２１１は、ドライブレコーダに着脱可能な外部メモリであり、例えば、ＥＥＰＲＯＭ２０３に格納されている運転状況データを持ち出したり、画像音声処理ＬＳＩ２００の動作プログラムを書き換えたりする際に用いられる。

拡張プログラム格納メモリ２１２、オプションカメラ２１３、画像処理ＩＣ２１４、ＩｒＤＡコントローラＩＣ２１５、及び、ＩｒＤＡモジュール２１６は、いずれも、ドライブレコーダの機能を拡張するためのオプションデバイスであり、いずれもオプションデバイス接続用のパラレルバスを介して、画像音声処理ＬＳＩ２００に接続されている。

拡張プログラム格納メモリ２１２は、基本プログラム格納メモリ２０９に格納しきれなかったプログラムやデータを格納する手段であり、例えば、フラッシュメモリ（２Ｍｂｙｔｅ）を用いることができる。オプションカメラ２１３は、カメラ２０１とは別視点（例えば車両後方）の映像を取得するための手段である。画像処理ＩＣ２１４は、オプションカメラ２１３で得られた映像データに所定の画像処理（アナログ／デジタル変換処理、ノイズ除去処理、色補正処理、画像圧縮処理など）を施して画像音声処理ＬＳＩ２００に出力する手段である。ＩｒＤＡコントローラＩＣ２１５及びＩｒＤＡモジュール２１６は、携帯電話端末やリモートコントローラとの赤外線通信を行う手段である。

降圧レギュレータ２２０は、入力電圧Ｖ１（例えば１２Ｖまたは２４Ｖ）を降圧して出力電圧Ｖ２（例えば５．０Ｖ）を生成する電源ＩＣである。

ダイオード２２１のアノードは、降圧レギュレータ２２０の出力端に接続されている。ダイオード２２１のカソードは、抵抗２２４を介して二次電池２２５の正極に接続されている。ダイオード２２２のアノードは、降圧レギュレータ２２０の出力端に接続されている。ダイオード２２２のカソードは、降圧レギュレータ２３０〜２３２の入力端に接続されている。ダイオード２２３のアノードは、二次電池２２５の正極に接続されている。ダイオード２２３のカソードは、降圧レギュレータ２３０〜２３２の入力端に接続されている。二次電池２２５は、ダイオード２２１及び抵抗２２４を介する充電経路により、出力電圧Ｖ２によって充電され、ダイオード２２３を介する放電経路により、正極から電池電圧Ｖ３が引き出される。降圧レギュレータ２３０〜２３２には、出力電圧Ｖ２と電池電圧Ｖ３のいずれか高い方が供給される。

降圧レギュレータ２３０〜２３２は、それぞれ内部電圧ＶＤＤ０（例えば１．５Ｖ）、第１インタフェイス電圧ＶＤＤ１（例えば２．８Ｖ）、及び、第２インタフェイス電圧ＶＤＤ２（例えば３．３Ｖ）を生成し、これらをドライブレコーダの各部に供給する。

上記構成から成るドライブレコーダを車両に搭載しておけば、自責の交通事故や危険運転が記録されてしまうことを嫌い、運転者は常に安全運転を心掛けるようになるので、交通事故の抑制に寄与することが可能となる。また、万一、過失責任のない運転者が交通事故に巻き込まれてしまった場合には、ドライブレコーダに記録された運転状況データを事後解析することにより、運転者の正当性を立証することも可能となる。

図９は、バスインタフェイス回路の一構成例（シリアル入出力）を示す回路図である。本図に示すように、画像音声処理ＬＳＩ２００は、コントローラ３００と、バスインタフェイス回路４００と、を有して成る。

バスインタフェイス回路４００は、装置外部に接続された２系統の２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２を装置内部で同一のバスとして取り扱うための双方向バスマルチプレクサであり、Ｎチャネル型ＭＯＳ電界効果トランジスタ４０１と、Ｎチャネル型ＭＯＳ電界効果トランジスタ４０２と、レベルシフタ４１１〜４１３と、レベルシフタ４２１〜４２３と、論理積演算器４３０と、を有して成る。

トランジスタ４０１のドレインは、２線式シリアルバスＩ２Ｃ＃１のデータ線に接続されており、抵抗Ｒ１を介して、第１インタフェイス電圧ＶＤＤ１の印加端にプルアップされている。トランジスタ４０１のソースは、接地端に接続されている。トランジスタ４０２のドレインは、２線式シリアルバスＩ２Ｃ＃２のデータ線に接続されており、抵抗Ｒ２を介して、第２インタフェイス電圧ＶＤＤ２の印加端にプルアップされている。トランジスタ４０２のソースは、接地端に接続されている。すなわち、２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２は、各々に接続される外部デバイスの電源電圧に適合したインタフェイス電圧が与えられている。

トランジスタ４０１がオンのとき、２線式シリアルバスＩ２Ｃ＃１のデータ線は、ローレベル（接地電圧ＧＮＤ）となる。トランジスタ４０１がオフのとき、２線式シリアルバスＩ２Ｃ＃１のデータ線は、ハイレベル（第１インタフェイス電圧ＶＤＤ１）となる。トランジスタ４０２がオンのとき、２線式シリアルバスＩ２Ｃ＃２のデータ線は、ローレベル（接地電圧ＧＮＤ）となる。トランジスタ４０２がオフのとき、２線式シリアルバスＩ２Ｃ＃２のデータ線は、ハイレベル（第２インタフェイス電圧ＶＤＤ２）となる。

レベルシフタ４１１の入力端は、２線式シリアルバスＩ２Ｃ＃１のデータ線に接続されている。レベルシフタ４１１の出力端は、論理積演算器４３０の第１入力端に接続されている。レベルシフタ４２１の入力端は、２線式シリアルバスＩ２Ｃ＃２のデータ線に接続されている。レベルシフタ４２１の出力端は、論理積演算器４３０の第２入力端に接続されている。論理積演算器４３０の出力端は、コントローラ３００のデータ信号入力端に接続されている。

レベルシフタ４１１は、第１インタフェイス電圧ＶＤＤ１と接地電圧ＧＮＤとの間でスイングされるパルス信号を内部電圧ＶＤＤ０と接地電圧ＧＮＤとの間でスイングされるパルス信号にレベルシフトして出力する。レベルシフタ４２１は、第２インタフェイス電圧ＶＤＤ２と接地電圧ＧＮＤとの間でスイングされるパルス信号を内部電圧ＶＤＤ０と接地電圧ＧＮＤとの間でスイングされるパルス信号にレベルシフトして出力する。論理積演算器４３０は、レベルシフタ４１１、４２１から各々入力されるパルス信号の論理積演算を行うことによって、内部電圧ＶＤＤ０と接地電圧ＧＮＤとの間でスイングされる論理積信号を生成し、これをコントローラ３００への入力データ信号ＩＮとして送出する。

レベルシフタ４１２、４２２の入力端は、いずれもコントローラ３００のデータ信号出力端に接続されている。レベルシフタ４１２の出力端は、トランジスタ４０１のゲートに接続されている。レベルシフタ４２２の出力端は、トランジスタ４０２のゲートに接続されている。

レベルシフタ４１２は、内部電圧ＶＤＤ０と接地電圧ＧＮＤとの間でスイングされるコントローラ３００からの出力データ信号ＯＵＴを第１インタフェイス電圧ＶＤＤ１と接地電圧ＧＮＤとの間でスイングされるパルス信号にレベルシフトして出力する。レベルシフタ４２２は、内部電圧ＶＤＤ０と接地電圧ＧＮＤとの間でスイングされるコントローラ３００からの出力データ信号ＯＵＴを第２インタフェイス電圧ＶＤＤ２と接地電圧ＧＮＤとの間でスイングされるパルス信号にレベルシフトして出力する。

レベルシフタ４１３、４２３の入力端は、いずれもコントローラ３００のクロック信号出力端に接続されている。レベルシフタ４１３の出力端は、２線式シリアルバスＩ２Ｃ＃１のクロック線に接続されている。レベルシフタ４２３の出力端は、２線式シリアルバスＩ２Ｃ＃２のクロック線に接続されている。

レベルシフタ４１３は、内部電圧ＶＤＤ０と接地電圧ＧＮＤとの間でスイングされるコントローラ３００からのクロック信号ＣＬＫを第１インタフェイス電圧ＶＤＤ１と接地電圧ＧＮＤとの間でスイングされるパルス信号にレベルシフトして出力する。レベルシフタ４２３は、内部電圧ＶＤＤ０と接地電圧ＧＮＤとの間でスイングされるコントローラ３００からのクロック信号ＣＬＫを第２インタフェイス電圧ＶＤＤ２と接地電圧ＧＮＤとの間でスイングされるパルス信号にレベルシフトして出力する。

上記したように、バスインタフェイス回路４００は、コントローラ３００から出力される単一の出力データ信号ＯＵＴを分配して２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２の各データ線に伝達する信号分配機能部（トランジスタ４０１、４０２、及び、レベルシフタ４１２、４２２）と、同じく、コントローラ３００から出力される単一のクロック信号ＣＬＫを分配して２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２の各クロック線に伝達する信号分配機能部（レベルシフタ４１３、４２３）と、を有して成る。

また、バスインタフェイス回路４００は、２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２から各々入力される複数の入力信号を結合してコントローラ３００への入力データ信号ＩＮを生成する信号結合機能部（レベルシフタ４１１、４２１及び論理積演算器４３０）を有して成る。

また、バスインタフェイス回路４００は、コントローラ３００と２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２との間で信号の受け渡しを行う際、コントローラ３００に与えられている内部電圧ＶＤＤ０と２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２に各々与えられているインタフェイス電圧ＶＤＤ１、ＶＤＤ２との間で、信号の電圧レベルを変換するレベルシフト機能部（レベルシフタ４１１〜４１３、４２１〜４２３）を有して成る。

このように、画像音声処理ＬＳＩ２００は、接続する外部デバイスの電源電圧に合わせて２系統のシリアルバスを有している。ただし、画像音声処理ＬＳＩ１００の内部において、２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２は１系統として取り扱われる。このような構成とすることにより、電源電圧の異なる複数の外部デバイスを接続する場合であっても、各々の電源電圧に基づいて適切なグループ分けを行い、各グループ（上記では、２．８Ｖ駆動のグループと３．３Ｖ駆動のグループ）を別系統のシリアルバスに接続することにより、ハイレベル電圧の差に起因する電力浪費やノイズ耐性劣化を防ぐことが可能となる。従って、上記構成を採用することにより、例えば、従来モジュール（３．３Ｖ系）と最新モジュール（２．８Ｖ系）とを同一のバスに接続して使用することが可能となる。また、上記構成を採用することにより、画像音声処理ＬＳＩ２００の設計（部品選定、外部デバイスを動作保証範囲内のインタフェイス電圧で使いこなすための電源周りの安定化など）や、ＰＣＢの設計、品質評価の負担を低減することも可能となる。

図１０は、インタフェイス電圧ＶＤＤ１、ＶＤＤ２の設定範囲を示す図である。本図に示したように、カメラ２０１、ＲＴＣ２０２、及び、ＥＥＰＲＯＭ２０３のそれぞれでインタフェイス電圧の推奨範囲（動作保証範囲）が異なっている場合であっても、インタフェイス電圧ＶＤＤ１の設定可能範囲、及び、インタフェイス電圧ＶＤＤ２の設定可能範囲を大幅に広げることが可能となる。また、電圧変換インタフェイスＩＣ（レベルシフタＩＣ）を別途設ける必要がなく、コストアップやセット規模の増大を招くおそれもない。

なお、コントローラ３００は、２線式シリアルバスＩ２Ｃ＃１、Ｉ２Ｃ＃２に各々接続される外部デバイス（カメラ２０１、ＲＴＣ２０２、及び、ＥＥＰＲＯＭ２０３）のアドレス制御またはチップセレクト制御を行う構成とされている。このように、バスに接続されている複数の外部デバイスは、コントローラ３００を主体として各々の信号出力動作が調停されているので、２系統の信号を結合させるときに支障が生じることはない。

（トリガ判定アルゴリズム）
次に、本発明に係るドライブレコーダのトリガ判定（運転状況データの不揮発記憶動作や運転者への警告動作を行うべき特定の運転挙動が生じたか否かの判定）について、詳細な説明を行う。

図１１Ａは、任意のサンプリングステップ（例えば１／１５秒）で実測された加速度データＧ（ｔ）を時系列的にグラフ化したタイムチャートである。なお、本図の加速度データＧ（ｔ）については、車両のＸ軸方向（前後方向）、Ｙ軸方向（左右方向）、及び、Ｚ軸方向（上下方向）いずれの加速度データであると考えてもよいが、以下では、図１１Ａの加速度データＧ（ｔ）がＸ軸方向の加速度データであって、車両走行中に急ブレーキが踏まれた状況を仮定して説明を行う。

図１１Ｂは、先の図１１Ａに示された加速度データＧ（ｔ）について、単位時間内（時刻（ｔ−α）〜時刻ｔ、例えばα＝１秒）における最大値Ｇｍａｘ（ｔ）から最小値Ｇｍｉｎ（ｔ）を差し引いた差分値Ｘ（ｔ）（＝Ｇｍａｘ（ｔ）−Ｇｍｉｎ（ｔ））を逐次算出し、その絶対値である絶対差分値｜Ｘ（ｔ）｜を所定のスレッショルド値Ｘｔｈと比較することで、上記のトリガ判定を行う様子が描写されたタイムチャートである。先にも述べた通り、従来のドライブレコーダでは、上記の絶対差分値｜Ｘ（ｔ）｜に基づくトリガ判定アルゴリズムが一般に採用されていたが、図１１Ｂでも示されているように、このトリガ判定アルゴリズムでは、路面状態（路面の凹凸など）に起因する加速度変化にも過敏に反応してしまい、不要な運転状況データの不揮発記憶動作や運転者への警告動作を発動してしまう場合があった。

そこで、本発明に係るドライブレコーダは、上記の絶対差分値｜Ｘ（ｔ）｜に基づくトリガ判定ではなく、先の図１１Ａに示した加速度データＧ（ｔ）について、時間的に異なる２系統の移動平均値Ｙ１（ｔ）、Ｙ２（ｔ）を生成した上で、これらの差分値Ｙ（ｔ）（＝Ｙ１（ｔ）−Ｙ２（ｔ））を逐次算出し、その絶対値である絶対移動平均差分値｜Ｙ（ｔ）｜を所定のスレッショルド値Ｙｔｈと比較することで、上記のトリガ判定を行う構成とされている。

図１１Ｃは、移動平均値Ｙ１（ｔ）、Ｙ２（ｔ）を時系列的にグラフ化したタイムチャートであり、図１１Ｄは、絶対移動平均差分値｜Ｙ（ｔ）｜を時系列的にグラフ化したタイムチャートである。

図１１Ｃを見れば分かるように、加速度データＧ（ｔ）の移動平均化処理により、路面状態に起因する加速度変化を鈍らせることが可能であるが、運転挙動（急ブレーキ）に伴う加速度変化のピークも出づらくなるので、移動平均値Ｙ１（ｔ）、Ｙ２（ｔ）と所定のスレッショルド値とを単純に比較しても、適切なトリガ判定を行えない場合がある。

そこで、図１１Ｄに示すように、２系統の移動平均値Ｙ１（ｔ）、Ｙ２（ｔ）から絶対移動平均差分値｜Ｙ（ｔ）｜を算出することにより、路面状態に起因する加速度変化をフィルタリングした上で、さらに、急峻な運転挙動（危険挙動）のみを浮き上がらせることができる。従って、上記の絶対移動平均差分値｜Ｙ（ｔ）｜と所定のスレッショルド値Ｙｔｈを比較することにより、適切なトリガ判定を行うことが可能となる。

また、上記のトリガ判定アルゴリズムを採用すれば、車両の加速度値とスレッショルド値を直接的に比較する従来構成と異なり、ドライブレコーダ本体の設置状態（傾き）や加速度センサの絶対値バラツキに依存しないトリガ判定が可能となり、複雑なキャリブレーションが不要となる。

図１２は、移動平均値Ｙ１（ｔ）、Ｙ２（ｔ）の算出手法を説明するための模式図である。現在時刻（現在カウント）をｔとした場合、移動平均値Ｙ１（ｔ）は、加速度データＧ（ｔ）〜Ｇ（ｔ−４）までの５サンプルを平均化した値（＝｛Ｇ（ｔ）＋Ｇ（ｔ−１）＋Ｇ（ｔ−２）＋Ｇ（ｔ−３）＋Ｇ（ｔ−４）｝／５）とされており、一方の移動平均値Ｙ２（ｔ）は、加速度データＧ（ｔ−４）〜Ｇ（ｔ−８）までの５サンプルを平均化した値（＝｛Ｇ（ｔ−４）＋Ｇ（ｔ−５）＋Ｇ（ｔ−６）＋Ｇ（ｔ−７）＋Ｇ（ｔ−８）｝／５）とされている。

すなわち、移動平均値Ｙ１（ｔ）及びＹ２（ｔ）は、互いに１サンプル分のオーバーラップデータ（図１２では、加速度データＧ（ｔ−４））を含みつつ、互いに隣接する時間帯を演算対象として算出された値である。なお、オーバーラップデータのサンプリング数（オーバーラップ期間）については、移動平均化処理のサンプリング数（移動平均期間）との関係を鑑みつつ任意に設定すればよく、０〜数サンプル分が望ましい。

図１３は、一般的な乗用車における移動平均期間の設定根拠を説明するためのタイムチャートであり、車両走行中に実測される３軸（Ｘ軸、Ｙ軸、Ｚ軸）方向の加速度データを時系列的にグラフ化したものである。本図に示すように、路面の凹凸に起因する加速度変化は、振動のような挙動を示しており、その周期については、車両の速度やサスペンション性能、ないしは、路面の状態に依ることなく、ほぼ０．３〜０．５秒の範囲内に収まっていることが実測データから判明している。そこで、上記の周期（０．３〜０．５秒）を考慮した移動平均期間を設定すれば、路面の凹凸に起因する加速度変化を適切にフィルタリングすることが可能であると考えられる。

図１４は、上記で説明したトリガ判定アルゴリズムをハードウェア的に実現するトリガ判定回路の一構成例を示すブロック図である。本構成例のトリガ判定回路５００は、ＦＩＦＯ［First-In First-Out］レジスタ５０１と、第１平均化処理部５０２と、第２平均化処理部５０３と、減算処理部５０４と、閾値比較部５０５と、論理和演算器５０６と、を有する。

ＦＩＦＯレジスタ５０１は、加速度センサから入力されるデジタル形式の加速度データを順次格納する。例えば、移動平均化処理のサンプリング数（移動平均期間）を「５」とし、オーバーラップデータのサンプリング数（オーバーラップ期間）を「１」とした場合には、９サンプル分の加速度データＧ（ｔ−８）〜Ｇ（ｔ）がＦＩＦＯレジスタ５０１に格納される。

第１平均化処理部５０２は、ＦＩＦＯレジスタ５０１に格納された９サンプル分の加速度データのうち、最新４サンプル分の加速度データＧ（ｔ−３）〜Ｇ（ｔ）の総和（＝Ｇ（ｔ−３）＋Ｇ（ｔ−２）＋Ｇ（ｔ−１）＋Ｇ（ｔ））を演算し、これを移動平均化処理のサンプリング数（＝５）で除すことにより、移動平均値Ｙ１’（ｔ）を算出する。

第２平均化処理部５０３は、ＦＩＦＯレジスタ５０１に格納されている９サンプル分の加速度データのうち、最古４サンプル分の加速度データＧ（ｔ−８）〜Ｇ（ｔ−５）の総和（＝Ｇ（ｔ−８）＋Ｇ（ｔ−７）＋Ｇ（ｔ−６）＋Ｇ（ｔ−５））を演算し、これを移動平均化処理のサンプリング数（＝５）で除すことにより、移動平均値Ｙ２’（ｔ）を算出する。

なお、第１平均化処理部５０２及び第２平均化処理部５０３では、オーバーラップ期間の加速度データＧ（ｔ−４）が演算対象に含められていない。その理由は、仮に加速度データＧ（ｔ−４）を演算対象に含めて、先述の移動平均値Ｙ１（ｔ）、Ｙ２（ｔ）を算出したとしても、後段の減算処理部５０４において移動平均差分値Ｙ（ｔ）を算出する際には、オーバーラップ期間の加速度データＧ（ｔ−４）が減算処理によってキャンセルされるため、これを予め演算対象から除いておく方が回路規模縮小の点で有利だからである。

減算処理部５０４は、移動平均値Ｙ１’（ｔ）から移動平均値Ｙ２’（ｔ）を減ずることにより、移動平均差分値Ｙ（ｔ）（＝Ｙ１’（ｔ）−Ｙ２’（ｔ））を算出する。

閾値比較部５０５は、移動平均差分値Ｙ（ｔ）と、正側スレッショルド値Ｙｔｈ＿Ｐ及び負側スレッショルド値Ｙｔｈ＿Ｍとを各々比較することにより、正側トリガ信号ＰＴＲＩＧ及び負側トリガ信号ＭＴＲＩＧを生成する。なお、移動平均差分値Ｙ（ｔ）が正側スレッショルド値Ｙｔｈ＿Ｐよりも高ければ、正側トリガ信号ＰＴＲＩＧがハイレベルとされ、負側トリガ信号ＭＴＲＩＧがローレベルとされる。また、移動平均差分値Ｙ（ｔ）が正側スレッショルド値Ｙｔｈ＿Ｐよりも低く、負側スレッショルド値Ｙｔｈ＿Ｍよりも高ければ、正側トリガ信号ＰＴＲＩＧ及び負側トリガ信号ＭＴＲＩＧがいずれもローレベルとされる。また、移動平均差分値Ｙ（ｔ）が負側スレッショルド値Ｙｔｈ＿Ｍよりも低ければ、正側トリガ信号ＰＴＲＩＧがローレベルとされ、負側トリガ信号ＭＴＲIＧがハイレベルとされる。

論理和演算器５０６は、正側トリガ信号ＰＴＲＩＧと負側トリガ信号ＭＴＲＩＧとの論理和演算を行い、トリガ信号ＴＲＩＧを生成する。従って、トリガ信号ＴＲＩＧは、正側トリガ信号ＰＴＲＩＧと負側トリガ信号ＭＴＲＩＧの少なくとも一方がハイレベルであればハイレベルとなり、両方がローレベルであるときにのみローレベルとなる。

なお、本構成例のトリガ判定回路５００では、移動平均差分値Ｙ（ｔ）と正負２種類のスレッショルド値Ｙｔｈ＿Ｐ、Ｙｔｈ＿Ｍとを比較する構成を例に挙げたが、本発明の構成はこれに限定されるものではなく、先出の図１１Ｄで示したように、絶対移動平均差分値｜Ｙ（ｔ）｜と１つのスレッショルド値Ｙｔｈとを比較する構成としてもよい。その場合、減算処理部５０４に絶対値演算処理機能が必要となる一方、負側スレッショルド値Ｙｔｈ＿Ｍや論理和演算器５０６は不要となる。

図１５は、上記で説明したトリガ判定アルゴリズムをマイコン等によってソフトウェア的に実現する際のトリガ判定動作を説明するためのフローチャートである。なお、本フローチャートの説明に際しては、前提条件として、移動平均化処理のサンプリング数（移動平均期間）を「ｍ」とし、オーバーラップデータのサンプリング数（オーバーラップ期間）を「ｎ」とする。また、ＦＩＦＯレジスタの格納値は、新しいものから順番に、ＦＩＦＯ［０］〜ＦＩＦＯ［（２ｍ−ｎ）−１］と表すことにする。

フローがスタートすると、ステップＳ１０１では、加速度センサから入力されるデジタル形式の加速度データがＦＩＦＯレジスタに順次格納され、続くステップＳ１０２では、ＦＩＦＯレジスタが満杯になったか否かの判定が行われる。ここで、ノー判定が下された場合には、フローがステップＳ１０１に戻されて、加速度データの格納が継続される。

ステップＳ１０２でイエス判定が下された場合、ステップＳ１０３では、移動平均値Ｙ１’、Ｙ２’の算出処理が行われる。なお、移動平均値Ｙ１’は、ＦＩＦＯレジスタに格納された（２ｍ−ｎ）サンプル分の加速度データのうち、最新（ｍ−ｎ）サンプル分の加速度データの総和（＝ＦＩＦＯ［（ｍ−ｎ）−１］＋ＦＩＦＯ［（ｍ−ｎ）−２］＋…＋ＦＩＦＯ［１］＋ＦＩＦＯ［０］）を移動平均化処理のサンプリング数（＝ｍ）で除した値となる。また、移動平均値Ｙ２’は、ＦＩＦＯレジスタに格納された（２ｍ−ｎ）サンプル分の加速度データのうち、最古（ｍ−ｎ）サンプル分の加速度データの総和（＝ＦＩＦＯ［（２ｍ−ｎ）−１］＋ＦＩＦＯ［（２ｍ−ｎ）−２］＋…＋ＦＩＦＯ［ｍ＋１］＋ＦＩＦＯ［ｍ］）を移動平均化処理のサンプリング数（＝ｍ）で除した値となる。

ステップＳ１０３において、移動平均値Ｙ１’、Ｙ２’が算出されると、続くステップＳ１０４では、移動平均差分値Ｙ（＝Ｙ１’−Ｙ２’）の算出処理が行われた後、フローがステップＳ１０５に進められる。

ステップＳ１０５では、移動平均差分値Ｙが負側スレッショルド値Ｙｔｈ＿Ｍよりも低いか否かの判定が行われる。ここで、イエス判定が下された場合には、ステップＳ１０６にて、負側トリガ信号ＭＴＲＩＧがハイレベルとされた後、フローがステップＳ１０８に進められる。一方、ノー判定が下された場合には、ステップＳ１０７にて、負側トリガ信号ＭＴＲＩＧがローレベルとされた後、フローがステップＳ１０８に進められる。

ステップＳ１０８では、移動平均差分値Ｙが正側スレッショルド値Ｙｔｈ＿Ｐよりも高いか否かの判定が行われる。ここで、イエス判定が下された場合には、ステップＳ１０９にて、正側トリガ信号ＰＴＲＩＧがハイレベルとされた後、フローがステップＳ１１１に進められる。一方、ノー判定が下された場合には、ステップＳ１１０にて、正側トリガ信号ＰＴＲＩＧがローレベルとされた後、フローがステップＳ１１１に進められる。

ステップＳ１１１では、正側トリガ信号ＰＴＲＩＧと負側トリガ信号ＭＴＲＩＧとの論理和演算処理により、トリガ信号ＴＲＩＧが生成されて、上記一連の処理が完了される。

なお、図１５のフローチャートでは、移動平均差分値Ｙと正負２種類のスレッショルド値Ｙｔｈ＿Ｐ、Ｙｔｈ＿Ｍを比較する構成を例に挙げたが、本発明の構成はこれに限定されるものではなく、先出の図１１Ｄで示したように、絶対移動平均差分値｜Ｙ｜と１つのスレッショルド値Ｙｔｈとを比較する構成としてもよい。その場合、ステップＳ１０４の後に絶対値処理ステップが必要となる一方、ステップＳ１０５〜Ｓ１０７は不要となる。

また、マイコンを用いて上記のトリガ判定動作を実行する場合には、マイコンに読み込まれて実行され、当該マイコンを図１４のＦＩＦＯレジスタ５０１、第１平均化処理部５０２、第２平均化処理部５０３、減算処理部５０４、及び、閾値比較部５０５として機能させるトリガ判定用プログラムを用意しておけばよい。

また、上記実施形態では、Ｘ軸方向の加速度データを演算対象として、本発明に係るトリガ判定アルゴリズムの説明を行ったが、Ｙ軸方向やＺ軸方向の加速度データを演算対象としてもよいことは言うまでもなく、演算対象とする加速度データの軸数も任意である。

（データ記録方式の切替機能）
図１６は、データ記録方式の切替機能を備えたドライブレコーダの一構成例を示すブロック図である。本構成例のドライブレコーダ６００は、カメラ６１０と、カメラデータ入力部６２０と、圧縮処理部６３０と、マイク６４０と、音声入力部６５０と、制御部６６０と、を有する。

カメラ６１０は、車両の運転状況データを収集するデータ収集部の一つであって、車外や車内の様子を撮影する。なお、カメラ６１０を構成する光電変換素子としては、ＣＣＤ［Charge Coupled Devices］やＣＭＯＳ［Complementary Metal Oxide Semiconductor］を用いればよい。

カメラデータ入力部６２０は、カメラ６１０で撮影された映像データに所定の画像処理（アナログ／デジタル変換処理、ノイズ除去処理、色補正処理など）を施して圧縮処理部６３０に出力する。

圧縮処理部６３０は、カメラデータ入力部６２０から入力される映像データや、音声入力部６５０から入力される音声データに対して、制御部６６０からの指示に応じた圧縮処理を施す手段であり、映像圧縮部６３１と、バッファ部６３２と、音声圧縮部６３３と、を有する。なお、図１６では、便宜上、圧縮処理部６３０を独立の回路ブロックとして描写しているが、圧縮処理部６３０については、専用ＤＳＰ［Digital Signal Processor］などを用いてハードウェア的に実現してもよいし、或いは、制御部６６０に含まれるＣＰＵ６６１やＲＡＭ６６２を用いてソフトウェア的に実現しても構わない。

映像圧縮部６３１は、カメラデータ入力部６２０から入力される映像データに対して、制御部６６０の指示に応じた映像圧縮処理を施す。なお、映像データ圧縮方式の選択肢としては、Ｍｏｔｉｏｎ−ＪＰＥＧ、ＭＰＥＧ−２、及び、ＭＰＥＧ４などが挙げられる。

バッファ部６３２は、圧縮処理済みの映像データ及び音声データを一時的に格納しておく揮発性の記憶手段である。

音声圧縮部６３３は、音声入力部６５０から入力される音声データに対して、制御部６６０の指示に応じた音声圧縮処理を施す。なお、音声データ圧縮方式の選択肢としては、ＡＡＣ［Advanced Audio Coding］、ＭＰ３、圧縮なしＰＣＭ［Pulse Code Modulation］などが挙げられる。

マイク６４０は、車両の運転状況データを収集するデータ収集部の一つであって、車外や車内で発せられた音を電気信号に変換して音声入力部６５０に出力する。

音声入力部６５０は、マイク６４０で集音された音声データに所定の音声処理（アナログ／デジタル変換処理、サンプリング処理など）を施して圧縮処理部６３０に出力する。

制御部６６０は、ドライブレコーダ６００を構成する各機能部６１０〜６５０を統括的に制御する手段であり、ＣＰＵ［Central Processing Unit］６６１と、ＲＡＭ［Random Access Memory］６６２と、プログラムメモリ６６３と、リムーバブルメディア制御部６６４と、センサ入力部６６５と、を有する。

ＣＰＵ６６１は、プログラムメモリ６６３に格納された種々のプログラムを実行することにより、ドライブレコーダ６００を構成する上記各機能部６１０〜６５０を統括的に制御する。特に、後ほど詳細に説明するデータ記録方式の切替機能に関しては、プログラムメモリ６６３に格納されているデータ記録方式指定プログラムを実行し、その内容に応じて圧縮処理部６３０やリムーバブルメディア制御部６６４を制御することにより、映像データや音声データをリムーバブルメディア７３０に出力する際のデータ圧縮方式、ファイルフォーマット、及び、出力先のフォルダ階層を指定する。

ＲＡＭ６６２は、ＣＰＵ６６１の作業領域として使用される揮発性の記憶手段である。

プログラムメモリ６６３は、ＣＰＵ６６１によって実行される各種プログラムの格納領域として使用される不揮発性の記憶手段である。

リムーバブルメディア制御部６６４は、ドライブレコーダ６００に着脱されるリムーバブルメディア７３０との間でデータの授受を行うインタフェイスブロックである。

なお、リムーバブルメディア７３０は、ドライブレコーダ６００から再生機器７１０に映像データや音声データを受け渡す際、或いは、パーソナルコンピュータ７２０からドライブレコーダ６００にデータ記録方式指定プログラムを受け渡す際の媒介として利用されるものであり、例えば、広く一般に普及しているフラッシュメモリカード（ＳＤカードなど）やＵＳＢ［Universal Serial Bus］メモリを用いることができる。

また、本明細書中では、上記で例示したフラッシュメモリカードやＵＳＢメモリだけでなく、ＵＳＢケーブルを介してドライブレコーダ６００に接続することが可能な情報端末（携帯電話機やポータブルＰＣ）についても、ドライブレコーダ６００との間でやり取りされる種々のデータを記憶するための記憶領域（内蔵型または着脱型のフラッシュメモリやハードディスクドライブなど）を備えている限り、ここでは、広義のリムーバブルメディアとして理解されるものとする。

センサ入力部６６５は、車両の運転状況データを収集するデータ収集部の一つであり、ドライブレコーダ６００の内部または外部に設けられた種々のセンサから加速度データ、ＧＰＳ［Global Positioning System］データ、車速データなどが入力される。

上記構成から成るドライブレコーダ６００に記録された運転状況データのうち、特に、カメラ６１０で撮影された映像データを事故現場で直ちに再生し、事故発生時の状況を確認することができれば、ドライブレコーダ６００の利便性ないし有効性を向上することが可能であることは、先にも述べた通りである。

映像データを事故現場で確認する機会を増やすためには、ドライブレコーダ６００にアナログビデオ出力端子を設けるだけでは足りず、運転状況データが記録されたリムーバブルメディア７３０をドライブレコーダ６００から抜き取り、これをユーザの身近に存在する再生機器７１０（ＰＮＤ、ポータブルメディアプレーヤ、携帯電話機など）に挿入するだけで、リムーバブルメディア７３０に記録されている運転状況データを再生機器７１０で手軽に再生できる環境を整えておくことが重要である。

しかし、ここで問題となるのは、ドライブレコーダ６００のデータ記録方式が再生機器７１０で再生可能なデータ記録方式と異なっている点である。なお、本明細書中での「データ記録方式」とは、データ圧縮方式、ファイルフォーマット、及び、リムーバブルメディア７３０内のフォルダ階層の組み合わせを言う。

図１７は、データ記録方式の一例を示すテーブルであり、左から順に、ドライブレコーダ６００で初期設定されているデータ記録方式、Ａ社製〜Ｃ社製のカーナビゲーションシステムで再生可能なデータ記録方式、Ｄ社製〜Ｆ社製のメディアプレーヤで再生可能なデータ記録形式、及び、Ｇ社製〜Ｉ社製の携帯電話機で再生可能なデータ記録方式が例示されている。なお、上記したカーナビゲーションシステム、メディアプレーヤ、及び、携帯電話機は、あくまでユーザの身近に存在する再生機器７１０の一例であり、これに限定されるものではない。

図１７に示したように、再生機器７１０で再生可能な映像データ圧縮方式としては、Ｍｏｔｉｏｎ−ＪＰＥＧやＭＰＥＧ４などが挙げられる。また、再生機器７１０で再生可能なファイルフォーマットとしては、ＡＶＩ[Audio Video Interleave]フォーマット、ＷＭＡ［Windows Media Audio］フォーマット、ＭＰＥＧ［Moving Picture Experts Group］フォーマットなどが挙げられる。また、再生機器７１０で再生可能なフォルダ階層については、特に分類がなく、無限のパターンが存在するが、一般的には再生機器７１０毎に固有の制約が設けられている。

例えば、ドライブレコーダ６００で初期設定されているデータ記録方式に従って、運転状況データをリムーバブルメディア７３０に出力する場合には、リムーバブルメディア７３０に「日付」フォルダが生成され、当該フォルダ内に独自形式の運転状況データファイル（＊．ｄｒｖ）が記録される。この運転状況データファイルには、映像データや音声データのほか、加速度データ、ＧＰＳデータ、車速データなどが含まれている。なお、ドライブレコーダ６００の初期設定において、映像データの圧縮方式としては、Ｍｏｔｉｏｎ−ＪＰＥＧが適用される。

一方、Ａ社製のカーナビゲーションシステムは、リムーバブルメディア７３０の「ｒｏｏｔ」フォルダ内に、Ｍｏｔｉｏｎ−ＪＰＥＧで圧縮されたＡＶＩ形式の映像データファイル（＊．ａｖｉ）が存在する場合にのみ、当該映像データファイルの再生を行うことができる。従って、ドライブレコーダ６００を初期設定のまま使用している限り、リムーバブルメディア７３０に記録されている運転状況データファイルをＡ社製のカーナビゲーションシステムで再生することは不可能である。

その他の再生機器７１０についても上記と同様であり、リムーバブルメディア７３０に記録された運転状況データ（特に映像データ）を再生機器７１０で再生するためには、ドライブレコーダ６００で設定されているデータ記録方式と、再生機器７１０で再生可能なデータ記録方式とを一致させておかなければならない。

そこで、本構成例のドライブレコーダ６００では、プログラムメモリ６６３に格納される種々のプログラムのうち、運転状況データの記録方式を指定するためのデータ記録方式指定プログラムを任意に書き換えることが可能な構成とされている。

このような構成とすることにより、ユーザの身近に存在する再生機器７１０で再生可能なデータ記録方式に合わせて、ドライブレコーダ６００のデータ記録方式を適宜変更することができるので、リムーバブルメディア７３０に記録された運転状況データ（特に映像データ）を再生機器７１０で手軽に再生することが可能となり、延いては、映像データを事故現場で確認する機会を増やして、ドライブレコーダ６００の利便性ないし有効性を向上することが可能となる。

なお、上記構成から成るドライブレコーダ６００において、制御部６６０は、映像データをリムーバブルメディア７３０に出力する際、映像データとこれに同期した音声データを１つのファイルに統合して出力する構成にするとよい。このような構成とすることにより、映像だけでなく、映像と音声を合わせて現場で確認することができるので、事故発生時の状況をより正確に確認することが可能となる。

また、ドライブレコーダ６００のデータ記録方式を再生機器７１０の再生可能なデータ記録方式に変更した場合、リムーバブルメディア７３０に記録されるデータファイルが独自フォーマットではなくなるため、映像データや音声データ以外の運転状況データ（車両の加速度データ、ＧＰＳデータ、及び、車速データなど）の取り扱いが問題となる。

この点に関して、例えば、制御部６６０は、映像データをリムーバブルメディア７３０に出力する際、車両の加速度データ、ＧＰＳデータ、及び、車速データなどの運転状況データを別ファイルとして出力する構成にするとよい。このような構成とすることにより、映像データや音声データについては、再生機器７１０による現場確認が可能となり、他の運転状況データについては、パーソナルコンピュータを用いた事後解析が可能となる。

或いは、制御部６６０は、映像データをリムーバブルメディア７３０に出力する際、車両の加速度データ、ＧＰＳデータ、及び、車速データなどの運転状況データを文字情報の形で映像データに埋め込んで出力する構成としてもよい（図１８を参照）。このような構成とすることにより、映像だけでなく、映像に合わせて時々刻々と変化する運転状況データを合わせて現場で確認することができるので、事故発生時の状況をより正確に確認することが可能となる。

上記で説明した通り、本構成例のドライブレコーダ６００において、制御部６６０は、ユーザ要求に応じて、映像データをリムーバブルメディア７３０に出力する際のデータ圧縮方式、ファイルフォーマット、及び、出力先のフォルダ階層を指定する構成とされているが、このユーザ要求については、リムーバブルメディア７３０に格納されたデータ記録方式指定プログラムの形で受け付けるとよい。言い換えれば、制御部６６０は、リムーバブルメディア７３０に新たなデータ記録方式プログラムが格納されている場合、その内容をプログラムメモリ６６３に上書きする構成にするとよい。

以下では、Ａ社製のカーナビゲーションシステムで再生可能なデータ記録方式に合わせて、ドライブレコーダ６００のデータ記録方式を切り替える際の手順を例示しながら具体的に説明する。

まず、ユーザは、インターネット７４０（その他のネットワークでも可）に接続されたパーソナルコンピュータ７２０（クライアント端末）を用いて、Ａ社製のカーナビゲーションシステムで再生可能なデータ記録方式を指定するためのデータ記録方式指定プログラムをサーバ７５０からダウンロードし、これをリムーバブルメディア７３０に記録する。

なお、サーバ７５０は、種々の再生機器７１０に対応したデータ記録方式指定プログラムを複数格納するものであり、例えば、ドライブレコーダ６００の製造者や販売者が運営するものである。このようなサーバ７５０を用意しておくことにより、ユーザは、自身で再生機器７１０の仕様を調べることなく、ドライブレコーダ６００のデータ記録方式を最適に設定することが可能となる。

次に、ユーザは、データ記録方式指定プログラムが記録されたリムーバブルメディア７３０をドライブレコーダ６００に挿入する。リムーバブルメディア７３０の挿入を検知した制御部６６０は、リムーバブルメディア７３０にデータ記録方式プログラムが格納されていることを認識し、その内容をプログラムメモリ６６３に上書きする。従って、以後、映像データをリムーバブルメディア７３０に出力する際には、新たなデータ記録方式プログラムによって指定されるデータ記録方式に従って、映像データがリムーバブルメディア７３０に出力される。

このようなドライブレコーダ運用システムを構築しておくことにより、ユーザは簡易な作業でドライブレコーダ６００のデータ記録方式を切り替えることが可能となる。

（その他の変形例）
なお、本発明の構成は、上記実施形態のほか、発明の主旨を逸脱しない範囲で種々の変更を加えることが可能である。すなわち、上記実施形態は、全ての点で例示であって、制限的なものではないと考えられるべきであり、本発明の技術的範囲は、上記実施形態の説明ではなく、特許請求の範囲によって示されるものであり、特許請求の範囲と均等の意味及び範囲内に属する全ての変更が含まれると理解されるべきである。

本発明は、ドライブレコーダの利便性を高める上で有用な技術である。

１ ドライブレコーダ
２ 携帯電話端末
３ 電子制御ユニット（ＥＣＵ）
４ 車載センサ
５ 携帯電話回線
６ サーバ
７ 回線
８ 交通センターサーバ
９ 警察サーバ
１０ 保険会社サーバ
６１ 通信部
６２ 情報管理部
６３ 情報解析部
６４ 情報格納部
１０１ 制御部
１０２ 撮像部
１０３ ＧＰＳ受信部
１０４ 加速度センサ
１０５ インタフェイス部
１０６ リアルタイムクロック（ＲＴＣ）
１０７ 記憶部
１０８ 通信部
１０９ 操作部
１１０ 警告部
２００ 画像音声処理ＬＳＩ
２０１ カメラ（ＣＡＭ）
２０２ リアルタイムクロック（ＲＴＣ）
２０３ ＥＥＰＲＯＭ（Ｅ２Ｐ）
２０４ 加速度センサ（Ｇセンサ）
２０５ ＧＰＳモジュール
２０６ スピーカ
２０７ マイク
２０８ オーディオコーデック
２０９ 基本プログラム格納メモリ
２１０ テレビモニタ
２１１ ＳＤカード
２１２ 拡張プログラム格納メモリ
２１３ オプションカメラ
２１４ 画像処理ＩＣ
２１５ ＩｒＤＡコントローラＩＣ
２１６ ＩｒＤＡモジュール
２２０ 降圧レギュレータ（電源ＩＣ）
２２１〜２２３ ダイオード
２２４ 抵抗
２２５ 二次電池
２３０、２３１、２３２ 降圧レギュレータ（ＬＤＯ）
３００ 制御部（ＣＴＲＬ）
４００ バスインタフェイス回路（双方向バスマルチプレクサ）
４０１、４０２ Ｎチャネル型ＭＯＳ電界効果トランジスタ
４１１〜４１３ レベルシフタ（ＶＤＤ０／ＶＤＤ１）
４２１〜４２３ レベルシフタ（ＶＤＤ０／ＶＤＤ２）
４３０ 論理積演算器
Ｉ２Ｃ＃１、Ｉ２Ｃ＃２ ２線式シリアルバス
Ｒ１、Ｒ２ 抵抗
Ｖ１ 入力電圧
Ｖ２ 出力電圧
Ｖ３ 電池電圧
ＶＤＤ０ 内部電圧
ＶＤＤ１ 第１インタフェイス電圧
ＶＤＤ２ 第２インタフェイス電圧
５００ トリガ判定回路
５０１ ＦＩＦＯレジスタ
５０２ 第１平均化処理部
５０３ 第２平均化処理部
５０４ 減算処理部
５０５ 閾値比較部
５０６ 論理和演算器
６００ ドライブレコーダ
６１０ カメラ
６２０ カメラデータ入力部
６３０ 圧縮処理部
６３１ 映像圧縮部
６３２ バッファ部
６３３ 音声圧縮部
６４０ マイク
６５０ 音声入力部
６６０ 制御部
６６１ ＣＰＵ
６６２ ＲＡＭ
６６３ プログラムメモリ
６６４ リムーバブルメディア制御部
６６５ センサ入力部
７１０ 再生機器
７２０ パーソナルコンピュータ（クライアント端末）
７３０ リムーバブルメディア
７４０ インターネット
７５０ サーバ

Claims (8)

1. 映像データを含む車両の運転状況データを収集するデータ収集部と；
   ユーザ要求に応じて、前記映像データをリムーバブルメディアに出力する際のデータ圧縮方式、ファイルフォーマット、及び、出力先のフォルダ階層を指定する制御部と；
   を有することを特徴とするドライブレコーダ。
2. 前記制御部は、前記映像データを前記リムーバブルメディアに出力する際、前記映像データとこれに同期した音声データを１つのファイルに統合して出力することを特徴とする請求項１に記載のドライブレコーダ。
3. 前記制御部は、前記映像データを前記リムーバブルメディアに出力する際、車両の加速度データ、ＧＰＳデータ、及び、車速データなどの運転状況データを別ファイルとして出力することを特徴とする請求項１または請求項２に記載のドライブレコーダ。
4. 前記制御部は、前記映像データを前記リムーバブルメディアに出力する際、車両の加速度データ、ＧＰＳデータ、及び、車速データなどの運転状況データを文字情報の形で前記映像データに埋め込んで出力することを特徴とする請求項１または請求項２に記載のドライブレコーダ。
5. 前記データ圧縮方式の選択肢には、Ｍｏｔｉｏｎ−ＪＰＥＧ、ＭＰＥＧ−２、及び、ＭＰＥＧ４が含まれていることを特徴とする請求項１〜請求項４のいずれかに記載のドライブレコーダ。
6. 前記ファイルフォーマットの選択肢には、独自フォーマット、ＡＶＩフォーマット、ＷＭＡフォーマット、及び、ＭＰＥＧフォーマットが含まれていることを特徴とする請求項１〜請求項５のいずれかに記載のドライブレコーダ。
7. 前記制御部は、前記リムーバブルメディアに格納されたデータ記録方式指定プログラムの形で前記ユーザ要求を受け付けることを特徴とする請求項１〜請求項６のいずれかに記載のドライブレコーダ。
8. 請求項７に記載のドライブレコーダと；
   種々の再生機器に対応した前記データ記録方式指定プログラムを格納するサーバと；
   ユーザ要求に応じて、ネットワークを介して前記サーバから前記データ記録方式指定プログラムを取得し、これを前記リムーバブルメディアに記録するクライアント端末と；
   を有することを特徴とするドライブレコーダ運用システム。

Images