JP2006193016A - 自動車用制御装置 - Google Patents

Abstract

【課題】 複数の端末ＥＣＵが、共通の制御判定事項に関して、その判定結果を得る上で互いに整合しない情報収集状態におかれている場合でも、円滑で内部矛盾のない制御を実現できる自動車用制御装置を提供する。
【解決手段】 自動車制御装置は、各々ＣＰＵを有した複数の制御ユニットが車内ネットワークを形成するネットワークバスを介して接続された構造を有する。複数の制御ユニットは、予め定められた制御判定事項に関し、その判定に使用する外部からの入力情報であって、判定に互いに独立して使用可能な原入力情報を取得する端末ユニットと、同一の制御判定事項に関して互いに競合する、内容の異なる複数の原入力情報を複数の端末ユニットから車内ネットワークを介して二次入力情報とし受信し、受信したそれら二次入力情報に基づいて、制御判定事項に係る調停判定結果情報の内容を定め、これを車内ネットワーク上に送出する管理ユニットとを備える。
【選択図】 図５

Description

この発明は自動車用制御装置に関する。

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

近年、自動車に搭載されるＥＣＵは、自動車の多機能化及び高性能化に対応して、１台の自動車への搭載個数も増えてきている。また、このような流れを受けて、複数の端末ＥＣＵを車内ネットワークで接続するとともに、これらを統括管理する管理ＥＣＵを設けた車両統合制御装置も提案されている（特許文献１，２）。個々の端末ＥＣＵには、統合制御のための原入力情報となる種々のセンサやスイッチ類が接続され、それら端末ＥＣＵを介して集められた検知情報をベースとして、管理ＥＣＵが制御全体の流れを司ることとなる。

ネットワーク接続された個々の端末ＥＣＵは、自身に接続されたセンサやスイッチから検知情報を受け取ったり、あるいはネットワークを介した通信により他のＥＣＵから情報を取得したりするだけでなく、それらの情報を独自に総合して、例えば自動車の状態や、自動車と人との位置関係などを判定・把握する処理も行なっている。その判定結果情報は管理ＥＣＵに送信され、より上位の判定・制御に使用される。

しかし、ネットワークに接続される端末ＥＣＵの数が増えてくると、同じ処理や判定が異なる端末ＥＣＵで独立して実施される状況が生ずる。管理ＥＣＵ側では、同じ判定事項に使用する情報であるにも拘わらず、受信する処理結果や判定結果が、送信元となる端末ＥＣＵに応じて異なる不整合を招くことにつながる。

本発明の課題は、複数の端末ＥＣＵが、共通の制御判定事項に関して、その判定結果を得る上で互いに整合しない情報収集状態におかれている場合でも、制御装置全体としては円滑で内部矛盾のない制御を実現できる自動車用制御装置を提供することにある。

課題を解決するための手段及び発明の効果

上記の課題を解決するために、本発明の自動車用制御装置は、
各々ＣＰＵを有した複数の制御ユニットが車内ネットワークを介して接続された構造を有するとともに、複数の制御ユニットとして、
予め定められた制御判定事項に関し、その判定に使用する外部からの入力情報であって、判定に互いに独立して使用可能な原入力情報を取得する端末ユニットと、
原入力情報に基づいて各端末ユニットが出力する情報であって、同一の制御判定事項に関して互いに競合しうる内容の異なる複数の二次入力情報を、車内ネットワークを介して受信し、受信したそれら二次入力情報に基づいて、制御判定事項に係る調停判定結果情報の内容を定め、これを車内ネットワーク上に送出する管理ユニットと、を備えたことを特徴とする。

「互いに独立して使用可能な原入力情報」とは、ある共通の制御判定事項について判定を行なう方法として、種別の異なる原入力情報を用いた複数の判定方法が独立に成立しうる場合、それらの原入力情報はその制御判定事項について「互いに独立して使用可能である」という。

予め定められた制御判定事項について複数の端末ユニットが、その判定に互いに独立して使用可能な原入力情報を取得しつつ、各々その原入力情報を用いた判定処理についても独立に実施してしまうと、同じ制御判定事項であるにも拘わらず、端末ユニットによって判定結果が異なる状況が起こり、誤判定や制御不安定などを招くことにつながる。だからといって、当該の制御判定事項に使用する原入力情報の種別を減ずることは、判定精度の低下につながる。

そこで本発明では、車内ネットワーク上に管理ユニットを新たに設け、上記のように、同一の制御判定事項に関して互いに競合する、内容の異なる複数の原入力情報を取得する複数の端末ユニットについては、上記管理ユニットが車内ネットワークを介して個々の端末ユニットが取得した原入力情報を二次入力情報として受信し、受信したそれら二次入力情報に基づいて、制御判定事項に係る調停判定結果情報の内容を定め、車内ネットワーク上に送出するようにした。つまり、個々の端末ユニットで原入力情報を用いた判定処理を個別に行なうのではなく、管理ユニットが一旦それらの原入力情報を二次入力情報として集め、その集めた二次入力情報を用いた総合的な判断処理により調停判定結果情報を別途作成するようにしたので、車内ネットワーク上において個々の制御判定事項に対し、常に統一的な判定結果（つまり、全ての端末ユニットで共有できる判定結果である）が得られるようになり、制御装置全体として円滑で内部矛盾のない制御を実現できるようになる。

上記本発明によると、同じ制御判定事項について異なる原入力情報に基づく判定処理を個別に行なった場合の不整合を、管理ユニットによる一元的な判定方式の採用により解消できる利点がある。しかし、管理ユニットが何らかの要因で機能しなくなった場合には、その一元化された調停判定結果情報の出力が不能となり、制御に重大な支障を来たす可能性がある。そこで、このような場合のフェールセーフを考慮して、次のような方式を採用することが望ましい。すなわち、端末ユニットのいずれかを、管理ユニットによる調停判定結果情報の送出が不能となった場合に、自身が受信する原入力情報に基づいて非常用調停判定結果情報の内容を定め、これを管理ユニットに代わって車内ネットワーク上に代行送出する代行管理ユニットの機能を有してなるものとして構成する。

本発明においては、最終的な調停判定結果情報の送出は管理ユニットが行なうにしても、複数の端末ユニットは、制御判定に使用可能な原入力情報を独立に取得するのだから、それぞれ自立的に制御判定を行なうためのポテンシャルは有している。上記構成によれば、そのポテンシャルを管理ユニットが不調となった場合のフェールセーフ処理に活用できる利点があり、異常発生時にもどれかの端末ユニットが代行管理ユニットとして判定を続行できるので、制御に重大な支障が及ぶ最悪の事態を効果的に回避できる。

一方、管理ユニットに異常が発生した場合のフェールセーフ処理は、以下のように、端末ユニットは別のバックアップ管理ユニットを設けることで行なってもよい。すなわち、この構成では、車内ネットワークには、管理ユニットによる調停判定結果情報の送出が不能となった場合に、各端末ユニットからの二次入力情報を代行受信し、受信したそれら二次入力情報に基づいて非常用調停判定結果情報の内容を定め、車内ネットワーク上に送出するバックアップ管理ユニットが設けられる。端末ユニットのどれかを代行管理ユニットとして機能させる上記の構成では、非常用調停判定結果情報の内容決定に際して、その代行管理ユニットが取得する原入力情報しか参照できず、該非常用調停判定結果情報の信頼性や多様性には幾分欠ける難点もある。しかし、バックアップ管理ユニットを別途設ける構成では、二次入力情報の収集は必要となるものの、生成される非常用調停判定結果情報の信頼性や多様性は大幅に改善される。

（実施の形態１）
図１は、本発明の自動車制御装置の全体構成を概念的に示すものである。自動車制御装置５０は、自動車上の種々の被制御要素の電気的動作を制御するために、各々ＣＰＵを有した複数の制御ユニット（ＥＣＵ）１００，１０１，１０２が車内ネットワークを形成するネットワークバスを介して接続された構造を有する。複数の制御ユニットは、予め定められた制御判定事項に関し、その判定に使用する外部からの入力情報であって、判定に互いに独立して使用可能な原入力情報を取得する端末ユニット１００，１０１と、同一の制御判定事項に関して互いに競合する、内容の異なる複数の原入力情報を複数の端末ユニット１００，１０１から車内ネットワークを介して二次入力情報とし受信し、受信したそれら二次入力情報に基づいて、制御判定事項に係る調停判定結果情報の内容を定め、これを車内ネットワーク上に送出する管理ユニット（ＥＣＵ）１０２とを備える。

図２は、端末ユニット１００の電気的な構成図である（図３に示すように、端末ユニット１０１も、後述の代行情報管理アプリケーションの実行機能が付加されている点を除き、図２と同じ構成である）。この端末ユニット１００のハードウェア構成は、一般的なＥＣＵと同一のものであり、ＣＰＵ１、ＲＡＭ２、ＲＯＭ３及び入出力部（Ｉ／Ｏポート）４がバス接続されたマイクロプロセッサからなる。ＲＯＭ３には情報取得・出力アプリケーションが格納されている。該アプリケーションは、ＲＡＭ２のアプリケーション実行メモリ２ａを実行エリアとしてＣＰＵ１により実行されるものである。原入力情報(A)は、その入出力部４に接続された種々のスイッチ群１１あるいはセンサ群１２からの入力信号を、上記の情報取得・出力アプリケーションの実行により取り込んで作成され、情報取得出力用メモリ２ｂ内に記憶されるとともに、管理ユニット１０２への二次入力情報(B)としてネットワークバスに出力する。

なお、二次入力情報(B)は、管理ユニット１０２における以降の判定処理に使用する上でより好都合な情報形態となるように、各端末ユニット１００にて原入力情報(A)を加工して作成した情報であってもよい。従って、原入力情報(A)と二次入力情報(B)とは情報形態が必ずしも等価であるとは限らない。例えば、原入力情報(A)が車速センサからの入力信号である場合、その情報形態は断続的なエンコーダパルス信号であるが、これを端末ユニット１００においてカウンタ計測することにより、車速情報を単位時間当たりのパルス数として算出し、これを二次入力情報(B)として出力することが好都合である。この場合、車速センサからの入力信号と、最終的に出力される車速情報とが情報形態として等価でないことは明らかである。また、別の例としては、原入力情報(A)が無線キー（携帯器）からの認証用のＩＤ情報であった場合、二次入力情報(B)はそのＩＤ情報に対する認証結果情報とすることができるが、この場合も、原入力情報(A)と二次入力情報(B)とは明らかに等価ではない。

図４は、管理ユニット１０２の電気的な構成図である。管理ユニット１０２のハードウェア構成も、一般的なＥＣＵと同一のものであり、ＣＰＵ１、ＲＡＭ２、ＲＯＭ３及び入出力部（Ｉ／Ｏポート）４がバス接続されたマイクロプロセッサからなる。ＲＯＭ３には情報管理アプリケーションが格納されている。該アプリケーションは、ＲＡＭ２のアプリケーション実行メモリ２ａを実行エリアとしてＣＰＵ１により実行されるものである。該情報管理アプリケーションの実行により、各端末ユニット１００からの前述の二次入力情報(B)がネットワークバスを介して集められ、これを参照して調停判定結果情報が作成され、対応するメモリ２ｂに記憶される。この調停判定結果情報が読み出され、各端末ユニット１００，１０１への共通の判定結果情報として、ネットワークバス上に出力される。

図１において、予め定められた制御判定事項について複数の端末ユニット１００，１０１は、その判定に互いに独立して使用可能な原入力情報を取得するので、各々その原入力情報を用いて独立に判定処理を実施し、その判定結果をネットワークバス上に送出する方式も想定できる。しかし、このような方式では、同じ制御判定事項について、個々の端末ユニット１００，１０１が送出する判定結果が互いに矛盾することもありえ、誤判定や制御不安定などを招くことにつながる。しかし、上記のように、複数の端末ユニット１００，１０１で上記原入力情報に基づく判定処理を個別に行なうのではなく、それぞれ二次入力情報の形で車内ネットワーク上に送出する一方、管理ユニット１０２が一旦それらの原入力情報を二次入力情報として集め、その集めた二次入力情報を用いた総合的な判断処理により調停判定結果情報を別途作成するようにすることで、上記の不具合を効果的に解消することができる。すなわち、それら二次入力情報の示す判定の方向性に競合（あるいは不整合）が存在している場合でも、管理ユニット１０２でその調停を行なうことができ、車内ネットワーク上で一元化された（つまり、各端末ユニット１００，１０１に共通の）調停判定結果情報として出力できる。その結果、制御装置全体として、円滑で内部矛盾のない制御を実現できるようになる。

単純な判定でよい場合は、制御判定事項に係る判定結果は、例えば予め定められた被判定状態が成立するか否かを二者択一的に示すべきものとすることができる。この場合、複数の二次入力情報は、それぞれ、被判定状態の成立に関して肯定を支持する肯定支持内容と、同じく否定を支持する否定支持内容とのいずれかの内容を取るものとすることができる。調停判定結果情報は、それら二次入力情報の全てが肯定支持内容となっている場合にのみ被判定状態の成立に関して肯定判定内容となり、その余の場合には否定判定内容となるように定めることができる。この方法は、アルゴリズムも単純で管理ユニット１０２の処理負担も少なく、また、採用する二次入力情報の数に応じて判定精度を高めることができる利点がある。

例えば、上記の構成において被判定状態は、自動車が走行中の状態として定めることができる。この場合の具体例を図５に示している。原入力情報として、車速センサ１２からの車速検知情報(1)'と、イグニッションスイッチ１１の付勢情報(2)'とが使用されている。これらは各々対応する端末ユニット１００，１０１（本実施形態では、端末ユニット１０１はメータＥＣＵ１０１であり、端末ユニット１００はボデーＥＣＵ１００である）に入力されるとともに、二次入力情報である車速情報(1)及びイグニッションスイッチ付勢情報(2)としてネットワークバス上に出力されている。

管理ユニット１０２は、イグニッションスイッチ１１が付勢され（つまり、付勢情報(2)がイグニッションＯＮを示しているとき）、かつ、車速情報(1)が予め定められた値以上の車速を示している場合に、判定情報として走行中情報を送出する。図７は、管理ユニット１０２におけるその処理の流れを示している（情報調停管理処理）。Ｓ１１でイグニッションスイッチ付勢情報(2)を受信し、Ｓ１２で車速情報(1)を取得する。Ｓ１３では、それら二次入力情報(1)(2)の送信元となる端末ユニット１０１，１００に、情報受領のアクノリッジ信号を返す（このアクノリッジ信号の途絶により、管理ユニット１０２の異常を検出することができる）。Ｓ１４では、車速情報(1)が示す車速ＶＲが規定値Ｖ０を超えているかどうかを比較判定し、超えていれば「走行中」を示す情報をネットワークバスに送出する（Ｓ１５）。なお、Ｓ１１でイグニッションＯＦＦと判定された場合や、Ｓ１４で車速ＶＲが規定値Ｖ０未満である場合は、いずれも「非走行中」を示す情報を送出する（「非走行中」を示す情報は敢えて送出しない構成でもよい）。例えば、ドアの制御を司る端末ユニット１００（ドアＥＣＵ）は、「走行中」の情報を受け取ることでドアロックユニット５０に対し、ドアロックを施錠状態とする制御指令を行なう。

上記の構成では、車速情報(1)を取得する端末ユニット１００，１０１は、その車速情報(1)のみを原入力情報と用いて、例えば一定速度以上の車速が検出された場合には走行中と判定することが可能であり、イグニッションスイッチ１１の付勢情報(2)'を取得する端末ユニット１００，１０１が、その付勢情報(2)のみを原入力情報として用いて、例えばイグニッションスイッチ１１の付勢が検出された場合には走行中と判定するように構成することが可能である。しかし、これら端末ユニット１００，１０１が個別に「走行中」の判定結果を出力したのでは、例えば上記予め定められた値以下で低速走行している場合には、２つの端末ユニット１００，１０１の走行中に係る判定結果が食い違うことになる。しかし、上記のように、管理ユニット１０２がこれら２つの情報を総合して走行中に係る判定を行ない、車内ネットワーク上に出力することで、このような食い違いは効果的に解消される。

上記の方式では、同じ制御判定事項について異なる原入力情報に基づく判定処理を個別に行なった場合の不整合を、管理ユニット１０２による一元的な判定方式の採用により解消できる利点がある。しかし、管理ユニット１０２が何らかの要因で機能しなくなった場合には、その一元化された調停判定結果情報の出力が不能となり、制御に重大な支障を来たす可能性がある。そこで、このような場合のそのフェールセーフを考慮して、次のような方式を採用することができる。すなわち、図１において、端末ユニット１００，１０１のいずれかを、管理ユニット１０２による調停判定結果情報の送出が不能となった場合に、自身が受信する原入力情報に基づいて非常用調停判定結果情報の内容を定め、これを管理ユニット１０２に代わって車内ネットワーク上に代行送出する代行管理ユニット１０１の機能を有してなるものとして構成する。

最終的な調停判定結果情報の送出は管理ユニット１０２が行なうにしても、複数の端末ユニット１００，１０１は、制御判定に使用可能な原入力情報を独立に取得するのだから、それぞれ自立的に制御判定を行なうためのポテンシャルは有している。上記構成によれば、そのポテンシャルを管理ユニット１０２が不調となった場合のフェールセーフ処理に活用できる利点があり、異常発生時にもどれかの端末ユニット１０１が代行管理ユニット１０１として判定を続行できるので、制御に重大な支障が及ぶ最悪の事態を効果的に回避できる。

図５の構成に、上記態様のフェールセーフ機能を追加した場合の構成例を図６に示す。すなわち、代行管理ユニット１０１の機能を有してなる端末ユニット１０１は、ここでは車速センサ１２が接続された端末ユニット１０１（メータＥＣＵ）とされている。図３は、その端末ユニット１０１のブロック図であり、ＲＯＭ３には前述の情報出力アプリケーションの他に代行情報管理アプリケーションが搭載され、管理ユニット１０２に異常発生した場合に、ＲＡＭ２の対応する実行メモリ２ｄ上にて実行される。

端末ユニット１０１は該車速センサ１２からの車速検知情報が、予め定められた値以上の車速を示している場合に、非常用調停判定結果情報として走行中情報(3)'を送出するものとして構成できる。この方式によれば、管理ユニット１０２が不調となった場合も、車速センサ１２が接続された端末ユニット１００，１０１が、車速の情報に基づいて直ちに走行中情報を生成でき、フェールセーフ処理に迅速に移行することができる。

図８は、この場合の端末ユニット１０１（メータＥＣＵ）の処理の流れを示している。この端末ユニット１０１は、常時は二次入力情報として車速情報ＶＲを管理ユニット１０２に向けて送信している。管理ユニット１０２が正常であれば、前述のごとく、車速情報ＶＲを受け取って端末ユニット１０１にアクノリッジ信号を返す。Ｓ２４では、そのアクノリッジ信号を検出する。アクノリッジ信号が返ってきていれば、そのサイクルでの処理は終了となる。しかし、もしアクノリッジ信号がない場合は、Ｓ２４で車速情報ＶＲをリトライ送信して再度管理ユニット１０２からの返信を待つ。それでもなおアクノリッジ信号が返らない場合は管理ユニット１０２に異常が発生したと判断し、Ｓ２５以下のフェールセーフ処理に移る。Ｓ２５では車速情報をリードし、Ｓ２６で車速情報が示す車速ＶＲが規定値Ｖ０を超えているかどうかを比較判定し、超えていれば、Ｓ２７で走行中情報を非常用調停判定結果情報として代行送信する。他方、超えていなければ、Ｓ２８に進んで非走行中情報を非常用調停判定結果情報として代行送信する。

（実施の形態２）
本発明のより進んだ実施形態として、次のような態様も可能である。すなわち、制御判定事項に係る被判定状態として、互いに異なる３つ以上のものが定められ、調停判定結果情報は、３つ以上の二次入力情報の組み合わせに基づいて、それら被判定状態のいずれが成立しているかを示すものとなるように、その内容が定められる。この態様によると、同じ制御判定事項に使用されつつも、互いに種別の異なる二次入力情報が複数使用される点に鑑み、その３つ以上の組み合わせに基づいて、３つ以上の被判定状態を互いに識別する形で、より多様な制御判定を行なうことが可能となる。

図９は、被判定状態として、自動車に対する搭乗者の乗降状態を、当該搭乗者の無線キー１５の携帯状況と関連付けて３つ以上に細分化する形で定めることができる。調停判定結果情報(4)は、搭乗者が所持する無線キー１５（具体的には、車側との認証ＩＤ照合に基づく個人認証機能を有した携帯型無線器）との通信に基づく該搭乗者の認証結果情報(1)と、自動車の座席に装着された着座検知部１３による着座検知情報(2)と、自動車のドアに設けられた開閉検知部１４によるドア開閉検知情報(3)とに基づいて、それら乗降状態のいずれが成立しているかを示すものとしてその出力内容が定められる。

従来は、着座検知部１３による乗車中判定と、無線キー１５（携帯器）によるＩＤ認証／ドア開閉による乗車中判定とが個別に行なわれており、いずれも、よりどころとする入力情報の数が少ないために、自動車に人が乗っているかどうかのみを単純に判定するに留まっていた。しかし、これらを互いに組み合わせることにより、搭乗者が無線キー１５を持った状態で車に乗り込んだのか、あるいは無線キー１５を持たずに車に乗り込んだのか、さらには、その無線キー１５を車中に置き去りにして車を降りたのか、無線キー１５を持って降りたのかなど、無線キー１５の携帯状況との組み合わせにより、より多様な乗降判定が可能となる。例えば、後者の２つのに状態が識別可能になると、無線キー１５を車中に置き去りにして車を降りた場合はドアロックを禁止して無線キー１５の閉じ込みを防止する一方、通常の乗車中判定のみでは困難だった、より高度な制御要求にも対応できるようになる。

以下、図９及び図１０に基づいて、より詳しく説明する。まず、図９において、無線キー１５は認証用ＩＤを自動車側の受信器１６に向けて無線送信するものとされている。この認証用ＩＤは、自動車側でマスターＩＤと照合され、その一致・不一致により自動車のユーザを認証するために使用される。自動車側では、その認証結果を受けてドアロックを解除したり、あるいはエンジン始動したりする、いわゆるスマートエントリー／スタート方式が構築され、前述の受信器１６は、その制御を司る端末ユニット１００（スマートＥＣＵ）に接続されている。受信器１６からの原入力情報は、無線キー１５からの認証用ＩＤであり、端末ユニット１００（スマートＥＣＵ）は、これを受けて認証照合処理を行ない、その結果である認証結果情報(1)を二次入力情報として出力する。他方、着座検知部をなす着座スイッチ１３は、本来はエアバッグ動作の制御に使用されるもので（非着座時にはエアバッグを動作させない）、端末ユニット１０１（エアバッグＥＣＵ）に接続されている。端末ユニット１０１（エアバッグＥＣＵ）は、そのスイッチの付勢情報(2)が着座検知情報すなわち二次入力情報として出力する。また、ドア開閉検知部はドアカーテシスイッチ１４であり、端末ユニット１０１（ドアＥＣＵ）に接続されている。

図１０は、管理ユニット１０２における処理の流れを示している（情報調停管理処理）。Ｓ５１、Ｓ５２及びＳ５３で、着座スイッチ１３の付勢情報（着座検知情報）、無線キー１５との通信によるＩＤ認証結果情報及びドアカーテシスイッチ１４の付勢情報（ドア開閉検知情報）をそれぞれリードする。次に、Ｓ５４で着座スイッチの付勢情報の内容を確認し、着座が検知されていればＳ５５に進んで第一のテーブルにより、着座が検知されていなければＳ５６に進んで第二のテーブルにより、それぞれ出力すべき乗降状態情報を検索する。上記第一及び第二のテーブル（乗降状態情報テーブル）は、図４のＲＯＭ３に搭載され、ＲＡＭ２上の実行メモリにロードされて検索処理に供される。

第一のテーブルは、着座検知状態なので基本的には乗車中を示す情報が記憶されているが、ドアカーテシスイッチの付勢状態とＩＤ照合結果との組み合わせに応じて、出力すべき情報が細分化されている。これらの情報の１つ１つは、全て固有の被判定状態を表している。具体的には、ドアカーテシスイッチがＯＦＦの場合（ドア開）、ＩＤ照合結果の内容によらず、被判定状態は、「自動車に乗り込んだ人が下車中」に設定されている。また、ドアカーテシスイッチがＯＮの場合（ドア閉）、ＩＤ照合結果が受理ならば、被判定状態は、「キーを持って乗車」に設定されている。他方、ＩＤ照合結果が棄却又はＩＤ非受信の場合は、被判定状態は、「キーを持たずに乗車」に設定されている。

第二のテーブルは、着座非検知状態なので基本的には非乗車を示す情報が記憶されているが、ここでもドアカーテシスイッチの付勢状態とＩＤ照合結果との組み合わせに応じて、出力すべき情報が細分化され、これらの情報の１つ１つが、固有の被判定状態を表す。具体的には、ドアカーテシスイッチがＯＦＦの場合（ドア開）、ＩＤ照合結果の内容によらず、被判定状態は、「自動車外の人が乗車中」に設定されている。また、ドアカーテシスイッチがＯＮの場合（ドア閉）、ＩＤ照合結果が受理ならば、被判定状態は、「キーを車内において下車」に設定されている。他方、ＩＤ照合結果が棄却又はＩＤ非受信の場合は、被判定状態は、「キーを持って下車」に設定されている。

本実施の形態２でも、実施の形態１と同様に、管理ユニット１０２に異常が発生したときのフェールセーフ処理を考慮することができる。例えば、代行管理ユニット１０１の機能を有してなる端末ユニット１０１を、着座検知部１３が接続された端末ユニット１０１（エアバッグＥＣＵ）とすることができ、該端末ユニット１０１は該着座検知部１３からの着座検知情報(2)が着座状態を示している場合に、非常用調停判定結果情報として乗車中情報を送出するものとして構成できる。この方式によれば、管理ユニット１０２が不調となった場合も、着座検知部１３による着座検知情報(1)に基づいて、乗車中であるかどうかについては直ちに判定することができ、フェールセーフ処理に迅速に移行することができる。

図１１は、この場合の端末ユニット１０１（エアバッグＥＣＵ）の処理の流れを示している。この端末ユニット１０１は、常時は二次入力情報として着座スイッチ付勢情報(2)を管理ユニット１０２に向けて送信している。管理ユニット１０２が正常であれば、前述のごとく、着座スイッチ付勢情報(2)を受け取って端末ユニット１０１にアクノリッジ信号を返す。Ｓ２４では、そのアクノリッジ信号を検出する。アクノリッジ信号が返ってきていれば、そのサイクルでの処理は終了となる。しかし、もしアクノリッジ信号がない場合は、Ｓ２４で着座スイッチ付勢情報(2)をリトライ送信して再度管理ユニット１０２からの返信を待つ。それでもなおアクノリッジ信号が返らない場合は管理ユニット１０２に異常が発生したと判断し、Ｓ２５以下のフェールセーフ処理に移る。Ｓ２５では着座スイッチ付勢情報(2)をリードし、Ｓ２６で着座検知しているかどうかを判定し、検知していれば、Ｓ２７で乗車中情報を非常用調停判定結果情報として代行送信する。他方、検知していなければ、Ｓ２８に進んで非乗車中情報を非常用調停判定結果情報として代行送信する。このように、フェースセーフ処理時に出力される代行管理ユニット１０１からの非常用調停判定結果情報は、通常時に管理ユニット１０１から出力される調停判定結果情報よりも、被判定状態の数が減じられ、より簡便な処理となっていることがわかる。

（実施の形態３）
管理ユニット１０２に異常が発生した場合のフェールセーフ処理は、図１に一点鎖線で示すように、端末ユニット１００，１０１は別のバックアップ管理ユニット１０３を設けることで行なってもよい。すなわち、この構成では、車内ネットワークには、管理ユニット１０２による調停判定結果情報の送出が不能となった場合に、各端末ユニット１００，１０１からの二次入力情報を代行受信し、受信したそれら二次入力情報に基づいて非常用調停判定結果情報の内容を定め、車内ネットワーク上に送出するバックアップ管理ユニット１０３が設けられる。

実施の形態１及び２で例示したような、端末ユニット１００，１０１のどれかを代行管理ユニット１０１として機能させる構成では、非常用調停判定結果情報の内容決定に際して、その代行管理ユニット１０１が取得する原入力情報しか参照できず、該非常用調停判定結果情報の信頼性や多様性には幾分欠ける難点もある。しかし、バックアップ管理ユニット１０３を別途設ける構成では、二次入力情報の収集は必要となるものの、生成される非常用調停判定結果情報の信頼性や多様性は大幅に改善される。

この場合、バックアップ管理ユニット１０３は、通常時は管理ユニット１０２の動作を監視するものとし、調停判定結果情報の送出が不能となる異常が管理ユニット１０２に発生したことを自ら検知して、非常用調停判定結果情報の送出の処理を行なうものとして構成できる。これにより、管理ユニット１０２での異常発生を直ちに検出することができ、バックアップ管理ユニット１０３によるフェールセーフ処理にもスムーズかつ迅速に移行することができる。

図４は、バックアップ管理ユニット１０３の電気的な構成図である。バックアップ管理ユニット１０３のハードウェア構成は、管理ユニット１０２のハードウェア構成とほぼ同一のものであり、ＣＰＵ１、ＲＡＭ２、ＲＯＭ３及び入出力部（Ｉ／Ｏポート）４がバス接続されたマイクロプロセッサからなる。ＲＯＭ３にはバックアップ情報管理アプリケーションが格納されている。該アプリケーションは、ＲＡＭ２のアプリケーション実行メモリ２ａを実行エリアとしてＣＰＵ１により実行されるものである。管理ユニット１０２に異常が発生した場合は、該バックアップ情報管理アプリケーションが立ち上がり、各端末ユニット１００からの二次入力情報がネットワークバスを介して集め、これを参照して非常用調停判定結果情報を作成し、対応するメモリ２ｂに記憶するとともに、これを読み出して、各端末ユニット１００，１０１への共通の判定結果情報として、ネットワークバス上に出力する。なお、バックアップ管理ユニット１０３は、図２と同様にスイッチ群１１あるいはセンサ群１２を接続し、かつ、情報取得・出力アプリケーションをＲＯＭ３に搭載し、ＲＡＭ２に取得情報出力用メモリ２ｃを設けることで、常時は端末ユニットとしても機能できるように構成することも可能である。

図１４に、この場合の、バックアップ管理ユニット１０３の処理の流れを示す。Ｓ３１では管理ＥＣＵ１０２の動作状態を確認する。その確認方法は、周知の種々の方法を考えることができるが、例えば、管理ＥＣＵ１０２に一定の時間間隔で確認用信号を出力させ、バックアップ管理ユニット１０３にてその確認用信号を、ネットワークバスを介して受信し、その通信が途絶した場合に異常ありと判断することができる。そして、Ｓ３２で異常ありと判断された場合は、バックアップ情報管理アプリケーションが立ち上がり、Ｓ３３で、各端末ユニット（ＥＣＵ）からの二次入力情報を代行受信し、Ｓ３４で非常用調停判定結果情報を作成し代行送信する。

上記構成では、管理ユニット１０２に異常が発生した場合、バックアップ管理ユニット１０３はあくまでフェールセーフ用であって、管理ユニット１０２が故障修理されるまでのあくまで「つなぎ」として使用されるに過ぎない。また、管理ユニット１０２が正常に機能しないことで（特に、管理ユニット１０２がネットワークの管理制御も司っている場合など）、ネットワーク全体の動作が不安定になることもあり、動作代行するバックアップ管理ユニット１０３の処理負担もできるだけ軽減しておくほうが、フェールセーフ効果を高める観点において望ましい。そのためには、バックアップ管理ユニット１０３が作成する非常用調停判定結果情報は、正常時に管理ユニット１０２が送出する調停判定結果情報よりも情報量が減じられたものとしておくとことが効果的である。

図１３にその一例を示す。この構成は、端末ユニット（メータＥＣＵ）１００には車速センサのほか、フューエルセンサが接続されている。また、端末ユニット（ボデーＥＣＵ）１００には、イグニッションスイッチのほか、その電圧モニタ端子にバッテリーが接続され、さらに、ヨーレートやステアリングの旋回角度などを検出するためのジャイロセンサ、タイヤ空気圧センサ、及びカーナビゲーションシステム（ジャイロセンサからの角速度情報が地図上の走行経路トレース処理に使用される）などが接続されている。また、端末ユニット（ドアＥＣＵ）１００には、ドアロック機構のほか、ドア開閉検知部をなすドアカーテシスイッチも接続されている。管理ユニット１０２が異常の場合、各端末ユニット１００に入力される上記各センサ／スイッチ類からの原入力情報に基づく二次入力情報(1)(2)は、バックアップ管理ユニット１０３に代行受信され、そこで、図５と同様に走行中情報(3)'が作成され送出される。

この場合、非常用調停判定結果情報は、正常時に管理ユニット１０２が送出する調停判定結果情報の内容から、自動車の走行／停止、ステアリング及び乗降を司るために予め必須と定められた走行用必須判定情報を抜粋する形で作成することができる。つまり、管理ユニット１０２の異常が検知された場合、管理ユニット１０２の処理停止により自動車がその異常発生地点で立ち往生してしまう不具合だけは避けねばならない。そして、この場合に予想される制御動作処理の不安定化を考慮すれば、バックアップ管理ユニット１０３には、最小限その修理が可能となる自動車ディーラーや修理工場まで、当該の自動車を自力でたどり着かせるための走行用必須判定情報だけを生成させるようにすることが、処理負担の軽減と必要最小限の制御処理とを両立させる観点において望ましいといえる。この場合、走行用必須判定情報はタイヤ空気圧センサからの空気圧情報を含むものとしておけば、上記のような緊急状態での走行中においてもタイヤ空気圧を確実に監視することができ、スタンディングウェーブ等の不安定走行状態やタイヤバーストといった不測の事態の発生を防止し、又はこれに備えることができる。

図１５は、通常時に管理ユニット１０２にて作成される調停判定結果情報の内容例と、異常時にバックアップ管理ユニット１０３にて作成される非常用調停判定結果情報の内容例とを対比して示すものである。通常時の調停判定結果情報には、前述の走行中情報のほか、下位の情報としてイグニッションスイッチの付勢情報、車速情報（車速センサによる）、角速度情報（ジャイロセンサによる）、タイヤ空気圧情報（タイヤ空気圧センサによる）、フューエル残量情報（フューエルセンサによる）、カーナビゲーションシステムからの情報などが含まれている。これに対し、非常用調停判定結果情報には、走行用必須判定情報として、イグニッションスイッチの付勢情報、車速情報、タイヤ空気圧情報（以上、走行／停止関連）、角速度情報（ステアリング関連）、走行中情報（以上、ドアロックひいては乗降関連）のみが抜粋されて作成される。

本発明の自動車用制御装置の全体構成を示す概念図。 端末ユニットのブロック図。 代行管理ユニット機能を有した端末ユニットのブロック図。 管理ユニットのブロック図。 本発明の自動車用制御装置の第一具体例に係る通常時の動作説明図。 同じくフェールセーフ処理時の動作説明図。 上記第一具体例における管理ユニットの動作フロー図。 同じく代行管理ユニットの動作フロー図。 本発明の自動車用制御装置の第二具体例に係る動作説明図。 上記第二具体例における管理ユニットの動作フロー図。 同じくフェールセーフ処理時の動作説明図。 本発明の自動車用制御装置におけるバックアップ管理ユニットのブロック図。 管理ユニットが作成する調停判定結果情報の内容とバックアップ管理ユニットが作成する調停判定結果情報の内容とを対比して示す図。 本発明の自動車用制御装置の第三具体例に係る動作説明図。 上記第三具体例における管理ユニットの動作フロー図。

符号の説明

５０ 自動車制御装置
１００，１０１，１０２，１０３ 制御ユニット（ＥＣＵ）
１００，１０１ 端末ユニット
１０１ 代行管理ユニット
１０２ 管理ユニット
１０３ バックアップ管理ユニット

Claims (13)

1. 各々ＣＰＵを有した複数の制御ユニットが車内ネットワークを介して接続された構造を有するとともに、前記複数の制御ユニットとして、
   予め定められた制御判定事項に関し、その判定に使用する外部からの入力情報であって、前記判定に互いに独立して使用可能な原入力情報を取得するとともに、端末ユニットと、
   前記原入力情報に基づいて各前記端末ユニットが出力する情報であって、同一の制御判定事項に関して互いに競合しうる内容の異なる複数の二次入力情報を、前記車内ネットワークを介して受信し、受信したそれら二次入力情報に基づいて、前記制御判定事項に係る調停判定結果情報の内容を定め、これを前記車内ネットワーク上に送出する管理ユニットと、
   を備えたことを特徴とする自動車用制御装置。
2. 前記制御判定事項に係る判定結果は、予め定められた被判定状態が成立するか否かを二者択一的に示すべきものとされ、複数の前記二次入力情報は、それぞれ、前記被判定状態の成立に関して肯定を支持する肯定支持内容と、同じく否定を支持する否定支持内容とのいずれかの内容を取るものであり、前記調停判定結果情報は、それら前記二次入力情報の全てが肯定支持内容となっている場合にのみ前記被判定状態の成立に関して肯定判定内容となり、その余の場合には否定判定内容となるように定められる請求項１記載の自動車用制御装置。
3. 前記被判定状態は自動車が走行中の状態であり、前記原入力情報として、車速センサからの車速情報と、イグニッションスイッチの付勢情報とが使用され、前記管理ユニットは、前記イグニッションスイッチが付勢され、かつ、前記車速情報が予め定められた値以上の車速を示している場合に、前記判定情報として走行中情報を送出するものである請求項２記載の自動車用制御装置。
4. 前記制御判定事項に係る被判定状態として、互いに異なる３つ以上のものが定められ、前記調停判定結果情報は、３つ以上の前記二次入力情報の組み合わせに基づいて、それら被判定状態のいずれが成立しているかを示すものとなるように、その内容が定められる請求項１記載の自動車用制御装置。
5. 前記被判定状態として、自動車に対する搭乗者の乗降状態が、当該搭乗者の無線キーの携帯状況と関連付けて３つ以上に細分化する形で定められ、前記調停判定結果情報は、前記搭乗者が所持する無線キーとの通信に基づく該搭乗者の認証結果情報と、自動車の座席に装着された着座検知部による着座検知情報と、前記自動車のドアに設けられた開閉検知部によるドア開閉検知情報とに基づいて、それら乗降状態のいずれが成立しているかを示すものとしてその出力内容が定められる請求項４記載の自動車用制御装置。
6. 前記端末ユニットのいずれかが、前記管理ユニットによる前記調停判定結果情報の送出が不能となった場合に、自身が受信する前記原入力情報に基づいて非常用調停判定結果情報の内容を定め、これを前記管理ユニットに代わって前記車内ネットワーク上に代行送出する代行管理ユニットの機能を有してなる請求項１ないし請求項５のいずれか１項に記載の自動車用制御装置。
7. 請求項３記載の要件を備え、前記代行管理ユニットの機能を有してなる端末ユニットは、前記車速センサが接続された端末ユニットであり、該端末ユニットは該車速センサからの車速検知情報が、予め定められた値以上の車速を示している場合に、前記非常用調停判定結果情報として走行中情報を送出するものである請求項６記載の自動車用制御装置。
8. 請求項５記載の要件を備え、前記代行管理ユニットの機能を有してなる端末ユニットは、前記着座検知部が接続された端末ユニットであり、該端末ユニットは該着座検知部からの着座検知情報が着座状態を示している場合に、前記非常用調停判定結果情報として乗車中情報を送出するものである請求項６記載の自動車用制御装置。
9. 前記車内ネットワークには、前記管理ユニットによる前記調停判定結果情報の送出が不能となった場合に、各端末ユニットからの前記二次入力情報を代行受信し、受信したそれら二次入力情報に基づいて非常用調停判定結果情報の内容を定め、前記車内ネットワーク上に送出するバックアップ管理ユニットが設けられている請求項１記載の自動車用制御装置。
10. 前記バックアップ管理ユニットは、通常時は前記管理ユニットの動作を監視するものであり、前記調停判定結果情報の送出が不能となる異常が前記管理ユニットに発生したことを自ら検知して、前記非常用調停判定結果情報の送出の処理を行なうものである請求項９記載の自動車用制御装置。
11. 前記非常用調停判定結果情報は、正常時に前記管理ユニットが送出する前記調停判定結果情報よりも情報量が減じられている請求項１０記載の自動車用制御装置。
12. 前記非常用調停判定結果情報は、正常時に前記管理ユニットが送出する前記調停判定結果情報の内容から、自動車の走行／停止、ステアリング及び乗降を司るために予め必須と定められた走行用必須判定情報を抜粋する形で作成される請求項１１記載の自動車用制御装置。
13. 前記走行用必須判定情報はタイヤ空気圧センサからの空気圧情報を含む請求項１２記載の自動車用制御装置。

Images