JP2006048402A

JP2006048402A - コントローラ

Info

Publication number: JP2006048402A
Application number: JP2004229060A
Authority: JP
Inventors: Koji Matsuoka; 康二松岡
Original assignee: Yokogawa Electric Corp
Current assignee: Yokogawa Electric Corp
Priority date: 2004-08-05
Filing date: 2004-08-05
Publication date: 2006-02-16

Abstract

【課題】汎用コントローラで制御対象のシステムの運転を停止すること無しに、ハードウェア診断プログラムを状況に合わせた任意の優先順位で実行させる手段を提供する。
【解決手段】制御対象のシステムで用いるＯＳを備えたコントローラにおいて、前記制御対象のシステムを通常運転する際に実行される運転用プロセスと並列して診断用プロセスを実行する診断実行手段と、前記診断用プロセスの実行優先順位を指定する優先度制御手段とを備えたことを特徴とするコントローラであり、前記診断用プロセスに、所定のハードウェア診断を実行させる。
【選択図】図１

Description

本発明は、各産業界で各種用途に適用され、管理対象システムを制御するコントローラに関する。より詳しくはソフトウェアにマルチプロセス対応のオペレーティングシステム（ＯＳ）を搭載した汎用のコントローラに関する。

マルチプロセス対応のオペレーティングシステムを搭載したコントローラに係わる先行技術として、例えば次のような文献がある。

特開平５−２１６６９４号公報

特許文献１は、外部機器と通信を行うコントローラのマルチタスクオペレーティングシステムに係わり、特に受信バッファを扱う受信タスクのプライオリティの制御方法に関する。

また、コントローラに関連しコンピュータの制御方式に係わる先行技術として、例えば次のような文献がある。
特開２００３−８４９８９号公報

特許文献２は、コントローラとしても使用可能なコンピュータにおいて、ジョブまたはプロセスのプライオリティ動的制御方式とその制御用プログラムを開示する。すなわち、実行中のジョブまたはプロセスのプライオリティを、外部の記憶装置を用いてコンピュータが決定し動的な変更を行うプログラムに関する。

本発明のコントローラは、Ｃ言語などの汎用の開発言語でそのプログラムが記載されたコンピュータ若しくはプロセッサ（以下、ＣＰＵと記す）を有し、プライオリティ制御機能を持つオペレーティングシステムやモニタププログラムが搭載されていることを前提としている。

また、本発明のコントローラが管理する管理対象システムとは、広く産業界で用いられる各種施設や設備装置など、業種業界や規模の大小を問わず１点以上の監視や制御を必要とする制御点を含み、これら制御点を所定の管理方針に基づいて有機的に結合させた集合体である。

より具体的には、管理対象システムが工場プラントの工業用計器や装置群である場合や、物流システム、運輸システム、或いは有人または無人の諸施設などが該当する。

すなわち、本発明のコントローラは管理対象システム内のフィールド機器を始めとする各種計装機器やセンサ群、装置、設備群を所定の方針の基に全体を協調して機能させ、所定の状態を維持し効率良く運用し生産活動をすべく管理する役割を担う。

例えば管理対象システムがプラント設備の工業計器や装置である場合、プラント内の制御点からリアルタイム情報を収集して得られた定量値情報に基づいて、所定の制御方針に従い所望の状態や結果を得るべく適切な処置を施すフィードバック制御を行う。

コントローラのソフトウェアは、管理対象内でそれぞれが機能や作用の異なる各種設備や機器を制御する際に、対象となる設備や目的毎に最適なプロセスが必要である。

一般にコントローラのオペレーティングシステム（以下ＯＳと表す）は、複数プロセスとこれら複数プロセスを対象とする優先（以下プライオリティと表す）制御機能を備えたソフトウェアモジュール構成を採用している。

これらのプロセス群はコントローラのＯＳが備えたプライオリティ制御機能やスケジューラ機能等によってその実行を管理されている。

コントローラは、通常の運転や運用活動に相当する運転モードに加えて、メンテナンスや障害切り分時など、敢えて通常の生産処理活動を一時中断させて行う診断モードを別に備えることがある。

すなわち、通常の運転モードで得られるセンサ等の出力値や警報情報のみではシステム内で発生進行している障害の箇所や内容が正確に把握できない場合がある。このような場合にはコントローラを運転モードから診断モードに切り替え、通常処理に係わるプロセスを一時中断してから診断用プログラムを起動する。

図５では従来例１として、このような診断モードを実装したコントローラのソフトウェアのシステム構成例を示している。コントローラのソフトウェアモジュールが、通常モードに相当するモードＰと、通常モードを一旦中断して行うモードＱとの２種類から構成されている。

モードＰで用いるソフトウェアモジュール群は、プロセス１、プロセス２、プロセス３の他にデバイスドライバインタフェース４、リアルタイムＯＳ５、ハードウェアアクセスインタフェース６の各ソフトウェアモジュールが含まれている。リアルタイムＯＳ５には、スケジューラ５１が内部に含まれている。

一方、モードＱで用いるソフトウェアモジュールでは、プロセスに相当する診断用プログラム７のみで構成されている。

次に、図５の構成図の作用を説明する。コントローラの通常の生産処理活動に係る運転モードはモードＰに設定される。モードＰでは図５の例としてプロセス１、２及び３の３つのプロセスをコントローラにロードし実行している状態を示している。

モードＰにおけるプロセス数は図５でプロセス１、２および３のみ示してあるが、コントローラの内部資源の規模や制御対象数に応じて適宜Ｎ個（Ｎ＝１，２、・・・Ｎ）までを用いて良い。

通常の運転モードの状態下で並列実効されるプロセス１、２、３のそれぞれは、コントローラが内部に備えるＣＰＵ（図示しない）によって時分割処理されている。

リアルタイムＯＳ５では、各プロセス処理に割り当てるＣＰＵの連続占有実行時間を、規格化された最小マシンタイムであるクオンタムを単位として、細分化した状態で割り当てる。

これらのプロセスを実行する際には、ＣＰＵのマシンタイムの利用規定としてそれぞれが所定の占有許可時間長（以下、スレッドと表す）を割り当てられて実行されている。

例えばリアルタイムＯＳ５がプロセス１を処理する場合には、連続２クオンタムの時間に亘りＣＰＵの処理時間を占有する。一方プロセス２またはプロセス３を処理する場合では、連続１クオンタムの時間に亘りＣＰＵの処理時間を占有する。

同一のプロセスに属して、連続Ｎクオンタム（Ｎ＝１，２、・・・Ｎ）に亘りＣＰＵの処理時間を占有して実行するＣＰＵの連続処理量を、一般にスレッドと称している。

またこのスレッドは、コントローラ内のＣＰＵが同一メモリ空間で実行を継続できる、同一プロセス処理の一部または全体を構成する実行ステップ量にも相当する。

プロセス１、２，３から観て、自分のプロセスに割り当てられたスレッドクオンタムの時間が巡ってきたときスケジューラ５１の指示に基づきＣＰＵの処理時間を占有することができる。

このようにマシンタイムをプロセス毎に長さが異なるスレッドクオンタムに細分化してＣＰＵに隙間無くスケジューリングすることで、リアルタイムＯＳ５はあたかもプロセス１、２、３を並列処理するかの如く、時分割でのマルチスレッド処理を実行する。

各プロセスのスレッドクオンタムをＣＰＵにスケジューリングする際は、それぞれのプロセスに割り当てられている実行処理の緊急度合すなわちプライオリティに基づいて時間割が作成され、スケジューラ５１が管理している。

この結果、コントローラのＣＰＵがプロセス１、２、３を並列処理するに当たり各スレッドに所定の処理時間であるスレッドクオンタムを配分している。

一方、制御対象のシステムの運用過程でハードウェア診断が必要となった場合は、診断用プログラム７が実行出来るようにモードＰからモードＱへの切換が必要である。

モードＱは、センサ出力値の異常、設定目標値からの乖離、機器の動作不良などの運転中に発見した障害の究明や、原因の早期切り分け、所定のハードウェア資源を対象とした点検チェックなどに使用する。

図５に示す様に、コントローラが動作モードで用いたソフトウェアモジュール群は全て診断用プログラム７に置き換えられる。

この様に、診断の際にコントローラの通常動作を停止して、リソース内の全域を使用した診断プログラム７をロードすることで、通常運転中には実行不可能であった診断作業に集中することが出来る。

また、モードＰとモードＱとをコントローラ資源上で同時に共存させず完全に排他的にロードされるため、両モードで個別にソフトウェアモジュールの版数管理やメンテナンスができる利点もある。

ところが、従来例１として図５に示すソフトウェアモジュール構成には、以下のような問題点があった。

第一の問題点は、診断用プログラムを実行する際、運転を一時中断しなければならないことである。すなわちコントローラから通常運転用のソフトウェアモジュール群を一旦全て退避させ、診断用プログラムをロードしなければならないことである。

このためモードＰを中断してモードＱに移行後、所定のハードウェア診断を終えて再びモードＰに復帰するまでの時間、管理対象システムの運転を停止させることになり、システムの運用効率が著しく低下する問題があった。

第二の問題点は、コントローラの制御端末等における操作手順が煩雑となりオペレータの手間と工数を要することである。すなわちモード切り替え操作に続く診断プログラムのロードと診断実行、運転モードへ復帰といった一連の操作は長時間に及ぶ場合が多く、作業を行うオペレータの負担が多きい。

第三の問題点は、通常の運転状態下でのハードウェア診断データを得られないことである。すなわち運転中に生じた不具合を、運転を停止させた状態で診断しなければならない。このために管理対象の障害や異常値が診断モードでは再現しなかった場合、不具合原因の究明作業や解析は困難を極めた。

すなわち既存のコントローラには、通常の稼動条件下にある設備やフィールド機器、開閉ループ群に属する装置等を対象として診断作業を併せて実施する作用をもつ、運転用プロセスと診断用プロセスの並列稼動の環境を提供する手段が存在しなかった。

以上の従来例１の問題点に鑑みて例えば図６に示す従来例２では、コントローラの実行モードを切り替えることなく、診断用プログラムを実行する。

従来例２である図６では、このような診断用プログラムを使用するプログラムコントローラのソフトウェア構成例を示している。この例では、プログラムコントローラのソフトウェアが、通常の運転モードに相当するプロセスの一つとして診断用プログラムを常駐させている。

図６で示す構成要素の内、図５の従来例１で説明した図中記号と同一記号のモジュールは、従来例１と同一作用を持つ構成要素であるので説明を省略する。

従来例２では、運転中のプログラムコントローラにプロセス１、プロセス２、プロセス３とデバイスドライバインタフェース４、リアルタイムＯＳ５、ハードウェアアクセスインタフェース６の各ソフトウェアモジュール群に加えて、診断プロセス１０を実装している。

次に、図６の構成図の作用を説明する。診断用プロセス１０は、通常運転モードの状態でコントローラにロードされて、リアルタイムＯＳ５内部に備えたスケジューラ５１が、プロセス１，２，３と並列に一括して実行管理される。

ところで、従来例２において診断用プロセス１０を実行させる緊急度を事前に正確に予見することは困難である。仮に制御対象の、例えば処理プラント等が通常運転中にハードウェア診断を必要とする事態が何も生じなければ、コントローラのメモリ資源を無駄に消費して通常運転に全く寄与しないばかりかスケジューラ５１の作業負荷を増大させてしまう。

このため、リアルタイムＯＳ５はプロセス１、２，３の実行スレッドのプライオリティを相対的に高く設定し、診断用プロセス１０はこれらに比して最低プライオリティに予め設定しておく必要がある。

ところが逆に、管理対象のシステムで例えば特定フィールド機器や特定制御ループに属する設備のハードウェア診断が急遽必要になり、診断用プロセス１０の実行が必要とされる場合、最低プライオリティに設定してある診断用プロセス１０では、確実な実行を担保することは困難である。

すなわち図６の従来例２の様に、例えハードウェア診断用プロセスを通常運転下のコントローラに常駐させたとしても、適切なプライオリティ制御が為されなければ、適切な時点で実行させることが出来ない問題がある。

さらに、ハードウェアの定期検診として例えば通常運転を実行しつつ一定周期で所定のハードウェア診断を実施させる手段も存在しながった。

以上の従来例１及び従来例２の問題点に鑑みて、例えば図７の従来例３ではコントローラのモードを切り替えることなく、診断機能の処理時間を確保したソフトウェアの実装方式例を示している。

従来例３である図７は、処理対象システムを通常運転中に診断用プログラムを実行するコントローラのソフトウェア構成例を示している。通常運転中に実行させるソフトウェアモジュールを単一プロセスで構成して、当該プロセス処理過程の一部にハードウェア診断処理を実行スケジュールに予め組み込むことで診断用プログラム実行時間を確保している。

図７の従来例３では、コントローラのソフトウェアが単一プロセスに属したタスクとして処理Ａ、処理Ｂ、処理Ｃ及び診断機能Ｄとで構成され、これらタスクの実行順序が処理Ａ、処理Ｂ、処理Ｃ、診断機能Ｄの順に連続して繰り返すラウンドロビン・スケジューリングの形式で実行される。

図７の別の見方として、従来例３の各タスクＡ，Ｂ，Ｃ，Ｄをそれぞれプロセスとして置き換え、予め同一クラスのプライオリティに設定した状態で処理Ａ、処理Ｂ、処理Ｃ、診断機能Ｄの４つのプロセスを扱うラウンドロビン・スケジューリングとして実行させても同等の結果を得る。

ところが、図７の従来例３は各プロセスまたはタスクに相当する処理Ａ、Ｂ，Ｃ及び診断機能Ｄが固定優先度であるため、高い優先度を要求されるリアルタイム処理の実行には不向きである。

すなわちシステムの規模が大きくなるに従い、各プロセスまたはタスクにとってＣＰＵ処理時間として付与されるクオンタムが与えられる周期間隔が長くなると共に、プロプラムの開発効率も低下しメンテナンス上不利である。

本発明は上述した従来例１、２、３の問題点を解決するために成され、その目的はコントローラで制御対象のシステムの運転を停止すること無しに、ハードウェア診断プログラムを状況に合わせた任意の優先順位で実行させる手段を提供することにある。

このような目的を達成するために、本発明のうち請求項１記載の発明は、
制御対象のシステムで用いるＯＳを備えたコントローラにおいて、
前記システムを通常運転する際に実行される運転用プロセスと並列して診断用プロセスを実行する診断実行手段と、前記診断用プロセスの実行優先順位を指定する優先度制御手段と、を備えたことを特徴とするコントローラである。

請求項２記載の発明は、
前記診断用プロセスは、所定のハードウェア診断を実行することを特徴とする請求項１に記載のコントローラである。

請求項３記載の発明は、
前記診断用プロセスに所定の優先順位を設定する入力部を備えたことを特徴とする請求項１または２に記載のコントローラである。

請求項４記載の発明は、
前記診断用プロセスの診断結果を出力する出力部を備えたことを特徴とする請求項１から３までの何れかに記載のコントローラである。

請求項５記載の発明は、
前記優先度制御手段は、前記診断用プロセスが所定の診断を終了すると前記優先順位を最低優先順位に設定することを特徴とする請求項１から４までの何れかに記載のコントローラである。

請求項６記載の発明は、
前記診断用プロセスは、前記リアルタイムＯＳ内で用いている所定のグローバル変数を介して前記運転用プロセスから所定のパラメータ取得を行うことを特徴とする請求項１から３までの何れかに記載のコントローラである。

請求項７記載の発明は、
前記入力部は、通信用インタフェースと接続することを特徴とする請求項３に記載のコントローラである。

請求項８記載の発明は、
前記出力部は、通信用インタフェースと接続することを特徴とする請求項４に記載のコントローラである。

請求項９記載の発明は、
前記出力部は、前記リアルタイムＯＳで現在実行中の前記運転用プロセス及び前記診断用プロセスについてその数と各々の実行状況とを出力することを特徴とする請求項４に記載のコントローラである。

請求項１０記載の発明は、
制御対象のシステムで用いるＯＳを備えたコントローラにおいて、
前記システムを通常運転する際に実行される運転用プロセスと並列して診断用プロセスを実行する診断実行手段と、前記診断用プロセスの実行優先順位を指定する優先度制御手段と、前記ＯＳの許容占有時間長を指定する動作時間制御手段と、を備えたことを特徴とするコントローラである。

請求項１１から請求項１８記載の発明は、請求項１０に従属し請求項１に対する請求項２から請求項９までの付加内容と同一である。

本発明によれば、以下のような効果がある。
第一の効果は、診断用プロセスがコントローラのモード変更を伴う管理対象システムの運転停止に至ることなく確実に実行できる効果がある。

すなわち診断用プロセスのプライオリティ値が緊急度に応じたレベルに可変できることから従来例２では実現不可能であった、診断プロセスのスレッドクオンタムが着実にスケジューラ上で確保される。

このため任意の機器を対象としたハードウェア障害切り分けが運転中の日常業務の中で手軽かつ柔軟に実行でき、システム運用効率と信頼性とを格段に向上させる。

第二の効果は、コントローラの制御端末におけるオペレータの手間と工数を軽減することである。ハードウェア診断を実行する場合は、従来要していたモード切り替え操作に続く診断プログラムのロードに診断、運転モードへの復帰といった一連の長時間の操作は必要なく、作業を行うオペレータの負担を軽減させる。

第三の効果は、通常の運転状態下にある管理対象システムのハードウェア診断データを得られることである。すなわち運転中に生じた不具合を、運転を続行させた状態で診断できる。このためハードウェア障害が疑われる状態を運転中に認めた場合は、直ちに不具合原因の究明作業に着手し原因の切り分けに着手できる。

第四の効果は、診断用プロセスの実行を制御する入力部と出力部とを備えたので、例えば通信用インタフェースを介したリモート制御端末から、当該コントローラ配下の任意のハードウェアを対象とする診断を任意の時間に指令し、その結果を着実かつ速やかに入手できることである。

第五の効果は、緊急時には臨時のハードウェア診断の強制実行が可能である他に、通常運転時に於いては運転に支障を与えること無く、ほぼ一定間隔の周期で実行されるハードウェア定期診断機能が実装可能である。

この効果は、診断用プロセスのプライオリティについて、必要の無いときはデフォルト状態の最低クラスに設定した事実上全く実行されない状態から、必要な場合には、最高クラスのプライオリティに設定した最優先で実行される状態までを任意のレンジ幅で設定できる特徴から与えられている。

すなわち、ハードウェア診断用プロセスのプライオリティを、現状の運転用プロセス群のプロセス数やＣＰＵ負荷状況に応じ、適切な値にその都度設定する特徴によって実現している。

従って管理対象システムの管理保守手段として有効でありハードウェアの信頼性を向上させて稼動効率を改善するとともに、オーバーホール定期診断やメンテナンス時には重点検査箇所を限定でき管理工数を低減する。

さらに、ハードウェア診断プロセスに対するプライオリティの制御に加えて、スレッドクオンタムの制御をも併せて付加したことから、現状の運転用プロセス群に対する影響を更に低減できる。

このため通常運転に支障を与えること無しに、多種多様のハードウェア診断プログラムを同時に並列に待機させ、必要に応じ最適化したスケジューリングにアレンジし臨機応変に実行させることができる。

本発明について実施例に基づき詳細に説明する。

本発明の実施例１は、図１の構成ブロック図に示している。

実施例１ではコントローラが備えたソフトウェアモジュールとして、プロセス１、プロセス２、プロセス３の他にデバイスドライバインタフェース４、ＯＳとしてリアルタイムＯＳ５、ハードウェアアクセスインタフェース６、及び診断用プロセス２０及び診断実行手段３０をもつ。

診断用プロセス２０の内部には、優先度制御手段２１を備えている。診断実行手段３０の外部には、入力部３１及び出力部３２を備え、入力部３１及び出力部３２は信号経路４０を介して診断実行手段３０に属する診断プロセス２０と接続している。

入力部３１及び出力部３２は実施例１に相当するコントローラ筐体の内部に設けても、外部に設けてもどちらでも差し支えない。例えば、入力部３１及び出力部３２を遠隔地に備えた制御用コンピュータの端末装置として実施すれば、信号経路４０を公衆回線や専用線などを含む通信用インタフェースで実施することができる。

次に図１の実施例１の作用について説明する。プロセス１、プロセス２及びプロセス３はコントローラが制御している制御対象システムの通常運転に対応している。診断用プロセス２０は、実行優先度が初期状態である最下位クラスに設定され、通常はスリープ状態を維持して待機している。

診断実行手段３０は、コントローラのハードウェアが備えた図示しないＣＰＵと、そのＣＰＵの実行用に記述された診断のためのソフトウェア・プログラムであり、診断プロセス２０を実行させる機能をもつ。

入力部３１は、診断要求Ｃと診断要求Ｃの付属パラメータであるプライオリティ値Ｐ１とを入力する作用をもつ。信号経路４０を経由して、診断要求Ｃは診断プロセス２０へ、プライオリティ値Ｐ１は優先度制御手段２１へ供給している。出力部３２は診断プロセス２０と接続して、診断用プロセス２０が発行する結果出力Ｒを受信する。

制御対象システムを通常運転中にハードウェア診断の必要が生じた場合は、コントローラでは診断用プロセス２０に診断要求Ｃとプライオリティ値Ｐ１を発行する。診断要求Ｃとパラメータであるプライオリティ値Ｐ１は、入力部３１から診断用プロセス２０に対して信号経路４０を介し入力される。診断要求Ｃは、診断用プロセス２０を現行のスリープ状態らラン状態に遷移させる作用をもつ。

パラメータであるプライオリティ値Ｐ１は、優先度制御手段２１に入力され所定のプライオリティ値を設定する。例えば、診断用プロセス２０のプライオリティを、現状の最下位クラスからプロセス２及びプロセス３と同等クラスに設定する。

同時にスケジューラ５１では、図示しない内部の管理テーブルにプロセス２及びプロセス３と同一プライオリティクラスとして新たな診断用プロセス２０を追加する。

この結果、診断用プロセス２０は、プロセス２及びプロセス３と同等条件でＣＰＵ処理時間であるスレッドクオンタムを取得する資格を得る。

診断用プロセス２０は、実行中のスレッド処理を通じて通常運端中のデバイスドライバ４やハードウェアアクセスインタフェース６等のソフトウェア共有資源を活用して、図示していない制御対象システムに属する所定ハードウェアの診断を実施する。

また、実施例１に示した構成要素に対応するコントローラのハードウェアや、通信経路４０、入力部３１または出力部４１などのハードウェア診断を実行しても差し支えない。

診断用プロセス２０は、実行したハードウェア診断結果または診断経過の状況を、結果出力Ｒを介し出力部３２へ提示する。所定のクオンタムを満了しハードウェア診断を終了した診断用プロセス２０は、自動的に自らのプライオリティを最下位クラスに設定し直してスリープ状態に復帰する。

この様に、コントローラにおいて最下位プライオリティにしてスリープ状態で潜伏させていた診断用プロセス２０を、緊急度やＣＰＵ負荷状況に応じ適宜最適なプライオリティを付与してからラン状態にする。これにより、診断用プロセス２０はＣＰＵ実行時間すなわちスレッドクオンタムを確実に確保することができる。

ＣＰＵ負荷状況については、実施例１では信号経路４０を介した出力部３２により現在ラン状態にある、全プロセスについて一覧表示して出力することで取得する。ラン中の全プロセスの一覧情報は、ＯＳに備えつきの管理用コマンドなどを活用してもよい。

現行のＣＰＵ負荷状況に合わせて、診断用プロセス２０に付与するプライオリティクラスを適切に選択することにより、診断用プロセス２０に対してクオンタム割り当てが発生するまでのレスポンス時間を調整することができる。

さらに入力部３１を介して行う診断要求Ｃの発行間隔を適切に調整することにより、制御対象システムの通常運転を妨げること無しに定期的な間隔で実行を開始するハードウェア診断プロセスのクオンタム確保が可能となる。診断プロセス２０のクオンタム割り当てが無い間は、診断用プロセス２０を最下位プライオリティクラスに固定してスリープ状態としておく。

もちろん実行するハードウェア診断が、一回分のスレッドクオンタムで終了し切れない場合、診断要求Ｃの発行時点で付与したプライオリティを保持させたまま、診断プロセス２０のクオンタム割り当てが無い間を、ウェイト状態で待機させても良い。

診断用プロセス２０は、リアルタイムＯＳ５によりプロセス１、２、３など他の運転用プロセスや、他の診断用プロセス（図示しない）との間で、グローバル変数を介した引数の送受やプロセス間通信ができる。

このため、他の運転用プロセスが自身のスレッドクオンタム中に現場の装置や設備から取得した、最新の物理量やステイタス情報を引数としてコピーし、ハードウェア診断用のデータとしても二次活用できる。

これにより、デバイスドライバ４やハードウェアアクセスインタフェース６などの共有資源に対して、診断プロセス２０の占有時間を短縮するので効率の良い診断を実行できる。

また逆に診断用プロセス２０が得た診断結果について、結果出力Ｒを介した出力部３２への出力データとして用いる以外に、実行中の他プロセスにおいて運転中の装置や設備の設定パラメータやモード変更など、通常運転に係わるフィードバック制御にも反映することができる。

この様に、運転用プロセスと診断用プロセスとを同時に並列して稼動させる結果、通常の運転環境下でもハードウェア診断が可能となる。稼動中のシステムで生じた軽微な不具合や不明箇所は、運転を停止させることなく早期の段階でハードウェア障害の有無について切り分け判断することができる。

さらには運転用プロセスと診断用プロセスとの共存により、双方のプロセスがスレッドクオンタム期間中に取得したデータは、ＯＳに備付けのグローバル変数などのプロセス間通信手段を媒介すれば互いに共有させることができる。

これにより運転と診断の両プロセスは、互いの専門性を生かした情報を相互に補完し合える環境が実現し、コントローラ内部リソースやＣＰＵ負荷を軽減させると共に、作業効率を改善する効果をもたらす。

以上の様に図１の実施例１によれば、管理対象システムの運転を停止させること無しにクオンタムを確実に確保して、定時または臨時のハードウェア診断プログラムを実行するコントローラが提供できる。

本発明の実施例２は、図２の構成ブロックに示している。

実施例２では診断実行手段３０として、優先度制御手段２１の他に動作制御時間制御部２２を備えた診断プロセス２０を使用している。また、入力部３１は信号経路４０を介して優先度制御手段２１及び動作時間制御手段２２に接続している。その他の構成は、図１に示した実施例１と同一である。

次に図２の実施例２の作用について説明する。図１の実施例１に示した同一記号の構成要素は同一作用をもつことから作用の詳細説明を省略する。

実施例２の診断プロセス２０が備える動作時間制御手段２２は、診断用プロセス２０の指定スレッドクオンタム値を設定する作用を持つ。プライオリティを設定する優先度制御手段２１と同様に、診断用プログラム２０のスレッド実行に必要なパラメータをスケジューラ５１に提供する作用をもつ。

制御対象システムの通常運転中に、ハードウェア診断の必要が生じた場合、入力部３１では診断要求Ｃとそのパラメータであるプライオリティ値Ｐ１及びスレッドクオンタム値Ｐ２を発行する。

パラメータの１つであるプライオリティ値Ｐ１は、優先度制御手段２１に入力され所定のプライオリティ値を設定する。また他のパラメータであるスレッドクオンタム値Ｐ２は動作時間制御手段２２へ入力して、診断用プロセス２０のクオンタム値を設定している。

この結果、スケジューラ５１では、内部の管理テーブルに指定されたプライオリティに加え、指定されたクオンタム値を含めた状態で診断用プロセス２０をスケジューリングできる。

実施例２のスケジューラ５１では、診断用プロセス２０についてプライオリティ制御以外にもスレッドクオンタム制御を併せて駆使できることから、他の運転用プロセス群に対する影響を最小限とするスケジューリング構成が実現できる。

このため、多種多様なハードウェア診断プログラムを予め複数個スリープさせておき、状況や必要に応じてパラメータ値を調整した診断要求を適宜発行することで、通常運転を停止させること無く複数の診断用プログラムの並列実行を最適化できる。

図３は、実施例２の信号経路４０に通信用インタフェースとして広域ネットワーク網を用いた場合の構成例を示している。図３の入力部３１及び出力部３２は、制御用端末装置５０として構成している。制御用端末装置５０には、専用に設計された装置以外にも例えば市販のコンピュータやワークステーション、モバイル端末装置などを流用しても良い。

入力部３１、出力部３２及び通信経路４０の各作用は図２の構成と同等であるが、図３の場合は入力部３１と出力部３２を遠隔地に設置できる効果をもつ。

次に実施例２の作用について、図４Ａおよび図４Ｂを用いて更に説明する。
図４Ａは、診断用プロセス２０が初期設定のスリープ状態のまま待機中のスケジューリング状況例である。実施例２のコントローラのリアルタイムＯＳ５における、プロセス別の実行時間、具体的にはスレッドクオンタムの配分状況を示している。

横軸は経過時間Ｔ、縦軸はプライオリティクラスであり例として高位、中位及び低位の３クラスを設定している。

横軸上で消費される規格化された、単位時間長はクオンタムに対応している。プロセス０とプロセス１は、高位クラスのプライオリティに属している。ＯＳ管理用のプロセス０はスレッドクオンタム数を１単位、運転用プロセス１は２クオンタム単位数で実行している。

運転用であるプロセス２とプロセス３は、中位クラスのプライオリティに属して、プロセス２はスレッドクオンタムを３単位、プロセス３はスレッドクオンタムを４単位で実行している。

診断用プロセス２０、２０１、２０２は低位クラスのプライオリティに属し、それぞれ初期値として３単位のスレッドクオンタムを割り当てている。

図４Ａと図４Ｂのスケジューリングは、説明が単純であることからコオペラティブ方式を採用し、同一クラスのプライオリティのスレッド同士ではラウンドロビン・スケジュールで示している。

図４Ａでは診断要求Ｃが発行されず、診断用プロセス２０、２０１、２０２はすべてスリープ状態に止まり、最低のプライオリティを維持することから、診断用プロセスのスレッドは実行されることは無い。また各診断用プロセスのスレッドクオンタムのデフォルト値は便宜上、３単位数に設定している。

一方、図４Ｂでは、診断用プロセス２０に対する診断要求Ｃが発行されている。このため最低クラスのプライオリティを維持してスリープ状態で待機していた診断プロセス２０は、図４Ｂの例では中位クラスのプライオリティで、スレッドクオンタムを４単位に設定されてラン状態に移行する。

このとき発行した診断要求Ｃは、第一のパラメータＰ１がプライオリティを中位クラスに指定し、第二のパラメータＰ２がスレッドクオンタムを４単位に指定している。

ラン中の診断用プロセス２０は、同じ中位クラスのプライオリティに属する、運転用のプロセス２及びプロセス３と同等に扱われてラウンドロビン・スケジュールで実行処理される。

診断要求Ｃを定期的に発行し、その都度診断用プロセス２０のプライオリティを中位クラスまで上げることによって確実かつ定期的なスレッドクオンタムを確保できる。

図４Ｂの例では一回のスレッドクオンタムを終了する度に、所定のハードウェア診断に係わる結果出力Ｒを得ているので診断用プロセス２０は、初期状態である低位プライオリティクラスに復帰してからスリープ状態へ戻っている。

もちろん、ハードウェア診断のプロセス実行に時間を要する場合は、復帰せずこのまま次回のスレッドクオンタムまでウェイト状態を維持しても良い。図４Ｂにおいては、診断要求Ｃを受けてからプロセス２０が実際に実行されるまでのウェイト状態は、破線部で示してある。

以上説明した様に、本発明によれば制御対象システムの通常運転を停止すること無く、ハードウェア診断プロセスをシステム稼動状況に合わせた任意の優先順位、かつ最適クオンタムで実行させる手段を備えたコントローラを提供できる。

さらに、信号経路４０を介在させて入力部３１と出力部３２とを接続したことで、コントローラに備付けのＨＭＩ手段の他、入出力機能を備えた遠隔地にあるコンピュータ端末等を用い通信用インタフェースを介した診断要求を発行し、コントローラで起動した所定のハードウェア診断プロセスについて診断結果を取得できる。

本発明の実施例１を示す構成ブロック図である。本発明の実施例２を示す構成ブロック図である。本発明における信号経路を通信インタフェースとした場合の構成例をブロック図である。本発明の実施例２のプロセスのスケジューリング動作例を示すブロック図である。診断用プロセスの実施形態の例として従来例１を示す構成ブロック図である。診断用プロセスの実施形態の例として従来例２を示す構成ブロック図である。診断用プロセスの実施形態の例として従来例３を示す構成ブロック図である。

符号の説明

１、２、３プロセス
４デバイスドライバインタフェース
５リアルタイムＯＳ
６ハードウェアアクセスインタフェース
７診断用プログラム
２０、２００、２０１診断用プロセス
２１優先度制御手段
２２動作時間制御手段
３０診断実行手段
３１入力部
３２出力部
４０信号経路
５１スケジューラ

Claims

制御対象のシステムで用いるＯＳを備えたコントローラにおいて、
前記制御対象のシステムを通常運転する際に実行される運転用プロセスと並列して診断用プロセスを実行する診断実行手段と、
前記診断用プロセスの実行優先順位を指定する優先度制御手段と、
を備えたことを特徴とするコントローラ。
前記診断用プロセスは、所定のハードウェア診断を実行することを特徴とする請求項１に記載のコントローラ。
前記診断用プロセスに所定の優先順位を設定する入力部を備えたことを特徴とする請求項１または２に記載のコントローラ。
前記診断用プロセスの診断結果を出力する出力部を備えたことを特徴とする請求項１から３までの何れかに記載のコントローラ。
前記優先度制御手段は、前記診断用プロセスが所定の診断を終了すると前記優先順位を最低優先順位に設定することを特徴とする請求項１から４までの何れかに記載のコントローラ。
前記診断用プロセスは、前記ＯＳ内で用いている所定のグローバル変数を介して前記運転用プロセスから所定のパラメータ取得を行うことを特徴とする請求項１から５までの何れかに記載のコントローラ。
前記入力部は、通信用インタフェースと接続することを特徴とする請求項３に記載のコントローラ。
前記出力部は、通信用インタフェースと接続することを特徴とする請求項４に記載のコントローラ。
前記出力部は、前記ＯＳで現在実行中の前記運転用プロセス及び前記診断用プロセスについてその数と各々の実行状況とを出力することを特徴とする請求項４に記載のコントローラ。
制御対象のシステムで用いるＯＳを備えたコントローラにおいて、
前記制御対象のシステムを通常運転する際に実行される運転用プロセスと並列して診断用プロセスを実行する診断実行手段と、
前記診断用プロセスの実行優先順位を指定する優先度制御手段と、
前記ＯＳの許容占有時間長を指定する動作時間制御手段と、
を備えたことを特徴とするコントローラ。
前記診断用プロセスは、所定のハードウェア診断を実行することを特徴とする請求項１０に記載のコントローラ。
前記診断用プロセスに所定の優先順位と所定の許容占有時間長とを設定する入力部を備えたことを特徴とする請求項１０または１１に記載のコントローラ。
前記診断用プロセスの診断結果を出力する出力部を備えたことを特徴とする請求項１０から１２までの何れかに記載のコントローラ。
前記優先度制御手段は、前記診断用プロセスが所定の診断を終了すると前記優先順位を最低順位に設定することを特徴とする請求項１０から１３の何れかに記載のプログラムコントローラ。
前記診断用プロセスは、前記ＯＳ内で用いている所定のグローバル変数を介して前記運転用プロセスから所定のパラメータ取得を行うことを特徴とする請求項１０から１４の何れかに記載のコントローラ。
前記入力部は、通信用インタフェースと接続することを特徴とする請求項１２に記載のコントローラ。
前記出力部は、通信用インタフェースと接続することを特徴とする請求項１３に記載のコントローラ。
前記出力部は、前記リアルタイムＯＳで現在実行中の前記運転用プロセス及び前記診断用プロセスについてその数と各々の実行状況とを出力することを特徴とする請求項１３に記載のコントローラ。