(57)【特許請求の範囲】
【請求項１】
ＣＰＵと、
ブレークアドレスレジスタを内蔵し、当該ブレークアドレスレジスタに設定されたアドレスに対応する関数が、前記ＣＰＵにより実行されるとき、ブレーク条件が満足されたとして、ブレーク割込要求を発するユーザブレークコントローラと、
を備えて、前記ＣＰＵにより実行されるプログラムを検査する検査システムであって、
検査対象のプログラム（以下、「検査対象プログラム」と表現する。）に基づき前記ＣＰＵにより実行される複数の関数各々のアドレスを、前記ブレークアドレスレジスタに設定すべき順序の情報と共に記憶するアドレス記憶手段と、
前記アドレス記憶手段が記憶する各アドレスの内、前記順序が先頭に定められたアドレスを、前記ブレークアドレスレジスタに設定するイニシャル処理手段と、
前記ブレーク割込要求が前記ユーザブレークコントローラにより発せられると、前記順序が、前記ブレークアドレスレジスタにアドレスが設定されている関数の次に定められた関数のアドレスを、前記ブレークアドレスレジスタに設定するブレーク割込例外処理手段と、
前記ブレーク割込例外処理手段の動作結果に基づき、前記検査対象プログラムに基づく処理の流れが正常であるか否かを判定する判定手段と、
を備え、
前記判定手段は、前記順序が最後尾に定められた関数の実行に伴い前記ブレーク割込例外処理手段が動作した場合、前記処理の流れが正常であると判定し、前記順序が最後尾に定められた関数の実行に伴う前記ブレーク割込例外処理手段の動作が生じなかった場合、前記処理の流れが正常ではないと判定することを特徴とする検査システム。
【請求項２】
前記ブレーク割込例外処理手段は、前記ブレーク割込要求が前記ユーザブレークコントローラにより発せられると、当該ブレーク割込要求が、前記順序が最後尾に定められた関数が前記ＣＰＵにより実行されることに起因して発せられたものであるか否かを判断し、当該ブレーク割込要求が、前記順序が最後尾に定められた関数が前記ＣＰＵにより実行されることに起因して発せられたものではないと判断すると、前記順序が前記ブレークアドレスレジスタにアドレスが設定されている関数の次に定められた関数のアドレスを、前記ブレークアドレスレジスタに設定し、当該ブレーク割込要求が、前記順序が最後尾に定められた関数がＣＰＵにより実行されることに起因して発せられたものであると判断すると、所定の判定用フラグをオンに設定し、
前記判定手段は、前記順序が最後尾に定められた関数の実行後のタイミングで起動して、前記判定用フラグがオンに設定されている場合には、前記検査対象プログラムに基づく処理の流れが正常であると判定し、前記フラグがオフに設定されている場合には、前記検査対象プログラムに基づく処理の流れが異常であると判定し、
前記イニシャル処理手段は、検査に関するイニシャル処理として、前記順序が先頭に定められたアドレスを、前記ブレークアドレスレジスタに設定する処理を実行すると共に、前記判定用フラグを、オフに設定する処理を実行する
構成にされていることを特徴とする請求項１記載の検査システム。
【請求項３】
前記ブレーク割込例外処理手段は、前記ブレーク割込要求が前記ユーザブレークコントローラにより発せられると、当該ブレーク割込要求が、前記順序が最後尾に定められた関数が前記ＣＰＵにより実行されることに起因して発せられたものであるか否かを判断し、当該ブレーク割込要求が、前記順序が最後尾に定められた関数が前記ＣＰＵにより実行されることに起因して発せられたものであると判断すると、前記順序が先頭に定められたアドレスを、前記ブレークアドレスレジスタに設定する
構成にされていることを特徴とする請求項１又は請求項２記載の検査システム。
【請求項４】
前記ＣＰＵにより周期的に繰返し実行されるプログラムを、前記検査対象プログラムとして検査する請求項１〜請求項３のいずれかに記載の検査システムであって、
クリアされた時点からの経過時間を計測する計時手段を備え、
前記判定手段は、前記検査対象プログラムに基づく処理の流れが正常であるか否かを判定する際、前記計時手段をクリアする構成され、
当該検査システムは、更に、
前記計時手段により計測された前記経過時間が、予め設定された閾値を超えると、前記判定手段による処理が異常であると判定する判定異常検知手段
を備える
ことを特徴とする検査システム。
【請求項５】
前記ＣＰＵにより周期的に繰返し実行されるプログラムを、前記検査対象プログラムとして検査する請求項１〜請求項３のいずれかに記載の検査システムであって、
起動時からの経過時間を計測する計時手段を備え、
前記アドレス記憶手段は、前記周期的に実行される前記検査対象プログラムのアドレス及び前記検査対象プログラムに基づき前記ＣＰＵにより実行される複数の関数各々のアドレスを、前記検査対象プログラムのアドレスを前記ブレークアドレスレジスタに最初に設定すべき前記順序が先頭のアドレスとした前記ブレークアドレスレジスタに設定すべき順序の情報と共に記憶し、
前記ブレーク割込例外処理手段は、前記ブレーク割込要求が発せられると、当該ブレーク割込要求が、前記検査対象プログラムの実行が前記ＣＰＵにより開始されることに起因して発せられたものであるか否かを判断し、当該ブレーク割込要求が、前記検査対象プログラムの実行が前記ＣＰＵにより開始されることに起因して発せられたものであると判断すると、前記計時手段を起動して前記計時手段に当該時点からの経過時間を計測させ、
前記判定手段は、前記検査対象プログラムに基づく処理の流れが正常であるか否かを判定する際、前記計時手段を停止する構成にされ、
当該検査システムは、更に、
前記計時手段により計測された経過時間が、予め設定された閾値を超えると、前記判定手段による処理が異常であると判定する判定異常検知手段
を備えることを特徴とする検査システム。
【請求項６】
前記判定異常検知手段は、前記検査対象プログラムの実行周期よりも短い周期で発生する周期割込要求の当該発生毎に起動して、前記計時手段により計測された経過時間が前記閾値を超えていると、前記判定手段による処理が異常であると判定する構成にされていることを特徴とする請求項５記載の検査システム。
【請求項７】
前記ＣＰＵにより周期的に繰返し実行されるプログラムを、前記検査対象プログラムとして検査する請求項１〜請求項３のいずれかに記載の検査システムであって、
前記ブレーク割込例外処理手段は、前記ブレーク割込要求が前記ユーザブレークコントローラにより発せられると、前記判定手段による処理の異常を検知するための異常検知用フラグをオンに設定し、
前記判定手段は、前記検査対象プログラムに基づく処理の流れが正常であるか否かを判定する際、前記異常検知用フラグをオフに設定する構成にされ、
当該検査システムは、更に、
前記検査対象プログラムが実行されていない期間であって尚且つ前記判定手段による処理が実行されていない期間において、繰返し起動し、前記異常検知用フラグがオフに設定されている場合には、前記判定手段による処理が正常であると判定し、前記異常検知用フラグがオンに設定されている場合には、前記判定手段による処理が異常であると判定する判定異常検知手段
を備えることを特徴とする検査システム。
【請求項８】
前記判定手段及び判定異常検知手段としての機能は、当該検査システムが搭載するプログラムを前記ＣＰＵが実行することにより、ソフトウェア的に実現され、
前記判定異常検知手段としての機能を実現するタスクは、前記検査対象プログラムに基づく処理を実現するタスク及び前記判定手段としての機能を実現するタスクよりも、実行優先度が低く設定されていることを特徴とする請求項７記載の検査システム。
【請求項９】
ＣＰＵと、
ブレークアドレスレジスタを内蔵し、当該ブレークアドレスレジスタに設定されたアドレスに対応する関数が、前記ＣＰＵにより実行されるとき、ブレーク条件が満足されたとして、ブレーク割込要求を発するユーザブレークコントローラと、
前記ＣＰＵにより実行される複数の関数各々のアドレスを、前記ブレークアドレスレジスタに設定すべき順序の情報と共に記憶するアドレス記憶手段と、
を備える情報処理システムの前記ＣＰＵに、
前記アドレス記憶手段が記憶する各アドレスの内、前記順序が先頭に定められたアドレスを、前記ブレークアドレスレジスタに設定するイニシャル処理手段と、
前記ブレーク割込要求が前記ユーザブレークコントローラにより発せられると、前記順序が、前記ブレークアドレスレジスタにアドレスが設定されている関数の次に定められた関数のアドレスを、前記ブレークアドレスレジスタに設定するブレーク割込例外処理手段と、
前記ブレーク割込例外処理手段の動作結果に基づき、検査対象のプログラムに基づく処理の流れが正常であるか否かを判定する手段であって、前記順序が最後尾に定められた関数の実行に伴い前記ブレーク割込例外処理手段が動作した場合、前記処理の流れが正常であると判定し、前記順序が最後尾に定められた関数の実行に伴う前記ブレーク割込例外処理手段の動作が生じなかった場合、前記処理の流れが正常ではないと判定する判定手段
としての機能を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、検査システム及びプログラムに関する。
【背景技術】
【０００２】
従来知られるように、プログラム開発に際して、設計者により設計されたプログラムは、デバッグ処理にかけられるが、デバッグ処理では、例えば、ブレークポイントを設定し、当該ブレークポイントにて、プログラムの実行を停止し、その時点で保持する変数等を検査することで行われる（例えば、特許文献１参照）。
【０００３】
また、複数の関数が、設計通りの順序で実行されているか否か等、プログラムに基づく処理の流れが正常であるか否かを検査する方法としては、検査対象のプログラムに基づきＣＰＵにより実行される各関数に、カウンタをカウントアップする処理を付加し、検査する方法が知られている。
【０００４】
図２３は、従来の検査方法を、ＣＰＵが実行する処理を表すフローチャートの形態で、示したものである。
従来手法では、例えば、第１及び第２関数を、第１関数、第２関数の順に実行するプログラムを検査するに際し、第１関数より前段に、カウンタ値を、値ＣＮ＝１に初期化するステップを設けると共に、第２関数より後段に、カウンタ値ＣＮに基づいて、処理の流れが正常であるか否かを判定するための判定処理ステップを設けて、検査対象プログラムを生成する。
【０００５】
このように検査対象プログラムを生成することにより、検査対象プログラムの実行時には、まずカウンタ値ＣＮが値１に初期化され（Ｓ２１１０）、次に第１関数が実行され（Ｓ２１２０）、次に第２関数が実行され（Ｓ２１３０）、更にその次に判定処理が実行される（Ｓ２１４０）ようにする。図２３（ａ）は、検査対象プログラムに基づきＣＰＵが実行する処理を表したフローチャートである。ここでは、説明を簡単にするために、関数が二つである例を挙げるが、本検査方法は、関数が二つである場合に限定されるものではない。
【０００６】
また、検査対象プログラムの生成時には、各関数を次のように設計する。即ち、第ｉ（ｉ＝１，２）関数には、カウンタ値ＣＮ＝ｉであるか否かを判断し（Ｓ２２１０）、カウンタ値ＣＮ＝ｉであれば（Ｓ２２１０でＹｅｓ）、カウンタ値ＣＮを１カウントアップし（Ｓ２２２０）、カウンタ値ＣＮ＝ｉでなければ（Ｓ２２１０でＮｏ）、カウンタ値ＣＮを、エラー値０ｘＦＦに設定する（Ｓ２２３０）ステップを設ける。このようにして、各関数が、設計した実行順に実行されなかった場合に、カウンタ値ＣＮがエラー値に設定されるようにする。
【０００７】
そして、判定処理では、カウンタ値ＣＮが正常値ＣＮ＝３であれば（Ｓ２３１０でＹｅｓ）、第１及び第２関数が設計順に実行されたとして正常判定し（Ｓ２３２０）、カウンタ値ＣＮが正常値ＣＮ＝３でなければ（Ｓ２３１０でＮｏ）、第１及び第２関数が設計順に実行されていないとして異常判定し（Ｓ２３３０）、その判定結果を出力する（Ｓ２３４０）ようにする。
【０００８】
このようにして検査対象プログラムを生成すれば、例えば、プログラムの設計ミス等により第１関数が実行されない場合、第２関数において、カウンタ値ＣＮがエラー値ＣＮ＝０ｘＦＦに設定されるので、プログラムに基づく処理の流れに異常があることを検出することができる。
【０００９】
一方、第１関数は実行されるが第２関数は実行されない場合、カウンタ値ＣＮは、第１関数でカウントアップされて、値ＣＮ＝２に変更されるが、第２関数が実行されないため、検査対象プログラムに基づく処理は、カウンタ値ＣＮ＝２の状態で判定処理に移行する。従って、判定処理では、正常値ＣＮ＝３と一致せず、プログラムに基づく処理の流れに異常があることを検出することができる。このようにして、従来では、検査対象のプログラムに基づく処理の流れが正常であるか否かを検査している。
【特許文献１】特開平６−４３４６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上述した方法で、プログラムに基づく処理の流れが正常であるか否かを検査する従来手法では、プログラムの設計変更により、第１関数及び第２関数との間に、第３関数を追加する場合、各関数におけるＳ２２１０の処理内容、判定処理におけるＳ２３１０の処理内容を変更しなければ、正常な検査を行うことができないといった問題があった。
【００１１】
即ち、従来手法では、関数を追加・削除する度、検査対象プログラムの各関数を修正しなければならず、プログラムに基づく処理の流れが正常であるか否かを検査するに際して、大変な労力がかかるといった問題があった。
【００１２】
本発明は、こうした問題に鑑みなされたものであり、従来よりも簡単に、設計したプログラムに基づく処理の流れが正常であるか否かを検査することが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
かかる目的を達成するため、本発明者らは、ユーザブレークコントローラを用いて検査することを想到するに至った。ここでいうユーザブレークコントローラとは、ブレークアドレスレジスタを内蔵し、ブレークアドレスレジスタに設定されたアドレスに対応する関数が、ＣＰＵにより実行されるとき、ブレーク条件が満足されたとして、ブレーク割込要求を発するものであり、例えば、ＣＰＵを内蔵するマイクロコンピュータに搭載される。
【００１４】
このユーザブレークコントローラに、関数のアドレスを設定すれば、ＣＰＵにより、当該関数が実行されるとき、割込要求信号をユーザブレークコントローラにより発生させることができ、その関数が実行される際に、所定の例外処理を、例えば、ＣＰＵに実行させることができる。本発明は、こうした技術を利用してなされたものである。
【００１５】
具体的に、本発明は、ＣＰＵとユーザブレークコントローラとを備えて、ＣＰＵにより実行されるプログラムを検査する検査システムであって、検査対象のプログラム（以下、「検査対象プログラム」と表現する。）に基づきＣＰＵにより実行される複数の関数各々のアドレスを、ブレークアドレスレジスタに設定すべき順序の情報と共に記憶するアドレス記憶手段を備える。
【００１６】
また、この検査システムは、アドレス記憶手段が記憶する各アドレスの内、順序が先頭に定められたアドレスを、ブレークアドレスレジスタに設定するイニシャル処理手段と、ブレーク割込例外処理手段と、判定手段と、を備える。
【００１７】
ブレーク割込例外処理手段は、ブレーク割込要求がユーザブレークコントローラにより発せられると、上記順序が、ブレークアドレスレジスタにアドレスが設定されている関数の次に定められた関数のアドレスを、ブレークアドレスレジスタに設定する。
【００１８】
判定手段は、このように動作するブレーク割込例外処理手段の動作結果に基づき、検査対象プログラムに基づく処理の流れが正常であるか否かを判定する（請求項１）。具体的に、判定手段は、上記順序が最後尾に定められた関数の実行に伴いブレーク割込例外処理手段が動作した場合、処理の流れが正常であると判定し、上記順序が最後尾に定められた関数の実行に伴うブレーク割込例外処理手段の動作が生じなかった場合、処理の流れが正常ではないと判定する。尚、イニシャル処理手段、ブレーク割込例外処理手段、及び、判定手段としての機能は、ＣＰＵが実行するプログラムにより、ソフトウェア的に実現することができる（請求項９）。
【００１９】
このように構成された本発明の検査システムによれば、検査対象プログラムにおいて、検査すべき関数のアドレスを実行順に記載したテーブル等を、アドレス記憶手段に記憶させておく程度で、検査対象プログラムに基づく処理の流れが正常であるか否かを検査することができる。
【００２０】
本発明のシステムでは、各関数が、アドレス記憶手段に登録された順序に対応する流れで実行される場合、ブレーク割込例外処理手段が、関数の実行毎に起動する。反対に、アドレス記憶手段に登録された関数群の一部がＣＰＵにより実行されない場合や、各関数がアドレス記憶手段に登録された順序に対応する流れで実行されない場合には、異常が生じた以降の関数の実行時にブレーク割込要求が発生しないため、ブレーク割込例外処理手段が、起動されないことになる。
【００２１】
従って、ブレーク割込例外処理手段の動作結果に基づけば、関数の実行抜け等を検知することができ、上述した手法で、検査対象プログラムに基づく処理の流れが正常であるか否かを判定することができるのである。
【００２２】
特に、本発明の検査システムによれば、検査対象プログラムを修正して、第１関数と第２関数との間に第３関数を追加する場合でも、従来技術のように、各関数を修正しなくてよく、アドレス記憶手段に記憶させる関数に対応したアドレス及びその順序を修正する程度で、第３関数追加後のプログラムを正確に検査することができる。従って、本発明によれば、従来よりも簡単に、プログラムに基づく処理の流れが正常であるか否かを検査することができる。
【００２３】
尚、この検査システムには、判定手段の判定結果を、ログや外部装置に出力する出力手段を設けることができる。判定手段の判定結果をログに出力するように、検査システムを構成すれば、設計者は、ログを参照することにより、設計したプログラムの正常／異常を把握することができる。また、外部装置として、例えば、サブＣＰＵに、判定手段の判定結果を出力するようにすれば、サブＣＰＵに、フェールセーフ処理等を実行させることができ、検査システムを搭載した信頼性の高い情報処理システムを、消費者に提供することができる。
【００２４】
また、上述の各検査システムは、具体的に、次のように構成して、処理の流れが正常であるか否かを判定する構成にされるとよい。
即ち、ブレーク割込例外処理手段は、ブレーク割込要求がユーザブレークコントローラにより発せられると、当該ブレーク割込要求が、上記順序が最後尾に定められた関数がＣＰＵにより実行されることに起因して発せられたものであるか否かを判断し、当該ブレーク割込要求が、上記順序が最後尾に定められた関数がＣＰＵにより実行されることに起因して発せられたものではないと判断すると、上記順序が、ブレークアドレスレジスタにアドレスが設定されている関数の次に定められた関数のアドレスを、ブレークアドレスレジスタに設定し、当該ブレーク割込要求が、順序が最後尾に定められた関数がＣＰＵにより実行されることに起因して発せられたものであると判断すると、所定の判定用フラグをオンに設定する構成にされるとよい。
【００２５】
また、判定手段は、上記順序が最後尾に定められた関数の実行後のタイミングで起動して、判定用フラグがオンに設定されている場合には、検査対象プログラムに基づく処理の流れが正常であると判定し、フラグがオフに設定されている場合には、検査対象プログラムに基づく処理の流れが異常であると判定する構成にされるとよい。この他、イニシャル処理手段は、検査に関するイニシャル処理として、上記順序が先頭に定められたアドレスを、ブレークアドレスレジスタに設定する処理を実行すると共に、判定用フラグを、オフに設定する処理を実行する構成にされるとよい（請求項２）。
【００２６】
この検査システムによれば、各関数が正常な流れで実行される限り、ブレーク割込例外処理手段が、関数の実行毎に起動して、最終的に、判定用フラグがオンに設定される。一方、関数の一部が実行されない等で各関数が正常な流れで実行されない場合には、上記順序が最後尾に定められた関数がＣＰＵにより実行されても、ブレーク割込要求が発せられないため、結果的に、ブレーク割込例外処理手段が起動せずに、判定用フラグがオフのままに維持される。
【００２７】
従って、この発明によれば、判定手段において、フラグを参照する程度の簡単な手順で、検査対象プログラムに基づく処理の流れが正常であるか否かを判定することができ、例えば、判定手段としての機能を、プログラムによりＣＰＵに実行させる場合には、ＣＰＵの処理負荷が高くならないようにして、検査を行うことができる。
【００２９】
また、検査対象プログラムが、ＣＰＵにより繰返し実行される類のプログラムである場合、ブレーク割込例外処理手段は、次のように構成されるとよい。
即ち、ブレーク割込例外処理手段は、ブレーク割込要求がユーザブレークコントローラにより発せられると、当該ブレーク割込要求が、上記順序が最後尾に定められた関数がＣＰＵにより実行されることに起因して発せられたものであるか否かを判断し、当該ブレーク割込要求が、上記順序が最後尾に定められた関数がＣＰＵにより実行されることに起因して発せられたものであると判断すると、上記順序が先頭に定められたアドレスを、ブレークアドレスレジスタに設定する構成にされるとよい（請求項３）。
【００３０】
繰返し実行される処理では、第１サイクルで各関数が正常な流れで実行されるものの、それ以降のサイクルでは、ＣＰＵの処理負荷や変数の変化等で、各関数が正常な流れで実行されない場合も考えられる。
【００３１】
従って、繰返し実行される処理については、複数サイクル分検査するのが好ましいが、本発明のように、上記順序が最後尾に定められた関数がＣＰＵにより実行されるときに、ブレークアドレスレジスタに、アドレス記憶手段の内容に基づいて、上記順序が先頭のアドレスを設定するようにすれば、第２サイクル以降についても、第１サイクルと同様に、検査対象プログラムに基づく処理の流れが正常であるか否かを検査することができ、精密にプログラムを検査することができる。
【００３２】
また、ＣＰＵにより周期的に繰返し実行されるプログラムを、検査対象プログラムとして検査する検査システムにおいては、判定手段が、何らかの原因で起動すべきタイミングで起動しないと、検査対象プログラムに基づく処理の流れが正常であるか否かの判定を行うことのできないサイクルが生じることになり、このサイクルで、処理の流れに異常が発生している場合には、その異常を見逃すことにもなりかねない。
【００３３】
従って、ＣＰＵにより周期的に繰返し実行されるプログラムを、検査対象プログラムとして検査する検査システムにおいては、判定手段による処理が正常であるか否かを判定するための手段を設けて、判定手段による処理の異常を検知できるようにするとよい。具体的に、検査システムは、次のように構成されるとよい（請求項４）。
【００３４】
即ち、検査システムには、クリアされた時点からの経過時間を計測する計時手段を設けて、検査対象プログラムに基づく処理の流れが正常であるか否かを判定する際に、計時手段をクリアするように、判定手段を構成するとよい。そして、当該検査システムには、計時手段により計測された経過時間が、予め設定された閾値を超えると、判定手段による処理が異常であると判定する判定異常検知手段を設けるとよい。
【００３５】
この検査システムのようにして、経過時間が閾値を超えると、判定手段による処理の異常を検知するようにすれば、判定手段にて、処理の流れが正常であるか否かの判定がなされたか否かを、簡単な手順で、正確に把握することができる。結果、この発明によれば、判定手段の異常に気づかず、設計者等が、検査対象プログラムが正常であると錯誤してしまうのを防止することができる。
【００３６】
この他、ＣＰＵにより周期的に繰返し実行されるプログラムを、検査対象プログラムとして検査する検査システムは、次のように構成されてもよい。
即ち、検査システムには、起動時からの経過時間を計測する計時手段を設ける。また、アドレス記憶手段には、上記周期的に実行される検査対象プログラムのアドレス及び当該検査対象プログラムに基づきＣＰＵにより実行される複数の関数各々のアドレスを、検査対象プログラムのアドレスをブレークアドレスレジスタに最初に設定すべきアドレスとした上記ブレークアドレスレジスタに設定すべき順序の情報と共に登録する。
【００３７】
そして、ブレーク割込要求が発せられると、当該ブレーク割込要求が、検査対象プログラムの実行がＣＰＵにより開始されることに起因して発せられたものであるか否かを判断し、当該ブレーク割込要求が、検査対象プログラムの実行がＣＰＵにより開始されることに起因して発せられたものである場合には、計時手段を起動して計時手段に当該時点からの経過時間を計測させるように、ブレーク割込例外処理手段を構成する。この他、検査対象プログラムに基づく処理の流れが正常であるか否かを判定する際、計時手段を停止するように、判定手段を構成する。
【００３８】
更に、検査システムには、計時手段により計測された経過時間が、予め設定された閾値を超えると、判定手段による処理が異常であると判定する判定異常検知手段を設ける（請求項５）。
【００３９】
この検査システムによれば、イニシャル処理により、上記順序が先頭である検査対象プログラムのアドレスがユーザブレークコントローラに設定されて、検査対象プログラムの実行時に、ブレーク割込要求が発せられ、計時手段が起動する。そして、この後に判定手段が正常に動作すれば、計時手段は停止されるが、判定手段が正常に動作しなければ、計時手段は停止しない。
【００４０】
従って、このように検査システムを構成すれば、判定手段にて、処理の流れが正常であるか否かの判定がなされたか否かを、簡単な手順で、正確に把握することができ、請求項４記載の発明と同様に、判定手段の異常に気づかず、設計者等が、検査対象プログラムが正常であると錯誤してしまうのを防止することができるのである。
【００４１】
特に、この検査システムによれば、検査対象プログラムに基づく周期処理の実行開始時に、計時手段を起動して、その時点からの経過時間を計測するので、正確且つ迅速に判定手段の実行抜けを検知することができ、検査対象プログラムに基づく処理の異常を、迅速に報知し、又、迅速にフェールセーフ処理を実行することができる。
【００４２】
具体的に、迅速に判定手段の実行抜けを検知することができるようにするためには、検査対象プログラムの実行周期よりも短い周期で割込要求信号（周期割込要求）を発生させて、周期割込要求の当該発生毎、換言すれば、検査対象プログラムの実行周期よりも短い周期で、判定異常検知手段が起動するように、検査システムを構成すればよい。
【００４３】
このようにすれば、毎サイクル、判定異常検知手段を起動することができて、判定手段の実行抜けを迅速に検知することができる（請求項６）。
また、ＣＰＵにより周期的に繰返し実行されるプログラムを、検査対象プログラムとして検査する検査システムは、次のようにして、判定手段の異常を検知する構成にされてもよい。
【００４４】
即ち、ブレーク割込要求がユーザブレークコントローラにより発せられると、判定手段による処理の異常を検知するための異常検知用フラグをオンに設定するように、ブレーク割込例外処理手段を構成すると共に、検査対象プログラムに基づく処理の流れが正常であるか否かを判定する際、異常検知用フラグをオフに設定するように、判定手段を構成する。
【００４５】
そして、当該検査システムには、検査対象プログラムが実行されていない期間であって尚且つ判定手段による処理が実行されていない期間において、繰返し動作し、異常検知用フラグがオフに設定されている場合には、判定手段による処理が正常であると判定し、異常検知用フラグがオンに設定されている場合には、判定手段による処理が異常であると判定する判定異常検知手段を設ける（請求項７）。
【００４６】
この検査システムによっても、判定手段にて、処理の流れが正常であるか否かの判定がなされたか否かを、簡単な手順で、正確に把握することができ、請求項４，５記載の発明と同様に、判定手段の異常に気づかず、設計者等が、検査対象プログラムが正常であると錯誤してしまうのを防止することができる。
【００４７】
また、検査システムが搭載するプログラムをＣＰＵに実行させることにより、この検査システム（請求項７記載）における判定手段及び判定異常検知手段としての機能を、ソフトウェア的に実現させる場合には、判定異常検知手段としての機能を実現するタスクの実行優先度を、検査対象プログラムに基づく処理を実現するタスク及び判定手段としての機能を実現するタスクの実行優先度よりも、低く設定するとよい。このように実行優先度を設定すれば、判定異常検知手段を、検査対象プログラムが実行されていない期間であって尚且つ判定手段による処理が実行されていない期間において起動することができる（請求項８）。
【００５２】
また、上記各手段としての機能は、プログラムにより、ＣＰＵにて実現することができ、当該プログラムを、メモリ等の記憶手段に記憶させて、検査システムを構成すれば、ソフトウェア的に、上記検査の手順を実現することができる（請求項９）。
【００５３】
そして、これらのプログラムを、ユーザブレークコントローラを内蔵するマイクロコンピュータ等に搭載すれば、ＣＰＵにより実行される検査対象プログラムに基づく処理の流れが正常であるか否かを、簡単な手順で、適切に検査することができる。
【発明を実施するための最良の形態】
【００５４】
以下に本発明の実施例について、図面と共に説明する。但し、本発明は、以下に説明する実施例に限定されるものではなく、種々の態様を採りうることは言うまでもない。
【実施例１】
【００５５】
図１（ａ）は、本実施例（第一実施例）のマイクロコンピュータ（以下、「マイコン」と表現する。）１０の構成を表すブロック図である。図１（ａ）に示すように、本実施例のマイコン１０は、各種演算処理を行うＣＰＵ１１と、フラッシュメモリ１３と、ＣＰＵ１１によるプログラム実行時に作業領域として使用されるＲＡＭ１５と、割込コントローラ１７と、ユーザブレークコントローラ（ＵＢＣ）１８と、外部装置と通信可能なインタフェース１９と、を備える。
【００５６】
ユーザブレークコントローラ１８は、周知のユーザブレークコントローラと同様であり、ブレークアドレスレジスタ１８ａを内蔵すると共に、ＣＰＵ１１に通じる内部アドレスバスに接続されたブレーク条件比較部１８ｂを備え、ブレークアドレスレジスタ１８ａに設定されたアドレスに対応する関数（命令）が、ＣＰＵ１１により実行されるとき、ブレーク条件が満足されたとして、ブレーク割込要求を、割込コントローラ１７を介してＣＰＵ１１に入力するものである。図１（ｂ）は、ユーザブレークコントローラ１８の構成を表すブロック図である。
【００５７】
このユーザブレークコントローラ１８は、具体的に、ブレークアドレスレジスタ１８ａに設定されたアドレスに対応する関数がＣＰＵ１１により実行される直前に、ブレーク割込要求を割込コントローラ１７に入力する。
【００５８】
割込コントローラ１７は、ＣＰＵ１１への割込要求を制御するものであり、ユーザブレークコントローラ１８から割込コントローラ１７に入力されたブレーク割込要求は、ＣＰＵ１１に入力される。
【００５９】
ＣＰＵ１１は、このブレーク割込要求を受けると、プログラムカウンタに設定された次命令のアドレス（ブレークアドレスレジスタ１８ａに設定されたアドレスに一致）を一旦退避させ、ブレーク割込要求に対応する例外処理（図５参照）を実行する。そして、この処理を終えると、退避させたアドレスに対応する命令（関数）を読み出して実行する。
【００６０】
このような構成のマイコン１０に対しては、予め、フラッシュメモリ１３に、ＣＰＵ１１にて実行される各種プログラムやデータが書き込まれる。また、本実施例では、マイコン１０を、検査システムとして機能させるため、フラッシュメモリ１３に、ＣＰＵ１１により実行される関数のアドレスが記述されたアドレス設定テーブルが書き込まれる。
【００６１】
本実施例では、ユーザブレークコントローラ１８を用いて、マイコン１０が実行するプログラムの処理の流れを検査するが、アドレス設定テーブルは、当該処理の流れを検査するため、予め設計者によりフラッシュメモリ１３に書き込まれるものである。
【００６２】
従来知られるように、プログラムは、設計された通りにＣＰＵにて実行されるか否か検査されるが、本実施例では、マイコン１０による検査対象のプログラムの実行時に、当該プログラム内の関数が設計通りの順序で実行されるか否かを検査するため、設計した実行順で検査対象の関数のアドレスを記述して、アドレス設定テーブルを生成する。そして、これを予めフラッシュメモリ１３に書き込む。
【００６３】
図２は、アドレス設定テーブルの構成を表す説明図である。例えば、検査対象のプログラムにおいて、第１関数から第Ｎ関数までのＮ個の関数が、設計した順序でＣＰＵ１１により実行されるか否かを検査する場合には、実行順が先頭の第１関数のアドレスを、アドレス設定テーブルの第０番地（ｉ＝０）に記述し、実行順がｋ番目の第ｋ関数のアドレスを、アドレス設定テーブルの第（ｋ−１）番地に記述し、実行順が最後尾であるＮ番目の第Ｎ関数のアドレスを、アドレス設定テーブルの第（Ｎ−１）番地に記述する。そして、アドレス設定テーブルの第Ｎ番地に、エンドオブテーブル（ＥＯＴ）のコードを記述して、アドレス設定テーブルを生成し、これをフラッシュメモリ１３に書き込む。
【００６４】
尚、検査する関数は、検査対象のプログラムに記述された関数の全てとする必要はなく、検査を所望する関数のみを抽出して、この関数のアドレスを、アドレス設定テーブルに設定すればよい。
【００６５】
本実施例では、このようにして生成したアドレス設定テーブルを、フラッシュメモリ１３に登録して、ＣＰＵ１１に後述する処理を実行させることにより、アドレス設定テーブルに登録された各関数のアドレスを、順にブレークアドレスレジスタ１８ａに設定し、ブレーク割込要求に応じてＣＰＵ１１が実行するブレーク割込例外処理の実行履歴に基づき、検査対象プログラムに基づく処理の流れが正常であるか否かを検査する。
【００６６】
具体的に、本実施例では、検査に先立って、検査対象とする第１〜第Ｎ関数の他に、第Ｎ関数より後段のステップに、図７に示す判定処理のステップを設けて、検査対象プログラムを設計する（図４参照）。また、検査対象プログラムの実行に先駆けて図３に示すイニシャル処理をＣＰＵ１１に実行させるためのイニシャル処理プログラムを設計し、更に、図５に示すブレーク割込例外処理をＣＰＵ１１に実行させるための例外処理プログラムを設計し、これらのプログラムと上記アドレス設定テーブルを、フラッシュメモリ１３に登録する手続を行う。
【００６７】
このような手続を経てフラッシュメモリ１３にプログラム等が記憶されたマイコン１０は、次のように動作して、プログラムの検査を実現する。
まず、検査対象プログラムの実行に先駆けては、ＣＰＵ１１により上述のイニシャル処理プログラムが実行される。図３は、ＣＰＵ１１がイニシャル処理プログラムに基づき実行するイニシャル処理を表すフローチャートである。
【００６８】
ＣＰＵ１１は、イニシャル処理を実行すると、まずアドレス設定テーブルの参照位置を表すポインタ変数ｉをゼロに初期化すると共に、フラグとして使用するパラメータＦＡ（以下、単に「フラグＦＡ」と表現する。）を、オフ値（値「０」）に設定する（Ｓ１１０）。また、フラッシュメモリ１３に記憶されたアドレス設定テーブルを参照して、アドレス設定テーブルにおける第０番地に記述された関数のアドレスを、ブレークアドレスレジスタ１８ａに設定する（Ｓ１２０）。このようにして、検査のための前処理（イニシャル処理）を終了する。
【００６９】
また、イニシャル処理を終えると、ＣＰＵ１１は、検査対象プログラムを実行する。図４は、ＣＰＵ１１が検査対象プログラムに基づき実行する処理を表すフローチャートである。
【００７０】
本実施例における検査対象プログラムは、ＣＰＵ１１により周期的に繰返し実行されるプログラムである。即ち、図４に示す処理は、ＣＰＵ１１により、周期的に繰返し実行される。以下では、検査対象プログラムに基づく上記周期的な処理を、単に「周期処理」と表現する。尚、周期的に繰返し実行されるプログラムとしては、例えば、周期的な制御が必要な車両制御用プログラム等を挙げることができる。
【００７１】
ＣＰＵ１１は、検査対象プログラムの実行を開始すると、第１関数から第Ｎ関数（図では、Ｎ＝３）までの処理を順に実行した後（Ｓ２１０〜Ｓ２３０）、図７に示す判定処理を実行し、１サイクル分の周期処理を終える。そして、当該検査対象プログラムの実行開始から所定時間が経過すると、再び、検査対象プログラムの実行を開始して、図４に示す処理を周期的に繰返し実行する。
【００７２】
但し、上述した検査対象プログラムに基づく周期処理の流れは、設計上の話であり、プログラムの設計ミス等で、図４に示す正常な流れで、処理が実行されない可能性がある。例えば、関数の一部が実行されない可能性がある。
【００７３】
本実施例では、イニシャル処理で、検査対象の第１関数がＣＰＵ１１にて実行される際に、ユーザブレークコントローラ１８からブレーク割込要求が発せられるようにするが、このブレーク割込要求に対応して、図５に示すブレーク割込例外処理を実行することにより、上述のようなエラーを検知する。
【００７４】
続いては、ユーザブレークコントローラ１８から発せられるブレーク割込要求に対応する例外処理として、ＣＰＵ１１が実行するブレーク割込例外処理について、図５を用いて説明する。図５は、ブレーク割込例外処理を表すフローチャートである。
【００７５】
ＣＰＵ１１は、割込コントローラ１７を通じてユーザブレークコントローラ１８からブレーク割込要求が入力されると、まず、ポインタ変数ｉを１加算した値に更新する（Ｓ３１０）。その後、アドレス設定テーブルの第ｉ番地に設定された値Ｔ［ｉ］を読出し、値Ｔ［ｉ］がＥＯＴであるか否かを判断する（Ｓ３２０）。そして、値Ｔ［ｉ］がＥＯＴではないと判断すると（Ｓ３２０でＮｏ）、Ｓ３５０に移行して、アドレス設定テーブルの第ｉ番地に設定された値Ｔ［ｉ］を、ブレークアドレスレジスタ１８ａに設定する。その後、当該ブレーク割込例外処理を終了する。
【００７６】
一方、値Ｔ［ｉ］がＥＯＴであると判断すると（Ｓ３２０でＹｅｓ）、ＣＰＵ１１は、Ｓ３３０に移行して、フラグＦＡを、オン値（値「１」）に設定すると共に、ポインタ変数ｉを値０に初期化する（Ｓ３４０）。その後、アドレス設定テーブルの第ｉ＝０番地に設定された値Ｔ［０］を、ブレークアドレスレジスタ１８ａに設定し（Ｓ３５０）、当該ブレーク割込例外処理を終了する。
【００７７】
このようにして、ブレーク割込例外処理では、当該例外処理を実行する原因となったブレーク割込要求が、アドレス設定テーブルにおいて、実行順が最後尾に定められた関数がＣＰＵ１１により実行されることに起因して発せられたものであるか否かを判断し（Ｓ３２０）、当該ブレーク割込要求が、実行順が最後尾に定められた関数がＣＰＵ１１により実行されることに起因して発せられたものではないと判断すると（Ｓ３２０でＮｏ）、アドレス設定テーブルにおいて、実行順が、ブレークアドレスレジスタ１８ａにアドレスが設定されている関数の次に定められた関数のアドレスを、ブレークアドレスレジスタ１８ａに設定する（Ｓ３５０）。
【００７８】
一方、ブレーク割込要求が、実行順が最後尾に定められた関数がＣＰＵ１１により実行されることに起因して発せられたものであると判断すると（Ｓ３２０でＹｅｓ）、フラグＦＡをオン値に設定すると共に、アドレス設定テーブルにおいて、実行順が先頭に定められた関数のアドレスＴ［０］を、ブレークアドレスレジスタ１８ａに設定する（Ｓ３５０）。
【００７９】
尚、このブレーク割込例外処理は、検査対象プログラムに基づいてＣＰＵ１１が、アドレス設定テーブルに登録された各関数を、その設定された順序で実行する限り、各関数の実行毎に、その関数の実行直前に実行される（図４参照）。そして、各関数が正常な順序で実行されると、実行順が最後尾に設定された第Ｎ関数がＣＰＵ１１に実行されることに起因して、ブレーク割込要求が発生し、このブレーク割込要求に対応するブレーク割込例外処理にて、フラグＦＡがオン値に設定される。図６は、検査対象プログラムに基づく各関数の実行タイミングと、ブレーク割込例外処理の実行タイミングと、フラグＦＡの設定値との対応関係を示したタイムチャートである。
【００８０】
一方、アドレス設定テーブルに登録された関数の一つが、プログラムの設計ミス等でＣＰＵ１１により実行されなかったときには、設計上、その関数の実行時点で実行されるはずのブレーク割込例外処理が実行されないことになるので、ブレークアドレスレジスタ１８ａの値を、更新することができなくなり、当該実行されなかった関数以降の実行順に設定された関数がＣＰＵ１１により実行されても、ブレーク割込要求が発生しないことになる。図６右側には、第２関数〜第Ｎ（Ｎ＝３）関数がＣＰＵ１１により実行されなかった場合のブレーク割込例外処理の実行タイミング及びフラグＦＡの設定値の変化を表す。
【００８１】
従って、この場合には、実行順が最後尾の関数がＣＰＵ１１により実行されるときにオン値に更新されるはずのフラグＦＡの値がオフ値のままに維持されることになる。
即ち、本実施例では、フラグＦＡの値が、最後尾の第Ｎ関数の実行が完了する時点でオンに設定されている場合には、検査対象プログラム内の各関数が、アドレス設定テーブルにて設定された実行順の通りに実行されたことになり、フラグＦＡの値が、最後尾の第Ｎ関数の実行が完了する時点でオフに設定されている場合には、検査対象プログラムに基づく処理の流れに異常が生じたことになる。
【００８２】
本実施例では、このような情報を含むフラグＦＡの値に基づき、検査対象プログラムにおける第Ｎ関数の後段ステップに設けられた判定処理で、処理の流れが正常であるか否かを判定する。
【００８３】
続いて、ＣＰＵ１１が実行する判定処理について説明する。図７は、ＣＰＵ１１が実行する判定処理（Ｓ２４０参照）を表すフローチャートである。
ＣＰＵ１１は、この判定処理を開始すると、フラグＦＡがオン値に設定されているか否かを判断し（Ｓ４１０）、フラグＦＡがオン値に設定されていると判断すると（Ｓ４１０でＹｅｓ）、検査対象プログラムに基づく処理の流れが正常であると判定する（Ｓ４２０）。その後、フラグＦＡをオフ値に設定して（Ｓ４４０）、Ｓ４２０での判定結果（「処理フロー正常」との情報）を出力し（Ｓ４５０）、当該判定処理を終了する。
【００８４】
尚、Ｓ４５０では、例えば、ログファイルに判定結果を出力すればよい。この他、マイコン１０のインタフェース１９に、サブマイコン等の外部装置が接続されている環境では、外部装置に、判定結果を出力してもよい。
【００８５】
一方、ＣＰＵ１１は、フラグＦＡがオフ値に設定されていると判断すると（Ｓ４１０でＮｏ）、検査対象プログラムに基づく処理の流れが異常であると判定する（Ｓ４３１）。その後、ポインタ変数ｉを値０に初期化して（Ｓ４３３）、アドレス設定テーブルにおける第０番地の値Ｔ［０］を、ブレークアドレスレジスタ１８ａに設定し（Ｓ４３５）、更に、フラグＦＡをオフ値に設定する（Ｓ４４０）。そして、Ｓ４３１での判定結果（「処理フロー異常」との情報）を出力する（Ｓ４５０）。その後、当該判定処理を終了する。
【００８６】
尚、Ｓ４４０で、フラグＦＡをオフ値に設定するのは、周期処理の次サイクルにおいても、フラグＦＡに基づいて、処理の流れが正常であるか否かを判定処理にて判定できるようにするためである。
【００８７】
以上、本実施例のマイコン１０の構成について説明したが、本実施例によれば、検査対象プログラムにおいて、検査すべき関数のアドレスを実行順に記載したアドレス設定テーブルを生成し、これをフラッシュメモリ１３に書き込む程度で、検査対象プログラムに基づく処理の流れが正常であるか否かを判定することができ、簡単にプログラムの検査を行うことができる。
【００８８】
即ち、本実施例によれば、従来技術のように、各関数に、カウンタＣＮをカウントアップするステップ（Ｓ２２１０〜Ｓ２２３０（図２３参照））を追加しなくても、検査対象プログラムに基づく処理の流れが正常であるか否かを判定することができ、従来よりも簡単に、プログラムに基づく処理の流れが正常であるか否かを検査することができる。
【００８９】
特に、本実施例によれば、検査対象プログラムを修正して、既存の関数の間に新規関数を追加することで、各関数の設計上の実行順が変化することがあっても、従来技術のように、各関数を修正しなくてもよく、アドレス設定テーブルの記述を修正する程度で、関数追加後のプログラムを正確に検査することができる。従って、本実施例によれば、プログラムの修正労力を大きく低減できる。
【００９０】
尚、検査に必要なマイコン１０の構成は、プログラム設計時のみに導入し、判定処理による判定結果の情報は、プログラムの修正にのみ活用されてもよいが、例えば、出荷する製品にも、検査に必要な構成（検査に必要なプログラム等）をマイコン１０に搭載し、判定結果をフェールセーフ処理に活用されてもよい。
【００９１】
例えば、マイコン１０を、メインマイコンとして、車両制御用のプログラムを、メインマイコンに実行させる場合には、上記車両制御用のプログラムを、検査対象プログラムとして、検査に必要な上述の処理を、車両制御と並行してメインマイコンに実行させる。また、マイコン１０には、インタフェース１９を通じて、サブマイコンを通信可能に接続する。そして、マイコン１０からは判定結果をサブマイコンに出力するようにし、サブマイコンでは、判定結果に応じ、フェールセーフ処理を実行するようにする。
【００９２】
このようにして、フェールセーフ処理を実行するように車両制御システムを構成すれば、プログラムの実行エラーにも適切に対応することができ、信頼性の高い車両制御システムを、消費者に提供することができる。
【００９３】
尚、請求項１〜３記載のアドレス記憶手段は、本実施例において、フラッシュメモリ１３が記憶するアドレス設定テーブルの当該記憶領域に相当する。また、イニシャル処理手段は、ＣＰＵ１１が実行する図３に示すイニシャル処理にて実現され、ブレーク割込例外処理手段は、ＣＰＵ１１が実行する図５に示すブレーク割込例外処理にて実現され、判定手段は、ＣＰＵ１１が実行する図７に示す判定処理にて実現されている。
【実施例２】
【００９４】
続いては、第二実施例を、図８及び図９を用いて説明する。図８は、第二実施例において、ＣＰＵ１１が実行するブレーク割込例外処理を表すフローチャートであり、図９は、判定処理が何らかの原因にて実行されなかったときの、フラグＦＡの設定値の変化態様を表したタイムチャートである。
【００９５】
以下に説明する第二実施例は、第一実施例のマイコン１０に対して、判定処理の実行抜けを検知するための機能を付加したものであり、第二実施例のマイコン１０の構成は、ＣＰＵ１１が実行するブレーク割込例外処理の内容が異なる以外、第一実施例と同一である。従って、以下では、第二実施例の説明として、図８に示すブレーク割込例外処理の内容を選択的に説明する。
【００９６】
ＣＰＵ１１は、ブレーク割込要求の発生に応じて、図８に示すブレーク割込例外処理を開始すると、まず、フラグＦＡがオフ値に設定されているか否かを判断する（Ｓ５０１）。そして、フラグＦＡがオフ値に設定されていると判断すると（Ｓ５０１でＹｅｓ）、Ｓ５０３，Ｓ５０５の処理を実行することなく、Ｓ５１０に移行する。
【００９７】
一方、フラグＦＡがオン値に設定されていると判断すると（Ｓ５０１でＮｏ）、判定処理が異常である（換言すると、判定処理の実行抜けが生じた）と判定し（Ｓ５０３）、その判定結果（判定処理が異常である旨の情報）を出力する（Ｓ５０５）。その後、Ｓ５１０に移行する。尚、Ｓ５０５では、Ｓ４５０の処理と同様、判定結果をログファイルや外部装置に出力することができる。
【００９８】
また、Ｓ５１０に移行すると、ＣＰＵ１１は、ポインタ変数ｉを１加算した値に更新した後、上述したＳ３２０〜Ｓ３５０の処理（図５参照）と同様にして、Ｓ５２０〜Ｓ５５０の処理を実行する。その後、当該ブレーク割込例外処理を終了する。
【００９９】
以上、第二実施例のマイコン１０の構成について説明したが、本実施例では、判定処理が、フラグＦＡをオフ値に初期化する手順を含むので（図７参照）、第Ｎ関数にてフラグＦＡがオンに設定されている環境で、判定処理が実行されないと、フラグＦＡがオンに設定されたままの状態で、次サイクルの処理が実行される。
【０１００】
第二実施例では、この現象を利用して、図９に示すように、前サイクルで判定処理が実行されず、フラグＦＡがオン値に設定されたままの状態である場合には、次サイクルの第１関数が実行されるときに行う上述のブレーク割込例外処理にて、判定処理の実行抜けを検知し、この異常を報知する。従って、第二実施例によれば、第一実施例と比較して、より適切な検査を行うことができる。
【０１０１】
但し、第二実施例の手法では、第１〜第Ｎ関数が正常にＣＰＵ１１にて実行されないと、フラグＦＡがオン値に設定されないので、結果的に、判定処理の実行抜けを検知することができない。従って、判定処理の実行抜けについては、次の手順で検知すると、一層好ましい（第三実施例）。
【実施例３】
【０１０２】
続いては、第三実施例を、図１０〜図１５を用いて説明する。但し、第三実施例のマイコン１０については、上述した第一実施例のマイコン１０と同一構成の部位も多いため、以下では、第三実施例の説明として、第一実施例とは異なるマイコン１０の構成について選択的に説明し、同一構成の部位についての説明を省略する。
【０１０３】
図１０上段は、第三実施例において、マイコン１０のフラッシュメモリ１３に書き込まれるアドレス設定テーブルの構成を表す説明図である。
本実施例においては、検査対象プログラムに基づく周期処理の流れが正常であるか否かを検査するために、第１関数〜第Ｎ関数のアドレスと共に、第１関数〜第Ｎ関数を呼び出す親関数のアドレス、即ち、検査対象プログラムのアドレスを、アドレス設定テーブルに登録する。具体的に、本実施例では、親関数のアドレスを、アドレス設定テーブルの第０番地に記述し、第ｋ（ｋ＝１，２，…，Ｎ）関数のアドレスを、アドレス設定テーブルの第ｋ番地に記述し、第Ｎ＋１番地にエンドオブテーブル（ＥＯＴ）のコードを記述して、アドレス設定テーブルを生成する。そして、これをフラッシュメモリ１３に登録する。
【０１０４】
本実施例では、このようにして、ＣＰＵ１１が第１関数〜第Ｎ関数を実行するときだけでなく、周期処理を実行するときにも、ユーザブレークコントローラ１８からブレーク割込要求が発生するようにする（図１０下段参照）。
【０１０５】
また、図１１は、本実施例において、ＣＰＵ１１が実行するブレーク割込例外処理を表すフローチャートである。
ＣＰＵ１１は、このブレーク割込例外処理を開始すると、まずポインタ変数ｉが値０であるか否かを判断し（Ｓ６０１）、ポインタ変数ｉ＝０であると判断すると（Ｓ６０１でＹｅｓ）、マイコン１０に内蔵されたタイマ２１をゼロ（ＴＭ＝０）にリセットし（Ｓ６０３）、タイマ２１をスタートさせる（Ｓ６０５）。その後、Ｓ６１０に移行する。
【０１０６】
尚、タイマ２１はスタートさせられると、その時点からの経過時間を計測して、その経過時間をタイマ値ＴＭとして更新する。尚、マイコン１０には、タイマ２１の他に、所定周期で割込要求を発するインターバルタイマ２３が設けられており、このインターバルタイマ２３の割込要求（以下、「周期割込要求」と表現する。）は、割込コントローラ１７を介して周期的にＣＰＵ１１に入力される。
【０１０７】
一方、ポインタ変数ｉ＝０ではないと判断すると（Ｓ６０１でＮｏ）、ＣＰＵ１１は、Ｓ６０３，Ｓ６０５の処理を実行せずに、Ｓ６１０に移行する。また、Ｓ６１０に移行すると、ＣＰＵ１１は、ポインタ変数ｉを１加算した値に更新した後、Ｓ３２０〜Ｓ３５０の処理（図５参照）と同様に、Ｓ６２０〜Ｓ６５０の処理を実行する。そして、Ｓ６５０での処理を終えると、当該ブレーク割込例外処理を終了する。
【０１０８】
即ち、本実施例のブレーク割込例外処理では、当該ブレーク割込例外処理を実行する原因となったブレーク割込要求が、アドレス設定テーブルにおいて実行順が先頭に設定された親関数がＣＰＵ１１により実行されることに起因して発せられたものであるか否かを判断し（Ｓ６０１）、当該ブレーク割込要求が、親関数がＣＰＵ１１により実行されることに起因して発せられたものである場合に限って、タイマ２１をリセットしスタートさせる（Ｓ６０３，Ｓ６０５）。このようにして、本実施例では、周期処理が実行される時点で、タイマ２１を起動し、この時点からの経過時間をタイマ２１に計測させる。
【０１０９】
尚、図１２は、検査対象プログラムに基づく周期処理が正常に実行されているときの、各関数の実行タイミングと、ブレーク割込例外処理の実行タイミングと、フラグＦＡの設定値と、タイマ値ＴＭと、後述する周期割込例外処理（図１４参照）の実行タイミングとの対応関係を示したタイムチャートである。
【０１１０】
また、図１３は、本実施例において、ＣＰＵ１１が実行する判定処理（図１０：Ｓ２４０参照）を表すフローチャートである。本実施例においては、判定処理を開始すると、まずタイマ２１を停止させて、タイマ値ＴＭが更新されないようにする（Ｓ７００）。その後、Ｓ４１０〜Ｓ４５０の処理（図７参照）と同様にして、Ｓ７１０〜Ｓ７５０の処理を実行する。そして、Ｓ７５０の処理を終えると、当該判定処理を終了する。
【０１１１】
このようにして、本実施例では、判定処理の実行時、第一実施例と同様の処理を実行すると共に、タイマ値ＴＭがタイムアウトしないようにする。
この他、図１４は、第三実施例において、周期割込要求が入力されるとＣＰＵ１１が実行する周期割込例外処理を表すフローチャートである。即ち、図１４に示す処理は、周期割込要求に対応する例外処理として、周期割込要求が入力される度、ＣＰＵ１１により実行される。
【０１１２】
周期割込例外処理を開始すると、ＣＰＵ１１は、タイマ２１が保持するタイマ値ＴＭに基づいて、タイマスタート時点からの経過時間が、予め設定されたタイムアウト時間に到達したか否かを判断し、経過時間がタイムアウト時間未満であると判断すると（Ｓ８１０Ｎｏ）、Ｓ８２０〜Ｓ８５０の処理を実行することなく、当該周期割込例外処理を終了する。
【０１１３】
一方、タイマスタート時点からの経過時間が、予め設定されたタイムアウト時間に到達したと判断すると（Ｓ８１０でＹｅｓ）、タイマ２１を停止させると共に（Ｓ８２０）、フラグＦＡをオフ値に設定する（Ｓ８３０）。また、判定処理が異常である（判定処理の実行抜けが発生した）と判定して（Ｓ８４０）、その判定結果（判定処理が異常である旨の情報）を出力する（Ｓ８５０）。その後、当該周期割込例外処理を終了する。
【０１１４】
本実施例では、このようにして、タイムアウトが発生しているか否かを周期的に判断し、タイムアウトが発生している場合には、判定処理の実行抜けが生じたと判定する。但し、本実施例においては、インターバルタイマ２３から出力される周期割込要求の出力周期を、検査対象プログラムに基づきＣＰＵ１１により実行される周期処理の実行周期よりも十分に短くする。
【０１１５】
具体的には、周期処理が正常に実行されているときに判定処理が実行される時点から、周期処理の次サイクルから開始されるまでの期間に、少なくとも１回以上の周期割込要求が発生するように、周期割込要求の出力周期を設定する。
【０１１６】
このように周期割込要求の出力周期を設定して、マイコン１０を構成すると、判定処理がＣＰＵ１１により正常に実行されなかったときには、次サイクルの周期処理が開始される前に、周期割込例外処理にて、判定処理が異常であると判定され、その旨の情報が出力されることになる。
【０１１７】
尚、図１５は、判定処理の実行抜けが生じたときのタイマ２１の状態変化を表したタイムチャートである。本実施例では、タイムアウト時間を、周期処理の実行開始時点から判定処理の実行開始時点までの時間間隔よりも長く、周期処理の実行周期よりも短い時間間隔に定めているので、次サイクルの周期処理が開始される前に、周期割込例外処理にて、タイムアウトを検知することができ、判定処理の異常を検知することができる。
【０１１８】
以上、第三実施例について説明したが、本実施例によれば、第二実施例とは異なり、第１関数〜第Ｎ関数が正常に実行されても、正常に実行されなくても、判定処理の実行抜けを検知できるので、より適切な検査を実現することができる。即ち、第１関数〜第Ｎ関数の一部が実行されず判定処理も実行されないときに、その異常を検知することができないことによって、判定処理の異常に気づかず、設計者等が、検査対象プログラムが正常であると錯誤してしまうのを防止することができる。
【０１１９】
特に、本実施例によれば、次サイクルの周期処理が実行されるまでの間に、判定処理の異常を検知することができるので、例えば、この異常に基づいて、迅速にフェールセーフ処理を実行することができる。
【０１２０】
尚、請求項５，６記載の計時手段は、本実施例におけるタイマ２１に相当し、アドレス記憶手段は、フラッシュメモリ１３が記憶するアドレス設定テーブル（図１０参照）の当該記憶領域に相当する。また、ブレーク割込例外処理手段は、本実施例においてＣＰＵ１１が実行する図１１に示すブレーク割込例外処理にて実現され、判定手段は、ＣＰＵ１１が実行する図１３に示す判定処理にて実現され、判定異常検知手段は、ＣＰＵ１１が実行する周期割込例外処理にて実現されている。
【実施例４】
【０１２１】
続いて、第四実施例を、図１６を用いて説明する。図１６（ａ）は、第四実施例において、ＣＰＵ１１が実行する判定処理を表すフローチャートであり、図１６（ｂ）は、第四実施例において、ＣＰＵ１１が実行する周期割込例外処理を表すフローチャートである。
【０１２２】
以下に説明する第四実施例は、第一実施例のマイコン１０に、インターバルタイマ２３を設けると共に、図７に示す判定処理に代えて、図１６（ａ）に示す判定処理をＣＰＵ１１に実行させるためのプログラムを、フラッシュメモリ１３に搭載し、更に、図１６（ｂ）に示す周期割込例外処理をＣＰＵ１１に実行させるためのプログラムを、フラッシュメモリ１３に搭載した程度のものである。従って、以下では、第四実施例のマイコン１０の説明として、第一実施例と異なる構成を選択的に説明し、その他の説明を省略する。
【０１２３】
まず、本実施例においてＣＰＵ１１が実行する判定処理は、先頭ステップに、カウンタの値ＣＮをゼロに設定するステップを設けたものである。即ち、ＣＰＵ１１は、図１６（ａ）に示す判定処理をＳ２４０（図４参照）で開始すると、カウンタの値ＣＮをゼロクリアした後（Ｓ９００）、Ｓ９１０に以降し、その後、Ｓ９１０〜Ｓ９５０の処理を、Ｓ４１０〜Ｓ４５０の処理（図７参照）と同様に実行する。そして、Ｓ９５０での処理を終えると、当該判定処理を終了する。
【０１２４】
一方、ＣＰＵ１１は、インターバルタイマ２３から周期的に出力される周期割込要求が割込コントローラ１７を介して入力される度、図１６（ｂ）に示す周期割込例外処理を実行する。
【０１２５】
この周期割込例外処理を開始すると、ＣＰＵ１１は、カウンタ値ＣＮが、予め設定された閾値以下であるか否かを判断し（Ｓ１０１０）、閾値以下であると判断すると（Ｓ１０１０でＹｅｓ）、カウンタ値ＣＮを１加算した値に更新した後（Ｓ１０２０）、当該周期割込例外処理を終了する。
【０１２６】
一方、カウンタ値ＣＮが閾値を超えていると判断すると（Ｓ１０１０でＮｏ）、ＣＰＵ１１は、カウンタ値ＣＮをゼロに設定すると共に（Ｓ１０３０）、フラグＦＡをオフ値に設定する（Ｓ１０４０）。また、判定処理が異常である（判定処理の実行抜けが生じている）と判定し（Ｓ１０５０）、その判定結果（判定処理が異常である旨の情報）を出力する（Ｓ１０６０）。その後、当該周期割込例外処理を終了する。
【０１２７】
即ち、本実施例では、判定処理が実行された時点からの経過時間をカウンタにより計測し、当該経過時間が閾値を超えると、判定処理が実行されていないとして、判定処理が異常であると判定し、その判定結果を、ログファイルや外部装置等に出力する。このようにして、判定処理の実行抜けを検知する。
【０１２８】
従って、本実施例によれば、第三実施例と同様に、第１関数〜第Ｎ関数が正常に実行されても、正常に実行されなくても、判定処理の実行抜けを検知でき、より適切な検査を実現することができる。即ち、判定処理の異常に気づかず、設計者等が、検査対象プログラムが正常であると錯誤してしまうのを防止することができる。
【０１２９】
尚、Ｓ１０１０での判断に用いる閾値は、周期処理の実行周期よりも若干長い程度の時間間隔に設定することができる。このようにすれば、判定処理の実行抜けが生じたときに、迅速に、判定処理の実行抜けを、周期割込例外処理にて検知することができる。
【０１３０】
また、請求項４記載の計時手段は、本実施例において、周期割込要求が入力される度にＣＰＵ１１が実行するカウンタＣＮのカウントアップ動作（Ｓ１０２０）にて実現され、判定手段は、ＣＰＵ１１が実行する図１６（ａ）に示す判定処理にて実現され、判定異常検知手段は、ＣＰＵ１１が実行する図１６（ｂ）に示す周期割込例外処理のＳ１０５０の処理にて実現されている。
【実施例５】
【０１３１】
続いて、第五実施例を、図１７〜図１９を用いて説明する。但し、以下に説明する第五実施例は、第一実施例のマイコン１０のフラッシュメモリ１３に、図５に示すブレーク割込例外処理に代えて、図１７に示すブレーク割込例外処理をＣＰＵ１１に実行させるためのプログラムを搭載し、図７に示す判定処理に代えて、図１８に示す判定処理をＣＰＵ１１に実行させるためのプログラムを搭載し、新たに、図１９（ａ）に示す周期判定処理をＣＰＵ１１に実行させるためのプログラムを、フラッシュメモリ１３に搭載した程度のものである。従って、以下では、第五実施例の説明として、第一実施例と異なるマイコン１０の構成についての説明を選択的にし、その他の説明を省略する。
【０１３２】
図１７は、本実施例においてＣＰＵ１１が実行するブレーク割込例外処理を表すフローチャートである。ＣＰＵ１１は、ブレーク割込要求が割込コントローラ１７を介してユーザブレークコントローラ１８から入力される度、図１７に示すブレーク割込例外処理を開始し、まず、Ｓ１１００にて、フラグとして使用するパラメータＦＸ（以下、単に「フラグＦＸ」と表現する。）を、オン値（値「１」）に設定する（Ｓ１１００）。その後、ポインタ変数ｉを、１加算した値に更新し（Ｓ１１１０）、その後、Ｓ３２０〜Ｓ３５０（図５参照）の処理と同様にして、Ｓ１１２０〜Ｓ１１５０の処理を実行する。そして、Ｓ１１５０での処理を終えると、当該ブレーク割込例外処理を終了する。
【０１３３】
このようにして、本実施例のブレーク割込例外処理では、判定処理の異常を検知するためのフラグＦＸをオンに設定する。そして、このフラグＦＸを、判定処理でオフ値に設定する。
【０１３４】
図１８は、本実施例においてＣＰＵ１１が実行する判定処理を表すフローチャートである。Ｓ２４０で判定処理を開始すると、ＣＰＵ１１は、Ｓ４１０〜Ｓ４５０（図７参照）の処理と同様にして、Ｓ１２１０〜Ｓ１２５０の処理を実行する。そして、Ｓ１２５０での処理を終えると、Ｓ１２６０に移行し、上述のフラグＦＸをオフ値に設定する。その後、当該判定処理を終了する。
【０１３５】
そして、本実施例では、このフラグＦＸの値に基づき、判定処理の実行抜けを、周期判定処理にて検知する。図１９（ａ）は、ＣＰＵ１１が実行する周期判定処理を表すフローチャートである。但し、本実施例においては、リアルタイムＯＳがマイコン１０に搭載され、タスクに設定されたプライオリティ（実行優先度）に従って、タスクスケジューリングが行われるように、マイコン１０が構成されており、周期判定処理を実現するタスクのプライオリティが、周期処理を実現するタスクよりも低く設定されているものとする。
【０１３６】
即ち、本実施例では、周期処理の非実行期間中において、ＣＰＵ１１により周期判定処理が繰返し実行されるように、システムが設計されているものとする。尚、図１９（ｂ）は、周期処理の実行タイミングと周期判定処理の実行タイミングとの対応関係を表すタイムチャートである。
【０１３７】
このように構成されたシステムにおいて、周期判定処理を開始すると、ＣＰＵ１１は、まず、フラグＦＸがオフ値に設定されているか否かを判断し（Ｓ１３１０）、フラグＦＸがオフ値に設定されていると判断すると（Ｓ１３１０でＹｅｓ）、判定処理が正常であるとして、Ｓ１３２０〜Ｓ１３６０の処理を実行することなく、当該周期判定処理を終了する。
【０１３８】
一方、フラグＦＸがオン値に設定されていると判断すると（Ｓ１３１０でＮｏ）、ＣＰＵ１１は、判定処理が異常であると判定して（Ｓ１３２０）、その判定結果（判定処理が異常である旨の情報）をログファイルや外部装置に出力する（Ｓ１３３０）。
【０１３９】
同時に、ポインタ変数ｉを値０に初期化すると共に（Ｓ１３４０）、アドレス設定テーブルの第０番地に設定されたアドレス（第１関数のアドレス）を、ブレークアドレスレジスタ１８ａに設定し（Ｓ１３５０）、更に、フラグＦＡをオフ値に設定する（Ｓ１３６０）。その後、当該周期判定処理を終了する。
【０１４０】
以上、第五実施例について説明したが、判定処理の実行抜けについては、本実施例の手法によっても検知できることができ、この実施例によれば、判定処理の異常に気づかず、設計者等が、検査対象プログラムが正常であると錯誤してしまうのを防止することができる。
【０１４１】
尚、請求項７，８記載のブレーク割込例外処理手段は、本実施例のＣＰＵ１１が実行するブレーク割込例外処理（図１７参照）にて実現され、判定手段は、ＣＰＵ１１が実行する図１８に示す判定処理にて実現され、判定異常検知手段は、ＣＰＵ１１が実行する図１９に示す周期判定処理にて実現されている。
【実施例６】
【０１４２】
続いて、第六実施例について、図２０〜図２２を用いて説明する。但し、第六実施例は、第一実施例のマイコン１０のフラッシュメモリ１３に、図２に示すアドレス設定テーブルに代えて、図１０上段に示すアドレス設定テーブルを搭載し、図５に示すブレーク割込例外処理に代えて、図２０（ａ）に示すブレーク割込例外処理をＣＰＵ１１に実行させるためのプログラムを搭載し、図７に示す判定処理に代えて、図２０（ｂ）に示す判定処理をＣＰＵ１１に実行させるためのプログラムを搭載し、新たに、図２１に示すオーバーフロー割込例外処理を、ＣＰＵ１１に実行させるためのプログラムを、フラッシュメモリ１３に搭載した程度のものである。従って、以下では、第六実施例の説明として、第一実施例と異なるマイコン１０の構成についての説明を選択的にし、その他の説明を省略する。
【０１４３】
図２０（ａ）は、本実施例において、ユーザブレークコントローラ１８から割込コントローラ１７を通じてブレーク割込要求が入力される度、ＣＰＵ１１が実行するブレーク割込例外処理を表すフローチャートである。
【０１４４】
ＣＰＵ１１は、ブレーク割込例外処理を開始すると、まず、タイマ２１を停止させると共にタイマ２１をリセットする。即ち、タイマ２１を停止させた状態でタイマ２１のタイマ値ＴＭをゼロに設定する（Ｓ１４００）。尚、本実施例のマイコン１０には、タイマ２１の他に、アウトプットコンペア２５が設けられており、タイマ値ＴＭが閾値（以下、第六実施例での「閾値」とはコンペア用レジスタ２５ａに設定された値とする。）を超えると、コンペア制御部２５ｂが、オーバーフロー割込要求を、割込コントローラ１７を通じてＣＰＵ１１に入力する。
【０１４５】
Ｓ１４００で、タイマ２１をリセットすると、ＣＰＵ１１は、ポインタ変数ｉを１加算した値に更新した後（Ｓ１４１０）、アドレス設定テーブルの第ｉ番地に設定された値Ｔ［ｉ］を読出し、値Ｔ［ｉ］がＥＯＴであるか否かを判断する（Ｓ１４２０）。
【０１４６】
そして、値Ｔ［ｉ］がＥＯＴではないと判断すると（Ｓ１４２０でＮｏ）、Ｓ１４５０に移行して、アドレス設定テーブルの第ｉ番地に設定された値Ｔ［ｉ］を、ブレークアドレスレジスタ１８ａに設定する。その後、タイマ２１をスタートさせ（Ｓ１４６０）、当該スタート時点からの経過時間を、タイマ値ＴＭとして、タイマ２１に計測させる。この後、当該ブレーク割込例外処理を終了する。
【０１４７】
一方、値Ｔ［ｉ］がＥＯＴであると判断すると（Ｓ１４２０でＹｅｓ）、ＣＰＵ１１は、Ｓ１４４０に移行し、ポインタ変数ｉを値０に初期化する。その後、アドレス設定テーブルの第ｉ＝０番地に記述された親関数のアドレス値Ｔ［０］を、ブレークアドレスレジスタ１８ａに設定する（Ｓ１４５０）。この後、タイマ２１をスタートさせて、タイマ値ＴＭのカウントを開始させ（Ｓ１４６０）、当該ブレーク割込例外処理を終了する。
【０１４８】
続いて、ＣＰＵ１１が実行する判定処理について説明する。図２０（ｂ）は、本実施例においてＣＰＵ１１が実行する判定処理を表すフローチャートである。
ＣＰＵ１１は、周期処理のＳ２４０（図１０下段参照）において判定処理を開始すると、まず、タイマ２１を停止させて（Ｓ１５００）。その後、フラグＦＡがオン値に設定されているか否かを判断する（Ｓ１５１０）。そして、フラグＦＡがオフ値に設定されていると判断すると（Ｓ１５１０でＮｏ）、検査対象プログラムに基づく処理の流れが正常であると判定し（Ｓ１５２０）、Ｓ１５４０に移行する。尚、本実施例においては、関数の実行抜けが生じると、後述するオーバーフロー割込処理で、フラグＦＡをオフ値からオン値に切り替えるものとする（図２１参照）。
【０１４９】
一方、フラグＦＡがオン値に設定されていると判断すると（Ｓ１５１０でＹｅｓ）、ＣＰＵ１１は、検査対象プログラムに基づく処理の流れが異常であると判定し（Ｓ１５３１）、フラグＦＡをオフ値に設定する（Ｓ１５３３）。その後、Ｓ１５４０に移行する。
【０１５０】
また、Ｓ１５４０に移行すると、ＣＰＵ１１は、ポインタ変数ｉが値０に設定されているか否かを判断する。そして、ポインタ変数ｉ＝０であると判断すると（Ｓ１５４０でＹｅｓ）、Ｓ１５４３，Ｓ１５４７の処理を実行せずに、Ｓ１５５０に移行する。
【０１５１】
一方、ポインタ変数ｉが値ゼロに設定されていないと判断すると（Ｓ１５４０でＮｏ）、ＣＰＵ１１は、ポインタ変数ｉを値０に初期化して（Ｓ１５４３）、アドレス設定テーブルにおける第０番地に記述された親関数のアドレスＴ［０］を、ブレークアドレスレジスタ１８ａに設定する（Ｓ１５４７）。その後、Ｓ１５５０に移行する。
【０１５２】
また、Ｓ１５５０に移行すると、ＣＰＵ１１は、Ｓ１５２０又はＳ１５３１での判定結果（「処理フロー正常」又は「処理フロー異常」との情報）を出力して（Ｓ１５５０）、当該判定処理を終了する。
【０１５３】
この他、図２１は、オーバーフロー割込要求が入力されるとＣＰＵ１１が実行するオーバーフロー割込例外処理を表すフローチャートである。即ち、図２１に示す処理は、オーバーフロー割込要求に対応する例外処理として、オーバーフロー割込要求が入力される度、ＣＰＵ１１により実行される。
【０１５４】
オーバーフロー割込例外処理を実行すると、ＣＰＵ１１は、まず、タイマ２１を停止させると共に、当該タイマ２１をリセットする（Ｓ１６１０）。
また、この処理を終えると、ポインタ変数ｉの現在値に対応するアドレス設定テーブルの第ｉ番地にアドレスが設定された第ｉ関数が、ＣＰＵ１１により実行されなかったとして、第ｉ関数が異常であると判定し（Ｓ１６２０）、フラグＦＡをオン値に設定する（Ｓ１６２５）。
【０１５５】
また、当該第ｉ関数に対応する代替処理を実行する（Ｓ１６３０）。例えば、第ｉ関数に代わるフェールセーフ処理を、上記代替処理として実行する。その他、第ｉ関数の出力変数に、デフォルト値を設定する処理を、上記代替処理として実行してもよい。尚、本実施例では、予め、各関数に対応した代替処理を定めて、この代替処理をＣＰＵ１１に実行させるための手順を組み込んだプログラムを、オーバーフロー割込例外処理プログラムとしてマイコン１０に登録するものとする。
【０１５６】
そして、Ｓ１６３０での処理を終えると、ＣＰＵ１１は、この異常を表す情報をログファイルに出力する（Ｓ１６４０）。更に、ポインタ変数ｉを、１加算した値に更新し（Ｓ１６５０）、タイマ２１をスタートさせる（Ｓ１６６０）。その後、当該オーバーフロー割込例外処理を終了する。
【０１５７】
但し、ｉ＝０であるときには、Ｓ１６２０にて、判定処理の実行抜けが生じたと判定し、Ｓ１６３０にて、判定処理に代替する処理を実行すると共に、Ｓ１６５０の処理については、スキップし、ｉ＝０の状態で、タイマ２１をスタートさせるものとする（Ｓ１６６０）。また、この状態で再度、オーバーフロー割込要求が発生した場合には、周期処理に異常が発生したとして、この周期処理に対応するフェールセーフ処理を実行すればよい。
【０１５８】
また、本実施例においては、タイマ２１に対し上記閾値として、実行順が次の関数が開始されるまでの時間よりも若干長い程度の時間を設定し、アドレス設定テーブルにおいて、タイマ２１をスタートする原因となった関数の次に実行順が設定された関数が開始される予定の時刻以降であって、その関数の実行が終了するまでの期間に、当該関数の実行抜けに起因したオーバーフロー割込要求がアウトプットコンペア２５のコンペア制御部２５ｂから出力されるようにする。
【０１５９】
具体的には、関数毎に閾値を定めておき、ブレーク割込例外処理にて、タイマ２１を停止させると共に、当該タイマ２１をリセットする際に、ポインタ変数ｉに対応した閾値をコンペア用レジスタ２５ａに設定するように、ブレーク割込例外処理を設計すればよい。
【０１６０】
例えば、第１関数の実行抜けの発生時には、第１関数の代替処理を実行できるように、周期処理の実行時に行うブレーク割込例外処理では、この時点から第１関数が実行されるまでの時間長さより若干長い程度の時間を、閾値として設定すればよい。この他、実行順が最後尾の第Ｎ関数の実行時に行うブレーク割込例外処理では、この時点から判定処理が実行されるまでの時間長さより若干長い程度の時間を、閾値として設定して、判定処理の実行抜け発生時には、次の周期処理が実行されるまでの期間に、オーバーフロー割込要求が発生するようにすればよい。
【０１６１】
このように構成された本実施例のマイコン１０によれば、周期処理において、どの関数の実行抜けが生じたか否かを検知することができると共に、その関数が実行されるべき時間帯に、代替処理を実行することができる。
【０１６２】
図２２は、タイマ値ＴＭの変化と、オーバーフロー割込要求の出力態様とを表した、本実施例のマイコン１０の動作態様を表すタイムチャートである。図２２に示すように第２関数の実行抜けが生じた場合には、その第２関数を実行すべき時間帯にオーバーフロー割込要求が発生して代替処理が実行される。従って、本実施例によれば、信頼性の高い製品を開発することができる。
【０１６３】
例えば、本実施例の構成を、マイコン１０にて車両制御を行う車両制御装置に導入すれば、車両制御に必要な処理（関数）が何らかの原因で実行されないときに、代わりにフェールセーフ処理等の代替処理を実行することができるので、当該エラーによって、車両制御が不安定になるのを抑えることができ、信頼性の高い車両制御装置を、提供することができる。
【図面の簡単な説明】
【０１６６】
【図１】マイコン１０の構成を表すブロック図である。
【図２】アドレス設定テーブルの構成を表す説明図である。
【図３】ＣＰＵ１１が実行するイニシャル処理を表すフローチャートである。
【図４】ＣＰＵ１１が実行する周期処理を表すフローチャートである。
【図５】ＣＰＵ１１が実行するブレーク割込例外処理を表すフローチャートである。
【図６】マイコン１０の動作態様を表すタイムチャートである。
【図７】ＣＰＵ１１が実行する判定処理を表すフローチャートである。
【図８】第二実施例のブレーク割込例外処理を表すフローチャートである。
【図９】判定処理の実行抜け発生時におけるフラグＦＡの変化を表すタイムチャートである。
【図１０】第三実施例のアドレス設定テーブルの構成を表す説明図である。
【図１１】第三実施例のブレーク割込例外処理を表すフローチャートである。
【図１２】第三実施例におけるマイコン１０の動作態様を表すタイムチャートである。
【図１３】第三実施例の判定処理を表すフローチャートである。
【図１４】第三実施例においてＣＰＵ１１が実行する周期割込例外処理を表すフローチャートである。
【図１５】判定処理の実行抜け発生時のマイコン１０の動作態様を表すタイムチャートである。
【図１６】第四実施例の判定処理を表すフローチャート（ａ）及び周期割込例外処理を表すフローチャート（ｂ）である。
【図１７】第五実施例のブレーク割込例外処理を表すフローチャートである。
【図１８】第五実施例の判定処理を表すフローチャートである。
【図１９】第五実施例においてＣＰＵ１１が実行する周期判定処理に関する説明図である。
【図２０】第六実施例のブレーク割込例外処理を表すフローチャート（ａ）及び判定処理を表すフローチャート（ｂ）である。
【図２１】第六実施例においてＣＰＵ１１が実行するオーバーフロー割込例外処理を表すフローチャートである。
【図２２】第六実施例におけるマイコン１０の動作態様を表すタイムチャートである。
【図２３】従来の検査方法に関する説明図である。
【符号の説明】
【０１６７】
１０…マイコン、１１…ＣＰＵ、１３…フラッシュメモリ、１５…ＲＡＭ、１７…割込コントローラ、１８…ユーザブレークコントローラ、１８ａ…ブレークアドレスレジスタ、１８ｂ…ブレーク条件比較部、１９…インタフェース、２１…タイマ、２３…インターバルタイマ、２５…アウトプットコンペア、２５ａ…コンペア用レジスタ、２５ｂ…コンペア制御部
【図１】
0004661854.tif 000002
【図２】
0004661854.tif 000003
【図３】
0004661854.tif 000004
【図４】
0004661854.tif 000005
【図５】
0004661854.tif 000006
【図６】
0004661854.tif 000007
【図７】
0004661854.tif 000008
【図８】
0004661854.tif 000009
【図９】
0004661854.tif 000010
【図１０】
0004661854.tif 000011
【図１１】
0004661854.tif 000012
【図１２】
0004661854.tif 000013
【図１３】
0004661854.tif 000014
【図１４】
0004661854.tif 000015
【図１５】
0004661854.tif 000016
【図１６】
0004661854.tif 000017
【図１７】
0004661854.tif 000018
【図１８】
0004661854.tif 000019
【図１９】
0004661854.tif 000020
【図２０】
0004661854.tif 000021
【図２１】
0004661854.tif 000022
【図２２】
0004661854.tif 000023
【図２３】
0004661854.tif 000024