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

Abstract

【課題】プラットフォームプログラム全体を改変することなく再利用性を向上させて開発過程の短縮化、開発負荷の削減を図ることができる制御装置、制御方法及びコンピュータプログラムを提供する。
【解決手段】プラットフォームプログラムに基づくプラットフォーム層１０８における機能を、ハードウェア資源の論理的な制御を行なうリソースマネージャ層１０８ａと、ハードウェア資源自体に依存する物理的制御を行なうリソースコントローラ層１０８ｂとに分離する。リソースマネージャ層１０８ａは、アプリケーションプログラムから必要となるデータを特定すればよく、実際に何れの記憶部のいずれのアドレスに存在するかを知る必要はなく、リソースコントローラ層１０８ｂにて把握しており、リソースマネージャ層１０８ａから指示されたデータを物理的に読み出して応答する。
【選択図】図２

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 (5)

1. 一又は複数のアプリケーションプログラムを実行する第１実行手段と、前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラムを実行する第２実行手段とを備える制御装置において、
   第２実行手段は、
   アプリケーションプログラムからの要求に対応して前記ハードウェア資源からの情報取得指示、又は前記ハードウェア資源への動作指示を行なう指示手段と、
   該手段からの指示に応じて前記ハードウェア資源に対するデータの入出力を制御する制御手段と
   を備え、
   前記制御手段は、複数の機能実行手段を備えること
   を特徴とする制御装置。
2. 前記機能実行手段の一は、
   動作指示に対応するハードウェア資源が存在するか否かを判断する手段と、
   存在しないと判断した場合、前記ハードウェア資源における動作をエミュレートし、前記指示手段へ応答する手段と
   を備えることを特徴とする請求項１に記載の制御装置。
3. 第１実行手段にて実行されるべきアプリケーションプログラムの指示、第２実行手段における前記指示手段及び制御手段にて実行されるべき機能の指示、又は、前記第１及び第２実行手段におけるアプリケーションプログラム及び各機能の実行状態の検出を行なう手段を更に備えること
   を特徴とする請求項１又は２に記載の制御装置。
4. 一又は複数のアプリケーションプログラムを実行し、前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラムを実行することにより、前記ハードウェア資源の制御を行なう方法において、
   プラットフォームプログラムの処理により、
   アプリケーションプログラムからの要求に対応して前記ハードウェア資源への情報取得指示又は前記ハードウェア資源への動作指示、及び前記ハードウェア資源に対するデータの入出力の制御を夫々独立に実行し、
   更に、データの入出力の制御を、ハードウェア資源夫々に応じて独立的に行なう
   ことを特徴とする制御方法。
5. コンピュータに、一又は複数のアプリケーションプログラムを実行させた場合に、該アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御させるコンピュータプログラムであって、
   所定の機能単位で分離された複数のプログラム部品を含み、
   各プログラム部品は、
   コンピュータに、
   アプリケーションプログラムからの要求に対応して前記ハードウェア資源からの情報取得指示、又は前記ハードウェア資源への動作指示を行なう機能、及び
   ハードウェア資源に対するデータの入出力を制御する機能
   を夫々実現させることを特徴とするコンピュータプログラム。

Images