(57)【要約】【課題】プロセスの静的優先度を設定しつつ、プロセスの暴走にも対処できるプラント監視制御システムを得る。【解決手段】複数のプロセス２０、３０が静的優先度および動的優先度に応じてＯＳカーネル１０上で動作するＨＭＩ装置にあって、プロセス３０に監視スレッド３１を設け、監視スレッド３１により、プロセス３０のＣＰＵ負荷を算出するとともに、この算出したＣＰＵ負荷の状態に応じて、ＯＳカーネル１０のシステムコールＩ／Ｆ１１を介して、プロセス３０の静的優先度の設定および解除を動的に行うようにした。【選択図】図２
2016170459.tif 000002
【特許請求の範囲】
【請求項１】
複数のプロセスが優先度に応じてＯＳカーネル上で動作するＨＭＩ装置を有するプラント監視制御システムであって、
上記ＯＳカーネルは、上記プロセスの静的優先度の設定および解除を行うためのシステムコールインタフェースを有し、
上記プロセスは、当該プロセスのＣＰＵ負荷状態を監視し、上記ＣＰＵ負荷状態に応じて、上記システムコールインタフェースを介して、当該プロセスの静的優先度の設定および解除を行う監視スレッドを有することを特徴とするプラント監視制御システム。
【請求項２】
上記監視スレッドは、他のプロセスに対しても、当該他のプロセスのＣＰＵ負荷状態を監視し、当該ＣＰＵ負荷状態に応じて、当該他のプロセスの静的優先度の設定および解除を行うことを特徴とする請求項１記載のプラント監視制御システム。
【請求項３】
上記監視スレッドは、他のプロセスから静的優先度の設定または解除の要求を受け付け、この要求に応じて、当該他のプロセスの静的優先度の設定または解除を行うことを特徴とする請求項１または請求項２記載のプラント監視制御システム。
【請求項４】
上記監視スレッドは、上記静的優先度の設定を停止する機能を有することを特徴とする請求項１から請求項３のいずれか一項記載のプラント監視制御システム。
【請求項５】
上記監視スレッドは、上記静的優先度を段階的に設定することを特徴とする請求項１から請求項４のいずれか一項記載のプラント監視制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、火力／原子力プラント等の止まることが許されないプラントを監視制御し、静的優先度（リアルタイムプロセス）の設定されるプロセスを動作させるＨＭＩ（Ｈｕｍａｎ  Ｍａｃｈｉｎｅ  Ｉｎｔｅｒｆａｃｅ）装置を有するプラント監視制御システムに関するものである。
【背景技術】
【０００２】
通常のプラント監視制御システムでは、プラント・補機に接続された分散ＰＩＯ（Ｐｒｏｃｅｓｓｏｒ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）が、プラント上のデータをアナログ／デジタル入力信号として取得し、制御装置に転送する。
制御装置は、取得したデータを用いて各種の演算処理を行うことで、プラントの監視制御を行う。さらに、制御装置は、ネットワークを通じて、ＨＭＩ装置に接続され、ユーザにより、制御装置の様々な制御データの監視を行うことができるようになっている。
【０００３】
ＨＭＩ装置の中では、トレンド表示用のデータ収集プロセスや、画面表示系のプロセスなど複数のプロセスが同時並行的に動作しており、それらのプロセスがどれくらい優先的に動作してほしいかを細かく設定する必要が生じている。例えば、トレンドのデータ収集プロセスは、トレンドデータの欠測につながるため、画面表示系のプロセスよりも優先的に動作する必要がある。
このため、現代のＯＳでは、プロセス優先度と呼ばれる仕組みが導入されており、対象としたいプロセスを、他のプロセスよりも高い優先度で優先的に動作させることが可能となっている。
【０００４】
このプロセス優先度には、静的優先度と動的優先度の２種類が存在する。ＯＳカーネル上では、優先度は１〜１３９の数字で表現され、１〜９９が静的優先度、１００〜１３９が動的優先度となり、値が小さいほど優先度が高くなる。
このとき、動的優先度は、ＯＳカーネルにより１００〜１３９の間で動的に変更されるが、静的優先度は、ユーザがシステムコールＩ／Ｆ（インタフェース）を介して設定した値に固定される。
また、動的優先度と静的優先度を比較した場合は、静的優先度の方が値が小さいため、静的優先度の方がより優先されることになる。
さらに、静的優先度は、スケジューラとして、ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ  Ｆｉｒｓｔ−Ｏｕｔ）とＲＲ（ラウンドロビン）の２種類を選択することができ、ＦＩＦＯは一度ＣＰＵをつかむとＣＰＵを離すまでずっと使い続けるのに対して、ＲＲは同じ優先度のプロセスがあると、ラウンドロビンでＣＰＵの割り当てが行われる。
しかし、どちらのスケジューラを選択したとしても、自身よりも優先度の低いプロセスにはＣＰＵが割り当てられないため、プロセスが暴走した場合には、最悪ＯＳがフリーズしたような状態となってしまう恐れがある。
【０００５】
実際のＨＭＩ装置上では、複数のプロセスが様々な優先度で同時並行的に動作しており、システムに重要なプロセスであっても、低優先度のプロセスは、全く動作しない状況になっている。
例えば、トレンドのデータ収集プロセスは、絶対に欠測があってはならないため、静的優先度を高く設定する必要があり、そのプロセスと同時に動く必要のある画面表示系のプロセスも、それぞれ独自に定められたＨＭＩの応答性能を確保するため、ある程度の静的優先度の設定がされている。
したがって、ＨＭＩ装置上の重要プロセスは、他のプロセスがすでに静的優先度を設定している関係上、自身も静的優先度を設定せざるを得ない状況にあり、プロセスが暴走しないよう、極めて高い信頼性が必要となっている。
【０００６】
特許文献１には、プロセス内の各スレッドが自律分散的に優先度を制御する手法が記載されている。
また、特許文献２には、定義ファイルで優先度情報の設定が可能となる手法が記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−９９７０号公報（第８〜１１頁、第１図）
【特許文献２】特開２００８−２７６５６９号公報（第３〜６頁、第３図）
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従来のプラント監視制御システムにおけるＨＭＩ装置は、その装置上で静的優先度を設定したプロセスが無数に動作しており、そのうちのどれかのプロセスで暴走が発生した場合は、ＨＭＩ装置内のＣＰＵが、そのプロセスに張り付いたような（フリーズした）状態となり、システムに重大な影響を恐れる必要があった。
また、特許文献１、２に示したものでは、あくまでもシステムの負荷最適化が目的であり、プロセス自身が暴走してしまった場合のことは考慮されていなかった。
【０００９】
この発明は、上述のような課題を解決するためになされたものであり、プロセスの静的優先度を設定しつつ、プロセスの暴走にも対処できるプラント監視制御システムを得ることを目的とする。
【課題を解決するための手段】
【００１０】
この発明に係わるプラント監視制御システムにおいては、複数のプロセスが優先度に応じてＯＳカーネル上で動作するＨＭＩ装置を有するプラント監視制御システムであって、ＯＳカーネルは、プロセスの静的優先度の設定および解除を行うためのシステムコールインタフェースを有し、プロセスは、当該プロセスのＣＰＵ負荷状態を監視し、ＣＰＵ負荷状態に応じて、システムコールインタフェースを介して、当該プロセスの静的優先度の設定および解除を行う監視スレッドを有するものである。
【発明の効果】
【００１１】
この発明によれば、複数のプロセスが優先度に応じてＯＳカーネル上で動作するＨＭＩ装置を有するプラント監視制御システムであって、ＯＳカーネルは、プロセスの静的優先度の設定および解除を行うためのシステムコールインタフェースを有し、プロセスは、当該プロセスのＣＰＵ負荷状態を監視し、ＣＰＵ負荷状態に応じて、システムコールインタフェースを介して、当該プロセスの静的優先度の設定および解除を行う監視スレッドを有するので、プロセスの静的優先度を設定しつつ、プロセスの暴走にも対処することができる。
【図面の簡単な説明】
【００１２】
【図１】この発明の実施の形態１によるプラント監視制御システムを示すシステム構成図である。
【図２】この発明の実施の形態１によるプラント監視制御システムのＨＭＩ装置内でのプロセスの動作を示すイメージ図である。
【図３】この発明の実施の形態１によるプラント監視制御システムのプロセス起動時間ごとのＣＰＵ負荷と静的優先度の関係を示す図である。
【図４】この発明の実施の形態１によるプラント監視制御システムの監視スレッドの手順を示すフローチャートである。
【図５】この発明の実施の形態２によるプラント監視制御システムのＨＭＩ装置内でのプロセスの動作を示すイメージ図である。
【図６】この発明の実施の形態２によるプラント監視制御システムの監視スレッドの手順を示すフローチャートである。
【図７】この発明の実施の形態３によるプラント監視制御システムのＨＭＩ装置内でのプロセスの動作を示すイメージ図である。
【図８】この発明の実施の形態３によるプラント監視制御システムの監視スレッドの手順を示すフローチャートである。
【図９】この発明の実施の形態４によるプラント監視制御システムの監視スレッドの手順を示すフローチャートである。
【図１０】この発明の実施の形態５によるプラント監視制御システムのプロセス起動時間ごとのＣＰＵ負荷と静的優先度の関係を示す図である。
【図１１】この発明の実施の形態５によるプラント監視制御システムの監視スレッドの手順を示すフローチャートである。
【図１２】この発明の実施の形態５によるプラント監視制御システムのＣＰＵ負荷と段階的な静的優先度の関係を示す図である。
【発明を実施するための形態】
【００１３】
実施の形態１．
以下、この発明の実施の形態１を図に基づいて説明する。
図１は、この発明の実施の形態１によるプラント監視制御システムを示すシステム構成図である。
図１において、プラント監視制御システムは、プラント・補機６に接続された分散ＰＩＯ５が、プラント上のデータ（圧力／温度／流量や、ファン／ポンプなどの起動／停止状態、オン／オフ弁の開／閉状態など）をアナログ／デジタル入力信号として取得し、制御装置１に転送する。
制御装置１は、取得したデータを用いて各種の演算処理を行うことで、プラントの監視制御を行う。制御装置１は、ネットワーク４を通じて、ＨＭＩ装置２と接続されており、ユーザ３は、ＨＭＩ装置２から、制御装置１の様々な制御データの監視を行うことができるようになっている。
【００１４】
図２は、この発明の実施の形態１によるプラント監視制御システムのＨＭＩ装置内でのプロセスの動作を示すイメージ図である。
図２において、ＨＭＩ装置では、ＯＳカーネル１０上で、複数のプロセス２０、３０が様々な優先度で同時並行的に動作している。各プロセス２０、３０は、それぞれ処理の実行単位のスレッド２１をもっている。ＯＳカーネル１０は、システムコールＩ／Ｆ１１（システムコールインタフェース）をもち、このシステムコールＩ／Ｆ１１を介して、静的優先度の設定が行われる。
プロセス３０は、監視スレッド３１をもち、監視スレッド３１は、ＣＰＵ負荷の算出と、システムコールＩ／Ｆ１１を介して、静的優先度の設定および解除を動的に制御する。
なお、ＯＳカーネル１０上では、優先度は１〜１３９の数字で表現され、１〜９９が静的優先度、１００〜１３９が動的優先度となり、値が小さいほど優先度が高くなる。
この発明は、従来、ユーザにより設定され、固定されて運用されていた静的優先度の動的な設定および解除についてのものである。
【００１５】
図３は、この発明の実施の形態１によるプラント監視制御システムのプロセス起動時間ごとのＣＰＵ負荷と静的優先度の関係を示す図である。
図３において、横軸にプロセス起動時間、縦軸にＣＰＵ負荷状態を取ったときの実線のグラフは、ＣＰＵ負荷を示す。また、横軸にプロセス起動時間を取り、縦軸に静的優先度の設定／解除を取ったときの点線のグラフは、設定の位置（高い位置）で優先度の設定状態、解除の位置（低い位置）で静的優先度の解除状態を示している。
【００１６】
次に、動作について説明する。
図２に示すように、本発明に係わるプロセス３０は、所定の動作を行うスレッド２１とは別に、監視スレッド３１を設け、この監視スレッド３１が、動的に静的優先度の設定／解除を制御するようになっている。
監視スレッド３１は、図３に示すように、定期的に自身のプロセス３０のＣＰＵ負荷状態を計測し、負荷が高まったと判断した場合は、静的優先度の解除を行うとともに、負荷が収まったと判断した場合は、再び静的優先度の設定を行う。
このようにすることによって、プロセス３０が暴走してしまった場合においても、監視スレッド３１がＣＰＵ負荷の高まりを検知し、自動的に静的優先度の解除を行うため、ＨＭＩ装置２自体がフリーズしてしまうのを防止することができる。
【００１７】
次に、図４を用いて、監視スレッド３１の動作手順について説明する。
監視スレッド３１は、そのプロセス３０が起動すると同時にあらかじめ起動しておき、決められた一定時間おき（例えば、１秒間隔等）に、以下の処理を実施するために待機する（Ｓ１０００）。
最初に、監視スレッド３１は、ＯＳカーネル１０上のシステムコールＩ／Ｆ１１を用いて、自身のプロセス３０のＣＰＵ負荷を算出する（Ｓ１００１）。このＣＰＵ負荷とは、ＣＰＵ使用率のことであり、ある単位時間のうち、そのプロセス３０が何らかの処理を実行している時間の割合を示す。このＣＰＵ負荷が０％の場合は、そのプロセス３０は何も実行されない待機状態のままであったということであり、１００％の場合は、ＣＰＵを占有して、その時間ずっと何らかの処理を行っていたことになる。
【００１８】
続いて、事前に静的優先度が設定されているかどうかでその後の処理が異なるため、現時点で静的優先度が設定されているかどうかの場合分けを行う（Ｓ１００２）。
まず、静的優先度が設定されていない場合は、Ｓ１００１で算出したＣＰＵ負荷を元に、自身のプロセス３０のＣＰＵ負荷が閾値（例えば、５％）よりも低いかどうかの判定を行う（Ｓ１００３）。そして、ＣＰＵ負荷が閾値よりも低い場合、そのプロセス３０は、安定状態に入ったということで、監視スレッド３１は、ＯＳカーネル１０上のシステムコールＩ／Ｆ１１を用いて、自身のプロセス３０の静的優先度の設定を行う（Ｓ１００４）。
なお、この閾値は、システムで固定の値を持たせても構わないし、アルゴリズムによって動的に閾値を変更するようにしても構わない。
【００１９】
一方、Ｓ１００２で、事前に静的優先度が設定されている場合は、Ｓ１００１で算出したＣＰＵ負荷を元に、自身のプロセス３０のＣＰＵ負荷が閾値（例えば、５０％）よりも高いかどうかの判定を行う（Ｓ１００５）。そして、ＣＰＵ負荷が閾値よりも高い場合、そのプロセス３０は、高負荷（暴走）状態に陥ったということで、監視スレッド３１は、ＯＳカーネル１０上のシステムコールＩ／Ｆ１１を用いて、自身のプロセス３０の静的優先度の解除を行う（Ｓ１００６）。
Ｓ１００１〜Ｓ１００６の処理が完了した場合は、監視スレッド３１の処理は、最初の待機状態に戻り、一定時間後に再び処理を開始する（Ｓ１０００）。
以上の処理を、そのプロセス３０が起動している間、常に実行し続ける。
【００２０】
実施の形態１によれば、このようにすることによって、プロセス３０の静的優先度を設定しつつ、そのプロセス３０が暴走した場合は、自動的にそのプロセス３０の静的優先度を解除することで、ＨＭＩ装置２のフリーズを防止し、システムの最低限の安定性を確保することができる。
また、いわゆるロードバランサの装置のように全体を監視し、負荷を調整する代表者（プロセス）を持つのではなく、自身のプロセス２０で自身を監視することによって、簡易に実現できることも利点の一つである。
【００２１】
実施の形態２．
図５は、この発明の実施の形態２によるプラント監視制御システムのＨＭＩ装置内でのプロセスの動作を示すイメージ図である。
図５において、１０、１１、２０、２１、３０、３１は図２におけるものと同一のものである。図５は、監視スレッド３１による監視対象が増えたときのものである。
【００２２】
実施の形態１では、自身のプロセス３０のみを監視対象としていたが、自身以外のプロセス２０も監視した方が良い場合がある。
例えば、あるプロセス３０が、一般的なデータベースソフトウェアを使用している場合は、自身とデータベースの両方のプロセス２０、３０について監視を行うことが望ましい。
そこで、実施の形態２は、実施の形態１において、自身のプロセス３０以外のプロセス２０についても、静的優先度の設定を行い、監視対象とした場合についてのものである。
【００２３】
次に、動作について説明する。
この実施の形態２では、図５に示すように、監視スレッド３１が、他のプロセス２０から監視対象への追加／削除の要求を受け付けるとともに、監視スレッド３１にて、監視対象に追加した他のプロセス２０のＣＰＵ負荷の算出、静的優先の設定／解除も行うようになっている。
【００２４】
次に、図６を用いて、実施の形態２の監視スレッド３１の動作手順について説明する。
監視スレッド３１は、Ｓ１０００で一旦待機した後、別のプロセス２０から、プロセス監視の追加／削除要求が届いているかどうかを確認する（Ｓ１０１０）。この要求は、プロセス間通信を想定しているが、特に要求伝達の手段は問わないものとする。
別のプロセス２０から追加要求が届いている場合は、その対象となるプロセス２０を監視対象に追加する。逆に、削除要求が届いている場合は、そのプロセス２０を監視対象から削除する（Ｓ１０１１）。
そして、監視対象としてリスト化された全てのプロセス２０、３０を対象に、実施の形態１と同様に、ＣＰＵ負荷の算出、ＣＰＵ負荷と閾値の比較、静的優先度の設定／解除を行う（Ｓ１０１２〜Ｓ１０１９）。
これらの処理は、実施の形態１では、自身のプロセス３０だけが監視対象であったが、実施の形態２では、この監視対象が、他のプロセス２０も含む複数のプロセス２０、３０である点が異なる。
【００２５】
実施の形態２によれば、このようにすることによって、監視スレッド３１にて自身のプロセス３０を含む複数のプロセス２０、３０の監視ができるようになり、監視スレッド３１を追加することができない一般的なプロセス２０についても、静的優先度の設定と暴走の監視を行うことができるようになる。
【００２６】
実施の形態３．
図７は、この発明の実施の形態３によるプラント監視制御システムのＨＭＩ装置内でのプロセスの動作を示すイメージ図である。
図７において、１０、１１、２０、２１、３０、３１は図２におけるものと同一のものである。図７では、監視スレッド３１が、別のスレッド２１または別のプロセス２０から直接、静的優先度の設定／解除要求を受け付ける機能を有し、受け付けた場合に、当該プロセスの静的優先度を設定または解除する。
【００２７】
実施の形態１〜実施の形態２においては、プロセス２０、３０の暴走をＣＰＵ負荷の上昇という形で検出を試みていたが、場合によっては、他のスレッド２１やプロセス２０から通知をしてもらった方が良い場合がある。
そこで、実施の形態３では、監視スレッド３１が、別のスレッド２１または別のプロセス２０から直接、静的優先度の設定／解除要求を受け付ける機能を有する場合についてのものである。
【００２８】
次に、動作について説明する。
実施の形態３では、図７に示すように、実施の形態１〜実施の形態２と比べて、別のスレッド２１または別のプロセス２０からの静的優先度の設定／解除要求が届いているかどうかの確認を行う処理が追加されている。
【００２９】
次に、図８を用いて、実施の形態３の監視スレッド３１の動作手順について説明する。
図８では、Ｓ１０１４のＮｏの後にＳ１０２０が追加され、Ｓ１０１４のＹｅｓの後にＳ１０２１が追加されている。
なお、Ｓ１０００、Ｓ１０１０〜Ｓ１０１９の各処理は、図６におけるものと同一の処理である。
【００３０】
監視スレッド３１は、Ｓ１０１４で、静的優先度が設定されている場合は、別のスレッド２１または別のプロセス２０から、静的優先度の設定要求が届いているかどうかを確認する（Ｓ１０２０）。この要求は、スレッド／プロセス間通信を想定しているが、特に要求伝達の手段は問わないものとする。
そして、要求が届いている場合は、ＣＰＵ負荷の状態に係わらず、強制的に対象となるプロセス２０、３０（要求したプロセス）に対して静的優先度の設定を行う（Ｓ１０１６）。
一方、Ｓ１０１４で、静的優先度が設定されていない場合は、別のスレッド２１または別のプロセス２０から、静的優先度の解除要求が届いているかどうかを確認する（Ｓ１０２１）。この要求は、スレッド／プロセス間通信を想定しているが、特に要求伝達の手段は問わないものとする。
そして、要求が届いている場合は、ＣＰＵ負荷の状態にかかわらず、強制的に対象となるプロセス２０、３０（要求したプロセス）に対して静的優先度の解除を行う（Ｓ１０１８）。
【００３１】
実施の形態３によれば、このようにすることによって、任意のタイミングで、静的優先度の設定／解除を行うことができ、あらかじめ重たい処理を行うことが分かっていた場合には、事前に静的優先度の設定を解除したり、その処理が終わったタイミングで、再度、静的優先度の設定を行ったりすることができる。
【００３２】
実施の形態４．
実施の形態１〜実施の形態３においては、プロセス２０、３０が小規模な暴走を繰り返した場合に、無意味に静的優先度の設定／解除を繰り返してしまう恐れがある。
そこで、実施の形態４では、静的優先度の設定停止の状態を追加する。これは、事前に決められた設定停止条件を満たした場合に停止状態となり、その状態となった場合は、静的優先度の設定を行わない場合についてのものである。
具体的には、監視スレッド３１に、各プロセス２０、３０に対して、設定停止条件を満たしている場合に静的優先度の設定を停止する機能を追加する。
【００３３】
次に、動作について説明する。
実施の形態４では、実施の形態１〜実施の形態３と比べて、設定停止の状態になっていない場合にのみ静的優先度の設定を行ったり、静的優先度の解除を行った後に設定停止の条件を満たしているかどうかの確認を行ったりする処理が追加されている。
【００３４】
次に、図９を用いて、実施の形態４の監視スレッド３１の動作手順について説明する。
図９では、Ｓ１０１４でＮｏの場合にＳ１０３０の処理が追加され、またＳ１０１８の処理の次にＳ１０３１とＳ１０３２の処理が追加されている。
なお、Ｓ１０００、Ｓ１０１０〜Ｓ１０２１の各処理は、図８における処理と同じものである。
【００３５】
監視スレッド３１は、Ｓ１０１８の処理で、対象となるプロセス２０、３０に対して静的優先度の解除を行った後、事前に決められた設定停止条件を満たしているかどうかの確認を行う（Ｓ１０３１）。この条件は、静的優先度の解除が、Ｘ時間の間にＹ回発生した場合など、自由に調整できるものとする。
ここで、設定停止条件を満たしている場合は、対象となるプロセス２０、３０を設定停止の状態にする（Ｓ１０３２）。なお、対象となるプロセス２０、３０を設定停止の状態にするときには、合わせてエラーログの出力等、ユーザ３にその旨を通知することが望ましい（その後、通知を受けたユーザ３自身がその状態を解除できるように）。
【００３６】
そして、静的優先度の設定を行う直前に、すなわちＳ１０２０の処理の直前に、そのプロセス２０、３０が設定停止の状態になっていないかどうかを確認する処理（Ｓ１０３０）を追加し、設定停止の状態になっていない場合にだけ、Ｓ１０２０に進んで、静的優先度の設定を行う（Ｓ１０１６）。
【００３７】
実施の形態４によれば、このようにすることによって、不要な静的優先度の設定を行うことを防止でき、ＨＭＩ装置２にかかる負荷を低減することができる。
【００３８】
実施の形態５．
図１０は、この発明の実施の形態５によるプラント監視制御システムのプロセス起動時間ごとのＣＰＵ負荷と静的優先度の関係を示す図である。
図１０において、横軸にプロセス起動時間、縦軸にＣＰＵ負荷状態を取ったときの実線のグラフは、ＣＰＵ負荷を示す。また、横軸にプロセス起動時間を取り、縦軸に静的優先度の高／低を取ったときの点線のグラフは、高の位置で優先度の設定状態、低の位置で静的優先度の解除状態となるように段階的に変化する静的優先度を示している。
【００３９】
図１２は、この発明の実施の形態５によるプラント監視制御システムのＣＰＵ負荷と段階的な静的優先度の関係を示す図である。
図１２において、縦軸にＣＰＵ負荷状態を取り、横軸に静的優先度を取った場合、ＣＰＵ負荷状態が低くなるにしたがって、段階的に高くなるように変化する静的優先度を実線のグラフで示している。
【００４０】
実施の形態１〜実施の形態４においては、静的優先度を設定／解除の二値だけで表現していたが、ＯＳカーネル１０上の静的優先度自体は、１〜９９の範囲で細かく値を設定できる仕組みとなっている。
そこで、実施の形態５では、静的優先度の値を段階的に設定することで、ＨＭＩ装置２内の静的優先度をきめ細かく設定する場合についてのものである。
【００４１】
次に、動作について説明する。
実施の形態５では、図１０のプロセス起動時間ごとのＣＰＵ負荷と静的優先度の関係を示すグラフのように、静的優先度の値が段階的に変更されている。
次に、図１１を用いて、実施の形態５の監視スレッド３１の動作手順について説明する。
図１１では、図９のＳ１０３０の後にＳ１０４０〜Ｓ１０４２が追加されている。
なお、Ｓ１０００、Ｓ１０１０〜Ｓ１０１３、Ｓ１０１９、Ｓ１０３０〜Ｓ１０３２の各処理は、図９における処理と同じものである。
【００４２】
実施の形態１〜実施の形態４では、監視スレッド３１は、別のスレッド２１または別のプロセス２０から静的優先度の設定／解除要求を受け付けるようになっていたが、実施の形態５では、静的優先度の変更要求という形で要求を受け付ける。
別のスレッド２１または別のプロセス２０から、対象となるプロセスに対して、静的優先度の変更要求が届いているかどうかを判断する（Ｓ１０４０）。この変更要求では、静的優先度を１〜９９の範囲で、どの値に設定するかを指定する。
変更要求が届いていれば、対象となるプロセスに対して、指定された静的優先度に変更する（Ｓ１０４１）。
【００４３】
また、実施の形態１〜実施の形態４では、ＣＰＵ負荷の状態に合わせて、静的優先度の設定／解除を行っていたが、実施の形態５では、図１２に示すように、ＣＰＵ負荷と静的優先度の間で段階的な閾値を設けることで、段階的な静定優先度の設定を行う。
Ｓ１０４０の処理で、変更要求が届いていない場合には、対象となるプロセスのＣＰＵ負荷が段階的な閾値の範囲内に収まっているかどうかをチェックし（Ｓ１０４２）、収まっていなければ、ＣＰＵ負荷に応じて、静的優先度を変更する（Ｓ１０４１）。
Ｓ１０４１の後はＳ１０３１に進む。
【００４４】
実施の形態５によれば、このようにすることによって、ＨＭＩ装置２内の静的優先度をきめ細かく制御することができ、各プロセス２０、３０のＣＰＵ負荷状態に合わせて、柔軟にシステム全体の負荷状態を安定させることができる。
【００４５】
なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略することが可能である。
【符号の説明】
【００４６】
１  制御装置、２  ＨＭＩ装置、３  ユーザ、４  ネットワーク、５  分散ＰＩＯ、
６  プラント・補機、１０  ＯＳカーネル、１１  システムコールＩ／Ｆ、
２０  プロセス、２１ スレッド、３０  プロセス、３１  監視スレッド
【図１】
2016170459.tif 000003
【図２】
2016170459.tif 000004
【図３】
2016170459.tif 000005
【図４】
2016170459.tif 000006
【図５】
2016170459.tif 000007
【図６】
2016170459.tif 000008
【図７】
2016170459.tif 000009
【図８】
2016170459.tif 000010
【図９】
2016170459.tif 000011
【図１０】
2016170459.tif 000012
【図１１】
2016170459.tif 000013
【図１２】
2016170459.tif 000014