JP2011002993A - ウォッチドックタイマ監視装置、ウォッチドックタイマ監視方法 - Google Patents

Abstract

【課題】ＣＰＵを個別に低電力モードにしても、ＣＰＵの異常を正確に検出できるマルチプロセッサシステムのウォッチドックタイマ監視装置及びウォッチドックタイマ監視方法を提供すること。
【解決手段】各ＣＰＵが個別に低電力モードに移行するマルチプロセッサシステムのウォッチドックタイマ監視装置１００であって、各ＣＰＵ毎に、プログラムが動作していることを示す動作状態情報を更新しながら記憶する動作状態記憶手段１４と、動作状態記憶手段に動作状態情報が記憶されている場合、ウォッチドッグタイマ１２をリセットするリセット手段１３と、各ＣＰＵ毎に、低電力モードであることを示す低電力モード状態情報を記憶するモード記憶手段１５と、を有し、モード記憶手段に低電力モード状態情報が記憶されている場合、リセット手段は、動作状態記憶手段に動作状態情報が記憶されていなくても、ウォッチドッグタイマをリセットする、ことを特徴とする。
【選択図】図６

Description

本発明は、マルチプロセッサシステムのウォッチドックタイマ監視装置等に関し、特に、各ＣＰＵ毎に、低電力モードに入っても、マルチプロセッサシステムを監視可能なウォッチドックタイマ監視装置及びウォッチドックタイマ監視方法に関する。

ＣＰＵの異常を検出する手段としてウォッチドッグタイマが知られている。ウォッチドッグタイマは、クロック信号をカウントしてカウンタがオーバフローするとＣＰＵをリセットすることで、ＣＰＵを初期化する等の異常ルーチンを実行する（例えば、特許文献１参照。）。また、ＣＰＵは消費電力の低減のためクロック信号の供給を停止又はクロック信号を遅くするスタンバイモードを有するが、スタンバイモードではウォッチドッグタイマへのクロック供給も停止されるため、スタンバイモードではＣＰＵの異常を検出することが困難とされている。

ところで、車両には多くの電子制御ユニット（以下、ＥＣＵという）が搭載されているが、搭載するＥＣＵの数と処理性能が共に増大し、ＥＣＵの増加と消費電力の増加がコストアップ要因となっている。このため、複数のＥＣＵの機能を統合することでＥＣＵの数及びコストの低減化が進められており、機能を統合するために１つのＥＣＵにマルチコアＣＰＵ又は仮想ＣＰＵを搭載することが検討されている。マルチコアＣＰＵ又は仮想ＣＰＵにおいても、消費電力を低減するには、動作の不要なＣＰＵ又は仮想ＣＰＵをスタンバイモードにすることが有効である。

一方、機能が統合されると、ＥＣＵの信頼性を確保する技術、信頼性の向上技術が益々重要になるが、マルチプロセッサシステムにおいてウォッチドッグタイマでＣＰＵの異常を検出することが提案されている（例えば、特許文献２参照。）。特許文献２記載のマルチプロセッサシステムは、ＣＰＵ毎にカウンタをリセットするフラグと、各ＣＰＵで実行されフラグを設定する監視プログラムと、１つのウォッチドッグタイマとを有する。監視プログラムは、自分のフラグを設定すると共に、他のＣＰＵが設定したフラグの状態を監視し、フラグの数がＣＰＵの数に等しいか否かに基づき複数のＣＰＵのいずれかに異常が生じていると判定する。すなわち、１つのウォッチドッグタイマで各ＣＰＵの異常を検出する。

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

しかしながら、特許文献２記載のマルチプロセッサシステムは、各ＣＰＵが個別にスタンバイモードに入った場合の異常検出が考慮されておらず、結果的に、ＣＰＵが個別にスタンバイモードに入ることができず、消費電力の低減が困難であるという問題がある。図を用いて説明する。

図１は、特許文献２記載のウォッチドッグタイマのカウント値を模式的に示す図の一例である。監視プログラム１〜３は、ＣＰＵ１〜３がそれぞれ実行する監視プログラムである。監視プログラム１〜３が正常に動作している場合、監視プログラム１〜３がフラグ１〜３をセットするため、カウンタリセット要求がオンになり、ＷＤＴカウント値もリセットされる。しかし、例えば、ＣＰＵ１、３をスタンバイモードにした場合、監視プログラム２が検出するフラグの数（例えば１になる）とＣＰＵの数（３つ）が一致しないので、カウンタリセット要求がオンにならず、タイムアウトしてしまう。

また、特許文献２には、監視するＣＰＵの数を設定できる旨の記載がある。しかしながら、特許文献２記載の方法では、各ＣＰＵが監視するＣＰＵの数を共有しなければならないという不都合がある。

図２は、特許文献２記載のウォッチドッグタイマのカウント値を模式的に示す図の一例である。例えば、２つのＣＰＵを監視する設定の場合、監視プログラム２，３が２つのフラグがオンであることを検出できればよい。しかしながら、特許文献２記載の方法では、監視プログラム２，３が、ＣＰＵ１がスタンバイモードであることを検知する必要があるため、各ＣＰＵが動的にスタンバイモードになった場合には、それを互いに通知する手段が必要になる。例えば、ＣＰＵ１がスタンバイモードの間に、ＣＰＵ２がスタンバイモードになった場合、ＣＰＵ１がスタンバイモードを解除すると、監視プログラム１はＣＰＵ２を監視対象とするか否か判定できない。このように、特許文献２記載の異常検出方法では、ＣＰＵ１〜３を動的にスタンバイモードにした場合、正確に異常を検出することが困難である。

車両では、駐車中もいくつかの機能が動作する必要があり、統合ＥＣＵのように複数のＣＰＵを搭載した場合は、ＣＰＵを動的にスタンバイモードにできないと、駐車中にバッテリ残量が低下してしまう。このため、ＥＣＵの異常を検出する場合、マルチコアＣＰＵ又は複数の仮想ＣＰＵが、動的にスタンバイモードになっても、信頼性を保証することが要請される。

本発明は、上記課題に鑑み、ＣＰＵを動的に低電力モードにしても、ＣＰＵの異常を正確に検出できるマルチプロセッサシステムのウォッチドックタイマ監視装置及びウォッチドックタイマ監視方法を提供することを目的とする。

上記課題に鑑み、本発明は、各ＣＰＵが個別に低電力モードに移行するマルチプロセッサシステムのウォッチドックタイマ監視装置であって、各ＣＰＵ毎に、プログラムが動作していることを示す動作状態情報を更新しながら記憶する動作状態記憶手段と、動作状態記憶手段に前記動作状態情報が記憶されている場合、ウォッチドッグタイマをリセットするリセット手段と、各ＣＰＵ毎に、低電力モードであることを示す低電力モード状態情報を記憶するモード記憶手段と、を有し、モード記憶手段に低電力モード状態情報が記憶されている場合、リセット手段は、動作状態記憶手段に前記動作状態情報が記憶されていなくても、ウォッチドッグタイマをリセットする、ことを特徴とする。

ＣＰＵを個別に低電力モードにしても、ＣＰＵの異常を正確に検出できるマルチプロセッサシステムのウォッチドックタイマ監視装置及びウォッチドックタイマ監視方法を提供することができる。

ウォッチドッグタイマのカウント値を模式的に示す図の一例である（従来図）。 ウォッチドッグタイマのカウント値を模式的に示す図の一例である（従来図）。 ＷＤＴ監視装置がウォッチドッグタイマのオーバフローを検出する手順の一例を示すフローチャート図である。 ＷＤＴ監視装置の概略構成図の一例である。 各ＣＰＵ１〜３がスタンバイモードに入る手順を示すフローチャート図の一例である。 スタンバイフラグ１〜３及びリセットフラグ１〜３の状態の組み合わせによるＷＤＴのリセット判定を模式的に示す図の一例である。 ウォッチドッグタイマのカウント値を模式的に示す図の一例である。 タイムアウト時間とスタンバイモード時間の関係を模式的に示す図の一例である。 ＷＤＴ監視装置の概略構成図の一例である（実施例２）。 ＣＰＵ１〜３がスタンバイモードに入る手順を示すフローチャート図の一例である（実施例２）。 イネーブルフラグ１〜３、スタンバイフラグ１〜３及びリセットフラグ１〜３の状態の組み合わせによるＷＤＴのリセット判定を模式的に示す図の一例である。 ＷＤＴのカウント値を模式的に示す図の一例である。

以下、本発明を実施するための最良の形態について図面を参照しながら実施例を挙げて説明する。

〔ＷＤＴ監視装置１００の概略〕
図３は、マルチプロセッサシステムのＷＤＴ監視装置１００がウォッチドッグタイマ（以下、ＷＤＴ１２という）のオーバフローを検出する手順の一例を示すフローチャート図である。マルチプロセッサは、例えば３つのＣＰＵを有し、それぞれが個別にスタンバイモードになることができる。ＷＤＴ監視装置１００は、ＣＰＵ毎に、ＷＤＴ１２をリセットするリセットフラグを有する（Ｓ２）。リセットフラグがオンでないことはそのＣＰＵに異常が生じていることを示す（Ｓ３）。ＷＤＴ監視装置１００は、１以上のＣＰＵに異常が発生すると、ＷＤＴ１２をタイムアウトさせ（Ｓ５）、異常のＣＰＵが１つもなければ、ＷＤＴ１２をリセットする（Ｓ６）。

このようなＷＤＴ監視装置１００において、本実施例では、ＣＰＵがスタンバイモードの場合（Ｓ１のＹｅｓ）、リセットフラグがオンであるとみなすことで、そのＣＰＵを監視対象から除外する。こうすることで、スタンバイモードのＣＰＵから異常検出されることを防止できる（Ｓ３）。したがって、マルチプロセッサシステムの各ＣＰＵをＣＰＵ毎にスタンバイモードにしても、ＷＤＴ１２がタイムアウトすることを防止できる。また、各ＣＰＵは、他のＣＰＵがスタンバイモードか否か関わらずに独立して異常を検出するので、各ＣＰＵは他のＣＰＵがスタンバイモードか否かを判定する必要もない。

なお、スタンバイモードとは、ＣＰＵ１〜３の全体に全く動作クロック及び電力が供給されない状態、ＣＰＵ１〜３の一部の回路に動作クロック及び電力が供給されない状態、又は、ＣＰＵ１〜３の全体若しくは一部の回路に供給される動作クロックの周波数が低減される状態、のいずれであってもよい。

〔ハードウェア構成〕
図４は、マルチプロセッサシステムのＷＤＴ監視装置１００の概略構成図の一例を示す。マルチプロセッサシステムは３つのＣＰＵ１〜３を有し、それぞれスタンバイ状態テーブル１５、リセットフラグテーブル１４、及び、ＷＤＴリセット信号生成部１３と接続されている。また、ＣＰＵ１〜３は、それぞれのスタンバイモードを制御するスタンバイ制御部１〜３、及び、クロック信号を供給するＣＬＫジェネレータ１〜３と接続されている。

なお、図４では、各ＣＰＵ１〜３が実在するＣＰＵとして記載されているが、ＣＰＵ１〜３のいずれか又は全てが仮想ＣＰＵであってもよい。仮想ＣＰＵとは、例えば、ハードウェアにより複数のスレッドを切り替えて実行可能な物理ＣＰＵにおける各スレッドを言う。物理ＣＰＵは、スレッド毎にプログラムカウンタ、命令バッファ、レジスタファイル、等を有し、演算回路を時分割して利用する。プログラムカウンタ等が独立しているため、演算回路を共有してもオーバーヘッドを最小にして、各スレッドが独立して各プログラムの命令を実行することができる。１つのスレッドが１つの仮想ＣＰＵに相当する。仮想ＣＰＵの場合、例えばレジスタファイルにスタンバイフラグ１〜３とリセットフラグ１〜３を確保すればよく、本実施例のＷＤＴ監視装置１００を好適に適用できる。

スタンバイ状態テーブル１５とリセットフラグテーブル１４は、ＣＰＵ１〜３の数以上の記憶素子（例えば、レジスタ、フリップフロップ、ラッチ回路等）を有する。スタンバイ状態テーブル１５はスタンバイフラグ１〜３がオンかオフかを記憶できればよく、リセットフラグテーブル１４はリセットフラグ１〜３がオンかオフかを記憶できればよいので、１つの記憶素子は１ビットあればよい。ＣＰＵ１はスタンバイフラグ１及びリセットフラグ１を、ＣＰＵ２はスタンバイフラグ２及びリセットフラグ２を、ＣＰＵ３はスタンバイフラグ３及びリセットフラグ３を、それぞれオン又はオフに操作することができる。

なお、スタンバイフラグ１〜３は、オン（１）の場合にそのＣＰＵ１〜３がスタンバイモードであることを示し、リセットフラグ１〜３はオン（１）である場合にＣＰＵ１〜３が正常に動作していることを示す。

ＷＤTリセット信号生成部１３は、ＣＰＵ１〜３の全てが正常な場合にリセット信号を生成してＷＤＴ１２に供給し、ＣＰＵ１〜３のいずれか１以上が正常でない場合にリセット信号を生成しない。リセット信号の生成については後に詳述する。なお、ＷＤＴ１２には、ＣＰＵ１〜３の１以上が動作している場合（ＣＰＵ１〜３の全てがスタンバイモードでない場合）、動作クロックが供給される。ＷＤＴ１２に供給される動作クロックの周波数は、ＣＰＵ１〜３と同じでもよいし、より小さい周波数でもよい。

ＣＰＵ１〜３の全てが正常であれば、ＷＤTリセット信号生成部１３がリセット信号をＷＤＴ１２に供給するので、ＷＤＴ１２がタイムアウトしない。一方、ＷＤTリセット信号生成部１３が、予め定められた時間（タイムアウト時間）内にリセット信号をＷＤＴ１２に供給しない場合、ＷＤＴ１２がタイムアウトすることでタイムアウト処理部１１にタイムアウト時の処理を要求する。タイムアウト処理部１１は、例えば、ＣＰＵ１〜３の再起動信号を生成する回路であってもよいし、ＣＰＵ１〜３の全てのＯＳにソフトウェア割り込みを要求する回路であってもよい。後者の場合、ＯＳがＣＰＵ１〜３の再起動に必要なＲＡＭやレジスタ、アプリケーションのパラメータを退避させた後、再起動するなどの手法を採用できる。

スタンバイ制御部１〜３は、ＣＰＵ１〜３の要求に応じてＣＬＫジェネレータ１〜３がＣＰＵ１〜３に供給するクロック信号を停止又はクロック信号の周波数を遅くする。すなわち、クロックゲーティングによりスタンバイモード時の消費電力を低減する。スタンバイ制御部１〜３は、ＣＰＵ１〜３の全体にクロックゲーティングしてもよいし、長期間使用されていない個別の回路へクロックゲーティングしてもよい。クロックゲーティングする回路はＣＰＵ１〜３により選定される。また、スタンバイ制御部は、ＣＰＵ１〜３の要求に応じて、ＣＰＵ１〜３の全体又は個別の回路へ供給される電力を停止してもよい（パワーゲーティング）。こうすることで、リーク電流を防止でき、クロックゲーティングのみで低消費電力するよりも更に消費電力を低減できる。

〔スタンバイモードになるアプリケーションプログラム〕
各ＣＰＵ１〜３は、アプリケーションプログラム（以下、単に「プログラム」という）を実行することで実現されるスタンバイフラグ設定部１〜３、リセットフラグ設定部１〜３、及び、スタンバイ要求部１〜３を有する。

ＣＰＵ１〜３がスタンバイモードになるプログラムは、例えば駐車中に使用されるものである。駐車中の車両は、例えばバッテリ残量を監視したり、キーレスエントリーシステムが検出エリアに進入した電子キーを監視している。バッテリ残量は、駐車中に急激に変動することは少ないので、長いターム（例えば、数秒から数時間）毎に監視すればよく、電子キーは１秒程度の間隔で検出しても、車両に接近した運転者に違和感を与えることは少ない。したがって、それぞれのプログラムに好適なサイクルで、スタンバイ要求部１〜３を呼び出す。呼び出されたスタンバイ要求部１〜３は、スタンバイ制御部１〜３に、ＣＰＵ１〜３をスタンバイモードとするよう要求する。スタンバイ制御部１〜３は、上記の方法でＣＰＵ１〜３をスタンバイモードに設定する。こうすることで、駐車中の消費電力を低減できる。

例えば、バッテリ残量を監視するプログラムのスタンバイ要求部１〜３は、ＩＧ及びアクセサリがオフになり、予め定められた所定時間が経過するとプログラムを実行するＣＰＵ１〜３をスタンバイモードに設定するようスタンバイ制御部１〜３に要求する。また、スタンバイ要求部１〜３は、スタンバイフラグ設定部１〜３にスタンバイフラグ１〜３の操作を要求する。スタンバイフラグ設定部１〜３は、スタンバイモードに入る直前、入る時、又は、入った直後、スタンバイフラグ１〜３をオンに操作する。これにより、ＣＰＵ１〜３がスタンバイモードになると、ＷＤＴ１２の監視対象から除外することができる。

また、スタンバイモードに入る前に、スタンバイ要求部１〜３はタイマを設定しておく。そして、ＣＰＵ１〜３は、タイマ割込みが発生すると、スタンバイモードを解除してプログラムを実行する。

プログラムがキーレスエントリーシステムの場合も同様である。すなわち、ドアロックされてから、予め定められた所定時間が経過すると、プログラムを実行するＣＰＵ１〜３をスタンバイモードに設定するようスタンバイ制御部１〜３に要求する。また、スタンバイ要求部１〜３は、スタンバイフラグ設定部１〜３にスタンバイフラグ１〜３の操作を要求する。また、スタンバイモードに入る前に、スタンバイ要求部１〜３はタイマを設定しておく。

なお、スタンバイモードの解除はタイマ割込みに限られず、乗員の操作、ＩＧオン、アクセサリオン、携帯電話網等を介した通信の発生等によっても、スタンバイモードは解除される。

また、スタンバイモードの解除によりプログラムが再起動すると、例えばＭＡＩＮ関数からスタンバイフラグ設定部１〜３が呼び出され、スタンバイフラグ設定部１〜３はスタンバイフラグ１〜３をオフに操作する。スタンバイモードの解除時に、ＣＰＵ１〜３に再起動信号が入力される場合、スタンバイフラグも自動的に初期化（オフ）されるので、この場合、プログラムが起動した後、スタンバイフラグ設定部１〜３がスタンバイフラグをオフに操作する必要はない。

一方、スタンバイモードでない（起動中の）ＣＰＵ１〜３は、タイムアウト時間よりも充分に短い時間間隔でリセットフラグ１〜３をオンに操作する。オン操作のタイミングはプログラムに記述されている。例えば、タイムアウト時間の１／１０〜１／２程度の時間が経過する毎に、プログラムはリセットフラグ設定部１〜３を呼び出す。リセットフラグ設定部１〜３は、リセットフラグ１〜３をオンに操作して、プログラムに制御を戻す。

図５は、各ＣＰＵ１〜３がスタンバイモードに入る手順を示すフローチャート図の一例である。スタンバイモードに入る前、各ＣＰＵ１〜３は、ＯＳ及びプログラムを実行している。図５のフローチャート図は、各ＣＰＵ１〜３が独立に実行する。

プログラムは、実行しているＣＰＵ１〜３のいずれかをスタンバイモードに設定するタイミングか否かを判定する（Ｓ１０）。スタンバイモードに設定するタイミングでない場合（Ｓ１０のＮｏ）、このＣＰＵ１〜３はＷＤＴ１２の監視対象となるので、タイムアウトしないように、リセットフラグ設定部１〜３がリセットフラグ１〜３をオンに操作する（Ｓ２０）。その後、リセットフラグ１〜３を再度、オン操作するタイミングとなるまで、リセットフラグ設定部１〜３はスケジュール待ちとなるが（Ｓ３０）、その間、プログラムが必要な処理を実行する場合もある。

ステップＳ１０に戻り、スタンバイモードに設定するタイミングになった場合（Ｓ１０のＹｅｓ）、スタンバイフラグ設定部１〜３が呼び出され、スタンバイフラグ設定部１〜３はスタンバイフラグ１〜３をオン操作する（Ｓ４０）。

また、スタンバイ要求部１〜３は、スタンバイ制御部１〜３にＣＰＵ１〜３をスタンバイモードに設定するよう要求する。これにより、ＣＰＵ１〜３はスタンバイモードに入る（Ｓ５０）。スタンバイモードに入ったＣＰＵ１〜３は、クロック信号や電力供給が低減されるので消費電力を低減できる。すなわち、ＣＰＵ１〜３毎に消費電力を低減できることになる。

スタンバイモードに入ったＣＰＵ１〜３は、スタンバイモードの間、スタンバイモードを解除するか否かを判定する（Ｓ６０）。具体的には、タイマ割込み、乗員の操作、センサの信号検出による再起動信号が入力されたか否かを判定する。

スタンバイモードを解除する場合（Ｓ６０のＹｅｓ）、プログラムから呼び出されたスタンバイフラグ設定部１〜３はスタンバイフラグ１〜３をオフに操作する（Ｓ７０）。これにより、ＣＰＵ１〜３はＷＤＴ１２の監視対象となる。ＣＰＵ１〜３がプログラムの実行を再開することで、各ＣＰＵ１〜３はバッテリ監視やドアのアンロック等の処理を再開する。各ＣＰＵ１〜３は、以上の処理を繰り返す。

〔ＷＤＴ１２のリセット判定〕
図６は、スタンバイフラグ１〜３及びリセットフラグ１〜３の状態の組み合わせによるＷＤＴ１２のリセット判定を模式的に示す図の一例である。図示するように、スタンバイフラグ１とリセットフラグ１がＯＲ回路１に、スタンバイフラグ２とリセットフラグ２がＯＲ回路２に、スタンバイフラグ３とリセットフラグ３がＯＲ回路３に、それぞれ接続されている。また、ＯＲ回路１〜３の出力がＡＮＤ回路２１に接続されている。ＡＮＤ回路２１の出力がＷＤＴ１２に接続されている。ＯＲ回路１〜３とＡＮＤ回路２１は、スタンバイフラグ１〜３とリセットフラグ１〜３の状態に応じて、リセット信号を生成する。しがたって、ＯＲ回路１〜３とＡＮＤ回路２１は、ＷＤTリセット信号生成部１３を論理回路で表したものである。ＡＮＤ回路２１が「１」を出力することが、ＷＤTリセット信号生成部１３がリセット信号を出力することに対応する。

ＯＲ回路１〜３は、スタンバイフラグ１〜３又はリセットフラグ１〜３のどちらかがオンであれば、「１」を出力する。例えば、ＣＰＵ１〜３がスタンバイモードでない場合、リセットフラグ設定部１〜３が定期的にリセットフラグ１〜３をオンに操作するので、スタンバイフラグ１〜３がオンでなくても、ＯＲ回路１〜３は「１」を出力する。同様に、ＣＰＵ１〜３がスタンバイモードであり、スタンバイフラグ１〜３がオンの場合、リセットフラグ１〜３の状態に関係なく、ＯＲ回路１〜３は「１」を出力する。これにより、ＡＮＤ回路２１は「１」を出力する。なお、ＡＮＤ回路２１の出力はリセットフラグ１〜３をオフに操作する信号として、リセットフラグ１〜３に入力される。

したがって、ＣＰＵ１〜３がスタンバイモードの場合、そのＣＰＵ１〜３はＷＤＴ１２の監視対象から除外できる。また、スタンバイモードになったＣＰＵ１〜３を他のＣＰＵ１〜３が把握しておくことも必要ない。換言すると、ＣＰＵ１〜３がスタンバイモードでなく、かつ、プログラムが暴走するなどＣＰＵ１〜３に異常が生じたためリセットフラグ１〜３がオンに操作されない場合にのみ、ＯＲ回路１〜３が「１」を出力しないことになる。ＡＮＤ回路２１は、ＯＲ回路１〜３が全て「１」を出力しないと「１」を出力しないので、１つのＷＤＴ１２で全てのＣＰＵ１〜３を監視できる。

図７は、WDT１２のカウント値を模式的に示す図の一例である。スタンバイフラグ１〜３に示すように、時刻ｔ１までＣＰＵ１〜３はスタンバイモードに入っていない。また、プログラムは時刻ｔ１までいずれも暴走することなく実行されており、リセットフラグ設定部１〜３は、リセットフラグ１〜３のオン操作のタイミングになると、リセットフラグ１〜３をオンに操作する。この結果、ＡＮＤ回路が「１」を出力し（ＷＤTリセット信号生成部１３がリセット信号を出力し）、時刻ｔ１にＷＤＴ１２がリセットされている。

一方、時刻ｔ２にはＣＰＵ１がスタンバイモードに入っている。このため、ＣＰＵ１はＷＤＴ１２の監視対象から除外される。そして、時刻ｔ２以降、ＣＰＵ３に異常が生じた。この結果、リセットフラグ３がオンに操作されない。このため、ＯＲ回路１，２からは「１」が出力されるが、ＯＲ回路３からは「１」が出力されないことになり、ＡＮＤ回路２１が「１」を出力することができない。すなわち、ＷＤTリセット信号生成部１３はＷＤＴ１２にリセット信号を出力できず、時刻ｔ３にＷＤＴ１２がタイムアウトしている。

以上説明したように、本実施例のＷＤＴ監視装置１００は、マルチプロセッサシステムのＣＰＵ１〜３を個別にスタンバイモードに設定することで消費電力を低減でき、スタンバイモードに入ったＣＰＵを監視対象から除外できる。

本実施例では、ＣＰＵ１〜３毎に、スタンバイモードの間もＷＤＴ１２の監視対象にするか否かを設定できるＷＤＴ監視装置１００について説明する。

図８は、タイムアウト時間とスタンバイモード時間の関係を模式的に示す図の一例である。図８（ａ）では、スタンバイモード時間がタイムアウト時間よりも長い。スタンバイモードの間、実施例１ではリセットフラグ設定部１〜３がリセットフラグ１〜３をオンに操作しないので、スタンバイモードのＣＰＵ１〜３を監視対象にすると、ＷＤＴ１２がタイムアウトしてしまう。したがって、図８（ａ）のようなプログラムの実行態様であれば、スタンバイモードの間、ＣＰＵ１〜３を監視対象から除外すればよい。

図８（ｂ）では、タイムアウト時間よりもスタンバイモード時間の方が短い。したがって、このような実行態様のプログラムであれば、スタンバイモードの間、ＣＰＵ１〜３を監視対象にしても、ＷＤＴ１２はタイムアウトしない。また、スタンバイモードの間、ＣＰＵ１〜３を監視対象から除外しても、実行時間の方が圧倒的に長いので、プログラムの実行中にＣＰＵ１〜３の異常を検出できると考えられる。したがって、図８（ｂ）のようなプログラムの実行態様であれば、スタンバイモードの間、ＣＰＵ１〜３を監視対象から除外してもよいし、しなくてもよい。

図８（ｃ）では、スタンバイモード時間がタイムアウト時間よりも長く、かつ、プログラムの実行時間がタイムアウト時間よりも短い。したがって、スタンバイモードの間、監視対象にすると、ＣＰＵ１〜３に異常が発生していなくても、ＷＤＴ１２がタイムアウトしてしまう。また、ＣＰＵ１〜３に異常が生じていても、実行時間内にＷＤＴ１２がタイムアウトしないので、ＣＰＵ１〜３を監視することが困難になる。したがって、図８（ｃ）のようなプログラムの実行態様であれば、スタンバイモードの間、ＣＰＵ１〜３を監視対象から除外しないことが好ましい。しかしながら、スタンバイモードの間、ＷＤＴ１２がタイムアウトしてしまうので、何らかの対処が必要である。

図８（ｄ）では、スタンバイモード時間がタイムアウト時間よりも短く、かつ、プログラムの実行時間がタイムアウト時間よりも短い。このような実行態様のプログラムでは、ＣＰＵ１〜３に異常が生じていても、実行時間内にＷＤＴ１２がタイムアウトしないので、ＣＰＵ１〜３を監視することが困難になる。一方、スタンバイモードの間、ＣＰＵ１〜３を監視対象にしても、ＷＤＴ１２はタイムアウトしない。したがって、したがって、図８（ｄ）のようなプログラムの実行態様であれば、スタンバイモードの間、ＣＰＵ１〜３を監視対象から除外しないことが好ましい。

以上から、図８（ｃ）及び図８（ｄ）のようなプログラムの実行態様では、スタンバイモードでもＣＰＵ１〜３を監視対象にする。こうすることで、図８（ｃ）（ｄ）のように、実行時間がタイムアウト時間よりも短い実行態様でも、ＣＰＵ１〜３の異常を検出できる。

また、図８（ｃ）のように、スタンバイモード時間がタイムアウト時間よりも長い実行態様では、スタンバイモード中に、定期的にリセットフラグ設定部１〜３を立ち上げリセットフラグ１〜３をオンに操作する。こうすることで、スタンバイモード中に、ＷＤＴ１２がタイムアウトすることを防止でき、かつ、プログラムの実行時間が短くてもスタンバイモードの間と実行時間のいずれもでもＣＰＵ１〜３を監視することができる。

図９は、マルチプロセッサシステムのＷＤＴ監視装置１００の概略構成図の一例を示す。図９において図４と同一部には同一の符号を付しその説明は省略する。図９のＣＰＵ１〜３はそれぞれイネーブルフラグテーブル１６と接続されている。イネーブルフラグテーブル１６はオンかオフかを記憶する記憶素子である。ＣＰＵ１〜３が有するイネーブルフラグ設定部１〜３は、イネーブルフラグ１〜３をそれぞれオン又はオフに操作する。イネーブルフラグ１〜３は、オン（１）の場合にスタンバイモードのＣＰＵ１〜３を監視対象としないことを示し、オフ（０）である場合にスタンバイモードのＣＰＵ１〜３を監視対象とすることを意味する。

プログラムの実行態様に応じてイネーブルフラグ１〜３をオンにするか否かは決まっている。イネーブルフラグ設定部１〜３は、予めプログラムに記述されたパラメータに従いイネーブルフラグ１〜３をオン又はオフに操作する。また、本実施例のリセットフラグ設定部１〜３は、スタンバイモードの間もリセットフラグ１〜３をオンに操作することができる。この場合、プログラムを立ち上げてプログラムのＭＡＩＮ関数からリセットフラグ設定部１〜３を呼び出してもよいし、リセットフラグ設定部１〜３だけを起動させてもよい。後者のようなリセットフラグ設定部１〜３は、例えば、タイマにリセットフラグ１〜３をオン操作する間隔である時間を設定し、タイマがゼロになる度に立ちがありリセットフラグ１〜３をオンにする監視用のプログラムとして実現できる。

また、本実施例のスタンバイ制御部１〜３は、プログラムの実行態様に応じて、スタンバイモードの実現方法を変えることができる。すなわち、図８（ｂ）（ｄ）のようにスタンバイモード時間が短いＣＰＵ１〜３では、クロックゲーティングによりスタンバイモードに入り、図８（ａ）（ｃ）のようにスタンバイモード時間が長いＣＰＵ１〜３ではパワーゲーティングによりスタンバイモードに入る。こうすることで、プログラムの実行態様に応じて、きめ細かな省電力制御が可能となる。なお、スタンバイ要求部１〜３は、プログラムの実行態様に応じて、好ましいスタンバイの実現方法をスタンバイ制御部１〜３に通知する。

図１０は、各ＣＰＵ１〜３がスタンバイモードに入る手順を示すフローチャート図の一例である。図１０において図５と同一ステップには同一の符号を付しその説明は省略する。本実施例では、ＣＰＵ１〜３がプログラムを実行すると、適当なタイミングでイネーブルフラグ設定部１〜３を呼び出し、イネーブルフラグ設定部１〜３がイネーブルフラグ１〜３をオン又はオフに操作する（Ｓ５）。オンに操作するか、オフに操作するかは、プログラム毎に決まっている。

例えば、図８（ａ）のような実行態様のＣＰＵ１〜３では、イネーブルフラグ１〜３はオンに操作される。図８（ｂ）〜（ｄ）のような実行態様のＣＰＵ１〜３では、イネーブルフラグ１〜３はオフに操作される。

以降の処理（ステップＳ１０〜Ｓ５０の処理）は実施例１と同様である。ステップＳ５０でスタンバイモードに入ると、ＣＰＵ１〜３は、クロック信号や電力供給が低減されるので消費電力を低減できる。すなわち、ＣＰＵ１〜３毎に消費電力を低減できることになる。

そして、リセットフラグ設定部１〜３は、イネーブルフラグ１〜３がオフに操作され、スタンバイモードでも監視対象のままのＣＰＵ１〜３について、スタンバイモードの間もタイムアウト時間よりも短い時間間隔で、リセットフラグ１〜３をオンに操作する（Ｓ５５）。こうすることで、図８（ｃ）のように、スタンバイモード時間が長く、実行時間が短いプログラムの暴走を検出することができる。以降の処理は実施例１と同様である。

〔ＷＤＴ１２のリセット判定〕
図１１は、イネーブルフラグ１〜３、スタンバイフラグ１〜３及びリセットフラグ１〜３の状態の組み合わせによるＷＤＴ１２のリセット判定を模式的に示す図の一例である。図１１において図６と同一部には同一の符号を付しその説明は省略する。図示するように、イネーブルフラグ１とスタンバイフラグ１がＡＮＤ回路１に、イネーブルフラグ２とスタンバイフラグ２がＡＮＤ回路２に、イネーブルフラグ３とスタンバイフラグ３がＡＮＤ回路３に、それぞれ接続されている。ＡＮＤ回路１の出力とリセットフラグ１がＯＲ回路１に、ＡＮＤ回路２の出力とリセットフラグ２がＯＲ回路２に、ＡＮＤ回路３の出力とリセットフラグ３がＯＲ回路３に、それぞれ接続されている。また、ＯＲ回路１〜３の出力がＡＮＤ回路２１に接続されている。ＡＮＤ回路２１の出力がＷＤＴ１２に接続されている。ＡＮＤ回路１〜３、ＯＲ回路１〜３及びＡＮＤ回路２１は、ＷＤTリセット信号生成部１３を論理回路で表したものである。ＡＮＤ回路２１が「１」を出力することが、ＷＤTリセット信号生成部１３がリセット信号を出力することに対応する。

スタンバイフラグ１〜３がオン、かつ、イネーブルフラグ１〜３がオンの場合、ＡＮＤ回路１〜３が「１」を出力する。イネーブルフラグ１〜３がオフの場合、スタンバイフラグ１〜３がオンでも、ＡＮＤ回路１〜３は「１」を出力しないので、リセットフラグ１〜３がオンにならない限り、リセット要求が出力されない。したがって、イネーブルフラグ１〜３をオフに操作しておくことで、リセットフラグ１〜３の状態に基づき、スタンバイモードの間、ＣＰＵ１〜３を監視することができる。

図１２は、ＷＤＴ１２のカウント値を模式的に示す図の一例である。イネーブルフラグ１〜３に示すように、ＣＰＵ１はスタンバイモードの間、ＷＤＴ１２の監視対象から除外され、ＣＰＵ２，３はスタンバイモードの間、ＷＤＴ１２の監視対象である。ＣＰＵ１は時刻ｔ４からスタンバイモードになり、ＣＰＵ２は時刻ｔ２から時刻ｔ５までの間と、時刻ｔ６からスタンバイモードになる。ＣＰＵ３はスタンバイモードにならない。

ＣＰＵ１〜３で実行されるプログラムは、いずれも時刻ｔ３まで暴走することなく実行されており、リセットフラグ設定部１〜３は、リセットフラグ１〜３のオン操作のタイミングになると、リセットフラグ１〜３をオンに操作する。この結果、ＡＮＤ回路が「１」を出力し（ＷＤTリセット信号生成部１３がリセット信号を出力し）、時刻ｔ３にＷＤＴ１２がリセットされている。

時刻ｔ３の後、ＣＰＵ１は時刻ｔ４にスタンバイモードに入るが、ＣＰＵ１はＷＤＴ１２の監視の対象外であり、ＡＮＤ回路１が「１」を出力するので、ＯＲ回路１は「１」を出力する。また、ＣＰＵ３はスタンバイモードに入らないが、プログラムが暴走することなく、リセットフラグ設定部３がリセットフラグ３をオンに操作している。このため、ＯＲ回路３は「１」を出力する。これに対し、ＣＰＵ２はスタンバイモードの間、監視対象であるが、スタンバイモードの間又は実行中に異常をきたしリセットフラグ設定部２がリセットフラグ２をオンに操作できなかった。このため、ＡＮＤ回路２も「１」を出力することなくリセットフラグ２もオンにならず、ＯＲ回路２が「１」を出力しないことになる。この結果、ＡＮＤ回路２１は「１」を出力することができないので（ＷＤTリセット信号生成部１３はＷＤＴ１２にリセット信号を出力できないので）、時刻ｔ７にＷＤＴ１２がタイムアウトしている。

以上説明したように、本実施例のＷＤＴ監視装置１００は、スタンバイモードにおいても、プログラムの実行態様に応じては監視対象に含めることで、特にスタンバイモード時間が短いＣＰＵ１〜３の異常を確実に検出することができる。

１１ タイムアウト処理部
１２ ウォッチドックタイマ（ＷＤＴ）
１３ ＷＤＴリセット信号生成部
１４ リセットフラグテーブル
１５ スタンバイ状態テーブル
１６ イネーブルフラグテーブル
２１ ＡＮＤ回路

Claims (5)

1. 各ＣＰＵが個別に低電力モードに移行するマルチプロセッサシステムのウォッチドックタイマ監視装置であって、
   各ＣＰＵ毎に、プログラムが動作していることを示す動作状態情報を更新しながら記憶する動作状態記憶手段と、
   前記動作状態記憶手段に前記動作状態情報が記憶されている場合、ウォッチドッグタイマをリセットするリセット手段と、
   各ＣＰＵ毎に、低電力モードであることを示す低電力モード状態情報を記憶するモード記憶手段と、を有し
   前記モード記憶手段に前記低電力モード状態情報が記憶されている場合、前記リセット手段は、前記動作状態記憶手段に前記動作状態情報が記憶されていなくても、ウォッチドッグタイマをリセットする、
   ことを特徴とするウォッチドックタイマ監視装置。
2. 各ＣＰＵ毎に、前記低電力モード状態情報を無効化させる無効化情報を記憶する無効化情報記憶手段を有し、
   前記リセット手段は、前記モード記憶手段に前記低電力モード状態情報が記憶されていても、前記無効化情報記憶手段に、前記無効化情報が記憶されていない場合、ウォッチドックタイマをリセットしない、
   ことを特徴とする請求項１記載のウォッチドックタイマ監視装置。
3. 低電力モードに移行した後、各ＣＰＵ毎に、前記動作状態情報を定期的に更新する更新手段を有する、
   ことを特徴とする請求項２記載のウォッチドックタイマ監視装置。
4. 低電力モードに移行するＣＰＵは、車両の駐車中に実行されるプログラムを実行する、
   ことを特徴とする請求項１〜３いずれか１項記載のウォッチドックタイマ監視装置。
5. 各ＣＰＵが個別に低電力モードに移行するマルチプロセッサシステムのウォッチドックタイマ監視方法であって、
   各ＣＰＵ毎に、更新手段が、プログラムが動作していることを示す動作状態情報を動作状態記憶手段に記憶するステップと、
   リセット手段が、前記動作状態記憶手段に前記動作状態情報が記憶されている場合、ウォッチドッグタイマをリセットするステップと、
   各ＣＰＵ毎に、状態記憶手段が、モード記憶手段に低電力モードであることを示す低電力モード状態情報を記憶するステップと、
   前記モード記憶手段に前記低電力モード状態情報が記憶されている場合、前記リセット手段は、前記動作状態記憶手段に前記動作状態情報が記憶されていなくても、ウォッチドッグタイマをリセットするステップと、
   ことを特徴とするウォッチドックタイマ監視方法。

Images