JP2020027434A - 制御システム及び制御装置 - Google Patents

Abstract

【課題】信頼性を高めつつ、コストを抑制する制御システム及び制御装置を実現する。【解決手段】制御システム２は、ハードウェア１１１と、ハードウェア１１１上にて動作するアプリケーション間干渉防止処理部１１９と、アプリケーション間干渉防止処理部１１９上で動作する複数のコントローラアプリケーション１１４と、選択処理部１１５と、を有し、コントローラアプリケーション１１４のそれぞれは、入力値に対して所定の演算を実行し、演算結果としての演算値を出力し、選択処理部１１５は、コントローラアプリケーション１１４のそれぞれから出力された演算値に基づいて、１つの出力値を選択し、出力値を出力する。【選択図】図２

Description

本開示は、プロセス制御を行う制御システム及び制御装置に関する。

制御システムには制御対象に応じた信頼性の確保が求められる。高い信頼性が求められない場合には制御装置を１台用いるシステムが採用される一方、高い信頼性が必要な場合には２台の制御装置を備える冗長化構成のシステムが採用される。例えば、特許文献１には、計算機という呼称の２台の制御装置を用いた待機冗長形の二重化計算器システムが開示されている。

制御装置の機能は、ＣＰＵ（Central Processing Unit：中央処理装置）やメモリ等のハードウェアと、コントローラアプリケーションのソフトウェアとから構成されるのが一般的である。このハードウェア、ソフトウェアのどちらが不具合を起こしても制御装置の動作に不具合をきたす。このため、特許文献１に示される制御装置は、ハードウェア及びソフトウェアの双方を冗長化した構成をとっている。ハードウェアが原因でシステム全体が不具合に陥る確率は、ハードウェア冗長化構成とすることにより、大幅に低減されている。同じく、ソフトウェアが原因でシステム全体が不具合に陥る確率はソフトウェア冗長化構成とすることにより大幅に低減している。

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

２台の制御装置を用いた冗長化構成を備えるシステムでは、１台の制御装置のみを用いるシステムの場合と比較して信頼性が大きく向上するというメリットがある反面、装置数が倍増するとともに、制御装置間でのデータベース等値化のための通信経路等が必要となるというデメリットがある。特許文献１に示されるような２台の制御装置を用いた冗長化構成を備えるシステムのシステムコストは一般的には１台の制御装置を用いるシステムの２倍以上となる。信頼性とコストとのトレードオフの観点で、２台の制御装置を用いた冗長化構成を備えるシステムと１台の制御装置のみを用いるシステムとの間には大きな隔たりがあり、中間的なシステムを提供できていなかった。

本開示はこのギャップを埋めるものであり、信頼性を高めつつ、コストを抑制する制御システム及び制御装置を実現することを可能とする。

本開示は一台のハードウェア上で複数のコントローラアプリケーションを冗長構成で動作させる制御システム及び制御装置に関するものである。

幾つかの実施形態に係る制御システムは、ハードウェアと、ハードウェア上にて動作するアプリケーション間干渉防止処理部と、アプリケーション間干渉防止処理部上で動作する複数のコントローラアプリケーション（以下、単にコントローラとも称する）と、選択処理部と、を有し、コントローラのそれぞれは、入力値に対して所定の演算を実行し、演算結果としての演算値を出力し、選択処理部は、コントローラのそれぞれから出力された演算値に基づいて、１つの出力値を選択し、出力値を出力する。このような構成を有する制御システムによれば、選択処理部が、正しい演算値を選択する限りにおいて、複数のコントローラの一部が停止したり異常な演算値を算出したりする等、エラーが発生した場合であっても、制御システムからは、正常な出力が継続され得る。すなわち制御システム全体としては正常な制御動作を行うことが可能である。

一実施形態において、制御システムは、コントローラを３以上有し、選択処理部は、コントローラのそれぞれから出力された演算値のうち、同一の値が最も多い演算値、又は、コントローラのそれぞれから出力された演算値のうち、同一の値が過半数となる演算値を、出力値として選択してもよい。

一実施形態において、コントローラの個数は、設定可能であってもよい。

一実施形態において、入力値は、入力装置からコントローラに入力され、出力値は、選択処理部から出力装置に出力されてよい。

一実施形態において、選択処理部は、アプリケーション間干渉防止処理部が動作するハードウェアとは異なるハードウェアに構成されてよい。

一実施形態において、制御システムは、出力値とは値が異なる演算値を出力したコントローラを特定してよい。

一実施形態において、制御システムは、特定したコントローラを再起動する処理を実行してよい。

一実施形態において、再起動する処理は、外部からの操作入力に基づいて実行されてよい。

一実施形態において、制御システムは、特定したコントローラを、予備のコントローラに差し替える処理を実行してよい。

一実施形態において、差し替える処理は、特定したコントローラに関する情報を、予備のコントローラに反映させる処理を含んでよい。

一実施形態において、制御システムは、特定したコントローラに関する情報又は特定したコントローラについて実行した処理に関する情報を、外部の装置に出力し、又は表示部に表示してよい。

一実施形態において、制御システムは、特定したコントローラに関するエラー情報が出力された場合、エラー情報の保存及び／又はエラー情報の分析を実行してよい。

一実施形態において、コントローラに割り当てられるリソースが異なる値に設定されてよい。

一実施形態において、アプリケーション間干渉防止処理部は、ハードウェアにて動作するＯＳと、ＯＳにて動作する少なくとも３以上のゲストＯＳによりコントローラを動作させる、又は、ハードウェアにて少なくとも３以上の仮想ハードウェアによりコントローラを動作させてよい。

一実施形態において、アプリケーション間干渉防止処理部は、ハードウェアにて動作するＯＳと、ＯＳにて動作する少なくとも３以上のコンテナによりコントローラを動作させてよい。

幾つかの実施形態に係る制御装置は、ハードウェアと、ハードウェア上にて動作するアプリケーション間干渉防止処理部と、アプリケーション間干渉防止処理部上で動作する複数のコントローラアプリケーションと、選択処理部と、を有し、コントローラアプリケーションのそれぞれは、入力値に対して所定の演算を実行し、演算結果としての演算値を出力し、選択処理部は、コントローラアプリケーションのそれぞれから出力された演算値に基づいて、１つの出力値を選択し、出力値を出力する。

本開示によれば、信頼性を高めつつ、コストを抑制する制御システム及び制御装置を提供することができる。

制御システムの一例を示す概略図である。 本開示に係る制御システムの概念図である。 第１実施形態に係る制御システムを示す概略図である。 第２実施形態に係る制御システムを示す概略図である。 第１実施形態に係る制御システムの一変形例を示す概略図である。 第１実施形態に係る制御システムの他の一変形例を示す概略図である。 第１実施形態に係る制御システムのさらに他の一変形例を示す概略図である。

以下、本発明の一実施形態について、図面を参照して説明する。

図１は、制御システムの一例を示す概略図である。図１に示す制御システム１は、制御装置１０と、入力装置２１と、出力装置３１を備える。制御システム１は、例えばプラントの工業プロセスの制御等に使用される。本明細書において、プラントは、化学等の工業プラント、ガス田もしくは油田等の井戸元又はその周辺を管理制御するプラント、水力・火力・原子力等の発電を管理制御するプラント、太陽光や風力等の環境発電を管理制御するプラント、及び上下水やダム等を管理制御するプラント等を含む。

制御装置１０は、ネットワークに接続される。センサ２０は工業プロセスに設けられ、測定対象の物理量は測定信号として入力装置２１からネットワーク経由で、制御装置１０に入力される。制御装置１０は、入力された測定信号に基づいて、例えば所定の演算処理を行い、ネットワーク経由で演算結果に応じた制御信号を出力装置３１に出力する。駆動装置３０は、出力装置３１から制御信号の入力を受け付けると、制御信号に応じて工業プロセスを駆動する。本明細書において、センサは、例えば圧力計、流量計、温度センサ等のセンサ機器、プラント内の異音等を収集するマイクや各機器の位置情報を出力する位置検出機器、プラント内の状況や対象物を撮影するカメラやビデオ等の撮像機器、駆動装置は、流量制御弁や開閉弁等のバルブ機器、ファンやモータ等の操作端、警報音等を発したりするスピーカ等の音響機器、及びその他の機器を含む。

制御装置１０は、例えばコンピュータ装置により構成される。ハードウェア上でＯＳ（Operating System：オペレーティングシステム）を動作させ、ＯＳ上で、制御アプリケーションであるコントローラアプリケーションを動作させるように構成されている。入力された測定信号について、所定のアルゴリズムで演算処理を行い、制御信号を生成する。

制御装置の機能は、ＣＰＵやメモリ等のハードウェアと、コントローラアプリケーションのソフトウェアから構成される。このどちらが動作不全に陥っても制御装置は動作不全となるので、制御装置の不具合発生率は、ハードウェアの不具合の発生率と、ソフトウェアの不具合の発生率との加算で決定される。また、ハードウェアの不具合は偶発故障等により発生することが多く、ソフトウェアの不具合は潜在バグの発現等による発生が多い。

近年の傾向では、ソフトウェアの複雑度の増加はハードウェアの複雑度の増加を大きく上回っており、ソフトウェアのバグ等に起因して不具合が発生する確率が、ハードウェアの故障に起因して不具合が発生する確率より高くなっている。従って、ソフトウェアに起因する不具合の発生を回避すれば、制御装置全体の信頼性の確保に有効である。

ソフトウェアの動作を確実なものとするため、ＯＳの機能を簡易なものに制限したり、ソフトウェアの作り方に制約を加えたりする等の対策が講じられる場合がある。しかしながら、このような対策により、制御システムの機能が制約されたり、新たな機能等の追加が遅れたりする場合がある。

異なるアプローチとして、一台のハードウェア上で複数のコントローラアプリケーションを冗長構成で動作させる構成が想定される。

一つのハードウェア上に複数のアプリケーションを動作させる場合には、ＯＳを導入することが一般的である。しかしながら、ＯＳ上で同一のアプリケーションを複数動作させるだけでは冗長化を実現したことにはならない。ＯＳが提供するアプリケーション間の干渉排除が完全ではないことがその理由である。

ＯＳ上で動作する複数のアプリケーションのうち、１つ以上のアプリケーションが何らかの理由で不必要に大きなコンピューティングリソースを浪費する場合がこれに相当する。例えば、アプリケーションにプログラム的なバグがあることにより、ＣＰＵの処理時間を異常に多く消費して他のアプリケーションの実行が遅くなる場合がある。

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

ＯＳ上に実装するコントローラアプリケーションの設計及び検証を完全に行うことでメモリリークのような問題の発生は回避できる。実際、コントローラアプリケーションの作成時には、多くの時間・工数を費やして詳細な設計と検証とを行っている。

しかし、ＯＳ上で動作するのはコントローラアプリケーションに限定されない。制御装置１０は、コントローラ以外のアプリケーションがインストールされて、動作を実行することがある。コントローラ以外のアプリケーションの一例として、センサや駆動装置や工業プロセス自体の情報を収集して劣化や異常が発生していないかを判定する診断機能等のアプリケーションなどが挙げられる。制御装置１０上で動作する診断アプリケーション等の全てに対して、コントローラアプリケーションと同等の綿密な設計及び検証を施すことは、投資対効果の観点より困難である。

さらに、ＯＳ自体に起因してコントローラアプリケーションの動作が滞ることもある。例えば、ＯＳ自体の脆弱性改善のためのパッチや更新を行う場合には、一時的にＯＳの動作が停滞したり、ＯＳの再起動が求められたりすることがある。すなわち、単にＯＳを導入し、その上で複数のコントローラアプリケーションを動作させるだけでは課題解決には不十分である。

そこで、本開示では、信頼性を高めつつ、コストを抑制する制御システムについて、説明する。

図２は、本開示に係る制御システムの概念図である。図２に示すように、制御システム２は、１台の制御装置１１０と、入力装置１２１と、出力装置１３１とを備える。制御システム２は、例えばプラントの工業プロセスの制御等に使用される。

制御装置１１０は、例えばコンピュータ装置により構成される。制御装置１１０は、ハードウェア１１１を備える。ハードウェア１１１は、例えばＣＰＵやメモリ等で構成される。

制御装置１１０は、ハードウェア１１１上で動作するアプリケーション間干渉防止処理部１１９と、選択処理部１１５とを備える。制御装置１１０は、アプリケーション間干渉防止処理部１１９上で動作する複数のコントローラ１１４−１乃至１１４−ｎを有する。ｎは、２以上の整数であってよい。また、図２には、アプリケーション間干渉防止処理部１１９上で動作するコントローラ以外のアプリケーションとしてＡＰＰ−Ａ、ＡＰＰ−Ｂ、・・・ＡＰＰ−Ｚを記載している。コントローラ以外のアプリケーションであるＡＰＰ−Ａ、ＡＰＰ−Ｂ、・・・ＡＰＰ−Ｚは、高い信頼性が求められる用途のアプリケーションではなく、それゆえにコントローラに比べて動作検証が不十分な可能性があるアプリケーションである。ＡＰＰ−Ａ、ＡＰＰ−Ｂ、・・・ＡＰＰ−Ｚは、複数をとりまとめてアプリケーション群として１１８−１、１１８−２、・・・１１８−ｎと記載している。

制御装置１１０は、アプリケーション間干渉防止処理部１１９と選択処理部１１５により、コントローラの不具合が発生した場合であっても、正常な制御動作を行うことができる。アプリケーション間干渉防止処理部１１９は、多様な態様で実現し得る。アプリケーション間干渉防止処理部１１９は、例えば、ハードウェアにて動作するＯＳと、ＯＳにて動作するゲストＯＳによりコントローラアプリケーションを動作させてよい。アプリケーション間干渉防止処理部１１９は、例えば、ハードウェアにて仮想ハードウェアによりコントローラアプリケーションを動作させてもよい。アプリケーション間干渉防止処理部１１９は、例えば、ハードウェアにて動作するＯＳと、ＯＳにて動作するコンテナによりコントローラアプリケーションを動作させてもよい。上述したゲストＯＳ、仮想ハードウェア、及びコンテナの数量は、適宜定められてよく、例えば以下の実施形態において説明するように、多数決により出力値が選択される場合には、３以上であってよい。以下、アプリケーション間干渉防止処理部１１９の具体的な態様も含め、本開示に係る制御システムの実施形態について説明する。

（第１実施形態）
図３は、第１実施形態に係る制御システムを示す概略図である。第１実施形態に係る制御システム３は、１台の制御装置２１０と、入力装置１２１と、出力装置１３１とを備える。制御システム３は、例えばプラントの工業プロセスの制御等に使用される。

制御装置２１０は、ネットワークに接続される。センサ１２０は工業プロセスに設けられ、測定対象の物理量は測定信号として入力装置１２１からネットワーク経由で、制御装置２１０に入力される。制御装置２１０は、入力された測定信号に基づいて、例えば所定の演算処理を行い、ネットワーク経由で演算結果に応じた制御信号を出力装置１３１に出力する。駆動装置１３０は、出力装置１３１から制御信号の入力を受け付けると、制御信号に応じて工業プロセスを駆動する。

制御装置２１０は、例えばコンピュータ装置により構成される。制御装置２１０は、ハードウェア１１１を備える。ハードウェア１１１は、例えばＣＰＵやメモリ等で構成される。

制御装置２１０は、ハードウェア１１１上で動作するＯＳ１１２と、ＯＳ１１２上で動作する複数のゲストＯＳ１１３−１乃至１１３−ｎと、複数のゲストＯＳ１１３−１乃至１１３−ｎ上でそれぞれ動作する複数のコントローラ１１４−１乃至１１４−ｎとを有する。また、図３にはゲストＯＳ上で動作するコントローラ以外のアプリケーションとしてＡＰＰ−Ａ、ＡＰＰ−Ｂ、・・・ＡＰＰ−Ｚを記載している。なお、ＡＰＰ−Ａ、ＡＰＰ−Ｂ、・・・ＡＰＰ−Ｚは、後述するコントローラ１１４−１乃至１１４−ｎが演算により算出する値の出力するタイミングを制御してもよい。ＯＳ１１２は、複数のゲストＯＳ１１３−１乃至１１３−ｎのホストＯＳとして機能する。以下、本明細書において、ゲストＯＳのそれぞれを区別しない場合には、まとめてゲストＯＳ１１３と記載する。同様に、本明細書において、コントローラのそれぞれを区別しない場合には、まとめてコントローラ１１４と記載する。同様に、本明細書において、アプリケーション群のそれぞれを区別しない場合には、まとめてアプリケーション群１１８と記載する。

各コントローラ１１４は、入力された測定信号に基づき、駆動装置１３０に対して適用されるべき値を算出する。各コントローラ１１４は、例えば、入力された測定信号について、所定のアルゴリズムで演算処理を行い、演算結果を出力する。

制御装置２１０は、さらにハードウェア１１１上で動作する選択処理部１１５を有する。なお、本明細書では、選択制御部１１５がハードウェア１１１上で動作するとして説明するが、選択制御部１１５は、ＯＳ１１２上で動作してもよい。本実施形態において、選択処理部１１５は、ソフトウェアにより構成されている。この場合、選択処理部１１５は、例えば、専用のファームウェアで構築されていてよい。選択処理部１１５は、各コントローラ１１４が算出した演算値に基づいて、１つの出力値を選択する。すなわち、各コントローラ１１４により算出された演算値は、選択処理部１１５に入力される。選択処理部１１５は、各コントローラ１１４から出力された演算値に基づいて、１つの出力値を選択し、当該出力値を出力する。制御装置２１０は、出力値に基づく制御信号を出力する。制御信号は、出力装置１３１から駆動装置１３０に入力される。駆動装置１３０は、制御信号に応じてプロセスを操作する。

選択処理部１１５は、任意の適切な方法で、１つの出力値を選択してよい。選択処理部１１５は、例えば、各コントローラ１１４から入力された演算値のいずれか１つを出力値として選択することができる。

選択処理部１１５は、各コントローラ１１４から出力された演算値に基づいて、多数決により出力値を選択するように構成されていてもよい。この場合、選択処理部１１５は、各コントローラ１１４から出力された演算値のうち、同一の値が最も多く出力された演算値を出力値として選択する。あるいは、選択処理部１１５は、複数のコントローラ１１４から出力された演算値のうち、同一の値が半数以上のコントローラ１１４から出力された演算値を、出力値として選択してもよい。すなわち、選択処理部は、複数のコントローラ１１４から出力された演算値のうち、同一の値が過半数となる演算値を、出力値として選択してもよい。

選択処理部１１５が多数決により出力値を選択するように構成される場合、制御装置２１０は、コントローラ１１４及びゲストＯＳ１１３を３以上有していてよい。例えば、制御装置２１０が３つのコントローラ１１４−１、１１４−２及び１１４−３を有する場合、選択処理部１１５は、３つのコントローラ１１４−１、１１４−２及び１１４−３からそれぞれ出力された演算値を取得する。選択処理部１１５は、例えば、いずれか２つのコントローラが同一の演算値を出力し、他の１つのコントローラが別の演算値を出力している場合、２つのコントローラが出力した演算値が最も多く出力された演算値であるため、当該演算値を出力値として選択する。

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

このように、制御装置２１０は、選択処理部１１５において、各コントローラ１１４から入力された演算値に基づいて１つの出力値を選択することにより、例えば複数のゲストＯＳ１１３の一部又は複数のコントローラ１１４の一部にエラーが発生している場合であっても、正常な出力値を継続して出力し得る。例えば、選択処理部１１５が多数決により出力値を選択するように構成されている場合、エラーが発生していないコントローラ１１４から出力された演算値が、出力値として選択されうる。そのため、複数のコントローラ１１４の一部にエラーが発生しても、制御装置２１０から正常な出力が継続され、駆動装置１３０が正常に駆動されうる。

また、制御装置２１０によれば、コントローラ１１４やアプリケーション群１１８の不具合に起因して、一部のコントローラ１１４や一部のゲストＯＳ１１３の動作が不安定になった場合であっても、ＯＳの動作により他のゲストＯＳに動作に影響を与えない。

また、本実施形態に係る制御システム３は、制御装置２１０内の複数のコントローラ１１４において演算値を算出し、選択処理部１１５により演算値に基づいて出力値が選択される。つまり、制御システム３では、１台の制御装置２１０によりコントローラアプリケーションの冗長化を図ることができる。従って、制御システム３は、特許文献１に開示されたシステムと異なり、冗長化のために複数の制御装置を必要とするものではない。そのため、制御システム３によれば、特許文献１と比較して、制御装置というハードウェアの数量を減らすことができるという点において、コストを低減することができる。

ここで、コストの決定要因としては制御装置の台数が支配的である。例えば、制御装置のもつ演算能力やメモリ容量をｎ倍にしても、そのコストはｎ倍にはならず１からｎの間で１倍に近い値になる。また、ライセンス料等の支払いが必要でなければ、一つの制御装置に同じコントローラアプリケーションを複数インストールしてもそのコストは増加しない。そのため、本実施形態に係る制御システム３によれば、複数の制御装置を用いて冗長化を行う場合と比較して、低コストで冗長化を実現可能である。

また、本実施形態に係る制御システム３は、１台のハードウェア１１１上に複数のコントローラ１１４を有するように構成されているため、入力装置１２１から制御装置２１０に入力された測定信号を、全てのコントローラ１１４に均一に入力することができる。つまり、例えば、センサ１２０がある時間に測定した値に関する測定信号が、センサ１２０から制御装置２１０に入力される場合、１台の制御装置２１０に入力されるため、ネットワークの遅延等にかかわらず、同一の測定信号が１台のハードウェア１１１上のコントローラ１１４に入力される。

また、本実施形態に係る制御システム３は、１台のハードウェア１１１上に複数のコントローラ１１４を有するように構成されている。そのため、例えばネットワーク上に複数の制御装置が分散して配置された構成を有するシステムと比較して、ネットワークのデータ通信量を低減することができる。つまり、例えば、入力装置１２１からの測定信号を制御装置に送信する場合、ネットワーク上に複数の制御装置が分散して配置された構成を有するシステムでは、複数の制御装置に対して、ネットワークを介してそれぞれ測定信号が送信される。これに対し、本実施形態に係る制御システム３では、１台の制御装置２１０に測定信号を送信すれば足りる。このように、本実施形態に係る制御システム３では、通信量を低減することができる。その結果、ネットワークの輻輳に起因する信号の送受信の遅延を防止することができるため、制御システム３は、リアルタイム性が重視されるアーキテクチャ環境における制御システムの実現に寄与し得る。

（第２実施形態）
図４は、第２実施形態に係る制御システムを示す概略図である。第２実施形態に係る制御システム４は、１台の制御装置３１０と、入力装置１２１と、出力装置１３１と、選択処理装置３２０とを備える。制御システム４は、例えばプラントの工業プロセスの制御等に使用される。図４において、制御システム４が備える各機能部のうち、図３に示す制御システム３が備える機能部と同一の構成及び機能を有する機能部については、同一の符号を付している。以下、第１実施形態と同様の点については、適宜説明を省略し、異なる点を中心に説明する。

図４に示すように、第２実施形態に係る制御システム４においては、選択処理装置３２０が、制御装置３１０から独立した別の装置として構成されている。選択処理装置３２０は、ネットワークに接続される。本実施形態において、制御装置３１０は、各コントローラ１１４から、演算結果としての演算値を出力する。選択処理装置３２０は、出力された演算値を、ネットワークを介して取得する。選択処理装置３２０は、各コントローラ１１４から出力された演算値に基づいて、１つの出力値を選択する。選択処理装置３２０は、出力値に基づく制御信号を出力する。制御信号は、出力装置１３１から駆動装置１３０に入力される。駆動装置１３０は、制御信号に応じて駆動する。この場合も、上述した第１実施形態に係る制御システム３と同様の理由で、一部のコントローラ１１４やアプリケーション群１１８の不具合に起因して、一部のゲストＯＳ１１３の動作が不安定になった場合であっても、正常な制御動作を行うことが可能である。また、本実施形態では、ハードウェア１１１の処理負荷を軽減し得る。

なお、選択処理装置３２０は、出力装置１３１内に構成されていてもよい。

上記各実施形態における制御装置は、２台以上のコントローラ１１４を有していればよい。選択処理部１１５及び選択処理装置３２０が多数決により出力値を選択するように構成される場合、制御装置２１０および３１０は、３以上のコントローラ１１４及びゲストＯＳ１１３を有していればよい。コントローラ１１４の個数が多いほど、不具合が発生したコントローラ１１４の個数が増加しても、制御装置から正常な出力値を出力し続けやすくなるため、信頼性が向上する。コントローラ１１４の個数が多いほど、一部のコントローラ１１４にエラーが発生してから、回復措置を講じるまでの時間的な猶予を、より長くとることができる。これにより、コントローラ１１４の個数が多いほど、制御システムのユーザ及び管理者等にとって利便性が高まる。

例えば、選択処理部１１５が多数決により出力値を選択するように構成され、複数のコントローラ１１４から出力された演算値のうち、同一の値が半数以上のコントローラ１１４から出力された演算値を、出力値として選択するとする。この場合、回復措置を講じるまでの時間は、複数のコントローラ１１４の全体の個数の半分にエラーが発生するまでの時間となる。この時間内では、同一の値が半数以上のコントローラ１１４から出力された演算値を、出力値として選択するという処理を実行することができるため、制御システムのユーザ又は管理者等は、この時間内に回復措置を講じればよい。従って、この時間までは、一部のコントローラ１１４にエラーが発生したとしても、制御システムを継続して稼働させることができる。

制御装置２１０及び３１０が有するコントローラ１１４の個数は、適宜定められてよい。制御装置２１０及び３１０が有するコントローラ１１４の個数は、例えば制御システム３及び４のユーザの入力操作等に基づく外部からの入力に応じて、適宜定められてよい。これにより、例えばユーザ等は、制御システム３又は４が適用される工業プロセスの使用条件（例えば求められる信頼性）等に応じて、コントローラ１１４の個数を変更することができる。

上記各実施形態において、選択処理部１１５又は選択処理装置３２０が、出力値を選択する際に、当該出力値とは値が異なる演算値を出力したコントローラ１１４を特定してよい。出力値とは値が異なる演算値を出力したコントローラ１１４は、エラーが発生している可能性があると言えるため、このように特定する処理を行うことにより、エラーが発生している可能性があるコントローラ１１４を特定することができる。

ＯＳ１１２は、上述のようにして特定されたコントローラ１１４を再起動する処理を実行してよい。特定されたコントローラ１１４を再起動することにより、コントローラ１１４において発生しているエラーを解消し得る。このように、エラーの解消は、再起動というソフトウェア的な処理で実現され得る。

コントローラ１１４がエラーを生じていない状態でも、意図的に停止や再起動を行ってもよい。コントローラプログラムの更新、ゲストＯＳへのセキュリティーパッチの適用や更新等では一般にコントローラの動作が滞ったり、再起動が必要となったりすることがある。過半数未満のコントローラプログラムやゲストＯＳに対して順番に更新作業を行うことで、制御システム全体としては動作を維持することができる。

再起動する処理は、外部からの操作入力に基づいて実行されてもよい。つまり、例えばユーザ又は管理者等が、制御装置２１０若しくは３１０、又は他の装置に対して、特定されたコントローラ１１４を再起動するための操作入力を行い、コントローラ１１４又はゲストＯＳ１１３は、当該操作入力に基づいて再起動する処理を実行してもよい。例えば、ユーザ又は管理者は、制御装置２１０又は３１０と通信可能に接続された他の装置に対して、コントローラ１１４を再起動するための操作入力を行うことによって、再起動を実行させることができる。例えば、制御装置２１０又は３１０が、ユーザ又は管理者等が常駐する場所から離れた位置にあるとしても、当該他の装置が、当該ユーザ又は管理者等が常駐する場所にある場合には、ユーザ又は管理者は、制御装置２１０又は３１０の設置位置まで実際に行くことなく、遠隔に位置する他の装置を介した通信によって、エラーの不具合を解消し得る。そのため、ユーザ又は管理者等にとって、利便性が高まる。

ＯＳ１１２は、上述のようにして特定されたコントローラ１１４を、それぞれ予備のコントローラに差し替える処理を実行してよい。ここで、予備のコントローラは、複数のコントローラ１１４のうち使用されていないコントローラをいう。例えば、制御装置２１０又は３１０は、複数のコントローラ１１４のうち、いずれのコントローラ１１４にもエラーが発生していない場合には、使用されていない（つまり情報処理を実行していない）コントローラを備える。いずれかのコントローラ１１４にエラーが発生することにより、当該コントローラ１１４が上述の処理によって特定された場合、ＯＳ１１２は、当該特定されたコントローラ１１４を、予備のコントローラに差し替えてよい。差替えを行うことにより、エラーが発生している可能性のあるコントローラ１１４に代えて、予備のコントローラを使用するため、制御装置２１０又は３１０から出力される出力値の正確性が維持されやすくなる。そのため、信頼性を向上可能である。

ＯＳ１１２は、特定されたコントローラ１１４を、それぞれ予備のコントローラに差し替える処理を実行する場合、特定されたコントローラ１１４に関する情報を、それぞれ差替え先である予備のコントローラに反映させてよい。この場合、ゲストＯＳ１１３上にコントローラアプリケーション以外のアプリケーションが実装されている場合、当該コントローラアプリケーション以外のアプリケーションに関する情報も反映させてよい。例えば、制御装置２１０又は３１０が工業プロセスの制御のための処理を行う過程で、コントローラ１１４で実行する処理で用いられるパラメータ又は設定値等のコントローラ１１４に関する情報が、初期値から変更されている場合がある。この場合、特定されたコントローラ１１４に関する情報、つまり変更された情報を、差替え先である予備のコントローラに反映させることによって、予備のコントローラに継承することができる。これにより、コントローラ１１４の差替え前後で、同一の条件で処理を継続することができる。その結果、信頼性を向上可能である。このような、特定されたコントローラ１１４に関する情報は、コントローラ１１４が有していてもよく、制御システム３又は４において、任意の場所に格納されていてもよい。

コントローラ１１４に対し、再起動したり、予備のコントローラに差し替えたりする等、所定の処理を実行した場合、当該処理の対象となったコントローラに関する情報又は当該実行された処理に関する情報は、制御装置２１０又は３１０が備える表示部に表示されてよい。当該処理の対象となったコントローラに関する情報又は当該実行された処理に関する情報は、制御装置２１０若しくは３１０と、ネットワークを介して通信可能に接続された外部の装置が備える表示部に表示されてもよい。このように、当該処理の対象となったコントローラに関する情報又は実行された処理に関する情報が表示される場合、ユーザ又は管理者等は、当該表示を確認することによって、処理の対象となったコントローラ１１４に関する情報又はコントローラ１１４に対して実行された処理を知ることができる。

ＯＳ１１２は、特定されたコントローラ１１４からエラーの発生に関する情報（以下、単に「エラー情報」とも言う）が出力されている場合、当該エラー情報を保存したり、当該エラー情報を用いて様々な処理を行ったりしてよい。エラー情報は、例えば、エラーの発生を示す情報、及びエラー発生時のコントローラ１１４の設定を示す情報等を含んでよい。ＯＳ１１２は、エラー情報を、例えば制御装置２１０又は３１０内の記憶領域に保存してよい。ＯＳ１１２は、エラー情報を、例えば制御装置２１０又は３１０の外部の装置に保存してもよい。エラー情報を保存することにより、過去のエラー情報を蓄積することができる。また、ＯＳ１１２は、エラー情報を用いて様々な処理を行うことができる。ＯＳ１１２は、例えばエラー情報を分析する処理を行うことができる。具体的には、ＯＳ１１２は、例えばコントローラ１１４が実行した演算処理等を分析することができる。これにより、エラーが発生した原因又は状況等を調査することができる。分析の結果の情報は、上述したコントローラ１１４の差替えの際に、差替え先である予備のコントローラに反映されてよい。すなわち、分析の結果の情報は、予備のコントローラに継承されてよい。予備のコントローラは、継承された情報を参照して、同様のエラーが発生しないように演算処理を実行してよい。

上記各実施形態では、制御装置２１０及び３１０が、センサ１２０により出力された測定信号を、入力装置１２１を介して取得し、制御信号を出力装置１３１を介して駆動装置１３０に出力すると説明した。しかしながら、制御装置における信号の入出力は、必ずしも入力装置１２１及び出力装置１３１により行われなくてもよい。

例えば、制御システム３及び４は、入力装置１２１及び出力装置１３１に代えて、入力装置１２１及び出力装置１３１の双方の機能を有する入出力装置を備えていてもよい。この場合、当該入出力装置を介して測定信号が制御装置２１０又は３１０に入力され、当該入出力装置を介して制御信号が制御装置２１０又は３１０から駆動装置１３０に出力される。

また、例えば、制御システムは、必ずしも入力装置１２１及び出力装置１３１を備えなくてもよい。例えば、図５に一例として概略的に示すように、制御システム５は、ネットワークを介して互いに通信可能に接続された、制御装置４１０と、センサ１２０と、駆動装置１３０とを備える。図５に示す制御システム５では、制御装置４１０が、ＯＳ１１２上に、信号の入力処理を実行する入力部４２１と、信号の出力処理を実行する出力部４３１とを有する。制御装置４１０は、入力部４２１を介して、センサ１２０から出力された測定信号の入力を受け付け、出力部４３１を介して、制御装置４１０からの制御信号を駆動装置１３０に出力する。

また、例えば、制御システムは、必ずしも複数のゲストＯＳ１１３を有していなくてもよい。例えば、図６に一例として概略的に示すように、制御システム６は、ネットワークを介して互いに通信可能に接続された、制御装置５１０と、センサ１２０と、駆動装置１３０とを備える。図６に示す制御装置５１０は、ハードウェア１１１上で動作するＯＳ１１２及び選択処理部１１５を有する。図６に示す制御装置５１０は、第１実施形態に係る制御装置２１０と異なり、コンテナ技術により、ＯＳ１１２上に構成される複数のコンテナ１１６−１乃至１１６−ｎを有する。本明細書において、コンテナのそれぞれを区別しない場合には、まとめてコンテナ１１６と記載する。各コンテナ１１６−１乃至１１６−ｎは、それぞれコントローラ１１４−１乃至１１４−ｎを有する。コントローラ１１４は、専用領域として設けられたコンテナ１１６内で、第１実施形態において説明した場合と同様に、入力された測定信号に基づいて、駆動装置１３０に対して適用されるべき値を算出し、演算結果としての演算値を出力する。そして、選択処理部１１５が各コントローラ１１４から出力された演算値に基づいて１つの出力値を選択し、当該出力値を出力する。このようにして、制御システム６においても、一部のコントローラ１１４に不具合が発生した場合であっても、正常な制御動作を行うことが可能である。

なお、図６に示す制御システム６において、制御装置５１０は、ＯＳ１１２上に、コンテナ１１６とは異なる更なるコンテナを備え、当該更なるコンテナ上で、コントローラ以外のアプリケーション（つまり、上述したＡＰＰ−Ａ、ＡＰＰ−Ｂ、・・・ＡＰＰ−Ｚ）を動作させてもよい。この場合、更なるコンテナのそれぞれは、コントローラ以外のアプリケーションのそれぞれに１対１で対応していてよい。つまり、制御装置５１０のＯＳ１１２上には、コントローラ以外のアプリケーションと同数の更なるコンテナが設けられていてよい。

また、例えば、図７に一例として概略的に示すように、制御システム７は、ネットワークを介して互いに通信可能に接続された、制御装置６１０と、センサ１２０と、駆動装置１３０とを備える。図７に示す制御装置６１０は、第１実施形態に係る制御装置２１０と異なり、ハードウェア１１１上に複数の仮想ハードウェア１１７−１乃至１１７−ｎが構成される。本明細書において、仮想ハードウェアのそれぞれを区別しない場合には、まとめて仮想ハードウェア１１７と記載する。制御装置６１０は、各仮想ハードウェア１１７上で動作する複数のゲストＯＳ１１３−１乃至１１３−ｎと、複数のゲストＯＳ１１３−１乃至１１３−ｎ上でそれぞれ動作する複数のコントローラ１１４−１乃至１１４−ｎとを有する。コントローラ１１４は、第１実施形態において説明した場合と同様に、入力された測定信号に基づいて、駆動装置１３０に対して適用されるべき値を算出し、演算結果としての演算値を出力する。そして、選択処理部１１５が各コントローラ１１４から出力された演算値に基づいて１つの出力値を選択し、当該出力値を出力する。このようにして、制御システム７においても、一部のコントローラ１１４に不具合が発生した場合であっても、正常な制御動作を行うことが可能である。

上記各実施形態及び変形例において、ＯＳ１１２、コンテナ１１６及び仮想ハードウェア１１７が、その上で動作するゲストＯＳ１１３、コントローラ１１４又はアプリケーション群１１８に割り当てるリソースは、異なる値に設定されていてもよい。これにより、メモリリークが発生する場合であっても、メモリリークによる不具合発生のタイミングをずらすことができる。たとえばゲストＯＳ１１３−１に対して、ゲストＯＳ１１３−２は１．１倍、ＯＳ１１３−３は１．３倍、ＯＳ１１３−４は１．７倍等のメモリ容量を割り当てておけば、コントローラに起因するメモリリークによって各ゲストＯＳのメモリ資源が同じぺースで浪費されたとしても、それぞれのゲストＯＳのメモリリソースが枯渇して動作不能となり再起動されるタイミングは重複しない。すなわち制御システム全体としての動作は継続することが期待される。

以上、本発明の実施形態について、図面を参照して説明してきたが、具体的な構成はこの実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲においての種々の変更も含まれる。

１、２、３、４、５、６、７ 制御システム
１０、１１０、２１０、３１０、４１０、５１０、６１０ 制御装置
２０、１２０ センサ
２１、１２１ 入力装置
３０、１３０ 駆動装置
３１、１３１ 出力装置
１１１ ハードウェア
１１２ ＯＳ
１１３ ゲストＯＳ
１１４ コントローラアプリケーション
１１５ 選択処理部
１１６ コンテナ
１１７ 仮想ハードウェア
１１８ アプリケーション群
１１９ アプリケーション間干渉防止処理部
３２０ 選択処理装置
４２１ 入力部
４３１ 出力部

Claims (16)

1. ハードウェアと、
   前記ハードウェア上にて動作するアプリケーション間干渉防止処理部と、
   前記アプリケーション間干渉防止処理部上で動作する複数のコントローラアプリケーションと、
   選択処理部と、
   を有し、
   前記コントローラアプリケーションのそれぞれは、入力値に対して所定の演算を実行し、演算結果としての演算値を出力し、
   前記選択処理部は、前記コントローラアプリケーションのそれぞれから出力された演算値に基づいて、１つの出力値を選択し、前記出力値を出力する、
   制御システム。
2. 前記コントローラアプリケーションを３以上有し、
   前記選択処理部は、前記コントローラアプリケーションのそれぞれから出力された演算値のうち、同一の値が最も多い演算値、又は、前記コントローラアプリケーションのそれぞれから出力された演算値のうち、同一の値が過半数となる演算値を、前記出力値として選択する、
   請求項１に記載の制御システム。
3. 前記コントローラアプリケーションの個数は、設定可能である、請求項１乃至請求項２のいずれか一項に記載の制御システム。
4. 前記入力値は、入力装置から前記コントローラアプリケーションに入力され、前記出力値は、前記選択処理部から出力装置に出力される、請求項１乃至請求項３のいずれか一項に記載の制御システム。
5. 前記選択処理部は、前記アプリケーション間干渉防止処理部が動作するハードウェアとは異なるハードウェアに構成される、請求項１乃至請求項４のいずれか一項に記載の制御システム。
6. 前記出力値とは値が異なる演算値を出力したコントローラアプリケーションを特定する、請求項１乃至請求項５のいずれか一項に記載の制御システム。
7. 前記特定したコントローラアプリケーションを再起動する処理を実行する、請求項６に記載の制御システム。
8. 前記再起動する処理は、外部からの操作入力に基づいて実行される、請求項７に記載の制御システム。
9. 前記特定したコントローラアプリケーションを、予備のコントローラアプリケーションに差し替える処理を実行する、請求項６に記載の制御システム。
10. 前記差し替える処理は、前記特定したコントローラアプリケーションに関する情報を、前記予備のコントローラアプリケーションに反映させる処理を含む、請求項９に記載の制御システム。
11. 前記特定したコントローラアプリケーションに関する情報又は前記特定したコントローラアプリケーションについて実行した処理に関する情報を、外部の装置に出力し、又は表示部に表示する、請求項６乃至請求項１０のいずれか一項に記載の制御システム。
12. 前記特定したコントローラアプリケーションに関するエラー情報が出力された場合、前記エラー情報の保存及び／又は前記エラー情報の分析を実行する、請求項６乃至請求項１１のいずれか一項に記載の制御システム。
13. 前記コントローラアプリケーションに割り当てられるリソースが異なる値に設定された、請求項１乃至請求項１２のいずれか一項に記載の制御システム。
14. 前記アプリケーション間干渉防止処理部は、前記ハードウェアにて動作するＯＳと、前記ＯＳにて動作する少なくとも３以上のゲストＯＳにより前記コントローラアプリケーションを動作させる、又は、前記ハードウェアにて少なくとも３以上の仮想ハードウェアにより前記コントローラアプリケーションを動作させる、請求項１乃至請求項１３のいずれか一項に記載の制御システム。
15. 前記アプリケーション間干渉防止処理部は、前記ハードウェアにて動作するＯＳと、前記ＯＳにて動作する少なくとも３以上のコンテナにより前記コントローラアプリケーションを動作させる、請求項１乃至請求項１３のいずれか一項に記載の制御システム。
16. ハードウェアと、
    前記ハードウェア上にて動作するアプリケーション間干渉防止処理部と、
    前記アプリケーション間干渉防止処理部上で動作する複数のコントローラアプリケーションと、
    選択処理部と、
    を有し、
    前記コントローラアプリケーションのそれぞれは、入力値に対して所定の演算を実行し、演算結果としての演算値を出力し、
    前記選択処理部は、前記コントローラアプリケーションのそれぞれから出力された演算値に基づいて、１つの出力値を選択し、前記出力値を出力する、
    制御装置。

Images