JP3692932B2 - 情報提供機能を備えた車両用制御装置及び記録媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、車両を制御する車両用制御装置の情報提供機能に関し、特に、当該情報提供機能をオブジェクト指向プログラミングにて実現する技術に関する。
【０００２】
【従来の技術】
近年、高性能マイクロプロセッサの出現などエレクトロニクス技術の進歩を背景として、機械技術と電子技術とが結びついたメカトロニクス技術の進歩が著しい。メカトロニクスの進歩の一部として、自動車等の車両にも多くのコンピュータシステムが採用されてきている。このような車載用のコンピュータシステムは、省資源、省エネルギー、走行性能、安全性、快適性等を追求するものであり、車両内のエンジン・駆動系、走行・安全系、エンターテイメント系、及びその他の随所に搭載されている。
【０００３】
特に高い信頼性を要求される車両制御用のコンピュータシステム（以下「車両用制御装置」という。）は、自己診断機能を備えることにより、信頼性の向上が図られている。すなわち、コンピュータ部やセンサ類の動作状態を適当な周期で自動的にチェックし、故障時には、その故障内容が修理担当者などに分かるよう故障情報である故障コード（ＤＴＣ）などを記憶する。
【０００４】
一方、このような故障情報をはじめとする車両情報は、車両に接続されるスキャンツールによって読み出され、外部の作業者に提供される。これによって、適切なメンテナンスが可能となる。
したがって、車両用制御装置は、このようなスキャンツールとの間で通信を行い、要求された車両情報を提供する情報提供機能を備えている。
【０００５】
ここでスキャンツールによる車両情報取得の概要について説明する。
上述した車両情報には、故障情報の他にも、例えばエミッションに関連する情報、アクチュエータに関連する情報など、様々なものが存在する。したがって、車両情報は所定のカテゴリに分けられている。このようなカテゴリは、法規によってＭｏｄｅ＄０１〜Ｍｏｄｅ＄０９として設定されている。例えば故障情報の中には故障時の車両状態などを含むフリーズ情報が通常含まれるが、このフリーズ情報は「Ｍｏｄｅ＄０２」として分類されている。また、このフリーズ情報を例に挙げれば、車両メーカの仕様によってもフリーズ情報は変わるため、近年では、メーカ毎にこのようなカテゴリが設定されるようになってきた。
【０００６】
そのため、上述したスキャンツールからはこのカテゴリとそのカテゴリに含まれる情報を指定して、目的とする情報を読み出すことになる。
すなわち、情報提供機能を実現するためのサービスプログラムは、スキャンツールとの間で通信を行い、スキャンツールで指定されたカテゴリを判断して車両情報を取得するものとなっている。
【０００７】
【発明が解決しようとする課題】
しかしながら、コンピュータシステムが車両の至る所に搭載されていくという状況下では、モデルチェンジにより、スキャンツールによって取得すべき車両情報が益々増え続けている。そのため、モデルチェンジのタイミングで、上述した車両情報に追加／変更が生じてくる。また、車両メーカの違いによっても、あるいは、車種・グレードの違いによっても、上述した車両情報が異なってくる。このような車両情報の変更は、上述したカテゴリの変更につながってくる。
【０００８】
このため、サービスプログラムは、カテゴリ単位の変更を含む車両情報の変更に対し容易に対応でき、しかも、変更を要しない部分については再利用できる構成とすることが望まれる。
また、スキャンツールとの間の通信方法が変更される場合もあり、このような通信方法の変更に対しても容易に対応でき、しかも、変更を要しない部分については再利用できる構成とすることが望まれる。
【０００９】
そこで本発明は、車両用制御装置に搭載されるサービスプログラムを、スキャンツールといった外部装置との間の通信方法が変更されても容易に対応できる構造にすることを第１の目的とし、加えて、要求される車両情報が変更されても容易に対応できる構造にすることを第２の目的とし、再利用性の向上に寄与する。
【００１０】
【課題を解決するための手段及び発明の効果】
上述した第１及び第２の目的を達成するためになされた請求項１に記載の車両用制御装置の情報提供機能を実現するサービスプログラム及び自己診断機能を実現する自己診断プログラムは、オブジェクト指向設計され、再利用が可能なオブジェクトの単位で構成されている。情報提供機能とは、上述したように、スキャンツールといった外部装置からの要求があると、車両に関連する車両情報を読み出して出力する機能をいう。また、自己診断機能とは、ダイアグ対象の故障検出結果に基づいて、ダイアグ対象の故障に関する情報である故障情報を記憶する機能をいう。
【００１１】
本発明では特に、上記情報提供機能が、複数のサービス実行オブジェクトと、サービス管理オブジェクトとで実現される。
サービス実行オブジェクトは、車両情報の所定のまとまりである車両情報群毎に用意され、起動指示に基づいて、対応する車両情報群中の車両情報を取得する。また、各サービス実行オブジェクトは、起動指示に基づいて、該当する自己診断プログラムを構成するオブジェクトに対し、故障情報を要求することにより、上記車両情報として、故障情報を取得可能な構成にされている。
一方、サービス管理オブジェクトは、外部装置との間でデータ通信を行い、外部装置からの情報要求があると、該当するサービス実行オブジェクトを判断し、当該サービス実行オブジェクトに対し起動指示を行うと共に、当該サービス実行オブジェクトにて取得された車両情報を外部装置へ出力する。
その他、自己診断プログラムを構成するオブジェクトは、サービス実行オブジェクトから要求された故障情報を、要求元のサービス実行オブジェクトに対して出力する。
【００１２】
すなわち、本発明では、車両情報（故障情報）の取得機能と外部装置との通信機能とを別個のオブジェクトにて実現するようにした。これによって、外部装置との通信方法のみが変更された場合には、サービス管理オブジェクトのみを変更することで容易に対応できる。そしてこのとき、サービス実行オブジェクトについてはそのまま再利用することができ、サービスプログラムの再利用性を向上させることができる。
【００１３】
また、本発明では、車両情報群毎にサービス実行オブジェクトを設けたため、要求される車両情報が変更されても、その車両情報を含む車両情報群の単位での変更作業が可能になる。これによって、車両情報の変更に容易に対応できる。そして、変更の必要がない車両情報群に対応するサービス実行オブジェクトはそのまま再利用でき、サービスプログラムの再利用性を向上させることができる。
また、サービス実行オブジェクトは、車両情報として故障情報を取得する際、故障情報を要求する程度であるので、本発明によれば、故障情報がどこに記憶されているかということについて意識する必要がなく、サービス実行オブジェクト単位での変更が極めて簡単になる。
【００１５】
なお、本明細書ではオブジェクトを主体とした表現を適宜用いるが、車両用制御装置の有するＣＰＵがオブジェクトの有するプログラムを実行することによって、該当する機能が実現されることは言うまでもない。
【００１６】
また、車両情報群は、車両情報の変更パターンを考慮し、同時に変更される車両情報のまとまりとすることが好ましい（請求項２）。一例として、法規又は車両メーカの要求の少なくとも一方に基づき定められる車両情報のまとまりとすることが考えられる（請求項３）。つまりこの場合、車両情報群は、上述したカテゴリ毎のまとまりとなる。このように、同時に変更される可能性の高い車両情報を車両情報群とすれば、これに対応するサービス実行オブジェクトだけの変更作業で対応できる可能性が高くなり、結果的に、再利用できるサービス実行オブジェクトが増えて、サービスプログラムの再利用性のさらなる向上に寄与する。
【００１７】
ところで、外部装置からはカテゴリを指定して情報要求を行うのが一般的であることは既に述べた。したがって、上述のように複数のサービス実行オブジェクトがこれらのカテゴリに対応させて用意される構成においては、外部装置からの情報要求に少なくとも車両情報群を特定するための特定データが含まれることを前提として、サービス管理オブジェクトは、この特定データに基づき、該当するサービス実行オブジェクトを判断することが考えられる（請求項４）。この場合は、サービス管理オブジェクトによる、該当するサービス実行オブジェクトの判断処理が簡単になる。
【００１８】
また、外部装置では通常、カテゴリと共に読出対象の情報を指定する。したがって、外部装置からの情報要求に、さらに、車両情報群中の車両情報を指定するための指定データが含まれることを前提として、サービス管理オブジェクトは起動指示と共にこの指定データを出力し、サービス実行オブジェクトは、サービス管理オブジェクトから出力される指定データに基づき、車両情報群中の車両情報を取得することが考えられる（請求項５）。この場合、サービス実行オブジェクトによる車両情報の取得処理が簡単になる。
【００２０】
また、自己診断プログラムが、故障検出結果に基づき、故障項目に対応するダイアグ故障情報を管理する故障情報管理オブジェクトを少なくとも備えている場合、サービス実行オブジェクトは、必要に応じて、故障情報管理オブジェクトに対してダイアグ故障情報を要求することにより、ダイアグ故障情報を故障情報として取得することが考えられる（請求項６）。
【００２１】
また、自己診断プログラムが、さらに、ダイアグ故障情報の付帯情報であって、故障時の車両状態を含むフリーズ情報を管理するＦＦＤ管理オブジェクトを備えている場合、サービス実行オブジェクトは、必要に応じて、ＦＦＤ管理オブジェクトに対してフリーズ情報を要求することにより、フリーズ情報を故障情報として取得することが考えられる（請求項７）。
【００２２】
この他、自己診断プログラムが、さらに、ダイアグ対象の故障を検出する故障検出オブジェクトを備えている場合には、サービス実行オブジェクトは、必要に応じて、故障検出オブジェクトに対して故障検出に係る検出情報を要求することにより、故障検出情報を故障情報として取得することが考えられる（請求項８）。
【００２３】
なお、請求項６〜８の記載中、必要に応じてとしたのは、外部装置から指定された場合にだけ取得することが考えられるためである。
以上のように、サービス実行オブジェクトからの要求に応じて、該当するオブジェクトが動作することによって故障情報が取得されるようにすれば、サービス実行オブジェクト単位での変更が簡単になるという点で有利である。つまり、サービス実行オブジェクトは、故障情報を要求するだけであり、故障情報がどこに記憶されているかということについて何等意識する必要がないのである。
【００２４】
なお、上述した車両用制御装置の備えるサービスプログラムや自己診断プログラムは、コンピュータシステム側で起動するプログラムとして備えることができる。このようなプログラムの場合、例えば、ＦＤ、ＭＯ、ＤＶＤ、ＣＤ−ＲＯＭ、ハードディスク等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータシステムにロードして起動することにより用いることができる。この他、ＲＯＭやバックアップＲＡＭをコンピュータ読み取り可能な記録媒体としてプログラムを記録しておき、このＲＯＭあるいはバックアップＲＡＭをコンピュータシステムに組み込んで用いてもよい。
【００２５】
【発明の実施の形態】
以下、本発明を具体化した一実施例を図面を参照して説明する。
図１は、エンジン制御システムの全体を示す構成図である。このエンジン制御システムは、エンジン１１及び、このエンジン１１を制御するエンジン制御ユニット１６を中心に構成されている。このエンジン制御ユニット１６が「車両用制御装置」に相当する。
【００２６】
エンジン１１には、エアクリーナからの吸入空気が吸気管１２を経て供給されている。この吸気管１２には、吸入空気量を測定するエアフローセンサ１３と、吸気温度を検出する吸気温センサ１４が配置され、さらに、アクセルペダルによって駆動されるスロットル弁１５が配置されている。
【００２７】
エンジン制御ユニット１６には、エンジン１１の状態を示す各種信号が入力される。この信号を列挙すれば、エアフローセンサ１３からの吸入空気量検出信号、スロットルセンサ１７からのスロットル弁１５の開度検出信号、排出ガス中に含まれる酸素濃度を検出する空燃比センサ１８からの信号、バッテリ１９からのバッテリ電圧信号、水温センサ２０からの検出信号、エンジン１１によって駆動されるディストリビュータ２１からの回転信号、さらに気筒判別信号等である。
【００２８】
エンジン制御ユニット１６は、これらの各種検出信号に基づいてエンジン１１の運転状態に対応した燃料噴射量等を演算し、エンジン１１の複数の気筒それぞれに設定されるインジェクタ２２ａ，２２ｂ，２２ｃ，２２ｄに対して燃料噴射指令を出力し、また、イグナイタ２３に対して点火指令信号を出力して、エンジン１１の運転制御を実行する。
【００２９】
さらに、エンジン制御ユニット１６は、車両の各部位の診断も各センサ群からの検出信号に基づいて実行する。このため、エンジン制御ユニット１６に対しては、異常検出結果の出力のための診断モードを設定するテストスイッチ２４が配置され、さらに、そのテスト結果であるダイアグノーシスの結果表示等を行う警告灯２５が接続されている。そして、エンジン制御ユニット１６による車両の各部位の診断に基づく情報を外部から読み出せるように、破線で示すようにエンジン制御ユニット１６に対してスキャンツール５０が接続可能になっている。
【００３０】
スイッチ２６はバッテリ１９をエンジン制御ユニット１６に対して接続するイグニッションスイッチであり、このイグニッションスイッチ２６に連動するようにしてスタータモータ２７を制御するスタータスイッチ２８が設けられている。次に、エンジン制御ユニット１６について説明する。図２は、図１に示したエンジン制御ユニット１６の構成を示すブロック図である。エンジン制御ユニット１６は、コンピュータシステムを構成するＣＰＵ３１を備える。このＣＰＵ３１にはアナログ入力回路３２及びディジタル入力回路３３からのデータが入力され、アナログ入力回路３２からのアナログ入力データは、Ａ／Ｄ変換器３４でディジタルデータに変換されてＣＰＵ３１に入力される。
【００３１】
アナログ入力回路３２には、エアフローセンサ１３からの検出信号Ｕｓ、水温センサ２０からの検出信号Ｔｈｗ、吸気温センサ１４からの検出信号Ｔｈａ、及びバッテリ１９の電圧＋Ｂが入力される。一方、ディジタル入力回路３３には、ディストリビュータ２１からの気筒判別信号Ｇ１と回転角信号Ｎｅ、空燃比センサ１８からの酸素濃度に対応したリーン・リッチ信号Ｏｘ、スロットルセンサ１７からのスロットル弁１５の開度を示す信号ＳＴＯ、スタータスイッチ２８からのスタート信号ＳＴＡ、及びテストスイッチ２４からの診断モードを設定する信号Ｔが入力される。
【００３２】
Ａ／Ｄ変換器３４は、アナログ入力回路３２に入力される各種の検出信号をＣＰＵ３１からの指令に従い順次選択して読み取り、ディジタルデータに変換するマルチプレクサ機能を有する。
また、電源回路３５は、イグニッションスイッチ２６を経てバッテリ１９の電圧＋ＢをＣＰＵ３１に供給し、また、常時バックアップ用電源Ｂａｔｔを供給している。
【００３３】
ＣＰＵ３１からの出力データは、出力回路３６、３７及び３８に供給され、エンジン制御ユニット１６からの出力信号として取り出される。すなわち、出力回路３６からはイグナイタ２３に対して点火指令信号ＩＧｔを出力する。また、出力回路３７からは診断結果を表す信号Ｗを出力して警告灯２５を点灯制御する。出力回路３８からの出力信号τｑは、エンジン１１の運転状態に対応した燃料噴射量を指示するもので、インジェクタ２２ａ〜２２ｄに出力されて、これらインジェクタ２２ａ〜２２ｄの噴射量を変える。
【００３４】
さらに、ＣＰＵ３１には入出力回路４０が接続されており、外部との通信機能を備えている。これによって、スキャンツール５０が接続された場合には、スキャンツール５０との間でデータ通信を行い、スキャンツール５０から要求される情報を出力する。また、特に図示しないが、入出力回路４０を介し、エンジン制御ユニット外部の様々な車両情報を、車両内ネットワークにて取得することもできる。
【００３５】
ＣＰＵ３１内には、後述する自己診断プログラムやサービスプログラムを格納するメモリ３９が設けられている。このメモリ３９は、ＲＯＭ及び、イグニッションスイッチ２６がオフされているときにも電源供給されてデータを保持するスタンバイＲＡＭ又は不揮発性のＥＥＰＲＯＭとで構成されている。自己診断プログラム及びサービスプログラムは、ＲＯＭ内に格納されている。そして後述するように、スタンバイＲＡＭ又はＥＥＰＲＯＭには、自己診断プログラムによって「ダイアグ故障情報」としてのダイアグ故障情報及び故障時における車両状態を含む「フリーズ情報」としてのフリーズ・フレーム・データ（以下「ＦＦＤ」という。）が記憶される。
【００３６】
本実施例は、メモリ３９のＲＯＭ内に格納されたプログラムの構造に特徴を有するものである。そこで次に、このプログラム構造について説明する。
図３は、メモリ３９のＲＯＭ内に格納されたプログラムの構造（アーキテクチャ）を概念的に示した説明図である。ここに示したプログラムは、いわゆるオブジェクト指向設計されたものであり、オブジェクトを最小構成単位として記述される。プログラム全体としては、オブジェクトからオブジェクトへの通知（メッセージ）によりオブジェクト間を結合することで一連の処理が実行される。オブジェクトは、データ（属性）とデータに対するメソッド（手続き）とを備え、他のオブジェクトからのメッセージによってメソッドを実行する。なお、本実施例においても、これまでと同様、「オブジェクトが・・・する。」というオブジェクトを主体とした表現を用いるが、実際には、ＣＰＵ３１が処理プログラムを実行することで実現されることは言うまでもない。また、図面では各オブジェクトを「ｏｂｊ」と示す。
【００３７】
図３に示すように、本実施例におけるプログラムは少なくとも、故障検出オブジェクト１００と、故障情報管理オブジェクト２００と、ＦＦＤ管理オブジェクト３００と、サービス管理オブジェクト４００と、サービス実行オブジェクト５００とを備えている。これらのオブジェクト１００〜５００は、プラットフォーム（以下「ＰＦ」という。）６００上のプログラムであり、ＰＦ６００との間で適宜情報交換を行いながら動作する。
【００３８】
図３中に一点鎖線で示したように、オブジェクト１００〜３００が自己診断プログラムの構成要素であり、オブジェクト４００，５００がサービスプログラムの構成要素となっている。
故障検出オブジェクト１００は、ダイアグ対象の故障検出処理毎に用意されており、ＰＦ６００から診断が指示されると、エンジン制御ユニット１６に入力された各センサ群などの情報に基づき、自己診断の対象となるダイアグ対象の故障を検出する。
【００３９】
故障情報管理オブジェクト２００は、故障検出オブジェクト１００からの正常／異常通知があると、故障のレベルを判定し、ダイアグ故障情報を保存する。
ＦＦＤ管理オブジェクト３００は、故障情報管理オブジェクト２００からのＦＦＤ保存依頼の通知があると、車両状態をＰＦ６００から取得し、ＦＦＤを保存する。
【００４０】
サービス管理オブジェクト４００は、スキャンツール５０が接続されてデータ通信可能状態が確立されると、スキャンツール５０との間で通信処理を行う。このスキャンツール５０が入出力回路４０を介して接続されることは、既に述べた（図２参照）。そして、スキャンツール５０からの情報要求があると、該当するサービス実行オブジェクト５００を判断して起動指示を行う。これに対して、サービス実行オブジェクト５００から出力される故障情報をスキャンツール５０へ出力して応答する。
【００４１】
サービス実行オブジェクト５００は、所定の故障項目のまとまり毎に用意されている。このまとまりが「車両情報群」に相当する。そして、サービス管理オブジェクト４００からの起動指示があると、故障検出オブジェクト１００、故障情報管理オブジェクト２００、ＦＦＤ管理オブジェクト３００の中の該当するオブジェクト１００〜３００に対し、故障情報を要求する。したがって、これらの各オブジェクト１００〜３００は、要求された故障情報を収集して出力する。
【００４２】
以上各オブジェクト１００〜５００それぞれの動作概要を述べたが、自己診断プログラムを構成するオブジェクト１００〜３００は、ＰＦ６００からの診断指示に基づき、ダイアグ故障情報及びＦＦＤを保存する一方、サービス実行オブジェクト５００からの故障情報の要求に対し、要求された故障情報を出力する。
【００４３】
したがってまず、故障情報の保存に係るメッセージシーケンスチャート（以下「ＭＳＣ」という。）を参照し、オブジェクト１００〜３００の結合をさらに詳しく説明する。
図４は、故障情報の保存手順を示すＭＳＣである。
【００４４】
まずＰＦ６００が故障検出オブジェクト１００に診断の開始を通知する。この診断開始の通知は、個々の故障検出オブジェクト１００に対し、それぞれのタイミングで行われる。ＰＦ６００からの診断開始の指示を受けた故障検出オブジェクト１００は、故障検出処理Ｓ１を実行する。この故障検出処理Ｓ１にて、故障検出に係る「検出情報」として各センサの値などである検出情報が取得され、故障情報管理オブジェクト２００へ正常又は異常が通知される。
【００４５】
正常又は異常が通知されると、故障情報管理オブジェクト２００は、故障レベル判定処理Ｓ２を実行し、ダイアグ故障情報を保存する。ダイアグ故障情報は、故障情報管理オブジェクト２００自体が記憶してもよいが、自己診断プログラムの再利用性を考えると、別途用意される故障情報保存オブジェクト（不図示）に記憶させるのが好ましい。ここではダイアグ故障情報として、一時的な故障を示す「仮異常」、永続的な故障を示す「確定異常」、故障していない状態を示す「正常」のいずれかが記憶される。
【００４６】
また、故障情報管理オブジェクト２００の故障レベル判定処理Ｓ２で、ＦＦＤの保存タイミングであると判断された場合、ＦＦＤ管理オブジェクト３００に対するＦＦＤ保存依頼を通知する。ＦＦＤの保存タイミングであるか否かは、故障検出オブジェクト１００毎に、詳しくは故障検出内容毎に異なっており、異常が確定的になった時点でＦＦＤを保存する場合もあれば、異常と判断された時点でＦＦＤを保存する場合もある。
【００４７】
ＦＦＤの保存依頼通知があると、ＦＦＤ管理オブジェクト３００は、ＦＦＤ保存処理Ｓ３を実行する。このＦＦＤ保存処理Ｓ３では、車両状態をＰＦ６００から取得しＦＦＤを保存する。このＦＦＤも、上述したダイアグ故障情報と同様、ＦＦＤ管理オブジェクト３００自体が記憶してもよいが、再利用性を考えた場合、別途用意されるＦＦＤ保存オブジェクト（不図示）に記憶させるのが好ましい。ＦＦＤが保存されると、ＦＦＤ管理オブジェクト３００は、故障情報管理オブジェクト２００に対し、ＦＦＤ保存依頼に対する依頼完了の通知を行う。
【００４８】
そして、故障検出オブジェクト１００に対する通知完了が故障情報管理オブジェクト２００によって出力され、故障検出オブジェクト１００がＰＦ６００に対して診断終了を通知することによって、診断処理が終了する。
続いて、スキャンツール５０による故障情報の読み出しに係るＭＳＣを参照し、オブジェクト１００〜５００の結合を説明する。
【００４９】
図５は、故障情報の読み出し手順を示すＭＳＣである。
スキャンツール５０を介して作業者は、故障情報のカテゴリ及び、読出対象である当該カテゴリ内の故障情報を指定する。このカテゴリは、法規によって定められたＭｏｄｅと呼ばれる部類であったり、車両メーカの要求によって定められたメーカ独自の部類であったりする。サービス実行オブジェクト５００が故障情報の所定のまとまり毎に用意されていることは既に述べたが、詳しくは、スキャンツール５０を介して指定されるこのカテゴリの単位で用意されている。
【００５０】
そして上述したようにスキャンツール５０からサービス管理オブジェクト４００へ情報要求がなされるのであるが、この情報要求には、上述したカテゴリを特定するための特定データ及び、カテゴリ内の故障情報を指定するための指定データ（パラメータ）が含まれている。
【００５１】
スキャンツール５０からの情報要求に対し、サービス管理オブジェクト４００は、起動処理Ｓ４を実行する。この起動処理Ｓ４にて、上述した特定データにより、対応するサービス実行オブジェクト５００が判断され、当該サービス実行オブジェクト５００に対し起動指示がなされる。このとき、起動指示と共に、上述した指定データが出力される。
【００５２】
起動指示がなされると、サービス実行オブジェクト５００は、故障情報取得処理Ｓ５を実行する。故障情報取得処理Ｓ５では、起動指示と共に出力される指定データに基づいて、少なくともオブジェクト１００〜３００のいずれかへ、故障情報を要求する。
【００５３】
サービス実行オブジェクト５００から故障情報が要求されると、故障検出オブジェクト１００は、検出情報出力処理Ｓ６を実行し、検出情報を出力する。また、同様に、故障情報管理オブジェクト２００はダイアグ故障情報出力処理Ｓ７を実行してダイアグ故障情報を出力し、ＦＦＤ管理オブジェクト３００はＦＦＤ出力処理Ｓ８を実行してＦＦＤを出力する。
【００５４】
サービス実行オブジェクト５００は、故障情報を要求した全てのオブジェクト１００〜３００からの情報出力があると、取得した故障情報をサービス管理オブジェクト４００へ出力する。
これによってサービス管理オブジェクト４００は、スキャンツール５０への応答を行う。
【００５５】
本実施例は、メモリ３９のＲＯＭ内に格納されたプログラムの構造に特徴を有するものであることは上述したが、詳しくは、サービスプログラムの構造に特徴を有するものである。
したがって次に、図５中に示した、起動処理Ｓ４、ダイアグ故障情報取得処理Ｓ５、検出情報出力処理Ｓ６、ダイアグ故障情報出力処理Ｓ７及びＦＦＤ出力処理Ｓ８を具体的に説明し、各オブジェクト１００〜５００の動作に対する理解を深める。
【００５６】
最初に起動処理Ｓ４を説明する。図６は、サービス管理オブジェクト４００にて実行される起動処理Ｓ４を示すフローチャートである。
まず最初のステップ（以下、ステップを単に記号Ｓで示す。）４０００において、上述した特定データに基づき、該当するサービス実行オブジェクト５００を判断する。例えば特定データが「Ｍｏｄｅ＄０２」を指定するものであれば、ＦＦＤを取得するためのサービス実行オブジェクト５００が、該当するオブジェクト５００として、判断されるという具合である。
【００５７】
続くＳ４０１０では、Ｓ４０００にて判断したサービス実行オブジェクト５００への起動指示を行う。このとき、上述した指定データを出力する。このＳ４０１０における起動指示により、サービス実行オブジェクト５００は、故障情報を出力してくる。
【００５８】
したがって、起動指示を行ったサービス実行オブジェクト５００からの故障情報出力を待って、Ｓ４０２０では、故障情報の応答データへの変換を行う。この処理は、スキャンツール５０との間の通信プロトコルに合わせて故障情報を変換するものである。
【００５９】
そして次のＳ４０３０では、変換した応答データを出力し、スキャンツール５０への応答を行う。その後、本起動処理Ｓ４を終了する。
続けて、ダイアグ故障情報取得処理Ｓ５を説明する。図７は、サービス実行オブジェクト５００にて実行されるダイアグ故障情報取得処理Ｓ５を示すフローチャートである。
【００６０】
まず最初のＳ５０００において、検出情報の指定があるか否かを判断する。この判断は、上述した指定データに基づいて行われる。ここで検出情報の指定があると判断された場合（Ｓ５０００：ＹＥＳ）、Ｓ５０１０にて、故障検出オブジェクト１００に対して、指定された検出情報を要求する。これによって、検出情報が取得されると、その後、Ｓ５０２０へ移行する。一方、検出情報の指定がないと判断された場合（Ｓ５０００：ＮＯ）、Ｓ５０１０の処理を実行せず、Ｓ５０２０へ移行する。
【００６１】
Ｓ５０２０では、ダイアグ故障情報の指定があるか否かを判断する。この判断も、上述した指定データに基づくものである。ここでダイアグ故障情報の指定があると判断された場合（Ｓ５０２０：ＹＥＳ）、Ｓ５０３０にて、故障情報管理オブジェクト２００に対して、指定されたダイアグ故障情報を要求する。これによって、ダイアグ故障情報が取得されると、その後、Ｓ５０４０へ移行する。一方、ダイアグ故障情報の指定がないと判断された場合（Ｓ５０２０：ＮＯ）、Ｓ５０３０の処理を実行せず、Ｓ５０４０へ移行する。
【００６２】
Ｓ５０４０では、ＦＦＤの指定があるか否かを判断する。この判断も、上述した指定データに基づくものである。ここでＦＦＤの指定があると判断された場合（Ｓ５０４０：ＹＥＳ）、Ｓ５０５０にて、ＦＦＤ管理オブジェクト３００に対して、指定されたＦＦＤを要求する。これによって、ＦＦＤが取得されると、その後、本故障情報取得処理Ｓ５を終了する。一方、ＦＦＤの指定がないと判断された場合（Ｓ５０４０：ＮＯ）、Ｓ５０５０の処理を実行せず、本故障情報取得処理Ｓ５を終了する。
【００６３】
なお、図７中の故障検出オブジェクト１００からの検出情報取得に係る処理（記号Ａで示すＳ５０００及びＳ５０１０の処理、以下「処理Ａ」という。）、故障情報管理オブジェクト２００からのダイアグ故障情報取得に係る処理（記号Ｂで示すＳ５０２０及びＳ５０３０の処理、以下「処理Ｂ」という。）、及び、ＦＦＤ管理オブジェクト３００からのＦＦＤ取得に係る処理（記号Ｃで示すＳ５０４０及びＳ５０５０の処理、以下「処理Ｃ」という。）の３つの処理Ａ，Ｂ，Ｃが、故障情報取得処理Ｓ５に常にそろって記述されるわけではない。サービス実行オブジェクト５００は、スキャンツール５０にて指定されるカテゴリの単位で用意され、例えばあるカテゴリにはＦＦＤのみが含まれることも考えられるからである。このようなＦＦＤのみを含むカテゴリに対応するサービス実行オブジェクト５００の実行する故障情報取得処理Ｓ５には、処理Ｃだけが記述されることになる。具体的に、例えばＦＦＤを読み出すための「Ｍｏｄｅ＄０２」に対応するサービス実行オブジェクト５００が、これに相当する。この場合、指定データによって例えば「故障時のエンジン回転数」などが指定されると、サービス実行オブジェクト５００は、処理Ｃの中で「故障時のエンジン回転数」をＦＦＤ管理オブジェクト３００へ要求するという具合である。同様に、１つの処理（処理Ａ又は処理Ｂ）だけが記述されたもの、２つの処理（処理ＡとＢ，処理ＢとＣ，処理ＣとＡ）だけが記述されたサービス実行オブジェクト５００も存在する場合がある。
【００６４】
続けて検出情報出力処理Ｓ６を説明する。図８は、故障検出オブジェクト１００にて実行される検出情報出力処理Ｓ６を示すフローチャートである。
まず最初のＳ６０００において、サービス実行オブジェクト５００から要求された検出情報を判断する。続くＳ６０１０では、それらの検出情報を収集する。例えばセンサ群からリアルタイムに出力されるセンサ値を収集するという具合である。そして次のＳ６０２０では、収集した検出情報を出力し、その後、本検出情報出力処理Ｓ６を終了する。
【００６５】
さらに続けて、故障情報管理オブジェクト２００にて実行されるダイアグ故障情報出力処理Ｓ７及び、ＦＦＤ管理オブジェクト３００にて実行されるＦＦＤ出力処理Ｓ８を、図９及び図１０のフローチャートに基づいて説明する。これらの処理は上述した検出情報出力処理Ｓ６とほぼ同様であるため、それぞれ簡単に説明する。
【００６６】
ダイアグ故障情報出力処理Ｓ７では、処理が開始されると、要求されたダイアグ故障情報を判断する（図９中のＳ７０００）。そして、例えばダイアグ故障情報を保存している故障情報保存オブジェクトから読み出して、ダイアグ故障情報を収集し（Ｓ７０１０）、収集したダイアグ故障情報を出力する（Ｓ７０２０）。その後、本ダイアグ故障情報出力処理Ｓ７を終了する。
【００６７】
ＦＦＤ出力処理Ｓ７では、処理が開始されると、要求されたＦＦＤを判断する（図１０中のＳ８０００）。そして、例えばＦＦＤを保存しているＦＦＤ保存オブジェクトから読み出して、ＦＦＤを収集し（Ｓ８０１０）、収集したＦＦＤを出力する（Ｓ８０２０）。その後、本ＦＦＤ出力処理Ｓ８を終了する。
【００６８】
以上のように各オブジェクト１００〜５００を構成したことによる効果を次に述べる。
本実施例では、サービスプログラムを、スキャンツール５０との通信を行うサービス管理オブジェクト４００と、オブジェクト１００〜３００へ故障情報を要求して取得するサービス実行オブジェクト５００とに分けて構成した（図３参照）。つまり、スキャンツール５０との通信機能と故障情報の取得機能とを別個のオブジェクトにて実現するようにしたのである。これによって、スキャンツール５０との通信方法のみが変更された場合には、サービス管理オブジェクト４００のみを変更することで容易に対応できる。そしてこのとき、サービス実行オブジェクト５００についてはそのまま再利用することができ、サービスプログラムの再利用性を向上させることができる。
【００６９】
また、本実施例では、サービス実行オブジェクト５００を、スキャンツール５０にて指定されるカテゴリ毎に用意した。言い換えれば、指定されるカテゴリに属する故障情報のまとまり（車両情報群）毎に、サービス実行オブジェクト５００を用意した。したがって、読出対象となる故障情報が変更されても、このまとまりの単位での変更作業が可能になり、故障情報の変更に容易に対応できる。そして、スキャンツール５０にて指定されるカテゴリは、法規に基づいて、さらには、車両メーカの要求に基づいて定められるものであり、このカテゴリの単位で故障情報が変更される可能性が高い。このように、同時に変更される可能性の高い故障情報のまとまりの単位でサービス実行オブジェクト５００を用意しておけば、変更箇所がオブジェクト単位でまとまる可能性が高く、結果的に、再利用できるサービス実行オブジェクト５００が増えて、サービスプログラムの再利用性の向上に寄与する。
【００７０】
さらにまた、本実施例では、スキャンツール５０からの特定データに基づき、サービス管理オブジェクト４００が、該当するサービス実行オブジェクト５００を判断する（図６中のＳ４０００）。これによって、サービス管理オブジェクト４００による、該当するサービス実行オブジェクト５００の判断処理が簡単なものになる。特定データは入力されるカテゴリに対応するものだからであり、例えば特定データとサービス実行オブジェクト５００との対応関係を用意しておけばよいためである。
【００７１】
また、本実施例では、カテゴリ内の情報を指定するための指定データに基づき、サービス実行オブジェクト５００が、該当するオブジェクト１００〜３００へ故障情報を要求する（図７中のＳ５０１０，Ｓ５０３０，Ｓ５０５０）。これによって、サービス実行オブジェクト５００による車両情報の取得処理が簡単なものとなる。
【００７２】
そしてこのように、サービス実行オブジェクト５００は、オブジェクト１００〜３００へ故障情報を要求することによって、それらオブジェクト１００〜３００から出力される故障情報を取得する。すなわち、サービス実行オブジェクト５００からの要求に応じて、該当するオブジェクト１００〜３００が動作することによって（図８，９，１０参照）故障情報が取得される。つまり、サービス実行オブジェクト５００は、故障情報を要求するだけであり、故障情報がどこに記憶されているかということについて何等意識する必要がないのである。その結果、サービス実行オブジェクト５００単位での変更が極めて簡単になっている。
【００７３】
以上、本発明はこのような実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。
（イ）上記実施例では、サービス実行オブジェクト５００を、スキャンツール５０にて指定されるカテゴリの単位で用意していた。この場合、スキャンツール５０から出力される特定データと、起動されるサービス実行オブジェクト５００が１対１に対応するという点で、サービス管理オブジェクト４００による判断処理が簡単になるというメリットが享受できる。しかし、サービス実行オブジェクト５００の設定単位はこれに限定されるわけではなく、システムの様々な変更パターンを考慮し、同時に変更される可能性の高い故障情報のまとまりの単位で設けることが考えられる。
【００７４】
（ロ）また、上記実施例では、スキャンツール５０にて故障情報を読み出す場合を例に挙げて説明したが、スキャンツール５０の読出対象となる情報は、故障情報に限定されない。すなわち、故障情報を含む車両情報を読出対象とすることが考えられる。
【００７５】
具体的には、サービス実行オブジェクト５００の故障情報取得処理Ｓ５に、例えば図７中のＳ５０６０及びＳ５０７０の処理（記号Ｄで示す破線で示した処理、以下「処理Ｄ」という。）を記述する。すなわち、車両情報の指定があるか否かを判断し（Ｓ５０６０）、車両情報の指定があれば（Ｓ５０６０：ＹＥＳ）、ＰＦ６００へ車両情報を要求する（Ｓ５０７０）。このようにして、例えばエミッションに係る情報やアクチュエータに係る情報などの様々な車両情報を読み出す構成も、処理Ｄと処理Ｄに対応するＰＦ６００側の車両情報出力に係る処理を記述することによって実現できる。このような車両情報は、ＰＦ６００から車両内のネットワークを介して得られる情報であることも考えられる。
【図面の簡単な説明】
【図１】実施例のエンジン制御システムを示す構成図である。
【図２】実施例のエンジン制御ユニットの構成を示すブロック図である。
【図３】実施例のプログラム構造を概念的に示した説明図である。
【図４】故障情報の保存手順を示すＭＳＣである。
【図５】故障情報の読出手順を示すＭＳＣである。
【図６】サービス管理オブジェクトの実行する起動処理を示すフローチャートである。
【図７】サービス実行オブジェクトの実行する故障情報取得処理を示すフローチャートである。
【図８】故障検出オブジェクトの実行する検出情報出力処理を示すフローチャートである。
【図９】故障情報管理オブジェクトの実行するダイアグ故障情報出力処理を示すフローチャートである。
【図１０】ＦＦＤ管理オブジェクトの実行するＦＦＤ出力処理を示すフローチャートである。
【符号の説明】
１１…エンジン
１２…吸気管
１３…エアフローセンサ
１４…吸気温センサ
１５…スロットル弁
１６…エンジン制御ユニット
１７…スロットルセンサ
１８…空燃比センサ
１９…バッテリ
２０…水温センサ
２１…ディストリビュータ
２２ａ，２２ｂ，２２ｃ，２２ｄ
…インジェクタ
２３…イグナイタ
２４…テストスイッチ
２５…警告灯
２６…イグニッションスイッチ
２７…スタータモータ
２８…スタータスイッチ
３２…アナログ入力回路
３３…ディジタル入力回路
３４…Ａ／Ｄ変換器
３５…電源回路
３６，３７，３８
…出力回路
３９…メモリ
４０…入出力回路
５０…スキャンツール
１００…故障検出オブジェクト
２００…故障情報管理オブジェクト
３００…ＦＦＤ管理オブジェクト
４００…サービス管理オブジェクト
５００…サービス実行オブジェクト
６００…ＰＦ

Claims (9)

1. 外部装置からの要求があると、車両に関連する車両情報を読み出して出力する情報提供機能と、
   ダイアグ対象の故障検出結果に基づいて前記ダイアグ対象の故障に関する情報である故障情報を記憶する自己診断機能と
   を備えた車両用制御装置において、
   前記情報提供機能を実現するためのサービスプログラムは、
   オブジェクト指向設計され、再利用が可能なオブジェクトの単位で構成され、
   前記自己診断機能を実現するための自己診断プログラムは、
   オブジェクト指向設計され、再利用が可能なオブジェクトの単位で構成され、
   前記情報提供機能は、
   前記車両情報の所定のまとまりである車両情報群毎に用意され、起動指示に基づいて、対応する車両情報群中の車両情報を取得する複数のサービス実行オブジェクトと、
   前記外部装置との間でデータ通信を行い、前記外部装置からの情報要求があると、該当するサービス実行オブジェクトを判断し、当該サービス実行オブジェクトに対し起動指示を行うと共に、当該サービス実行オブジェクトにて取得された前記車両情報を前記外部装置へ出力するサービス管理オブジェクトと
   で実現され、
   前記各サービス実行オブジェクトは、起動指示に基づいて、該当する自己診断プログラムを構成するオブジェクトに対し、前記故障情報を要求することにより、前記車両情報として前記故障情報を取得可能な構成にされ、
   前記自己診断プログラムを構成するオブジェクトは、前記サービス実行オブジェクトから要求された故障情報を、要求元の前記サービス実行オブジェクトに対して出力する構成にされていること
   を特徴とする情報提供機能を備えた車両用制御装置。
2. 請求項１に記載の車両用制御装置において、
   前記車両情報群を、前記車両情報の変更パターンを考慮し、同時に変更される車両情報のまとまりとしたこと
   を特徴とする情報提供機能を備えた車両用制御装置。
3. 請求項２に記載の車両用制御装置において、
   前記車両情報群を、法規又は車両メーカの要求の少なくとも一方に基づき定められる車両情報のまとまりとしたこと
   を特徴とする情報提供機能を備えた車両用制御装置。
4. 請求項１〜３のいずれかに記載の車両用制御装置において、
   前記外部装置からの情報要求には、少なくとも前記車両情報群を特定するための特定データが含まれており、
   前記サービス管理オブジェクトは、前記特定データに基づき、前記該当するサービス実
   行オブジェクトを判断すること
   を特徴とする情報提供機能を備えた車両用制御装置。
5. 請求項４に記載の車両用制御装置において、
   前記外部装置からの情報要求には、さらに、前記車両情報群中の車両情報を指定するための指定データが含まれており、
   前記サービス管理オブジェクトは、前記起動指示と共に前記指定データを出力し、
   前記サービス実行オブジェクトは、前記サービス管理オブジェクトから出力される前記指定データに基づき、前記車両情報群中の車両情報を取得すること
   を特徴とする情報提供機能を備えた車両用制御装置。
6. 請求項１〜５のいずれかに記載の車両用制御装置において、
   前記自己診断プログラムは、故障検出結果に基づき、故障項目に対応するダイアグ故障情報を管理する故障情報管理オブジェクトを少なくとも備えており、
   前記サービス実行オブジェクトは、必要に応じて、前記故障情報管理オブジェクトに対して前記ダイアグ故障情報を要求することにより、前記ダイアグ故障情報を前記故障情報として取得すること
   を特徴とする情報提供機能を備えた車両用制御装置。
7. 請求項６に記載の車両用制御装置において、
   前記自己診断プログラムは、さらに、
   前記ダイアグ故障情報の付帯情報であって、故障時の車両状態を含むフリーズ情報を管理するＦＦＤ管理オブジェクトを備えており、
   前記サービス実行オブジェクトは、必要に応じて、前記ＦＦＤ管理オブジェクトに対して前記フリーズ情報を要求することにより、前記フリーズ情報を前記故障情報として取得すること
   を特徴とする情報提供機能を備えた車両用制御装置。
8. 請求項６又は７に記載の車両用制御装置において、
   前記自己診断プログラムは、さらに、
   前記ダイアグ対象の故障を検出する故障検出オブジェクトを備えており、
   前記サービス実行オブジェクトは、必要に応じて、前記故障検出オブジェクトに対して故障検出に係る検出情報を要求することにより、前記検出情報を前記故障情報として取得すること
   を特徴とする情報提供機能を備えた車両用制御装置。
9. 請求項１〜８のいずれかに記載の車両用制御装置の前記サービスプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images