JP2008121646A - エンジン制御装置 - Google Patents

Abstract

【課題】
エンジン制御装置の起動方法により制御を切り替えるシステムのソフトウェア構造において、簡単なソフトウェア構造の提供を目的とする。
【解決手段】
エンジン制御装置の起動方法によって制御が切り替わると共にエンジン制御装置の起動方法をリアルタイムオペレーティングシステムの起動前に検知できる手段を有したシステムのソフトウェア構造であって、制御毎に個別に複数のタスクキューを有することを特徴とするソフトウェア構造を用いたエンジン制御装置。
【選択図】図１

Description

本発明は、リアルタイムオペレーディングシステム（以下、リアルタイムＯＳ）のソフトウェア構造に係り、エンジン制御装置の起動方法により制御を切り替えるシステムのソフトウェア設計工数の削減を図るソフトウェア構造を有するエンジン制御装置に関する。

エンジン制御装置の一般においては、タスクキューと呼ばれるタスク毎の起動周期と優先順位を登録するマップを、タスクディスパッチャと呼ばれるリアルタイムＯＳの起動タスク管理システムが参照し、起動周期と優先順位を考慮した適切なタスク起動により、制御が行われるように設計されており、原則的にはタスクキューとリアルタイムＯＳは一対である。この場合、エンジン制御装置の起動方法により制御を切り替えるシステムは、タスク単位、もしくはさらに細分化した単位で起動方法を条件に処理を分岐させて制御を切り替えるソフトウェア構成となる。

エンジン制御装置において、エンジン制御装置の起動方法により切り替える制御には、例えば燃料タンクのエバポのリーク診断と、エンジン制御装置が正常に動作しているか否かを判定する診断（以下、「ハードチェック制御」という。）がある。なお、エンジン制御装置の起動方法により制御を切り替えるシステムに関する文献としては、特許文献１がある。これは、車両燃料タンクのエバポのリーク診断制御に関するものであり、車両走行制御と、燃料タンクのエバポのリーク診断制御を、エンジン制御装置の起動方法によって切り替えるシステムである。

特開２００４−２４５２１２号公報

しかしながら、上記に示す従来技術は、そのシステムを実現するソフトウェア構造に関する記述が十分に開示されておらず、また、効率的なソフトウェア構造を十分に考慮してソフトウェア設計を行わなければ、複雑なソフトウェア構造になることが一般的である。複雑なソフトウェア構造は、ソフトウェア設計において、全体が見え辛い為に、影響範囲の検討工数の増加，制御毎に独立していない為に、他の装置へのソフトウェア展開工数の増加という問題がある。

本発明の目的は、上記従来技術の課題に鑑み、エンジン制御装置の起動方法により制御を切り替えるシステムに対して簡易なソフトウェア構造を提供することにある。

本発明において、エンジン制御装置の起動方法によって制御が切り替わり、かつエンジン制御装置の起動方法をリアルタイムオペレーティングシステムの起動前に検知できる手段を有したシステムのソフトウェア構造であって、制御毎に個別に複数のタスクキューを有することを特徴とするソフトウェア構造を用いる。

さらに好ましくは、上述のエンジン制御装置において、リアルタイムオペレーティングシステムの起動前に中央処理装置の起動方法により複数あるタスクキューからタスクキューを選択することを特徴とするソフトウェア構造を用いる。

さらに好ましくは、上述のエンジン制御装置において、異なる制御間で全く同様のタスクがある場合、制御毎に設計したタスクキュー間でそのタスクを共有させることを特徴とするソフトウェア構造を用いる。

本発明によれば、制御毎に個別にタスクキューを有し、エンジン制御装置の起動方法により制御に応じたタスクキューを選択することで、独立した制御による、簡易なソフトウェア構成の設計と、影響範囲の検討工数の削減が可能となる。

以下、本発明が適用された実施例について図面を用いて説明する。

図１は、本発明で提案する、エンジン制御装置の起動方法によって制御を切り替えるシステムの代表的なソフトウェア構造である。実施例として、車両走行制御と、エバポのリーク診断制御と、ハードチェック制御の３つの制御を実現するソフトウェア構造を用いたエンジン制御装置について説明する。

なお、車両走行制御とは、車両が通常走行時に実行するエンジン制御と診断制御のことであり、ハードチェック制御は、エンジン制御装置の入出力等が正常に動作しているか否かを診断する制御であり、診断時は通常は有りえない入出力値を用いる場合がある為、本発明の実施例では起動条件により、通常の車両走行制御と制御を切り替えて実施する。また、エバポのリーク診断制御についても、エンジン制御装置の起動方法で車両走行制御と制御を切り替えて実施する診断方法がある。

Ｓ１０でエンジン制御装置の中央処理装置（以下ＣＰＵ）起動後、Ｓ２０でＣＰＵレジスタの初期化、Ｓ３０でドライバの初期化を実施する。Ｓ３５のエンジン制御装置の起動方法判定により、車両の通常走行制御の起動と判定された場合は、Ｓ４０でエンジン制御タスク全般の初期化を実施し、Ｓ５０で車両走行制御用のタスクキューのアドレスをバッファに格納する。同様に、エバポのリーク診断制御もしくはハードチェック制御の起動と判定された場合は、それぞれのタスクの初期化を実施し、対応する制御のタスクキューのアドレスをバッファに格納する。Ｓ６０で、バッファに格納されたタスクキューのアドレスをリアルタイムＯＳに登録する。Ｓ７０でリアルタイムＯＳが起動後、タスクディスパッチャが登録されたタスクキューを参照する。

これにより、本発明によると、タスクキューに登録するタスク毎に分岐を入れずに、タスクキューを制御毎に作成し、タスクディスパッチャが参照するタスクキューを選択する為、制御毎に独立したソフトウェア構造を実現し、簡易なソフトウェア構成によるソフトウェアの新規設計・変更時の工数を削減することが可能となる。

次に、起動方法の判別方法について述べる。図２は、車両燃料タンクのエバポのリーク診断とハードチェック制御を実現する為の、車両に搭載されるエンジン制御装置２０１であり、このエンジン制御装置２０１は、ＣＰＵ２０２，ＳｕｂＣＰＵ２０３の２つのCPUを有する。ＣＰＵ２０２の起動は、メインリレー２０４からの電源供給で制御されており、メインリレー２０４の入力は、イグニッションスイッチ２０５とＣＰＵ２０２の電源供給制御２０６の出力信号と、ＳｕｂＣＰＵ２０３からのＣＰＵ起動制御信号２１２の出力信号とのＯＲ回路２０７で構成される。ＳｕｂＣＰＵ２０３の起動は、電源回路２０８からの電源供給により制御されており、電源回路２０８はイグニッションスイッチ２０５と
ＳｕｂＣＰＵの電源供給制御２０９の出力信号とのＯＲ回路２１０で構成される。また、このエンジン制御装置は外部通信機器２１５との通信機能を搭載しており、情報の送受信が可能である。

図３はエバポのリーク診断のタイムチャートである。エバポのリーク診断は、車両停止状態が一定時間経過した後、エバポのリーク診断のみ実行する。その方法は、通常の車両走行制御時はユーザーによるイグニッションスイッチ２０５の入力がメインリレー２０４への入力ＯＲ回路２０７への入力となり、それにより、ＣＰＵ２０２が起動する。エバポのリーク診断の際は、イグニッションスイッチオフ時、ＣＰＵ２０２の電源はオフになるが、ＳｕｂＣＰＵ２０３は電源オンの状態を継続し内部タイマー２１１でＣＰＵ２０２の停止状態継続時間をカウントする。一定時間経過後、ＳｕｂＣＰＵ２０３がＣＰＵ起動制御信号２１２をメインリレー２０４への入力ＯＲ回路２０７へ出力し、メインリレー204がオンとなりＣＰＵ２０２が起動する。

Ｓ３５の判定処理において、エバポのリーク診断制御の為のエンジン制御装置の起動か否かの判定方法は、イグニッションスイッチ２０５オンかつＣＰＵ起動制御信号２１２オフの場合、車両走行制御の為のエンジン制御装置の起動で、イグニッションスイッチ205オフかつＣＰＵ起動制御信号２１２オンの場合は、エバポのリーク診断制御用のエンジン制御装置の起動と判定できる。

図４は、ハードチェック制御のタイムチャートである。エンジン制御装置が、外部通信機器２１５よりハードチェック要求信号を受信すると、ＣＰＵ２０２はハードチェック起動判定用のバックアップラムに情報を格納した後、再起動を行う。再起動後にハードチェック起動判定用のバックアップラムをクリアするので、このバックアップラムをモニタすることで判定できる。

Ｓ３５の判定処理において、ハードチェック制御の起動か否かの判定は、エンジン制御装置の起動時にバックアップラムの値がクリアされていた場合、車両走行制御の起動で、値が保持されていた場合はハードチェック制御の起動と判定することが可能である。

図５は車両走行制御用タスクキューを示している。タスクキューには車両走行制御に必要なタスクを、優先順位と処理周期のマップに登録する。リアルタイムＯＳのタスクディスパッチャはタスクキューを参照して優先順位と処理周期から実行するタスクを決定する。登録されたタスクの内、タスク１とタスク２はエバポのリーク診断制御時にも同様の処理を実行するタスクである。

図６はエバポのリーク診断制御用のタスクキューを示している。新規にエバポのリーク診断を設計する際、本発明のソフトウェア構造では、エバポのリーク診断用のタスクキューを新規に設計する。車両走行制御が既存であれば、新規設計するタスクキューに登録するタスクの内、車両走行制御と共通の動作をするタスクは制御間で共有可能である為、タスク１，タスク２を新規で設計する必要が無くなる。

図７はハードチェック制御用のタスクキューを示している。新規にハードチェック制御を設計する際も同様に、本発明のソフトウェア構造では、ハードチェック用のタスクキューを新規に設計する。車両走行制御が既存である場合、新規設計するタスクキューに登録するタスクの内、車両走行制御と共通の動作をするタスクは制御間で共有可能である為、タスク２，タスク５を新規で設計する必要が無い。

これにより、エンジン制御装置の起動方法により制御内容が切り替わるような制御を新規で設計する際、システム中の既存のタスクは流用できる為、新規設計するタスクは、追加する制御特有のタスクのみに留まるものである。

上述のように、本発明によれば、制御毎に作成した複数のタスクキューを有するソフトウェア構造は、異なる制御間でタスクを共有することで、ソフトウェア開発工数削減が可能であるソフトウェア構造とすることができる。

本発明は、エンジン制御装置の起動方法により制御を切り替えるシステムのソフトウェア構造に関する。

エンジン制御装置の起動方法により制御を切り替えるシステムの代表的なソフトウェア構造を示す図である。 本発明が適用されたエバポのリーク診断制御とハードチェック制御を有する車両の電子制御装置の模式図である。 本発明で適用したエバポのリーク診断制御のタイムチャートである。 本発明で適用したハードチェック制御のタイムチャートである。 本発明が適用されたエバポのリーク診断制御とハードチェック制御を有する車両の、車両走行制御用タスクキューの模式図である。 本発明が適用されたエバポのリーク診断制御とハードチェック制御を有する車両の、エバポのリーク診断用タスクキューの模式図である。 本発明が適用されたエバポのリーク診断制御とハードチェック制御を有する車両の、ハードチェック制御用タスクキューの模式図である。

符号の説明

２０１ エンジン制御装置（車両に搭載されるエンジン制御用電子制御装置）
２０２ ＣＰＵ
２０３ ＳｕｂＣＰＵ
２０４ メインリレー
２０５ イグニッションスイッチ
２０６，２０９ 電源供給制御
２０７，２１０ 入力ＯＲ回路
２０８ 電源供給回路
２１１ 内部タイマー
２１２ ＣＰＵ起動制御信号

Claims (3)

1. エンジン制御装置の起動方法によって制御が切り替わると共にエンジン制御装置の起動方法をリアルタイムオペレーティングシステムの起動前に検知できる手段を有したシステムのソフトウェア構造であって、制御毎に個別に複数のタスクキューを有することを特徴とするソフトウェア構造を用いたエンジン制御装置。
2. 請求項１に記載のエンジン制御装置において、リアルタイムオペレーティングシステムの起動前に前記エンジン制御装置の起動方法に基づいて前記複数あるタスクキューからタスクキューを選択することを特徴とするソフトウェア構造を用いたエンジン制御装置。
3. 請求項１に記載のエンジン制御装置において、異なる制御間で同一の処理を行うタスクがある場合、制御毎に設計したタスクキュー間でそのタスクを共有させることを特徴とするソフトウェア構造を用いたエンジン制御装置。

Images