(57)【要約】【課題】  各種処理タスクにおける異常を漏れなく検出し、必要な処理が意図した順序で正常に実行されていることを検出することのできる制御装置の診断方法を実現する。【解決手段】  各種処理タスクを実行する制御装置のタスク実行状況を監視する診断方法において、前記処理タスクにおける処理単位の実行順を記憶した実行順情報を有し、この実行順情報を基にして実際の処理単位の実行状況を診断することを特徴とする。【選択図】    図１
2006285734.tif 000002
【特許請求の範囲】
【請求項１】
各種処理タスクを実行する制御装置のタスク実行状況を監視する診断方法において、
前記処理タスクにおける処理単位の実行順を記憶した実行順情報を有し、
この実行順情報を基にして実際の処理単位の実行状況を診断することを特徴とする制御装置の診断方法。
【請求項２】
前記処理タスクにおける処理単位は、プログラムのファンクション単位であることを特徴とする請求項１に記載の制御装置の診断方法。
【請求項３】
前記実行順情報は、処理順をインデックスとして、その時に処理すべき処理単位と、次に処理すべき処理単位とを関連させて記憶することを特徴とする請求項１または２に記載の制御装置の診断方法。
【請求項４】
前記実行順情報は、処理タスクの最初の実行時に、プログラムを基に構築されることを特徴とする請求項１乃至３のいずれかに記載の制御装置の診断方法。
【請求項５】
前記処理タスクには、ウォッチドックタイマー処理を含むことを特徴とする請求項１乃至４のいずれかに記載の制御装置の診断方法。
【請求項６】
前記処理タスクは、制御タスクであることを特徴とする請求項１乃至５のいずれかに記載の制御装置の診断方法。
【請求項７】
前記制御タスクには、装置の自己診断を行う診断処理を含むことを特徴とする請求項６に記載の制御装置の診断方法。
【請求項８】
前記実行順情報を基にして実際の処理単位の実行状況を診断する動作を、前記処理タスクの一部として実行することを特徴とする請求項１乃至７のいずれかに記載の制御装置の診断方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プラントに配置されたフィールド機器を管理・制御するプラント制御システムにおいて、制御動作における各種処理タスクの実行状況を監視する診断方法に関するものである。
【背景技術】
【０００２】
このようなプラント制御システムにおいては、プラントの安全を図るために安全システムが導入されている。安全システムは、フィールド機器などに異常が認められた場合に、警報を通知するとともに、必要な措置を実行するシステムであり、プラント制御システムの一部として、あるいは、プラント制御システムとは独立して設けられる。
【０００３】
図８は、従来の診断機能を有する制御装置の一例を示す構成図である。図において、１はフィールド機器からのプロセスデータを取り込み、制御バルブなどの操作端を駆動する制御信号を出力する制御装置、２は制御装置１の設定値を変更したり、動作状態の監視などを行うエンジニアリングステーション、３はこれらの機器間を接続する制御バスである。制御装置１は各種の処理タスクを有するものであるが、ここでは、診断タスク１０および制御タスク２０を例示している。
【０００４】
診断タスク１０は、設定された診断周期（例えば、１秒）で動作し、フィールド機器の異常診断や、制御装置１の自己診断などを行い（診断処理１１）、異常が認められた場合には、警報を通知するとともに、必要な措置を実行したり、システムを停止させる。
【０００５】
制御タスク２０は、設定された制御周期（スキャン周期）で動作し、プロセスデータなどを取り込むＩＮＰＵＴ処理２１、各種演算などを行うＬＯＧＩＣ処理２２、制御信号などを出力するＯＵＴＰＵＴ処理２３を実行する。また、処理の異常を検出するために、ウォッチドックタイマーを起動するＷＤＴ（ウォッチドックタイマー）処理２４を行う。
【０００６】
したがって、フィールド機器や制御装置１のハードウエア的な故障などは、診断処理１１により検出することができ、ソフトウエアの暴走などは、ＷＤＴ処理２４により検出することができる。
【０００７】
【特許文献１】特開平０７−０５６７７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記のような制御装置の診断方法においては、以下のような状況においては、異常が検出されず、安全上問題となってしまう。
【０００９】
図９は、診断処理１１における各種診断（処理単位）の流れを示すフロー図である。図において、（ａ）は本来の処理順を示すフローであり、例えば、フィールド機器（１）の診断１１−１、フィールド機器（２）の診断１１−２、フィールド機器（３）の診断１１−３、・・・の順で診断の実行が設定されている。
【００１０】
これに対して、（ｂ）に示す如く、一部の処理（診断１１−２）が抜けてしまうと、フィールド機器（２）の故障を検出することができず、故障した機器により制御動作が継続されてしまう恐れがある。
【００１１】
図１０は、ＬＯＧＩＣ処理２２における各種処理（処理単位）の流れを示すフロー図である。図において、（ａ）は本来の処理順を示すフローであり、例えば、演算（１）２２−１、演算（２）２２−２、演算（３）２２−３、・・・の順で各種演算の実行が設定されている。
【００１２】
これに対して、（ｂ）に示す如く、演算の順序が入れ替わってしまうと、意図した演算結果を得ることができず、正常な制御動作を行うことができなくなってしまう。
また、ＩＮＰＵＴ処理２１やＯＵＴＰＵＴ処理２３においても、処理順が狂うと、適切でないデータを読み込んだり、書き込んでしまう可能性がある。
【００１３】
図１１は、ＷＤＴ処理２４における誤検出の様子を示すフロー図である。図において、（ａ）を本来の処理順を示すフローとし、例えば、処理（１）２５−１、処理（２）２５−２、処理（３）２５−３、・・・の順で各処理が実行され、各処理の終了に応じてＷＤＴがトリガされているとする。
【００１４】
ここで、（ｂ）に示す如く、同じ処理２５−４が繰り返され、ＷＤＴにトリガが供給され続けた場合には、ＷＤＴは期待される監視動作を行うことができず、処理の異常を検出することができない。
【００１５】
従来、このような処理タスク内の処理順に関しては、監視する手段がなく、必要な処理が意図した順序で正常に実行されているか否かを検出することはできない。
【００１６】
本発明は、上記のような従来装置の欠点をなくし、各種処理タスクにおける異常を漏れなく検出し、必要な処理が意図した順序で正常に実行されていることを検出することのできる制御装置の診断方法を実現することを目的としたものである。
【課題を解決するための手段】
【００１７】
上記のような目的を達成するために、本発明の請求項１では、各種処理タスクを実行する制御装置のタスク実行状況を監視する診断方法において、前記処理タスクにおける処理単位の実行順を記憶した実行順情報を有し、この実行順情報を基にして実際の処理単位の実行状況を診断することを特徴とする。
【００１８】
請求項２では、請求項１の制御装置の診断方法において、前記処理タスクにおける処理単位は、プログラムのファンクション単位であることを特徴とする。
【００１９】
請求項３では、請求項１または２の制御装置の診断方法において、前記実行順情報は、処理順をインデックスとして、その時に処理すべき処理単位と、次に処理すべき処理単位とを関連させて記憶することを特徴とする。
【００２０】
請求項４では、請求項１乃至３のいずれかの制御装置の診断方法において、前記実行順情報は、処理タスクの最初の実行時に、プログラムを基に構築されることを特徴とする。
【００２１】
請求項５では、請求項１乃至４のいずれかの制御装置の診断方法において、前記処理タスクには、ウォッチドックタイマー処理を含むことを特徴とする。
【００２２】
請求項６では、請求項１乃至５のいずれかの制御装置の診断方法において、前記処理タスクは、制御タスクであることを特徴とする。
【００２３】
請求項７では、請求項６の制御装置の診断方法において、前記制御タスクには、装置の自己診断を行う診断処理を含むことを特徴とする。
【００２４】
請求項８では、請求項１乃至７のいずれかの制御装置の診断方法において、前記実行順情報を基にして実際の処理単位の実行状況を診断する動作を、前記処理タスクの一部として実行することを特徴とする。
【発明の効果】
【００２５】
このように、処理タスクにおける処理単位の実行順を記憶した実行順情報を設け、この実行順情報を基にして実際の処理単位の実行状況を診断するように構成すると、必要な処理が意図した順序で実行されているか否かを容易に検出することができる。
また、処理タスクの最初の実行時に実行順情報を構築するようにすると、処理タスクの実行内容が逐次変更されるような場合でも、処理タスクの変更の都度、実行順情報を再構築することができ、常に変更された実行内容に基づいて監視を行うことができる。
さらに、ＷＤＴ処理を処理タスクの中に含めることにより、処理時間に対する異常を検出することができ、一連の処理が時間内に実行されているか否かを検出することができる。
【発明を実施するための最良の形態】
【００２６】
以下、図面を用いて、本発明の制御装置の診断方法を説明する。
【実施例１】
【００２７】
図１は、本発明の制御装置の診断方法の一実施例を示す構成図である。図において、前記図８と同様のものは同一符号を付して示す。３０は制御装置１内で実行される制御タスクであり、この制御タスク３０は、診断処理３１、ＩＮＰＵＴ処理３２、ＬＯＧＩＣ処理３３、ＯＵＴＰＵＴ処理３４、ＷＤＴ処理３５から構成され、これらの処理を順次実行する。なお、各処理の内容は、前記図８における同一名の処理と同様である。
また、制御タスク３０は、各処理の実行順および各処理内における処理単位の実行順を監視する実行順監視機能３６を有している。
【００２８】
図２は、制御タスク３０における各処理の実行順および実行順監視動作の一例を示すフロー図である。設定された制御周期に応じて制御タスク３０が起動されると、まず、診断処理３１が実行される。
【００２９】
図３は、診断処理３１の一例を示すもので、フィールド機器の故障診断やメモリのチェックなど、一連の診断処理１〜診断処理Ｎを決められた順序で実行する。
ここで、各診断処理１〜診断処理Ｎの終了時には、実行順のチェックが行われ、実行順の異常が検出された場合には、異常終了として、警報の通知やシステムのシャットダウンなど、必要な措置が取られる。
【００３０】
図４は、実行順のチェック動作を説明するフロー図である。なお、診断処理１〜診断処理Ｎなどの処理単位における実行順情報は、図５の如き実行順テーブルとして記憶されている。
このテーブルにおいて、Ｉｎｄｅｘは処理単位の処理順、Ｃｕｒｒｅｎｔは現在地点を０以外の整数で指定したもので、最初の地点ならばＳＴＡＲＴを指定する。Ｎｅｘｔは次に呼び出す地点を０以外の整数で指定したもので、最初の地点ならばＳＴＡＲＴを指定する。
【００３１】
図４に戻って、実行順チェックの開始時には、実行順テーブルのＩｎｄｅｘポインタを初期化し、処理１（診断処理１）の実行順をテーブルと比較する。実行順テーブルのＩｎｄｅｘが指す所に処理１の情報があるか、情報があれば処理１のＣｕｒｒｅｎｔおよびＮｅｘｔが実行順テーブルの各々と一致しているかを調べる。なお、ＣｕｒｒｅｎｔまたはＮｅｘｔが０ならば、情報未登録である。
【００３２】
比較結果が正常であれば、処理単位（診断処理１〜診断処理Ｎ）の実行終了に合わせて、順次Ｉｎｄｅｘポインタを更新し、同様な比較動作を繰り返す。
最後の処理Ｎまで比較を行い、異常が検出されなければ、診断処理３１が実行順を含めて正常に終了したことになる。
【００３３】
したがって、診断処理３１を処理単位（診断処理１〜診断処理Ｎ）の実行順を含めて監視することができ、前記した図９のような処理の抜けによる不具合を防止することができる。
【００３４】
図２に戻って、診断処理３１が終了すると、この診断処理３１に対する実行順のチェックが行われ、処理がＩＮＰＵＴ処理３２へ移される。
このとき使用される実行順情報は、前記図５の如き、実行順テーブルの形式で記憶したものでも良いし、制御タスク３０中に持っている順序情報を利用しても良い。
【００３５】
ＩＮＰＵＴ処理３２の次は、ＬＯＧＩＣ処理３３に移るが、ＬＯＧＩＣ処理３３はエンジニアリングステーション２などからのオンラインメンテナンス操作により、処理の内容が変更される可能性がある。
このような場合には、ＬＯＧＩＣ処理３３を実行する前に、図６に示す如く、実行順情報の作成を行う。
【００３６】
図６は、ＬＯＧＩＣ処理３３の一例を示すフロー図である。ＬＯＧＩＣ処理３３においては、その実行前に、処理が初回の実行であるか否かが判断される。初回の実行とは、制御装置１の起動後に、制御タスク３０が始めて動作した場合と、処理の内容が変更された後に、制御タスク３０が始めて動作した場合とが該当する。
【００３７】
制御タスク３０が初回の実行であった場合、処理単位（ＬＯＧＩＣ処理１〜ＬＯＧＩＣ処理Ｎ）の実行前に実行順情報の作成が行われる。
実行順情報の作成は、プログラムの記載に基づき、図７に示す如き手順により行われ、前記図５の如き、実行順テーブルを再構築する。図７に示すように、処理１（ＬＯＧＩＣ処理１）の実行順を実行順テーブルのＮｏ．１（Ｉｎｄｅｘ）に登録し、以下、順に処理Ｎ（ＬＯＧＩＣ処理Ｎ）までを実行順テーブルに登録する。最後に、実行順テーブルに登録された数字に重複がないか、整合が取れているかなど、実行順テーブルのチェックをして、実行順テーブルの作成を終了する。
【００３８】
このように、初回の実行時には、実行順情報（実行順テーブル）が構築され、その後、処理単位（ＬＯＧＩＣ処理１〜ＬＯＧＩＣ処理Ｎ）とともに、この実行順情報を使用して実行順のチェックが行われる。
したがって、処理タスクの実行内容が逐次変更されるような場合であっても、処理タスクの変更の都度、実行順情報を再構築することができ、常に変更された実行内容に基づいて実行順の監視を行うことができる。
また、実行順情報（実行順テーブル）の構築を自動的に行うため、実行内容の変更に対処するための特別なエンジニアリングは必要としない。
【００３９】
なお、ここでは、ＬＯＧＩＣ処理３３内の処理単位（ＬＯＧＩＣ処理１〜ＬＯＧＩＣ処理Ｎ）に対する実行順情報（実行順テーブル）のみを書き換える場合を例示したが、他の処理に対する実行順情報（実行順テーブル）も同時に書き換えるようにすることも可能である。
【００４０】
その後、タスクの実行は、ＯＵＴＰＵＴ処理３４、ＷＤＴ処理３５と進み、全ての処理に対して、同様の実行順チェックが実施される。
ここで、ＷＤＴ処理３５のように、時間に制約を持たせる処理を実行順チェックの対象に含ませているので、ソフトウエアの暴走などとともに、必要な一連の処理が時間内に実行されているか否かを検出することができる。
【００４１】
また、制御タスク３０の中に診断処理３１が含まれているので、制御タスク３０が起動される都度、診断動作を実行することができ、制御周期に合わせて、きめ細かく診断処理３１を行うことができる。
【００４２】
以上説明したように、処理タスクにおける処理単位の実行順を記憶した実行順情報を設け、この実行順情報を基にして実際の処理単位の実行状況を診断するように構成すると、必要な処理が意図した順序で実行されているか否かを容易に検出することができる。
また、実行順チェックのために、高速なＣＰＵ演算能力や特別なメモリなど、特別な機構を必要としないので、ＣＰＵの負荷を増加させることなく、確実に監視動作を行うことができる。
【００４３】
なお、上記の説明においては、処理タスクの一例として制御タスク３０を例示したが、本発明の対象は制御タスク３０のみに限らず、他の処理タスクにも応用することができるものである。
【００４４】
また、実行順監視機能３６を制御タスク３０の中に持たせる場合を例示したが、実行順監視機能３６を監視すべき処理タスクと独立に動作させることも可能である。
【図面の簡単な説明】
【００４５】
【図１】図１は本発明の制御装置の診断方法の一実施例を示す構成図。
【図２】図２は制御タスク３０における各処理の実行順および実行順監視動作の一例を示すフロー図。
【図３】図３は診断処理３１の一例を示すフロー図。
【図４】図４は実行順のチェック動作を説明するフロー図。
【図５】図５は実行順のチェック動作に使用される実行順テーブル。
【図６】図６はＬＯＧＩＣ処理３３の一例を示すフロー図。
【図７】図７は実行順情報の作成動作を説明するフロー図。
【図８】図８は従来の診断機能を有する制御装置の一例を示す構成図。
【図９】図９は診断処理１１における各種診断（処理単位）の流れを示すフロー図。
【図１０】図１０はＬＯＧＩＣ処理２２における各種処理（処理単位）の流れを示すフロー図。
【図１１】図１１はＷＤＴ処理２４における誤検出の様子を示すフロー図。
【符号の説明】
【００４６】
１      制御装置
２      エンジニアリングステーション
３      制御バス
１０    診断タスク
１１、３１    診断処理
２０、３０    制御タスク
２１、３２    ＩＮＰＵＴ処理
２２、３３    ＬＯＧＩＣ処理
２３、３４    ＯＵＴＰＵＴ処理
２４、３５    ＷＤＴ処理
３６      実行順監視機能
【図１】
2006285734.tif 000003
【図２】
2006285734.tif 000004
【図３】
2006285734.tif 000005
【図４】
2006285734.tif 000006
【図５】
2006285734.tif 000007
【図６】
2006285734.tif 000008
【図７】
2006285734.tif 000009
【図８】
2006285734.tif 000010
【図９】
2006285734.tif 000011
【図１０】
2006285734.tif 000012
【図１１】
2006285734.tif 000013