JP2014059846A - プログラム異常検出装置、そのプログラム - Google Patents

Abstract

【課題】複数の定周期タスクから構成されるソフトウェアであっても異常（無限ループ等を含む）を検出できる。
【解決手段】ソフトウェアを構成する各タスク・プログラム４１全てにリフレッシュ処理部４２を設けて、そのタスク実行の際にリフレッシュ処理（リフレッシュ記録テーブル３１における自己の情報を更新する処理）も実行させる。監視条件設定テーブル２１には、各タスク・プログラム４１に対応してそのタスクが実行するリフレッシュ処理に関する時間的な条件が設定・登録される。この時間的な条件は、監視タイムアウト時間、及び、リフレッシュ禁止期間である。監視部２３は、定期的に、リフレッシュ記録テーブル３１を参照してタスク毎に上記時間的な条件を満たしているか否かを判定し、条件を満たしていない場合にはそのタスクに異常発生と見做す。
【選択図】図２

Description

本発明は、プログラムの異常を検出する装置等に関する。

プログラムの異常を検出する方法として、ＷＤＴ（ウォッチドッグタイマ）を使用して異常検出をする方法が一般的に知られている。これは、ＷＤＴに対して一定時間内にプログラムからのタイマリセット（クリア）がなされないとプログラムに異常発生したと見做して、ＣＰＵリセットまたは停止状態にするものである。

この様なプログラムの異常検出方法として、例えば特許文献１，２に記載の従来技術が知られている。
特許文献１には、プログラム処理実行される中央処理装置から送出される監視タイマリセット信号を入力して、この信号に基づいてプログラム異常を検出するプログラム異常検出回路が開示されている。プログラム異常検出回路は、監視タイマやＯＲ回路やフリップフロップ等を有しており、上記監視タイマリセット信号を、監視タイマのカウント時間T1(T1≠0)までに受信した場合、またはカウント時間T1からT2(T1<T2)までの間に受信しなかった場合に、プログラム異常として検出する。

また、特許文献２には、ＷＤＴの機能をソフトウェアで拡張して、プログラム異常の検出精度を上げる方式が提案されている。これは、アプリケーションプログラム（ＡＰ）がＷＤＴに設定時間を通知し、ＷＤＴが通知された設定時間をタイマに設定してリスタートさせるが、上記ＡＰから通知される設定時間が毎回異なるようにすることで、プログラムの異常を検出する方法である。この方法によれば、プログラムが暴走して繰り返し実行する部分にタイマリセットのルーチンが含まれている場合でも、当該プログラム暴走を検出できる。

特開昭５９−８３４３８号公報 特開２００７−２８７０９６号公報

しかしながら、前述した従来の方法では以下のような問題が生じる。
すなわち、特許文献１に関しては、下記の問題がある。
・プログラム異常検出回路はハードウェアで実現しており、ソフトウェアが複数の定周期処理（定周期タスク）から構成されている場合には対応困難である。

例えば、ＷＤＴリセット処理を行わないプログラム(定周期タスク)が存在した場合、この定周期タスクに異常が生じても検出できない可能性がある。これに対して、全ての定周期タスクにそれぞれＷＤＴリセット処理を行わせる場合、例えば上記監視タイマリセット信号が各定周期タスク実行に伴って出力されることになるが、プログラム異常検出回路ではどの定周期タスクによるリセット信号であるのか区別することはできないし、当然、定周期タスク毎の正常／異常を判別することはできない。あるいは、ＷＤＴリセット処理を行う定周期タスクが暴走して当該リセット処理を含む無限ループになった場合、異常を検出できない可能性がある。

また、特許文献２に関しても、下記の問題がある。
・ソフトウェアが複数の定周期処理（定周期タスク）から構成されている場合の異常検出は、考慮されていない。従って、複数の定周期タスクから構成されるソフトウェアの異常検出に関しても、何等想到されていない。更に、ＷＤＴのリセット処理を有するプログラム（定周期タスク）が暴走して、リセット処理を含む無限ループになった場合、異常検出はできない可能性がある。

上述したように、従来では、ソフトウェアが複数の定周期処理（定周期タスク）から構成されている場合において、プログラム異常検出することは、何等想到されていないし実現できないものである。

ここで、上記複数の定周期タスクとは、例えばリアルタイムＯＳ上のタスクである。よく知られているように、リアルタイムＯＳは各処理（タスク）のスケジューリング機能、各タスクを一定周期毎に呼び出して実行したりタスク処理を一定時間止めておくなど時間に関係した動作を行うための時間管理機能を備えている。また、割込み管理機能等も備えている。あるいは、制御分野におけるプログラマブルコントローラ（ＰＬＣ）では、複数の定周期タスクが順次実行されて何らかの制御対象機器が制御される場合が少なくない。

本発明の課題は、複数の定周期タスクから構成されるソフトウェアであっても異常検出でき、更に、任意のタスクのプログラムが暴走してリフレッシュ処理を含む無限ループになるような場合でも異常検出できるプログラム異常検出装置等を提供することである。

本発明のプログラム異常検出装置は、複数の定周期タスクから構成されるプログラムの異常を検出するプログラム異常検出装置であって、前記定周期タスク毎に対応して所定のリフレッシュ情報が記憶されるリフレッシュ情報記憶手段と、前記定周期タスク毎に対応してその定周期タスクが実行するリフレッシュ処理に関する時間的な条件が登録される条件登録手段とを有し、前記各定周期タスクは、それぞれ、前記リフレッシュ処理としてその定周期タスクに対応する前記リフレッシュ情報の更新を行うリフレッシュ手段を有し、定期的に、前記定周期タスク毎に、対応する前記リフレッシュ情報を参照して前記時間的な条件を満たしているか否かを判定し、該時間的な条件を満たしていない場合、あるいは複数回連続して該時間的な条件を満たしていない場合には、その定周期タスクの異常と判定する監視手段とを有する。

前記時間的な条件は、例えば、監視タイムアウト時間、及び、リフレッシュ禁止期間である。そして、例えば、前記監視手段は、前記定周期タスク毎に、任意の前記リフレッシュ処理実行時から前記監視タイムアウト時間経過するまでに次の前記リフレッシュ処理が実行されなかった場合、あるいは、前記リフレッシュ禁止期間内に前記リフレッシュ処理が実行された場合には、前記時間的な条件を満たしていないと判定する。

本発明のプログラム異常検出装置等によれば、複数の定周期タスクから構成されるソフトウェアであっても異常検出でき、更に、リフレッシュ処理を含む任意のタスクのプログラムが暴走して無限ループになるような場合でも異常検出できる。

本例のプログラム異常検出装置のハードウェア構成例である。 プログラム異常検出機能に係わる構成図である。 （ａ）、（ｂ）は、監視条件設定テーブルの具体例を示す図である。 （ａ）、（ｂ）は、リフレッシュ順序設定テーブルの具体例を示す図である。 （ａ）、（ｂ）は、リフレッシュ記録テーブルの具体例を示す図である。 （ａ）、（ｂ）は、リフレッシュ順序記録テーブルの具体例を示す図である。 リフレッシュ処理部の処理フローチャート図である。 監視部の処理フローチャート図である。 監視タイムアウト、禁止期間について説明する為の図である。 監視部の処理フローチャート図（順序チェック）である。

以下、図面を参照して、本発明の実施の形態について説明する。
図１は、本例のプログラム異常検出装置のハードウェア構成例である。
これは、本例のプログラム異常検出装置の機能を有する何らかのコンピュータ／情報処理装置（パソコン、組み込み機器、プログラマブルコントローラ等）のハードウェア構成例と見做してもよい。

本例のプログラム異常検出装置１０は、ＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、外部Ｉ／Ｆ（インタフェース）１４などから構成され、それぞれバス接続されている。
ＲＯＭ１３は、ＣＰＵ１１が実行するプログラムコード等（後述するアプリケーションプログラム群４０等）が格納されているメモリである。更に、ＲＯＭ１３には、後述するプログラム異常検出機能部２０の各種処理機能を実現させる為の他のアプリケーションプログラム（不図示）も、予め記憶されている。ＣＰＵ１１が、このアプリケーションプログラムを読出し実行することにより、例えば後述する各種フローチャート図（図７、図８、図１０）の処理が実現される。

ＲＡＭ１２は、書き換え可能なメモリであり、例えば後述するリフレッシュ処理情報の記憶領域３０を割り当てる。後述する各設定テーブル２１，２２等は、ＲＡＭ１２、ＲＯＭ１３のどちらに記憶させてもよい。

外部Ｉ／Ｆ１４は、不図示の何らかの外部機器と接続するためのインタフェースであり、シリアルコントローラやＬＡＮコントローラ等の通信デバイスが接続される。また、外部Ｉ／Ｆ１４は、ＣＦカードやＵＳＢメモリといったストレージデバイスが接続されても良い。このインタフェース経由で例えば、各設定テーブル２１，２２等の変更を可能としても良い。

図２は、図１の情報処理装置内のプログラム異常検出機能に係わる構成図である。
まず、上記ＲＯＭ１３には、予め、上述した複数の定周期処理（定周期タスク；以下、省略して単にタスクと記す場合もある）から構成されるソフトウェアであるアプリケーションプログラム群４０が記憶されている。

アプリケーションプログラム群４０は、タスク毎に分割された複数のプログラム（タスクＡプログラム〜タスクＸプログラム）４１から構成される。これら各タスク・プログラム４１（タスク）は、それぞれ、予め決められた定周期で周期的な動作を行う。各タスク・プログラム４１は、例えばリアルタイムＯＳ上のタスク等であるが、この例に限らない。

各タスク・プログラム４１は、それぞれ何らかの所定の処理を定周期で実行するが、それ以外に、上述した従来のＷＤＴに対する一定時間毎のタイマリセット処理に相当するリフレッシュ処理を実行する、リフレッシュ処理部４２が組み込まれている。尚、本手法では、タイマは使用しないで、ソフトウェア処理によって“従来のＷＤＴを用いた異常検出”に相当する機能を実現する。

また、上記記憶領域３０には、上記リフレッシュ処理情報の一例であるリフレッシュ記録テーブル３１、リフレッシュ順序記録テーブル３２等が格納されている。基本的には、各リフレッシュ処理部４２によってリフレッシュ処理が行われる毎に少なくともリフレッシュ記録テーブル３１の内容が更新される。本例では、更に、リフレッシュ順序記録テーブル３２も用いるが、これは必ずしも用いる必要はない（よって後述する図１０において、リフレッシュ順序記録テーブル３２を用いる処理やこれに関連する処理等も、必須のものではない）。但し、これらを実行することで、後述する効果が更に得られることになる。

そして、プログラム異常検出機能部２０は、監視条件設定テーブル２１、リフレッシュ順序設定テーブル２２、設定部２３、監視部２４等から構成される。
設定部２３によって、上記監視条件設定テーブル２１、リフレッシュ順序設定テーブル２２に対する設定が行われる。設定部２３は、例えば不図示の設定画面を不図示のディスプレイ等に表示して、ユーザに任意の情報を設定させて当該設定情報を設定テーブル２１，２２に格納するものであるが（ユーザは不図示のキーボード、マウス等を操作して設定する）、この例に限らない。例えば、設定部２３は、外部でユーザ等によって任意に作成された上記設定テーブル２１，２２等を何らかの形で取り込んで（ネットワーク経由や可搬記憶媒体経由など）ＲＡＭ１２／ＲＯＭ１３に記憶する処理を行うものであってもよい。何れにしても、これら各設定テーブル２１，２２の内容は、ユーザ等が任意に設定するものであってよい。

上記監視条件設定テーブル２１には、例えば、各定周期タスク（各タスク・プログラム４１）に対応してその定周期タスクが実行するリフレッシュ処理に関する時間的な条件が設定・登録される。この時間的な条件は、監視タイムアウト時間、及び、リフレッシュ禁止期間であり、監視部２４は、例えば、タスク・プログラム４１毎に、任意のリフレッシュ処理実行時から監視タイムアウト時間経過するまでに次のリフレッシュ処理が実行されなかった場合、あるいは、リフレッシュ禁止期間内にリフレッシュ処理が実行された場合には、上記時間的な条件を満たしていないと判定する。詳しくは後述する。

リフレッシュ記録テーブル３１には、例えば、タスク・プログラム４１毎に対応して所定のリフレッシュ情報が記憶される。
上記各タスク・プログラム４１のリフレッシュ処理部４２は、上記定期的なリフレッシュ処理として、上記監視条件設定テーブル２１や、リフレッシュ順序設定テーブル２２の設定内容を参照しつつ、上記リフレッシュ記録テーブル３１や、リフレッシュ順序記録テーブル３２の後述する各種格納内容（リフレッシュ情報と呼ぶものとする）を更新する。詳しくは後に図７を参照して説明する。

監視部２４は、定期的に、リフレッシュ記録テーブル３１、リフレッシュ順序記録テーブル３２に記録されているデータを読み出し、監視条件設定テーブル２１、リフレッシュ順序設定テーブル２２の設定内容を参照して、上記定周期タスク（タスク・プログラム４１）毎の異常の有無の判定を行う。

以下、上記各種テーブルについて、具体例を示して説明する。
図３（ａ）、（ｂ）には、監視条件設定テーブル２１の具体例を示す。
図４（ａ）、（ｂ）には、リフレッシュ順序設定テーブル２２の具体例を示す。

図５（ａ）、（ｂ）には、リフレッシュ記録テーブル３１の具体例を示す。
図６（ａ）、（ｂ）には、リフレッシュ順序記録テーブル３２の具体例を示す。
以下、まず、図３を参照して監視条件設定テーブル２１の具体例について説明する。

図３（ａ）に示すように、監視条件設定テーブル２１は、概略的には、監視条件設定データ数２１１、各監視条件設定データ（（１）〜（ｎ））２１２から構成される。
監視条件設定データ数２１１には、監視条件設定データ２１２の数（レコード数）が格納され、図示の例ではｎ個が格納される。

図３（ｂ）には、監視条件設定データ２１２（レコード）のデータ項目例を示す。
監視条件設定データ２１２は、リフレッシュ監視時間２１２ａ、リフレッシュ遅延最小時間２１２ｂ、リフレッシュ遅延最大時間２１２ｃ、監視時間タイムアップ連続発生許容回数２１２ｄ、監視時間タイムアップ時動作２１２ｅ、監視時間タイムアップ時呼出関数２１２ｆ、禁止期間リフレッシュ連続発生許容回数２１２ｇ、禁止期間リフレッシュ時動作２１２ｈ、禁止期間リフレッシュ時呼出関数２１２ｉから構成される。

尚、これら各データ項目の内容は、例えば上記設定部２３を介して、開発者等が任意に設定できる。すなわち、特に図示しないが、上記設定部２３は、例えば上記各データ項目２１２ａ〜２１２ｉの内容をユーザが任意に設定・入力できるようにする画面を表示する。そして、任意の定周期タスク（タスク・プログラム４１）に関して設定・入力されたデータを、上記監視条件設定テーブル２１の監視条件設定データ２１２として格納する。その際、当該格納する監視条件設定データ２１２に、対応するタスク・プログラム４１の識別子等を付与するようにしてもよい。そして、監視条件設定データ数２１１を更新（＋１インクリメント等）する。

“リフレッシュ監視時間”２１２ａは、任意のリフレッシュ実行時から次にリフレッシュが行われるまでの許容待ち時間である。換言すれば、上記従来のＷＤＴに対する一定時間に相当する時間である。任意のタスク・プログラム４１に関して、任意のリフレッシュ実行時から次にリフレッシュが行われるまでの時間（リフレッシュ間隔）が、“リフレッシュ監視時間”２１２ａを超えると、そのタスク・プログラム４１に異常発生が疑われる。

但し、本例では、１回だけで異常と判定するものではなく、リフレッシュ間隔が“リフレッシュ監視時間”２１２ａを越える事態が複数回連続した場合に（後述する“監視時間タイムアップ連続発生回数”３１２ｅが、閾値（“監視時間タイムアップ連続発生許容回数”２１２ｄ）を越えた場合に）、異常と判定する。但し、この例に限らず、１回だけで異常と判定するようにしてもよい。

“リフレッシュ遅延最小時間”２１２ｂと“リフレッシュ遅延最大時間”２１２ｃは、リフレッシュ禁止期間を設定するものである。これは、上述した“プログラムが暴走してＷＤＴリセット処理を含む無限ループとなる”異常（簡略化して、無限ループと呼ぶものとする）に相当する異常を検出するためのものである。上記のように、この様な無限ループが発生した場合は、頻繁にリフレッシュ処理が行われる場合がある。これより、例えば、任意のリフレッシュ処理実行時から次のリフレッシュ処理が実行されるまでの時間が、短すぎる場合には（“リフレッシュ遅延最小時間”２１２ｂ未満の場合）、異常と判定する。

従来でも、複数の定周期タスクから構成されるソフトウェアではない場合には、この様な無限ループを検出することができたが、複数の定周期タスクから構成されるソフトウェアの場合には従来では実現できなかった。

これに対して、本手法では、例えば、少なくとも、監視条件設定テーブル２１、リフレッシュ記録テーブル３１を用いて、図７、図８の処理（但し、リフレッシュ順序に係わる処理は必須ではない）を行うことで、複数の定周期タスクから構成されるソフトウェアであっても、各タスクそれぞれについて、監視タイムアウト（ＷＤＴタイムアウトに相当）に係わる異常だけでなく、上記無限ループも検出することができる。

上記無限ループの検出に関しては、例えば、タスク毎に対応して上記禁止期間を設定することで、あるタスク・プログラム４１に関して禁止期間中にリフレッシュが行われた場合には、そのタスク・プログラム４１の暴走（無限ループ）などの異常発生が疑われるものとした。

“リフレッシュ遅延最小時間”２１２ｂは、任意のリフレッシュ実行時から次にリフレッシュが行われるまでの時間（リフレッシュ間隔）に関する最小時間である。任意のタスク・プログラム４１について“リフレッシュ遅延最小時間”２１２ｂより短い時間間隔でリフレッシュが行われると、そのタスク・プログラム４１の暴走（無限ループ）などの異常発生が疑われる。

但し、本例では、１回だけで異常と判定するものではなく、リフレッシュ間隔が“リフレッシュ遅延最小時間”２１２ｂより短い場合には、後述する“禁止期間リフレッシュ連続発生回数”３１２ｆとしてカウントされる。そして、この連続発生回数３１２ｆが所定の閾値（２１２ｇ）を越えた場合に、異常と判定する。但し、この例に限らず、１回だけで異常と判定するようにしてもよい。

一方、“リフレッシュ遅延最大時間”２１２ｃは、任意のリフレッシュ実行時から次にリフレッシュが行われるまでの時間（リフレッシュ間隔）に関する最大時間である。任意のタスク・プログラム４１についてリフレッシュ間隔が“リフレッシュ遅延最大時間”２１２ｃを越える場合には、たとえ“リフレッシュ監視時間”２１２ａを超えなくても、そのタスク・プログラム４１に異常発生が疑われる。

但し、本例では、１回だけで異常と判定するものではなく、リフレッシュ間隔が“リフレッシュ遅延最大時間”２１２ｃより長い場合には、上記“禁止期間リフレッシュ連続発生回数”３１２ｆとしてカウントされる。そして、上記の通り、この連続発生回数３１２ｆが所定の閾値（２１２ｇ）を越えた場合に、異常と判定する。但し、この例に限らず、１回だけで異常と判定するようにしてもよい。

また、上記禁止期間に関しては、“リフレッシュ遅延最大時間”２１２ｃは必ずしも用いなくてもよく、“リフレッシュ遅延最小時間”２１２ｂのみを用いても構わない。
上記のように本例では、任意のタスク・プログラム４１に関して、上記“監視時間タイムアップ連続発生回数”３１２ｅや“禁止期間リフレッシュ連続発生回数”３１２ｆが、所定の閾値を越えた場合に、そのタスク・プログラム４１（タスク）に異常発生と判定する。この閾値が上記監“視時間タイムアップ連続発生許容回数”２１２ｄや“禁止期間リフレッシュ連続発生許容回数”２１２ｇである。

すなわち、“監視時間タイムアップ連続発生許容回数”２１２ｄは、監視時間タイムアップ回数の連続発生を許容する回数であり、任意のタスク・プログラム４１に関して、上記“監視時間タイムアップ連続発生回数”３１２ｅが“監視時間タイムアップ連続発生許容回数”２１２ｄを超えると、そのタスク・プログラム４１の暴走（無限ループ）などの異常発生と判定する。そして、プログラム異常と判定した場合には、例えば“監視時間タイムアップ時動作”２１２ｅに設定されている動作を実行する。“監視時間タイムアップ時動作”２１２ｅに設定されている動作は、例えばＣＰＵリセット、システム停止、タスク停止、タスク再起動、関数呼出等であり、例えば開発者等が設定部２３を介して任意に指定したものである。

尚、“監視時間タイムアップ時呼出関数”２１２ｆは、“監視時間タイムアップ時動作”２１２ｅに“関数呼出”が指定されていた場合に呼び出される関数が設定されるものであり、例えば当該関数の格納アドレスが設定されているが、この例に限らない。

また、上記“禁止期間リフレッシュ連続発生許容回数”２１２ｇは、禁止期間にリフレッシュが行われることが連続発生する際の許容回数であり、任意のタスク・プログラム４１に関して、上記“禁止期間リフレッシュ連続発生回数”３１２ｆが“禁止期間リフレッシュ連続発生許容回数”２１２ｇを超えると、そのタスク・プログラム４１に無限ループの異常発生と判定する。そして、無限ループと判定した場合には、“禁止期間リフレッシュ時動作”２１２ｈに設定されている動作を実行する。“禁止期間リフレッシュ時動作”２１２ｈに設定されている動作は、例えばＣＰＵリセット、システム停止、タスク停止、タスク再起動、関数呼出等であり、例えば開発者等が設定部２３を介して任意に指定したものである。

尚、“禁止期間リフレッシュ時呼出関数”２１２ｉは、“禁止期間リフレッシュ時動作”２１２ｈに“関数呼出”が指定されていた場合に呼び出される関数が設定されるものであり、例えば当該関数の格納アドレスが設定されているが、この例に限らない。

次に、図４を参照してリフレッシュ順序設定テーブル２２の具体例について説明する。
本テーブル２２は、上記複数のタスク・プログラム４１（タスク）のなかに、動作順番が決められている複数のタスク・プログラム４１がある場合に、決められた順番通りに処理（リフレッシュ）が行われているか否かを判定するためのテーブルであり、決められた順番通りにリフレッシュが行われていない場合には、各タスク・プログラム４１個々については上述した異常（無限ループなど）が無くても、プログラム異常と判断する。

例えば、図１に示すタスクＡプログラム、タスクＢプログラム、・・・、タスクＸプログラムのうち（Ａ〜Ｘまであるものとする）、仮に、タスクＢ→タスクＤ→タスクＥ→タスクＢ・・・という順番でタスク実行されるものと決められていた場合、これらタスク実行に伴ってリフレッシュ処理も実行されるので、正常であれば、リフレッシュ処理もこの順番通りに行われるはずである。

リフレッシュ順序設定テーブル２２は、複数のグループ設定を可能とし、グループ毎にそれぞれ、“リフレッシュ順序設定グループデータ”２２２が設定・登録される。リフレッシュ順序設定テーブル２２は、図４（ａ）に示すように概略的には、“リフレッシュ順序設定グループ数”２２１と“リフレッシュ順序設定グループデータ”（（１）〜（ｍ））２２２から構成される。“リフレッシュ順序設定グループ数”２２１には、“リフレッシュ順序設定グループデータ”２２２の数が登録され、図示の例ではｍ個となる。

図４（ｂ）には、“リフレッシュ順序設定グループデータ”２２２のデータ項目例を示す。
“リフレッシュ順序設定グループデータ”２２２は、異常時動作２２２ａ、異常時呼出関数２２２ｂ、順序設定データ数２２２ｃ、監視条件設定データ識別子（（１）〜（ｒ））２２２ｄ等から構成される。

“異常時動作”２２２ａには、設定された順番でリフレッシュが行われなかったことを以ってプログラム異常と判断した場合の動作が指定（設定）される。設定される動作は、例えば、ＣＰＵリセット、システム停止、関数呼出等であるが、これらの例に限らない。

“異常時呼出関数”２２２ｂには、“異常時動作”２２２ａに上記“関数呼出”が指定されていた場合に呼び出される関数が設定され、例えば当該関数の格納アドレスが設定されているものであるが、この例に限らない。

“順序設定データ数”２２２ｃには、“監視条件設定データ識別子”２２２ｄの数が登録され、図示の例ではｒ個が登録される。
“監視条件設定データ識別子”２２２ｄは、そのグループに属するタスク（タスク・プログラム４１）の識別情報（識別子）である。これら各識別子が、任意に決められた実行順序通りに登録されている。つまり、図示の“監視条件設定データ識別子”（１）→“監視条件設定データ識別子”（２）→・・・→“監視条件設定データ識別子”（ｒ）→“監視条件設定データ識別子”（１）→・・・という順番で、各タスクが実行されるはずであり、もしこの順番通りに実行されていないことが検出されると、プログラム異常と判定されることになる。

次に、図５を参照してリフレッシュ記録テーブル３１の具体例について説明する。
図５（ａ）に示すように、リフレッシュ記録テーブル３１は概略的には、リフレッシュ記録データ数３１１、リフレッシュ記録データ（（１）〜（ｎ））３１２から構成される。

“リフレッシュ記録データ数”３１１には、“リフレッシュ記録データ”３１２の数が格納され、図示の例ではｎ個となる。これは、監視条件設定テーブル２１内の“監視条件設定データ”２１２と同一（ｎ個）である。このｎ個は、基本的には、タスク・プログラム４１の数と考えてよい。そして、本例では後述する処理の為に、各“リフレッシュ記録データ”３１２の順番が、上記“監視条件設定データ”２１２の順番と対応関係にあることが望ましい。つまり、例えば先頭レコードである“監視条件設定データ”（１）が図１のタスクＡプログラムに関する設定データであるとするならば、同じく先頭レコードである“リフレッシュ記録データ”（１）がタスクＡプログラムに関する記録データとなるように設定しておくことが望ましい。

尚、これは、上記“監視条件設定データ識別子”２２２ｄとは異なり、実行順番通りにする必要はない。
また、尚、各“リフレッシュ記録データ”３１２や各“監視条件設定データ”２１２には、対応するタスク・プログラム４１の識別子も登録されていることが望ましい。

図５（ｂ）には、リフレッシュ記録データ３１２のデータ項目例を示す。
リフレッシュ記録データ３１２は、リフレッシュカウンタ今回値３１２ａ、タイムスタンプ今回値３１２ｂ、リフレッシュカウンタ前回値３１２ｃ、タイムスタンプ前回値３１２ｄ、監視時間タイムアップ連続発生回数３１２ｅ、禁止期間リフレッシュ連続発生回数３１２ｆから構成される。

各“リフレッシュ記録データ”３１２は、タスク・プログラム４１（特にそのリフレッシュ処理部４２）毎に対応して設けられるものであり、任意のタスク・プログラム４１のリフレッシュ処理部４２は、そのリフレッシュ処理毎に、自己に対応する“リフレッシュ記録データ”３１２の内容を更新する。

すなわち、各リフレッシュ処理部４２は、それぞれ、自己に対応する“リフレッシュ記録データ”３１２の“リフレッシュカウンタ今回値”３１２ａ、“タイムスタンプ今回値”３１２ｂ等のデータを、監視条件設定テーブル２１における自己に対応する“監視条件設定データ”２１２等を参照する等して、更新する。この更新処理は、基本的には例えば、各カウンタ値はそれぞれ＋１インクリメントし、タイムスタンプは、現在日時を新たな今回値とする。

一方、"リフレッシュカウンタ前回値"３１２ｃ、"タイムスタンプ前回値"３１２ｄは、監視部２４が今回値を新たな前回値として更新する。また、“監視時間タイムアップ連続発生回数”３１２ｅと“禁止期間リフレッシュ連続発生回数”３１２ｆについても、監視部２４が更新する。監視部２４は、後述する処理で監視時間タイムアップの発生を検出した場合には“監視時間タイムアップ連続発生回数”３１２ｅを更新（＋１インクリメント）し、禁止期間リフレッシュの発生検出をした場合には禁止期間リフレッシュ連続発生回数”３１２ｆを更新（＋１インクリメント）する。

また、監視部２４は、後述する処理で監視時間タイムアップの発生を検出しなかった場合には“監視時間タイムアップ連続発生回数”３１２ｅを‘０’クリアし、禁止期間リフレッシュの発生を検出しなかった場合には“禁止期間リフレッシュ連続発生回数”３１２ｆを‘０’クリアする。これらは文字通り連続して発生する回数をカウントするものであるので、連続発生が途切れたら‘０’に戻す。

次に、図６を参照してリフレッシュ順序記録テーブル３２の具体例について説明する。
まず、図６（ａ）に示すように、リフレッシュ順序記録テーブル３２は概略的には、リフレッシュ順序記録データ数３２１、リフレッシュ順序記録データ（（１）〜（ｍ））３２２から構成される。

“リフレッシュ順序記録データ数”３２１には、“リフレッシュ順序記録データ”３２２の数が格納され、図示の例ではｍ個が格納される。これは、リフレッシュ順序設定テーブル２２内の“リフレッシュ設定グループ数”２２１と同一（ｍ個）である。このｍ個は、基本的に、グループの数であると考えてよい。グループ分けや各グループ内での実行順序は、例えばプログラマ等が任意に決めて設定してよい。そして、ここでは、各“リフレッシュ順序記録データ”３２２の順番が、上記“リフレッシュ順序設定グループデータ”２２２の順番と対応関係にあることが望ましい。つまり、例えば先頭レコードである“リフレッシュ順序設定グループデータ”（１）が、任意のグループαに関する設定データであったならば、同じく先頭レコードであるリフレッシュ順序記録データ”（１）もグループαに関する記録データとなるように設定しておくことが望ましい。

図６（ｂ）には、リフレッシュ順序記録データ３２２の項目例を示す。
“リフレッシュ順序記録データ”３２２は、“リフレッシュ共通カウンタ”３２２ａ、“カウンタ”（（１）〜（ｒ））３２２ｂから構成される。各“カウンタ”３２２ｂは、それぞれ、そのグループに属するタスク・プログラム４１の何れかに対応するものであり、従って上記“監視条件設定データ識別子”２２２ｄと同じくｒ個となっている。各“カウンタ”３２２ｂの順番は、“監視条件設定データ識別子”２２２ｄの順番と対応関係にあることが望ましい。つまり、例えば、先頭レコードである“カウンタ”（１）は、同じく先頭レコードである“監視条件設定データ識別子”（１）に対応するカウンタである。この“カウンタ”（１）のカウント値は、識別子（１）に対応するタスク・プログラム４１がリフレッシュ処理を実行する毎に更新されるが、更新方法は下記のようにリフレッシュ共通カウンタ３２２ａを用いるものとなる。

“リフレッシュ共通カウンタ”３２２ａは、そのグループ内で共通に使用されるカウンタであり、そのグループに属する何れかのタスク・プログラム４１のリフレッシュ処理部４２がリフレッシュ処理を実行する毎に、当該リフレッシュ処理部４２によって更新（１ずつカウントアップ）される。そして、更新後のカウント値が、当該リフレッシュ処理部４２に対応する“カウンタ”３２２ｂに格納される。

また、監視部２４は後述するように、各“カウンタ”３２２ｂ等に基づいて、設定された順番通りに“カウンタ”３２２ｂが更新されているか否かを判定し、設定された順番通りに“カウンタ”３２２ｂが更新されていなかった場合は、プログラム異常と判断する。

次に、上記各種処理機能部（リフレッシュ処理部４２、監視部２４）の処理について、図７、図８、図１０の各フローチャート図を参照して説明する。これは、具体例として上記図３〜図６に示すデータ構成例を用いて説明する。

図７は、リフレッシュ処理部４２の処理フローチャート図である。
上記アプリケーションプログラム群４０を構成する各タスク・プログラム４１は、自己のリフレッシュ処理部４２を例えば定期的に呼び出す。その際に、パラメータとして自己の識別子を渡す。尚、各タスク・プログラム４１には、予めユニークな識別情報（識別子）が割り当てられている。

呼び出されたリフレッシュ処理部４２は、図７の処理を実行開始すると、まず、上記識別子を取得する（ステップＳ１１）。上記のように、各設定テーブルおよび各記録テーブルの各格納情報は、識別子を用いて管理されており、取得した識別子を用いることで、自己に対応する格納情報（その格納位置等）を判別することができる。

リフレッシュ処理部４２は、次に、現在のタイムスタンプを取得する（ステップＳ１２）。尚、これは単に、装置内の時計機能等から現在時刻を取得するものであってよい。そして、ステップＳ１１で取得した識別子によってリフレッシュ記録テーブル３１内の該当するリフレッシュ記録データ３１２を判別して、例えばそのレコード位置をセットする（処理対象レコードとする）（ステップＳ１３）。尚、図５（ａ）で説明したように、各リフレッシュ記録データ３１２は、例えばそれぞれが任意のタスク・プログラム４１に対応するものであり、その識別子が登録されている。

そして、上記該当するリフレッシュ記録データ３１２（該当レコード）のデータ内容を更新する。すなわち、まず、該当レコードのリフレッシュカウンタ今回値３１２ａを更新すると共に、タイムスタンプ今回値３１２ｂを更新する（ステップＳ１５）。リフレッシュカウンタ今回値３１２ａの更新は、例えば現在の値（＝上記新たな前回値３１２ｃの値）に１加算した値を、新たな今回値として設定する。タイムスタンプ今回値３１２ｂの更新は、上記ステップＳ１２で取得した現在のタイムスタンプを設定する。

以上で該当するリフレッシュ記録データ３１２のデータ内容を更新したら、本例では更にフレッシュ順序記録テーブル３２の更新を行う。尚、フレッシュ順序記録テーブル３２の利用（更新や、参照して異常判定）は、必須ではないが、これを行うことによる効果も得られる。

まず、リフレッシュ順序設定テーブル２２を参照・検索して、ステップＳ１１で取得した識別子の設定の有無を判別する（ステップＳ１６,Ｓ１７）。すなわち、上述したように、リフレッシュ順序設定テーブル２２にはグループ毎にそのグループに属するタスク・プログラム４１の識別子が上記“監視条件設定データ識別子”２２２ｄとして登録されている。これら複数の“監視条件設定データ識別子”２２２ｄのなかに上記ステップＳ１１で取得した識別子と同一の識別子があるか否かを判別するのが、上記ステップＳ１６の処理である。

尚、上述したことから、ステップＳ１１で取得した識別子と同一の識別子がある場合には、該当する“リフレッシュ順序設定グループデータ”２２２や該当する“監視条件設定データ識別子”２２２ｄが分かるだけでなく、該当する“リフレッシュ順序記録データ”３２２や該当する“カウンタ”３２２ｂも判別できる。

これより、該当する識別子の設定がある場合には（ステップＳ１７，ＹＥＳ）、該当する“リフレッシュ順序記録データ”３２２内の“リフレッシュ共通カウンタ”３２２ａを更新すると共に（例えば＋１インクリメントする）（ステップＳ１８）、更に、該当する“カウンタ”３２２ｂに、上記更新後のリフレッシュ共通カウンタ３２２ａの値を設定する（ステップＳ１９）。そして、本処理を終了する。

一方、該当する識別子の設定が無い場合には（ステップＳ１７，ＮＯ）、そのまま本処理を終了する。
図８は、監視部２４の処理フローチャート図である。

尚、監視部２４は、例えば一定周期毎に図８の処理を実行するものであって、各タスク・プログラム４１より高い優先順位で動作し、かつ各タスク・プログラム４１より短い周期間隔で動作するものとする。

監視部２４は、図８の処理を実行開始すると、まず、現在のタイムスタンプを取得し、これを変数‘TIMcur’に代入する（ステップＳ５１）。
次に、監視条件設定テーブル２１の先頭レコードとリフレッシュ記録テーブル３１の先頭レコードを、処理対象レコードとしてセットする（ステップＳ５２，Ｓ５３）。尚、セットするとは、例えばポインタ指定することであり、現在の処理対象レコードを指し示すものである。

また、尚、上記先頭レコードとは、監視条件設定テーブル２１の複数の“監視条件設定データ”２１２のうちの先頭（図３の例では“監視条件設定データ（１）”）、リフレッシュ記録テーブル３１の複数の“リフレッシュ記録データ”３１２のうちの先頭（図５の例では“リフレッシュ記録データ（１）”を、意味する。また、本例では、最初の処理対象レコードを上記先頭レコードとしているが、勿論、この例に限るものではない。

そして、上記処理対象レコードから下記のデータ読出しと変数への代入を行う。また、下記の発生回数の更新／クリア等も、処理対象レコードの該当データ項目に対して行われるものである。

まず、監視条件設定テーブル２１の処理対象レコードの“リフレッシュ監視時間”２１２ａ、“リフレッシュ遅延最小時間”２１２ｂ、“リフレッシュ遅延最大時間”２１２ｃを読出し、それぞれ変数‘Tout’,変数‘Tmin’,変数‘Tmax’に代入する（ステップＳ５４）。また、リフレッシュ記録テーブル３１の処理対象レコードの“リフレッシュカウンタ今回値”３１２ａ、“リフレッシュカウンタ前回値”３１２ｃ、“タイムスタンプ今回値”３１２ｂ、“タイムスタンプ前回値”３１２ｄを読出し、それぞれ変数‘CNTa’,変数‘CNTb’,変数‘TIMa’,変数‘TIMb’に代入する（ステップＳ５５）。

次に、上記リフレッシュカウンタの今回値（CNTa）と前回値（CNTb）との差分（CNTa−CNTb）を計算し、この差分を変数‘CNTdif’に代入する（ステップＳ５６）。また、上記タイムスタンプの今回値(TIMa)と前回値(TIMb)の差分（TIMa−TIMb）を計算し、この差分を変数‘TIMdif’に代入する（ステップＳ５７）。

そして、概略的には、監視タイムアウトであるか否かを判定し、監視タイムアウトではない場合でも更に禁止期間にリフレッシュ処理が実行されたか否かを確認する。基本的には、監視タイムアウトではなく、且つ、禁止期間におけるリフレッシュ実行でも無い場合に、正常と見做すことになる。

すなわち、まず、上記リフレッシュカウンタの差分値（CNTdif）に基づいて、カウンタの更新があるか否か（CNTdif＞０か否か）の判定を行う（ステップＳ５８）。
カウンタの更新が無い場合（CNTdif≦０）（ステップＳ５８，ＮＯ）は、監視タイムアウト判定処理（ステップＳ６３〜Ｓ６８）に移行する。一方、カウンタの更新がある場合（CNTdif＞０）（ステップＳ５８，ＹＥＳ）は、処理対象レコードの"リフレッシュカウンタ前回値"３１２ｃに"リフレッシュカウンタ今回値"３１２ａの値を設定する。更に、処理対象レコードの"タイムスタンプ前回値"３１２ｄに"タイムスタンプ今回値"３１２ｂの値を設定したうえで（ステップＳ７２）、そのままステップＳ５９以降の禁止期間リフレッシュ判定処理へと移行する。

上記監視タイムアップ判定処理では、まず、現在のタイムスタンプ(TIMcur)とタイムスタンプ今回値（TIMa）との差分（TIMcur−TIMa）を計算し、この差分を変数‘TIMdif2’に代入する（ステップＳ６３）。次に、この差分値（TIMdif2）と上記リフレッシュ監視時間（Tout）とを比較し、監視タイムアップ（TIMdif2＞Tout）であるか否かの判定を行う（ステップＳ６４）。

監視タイムアップでない場合（TIMdif2≦Tout）（ステップＳ６４，ＮＯ）は、処理対象レコードの“監視時間タイムアップ連続発生回数”３１２ｅをクリアし（ステップＳ６６）、ステップＳ５９以降の処理に移る。

一方、監視タイムアップの場合（TIMdif2＞Tout）（ステップＳ６４，ＹＥＳ）は、処理対象レコードの“監視時間タイムアップ連続発生回数”３１２ｅを更新する（＋１インクリメント等）（ステップＳ６５）。更に、更新後の“監視時間タイムアップ連続発生回数”３１２ｅを、処理対象レコードの“監視時間タイムアップ連続発生許容回数”２１２ｄと比較して、連続発生回数３１２ｅが許容回数２１２ｄを超えたか否かを判定する（ステップＳ６７）。

連続発生回数３１２ｅが許容回数２１２ｄを越えていれば（ステップＳ６７，ＹＥＳ）、処理対象レコードに対応するタスク・プログラム４１に異常ありと見做し、異常発生時の動作を行う。すなわち、本例では例えば、処理対象レコードの“監視時間タイムアップ時動作”２１２ｅに設定されている動作を行う（ステップＳ６８）。その際、仮に“監視時間タイムアップ時動作”２１２ｅに上記「関数呼出」が設定されている場合は、“監視時間タイムアップ時呼出関数”２１２ｆに登録されている関数を呼出す。

そして、ステップＳ５９以降の処理へと移行する。但し、この場合は、“監視時間タイムアップ時動作”２１２ｅに上記ＣＰＵリセットやシステム停止等が指定されている場合には、これらが実行されるので、ステップＳ５９以降の処理へと移行することなく、初期化処理などが行われることになる。

一方、連続発生回数３１２ｅが許容回数２１２ｄ以下であれば（ステップＳ６７，ＮＯ）、そのままステップＳ５９以降の処理へと移行する。
以下、ステップＳ５９以降の処理について説明する。

まず、ステップＳ５９においては、上記タイムスタンプの差分値（TIMdif）と上記リフレッシュ遅延最小時間（Tmin）およびリフレッシュ遅延最大時間（Tmax）に基づいて、タイムスタンプの差分値（TIMdif）がリフレッシュ遅延範囲内（Tmin≦TIMdif≦Tmax）であるか否かの判定を行う（ステップＳ５９）。換言すれば、リフレッシュ禁止期間内にリフレッシュが行われていないかを判定する。

タイムスタンプの差分値（TIMdif）がリフレッシュ遅延範囲内（Tmin≦TIMdif≦Tmax）である場合には（ステップＳ５９，ＹＥＳ）、処理対象レコードに対応するタスク・プログラム４１の動作は正常と見做してよく、処理対象レコードの“禁止期間リフレッシュ連続発生回数”３１２ｆをクリアする（ステップＳ６０）。そして、ステップＳ６１へ移行する。

一方、タイムスタンプの差分値（TIMdif）がリフレッシュ遅延範囲内ではない場合には（Tmin＞TIMdif もしくは、TIMdif＞Tmax）（ステップＳ５９，ＮＯ）、処理対象レコードに対応するタスク・プログラム４１の動作に異常（暴走）の可能性ありと見做して、処理対象レコードの“禁止期間リフレッシュ連続発生回数”３１２ｆを更新する（＋１インクリメント等）（ステップＳ６９）。更に、更新後の“禁止期間リフレッシュ連続発生回数”３１２ｆを、処理対象レコードの“禁止期間リフレッシュ連続発生許容回数”２１２ｇと比較して、連続発生回数３１２ｆが許容回数２１２ｇを超えるか否かを判定する（ステップＳ７０）。

連続発生回数３１２ｆが許容回数２１２ｇを超える場合には（ステップＳ７０，ＹＥＳ）、処理対象レコードに対応するタスク・プログラム４１に異常（暴走）ありと見做し、異常発生時の動作を行う。すなわち、本例では例えば処理対象レコードの“禁止期間リフレッシュ時動作”２１２ｈで設定されている動作を行う（ステップＳ７１）。尚、“禁止期間リフレッシュ時動作”２１２ｈに上記「関数呼出」が設定されている場合には、“禁止期間リフレッシュ時呼出関数”２１２ｉに登録されている関数を呼出す。

そして、ステップＳ７１の動作が完了したら、ステップＳ６１へ移行する。但し、この場合は、“禁止期間リフレッシュ時動作”２１２ｈに上記ＣＰＵリセットやシステム停止等が指定されている場合には、これらが実行されるので、ステップＳ６１へと移行することなく、初期化処理などが行われることになる。

一方、連続発生回数３１２ｆが許容回数２１２ｇ以下である場合には（ステップＳ７０，ＮＯ）、そのままステップＳ６１へ移行する。
ステップＳ６１では、処理対象レコードを更新する。すなわち、監視条件設定テーブル２１とリフレッシュ記録テーブル３１の処理対象レコードを、それぞれ、現在の処理対象レコードの次のレコード（最初は２番目のレコードとなる）にセットすると共に、変数「処理レコード数」を更新する（＋１インクリメントなど）。尚、変数「処理レコード数」は、図８の処理開始時の初期化処理で‘１’となっているものとする。

そして、上記「処理レコード数」が、上記“監視条件設定データ数”２１１を越えた場合等には、当該監視処理が所定のレコード数分実行終了したものと判定し（ステップＳ６２，ＹＥＳ）、すなわち全てのタスク・プログラム４１について動作異常チェック完了したものとして、当該監視処理を終了する。

「処理レコード数」が上記設定数以下である場合には（ステップＳ６２，ＮＯ）、未処理のレコードがあることになるので、ステップＳ５４に戻り、新たな処理対象レコードについて上記と同様の監視処理を続行する。

ここで、上記ステップＳ６４の監視タイムアップや、ステップＳ５９のリフレッシュ遅延範囲内（逆に、リフレッシュ禁止期間）について、図９を参照して説明する。
図９は、監視タイムアウト、禁止期間について説明する為の図である。

図９において、任意のタスク・プログラム４１のリフレッシュ処理部４２によって、図示の任意のタイミングｔ１でリフレッシュ処理（図７の処理）が正常に行われたものとする。

この例の場合、このタイミングｔ１から上記リフレッシュ監視時間（Tout）経過する前に（図示のタイミングｔ４になる前に）次のリフレッシュ処理が実行されなければ、上記ステップＳ６４の判定がＹＥＳ（監視タイムアウト）となるはずである。つまり、例えば図示のタイミングｔ４以後の任意のタイミングｔ５において図８の監視処理が行われた場合（更に、その時点で未だ、次のリフレッシュ処理が実行されていなかった場合）、上記ステップＳ６３で計算される上記差分‘TIMdif2’は「ｔ５−ｔ１」となり、当然、「‘TIMdif2’＞Ｔout」となる（ステップＳ６４，ＹＥＳ）。

また、タイミングｔ１時点から上記Ｔmin経過した時点（図示のｔ２）までの期間を、上記リフレッシュ禁止期間としている。また、図示のタイミングｔ３から上記タイミングｔ４までの期間も、上記リフレッシュ禁止期間としている。尚、タイミングｔ３は、タイミングｔ１時点から上記Ｔmax経過した時点である。

この様なリフレッシュ禁止期間を設けるのは、任意のタスク・プログラム４１が上記無限ループした場合には図示のように頻繁にリフレッシュ処理が行われることが考えられるので、リフレッシュ禁止期間においてもリフレッシュ処理が行われる可能性が高く、これを以ってタスクの無限ループ発生と判定できる。

尚、上記ステップＳ５９におけるリフレッシュ遅延範囲は、例えば図９に示す期間となる。つまり、タイミングｔ１から上記リフレッシュ監視時間（Tout）経過する前までの期間であって上記リフレッシュ禁止期間以外の期間となる。リフレッシュ遅延範囲は、例えばタスク・プログラム４１が正常であれば必ずリフレッシュ遅延範囲内に次のリフレッシュ処理を行うと考えられる期間を、開発者等が考えて設定する。これより、設定されたリフレッシュ遅延範囲以外の期間が、上記リフレッシュ禁止期間となる。

監視部２４による上記図８の監視処理は、タスク・プログラム４１毎の個別の異常を検出するものであった。これに対して、たとえ図８の処理では異常と判定されない状況であっても、例えば図１０の処理によって異常と判定される場合も起こり得る。すなわち、所定の順番通りに処理実行されるものと決められた複数のタスク・プログラム４１があった場合、これらをグループ化して、グループ内の複数のタスク・プログラム４１が所定の順番通りに処理実行されなかった場合、異常と判定する。

この様な異常を検出する処理の一例を、図１０に示す。
図１０は、監視部２４の処理順序監視動作を説明するフローチャートである。
ここで、図１に示す情報処理装置が、例えば制御システム用のコンピュータ（ＰＬＣ；プログラマブルコントローラ）等である場合においては、複数の定周期タスクが動作する場合が多い。更に、これら複数の定周期タスクは、予め決められた順番で順次実行される場合も少なくない。この様な場合、これら各定周期タスクのリフレッシュ処理も、予め決められた順番で順次実行されることになる。更に、この様な実行順序が決められた複数の定周期タスクを１グループとして、複数のグループが存在する場合もある。

例えばこの様なグループ毎に、そのグループ内の複数のタスク・プログラム４１が予め決められた順番通りに実行されているか否かをチェックして、実行されていない場合には異常と判定する。その為に、上述したリフレッシュ順序設定テーブル２２とリフレッシュ順序記録テーブル３２とを用いて、図１０の処理によって、上記のチェック・異常判定を行う例を示す。

図１０の処理は、図８の処理を実行する毎に行っても良いし、図８の処理とは関係なく定周期で行っても良い。
何れにしても、監視部２４は、図１０の処理を実行開始すると、まず、リフレッシュ順序設定テーブル２２の先頭レコードおよびリフレッシュ順序記録テーブル３２の先頭レコードを、処理対象レコードとしてセットする（ステップＳ８１，Ｓ８２）。

また、尚、上記先頭レコードとは、リフレッシュ順序設定テーブル２２の複数の“リフレッシュ順序設定グループデータ”２２２のうちの先頭（図４では“リフレッシュ順序設定グループデータ（１）”、リフレッシュ順序記録テーブル３２の複数の“リフレッシュ順序記録データ”３２２のうちの先頭（図６では“リフレッシュ順序記録データ（１）”）を、意味するものである。尚、本例では、最初の処理対象レコードを上記先頭レコードとしているが、勿論、この例に限るものではない。

そして、処理対象レコードを順次変えながら、そのときの処理対象レコードに関して、ステップＳ８３〜Ｓ８６の処理を行う。
すなわち、まず、リフレッシュ順序記録テーブル３２における処理対象レコード（上記の通り最初は“リフレッシュ順序記録データ（１）”）に記録されている各カウンタ３２２ｂ（カウンタ（１）、カウンタ（２）、・・・、カウンタ（ｒ））同士を比較することで、カウンタ更新順序が予め決められた順序通りとなっているか否を確認する（ステップＳ８３）。

ここでは、予め決められた順番は、カウンタ３２２ｂの順番通りであるものとする（その様に設定しておく）。よって、図示の例では「カウンタ（１）→カウンタ（２）→・・・→カウンタ（ｒ−１）→カウンタ（ｒ）→カウンタ（１）→・・・」という順番であることになる。まず、このなかで最新の更新が行われたカウンタ３２２ｂを識別する。これは、そのカウンタ３２２ｂの値が、リフレッシュ共通カウンタ３２２ａの値と同一であるものが、最新の更新が行われたカウンタ３２２ｂであることになる。

そして、この最新更新のカウンタ３２２ｂから上記順番の逆に見ていき、カウンタ値が１ずつ減少しているか否かをチェックする。例えば、仮に、最新更新のカウンタ３２２ｂがカウンタ（３）でありその値が‘１００’であったとした場合、正常であれば、カウンタ（２）は‘９９’、カウンタ（１）は‘９８’、カウンタ（ｒ）は‘９７’、カウンタ（ｒ−１）は‘９６’であるはずである。各カウンタ値がこの通りになっているか否かをチェックし、この通りになっているならば順序正常（ステップＳ８４，ＹＥＳ）、この通りになっていない場合には順序異常（ステップＳ８４，ＮＯ）と判定する。

順序異常と判定された場合（設定された順番通りに処理実行されていないと見做せる場合）には（ステップＳ８４，ＮＯ）、リフレッシュ順序設定テーブル２２の処理対象レコードの上記“異常時動作”２２２ａに従った動作を実行する（ステップＳ８５）。“異常時動作”２２２ａで上記「関数呼出」が設定されている場合は、“異常時呼出関数”２２２ｂに登録されている関数を呼出す。

そして、ステップＳ８５の処理を完了したら、ステップＳ８６へ移行する。但し、“異常時動作”２２２ａに上記ＣＰＵリセットやシステム停止等が指定されている場合には、これらが実行されるので、ステップＳ８６へと移行することなく、初期化処理などが行われることになる。

一方、順序正常と判定された場合（設定された順番通りに処理実行されていると見做せる場合）（ステップＳ８４，ＹＥＳ）には、そのままステップＳ８６へと移行する。
ステップＳ８６では、リフレッシュ順序設定テーブル２２およびリフレッシュ順序記録テーブル３２の両方に関して、次の処理対象レコードを決定する。上記の通り最初は先頭レコードが処理対象レコードであるので、２番目のレコードが次の処理対象レコードとなる。

但し、次の処理対象レコードが無ければ（ステップＳ８７，ＹＥＳ）、当該順序監視処理は終了する。未処理のレコードがあれば（ステップＳ８７，ＮＯ）、ステップＳ８３に戻り、次の処理対象レコードについても上記と同様の処理を行う。

以上、本手法では、複数の定周期処理（定周期タスク）から構成されるプログラムであっても、タスク毎に暴走等の異常発生を検出できる。これは、特にタスク毎の異常検出監視時間とリフレッシュ禁止期間を用いた異常判定を行うことができる。よって、例えば、ある定周期タスクのプログラムが上記「無限ループ」になるような場合においても、プログラム異常を検出することができ、プログラム暴走の検出精度の向上が期待できる。

また、図１０の処理によって、複数の定周期タスクが所定の順番通りに実行されないという異常も検出可能となる。
さらに異常検出後の動作をアプリケーション側で柔軟に構成することが可能となる。

１０ プログラム異常検出装置
１１ ＣＰＵ
１２ ＲＡＭ
１３ ＲＯＭ
１４ 外部Ｉ／Ｆ（インタフェース）
２０ プログラム異常検出機能部
２１ 監視条件設定テーブル
２２ リフレッシュ順序設定テーブル
２３ 設定部
２４ 監視部
３０ 記憶領域
３１ リフレッシュ記録テーブル
３２ リフレッシュ順序記録テーブル
４０ アプリケーションプログラム群
４１ プログラム（タスク）
４２ リフレッシュ処理部
２１１ 監視条件設定データ数
２１２ 各監視条件設定データ（（１）〜（ｎ））
２１２ａ リフレッシュ監視時間
２１２ｂ リフレッシュ遅延最小時間
２１２ｃ リフレッシュ遅延最大時間
２１２ｄ 監視時間タイムアップ連続発生許容回数
２１２ｅ 監視時間タイムアップ時動作
２１２ｆ 監視時間タイムアップ時呼出関数
２１２ｇ 禁止期間リフレッシュ連続発生許容回数
２１２ｈ 禁止期間リフレッシュ時動作
２１２ｉ 禁止期間リフレッシュ時呼出関数
２２１ リフレッシュ順序設定グループ数
２２２ リフレッシュ順序設定グループデータ（（１）〜（ｍ））
２２２ａ 異常時動作
２２２ｂ 異常時呼出関数
２２２ｃ 順序設定データ数
２２２ｄ 監視条件設定データ識別子（（１）〜（ｒ））
３１１ リフレッシュ記録データ数
３１２ リフレッシュ記録データ（（１）〜（ｎ））
３１２ａ リフレッシュカウンタ今回値
３１２ｂ タイムスタンプ今回値
３１２ｃ リフレッシュカウンタ前回値
３１２ｄ タイムスタンプ前回値
３１２ｅ 監視時間タイムアップ連続発生回数
３１２ｆ 禁止期間リフレッシュ連続発生回数
３２１ リフレッシュ記録データ数
３２２ リフレッシュ順序記録データ（（１）〜（ｍ））
３２２ａ リフレッシュ共通カウンタ
３２２ｂ カウンタ（（１）〜（ｒ））

Claims (7)

1. 複数の定周期タスクから構成されるプログラムの異常を検出するプログラム異常検出装置であって、
   前記定周期タスク毎に対応して所定のリフレッシュ情報が記憶されるリフレッシュ情報記憶手段と、
   前記定周期タスク毎に対応してその定周期タスクが実行するリフレッシュ処理に関する時間的な条件が登録される条件登録手段とを有し、
   前記各定周期タスクは、それぞれ、前記リフレッシュ処理としてその定周期タスクに対応する前記リフレッシュ情報の更新を行うリフレッシュ手段を有し、
   定期的に、前記定周期タスク毎に、対応する前記リフレッシュ情報を参照して前記時間的な条件を満たしているか否かを判定し、該時間的な条件を満たしていない場合、あるいは複数回連続して該時間的な条件を満たしていない場合には、その定周期タスクの異常と判定する監視手段と、
   を有することを特徴とするプログラム異常検出装置。
2. 前記時間的な条件は、監視タイムアウト時間、及び、リフレッシュ禁止期間であり、
   前記監視手段は、前記定周期タスク毎に、任意の前記リフレッシュ処理実行時から前記監視タイムアウト時間経過するまでに次の前記リフレッシュ処理が実行されなかった場合、あるいは、前記リフレッシュ禁止期間内に前記リフレッシュ処理が実行された場合には、前記時間的な条件を満たしていないと判定することを特徴とする請求項１記載のプログラム異常検出装置。
3. 前記リフレッシュ禁止期間は、任意の前記リフレッシュ処理実行時から前記監視タイムアウト時間経過するまでの期間内であって、任意の前記リフレッシュ処理実行時点から所定の第１の時間経過する時点までの期間であることを特徴とする請求項２記載のプログラム異常検出装置。
4. 前記リフレッシュ禁止期間は、任意の前記リフレッシュ処理実行時から前記監視タイムアウト時間経過するまでの期間内であって、任意の前記リフレッシュ処理実行時から所定の第２の時間経過する時点から、前記監視タイムアウト時間経過時点までの期間であることを特徴とする請求項２記載のプログラム異常検出装置。
5. 前記条件登録手段には、更に、前記定周期タスク毎に、その定周期タスクが異常と判定された場合に対応する動作が登録されており、
   前記監視手段は、任意の定周期タスクに関して異常と判定した場合、その定周期タスクに対応する前記登録されている動作を実行することを特徴とする請求項１〜４の何れかに記載のプログラム異常検出装置。
6. 前記複数の定周期タスクのうち実行順序が決められている複数の定周期タスクを実行順序監視対象として、該実行順序監視対象となる定周期タスク毎に対応して前記実行順序に従って設けられるカウンタ値記憶手段と、
   前記実行順序監視対象となる複数の定周期タスクに共通のカウンタである共通カウンタとを有し、
   前記実行順序監視対象となる各定周期タスクのリフレッシュ手段は、その前記リフレッシュ処理の際に、前記共通カウンタを更新すると共に、そのカウンタ値を自己に対応する前記カウンタ値記憶手段に記憶し、
   前記監視手段は、該各カウンタ値記憶手段を参照することで、前記実行順序監視対象となる複数の定周期タスクが前記実行順序通りに実行されているか否かを判別する処理を更に実行することを特徴とする請求項１〜５の何れかに記載のプログラム異常検出装置。
7. 複数の定周期タスクから構成されるプログラムの異常を検出するプログラム異常検出装置のコンピュータを、
   前記定周期タスク毎に対応して所定のリフレッシュ情報が記憶されるリフレッシュ情報記憶手段と、
   前記定周期タスク毎に対応してその定周期タスクが実行するリフレッシュ処理に関する時間的な条件が登録される条件登録手段とを有し、
   前記各定周期タスクは、それぞれ、前記リフレッシュ処理としてその定周期タスクに対応する前記リフレッシュ情報の更新を行うリフレッシュ手段を有し、
   定期的に、前記定周期タスク毎に、対応する前記リフレッシュ情報を参照して前記時間的な条件を満たしているか否かを判定し、該時間的な条件を満たしていない場合、あるいは複数回連続して該時間的な条件を満たしていない場合には、その定周期タスクの異常と判定する監視手段、
   として機能させるためのプログラム。
   

Images