車両に搭載される電子制御装置において、ソフトウェアの処理負荷を検出する負荷検出手段と、前記負荷検出手段が検出した前記処理負荷が予め設定された所定負荷を超えると、前記ソフトウェアの処理負荷異常と判定する異常判定手段と、前記異常判定手段が前記処理負荷異常と判定すると、前記処理負荷異常の判定結果と車両走行情報とを記憶部に記憶する異常記憶手段と、を備えることを特徴とする電子制御装置。前記負荷検出手段は、前記処理負荷として、同じタスクが起床されるときに前記タスクの起床が連続して失敗する連続失敗回数を検出し、前記異常判定手段は、前記連続失敗回数が所定回数を超えると前記処理負荷異常であると判定する、ことを特徴とする請求項1に記載の電子制御装置。前記負荷検出手段は、前記処理負荷として、同じタスクが起床される起床回数と前記タスクの起床が失敗する起床失敗回数とを検出し、前記異常判定手段は、前記起床回数に対する前記起床失敗回数の比率である起床失敗率が所定比率を超えると前記処理負荷異常であると判定する、ことを特徴とする請求項1または2に記載の電子制御装置。前記負荷検出手段は、前記処理負荷として、タスクが起床されてから前記タスクの処理が完了するまでに要する処理時間を検出し、前記異常判定手段は、前記処理時間が所定時間を超えると前記処理負荷異常であると判定する、ことを特徴とする請求項1から3のいずれか一項に記載の電子制御装置。マイコンにおいてソフトウェアの処理負荷が高くなり、前述したようなウォッチドッグタイマのクリア処理や、宿題の回答処理等が実行されない場合にマイコンがリセットされると、マイコンがリセットされた原因が処理負荷の上昇であることを検出できない。特許文献1においては、所定の高負荷プログラムが実行されると異常監視処理を停止するものの、異常監視処理を停止する対象である所定の高負荷プログラム以外のプログラムが実行され処理負荷が高くなった場合には、異常監視処理は停止されない。この場合には、マイコンから宿題が回答されないとしてマイコンがリセットされる。そのため、マイコンがリセットされた原因が処理負荷の上昇であることを検出できない。また、処理負荷が上昇したために車両制御上必要な処理が実行されなかったり待ち合わされたりすると、車両挙動に異常が発生することがある。この場合、処理負荷が上昇したためにマイコンがリセットされると、処理負荷の上昇が原因で車両挙動の異常が発生したことを検出できない。本発明は、上記課題を解決するためになされたものであり、ソフトウェアの処理負荷が所定負荷を超えた場合に、処理負荷の異常原因を解析できる電子制御装置を提供することを目的とする。請求項1から4に記載の発明によると、車両に搭載される電子制御装置において、ソフトウェアの処理負荷を検出する負荷検出手段が検出した処理負荷が予め設定された所定負荷を超えることにより、異常判定手段が処理負荷異常と判定すると、異常記憶手段は処理負荷異常の判定結果と車両走行情報とを記憶部に記憶する。この構成によれば、定期点検または車両の挙動異常時の点検等において処理負荷異常の判定結果を記憶部から読み出すことにより、処理負荷が所定負荷を超えたことを検出できる。さらに、処理負荷異常時の車両走行情報を記憶部から読み出すことにより、処理負荷が所定負荷を超えて処理負荷異常となった原因を車両走行情報に基づいて解析できる。ソフトウェアの処理負荷異常であることを判定する場合、請求項2に記載の発明のように、同じタスクが起床されるときにタスクの起床が連続して失敗する連続失敗回数を検出し、連続失敗回数が所定回数を超えると処理負荷異常であると判定してもよい。タスクの起床失敗は、例えば、タスクを起床させるときに、前回起床されたタスクの処理が完了しておらず、まだ実行中であるときに発生する。タスクを起床させるときに該当するタスクよりも優先順位の高いタスクが実行中か、該当するタスクの処理中に優先順位の高いタスクの処理が開始されると、該当するタスクの処理が待ち合わされて処理時間が延びる。その結果、タスクを起床させるときに前回起床されたタスクの処理が完了していない場合には、今回のタスクの起床が失敗し、タスクの処理が抜けることになる。そして、タスクの起床を連続して失敗する連続失敗回数が所定回数を超えることは、処理負荷が上昇したために該当するタスクの処理を所望の頻度で実行できないことを表わしている。この場合、処理負荷異常時に記憶部に記憶した車両走行情報に基づいて処理負荷異常の原因を解析することにより、処理負荷の異常上昇を避けるようにソフトウェアの仕様を修正できる。ソフトウェアの仕様修正として、例えば、タスクの起床条件、起床間隔、優先順位等の変更が考えられる。ソフトウェアの処理負荷異常であることを判定する場合、請求項3に記載の発明のように、同じタスクが起床される起床回数とタスクの起床が失敗する起床失敗回数とを検出し、起床回数に対する起床失敗回数の比率である起床失敗率が所定比率を超えると処理負荷異常であると判定してもよい。また、ソフトウェアの処理負荷異常であることを判定する場合、請求項4に記載の発明のように、タスクが起床されてからタスクの処理が完了するまでに要する処理時間を検出し、処理時間が所定時間を超えると処理負荷異常であると判定してもよい。起床失敗率が所定比率を超えるか、あるいはタスクの処理時間が所定時間を超えることは、処理負荷が上昇したために該当するタスクの処理を所望の頻度で実行できないことを表わしている。これらの場合にも、処理負荷異常時に記憶部に記憶した車両走行情報に基づいて処理負荷異常の原因を解析することにより、処理負荷の異常上昇を避けるようにソフトウェアの仕様を修正できる。以下、本発明の実施形態を図に基づいて説明する。[第1実施形態]図1に、車両に搭載される第1実施形態のエンジン用の電子制御装置ECU:ElectronicControlUnit10を示す。エンジンECU以下、単にECUとも言う。10は、電源回路12、14、マイコン20、EEPROM40、入出力回路42等から構成されている。電源回路12は、スタートスイッチ4がオンになると、エンジンECU10の主な電子部品にバッテリ2の電力を供給する。電源回路14は、スタートスイッチ4のオン、オフに関わらず、常にエンジンECU10の該当する電子部品、例えばSRAMスタンバイRAM28にバッテリ2の電力を供給する。マイコン20は、CPU22、RAM24、ROM26、SRAM28、I/O30から主に構成されている。マイコン20は、ROM26に記憶されている制御プログラムをCPU22が実行することにより、AFセンサ50、回転数センサ52、吸気温センサ54、エアフロセンサ56、水温センサ58、車速センサ60等から車両走行状態を表わす検出信号を入力し、車両走行状態に基づいてエンジン制御を実行する。制御プログラムが作業用に使用し、スタートスイッチ4がオフになると記憶データが消失するRAM24に対し、SRAM28は、スタートスイッチ4のオン、オフに関わらず、電源回路14を介してバッテリ2から電力を供給されている。したがって、SRAM28に記憶されているデータは、バッテリ2の交換等によりバッテリ2からの電力供給が遮断されない限り保存される。I/030は、入出力回路42を介して、各種センサから検出信号を入力したり、CAN等の車内LANにより他のECUと通信する。EEPROM40は、マイコン20に外付けされている。EEPROM40は、書き込み可能な不揮発性の記憶部であり、バッテリ2が交換されても、記憶されているデータは保存される。車両点検定期点検や車両100の挙動異常時にユーザがディーラまたは修理工場に車両100を持ち込むと、図2に示すように、診断ツール110により車両100からダイアグコードおよび車両走行情報を読込んで異常原因が診断される。ディーラまたは修理工場とは別に、車両100の挙動異常が発生したときに、車両100から無線通信により情報センタ120にダイアグコードと車両走行情報を送信してもよい。点検作業図3に、定期点検や車両の挙動異常時における点検作業の手順を示す。定期点検または車両の挙動異常時にユーザがディーラ等に車両を持ち込むとS400、ディーラでは、車両を点検するとともに、診断ツールにより車両からダイアグコードを読み出し、異常が発生している場合には、診断マニュアル等に基づいて適切な処置を施そうとするS402。異常が発生している場合に適切な処置が実施され、異常が解決するとS404:Yes、本実施形態の点検作業は終了する。ダイアグコードからソフトウェアの処理負荷が異常原因であると判断されるとS406:Yes、ディーラではソフトウェアの処理負荷の異常原因を解析できないので、車両はソフトウェアの設計部門等に持ち込まれる。設計部門では、車両からソフトウェアの処理負荷異常時の車両走行情報を読み出し、処理負荷異常の原因を解析するS408。ソフトウェアの処理負荷異常時の車両走行情報は、異常発生時にECU10により記憶されている。ソフトウェアの処理負荷異常の原因を解析した結果、処理負荷異常の原因がソフトウェアの制御仕様の場合S410:Yes、ソフトウェアの制御仕様の修正要と判断するS412。そして、処理負荷異常を解消するために、ソフトウェアの制御仕様が検討される。処理負荷の異常検出処理ECU10においては、エンジン制御のために複数のタスクが実行される。各タスクには、起床条件、起床間隔、優先順位等が設定されている。複数のタスクが実行されているときにソフトウェアの処理負荷が上昇し、例えば優先順位の高いタスクの実行頻度が増えると、優先順位の低いタスクは、優先順位の高いタスクの処理が完了するまで、処理が待ち合わされる。タスクの処理が待ち合わされると、タスクが処理する車両制御の頻度が低くなったり、処理完了までの処理時間が長くなったりする。その結果、車両制御に不具合が生じ、車両挙動に異常が発生することがある。図4に、ECU10において実行されるソフトウェアの処理負荷異常の検出処理を示す。図4のAはタスクの起床元での処理を示し、図4のBは起床される側のタスクの処理を示している。タスクの起床元では、図4のAに示すように、タスクを起床するとS420、起床対象のタスクからリターンされる起床結果に基づいて、起床が成功したか否かを判定するS422。起床に成功した場合にはS422:Yes、本処理を終了する。ここで、図5に、優先順位の低い低タスクと、それよりも優先順位の高い高タスクとが起床されるときに、同じ低タスクの起床が連続して失敗する連続失敗回数の変化を示す。図5では、起床成功、起床失敗を含め13回低タスクが起床されている。1回目~3回目の起床は成功しているので、連続失敗回数カウンタの値は0のままである。3回目の起床時には高タスクが起床されるので低タスクの処理開始は待ち合わされているが、4回目の起床前に高タスクの処理が完了し低タスクの処理が開始されるので、3回目の起床は成功になっている。一方、図5の4回目、5回目の起床時には、3回目の起床で処理を開始した低タスクの処理が完了していないので、起床時に起床失敗になっている。このように起床に失敗するとS422:No、起床元のタスクは、RAM24図6参照に設定された連続失敗回数カウンタを1するS424。第1実施形態では、ソフトウェアの設計時に設定した連続失敗回数の許容範囲を表わす所定回数を2回にしている。したがって、連続失敗回数が2回以下であれば正常であり、2回を超えると異常になる。尚、複数のタスクを異常検出処理の対象として連続失敗回数をカウントする場合、異常検出処理の対象タスク毎に連続失敗回数カウンタが設定される。図5では、1回目~3回目の起床において低タスクの起床が成功しているので、連続失敗回数カウンタの値は0のままである。4回目、5回目の起床は失敗になっており、後述するように起床されたタスクにより連続失敗回数カウンタがクリアされないので、連続失敗回数カウンタがそれぞれ1され、1、2と増加している。タスクの起床が成功すると、図4のBに示すように、起床されたタスクは、起床元のタスクでカウントした連続失敗回数カウンタの値を今回値としてRAM24に記憶しS430、連続失敗回数カウンタをクリアするS432。そして、連続失敗回数の今回値と、RAM24に記憶されている前回までの連続失敗回数の最大値とを比較し、大きい方の値を連続失敗回数の最大値として記憶するS434。図5の6回目の起床では、高タスクの処理完了後に低タスクの処理が開始しているので、起床は成功している。したがって、起床された低タスクは、連続失敗回数カウンタの値である2を今回値としてRAM24に記憶し、連続失敗回数カウンタをクリアして0にする。連続失敗回数の最大値の初期値は0であるから、連続失敗回数の今回値の2が最大値として記憶される。第1実施形態では、連続失敗回数の許容範囲を2回以下としているので、今回更新した連続失敗回数の最大値の2は許容範囲内である。最大値が許容範囲内であればS436:Yes、本処理を終了する。図5の9回目~11回目の起床時には、8回目の起床で処理を開始した低タスクの処理が完了していないので、起床時に起床失敗になっている。したがって、11回目の起床時において連続失敗回数のカウント値は3に設定される。9回目~11回目の3回の起床に失敗した後、12回目の起床は成功するので、連続失敗回数の最大値は3に更新される。12回目の起床により処理を開始した低タスクでは、更新された連続失敗回数の最大値の3は許容範囲を超えており、ソフトウェアの処理負荷異常であると判定するS436:No。この場合、起床されたタスクは、ソフトウェアの処理負荷異常と判定した判定結果と処理負荷異常時の車両走行情報とをSRAM28またはEEPROM40に記憶しS438、S440、処理負荷異常が発生したことを通知する。ダイアグタスクは、ソフトウェアの処理負荷異常が通知されると、該当するダイアグコードを設定する。SRAM28またはEEPROM40に記憶する車両走行情報として、吸気量、吸気温、水温、エンジン回転数、車速、連続失敗回数が所定回数を超えたタスク名等が考えられる。車両走行情報としては、車両自体の走行情報だけでなく、ナビゲーション装置等から取得する道路の曲率、勾配等の道路形状、天気、渋滞等の車両周囲の環境を表わす走行情報を記憶してもよい。尚、ソフトウェアの処理負荷異常と判定した判定結果と処理負荷異常時の車両走行情報とが記憶される記憶部は、車両のスタートスイッチがオフになってもデータが保持されるものであれば本実施形態で例示したSRAMスタンバイRAMまたはEEPROMに限るものではなく、EEPROM以外の書き換え可能な不揮発性メモリであってもよい。第1実施形態では、ECU10が本発明の電子制御装置に相当し、SRAM28またはEEPROM40が本発明の記憶部に相当する。そして、ECU10は、負荷検出手段、異常判定手段および異常記憶手段が実行する機能を実現する。また、図4のS422、S424、S430~S434の処理が本発明の負荷検出手段が実行する機能に相当し、S436の処理が本発明の異常判定手段が実行する機能に相当し、S438およびS440の処理が本発明の異常記憶手段が実行する機能に相当する。[第2実施形態]本発明の第2実施形態による処理負荷の異常検出処理を図7および図8に示す。第2実施形態の異常検出処理は、起床失敗率に基づいて処理負荷異常を検出する。第2実施形態では、ソフトウェアの設計時に設定した起床失敗率の許容範囲を表わす所定比率を50にしている。したがって、起床失敗率が50以下であれば正常であり、50を超えると異常になる。図7のAに示すように、起床元のタスクでは、低タスクを起床するとS450、起床の成功、失敗に関わらず所定回数まで起床回数をカウントアップするS452。一方、図7のBに示すように、起床に成功して低タスクの処理が開始すると、低タスクでは、起床されて処理が開始される毎に処理回数カウントをカウントアップするS470。図8に示すように、1回目~3回目の起床は成功しているが、4回目および5回目の起床は、3回目の起床により処理を開始した低タスクの処理が完了していないために失敗しているので、処理回数カウンタの値は3回のまま更新されていない。尚、複数のタスクを異常検出処理の対象として起床回数および処理回数をカウントする場合、異常検出処理の対象タスク毎に起床回数カウンタ、処理回数カウンタが設定される。起床元タスクでは、起床回数が所定回数以上になるとS454:Yes、次式1に基づいて起床失敗率を算出しS456、RAM24に起床失敗率を記憶する。そして、処理回数カウンタおよび起床回数カウンタをクリアするS460。起床失敗率[]={起床回数カウンタ-処理回数カウンタ/起床回数カウンタ}×1001第2実施形態では、所定回数は100回であり、ソフトウェアの設計時に設定する起床失敗率の許容範囲は前述したように50以下である。図8の起床結果に基づいて、起床回数カウンタ=100、処理回数カウンタ=46を式1に代入して起床失敗率を算出すると、起床失敗率=54になる。S456で算出した所定回数100回の起床処理までの起床失敗率がソフトウェアの設計時に設定した許容範囲第2実施形態では50以下を超えている場合S462:No、起床元タスクは、ソフトウェアの処理負荷異常と判断する。そして、起床元タスクは、ソフトウェアの処理負荷異常と判定した判定結果と処理負荷異常時の車両走行情報とをSRAM28またはEEPROM40に記憶しS464、S466、処理負荷異常が発生したことを通知する。ダイアグタスクは、ソフトウェアの処理負荷異常が通知されると、該当するダイアグコードを設定する。第2実施形態では、図7のS452~S456およびS470の処理が本発明の負荷検出手段が実行する機能に相当し、S462の処理が本発明の異常判定手段が実行する機能に相当し、S464およびS466の処理が本発明の異常記憶手段が実行する機能に相当する。[第3実施形態]本発明の第3実施形態による処理負荷の異常検出処理を図9および図10に示す。第3実施形態の異常検出処理は、タスクが起床されてからタスクの処理が完了するまでの処理時間に基づいて処理負荷異常を検出する。第3実施形態では、ソフトウェアの設計時に設定した処理時間の許容範囲を表わす所定時間を4にしている。したがって、処理時間が4以下であれば正常であり、4を超えると異常になる。図9のAに示すように、起床元のタスクでは、低タスクを起床しS480、起床時刻をRAM24に記憶するS482。例えば、図10において、1回目~4回目の起床時刻は、1、8、15、22である。図9のBに示すように、起床されたタスクは、タスクとして割り当てられた処理を実行するとS490、処理完了時刻をRAM24に記憶するS492。起床元タスクで記憶した起床時刻とS492で記憶した処理完了時刻とから、起床されたタスクの処理時間を算出しS494、処理時間がソフトウェアの設計時に設定した許容範囲内であるか否かを判定するS496。尚、複数のタスクを異常検出処理の対象とする場合、異常検出処理の対象タスク毎に処理時間が算出される。図10において、1回目~4回目の起床における低タスクの処理完了時刻は、3、11、20、24である。したがって、1回目~4回目の起床における各低タスクの処理時間は、処理完了時刻と起床時刻との差から、2、3、5、2と算出される。図10においては、処理時間が4を超えると、処理時間が許容範囲を超えていると判断している。処理時間が許容範囲第3施形態では4以下を超えるとS496:No、起床されたタスクは、ソフトウェアの処理負荷異常と判断し、ソフトウェアの処理負荷異常と判定した判定結果と処理負荷異常時の車両走行情報とをSRAM28またはEEPROM40に記憶しS498、S500、処理負荷異常が発生したことを通知する。ダイアグタスクは、ソフトウェアの処理負荷異常が通知されると、該当するダイアグコードを設定する。第3実施形態では、図9のS482、S492およびS494の処理が本発明の負荷検出手段が実行する機能に相当し、S496の処理が本発明の異常判定手段が実行する機能に相当し、S498およびS500の処理が本発明の異常記憶手段が実行する機能に相当する。以上説明した上記複数の実施形態によると、同じタスクを起床するときに連続して起床に失敗する連続失敗回数、同じタスクが起床された起床回数に対する起床に失敗した起床失敗回数の比率、あるいはタスクが起床されてからタスクの処理が完了するまでに要する処理時間のいずれかがソフトウェアの設計時に設定した許容範囲をこえると、ソフトウェアの処理負荷の異常と判断する。そして、処理負荷の異常発生の判定結果を表わすダイアグコードと異常発生時における車両走行情報とを、車両のスタートスイッチがオフになっても記憶データが消失しないSRAM28またはEEPROM40に記憶する。これにより、定期点検または車両の挙動異常時に診断ツールでダイアグコードを読み出せば、ソフトウェアの処理負荷異常が発生していた場合に、処理負荷異常を検出できる。そして、処理負荷異常発生時の車両走行情報に基づいて処理負荷の異常原因を解析することにより、ソフトウェアの処理負荷の異常が発生しないように、ソフトウェアの仕様を修正する等の適切な処置を実施することができる。また、上記実施形態で説明したソフトウェアの処理負荷異常の検出処理をソフトウェアの開発段階で実行すれば、ソフトウェアの処理負荷が所定負荷を超えないように、ソフトウェアの開発段階で仕様を設定できる。[他の実施形態]上記実施形態では、連続失敗回数、起床失敗率または処理時間がソフトウェアの設計時に予め設定した所定値を超えると、ソフトウェアの処理負荷異常と判定した。これ以外にも、所定期間中にアイドルタスクが実行される時間の比率であるアイドル率が所定値を下回ると、ソフトウェアの処理負荷異常と判定してもよい。また、起床されたタスクの処理が完了してから同じタスクが起床されるまでの余裕時間が所定時間よりも短くなると、ソフトウェアの処理負荷異常と判定してもよい。また、連続失敗回数、起床失敗率または処理時間を計測してソフトウェアの処理負荷異常の検出対象となるタスクは優先順位の低い低タスクに限るものではなく、優先順位に関わらず複数のタスクを検出対象とすることができる。また、異常検出対象のタスク毎に、連続失敗回数、起床失敗率および処理時間のうち2個以上を計測し、ソフトウェアの処理負荷が所定負荷を超えていることを計測値のいずれかが示せば、処理負荷異常と判定してもよい。上記実施形態では、異常判定結果および異常発生時の車両走行情報を、処理負荷異常の発生している同じECUの記憶部に記憶したが、別のECUの記憶部に記憶してもよい。このように、本発明は、上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々の実施形態に適用可能である。