JP2017079406A - 車載記録システム及び車載制御装置 - Google Patents

Abstract

【課題】異なるイベントが連続発生しても、ゲートウェイ装置が先発イベントに対応するトリガの成立状態を中継すること。
【解決手段】第１の車載ネットワークを介してゲートウェイ装置に接続され、車両等の状況を表すデータを不揮発性メモリに記録するためのトリガの状態を送信する車載装置。所定の複数のイベントが前記車両で発生したか否かをイベント毎に判定する判定部と、前記判定部が前記車両で発生したと判定したイベントに対応するトリガの状態を成立状態に設定する設定部と、複数のイベントそれぞれのトリガの状態を搬送する通信フレームを第１の車載ネットワークに送信する送信処理部と、前記設定部がトリガの状態を成立状態に設定してから所定時間経過するまでトリガの状態を成立状態に維持し、所定時間経過後にトリガの状態を成立状態から非成立状態に変更するラッチ処理を、複数のイベントそれぞれのトリガについて行うラッチ処理部とを備えるもの。
【選択図】図６

Description

本発明は、車載記録システム及び車載制御装置に関する。

従来、車両の衝突等のイベントが検出された場合、車載ネットワークを介して各ＥＣＵ（Electronic Control Unit）から受信した検出データを不揮発性メモリに記録するシステムが知られている（例えば、特許文献１を参照）。このシステムは、車載ネットワークが異なるＥＣＵ間で検出データを送受信できるように、データ通信を中継するゲートウェイＥＣＵを備えるものである。

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

車両の状況を表す車両データを不揮発性メモリに記録する車載記録システムでは、当該不揮発性メモリの総メモリ容量が限られていることから、車両データをイベントドリブン方式で記録することが多い。その仕組みは、例えば、衝突等のイベントが発生したとき、当該イベントに対応する車両データを不揮発性メモリに記録するためのトリガの状態を車載ネットワークに送信し、車載ネットワークから受信したトリガの状態に基づいて、当該車両データを当該不揮発性メモリに記録するものである。

しかしながら、トリガの状態がゲートウェイ装置を経由して異なる車載ネットワーク間で送受される形態では、ゲートウェイ装置がトリガの状態を中継する際に中継遅延が発生する。そのため、異なるイベントが連続して発生すると、ゲートウェイ装置は、先発のイベントが検出された場合に送信される通信フレーム内のトリガの状態を、後発のイベントが検出された場合に送信される通信フレーム内のトリガの状態で上書きしてしまうことがある。

例えば、図１は、送信ＥＣＵ２０１が、先発イベントに対応する第１のトリガ２２１の状態「１」を含む第１の通信フレーム２３１を送信した後に、後発イベントに対応する第２のトリガ２２２の状態「１」を含む第２の通信フレーム２３２を送信する場合を例示する。この場合、送信ＥＣＵ２０１は、先発イベントが発生したと判定すると、先発イベントに対応する第１のトリガ２２１の状態を「１」に設定した第１の通信フレーム２３１を送信することで、当該先発イベントに対応する車両データを不揮発性メモリに記録することを受信ＥＣＵ２０２に対して指令する。その後、送信ＥＣＵ２０１は、後発イベントが発生したと判定すると、後発イベントに対応する第２のトリガ２２２の状態を「１」に設定した第２の通信フレーム２３２を送信することで、当該後発イベントに対応する車両データを不揮発性メモリに記録することを受信ＥＣＵ２０２に対して指令する。なお、図示の第１の通信フレーム２３１と第２の通信フレーム２３２は、いずれも、５つ分のトリガの状態を搬送可能なデータフレームの一例を模式的に表したものである。

ところが、ゲートウェイ装置２０３は、通信フレームを第１の車載ネットワーク２１１から第２の車載ネットワーク２１２に中継するのに中継遅延時間Ｔ（すなわち、ゲートウェイ装置２０３が第１の車載ネットワーク２１１から通信フレームを受信してから第２の車載ネットワーク２１２に送信するまでの時間）を要する。このため、ゲートウェイ装置２０３は、第１の車載ネットワーク２１１から第１の通信フレーム２３１を受信してから中継遅延時間Ｔ内に第２の通信フレーム２３２を受信すると、第１の通信フレーム２３１を中継せずに第２の通信フレーム２３２を第２の車載ネットワーク２１２に中継する。その結果、第２の車載ネットワーク２１２側の受信ＥＣＵ２０２は、先発イベントに対応する第１のトリガ２２１の状態「１」を取得できないので、当該先発イベントに対応する車両データを不揮発性メモリに記録できない。

そこで、本発明は、異なるイベントが連続して発生しても、ゲートウェイ装置が先発のイベントに対応するトリガの成立状態を中継できることを目的とする。

上記目的を達成するため、本発明の第１の態様では、
車両又は前記車両の乗員の状況を表す状況データを不揮発性メモリに記録するためのトリガの状態を第１の車載ネットワークに送信する第１の制御装置と、
前記第１の車載ネットワークに送信されたトリガの状態を前記第１の車載ネットワークから第２の車載ネットワークに中継するゲートウェイ装置と、
前記ゲートウェイ装置によって前記第１の車載ネットワークから前記第２の車載ネットワークに中継されたトリガの状態を前記第２の車載ネットワークから受信する第２の制御装置とを備え、
前記第１の制御装置は、
所定の複数のイベントが前記車両で発生したか否かをイベント毎に判定するイベント発生判定部と、
前記イベント発生判定部が前記車両で発生したと判定したイベントに対応する前記トリガの状態を成立状態に設定するトリガ状態設定部と、
前記複数のイベントそれぞれの前記トリガの状態を搬送する通信フレームを前記第１の車載ネットワークに送信する送信処理部とを有し、
前記ゲートウェイ装置は、
前記第１の車載ネットワークから受信した第１の通信フレームを前記第２の車載ネットワークに中継するまでに、前記第１の通信フレームとは別の第２の通信フレームを前記第１の車載ネットワークから受信した場合、前記第１の通信フレームを中継せずに前記第２の通信フレームを前記第１の車載ネットワークから前記第２の車載ネットワークに中継する中継処理部を有し、
前記第２の制御装置は、前記第２の車載ネットワークから受信した通信フレーム内の前記複数のイベントそれぞれの前記トリガのうち、成立状態の前記トリガに対応する前記状況データを前記不揮発性メモリに記録するデータ記録部を有する、車載記録システムであって、
前記第１の制御装置は、
前記トリガ状態設定部が前記トリガの状態を成立状態に設定してから所定時間が経過するまで前記トリガの状態を成立状態に維持し、前記所定時間が経過した後に前記トリガの状態を成立状態から非成立状態に変更するラッチ処理を、前記複数のイベントそれぞれの前記トリガについて行うラッチ処理部を有することを特徴とする、車載記録システムが提供される。

第１の態様によれば、前記イベント発生判定部が前記複数のイベントのうちいずれかのイベント（以下、「第１のイベント」と称する）が発生したと判定した場合、前記第１のイベントに対応するトリガの成立状態を搬送する通信フレーム（第１の通信フレーム）が前記送信処理部により送信される。また、前記イベント発生判定部が前記第１のイベントが発生したと判定した場合、前記第１のイベントに対応するトリガの成立状態は、前記所定時間が経過するまで前記ラッチ処理部により維持される。

そのため、前記イベント発生判定部が前記第１のイベントが発生したと判定した後に前記第１のイベントとは別のイベント（以下、「第２のイベント」と称する）が前記所定時間内に発生したとすると、前記送信処理部は、先発の前記第１のイベントに対応するトリガの成立状態と後発の前記第２のイベントに対応するトリガの成立状態とを搬送する通信フレーム（第２の通信フレーム）を、前記第１の車載ネットワークに送信できる。

したがって、前記ゲートウェイ装置が前記第１の通信フレームを前記第２の車載ネットワークに中継するまでに前記第２の通信フレームを前記第１の車載ネットワークから受信することによって、前記第１の通信フレームが前記第２の車載ネットワークに中継されなくても、前記第２の通信フレームは前記第２の車載ネットワークに中継される。よって、異なるイベントが連続して発生しても、前記ゲートウェイ装置は、先発の前記第１のイベントに対応するトリガの成立状態を前記第２の車載ネットワーク側に中継できる。

また、本発明の第２の態様では、
前記所定時間は、通信フレームが前記第１の車載ネットワークに送信されてから前記ゲートウェイ装置に受信されるまでの第１の遅延時間と、通信フレームが前記ゲートウェイ装置によって前記第１の車載ネットワークから前記第２の車載ネットワークに中継されるまでの第２の遅延時間との合計時間以上である。

第２の態様によれば、前記イベント発生判定部が前記第１のイベントが発生したと判定した場合、前記第１のイベントに対応する前記トリガの成立状態は、前記合計時間以上前記ラッチ処理部により維持される。そのため、前記イベント発生判定部が前記第１のイベントが発生したと判定した後に前記第１のイベントとは別の第２のイベントが前記合計時間以上遅れて発生したとしても、前記送信処理部は、先発の前記第１のイベントに対応するトリガの成立状態と後発の前記第２のイベントに対応するトリガの成立状態とを搬送する第２の通信フレームを、前記第１の車載ネットワークに送信できる。したがって、異なるイベントが前記合計時間内で連続して発生しても、前記ゲートウェイ装置は、先発の前記第１のイベントに対応するトリガの成立状態を前記第２の車載ネットワーク側に中継できる。

本発明の他の態様は、その他、車載制御装置として実現が可能である。

本発明の態様によれば、異なるイベントが連続して発生しても、ゲートウェイ装置が先発のイベントに対応するトリガの成立状態を中継できる。

異なるイベントが連続して発生した場合に送信ＥＣＵが通信フレームを送信する動作の一例（比較例）を示すタイミングチャートである。 車載記録システムの構成の一例を概略的に示す構成図である。 ＣＡＮプロトコルにおけるフレームタイプの一例を示す図である。 情報記録ＥＣＵのハードウェア構成の一例を概略的に示す構成図である。 各種検出・計測装置の構成の一例を概略的に示す構成図である。 一実施形態に係るＥＣＵの機能ブロックの一例を示す図である。 一実施形態に係るＥＣＵの各機能部による処理の一例を概念的に示すフローチャートである。 イベント発生判定部及びトリガ状態設定部による処理の一例を概念的に示すフローチャートである。 ラッチ処理部による処理の一例を概念的に示すフローチャートである。 一実施形態に係る情報記録ＥＣＵの機能ブロックの一例を示す図である。 イベント検出部によるイベント検出処理の一例を概念的に示すフローチャートである。 記録処理部によるデータ記録処理の一例を概念的に示すフローチャートである。 記録処理部によるデータ記録処理の他の例を概念的に示すフローチャートである。 一実施形態に係る車載記録システムの動作の一例を説明するためのタイミングチャートである。

以下、図面を参照して発明を実施するための形態について説明する。

図２は、本実施形態に係る車載記録システム１の構成の一例を概略的に示す構成図である。車載記録システム１は、車両に搭載され、予め規定された種類のイベントを検出すると、イベントの種類毎に予め規定された、車両又は前記車両の乗員の状況を表す状況データ（以下、「車両データ」とも称する）を記録する。以下、「車両」は、特に断らない限り、車載記録システム１が搭載される車両を指す。

なお、「イベント」とは、例えば、車両を制御するために算出される制御値、車両乗員（運転者等）の操作に応じて出力される操作信号等が引き起こす車両のイベントである。検出対象のイベントの種類は、解析目的等に応じて、予め規定される。例えば、検出対象のイベントには、特定の条件が成立した際に実行される特定の運転支援機能（警報制御機能や介入制御機能等）の作動が含まれる。警報制御機能は、車両前方の障害物との衝突回避のための警報（以下、「ＰＣＳ警報」と称する）、ＬＤＡ（Ｌａｎｅ Ｄｅｐａｒｔｕｒｅ Ａｌｅｒｔ）、ＣＴＡ（Ｃｒｏｓｓ Ｔｒａｆｆｉｃ Ａｌｅｒｔ）等を含む。また、介入制御機能は、運転者による操作とは無関係に実行される制御機能であり、車両前方の障害物との衝突回避のための自動ブレーキ（以下、ＰＣＳブレーキと称する）、ＶＳＣ（Ｖｅｈｉｃｌｅ Ｓｔａｂｉｌｉｔｙ Ｃｏｎｔｒｏｌ）、ＡＢＳ（Ａｎｔｉ−ｌｏｃｋ Ｂｒａｋｅ Ｓｙｓｔｅｍ）、ＴＲＣ（Ｔｒａｃｔｉｏｎ Ｃｏｎｔｒｏｌ）、ＬＫＡ（Ｌａｎｅ Ｋｅｅｐｉｎｇ Ａｓｓｉｓｔ）等を含む。また、検出対象のイベントには、例えば、特定の操作に起因するイベントが含まれうる。特定の操作に起因するイベントは、アクセル信号（０より大きいアクセル開度）とブレーキ信号（０より大きいブレーキペダル操作量）が同時発生すること、Ｎレンジでアクセル開度が中開度以上になること、急制動（雨天時にＡＢＳが作動する程度の制動）、緊急制動（急制動よりも緊急な制動）、急旋回等を含む。また、イベントには、例えば、車両と他の物体との衝突が検知されたことや、車両が特定の地点を通過することなども含まれる。以下、検出対象のイベントは、Ｊ種類（Ｊは、２以上の整数を表す）である前提で説明を行う。また、「検出対象」は、「イベントの発生有無の判定対象」と言い換え可能である。

また、「車両の状況」とは、車両の運動状況（センサ値や算出値に基づく加速度、速度等）車両の制御状況（制御の作動指令、指令値等）、車両の走行状況（センサ値や算出値に基づく先行車との距離、走行レーン等）、車両の操作状況（センサ値に基づくアクセル開度やブレーキ操作量等）、車両の環境状況（センサ値に基づく室内温度、室外温度、雨滴の有無等）を含む概念である。「車両の乗員の状況」とは、車両の乗員（運転者を含む）の状態（例えば、カメラセンサから得られる運転者の画像等）を含む概念である。記録対象となる車両データの種類は、上述の如く、イベントの種類毎に予め規定される。これは、イベントの種類によって、解析に有用となる車両データの種類が異なり得るからである。また、ある１つのイベントに対する記録対象となる車両データの種類は、２種類以上であってもよい。

車載記録システム１は、図２に示すように、車載ネットワークの一例であるＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）９と、ゲートウェイ装置９４と、ゲートウェイ装置９４を介して接続された情報記録ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）６及び各種ＥＣＵ７と、情報記録ＥＣＵ６及び各種ＥＣＵ７と通信可能に接続される各種検出・計測装置８とを含む。情報記録ＥＣＵ６は、例えば、車室内のセンターコンソール下部に設けられる。

ＣＡＮ９は、ＣＡＮバス９１〜９３を含む。ＣＡＮバス９１〜９３は、それぞれ、ゲートウェイ装置９４を介して接続される。各種ＥＣＵ７は、ＣＡＮバス９１又はＣＡＮバス９２に接続されると共に、情報記録ＥＣＵ６は、ＣＡＮバス９３に接続され、情報記録ＥＣＵ６及び各種ＥＣＵ７は、ゲートウェイ装置９４を介して、ＣＡＮプロトコルによる相互通信が可能に接続されている。

なお、情報記録ＥＣＵ６及び各種ＥＣＵ７の接続態様は一例である。各種ＥＣＵ７のいずれか一つは、車両又は前記車両の乗員の状況を表す車両データを不揮発性メモリに記録するためのトリガの状態を第１の車載ネットワークに送信する第１の制御装置又は車載制御装置の一例である。ゲートウェイ装置９４は、第１の車載ネットワークに送信されたトリガ（詳細は後述）の状態を第１の車載ネットワークから第２の車載ネットワークに中継するゲートウェイ装置の一例である。情報記録ＥＣＵ６は、ゲートウェイ装置によって第１の車載ネットワークから第２の車載ネットワークに中継されたトリガの状態を第２の車載ネットワークから受信する第２の制御装置の一例である。ＣＡＮバス９１又はＣＡＮバス９２は、第１の車載ネットワークの一例であり、ＣＡＮバス９３は、第２の車載ネットワークの一例である。

ＣＡＮプロトコルの標準フォーマットにおけるＣＡＮフレーム（データフレーム）は、図３（ＣＡＮプロトコルにおけるフレームタイプの一例を示す図）に示すような構造を有する。具体的には、ＳＯＦ（Ｓｔａｒｔ Ｏｆ Ｆｒａｍｅ、１ビット）、ＩＤ（１１ビット）、ＲＴＲ（１ビット）、コントロールフィールド（６ビット）、データフィールド（０〜６４ビット）、ＣＲＣシーケンス（１５ビット）、ＣＲＣデリミタ（１ビット）、ＡＣＫスロット（１ビット）、ＡＣＫデリミタ（１ビット）、ＥＯＦ（Ｅｎｄ Ｏｆ Ｆｒａｍｅ、７ビット）から構成される。ＣＡＮフレームにより送信されるデータは、データフィールドに含まれ、ＣＡＮフレームは、１バイト単位で最大８バイトのデータまで送信することができる。ＣＡＮフレームに含まれるデータの長さは、コントロールフィールド内の４ビットのＤＬＣ（Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）により０〜８の間で設定される。

ＩＤは、データ内容や送信ノード等を識別するために使用されると共に、ＣＡＮ９における通信調停（複数のノードから同時に通信フレームがＣＡＮバス９１〜９３に出力された場合の調停）の優先順位を決定する機能を有する（ＩＤがより小さいほど、優先順位が高い）。１１ビット長のＩＤは、０ｘ０〜０ｘ７ＦＦ（１６進数）の範囲を有するため、最大で２０４８種類の識別が可能なＩＤを割り当てることができる。また、ＣＡＮプロトコルの拡張フォーマットにおけるＣＡＮフレーム（不図示）では、標準フォーマットにおけるＩＤに対応するベースＩＤ（１１ビット）に加えて、拡張ＩＤ（１８ビット）が設けられる。そのため、ベースＩＤと拡張ＩＤを併せた２９ビット長のＩＤは、０ｘ０〜１ＦＦＦＦＦＦＦ（１６進数）の範囲を有するため、最大で約５４０万種の識別が可能なＩＤを割り当てることができる。

このように、情報記録ＥＣＵ６及び各種ＥＣＵ７は、予め割り当てられたＩＤに従い、ＣＡＮ９におけるＣＡＮフレームの送受信を行うことにより、ＣＡＮ９（ＣＡＮバス９１、９２、９３）上のＣＡＮフレームを識別して必要なデータを受信することができる。以下、標準フォーマットにおけるＩＤ、及び拡張フォーマットにおけるベースＩＤ及び拡張ＩＤを併せたものを「ＣＡＮ−ＩＤ」と称する。

図２において、ゲートウェイ装置９４は、中継処理部９５を備える。中継処理部９５は、ＣＡＮバス９１又はＣＡＮバス９２から受信した第１のＣＡＮフレームをＣＡＮバス９３に中継するまでに、当該第１のＣＡＮフレームとは別の第２のＣＡＮフレームをＣＡＮバス９１又はＣＡＮバス９２から受信した場合、当該第１のＣＡＮフレームを中継せずに当該第２のＣＡＮフレームをＣＡＮバス９１又はＣＡＮバス９２からＣＡＮバス９３に中継する。第２のＣＡＮフレームは、第１のＣＡＮフレームと同一のＣＡＮ−ＩＤが付与されたものであることを前提とする。第１のＣＡＮフレームは、第１の通信フレームの一例であり、第２のＣＡＮフレームは、第２の通信フレームの一例である。

図４は、情報記録ＥＣＵ６のハードウェア構成の一例を概略的に示す構成図である。

情報記録ＥＣＵ６は、内部バス１９で接続されるＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、不揮発性メモリ１４、時計１５、通信インターフェース１７と、通信インターフェース１７に接続される送受信部２５を含む。

不揮発性メモリ１４は、例えばＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）等である。不揮発性メモリ１４は、搭載スペースやコストの観点から、例えば、数１０ＫＢから数１００ＫＢ程度の比較的低容量のものが採用される場合がある。また、送受信部２５は、ＣＡＮトランシーバー、ＣＡＮドライバを含み、ＣＡＮバス９３に接続される。また、送受信部２５は、各種検出・計測装置８と任意の通信手段（例えば、ＣＡＮ９、ＬＩＮ（Ｌｏｃａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｎｅｔｗｏｒｋ）、１対１の通信線等）を用いて通信可能な送受信部を含む。

図５は、各種検出・計測装置８の構成の一例を概略的に表す構成図である。

各種検出・計測装置８は、車両に搭載される各種センサ等であり、図２（点線矢印）で示すように、任意の通信手段（例えば、ＣＡＮ９、ＬＩＮ、１対１の通信線等）を介して、情報記録ＥＣＵ６及び各種ＥＣＵ７（ＥＣＵ７Ａ−１〜７Ａ−Ｎ、７Ｂ−１〜７Ｂ−Ｍ）と通信可能に接続される。各種検出・計測装置８は、一例として、前方レーダセンサ８−１、前方カメラセンサ８−２、...、加速度センサ８−Ｋを含む。以下、検出・計測装置８−ｈ（ｈ＝１，２，...，Ｋ）は、検出・計測装置８−１〜８−Ｋの何れか任意の１つを指す。

図２に戻り、各種ＥＣＵ７は、車両制御を実行する制御装置であり、車両に搭載されるＥＣＵのうち、予め規定された種類のイベントに関連する制御を実行するＥＣＵである。各種ＥＣＵ７は、それぞれ、１種類以上のイベントに関連する制御を実行する。各種ＥＣＵ７は、運転支援機能の作動等のイベントに関連する制御を実行するＥＣＵ７−１〜７−Ｎを含む。一例として、各種ＥＣＵ７は、ＰＣＳ−ＥＣＵ７−１、ＬＫＡ−ＥＣＵ７−２、ブレーキＥＣＵ７−３、...、エンジンＥＣＵ７−Ｎを含む。以下、ＥＣＵ７−ｉ（ｉ＝１，２，...，Ｎ）は、ＥＣＵ７−１〜７−Ｎの何れか任意の１つを指す。

ＰＣＳ−ＥＣＵ７−１は、ＰＣＳ警報の機能及びＰＣＳブレーキの機能に関連する制御（ＰＣＳ警報の機能及びＰＣＳブレーキの機能を実現するための制御）を実行する。また、ＬＫＡ−ＥＣＵ７−２は、ＬＫＡの機能に関連する制御（ＬＫＡの機能を実現するための制御）を実行する。また、ブレーキＥＣＵ７−３は、ＡＢＳの機能及びＶＳＣの機能に関連する制御（ＡＢＳの機能及びＶＳＣの機能を実現するための制御）を実行する。また、エンジンＥＣＵ７−Ｎは、ＴＲＣの機能に関連する制御（ＴＲＣの機能を実現するための制御）を実行する。

なお、各種ＥＣＵ７（ＥＣＵ７−ｉ）及び上述した各種検出・計測装置８（検出・計測装置８−ｈ）は、上述した車両データを生成する車両データ生成部を実現する。車両データ生成部が何れのＥＣＵ７−ｉ或いは検出・計測装置８−ｈにより実現されるかは、検出対象のイベントの種類毎に予め規定される車両データの種類（書き込み対象の車両データの種類）に応じて決まる。例えば、書き込み対象の車両データが車両の加速度である場合、車両データ生成部は、加速度センサ８−Ｋにより実現される。また、書き込み対象の車両データがブレーキＥＣＵ７−３の制御指令値である場合、車両データ生成部は、ブレーキＥＣＵ７−３により実現される。また、書き込み対象の車両データとしては、前方レーダセンサ８−１の検出情報、前方カメラセンサ８−２の撮像画像、アクセル信号、駆動装置の制御指令値、各種制御関連のフラグの成立履歴、ダイアグ情報、車載バッテリの各種状態等が含まれ得る。

図６は、各種ＥＣＵ７（ＥＣＵ７−ｉ）の機能ブロック図である。ここでは、一例として、ＥＣＵ７−ｉがＰＣＳ−ＥＣＵ７−１である場合を中心に説明する。

なお、各種ＥＣＵ７（ＥＣＵ７−ｉ）のハードウェア構成は、情報記録ＥＣＵ６と同様であるため、図示を省略する。また、各種ＥＣＵ７（ＥＣＵ７−ｉ）における各機能は、ＲＯＭに格納される各種プログラムをＣＰＵ上で実行することにより実現することができる。

各種ＥＣＵ７（ＥＣＵ７−ｉ）は、ＲＯＭに格納される対応するプログラムをＣＰＵ上で実行することにより実現される機能部として、制御指令生成部７１、トリガ状態設定部７２、送信処理部７３、ラッチ処理部７４、イベント発生判定部７５を含む。

各種ＥＣＵ７（ＥＣＵ７−ｉ）が２種類以上のイベントに関連する制御を行う場合（例えば、複数の運転支援機能に関連する制御を行う場合）、制御指令生成部７１、トリガ状態設定部７２、ラッチ処理部７４、及びイベント発生判定部７５は、制御対象であるイベントの種類毎（運転支援機能毎）に設けられる。

制御指令生成部７１は、イベントに関連する制御指令（例えば、運転支援機能の作動に関連する制御指令や特定の操作に起因するイベントに対するフェールセーフ機能の作動に関連する制御指令等）を生成する。

ＰＣＳ−ＥＣＵ７−１における制御指令生成部７１は、"ＰＣＳ警報の作動"及び"ＰＣＳブレーキの作動"に関連する制御指令を生成する。具体的には、検出・計測装置８の少なくとも一つからの情報に基づき、ＰＣＳ警報の作動、及びＰＣＳブレーキの作動の要否を判定する。例えば、ＰＣＳ−ＥＣＵ７−１における制御指令生成部７１は、前方レーダセンサ８−１及び前方カメラセンサ８−２の少なくとも一方からの検出情報に基づき、車両が前方の障害物に衝突するまでの時間（ＴＴＣ：Ｔｉｍｅ Ｔｏ Ｃｏｌｌｉｓｉｏｎ）を算出する。そして、ＴＴＣが所定閾値Ｔｔｈ１以下になったとき、警報指令を生成し、後述する送信処理部７３が送受信部を介してブレーキＥＣＵ７−３に送信する。また、ＴＴＣがＴｔｈ２（＜Ｔｔｈ１）以下になったとき、自動ブレーキ指令を生成し、後述する送信処理部７３が送受信部を介してブレーキＥＣＵ７−３に送信する。ブレーキＥＣＵ７−３は、警報指令の受信に応じて、制御指令を生成し、警報ブザーを作動させる（ＰＣＳ警報を作動させる）。また、ブレーキＥＣＵ７−３は、自動ブレーキ指令の受信に応じて、制御指令（指令値）を生成し、各種バルブ、ポンプ、アキュムレータ等を含むブレーキアクチュエータの制御を行う。即ち、ブレーキＥＣＵ７−３は、運転者のブレーキ操作に応じた制御値とは異なる制御値に基づき、各車輪のホイルシリンダ圧を増圧させることにより、ＰＣＳブレーキを作動させる。

イベント発生判定部７５は、所定のイベントが車両で発生したか否かを判定する。例えば、ＰＣＳ−ＥＣＵ７−１におけるイベント発生判定部７５は、ＰＣＳ警報を作動させる警報指令を制御指令生成部７１が生成したか否かを判定する。また、ＰＣＳ−ＥＣＵ７−１におけるイベント発生判定部７５は、ＰＣＳブレーキを作動させる自動ブレーキ指令を制御指令生成部７１が生成したか否かを判定する。このように、各種ＥＣＵ７（ＥＣＵ７−ｉ）は、所定の複数のイベントに関連する制御を行う場合、当該複数のイベントが車両で発生したか否かをイベント毎に判定するイベント発生判定部を備える。

トリガ状態設定部７２は、情報記録ＥＣＵ６（後述するデータ記録部１０６）において、車両又は前記車両の乗員の状況を表す車両データを不揮発性メモリ１４に記録するためのトリガに関する情報（トリガ情報）を生成する。トリガ状態設定部７２は、イベント発生判定部７５が車両で発生したと判定したイベントに対応するトリガの状態を成立状態に設定する。例えば、ＰＣＳ−ＥＣＵ７−１におけるトリガ状態設定部７２は、ＰＣＳ警報を作動させる警報指令を制御指令生成部７１が生成したとイベント発生判定部７５が判定した場合、ＰＣＳ警報を作動させる警報指令の生成に対応するトリガの状態を成立状態に設定する。同様に、ＰＣＳ−ＥＣＵ７−１におけるトリガ状態設定部７２は、ＰＣＳブレーキを作動させる自動ブレーキ指令を制御指令生成部７１が生成したとイベント発生判定部７５が判定した場合、ＰＣＳブレーキを作動させる自動ブレーキ指令の生成に対応するトリガの状態を成立状態に設定する。

送信処理部７３は、複数のイベントそれぞれのトリガの状態（成立状態又は非成立状態）を搬送するＣＡＮフレームをＣＡＮバス９１又はＣＡＮバス９２に送信する。例えば、ＰＣＳ−ＥＣＵ７−１における送信処理部７３は、ＰＣＳ警報を作動させる警報指令に対応するトリガ（ＰＣＳ警報トリガ）の状態と、ＰＣＳブレーキを作動させる自動ブレーキ指令に対応するトリガ（自動ブレーキトリガ）の状態とを搬送するＣＡＮフレームをＣＡＮバス９１に送信する。

ラッチ処理部７４は、トリガ状態設定部７２がトリガの状態を成立状態に設定してから所定時間Ｓが経過するまで当該トリガの状態を成立状態に維持し、所定時間Ｓが経過した後に当該トリガの状態を成立状態から非成立状態に変更するラッチ処理を行う。例えば、ＰＣＳ−ＥＣＵ７−１におけるラッチ処理部７４は、トリガ状態設定部７２がＰＣＳ警報トリガの状態を成立状態に設定してから所定時間Ｓが経過するまで当該ＰＣＳ警報トリガの状態を成立状態に維持し、所定時間Ｓが経過した後に当該ＰＣＳ警報トリガの状態を成立状態から非成立状態に変更するラッチ処理を行う。同様に、ＰＣＳ−ＥＣＵ７−１におけるラッチ処理部７４は、トリガ状態設定部７２が自動ブレーキトリガの状態を成立状態に設定してから所定時間Ｓが経過するまで当該自動ブレーキトリガの状態を成立状態に維持し、所定時間Ｓが経過した後に当該自動ブレーキトリガの状態を成立状態から非成立状態に変更するラッチ処理を行う。このように、各種ＥＣＵ７（ＥＣＵ７−ｉ）は、トリガ状態設定部７２がトリガの状態を成立状態に設定してから所定時間Ｓが経過するまで当該トリガの状態を成立状態に維持し、所定時間Ｓが経過した後に当該トリガの状態を成立状態から非成立状態に変更するラッチ処理を、所定の複数のイベントそれぞれのトリガについて行うラッチ処理部を備える。

図７は、ＥＣＵ７の各機能部によるメイン処理ルーチンの一例を概念的に示すフローチャートである。本フローチャートによるメイン処理ルーチンは、車両の起動から停止までの間で、所定周期毎に繰り返し実行される。即ち、車両の起動に伴い実行されると共に、その後、車両の停止までの所定周期毎に繰り返し実行される。

「車両の起動」とは、車両を、運転者の操作に応じた走行が可能な状態にすることを意味し、例えば、エンジン車におけるイグニッションオン（ＩＧ−ＯＮ）や、電動車両（ハイブリッド車、レンジエクステンダ車等を含む）における車両全体を協調制御する制御装置（例えば、ＨＶ−ＥＣＵ等）を起動すること等を含む概念である。また、「車両の停止」とは、運転者の操作に応じた走行が不可能な状態にすることを意味し、例えば、エンジン車におけるイグニッションオフ（ＩＧ−ＯＦＦ）や、電動車両における上記制御装置の停止等を含む概念である。

ステップＳ１００１にて、イベントの種類毎に設けられた制御指令生成部７１のそれぞれは、ステップＳ１００２のトリガ判定処理をするための検出情報を、検出・計測装置８の少なくとも一つから取得する検出処理を行う。

ステップＳ１００２にて、イベントの種類毎に設けられたイベント発生判定部７５の判定結果を参照して、イベントの種類毎に設けられたトリガ状態設定部７２は、車両又は前記車両の乗員の状況を表す車両データを不揮発性メモリ１４に記録するためのトリガに関する情報（トリガ情報）を生成するトリガ判定処理を行う。

図８は、イベント発生判定部７５及びトリガ状態設定部７２によるトリガ判定処理の一例を概念的に示すフローチャートであり、図７のステップＳ１００２の詳細を示すものである。図８のトリガ判定処理は、イベントの種類毎に設けられたイベント発生判定部７５及びトリガ状態設定部７２により、イベントの種類毎に実行される。

なお、トリガ成立フラグＦ１−１〜Ｆ１−Ｊは、Ｊ種類ある検出対象のイベントの種類毎に設けられ、トリガが成立しているか否かを表すフラグである。以下、トリガ成立フラグＦ１−ｋ（ｋ＝１，２，...，Ｊ）は、トリガ成立フラグＦ１−１〜Ｆ１−Ｊの何れか任意の１つを指す。

トリガ成立フラグＦ１−ｋが"１"であるとは、トリガの状態が成立状態であることを意味し、トリガ成立フラグＦ１−ｋが"０"であるとは、トリガの状態が非成立状態であることを意味する。車両の起動の時のトリガ成立フラグＦ１−ｋの初期値は、"０"である。

ステップＳ１０１にて、イベント発生判定部７５は、トリガを成立させるイベントが発生したか否かを判定し、例えば、イベントの制御に関連する制御指令を制御指令生成部７１が生成したか否かを判定する。例えば、ＰＣＳ−ＥＣＵ７−１のＰＣＳ警報に対応するイベント発生判定部７５は、ＰＣＳ警報の作動に関連する制御指令（例えば、ＰＣＳ警報を作動させる警報指令）を生成したか否かを判定する。同様に、ＰＣＳ−ＥＣＵ７−１のＰＣＳブレーキに対応するイベント発生判定部７５は、ＰＣＳブレーキの作動に関連する制御指令（例えば、ＰＣＳブレーキを作動させる自動ブレーキ指令）を生成したか否かを判定する。イベント発生判定部７５は、かかる判定条件を満足する場合、ステップＳ１０２の処理に進み、満足しない場合、ステップＳ１０２の処理を実行せずに、トリガ判定処理を終了する。

ステップＳ１０２にて、トリガ状態設定部７２は、トリガ成立フラグＦ１−ｋを"１"に設定して、今回のトリガ判定処理を終了する。

このように、トリガ状態設定部７２は、イベント発生判定部７５の判定結果を参照して、トリガの成否を表すトリガ成立フラグＦ１−ｋを含むトリガ情報を、定期的に生成する。

そして、図７のステップＳ１００３にて、ラッチ処理部７４は、トリガ状態設定部７２がトリガの状態を成立状態に設定してから所定時間Ｓが経過するまで当該トリガの状態を成立状態に維持し、所定時間Ｓが経過した後に当該トリガの状態を成立状態から非成立状態に変更するラッチ処理を行う。

次に、図７のステップＳ１００４において、送信処理部７３は、複数のイベントそれぞれのトリガの状態（成立状態又は非成立状態）を搬送するＣＡＮフレームを、送受信部を介してＣＡＮバス９１又はＣＡＮバス９２に送信する送信処理を行う。

送信処理部７３は、制御指令生成部７１が生成する制御指令と、イベント発生判定部７５の判定結果を参照してトリガ状態設定部７２が生成するトリガ情報とを、送受信部を介して対象となる送信先に向けて送信する処理を実行する。例えば、制御対象が有線で各種ＥＣＵ７（ＥＣＵ７−ｉ）と通信可能に接続される場合、送信処理部７３は、制御指令生成部７１が生成した制御指令を、有線を介してかかる制御対象に送信する。また、送信処理部７３は、トリガ情報を含むＣＡＮフレームを、送受信部を介してＣＡＮ９に出力する（ＣＡＮ９を介して情報記録ＥＣＵ６に送信する）。

図９は、ラッチ処理部７４によるラッチ処理の一例を概念的に示すフローチャートであり、図７のステップＳ１００３の詳細を示すものである。図９のラッチ処理は、イベントの種類毎に設けられたラッチ処理部７４により、イベントの種類毎に実行される。

ステップＳ２０２にて、ラッチ処理部７４は、現時点のトリガ成立フラグＦ１−ｋの値に従って、現時点のトリガの状態が成立状態であるか非成立状態であるのか判定する。ラッチ処理部７４は、トリガ成立フラグＦ１−ｋの値が"０"であることを検出することによって、トリガの状態が非成立状態であると判定した場合、今回のラッチ処理を終了する。一方、ラッチ処理部７４は、トリガ成立フラグＦ１−ｋの値が"１"であることを検出することによって、トリガの状態が成立状態であると判定した場合、ステップＳ２０３の処理に進む。

ステップＳ２０３にて、ラッチ処理部７４は、今回のメイン処理ルーチン（図７参照）において、トリガが新規に成立したものか否かを判定する。つまり、ラッチ処理部７４は、今回のメイン処理ルーチン実行中の図８のトリガ判定処理のステップＳ１０２にて、トリガ成立フラグＦ１−ｋを"０"から"１"に設定したか否か（トリガの状態を非成立状態から成立状態に設定したか否か）を判定する。

ステップＳ２０３にて、ラッチ処理部７４は、今回のメイン処理ルーチンにおいてトリガ成立フラグＦ１−ｋを"０"から"１"に設定したと判定した場合、ステップＳ２０４の処理に進む。

ステップＳ２０４にて、ラッチ処理部７４は、トリガ成立フラグＦ１−ｋの値"１"を維持する時間（ラッチ時間ｔ）をリセットして、ステップＳ２０６の処理に進む。

ラッチ処理部７４は、ステップＳ２０６にてトリガの状態をラッチし、ステップＳ２０７にてラッチ時間ｔをインクリメントする。これにより、ラッチ処理部７４は、トリガ成立フラグＦ１−ｋを"１"に維持できる（トリガの状態を成立状態に維持できる）。ラッチ処理部７４は、ステップＳ２０７の処理後、今回のラッチ処理を終了する。

一方、ステップＳ２０３にて、ラッチ処理部７４は、前回以前のメイン処理ルーチンにおいてトリガ成立フラグＦ１−ｋを"０"から"１"に設定したと判定した場合、ステップＳ２０５の処理に進む。

ステップＳ２０５にて、ラッチ処理部７４は、ラッチ時間ｔが上述の所定時間Ｓ以下か否か、言い換えれば、ラッチ時間ｔが所定時間Ｓを経過したか否かを判定する。

ラッチ処理部７４は、ラッチ時間ｔが所定時間Ｓを経過していないとステップＳ２０５にて判定した場合、ステップＳ２０６の処理に進み、ステップＳ２０７の処理に進む。これにより、ラッチ処理部７４は、トリガ成立フラグＦ１−ｋを"１"に維持できる（トリガの状態を成立状態に維持できる）。

一方、ラッチ処理部７４は、ラッチ時間ｔが所定時間Ｓを経過したとステップＳ２０５にて判定した場合、ステップＳ２０８の処理に進む。ステップＳ２０８にて、ラッチ処理部７４は、トリガのラッチ状態を解除する。つまり、ラッチ処理部７４は、トリガ成立フラグＦ１−ｋを"１"から"０"にリセットする（トリガの状態を成立状態から非成立状態に変更する）。ラッチ処理部７４は、ステップＳ２０８の処理後、今回のラッチ処理を終了する。

したがって、図９に示される処理によれば、ラッチ処理部７４は、トリガ状態設定部７２がトリガの状態を成立状態に設定してから所定時間Ｓが経過するまで当該トリガの状態を成立状態に維持し、所定時間Ｓが経過した後に当該トリガの状態を成立状態から非成立状態に変更するラッチ処理を実行できる。

次に、図１０を参照して、情報記録ＥＣＵ６の具体的な処理内容について説明する。

図１０は、情報記録ＥＣＵ６の機能ブロック図である。車両データ記憶部１１０を除く各機能は、ＲＯＭ１３に格納される各種プログラムをＣＰＵ１１上で実行することにより実現可能である。また、車両データ記憶部１１０は、不揮発性メモリ１４上の予め規定された記憶領域により実現される。

制御指令生成部１０１は、各種ＥＣＵ７（ＥＣＵ７−ｉ）の制御指令生成部７１と同様、予め規定された種類のイベントに関連する制御指令を生成する。但し、制御指令生成部１０１は、各種ＥＣＵ７（ＥＣＵ７−ｉ）とは異なる種類のイベントに関連する制御指令を生成する。制御指令生成部１０１は、一例として、"乗員保護補助装置（例えば、シートベルトプリテンショナ）の作動"に関連する制御指令を生成する。制御指令生成部１０１は、予め規定された作動条件が成立したときに、かかる制御指令（作動指令）を生成し、後述する送信処理部１０３が送受信部２５を介して乗員保護補助装置に送信する。

トリガ状態設定部１０２は、各種ＥＣＵ７（ＥＣＵ７−ｉ）のトリガ状態設定部７２及びイベント発生判定部７５と同様、イベント発生判定部１０５の判定結果を参照して、予め規定された種類のイベント（"乗員保護補助装置の作動"）に対応する車両データを記録するためのトリガに関する情報（トリガ情報）を生成する。具体的には、図８に示すフローチャート（ステップＳ１０１，Ｓ１０２）に従い、トリガ成立フラグＦ１−Ｊを設定し、トリガ成立フラグＦ１−Ｊを含むトリガ情報を生成する。

なお、情報記録ＥＣＵ６は、検出対象の種類のイベントに関連する制御（"乗員保護補助装置"の作動に関連する制御）を行わない態様であってもよい。即ち、情報記録ＥＣＵ６は、各種ＥＣＵ７（ＥＣＵ７−ｉ）が制御対象とする種類のイベントを検出し、検出したイベントの種類に対応する車両データを記録する処理に特化した構成であってもよい。かかる場合、制御指令生成部１０１、トリガ状態設定部１０２及びイベント発生判定部１０５は省略される。

送信処理部１０３は、制御指令生成部１０１が生成する制御指令を、送受信部を介して制御対象である送信先に向けて出力する処理を実行する。

受信処理部１０４は、送受信部２５を介してＣＡＮ９から受信する通信フレーム（ＣＡＮフレーム）を受信する処理を実行する。

データ記録部１０６は、検出対象のイベントの種類毎に設けられるデータ記録部１０６−１〜１０６−Ｊを含む。データ記録部１０６−１〜１０６−Ｊは、各種ＥＣＵ７（ＥＣＵ７−ｉ）に対して設けられるデータ記録部１０６−１〜１０６−Ｈと、情報記録ＥＣＵ６自身に対して設けられるデータ記録部１０６−Ｊを含む（Ｈ＝Ｊ−１）。以下、データ記録部１０６−ｋ（ｋ＝１，２，...，Ｊ）は、データ記録部１０６−１〜１０６−Ｊのうちの任意の１つを指す。データ記録部１０６は、第２の車載ネットワークから受信した通信フレーム内の複数のイベントそれぞれのトリガのうち、成立状態のトリガに対応する車両データを不揮発性メモリに記録するデータ記録部の一例である。

データ記録部１０６は、イベント検出部１０７、記録処理部１０８を含む。イベント検出部１０７及び記録処理部１０８は、それぞれ、データ記録部１０６−１〜１０６−Ｊに対応する（即ち、検出対象のイベントの種類毎に設けられる）イベント検出部１０７−１〜１０７−Ｊ、及び記録処理部１０８−１〜１０８−Ｊを含む。以下、イベント検出部１０７−ｋは、イベント検出部１０７−１〜１０７−Ｊのうちの任意の１つを指す。また、記録処理部１０８−ｋは、記録処理部１０８−１〜１０８−Ｊのうちの任意の１つを指す。

イベント検出部１０７−１〜１０７−Ｊ、記録処理部１０８−１〜１０８−Ｊの各機能は、扱うイベントの種類が異なるだけであり、実質的に同一である。従って、以下では、特に断わらない限り、イベント検出部１０７−ｋ、記録処理部１０８−ｋについて説明する。

イベント検出部１０７−ｋは、受信処理部１０４が、送受信部２５及びＣＡＮ９を介してＥＣＵ７から受信するトリガ情報、或いはトリガ状態設定部１０２により生成されたトリガ情報に基づき、車両データを記録するためのトリガに対応する種類のイベントの検出を行う。そして、特定の場合（後述するマスク条件が成立する場合）を除き、対応する種類のイベントを検出すると、検出時の車両データ（対応する種類のイベントに対して予め規定された種類の車両データ）を車両データ記憶部１１０内に記録するための書き込み要求を出力する。以下、図１１を参照して、イベント検出部１０７−ｋによる処理について説明する。

図１１は、イベント検出部１０７−ｋによる処理の一例を概念的に示すフローチャートである。本フローチャートによる処理は、車両の起動から停止の間で、所定周期毎に繰り返し実行される。

ステップＳ３０１にて、イベント検出部１０７−ｋは、受信処理部１０４が、送受信部２５を介して、対応する種類のイベントに関するトリガ情報を受信したか否かを判定する。イベント検出部１０７−ｋは、トリガ情報を受信した場合、ステップＳ３０２に進み、トリガ情報を受信していない場合、今回の処理を終了する。

なお、イベント検出部１０７−Ｊは、"乗員保護補助装置の作動"を検出するため、トリガ状態設定部１０２により生成されるトリガ情報を使用する。そのため、イベント検出部１０７−ＪによるステップＳ３０１の処理は、スキップされてもよいし、常に、トリガ情報を受信したとみなして、ステップＳ３０２に進む処理を行ってもよい。

ステップＳ３０２にて、イベント検出部１０７−ｋは、対応する種類のイベントに関するトリガ情報に含まれるトリガ成立フラグＦ１−ｋが"１"であるか否かを判定する。イベント検出部１０７−ｋは、トリガ成立フラグＦ１−ｋが"１"である場合、対応する種類のイベントに関するトリガが成立した、即ち、対応する種類のイベントを検出したと判断してステップＳ３０３に進み、"１"でない場合（"０"である場合）、今回の処理を終了する。

ステップＳ３０３にて、イベント検出部１０７−ｋは、マスク条件が成立するか否かを判定する。マスク条件とは、後述するように、定期的にバッファリングされる車両データを重複して車両データ記憶部１１０に書き込まないようにするための条件である。例えば、マスク条件は、「本フローチャートによる処理により、対応する種類のイベントを連続して検出していること」等である。イベント検出部１０７−ｋは、マスク条件が成立しない場合、ステップＳ３０４に進み、マスク条件が成立する場合、今回の処理を終了する。

ステップＳ３０４にて、イベント検出部１０７−ｋは、書き込み要求を出力して、今回の処理を終了する。

図１０に戻り、記録処理部１０８−ｋは、イベント検出部１０７−ｋが対応する種類のイベントを検出すると、検出時に対応した所定期間において、対応する車両データを車両データ記憶部１１０に記録する。具体的には、所定周期毎に、対応する種類のイベントに対して予め規定された車両データをバッファリングすると共に、かかるバッファリング中にイベント検出部１０７−ｋから書き込み要求が出力されると、バッファリングされた車両データを車両データ記憶部１１０上に割り当てられた記録領域に書き込む処理を実行する。以下、図１２を参照して、記録処理部１０８−ｋによる処理フローについて説明する。

なお、「検出時に対応した所定期間」とは、例えば、対応する種類のイベントが検出された時点の前後を含む期間、検出された時点から始まる期間、検出された時点で終了する期間、検出された時点より後から始まる期間、及び検出された時点より前に終了する期間等を含む概念である。即ち、イベントの種類によって、解析に有用となる車両データの期間が異なり得るため、かかる所定期間の長さ及び開始タイミング等は、イベントの種類毎に予め規定される。但し、本実施形態では、上述の如く、所定周期毎に実行されるバッファリング中に対応するイベントが検出された場合に、バッファリングされた対応する車両データが記録される、即ち、対応する種類のイベントが検出された時点の前後を含む所定期間の車両データが記録される。

図１２は、記録処理部１０８−ｋによるデータ記録処理の一例を概念的に示すフローチャートである。本フローチャートによる処理は、車両の起動から停止までの間で、所定周期毎に実行される。

ステップＳ４０１にて、記録処理部１０８−ｋは、タイマをセットする。

なお、タイマは、予め規定された時間（記録時間Ｔ１）経過するとタイムアウトし、記録時間Ｔ１は、対応するイベントの種類毎に予め規定される。

ステップＳ４０２にて、記録処理部１０８−ｋは、対応する種類のイベントに対して予め規定された車両データのバッファリングを開始する。車両データのバッファリングは、例えば、対応するイベントの種類毎に設定されるＲＡＭ１２内のリングバッファを用いて行われる。

ステップＳ４０３にて、記録処理部１０８−ｋは、タイマがタイムアウトしたか否かを判定する。記録処理部１０８−ｋは、タイムアウトした場合、ステップＳ４０４に進み、タイムアウトしていない場合、タイムアウトするまで処理を繰り返す。

ステップＳ４０４にて、記録処理部１０８−ｋは、対応する種類のイベントに対して予め規定された車両データのバッファリングを終了する。

ステップＳ４０５にて、記録処理部１０８−ｋは、本フローによる車両データのバッファリング中に、対応する種類のイベントに関するイベント検出部１０７−ｋから書き込み要求が出力されているか否かを判定する。記録処理部１０８−ｋは、書き込み要求が出力されている場合、ステップＳ４０６に進み、書き込み要求が出力されていない場合、今回の処理を終了する。

ステップＳ４０７にて、記録処理部１０８−ｋは、車両データ記憶部１１０の記録領域にリングバッファ内のバッファリングした車両データを書き込む処理を実行し、今回の処理を終了する。

このように、本フローによる処理よれば、対応する種類のイベントに対して予め規定された車両データのバッファリング中に、イベント検出部１０７−ｋが対応する種類のイベントを検出して書き込み要求を出力すると、バッファリングの終了後に、車両データ記憶部１１０上に割り当てられた記録領域にバッファリングされた車両データが記録される。

続いて、図１３は、記録処理部１０８−ｋによるデータ記録処理の他の例を概念的に示すフローチャートである。本フローチャートによる処理は、図１２と同様、車両の起動から停止までの間で、所定周期毎に実行される。

ステップＳ５０１にて、記録処理部１０８−ｋは、ステップＳ４０１と同様、タイマをセットする。

ステップＳ５０２にて、記録処理部１０８−ｋは、ステップＳ４０２と同様、対応する種類のイベントに対して予め規定された車両データのバッファリングを開始する。

ステップＳ５０３にて、記録処理部１０８−ｋは、タイマがタイムアウトしたか否かを判定する。記録処理部１０８−ｋは、タイムアウトした場合、ステップＳ５１０に進み、対応する種類のイベントに対して予め規定された車両データのバッファリングを終了して、今回の処理を終了する。記録処理部１０８−ｋは、タイムアウトしていない場合、ステップＳ５０４に進む。

ステップＳ５０４にて、記録処理部１０８−ｋは、対応する種類のイベントに関するイベント検出部１０７−ｋから書き込み要求が出力されたか否かを判定する。記録処理部１０８−ｋは、書き込み要求が出力されている場合、ステップＳ５０６に進み、書き込み要求が出力されていない場合、ステップＳ５０３に戻り、ステップＳ５０３、Ｓ５０４の処理を繰り返す。

ステップＳ５０６にて、記録処理部１０８−ｋは、車両データ記憶部１１０の記録領域にリングバッファ内のバッファリングした車両データを書き込む処理を開始する。

ステップＳ５０７にて、記録処理部１０８−ｋは、タイマがタイムアウトしたか否かを判定する。タイムアウトした場合、ステップＳ５０８に進み、タイムアウトしていない場合、タイムアウトするまで処理を繰り返す。

ステップＳ５０８にて、記録処理部１０８−ｋは、対応する種類のイベントに対して予め規定された車両データのバッファリングを終了する。

そして、ステップＳ５０９にて、記録処理部１０８−ｋは、書き込み処理が終了すると、今回の処理を終了する。

このように、本フローによる処理によれば、イベント検出部１０７−ｋが対応する種類のイベントを検出して書き込み要求を出力すると、即、車両データ記憶部１１０上に割り当てられた記録領域にバッファリング中の車両データの記録が開始される。特に、車両の衝突に関連する種類のイベント（例えば、"ＰＣＳブレーキの作動"等）の場合、バッファリング終了後に書き込む処理では、バッファリング中の衝突により車両データを車両データ記憶部１１０に記録できなくなる可能性もある。そのため、本フローによる処理を採用することでバッファリング中の車両データを確実に記録することができる。

記録処理部１０８−ｋは、対応する種類のイベントに対して割り当てた記録領域が車両データで一杯になると、新たにバッファリングした車両データを記録する場合、記録された古い車両データに対して上書きを行う。また、記録処理部１０８−ｋが記録した車両データは、例えば、車両に設けられるＤＬＣ３コネクタ等を介して外部ツール（故障診断用ツール）をＣＡＮ９に接続し、かかる外部ツールからコマンドを情報記録ＥＣＵ６に対して送信する等により、外部に取り出すことができる。

次に、図１４を参照して、本実施形態に係る車載記録システム１の動作タイミングチャートについて説明する。

図１４は、本実施形態に係る車載記録システム１の動作タイミングチャートである。図１４は、ＥＣＵ７が、先発イベントに対応する第１のトリガ３２１の状態「１」を含む第１の通信フレーム３３１を送信した後に、後発イベントに対応する第２のトリガ３２２の状態「１」を含む第２の通信フレーム３３２を送信する場合を例示する。この場合、ＥＣＵ７は、先発イベントが発生したと判定すると、先発イベントに対応する第１のトリガ３２１の状態を「１」に設定した第１の通信フレーム３３１を送信することで、当該先発イベントに対応する車両データを不揮発性メモリ１４に記録することを情報記録ＥＣＵ６に対して指令する。その後、ＥＣＵ７は、後発イベントが発生したと判定すると、後発イベントに対応する第２のトリガ３２２の状態を「１」に設定した第２の通信フレーム３３２を送信することで、当該後発イベントに対応する車両データを不揮発性メモリ１４に記録することを情報記録ＥＣＵ６に対して指令する。なお、図示の第１の通信フレーム３３１と第２の通信フレーム３３２は、いずれも、５つ分のトリガの状態を搬送可能なデータフレームの一例を模式的に表したものである。

以下、第１のトリガ３２１に対して設けられたイベント発生判定部７５を、イベント発生判定部７５−１とし、第２のトリガ３２２に対して設けられたイベント発生判定部７５を、イベント発生判定部７５−２とする。また、第１のトリガ３２１に対して設けられたトリガ状態設定部７２を、トリガ状態設定部７２−１とし、第２のトリガ３２２に対して設けられたトリガ状態設定部７２を、トリガ状態設定部７２−２とする。また、第１のトリガ３２１に対して設けられたラッチ処理部７４を、ラッチ処理部７４−１とする。

本実施形態によれば、ＥＣＵ７において、イベント発生判定部７５−１が第１のトリガ３２１に対応するイベントが発生したと判定した場合、トリガ状態設定部７２−１は、第１のトリガ３２１の状態を成立状態（トリガ成立フラグＦ１−１＝"１"）に設定する。そして、トリガ状態設定部７２−１により設定された第１のトリガ３２１の成立状態（トリガ成立フラグＦ１−１＝"１"）は、送信処理部７３により第１の通信フレーム３３１でＣＡＮバス９１に送信される一方で、ラッチ処理部７４−１により所定時間Ｓが経過するまで維持される。

そして、イベント発生判定部７５−１が第１のトリガ３２１に対応するイベントが発生したと判定した後に当該イベント（つまり、先発イベント）とは別の後発イベント（図１４の場合、第２のトリガ３２２に対応するイベント）が所定時間Ｓ内に発生したとする。この場合、送信処理部７３は、ラッチ処理部７４−１により維持されている第１のトリガ３２１の成立状態"１"と、トリガ状態設定部７２−２により設定された第２のトリガ３２２の成立状態"１"とを搬送する第２の通信フレーム３３２を、ＣＡＮバス９１に送信する。

したがって、第１のトリガ３２１の成立状態"１"を搬送する第１の通信フレーム３３１がゲートウェイ装置９４によりＣＡＮバス９３に中継されなくても、ゲートウェイ装置９４は、第１のトリガ３２１の成立状態"１"と第２のトリガ３２２の成立状態"１"とを搬送する第２の通信フレーム３３２をＣＡＮバス９３に中継できる。よって、情報記録ＥＣＵ６は、第１のトリガ３２１に対応する車両データと第２のトリガ３２２に対応する車両データとを不揮発性メモリ１４に記録できる。

また、例えば、所定時間Ｓは、通信フレームがＣＡＮバス９１に送信されてからゲートウェイ装置９４に受信されるまでの第１の遅延時間Ｕと、通信フレームがゲートウェイ装置９４によってＣＡＮバス９１からＣＡＮバス９３に中継されるまでの第２の遅延時間（つまり、中継遅延時間Ｔ）との合計時間（Ｕ＋Ｔ）以上に設定される。

所定時間Ｓがこのように設定されることで、ＥＣＵ７において、イベント発生判定部７５−１が第１のトリガ３２１に対応するイベントが発生したと判定した場合、第１のトリガ３２１の成立状態（トリガ成立フラグＦ１−１の状態"１"）は、合計時間（Ｕ＋Ｔ）以上、ラッチ処理部７４−１により維持される。そのため、イベント発生判定部７５−１が当該イベントが発生したと判定した後に当該イベント（つまり、先発イベント）とは別の後発イベントが合計時間（Ｕ＋Ｔ）以上遅れて発生したとしても、送信処理部７３は、ラッチ処理部７４−１により維持されている第１のトリガ３２１の成立状態"１"と、トリガ状態設定部７２−２により設定された第２のトリガ３２２の成立状態"１"とを搬送する第２の通信フレーム３３２を、ＣＡＮバス９１に送信できる。

したがって、異なるイベントが合計時間（Ｕ＋Ｔ）内で連続して発生しても、ゲートウェイ装置９４は、第１のトリガ３２１の成立状態"１"と第２のトリガ３２２の成立状態"１"とを搬送する第２の通信フレーム３３２をＣＡＮバス９３に中継できる。よって、情報記録ＥＣＵ６は、第１のトリガ３２１に対応する車両データと第２のトリガ３２２に対応する車両データとを不揮発性メモリ１４に記録できる。

以上、車載記録システム及び車載制御装置を実施形態により説明したが、本発明は上記実施形態に限定されるものではない。他の実施形態の一部又は全部との組み合わせや置換などの種々の変形及び改良が、本発明の範囲内で可能である。

１ 車載記録システム
６ 情報記録ＥＣＵ
７ ＥＣＵ
７Ａ，７Ａ−ｉ ＥＣＵ
７Ｂ，７Ｂ−ｊ ＥＣＵ
８，８−ｈ 検出・計測装置
９ ＣＡＮ
１４ 不揮発性メモリ
２５ 送受信部
７１ 制御指令生成部
７２ トリガ状態設定部
７３ 送信処理部
７４ ラッチ処理部
７５ イベント発生判定部
９１，９２，９３ ＣＡＮバス
９４ ゲートウェイ装置
１０１ 制御指令生成部
１０２ トリガ状態設定部
１０３ 送信処理部
１０４ 受信処理部
１０５ イベント発生判定部
１０６，１０６−ｋ データ記録部
１０７，１０７−ｋ イベント検出部
１０８，１０８−ｋ 記録処理部
１１０ 車両データ記憶部

Claims (4)

1. 車両又は前記車両の乗員の状況を表す状況データを不揮発性メモリに記録するためのトリガの状態を第１の車載ネットワークに送信する第１の制御装置と、
   前記第１の車載ネットワークに送信されたトリガの状態を前記第１の車載ネットワークから第２の車載ネットワークに中継するゲートウェイ装置と、
   前記ゲートウェイ装置によって前記第１の車載ネットワークから前記第２の車載ネットワークに中継されたトリガの状態を前記第２の車載ネットワークから受信する第２の制御装置とを備え、
   前記第１の制御装置は、
   所定の複数のイベントが前記車両で発生したか否かをイベント毎に判定するイベント発生判定部と、
   前記イベント発生判定部が前記車両で発生したと判定したイベントに対応する前記トリガの状態を成立状態に設定するトリガ状態設定部と、
   前記複数のイベントそれぞれの前記トリガの状態を搬送する通信フレームを前記第１の車載ネットワークに送信する送信処理部とを有し、
   前記ゲートウェイ装置は、
   前記第１の車載ネットワークから受信した第１の通信フレームを前記第２の車載ネットワークに中継するまでに、前記第１の通信フレームとは別の第２の通信フレームを前記第１の車載ネットワークから受信した場合、前記第１の通信フレームを中継せずに前記第２の通信フレームを前記第１の車載ネットワークから前記第２の車載ネットワークに中継する中継処理部を有し、
   前記第２の制御装置は、前記第２の車載ネットワークから受信した通信フレーム内の前記複数のイベントそれぞれの前記トリガのうち、成立状態の前記トリガに対応する前記状況データを前記不揮発性メモリに記録するデータ記録部を有する、車載記録システムであって、
   前記第１の制御装置は、
   前記トリガ状態設定部が前記トリガの状態を成立状態に設定してから所定時間が経過するまで前記トリガの状態を成立状態に維持し、前記所定時間が経過した後に前記トリガの状態を成立状態から非成立状態に変更するラッチ処理を、前記複数のイベントそれぞれの前記トリガについて行うラッチ処理部を有することを特徴とする、車載記録システム。
2. 前記所定時間は、通信フレームが前記第１の車載ネットワークに送信されてから前記ゲートウェイ装置に受信されるまでの第１の遅延時間と、通信フレームが前記ゲートウェイ装置によって前記第１の車載ネットワークから前記第２の車載ネットワークに中継されるまでの第２の遅延時間との合計時間以上である、請求項１に記載の車載記録システム。
3. 第１の車載ネットワークから受信した第１の通信フレームを第２の車載ネットワークに中継するまでに前記第１の通信フレームとは別の第２の通信フレームを前記第１の車載ネットワークから受信した場合、前記第１の通信フレームを中継せずに前記第２の通信フレームを前記第１の車載ネットワークから前記第２の車載ネットワークに中継する中継処理部を備えるゲートウェイ装置に前記第１の車載ネットワークを介して接続され、車両又は前記車両の乗員の状況を表す状況データを不揮発性メモリに記録するためのトリガの状態を前記第１の車載ネットワークに送信する車載制御装置であって、
   所定の複数のイベントが前記車両で発生したか否かをイベント毎に判定するイベント発生判定部と、
   前記イベント発生判定部が前記車両で発生したと判定したイベントに対応する前記トリガの状態を成立状態に設定するトリガ状態設定部と、
   前記複数のイベントそれぞれの前記トリガの状態を搬送する通信フレームを前記第１の車載ネットワークに送信する送信処理部と、
   前記トリガ状態設定部が前記トリガの状態を成立状態に設定してから所定時間が経過するまで前記トリガの状態を成立状態に維持し、前記所定時間が経過した後に前記トリガの状態を成立状態から非成立状態に変更するラッチ処理を、前記複数のイベントそれぞれの前記トリガについて行うラッチ処理部とを備えることを特徴とする、車載制御装置。
4. 前記所定時間は、通信フレームが前記第１の車載ネットワークに送信されてから前記ゲートウェイ装置に受信されるまでの第１の遅延時間と、通信フレームが前記ゲートウェイ装置によって前記第１の車載ネットワークから前記第２の車載ネットワークに中継されるまでの第２の遅延時間との合計時間以上である、請求項３に記載の車載制御装置。

Images