JP2012185671A - 電子制御装置 - Google Patents

Abstract

【課題】ソフトウェアの処理負荷が所定負荷を超えた場合に、処理負荷の異常原因を解析できる電子制御装置を提供する。
【解決手段】タスクの起床元では、起床対象のタスクを起床すると（Ｓ４２０）、起床対象のタスクからリターンされる起床結果に基づいて起床が成功したか否かを判定し（Ｓ４２２）、起床に失敗すると（Ｓ４２２：Ｎｏ）、連続失敗回数カウンタを＋１する（Ｓ４２４）。起床されたタスクは、起床元のタスクでカウントした連続失敗回数カウンタの値を今回値として記憶し（Ｓ４３０）、連続失敗回数カウンタをクリアし（Ｓ４３２）、今回の起床までにおける連続失敗回数の最大値を算出する（Ｓ４３４）。起床されたタスクは、連続失敗回数がソフトウェアの設計時に設定した許容範囲を超えている場合（Ｓ４３６：Ｎｏ）、ソフトウェアの処理負荷異常と判定し、判定結果と処理負荷異常時の車両走行情報とを記憶する（Ｓ４３８、Ｓ４４０）。
【選択図】図４

Description

本発明は、車両に搭載される電子制御装置に関する。

従来、車両に搭載される電子制御装置において、制御部であるマイクロコンピュータ（マイコンとも言う。）が正常に作動しているか否かを監視するために、ウォッチドッグタイマ方式や宿題回答方式が採用されている。

ウォッチドッグタイマ方式は、ウォッチドッグタイマがマイコンにより定期的にクリアされずにオーバーフローすると、マイコンの異常であると判定する。
また、宿題回答方式は、予め定められた監視用の信号をマイコンに送り、監視用信号に基づいてマイコンが所定の演算を行った演算結果をマイコンから受け取り、受け取った演算結果が正常値と異なる場合、あるいは所定時間内でマイコンから演算結果が回答されない場合、マイコンの異常であると判定する。

このようなウォッチドッグタイマ方式や宿題回答方式を採用してマイコンの異常を監視しているときに所定の高負荷プログラムが実行されると、ウォッチドッグタイマのクリア処理や、宿題の回答処理が実行されないことがある。そのため、マイコンは正常であるにも関わらず、マイコンの異常と判定され、マイコンがリセットされるおそれがある。

これに対し、特許文献１では、高負荷プログラムが実行されるときには、前述した宿題回答方式による異常監視処理を停止させることにより、マイコンを異常と判定せず、マイコンをリセットしないようにしている。

特開２００５−２５０８５４号公報

マイコンにおいてソフトウェアの処理負荷が高くなり、前述したようなウォッチドッグタイマのクリア処理や、宿題の回答処理等が実行されない場合にマイコンがリセットされると、マイコンがリセットされた原因が処理負荷の上昇であることを検出できない。

特許文献１においては、所定の高負荷プログラムが実行されると異常監視処理を停止するものの、異常監視処理を停止する対象である所定の高負荷プログラム以外のプログラムが実行され処理負荷が高くなった場合には、異常監視処理は停止されない。この場合には、マイコンから宿題が回答されないとしてマイコンがリセットされる。そのため、マイコンがリセットされた原因が処理負荷の上昇であることを検出できない。

また、処理負荷が上昇したために車両制御上必要な処理が実行されなかったり待ち合わされたりすると、車両挙動に異常が発生することがある。この場合、処理負荷が上昇したためにマイコンがリセットされると、処理負荷の上昇が原因で車両挙動の異常が発生したことを検出できない。

本発明は、上記課題を解決するためになされたものであり、ソフトウェアの処理負荷が所定負荷を超えた場合に、処理負荷の異常原因を解析できる電子制御装置を提供することを目的とする。

請求項１から４に記載の発明によると、車両に搭載される電子制御装置において、ソフトウェアの処理負荷を検出する負荷検出手段が検出した処理負荷が予め設定された所定負荷を超えることにより、異常判定手段が処理負荷異常と判定すると、異常記憶手段は処理負荷異常の判定結果と車両走行情報とを記憶部に記憶する。

この構成によれば、定期点検または車両の挙動異常時の点検等において処理負荷異常の判定結果を記憶部から読み出すことにより、処理負荷が所定負荷を超えたことを検出できる。さらに、処理負荷異常時の車両走行情報を記憶部から読み出すことにより、処理負荷が所定負荷を超えて処理負荷異常となった原因を車両走行情報に基づいて解析できる。

ソフトウェアの処理負荷異常であることを判定する場合、請求項２に記載の発明のように、同じタスクが起床されるときにタスクの起床が連続して失敗する連続失敗回数を検出し、連続失敗回数が所定回数を超えると処理負荷異常であると判定してもよい。

タスクの起床失敗は、例えば、タスクを起床させるときに、前回起床されたタスクの処理が完了しておらず、まだ実行中であるときに発生する。タスクを起床させるときに該当するタスクよりも優先順位の高いタスクが実行中か、該当するタスクの処理中に優先順位の高いタスクの処理が開始されると、該当するタスクの処理が待ち合わされて処理時間が延びる。その結果、タスクを起床させるときに前回起床されたタスクの処理が完了していない場合には、今回のタスクの起床が失敗し、タスクの処理が抜けることになる。

そして、タスクの起床を連続して失敗する連続失敗回数が所定回数を超えることは、処理負荷が上昇したために該当するタスクの処理を所望の頻度で実行できないことを表わしている。この場合、処理負荷異常時に記憶部に記憶した車両走行情報に基づいて処理負荷異常の原因を解析することにより、処理負荷の異常上昇を避けるようにソフトウェアの仕様を修正できる。ソフトウェアの仕様修正として、例えば、タスクの起床条件、起床間隔、優先順位等の変更が考えられる。

ソフトウェアの処理負荷異常であることを判定する場合、請求項３に記載の発明のように、同じタスクが起床される起床回数とタスクの起床が失敗する起床失敗回数とを検出し、起床回数に対する起床失敗回数の比率である起床失敗率が所定比率を超えると処理負荷異常であると判定してもよい。

また、ソフトウェアの処理負荷異常であることを判定する場合、請求項４に記載の発明のように、タスクが起床されてからタスクの処理が完了するまでに要する処理時間を検出し、処理時間が所定時間を超えると処理負荷異常であると判定してもよい。

起床失敗率が所定比率を超えるか、あるいはタスクの処理時間が所定時間を超えることは、処理負荷が上昇したために該当するタスクの処理を所望の頻度で実行できないことを表わしている。

これらの場合にも、処理負荷異常時に記憶部に記憶した車両走行情報に基づいて処理負荷異常の原因を解析することにより、処理負荷の異常上昇を避けるようにソフトウェアの仕様を修正できる。

第１実施形態による電子制御装置を示すブロック図。 車両点検形態を示す模式図。 車両点検の作業手順を示すフローチャート。 （Ａ）はタスク起床元における異常検出処理を示すフローチャート、（Ｂ）は起床されるタスクにおける異常検出処理を示すフローチャート。 連続失敗回数に基づく異常検出を示すタイムチャート。 異常検出用の変数、異常判定結果および異常発生時の車両走行情報を記憶する記憶部の構成を示す模式図。 （Ａ）は第２実施形態によるタスク起床元における異常検出処理を示すフローチャート、（Ｂ）は起床されるタスクにおける異常検出処理を示すフローチャート。 起床失敗率に基づく異常検出を示すタイムチャート。 （Ａ）は第３実施形態によるタスク起床元における異常検出処理を示すフローチャート、（Ｂ）は起床されるタスクにおける異常検出処理を示すフローチャート。 タスクの処理時間に基づく異常検出を示すタイムチャート。

以下、本発明の実施形態を図に基づいて説明する。
［第１実施形態］
図１に、車両に搭載される第１実施形態のエンジン用の電子制御装置（ＥＣＵ：Electronic Control Unit）１０を示す。エンジンＥＣＵ（以下、単にＥＣＵとも言う。）１０は、電源回路１２、１４、マイコン２０、ＥＥＰＲＯＭ４０、入出力回路４２等から構成されている。

電源回路１２は、スタートスイッチ４がオンになると、エンジンＥＣＵ１０の主な電子部品にバッテリ２の電力を供給する。電源回路１４は、スタートスイッチ４のオン、オフに関わらず、常にエンジンＥＣＵ１０の該当する電子部品、例えばＳＲＡＭ（スタンバイＲＡＭ）２８にバッテリ２の電力を供給する。

マイコン２０は、ＣＰＵ２２、ＲＡＭ２４、ＲＯＭ２６、ＳＲＡＭ２８、Ｉ／Ｏ３０から主に構成されている。マイコン２０は、ＲＯＭ２６に記憶されている制御プログラムをＣＰＵ２２が実行することにより、ＡＦセンサ５０、回転数センサ５２、吸気温センサ５４、エアフロセンサ５６、水温センサ５８、車速センサ６０等から車両走行状態を表わす検出信号を入力し、車両走行状態に基づいてエンジン制御を実行する。

制御プログラムが作業用に使用し、スタートスイッチ４がオフになると記憶データが消失するＲＡＭ２４に対し、ＳＲＡＭ２８は、スタートスイッチ４のオン、オフに関わらず、電源回路１４を介してバッテリ２から電力を供給されている。したがって、ＳＲＡＭ２８に記憶されているデータは、バッテリ２の交換等によりバッテリ２からの電力供給が遮断されない限り保存される。

Ｉ／０３０は、入出力回路４２を介して、各種センサから検出信号を入力したり、ＣＡＮ等の車内ＬＡＮにより他のＥＣＵと通信する。
ＥＥＰＲＯＭ４０は、マイコン２０に外付けされている。ＥＥＰＲＯＭ４０は、書き込み可能な不揮発性の記憶部であり、バッテリ２が交換されても、記憶されているデータは保存される。

（車両点検）
定期点検や車両１００の挙動異常時にユーザがディーラまたは修理工場に車両１００を持ち込むと、図２に示すように、診断ツール１１０により車両１００からダイアグコードおよび車両走行情報を読込んで異常原因が診断される。ディーラまたは修理工場とは別に、車両１００の挙動異常が発生したときに、車両１００から無線通信により情報センタ１２０にダイアグコードと車両走行情報を送信してもよい。

（点検作業）
図３に、定期点検や車両の挙動異常時における点検作業の手順を示す。
定期点検または車両の挙動異常時にユーザがディーラ等に車両を持ち込むと（Ｓ４００）、ディーラでは、車両を点検するとともに、診断ツールにより車両からダイアグコードを読み出し、異常が発生している場合には、診断マニュアル等に基づいて適切な処置を施そうとする（Ｓ４０２）。

異常が発生している場合に適切な処置が実施され、異常が解決すると（Ｓ４０４：Ｙｅｓ）、本実施形態の点検作業は終了する。
ダイアグコードからソフトウェアの処理負荷が異常原因であると判断されると（Ｓ４０６：Ｙｅｓ）、ディーラではソフトウェアの処理負荷の異常原因を解析できないので、車両はソフトウェアの設計部門等に持ち込まれる。

設計部門では、車両からソフトウェアの処理負荷異常時の車両走行情報を読み出し、処理負荷異常の原因を解析する（Ｓ４０８）。ソフトウェアの処理負荷異常時の車両走行情報は、異常発生時にＥＣＵ１０により記憶されている。

ソフトウェアの処理負荷異常の原因を解析した結果、処理負荷異常の原因がソフトウェアの制御仕様の場合（Ｓ４１０：Ｙｅｓ）、ソフトウェアの制御仕様の修正要と判断する（Ｓ４１２）。そして、処理負荷異常を解消するために、ソフトウェアの制御仕様が検討される。

（処理負荷の異常検出処理）
ＥＣＵ１０においては、エンジン制御のために複数のタスクが実行される。各タスクには、起床条件、起床間隔、優先順位等が設定されている。複数のタスクが実行されているときにソフトウェアの処理負荷が上昇し、例えば優先順位の高いタスクの実行頻度が増えると、優先順位の低いタスクは、優先順位の高いタスクの処理が完了するまで、処理が待ち合わされる。

タスクの処理が待ち合わされると、タスクが処理する車両制御の頻度が低くなったり、処理完了までの処理時間が長くなったりする。その結果、車両制御に不具合が生じ、車両挙動に異常が発生することがある。

図４に、ＥＣＵ１０において実行されるソフトウェアの処理負荷異常の検出処理を示す。図４の（Ａ）はタスクの起床元での処理を示し、図４の（Ｂ）は起床される側のタスクの処理を示している。

タスクの起床元では、図４の（Ａ）に示すように、タスクを起床すると（Ｓ４２０）、起床対象のタスクからリターンされる起床結果に基づいて、起床が成功したか否かを判定する（Ｓ４２２）。起床に成功した場合には（Ｓ４２２：Ｙｅｓ）、本処理を終了する。

ここで、図５に、優先順位の低い低タスクと、それよりも優先順位の高い高タスクとが起床されるときに、同じ低タスクの起床が連続して失敗する連続失敗回数の変化を示す。図５では、起床成功、起床失敗を含め１３回低タスクが起床されている。１回目〜３回目の起床は成功しているので、連続失敗回数カウンタの値は０のままである。３回目の起床時には高タスクが起床されるので低タスクの処理開始は待ち合わされているが、４回目の起床前に高タスクの処理が完了し低タスクの処理が開始されるので、３回目の起床は成功になっている。

一方、図５の４回目、５回目の起床時には、３回目の起床で処理を開始した低タスクの処理が完了していないので、起床時に起床失敗になっている。
このように起床に失敗すると（Ｓ４２２：Ｎｏ）、起床元のタスクは、ＲＡＭ２４（図６参照）に設定された連続失敗回数カウンタを＋１する（Ｓ４２４）。第１実施形態では、ソフトウェアの設計時に設定した連続失敗回数の許容範囲を表わす所定回数を「２回」にしている。したがって、連続失敗回数が２回以下であれば正常であり、２回を超えると異常になる。

尚、複数のタスクを異常検出処理の対象として連続失敗回数をカウントする場合、異常検出処理の対象タスク毎に連続失敗回数カウンタが設定される。
図５では、１回目〜３回目の起床において低タスクの起床が成功しているので、連続失敗回数カウンタの値は０のままである。４回目、５回目の起床は失敗になっており、後述するように起床されたタスクにより連続失敗回数カウンタがクリアされないので、連続失敗回数カウンタがそれぞれ＋１され、１、２と増加している。

タスクの起床が成功すると、図４の（Ｂ）に示すように、起床されたタスクは、起床元のタスクでカウントした連続失敗回数カウンタの値を今回値としてＲＡＭ２４に記憶し（Ｓ４３０）、連続失敗回数カウンタをクリアする（Ｓ４３２）。そして、連続失敗回数の今回値と、ＲＡＭ２４に記憶されている前回までの連続失敗回数の最大値とを比較し、大きい方の値を連続失敗回数の最大値として記憶する（Ｓ４３４）。

図５の６回目の起床では、高タスクの処理完了後に低タスクの処理が開始しているので、起床は成功している。したがって、起床された低タスクは、連続失敗回数カウンタの値である「２」を今回値としてＲＡＭ２４に記憶し、連続失敗回数カウンタをクリアして０にする。連続失敗回数の最大値の初期値は０であるから、連続失敗回数の今回値の「２」が最大値として記憶される。

第１実施形態では、連続失敗回数の許容範囲を２回以下としているので、今回更新した連続失敗回数の最大値の「２」は許容範囲内である。最大値が許容範囲内であれば（Ｓ４３６：Ｙｅｓ）、本処理を終了する。

図５の９回目〜１１回目の起床時には、８回目の起床で処理を開始した低タスクの処理が完了していないので、起床時に起床失敗になっている。したがって、１１回目の起床時において連続失敗回数のカウント値は「３」に設定される。

９回目〜１１回目の３回の起床に失敗した後、１２回目の起床は成功するので、連続失敗回数の最大値は「３」に更新される。１２回目の起床により処理を開始した低タスクでは、更新された連続失敗回数の最大値の「３」は許容範囲を超えており、ソフトウェアの処理負荷異常であると判定する（Ｓ４３６：Ｎｏ）。

この場合、起床されたタスクは、ソフトウェアの処理負荷異常と判定した判定結果と処理負荷異常時の車両走行情報とをＳＲＡＭ２８またはＥＥＰＲＯＭ４０に記憶し（Ｓ４３８、Ｓ４４０）、処理負荷異常が発生したことを通知する。ダイアグタスクは、ソフトウェアの処理負荷異常が通知されると、該当するダイアグコードを設定する。

ＳＲＡＭ２８またはＥＥＰＲＯＭ４０に記憶する車両走行情報として、吸気量、吸気温、水温、エンジン回転数、車速、連続失敗回数が所定回数を超えたタスク名等が考えられる。車両走行情報としては、車両自体の走行情報だけでなく、ナビゲーション装置等から取得する道路の曲率、勾配等の道路形状、天気、渋滞等の車両周囲の環境を表わす走行情報を記憶してもよい。

尚、ソフトウェアの処理負荷異常と判定した判定結果と処理負荷異常時の車両走行情報とが記憶される記憶部は、車両のスタートスイッチがオフになってもデータが保持されるものであれば本実施形態で例示したＳＲＡＭ（スタンバイＲＡＭ）またはＥＥＰＲＯＭに限るものではなく、ＥＥＰＲＯＭ以外の書き換え可能な不揮発性メモリであってもよい。

第１実施形態では、ＥＣＵ１０が本発明の電子制御装置に相当し、ＳＲＡＭ２８またはＥＥＰＲＯＭ４０が本発明の記憶部に相当する。そして、ＥＣＵ１０は、負荷検出手段、異常判定手段および異常記憶手段が実行する機能を実現する。

また、図４のＳ４２２、Ｓ４２４、Ｓ４３０〜Ｓ４３４の処理が本発明の負荷検出手段が実行する機能に相当し、Ｓ４３６の処理が本発明の異常判定手段が実行する機能に相当し、Ｓ４３８およびＳ４４０の処理が本発明の異常記憶手段が実行する機能に相当する。

［第２実施形態］
本発明の第２実施形態による処理負荷の異常検出処理を図７および図８に示す。第２実施形態の異常検出処理は、起床失敗率に基づいて処理負荷異常を検出する。第２実施形態では、ソフトウェアの設計時に設定した起床失敗率の許容範囲を表わす所定比率を「５０％」にしている。したがって、起床失敗率が５０％以下であれば正常であり、５０％を超えると異常になる。

図７の（Ａ）に示すように、起床元のタスクでは、低タスクを起床すると（Ｓ４５０）、起床の成功、失敗に関わらず所定回数まで起床回数をカウントアップする（Ｓ４５２）。

一方、図７の（Ｂ）に示すように、起床に成功して低タスクの処理が開始すると、低タスクでは、起床されて処理が開始される毎に処理回数カウントをカウントアップする（Ｓ４７０）。図８に示すように、１回目〜３回目の起床は成功しているが、４回目および５回目の起床は、３回目の起床により処理を開始した低タスクの処理が完了していないために失敗しているので、処理回数カウンタの値は３回のまま更新されていない。

尚、複数のタスクを異常検出処理の対象として起床回数および処理回数をカウントする場合、異常検出処理の対象タスク毎に起床回数カウンタ、処理回数カウンタが設定される。

起床元タスクでは、起床回数が所定回数以上になると（Ｓ４５４：Ｙｅｓ）、次式（１）に基づいて起床失敗率を算出し（Ｓ４５６）、ＲＡＭ２４に起床失敗率を記憶する。そして、処理回数カウンタおよび起床回数カウンタをクリアする（Ｓ４６０）。

起床失敗率［％］
＝｛（起床回数カウンタ−処理回数カウンタ）／起床回数カウンタ｝×１００
・・・（１）
第２実施形態では、所定回数は１００回であり、ソフトウェアの設計時に設定する起床失敗率の許容範囲は前述したように５０％以下である。図８の起床結果に基づいて、起床回数カウンタ＝１００、処理回数カウンタ＝４６を式（１）に代入して起床失敗率を算出すると、起床失敗率＝５４％になる。

Ｓ４５６で算出した所定回数（１００回）の起床処理までの起床失敗率がソフトウェアの設計時に設定した許容範囲（第２実施形態では５０％以下）を超えている場合（Ｓ４６２：Ｎｏ）、起床元タスクは、ソフトウェアの処理負荷異常と判断する。

そして、起床元タスクは、ソフトウェアの処理負荷異常と判定した判定結果と処理負荷異常時の車両走行情報とをＳＲＡＭ２８またはＥＥＰＲＯＭ４０に記憶し（Ｓ４６４、Ｓ４６６）、処理負荷異常が発生したことを通知する。ダイアグタスクは、ソフトウェアの処理負荷異常が通知されると、該当するダイアグコードを設定する。

第２実施形態では、図７のＳ４５２〜Ｓ４５６およびＳ４７０の処理が本発明の負荷検出手段が実行する機能に相当し、Ｓ４６２の処理が本発明の異常判定手段が実行する機能に相当し、Ｓ４６４およびＳ４６６の処理が本発明の異常記憶手段が実行する機能に相当する。

［第３実施形態］
本発明の第３実施形態による処理負荷の異常検出処理を図９および図１０に示す。第３実施形態の異常検出処理は、タスクが起床されてからタスクの処理が完了するまでの処理時間に基づいて処理負荷異常を検出する。第３実施形態では、ソフトウェアの設計時に設定した処理時間の許容範囲を表わす所定時間を「４」にしている。したがって、処理時間が４以下であれば正常であり、４を超えると異常になる。

図９の（Ａ）に示すように、起床元のタスクでは、低タスクを起床し（Ｓ４８０）、起床時刻をＲＡＭ２４に記憶する（Ｓ４８２）。例えば、図１０において、１回目〜４回目の起床時刻は、「１」、「８」、「１５」、「２２」である。

図９の（Ｂ）に示すように、起床されたタスクは、タスクとして割り当てられた処理を実行すると（Ｓ４９０）、処理完了時刻をＲＡＭ２４に記憶する（Ｓ４９２）。起床元タスクで記憶した起床時刻とＳ４９２で記憶した処理完了時刻とから、起床されたタスクの処理時間を算出し（Ｓ４９４）、処理時間がソフトウェアの設計時に設定した許容範囲内であるか否かを判定する（Ｓ４９６）。

尚、複数のタスクを異常検出処理の対象とする場合、異常検出処理の対象タスク毎に処理時間が算出される。
図１０において、１回目〜４回目の起床における低タスクの処理完了時刻は、「３」、「１１」、「２０」、「２４」である。したがって、１回目〜４回目の起床における各低タスクの処理時間は、処理完了時刻と起床時刻との差から、「２」、「３」、「５」、「２」と算出される。図１０においては、処理時間が「４」を超えると、処理時間が許容範囲を超えていると判断している。

処理時間が許容範囲（第３施形態では４以下）を超えると（Ｓ４９６：Ｎｏ）、起床されたタスクは、ソフトウェアの処理負荷異常と判断し、ソフトウェアの処理負荷異常と判定した判定結果と処理負荷異常時の車両走行情報とをＳＲＡＭ２８またはＥＥＰＲＯＭ４０に記憶し（Ｓ４９８、Ｓ５００）、処理負荷異常が発生したことを通知する。ダイアグタスクは、ソフトウェアの処理負荷異常が通知されると、該当するダイアグコードを設定する。

第３実施形態では、図９のＳ４８２、Ｓ４９２およびＳ４９４の処理が本発明の負荷検出手段が実行する機能に相当し、Ｓ４９６の処理が本発明の異常判定手段が実行する機能に相当し、Ｓ４９８およびＳ５００の処理が本発明の異常記憶手段が実行する機能に相当する。

以上説明した上記複数の実施形態によると、同じタスクを起床するときに連続して起床に失敗する連続失敗回数、同じタスクが起床された起床回数に対する起床に失敗した起床失敗回数の比率、あるいはタスクが起床されてからタスクの処理が完了するまでに要する処理時間のいずれかがソフトウェアの設計時に設定した許容範囲をこえると、ソフトウェアの処理負荷の異常と判断する。

そして、処理負荷の異常発生の判定結果を表わすダイアグコードと異常発生時における車両走行情報とを、車両のスタートスイッチがオフになっても記憶データが消失しないＳＲＡＭ２８またはＥＥＰＲＯＭ４０に記憶する。

これにより、定期点検または車両の挙動異常時に診断ツールでダイアグコードを読み出せば、ソフトウェアの処理負荷異常が発生していた場合に、処理負荷異常を検出できる。そして、処理負荷異常発生時の車両走行情報に基づいて処理負荷の異常原因を解析することにより、ソフトウェアの処理負荷の異常が発生しないように、ソフトウェアの仕様を修正する等の適切な処置を実施することができる。

また、上記実施形態で説明したソフトウェアの処理負荷異常の検出処理をソフトウェアの開発段階で実行すれば、ソフトウェアの処理負荷が所定負荷を超えないように、ソフトウェアの開発段階で仕様を設定できる。

［他の実施形態］
上記実施形態では、連続失敗回数、起床失敗率または処理時間がソフトウェアの設計時に予め設定した所定値を超えると、ソフトウェアの処理負荷異常と判定した。これ以外にも、所定期間中にアイドルタスクが実行される時間の比率であるアイドル率が所定値を下回ると、ソフトウェアの処理負荷異常と判定してもよい。

また、起床されたタスクの処理が完了してから同じタスクが起床されるまでの余裕時間が所定時間よりも短くなると、ソフトウェアの処理負荷異常と判定してもよい。
また、連続失敗回数、起床失敗率または処理時間を計測してソフトウェアの処理負荷異常の検出対象となるタスクは優先順位の低い低タスクに限るものではなく、優先順位に関わらず複数のタスクを検出対象とすることができる。

また、異常検出対象のタスク毎に、連続失敗回数、起床失敗率および処理時間のうち２個以上を計測し、ソフトウェアの処理負荷が所定負荷を超えていることを計測値のいずれかが示せば、処理負荷異常と判定してもよい。

上記実施形態では、異常判定結果および異常発生時の車両走行情報を、処理負荷異常の発生している同じＥＣＵの記憶部に記憶したが、別のＥＣＵの記憶部に記憶してもよい。
このように、本発明は、上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々の実施形態に適用可能である。

１０：ＥＣＵ（電子制御装置、負荷検出手段、異常判定手段、異常記憶手段）、ＳＲＡＭ２８（記憶部）、ＥＥＰＲＯＭ４０（記憶部）

Claims (4)

1. 車両に搭載される電子制御装置において、
   ソフトウェアの処理負荷を検出する負荷検出手段と、
   前記負荷検出手段が検出した前記処理負荷が予め設定された所定負荷を超えると、前記ソフトウェアの処理負荷異常と判定する異常判定手段と、
   前記異常判定手段が前記処理負荷異常と判定すると、前記処理負荷異常の判定結果と車両走行情報とを記憶部に記憶する異常記憶手段と、
   を備えることを特徴とする電子制御装置。
2. 前記負荷検出手段は、前記処理負荷として、同じタスクが起床されるときに前記タスクの起床が連続して失敗する連続失敗回数を検出し、
   前記異常判定手段は、前記連続失敗回数が所定回数を超えると前記処理負荷異常であると判定する、
   ことを特徴とする請求項１に記載の電子制御装置。
3. 前記負荷検出手段は、前記処理負荷として、同じタスクが起床される起床回数と前記タスクの起床が失敗する起床失敗回数とを検出し、
   前記異常判定手段は、前記起床回数に対する前記起床失敗回数の比率である起床失敗率が所定比率を超えると前記処理負荷異常であると判定する、
   ことを特徴とする請求項１または２に記載の電子制御装置。
4. 前記負荷検出手段は、前記処理負荷として、タスクが起床されてから前記タスクの処理が完了するまでに要する処理時間を検出し、
   前記異常判定手段は、前記処理時間が所定時間を超えると前記処理負荷異常であると判定する、
   ことを特徴とする請求項１から３のいずれか一項に記載の電子制御装置。

Images