制御装置、制御方法及びコンピュータプログラム
【課題】組み込み系のコンピュータプログラムにオブジェクト指向型の概念を適用し、メモリを節約して装置の簡素化を実現させ、開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムを提供する。
【解決手段】マイコンはアプリケーション層１０１における１つの入力信号判定モジュール１０７の機能により、複数のアプリ（１０３，１０４）夫々にて制御対象に対し動作を要求する状況にあるか否か、制御対象の状態情報、又はセンサからの情報などを示す入力信号に対する判定処理が共通化される。
【解決手段】マイコンはアプリケーション層１０１における１つの入力信号判定モジュール１０７の機能により、複数のアプリ（１０３，１０４）夫々にて制御対象に対し動作を要求する状況にあるか否か、制御対象の状態情報、又はセンサからの情報などを示す入力信号に対する判定処理が共通化される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータプログラムに基づき各種負荷の動作制御を行なう制御装置に関する。特に、コンピュータプログラムの構成を、メモリを節約させることを可能とする構成として装置の簡素化を実現させ、且つ各負荷用の多様な機能の増減に柔軟に対応させることができ、開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムに関する。
【背景技術】
【０００２】
マイクロコンピュータ（以下、マイコンという）を利用し、マイコン内蔵ＲＯＭに書き込まれたコンピュータプログラムに基づいて制御を行なう制御装置の場合、コンピュータプログラムは所謂組み込み系の言語で記述される。組み込み系の言語で記述するコンピュータプログラムは、装置の簡素化のためにメモリなどリソースを節約し、必要最低限の処理を制御対象毎に、且つ機能毎に実装する構成が基本的である。
【０００３】
図１２は、従来のマイコンにおけるコンピュータプログラムの構成の概略を示す概略図である。図１２に示すコンピュータプログラムの構成は特に、制御対象（負荷Ｘ）の動作を制御する制御装置にてマイコンにより実行されるコンピュータプログラムの例を示している。図１２は、コンピュータプログラムにより実現される機能をブロックにて示している。図１２の例のコンピュータプログラムによって負荷Ｘを制御対象とする機能が実現される場合、図１２に示すように、当該コンピュータプログラムは例えば、機能毎に、センサ又は負荷から入力される信号Ａ，Ｂ，Ｃ夫々に対する判定処理、入力信号の判定結果に基づき機能を実現するため負荷Ｘに要求する動作を判定する判定処理、負荷への動作要求の信号出力の調停、動作毎の負荷への信号出力などの機能が、アプリケーションプログラムにより実現したい機能（ア）及び機能（イ）夫々に対応して実現される。
【０００４】
コンピュータプログラムの実装上も、夫々の機能に応じたプログラムコード（実行ファイル）が作成され、いずれのプログラムコードもメモリ上に予め記憶されており、ＣＰＵにより読み出される。したがって、図１２に示したブロック夫々に応じてメモリが占有される。したがって、例えば入力信号に対する判定処理は、機能（ア）及び（イ）毎に、更に信号Ａ，Ｂ，Ｃ毎にプログラムコードが夫々存在する。
【０００５】
図１２に示した例では、機能が（ア）と（イ）とで異なるのみで同一の入力信号Ａに対しても夫々、入力信号判定部に対応するプログラムコードが存在する構成である。機能（ア）と（イ）とが同時並行的に実行される可能性がない場合、夫々存在する構成ではメモリの使用が非効率的である。
【０００６】
また、入力信号に対する判定処理は、概ね信号レベルがＨｉかＬｏｗかに基づき、スイッチがＯＮかＯＦＦか、ロックかアンロックかなどを判定するものである。即ち、入力信号の内容が異なるのみで、判定処理の具体的な処理内容はいずれも信号レベルがＨｉかＬｏｗかであって共通している。この判定処理のためのプログラムコードが種々の入力信号夫々に存在する構成では、メモリの使用が非効率的である。
【０００７】
しかもこの場合、各入力信号Ａ，Ｂ，Ｃに対する判定は同時的に行なわれるのではなしに、シーケンシャルに各入力信号Ａ，Ｂ，Ｃに対する判定がされ、判定結果に応じた動作もシーケンシャルに行なわれて、入力信号の判定処理のためのプログラムコードに占有されるメモリが同時的にアクセスされることもないにも拘わらず、マイコンに実行させるための各動作に対応するプログラムコードがいずれも、メモリを予め占有するので、メモリ
の使用効率が非効率的である。
【０００８】
これに対し、制御装置に求められる機能の多様化、複雑化が進むにつれ、オブジェクト指向型の言語によって記述されるプログラムをマイコンが読み出して実行する制御装置も提案されている（特許文献１など参照）。このように、処理が実行される都度にメモリが確保され、処理が終了した場合にはメモリが開放されて他に使用できるなど、メモリを効率的に利用することができる。しかしながらこの場合、プログラム実行中にメモリを動的に確保するなどの処理をマイコンに実現させる基本機能（ライブラリ）などが必要である。このようにオブジェクト指向に基づく設計では、基本機能を実現するためのライブラリプログラムコードがメモリを使用する上、動的なメモリ確保、動的なライブラリのリンクなどの処理が想定され、オブジェクト指向型のコンピュータプログラムの構成により各種機能が実現できるのはメモリの記憶容量に余裕があるからである。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００８−７７２２０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、負荷制御を行なうマイコンを用いた制御装置では、メモリの容量に制限があるからこそ組み込み系の言語で記述されるコンピュータプログラムを利用するのであって、メモリの記憶容量に余裕を持たせてもよい特定の制御装置以外では、オブジェクト指向型のソフトウェア構成は適していない。一方で、従来のコンピュータプログラムの構成のように、共有できる処理であっても種々の入力信号毎、制御対象である負荷毎、及び機能毎にプログラムコードがメモリを占有する構成では上述のようにメモリの使用が非効率的である。共通する同様な処理は共有化して再利用が可能な構成とし、共有化された処理はそれに対応するプログラムコードのみでメモリを占有することが望ましい。
【００１１】
本発明は斯かる事情に鑑みてなされたものであり、組み込み系のコンピュータプログラムにオブジェクト指向型の概念を適用し、メモリを節約して装置の簡素化を実現させ、開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
第１発明に係る制御装置は、複数の制御対象の状態情報又は複数のセンサからの検知情報を示す信号の入力を受け付けるマイクロコンピュータを備え、該マイクロコンピュータが複数のアプリケーションプログラムに基づく処理を行ない、入力信号から判断される状況に応じて、前記複数の制御対象の内のいずれかへ動作要求を出力して前記制御対象の動作を制御するようにしてある制御装置において、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定する判定手段と、複数の入力信号から、アプリケーションプログラムの機能毎に１又は複数の入力信号を抽出する抽出手段と、機能毎に抽出した１又は複数の入力信号、及び該入力信号に対応する判定条件を、前記判定手段に与え、前記判定手段からの各判定結果に応じて、動作要求を出力する状況であるか否かを判断する判断手段とを備えることを特徴とする。
【００１３】
第２発明に係る制御装置は、機能毎に、前記判定手段へ与える入力信号及び判定条件、並びに、前記判定手段へ入力信号及び判定条件を与えた場合の判定結果に応じて次に与えるべき入力信号及び判定条件を示す分岐条件情報を記憶する手段を備え、前記判断手段は、前記分岐条件情報に基づき、各判定結果に応じて次の入力信号及び判定条件を選択して与えるようにしてあることを特徴とする。
【００１４】
第３発明に係る制御装置は、入力信号毎に判定条件を示すテーブルを備え、前記分岐条件情報は、次に与えるべき入力信号の判定条件の参照箇所を示すアドレスを含むことを特徴とする。
【００１５】
第４発明に係る制御装置は、前記判断手段は、前記分岐条件情報に基づいて入力信号及び判定条件を前記判定手段へ順次与えた場合の最後の判定結果が成立である場合、動作要求を出力する状況であると判断するようにしてあることを特徴とする。
【００１６】
第５発明に係る制御装置は、各機能に対応する入力信号、及び該入力信号への判定条件を示すテーブルを機能毎に備え、前記抽出手段は、前記テーブルに基づいて入力信号を抽出するようにしてあることを特徴とする。
【００１７】
第６発明に係る制御方法は、複数の制御対象の状態情報又は複数のセンサからの検知情報を示す信号の入力を受け付けるマイクロコンピュータを用い、該マイクロコンピュータに複数のアプリケーションプログラムに基づく処理を行なわせると共に、前記マイクロコンピュータは、前記複数のアプリケーションプログラムと異なるコンピュータプログラムに基づき、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定する判定手段として機能し、入力信号から判断される状況に応じて、前記複数の制御対象の内のいずれかへ動作要求を出力させて前記制御対象の動作を制御する方法であって、前記マイクロコンピュータは、前記アプリケーションプログラムに基づく処理により、機能毎に、該機能に関する入力信号を１又は複数抽出し、抽出した１又は複数の入力信号、及び該入力信号に対応する判定条件を前記判定手段へ順次与え、前記判定手段からの各判定結果に応じて、動作要求を出力する状況であるか否かを判断し、出力する状況であると判断した場合に動作要求を出力させることを特徴とする。
【００１８】
第７発明に係るコンピュータプログラムは、複数の制御対象又は複数のセンサが接続され、前記制御対象の状態情報又は前記センサからの検知情報を示す信号の入力を受け付けるコンピュータに、複数のアプリケーションプログラムに基づき、入力信号から判断される状況に応じて複数の制御対象の内のいずれかへ動作要求を出力させて前記制御対象を動作させる処理を実行させる際に、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定させる判定手段として機能させるコンピュータプログラムであって、コンピュータを、アプリケーションプログラムの機能毎に抽出された１又は複数の入力情報、及び該入力情報に対応する判定条件、前記判定手段へ与える手段、及び、１又は複数の入力情報を与えて前記判定手段により得られた各判定結果により、動作要求を出力する状況であるか否かを判断する手段として機能させることを特徴とする。
【００１９】
第１発明、第６発明及び第７発明では、マイクロコンピュータが、制御対象の制御状態の情報又は各センサが検知した情報を示す入力信号から、複数の機能を夫々実現するアプリケーションプログラムの処理において当該機能に対応する動作要求を出力する状況にあるか否かを判断するに際し、入力信号に対する判定処理が判定手段によって実行される。複数の機能夫々に応じて制御対象を動作させるか否かを判断させるための信号が夫々が抽出され、判定手段で抽出された各入力信号に対して判定条件が成立するか否かが判定される。判定手段による各判定結果に基づいて、動作要求を出力する状況にあるか否かが判断される。
【００２０】
このとき、複数のアプリケーションプログラムに基づく処理が実行されるのに対し、入力信号に対する判定条件の成否を判定する判定手段は、複数のアプリケーションプログラムに共有される構成である。これにより、従来では処理の内容が重複するにも拘わらず、各アプリケーションプログラムに対応する入力信号に対して別個に実行されていた判定処
理が共有化される。
【００２１】
第２発明では、機能毎に、該機能に対応する制御を実行する状況にあるかを判断するための判定対象の入力信号及び各入力信号に対する判定条件と、判定条件の判定結果に応じて次に与えるべき入力信号を示す情報とからなる分岐条件情報が記憶され、当該分岐条件情報に基づき判定がなされる。判定対象が分岐条件に基づいて切り替わることで１つの判定手段が同一の判定処理を実行する構成でも、各々固有の信号に対する判定処理を実行する構成と同じ結果が得られる。
【００２２】
第３発明では、入力信号毎の判定条件はテーブル化されており、分岐条件情報は、各判定条件の結果に応じた次の入力信号に対する判定条件の参照箇所を示している。判定手段は、示される参照箇所の判定条件を参照して入力信号が一致するか否かの判定処理を、判定対象の信号が変わったとしても変わらずに行なう構成で、異なる入力信号に対する判定が、判定結果に応じた分岐に従って行なわれる。これにより、共通の１つの判定手段により、種々の入力信号に対する判定を実行できる。
【００２３】
第４発明では、分岐条件情報に基づく判定手段の処理により最終的に得られた判定結果が示す成否が、動作要求を出力する状況か否かである。判定手段が、複数の入力信号に対して判定結果を返す処理を変わらず実行することにより、最終的な判断結果が得られる。
【００２４】
第５発明では、判定対象となるべき入力信号と、各入力信号に対する判定条件とが機能毎にテーブルにて記憶されてもよい。機能が指定された場合に判定すべき入力信号を抽出され、判定対象の入力信号の判定の順序に関わらず、抽出された入力信号の内のいずれかについて判定条件が不成立の場合に判定結果は不成立となる。
【発明の効果】
【００２５】
本発明による場合、組み込み系のコンピュータプログラムに基づき制御を行なう制御装置でも、各機能を実現させる動作について、動作を行なう状況であるか否かを判断するための入力信号に対する判定処理を各機能に共有化し、１つの判定手段の機能を種々の入力信号に対する判定処理に利用する。
【００２６】
これにより、種々の入力信号夫々に対して入力信号の判定処理を行なわせるプログラムコードが種々の入力信号毎に、且つ機能毎に記憶されて実行される構成よりも、共通して利用できるプログラムコードを１つメモリに記憶して実行可能に構成しておくことにより各機能を実現可能であるからメモリの占有量は少なくて済む。メモリを節約できるので装置を簡素化させることができる。更に、入力信号自体と、判定結果の関係を変えて共有化された判定手段の機能を再利用すればよいので、新たな入力信号に対する判定処理が加わったとしても、これに対するプログラムは実装せずとも、入力信号と該入力信号に対応する判定条件とを与える構成を守ればアプリケーションプログラムの開発のみで済み、開発効率を向上させることができる点、優れた効果を奏する。
【図面の簡単な説明】
【００２７】
【図１】実施の形態１における車載制御システムの構成を示す構成図である。
【図２】実施の形態１における車載制御システムに含まれるボディＥＣＵの内部構成を示すブロック図である。
【図３】実施の形態１におけるボディＥＣＵのマイコンのＣＰＵにて実現される機能を概念的に示す機能ブロック図である。
【図４】実施の形態１におけるボディＥＣＵのＲＯＭに記憶されている判定テーブルの内容例を示す説明図である。
【図５】実施の形態１におけるリンク情報の内容例を模式的に示す説明図である。
【図６】実施の形態１における入力信号判定モジュールにより実行される処理手順の一例を示すフローチャートである。
【図７】実施の形態１における入力信号判定モジュールによる判定処理の過程を概念的に示す説明図である。
【図８】ＣＰＵが入力信号判定モジュールとして機能する際の処理の具体例を概念的に示す説明図である。
【図９】実施の形態２におけるＲＯＭに記憶されている判定テーブルの基本構成を示す説明図である。
【図１０】実施の形態２における判定テーブルの内容例を示す説明図である。
【図１１】実施の形態２における入力信号判定モジュールにより実行される処理手順の一例を示すフローチャートである。
【図１２】従来のマイコンにおけるコンピュータプログラムの構成の概略を示す概略図である。
【発明を実施するための形態】
【００２８】
以下、本発明をその実施の形態を示す図面に基づいて具体的に説明する。なお、以下に示す実施の形態では、車両の室内に搭載されているランプ、ライト、ドア、ワイパーなどのボディ系の各種制御対象を制御する車載ボディＥＣＵに本発明の制御装置を適用した車載制御システムを例に挙げて説明する。
【００２９】
（実施の形態１）
図１は、実施の形態１における車載制御システムの構成を示す構成図である。車載制御システムは、車室内の前部天井に取り付けられるルームランプ１と、車両のドア部に設置され、ドアの開閉を検知するカーテシセンサ２，２及びドアロックを検知するドアロックセンサ３，３と、イグニッション（Ignition）キー（以下、ＩＧキーという）の挿抜を検知するＩＧキーセンサ４と、夫々を制御するボディＥＣＵ５とを含む。
【００３０】
ルームランプ１はボディＥＣＵ５に接続されており、ボディＥＣＵ５により点灯、消灯が制御される。なお、点灯、消灯のいずれにおいてもＰＷＭ制御により減光、増光が可能である。
【００３１】
カーテシセンサ２，２及びドアロックセンサ３，３はボディＥＣＵ５に接続されており、夫々ドア開閉状態を知らしめる信号又はドアロックの開閉状態を知らしめる信号をボディＥＣＵ５へ出力する。
【００３２】
ＩＧキーセンサ４はボディＥＣＵ５に接続されており、ＩＧキーセンサ４にて検知したＩＧキーの挿抜、及びキー位置を示す信号をボディＥＣＵ５へ出力する。
【００３３】
ボディＥＣＵ５は、カーテシセンサ２，２、ドアロックセンサ３，３又はＩＧキーセンサ４から出力される各信号を入力して、それらの信号レベルに基づき、例えば、ドアが閉状態で、ＩＧキーは挿入されていない状態で、ドアロックがロックからアンロックへ変化した場合には、乗車しようとするユーザによりドアが開錠された状況にあるから、ルームランプ１を点灯させるべく制御信号を出力するエントリー制御を実現する。また、同様にドアが閉状態で、ＩＧキーは挿入されていない状態で、ドアロックがアンロックからロックへ変化した場合には、降車したユーザがドアが施錠された状況にあるから、点灯していたルームランプ１を少しずつ減光させて消灯させるべく制御信号を出力するドアロック減光制御を実現する。
【００３４】
なお、実施の形態１では、ボディＥＣＵ５について、ルームランプ１の点灯に関する機能各構成部の処理のみ記載するが、ボディＥＣＵ５が他の機能を実現するために他の制御
対象となる負荷（アクチュエータ）、例えばヘッドライト、スモールランプ、フロントワイパー、リアワイパーなどを制御することが可能な構成でもよいことは勿論である。
【００３５】
このような各種機能をボディＥＣＵ５にて実現するためのボディＥＣＵ５内部の構成及び処理について説明する。ボディＥＣＵ５は後述するように、マイコン５０を備えて、マイコン５０内臓のＲＯＭ（Read Only Memory）５２に記憶されているコンピュータプログラムに基づく処理を実行することにより各種機能を実現する。
【００３６】
図２は、実施の形態１における車載制御システムに含まれるボディＥＣＵ５の内部構成を示すブロック図である。ボディＥＣＵ５は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ（Random
Access Memory）５３及びＩ／Ｏ５４を含むマイコン５０を備えて構成される。他に、カーテシセンサ２，２、ドアロックセンサ３，３、キーセンサ４などのセンサと車載ネットワークを介して接続される場合は通信手段としてネットワークコントローラ、トランシーバをマイコン５０内又は外に備える構成としてもよい。
【００３７】
ＣＰＵ５１は、ＲＯＭ５２に記憶されているコンピュータプログラムをＲＡＭ５３に読み出して実行することにより、上述のようなルームランプ１の点灯、消灯、減光機能を実現する。
【００３８】
ＲＯＭ５２には、フラッシュメモリを利用する。ＲＯＭ５２には、ＣＰＵ５１が読み出して実行するコンピュータプログラムとして、ボディ系に関する各機能を実現するためのアプリケーションプログラム５５，５５，…、アプリケーションドライバプログラム５６、入力信号判定モジュールプログラム５７が記憶されている。他に接続されるルームランプ１などの各種負荷との信号の物理層における入出力を実現するためのドライバプログラム（図示せず）が記憶されている。またＲＯＭ５２には、ＣＰＵ５１が各センサからの入力信号が示す状態を判定するために参照する判定テーブル５８，５８，…が負荷毎に記憶されている。そして、機能毎に、判定テーブル５８，５８，…間のリンク関係を示すリンク情報５９が記憶されている。
【００３９】
なお、ＲＯＭ５２は基本的に、ボディＥＣＵ５の稼働中は読み出し専用（ＲＯＭ）ではあるが、ＣＰＵ５１に実行させたいコンピュータプログラムの更新、又は判定テーブル５８，５８，…の更新が必要な場合に書換が可能である。
【００４０】
ＲＡＭ５３には、ＤＲＡＭ（Dynamic RAM）、ＳＲＡＭ（Static RAM）等を利用する。ＲＡＭ５３にはＣＰＵ５１が読み出すコンピュータプログラムがロードされる他、処理によって発生する各種情報が一時的に記憶される。
【００４１】
Ｉ／Ｏ５４は、マイコン５０と外部とのインタフェースである。マイコン５１はＩ／Ｏ５４により、ルームランプ１へ制御信号を出力する。
【００４２】
次に、マイコン５０のＣＰＵ５１がＲＯＭ５２に記憶されているコンピュータプログラムを読み出して実現するマイコン５０内の詳細な機能について説明する。図３は、実施の形態１におけるボディＥＣＵ５のマイコン５０のＣＰＵ５１にて実現される機能を概念的に示す機能ブロック図である。
【００４３】
ＣＰＵ５１は、ＲＯＭ５２に記憶されているアプリケーションプログラム５５，５５，…、アプリケーションドライバプログラム５６、入力信号判定モジュールプログラム５７、及びその他ドライバプログラムなどを読み出して実行することにより、アプリケーション層１０１、プラットフォーム層１０２の階層に分けられたソフトウェア構造にて動作する。
【００４４】
ＣＰＵ５１がアプリケーションプログラム５５，５５，…の内、エントリー制御用のアプリケーションプログラム５５に基づき、エントリー制御アプリ１０３として機能する。同様にＣＰＵ５１は、ドアロック減光制御用のアプリケーションプログラム５５に基づき、ドアロック減光制御アプリ１０４として機能する。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４としての機能は構造的に、アプリケーション層１０１に位置する。
【００４５】
ＣＰＵ５１はアプリケーションドライバプログラム５６に基づき、選択部１０５及び出力ドライバ部１０６としての機能を実現する。選択部１０５及び出力ドライバ部１０６としての機能は、ハードウェア群（制御対象群、即ちルームランプ１、ヘッドライト、スモールランプ等）を直接的に制御すべく物理層の信号を扱う所謂ドライバの機能ではなく、エントリー制御アプリ１０３又はドアロック減光制御アプリ１０４などの各種アプリケーションの処理の内の信号生成処理などの共通部分を１つにしたモジュールであり、アプリケーション層１０１に位置する。
【００４６】
ＣＰＵ５１は、入力信号判定モジュールプログラム５７に基づき、入力信号判定モジュール１０７としての機能を実現する。入力信号判定モジュール１０７としての機能は、アプリからの入力信号判定の指示があった場合に、機能に関係する入力信号の信号レベルを判定する処理を共通化した１つのモジュールである。各アプリは、入力信号判定モジュール１０７の機能を再利用して、動作を行なう状況にあるか否かを判定する。即ち、エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４はいずれも、ルームランプ１を点灯する状況にあるか、減光消灯させる状況にあるか否かを入力信号判定モジュール１０７を利用して判定する。入力信号判定モジュール１０７は、アプリケーション層１０１に位置する。
【００４７】
そしてＣＰＵ５１はドライバプログラムに基づき、入出力ドライバ１０８として機能する。入出力ドライバ１０８としての機能は所謂ドライバの機能を実現し、ハードウェア群を直接的に制御すべくＩ／Ｏ５４へ実際に物理層の制御信号の入出力を行なう。入出力ドライバ１０８としての機能は構造的に、プラットフォーム層１０２に位置する。
【００４８】
ＣＰＵ５１の選択部１０５としての機能は以下である。選択部１０５は、ＣＰＵ５１がエントリー制御アプリ１０３又はドアロック減光制御アプリ１０４としての機能により制御対象となるハードウェア、例えばルームランプ１へ点灯要求などの動作要求を発した場合に、動作要求を受け付け、制御対象と、制御対象に行なわせる具体的な動作とを特定し、特定した制御対象及び動作の内容を示す情報を出力ドライバ部１０８へ与える。
【００４９】
ＣＰＵ５１の出力ドライバ部１０６としての機能は以下である。出力ドライバ部１０６は、選択部１０５から与えられる制御対象、及び制御対象に行なわせる具体的な動作の情報に基づき、動作を実現させるための制御信号を生成して、制御対象のハードウェアへ制御信号を出力させるべくプラットフォーム層１０２の入出力ドライバ１０８へ指示する。
【００５０】
ＣＰＵ５１の入力信号判定モジュール１０７としての機能は以下である。入力信号判定モジュール１０７は、各アプリから夫々の機能に応じて抽出された入力信号について夫々、前記機能を発揮させる状況にあるか否かを判定するための判定条件の成立／不成立を判定し、判定結果を各アプリに戻すことである。実施の形態１における入力信号判定モジュール１０７は、入力信号毎に利用されるリエントランス構造となっている。
【００５１】
このようにまず、本実施の形態１のボディＥＣＵ５では、各アプリケーションからの動作要求を選択部１０５にて一括して受け付け、制御信号の生成を行なう出力ドライバ部１
０６の機能を共有化する構成とする。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４など各アプリケーション毎、制御対象の負荷毎に、制御信号を生成して入出力ドライバ１０８へ夫々出力する構成（図１２参照）ではない。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４などのいずれのアプリケーションでも、制御がオン、オフのスイッチングにて実現する場合、動作要求に応じて制御信号を生成する処理は、動作の具体的内容が異なるのみで共通した処理であるから共有化が可能である。また、ボディＥＣＵ５では、各制御対象のハードウェアの制御を同時に行なうことはなく、各アプリケーションの機能も順に実現されるから制御信号の生成処理が同時に行なえる構成とする必要はないので共有化が可能である。当該処理を１つにして各機能から再利用可能に共有化した構成とすることにより、ＲＯＭ５２及びＲＡＭ５３におけるメモリ占有量を削減できる。
【００５２】
また、本実施の形態１のボディＥＣＵ５では、入力信号に対する判定も入力信号判定モジュール１０７に共有化される構成とする。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４など各アプリケーションに夫々、入力信号毎に入力信号判定処理を行なうモジュールが含まれる構成ではない。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４などのいずれのアプリケーションでも、更に、いずれの入力信号についても、信号レベルがＨｉであるかＬｏｗであるかの判定が行なわれる。判定の対象である入力信号がいずれであるかが異なるのみで、判定処理自体は共通するから共有化が可能である。また、ボディＥＣＵ５では、各制御対象のハードウェアの制御を同時に行なうことはなく、各アプリケーションの機能も順に実現されるから各アプリケーションの機能で入力信号に対する判定処理が同時に行なえる必要もない。入力信号判定処理を１つにして各機能から再利用可能に共有化した構成とすることにより、ＲＯＭ５２及びＲＡＭ５３におけるメモリ占有量を更に削減できる。
【００５３】
具体的には、ＣＰＵ５１にて各機能が実現される場合、図３の各ブロックにて示す各機能に対応する実行プログラムファイル（プログラムコード）が必要となる。まず、制御対象の決定及び制御信号の生成処理の機能を１つの選択部１０５及び出力ドライバ部１０６に共有化して、各種機能から利用される構成とすることにより、複数のアプリケーションプログラム５５，５５，…夫々に対応させたアプリケーションドライバプログラムを複数実行する構成よりもＲＯＭ５２及びＲＡＭ５３における記憶容量が少なくて済む。各アプリケーションプログラム５５，５５，…で、出力ドライバ部１０６に対応するプログラムコードを用意する必要がないからである。同様に、入力信号判定処理を入力信号判定モジュール１０７に共有化して各アプリケーションの機能から利用される構成とすることにより、各アプリケーションにおける入力信号判定処理のプログラムコードを省略することができるから、更にＲＯＭ５２及びＲＡＭ５３における記憶容量が少なくて済む。また、実現したい各機能について実際に、入力信号を判定する処理、及び制御信号を生成する処理を実装せずとも、入力信号判定モジュール１０７、選択部１０５及び出力ドライバ部１０６の機能を再利用すればよいので、機能の開発は動作要求を発するアプリケーションプログラム５５，５５，…の開発のみで済み、開発効率を向上させることができる。
【００５４】
次に、エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４が入力信号判定モジュール１０７を利用して判定結果を得る処理について詳細を説明する。
【００５５】
ＲＯＭ５２には、負荷毎に信号レベルに応じた判定テーブル５８，５８，…が記憶されている。判定テーブル５８，５８，…は、センサなどの信号の出力元毎の判定条件及び判定方法を含む。図４は、実施の形態１におけるボディＥＣＵ５のＲＯＭ５２に記憶されている判定テーブル５８，５８，…の内容例を示す説明図である。判定テーブル５８，５８，…では、入力信号の種類毎に、判定の方法及び判定条件が記憶されている。
【００５６】
図４には、ＩＧキーセンサ４、カーテシセンサ２，２、及びドアロックセンサ３，３からの入力信号の判定テーブル５８，５８，５８の例が示されている。ＩＧキーセンサ４からの入力信号はＩＧキーの挿抜、及びキー位置を検知したセンサ情報を示す。入力信号判定モジュール１０７では、与えられた入力信号のレベル判定か又はエッジ判定かを行なうようにしてある。入力信号に対し、エッジ判定によりＯＦＦからＯＮとなったか、レベル判定によりＯＮであるか、エッジ判定によりＯＮからＯＦＦとなったか、又はレベル判定によりＯＦＦであるかのいずれであるかが判定される。このとき、ＯＮはキー位置がＩＧ１の位置にあることに対応する。
【００５７】
カーテシセンサ２，２からの入力信号はドアの開閉を検知したセンサ情報を示す。カーテシセンサ２，２からの入力信号についても、与えられた入力信号のレベル判定か又はエッジ判定かのいずれかの方法でＯＮであるかＯＦＦであるかが判定される。ＯＮは開に対応し、ＯＦＦは閉に対応する。
【００５８】
ドアロックセンサ３，３からの入力信号は、ドアロックのロック／アンロックを検知したセンサ情報を示す。ドアロックセンサ３，３からの入力信号についても、与えられた入力信号のレベル判定か又はエッジ判定かのいずれかの方法でＬＯＣＫ（ＯＮ）であるかＵＮＬＯＣＫ（ＯＦＦ）であるかが判定される。
【００５９】
入力信号判定モジュール１０７は、図４に示したような判定テーブル５８，５８，…を参照して、各アプリから入力信号が与えられた場合にその信号レベルから、判定条件のうちのいずれが成立するか否かを判定する。例えば入力判定モジュール１０７は、ドアロックセンサ３，３からの入力信号に対し、エッジ判定を行なった結果ＵＮＬＯＣＫからＬＯＣＫとなったという判定条件、レベル判定を行なった結果ＬＯＣＫであるという判定条件、エッジ判定を行なった結果ＬＯＣＫからＵＮＬＯＣＫとなったという判定条件、又はレベル判定を行なった結果ＵＮＬＯＣＫであるという判定条件のいずれが成立するかを判定する。
【００６０】
入力信号判定モジュール１０７は更に、判定結果に応じて、次の入力信号に対する判定を行なう。このとき入力信号判定モジュール１０７は、判定結果に応じた次の入力信号がいずれなのかを各アプリから与えられるリンク情報５９を参照して判断する。リンク情報５９は、機能毎及び負荷毎に、各判定テーブル５８，５８，…に基づく判定結果の分岐に応じて、次にいずれの入力信号、及び入力信号の判定テーブル５８，５８，…にて判定がされるべきかを示す情報である。
【００６１】
図５は、実施の形態１におけるリンク情報５９の内容例を模式的に示す説明図である。図５に示すリンク情報５９は、ユーザが乗車しようとして車外からドアロックを開錠した場合にルームランプ１を点灯させるエントリー制御アプリ１０３に対応している。
【００６２】
リンク情報５９は、アプリケーションプログラム５５、又はその機能毎に抽出されるべき入力信号を含む。図５の例に示すリンク情報５９は、エントリー制御アプリ１０３に対応する入力信号がＩＧキーセンサ４からの入力信号、カーテシセンサ２，２からの入力信号、及びドアロックセンサ３，３からの入力信号であることを示している。
【００６３】
そしてリンク情報５９は、判定結果に応じた次の判定対象の入力信号の情報を含む。図５の例では、各入力信号に対する判定テーブル５８と、判定結果に応じた次の判定テーブル５８のＲＯＭ５２内におけるアドレスとのリンク関係が示されている。つまり、入力信号についての判定テーブル５８に基づく判定結果に応じて、次に判定対象とすべき入力信号の判定テーブル５８のアドレスが記述されている。図５の「ＮＵＬＬ」は、次に判定対象とすべき入力信号の判定テーブル５８が「無い」ことを示している。次の判定テーブル
５８が「無い」場合は、入力信号判定モジュール１０７は入力信号の判定処理を終了する。
【００６４】
図５の例では、具体的には、エントリー制御アプリ１０３に関し、入力信号判定モジュール１０７で最初に判定されるべき入力信号はＩＧキーセンサ４からの入力信号であることが示されている。そして、ＩＧキーセンサ４からの入力信号に対する判定テーブル５８に基づき、入力信号がＯＮであると判定された場合には、ＯＦＦからＯＮに変化した場合もＯＮのままである場合も、判定結果は「不成立」であることが示されている。この場合、これ以上判定する必要はないので、次に判定対象とすべき入力信号の判定テーブル５８のアドレスは「ＮＵＬＬ」を示している。
【００６５】
このように、機能毎に判定対象の入力信号と、判定結果に応じて次に判定対象とすべき入力信号の順序とを示すリンク情報５９をＲＯＭ５２に記憶しておく構成により、１つの入力信号判定モジュール１０７が処理を行なうとしてもリンク情報５９の内容に応じて、種々の入力信号に対する判定処理を行なうことができる。
【００６６】
図５に示したように、実施の形態１におけるリンク情報５９は、各入力信号に対する判定テーブル５８，５８，…のアドレス同士のリンク関係にて示した。しかしながら、リンク情報５９の内容はこれに限らず、判定結果に応じて、次にいずれの入力信号についての判定をするべきかを示す情報であればよい。
【００６７】
なお、リンク情報５９には、上述のようなエントリー制御アプリ１０３のルームランプ１についての情報のみならず、他のアプリケーションプログラム５５，５５，…、負荷に対応する情報が含まれることは勿論である。
【００６８】
このような判定テーブル５８，５８，…及びリンク情報５９を参照して、入力信号判定モジュール１０７が各入力信号に対する判定結果に基づいて、機能を実現すべき状況に有るか、即ち動作すべき条件が成立するか否かを判断する処理についてフローチャートを参照して説明する。
【００６９】
図６は、実施の形態１における入力信号判定モジュール１０７により実行される処理手順の一例を示すフローチャートである。以下の処理は、エントリー制御アプリ１０３が、自身のエントリー制御の動作を行なう状況にあるか否かを判断するために行なわれる。エントリー制御アプリ１０３は、入力信号判定モジュール１０７に、自身の動作状況判定に関するリンク情報５９を指示する情報を与える。
【００７０】
入力信号判定モジュール１０７は、与えられた情報からリンク情報５９を特定してＲＯＭ５２から読み出し（ステップＳ１）、リンク情報５９に基づき、判定に必要な入力信号を抽出して読み込む（ステップＳ２）。
【００７１】
次に入力信号判定モジュール１０７は、抽出した入力信号に対する判定テーブル５８，５８，…を読み出す（ステップＳ３）。入力信号判定モジュール１０７は、リンク情報５９に基づき、抽出した入力信号の内、最初に判定対象とすべき入力信号について、入力信号の信号レベルの状態が判定テーブル５８のいずれの判定条件に一致するかを判断する（ステップＳ４）。
【００７２】
入力信号判定モジュール１０７は、ステップＳ４にて、入力信号が「ＯＦＦ」から「ＯＮ」へ変化したという判定条件に一致すると判断した場合（Ｓ４：ＯＦＦ→ＯＮ）、リンク情報５９から当該条件に一致する場合の次の判定テーブル５８のアドレスを取得する（ステップＳ５）。そして入力信号判定モジュール１０７は、取得したアドレスは「ＮＵＬ
Ｌ」か否かを判断する（ステップＳ６）。
【００７３】
入力信号判定モジュール１０７は、ステップＳ６にて取得したアドレスが「ＮＵＬＬ」でないと判断した場合（Ｓ６：ＮＯ）、次の入力信号及びその判定テーブル５７に基づく判定を行なうべく、処理をステップＳ２へ戻す。
【００７４】
入力信号判定モジュール１０７は、ステップＳ６にて取得したアドレスが「ＮＵＬＬ」であると判断した場合（Ｓ６：ＹＥＳ）、次に判定すべき入力信号はないので、ステップＳ４における判断結果に対応する条件成立／不成立の判定結果を、リンク情報５９から読み出して戻り値として、入力信号判定モジュール１０７の呼び出し元のアプリへ返し（ステップＳ７）、処理を終了する。
【００７５】
入力信号判定モジュール１０７は、ステップＳ４における他の判定条件、即ち入力信号が「ＯＮ」から「ＯＮ」のままという判定条件に一致すると判断した場合（Ｓ４：ＯＮ→ＯＮ）、「ＯＮ」から「ＯＦＦ」へ変化したという判定条件に一致すると判断した場合（Ｓ４：ＯＮ→ＯＦＦ）、又は、「ＯＦＦ」から「ＯＦＦ」のままという判定条件に一致すると判断した場合（Ｓ４：ＯＦＦ→ＯＦＦ）、いずれの場合も次の判定テーブル５８のアドレスを取得し（Ｓ８、Ｓ１１、Ｓ１４）、アドレスが「ＮＵＬＬ」か否かを判断し（Ｓ９、Ｓ１２、Ｓ１５）、アドレスが「ＮＵＬＬ」でない場合は（Ｓ９、Ｓ１２、Ｓ１５：ＮＯ）、処理をステップＳ２へ戻し、アドレスが「ＮＵＬＬ」である場合は（Ｓ９、Ｓ１２、Ｓ１５：ＹＥＳ）、ステップＳ４における判断結果に対応する判定結果をアプリへ戻り値として返し（Ｓ１０、Ｓ１３、Ｓ１６）、処理を終了する。
【００７６】
図６のフローチャートに示したように、入力信号判定モジュール１０７では、各入力信号の状態に対する判定を、与えられる入力信号と当該入力信号に対す判定テーブル５８とを用いて、同じプログラムコード内で繰り返し処理できる構成により（Ｓ４〜Ｓ１５）、各入力信号に対する処理を夫々プログラムコードとして実装せずともよい点で効果的である。
【００７７】
図７は、実施の形態１における入力信号判定モジュール１０７による判定処理の過程を概念的に示す説明図である。図７には、エントリー制御アプリ１０３から、判定処理を要求された場合に図６に示したように入力信号判定モジュール１０７が処理を行なったときに、図５に示したリンク情報５９に基づいて読み出される判定テーブル５８が示されている。
【００７８】
図７に示すように、入力信号判定モジュール１０７は、エントリー制御アプリ１０３から、判定処理を要求された場合に、まずエントリー制御に関するリンク情報５９を読み出す（Ｓ１）。入力信号判定モジュール１０７は最初に、ＩＧキーセンサ４からの入力信号を読み込んで（Ｓ２）、当該入力信号に対する判定を行なう。入力信号判定モジュール１０７は、ＩＧキーセンサ４からの入力信号に対応する判定テーブル５８を読み出し（Ｓ３）、判定テーブル５８に含まれているいずれの条件に一致するかを判断する（Ｓ４）。
【００７９】
入力信号判定モジュール１０７は、ＩＧキーセンサ４からの入力信号が「ＯＮ」状態である場合、「ＯＮ」から「ＯＮ」のままでも、「ＯＦＦ」から変化したときでも、次の判定テーブル５８のアドレスは「ＮＵＬＬ」であるから、判定結果としてＩＧキーセンサ４からの入力信号の「ＯＮ」状態であることに対する判定結果の「条件不成立」を戻り値として返す（Ｓ１０）。
【００８０】
エントリー制御のルームランプ１の点灯制御では、車外からユーザが車両に乗ろうとしてドアロックを開錠した場合に行なう。キー位置がＩＧ１の位置にある場合では、既にユ
ーザがドアロックを開錠してドアを開けて、エンジンをかけた状況であるから、当該エントリー制御を行なうべきでないからである。
【００８１】
エントリー制御アプリ１０３は、入力信号判定モジュール１０７から「条件不成立」の判定結果を返された場合、自身の処理により制御対象に動作を要求する状況を示す条件が「条件不成立」であると認識し、動作要求は行なわない。
【００８２】
入力信号判定モジュール１０７は、ＩＧキーセンサ４からの入力信号が「ＯＦＦ」状態である場合、「ＯＮ」から「ＯＦＦ」変化したときでも、「ＯＦＦ」から「ＯＦＦ」のままでも、次のテーブル５８のアドレスは、カーテシセンサ２，２からの入力信号に対する判定テーブル５８のアドレスである。したがって入力信号判定モジュール１０７は、カーテシセンサ２，２からの入力信号を読み込み（Ｓ２）、判定テーブル５８におけるいずれの条件に一致するかを判断する（Ｓ３、Ｓ４）。この場合も、カーテシセンサ２，２からの入力信号がいずれか一方のみでも「ＯＮ」状態である場合は、次の判定テーブル５８のアドレスは「ＮＵＬＬ」であるから判定処理は終了され、「条件不成立」の判定結果が返される（Ｓ１０）。
【００８３】
カーテシセンサ２，２からの入力信号が「ＯＦＦ」状態である場合には、次の判定テーブル５８としてドアロックセンサ３，３からの入力信号に対する判定テーブル５８のアドレスがリンク情報５９から読み出せる。したがって入力信号判定モジュール１０７は次に、ドアロックセンサ３，３からの入力信号を読み込み（Ｓ２）、判定処理を行なう。
【００８４】
入力信号判定モジュール１０７は、ドアロックセンサ３，３からの入力信号がいずれの判定条件に一致したとしても、次の判定テーブル５８のアドレスとして「ＮＵＬＬ」を取得する（Ｓ５，Ｓ８，Ｓ１１，Ｓ１４）。したがって、アドレスは「ＮＵＬＬ」であるから（Ｓ６，９，１２，１５：ＹＥＳ）、入力信号判定モジュール１０７は、ドアロック３，３からの入力信号が一致する判定条件に対応する判定結果を戻り値として返し（Ｓ７，Ｓ１０，Ｓ１３，Ｓ１６）、処理終了する。このとき、図５のリンク情報５９の内容例では、ドアロックセンサ３，３からの入力信号の状態が「ＬＯＣＫ」から「ＵＮＬＯＣＫ」へ変化したという条件に一致する場合のみ、判定結果として「条件成立」が返される。
【００８５】
つまり、入力信号モジュール１０７は、図５に示すようなリンク情報５９に基づき、エントリー制御に対する判定処理を行なう場合、ＩＧキーセンサ４からの入力信号が「ＯＦＦ」であって、カーテシセンサ２，２からの入力信号も「ＯＦＦ」であって、更にドアロックセンサ３，３からの入力信号が「ＬＯＣＫ」から「ＵＮＬＯＣＫ」へ変化したときのみ「条件成立」となり、エントリー制御アプリ１０３によりエントリー制御が実行される。
【００８６】
このように、リンク情報５９に入力信号を読み込む順序、及び当該入力信号に対する判定結果に応じた次の入力信号の関係がリンク形式で示されていることにより、入力信号判定モジュール１０７は、エントリー制御アプリ１０３から、ルームランプ１のエントリー制御に対する入力信号判定の要求がされるのみで、判定処理を行なうことができる。
【００８７】
なお、リンク情報５９を用いて、最初に１つでも条件不成立となるような判定条件に入力信号の状態が一致した場合に処理が終了できる構成としたことにより、他の入力信号に対する判定処理をその後行なわずともよく、処理が迅速化される点で効果的である。
【００８８】
図８は、ＣＰＵ５１が入力信号判定モジュール１０７として機能する際の処理の具体例を概念的に示す説明図である。図８には、ＣＰＵ５１が入力信号判定モジュール１０７として機能している際にＲＡＭ５３を占有する各種情報をブロックにて示している。
【００８９】
図８中の上段に示すように、ＲＡＭ５３にはボディＥＣＵ５の制御対象である負荷、例えばヘッドライト、ルームランプ１についての動作状態と、各負荷に関して起動中の機能と、当該機能に対応する入力信号に対する判定結果とが記憶されている。同一の制御対象であっても対応する機能に応じて夫々動作状態、判定結果が記憶されている。例えば、エントリー制御の機能に対しては、当該機能を発揮するため動作要求を出力する条件が成立しているが、ドアロック減光制御の機能に対しては条件が成立していないなどの状態は勿論ありえるからである。動作状態の内容は、停止中、オン（点灯）、オフ（消灯）などのいずれかである。なお、斜線にて示す動作状態及び判定結果は、選択部１０５、出力ドライバ部１０６及び入力信号判定モジュール１０７などの処理により随時書き換えられる。
【００９０】
図８中の下段には、判定テーブル及びリンク情報の内容が示されている。図８に示すＲＡＭ５３に記憶されている判定テーブル及びリンク情報は、ＣＰＵ５１によってＲＯＭ５２から一時的に読み出された判定テーブル５８，５８，…及びリンク情報５９の一部である。
【００９１】
図８中の中段には、入力信号判定モジュール１０７のプログラムコードがロードされていることが示されている。このとき、１つのプログラムコードとしてロードされる入力信号判定モジュール１０７により、種々の機能にて複数の負荷夫々に対する動作を要求する状況にあるか否かの判定結果が行なわれることに注目すべきである。入力信号判定モジュール１０７は、エントリー制御アプリ１０３から、入力信号に対する判定処理を行なうべく呼び出された場合、エントリー制御に係るリンク情報５９をＲＡＭ５３に読み出し、各入力信号に対する判定テーブルを読み出し、判定処理を行って判定結果をエントリー制御に対応する記憶領域に書き込む。他の各アプリに呼び出された場合であっても、１つの入力信号判定モジュール１０７にて各アプリに対応する記憶領域にて記憶されている固有の情報を書き換えるなどして、共通のコードで固有の動作を行なう。
【００９２】
このように、エントリー制御アプリ１０３に対応する入力信号判定処理も、ドアロック減光制御アプリ１０４に対応する入力信号判定処理も、共通して入力信号判定モジュール１０７が処理を行なう。これにより、各アプリで夫々入力信号判定のプログラムコードを実装する必要が無く、実行中に重複する内容が多いプログラムコードが多数ＲＡＭ５２にロードされてメモリを占有することが無い。
【００９３】
１つのプログラムコードで、各アプリからの動作要求毎に順に実行することにより、オブジェクト指向型の概念において１つの共通する入力信号判定処理を持つクラスを各機能毎、入力信号毎に夫々実体化するようにクラスが持つ共通処理を固有パラメータに対して実行する構成を、メモリ容量に制限がある組み込み系のコンピュータプログラムでも実現することができる。
【００９４】
処理の実行中にＲＡＭ５３にてプログラムコードが占有する容量が少なくて済み、また、動的に容量が確保されることもなく煩雑なメモリ管理も要しないので、簡易な構成のマイコンに基づくＥＣＵにおける処理に適している。
【００９５】
ＲＡＭ５３の記憶容量を節約できるのでボディＥＣＵ５の内部構成を簡素化させることができる。更に、ボディＥＣＵ５にて実現したい機能毎に、入力信号に対する判定処理を実行させるプログラムを実装せずとも、共有化された入力信号判定モジュール１０７の機能を共有化する。したがって、入力信号判定モジュール１０７とのインタフェースを考慮すれば、アプリケーションプログラム５５，５５，…では、入力信号判定処理以外の開発のみで済み、開発効率を向上させることができる。
【００９６】
実施の形態１では、判定テーブル５８，５８，…は入力信号毎に別個のテーブルとして構成した。しかしながら、入力信号毎に判定条件を示す１個のテーブルとして構成されてもよい。この場合、リンク情報５９に示されている次の判定テーブル５８のアドレスは、次の入力信号の判定条件の項目の箇所を示すアドレスとなる。当該構成でも、リンク情報５９の利用方法は同じであり、各機能の固有の情報を１つの入力信号判定モジュール１０７で用いて個々の入力信号に対する判定処理を実行することができる。
【００９７】
（実施の形態２）
実施の形態１では、入力信号判定モジュール１０７は、図５に示したリンク情報５９に基づいて、判定対象の入力信号を順に読み出し、夫々に対する判定テーブル５８，５８，…における判定条件により判定を行なって最終的な判定結果を得る構成とした。これに対し、実施の形態２では、判定テーブル５８，５８，…は機能毎に、判定対象となる入力信号と、各機能のために動作を要求する条件となる該入力信号に対するマスク情報及び信号状態との対応を記憶したものである。判定対象の入力信号を読み込む順序をも参照できるリンク情報５９を用いない。
【００９８】
以下に示す実施の形態２の車載制御システムは、リンク情報５９がＲＯＭ５２に記憶されていないこと、判定テーブル５８，５８，…の内容、及び入力信号判定モジュール１０７の判定処理の詳細が異なる。リンク情報５９が記憶されていない以外は、ハードウェア的な構成は実施の形態１における車載制御システムと同様であるので、図示及び詳細な説明を省略する。共通する構成部については同一の符号を用いて説明する。
【００９９】
図９は、実施の形態２におけるＲＯＭ５２に記憶されている判定テーブル５８，５８，…の基本構成を示す説明図である。判定テーブル５８，５８，…では、機能毎に、当該機能に対応する負荷に、前記機能に対応する動作を要求する状況であるか否かを判断するための入力信号と、夫々の入力信号の状態を判断するためのマスク情報及び入力信号が充たすべき信号状態が判定条件として記憶されている。図９に示す例では、入力信号判定モジュール１０７は、ある機能に対応するアプリから呼び出された場合、入力信号Ａ、入力信号Ｂ及び入力信号Ｃ夫々について、各々マスク情報に基づき信号をマスクして信号を読み取ったときに信号状態という判定条件が成立しているか否かを判定し、判定結果を返す。
【０１００】
なお判定テーブル５８，５８，…は、機能毎のみならず、制御対象の負荷毎に、当該負荷に関する機能毎の判定テーブルを含む構成としてもよい。図１０は、実施の形態２における判定テーブル５８，５８，…の内容例を示す説明図である。図１０に示す例では、ルームランプ１を制御対象とする各機能について、マスク情報と信号状態の判定条件が含まれている。
【０１０１】
ドアが開いている間はルームランプ１を点灯させる機能にて、ルームランプ１へ点灯を要求するのは、カーテシセンサ２，２からの入力信号をレベル判定するようにマスクして読み取ったときに信号状態が「ＯＮ」であるという条件が成立したときであることが示されている。マスク情報が「レベル」であるから、信号状態が「ＯＦＦ」から「ＯＮ」へ変化した場合であっても「ＯＮ」から「ＯＮ」のままであってもよい。当該判定テーブル５８に基づき、入力信号判定モジュール１０７は、ドアが開いている間はルームランプ１を点灯させる機能のアプリから呼び出された場合、カーテシセンサ２，２からの入力信号に対する判定処理のみ行なえばよい。なお当該判定処理に、ＩＧキー４からの入力信号及びドアロックセンサ３，３からの入力信号は無効であることが「−」で示されている。
【０１０２】
図１０に示す他の例は、ドアが閉じた場合にルームランプ１を消灯させる機能にて、ルームランプ１への点灯要求を停止するのは、カーテシセンサ２，２からの入力信号をエッジ判定するようにマスクして読み取ったときに信号状態が「ＯＮ」から「ＯＦＦ」へ変化
したという条件が成立したときであることが示されている。マスク情報が「エッジ」であるから、信号状態が変化した場合のみ条件が成立する。この場合も、カーテシセンサ２，２からの入力信号のみ判定処理を行なえばよい。
【０１０３】
また他の例は、エントリー制御アプリ１０３の機能、即ち、車外からユーザが車両に乗るためにドアロックが開錠されたときにルームランプ１を点灯させる機能にて、ルームランプ１へ点灯を要求するのは、以下の入力信号及び各入力信号に対する判定条件がいずれも成立したときである。つまり、ＩＧキーセンサ４からの入力信号をレベル判定するようにマスクして読み取ったときに信号状態が「ＯＦＦ」状態であるという条件が成立し、カーテシセンサ２，２からの入力信号をレベル判定するようにマスクして読み取ったときに「ＯＦＦ」状態であるという条件が成立し、且つ、ドアロックセンサ３，３からの入力信号をエッジ判定するようにマスクして読み取ったときに信号状態が「ＬＯＣＫ」から「ＵＮＬＯＣＫ」へ変化したという条件が成立したときのみである。
【０１０４】
このような判定テーブル５８を用いた入力信号判定モジュール１０７による判定処理について説明する。図１１は、実施の形態２における入力信号判定モジュール１０７により実行される処理手順の一例を示すフローチャートである。以下の処理は、エントリー制御アプリ１０３が、自身のエントリー制御の動作を行なう状況にあるか否かを判断するために行なわれる。エントリー制御アプリ１０３は、入力信号判定モジュール１０７に、制御対象に対応する判定テーブル５８を指示する情報を与える。
【０１０５】
入力信号判定モジュール１０７は、与えられた判定テーブル５８を読み出し（ステップＳ２１）、自身の呼び出し元の機能を特定して機能に対応する判定テーブル５８からマスク情報及び判定条件を読み出し（ステップＳ２２）、読み出したマスク情報に基づき各入力信号にマスク処理を行なう（ステップＳ２３）。具体的には、複数の入力信号に対し判定対象以外の信号をマスクし、レベル判定対象の入力信号にはレベルのみとなるようにマスクする。
【０１０６】
詳細には、入力信号判定モジュール１０７は、エントリー制御についての判定対象であるＩＧキーセンサ４からの入力信号、カーテシセンサ２，２からの入力信号、及びドアロックセンサ３，３からの入力信号を含む複数の入力信号の情報を取得する。各入力信号はエッジ型で各々１バイトで表わされ、最下位２ビットで変化が表わされる。例えば入力信号がＯＮからＯＦＦとなった場合には入力信号は０ｘ０２で、ＯＦＦからＯＮとなった場合には０ｘ０１で表わされる。ＯＮのままの場合は０ｘ０３で表わされる。マスク情報も夫々１バイトで表わされ、レベル判定のみの場合は０ｘ０１、エッジ判定の場合は０ｘ０３である。条件が成立するための信号状態も１バイトで表わされ、ＯＮからＯＦＦは０ｘ０２、ＯＮであることは０ｘ０１で表わされる。入力信号判定モジュール１０７は、これらの各入力信号に対してマスク情報とのＡＮＤを取ることでマスク処理を行なう。例えば、入力信号が０ｘ０２である場合にレベル判定のマスク情報に基づいてマスクした結果は０ｘ００となるし、エッジ判定のマスク情報に基づいてマスクした結果は０ｘ０２である。なお、入力信号判定モジュール１０７は、これらの１バイトずつの入力信号の情報、マスク情報及び信号状態を夫々、例えば４バイトの情報としてまとめ、一括した演算を可能とする。例えば入力信号の情報は０ｘ０３０００２００、マスク情報は０ｘ０１０１０３００である場合、マスク処理により０ｘ０１０００２００が得られ、まとめられた判定対象の信号状態０ｘ０００００２００と一致するかが後述のステップＳ２４のように判定される。
【０１０７】
次に入力信号判定モジュール１０７は、マスク処理を行なって得られた信号がステップＳ２２にて読み出した判定条件の信号状態に一致するか否かにより複数の入力信号に対する判定条件の成否を一括して判定する（ステップＳ２４）。入力信号判定モジュール１０
７は、ステップＳ２４にて条件が成立すると判定した場合（Ｓ２４：ＹＥＳ）、条件成立という判定結果を戻り値として返し（ステップＳ２５）、処理を終了する。
【０１０８】
入力信号判定モジュール１０７は、ステップＳ２４にて条件が不成立であると判定した場合（Ｓ２４：ＮＯ）、全入力信号について条件の成否を判定したかを判断する（ステップＳ２６）。一括して判定される入力信号は上述の例では４つであるから、他にある場合には再度判定が必要である。入力信号判定モジュール１０７は、全入力信号について条件の成否を判定したと判断した場合（Ｓ２６：ＹＥＳ）、条件不成立という判定結果を戻り値として返し（ステップＳ２７）、処理を終了する。
【０１０９】
入力信号判定モジュール１０７は、全入力信号について条件の成否を判定していないと判断した場合（Ｓ２６：ＮＯ）、処理をステップＳ２２へ戻し、次の判定対象のマスク情報及び判定条件の信号状態を読み出して処理を継続する。
【０１１０】
図１１に示した処理手順を実行する入力信号判定モジュール１０７の処理によっても、エントリー制御アプリ１０３から呼び出された場合、図７に示したような過程を経て、ルームランプ１へ点灯を要求する状況であるか否かを判断できる。実施の形態２における構成では、入力信号判定モジュール１０７が判定対象の入力信号に対して順に判定がされることなしに、一括して信号状態に対する判定が行なわれる点が、実施の形態１と異なる。
【０１１１】
実施の形態２では、複数の入力信号が判定対象として抽出された場合に一括して判定されるので処理が迅速化される。
【０１１２】
実施の形態２でも、入力信号判定モジュール１０７が、複数の各アプリに対して共有化されることは実施の形態１と同様である。つまり、エントリー制御アプリ１０３に対応する入力信号判定処理も、ドアロック減光制御アプリ１０４に対応する入力信号判定処理も、共通して入力信号判定モジュール１０７が処理を行なう。判定処理の詳細が異なるのみである。これにより、各アプリで夫々入力信号判定のプログラムコードを実装する必要が無く、実行中に重複する内容が多いプログラムコードが多数ＲＡＭ５２にロードされてメモリを占有することが無い。開発効率を向上させることができる点も、実施の形態１と同様である。
【０１１３】
なお、開示された実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上述の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。
【符号の説明】
【０１１４】
１ ルームランプ（制御対象）
２ カーテシセンサ
３ ドアロックセンサ
４ ＩＧキーセンサ
５ ボディＥＣＵ（制御装置）
５０ マイコン（マイクロコンピュータ）
７２ ＲＯＭ（記憶手段）
５５ アプリケーションプログラム
５６ アプリケーションドライバプログラム
５７ 入力信号判定モジュールプログラム（コンピュータプログラム）
５８ 動作パターンテーブル
５９ リンク情報（分岐条件情報）
１０３ エントリー制御アプリ（アプリケーション）
１０４ ドアロック減光制御アプリ（アプリケーション）
１０７ 入力信号判定モジュール（判定手段）
【技術分野】
【０００１】
本発明は、コンピュータプログラムに基づき各種負荷の動作制御を行なう制御装置に関する。特に、コンピュータプログラムの構成を、メモリを節約させることを可能とする構成として装置の簡素化を実現させ、且つ各負荷用の多様な機能の増減に柔軟に対応させることができ、開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムに関する。
【背景技術】
【０００２】
マイクロコンピュータ（以下、マイコンという）を利用し、マイコン内蔵ＲＯＭに書き込まれたコンピュータプログラムに基づいて制御を行なう制御装置の場合、コンピュータプログラムは所謂組み込み系の言語で記述される。組み込み系の言語で記述するコンピュータプログラムは、装置の簡素化のためにメモリなどリソースを節約し、必要最低限の処理を制御対象毎に、且つ機能毎に実装する構成が基本的である。
【０００３】
図１２は、従来のマイコンにおけるコンピュータプログラムの構成の概略を示す概略図である。図１２に示すコンピュータプログラムの構成は特に、制御対象（負荷Ｘ）の動作を制御する制御装置にてマイコンにより実行されるコンピュータプログラムの例を示している。図１２は、コンピュータプログラムにより実現される機能をブロックにて示している。図１２の例のコンピュータプログラムによって負荷Ｘを制御対象とする機能が実現される場合、図１２に示すように、当該コンピュータプログラムは例えば、機能毎に、センサ又は負荷から入力される信号Ａ，Ｂ，Ｃ夫々に対する判定処理、入力信号の判定結果に基づき機能を実現するため負荷Ｘに要求する動作を判定する判定処理、負荷への動作要求の信号出力の調停、動作毎の負荷への信号出力などの機能が、アプリケーションプログラムにより実現したい機能（ア）及び機能（イ）夫々に対応して実現される。
【０００４】
コンピュータプログラムの実装上も、夫々の機能に応じたプログラムコード（実行ファイル）が作成され、いずれのプログラムコードもメモリ上に予め記憶されており、ＣＰＵにより読み出される。したがって、図１２に示したブロック夫々に応じてメモリが占有される。したがって、例えば入力信号に対する判定処理は、機能（ア）及び（イ）毎に、更に信号Ａ，Ｂ，Ｃ毎にプログラムコードが夫々存在する。
【０００５】
図１２に示した例では、機能が（ア）と（イ）とで異なるのみで同一の入力信号Ａに対しても夫々、入力信号判定部に対応するプログラムコードが存在する構成である。機能（ア）と（イ）とが同時並行的に実行される可能性がない場合、夫々存在する構成ではメモリの使用が非効率的である。
【０００６】
また、入力信号に対する判定処理は、概ね信号レベルがＨｉかＬｏｗかに基づき、スイッチがＯＮかＯＦＦか、ロックかアンロックかなどを判定するものである。即ち、入力信号の内容が異なるのみで、判定処理の具体的な処理内容はいずれも信号レベルがＨｉかＬｏｗかであって共通している。この判定処理のためのプログラムコードが種々の入力信号夫々に存在する構成では、メモリの使用が非効率的である。
【０００７】
しかもこの場合、各入力信号Ａ，Ｂ，Ｃに対する判定は同時的に行なわれるのではなしに、シーケンシャルに各入力信号Ａ，Ｂ，Ｃに対する判定がされ、判定結果に応じた動作もシーケンシャルに行なわれて、入力信号の判定処理のためのプログラムコードに占有されるメモリが同時的にアクセスされることもないにも拘わらず、マイコンに実行させるための各動作に対応するプログラムコードがいずれも、メモリを予め占有するので、メモリ
の使用効率が非効率的である。
【０００８】
これに対し、制御装置に求められる機能の多様化、複雑化が進むにつれ、オブジェクト指向型の言語によって記述されるプログラムをマイコンが読み出して実行する制御装置も提案されている（特許文献１など参照）。このように、処理が実行される都度にメモリが確保され、処理が終了した場合にはメモリが開放されて他に使用できるなど、メモリを効率的に利用することができる。しかしながらこの場合、プログラム実行中にメモリを動的に確保するなどの処理をマイコンに実現させる基本機能（ライブラリ）などが必要である。このようにオブジェクト指向に基づく設計では、基本機能を実現するためのライブラリプログラムコードがメモリを使用する上、動的なメモリ確保、動的なライブラリのリンクなどの処理が想定され、オブジェクト指向型のコンピュータプログラムの構成により各種機能が実現できるのはメモリの記憶容量に余裕があるからである。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００８−７７２２０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、負荷制御を行なうマイコンを用いた制御装置では、メモリの容量に制限があるからこそ組み込み系の言語で記述されるコンピュータプログラムを利用するのであって、メモリの記憶容量に余裕を持たせてもよい特定の制御装置以外では、オブジェクト指向型のソフトウェア構成は適していない。一方で、従来のコンピュータプログラムの構成のように、共有できる処理であっても種々の入力信号毎、制御対象である負荷毎、及び機能毎にプログラムコードがメモリを占有する構成では上述のようにメモリの使用が非効率的である。共通する同様な処理は共有化して再利用が可能な構成とし、共有化された処理はそれに対応するプログラムコードのみでメモリを占有することが望ましい。
【００１１】
本発明は斯かる事情に鑑みてなされたものであり、組み込み系のコンピュータプログラムにオブジェクト指向型の概念を適用し、メモリを節約して装置の簡素化を実現させ、開発効率を向上させることができる制御装置、制御方法及びコンピュータプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
第１発明に係る制御装置は、複数の制御対象の状態情報又は複数のセンサからの検知情報を示す信号の入力を受け付けるマイクロコンピュータを備え、該マイクロコンピュータが複数のアプリケーションプログラムに基づく処理を行ない、入力信号から判断される状況に応じて、前記複数の制御対象の内のいずれかへ動作要求を出力して前記制御対象の動作を制御するようにしてある制御装置において、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定する判定手段と、複数の入力信号から、アプリケーションプログラムの機能毎に１又は複数の入力信号を抽出する抽出手段と、機能毎に抽出した１又は複数の入力信号、及び該入力信号に対応する判定条件を、前記判定手段に与え、前記判定手段からの各判定結果に応じて、動作要求を出力する状況であるか否かを判断する判断手段とを備えることを特徴とする。
【００１３】
第２発明に係る制御装置は、機能毎に、前記判定手段へ与える入力信号及び判定条件、並びに、前記判定手段へ入力信号及び判定条件を与えた場合の判定結果に応じて次に与えるべき入力信号及び判定条件を示す分岐条件情報を記憶する手段を備え、前記判断手段は、前記分岐条件情報に基づき、各判定結果に応じて次の入力信号及び判定条件を選択して与えるようにしてあることを特徴とする。
【００１４】
第３発明に係る制御装置は、入力信号毎に判定条件を示すテーブルを備え、前記分岐条件情報は、次に与えるべき入力信号の判定条件の参照箇所を示すアドレスを含むことを特徴とする。
【００１５】
第４発明に係る制御装置は、前記判断手段は、前記分岐条件情報に基づいて入力信号及び判定条件を前記判定手段へ順次与えた場合の最後の判定結果が成立である場合、動作要求を出力する状況であると判断するようにしてあることを特徴とする。
【００１６】
第５発明に係る制御装置は、各機能に対応する入力信号、及び該入力信号への判定条件を示すテーブルを機能毎に備え、前記抽出手段は、前記テーブルに基づいて入力信号を抽出するようにしてあることを特徴とする。
【００１７】
第６発明に係る制御方法は、複数の制御対象の状態情報又は複数のセンサからの検知情報を示す信号の入力を受け付けるマイクロコンピュータを用い、該マイクロコンピュータに複数のアプリケーションプログラムに基づく処理を行なわせると共に、前記マイクロコンピュータは、前記複数のアプリケーションプログラムと異なるコンピュータプログラムに基づき、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定する判定手段として機能し、入力信号から判断される状況に応じて、前記複数の制御対象の内のいずれかへ動作要求を出力させて前記制御対象の動作を制御する方法であって、前記マイクロコンピュータは、前記アプリケーションプログラムに基づく処理により、機能毎に、該機能に関する入力信号を１又は複数抽出し、抽出した１又は複数の入力信号、及び該入力信号に対応する判定条件を前記判定手段へ順次与え、前記判定手段からの各判定結果に応じて、動作要求を出力する状況であるか否かを判断し、出力する状況であると判断した場合に動作要求を出力させることを特徴とする。
【００１８】
第７発明に係るコンピュータプログラムは、複数の制御対象又は複数のセンサが接続され、前記制御対象の状態情報又は前記センサからの検知情報を示す信号の入力を受け付けるコンピュータに、複数のアプリケーションプログラムに基づき、入力信号から判断される状況に応じて複数の制御対象の内のいずれかへ動作要求を出力させて前記制御対象を動作させる処理を実行させる際に、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定させる判定手段として機能させるコンピュータプログラムであって、コンピュータを、アプリケーションプログラムの機能毎に抽出された１又は複数の入力情報、及び該入力情報に対応する判定条件、前記判定手段へ与える手段、及び、１又は複数の入力情報を与えて前記判定手段により得られた各判定結果により、動作要求を出力する状況であるか否かを判断する手段として機能させることを特徴とする。
【００１９】
第１発明、第６発明及び第７発明では、マイクロコンピュータが、制御対象の制御状態の情報又は各センサが検知した情報を示す入力信号から、複数の機能を夫々実現するアプリケーションプログラムの処理において当該機能に対応する動作要求を出力する状況にあるか否かを判断するに際し、入力信号に対する判定処理が判定手段によって実行される。複数の機能夫々に応じて制御対象を動作させるか否かを判断させるための信号が夫々が抽出され、判定手段で抽出された各入力信号に対して判定条件が成立するか否かが判定される。判定手段による各判定結果に基づいて、動作要求を出力する状況にあるか否かが判断される。
【００２０】
このとき、複数のアプリケーションプログラムに基づく処理が実行されるのに対し、入力信号に対する判定条件の成否を判定する判定手段は、複数のアプリケーションプログラムに共有される構成である。これにより、従来では処理の内容が重複するにも拘わらず、各アプリケーションプログラムに対応する入力信号に対して別個に実行されていた判定処
理が共有化される。
【００２１】
第２発明では、機能毎に、該機能に対応する制御を実行する状況にあるかを判断するための判定対象の入力信号及び各入力信号に対する判定条件と、判定条件の判定結果に応じて次に与えるべき入力信号を示す情報とからなる分岐条件情報が記憶され、当該分岐条件情報に基づき判定がなされる。判定対象が分岐条件に基づいて切り替わることで１つの判定手段が同一の判定処理を実行する構成でも、各々固有の信号に対する判定処理を実行する構成と同じ結果が得られる。
【００２２】
第３発明では、入力信号毎の判定条件はテーブル化されており、分岐条件情報は、各判定条件の結果に応じた次の入力信号に対する判定条件の参照箇所を示している。判定手段は、示される参照箇所の判定条件を参照して入力信号が一致するか否かの判定処理を、判定対象の信号が変わったとしても変わらずに行なう構成で、異なる入力信号に対する判定が、判定結果に応じた分岐に従って行なわれる。これにより、共通の１つの判定手段により、種々の入力信号に対する判定を実行できる。
【００２３】
第４発明では、分岐条件情報に基づく判定手段の処理により最終的に得られた判定結果が示す成否が、動作要求を出力する状況か否かである。判定手段が、複数の入力信号に対して判定結果を返す処理を変わらず実行することにより、最終的な判断結果が得られる。
【００２４】
第５発明では、判定対象となるべき入力信号と、各入力信号に対する判定条件とが機能毎にテーブルにて記憶されてもよい。機能が指定された場合に判定すべき入力信号を抽出され、判定対象の入力信号の判定の順序に関わらず、抽出された入力信号の内のいずれかについて判定条件が不成立の場合に判定結果は不成立となる。
【発明の効果】
【００２５】
本発明による場合、組み込み系のコンピュータプログラムに基づき制御を行なう制御装置でも、各機能を実現させる動作について、動作を行なう状況であるか否かを判断するための入力信号に対する判定処理を各機能に共有化し、１つの判定手段の機能を種々の入力信号に対する判定処理に利用する。
【００２６】
これにより、種々の入力信号夫々に対して入力信号の判定処理を行なわせるプログラムコードが種々の入力信号毎に、且つ機能毎に記憶されて実行される構成よりも、共通して利用できるプログラムコードを１つメモリに記憶して実行可能に構成しておくことにより各機能を実現可能であるからメモリの占有量は少なくて済む。メモリを節約できるので装置を簡素化させることができる。更に、入力信号自体と、判定結果の関係を変えて共有化された判定手段の機能を再利用すればよいので、新たな入力信号に対する判定処理が加わったとしても、これに対するプログラムは実装せずとも、入力信号と該入力信号に対応する判定条件とを与える構成を守ればアプリケーションプログラムの開発のみで済み、開発効率を向上させることができる点、優れた効果を奏する。
【図面の簡単な説明】
【００２７】
【図１】実施の形態１における車載制御システムの構成を示す構成図である。
【図２】実施の形態１における車載制御システムに含まれるボディＥＣＵの内部構成を示すブロック図である。
【図３】実施の形態１におけるボディＥＣＵのマイコンのＣＰＵにて実現される機能を概念的に示す機能ブロック図である。
【図４】実施の形態１におけるボディＥＣＵのＲＯＭに記憶されている判定テーブルの内容例を示す説明図である。
【図５】実施の形態１におけるリンク情報の内容例を模式的に示す説明図である。
【図６】実施の形態１における入力信号判定モジュールにより実行される処理手順の一例を示すフローチャートである。
【図７】実施の形態１における入力信号判定モジュールによる判定処理の過程を概念的に示す説明図である。
【図８】ＣＰＵが入力信号判定モジュールとして機能する際の処理の具体例を概念的に示す説明図である。
【図９】実施の形態２におけるＲＯＭに記憶されている判定テーブルの基本構成を示す説明図である。
【図１０】実施の形態２における判定テーブルの内容例を示す説明図である。
【図１１】実施の形態２における入力信号判定モジュールにより実行される処理手順の一例を示すフローチャートである。
【図１２】従来のマイコンにおけるコンピュータプログラムの構成の概略を示す概略図である。
【発明を実施するための形態】
【００２８】
以下、本発明をその実施の形態を示す図面に基づいて具体的に説明する。なお、以下に示す実施の形態では、車両の室内に搭載されているランプ、ライト、ドア、ワイパーなどのボディ系の各種制御対象を制御する車載ボディＥＣＵに本発明の制御装置を適用した車載制御システムを例に挙げて説明する。
【００２９】
（実施の形態１）
図１は、実施の形態１における車載制御システムの構成を示す構成図である。車載制御システムは、車室内の前部天井に取り付けられるルームランプ１と、車両のドア部に設置され、ドアの開閉を検知するカーテシセンサ２，２及びドアロックを検知するドアロックセンサ３，３と、イグニッション（Ignition）キー（以下、ＩＧキーという）の挿抜を検知するＩＧキーセンサ４と、夫々を制御するボディＥＣＵ５とを含む。
【００３０】
ルームランプ１はボディＥＣＵ５に接続されており、ボディＥＣＵ５により点灯、消灯が制御される。なお、点灯、消灯のいずれにおいてもＰＷＭ制御により減光、増光が可能である。
【００３１】
カーテシセンサ２，２及びドアロックセンサ３，３はボディＥＣＵ５に接続されており、夫々ドア開閉状態を知らしめる信号又はドアロックの開閉状態を知らしめる信号をボディＥＣＵ５へ出力する。
【００３２】
ＩＧキーセンサ４はボディＥＣＵ５に接続されており、ＩＧキーセンサ４にて検知したＩＧキーの挿抜、及びキー位置を示す信号をボディＥＣＵ５へ出力する。
【００３３】
ボディＥＣＵ５は、カーテシセンサ２，２、ドアロックセンサ３，３又はＩＧキーセンサ４から出力される各信号を入力して、それらの信号レベルに基づき、例えば、ドアが閉状態で、ＩＧキーは挿入されていない状態で、ドアロックがロックからアンロックへ変化した場合には、乗車しようとするユーザによりドアが開錠された状況にあるから、ルームランプ１を点灯させるべく制御信号を出力するエントリー制御を実現する。また、同様にドアが閉状態で、ＩＧキーは挿入されていない状態で、ドアロックがアンロックからロックへ変化した場合には、降車したユーザがドアが施錠された状況にあるから、点灯していたルームランプ１を少しずつ減光させて消灯させるべく制御信号を出力するドアロック減光制御を実現する。
【００３４】
なお、実施の形態１では、ボディＥＣＵ５について、ルームランプ１の点灯に関する機能各構成部の処理のみ記載するが、ボディＥＣＵ５が他の機能を実現するために他の制御
対象となる負荷（アクチュエータ）、例えばヘッドライト、スモールランプ、フロントワイパー、リアワイパーなどを制御することが可能な構成でもよいことは勿論である。
【００３５】
このような各種機能をボディＥＣＵ５にて実現するためのボディＥＣＵ５内部の構成及び処理について説明する。ボディＥＣＵ５は後述するように、マイコン５０を備えて、マイコン５０内臓のＲＯＭ（Read Only Memory）５２に記憶されているコンピュータプログラムに基づく処理を実行することにより各種機能を実現する。
【００３６】
図２は、実施の形態１における車載制御システムに含まれるボディＥＣＵ５の内部構成を示すブロック図である。ボディＥＣＵ５は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ（Random
Access Memory）５３及びＩ／Ｏ５４を含むマイコン５０を備えて構成される。他に、カーテシセンサ２，２、ドアロックセンサ３，３、キーセンサ４などのセンサと車載ネットワークを介して接続される場合は通信手段としてネットワークコントローラ、トランシーバをマイコン５０内又は外に備える構成としてもよい。
【００３７】
ＣＰＵ５１は、ＲＯＭ５２に記憶されているコンピュータプログラムをＲＡＭ５３に読み出して実行することにより、上述のようなルームランプ１の点灯、消灯、減光機能を実現する。
【００３８】
ＲＯＭ５２には、フラッシュメモリを利用する。ＲＯＭ５２には、ＣＰＵ５１が読み出して実行するコンピュータプログラムとして、ボディ系に関する各機能を実現するためのアプリケーションプログラム５５，５５，…、アプリケーションドライバプログラム５６、入力信号判定モジュールプログラム５７が記憶されている。他に接続されるルームランプ１などの各種負荷との信号の物理層における入出力を実現するためのドライバプログラム（図示せず）が記憶されている。またＲＯＭ５２には、ＣＰＵ５１が各センサからの入力信号が示す状態を判定するために参照する判定テーブル５８，５８，…が負荷毎に記憶されている。そして、機能毎に、判定テーブル５８，５８，…間のリンク関係を示すリンク情報５９が記憶されている。
【００３９】
なお、ＲＯＭ５２は基本的に、ボディＥＣＵ５の稼働中は読み出し専用（ＲＯＭ）ではあるが、ＣＰＵ５１に実行させたいコンピュータプログラムの更新、又は判定テーブル５８，５８，…の更新が必要な場合に書換が可能である。
【００４０】
ＲＡＭ５３には、ＤＲＡＭ（Dynamic RAM）、ＳＲＡＭ（Static RAM）等を利用する。ＲＡＭ５３にはＣＰＵ５１が読み出すコンピュータプログラムがロードされる他、処理によって発生する各種情報が一時的に記憶される。
【００４１】
Ｉ／Ｏ５４は、マイコン５０と外部とのインタフェースである。マイコン５１はＩ／Ｏ５４により、ルームランプ１へ制御信号を出力する。
【００４２】
次に、マイコン５０のＣＰＵ５１がＲＯＭ５２に記憶されているコンピュータプログラムを読み出して実現するマイコン５０内の詳細な機能について説明する。図３は、実施の形態１におけるボディＥＣＵ５のマイコン５０のＣＰＵ５１にて実現される機能を概念的に示す機能ブロック図である。
【００４３】
ＣＰＵ５１は、ＲＯＭ５２に記憶されているアプリケーションプログラム５５，５５，…、アプリケーションドライバプログラム５６、入力信号判定モジュールプログラム５７、及びその他ドライバプログラムなどを読み出して実行することにより、アプリケーション層１０１、プラットフォーム層１０２の階層に分けられたソフトウェア構造にて動作する。
【００４４】
ＣＰＵ５１がアプリケーションプログラム５５，５５，…の内、エントリー制御用のアプリケーションプログラム５５に基づき、エントリー制御アプリ１０３として機能する。同様にＣＰＵ５１は、ドアロック減光制御用のアプリケーションプログラム５５に基づき、ドアロック減光制御アプリ１０４として機能する。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４としての機能は構造的に、アプリケーション層１０１に位置する。
【００４５】
ＣＰＵ５１はアプリケーションドライバプログラム５６に基づき、選択部１０５及び出力ドライバ部１０６としての機能を実現する。選択部１０５及び出力ドライバ部１０６としての機能は、ハードウェア群（制御対象群、即ちルームランプ１、ヘッドライト、スモールランプ等）を直接的に制御すべく物理層の信号を扱う所謂ドライバの機能ではなく、エントリー制御アプリ１０３又はドアロック減光制御アプリ１０４などの各種アプリケーションの処理の内の信号生成処理などの共通部分を１つにしたモジュールであり、アプリケーション層１０１に位置する。
【００４６】
ＣＰＵ５１は、入力信号判定モジュールプログラム５７に基づき、入力信号判定モジュール１０７としての機能を実現する。入力信号判定モジュール１０７としての機能は、アプリからの入力信号判定の指示があった場合に、機能に関係する入力信号の信号レベルを判定する処理を共通化した１つのモジュールである。各アプリは、入力信号判定モジュール１０７の機能を再利用して、動作を行なう状況にあるか否かを判定する。即ち、エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４はいずれも、ルームランプ１を点灯する状況にあるか、減光消灯させる状況にあるか否かを入力信号判定モジュール１０７を利用して判定する。入力信号判定モジュール１０７は、アプリケーション層１０１に位置する。
【００４７】
そしてＣＰＵ５１はドライバプログラムに基づき、入出力ドライバ１０８として機能する。入出力ドライバ１０８としての機能は所謂ドライバの機能を実現し、ハードウェア群を直接的に制御すべくＩ／Ｏ５４へ実際に物理層の制御信号の入出力を行なう。入出力ドライバ１０８としての機能は構造的に、プラットフォーム層１０２に位置する。
【００４８】
ＣＰＵ５１の選択部１０５としての機能は以下である。選択部１０５は、ＣＰＵ５１がエントリー制御アプリ１０３又はドアロック減光制御アプリ１０４としての機能により制御対象となるハードウェア、例えばルームランプ１へ点灯要求などの動作要求を発した場合に、動作要求を受け付け、制御対象と、制御対象に行なわせる具体的な動作とを特定し、特定した制御対象及び動作の内容を示す情報を出力ドライバ部１０８へ与える。
【００４９】
ＣＰＵ５１の出力ドライバ部１０６としての機能は以下である。出力ドライバ部１０６は、選択部１０５から与えられる制御対象、及び制御対象に行なわせる具体的な動作の情報に基づき、動作を実現させるための制御信号を生成して、制御対象のハードウェアへ制御信号を出力させるべくプラットフォーム層１０２の入出力ドライバ１０８へ指示する。
【００５０】
ＣＰＵ５１の入力信号判定モジュール１０７としての機能は以下である。入力信号判定モジュール１０７は、各アプリから夫々の機能に応じて抽出された入力信号について夫々、前記機能を発揮させる状況にあるか否かを判定するための判定条件の成立／不成立を判定し、判定結果を各アプリに戻すことである。実施の形態１における入力信号判定モジュール１０７は、入力信号毎に利用されるリエントランス構造となっている。
【００５１】
このようにまず、本実施の形態１のボディＥＣＵ５では、各アプリケーションからの動作要求を選択部１０５にて一括して受け付け、制御信号の生成を行なう出力ドライバ部１
０６の機能を共有化する構成とする。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４など各アプリケーション毎、制御対象の負荷毎に、制御信号を生成して入出力ドライバ１０８へ夫々出力する構成（図１２参照）ではない。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４などのいずれのアプリケーションでも、制御がオン、オフのスイッチングにて実現する場合、動作要求に応じて制御信号を生成する処理は、動作の具体的内容が異なるのみで共通した処理であるから共有化が可能である。また、ボディＥＣＵ５では、各制御対象のハードウェアの制御を同時に行なうことはなく、各アプリケーションの機能も順に実現されるから制御信号の生成処理が同時に行なえる構成とする必要はないので共有化が可能である。当該処理を１つにして各機能から再利用可能に共有化した構成とすることにより、ＲＯＭ５２及びＲＡＭ５３におけるメモリ占有量を削減できる。
【００５２】
また、本実施の形態１のボディＥＣＵ５では、入力信号に対する判定も入力信号判定モジュール１０７に共有化される構成とする。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４など各アプリケーションに夫々、入力信号毎に入力信号判定処理を行なうモジュールが含まれる構成ではない。エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４などのいずれのアプリケーションでも、更に、いずれの入力信号についても、信号レベルがＨｉであるかＬｏｗであるかの判定が行なわれる。判定の対象である入力信号がいずれであるかが異なるのみで、判定処理自体は共通するから共有化が可能である。また、ボディＥＣＵ５では、各制御対象のハードウェアの制御を同時に行なうことはなく、各アプリケーションの機能も順に実現されるから各アプリケーションの機能で入力信号に対する判定処理が同時に行なえる必要もない。入力信号判定処理を１つにして各機能から再利用可能に共有化した構成とすることにより、ＲＯＭ５２及びＲＡＭ５３におけるメモリ占有量を更に削減できる。
【００５３】
具体的には、ＣＰＵ５１にて各機能が実現される場合、図３の各ブロックにて示す各機能に対応する実行プログラムファイル（プログラムコード）が必要となる。まず、制御対象の決定及び制御信号の生成処理の機能を１つの選択部１０５及び出力ドライバ部１０６に共有化して、各種機能から利用される構成とすることにより、複数のアプリケーションプログラム５５，５５，…夫々に対応させたアプリケーションドライバプログラムを複数実行する構成よりもＲＯＭ５２及びＲＡＭ５３における記憶容量が少なくて済む。各アプリケーションプログラム５５，５５，…で、出力ドライバ部１０６に対応するプログラムコードを用意する必要がないからである。同様に、入力信号判定処理を入力信号判定モジュール１０７に共有化して各アプリケーションの機能から利用される構成とすることにより、各アプリケーションにおける入力信号判定処理のプログラムコードを省略することができるから、更にＲＯＭ５２及びＲＡＭ５３における記憶容量が少なくて済む。また、実現したい各機能について実際に、入力信号を判定する処理、及び制御信号を生成する処理を実装せずとも、入力信号判定モジュール１０７、選択部１０５及び出力ドライバ部１０６の機能を再利用すればよいので、機能の開発は動作要求を発するアプリケーションプログラム５５，５５，…の開発のみで済み、開発効率を向上させることができる。
【００５４】
次に、エントリー制御アプリ１０３及びドアロック減光制御アプリ１０４が入力信号判定モジュール１０７を利用して判定結果を得る処理について詳細を説明する。
【００５５】
ＲＯＭ５２には、負荷毎に信号レベルに応じた判定テーブル５８，５８，…が記憶されている。判定テーブル５８，５８，…は、センサなどの信号の出力元毎の判定条件及び判定方法を含む。図４は、実施の形態１におけるボディＥＣＵ５のＲＯＭ５２に記憶されている判定テーブル５８，５８，…の内容例を示す説明図である。判定テーブル５８，５８，…では、入力信号の種類毎に、判定の方法及び判定条件が記憶されている。
【００５６】
図４には、ＩＧキーセンサ４、カーテシセンサ２，２、及びドアロックセンサ３，３からの入力信号の判定テーブル５８，５８，５８の例が示されている。ＩＧキーセンサ４からの入力信号はＩＧキーの挿抜、及びキー位置を検知したセンサ情報を示す。入力信号判定モジュール１０７では、与えられた入力信号のレベル判定か又はエッジ判定かを行なうようにしてある。入力信号に対し、エッジ判定によりＯＦＦからＯＮとなったか、レベル判定によりＯＮであるか、エッジ判定によりＯＮからＯＦＦとなったか、又はレベル判定によりＯＦＦであるかのいずれであるかが判定される。このとき、ＯＮはキー位置がＩＧ１の位置にあることに対応する。
【００５７】
カーテシセンサ２，２からの入力信号はドアの開閉を検知したセンサ情報を示す。カーテシセンサ２，２からの入力信号についても、与えられた入力信号のレベル判定か又はエッジ判定かのいずれかの方法でＯＮであるかＯＦＦであるかが判定される。ＯＮは開に対応し、ＯＦＦは閉に対応する。
【００５８】
ドアロックセンサ３，３からの入力信号は、ドアロックのロック／アンロックを検知したセンサ情報を示す。ドアロックセンサ３，３からの入力信号についても、与えられた入力信号のレベル判定か又はエッジ判定かのいずれかの方法でＬＯＣＫ（ＯＮ）であるかＵＮＬＯＣＫ（ＯＦＦ）であるかが判定される。
【００５９】
入力信号判定モジュール１０７は、図４に示したような判定テーブル５８，５８，…を参照して、各アプリから入力信号が与えられた場合にその信号レベルから、判定条件のうちのいずれが成立するか否かを判定する。例えば入力判定モジュール１０７は、ドアロックセンサ３，３からの入力信号に対し、エッジ判定を行なった結果ＵＮＬＯＣＫからＬＯＣＫとなったという判定条件、レベル判定を行なった結果ＬＯＣＫであるという判定条件、エッジ判定を行なった結果ＬＯＣＫからＵＮＬＯＣＫとなったという判定条件、又はレベル判定を行なった結果ＵＮＬＯＣＫであるという判定条件のいずれが成立するかを判定する。
【００６０】
入力信号判定モジュール１０７は更に、判定結果に応じて、次の入力信号に対する判定を行なう。このとき入力信号判定モジュール１０７は、判定結果に応じた次の入力信号がいずれなのかを各アプリから与えられるリンク情報５９を参照して判断する。リンク情報５９は、機能毎及び負荷毎に、各判定テーブル５８，５８，…に基づく判定結果の分岐に応じて、次にいずれの入力信号、及び入力信号の判定テーブル５８，５８，…にて判定がされるべきかを示す情報である。
【００６１】
図５は、実施の形態１におけるリンク情報５９の内容例を模式的に示す説明図である。図５に示すリンク情報５９は、ユーザが乗車しようとして車外からドアロックを開錠した場合にルームランプ１を点灯させるエントリー制御アプリ１０３に対応している。
【００６２】
リンク情報５９は、アプリケーションプログラム５５、又はその機能毎に抽出されるべき入力信号を含む。図５の例に示すリンク情報５９は、エントリー制御アプリ１０３に対応する入力信号がＩＧキーセンサ４からの入力信号、カーテシセンサ２，２からの入力信号、及びドアロックセンサ３，３からの入力信号であることを示している。
【００６３】
そしてリンク情報５９は、判定結果に応じた次の判定対象の入力信号の情報を含む。図５の例では、各入力信号に対する判定テーブル５８と、判定結果に応じた次の判定テーブル５８のＲＯＭ５２内におけるアドレスとのリンク関係が示されている。つまり、入力信号についての判定テーブル５８に基づく判定結果に応じて、次に判定対象とすべき入力信号の判定テーブル５８のアドレスが記述されている。図５の「ＮＵＬＬ」は、次に判定対象とすべき入力信号の判定テーブル５８が「無い」ことを示している。次の判定テーブル
５８が「無い」場合は、入力信号判定モジュール１０７は入力信号の判定処理を終了する。
【００６４】
図５の例では、具体的には、エントリー制御アプリ１０３に関し、入力信号判定モジュール１０７で最初に判定されるべき入力信号はＩＧキーセンサ４からの入力信号であることが示されている。そして、ＩＧキーセンサ４からの入力信号に対する判定テーブル５８に基づき、入力信号がＯＮであると判定された場合には、ＯＦＦからＯＮに変化した場合もＯＮのままである場合も、判定結果は「不成立」であることが示されている。この場合、これ以上判定する必要はないので、次に判定対象とすべき入力信号の判定テーブル５８のアドレスは「ＮＵＬＬ」を示している。
【００６５】
このように、機能毎に判定対象の入力信号と、判定結果に応じて次に判定対象とすべき入力信号の順序とを示すリンク情報５９をＲＯＭ５２に記憶しておく構成により、１つの入力信号判定モジュール１０７が処理を行なうとしてもリンク情報５９の内容に応じて、種々の入力信号に対する判定処理を行なうことができる。
【００６６】
図５に示したように、実施の形態１におけるリンク情報５９は、各入力信号に対する判定テーブル５８，５８，…のアドレス同士のリンク関係にて示した。しかしながら、リンク情報５９の内容はこれに限らず、判定結果に応じて、次にいずれの入力信号についての判定をするべきかを示す情報であればよい。
【００６７】
なお、リンク情報５９には、上述のようなエントリー制御アプリ１０３のルームランプ１についての情報のみならず、他のアプリケーションプログラム５５，５５，…、負荷に対応する情報が含まれることは勿論である。
【００６８】
このような判定テーブル５８，５８，…及びリンク情報５９を参照して、入力信号判定モジュール１０７が各入力信号に対する判定結果に基づいて、機能を実現すべき状況に有るか、即ち動作すべき条件が成立するか否かを判断する処理についてフローチャートを参照して説明する。
【００６９】
図６は、実施の形態１における入力信号判定モジュール１０７により実行される処理手順の一例を示すフローチャートである。以下の処理は、エントリー制御アプリ１０３が、自身のエントリー制御の動作を行なう状況にあるか否かを判断するために行なわれる。エントリー制御アプリ１０３は、入力信号判定モジュール１０７に、自身の動作状況判定に関するリンク情報５９を指示する情報を与える。
【００７０】
入力信号判定モジュール１０７は、与えられた情報からリンク情報５９を特定してＲＯＭ５２から読み出し（ステップＳ１）、リンク情報５９に基づき、判定に必要な入力信号を抽出して読み込む（ステップＳ２）。
【００７１】
次に入力信号判定モジュール１０７は、抽出した入力信号に対する判定テーブル５８，５８，…を読み出す（ステップＳ３）。入力信号判定モジュール１０７は、リンク情報５９に基づき、抽出した入力信号の内、最初に判定対象とすべき入力信号について、入力信号の信号レベルの状態が判定テーブル５８のいずれの判定条件に一致するかを判断する（ステップＳ４）。
【００７２】
入力信号判定モジュール１０７は、ステップＳ４にて、入力信号が「ＯＦＦ」から「ＯＮ」へ変化したという判定条件に一致すると判断した場合（Ｓ４：ＯＦＦ→ＯＮ）、リンク情報５９から当該条件に一致する場合の次の判定テーブル５８のアドレスを取得する（ステップＳ５）。そして入力信号判定モジュール１０７は、取得したアドレスは「ＮＵＬ
Ｌ」か否かを判断する（ステップＳ６）。
【００７３】
入力信号判定モジュール１０７は、ステップＳ６にて取得したアドレスが「ＮＵＬＬ」でないと判断した場合（Ｓ６：ＮＯ）、次の入力信号及びその判定テーブル５７に基づく判定を行なうべく、処理をステップＳ２へ戻す。
【００７４】
入力信号判定モジュール１０７は、ステップＳ６にて取得したアドレスが「ＮＵＬＬ」であると判断した場合（Ｓ６：ＹＥＳ）、次に判定すべき入力信号はないので、ステップＳ４における判断結果に対応する条件成立／不成立の判定結果を、リンク情報５９から読み出して戻り値として、入力信号判定モジュール１０７の呼び出し元のアプリへ返し（ステップＳ７）、処理を終了する。
【００７５】
入力信号判定モジュール１０７は、ステップＳ４における他の判定条件、即ち入力信号が「ＯＮ」から「ＯＮ」のままという判定条件に一致すると判断した場合（Ｓ４：ＯＮ→ＯＮ）、「ＯＮ」から「ＯＦＦ」へ変化したという判定条件に一致すると判断した場合（Ｓ４：ＯＮ→ＯＦＦ）、又は、「ＯＦＦ」から「ＯＦＦ」のままという判定条件に一致すると判断した場合（Ｓ４：ＯＦＦ→ＯＦＦ）、いずれの場合も次の判定テーブル５８のアドレスを取得し（Ｓ８、Ｓ１１、Ｓ１４）、アドレスが「ＮＵＬＬ」か否かを判断し（Ｓ９、Ｓ１２、Ｓ１５）、アドレスが「ＮＵＬＬ」でない場合は（Ｓ９、Ｓ１２、Ｓ１５：ＮＯ）、処理をステップＳ２へ戻し、アドレスが「ＮＵＬＬ」である場合は（Ｓ９、Ｓ１２、Ｓ１５：ＹＥＳ）、ステップＳ４における判断結果に対応する判定結果をアプリへ戻り値として返し（Ｓ１０、Ｓ１３、Ｓ１６）、処理を終了する。
【００７６】
図６のフローチャートに示したように、入力信号判定モジュール１０７では、各入力信号の状態に対する判定を、与えられる入力信号と当該入力信号に対す判定テーブル５８とを用いて、同じプログラムコード内で繰り返し処理できる構成により（Ｓ４〜Ｓ１５）、各入力信号に対する処理を夫々プログラムコードとして実装せずともよい点で効果的である。
【００７７】
図７は、実施の形態１における入力信号判定モジュール１０７による判定処理の過程を概念的に示す説明図である。図７には、エントリー制御アプリ１０３から、判定処理を要求された場合に図６に示したように入力信号判定モジュール１０７が処理を行なったときに、図５に示したリンク情報５９に基づいて読み出される判定テーブル５８が示されている。
【００７８】
図７に示すように、入力信号判定モジュール１０７は、エントリー制御アプリ１０３から、判定処理を要求された場合に、まずエントリー制御に関するリンク情報５９を読み出す（Ｓ１）。入力信号判定モジュール１０７は最初に、ＩＧキーセンサ４からの入力信号を読み込んで（Ｓ２）、当該入力信号に対する判定を行なう。入力信号判定モジュール１０７は、ＩＧキーセンサ４からの入力信号に対応する判定テーブル５８を読み出し（Ｓ３）、判定テーブル５８に含まれているいずれの条件に一致するかを判断する（Ｓ４）。
【００７９】
入力信号判定モジュール１０７は、ＩＧキーセンサ４からの入力信号が「ＯＮ」状態である場合、「ＯＮ」から「ＯＮ」のままでも、「ＯＦＦ」から変化したときでも、次の判定テーブル５８のアドレスは「ＮＵＬＬ」であるから、判定結果としてＩＧキーセンサ４からの入力信号の「ＯＮ」状態であることに対する判定結果の「条件不成立」を戻り値として返す（Ｓ１０）。
【００８０】
エントリー制御のルームランプ１の点灯制御では、車外からユーザが車両に乗ろうとしてドアロックを開錠した場合に行なう。キー位置がＩＧ１の位置にある場合では、既にユ
ーザがドアロックを開錠してドアを開けて、エンジンをかけた状況であるから、当該エントリー制御を行なうべきでないからである。
【００８１】
エントリー制御アプリ１０３は、入力信号判定モジュール１０７から「条件不成立」の判定結果を返された場合、自身の処理により制御対象に動作を要求する状況を示す条件が「条件不成立」であると認識し、動作要求は行なわない。
【００８２】
入力信号判定モジュール１０７は、ＩＧキーセンサ４からの入力信号が「ＯＦＦ」状態である場合、「ＯＮ」から「ＯＦＦ」変化したときでも、「ＯＦＦ」から「ＯＦＦ」のままでも、次のテーブル５８のアドレスは、カーテシセンサ２，２からの入力信号に対する判定テーブル５８のアドレスである。したがって入力信号判定モジュール１０７は、カーテシセンサ２，２からの入力信号を読み込み（Ｓ２）、判定テーブル５８におけるいずれの条件に一致するかを判断する（Ｓ３、Ｓ４）。この場合も、カーテシセンサ２，２からの入力信号がいずれか一方のみでも「ＯＮ」状態である場合は、次の判定テーブル５８のアドレスは「ＮＵＬＬ」であるから判定処理は終了され、「条件不成立」の判定結果が返される（Ｓ１０）。
【００８３】
カーテシセンサ２，２からの入力信号が「ＯＦＦ」状態である場合には、次の判定テーブル５８としてドアロックセンサ３，３からの入力信号に対する判定テーブル５８のアドレスがリンク情報５９から読み出せる。したがって入力信号判定モジュール１０７は次に、ドアロックセンサ３，３からの入力信号を読み込み（Ｓ２）、判定処理を行なう。
【００８４】
入力信号判定モジュール１０７は、ドアロックセンサ３，３からの入力信号がいずれの判定条件に一致したとしても、次の判定テーブル５８のアドレスとして「ＮＵＬＬ」を取得する（Ｓ５，Ｓ８，Ｓ１１，Ｓ１４）。したがって、アドレスは「ＮＵＬＬ」であるから（Ｓ６，９，１２，１５：ＹＥＳ）、入力信号判定モジュール１０７は、ドアロック３，３からの入力信号が一致する判定条件に対応する判定結果を戻り値として返し（Ｓ７，Ｓ１０，Ｓ１３，Ｓ１６）、処理終了する。このとき、図５のリンク情報５９の内容例では、ドアロックセンサ３，３からの入力信号の状態が「ＬＯＣＫ」から「ＵＮＬＯＣＫ」へ変化したという条件に一致する場合のみ、判定結果として「条件成立」が返される。
【００８５】
つまり、入力信号モジュール１０７は、図５に示すようなリンク情報５９に基づき、エントリー制御に対する判定処理を行なう場合、ＩＧキーセンサ４からの入力信号が「ＯＦＦ」であって、カーテシセンサ２，２からの入力信号も「ＯＦＦ」であって、更にドアロックセンサ３，３からの入力信号が「ＬＯＣＫ」から「ＵＮＬＯＣＫ」へ変化したときのみ「条件成立」となり、エントリー制御アプリ１０３によりエントリー制御が実行される。
【００８６】
このように、リンク情報５９に入力信号を読み込む順序、及び当該入力信号に対する判定結果に応じた次の入力信号の関係がリンク形式で示されていることにより、入力信号判定モジュール１０７は、エントリー制御アプリ１０３から、ルームランプ１のエントリー制御に対する入力信号判定の要求がされるのみで、判定処理を行なうことができる。
【００８７】
なお、リンク情報５９を用いて、最初に１つでも条件不成立となるような判定条件に入力信号の状態が一致した場合に処理が終了できる構成としたことにより、他の入力信号に対する判定処理をその後行なわずともよく、処理が迅速化される点で効果的である。
【００８８】
図８は、ＣＰＵ５１が入力信号判定モジュール１０７として機能する際の処理の具体例を概念的に示す説明図である。図８には、ＣＰＵ５１が入力信号判定モジュール１０７として機能している際にＲＡＭ５３を占有する各種情報をブロックにて示している。
【００８９】
図８中の上段に示すように、ＲＡＭ５３にはボディＥＣＵ５の制御対象である負荷、例えばヘッドライト、ルームランプ１についての動作状態と、各負荷に関して起動中の機能と、当該機能に対応する入力信号に対する判定結果とが記憶されている。同一の制御対象であっても対応する機能に応じて夫々動作状態、判定結果が記憶されている。例えば、エントリー制御の機能に対しては、当該機能を発揮するため動作要求を出力する条件が成立しているが、ドアロック減光制御の機能に対しては条件が成立していないなどの状態は勿論ありえるからである。動作状態の内容は、停止中、オン（点灯）、オフ（消灯）などのいずれかである。なお、斜線にて示す動作状態及び判定結果は、選択部１０５、出力ドライバ部１０６及び入力信号判定モジュール１０７などの処理により随時書き換えられる。
【００９０】
図８中の下段には、判定テーブル及びリンク情報の内容が示されている。図８に示すＲＡＭ５３に記憶されている判定テーブル及びリンク情報は、ＣＰＵ５１によってＲＯＭ５２から一時的に読み出された判定テーブル５８，５８，…及びリンク情報５９の一部である。
【００９１】
図８中の中段には、入力信号判定モジュール１０７のプログラムコードがロードされていることが示されている。このとき、１つのプログラムコードとしてロードされる入力信号判定モジュール１０７により、種々の機能にて複数の負荷夫々に対する動作を要求する状況にあるか否かの判定結果が行なわれることに注目すべきである。入力信号判定モジュール１０７は、エントリー制御アプリ１０３から、入力信号に対する判定処理を行なうべく呼び出された場合、エントリー制御に係るリンク情報５９をＲＡＭ５３に読み出し、各入力信号に対する判定テーブルを読み出し、判定処理を行って判定結果をエントリー制御に対応する記憶領域に書き込む。他の各アプリに呼び出された場合であっても、１つの入力信号判定モジュール１０７にて各アプリに対応する記憶領域にて記憶されている固有の情報を書き換えるなどして、共通のコードで固有の動作を行なう。
【００９２】
このように、エントリー制御アプリ１０３に対応する入力信号判定処理も、ドアロック減光制御アプリ１０４に対応する入力信号判定処理も、共通して入力信号判定モジュール１０７が処理を行なう。これにより、各アプリで夫々入力信号判定のプログラムコードを実装する必要が無く、実行中に重複する内容が多いプログラムコードが多数ＲＡＭ５２にロードされてメモリを占有することが無い。
【００９３】
１つのプログラムコードで、各アプリからの動作要求毎に順に実行することにより、オブジェクト指向型の概念において１つの共通する入力信号判定処理を持つクラスを各機能毎、入力信号毎に夫々実体化するようにクラスが持つ共通処理を固有パラメータに対して実行する構成を、メモリ容量に制限がある組み込み系のコンピュータプログラムでも実現することができる。
【００９４】
処理の実行中にＲＡＭ５３にてプログラムコードが占有する容量が少なくて済み、また、動的に容量が確保されることもなく煩雑なメモリ管理も要しないので、簡易な構成のマイコンに基づくＥＣＵにおける処理に適している。
【００９５】
ＲＡＭ５３の記憶容量を節約できるのでボディＥＣＵ５の内部構成を簡素化させることができる。更に、ボディＥＣＵ５にて実現したい機能毎に、入力信号に対する判定処理を実行させるプログラムを実装せずとも、共有化された入力信号判定モジュール１０７の機能を共有化する。したがって、入力信号判定モジュール１０７とのインタフェースを考慮すれば、アプリケーションプログラム５５，５５，…では、入力信号判定処理以外の開発のみで済み、開発効率を向上させることができる。
【００９６】
実施の形態１では、判定テーブル５８，５８，…は入力信号毎に別個のテーブルとして構成した。しかしながら、入力信号毎に判定条件を示す１個のテーブルとして構成されてもよい。この場合、リンク情報５９に示されている次の判定テーブル５８のアドレスは、次の入力信号の判定条件の項目の箇所を示すアドレスとなる。当該構成でも、リンク情報５９の利用方法は同じであり、各機能の固有の情報を１つの入力信号判定モジュール１０７で用いて個々の入力信号に対する判定処理を実行することができる。
【００９７】
（実施の形態２）
実施の形態１では、入力信号判定モジュール１０７は、図５に示したリンク情報５９に基づいて、判定対象の入力信号を順に読み出し、夫々に対する判定テーブル５８，５８，…における判定条件により判定を行なって最終的な判定結果を得る構成とした。これに対し、実施の形態２では、判定テーブル５８，５８，…は機能毎に、判定対象となる入力信号と、各機能のために動作を要求する条件となる該入力信号に対するマスク情報及び信号状態との対応を記憶したものである。判定対象の入力信号を読み込む順序をも参照できるリンク情報５９を用いない。
【００９８】
以下に示す実施の形態２の車載制御システムは、リンク情報５９がＲＯＭ５２に記憶されていないこと、判定テーブル５８，５８，…の内容、及び入力信号判定モジュール１０７の判定処理の詳細が異なる。リンク情報５９が記憶されていない以外は、ハードウェア的な構成は実施の形態１における車載制御システムと同様であるので、図示及び詳細な説明を省略する。共通する構成部については同一の符号を用いて説明する。
【００９９】
図９は、実施の形態２におけるＲＯＭ５２に記憶されている判定テーブル５８，５８，…の基本構成を示す説明図である。判定テーブル５８，５８，…では、機能毎に、当該機能に対応する負荷に、前記機能に対応する動作を要求する状況であるか否かを判断するための入力信号と、夫々の入力信号の状態を判断するためのマスク情報及び入力信号が充たすべき信号状態が判定条件として記憶されている。図９に示す例では、入力信号判定モジュール１０７は、ある機能に対応するアプリから呼び出された場合、入力信号Ａ、入力信号Ｂ及び入力信号Ｃ夫々について、各々マスク情報に基づき信号をマスクして信号を読み取ったときに信号状態という判定条件が成立しているか否かを判定し、判定結果を返す。
【０１００】
なお判定テーブル５８，５８，…は、機能毎のみならず、制御対象の負荷毎に、当該負荷に関する機能毎の判定テーブルを含む構成としてもよい。図１０は、実施の形態２における判定テーブル５８，５８，…の内容例を示す説明図である。図１０に示す例では、ルームランプ１を制御対象とする各機能について、マスク情報と信号状態の判定条件が含まれている。
【０１０１】
ドアが開いている間はルームランプ１を点灯させる機能にて、ルームランプ１へ点灯を要求するのは、カーテシセンサ２，２からの入力信号をレベル判定するようにマスクして読み取ったときに信号状態が「ＯＮ」であるという条件が成立したときであることが示されている。マスク情報が「レベル」であるから、信号状態が「ＯＦＦ」から「ＯＮ」へ変化した場合であっても「ＯＮ」から「ＯＮ」のままであってもよい。当該判定テーブル５８に基づき、入力信号判定モジュール１０７は、ドアが開いている間はルームランプ１を点灯させる機能のアプリから呼び出された場合、カーテシセンサ２，２からの入力信号に対する判定処理のみ行なえばよい。なお当該判定処理に、ＩＧキー４からの入力信号及びドアロックセンサ３，３からの入力信号は無効であることが「−」で示されている。
【０１０２】
図１０に示す他の例は、ドアが閉じた場合にルームランプ１を消灯させる機能にて、ルームランプ１への点灯要求を停止するのは、カーテシセンサ２，２からの入力信号をエッジ判定するようにマスクして読み取ったときに信号状態が「ＯＮ」から「ＯＦＦ」へ変化
したという条件が成立したときであることが示されている。マスク情報が「エッジ」であるから、信号状態が変化した場合のみ条件が成立する。この場合も、カーテシセンサ２，２からの入力信号のみ判定処理を行なえばよい。
【０１０３】
また他の例は、エントリー制御アプリ１０３の機能、即ち、車外からユーザが車両に乗るためにドアロックが開錠されたときにルームランプ１を点灯させる機能にて、ルームランプ１へ点灯を要求するのは、以下の入力信号及び各入力信号に対する判定条件がいずれも成立したときである。つまり、ＩＧキーセンサ４からの入力信号をレベル判定するようにマスクして読み取ったときに信号状態が「ＯＦＦ」状態であるという条件が成立し、カーテシセンサ２，２からの入力信号をレベル判定するようにマスクして読み取ったときに「ＯＦＦ」状態であるという条件が成立し、且つ、ドアロックセンサ３，３からの入力信号をエッジ判定するようにマスクして読み取ったときに信号状態が「ＬＯＣＫ」から「ＵＮＬＯＣＫ」へ変化したという条件が成立したときのみである。
【０１０４】
このような判定テーブル５８を用いた入力信号判定モジュール１０７による判定処理について説明する。図１１は、実施の形態２における入力信号判定モジュール１０７により実行される処理手順の一例を示すフローチャートである。以下の処理は、エントリー制御アプリ１０３が、自身のエントリー制御の動作を行なう状況にあるか否かを判断するために行なわれる。エントリー制御アプリ１０３は、入力信号判定モジュール１０７に、制御対象に対応する判定テーブル５８を指示する情報を与える。
【０１０５】
入力信号判定モジュール１０７は、与えられた判定テーブル５８を読み出し（ステップＳ２１）、自身の呼び出し元の機能を特定して機能に対応する判定テーブル５８からマスク情報及び判定条件を読み出し（ステップＳ２２）、読み出したマスク情報に基づき各入力信号にマスク処理を行なう（ステップＳ２３）。具体的には、複数の入力信号に対し判定対象以外の信号をマスクし、レベル判定対象の入力信号にはレベルのみとなるようにマスクする。
【０１０６】
詳細には、入力信号判定モジュール１０７は、エントリー制御についての判定対象であるＩＧキーセンサ４からの入力信号、カーテシセンサ２，２からの入力信号、及びドアロックセンサ３，３からの入力信号を含む複数の入力信号の情報を取得する。各入力信号はエッジ型で各々１バイトで表わされ、最下位２ビットで変化が表わされる。例えば入力信号がＯＮからＯＦＦとなった場合には入力信号は０ｘ０２で、ＯＦＦからＯＮとなった場合には０ｘ０１で表わされる。ＯＮのままの場合は０ｘ０３で表わされる。マスク情報も夫々１バイトで表わされ、レベル判定のみの場合は０ｘ０１、エッジ判定の場合は０ｘ０３である。条件が成立するための信号状態も１バイトで表わされ、ＯＮからＯＦＦは０ｘ０２、ＯＮであることは０ｘ０１で表わされる。入力信号判定モジュール１０７は、これらの各入力信号に対してマスク情報とのＡＮＤを取ることでマスク処理を行なう。例えば、入力信号が０ｘ０２である場合にレベル判定のマスク情報に基づいてマスクした結果は０ｘ００となるし、エッジ判定のマスク情報に基づいてマスクした結果は０ｘ０２である。なお、入力信号判定モジュール１０７は、これらの１バイトずつの入力信号の情報、マスク情報及び信号状態を夫々、例えば４バイトの情報としてまとめ、一括した演算を可能とする。例えば入力信号の情報は０ｘ０３０００２００、マスク情報は０ｘ０１０１０３００である場合、マスク処理により０ｘ０１０００２００が得られ、まとめられた判定対象の信号状態０ｘ０００００２００と一致するかが後述のステップＳ２４のように判定される。
【０１０７】
次に入力信号判定モジュール１０７は、マスク処理を行なって得られた信号がステップＳ２２にて読み出した判定条件の信号状態に一致するか否かにより複数の入力信号に対する判定条件の成否を一括して判定する（ステップＳ２４）。入力信号判定モジュール１０
７は、ステップＳ２４にて条件が成立すると判定した場合（Ｓ２４：ＹＥＳ）、条件成立という判定結果を戻り値として返し（ステップＳ２５）、処理を終了する。
【０１０８】
入力信号判定モジュール１０７は、ステップＳ２４にて条件が不成立であると判定した場合（Ｓ２４：ＮＯ）、全入力信号について条件の成否を判定したかを判断する（ステップＳ２６）。一括して判定される入力信号は上述の例では４つであるから、他にある場合には再度判定が必要である。入力信号判定モジュール１０７は、全入力信号について条件の成否を判定したと判断した場合（Ｓ２６：ＹＥＳ）、条件不成立という判定結果を戻り値として返し（ステップＳ２７）、処理を終了する。
【０１０９】
入力信号判定モジュール１０７は、全入力信号について条件の成否を判定していないと判断した場合（Ｓ２６：ＮＯ）、処理をステップＳ２２へ戻し、次の判定対象のマスク情報及び判定条件の信号状態を読み出して処理を継続する。
【０１１０】
図１１に示した処理手順を実行する入力信号判定モジュール１０７の処理によっても、エントリー制御アプリ１０３から呼び出された場合、図７に示したような過程を経て、ルームランプ１へ点灯を要求する状況であるか否かを判断できる。実施の形態２における構成では、入力信号判定モジュール１０７が判定対象の入力信号に対して順に判定がされることなしに、一括して信号状態に対する判定が行なわれる点が、実施の形態１と異なる。
【０１１１】
実施の形態２では、複数の入力信号が判定対象として抽出された場合に一括して判定されるので処理が迅速化される。
【０１１２】
実施の形態２でも、入力信号判定モジュール１０７が、複数の各アプリに対して共有化されることは実施の形態１と同様である。つまり、エントリー制御アプリ１０３に対応する入力信号判定処理も、ドアロック減光制御アプリ１０４に対応する入力信号判定処理も、共通して入力信号判定モジュール１０７が処理を行なう。判定処理の詳細が異なるのみである。これにより、各アプリで夫々入力信号判定のプログラムコードを実装する必要が無く、実行中に重複する内容が多いプログラムコードが多数ＲＡＭ５２にロードされてメモリを占有することが無い。開発効率を向上させることができる点も、実施の形態１と同様である。
【０１１３】
なお、開示された実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上述の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。
【符号の説明】
【０１１４】
１ ルームランプ（制御対象）
２ カーテシセンサ
３ ドアロックセンサ
４ ＩＧキーセンサ
５ ボディＥＣＵ（制御装置）
５０ マイコン（マイクロコンピュータ）
７２ ＲＯＭ（記憶手段）
５５ アプリケーションプログラム
５６ アプリケーションドライバプログラム
５７ 入力信号判定モジュールプログラム（コンピュータプログラム）
５８ 動作パターンテーブル
５９ リンク情報（分岐条件情報）
１０３ エントリー制御アプリ（アプリケーション）
１０４ ドアロック減光制御アプリ（アプリケーション）
１０７ 入力信号判定モジュール（判定手段）
【特許請求の範囲】
【請求項１】
複数の制御対象の状態情報又は複数のセンサからの検知情報を示す信号の入力を受け付けるマイクロコンピュータを備え、該マイクロコンピュータが複数のアプリケーションプログラムに基づく処理を行ない、入力信号から判断される状況に応じて、前記複数の制御対象の内のいずれかへ動作要求を出力して前記制御対象の動作を制御するようにしてある制御装置において、
入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定する判定手段と、
複数の入力信号から、アプリケーションプログラムの機能毎に１又は複数の入力信号を抽出する抽出手段と、
機能毎に抽出した１又は複数の入力信号、及び該入力信号に対応する判定条件を、前記判定手段に与え、前記判定手段からの各判定結果に応じて、動作要求を出力する状況であるか否かを判断する判断手段と
を備えることを特徴とする制御装置。
【請求項２】
機能毎に、前記判定手段へ与える入力信号及び判定条件、並びに、前記判定手段へ入力信号及び判定条件を与えた場合の判定結果に応じて次に与えるべき入力信号及び判定条件を示す分岐条件情報を記憶する手段を備え、
前記判断手段は、前記分岐条件情報に基づき、各判定結果に応じて次の入力信号及び判定条件を選択して与えるようにしてあること
を特徴とする請求項１に記載の制御装置。
【請求項３】
入力信号毎に判定条件を示すテーブルを備え、
前記分岐条件情報は、次に与えるべき入力信号の判定条件の参照箇所を示すアドレスを含むこと
を特徴とする請求項２に記載の制御装置。
【請求項４】
前記判断手段は、前記分岐条件情報に基づいて入力信号及び判定条件を前記判定手段へ順次与えた場合の最後の判定結果が成立である場合、動作要求を出力する状況であると判断するようにしてあること
を特徴とする請求項２又は３に記載の制御装置。
【請求項５】
各機能に対応する入力信号、及び該入力信号への判定条件を示すテーブルを機能毎に備え、
前記抽出手段は、前記テーブルに基づいて入力信号を抽出するようにしてあること
を特徴とする請求項１に記載の制御装置。
【請求項６】
複数の制御対象の状態情報又は複数のセンサからの検知情報を示す信号の入力を受け付けるマイクロコンピュータを用い、該マイクロコンピュータに複数のアプリケーションプログラムに基づく処理を行なわせると共に、前記マイクロコンピュータは、前記複数のアプリケーションプログラムと異なるコンピュータプログラムに基づき、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定する判定手段として機能し、入力信号から判断される状況に応じて、前記複数の制御対象の内のいずれかへ動作要求を出力させて前記制御対象の動作を制御する方法であって、
前記マイクロコンピュータは、
前記アプリケーションプログラムに基づく処理により、
機能毎に、該機能に関する入力信号を１又は複数抽出し、
抽出した１又は複数の入力信号、及び該入力信号に対応する判定条件を前記判定手段へ順次与え、
前記判定手段からの各判定結果に応じて、動作要求を出力する状況であるか否かを判断し、
出力する状況であると判断した場合に動作要求を出力させる
ことを特徴とする制御方法。
【請求項７】
複数の制御対象又は複数のセンサが接続され、前記制御対象の状態情報又は前記センサからの検知情報を示す信号の入力を受け付けるコンピュータに、複数のアプリケーションプログラムに基づき、入力信号から判断される状況に応じて複数の制御対象の内のいずれかへ動作要求を出力させて前記制御対象を動作させる処理を実行させる際に、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定させる判定手段として機能させるコンピュータプログラムであって、
コンピュータを、
アプリケーションプログラムの機能毎に抽出された１又は複数の入力情報、及び該入力情報に対応する判定条件、前記判定手段へ与える手段、及び、
１又は複数の入力情報を与えて前記判定手段により得られた各判定結果により、動作要求を出力する状況であるか否かを判断する手段
として機能させることを特徴とするコンピュータプログラム。
【請求項１】
複数の制御対象の状態情報又は複数のセンサからの検知情報を示す信号の入力を受け付けるマイクロコンピュータを備え、該マイクロコンピュータが複数のアプリケーションプログラムに基づく処理を行ない、入力信号から判断される状況に応じて、前記複数の制御対象の内のいずれかへ動作要求を出力して前記制御対象の動作を制御するようにしてある制御装置において、
入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定する判定手段と、
複数の入力信号から、アプリケーションプログラムの機能毎に１又は複数の入力信号を抽出する抽出手段と、
機能毎に抽出した１又は複数の入力信号、及び該入力信号に対応する判定条件を、前記判定手段に与え、前記判定手段からの各判定結果に応じて、動作要求を出力する状況であるか否かを判断する判断手段と
を備えることを特徴とする制御装置。
【請求項２】
機能毎に、前記判定手段へ与える入力信号及び判定条件、並びに、前記判定手段へ入力信号及び判定条件を与えた場合の判定結果に応じて次に与えるべき入力信号及び判定条件を示す分岐条件情報を記憶する手段を備え、
前記判断手段は、前記分岐条件情報に基づき、各判定結果に応じて次の入力信号及び判定条件を選択して与えるようにしてあること
を特徴とする請求項１に記載の制御装置。
【請求項３】
入力信号毎に判定条件を示すテーブルを備え、
前記分岐条件情報は、次に与えるべき入力信号の判定条件の参照箇所を示すアドレスを含むこと
を特徴とする請求項２に記載の制御装置。
【請求項４】
前記判断手段は、前記分岐条件情報に基づいて入力信号及び判定条件を前記判定手段へ順次与えた場合の最後の判定結果が成立である場合、動作要求を出力する状況であると判断するようにしてあること
を特徴とする請求項２又は３に記載の制御装置。
【請求項５】
各機能に対応する入力信号、及び該入力信号への判定条件を示すテーブルを機能毎に備え、
前記抽出手段は、前記テーブルに基づいて入力信号を抽出するようにしてあること
を特徴とする請求項１に記載の制御装置。
【請求項６】
複数の制御対象の状態情報又は複数のセンサからの検知情報を示す信号の入力を受け付けるマイクロコンピュータを用い、該マイクロコンピュータに複数のアプリケーションプログラムに基づく処理を行なわせると共に、前記マイクロコンピュータは、前記複数のアプリケーションプログラムと異なるコンピュータプログラムに基づき、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定する判定手段として機能し、入力信号から判断される状況に応じて、前記複数の制御対象の内のいずれかへ動作要求を出力させて前記制御対象の動作を制御する方法であって、
前記マイクロコンピュータは、
前記アプリケーションプログラムに基づく処理により、
機能毎に、該機能に関する入力信号を１又は複数抽出し、
抽出した１又は複数の入力信号、及び該入力信号に対応する判定条件を前記判定手段へ順次与え、
前記判定手段からの各判定結果に応じて、動作要求を出力する状況であるか否かを判断し、
出力する状況であると判断した場合に動作要求を出力させる
ことを特徴とする制御方法。
【請求項７】
複数の制御対象又は複数のセンサが接続され、前記制御対象の状態情報又は前記センサからの検知情報を示す信号の入力を受け付けるコンピュータに、複数のアプリケーションプログラムに基づき、入力信号から判断される状況に応じて複数の制御対象の内のいずれかへ動作要求を出力させて前記制御対象を動作させる処理を実行させる際に、入力信号及び該入力信号に対する判定条件が与えられた場合に、条件の成否を判定させる判定手段として機能させるコンピュータプログラムであって、
コンピュータを、
アプリケーションプログラムの機能毎に抽出された１又は複数の入力情報、及び該入力情報に対応する判定条件、前記判定手段へ与える手段、及び、
１又は複数の入力情報を与えて前記判定手段により得られた各判定結果により、動作要求を出力する状況であるか否かを判断する手段
として機能させることを特徴とするコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１０−２２４９６１（Ｐ２０１０−２２４９６１Ａ）
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願番号】特願２００９−７２６２３（Ｐ２００９−７２６２３）
【出願日】平成２１年３月２４日（２００９．３．２４）
【出願人】（３９５０１１６６５）株式会社オートネットワーク技術研究所 (2,668)
【出願人】（０００１８３４０６）住友電装株式会社 (6,135)
【出願人】（０００００２１３０）住友電気工業株式会社 (12,747)
【Ｆターム（参考）】
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願日】平成２１年３月２４日（２００９．３．２４）
【出願人】（３９５０１１６６５）株式会社オートネットワーク技術研究所 (2,668)
【出願人】（０００１８３４０６）住友電装株式会社 (6,135)
【出願人】（０００００２１３０）住友電気工業株式会社 (12,747)
【Ｆターム（参考）】
[ Back to top ]