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

Abstract

【課題】組み込み系のコンピュータプログラムにオブジェクト指向型の概念を適用し、メモリを節約して装置の簡素化を実現させ、開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムを提供する。
【解決手段】マイコンはアプリケーション層１０１における１つの選択部１０５の機能により、複数のアプリ（１０３，１０４）夫々からの動作要求を受け付け、動作要求に対応する制御対象の負荷と、該負荷に行なわせる動作パターンを選択し、選択した負荷及び動作パターンを示す情報を出力ドライバ部１０６の機能へ与える。マイコンは、１つの出力ドライバ部１０６の機能により与えられた情報が示す負荷へ、動作パターンに対応する制御信号を生成し、プラットフォーム層１０２における物理的な信号の入出力を実現する入出力ドライバ１０７から信号を出力させる。
【選択図】図３

Description

本発明は、コンピュータプログラムに基づき各種負荷の動作制御を行なう制御装置に関する。特に、コンピュータプログラムの構成を、メモリを節約させることを可能とする構成として装置の簡素化を実現させ、且つ各負荷用の多様な機能の増減に柔軟に対応させることができ、開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムに関する。

マイクロコンピュータ（以下、マイコンという）を利用し、マイコン内臓ＲＯＭに書き込まれたコンピュータプログラムに基づいて制御を行なう制御装置の場合、コンピュータプログラムは所謂組み込み系の言語で記述される。組み込み系の言語で記述するコンピュータプログラムは、装置の簡素化のためにメモリなどリソースを節約し、必要最低限の処理を制御対象毎に且つ機能毎に実装する構成が基本的である。

図１１は、従来のマイコンにおけるコンピュータプログラムの構成の概略を示す概略図である。図１１に示すコンピュータプログラムの構成は特に、制御対象（負荷Ａ及びＢ）の動作を制御する制御装置にてマイコンにより実行されるコンピュータプログラムの例を示している。図１１は、コンピュータプログラムにより実現される機能をブロックにて示している。図１１の例のコンピュータプログラムによって負荷Ａと負荷Ｂとを制御する機能が実現される場合、図１１に示すように、当該コンピュータプログラムは例えば入力信号に対する判定処理、入力信号に基づく負荷に対する動作条件の判定処理、各負荷への信号出力の調停、動作毎の負荷への信号出力などの機能が、アプリケーションプログラムにより実現したい機能（ア）及び機能（イ）夫々に対応して、更に負荷Ａ及びＢ毎に実現される。

コンピュータプログラムの実装上も、夫々の機能に応じたプログラムコード（実行ファイル）が作成され、いずれのプログラムコードもメモリ上に予め記憶されており、ＣＰＵにより読み出される。したがって、図１１に示したブロック夫々に応じてメモリが占有される。このとき、負荷に対する調停処理の内容は負荷Ａ及びＢによらず同じであって、且つ負荷Ａ及び負荷Ｂにおける調停処理は同期的に行なう必要がない。それにも拘わらず、調停処理を実現する機能は負荷Ａ及びＢとで夫々存在する。また、マイコンでの処理では機能（ア）のアプリケーションにおける処理と、機能（イ）のアプリケーションにおける処理とは同期的に動作する必要がないにも拘わらず、同一の動作を実行する負荷Ａの調停部の処理、負荷Ｂの調停部の処理を実現するプログラムが夫々に含まれて重複している。また、負荷Ａ及びＢへの動作毎の信号出力部もほぼ処理の内容は同一で出力される信号の波形が異なる程度であるはずにも拘わらず、機能（ア）及び（イ）のアプリケーションに夫々含まれており、同時に使用される可能性がないにもかかわらず重複して夫々プログラムとして存在する。

このような構成では、同時に使用される可能性がないプログラムコードが多数重複して存在し、メモリを占有する量が多くなる。

また車両用の制御装置の分野では、近年では車両の機能の多様化、複雑化に伴なって、従来のように実現される機能と、機能に対応する制御対象とが１対１ではない。例えば、従来では、運転者が意図的に方向指示器ランプ（ウィンカー）を点滅させるなど、進行方向を指示する方向指示機能と、制御対象となる方向指示器ランプとがほぼ１対１で対応する構成であった。しかしながら、近年では、方向指示器ランプは、方向指示機能を実現させるための制御対象であると共に、車外にいるユーザへの情報通知機能を実現するための制御対象である場合がある。この場合、同一の方向指示器ランプの点滅制御であっても方向指示機能に基づく点滅制御と、情報通知機能に基づく点滅制御との夫々について１対１の対応で独立にプログラムコードが作成されて記憶される。図１１の例では、負荷Ａの動作ａ及び負荷Ｂの動作ｂは、機能（ア）のアプリケーションのみならず、機能（イ）のアプリケーションにも対応している。

このように、複数の機能に１の制御対象が対応し、機能毎且つ制御対象毎の制御処理単位にプログラムコードがメモリを占有するのでメモリの使用が非効率的である。

マイコンを用いて負荷の動作を制御する制御装置では、モータなどの制御対象のように回転数等の情報が必要な負荷以外の制御対象に対しては大抵、オン、オフの切り換えによって制御する。制御信号を生成する処理などは結果的に同じ内容の処理を行ない、単に制御対象が異なるのみであっても、図１１の説明図に示したように、負荷夫々に対して信号出力機能を実現するプログラムコードがメモリに記憶される。更に、制御対象が同一であっても、各機能を実現するアプリケーションプログラムが複数実行可能である場合、各アプリケーションプログラムに応じて信号出力機能を実現するプログラムコードがメモリに記憶される。

しかもこの場合、各負荷を同時的に制御するのではなしに、シーケンシャルに各負荷へ制御信号を出力して各負荷で制御信号に応じた動作が行なわれ、各プログラムコードに占有されるメモリが同時的にアクセスされることもないにも拘わらず、マイコンに実行させるための各動作に対応するプログラムコードがいずれも、メモリを予め占有するので、メモリの使用効率が非効率的である。

これに対し、制御装置に求められる機能の多様化、複雑化が進むにつれ、オブジェクト指向型の言語によって記述されるプログラムをマイコンが読み出して実行する制御装置も提案されている（特許文献１など参照）。このように、処理が実行される都度にメモリが確保され、処理が終了した場合にはメモリが開放されて他に使用できるなど、メモリを効率的に利用することができる。しかしながらこの場合、プログラム実行中にメモリを動的に確保するなどの処理をマイコンに実現させる基本機能（ライブラリ）などが必要である。このようにオブジェクト指向に基づく設計では、基本機能を実現するためのライブラリプログラムコードがメモリを使用する上、動的なメモリ確保、動的なライブラリのリンクなどの処理が想定され、オブジェクト指向型のコンピュータプログラムの構成により各種機能が実現できるのはメモリの記憶容量に余裕があるからである。
特開２００８−７７２２０号公報

しかしながら、負荷制御を行なうマイコンを用いた制御装置では、メモリの容量に制限があるからこそ組み込み系の言語で記述されるコンピュータプログラムを利用するのであって、メモリの記憶容量に余裕を持たせてもよい特定の制御装置以外では、オブジェクト指向型のソフトウェア構成は適していない。一方で、従来のコンピュータプログラムの構成のように、共有できる処理であっても制御対象の負荷毎、及び機能毎にプログラムコードがメモリを占有する構成では、非効率的である。共通する同様な処理は共有化して再利用が可能な構成とし、共有化された処理はそれに対応するプログラムコードのみでメモリを占有することが望ましい。

本発明は斯かる事情に鑑みてなされたものであり、組み込み系のコンピュータプログラムにオブジェクト指向型の概念を適用し、メモリを節約して装置の簡素化を実現させ、開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムを提供することを目的とする。

第１発明に係る制御装置は、マイクロコンピュータを備え、該マイクロコンピュータが各機能に対応する複数のアプリケーションプログラムに基づく処理を行なうことにより複数の負荷の動作を制御する制御装置において、前記複数のアプリケーションプログラムに基づく処理からの動作要求を受け付け、該動作要求及び要求元のアプリケーションプログラムに対応する機能に応じて制御対象の負荷、及び該負荷に行なわせる動作を選択する選択手段、及び、該選択手段が選択した負荷、及び動作を示す情報が与えられた場合に、前記動作を実現させる制御信号を生成して前記負荷へ出力する出力手段を備えることを特徴とする。

第２発明に係る制御装置は、連続的オン、オフ、断続的オン、待機時間、又は断続的オンの場合の回数若しくはオン時間及びオフ時間を含む動作特定要素の内のいずれか一又は複数の組み合わせからなり、各々識別情報が付与された動作パターンのテーブルを記憶する手段を備え、前記選択手段は、前記テーブルから前記動作要求に対応する動作パターンを抽出し、抽出した動作パターンに付与されている識別情報を前記出力手段に与え、前記出力手段は、前記識別情報により動作を特定するようにしてあることを特徴とする。

第３発明に係る制御装置は、前記テーブルは制御対象の負荷毎に記憶されており、前記選択手段は、前記動作要求に応じて選択した負荷と、該負荷のテーブルから抽出した動作パターンに付与されている識別情報とを前記出力手段に与えるようにしてあることを特徴とする。

第４発明に係る制御装置は、前記テーブルは、前記動作特定要素毎に記憶されており、前記選択手段は、前記動作要求に応じて選択した負荷に行なわせる動作を、前記動作特定要素毎のテーブルから夫々動作パターンを読み出して組み合わせるようにしてあり、選択した負荷を示す情報と、組み合わせた動作パターン夫々に付与されている識別情報の組み合わせとを前記出力手段に与えるようにしてあることを特徴とする。

第５発明に係る制御装置は、前記選択手段は、前記動作要求に対応する動作パターンが前記テーブルに存在しない場合、前記動作パターンを前記テーブルに追加する手段を備えることを特徴とする。

第６発明に係る制御装置は、前記複数のアプリケーションプログラムには優先度が付与されており、前記選択手段は、複数のアプリケーションプログラムに基づく処理から夫々複数の動作要求を受け付けた場合、前記複数のアプリケーションプログラムの内の優先度が高いアプリケーションプログラムからの動作要求に応じた負荷及び動作を選択するようにしてあることを特徴とする。

第７発明に係る制御方法は、マイクロコンピュータを用い、該マイクロコンピュータに各機能に対応する複数のアプリケーションプログラムに基づく処理を行なわせることにより複数の負荷の動作を制御する方法において、前記マイクロコンピュータが前記複数のアプリケーションプログラムと異なるコンピュータプログラムに基づき、前記アプリケーションプログラムに基づく処理からの動作要求を受け付け、受け付けた動作要求及び要求元のアプリケーションプログラムに対応する機能に応じて制御対象の負荷、及び該負荷に行なわせる動作を選択し、選択した負荷及び動作を示す情報に基づき、前記動作を実現させる制御信号を生成して前記負荷へ出力することを特徴とする。

第８発明に係るコンピュータプログラムは、制御対象である複数の負荷が接続されているコンピュータに、アプリケーションプログラムに基づく処理を行なわせて前記複数の負荷の動作を制御させるコンピュータプログラムにおいて、コンピュータに、前記アプリケーションプログラムに基づく処理からの動作要求及び要求元のアプリケーションプログラムに対応する機能に応じて制御対象の負荷、及び該負荷に行なわせる動作を選択する選択手段、及び、該選択手段が選択した負荷、及び動作を示す情報が与えられた場合に、前記動作を実現させる制御信号を生成して前記負荷へ出力する出力手段として機能させることを特徴とする。

第１発明、第７発明及び第８発明では、マイコンはアプリケーションプログラムを実行するのみならず、アプリケーションプログラムに基づく処理によって発せられる動作要求を受け付け、受け付けた動作要求及び要求元のアプリケーションプログラムに対応する機能に基づいて対象となる負荷及び具体的な動作内容を選択する手段、及び、選択された負荷及び動作内容に基づいて、負荷に選択された動作を実行せしめる制御信号を生成して負荷へ出力する手段としても夫々機能する。当該機能は、アプリケーションプログラムと同様の、ドライバへの指示を具体的に実行する特定のアプリケーションとして実現される。

このとき選択手段としての機能では、動作要求元のアプリケーションを特定するが、出力手段としての機能では、動作要求元のアプリケーションを特定することなしに、選択された負荷へ選択された動作内容に応じた制御信号を生成して出力する。出力手段の機能は、いずれの負荷に対しても共通して利用することが可能である。

第２発明では、動作の内容を具体的に特定する動作パターンは、負荷毎にテーブル化されて記憶され、選択手段としての機能では、動作パターンテーブルからいずれかの動作パターンを選択して出力手段へ与えればよい。出力手段では、識別情報にて示される動作パターンを動作パターンテーブルから特定して当該動作パターンに対応させた制御信号を生成すればよく、選択手段にて動作を示す情報として具体的な動作特定要素を夫々与え、出力手段にて動作特定要素を夫々解釈する構成とするよりも、処理が単純化されて装置を簡素化させることができる。また、更に各機能で実現される具体的な動作を変更する場合は動作パターンテーブルの内容を更新すればよい点で、柔軟性に優れる。

第３発明では、負荷の動作の内容を具体的に特定する動作パターンは、負荷毎にテーブル化されて記憶されている。これにより、負荷毎に特定の動作を行なうべく設計されている場合、動作パターンとして負荷毎に最小限の動作パターンを記憶しておけばよく、動作パターンテーブルが占めるメモリの容量は少なくて済む。

第４発明では、負荷の動作の内容を具体的に特定する動作パターンは、負荷の違いによらずに連続的オン、オフ（停止）、断続的オン、待機時間、又は断続的オンの場合の回数、若しくはオン時間とオフ時間にて記述可能である。連続的オン、オフ、断続的オンなどの基本的な動作内容、待機時間、回数、又はオン時間若しくはオフ時間夫々について、パラメータをテーブル化し、夫々のテーブルから動作内容と、待機時間又はオン時間及びオフ時間とを組み合わせることにより、動作パターンテーブルとして記憶しておくべき内容は少なくてよく、テーブルが占有するメモリを節約することができる。出力手段としての機能は１つに共有化して再利用できる一方で、自由な組み合わせで多様な動作を実現させることができる。

第５発明では、第２発明において、選択手段がアプリケーションプログラムから受け付けた動作要求に対応する動作パターンを動作パターンテーブルから抽出できない場合、新たに動作パターンが動作パターンテーブルに追加される。これにより、アプリケーションプログラムにおける仕様変更に動的に動作パターンを対応させ、多様な動作を実現させることができる。

第６発明では、動作要求が複数のアプリケーションプログラムから受け付けられた場合、選択手段にて各アプリケーションプログラムに対応する機能の優先度に基づき、いずれの動作要求を優先的に受け付けるかが判断されるから、出力手段としての機能では、動作要求元のアプリケーションプログラムを認識することなしに、選択手段としての機能にて優先された動作のみ実行させるべく制御信号を生成して出力すればよい。出力手段としての機能は１つに共有化して再利用できる一方で、アプリケーションプログラムが対応する機能の内の優先度が高い機能を優先的に実現させるべく適宜選択して制御信号を生成して出力させることができる。

本発明による場合、組み込み系のコンピュータプログラムに基づき制御を行なう制御装置でも、各機能を実現させる動作の内容に対応する制御信号を生成して負荷へ出力する処理を各機能にとって共有化し、１つの出力手段の機能を各種の負荷の制御に利用する。これにより、制御信号を生成して出力する機能を実現させるプログラムコードが負荷毎に且つ機能毎に記憶されて実行される構成よりも、共通して利用できるプログラムコードを１つメモリに記憶して実行可能に構成しておくことにより各機能を実現可能であるからメモリの占有量は少なくて済む。メモリを節約できるので装置を簡素化させることができる。更に、実現したい機能毎に、実際の負荷制御の出力手段を夫々実装せずとも、共有化された出力手段の機能を再利用すればよいので、開発時に負荷への出力を意識せずに実現させたい機能に対応する動作内容を特定できる構成とする条件を守ればアプリケーションプログラムを開発のみで済み、開発効率を向上させることができる点、優れた効果を奏する。

以下、本発明をその実施の形態を示す図面に基づいて具体的に説明する。なお、以下に示す実施の形態では、車両に搭載されているヘッドライト、ドアなどのボディ系の各種制御対象を制御する車載ボディＥＣＵに本発明の制御装置を適用した車載制御システムを例に挙げて説明する。

（実施の形態１）
図１は、実施の形態１における車載制御システムの構成を示す構成図である。車載制御システムは、車両の前部左右に搭載されるヘッドライト１０，１０、方向指示器ランプ１１，１１及びスモールランプ１２，１２と、同様に車両の前部に搭載されるホーン２と、車室内に搭載されるブザー３と、車両のドア部に設置され、ドアの開閉を検知するドア開閉センサ４，４及びドアロックを検知するドアロックセンサ５，５と、車室内のキーを探知するキーセンサ６と、夫々を制御するボディＥＣＵ７とを含む。

ヘッドライト１０，１０、方向指示器ランプ１１，１１及びスモールランプ１２，１２は夫々ボディＥＣＵ７に接続されており、ボディＥＣＵ７により夫々の点灯、消灯が制御される。

ホーン２及びブザー３はボディＥＣＵ７に接続されており、ボディＥＣＵ７により吹鳴が制御される。

ドア開閉センサ４，４及びドアロックセンサ５，５はボディＥＣＵ７に接続されており、夫々ドア開閉状態を知らしめる信号又はドアロックの開閉状態を知らしめる信号をボディＥＣＵ７へ出力する。

キーセンサ６はボディＥＣＵ７に接続されており、キーセンサ６にて検知したキーの有無を示す信号をＥＣＵ７へ出力する。

ボディＥＣＵ７は、ドア開閉センサ４，４、ドアロックセンサ５，５又はキーセンサ６から出力される信号に基づき、例えばエンジンが停止しており、車室内にキーが存在しない状態で外部からドアロックがされたことをドアロックセンサ５，５、キーセンサ６にて検知した場合、方向指示器ランプ１１，１１、又はスモールランプ１２，１２に複数回点滅させるべく制御信号を出力するなどしてキーレスアンサーバック機能を実現する。また、ボディＥＣＵ７は、ドア開閉センサ４，４、ドアロックセンサ５，５又はキーセンサ６から出力される信号に基づき、ドアロックがされている状態で正規なキー以外でドアロックが解除されようとしていることをドアロックセンサ５，５で検知した場合、ホーン２及びブザー３を吹鳴させ、ヘッドライト１０などを点灯させるべく制御信号を出力するなどしてセキュリティアンサーバック機能を実現する。

なお、実施の形態１では、キーレスアンサーバック機能、セキュリティアンサーバック機能に関する各構成部の処理のみ記載するが、ボディＥＣＵ７が他の機能を実現するために他の制御対象となる負荷（アクチュエータ）を制御することが可能な構成でもよいことは勿論である。

このような各種機能をボディＥＣＵ７にて実現するためのボディＥＣＵ７内部の構成及び処理について説明する。ボディＥＣＵ７は後述するように、マイコンを備えて、マイコン内臓のＲＯＭ（Read Only Memory）に記憶されているコンピュータプログラムに基づく処理を実行することにより各種機能を実現する。

図２は、実施の形態１における車載制御システムに含まれるボディＥＣＵ７の内部構成を示すブロック図である。ボディＥＣＵ７は、ＣＰＵ７１、ＲＯＭ７２、ＲＡＭ（Random Access Memory）７３及びＩ／Ｏ７４を含むマイコン７０を備えて構成される。他に、ドア開閉センサ４，４、ドアロックセンサ５，５、キーセンサ６などのセンサと車載ネットワークを介して接続される場合は通信手段としてネットワークコントローラ、トランシーバをマイコン７０内又は外に備える構成としてもよい。

ＣＰＵ７１は、ＲＯＭ７２に記憶されているコンピュータプログラムをＲＡＭ７３に読み出して実行することにより、上述のようなキーレスアンサーバック機能又はセキュリティアンサーバック機能を実現する。

ＲＯＭ７２には、フラッシュメモリを利用する。ＲＯＭ７２には、ＣＰＵ７１が読み出して実行するコンピュータプログラムとして、アプリケーションプログラム７５，７５，…、アプリケーションドライバプログラム７６、及びドライバプログラム７８が記憶されている。またＲＯＭ７２には、ＣＰＵ７１が各制御対象の動作内容を特定するために参照する動作パターンテーブル７７が記憶されている。なお、ＲＯＭ７２は基本的に、ボディＥＣＵ７の稼働中は読み出し専用ではあるが、ＣＰＵ７１に実行させたいコンピュータプログラムの更新、又は動作パターンテーブル７７の更新が必要な場合に書換が可能である。

ＲＡＭ７３には、ＤＲＡＭ（Dynamic RAM）、ＳＲＡＭ（Static RAM）等を利用する。ＲＡＭ７３にはＣＰＵ７１が読み出すコンピュータプログラムがロードされる他、処理によって発生する各種情報が一時的に記憶される。

Ｉ／Ｏ７４は、マイコン７０と外部とのインタフェースである。マイコン７１はＩ／Ｏ７４により、ヘッドライト１０，１０、方向指示器ランプ１１，１１又はスモールランプ１２，１２、ホーン２若しくはブザー３へ制御信号を出力する。

次に、マイコン７０のＣＰＵ７１がＲＯＭ７２に記憶されているコンピュータプログラムを読み出して実現するマイコン７０内の詳細な機能について説明する。図３は、実施の形態１におけるボディＥＣＵ７のマイコン７０のＣＰＵ７１にて実現される機能を概念的に示す機能ブロック図である。

ＣＰＵ７１は、ＲＯＭ７２に記憶されているアプリケーションプログラム７５，７５、アプリケーションドライバプログラム７６、及びドライバプログラム７８を読み出して実行することにより、アプリケーション層１０１、プラットフォーム層１０２の階層に分けられたソフトウェア構造にて動作する。

ＣＰＵ７１がアプリケーションプログラム７５，７５，…の内、キーレスアンサーバック用のアプリケーションプログラム７５に基づき、キーレスアンサーバック機能を実現するアプリケーション、即ちＫＡＢ（Keyless Answer Back）アプリ１０３として機能する。同様にＣＰＵ７１は、セキュリティアンサーバック用のアプリケーションプログラム７５に基づき、ＳＡＢ（Security Answer Back）アプリ１０４として機能する。ＫＡＢアプリ１０３及びＳＡＢアプリ１０４としての機能は構造的に、アプリケーション層１０１に位置する。

ＣＰＵ７１はアプリケーションドライバプログラム７６に基づき、選択部１０５及び出力ドライバ部１０６としての機能を実現する。選択部１０５及び出力ドライバ部１０６としての機能は、ハードウェア群（制御対象群、即ちヘッドライト１０、方向指示器ランプ１１、スモールランプ１２、ホーン２、ブザー３等）を直接的に制御すべく物理層の信号を扱う所謂ドライバの機能ではなく、ＫＡＢアプリ１０３又はＳＡＢアプリ１０４などの各種アプリケーションの処理の内の信号生成処理などの共通部分を１つにしたモジュールであり、アプリケーション層１０１に位置する。

そしてＣＰＵ７１はドライバプログラム７８に基づき、入出力ドライバ１０７として機能する。入出力ドライバ１０７としての機能は所謂ドライバの機能を実現し、ハードウェア群を直接的に制御すべくＩ／Ｏ７４へ実際に物理層の制御信号の入出力を行なう。入出力ドライバ１０７としての機能は構造的に、プラットフォーム層１０２に位置する。

ＣＰＵ７１の選択部１０５としての機能は、ＣＰＵ７１がＫＡＢアプリ１０３又はＳＡＢアプリ１０４としての機能により制御対象となるハードウェア、例えばヘッドライト１０へ点灯要求などの動作要求を発した場合に、動作要求を受け付け、制御対象と、制御対象に行なわせる具体的な動作とを特定し、特定した制御対象及び動作の内容を示す情報を出力ドライバ部１０６へ与える。

ＣＰＵ７１の出力ドライバ部１０６としての機能は、選択部１０５から与えられる制御対象、及び制御対象に行なわせる具体的な動作の情報に基づき、動作を実現させるための制御信号を生成して、制御対象のハードウェアへ制御信号を出力させるべくプラットフォーム層１０２の入出力ドライバ１０７へ指示する。

このように、ＫＡＢアプリ１０３及びＳＡＢアプリ１０４など各アプリケーション毎、制御対象毎に、制御信号を生成して入出力ドライバ１０７へ夫々出力する構成（図１１参照）とするよりも、本実施の形態１のボディＥＣＵ７では、各アプリケーションからの動作要求を選択部１０５にて一括して受け付け、制御信号の生成を行なう出力ドライバ部１０６の機能を共有化する構成とする。ＫＡＢアプリ１０３及びＳＡＢアプリ１０４などのいずれのアプリケーションでも、制御がオン、オフのスイッチングにて実現する場合、動作要求に応じて制御信号を生成する処理は、動作の具体的内容が異なるのみで共通した処理であるから共有化が可能である。また、ボディＥＣＵ７では、各制御対象のハードウェアの制御を同時に行なうことはなく、各アプリケーションの機能も順に実現されるから制御信号の生成処理が同時に行なえる構成とする必要はないので共有化が可能である。当該処理を１つにして各機能から再利用可能に共有化した構成とすることにより、ＲＯＭ７２及びＲＡＭ７３におけるメモリ占有量を削減できる。

具体的には、ＣＰＵ７１にて各機能が実現される場合、図３の各ブロックにて示す各機能に対応する実行プログラムファイル（プログラムコード）が必要となる。制御対象の決定及び制御信号の生成処理の機能を１つの選択部１０５及び出力ドライバ部１０６に共有化して、各種機能から利用される構成とすることにより、複数のアプリケーションプログラム７５，７５，…夫々に対応させたアプリケーションドライバプログラムを複数実行する構成よりもＲＯＭ７２及びＲＡＭ７３における記憶容量が少なくて済む。ＫＡＢアプリ１０３及びＳＡＢアプリ１０４夫々のために出力ドライバ部１０６に対応するプログラムコードを用意する必要がないからである。また、実現したい各機能について実際に制御信号を生成する処理を実装せずとも、選択部１０５及び出力ドライバ部１０６の機能を再利用すればよいので、機能の開発は動作要求を発するアプリケーションプログラム７５，７５，…の開発のみで済み、開発効率を向上させることができる。

そして実施の形態１においてＣＰＵ７１は選択部１０５の機能にて動作の内容を特定するに際し、ＲＯＭ７２に予め記憶させてある動作パターンテーブル７７を参照して特定する。動作パターンテーブル７７には、実施の形態１では制御対象となるハードウェア毎に想定される複数の動作パターンが記憶されており、選択部１０５は動作パターンテーブル７７から動作パターンを特定する識別情報を出力ドライバ部１０６へ与え、出力ドライバ１０６では与えられた識別情報から特定される動作パターンに基づき当該動作パターンに対応する制御信号が入出力ドライバ１０７から出力されるように入出力ドライバ１０７へ指示する。

図４は、実施の形態１におけるボディＥＣＵ７のＲＯＭ７２に記憶されている動作パターンテーブル７７の内容例を示す説明図である。実施の形態１において動作パターンテーブル７７は、制御対象毎に動作パターンが記憶されているが、図４に示す内容例では、制御対象としてスモールランプ１２，１２の動作パターンの例を挙げている。

動作パターンは、動作をオンとするまでの待機時間、連続的にオンとするか、断続的にオンとするか、又は１回のみオンとするかなどの動作方式、動作方式が断続的オンである場合のオンとする回数、断続的動作である場合のオン時間とオフ時間とを含む動作特定要素の組み合わせにて特定される。図４の内容例では、スモールランプ１２，１２の動作パターンは、オン即ち点灯させるまでの待機時間、連続的点灯か又は断続的点灯即ち点滅かの動作方式、動作方式が点滅の場合の点滅の回数、動作方式が点滅の場合の点灯時間と消灯時間とを含む。このような動作特定要素により、スモールランプ１２，１２に行なわせる動作を特定する。

そして、動作パターンテーブル７７では、各動作パターンに識別情報として番号が付与されている。図４の内容例において、「１」の動作パターンは、スモールランプ１２，１２を、待機することなく「１０００ｍｓ（ミリ秒）」の間、点灯させることで「１回」「点滅」させるパターンであり、「２」の動作パターンは、スモールランプ１２，１２を、待機することなく「７５０ｍｓ」点灯させ、「７５０ｍｓ」消灯させることを繰り返して「２回」「点滅」させるパターンである。「３」の動作パターンは、「１０ｍｓ」待機した後、オフが指示されるまで連続的に「点灯」させるパターンである。

選択部１０５としての機能によりＣＰＵ７１は、例えばＫＡＢアプリ１０３の機能から
「ロックしました」の通知に対応するスモールランプ１２，１２の１回点滅要求を受け付けた場合、スモールランプ１２，１２の動作パターンとして図４の内容例において動作パターン「１」を選択する。そして選択部１０５としての機能によりＣＰＵ７１は、スモールランプ１２，１２を示す情報、例えば制御対象の番号と、選択した動作パターンの番号（「１」）とを出力ドライバ部１０６へ与える。このとき選択部１０５としての機能では、「ロックしました」の通知要求のみ受け付け、「ロックしました」の通知要求に対応する動作として「１」の動作パターンを特定して出力する構成としてもよい。

そしてこの場合、出力ドライバ部１０６としての機能によりＣＰＵ７１は、選択部１０５から与えられたスモールランプ１２，１２を示す情報と、動作パターンの識別情報、この場合「１」とから動作パターンテーブル７７を参照し、スモールランプ１２，１２を待機することなく「１０００ｍｓ（ミリ秒）」の間のみ点灯させて「１回」「点滅」させるパターンであることを特定し、当該パターンに対応する制御信号が入出力ドライバ１０７から出力されるように入出力ドライバ１０７へ指示する。

このように、選択部１０５及び出力ドライバ部１０６としての機能によりＣＰＵ７１は、動作パターンテーブル７７を参照して動作の内容を特定することにより、処理が単純化されて装置を簡素化させることができる。また具体的な動作を変更する場合は動作パターンテーブル７７の内容を更新すればよく、多様な動作を柔軟に実現させることができる。

次に、出力ドライバ部１０６にて実現されるＣＰＵ７１の処理の詳細を説明する。図５は、ＣＰＵ７１が出力ドライバ部１０６として機能する際の処理の具体例を概念的に示す説明図である。図５には、ＣＰＵ７１が出力ドライバ部１０６として機能している際にＲＡＭ７３を占有する各種情報をブロックにて示している。

図５中の上段には、ボディＥＣＵ７の制御対象であるヘッドライト１０，１０、方向指示器ランプ１１，１１、スモールランプ１２，１２、ホーン２、ブザー３夫々について、動作状態、動作回数、各動作の経過時間が制御対象毎の固有パラメータが記憶されている。なお、同一の制御対象であっても、該制御対象に動作を要求するアプリケーションプログラム毎に動作状態を記憶してもよい。動作状態の内容は、停止中、オン（点灯）、オフ（消灯）などのいずれかであり、回数とは断続的動作の場合の回数、例えば現在の点滅回数を示す。なお、斜線にて示す動作状態、動作回数及び経過時間の内容は随時書き換えられる。

図５中の下段には、動作パターンテーブル７７が示されている。動作パターンテーブル７７はＲＯＭ７２に記憶されている。図５に示すＲＡＭ７３上の情報は、ＣＰＵ７１によって一時的に抽出された動作パターンテーブル７７の一部である。

図５中の中段には、出力ドライバ部１０６に対応するプログラムコードがロードされていることが示されている。プログラムコードにおいて選択部１０５から与えられた制御対象を示す情報と動作パターンを特定する識別情報とにより、制御信号の出力先を特定し、当該出力先の固有パラメータの動作状態及び動作回数と、特定された動作パターンの動作特定要素を比較して、動作状態に応じた信号を生成し、動作状態及び動作回数を書き換えて処理を終了し、次の他の制御対象に対する動作要求に対応する処理を実行する。

このとき、複数の制御対象毎、又は複数のアプリケーションプログラム７５，７５毎に、複数の出力ドライバ部１０６のプログラムコードが展開されて夫々対応付けられる構成ではなく、１つのプログラムコードで複数の制御対象への制御信号生成処理が実現していることに注目すべきである。

図６は、オブジェクト指向型における各制御対象毎の制御処理用のプログラムの実現例を比較例として示す説明図である。図６中の左側に、出力ドライバ部１０６の処理に対応する共通の制御信号生成処理を持つ制御クラスの定義を示している。制御クラスは、動作状態、動作回数及び経過時間を固有パラメータとして有し、制御信号生成処理では、これらの固有パラメータを内部で可変情報として処理を実行する。当該制御クラスを、制御対象毎に実体（インスタンス）化することにより、右側に示すように各制御対象について処理を実際に実現するプログラムコードが生成される。図６の例では、ヘッドライト制御、スモールランプ制御、及びホーン制御について実体化されている。この場合、制御信号生成処理の内容はいずれも共通するものの、いずれも実体化されるから各インスタンスについてメモリが確保され、プログラムコード部分は図５に示した場合よりも約３倍のメモリを占有する。

このように、１つのプログラムコードで各制御対象毎の固有パラメータを動作の進行具合に応じて書き換え、各アプリケーションからの動作要求毎に順に実行することにより、オブジェクト指向型の概念において１つの共通する制御処理を持つクラスを各制御対象毎に実体化して、クラスが持つ共通処理を各制御対象の固有パラメータに対して実行する処理を、メモリ容量に制限がある組み込み系のコンピュータプログラムでも実現することができる。

図７は、ＣＰＵ７１が出力ドライバ部１０６として機能する際の処理手順の具体例を示すフローチャートである。ＣＰＵ７１は、動作要求を受け付けた選択部１０５から制御対象を示す情報と、制御対象に行なわせるべき動作の動作パターンの情報とを与えられた場合、図５に示したようにメモリに展開された１つのプログラムコードに基づき以下の処理を実行する。なお、ＣＰＵ７１は、以下に示すフローチャートの処理を終了した後、所定時間待った後に再度処理を開始して繰り返し、適宜その時点での動作状態及び経過時間等に基づいて処理を進める。なお、以下に示す処理手順では、制御対象としてスモールランプ１２，１２を例とする。

ＣＰＵ７１は、与えられた制御対象の情報、ここではスモールランプ１２，１２の情報に基づき、スモールランプ１２，１２の固有パラメータが記載されているメモリを参照し（ステップＳ１）、固有パラメータの内の動作状態を読み出す（ステップＳ２）。

ＣＰＵ７１は、ステップＳ２にて読み出した動作状態が、停止中、オン（点灯）状態、オフ（消灯）状態のいずれであるかを判別し（ステップＳ３）、動作状態が停止中状態である場合は処理をステップＳ４へ、動作状態がオン状態である場合は処理をステップＳ７へ、動作状態がオフ状態である場合は処理をステップＳ１３へ進める。

ステップＳ３にて、ＣＰＵ７１は、スモールランプ１２，１２への現在の動作要求に対応する動作状態の内容が停止中状態であると判別された場合（Ｓ３：停止中）、連続的オン又は断続的オンが要求されているか否かを判断する（ステップＳ４）。ＣＰＵ７１は、連続的オン即ちここではスモールランプ１２，１２の点灯、又は、断続的オン、即ちここではスモールランプ１２，１２の点滅が要求されていると判断した場合（Ｓ４：ＹＥＳ）、制御対象の動作状態をオン状態、即ちスモールランプ１２，１２の動作状態をオン（点灯）状態とし（ステップＳ５）、実際にスモールランプ１２，１２へオン信号を出力すべく入出力ドライバ１０７へ指示し（ステップＳ６）、処理を終了する。

なお、ステップＳ４にてＣＰＵ７１は、連続的オン及び断続的オンのいずれの動作も要求されていないと判断した場合（Ｓ４：ＮＯ）、停止中状態を維持するため処理をそのまま終了する。

ステップＳ３にて、ＣＰＵ７１は、スモールランプ１２，１２への現在の動作状態の内容がオン（点灯）であると判断した場合（Ｓ３：オン）、動作要求に対応する制御対象の固有パラメータの内の、現在のオンとなってからの経過時間、即ちここではスモールランプ１２，１２の点滅又は点灯要求に対応するオンとなってからの経過時間を参照し、経過時間が、与えられている動作パターンの動作特定要素の内のオン時間を経過しているか否かを判断する（ステップＳ７）。

ＣＰＵ７１はステップＳ７にて、オン時間が経過していると判断した場合（Ｓ７：ＹＥＳ）、与えられている動作パターンの動作特定要素の動作方式が断続的オンのときは動作回数、即ちここでは点滅回数を加算し（ステップＳ８）、実際にスモールランプ１２，１２へオフ信号を出力すべく入出力ドライバ１０７へ指示する（ステップＳ９）。

次にＣＰＵ７１は、ステップＳ８で加算した後の動作回数は、即ちここでは点滅回数は、与えられている動作パターンの動作特定要素の内の動作回数を超えているか否かを判断する（ステップＳ１０）。ＣＰＵ７１は、ステップＳ１０にて動作回数を超えていないと判断した場合（Ｓ１０：ＮＯ）、断続的オン、即ち点滅動作は継続するので制御対象の動作状態の内容をオフ状態、即ちここではスモールランプ１２，１２の動作状態を消灯状態へ遷移させ（ステップＳ１１）、処理を終了する。ＣＰＵ７１は、ステップＳ１０にて動作回数を超えていると判断した場合（Ｓ１０：ＹＥＳ）、断続的オン、即ち点滅動作は終了するので動作状態の内容を停止状態へ遷移させ（ステップＳ１２）、処理を終了する。

ＣＰＵ７１はステップＳ７にて、オン時間が経過していないと判断した場合（Ｓ７：ＮＯ）、オン状態即ち点灯状態を維持するため処理をそのまま終了する。

ステップＳ３にて、ＣＰＵ７１は、スモールランプ１２，１２への現在の動作状態の内容がオフ（消灯）であると判断した場合（Ｓ３：オフ）、動作要求に対応する制御対象の固有パラメータの内の、現在のオフとなってからの経過時間、即ちここではスモールランプ１２，１２の点滅又は点灯要求に対応するオフとなってからの経過時間を参照し、経過時間が、与えられている動作パターンの動作特定要素の内のオフ時間を経過しているか否かを判断する（ステップＳ１３）。

ＣＰＵ７１はステップＳ１３にて、オフ時間が経過していると判断した場合（Ｓ１３：ＹＥＳ）、制御対象の動作状態をオン状態、即ちスモールランプ１２，１２の動作状態をオン（点灯）状態とし（ステップＳ１４）、実際にスモールランプ１２，１２へオン信号を出力すべく入出力ドライバ１０７へ指示し（ステップＳ１５）、処理を終了する。

なお、ステップＳ１３にてＣＰＵ７１は、オフ時間が経過していないと判断した場合（Ｓ１３：ＮＯ）、オフ状態を維持するため処理をそのまま終了する。

上述のような処理により、各制御対象の固有パラメータの内の動作状態と、動作回数、及び経過時間の内容を変更することにより、各制御対象及び該制御対象夫々に対して動作要求を発するアプリケーションプログラム毎にオブジェクトが実体化されて処理が行なわれているようなオブジェクト指向的な処理が実現できる。なお、車載ＥＣＵなどでは、制御対象毎に巡回的に高速に処理を実行すればよい点が利用され、同一のプログラムコードを用いている。更に、上述のように１つのアプリケーションドライバプログラム７６のプログラムコードを複数の制御対象及び複数の機能を実現するアプリケーションプログラム７５，７５，…に基づく制御に対応させて用いることにより、処理の実行中にＲＡＭ７３に対しプログラムコードが占有する容量が少なくて済み、また、動的に容量が確保されることもなく煩雑なメモリ管理も要しないので、マイコンに基づくＥＣＵにおける処理に適している。

このようにＲＯＭ７２及びＲＡＭ７３の記憶容量を節約できるのでボディＥＣＵ７の内部構成を簡素化させることができる。更に、ボディＥＣＵ７にて実現したい機能毎に、アプリケーションドライバプログラム７６に対応するプログラムを実装せずとも、共有化されたアプリケーションドライバプログラム７６の機能を共有化するから、開発時は選択部１０５としての機能に対するインタフェースを考慮すればアプリケーションプログラム７５，７５，…の開発のみで済み、開発効率を向上させることができる

（実施の形態２）
実施の形態１では、図４に示したように、動作パターンテーブル７７の具体的内容は、制御対象毎の動作パターンを一覧にした構成とした。これに対し、実施の形態２における動作パターンテーブル７７の内容は、動作パターンを特定する動作特定用素毎の内容を特定する形式であり、いずれの制御対象でも単一の動作パターンテーブル７７を利用する構成とする。

実施の形態２における車載制御システムの構成は、動作パターンテーブル７７の内容以外は、実施の形態１における構成と共通である。したがって、以下の説明では、実施の形態１の構成と共通する構成について実施の形態１と同一の符号を用い、相違点である動作パターンテーブル７７の具体的内容、及びそれを用いた動作パターンの特定の方法について説明する。

図８は、実施の形態２におけるボディＥＣＵ７のＲＯＭ７２に記憶されている動作パターンテーブル７７の内容例を示す説明図である。図８に示すように、実施の形態２における動作パターンテーブル７７は、時間テーブル、動作方式テーブル及び回数テーブルのように動作特定要素毎にテーブル化されており、いずれからも番号で内容を選択して動作特定要素を特定することができる。

図８に示す例では、時間テーブルには、待機時間又はオン時間、オフ時間の内容を特定する候補として「０ｍｓ」、「５ｍｓ」などが含まれており、夫々識別情報として番号で選択が可能である。動作方式テーブルには動作方式として連続的オン、断続的オンを含み、番号で選択できる。なお、スモールランプ１２，１２に対して動作方式として連続的オンを選択した場合、具体的な動作は点灯であるし、断続的オンを選択した場合、具体的な動作は点滅である。更に、回数テーブルには回数を特定する候補として「０」、「１」、「２」などが含まれており、これも番号で選択が可能である。

例えば、図４の説明図に示した番号「１」の動作パターンは、図８に示した動作パターンテーブル７７の内容を用いれば、待機時間は「１」、動作方式は「２」、回数は「２」オン時間及びオフ時間は「５」及び「１」として、（待機時間、動作方式、回数、オン時間、オフ時間）＝（１，２，２，５，１）のようにパラメータとして動作パターンを特定して出力ドライバ部１０６へ与えることができる。

このような動作パターンテーブル７７の内容とすることにより、ＲＯＭ７２を更に節約することができ、効果的である。また、実施の形態１のような負荷毎に動作パターンを予め記憶しておく場合には、新たなパターンが増えた場合には動作パターンテーブル７７に追加しなければならないが、実施の形態２のような構成とすることにより、各制御対象について選択部１０５の機能により自由な動作パターンを選択することが可能となる。したがって、多様な動作を実現できる点でも効果的である。

（変形例）
上述のようなボディＥＣＵ７において、マイコン７０のＣＰＵ７１は選択部１０５としての機能により、次のような処理を行なう構成としてもよい。つまり、ＫＡＢアプリ１０３若しくはＳＡＢアプリ１０４、又は新たなアプリケーションプログラム７５に基づくアプリにより、新たな動作要求がされた場合、選択部１０５は動作パターンテーブル７７に対応する動作パターンが無いことを確認して新たに動作パターンを追加する。

図９は、選択部１０５としての機能によりＣＰＵ７１が動作要求に対応する動作パターンを新たに動作パターンテーブル７７に追加する処理手順の一例を示すフローチャートである。

ＣＰＵ７１は、選択部１０５としての機能により、ＫＡＢアプリ１０３又はＳＡＢアプリ１０４を含む各アプリケーションプログラム７５，７５，…に基づく各アプリからの動作要求を受け付ける（ステップＳ２１）。ＣＰＵ７１は、動作パターンテーブル７７に、受け付けた動作要求に対応する動作パターンが有るか否かを判断する（ステップＳ２２）。

ＣＰＵ７１は、動作要求に対応する動作パターンが有ると判断した場合（Ｓ２２：ＹＥＳ）、対応する動作パターンを選択して（ステップＳ２３）、出力ドライバ部１０６の機能へ動作パターンを特定する情報を与え（ステップＳ２４）、処理を終了する。

ＣＰＵ７１は、ステップＳ２２にて動作要求に対応する動作パターンが無いと判断した場合（Ｓ２２：ＮＯ）、受け付けた動作要求に対応する動作パターンを特定する（ステップＳ２５）。具体的には、例えば動作要求が「２回点滅要求」などを識別可能な命令「blink（回数パラメータ）」などのコマンドであれば、動作パターンテーブル７７の内容が制御対象毎であるときには制御対象に対する「２」回「点滅」する動作パターンの有無を判断すればよい。また、動作パターンテーブル７７の内容が、動作特定要素毎であって、例えば回数テーブルに「２」に対応する候補の有無で判断すればよい。

ＣＰＵ７１は、ステップＳ２５で特定した動作パターンを新たに作成して追加し（ステップＳ２６）、出力ドライバ部１０６の機能へ動作パターンを特定する情報を与え（Ｓ２４）、処理を終了する。

ステップＳ２６において、新たに動作パターンを追加する場合、動作パターンテーブル７７が制御対象毎の動作パターンである場合は特定した動作パターンの動作特定要素を夫々設定して追加し新たな番号を付与する。動作パターンテーブル７７が動作特定用素毎のテーブルである場合、新たな候補をいずれかの動作特定要素のテーブルに追加する。例えば動作要求が上述のように「２」回「点滅」である場合に、回数テーブルに「２」が存在しなかったときは、ステップＳ２６にて回数テーブルに「２」を追加すればよい。

このように、動作パターンテーブル７７の内容を更新することが可能とするように選択部１０５の機能を構成することにより、メモリを節約する構成で且つオブジェクト指向的な処理が可能であると共に、更に多様な動作を実現することができる。

更に、ボディＥＣＵ７のマイコン７０のＣＰＵ７１は、選択部１０５としての機能により、次のような処理を行なう構成としてもよい。ＫＡＢアプリ１０３若しくはＳＡＢアプリ１０４、又は新たなアプリケーションプログラム７５に基づくアプリにより動作要求が同時的にされた場合、選択部１０５は優先度が高いアプリからの動作要求を優先して受け付ける。以下に示す例では、セキュリティに関するＳＡＢアプリ１０４が最も優先度が高いとする。なお、優先度の高低はＲＯＭ７２に記憶されており、マイコン７０のＣＰＵ７１が参照可能である。

図１０は、動作要求の要求元のアプリケーションプログラムの優先度に応じて、ＣＰＵ７１が制御対象及び動作の内容を優先的に選択する処理手順の一例を示すフローチャートである。

ＣＰＵ７１は、選択部１０５としての機能により、ＫＡＢアプリ１０３又はＳＡＢアプリ１０４を含む各アプリケーションプログラム７５，７５，…に基づくアプリからの動作要求を受け付ける（ステップＳ３１）。

ＣＰＵ７１は、他のアプリから他に動作要求を受け付けているか否かを判断する（ステップＳ３２）。ＣＰＵ７１は、他に動作要求を受け付けていると判断した場合（Ｓ３２：ＹＥＳ）、受け付けている動作要求の要求元の各アプリのうちの最も優先度が高いアプリからの動作要求を優先させる（ステップＳ３３）。他の動作要求については保持しておく。

ＣＰＵ７１は優先させた動作要求に対応する動作パターンを選択し（ステップ３４）、処理を終了する。ＣＰＵ７１は以降、実施の形態１の図７のフローチャートに示した処理を実行する。

ＣＰＵ７１は、ステップＳ３２にて他に動作要求を受け付けていないと判断した場合（Ｓ３２：ＮＯ）、そのままステップＳ３１で受け付けた動作要求に対応する動作パターンを選択し（Ｓ３４）、処理を終了し、図７のフローチャートに示した処理を実行する。

このように、アプリケーション層１０１の選択部１０５及び出力ドライバ部１０６の機能は１つに共有化して再利用できる一方で、各アプリケーションプログラム７５，７５，…が対応する機能の内、優先度が高い機能を優先的に実現させるべく適宜選択することができる。なおこのとき、出力ドライバ部１０６では、いずれの負荷への信号出力が優先的かを判断する必要がない。優先度の設定は、各動作要求を一括して受け付ける選択部１０５で変更でき、当該ソフトウェア構成は柔軟性に優れる。

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

実施の形態１における車載制御システムの構成を示す構成図である。 実施の形態１における車載制御システムに含まれるボディＥＣＵの内部構成を示すブロック図である。 実施の形態１におけるボディＥＣＵのマイコンのＣＰＵにて実現される機能を概念的に示す機能ブロック図である。 実施の形態１におけるボディＥＣＵのＲＯＭに記憶されている動作パターンテーブルの内容例を示す説明図である。 ＣＰＵが出力ドライバ部として機能する際の処理の具体例を概念的に示す説明図である。 オブジェクト指向型における各制御対象毎の制御処理用のプログラムの実現例を比較例として示す説明図である。 ＣＰＵが出力ドライバ部として機能する際の処理手順の具体例を示すフローチャートである。 実施の形態２におけるボディＥＣＵのＲＯＭに記憶されている動作パターンテーブルの内容例を示す説明図である。 選択部としての機能によりＣＰＵが動作要求に対応する動作パターンを新たに動作パターンテーブルに追加する処理手順の一例を示すフローチャートである。 動作要求の要求元のアプリケーションプログラムの優先度に応じて、ＣＰＵが制御対象及び動作の内容を優先的に選択する処理手順の一例を示すフローチャートである。 従来のマイコンにおけるコンピュータプログラムの構成の概略を示す概略図である。

符号の説明

１０ ヘッドライト（負荷）
１１ 方向指示器ランプ（負荷）
１２ スモールランプ（負荷）
２ ホーン（負荷）
３ ブザー（負荷）
７ ボディＥＣＵ（制御装置）
７０ マイコン（マイクロコンピュータ）
７２ ＲＯＭ（記憶手段）
７５ アプリケーションプログラム
７６ アプリケーションドライバプログラム（コンピュータプログラム）
７７ 動作パターンテーブル
１０５ 選択部（選択手段）
１０６ 出力ドライバ部（出力手段）

Claims (8)

1. マイクロコンピュータを備え、該マイクロコンピュータが各機能に対応する複数のアプリケーションプログラムに基づく処理を行なうことにより複数の負荷の動作を制御する制御装置において、
   前記複数のアプリケーションプログラムに基づく処理からの動作要求を受け付け、該動作要求及び要求元のアプリケーションプログラムに対応する機能に応じて制御対象の負荷、及び該負荷に行なわせる動作を選択する選択手段、及び、
   該選択手段が選択した負荷、及び動作を示す情報が与えられた場合に、前記動作を実現させる制御信号を生成して前記負荷へ出力する出力手段
   を備えることを特徴とする制御装置。
2. 連続的オン、オフ、断続的オン、待機時間、又は断続的オンの場合の回数若しくはオン時間及びオフ時間を含む動作特定要素の内のいずれか一又は複数の組み合わせからなり、各々識別情報が付与された動作パターンのテーブルを記憶する手段を備え、
   前記選択手段は、前記テーブルから前記動作要求に対応する動作パターンを抽出し、抽出した動作パターンに付与されている識別情報を前記出力手段に与え、
   前記出力手段は、前記識別情報により動作を特定するようにしてあること
   を特徴とする請求項１に記載の制御装置。
3. 前記テーブルは制御対象の負荷毎に記憶されており、
   前記選択手段は、前記動作要求に応じて選択した負荷と、該負荷のテーブルから抽出した動作パターンに付与されている識別情報とを前記出力手段に与えるようにしてあること
   を特徴とする請求項２に記載の制御装置。
4. 前記テーブルは、前記動作特定要素毎に記憶されており、
   前記選択手段は、前記動作要求に応じて選択した負荷に行なわせる動作を、前記動作特定要素毎のテーブルから夫々動作パターンを読み出して組み合わせるようにしてあり、
   選択した負荷を示す情報と、組み合わせた動作パターン夫々に付与されている識別情報の組み合わせとを前記出力手段に与えるようにしてあること
   を特徴とする請求項２に記載の制御装置。
5. 前記選択手段は、前記動作要求に対応する動作パターンが前記テーブルに存在しない場合、前記動作パターンを前記テーブルに追加する手段を備えること
   を特徴とする請求項２に記載の制御装置。
6. 前記複数のアプリケーションプログラムには優先度が付与されており、
   前記選択手段は、複数のアプリケーションプログラムに基づく処理から夫々複数の動作要求を受け付けた場合、前記複数のアプリケーションプログラムの内の優先度が高いアプリケーションプログラムからの動作要求に応じた負荷及び動作を選択するようにしてあること
   を特徴とする請求項１乃至５に記載の制御装置。
7. マイクロコンピュータを用い、該マイクロコンピュータに各機能に対応する複数のアプリケーションプログラムに基づく処理を行なわせることにより複数の負荷の動作を制御する方法において、
   前記マイクロコンピュータが前記複数のアプリケーションプログラムと異なるコンピュータプログラムに基づき、
   前記アプリケーションプログラムに基づく処理からの動作要求を受け付け、
   受け付けた動作要求及び要求元のアプリケーションプログラムに対応する機能に応じて制御対象の負荷、及び該負荷に行なわせる動作を選択し、
   選択した負荷及び動作を示す情報に基づき、前記動作を実現させる制御信号を生成して前記負荷へ出力する
   ことを特徴とする制御方法。
8. 制御対象である複数の負荷が接続されているコンピュータに、アプリケーションプログラムに基づく処理を行なわせて前記複数の負荷の動作を制御させるコンピュータプログラムにおいて、
   コンピュータに、
   前記アプリケーションプログラムに基づく処理からの動作要求及び要求元のアプリケーションプログラムに対応する機能に応じて制御対象の負荷、及び該負荷に行なわせる動作を選択する選択手段、及び、
   該選択手段が選択した負荷、及び動作を示す情報が与えられた場合に、前記動作を実現させる制御信号を生成して前記負荷へ出力する出力手段
   として機能させることを特徴とするコンピュータプログラム。

Images