JP3659017B2 - 自己診断装置を備えた車両用制御装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は車両用制御装置に関し、特に自動車に搭載されたセンサ類、アクチュエータ類等の異常発生状態を自己診断する自己診断装置を備えた車両用制御装置に関する。
【０００２】
【従来の技術】
例えば、特開平７−９１３１０号公報には、車両用制御装置の自己診断装置の一例が開示されている。従来より、多くの自動車エンジンは電子制御装置により制御され、この電子制御装置にはエンジン制御システムの異常個所を検出する自己診断機能を備えている。そして異常を検出した場合には、表示ランプを点灯して運転者への警告を促し、或いは外部診断装置に対し異常個所を示す異常コードを出力してディーラーやサービス工場の作業者が異常個所を特定させる等の機能を備えている。
【０００３】
図１８は従来技術における異常フラグ、ランプ点灯用フラグ、異常コードフラグのメモリエリアの説明図である。また、図１９は異常コード判定用テーブルの説明図である。図１８に示すように、表示ランプを点灯し異常コードを出力するために、電子制御装置内のメモリはその使用及び用途毎に複数のフラグ情報を格納している。
【０００４】
図１８において、（Ａ）は現在異常フラグを格納するメモリエリアを示し、そのメモリエリア内のビット位置は異常検出対象毎に対応して予め設定されている。即ち、１ビット目が水温センサ用のビット位置、２ビット目が吸気温センサ用のビット位置、３ビット目がスロットルセンサ用のビット位置、４ビット目がＥＣＴソレノイド用のビット位置である。そして、図示しない異常検出ルーチンにて異常と判断した場合に、異常検出対象に該当するビット情報が「０」から「１」に変化する。
【０００５】
また、（Ｂ）は表示ランプ点灯用フラグを格納するメモリエリアを示し、表示ランプ点灯用フラグの情報は現在異常フラグ（Ａ）でのビット情報を、所定時間毎にコピーすることにより常に最新の値が格納されている。そして、表示ランプ点灯用フラグエリア内のビット情報の内、１つでも異常を示すデータがあるなら表示ランプが点灯される。
【０００６】
さらに、（Ｃ）は異常コードフラグを格納するメモリエリアを示し、異常コードフラグの情報と現在異常フラグでのビット情報を、所定時間毎にコピーすることにより常に最新の値が格納される。そして、この情報はディーラーやサービス工場の作業者が所望の操作をすることにより外部に読み出される。
なお、異常コードフラグの情報は、そのまま出力してもどの部品が異常であるかを特定できないため、一般的には、図１９に示すように、異常コードフラグのビット位置と出力コードとを対応させたテーブルを電子制御装置内に用意し、このテーブルにより変換されたコードが外部に読み出される。例えば、水温センサに異常が発生した場合には、「１１」というコードが出力されることになる。
【０００７】
このような、従来の故障診断装置では、
１）現在異常フラグ、表示ランプ点灯用フラグ等の各フラグエリアのビット位置情報の対応関係（１ビット目は水温センサ等）は等しく、これにより、各異常検出情報をバイト単位でコピー（処理）できる。
２）現在発生した異常を記憶する目的、ランプ表示する目的等の各使用目的毎にメモリエリアを設け、各メモリエリアには全ての異常検出対象情報を集約させているため、一括処理できるアクセス回数が減りメモリ容量を削減できる。例えば、異常の誤検出防止のため、イグニッション・キーがオフした状態での異常検出結果を無効にする場合には、現在異常フラグの各ビット情報を一括して「０」にすることで達成できる。
【０００８】
【発明が解決しようとする課題】
しかしながら、上述した従来の技術では、異常検出プログラムを異なるエンジン制御システムに適応する場合、或いは、仕様変更等の理由により異常検出対象が増加した場合、各メモリエリアのビットの定義に始まり図１９のような各種テーブルに至るまで全て変更する必要があった。
【０００９】
具体的には、例えば、自動変速機（Ａ／Ｔ）付き自動車に手動変速機（Ｍ／Ｔ）付き自動車の設定が増えた場合には、Ａ／Ｔ制御ソレノイドに関するビット、テーブルの削除、Ｍ／Ｔ専用のダイアグの追加等の作業を必要とする。そのためにプログラム開発工数が膨大となっていた。さらに、このような変更を全て完了しないと、プログラムの動作確認（デバック）ができず作業性の悪化も来していた。
【００１０】
本発明は、異常検出対象が増減しても異常検出処理に関わるメモリ情報、テーブル等の変更個所を極力低減させ、プログラム開発工数を低減させた車両用制御装置の自己診断装置を提供することを目的とする。
【００１１】
【課題を解決するための手段】
請求項１〜４の発明によれば、従来は、異常検出プログラムを異なるエンジン制御システムに適用する場合、或いは仕様変更などの理由で異常検出対象が増加した場合、各メモリエリアのビット定義から各種テーブルに至るまで全て変更する必要があったが、本発明では異常検出対象が増減しても、異常検出処理に関わるメモリ情報やテーブル等の変更個所を極力低減させ、その結果プログラムの開発工数を著しく低減させることができ、ソフトウェアの再利用性を顕著に向上させることができる。
【００１２】
【発明の実施の形態】
以下に、本発明の一実施形態を図面を参照して説明する。図１は異常診断を行うエンジン制御システムの一例構成図である。エンジン１１には、エアクリーナからの吸入空気が吸気管１２を経て供給されている。この吸気管１２には、吸入空気量を測定するエアフローセンサ１３と、吸気温度を検出する吸気温センサ１４が配置され、さらに、アクセルペダルによって駆動されるスロットル弁１５が配置されている。このエンジン１１は、マイクロコンピュータ等によって構成されるエンジン制御ユニット１６によって制御され、エンジン制御ユニット１６には、エアフローセンサ１３からの吸入空気量検出信号、スロットルセンサ１７からのスロットル弁１５の開度状態を検出する検出信号が供給される。
【００１３】
エンジン制御ユニット１６には、さらに排出ガス中に含まれる酸素濃度を検出する空燃比センサ１８からの検出信号、バッテリ１９からのバッテリ電圧信号、水温センサ２０からの検出信号、エンジン１１によって駆動されるディストリビュータ２１からの回転信号、さらに気筒判別信号等、エンジン１１の運転状態に対応した各種検出信号が供給される。
【００１４】
また、エンジン制御ユニット１６では、これらの各種検出信号に基づいてエンジン１１の運転状態に対応した燃料噴射量等を演算し、エンジン１１の複数の気筒それぞれに設定されるインジェクタ２２ａ〜２２ｄに対して燃料噴射指令を出力し、また、イグナイタ２３に対して点火指令信号を出力して、このエンジン１１の運転制御を実行する。
【００１５】
さらに、エンジン制御ユニット１６では、車両に搭載される各種制御装置の異常診断動作も各センサ群からの検出信号に基づいて実行される。このため、エンジン制御ユニット１６に対しては、異常検出結果の出力のための診断モードを設定するテストスイッチ２４が配置され、さらに、そのテスト結果であるダイアグノーシスの結果表示等を行う表示ランプ２５が接続されている。
【００１６】
さらに、スイッチ２６はバッテリ１９をエンジン制御ユニット１６に対して接続するイグニッションスイッチであり、このイグニッションスイッチ２６に連動するようにしてスタータモータ２７を制御するスタータスイッチ２８が設けられている。
図２は図１のエンジン制御ユニットの基本的な構成を説明するブロック図である。エンジン制御ニット１６はマイクロコンピュータを構成するＣＰＵ３１を備える。このＣＰＵ３１にはアナログ入力回路３２及びディジタル入力回路３３からのデータが入力され、アナログ入力回路３２からのアナログ入力データは、Ａ／Ｄ変換器３４でディジタルデータに変換されＣＰＵ３１に入力される。
【００１７】
また、アナログ入力回路３２には、エアフローセンサ１３からの検出信号Ｕｓ、水温センサ２０からの検出信号Ｔｈｗ、吸気センサ１４からの検出信号Ｔｈａ、バッテリ１９の電圧＋Ｂ、等が入力される。また、ディジタル入力回路３３には、ディストリビュータ２１からの気筒判別信号Ｇ１と回転数信号Ｎｅ、空燃比センサ１８からの酸素濃度に対応したリーン・リッチ信号Ｏｘ、スロットルセンサ１７からのスロットル弁１５が全開であることを示すアイドル信号Ｉｄｌｅ、スタータスイッチ２８からのスタート信号ＳＴＡ、及びテストスイッチ２４からの診断モードを設定する信号Ｔ、等が入力される。
【００１８】
また、Ａ／Ｄ変換器３４は、アナログ入力回路３２に入力される各種の検出信号をＣＰＵ３１からの指令に対応して順次選択して読み取り、ディジタルデータに変換するマルチプレクサ機能を含んで構成される。さらに、電源回路３５は、イグニッションスイッチ２６を経てバッテリ１９の電圧＋ＢをＣＰＵ３１に供給し、また、常時バックアップ用電源Ｂａｔｔを供給している。
【００１９】
ＣＰＵ３１からの出力データは、出力回路３６、３７及び３８に供給され、このエンジン制御ユニット１６からの出力信号として取り出される。即ち、出力回路３６からはイグナイタ２３に対して点火指令信号ＩＧｔを出力する。また、出力回路３７からはダイアグノーシスの結果を表す信号Ｗを出力して表示ランプ２５を点灯制御し、さらに出力回路３８からの出力信号τｑはエンジン１１の運転状態に対応した燃料噴射量を指示するもので、インジェクタ２２ａ〜２２ｄに供給され、これらインジェクタをそれぞれ制御して各気筒それぞれに噴射される燃料量が制御されるようになっている。
【００２０】
さらに、ＣＰＵ（エンジン制御ユニット）３１内には、後述する異常診断プログラムを格納するメモリ（ＲＯＭ）３９が設けられている。
図３は本発明によるエンジン制御ユニット内のメモリ３９に格納されている異常診断プログラムの構造（アーキテクチャ）を概念的に示した説明図である。本発明による異常診断プログラムは、オブジェクト指向設計されたプログラムで構成される。既に知られるように、オブジェクト指向設計とは、従来のソフトウェアがその目的とする処理（例えば、燃料噴射という処理）に着目したものに対し、そのモノを基本単位にモデル化し、そのモノの特性や振る舞い（作動）で処理を記述するものでる。この基本単位を「オブジェクト」と称し、オブジェクト指向設計されたプログラムでは、このオブジェクトを最小構成単位として記述される。プログラム全体としては、オブジェクト間を要求や応答といったやりとり（「メッセージ」と称する）により結合することで一連の処理が実行される。オブジェクトはデータ（「属性」ともいう）とデータを処理する手続き（「メソッド」ともいう）とを一体化した形で記述され、オブジェクトは他のオブジェクトからの要求（メッセージ）を受信することによりメソッドが実行される。なお、オブジェクトへの仕事の依頼はメソッドを介してのみ行うことができ、オブジェクト内のデータへの直接のアクセスは禁止される。
【００２１】
なお、実際の異常診断プログラムは、エンジン制御ユニット１６の外部に接続される診断ツールとの通信を行うもの等、種々のプログラムを備えているが、ここでは本実施形態を説明するための要部のみ示す。
図３に示すように、本発明の異常診断プログラムは、異常検出オブジェクト１００と、異常確定オブジェクト２００と、異常時処理オブジェクト３００とで構成される。異常検出オブジェクト１００は、エンジン制御ユニット１６に入力された各センサ群の情報に基づいて、正常／異常を判断するプログラムを有し、この異常検出オブジェクト１００は異常検出対象毎にオブジェクト化される。
【００２２】
即ち、図３の例は、水温センサ２０の異常を検出する水温センサ異常検出オブジェクト１１０（以下、水温センサＯｂｊと称する）、吸気温センサ１４の異常を検出する吸気温センサ異常検出オブジェクト１２０（以下、吸気温センサＯｂｊ）、スロットルセンサ１７の異常を検出するスロットルセンサ異常検出オブジェクト１３０（以下、スロットルセンサＯｂｊ）、を図示している。さらに、異常検出対象が増えるとこれに対応した異常検出オブジェクトが追加され、逆に異常検出対象が減った場合には、異常検出オブジェクトがここから削除される。
【００２３】
異常が検出されると、後述するようにフラグ処理要求のメッセージが異常確定オブジェクト２００に発行され、さらに異常確定オブジェクト２００からカウント処理要求のメッセージが異常時処理オブジェクト３００に発行される。
即ち、異常確定オブジェクト２００は、異常検出オブジェクト１００にて立てられたフラグを処理するプログラムを有し、異常検出オブジェクト１００からのサブルーチンコールにより起動される。
【００２４】
なお、異常確定オブジェクト２００にあるプログラムを異常検出オブジェクト１００の各オブジェクトに組み入れ、それぞれで実行することもできるが、図示の異常確定オブジェクト２００のプログラムは各オブジェクト間で共通の処理のため、異常確定オブジェクト２００として独立させている。これにより、本発明ではＲＯＭ容量を削減でき、さらに新たな異常検出対象における異常検出オブジェクトを作成する場合にもこの共通部分のプログラムを作成する必要がなく作業を簡素化することができる。
【００２５】
さらに、異常時処理オブジェクト３００は、複数ある異常検出対象への異常検出結果を総合的に判断し、最終的にランプを点灯すべきか否かを判断するプログラムを有している。
前述したように、異常検出対象の増減により、異常検出オブジェクト１００が追加又は削除されるが、異常確定オブジェクト２００及び異常時処理オブジェクト３００におけるプログラムを変更することはない。
【００２６】
図４は図３に示す水温センサＯｂｊの詳細を示した説明図である。なお、吸気温センサＯｂｊ１２０、スロットルセンサＯｂｊ１３０、等もこれと同じ構成となっている。図示のように、水温センサＯｂｊ１１０は、フラグ格納部１１２と、異常検出プログラム部１１４と、異常情報テーブル１１６とで構成される。
フラグ格納部１１２には、異常か正常かを示す情報、異常時に運転者に警告するランプを点灯するか否かを示す情報等が、フラグ（１ビット）情報として記憶されている。これを具体的に以下に説明する。
【００２７】
・正常判定フラグは、異常検出プログラム部１１４にて正常判断したときにはフラグ「１」が立つ。
・現在異常フラグは、異常検出プログラム部１１４にて異常判断したときにはフラグ「１」が立つ。
・ランプ点灯フラグは、異常確定しフラグ「１」が立つと、ランプ点灯を指示する。
【００２８】
・異常コードフラグは、異常確定しフラグ「１」が立つと、異常であることを記憶する。
また、異常検出プログラム部１１４には、後述の図６に示す異常検出プログラムが格納され、ここでの判断結果に応じてフラグ格納部１１２のフラグが操作される。
【００２９】
さらに、異常情報テーブル１１６には、診断ツールへ出力するコード情報（ＳＡＥコード）や、異常時ランプを点灯させるか否かを示す情報（ランプ点灯）、複数あるランプの内でどのランプを点灯させるかを示す情報（ランプ適用）、異常判断条件を示す情報（低電圧１〜３）等、各異常検出対象に関連した特有の情報が格納されている。図４の水温センサＯｂｊの場合は、診断ツールへは「１１５」を、ランプへは「１１」を出力することを示している。
【００３０】
即ち、本実施形態では、従来のものと異なりフラグ情報や異常情報テーブルが各異常検出対象毎に設けられている。
図５は異常診断プログラムが実行される処理の流れを示すメッセージ・シーケンスチャート（ＭＳＣ）である。この図では各オブジェクトにて実際に実行される処理が示され、矢印により他のオブジェクトへの関数コール（メッセージ）が示されている。即ち、図４に示す異常検出プログラム部１１４にて異常／正常の判定の結果で、フラグ処理要求のメッセージが異常確定オブジェクトに発行され、異常確定オブジェクトにて異常確定処理が行われ、異常時処理オブジェクトにてランプ点灯／消灯判定を行い、ランプ点灯／消灯要求を発行する。
【００３１】
図６は水温センサＯｂｊ１１０での処理フローチャートである。このプログラムは１６ｍｓ毎に実行される。水温センサＯｂｊでは、まず、フラグ情報をレジスタにコピーする（Ｓ６０１）。ここで、「レジスタへのコピー」とは前回の異常検出処理にて確定したフラグ格納部１１２のフラグ情報を、過去のフラグ情報として所望のレジスタ（図示せず）に待避させることである（なお、この待避データは図８のステップＳ８０５で使用する）。
【００３２】
次に、水温センサ２０の検出値を読み込み（Ｓ６０２）、次に、読み込み値が所定範囲内か否かを判定する（Ｓ６０３）。そして、所定範囲内であれば（ＹＥＳ）、正常判定フラグを「１」に現在異常フラグを「０」にする（Ｓ６０４）。一方、読み込み値が所定範囲にないとき（ＮＯ）、正常判定フラグを「０」に、現在異常フラグを「１」にする（Ｓ６０５）。そしてこのようなフラグ処理要求を異常確定オブジェクトに発行する（Ｓ６０６）。
【００３３】
図７は吸気温センサＯｂｊ１２０での処理フローチャートである。図７のフローチャートは、図６の水温センサ値の読み込みが、吸気温センサの読み込みに変わっただけなので説明を省略する。
図８は図３の異常確定Ｏｂｊ２００での処理フローチャートである。図示のステップＳ８０１〜Ｓ８０３では、現在の運転状態と異常検出Ｏｂｊ１００から送られた異常情報テーブル１１６の情報（低電圧１〜３）が「１」か否かを判断し、異常と判断してよい条件か否かを判断する。具体的には、水温センサの異常検出の場合、バッテリ電圧が低下すると水温センサが正常であるにもかかわらず、水温センサの値は所定範囲外となる。従って、水温センサの場合は異常情報テーブル１１６の低電圧３を「１」とすることで（図４参照）、ステップＳ８０３にて肯定判断され（ＹＥＳ）、異常判定フラグがリセットされる。即ち、異常と判断した結果がキャンセルされる。
【００３４】
一方、エンジンの回転信号を検出する回転センサ等はバッテリ電圧に関係しないため、低電圧３は「０」と設定される。これにより、回転センサについてはステップＳ８０３で否定判断され（ＮＯ）、ステップＳ８０５以降で異常か否か判定される。このように、図４の異常情報テーブル１１６の低電圧１〜３の情報を基にして処理することで、異常条件の違いを意識せず、共通の処理ステップ（Ｓ８０１〜Ｓ８０３）で処理することができる。尚、ＩＧ（イグニッションスイッチの状態）、ＳＴＡ（スタータスイッチの状態）、＋Ｂ（バッテリ電圧の状態）に関する情報は、異常時処理Ｏｂｊ３００に格納している。
【００３５】
次に、異常検出条件が全て満足されたならば、ステップＳ８０５にてレジスタに待避した値と現在のフラグ格納部とのフラグ情報を比較してフラグが変化したか否かを判定する。ステップＳ８０６及びＳ８０７にて、フラグが変化した場合のみ現在異常フラグの値を異常コードフラグとランプ点灯フラグとにコピーする。なお、ＸＭＳＧフラグは図１３の処理を起動するためのフラグである。
【００３６】
以上説明したとおり、ステップＳ８０６以降の処理はフラグ状態が変化したときのみ行われ、後述する図１３の処理も同様である。これによりプログラム負荷を軽減することができる。
図９はランプ点灯処理に関わるメッセージ・シーケンスチャート（ＭＳＣ）であり、このシーケンスは６５ｍｓ毎に繰り返し実行される。（Ａ），（Ｂ），（Ｃ），（Ｄ）はそれぞれ１つの異常検出対象の処理であり、（Ａ）の処理が終了すると（Ｂ）に処理が移行する。
【００３７】
詳細は図１０以降で説明するが、まず、ステップＳ９０１でステップＳ９５０にてランプ点灯／消灯を判断するためのカウンタをクリア（リセット）し、ステップＳ９０２でＳ９０３にてカウントすべきか否かランプ点灯フラグの状態から判断する。カウントすべきと判断したならば異常時処理オブジェクト３００へカウント処理要求を発行する。
【００３８】
ステップＳ９０４ではＸＭＳＧフラグを見て異常コードを記憶すべきか否か判断し、記憶すべきと判断したならば異常時処理オブジェクトへ異常コード記憶要求を発行する。ステップＳ９０５ではＸＭＳＧフラグ、ランプ点灯フラグをクリアする。以上で１つの異常検出対象（＝異常検出Ｏｂｊ）の処理が終わり、これと同じ処理を他の異常検出対象に対しても繰り返す（（Ｂ）〜（Ｄ））。そして、全ての異常検出対象の処理が終わると、ステップＳ９５０にてランプ点灯／消灯の判断を行い、ランプ点灯と判断したらランプ点灯要求を出す。
【００３９】
図１０は図９のステップＳ９０１の詳細フローチャートである。図示のように、異常個所数をカウントするカウンタ（ＤＩＡＧＥＲＲ）と、正常復帰個所をカウントするカウンタ（ＤＩＡＧＯＫ）をリセットする（Ｓ１００１）。
図１１は図９のステップＳ９０２の詳細フローチャートである。ランプ点灯フラグ（異常発生しランプ点灯を指示するフラグ）が「１」か否か判断し（Ｓ１１０１）、「１」のときのみ異常時処理オブジェクトに対して異常／正常のカウント処理の実行を要求する（Ｓ１１０２）。
【００４０】
図１２は図９のステップＳ９０３の詳細フローチャートである。まず、点灯するランプを指定する情報（ランプ適用）を見て該当するものか否か判断する（Ｓ１２０１）。ここでは「１」であるが、車両には警告ランプが多数ありその場合はランプ適用２，３等となる。
次に、異常個所数をカウントするカウンタＤＩＡＧＥＲＲをインクリメントし（Ｓ１２０２）、次に現在異常フラグが「０」でかつ正常判定フラグが「１」、即ち、一旦は異常と判断したが、その後正常に復帰したか否かを判断し（Ｓ１２０３）、正常復帰したならば正常復帰個所をカウントするカウンタＤＩＡＧＯＫをインクリメントする（Ｓ１２０４）。
【００４１】
より正確には、ランプ点灯フラグが「１」で正常判定フラグも「１」である数をカウントし、正常復帰後の最初に実行される図１２の処理でのみカウントされる。これは、カウント後、後述する図１４の処理でランプ点灯フラグは「０」となり、図１１で否定判定され図１２の処理自体実行されなくなるためである。
図１３は図９のステップＳ９０４の詳細フローチャートである。まず、フラグ状態が変化したとき「１」となるメッセージフラグＸＭＳＧが、ＸＭＳＧ＝１か否か判断し（Ｓ１３０１）、ＸＭＳＧ＝１なら異常コードの記憶要求を発行する（Ｓ１３０２）。この場合、異常コードの記憶要求は、一旦異常となると毎回、異常コード記憶要求を出すのではなく、フラグ状態が変化したときのみ異常検出オブジェクトでの処理を行うので、異常検出オブジェクトでの処理負荷が増大することはない。
【００４２】
図１４は図９のステップＳ９０５の詳細フローチャートである。図１４では、フラグ状態が変化したとき「１」となるＸＭＳＧフラグを見て「１」なら（Ｓ１４０１）、ＸＭＳＧフラグをリセットし（Ｓ１４０２）、ランプ点灯フラグを現在異常フラグの値とする（Ｓ１４０３）。つまり、図１２で異常から正常に復帰したことを判断するために、正常復帰してもランプ点灯フラグを直ちにリセットせず、カウンタＤＩＡＧＯＫのカウント処理を終了したタイミングでリセットしている。これにより、異常時処理オブジェクトは異常から正常に切り換わった数を正確に把握できる。
【００４３】
このように、１つの異常検出対象に対し、図１０から図１４の処理を実行し、他の異常検出対象もこれと同じ処理を実行して、全ての異常検出対象に対するカウンタＤＩＡＧＥＲＲ及びＤＩＡＧＯＫをカウントしたならば、図９のステップＳ９５０のランプ点灯／消灯判定を行う。
図１５は図９のステップＳ９５０の詳細フローチャートである。カウンタＤＩＡＧＥＲＲ＝０で（Ｓ１５０１でＹＥＳ）、又はカウンタＤＩＡＧＯＫのカウント値がＤＩＡＧＥＲＲのカウント値以上であるなら（Ｓ１５０２でＹＥＳ）、ランプを消灯すべくＸＬＡＭＰ（ランプ点灯／消灯要求フラグ）を「０」にする（Ｓ１５０３）。明らかなように、カウンタＤＩＡＧＥＲＲ＝０でなく（Ｓ１５０１でＮＯ）、さらにカウンタＤＩＡＧＯＫのカウント値がＤＩＡＧＥＲＲのカウント値以上でないなら（Ｓ１５０２でＮＯ）、ランプを点灯すべくＸＬＡＭＰ（ランプ点灯／消灯要求フラグ）を「１」にする（Ｓ１５０４）。
【００４４】
ここで、カウンタＤＩＡＧＯＫとＤＩＡＧＥＲＲの各カウント値の比較によりランプ点灯是非を決めている理由を説明すると、ランプは複数ある異常検出対象のうち１つでも異常が発生していると点灯させなければならない性質を持つ。これは所定の法規で決められているからである。
さらに検討しなければならない事項として、前述したように、異常検出オブジェクト１００は仕様の違い（異常検出対象の数）で増減するが、異常時処理オブジェクト３００は異常検出オブジェクト１００に、どの異常検出対象のものがあるか分からない。このように構成されているのは、もし分かるようにするためには異常時処理オブジェクト３００に異常検出対象を特定するための何らかの情報を持たせる必要があり、このようにすると、異常検出オブジェクト１００の増減に伴い異常時処理オブジェクト３００も修正する必要があり、プログラムの再利用性を悪化させるからである。
【００４５】
従って、本発明では、異常検出オブジェクト１００の異常情報テーブル１１６に、あるランプに関係する異常検出対象のグループを示す情報（ランプ適用）を持たせ、異常時処理オブジェクト３００はこの情報からあるランプに関係する異常検出対象を特定するように構成されている。そして、異常時処理オブジェクト３００は現在異常を示している数（ＤＩＡＧＥＲＲの数）と、異常から正常に復帰した直後の数を比較することで、これに関係する異常検出対象の総数や具体的にどの異常検出対象かを知ることなくランプ点灯処理を実行できる。
【００４６】
なお、単純にランプ点灯フラグの数と正常判定フラグの数を比較することで目的を達成できるかに見えるが、このフラグのセット、リセット動作がされた場合はカウント数が誤り、正常復帰してもランプが消灯しない可能性がある。
これに対して、本発明では、正常復帰しても直ちにランプ点灯フラグをリセットするのではなく、後述する図１７の（Ａ）〜（Ｃ）で示すように、カウント処理が終了したタイミングでリセットしている。これにより、異常から正常に復帰した異常検出対象の数を正確に把握することができる。また、ここでは、ランプ点灯フラグを用いているが、正常復帰してもＤＩＡＧＯＫのカウント処理を完了するまで、異常状態を保持しているデータであれば何でもよい。
図１６は同じランプを適用する３つのセンサが正常、異常を繰り返した場合のＤＩＡＧＥＲＲ、ＤＩＡＧＯＫ、実際のランプ点灯／消灯状態を示す図である。この図は図９で説明したように６５ｍｓのタイミングで８回実行した場合である。図示のように、ダイアグ異常数（ＤＩＡＧＥＲＲ）とダイアグ復帰数（ＤＩＡＧＯＫ）との比較で適切にランプ制御できることが分かる。
【００４７】
図中の（ａ）〜（ｍ）は、前述のランプ点灯／消灯タイミングの説明を補足するために付加した符号である。即ち、（ｆ）ではダイアグ異常数がこのサイクル（６５ｍｓ−５）では（ｂ），（ｅ）の２個のはずであるが、「３」となっている。これは、このタイミングでは（ａ）の「異常」がカウントされているからである（ランプ点灯フラグがまだ「１」のため）。また、（ｇ）のダイアグ復帰数「１」は（ｄ）をカウントした数である。
【００４８】
また、サイクル（６５ｍｓ−８）では、（ｌ）のダイアグ異常数「１」は（ｈ）をカウントしたものであり、（ｍ）のダイアグ復帰数「１」は（ｋ）をカウントしたものである。ダイアグ異常数とダイアグ復帰数が等しい場合は「消灯」となる。
さらに、（ｉ），（ｊ）の「正常」は、（ｍ）に「１」と示すように、カウントされていない。これは、図１１で否定判定され（Ｓ１１０１）、図１２の処理（Ｓ１２０３）が行われないためである。
【００４９】
図１７は図１６のように正常／異常を繰り返した場合の各フラグ、カウンタの動きを示したタイムチャートである。ここでの特徴は、ランプ点灯フラグは正常復帰しても直ぐにリセットされず、カウント処理を待ってリセットされる点にある。即ち、図中の（Ａ），（Ｂ），（Ｃ）に示すように、（Ａ）のタイミングで正常復帰しても、（Ｂ）のタイミングでＤＩＡＧＯＫをカウントするまで、ランプ点灯フラグをリセットしていない（Ｃ）。従って、前述したように、異常から正常になった数を正確にカウントできる。なお、（Ｄ）は、図１２のステップＳ１２０２に示すように、ＤＩＡＧＥＲＲによるランプ点灯フラグの数（異常数）のカウントであり、（Ｅ）は、図１２のステップＳ１２０３及びＳ１２０４に示すように、ＤＩＡＧＯＫによるランプ点灯フラグが「１」で、かつ正常判定フラグが「１」の数のカウントである。
【図面の簡単な説明】
【図１】異常診断を行うエンジン制御システムの一例構成図である。
【図２】図１のエンジン制御ユニットの基本的な構成を説明するブロック図である。
【図３】本発明による異常診断プログラムの構造（アーキテクチャ）を概念的に示した説明図である。
【図４】図３に示す水温センサＯｂｊの詳細を示した説明図である。
【図５】本発明の異常診断プログラムが実行される処理の流れを示すメッセージ・シーケンスチャート（ＭＳＣ）である。
【図６】本発明の水温センサＯｂｊでの処理フローチャートである。
【図７】本発明の吸気温センサＯｂｊでの処理フローチャートである。
【図８】本発明の異常確定Ｏｂｊでの処理フローチャートである。
【図９】本発明のランプ点灯処理のメッセージ・シーケンスチャート（ＭＳＣ）である。
【図１０】図９のステップＳ９０１の詳細フローチャートである。
【図１１】図９のステップＳ９０２の詳細フローチャートである。
【図１２】図９のステップＳ９０３の詳細フローチャートである。
【図１３】図９のステップＳ９０４の詳細フローチャートである。
【図１４】図９のステップＳ９０５の詳細フローチャートである。
【図１５】図９のステップＳ９５０の詳細フローチャートである。
【図１６】同じランプを適用する３つのセンサが正常、異常を繰り返した場合のＤＩＡＧＥＲＲ、ＤＩＡＧＯＫ、実際のランプ点灯／消灯状態を示す図である。
【図１７】図１６の正常／異常を繰り返した場合の各フラグ、カウンタの動きを示したタイムチャートである。
【図１８】従来技術における異常フラグ、ランプ点灯用フラグ、異常コードフラグのメモリエリアの説明図である。
【図１９】異常コード判定用テーブルの説明図である。
【符号の説明】
１１…エンジン
１２…吸気管
１３…エアフローセンサ
１４…吸気温センサ
１５…スロットル弁
１６…エンジン制御ユニット
１７…スロットルセンサ
１８…空燃比センサ
１９…バッテリ
２０…冷却水温センサ
２１…ディストリビュータ
２２ａ，２２ｂ，２２ｄ…インジェクタ
２３…イグナイタ
２４…テストスイッチ
２５…ランプ
２６…イグニッションスイッチ
２７…スタータ
２８…スタータスイッチ
３１…ＣＰＵ
３２…アナログ入力回路
３３…ディジタル入力回路
３４…Ａ／Ｄ変換器
３５…電源回路
３６，３７，３８…出力回路
３９…メモリ

Claims (9)

1. 自己診断装置を備えた車両用制御装置において、前記自己診断装置は前記車両に対する異常診断を行う異常診断手段を有し、前記異常診断手段は、
   異常検出対象毎に分割され、分割された各々は、異常検出するための異常検出プログラム（１１４）と、前記異常検出プログラムでの異常検出時に検出対象に対する処理を行うためのデータを格納する第１のデータ格納部（１１２）と、異常検出対象毎に少なくとも異常判断条件を示す情報を含む異常発生時処理情報を格納する第２のデータ格納部（１１６）とを有する複数の異常検出オブジェクト（１１０，１２０，１３０）と、
   前記複数の異常検出オブジェクトの前記第１のデータ格納部の情報を基に、前記第２のデータ格納部の前記異常発生時処理情報に基づく処理を行う１つの異常時処理オブジェクト（３００）と、
   を備えたことを特徴とする自己診断装置を備えた車両用制御装置。
2. 自己診断装置を備えた車両用制御装置において、前記自己診断装置は前記車両に対する異常診断を行う異常診断手段を有し、前記異常診断手段は、
   異常検出対象毎に分割され、分割された各々は、異常検出するための異常検出プログラム（１１４）と、前記異常検出プログラムでの異常検出時に検出対象に対する処理を行うためのデータを格納する第１のデータ格納部（１１２）と、異常検出時の車両の環境状態に応じて異常検出結果を有効とすべきか否かを示す異常検出対象固有のデータを格納する第２のデータ格納部（１１６）と、を有する複数の異常検出オブジェクト（１１０，１２０，１３０）と、
   前記第２のデータ格納部の情報に基づき、前記異常検出オブジェクトでの異常検出結果が有効か否かを判断する１つの異常確定オブジェクト（２００）と、
   前記複数の異常検出オブジェクトの前記第１のデータ格納部の情報を基に、検出対象に対する異常発生時処理を行う１つの異常時処理オブジェクト（３００）と、を備え、
   ここに、前記第１のデータ格納部（１１２）は異常検出対象毎のフラグを格納するフラグ格納部であり、前記第２のデータ格納部（１１６）は異常検出対象毎の情報を格納する異常情報テーブルであることを特徴とする自己診断装置を備えた車両用制御装置。
3. 自己診断装置を備えた車両用制御装置において、前記自己診断装置は前記車両に対する異常診断を行う異常診断手段を有し、前記異常診断手段は、
   異常検出対象毎に分割され、分割された各々は、異常検出するための異常検出プログラム（１１４）と、前記異常検出プログラムでの異常検出時にランプ点灯等の処理を行うためのフラグを格納するフラグ格納部（１１２）とを有する複数の異常検出オブジェクト（１１０，１２０，１３０）と、
   前記複数の異常検出オブジェクトの前記フラグ格納部の情報を基に、ランプ点灯等の異常発生時処理を行う１つの異常時処理オブジェクト（３００）と、を備え、
   さらに、前記異常検出オブジェクト（１１０，１２０，１３０）は、異常検出時にランプ点灯を指示するランプ点灯フラグをセットし、正常判断時に正常判定フラグをセットする手段を有し、
   前記異常時処理オブジェクト（３００）は、複数の異常検出オブジェクト（１１０，１２０，１３０）に対するランプ点灯フラグ及び正常判定フラグを調査しランプ点灯フラグがセットされている数をカウントする第１のカウント手段（Ｓ１２０２）と、ランプ点灯フラグと正常判定フラグが共にセットされている数をカウントする第２のカウント手段（Ｓ１２０４）と、前記第１のカウント手段でのカウント数と前記第２のカウント手段からのカウント数との比較結果でランプ点灯するか否かを判断する判断手段と、
   を備えたことを特徴とする自己診断装置を備えた車両用制御装置。
4. 自己診断装置を備えた車両用制御装置において、前記自己診断装置は前記車両に対する異常診断を行う異常診断手段を有し、前記異常診断手段は、
   異常検出対象毎に分割され、分割された各々は、異常検出するための異常検出プログラム（１１４）と、前記異常検出プログラムでの異常検出時にランプ点灯等の処理を行うためのフラグを格納するフラグ格納部（１１２）とを有する複数の異常検出オブジェクト（１１０，１２０，１３０）と、
   前記複数の異常検出オブジェクトの前記フラグ格納部の情報を基に、ランプ点灯等の異常発生時処理を行う１つの異常時処理オブジェクト（３００）と、を備え、
   前記異常検出オブジェクト（１１０，１２０，１３０）は、異常検出時に異常発生を示す異常発生データを前記フラグ格納部（１１２）にセットし、正常判断時に正常判断した結果を示す正常判定データを前記フラグ格納部（１１２）にセットする手段を有し、
   前記異常時処理オブジェクト（３００）は、複数の異常検出オブジェクト（１１０，１２０，１３０）に対する異常発生データ及び正常判定データを調査し異常発生データがセットされている個数をカウントする第１のカウント手段（Ｓ１２０２）と、異常発生データと正常判定データとが共にセットされている数をカウントする第２のカウント手段（Ｓ１２０４）と、前記第１のカウント手段でのカウント数と前記第２のカウント手段からのカウント数との比較結果でランプ点灯するか否かを判断する判断手段と、
   を備えたことを特徴とする自己診断装置を備えた車両用制御装置。
5. 正常復帰時の前記ランプ点灯フラグのリセットを、前記異常時処理オブジェクトにてランプ点灯するか否かの判断後、又は前記第１及び第２のカウント手段でのカウント処理実行後まで遅延させる手段をさらに備えることを特徴とする請求項３に記載の自己診断装置を備えた車両用制御装置。
6. 正常復帰時の前記異常発生データのリセットを、前記異常時処理オブジェクトにてランプ点灯するか否かの判断後、又は前記第１及び第２のカウント手段でのカウント処理実行後まで遅延させる手段をさらに備えることを特徴とする請求項４に記載の自己診断装置を備えた車両用制御装置。
7. 前記第１及び第２のカウント手段でのカウント処理は、点灯すべきランプ毎に行われ、前記異常検出オブジェクト（１１０，１２０，１３０）は、いずれのランプ点灯に関わるものかを示す情報を有することを特徴とする請求項３又は４に記載の自己診断装置を備えた車両用制御装置。
8. 前記異常診断手段は、オブジェクト指向設計されたプログラムで記述されることを特徴とする請求項１〜４のいずれか一項に記載の自己診断装置を備えた車両用制御装置。
9. 前記第１のデータ格納部（１１２）は異常検出対象毎のフラグを格納するフラグ格納部であり、前記第２のデータ格納部（１１６）は異常検出対象毎の情報を格納する異常情報テーブルであることを特徴とする請求項１に記載の自己診断装置を備えた車両用制御装置。

Images