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

Description

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

特開２００２−４１１４１号公報 特開２００３−３１８９２４号公報

自動車には、各種機器（被制御要素）を制御するために、マイクロプロセッサ（ハードウェア制御主体）からなるＥＣＵが搭載されている。ＥＣＵは、ある条件で、例えば、車両が駐車状態にある場合、又はあるスイッチ操作がない場合にスリープモードに移行するようにしている（例えば、特許文献１、特許文献２）。具体的にはスリープモードとは、ＥＣＵを構成する発振器を停止したスタンバイモードや、通常動作と異なる低周波数の発振器で動作するスロークロックモード、あるいは一定時間ごとにＣＰＵを間欠的に動作させる間欠モードなどであり、低消費電流モードにあることをいう。特に、キーレスエントリ方式のように、携帯器を保有したユーザーが自動車に接近したことを上記携帯器を介して無線検知し、ドアロック解除やエンジン始動などの動作を自動制御したい場合、この制御を司るＥＣＵは、駐車中あるいはエンジン停止中であっても動作を常時継続していなければならない。特に駐車時間が長期に渡る場合、通常動作モードでＥＣＵを作動させつづけるとバッテリー電圧低下を招き、自動車を始動できなくなる問題を生ずるので、ＥＣＵのスリープ制御は、バッテリー保護の観点から近年重要性を増しつつある。

スリープモードからのウェイクアップには、特定のアプリケーションに対する外部からの動作要求に基づき、割り込み処理により不定期にウェイクアップする場合（以下、外部要因ウェイクアップという）と、タイマー制御により定期的にスリープとウェイクアップとを繰り返す場合（以下、タイマーウェイクアップという）との２種類がある。タイマーウェイクアップにおいては、例えばキーレスエントリシステムのように、ユーザーの携帯器からの信号受信スタンバイ期間を、スリープ期間を介して断続的に生じさせ、節電を図る目的に活用されている。

自動車制御装置がスリープ状態からウェイクアップし、アプリケーションを起動するには、各アプリケーションに割り当てられたリソース（例えば、入出力のポート、割り込みの番号など）を適切な状態に設定することが必要である。しかし、このリソースの設定が必要となる状況は、上記の外部要因ウェイクアップ、つまり、被制御要素の具体的な動作制御のため、外部から当該アプリケーションへの動作要求が発生している場合（つまり、アプリケーション要部に対する実行要請が生じている場合）に限られる。他方、タイマーウェイクアップにおいては、アプリケーションは、特に外部からの動作要求が存在しない場合は、起動処理を行なったあとは待機状態となるから、アプリケーション要部は実行されず、仮にリソースの設定を行なっても使われないままタイムアップして、次のスリープに入ってしまうこともありえる。

しかし、従来の自動車制御装置においては、発生したウェイクアップ要因が、上記外部要因ウェイクアップとタイマーウェイクアップとのいずれに該当するのか、さらには、外部要因ウェイクアップであっても、動作要求を受けたのがどのアプリケーションであるか、などについては特に判断せず、全てのアプリケーションのリソース設定を一律に行なってから各アプリケーションを立ち上げるようにしていた。このため、動作要求を特に受けていないアプリケーションについて余分なリソース設定がされるので、動作要求のある肝心のアプリケーションの起動が遅れてしまう問題がある。また、動作要求のないアプリケーションのリソース設定が介在する分だけ、ウェイクアップしてから次にスリープするまでの時間も長くなりがちであり、暗電流が増大する欠点があった。

本発明の課題は、複数の機能の制御を担うハードウェア制御主体（ＥＣＵ）が、スリープ後ウェイクアップするときに、そのウェイクアップ要因に応じてアプリケーションの起動シーケンスの適正化を図ることができる自動車用制御装置を提供することにある。

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

上記の課題を解決するために、本発明の自動車用制御装置の第一の構成は、
自動車上の複数の被制御要素の電気的動作を制御するために被制御要素に対応して設けられた複数の制御手段を、同一のハードウェア制御主体上でそれぞれ実行される、各制御手段に対応した複数のアプリケーションにより機能実現するとともに、制御手段の動作モードが、通常動作モードと、該通常動作モードよりも消費電力量が少ないスリープモードとの間で切り替え可能に構成された自動車用制御装置であって、
ハードウェア制御主体は、ＣＰＵと、アプリケーションを格納するＲＯＭと、ＣＰＵ上にて複数のアプリケーションを実行するためのワークエリアとなるＲＡＭとを有し、ＲＡＭ上には、ハードウェア制御主体の各アプリケーションに割り当てられるリソースの設定領域がアプリケーション毎に個別に設けられ、
ハードウェア制御主体がスリープモードから通常モードに切り替わるウェイクアップの要因が、複数のアプリケーションの少なくとも１つに対する外部からの作動要求に基づいて発生する場合において、複数のアプリケーションのうち、当該作動要求のあったアプリケーションを第一種アプリケーション、残余のアプリケーションを第二種アプリケーションとして定めたとき、前記ウェイクアップに際して第一種アプリケーションのリソースを、第二種アプリケーションのリソースに優先してＲＡＭ上の対応する設定領域に設定するリソース設定手段と、
第一種アプリケーションのリソースを設定後に、第二種アプリケーションのリソースを設定することなく第一種アプリケーションを起動するアプリケーション起動手段と、を有することを特徴とする。

上記構成によると、ハードウェア制御主体のウェイクアップの要因が、複数のアプリケーションの少なくとも１つに対する外部からの作動要求に基づいて発生する場合において、当該アプリケーション（つまり、第一種アプリケーション）のリソースを第二種アプリケーションのリソースに優先して設定し、その後、第二種アプリケーションのリソースを設定することなく第一種アプリケーションを起動するようにしたから、動作要求を特に受けていないアプリケーションのリソース設定が省略される分、動作要求のあるアプリケーションの起動を早めることができる。

アプリケーション起動手段は、第二種アプリケーションに対するリソース設定を行なわない状態で、第一種アプリケーションとともに該第二種アプリケーションも合せて起動するものとすることができる。このようにすると、第一種アプリケーションの起動後に、第二種アプリケーション（が司る機能）についても新たに動作要求が生じた場合に、該第二種アプリケーションが既に立ち上がっていることで、その要部の実行処理に素早く移行することができる。

次に、本発明の自動車用制御装置の第一には、ハードウェア制御主体がウェイクアップした後、複数のアプリケーションに対する外部からの作動要求が途絶してから一定のアイドリング期間が経過した場合に、該ハードウェア制御主体をスリープモードに移行させるスリープ移行手段を設けることができる。この場合、前記のリソース設定手段は、アイドリング期間中に第二種アプリケーションのいずれに対しても外部からの作動要求がなされなかった場合に、該第二種アプリケーションへのリソース設定を行なわず、スリープ移行手段は該第二種アプリケーションへのリソース設定を行なわないままスリープモードへ移行させるものとすることができる。これにより、当該のウェイクアップ→スリープのサイクルにおいて、作動要求のなかったアプリケーションについて無駄なリソース設定を行なわないままスリープモードへ移行できるので、ウェイクアップしてから次にスリープするまでの時間を短縮でき、暗電流軽減を図ることができる。この場合、リソース設定手段は、アイドリング期間中に第二種アプリケーションのいずれかに対して外部からの作動要求がなされた場合に、その作動要求のあった第二種アプリケーションについてのみ追加してリソース設定を行なうように構成すると、第二種アプリケーションについて作動要求が追加発生したときも必要最小限のリソース設定を補うだけでよく、効率的である。

また、本発明の自動車用制御装置の第一においては、ハードウェア制御主体がスリープモードへ移行後、スリープタイマーが計測する予め定められたスリープ期間が経過した場合に、該ハードウェア制御主体をウェイクアップさせるタイマーウェイクアップ制御手段を設けることができる。この場合、前述のアプリケーション起動手段は、ウェイクアップの要因が、タイマーウェイクアップ制御手段によるウェイクアップ要求に基づいて発生する場合において、当該ウェイクアップに際してアプリケーションを、そのリソース設定を行なうことなく起動するものとして構成することができる。

また、本発明の自動車用制御装置の第二は、
自動車上の複数の被制御要素の電気的動作を制御するために被制御要素に対応して設けられた複数の制御手段を、同一のハードウェア制御主体上でそれぞれ実行される、各制御手段に対応した複数のアプリケーションにより機能実現するとともに、制御手段の動作モードが、通常動作モードと、該通常動作モードよりも消費電力量が少ないスリープモードとの間で切り替え可能に構成された自動車用制御装置であって、
ハードウェア制御主体がスリープモードへ移行後、スリープタイマーが計測する予め定められたスリープ期間が経過した場合に、該ハードウェア制御主体をウェイクアップさせるタイマーウェイクアップ制御手段と、
ハードウェア制御主体がスリープモードから通常モードに切り替わるウェイクアップの要因が、タイマーウェイクアップ制御手段によるウェイクアップ要求に基づいて発生する場合において、当該ウェイクアップに際してアプリケーションを、そのリソース設定を行なうことなく起動するアプリケーション起動手段と、を有することを特徴とする。

上記の構成によると、特定アプリケーションに対する外部からの動作要求とは無関係に、スリープタイマーにより定期的に発生するウェイクアップ要因については、これに基づくウェイクアップに際して、複数のアプリケーションを、そのリソース設定を行なうことなく起動するようにしたので、ウェイクアップからアプリケーション起動までの時間を短縮することができる。

この場合、ハードウェア制御主体がウェイクアップした後、複数のアプリケーションに対する外部からの作動要求が途絶してから一定のアイドリング期間が経過した場合には、該ハードウェア制御主体をスリープモードに移行させるとともに、アイドリング期間中に複数のアプリケーションのいずれに対しても外部からの作動要求がなされなかった場合に、該アプリケーションへのリソース設定を行なわないままスリープモードへ移行させるスリープ移行手段を設けることができる。外部からの作動要求がない場合に、リソース設定を全く行なわずに再びスリープモードに復帰するので、スリープタイマーによりウェイクアップしてから次にスリープするまでの時間を大幅に短縮でき、暗電流軽減を図ることができる。

また、アイドリング期間中に複数のアプリケーションのいずれかに対して外部からの作動要求がなされた場合に、その作動要求のあったアプリケーションについてリソース設定を行なうリソース設定手段を設けることもできる。これにより、スリープタイマーによるウェイクアップ後に、特定のアプリケーションについて作動要求が追加発生した場合は、そのアプリケーションについてのみ、必要最小限のリソース設定を補うだけでよいので、効率的である。

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

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

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

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

上記ライト系アプリケーションは、メインライトの自動点灯制御を司るものであり、車外光量を検出するライトセンサ６１（照度センサ：図１）からの照度情報を取得するとともに、該照度情報が示す車外光量が規定値より小さい場合にメインライトを自動点灯させ、該車外光量が規定値より大きい場合にメインライトを自動消灯させる。

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

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

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

各リソース設定領域のメモリ構造は、例えば図１２に示すごとくであり、入出力部２に設けられた各ポートのアドレスと、対応する割当アプリケーションの特定情報、及び割当アプリケーションが要求するそのポートの設定状態とを互いに対応付けて記憶するものである。スリープモードからウェイクアップする場合には、スリープ状態でのポート設定状態から、ウェイクアップ後、アプリケーションの起動に必要な設定状態（これらはアプリケーション毎に固有に定められるものである）に書き換える必要がある。その書き換え処理がウェイクアップに際してリソース設定処理であり、後述のウェイクアップ制御プログラム（図１のスリープ管理制御ソフト５５の一部をなす：図２のプラットフォームに組み入れられている）が担うこととなる。そして、該ウェイクアップ制御プログラムが、本発明の特許請求の範囲に記載した、リソース設定手段、アプリケーション起動手段及びスリープ移行手段の各機能実現手段を、ＣＰＵ３上での実行により実現する。

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

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

ＥＣＵ１は、ネットワークバスを介して他のハードウェア制御主体（例えば他のＥＣＵ）と接続されており、該ネットワークバスを介した通信により、リセット指示又はウェイクアップ要因を判断すると動作を開始する。図１０は、その処理の概略を示すフローチャートであり、リセット指示があった場合はリセット時のシステム設定を行ない（Ｓ１００）、その後、Ｓ１２０へ移行する。一方、ウェイクアップ要因を判断した場合、ウェイクアップ時のシステム設定を行ない（Ｓ１１０）、その後、Ｓ１２０へ移行する。Ｓ１２０では、各アプリケーションによる制御が行われる。ここでは、複数のアプリケーションの状態が判定され、所定条件成立時にスリープ時のシステム設定を行ない（Ｓ１３０）、その後、スリープする。この判定を含めたＥＣＵ１のスリープ状態への移行、及びウェイクアップのための準備制御などを統括的に司るのが、図１のスリープ管理・制御ソフト８１である。スリープ管理・制御ソフト８１は、以下の各機能実現手段をＣＰＵ３上にて実現するものである。
・スリープ制御情報取得手段：複数のアプリケーションソフトウェアが要求するスリープ期間の開始時刻及び終了時刻を直接的又は間接的に特定するためのスリープ制御情報を、それら複数のアプリケーションソフトウェアから要求スリープ制御情報として個別に取得する；
・有効スリープ期間算出手段：取得された各アプリケーションソフトウェアの要求スリープ制御情報が各々規定する複数の要求スリープ期間に、共通に含まれる期間を有効スリープ期間として算出する；
・スリープ移行手段：算出された有効スリープ期間の開始時刻が到来することにより、複数のアプリケーションソフトウェアの実行を一元的に司るハードウェア制御主体をスリープモードに移行させ、該有効スリープ期間が経過することにより、ハードウェア制御主体をスリープモードから通常動作モードにウェイクアップさせる。
ソフトウェア構造上は、図１のプラットフォームの一部をなすものとして把握できる。その詳細については、後述する。

図１０の、Ｓ１２０における各アプリケーションによる制御を示すのが図３の説明図である。ここには、プラットフォームの機能の一部として形成されたスケジューラによって、複数のアプリケーション１，２‥ｎが順次起動される様子が示されている。このとき、プラットフォーム内の状態管理プログラムが、一連のアプリケーションの状態をまとめて管理するようになっており、制御状態を判定して状態遷移処理を行なう。状態管理プログラムによる状態遷移処理を示すのが、図４の説明図である。状態管理プログラムは、アプリケーションの状態として３つの状態、すなわち準備状態α、制御状態β、そして、制御開始監視状態γを定義しており、図３に示したスケジューラによる一連の起動処理毎に、各アプリケーションからの信号に基づき、必要に応じて状態を遷移させる。

すなわち、リセット指示によって動作を開始している場合、最初は準備状態αとし、一方、ウェイクアップ要因を判断して動作を開始している場合、最初は制御開始監視状態γとする。そして、準備状態αにある場合、各アプリケーションから準備完了の通知があると、次に制御状態βへ状態を遷移させる（記号(1)）。また、制御状態βにある場合、前述のスリープ管理・制御ソフト８１は、アプリケーションソフトウェア毎に異なる要求スリープ期間の開始時刻及び終了時刻を直接的又は間接的に特定するためのスリープ制御情報を取得し、全てのアプリケーションからスリープ制御情報を取得すれば、制御開始監視状態γへ状態が遷移する（記号(2)）。

各アプリケーションは、要求するスリープ期間をタイマー設定し、スリープとウェイクアップとを定期的に繰り返すようにプログラミングされている。例えば、キーレスエントリ方式が採用される場合、図１の「スイッチ／センサ等の入力」として、ユーザー携帯器からの無線信号が受信入力され、キーレスエントリ方式に対応したドアロック制御アプリケーションは、その受信スタンバイ期間を通常モード期間として、スリープ期間と交互に繰り返すようにＥＣＵ１の作動制御を行なうこととなる。

他方、アプリケーションの一部又は全部は、上記のスリープサイクルとは無関係に、外部の操作信号（ライト点灯、ドアロック解除指令など）をトリガーとした割り込み処理指令（つまり、外部からの動作指令である）を受けた場合も、これをウェイクアップ要因として随時ウェイクアップするようになっている。そして、その後一定期間ウェイクアップ要因がなければ要求スリープ期間が再設定され、スリープに移行する。従って、各アプリケーションの要求スリープ期間の、時間軸上の相対関係は、上記の不定期ウェイクアップ要因により様々に変化する。さらに、タイマーにより規定される要求スリープ期間はアプリケーションによってまちまちである。本実施形態においては、取得された各アプリケーションソフトウェアの要求スリープ制御情報が各々規定する複数の要求スリープ期間に、共通に含まれる期間を有効スリープ期間として算出する。そして、制御開始監視状態γにおいては、有効スリープ期間の開始タイミングが到来すれば、ウェイクアップ用のスリープタイマー７Ｔにその有効スリープ期間をセットし、スリープ状態に移行する。スリープタイマー７Ｔは有効スリープ期間がタイムアップすればウェイクアップ信号を送信し、ＥＣＵ１をウェイクアップさせる。

要求スリープ制御情報は各アプリケーション中に記述されており、ＲＡＭ４の対応するワークエリアの指定されたアドレスに書き込まれる。スリープ管理・制御ソフト８１は、このアドレスに自発的にアクセスして要求スリープ制御情報を取得することも可能であるが、アプリケーションプログラムがロードされるメモリアドレスが相対アドレス化されている場合に、要求スリープ制御情報の書き込みアドレスが不定となり、要求スリープ制御情報を特定するために余分なステップが必要となる（アプリケーション側からスリープ管理・制御ソフト８１に書き込みアドレスを報知することなどが考えられる）。このような面倒をなくすため、図１に示すように、ＥＣＵ１のＲＡＭ４には、複数のアプリケーションソフトウェアにて共通に使用される登録メモリ（図中では下位概念にて「タイマー登録メモリ８２」と表示している）が設けられており、各プリケーションソフトウェアが、自身に設定されているスリープ制御情報を自発的にこのメモリに書き込むことにより、これが登録されるようになっている（スリープ制御情報登録手段）。なお、本実施形態では、複数のタイマーのＩＤ（番号）とアプリケーションとの対応関係が予め定められており、以降は、要求のあったＩＤ（アプリケーション）のタイマーに設定されたスリープ開始/終了時間（要求スリープ制御情報）が読み出されて使用されるようになっている（つまり、「アプリケーションと対応付けて記憶されている」とは、「アプリケーションとの対応関係が特定可能な状態で記憶されている」との意味であり、アプリケーションそのものが登録メモリに記憶されているわけではない）。

図５に示すように、要求スリープ制御情報の与え方は種々考えられる。まず、Ａは最も簡単な方式であり、アプリケーションはスリープを開始したい時刻に要求スリープ期間Ｔｄ（つまり、タイマー登録データ）を登録メモリ（つまり、タイマー登録メモリ８２）に登録する。図９は、その場合のスリープ管理・制御ソフト８１によるタイマー登録処理の流れを示すフローチャートの例であり、Ｓ５１でアプリケーションの番号ｋを初期化し、Ｓ５２では番号ｋのアプリケーションから要求スリープ期間Ｔｄが書き込まれたかどうかを確認する。書き込まれれば、そＳ５３で、その書き込み時間に対応する要求スリープ開始時刻ｔｓｋを登録する。

この場合、スリープ管理・制御ソフト８１には、図１に示すように管理タイマー８１Ｔを設けておき、書き込みのあったときの管理タイマー８１Ｔの値から時刻把握することができる。アプリケーションからは、実際にスリープに入りたい時刻に対して、一定時間Δｔだけ前倒しで要求スリープ期間Ｔｄｋが書き込まれるようにしておき、書き込みのあった時刻をｔｓｋ’とすれば、ｔｓｋ’＋Δｔを要求スリープ開始時刻ｔｓｋとして登録することができる。要求スリープ期間Ｔｄｋは、例えば前回スリープからのウェイクアップ時に、次回スリープのために後述のスリープタイマー７Ｔにセットすることができる。この場合、Δｔは、ウェイクアップ後の次回スリープの条件となる、外部要求ウェイクアップ要因（例えば、ドア開閉、ドアロック、ランプ点灯などのユーザーによる操作信号）の不発生継続時間（アイドリング期間）として定めることができる。

要求スリープ開始時刻ｔｓｋが算出できれば、書き込まれた要求スリープ期間Ｔｄｋから、要求スリープ終了時刻ｔｗｋをｔｓｋ＋Ｔｄｋにて算出し、登録する（Ｓ５５，Ｓ５６）。以上の処理を全てのアプリケーションについて繰り返すと、登録メモリの内容は図６のような状態となる。すなわち、各アプリケーションの要求スリープ制御情報の内容が、アプリケーションと対応付けて記憶されている。

そして、ここでの処理の最終的な目的は、複数のアプリケーションの要求スリープ期間Ｔｄｋを調停し、共通に含まれる期間を、ＥＣＵ１を実際にスリープさせる有効スリープ期間Ｔｄｃとして決定することにある。このためには、有効スリープ期間Ｔｄｃの開始時刻（ｔｓｃ）を決定するために要求スリープ開始時刻ｔｓｋが必要であり、また、終了時刻（ｔｗｃ）を決定するために要求スリープ終了時刻ｔｗｋが必要である。図１に一点鎖線で示すように、ＥＣＵ１に絶対時刻把握のための時計６が設けられていれば、図５のＢ〜Ｄのような登録方式も可能である。すなわち、アプリケーション側で時計６を読み取ることにより、Ｂでは要求スリープ開始時刻ｔｓｋと要求スリープ期間Ｔｄｋとを登録する。また、Ｃでは、要求スリープ終了時刻ｔｗｋと要求スリープ期間Ｔｄｋとを登録する。そしてＤでは、要求スリープ開始時刻ｔｓｋと要求スリープ期間Ｔｄｋとを登録する。

有効スリープ期間Ｔｄｃを含むスリープ条件の設定は、例えば、以下のような手順で行なうことができる。まず、登録された要求スリープ開始時刻ｔｓｋのうち最も遅く到来するもの（第二種限界時刻）を有効スリープ開始了時刻ｔｓｃとして算出し、図５に示すごとく登録する。ただし、スリープ処理の時間的マージンを見込んで、第二種限界時刻に一定期間δｔを加算して有効スリープ開始時刻ｔｓｃを設定してもよい。

また、登録された要求スリープ終了時刻ｔｗｋのうち、最も早く到来するもの（第一種限界時刻）を有効スリープ終了時刻ｔｗｃとして算出し、図５に示すごとく登録する。ただし、ウェイクアップ処理の時間的マージンを見込んで、第一種限界時刻から一定期間δｔを減算して有効スリープ終了時刻ｔｗｃを設定してもよい。そして、有効スリープ期間Ｔｄｃをｔｗｃ−ｔｗｓにより算出する。

図７と図８は、上記の処理のタイミングチャート的に図示したものであり、図７では、全てのアプリケーションの要求スリープ開始時刻ｔｓｋが一致する場合の例を示している。この場合、要求スリープ終了時刻ｔｗｋが最も早く到来するアプリケーションの要求スリープ期間（図ではＴｄ２）が、有効スリープ終了時刻ｔｗｃと等価となる。全てのアプリケーションの要求スリープ開始時刻ｔｓｋが常時一致することが予めわかっている場合は、スリープ制御情報として要求スリープ期間Ｔｄｋか要求スリープ終了時刻ｔｗｋのみを登録することも考えられる。

一方、図８は、要求スリープ開始時刻ｔｓｋがアプリケーション間で不一致となる場合である。登録された要求スリープ開始時刻ｔｓｋのうち最も遅く到来するもの（第二種限界時刻）と、登録された要求スリープ終了時刻ｔｗｋのうち、最も早く到来するもの（第一種限界時刻）との間に、有効スリープ期間Ｔｄｃが設定されていることが明らかである。

さて、以上説明したごとく、スリープモードからのウェイクアップに関しては、その要因が２種類あることは明らかである。その一方は、スリープタイマー７Ｔのタイムアップを要因とするウェイクアップ（タイマーウェイクアップ：本実施形態では、それに伴いウェイクアップ信号発生部７がウェイクアップ信号をウェイクアップポートＩＮＴに入力することにより実行される割り込み処理である）、他方は外部からの動作要求による内部処理的な割り込みを要因とするウェイクアップ（外部要求ウェイクアップ）である。本発明の要点は、この二種のウェイクアップ要因を明確に検出・区別し、ウェイクアップ後のアプリケーション起動処理の流れも異なるものとしていることにある。

図１１は、その具体的な処理を司る、前述のウェイクアップ制御処理の流れを示すフローチャートである。まず、Ｓ１０１ではウェイクアップ要因の監視を行なう。具体的には、イグニッションスイッチＳＷ１、ライトコントロールスイッチＳＷ２、ライトセンサ６１（以上、ライト制御アプリケーション用）、パワーウィンドウスイッチユニット６３（パワーウィンドウ制御アプリケーション用）、ドア操作スイッチユニット６３（ドア開閉制御アプリケーション用）、無線受信機６４（ワイヤレスドアロック制御アプリケーション用）などの、各信号入力ポート（第一種入力ポートという）の状態と、タイマーウェイクアップ用のポートＩＮＴ（第二種入力ポートという）の状態を監視する。上記の各入力デバイスからの入力状態は、ユーザーによる操作によって変化するものであり、その変化を検出して、対応する被制御要素（ヘッドライト／テールライトの点灯ユニット７１，７２、パワーウィンドウ駆動ユニット７３、ドア開閉ユニット７４あるいはドアロック機構７５）が対応するアプリケーションにより動作制御される。つまり、第一種入力ポートの入力状態変化から、そのポートが割り当てられたアプリケーションに対する動作要求の有無を容易に判断することができる。また、第一種入力ポートのどれかに有効な状態変化が現れれば、この場合のウェイクアップが外部要因ウェイクアップであり、そのポートの種別からどのアプリケーションの動作が要求されたかを把握できる。他方、第二種ポートに有効な状態変化が現れれば、この場合のウェイクアップがタイマーウェイクアップであることを把握できる。

Ｓ１０２でウェイクアップ要因が検出されれば、Ｓ１０３に進んで初期設定処理となる。この処理は、周辺レジスタの内容設定等の他、前述のスリープ条件ｔｓｃ、ｔｗｃ、Ｔｄｃの算出・設定処理も含む。そして、Ｓ１０４では、ウェイクアップがタイマーウェイクアップであるかどうかが判断される。もし、タイマーウェイクアップでなければ、それは外部要因ウェイクアップであるからＳ１１３に進み、ウェイクアップ要因に関与するアプリケーションがどれであるかを、信号変化のあったポートの種別から判定する。そして、そのアプリケーションを第一種アプリケーションとして、該第一種アプリケーションに割り当てられたリソースのみ、ウェイクアップに必要な状態に設定する（本発明の第一におけるリソース設定手段の機能が実現している）。次に、Ｓ１１４に進み、上記第一種アプリケーションと、残余の第二種アプリケーションとの全てを起動する（本発明の第一におけるアプリケーション起動手段の機能が実現している）。この後のアプリケーションの処理流れは、図１１には表れていないが、第一種アプリケーションは外部から動作要求に従い、対応する被制御要素が所望の動作を行なうように、その要部（メインプログラム）が実行動作に移される。他方、第二種アプリケーションは、外部から動作要求がないので、動作要求があるまで待機状態となる。このあとＳ１０６に進む。

一方、タイマーウェイクアップであった場合はＳ１０４からＳ１０５に進む。この場合は、どのアプリケーションについても外部から動作要求がない状態であるから、アプリケーションのリソース設定を全く行なわない状態で、全てのアプリケーションを起動させる（本発明の第二におけるアプリケーション起動手段の機能が実現している）。

Ｓ１０６以下は、上記２種のウェイクアップについて共通の処理となる。まず、Ｓ１０６では、算出された有効スリープ期間Ｔｄｃが基準値Ｔｄminよりも小さいかどうかを判定し、小さくなければＳ１０７に進んで、図１の管理タイマー８１Ｔにより現在時刻を読み取るとともに、Ｓ１０８で有効スリープ開始時刻ｔｓｃが到来しているかどうかを確認する。到来していればＳ１０９に進み、図１のウェイクアップ信号発生部７のスリープタイマー７Ｔに有効スリープ期間Ｔｄｃをセットして、ＥＣＵ１をスリープ状態に移行させる。

Ｓ１１４からの流れでこの処理に移行した場合、スリープタイマーが計測する一定のアイドリング期間がタイムアップするまで、第二種アプリケーションのどれにも動作要求がなかったことを意味し、結局、第二種アプリケーションについてはリソース設定が行なわれないままスリープモードへ移行することになる（図１３のパターンＢ）。他方、Ｓ１０５からの流れでこの処理に移行した場合は、アイドリング期間中に複数のアプリケーションのいずれに対しても外部からの作動要求がなされなかった場合に、該アプリケーションへのリソース設定を行なわないままスリープモードへ移行することになる（図１３のパターンＣ）。それぞれ、本発明の第一及び第二におけるスリープ移行手段の機能が実現していることが明らかである。そして、いずれの場合も、図１３のパターンＡに示すごとく、ウェイクアップ要因の区別なく全アプリケーションのリソース設定を行なってからアプリケーションを起動する従来の方式と比較して、アプリケーションが起動するまでの時間が大幅に短縮され、かつ、次のスリープに移行するまでの時間ひいては暗電流の通電時間も短くなっていることがわかる。

図１１のフローチャートには表れていないが、図１のウェイクアップ信号発生部７は、上記の処理流れを受け、有効スリープ期間Ｔｄｃが経過すれば割り込みポートの１つであるウェイクアップ用ポートＩＮＴにウェイクアップ信号を入力する（つまり、タイマーウェイクアップ制御手段として機能する）。ＥＣＵ１は、これを受けて割り込み処理により、スリープモードからウェイクアップする（上記のタイマーウェイクアップである）。

図１１のウェイクアップ制御処理は、一定の周期で繰り返し実行される。例えば、Ｓ１０８で有効スリープ開始時刻ｔｓｃが到来していないようであれば、Ｓ１１０はスキップされ、スリープモードに入ることなくスリープ制御処理のその実行サイクルは終了し、移行の実行サイクルで有効スリープ開始時刻ｔｓｃが到来したときスリープモードに移行することとなる。

なお、この途上のＳ１１１では、再び第一種ポート群の入力状態をスキャンし、特定アプリケーションに対する動作要求を示す有効な状態変化が新たに生じていないかを確認する。状態変化が生じていれば、そのアプリケーションを特定して、直ちにそのアプリケーションのリソースを設定する（Ｓ１１２）。他方、有効な状態変化が生じていなければＳ１１２はスキップされる。つまり、ウェイクアップ制御処理の反復に伴い、動作要求を示す有効な状態変化が検出されれば、これに対応するアプリケーションについてのみリソースの設定が追加される。これにより、無駄なリソース設定処理が反復されて非スリープ期間が侵食され、暗電流が増大する不具合をより効果的に抑制できる。ただし、Ｓ１１２の処理に代え、何らかのアプリケーションに対する外部動作要求があった場合は、全てのアプリケーションのリソース設定を行ない、その後、再度アプリケーションを起動しなおす処理を行なうようにしてもよい（図１３のパターンＤ）。

なお、Ｓ１０３のスリープ条件設定（調停）処理は、実行サイクル毎に各アプリケーションの状態を監視する役割も果たしており、もしスリープ制御情報の登録内容に変化があれば、有効スリープ期間の設定内容も更新される。例えば、図８において、動作頻度の比較的高いアプリケーション１〜３の間で、一旦スリープ調停された後、常時は動作頻度の非常に低いアプリケーション４が偶然動作して、そのアプリケーション４を追加した形での再調停が必要となった場合は、破線で示すように、そのアプリケーション４のスリープ制御情報が追加され、有効スリープ期間Ｔｄｃが更新される。

また、アプリケーション１〜３がバージョンアップ等により書き換えられた場合も、アプリケーション１〜３に要求スリープ制御情報の登録機能が備わっている限り、図９のスリープ制御情報の登録処理や、図１１のウェイク制御処理のプログラムには何ら変化は生じず、図６の登録内容もバージョンアップに対応した形で自発的に書き換えられ、スリープ調停のためのプログラムの手直し等は一切不要である。この事情は、もともと存在していなかったアプリケーションが、機能追加により新たにＲＯＭ５（図１）に書き加えられた場合においても同様である。

次に、図７及び図８に示すように、各アプリケーションのハードウェア的なスリープ／ウェイクアップは、要求スリープ期間の調停結果として算出される有効スリープ期間Ｔｄｃに従って、ＥＣＵ１を単位として実行される。しかし、個々のアプリケーションの内部処理においては、図１に示すごとく、要求スリープ制御情報が、要求スリープ期間Ｔｄを設定時間とする個別のタイマーにより与えられており、ＥＣＵ１がウェイクアップしても、個々のアプリケーションは各タイマーが規定する要求スリープ終了時刻が到来しなければ、アプリケーション自体は起動しない。この様子を図１４に示している。この場合、ａ〜ｃに示すように、有効スリープ期間の設定状況によりアプリケーションの起動タイミングも一定しないことになる。例えば有効スリープ期間Ｔｄｃに対して、要求スリープ期間が時間的に後に乖離している場合は、当該アプリケーションへの外部動作要求が存在していなくとも、その起動が遅れる分だけ次のスリープに入るタイミングも遅れ、暗電流の増大につながる問題がある。そこで、ｄに示すように、ウェイクアップ後にどのアプリケーションについても外部動作要求が存在しない場合に限り、スリープタイマーよりも上位の割り込みを別途用意したソフトウェアの実行により強制的に発生させ、アプリケーションの実行開始時刻を前倒しするように制御することができる。これにより、暗電流の低減を図ることができる。

本発明の自動車用制御装置を構成するＥＣＵの一例を示すブロック図。 図１のシステムのアーキテクチャを示す模式図。 スケジューラによる複数アプリケーションの実行サイクルの概念を模式的に示す図。 リセット及びスリープに係る状態遷移の模式図。 各アプリケーションの要求スリープ制御情報の登録形態を各種例示して示す図。 タイマー登録メモリの内容を示す模式図。 スリープ調停の第一例を示す概念図。 同じく第二例を示す概念図。 要求スリープ制御情報の登録処理の一例を示すフローチャート。 リセット、スリープ及びウェイクアップに係る概略の処理流れを示すフローチャート。 本発明の要部をなすウェイクアップ制御処理の一例を示すフローチャート。 リソース設定領域のメモリ構造を示す概念図。 本発明の効果を従来例と比較して示すタイミング図。 参考技術の概要を示すタイミング図。

符号の説明

１ ＥＣＵ（ハードウェア制御主体：自動車用制御装置）

Claims (8)

1. 自動車上の複数の被制御要素の電気的動作を制御するために前記被制御要素に対応して設けられた複数の制御手段を、同一のハードウェア制御主体上でそれぞれ実行される、各制御手段に対応した複数のアプリケーションにより機能実現するとともに、前記制御手段の動作モードが、通常動作モードと、該通常動作モードよりも消費電力量が少ないスリープモードとの間で切り替え可能に構成された自動車用制御装置であって、
   前記ハードウェア制御主体は、ＣＰＵと、前記アプリケーションを格納するＲＯＭと、前記ＣＰＵ上にて前記複数のアプリケーションを実行するためのワークエリアとなるＲＡＭとを有し、前記ＲＡＭ上には、前記ハードウェア制御主体の各アプリケーションに割り当てられるリソースの設定領域がアプリケーション毎に個別に設けられ、
   前記ハードウェア制御主体が前記スリープモードから前記通常モードに切り替わるウェイクアップの要因が、前記複数のアプリケーションの少なくとも１つに対する外部からの作動要求に基づいて発生する場合において、前記複数のアプリケーションのうち、当該作動要求のあったアプリケーションを第一種アプリケーション、残余のアプリケーションを第二種アプリケーションとして定めたとき、前記ウェイクアップに際して前記第一種アプリケーションのリソースを、前記第二種アプリケーションのリソースに優先して前記ＲＡＭ上の対応する設定領域に設定するリソース設定手段と、
   前記第一種アプリケーションのリソースを設定後に、前記第二種アプリケーションのリソースを設定することなく前記第一種アプリケーションを起動するアプリケーション起動手段と、
   を有することを特徴とする自動車用制御装置。
2. 前記アプリケーション起動手段は、前記第二種アプリケーションに対するリソース設定を行なわない状態で、前記第一種アプリケーションとともに該第二種アプリケーションも合せて起動する請求項１記載の自動車用制御装置。
3. 前記ハードウェア制御主体がウェイクアップした後、前記複数のアプリケーションに対する外部からの作動要求が途絶してから一定のアイドリング期間が経過した場合に、該ハードウェア制御主体を前記スリープモードに移行させるスリープ移行手段を有するとともに、前記リソース設定手段は、前記アイドリング期間中に前記第二種アプリケーションのいずれに対しても前記外部からの作動要求がなされなかった場合に、該第二種アプリケーションへのリソース設定を行なわず、前記スリープ移行手段は該第二種アプリケーションへのリソース設定を行なわないまま前記スリープモードへ移行させるものである請求項１又は請求項２に記載の自動車用制御装置。
4. 前記リソース設定手段は、前記アイドリング期間中に前記第二種アプリケーションのいずれかに対して前記外部からの作動要求がなされた場合に、その作動要求のあった第二種アプリケーションについてのみ追加してリソース設定を行なう請求項３記載の自動車用制御装置。
5. 前記ハードウェア制御主体が前記スリープモードへ移行後、スリープタイマーが計測する予め定められたスリープ期間が経過した場合に、該ハードウェア制御主体をウェイクアップさせるタイマーウェイクアップ制御手段を有するとともに、
   前記アプリケーション起動手段は、前記ウェイクアップの要因が、前記タイマーウェイクアップ制御手段によるウェイクアップ要求に基づいて発生する場合において、当該ウェイクアップに際して前記アプリケーションを、そのリソース設定を行なうことなく起動する請求項１ないし請求項４のいずれか１項に記載の自動車用制御装置。
6. 自動車上の複数の被制御要素の電気的動作を制御するために前記被制御要素に対応して設けられた複数の制御手段を、同一のハードウェア制御主体上でそれぞれ実行される、各制御手段に対応した複数のアプリケーションにより機能実現するとともに、前記制御手段の動作モードが、通常動作モードと、該通常動作モードよりも消費電力量が少ないスリープモードとの間で切り替え可能に構成された自動車用制御装置であって、
   前記ハードウェア制御主体が前記スリープモードへ移行後、スリープタイマーが計測する予め定められたスリープ期間が経過した場合に、該ハードウェア制御主体をウェイクアップさせるタイマーウェイクアップ制御手段と、
   前記ハードウェア制御主体が前記スリープモードから前記通常モードに切り替わるウェイクアップの要因が、前記タイマーウェイクアップ制御手段によるウェイクアップ要求に基づいて発生する場合において、当該ウェイクアップに際して前記アプリケーションを、そのリソース設定を行なうことなく起動するアプリケーション起動手段と、
   を有することを特徴とする自動車用制御装置。
7. 前記ハードウェア制御主体がウェイクアップした後、前記複数のアプリケーションに対する外部からの作動要求が途絶してから一定のアイドリング期間が経過した場合には、該ハードウェア制御主体を前記スリープモードに移行させるとともに、前記アイドリング期間中に前記複数のアプリケーションのいずれに対しても前記外部からの作動要求がなされなかった場合に、該アプリケーションへのリソース設定を行なわないまま前記スリープモードへ移行させるスリープ移行手段を有する請求項５又は請求項６に記載の自動車用制御装置。
8. 前記アイドリング期間中に前記複数のアプリケーションのいずれかに対して前記外部からの作動要求がなされた場合に、その作動要求のあったアプリケーションについてリソース設定を行なうリソース設定手段を有する請求項７記載の自動車用制御装置。

Images