以下に添付図面を参照しながら本発明の好適な実施の形態について詳細に説明する。なお本明細書及び図面において実質的に同一の機能構成を有する構成要素については同一の符号を付することにより重複説明を省略する。
<<1.背景技術の詳述>>
本発明の背景技術を詳細に説明した後、本発明の実施の形態を説明する。
図20は車両に搭載された複数の制御装置(ECU:Electronic Control Unit)を互いに接続する制御ネットワーク10の構成の一例を示す。
図示した制御ネットワーク10はボディ系CANネットワーク20とシャシー/パワートレイン系CANネットワーク30とを含む。ボディ系CANネットワーク20とシャシー/パワートレイン系CANネットワーク30とはゲートウェイECU50hを介して互いに通信可能に接続されている。
ボディ系CANネットワーク20及びシャシー/パワートレイン系CANネットワーク30はそれぞれCAN(Controller Area Network)通信線を介して互いに通信可能に接続された複数の制御装置50a~50h(以下、特に区別が必要な場合を除き制御装置50と総称する。)を含む。
ボディ系CANネットワーク20はCAN通信線を介して互いに通信可能に接続されたエアバッグECU50a、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dを備える。
エアバッグECU50aは主として車両の衝突を検知してエアバッグ装置を制御する。エアバッグECU50aにはLIN(Local Internet Network)を介して助手席乗員検知ECU50iが接続されている。
ボディ制御ECU50bは主として空調装置、パワーウィンドウ、ワイパー装置、ドアロック及びパワーシートを制御する。ライト制御ECU50cは主として室内灯(ルームランプ)、前照灯、後退灯、車幅灯等の車室内及び車室外の灯火類を制御する。メーター制御ECU50dは主として車両の車速を検出してメーターパネル内のスピードメーターを表示し記録するとともに、記録された車速を車両の他の部品へ送信する。またメーター制御ECU50d以外の他の制御装置50からCAN通信線を介して送信されるメッセージに含まれる故障有無を示す信号を元に、メーターパネル内に配置されるメーター制御ECU50d以外の他の制御装置50に関わる異常を示す警告ランプを制御する。故障有りの場合には当該制御装置の警告ランプを点灯させ、車両の運転者に故障を報知する。
またボディ系CANネットワーク20にはOBD(On Board Diagnosis)コネクタ91を介してECUテスター90が接続可能になっている。例えばECUテスター90はCAN通信線を介して各制御装置50に対してテスト信号を送信し、各制御装置50から応答信号を受信することにより各制御装置50の診断を実行する。
あるいは、ECUテスター90は、各制御装置50によってそれぞれ実施された故障診断の結果記録される、故障部位を示す故障コード(Diagnostic Trouble Code)データと、その故障が現在も継続しているか、あるいは、過去に故障が存在し、現在は復帰しているか等を示す故障状態記録データを受信し、受信結果をディスプレーに表示する。これにより、ディーラーや修理工場において故障部位の特定や故障修理後に、故障コードとその故障の状態を確認すること等により、修理が正しく完了したか否か等の動作確認に使用される。修理完了後には、整備士がECUテスター90を操作することにより、ECUテスター90から故障コード等の記録を消去するコマンドが制御装置50に送信され、制御装置50は故障が復帰した場合には記録していた故障コードデータや故障状態記録データ等を消去する。
シャシー/パワートレイン系CANネットワーク30はCAN通信線を介して互いに通信可能に接続された自動変速機ECU50e、車両安定制御ECU50f及びエンジンECU50gを備える。
自動変速機ECU50eは主として自動変速機を制御する。車両安定制御ECU50fは主として自動変速機、ブレーキシステム及びエンジンを統合的に制御して車両の横滑り等を防止する。エンジンECU50gは主としてエンジンを制御する。
それぞれの制御装置50は制御装置50あるいは車両に発生した様々なイベントを検知する。ここで「イベント」とは制御装置50が現在の状態から異なる状態に遷移する事象を指す。
イベントを検知した制御装置(以下、「自制御装置」ともいう。)は検知したイベントの情報(以下、「イベントデータ」ともいう。)を自制御装置内に記録するだけでなくCANやLIN等の通信手段を介して他の制御装置(以下、自制御装置から所定のメッセージが送信される制御装置を「他の制御装置」という。)に対してイベントの記録要求を含むメッセージを送信する。
イベントの記録要求を含むメッセージを受信した他の制御装置は当該他の制御装置内に自制御装置の識別子とともにイベントデータを記録する。このとき他の制御装置は車両の状態の情報を同時に記録してもよい。これによりイベントデータを記録した複数の制御装置50を解析することでイベントの発生状況を詳細に知ることができる。
以下エアバッグ装置を制御するエアバッグECU50aが自制御装置である場合を例に採って説明する。
例えば車両の組立工程においてステアリングホイールの組付けは通常車両の製造過程の最終段階で行われる。ステアリングの中立位置の調整、車両の前輪のトーイン調整が完了した後、ステアリングシャフトにステアリングホイールが組み付けられ、さらにロックナットが締結された後に、ステアリングホイールにはドライバを保護するためのエアバッグ装置が搭載される。
エアバッグECU50aは通電状態において常時エアバッグ装置が正しく搭載されているか否かを診断する。このためエアバッグECU50aは車両の組立工程においてステアリングホイールの組付けが完了するまで運転席エアバッグ未装着故障を検知し続ける。
このとき通電状態の他の制御装置50b,50c・・・が存在する場合には当該他の制御装置50b,50c・・・も同様に、イベントの記録要求にしたがって故障検知イベントデータを記録する。このような場合においては車両の製造が完了した段階でイベントデータが記録されたすべての制御装置50に対して記録されているイベントデータを消去する作業が必要となる。
また車両の製造時においては電子制御部品のコネクタの接続や機械部品のボルト及びナットの締結等が完了した後などの車両の組立完了後に、それぞれの制御装置50に対してEOL(End Of Line programming)操作が行われる場合がある。
EOL操作は制御装置50の部品の種類を削減するために、車両の製造の最終段階で部品の組付け後に車両のグレードや仕向地ごとに機能の有無又は出力特性等の設定を行ったり車両又は部品の個体差を調整したりするための設定を行う操作である。EOL操作による設定情報は例えば不揮発性メモリに書き込まれる。
具体的に制御装置50は複数の車種に対応可能に構成される一方、不揮発性メモリには制御装置50が搭載される車種に応じた装備有無データが記憶される。装備有無データは例えば車両の製造ラインで外部接続されるECUテスター90等を用いて、決定された車種に応じて制御装置50に入力される。
このようなEOL操作が実施されていない制御装置50を搭載した車両が市場に流通することを防ぐために、制御装置50がEOL操作の未実施を診断する機能を備える場合がある。例えば当該診断機能によりEOL操作の未実施が検知された場合、制御装置50は故障を記録したり警告灯を点灯させたり等の処置を行い組立作業者に異常を知らせる。
車両が市場に向けて出荷されるには単に組立が完了しているだけではなくEOL操作が必要な制御装置50すべてに対してEOL操作が完了していることが必要になる。このため車両の製造段階でEOL操作の完了前に通電が行われる制御装置50はEOL操作の未実施状態のまま組付けられる。制御装置50のEOL操作が適切に完了する前に制御装置50が通電状態になると、EOL未実施イベントが検知され得る。
したがってこのような制御装置50はEOL操作の実施が完了するまで継続的に異常を検知する。またEOL操作が未実施の状況では初期設定のままで制御動作が行われることから例えば装備過装着又は未装着の故障が確定した状態となっている場合も考えられる。
また制御装置50同士が相互に通信を行い相互の存在を確認する診断を行う場合がある。例えばある制御装置50から所定の周期で送信されるメッセージを別の制御装置50が受信するようになっている場合、受信対象となっているメッセージが送信周期よりも長い期間途絶しているか否か等を判定することにより受信対象メッセージの途絶を診断する場合がある。
さらにボディ系CANネットワーク20又はパワートレイン系CANネットワーク30等に属する制御装置50が送受信するメッセージの構成とそれらのネットワークを介するゲートウェイECU50hが処理するメッセージのルーティング規則はEOL操作の前後で異なる場合がある。このため互いの存在を確認するための定期的なメッセージの送受信等を正常に行えない場合がある。
例えば電源供給の形態の違いや通信形態の違い、さらには車両のグレードの違いによる装備有無等により互いの存在を確認する処理が正常に実行できない場合がある。具体的には、ある制御装置50において“A”というメッセージは初期状態として送信が無効に設定され、EOL操作により所定のメッセージの定周期送信機能が無効な状態から有効な状態に設定されるように構成される場合がある。このような場合においても制御装置50の故障が確定した状態となる場合が考えられる。
また、例えば車両の製造時又は修理整備作業時において制御装置50をCAN通信線15に接続する前に制御装置50が通電状態になると、CAN通信途絶イベントが検知され得る。
以上例示したような状況においてイベントを検知した制御装置50が存在する場合には当該制御装置50から他の制御装置50に対するイベントの記録要求に伴って他の制御装置50もイベントデータを記録しなければならない。
しかしながら制御装置50によるイベントデータの記録は本来車両出荷後に車両が使用されている間に検出したイベントデータの記録を目的とする機能であるにもかかわらず、目的外のイベントデータの記録が行われている。
これらの目的外のイベントを検知した制御装置50から他の制御装置50に対してイベントの記録要求を含むメッセージが送信されると、他の制御装置50は当該イベントデータを当該他の制御装置50内に記録する。
上述の車両の製造段階における目的外のイベントデータの記録は予期されるものであるにもかかわらず行われているため、車両の市場への出荷前には記録されているイベントデータを消去する必要が生じている。
このような目的外のイベントデータの記録は車両の製造段階に限らず組立工場からの出荷後の車両の修理整備作業時においても生じる。整備工場で車両の故障修理を行う場合、上記のような故障の検知が予期された環境下で修理作業が行われるため、車両の整備が完了した後には記録されているイベントデータを消去する必要がある。
例えばEOL操作の対象である制御装置50を車両組み立て工場からの出荷後の車両の修理整備作業時に交換する場合、制御装置50は初期状態のままで車両に組付けられて組付け後にEOL操作が行われる場合がある。このため車両の製造段階と同様に故障が確定した状態になることが予期される。
図21は従来の制御装置を用いた場合におけるイベントデータの蓄積期間について説明するための図である。上述のように車両の製造段階においてはイベントを検知した制御装置によるイベントデータの記録及び他の制御装置へのイベントの記録要求を含むメッセージの送信が行われる。
これに伴って他の制御装置には目的外のイベントデータについても記録されてそれぞれの制御装置の不揮発性メモリにイベントデータが蓄積される。車両の製造段階における目的外のイベントデータの記録は回避できないものであるため、車両の製造が完了して車両を出荷する際には蓄積された目的外のイベントデータの消去作業が行われる。
車両の整備あるいは修理整備作業時においても同様に作業終了時には蓄積された目的外のイベントデータの消去作業が行われる。イベントデータの消去作業に要する時間はネットワーク上の制御装置の数が多いほど長くなり、それに伴い、車両製造工程、車両修理工程に要する作業時間が増大し、結果として製造コストあるいは修理コストも増大する。
このような背景の下、本実施形態に係る車両の制御システムはあらかじめ予期される目的外のイベントデータの記録の消去作業の負荷を軽減することができるものとなっている。
<<2.車両の制御システムの基本構成例>>
まず後述する各実施の形態に共通する車両の制御システムの基本構成例を説明する。
<2-1.車両の制御システムの全体構成例>
図1は本実施形態に係る車両の制御システム40の全体構成例を簡略化して示した模式図である。図1は図20に示した車両の制御システムの一部を簡略化して示したものである。制御システム40は複数の制御装置50を備えている。以下エアバッグECU50aが自制御装置として機能し、ボディ制御ECU50b、ライト制御ECU50c、メーター制御ECU50dが他の制御装置として機能する場合の例を説明する。
なお本実施形態の説明中、複数の制御装置としてのエアバッグECU50a、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dの区別を要しない場合には単に制御装置50と総称する。
制御装置50はそれぞれ接続されている機器70a,70b,70c,70dの制御を行う。制御装置50はそれぞれCAN通信線15を介して相互にメッセージを送受信する。
エアバッグECU50aにはLIN通信線17を介して助手席乗員検知ECU50iが互いに通信可能に接続されている。
<2-2.制御装置の機能構成>
図2は本実施形態に係る車両の制御システム40に適用可能な制御装置50の機能構成を示すブロック図である。図示した制御装置50の構成例は、自身がイベントを検知する自制御装置、及びイベントの記録要求を含むメッセージを受信する他の制御装置のいずれにも適用することができる。
制御装置50はCPU等のプロセッサを備えて構成されている。制御装置50はモード設定部51、診断部52、イベント情報取得部53、イベント処理部55、記憶部57及び通信部59を備える。このうちのモード設定部51、診断部52、イベント情報取得部53及びイベント処理部55はCPU等のプロセッサによる各種プログラムの実行により実現される機能である。
なお制御装置50の一部又は全部はCPUやMCU等のプロセッサにより構成される以外に、ファームウェア等の更新可能なもので構成されていてもよく、またCPU等からの指令によって実行されるプログラムモジュール等であってもよい。
通信部59はCAN通信線15上へのメッセージの送信及びCAN通信線15上からのメッセージの受信を行うインターフェースである。
記憶部57は少なくとも取得したイベントデータを記憶する不揮発性メモリを含む。また記憶部57はソフトウェアプログラム及び制御パラメータ等を記憶するROM(Read Only Memory)や、取得した情報、制御パラメータ及び演算処理結果の情報等を記憶するRAM(Random Access Memory)等の記憶素子を含む。この他に記憶部57はCD-ROMやストレージ装置等の他の記憶媒体による記憶装置を含んでもよい。
モード設定部51は制御装置50の処理モードを制御する。処理モードの一つである市場モードとは車両の製造後に車両が市場に向けて出荷された後かつ車両の修理整備時以外の状態で設定される処理モードである。つまり車両の完成後に車両が通常の使用状態に置かれている場合に設定される処理モードである。
モード設定部51は例えばCAN通信線15を介して接続されるECUテスター90(図20を参照。)に対して作業者が操作入力を行うことにより、あるいは検知したイベントの内容又は受信したメッセージの内容に応じて制御装置50の処理モードを市場モードに設定する。
またモード設定部51は、制御装置50の処理モードを一旦市場モードに設定した後に、車両が出荷並びに販売され、例えばディーラーや修理工場等で修理整備作業を開始する際に市場モードをリセットする。処理モードのリセットは例えばCAN通信線15を介して接続されるECUテスター90に対して作業者が操作入力を行うことによって行われる。
なおモード設定部51により設定可能な処理モードの例としては、市場モード以外にも、車両の製造段階又は修理整備段階に設定された工場用モード、ディーラー用モード、サプライヤー用モードなどが挙げられる。
診断部52は自身の制御装置50に関する診断又は自身の制御装置50に接続された各種機器70あるいはLIN通信線17により接続されたサブネットワーク上の構成部品に関する診断を実行する。例えば診断部52はCAN通信線15を介した通信の途絶を診断するCAN途絶診断や、制御装置50に接続されたセンサの故障診断等を実行してもよい。診断部52は診断結果に関する情報を記憶部57に記憶する。
イベント情報取得部53は制御装置50又は車両に発生した種々のイベントデータを取得する。例えば制御装置50自身がイベントを検知する場合、当該イベントを検知する動作がイベントデータを取得する処理に相当する。例えば制御装置50のイベント情報取得部53は診断部52により実行される診断処理の結果に基づいてイベントを検知する。
また制御装置50がイベントを検知した他の制御装置50から送信されたイベントの記録要求を含むメッセージを受信する場合、当該記録要求の受信動作がイベントデータを取得する処理に相当する。
制御装置50のイベント情報取得部53が検出するイベントは例えば以下のイベントを含む。
-通信途絶イベント
-異常検知イベント
-異常復帰イベント
-故障確定イベント
-故障復帰イベント
-EOL未実施イベント
-製造時不具合イベント
通信途絶イベントはCAN通信線15あるいはLIN通信線17との間の通信が途絶えた場合に検知されるイベントである。例えば制御装置50とCAN通信線15とを接続する通信線が断線した場合に制御装置50が受信対象としているCANメッセージを受信することができなくなることにより通信途絶イベントが検知される。
または、制御装置50が受信対象としているCANメッセージを送信する他の制御装置50のEOL操作が実施されておらず、定周期送信機能によるCANメッセージの送信が行われない場合に、制御装置50がCANメッセージを受信することができないために通信途絶イベントが検知される。
異常検知イベントは制御装置50に関連する異常が見られた場合に検知されるイベントである。例えばイベント情報取得部53は制御装置50に接続された機器70aの故障診断において異常が見られた場合に異常検知イベントを検知する。異常復帰イベントは制御装置50に関連する異常が解消した場合に検知されるイベントである。
故障確定イベントは制御装置50に関連する異常が確定した場合に検知されるイベントである。例えばイベント情報取得部53は制御装置50に接続された機器70の異常を検知した状態が所定時間継続した場合に故障を確定し、それを故障確定イベントとする。またイベント情報取得部53は、制御装置50に関連する異常が解消した状態が所定時間継続した場合に故障の復帰を確定し、それを故障復帰イベントとする。
異常検知イベント、異常復帰イベント、故障確定イベント及び故障復帰イベントについては、制御装置50に接続された機器70に適用した例を例示したが、制御装置50に搭載される回路に適用してもよい。
EOL未実施イベントは制御装置50のEOL操作が未実施の場合に検知されるイベントである。イベント情報取得部53は例えばEOL操作の未実施を診断する診断処理に基づいてEOL操作が未実施の場合やEOL操作によって記憶部57の不揮発性メモリに書き込まれた設定情報が正常でない場合にEOL未実施イベントを検知する。
製造時不具合イベントは市場モード以外の設定となる車両の製造時あるいは修理整備作業時においてのみ検知を有効とするイベントである。例えば製造時不具合イベントとしては、車両の製造時において制御装置50のコネクタや、機器70等を相互に接続する図示しないワイヤーハーネスのコネクタと、コネクタピンの嵌合不良等による故障確定イベントが挙げられる。また製造時不具合イベントとしては、制御装置50と機器70とを接続するワイヤーハーネスの断線などによる故障確定イベントが挙げられる。また製造時不具合イベントとしては、制御装置50から送信されるCANメッセージを受信することができないCANメッセージの通信途絶による故障確定イベントが挙げられる。また製造時不具合イベントとしては、EOLが失敗した場合にEOL未実施故障が継続することによる故障確定イベントなどが挙げられる。
通常、車両の製造工場における製造工程と製造設備は複数の車両型式の製造に共用されることが多い。したがって、新型車において量産に近い時期に実施する主に製造工程や製造設備の確認を目的とした台数を限定した試作車両の製造と、既存の車両製造ラインにおける現在量産されている車両の製造が車両製造ラインに同時に流れることになる。試作車両の製造工程内で機器のワイヤーハーネスの断線故障を示す故障コード記録やCANメッセージの通信途絶を示す故障コード記録が記録された車両が見つかった場合に、製造工程内に測定器を持ち込み故障の発生の要因を調査することは、既に量産中の車両製造ラインを一時的に停止することになる。これでは工場全体の製造効率を下げることになってしまうため、実施することが困難な場合が多い。
したがって、製造時不具合イベントを検知した場合、他の制御装置50に向けてイベントの記録要求を含むメッセージの送信が行われ、これらのイベントの情報が自制御装置50だけでなく他の制御装置50に記録される。これにより、故障がどの時点で発生したかを特定することができ、異常部位の特定及び問題解消に有用となる。
工場用モードは量産工程や量産製造装置を使用した試作車両の製造時にのみ設定してもよいし、新型車の量産開始後、安定的に製造ができることが確認された後に設定を解除してもよい。工場用モードは、制御装置50を製造する部品のサプライヤーの出荷時に予め設定された上で車両の製造工場に納入されてもよい。この場合には、車両におけるイグニッションスイッチOFFからONの際には既に工場用モードがセットされているため、不要なイベント記録を無効にする効果を得ることができる。また、工場用モードから市場モードへの切り替えは、車両の製造工程内のEOL工程で実施してもよい。
これに対して通常市場で用いられる車両の機能のなかには、製造工程あるいはディーラーでの検査工程については不要な機能がある。これらの機能に関する異常又は故障の情報は、市場モード以外において他の制御装置50に記録することを要しない。このため制御装置50の処理モードが市場モードか市場モード以外かによって選択的に他の制御装置50への記録の要否を切り分けることが有用である。
イベントを検知した制御装置50のイベント情報取得部53は、通信部59を介して、当該イベントの記録要求を含むメッセージをCAN通信線15上に送信する。これにより通信部59を介して当該メッセージを受信した他の制御装置50のイベント情報取得部53は当該イベントの記録要求を取得する。
イベント処理部55は取得したイベントデータを不揮発性メモリに記録させるための処理を行う。イベント処理部55の基本的な機能として、所定のイベントを検知した制御装置50のイベント処理部55は制御装置50内の記憶部57の不揮発性メモリにイベントデータを記録する処理を行う。
またイベントを検知した制御装置50のイベント処理部55は、制御装置50の識別子とともにイベントの記録要求を含むメッセージを、制御装置50の処理モードが市場モードに設定されているか否かによってイベントデータをCAN通信線15上に送信する処理を行う。
他の制御装置50がイベントの記録要求を含むメッセージを受信すると、他の制御装置50のイベント処理部55は当該他の制御装置50内の記憶部57の不揮発性メモリにメッセージを送信した制御装置50の識別子とともにイベントデータを記録する処理を行う。
このとき、他の制御装置50のイベント処理部55は他の制御装置50の処理モードが市場モードに設定されているか否かによってイベントデータを当該他の制御装置50内の記憶部57の不揮発性メモリに記録させるか否かを切り替える。
他の制御装置50のイベント処理部55は処理モードが市場モードに設定されている場合にはイベントデータを他の制御装置50の記憶部57の不揮発性メモリに記録させる処理を行う。
一方他の制御装置50のイベント処理部55は処理モードが市場モードに設定されていない場合には一部又は全部のイベントデータを記憶部57の不揮発性メモリに記録させないように処理を行う。これにより車両の製造完了後あるいは修理整備作業後に目的外のイベントデータの記録を消去する作業の負荷を軽減することができる。
<2-3.エアバッグ制御システムの具体的構成例>>
次に本実施形態に係る車両の制御システム40の一例としてのエアバッグ制御システム1000の構成例を具体的に説明する。
図3はエアバッグECU50aを含むエアバッグ制御システム1000の構成例を示す説明図である。エアバッグ制御システム1000は車両に設けられた各種加速度センサによって検出されたセンサ信号をモニタし、車両が衝突したと判断した場合に運転席又は助手席などの各部位のエアバッグを展開することにより車両の衝突時の搭乗者の安全性を向上させる。
エアバッグ制御システム1000はエアバッグECU50a、助手席乗員検知ECU50i、メーター制御ECU50d、バッテリ電源400及びイグニッションスイッチ410を備える。エアバッグECU50a、メーター制御ECU50d及び助手席乗員検知ECU50iはそれぞれ図1に示した制御システム40の制御装置50a、制御装置50d及び制御装置50iに相当する。なお図3には示されていないもののCAN通信線15L,15Hにはボディ制御ECU50b及びライト制御ECU50c等が相互に通信可能に接続されている。
またエアバッグ制御システム1000は運転側エアバッグ用スクイブ500、助手席側エアバッグ用スクイブ510、右サイドエアバッグ用スクイブ520、左サイドエアバッグ用スクイブ530、右カーテンエアバッグ用スクイブ540及び左カーテンエアバッグ用スクイブ550を備える。
またエアバッグ制御システム1000はフロント右加速度センサ600、フロント左加速度センサ610、右サイド加速度センサ620及び左サイド加速度センサ630を備える。
バッテリ電源400は車両に搭載された鉛蓄電池など各種の蓄電池である。バッテリ電源400は電源ライン405を介してメーター制御ECU50d、ライト制御ECU50cへ電源を直接供給するとともに電源ライン405を介して車両の各種の図示しない他の制御装置等へも電源を直接供給する。
イグニッションスイッチ410は車両のエンジンを始動したり切ったりするスイッチである。車両のエンジンを切った状態ではイグニッションスイッチ410は「OFF」になる。この状態からユーザがキーを回すことによってイグニッションスイッチ410は「ON」になる。
イグニッションスイッチ410が「ON」になるとバッテリ電源400がイグニッションライン407を介してメーター制御ECU50d、助手席乗員検知ECU50i及びエアバッグECU50aへ電源が供給される。
メーター制御ECU50dは警告ランプ201や図示しないインストルメントパネルに対して点灯信号又は表示信号等を送信する。例えば、エアバッグECU50aから送信されたエアバッグ警告灯ON/OFF信号に基づくメーターパネル内のエアバッグ警告灯の点灯/消灯制御、ライト制御ECU50cから送信された前照灯点灯中/非点灯中信号に基づくメーターパネル自体の照明点灯/消灯制御をするようになっている。メーター制御ECU50dは車速センサの信号に基づいて車速を検出して記録し、CAN通信線15L,15Hを介して、記録した車速をエアバッグECU50aへ送信する。同様に、図示しない車両安定制御ECUは図示しないブレーキスイッチの信号に基づいて運転者のブレーキ操作状態を検出して記録し、CAN通信線15L,15Hを介して、記録したブレーキ操作状態をエアバッグECU50aへ送信する。
これによりエアバッグECU50aは車両がどのような状態で運転されているか、例えば車両のブレーキ状態などを検出することができる。この他エアバッグECU50aはボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dを介して車両の種々の状態の情報を検出する。
助手席乗員検知ECU50iは車両の助手席のシート上の重量を図示しない荷重センサの信号に基づいて検出し助手席の乗員状態を判定する。例えば助手席乗員検知ECU50iは大人の男性、小柄な女性、子供又は空席などの状態を判定する。
助手席乗員検知ECU50iは、LIN通信線17を介して、判定された助手席の乗員状態をエアバッグECU50aへ送信する。エアバッグECU50aは例えば助手席のシート上の乗員状態をモニタすることによって、車両のフロント衝突時において例えば助手席の乗員が子供の場合に意図しない助手席エアバッグ用スクイブ510の通電を抑制し、図示しない助手席側エアバッグの展開を抑制することができる。
エアバッグECU50aは電圧検出器101、昇圧回路102、電圧検出器103、キャパシタ(バックアップ電源)104、電圧検出I/F(InterFace)105,107、DC-DCコンバータ106、CAN通信トランシーバ108及びLIN通信トランシーバ110を備える。
またエアバッグECU50aはMCU(Micro Controller Unit)120、ASIC(Application Specific Integrated Circuit)140、加速度センサ150及び不揮発性メモリ160を備える。
電圧検出器101はバッテリ電源400からイグニッションスイッチ410を介してエアバッグECU50aへ供給された電源電圧値を検出する。電圧検出I/F105は電圧検出器101によって検出された電圧信号をMCU120へ出力するためのインターフェースである。電圧検出器101によって検出された電圧信号は電圧検出I/F105を介してMCU120へ出力される。
昇圧回路102はバッテリ電源400からイグニッションスイッチ410を介してエアバッグECU100へ供給された電源電圧を昇圧する回路である。昇圧回路102は例えばバッテリ電源400から供給された9Vから16Vの電源電圧を33V程度まで昇圧する。昇圧回路102は昇圧した電圧をキャパシタ104及びDC-DCコンバータ106へ供給する。
電圧検出器103は昇圧回路102から出力された電源電圧値を検出する。電圧検出I/F107は電圧検出器103によって検出された電圧信号をMCU120へ出力するためのインターフェースである。電圧検出器103によって検出された電圧信号は電圧検出I/F107を介してMCU120へ出力される。
キャパシタ104は昇圧回路102から供給された電圧の充放電を行う蓄電器でありバッテリ電源400のバックアップ電源となる。DC-DCコンバータ106は昇圧回路102から供給された電圧をMCU120で使用される電圧(例えば5V)へ変換(降圧)する変換器である。DC-DCコンバータ106は降圧した電圧をMCU120へ供給する。
CAN通信トランシーバ108はCAN規格に基づいてCAN通信線15L,15Hを介してメーター制御ECU50d及び図示しないボディ制御ECU50b及びライト制御ECU50cとの間でメッセージを送受信するインターフェースである。CAN通信トランシーバ108によって受信されたデータはMCU120へ送信される。
LIN通信トランシーバ110はLIN通信線17を介して助手席乗員検知ECU50iとの間でデータの送受信を行うインターフェースである。LIN通信トランシーバ110は通信信号の電圧レベルを変換する。例えばLIN通信トランシーバ110はMCU120が取り扱える5V系の信号レベルをLINの電圧レベル(12V)に変換する。
MCU120はA/D(Analog to Digital Converter)121、CPU122、ROM124、RAM126及びCAN通信コントローラ128を備える。またMCU120はLIN通信コントローラ132及びSPI(Serial Peripheral Interface)134,136,138を備える。ROM124、RAM126及び不揮発性メモリ160は、図2に示した記憶部57に相当する。
A/D121、CPU122、ROM124、RAM126、CAN通信コントローラ128、LIN通信コントローラ132及びSPI134,136,138はMCU120の内部バス170を介して相互に接続されている。
A/D121は電圧検出I/F105,107を介して入力されたアナログ電圧信号をデジタル電圧信号へ変換する。CPU122はROM124又はRAM126に格納された各種プログラムを実行する演算処理部である。CPU122はROM124又はRAM126に格納された各種プログラムを実行することにより、エアバッグECU50aの各種機能を実行する。
図3に示したエアバッグECU50aの例では、CPU122が各種プログラムを実行することにより、図2に示したモード設定部51、診断部52、イベント情報取得部53及びイベント処理部55の機能が実現される。
ROM124はエアバッグECU50aの各種機能を実行するためのデータ及び各種プログラムを格納するメモリである。RAM126はROM124に格納された各種プログラムのうちCPU122で実行されるプログラムの演算結果などを格納する比較的小容量で高速アクセスが可能なメモリである。
CAN通信コントローラ128はCAN通信トランシーバ108を介してメーター制御ECU50d又は図示しない車両の他の部品との間の通信を行うコントローラである。LIN通信コントローラ132は非同期シリアル通信を制御する。エアバッグECU50aはLIN通信トランシーバ110を介して助手席乗員検知ECU50iと通信する。
図3に示したエアバッグECU50aの例では、MCU120がCAN通信トランシーバ108及びLIN通信トランシーバ110を介してデータを送受信し、これらを用いて図2に示した通信部59の機能が実現されている。
SPI134はクロック同期式シリアル通信のインターフェースでありASIC140とMCU120内の各デバイスとのインターフェースとなる。SPI136は加速度センサ150とMCU120内の各デバイスとのインターフェースとなる。SPI138は不揮発性メモリ160とMCU120内の各デバイスとのインターフェースとなる。
加速度センサ150はエアバッグECU50aが配置された場所における加速度を検出するセンサである。加速度センサ150は、SPI136を介して、検出した加速度をMCU120へ出力する。例えば、エアバッグECU50aは通常、車両の前後方向の中心軸上に設置され、より具体的には車体のフロアトンネル上の剛性の高い部位にボルト・ナットまたはボルト・タップ穴などの機械的な締結手段により固定される。車体の前面や側面に衝撃を受ける衝突事象において、エアバッグECU50aに搭載された加速度センサ150は車体を介して加速度を検出する。
不揮発性メモリ160は電力を供給しない場合においても記録を保持するメモリであり、例えばEEPROM(Electrically Erasable Programmable Read Only Memory)である。不揮発性メモリ160は例えばSPI138を介してMCU120から出力されたデータを記録する。
ASIC140は複数機能の回路を1つにまとめた集積回路である。ASIC140はスクイブI/F142とセンサI/F144とを備える。スクイブI/F142は運転側エアバッグ用スクイブ500、助手席側エアバッグ用スクイブ510、右サイドエアバッグ用スクイブ520、左サイドエアバッグ用スクイブ530、右カーテンエアバッグ用スクイブ540及び左カーテンエアバッグ用スクイブ550へエアバッグの展開信号を送信するインターフェースとなる。
またセンサI/F144はフロント右加速度センサ600、フロント左加速度センサ610、右サイド加速度センサ620及び左サイド加速度センサ630から送信される加速度信号を受信するインターフェースとなる。フロント右加速度センサ600、フロント左加速度センサ610はそれぞれ車体の前部における剛性の高い金属部に機械的に締結され、車体の前部に対する衝突時に生じる加速度を検出する。右サイド加速度センサ620及び左サイド加速度センサ630は車体の側面にあるBピラーの付け根付近など、車体の概側面部の車室内側に締結され車体の側面衝突時に受ける車体の横方向に対する衝撃を検出する。フロント右加速度センサ600、フロント左加速度センサ610、右サイド加速度センサ620及び左サイド加速度センサ630とエアバッグECU50aとはワイヤーハーネスを介してコネクタなどの電気的着脱手段により接続される。
運転側エアバッグ用スクイブ500はMCU120からスクイブI/F142を介して送信された展開信号に基づいて運転席側の点火装置(スクイブ)に電流を供給しガス発生剤に着火することで高圧ガスを発生させ、瞬時にエアバッグを膨らませる。
助手席側エアバッグ用スクイブ510、右サイドエアバッグ用スクイブ520、左サイドエアバッグ用スクイブ530、右カーテンエアバッグ用スクイブ540及び左カーテンエアバッグ用スクイブ550も同様にMCU120から送信された展開信号に基づいて車両の各場所に配置されたエアバッグを膨らませる。
フロント右加速度センサ600は車両のフロントの右側に配置された加速度センサであり、センサで検出した加速度をセンサI/F144を介してMCU120へ送信する。またフロント左加速度センサ610、右サイド加速度センサ620及び左サイド加速度センサ630も同様に車両の各場所に配置されており、車両の各場所における加速度を検出してMCU120へ送信する。
<2-4.エアバッグECUが検知するイベント>
制御装置がエアバッグECU50aの場合、図2に示したイベント情報取得部53は上述した制御装置50が検知する共通のイベントと併せてエアバッグECU50aに固有のイベントを検知する。エアバッグECU50aのイベント情報取得部53が検知するイベントは例えば上述した共通のイベントに加えて以下のイベントを含んでもよい。
-衝突事象検知イベント
-エアバッグ展開イベント
-衝突処理完了イベント
-衝突記録開始イベント
-衝突記録完了イベント
固有のイベントとしての衝突事象検知イベントは、例えばエアバッグECU50aが加速度センサ(150,600,610,620,630)のセンサ信号等に基づいて検知される衝撃が、所定の衝撃強度を超えた場合に検知されるイベントである。
エアバッグ展開イベントは、例えばエアバッグECU50aがエアバッグ用スクイブ(500,510,520,530,540,550)を駆動してエアバッグを展開させた場合に検知されるイベントである。
衝突処理完了イベントは、例えば車両の衝突発生後にエアバッグECU50aがエアバッグを展開させる等の所定の処理が完了した場合に検知されるイベントである。
衝突記録開始イベントは、例えば、所定の衝撃強度を検出したことをきっかけに衝突記録を開始した場合に検知されるイベントである。
衝突記録完了イベントは、例えば、上述の衝突記録が完了した場合に検知されるイベントである。
イベント情報取得部53は、車両の製造時又は修理整備作業時においても、これらの固有のイベントを検知し得る。例えばイベント情報取得部53は加速度センサに強い衝撃が与えられたときに衝突事象検知イベントを検知し得る。
またエアバッグECU50aのイベント情報取得部53は、車両の製造時又は修理整備作業時においても、例えばエアバッグECU50aにエアバッグ用スクイブや加速度センサを接続する前にエアバッグECU50aが通電状態になると異常検知イベントを検知する。
またエアバッグECU50aのイベント情報取得部53は、車両の製造時又は修理整備作業時においても、例えば異常検知イベントが検知されてから所定時間経過する前にエアバッグ用スクイブや加速度センサが接続されると異常復帰イベントを検知する。
またエアバッグECU50aのイベント情報取得部53は、車両の製造時又は修理整備作業時においても、例えば異常検知イベントの検知が所定時間継続した場合に故障確定イベントを検知する。
またエアバッグECU50aのイベント情報取得部53は、車両の製造時又は修理整備作業時においても、例えば故障確定イベントが検知された後にエアバッグ用スクイブや加速度センサがエアバッグECU50aに接続されると故障復帰イベントを検知する。
<2-5.自制御装置によるイベント記録要求の送信設定>
図4は所定のイベントを検出した自制御装置としてのエアバッグECU50aによるイベントの記録要求を含むメッセージの送信要否の設定例を示す説明図である。
エアバッグECU50aからボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへのイベントの記録要求を含むメッセージの送信要否の設定は、エアバッグECU50aの処理モードの設定が市場モードの場合と市場モード以外の場合とで異なっている。
エアバッグECU50aの処理モードが市場モードに設定されている場合、エアバッグECU50aは製造時不具合イベントを除くすべてのイベントについてイベントの記録要求を含むメッセージをボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信する。
またエアバッグECU50aの処理モードが市場モードに設定されている場合、エアバッグECU50aは製造時不具合イベントについてはイベントの記録要求を含むメッセージをボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信しない。
一方エアバッグECU50aの処理モードが市場モード以外に設定されている場合、エアバッグECU50aは、例えば製造時不具合イベントについてはイベントの記録要求を含むメッセージをボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信する。
またエアバッグECU50aの処理モードが市場モード以外に設定されている場合、エアバッグECU50aは、例えば製造時不具合イベントを除くイベントについては当該メッセージをボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信しない。
なお図4に示した設定例はあくまでも一例であり、イベントの種類あるいは目的に応じて適宜設定を変更することができる。
<2-6.他の制御装置によるイベント記録要否の設定>
図5はエアバッグECU50aからイベントの記録要求を含むメッセージを受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dによるイベントデータの記録要否の設定例を示す説明図である。
ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dによる不揮発性メモリ160へのイベント記録の要否の設定は、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dの処理モードの設定が市場モードの場合と市場モード以外の場合とよって異なっている。
イベントの記録要求を含むメッセージを受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dは、処理モードが市場モードに設定されている場合、製造時不具合イベントを除くすべてのイベントについて記録要求のメッセージにしたがってイベントデータを不揮発性メモリ160に記録する。
またイベントの記録要求を含むメッセージを受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dは、処理モードが市場モードに設定されている場合、製造時不具合イベントについてはイベントデータを不揮発性メモリ160に記録しない。
一方処理モードが市場モード以外に設定されている場合、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dは、例えば製造時不具合イベントについては記録要求のメッセージにしたがってイベントデータをボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50d内の不揮発性メモリに記録する。
また処理モードが市場モード以外に設定されている場合、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dは、例えば製造時不具合イベントを除くイベントについてはイベントデータをボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50d内の不揮発性メモリに記録しない。
なお図5に示した設定例はあくまでも一例であり、イベントの種類あるいは目的に応じて適宜設定を変更することができる。
ここまで本実施形態に係る車両の制御システム40及びその具体例としてのエアバッグ制御システム1000の構成例を説明した。以下相互に通信可能に接続された制御装置50により実行される各種処理の詳細について、エアバッグ制御システム1000を例に採って説明する。
<3.第1の実施の形態>
第1の実施の形態に係るエアバッグ制御システム1000ではイベントを検知したエアバッグECU50aが処理モードに応じてボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに対するイベントの記録要求を含むメッセージの送信の要否を切り替える。
(3-1.エアバッグECUの動作例)
図6は自制御装置としてのエアバッグECU50aにより実行される一連の処理動作の概略を示すフローチャートである。
(初期診断処理)
まずエアバッグECU50aが初期化されると(ステップS101)、エアバッグECU50aの診断部52は初期診断処理を実行する(ステップS103)。
図7は初期診断の一例としてエアバッグECU50aに接続された外部センサの初期診断処理の一例を示すフローチャートである。外部センサは例えば図3に示したフロント右加速度センサ600、フロント左加速度センサ610、右サイド加速度センサ620及び左サイド加速度センサ630である。
まず診断部52は外部センサの型式を識別するIDデータを受信する(ステップS111)。次いで診断部52は受信したIDが所定値と一致しているか否かを判別する(ステップS113)。所定値は使用する外部センサに対応するIDとしてあらかじめ記憶部57に記憶された値である。
受信したIDが所定値と一致している場合(S113/Yes)、初期診断による故障の検出はないため診断部52はこのまま初期診断処理を終了する。一方受信したIDが所定値と一致していない場合(S113/No)、診断部52は外部センサのIDの不一致故障に該当する故障コード(DTC:Diagnostic Trouble Code)を記憶部57に記録する処理を実行する(ステップS115)。
次いで診断部52は外部センサのIDの不一致故障によるイベント記録要求を発行する(ステップS117)。イベント記録要求はイベント処理部55に対してエアバッグECU50a自身の不揮発性メモリ160にIDの不一致故障によるイベントを記録させるための指示データである。
次いで診断部52は外部センサのIDの不一致故障によるイベント通知要求を発行する(ステップS119)。イベント通知要求はイベント処理部55に対してボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへのイベントの記録要求を含むメッセージを送信させるための指令情報である。
診断部52はIDの不一致故障によるイベント記録要求及びイベント通知要求を発行した後に初期診断処理を終了する。
(通常時診断処理)
図6に戻り、エアバッグECU50aの診断部52は初期診断処理(S103)の終了後に通常時診断処理を実行する(ステップS105)。通常時診断は例えば通信途絶診断又は外部センサ故障診断を含む。
図8は通常時診断の一例としての外部センサ故障診断処理の一例を示すフローチャートである。まずエアバッグECU50aの診断部52は外部センサから検出データを取得する(ステップS121)。次いで診断部52は取得した検出データが正常範囲内か否かを判別する(ステップS123)。検出データの正常範囲は例えばあらかじめ想定される検出範囲として設定されている。
検出データが正常範囲内である場合(S123/Yes)、診断部52は衝突判定制御に用いる外部センサの検出データの基準値を、今回取得した検出データで更新する(ステップS125)。次いで診断部52は外部センサの状態を「正常検知状態」に設定する(ステップS127)。
次いで診断部52は外部センサの状態が今回「故障検知状態」から「正常検知状態」に変化したか否かを判別する(ステップS129)。外部センサの状態が「故障検知状態」から「正常検知状態」に変化していない場合、つまり前回から継続して「正常検知状態」であった場合(S129/No)、診断部52はそのままステップS135に進む。
一方外部センサの状態が今回「故障検知状態」から「正常検知状態」に変化した場合(S129/Yes)、診断部52は外部センサの「正常検知状態」によるイベント記録要求を発行する(ステップS131)。次いで診断部52は外部センサの「正常検知状態」の継続時間を計測するタイマT1を初期化して(ステップS133)、ステップS135に進む。
ステップS135において診断部52は外部センサの「正常検知状態」の継続時間を計測するタイマT1があらかじめ設定した所定時間T1_0を経過したか否かを判別する(ステップS135)。タイマT1が所定時間T1_0を経過していない場合(S135/No)、診断部52はそのまま外部センサ故障診断処理を終了する。一方タイマT1が所定時間T1_0を経過した場合(S135/Yes)、診断部52は外部センサの状態を「正常確定状態」に設定する(ステップS137)。
次いで診断部52は外部センサの状態が今回「故障確定状態」から「正常確定状態」に変化したか否かを判別する(ステップS139)。外部センサの状態が「故障確定状態」から「正常確定状態」に変化していない場合、つまり前回から継続して「正常確定状態」であった場合(S139/No)、診断部52はそのまま外部センサ故障診断処理を終了する。
一方外部センサの状態が今回「故障確定状態」から「正常確定状態」に変化した場合(S139/yes)、診断部52は外部センサの正常確定状態によるイベント記録要求を発行する(ステップS141)。次いで診断部52は外部センサの正常状態復帰に該当する故障コード(DTC)を記憶部57に記録する処理を実行し(ステップS143)、外部センサ故障診断処理を終了する。このとき外部センサの過去の故障記録は残される。
上述のステップS123において検出データが正常範囲外である場合(S123/No)、診断部52は衝突判定制御に用いる外部センサの検出データの基準値をゼロにして更新する(ステップS145)。次いで診断部52は外部センサの状態を「故障検知状態」に設定する(ステップS147)。
次いで診断部52は外部センサの状態が今回「正常検知状態」から「故障検知状態」に変化したか否かを判別する(ステップS149)。外部センサの状態が「正常検知状態」から「故障検知状態」に変化していない場合、つまり前回から継続して「故障検知状態」であった場合(S149/No)、診断部52はそのままステップS155に進む。
一方外部センサの状態が今回「正常検知状態」から「故障検知状態」に変化した場合(S149/Yes)、診断部52は外部センサの「故障検知状態」によるイベント記録要求を発行する(ステップS151)。次いで診断部52は外部センサの「故障検知状態」の継続時間を計測するタイマT2を初期化して(ステップS153)、ステップS155に進む。
ステップS155において診断部52は外部センサの「故障検知状態」の継続時間を計測するタイマT2があらかじめ設定した所定時間T2_0を経過したか否かを判別する(ステップS155)。タイマT2が所定時間T2_0を経過していない場合(S155/No)、診断部52はそのまま外部センサ故障診断処理を終了する。一方タイマT2が所定時間T2_0を経過した場合(S155/Yes)、診断部52は外部センサの状態を「故障確定状態」に設定する(ステップS157)。
次いで診断部52は外部センサの状態が今回「正常確定状態」から「故障確定状態」に変化したか否かを判別する(ステップS159)。外部センサの状態が「正常確定状態」から「故障確定状態」に変化していない場合、つまり前回から継続して「故障確定状態」であった場合(S159/No)、診断部52はそのまま外部センサ故障診断処理を終了する。
一方外部センサの状態が今回「正常確定状態」から「故障確定状態」に変化した場合(S159/yes)、診断部52は外部センサの「故障確定状態」によるイベント記録要求を発行する(ステップS161)。次いで診断部52は外部センサの「故障確定状態」に該当する故障コード(DTC)を記憶部57に記録する処理を実行し(ステップS163)、外部センサ故障診断処理を終了する。
図9は通常時診断の一例としてのメッセージの通信途絶診断処理の一例を示すフローチャートである。まずエアバッグECU50aの診断部52は所定のメッセージの受信があるか否かを判別する(ステップS171)。当該メッセージの受信がある場合(S171/Yes)、診断部52は当該メッセージを取り込んで受信処理を行う(ステップS173)。
次いで診断部52は当該メッセージの途絶状態の継続時間を計測するタイマT3を初期化する(ステップS175)。次いで診断部52は途絶診断状態を「正常状態」に設定する(ステップS177)。次いで診断部52は途絶診断状態が今回「故障状態」から「正常状態」に変化したか否かを判別する(ステップS179)。
途絶診断状態が「故障状態」から「正常状態」に変化していない場合、つまり前回から継続して「正常状態」であった場合(S179/No)、診断部52はそのままメッセージの通信途絶診断処理を終了する。
一方途絶診断状態が今回「故障状態」から「正常状態」に変化した場合(S179/Yes)、診断部52は通信途絶の正常復帰によるイベント記録要求を発行する(ステップS181)。さらに診断部52は通信途絶の正常復帰に該当する故障コード(DTC)を記憶部57に記録する処理を実行し(ステップS183)、メッセージの通信途絶診断処理を終了する。
一方上述のステップS171において当該メッセージの受信がない場合(S171/No)、診断部52は当該メッセージの途絶状態の継続時間を計測するタイマT3があらかじめ設定した所定時間T3_0を経過したか否かを判別する(ステップS185)。
タイマT3が所定時間T3_0を経過していない場合(S185/No)、診断部52はそのままメッセージの通信途絶診断処理を終了する。一方タイマT3が所定時間T3_0を経過した場合(S185/Yes)、診断部52は途絶診断状態を「故障状態」に設定する(ステップS187)。
次いで診断部52は途絶診断状態が今回「正常状態」から「故障状態」に変化したか否かを判別する(ステップS189)。途絶診断状態が「正常状態」から「故障状態」に変化していない場合、つまり前回から継続して「故障状態」であった場合(S189/No)、診断部52はそのままメッセージの通信途絶診断処理を終了する。
一方途絶診断状態が今回「正常状態」から「故障状態」に変化した場合(S189/Yes)、診断部52は通信途絶故障によるイベント記録要求を発行する(ステップS191)。さらに診断部52は通信途絶故障に該当する故障コード(DTC)を記憶部57に記録する処理を実行し(ステップS193)、メッセージの通信途絶診断処理を終了する。
(イベント記録用データ収集処理)
図6に戻り、通常時診断処理(S105)の終了後、エアバッグECU50aのイベント情報取得部53はイベント記録用のデータを収集する処理を行う(ステップS107)。イベント記録用のデータはイベント記録要求が発行された時刻の前後の車両状態やユーザの操作状況等のデータであり、検知したイベントの情報とともに不揮発性メモリ160に記憶される。
図10はイベント記録用データを収集する処理の具体例を示すフローチャートである。まずエアバッグECU50aのイベント情報取得部53はCAN通信線15を介して受信したブレーキペダルの操作情報を記憶部57に記録する(ステップS201)。記憶部57は例えばリングバッファであってよい。
次いでイベント情報取得部53はCAN通信線15を介して受信した舵角情報を記憶部57に記録する(ステップS203)。次いでイベント情報取得部53はCAN通信線15を介して受信したエンジン回転数の情報を記憶部57に記録する(ステップS205)。
次いでイベント情報取得部53はイグニッションスイッチの電圧データを記憶部57に記録する(ステップS207)。次いでイベント情報取得部53はCAN通信線15を介して受信したアクセルペダルの開度情報を記憶部57に記録する(ステップS209)。
次いでイベント情報取得部53はエアバッグECU50aのスリープ状態を記憶部57に記録する(ステップS211)。次いでイベント情報取得部53は車速情報を記憶部57に記録する(ステップS213)。
イベント情報取得部53はこれらの一連の処理を行いイベント記録用のデータの収集処理を繰り返し実行する。なお収集する各種データを記録する順序は上記の例に限られず、適宜入れ替えられてよい。
(イベント通知要求判定及びイベント記録要求メッセージ送信処理)
図6に戻り、イベント記録用データ収集処理(S107)の終了後、エアバッグECU50aのイベント処理部55はイベント通知要求の発行の有無を判定する。またイベント処理部55はイベント通知要求が発行されている場合にはボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに対してイベントの記録要求を含むメッセージを送信する処理を行う(ステップS109)。
図11はステップS109の処理の具体例を示すフローチャートである。まずエアバッグECU50aのイベント処理部55はイベント通知要求の有無を判別する(ステップS221)。イベント通知要求がない場合(S221/No)、イベント処理部55はそのまま処理を終了する。
一方イベント通知要求がある場合(S221/Yes)、イベント処理部55はイベント通知要求が発行されているイベントがボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに記録要求を送信すべき対象に設定されているか否かを判別する(ステップS223)。
イベント通知要求が発行されているイベントがボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに記録要求を送信すべき対象に設定されている場合(S223/Yes)、イベント処理部55はさらに当該イベントのボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへの記録要求の送信が許可されているか否かを判別する(ステップS225)。
上記のステップS223及びS225では、イベント処理部55は例えば図4の設定例にしたがって判別を行う。例えば図4に示した設定例に含まれるイベントであればイベント処理部55はステップS223を「Yes」と判定する。その場合にイベント処理部55は、エアバッグECU50aの処理モードの設定が市場モードか市場モード以外かに応じて自制御装置の欄の市場モード又は市場モード以外の欄を参照して、ステップS225の送信の可否を判定する。
ステップS223又はステップS225のいずれかが「No」と判定された場合(S223/No又はS225/No)、イベント処理部55はそのままステップS231に進み、イベント通知要求処理の完了処理を行い(ステップS231)、処理を終了する。
イベント通知要求が発行されているイベントのボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへの記録要求の送信が許可されている場合(S225/Yes)、イベント処理部55は記録要求を含むボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへ通知するデータをセットする(ステップS227)。
次いでイベント処理部55はCAN通信線15を介してセットしたデータを含むメッセージをボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信し(ステップS229)、イベント通知要求処理の完了処理を行って(ステップS231)、処理を終了する。
(イベント記録処理)
図6に戻り、エアバッグECU50aのイベント処理部55は自身のエアバッグECU50aに備えられた不揮発性メモリ160に検出したイベントの情報を含むイベントデータを記録する(ステップS111)。
図12はエアバッグECU50aのイベント処理部55が自身の不揮発性メモリ160にイベントを記録する処理の具体例を示すフローチャートである。まずイベント処理部55はイベントの記録要求の有無を判別する(ステップS241)。イベント記録要求がない場合(S241/No)、イベント処理部55はそのままイベント記録処理を終了する。
一方イベント記録要求がある場合(S241/Yes)、イベント処理部55はイベント記録要求が発行されているイベントが不揮発性メモリ160に記録すべき対象に設定されているか否かを判別する(ステップS243)。
イベント記録要求の対象となっているイベントが不揮発性メモリ160に記録すべき対象に設定されている場合(S243/Yes)、イベント処理部55はさらに当該イベントの不揮発性メモリ160への記録が許可されているか否かを判別する(ステップS245)。
イベント記録要求が発行されているイベントが不揮発性メモリ160に記録すべき対象に設定されているか否か、及び、不揮発性メモリ160への記録が許可されているか否かは、あらかじめ設定された情報を参照して判定される。
ステップS243又はステップS245のいずれかがNo判定である場合(S243/No又はS245/No)、イベント処理部55はそのままステップS249に進み、イベント記録要求処理の完了処理を行い(ステップS249)、イベント記録処理を終了する。
イベント記録要求が発行されているイベントの不揮発性メモリ160への記録が許可されている場合(S245/Yes)、イベント処理部55は検知したイベントの情報と併せて、収集していたイベント記録用データを不揮発性メモリ160に記録する(ステップS247)。
次いでイベント処理部55はイベント記録要求処理の完了処理を行って(ステップS249)、イベント記録処理を終了する。
(警告ランプ点灯処理)
図6に戻りエアバッグECU50aのイベント処理部55はイベント記録処理(S111)の終了後に警告ランプ201を点灯させる信号を送信する処理を行う(ステップS113)。
図13は警告ランプ点灯処理の具体例を示すフローチャートである。まずイベント処理部55は故障コード(DTC)に故障記録が含まれているか否かを判別する(ステップS251)。故障コード(DTC)に故障記録が含まれている場合(S251/Yes)、イベント処理部55は警告ランプ201の点灯を要求する制御データを含むメッセージを設定する(ステップS253)。
一方故障コード(DTC)に故障記録が含まれていない場合(S251/No)、イベント処理部55は警告ランプ201の消灯を要求する制御データを含むメッセージを設定する(ステップS255)。
ステップS253又はステップS255においてメッセージを設定した後、イベント処理部55は警告ランプ制御データを含むメッセージをCAN通信線15上に送信する(ステップS257)。これによりメーターパネルの表示を制御するメーター制御ECU50dが当該メッセージを受信し、警告ランプ201を点灯又は消灯させる。
その後通常時診断処理を行うステップS105に戻り、ステップS105~ステップS113の各処理を繰り返し実行する。
(3-2.他の制御装置の動作例)
図14はエアバッグ制御システム1000におけるボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dにより実行される処理動作の一例を示すフローチャートである。
本実施形態においてはイベントを検知したエアバッグECU50aは、イベントの記録要求の送信を要するイベントについてのみボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに対して記録要求を含むメッセージを送信する。
したがってボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dは記録要求を含むメッセージを受信した場合、当該ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50d内の記憶部57の不揮発性メモリにイベントデータを書き込む処理を実行する。
具体的にボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dのイベント情報取得部53がイベントの記録要求を含むメッセージを受信すると(ステップS25)、イベント処理部55は受信したイベントデータをエアバッグECU50aの識別子とともに記憶部57の不揮発性メモリに記録する(ステップS27)。
このときイベント処理部55はイベントの記録要求を含むメッセージを受信したときの当該ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dの動作状態を併せて記録してもよい。ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dの動作状態とは例えばボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dの停止状態、初期化状態又は正常駆動状態である。
このようにしてボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dは、イベントを検知したエアバッグECU50aからイベントの記録要求を含むメッセージを受信した場合に、そのときの動作状態と併せてイベントデータを記録する。これによりボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dの記憶部57の不揮発性メモリに目的外のイベントデータが記録されて蓄積されることがない。
したがって市場モード以外のモードで記録されたイベントデータを消去する作業負荷を軽減することができる。一方でボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに記録されたイベントデータは、イベント発生時の状況の詳細な解析に用いることができる。
<3-3.処理モードの設定例>
次に各制御装置50のモード設定部51が処理モードを市場モードに設定する処理の例の幾つかを説明する。
(3-3-1.第1の例)
第1の例は、CAN通信線15を介して接続されたECUテスター等の外部機器を用いて処理モードを市場モードに設定する例である。図15は処理モードの設定処理の第1の例を示すフローチャートである。
例えば図20に示したようにOBDコネクタ91を介してECUテスター90が制御ネットワークに接続され、ユーザの操作入力に基づいて各制御装置50に対して処理モードの設定要求が送信されてもよい。あるいは各制御装置50にECUテスターが直接接続され、ユーザの操作入力に基づいて当該制御装置50に対して処理モードの設定要求が送信されてもよい。
第1の例では、ユーザがECUテスターを用いて各制御装置50の処理モードを市場モードに設定する操作入力を行うと、各制御装置50のモード設定部51は市場モードへの設定要求のメッセージ又は信号を取得する(ステップS51)。
次いでモード設定部51は処理モードを市場モードに設定する(ステップS53)。なお処理モードを市場モードに設定することは、市場モード以外の処理モードの設定を解除することであってもよい。
(3-3-2.第2の例)
第2の例は、自制御装置としてのエアバッグECU50aが検知したイベントに基づいて処理モードを市場モードに設定する例である。図16は処理モードの設定処理の第2の例を示すフローチャートである。
例えば車両の組立工程の最終段階あるいは修理整備作業の完了時にエアバッグECU50aによる故障診断の結果がすべて故障復帰と検知された場合にモード設定部51は処理モードを市場モードに設定してもよい。
第2の例では、イベント情報取得部53が所定のイベントを検知すると(ステップS61)、モード設定部51は検知したイベントが市場モードの設定の要求を伴うイベントであるか否かを判別する(ステップS63)。
例えば検知されたイベントが車両の組立工程の最終段階における故障無しの診断結果である故障無し確定イベントである場合、モード設定部51は当該イベントが市場モードの設定の要求を伴うイベントであると判定する。
検知されたイベントが市場モードの設定の要求を伴うイベントでない場合(S63/No)、モード設定部51は現在の処理モードの設定を維持して処理を終了する。
一方検知されたイベントが市場モードの設定の要求を伴うイベントである場合(S63/Yes)、モード設定部51は現在設定されている処理モードが市場モードと異なっているか否かを判別する(ステップS65)。
現在市場モードに設定されている場合(S65/No)、モード設定部51はそのまま市場モードの設定を維持して処理を終了する。一方現在の処理モードが市場モードでない場合(S65/Yes)、モード設定部51は処理モードを市場モードに設定して処理を終了する(ステップS67)。
このときエアバッグECU50aはボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに対して処理モードを市場モードに設定する要求を含むメッセージを送信してもよい。なお第1の例と同様に、処理モードを市場モードに設定することは、市場モード以外の処理モードの設定を解除することであってもよい。
(3-3-3.第3の例)
第3の例は、各制御装置50が他のいずれかの制御装置50から受信したメッセージに基づいて処理モードを市場モードに設定する例である。図17は処理モードの設定処理の第3の例を示すフローチャートである。
例えば車両の組立工程の最終段階あるいは修理整備作業完了時に制御ネットワーク内のいずれかの制御装置50から送信されるメッセージに市場モードへの設定要求の信号を含ませ、当該メッセージを受信した制御装置50が処理モードを市場モードに設定してもよい。
第3の例は、第2の例におけるエアバッグECU50aが処理モードを市場モードに設定する要求を含むメッセージをボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信した場合にボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dにおいて行われる処理の例であってもよい。
例えばボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dのイベント情報取得部53がエアバッグECU50aからメッセージを受信すると(ステップS71)、モード設定部51は受信したメッセージに市場モードの設定要求が含まれているか否かを判別する(ステップS73)。
受信したメッセージに市場モードの設定要求が含まれていない場合(S73/No)、モード設定部51は現在の処理モードの設定を維持して処理を終了する。一方受信したメッセージに市場モードの設定要求が含まれている場合(S73/Yes)、モード設定部51は現在設定されている処理モードが市場モードと異なっているか否かを判別する(ステップS75)。
現在市場モードに設定されている場合(S75/No)、モード設定部51はそのまま市場モードの設定を維持して処理を終了する。一方現在の処理モードが市場モードでない場合(S75/Yes)、モード設定部51は処理モードを市場モードに設定して処理を終了する(ステップS77)。
なお第1の例と同様に、処理モードを市場モードに設定することは、市場モード以外の処理モードの設定を解除することであってもよい。
なおモード設定部51による市場モードの設定処理は、上記の第1の例~第3の例に限られない。またモード設定部51は、上記の第1の例~第3の例その他の例を組み合わせて市場モードの設定処理を行ってもよい。
<3-4.効果>
以上説明したように本実施形態に係るエアバッグ制御システム1000では、エアバッグECU50aがイベントを検知した際に、処理モードが市場モードに設定されているか否かによってボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに対する少なくとも一部のイベントの記録要求の送信の要否を切り替える。
具体的にエアバッグECU50aは、処理モードが市場モードに設定されている場合にはイベントデータの記録要求をボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信する。一方エアバッグECU50aは、処理モードが市場モードに設定されていない場合には少なくとも一部のイベントの記録要求をボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信しない。
これにより車両の製造段階及び修理整備作業時におけるボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへの目的外のイベントデータの記録が省略され、車両の出荷時あるいは納車時におけるイベントデータの記録を消去する作業負荷を軽減することができる。
図18は本実施形態に係るボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dによるイベントデータの記録期間について説明するための図である。本実施形態に係るボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dの場合、車両の製造段階においてはエアバッグECU50aがイベントを検知しても一部又は全部のイベントについては記録要求を含むメッセージの送信が行われない。
このためボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dには目的外のイベントデータの記録が蓄積されることがない。これにより車両の製造が完了して車両を出荷する際に、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに蓄積された目的外のイベントデータの消去作業が不要となる。
車両の整備あるいは修理整備作業時においても同様に、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに目的外のイベントデータの記録が蓄積されることがなく、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに蓄積された目的外のイベントデータの消去作業が不要となる。したがってイベントデータの消去作業に要する時間が省略され、製造コストあるいは修理コストを低減することができる。
<<4.第2の実施の形態>>
第2の実施の形態に係るエアバッグ制御システム1000ではイベントを検知したエアバッグECU50aが処理モードに拘わらずイベントの記録要求をボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに送信し、当該記録要求を受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dが処理モードに応じてイベントデータの記録の要否を切り替える。
<4-1.エアバッグECUの処理動作>
本実施形態に係るエアバッグ制御システム1000において、自制御装置としてのエアバッグECU50aは基本的には図6に示すフローチャートにしたがって処理を実行する。ただし、ステップS109において、イベント通知要求の有無の判定を行うことなく、ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに対してイベントの記録要求を含むメッセージを送信する。
<4-2.他の制御装置の処理動作>
図19は本実施形態に係るエアバッグ制御システム1000におけるボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dにより実行される処理動作の一例を示すフローチャートである。
ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dのイベント情報取得部53がエアバッグECU50aからイベントの記録要求を含むメッセージを受信すると(ステップS41)、イベント処理部55は処理モードが市場モードに設定されているか否かを判別する(ステップS43)。
処理モードが市場モードに設定されている場合(S43/Yes)、イベント処理部55はボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50d内の記憶部57の不揮発性メモリにエアバッグECU50aの識別子とともにイベントデータを記録して処理を終了する(ステップS47)。このときイベント処理部55はイベントを検知したときのボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dの動作状態を併せて記録してもよい。
一方処理モードが市場モードに設定されていない場合(S43/No)、イベント処理部55は記録要求を受信したイベントのイベントデータを記録する必要があるか否かを判別する(ステップS45)。
上記のステップS43及びS45では、イベント処理部55は例えば図5の設定例にしたがって判別を行う。その場合にイベント処理部55は、処理モードの設定が市場モードか市場モード以外かに応じて市場モード又は市場モード以外の欄を参照して、ステップS45の記録の要否を判定する。
ステップS45において、イベント処理部55は記録要求を受信したイベントのイベントデータを記録する必要があると判定した場合(S45/Yes)、上述のステップS47の処理にしたがってボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50d内の記憶部57の不揮発性メモリにエアバッグECU50aの識別子とともにイベントデータを記録する(ステップS47)。
一方ステップS45において、イベント処理部55は記録要求を受信したイベントのイベントデータを記録する必要がないと判定した場合(S45/No)、イベントデータを記録することなくそのままイベント処理を終了させる。したがって市場モード以外のモードで記録されたイベントデータを消去する作業負荷を軽減することができる。
なお各制御装置50の処理モードを市場モードに設定する方法は第1の実施の形態で説明した例を適宜採用することができる。
<4-3.効果>
以上説明したように本実施形態に係るエアバッグ制御システム1000では、イベントの記録要求を含むメッセージ受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dが、処理モードが市場モードに設定されているか否かによって少なくとも一部のイベントデータの記録の要否を切り替える。
具体的にイベントの記録要求を含むメッセージ受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dは、処理モードが市場モードに設定されている場合には記録要求を受信したイベントのイベントデータを記憶部57に記録する。一方ボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dは、処理モードが市場モードに設定されていない場合には少なくとも一部のイベントデータの記録を行わない。
これにより第1の実施の形態の場合と同様に車両の製造段階及び修理整備作業時におけるボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへの目的外のイベントデータの記録が省略され、車両の出荷時あるいは納車時におけるイベントデータの記録を消去する作業負荷を軽減することができる。したがってイベントデータの記録の消去作業による製造時間あるいは修理整備作業時間の増大及びコストの増加を抑制することができる。
また本実施形態に係るエアバッグ制御システム1000においても、検知したイベントの内容に応じてボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dによるイベントデータの記録の要否が設定されている。
<<5.第3の実施の形態>>
第3の実施の形態に係るエアバッグ制御システム1000ではイベントを検知したエアバッグECU50aが処理モードに応じてボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dに対する記録要求を含むメッセージの送信の要否を切り替える。
また本実施形態に係るエアバッグ制御システム1000では記録要求を含むメッセージを受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dが処理モードに応じてイベントデータの記録の要否を切り替える。
つまり本実施形態に係るエアバッグ制御システム1000ではイベントを検知したエアバッグECU50a及びイベントの記録要求を含むメッセージを受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dが、それぞれ処理モードが市場モードに設定されているか否かに応じてイベントデータを記録させるための処理を切り替える。
エアバッグECU50aによる処理動作は図6に示した第1の実施の形態に係るエアバッグECU50aによる処理動作のフローチャートにしたがって実行することができる。またボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dによる処理動作は図19に示した第2の実施の形態に係るボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dによる処理動作のフローチャートにしたがって実行することができる。
本実施形態においては制御装置50の処理モードが市場モードに設定されていない場合に、エアバッグECU50a側でイベントの記録要求を送信するか否かを決定するか、あるいはボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50d側でイベントデータを記録するか否かを決定するかを、イベントの内容に応じて適宜設定することができる。
本実施形態に係るエアバッグ制御システム1000によっても、第1の実施の形態又は第2の実施の形態に係るエアバッグ制御システム1000と同様に車両の製造段階及び修理整備作業時におけるボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへの目的外のイベントデータの記録が省略される。これにより車両の出荷時あるいは納車時におけるイベントデータの記録を消去する作業負荷を軽減することができる。したがってイベントデータの記録の消去作業による製造時間あるいは修理整備作業時間の増大及びコストの増加を抑制することができる。
また本実施形態に係るエアバッグ制御システム1000ではエアバッグECU50a側で送信の要否を決定するか、あるいはイベントの記録要求を含むメッセージを受信したボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50d側で記録の要否を決定するかを、イベントの内容に応じて設定することができる。
これによりエアバッグECU50aのみにイベントの記録を残したい場合やボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dへの記録要求の送信を行いたい場合等にはボディ制御ECU50b、ライト制御ECU50c及びメーター制御ECU50dにイベントデータの記録の要否を委ねることができる。したがってイベントの内容に応じて最低限必要な処理を実行させた上で、イベントデータの記録の要否を切り替えることができる。
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
本発明は上記を背景になされたものであり、ある制御装置が検知した目的外のイベントの情報を他の制御装置に記録させないようにして当該イベントの情報の記録の消去作業の負荷を軽減可能な車載システム及び制御装置を提供することを目的とする。