JP2006150999A - 自動車用制御装置 - Google Patents

Abstract

【課題】 複数の機能の制御を担うハードウェア制御主体（ＥＣＵ）が、リセット後再起動されるときに、その再起動処理に伴う特定の重要機能の動作停止時間を短縮することができ、ひいては機能停止に伴うユーザーへの違和感や不快感を低減できる自動車用制御装置を提供する。
【解決手段】 複数のアプリケーションを、制御装置の起動時に優先的に機能すべき制御手段に対応した第一種アプリケーションと、その余の制御手段に対応した第二種アプリケーションとに区分する。そして、その起動に際しては、優先度の高い第一種アプリケーションのみについてリソース設定を行ない、優先度の低い第二種アプリケーションのリソース設定は、第一種アプリケーションの起動後に行なう。
【選択図】 図５

Description

この発明は自動車用制御装置に関する。

特開昭６１−８１２３５号公報 特開平７−４２６０９号公報

近年、自動車に搭載されるＥＣＵは処理容量（パラレル処理ビット数及びクロック周波数）に大きいものが使用されるようになってきており、１つのＥＣＵが、被制御要素の異なる複数のアプリケーションを並列に実行する状況が生じている（例えば特許文献１，２）。

上記のような複数のアプリケーションを取り扱うＥＣＵは、その起動時において、全てのアプリケーションが使用するハードウェアのリソース（例えば、入出力のポート、割り込みの番号など）の設定、ＲＡＭ／ＲＯＭのチェック、ＲＡＭの初期化といった一連の起動準備処理を行なった後、全てのアプリケーションを一括して立ち上げるようにしていた。

しかし、自動車の運転中には、電力消費量の大きい高負荷状態の発生や、ノイズの重畳、さらには断線などの要因により、ＥＣＵのリセットがかかる場合がある。リセットされたＥＣＵは、たとえ運転中であっても起動処理は同様に実行するため、リセットにより実行停止したアプリケーションが再度立ち上がるまでには一定の時間を要する。特に、複数のアプリケーションの実行を担うＥＣＵの場合、全てのアプリケーション（つまり、機能）についての起動処理を一括して行なった後、個々のアプリケーションの立ち上げに移行していたのでは、個々のアプリケーションが制御を担う機能の停止時間も長くなる。この場合、個々のアプリケーションが担う機能には、動作頻度や継続期間あるいは重要度の上で差が存在するにも拘わらず、従来は、リセットがかかったときの再起動シーケンスに関しては何ら考慮が払われていなかったため、特定の重要な機能の再起動に伴う動作停止が、ユーザーに思わぬ違和感や不快感を与えることもありえる。

例えば、ヘッドライトやテールライトなどのメインライトの点灯制御を司るアプリケーションは、例えばパワーウィンドウ、ドア開閉及びワイヤレスドアロック機構等の制御用アプリケーションとともに、ボデー系のＥＣＵが一括して実行するケースが多い。この場合、そのボデー系ＥＣＵがリセットされた場合、その再起動までのインターバルが視認限界時間を超えて長くなると、夜間走行中に点灯していたヘッドランプやテールランプが、ごく短時間ではあるが消灯してしまう不具合につながる。

本発明の課題は、複数の機能の制御を担うハードウェア制御主体（ＥＣＵ）が、リセット後再起動されるときに、その再起動処理に伴う特定の重要機能の動作停止時間を短縮することができ、ひいては機能停止に伴うユーザーへの違和感や不快感を低減できる自動車用制御装置を提供することにある。

課題を解決するための手段及び発明の効果

上記の課題を解決するために、本発明の自動車用制御装置の第一の構成は、
自動車上の複数の被制御要素の電気的動作を制御するために被制御要素に対応して設けられた複数の制御手段を、同一のハードウェア制御主体上でそれぞれ実行される、各制御手段に対応した複数のアプリケーションにより機能実現する自動車用制御装置であって、
ハードウェア制御主体は、ＣＰＵと、アプリケーションを格納するＲＯＭと、ＣＰＵ上にてアプリケーションを実行するためのワークエリアとなるＲＡＭとを有し、ＲＡＭ上には、ハードウェア制御主体の各アプリケーションに割り当てられるリソースの設定領域がアプリケーション毎に個別に設けられ、
複数のアプリケーションは、制御装置の起動時に優先的に機能すべき制御手段に対応した第一種アプリケーションと、その余の制御手段に対応した第二種アプリケーションとに区分され、さらに、
第一種アプリケーションのリソースを、第二種アプリケーションのリソースに先んじてＲＡＭ上の対応する設定領域に設定する第一種アプリケーションリソース設定手段と、
第一種アプリケーションのリソースを設定後に、該第一種アプリケーションを第二種アプリケーションに先んじて起動する第一種アプリケーション起動手段と、
第一種アプリケーションの起動後に、第二種アプリケーションのリソースを、ＲＡＭ上の対応する設定領域に設定する第二種アプリケーションリソース設定手段と、
第二種アプリケーションリソースの設定後に第二種アプリケーションを起動する第二種アプリケーション起動手段と、を有したアプリケーション起動マネージャを搭載してなることを特徴とする。

上記本発明の第一の構成によると、複数のアプリケーションは、制御装置の起動時に優先的に機能すべき制御手段に対応した第一種アプリケーションと、その余の制御手段に対応した第二種アプリケーションとに区分され、その起動に際しては、優先度の高い第一種アプリケーションのみについてリソース設定を行ない、優先度の低い第二種アプリケーションのリソース設定をいわば後回しにすることで、例えばリセット／再起動後に第一種アプリケーションが立ち上がるまでの時間、ひいては第一種アプリケーションが担う優先機能の、再起動準備処理に伴う動作中断時間を大幅に短縮することができる。

上記アプリケーション起動マネージャは、ＲＡＭ及びＲＯＭの少なくともいずれかに対し、第一種アプリケーションに割り当てられている第一種メモリ領域と、第二種アプリケーションに割り当てられている第二種メモリ領域との一方又は双方のチェック処理を、第一種アプリケーションの起動後に行なうメモリチェック手段を有するものとして構成することができる。この構成によると、通常はアプリケーションの立ち上げに先立って行なうＲＡＭあるいはＲＯＭのチェックの少なくとも一部を、第一種アプリケーションの起動後に行なうようにしたので、例えばリセット／再起動後に第一種アプリケーションが立ち上がるまでの時間、ひいては第一種アプリケーションが担う優先機能の、再起動準備処理に伴う動作中断時間をさらに短縮することができる。

具体的には、上記メモリチェック手段は、ＲＡＭ及びＲＯＭの第一種メモリ領域のチェック処理のみ第一種アプリケーションの起動前に行ない、ＲＡＭ及びＲＯＭの第二種メモリ領域のチェック処理のみ第一種アプリケーションの起動後に行なうように構成することができる。これにより、優先的に起動させるべき第一種アプリケーションについては、ＲＡＭ及びＲＯＭの対応メモリ領域である第一種メモリ領域のチェックを行なうことができるので、第一種アプリケーションの再起動をより確実に行なうことができるとともに、第一種アプリケーションが使用しない第二種メモリ領域のチェック処理は後回しにされるので、第一種アプリケーションの再起動までの時間短縮も両立することができる。

次に、ハードウェア制御主体はボデー系ＥＣＵを構成するものとすることができ、第一種アプリケーションは自動車のヘッドライトを含むメインライト（被制御要素）の点灯制御を司るものとすることができる。このような構成に上記本発明の第一を適用することで、夜間走行中あるいはトンネル内走行中等において、第一種アプリケーションの再起動に伴い、ヘッドライトを含むメインライトが消灯してしまう不具合の発生時間を大幅に短縮することができる。

特に、メインライトの点灯制御処理として、車外光量を検出する照度センサからの照度情報を取得するとともに、該照度情報が示す車外光量が規定値より小さい場合にメインライトを自動点灯させ、該車外光量が規定値より大きい場合にメインライトを自動消灯させる処理を行なう場合は、手動によるライトの点灯／消灯処理と比較してはるかに複雑であり、第一種アプリケーションによるプログラム制御が必須である。従って、第一種アプリケーションが立ち上がらなければ、メインライトは本質的に点灯することができないし、再起動処理に時間がかかれば、不測の消灯状態もより目立ちやすくなる。また、この場合のリソースの設定項目も、ソース照度センサの入力ポートが追加されることに加え、センサ検出値の取得及びそれを照度値に加工するためのソフトウェア処理の割り込みなど、増加傾向となるのは必至である。従って、第二種アプリケーションのリソース設定並びに再起動を後回しにすることによる、第一種アプリケーションの優先立ち上げ効果がより顕著となる。

なお、ボデー系ＥＣＵが扱う第二種アプリケーションとしては、パワーウィンドウ、ドア開閉及びワイヤレスドアロック機構の少なくともいずれかの制御を司るものとすることができる。これらの制御対象機能は、走行中におけるごく短時間の機能停止であればユーザーはまず違和感を感ずることがないので、メインライトの点灯／消灯制御を司る第二種プリケーションの起動後にリソース設定及び起動を行なっても、実害はほとんどないといえる。

次に、本発明の自動車用制御装置の第二の構成は、自動車上の複数の被制御要素の電気的動作を制御するために被制御要素に対応して設けられた複数の制御手段を、同一のハードウェア制御主体上でそれぞれ実行される、各制御手段に対応した複数のアプリケーションにより機能実現する自動車用制御装置であって、
ハードウェア制御主体は、ＣＰＵと、アプリケーションを格納するＲＯＭと、ＣＰＵ上にてアプリケーションを実行するためのワークエリアとなるＲＡＭとを有し、
複数のアプリケーションに割り当てられたＲＡＭ及びＲＯＭのメモリ領域の全部又は一部のチェック処理を、複数のアプリケーションの１つ又は複数を起動した後で行なうメモリチェック手段を有することを特徴とする。

上記本発明の第二の構成によると、通常はアプリケーションの立ち上げに先立って行なうＲＡＭあるいはＲＯＭのチェックの少なくとも一部を、上記複数のアプリケーションの１つ又は複数を起動した後で行なうようにしたので、例えばリセット／再起動後にアプリケーションが立ち上がるまでの時間、ひいてアプリケーションの再起動準備処理に伴う動作中断時間をさらに短縮することができる。

以下、本発明の実施の形態を、図面を参照して説明する。
図１は、本発明の自動車用制御装置を構成するＥＣＵの電気的な構成図である。ＥＣＵ１は、ＣＰＵ３、ＲＯＭ５、ＲＡＭ４及び入出力部（Ｉ／Ｏポート）２がバス接続されたマイクロプロセッサからなる。ＥＣＵ１は、本実施形態では自動車のボデー系の制御を司るボデー系ＥＣＵとして構成され、図２はその概略アーキテクチャを示すものである。マイクロプロセッサからなるハードウェア制御主体上に搭載されるソフトウェアは、プラットフォームと、そのプラットフォーム上で動作する、ボデー系機能を実現するためのアプリケーションである。なお、複数のアプリケーションを区別するために、１〜ｎの記号を付して示した。プラットフォームは、ベースとなるハードウェアが相違する場合にも、各アプリケーションに共通の動作環境を与えるためのものであり、該アプリケーションに対する基本ソフト（ＯＳ）のほか、アプリケーションやハードウェアとの連携を図るインターフェースプログラムなどを含んで構成されるが、概念的には周知の部分なので説明の詳細は省略する。

アプリケーションは、車両利用者による車両各部の操作に係る機能であるボデー系機能を実現するものである。このボデー系機能とは、具体的には、ドア開閉に伴う制御、窓開閉に伴う制御、ライトの点灯制御、キーレスエントリ方式等に採用されるワイヤレスドアロック機構の制御、・・・といったものをいう。具体的には、以下のようなものを例示できる：
・運転席ドア、助手席ドア、後部右側座席ドア、後部左側座席ドア、ルーフなどのロック／ロック解除、パワーウィンドウ動作など。
・エアコン、カーオーディオ、カーナビゲーションシステムなどの電源動作など。
・ルームランプ、コックピットランプ、ヘッドライト、スモールランプ、ハザードランプ、テールライトなどの点灯制御など。特に、ヘッドライト及びテールライトは、夜間あるいはトンネル走行時に点灯が義務付けられるメインライトを構成する。

図１に戻り、各アプリケーション１、２、‥はＲＯＭ５に記憶されており、ＲＡＭ４の各アプリケーションに対応したワークエリア上でＣＰＵ３により実行される。アプリケーション１、２‥のバージョンアップや追加／削除などを前提としない場合は、ＲＯＭ５は書き換え不能なマスクＲＯＭで構成することができる。他方、バージョンアップや追加／削除などを前提とする場合は、電気的な書き換えが可能なＲＯＭ、例えばＥＥＰＲＯＭ５やフラッシュＲＯＭで構成しておく（もちろん、マスクＲＯＭと電気的な書き換えが可能なＲＯＭとを併用することも可能である）。この種の書き換え可能なＲＯＭは、読み出し時の駆動電圧と書き込み消去時の駆動電圧が異なる値に設定され、ＲＡＭと異なって、読み出し時と同じ制御電圧では書き込み消去が不能となっている。

本実施形態では、ボデー系ＥＣＵ１が実行を司るアプリケーションとして、次の４つを例示しており、各々そのワークエリア４１、４２、４３及び４４がＲＡＭ４内に確保され、所定のリソースが割り当てられる。
（１）ライト系アプリケーション（ワークエリア４１）：ヘッドライトの点灯ユニット７１及びそれと連動点灯されるテールランプの点灯ユニット７２（つまり、メインライト）の動作制御アプリケーションであり、以下のリソースがワークエリア４１内のリソース設定領域４１Ｒに設定される。
（入力系：ライトスイッチ／センサ用リソース領域）
・イグニッションスイッチＳＷ１の入力ポート（共有リソース）；イグニッションスイッチＳＷ１がＯＦＦの場合は、手動スイッチ操作によるメインライトの点灯／消灯のみ可能；
・ライトコントロールスイッチＳＷ２（ロービーム、ハイビーム、ハイフラッシュ点灯などの点灯モード切替、及びマニュアル点灯／消灯、及び自動点灯／消灯の切替え）からの操作信号の入力ポート；
・ライトセンサ（照度センサ）６１からの照度検出情報の入力ポート；
（出力系：ライト出力制御用リソース領域）
・ヘッドライト点灯ユニット７１に対する、ロービーム点灯、ハイビーム点灯、ハイフラッシュ点灯及び消灯の切替え制御出力ポート；
・テールライト点灯ユニット７２に対する点灯及び消灯の切替え制御出力ポート。

上記ライト系アプリケーションは、リセット／再起動時に優先起動される第一種アプリケーションとして定められ、ＲＯＭ５の対応する格納領域５１、及びＲＡＭ４の対応するワークエリア４１が、第一種メモリ領域４Ｐ，５Ｐとして定められている。

（２）パワーウィンドウ制御アプリケーション（ワークエリア４２）：パワーウィンドウの動作制御アプリケーションであり、以下のリソースがワークエリア４２内のリソース設定領域４２Ｒに設定される。
（入力系：パワーウィンドウスイッチ用リソース領域）
・イグニッションスイッチＳＷ１の入力ポート（共有リソース）；イグニッションスイッチＳＷ１がＯＦＦの場合は、パワーウィンドウの動作禁止；
・パワーウィンドウスイッチユニット６２（ウィンドウ上昇／下降切替え、昇降モードの断続／オート切替えなど））からの操作信号の入力ポート；
（出力系：パワーウィンドウ出力制御用リソース領域）
・パワーウィンドウ駆動ユニット７３に対する、ウィンドウ上昇／下降、及び昇降モードの断続／オート切替えなどの駆動モード切替えの制御出力ポート。

（３）ドア開閉アプリケーション（ワークエリア４３）：ドア開閉ユニットの動作制御アプリケーションであり、以下のリソースがワークエリア４３内のリソース設定領域４３Ｒに設定される。電動式ドアが搭載される場合に必要となるアプリケーションである。
（入力系：ドア操作スイッチ用リソース領域）
・ドア操作スイッチユニット６３からの操作信号の入力ポート；
（出力系：ドア開閉機構用リソース領域）
・ドア開閉ユニット７４に対するドア開閉の制御出力ポート。

（４）ワイヤレスドアロック制御アプリケーション（ワークエリア４４）：ユーザーが所持する無線キーあるいは携帯器１６４により、無線遠隔操作でドアを施錠／開錠するワイヤレスドアロック機構の動作制御アプリケーションであり、以下のリソースがワークエリア４４内のリソース設定領域４４Ｒに設定される。電動式ドアが搭載される場合に必要となるアプリケーションである。
（入力系：無線受信機用リソース領域）
・無線受信機用コントロールユニット６４（携帯器１６４と無線通信し、ロック開閉のための制御信号（ロック開閉要求信号）を出力する）からのロック開閉要求信号の入力ポート；
（出力系：ドアロック機構用リソース領域）
・ドアロック機構７５に対する施錠／開錠の制御出力ポート；

上記ライト系アプリケーション以外の３つのアプリケーションは、リセット／再起動時に、第一種アプリケーションに対してその起動が後回しにされる第二種アプリケーションとして定められ、ＲＯＭ５の対応する格納領域５２〜５４、及びＲＡＭ４の対応するワークエリア４２〜４４が、第二種メモリ領域４Ｓ，５Ｓとして定められている。

ＥＣＵ１は、上記のごとく外部からのスイッチやセンサからの入力信号等を参照しつつ、各アプリケーションの実行により、前述した各種ボデー系の制御対象機器（被制御要素）の動作制御を司る。また、ＥＣＵ１は、全てのアプリケーションが動作終了し、次の動作開始のための待機状態になっている場合に、低消費電力モードであるスリープモード（ＥＣＵを構成する発振器を停止したスタンバイモードや、通常動作と異なる低周波数の発振器で動作するスロークロックモード、あるいは一定時間ごとにＣＰＵを間欠的に動作させる間欠モードなど）へ移行する。その制御は図２のプラットフォーム部分が担うこととなる（図１のＲＯＭ５に搭載されているが、記載は省略している）。

そして、図３に示すように、上記の複数のアプリケーション１，２‥ｎは、プラットフォームの一部をなすソフトウェアとして形成されたアプリケーション起動マネージャにより起動処理され、以降はプラットフォーム上で実現されるスケジューラによって周期的に実行される。具体的には各アプリケーションは、要求するスリープ期間をタイマー設定し、スリープとウェイクアップとを定期的に繰り返すようにプログラミングされている。例えば、ワイヤレスドアロック機構の制御に関しては、携帯器１６４からの無線信号が受信入力され、ドアロック制御アプリケーションは、その受信スタンバイ期間を通常モード期間として、スリープ期間と交互に繰り返すようにＥＣＵ１の作動制御を行なうこととなる。他方、上記のアプリケーションは、上記のスリープサイクルとは無関係に、外部の操作信号（ライト点灯、ドアロック解除指令など）をトリガーとした割り込み処理指令を受けた場合も、これをウェイクアップ要因として随時ウェイクアップするようになっている。そして、その後一定期間ウェイクアップ要因がなければ要求スリープ期間が再設定され、スリープに移行する。

アプリケーション起動マネージャは、図４に比較例として示すように、従来は、ＣＰＵ周辺レジスタの内容設定等を含む一般的な初期設定処理（Ｓ１）を行なった後、全てのアプリケーションについてのリソース設定を行ない（Ｓ２）、さらにＲＯＭ５及びＲＡＭ４の全アプリケーションの割当領域を、チェックサム演算や定型確認用データを用いたリード／ライト確認処理当等の周知のチェックアルゴリズムに従いチェック処理する（Ｓ３，Ｓ４）。このＳ１〜Ｓ４までのステップが、複数のアプリケーションの起動準備処理に該当し、これが終了した後、全てのアプリケーションをまとめて起動（立ち上げ）処理する（Ｓ６）。しかし、この方式では、自動車の走行中にＥＣＵ１に何らかの要因でリセットがかかり、起動準備処理から再起動しなければならなくなったときに、リセット発生時に動作継続していた優先度の高いアプリケーションが動作復帰するまでに相当の時間を要することになる。

そこで、本発明においてアプリケーション起動マネージャは、図４において、実施例１に示すような流れの起動処理を行なうようにしている。すなわち、複数のアプリケーションを上記のごとく、再起動時に優先的に機能すべき制御手段に対応した第一種アプリケーション（図面中では「使用機能」と表示）と、その余の制御手段に対応した第二種アプリケーション（図面中では「残り全て」と表示）とに区分する。そして、Ｓ１の初期設定が終了した後、第一種アプリケーションのリソースを、第二種アプリケーションのリソースに先んじてＲＡＭ４上の対応する設定領域４１Ｒに設定する（第一種アプリケーションリソース設定手段：Ｓ２Ｐ）。次に、第一種アプリケーションのリソースを設定後に、該第一種アプリケーションを第二種アプリケーションに先んじて起動する（第一種アプリケーション起動手段：Ｓ６Ｐ）。第一種アプリケーションが起動した後は、第二種アプリケーションのリソースを、ＲＡＭ４上の対応する設定領域４２Ｒ，４３Ｒ，４４Ｒに設定する（第二種アプリケーションリソース設定手段：Ｓ２Ｓ）。そして、第二種アプリケーションリソースの設定後に第二種アプリケーションを起動する（第二種アプリケーション起動手段：Ｓ６Ｓ）。

上記処理によると、リセット後の再起動時においては、第一種アプリケーションについてまずリソース設定が行なわれ、優先度の低い第二種アプリケーションのリソース設定及び起動を後回しにして、優先度の高い第一種アプリケーションが先に起動処理される。つまり、リセットがかかってから第一種アプリケーションが立ち上がるまでに実行される起動準備処理が、第一種アプリケーションに関与するものについて選択的になされるので、該第一種アプリケーションが担う優先機能の、起動準備処理に伴う動作中断時間を大幅に短縮することができる。

実施例１のアプリケーション起動マネージャは、図４に示すごとく、ＲＡＭ４及びＲＯＭ５の、第一種アプリケーションに割り当てられている第一種メモリ領域４Ｐ，５Ｐ（図１）のチェック処理（Ｓ３Ｐ，Ｓ４Ｐ）を、第一種アプリケーションの起動前に行ない、同じくＲＡＭ４及びＲＯＭ５の、第二種アプリケーションに割り当てられている第二種メモリ領域４Ｓ，５Ｓ（図１）のチェック処理（Ｓ３Ｓ，Ｓ４Ｓ）を、第一種アプリケーションの起動後に行なうようにしている。また、ＲＡＭ４のワークエリアの初期化についても、ＲＡＭ４の全領域を一括して初期化するのではなく、第一種アプリケーションの起動に先立っては、まず第一種アプリケーションが使用するメモリ領域（ただし、リソース設定領域を除く）のみを初期化し（Ｓ５Ｐ）、残余の第二種アプリケーションが使用するメモリ領域の初期化は、第一種アプリケーションの起動後であって、第二種アプリケーションの起動前に行なうようにしている（Ｓ５Ｓ）。

図５は、実施例１と比較例とのアプリケーション起動マネージャの処理シーケンスをタイミング図的に示したものである。実施例１では、起動準備処理を構成するリソース設定、ＲＯＭチェック、ＲＡＭチェック及びＲＡＭ初期化の全てにおいて、第一種アプリケーションに関与する部分だけが選択的に実行される結果、リセット後、第一種アプリケーションが起動されるまでの時間が、比較例１よりも大幅に短縮されていることがわかる。また、図６は、図４の実施例２のフローチャートを、図１のボデー系ＥＣＵ１の動作に即して、より具体化して記述したものである。第一種アプリケーションはメインライトの自動点灯制御を司るものであり、車外光量を検出するライトセンサ６１（照度センサ：図１）からの照度情報を取得するとともに（Ｓ５１）、該照度情報が示す車外光量が規定値より小さい場合にメインライトを自動点灯させ（Ｓ５３）、該車外光量が規定値より大きい場合にメインライトを自動消灯させる（Ｓ５５）。夜間あるいはトンネル通過時には、自動車はメインライトの点灯を継続させながら走行する。しかし、走行中にＥＣＵ１にリセットがかかると、第一種アプリケーションの処理は打ち切られ、アプリケーション起動マネージャが起動準備処理をやり直すことになる。この起動準備処理期間中は第一種アプリケーションが作動しないから、メインライトは一時的にではあるが消灯することになる。しかし、図５に示すごとく、起動準備処理期間が短縮されれば、走行中にメインライトが消灯する不具合を最小限に押さえることができる。

以下、アプリケーション起動マネージャの処理形態に関する種々の別実施例について説明する。図４の実施例２は、第一種アプリケーション及び第二種アプリケーションの区別無く、全てのアプリケーションについて、リソース設定及びＲＡＭの初期化を行なった後（Ｓ２，Ｓ５）、全アプリケーションの起動を一括して行なう（Ｓ６）。この点は、比較例と何ら変わりはないが、全アプリケーション分のＲＡＭ４／ＲＯＭ５のチェックを、該全アプリケーションの起動後に行なっている。図５にタイミング図にて示すように、ＲＡＭ４／ＲＯＭ５のチェック処理が後回しになった分、アプリケーションの再起動までの時間が短縮され、例えば走行中にメインライトが消灯する不具合も抑制できることが明らかである。

図７の実施例３は、図４の実施例１において、第一種アプリケーションの起動（Ｓ６Ｐ）に先立って行なわれていた第一種メモリ領域（４Ｐ，５Ｐ：図１）のチェック処理（Ｓ３Ｐ，Ｓ４Ｐ）を、第一種アプリケーションの起動後に、第二種メモリ領域（４Ｓ，５Ｓ：図１）のチェック処理と統合して行なうようにした例である。この方法は、優先起動される第一種アプリケーションのメモリ領域の異常検出が後手に回るリスクは存在するが、全メモリ領域のチェック処理が第一種アプリケーションの起動後にシフトするので、第一種アプリケーションの再起動に至るまでの時間短縮効果は最も大きい。

他方、図８の実施例４は、図４の実施例１において、第一種アプリケーションの起動（Ｓ６Ｐ）に先立って行なわれていた第一種メモリ領域（４Ｐ，５Ｐ：図１）のチェック処理（Ｓ３Ｐ，Ｓ４Ｐ）を、第一種アプリケーションの起動前に、第二種メモリ領域（４Ｓ，５Ｓ：図１）のチェック処理と統合して行なうようにした例である。この方式は、第一種アプリケーションの再起動に至るまでの時間短縮効果に関しては、実施例１や実施例３には劣るものの、リソース設定処理は実施例１と同様に第一種アプリケーションの前後に分割されるので、図４の比較例に対して優位であることは明らかである。また、全アプリケーションの起動前に全てのメモリ領域のチェックが完了するので信頼性が高い。

なお、本明細書は、自動車用制御装置に係る第一発明と第二発明とを開示するものであるが、上記４つの実施例と第一発明及び第二発明の関係は以下の通りである。
・実施例１：第一発明と第二発明とが複合した実施例に相当する。第二発明の観点から見た場合、ＲＡＭ及びＲＯＭの一部の領域についてのみ、全アプリケーションの起動後にチェックを行なう態様に相当する。
・実施例２：第二発明単独の実施例であり、第一発明の要件は含まない。
・実施例３：第一発明と第二発明とが複合した実施例に相当する。第二発明の観点から見た場合、ＲＡＭ及びＲＯＭの全て領域を、一部のアプリケーション（第一発明でいうところの第一種アプリケーション）の起動後にチェックする態様に相当する。
・実施例４：第一発明単独の実施例であり、第二発明の要件は含まない。

また、上記の実施形態では、ＲＡＭ及びＲＯＭのチェックは常に対にして行なっていたが、ＲＡＭのチェックとＲＯＭのチェックとを、特定のアプリケーションの起動処理の前後に振り分けることも可能である。例えば、第一種アプリケーションの起動に先立っては、第一種アプリケーションの実行に使用するＲＡＭ４のメモリ領域についてチェックを行ない、他方、ＲＯＭ５のチェックを第一種アプリケーションの起動後に行なうことが可能である。

本発明の自動車用制御装置として機能するＥＣＵの一例を示すブロック図。 図１のＥＣＵのアーキテクチャを示す模式図。 スケジューラによる複数アプリケーションの実行サイクルの概念を模式的に示す図。 アプリケーション起動マネージャの処理の流れを、本発明の実施例１及び実施例２と比較例とで対比して示すフローチャート。 図４に対応する模式的なタイミング図。 実施例１におけるアプリケーション起動マネージャの処理の流れを、より具体化して示すフローチャート。 実施例３に係るアプリケーション起動マネージャの処理の流れを示すフローチャート。 実施例４に係るアプリケーション起動マネージャの処理の流れを示すフローチャート。

符号の説明

１ ＥＣＵ（ハードウェア制御主体：自動車用制御装置）
３ ＣＰＵ
４ ＲＡＭ
５ ＲＯＭ
４Ｐ，５Ｐ 第一種メモリ領域
４Ｓ，５Ｓ 第二種メモリ領域

Claims (7)

1. 自動車上の複数の被制御要素の電気的動作を制御するために前記被制御要素に対応して設けられた複数の制御手段を、同一のハードウェア制御主体上でそれぞれ実行される、各制御手段に対応した複数のアプリケーションにより機能実現する自動車用制御装置であって、
   前記ハードウェア制御主体は、ＣＰＵと、前記アプリケーションを格納するＲＯＭと、前記ＣＰＵ上にて前記複数のアプリケーションを実行するためのワークエリアとなるＲＡＭとを有し、前記ＲＡＭ上には、前記ハードウェア制御主体の各アプリケーションに割り当てられるリソースの設定領域がアプリケーション毎に個別に設けられ、
   前記複数のアプリケーションは、前記制御装置の起動時に優先的に機能すべき制御手段に対応した第一種アプリケーションと、その余の制御手段に対応した第二種アプリケーションとに区分され、さらに、
   前記第一種アプリケーションのリソースを、前記第二種アプリケーションのリソースに先んじて前記ＲＡＭ上の対応する設定領域に設定する第一種アプリケーションリソース設定手段と、
   前記第一種アプリケーションのリソースを設定後に、該第一種アプリケーションを前記第二種アプリケーションに先んじて起動する第一種アプリケーション起動手段と、
   前記第一種アプリケーションの起動後に、前記第二種アプリケーションのリソースを、前記ＲＡＭ上の対応する設定領域に設定する第二種アプリケーションリソース設定手段と、
   前記第二種アプリケーションリソースの設定後に前記第二種アプリケーションを起動する第二種アプリケーション起動手段と、を有したアプリケーション起動マネージャを搭載してなることを特徴とする自動車用制御装置。
2. 前記アプリケーション起動マネージャは、
   前記ＲＡＭ及び前記ＲＯＭの少なくともいずれかに対し、前記第一種アプリケーションに割り当てられている第一種メモリ領域と、前記第二種アプリケーションに割り当てられている第二種メモリ領域との一方又は双方のチェック処理を、前記第一種アプリケーションの起動後に行なうメモリチェック手段を有する請求項１記載の自動車用制御装置。
3. 前記メモリチェック手段は、前記ＲＡＭ及び前記ＲＯＭの前記第一種メモリ領域のチェック処理のみ前記第一種アプリケーションの起動前に行ない、前記ＲＡＭ及び前記ＲＯＭの前記第二種メモリ領域のチェック処理のみ前記第一種アプリケーションの起動後に行なう請求項２記載の自動車用制御装置。
4. 前記ハードウェア制御主体はボデー系ＥＣＵを構成するものであり、前記第一種アプリケーションは自動車のヘッドライトを含むメインライトの点灯制御を司るものである請求項１ないし請求項３のいずれか１項に記載の自動車用制御装置。
5. 前記第一種アプリケーションは、前記メインライトの点灯制御処理として、車外光量を検出する照度センサからの照度情報を取得するとともに、該照度情報が示す車外光量が規定値より小さい場合に前記メインライトを自動点灯させ、該車外光量が規定値より大きい場合に前記メインライトを自動消灯させる処理を行なうものである請求項４記載の自動車用制御装置。
6. 前記第二種アプリケーションは、パワーウィンドウ、ドア開閉及びワイヤレスドアロック機構の少なくともいずれかの制御を司るものである請求項４又は請求項５に記載の自動車用制御装置。
7. 自動車上の複数の被制御要素の電気的動作を制御するために前記被制御要素に対応して設けられた複数の制御手段を、同一のハードウェア制御主体上でそれぞれ実行される、各制御手段に対応した複数のアプリケーションにより機能実現する自動車用制御装置であって、
   前記ハードウェア制御主体は、ＣＰＵと、前記アプリケーションを格納するＲＯＭと、前記ＣＰＵ上にて前記アプリケーションを実行するためのワークエリアとなるＲＡＭとを有し、
   前記複数のアプリケーションに割り当てられた前記ＲＡＭ及び前記ＲＯＭのメモリ領域の全部又は一部のチェック処理を、前記複数のアプリケーションの１つ又は複数を起動した後で行なうメモリチェック手段を有することを特徴とする自動車用制御装置。

Images