JP2007001420A - 自動車用制御ユニット - Google Patents

Abstract

【課題】 シリアル通信処理を、複数のプログラムモジュールにより非同期に実行する場合においても、通信異常発生時に迅速かつ的確に対応できる異常処理機能を有した自動車用制御ユニットを提供する。
【解決手段】 通信ソフトウェアが、通信バスに接続されたシリアル通信インターフェースを送受信駆動する駆動モジュールと、駆動モジュールとアプリケーションとの間の送受信中継処理を行なう中継モジュールと、制御状態が制御用メッセージの送受信に適した状態に遷移しているか否かに基づいて、制御用メッセージの送受信に関する指令を行なう駆動管理モジュールと、駆動モジュール、中継モジュール及び駆動管理モジュールから異常発生報告を受け、駆動モジュール、中継モジュール及び駆動管理モジュールのそれぞれに一元的な異常発生通知を行なう異常監視モジュールと、を有する。
【選択図】 図５

Description

この発明は、自動車用制御ユニットに関し、特に自動車上の他の制御ユニットとシリアル通信バスにより接続された形で使用される自動車用制御ユニットに関する。

特開２００２−３１８７８３号公報

自動車には、各種機器（被制御要素）を制御するために、マイクロプロセッサ（ハードウェア制御主体）からなるＥＣＵが搭載されている。このようなＥＣＵとして、自動車上の他のＥＣＵと通信バスを介して通信できるようにしたマイクロプロセッサが使用されている。一つのＥＣＵは、一般には複数機能を統括的に司るために、制御処理用のアプリケーションも複数搭載されるのが常である。各アプリケーションによる制御は、ＥＣＵのプラットフォーム機能の一部として形成されたスケジューラによって順次起動され、プラットフォーム内の状態管理プログラムが、一連のアプリケーションの状態をまとめて管理するようになっており、制御状態を判定して状態遷移処理を行なう方式がとられる。シリアル通信処理を行なう場合、シリアル通信バスを介してアプリケーションが使用する制御用メッセージを受信する処理と、アプリケーションからの制御用メッセージがシリアル通信バス上に送信する処理とが必要になるが、その送受信のタイミングが、アプリケーション側の制御状態と適合している必要がある。この場合、ＥＣＵハードウェアによる通信バスとの間の直接的なメッセージ送受信のための駆動処理と、送受信に係るメッセージを、通信ハードウェア側とアプリケーション側との間で中継する中継処理と、アプリケーション側の状態遷移を監視しつつ、送受信に係るメッセージの中継タイミングの意思決定を行なう駆動管理処理とが、互いに独立して行なわれることが必要となり、それぞれが異なるプログラムモジュールにより非同期に実行されることとなる。

上記のような方式で通信に異常が発生した場合、その異常対応処理も、各プログラムモジュールが全体に与える影響を考慮して非同期に行なうことになる。しかし、このようなモジュール単位での異常処理では、各モジュールが異常発生の認識に一定数の処理ステップを消費するために、発生した異常に対応する処理がなされるまでに時間を要する問題がある。また、同時に発生した異常処理をまとめて処理することもできない。

本発明の課題は、シリアル通信処理を、複数のプログラムモジュールにより非同期に実行する場合においても、通信異常発生時に迅速かつ的確に対応できる異常処理機能を有した自動車用制御ユニットを提供することにある。

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

上記の課題を解決するために、本発明の自動車用制御ユニットは、
ＣＰＵからなる主制御部を有し、自動車上の他の制御ユニットとシリアル通信バスにより接続され、自動車上に搭載される電子機器の制御処理を、予め定められた複数のアプリケーションの実行に基づいて実施する自動車用制御ユニットであって、
アプリケーションによる電子機器の制御状態を管理するとともに、制御状態を判定して状態遷移処理を行なうアプリケーション状態管理手段と、
シリアル通信バスを介してアプリケーションが使用する制御用メッセージを受信する処理と、他方、アプリケーションからの制御用メッセージをシリアル通信バス上に送信する処理とを、主制御部による通信ソフトウェアの実行に基づいて実施するシリアル通信制御手段とを有し、通信ソフトウェアが、
制御用メッセージの通信バスへの送信ないし通信バスからの受信のために、通信バスに接続されたシリアル通信インターフェースを駆動する駆動モジュールと、
駆動モジュールとアプリケーションとの間の送受信中継処理として、アプリケーションからの制御用メッセージの送受信要求を受け付けるとともに、駆動モジュールが受信した制御用メッセージをアプリケーションに転送する一方、アプリケーションから送信要求のあった制御用メッセージを駆動モジュールに転送する中継モジュールと、
アプリケーション状態管理手段による制御状態が、該アプリケーションにおける制御用メッセージの送受信に適した状態に遷移しているか否かを判定し、該判定結果に基づいて駆動モジュール及び中継モジュールに対する制御用メッセージの送受信に関する指令を行なう駆動管理モジュールと、
駆動モジュール、中継モジュール及び駆動管理モジュールのうち、少なくとも駆動管理モジュールからの異常発生報告を受け、駆動モジュール、中継モジュール及び駆動管理モジュールのそれぞれに一元的な異常発生通知を行なう異常監視モジュールと、を有することを特徴とする。

上記の構成によると、アプリケーションとシリアル通信バスとの間での通信メッセージの送受信処理が、駆動モジュールと、中継モジュールと、駆動管理モジュールとの連携により、制御状態に状態遷移に合わせて的確に実施することができる。そして、通信異常が発生した場合は、駆動モジュール、中継モジュール及び駆動管理モジュールのうち、少なくとも駆動管理モジュールからの異常発生報告を受け、駆動モジュール、中継モジュール及び駆動管理モジュールのそれぞれに一元的な異常発生通知を行なうようにしたから、これら３つのモジュールによる非同期のシリアル通信処理であるにもかかわらず、通信異常発生への対応処理を迅速かつ的確に実施できる。

この場合、駆動管理モジュール、中継モジュール及び駆動モジュールが、予め定められた異常状態が成立した場合に、いずれも異常監視モジュールに異常報告を個別に行なうように構成しておくと、各モジュールレベルに特有の通信異常にきめ細かく対応することができる。駆動管理モジュール、中継モジュール、駆動モジュール及び異常監視モジュールは、予め定められた時系列順序にて周期的に実行するようにしておくと、モジュール間の処理のコンフリクトが発生せず、時分割による効率的な非同期処理が可能となる。

異常監視モジュールは、異常発生時に通信ソフトウェアの動作をスリープ状態に移行させるスリープ指示を行なうものとして構成することができる。通信異常発生時にＥＣＵが余計な動作を行なわず一旦スリープすることで、ＥＣＵ動作を介して異常不具合が以降の処理に伝播することを防止できる。また、再度通信が必要か否かを上位のアプリケーションからの指示を待って判断することで、シリアル通信全体への影響を少なくすることができる。

上記した機能からもわかる通り、中継モジュール及び駆動モジュールによる送受信処理の統括管理は駆動管理モジュールが行なっている。従って、スリープ状態に移行するためのハードウェアないしソフトウェアの準備設定を、適切なタイミングで実施できるようにする観点から、異常監視モジュールは、異常発生時に駆動管理モジュールを介して駆動モジュールにスリープ指示を行なうものとすることが望ましい。

駆動管理モジュール、中継モジュール及び駆動モジュールは、この順序にて周期的に実行することができる。中継モジュール及び駆動モジュールによる送受信タイミング調整をスムーズに行なうには、駆動管理モジュール、中継モジュール及び駆動モジュールをこの順序で立ち上げるのが合理的である。そして、異常監視モジュールは、駆動管理モジュール、中継モジュール及び駆動モジュールのいずれかから異常発生通知を受けることにより、それら駆動管理モジュール、中継モジュール及び駆動モジュールの全てにスリープ指令を行ない、制御ユニットハードウェアのスリープ設定を行なうように構成することで、上記のごとく異常発生時に駆動管理モジュールを介して駆動モジュールにスリープ指示を行なう処理もスムーズに進めることができる。

次に、本発明の自動車用制御ユニットは、アプリケーション状態管理手段が行なう状態遷移処理に伴い、遷移により設定された制御状態が制御状態特定情報の形で制御状態メモリに記憶されるよう構成することができる。この場合、駆動管理モジュールは、制御状態メモリの記憶内容に基づいてアプリケーション側の異常判定を行ない、異常監視モジュールに異常発生報告を行なうものとすることができる。通信異常が発生した場合、状態遷移設定の際に一度書き込まれた制御状態特定情報が、アプリケーション状態管理手段を司るソフトウェア以外による不正なメモリアクセスにより書き換えられることが多い。従って、これを利用すれば、制御状態メモリの記憶内容を確認することにより、通信異常の有無を容易に判定することができる。具体的には、制御状態メモリには、状態遷移が発生するたびに、制御状態特定情報とともに、そのミラー情報が記憶され、駆動管理モジュールは、該制御状態特定情報と該ミラー情報とを照合し、その照合結果に基づいて異常判定を行なうものとすることができる。ミラー情報は、アプリケーション状態管理手段が状態遷移設定に伴い、制御状態特定情報と対にして意図的に作成されるものであり、通信異常による不正アクセスでは、制御状態特定情報とそのミラー情報とが照合の取れた形で同時に書き換わる可能性は限りなくゼロに近い。従って、制御状態特定情報と対応するミラー情報との照合により、通信異常が発生したか否かを的確に判定することができる。

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

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

ＥＣＵ１は、必要に応じて外部からのスイッチやセンサからの入力信号等も参照しつつ、各アプリケーションの実行により、前述した各種ボデー系の制御対象機器（被制御要素）の動作制御を司る。しかし、ＥＣＵ１は、ある条件で、例えば、車両が駐車状態にある場合、又はあるスイッチ操作がない場合にはスリープモードに移行する。このスリープモードへの移行は、具体的には全てのアプリケーションが動作終了し、次の動作開始のための待機状態になっている場合に、ＥＣＵ１全体を低消費電力モード（ＣＰＵ３の動作クロックを与えるメインクロック回路８を停止したスタンバイモードや、通常動作と異なる低周波数の発振器で動作するスロークロックモード、あるいは一定時間ごとにＣＰＵを間欠的に動作させる間欠モードなど）へ移行させる形で行なうものであり、その制御は図２のプラットフォーム部分が担うこととなる。

ＥＣＵ１は、通信バスを介して他のハードウェア制御主体（例えば他のＥＣＵ）と接続されており、シリアル通信によりウェイクアップ要因を判断すると動作を開始する。該ウェイクアップ要因を判断した場合、ウェイクアップ時のシステム設定（リソース設定など）を行なう。いずれも、そのシステム設定の後で複数のアプリケーションの状態が判定され、所定条件成立時にスリープ時のシステム設定を行ない、その後、スリープする。この判定を含めたＥＣＵ１のスリープ状態への移行、及びウェイクアップのための準備制御などを統括的に司るのが、図１のスリープ管理・制御ソフトである。

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

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

該状態遷移処理に伴い設定された制御状態は、状態データ（制御状態特定情報）の形で、図６に示すようなＲＡＭ４内の制御状態メモリに記憶される。このとき、状態データのミラーデータ（本実施形態では、状態データの各ビットの０／１を反転させたビット反転データとしてミラーデータを作成している）も作成し、個々の状態データに対応付けて記憶する。

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

他方、アプリケーションの一部又は全部は、上記のスリープサイクルとは無関係に、外部の操作信号（ライト点灯、ドアロック解除指令など）をトリガーとした割り込み処理指令を受けた場合も、これをウェイクアップ要因として随時ウェイクアップするようになっている。そして、その後一定期間ウェイクアップ要因がなければ要求スリープ期間が再設定され、スリープに移行する。

次に、アプリケーションが使用する制御用メッセージを受信する処理と、アプリケーションからの制御用メッセージをシリアル通信バス上に送信する処理とは、図１のＣＰＵ３（主制御部）による通信ソフトウェアの実行に基づいて実施される。シリアル通信バスとＥＣＵ１の内部バスとは、シリアル通信インターフェース６を介して接続されている。また、受信メッセージを一時格納する受信バッファ６Ｂが設けられている。

通信ソフトウェアの階層構造を図５に示している。下層ほどハードウェア（ここでは通信バス）層に近く、上層ほどアプリケーション層に近いことを意味する。具体的には、下記のモジュール群よりなる。
・駆動モジュール（以下、ＤＲＶモジュールともいう）：制御用メッセージの通信バスへの送信ないし通信バスからの受信のために、通信バスに接続されたシリアル通信インターフェース６を駆動する。
・中継モジュール（以下、ＣＯＭモジュールともいう）：駆動モジュールとアプリケーションとの間の送受信中継処理として、アプリケーションからの制御用メッセージの送受信要求を受け付けるとともに、駆動モジュールが受信した制御用メッセージをアプリケーションに転送する一方、アプリケーションから送信要求のあった制御用メッセージを駆動モジュールに転送する。
・駆動管理モジュール（以下、ＮＭモジュールともいう）：アプリケーション状態管理手段による制御状態が、該アプリケーションにおける制御用メッセージの送受信に適した状態に遷移しているか否かを判定し、該判定結果に基づいて駆動モジュール及び中継モジュールに対する制御用メッセージの送受信に関する指令を行なう。
・異常監視モジュール：駆動モジュール、中継モジュール及び駆動管理モジュールのうち、少なくとも駆動管理モジュール（本実施形態では、上記３つのモジュールの全て）からの異常発生報告を受け、駆動モジュール、中継モジュール及び駆動管理モジュールのそれぞれに一元的な異常発生通知を行なう。

ＤＲＶモジュールが最もハードウェア層に近く、ＣＯＭモジュール、ＮＭモジュール及び異常監視モジュールはアプリケーション層とＤＲＶモジュール層との中間に位置する。なお、本実施形態では、通信容量の増大を図るために、シリアル通信バスを複数チャネルにて構成し、ＤＲＶモジュールとＮＭモジュールとはチャネル毎に設けられている。

図１のＲＡＭ４には、通信制御メモリが設けられている。図７に示すように、通信制御メモリには、通信バスから受信した制御用メッセージを格納する受信メッセージボックスメモリ、これから通信バスへ送信しようとしている制御用メッセージを格納する送信メッセージボックスメモリ、アプリケーションからの制御用メッセージの送信要求を受け付けて登録するための送信受付メモリ、ＮＭモジュールによるＤＲＶモジュールへの指令内容を格納するＮＭ通知メモリ（送信用と受信用とが個別に設けられている）及び異常監視モジュールへの異常通知内容を記憶する異常通知メモリが設けられている。図８に示すように、アプリケーションとは別のスケジューラによって、ＮＭモジュール、ＣＯＭモジュール、ＤＲＶモジュール及び異常監視モジュールは、この順序で周期的に実行される。

図９は、ＮＭモジュールの処理の流れを示すものである。まず、Ｓ３で対象となるアプリケーションの状態データを読み出し、Ｓ４でこれに対応するミラーデータを読み出す（図６参照）。Ｓ５では、読み出した状態データとミラーデータの照合処理を行なう。図６に示すように、本実施形態ではミラーデータは状態データのビット反転データに相当し、状態データが書き換わって、ミラーデータの対応するビットとの間で不整合が生じていれば、その否定排他的論理和の値がゼロとなる。従って、その値の全ビットに対するサムを演算し、そのサムがゼロであれば照合一致、ゼロでなければ照合不一致として判定される。Ｓ６でその判定結果が不一致であればＳ１３に進み、異常監視モジュールに異常通知を行なって処理サイクルを終了する（本実施形態では異常通知メモリへの書込みによっているが、この形態に限られるものではない）。

他方、Ｓ６で照合一致ならば状態データに異常なしなので、Ｓ７でその状態が送信許可に適合した状態であるか否かを判定する。送信不可であれば処理サイクルを終了する一方、送信可能であればＳ９に進み、ＮＭ通知メモリに制御用メッセージの通信バスへの送出許可をセットする。また、Ｓ１０では受信許可に適合した状態であるか否かを判定し、受信不可であれば処理サイクルを終了する一方、受信可能であればＳ１１に進み、ＮＭ通知メモリに制御用メッセージのＣＯＭモジュールへの転送許可をセットし、処理サイクルを終了する。

図１０は、ＣＯＭモジュールの処理の流れを示すものである。まず、Ｓ１０３では、先のサイクルでアプリケーションに転送してある制御用メッセージの、当該アプリケーションからの受領（アクノリッジ）があるかどうかを確認する。Ｓ１０４では、その結果を判定し、受領なしであればアプリケーション側の異常と判定してＳ１１２に進み、異常監視モジュールに異常通知を行なって処理サイクルを終了する。なお、ＮＭモジュールと同様に、監視対象となる状態データと、ミラーデータとの照合処理に基づいて異常判定を行なうようにしてもよい。

他方、Ｓ１０４で「異常なし」であれば、Ｓ１０５で受信メッセージボックスメモリをリードし、Ｓ１０６で処理対象となるアプリケーションへの受信メッセージがあるかどうかを調べる。受信メッセージがあれば、Ｓ１０７で対応するアプリケーションへ受信メッセージを転送する（この結果に対して、次サイクル以降にアプリケーションからアクノリッジが返されることとなる）。一方、Ｓ１０６で受信メッセージがなければＳ１０７をスキップする。

次いで、Ｓ１０８では送信受付メモリをリードし、Ｓ１０９で処理対象となるアプリケーションからの制御用メッセージの送信要求があるかどうかを確認する。送信要求があればＳ１１０に進み、その制御用メッセージを受け付けてこれを送信メッセージボックスメモリにセットする。一方、Ｓ１０９で制御用メッセージの送信要求がなければＳ１１０をスキップする。以上で処理サイクルを終了する。

図１１は、ＤＲＶモジュールの処理の流れを示すものである。まず、Ｓ２０３にて、通信バスに断線やショートなどのハードウェア異常がないかどうかを、ポート電圧などを参照して判定する。異常があれば、Ｓ２１７に進んで、シリアル通信インターフェース６（図１）の送受信動作を停止させる。そして、Ｓ２１８に進み、異常監視モジュールに異常通知を行なって処理サイクルを終了する。なお、ＮＭモジュールと同様に、監視対象となる状態データと、ミラーデータとの照合処理に基づいて異常判定を行なうようにしてもよい。

Ｓ２０３でハードウェア異常が検出されなければ、Ｓ２０４に進んで受信バッファをリードし、Ｓ２０５で制御用メッセージを受信しているかどうか（受信していれば、そのヘッダＩＤの内容から、どのアプリケーションへの制御用メッセージなのか）を判定する。制御用メッセージを受信していれば、Ｓ２０６に進んでＮＭ通知メモリをリードする（制御用メッセージが受信されていなければ、Ｓ２０９へジャンプする）。そして、Ｓ２０７で、ＣＯＭへの転送許可が通知されているかどうかを確認し、転送許可されていれば、受信バッファ上の制御用メッセージを受信メッセージボックスメモリへ格納する（転送許可されていなければＳ２０８をスキップする）。

Ｓ２０９では送信メッセージボックスメモリをリードし、処理対象となるアプリケーションからの送信メッセージがあるかどうかを確認する。送信メッセージがあればＳ２１１に進み、ＮＭ通知メモリをリードする（送信メッセージがなければ、処理サイクルを終了する）。Ｓ２１２では、ＮＭ通知メモリの内容が、制御用メッセージの通信バスへの送出許可を示す内容か否かを確認し、送出許可になっていればＳ２１３へ進み、メッセージを通信バスへ送出する（送出許可がなされていなければ、そのまま処理サイクルを終了する）。

図１２は、異常監視モジュールの処理の流れを示すものである。Ｓ３０１〜Ｓ３０３では、ＮＭモジュール、ＣＯＭモジュール及びＤＲＶモジュールから、それぞれ異常通知（異常報告）があるかどうかを確認し、異常通知があれば、Ｓ３０６に進んで、各モジュールに対してスリープ設定を行なう。なお、あとで異常の原因をトレースする場合の便宜を図るため、各モジュールは、どのモジュールから異常通知があったかを区別できるように異常通知メモリに異常セットすることが望ましい（モジュール別に個別の異常通知メモリを設けておくことも可能である）。また、異常内容（例えば、異常の種別をコード化したもの）も合わせて異常通知メモリにセットすると、異常原因トレースがより容易になる。

図９〜図１１に示すごとく、異常監視モジュールの上記機能により、どれかのモジュールから異常通知があった場合は、シリアル通信処理の動作を一旦停止するために、どのモジュールも直ちにスリープ対応処理を行なう。これにより、通信異常発生時には、ＥＣＵ１が余計な動作を行なわず一旦スリープすることになり、ＥＣＵ動作を介して異常不具合が以降の処理に伝播することを防止できる。また、再度通信が必要か否かを上位のアプリケーションからの指示を待って判断することも可能となり、シリアル通信全体への影響を少なくすることができる。

図１２の処理流れからもわかる通り、異常監視モジュールは、各モジュールからの異常報告を受け付け、それらモジュールのスリープ移行処理を統括的に管理する。つまり、ＮＭモジュール、ＣＯＭモジュール及びＤＲＶモジュールのいずれかから異常発生通知を受けることにより、それらＮＭモジュール、ＣＯＭモジュール及びＤＲＶモジュールの全てにスリープ指令を行ない、制御ユニットハードウェアのスリープ設定を行なうことが明らかである。

本発明の自動車用スリープ制御システムの機能を有したＥＣＵの一例を示すブロック図。 図１のシステムのアーキテクチャを示す模式図。 スケジューラによる複数アプリケーションの実行サイクルの概念を模式的に示す図。 リセット及びスリープに係る状態遷移の模式図。 通信ソフトウェアの階層構造を示す模式図。 状態データとミラーデータの概念図。 通信制御メモリの内容を示す模式図。 各モジュールの実行サイクルを示す概念図。 ＮＭモジュールの処理の流れを示すフローチャート。 ＣＯＭモジュールの処理の流れを示すフローチャート。 ＤＲＶモジュールの処理の流れを示すフローチャート。 異常監視モジュールの処理の流れを示すフローチャート。

符号の説明

１ ＥＣＵ（自動車用制御ユニット）

Claims (7)

1. ＣＰＵからなる主制御部を有し、自動車上の他の制御ユニットとシリアル通信バスにより接続され、自動車上に搭載される電子機器の制御処理を、予め定められた複数のアプリケーションの実行に基づいて実施する自動車用制御ユニットであって、
   前記アプリケーションによる前記電子機器の制御状態を管理するとともに、前記制御状態を判定して状態遷移処理を行なうアプリケーション状態管理手段と、
   前記シリアル通信バスを介して前記アプリケーションが使用する制御用メッセージを受信する処理と、他方、前記アプリケーションからの制御用メッセージを前記シリアル通信バス上に送信する処理とを、前記主制御部による通信ソフトウェアの実行に基づいて実施するシリアル通信制御手段とを有し、前記通信ソフトウェアが、
   前記制御用メッセージの前記通信バスへの送信ないし前記通信バスからの受信のために、前記通信バスに接続されたシリアル通信インターフェースを駆動する駆動モジュールと、
   前記駆動モジュールと前記アプリケーションとの間の送受信中継処理として、前記アプリケーションからの制御用メッセージの送受信要求を受け付けるとともに、前記駆動モジュールが受信した制御用メッセージを前記アプリケーションに転送する一方、前記アプリケーションから送信要求のあった制御用メッセージを前記駆動モジュールに転送する中継モジュールと、
   前記アプリケーション状態管理手段による制御状態が、該アプリケーションにおける前記制御用メッセージの送受信に適した状態に遷移しているか否かを判定し、該判定結果に基づいて前記駆動モジュール及び前記中継モジュールに対する前記制御用メッセージの送受信に関する指令を行なう駆動管理モジュールと、
   前記駆動モジュール、前記中継モジュール及び前記駆動管理モジュールのうち、少なくとも前記駆動管理モジュールからの異常発生報告を受け、前記駆動モジュール、前記中継モジュール及び前記駆動管理モジュールのそれぞれに一元的な異常発生通知を行なう異常監視モジュールと、
   を有することを特徴とする自動車用制御ユニット。
2. 前記駆動管理モジュール、前記中継モジュール及び前記駆動モジュールが、予め定められた異常状態が成立した場合に、いずれも前記異常監視モジュールに異常報告を個別に行なう請求項１記載の自動車用制御ユニット。
3. 前記駆動管理モジュール、前記中継モジュール、前記駆動モジュール及び前記異常監視モジュールを、予め定められた時系列順序にて周期的に実行する請求項１又は請求項２に記載の自動車用制御ユニット。
4. 前記異常監視モジュールは、異常発生時に前記通信ソフトウェアの動作をスリープ状態に移行させるスリープ指示を行なう請求項１ないし請求項３のいずれか１項に記載の自動車用制御ユニット。
5. 前記駆動管理モジュール、前記中継モジュール及び前記駆動モジュールがこの順序にて周期的に実行されるとともに、前記異常監視モジュールは、前記駆動管理モジュール、前記中継モジュール及び前記駆動モジュールのいずれかから異常発生通知を受けることにより、それら駆動管理モジュール、中継モジュール及び駆動モジュールの全てにスリープ指令を行ない、制御ユニットハードウェアのスリープ設定を行なう請求項４記載の自動車用制御ユニット。
6. 前記アプリケーション状態管理手段が行なう前記状態遷移処理に伴い、遷移により設定された制御状態が制御状態特定情報の形で制御状態メモリに記憶され、
   前記駆動管理モジュールは、前記制御状態メモリの記憶内容に基づいて前記アプリケーション側の異常判定を行ない、前記異常監視モジュールに異常発生報告を行なう請求項１ないし請求項５のいずれか１項に記載の自動車用制御ユニット。
7. 前記制御状態メモリには、前記状態遷移が発生するたびに、制御状態特定情報とともに、そのミラー情報が記憶され、前記駆動管理モジュールは、該制御状態特定情報と該ミラー情報とを照合し、その照合結果に基づいて異常判定を行なう請求項６記載の自動車用制御ユニット。
   

Images