JP2019045914A - 制御装置及び車両の制御システム - Google Patents

Abstract

【課題】ある制御装置が検知した目的外のイベントの情報を他の制御装置に記録させないようにして当該イベントの情報の記録の消去作業の負荷を軽減可能な制御装置及び車両の制御システムを提供する。【解決手段】車両に搭載されて互いに通信可能に接続される制御装置（５０ａ〜５０ｄ）において、制御装置（５０ａ〜５０ｄ）は、イベント処理部（５５）を備え、イベント処理部（５５）は、イベントの情報の記録要求を通知するか否かを切り替える処理、あるいは、イベントの情報の記録の要否を切り替える処理、のうちのいずれか一方又は両方を実行する。【選択図】図１８

Description

本発明は車両に搭載される制御装置及び車両の制御システムに関する。

従来自動車等の車両の制御において、車両の製造後に生じた故障検知等の事象（イベント）の解析を、互いに通信可能に接続された複数の制御装置を利用して行う技術が知られている。例えば特許文献１及び２にはイベントを検知した制御装置が他の制御装置にイベントの記録要求を送信し、他の制御装置が受信した情報に基づいてイベントの情報を記録する技術が開示されている。

特許文献１及び２に開示された技術によれば、例えば故障が発生したときの周辺状況などの運転者等の搭乗者からの説明によるイベントの報告だけでなく、イベントの情報を記録した制御装置の記録を参照することができる。その際にイベントを検知した制御装置だけでなく他の制御装置にも当該イベントの情報の記録が残されるため、イベントの詳細な解析を行うことが可能になる。

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

しかしながら特許文献１及び２に開示された技術においては車両の組立工程や修理整備作業中等、車両の通常使用時以外に検知されたイベントについてもイベントを検知した制御装置から他の制御装置にイベントの記録要求が送信されて、他の制御装置にイベントの情報が記録される。

つまり車両の組立工程や修理整備作業中等、車両がユーザにより使用されていない状況でいくつかの制御装置により不可避的にイベントの検知が予期される環境下においても、複数の制御装置が相互にイベントの情報を記録する。

このときに記録されるイベントの情報は本来記録することを予定している対象でないものも含まれるため、組立完了後や整備完了後には記録したイベントの情報を消去する必要がある。

近年ではエンジンとブレーキとの協調制御や自動運転制御等の車両の制御の高度化により、車両に搭載される制御装置が増加する傾向にある。また車載の制御装置の増加に伴って互いに情報の記録を要求する機会も増加する。

このため制御装置に記録されたイベントの情報を消去する作業に要する時間も比例して増加する。したがって車両の製造コストが増加したり、整備工場における作業時間の増加による修理費用の負担が増加したりする場合があった。

本発明は上記を背景になされたものであり、ある制御装置が検知した目的外のイベントの情報を他の制御装置に記録させないようにして当該イベントの情報の記録の消去作業の負荷を軽減可能な制御装置及び車両の制御システムを提供することを目的とする。

本発明のある観点によれば、車両に搭載されて互いに通信可能に接続される制御装置において、制御装置は、イベント処理部を備え、イベント処理部は、イベントの情報の記録要求を通知するか否かを切り替える処理、あるいは、イベントの情報の記録の要否を切り替える処理、のうちのいずれか一方又は両方を実行することを特徴とする制御装置が提供される。

また、本発明の別の観点によれば、互いに通信可能に接続された複数の制御装置を含む車両の制御システムにおいて、制御装置は、イベント処理部を備え、イベント処理部は、イベントの情報の記録要求を通知するか否かを切り替える処理、あるいは、イベントの情報の記録の要否を切り替える処理、のうちのいずれか一方又は両方を実行することを特徴とする車両の制御システムが提供される。

以上説明したように本発明によれば、ある制御装置が検知した目的外のイベントの情報の記録を他の制御装置に記録させないようにして当該イベントの記録の消去作業の負荷を軽減することができる。

本発明の実施の形態に係る車両の制御システムの全体構成例を示す模式図である。 同実施形態に係る制御装置の基本構成例を示すブロック図である。 エアバッグ制御システムの構成例を示す説明図である。 制御装置による記録要求送信要否の設定例を示す説明図である。 他の制御装置による記録要否の設定例を示す説明図である。 第１の実施の形態に係る制御装置の処理動作の概略を示すフローチャートである。 制御装置による初期診断処理を示すフローチャートである。 制御装置による通常時診断の一例としての外部センサ故障診断処理を示すフローチャートである。 制御装置による通常時診断の一例としてのメッセージの通信途絶診断処理を示すフローチャートである。 制御装置によるイベント記録用データ取得処理を示すフローチャートである。 制御装置によるイベント通知要求判定及びメッセージ送信処理を示すフローチャートである。 制御装置によるイベントデータ記録処理を示すフローチャートである。 制御装置による警告ランプ点灯処理を示すフローチャートである。 第１の実施の形態に係る他の制御装置がイベントの記録要求を受信した場合の処理を示すフローチャートである。 処理モード設定処理の第１の例を示すフローチャートである。 処理モード設定処理の第２の例を示すフローチャートである。 処理モード設定処理の第３の例を示すフローチャートである。 他の制御装置によるイベントデータの蓄積期間を示す説明図である。 第２の実施の形態に係る他の制御装置の処理動作を示すフローチャートである。 車載制御ネットワークの構成例を示す説明図である。 従来の他の制御装置のイベントデータの蓄積期間を示す説明図である。

以下に添付図面を参照しながら本発明の好適な実施の形態について詳細に説明する。なお本明細書及び図面において実質的に同一の機能構成を有する構成要素については同一の符号を付することにより重複説明を省略する。

＜＜１．背景技術の詳述＞＞
本発明の背景技術を詳細に説明した後、本発明の実施の形態を説明する。
図２０は車両に搭載された複数の制御装置（ＥＣＵ：Electronic Control Unit）を互いに接続する制御ネットワーク１０の構成の一例を示す。

図示した制御ネットワーク１０はボディ系ＣＡＮネットワーク２０とシャシー／パワートレイン系ＣＡＮネットワーク３０とを含む。ボディ系ＣＡＮネットワーク２０とシャシー／パワートレイン系ＣＡＮネットワーク３０とはゲートウェイＥＣＵ５０ｈを介して互いに通信可能に接続されている。

ボディ系ＣＡＮネットワーク２０及びシャシー／パワートレイン系ＣＡＮネットワーク３０はそれぞれＣＡＮ（Controller Area Network）通信線を介して互いに通信可能に接続された複数の制御装置５０ａ〜５０ｈ（以下、特に区別が必要な場合を除き制御装置５０と総称する。）を含む。

ボディ系ＣＡＮネットワーク２０はＣＡＮ通信線を介して互いに通信可能に接続されたエアバッグＥＣＵ５０ａ、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄを備える。

エアバッグＥＣＵ５０ａは主として車両の衝突を検知してエアバッグ装置を制御する。エアバッグＥＣＵ５０ａにはＬＩＮ（Local Internet Network）を介して助手席乗員検知ＥＣＵ５０ｉが接続されている。

ボディ制御ＥＣＵ５０ｂは主として空調装置、パワーウィンドウ、ワイパー装置、ドアロック及びパワーシートを制御する。ライト制御ＥＣＵ５０ｃは主として室内灯（ルームランプ）、前照灯、後退灯、車幅灯等の車室内及び車室外の灯火類を制御する。メーター制御ＥＣＵ５０ｄは主として車両の車速を検出してメーターパネル内のスピードメーターを表示し記録するとともに、記録された車速を車両の他の部品へ送信する。またメーター制御ＥＣＵ５０ｄ以外の他の制御装置５０からＣＡＮ通信線を介して送信されるメッセージに含まれる故障有無を示す信号を元に、メーターパネル内に配置されるメーター制御ＥＣＵ５０ｄ以外の他の制御装置５０に関わる異常を示す警告ランプを制御する。故障有りの場合には当該制御装置の警告ランプを点灯させ、車両の運転者に故障を報知する。

またボディ系ＣＡＮネットワーク２０にはＯＢＤ（On Board Diagnosis）コネクタ９１を介してＥＣＵテスター９０が接続可能になっている。例えばＥＣＵテスター９０はＣＡＮ通信線を介して各制御装置５０に対してテスト信号を送信し、各制御装置５０から応答信号を受信することにより各制御装置５０の診断を実行する。

あるいは、ＥＣＵテスター９０は、各制御装置５０によってそれぞれ実施された故障診断の結果記録される、故障部位を示す故障コード（Diagnostic Trouble Code）データと、その故障が現在も継続しているか、あるいは、過去に故障が存在し、現在は復帰しているか等を示す故障状態記録データを受信し、受信結果をディスプレーに表示する。これにより、ディーラーや修理工場において故障部位の特定や故障修理後に、故障コードとその故障の状態を確認すること等により、修理が正しく完了したか否か等の動作確認に使用される。修理完了後には、整備士がＥＣＵテスター９０を操作することにより、ＥＣＵテスター９０から故障コード等の記録を消去するコマンドが制御装置５０に送信され、制御装置５０は故障が復帰した場合には記録していた故障コードデータや故障状態記録データ等を消去する。

シャシー／パワートレイン系ＣＡＮネットワーク３０はＣＡＮ通信線を介して互いに通信可能に接続された自動変速機ＥＣＵ５０ｅ、車両安定制御ＥＣＵ５０ｆ及びエンジンＥＣＵ５０ｇを備える。

自動変速機ＥＣＵ５０ｅは主として自動変速機を制御する。車両安定制御ＥＣＵ５０ｆは主として自動変速機、ブレーキシステム及びエンジンを統合的に制御して車両の横滑り等を防止する。エンジンＥＣＵ５０ｇは主としてエンジンを制御する。

それぞれの制御装置５０は制御装置５０あるいは車両に発生した様々なイベントを検知する。ここで「イベント」とは制御装置５０が現在の状態から異なる状態に遷移する事象を指す。

イベントを検知した制御装置（以下、「自制御装置」ともいう。）は検知したイベントの情報（以下、「イベントデータ」ともいう。）を自制御装置内に記録するだけでなくＣＡＮやＬＩＮ等の通信手段を介して他の制御装置（以下、自制御装置から所定のメッセージが送信される制御装置を「他の制御装置」という。）に対してイベントの記録要求を含むメッセージを送信する。

イベントの記録要求を含むメッセージを受信した他の制御装置は当該他の制御装置内に自制御装置の識別子とともにイベントデータを記録する。このとき他の制御装置は車両の状態の情報を同時に記録してもよい。これによりイベントデータを記録した複数の制御装置５０を解析することでイベントの発生状況を詳細に知ることができる。

以下エアバッグ装置を制御するエアバッグＥＣＵ５０ａが自制御装置である場合を例に採って説明する。

例えば車両の組立工程においてステアリングホイールの組付けは通常車両の製造過程の最終段階で行われる。ステアリングの中立位置の調整、車両の前輪のトーイン調整が完了した後、ステアリングシャフトにステアリングホイールが組み付けられ、さらにロックナットが締結された後に、ステアリングホイールにはドライバを保護するためのエアバッグ装置が搭載される。

エアバッグＥＣＵ５０ａは通電状態において常時エアバッグ装置が正しく搭載されているか否かを診断する。このためエアバッグＥＣＵ５０ａは車両の組立工程においてステアリングホイールの組付けが完了するまで運転席エアバッグ未装着故障を検知し続ける。

このとき通電状態の他の制御装置５０ｂ，５０ｃ・・・が存在する場合には当該他の制御装置５０ｂ，５０ｃ・・・も同様に、イベントの記録要求にしたがって故障検知イベントデータを記録する。このような場合においては車両の製造が完了した段階でイベントデータが記録されたすべての制御装置５０に対して記録されているイベントデータを消去する作業が必要となる。

また車両の製造時においては電子制御部品のコネクタの接続や機械部品のボルト及びナットの締結等が完了した後などの車両の組立完了後に、それぞれの制御装置５０に対してＥＯＬ（End Of Line programming）操作が行われる場合がある。

ＥＯＬ操作は制御装置５０の部品の種類を削減するために、車両の製造の最終段階で部品の組付け後に車両のグレードや仕向地ごとに機能の有無又は出力特性等の設定を行ったり車両又は部品の個体差を調整したりするための設定を行う操作である。ＥＯＬ操作による設定情報は例えば不揮発性メモリに書き込まれる。

具体的に制御装置５０は複数の車種に対応可能に構成される一方、不揮発性メモリには制御装置５０が搭載される車種に応じた装備有無データが記憶される。装備有無データは例えば車両の製造ラインで外部接続されるＥＣＵテスター９０等を用いて、決定された車種に応じて制御装置５０に入力される。

このようなＥＯＬ操作が実施されていない制御装置５０を搭載した車両が市場に流通することを防ぐために、制御装置５０がＥＯＬ操作の未実施を診断する機能を備える場合がある。例えば当該診断機能によりＥＯＬ操作の未実施が検知された場合、制御装置５０は故障を記録したり警告灯を点灯させたり等の処置を行い組立作業者に異常を知らせる。

車両が市場に向けて出荷されるには単に組立が完了しているだけではなくＥＯＬ操作が必要な制御装置５０すべてに対してＥＯＬ操作が完了していることが必要になる。このため車両の製造段階でＥＯＬ操作の完了前に通電が行われる制御装置５０はＥＯＬ操作の未実施状態のまま組付けられる。制御装置５０のＥＯＬ操作が適切に完了する前に制御装置５０が通電状態になると、ＥＯＬ未実施イベントが検知され得る。

したがってこのような制御装置５０はＥＯＬ操作の実施が完了するまで継続的に異常を検知する。またＥＯＬ操作が未実施の状況では初期設定のままで制御動作が行われることから例えば装備過装着又は未装着の故障が確定した状態となっている場合も考えられる。

また制御装置５０同士が相互に通信を行い相互の存在を確認する診断を行う場合がある。例えばある制御装置５０から所定の周期で送信されるメッセージを別の制御装置５０が受信するようになっている場合、受信対象となっているメッセージが送信周期よりも長い期間途絶しているか否か等を判定することにより受信対象メッセージの途絶を診断する場合がある。

さらにボディ系ＣＡＮネットワーク２０又はパワートレイン系ＣＡＮネットワーク３０等に属する制御装置５０が送受信するメッセージの構成とそれらのネットワークを介するゲートウェイＥＣＵ５０ｈが処理するメッセージのルーティング規則はＥＯＬ操作の前後で異なる場合がある。このため互いの存在を確認するための定期的なメッセージの送受信等を正常に行えない場合がある。

例えば電源供給の形態の違いや通信形態の違い、さらには車両のグレードの違いによる装備有無等により互いの存在を確認する処理が正常に実行できない場合がある。具体的には、ある制御装置５０において“Ａ”というメッセージは初期状態として送信が無効に設定され、ＥＯＬ操作により所定のメッセージの定周期送信機能が無効な状態から有効な状態に設定されるように構成される場合がある。このような場合においても制御装置５０の故障が確定した状態となる場合が考えられる。

また、例えば車両の製造時又は修理整備作業時において制御装置５０をＣＡＮ通信線１５に接続する前に制御装置５０が通電状態になると、ＣＡＮ通信途絶イベントが検知され得る。

以上例示したような状況においてイベントを検知した制御装置５０が存在する場合には当該制御装置５０から他の制御装置５０に対するイベントの記録要求に伴って他の制御装置５０もイベントデータを記録しなければならない。

しかしながら制御装置５０によるイベントデータの記録は本来車両出荷後に車両が使用されている間に検出したイベントデータの記録を目的とする機能であるにもかかわらず、目的外のイベントデータの記録が行われている。

これらの目的外のイベントを検知した制御装置５０から他の制御装置５０に対してイベントの記録要求を含むメッセージが送信されると、他の制御装置５０は当該イベントデータを当該他の制御装置５０内に記録する。

上述の車両の製造段階における目的外のイベントデータの記録は予期されるものであるにもかかわらず行われているため、車両の市場への出荷前には記録されているイベントデータを消去する必要が生じている。

このような目的外のイベントデータの記録は車両の製造段階に限らず組立工場からの出荷後の車両の修理整備作業時においても生じる。整備工場で車両の故障修理を行う場合、上記のような故障の検知が予期された環境下で修理作業が行われるため、車両の整備が完了した後には記録されているイベントデータを消去する必要がある。

例えばＥＯＬ操作の対象である制御装置５０を車両組み立て工場からの出荷後の車両の修理整備作業時に交換する場合、制御装置５０は初期状態のままで車両に組付けられて組付け後にＥＯＬ操作が行われる場合がある。このため車両の製造段階と同様に故障が確定した状態になることが予期される。

図２１は従来の制御装置を用いた場合におけるイベントデータの蓄積期間について説明するための図である。上述のように車両の製造段階においてはイベントを検知した制御装置によるイベントデータの記録及び他の制御装置へのイベントの記録要求を含むメッセージの送信が行われる。

これに伴って他の制御装置には目的外のイベントデータについても記録されてそれぞれの制御装置の不揮発性メモリにイベントデータが蓄積される。車両の製造段階における目的外のイベントデータの記録は回避できないものであるため、車両の製造が完了して車両を出荷する際には蓄積された目的外のイベントデータの消去作業が行われる。

車両の整備あるいは修理整備作業時においても同様に作業終了時には蓄積された目的外のイベントデータの消去作業が行われる。イベントデータの消去作業に要する時間はネットワーク上の制御装置の数が多いほど長くなり、それに伴い、車両製造工程、車両修理工程に要する作業時間が増大し、結果として製造コストあるいは修理コストも増大する。

このような背景の下、本実施形態に係る車両の制御システムはあらかじめ予期される目的外のイベントデータの記録の消去作業の負荷を軽減することができるものとなっている。

＜＜２．車両の制御システムの基本構成例＞＞
まず後述する各実施の形態に共通する車両の制御システムの基本構成例を説明する。

＜２−１．車両の制御システムの全体構成例＞
図１は本実施形態に係る車両の制御システム４０の全体構成例を簡略化して示した模式図である。図１は図２０に示した車両の制御システムの一部を簡略化して示したものである。制御システム４０は複数の制御装置５０を備えている。以下エアバッグＥＣＵ５０ａが自制御装置として機能し、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ、メーター制御ＥＣＵ５０ｄが他の制御装置として機能する場合の例を説明する。

なお本実施形態の説明中、複数の制御装置としてのエアバッグＥＣＵ５０ａ、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄの区別を要しない場合には単に制御装置５０と総称する。

制御装置５０はそれぞれ接続されている機器７０ａ，７０ｂ，７０ｃ，７０ｄの制御を行う。制御装置５０はそれぞれＣＡＮ通信線１５を介して相互にメッセージを送受信する。

エアバッグＥＣＵ５０ａにはＬＩＮ通信線１７を介して助手席乗員検知ＥＣＵ５０ｉが互いに通信可能に接続されている。

＜２−２．制御装置の機能構成＞
図２は本実施形態に係る車両の制御システム４０に適用可能な制御装置５０の機能構成を示すブロック図である。図示した制御装置５０の構成例は、自身がイベントを検知する自制御装置、及びイベントの記録要求を含むメッセージを受信する他の制御装置のいずれにも適用することができる。

制御装置５０はＣＰＵ等のプロセッサを備えて構成されている。制御装置５０はモード設定部５１、診断部５２、イベント情報取得部５３、イベント処理部５５、記憶部５７及び通信部５９を備える。このうちのモード設定部５１、診断部５２、イベント情報取得部５３及びイベント処理部５５はＣＰＵ等のプロセッサによる各種プログラムの実行により実現される機能である。

なお制御装置５０の一部又は全部はＣＰＵやＭＣＵ等のプロセッサにより構成される以外に、ファームウェア等の更新可能なもので構成されていてもよく、またＣＰＵ等からの指令によって実行されるプログラムモジュール等であってもよい。

通信部５９はＣＡＮ通信線１５上へのメッセージの送信及びＣＡＮ通信線１５上からのメッセージの受信を行うインターフェースである。

記憶部５７は少なくとも取得したイベントデータを記憶する不揮発性メモリを含む。また記憶部５７はソフトウェアプログラム及び制御パラメータ等を記憶するＲＯＭ（Read Only Memory）や、取得した情報、制御パラメータ及び演算処理結果の情報等を記憶するＲＡＭ（Random Access Memory）等の記憶素子を含む。この他に記憶部５７はＣＤ−ＲＯＭやストレージ装置等の他の記憶媒体による記憶装置を含んでもよい。

モード設定部５１は制御装置５０の処理モードを制御する。処理モードの一つである市場モードとは車両の製造後に車両が市場に向けて出荷された後かつ車両の修理整備時以外の状態で設定される処理モードである。つまり車両の完成後に車両が通常の使用状態に置かれている場合に設定される処理モードである。

モード設定部５１は例えばＣＡＮ通信線１５を介して接続されるＥＣＵテスター９０（図２０を参照。）に対して作業者が操作入力を行うことにより、あるいは検知したイベントの内容又は受信したメッセージの内容に応じて制御装置５０の処理モードを市場モードに設定する。

またモード設定部５１は、制御装置５０の処理モードを一旦市場モードに設定した後に、車両が出荷並びに販売され、例えばディーラーや修理工場等で修理整備作業を開始する際に市場モードをリセットする。処理モードのリセットは例えばＣＡＮ通信線１５を介して接続されるＥＣＵテスター９０に対して作業者が操作入力を行うことによって行われる。

なおモード設定部５１により設定可能な処理モードの例としては、市場モード以外にも、車両の製造段階又は修理整備段階に設定された工場用モード、ディーラー用モード、サプライヤー用モードなどが挙げられる。

診断部５２は自身の制御装置５０に関する診断又は自身の制御装置５０に接続された各種機器７０あるいはＬＩＮ通信線１７により接続されたサブネットワーク上の構成部品に関する診断を実行する。例えば診断部５２はＣＡＮ通信線１５を介した通信の途絶を診断するＣＡＮ途絶診断や、制御装置５０に接続されたセンサの故障診断等を実行してもよい。診断部５２は診断結果に関する情報を記憶部５７に記憶する。

イベント情報取得部５３は制御装置５０又は車両に発生した種々のイベントデータを取得する。例えば制御装置５０自身がイベントを検知する場合、当該イベントを検知する動作がイベントデータを取得する処理に相当する。例えば制御装置５０のイベント情報取得部５３は診断部５２により実行される診断処理の結果に基づいてイベントを検知する。

また制御装置５０がイベントを検知した他の制御装置５０から送信されたイベントの記録要求を含むメッセージを受信する場合、当該記録要求の受信動作がイベントデータを取得する処理に相当する。

制御装置５０のイベント情報取得部５３が検出するイベントは例えば以下のイベントを含む。
−通信途絶イベント
−異常検知イベント
−異常復帰イベント
−故障確定イベント
−故障復帰イベント
−ＥＯＬ未実施イベント
−製造時不具合イベント

通信途絶イベントはＣＡＮ通信線１５あるいはＬＩＮ通信線１７との間の通信が途絶えた場合に検知されるイベントである。例えば制御装置５０とＣＡＮ通信線１５とを接続する通信線が断線した場合に制御装置５０が受信対象としているＣＡＮメッセージを受信することができなくなることにより通信途絶イベントが検知される。

または、制御装置５０が受信対象としているＣＡＮメッセージを送信する他の制御装置５０のＥＯＬ操作が実施されておらず、定周期送信機能によるＣＡＮメッセージの送信が行われない場合に、制御装置５０がＣＡＮメッセージを受信することができないために通信途絶イベントが検知される。

異常検知イベントは制御装置５０に関連する異常が見られた場合に検知されるイベントである。例えばイベント情報取得部５３は制御装置５０に接続された機器７０ａの故障診断において異常が見られた場合に異常検知イベントを検知する。異常復帰イベントは制御装置５０に関連する異常が解消した場合に検知されるイベントである。

故障確定イベントは制御装置５０に関連する異常が確定した場合に検知されるイベントである。例えばイベント情報取得部５３は制御装置５０に接続された機器７０の異常を検知した状態が所定時間継続した場合に故障を確定し、それを故障確定イベントとする。またイベント情報取得部５３は、制御装置５０に関連する異常が解消した状態が所定時間継続した場合に故障の復帰を確定し、それを故障復帰イベントとする。

異常検知イベント、異常復帰イベント、故障確定イベント及び故障復帰イベントについては、制御装置５０に接続された機器７０に適用した例を例示したが、制御装置５０に搭載される回路に適用してもよい。

ＥＯＬ未実施イベントは制御装置５０のＥＯＬ操作が未実施の場合に検知されるイベントである。イベント情報取得部５３は例えばＥＯＬ操作の未実施を診断する診断処理に基づいてＥＯＬ操作が未実施の場合やＥＯＬ操作によって記憶部５７の不揮発性メモリに書き込まれた設定情報が正常でない場合にＥＯＬ未実施イベントを検知する。

製造時不具合イベントは市場モード以外の設定となる車両の製造時あるいは修理整備作業時においてのみ検知を有効とするイベントである。例えば製造時不具合イベントとしては、車両の製造時において制御装置５０のコネクタや、機器７０等を相互に接続する図示しないワイヤーハーネスのコネクタと、コネクタピンの嵌合不良等による故障確定イベントが挙げられる。また製造時不具合イベントとしては、制御装置５０と機器７０とを接続するワイヤーハーネスの断線などによる故障確定イベントが挙げられる。また製造時不具合イベントとしては、制御装置５０から送信されるＣＡＮメッセージを受信することができないＣＡＮメッセージの通信途絶による故障確定イベントが挙げられる。また製造時不具合イベントとしては、ＥＯＬが失敗した場合にＥＯＬ未実施故障が継続することによる故障確定イベントなどが挙げられる。

通常、車両の製造工場における製造工程と製造設備は複数の車両型式の製造に共用されることが多い。したがって、新型車において量産に近い時期に実施する主に製造工程や製造設備の確認を目的とした台数を限定した試作車両の製造と、既存の車両製造ラインにおける現在量産されている車両の製造が車両製造ラインに同時に流れることになる。試作車両の製造工程内で機器のワイヤーハーネスの断線故障を示す故障コード記録やＣＡＮメッセージの通信途絶を示す故障コード記録が記録された車両が見つかった場合に、製造工程内に測定器を持ち込み故障の発生の要因を調査することは、既に量産中の車両製造ラインを一時的に停止することになる。これでは工場全体の製造効率を下げることになってしまうため、実施することが困難な場合が多い。

したがって、製造時不具合イベントを検知した場合、他の制御装置５０に向けてイベントの記録要求を含むメッセージの送信が行われ、これらのイベントの情報が自制御装置５０だけでなく他の制御装置５０に記録される。これにより、故障がどの時点で発生したかを特定することができ、異常部位の特定及び問題解消に有用となる。

工場用モードは量産工程や量産製造装置を使用した試作車両の製造時にのみ設定してもよいし、新型車の量産開始後、安定的に製造ができることが確認された後に設定を解除してもよい。工場用モードは、制御装置５０を製造する部品のサプライヤーの出荷時に予め設定された上で車両の製造工場に納入されてもよい。この場合には、車両におけるイグニッションスイッチＯＦＦからＯＮの際には既に工場用モードがセットされているため、不要なイベント記録を無効にする効果を得ることができる。また、工場用モードから市場モードへの切り替えは、車両の製造工程内のＥＯＬ工程で実施してもよい。

これに対して通常市場で用いられる車両の機能のなかには、製造工程あるいはディーラーでの検査工程については不要な機能がある。これらの機能に関する異常又は故障の情報は、市場モード以外において他の制御装置５０に記録することを要しない。このため制御装置５０の処理モードが市場モードか市場モード以外かによって選択的に他の制御装置５０への記録の要否を切り分けることが有用である。

イベントを検知した制御装置５０のイベント情報取得部５３は、通信部５９を介して、当該イベントの記録要求を含むメッセージをＣＡＮ通信線１５上に送信する。これにより通信部５９を介して当該メッセージを受信した他の制御装置５０のイベント情報取得部５３は当該イベントの記録要求を取得する。

イベント処理部５５は取得したイベントデータを不揮発性メモリに記録させるための処理を行う。イベント処理部５５の基本的な機能として、所定のイベントを検知した制御装置５０のイベント処理部５５は制御装置５０内の記憶部５７の不揮発性メモリにイベントデータを記録する処理を行う。

またイベントを検知した制御装置５０のイベント処理部５５は、制御装置５０の識別子とともにイベントの記録要求を含むメッセージを、制御装置５０の処理モードが市場モードに設定されているか否かによってイベントデータをＣＡＮ通信線１５上に送信する処理を行う。

他の制御装置５０がイベントの記録要求を含むメッセージを受信すると、他の制御装置５０のイベント処理部５５は当該他の制御装置５０内の記憶部５７の不揮発性メモリにメッセージを送信した制御装置５０の識別子とともにイベントデータを記録する処理を行う。

このとき、他の制御装置５０のイベント処理部５５は他の制御装置５０の処理モードが市場モードに設定されているか否かによってイベントデータを当該他の制御装置５０内の記憶部５７の不揮発性メモリに記録させるか否かを切り替える。

他の制御装置５０のイベント処理部５５は処理モードが市場モードに設定されている場合にはイベントデータを他の制御装置５０の記憶部５７の不揮発性メモリに記録させる処理を行う。

一方他の制御装置５０のイベント処理部５５は処理モードが市場モードに設定されていない場合には一部又は全部のイベントデータを記憶部５７の不揮発性メモリに記録させないように処理を行う。これにより車両の製造完了後あるいは修理整備作業後に目的外のイベントデータの記録を消去する作業の負荷を軽減することができる。

＜２−３．エアバッグ制御システムの具体的構成例＞＞
次に本実施形態に係る車両の制御システム４０の一例としてのエアバッグ制御システム１０００の構成例を具体的に説明する。

図３はエアバッグＥＣＵ５０ａを含むエアバッグ制御システム１０００の構成例を示す説明図である。エアバッグ制御システム１０００は車両に設けられた各種加速度センサによって検出されたセンサ信号をモニタし、車両が衝突したと判断した場合に運転席又は助手席などの各部位のエアバッグを展開することにより車両の衝突時の搭乗者の安全性を向上させる。

エアバッグ制御システム１０００はエアバッグＥＣＵ５０ａ、助手席乗員検知ＥＣＵ５０ｉ、メーター制御ＥＣＵ５０ｄ、バッテリ電源４００及びイグニッションスイッチ４１０を備える。エアバッグＥＣＵ５０ａ、メーター制御ＥＣＵ５０ｄ及び助手席乗員検知ＥＣＵ５０ｉはそれぞれ図１に示した制御システム４０の制御装置５０ａ、制御装置５０ｄ及び制御装置５０ｉに相当する。なお図３には示されていないもののＣＡＮ通信線１５Ｌ，１５Ｈにはボディ制御ＥＣＵ５０ｂ及びライト制御ＥＣＵ５０ｃ等が相互に通信可能に接続されている。

またエアバッグ制御システム１０００は運転側エアバッグ用スクイブ５００、助手席側エアバッグ用スクイブ５１０、右サイドエアバッグ用スクイブ５２０、左サイドエアバッグ用スクイブ５３０、右カーテンエアバッグ用スクイブ５４０及び左カーテンエアバッグ用スクイブ５５０を備える。

またエアバッグ制御システム１０００はフロント右加速度センサ６００、フロント左加速度センサ６１０、右サイド加速度センサ６２０及び左サイド加速度センサ６３０を備える。

バッテリ電源４００は車両に搭載された鉛蓄電池など各種の蓄電池である。バッテリ電源４００は電源ライン４０５を介してメーター制御ＥＣＵ５０ｄ、ライト制御ＥＣＵ５０ｃへ電源を直接供給するとともに電源ライン４０５を介して車両の各種の図示しない他の制御装置等へも電源を直接供給する。

イグニッションスイッチ４１０は車両のエンジンを始動したり切ったりするスイッチである。車両のエンジンを切った状態ではイグニッションスイッチ４１０は「ＯＦＦ」になる。この状態からユーザがキーを回すことによってイグニッションスイッチ４１０は「ＯＮ」になる。

イグニッションスイッチ４１０が「ＯＮ」になるとバッテリ電源４００がイグニッションライン４０７を介してメーター制御ＥＣＵ５０ｄ、助手席乗員検知ＥＣＵ５０ｉ及びエアバッグＥＣＵ５０ａへ電源が供給される。

メーター制御ＥＣＵ５０ｄは警告ランプ２０１や図示しないインストルメントパネルに対して点灯信号又は表示信号等を送信する。例えば、エアバッグＥＣＵ５０ａから送信されたエアバッグ警告灯ＯＮ／ＯＦＦ信号に基づくメーターパネル内のエアバッグ警告灯の点灯／消灯制御、ライト制御ＥＣＵ５０ｃから送信された前照灯点灯中／非点灯中信号に基づくメーターパネル自体の照明点灯／消灯制御をするようになっている。メーター制御ＥＣＵ５０ｄは車速センサの信号に基づいて車速を検出して記録し、ＣＡＮ通信線１５Ｌ，１５Ｈを介して、記録した車速をエアバッグＥＣＵ５０ａへ送信する。同様に、図示しない車両安定制御ＥＣＵは図示しないブレーキスイッチの信号に基づいて運転者のブレーキ操作状態を検出して記録し、ＣＡＮ通信線１５Ｌ，１５Ｈを介して、記録したブレーキ操作状態をエアバッグＥＣＵ５０ａへ送信する。

これによりエアバッグＥＣＵ５０ａは車両がどのような状態で運転されているか、例えば車両のブレーキ状態などを検出することができる。この他エアバッグＥＣＵ５０ａはボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄを介して車両の種々の状態の情報を検出する。

助手席乗員検知ＥＣＵ５０ｉは車両の助手席のシート上の重量を図示しない荷重センサの信号に基づいて検出し助手席の乗員状態を判定する。例えば助手席乗員検知ＥＣＵ５０ｉは大人の男性、小柄な女性、子供又は空席などの状態を判定する。

助手席乗員検知ＥＣＵ５０ｉは、ＬＩＮ通信線１７を介して、判定された助手席の乗員状態をエアバッグＥＣＵ５０ａへ送信する。エアバッグＥＣＵ５０ａは例えば助手席のシート上の乗員状態をモニタすることによって、車両のフロント衝突時において例えば助手席の乗員が子供の場合に意図しない助手席側エアバッグ用スクイブ５１０の通電を抑制し、図示しない助手席側エアバッグの展開を抑制することができる。

エアバッグＥＣＵ５０ａは電圧検出器１０１、昇圧回路１０２、電圧検出器１０３、キャパシタ（バックアップ電源）１０４、電圧検出Ｉ／Ｆ（InterFace）１０５，１０７、ＤＣ−ＤＣコンバータ１０６、ＣＡＮ通信トランシーバ１０８及びＬＩＮ通信トランシーバ１１０を備える。

またエアバッグＥＣＵ５０ａはＭＣＵ（Micro Controller Unit）１２０、ＡＳＩＣ（Application Specific Integrated Circuit）１４０、加速度センサ１５０及び不揮発性メモリ１６０を備える。

電圧検出器１０１はバッテリ電源４００からイグニッションスイッチ４１０を介してエアバッグＥＣＵ５０ａへ供給された電源電圧値を検出する。電圧検出Ｉ／Ｆ１０５は電圧検出器１０１によって検出された電圧信号をＭＣＵ１２０へ出力するためのインターフェースである。電圧検出器１０１によって検出された電圧信号は電圧検出Ｉ／Ｆ１０５を介してＭＣＵ１２０へ出力される。

昇圧回路１０２はバッテリ電源４００からイグニッションスイッチ４１０を介してエアバッグＥＣＵ１００へ供給された電源電圧を昇圧する回路である。昇圧回路１０２は例えばバッテリ電源４００から供給された９Ｖから１６Ｖの電源電圧を３３Ｖ程度まで昇圧する。昇圧回路１０２は昇圧した電圧をキャパシタ１０４及びＤＣ−ＤＣコンバータ１０６へ供給する。

電圧検出器１０３は昇圧回路１０２から出力された電源電圧値を検出する。電圧検出Ｉ／Ｆ１０７は電圧検出器１０３によって検出された電圧信号をＭＣＵ１２０へ出力するためのインターフェースである。電圧検出器１０３によって検出された電圧信号は電圧検出Ｉ／Ｆ１０７を介してＭＣＵ１２０へ出力される。

キャパシタ１０４は昇圧回路１０２から供給された電圧の充放電を行う蓄電器でありバッテリ電源４００のバックアップ電源となる。ＤＣ−ＤＣコンバータ１０６は昇圧回路１０２から供給された電圧をＭＣＵ１２０で使用される電圧（例えば５Ｖ）へ変換（降圧）する変換器である。ＤＣ−ＤＣコンバータ１０６は降圧した電圧をＭＣＵ１２０へ供給する。

ＣＡＮ通信トランシーバ１０８はＣＡＮ規格に基づいてＣＡＮ通信線１５Ｌ，１５Ｈを介してメーター制御ＥＣＵ５０ｄ及び図示しないボディ制御ＥＣＵ５０ｂ及びライト制御ＥＣＵ５０ｃとの間でメッセージを送受信するインターフェースである。ＣＡＮ通信トランシーバ１０８によって受信されたデータはＭＣＵ１２０へ送信される。

ＬＩＮ通信トランシーバ１１０はＬＩＮ通信線１７を介して助手席乗員検知ＥＣＵ５０ｉとの間でデータの送受信を行うインターフェースである。ＬＩＮ通信トランシーバ１１０は通信信号の電圧レベルを変換する。例えばＬＩＮ通信トランシーバ１１０はＭＣＵ１２０が取り扱える５Ｖ系の信号レベルをＬＩＮの電圧レベル（１２Ｖ）に変換する。

ＭＣＵ１２０はＡ／Ｄ（Analog to Digital Converter）１２１、ＣＰＵ１２２、ＲＯＭ１２４、ＲＡＭ１２６及びＣＡＮ通信コントローラ１２８を備える。またＭＣＵ１２０はＬＩＮ通信コントローラ１３２及びＳＰＩ（Serial Peripheral Interface）１３４，１３６，１３８を備える。ＲＯＭ１２４、ＲＡＭ１２６及び不揮発性メモリ１６０は、図２に示した記憶部５７に相当する。

Ａ／Ｄ１２１、ＣＰＵ１２２、ＲＯＭ１２４、ＲＡＭ１２６、ＣＡＮ通信コントローラ１２８、ＬＩＮ通信コントローラ１３２及びＳＰＩ１３４，１３６，１３８はＭＣＵ１２０の内部バス１７０を介して相互に接続されている。

Ａ／Ｄ１２１は電圧検出Ｉ／Ｆ１０５，１０７を介して入力されたアナログ電圧信号をデジタル電圧信号へ変換する。ＣＰＵ１２２はＲＯＭ１２４又はＲＡＭ１２６に格納された各種プログラムを実行する演算処理部である。ＣＰＵ１２２はＲＯＭ１２４又はＲＡＭ１２６に格納された各種プログラムを実行することにより、エアバッグＥＣＵ５０ａの各種機能を実行する。

図３に示したエアバッグＥＣＵ５０ａの例では、ＣＰＵ１２２が各種プログラムを実行することにより、図２に示したモード設定部５１、診断部５２、イベント情報取得部５３及びイベント処理部５５の機能が実現される。

ＲＯＭ１２４はエアバッグＥＣＵ５０ａの各種機能を実行するためのデータ及び各種プログラムを格納するメモリである。ＲＡＭ１２６はＲＯＭ１２４に格納された各種プログラムのうちＣＰＵ１２２で実行されるプログラムの演算結果などを格納する比較的小容量で高速アクセスが可能なメモリである。

ＣＡＮ通信コントローラ１２８はＣＡＮ通信トランシーバ１０８を介してメーター制御ＥＣＵ５０ｄ又は図示しない車両の他の部品との間の通信を行うコントローラである。ＬＩＮ通信コントローラ１３２は非同期シリアル通信を制御する。エアバッグＥＣＵ５０ａはＬＩＮ通信トランシーバ１１０を介して助手席乗員検知ＥＣＵ５０ｉと通信する。

図３に示したエアバッグＥＣＵ５０ａの例では、ＭＣＵ１２０がＣＡＮ通信トランシーバ１０８及びＬＩＮ通信トランシーバ１１０を介してデータを送受信し、これらを用いて図２に示した通信部５９の機能が実現されている。

ＳＰＩ１３４はクロック同期式シリアル通信のインターフェースでありＡＳＩＣ１４０とＭＣＵ１２０内の各デバイスとのインターフェースとなる。ＳＰＩ１３６は加速度センサ１５０とＭＣＵ１２０内の各デバイスとのインターフェースとなる。ＳＰＩ１３８は不揮発性メモリ１６０とＭＣＵ１２０内の各デバイスとのインターフェースとなる。

加速度センサ１５０はエアバッグＥＣＵ５０ａが配置された場所における加速度を検出するセンサである。加速度センサ１５０は、ＳＰＩ１３６を介して、検出した加速度をＭＣＵ１２０へ出力する。例えば、エアバッグＥＣＵ５０ａは通常、車両の前後方向の中心軸上に設置され、より具体的には車体のフロアトンネル上の剛性の高い部位にボルト・ナットまたはボルト・タップ穴などの機械的な締結手段により固定される。車体の前面や側面に衝撃を受ける衝突事象において、エアバッグＥＣＵ５０ａに搭載された加速度センサ１５０は車体を介して加速度を検出する。

不揮発性メモリ１６０は電力を供給しない場合においても記録を保持するメモリであり、例えばＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）である。不揮発性メモリ１６０は例えばＳＰＩ１３８を介してＭＣＵ１２０から出力されたデータを記録する。

ＡＳＩＣ１４０は複数機能の回路を１つにまとめた集積回路である。ＡＳＩＣ１４０はスクイブＩ／Ｆ１４２とセンサＩ／Ｆ１４４とを備える。スクイブＩ／Ｆ１４２は運転側エアバッグ用スクイブ５００、助手席側エアバッグ用スクイブ５１０、右サイドエアバッグ用スクイブ５２０、左サイドエアバッグ用スクイブ５３０、右カーテンエアバッグ用スクイブ５４０及び左カーテンエアバッグ用スクイブ５５０へエアバッグの展開信号を送信するインターフェースとなる。

またセンサＩ／Ｆ１４４はフロント右加速度センサ６００、フロント左加速度センサ６１０、右サイド加速度センサ６２０及び左サイド加速度センサ６３０から送信される加速度信号を受信するインターフェースとなる。フロント右加速度センサ６００、フロント左加速度センサ６１０はそれぞれ車体の前部における剛性の高い金属部に機械的に締結され、車体の前部に対する衝突時に生じる加速度を検出する。右サイド加速度センサ６２０及び左サイド加速度センサ６３０は車体の側面にあるＢピラーの付け根付近など、車体の概側面部の車室内側に締結され車体の側面衝突時に受ける車体の横方向に対する衝撃を検出する。フロント右加速度センサ６００、フロント左加速度センサ６１０、右サイド加速度センサ６２０及び左サイド加速度センサ６３０とエアバッグＥＣＵ５０ａとはワイヤーハーネスを介してコネクタなどの電気的着脱手段により接続される。

運転側エアバッグ用スクイブ５００はＭＣＵ１２０からスクイブＩ／Ｆ１４２を介して送信された展開信号に基づいて運転席側の点火装置（スクイブ）に電流を供給しガス発生剤に着火することで高圧ガスを発生させ、瞬時にエアバッグを膨らませる。

助手席側エアバッグ用スクイブ５１０、右サイドエアバッグ用スクイブ５２０、左サイドエアバッグ用スクイブ５３０、右カーテンエアバッグ用スクイブ５４０及び左カーテンエアバッグ用スクイブ５５０も同様にＭＣＵ１２０から送信された展開信号に基づいて車両の各場所に配置されたエアバッグを膨らませる。

フロント右加速度センサ６００は車両のフロントの右側に配置された加速度センサであり、センサで検出した加速度をセンサＩ／Ｆ１４４を介してＭＣＵ１２０へ送信する。またフロント左加速度センサ６１０、右サイド加速度センサ６２０及び左サイド加速度センサ６３０も同様に車両の各場所に配置されており、車両の各場所における加速度を検出してＭＣＵ１２０へ送信する。

＜２−４．エアバッグＥＣＵが検知するイベント＞
制御装置がエアバッグＥＣＵ５０ａの場合、図２に示したイベント情報取得部５３は上述した制御装置５０が検知する共通のイベントと併せてエアバッグＥＣＵ５０ａに固有のイベントを検知する。エアバッグＥＣＵ５０ａのイベント情報取得部５３が検知するイベントは例えば上述した共通のイベントに加えて以下のイベントを含んでもよい。
−衝突事象検知イベント
−エアバッグ展開イベント
−衝突処理完了イベント
−衝突記録開始イベント
−衝突記録完了イベント

固有のイベントとしての衝突事象検知イベントは、例えばエアバッグＥＣＵ５０ａが加速度センサ（１５０，６００，６１０，６２０，６３０）のセンサ信号等に基づいて検知される衝撃が、所定の衝撃強度を超えた場合に検知されるイベントである。

エアバッグ展開イベントは、例えばエアバッグＥＣＵ５０ａがエアバッグ用スクイブ（５００，５１０，５２０，５３０，５４０，５５０）を駆動してエアバッグを展開させた場合に検知されるイベントである。

衝突処理完了イベントは、例えば車両の衝突発生後にエアバッグＥＣＵ５０ａがエアバッグを展開させる等の所定の処理が完了した場合に検知されるイベントである。

衝突記録開始イベントは、例えば、所定の衝撃強度を検出したことをきっかけに衝突記録を開始した場合に検知されるイベントである。

衝突記録完了イベントは、例えば、上述の衝突記録が完了した場合に検知されるイベントである。

イベント情報取得部５３は、車両の製造時又は修理整備作業時においても、これらの固有のイベントを検知し得る。例えばイベント情報取得部５３は加速度センサに強い衝撃が与えられたときに衝突事象検知イベントを検知し得る。

またエアバッグＥＣＵ５０ａのイベント情報取得部５３は、車両の製造時又は修理整備作業時においても、例えばエアバッグＥＣＵ５０ａにエアバッグ用スクイブや加速度センサを接続する前にエアバッグＥＣＵ５０ａが通電状態になると異常検知イベントを検知する。

またエアバッグＥＣＵ５０ａのイベント情報取得部５３は、車両の製造時又は修理整備作業時においても、例えば異常検知イベントが検知されてから所定時間経過する前にエアバッグ用スクイブや加速度センサが接続されると異常復帰イベントを検知する。

またエアバッグＥＣＵ５０ａのイベント情報取得部５３は、車両の製造時又は修理整備作業時においても、例えば異常検知イベントの検知が所定時間継続した場合に故障確定イベントを検知する。

またエアバッグＥＣＵ５０ａのイベント情報取得部５３は、車両の製造時又は修理整備作業時においても、例えば故障確定イベントが検知された後にエアバッグ用スクイブや加速度センサがエアバッグＥＣＵ５０ａに接続されると故障復帰イベントを検知する。

＜２−５．自制御装置によるイベント記録要求の送信設定＞
図４は所定のイベントを検出した自制御装置としてのエアバッグＥＣＵ５０ａによるイベントの記録要求を含むメッセージの送信要否の設定例を示す説明図である。

エアバッグＥＣＵ５０ａからボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへのイベントの記録要求を含むメッセージの送信要否の設定は、エアバッグＥＣＵ５０ａの処理モードの設定が市場モードの場合と市場モード以外の場合とで異なっている。

エアバッグＥＣＵ５０ａの処理モードが市場モードに設定されている場合、エアバッグＥＣＵ５０ａは製造時不具合イベントを除くすべてのイベントについてイベントの記録要求を含むメッセージをボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信する。

またエアバッグＥＣＵ５０ａの処理モードが市場モードに設定されている場合、エアバッグＥＣＵ５０ａは製造時不具合イベントについてはイベントの記録要求を含むメッセージをボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信しない。

一方エアバッグＥＣＵ５０ａの処理モードが市場モード以外に設定されている場合、エアバッグＥＣＵ５０ａは、例えば製造時不具合イベントについてはイベントの記録要求を含むメッセージをボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信する。

またエアバッグＥＣＵ５０ａの処理モードが市場モード以外に設定されている場合、エアバッグＥＣＵ５０ａは、例えば製造時不具合イベントを除くイベントについては当該メッセージをボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信しない。

なお図４に示した設定例はあくまでも一例であり、イベントの種類あるいは目的に応じて適宜設定を変更することができる。

＜２−６．他の制御装置によるイベント記録要否の設定＞
図５はエアバッグＥＣＵ５０ａからイベントの記録要求を含むメッセージを受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄによるイベントデータの記録要否の設定例を示す説明図である。

ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄによる不揮発性メモリ１６０へのイベント記録の要否の設定は、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄの処理モードの設定が市場モードの場合と市場モード以外の場合とよって異なっている。

イベントの記録要求を含むメッセージを受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄは、処理モードが市場モードに設定されている場合、製造時不具合イベントを除くすべてのイベントについて記録要求のメッセージにしたがってイベントデータを不揮発性メモリ１６０に記録する。

またイベントの記録要求を含むメッセージを受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄは、処理モードが市場モードに設定されている場合、製造時不具合イベントについてはイベントデータを不揮発性メモリ１６０に記録しない。

一方処理モードが市場モード以外に設定されている場合、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄは、例えば製造時不具合イベントについては記録要求のメッセージにしたがってイベントデータをボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄ内の不揮発性メモリに記録する。

また処理モードが市場モード以外に設定されている場合、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄは、例えば製造時不具合イベントを除くイベントについてはイベントデータをボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄ内の不揮発性メモリに記録しない。

なお図５に示した設定例はあくまでも一例であり、イベントの種類あるいは目的に応じて適宜設定を変更することができる。

ここまで本実施形態に係る車両の制御システム４０及びその具体例としてのエアバッグ制御システム１０００の構成例を説明した。以下相互に通信可能に接続された制御装置５０により実行される各種処理の詳細について、エアバッグ制御システム１０００を例に採って説明する。

＜３．第１の実施の形態＞
第１の実施の形態に係るエアバッグ制御システム１０００ではイベントを検知したエアバッグＥＣＵ５０ａが処理モードに応じてボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに対するイベントの記録要求を含むメッセージの送信の要否を切り替える。

（３−１．エアバッグＥＣＵの動作例）
図６は自制御装置としてのエアバッグＥＣＵ５０ａにより実行される一連の処理動作の概略を示すフローチャートである。

（初期診断処理）
まずエアバッグＥＣＵ５０ａが初期化されると（ステップＳ１０１）、エアバッグＥＣＵ５０ａの診断部５２は初期診断処理を実行する（ステップＳ１０３）。

図７は初期診断の一例としてエアバッグＥＣＵ５０ａに接続された外部センサの初期診断処理の一例を示すフローチャートである。外部センサは例えば図３に示したフロント右加速度センサ６００、フロント左加速度センサ６１０、右サイド加速度センサ６２０及び左サイド加速度センサ６３０である。

まず診断部５２は外部センサの型式を識別するＩＤデータを受信する（ステップＳ１１１）。次いで診断部５２は受信したＩＤが所定値と一致しているか否かを判別する（ステップＳ１１３）。所定値は使用する外部センサに対応するＩＤとしてあらかじめ記憶部５７に記憶された値である。

受信したＩＤが所定値と一致している場合（Ｓ１１３／Ｙｅｓ）、初期診断による故障の検出はないため診断部５２はこのまま初期診断処理を終了する。一方受信したＩＤが所定値と一致していない場合（Ｓ１１３／Ｎｏ）、診断部５２は外部センサのＩＤの不一致故障に該当する故障コード（ＤＴＣ：Diagnostic Trouble Code）を記憶部５７に記録する処理を実行する（ステップＳ１１５）。

次いで診断部５２は外部センサのＩＤの不一致故障によるイベント記録要求を発行する（ステップＳ１１７）。イベント記録要求はイベント処理部５５に対してエアバッグＥＣＵ５０ａ自身の不揮発性メモリ１６０にＩＤの不一致故障によるイベントを記録させるための指示データである。

次いで診断部５２は外部センサのＩＤの不一致故障によるイベント通知要求を発行する（ステップＳ１１９）。イベント通知要求はイベント処理部５５に対してボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへのイベントの記録要求を含むメッセージを送信させるための指令情報である。

診断部５２はＩＤの不一致故障によるイベント記録要求及びイベント通知要求を発行した後に初期診断処理を終了する。

（通常時診断処理）
図６に戻り、エアバッグＥＣＵ５０ａの診断部５２は初期診断処理（Ｓ１０３）の終了後に通常時診断処理を実行する（ステップＳ１０５）。通常時診断は例えば通信途絶診断又は外部センサ故障診断を含む。

図８は通常時診断の一例としての外部センサ故障診断処理の一例を示すフローチャートである。まずエアバッグＥＣＵ５０ａの診断部５２は外部センサから検出データを取得する（ステップＳ１２１）。次いで診断部５２は取得した検出データが正常範囲内か否かを判別する（ステップＳ１２３）。検出データの正常範囲は例えばあらかじめ想定される検出範囲として設定されている。

検出データが正常範囲内である場合（Ｓ１２３／Ｙｅｓ）、診断部５２は衝突判定制御に用いる外部センサの検出データの基準値を、今回取得した検出データで更新する（ステップＳ１２５）。次いで診断部５２は外部センサの状態を「正常検知状態」に設定する（ステップＳ１２７）。

次いで診断部５２は外部センサの状態が今回「故障検知状態」から「正常検知状態」に変化したか否かを判別する（ステップＳ１２９）。外部センサの状態が「故障検知状態」から「正常検知状態」に変化していない場合、つまり前回から継続して「正常検知状態」であった場合（Ｓ１２９／Ｎｏ）、診断部５２はそのままステップＳ１３５に進む。

一方外部センサの状態が今回「故障検知状態」から「正常検知状態」に変化した場合（Ｓ１２９／Ｙｅｓ）、診断部５２は外部センサの「正常検知状態」によるイベント記録要求を発行する（ステップＳ１３１）。次いで診断部５２は外部センサの「正常検知状態」の継続時間を計測するタイマＴ１を初期化して（ステップＳ１３３）、ステップＳ１３５に進む。

ステップＳ１３５において診断部５２は外部センサの「正常検知状態」の継続時間を計測するタイマＴ１があらかじめ設定した所定時間Ｔ１＿０を経過したか否かを判別する（ステップＳ１３５）。タイマＴ１が所定時間Ｔ１＿０を経過していない場合（Ｓ１３５／Ｎｏ）、診断部５２はそのまま外部センサ故障診断処理を終了する。一方タイマＴ１が所定時間Ｔ１＿０を経過した場合（Ｓ１３５／Ｙｅｓ）、診断部５２は外部センサの状態を「正常確定状態」に設定する（ステップＳ１３７）。

次いで診断部５２は外部センサの状態が今回「故障確定状態」から「正常確定状態」に変化したか否かを判別する（ステップＳ１３９）。外部センサの状態が「故障確定状態」から「正常確定状態」に変化していない場合、つまり前回から継続して「正常確定状態」であった場合（Ｓ１３９／Ｎｏ）、診断部５２はそのまま外部センサ故障診断処理を終了する。

一方外部センサの状態が今回「故障確定状態」から「正常確定状態」に変化した場合（Ｓ１３９／ｙｅｓ）、診断部５２は外部センサの正常確定状態によるイベント記録要求を発行する（ステップＳ１４１）。次いで診断部５２は外部センサの正常状態復帰に該当する故障コード（ＤＴＣ）を記憶部５７に記録する処理を実行し（ステップＳ１４３）、外部センサ故障診断処理を終了する。このとき外部センサの過去の故障記録は残される。

上述のステップＳ１２３において検出データが正常範囲外である場合（Ｓ１２３／Ｎｏ）、診断部５２は衝突判定制御に用いる外部センサの検出データの基準値をゼロにして更新する（ステップＳ１４５）。次いで診断部５２は外部センサの状態を「故障検知状態」に設定する（ステップＳ１４７）。

次いで診断部５２は外部センサの状態が今回「正常検知状態」から「故障検知状態」に変化したか否かを判別する（ステップＳ１４９）。外部センサの状態が「正常検知状態」から「故障検知状態」に変化していない場合、つまり前回から継続して「故障検知状態」であった場合（Ｓ１４９／Ｎｏ）、診断部５２はそのままステップＳ１５５に進む。

一方外部センサの状態が今回「正常検知状態」から「故障検知状態」に変化した場合（Ｓ１４９／Ｙｅｓ）、診断部５２は外部センサの「故障検知状態」によるイベント記録要求を発行する（ステップＳ１５１）。次いで診断部５２は外部センサの「故障検知状態」の継続時間を計測するタイマＴ２を初期化して（ステップＳ１５３）、ステップＳ１５５に進む。

ステップＳ１５５において診断部５２は外部センサの「故障検知状態」の継続時間を計測するタイマＴ２があらかじめ設定した所定時間Ｔ２＿０を経過したか否かを判別する（ステップＳ１５５）。タイマＴ２が所定時間Ｔ２＿０を経過していない場合（Ｓ１５５／Ｎｏ）、診断部５２はそのまま外部センサ故障診断処理を終了する。一方タイマＴ２が所定時間Ｔ２＿０を経過した場合（Ｓ１５５／Ｙｅｓ）、診断部５２は外部センサの状態を「故障確定状態」に設定する（ステップＳ１５７）。

次いで診断部５２は外部センサの状態が今回「正常確定状態」から「故障確定状態」に変化したか否かを判別する（ステップＳ１５９）。外部センサの状態が「正常確定状態」から「故障確定状態」に変化していない場合、つまり前回から継続して「故障確定状態」であった場合（Ｓ１５９／Ｎｏ）、診断部５２はそのまま外部センサ故障診断処理を終了する。

一方外部センサの状態が今回「正常確定状態」から「故障確定状態」に変化した場合（Ｓ１５９／ｙｅｓ）、診断部５２は外部センサの「故障確定状態」によるイベント記録要求を発行する（ステップＳ１６１）。次いで診断部５２は外部センサの「故障確定状態」に該当する故障コード（ＤＴＣ）を記憶部５７に記録する処理を実行し（ステップＳ１６３）、外部センサ故障診断処理を終了する。

図９は通常時診断の一例としてのメッセージの通信途絶診断処理の一例を示すフローチャートである。まずエアバッグＥＣＵ５０ａの診断部５２は所定のメッセージの受信があるか否かを判別する（ステップＳ１７１）。当該メッセージの受信がある場合（Ｓ１７１／Ｙｅｓ）、診断部５２は当該メッセージを取り込んで受信処理を行う（ステップＳ１７３）。

次いで診断部５２は当該メッセージの途絶状態の継続時間を計測するタイマＴ３を初期化する（ステップＳ１７５）。次いで診断部５２は途絶診断状態を「正常状態」に設定する（ステップＳ１７７）。次いで診断部５２は途絶診断状態が今回「故障状態」から「正常状態」に変化したか否かを判別する（ステップＳ１７９）。

途絶診断状態が「故障状態」から「正常状態」に変化していない場合、つまり前回から継続して「正常状態」であった場合（Ｓ１７９／Ｎｏ）、診断部５２はそのままメッセージの通信途絶診断処理を終了する。

一方途絶診断状態が今回「故障状態」から「正常状態」に変化した場合（Ｓ１７９／Ｙｅｓ）、診断部５２は通信途絶の正常復帰によるイベント記録要求を発行する（ステップＳ１８１）。さらに診断部５２は通信途絶の正常復帰に該当する故障コード（ＤＴＣ）を記憶部５７に記録する処理を実行し（ステップＳ１８３）、メッセージの通信途絶診断処理を終了する。

一方上述のステップＳ１７１において当該メッセージの受信がない場合（Ｓ１７１／Ｎｏ）、診断部５２は当該メッセージの途絶状態の継続時間を計測するタイマＴ３があらかじめ設定した所定時間Ｔ３＿０を経過したか否かを判別する（ステップＳ１８５）。

タイマＴ３が所定時間Ｔ３＿０を経過していない場合（Ｓ１８５／Ｎｏ）、診断部５２はそのままメッセージの通信途絶診断処理を終了する。一方タイマＴ３が所定時間Ｔ３＿０を経過した場合（Ｓ１８５／Ｙｅｓ）、診断部５２は途絶診断状態を「故障状態」に設定する（ステップＳ１８７）。

次いで診断部５２は途絶診断状態が今回「正常状態」から「故障状態」に変化したか否かを判別する（ステップＳ１８９）。途絶診断状態が「正常状態」から「故障状態」に変化していない場合、つまり前回から継続して「故障状態」であった場合（Ｓ１８９／Ｎｏ）、診断部５２はそのままメッセージの通信途絶診断処理を終了する。

一方途絶診断状態が今回「正常状態」から「故障状態」に変化した場合（Ｓ１８９／Ｙｅｓ）、診断部５２は通信途絶故障によるイベント記録要求を発行する（ステップＳ１９１）。さらに診断部５２は通信途絶故障に該当する故障コード（ＤＴＣ）を記憶部５７に記録する処理を実行し（ステップＳ１９３）、メッセージの通信途絶診断処理を終了する。

（イベント記録用データ収集処理）
図６に戻り、通常時診断処理（Ｓ１０５）の終了後、エアバッグＥＣＵ５０ａのイベント情報取得部５３はイベント記録用のデータを収集する処理を行う（ステップＳ１０７）。イベント記録用のデータはイベント記録要求が発行された時刻の前後の車両状態やユーザの操作状況等のデータであり、検知したイベントの情報とともに不揮発性メモリ１６０に記憶される。

図１０はイベント記録用データを収集する処理の具体例を示すフローチャートである。まずエアバッグＥＣＵ５０ａのイベント情報取得部５３はＣＡＮ通信線１５を介して受信したブレーキペダルの操作情報を記憶部５７に記録する（ステップＳ２０１）。記憶部５７は例えばリングバッファであってよい。

次いでイベント情報取得部５３はＣＡＮ通信線１５を介して受信した舵角情報を記憶部５７に記録する（ステップＳ２０３）。次いでイベント情報取得部５３はＣＡＮ通信線１５を介して受信したエンジン回転数の情報を記憶部５７に記録する（ステップＳ２０５）。

次いでイベント情報取得部５３はイグニッションスイッチの電圧データを記憶部５７に記録する（ステップＳ２０７）。次いでイベント情報取得部５３はＣＡＮ通信線１５を介して受信したアクセルペダルの開度情報を記憶部５７に記録する（ステップＳ２０９）。

次いでイベント情報取得部５３はエアバッグＥＣＵ５０ａのスリープ状態を記憶部５７に記録する（ステップＳ２１１）。次いでイベント情報取得部５３は車速情報を記憶部５７に記録する（ステップＳ２１３）。

イベント情報取得部５３はこれらの一連の処理を行いイベント記録用のデータの収集処理を繰り返し実行する。なお収集する各種データを記録する順序は上記の例に限られず、適宜入れ替えられてよい。

（イベント通知要求判定及びイベント記録要求メッセージ送信処理）
図６に戻り、イベント記録用データ収集処理（Ｓ１０７）の終了後、エアバッグＥＣＵ５０ａのイベント処理部５５はイベント通知要求の発行の有無を判定する。またイベント処理部５５はイベント通知要求が発行されている場合にはボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに対してイベントの記録要求を含むメッセージを送信する処理を行う（ステップＳ１０９）。

図１１はステップＳ１０９の処理の具体例を示すフローチャートである。まずエアバッグＥＣＵ５０ａのイベント処理部５５はイベント通知要求の有無を判別する（ステップＳ２２１）。イベント通知要求がない場合（Ｓ２２１／Ｎｏ）、イベント処理部５５はそのまま処理を終了する。

一方イベント通知要求がある場合（Ｓ２２１／Ｙｅｓ）、イベント処理部５５はイベント通知要求が発行されているイベントがボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに記録要求を送信すべき対象に設定されているか否かを判別する（ステップＳ２２３）。

イベント通知要求が発行されているイベントがボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに記録要求を送信すべき対象に設定されている場合（Ｓ２２３／Ｙｅｓ）、イベント処理部５５はさらに当該イベントのボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへの記録要求の送信が許可されているか否かを判別する（ステップＳ２２５）。

上記のステップＳ２２３及びＳ２２５では、イベント処理部５５は例えば図４の設定例にしたがって判別を行う。例えば図４に示した設定例に含まれるイベントであればイベント処理部５５はステップＳ２２３を「Ｙｅｓ」と判定する。その場合にイベント処理部５５は、エアバッグＥＣＵ５０ａの処理モードの設定が市場モードか市場モード以外かに応じて自制御装置の欄の市場モード又は市場モード以外の欄を参照して、ステップＳ２２５の送信の可否を判定する。

ステップＳ２２３又はステップＳ２２５のいずれかが「Ｎｏ」と判定された場合（Ｓ２２３／Ｎｏ又はＳ２２５／Ｎｏ）、イベント処理部５５はそのままステップＳ２３１に進み、イベント通知要求処理の完了処理を行い（ステップＳ２３１）、処理を終了する。

イベント通知要求が発行されているイベントのボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへの記録要求の送信が許可されている場合（Ｓ２２５／Ｙｅｓ）、イベント処理部５５は記録要求を含むボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへ通知するデータをセットする（ステップＳ２２７）。

次いでイベント処理部５５はＣＡＮ通信線１５を介してセットしたデータを含むメッセージをボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信し（ステップＳ２２９）、イベント通知要求処理の完了処理を行って（ステップＳ２３１）、処理を終了する。

（イベント記録処理）
図６に戻り、エアバッグＥＣＵ５０ａのイベント処理部５５は自身のエアバッグＥＣＵ５０ａに備えられた不揮発性メモリ１６０に検出したイベントの情報を含むイベントデータを記録する（ステップＳ１１１）。

図１２はエアバッグＥＣＵ５０ａのイベント処理部５５が自身の不揮発性メモリ１６０にイベントを記録する処理の具体例を示すフローチャートである。まずイベント処理部５５はイベントの記録要求の有無を判別する（ステップＳ２４１）。イベント記録要求がない場合（Ｓ２４１／Ｎｏ）、イベント処理部５５はそのままイベント記録処理を終了する。

一方イベント記録要求がある場合（Ｓ２４１／Ｙｅｓ）、イベント処理部５５はイベント記録要求が発行されているイベントが不揮発性メモリ１６０に記録すべき対象に設定されているか否かを判別する（ステップＳ２４３）。

イベント記録要求の対象となっているイベントが不揮発性メモリ１６０に記録すべき対象に設定されている場合（Ｓ２４３／Ｙｅｓ）、イベント処理部５５はさらに当該イベントの不揮発性メモリ１６０への記録が許可されているか否かを判別する（ステップＳ２４５）。

イベント記録要求が発行されているイベントが不揮発性メモリ１６０に記録すべき対象に設定されているか否か、及び、不揮発性メモリ１６０への記録が許可されているか否かは、あらかじめ設定された情報を参照して判定される。

ステップＳ２４３又はステップＳ２４５のいずれかがＮｏ判定である場合（Ｓ２４３／Ｎｏ又はＳ２４５／Ｎｏ）、イベント処理部５５はそのままステップＳ２４９に進み、イベント記録要求処理の完了処理を行い（ステップＳ２４９）、イベント記録処理を終了する。

イベント記録要求が発行されているイベントの不揮発性メモリ１６０への記録が許可されている場合（Ｓ２４５／Ｙｅｓ）、イベント処理部５５は検知したイベントの情報と併せて、収集していたイベント記録用データを不揮発性メモリ１６０に記録する（ステップＳ２４７）。

次いでイベント処理部５５はイベント記録要求処理の完了処理を行って（ステップＳ２４９）、イベント記録処理を終了する。

（警告ランプ点灯処理）
図６に戻りエアバッグＥＣＵ５０ａのイベント処理部５５はイベント記録処理（Ｓ１１１）の終了後に警告ランプ２０１を点灯させる信号を送信する処理を行う（ステップＳ１１３）。

図１３は警告ランプ点灯処理の具体例を示すフローチャートである。まずイベント処理部５５は故障コード（ＤＴＣ）に故障記録が含まれているか否かを判別する（ステップＳ２５１）。故障コード（ＤＴＣ）に故障記録が含まれている場合（Ｓ２５１／Ｙｅｓ）、イベント処理部５５は警告ランプ２０１の点灯を要求する制御データを含むメッセージを設定する（ステップＳ２５３）。

一方故障コード（ＤＴＣ）に故障記録が含まれていない場合（Ｓ２５１／Ｎｏ）、イベント処理部５５は警告ランプ２０１の消灯を要求する制御データを含むメッセージを設定する（ステップＳ２５５）。

ステップＳ２５３又はステップＳ２５５においてメッセージを設定した後、イベント処理部５５は警告ランプ制御データを含むメッセージをＣＡＮ通信線１５上に送信する（ステップＳ２５７）。これによりメーターパネルの表示を制御するメーター制御ＥＣＵ５０ｄが当該メッセージを受信し、警告ランプ２０１を点灯又は消灯させる。

その後通常時診断処理を行うステップＳ１０５に戻り、ステップＳ１０５〜ステップＳ１１３の各処理を繰り返し実行する。

（３−２．他の制御装置の動作例）
図１４はエアバッグ制御システム１０００におけるボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄにより実行される処理動作の一例を示すフローチャートである。

本実施形態においてはイベントを検知したエアバッグＥＣＵ５０ａは、イベントの記録要求の送信を要するイベントについてのみボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに対して記録要求を含むメッセージを送信する。

したがってボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄは記録要求を含むメッセージを受信した場合、当該ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄ内の記憶部５７の不揮発性メモリにイベントデータを書き込む処理を実行する。

具体的にボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄのイベント情報取得部５３がイベントの記録要求を含むメッセージを受信すると（ステップＳ２５）、イベント処理部５５は受信したイベントデータをエアバッグＥＣＵ５０ａの識別子とともに記憶部５７の不揮発性メモリに記録する（ステップＳ２７）。

このときイベント処理部５５はイベントの記録要求を含むメッセージを受信したときの当該ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄの動作状態を併せて記録してもよい。ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄの動作状態とは例えばボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄの停止状態、初期化状態又は正常駆動状態である。

このようにしてボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄは、イベントを検知したエアバッグＥＣＵ５０ａからイベントの記録要求を含むメッセージを受信した場合に、そのときの動作状態と併せてイベントデータを記録する。これによりボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄの記憶部５７の不揮発性メモリに目的外のイベントデータが記録されて蓄積されることがない。

したがって市場モード以外のモードで記録されたイベントデータを消去する作業負荷を軽減することができる。一方でボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに記録されたイベントデータは、イベント発生時の状況の詳細な解析に用いることができる。

＜３−３．処理モードの設定例＞
次に各制御装置５０のモード設定部５１が処理モードを市場モードに設定する処理の例の幾つかを説明する。

（３−３−１．第１の例）
第１の例は、ＣＡＮ通信線１５を介して接続されたＥＣＵテスター等の外部機器を用いて処理モードを市場モードに設定する例である。図１５は処理モードの設定処理の第１の例を示すフローチャートである。

例えば図２０に示したようにＯＢＤコネクタ９１を介してＥＣＵテスター９０が制御ネットワークに接続され、ユーザの操作入力に基づいて各制御装置５０に対して処理モードの設定要求が送信されてもよい。あるいは各制御装置５０にＥＣＵテスターが直接接続され、ユーザの操作入力に基づいて当該制御装置５０に対して処理モードの設定要求が送信されてもよい。

第１の例では、ユーザがＥＣＵテスターを用いて各制御装置５０の処理モードを市場モードに設定する操作入力を行うと、各制御装置５０のモード設定部５１は市場モードへの設定要求のメッセージ又は信号を取得する（ステップＳ５１）。

次いでモード設定部５１は処理モードを市場モードに設定する（ステップＳ５３）。なお処理モードを市場モードに設定することは、市場モード以外の処理モードの設定を解除することであってもよい。

（３−３−２．第２の例）
第２の例は、自制御装置としてのエアバッグＥＣＵ５０ａが検知したイベントに基づいて処理モードを市場モードに設定する例である。図１６は処理モードの設定処理の第２の例を示すフローチャートである。

例えば車両の組立工程の最終段階あるいは修理整備作業の完了時にエアバッグＥＣＵ５０ａによる故障診断の結果がすべて故障復帰と検知された場合にモード設定部５１は処理モードを市場モードに設定してもよい。

第２の例では、イベント情報取得部５３が所定のイベントを検知すると（ステップＳ６１）、モード設定部５１は検知したイベントが市場モードの設定の要求を伴うイベントであるか否かを判別する（ステップＳ６３）。

例えば検知されたイベントが車両の組立工程の最終段階における故障無しの診断結果である故障無し確定イベントである場合、モード設定部５１は当該イベントが市場モードの設定の要求を伴うイベントであると判定する。

検知されたイベントが市場モードの設定の要求を伴うイベントでない場合（Ｓ６３／Ｎｏ）、モード設定部５１は現在の処理モードの設定を維持して処理を終了する。

一方検知されたイベントが市場モードの設定の要求を伴うイベントである場合（Ｓ６３／Ｙｅｓ）、モード設定部５１は現在設定されている処理モードが市場モードと異なっているか否かを判別する（ステップＳ６５）。

現在市場モードに設定されている場合（Ｓ６５／Ｎｏ）、モード設定部５１はそのまま市場モードの設定を維持して処理を終了する。一方現在の処理モードが市場モードでない場合（Ｓ６５／Ｙｅｓ）、モード設定部５１は処理モードを市場モードに設定して処理を終了する（ステップＳ６７）。

このときエアバッグＥＣＵ５０ａはボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに対して処理モードを市場モードに設定する要求を含むメッセージを送信してもよい。なお第１の例と同様に、処理モードを市場モードに設定することは、市場モード以外の処理モードの設定を解除することであってもよい。

（３−３−３．第３の例）
第３の例は、各制御装置５０が他のいずれかの制御装置５０から受信したメッセージに基づいて処理モードを市場モードに設定する例である。図１７は処理モードの設定処理の第３の例を示すフローチャートである。

例えば車両の組立工程の最終段階あるいは修理整備作業完了時に制御ネットワーク内のいずれかの制御装置５０から送信されるメッセージに市場モードへの設定要求の信号を含ませ、当該メッセージを受信した制御装置５０が処理モードを市場モードに設定してもよい。

第３の例は、第２の例におけるエアバッグＥＣＵ５０ａが処理モードを市場モードに設定する要求を含むメッセージをボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信した場合にボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄにおいて行われる処理の例であってもよい。

例えばボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄのイベント情報取得部５３がエアバッグＥＣＵ５０ａからメッセージを受信すると（ステップＳ７１）、モード設定部５１は受信したメッセージに市場モードの設定要求が含まれているか否かを判別する（ステップＳ７３）。

受信したメッセージに市場モードの設定要求が含まれていない場合（Ｓ７３／Ｎｏ）、モード設定部５１は現在の処理モードの設定を維持して処理を終了する。一方受信したメッセージに市場モードの設定要求が含まれている場合（Ｓ７３／Ｙｅｓ）、モード設定部５１は現在設定されている処理モードが市場モードと異なっているか否かを判別する（ステップＳ７５）。

現在市場モードに設定されている場合（Ｓ７５／Ｎｏ）、モード設定部５１はそのまま市場モードの設定を維持して処理を終了する。一方現在の処理モードが市場モードでない場合（Ｓ７５／Ｙｅｓ）、モード設定部５１は処理モードを市場モードに設定して処理を終了する（ステップＳ７７）。

なお第１の例と同様に、処理モードを市場モードに設定することは、市場モード以外の処理モードの設定を解除することであってもよい。

なおモード設定部５１による市場モードの設定処理は、上記の第１の例〜第３の例に限られない。またモード設定部５１は、上記の第１の例〜第３の例その他の例を組み合わせて市場モードの設定処理を行ってもよい。

＜３−４．効果＞
以上説明したように本実施形態に係るエアバッグ制御システム１０００では、エアバッグＥＣＵ５０ａがイベントを検知した際に、処理モードが市場モードに設定されているか否かによってボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに対する少なくとも一部のイベントの記録要求の送信の要否を切り替える。

具体的にエアバッグＥＣＵ５０ａは、処理モードが市場モードに設定されている場合にはイベントデータの記録要求をボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信する。一方エアバッグＥＣＵ５０ａは、処理モードが市場モードに設定されていない場合には少なくとも一部のイベントの記録要求をボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信しない。

これにより車両の製造段階及び修理整備作業時におけるボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへの目的外のイベントデータの記録が省略され、車両の出荷時あるいは納車時におけるイベントデータの記録を消去する作業負荷を軽減することができる。

図１８は本実施形態に係るボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄによるイベントデータの記録期間について説明するための図である。本実施形態に係るボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄの場合、車両の製造段階においてはエアバッグＥＣＵ５０ａがイベントを検知しても一部又は全部のイベントについては記録要求を含むメッセージの送信が行われない。

このためボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄには目的外のイベントデータの記録が蓄積されることがない。これにより車両の製造が完了して車両を出荷する際に、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに蓄積された目的外のイベントデータの消去作業が不要となる。

車両の整備あるいは修理整備作業時においても同様に、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに目的外のイベントデータの記録が蓄積されることがなく、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに蓄積された目的外のイベントデータの消去作業が不要となる。したがってイベントデータの消去作業に要する時間が省略され、製造コストあるいは修理コストを低減することができる。

＜＜４．第２の実施の形態＞＞
第２の実施の形態に係るエアバッグ制御システム１０００ではイベントを検知したエアバッグＥＣＵ５０ａが処理モードに拘わらずイベントの記録要求をボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに送信し、当該記録要求を受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄが処理モードに応じてイベントデータの記録の要否を切り替える。

＜４−１．エアバッグＥＣＵの処理動作＞
本実施形態に係るエアバッグ制御システム１０００において、自制御装置としてのエアバッグＥＣＵ５０ａは基本的には図６に示すフローチャートにしたがって処理を実行する。ただし、ステップＳ１０９において、イベント通知要求の有無の判定を行うことなく、ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに対してイベントの記録要求を含むメッセージを送信する。

＜４−２．他の制御装置の処理動作＞
図１９は本実施形態に係るエアバッグ制御システム１０００におけるボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄにより実行される処理動作の一例を示すフローチャートである。

ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄのイベント情報取得部５３がエアバッグＥＣＵ５０ａからイベントの記録要求を含むメッセージを受信すると（ステップＳ４１）、イベント処理部５５は処理モードが市場モードに設定されているか否かを判別する（ステップＳ４３）。

処理モードが市場モードに設定されている場合（Ｓ４３／Ｙｅｓ）、イベント処理部５５はボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄ内の記憶部５７の不揮発性メモリにエアバッグＥＣＵ５０ａの識別子とともにイベントデータを記録して処理を終了する（ステップＳ４７）。このときイベント処理部５５はイベントを検知したときのボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄの動作状態を併せて記録してもよい。

一方処理モードが市場モードに設定されていない場合（Ｓ４３／Ｎｏ）、イベント処理部５５は記録要求を受信したイベントのイベントデータを記録する必要があるか否かを判別する（ステップＳ４５）。

上記のステップＳ４３及びＳ４５では、イベント処理部５５は例えば図５の設定例にしたがって判別を行う。その場合にイベント処理部５５は、処理モードの設定が市場モードか市場モード以外かに応じて市場モード又は市場モード以外の欄を参照して、ステップＳ４５の記録の要否を判定する。

ステップＳ４５において、イベント処理部５５は記録要求を受信したイベントのイベントデータを記録する必要があると判定した場合（Ｓ４５／Ｙｅｓ）、上述のステップＳ４７の処理にしたがってボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄ内の記憶部５７の不揮発性メモリにエアバッグＥＣＵ５０ａの識別子とともにイベントデータを記録する（ステップＳ４７）。

一方ステップＳ４５において、イベント処理部５５は記録要求を受信したイベントのイベントデータを記録する必要がないと判定した場合（Ｓ４５／Ｎｏ）、イベントデータを記録することなくそのままイベント処理を終了させる。したがって市場モード以外のモードで記録されたイベントデータを消去する作業負荷を軽減することができる。

なお各制御装置５０の処理モードを市場モードに設定する方法は第１の実施の形態で説明した例を適宜採用することができる。

＜４−３．効果＞
以上説明したように本実施形態に係るエアバッグ制御システム１０００では、イベントの記録要求を含むメッセージ受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄが、処理モードが市場モードに設定されているか否かによって少なくとも一部のイベントデータの記録の要否を切り替える。

具体的にイベントの記録要求を含むメッセージ受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄは、処理モードが市場モードに設定されている場合には記録要求を受信したイベントのイベントデータを記憶部５７に記録する。一方ボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄは、処理モードが市場モードに設定されていない場合には少なくとも一部のイベントデータの記録を行わない。

これにより第１の実施の形態の場合と同様に車両の製造段階及び修理整備作業時におけるボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへの目的外のイベントデータの記録が省略され、車両の出荷時あるいは納車時におけるイベントデータの記録を消去する作業負荷を軽減することができる。したがってイベントデータの記録の消去作業による製造時間あるいは修理整備作業時間の増大及びコストの増加を抑制することができる。

また本実施形態に係るエアバッグ制御システム１０００においても、検知したイベントの内容に応じてボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄによるイベントデータの記録の要否が設定されている。

＜＜５．第３の実施の形態＞＞
第３の実施の形態に係るエアバッグ制御システム１０００ではイベントを検知したエアバッグＥＣＵ５０ａが処理モードに応じてボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄに対する記録要求を含むメッセージの送信の要否を切り替える。

また本実施形態に係るエアバッグ制御システム１０００では記録要求を含むメッセージを受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄが処理モードに応じてイベントデータの記録の要否を切り替える。

つまり本実施形態に係るエアバッグ制御システム１０００ではイベントを検知したエアバッグＥＣＵ５０ａ及びイベントの記録要求を含むメッセージを受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄが、それぞれ処理モードが市場モードに設定されているか否かに応じてイベントデータを記録させるための処理を切り替える。

エアバッグＥＣＵ５０ａによる処理動作は図６に示した第１の実施の形態に係るエアバッグＥＣＵ５０ａによる処理動作のフローチャートにしたがって実行することができる。またボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄによる処理動作は図１９に示した第２の実施の形態に係るボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄによる処理動作のフローチャートにしたがって実行することができる。

本実施形態においては制御装置５０の処理モードが市場モードに設定されていない場合に、エアバッグＥＣＵ５０ａ側でイベントの記録要求を送信するか否かを決定するか、あるいはボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄ側でイベントデータを記録するか否かを決定するかを、イベントの内容に応じて適宜設定することができる。

本実施形態に係るエアバッグ制御システム１０００によっても、第１の実施の形態又は第２の実施の形態に係るエアバッグ制御システム１０００と同様に車両の製造段階及び修理整備作業時におけるボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへの目的外のイベントデータの記録が省略される。これにより車両の出荷時あるいは納車時におけるイベントデータの記録を消去する作業負荷を軽減することができる。したがってイベントデータの記録の消去作業による製造時間あるいは修理整備作業時間の増大及びコストの増加を抑制することができる。

また本実施形態に係るエアバッグ制御システム１０００ではエアバッグＥＣＵ５０ａ側で送信の要否を決定するか、あるいはイベントの記録要求を含むメッセージを受信したボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄ側で記録の要否を決定するかを、イベントの内容に応じて設定することができる。

これによりエアバッグＥＣＵ５０ａのみにイベントの記録を残したい場合やボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄへの記録要求の送信を行いたい場合等にはボディ制御ＥＣＵ５０ｂ、ライト制御ＥＣＵ５０ｃ及びメーター制御ＥＣＵ５０ｄにイベントデータの記録の要否を委ねることができる。したがってイベントの内容に応じて最低限必要な処理を実行させた上で、イベントデータの記録の要否を切り替えることができる。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

４０・・・車両の制御システム、５０・・・制御装置、５０ａ・・・エアバッグＥＣＵ、５０ｂ・・・ボディ制御ＥＣＵ、５０ｃ・・・ライト制御ＥＣＵ、５０ｄ・・・メーター制御ＥＣＵ、５０ｉ・・・助手席乗員検知ＥＣＵ、５１・・・モード設定部、５３・・・イベント情報取得部、５５・・・イベント処理部、５７・・・記憶部、５９・・・通信部、１０００・・・エアバッグ制御システム

Claims (6)

1. 車両に搭載されて互いに通信可能に接続される制御装置（５０ａ〜５０ｄ）において、
   前記制御装置（５０ａ〜５０ｄ）は、イベント処理部（５５）を備え、
   前記イベント処理部（５５）は、
   イベントの情報の記録要求を通知するか否かを切り替える処理、あるいは、前記イベントの情報の記録の要否を切り替える処理、のうちのいずれか一方又は両方を実行する
   ことを特徴とする制御装置。
2. 前記制御装置（５０ａ）は、
   処理モードを設定するモード設定部（５１）と、
   自制御装置（５０ａ）に関連する所定のイベントの情報を検知するイベント情報取得部（５３）とを備え、
   前記イベント処理部（５５）は、
   前記イベントの情報の記録要求を通知するか否かを切り替える処理を実行する場合、
   検知した前記イベントの情報の記録要求を他の制御装置（５０ｂ〜５０ｄ）に通知するか否かを設定された前記処理モードに応じて切り替える
   ことを特徴とする請求項１に記載の制御装置。
3. 前記イベント処理部（５５）は、
   前記処理モードが所定の処理モードに設定されている場合、少なくとも一つの前記イベントの情報の記録要求を他の制御装置（５０ｂ〜５０ｄ）に通知せず、
   前記処理モードが前記所定の処理モードに設定されていない場合、設定されている処理モードに応じて前記イベントの情報の記録要求を他の制御装置（５０ｂ〜５０ｄ）に通知する
   ことを特徴とする請求項２に記載の制御装置。
4. 前記イベント情報取得部（５３）は、
   所定のイベントの情報を検知した他の制御装置（５０ａ）から前記イベントの情報の記録要求を取得し、
   前記イベント処理部（５５）は、
   前記イベントの情報の記録の要否を切り替える処理を実行する場合、
   前記記録要求を取得した前記イベントの情報の記録の要否を設定された前記処理モードに応じて切り替える
   ことを特徴とする請求項２又は３に記載の制御装置。
5. 前記イベント処理部（５５）は、
   前記処理モードが所定の処理モードに設定されている場合、少なくとも一つの前記記録要求を取得した前記イベントの情報を記録せず、
   前記処理モードが前記所定の処理モードに設定されていない場合、設定されている処理モードに応じて前記記録要求を取得した前記イベントの情報を記録する
   ことを特徴とする請求項４に記載の制御装置。
6. 互いに通信可能に接続された複数の制御装置（５０ａ〜５０ｄ）を含む車両の制御システム（４０）において、
   前記制御装置（５０ａ〜５０ｄ）は、イベント処理部（５５）を備え、
   前記イベント処理部（５５）は、
   イベントの情報の記録要求を通知するか否かを切り替える処理、あるいは、前記イベントの情報の記録の要否を切り替える処理、のうちのいずれか一方又は両方を実行する
   ことを特徴とする車両の制御システム（４０）。

Images