プログラム変更方法及びコンピュータプログラム
【課題】多様な要求仕様に柔軟に対応した制御を可能とし、且つ各プログラムの再利用性を向上させて開発過程の短縮化、開発負荷の削減を図ることができるプログラム変更方法及びコンピュータプログラムを提供する。
【解決手段】アプリケーション層、及びプラットフォーム層において実現される各機能は、機能又は役割などの属性が関連付けられた詳細な機能を実現するコンポーネントの集合対である機能フレームワークが構成されることで実現する。属性情報は複数有してもよく、機能フレームワークを構成する際に、属性情報の選択の仕方により多様な仕様に応じた機能フレームワークの構成が可能となる。
【解決手段】アプリケーション層、及びプラットフォーム層において実現される各機能は、機能又は役割などの属性が関連付けられた詳細な機能を実現するコンポーネントの集合対である機能フレームワークが構成されることで実現する。属性情報は複数有してもよく、機能フレームワークを構成する際に、属性情報の選択の仕方により多様な仕様に応じた機能フレームワークの構成が可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータプログラムに基づき各種制御を行なう制御装置に関する。特に、コンピュータプログラムを種々の機能をその属性に基づき選択、組み合わせ可能に構成することにより、多様な要求仕様に柔軟に対応した制御を可能とし、且つ各プログラムの再利用性を向上させて開発過程の短縮化、開発負荷の削減を図ることができるプログラム変更方法及びコンピュータプログラムに関する。
【背景技術】
【０００２】
近年では、種々の制御を行なう制御装置に通信機能を備えさせて複数接続し、各制御装置に夫々機能を割り振って相互にデータを交換し、連携して多様な処理を行なわせるシステムが各分野で利用されている。例えば、車両に配される車載ＬＡＮ（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）に相当するリソースコントローラとを含む。
【００２９】
システムマネージャプログラム１９は、ＣＰＵ１１によって実行されるアプリケーションプログラム１７，１７，…に基づく処理、プラットフォームプログラム１８に基づく処理、及び、システムマネージャプログラム１９に基づく処理の全体を、ＥＣＵ１として機能すべき状況に対応させて制御させるためのプログラムである。例えば、ＥＣＵ１が出荷前のテスト段階における動作をすべきなのか、運用中における動作をすべきなのか、又はメンテナンス中における動作をすべきなのかなどの状況の違いに応じて、各プログラムに基づく処理を切り替える機能を実現する。又は、ＥＣＵ１が日本国仕様の車両、又は北米仕様の車両に対応すべきなのかに応じて各プログラムに基づく処理を切り替える機能を実現する。また例えば、実行されているアプリケーションプログラム１７，１７，…に応じてハードウェア資源の物理的制御方法を変化させるなどの機能を実現する。
【００３０】
図２は、本実施の形態におけるＥＣＵ１のＣＰＵ１１が実現する機能を概念的に説明する説明図である。ＣＰＵ１１は、ＲＯＭ１２に記憶されている制御プログラム１ＰをＲＡＭ１３に読み出して実行する。制御プログラム１Ｐは上述のようにアプリケーションプログラム１７，１７，…、プラットフォームプログラム１８、及びシステムマネージャプログラム１９を含む。ＣＰＵ１１は、制御プログラム１Ｐに含まれる各プログラムに基づき、大きくはアプリケーション層１０７、プラットフォーム層１０８の２つの階層に分けられたソフトウェア構造にて動作する。更に、プラットフォーム層１０８と同等の階層にてシステムマネージャ１０９として動作する。
【００３１】
アプリケーション層１０７と、プラットフォーム層１０８とはプラットフォームインタフェース１０８ｃにて接続され、アプリケーション層１０７プラットフォームインタフェース１０８ｃが呼び出されることにより処理要求、又は情報の受け渡しが可能である。
【００３２】
アプリケーション層１０７では、ＣＰＵ１１はアプリケーションプログラム１７，１７，…に基づき、特有の機能を実現させるための各種アプリとして機能する。各アプリケーションプログラム１７，１７，…にて実行されるアプリは、アプリにて実現される機能の対象、又は役割等によって分離された複数のコンポーネントからなる機能フレームワークとして構成される。図２に示す例では、プラットフォーム層１０８側から得られるデータ（信号）を解釈する機能を実現するコンポーネントの集合体である信号解釈フレームワーク１７１が含まれる。また、各種制御対象のオン・オフなどの条件判定の機能を実現するコンポーネントの集合体である入力条件判定フレームワーク１７２、アクチュエータ４（負荷）を制御するための機能を実現するコンポーネントの集合体である負荷制御フレームワーク１７３がアプリケーション層１０７に含まれる。
【００３３】
プラットフォーム層１０８では、ＣＰＵ１１によりプラットフォームプログラム１８に基づきハードウェア群１４，１５，１６，…を実際に制御する処理が行なわれる。例えば、記憶部１４との間のデータの読み書き、通信部１５とのデータの受け渡しなどの各機能が実現される。プラットフォーム層１０８は、記憶部１４からどのデータを読み出すかを指示するなど論理的なアクセスを実行する機能が実現されるリソースマネージャ層１０８ａと、実際に送信するデータを通信部１５のＩ／Ｏメモリに書き込むなど物理的アクセスを実行する機能が実現されるリソースコントローラ層１０８ｂとに更に内部で階層化される。
【００３４】
プラットフォーム層１０８においても、ハードウェア資源を制御する各機能は、機能の対象、又は役割等によって分離された複数のコンポーネントからなる機能フレームワークにて夫々実現される。図２に示す例では、リソースマネージャ層１０８ａに、記憶部１４などのメモリの読み書きについては、メモリから何れのデータを読み出すのか、何れのデータを書き込むのかを、アプリケーション層１０７からの要求に応じて決定する機能を実現するコンポーネントの集合体であるメモリ管理フレームワーク１８１ａが含まれる。その他、通信部１５へのデータの送信指示等を行なう通信管理機能を実現するコンポーネントの集合体である通信管理フレームワーク１８２ａが含まれる。また、その他Ｉ／Ｏデバイスに対するデータの入出力を管理する機能を実現するコンポーネントの集合体である実現するＩ／Ｏ管理フレームワーク１８３ａが含まれる。
【００３５】
リソースコントローラ層１０８ｂには、メモリ管理フレームワーク１８１ａからの指示に基づき、データのメモリ中におけるアドレスを特定して実際にデータを読み出し、データを実際に書き込むメモリ制御機能を実現するコンポーネントの集合体であるメモリ制御フレームワーク１８１ｂが含まれる。その他、リソースコントローラ層１０８ｂには、実際に通信部１５へのデータの入出力を行なう通信制御機能を実現するコンポーネントの集合体である通信制御フレームワーク１８２ｂが含まれる。また、その他Ｉ／ＯデバイスのＩ／Ｏメモリに実際にアクセスして入出力機能を実現するコンポーネントの集合体である実現するＩ／Ｏ制御フレームワーク１８３ｂが含まれる。
【００３６】
更に、ＣＰＵ１１がシステムマネージャプログラム１９を読み出して実行することにより、システムマネージャ１０９の機能がプラットフォーム層１０８とインタフェースを共有して実現される。システムマネージャ１０９は、アプリケーション層１０７及びプラットフォーム層１０８の両方にわたって、各層にて機能する各種フレームワークにおいて起動しているコンポーネントにおける実行状態を検出し、情報を保持するシステム監視機能１１１、ＥＣＵ１が搭載される車両の車種、仕向地、グレード、ＥＣＵ１の機能の切り替えに応じて各層の各種フレームワークから何れの機能のコンポーネントを起動させるかなどを指示する機能管理１１２を実現する。なお、システムマネージャ１０９は図２に示すようなプラットフォーム層１０８とインタフェースを共有する構成のみならず、各層の機能と直接的に情報を授受できる構成としてもよい。
【００３７】
次に、図２に示したような各機能を実現するための各種フレームワークの例を挙げて説明する。アプリケーションプログラム１７，１７，…、プラットフォームプログラム１８はいずれも、以下の図３及び図４に示すように各機能を詳細に分離させたコンポーネントに相当するプログラムモジュールを組み合わせて実装してある。更に、各コンポーネントに相当するプログラムモジュールには属性情報を関連付け、コンポーネントの集合体であるフレームワークとして動作することを可能とし、各コンポーネントを選択的に実行させることができるように構成してある。
【００３８】
図３は、アプリケーション層１０７に含まれるフレームワークとフレームワークを構成するコンポーネントの内容例を示す説明図である。図３に示すように、例えば入力条件判定フレームワーク１７２は、ハードウェア資源から情報を提供する機能を実現する内部情報提供コンポーネント、各ワイパーへの入力の条件判定機能を実現するワイパー系コンポーネント等からなる。また、入力条件判定フレームワーク１７２を構成する各コンポーネントも夫々、複数のコンポーネントからなるフレームワークとして構成される。内部情報提供コンポーネントは、セキュリティ状態を通知する機能を実現するセキュリティ状態コンポーネント等からなる内部情報提供フレームワークを構成する。ワイパー系コンポーネントもワイパーの種類別に機能を実現するオートワイパーコンポーネントなどからなり、ワイパー系フレームワークを構成する。このように、各フレームワークは階層的構造をなす。
【００３９】
そして本実施の形態におけるアプリケーションプログラム１７，１７，…及びプラットフォームプログラム１８にて実現される各コンポーネントには各機能の対象、各機能にて実現される動作など、機能又は役割を含む複数の属性情報が関連付けられている。例えば、図３に示す例では、内部情報提供コンポーネントは、機能属性として「内部情報提供」が関連付けられ、役割属性として「内部情報取得」が関連付けられた構成としてある。また、例えば、内部情報提供フレームワークを構成するセキュリティ状態コンポーネントは、機能属性として「セキュリティ」、役割属性として「セキュリティ状態監視」、仕様として「なし／北米／欧州／日本」といった各仕向地仕様が関連付けられている。なお、具体的には、各フレームワークを実現するプログラムモジュールを識別する情報と、各属性情報とが関連付けられてＲＯＭ１２に記憶されており、ＣＰＵ１１から識別することが可能である。
【００４０】
また、属性情報によって各コンポーネントを管理することが可能である。図４は、プラットフォーム層１０８に含まれるフレームワークとフレームワークを構成するコンポーネントの内容例を示す説明図である。図２にて示した通信管理フレームワーク１８２ａは、一のコンポーネントとして通信プロトコルの一つであるＣＡＮに基づく通信を管理する機能を実現するＣＡＮ管理コンポーネントを含む。通信制御フレームワーク１８２ｂは、一のコンポーネントとしてＣＡＮプロトコルに準じた通信モジュールを制御する機能を実現するＣＡＮ制御コンポーネントを含む。ＣＡＮ管理コンポーネントは、図４に示すように、受信状態監視する機能を実現する受信状態監視コンポーネント、送信フレームを作成する機能を実現する送信フレーム作成コンポーネント等のコンポーネントからなるＣＡＮ管理フレームワークとして構成される。ＣＡＮ制御コンポーネントも、図４に示すように、受信割込み機能を実現する受信割込コンポーネント、ＣＡＮコントローラを物理的に制御する機能を実現するＣＡＮコントローラコンポーネントからなるＣＡＮ制御フレームワークとして構成される。
【００４１】
図４に示す例では、ＣＡＮ管理フレームワークを構成する各コンポーネントの役割属性は、いずれも「ＣＡＮ管理」である。即ち、ＣＡＮ管理フレームワークは、「ＣＡＮ管理」の役割属性が関連付けられたコンポーネントから構成される。同様にＣＡＮ制御フレームワークを構成する各コンポーネントの役割属性は、いずれも「ＣＡＮ制御」であり、ＣＡＮ制御フレームワークは、「ＣＡＮ制御」の役割属性が関連付けられたコンポーネント群から構成される。また、ＣＡＮ管理フレームワーク及びＣＡＮ制御フレームワークを夫々構成する各コンポーネントは、機能属性としていずれも「ＣＡＮ通信」が関連付けられている。これにより、図４に示す例では、「ＣＡＮ通信」なる機能属性を共通とするコンポーネントは、「ＣＡＮ通信フレームワーク」をも構成する。
【００４２】
このように、各コンポーネントは複数のフレームワークに属することも可能である。つまり、同一の機能を実現するコンポーネントを他の機能を実現するコンポーネントのために再利用することが可能となる。また、図４に示す例では、各コンポーネントは機能、役割のみならず、仕様又は動作の種別等の属性も関連付けられている。したがって、属性情報として動作の種別、例えば「受信」にて各コンポーネントを対応付けるとすれば、受信状態監視コンポーネントと、受信割込コンポーネントとからなる「受信フレームワーク」などのように各コンポーネントを対応付けて新たな機能を実現するフレームワークとして構築することも可能である。
【００４３】
次に、各フレームワーク及びコンポーネント間の階層的な構造を図を参照して説明する。図５は、アプリケーション層１０７に含まれる入力条件判定フレームワーク１７２の階層構造を概念的に示す説明図である。入力条件判定フレームワーク１７２は、ハードウェア資源における状態などの情報を提供する機能を実現する内部情報提供コンポーネント７１、ドアロック制御に関する各種機能を実現するドアロック系コンポーネント７２、ライト制御に関する各種機能を実現するライト系コンポーネント７３、ワイパー制御に関する各種機能を実現するワイパー系コンポーネント７４からなる。
【００４４】
また、各コンポーネント７１，７２，７３，７４は夫々更に、階層的にフレームワークとして構成されており、詳細な機能を実現するコンポーネントからなる。例えば、内部情報提供コンポーネント７１は、セキュリティ状態を通知するセキュリティ状態コンポーネント７１１、ヘッドライトスイッチ（ＳＷ）のオン／オフ状態をアプリケーション層１０７へ入力するヘッドライトＳＷ入力コンポーネント７１２、エンジンスタータの状態を通知するエンジンスタータコンポーネント７１３、フロントワイパーの状態をアプリケーション層１０７へ入力するフロントワイパー入力コンポーネント７１４などからなる内部情報提供フレームワーク７１０として構成される。同様にしてライト系コンポーネント７３は、ヘッドライト（Ｌｏｗ）、ヘッドライト（Ｈｉｇｈ）、スモールライト、インテリアライト、及びターンライト夫々への入力条件を判定するヘッドライト（Ｌｏｗ）コンポーネント７３１、ヘッドライト（Ｈｉｇｈ）コンポーネント７３２、スモールライトコンポーネント７３３、インテリアライトコンポーネント７３４、及びターンライトコンポーネント７３５などからなるライト系フレームワーク７３０として構成される。ワイパー系コンポーネント７４は、フロントワイパー、オートワイパー、フロントウォッシャー、リアウォッシャー、及びリアワイパー夫々への入力条件を判定するフロントワイパーコンポーネント７４１、オートワイパーコンポーネント７４２、フロントウォッシャーコンポーネント７４３、リアウォッシャーコンポーネント７４４、及びリアワイパーコンポーネント７４５などからなるワイパー系フレームワーク７４０として構成される。
【００４５】
図５に示したように、アプリケーション層１０７における各フレームワークは、機能によって区分されるドメインにて識別され、階層的にコンポーネントを有する。
【００４６】
図６は、プラットフォーム層１０８に含まれる通信管理フレームワーク１８２ａ及び通信制御フレームワーク１８２ｂの階層構造を概念的に示す説明図である。通信管理フレームワーク１８２ａは、ＵＡＲＴ（Universal Asynchronous Receiver Transmitter）の管理機能を実現するＵＡＲＴ管理コンポーネント８１、ＣＡＮ通信機能を実現するＣＡＮ管理コンポーネント８２、ＬＩＮ通信機能を実現するＬＩＮ管理コンポーネント８３、その他のプロトコルによる通信機能を実現するその他（拡張）管理コンポーネント８４からなる。また、通信制御フレームワーク１８２ｂは、ＵＡＲＴの制御を実現するＵＡＲＴ制御コンポーネント８５、ＬＩＮコントローラの制御機能を実現するＬＩＮ制御コンポーネント８６、ＣＡＮコントローラの制御機能を実現するＣＡＮ制御コンポーネント８７、その他のプロトコルによる通信コントローラの制御機能を実現するその他（拡張）制御コンポーネント８８からなる。
【００４７】
そしてＣＡＮ管理コンポーネント８２は、受信フレーム解析機能を実現する受信フレーム解析コンポーネント８２１、受信状態監視機能を実現する受信状態監視コンポーネント８２２、フェール処理機能を実現するフェール処理コンポーネント８２３、送信フレーム作成機能を実現する送信フレーム作成コンポーネント８２４、定期送信を実現する定期送信コンポーネント８２５からなるＣＡＮ管理フレームワーク８２０を構成する。ＣＡＮ制御コンポーネント８７は、受信処理機能を実現する受信処理コンポーネント８７１、受信割込機能を実現する受信割込コンポーネント８７２、ＣＡＮコントローラを制御するＣＡＮコントローラコンポーネント８７３、送信割込機能を実現する送信割込コンポーネント８７４、送信処理機能を実現する送信処理コンポーネント８７５からなるＣＡＮ制御フレームワーク８７０を構成する。そして、ＣＡＮ管理フレームワーク８２０及びＣＡＮ制御フレームワーク８７０はいずれも、コンポーネントとして「ＣＡＮ通信」なる機能属性を共通とするので、ＣＡＮ通信フレームワーク９を構成する。
【００４８】
図５及び図６に示したような各フレームワーク及び各コンポーネントは、上位層のコンポーネントが下位層のコンポーネントに、システムマネージャ１０９からの指示に従っていずれかに起動要求を通知し、起動要求に応じて各コンポーネントが状態変化したことを上位層のコンポーネントに通知するという階層的構造にて動作するようにしてある。これにより、各機能を選択的に実現させることができ、不要な機能は動作を停止させるなど、効率的な制御が可能である。つまり、例えば入力条件判定フレームワーク１７２により、内部情報提供コンポーネント７１、ドアロック系コンポーネント７２、ライト系コンポーネント７３、ワイパー系コンポーネント７４のいずれかへ起動要求がされ、各コンポーネントから状態が通知されることにより、各機能の動作が入力条件判定フレームワーク１７２によって管理される。
【００４９】
図３乃至図６に示したように、アプリケーション層１０７と、プラットフォーム層１０８とでは、夫々に含まれるコンポーネントの属性情報は異なる。しかしながら、各々で属性情報に基づき、アプリケーション層１０７及びプラットフォーム層１０８夫々での各フレームワークによって実現される機能は明確に分類され、対応する集合体として扱われる。また、各コンポーネントは属性情報によって特定の機能を実現する要素として対応付けられるので、一つの属性情報によってその機能の追加・削除を容易に変更可能である。例えば、図４及び図６に示したＣＡＮ管理コンポーネント（フレームワーク）８２（８２０）及びＣＡＮ制御コンポーネント（フレームワーク）８７（８７０）は、ＣＡＮ通信フレームワーク９を構成しているが、ＥＣＵ１においてＣＡＮ通信に対応する必要がなくなった場合、削除対象のコンポーネントの属性情報として「ＣＡＮ通信」を選択することにより、ＣＡＮ通信を属性情報に持つコンポーネントからなるＣＡＮ通信フレームワーク９をまとめて機能しないように制御することができる。したがって、各層において属性情報によって機能の抜き差しが可能となり、いずれの機能（属性）を基準とするか、役割（属性）を基準とするか、その他の属性情報を基準とするかによって、フレームワークの構成を変更することが容易となる。
【００５０】
次に、ＥＣＵ１におけるアプリケーション層１０７と、プラットフォーム層１０８とで機能構成の変更が容易に可能であることをフローチャートを参照して説明する。
【００５１】
図７は、属性情報の選択によって、ＥＣＵ１の機能構成が変更される処理手順の一例を示すフローチャートである。なお、本処理は例えば、要求仕様の変更に伴ってアプリケーションプログラム１７，１７，…、プラットフォームプログラム１８、システムマネージャプログラム１９をリンクさせる際に、コンパイラなどによって実行される。
【００５２】
要求仕様の変更に伴い、制御ロジックに基づいて必要となる各機能に対応する属性情報が選択される（ステップＳ１）。アプリケーションプログラム１７，１７，…、プラットフォームプログラム１８に含まれる各フレームワーク及びコンポーネントに関連付けられた属性情報が参照される（ステップＳ２）。
【００５３】
ステップＳ１にて必要となる各機能に応じて選択された属性情報を共通する属性とするコンポーネントに相当するプログラムモジュールが、アプリケーションプログラム１７，１７，…及びプラットフォームプログラム１８から夫々選択される（ステップＳ３）。選択されたプログラムモジュールは共通する属性情報にて対応付けられ（ステップＳ４）、処理が終了される。
【００５４】
このような処理により、ＥＣＵ１の機能構成が容易に要求仕様に従って再構築可能である。
【００５５】
更に属性情報にはアプリケーション層１０７と、プラットフォーム層１０８との異なるソフトウェア階層間での関連を示す各フレームワーク間のリンク情報が含まれることが望ましい。図８は、各層における機能フレームワークの属性情報にリンク情報が含まれる場合の構成の例を示す説明図である。
【００５６】
図８の例では、アプリケーション層１０７、プラットフォーム層１０８におけるリソースマネージャ層１０８ａ及びリソースコントローラ層１０８ｂにて夫々選択されて構築された各コンポーネントが示されている。アプリケーション層１０７では、オートドアロック、とじこみ防止機能などドアロック関連の機能を実現するドアロックフレームワーク、各ライトの制御を実現するライト系フレームワーク７３０、及び車両の故障状況の診断機能を実現する診断フレームワークが動作するように構成されている。図８に示す例では、診断フレームワークに含まれる外部故障診断コンポーネントの属性情報として、以下のような情報が関連付けられている。機能属性として「診断」、役割属性として「外部故障診断」、リンク属性として「ＵＡＲＴ管理／Ｋ−ＬＩＮＥ」が関連付けられている。つまり、アプリケーション層１０７における外部故障診断コンポーネントには、プラットフォーム層１０８において「ＵＡＲＴ管理」及び「Ｋ−ＬＩＮＥ」が機能属性及び役割属性として関連付けられているコンポーネント、即ちリソースマネージャ層１０８ａのＫ−ＬＩＮＥコンポーネントと関連関係があることを示している。ここで、ＵＡＲＴ、Ｋ−ＬIＮＥはいずれも、ＥＣＵ１又は他のＥＣＵに接続される外部故障診断機器との通信ラインである。外部故障診断機能を実現するためには、関連してＵＡＲＴ管理又はＫ−ＬＩＮＥ管理の機能が必要となることから、関連関係がある。
【００５７】
プラットフォーム層１０８におけるリソースマネージャ層１０８ａでは、メモリ管理フレームワーク１８１ａ、通信管理フレームワーク１８２ａ、Ｉ／Ｏ管理フレームワーク１８３ａの他、リソース監視フレームワークなどが動作するように構成されている。通信管理フレームワーク１８２ａにはＵＡＲＴ管理コンポーネント（フレームワーク）８１が含まれている。更に、ＵＡＲＴ管理フレームワークはＫ−ＬＩＮＥコンポーネントを含む。Ｋ−ＬＩＮＥコンポーネントには属性情報として、以下のような情報が関連付けられている。機能属性として「ＵＡＲＴ管理」、役割属性として「Ｋ−ＬＩＮＥ」、リンク属性として「診断／外部故障診断／ＵＡＲＴ制御／ＵＡＲＴ ＣＨ１」が関連付けられている。つまり、リソースマネージャ層１０８ａにおけるＫ−ＬＩＮＥコンポーネントには、アプリケーション層１０７において「診断」及び「外部故障診断」が機能属性及び役割属性として関連付けられているコンポーネント、即ちアプリケーション層１０７の外部故障診断コンポーネントと関連関係があることを示している。また、Ｋ−ＬＩＮＥコンポーネントには、リソースコントローラ１０８ｂにおいて「ＵＡＲＴ制御」及び「ＵＡＲＴ ＣＨ１」が機能属性及び役割属性として関連付けられているコンポーネント、即ちリソースマネージャ層１０８ａのＫ−ＬＩＮＥコンポーネントは、リソースコントローラ層１０８ｂのＵＡＲＴ ＣＨ１コンポーネントと関連関係があることを示している。
【００５８】
プラットフォーム層１０８におけるリソースコントローラ層１０８ｂでは、メモリ制御フレームワーク１８１ｂ、通信制御フレームワーク１８２ｂ、Ｉ／Ｏ制御フレームワーク１８３ｂの他、存在しないハードウェアの動作をエミュレータして応答する仮想化フレームワークが動作するように構成されている。通信制御フレームワーク１８２ｂには、ＵＡＲＴ制御コンポーネント（フレームワーク）８５が含まれている。更に、ＵＡＲＴ制御フレームワークはＵＡＲＴ ＣＨ１コンポーネントを含む。ＵＡＲＴ ＣＨ１コンポーネントには属性情報として、以下のような情報が関連付けられている。機能属性として「ＵＡＲＴ制御」、役割属性として「ＵＡＲＴ ＣＨ１」、リンク属性として「ＵＡＲＴ管理／Ｋ−ＬＩＮＥ」が関連付けられている。ＵＡＲＴ ＣＨ１コンポーネントは、ＵＡＲＴのＣＨ１による通信を制御する機能を実現するものである。そして、ＵＡＲＴ ＣＨ１コンポーネントは、リソースマネージャ層１０８ａにおいて「ＵＡＲＴ管理」及び「Ｋ−ＬＩＮＥ」が機能属性及び役割属性として関連付けられているコンポーネント、即ちＫ−ＬＩＮＥコンポーネントと関連関係があることを示している。
【００５９】
ここで例えば、外部診断機能機器など外部機器との接続が不要になった場合、アプリケーション層１０７において外部故障診断フレームワークが動作しないように削除するとする。このとき、外部故障診断フレームワークとリンクしているリソースマネージャ層１０８ａのＫ−ＬＩＮＥコンポーネント、及び更にＫ−ＬＩＮＥコンポーネントとリンクしているリソースコントローラ層１０８ｂのＵＡＲＴ ＣＨ１コンポーネントをいずれも削除して、一括して機能しないように構築し直すなどが可能となる。このように、属性情報に含まれるリンク属性により、ソフトウェア構造の階層にわたって各機能間の対応付けを可能とすることにより、各機能の連動的な抜き差しが容易に可能となり、多様な要求仕様に対応させることができる点、優れた効果を奏する。
【００６０】
このような構成により、以下のような効果を奏する。例えば、ある仕様では、通信管理機能としては状態監視機能まで含まれることが要求される一方で、他の仕様では、状態監視機能はアプリケーション層１０７における機能によって実現されればよい場合がある。本実施の形態の構成では、そのような仕様の変更に応じた各機能の具体的要素の組み合わせを自在とすることができ、容易にＥＣＵ１における機能構成を幅広いバリエーションにて変更することが可能となり、様々な仕様要求に容易に対応させることが可能となる。このように、一のプログラムでも種々の仕様に柔軟に対応できるので、プログラムの再利用性が向上し、開発過程の短縮化、開発負荷の削減を図ることができる。
【００６１】
上述に示した実施の形態では、本発明は車両に搭載されるＥＣＵに適用される例を示した。しかしながら本発明はこれに限らず、種々の制御を行なうコンピュータ装置全般に適用することができる。
【００６２】
なお、上述のように開示された本実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【００６３】
１ ＥＣＵ
１０ マイコン
１１ ＣＰＵ
１２ ＲＯＭ
１７，１７ アプリケーションプログラム
１８ プラットフォームプログラム
１９ システムマネージャプログラム
１０７ アプリケーション層
１０８ プラットフォーム層
１０８ａ リソースマネージャ層
１０８ｂ リソースコントローラ層
１０９ システムマネージャ
【技術分野】
【０００１】
本発明は、コンピュータプログラムに基づき各種制御を行なう制御装置に関する。特に、コンピュータプログラムを種々の機能をその属性に基づき選択、組み合わせ可能に構成することにより、多様な要求仕様に柔軟に対応した制御を可能とし、且つ各プログラムの再利用性を向上させて開発過程の短縮化、開発負荷の削減を図ることができるプログラム変更方法及びコンピュータプログラムに関する。
【背景技術】
【０００２】
近年では、種々の制御を行なう制御装置に通信機能を備えさせて複数接続し、各制御装置に夫々機能を割り振って相互にデータを交換し、連携して多様な処理を行なわせるシステムが各分野で利用されている。例えば、車両に配される車載ＬＡＮ（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）に相当するリソースコントローラとを含む。
【００２９】
システムマネージャプログラム１９は、ＣＰＵ１１によって実行されるアプリケーションプログラム１７，１７，…に基づく処理、プラットフォームプログラム１８に基づく処理、及び、システムマネージャプログラム１９に基づく処理の全体を、ＥＣＵ１として機能すべき状況に対応させて制御させるためのプログラムである。例えば、ＥＣＵ１が出荷前のテスト段階における動作をすべきなのか、運用中における動作をすべきなのか、又はメンテナンス中における動作をすべきなのかなどの状況の違いに応じて、各プログラムに基づく処理を切り替える機能を実現する。又は、ＥＣＵ１が日本国仕様の車両、又は北米仕様の車両に対応すべきなのかに応じて各プログラムに基づく処理を切り替える機能を実現する。また例えば、実行されているアプリケーションプログラム１７，１７，…に応じてハードウェア資源の物理的制御方法を変化させるなどの機能を実現する。
【００３０】
図２は、本実施の形態におけるＥＣＵ１のＣＰＵ１１が実現する機能を概念的に説明する説明図である。ＣＰＵ１１は、ＲＯＭ１２に記憶されている制御プログラム１ＰをＲＡＭ１３に読み出して実行する。制御プログラム１Ｐは上述のようにアプリケーションプログラム１７，１７，…、プラットフォームプログラム１８、及びシステムマネージャプログラム１９を含む。ＣＰＵ１１は、制御プログラム１Ｐに含まれる各プログラムに基づき、大きくはアプリケーション層１０７、プラットフォーム層１０８の２つの階層に分けられたソフトウェア構造にて動作する。更に、プラットフォーム層１０８と同等の階層にてシステムマネージャ１０９として動作する。
【００３１】
アプリケーション層１０７と、プラットフォーム層１０８とはプラットフォームインタフェース１０８ｃにて接続され、アプリケーション層１０７プラットフォームインタフェース１０８ｃが呼び出されることにより処理要求、又は情報の受け渡しが可能である。
【００３２】
アプリケーション層１０７では、ＣＰＵ１１はアプリケーションプログラム１７，１７，…に基づき、特有の機能を実現させるための各種アプリとして機能する。各アプリケーションプログラム１７，１７，…にて実行されるアプリは、アプリにて実現される機能の対象、又は役割等によって分離された複数のコンポーネントからなる機能フレームワークとして構成される。図２に示す例では、プラットフォーム層１０８側から得られるデータ（信号）を解釈する機能を実現するコンポーネントの集合体である信号解釈フレームワーク１７１が含まれる。また、各種制御対象のオン・オフなどの条件判定の機能を実現するコンポーネントの集合体である入力条件判定フレームワーク１７２、アクチュエータ４（負荷）を制御するための機能を実現するコンポーネントの集合体である負荷制御フレームワーク１７３がアプリケーション層１０７に含まれる。
【００３３】
プラットフォーム層１０８では、ＣＰＵ１１によりプラットフォームプログラム１８に基づきハードウェア群１４，１５，１６，…を実際に制御する処理が行なわれる。例えば、記憶部１４との間のデータの読み書き、通信部１５とのデータの受け渡しなどの各機能が実現される。プラットフォーム層１０８は、記憶部１４からどのデータを読み出すかを指示するなど論理的なアクセスを実行する機能が実現されるリソースマネージャ層１０８ａと、実際に送信するデータを通信部１５のＩ／Ｏメモリに書き込むなど物理的アクセスを実行する機能が実現されるリソースコントローラ層１０８ｂとに更に内部で階層化される。
【００３４】
プラットフォーム層１０８においても、ハードウェア資源を制御する各機能は、機能の対象、又は役割等によって分離された複数のコンポーネントからなる機能フレームワークにて夫々実現される。図２に示す例では、リソースマネージャ層１０８ａに、記憶部１４などのメモリの読み書きについては、メモリから何れのデータを読み出すのか、何れのデータを書き込むのかを、アプリケーション層１０７からの要求に応じて決定する機能を実現するコンポーネントの集合体であるメモリ管理フレームワーク１８１ａが含まれる。その他、通信部１５へのデータの送信指示等を行なう通信管理機能を実現するコンポーネントの集合体である通信管理フレームワーク１８２ａが含まれる。また、その他Ｉ／Ｏデバイスに対するデータの入出力を管理する機能を実現するコンポーネントの集合体である実現するＩ／Ｏ管理フレームワーク１８３ａが含まれる。
【００３５】
リソースコントローラ層１０８ｂには、メモリ管理フレームワーク１８１ａからの指示に基づき、データのメモリ中におけるアドレスを特定して実際にデータを読み出し、データを実際に書き込むメモリ制御機能を実現するコンポーネントの集合体であるメモリ制御フレームワーク１８１ｂが含まれる。その他、リソースコントローラ層１０８ｂには、実際に通信部１５へのデータの入出力を行なう通信制御機能を実現するコンポーネントの集合体である通信制御フレームワーク１８２ｂが含まれる。また、その他Ｉ／ＯデバイスのＩ／Ｏメモリに実際にアクセスして入出力機能を実現するコンポーネントの集合体である実現するＩ／Ｏ制御フレームワーク１８３ｂが含まれる。
【００３６】
更に、ＣＰＵ１１がシステムマネージャプログラム１９を読み出して実行することにより、システムマネージャ１０９の機能がプラットフォーム層１０８とインタフェースを共有して実現される。システムマネージャ１０９は、アプリケーション層１０７及びプラットフォーム層１０８の両方にわたって、各層にて機能する各種フレームワークにおいて起動しているコンポーネントにおける実行状態を検出し、情報を保持するシステム監視機能１１１、ＥＣＵ１が搭載される車両の車種、仕向地、グレード、ＥＣＵ１の機能の切り替えに応じて各層の各種フレームワークから何れの機能のコンポーネントを起動させるかなどを指示する機能管理１１２を実現する。なお、システムマネージャ１０９は図２に示すようなプラットフォーム層１０８とインタフェースを共有する構成のみならず、各層の機能と直接的に情報を授受できる構成としてもよい。
【００３７】
次に、図２に示したような各機能を実現するための各種フレームワークの例を挙げて説明する。アプリケーションプログラム１７，１７，…、プラットフォームプログラム１８はいずれも、以下の図３及び図４に示すように各機能を詳細に分離させたコンポーネントに相当するプログラムモジュールを組み合わせて実装してある。更に、各コンポーネントに相当するプログラムモジュールには属性情報を関連付け、コンポーネントの集合体であるフレームワークとして動作することを可能とし、各コンポーネントを選択的に実行させることができるように構成してある。
【００３８】
図３は、アプリケーション層１０７に含まれるフレームワークとフレームワークを構成するコンポーネントの内容例を示す説明図である。図３に示すように、例えば入力条件判定フレームワーク１７２は、ハードウェア資源から情報を提供する機能を実現する内部情報提供コンポーネント、各ワイパーへの入力の条件判定機能を実現するワイパー系コンポーネント等からなる。また、入力条件判定フレームワーク１７２を構成する各コンポーネントも夫々、複数のコンポーネントからなるフレームワークとして構成される。内部情報提供コンポーネントは、セキュリティ状態を通知する機能を実現するセキュリティ状態コンポーネント等からなる内部情報提供フレームワークを構成する。ワイパー系コンポーネントもワイパーの種類別に機能を実現するオートワイパーコンポーネントなどからなり、ワイパー系フレームワークを構成する。このように、各フレームワークは階層的構造をなす。
【００３９】
そして本実施の形態におけるアプリケーションプログラム１７，１７，…及びプラットフォームプログラム１８にて実現される各コンポーネントには各機能の対象、各機能にて実現される動作など、機能又は役割を含む複数の属性情報が関連付けられている。例えば、図３に示す例では、内部情報提供コンポーネントは、機能属性として「内部情報提供」が関連付けられ、役割属性として「内部情報取得」が関連付けられた構成としてある。また、例えば、内部情報提供フレームワークを構成するセキュリティ状態コンポーネントは、機能属性として「セキュリティ」、役割属性として「セキュリティ状態監視」、仕様として「なし／北米／欧州／日本」といった各仕向地仕様が関連付けられている。なお、具体的には、各フレームワークを実現するプログラムモジュールを識別する情報と、各属性情報とが関連付けられてＲＯＭ１２に記憶されており、ＣＰＵ１１から識別することが可能である。
【００４０】
また、属性情報によって各コンポーネントを管理することが可能である。図４は、プラットフォーム層１０８に含まれるフレームワークとフレームワークを構成するコンポーネントの内容例を示す説明図である。図２にて示した通信管理フレームワーク１８２ａは、一のコンポーネントとして通信プロトコルの一つであるＣＡＮに基づく通信を管理する機能を実現するＣＡＮ管理コンポーネントを含む。通信制御フレームワーク１８２ｂは、一のコンポーネントとしてＣＡＮプロトコルに準じた通信モジュールを制御する機能を実現するＣＡＮ制御コンポーネントを含む。ＣＡＮ管理コンポーネントは、図４に示すように、受信状態監視する機能を実現する受信状態監視コンポーネント、送信フレームを作成する機能を実現する送信フレーム作成コンポーネント等のコンポーネントからなるＣＡＮ管理フレームワークとして構成される。ＣＡＮ制御コンポーネントも、図４に示すように、受信割込み機能を実現する受信割込コンポーネント、ＣＡＮコントローラを物理的に制御する機能を実現するＣＡＮコントローラコンポーネントからなるＣＡＮ制御フレームワークとして構成される。
【００４１】
図４に示す例では、ＣＡＮ管理フレームワークを構成する各コンポーネントの役割属性は、いずれも「ＣＡＮ管理」である。即ち、ＣＡＮ管理フレームワークは、「ＣＡＮ管理」の役割属性が関連付けられたコンポーネントから構成される。同様にＣＡＮ制御フレームワークを構成する各コンポーネントの役割属性は、いずれも「ＣＡＮ制御」であり、ＣＡＮ制御フレームワークは、「ＣＡＮ制御」の役割属性が関連付けられたコンポーネント群から構成される。また、ＣＡＮ管理フレームワーク及びＣＡＮ制御フレームワークを夫々構成する各コンポーネントは、機能属性としていずれも「ＣＡＮ通信」が関連付けられている。これにより、図４に示す例では、「ＣＡＮ通信」なる機能属性を共通とするコンポーネントは、「ＣＡＮ通信フレームワーク」をも構成する。
【００４２】
このように、各コンポーネントは複数のフレームワークに属することも可能である。つまり、同一の機能を実現するコンポーネントを他の機能を実現するコンポーネントのために再利用することが可能となる。また、図４に示す例では、各コンポーネントは機能、役割のみならず、仕様又は動作の種別等の属性も関連付けられている。したがって、属性情報として動作の種別、例えば「受信」にて各コンポーネントを対応付けるとすれば、受信状態監視コンポーネントと、受信割込コンポーネントとからなる「受信フレームワーク」などのように各コンポーネントを対応付けて新たな機能を実現するフレームワークとして構築することも可能である。
【００４３】
次に、各フレームワーク及びコンポーネント間の階層的な構造を図を参照して説明する。図５は、アプリケーション層１０７に含まれる入力条件判定フレームワーク１７２の階層構造を概念的に示す説明図である。入力条件判定フレームワーク１７２は、ハードウェア資源における状態などの情報を提供する機能を実現する内部情報提供コンポーネント７１、ドアロック制御に関する各種機能を実現するドアロック系コンポーネント７２、ライト制御に関する各種機能を実現するライト系コンポーネント７３、ワイパー制御に関する各種機能を実現するワイパー系コンポーネント７４からなる。
【００４４】
また、各コンポーネント７１，７２，７３，７４は夫々更に、階層的にフレームワークとして構成されており、詳細な機能を実現するコンポーネントからなる。例えば、内部情報提供コンポーネント７１は、セキュリティ状態を通知するセキュリティ状態コンポーネント７１１、ヘッドライトスイッチ（ＳＷ）のオン／オフ状態をアプリケーション層１０７へ入力するヘッドライトＳＷ入力コンポーネント７１２、エンジンスタータの状態を通知するエンジンスタータコンポーネント７１３、フロントワイパーの状態をアプリケーション層１０７へ入力するフロントワイパー入力コンポーネント７１４などからなる内部情報提供フレームワーク７１０として構成される。同様にしてライト系コンポーネント７３は、ヘッドライト（Ｌｏｗ）、ヘッドライト（Ｈｉｇｈ）、スモールライト、インテリアライト、及びターンライト夫々への入力条件を判定するヘッドライト（Ｌｏｗ）コンポーネント７３１、ヘッドライト（Ｈｉｇｈ）コンポーネント７３２、スモールライトコンポーネント７３３、インテリアライトコンポーネント７３４、及びターンライトコンポーネント７３５などからなるライト系フレームワーク７３０として構成される。ワイパー系コンポーネント７４は、フロントワイパー、オートワイパー、フロントウォッシャー、リアウォッシャー、及びリアワイパー夫々への入力条件を判定するフロントワイパーコンポーネント７４１、オートワイパーコンポーネント７４２、フロントウォッシャーコンポーネント７４３、リアウォッシャーコンポーネント７４４、及びリアワイパーコンポーネント７４５などからなるワイパー系フレームワーク７４０として構成される。
【００４５】
図５に示したように、アプリケーション層１０７における各フレームワークは、機能によって区分されるドメインにて識別され、階層的にコンポーネントを有する。
【００４６】
図６は、プラットフォーム層１０８に含まれる通信管理フレームワーク１８２ａ及び通信制御フレームワーク１８２ｂの階層構造を概念的に示す説明図である。通信管理フレームワーク１８２ａは、ＵＡＲＴ（Universal Asynchronous Receiver Transmitter）の管理機能を実現するＵＡＲＴ管理コンポーネント８１、ＣＡＮ通信機能を実現するＣＡＮ管理コンポーネント８２、ＬＩＮ通信機能を実現するＬＩＮ管理コンポーネント８３、その他のプロトコルによる通信機能を実現するその他（拡張）管理コンポーネント８４からなる。また、通信制御フレームワーク１８２ｂは、ＵＡＲＴの制御を実現するＵＡＲＴ制御コンポーネント８５、ＬＩＮコントローラの制御機能を実現するＬＩＮ制御コンポーネント８６、ＣＡＮコントローラの制御機能を実現するＣＡＮ制御コンポーネント８７、その他のプロトコルによる通信コントローラの制御機能を実現するその他（拡張）制御コンポーネント８８からなる。
【００４７】
そしてＣＡＮ管理コンポーネント８２は、受信フレーム解析機能を実現する受信フレーム解析コンポーネント８２１、受信状態監視機能を実現する受信状態監視コンポーネント８２２、フェール処理機能を実現するフェール処理コンポーネント８２３、送信フレーム作成機能を実現する送信フレーム作成コンポーネント８２４、定期送信を実現する定期送信コンポーネント８２５からなるＣＡＮ管理フレームワーク８２０を構成する。ＣＡＮ制御コンポーネント８７は、受信処理機能を実現する受信処理コンポーネント８７１、受信割込機能を実現する受信割込コンポーネント８７２、ＣＡＮコントローラを制御するＣＡＮコントローラコンポーネント８７３、送信割込機能を実現する送信割込コンポーネント８７４、送信処理機能を実現する送信処理コンポーネント８７５からなるＣＡＮ制御フレームワーク８７０を構成する。そして、ＣＡＮ管理フレームワーク８２０及びＣＡＮ制御フレームワーク８７０はいずれも、コンポーネントとして「ＣＡＮ通信」なる機能属性を共通とするので、ＣＡＮ通信フレームワーク９を構成する。
【００４８】
図５及び図６に示したような各フレームワーク及び各コンポーネントは、上位層のコンポーネントが下位層のコンポーネントに、システムマネージャ１０９からの指示に従っていずれかに起動要求を通知し、起動要求に応じて各コンポーネントが状態変化したことを上位層のコンポーネントに通知するという階層的構造にて動作するようにしてある。これにより、各機能を選択的に実現させることができ、不要な機能は動作を停止させるなど、効率的な制御が可能である。つまり、例えば入力条件判定フレームワーク１７２により、内部情報提供コンポーネント７１、ドアロック系コンポーネント７２、ライト系コンポーネント７３、ワイパー系コンポーネント７４のいずれかへ起動要求がされ、各コンポーネントから状態が通知されることにより、各機能の動作が入力条件判定フレームワーク１７２によって管理される。
【００４９】
図３乃至図６に示したように、アプリケーション層１０７と、プラットフォーム層１０８とでは、夫々に含まれるコンポーネントの属性情報は異なる。しかしながら、各々で属性情報に基づき、アプリケーション層１０７及びプラットフォーム層１０８夫々での各フレームワークによって実現される機能は明確に分類され、対応する集合体として扱われる。また、各コンポーネントは属性情報によって特定の機能を実現する要素として対応付けられるので、一つの属性情報によってその機能の追加・削除を容易に変更可能である。例えば、図４及び図６に示したＣＡＮ管理コンポーネント（フレームワーク）８２（８２０）及びＣＡＮ制御コンポーネント（フレームワーク）８７（８７０）は、ＣＡＮ通信フレームワーク９を構成しているが、ＥＣＵ１においてＣＡＮ通信に対応する必要がなくなった場合、削除対象のコンポーネントの属性情報として「ＣＡＮ通信」を選択することにより、ＣＡＮ通信を属性情報に持つコンポーネントからなるＣＡＮ通信フレームワーク９をまとめて機能しないように制御することができる。したがって、各層において属性情報によって機能の抜き差しが可能となり、いずれの機能（属性）を基準とするか、役割（属性）を基準とするか、その他の属性情報を基準とするかによって、フレームワークの構成を変更することが容易となる。
【００５０】
次に、ＥＣＵ１におけるアプリケーション層１０７と、プラットフォーム層１０８とで機能構成の変更が容易に可能であることをフローチャートを参照して説明する。
【００５１】
図７は、属性情報の選択によって、ＥＣＵ１の機能構成が変更される処理手順の一例を示すフローチャートである。なお、本処理は例えば、要求仕様の変更に伴ってアプリケーションプログラム１７，１７，…、プラットフォームプログラム１８、システムマネージャプログラム１９をリンクさせる際に、コンパイラなどによって実行される。
【００５２】
要求仕様の変更に伴い、制御ロジックに基づいて必要となる各機能に対応する属性情報が選択される（ステップＳ１）。アプリケーションプログラム１７，１７，…、プラットフォームプログラム１８に含まれる各フレームワーク及びコンポーネントに関連付けられた属性情報が参照される（ステップＳ２）。
【００５３】
ステップＳ１にて必要となる各機能に応じて選択された属性情報を共通する属性とするコンポーネントに相当するプログラムモジュールが、アプリケーションプログラム１７，１７，…及びプラットフォームプログラム１８から夫々選択される（ステップＳ３）。選択されたプログラムモジュールは共通する属性情報にて対応付けられ（ステップＳ４）、処理が終了される。
【００５４】
このような処理により、ＥＣＵ１の機能構成が容易に要求仕様に従って再構築可能である。
【００５５】
更に属性情報にはアプリケーション層１０７と、プラットフォーム層１０８との異なるソフトウェア階層間での関連を示す各フレームワーク間のリンク情報が含まれることが望ましい。図８は、各層における機能フレームワークの属性情報にリンク情報が含まれる場合の構成の例を示す説明図である。
【００５６】
図８の例では、アプリケーション層１０７、プラットフォーム層１０８におけるリソースマネージャ層１０８ａ及びリソースコントローラ層１０８ｂにて夫々選択されて構築された各コンポーネントが示されている。アプリケーション層１０７では、オートドアロック、とじこみ防止機能などドアロック関連の機能を実現するドアロックフレームワーク、各ライトの制御を実現するライト系フレームワーク７３０、及び車両の故障状況の診断機能を実現する診断フレームワークが動作するように構成されている。図８に示す例では、診断フレームワークに含まれる外部故障診断コンポーネントの属性情報として、以下のような情報が関連付けられている。機能属性として「診断」、役割属性として「外部故障診断」、リンク属性として「ＵＡＲＴ管理／Ｋ−ＬＩＮＥ」が関連付けられている。つまり、アプリケーション層１０７における外部故障診断コンポーネントには、プラットフォーム層１０８において「ＵＡＲＴ管理」及び「Ｋ−ＬＩＮＥ」が機能属性及び役割属性として関連付けられているコンポーネント、即ちリソースマネージャ層１０８ａのＫ−ＬＩＮＥコンポーネントと関連関係があることを示している。ここで、ＵＡＲＴ、Ｋ−ＬIＮＥはいずれも、ＥＣＵ１又は他のＥＣＵに接続される外部故障診断機器との通信ラインである。外部故障診断機能を実現するためには、関連してＵＡＲＴ管理又はＫ−ＬＩＮＥ管理の機能が必要となることから、関連関係がある。
【００５７】
プラットフォーム層１０８におけるリソースマネージャ層１０８ａでは、メモリ管理フレームワーク１８１ａ、通信管理フレームワーク１８２ａ、Ｉ／Ｏ管理フレームワーク１８３ａの他、リソース監視フレームワークなどが動作するように構成されている。通信管理フレームワーク１８２ａにはＵＡＲＴ管理コンポーネント（フレームワーク）８１が含まれている。更に、ＵＡＲＴ管理フレームワークはＫ−ＬＩＮＥコンポーネントを含む。Ｋ−ＬＩＮＥコンポーネントには属性情報として、以下のような情報が関連付けられている。機能属性として「ＵＡＲＴ管理」、役割属性として「Ｋ−ＬＩＮＥ」、リンク属性として「診断／外部故障診断／ＵＡＲＴ制御／ＵＡＲＴ ＣＨ１」が関連付けられている。つまり、リソースマネージャ層１０８ａにおけるＫ−ＬＩＮＥコンポーネントには、アプリケーション層１０７において「診断」及び「外部故障診断」が機能属性及び役割属性として関連付けられているコンポーネント、即ちアプリケーション層１０７の外部故障診断コンポーネントと関連関係があることを示している。また、Ｋ−ＬＩＮＥコンポーネントには、リソースコントローラ１０８ｂにおいて「ＵＡＲＴ制御」及び「ＵＡＲＴ ＣＨ１」が機能属性及び役割属性として関連付けられているコンポーネント、即ちリソースマネージャ層１０８ａのＫ−ＬＩＮＥコンポーネントは、リソースコントローラ層１０８ｂのＵＡＲＴ ＣＨ１コンポーネントと関連関係があることを示している。
【００５８】
プラットフォーム層１０８におけるリソースコントローラ層１０８ｂでは、メモリ制御フレームワーク１８１ｂ、通信制御フレームワーク１８２ｂ、Ｉ／Ｏ制御フレームワーク１８３ｂの他、存在しないハードウェアの動作をエミュレータして応答する仮想化フレームワークが動作するように構成されている。通信制御フレームワーク１８２ｂには、ＵＡＲＴ制御コンポーネント（フレームワーク）８５が含まれている。更に、ＵＡＲＴ制御フレームワークはＵＡＲＴ ＣＨ１コンポーネントを含む。ＵＡＲＴ ＣＨ１コンポーネントには属性情報として、以下のような情報が関連付けられている。機能属性として「ＵＡＲＴ制御」、役割属性として「ＵＡＲＴ ＣＨ１」、リンク属性として「ＵＡＲＴ管理／Ｋ−ＬＩＮＥ」が関連付けられている。ＵＡＲＴ ＣＨ１コンポーネントは、ＵＡＲＴのＣＨ１による通信を制御する機能を実現するものである。そして、ＵＡＲＴ ＣＨ１コンポーネントは、リソースマネージャ層１０８ａにおいて「ＵＡＲＴ管理」及び「Ｋ−ＬＩＮＥ」が機能属性及び役割属性として関連付けられているコンポーネント、即ちＫ−ＬＩＮＥコンポーネントと関連関係があることを示している。
【００５９】
ここで例えば、外部診断機能機器など外部機器との接続が不要になった場合、アプリケーション層１０７において外部故障診断フレームワークが動作しないように削除するとする。このとき、外部故障診断フレームワークとリンクしているリソースマネージャ層１０８ａのＫ−ＬＩＮＥコンポーネント、及び更にＫ−ＬＩＮＥコンポーネントとリンクしているリソースコントローラ層１０８ｂのＵＡＲＴ ＣＨ１コンポーネントをいずれも削除して、一括して機能しないように構築し直すなどが可能となる。このように、属性情報に含まれるリンク属性により、ソフトウェア構造の階層にわたって各機能間の対応付けを可能とすることにより、各機能の連動的な抜き差しが容易に可能となり、多様な要求仕様に対応させることができる点、優れた効果を奏する。
【００６０】
このような構成により、以下のような効果を奏する。例えば、ある仕様では、通信管理機能としては状態監視機能まで含まれることが要求される一方で、他の仕様では、状態監視機能はアプリケーション層１０７における機能によって実現されればよい場合がある。本実施の形態の構成では、そのような仕様の変更に応じた各機能の具体的要素の組み合わせを自在とすることができ、容易にＥＣＵ１における機能構成を幅広いバリエーションにて変更することが可能となり、様々な仕様要求に容易に対応させることが可能となる。このように、一のプログラムでも種々の仕様に柔軟に対応できるので、プログラムの再利用性が向上し、開発過程の短縮化、開発負荷の削減を図ることができる。
【００６１】
上述に示した実施の形態では、本発明は車両に搭載されるＥＣＵに適用される例を示した。しかしながら本発明はこれに限らず、種々の制御を行なうコンピュータ装置全般に適用することができる。
【００６２】
なお、上述のように開示された本実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【００６３】
１ ＥＣＵ
１０ マイコン
１１ ＣＰＵ
１２ ＲＯＭ
１７，１７ アプリケーションプログラム
１８ プラットフォームプログラム
１９ システムマネージャプログラム
１０７ アプリケーション層
１０８ プラットフォーム層
１０８ａ リソースマネージャ層
１０８ｂ リソースコントローラ層
１０９ システムマネージャ
【特許請求の範囲】
【請求項１】
複数の機能単位で分離された複数のプログラムモジュールから構成される一又は複数のアプリケーションプログラム、及び、前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御し、複数の機能単位で分離されたプログラムモジュールから構成されるプラットフォームプログラムを含むコンピュータプログラムの構成を変更する方法であって、
各プログラムモジュールには夫々を識別する識別情報と、各プログラムモジュールに基づきコンピュータが実現する機能の属性を示す属性情報とを関連付けて記憶しておき、
コンピュータが実現する機能の構成の変更に伴う属性情報の選択を受け付け、
選択された属性情報が共通に関連付けられたプログラムモジュールを選択し、
選択したプログラムモジュールからコンピュータプログラムを構築する
ことを特徴とするプログラム変更方法。
【請求項２】
前記属性情報は、機能の内容を示す情報、機能の役割を示す情報、及び他の機能との関連を示す情報の内の一又は複数を含むこと
を特徴とする請求項１に記載のプログラム変更方法。
【請求項３】
一又は複数のアプリケーションプログラムの機能を各実現する一又は複数のアプリケーションプログラム、及び、前記一又はアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムを含み、
前記アプリケーションプログラム及びプラットフォームプログラムは夫々、機能の属性を示す属性情報が関連付けられた複数のプログラムモジュールから構成されており、
同一の属性情報が共通して関連付けられたプログラムモジュールが選択されたアプリケーションプログラム及びプラットフォームプログラムを実行可能としてあること
を特徴とするコンピュータプログラム。
【請求項１】
複数の機能単位で分離された複数のプログラムモジュールから構成される一又は複数のアプリケーションプログラム、及び、前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御し、複数の機能単位で分離されたプログラムモジュールから構成されるプラットフォームプログラムを含むコンピュータプログラムの構成を変更する方法であって、
各プログラムモジュールには夫々を識別する識別情報と、各プログラムモジュールに基づきコンピュータが実現する機能の属性を示す属性情報とを関連付けて記憶しておき、
コンピュータが実現する機能の構成の変更に伴う属性情報の選択を受け付け、
選択された属性情報が共通に関連付けられたプログラムモジュールを選択し、
選択したプログラムモジュールからコンピュータプログラムを構築する
ことを特徴とするプログラム変更方法。
【請求項２】
前記属性情報は、機能の内容を示す情報、機能の役割を示す情報、及び他の機能との関連を示す情報の内の一又は複数を含むこと
を特徴とする請求項１に記載のプログラム変更方法。
【請求項３】
一又は複数のアプリケーションプログラムの機能を各実現する一又は複数のアプリケーションプログラム、及び、前記一又はアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムを含み、
前記アプリケーションプログラム及びプラットフォームプログラムは夫々、機能の属性を示す属性情報が関連付けられた複数のプログラムモジュールから構成されており、
同一の属性情報が共通して関連付けられたプログラムモジュールが選択されたアプリケーションプログラム及びプラットフォームプログラムを実行可能としてあること
を特徴とするコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１０−２３１８０８（Ｐ２０１０−２３１８０８Ａ）
【公開日】平成２２年１０月１４日（２０１０．１０．１４）
【国際特許分類】
【出願番号】特願２０１０−１３７３５０（Ｐ２０１０−１３７３５０）
【出願日】平成２２年６月１６日（２０１０．６．１６）
【分割の表示】特願２００８−１９６５２１（Ｐ２００８−１９６５２１）の分割
【原出願日】平成２０年７月３０日（２００８．７．３０）
【出願人】（３９５０１１６６５）株式会社オートネットワーク技術研究所 (2,668)
【出願人】（０００１８３４０６）住友電装株式会社 (6,135)
【出願人】（０００００２１３０）住友電気工業株式会社 (12,747)
【Ｆターム（参考）】
【公開日】平成２２年１０月１４日（２０１０．１０．１４）
【国際特許分類】
【出願日】平成２２年６月１６日（２０１０．６．１６）
【分割の表示】特願２００８−１９６５２１（Ｐ２００８−１９６５２１）の分割
【原出願日】平成２０年７月３０日（２００８．７．３０）
【出願人】（３９５０１１６６５）株式会社オートネットワーク技術研究所 (2,668)
【出願人】（０００１８３４０６）住友電装株式会社 (6,135)
【出願人】（０００００２１３０）住友電気工業株式会社 (12,747)
【Ｆターム（参考）】
[ Back to top ]