(57)【要約】【課題】  従来技術では、運転手に不要な情報の報知を行わないようにするために、情報の報知の可否の判断を行うまでに、個々の処理条件の判断処理を行っていた。そのため、判断処理に要する時間が長くなっていた。また多数の処理条件が与えられるため、全体として車載機内の処理が増大し、処理条件を判断するための時間がかかっていた。そのため、車両の運転手に必要な情報を報知する時間が遅れるという問題があった。【解決手段】  機機器の状態情報の値に対して、イベント定義の中で、状態条件が成立する確率が低い順に設定された、状態条件番号の順に、状態条件を判定して、処理内容を処理するか否かを判定するので、例えば、車両の運転手に必要な情報を、報知するまでの時間を短縮することができる。【選択図】        図１
2014154069.tif 000002
【特許請求の範囲】
【請求項１】
機器に関する状態を示す状態情報に対して、設定される状態条件と、該状態条件がすべて成立したときに処理される処理内容と、前記状態条件を判定する順を示す状態条件番号と、から構成されるイベント定義が記憶されているイベント定義記憶手段、
前記機器の状態情報の値が入力される状態情報入力手段、
該状態情報入力手段から入力された状態情報の値に対して、前記イベント定義の中で、前記状態条件が成立する確率が低い順に設定された、前記状態条件番号の順に、前記イベント定義の状態条件を判定し、前記処理内容を処理するか否かを判定する処理条件判定手段、
を備えたことを特徴とするイベント検出装置。
【請求項２】
前記状態情報の状態条件毎に、機器の状態情報の値に対して、状態条件が成立する確率である条件成立確率が記憶されている条件成立確率記憶手段、
該条件成立確率記憶手段に記憶されている条件成立確率を用いて、前記イベント定義の状態条件番号を設定する状態条件設定手段、を更に備えたことを特徴とする請求項１記載のイベント検出装置。
【請求項３】
前記条件成立確率記憶手段は、前記状態情報の状態条件毎に、機器の状態情報の値に対する条件成立の確率が記憶されている複数の条件成立確率テーブルを記憶し、
該条件成立確率記憶手段に記憶されている、複数の条件成立確率テーブルから、１つの条件成立確率テーブルを有効に切り替える条件成立確率切替手段、を更に備え、
前記状態条件設定手段は、前記条件成立確率切替手段によって有効にされた、条件成立確率テーブルの条件成立確率を用いて、前記状態条件番号を設定することを特徴とする請求項２記載のイベント検出装置。
【請求項４】
前記状態情報入力手段から入力された値に対して、前記処理条件判定手段が、前記状態条件が成立しないと判定した場合に、判定した状態条件を含むイベント定義と、判定した状態条件を記憶する判定状態記憶手段を更に備え、
前記処理条件判定手段は、前記状態情報入力手段から入力された次の値に対して、前記判定状態記憶手段に記憶されている、イベント定義の状態条件から判定することを特徴とする請求項１〜請求項３のいずれかに記載のイベント検出装置。
【請求項５】
前記イベント定義には、各イベント定義に一意に与えられたイベント定義番号が更に記憶され、
前記状態情報の状態条件毎に、該状態条件を含むイベント定義のイベント定義番号を記憶する条件クラス記憶手段、
前記状態情報入力手段から入力された値に対して、前記条件クラス記憶手段に記憶された状態条件を判定し、該状態条件が成立すると判定すると、前記条件クラス記憶手段に記憶されている、成立すると判定した前記状態条件を含むイベント定義番号と、成立すると判定した前記状態条件の状態条件番号と、を前記処理条件判定手段に出力する条件クラス判定手段を更に備え、
前記処理条件判定手段は、前記状態情報入力手段から入力された測定値に対して、前記条件クラス判定手段から入力されたイベント定義番号の、状態条件番号の状態条件を判定することを特徴とする請求項１〜請求項４のいずれかに記載のイベント検出装置。
【請求項６】
前記条件クラス判定手段は、前記条件クラス記憶手段に記憶されている状態条件のうち、他の状態条件がすべて成立する状態条件から判定することを特徴とする請求項５記載のイベント検出装置。
【請求項７】
車両に関する状態を示す状態情報に対して、車両の運転を支援する先進運転支援装置から設定される状態条件と、該状態条件がすべて成立したときに処理される処理内容と、前記状態条件を判定する順を示す状態条件番号と、から構成されるイベント定義が記憶されているイベント定義記憶手段、
前記機器の状態情報の値が入力される状態情報入力手段、
該状態情報入力手段から入力された状態情報の値に対して、前記イベント定義の中で、前記状態条件が成立する確率が低い順に設定された、前記状態条件番号の順に、前記イベント定義の状態条件を判定し、条件が成立すると前記イベント定義の処理内容を外部に出力する処理条件判定手段、
を備えたことを特徴とする車載報知装置。
【請求項８】
機器に関する状態を示す状態情報に対して、設定される状態条件と、該状態条件がすべて成立したときに処理される処理内容と、前記状態条件を判定する順を示す状態条件番号と、から構成されるイベント定義が記憶されているイベント定義記憶手段、
前記機器の状態情報の値が入力される状態情報入力手段、
該状態情報入力手段から入力された状態情報の値に対して、前記イベント定義の中で、前記状態条件が成立する確率が低い順に設定された、前記状態条件番号の順に、前記イベント定義の状態条件を判定し、前記処理内容を処理するか否かを判定する処理条件判定手段、
を備えたイベント検出装置、
該イベント検出装置から出力された処理内容を報知する外部装置、
を備えたことを特徴とするイベント検出システム。
【請求項９】
機器に関する状態を示す状態情報に対して、設定される状態条件と、該状態条件がすべて成立したときに処理される処理内容と、前記状態条件を判定する順を示す状態条件番号と、から構成されるイベント定義が記憶されているイベント定義記憶手段、を備えたイベント検出装置のイベント検出方法において、
前記機器の状態情報の値が入力される状態情報入力ステップ、
該状態情報入力ステップで入力された状態情報の値に対して、前記イベント定義の中で、前記状態条件が成立する確率が低い順に設定された、前記状態条件番号の順に、前記イベント定義の状態条件を判定し、前記処理内容を処理するか否かを判定する処理条件判定ステップ、
を備えたことを特徴とするイベント検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器の状態を示す状態情報の値に対して、条件が成立する時に処理するイベントを検出するイベント検出装置、車載報知装置、イベント検出システム、およびイベント検出方法に関する。
【背景技術】
【０００２】
従来、自動車や鉄道車両等、移動体としての車両を安全に走行させるために、運転手に安全な運行を報知するシステム、またはＦＡ（Factory Automation）機器の運転等の際にに、障害が発生する状態の条件が成立したときに、機器の管理者に報知するシステムなどがある。
例えば、自動車の分野では、各車両が情報配信サーバに自車の位置情報を送信して、情報配信サーバは当該車両付近の位置に関連付けられた情報を配信し、運転手に報知する運転支援サービスが提案されている。ところが、当該車両付近の位置に関連付けられた情報が増大すると、運転手に報知する情報も増大してしまい、運転手に煩わしさを感じさせる。
【０００３】
そこで、車速や車両周囲の環境情報（気象、気温）等を参照して情報の報知の可否の判断を行い、運転手の煩わしさの低減を試みた例が開示されている（たとえば、特許文献１）。
【０００４】
【特許文献１】特開２００９−２３６５２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来技術では、運転手に不要な情報の報知を行わないようにするために、情報の報知の可否の判断を行うまでに、個々の処理条件の判断処理を行っていた。そのため、判断処理に要する時間が長くなっていた。また多数の処理条件が与えられるため、全体として車載機内の処理が増大し、処理条件を判断するための時間がかかっていた。そのため、車両の運転手に必要な情報を報知する時間が遅れるという問題があった。
本発明は、上述のような課題を解決するためになされたものであり、目的は、個々の処理条件の判断処理に要する時間を削減し、例えば、運転手に報知する時間を短縮することである。
【課題を解決するための手段】
【０００６】
この発明に係るイベント検出装置は、機器に関する状態を示す状態情報に対して、設定される状態条件と、該状態条件がすべて成立したときに処理される処理内容と、前記状態条件を判定する順を示す状態条件番号と、から構成されるイベント定義が記憶されているイベント定義記憶手段、該状態情報入力手段から入力された状態情報の値に対して、前記イベント定義の中で、前記状態条件が成立する確率が低い順に設定された、前記状態条件番号の順に、前記イベント定義の状態条件を判定し、前記処理内容を処理するか否かを判定する処理条件判定手段、を備えたことを特徴とする。
【発明の効果】
【０００７】
この発明は、機器の状態情報の値に対して、イベント定義の中で、状態条件が成立する確率が低い順に設定された、状態条件番号の順に、状態条件を判定して、処理内容を処理するか否かを判定するので、例えば、車両の運転手に必要な情報を、報知するまでの時間を短縮することができる。
【図面の簡単な説明】
【０００８】
【図１】この発明の実施の形態１における、イベント検出装置１の構成図である。
【図２】この発明の実施の形態１における、イベント定義の例を示す図である。
【図３】この発明の実施の形態１における、条件確率テーブルの例を示す図である。
【図４】この発明の実施の形態１における、エンジニアリング環境装置２の動作のフローチャートである。
【図５】この発明の実施の形態１における、イベント検出装置１の動作のフローチャートである。
【図６】この発明の実施の形態１における、イベント検出装置１の動作のフローチャートである。
【図７】この発明の実施の形態１における、イベント検出装置１を含む車載マイコンの処理周期のタイムスロット図である。
【図８】この発明の実施の形態１における、イベント検出装置１を含む車載マイコンのイベント定義判定処理のタイムスロット図である。
【図９】この発明の実施の形態１における、イベント検出装置１のイベント定義蓄積手段５に蓄積されるイベント定義の例を示す図である。
【図１０】この発明の実施の形態１における、状態情報の測定値の例を示す図である。
【図１１】この発明の実施の形態２における、イベント検出装置１の構成図である。
【図１２】この発明の実施の形態２における、エンジニアリング環境装置２の動作のフローチャートである。
【図１３】この発明の実施の形態２における、イベント検出装置１の動作のフローチャートである。
【図１４】この発明の実施の形態２における、イベント検出装置１のイベント定義蓄積手段５に蓄積されるイベント定義の例を示す図である。
【図１５】この発明の実施の形態３における、イベント検出装置１の構成図である。
【図１６】この発明の実施の形態３における、イベント検出装置１の動作のフローチャートである。
【図１７】この発明の実施の形態３における、状態情報の測定値の例を示す図である。
【図１８】この発明の実施の形態３における、イベント検出装置１の判定状態蓄積手段１２に蓄積された状態条件番号の例を示す図である。
【図１９】この発明の実施の形態４における、イベント検出装置１の構成図である。
【図２０】この発明の実施の形態４における、条件クラステーブルの例を示す図である。
【図２１】この発明の実施の形態４における、イベント検出装置１の動作のフローチャートである。
【図２２】この発明の実施の形態４における、イベント検出装置１の動作のフローチャートである。
【図２３】この発明の実施の形態４における、イベント検出装置１の動作のフローチャートである。
【図２４】この発明の実施の形態４における、イベント検出装置１の動作のフローチャートである。
【図２５】この発明の実施の形態４における、状態情報の測定値の例を示す図である。
【図２６】この発明の実施の形態５における、イベント検出装置１が接続されるＡＤＡＳシステムの構成図である。
【図２７】この発明の実施の形態５における、イベント検出装置１が接続されるＡＤＡＳ装置システムの動作を示すフローチャートである。
【図２８】この発明の実施の形態５における、イベント定義の例である。
【図２９】この発明の実施の形態５における、危険状態自動収集システムの構成図である。
【発明を実施するための形態】
【０００９】
実施の形態１．
図１は、この発明の実施の形態１における、イベント検出装置１の構成図である。
図１のイベント検出装置１は、エンジニアリング環境装置２、センサ３、および外部装置４に接続されている。
ここでは、イベント検出装置１が検出するイベント定義は、例えば、移動体としての車両（自動車）を安全に走行させるために定義されている。そして、そのイベント定義には、自動車の状態を示す状態情報の測定値に対して、予め設定された状態条件と、その状態条件がすべて成立したときに、処理される処理内容（例えば、「この先凍結注意」と報知）が登録されているとする。
【００１０】
そして、自動車の状態情報の測定値がセンサ３で測定され、イベント検出装置１に入力された時に、イベント検出装置１が、その状態情報の測定値に対して、状態条件が成立するか否かを判定する。そして、すべての状態条件が成立すると判定すると、イベント定義で定義されている処理内容を外部装置４に出力して、外部装置４が運転者にその内容を報知する。
また、イベント定義は、イベント定義設定者によって、エンジニアリング環境装置２を介して、イベント検出装置１に入力される。
ここでは、イベント定義設定者が、エンジニアリング環境装置２を介して、イベント検出装置１にイベント定義を入力するとして説明するが、イベント定義を入力するのは、外部コンピュータシステム、システム設計者であってもよい。
【００１１】
イベント検出装置１は、イベント定義蓄積手段５、状態情報収集手段６、処理条件判定手段７から構成されている。
エンジニアリング環境装置２は、イベント定義入力手段８、状態条件並び替え手段９、条件成立確率蓄積手段１０から構成されている。
イベント定義蓄積手段５は、イベント定義記憶手段に相当し、状態情報収集手段６は、状態情報入力手段に相当する。また、状態条件並び替え手段９は、状態条件設定手段に相当し、条件成立確率蓄積手段１０は、条件成立確率記憶手段に相当する。
【００１２】
まず、各構成要素について説明する。
エンジニアリング環境装置２は、イベント定義設定者が、イベント定義をイベント検出装置１に設定するために用いるコンピュータシステムである。エンジニアリング環境装置２は、イベント検出装置１に接続され、イベント定義をイベント検出装置１に書き込む。また、エンジニアリング環境２に、ＳＤカードをはじめとした、フラッシュメモリを接続して、そのフラッシュメモリにイベント定義を書込み、そのフラッシュメモリをイベント検出装置１に挿入して、イベント検出装置１にイベント定義を書き込んでも良い。
【００１３】
エンジニアリング環境装置２のイベント定義入力手段８は、イベント定義設定者によって、イベント検出装置１にイベント定義を設定するためのインターフェースである。イベント定義入力手段８は、イベント定義設定者によって、イベント定義が入力され、入力されたイベント定義を状態条件並び替え手段９に出力する。イベント定義の構成については後述する。
【００１４】
エンジニアリング環境装置２の状態条件並び替え手段９は、条件成立確率蓄積手段１０に蓄積されている条件成立確率を用いて、イベント定義入力手段８から入力されたイベント定義の、状態条件が真となる確率（状態条件が成立する確率）が低い順となるように、状態条件番号を設定する。そして、状態条件を並び替えたイベント定義を、イベント検出装置１のイベント定義蓄積手段５に出力する。
【００１５】
エンジニアリング環境装置２の条件成立確率蓄積手段１０は、ある特定の状態条件が真となる確率を記録する条件成立確率テーブルのデータを蓄積（記憶）する。条件成立確率テーブルは、状態情報、状態条件、条件成立確率から構成される。
条件成立確率は、状態条件が成立する確率であり、例えば、複数台の自動車を走行させたときに、得られた状態情報の測定値から、状態条件が真となる確率を割り出し、記憶しておく。
条件成立確率蓄積手段１０に蓄積されている、条件成立確率テーブルの条件成立確率は、状態条件並び替え手段９から参照される。
【００１６】
イベント検出装置１のイベント定義蓄積手段５は、エンジニアリング環境装置２の状態条件並び替え手段９から入力されたイベント定義を蓄積している。そして、そのイベント定義は、処理条件判定手段７から参照される。
【００１７】
イベント検出装置１の状態情報収集手段６は、自動車の状態情報の測定値を収集（取得）する。自動車の状態情報の測定値は、イベント検出装置１に接続されたセンサ３から入力されて、状態情報収集手段６に収集してもよいし、車載ネットワーク（図示せず）に接続して入力されて、状態情報収集手段６に収集してもよい。状態情報収集手段６は、センサ３、または車載ネットワーク（図示せず）から収集した自動車の状態情報の値を処理条件判定手段７に出力する。
【００１８】
センサ３、または車載ネットワーク（図示せず）として、一般的な自動車には、ＣＡＮ（Ｃｏｎｔｒｏｌｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＥｔｈｅｒｎｅｔ（登録商標）が搭載されている。
センサ３、または車載ネットワークを接続して収集できる状態情報の例は、たとえば、車速、操舵角、アクセル開度、ブレーキ踏度、シフトの位置、残燃料、ブレーキ温度、ウィンカーの点灯状態、ライトの点灯状態、エアコンの動作状態、ワイパーの動作状態、パワーウインドウの動作状態、等がある。
以降、車載ネットワークを接続して収集できる状態情報の値を含めて、センサ３から入力される状態情報の測定値として説明する。
【００１９】
イベント検出装置１の処理条件判定手段７は、状態情報収集手段６から入力される自動車の状態情報の測定値に対して、イベント定義蓄積手段５のイベント定義を参照し、イベント定義に含まれる処理条件の真偽（処理条件が成立するか否か）を、事前に定義された状態条件の判定順序で判定する。また、処理条件判定手段７は、イベント定義に含まれる処理条件が真となったとき、外部装置４にその旨を通知し、イベント定義に含まれる処理内容を出力する。
【００２０】
外部装置４は、イベント検出装置１の処理条件判定手段７からイベント定義の処理内容が入力され、特定の処理を実行する装置である。例えば、運転手への情報の通知処理を行うカーナビゲーション装置、外部への通信処理を行う外部通信装置、車両の制御処理を行う車両制御装置、車両内の情報の収集を行う車両情報収集装置等が挙げられる。
以上が、各構成要素の説明である。
【００２１】
次に、イベント定義の例について説明する。
図２は、この発明の実施の形態１における、エンジニアリング環境装置２のイベント定義入力手段８に入力されるイベント定義の例を示す図である。
図２では、イベント定義Ｔ１０１〜Ｔ１０８が示されている。
イベント定義は、例えば、イベント定義番号、処理内容、処理条件、状態条件番号、状態条件から構成される。
イベント定義番号とは、イベント定義に対して、イベント検出装置１内で一意に与えられる番号のことである。図２のイベント定義Ｔ１０１に対しては「１」が、イベント定義Ｔ１０２に対しては「２」がそれにあたる。
【００２２】
処理内容とは、外部装置４に行わせる特定の処理を示す。例えば、イベント定義Ｔ１０１では、「『この先凍結注意』なる通知を運転手に報知すること」が処理内容にあたる。
処理条件とは、自動車の状態情報に関する条件で、外部装置４に特定の処理を行わせるための通知を行う条件である。処理条件は、１つ、あるいは複数の状態条件から構成される。処理条件の真偽は、処理条件を構成する状態条件の真偽の論理積と定義する。
【００２３】
例えば、処理条件の真偽は、処理条件を構成する状態条件の１つが偽であれば（状態条件の１つが成立しなければ）、処理条件は偽となり、処理条件判定手段７は、外部装置４に処理内容を出力しない。そのため、外部装置４からは運転手に何も報知されない。また、状態条件のすべてが真であれば（状態条件のすべてが成立すれば）、処理条件は真となり、処理条件判定手段７は、外部装置４に処理内容を出力する。そのため、外部装置４から運転手に、イベント定義の処理内容に含まれる情報が報知される。
【００２４】
例えば、イベント定義Ｔ１０１においては、処理条件は３つの状態条件（「｛車速｝が８０ｋｍ／ｈ以上」、「｛操舵角｝が１０度より大きい」、「｛気温｝が０℃より低い」）から構成される。そして、センサ３から入力される自動車の状態情報の測定値について、これらの３つの状態条件のすべてが真である時（すべてが成立する時）、処理内容『この先凍結注意』が運転手に報知される。
【００２５】
状態条件とは、単一の状態情報（センサ３から入力される自動車の状態情報）を用いて表せる条件である。状態条件の真偽は、ある瞬間の、センサ３から入力される自動車の状態情報の測定値に対して、特定の値と比較した結果と定義する。比較の種類は、「ある値と等しい」、「ある値と等しくない」、「ある値よりも大きい」、「ある値よりも小さい」等で表される。
【００２６】
例えば、イベント定義Ｔ１０１の状態条件「｛車速｝が８０ｋｍ／ｈ以上」に対する状態条件の真偽は、センサ３から入力される状態情報の測定値が、｛車速｝＝８０ｋｍ／ｈであれば真となり、｛車速｝＝７９ｋｍ／ｈであれば偽となる。
【００２７】
状態情報とは、自動車のセンサ３から状態情報収集手段６によって収集される、自動車の状態を示す情報である。状態情報の測定値は、状態条件の特定の値と比較可能な値である。
例えば、イベント定義Ｔ１０１においては、３つの状態条件がそれぞれ｛車速｝、｛操舵角｝、｛気温｝の状態情報を用いて表されている。
【００２８】
状態条件番号とは、状態条件に設定される番号であり、状態条件を判定する順序を表す。イベント定義Ｔ１０１においては、３つの状態条件に１から３の状態条件番号が設定されている。イベント定義Ｔ１０２のように、状態条件番号が設定されていなくてもよい。
例えば、図１のイベント定義Ｔ１０１の状態条件を判定する順序は、状態条件番号１の次は、状態条件番号２、状態条件番号３の順となる。また、本発明で次の状態条件と記述したときには、その時判定している状態条件に付された状態条件番号の、次に大きい状態条件番号が付されている状態条件を指すものとする。
【００２９】
また、イベント定義Ｔ１０２に示した様に、状態条件番号が設定されていない場合には、エンジニアリング環境装置２の状態条件並び替え手段９によって、条件成立確率蓄積手段１０を参照して、イベント定義の中で、条件成立確率が低い順に、状態条件番号が昇順に設定される。
以上が、イベント定義の例についての説明である。
【００３０】
次に、条件成立確率テーブルの例について説明する。
図３は、この発明の実施の形態１における、エンジニアリング環境装置２の条件成立確率蓄積手段１０に蓄積されている、条件成立確率テーブルの例を示す図である。
条件成立確率テーブルは、状態情報、状態条件、条件成立確率（状態条件が真となる確率）から構成されている。
ここでは、条件成立確率テーブルには、条件成立確率テーブルＴ２０１と条件成立確率テーブルＴ２０２があるとする。
【００３１】
条件成立確率テーブルＴ２０１からは、例えば、状態情報｛車速｝について、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件が真となる確率が１１％、「｛車速｝が３０ｋｍ／ｈ以上」という状態条件が真となる確率が６１％、「｛車速｝が１０ｋｍ／ｈ以上」という状態条件が真となる確率が９６％であると読み取れる。
【００３２】
また、状態情報｛操舵角｝について、「｛操舵角｝が２０度より大きい」という状態条件が真と成る確率が５％、「｛操舵角｝が１０度より大きい」という状態条件が真と成る確率が１０％、「｛操舵角｝が５度より大きい」という状態条件が真と成る確率が１０％であると読み取れる。
【００３３】
また、状態情報｛気温｝について、「｛気温｝が１０℃より低い」という状態条件が真となる確率は９９％、「｛気温｝が０℃より低い」という状態条件が真となる確率は５％、「｛気温｝が−１０℃より低い」という状態条件が真となる確率は１％であると読み取れる。
【００３４】
そして、条件成立確率テーブルＴ２０２からは、状態情報｛車速｝について、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件が真となる確率が０．１％、「｛車速｝が３０ｋｍ／ｈ以上」という状態条件が真となる確率が７５％、「｛車速｝が１０ｋｍ／ｈ以上」という状態条件が真となる確率が９６％であると読み取れる。
また、状態情報｛操舵角｝以下については、条件成立確率テーブルＴ２０１と同じであると読み取れる。
【００３５】
尚、条件成立確率テーブルには、条件成立確率テーブルＴ２０１に示したように、とびとびの値が記録されていてもよいし、あるいは「｛車速｝がｘ  ｋｍ／ｈ以上」という状態条件が真となる確率はｆ（ｘ）％であるというように、関数の形で記録されていてもよい。
条件成立確率テーブルは、予めエンジニアリング環境装置２の条件成立確率蓄積手段１０に設定され、蓄積（登録）されている。
条件成立確率テーブルの定義は、例えば、エンジニアリング環境装置２の製作者などが実施する。設定する方法は、例えば、任意に設定してもよいし、自動車の状態情報を収集して、自動車の稼働時間に対して、ある状態条件が真となる時間の割合を算出し、その割合を条件成立確率テーブルの条件成立確率に設定する方法をとってもよい。
以上が、条件成立確率テーブルの例についての説明である。
【００３６】
次に、この発明の実施の形態１における、イベント検出装置１とエンジニアリング環境装置２の動作を、以下に示す二つの動作に区分して説明する。
動作１−１：エンジニアリング環境装置２が、イベント定義設定者によって入力されたイベント定義をイベント検出装置１に設定する動作。
動作１−２：イベント検出装置１が、センサ３からの状態情報の測定値に対して、イベント定義に含まれる処理条件を判定して、真であれば、外部装置４に処理内容の通知を行う動作。
【００３７】
まず、動作１−１（エンジニアリング環境装置２の動作）について説明する。
図４は、この発明の実施の形態１における、複数のイベント定義を設定する動作（エンジニアリング環境装置２の動作）のフローチャートである。
複数のイベント定義を設定する場合には、図４のフローチャートを繰り返す。
まず、イベント定義設定者は、エンジニアリング環境装置２のイベント定義入力手段８を用いて、イベント定義を入力する（ステップ（以下Ｓ）１５０）。
【００３８】
次に、エンジニアリング環境装置２の状態条件並び替え手段９は、図３の条件成立確率蓄積手段１０の条件成立確率テーブルを用いて、Ｓ１５０で入力されたイベント定義に含まれる状態条件に対して、各状態条件が真となる確率（条件成立確率）を抽出する（Ｓ１５１）。
次に、状態条件並び替え手段９は、各状態条件に対し、イベント定義の中の、状態条件が真となる確率が低い順に順位をつけ、順位に従って昇順に状態条件番号を設定する（Ｓ１５２）。
次に、状態条件並び替え手段９は、状態条件番号を設定したイベント定義を、イベント検出装置１のイベント定義蓄積手段５に書込み（出力し）、イベント定義蓄積手段５はイベント定義を蓄積する。（Ｓ１５３）。
【００３９】
次に、動作１−２（イベント検出装置１の動作）について説明する。
図５は、この発明の実施の形態１における、イベント検出装置１の処理条件判定手段７の動作のフローチャートである。
この動作は、一定の処理周期毎に、処理条件判定手段７が行う。
まず、処理条件判定手段７は、イベント定義蓄積手段５のイベント定義に、未判定のイベント定義が存在するか否かを確認する。（Ｓ２５０）
【００４０】
Ｓ２５０において未判定のイベント定義が存在しない場合、処理を終了する。
Ｓ２５０において未判定のイベント定義が存在する場合には、Ｓ２５１にすすむ。
次に、イベント定義蓄積手段５から、イベント定義を一つ読み込む（Ｓ２５１）。
次に、読み込んだイベント定義に記載された処理条件の真偽を判定する（Ｓ２５２）。この処理条件の真偽の判定の動作の詳細は、後で詳述する。
【００４１】
Ｓ２５２において処理条件の真偽の判定が真であれば、イベント定義に含まれる処理内容を、外部装置４に通知する（Ｓ２５３）。そして、外部装置４によって、運転手にイベント定義の処理内容に含まれる情報が報知される。
Ｓ２５２において処理条件の真偽の判定が偽であれば、Ｓ２５０にもどる。外部装置４に処理条件の真偽の判定結果は通知されず、運転手にイベント定義の処理内容に含まれる情報は報知されない。
【００４２】
Ｓ２５２において処理条件判定手段７が、処理条件の真偽を判定する動作の詳細について、フローチャートを図６に示す。
図６は、この発明の実施の形態１における、イベント検出装置１の処理条件判定手段７の動作のフローチャートである。
まず、処理条件の中に未判定の状態条件が存在するか否か判定する（Ｓ２６０）。
【００４３】
Ｓ２６０において未判定の状態条件が存在しない場合、すべての状態条件の真偽の判定が行われ、真であったことになる。そのため、処理条件判定手段７は、一時記憶領域（図示せず）に処理条件の判定結果が真であったことを出力する。（Ｓ２６１）。出力された結果は、図５のＳ２５２の処理条件の真偽の判定で参照される。ここでは、処理条件が真と出力されるため、Ｓ２５２ではＹＥＳとなり、Ｓ２５３の処理となる。
Ｓ２６０において未判定の状態条件が存在する場合、処理条件に含まれる状態条件のうち、状態条件番号の小さい番号から順に、次の状態条件を読み込む。状態条件を一つも判定していない場合には、状態条件番号「１」をもつ状態条件を読み込む（Ｓ２６２）。
【００４４】
次に、状態条件の真偽を判定する、自動車の状態情報の測定値を、状態情報収集手段６から読み込む（Ｓ２６３）。
次に、Ｓ２６３で読み込んだ状態情報の測定値に対して、状態条件を判定する。（Ｓ２６４）
Ｓ２６４において状態条件が偽であれば、処理条件の判定結果は偽であり（状態条件が１つでも偽であれば処理条件は偽となるため）、処理条件判定手段７は、一時記憶領域（図示せず）に処理条件の判定結果が偽であることを出力する（Ｓ２６５）。
Ｓ２６４において状態条件が真であれば、Ｓ２６０にもどる。ここで、Ｓ２６０に戻るため、Ｓ２６１で未判定の状態条件が存在するか否かを判定する。そして、存在しなければ、判定したすべての状態条件の判定結果が真となる。
【００４５】
次に、実施の形態１における、イベント検出装置１の動作を具体例で説明する。
図７は、この発明の実施の形態１における、イベント検出装置１を含む車載マイコンの処理周期のタイムスロット図である。
一般的に車載マイコンは、特定の処理に対して一定の時間を割り当て、それらの処理を一定の処理周期で繰り返す。たとえば、図７は通信処理・イベント定義判定処理（イベント判定処理）・通知処理・制御処理の４つの処理それぞれに、時間が割り当てられ、それを一定の処理周期で繰り返すことを示している。
【００４６】
イベント定義判定処理は、イベント検出装置１の処理条件判定手段７の判定処理に相当する。図７においてイベント定義判定処理に注目すると、イベント定義判定処理には時間ｄが割り当てられ、それが時間Ｔおきに繰り返される。
【００４７】
図８は、この発明の実施の形態１における、イベント検出装置１を含む車載マイコンのイベント定義判定処理のタイムスロット図である。
説明の便宜上、１単位時間を、イベント定義判定処理に割り当てられた、時間ｄの１２分の１と定義する。つまり、イベント定義の判定に割り当てられた時間は１２単位時間となる。
【００４８】
１つの状態条件の判定に１単位時間要するとすると、３つの状態条件をもつ、イベント定義の判定に要する時間は３単位時間である。仮に、イベント検出装置１のイベント定期蓄積手段５にイベント定義Ｔ１０１〜Ｔ１０８が入力された場合、３状態条件×８イベント定義＝２４単位時間の判定時間を要する。
しかし、図８に示したたように、イベント定義の判定に割り当てられた１２単位時間では、１回の処理周期に４つまでしかイベント定義を判定できないことになる。
【００４９】
８つのイベント定義の条件をすべて判定すると、４つのイベント定義を判定したところで、イベント定義の判定に割り当てられた１２単位時間になるため、別の処理が行われる。そのため、次の処理周期のイベント判定に割り当てられた時間に、イベント定義の判定を先送りすることになる。先送りして判定した場合には、報知するタイミングが処理周期分だけ遅れてしまう。
【００５０】
例えば、図２のイベント定義Ｔ１０１〜Ｔ１０６の状態条件を順に判定して、イベント定義Ｔ１０６で状態条件がすべて真になる（処理条件が真になる）という場合、３状態条件×６イベント定義＝１８単位時間が必要になる。そのため、２回目の処理周期で処理内容が、運転者に報知されることになる。
【００５１】
そこで、本発明では、イベント定義が真となる確率が低い（偽となる確率が高い）状態条件から判定を行う。
例えば、イベント定義５までは、１つめの状態条件が偽であると判定されるとすると、２つめと３つめの状態条件は判定をする必要がなくなるため、次のイベント定義の判定を行う。そのため、イベント定義６の状態条件が全て真と判定されるまでに要する判定時間は、８単位時間となる。そのため、１回目のイベント定義の判定で報知することができる。
【００５２】
この様に、偽となりやすい状態条件から判定を開始することで、個々のイベント定義の判定に要する時間を削減することができる。そのため、車載マイコンで１処理周期内に判定できるイベント定義の数を増やすことができ、処理内容を運転者に報知するタイミングを、早くすることができる。
【００５３】
次に、図４のフローチャートを用いて、イベント定義設定者が、イベント定義Ｔ１０１をエンジニアリング環境装置２に入力し、イベント検出装置１に設定するまでの動作（Ｓ１５０〜Ｓ１５３）を、具体例を用いて説明する。この動作は、動作１−１に対応する。
まず、Ｓ１５０において、イベント定義設定者はイベント定義Ｔ１０１をエンジニアリング環境装置２のイベント定義入力手段９に入力する。そして、イベント定義入力手段９は、状態条件並び替え手段９に入力されたイベント定義Ｔ１０１を出力する
【００５４】
次に、Ｓ１５１において、エンジニアリング環境装置２の状態条件並び替え手段９は、条件成立確率蓄積手段１０に蓄積されている、図３の条件成立確率テーブルＴ２０１のデータを参照して、入力されたイベント定義Ｔ１０１の各状態条件が真となる確率を抽出する。
イベント定義Ｔ１０１の「｛車速｝が８０ｋｍ／ｈ以上」という状態条件が真となる確率は「１１％」、「｛操舵角｝が１０度より大きい」という状態条件が真となる確率は「１０％」、「｛気温｝が０℃より低い」という状態条件が真となる確率は「５％」となる。
【００５５】
次に、Ｓ１５２において、イベント定義の中で、状態条件が真となる確率が低い順に順位をつけ、その順位をイベント定義Ｔ１０１の含まれる状態条件番号に設定する。
５％＜１０％＜１１％であるので、「｛気温｝がー１０℃より低い」という状態条件には「１」が、「｛操舵角｝が１０度より大きい」という状態条件には「２」が、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件には「３」が、状態条件番号に設定される。
【００５６】
この様に、エンジニアリング環境装置２の状態条件並び替え手段９が、イベント定義入力手段８から入力されたイベント定義Ｔ１０１に対して、条件成立確率蓄積手段１０の条件成立確率テーブルＴ２０１のデータを参照して、イベント定義の中で、状態条件が真となる確率が低い順に状態条件番号を設定する。
図９は、この発明の実施の形態１における、イベント検出装置１のイベント定義蓄積手段５に蓄積されるイベント定義の例を示す図である。
例えば、イベント定義Ｔ１０１は、図９のイベント定義Ｔ１１１の状態条件番号ように設定される。
【００５７】
イベント定義Ｔ１０２〜Ｔ１０８についても、同様に、エンジニアリング環境装置２のイベント定義入力手段８に入力されると、イベント定義の中で、状態条件が真となる確率が低い順に、状態条件番号が設定される。そして、Ｓ１５３において、図９に示したイベント定義Ｔ１１１−Ｔ１１８のように、イベント定義蓄積手段５に蓄積される。
【００５８】
次に、図５と図６のフローチャートを用いて、イベント検出装置１の処理条件判定手段７が、複数のイベント定義に含まれる処理条件の真偽を判定する動作（Ｓ２５０〜Ｓ２５３）について説明する。この動作は、動作１−２に対応する。
ここでは、図９に示すように、イベント検出装置１のイベント定義蓄積手段５に、イベント定義の中で、状態条件が真となる確率が低い順に、状態条件番号が設定された、８つのイベント定義が蓄積されているものとする。また、ある瞬間の状態情報の測定値として、図１０に示す値がセンサ３で測定され、イベント検出装置１の状態情報収集手段６に入力されたものとする。
【００５９】
図１０は、この発明の実施の形態１における、イベント検出装置１の状態情報収集手段６に収集された状態情報の具体例を示す図である。
例えば、図１０のように、状態情報の｛車速｝の測定値が８１ｋｍ／ｈ，｛操舵角｝の測定値が７度、｛気温｝の測定値が１℃、｛アクセル開度｝の測定値が３１％、｛ブレーキ踏度｝の測定値が０％、｛ウィンカー｝の測定値がＯＦＦであったとする。
【００６０】
まず、図５のＳ２５０において、状態情報収集手段６に収集された状態情報の測定値に対して、判定するイベント定義が存在するので、Ｓ２５１にすすむ。
次に、Ｓ２５１において、イベント定義が一つ読み込まれる。どのイベント定義を読み込んでもよいが、ここではイベント定義Ｔ１１１が読み込まれたものとする。
次に、Ｓ２５２において、読み込んだイベント定義Ｔ１１１の処理条件を判定するため、Ｓ２５２の処理を詳細に説明した図６にすすむ。
【００６１】
Ｓ２６０において、処理条件の中で、未判定の状態条件が存在するか確認する。未判定の状態条件が存在するので、Ｓ２６２にすすむ。
次に、Ｓ２６２において、処理条件判定手段７は、状態条件番号「１」をもつ状態条件である「｛気温｝が０℃より低い」を、イベント定義蓄積手段５から読み込む。
次に、Ｓ２６３において、処理条件判定手段７は、状態条件を判定する状態情報である｛気温｝の測定値を、状態情報収集手段６から読み込む。ここでは「１℃」が読み込まれたとする。
【００６２】
次に、Ｓ２６４において、状態条件を判定する。「１℃」＜「０℃」は偽であるので、Ｓ２６５にすすむ。
次に、Ｓ２６５において、処理条件が偽であると出力された結果、図５のＳ２５２の判定はＮＯとなるため、図５のＳ２５０にもどる。そして、次のイベント定義を判定することになる。
以降、未判定のイベント定義が存在しなくなるまで、Ｓ２５０からＳ２５３が繰り返される。
イベント定義Ｔ１１１〜Ｔ１１５、およびイベント定義Ｔ１１７〜Ｔ１１８に関しては、最初の状態条件が偽であるため、一つの状態条件の判定のみで、処理条件が偽と判定される。
【００６３】
また、イベント定義Ｔ１１６に関しては、「｛アクセル開度｝が５０％より大きい」→「｛車速｝３０ｋｍ／ｈ以上」→「｛ウィンカー｝がＯＦＦ」の順で状態条件が判定され、いずれの状態条件も真となるので、処理条件が真と判定される。したがって、運転手には「この先飛び出し注意」なる報知が行われることになる。
【００６４】
以上のように、自動車から得られるセンサ３の状態情報の測定値に対して、状態条件の少なくとも１つが偽となれば、イベント定義の処理条件の真偽の判定を、偽と判定するような場合には、イベント定義の、状態条件の真になる確率が低い順（または、偽になる確率が高い順）に状態条件を判定することにより、処理条件の判定の処理時間を低減することができる。そのため、１回の処理周期に処理するイベント定義を多くすることができるため、イベント定義の処理内容に含まれる情報を報知するタイミングを早くすることができる。
【００６５】
例えば、イベント定義の状態条件を２４回行う必要がある場合に、１つの状態条件の判定に１単位時間要するとすると、２４単位時間かかるところを、１０回行えばよいため、すべてのイベント定義を判定するのに１０単位時間で済むことになる。これにより、図８に示したように、１回の処理周期に８つのイベント定義を処理することが可能になり、報知のタイミングを早くすることができる。
【００６６】
ここでは、自動車を例にあげたが、例えば、ＦＡ機器など、ＦＡ機器の状態を示す状態情報について、起こりうる確率が予めわかっていて、状態条件がすべて成立する時に、設定された処理内容を処理するような機器に対しても適用することができる。
【００６７】
実施の形態２．
実施の形態１では、エンジニアリング環境装置２の状態条件並び替え手段９によって、イベント定義の中で、状態条件が真となる確率が低い順（または、偽になる確率が高い順）に状態条件の判定順を並び替え、イベント検出装置１のイベント定義蓄積手段５に蓄積し、並び替えた順に状態条件を判定することで、個々の処理条件の判定の時間を低減させる構成をとった。
しかし、状態条件が真となる確率は、その自動車が置かれている状況、たとえば、ドライバーの運転の仕方、運転する地域または気候によって異なる。
そこで、実施の形態２では、状態条件並び替え手段９、条件成立確率蓄積手段１０をイベント検出装置１に配置し、条件成立確率蓄積手段１０の条件成立確率テーブルを、イベント検出装置１内で切り替えられるようにする構成例を示す。
【００６８】
図１１は、この発明の実施の形態２における、イベント検出装置１の構成図である。
実施の形態２におけるイベント検出装置１、エンジニアリング環境装置２、センサ３、および外部装置４の接続関係は、実施の形態１と同様である。
実施の形態２におけるイベント検出装置１は、イベント定義蓄積手段５、状態情報収集手段６、処理条件判定手段７、状態条件並び替え手段９、条件成立確率蓄積手段１０、条件成立確率切替手段１１から構成されている。
エンジニアリング環境装置２は、イベント定義入力手段８から構成されている。
【００６９】
次に、実施の形態２における、各構成要素について説明する。
エンジニアリング環境装置２のイベント定義入力手段８は、イベント定義設定者によって、入力されたイベント定義を、イベント検出装置１の状態条件並び替え手段９に出力する。
【００７０】
イベント検出装置１の状態条件並び替え手段９は、エンジニアリング環境装置２のイベント定義入力手段８から入力されたイベント定義を、イベント定義蓄積手段５に出力する。この時、状態条件並び替え手段９は、入力されたイベント定義に対して、イベント検出装置１の条件成立確率蓄積手段１０に蓄積されている、条件成立確率テーブルの条件成立確率を用いて、イベント定義の中で、状態条件が真となる確率が低い順に、状態条件番号を割り当てる。そして、イベント定義の状態条件番号が小さい順に処理条件を並び替えて、イベント定義をイベント定義蓄積手段５に出力して蓄積する。
【００７１】
また、状態条件並び替え手段９は、条件成立確立蓄積手段１０の有効となる条件成立確立テーブルが切り替えられると、イベント定義蓄積手段５に蓄積されている、イベント定義の状態条件番号の割り当てをし直し、イベント定義の状態条件番号を並び替える。
【００７２】
イベント検出装置１の条件成立確立蓄積手段１０は、単一、あるいは複数の条件成立確率テーブルを蓄積する。複数の条件成立確率テーブルを蓄積している場合には、そのうちただ一つのみが有効となっており、有効となる条件成立確率テーブルは、外部からの入力により、イベント検出装置１の条件成立確立切替手段１１によって切り替えられる。
【００７３】
イベント検出装置１の条件成立確立切替手段１１は、条件成立確立蓄積手段１０の複数の条件成立確率テーブルを切り替えるインターフェースである。条件成立確率切替手段１１は、たとえば時刻や気候、運転者等の変化によって、状態条件の成立確率が変化したと考えられるとき、状態条件並び替え手段９が参照する、有効とする条件成立確率テーブルを切り替える。
【００７４】
条件成立確率テーブルの切り替えは、ボタン操作等によって、自動車の運転手が手動で行なってもよいし、事前にイベント定義設定者が設定したスケジュールに従って行われてもよいし、運転手または気候を検知するプログラムによって自動で切り替えられてもよい。
例えば、車内カメラを用いて画像認識により、運転手が誰であるかを認識して、その個人に応じた適切な条件成立確率テーブルを選択して切り替えてもよいし、車外カメラを用いて、路面状況等から天候を認識して、その天候に応じた適切な条件成立確率テーブルを選択して切り替えても良い。
【００７５】
イベント検出装置１のイベント定義蓄積手段５は、イベント定義の中で、状態条件が真となる確率が低い順に、状態条件番号が設定されたイベント定義が、状態条件並び替え手段９から入力され、入力されたイベント定義を蓄積する。また、蓄積しているイベント定義は、処理条件判定手段７から参照される。
イベント検出装置１の状態情報収集手段６と処理条件判定手段７は、実施の形態１と同様であるため、説明を省略する。
また、センサ３と外部接続４も、実施の形態１と同様であるため、説明を省略する。
以上が、実施の形態２の各構成要素についての説明である。
【００７６】
次に、実施の形態２における、イベント検出装置１とエンジニアリング環境装置２の動作を、以下の３つの動作に分けて説明する。
動作２−１：エンジニアリング環境装置２が、イベント定義設定者によって入力されたイベント定義をイベント検出装置１に設定する動作。
動作２−２：イベント検出装置１が、イベント定義を蓄積する動作。
動作２−３：イベント検出装置１が、センサ３からの状態情報の測定値に対して、イベント定義の処理条件を判定して、真であれば、外部装置４に処理内容の通知を行う動作。
【００７７】
まず、動作２−１について説明する。
図１２は、この発明の実施の形態２における、イベント検出装置１にイベント定義を設定するエンジニアリング環境装置２の動作のフローチャートである。
動作２−１は、複数のイベント定義を設定する場合には、図１２のフローチャートを繰り返す。
イベント定義設定者は、図１１のエンジニアリング環境装置２のイベント定義入力手段８から、イベント定義を入力する（Ｓ１６０）。
次に、イベント定義入力手段８は、イベント定義設定者が入力したイベント定義を、イベント検出装置１の状態条件並び替え手段９に出力して、イベント検出装置１にイベント定義を書き込む。（Ｓ１６１）。
【００７８】
次に、動作２−２について説明する。
動作２−２は、エンジニアリング環境装置２からイベント検出装置１にイベント定義が書き込まれるたびに、イベント検出装置１の状態条件並び替え手段９がイベント定義蓄積手段５にイベント定義を出力する。そして、イベント定義蓄積手段５にイベント定義が蓄積される。
図１３は、この発明の実施の形態２における、イベント検出装置１の状態条件並び替え手段９の動作のフローチャートである。
まず、エンジニアリング環境装置２からイベント検出装置１に書き込まれた（入力された）イベント定義を、イベント検出装置１の状態条件並び替え手段９が受信（取得）する（Ｓ２７０）。
【００７９】
次に、状態条件並び替え手段９は、Ｓ２７０において取得したイベント定義の、処理条件に含まれる状態条件に対して、条件成立確率蓄積手段１０の条件成立確率テーブルを参照して、各状態条件が真となる確率を抽出する（Ｓ２７１）。
尚、複数の条件成立確率テーブルが条件成立確率蓄積手段１０に蓄積されている場合には、条件成立確率切替手段１１によって有効とされた条件成立確率テーブルが参照される。
【００８０】
次に、状態条件並び替え手段９は、各状態条件に対し、イベント定義の中で、状態条件が真となる確率が低い順に順位をつけ、その順位に従って昇順に状態条件番号を設定する。（Ｓ２７２）。
最後に、状態条件並び替え手段９は、状態条件番号が設定されたイベント定義を、イベント定義蓄積手段５に出力する。そして、イベント定義蓄積手段５は、入力されたイベント定義を蓄積（記憶）する（Ｓ２７３）。
【００８１】
動作２−３については、実施の形態１で説明した、動作１−２と同様であるので、説明を省略する。
【００８２】
次に、実施の形態２における、イベント検出装置１とエンジニアリング環境装置２の動作を具体例で説明する。
イベント定義設定者が、図２のイベント定義Ｔ１０１を書き込む動作の例を、図１２のフローチャートを用いて説明する。この動作は、動作２−１に対応する。
まず、Ｓ１６０において、イベント定義設定者は、イベント定義入力手段８からイベント定義Ｔ１０１を入力する。
次に、Ｓ１６１において、イベント定義入力手段８は、イベント定義Ｔ１０１をイベント検出装置１に書き込む。
【００８３】
次に、図２のイベント定義Ｔ１０１が、エンジニアリング環境装置２からイベント検出装置１に書き込まれ、図１４のイベント定義Ｔ１３１とＴ１３２が蓄積されるまでの、状態条件並び替え手段９の動作の例を図１３のフローチャートを用いて説明する。
図１３は、この発明の実施の形態２における、イベント検出装置１の状態条件並び替え手段９の動作のフローチャートである。
また、図１４は、この発明の実施の形態２における、イベント検出装置１のイベント定義蓄積手段５に蓄積されるイベント定義の例である。
この例は、動作２−２に対応する。尚、条件成立確率蓄積手段１０は、図３に示す複数の条件成立確率テーブルＴ２０１とＴ２０２を蓄積しており、条件成立確率切替手段１１によって、条件成立確率テーブルＴ２０１が有効になっているものとする。
【００８４】
まず、Ｓ２７０において、イベント検出装置１の状態条件並び替え手段９は、エンジニアリング環境装置２から書き込まれたイベント定義Ｔ１０１を取得する。
次に、Ｓ２７１において、状態条件並び替え手段９は、条件成立確率蓄積手段１０の条件成立確率テーブルＴ２０１を参照し、イベント定義Ｔ１０１の各状態条件が真となる確率を抽出する。したがって、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件が真となる確率は「１１％」、「｛操舵角｝が１０度より大きい」という状態条件が真となる確率は「１０％」、「｛気温｝が０℃より低い」という状態条件が真となる確率は「５％」という確率が抽出される。
【００８５】
次に、Ｓ２７２において、状態条件並び替え手段９は、状態条件が真となる確率が低い順に順位をつけ、その順位に従って昇順に、イベント定義Ｔ１０１に含まれる状態条件番号を設定する。５％＜１０％＜１１％であるので、「｛気温｝が０℃より低い」という状態条件には「１」が、「｛操舵角｝が１０度より大きい」という状態条件には「２」が、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件には「３」が状態条件番号に設定される。
【００８６】
最後に、Ｓ２７３において、状態条件並び替え手段９は、状態条件番号が設定されたイベント定義Ｔ１３１をイベント定義蓄積手段５に出力し、イベント定義蓄積手段５は、状態条件が、真となる確率が低い順に、状態条件番号が並び替えられたイベント定義Ｔ１３１を蓄積する。
これにより、イベント定義Ｔ１３１に含まれる状態条件を判定するときには、状態条件番号の順、「｛気温｝が０℃より低い」→「｛操舵角｝が１０度より大きい」→「｛車速｝が８０ｋｍ／ｈ以上」、で状態条件が判定されることになる。
【００８７】
一方、条件成立確率切替手段１１によって条件成立確率テーブルＴ２０２が有効になっているときの、状態条件並び替え手段９の動作は以下のようになる。
まず、Ｓ２７０において、状態条件並び替え手段９は、エンジニアリング環境装置２のイベント定義入力手段８から書き込まれた、イベント定義Ｔ１０１を取得する。
【００８８】
次に、Ｓ２７１において、状態条件並び替え手段９は、条件成立確率蓄積手段１０の条件成立確率テーブルＴ２０２を参照し、イベント定義Ｔ１０１の各状態条件が真となる確率を抽出する。したがって、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件が真となる確率は「０．１％」、「｛操舵角｝が１０度より大きい」という状態条件が真となる確率は「１０％」、「｛気温｝が０℃より低い」という状態条件が真となる確率は「５％」が抽出される。
【００８９】
次に、Ｓ２７２において、状態条件並び替え手段９は、イベント定義の中で、状態条件が真となる確率が低い順に順位をつけ、その順位に従って昇順に、イベント定義Ｔ１０１に含まれる状態条件番号を設定する。０．１％＜５％＜１０％であるので、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件には「１」が、「｛気温｝が−１０℃より低い」という状態条件には「２」が、「｛操舵角｝が１０度より大きい」という状態条件には「３」が状態条件番号に設定される。
【００９０】
最後に、Ｓ２７３において、状態条件並び替え手段９は、状態条件番号が設定されたイベント定義Ｔ１３２をイベント定義蓄積手段５に出力し、イベント定義蓄積手段５は、状態条件が、真となる確率が低い順に、状態条件番号が並び替えられたイベント定義Ｔ１３２を蓄積する。
これにより、イベント定義Ｔ１３２に含まれる状態条件を判定するときには、状態条件番号の順、「｛車速｝が８０ｋｍ／ｈ以上」→「｛気温｝が０℃より低い」→「｛操舵角｝が１０度より大きい」で、状態条件が判定されることになる。
【００９１】
「｛車速｝が８０ｋｍ／ｈ以上」という状態条件の成立確率（条件成立確率）は０．１％であるので、イベント定義Ｔ１３２に含まれる状態条件の判定回数はほとんどの場合で１回となり、個々のイベント定義の判定時間が削減できることが期待できる。
尚、自動車の動作中に、条件成立確率切替手段１１によって有効である条件成立確率テーブルが切り替えられた場合には、イベント定義蓄積手段５に蓄積されているすべてのイベント定義が、Ｓ２７０において再度入力されたとして、Ｓ２７０〜Ｓ２７３の動作を繰り返す。そうすることで、新たに有効になったその条件成立確率テーブルにしたがって状態条件の状態条件番号を設定し直す。
【００９２】
以上の様に、ドライバーの運転の仕方、運転する地域または気候に応じて、イベント検出装置１の条件成立確率蓄積手段１０に蓄積されている条件成立確率テーブルを切り替えて、条件成立確率テーブルの条件成立の確率を参照して、イベント定義の状態条件番号を、状態条件が真となる確率が低い順に並び替えて、イベント定義蓄積手段５に蓄積するので、ドライバーの運転の仕方、運転する地域または気候に応じて処理条件を早く判定することができる。したがって、ドライバーの運転の仕方、運転する地域または気候に応じて、運転手に必要な報知を早くすることができる。
【００９３】
実施の形態３．
自動車の状態情報が時間的な相関性をもち、処理周期程度の時間では、自動車の状態情報の変化量が小さいと考えられるとき、状態条件の判定結果が変化する確率は低い。したがって、状態条件が一度偽となったとき、次の判定周期でも状態条件が偽となる可能性が高い。そこで本構成では、偽になった状態条件を登録する判定状態蓄積手段を配置し、前回の判定で偽になった状態条件から処理条件の判定ができるようにする。
【００９４】
図１５は、この発明の実施の形態３における、イベント検出装置１の構成図である。
実施の形態３におけるイベント検出装置１、エンジニアリング環境装置２、センサ３、および外部装置４の接続関係は、実施の形態１と同様である。
実施の形態３におけるイベント検出装置１は、イベント定義蓄積手段５、状態情報収集手段６、処理条件判定手段７、状態条件並び替え手段９、条件成立確率蓄積手段１０、条件成立確率切替手段１１、判定状態蓄積手段１２から構成されている。
また、エンジニアリング環境装置２は、イベント定義入力手段８から構成されている。
判定状態蓄積手段１２は、判定状態記憶手段に相当する。
【００９５】
エンジニアリング環境装置２のイベント定義入力手段８は、実施の形態２と同様であるため、説明を省略する。
また、イベント検出装置１のイベント定義蓄積手段５、状態情報収集手段６、状態条件並び替え手段９、条件成立確率蓄積手段１０、条件成立確率切替手段１１も、実施の形態２と同様であるため、説明を省略する。
また、センサ３と外部接続４も、実施の形態１と同様であるため、説明を省略する。
【００９６】
イベント検出装置１の処理条件判定手段７は、イベント定義に含まれる処理条件の真偽を判定する。事前に定義された状態条件の判定順序で判定を行うが、処理条件が偽と判定された場合、偽と判定した状態条件の状態条件番号を判定状態蓄積手段１２に出力する。そして、次の判定周期の時、判定状態蓄積手段１２の蓄積データを参照して、前回の判定周期で偽となった状態条件の状態条件番号が蓄積されていれば、その状態条件番号の状態条件から処理条件の判定を開始する。また、処理条件判定手段７は、イベント定義に含まれる処理条件が真となったとき、外部装置４にその旨を通知し、イベント定義の処理内容を通知する。
【００９７】
イベント検出装置１の判定状態蓄積手段１２は、処理条件判定手段７でイベント定義の処理条件の判定処理において、偽となった状態条件番号が、処理条件判定手段７から入力され、イベント定義番号に対応して、入力された状態条件番号を蓄積する。判定状態蓄積手段１２には、イベント定義毎に、偽と判定された状態条件が蓄積されている。
以上が、実施の形態３の各構成要素についての説明である。
【００９８】
次に、実施の形態３における、イベント判定装置１とエンジニアリング環境装置２の動作を、以下の３つの動作に分けて説明する。
動作３−１：エンジニアリング環境装置２が、イベント定義設定者によって入力されたイベント定義をイベント検出装置１に設定する動作。
動作３−２：イベント検出装置１の状態条件並び替え手段９が、イベント定義を蓄積する動作。
動作３−３：イベント検出装置１の処理条件判定手段７が、センサ３から入力された状態情報の測定値に対して、イベント定義に含まれる処理条件で判定して、判定結果に応じて処理する動作。
【００９９】
動作３−１は、実施の形態２の動作２−１と同様、動作３−２は、実施の形態の動作２−２と同様であるため、説明を省略する。
動作３−３に関しては、動作１−２とほぼ同様であるが、図５のフローチャートと、Ｓ２５２の動作（図６の動作）の詳細が異なる。
図１６は、この発明の実施の形態３における、イベント検出装置１の処理条件判定手段７の動作のフローチャートである。
まず、処理条件判定手段７は、判定状態蓄積手段１２に、前回の判定周期で偽になった状態条件の状態条件番号が蓄積されているか否かを確認する。（Ｓ２８０）
【０１００】
Ｓ２８０において、状態条件番号が蓄積されていれば、前回の判定で偽になった状態条件番号の状態条件を読み込む（Ｓ２８１）。
Ｓ２８０において、状態条件番号が蓄積されていなければ、処理条件判定手段７は、処理条件に含まれている状態条件のうち、状態条件番号が「１」のイベント定義をイベント定義蓄積手段５から読み込む（Ｓ２８２）。
次に、読み込んだ状態条件を判定する、自動車の状態情報のデータを、状態情報収集手段６から取得する（Ｓ２８３）。この時、状態情報収集手段６には、センサ３から自動車の状態情報の測定値が入力されている。
【０１０１】
次に、Ｓ２８３で読み込んだ状態情報の測定値に対して、判定状態蓄積手段１２に蓄積されていた、前回の判定で偽になった状態条件番号、または状態条件番号が「１」のイベント定義の状態条件を判定する（Ｓ２８４）。
Ｓ２８４において状態条件が偽であれば、判定状態蓄積手段１２に状態条件番号を出力して蓄積し（Ｓ２８５）、処理条件が偽であると出力する。その結果、図５のＳ２５２の判定はＮｏとなるため、図５のＳ２５０にもどる。
Ｓ２８４において状態条件が真であれば、Ｓ２８６にすすむ。
【０１０２】
次に、処理条件の中に未判定の状態条件が存在するか確認する（Ｓ２８６）。
Ｓ２８６において未判定の状態条件が存在しない場合、処理条件が真であると出力する（Ｓ２８７）。処理条件が真と出力されると、図５のＳ２５２の判定はＹＥＳとなるため、外部装置４にイベント定義の処理内容が通知される。
Ｓ２８６において未判定の状態条件が存在する場合、イベント定義に付加された処理条件に含まれる状態条件のうち、次の状態条件を読み込み、Ｓ２８３にもどる（Ｓ２８８）。
【０１０３】
次に、実施の形態３における、イベント検出装置１とエンジニアリング環境装置２の動作を具体例で説明する。
処理条件判定手段７が、複数のイベント定義に含まれる処理条件の真偽を判定する動作の例を、図５と図１６のフローチャートを用いて説明する。
この動作は、動作３−３に対応する。尚、イベント定義蓄積手段５には、図９に示すイベント定義Ｔ１１１−Ｔ１１８が格納されており、また、判定状態蓄積手段１２には、状態条件番号が蓄積されていないものとして説明する。
【０１０４】
図１７は、この発明の実施の形態３における、イベント検出送位置１の状態情報収集手段６に収集された状態情報の測定値の具体例を示す図である。
図１７の（ａ）は、センサ３による１回目の測定値であり、図１７の（ｂ）は、センサ３による１回目の測定値である。
ここでは、ある処理周期で、センサ３からの状態情報の測定値として、図１７の（ａ）に示す値が測定されたものとして説明する。
【０１０５】
まず、図５のＳ２５０において、未判定のイベント定義が存在するので、Ｓ２５１にすすむ。
次に、Ｓ２５１において、イベント定義が一つ読み込まれる。どのイベント定義を読み込んでもよいが、ここではイベント定義Ｔ１１１が読み込まれたものとする。
次に、Ｓ２５２において、読み込んだ図９のイベント定義Ｔ１１１の処理条件を判定するため、Ｓ２５２の処理を詳細に説明した図１６にすすむ。
Ｓ２８０において、偽になった状態条件の状態条件番号が、判定状態蓄積手段１２に蓄積されているか否かを確認する。初めは、状態条件番号が蓄積されていないので、Ｓ２８２にすすむ。
【０１０６】
次に、Ｓ２８２において、処理条件に含まれている状態条件のうち、状態条件番号が「１」のもの、つまり、「｛気温｝が０℃より低い」を読み込む。
次に、Ｓ２８３において、状態情報収集手段６から、状態条件を判定する｛気温｝の測定値を読み込む。ここでは「−５℃」が読み込まれる。この時、状態情報収集手段６には、センサ３から自動車の状態の測定値が入力されている。
次に、Ｓ２８４において、状態条件を判定する。「−５℃」＜「０℃」は真であるので、Ｓ２８６にすすむ。
次に、Ｓ２８６において、次の状態条件、つまり、「｛操舵角｝が１０度より大きい」が読み込まれ、Ｓ２８３にすすむ。
【０１０７】
次に、Ｓ２８３において、状態情報収集手段６から、状態条件を判定する｛操舵角｝の測定値を読み込む。ここでは「４度」が読み込まれる。
次に、Ｓ２８４において、状態条件を判定する。「４度」＞「１０度」は偽であるので、Ｓ２８５にすすむ。
次に、Ｓ２８５において、処理条件判定手段７は、判定状態蓄積手段１２に状態条件番号「２」を登録する。そして、処理条件が偽であると出力し、その結果、図５のＳ２５２の判定はＮＯとなるため、図５のＳ２５０にもどる。
【０１０８】
以降、未判定のイベント定義が存在しなくなるまで、Ｓ２５０からＳ２５３の動作が繰り返される。
イベント定義蓄積手段５に存在する、イベント定義Ｔ１１１−Ｔ１１８が判定されると、判定状態蓄積手段１２には、図１８に示す様に、イベント定義番号に対応して、偽と判定された状態条件の状態条件番号が蓄積される。
図１８は、この発明の実施の形態３における、イベント検出装置１の判定状態蓄積手段１２に蓄積された状態条件番号の例を示す図である。
【０１０９】
以上の動作では、状態条件の判定を１２回行うことになる。
一つの状態条件の判定に１単位時間要するとすると、すべてのイベント定義を判定するのに１２単位時間を要する。
さらに、以上の動作ののち、次の処理周期の測定値として、図１７の（ｂ）に示す値が測定されたものとして、処理条件判定手段７が複数のイベント定義に含まれる処理条件の真偽を判定する動作の例を、図５と図１６のフローチャートを用いて説明する。
まず、Ｓ２５０において、未判定のイベント定義が存在するので、Ｓ２５１にすすむ。
【０１１０】
次に、Ｓ２５１において、イベント定義が一つ読み込まれる。どのイベント定義を読み込んでもよいが、ここではイベント定義Ｔ１１１が読み込まれたものとする。
次に、Ｓ２５２において、読み込んだイベント定義Ｔ１１１の処理条件を判定するため、Ｓ２５２の処理を詳細に説明した図１６にすすむ。
Ｓ２８０において、偽になった状態条件の状態条件番号が、判定状態蓄積手段１２に蓄積（登録）されているか否かを確認する。判定状態蓄積手段１２には状態条件番号が登録されているので、Ｓ２８１にすすむ。
【０１１１】
次に、Ｓ２８１において、前回の判定で偽になった状態条件、状態条件番号「２」をもつ、「｛操舵角｝が１０度より大きい」を読み込む。
次に、Ｓ２８３において、状態情報収集手段６から、状態条件が参照する｛操舵角｝の測定値を読み込む。ここでは「３度」が読み込まれる。この時、状態情報収集手段６には、センサ３から自動車の状態の測定値が入力されている。
次に、Ｓ２８４において、状態条件を判定する。「３度」＞「１０度」は偽であるので、Ｓ２８５にすすむ。
【０１１２】
次に、Ｓ２８５において、処理条件判定手段７は、判定状態蓄積手段１２に状態条件番号「２」を登録する。そして、処理条件が偽であると出力し、その結果、図５のＳ２５２の判定はＮＯとなるため、図５のＳ２５０にもどる。
以降、未判定のイベント定義が存在しなくなるまで、Ｓ２５０からＳ２５３の動作が繰り返される。
【０１１３】
以上の動作の場合、自動車の状態情報の値の変化量が小さいと考えられるとき、すべてのイベント定義が、１回の状態条件で判定できるので、状態条件の判定を８回行えば済むことになる。状態条件の判定に１単位時間要するとすると、すべてのイベント定義を判定するのに８単位時間で済み、初回の判定周期と比べて、判定時間を低減できる。
【０１１４】
即ち、自動車の状態情報が時間的な相関性をもち、処理周期程度の時間では、自動車の状態情報の変化量が小さいような場合、イベント定義毎に、状態条件の判定で偽となった状態条件の状態条件番号を蓄積しておく。そうすることで、次に同じイベント定義の処理条件を判定する際に、その蓄積されている状態条件番号の状態条件から判定するので、イベント定義の状態条件の判定回数を削減することができ、イベント定義の処理内容を報知するタイミングを早くすることができる。
【０１１５】
実施の形態４．
実施の形態３では、前回、偽になった状態条件を記録することで、処理条件一つ当たりの判定時間の期待値を低減させた。
本実施の形態４では、複数のイベント定義に、同一の状態情報を判定する状態条件が含まれていることを利用して、同一の状態情報を含むイベント定義の状態条件をまとめて判定して、処理条件を判定する処理時間を短縮する例について説明する。
【０１１６】
あるイベント定義の状態条件が偽であると判定されたとき、他のイベント定義の、同一の状態情報の状態条件の真偽も明らかになる処理条件がある。即ち、あるイベント定義の状態条件が偽であると判定されると、他のイベント定義の同一の状態情報の状態条件を含む処理条件も、偽であると判定できる。
ここでは、同一の状態情報の状態条件を判定するために、同一の状態情報の状態条件を含む処理条件を集約する条件クラス登録手段を配置する。そして、条件クラス判定手段によって、集約した処理条件をまとめて判定することにより、さらに処理条件の判定時間を低減できるようにする。
この実施の形態４における状態条件は、既に述べた性質に加えて、状態情報と比較する値の候補が、有限個の値に限定される。
【０１１７】
図１９は、この発明の実施の形態４における、イベント検出装置１の構成図である。
実施の形態４におけるイベント検出装置１、エンジニアリング環境装置２、センサ３、および外部装置４の接続関係は、実施の形態１と同様である。
実施の形態４におけるイベント検出装置１は、イベント定義蓄積手段５、状態情報収集手段６ｂ、処理条件判定手段７ｂ、状態条件並び替え手段９、条件成立確立蓄積手段１０、条件成立確率切替手段１１、条件クラス蓄積手段１３、条件クラス判定手段１４、条件クラス登録手段１５から構成されている。
また、エンジニアリング環境装置２は、イベント定義入力手段８から構成されている。
条件クラス蓄積手段１３は、条件クラス記憶手段１３に相当する。
【０１１８】
次に、各構成要素について説明する。
エンジニアリング環境装置２のイベント定義入力手段８は、実施の形態２と同様であるため、説明を省略する。
また、イベント検出装置１のイベント定義蓄積手段５、状態条件並び替え手段９、条件成立確率蓄積手段１０、条件成立確率切替手段１１も、実施の形態２と同様であるため、説明を省略する。
また、センサ３と外部接続４も、実施の形態１と同様であるため、説明を省略する。
【０１１９】
イベント検出装置１の条件クラス蓄積手段１３は、条件クラステーブルを蓄積する。条件クラステーブルとは、ある特定の状態情報の状態条件に、イベント定義番号を関連付けたものである。
図２０は、この発明の実施の形態４における、条件クラステーブルの例を示す図である。
【０１２０】
条件クラステーブルは、状態情報（状態情報の種類）、状態条件、イベント定義番号から構成される。状態情報の種類とは、例えば｛車速｝、｛操舵角｝、｛気温｝、｛アクセス開度｝、｛ブレーキ踏度｝、｛ウィンカー｝のことである。
条件クラステーブルには、処理条件判定手段７ｂで、状態条件が偽と判定されたイベント定義番号が、状態情報と状態条件に関連付けて、記憶されている。
例えば、図２０の条件クラステーブルＴ４０１では、３０個のイベント定義番号が、１７の状態条件に関連付けられている。
【０１２１】
図２０の条件クラステーブルＴ４０1では、例えば、状態情報｛車速｝に関して、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件に関連付けられているのは、イベント定義番号１、３、７である。
また、「｛車速｝が３０ｋｍ／ｈ以上」という状態条件に関連付けられているのは、イベント定義番号２、４、６、８である。
また、「｛車速｝が１０ｋｍ／ｈ以上」という状態条件に関連付けられているのは、イベント定義番号５である。
また、「｛操舵角｝が２０度より大きい」、という状態条件に関連付けられているのは、イベント定義番号１６、１９、２６、２８である。
【０１２２】
イベント定義番号「１」をもつ図９のイベント定義Ｔ１０１は、イベント定義Ｔ１０１がもつ３つの状態条件のうち、「｛車速｝が８０ｋｍ／ｈ以上」という状態条件が、図２０の条件クラステーブルに関連付けられている。イベント定義Ｔ１０１がもつ他の状態条件「｛気温｝が０℃より低い」や「｛操舵角｝が１０度より大きい」にイベント定義番号「１」を関連付けることもあるが、ここでは、一つのイベント定義番号は、状態条件番号「１」の一つの状態条件のみに関連付けられるとする。
【０１２３】
条件クラス判定手段１４は、状態情報収集手段６ｂから入力される、自動車の状態情報の測定値に対して、条件クラス蓄積手段１３の条件クラステーブルを用いて、偽となる確率が高い状態条件から、まとめて判定する。そして、状態条件が真と判定されると、イベント定義蓄積手段５のイベント定義を参照して、真と判定された状態条件に関連付けられたイベント定義番号と、そのイベント定義の状態条件の状態条件番号を処理条件判定手段７ｂに出力する。
【０１２４】
条件クラス登録手段１５は、条件クラス蓄積手段１３の条件クラステーブルの状態情報と状態条件に対して、初期値のイベント定義番号を登録する。条件クラス登録手段１５は、イベント定義蓄積手段５に蓄積されているイベント定義を参照して、状態条件番号「１」が定義されている状態条件、または偽となる確率が高い状態条件に対応付けて、イベント定義番号を条件クラス蓄積手段１３の条件クラステーブルに登録する。
【０１２５】
処理条件判定手段７ｂは、状態情報収集手段６から入力される、自動車の状態情報の測定値に対して、条件クラス判定手段１４から入力されたイベント定義番号の状態条件の次の状態条件を判定する。そして、イベント定義の処理条件が真であると判定すると、外部装置４にその旨を通知する。更に、外部装置４に対して、その実行に必要な情報を送出する。また、イベント定義の処理条件が偽であると判定すると、その状態情報の状態条件について、条件クラステーブルの対応する状態情報、状態条件に、イベント定義番号を記憶する。
処理条件判定手段７ｂでは、条件クラス判定手段１４でまとめて偽であることを判定した、状態条件については判定しないため、イベント定義を判定する処理時間を短縮することができる。
【０１２６】
状態情報収集手段６ｂは、センサ３から入力された自動車の状態情報の測定値を、条件クラス判定手段１４と処理条件判定手段７ｂに出力する。
【０１２７】
実施の形態４における、イベント検出装置１とエンジニアリング環境２の動作を、以下に示す五つの動作に区分して、説明する。
動作４−１：エンジニアリング環境装置２が、イベント定義設定者によって入力されたイベント定義をイベント検出装置１に設定する動作。
動作４−２：イベント検出装置１の状態条件並び替え手段９が、イベント定義を蓄積する動作
動作４−３：イベント検出装置１の条件クラス登録手段１５が、イベント定義の状態条件を分類する動作
動作４−４：イベント検出装置１の条件クラス判定手段１４が、センサ３から入力された状態情報の測定値に対して、複数のイベント定義に含まれる状態条件をまとめて判定する動作
動作４−５：イベント検出装置１の処理条件判定手段７ｂが、センサ３から入力された状態情報の測定値に対して、条件クラス判定手段１４から通知されたイベント定義の状態条件を判定し、判定結果に応じて処理する動作。
【０１２８】
次に、各動作について詳細に説明する。
動作４−１に関しては、動作２−１と同様であり、動作４−２に関しては、動作２−２と同様であるため、説明を省略する。
【０１２９】
まず、動作４−３、イベント検出装置１の条件クラス登録手段１５の動作について、詳細に説明する。
図２１は、この発明の実施の形態４における、イベント検出装置１の条件クラス登録手段１５の動作を示すフローチャートである。
条件クラス登録手段１５は、イベント定義蓄積手段５の各イベント定義に対して、状態条件番号「１」が定義されている状態条件の、状態情報の種類に応じて、条件クラス蓄積手段１３の条件クラステーブルに、そのイベント定義番号を登録する（Ｓ２７４）。
【０１３０】
条件クラス登録手段１５は、条件成立確率蓄積手段１０が有効になっている条件成立確率テーブルを参照して、イベント定義蓄積手段５の各イベント定義に対して、条件成立確率が低い（偽となりやすい）状態条件の、状態情報の種類に応じて、条件クラス蓄積手段１３の条件クラステーブルに、イベント定義番号を登録してもよい。
【０１３１】
次に、動作４−４（イベント検出装置１の条件クラス判定手段１４の動作）について、詳細に説明する。
図２２は、この発明の実施の形態４における、イベント検出装置１の条件クラス判定手段１４の動作を示すフローチャートである。
この動作は、例えば、図７に示すような事前に定義された一定の周期毎に、条件クラス判定手段１４が行う。
まず、条件クラス判定手段１４は、状態情報収集手段６ｂから入力された状態情報の種類を任意に一つ選択する。（Ｓ３００）。ここで選択した状態情報の種類を、注目状態情報と呼ぶ。
【０１３２】
次に、条件クラス判定手段１４は、Ｓ３００で選択した状態情報の種類を判定する状態条件の中で、条件クラス蓄積手段１３の条件クラステーブルのイベント定義番号に、一つ以上のイベント定義番号が登録されている状態条件の中から、他のすべての状態条件を包含する（他のすべての状態条件が成立する）状態条件を判定し、その状態条件を読み込む。他のすべての状態条件を包含する状態条件が存在しない場合、状態条件を一つ任意に選択し、読み込む（Ｓ３０１）。
【０１３３】
他のすべての状態条件を包含する状態条件とは、その状態条件が真であれば、他のすべての状態条件が常に真となる状態条件のことをいう。
たとえば、「｛車速｝が８０ｋｍ／ｈ以上」「｛車速｝が３０ｋｍ／ｈ以上」「｛車速｝が１０ｋｍ／ｈ以上」の３つの状態条件があるとき、「｛車速｝が８０ｋｍ／ｈ以上」が真となれば、他の２状態条件は常に真となる。このとき、「｛車速｝が８０ｋｍ／ｈ以上」の状態条件は、他のすべての状態条件を包含するといえる。
【０１３４】
次に、条件クラス判定手段１４は、読み込んだ状態条件を判定する、自動車の状態情報の測定値を、状態情報収集手段６ｂから読み込む（Ｓ３０２）。
次に、条件クラス判定手段１４は、Ｓ３０２で読み込んだ状態情報の測定値を用いて、Ｓ３０１で読み込んだ状態条件が偽か否かを判定する（Ｓ３０３）。
Ｓ３０３において判定結果が偽となった場合、読み込んだ状態条件を除いて、条件クラステーブルに、一つ以上のイベント定義が登録されている状態条件が、存在するか否かを確認する（Ｓ３０４）。
Ｓ３０３で判定結果が偽となれば、偽と判定した状態情報の状態条件に対応して、条件クラステーブルに記憶されているイベント定義番号の、イベント定義の状態条件をすべて偽として判定したものとして、次の状態条件を判定することになる。
【０１３５】
Ｓ３０４において状態条件が存在する場合、既に読み込んだ状態条件を除いた状態条件の中で、他のすべての状態条件を包含する状態条件を読み込み、Ｓ３０３に戻る。また、他のすべての状態条件を包含する状態条件が存在しない場合、既に読み込んだ状態条件以外で、一つ任意に選択し読み込む（Ｓ３０５）。
Ｓ３０４において状態条件が存在しない場合、この注目状態情報に関する処理を終了する。
【０１３６】
Ｓ３０５からＳ３０３に戻り、Ｓ３０３において判定結果が偽ではない（真である）場合、図２０の条件クラステーブルで、その状態条件に関連付けられたイベント定義番号と、イベント定義番号が割り当てられたイベント定義の中における、注目状態情報を判定する状態条件番号を処理条件判定手段７ｂに通知する（Ｓ３０６）。
Ｓ３０６に続けて、読み込んだ状態条件に包含されている、状態条件に関連付けられたイベント定義番号と、イベント定義番号が割り当てられたイベント定義の中の、注目状態情報を参照する状態条件番号を、処理条件判定手段７ｂに通知する（Ｓ３０７）。
状態情報のすべての種類について、Ｓ３００からＳ３０７までの動作を繰り返す。
【０１３７】
次に、動作４−５（イベント検出装置１の処理条件判定手段７ｂの動作）について説明する。
図２３は、この発明の実施の形態４における、イベント検出装置１の処理条件判定手段７ｂの動作を示すフローチャートである。
この動作は、処理条件判定手段７ｂが、条件クラス判定手段１４から、イベント定義番号と状態条件番号を通知されたときに、処理条件判定手段７ｂが行う。
まず、処理条件判定手段７ｂは、条件クラス判定手段１４から通知されたイベント定義番号をもつイベント定義を、イベント定義蓄積手段５から、一つ読み込む（Ｓ３１０）。
【０１３８】
次に、読み込んだイベント定義に記載された、処理条件が真であるか否か（処理条件が成立するか否か）を判定する（Ｓ３１１）。この動作の詳細は、後で詳述する。
Ｓ３１１において処理条件が真であれば、処理条件判定手段７ｂは、処理内容を外部装置４に通知する（Ｓ３１２）。
Ｓ３１１において処理条件が真でなければ、Ｓ３１０にもどる。そして、通知されたすべてのイベント定義番号について処理したとき、動作を終了する。
【０１３９】
ここで、Ｓ３１１において、処理条件判定手段７ｂが、処理条件が真であるか否かを判定する動作について詳細に説明する。
図２４は、この発明の実施の形態４における、イベント検出装置１の処理条件判定手段７ｂが、処理条件が真であるか否かを判定する（図２３のＳ３１１の）動作を詳細に示したフローチャートである。
【０１４０】
まず、処理条件判定手段７ｂは、条件クラス判定手段１４から通知された状態条件番号を一つ増やして、一時記憶領域に記憶する。その状態条件番号が存在しない場合には、１を一時記憶領域に記憶する。（Ｓ３２０）。ここで、条件クラス判定手段１４から通知された状態条件番号を一つ増やすことにより、条件クラス判定手段１４から通知された状態条件番号は、既に条件クラス判定手段１４で偽であると判定済みとして、処理条件判定手段７ｂは、通知された状態条件番号の次の状態条件番号の状態条件を判定する。
【０１４１】
次に、処理条件判定手段７ｂは、Ｓ３２０で一時記憶領域に記憶した、状態条件番号に関連付けられた状態条件を読み込む（Ｓ３２１）。
そして、処理条件判定手段７ｂは、Ｓ３２１で読み込んだ状態条件について判定する、自動車の状態情報の測定値を、状態情報収集手段６ｂから読み込む（Ｓ３２２）。
【０１４２】
次に、処理条件判定手段７ｂは、Ｓ３２２で読み込んだ状態情報の測定値に対して、状態条件を判定する（Ｓ３２３）。
Ｓ３２３において状態条件が偽であれば、処理条件判定手段７ｂは、条件クラス蓄積手段１３の条件クラステーブルに、イベント定義の番号を登録し（Ｓ３２４）、処理条件が偽であることを一時記憶領域に出力する（Ｓ３２５）。そして、図２４のＳ３１１に戻り、処理条件は真ではないため、処理条件判定手段７ｂは動作を終了し、外部装置４への通知は行われない。
Ｓ３２３において状態条件が真であれば、未判定の状態条件があるか否かを判定する（Ｓ３２６）。このとき、条件クラス判定手段１４において、既に判定した状態条件は、判定済として扱う。
【０１４３】
Ｓ３２６において未判定の状態条件が存在しない場合、処理条件が真であることを一時記憶領域に出力する（Ｓ３２７）。そして、図２３のＳ３１１に戻り、処理条件は真であるため、Ｓ３１２にすすむ。そして、処理条件判定手段７ｂは、処理条件が真であることと、イベント定義の処理内容を、外部装置４に通知する。
Ｓ３２６において未判定の状態条件が存在する場合、処理条件に含まれる状態条件のうち、次の状態条件を読み込むＳ３２１にもどる。
以上が、動作４−１、動作４−２、動作４−３、動作４−４の説明である。
【０１４４】
次に、実施の形態４における、イベント検出装置１の動作を具体例で説明する。
まず、イベント検出装置１の条件クラス判定手段１４が、複数のイベント定義に含まれる状態条件をまとめて判定する動作の例を、図２２のフローチャートを用いて説明する。この動作は、動作４−４に対応する。
尚、図２０に示す条件クラス蓄積手段１３の条件クラステーブルＴ４０１が、条件クラス蓄積手段１３に蓄積されている。また、イベント定義蓄積手段５に少なくとも図９に示すイベント定義Ｔ１１１−Ｔ１１８が蓄積されており、ある処理周期の状態情報の測定値として、図２５に示す値が測定されているものとする。
図２５は、この発明の実施の形態４における、イベント検出装置１の状態情報収集手段６ｂに収集された自動車の状態情報の測定値の具体例を示す図である。
【０１４５】
まず、図２２のＳ３００において、イベント検出装置１の条件クラス判定手段１４は、状態情報の種類を任意に一つ選択する。ここでは、｛車速｝を選択したものとする。
｛車速｝について判定する状態条件の中で、条件クラステーブルに一つ以上のイベント定義番号が登録されているものは、「｛車速｝が８０ｋｍ／ｈ以上」「｛車速｝が３０ｋｍ／ｈ以上」「｛車速｝が１０ｋｍ／ｈ以上」の３つ状態条件である。このうち、「｛車速｝が８０ｋｍ／ｈ以上」が真であれば、他の２つの状態条件は常に真となるので、「｛車速｝が８０ｋｍ／ｈ以上」なる状態条件は、他のすべての状態条件を包含する。したがって、「{車速}が８０ｋｍ／ｈ以上」が、他の状態条件を全て包含する状態条件となる。
そのため、Ｓ３０１において、条件クラス判定手段１４は、他のすべての状態条件を包含する状態条件として、「{車速}が８０ｋｍ／ｈ以上」を読み込む。
【０１４６】
次に、Ｓ３０２において、条件クラス判定手段１４は、読み込んだ状態条件を判定する状態情報の｛車速｝の測定値を、状態情報収集手段６ｂから読み込む。このとき、図２５に示した測定値「６０ｋｍ／ｈ」が読み込まれる。
そして、Ｓ３０３において、条件クラス判定手段１４は、読み込んだ｛車速｝の状態情報の測定値に対して、状態条件を判定する。「６０ｋｍ／ｈ」＞「８０ｋｍ／ｈ」は偽であるため、Ｓ３０４にすすむ。
ここで、Ｓ３０４にすすむことにより、条件クラステーブルに記憶されている状態条件「{車速}が８０ｋｍ／ｈ以上」のイベント定義番号の１，３，７をまとめて偽であると判定したことになる。
【０１４７】
次に、Ｓ３０４において、既に読み込んだ状態条件を除いて、条件クラステーブルＴ４０１に、一つ以上のイベント定義番号が登録されている状態条件が存在するか確認する。「｛車速｝が３０ｋｍ／ｈ以上」なる状態条件には、一つ以上のイベント定義番号が登録されているので、Ｓ３０５にすすむ。
【０１４８】
次に、Ｓ３０５において、既に読み込んだ状態条件、すなわち、「｛車速｝が８０ｋｍ／ｈ以上」をのぞいて、他のすべての状態条件を包含する、「｛車速｝が３０ｋｍ／ｈ以上」という状態条件を読み込む。そしてＳ３０３にもどる。
【０１４９】
次に、Ｓ３０３において、条件クラス判定手段１４は、「｛車速｝が３０ｋｍ／ｈ以上」の状態条件を判定する。「６０ｋｍ／ｈ」＞「３０ｋｍ／ｈ」は偽ではないので、Ｓ３０６にすすむ。
【０１５０】
次に、Ｓ３０６において、条件クラス判定手段１４は、「｛車速｝が３０ｋｍ／ｈ以上」に割り当てられたイベント定義番号と、その番号が割り当てられたイベント定義において、「｛車速｝が３０ｋｍ／ｈ以上」の状態条件番号を、処理条件判定手段７ｂに出力する。つまり、イベント定義番号「２、４、６、８」と、それぞれに対して「｛車速｝が３０ｋｍ／ｈ以上」の状態条件番号「３、３、２、３」を、条件クラス判定手段１４は処理条件判定手段７ｂに出力する。
【０１５１】
最後に、Ｓ３０７において、条件クラス判定手段１４は、「｛車速｝が３０ｋｍ／ｈ以上」に包含されている状態条件に割り当てられた番号と、その番号が割り当てられたイベント定義において、包含されている状態条件の判定の順位をあらわす状態条件番号を、処理条件判定手段７ｂに出力する。包含されている状態条件は「｛車速｝が１０ｋｍ／ｈ以上」のみであるので、イベント定義番号５と、それに対して、状態条件番号３を処理条件判定手段７ｂに通知する。
条件クラステーブルＴ４１０に記載されている、他の状態情報の種類の、｛操舵角｝、｛気温｝、｛アクセル開度｝、｛ブレーキ踏度｝、｛ウィンカー｝に対してもＳ３００−Ｓ３０７の動作を行う。
【０１５２】
次に、イベント検出装置１の処理条件判定手段７ｂが、イベント定義に含まれる処理条件が真になったときに、処理内容の通知を、外部装置４に行う動作の例を、図２３と図２４のフローチャートを用いて説明する。この動作は、動作４−５に対応する。
尚、少なくともイベント定義蓄積手段５にイベント定義Ｔ１１１−Ｔ１１８が蓄積されているとする。また、センサ３から状態情報収集手段６ｂに、ある処理周期の状態情報の測定値として、図２５に示す値が測定され、条件クラス判定手段１４からイベント定義番号「２」と、状態条件番号「３」が通知されるとする。
【０１５３】
このとき、図２３のＳ３１０とＳ３１１は、以下のような動作となる。
まず、Ｓ３１０において、処理条件判定手段７ｂは、イベント定義を一つ読み込む。イベント定義番号「２」が通知されるので、イベント定義Ｔ１１２が読み込まれる。
次に、Ｓ３１１において、処理条件判定手段７ｂは、読み込んだイベント定義Ｔ１１２の処理条件を判定するため、Ｓ３１１の処理を詳細に説明した図２４にすすむ。
【０１５４】
図２４のＳ３２０において、状態条件番号「３」に１を加えた状態条件番号「４」は、イベント定義Ｔ１１２に存在しないため、状態条件番号「１」とする。
この時、状態条件番号「３」は、条件クラス判定手段１４によって、既に真であると判定されているため、処理条件犯値手段７ｂでは、状態条件番号「３」の次の、判定の順位の状態条件番号を判定する。
次に、Ｓ３２１において、処理条件判定手段７ｂは、イベント定義蓄積手段５を参照して、イベント定義Ｔ１１２の状態条件番号「１」をもつ状態条件「｛気温｝がー１０℃より低い」を読み込む。
【０１５５】
次に、Ｓ３２２において、処理条件判定手段７ｂは、状態情報収集手段６ｂから、状態条件を判定する｛気温｝の測定値を読み込む。ここでは「−５℃」が読み込まれる。
次に、Ｓ３２３において、処理条件判定手段７ｂは、状態条件を判定する。「−５℃」＜「−１０℃」は偽であるので、Ｓ３２４にすすむ。
【０１５６】
次に、Ｓ３２４において、処理条件判定手段７ｂは、条件クラス蓄積手段１３の条件クラステーブルＴ１４１の、「｛気温｝が−１０℃より低い」という状態条件に、イベント定義番号「２」を関連付ける。
そして、Ｓ３２５において、処理条件判定手段７ｂは、処理条件は偽（真ではない）として、図２３のＳ３１１に戻る。
そして、図２３のＳ３１１において、処理条件は真ではないため、処理を終了する。
【０１５７】
以上のように、条件クラス蓄積手段１３に蓄積されている状態条件と、状態条件を含むイベント定義番号を用いて、条件クラス判定手段１４が、状態情報の測定値に対して、状態条件をまとめて判定するので、処理速度を短縮することができる。また、１回の処理周期に処理するイベント定義の判定を多くすることができるため、イベント定義の処理内容の報知が必要な、処理内容の報知を早くすることができる。
【０１５８】
実施の形態５．
実施の形態２から実施の形態４では、イベント検出装置１をエンジニアリング環境２に接続した例を示したが、イベント検出装置１を接続するシステムは、エンジニアリング環境２に限定されない。その具体例を本実施の形態５で示す。実施の形態５で示す構成は、あくまでも概念的なものであり、同一ハードウェアや一体したソフトウェアで実現してもよい。
【０１５９】
実施の形態５では、車載ネットワークに接続されているセンサの情報に関して、必要な情報のみを、必要な条件を満たしたときのみに、イベント検出装置１が、先進運転支援システム（ＡＤＡＳ：Ａｄｖａｎｃｅｄ  Ｄｒｉｖｅｒ  Ａｓｓｉｓｔａｎｃｅ  Ｓｙｓｔｅｍｓ）の先進運転支援装置（ＡＤＡＳ装置）に通知するの例を示す。
ＡＤＡＳ装置とは、自動車にレーダやカメラ、赤外線センサ等のセンサデバイスを搭載して、自動車周囲の状況を判断し、運転手に適切な情報の報知を行ったり、あるいは自動車の制御を行ったりするものである。
【０１６０】
図２６は、この発明の実施の形態５における、ＡＤＡＳ装置に接続されたイベント検出装置１の構成図である。
実施の形態５におけるイベント検出装置１は、センサ３、ＡＤＡＳ装置１６、情報収集装置１７に接続されている。
イベント検出装置１は、車載報知装置に相当する。
実施の形態５におけるイベント検出装置１は、ＡＤＡＳ装置１６から入力されるイベント定義を、状態条件が真となる確率が低い順に蓄積し、センサ３から入力される状態情報のイベントの条件を判定する。そして、判定した結果を例えばドライブレコーダのような情報収集装置１７に出力する。
【０１６１】
ＡＤＡＳ装置１６は、情報収集装置１７から入力される自動車の状態情報に応じてイベント定義を変更し、変更したイベント定義をイベント検出装置１に出力する。
情報収集装置１７には、車載レーダ、ドライバーのブレーキ操作情報などの状態情報が入力され、一定期間の状態情報が記憶されている。そして、イベント検出装置１から、あるイベント定義が成立した判定結果が入力されると、その判定された時点から一定期間記憶されていた状態情報をＡＤＡＳ装置に出力する。
そして、ＡＤＡＳ装置は、この情報収集装置１７から入力される状態情報に基づいて、イベント定義を変更する。
【０１６２】
情報収集装置１７は、イベント検出装置１の判定結果に基づいて、イベント定義の処理条件が成立した時に、情報収集装置１７に入力される車載レーダ、またはドライバーのブレーキ操作情報などの自動車の状態情報をＡＤＡＳ装置１６に出力する。
そして、ＡＤＡＳ装置１６は、情報収集装置１７から入力された自動車の状態情報に応じて、イベント定義を変更する。そしてこの変更されたイベント定義が、イベント装置１に入力され、変更されたイベント定義を判定する。
実施の形態５では、この様に、ＡＤＡＳ装置で、動的に変更されるイベント定義に対して、イベント検出装置１がその変更されたイベント定義を判定する例について説明する。
【０１６３】
本実施の形態５のイベント検出装置１は、図２６に示すように、イベント定義蓄積手段５、状態条件収集手段６、処理条件判定手段７ｂ、状態条件並び替え手段９、条件成立確率蓄積手段１０、条件成立確率切替手段１１、条件クラス蓄積手段１３、条件クラス判定手段１４、条件クラス登録手段１５から構成されている。
また、ＡＤＡＳ装置１６は、ドライバモデル処理手段１８、イベント定義生成手段１９、情報報知手段２０、自動車制御手段２１から構成されている。
【０１６４】
以下、各構成について説明する。
イベント検出装置１の各構成は、実施の形態４と同様である。
ＡＤＡＳ装置１６のドライバモデル処理手段１８は、ドライバモデルを保持し、ドライバモデルと自動車内の状態情報（情報収集装置１７から入力される自動車の状態情報）から、運転手の状態を推定する。また、運転手の状態と状態情報に基づき、運転手への情報報知や自動車の安全制御を行う。また、自身が保持するドライバモデルに基づき、運転手への報知の可否判断、自動車の制御の可否判断および運転手の状態の推定、に必要となる状態情報とその状態情報の収集条件を生成する。
そして、ドライバモデル処理手段１８は、生成した状態条件の収集条件を、イベント定義手段１９に出力する。
【０１６５】
ドライバモデル処理手段１８に、情報収集装置１７から入力される自動車の状態情報は、イベント検出装置１から状態収集装置１７に処理内容が入力され、その時点から一定時間、処理内容に関して記録した、車載レーダ、またはドライバーのブレーキ操作情報など、の自動車の状態情報、である。
ドライバモデル処理手段１８は、ドライバモデルと、情報収集装置１７から入力された、一定時間記録した自動車の状態情報に基づいて、情報報知手段２０に運転手へ報知する情報を出力し、自動車制御手段２１に自動車を安全に制御するための情報を出力する。
【０１６６】
前記ドライバモデルとは、外部の視覚情報や計器盤からの情報等、ドライバーへの入力情報と、アクセルやブレーキ、ステアリング操作等のドライバーの操作情報から運転手の状態を出力するモデルのことである。例えば、外部からの入力情報に対して、ドライバモデルを用いて、運転操作が遅れる傾向にあることを判断すると、運転手が疲労状態にあると推定される。。
【０１６７】
ＡＤＡＳ装置１６のイベント定義生成手段１９は、ドライバモデル処理手段１８から入力された、生成した状態情報とその状態情報の収集条件であって、ドライバモデルが注目する状態情報とその状態情報の収集条件を、本発明におけるイベント定義の形式に変換して、イベント検出装置１に出力する。
ＡＤＡＳ装置１６の情報報知手段２０は、運転手に情報を報知する能力をもった装置であり、たとえばディスプレイやスピーカー等である。ドライバモデル処理手段１８から入力された判断結果に基づいて、運転手に情報を報知する。
ＡＤＡＳ装置１６の自動車制御手段２０は、自動車を制御するための装置であり、たとえばエンジン回転数やブレーキ力、シフト等を制御する信号を送出する装置である。ドライバモデル処理手段１８から入力された判断結果に基づいて、自動車を制御する。
【０１６８】
また、情報収集装置１７は、一般的には、自動車に搭載された車載レーダ、カメラ、赤外線センサなどのセンサデバイスの状態情報を収集し、一定時間記録する装置である。たとえば、リングバッファをもった情報処理装置であり、ある瞬間から一定時間前までに、車載ネットワーク上を流れた信号（状態情報）を、すべて記録している装置である。ここでは、イベント検出装置１が、イベント定義の処理条件が成立すると判定して、処理内容が情報収集装置１７に入力された場合に、その時点からある一定時間記録した状態情報をＡＤＡＳ装置１６に出力するものとして説明する。
【０１６９】
例えば、イベント検出装置１の処理条件判定手段７ｂで、あるイベント定義の処理条件が真と判定され、処理内容が情報収集装置１７に入力されると、情報収集装置１７は、その時点より５秒前から現在までの車載レーダの状態情報をＡＤＡＳ装置１６に出力する。
ＡＤＡＳ装置１６は、情報収集装置１７から入力された状態情報を、イベント定義の形式に変換し（イベント定義を変更し）、イベント検出装置１に出力する。イベント検出装置１は、このようにして変更されたイベント定義の状態条件を判定することになる。
【０１７０】
次に、実施の形態５の動作について説明する。
図２７は、この発明の実施の形態５における、イベント検出装置１、ＡＤＡＳ装置１６、情報収集装置１７の動作を示すフローチャートである。
また、図２８は、ＡＤＡＳ装置により更新されたイベント定義の例である。
以下、図２７のフローチャート、図２８のイベント定義を参照して実施の形態５の動作を説明する。
まず、ＡＤＡＳ装置１６のドライバモデル処理手段１８は、自身が保持するドライバモデルと、情報収集装置１７から入力された状態情報に基づき、運転手の状態を推定する。さらに、運転手の状態の推定結果から、運転手への報知の可否判断、自動車の制御の可否判断、および運転手の状態の推定に必要となる状態情報と、その状態情報の収集条件を生成する。（Ｓ３３０）。
【０１７１】
次に、ＡＤＡＳ装置１６のイベント定義生成手段１９は、Ｓ３３０の結果から、イベント定義を生成し、イベント検出装置１に書き込む（出力する）（Ｓ３３１）。
次に、イベント検出装置１は、ＡＤＡＳ装置１６のイベント定義生成手段１９から入力されたイベント定義に従って、自動車の状態情報を判定する（Ｓ３３２）。イベント定義の判定処理の動作は、実施の形態４における動作４−２から動作４−５と同様である。
次に、イベント検出装置１の処理条件判定手段７は、イベント定義の判定結果である処理内容を情報収集装置１７に送信（出力）する（Ｓ３３３）。
【０１７２】
そして、情報収集装置１７は、イベント検出装置１から処理内容が入力されると、その時点から一定時間前から記録している、処理内容に関する車載レーダ、またはドライバーのブレーキ操作情報などの状態情報をＡＤＡＳ装置１６に送信する（Ｓ３３４）。
【０１７３】
次に、ＡＤＡＳ装置１６のドライバモデル処理手段１８は、入力された状態情報に基づいて、運転手への報知や自動車の制御の必要性を判断し、情報報知手段２０や自動車制御手段２１を用いて必要な処理を行い、更に、イベント定義生成手段１９にイベント定義の更新を要求する（Ｓ３３５）。
イベント定義生成手段１９は、ドライバモデル処理手段１８からの要求によりイベント定義を更新し、更新したイベント定義を、イベント検出装置１に出力する。
この様にして、更新されたイベント定義について、イベント検出装置１でイベント定義が判定される。そして、判定した結果に基づいて、情報収集装置１７で記録した自動車の状態情報がＡＤＡＳ装置１６に入力される。そして、その状態情報によりイベント定義が更新されるので、動的に更新されるイベント定義に対して、処理時間を短縮してイベント定義を判定することができる。
【０１７４】
次に、図２８のイベント定義の更新データを用いて、具体例で動作を説明する。
例えば、ドライバモデル処理手段１８は、車載レーダによって測定された前方車両との距離情報と、ドライバーのブレーキ操作情報を情報収集装置１７から受け取る。
このとき、ブレーキのタイミングが通常より遅ければ、ドライバモデル処理手段１８は、運転手が疲労状態にあると判断する。仮に、運転手が疲労状態にないときには、図２８のＴ３３１に示すようなイベント定義が書き込まれていたものとする。
【０１７５】
この時の、｛車速｝の状態条件が真となる条件は｛車速｝＞＝８０ｋｍ／ｈである。
そして、ドライバモデル処理手段１８が、情報収集装置１７から受け取った車載レーダの情報、ブレーキの操作情報から疲労状態にあると判断すると、より早く報知を行わせるために、車速に関連する状態条件がより遅い車速、｛車速｝＞＝７０ｋｍ／ｈで真となるように変更されたイベント定義Ｔ３３２をイベント検出装置１に出力する。
【０１７６】
これに伴い、各状態条件に対する条件成立確率も変動する。したがって、イベント定義Ｔ３１２が書き込まれたときとは、状態条件の判定順序が変動する可能性がある。例えば、イベント検出装置１の条件成立確率切替手段１１によって、条件成立確率蓄積手段２１５の条件成立確率テーブルの、有効なテーブルが切り替えられる。そして、有効に切り替えられた条件成立確率テーブルを参照して、状態条件並び替え手段９がイベント定義蓄積手段５のイベント定義の状態条件番号を並び替える。
【０１７７】
以上のように、イベント検出装置１の判定結果により、情報収集装置１７が車載レーダ、またはブレーキ操作情報の状態情報をＡＤＡＳ装置１６に出力する。そして、ＡＤＡＳ装置１６は、入力された状態情報に基づいてイベント定義を更新し、その更新したイベント定義をイベント検出装置１に出力する。
このように、イベント検出装置１が、更新されたイベント定義で状態情報を判定することにより、自動車を運転する運転手の状態、路面状況などの走行中の車両周辺の状況に応じて、動的に状態条件の判定順序を変更することができるようになる。そのため、車載マイコンの様に、一定の処理周期の中で、動的に更新される状態条件の判定の時間を低減することができるので、運転手に必要な情報の報知、自動車を安全に走行させるための制御を早く行うことができる。
【０１７８】
また、図２９は、車載ネットワークに接続されているセンサーの情報に関して、自動車が危険な状態に陥ったときに、関連する情報を自動的に外部サーバに通知する危険状態自動収集システムの例である。
図２９に示す様に、ＡＤＡＳ装置１６を無線ネットワークと外部サーバ装置１８に置き換え、情報収集装置１７から外部サーバ装置１８へは、無線ネットワークを介して状態情報が出力されてもよい。
【符号の説明】
【０１７９】
１  イベント検出装置、２  エンジニアリング環境装置、３  センサ、４  外部装置、５  イベント定義蓄積、６  状態情報収集手段、７  処理条件判定手段、８  イベント定義入力手段、９  状態条件並び替え手段、１０  条件成立確率蓄積手段、１１  条件成立確率切替手段、１２  判定状態蓄積手段、１３  条件クラス蓄積種ｄ何、１４  条件クラス判定手段、１５  条件クラス登録手段、１６  ＡＤＡＳ装置、１７  情報収集装置、１８  ドライバモデル処理手段、１９  イベント定義生成手段、２０  情報報知手段、２１  自動車制御手段、２２  外部サーバ装置。
【図１】
2014154069.tif 000003
【図２】
2014154069.tif 000004
【図３】
2014154069.tif 000005
【図４】
2014154069.tif 000006
【図５】
2014154069.tif 000007
【図６】
2014154069.tif 000008
【図７】
2014154069.tif 000009
【図８】
2014154069.tif 000010
【図９】
2014154069.tif 000011
【図１０】
2014154069.tif 000012
【図１１】
2014154069.tif 000013
【図１２】
2014154069.tif 000014
【図１３】
2014154069.tif 000015
【図１４】
2014154069.tif 000016
【図１５】
2014154069.tif 000017
【図１６】
2014154069.tif 000018
【図１７】
2014154069.tif 000019
【図１８】
2014154069.tif 000020
【図１９】
2014154069.tif 000021
【図２０】
2014154069.tif 000022
【図２１】
2014154069.tif 000023
【図２２】
2014154069.tif 000024
【図２３】
2014154069.tif 000025
【図２４】
2014154069.tif 000026
【図２５】
2014154069.tif 000027
【図２６】
2014154069.tif 000028
【図２７】
2014154069.tif 000029
【図２８】
2014154069.tif 000030
【図２９】
2014154069.tif 000031