JP4515701B2 - 車両用制御プログラム、及び、車両用制御装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
車両用制御プログラム、例えばエンジン制御用組込ソフトウェアとして好適な構成をもつプログラム等に関する。
【０００２】
【従来の技術】
従来より、例えばマイコン等のコンピュータを用いて、自動車等の車両の各部を制御する車両用制御装置が知られている。こうした車両用制御装置では、ＲＯＭ等の記憶装置に記憶された車両用制御プログラムをコンピュータが実行することにより、種々の制御を実現している。
【０００３】
車両用制御プログラムは、一般的に、ハードウェアに依存するプログラムであるプラットフォームプログラム（ＰＦ）と、車両用の制御に依存するプログラムであるアプリケーションプログラム（ＡＰ）とに分けて構成する。
プラットフォームプログラムは、ハードウェアデバイスからデータを入力して、その入力したデータに基づくデータを、例えばＡＰＩ（Application Program Interface）のようなインターフェース（以下このインターフェースをＰＦインターフェースと称する）を介して、アプリケーションプログラムによる処理に対して提供したり、アプリケーションプログラムによる処理からこのＰＦインターフェースを介して得たデータをハードウェアデバイスに対して出力したりする処理をコンピュータに実行させるためのプログラムである。
【０００４】
一方、アプリケーションプログラムは、このＰＦインターフェースを介して入力したデータを用いた処理や、ＰＦインターフェースを介して出力するデータを生成する処理をコンピュータに実行させるためのプログラムである。例えばＰＦインターフェースを介して入力したデータに基づいてＰＦインターフェースを介して出力するデータを生成する処理をコンピュータに実行させるためのプログラムである。
【０００５】
このように、プラットフォームプログラムは、ハードウェアデバイスに対するアクセスを行うプログラムを含む一方、アプリケーションプログラムは、直接ハードウェアデバイスへのアクセスを行うプログラムを含まず、ＰＦインターフェースを介して、プラットフォームプログラムによる処理にハードウェアデバイスとの入出力をさせている。こうすることで、アプリケーションプログラムの開発者は、ハードウェアの詳細構成や制御方法を意識することなくアプリケーションプログラムを作成することができる。
【０００６】
また、従来、例えば、特許文献１に示すように、オペレーティングシステムとアプリケーションソフトとを接続するインターフェースソフトを設け、アプリケーションソフトにおいて必要な信号の演算をインターフェースソフトで行うようにすることで、ハードウェアに変更があった場合にインターフェースソフトを書き換えるだけで「アプリケーションソフトを」永続的に使用可能にした自動車用制御ユニットも知られている。
【０００７】
【特許文献１】
特開平０７−０４０７９４号公報
【０００８】
【発明が解決しようとする課題】
しかしながら、車両用制御装置のメーカでは、顧客である車両メーカから異なる要求仕様を持つ複数の車両用制御装置の開発を依頼されることが多く、アプリケーションプログラムはそれぞれの要求仕様に応じて新規に作成する必要がある。したがって、上述した特許文献１に記載のように「アプリケーションプログラムソフトを」流用して車両用制御プログラムを作成するのではなく、プラットフォームプログラムを、できるだけ流用して、車両用制御プログラムを構成することにより、開発コストを削減する手法が採られる。
【０００９】
プラットフォームプログラムを流用するためには、例えば、異なる要求仕様間の共通項を抽出し、その共通項で標準化したＰＦインターフェースを提供するようにプラットフォームプログラムを構成する。例えば各要求仕様の中で、最も要求の厳しい要求仕様に合わせたデータ型式やデータ提供タイミング等でデータをアプリケーションプログラムによる処理へ提供するようにＰＦインターフェースの仕様であるＰＦインターフェース仕様を標準化する。
【００１０】
例えば車両用制御装置がエンジン制御装置であって、エンジンの冷却水の水温を検出するための水温センサからの電圧値に基づく処理を行う場合の要求仕様として、ある車種のエンジン制御装置Ａでは、この電圧値の分解能として1/256Vが要求仕様であるのに対し、別の車種のエンジン制御装置Ｂでは分解能として1/128Vが要求仕様とされている場合を考える。このような場合には、プラットフォームプログラムによる処理では両方の車種のエンジン制御装置の要求仕様を共に満たすように分解能の細かいエンジン制御装置Ａに合わせた分解能1/256Vで、アプリケーションプログラムによる処理に対してＰＦインターフェースを提供するＰＦインターフェース仕様を策定し、このＰＦインターフェース仕様に沿ったＰＦインターフェースを提供するようにプラットフォームプログラムを構成する。こうして、異なる要求仕様を持つエンジン制御装置で同一のプラットフォームプログラムを流用することができる。
【００１１】
しかしながら、エンジン制御装置Ｂのアプリケーションプログラムを作成する場合、要求仕様の分解能は1/128Vであるのに対し、プラットフォームプログラムによるＰＦインターフェースが提供する分解能は1/256Vであるため、アプリケーションプログラムの開発者は、プラットフォームプログラムによるＰＦインターフェース仕様の分解能と、開発対象の車両用制御装置の要求仕様の分解能とのギャップを埋めるための分解能変換処理プログラムをアプリケーションプログラムに組み込む必要がある。
【００１２】
こうした要求仕様としては、分解能の他にも、データの種類、データの型、データの取り込みタイミング等、様々なものがあり、異なる要求仕様を持つ車両用制御装置において標準化されたプラットフォームプログラムを利用するアプリケーションプログラムを作成する場合、アプリケーションプログラムの開発者は、常にプラットフォームプログラムの提供するＰＦインターフェース仕様を念頭において要求仕様を実現する方法を考える必要があり、アプリケーションプログラムの開発者の負担が大きいといった問題がある。
【００１３】
そこで本発明は、アプリケーションプログラムの開発者の負担を軽減することのできる車両用制御プログラム等を提供することを目的とする。
【００１４】
【課題を解決するための手段及び発明の効果】
上述した問題点を解決するためになされた請求項１に記載の車両用制御プログラムは、プラットフォームプログラムと、アプリケーションプログラムと、結合処理プログラムとから構成されている。
【００１５】
プラットフォームプログラムは、所定の時間間隔で起動し、ハードウェアデバイスからデータを入力して、当該データをプラットフォームプログラム管理下のメモリに記憶する処理、をコンピュータに実行させるためのプログラムである。
【００１６】
また、結合処理プログラムは、プラットフォームプログラムとアプリケーションプログラムとの間のデータ授受を仲介する処理を、コンピュータに実行させるためのプログラムであり、具体的には、要求仕様における更新周期に基づきプラットフォームプログラムの上記時間間隔とは異なる時間間隔で起動し、プラットフォームプログラム管理下のメモリに記憶されたデータを入力して、当該データを結合処理プログラム管理下のメモリに記憶する処理、をコンピュータに実行させるためのプログラムである。
【００１７】
そして、アプリケーションプログラムは、要求仕様による利用周期に基づく、プラットフォームプログラムの上記時間間隔とは異なる時間間隔で、結合処理プログラム管理下のメモリに記憶されたデータを入力し、当該データに基づき制御演算を行う処理、をコンピュータに実行させるためのプログラムである。
このように、本発明では、結合処理プログラムが、プラットフォームプログラムとアプリケーションプログラムとの間のデータの橋渡しを行うため、アプリケーションプログラムの開発者は、ＡＰインターフェース仕様、すなわち、開発対象の車両用制御装置の要求仕様を満たすインターフェース仕様に沿ってアプリケーションプログラムを作成することができる。すなわち、アプリケーションプログラムの開発者は、ＰＦインターフェース仕様を念頭において要求仕様を実現する方法を考える必要はなくなるので、アプリケーションプログラムの開発者の負担を軽減することができる。
【００１８】
具体的に、アプリケーションプログラムの開発者は、アプリケーションプログラムの作成時に、プラットフォームプログラムによるサンプリングタイミングがどのようになっているのかを意識することなく、要求仕様に従ったタイミングでデータを利用するように構成することができる。
【００１９】
例えば、上記車両用制御プログラムでは、プラットフォームプログラムにより実現されるデータ入力の時間間隔を、結合処理プログラムにより実現されるデータ入力の時間間隔、及び、アプリケーションプログラムにより実現されるデータ入力の時間間隔、よりも短い時間間隔に設定することができる（請求項２）。
【００２０】
また、結合処理プログラムは、結合処理プログラム管理下のメモリにデータを記憶するに際し、データを、アプリケーションプログラムの要求仕様を満たすデータ形式に変換し、当該変換後のデータを、結合処理プログラム管理下のメモリに記憶する処理を、コンピュータに実行させるための命令コードを含むプログラムとして構成されてもよい（請求項３）。
異なる要求仕様に従って作成されたアプリケーションプログラムは、異なるデータ構造を持つデータを必要とする場合があるが、上記のように車両用制御プログラムを構成すれば、アプリケーションプログラムの作成時にＰＦインターフェースにおけるデータがどのような精度やデータ型式となっているのかを意識しなくても、要求仕様に従ったデータを利用することができる。
【００２６】
この他、結合処理プログラムは、入力あるいは出力のいずれかのみについて仲介を行うように構成してもよいが、入力と出力の双方を仲介するようにするとよい。例えば、請求項４に示すように、請求項１〜３のいずれかに記載の車両用プログラムを備える車両用制御プログラムとするとよい。このようにすれば、アプリケーションプログラムの開発者は、入出力の双方について、プラットフォームプログラムによる処理によって提供されるＰＦインターフェースの仕様を意識することなく、単に要求仕様に従ってアプリケーションプログラムを作成することができる。
【００２７】
また、請求項５に示すように、請求項１〜４のいずれかに記載の車両用制御プログラムと、この車両用制御プログラムを実行するコンピュータとを備えた車両用制御装置を構成することができる。このような車両用制御装置は、アプリケーションの開発を効率的に行うことができるため、従来より、低コストでの開発が容易にできるようになる。
【００３０】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００３１】
本実施例の車両用制御装置は、エンジンの制御を行うためのエンジンＥＣＵであり、図１に本実施例の説明に必要な部分についての構成を図示している。本実施例のエンジンＥＣＵ１０と従来のエンジンＥＣＵとの差異は、ＲＯＭ１２に記憶されたプログラムの構成にあり、その他の構成は従来のエンジンＥＣＵと同様である。
【００３２】
エンジンＥＣＵ１０は、図１に示すように、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，Ｉ／Ｏ１４、Ａ／Ｄ変換器１５、タイマ１６等とこれらを接続するバスライン等から構成されている。そして、Ｉ／Ｏ１４やＡ／Ｄ変換器１５には、エンジン回転センサ２１、Ｏ２センサヒータ２２、水温センサ２３、…、といった各種のエンジン制御用装置２０が駆動回路等を介して接続されている。そして、ＲＯＭ１２に記憶されたプログラムをＣＰＵ１１が実行することによって、こうしたエンジン制御用装置２０からの信号の入力や、エンジン制御用装置２０に対する信号の出力を行う。例えば、ＣＰＵ１１による処理によって、エンジン回転センサ２１からのクランク軸の所定回転角毎（例えば１８０度毎）に発生するパルスをＩ／Ｏ１４から入力したり、Ｉ／Ｏ１４に対してＯ２センサを所定の動作温度まで加熱するためのＯ２センサヒータ２２をＰＷＭ制御するＯ２センサヒータ制御信号を出力したりする。また、Ａ／Ｄ変換器１５を介して、水温センサ２３から水温に対応する電圧値を入力し、入力した電圧値をデジタルデータとしてＲＡＭ１３等へ取り込む。
【００３３】
こうした制御をＣＰＵ１１に実行させるためにＲＯＭ１２に記憶するプログラム１は、図２（ａ）に示すように、プラットフォームプログラム２（図中ＰＦで表記している）と、特許請求の範囲における結合処理プログラムに相当する結合処理部３と、アプリケーションプログラム４（図中ＡＰで表記している）とをリンクして構成している。
【００３４】
プラットフォームプログラム２は、Ｉ／Ｏ１４やＡ／Ｄ変換器１５等のハードウェアデバイスを制御する処理（ハードウェアに依存する処理）をＣＰＵ１１が実行するためのデバイスドライバを含むプログラムであり、一方アプリケーション４は、Ｉ／Ｏ１４やＡ／Ｄ変換器１５といったハードウェアデバイスを直接制御する処理を行わず、車両メーカからの要求仕様を実現するための処理（車両用の制御に依存する処理（判定処理、演算処理など））をＣＰＵ１１が実行するためのプログラムである。そして、結合処理部３は、アプリケーションプログラム４によるＣＰＵ１１の処理とプラットフォームプログラム２におけるＣＰＵ１１の処理との仲介を行うための処理をＣＰＵ１１が実行するためのプログラムである。
【００３５】
プラットフォームプログラム２と結合処理部３とアプリケーションプログラム４は別々に開発が行われており、プラットフォームプログラム２は、すでに開発済みの従来のエンジンＥＣＵに用いられていたものを利用する。一方、結合処理部３とアプリケーションプログラム４は新規に開発する。
【００３６】
プラットフォームプログラム２は、図２（ｂ）に示すように、結合処理部３による処理からのＩ／Ｏ１４やＡ／Ｄ変換器１５の駆動要求を受け付けてＩ／Ｏ１４やＡ／Ｄ変換器１５を駆動し、また、Ｉ／Ｏ１４やＡ／Ｄ変換器１５から取得した情報を結合処理部３による処理から参照可能とする処理を行うことによって、結合処理部３の処理に対するインターフェースを提供する（ＰＦインターフェースと称する）。このＰＦインターフェースは、すでに開発済みの従来の車種のエンジンＥＣＵの要求仕様を満足するように標準化して構成されている。
【００３７】
また、結合処理部３は、ＰＦインターフェースを介して取得した情報を開発対象のアプリケーションプログラム４の要求仕様を満足する情報に変換してアプリケーションプログラム４の処理から参照可能とする処理と、アプリケーションプログラム４による処理によって生成された要求仕様に従った出力対象の情報を参照してＰＦインターフェースの要求する情報に変換してＰＦインターフェースを介してＩ／Ｏ１４へ出力させる処理をＣＰＵ１１に行わせるプログラムである。
【００３８】
こうした結合処理部３を設けることによって、アプリケーションプログラム４の開発者は、ＰＦインターフェースの仕様を意識することなく、要求仕様のみを考慮してアプリケーションプログラムを開発することができる。この要求仕様には、入出力するデータのタイミングやデータ型式等のＡＰインターフェースに関する仕様と、ＡＰインターフェースを介して取得したデータを利用した車両用の制御仕様とが含まれる。制御仕様については、アプリケーションプログラム２の開発中であってもたびたび車両メーカ側からの変更の要求があるのに対し、ＡＰインターフェースに関する仕様については、開発の初期段階でほぼフィックスされている。したがって開発の初期段階でＡＰインターフェースの仕様は決定することができ、また、ＰＦインターフェースの仕様はすでに標準化されているものを流用するため、開発の初期段階から結合処理部３の開発を進めることができる。一方、アプリケーションプログラム２については、開発の初期段階から要求仕様のみを意識して開発を進めることができ、開発中に制御仕様の変更があったとしても、ＡＰインターフェースは変更する必要がなく、制御仕様に従って制御部分の変更を行うだけで済む。
【００３９】
こうした結合処理部３を備えたプログラム１の詳細な構成の例を図に示して説明する。
例えば、図３（ａ）に示すように、ＰＦインターフェースによってunsigned short型でＬＳＢの示す値が５／６５５３６［Ｖ］のデータ型式でデータが提供されるよう標準化されている一方、要求仕様のデータ型式がunsigned char型でＬＳＢの示す値が５／２５６［Ｖ］の場合について説明する。
【００４０】
この場合、図３（ｂ）に示すように、結合処理部３は、プラットフォームプログラム２による処理から受けとったデータのデータ型及びＬＳＢの対応する値についての変換処理をＣＰＵ１１に実行させるように構成する。
すなわち、結合処理部３は、ＰＦインターフェースを介してunsigned short型でＬＳＢの示す値が５／６５５３６［Ｖ］のデータを取得し、取得したデータをunsigned char型でＬＳＢの示す値が５／２５６［Ｖ］のデータに変換（加工）する変換処理を行い、変換したデータをアプリケーションプログラム４による処理から参照可能にする処理をＣＰＵ１１が実行するための命令コードを備える。例えば結合処理部３による処理では、変換したデータを予め定めたアドレスのＲＡＭ１３に格納しておき、アプリケーションプログラム４による処理では、このアドレスのＲＡＭ１３の値を取得するようにして、ＡＰインターフェースを構成し、アプリケーションプログラム４による処理による要求仕様に沿ったデータの参照を行うことができる。
【００４１】
従来の車両用制御プログラムの構成では、図４に示すように、プラットフォームプログラム２による処理によって提供されるunsigned short型でＬＳＢの示す値が５／６５５３６［Ｖ］のデータ型式のデータをアプリケーションプログラムによる処理で取得して、アプリケーションプログラムによる処理で、要求仕様を満たすデータ型式であるunsigned char型のＬＳＢの示す値が５／２５６［Ｖ］のデータに変換する変換処理を行う必要があった。したがって、このような変換処理をアプリケーションプログラム内で行う必要があり、アプリケーションプログラムの開発者は、この点を常に意識しながらアプリケーションプログラムを開発する必要があるため、アプリケーションプログラムの開発者の負担が大きかった。しかし、上述した結合処理部３を備えることにより、アプリケーションプログラム４の開発者は、ＰＦインターフェースのデータ型式を意識することなく、単に要求仕様のみを考慮してアプリケーションプログラム４の開発を行うことができる。
【００４２】
次に、結合処理部３による処理で、データの取得タイミングを調整する例を示す。
図５（ａ）に示すように、プラットフォームプログラム２による処理で提供されるＰＦインターフェースは、結合処理部３による処理から参照可能なデータを１ｍｓ毎に更新する構成で標準化されており、一方、要求仕様としては、８ｍｓ毎に利用する仕様である。但し、この８ｍｓ毎に利用するデータは、１６ｍｓ毎に取り込んだデータとする。
【００４３】
この場合、図５（ｂ）に示すように、プラットフォームプログラム２は、１ｍｓ毎に水温センサ２３の電圧値をＡ／Ｄ変換器１５を介してプラットフォームプログラム２の管理下のＲＡＭ１３に取り込む処理をＣＰＵ１１に実行させるための命令コードを備える。またプラットフォームプログラム２は、結合処理部３による処理からの要求に応じてプラットフォームプログラム２による管理下のＲＡＭ１３に取り込んだ電圧値を結合処理部３による処理へ渡す処理をＣＰＵ１１に実行させるための命令コードを備える。
【００４４】
そして、結合処理部３は、１６ｍｓ毎にプラットフォームプログラム２による処理に対して電圧値を要求して、プラットフォームプログラム２による処理における管理下のメモリに取り込まれた電圧値を受け取り、結合処理部３の処理による管理下のメモリに記憶する処理をＣＰＵ１１に実行させるための命令コードを備える。また、アプリケーションプログラム４による処理からの要求に応じて、この結合処理部３による処理の管理下のメモリに記憶された電圧値をアプリケーションプログラム４による処理へ渡す処理を行うための命令コードを備えることで、ＡＰインターフェースを提供する。
【００４５】
そして、アプリケーションプログラム４は、８ｍｓ毎に結合処理部３に対して電圧値を要求し、結合処理部３による処理から電圧値を受け取って、利用する処理を行う命令コードを備える。
なお、アプリケーションプログラム４による処理からこの結合処理部３による処理の管理下のメモリを直接参照して取得するＡＰインターフェースとしてもよい。
【００４６】
また、プラットフォームプログラム２には、結合処理部３を１６ｍｓ以内の間隔で実行し、アプリケーション４を８ｍｓ以内の間隔で実行するための命令コードを備える。
こうした車両用制御プログラム１をＣＰＵ１１が実行すると、図５（ｂ）に示すように、結合処理部３による処理で、１６ｍｓ毎に電圧値をＰＦインターフェースを介して取得して記憶しておき、アプリケーションプログラム４の処理によって８ｍｓ毎に、この記憶している電圧値を利用する。
【００４７】
このように、結合処理部３を設けることで、アプリケーションプログラム４は、要求仕様を満足する１６ｍｓ毎にサンプリングされた電圧値を、８ｍｓ毎に利用することができる。すなわち、アプリケーションの開発者は、図６に示す従来例のようにアプリケーションプログラムによる処理内でサンプリングタイミング変換しなければならないことを意識する必要はなく、アプリケーションプログラム４を開発することができる。
【００４８】
次に、割り込み処理に適用した例を説明する。図７に示すように、エンジン回転センサ２１からの信号パルスの立ち下がりで、ＣＰＵ１１にＩ／Ｏ１４から割り込みがかかり、ＣＰＵ１１はプラットフォームプログラム２に備えた割り込み処理ルーチンを実行する。このプラットフォームプログラム２の割り込み処理ルーチンは、この割り込み処理ルーチンの前回の実行時からの経過時間をタイマ１６の値を取得して算出し、これに基づいてエンジン回転数を求めて、プラットフォームプログラム２の管理下のＲＡＭ１３のメモリ領域へ記憶する処理を行うためのＣＰＵ１１の命令コードを備える。また、プラットフォームプログラム２は、結合処理部３による処理からの要求に応じてこのプラットフォームプログラム２の管理下のＲＡＭ１３のメモリ領域へ記憶された回転数を結合処理部３による処理に渡す処理を行うためのＣＰＵ１１の命令コードを備える。そして、プラットフォームプログラム２は、結合処理部３のタスク（特許請求の範囲における取得プログラムに相当する）を起動する命令コードを備え、この命令コードをＣＰＵ１１が実行することで、結合処理部３のタスクが起動される。
【００４９】
このタスクは、プラットフォームプログラム２の処理に回転数を要求するための命令コードと、プラットフォームプログラム２による処理から受け取った回転数を結合処理部３の管理下のＲＡＭ１３のメモリ領域へ記憶する処理を行うための命令コードと、アプリケーションプログラム４による処理から回転数の要求があった場合に、この結合処理部３の管理下のＲＡＭ１３のメモリ領域へ記憶された回転数をアプリケーションプログラム４による処理へ渡す処理を行うための命令コードとを備える。
【００５０】
そして、エンジン回転数を利用して要求仕様を満たす機能を実現させるためのプログラムであるアプリケーションプログラム４の回転数利用処理部は、エンジン回転数を参照する各部で、結合処理部３による処理に対して回転数を要求するための命令コードを備える。
【００５１】
そして、割り込み処理部の実行レベルは他のプログラム部分よりレベルを高く設定し、結合処理部３の実行レベルはアプリケーションプログラム４の実行レベルと同一かそれ以下に設定する命令コードをプラットフォームプログラム２に備える。そして、ＣＰＵ１１は、事前にこの実行レベルの設定をするプログラムの命令コードを実行しておく。また、プラットフォームプログラム２には、実行レベルに応じて実行すべきタスクを決定する処理を行う命令コードを備える。
【００５２】
このような構成によれば、図７に示すように、エンジン回転センサ信号のパルスの立ち下がりで、ＣＰＵ１１がプラットフォームプログラム２の割り込み処理ルーチンを実行し、エンジン回転数を求めて、プラットフォームプログラム２の管理下のＲＡＭ１３のメモリ領域へ記憶する。そして、プラットフォームプログラム２による処理によって、アプリケーションプログラム４が実行中でない場合には、図７に示す割り込み処理Ｐ１の後のように、結合処理部３のタスク処理部Ｃ１が実行されてプラットフォームプログラムによる処理に対して回転数を要求し、プラットフォームプログラムによる処理では結合処理部３による処理に対して回転数を渡す。結合処理部３のタスク処理部Ｃ１の処理により回転数を受け取り、結合処理部３の管理下のＲＡＭ１３のメモリ領域へ記憶する。そしてプラットフォームプログラム２は、アプリケーションＡ１を実行する。
【００５３】
アプリケーションＡ１において、回転数を参照する場合には、結合処理部３による処理に回転数を要求する。結合処理部３による処理では、結合処理部３の管理下のＲＡＭ１３のメモリ領域へ記憶された回転数を渡す。そして、アプリケーションプログラム４の処理では、この回転数を受け取って自動車用の制御処理に利用する。
【００５４】
また、図７に示すように、アプリケーションＡ２の処理中に、エンジン回転センサ信号による割り込みが発生し、プラットフォームプログラム２の割り込み処理Ｐ３が実行される場合、割り込み処理Ｐ３の完了後、プラットフォームプログラム２によって結合処理部Ｃ３が起動されるのであるが、結合処理部Ｃ３の実行レベルは、アプリケーションＡ２の実行レベルと同一かそれ以下に設定されているため、プラットフォームプログラム２による処理では、結合処理部Ｃ３の実行を後回しにして、先に、アプリケーションＡ２の割り込みによる中断時点からの命令を実行する。そのため、アプリケーションＡ２では、途中で割り込み処理Ｐ３を行っているが、回転数を参照する場合には、結合処理部Ｃ２の管理下のＲＡＭ１３のメモリ領域へ記憶された回転数を取得して処理に利用することとなる。
【００５５】
このように、アプリケーションプログラム２による処理で結合処理部３による処理を介して回転数を取得するようにプログラムを構成することで、アプリケーションプログラム４の開発者は、プラットフォームプログラム２の仕様を意識することなく、単に結合処理部３とのやりとりを行うＡＰインターフェースの仕様を知るだけでアプリケーションプログラム４を開発することができる。
【００５６】
すなわち、従来は、上述した結合処理部３が存在しないため、図８（ａ）のようにアプリケーションＡ１の処理中で、回転数の参照を行うと、プラットフォームの割り込み処理Ｐ１でメモリに記憶された回転数がプラットフォームから提供されていた。この場合、アプリケーションＡ１中で複数回のプラットフォームの回転数を参照したとしても、アプリケーションＡ１中では、得られる回転数は全て同じ値となり、問題は生じない。しかし、割り込み処理Ｐ２の後にアプリケーション処理Ａ２が実行され、このアプリケーションＡ２中に、エンジン回転センサ信号による割り込みが発生した場合、アプリケーションＡ２の処理は中断され、プラットフォームプログラム２による割り込み処理Ｐ３が実行される。そして、割り込み処理Ｐ３の完了後にアプリケーション処理Ａ２が再開される。この結果、割り込み処理Ｐ３中で回転数は新たな値に更新されるので、中断前のアプリケーション処理Ａ２の部分では、プラットフォームから取得した割り込み処理Ｐ２による回転数を用いた処理がなされ、割り込み処理Ｐ３から復帰した後のアプリケーション処理Ａ２の部分では、プラットフォームから取得した割り込み処理Ｐ３による回転数を用いた処理がなされることとなる。このように、１単位のアプリケーション処理内で、ハードウェアデバイスからのデータに基づくデータに関して一貫性が保持できない。そのため、従来は、アプリケーションの開発者は、こうしたプラットフォームの制約条件を理解し、例えば図８（ｂ）に示すように、割り込みの影響を受けないように、アプリケーション処理の先頭でディスパッチ禁止処理を行い、プラットフォームのＡＰＩを呼び出して回転数を取り込んで、自己の管理下のメモリに記憶する（グローバルコピーすると称する）処理を行い、そして、それ以降のアプリケーション処理では、このグローバルコピーされた回転数を用いて処理を行うようにする必要があった。このように、アプリケーションプログラムの開発者は、プラットフォームの仕様（制約条件）を熟知し、仕様間のギャップを埋めて、アプリケーションプログラムを作成しなければならない。もしも、こうしたプラットフォームの仕様をアプリケーション作成者がよく理解せずに作成すると、例えば図８（ａ）のように、ときどき動作がおかしくなるといった症状などが生じ、作成したアプリケーションプログラムが、アプリケーション作成者の意図通りに動かない。このような場合、アプリケーションの開発者はプラットフォームの仕様を理解していないため、動作異常の原因を特定するのは困難になってしまう。かといって、複数のアプリケーション（例えばタスク）を動作させる場合、すべてのアプリケーションについてグローバルコピーを行うとメモリ領域の消費や処理時間の消費などオーバーヘッドが大きくなる。そのため、どのアプリケーションが、処理内でのデータの一貫性（同時性）を保てないのかを、プラットフォームの仕様とアプリケーションの仕様とを照らし合わせて判断する必要があり、アプリケーションの開発者の負担が大きく、開発効率を高める上での障害となっていた。
【００５７】
しかし、図７に示して説明した本実施例の構成にすれば、図８（ｂ）に示すようなグローバルコピーをアプリケーションプログラム中で行う必要もなくなり、どのアプリケーションプログラムについてグロバールコピーをする必要があるのかなどを検討する必要もなくなる。したがって、アプリケーションの生産性を向上させることができる。
【００５８】
以上、アプリケーションプログラムによる処理でデータを入力する場合について説明したが、アプリケーションプログラムによる処理で、データを出力する場合にも、従来のように、直接プラットフォームプログラムの提供するインターフェースにアクセスするのではなく、結合処理部３を介して処理を行うとよい。
【００５９】
例えば、図９（ａ）に示すように、アプリケーションプログラム４は、条件判定処理と、演算処理をＣＰＵ１１が実行するための命令コードを備える。そして、結合処理部３は、プラットフォームプログラム２による処理によって、例えば所定周期毎に実行される。
【００６０】
そして、結合処理部３には、アプリケーションプログラム２による演算処理によって得られたデータを取得する情報取得処理と、情報取得処理によって取得したデータをプラットフォームプログラム２による負荷駆動処理で用いるデータ型式に変換する情報変換処理と、プラットフォームプログラム２による負荷駆動処理を実行させるための負荷駆動要求処理とをＣＰＵ１１が実行するための命令コードを備える。また、プラットフォームプログラム２は、負荷駆動要求があった場合に、負荷駆動処理を行う。
【００６１】
例えば、図９（ｂ）に示すように、エンジンを始動して所定時間経過後、エンジン始動時の水温に応じてＯ２センサヒータ２２の制御を行い、要求仕様として周期２５６ｍｓでＤｕｔｙ制御するものであるとする。
この場合、プラットフォームプログラムでは、図９（ｂ）に示すように、Ｏ２センサヒータ２２を駆動するプラットフォームのＡＰＩをＯ２Ｈ＿ＤｕｔｙＯｕｔ（周期，Ｄｕｔｙ）とし、周期のデータ型は、unsigned shortでＬＳＢの対応する値は１ｍｓとし、Ｄｕｔｙのデータ型はsigned longでＬＳＢの対応する値は１／６５５３６とする。Ｄｕｔｙのデータ範囲は０〜１として、それ以外は動作を保証しない。
【００６２】
一方、要求仕様は、アプリケーションプログラム４の演算処理によって出力するＤｕｔｙがfloat型であり、範囲が０〜１００％で、システムの要求する周期２５６ｍｓでＤｕｔｙ制御であるとする。
このとき、従来は、アプリケーションプログラムでは、図１１及び図１２に示すように、アプリケーション内の演算処理で出力されたfloat型のＤｕｔｙを、プラットフォームが指定する型およびＬＳＢの対応する値に変換処理して、プラットフォームのＡＰＩを呼び出すように構成する必要があった。
【００６３】
具体的には、アプリケーションプログラムとプラットフォームプログラムとはそれぞれ図１２に示すように、処理を行っていた。すなわち、アプリケーションプログラムは、図１２に示すように条件判定処理、演算処理、負荷駆動要求処理を行い、プラットフォームは、負荷駆動処理を行う。
【００６４】
アプリケーションプログラムでは、Ｓ１１０で、エンジン始動後所定時間経過したか否かを判定し、所定時間経過した場合には（Ｓ１１０：成立）、Ｓ１２０へ移行して、所定の処理（始動時水温補間テーブルによる補間）によってＤｕｔｙ＿ＡＰを求める。一方、エンジン始動後所定時間経過していない場合には（Ｓ１１０：不成立）、ヒータ制御は不要であるので、Ｓ１３０へ移行して、Ｄｕｔｙ＿ＡＰを０％にする。
【００６５】
そしてＳ１４０では、Ｄｕｔｙ＿ＡＰを、プラットフォームのＡＰＩ（プラットフォーム命令）の引数として用いられる型とＬＳＢの示す値に変換してＤｕｔｙ＿ＰＦとして求める。すなわち、変換後のＬＳＢの示す値が１／６５５３６となるようにfloat型からsigned long型への変換を行う。続くＳ１５０では、Ｄｕｔｙ＿ＰＦをプラットフォームの仕様に従って０〜１でガードする。そして、Ｓ１６０で、周期を２５６（ｍｓ）、ＤｕｔｙをＤｕｔｙ＿ＰＦとしてプラットフォーム命令Ｏ２Ｈ＿Ｄｕｔｙを呼び出す。このようにアプリケーションの開発者は、プラットフォームの制約条件を意識して、アプリケーション内に変換処理を設ける必要がある。
【００６６】
プラットフォーム側では、この呼び出しに応じて、呼び出し時にセットされた値（引数）に基づき、実際にハードウェアを制御し、ヒーター制御を行う（Ｓ２００）。
このように、プラットフォームプログラムの提供する機能をアプリケーションプログラムから直接利用するため、プラットフォームプログラムの動作上の仕様が、アプリケーションプログラム作成時の制約条件となってしまう。アプリケーションプログラムの開発者は、常にこうした制約条件に注意を払って、入出力のタイミングやデータ形式等に気を配ってこうした制約条件をなくすためのルーチン（例えばＣＰＵ１１の命令コード）をアプリケーションに組み込む必要があった。
【００６７】
しかも、アプリケーションプログラムは、機能の追加、変更等の頻度が高く、こうした制約条件に注意を払いながら、これらの機能の追加や変更を行うのは困難であった。
そこで、本実施例では、図１２に示した従来のプログラム構成を図１０に示すように変更する。すなわち、上述したように従来は、条件判定処理と、演算処理と、負荷駆動要求処理とをアプリケーションプログラムで行うようにしていたのであるが、本実施例では、図１０に示すように結合処理部３に、従来、アプリケーションプログラムによって行っていた図１２のＳ１４０〜１６０に相当する処理を、図１０のＳ４２０〜４４０に示すように結合処理部３に設ける。そして結合処理部３には、アプリケーションプログラム４のＳ３１０〜３３０によって求められたＤｕｔｙＡＰを読み込む処理（Ｓ４１０）を設ける。このようにして図１０に示すように、情報加工処理と負荷駆動要求処理を結合処理部３による処理で行う。
【００６８】
その結果、アプリケーションプログラム４は、図１０のＳ３１０〜３３０のように、条件判定処理と演算処理とをＣＰＵ１１が実行するように構成するだけで済む。
このように、出力処理に関しても、アプリケーションの開発者は、プラットフォームプログラムのインターフェース仕様を気にすることなく、アプリケーションの開発を行うことができる。
【００６９】
なお、本実施例では、エンジンＥＣＵの例で説明したが、種々の車両用のＥＣＵのプログラム開発に適用できる。
【図面の簡単な説明】
【図１】実施例の車両用制御装置の構成を示すブロック図である。
【図２】実施例の車両用制御プログラムの構成を示す説明図である。
【図３】実施例の車両用制御プログラムによるデータ型式の変換処理の例を示す説明図である。
【図４】従来の車両用制御プログラムによるデータ型式の変換処理の例を示す説明図である。
【図５】実施例の車両用制御プログラムによるサンプリングタイミングの例を示す説明図である。
【図６】従来の車両用制御プログラムによるサンプリングタイミングの例を示す説明図である。
【図７】実施例の車両用制御プログラムによる割り込み処理の実行例を示す説明図である。
【図８】従来の車両用制御プログラムによる割り込み処理の実行例を示す説明図である。
【図９】実施例の車両用制御プログラムによるデータの出力処理の例を示す説明図である。
【図１０】実施例の車両用制御プログラムによるデータの出力処理を示すフローチャートである。
【図１１】従来の車両用制御プログラムによるデータの出力処理の例を示す説明図である。
【図１２】従来の車両用制御プログラムによるデータの出力処理を示すフローチャートである。
【符号の説明】
１…プログラム
２…プラットフォーム
３…結合処理部
４…アプリケーション
１０…エンジンＥＣＵ
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…Ｉ／Ｏ
１５…Ａ／Ｄ変換器
１６…タイマ
２０…エンジン制御用装置
２１…エンジン回転センサ
２２…Ｏ２センサヒータ
２３…水温センサ

Claims (5)

1. プラットフォームプログラムと、アプリケーションプログラムとを備える車両用制御プログラムにおいて、
   さらに、前記プラットフォームプログラムと前記アプリケーションプログラムとの間のデータ授受を仲介する処理を、コンピュータに実行させるための結合処理プログラムを備え、
   前記プラットフォームプログラムは、ハードウエアに依存した所定の時間間隔で起動し、ハードウェアデバイスからデータを入力して、当該データを前記プラットフォームプログラム管理下のメモリに記憶する処理、を前記コンピュータに実行させるためのプログラムであり、
   前記結合処理プログラムは、要求仕様による更新周期に基づく、前記プラットフォームプログラムの時間間隔とは異なる時間間隔で起動し、前記プラットフォームプログラム管理下のメモリに記憶されたデータを入力して、当該データを前記結合処理プログラム管理下のメモリに記憶する処理、を前記コンピュータに実行させるためのプログラムであり、
   前記アプリケーションプログラムは、要求仕様による利用周期に基づく、前記プラットフォームプログラムの時間間隔とは異なる時間間隔で起動し、前記結合処理プログラム管理下のメモリに記憶されたデータを入力して、当該データに基づき制御演算を行う処理、を前記コンピュータに実行させるためのプログラムであること
   を特徴とする車両用制御プログラム。
2. 前記プラットフォームプログラムにより実現されるデータ入力の前記時間間隔は、前記結合処理プログラムにより実現されるデータ入力の前記時間間隔、及び、前記アプリケーションプログラムにより実現されるデータ入力の前記時間間隔、よりも短い時間間隔であることを特徴とする請求項１記載の車両用制御プログラム。
3. 前記結合処理プログラムは、前記結合処理プログラム管理下のメモリに前記データを記憶するに際し、前記データを、前記アプリケーションプログラムの要求仕様を満たすデータ形式に変換し、当該変換後のデータを、前記結合処理プログラム管理下のメモリに記憶する処理を、前記コンピュータに実行させるための命令コードを含むプログラムであることを特徴とする請求項１又は請求項２記載の車両用制御プログラム。
4. 請求項１〜３のいずれかに記載の車両用制御プログラムを備える車両用制御プログラム。
5. 請求項１〜４のいずれかに記載の車両用制御プログラムと、
   当該車両用制御プログラムを実行するコンピュータと、
   を備えた車両用制御装置。

Images