JP4922262B2 - 制御装置 - Google Patents

Description

本発明は、アプリケーションプログラムとプラットフォームプログラムとが実行される制御装置に関する。特に、アプリケーションプログラム及びプラットフォームプログラムの種々の組み合わせに柔軟に対応でき、アプリケーションプログラム及びプラットフォームプログラムの再利用性を向上させて開発過程の短縮化、開発負荷の削減を図ることができる制御装置に関する。

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

複数の制御装置が相互に連携して多様な処理を行なわせる場合、各制御装置の機能を特化させるよりも、各制御装置が同様の機能を実現することが可能な構成とし、設定に応じて相互に代替して処理を行なうことができるようにすることもできる。具体的には、各制御装置に特定の機能を実現させるための各アプリケーションプログラムから共通機能を分離し、共通機能をプラットフォームとなるプログラムで実現するように構成する。共通機能としては例えば、アプリケーションプログラムの実行に用いられるデータの記憶、更新、及び他の装置との通信処理等がある。

これにより、通信仕様の定義が変化した場合にはプラットフォームのプログラムを改変し、全制御装置に改変後のプラットフォームのプログラムを実行させればよい。この場合、アプリケーションプログラムは通信仕様の改変に対応させる必要がなく、それまでと同様の処理によって他の制御装置との通信を実現できる。したがって、ハードウェアの違いに応じた種々のバージョンのアプリケーションプログラムを用意するなど、煩雑な管理が必要ない。アプリケーションプログラムは、純粋に特定の機能を実現するための構成とすればよく、プログラムの再利用性が高くなる。
特開２００７−３２９５７８号公報

しかしながら、プラットフォームプログラムの構成もハードウェア資源の違い、又はメーカの違いによって多様である。プラットフォームプログラムに含まれるべき機能の定義は様々である。例えば、通信機能の内、通信線における障害検知機能をもプラットフォームプログラムにて実現されるように構成されている場合がある一方で、障害検知機能はアプリケーションプログラムで実現されるように設計されている場合もある。

特定のハードウェア資源を用いた制御を行なうためには当該ハードウェア資源に特化したプラットフォームプログラムを利用しなければならない場合もある。アプリケーションプログラムを設計するに際し、通信機能などはプラットフォームプログラムにて実現されるのでハードウェア資源の違いに対応させる必要がなかったにも拘わらず、プラットフォームプログラムが違う場合には結局アプリケーションプログラムにて各プラットフォームプログラムに対応させることが必要となる。この場合、アプリケーションプログラム及びプラットフォームプログラム双方での開発における煩雑性を改善させることができず、開発過程の短縮化、開発負荷の削減を図ることが困難である。

本発明は斯かる事情に鑑みてなされたものであり、アプリケーションプログラム及びプラットフォームプログラムの種々の組み合わせに柔軟に対応させ、装置の特有機能を実現させるアプリケーションプログラム及びプラットフォームプログラムの再利用性を向上させて開発過程の短縮化、開発負荷の削減を図ることができる制御装置を提供することを目的とする。

第１発明に係る制御装置は、一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム、及び、前記一又は複数のアプリケーションの機能からの処理要求に対応して一又は複数のハードウェア資源の動作の制御に対応する一又は複数の機能を実現するプラットフォームプログラムを含むコンピュータプログラムを実行する制御部を備え、前記プラットフォームプログラムは異なる複数のプログラムの内のいずれかに入れ替え可能にしてある制御装置において、前記コンピュータプログラムは、前記一又は複数のアプリケーションの機能と、前記プラットフォームプログラムに基づく各機能との間のデータの授受を、夫々のプログラムに対応して行なう複数の機能を実現するミドルウェアプログラムと、前記一又は複数のアプリケーション、プラットフォームプログラムに基づく機能及びミドルウェアプログラムに基づく機能のいずれからも独立して実現させるシステムマネージャプログラムとを更に含み、前記ミドルウェアプログラムは、前記一又は複数のアプリケーションプログラムに対応し、各アプリケーションとデータの授受を行なうための複数のインタフェース、及び、異なる複数のプラットフォームプログラムに対応し、該プラットフォームプログラムに基づく各機能とデータの授受を行なうための複数のインタフェースの機能を各実現するように構成されており、前記システムマネージャプログラムは、前記プラットフォームプログラムとインタフェースを共有して、前記ミドルウェアプログラムとデータの授受を行うように構成されており、前記制御部は、前記ミドルウェアプログラムに基づき、実行されるアプリケーションプログラム及び前記コンピュータプログラムに含まれるプラットフォームプログラムに応じて、異なるインタフェースの内から静的に選択されたインタフェースによりデータの授受を行ない、前記システムマネージャプログラムに基づき、動作すべき前記一又は複数のアプリケーション、前記プラットフォームプログラムに基づく各機能、及び前記ミドルウェアプログラムに基づく各機能を指示し、前記一又は複数のアプリケーションの実行状態、前記プラットフォームプログラムに基づく各機能の実行状態、及び前記ミドルウェアプログラムに基づく各機能の実行状態を検出することを特徴とする。

第２発明に係る制御装置は、前記制御部は、前記ミドルウェアプログラムに基づき、実行されるアプリケーション、又は前記プラットフォームプログラムに基づく機能に対応して機能を選択することを特徴とする。

第３発明に係る制御装置は、前記制御部は、前記ミドルウェアプログラムに基づき、前記プラットフォームプログラムに基づく機能により授受されるデータの内、前記一又は複数のアプリケーションへ渡すべきデータを選択し、前記一又は複数のアプリケーションにより授受されるデータの前記プラットフォームプログラムに基づく各機能の内の出力先を選択することを特徴とする。

第４発明に係る制御装置は、前記制御部は、前記ミドルウェアプログラムに基づき、実行させるべきアプリケーションを指示する情報、実行中の一又は複数のアプリケーションの機能を識別する情報、又はアプリケーションの実行状態を示す状態情報を、前記アプリケーション又は前記プラットフォームプログラムに基づく各機能との間で授受する機能を実現させることを特徴とする。

本発明にあっては、アプリケーションプログラム及びプラットフォームプログラム間のデータの授受を、各プログラムに対応させて行なうミドルウェアプログラムが実行される。更に、ミドルウェアプログラムにより複数の機能が夫々実行可能である。且つ、アプリケーションプログラムとのデータの授受と、プラットフォームプログラムとのデータの授受との何れについても、夫々異なるプログラムに応じたデータの授受を実現するインタフェースが用意されている。したがって、アプリケーションプログラム及びプラットフォームプログラムの種々の組み合わせに応じて、インタフェースを選択変更することができる。
これにより、実行されるアプリケーションプログラム及びプラットフォームプログラムの組み合わせに応じてデータの授受、及び、ミドルウェアプログラムにて実現される機能も種々選択可能となる。また、アプリケーションプログラム側で想定されていないプラットフォームプログラムとの組み合わせも含め、種々の組み合わせに柔軟に対応させることができ、多様なプラットフォームプログラムに再利用が可能である。

本発明にあっては、一のミドルウェアプログラムにて、種々のアプリケーションプログラム及びプラットフォームプログラムの組み合わせに対応して機能が選択される。例えば、一のアプリケーションプログラムでは、プラットフォームプログラムに所定の機能が在ることを前提として構成されているにも拘らず、組み合わせられるプラットフォームプログラムに所定の機能がない場合も、ミドルウェアプログラムにて当該機能が実現されるので、アプリケーションプログラムの動作に問題がない。したがって、アプリケーションプログラムをプラットフォームプログラムの違いに対応させて個別に改変する必要がなく、多様なプラットフォームプログラムに再利用が可能である。

本発明にあっては、プラットフォームプログラムからデータがアプリケーションプログラムへ出力された場合に、ミドルウェアプログラムの処理により、必要なデータが選択されてアプリケーションプログラムへ渡される。また、アプリケーションプログラムからプラットフォームプログラムへのデータについては、プラットフォームプログラム内の出力先がミドルウェアプログラムの処理によって選択されて渡される。これにより、アプリケーションプログラム及びプラットフォームプログラム間のデータの授受が合致していない場合であっても、適宜選択され調整される。アプリケーションプログラム側は何れのプラットフォームプログラムを用いるかに拠らず、アプリケーションプログラムに合致したデータを得ることができ、多様なプラットフォームプログラムに再利用可能である。

本発明にあっては更に、ミドルウェアプログラムの処理によって、実行されるべきアプリケーションプログラムを指示すること、実行中のアプリケーションプログラム又は実行状態をプラットフォームプログラム側に通知することが可能となる。プラットフォームプログラムによっては、アプリケーションプログラム側で実現されるべき機能がある場合もある。また、アプリケーションプログラムの状態によってはプラットフォームプログラム側で実現されるべき機能がある場合がある。ミドルウェアプログラムの処理によって相互に情報を得ることができ、アプリケーションプログラム及びプラットフォームプログラムの種々の組み合わせに対応が可能である。

本発明にあっては、更にアプリケーションプログラム及びプラットフォームプログラムの実行、並びに種々の組み合わせを実現するミドルウェアプログラムの実行を制御装置全体の種々の条件に応じて変更することが可能となる。また、各プログラムの状態を夫々の実行手段に亘って検出可能であるので、アプリケーションプログラムに応じてミドルウェアプログラムにおける機能を選択するなどの処理が可能となる。これにより、アプリケーションプログラム及びプラットフォームプログラムの種々の組み合わせが適宜実現可能となる。

本発明による場合、ミドルウェアプログラムがアプリケーションプログラム及びプラットフォームプログラムの種々の組み合わせに応じて、アプリケーションプログラム及びプラットフォームプログラム間におけるデータの授受を実現するので、アプリケーションプログラムをプラットフォームプログラムの違いに対応させずともよい。更にアプリケーションプログラム及びプラットフォームプログラムの組み合わせに応じてミドルウェアプログラムにて実現される機能も選択可能となるので、相互に過不足となる機能がミドルウェアプログラムにて調整可能である。これにより、プラットフォームプログラムが違う場合であってもアプリケーションプログラムを個別に対応させる必要がなくなり、アプリケーションプログラム及びプラットフォームプログラム双方の開発過程の短縮化を図ることができる。

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

なお、以下に示す実施の形態では、本発明に係る制御装置を車両に搭載される種々の制御を行なうＥＣＵ（Electronic Control Unit）に適用する場合を例に説明する。

図１は、本実施の形態におけるＥＣＵの構成を示すブロック図である。なおＥＣＵ１は、通信線２を介して他のＥＣＵと接続され、相互に通信が可能に構成されている。また、ＥＣＵ１には、センサ３及びアクチュエータ４が接続されている。ＥＣＵ１は、センサ３から得られる情報に基づく自身の処理、又は他のＥＣＵの処理によって得られる情報に基づいてアクチュエータ４を動作させるなど、特有の機能を有している。なお、ＥＣＵ１には、センサ３及びアクチュエータ４がいずれも接続されているが、何れか一方のみ接続されているか又は何れも接続されていなくともよい。

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

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

通信部１５は、マイコン１０による通信線２を介した他のＥＣＵとの通信を実現する。通信部１５は具体的に、ＣＡＮ（Control Area Network）、ＬＩＮ（Local Interconnect Network）、又はＦｌｅｘＲａｙ（登録商標）などのプロトコルに準じた通信を実現する。通信部１５は、マイコン１０の一部として構成されてもよい。

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

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

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

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

ＲＯＭ１２に記憶されている制御プログラム１Ｐは、マイコン１０にＥＣＵ１特有の処理を実行させるためのアプリケーションプログラム１７，１７，…、ハードウェア資源の制御、通信機能など、他のＥＣＵとの共通機能を実現するための各種を含むプラットフォームプログラム１８、アプリケーションプログラム１７，１７，…とプラットフォームプログラム１８との間のやり取りを仲介するミドルウェアプログラム１９、及び、各プログラムに基づく処理をＥＣＵ１全体として制御するシステムマネージャプログラム２０を含んで構成される。

アプリケーションプログラム１７，１７，…には、車両のエンジンを制御するための処理を実現させるプログラム、ドアロックのオン・オフ、ヘッドライトのオン・オフ等を切り替えるための処理を実現させるプログラム等、ＥＣＵ１に特有の機能を実現させるための種々のプログラムが含まれる。

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

ミドルウェアプログラム１９には、アプリケーションプログラム１７，１７，…からの処理要求をプラットフォームプログラム１８に対応させるように変換し、プラットフォームプログラム１８へ渡すなどのインタープリタ機能を実現するためのプログラムが含まれている。具体的には、ミドルウェアプログラム１９は、アプリケーションプログラム１７，１７，…に基づくＣＰＵ１１からの出力要求、例えば記憶部１４へのデータ書き込み要求、通信部１５を介した送信要求を受け付け、プラットフォームプログラム１８に対応させて受け渡す出力系処理機能を含む。そしてミドルウェアプログラム１９は、プラットフォームプログラム１８から入力されるデータを受け付け、アプリケーションプログラム１７が解釈可能に変換等を行なってアプリケーションプログラム１７，１７，…へ渡す入力系処理機能とを含む。また、ミドルウェアプログラム１９は、後述するシステムマネージャプログラム２０に基づくＣＰＵ１１から渡される管理情報をアプリケーションプログラム１７，１７，…へ渡す機能を実現するための管理系処理機能を実現する。

ミドルウェアプログラム１９に含まれる出力系処理機能、入力系処理機能、管理系処理機能は夫々、独立した機能モジュールとして夫々選択可能に構成されている。つまり、ＣＰＵ１１にてミドルウェアプログラム１９に基づいて処理を行なうに際し、不要な機能を実現する機能モジュールを削除してミドルウェアプログラム１９を実行した場合であっても、ＣＰＵ１１の処理が問題なく行えるように構成されている。また、各機能モジュールはアプリケーションプログラム１７又はプラットフォームプログラム１８に取り込み可能に構成されており、アプリケーションプログラム１７で不足している機能を補完するなどが可能である。具体的には、ミドルウェアプログラム１９は、オブジェクト構造のソフトウェアプログラムにて構成されており、各機能モジュールをオブジェクト単位に分けて設計されており、オブジェクトを選択して実行ファイルを作成することにより、種々の機能が選択可能である。

システムマネージャプログラム２０は、ＣＰＵ１１によって実行されるアプリケーションプログラム１７，１７，…に基づく処理、プラットフォームプログラム１８に基づく処理、ミドルウェアプログラム１９に基づく処理、及び、システムマネージャプログラム２０に基づく処理の全体を、ＥＣＵ１として機能すべき状況に対応させて制御させるためのプログラムである。例えば、ＥＣＵ１が出荷前のテスト段階における動作をすべきなのか、運用中における動作をすべきなのか、又はメンテナンス中における動作をすべきなのかなどの状況の違いに応じて、各プログラムに基づく処理を切り替える機能を実現する。又は、ＥＣＵ１が日本国仕様の車両、又は北米仕様の車両に対応すべきなのかに応じて各プログラムに基づく処理を切り替える機能を実現する。また例えば、実行されているアプリケーションプログラム１７，１７，…に応じてハードウェア資源の物理的制御方法を変化させるなどの機能を実現する。

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

最上層のアプリケーション層１０７では、ＣＰＵ１１はアプリケーションプログラム１７，１７，…に基づき、各種アプリ（アプリＡ，アプリＢ，アプリＣ，…）として機能する。

中間層に当たるミドルウェア層１０９では、ＣＰＵ１１はミドルウェアプログラム１９に基づき、アプリケーション層１０７の各アプリからの処理要求を受け付け、又はプラットフォーム層１０８からのデータをアプリケーション層１０７へ受け渡すための各機能モジュール群１１２，１１２，…が実行される。アプリケーション層１０７で実行されるアプリケーションプログラム１７，１７，…又はプラットフォーム層１０８で実行されるプラットフォームプログラム１８に応じて実行される機能モジュール１１２，１１２，…の選択が可能である。また、各機能モジュール１１２，１１２，…では、プラットフォーム層１０８で実行されるプラットフォームプログラム１８のプラットフォームインタフェース１０８ａに応じて、データの入出力方法等を切替可能である。そしてミドルウェア層１０９では、ミドルウェアプログラム１９に基づき、種々のアプリケーションプログラム１７，１７に対応するインタフェース群１１１，１１１，…が実現される。アプリケーション層１０７にて実行されるアプリケーションプログラム１７，１７，…に応じて呼び出し方法、データの受け渡し方法等を切り替え可能である。

最下層のプラットフォーム層１０８では、ＣＰＵ１１によりプラットフォームプログラム１８に基づきハードウェア群１４，１５，１６，…を実際に制御する処理が行なわれる。例えば、記憶部１４との間のデータの読み書き、通信部１５とのデータの受け渡しなどの各機能が実現される。なお、本実施の形態ではプラットフォーム層１０８における機能は、記憶部１４からどのデータを読み出すかなどの論理的なアクセスを実行する論理層と、実際に通信部１５のＩ／Ｏメモリに送信するデータを書き込むなど物理的アクセスを実行する物理層とに更に内部で階層化されているとする。

更に、ＣＰＵ１１がシステムマネージャプログラム２０を読み出して実行することにより、システムマネージャ１１０の機能がプラットフォーム層１０８とインタフェースを共有して実現される。システムマネージャ１１０は、アプリケーション層１０７にて機能する各種アプリの実行状態、実行されるアプリに応じたミドルウェア層１０９における機能モジュールの実行状態、プラットフォーム層１０８におけるハードウェア資源の有無等を３つの層にわたって検出し、情報を保持するシステム監視機能、ＥＣＵ１が搭載される車両の車種、仕向地、グレード、ＥＣＵ１の機能の切り替えに応じて各層で実現されるべきアプリ、機能モジュール群１１２，１１２，…、動作すべきハードウェア資源１４，１５，１６，…等を指示する機能管理を実現する。なお、システムマネージャ１１０は図２に示すようなプラットフォーム層１０８とインタフェースを共有する構成のみならず、各層の機能と直接的に情報を授受できる構成としてもよい。

アプリケーション層１０７で機能するアプリの例としては、信号制御、条件判定、負荷（アクチュエータ４等）を制御する負荷制御などがある。アプリケーション層１０７で実行される各アプリケーションプログラム１７，１７，…は、システムマネージャ１１０がミドルウェア層１０９の管理系の機能モジュール１１２を介して渡す管理情報に基づいて決定される。例えば、アプリケーション層１０７にて実行される特定のアプリケーションプログラム１７に基づき、ＣＰＵ１１がミドルウェア層１０９から管理情報を読み出し、管理情報に基づき実行されるべき他のアプリケーションプログラム１７，１７，…を選択して実行させる。管理情報には、例えば、ＥＣＵ１の状態又は状況を示す情報が含まれ、ＥＣＵ１の状態又は状況に応じて実行すべきアプリケーションプログラム１７，１７，…を識別する情報が含まれている。例えば、ＥＣＵ１が出荷前のテスト段階にあることを示す情報、その場合に実行されるべきアプリケーションプログラム１７，１７，…を識別する情報が含まれており、アプリケーション層１０７で当該管理情報に基づいて適切なアプリケーションプログラム１７が選択されて実行されるなど、状況に応じた処理が可能である。

ミドルウェア層１０９で機能する機能モジュール１１２の例としては、プラットフォーム層１０８から得られる情報を、アプリケーション層１０７で機能するアプリへ受け渡す入力系の中継機能がある。入力系の中継機能では、ＣＰＵ１１はプラットフォーム層１０８から得られる情報の内、アプリケーション層１０７で機能するアプリが要求する情報を渡す。他に、アプリケーション層１０７で機能するアプリから出力されるデータをプラットフォーム層１０８へ引き渡す出力系の中継機能がある。出力系の中継機能では、ＣＰＵ１１はアプリケーション層１０７で機能するアプリから出力された情報をその用途に合わせて、プラットフォーム層１０８における出力先を選択し、プラットフォームインタフェース１０８ａから適切なインタフェースを呼び出して渡す。

例えば、アプリから出力された情報が外部装置へ送信するデータである場合、プラットフォーム層１０８に対応した出力系の機能モジュール１１２の機能により、適した通信プロトコルに対応した通信ハードウェアからデータが送信されるように、プラットフォームインタフェース１０８ａから適切なインタフェースが呼び出されることによって出力先が選択される。また、アプリから出力された情報がアクチュエータ４への制御信号である場合、出力系の機能モジュール１１２の機能により、アクチュエータ４に対応するハードウェアへアクセスするためのインタフェースが適切に選択される。

図３は、ミドルウェアプログラム１９に基づき、アプリケーション層１０７及びプラットフォーム層１０８に対応させてインタフェース及び機能が実行される処理の一例を示すフローチャートである。なお、本処理は例えば、アプリケーションプログラム１７，１７，…、ミドルウェアプログラム１９、プラットフォームプログラム１８をリンクさせる際に、コンパイラなどによって実行される。

ミドルウェアプログラム１９には上述のように、種々のアプリケーションプログラム１７，１７，…の仕様要求に対応した呼び出し方法、データの受け渡しを実現するインタフェース群１１１，１１１，…が用意されている。したがって、実行されるアプリケーションプログラム１７、１７，…に応じたインタフェース１１１が選択される（ステップＳ１）。

また、ミドルウェアプログラム１９では、プラットフォーム層１０８にて実行されるプラットフォームプログラム１８の仕様に対応したデータの入出力方法等をインタフェースの選択により切替可能である。そこで、プラットフォームプログラム１８の仕様に対応したインタフェースが選択される（ステップＳ２）。

そして、実行されるアプリケーションプログラム１７，１７，…、プラットフォームプログラム１８に応じた機能モジュール１１２，１１２，…が選択される（ステップＳ３）。また、アプリケーション層１０７で実行されるべき機能、又はプラットフォーム層１０８にて実行されるべき機能がある。そこで、選択された機能モジュール１１２，１１２，…はアプリケーション層１０７又はプラットフォーム層１０８にて実行されるように配置され（ステップＳ４）、処理が終了する。

次に、ＣＰＵ１１のシステムマネージャ１１０としての機能により実現される処理について説明する。図４は、システムマネージャ１１０の機能に応じてアプリケーション層１０７、プラットフォーム層１０８及びミドルウェア層１０９にて実行される処理の一例を示すフローチャートである。以下に示す処理は例えば、ＥＣＵ１がリセットされた場合に行なわれる。

ＥＣＵ１がリセットされ、ＣＰＵ１１がリセットされるとプラットフォーム層１０８が起動し（ステップＳ１０１）、プラットフォーム層１０８と共に起動するシステムマネージャ１１０により、管理情報が作成されてプラットフォームインタフェース１０８ａを介して管理情報がミドルウェア層１０９に受け渡される（ステップＳ１０２）。

ミドルウェア層１０９では、プラットフォームインタフェース１０８ａによる通知によって管理情報が受け付けられ（ステップＳ１０３）、管理系の機能に基づき、管理情報が管理系インタフェースからアプリケーション層１０７に受け渡される（ステップＳ１０４）。

アプリケーション層１０７では、管理情報が受け付けられ（ステップＳ１０５）、管理情報に含まれる情報に基づき実行されるべきアプリケーションプログラム１７，１７，…が選択されて実行される（ステップＳ１０６）。そしてアプリケーション層１０７にて、実行されるアプリケーションプログラム１７，１７，…の実行状態が検知され（ステップＳ１０７）、検知された状態を示す状態情報が作成され（ステップＳ１０８）、作成された状態情報はミドルウェア層１０９に出力される（ステップＳ１０９）。

ミドルウェア層１０９では、アプリケーション層１０７から出力された状態情報が、アプリケーションプログラム１７に対応する管理系インタフェースにより受け付けられる（ステップＳ１１０）。ミドルウェア層１０９では、状態情報がシステムマネージャ１１０へ出力されるようにプラットフォームインタフェース１０８ａの内からインタフェースが選択されて受け渡される（ステップＳ１１１）。

システムマネージャ１１０により状態情報が受け付けられ（ステップＳ１１２）、処理が終了する。

ステップＳ１１２にてシステムマネージャ１１０にて状態情報が受け付けられると、システムマネージャ１１０では、状態情報に基づきＥＣＵ１全体として最適な状態が判定され、アプリケーション層１０７、ミドルウェア層１０９、及びプラットフォーム層１０８の各層にて最適な処理が行なわれるように管理情報が再度作成されるなどする。以後、ステップＳ１０７からステップＳ１１２までの処理が繰り返し行なわれて、システムマネージャ１１０にてアプリケーション層１０７における実行状態が監視される。これにより例えば、アプリケーション層１０７における処理の状態が変化したときには、装置全体でその状態変化に対応して最適な処理が行なわれるようにすることが可能である。

次に、本実施の形態においてミドルウェア層１０９にて、アプリケーション層１０７及びプラットフォーム層１０８に応じて各機能が選択される処理について具体例を挙げて説明する。

図５は、アプリケーションプログラム１７及びプラットフォームプログラム１８の一の組み合わせに対応した制御プログラム１Ｐの構造の一例を概念的に示す説明図である。図５の説明図では、プラットフォームプログラム１８が仕様Ｘに基づくものであり、プラットフォームインタフェース１０８ａも仕様Ｘに準じた構成である。また、図５の説明図では、アプリケーションプログラム１７，１７，…のアプリケーション層１０７は仕様Ｙに準じて設計、作成されたものである。そして、仕様Ｘのプラットフォームインタフェース１０８ａと仕様Ｙのアプリケーションプログラム１７，１７，…からの呼び出し方法等は対応しておらず、直接的には組み合わせられない。

しかしながら、本実施の形態における制御プログラム１Ｐのソフトウェア構造では、ミドルウェアプログラム１９が共にリンクされることにより、リンクの際に、アプリケーションプログラム１７，１７，…の仕様Ｙに対応するアプリケーション層１０７側のインタフェース１１１、仕様Ｘに対応するプラットフォーム層１０８側のインタフェースが選択され、組み合わせが可能となる。そして、ミドルウェア層１０９にて仕様Ｘのプラットフォーム層１０８、仕様Ｙのアプリケーション層１０７に対応する入力系、出力系、及び管理系の機能モジュール１１２，１１２，…が適切に選択される。これにより、仕様Ｘと仕様Ｙとでは直接的に組み合わせることができない場合であっても、組み合わせが可能となる。したがって、プラットフォーム層１０８の仕様毎にアプリケーションプログラム１７，１７，…を作成し直す等の処理が必要なくなる。

図６は、アプリケーションプログラム１７及びプラットフォームプログラム１８の一の組み合わせに対応した制御プログラム１Ｐの構造の他の一例を概念的に示す説明図である。図６の説明図では、プラットフォームプログラム１８が仕様Ｚに基づくものであり、プラットフォームインタフェース１０８ａも仕様Ｚに準じた構成である。一方、アプリケーションプログラム１７，１７，…のアプリケーション層１０７は仕様Ｗに準じて設計、作成されたものである。この場合も仕様Ｚのプラットフォームインタフェース１０８ａと仕様Ｗのアプリケーションプログラム１７，１７，…とは直接的に組み合わせられない。

図６に示す例では、アプリケーションプログラム１７，１７，…の仕様Ｗに対応するアプリケーション層１０７側のインタフェース１１１、仕様Ｚに対応するプラットフォーム層１０８側のインタフェースが選択され、組み合わせが可能となる。そして、仕様Ｗのアプリケーションプログラム１７，１７，…には、プラットフォーム層１０８から入力されるデータ（信号）を展開するアプリ、出力するデータ（信号）を作成するアプリが実装されており、ミドルウェア層１０９にて対応が不要である。この場合、図３のフローチャートにて示したように、ミドルウェアプログラム１９から適宜機能モジュール１１２，１１２，…が選択されるので、インタフェース間のインタープリタのみの機能、管理系の機能が選択される。このように、組み合わせられるアプリケーションプログラム１７，１７，…及びプラットフォームプログラム１８に応じて、機能も選択が可能であるため、種々の組み合わせが可能となり、プラットフォーム層１０８の仕様毎にアプリケーションプログラム１７，１７，…を作成し直す等の処理が必要なくなる。

図７は、アプリケーションプログラム１７及びプラットフォームプログラム１８の一の組み合わせに対応した制御プログラム１Ｐの構造の他の一例を概念的に示す説明図である。図７の説明図では、プラットフォームプログラム１８が仕様Ｖに基づくものであり、プラットフォームインタフェース１０８ａも仕様Ｖに準じた構成である。一方、アプリケーションプログラム１７，１７，…のアプリケーション層１０７は仕様Ｓに準じて設計、作成されたものである。この場合も仕様Ｖのプラットフォームインタフェース１０８ａと仕様Ｓのアプリケーションプログラム１７，１７，…とは直接的に組み合わせられない。

図７に示す例では、アプリケーションプログラム１７，１７，…の仕様Ｓに対応するアプリケーション層１０７側のインタフェース１１１、仕様Ｖに対応するプラットフォーム層１０８側のインタフェースが選択され、組み合わせが可能となる。仕様Ｖのプラットフォームインタフェース１０８ａと仕様Ｓのアプリケーションプログラム１７，１７，…との組み合わせでは、入力系の機能として入力データ（信号）を展開する機能、他のＥＣＵから受信したデータを解析する機能が不足しているので図３のフローチャートに示した処理によって機能モジュール１１２，１１２，…が選択されるとする。また、出力系の機能として、出力データ（信号）を更新する機能、他のＥＣＵへ送信するデータを作成する機能が不足しているので選択される。更に、通信部１５における通信状態を監視する機能、断線を検知する機能も不足しているためにミドルウェアプログラム１９からそれらに相当する機能モジュール１１２，１１２，…が選択されるとする。

更に図７に示す例では、図３のフローチャートに示した処理によって、入力データ展開機能は、例えばアプリケーション層１０７で実行される他のアプリとの関係から、アプリケーションプログラム１７として実行されるべきと判断され、ミドルウェアプログラム１９からそれらに相当する機能モジュール１１２，１１２，…が選択されてアプリケーション層１０７に配置される。図７に示す例では他に、出力データ更新機能、断線検知機能についてもアプリケーション層１０７に配置され、受信データ解析機能、送信データ作成機能及び通信状態監視機能が不足しているとして機能モジュール１１２，１１２，…が選択された上でプラットフォーム層１０８に配置されている。

このように、組み合わせられるアプリケーションプログラム１７，１７，…及びプラットフォームプログラム１８に応じて、機能の選択も可能であり、更に夫々の構成に応じて配置も可能である。したがって種々の組み合わせにて、所望の機能実現が可能となり、プラットフォーム層１０８の仕様毎にアプリケーションプログラム１７，１７，…を作成し直す等の処理が必要なくなる。

このように、どのような仕様に基づき作成されたプラットフォームプログラム１０８に基づくプラットフォーム層１０８に対しても、種々のアプリケーションプログラム１７，１７，…に基づくアプリケーション層１０７の機能を組み合わせることができる。何れのプラットフォームプログラム１０８からも、プラットフォームインタフェース１０８ａより上層は自身の仕様に対応するアプリケーション層として区別なく扱われ、何れのアプリケーションプログラム１７，１７，…からもミドルウェア層１０９以下の層は、自身の仕様に対応するプラットフォーム層１０８として区別なく扱われる。これにより、アプリケーションプログラム１７，１７，…を改変することなく種々のプラットフォームプログラム１８と組み合わせて使用可能である。したがって、アプリケーションプログラム１７，７，…及びプラットフォームプログラム１８の再利用性が高まる。

ミドルウェアプログラム１９にて、種々のアプリケーション層１０７、及びプラットフォーム層１０８の構成に対応可能なソフトウェア構造とすることにより、種々のアプリケーション層１０７及びプラットフォーム層１０８の組み合わせにてＥＣＵ１の制御が可能となる。そして、従来のようなプラットフォーム層１０８側のインタフェースの違いのみ、又はアプリケーション層１０７側の呼び出し方法等の違いのみいずれか一方を吸収するためのみならず、両者のインタフェースに対応して夫々独立にインタフェースを選択可能な構成とすることにより、多様な組み合わせに対応させることが可能である。したがって、これまで仕様Ｘのプラットフォーム層１０８を利用する場合に、仕様Ｘ用のアプリケーションプログラム１７，１７，…を独立に作成する必要があるなどしたが、仕様Ｘ及び仕様Ｚのプラットフォーム層１０８に対し、同一の仕様のアプリケーションプログラム１７，１７，…を利用することができ、アプリケーションプログラム１７，１７，…及びプラットフォームプログラム１８双方の再利用性が向上する。

複数のＥＣＵを用いて連携して多様な処理を行なわせる場合、いずれかのＥＣＵでは特定のハードウェア資源を用いることが必須となる場合がある。特定のハードウェア資源を用いるには、当該ハードウェア資源に特化したプラットフォームプログラム１８を用いる必要がある。そのようなプラットフォームプログラム１８に各別にアプリケーションプログラム１７，１７，…を改変する構成では、開発期間を短縮できない。これに対し、本実施の形態におけるソフトウェア構成であれば、ミドルウェアプログラム１９の内容を、アプリケーション層１０７、プラットフォーム層１０８夫々の仕様に独立に対応させれば、一のミドルウェアプログラム１９で、各ＥＣＵの種々の組み合わせに応じた処理を可能とすることができる汎用化を実現し、開発期間の短縮化のみならず、大規模開発においてもプログラム管理の煩雑性を解消することができるなど、優れた効果を奏する。

例えば、現状では各ベンダーが夫々独自にＥＣＵ及びＥＣＵの構成部品を作成し、プラットフォームプログラム１８も多様である。しかしながら、新規又は既存のプラットフォーム層１０８の標準化が進み、更にその後プラットフォームインタフェース１０８ａが改変、追加される可能性がある。標準化が進んだ場合はアプリケーションプログラム１７，１７，…を対応させることが必須となる上、インタフェースが改変追加される都度に改変が必要となる。しかしながら、本実施の形態における制御プログラム１Ｐのソフトウェア構造によれば、アプリケーションプログラム１７，１７，…の改変は必要なく、ミドルウェアプログラム１９を標準化プラットフォームに適応させてリンクをし直すのみでよく、更に他のプラットフォームにも依然として利用可能となる。

また、ミドルウェアプログラム１９は複数の夫々分離可能な機能モジュールにて構成されているので、図７に示したように、機能モジュールを必要に応じてアプリケーション層１０７側で実行する、又はプラットフォーム層１０８側で実行するように機能を配置することが可能となる。これにより、種々のアプリケーション層１０７及びプラットフォーム層１０８の組み合わせによっては夫々不足する機能を補完するなどが可能である。即ち、種々の組み合わせに対応させることができ、アプリケーションプログラム１７，１７，…及びプラットフォームプログラム１８の再利用性が向上する。

上述に示した実施の形態では、本発明は車両に搭載されるＥＣＵに適用される例を示した。しかしながら本発明はこれに限らず、ハードウェア資源の制御をアプリケーションプログラムに基づき制御するコンピュータ装置に適用することができる。

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

本実施の形態におけるＥＣＵの構成を示すブロック図である。 本実施の形態におけるＥＣＵのＣＰＵが実現する機能を概念的に説明する説明図である。 ミドルウェアプログラムに基づき、アプリケーション層及びプラットフォーム層に対応させてインタフェース及び機能が実行される処理の一例を示すフローチャートである。 システムマネージャの機能に応じてアプリケーション層、プラットフォーム層及びミドルウェア層にて実行される処理の一例を示すフローチャートである。 アプリケーションプログラム及びプラットフォームプログラムの一の組み合わせに対応した制御プログラムの構造の一例を概念的に示す説明図である。 アプリケーションプログラム及びプラットフォームプログラムの一の組み合わせに対応した制御プログラムの構造の他の一例を概念的に示す説明図である。 アプリケーションプログラム及びプラットフォームプログラムの一の組み合わせに対応した制御プログラムの構造の他の一例を概念的に示す説明図である。

符号の説明

１ ＥＣＵ
１０ マイコン
１１ ＣＰＵ
１２ ＲＯＭ
１７，１７ アプリケーションプログラム
１８ プラットフォームプログラム
１９ ミドルウェアプログラム
２０ システムマネージャプログラム
１０７ アプリケーション層
１０８ プラットフォーム層
１０９ ミドルウェア層
１１０ システムマネージャ

Claims (4)

1. 一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム、及び、前記一又は複数のアプリケーションの機能からの処理要求に対応して一又は複数のハードウェア資源の動作の制御に対応する一又は複数の機能を実現するプラットフォームプログラムを含むコンピュータプログラムを実行する制御部を備え、前記プラットフォームプログラムは異なる複数のプログラムの内のいずれかに入れ替え可能にしてある制御装置において、
   前記コンピュータプログラムは、
   前記一又は複数のアプリケーションの機能と、前記プラットフォームプログラムに基づく各機能との間のデータの授受を、夫々のプログラムに対応して行なう複数の機能を実現するミドルウェアプログラムと、
   前記一又は複数のアプリケーション、プラットフォームプログラムに基づく機能及びミドルウェアプログラムに基づく機能のいずれからも独立して実現させるシステムマネージャプログラムと
   を更に含み、
   前記ミドルウェアプログラムは、前記一又は複数のアプリケーションプログラムに対応し、各アプリケーションとデータの授受を行なうための複数のインタフェース、及び、異なる複数のプラットフォームプログラムに対応し、該プラットフォームプログラムに基づく各機能とデータの授受を行なうための複数のインタフェースの機能を各実現するように構成されており、
   前記システムマネージャプログラムは、前記プラットフォームプログラムとインタフェースを共有して、前記ミドルウェアプログラムとデータの授受を行うように構成されており、
   前記制御部は、
   前記ミドルウェアプログラムに基づき、実行されるアプリケーションプログラム及び前記コンピュータプログラムに含まれるプラットフォームプログラムに応じて、異なるインタフェースの内から静的に選択されたインタフェースによりデータの授受を行ない、
   前記システムマネージャプログラムに基づき、動作すべき前記一又は複数のアプリケーション、前記プラットフォームプログラムに基づく各機能、及び前記ミドルウェアプログラムに基づく各機能を指示し、前記一又は複数のアプリケーションの実行状態、前記プラットフォームプログラムに基づく各機能の実行状態、及び前記ミドルウェアプログラムに基づく各機能の実行状態を検出する
   ことを特徴とする制御装置。
2. 前記制御部は、
   前記ミドルウェアプログラムに基づき、
   実行されるアプリケーション、又は前記プラットフォームプログラムに基づく機能に対応して機能を選択すること
   を特徴とする請求項１に記載の制御装置。
3. 前記制御部は、
   前記ミドルウェアプログラムに基づき、
   前記プラットフォームプログラムに基づく機能により授受されるデータの内、前記一又は複数のアプリケーションへ渡すべきデータを選択し、
   前記一又は複数のアプリケーションにより授受されるデータの前記プラットフォームプログラムに基づく各機能の内の出力先を選択すること
   を特徴とする請求項１又は２に記載の制御装置。
4. 前記制御部は、
   前記ミドルウェアプログラムに基づき、
   実行させるべきアプリケーションを指示する情報、実行中の一又は複数のアプリケーションの機能を識別する情報、又はアプリケーションの実行状態を示す状態情報を、前記アプリケーション又は前記プラットフォームプログラムに基づく各機能との間で授受する機能を実現させること
   を特徴とする請求項１乃至３のいずれかに記載の制御装置。

Images