特開 2024-9696 制御装置、制御システム、制御方法、及び制御プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024009696

(43)【公開日】2024-01-23

(54)【発明の名称】制御装置、制御システム、制御方法、及び制御プログラム

(51)【国際特許分類】

   G05B 23/02 20060101AFI20240116BHJP

   G06F 11/16 20060101ALI20240116BHJP

   G06F 11/07 20060101ALI20240116BHJP

【ＦＩ】

G05B23/02 Z

G06F11/16 629

G06F11/07 193

【審査請求】未請求

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2022111401

(22)【出願日】2022-07-11

(71)【出願人】

【識別番号】000006507

【氏名又は名称】横河電機株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】林 俊介

(72)【発明者】

【氏名】江間 伸明

(72)【発明者】

【氏名】吉田 善貴

【テーマコード（参考）】

3C223

5B034

5B042

【Ｆターム（参考）】

3C223AA01

3C223AA02

3C223AA04

3C223AA06

3C223BA01

3C223CC01

3C223DD01

3C223EB01

3C223FF05

3C223FF33

3C223GG01

5B034AA05

5B042GA22

5B042GB06

5B042JJ29

5B042KK15

5B042KK20

(57)【要約】

【課題】アプリケーションの動作不安定を回避して、制御システムの信頼性を向上させる制御装置、制御システム、制御方法、及び制御プログラムを提供する。
【解決手段】所定演算を実行する複数のコントローラ１４１～１４３のそれぞれの演算結果を基に出力する演算結果を選択して出力する。アプリケーション管理部１７０は、コントローラ１４１～１４３のいずれか一つ又はいくつかを再構築対象として、再構築対象以外のコントローラの演算により選択処理部１６０による出力の信頼性を確保できるか否かを判定し、信頼性が確保できる場合に再構築対象のコントローラの再構築を実行する。
【選択図】図１

【特許請求の範囲】

【請求項1】

所定演算を実行する複数のアプリケーションのそれぞれの演算結果を基に出力する演算結果を選択して出力する選択処理部と、
前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算により前記選択処理部による出力の信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行するアプリケーション管理部と
を備えたことを特徴とする制御装置。

【請求項2】

前記アプリケーションは、前記所定演算としてそれぞれが同じ演算を行なう同一制御演算を実行し、
前記選択処理部は、前記演算結果に対して多数決ロジックを用いて前記出力する演算結果を選択する
ことを特徴とする請求項１に記載の制御装置。

【請求項3】

前記アプリケーション管理部は、再構築対象以外の前記アプリケーションの数が、前記選択処理部の多数決ロジックを用いた出力の信頼性を確保できる前記アプリケーションの数以上の場合に、前記信頼性を確保できると判定することを特徴とする請求項２に記載の制御装置。

【請求項4】

前記アプリケーション管理部は、前記アプリケーションの動作状態を基に、各前記アプリケーションを再構築するか否かを決定し、再構築対象以外の前記アプリケーションの演算により前記信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行することを特徴とする請求項１に記載の制御装置。

【請求項5】

前記選択処理部は、前記アプリケーションのそれぞれの演算結果を受信した結果を基に、前記アプリケーションの異常動作を検出し、
前記アプリケーション管理部は、前記選択処理部により異常動作が検出された前記アプリケーションを再構築対象として、再構築対象以外の前記アプリケーションの演算により前記信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行する
ことを特徴とする請求項１に記載の制御装置。

【請求項6】

前記アプリケーション管理部は、前記再構築対象の前記アプリケーションの、停止及び起動、又は、再インストールを行うことで、前記再構築対象の前記アプリケーションを再構築することを特徴とする請求項１に記載の制御装置。

【請求項7】

前記アプリケーション管理部は、再構築中に前記選択処理部による出力の信頼性を確保可能な数以上の前記アプリケーションが動作するように制御することを特徴とする請求項１に記載の制御装置。

【請求項8】

前記選択処理部は、新しいアプリケーションからの出力を受信した場合、前記所定演算を実行するアプリケーションの数を１つ増やし、前記アプリケーションの異常を検知した場合、前記所定演算を実行するアプリケーションの数を１つ減らして、前記選択処理部による出力の信頼性を確保できるか否かの判定を行なうことを特徴とする請求項１に記載の制御装置。

【請求項9】

前記アプリケーション管理部は、前記選択処理部による出力の信頼性を確保できるか否かの判定ロジックを、前記アプリケーションが実行する前記所定演算に求められる信頼性に応じて異ならせることを特徴とする請求項１に記載の制御装置。

【請求項10】

前記アプリケーション管理部は、前記アプリケーションの稼働時間を基に再構築対象とする前記アプリケーションを決定することを特徴とする請求項１に記載の制御装置。

【請求項11】

前記アプリケーションは、工業プロセスに対する制御値を算出するための前記所定演算を実行するアプリケーションであることを特徴とする請求項１に記載の制御装置。

【請求項12】

プラント施設に配置されたセンサからの計測結果の入力を受ける入力装置、前記プラント施設に設けられた機構を駆動する駆動装置を駆動させる出力装置及び制御装置を有する制御システムであって
前記制御装置は、
前記入力装置に入力された前記センサによる計測結果を基に所定演算を実行するアプリケーションを各々が動作させる複数の仮想マシンと、
前記アプリケーションのそれぞれの演算結果を基に出力する演算結果を選択し、選択した演算結果を前記出力装置から出力させて前記駆動装置を駆動させる選択処理部と、
前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算により前記選択処理部による出力の信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行するアプリケーション管理部と
を備えたことを特徴とする制御システム。

【請求項13】

制御装置に、
所定演算を実行する複数のアプリケーションを実行させ、
前記複数のアプリケーションそれぞれの演算結果を基に出力する演算結果を選択させて出力させ
各前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算結果により、出力する前記演算結果の出力の信頼性を確保できるか否かを判定させ、
前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行させる
ことを特徴とする制御方法。

【請求項14】

所定演算を実行する複数のアプリケーションを動作させ、
前記複数のアプリケーションそれぞれの演算結果を基に出力する演算結果を選択して出力し、
前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算結果により、出力する前記演算結果の出力の信頼性を確保できるか否かを判定し、
前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行する
処理をコンピュータに実行させることを特徴とする制御プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、制御装置、制御システム、制御方法、及び制御プログラムに関する。

【背景技術】

【0002】

石油、石油化学、化学、ガスなどを用いた各種プラントでは、バルブの開け閉めの制御や温度を一定に保つ制御といった様々な制御が制御システムにより行われる。そのため、制御システムには制御対象に応じた信頼性の確保が求められる。

【0003】

制御装置の機能は、ＣＰＵ（Central Processing Unit：中央処理装置）やメモリ等のハードウェアと、コントローラアプリケーション等のソフトウェアとから構成されるのが一般的である。コントローラアプリケーションやコントローラとは、制御アプリケーションのことであり、以後、まとめて「コントローラ」と呼ぶ。また、制御装置では、コントローラ以外のアプリケーションも動作する。以後それらを「ＡＰＰ（Application）」と呼ぶ。また、コントローラ及びＡＰＰを合わせて、アプリケーションと呼ぶ。

【0004】

制御装置では、ハードウェア上の仮想環境でアプリケーションが動作する場合もあり、その場合、ＯＳ（Operating System）や仮想ハードウェアの上で複数のＶＭ（Virtual Machine）が動作し、各ＶＭ上でアプリケーションが動作する構成などがとられる。ＶＭは、ゲストＯＳやコンテナなどと呼ばれる仮想的なＯＳ環境を提供する。

【0005】

制御装置では、ハードウェア又はソフトウェアのどちらが不具合を起こしても動作に支障をきたす。そこで、複数のコントローラで所定の演算を実行して出力し、選択処理部においてそれぞれの演算値から１つの出力値を選択することによって、信頼性を高めつつコストを抑制する制御システムが提案されている（特許文献１）。

【0006】

さらに、ソフトウェアの観点での不具合として、メモリリークと呼ばれる現象が発生する場合がある。メモリリークとは、例えばアプリケーションにプログラム的なバグがあることにより、ＯＳにメモリ領域取得要求をかけた後に、そのメモリの解放が実行されないといった現象である。メモリリークが繰り返し発生することで、ＯＳが保持するメモリ資源が枯渇し、ＯＳとそのＯＳ上で動作する全てのアプリケーションの動作が不安定になるおそれがある。

【0007】

そこで、例えば仮想環境下でアプリケーションが動作する制御システムであれば、メモリリークによる不安定状態を解消するために、ゲストＯＳ又はコンテナなどの仮想マシンとアプリケーションとの再起動が行われる。しかし、メモリリークが発生してから再起動するまでの不安定な動作は可能であれば発生させないことが好ましい。これは、アプリケーションが中途半端に不安定な動作をし続けた場合に、アプリケーション間干渉防止処理部の動作により完全に影響を抑え込めない可能性があることが理由である。そこで、メモリリークによって動作が不安定になる前に予防保全的にアプリケーションを再起動することによって、エラーの発生を防ぐことが考えられる。

【0008】

このようなメモリリーク対策の技術として、メモリリークを起こすソフトウェアの再起動を実行し、且つ、サービスを提供するプロセスを複数動作させて、一部のプロセスを再起動させた状態でもサービスの継続を可能とする技術が提案されている（特許文献２）。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開２０２０－２７４３４号公報

【特許文献2】特開２０１１－５４１１４号公報

【発明の概要】

【発明が解決しようとする課題】

【0010】

しかしながら、メモリリークの状態によっては、複数のアプリケーションを同時に再起動させる可能性がある。その場合、複数のコントローラによるそれぞれの演算値から１つの出力値を選択する技術では、再起動されるアプリケーションの数によっては適切な選択が行われなくなるおそれがある。これに対して、メモリリークによる動作不安定が同時に発生することを回避する目的でリソースの割り当てを意図的に異なる値にすることが提案されている。しかし、メモリリークの発生度合いを正確に予測することは困難であり、最適なリソース割り当てを行うことは難しい。そのため、アプリケーションの動作不安定を回避して、制御システムの信頼性を向上させることは困難である。

【0011】

また、サービスを提供するプロセスを複数動作させたうえでメモリリークを起こすソフトウェアの再起動を実行する技術では、再起動により動作するプロセスが設定した数に満たない間は、高信頼なサービス提供することが困難である。また、この技術では、キュー部によりプロセス管理が行われているが、プロセス制御システムのようなリアルタイム性が重要な処理ではキュー管理が難しく、キュー部での管理が煩雑となるおそれがある。そのため、アプリケーションの動作不安定を回避して、制御システムの信頼性を向上させることは困難である。

【0012】

開示の技術は、アプリケーションの動作不安定を回避して、制御システムの信頼性を向上させる制御装置、制御システム、制御方法、及び制御プログラムを提供することを目的とする。

【課題を解決するための手段】

【0013】

本願の開示する制御装置、制御システム、制御方法、及び制御プログラムの一つの態様において、制御装置は、以下の選択処理部及びアプリケーション管理部を有する。選択処理部は、所定演算を実行する複数のアプリケーションのそれぞれの演算結果を基に出力する演算結果を選択して出力する。アプリケーション管理部は、前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算により前記選択処理部による出力の信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行する。

【発明の効果】

【0014】

１つの側面では、本発明は、アプリケーションの動作不安定を回避して、制御システムの信頼性を向上させることができる。

【図面の簡単な説明】

【0015】

【図1】制御システムの一例を示す概略図である。

【図2】ＶＭからの再構築要求に基づく再構築処理のフローチャートである。

【図3】アプリケーション管理部による再構築の決定に基づく再構築処理のフローチャートである。

【図4】実施の形態１の変形例に係る制御システムの構成の一例を示す図である。

【図5】制御装置のハードウェア構成図である。

【発明を実施するための形態】

【0016】

以下に、本願の開示する制御装置、制御システム、制御方法、及び制御プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、同一の要素には同一の符号を付し、重複する説明は適宜省略し、各実施形態は、矛盾のない範囲内で適宜組み合わせることができる。

【0017】

［実施の形態１］
［全体構成］
図１は、制御システムの一例を示す概略図である。図１に示す制御システム１は、センサ２０及び駆動装置３０とネットワークを介して接続される。制御システム１は、例えばプラントの工業プロセス４０の制御等に使用される。本明細書において、プラントは、化学等の工業プラント、ガス田もしくは油田等の井戸元又はその周辺を管理制御するプラント、水力・火力・原子力等の発電を管理制御するプラント、太陽光や風力等の環境発電を管理制御するプラント、及び上下水やダム等を管理制御するプラント等を含む。

【0018】

センサ２０は、工業プロセス４０に設けられ、工業プロセス４０における物理量の測定を行う。センサ２０は、測定対象の物理量を測定信号として、制御システム１の入力装置１１へネットワーク経由で送信する。本明細書において、センサ２０は、例えば、圧力計、流量計、温度センサ等のセンサ機器、プラント内の異音等を収集するマイクや各機器の位置情報を出力する位置検出機器及びプラント内の状況や対象物を撮影するカメラやビデオ等の撮像機器等を含む。

【0019】

駆動装置３０は、出力装置１２から制御信号の入力を受け付けると、制御信号に応じて工業プロセス４０を駆動する。また、駆動装置３０は、流量制御弁や開閉弁等のバルブ機器、ファンやモータ等の操作端及び警報音等を発したりするスピーカ等の音響機器等を含む。

【0020】

制御システム１は、図１に示すように、制御装置１０、入力装置１１及び出力装置１２を備える。制御装置１０は、ネットワークを介して入力装置１１及び出力装置１２に接続される。

【0021】

入力装置１１は、センサ２０から測定信号の入力を受ける。そして、入力装置１１は、受信した信号を制御装置１０へ送信する。

【0022】

出力装置１２は、制御装置１０から送信された制御信号を受信する。そして、出力装置１２は、受信した制御信号を駆動装置３０へ出力する。駆動装置３０は、制御信号に応じて工業プロセス４０を操作する。ここで、入力装置１１と出力装置１２とは、ハードウェアとして一体であってもよい。

【0023】

［制御装置の構成］
制御装置１０は、入力装置１１から入力された測定信号に基づいて、所定の演算処理を行い、ネットワーク経由で演算結果に応じた制御信号を出力装置１２へ出力する。制御装置１０は、例えばコンピュータ装置により構成される。制御装置１０は、分散制御システム（Distributed Control Systems：ＤＣＳ）に含まれてもよい。制御装置１０は、入力装置１１から入力された測定信号について、所定のアルゴリズムで演算処理を行い、制御信号を生成する。制御装置１０の機能は、ＣＰＵやメモリ等のハードウェア１１０と、ＯＳ１２０、ＶＭ１３１～１３３、コントローラ１４１～１４３及びＡＰＰ１５１～１５３を含むソフトウェアから構成される。以下の説明では、ＶＭ１３１～１３３のそれぞれを区別しない場合、まとめて「ＶＭ１３０」と記載する。また、コントローラ１４１～１４３のそれぞれを区別しない場合、まとめて「コントローラ１４０」と記載する。また、ＡＰＰ１５１～１５３のそれぞれを区別しない場合、まとめて「ＡＰＰ１５０」と記載する。

【0024】

制御装置１０は、メモリリークなどのソフトウェアエラーによりコントローラ１４０の不安定動作が発生した後に対処するのではなく、ソフトウェアエラーの影響が出るよりも前の段階でコントローラ１４０の再構築処理を行うことで不安定動作の発生を回避する。このように、不安定な動作をするコントローラ１４０の影響を抑え込むよりも、計画的にコントローラ１４０を再構築させたほうが、全体としてのソフトウェアエラーによる悪影響の排除は容易である。

【0025】

制御装置１０は、コントローラ１４０の再構築の実施にあたって、選択処理部１６０において正しい出力値の選択を維持継続するため、再構築中に制御システム１の信頼性を確保可能な数以上のコントローラ１４０が動作するように制御する。また、制御装置１０は、以下に説明する簡単な仕組みによりコントローラ１４０の再起動や再インストールなどの再構築を行うことで、制御システム１の信頼性を担保する。以下の制御装置１０の詳細について説明する。

【0026】

制御装置１０は、ハードウェア１１０上でＯＳ１２０を動作させる。ＯＳ１２０は、例えば、ＶＭ１３０がゲストＯＳの場合、ホストＯＳとして動作する。ＯＳ１２０は、新たなＶＭ１３０及びコントローラ１４０の起動の指示をアプリケーション管理部１７０から受けると、ＶＭ１３０及びコントローラ１４０を新たに起動させる。

【0027】

制御装置１０は、ＯＳ１２０上で、仮想マシンである複数のＶＭ１３１～１３３を動作させる。ＶＭ１３０は、ゲストＯＳやコンテナである。ＶＭ１３１～１３３のそれぞれは、コントローラ１４１～１４３及びＡＰＰ１５１～１５３を動作させる。

【0028】

また、ＶＭ１３０は、それぞれがソフトウェアエラーの発生によりコントローラ１４０の動作に影響が出そうな時期が近いことを予測する。すなわち、仮想マシンである複数のＶＭ１３０は、所定演算を実行する個別のアプリケーションであるコントローラ１４０を各々が動作させ、且つ、動作させるコントローラ１４０における障害発生を予測する。

【0029】

例えば、ＶＭ１３０は、自己のメモリ使用量の増加を検出してメモリリークによりコントローラ１４０の動作に影響が出る時期が近いことを予測する。他にも、例えば、ソフトウェアエラーには、ＯＳ１２０へのセキュリティパッチ適用等による不安定動作も含まれる。また、ＶＭ１３０は、宇宙線などによるビットエラーといったソフトエラーの発生によりコントローラ１４０の動作に影響が出そうな時期が近いことを予測してもよい。以下の説明では、ソフトウェアエラーを例に説明するが、ＶＭ１３０は、ソフトエラーについても同様に動作可能である。以下では、ソフトウェアエラーの発生によりコントローラ１４０の動作に影響が出そうな時期が近いことの予測を、「ソフトウェアエラーの予測」と呼ぶ。

【0030】

ここで、ＶＭ１３０によるソフトウェアエラーの予測方法に特に制限はない。例えば、ＶＭ１３０は、ＣＰＵ（Central Processing Unit）の温度が閾値を超えた状態が一定時間以上になった場合に、ソフトウェアエラーを予測する。他にも、ＶＭ１３０は、制御装置１０の稼働時間、コントローラ１４０を含むアプリケーションの稼働時間又は動作ステップ数などを用いてソフトウェアエラーを予測してもよい。さらに、ＶＭ１３０は、いずれか１つを用いてソフトウェアエラーの予測を行ってもよいし、複数の方法を組み合わせて用いてソフトウェアエラーの予測を行ってもよい。

【0031】

ＶＭ１３０は、ソフトウェアエラーを予測した場合、自己が動作させるコントローラ１４０を再構築対象として、コントローラ１４０の再構築要求をアプリケーション管理部１７０に通知する。その後、ＶＭ１３０は、再構築の指示をアプリケーション管理部１７０から受けると、コントローラ１４０の再構築を実行する。

【0032】

ここで、コントローラ１４０の再構築は、コントローラ１４０の演算処理機能を停止した後に再度コントローラ１４０の演算処理機能を復旧させることができればどの様な方法であってもよい。すなわち、コントローラ１４０の再構築には、そのコントローラ１４０を動作させるＶＭ１３０の再起動、当該ＶＭ１３０を停止後に起動、及び、当該ＶＭ１３０の再インストールなどが含まれる。ＶＭ１３０を停止後に起動は、単なる再起動とは異なり、ＶＭ１３０をシャットダウンした後に起動させる処理を指す。この場合、メモリ内の情報は完全にクリアされる。また、ＶＭ１３０の再インストールの場合、ＶＭ１３０及びコントローラ１４０は初期状態からの再スタートとなる。ここで、コントローラ１４０は、「アプリケーション」の一例にあたる。すなわち、「アプリケーションの再構築」は、再起動、停止後の起動及び再インストールなどといった、アプリケーションの演算処理機能を停止した後に再度アプリケーションの演算処理機能を復旧させる動作にあたる。ＶＭ１３０の再起動によるコントローラ１４０の再起動及びＶＭ１３０の停止後に起動によるコントローラ１４０の停止後に起動のそれぞれが、「停止及び起動」の一例にあたる。

【0033】

また、制御装置１０は、ＶＭ１３０のそれぞれにおいて、コントローラ１４０及びＡＰＰ１５０を動作させる。ＡＰＰ１５０は、コントローラ１４０以外のアプリケーションである。本実施の形態に係る制御装置１０は、ＶＭ１３０及びコントローラ１４０の組を３以上有する。なお、ＡＰＰ１５０は、コントローラ１４０が演算により算出する値の出力するタイミングを制御してもよい。

【0034】

コントローラ１４０は、センサ２０から入力された測定信号を、入力装置１１を介して受信する。次に、コントローラ１４０は、センサ２０から入力された測定信号に基づき、駆動装置３０に対して適用されるべき値を算出する。すなわち、コントローラ１４０は、工業プロセス４０に対する制御値を算出するための所定演算を実行するアプリケーションである。各コントローラ１４０は、例えば、入力された測定信号について所定のアルゴリズムで演算処理を行い、演算結果を出力する。各コントローラ１４０は、同一制御演算を実行する。同一制御演算とは、入力値が同じであり且つ正しい演算が行われた場合、まったく同じ演算結果が算出される演算である。

【0035】

さらに、制御装置１０は、ハードウェア１１０上で動作する選択処理部１６０を有する。なお、本実施の形態では選択処理部１６０がハードウェア１１０上で動作するとして説明するが、選択処理部１６０は、ＯＳ１２０上で動作してもよい。本実施形態において、選択処理部１６０は、ソフトウェアにより構成される。この場合、選択処理部１６０は、例えば、ハードウェア１１０上に専用のファームウェアで構築されてよい。

【0036】

選択処理部１６０は、各コントローラ１４０の動作を管理する。そして、選択処理部１６０は、アプリケーション管理部１７０からの要求を受けて、同一制御演算を実行するコントローラ１４０の総数をアプリケーション管理部１７０に通知する。

【0037】

また、選択処理部１６０は、各コントローラ１４０により算出されたそれぞれの演算値の入力をコントローラ１４０から受ける。ここで、図１では、図示の都合上、コントローラ１４３から選択処理部１６０へ延びる通信経路を記載したが、他のコントローラ１４０からも同様に選択処理部１６０へ通信経路が延びる。

【0038】

選択処理部１６０は、各コントローラ１４０により算出された演算値に基づいて出力値を選択する。具体的には、選択処理部１６０は、各コントローラ１４０から出力された演算値の中から１つの演算値を出力値として選択する。その後、選択処理部１６０は、選択した出力値に基づく制御信号を出力装置１２へ出力する。この制御信号が駆動装置３０へ送信されることで、制御信号に応じた駆動装置３０による工業プロセス４０の操作が行われる。このように、選択処理部１６０は、工業プロセス４０に対する制御値を算出するための所定演算を実行する複数のコントローラ１４０のそれぞれの演算結果を基に出力する演算結果を選択して出力する。

【0039】

例えば、センサ２０が流量を測定するセンサであり、駆動装置３０は配管に取り付けられ、当該配管に流れる流体の流量を制御するバルブの開度を調整するアクチュエータにより構成されている場合で説明する。この場合、センサ２０で測定された流量に関する情報の信号が、制御装置１０に入力される。選択処理部１６０は、複数のコントローラ１４０のそれぞれが取得した流量に関する情報に基づきアクチュエータに出力すべき値を演算した演算結果を演算値として取得する。次に、選択処理部１６０は、取得した演算値のうちの１つの演算値を出力値として選択する。その後、選択処理部１６０は、選択された出力値に基づく制御信号を出力装置１２出力する。その後、駆動装置３０が制御信号を受信すると、出力値に基づいて配管に流れる流体の流量が調整される。

【0040】

選択処理部１６０による演算値の選択処理についてさらに詳細に説明する。選択処理部１６０は、複数のコントローラ１４０から出力された演算値の中から、多数決ロジックにより出力値とする演算値を選択する。すなわち、選択処理部１６０は、複数のコントローラ１４０から出力された演算値のうち、同一の値が最も多く出力された演算値を出力値として選択する。もしくは、選択処理部１６０は、複数のコントローラ１４０から出力された演算値のうち、同一の値が半数以上のコントローラ１４０から出力された演算値を出力値として選択してもよい。ここで、同一の値としては、完全に値が一致していなくても、予め決められた許容差範囲内であれば、同一とみなしてもよい。許容差範囲としては、例えば、±１％以内など運用に応じて適切な値が設定されることが好ましい。さらに、許容範囲内にある演算値が複数ある場合、選択処理部１６０は、例えば、複数の演算値の平均値を算出して出力値として出力してもよい。他にも、選択処理部１６０は、許容範囲内にある演算値が３つ以上で存在する場合、中央値を算出して出力値として出力してもよい。このように、許容範囲内にある複数の演算値を代表する値を算出して出力値とすることができれば、選択処理部１６０は、他の方法により出力値を決定してもよい。

【0041】

例えば、コントローラ１４０が３つ存在する場合、選択処理部１６０は、３つのコントローラ１４０からそれぞれ出力された演算値を取得する。ここで、いずれか２つのコントローラ１４０が同一の演算値を出力し、他の１つのコントローラ１４０が別の演算値を出力している場合について説明する。この場合、選択処理部１６０は、２つのコントローラ１４０が出力した演算値が最も多く出力された演算値であるため、当該演算値を出力値として選択する。

【0042】

選択処理部１６０は、各コントローラ１４０から入力された演算値から多数決ロジックで１つの出力値を選択することで、ＶＭ１３０の一部又はコントローラ１４０の一部に異常が発生している場合であっても、正常とみなせる演算値を出力することができる。そのため、制御装置１０は、正常とみなせる出力値を継続して出力することができ、駆動装置３０を正常に駆動させることができる。ただし、選択処理部１６０が正常とみなせる演算値を得るといった信頼性を確保するためには、多数決ロジックによって信頼性を確保できる最低限のコントローラ１４０の数以上のコントローラ１４０が動作することが好ましい。

【0043】

また、選択処理部１６０は、コントローラ１４０の総数及び同一制御演算を実行するコントローラ１４０の数などを管理する。選択処理部１６０は、新しいコントローラ１４０からの出力を受信した場合、同一制御演算を実行させるコントローラ１４０の数を１つ増やす。逆に、値の比較等でコントローラ１４０の異常を検知した場合、選択処理部１６０は、同一制御演算を実行するコントローラ１４０の数を１つ減らす。

【0044】

さらに、制御装置１０は、ハードウェア１１０上で動作するアプリケーション管理部１７０を有する。ここで、図１では、選択処理部１６０とアプリケーション管理部１７０とを別個に図示したが、アプリケーション管理部１７０は、選択処理部１６０の機能の一部として選択処理部１６０に含まれてもよい。

【0045】

アプリケーション管理部１７０は、ＶＭ１３０及びコントローラ１４０を含むアプリケーションの実行中及び停止中といった動作状態を管理する。さらに、アプリケーション管理部１７０は、ＶＭ１３０の起動、停止、再起動などの動作の指示を行う。また、アプリケーション管理部１７０は、コントローラ１４０の再構築を行う際に、再構築の可否の判定を行い、再構築が可能な場合にコントローラ１４０の再構築を実行させる。

【0046】

具体的には、アプリケーション管理部１７０は、ソフトウェアエラーの予測の通知をＶＭ１３０から受けた場合、通知元のＶＭ１３０を対象として、そのＶＭ１３０が動作させるコントローラ１４０の再構築の可否の判定を行う。また、アプリケーション管理部１７０は、ＶＭ１３０やコントローラ１４０の状態が所定条件に達した場合、その所定条件に達したＶＭ１３０が動作させるコントローラ１４０又は所定条件に達したコントローラ１４０を再構築対象として、再構築の可否を判定する。所定条件に達したとは、例えば、ＶＭ１３０の稼働時間が所定時間を超えた場合などである。

【0047】

ここで、アプリケーション管理部１７０は、システム環境によって、所定条件に基づいて再起動対象を特定するための基準を変化させることができる。例えば、アプリケーション管理部１７０は、各ＶＭ１３０に割り当てられたメモリサイズにより、特定のコントローラ１４０を再構築対象とする判断基準である稼働時間を変化させる。すなわち、アプリケーション管理部１７０は、搭載メモリサイズと係数とを乗算して所定条件における判定基準である稼働時間を算出する。例えば、ＶＭ１３０に割り当てられたメモリサイズが４ＧＢの場合、アプリケーション管理部１７０は、所定条件における判定基準である稼働時間を４×１日＝４日と算出する。また、ＶＭ１３０に割り当てられた８ＧＢの場合、アプリケーション管理部１７０は、所定条件における判定基準である稼働時間を８×１日＝８日と算出する。

【0048】

再構築要求をＶＭ１３０から受けた場合及び再起動対象のコントローラ１４０を自ら決定した場合のいずれの場合も、アプリケーション管理部１７０は、以下の再構築の可否の判定処理を実行する。以下に、アプリケーション管理部１７０による再構築の可否の判定処理の詳細について説明する。

【0049】

アプリケーション管理部１７０は、同一制御演算を実行するコントローラ１４０の総数を選択処理部１６０から取得する。次に、アプリケーション管理部１７０は、同一制御演算を実行するコントローラ１４０の総数から、再構築対象のコントローラ１４０の数を減算して、再構築中に稼働する同一制御演算を実行するコントローラ１４０の数を算出する。以下では、再構築中に稼働する同一制御演算を実行するコントローラ１４０を、「再構築中に稼働するコントローラ１４０」と呼ぶ。そして、アプリケーション管理部１７０は、再構築中に稼働するコントローラ１４０により、制御システム１の信頼性を確保できるか否かを判定する。制御システム１の信頼性を確保できるとは、選択処理部１６０が多数決ロジックで正しいと思われる演算値を選択する信頼性を確保できることである。すなわち、制御システム１の信頼性が確保できれば、制御装置１０が駆動装置３０を正常に駆動させることができる。

【0050】

例えば、アプリケーション管理部１７０は、再構築中に稼働するコントローラ１４０の数が、同一制御演算を実行するコントローラ１４０の元の総数の過半数以上であれば、制御システム１の信頼性を確保できると判定する。ここで、同一制御演算を実行するコントローラ１４０の総数が５つの場合を例に説明する。再構築対象のコントローラ１４０の数が１つであれば、アプリケーション管理部１７０は、再構築中に稼働するコントローラ１４０の数が４で元の総数の過半数以上であることから、制御システム１の信頼性を確保できると判定する。これに対して、再構築対象のコントローラ１４０の数が３つであれば、アプリケーション管理部１７０は、再構築中に稼働するコントローラ１４０の数が２で元の総数の過半数未満であることから、制御システム１の信頼性を確保困難である判定する。

【0051】

制御システム１の信頼性を確保できると判定した場合、アプリケーション管理部１７０は、再構築対象のコントローラ１４０の再構築の実行が可能と判定する。そして、アプリケーション管理部１７０は、再構築対象のコントローラ１４０が動作する対象のＶＭ１３０に、そのＶＭ１３０が動作させるコントローラ１４０の再構築を指示する。すなわち、アプリケーション管理部１７０は、コントローラ１４０のいずれか一つまたはいくつかを再構築対象として、再構築対象以外のコントローラ１４０の演算により選択処理部１６０による出力値の信頼性を確保できるか否かを判定し、信頼性が確保できる場合に再構築対象のコントローラ１４０の再構築を実行する。また、アプリケーション管理部１７０は、ＶＭ１３０及びコントローラ１４０の動作状態を基に、各コントローラ１４０を再構築するか否かを決定し、再構築対象以外のコントローラ１４０の演算により信頼性を確保できるか否かを判定し、信頼性が確保できる場合に再構築対象のコントローラ１４０の再構築を実行する。

【0052】

これに対して、制御システム１の全体の信頼性を確保できないと判定した場合、アプリケーション管理部１７０は、再構築の実行を一定の再判定時間保留する。再判定時間は、例えば、１分とすることができる。再判定時間の経過後、アプリケーション管理部１７０は、再構築の可否の判定処理を再実行する。

【0053】

再構築の可否の判定処理を繰り返す場合、アプリケーション管理部１７０は、一定の上限時間に達したか否かを判定する。上限時間は、例えば、５分とすることができる。上限時間を経過しても再構築が実行できない場合、アプリケーション管理部１７０は、ＯＳ１２０に新たなＶＭ１３０及びコントローラ１４０の起動を指示する。そして、新たなコントローラ１４０が増えた後、アプリケーション管理部１７０は、新たなコントローラ１４０が加えられた同一制御演算を実行するコントローラ１４０の総数を選択処理部１６０から取得する。その後、アプリケーション管理部１７０は、取得した新たな総数を用いて、再構築の可否の判定処理を再度実行する。

【0054】

ここで、アプリケーション管理部１７０が用いる再構築の可否の判定ロジックは、対象とするコントローラ１４０が実行する同一制御演算に求められる信頼性によって可変である。例えば、アプリケーション管理部１７０は、以下のように再起動の可否の判定ロジックを異ならせることができる。すなわち、コントローラ１４０が実行する同一制御演算に高信頼が求められる場合、アプリケーション管理部１７０は、過半数以上が稼働すれば（５台中３台が稼働するなどの状態）、制御システム１の全体の信頼性を確保でき、再起動を実行すると判定する。これに対して、コントローラ１４０が実行する同一制御演算に高信頼性が求められない場合、アプリケーション管理部１７０は、複数台が稼働すれば（５台中２台が稼働するなどの状態）、制御システム１の全体の信頼性を確保でき、再起動を実行すると判定する。

【0055】

他にも、アプリケーション管理部１７０は、再構築中に稼働するコントローラ１４０の数に３以上などと最低数の条件を加えて、再起動の可否の判定を行ってもよい。ただし、再構築中に動作するコントローラ１４０の数は２台よりは３台、３台よりは４台の方が最終的に正しい出力を選択処理部１６０が選択できる可能性は高くなる。そこで、再構築中に動作するコントローラ１４０の最低数は、運用状態に合わせて設定されることが好ましい。

【0056】

［再構築処理］
図２は、ＶＭからの再構築要求に基づく再構築処理のフローチャートである。次に、図２を参照して、実施の形態１に係る制御装置１０におけるＶＭ１３０らの再構築要求に基づく再構築処理の流れを説明する。

【0057】

アプリケーション管理部１７０は、再構築要求をＶＭ１３０から受信する（ステップＳ１０１）。

【0058】

次に、アプリケーション管理部１７０は、同一制御演算を実行するコントローラ１４０の総数を選択処理部１６０から取得する（ステップＳ１０２）。

【0059】

次に、アプリケーション管理部１７０は、再構築要求の送信元である再構築対象のコントローラ１４０を停止しても制御システム１の信頼性が確保可能か否かを判定する（ステップＳ１０３）。

【0060】

再構築対象のコントローラ１４０を停止しても制御システム１の信頼性が確保可能な場合（ステップＳ１０３：肯定）、アプリケーション管理部１７０は、再構築対象のコントローラ１４０を動作させるＶＭ１３０に再構築を指示する（ステップＳ１０４）。そして、アプリケーション管理部１７０は、再構築処理を終了する。

【0061】

これに対して、再構築対象のコントローラ１４０を停止すると制御システム１の信頼性の確保が困難な場合（ステップＳ１０３：否定）、アプリケーション管理部１７０は、予め決められた一定時間である再判定時間待機する（ステップＳ１０５）。

【0062】

次に、アプリケーション管理部１７０は、再起動判定時間よりも長い予め決められた一定時間である上限時間が経過したか否かを判定する（ステップＳ１０６）。上限時間が経過していない場合（ステップＳ１０６：否定）、アプリケーション管理部１７０は、ステップＳ１０２へ戻る。

【0063】

これに対して、上限時間が経過した場合（ステップＳ１０６：肯定）、アプリケーション管理部１７０は、新たなＶＭ１３０及びコントローラ１４０の起動をＯＳ１２０に指示する（ステップＳ１０７）。その後、アプリケーション管理部１７０は、ステップＳ１０２へ戻る。

【0064】

図３は、アプリケーション管理部による再構築の決定に基づく再構築処理のフローチャートである。次に、図３を参照して、実施の形態１に係る制御装置１０におけるアプリケーション管理部１７０による再構築の決定に基づく再構築処理の流れを説明する。

【0065】

アプリケーション管理部１７０は、ＶＭ１３０やコントローラ１４０の稼働時間などから再構築対象のコントローラ１４０を決定する（ステップＳ２０１）。

【0066】

次に、アプリケーション管理部１７０は、同一制御演算を実行するコントローラ１４０の総数を選択処理部１６０から取得する（ステップＳ２０２）。

【0067】

次に、アプリケーション管理部１７０は、再構築対象のコントローラ１４０を停止しても制御システム１の信頼性が確保可能か否かを判定する（ステップＳ２０３）。

【0068】

再構築対象のコントローラ１４０を停止しても制御システム１の信頼性が確保可能な場合（ステップＳ２０３：肯定）、アプリケーション管理部１７０は、再構築対象のコントローラ１４０を動作させるＶＭ１３０に再構築を指示する（ステップＳ２０４）。そして、アプリケーション管理部１７０は、再構築処理を終了する。

【0069】

これに対して、再構築対象のコントローラ１４０を停止すると制御システム１の信頼性の確保が困難な場合（ステップＳ２０３：否定）、アプリケーション管理部１７０は、予め決められた一定時間である再判定時間待機する（ステップＳ２０５）。

【0070】

次に、アプリケーション管理部１７０は、再起動判定時間よりも長い予め決められた一定時間である上限時間が経過したか否かを判定する（ステップＳ２０６）。上限時間が経過していない場合（ステップＳ２０６：否定）、アプリケーション管理部１７０は、ステップＳ２０２へ戻る。

【0071】

これに対して、上限時間が経過した場合（ステップＳ２０６：肯定）、アプリケーション管理部１７０は、新たなＶＭ１３０及びコントローラ１４０の起動をＯＳ１２０に指示する（ステップＳ２０７）。その後、アプリケーション管理部１７０は、ステップＳ２０２へ戻る。

【0072】

ここで、本実施例では、ＶＭ１３０やコントローラ１４０の状態が所定条件に達した場合にアプリケーション管理部１７０が再起動対象とするＶＭ１３０を決定したが、再起動対象を決定する処理は各ＶＭ１３０が行ってもよい。その場合、ＶＭ１３０は、ＶＭ１３０やコントローラ１４０の状態が所定条件に達した場合もソフトウェアエラーの予測の場合と同様に、再起動対象としたＶＭ１３０やコントローラ１４０の再起動の指示をアプリケーション管理部１７０に通知する。

【0073】

例えば、ＶＭ１３０は、自己が動作させるコントローラ１４０の稼働時間が自己に割り当てられたメモリサイズに対応した稼働時間閾値を超えたか否かを判定する。自己が動作させるコントローラ１４０の稼働時間が稼働時間閾値を超えた場合、ＶＭ１３０は、ソフトウェアエラーの発生を予測する。そして、ＶＭ１３０は、再構築要求をアプリケーション管理部１７０に通知する。この場合、アプリケーション管理部１７０は、ＶＭ１３０からの通知を基に再構築対象とするコントローラ１４０を決定して再構築の可否の判定処理を実行する。

【0074】

［効果］
以上に説明したように、本実施の形態に係る制御システム１は、ソフトウェアエラーによりシステムの動作に影響がでることを予測して、そのソフトウェアエラーの予測がなされたコントローラ１４０を再構築対象とする。また、制御システム１は、ＶＭ１３０やコントローラ１４０の状態が所定条件に達した場合に、そのＶＭ１３０やそのコントローラ１４０を再構築対象とする。そして、制御システム１は、再構築対象としたコントローラ１４０が停止してもシステムの信頼性が確保可能か否かを判定し、確保可能な場合に再構築対象のＶＭ１３０の再構築を実行する。

【0075】

これにより、制御システム１は、メモリリークなどのソフトウェアエラーが実際に発生する前に、事前にコントローラ１４０を再構築することができ、ソフトウェアエラーによる制御動作の中断などの信頼性の低下を軽減することが可能となる。また、制御システム１は、コントローラ１４０の再構築中にも制御動作の継続など信頼性を確保することができるため、通常運用及び再構築処理を含むシステムの動作全体において信頼性を維持することが可能となる。したがって、アプリケーションの動作不安定を回避して、制御システム１の信頼性を向上させることが可能となる。

【0076】

（変形例）
上述した実施の形態１では、１つのハードウェア１１０上でシステム全体が稼働する構成で説明したが、システム構成はこれに限らない。

【0077】

例えば、ハードウェア１１０において複数のＯＳ１２０が動作し、各ＯＳ１２０上で１つ又は複数のＶＭ１３０が動作してもよい。また、ハードウェア１１０が複数存在し、それぞれで１つ又は複数のＶＭ１３０が動作してもよい。その場合、いずれかのハードウェア１１０の選択処理部１６０及びアプリケーション管理部１７０が、複数のハードウェア１１０にまたがって演算値の選択処理やＶＭ１３０の再構築を統括してもよい。

【0078】

さらに、１つ又は複数のコントローラ１４０が、ハードウェア１１０から物理的に独立してもよい。また、ハードウェア１１０上で動作するコントローラ１４０と、物理的に独立したコントローラ１４０とが共存してもよい。また、アプリケーション管理部１７０及び選択処理部１６０が、ＶＭ１３０及びコントローラ１４０とは異なるハードウェア１１０上で動作してもよい。

【0079】

図４は、実施の形態１の変形例に係る制御システムの構成の一例を示す図である。図４では、制御システム１は、２つの制御装置１０を有する。さらに、制御システム１は、コントローラ専用ハードウェア４０１でコントローラ４０２が動作する物理コントローラ４００を２つ有する。コントローラ４０２は、コントローラ１４０と同一制御演算を行なうことができる。また、物理コントローラ４００以外にも、コントローラ４０２は、クラウドやネットワーク上のサーバに配置されてもよい。

【0080】

この場合、２つの制御装置１０のいずれかの選択処理部１６０及びアプリケーション管理部１７０が、全てのＶＭ１３０、並びに、コントローラ１４０及び４０２の演算値の選択処理やＶＭ１３０の再構築を行ってもよい。もしくは、異なる同一制御演算を行なう複数のグループにコントローラ１４０及び４０２が分けられる場合、グループ毎に担当する選択処理部１６０及びアプリケーション管理部１７０を割り当ててもよい。

【0081】

ここで、再構築対象となったコントローラ１４０を動作させるＶＭ１３０が他のＶＭ１３０とは異なるＯＳ１２０で動作する場合、コントローラ１４０の再構築には、ＯＳ１２０の再起動、ＯＳ１２０を停止した後に起動、及び、ＯＳ１２０の再インストールなどが含まれてもよい。

【0082】

［実施の形態２］
次に、実施の形態２について説明する。本実施の形態に係る制御装置１０も、図１のブロック図で表される。本実施の形態に係る制御装置１０は、動作の特異なコントローラ１４０を特定して再構築要求を行なう。以下の説明では、実施の形態１と同様の各部の動作については説明を省略する。

【0083】

選択処理部１６０は、演算値を各コントローラ１４０から受信する。そして、選択処理部１６０は、演算値の受信結果から動作の特異なコントローラ１４０を特定する。その後、選択処理部１６０は、特定した動作の特異なコントローラ１４０の再構築要求をアプリケーション管理部１７０へ出力する。

【0084】

例えば、選択処理部１６０は、同一制御演算を行う複数のコントローラ１４０のうち、特定のコントローラ１４０の演算結果が異なる場合に、その特定のコントローラ１４０を動作の特異なコントローラ１４０として特定する。選択処理部１６０は、演算結果が１回異なった場合に、その特定のコントローラ１４０の演算結果が異なると判定しても良いし、複数回異なった場合に、その特定のコントローラ１４０の演算結果が異なると判定しても良い。さらに、選択処理部１６０は、予め決められた回数連続して演算結果が異なった場合に、その特定のコントローラ１４０の演算結果が異なると判定しても良いし、異なった回数の累積が予め決められた数に達した場合に、その特定のコントローラ１４０の演算結果が異なると判定しても良い。

【0085】

他にも、例えば一定時間の範囲で演算結果を受信する設計だった場合に、選択処理部１６０は、特定のコントローラ１４０からの演算結果の受信が一定時間以上遅れた場合に、その特定のコントローラ１４０を動作の特異なコントローラ１４０として特定する。これは、例えばメモリリーク等によりコントローラ１４０の処理能力が低くなることが想定されるため、選択処理部１６０は、演算結果の受信が一定時間以上遅れた特定のコントローラ１４０を動作の特異なコントローラ１４０として特定する。ここで、複数のアプリケーションから選択処理部１６０に演算結果が届くタイミングはそれぞれ異なる可能性があるため、選択処理部１６０は、ある程度の期間、演算結果が届くことを待つ機能を有してもよい。

【0086】

さらに、選択処理部１６０は、同一制御演算の演算値のうち選択されなかった演算値を出力したコントローラ１４０を、動作の特異なコントローラ１４０として特定してもよい。

【0087】

このように、選択処理部１６０は、アプリケーションであるコントローラ１４０のそれぞれの演算結果を受信した結果を基に、コントローラ１４０の異常動作を検出する。

【0088】

また、ＶＭ１３０が動作の特異なコントローラ１４０を特定してもよい。例えば、ＶＭ１３０は、一般的な動作状態の監視結果として、ＣＰＵ負荷やネットワークの異常といったＶＭ１３０を再起動させることで回復する障害を検出して、自己が動作させるコントローラ１４０の動作が特異であると判定する。そして、ＶＭ１３０は、アプリケーション管理部１７０に再構築要求を行なう。

【0089】

アプリケーション管理部１７０は、動作の特異なコントローラ１４０の再構築要求を選択処理部１６０から受ける。そして、アプリケーション管理部１７０は、動作の特異なコントローラ１４０として指定されえたコントローラ１４０を再構築対象として、再構築の可否の判定処理を行う。アプリケーション管理部１７０は、再構築の実行が可能であれば、指定された動作の特異なコントローラ１４０を動作させるＶＭ１３０に再構築を指示する。

【0090】

また、アプリケーション管理部１７０は、自己が動作させるコントローラ１４０の動作が特異であると判定したＶＭ１３０から再構築要求を受けてもよい。そして、アプリケーション管理部１７０は、再構築要求の送信元のＶＭ１３０が動作させるコントローラ１４０を再構築対象とする。その後、アプリケーション管理部１７０は、再構築の可否の判定処理を行い、再構築が可能であれば動作の特異なコントローラ１４０を動作させるＶＭ１３０に再構築を指示する。

【0091】

このように、アプリケーション管理部１７０は、選択処理部１６０により検出された動作の特異なコントローラ１４０を再構築対象として、再構築対象以外のコントローラ１４０の演算により信頼性を確保できるか否かを判定し、信頼性が確保できる場合に再構築対象のコントローラ１４０の再構築を実行する。

【0092】

以上に説明したように、本実施例に係る制御システム１は、動作の特異なコントローラ１４０を特定して、その特定されたコントローラ１４０を動作させるＶＭ１３０を再構築する。これにより、ソフトウェアエラー以外にも、制御システム１の動作に影響を与えそうな不安定な動作を行うコントローラ１４０の再構築を実際に障害が発生する前に行うことができ、制御システム１の信頼性を向上させることが可能となる。

【0093】

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

【0094】

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

【0095】

さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

【0096】

［ハードウェア］
次に、制御装置１０のハードウェア構成例を説明する。図５は、制御装置のハードウェア構成図である。図５に示すように、制御装置１０は、プロセッサ９１、メモリ９２、通信装置９３及びＨＤＤ（Hard Disk Drive）９４を有する。プロセッサ９１、メモリ９２、通信装置９３及びＨＤＤ９４は、図１に例示したハードウェア１１０の一例にあたる。プロセッサ９１は、バスを介してメモリ９２、通信装置９３及びＨＤＤ９４と接続される。

【0097】

通信装置９３は、ネットワークインタフェースカードなどであり、他の情報処理装置との通信に使用される。例えば、制御装置１０が複数存在する場合、通信装置９３は、異なる制御装置１０のプロセッサ９１間の通信を中継する。

【0098】

ＨＤＤ９４は、補助記憶装置である。ＨＤＤ９４は、図１に例示した、ＯＳ１２０、ＶＭ１３１～１３３、コントローラ１４１～１４３、ＡＰＰ１５１～１５３、選択処理部１６０及びアプリケーション管理部１７０の機能を実現するプログラムを含む各種プログラムを格納する。

【0099】

プロセッサ９１は、ＨＤＤ９４に格納された各種プログラムを読み出してメモリ９２に展開して実行する。これにより、プロセッサ９１は、図１に例示した、ＯＳ１２０、ＶＭ１３１～１３３、コントローラ１４１～１４３、ＡＰＰ１５１～１５３、選択処理部１６０及びアプリケーション管理部１７０の機能を実現する。

【0100】

このように制御装置１０は、プログラムを読み出して実行することで各種処理方法を実行する情報処理装置として動作する。また、制御装置１０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、ここでいうプログラムは、制御装置１０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

【0101】

このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ（Magneto－Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。

【0102】

開示される技術的特徴の組合せのいくつかの例を以下に記載する。
（１）
所定演算を実行する複数のアプリケーションのそれぞれの演算結果を基に出力する演算結果を選択して出力する選択処理部と、
前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算により前記選択処理部による出力の信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行するアプリケーション管理部と
を備えたことを特徴とする制御装置。
（２）
前記アプリケーションは、前記所定演算としてそれぞれが同じ演算を行なう同一制御演算を実行し、
前記選択処理部は、前記演算結果に対して多数決ロジックを用いて前記出力する演算結果を選択する
ことを特徴とする（１）に記載の制御装置。
（３）
前記アプリケーション管理部は、再構築対象以外の前記アプリケーションの数が、前記選択処理部の多数決ロジックを用いた出力の信頼性を確保できる前記アプリケーションの数以上の場合に、前記信頼性を確保できると判定することを特徴とする（２）に記載の制御装置。
（４）
前記アプリケーション管理部は、前記アプリケーションの動作状態を基に、各前記アプリケーションを再構築するか否かを決定し、再構築対象以外の前記アプリケーションの演算により前記信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行することを特徴とする（１）～（３）のいずれか一つに記載の制御装置。
（５）
前記選択処理部は、前記アプリケーションのそれぞれの演算結果を受信した結果を基に、前記アプリケーションの異常動作を検出し、
前記アプリケーション管理部は、前記選択処理部により異常動作が検出された前記アプリケーションを再構築対象として、再構築対象以外の前記アプリケーションの演算により前記信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行する
ことを特徴とする（１）～（４）のいずれか一つに記載の制御装置。
（６）
前記アプリケーション管理部は、前記再構築対象の前記アプリケーションの、停止及び起動、又は、再インストールを行うことで、前記再構築対象の前記アプリケーションを再構築することを特徴とする（１）～（５）のいずれか一つに記載の制御装置。
（７）
前記アプリケーション管理部は、再構築中に前記選択処理部による出力の信頼性を確保可能な数以上の前記アプリケーションが動作するように制御することを特徴とする（１）～（６）のいずれか一つに記載の制御装置。
（８）
前記選択処理部は、新しいアプリケーションからの出力を受信した場合、前記所定演算を実行するアプリケーションの数を１つ増やし、前記アプリケーションの異常を検知した場合、前記所定演算を実行するアプリケーションの数を１つ減らして、前記選択処理部による出力の信頼性を確保できるか否かの判定を行なうことを特徴とする（１）～（７）のいずれか一つに記載の制御装置。
（９）
前記アプリケーション管理部は、前記選択処理部による出力の信頼性を確保できるか否かの判定ロジックを、前記アプリケーションが実行する前記所定演算に求められる信頼性によって異ならせることを特徴とする（１）～（８）のいずれか一つに記載の制御装置。
（１０）
前記アプリケーション管理部は、前記アプリケーションの稼働時間を基に再構築対象とする前記アプリケーションを決定することを特徴とする（１）～（９）のいずれか一つに記載の制御装置。
（１１）
前記アプリケーションは、工業プロセスに対する制御値を算出するための前記所定演算を実行するアプリケーションであることを特徴とする（１）～（１０）に記載の制御装置。
（１２）
プラント施設に配置されたセンサからの計測結果の入力を受ける入力装置、前記プラント施設に設けられた機構を駆動する駆動装置を駆動させる出力装置及び制御装置を有する制御システムであって
前記制御装置は、
前記入力装置に入力された前記センサによる計測結果を基に所定演算を実行するアプリケーションを各々が動作させる複数の仮想マシンと、
前記アプリケーションのそれぞれの演算結果を基に出力する演算結果を選択し、選択した演算結果を前記出力装置から出力させて前記駆動装置を駆動させる選択処理部と、
前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算により前記選択処理部による出力の信頼性を確保できるか否かを判定し、前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行するアプリケーション管理部と
を備えたことを特徴とする制御システム。
（１３）
制御装置に、
所定演算を実行する複数のアプリケーションを実行させ、
前記複数のアプリケーションそれぞれの演算結果を基に出力する演算結果を選択させて出力させ
各前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算結果により、出力する前記演算結果の出力の信頼性を確保できるか否かを判定させ、
前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行させる
ことを特徴とする制御方法。
（１４）
所定演算を実行する複数のアプリケーションを動作させ、
前記複数のアプリケーションそれぞれの演算結果を基に出力する演算結果を選択して出力し、
前記アプリケーションのいずれか一つ又はいくつかを再構築対象として、再構築対象以外の前記アプリケーションの演算結果により、出力する前記演算結果の出力の信頼性を確保できるか否かを判定し、
前記信頼性が確保できる場合に前記再構築対象の前記アプリケーションの再構築を実行する
処理をコンピュータに実行させることを特徴とする制御プログラム。

【符号の説明】

【0103】

１ 制御システム
１０ 制御装置
１１ 入力装置
１２ 出力装置
２０ センサ
３０ 駆動装置
１１０ ハードウェア
１２０ ＯＳ
１３０～１３３ ＶＭ（Virtual Machine）
１４０～１４３ コントローラ
１５０～１５３ ＡＰＰ
１６０ 選択処理部
１７０ アプリケーション管理部

【図1】

【図2】

【図3】

【図4】

【図5】