JP2011081671A - 制御装置、制御方法及びコンピュータプログラム - Google Patents

Abstract

【課題】アプリケーションプログラムとプラットフォームプログラムとの間の中間層にて、アプリケーションプログラムのインタフェース側、及びプラットフォームプログラムのインタフェース側に中間処理部を２層化し、且つ２層夫々における処理を汎用化することで開発を効率化することができる制御装置、制御方法及びコンピュータプログラムを提供する。
【解決手段】アプリケーション層１０６及びプラットフォーム層１０７の間に、アプリケーション側の入出力に適合させるＡＰ入出力処理部１８２，１８３と、プラットフォーム側の入出力に適合させるＰＦ入出力処理部１８４，１８５とを含む中間処理層１０８を設け、夫々、アプリケーションプログラム及びプラットフォームプログラム各々の入出力を定義する外部から設定される定義テーブル１９に基づき適合させる。
【選択図】図２

Description

本発明は、アプリケーションプログラムとハードウェア資源の制御に直接的に関わるプラットフォームプログラムとが実行される制御装置に関する。特に、アプリケーションプログラム及びプラットフォームプログラム、又はいずれか一方の仕様変更に対し、その都度プログラムを改変することを不要とし、再利用性、及び開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムに関する。

近年では、種々の制御を行なう制御装置に通信機能を備えさせて複数接続し、各制御装置に夫々機能を割り振って相互にデータを交換し、連携して多様な処理を行なわせるシステムが各分野で利用されている。例えば、車両に配される車載ＬＡＮ（Local Area Network）の分野では、ＥＣＵ（電子制御装置；Electronic Control Unit）は通信機能を有し、各ＥＣＵに夫々特定の処理を行なわせて相互にデータを交換することにより、システムとして多様な機能を実現させている（例えば、特許文献１参照）。

各ＥＣＵは、ハードウェア資源との間で制御信号、状態信号を入出力して動作する。そして、各ＥＣＵでは、信号の入出力という機械的な処理と、ＥＣＵ夫々の特定の機能を実現するソフトウェア的な処理との間を仲介するドライバプログラムが利用される。多数のＥＣＵを用いる場合、夫々が有するハードウェア資源又は接続されるハードウェア資源によって、ドライバプログラムを個々に開発して搭載するのでは効率的でない。

そこで特許文献２に開示されているように、ハードウェア資源の際によらない処理などを汎用化し、ハードウェア資源に関わるプログラムはプラットフォームプログラムとして共通化して多様なアプリケーションプログラムに対応させるようなプログラム構成とすることが行なわれている。

特開２００７−３２９５７８号公報 特開２００４−１９２５４１号公報

特許文献２に開示されている発明のように、アプリケーションプログラムとプラットフォームプログラムとの間に結合処理部を設けてインタフェースの差異を吸収できるので、異なる仕様のハードウェア資源を使用する場合でも、アプリケーションプログラムを流用することができ、開発効率が向上する。

しかしながら、結合処理部が設けられる構成としても効率化が不十分な場合が考えられる。例えば、ハードウェア資源が替えられた場合、又は仕様が変更された場合にこれに応じてプラットフォームプログラムのインタフェースが変化したとする。この場合、アプリケーションプログラムをも改変する必要がないように、当該アプリケーションプログラムのインタフェースには対応させたまま、結合処理部を新たなプラットフォームプログラムのインタフェースに対応させるように改変する必要がある。もしも、次にアプリケーションプログラムを入れ替えるとするとプラットフォームプログラムのインタフェースには対応させたまま、新たなアプリケーションプログラムのインタフェースに対応させなければならない。つまり、アプリケーションプログラムとプラットフォームプログラムとの組み合わせに応じて結合処理部を対応させなければならない。

また、１つのＥＣＵにて、異なる複数のアプリケーションプログラムが実行される場合がある。このとき、夫々のアプリケーションプログラムから、同一のデータの読み出し要求がされる場合、結合処理部を設けたとしても、異なるアプリケーションプログラムそれぞれに独立に対応させる構成では、同一のデータを複数回読み出して渡す処理が行なわれ、処理が冗長的となり、ＥＣＵ全体での処理負荷の低減が不十分である。

更に、同一の機能を実現するアプリケーションプログラム及びプラットフォームプログラムの組であっても、ＥＣＵを搭載する車両の仕向けによっては、入力されるべきでないデータ、出力されるべきでないデータなどが存在する場合がある。この場合に、アプリケーションプログラム及びプラットフォームプログラム夫々に応じて入出力の形式を変える構成では、仕向けごとに開発が必要となり開発効率が低下する。

本発明は斯かる事情に鑑みてなされたものであり、アプリケーションプログラムとプラットフォームプログラムとの間の中間層にて、アプリケーションプログラムのインタフェース側、及びプラットフォームプログラムのインタフェース側に、結合処理（中間処理）部を２層化し、且つ２層夫々における処理を汎用化することで開発を効率化することができる制御装置、制御方法及びコンピュータプログラムを提供することを目的とする。

第１発明に係る制御装置は、一又は複数のアプリケーションプログラムを実行する第１実行手段と、前記アプリケーションプログラムからのデータに対応して一又は複数のハードウェア資源の動作を制御し、又は前記ハードウェア資源のデータを前記アプリケーションプログラムへ入力するプラットフォームプログラムを実行する第２実行手段と、第１実行手段及び第２実行手段の間でデータを夫々に適合するように変換して入出力処理を行なう中間処理実行手段とを備える制御装置において、前記中間処理実行手段は、第１実行手段とのデータの入出力処理を実行する第１処理手段と、第２実行手段とのデータの入出力処理を実行する第２処理手段と、外部から設定することが可能であって各アプリケーションプログラム及びプラットフォームプログラムに夫々対応付けて入出力データを定義するテーブルとを備え、第１処理手段及び第２処理手段は夫々、前記テーブルに基づき入出力データを変換して入出力するようにしてあることを特徴とする。

第２発明に係る制御装置は、第１処理手段は、前記テーブルとして、異なるアプリケーションプログラム夫々の入出力データの数、型又は形式の定義情報の第１テーブルをアプリケーションプログラム毎に有し、第１実行手段から出力されるデータを、第１実行手段が実行するアプリケーションプログラムに対応する定義情報に基づいて取り出し、第１実行手段へ入力するデータを、第１実行手段が実行するアプリケーションプログラムに対応する定義情報に基づいてデータを変換するようにしてあることを特徴とする。

第３発明に係る制御装置は、第２処理手段は、前記テーブルとして、制御対象のハードウェア資源により異なるプラットフォームプログラム夫々の入出力データの数、型、形式又はその組み合わせの定義情報の第２テーブルをプラットフォームプログラム毎に有し、第２実行手段とのデータの入出力の際に、第２実行手段が実行するプラットフォームプログラムに対応する定義情報に基づき、データを変換して入出力するようにしてあることを特徴とする。

第４発明に係る制御装置は、前記入出力データは、データの内容に応じて異なる種類に分類されており、該分類は前記テーブルに含まれ、第１処理手段は、第１実行手段へ入出力データを前記分類毎に入力するようにしてあることを特徴とする。

第５発明に係る制御装置は、第１テーブルは、入出力データ夫々について無効／有効の設定を受け付けるようにしてあり、第１処理手段は、アプリケーションプログラム毎に対応する入出力データの第１テーブルにて、無効が設定されているデータについては予め規定してある無効値に変換して入出力するようにしてあることを特徴とする。

第６発明に係る制御装置は、第１処理手段は、入出力データの内の一部又は全部を、第２実行手段が実行するプラットフォームプログラムに対応して作成する手段を備えることを特徴とする。

第７発明に係る制御方法は、一又は複数のアプリケーションプログラムを実行し、前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラムを実行し、更に、前記アプリケーションプログラム及びプラットフォームプログラムの間の入出力データを夫々に適合するように変換して入出力処理を行なう中間処理プログラムを実行し、前記ハードウェア資源の制御を行なう制御方法において、外部から設定することが可能であって各アプリケーションプログラム及びプラットフォームプログラムに夫々対応付けて入出力データを定義するテーブルを記憶しておき、
前記中間処理プログラムにより、前記テーブルに基づき、前記アプリケーションプログラムに適合するように入出力データを変換し、前記テーブルに基づき、前記プラットフォームプログラムに適合するように入出力データを変換することを特徴とする。

第８発明に係るコンピュータプログラムは、コンピュータに、一又は複数のアプリケーションプログラム、及び該アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラム間のデータの入出力を夫々のプログラムに対応させて実行させるコンピュータプログラムであって、コンピュータに、各アプリケーションプログラムに夫々対応付けて入出力データを定義するテーブルに基づき、前記アプリケーションプログラムに適合するように入出力データを変換させ、各プラットフォームプログラムに夫々対応付けて入出力データを定義するテーブルに基づき、前記プラットフォームプログラムに適合するように入出力データを変換させることを特徴とする。

本発明では、アプリケーションプログラムと制御対象のハードウェア資源に依存するプラットフォームとの間の入出力を夫々に適合させる中間処理実行手段（中間処理プログラム）が、アプリケーションプログラムによる入出力を処理する側と、プラットフォームプログラムによる入出力を処理する側との２つに分離される。しかも、アプリケーションプログラム側の処理及びプラットフォームプログラム側の処理では夫々、外部から適宜設定することが可能なテーブルに基づき変換を行なうようにしてある。これにより、アプリケーションプログラムの入れ替え、ハードウェア資源の入れ替え又は仕様変更がされた場合であっても、中間処理実行手段の処理自体を変更させることなく、テーブルの入れ替えのみで適切に入出力がされる。

本発明では、テーブルにはアプリケーションプログラムの入出力データの数、型又は形式の定義情報が含まれる。中間処理実行手段では、定義情報に基づく数、型又は形式でデータの取り出し、又は入力をする構成を実現しておけば、参照する定義情報をアプリケーションプログラムに対応させることで適合した入出力を行なうことができる。

本発明では、テーブルにはプラットフォームプログラムの入出力データの数、型又は形式の定義情報が含まれる。中間処理実行手段では、定義情報に基づく数、型又は形式でデータの入出力をする構成を実現しておけば、参照する定義情報をプラットフォームプログラムの仕様に対応させることで適合した入出力を行なうことができる。

本発明では、アプリケーションプログラムが入出力するデータを、データの種類毎に分類しておき、分類毎に入出力がされる。同一の分類に分けられるデータは、アプリケーションプログラムによって共に使用される可能性が高い。同一の分類に分けられるデータを１つずつ入出力するよりも、入出力の回数を低減することが可能となり、プログラム全体の規模を縮小し、制御装置全体としての処理負荷を軽減し、処理速度を向上させることも可能である。

本発明では、制御装置の仕様、仕向けによって無効とすべきデータの入出力を中間処理実行手段にて無効化することが可能である。これにより、アプリケーションプログラムの入出力の仕様の変更が不要となり、開発効率を向上させることが可能である。

本発明では、アプリケーションプログラムにおけるプラットフォームプログラムへの入出力データの作成処理の内、汎用化できる処理を中間処理実行手段にて代替される。これにより、アプリケーションプログラムの規模を縮小し、処理速度を高速化することが可能となる。

本発明による場合、アプリケーションプログラムの入れ替え、ハードウェア資源の入れ替え又は仕様変更がされた場合であっても、中間処理実行手段（中間処理プログラム）が参照するテーブルの入れ替えによって適応させることができる。したがって、中間処理実行手段の構成の変更が少なくて済み、汎用性が向上し、開発効率が向上する。

更に本発明による場合、中間処理実行手段（中間処理プログラム）内の構成も汎用化され、アプリケーションプログラムの入れ替え、ハードウェア資源の入れ替え又は仕様変更に、定義情報のテーブルの更新のみで適応できるので、再利用性が向上する。

本実施の形態におけるＥＣＵの構成を示すブロック図である。 本実施の形態におけるＥＣＵのＣＰＵが実現する機能を概念的に示す説明図である。 本実施の形態におけるＥＣＵのＣＰＵがＡＰ入出力処理部として参照する定義テーブルの内容例を示す説明図である。 本実施の形態におけるＥＣＵのＣＰＵがＰＦ入出力処理部として参照する定義テーブルの内容例を示す説明図である。 グループ単位でデータが入出力されることを概念的に示す説明図である。 仕向け毎に無効化させる情報を記憶する定義テーブルの内容例を示す説明図である。 各アプリケーションプログラム中の入出力データの作成処理を中間処理層にて代替させる構成を概念的に示す説明図である。

以下、本発明をその実施の形態を示す図面に基づいて具体的に説明する。

図１は、本実施の形態におけるＥＣＵの構成を示すブロック図である。ＥＣＵ１は、車両に搭載され、車両の走行又はドア、ミラーなどの機構の動作を制御する。ＥＣＵ１にはセンサ２及びアクチュエータ３が接続されている。ＥＣＵ１は、センサ２から得られる情報に基づきアクチュエータ３を動作させるか、又は図示しない他のＥＣＵの処理によって得られる情報に基づいてアクチュエータ３を動作させるなど、特有の機能を有する。なお、ＥＣＵ１にはセンサ２及びアクチュエータ３がいずれも接続されているが、何れか一方のみ接続されているか又はいずれも接続されていなくともよい。

ＥＣＵ１は、各構成部の動作を制御するＣＰＵ（Central Processing Unit、ＣＰＵコア）１１、不揮発性メモリを用いたＲＯＭ（Read Only Memory）１２、高速にアクセスすることが可能なメモリを用いたＲＡＭ１３を含むマイクロコンピュータ１０（以下、マイコン１０という）と、不揮発性メモリを用いた記憶部１４、センサ２及びアクチュエータ３とのインタフェースである入出力部１５とを備える。

記憶部１４は、フラッシュメモリ、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）等のメモリを利用し、ＲＯＭ１２等よりも比較的に大容量の記憶容量にて構成される。記憶部１４には、マイコン１０が後述するアプリケーションプログラム１６，１６，…を実行することによって行われる処理により得られる情報、例えばＥＣＵ１の状態情報、ＥＣＵ１が搭載される車両の状態情報等のシステム情報が記憶される。また、記憶部１４には、マイコン１０がセンサ２から取得したデータ、及び他のＥＣＵから受信したデータ等が記憶される。

入出力部１５は、上述のようにセンサ２及びアクチュエータ３とのインタフェースであり、入出力部１５はセンサ２が接続されている場合、センサ２から出力される測定値等を表わす信号を取り出してマイコン１０へ出力する。また入出力部１５は、アクチュエータ３が接続されている場合、マイコン１０から出力されるアクチュエータ３の制御信号をアクチュエータ３へ出力する。入出力部１５は、Ｄ／Ａ変換、Ａ／Ｄ変換機能を有していてもよい。

マイコン１０のＣＰＵ１１は、ＲＯＭ１２に記憶されている制御プログラム１ＰをＲＡＭ１３に読み出して実行することにより各構成部を制御し、特有の機能を実現する。

ＲＯＭ１２には、マスクＲＯＭ、フラッシュメモリ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable and Programmable ROM）、ＥＥＰＲＯＭ（Electrically EPROM）等のメモリを利用する。ＲＯＭ１２には、上述のように制御プログラム１Ｐが記憶されているほか、制御に用いる制御データが記憶されていてもよい。

ＲＡＭ１３は、ＤＲＡＭ（Dynamic Random Access Memory）、ＳＲＡＭ（Static Random Access Memory）等のメモリを利用している。ＲＡＭ１３にはＣＰＵ１１の処理によって発生する各種情報が一時的に記憶される。

ＲＯＭ１２に記憶されている制御プログラム１Ｐは、マイコン１０にＥＣＵ１特有の処理を実行させるためのアプリケーションプログラム１６，１６，…、ハードウェア資源の制御を実現するための各種を含むプラットフォームプログラム１７、アプリケーションプログラム１６，１６，…とプラットフォームプログラム１７との間のやり取りを仲介する中間処理プログラム１８を含んで構成される。

アプリケーションプログラム１６，１６，…には、ドアロックのオン・オフ、車室内ライトのオン・オフ、ヘッドライトのオン・オフ等を切り替えるための処理、又は自身の動作の正常／異常を診断する処理を実現させるプログラム等、ＥＣＵ１に特有の機能を実現させるための種々のプログラムが含まれる。

プラットフォームプログラム１７には、入出力部１５を介したセンサ２又はアクチュエータ３への制御信号の入出力、更には、記憶部１４へのデータの書き込み、記憶部１４からのデータの読み出しなどのアプリケーションプログラム１６，１６，…に基づくマイコン１０からのハードウェア資源への処理要求に対応して各ハードウェア資源への処理を実現するプログラムが含まれる。具体的には、アプリケーションプログラム１６，１６，…を実行するＣＰＵ１１からの処理要求に応じた論理的データアクセスを実現するデバイスドライバと、各ハードウェア資源の実装に基づく物理的データアクセスを実現するＢＩＯＳ（Basic Input/Output System）とを含む。

中間処理プログラム１８には、アプリケーションプログラム１６，１６，…からの処理要求をプラットフォームプログラム１７に対応させるように変換し、プラットフォームプログラム１７へ渡すなどのインタープリタ機能を実現するためのプログラムが含まれている。具体的には、中間処理プログラム１８は、アプリケーションプログラム１６，１６，…に基づくＣＰＵ１１からの駆動要求、例えばアクチュエータ３への駆動要求、又は記憶部１４へのデータ書き込み要求などを、各アプリケーションプログラム１６，１６，…に対応するデータの数、型又は形式で受け付け、プラットフォームプログラム１７が受け付けるデータの数、型又は形式に変換して受け渡す出力系の中間処理機能を実現する。また、中間処理プログラム１８は、プラットフォームプログラム１７から入力されるデータを受け付け、アプリケーションプログラム１６が解釈可能に変換等を行なってアプリケーションプログラム１６，１６，…へ渡す入力系の中間処理機能を実現する。

図２は、本実施の形態におけるＥＣＵ１のＣＰＵ１１が実現する機能を概念的に示す説明図である。なお、図２中のＡＰはアプリケーションの略であり、ＰＦはプラットフォームの略である。ＣＰＵ１１は、ＲＯＭ１２に記憶されている制御プログラム１ＰをＲＡＭ１３に読み出して実行する。制御プログラム１Ｐは上述のようにアプリケーションプログラム１６，１６，…、プラットフォームプログラム１７、及び中間処理プログラム１８を含む。ＣＰＵ１１は、制御プログラム１Ｐに含まれる各プログラムに基づき、アプリケーション層１０６、中間処理層１０８、プラットフォーム層１０７の３つの階層に分けられたソフトウェア構造にて動作する。

最上層のアプリケーション層１０６では、ＣＰＵ１１はアプリケーションプログラム１６，１６，…に基づき、各種アプリケーション（本実施の形態ではドアロックＡＰ１６１、室内ランプＡＰ１６２、ヘッドライト制御ＡＰ１６３、及び自己診断ＡＰ１６４）として機能する。

最下層のプラットフォーム層１０７では、ＣＰＵ１１によりプラットフォームプログラム１７に基づき、ハードウェア群２，３，１４，１５，…夫々の呼び出しインタフェース群であるＰＦＩ／Ｆ１７１を介して、ハードウェア群２，３，１４，１５，…の物理層における制御処理が行なわれる。

中間処理層１０８では、ＣＰＵ１１は中間処理プログラム１８に基づき、共有化されるＡＰＩ／Ｆ１８１にてアプリケーション層１０６の各アプリケーションからの駆動要求を受け付ける。そして、アプリケーション層１０６の各アプリケーションは共通に、ＡＰＩ／Ｆ１８１を呼び出すことにより情報を取得する。

また、中間処理層１０８では、ＣＰＵ１１は中間処理プログラム１８に基づき、各アプリケーションからの駆動要求を各アプリケーションに対応するデータとして変換するＡＰ出力処理部１８２として機能する。更に、各アプリケーションからの情報取得の呼び出しに対し、各アプリケーションに対応するデータを参照するように変換するＡＰ入力処理部１８３として機能する。

具体的には、ＡＰ出力処理部１８２は、例えばドアロックＡＰ１６１からの駆動要求である場合には、ドアロックＡＰ１６１に対応する定義テーブル１９内の定義情報に基づき、ドアロックに関する駆動要求であると変換する。詳細には、ＡＰ出力処理部１８２は、ドアロックＡＰ１６１からＮ番目の対象に対する駆動要求と、室内ランプＡＰ１６２から同一のＮ番目の対象に対する駆動要求とを受けた場合、ドアロックＡＰ１６１からの駆動要求については例えば助手席のドアロックに対する要求であると変換し、室内ランプＡＰ１６２からの駆動要求については例えば天井のランプに対する要求であるなどと、各アプリケーションに対応して変換することができる。

同様にしてＡＰ入力処理部１８３は、例えばドアロックＡＰ１６１からのＭ番目の対象に対する情報取得と、室内アンプＡＰ１６２からの同一のＭ番目の対象に対する情報取得とを受けた場合、ドアロックＡＰ１６１からの情報取得については、運転席のドアロック状態の情報取得であると変換し、室内ランプＡＰ１６２からの情報取得については例えばドア下部のランプの点灯状態の情報取得であると変換する。このように、各アプリケーションとの入出力を適宜夫々の仕様に応じて処理するＡＰ処理部としての機能を実現する。

更に、中間処理層１０８では、ＣＰＵ１１は中間処理プログラム１８に基づき、各アプリケーションからの駆動要求をプラットフォームに対応するデータに変換するＰＦ出力処理部１８４として機能する。更に、各アプリケーションへの情報取得を、プラットフォームに対応する形式での情報取得に変換するＰＦ入力処理部１８５として機能する。

図２に示したように、中間処理層１０８にて、各アプリケーションに対応した入出力に変換するＡＰ処理部（ＡＰ入出力処理部１８２，１８３）と、プラットフォーム層１０７のＰＦＩ／Ｆ１７１に対応した入出力に変換するＰＦ処理部（ＰＦ入出力処理部１８４，１８５）とに２層化されていることにより、多様なアプリケーション及び多様なハードウェア資源に対応させることができる。

次に、ＡＰ入出力処理部１８２，１８３の処理について具体的に説明する。ＡＰ出力処理部１８２、及びＡＰ入力処理部１８３は上述のように、各アプリケーションとの入出力を、いずれのアプリケーションとの間の入出力であるかに応じて適切に処理対象のデータを変換するとした。具体的には、ＡＰ出力処理部１８２及びＡＰ入力処理部１８３は、要求元又は情報取得元のアプリケーションに対応する定義テーブル１９内のテーブルを参照して変換を行なう。

図３は、本実施の形態におけるＥＣＵ１のＣＰＵ１１がＡＰ入出力処理部１８２，１８３として参照する定義テーブル１９の内容例を示す説明図である。図３に示すように、定義テーブル１９は、アプリケーション層１０６で動作する各アプリケーション、即ちドアロックＡＰ１６１、室内ランプＡＰ１６２、ヘッドライト制御ＡＰ１６３、自己診断ＡＰ１６４夫々の識別情報（ＩＤ）の一覧をアプリケーションテーブルとして含む。そしてアプリケーションテーブルは、アプリケーション毎に、ＩＤにより入出力データの定義と対応付けられている。図３に示すように、ドアロックＡＰ１６１にはＩＤ「１」が振られている。そして、ＩＤ「１」の入出力データは、運転席ドア開閉、助手席ドア開閉、運転席ドアロック解錠・施錠などの２値が定義されている。

ＣＰＵ１１は、例えばドアロックＡＰ１６１から駆動要求として、１バイト分のデータの出力があった場合を考える。このときＣＰＵ１１は、ＡＰ出力処理部１８３としての機能により、図３に示すような定義テーブル１９に基づき、出力されたデータの１ビット目は運転席ドア開閉、２ビット目は助手席ドア開閉、３ビット目は運転席ドアロック解錠・施錠であると認識する。そしてＣＰＵ１１は、３ビット目が施錠を示している場合、ＰＦ出力部１８４の機能へ、運転席ドアロックを施錠する駆動要求がされたことを通知する。

ＡＰＩ／Ｆ１８１は単純に、各アプリケーションから出力されたデータをＡＰ出力処理部１８２へ複製して与える処理のみで済む。これにより、ＡＰＩ／Ｆ１８１としてはアプリケーションによらない構成とすることができる。このようにして、中間処理層１０８のＡＰ入出力部１８２，１８３の機能にて、アプリケーションプログラムに依存する入出力を、ＡＰＩ／Ｆ１８１で汎用化しつつ、各アプリケーションからの呼び出しに適合させることができる。しかも、新たなアプリケーションプログラムが追加された場合、又は既存のアプリケーションプログラムの仕様が変わった場合などは、定義テーブル１９を更新、書き換え、又は入れ替えることによって、ＡＰ入出力部１８２，１８３、及びＡＰＩ／Ｆ１８１を実現させるプログラム自体を更新せずともよい点で、構成の変更が少なくて済み、汎用性即ち再利用性が向上し、開発効率が向上する。

次に、ＰＦ入出力処理部１８４，１８５の処理について説明する。ＰＦ出力部１８４及びＰＦ入力部１８５は上述のように、ＰＦＩ／Ｆ１７１を呼び出して駆動要求、又は情報取得をする際に、ＰＦＩ／Ｆ１７１に対応するように適宜データを変換する。具体的にはＡＰ入出力部１８２，１８３同様に、ＰＦ出力処理部１８４及びＰＦ入力処理部１８５は、駆動要求先又は情報取得先のハードウェア資源に対応する定義テーブル１９内のテーブルを参照し、データの数、型又は形式を夫々に応じて設定してＰＦＩ／Ｆ１７１を呼び出す。

図４は、本実施の形態におけるＥＣＵ１のＣＰＵ１１がＰＦ入出力処理部１８４，１８５として参照する定義テーブル１９の内容例を示す説明図である。図４に示すように、定義テーブル１９は、ハードウェア群２，３，１４，１５，…夫々に対応するＩ／Ｆ（呼び出し関数）のリストを、入力用及び出力用夫々に定義したプラットフォームテーブルを含む。

ＰＦ出力部１８４は例えば、ドアロックＡＰ１６１から運転席ドアロックを施錠するための駆動要求を、ＡＰ出力部１８２を介して受けた場合、運転席ドアロックを施錠するためのＩ／Ｆをプラットフォームテーブル内から抽出する。運転席ドアロックを施錠するためのＩ／Ｆが仮に、例えば引数がなく成功／不成功を戻り値として返す「３」番目の出力Ｉ／Ｆであれば、ＰＦ出力部１８４は当該Ｉ／Ｆの呼び出し方でＰＦＩ／Ｆ１７１を呼び出す。

ＰＦ入力部１８５は例えば、運転席ドア下部のランプの状態の情報取得を室内ランプＡＰ１６２からＡＰ入力部１８３を介して受けた場合、運転席ドアのみならず、各ドア下部のランプの状態を取得するＩ／Ｆ、例えば「１」番目の入力Ｉ／Ｆを呼び出すことを認識する。そして、引数１のＸは運転席ドアランプ状態情報に対応するポインタ、引数２のＹは助手席ドアランプ状態情報に対応するポインタを渡すようにしてあるとする。このときＰＦ入力部１８５は、情報取得の対象ではない助手席ドアランプ状態情報についても定義して併せてＰＦＩ／Ｆ１７１を呼び出し、運転席ドアランプ状態情報のみについてＡＰ入力部１８３へ渡す。

これにより、アプリケーション側ではプラットフォーム（ハードウェア資源）によって異なるＩ／Ｆについては意識する必要がなく、各プラットフォームへの呼び出しを各ハードウェア資源に適合させることができる。また、プラットフォームテーブルを更新、書き換え、又は入れ替えることによって、ＰＦ入出力部１８４，１８５が実現させるプログラム自体を更新せずともよい点で、構成の変更が少なくて済み、汎用性即ち再利用性が向上し、開発効率が向上する。

更に、各アプリケーション（ドアロックＡＰ１６１、室内ランプＡＰ１６２、ヘッドライト制御ＡＰ１６３、自己診断ＡＰ１６４）とＡＰＩ／Ｆ１８１との間での情報取得又は駆動要求については、一度にやり取りがなされる構成とすることが望ましい。したがって、一度にやり取りがなされるようなデータについてはグループ化しておき、グループ単位で入出力されるようにすることが望ましい。

図５は、グループ単位でデータが入出力されることを概念的に示す説明図である。図５に示すように、ＡＰＩ／Ｆ１８１は、各アプリケーションからの駆動要求又は情報取得の受け付けをグループ単位のデータ入出力にて実現する。具体的には、例えばドアロックＡＰ１６１は、運転席ドアの開閉状態、助手席ドアの開閉状態、運転席ドアロックの解錠・施錠状態、助手席ドアロックの解錠・施錠状態、及びイグニッションキーの状態の情報取得を夫々要求するとする。このとき、予めこれらの情報をドアロックＧ（グループ）データとしてグループ化しておく。そしてドアロックＡＰ１６１からは、各情報を１つずつ情報取得させずに、一度に情報取得させるようにし、ＡＰ入力処理部１８３は、ドアロックＧデータ（運転席ドアの開閉状態、助手席ドアの開閉状態、運転席ドアロックの解錠・施錠状態、助手席ドアロックの解錠・施錠状態、及びイグニッションキーの状態）を１ビットずつで表し１バイト分でまとめてドアロックＡＰ１６１へ返す。

また、中間処理層１０８にて、全入出力データをデータベース化しておき、いずれかのデータの情報取得をアプリケーション層１０６から受けた場合に、グループ毎プラットフォーム層１０７のＰＦＩ／Ｆ１７１から情報取得の呼び出しをしてデータベースを更新しておくようにしてもよい。また、プラットフォームテーブルを参照して同一のＩ／Ｆで情報を取得できるデータについては一度に取得し、データベースを更新しておき、ＡＰＩ／Ｆ１８１は、各アプリケーションからの情報取得に対しデータベースからグループ単位で各データを返すようにしてもよい。

これにより、入出力の回数を低減することが可能となり、プログラム全体の規模を縮小し、制御装置全体としての処理負荷を軽減し、処理速度を向上させることも可能である。

本実施の形態では、ＥＣＵ１は車両に搭載されて車両の走行又はドア、ミラーなどの機構の動作を制御する制御装置である。車両については、同一のエンジンなどの部品を用いた同一の車種であっても、仕向けによって動作させてはいけない機能などがあり、使用されない情報、使用しなければならない情報がある。また、同一の制御対象の制御装置であっても車種又はグレードなどによって仕様が一部異なり、動作させるべきでない機能などがある。

そこで更に本実施の形態では、無効とすべき情報については、中間処理層１０８のＡＰ入出力部１８２，１８３又はＰＦ入出力部１８４，１８５にて無効化する。つまり、中間処理層１０８では、いずれかのアプリケーションからの情報取得を受けた場合に、該当する情報についてプラットフォーム層１０７から取得したとしても、予め設定される値（例えばゼロ）に置き換えてアプリケーションへ戻す。

そして、仕向け毎にいずれの情報を無効とすべきかを、定義テーブル１９にて定義する。例えば、仕向け毎に定義テーブル１９の内容を入れ替えてもよいし、定義テーブル１９に、各情報について「ある仕向けでは」、「通信にて有効な信号を受信しているときのみ」、又は「記憶部１４に記憶されているデータが特定の値のときのみ」にアプリケーションへ情報を取得させるなどの条件を付加しておいてもよい。

図６は、仕向け毎に無効化させる情報を記憶する定義テーブル１９の内容例を示す説明図である。図６に示すように、仕向け毎に入出力データの定義をグループ化しておく。

図６では、ドアロックＧデータの例が示されている。ドアロックＧデータは、運転席ドアの開閉、助手席ドアの開閉、運転席ドアロックの解錠・施錠の状態に加え、車速及び回転数を含むとする。図６に示す例では、破線に示すように、仕向けＡの場合には車速及び回転数については、ゼロを入力値とし情報の使用を無効化すべきことが定義テーブル１９に記憶される。ドアロックＡＰ１６１からの情報取得をＡＰＩ／Ｆ１８１が受けた場合、ＡＰ入力処理部１８３、又はＰＦ入力処理部１８５が、例えば記憶部１４、又はＲＯＭ１２内に設定されている仕向けに対応する無効化の情報を定義テーブル１９から読み出す。そして、ＡＰ入力処理部１８３又はＰＦ入力処理部１８５は、ＰＦＩ／Ｆ１７１により取得した運転席ドアの開閉、助手席ドアの開閉、運転席ドアロックの解錠・施錠の状態、車速及び回転数の情報の内、定義テーブル１９にて無効化すべきとされている車速及び回転数については、ＰＦＩ／Ｆ１７１から取得した値ではなく、「ゼロ」を値とし、ＡＰＩ／Ｆ１８１はこのデータをドアロックＡＰ１６１へ戻す。

なお、ＡＰ入力処理部１８３又はＰＦ入力処理部１８５は、記憶部１４又は図示しない通信Ｉ／Ｆからの信号に応じて、車速及び回転数を「ゼロ」とするか否かを決定してもよい。

これにより、制御装置の仕様、仕向けによって無効とすべきデータの入出力を中間処理層１０８にて無効化することが可能である。しかも定義テーブル１９の内容を更新すれば、ＡＰＩ／Ｆ１８１、ＡＰ入出力部１８２，１８３、及びＰＦ入出力部１８４，１８５の動作を変更することなしに、多様な仕様又は仕向けに対応させることができ、プログラム部品の再利用性を向上し、更に、開発効率を向上させることができる。

また、ドアロックＡＰ１６１、室内ランプＡＰ１６２、ヘッドライト制御ＡＰ１６３及び自己診断ＡＰ１６４はいずれも、駆動要求時には、プラットフォーム層１０７から中間処理層１０８を介して情報取得したデータに基づいてデータを作成し、作成したデータを、中間処理層１０８を介してプラットフォーム層１０７へ出力する。つまり、夫々異なる機能のためのアプリケーションであるが、入出力データを作成する処理は共通する。

そこで、本実施の形態では更に、中間処理層１０８の機能として作成処理を代替して実行する。定義テーブル１９にアプリケーション毎の入出力データの定義情報が含まれるから、ＣＰＵ１１は、中間処理層１０８にて、いずれのアプリケーションとの間の入出力であるか、又はいずれのハードウェア資源に対応するＰＦＩ／Ｆ１７１の呼び出しであるかに応じて、データを組み合わせて１つのグループへ作成する処理を代替することが可能である。

図７は、各アプリケーションプログラム中の入出力データの作成処理を中間処理層１０８にて代替させる構成を概念的に示す説明図である。図７に示すように、中間処理層１０８にてＣＰＵ１１は、作成処理部１８６として動作する。作成処理部１８６は、ドアロックＡＰ１６１、室内ランプＡＰ１６２、ヘッドライト制御ＡＰ１６３及び自己診断ＡＰ１６４にて共通して実行していた駆動要求時のデータの作成処理を代替して行なう。

具体的には、定義テーブル１９には更に、ドアロックＡＰ１６１、室内ランプＡＰ１６２、ヘッドライト制御ＡＰ１６３及び自己診断ＡＰ１６４夫々について、駆動要求時のデータの基準となるデータの定義が含まれている。そして、作成処理部１８６は、いずれのアプリケーションからの駆動要求であるかに応じて定義テーブル１９を参照し、例えばドアロックＡＰ１６１からの駆動要求である場合には、出力すべきデータをプラットフォーム層１０７から既に取得していたデータから作成し、ＡＰ出力処理部１８２へ渡す。なお、作成処理部１８６は、ＡＰ出力処理部１８２に含まれる構成でもよい。

これにより、各ドアロックＡＰ１６１、室内ランプＡＰ１６２、ヘッドライト制御ＡＰ１６３及び自己診断ＡＰ１６４の内の共通していた作成処理部分を、各アプリケーションプログラム１６，１６，１６，１６から除くことができる。したがって、アプリケーションプログラムの規模を縮小し、処理速度を高速化することが可能となる。

なお、開示された実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上述の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。

１ ＥＣＵ（制御装置）
１１ ＣＰＵ（第１実行手段、第２実行手段、中間処理実行手段）
１２ ＲＯＭ
１４ 記憶部
１６ アプリケーションプログラム
１０６ アプリケーション層（第１実行手段）
１７ プラットフォームプログラム
１０７ プラットフォーム層（第２実行手段）
１７１ ＰＦＩ／Ｆ
１８ 中間処理プログラム
１０８ 中間処理層（中間処理実行手段）
１８１ ＡＰＩ／Ｆ
１８２ ＡＰ出力処理部（第１処理手段）
１８３ ＡＰ入力処理部（第１処理手段）
１８４ ＰＦ出力処理層（第２処理手段）
１８５ ＰＦ入力処理層（第２処理手段）

Claims (8)

1. 一又は複数のアプリケーションプログラムを実行する第１実行手段と、前記アプリケーションプログラムからのデータに対応して一又は複数のハードウェア資源の動作を制御し、又は前記ハードウェア資源のデータを前記アプリケーションプログラムへ入力するプラットフォームプログラムを実行する第２実行手段と、第１実行手段及び第２実行手段の間でデータを夫々に適合するように変換して入出力処理を行なう中間処理実行手段とを備える制御装置において、
   前記中間処理実行手段は、
   第１実行手段とのデータの入出力処理を実行する第１処理手段と、
   第２実行手段とのデータの入出力処理を実行する第２処理手段と、
   外部から設定することが可能であって各アプリケーションプログラム及びプラットフォームプログラムに夫々対応付けて入出力データを定義するテーブルと
   を備え、
   第１処理手段及び第２処理手段は夫々、前記テーブルに基づき入出力データを変換して入出力するようにしてあること
   を特徴とする制御装置。
2. 第１処理手段は、
   前記テーブルとして、異なるアプリケーションプログラム夫々の入出力データの数、型又は形式の定義情報の第１テーブルをアプリケーションプログラム毎に有し、
   第１実行手段から出力されるデータを、第１実行手段が実行するアプリケーションプログラムに対応する定義情報に基づいて取り出し、第１実行手段へ入力するデータを、第１実行手段が実行するアプリケーションプログラムに対応する定義情報に基づいてデータを変換するようにしてあること
   を特徴とする請求項１に記載の制御装置。
3. 第２処理手段は、
   前記テーブルとして、制御対象のハードウェア資源により異なるプラットフォームプログラム夫々の入出力データの数、型、形式又はその組み合わせの定義情報の第２テーブルをプラットフォームプログラム毎に有し、
   第２実行手段とのデータの入出力の際に、第２実行手段が実行するプラットフォームプログラムに対応する定義情報に基づき、データを変換して入出力するようにしてあること
   を特徴とする請求項１又は２に記載の制御装置。
4. 前記入出力データは、データの内容に応じて異なる種類に分類されており、該分類は前記テーブルに含まれ、
   第１処理手段は、第１実行手段へ入出力データを前記分類毎に入力するようにしてあること
   を特徴とする請求項１乃至３のいずれかに記載の制御装置。
5. 第１テーブルは、入出力データ夫々について無効／有効の設定を受け付けるようにしてあり、
   第１処理手段は、アプリケーションプログラム毎に対応する入出力データの第１テーブルにて、無効が設定されているデータについては予め規定してある無効値に変換して入出力するようにしてあること
   を特徴とする請求項２乃至４のいずれかに記載の制御装置。
6. 第１処理手段は、
   入出力データの内の一部又は全部を、第２実行手段が実行するプラットフォームプログラムに対応して作成する手段を備えること
   を特徴とする請求項１乃至５のいずれかに記載の制御装置。
7. 一又は複数のアプリケーションプログラムを実行し、前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラムを実行し、更に、前記アプリケーションプログラム及びプラットフォームプログラムの間の入出力データを夫々に適合するように変換して入出力処理を行なう中間処理プログラムを実行し、前記ハードウェア資源の制御を行なう制御方法において、
   外部から設定することが可能であって各アプリケーションプログラム及びプラットフォームプログラムに夫々対応付けて入出力データを定義するテーブルを記憶しておき、
   前記中間処理プログラムにより、
   前記テーブルに基づき、前記アプリケーションプログラムに適合するように入出力データを変換し、
   前記テーブルに基づき、前記プラットフォームプログラムに適合するように入出力データを変換する
   ことを特徴とする制御方法。
8. コンピュータに、一又は複数のアプリケーションプログラム、及び該アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラム間のデータの入出力を夫々のプログラムに対応させて実行させるコンピュータプログラムであって、
   コンピュータに、
   各アプリケーションプログラムに夫々対応付けて入出力データを定義するテーブルに基づき、前記アプリケーションプログラムに適合するように入出力データを変換させ、
   各プラットフォームプログラムに夫々対応付けて入出力データを定義するテーブルに基づき、前記プラットフォームプログラムに適合するように入出力データを変換させる
   ことを特徴とするコンピュータプログラム。

Images