JP2011031774A - 車両故障判定装置、車両故障判定装置設計プログラム - Google Patents

Abstract

【課題】各車両の仕様に柔軟に対応することのできる車両故障判定装置、およびその車両故障判定装置を設計するプログラムを提供する。
【解決手段】本発明に係る車両故障判定装置では、各故障診断プログラム、その故障診断プログラムを実行する際に用いられる制御データ、および各故障診断プログラムの診断結果データの対応順序を、故障診断プログラムとは別に独立して定義する。また、本発明に係る車両故障判定装置設計プログラムは、故障診断項目となり得る全ての項目を記述した総診断項目リストから、必要なる故障診断項目を抽出する。
【選択図】図２

Description

本発明は、車両の故障を判定する装置、およびその装置を設計するプログラムに関するものである。

近年、車両に搭載される制御機能は増加傾向にあり、これに伴い制御に用いるセンサやアクチュエータの種類が増加している。また、診断内容の細分化に対する要求がある。これらの結果として、故障発生状況を診断すべき対象が増加してきている。

故障検出対象の増加によるプログラム開発工数の削減および故障診断プログラムの再利用性を向上させる手法として、下記特許文献１に記載の技術が提案されている。この技術における故障検出プログラムは、オブジェクト指向技術を用いて開発されており、故障検出オブジェクト、故障情報保存オブジェクト、故障情報管理オブジェクトを備える。同技術では、故障検出オブジェクトと故障情報保存オブジェクトの間の対応関係を故障情報管理オブジェクトに持たせ、オブジェクトの独立性を向上させている。

一方、ある診断対象の診断結果を基にさらに別の診断や制御を行っている場合、異常を検出した診断対象を未処理のまま放置していると、誤診断あるいは異常値の原因となる。そこで、診断対象の異常に起因して誤検出が発生する可能性のある他の診断対象について、その診断対象を診断する検出プログラムを実行させないようにする技術が、下記特許文献２に記載されている。

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

故障診断プログラムを開発する際には、診断項目を対象車両の仕様に合わせて選択する必要がある。また、誤診断を防止するための上記のような診断禁止処理や、各機能部をフェールセーフ状態へ切換えるか否かを判断する処理は、複数の機能部の故障状態を参照する必要があるため、対象車両の機能部の構成などが変わると、同様に当該車両の仕様に合わせて変更する必要がある。

したがって、故障検出プログラム（特許文献１では各オブジェクトに相当）の独立性や再利用性を高めたとしても、各故障検出プログラムが連携する部分に関しては、各車両の仕様に合わせて変更する必要がある。すなわち、各故障検出処理のインターフェースに相当する部分は、完全に再利用等することが難しい。

また、誤診断を防止するための上記のような診断禁止処理や、各機能部をフェールセーフ状態へ切り換えるか否かを判断する処理を行う際には、各機能部の故障発生情報を参照する必要があるが、これらの故障発生情報を故障検出プログラムの制御条件として用いている場合には、同様に各車両の仕様に合わせて制御条件を変更する必要がある。

以上のように、故障検出プログラムの独立性や再利用性を高めても、プログラム間で連携する部分などに関しては、各車両の仕様に合わせて個別に開発する必要がある。そのため、派生的に故障検出プログラムの種類が増加し、再利用性が低下するのみならず、各車両と故障検出プログラムの対応関係を管理するなどの管理工数も増加する。したがって、結果的に故障検出プログラムの開発工数、デバッグ工数、管理工数などが膨大になってしまう。

本発明は、上記のような課題を解決するためになされたものであり、各車両の仕様に柔軟に対応することのできる車両故障判定装置、およびその車両故障判定装置を設計するプログラムを提供することを目的とする。

本発明に係る車両故障判定装置では、各故障診断プログラム、その故障診断プログラムを実行する際に用いられる制御データ、および各故障診断プログラムの診断結果データの対応順序を、故障診断プログラムとは別に独立して定義する。

本発明に係る車両故障判定装置では、故障診断プログラム、制御データ、診断結果データの対応関係が、故障診断プログラム本体とは別に定義されているので、これらを容易かつ柔軟に入れ替えることができる。これにより、故障診断対象の増減、対象車両の仕様の差異などに容易に対応することができる。

実施の形態１に係るエンジンコントロールユニット２００の機能ブロック図である。 実施の形態１に係る車両故障判定装置の機能構成を模式的に示すブロック図である。 エンジンの噴射量を制御するための故障診断項目が車両毎に異なる様子を示す図である。 図３で説明したようなシステム構成の相違による故障検出対象項目の相違に対して、車両故障診断装置の開発手法をより効率的に発展させた例を示す。 図３〜図４で説明した手法を実現する具体的手段を説明する図である。 実施の形態２に係る車両故障診断装置の機能構成を模式的に示すブロック図である。 故障診断プログラムと他の故障診断プログラムの診断結果の相関関係を説明する図である。 『診断相関表』の具体例を示す図である。 図８で説明した手法を実現するための具体的手段を説明する図である。 図９（Ｂ）に示すリストを、ソフトウェアプログラムが処理し易い形式で表現しなおした例を示す図である。 実施の形態３に係る車両故障診断装置の機能構成を模式的に示すブロック図である。 故障診断プログラムの実行可否とフェールセーフ状態の相関関係を説明する図である。 『フェールセーフ（Ｆ／Ｓ）相関表』をより具体化したものを示す図である。 『フェールセーフ（Ｆ／Ｓ）相関表』をより具体化したものを示す図である。 診断結果統括処理部３０００の動作のうち、ＯＫフラグを受け取った場合のフローを示す図である。 診断結果統括処理部３０００の動作のうち、ＮＧフラグを受け取った場合のフローを示す図である。 診断結果統括処理部３０００の動作のうち、車両故障診断装置の始動時または終了時などに実行されるフローを示す図である。 図１５のステップＳ１４０５等において診断相関判定部５０００が実行する処理フローである。 図１５のステップＳ１４０５等においてフェールセーフ相関判定部７０００が実行する処理フローである。 故障診断プログラムの１例として、吸気管圧力センサ機能診断プログラム１００３の動作フローを説明する図である。

＜実施の形態１＞
図１は、本発明の実施の形態１に係るエンジンコントロールユニット２００の機能ブロック図である。エンジンコントロールユニット２００は、車両のエンジンの動作を制御する装置である。

エンジンコントロールユニット２００は、エンジン制御に必要なセンサ類、例えばクランク角センサ１０１、カム角センサ１０２、吸気管圧力センサ１２０、吸気温度センサ１２１、エンジン水温センサ１２２、大気圧センサ１２３、スロットルセンサ１２４、空燃比センサ１２５などを備える。また、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、出力回路２２０、モニタ回路２３０を備える。

クランク角センサ１０１、カム角センサ１０２は、エンジン回転数と位相を検出する。圧力センサ１２０は、吸気管吸入圧力を計測する。 吸気温度センサ１２１は、内燃機関の運転状態を検出するための手段である。エンジン水温センサ１２２は、内燃機関の冷却水（クーラント）温度を検出する。大気圧センサ１２３は、大気圧を検出する。スロットルセンサ１２４は、スロットル弁開度を検出する。空燃比センサ１２５は、排気の空燃比を検出する。

エンジンコントロールユニット２００内の入力処理回路２１０は、上記各センサ類が出力する電気的情報を信号処理し、ＣＰＵ２０１に出力する。ＣＰＵ２０１へ入力される信号は、Ａ／Ｄ変換器２０３に入力されるアナログ信号と、Ｈｉｇｈ／Ｌｏｗレベルの２値信号として入力されるその他の信号とに分かれる。

ＣＰＵ２０１は、ＲＯＭ２０２に格納されているプログラムが規定する演算処理を実行し、この演算結果に基づきエンジン制御に必要な各種アクチュエータの制御信号を出力し、出力回路２２０を介してこれらを制御する。

例えば、ＣＰＵ２０１は、吸気管圧力センサ１２０の入力から計測される質量流量、クランク角センサ１０１から計測されるエンジン回転数、エンジン水温センサ１２２から検出される水温を含む各補正量、空燃比センサ１２５によって検出される空燃比状態に応じた補正量を付加した上で燃料噴射量を演算する。ＣＰＵ２０１は、上記演算に基づき、最終的にエンジンの各インジェクタ１１１に駆動パルス幅を出力する。

同様にＣＰＵ２０１は、エンジンの燃焼に必要な点火コイル１１２への通電タイミングを制御する点火信号、スロットル弁開度を制御する電制スロットル１１４への信号、空燃比センサヒータ１１５への通電を制御する空燃比センサヒータ信号、可変吸気バルブ１１３のタイミングを制御する信号などを出力する。

入力センサ信号、および出力アクチュエータ信号は、最低限必要なものと、高性能、高機能化によって部品が付加されるものとがあるため、エンジンのシステム構成によって、これらの要否が変わることは明白である。

ＣＰＵ２０１は、上記機能の他に、本発明に係る車両故障判定装置としての機能を有している。ＣＰＵ２０１は、ＲＯＭ２０２が格納している故障診断プログラムを実行することにより、センサ類などからの入力信号のレベルや機能的な動作状態に基づき、各センサの検出値が異常であるか否かを判定する。またＣＰＵ２０１は、ＣＰＵ２０１自身が出力する上述の制御信号と、出力回路２２０に付加されている信号モニタ機能、または直接モニタ回路２３０を介して取得した出力回路２２０の出力信号を再度ＣＰＵ２０１に取り込む。ＣＰＵ２０１は、これらの情報を比較して、各信号のレベルや機能的な動作状態に基づき、各アクチュエータが異常であるか否かを判定する。ＣＰＵ２０１は、これらの判定結果をＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０４や不揮発性のＲＡＭであるＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０５に保存する。

以下の説明において、各プログラムが規定する動作を説明する際には、記載の便宜上、各プログラム本体を動作主体として記載するが、実際の動作主体はＣＰＵ２０１などの演算装置であることを付言しておく。

図２は、本実施の形態１に係る車両故障判定装置の機能構成を模式的に示すブロック図である。車両故障診断装置は、故障診断部１０００、診断制御用データ記憶部２０００、診断結果統括処理部３０００、診断結果情報記憶部４０００を備える。

故障診断部１０００は、故障診断を行う各対象に対応する、１ないし複数の個別の故障診断プログラムを実行する。ここでは、Ｎ個の故障診断プログラム１００１〜１００Ｎが存在しているものとする。故障診断部１０００は、診断結果を診断結果統括処理部３０００に引き渡す。

診断制御用データ記憶部２０００は、故障診断プログラムの動作を制御するための制御データを格納する。この制御データは、データ形式で構成してもよいし、故障診断プログラムと連携して動作するプログラムとして構成してもよい。故障診断プログラムと上記制御データの関連については、後に改めて説明する。診断制御用データ記憶部２０００は、本発明における『診断制御部』に相当する。

診断結果統括処理部３０００は、故障診断部１０００のそれぞれの診断結果を受け取って、必要な処理を施した上で診断結果情報記憶部４０００に格納する。

診断結果情報記憶部４０００は、故障診断部１０００の診断結果を格納する。図２に示す例では、診断対象が現在故障中であるか否かを示す『現在故障』フラグの他に、『ランプＯＮ要求』、『運転内診断完了』、『運転内故障』、『仮ＮＧ状態』、『故障判定中』などのフラグを診断結果と併せて格納する例を示した。上述の各フラグは、ビット列などの形式で表すことができる。

車両故障診断装置を構成する各記憶部は、ＲＡＭ２０４などの記憶装置を用いて構成することができる。その他の各機能部は、これらの機能を実現する回路デバイスなどのハードウェアを用いて構成することもできるし、ＣＰＵ２０１などの演算装置とその動作を規定するソフトウェアを用いて構成することもできる。

ランプ出力５０は、車室内のメータインパネ上に設置される警告灯（チェック・エンジン・ランプ）への出力に相当するものである。車両のユーザーに故障を認識させるために、例えば、上述の診断結果情報記憶部４０００に格納する『ランプＯＮ要求』フラグを基に、何れかの診断対象の『ランプＯＮ要求』がセットさせている場合に、ランプをＯＮ（点灯）するように制御する。

ここで、故障診断プログラム１００１〜１００Ｎについて補足しておく。
故障診断プログラム１００１〜１００Ｎは、それぞれの診断対象の診断を実行し、その診断結果情報を出力する。図２では、記載の都合上、各故障診断プログラム１００１〜１００Ｎは機能ブロックとして記載したが、実際にはＲＯＭ２０２などの記憶装置内に各故障診断プログラムを格納しておき、ＣＰＵ２０１がこれを読み出して実行する。

必ずしも、１つの診断対象または１つの診断結果情報に対して１つの故障診断プログラムが対応するわけではなく、１つの故障診断プログラムで複数の診断対象を診断してもよいし、同様に１つの故障診断プログラムが複数の診断結果情報を出力してもよい。このように、故障診断プログラムと診断結果情報は相互に関連し合っており、さらには車両の仕様が異なると診断対象も異なるので、両社の対応関係は複雑である。

そこで、本実施の形態１に係る車両故障診断装置では、故障診断プログラム１００１〜１００Ｎが出力する診断結果と、診断結果情報記憶部４０００が格納する診断結果情報との対応関係を、診断制御用データ記憶部２０００が格納する制御データによって定義する。制御データの例は後述の図５で改めて説明するが、具体的な実装方法としては、例えば両者の対応関係を配列などで順番に定義するとよい。

本発明に係る車両故障診断装置は、ＣＰＵ２０１などの演算装置とＲＡＭ２０４などの記憶装置を用いて、車両制御を行うソフトウェアとして構成してもよいし、各機能部を別途備える独立した装置として構成してもよい。

以上、本実施の形態１に係る車両故障診断装置の構成について説明した。次に、車両の仕様が変更されることにともなって故障診断プログラムの診断対象を変更することの困難性について説明する。

図３は、エンジンの噴射量を制御するための故障診断項目が車両毎に異なる様子を示す図である。図３（Ａ）は、吸気管圧力センサを主としてエンジンの噴射量を制御する車両の故障診断項目を示す。図３（Ｂ）は、エアフローセンサを主としてエンジンの噴射量を制御する車両の故障診断項目を示す。図３（Ｂ）では、車両の高機能化により、可変吸気バルブデバイスや吸気管長切換え機構等を搭載していることに加え、エンジンの気筒数も４気筒から６気筒に変更されている。記載の都合上、図３では診断項目の一部のみ図示しているが、実際の故障検出対象は数十から数百項目にも達する場合がある。

図３（Ａ）に示すシステム構成（システムＡ）の下で故障診断プログラムを既に開発済みである状況を想定する。車両のエンジン周辺の仕様を、図３（Ａ）に示すシステム構成から図３（Ｂ）に示すシステム構成に変更しようとする場合には、故障診断プログラムの診断対象も変更する必要がある。図３に示す例では、故障診断を行うための主センサが、吸気管圧力センサからエアフローセンサに変わる。そのため、故障診断項目の削除および追加、例えば可変吸気バルブや吸気管長切換え用デバイスを故障診断項目に追加、失火診断の対応気筒数を故障診断項目に追加、などの作業が発生することになる。

以上説明したように、車両の仕様が変わると、故障診断対象の削除や追加、すなわち、個々の故障診断プログラム（例えば１００１〜１００Ｎのいずれか）を削除したり追加したりする変更工数がかかるのは明白である。また、車両故障診断装置に搭載する故障診断プログラムの組み合わせと各車両の仕様を対応させるための管理工数も増加することになるので、結果的には個々の仕様に応じて故障診断プログラムの変更、確認（デバッグ）などを行うための開発工数と、これらを管理する管理工数が膨大となってしまう。

そこで、本実施の形態１では、各故障診断プログラム、後述の制御データ、各故障診断プログラムの診断結果データを対応付ける手段を、故障診断プログラムとは別に独立して設けることとした。これにより、故障診断プログラム本体を変更することなく、対応する故障診断プログラムを追加したり不要な故障診断プログラムを削除したりするのみですむので、確認（デバッグ）工数と管理工数を大幅に低減することができる。

図４は、図３で説明したようなシステム構成の相違による故障検出対象項目の相違に対して、車両故障診断装置の開発手法をより効率的に発展させた例を示す。図４の各項目について以下に説明する。

図４（Ａ）は、エンジン制御を行うために必要な故障診断項目として存在し得る全ての故障診断項目を記載した総診断項目リストである。同リストには、エンジン制御に関する故障診断項目として、考え得るセンサやデバイスが全て列挙されている。「診断項目」列の値は診断項目の名称または内容を示し、「総番号」列の値はその通番を示す。実際の項目数は、数百項目にのぼる場合がある。

図４（Ａ）の「選択項目」列の値は、各車両仕様に対していずれの診断項目が選択されるかを示す。例えば図３（Ａ）のシステム構成（システムＡ）に対応しようとする場合、設計者は同システムの故障診断対象となる「選択項目」欄に“１”を設定する。

図４（Ｂ）は、図４（Ａ）の「選択項目」列内の「Ａ」欄で示したような設定とし、この欄に“１”が設定してあるものだけを抽出して再配列したものである。再配列するときに、「配列番地」列の値を０から改めて割り付けている。

以上のようにして抽出された故障診断対象は、図３（Ａ）の“システムＡ“と等価となる。このように、あらかじめ設定しておいた総診断項目リストから、対象とする車両に必要な故障診断項目のみを選択することにより、必要な故障診断項目のみを抽出して配列番地に割り付けることができる。

図５は、図３〜図４で説明した手法を実現するための具体的手段を説明する図である。図５（Ａ）は総診断項目リスト、図５（Ｂ）は図５（Ａ）から必要な故障診断項目のみを抽出したリスト、図５（Ｃ）は図５（Ｂ）に示すリストをプログラムに実装可能な形式で表現した状態を示す図である。

図５（Ａ）に示す総診断項目リストには、図４（Ａ）で説明した「選択項目」列と「総番号」列（記載の都合上、図５では「選択」「Ｔｏｔａｌ Ｎｏ」とした）が設けられている。設計者は、当該車両の故障診断を行うために必要な診断項目の「選択項目」列に“１”を設定する。

図５（Ｂ）は、図５（Ａ）から「選択項目」列に“１”が設定してあるものだけを抽出して再配列し、配列番地を０から割り付けることにより、図５（Ａ）を圧縮したものである。図５（Ｂ）の左部に、抽出結果および配列番地を例示した。

図５（Ｂ）ではさらに、各故障診断項目と各故障診断プログラムの対応関係や、各故障診断プログラム内で実行される処理の繰り返し回数などの制御用データを、抽出した故障診断項目と併せて記述した。各項目について説明する。

（項目１）許可フラグ名、ＲＡＭ名
許可フラグ名、ＲＡＭ名は、各診断項目と故障診断プログラムを対応付けるとともに、各故障診断プログラムが内部的に使用する値などをそれぞれの故障診断プログラムと対応付ける役割を有する。

（項目２）制御用データ
制御用データは、各故障診断プログラムが内部的に使用する制御パラメータである。ここでは、Ｐコード等のＤＴＣ（ダイアグノーシス・トラブル・コード）、コード消去回数、ランプを点灯する判定回数、ランプ点灯許可（ＳＷ）を例示した。これらのパラメータは、各故障診断プログラムの動作に影響を与える。例えば回数パラメータの値が変更されると、故障診断プログラム内部のある処理の繰り返し回数が変更される、といったものである。

（項目２：補足）
ここでいう制御用データは、図２で説明した診断制御用データ記憶部２０００が格納している各データ（２００１、２００２など）に相当する。例えば、制御データ２００１は吸気管圧力センサの電圧Ｈｉｇｈ故障についての制御データ、制御データ２００２は電圧Ｌｏｗ故障についての制御データ、などである。なお、上記許可フラグ名やＲＡＭ名などのパラメータも、制御用データに含めてもよい。

このように、各故障診断プログラムと各パラメータ等を対応付け、配列形式でその対応関係を定義しておくことにより、故障診断プログラムおよびパラメータともに、必要な情報のみを抽出し、配列上の順番によってそれぞれを対応付けることができる。

図５（Ｃ）は、図５（Ｂ）に示すリストを、プログラム言語の形式で表現し直した例を示す図である。ここではＣ言語類似の例を示したが、表現方法は故障診断プログラムなどを実装するプログラム言語に合わせて適宜変更してもよい。

図５（Ｃ）では、図５（Ｂ）に示すリストを、（Ａ−１）：配列定義リスト、（Ａ−２）：フラグインタフェース定義リスト、（Ａ−３）：変数定義リスト、（Ａ−４）：ＲＯＭデータリストとして改めて記述した例を示した。このように、図５（Ｂ）のリストをプログラム言語の仕様に合わせてリスト化することにより、プログラムへそのまま実装することができるので、開発効率を向上させることができる。

各故障診断プログラムは、診断結果を診断結果統括処理部３０００に出力する。診断結果統括処理部３０００は、診断結果情報記憶部４０００に、各診断結果情報を配列状に格納する。各診断結果情報の配列番号は、（Ａ−１）：配列定義リストが定義する配列順序にしたがって定められる。これにより、故障診断プログラム、制御データ、診断結果情報が配列番号によって順番に対応付けられることになる。

なお、図５（Ａ）〜図５（Ｂ）、さらには図５（Ｂ）〜図５（Ｃ）に至る工程は、設計者などが人手で行うと作業負担が大きく効率的でない。そこで、本実施の形態１では、これらの工程を自動的に実行する設計支援プログラム（本実施の形態１に係る車両故障判定装置設計プログラムに相当）を用いることとする。以下に、各設計支援プログラムの役割を説明する。

（設計支援プログラムα１）データ定義情報圧縮
設計支援プログラムα１は、ＣＰＵ２０１によって実行される。設計支援プログラムα１は、図５（Ａ）に示す総診断項目リストから、「選択項目」列に“１”がセットされている項目のみを抽出し、図５（Ｂ）に示すリストを出力する。また、各故障診断プログラムが用いる制御データを別途取得し、図５（Ｂ）に示すように配列上に対応付ける。各故障診断プログラムに対応する制御データは、例えば設計支援プログラムα１を実行するコンピュータ上にあらかじめ保存しておいてもよいし、設計者が入力してもよいが、効率の観点からはあらかじめ準備したものを読み込むほうが好ましい。

（設計支援プログラムα２）リスト生成
設計支援プログラムα２は、ＣＰＵ２０１によって実行される。設計支援プログラムα２は、図５（Ｂ）に示すリストから、図５（Ｃ）に示すプログラム言語形式のリストを生成する。どのような形式でリストを出力するかは、設計支援プログラムα２内部で定めてもよいし、例えば設計支援プログラムα２を実行するコンピュータ上にあらかじめそのルールを保存しておいてもよい。

（設計支援プログラム：補足）
各設計支援プログラムは、上記α１、α２のように２種類に分けてもよいし、単一のプログラムで両者の処理を実行するようにしてもよい。また、上記各設計支援プログラムに相当するプログラムを車両故障診断装置内部に構成してもよい。ただし、車両故障診断装置のプログラムサイズを最小化する観点からは、設計支援プログラムを外部プログラムとして構成しておき、車両故障診断装置内部に組み込むプログラムのサイズを少なくするほうが好ましい。

以上のように、本実施の形態１に係る車両故障診断装置では、各故障診断プログラム、各故障診断プログラムの制御データ、各故障診断プログラムの診断結果情報を、配列番号によって対応付け、診断結果情報記憶部４０００に格納する。これにより、それぞれの対応関係を容易に入れ替えることができるので、車両の仕様変更などに柔軟に対応することができる。また、故障診断プログラム本体を変更する必要がないので、開発工数や管理工数を削減することができる。

また、本実施の形態１に係る車両故障判定装置設計プログラム（設計支援プログラムα１、α２）は、故障診断項目となり得る総診断項目リストから、当該車両の故障診断に必要な項目のみを抽出し、当該車両用の診断項目リストを生成する。これにより、設計者は必要な診断項目を選択するのみで、車両故障診断装置を任意の車両の仕様に対応させることができるので、開発工数を大幅に削減することができる。

また、本実施の形態１に係る車両故障判定装置設計プログラム（特に設計支援プログラムα２）は、当該車両用の診断項目リストをプログラム言語の形式で生成する。これにより、同リストをプログラム内に容易に組み込むことができるので、車両故障診断装置の機能を損なうことなく、ＲＯＭ２０２の消費容量を抑制することができる。

＜実施の形態２＞
実施の形態１では、車両の仕様に応じて故障診断プログラムや制御データの組み合わせを容易に入れ替えることのできる車両故障診断装置およびその設計プログラムについて説明した。本発明の実施の形態２では、実施の形態１で説明した構成に加え、故障診断プログラム相互の相関関係に対応することのできる構成を新たに導入する。その他の構成は概ね実施の形態１と同様であるため、以下では差異点を中心に説明する。

図６は、本実施の形態２に係る車両故障診断装置の機能構成を模式的に示すブロック図である。本実施の形態２に係る車両故障診断装置は、実施の形態１の図２で説明した構成に加え、新たに診断相関判定部５０００、フェールセーフ状態判定部６０００を備える。

診断相関判定部５０００は、診断結果情報記憶部４０００が格納している情報に基づき各故障診断プログラムの実行許可または実行停止を指示する。また、各故障診断プログラムの実行許可または実行停止を指示するために必要な事項を定義する診断相関定義リスト５００１を有する。診断相関判定部５０００は、各故障診断プログラムの実行許可または実行停止の指示を、診断結果情報記憶部４０００に格納する。格納先は、各故障診断プログラムの診断結果情報と対応付けるようにする。図６では、各診断結果情報の一部に一体化して格納した例を示したが、必ずしも各診断結果情報と一体化しなくともよい。

フェールセーフ状態判定部６０００は、故障診断プログラムの診断結果が以下のような値となっているとき、その故障診断プログラムの故障診断対象がフェールセーフ状態にあると判定する。
（フェールセーフ状態その１）故障診断結果が制御範囲外となっている場合
（フェールセーフ状態その２）故障診断結果が通常制御状態ではない値となっている場合、例えば初期値や固定値である場合

以上、本実施の形態２に係る車両故障診断装置の構成について説明した。次に、故障診断プログラムの診断結果が相互に関連することについて説明する。

図７は、故障診断プログラムと他の故障診断プログラムの診断結果の相関関係を説明する図である。ここでは、ＲＯＭ２０２内に格納されている吸気管圧力センサ機能診断プログラム１００３を例に取り上げる。

図７（Ａ）は、従来の吸気管圧力センサ機能診断プログラム１００３の一般的な構成を示す図である。同プログラムの主な構成要素としては、故障診断を実行するための各種条件を含めた診断実行条件部と、診断に必要なパラメータを演算する部分と、これらを用いて故障を判定する部分とに分かれる。演算処理結果は、ＯＫ、ＮＧ判定フラグと、判定成立フラグとして出力される。

吸気管圧力センサ機能診断プログラム１００３の中で、車両のシステム仕様に影響を受けるのは、診断実行条件部である。

例えば、誤判定を防止するため、可変吸気バルブデバイスを搭載するシステムでは、可変吸気バルブが未故障状態でなければならないという制約がある。可変吸気バルブが故障している場合、吸気管圧力センサが検出する圧力と、判定用パラメータとして他のセンサ情報を基に比較値として演算される擬似圧力値との間に乖離が発生する。そのため、吸気管圧力センサ機能診断プログラム１００３の診断実行条件部は、『可変吸気バルブが故障しているか否か』を表す情報と、『フェールセーフ状態実行中であるか否か』を表す情報とを参照する必要がある。これらは、可変吸気バルブの故障状態情報（『現在故障』フラグ）、および可変吸気バルブのフェールセーフ状態情報（『フェールセーフ状態』フラグ）を参照することにより得られる。

なお、実際の吸気管圧力センサ機能診断プログラム１００３では、可変吸気バルブの故障状態以外にも、例えば水温センサや大気圧センサなどの故障状態を参照しなければならない場合もあることを付言しておく。

一方、可変吸気バルブを搭載していないシステムにおける吸気管圧力センサ機能診断プログラム１００３では、可変吸気バルブの故障状態情報などを参照する必要がない。この場合には、可変吸気バルブの故障状態情報、および可変吸気バルブのフェールセーフ状態情報を取得する必要はないことになる。

上記のように、可変吸気バルブデバイスが有るか否かによって、吸気管圧力センサ機能診断プログラム１００３を修正変更する必要がある。他のシステム構成要素が変るとさらに変更するべき項目が増加し、プログラムの変更、開発、検証、および管理工数が、システムが変る毎に増大する。そのため、開発効率の低下、費用の増大などが発生してコスト面で不利であるのみならず、管理ミスによるアンマッチなどが発生し、品質の低下を招く恐れがある。

図７（Ｂ）は、本実施の形態２における吸気管圧力センサ機能診断プログラム１００３の構成を示す図である。本実施の形態２では、上述のようなシステム構成の差異に起因して、吸気管圧力センサ機能診断プログラム１００３が参照すべき情報を変更しなければならないことに対応するため、参照すべき情報をプログラム本体から切り離した。

本実施の形態２において、吸気管圧力センサ機能診断プログラム１００３は、『診断許可要求フラグ』の値を取得し、その値に基づき可変吸気バルブの故障診断を実行してよいか否かを判断する。『診断許可要求フラグ』の値は、後述の診断相関判定部５０００によって診断結果情報記憶部４０００に格納される。

図７（Ｂ）の例では、『可変吸気バルブが故障しているか否か』を表す情報と、『可変吸気バルブがフェールセーフ機能を実行中であるか否か』を表す情報とを吸気管圧力センサ機能診断プログラム１００３から切り離し、『診断許可要求フラグ』を介して間接的にこれらの情報を参照するようにした。これにより、吸気管圧力センサ機能診断プログラム１００３の独立性を高めることができる。

例えば、システム構成が変わって可変吸気バルブが存在しないようになった場合でも、『診断許可要求フラグ』の初期値を「診断を許可する」旨の値（本実施形態では１）としておけば、診断実行条件部を作成し直す必要はない。

また、システム構成が変更され、参照すべき故障状態情報やフェールセーフ状態情報を変更しなければならない場合でも、『診断許可要求フラグ』の値を参照して診断実行可否を判断するというロジックそのものは変更する必要はない。参照すべき故障状態情報やフェールセーフ状態情報を変更するには、吸気管圧力センサ機能診断プログラム１００３が参照する『診断許可要求フラグ』の値をセットする診断相関判定部５０００のみを変更すればよい。

以上説明したように、本実施の形態２では、各故障診断プログラムが診断実行可否を判断するために参照する他の故障診断プログラムの診断結果やフェールセーフ状態と、当該故障診断プログラムとの間のインタフェースのみを、各故障診断プログラムに定義しておく。これにより、システム仕様（車両仕様）が変更になっても、故障診断プログラム自体を変更する必要がないので、開発工数、検証工数、および管理工数を大幅に削減することができる。なお、ここでは吸気管圧力センサ機能診断プログラム１００３を例に取り上げたが、他の故障診断プログラムについても同様である。

以上、本実施の形態２における故障診断プログラムと他の故障診断プログラムの診断結果の相関関係について説明した。次に、本実施の形態２における診断相関の考え方、および診断相関判定部５０００の具体的な実装手法について、図８〜図９を用いて説明する。

図８は、『診断相関表』の具体例を示す図である。『診断相関表』は、縦軸と横軸に故障診断項目を並べた表である。横軸は診断結果情報（正常／故障）を意味している。横軸に示す診断項目が故障である場合、その故障によって誤検出を招く可能性のある縦軸の故障診断項目に●がついている。すなわち、横方向に見た場合、横方向で●がついた診断結果が故障と検出されていれば、当該故障診断の実行を禁止しなければならない。

例えば、水温センサが電気的に故障している場合は、水温センサの機能診断（８−ａ）を行う故障診断プログラムは実行不可能であるので、「水温センサＨｉ側診断」「水温診断Ｌｏ側診断」の値を●とした。また、同故障診断プログラムは、水温センサの機能診断（８−ａ）を実行する際に、機能的な故障を判定するための条件として、吸気管圧力（ＭＡＰ）センサ、吸気温センサ、回転数情報を得るクランク角センサなどを参照している。そのため、これらが故障状態であると判定している場合は、同故障診断プログラムの実行を停止しなければならない。そこで、これらに関係する値を●とした。

ある１つのシステムにおいては、上述のような故障診断プログラム同士の相関関係は固定されるが、異なるシステムへ対応する場合には、診断項目が変わると、故障検出対象や参照すべき故障状態情報などを、そのシステムの仕様に合わせて変更する必要がある。

そこで、本実施の形態２では、考え得るセンサやデバイスなどの故障診断項目を全て列挙して、図８のように縦軸と横軸に並べ、全故障診断項目相互の相関関係を図８と同様に定義することを考える。この表を『総診断相関表』と呼ぶことにする。『総診断相関表』のうち対象システム（故障診断対象車両）に関連する故障診断項目のみを抽出することにより、各故障診断プログラムの相関関係のうち必要なもののみを取り出すことができる。あらかじめ全故障診断項目相互の相関関係を定義しておけば、抜けが生じる心配はない。

以上、本実施の形態２における診断相関の考え方について説明した。次に、診断相関判定部５０００の具体的な実装手法について説明する。

各故障診断プログラムは、上述の通り『診断許可要求フラグ』の値を参照するように実装される。この『診断許可要求フラグ』の値は、診断結果情報記憶部４０００のいずれかの領域に格納されている。『診断許可要求フラグ』の値は、各故障診断プログラムからは独立してセットされるので、各故障診断プログラムは、『診断許可要求フラグ』の具体的な格納場所（例えば格納先番地など）がどこであるかを、別途把握しておかなければならない。そこで本実施の形態２では、各故障診断プログラムと『診断許可要求フラグ』の相関関係を、後述の診断相関定義リスト５００１で定義し、実施の形態１で説明した配列順序を用いて参照できるようにした。

図９は、図８で説明した手法を実現するための具体的手段を説明する図である。図９（Ａ）は総診断相関表、図９（Ｂ）は図９（Ａ）から必要な故障診断項目のみを抽出したリストを示す図である。

なお、図９において、図７で説明した『診断許可要求フラグ』は、『診断ＮＧフラグ』と『フェールセーフ（Ｆ／Ｓ）状態フラグ』に分けて記載されている。これは、各故障診断項目の故障診断結果は各故障診断プログラムが出力し、フェールセーフ状態にあるか否かの判断結果はフェールセーフ状態判定部６０００が出力するからである。診断相関判定部５０００は、両者のフラグを用いて、図８で説明した『診断許可要求フラグ』を診断結果情報記憶部４０００に書き込む。

図９（Ａ）では、図８で説明した総診断相関表をより具体化した例を示した。同図において、縦軸には全故障診断項目、「選択項目」列が配置されている。横軸には、縦軸と同じ項目に加え、以下の項目が配置されている。

（横軸項目その１）『診断ＮＧフラグ』の配置場所
『診断ＮＧフラグ』は、診断結果統括処理部３０００が各故障診断プログラムの故障診断結果を診断結果情報記憶部４０００に格納することにより作成される。本フラグは、図６における診断結果情報４００１、４００２等のうち左から２番目の『現在故障』フラグに相当する。本フラグの格納場所は、図９の（１）ＲＡＭ名と（２）フラグ名により特定される。フラグ名については、後述の図１０で例を挙げて説明する。

（横軸項目その２）『Ｆ／Ｓ状態フラグ』の配置場所
『Ｆ／Ｓ状態フラグ』は、フェールセーフ状態判定部６０００が各故障診断プログラムの診断結果に基づき、ＲＡＭ２０４などの適当な領域に格納する。図６では、Ｆ／Ｓ状態フラグ６００１〜６００Ｎとして記載した。本フラグの格納場所は、図９の（３）Ｆ／Ｓ状態のＲＡＭ名、フラグ名により特定される。

（横軸項目その３）最終列を示すフラグ
最終列には、横軸が最終であることを示す情報である０ｘＦＦが全ての項目に定義してある。これは、ループ処理の終了判定を行うための情報として使用するものである。必ずしも０ｘＦＦでなくとも、プログラムが識別できる情報であれば値は任意でよい。また、あらかじめ総診断項目数を得られるのであれば、本項目はなくてもよい。

図８では、各故障診断プログラムの診断結果の相関関係は、記号●を用いて表したが、図９ではこれをより細分化し、「１」から「３」までの数値を割付けることにした。数値「１」は『現在故障』、数値「２」は『運転内故障』、数値「３」は『故障成立中』の診断状態を表す。総診断相関表の各セルに設定する値により、単に診断結果がＯＫ／ＮＧという２値のみならず、複数の診断結果を相互に関連付けることができる。ただし、各故障診断対象がフェールセーフ状態にあるか否かは、数値「０」「１」のみを用いることとした。

図９において、総診断項目数を４０３としているが、これに限られるものではなく、例えば将来的に診断対象項目が増えた場合は、それぞれ縦横方向に診断項目を追加していけばよい。

図９（Ｂ）は、図９（Ａ）から「選択項目」列に“１”が設定してあるものだけを抽出して再配列し、配列番地を０から割り付けることにより、図９（Ａ）を圧縮したものである。

図１０は、図９（Ｂ）に示すリストを、ソフトウェアプログラムが処理し易い形式で表現しなおした例を示す図である。図１０は、図９（Ｂ）の続きであるため、図１０上では（Ｃ）と記載した。図１０では、図９（Ｂ）に示すリストを、（Ｂ−１）：診断相関定義リスト５００１として再構成した例を示した。図１０に示す診断相関定義リスト５００１では、図９（Ｂ）に示すリストに基づき、診断項目名、診断項目数数、参照するべきフラグ名、およびフラグの値を格納するＲＡＭ名が、配列状に順番にリスト化されている。

配列番号０〜４に相当する故障診断項目では、参照すべき他の故障診断状態がなく、故障診断を禁止すべき状況が発生しないので、項目名、最終であることを示す０ｘＦＦ、項目数：１がセットされている。

配列の５番目（ａ）は、図９（Ｂ）における（ａ）に相当する。同診断項目が参照すべき情報は、図９（Ｂ）の（ａ）を横軸方向に見ると分かる。横軸方向に数値「１」から「３」が設定されている項目は、０ｘＦＦを含めて１０項目である。したがって、参照情報数：１０となる。

フラグ名は、総診断相関表の数値「１」に対応するものがＦ１、数値「３」に対応するものがＦ３、などとなるように設定しておく。数値そのものを用いないのは、各診断状態を表す数値が後に変更されたような場合でも、プログラムの変更範囲を最小限に留めるためである。例えば、『現在故障』を表す数値が「１」から「１１」に変更になった場合などが考えられる。数値そのものに代えてフラグ名を用いるようにしておけば、上記のように数値が変更になっても、数値とフラグ名の対応関係のみ書き換えればよいので、プログラム本体は変更する必要がない。

図１０に示すリストにより、各故障診断プログラムを実行することができるか否かは、最終的には１つの『診断許可要求フラグ』に集約することができる。また、図１０のようにリスト化しておけば、車両故障診断装置の診断機能を構成するプログラムへそのまま実装することができる。

なお、図９（Ａ）〜図９（Ｂ）、さらには図１０に至る工程は、設計者などが人手で行うと作業負担が大きく効率的でない。そこで、本実施の形態２では、これらの工程を自動的に実行する設計支援プログラム（本実施の形態２に係る車両故障判定装置設計プログラムに相当）を用いることとする。以下に、各設計支援プログラムの役割を説明する。

（設計支援プログラムβ１）総診断相関表圧縮
設計支援プログラムβ１は、ＣＰＵ２０１によって実行される。設計支援プログラムβ１は、図９（Ａ）に示す総診断相関表から、「選択項目」列に“１”がセットされている項目のみを抽出し、図９（Ｂ）に示すリストを出力する。また、図９の横軸に示す各項目の値を別途取得し、配列上に対応付ける。図９の横軸に示す各値は、例えば設計支援プログラムβ１を実行するコンピュータ上にあらかじめ保存しておいてもよいし、設計者が入力してもよいが、効率の観点からはあらかじめ準備したものを読み込むほうが好ましい。

（設計支援プログラムβ２）リスト生成
設計支援プログラムβ２は、ＣＰＵ２０１によって実行される。設計支援プログラムβ２は、図９（Ｂ）に示すリストから、図１０に示すリストを生成する。どのような形式でリストを出力するかは、設計支援プログラムβ２内部で定めてもよいし、例えば設計支援プログラムβ２を実行するコンピュータ上にあらかじめそのルールを保存しておいてもよい。

（設計支援プログラム：補足その１）
各設計支援プログラムは、上記β１、β２のように２種類に分けてもよいし、単一のプログラムで両者の処理を実行するようにしてもよい。また、上記各設計支援プログラムに相当するプログラムを車両故障診断装置内部に構成してもよい。さらには、実施の形態１で説明した設計支援プログラムα１、α２と、本実施の形態２における設計支援プログラムβ１、β２を、一体化して構成してもよい。

（設計支援プログラム：補足その２）
本実施の形態２において、設計支援プログラムをβ１とβ２に分けた理由を補足しておく。図９（Ａ）に示す総診断相関表から、図９（Ｂ）に示す圧縮した診断相関表を作成した後、設計作業の過程で、システム構成が変更になる可能性がある。この場合、図９（Ａ）から改めて作業を行ってもよいが、圧縮した診断相関表を直接編集した方が効率的である場合も考えられる。例えば、一部の表セルの数値のみを「１」から「２」に変更する、といった場合である。そこで、本実施の形態２では、図９（Ａ）〜図１０に至る過程を２段階に分けるとともに、設計支援プログラムの機能もこれに対応させて２種類に分け、途中で編集作業を介入させることができるようにした。これにより、総診断相関表から一括的に診断相関定義リスト５００１を作成する処理と、圧縮された診断相関表を個別に編集する作業とを両立させることができるので、開発工数を大幅に効率化することができる。

以上、本実施の形態２に係る車両故障診断装置とその設計支援プログラムについて説明した。なお、１つの故障診断プログラムで複数の診断結果情報を出力するケースでは、診断相関判定部５０００が出力する各故障診断プログラムの実行許可指示や実行停止指示が同じ情報を基になされるようにしておくことが望ましい。具体的には、入力センサの電圧レベルが異常に高い、低いという状態を１つの故障診断プログラムで検出し、診断結果情報を、電圧レベルが高い、低いで分割する場合などがこれにあてはまる。

以上のように、本実施の形態２において、診断相関判定部５０００は、各故障診断プログラムの診断結果、または各故障診断対象がフェールセーフ状態にあるか否かの少なくともいずれかを用いて、故障診断の実行可否を判定する。これにより、故障診断項目が相互に関係する場合に、その相関関係を故障診断に反映することができる。

また、本実施の形態２によれば、診断相関判定部５０００は、上記相関関係を定義する診断相関定義リスト５００１を備え、これに基づき各故障診断プログラムの実行開始や実行停止を指示する。これにより、各故障診断プログラムの診断実行条件部を他の故障診断プログラムから切り離し、独立性を高めることができる。

また、本実施の形態２によれば、診断相関定義リスト５００１は、複数種類の診断結果を数値「１」〜「３」によって表し、各診断結果と他の故障診断プログラムの実行可否の相関関係を定義する。これにより、各診断プログラム相互の相関関係をより詳細に定義することができる。さらには、例えば『現在故障情報』を選択している場合は、運転中に故障状態が復帰した際に、直ぐにフェールセーフからの復帰が可能となる。また、『運転内故障情報』を選択している場合は、故障が復帰しても、運転中はフェールセーフを継続する機能選択が可能となる。また、『故障成立中情報』を選択している場合は、運転が停止、再開された場合にも、故障状態が復帰したと判定されない限りはフェールセーフを継続することができる。このように、特にフェールセーフ機能の起動を解除する条件を、フェールセーフ機能の復帰条件によって選択することが可能となる。

また、本実施の形態２によれば、『診断許可要求フラグ』は各故障診断プログラムおよびその故障診断結果情報と同じ配列番号を用いて診断結果情報記憶部４０００に格納されるので、これらの対応関係を容易に把握することができる。

また、本実施の形態２に係る車両故障判定装置設計プログラム（設計支援プログラムβ１、β２）は、総診断相関表から、当該車両の故障診断に必要な項目のみを抽出し、当該車両用の診断相関定義リスト５００１を生成する。これにより、設計者は必要な診断項目を選択するのみで、車両故障診断装置を任意の車両の仕様に対応させることができるので、開発工数を大幅に削減することができる。

＜実施の形態３＞
実施の形態２では、故障診断プログラム相互の相関関係に対応することのできる構成を説明した。本発明の実施の形態３では、故障診断プログラムの診断結果とフェールセーフ状態に移行してよいか否かとの相関関係に対応することのできる構成を説明する。その他の構成は概ね実施の形態１〜２いずれかと同様であるため、以下では差異点を中心に説明する。なお、以下では説明の便宜上、実施の形態２で説明した構成に加えて新たに上記構成を導入する例を示すが、実施の形態１で説明した構成に加え、上記構成を導入することもできる。本実施の形態３と実施の形態１を組み合わせる場合には、本実施の形態３で新たに説明する構成に加え、フェールセーフ状態判定部６０００またはこれに相当する機能部が必要である。

図１１は、本実施の形態３に係る車両故障診断装置の機能構成を模式的に示すブロック図である。本実施の形態３に係る車両故障診断装置は、実施の形態２の図６で説明した構成に加え、新たにフェールセーフ相関判定部７０００、フェールセーフ起動情報記憶部８０００を備える。

フェールセーフ相関判定部７０００は、フェールセーフ状態判定部６０００が格納している、各故障診断対象がフェールセーフ状態にあるか否かを表すフラグ（Ｆ／Ｓ状態フラグ６００１など）に基づき、車両が備える各フェールセーフ機能の実行許可と実行停止を指示する。また、各フェールセーフ機能の実行許可または実行停止を指示するために必要な事項を定義するフェールセーフ相関定義リスト７００１を有する。フェールセーフ相関判定部７０００は、各フェールセーフ機能の実行許可または実行停止の指示を、フェールセーフ起動情報記憶部８０００に格納する。格納先は、配列上の順番を用いて、各故障診断プログラムの診断結果情報と対応付けるようにする。

フェールセーフ起動情報記憶部８０００は、フェールセーフ相関判定部７０００の判定結果を格納する。格納形式は、各故障診断プログラム、その診断結果情報などと同じ配列番号で、配列形式とする。

以上、本実施の形態３に係る車両故障診断装置の構成について説明した。次に、故障診断プログラムの実行可否と、各診断対象項目がフェールセーフ状態であるか否かとが、相互に関連することについて説明する。

図１２は、故障診断プログラムの実行可否とフェールセーフ状態の相関関係を説明する図である。ここでは、ＲＯＭ２０２内に格納されている空燃比制御プログラム１００４を例に取り上げる。空燃比制御プログラム１００４は、故障診断プログラムとは別に構成された、エンジン制御を行うためのプログラムである。

図１２（Ａ）は、従来の空燃比制御プログラム１００４の構成を示す図である。空燃比制御プログラム１００４が空燃比補正量を正しく演算するためには、空燃比制御に影響するセンサ、例えば吸気管圧力センサ、空燃比センサが故障していない状態でなければならない。そのため、空燃比制御プログラム１００４はこれらの診断結果情報を参照する必要がある。これらが故障中であると判定している場合には、空燃比制御プログラム１００４は、空燃比補正量を初期値に戻すフェールセーフ状態に移行する。

また、通信により取得した外部指令などに基づき、通常制御状態ではない状態、例えば燃料噴射量を固定噴射状態などにしている場合には、制御を実行すると、異常な空燃比補正量を出力してしまう可能性がある。このような状況下では、空燃比制御プログラム１００４は空燃比補正量の演算をやめる必要があるので、上記と同様に空燃比補正量を初期値に戻すフェールセーフ状態に移行する。

実施の形態２で説明した、故障診断プログラム同士の相関関係と同様に、エンジンなどの車両構成要素を制御するプログラムにおいても、診断結果情報を参照してフェールセーフを実行する場合には、システム構成の変更に影響を受ける。例えば、システム構成が変更になり、空燃比の演算に用いる主センサが、吸気管圧力センサからエアフローセンサに変った場合を考える。このとき、制御プログラム内においてこれら診断結果情報を個別に参照している場合、プログラムを変更する必要があるため、開発効率が低下する。

さらには、フェールセーフ状態に移行するか否かを判定する際に、ある特定の診断項目がフェールセーフ状態であってはならないという制約がある場合には、診断結果情報に加えてフェールセーフ状態フラグ６００１なども参照する必要がある。

そこで、本実施の形態３では、空燃比制御プログラム１００４が参照する診断結果情報やフェールセーフ状態フラグなどの情報を、『フェールセーフ起動要求フラグ』として１つのフラグにまとめることとした。このフラグは、図１１の８００１〜８００Ｎに相当するものである。

図１２（Ｂ）は、本実施の形態３における空燃比制御プログラム１００４の構成を示す図である。『フェールセーフ起動要求フラグ』を導入することにより、制御プログラムの独立性を向上できる。

例えば、システム構成が変わった場合でも、『フェールセーフ起動要求フラグ』の初期値を「起動を禁止する」旨の値（本実施形態では０）としておけば、実行条件部を作成し直す必要はない。

また、システム構成が変更され、参照すべき診断結果情報やフェールセーフ状態情報を変更しなければならない場合でも、『フェールセーフ起動要求フラグ』の値を参照してフェールセーフ機能実行可否を判断するというロジックそのものは変更する必要はない。参照すべき診断結果情報やフェールセーフ状態情報を変更するには空燃比制御プログラム１００４が参照する『フェールセーフ起動要求フラグ』の値をセットするフェールセーフ相関判定部７０００のみを変更すればよい。なお、ここでは空燃比制御プログラム１００４を例に取り上げたが、他の制御プログラムについても同様である。

以上、本実施の形態３における故障診断プログラムとフェールセーフ機能の相関関係について説明した。次に、本実施の形態３におけるフェールセーフ相関の考え方、およびフェールセーフ相関判定部７０００の具体的な実装手法について説明する。

本実施の形態３では、実施の形態２で説明した総診断相関表と同様の手法を用いる。すなわち、図８における縦軸を診断項目に代えてフェールセーフ機能として構成した『フェールセーフ（Ｆ／Ｓ）相関表』を用いる。同表では、フェールセーフ機能毎に、診断結果情報を１つのフラグ情報にまとめて扱う。

図１３〜図１４は、上記『フェールセーフ（Ｆ／Ｓ）相関表』をより具体化したものを示す図である。図１３（Ａ）は『Ｆ／Ｓ総相関表』、図１３（Ｂ）は『圧縮したＦ／Ｓ相関表』、図１４（Ｃ）はフェールセーフ相関定義リスト７００１を示す。

フェールセーフ相関表の考え方は、診断相関表と同様である。図９で説明した診断相関表の縦軸をＦ／Ｓ機能項目に置換え、そのフラグとＲＡＭ名の情報を配列的に並べると、Ｆ／Ｓ相関表が得られる。圧縮したＦ／Ｓ相関表についても同様である。図１３（Ｂ）からさらに、Ｆ／Ｓ機能項目毎に配列順にリスト化し、（Ｃ−１）：フェールセーフ相関定義リスト７００１を得ることができる。

図１３中の（ｂ）に示すＦ／Ｓ３項目を例に、具体例を説明する。同項目を基準として数値１から３が設定されているセルを横軸方向に検索し、ＲＡＭ名、ＮＧフラグの値を抽出すると、０ｘＦＦを含め３項目が検索される。この場合、参照情報数：３となる。数値は図９〜図１０と同様にフラグ名で置き換え、図１４（Ｃ）に示したようにリスト化する。

本実施形態３では、診断項目に比べてＦ／Ｓ機能の数が少ないことから、実施の形態１〜２で説明したように、Ｆ／Ｓ項目のうち「選択項目」列の値が１であるもののみを抽出するという過程を省略した。ただし、Ｆ／Ｓ項目数が多大となるようであれば、実施形態１〜２と同様にＦ／Ｓ機能項目も選択するようにし、再配列したフラグおよびＲＡＭ名と、これを参照する各制御プログラム側とのインタフェース定義を、これに加えて作成するようにしてもよい。

なお、図１３（Ａ）〜図１４（Ｃ）に至る工程は、設計者などが人手で行うと作業負担が大きく効率的でない。そこで、本実施の形態３では、これらの工程を自動的に実行する設計支援プログラム（本実施の形態３に係る車両故障判定装置設計プログラムに相当）を用いることとする。以下に、各設計支援プログラムの役割を説明する。

（設計支援プログラムγ１）フェールセーフ断相関表圧縮
設計支援プログラムγ１は、ＣＰＵ２０１によって実行される。設計支援プログラムγ１は、図１３（Ａ）に示すＦ／Ｓ総相関表から、横軸の「選択項目」列に“１”がセットされている項目のみを抽出し、図１３（Ｂ）に示すリストを出力する。また、図１３の横軸に示す各項目の値を別途取得し、配列上に対応付ける。図１３の横軸に示す各値は、例えば設計支援プログラムγ１を実行するコンピュータ上にあらかじめ保存しておいてもよいし、設計者が入力してもよいが、効率の観点からはあらかじめ準備したものを読み込むほうが好ましい。

（設計支援プログラムγ２）リスト生成
設計支援プログラムγ２は、ＣＰＵ２０１によって実行される。設計支援プログラムγ２は、図１３（Ｂ）に示すリストから、図１４（Ｃ）に示すリストを生成する。どのような形式でリストを出力するかは、設計支援プログラムγ２内部で定めてもよいし、例えば設計支援プログラムγ２を実行するコンピュータ上にあらかじめそのルールを保存しておいてもよい。

（設計支援プログラム：補足その１）
各設計支援プログラムは、上記γ１、γ２のように２種類に分けてもよいし、単一のプログラムで両者の処理を実行するようにしてもよい。また、上記各設計支援プログラムに相当するプログラムを車両故障診断装置内部に構成してもよい。さらには、実施の形態１〜２で説明した設計支援プログラムα１、α２、β１、β２のいずれか1ないし複数と一体化して構成してもよい。

（設計支援プログラム：補足その２）
本実施の形態３において、設計支援プログラムをγ１とγ２に分けた理由は、実施の形態２における設計支援プログラムβ１、β２を分けた理由と同様である。

以上、本実施の形態３に係る車両故障診断装置および車両故障診断装置設計プログラムについて説明した。

以上のように、本実施の形態３において、フェールセーフ相関判定部７０００は、各故障診断プログラムの診断結果、または各故障診断対象がフェールセーフ状態にあるか否かの少なくともいずれかを用いて、フェールセーフ機能の実行可否を判定する。これにより、フェールセーフ機能項目が相互に関係する場合に、その相関関係をフェールセーフ機能の起動・停止制御に反映することができる。

また、本実施の形態３によれば、フェールセーフ相関判定部７０００は、上記相関関係を定義するフェールセーフ相関定義リスト７００１を備え、これに基づき各フェールセーフ機能の実行開始や実行停止を指示する。これにより、各フェールセーフ機能の実行条件部を他の制御プログラムから切り離し、独立性を高めることができる。

また、本実施の形態３によれば、フェールセーフ相関定義リスト７００１は、複数種類の診断結果を数値「１」〜「３」によって表し、各診断結果とフェールセーフ機能の実行可否の相関関係を定義する。これにより、各フェールセーフ機能相互の相関関係をより詳細に定義することができる。

また、本実施の形態３によれば、『フェールセーフ起動要求フラグ』は各故障診断プログラムおよびその故障診断結果情報と同じ配列番号を用いてフェールセーフ起動情報記憶部８０００に格納されるので、これらの対応関係を容易に把握することができる。

また、本実施の形態３に係る車両故障判定装置設計プログラム（設計支援プログラムγ１、γ２）は、総フェールセーフ相関表から、当該車両の故障診断に必要な項目のみを抽出し、当該車両用のフェールセーフ相関定義リスト７００１を生成する。これにより、設計者は必要な診断項目を選択するのみで、車両故障診断装置を任意の車両の仕様に対応させることができるので、開発工数を大幅に削減することができる。

＜実施の形態４＞
本発明の実施の形態４では、実施の形態１〜３で説明した各機能部および各設計支援プログラムの動作フローについて説明する。なお、以下の説明において、説明の便宜上各プログラムが動作主体であるものとして記載する場合があるが、実際の動作主体は各プログラムを実行するＣＰＵ２０１などの演算装置である。

図１５は、診断結果統括処理部３０００の動作のうち、ＯＫフラグを受け取った場合のフローを示す図である。以下、図１５の各ステップについて説明する。

（図１５：ステップＳ１４０１）
各故障診断プログラムは、診断結果として、ＯＫ／ＮＧフラグなどを出力する。診断結果統括処理部３０００がその出力を受け取った時点で、本ステップが開始される。受け取った出力がＯＫフラグであればステップＳ１４０２へ進み、それ以外であれば本動作フローを終了する。

（図１５：ステップＳ１４０２）
診断結果統括処理部３０００は、ステップＳ１４０１で受け取った診断項目に対応する配列番地の情報を、受け取った出力に付加する。診断結果統括処理部３０００は、図５などで説明した『診断名』列で定義された情報から、当該診断項目に対応する配列番地を得ることができる。

（図１５：ステップＳ１４０３）
診断結果統括処理部３０００は、運転内診断完了フラグを、診断結果情報記憶部４０００の当該診断項目に対応する配列上のビットに書き込む。運転内診断完了フラグは、ＯＫ／ＮＧフラグが当該診断項目について既に出力されたこと、すなわち診断が完了した旨を表すフラグである。

（図１５：ステップＳ１４０４）
診断結果統括処理部３０００は、診断結果情報記憶部４０００の当該診断項目に対応する配列上の『現在故障』フラグをクリアする。このフラグは、対応する診断対象が故障中であるか否かを表すフラグである。

（図１５：ステップＳ１４０５）
診断相関判定部５０００は、当該故障診断プログラムの実行可否を指示するビットを、診断結果情報記憶部４０００の対応する配列上の『診断許可』フラグに書き込む。また、フェールセーフ相関判定部７０００は、『フェールセーフ起動要求』フラグをフェールセーフ起動情報記憶部８０００に書き込む。診断結果統括処理部３０００は、以上の処理が終了した後、本動作フローを終了する。

以上のように、診断結果情報記憶部４０００が格納している配列内の各ビット（フラグ）の名称および位置を、同じ名称で定義することによって、プログラム処理上は配列名だけを変えれば同じ処理として扱えるので、診断結果統括処理部３０００は独立した処理とすることができる。これにより、診断結果統括処理部３０００は各故障診断プログラム等の影響を受けにくくなり、独立性が高まる。

図１６は、診断結果統括処理部３０００の動作のうち、ＮＧフラグを受け取った場合のフローを示す図である。以下、図１６の各ステップについて説明する。

（図１６：ステップＳ１５０１）
診断結果統括処理部３０００は、各故障診断プログラムから受け取った出力がＮＧフラグであればステップＳ１５０２へ進み、それ以外であれば本動作フローを終了する。

（図１６：ステップＳ１５０２〜Ｓ１５０３）
本ステップは、図１５のステップＳ１４０２〜Ｓ１４０３と同様である。

（図１６：ステップＳ１５０４）
診断結果統括処理部３０００は、診断結果情報記憶部４０００の当該診断項目に対応する配列上に『現在故障』フラグをセットする。

（図１６：ステップＳ１５０５）
診断結果統括処理部３０００は、ランプ用のカウンタをカウントアップする。

（図１６：ステップＳ１５０６）
診断結果統括処理部３０００は、診断制御用データ記憶部２０００に格納されている制御データのうち当該診断項目に対応する配列番地のものを取得する。診断結果統括処理部３０００は、ランプ用のカウンタが同制御データの判定回数欄で定義されている数値に達したか否かを判断する。達していればステップＳ１５０７へ進み、達していなければＳ１５１０へスキップする。上述の判断は、ランプを点灯するためのＮＧ検出回数を任意に設定できることを示しており、判定回数欄で定義することで、各国の法規制あるいは、カーメーカ毎の要求に対する汎用性を向上している。

（図１６：ステップＳ１５０７）
診断結果統括処理部３０００は、診断結果情報記憶部４０００の当該診断項目に対応する配列上に『ランプＯＮ要求』フラグをセットする。

（図１６：ステップＳ１５０８）
診断結果統括処理部３０００は、診断結果情報記憶部４０００の当該診断項目に対応する配列上に、Ｐコード等のＤＴＣ（ダイアグノーシス・トラブル・コード）の情報をセットする。

（図１６：ステップＳ１５０９）
診断結果統括処理部３０００は、ＤＴＣをクリアするための回数をセットする。

（図１６：ステップＳ１５１０）
本ステップは、図１５のステップＳ１４０５と同様である。

図１７は、診断結果統括処理部３０００の動作のうち、車両故障診断装置の始動時または終了時などに実行されるフローを示す図である。以下、図１７の各ステップについて説明する。

（図１７：ステップＳ１６０１）
診断結果統括処理部３０００は、配列番地を０から順番にセットする。本ステップを再度実行するときは、配列番地を１つずつ増やす。本ステップは、診断項目のカウンタを１つずつ順次増やす役割を有する。

（図１７：ステップＳ１６０２）
診断結果統括処理部３０００は、運転内で故障診断が完了し、かつ故障がなかったかどうかを判定する。これは、診断結果情報記憶部４０００の当該診断項目に対応する配列上の『運転内診断完了』フラグと『運転内故障』フラグを参照することにより判定できる。運転内で故障診断が完了し、かつ故障がなければ、ステップＳ１６０３へ進む。いずれかの条件を満たさなければステップＳ１６０９へ進む。

（図１７：ステップＳ１６０３）
本ステップは、図１５のステップＳ１４０４と同様である。

（図１７：ステップＳ１６０４）
診断結果統括処理部３０００は、ランプの消灯用回数とＤＴＣの消去用回数をカウントする。

（図１７：ステップＳ１６０５）
ステップＳ１６０４でカウントした回数がランプ消灯回数に達している場合はステップＳ１６０６に進み、そうでなければステップＳ１６０９に進む。

（図１７：ステップＳ１６０６）
診断結果統括処理部３０００は、診断結果情報記憶部４０００の当該診断項目に対応する配列上における『ランプＯＮ要求』フラグをクリアする。

（図１７：ステップＳ１６０７）
ステップＳ１６０４でカウントした回数がＤＴＣクリア回数に達している場合はステップＳ１６０８に進み、そうでなければステップＳ１６０９に進む。

（図１７：ステップＳ１６０８）
診断結果統括処理部３０００は、ＤＴＣ関連情報をクリアする。

（図１７：ステップＳ１６０９）
診断結果統括処理部３０００は、全ての配列番地について以上の処理を終了したか否かを判定する。終了していなければステップＳ１６０１に戻って同様の処理を次の配列番地について実行し、終了していればステップＳ１６１０へ進む。

（図１７：ステップＳ１６１０）
本ステップは、図１５のステップＳ１４０５と同様である。

図１８は、図１５のステップＳ１４０５等において診断相関判定部５０００が実行する処理フローである。以下、図１８の各ステップについて説明する。

（図１８：ステップＳ１７０１）
診断相関判定部５０００は、配列番地を０から順番にセットする。本ステップを再度実行するときは、配列番地を１つずつ増やす。本ステップは、診断項目のカウンタを１つずつ順次増やす役割を有する。

（図１８：ステップＳ１７０２）
診断相関判定部５０００は、診断相関定義リスト５００１のうちステップＳ１７０１でセットした配列番地の内容を取得する。診断相関判定部５０００は、同配列番地の内容が定義する各フラグの値を取得する。

（図１８：ステップＳ１７０３）
ステップＳ１７０２で取得した全てのフラグの値が０であればステップＳ１７０４へ進み、０でない値があればステップＳ１７０５へ進む。

（図１８：ステップＳ１７０４）
診断相関判定部５０００は、故障している診断対象がない、またはフェールセーフ状態の診断対象がないと判断し、診断結果情報記憶部４０００の当該配列番地に対応する配列上における『診断許可』フラグをセットする。これは、当該診断項目の診断を許可することに相当する。

（図１８：ステップＳ１７０５）
診断相関判定部５０００は、診断結果情報記憶部４０００の当該配列番地に対応する配列上における『診断許可』フラグをクリアする。これは、当該診断項目の診断を禁止することに相当する。

（図１８：ステップＳ１７０６）
診断相関判定部５０００は、全ての配列番地について以上の処理を終了したか否かを判定する。終了していなければステップＳ１７０１に戻って同様の処理を次の配列番地について実行し、終了していれば本動作フローを終了する。

図１９は、図１５のステップＳ１４０５等においてフェールセーフ相関判定部７０００が実行する処理フローである。以下、図１９の各ステップについて説明する。

（図１９：ステップＳ１８０１）
フェールセーフ相関判定部７０００は、配列番地を０から順番にセットする。本ステップを再度実行するときは、配列番地を１つずつ増やす。本ステップは、診断項目のカウンタを１つずつ順次増やす役割を有する。

（図１９：ステップＳ１８０２）
フェールセーフ相関判定部７０００は、フェールセーフ相関定義リスト７００１のうちステップＳ１８０１でセットした配列番地の内容を取得する。フェールセーフ相関判定部７０００は、同配列番地の内容が定義する各フラグの値を取得する。

（図１９：ステップＳ１８０３）
ステップＳ１８０２で取得した全てのフラグの値が０であればステップＳ１８０４へ進み、０でない値があればステップＳ１８０５へ進む。

（図１９：ステップＳ１８０４）
フェールセーフ相関判定部７０００は、故障している診断対象がない、またはフェールセーフ状態の診断対象がないと判断し、フェールセーフ起動情報記憶部８０００の当該配列番地に対応する配列上における『起動要求』フラグをセットする。これは、当該フェールセーフ機能の実行を許可することに相当する。

（図１９：ステップＳ１８０５）
フェールセーフ相関判定部７０００は、フェールセーフ起動情報記憶部８０００の当該配列番地に対応する配列上における『起動要求』フラグをクリアする。これは、当該フェールセーフ機能の実行を禁止することに相当する。

（図１９：ステップＳ１８０６）
フェールセーフ相関判定部７０００は、全ての配列番地について以上の処理を終了したか否かを判定する。終了していなければステップＳ１８０１に戻って同様の処理を次の配列番地について実行し、終了していれば本動作フローを終了する。

図２０は、本発明における故障診断プログラムの１例として、吸気管圧力センサ機能診断プログラム１００３の動作フローを説明する図である。以下、図２０の各ステップについて説明する。

（図２０：ステップＳ１９００）
本動作フローは、所定の時間間隔毎（例えば４０ｍｓ）に実行される。

（図２０：ステップＳ１９０１）
吸気管圧力センサ機能診断プログラム１００３は、診断結果情報記憶部４０００のうち吸気管圧力センサ機能診断プログラム１００３の診断項目に対応する配列番号の配列値を取得する。吸気管圧力センサ機能診断プログラム１００３は、取得した配列値のうち『診断許可要求』フラグの値をチェックする。同フラグに『診断許可』の旨がセットされていればステップＳ１９０２へ進み、セットされていなければ本動作フローを終了する。

（図２０：ステップＳ１９０２）
吸気管圧力センサ機能診断プログラム１００３は、判定に適した運転条件であるかをチェックする。条件不成立であれば本動作フローを終了する。条件成立の時は、ステップＳ１９０３へ進む。

（図２０：ステップＳ１９０３）
吸気管圧力センサ機能診断プログラム１００３は、吸気管圧力センサ値を取り込む。

（図２０：ステップＳ１９０４）
フェールセーフ状態判定部６０００（または吸気管圧力センサ機能診断プログラム１００３）は、ステップＳ１９０３で取り込んだセンサ出力値から、当該診断対象がフェールセーフ状態にあるか否かを判定する。フェールセーフ状態であればステップＳ１９０５へ進み、フェールセーフ状態でなければステップＳ１９０６へ進む。

（図２０：ステップＳ１９０５）
フェールセーフ状態判定部６０００（または吸気管圧力センサ機能診断プログラム１００３）は、吸気管圧力センサ機能診断プログラム１００３の診断項目に対応するＦ／Ｓ状態フラグをセットする。本ステップにおいて、Ｆ／Ｓ状態フラグは必ずしも１つのみである必要はなく、制御目的に応じた複数のＦ／Ｓ状態フラグの値をセットするようにしてもよい。Ｆ／Ｓ状態フラグの使用目的は、Ｆ／Ｓ相関表における横軸のＦ／Ｓ状態フラグを作成することであるので、故障診断プログラムの実行許可／実行禁止、あるいは各フェールセーフ機能の起動／停止に関わる目的毎に、フラグを適宜分けて設定すればよい。次のステップＳ１９０６においても同様である。

（図２０：ステップＳ１９０６）
フェールセーフ状態判定部６０００（または吸気管圧力センサ機能診断プログラム１００３）は、吸気管圧力センサ機能診断プログラム１００３の診断項目に対応するＦ／Ｓ状態フラグをクリアする。

（図２０：ステップＳ１９０７）
吸気管圧力センサ機能診断プログラム１００３は、ステップＳ１９０３で取得したセンサ出力値が故障判定用の所定範囲内にあるか否かをチェックする。範囲内であればステップＳ１９０８へ進み、範囲内でなければステップＳ１９０９へ進む。

（図２０：ステップＳ１９０８）
吸気管圧力センサ機能診断プログラム１００３は、ＯＫ判定用の継続時間を計測する。継続時間が所定の時間に達しない場合は本動作フローを終了し、達していればステップＳ１９１０へ進む。

（図２０：ステップＳ１９０９）
吸気管圧力センサ機能診断プログラム１００３は、ＮＧ判定用の継続時間を計測する。継続時間が所定の時間に達しない場合は本動作フローを終了し、達していればステップＳ１９１１へ進む。

（図２０：ステップＳ１９１０）
吸気管圧力センサ機能診断プログラム１００３は、診断結果情報記憶部４０００のうち吸気管圧力センサ機能診断プログラム１００３の診断項目に対応する配列番号の『現在故障』フラグをセットする。

（図２０：ステップＳ１９１１）
吸気管圧力センサ機能診断プログラム１００３は、診断結果情報記憶部４０００のうち吸気管圧力センサ機能診断プログラム１００３の診断項目に対応する配列番号の『現在故障』フラグをクリアする。

（図２０：ステップＳ１９１２）
吸気管圧力センサ機能診断プログラム１００３は、判定成立フラグをセットする。

以上のように、診断相関判定部５０００およびフェールセーフ相関判定部７０００は、全ての配列番地に定義された診断項目について順次ループ処理を実行する。そのため、項目数が多いと、検索および演算するための負荷が重くなる。

そこで本発明では、故障診断プログラムがＯＫ／ＮＧフラグを出力するタイミングと、始動時または停止時の処理において上記各フローを実行することとし、複数項目についての処理タイミングが重なる状況をできるだけ避けるようにしている。ただし、処理能力の速いＣＰＵを用いて上記処理を実行するのであれば、実用上の問題はない。

また、演算負荷を低減するその他の手法として、診断項目全ての配列を処理するのではなく、診断相関定義リスト５００１やフェールセーフ相関定義リスト７００１を生成する際に、抽出する項目を限定する手法も考えられる。すなわち、図１０や図１４（Ｃ）で説明した各定義リストでは、項目が存在していない配列要素についても配列要素として０ｘＦＦを記載し、項目そのものは残すようにしているが、これに代えて、項目が存在しない配列要素は最初から除去し、図９（Ｂ）や図１３（Ｂ）で説明した相関表において、横軸の診断項目基準で、ＮＧ検出時に、縦軸方向を検索して、禁止するべき診断項目の『診断許可要求フラグ』や実行するべきフェールセーフ項目の『フェールセーフ起動要求フラグ』をセットするように定義リストを作成しておく、という手法である。

しかし上記のように定義リストを構成すると、故障状態情報（『現在故障情報』、『運転内故障情報』、『故障成立中情報』のいずれか）に基づき診断実行可否やフェールセーフ機能の実行可否を制御するためには、１つの横軸の診断項目に対して３パターンの故障状態情報を予め設定しておく必要があり、これを用いて制御対象項目を作成しなければならない。

そうすると、故障診断プログラムおよび定義リストが複雑化する。また、各制御対象項目のフラグなどの格納場所（すなわち項目名とこれに対応する配列番地を示す対応保存場所）の定義情報をそれぞれ記憶部に格納しておかなければならないため、プログラム処理上の効率がよくない。また、さらに関連付けに用いる定義情報が増えることになるので、項目数が数百個となるような場合には、相関表などを圧縮する処理には向いていない。

以上、本実施の形態４では、実施の形態１〜３で説明した各機能部および各設計支援プログラムの動作フローについて説明した。

本発明に係る車両故障診断装置設計プログラムは、例えばＪａｖａ（登録商標）言語や、表計算ソフトのマクロ原語などを用いて開発するソフトウェアプログラムとして実装することができる。

１０１：クランク角センサ、１０２：カム角センサ、１２０：吸気管圧力センサ、１２１：吸気温度センサ、１２２：エンジン水温センサ、１２３：大気圧センサ、１２４：スロットルセンサ、１２５：空燃比センサ、２００：エンジンコントロールユニット、２０１：ＣＰＵ、２０２：ＲＯＭ、２０３：Ａ／Ｄ変換器、２０４：ＲＡＭ、２１０：入力処理回路、２２０：出力回路、２３０：モニタ回路、１０００：故障診断部、２０００：診断制御用データ記憶部、３０００：診断結果統括処理部、４０００：診断結果情報記憶部、５０００：診断相関判定部、５００１：診断相関定義リスト、６０００：フェールセーフ状態判定部、７０００：フェールセーフ相関判定部、７００１：フェールセーフ相関定義リスト、８０００：フェールセーフ起動情報記憶部。

Claims (14)

1. 車両の故障を判定する装置であって、
   前記車両の故障診断項目について故障診断を行う１以上の故障診断プログラムを実行して故障診断を行う故障診断部と、
   各前記故障診断プログラム、その故障診断プログラムを実行する際に用いられる制御データ、および各前記故障診断プログラムの診断結果データの対応順序を定義する診断制御部と、
   を備えたことを特徴とする車両故障判定装置。
2. 前記故障診断プログラムの診断結果に基づき他の前記故障診断プログラムの実行許可または実行停止を指示する診断相関判定部を備えた
   ことを特徴とする請求項１記載の車両故障判定装置。
3. 前記診断相関判定部は、
   前記故障診断プログラムの診断結果と他の前記診断プログラムの実行許可または実行停止の相関関係を定義する診断相関定義リストを備え、
   前記故障診断プログラムの診断結果と前記診断相関定義リストを照合して前記故障診断プログラムの実行許可または実行停止を指示する
   ことを特徴とする請求項２記載の車両故障判定装置。
4. 前記診断相関定義リストは、
   前記故障診断項目の複数種類の故障状態と他の前記診断プログラムの実行許可または実行停止の相関関係を定義しており、
   前記診断相関判定部は、
   前記故障状態と前記診断相関定義リストを照合して前記故障診断プログラムの実行許可または実行停止を指示する
   ことを特徴とする請求項３記載の車両故障判定装置。
5. 前記診断相関判定部は、
   前記診断制御部が定義する前記対応順序と同じ対応順序で、前記故障診断プログラムの診断結果と他の前記故障診断プログラムの実行許可または実行停止の指示を相互に対応付ける
   ことを特徴とする請求項２から請求項４のいずれか１項に記載の車両故障判定装置。
6. 前記故障診断プログラムの診断結果に基づき前記車両が備えるフェールセーフ機能の実行許可または実行停止を指示するフェールセーフ相関判定部を備えた
   ことを特徴とする請求項１から請求項５のいずれか１項に記載の車両故障判定装置。
7. 前記フェールセーフ相関判定部は、
   前記故障診断プログラムの診断結果と前記車両が備えるフェールセーフ機能の実行許可または実行停止の相関関係を定義するフェールセーフ相関定義リストを備え、
   前記故障診断プログラムの診断結果と前記フェールセーフ相関定義リストを照合して前記フェールセーフ機能の実行許可または実行停止を指示する
   ことを特徴とする請求項６記載の車両故障判定装置。
8. 前記フェールセーフ相関定義リストは、
   前記故障診断項目の複数種類の故障状態と他の前記フェールセーフ機能の実行許可または実行停止の相関関係を定義しており、
   前記フェールセーフ相関判定部は、
   前記故障状態と前記フェールセーフ相関定義リストを照合して前記フェールセーフ機能の実行許可または実行停止を指示する
   ことを特徴とする請求項７記載の車両故障判定装置。
9. 前記フェールセーフ相関判定部は、
   前記診断制御部が定義する前記対応順序と同じ対応順序で、前記車両が備えるフェールセーフ機能の実行許可または実行停止の指示を相互に対応付ける
   ことを特徴とする請求項６から請求項８のいずれか１項に記載の車両故障判定装置。
10. 車両の故障を判定する装置を設計するための処理をコンピュータに実行させるプログラムであって、
    前記コンピュータに、
    前記車両の故障診断項目となり得る全ての項目を記述した総診断項目リストを読み込むステップと、
    前記総診断項目リストが記述している前記故障診断項目のうち前記車両に対応する故障診断項目を抽出して当該車両の故障診断項目リストを生成するステップと、
    を実行させることを特徴とする車両故障判定装置設計プログラム。
11. 前記コンピュータに、
    前記故障診断項目の診断結果と他の前記故障診断項目の故障診断を行うか否かの相関関係を、前記車両の故障診断項目となり得る全ての項目について定義する総診断相関定義リストを読み込むステップと、
    前記総診断相関定義リストが定義している前記相関関係のうち前記車両に対応する故障診断項目に係るものを抽出して当該車両の診断相関定義リストを生成するステップと、
    を実行させることを特徴とする請求項１０記載の車両故障判定装置設計プログラム。
12. 前記総診断相関定義リストは、
    前記故障診断項目の複数種類の故障状態と他の前記故障診断項目の故障診断を行うか否かの相関関係を定義している
    ことを特徴とする請求項１１記載の車両故障判定装置設計プログラム。
13. 前記コンピュータに、
    前記故障診断項目の診断結果と前記車両が備えるフェールセーフ機能を実行するか否かの相関関係を、前記車両の故障診断項目となり得る全ての項目および前記車両のフェールセーフ機能となり得る全ての機能について定義する総フェールセーフ相関定義リストを読み込むステップと、
    前記総フェールセーフ相関定義リストが定義している前記相関関係のうち前記車両に対応する故障診断項目および前記車両のフェールセーフ機能に係るものを抽出して当該車両のフェールセーフ相関定義リストを生成するステップと、
    を実行させることを特徴とする請求項１０から請求項１２のいずれか１項に記載の車両故障判定装置設計プログラム。
14. 前記総フェールセーフ相関定義リストは、
    前記故障診断項目の複数種類の故障状態と前記フェールセーフ機能を実行するか否かの相関関係を定義している
    ことを特徴とする請求項１３記載の車両故障判定装置設計プログラム。

Images