JP4728020B2 - 車両制御用ソフトウェア及び車両制御装置 - Google Patents

Description

本発明は、車両の走行状態を制御する車両制御ソフトウェア及び車両制御装置に関する。

近年、車両制御システムとして、マイクロプロセッサおよびマイクロプロセッサによって実行されるソフトウェア（コンピュータ・プログラム）を用いて、車両を電子的に制御するシステムが急速に発展している。電子式車両制御システムにより、エンジンの燃焼状態をきめ細かく制御して燃費を向上したり、排出ガスを低減したりすることが可能になっている。また、制動力や駆動力や操舵角に関する制御手段を、通信により連動させて車両全体の運動状態を統合的に制御するシステムが実用化されている。

このような車両制御システムに用いられるソフトウェアのサイズは非常に大きくなるため、いわゆるオブジェクト指向を採用してソフトウェアを部品化し、部品単位で、ソフトウェアの開発・再利用を行う手法が採用されている。

また、車両制御用ソフトウェアは、電子制御装置そのものやセンサ・アクチュエータ類を制御するための基本プログラムと、センサ・アクチュエータを利用してエンジンや変速機などを制御する制御アプリケーションとに分割して構成されるようになりつつある。

従来技術として、公開側プログラムと参照側プログラムとの間にデータ形式を変換する変換プログラム（管理プログラム）を設け、公開側プログラムのデータを、参照側プログラムからの参照要求のタイミングに合わせて変換処理を行って参照側プログラムに渡すプログラム構造のソフトウェアがある（例えば、特許文献１）。

このプログラム構造のソフトウェアは、公開側プログラムと参照側プログラムとのデータ形式の違いを吸収し、データ形式の不一致による再利用性の低下を防止することができる。
特開２００３−２５６２０１号公報

ここで、基本プログラムに属するソフトウェア部品と、制御アプリケーションに属するソフトウェア部品との間のデータの受け渡しを考える。車両制御用電子制御装置の基本プログラムは、電子制御装置メーカが作成するが、制御アプリケーションの要求仕様、すなわち、センサやアクチュエータ入出力値の変数名や単位等のデータ形式は、車両メーカごとに異なっているローカルなものである。

そのため、基本プログラム部分のソフトウェア部品において、センサやアクチュエータ入出力値などのデータ形式が標準化できず、再利用性が低下してしまうという問題点がある。

このような問題点を回避するため、前述の従来技術のように、データ形式を変換する変換プログラムを設け、変換プログラムを経由して基本プログラムのデータにアクセスするという方法が知られている。

しかし、この方法では、データを参照するごとに変換処理が実行されるため、複数の制御アプリケーションが、一つの基本プログラム（ソフトウェア部品）を参照していた場合には、参照要求が起こるごとに変換処理が行われ、変換処理頻度が高くなり、処理効率が悪化するという課題が生じる。

また、データ変換のタイミングを、基本プログラムのデータ更新タイミングと同期させる方法も考えられる。

しかしながら、この同期変換では、制御アプリケーションでのデータ同時性の問題が生じる。すなわち、同じ時間周期で起動要求が行われるタスク（たとえば１０ｍｓ周期）の中で実行される制御アプリケーション中では、そのタスク実行中は、基本プログラム側の制御データが更新されないように見えている必要がある。

デジタル制御理論では、周期的・外部割込みに同期して行われる制御処理は、瞬間的に行われ、処理中は状態変化が起きないものとして設計する。

しかし、マイクロプロセッサ上でソフトウェアが実際に動作する際には、若干の実行時間が必要となる。そのため、タスクの前半と後半とで、実際には状態変化が生じていたとしても、制御アプリケーションからは、当該タスク起動時の状況を保持し続けなければならないという課題がある。

本発明は、前記課題に鑑みてなされたものであって、その目的とするところは、データ形式の変換が必要なリアルタイムの車両制御ソフトウェアであって、データ変換処理回数を低減して処理性能を向上させ、処理効率を高く、制御データの同時性も保つことができる車両制御用ソフトウェアを提供することにある。

この発明による車両制御用ソフトウェアは、車両を制御するための情報である制御データと、前記制御データを公開するソフトウェア部品である公開側ソフトウェア部品と、前記制御データを参照するソフトウェア部品である参照側ソフトウェア部品と、前記公開側ソフトウェア部品と前記参照側ソフトウェア部品との間での前記制御データの受け渡しに際してデータ形式を変換するデータ変換ソフトウェアと有し、前記データ変換ソフトウェアは所定のタイミングで起動要求され、前記公開側ソフトウェア部品にデータ参照要求を行い、取得した前記制御データを前記参照側ソフトウェア部品が参照するデータ形式へと変換する。

この発明による車両制御用ソフトウェアは、好ましくは、前記データ変換ソフトウェアは、変換した前記制御データを参照用データとして保存するとともに、前記参照側ソフトウェア部品は前記参照用データを参照する車両制御用ソフトウェア。

この発明による車両制御用ソフトウェアは、好ましくは、データ変換ソフトウェアは、前記参照側ソフトウェア部品の用意するデータ要求命令を用いて、変換した前記制御データを前記参照側ソフトウェア部品に渡す。

この発明による車両制御用ソフトウェアは、好ましくは、前記公開側ソフトウェア部品と前記参照側ソフトウェア部品との間での前記制御データの受け渡しに際して変換される前記データ形式とは、少なくとも変数名と変数単位とのいずれか一つである。

この発明による車両制御用ソフトウェアは、好ましくは、前記データ変換ソフトウェアが起動要求されるタイミングを、前記参照用ソフトウェア部品が起動要求されるタイミングとは独立に設定する。

この発明による車両制御用ソフトウェアは、好ましくは、前記データ変換ソフトウェアが起動要求されるタイミングを、前記公開用ソフトウェア部品が起動要求されるタイミングとは独立に設定する。

この発明による車両制御用ソフトウェアは、好ましくは、前記データ変換ソフトウェアが起動要求されるタイミングが、少なくとも時間周期か、割り込み信号のいずれかである。

この発明による車両制御用ソフトウェアは、好ましくは、前記ソフトウェア部品とは、車両制御用ソフトウェアが搭載されている電子車両制御装置とセンサとアクチュエータを制御するための基本ソフトウェア部品と、前記基本ソフトウェア部品を用いて制御対象の状態を制御するための制御アプリケーション部品とで構成される。

この発明による車両制御用ソフトウェアは、好ましくは、前記データ変換ソフトウェアによって前記制御データが変換されるのは、前記基本ソフトウェア部品と前記制御アプリケーション部品との間のデータの公開および参照の際である。

この発明による車両制御用ソフトウェアは、好ましくは、前記ソフトウェア部品が前記制御データを公開するとともに前記制御データを参照する部品である。

この発明による車両制御用ソフトウェアは、好ましくは、前記ソフトウェア部品が公開データと参照要求データの区別を明示したインターフェースを持つことである。

この発明による車両制御用ソフトウェアは、好ましくは、前記データ変換ソフトウェアが前記ソフトウェア部品の明示する公開用データと参照要求データの区別を参照することである。

この発明のマイクロコンピュータを用いて車両の制御を行う車両制御用装置は、請求項１〜１２に記載のソフトウェアを搭載することを特徴としている。

この発明による車両制御用ソフトウェアは、データ変換ソフトウェアの実行タイミングを、参照側ソフトウェア部品に呼び出されたタイミングではなく、別の実行タイミングを設けて起動要求を行うにすることによって、制御データの同時性を設計してデータ変換ソフトウェアの実装を行うことができる。

本発明による車両制御ソフトウェアの一つの実施形態の概要を、図１を参照して説明する。

本実施形態の車両制御ソフトウェアは、公開用データ２を持つデータ公開側ソフトウェア部品１と、データ対応部４を持つデータ変換ソフトウェア部品（プログラム）３と、参照用データ５Ａ、５Ｂを格納するデータストレージ６と、第１〜第３のデータ参照側ソフトウェア部品（プログラム）７、８、９とで構成されている。

データ公開側ソフトウェア部品１は、そのソフトウェア部品ごとに定められたタイミングによって公開用データ２を更新する。

データ変換ソフトウェア３は、時間周期やマイクロプロセッサコアへの割り込み信号などの所定のタイミングで起動する。データ変換ソフトウェア３のデータ対応部４は、それぞれの起動タイミングで変換するべきデータを定義している。

起動したデータ変換ソフトウェア３は、データ対応部４に定義されたソフトウェア部品、例えば公開側ソフトウェア部品１の公開用データ２を、データ公開側ソフトウェア部品１が用意するインタフェースを利用して取得する。

そして、取得した公開用データ２のデータ名や、変数の単位などを変換したのち、参照用データ５Ａとしてデータストレージ６に保存する。

第１のデータ参照側ソフトウェア部品７、第２のデータ参照側ソフトウェア部品８は、それぞれの参照用ソフトウェア部品ごとに定義された起動タイミングで起動し、データストレージ６が用意するインタフェースを利用して参照用データ５Ａを参照して、各々自プログラムに従ってデータ参照側処理を行う。

また、上記とは異なるタイミングでデータ変換ソフトウェア３は起動され、上記と同一のデータ公開側ソフトウェア部品１の公開用データ２を変換し、これを上記とは異なる参照用データ５Ｂとしてデータストレージ６に保存する。

第３のデータ参照側ソフトウェア部品９は、データストレージ６が用意するインタフェースを利用して参照用データ５Ｂを参照して、自プログラムに従ってデータ参照側処理を行う。

上記のような構成をとることによって、複数のデータ参照側のソフトウェア部品が一つのデータを参照し、かつそのデータの変換が必要な場合でも、参照要求ごとに変換処理を行う必要がなく、ソフトウェアの処理効率が向上する。

例えば、同じデータを１０ｍｓ周期タスクで参照する場合を考える。参照されるデータの元となる公開用データの更新処理が、１０ｍｓ周期タスクよりも優先度が高い場合には、１０ｍｓ周期タスクの処理中に公開用データが変更されてしまい、１０ｍｓ周期という同じタイミングで起動される処理にもかかわらず、同じデータを参照した場合の値が異なってしまうという問題がある。

このような状態を、変数の同時性が損なわれるという。本構成をとることによって、１０ｍｓ周期タスク内では参照用データの同時性が保たれるという効果がある。

さらに、４０ｍｓ周期タスクからも同じ公開用データを参照する場合を考える。このとき、１０ｍｓ周期タスクの優先度は４０ｍｓ周期タスクの優先度よりも高いものとする。

一つの公開用データに対して参照用データが一つしかない場合には、４０ｍｓ周期タスク処理中にデータ変換処理が実行されてしまい、４０ｍｓ周期タスクでの変数の同時性が損なわれるという問題点がある。

本実施形態のように、一つの公開用データに対して複数の参照用データを用意し、必要に応じてタスク毎に参照用データを割り当てることによって、複数のタスクから一つのデータを参照する場合でも変数の同時性が保たれるという効果がある。

図２は、本発明の車両制御用ソフトウェアが適用されるエンジン向けの電子制御装置（ＥＣＵ）５０を示している。

ＥＣＵ５０に搭載されるソフトウェアは、ＥＣＵそのものやＥＣＵに接続されるセンサ・アクチュエータ類を制御するための基本ソフトウェア（プラットフォームソフトウェア）部分２０と、センサ・アクチュエータを利用してエンジンや変速機などを制御するアプリケーション部分１０とで構成される。

制御アプリケーション部分１０と基本ソフトウェア部分２０との間でのデータの受け渡しを、図３を参照して説明する。

近年、車両制御用ソフトウェアはソフトウェア規模の大型化に伴い、ソフトウェアを部品化して構成するオブジェクト指向がとられている。そのため、データの受け渡しも、そのオブジェクトのインタフェースを利用して行われる。

その一方で、基本ソフトウェア部分２０は、ＥＣＵメーカによって開発され、制御アプリケーション部分１０は、カーメーカによって開発される。

基本ソフトウェア部分２０のインタフェースは、そのＥＣＵメーカ内で共通化されるが、制御アプリケーション部分のインタフェース仕様は、カーメーカによって異なる。

たとえば、トルクを制御する制御アプリケーションソフトウェア部品がエンジン回転数を参照する場合を考える。

トルクべースエンジン制御を行う第１の制御アプリケーションソフトウェア部品１０１は、ＮＤＡＴＡというインタフェース１０１１を利用してアクセスしようとし、もう一つのトルクべースエンジン制御を行う第２の制御アプリケーションソフトウェア部品１０２は、ＥｎｇＲｅｖというインタフェース１０２１を使用してアクセスしようとする。

ここで、従来技術のデータ変換ソフトウェアについて、図４を参照して説明する。
図４に示すデータ変換ソフトウェアは、データ公開側ソフトウェア部品９１と、公開用データ９３と対応テーブル９４とを有するデータ変換ソフトウェア９２と、データ参照側ソフトウェア部品９５とで構成されている。

データ公開側ソフトウェア部品９１は、データ変換ソフトウェア９２に対して公開データ登録を行い、公開用データ９３を更新する。

データ参照側ソフトウェア部品９５は、データ変換ソフトウェア９２に対してデータ参照要求を行う。参照要求を受けたデータ変換ソフトウェア９２は、対応テーブル９４に基づいて、要求されたデータと公開用データ９３との対応をとる。その上で、対応する公開用データ９３の変数名や変数単位などのデータ形式を変換し、これを、参照要求元のデータ参照側ソフトウェア部品９５に渡す。

この構成をとった場合には、データ参照要求が生じるたびにデータ変換を行わなければならず、特に、車両制御ソフトウェアのように、リアルタイム性が要求されるソフトウェアの場合には性能が低下してしまうという課題がある。

また、車両制御用ソフトウェアのように、複数の制御タスクや割り込みハンドラ、およびイベントタスクが混在するようソフトウェアの場合には、制御タスク内での変数の同時性が重要である。

変数の同時性が保たれない場合には、同じタイミング起動する処理であるにもかかわらず、タスクの前半と後半とで参照した値が異なり、制御ロジックの整合性を取ることが難しくなる。

図４に示すような構成では、参照要求ごとにデータの変換を行う。さらにデータを変換する際に用いる公開用データは、データ公開側ソフトウェア部品の動作タイミングで登録しているために、データ変換ソフトウェアの提供するインタフェースを利用した場合には、データ参照側では変数の同時性を保つことができないという課題がある。

図５は、本発明を実施した車両制御用ソフトウェアとしてエンジン制御用ソフトウェアを例とした構成例である。

図５に示す車両制御用ソフトウェアは、制御アプリケーション部分１０と、基本ソフトウェア部分２０と、フレームワーク３０とで構成されている。

制御アプリケーション部分１０は、第１の制御ソフトウェア部品（ＡＰ部品１：吸入空気量推定処理ソフトウェア部品）１１と、第２の制御ソフトウェア部品（ＡＰ部品２：燃料量・点火時期演算処理ソフトウェア部品）１２と、第３の制御ソフトウェア部品（ＡＰ部品３：故障診断処理ソフトウェア部品）１３と、制御アプリケーション部分と基本ソフトウェア部分との仲介をするためのＡＰ変数部１４とで構成されている。

基本ソフトウェア部分２０は、リアルタイムＯＳ（ＲＴＯＳ）２１と、燃料噴射機能や点火機能などを制御するアクチュエータ制御機能２２と、空気流量センサアクセル開度センサなどの計測値を処理するためのセンサ制御機能２３と、ＣＡＮやＬＩＮやＦｌｅｘＲａｙなどの通信機能を制御するための通信ドライバ２４と、デジタル入出力を行うためのデジタル入出力部２５と、アナログ入出力を行うためのアナログ入出力部２６と、ＥＣＵ５０への電源投入時の処理を行うリセット部２７とで構成されている。

フレームワーク３０は、割り込みハンドラやリアルタイムＯＳ２１によって起動されるタスク内でのソフトウェア部品実行フローを制御するためのタスクＦＷ３１と、基本ソフトウェア部分のソフトウェア部品の実行フローを制御するためのＩＯＦＷ３２と、データ変換処理の実行フローを制御するためのキャッシュＦＷ３３と、制御アプリケーション部分のソフトウェア部品実行フローを制御するためのアプリケーションＦＷ３４とで構成されている。

図５中の矢印は、機能間での呼び出し関係の一例を示しており、矢印の根元が呼び出し元であり、矢印の先が実行先である。

ＥＣＵ５０に電源が投入されると、まず、リセット部２７が実行され、リアルタイムＯＳ２１を起動する。リアルタイムＯＳ２１は、時間やマイクロプロセッサへの割り込みに応じてタスクを起動し、タスク内ではタスクＦＷ３１が実行される。タスクＦＷ３１は、ＩＯＦＷ３２、キャッシュＦＷ３３、アプリケーションＦＷ３４を実行する。

ＩＯＦＷ３２は、定義された制御フローに従って、アクチュエータ制御機能２２のソフトウェア部品や、センサ制御機能２３のソフトウェア部品や、通信ドライバ２４のソフトウェア部品を起動する。

アクチュエータ機能２２やセンサ制御機能２３のソフトウェア部品は、デジタル入出力２５やアナログ入出力２６や通信ドライバ２４のソフトウェア部品を利用して、アクチュエータやセンサの制御を行う。

キャッシュＦＷ３３は、定義された制御フローに従って、センサ制御２３のソフトウェア部品のインタフェースを利用してセンサ計測値を取得し、変数名および変数の単位を制御アプリケーション１０の要求しように合致するように変換し、ＡＰ変数（アプリケーション変数）としてＡＰ変数部１４に保存する。

また、制御アプリケーション側のソフトウェア部品（例えば、吸入空気量推定処理ソフトウェア部品１１、燃料量・点火時期演算処理ソフトウェア部品１２、故障診断処理ソフトウェア部品１３）が演算したアクチュエータ制御目標値は、ＡＰ変数としてＡＰ変数部１４に保存され、キャッシュＦＷ３３に適された制御フローにしたがって、データ形式が変換されてアクチュエータ制御機能２２のソフトウェア部品に渡される。

アプリケーションＦＷ３４は、定義された制御フローに従って、制御アプリケーションソフトウェア部品１１、１２、１３を起動する。制御アプリケーションソフトウェア部品１１、１２、１３をは、ＡＰ変数として変換されたセンサ計測値や他の制御アプリケーションソフトウェア部品が計算した値を用いて、制御変数を演算する。このとき、アクチュエータの制御目標値となる制御変数は、ＡＰ変数として扱われる。

図６は、ＡＰ変数部１４の内部構造の一例を示している。ＡＰ変数部１４は、ＡＰ変数ＱＡＶ１４１と、ＡＰ変数ＮＤＡＴＡＶ・Ａ１４２と、ＡＰ変数ＴＷＶ１４３と、燃料量ＦＩ１４４と、点火時期ＴＩ１４５と、故障診断結果ＥＲＲ・ＥＮＧ１４６と、ＡＰ変数ＮＤＡＴＡＶ・Ｂ１４７とで構成されている。

図７は、１０ｍｓ周期で起動されるタスク用の１０ｍｓ周期タスクＦＷ３１１のフローチャートである。

１０ｍｓ周期タスクＦＷ３１１は、１０ｍｓ周期ＩＯＦＷ（１）３２１を実行し、１０ｍｓ周期キャッシュＦＷ（１）３３１を実行し、１０ｍｓ周期アプリケーションＦＷ３４０を実行し、１０ｍｓ周期キャッシュＦＷ（２）３３２を実行し、１０ｍｓ周期ＩＯＦＷ（２）を実行する。

図８は、１０ｍｓ周期ＩＯＦＷ（１）３２１のフローチャートである。
１０ｍｓ周期ＩＯＦＷ（１）３２１は、ステップ３２１１にて空気流量センサのセンサ値入力および更新処理を行う。その後、ステップ３２１２にてエンジン回転数センサのセンサ値入力および更新処理を行う。さらに、ステップ３２１３にてエンジン温度センサのセンサ値入力および更新処理を行う。

図９は、１０ｍｓ周期キャッシュＦＷ（１）３３１のフローチャートである。
１０ｍｓ周期キャッシュＦＷ（１）３３１は、ステップ３３１１にて空気流量センサ値をセンサ制御機能２３のインタフェースを利用して取得し、変数名および変数単位を変換し、ＡＰ変数ＱＡＶ１４１として保存する。ステップ３３１２にてエンジン回転数センサ値をセンサ制御機能２３のインタフェースを利用して取得し、変数名および変数単位を変換し、ＡＰ変数ＮＤＡＴＡ・Ａ１４２として保存する。ステップ３３１３にてエンジン温度センサ値をセンサ制御機能２３のインタフェースを利用して取得し、変数名および変数単位を変換し、ＡＰ変数ＴＷＶ１４３として保存する。

図１０は、１０ｍｓ周期アプリケーションＦＷ３４０のフローチャートである。
ステップ３４０１にて吸入空気量推定処理ソフトウェア部品１１を実行し、ステップ３４０２にて燃料量・点火時期演算処理ソフトウェア部品１２を実行し、ステップ３４０３にて故障診断処理ソフトウェア部品１３を実行する。

図１１は、吸入空気量推定処理ソフトウェア部品１１による吸入空気量推定処理（ステップ３４０１）のフローチャートである。

ステップ３４０１１にてＡＰ変数ＱＡＶ１４１を取得し、ステップ３４０１２にてＡＰ変数ＮＤＡＴＡＶ・Ａ１４２を取得し、これらＡＰ変数に基づいてステップ３４０１３にて吸入空気量ＱＡを演算し、ステップ３４０１４にて変数ＱＡとして保存する。

図１２は、燃料量・点火時期演算処理ソフトウェア部品１２による燃料量・点火時期演算処理（ステップ３４０２）のフローチャートである。

ステップ３４０２１にてステップ３４０１４で保存された変数ＱＡを取得し、ステップ３４０２２にてＡＰ変数ＮＤＡＴＡＶ・Ａ１４２を取得し、これらの変数に基づいてステップ３４０２３にて燃料量ＦＩと点火時期ＴＩを演算し、これらをステップ３４０２４にてＡＰ変数燃料量ＦＩ１４４・点火時期ＴＩ１４５として保存する。

図１３は、故障診断処理ソフトウェア部品１３による故障診断処理（ステップ３４５０３）のフローチャートである。

ステップ３４０３１にてステップ３４０１４で保存された変数ＱＡを取得し、ステップ３４０３２にてＡＰ変数ＮＤＡＴＡＶ・Ａ１４２を取得し、ステップ３４０３３にてエンジンの動作状態を診断し、ステップ３４０３４にて診断結果をＡＰ変数故障診断結果ＥＲＲ・ＥＮＧ１４６として保存する。

図１４は、１０ｍｓ周期キャッシュＦＷ（２）３３２のフローチャートである。
１０ｍｓ周期キャッシュＦＷ（２）３３２は、ステップ３３２１にてＡＰ変数燃料量ＦＩ１４４をＡＰ変数のインタフェースを利用して取得し、変数単位を変換した後に、アクチュエータ制御機能２２のインタフェースを利用して燃料噴射量の制御目標値としてセットする。

ステップ３３２２にてＡＰ変数燃料量ＴＩ１４５をＡＰ変数のインタフェースを利用して取得し、変数単位を変換した後に、アクチュエータ制御機能２２のインタフェースを利用して点火次期の制御目標値としてセットする。

ステップ３３２３にてＡＰ変数故障診断結果ＥＲＲ・ＥＮＧ１４６をＡＰ変数のインタフェースを利用して取得し、変数単位を変換した後に、アクチュエータ制御機能２２のインタフェースを利用して計器盤上の警告ランプのＯＮ／ＯＦＦ状態としてセットする。

なお、この状態では目標値がセットされただけであり、実際のアクチュエータの制御に反映されるタイミングとは異なる。

このような構成をと取ることによって、排気低減用燃焼制御などを行う際に、制御に必要な制御目標値が揃ったのちに、一斉に制御に反映することが可能となる。また、制御目標値が更新されるタイミングと、実際に制御が行われるタイミングとが異なる場合にも対応できる。

図１５は、１０ｍｓ周期ＩＯＦＷ（２）３２２のフローチャートである。
ステップ３２２１にて、アクチュエータ制御機能２２のソフトウェア部品に対して警告ランプ出力の更新処理を要求する。

図１６は、エンジン回転同期割り込みハンドラまたはイベントタスクにて実行されるＩＯＦＷ３２３のフローチャートである。

ステップ３２３１にて、アクチュエータ制御機能２２のソフトウェア部品に対して燃料噴射実行処理を要求する。この時、アクチュエータ制御機能内部では、ステップ３３２１でセットした燃料噴射量に基づいて燃料噴射処理が行われる。ステップ３２３２にて、アクチュエータ制御機能２２のソフトウェア部品に対して点火用タイマの起動を要求する。この時、アクチュエータ制御機能内部では、ステップ３３２２でセットした点火時期に基づいてマイコンタイマのセットが行われる。実際に点火が行われるのは、タイマが起動したタイミングとなる。

図１７は、４０ｍｓ周期キャッシュＦＷ３３３のフローチャートである。
ステップ３３３１にてエンジン回転数センサ値をセンサ制御機能２３のインタフェースを利用して取得し、変数名および変数単位を変換し、ＡＰ変数ＮＤＡＴＡＶ・Ｂ１４７として保存する。こうすることにより、異なるタイミングで起動する１０ｍｓタスクと４０ｍｓ周期タスクとのそれぞれのタスクの内部で、制御アプリケーションとは異なるタイミングで更新されるセンサ入力値の同時性を保つことが可能となる。

図１８は、リセット部２７によるリセット処理（初期化処理）３５のフローチャートである。

ステップ３５１にて、基本ソフトウェア部分２０の初期化処理を行う。初期化処理は、アクチュエータ制御機能２２と、センサ制御機能２３と、通信ドライバ２４と、デジタル入出力部２５と、アナログ入出力部２６とがそれぞれ用意する初期化処理のインタフェースを利用することにより実行する。

ステップ３５２において、リアルタイムＯＳ（ＲＴＯＳ）２１の起動処理を行う。この際、時間周期タスクが起動される。しかし、その後ステップ３５３にて最高優先度で初期化タスクが実行されるため、時間周期タスクおよび割り込みハンドラ、イベントタスクはステップ３５３終了後に実行可能となる。

ステップ３５３では、初期化タスクＦＷが実行される。ここでは、図７の１０ｍｓ周期タスクと同様に、ＩＯＦＷ３２、キャッシュＦＷ３３、アプリケーションＦＷ３４が実行され、エンジン起動時のセンサ値の計測や、制御アプリケーションソフトウェア部品の初期化処理などが実行される。

本実施形態の効果を要約すると、以下の通りである。
（１）データ変換ソフトウェアの実行タイミングを、参照側ソフトウェア部品に呼び出されたタイミングではなく、別の実行タイミングを設けて起動要求を行うから、制御データの同時性を設計してデータ変換ソフトウェアの実装を行うことが出来るという効果がある。

（２）制御データ変換後は参照用データとして保存し、参照側プログラム実行タイミングでは変換後の参照用データを参照することにより、データ変換回数を必要最小限にすることが出来、処理性能向上につながる。

（３）データの受け渡しは、センサ値のような基本ソフトウェアから制御アプリケーションへの流れだけでなく、アクチュエータ値のような制御アプリケーションから基本ソフトウェアへの流れもあり、制御アプリケーションを開発する際は基本ソフトウェアのインタフェースを意識することなく制御データに目標値を代入しておけば、データ変換プログラムが所定のタイミングで基本ソフトウェア側で制御データを設定するようにでき、制御アプリケーションの再利用効率が向上する。

（４）公開側ソフトウェア部品と参照側ソフトウェア部品との間での制御データの受け渡しに際して変換されるデータ形式は、少なくとも変数名と変数単位とのいずれか一つであるから、制御アプリケーションの開発者は、基本ソフトウェアのインタフェースが用意する変数名や変数の単位、データアクセス用のインタフェースを意識せずに、制御アプリケーションを開発できるようになり、開発効率および再利用効率が向上する。

（５）データ変換ソフトウェアが起動要求されるタイミングは、参照用ソフトウェア部品が起動要求されるタイミングとは独立に設定できるから、データ変換処理のタイミングと、データを参照して行う処理との制御フローを分離できるようになり、ソフトウェアの開発効率・再利用効率が向上する。

（６）データ変換ソフトウェアが起動要求されるタイミングは、公開用ソフトウェア部品が起動要求されるタイミングとは独立に設定できるから、データ変換処理のタイミングと、データを計算して公開する処理との制御フローを分離できるようになり、ソフトウェアの開発効率・再利用効率が向上する。

（７）データ変換ソフトウェアが起動要求されるタイミングが、少なくとも時間周期か、割り込み信号のいずれかであるから、データ変換のタイミングを、データ毎の更新周期や、制御対象の状態変化に伴う割り込み信号とすることによって、適切なタイミングで変換処理が実行できるようになる。

（８）ソフトウェア部品か、車両制御用ソフトウェアが搭載されている電子車両制御装置とセンサとアクチュエータを制御するための基本ソフトウェア部品と、基本ソフトウェア部品を用いて制御対象の状態を制御するための制御アプリケーション部品とで構成されることにより、基本ソフトウェア部分と制御アプリケーション部分とに分割され、ソフトウェア部品間でデータの受け渡しを行う車両制御ソフトウェアにおいて、ソフトウェア実行効率とデータ同時性確保とを両立する車両制御ソフトウェアが実現できる。

（９）データ変換ソフトウェアによって制御データが変換されるのは、基本ソフトウェア部品と制御アプリケーション部品との間のデータの公開および参照の際であるから、基本ソフトウェア側ソフトウェア部品間や、制御アプリケーション側ソフトウェア部品間といったデータ変換を伴わないデータの受け渡しに際しては、データ変換プログラムの呼び出しが省略され、ソフトウェアの処理効率が向上する。

上記実施例では、データ公開側ソフトウェア部品とデータ参照側ソフトウェア部品を別個のものとしたが、一つの部品であるデータを公開するとともに別のデータを参照することも可能である。図１におけるデータ公開ソフトウェア部品１の持つ公開用データ７とデータ参照側ソフトウェア部品７，８，９の参照要求データを併せ持つソフトウェア部品において、各データが公開データであるか参照要求データであるかを明示した入出力インターフェイス仕様として明示することにより、データ変換ソフトウェアは公開データとして明示されたデータをその変換処理において参照用変数５Ａ，５Ｂからなるデータストレージ６の更新を図７〜図１８に記載の手順で行う。

また、上記実施例では図１中のデータストレージ６の具体的な実施例として、図５中ＡＰ変数１４を配置した制御アプリケーション部分１０の例を示したが、基本ソフトウェア部分２０、あるいはフレームワーク３０内に配置することも可能である。

このような配置にした場合には、アプリケーションソフトウェアはデータストレージの配置方法と独立に設計できるため、その設計に要する工数を削減できるため、アプリケーションソフトの変更が頻繁な場合に一層の工数削減効果がある。

以上、本発明のいくつかの実施形態について説明したが、本発明の実施形態は、様々な形をとることができる。例えば、車両制御システムは複数のＥＣＵで構成されている場合には、本発明が適用される車両制御ソフトウェアで変換されるセンサ計測値やアクチュエータ出力等は、一つのＥＣＵ内のセンサやアクチュエータにとどまらず、ネットワークを経由して参照可能な他のＥＣＵのセンサやアクチュエータでも良い。

本発明による車両制御ソフトウェアの一つの実施形態の概要を示すブロック図。 本発明の車両制御用ソフトウェアが適用されるエンジン向けの電子制御装置の一つの実施形態を示すブロック図。 本実施形態による車両制御ソフトウェアにおける制御アプリケーション部分と基本ソフトウェア部分との間のデータの受け渡しを示すブロック図。 従来技術のデータ変換ソフトウェアを示すブロック図。 本発明を実施した車両制御用ソフトウェアとしてエンジン制御用ソフトウェアを例とした構成例を示すブロック図。 本実施形態による車両制御ソフトウェアのＡＰ変数部の内部構造の一例を示すブロック図。 １０ｍｓ周期タスクＦＷのフローチャート。 １０ｍｓ周期ＩＯＦＷのフローチャート。 １０ｍｓ周期キャッシュのフローチャート。 １０ｍｓ周期アプリケーションＦＷのフローチャート。 吸入空気量推定処理ソフトウェア部品による吸入空気量推定処理のフローチャート。 燃料量・点火時期演算処理ソフトウェア部品による燃料量・点火時期演算処理のフローチャート。 故障診断処理ソフトウェア部品による故障診断処理のフローチャート。 １０ｍｓ周期キャッシュＦＷのフローチャート。 １０ｍｓ周期ＩＯＦＷのフローチャート。 エンジン回転同期割り込みハンドラまたはイベントタスクにて実行されるＩＯＦＷのフローチャート。 ４０ｍｓ周期キャッシュＦＷのフローチャート。 リセット処理部によるリセット処理のフローチャート。

符号の説明

１ データ公開側ソフトウェア部品
２ 公開用データ
３ データ変換ソフトウェア
４ データ対応部
５Ａ、５Ｂ 参照用データ
６ データストレージ
７、８、９ データ参照側ソフトウェア部品
５０ ＥＣＵ
１０ アプリケーション部分
１１ 第１の制御ソフトウェア部品（吸入空気量推定処理ソフトウェア部品）
１２ 第２の制御ソフトウェア部品（燃料量・点火時期演算処理ソフトウェア部品）１ １３ 第３の制御ソフトウェア部品（故障診断処理ソフトウェア部品）
１４ ＡＰ変数部
２０ 基本ソフトウェア部分
２１ リアルタイムＯＳ
２２ アクチュエータ制御機能
２３ センサ制御機能
２４ 通信ドライバ
２５ デジタル入出力部
２６ アナログ入出力部
２７ リセット部
３０ フレームワーク
３１ タスクＦＷ
３２ ＩＯＦＷ
３３ キャッシュＦＷ
３４ アプリケーションＦＷ
５０ ＥＣＵ

Claims (4)

1. マイクロコンピュータを用いて車両の制御を行う車両制御用装置の前記マイクロコンピュータに車両の制御動作を実行させるソフトウェアであって、
   車両を制御するための情報である制御データを公開する処理を前記マイクロコンピュータに実行させるソフトウェア部品である公開側ソフトウェア部品と、
   前記制御データを参照する処理を前記マイクロコンピュータに実行させるソフトウェア部品である複数の参照側ソフトウェア部品と、
   前記公開側ソフトウェア部品と前記参照側ソフトウェア部品との間での前記制御データの受け渡しに際してデータ形式を変換する処理を前記マイクロコンピュータに実行させ、前記車両制御用装置が有する記憶装置に、データ形式が変換された前記制御データを保持するデータ変換ソフトウェアと、
   を有し、
   前記公開側ソフトウェア部品は計測値公開ソフトウェア部品と制御目標値公開ソフトウェア部品とを備えており、
   前記計測値公開ソフトウェア部品は、複数のセンサにより出力される複数の計測データをそれぞれ検知してそれぞれを前記制御データとして公開する処理を前記マイクロコンピュータに実行させ、
   前記制御目標値公開ソフトウェア部品は、前記制御データとして公開された複数の前記計測データをそれぞれ参照し、該複数の計測データに基づいて複数の制御目標値をそれぞれ演算する処理を前記マイクロコンピュータに実行させ、
   複数の前記参照側ソフトウェア部品は、前記制御データとして公開された複数の前記制御目標値のそれぞれに基づき車両の制御を実行する複数の実行処理ソフトウェアを備えており、
   前記データ変換ソフトウェアは、前記マイクロコンピュータに、
   所定のタイミングで起動要求され、前記公開側ソフトウェア部品にデータ参照要求を行い、取得した前記制御データを起動要求されているタイミング毎に複数の参照側データに変換して前記参照側ソフトウェア部品へ提供するステップを実行することにより、前記データ変換ソフトウェアは、複数の前記計測データを前記制御目標公開ソフトウェア部品に参照させるために参照側データへの変換処理を前記マイクロコンピュータに実行させ、また複数の前記制御目標値データを前記実行処理ソフトウェアに参照させるために参照側データへの変換処理を前記マイクロコンピュータに実行させ、
   前記データ変換ソフトウェアは、
   前記参照側ソフトウェア部品が起動要求されるタイミングおよび前記公開側ソフトウェア部品が起動要求されるタイミングとは異なるタイミングで起動し、複数の前記計測データの参照側データへの変換を一の起動による処理中に前記マイクロコンピュータに実行させ、また複数の前記制御目標値の参照側データへの変換を一の起動による処理中に前記マイクロコンピュータに実行させ、
   前記車両用制御装置の記憶装置は、参照側データに変換された複数の前記計測データと複数の前記制御目標値をそれぞれ前記制御データとして記憶している
   ことを特徴とする車両制御用ソフトウェア。
2. 前記公開側ソフトウェア部品と前記参照側ソフトウェア部品との間での前記制御データの受け渡しに際して変換される前記データ形式とは、少なくとも変数名と変数単位とのいずれか一つであることを特徴とする請求項１に記載の車両制御用ソフトウェア。
3. 前記データ変換ソフトウェアを、少なくとも時間周期か、割り込み信号かのいずれかで起動要求するステップを、前記マイクロコンピュータに実行させる
   ことを特徴とする請求項１に記載の車両制御用ソフトウェア。
4. マイクロコンピュータを用いて車両の制御を行う車両制御用装置において、請求項１〜３のいずれか１項に記載のソフトウェアを搭載することを特徴とする車両制御用装置。

Images