図面 (/)

技術 ハードウェア要素を遠隔制御するための制御システムおよび方法

出願人 カタール・ファウンデーション
発明者 タミルエー.ヘガジー
出願日 2013年4月26日 (8年6ヶ月経過) 出願番号 2015-556405
公開日 2016年6月30日 (5年3ヶ月経過) 公開番号 2016-519344
状態 特許登録済
技術分野 フィードバック制御一般 制御系の安全装置 選択的呼出装置(遠隔制御・遠隔測定用) 電話通信サービス
主要キーワード 連続的制御 副コントローラ リセット事象 演算機器 発明提案 直接デジタル制御 定常状態誤差 遅延補償器
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年6月30日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (16)

課題・解決手段

制御システムは、第1および第2のハードウェア要素と、それらハードウェア要素から遠隔に配置されるサーバとを含む。サーバは、インターネットを介してハードウェア要素に接続されたクラウド内のサーバである。サーバで実行されるサービスとして制御モジュール実装し、制御モジュールは、ハードウェア要素と通信してハードウェア要素のうちの少なくとも1つを制御するように動作することができる。

概要

背景

デジタルコンピュータが最初に制御システムで使用されたのは1960年前後であった。以降、制御システムは演算機器の進歩に伴って発展してきた。今日では、オートメーション・システムは、演算および通信を行う数個の階層を伴う多層構造アーキテクチャである。オートメーションは、直接的で自動的な制御に加えて、モニタリング監視制御、警報管理、履歴化、プラント・レベルの管理、企業レベルアプリケーションなど、他の高レベルの機能を提供していることから、今日オートメーションが意味するものは自動的な制御を越えている。

既存技術を使用する大規模なオートメーション計画は非常に高費用で時間を要する事業である。そのような事業は、多大な人的技術労力に加えて、大量のハードウェアおよびソフトウェアを必要とする。オートメーションの初期費用はしばしば数千万ドルに達する。また、別のオートメーション提供者への切り換えは、既存のオートメーション・システムに行われた多大な投資のために通常は避けられる。費用を別にしても、オートメーション・システム全体を配備し直すことは、特に稼働中のプラントの場合は極めて時間を要する。

概要

制御システムは、第1および第2のハードウェア要素と、それらハードウェア要素から遠隔に配置されるサーバとを含む。サーバは、インターネットを介してハードウェア要素に接続されたクラウド内のサーバである。サーバで実行されるサービスとして制御モジュール実装し、制御モジュールは、ハードウェア要素と通信してハードウェア要素のうちの少なくとも1つを制御するように動作することができる。

目的

本発明は、改良された制御システムおよび方法を提供する

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

制御システムであって、第1のハードウェア要素と、第2のハードウェア要素と、該ハードウェア要素から遠隔に配置されるサーバであって、前記ハードウェア要素が前記サーバと通信状態にあり、前記ハードウェア要素と前記サーバとの間で現場レベルプロトコルを使用してデータを通信することができる、サーバと、該サーバで実行されるサービスとして実装される主制御モジュールであって、前記制御システム内の直接制御層の一部を形成し、前記現場レベルのプロトコルを使用して前記ハードウェア要素と通信して前記ハードウェア要素のうちの少なくとも1つを制御するように動作することができる主制御モジュールとを備える制御システム。

請求項2

前記主制御モジュールが、前記ハードウェア要素のうちの少なくも1つを連続的に制御するように動作することができる直接連続制御モジュールである請求項1に記載の制御システム。

請求項3

前記主制御モジュールが、直接デジタル制御モジュールである請求項1または請求項2に記載の制御システム。

請求項4

前記ハードウェア要素の1つが、センサである請求項1から請求項3のいずれか一項に記載の制御システム。

請求項5

前記ハードウェア要素の1つが、アクチュエータである請求項1から請求項4のいずれか一項に記載の制御システム。

請求項6

前記第1および第2のハードウェア要素が、単一のハードウェア装置統合される請求項1から請求項5のいずれか一項に記載の制御システム。

請求項7

前記主制御モジュールが、前記サーバでサービスとして実行されるアルゴリズムを備える請求項1から請求項6のいずれか一項に記載の制御システム。

請求項8

前記ハードウェア要素が、伝送制御プロトコル(TCP)の上で実行される現場レベルのプロトコルを使用して前記サーバと通信する請求項1から請求項7のいずれか一項に記載の制御システム。

請求項9

前記ハードウェア要素が、Modbus/TCPおよびProfibus/TCPからなる群から選択されるプロトコルを使用して前記サーバと通信する請求項8に記載の制御システム。

請求項10

前記ハードウェア要素が、インターネットを介して前記サーバと通信する請求項1から請求項9のいずれか一項に記載の制御システム。

請求項11

前記サーバが、クラウドの一部を形成するサーバである請求項1から請求項10のいずれか一項に記載の制御システム。

請求項12

前記ハードウェア要素のうちの少なくとも1つが、直接前記クラウドに接続される請求項1から請求項11のいずれか一項に記載の制御システム。

請求項13

前記ハードウェア要素のうちの少なくとも1つが、ローカルエリアネットワークを介して前記クラウドに接続される請求項1から請求項11のいずれか一項に記載の制御システム。

請求項14

前記ハードウェア要素のうちの少なくとも1つが、ゲートウェイ・サーバを介して前記クラウドに接続される請求項1から請求項11のいずれか一項に記載の制御システム。

請求項15

前記ゲートウェイ・サーバが、前記ハードウェア要素と同じ建物の中に位置する請求項14に記載の制御システム。

請求項16

前記サーバと通信状態にあり、ユーザが前記サーバと対話して前記主制御モジュールを監視および制御できるようにするユーザ・インターフェースを備える請求項1から請求項15のいずれか一項に記載の制御システム。

請求項17

前記ユーザ・インターフェースが、サービスとしてのプラットフォーム(PaaS)またはサービスとしてのシステム(SaaS)として実装される請求項16に記載の制御システム。

請求項18

前記ハードウェア要素が、プロセス変量を出力し、前記プロセス変量を前記主制御モジュールの入力に伝達するフィードバックループと、前記プロセス変量を遅延補償値によって修正して、前記主制御モジュールと前記ハードウェア要素との間の通信の遅延補償する遅延補償モジュールとを備える、請求項1から請求項17のいずれか一項に記載の制御システム。

請求項19

前記プロセス変量を受け取る第1の入力および基準値を受け取る第2の入力とを含む比較装置を備え、該比較装置は、前記プロセス変量を前記基準値と比較し、前記主制御モジュールの入力に比較値を出力し、前記遅延補償モジュールは、前記プロセス変量または誤差値を前記遅延補償値によって修正する、請求項18に記載の制御システム。

請求項20

前記遅延補償モジュールは、前記主制御モジュールと前記ハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延に一致するように前記遅延補償値を選択する請求項18または請求項19に記載の制御システム。

請求項21

前記遅延補償モジュールは、前記主制御モジュールと前記ハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延と等しくなるように前記遅延補償値を選択する請求項18または請求項19に記載の制御システム。

請求項22

前記遅延補償モジュールが、スミス予測器である請求項18から請求項21のいずれか一項に記載の制御システム。

請求項23

前記スミス予測器が、前記プロセス変量に代えてプロセス誤差を遅延補償値によって修正して、前記主制御モジュールと前記ハードウェア要素との間の通信の遅延を補償する請求項22に記載の制御システム。

請求項24

前記主制御モジュールと前記ハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延を推定するように動作することが可能な遅延推定モジュールを備える請求項18から請求項23のいずれか一項に記載の制御システム。

請求項25

前記遅延推定モジュールが、指数重み付き移動平均の計算を使用して前記遅延を推定する請求項24に記載の制御システム。

請求項26

前記遅延推定モジュールが、指数重み付き移動分散の計算を使用して遅延の分散を推定する請求項24に記載の制御システム。

請求項27

前記遅延補償モジュールが、所定の時間にわたって前記プロセス変量を次第に修正する請求項18から請求項26のいずれか一項に記載の制御システム。

請求項28

前記サーバで実行されるサービスとして実装される副制御モジュールであって、前記ハードウェア要素と通信して前記ハードウェア要素のうちの少なくとも1つを制御するように動作することが可能な副制御モジュールを備え、各制御モジュールは、前記ハードウェア要素に制御動作を送信しない待機モードと、前記ハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、各制御モジュールは、通信して他方の制御モジュールの動作モードを確認するように動作することができ、他方の制御モジュールが前記稼働モードで動作していない場合は、一方の制御モジュールが前記稼働モードに切り替わるように動作することが可能である請求項1から請求項27のいずれか一項に記載の制御システム。

請求項29

前記システムの初期化時に、前記主制御モジュールが前記稼働モードで動作し、前記副制御モジュールが前記待機モードで動作する請求項28に記載の制御システム。

請求項30

入力/出力(I/O)インターフェースを備え、各制御モジュールが、前記I/Oインターフェースと通信するために接続される請求項28または請求項29に記載の制御システム。

請求項31

前記I/Oインターフェースは、各制御モジュールが最後に稼働して前記ハードウェア要素のうちの少なくとも1つに制御データを通信してからの時間を示す時間値を記録するように動作することが可能な時間記録モジュールを含む請求項30に記載の制御システム。

請求項32

各制御モジュールは、所定のサンプリング期間にわたって前記I/Oインターフェースをポーリングして、他方の制御モジュールの時間記録モジュールによって記録された前記時間値を判定するように動作することが可能である請求項31に記載の制御システム。

請求項33

前記主制御モジュールに第1のID番号が割り当てられ、前記副制御モジュールに、前記第1のID番号よりも大きい第2のID番号が割り当てられる請求項28から請求項32のいずれか一項に記載の制御システム。

請求項34

最も小さいID番号を有する制御モジュールが、前記稼働モードで動作するように構成される請求項33に記載の制御システム。

請求項35

前記サーバで実行されるサービスとして実装される少なくとも1つのさらに他の制御モジュールを備え、さらに他の制御モジュールは各々、前記ハードウェア要素と通信して前記ハードウェア要素のうちの少なくとも1つを制御するように動作することが可能であり、さらに他の制御モジュールは各々、前記ハードウェア要素に制御動作を送信しない待機モードと、前記ハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、さらに他の制御モジュールは各々、前記I/Oインターフェースと通信して、他の制御モジュールの動作モードを判定するように動作することが可能である請求項30から請求項32のいずれか一項に記載の制御システム。

請求項36

少なくとも1つの制御モジュールが、その他の制御モジュールのうちの少なくとも1つとは異なるサーバで実行されるサービスとして実装される請求項28から請求項35のいずれか一項に記載の制御システム。

請求項37

前記サーバが、互いに異なる地理的場所に配置される請求項36に記載の制御システム。

請求項38

各制御モジュールが、積分器を含み、各制御モジュールが、自身の積分器の値をその他の制御モジュールに通信するように動作することができ、前記待機モードで動作している各制御モジュールは、前記待機モードで動作している各制御モジュールがいつでも前記稼働モードに滑らかに切り替われることができるように、前記稼働モードで動作している制御モジュールの積分器の値と一致するように自身の積分器の値を設定するように構成される、請求項28から請求項37のいずれか一項に記載の制御システム。

請求項39

各制御モジュールが、比例積分微分(PID)コントローラである請求項38に記載の制御システム。

請求項40

前記待機モードで動作している各制御モジュールは、前記稼働モードで動作している制御モジュールの目標値と同じ値に自身の目標値を設定するように動作することが可能である請求項39に記載の制御システム。

請求項41

前記主制御モジュールは、前記サーバで実行されている仮想機械で実行されるサービスとして実装される請求項1から請求項40のいずれか一項に記載の制御システム。

請求項42

各他の制御モジュールは、前記サーバで実行されている前記仮想機械で実行されるサービスとして実装される請求項41に記載の制御システム。

請求項43

各他の制御モジュールは、前記サーバで実行されているそれぞれ別個の仮想機械で実行されるサービスとして実装される請求項41に記載の制御システム。

請求項44

各他の制御モジュールは、1つまたは複数の別個のサーバで実行されている別個の仮想機械で実行されるサービスとして実装される請求項41に記載の制御システム。

請求項45

各サーバは、その他のサーバとは異なる地理的場所に配置される請求項44に記載の制御システム。

請求項46

第1のハードウェア要素および第2のハードウェア要素を制御する方法であって、前記ハードウェア要素から遠隔に配置されるサーバでサービスとして主制御モジュールを実行するステップであって、前記主制御モジュールが直接制御層の一部を形成し、前記ハードウェア要素が現場レベルのプロトコルを使用して前記サーバと通信状態にあるステップと、前記ハードウェア要素と前記主制御モジュールとの間で現場レベルのプロトコルを使用してデータを通信することによって、前記主制御モジュールを使用して前記ハードウェア要素のうちの少なくとも1つを制御するステップとを含む方法。

請求項47

前記主制御モジュールが、直接連続制御モジュールであり、前記主制御モジュールを使用して前記ハードウェア要素のうちの少なくとも1つを連続的に制御するステップをさらに含む請求項46に記載の方法。

請求項48

前記主制御モジュールが、直接デジタル制御モジュールである請求項46または請求項47のいずれか一項に記載の方法。

請求項49

前記ハードウェア要素の1つが、センサである請求項46から請求項48のいずれか一項に記載の方法。

請求項50

前記ハードウェア要素の1つが、アクチュエータである請求項46から請求項49のいずれか一項に記載の方法。

請求項51

前記第1および第2のハードウェア要素が、単一のハードウェア装置に統合される請求項46から請求項48のいずれか一項に記載の方法。

請求項52

前記主制御モジュールが、前記サーバでサービスとして実行されるアルゴリズムを備える請求項46から請求項50のいずれか一項に記載の方法。

請求項53

前記ハードウェア要素が、伝送制御プロトコル(TCP)の上で実行される現場レベルのプロトコルを使用して前記サーバと通信する請求項46から請求項51のいずれか一項に記載の方法。

請求項54

前記ハードウェア要素が、Modbus/TCPおよびProfibus/TCPからなる群から選択されるプロトコルを使用して前記サーバと通信する請求項52に記載の方法。

請求項55

前記ハードウェア要素が、インターネットを介して前記サーバと通信する請求項46から請求項53のいずれか一項に記載の方法。

請求項56

前記サーバが、クラウドの一部を形成するサーバである請求項46から請求項54のいずれか一項に記載の方法。

請求項57

前記ハードウェア要素のうちの少なくとも1つが、直接前記クラウドに接続される請求項46から請求項55のいずれか一項に記載の方法。

請求項58

前記ハードウェア要素のうちの少なくとも1つが、ローカル・エリア・ネットワークを介して前記クラウドに接続される請求項46から請求項55のいずれか一項に記載の方法。

請求項59

前記ハードウェア要素のうちの少なくとも1つが、ゲートウェイ・サーバを介して前記クラウドに接続される請求項46から請求項55のいずれか一項に記載の方法。

請求項60

前記ゲートウェイ・サーバが、前記ハードウェア要素と同じ建物の中に位置する請求項48に記載の方法。

請求項61

前記サーバと通信状態にあるユーザ・インターフェースを提供し、該ユーザ・インターフェースを使用して前記サーバと対話して前記主制御モジュールを監視および制御するステップをさらに含む請求項46から請求項59のいずれか一項に記載の方法。

請求項62

前記ユーザ・インターフェースが、サービスとしてのプラットフォーム(PaaS)またはサービスとしてのシステム(SaaS)として実装される請求項60に記載の方法。

請求項63

前記ハードウェア要素が、プロセス変量を出力し、該プロセス変量をフィードバック・ループを介して前記主制御モジュールの入力に伝達するステップと、前記プロセス変量を遅延補償値によって修正して、前記主制御モジュールと前記ハードウェア要素との間の通信の遅延を補償するステップとをさらに含む請求項46から請求項61のいずれか一項に記載の方法。

請求項64

前記プロセス変量を前記基準値と比較し、前記主制御モジュールの入力に比較値を出力し、前記プロセス変量または誤差値を前記遅延補償値によって修正するステップをさらに含む請求項62に記載の方法。

請求項65

前記主制御モジュールと前記ハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延に一致するように前記遅延補償値を選択するステップを含む請求項62または請求項63に記載の方法。

請求項66

前記主制御モジュールと前記ハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延と等しくなるように前記遅延補償値を選択するステップを含む請求項62または請求項63に記載の方法。

請求項67

スミス予測器を使用して前記プロセス変量を修正するステップを含む請求項62から請求項63のいずれか一項に記載の方法。

請求項68

前記スミス予測器を使用して、前記プロセス変量に代えてプロセス誤差を遅延補償値によって修正して、前記主制御モジュールと前記ハードウェア要素との間の通信の遅延を補償するステップを含む請求項66に記載の方法。

請求項69

前記主制御モジュールと前記ハードウェア要素のうちの少なくとも1つとの間の往復通信時間遅延を推定するステップを含む請求項62から請求項67のいずれか一項に記載の方法。

請求項70

指数重み付き移動平均の計算を使用して前記遅延を推定するステップを含む請求項68に記載の方法。

請求項71

指数重み付き移動分散の計算を使用して遅延の分散を推定するステップを含む請求項68に記載の方法。

請求項72

所定の時間にわたって前記プロセス変量を次第に修正するステップを含む請求項62から請求項70のいずれか一項に記載の方法。

請求項73

前記サーバでサービスとして副制御モジュールを実行するステップを含み、前記ハードウェア要素が、前記サーバと通信状態にあり、各制御モジュールが前記ハードウェア要素に制御動作を送信しない待機モードと、前記ハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、各制御モジュールを起動して他方の制御モジュールの動作モードを確認するステップと、他方の制御モジュールが前記稼働モードで動作していない場合は、一方の制御モジュールを前記稼働モードに切り替えるステップとを含む請求項46から請求項71のいずれか一項に記載の方法。

請求項74

最初に前記主制御モジュールを前記稼働モードで動作させ、前記副制御モジュールは前記待機モードで動作する請求項72に記載の方法。

請求項75

各制御モジュールが、I/Oインターフェースと通信する請求項72または請求項73に記載の方法。

請求項76

前記I/Oインターフェースは、各制御モジュールが最後に稼働して前記ハードウェア要素のうちの少なくとも1つに制御データを通信してからの時間を示す時間値を記録するように動作することが可能な時間記録モジュールを含む請求項74に記載の方法。

請求項77

各制御モジュールが、所定のサンプリング期間にわたって前記I/Oインターフェースをポーリングして、他方の制御モジュールの時間記録モジュールによって記録された前記時間値を判定する請求項75に記載の方法。

請求項78

前記主制御モジュールに第1のID番号を割り当て、前記副制御モジュールに前記第1のID番号よりも大きい第2のID番号を割り当てるステップを含む請求項72から請求項76のいずれか一項に記載の方法。

請求項79

最も小さいID番号を有する前記制御モジュールを前記稼働モードで動作させるステップを含む請求項77に記載の方法。

請求項80

少なくとも1つのさらに他の制御モジュールを前記サーバでサービスとして実行するステップであって、さらに他の制御モジュールは各々、前記ハードウェア要素と通信状態にあるステップを含み、さらに他の制御モジュールは各々、前記ハードウェア要素に制御動作を送信しない待機モードと、前記ハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、さらに他の制御モジュール各々を動作させて、前記I/Oインターフェースと通信して、他の制御モジュールの動作モードを判定させるステップをさらに含む請求項74から請求項76のいずれか一項に記載の方法。

請求項81

少なくとも1つの制御モジュールが、その他の制御モジュールのうちの少なくとも1つと異なるサーバで実行されるサービスとして実装される請求項72から請求項79のいずれか一項に記載の方法。

請求項82

前記サーバが、互いに異なる地理的場所に配置される請求項80に記載の方法。

請求項83

各制御モジュールが、積分器を含み、各制御モジュールの積分器の値を他の制御モジュールに通信するステップと、前記待機モードで動作している各制御モジュールがいつでも前記稼働モードに滑らかに切り替われるように、前記待機モードで動作している各制御モジュールの積分器を前記稼働モードで動作している制御モジュールの積分器の値と一致するように設定するステップとを含む、請求項72から請求項79のいずれか一項に記載の方法。

請求項84

各制御モジュールが、比例積分微分(PID)コントローラである請求項82に記載の方法。

請求項85

前記待機モードで動作している各制御モジュールの目標値を、前記稼働モードで動作している制御モジュールの目標値と同じ値に設定するステップを含む請求項82に記載の方法。

請求項86

前記主制御モジュールが、前記サーバで実行されている仮想機械で実行されるサービスとして実装される請求項46から請求項84のいずれか一項に記載の方法。

請求項87

各他の制御モジュールが、前記サーバで実行されている前記仮想機械で実行されるサービスとして実装される請求項85に記載の方法。

請求項88

各他の制御モジュールが、前記サーバで実行されているそれぞれ別個の仮想機械で実行されるサービスとして実装される請求項85に記載の方法。

請求項89

各他の制御モジュールが、1つまたは複数の別個のサーバで実行されている別個の仮想機械で実行されるサービスとして実装される請求項85に記載の方法。

請求項90

各サーバが、その他のサーバとは異なる地理的場所に配置される請求項85に記載の方法。

技術分野

0001

本発明は、制御システムおよび方法に関し、より詳細には、クラウドに置かれたサーバと共に使用するための制御システムおよび方法に関する。

背景技術

0002

デジタルコンピュータが最初に制御システムで使用されたのは1960年前後であった。以降、制御システムは演算機器の進歩に伴って発展してきた。今日では、オートメーション・システムは、演算および通信を行う数個の階層を伴う多層構造アーキテクチャである。オートメーションは、直接的で自動的な制御に加えて、モニタリング監視制御、警報管理、履歴化、プラント・レベルの管理、企業レベルアプリケーションなど、他の高レベルの機能を提供していることから、今日オートメーションが意味するものは自動的な制御を越えている。

0003

既存技術を使用する大規模なオートメーション計画は非常に高費用で時間を要する事業である。そのような事業は、多大な人的技術労力に加えて、大量のハードウェアおよびソフトウェアを必要とする。オートメーションの初期費用はしばしば数千万ドルに達する。また、別のオートメーション提供者への切り換えは、既存のオートメーション・システムに行われた多大な投資のために通常は避けられる。費用を別にしても、オートメーション・システム全体を配備し直すことは、特に稼働中のプラントの場合は極めて時間を要する。

先行技術

0004

T. Abdelzaher, Y. Diao, J. L. Hellerstein, C. Lu, and X. Zhu. Introduction to Control Theory And Its Application to Computing Systems Performance Modeling and Engineering. In Performance Modeling and Engineering, chapter 7, pages 185−215. Springer US, 2008.
Introduction to Modbus TCP/IP (white paper). http://www.acromag.com/sites/ default/files/Acromag_Intro_ModbusTCP_765A.pdf, 2005.
M. Bandyopadhyay. Control Engineering Theory and Practice. Prentice−Hall of India, 2006.
J. Bendtsen, J. Stoustrup, and K. Trangbaek. Bumpless transfer between advanced controllers with applications to power plant control. In Proc. ofIEEE Conference on Decision and Control, volume 3, pages 2059−64, Dec 2003.
S. Bhattacharyya, A. Datta, and L. Keel. Linear Control Theory: Structure, Robustness, And Optimization.CRCPress, 2009.
M. Bjorkqvist, L. Chen, M. Vukolic, and Z. Xi. Minimizing retrieval latency for content cloud. In Proc. of IEEEINFOCOM, 2011.
Y. Chen, Z. Du, and M. Garcia−Acosta. Robot as a service in cloud computing. In Proc. of IEEE International Symposium on Service Oriented System Engineering, 2010.
Z. Chen, L. Liu, and X. Yin. Networked control system with network time−delay compensation. In Proc. of Industry Applications Conference, volume 4, pages 2435−40, 2005.
DS2 :Delay Space Synthesizer. http://www.cs.rice.edu/〜bozhang/ds2/.
L. Desborough and R. Miller. Increasing customer value of industrial control performance monitoring−Honeywell’s experience. In Preprint of Chemical Process Control, 2002.
V. Gabale, P. Dutta, R. Kokku, and S. Kalyanaraman. InSite: QoE−aware video delivery from cloud data centers. In Proc. of International Symposium on QoS, 2012.
X. Gao and L. Schulman. Feedback control for router congestion resolution. In Proc. ofACMSymposium on Principles of Distributed Computing, 2005.
M. Gopal. Digital Control Engineering. New Age International, 1998.
M. Gopal. Control Systems: Principles and Design. Tata McGraw−Hill, 2006. Reprinted from the 2002 original.
U. Herrmann, B. Kelly, and H. Price. Two−tank molten salt storage for parabolic trough solar power plants. Energy, 29(5−6):883−93, Apr 2004.
S. Kumar, S. Gollakota, and D. Katabi. A cloud−assisted design for autonomous driving. In Proc. of SIGCOMM MCC workshop on Mobile Cloud Computing, 2012.
Why Use LabVIEW? http: //www.ni.com/white−paper/8536/en.
C. Lu, Y. Lu, T. Abdelzaher, J. A. Stankovic, and S. Son. Feedback control architecture and design methodology for service delay guarantees in web servers. IEEE Transactions on Parallel and Distributed Systems, 17(7), Sept 2006.
K. Natori and K. Ohnishi. A design method of communication disturbance observer for time−delay compensation, taking the dynamic property of network disturbance into account. IEEE Transactions on Industrial Electronics,55(5):2152−68, May 2008.
P. Patras, A. Banchs, and P. Serrano. A control theoretic scheme for efficient video transmission over ieee 802.11e edca wlans. ACM Transactions on Multimedia Computing Communications and Applications, 8(3):29:1−29:23, Aug 2012.
J. Rossiter. Model−Based Predictive Control: A Practical Approach. CRC Press, 2004.
J. Sherry, S. Hasan, C. Scott, A. Krishnamurthy, S. Ratnasamy, and V. Sekar. Making middleboxes someone else’s problem: network processing as a cloud service. In Proc. of SIGCOMM, 2012.
Smith Predictor for Control of Processes with Dead Times. http://support.automation. siemens.com/WW/view/en/37361207, 2009.
G. Smaragdakis, N. Laoutaris, I. Matta, A. Bestavros, and I. Stavrakakis. A feedback control approach to mitigating mistreatment in distributed caching groups. In Proc. ofIFIP−TC6 Conference on Networking Technologies, Services, and Protocols, 2006.
O. Smith. Closer control of loops with dead time. Chemical Engineering Progress, 53(5):217−9, May 1957.
Solar plots. http://www.solarplots.info/.
H. Wade. Basic and Advanced Regulatory Control: System Design and Application.ISA, 2004.
T. Wood, E. Cecchet, K. Ramakrishnan, P. Shenoy, J. van der Merwe, and A. Venkataramani. Disaster recovery as a cloud service: economic benefits & deployment challenges. In Proc. of USENIX Conference on Hot Topics in Cloud Computing, 2010.
X. Xu. From cloud computing to cloud manufacturing. Robotics and Computer−Integrated Manufacturing, 28(1):75−86, Feb 2012.
S. Yang, X. Chen, L. Tan, and L. Yang. Time delay and data loss compensation for internet−based process control systems. Transactions of the Institute of Measurement and Control, 27(2):103−18, June 2012.
Y. Yang, Y. Wang, and S.−H. Yang. A networked control system with stochastically varying transmission delay and uncertain process parameters. In Proc. ofIFAC, volume 16, 2005.

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

0005

本発明は、改良された制御システムおよび方法を提供することを目的とする。
本発明の一態様によると、第1のハードウェア要素と、第2のハードウェア要素と、ハードウェア要素から遠隔に配置されるサーバであって、ハードウェア要素はサーバと通信状態にあって、ハードウェア要素とサーバとの間でデータを通信することができる、サーバと、サーバで実行されるサービス(service)として実装される主制御モジュールであって、ハードウェア要素と通信してハードウェア要素のうちの少なくとも1つを制御するように動作することができる主制御モジュールとを備える制御システムが提供される。

0006

好ましくは、ハードウェア要素の1つはセンサである。
好都合には、ハードウェア要素の1つはアクチュエータである。
有利には、第1および第2のハードウェア要素は単一のハードウェア装置統合される。

0007

好ましくは、主制御モジュールは、制御システム内の直接制御層の一部を形成する。
好都合には、主制御モジュールは、サーバでサービスとして実行されるアルゴリズムを備える。
有利には、ハードウェア要素は、伝送制御プロトコル(TCP)の上で実行される現場レベル(field−level)のプロトコルを使用してサーバと通信する。

0008

好ましくは、ハードウェア要素は、Modbus/TCPおよびProfibus/TCPからなる群から選択されるプロトコルを使用してサーバと通信する。
好都合には、ハードウェア要素はインターネットを介してサーバと通信する。
有利には、サーバは、クラウドの一部を形成するサーバである。

0009

好ましくは、ハードウェア要素のうちの少なくとも1つは直接クラウドに接続される。
好都合には、ハードウェア要素のうちの少なくとも1つはローカルエリアネットワークを介してクラウドに接続される。
有利には、ハードウェア要素のうちの少なくとも1つはゲートウェイ・サーバを介してクラウドに接続される。

0010

好ましくは、ゲートウェイ・サーバはハードウェア要素と同じ建物の中に位置する。
好都合には、上記システムはさらに、サーバと通信状態にあってユーザがサーバと対話して主制御モジュールを監視および制御できるようにするユーザ・インターフェースを備える。
有利には、ユーザ・インターフェースは、サービスとしてのプラットフォーム(PaaS)またはサービスとしてのシステム(SaaS)として実装される。

0011

好ましくは、ハードウェア要素はプロセス変量を出力し、上記システムは、プロセス変量を主制御モジュールの入力に伝達するフィードバックループを備え、システムはさらに、遅延補償値でプロセス変量を変更して、主制御モジュールとハードウェア要素との間の通信の遅延補償する遅延補償モジュールを備える。

0012

好都合には、上記システムはさらに、プロセス変量を受け取る第1の入力と、基準値を受け取る第2の入力とを含む比較装置を備え、比較装置は、プロセス変量を基準値と比較し、主制御モジュールの入力に比較値を出力し、遅延補償モジュールはプロセス変量または誤差値を遅延補償値で変更する。
有利には、遅延補償モジュールは、主制御モジュールとハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延に一致するように遅延補償値を選択する。

0013

好ましくは、遅延補償モジュールは、主制御モジュールとハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延と等しくなるように遅延補償値を選択する。
好都合には、遅延補償モジュールはスミス予測器である。
有利には、スミス予測器は、プロセス変量ではなくプロセス誤差を遅延補償値で変更して、主制御モジュールとハードウェア要素との間の通信の遅延を補償する。

0014

好ましくは、上記システムはさらに、主制御モジュールとハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延を推定するように動作することが可能な遅延推定モジュールを備える。
好都合には、遅延推定モジュールは、指数重み付き移動平均の計算を使用して遅延を推定する。
有利には、遅延推定モジュールは、指数重み付き移動分散の計算を使用して遅延の分散を推定する。

0015

好ましくは、遅延補償モジュールは、所定の時間にわたってプロセス変量を次第に変更する。

0016

好都合には、上記システムはさらに、サーバで実行されるサービスとして実装される副制御モジュールであって、ハードウェア要素と通信してハードウェア要素のうちの少なくとも1つを制御するように動作することが可能な副制御モジュールを備え、各制御モジュールは、ハードウェア要素に制御動作を送信しない待機モードと、ハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、各制御モジュールは、通信して他方の制御モジュールの動作モードを確認するように動作することができ、他方の制御モジュールが稼働モードで動作していない場合は、一方の制御モジュールが稼働モードに切り替わるように動作することが可能である。

0017

有利には、システムが初期化されると、主制御モジュールは稼働モードで動作し、副制御モジュールは待機モードで動作する。

0018

好ましくは、上記システムは入力/出力(I/O)インターフェースを備え、各制御モジュールはI/Oインターフェースと通信するために接続される。
好都合には、I/Oインターフェースは、各制御モジュールが最後に稼働し、ハードウェア要素のうちの少なくとも1つに制御データを通信してからの時間を示す時間値を記録するように動作することが可能な時間記録モジュールを含む。
有利には、各制御モジュールは、所定のサンプリング期間にわたってI/Oインターフェースをポーリングして、他方の制御モジュールの時間記録モジュールによって記録された時間値を判定するように動作することが可能である。

0019

好ましくは、主制御モジュールに第1のID番号が割り当てられ、副制御モジュールに、第1のID番号よりも大きい第2のID番号が割り当てられる。
好都合には、最も小さいID番号を有する制御モジュールが稼働モードで動作するように構成される。

0020

有利には、上記システムはさらに、サーバで実行されるサービスとして実装される少なくとも1つのさらに他の制御モジュールを備え、さらに他の制御モジュールは各々、ハードウェア要素と通信してハードウェア要素のうちの少なくとも1つを制御するように動作することが可能であり、さらに他の制御モジュールは各々、ハードウェア要素に制御動作を送信しない待機モードと、ハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、さらに他の制御モジュールは各々、I/Oインターフェースと通信して、他の制御モジュールの動作モードを判定するように動作することが可能である。

0021

好ましくは、少なくとも1つの制御モジュールは、その他の制御モジュールのうちの少なくとも1つと異なるサーバで実行されるサービスとして実装される。
好都合には、サーバは、互いに異なる地理的場所に配置される。

0022

有利には、各制御モジュールは積分器を含み、各制御モジュールは、自身の積分器の値をその他の制御モジュールに通信するように動作することができ、待機モードで動作している各制御モジュールは、稼働モードで動作している制御モジュールの積分器の値と一致するように自身の積分器の値を設定して、待機モードで動作している各制御モジュールがいつでも稼働モードに滑らかに切り替われるようにするように構成される。

0023

好ましくは、各制御モジュールは比例積分微分(PID)コントローラである。
好都合には、待機モードで動作している各制御モジュールは、稼働モードで動作している制御モジュールの目標値と同じ値に自身の目標値を設定するように動作することが可能である。
有利には、主制御モジュールは、サーバで実行されている仮想機械で実行されるサービスとして実装される。

0024

好ましくは、各他の制御モジュールは、サーバで実行されている仮想機械で実行されるサービスとして実装される。
好都合には、各他の制御モジュールは、サーバで実行されているそれぞれ別個の仮想機械で実行されるサービスとして実装される。
有利には、各他の制御モジュールは、1つまたは複数の別個のサーバで実行されている別個の仮想機械で実行されるサービスとして実装される。

0025

好ましくは、各サーバは、その他のサーバと異なる地理的場所に配置される。

0026

本発明の別の態様によると、第1のハードウェア要素および第2のハードウェア要素を制御する方法が提供され、この方法は、ハードウェア要素から遠隔に配置されるサーバでサービスとして主制御モジュールを実行するステップであって、ハードウェア要素はサーバと通信状態にあるステップと、ハードウェア要素と主制御モジュールとの間でデータを通信することによって、主制御モジュールを使用してハードウェア要素のうちの少なくとも1つを制御するステップとを含む。

0027

好ましくは、ハードウェア要素の1つはセンサである。
好都合には、ハードウェア要素の1つはアクチュエータである。
有利には、第1および第2のハードウェア要素は単一のハードウェア装置に統合される。

0028

好ましくは、主制御モジュールは、制御システム内の直接制御層の一部を形成する。
好都合には、主制御モジュールは、サーバでサービスとして実行されるアルゴリズムを備える。
有利には、ハードウェア要素は、伝送制御プロトコル(TCP)の上で実行される現場レベルのプロトコルを使用してサーバと通信する。

0029

好ましくは、ハードウェア要素は、Modbus/TCPおよびProfibus/TCPからなる群から選択されるプロトコルを使用してサーバと通信する。
好都合には、ハードウェア要素はインターネットを介してサーバと通信する。
有利には、サーバは、クラウドの一部を形成するサーバである。

0030

好ましくは、ハードウェア要素のうちの少なくとも1つは直接クラウドに接続される。
好都合には、ハードウェア要素のうちの少なくとも1つはローカル・エリア・ネットワークを介してクラウドに接続される。
有利には、ハードウェア要素のうちの少なくとも1つはゲートウェイ・サーバを介してクラウドに接続される。

0031

好ましくは、ゲートウェイ・サーバは、ハードウェア要素と同じ建物の中に位置する。
好都合には、上記方法はさらに、サーバと通信状態にあるユーザ・インターフェースを提供し、そのユーザ・インターフェースを使用してサーバと対話して主制御モジュールを監視および制御するステップを含む。
有利には、ユーザ・インターフェースは、サービスとしてのプラットフォーム(PaaS)またはサービスとしてのシステム(SaaS)として実装される。

0032

好ましくは、ハードウェア要素はプロセス変量を出力し、上記方法は、プロセス変量をフィードバック・ループを介して主制御モジュールの入力に伝達するステップを含み、上記方法はさらに、遅延補償値でプロセス変量を変更して、主制御モジュールとハードウェア要素との間の通信の遅延を補償するステップを含む。

0033

好都合には、上記方法はさらに、プロセス変量を基準値と比較し、主制御モジュールの入力に比較値を出力し、プロセス変量または誤差値を遅延補償値で変更するステップを含む。
有利には、上記方法は、主制御モジュールとハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延に一致するように遅延補償値を選択するステップを含む。

0034

好ましくは、上記方法は、主制御モジュールとハードウェア要素のうちの少なくとも1つとの間の通信の往復時間遅延と等しくなるように遅延補償値を選択するステップを含む。
好都合には、上記方法は、スミス予測器を使用してプロセス変量を変更するステップを含む。
有利には、上記方法は、スミス予測器を使用して、プロセス変量ではなくプロセス誤差を遅延補償値で変更して、主制御モジュールとハードウェア要素との間の通信の遅延を補償するステップを含む。

0035

好ましくは、上記方法はさらに、主制御モジュールとハードウェア要素のうちの少なくとも1つとの間の往復通信時間遅延を推定するステップを含む。
好都合には、上記方法は、指数重み付き移動平均の計算を使用して遅延を推定するステップを含む。
有利には、上記方法は、指数重み付き移動分散の計算を使用して遅延の分散を推定するステップを含む。

0036

好ましくは、上記方法は、所定の時間にわたってプロセス変量を次第に変更するステップを含む。

0037

好都合には、上記方法はさらに、サーバでサービスとして副制御モジュールを実行するステップを含み、ハードウェア要素はサーバと通信状態にあり、各制御モジュールは、ハードウェア要素に制御動作を送信しない待機モードと、ハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、上記方法は、各制御モジュールを起動して他方の制御モジュールの動作モードを確認するステップを含み、上記方法は、他方の制御モジュールが稼働モードで動作していない場合は、一方の制御モジュールを稼働モードに切り替えるステップを含む。

0038

有利には、はじめは、上記方法は主制御モジュールを稼働モードで動作させ、副制御モジュールは待機モードで動作する。

0039

好ましくは、各制御モジュールはI/Oインターフェースと通信する。
好都合には、I/Oインターフェースは、各制御モジュールが最後に稼働し、ハードウェア要素のうちの少なくとも1つに制御データを通信してからの時間を示す時間値を記録するように動作することが可能な時間記録モジュールを含む。
有利には、各制御モジュールは、所定のサンプリング期間にわたってI/Oインターフェースをポーリングして、他方の制御モジュールの時間記録モジュールによって記録された時間値を判定する。

0040

好ましくは、上記方法は、主制御モジュールに第1のID番号を割り当て、副制御モジュールに、第1のID番号よりも大きい第2のID番号を割り当てるステップを含む。
好都合には、上記方法は、最も小さいID番号を有する制御モジュールを稼働モードで動作させるステップを含む。

0041

有利には、上記方法はさらに、少なくとも1つのさらに他の制御モジュールをサーバでサービスとして実行するステップであって、さらに他の制御モジュールは各々、ハードウェア要素と通信状態にあるステップを含み、さらに他の制御モジュールは各々、ハードウェア要素に制御動作を送信しない待機モードと、ハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、上記方法は、さらに他の制御モジュール各々を動作させて、I/Oインターフェースと通信して、他の制御モジュールの動作モードを判定させるステップを含む。

0042

好ましくは、少なくとも1つの制御モジュールは、その他の制御モジュールのうちの少なくとも1つと異なるサーバで実行されるサービスとして実装される。
好都合には、サーバは、互いに異なる地理的場所に配置される。

0043

有利には、各制御モジュールは積分器を含み、上記方法は、各制御モジュールの積分器の値を他の制御モジュールに通信するステップを含み、上記方法は、待機モードで動作している各制御モジュールの積分器を、稼働モードで動作している制御モジュールの積分器の値と一致するように設定して、待機モードで動作している各制御モジュールがいつでも稼働モードに滑らかに切り替われるようにするステップを含む。

0044

好ましくは、各制御モジュールは比例積分微分(PID)コントローラである。
好都合には、上記方法は、待機モードで動作している各制御モジュールの目標値を、稼働モードで動作している制御モジュールの目標値と同じ値に設定するステップを含む。
有利には、主制御モジュールは、サーバで実行されている仮想機械で実行されるサービスとして実装される。

0045

好ましくは、各他の制御モジュールは、サーバで実行されている仮想機械で実行されるサービスとして実装される。
好都合には、各他の制御モジュールは、サーバで実行されているそれぞれ別個の仮想機械で実行されるサービスとして実装される。
有利には、各他の制御モジュールは、1つまたは複数の別個のサーバで実行されている別個の仮想機械で実行されるサービスとして実装される。

0046

好ましくは、各サーバはその他のサーバと異なる地理的場所に配置される。

0047

本発明をより容易に理解することができるように、またさらに他の特徴を理解できるように、次いで本発明の実施形態について添付図面を参照して例として説明する。

図面の簡単な説明

0048

従来の産業用オートメーション・システムを示す概略図である。
本発明の一実施形態のクラウドを利用する制御システムの要素を示す概略図である。
仮想機械にコントローラを割り当てるアルゴリズムの疑似コードを示す図である。
(a)〜(e)本発明の一実施形態におけるインターネット遅延を緩和するフィードバック制御ループを示す図である。
本発明の一実施形態のクラウドを使用する制御システムの概略図である。
3つの別個のクラウド提供者によって提供されるシステムでサービスとして実行されるクラウドに置かれた複数のコントローラを示す概略図である。
本発明の一実施形態の高信頼クラウド制御(RCC)アルゴリズムの疑似コードを示す図である。
本発明の一実施形態の滑らかな引き継ぎアルゴリズムの疑似コードを示す図である。
本発明の一実施形態の試験時における2つのクラウド・コントローラの位置を示す概略図である。
本発明の実施形態の試験でその模擬を使用した太陽熱発電プラント制御システムの概略図である。
(a)〜(c)本発明の一実施形態の試験時における太陽光集光器の角度のグラフを示す図である。
(a)〜(c)本発明の一実施形態の試験時における太陽熱発電プラントの制御結果を示すグラフである。
(a)〜(c)遅延を導入した場合の本発明の実施形態の制御システムの試験結果を示すグラフである。
本発明の一実施形態の遅延補償器を使用した性能指標を要約した表である。
(a)〜(b)滑らかな引き継ぎを行う場合と行わない場合のRCCアルゴリズムの性能を示すグラフである。

実施例

0049

本発明の一実施形態では、広義のオートメーションを使用して、クラウドを利用するオートメーション方式を提案する。産業用オートメーションの一例を以下で詳しく説明して、本発明の一実施形態の実現可能性を実証する。オートメーション・システムのアーキテクチャおよび機能を定義する。それに続いて、本発明の一実施形態の実施および評価で使用される連続的で調節を伴う産業プロセスを定義する。オートメーションの意味は自動的な制御の定義を越えている。オートメーションは、直接的で自動的な制御の上にいくつかの機能を提供するアーキテクチャ全体を言う。

0050

オートメーションは、産業オートメーション、建物のオートメーション、高速道路のオートメーション、住宅のオートメーションなど、いくつかの応用領域を有する。アーキテクチャの最も低い層では、センサが配置されて、制御する必要がある数量(プロセス変量と呼ばれる)を測定する。アクチュエータを使用してプロセス変量を各自の所望の値に制御する。プロセス変量の例としては、建物内の温度、高速道路の交通速度、および産業用ボイラーの圧力が挙げられる。一レベル上に移ると、ダイレクト・コントローラがプロセス変量のセンサ測定値を入力として受け取り、必要な動作を算出し、アクチュエータに各自の動作を出力する。直接制御に加えて、ユーザは高水準制御関連機能を必要とし、そのような機能としては、ユーザがプロセス変量を利便に観察できるようにするためのモニタリング、ダイレクト・コントローラを設定する監視制御、および種々の変量をデータベースに記録する履歴化などがある。複雑なオートメーションの応用例では、企業レベルの管理のための高水準の最適化が必要とされる。

0051

産業用オートメーションは、最も複雑なアーキテクチャの1つである。図1に、従来の産業用オートメーション・システムのアーキテクチャを簡略化して示す。システムは階層的にいくつかの層に分割される。1番目に、現場機器は、プラントのプロセス変量を監視および制御するためにプラント内に設置されたセンサおよびアクチュエータである。I/O数が多い中規模および大規模のプラントの場合は、現場レベルのネットワークを使用して、センサおよびアクチュエータのレベルでより良好なデータ通信配線管理を提供する。データは、現場機器と、制御室に置かれたコントローラとの間を転送される。2番目に、コントローラは、直接の連続的制御または離散的制御、安全性、および緊急時の運転停止など、すべての必要な制御演算を行う特殊目的のソフトウェア・ブロックを実行するマイクロプロセッサである。プロセッサ速度と制御ループサンプリングレートおよび複雑度にもよるが、通常は1つのコントローラで数個の制御ループを処理することができる。

0052

3番目に、コントローラの上には人間−機械インターフェース(HMI)および監視制御およびデータ取得(supervisory control and data acquisition:SCADA)が来る。HMI/SCADAステーションに加えて、履歴記録、警報マネジャ、およびその他多くのアプリケーションなどの他のアプリケーションが、専用のワークステーションで実行される。さらに、技術ワークステーションで制御方針の必要な変更が実装され、その後技術ワークステーションから配備される。そのようなコンピュータはすべて制御ネットワークを通じてコントローラに接続される。

0053

4番目に、高レベルのプラント最適化で高度な計算を行って、エネルギー消費製造速度製造品質などの特定の目標を最適化するための最適なプラント動作パラメータの決定支援を提供する。プラント・レベルの最適化のワークステーションおよびサーバは、プラント・ネットワークと呼ばれる専用ネットワークを通じてHMI/SCADAレベルに接続される。最後に、企業レベルの管理で資産管理経理などのいくつかの機能を行う。プラント最適化の目標は、企業レベルで行われる分析に基づいて決定される。

0054

産業プロセスは、原材料エネルギーを入力として取り込み、1つの製品または製品のセットを作製する。原材料の種類や材料の流れを含むいくつかの要因に基づいて、産業プロセスは、連続、バッチ、および離散の3つの主要な部類分類することができる。産業プラントは、いくつかの産業プロセスから構成される。プラントは、そのプラントのプロセスの最も主要な種類に基づいて分類される。例えば、主として連続プロセスからなるプラントは、連続プラントに分類される。一般に、3つの分類に明確な境界はないが、分類により、各プロセスの要件とそれをどのように制御するかを理解する助けとなる。

0055

製油所発電所、および原子炉はすべて連続プロセスの例である。これらはすべて、いくつかの共通する特徴を有する。第1に、原材料は、通常、油、水、天然ガスなどの流体タイプである。第2に、材料の流れは、流量が変動することはあるが、継続的な需要を満たすために常に継続的である。第3に、連続プロセスは、通常、非常に長い未確定の時間にわたって実行される。第4に、発生する費用と材料の損失のために、プロセスの停止は極めて望ましくない。プロセスが定常状態に達し、有効な製品を製造するまでには、非常に長い過渡時間、例えば数時間または数日を要する場合もある。その過渡時間の間はすべての材料とエネルギーが空費される。

0056

食品業界は、バッチ・プロセスが多く用いられる例であり、これに対して自動車業界は離散プロセスが行われる例である。両方の場合とも材料の流れは一般に非連続的である。また、両タイプとも、一般には組み立てを主体とする。しかし、一般に、バッチ・プロセスの製品は分解して元の原料に戻すことはできず、一方、離散プロセスの製品は分解して元の部品に戻すことができる。バッチ・プロセスで使用される材料が流体材料乾燥材料との混合物であるのに対し、離散プロセスは通常は固形の部品を処理する。連続プロセスとは異なり、バッチ・プロセスと離散プロセスはいずれも終わりがある。バッチ・プロセスでは、プロセスの終了は所定時間の経過または終了条件に従って発生し、例えばパンは1時間焼くか、または表面がきつね色になるまで焼かれる。離散プロセスでは、プロセスは、製品が完成した時、例えば自動車が完全に組み立てられた時に終了する。

0057

連続産業プロセスは、最も高リスク高影響のプロセスとみなされることが度々ある。連続プロセスは、非常に長い時間にわたって継続的なモニタリングと制御を必要とする。例として、発電所について考える。制御が不良であるために性能が低下すると、資金、材料、およびエネルギーに関して多大な損失を招く。さらに、そのようなプロセスに伴う安全性に関する災害重篤なものになる可能性があり、1回の事故で複数の人命損失を容易に起こしうる。

0058

本発明の一実施形態では、(i)クラウド・コントローラ、および(ii)制御入力/出力(I/O)インターフェース、の2つの要素を有するクラウド・サービスとしてフィードバック制御が実装される。コントローラは、比例積分微分(PID)コントローラなどの標準的なコントローラに変更を加えたバージョンを実装するソフトウェア・モジュールである。変更は、インターネット遅延、パケットの損失、および障害対処し、制御の理論的性能の保証が確実に達成されるようにするために加えられる。一実施形態では、コントローラは仮想機械(VM)に配備され、同じVMで複数のコントローラを実行することができる。制御I/Oインターフェースは、制御されるシステム側に配置される。制御I/Oインターフェースは、制御動作を受け取り、現在のプロセス・ステータスを送信することにより、クラウド・コントローラと通信する。制御動作は次いで被制御システムのアクチュエータに中継され、現在のステータスは各種センサによって更新される。

0059

ネットワーク化された制御システムは、分散型制御システム一バージョンと考えることができ、専用の現場レベルのネットワークに加えて、またはそれに代えて、汎用通信ネットワークイントラネットおよびインターネット)を使用してプロセス・データおよび制御データを移送する。通信ネットワークがインターネットである場合、制御システムは、インターネット・ベースの制御システムと呼ばれる。インターネット・ベースの制御システムは、ネットワーク化された制御システムの特殊事例と考えられる。典型的な分散制御システムが専用ネットワークを通じて確定的な遅延を伴う信頼性の高い通信を提供するのに対して、ネットワーク化された制御システムは、遅延の不確定性と信頼性の劣る通信が課題となる。

0060

ネットワーク遅延を克服するために、遅延補償器を設けてもよい。大半の事例では、順方向経路およびフィードバック経路の遅延を補償するために、2つの補償器が必要となる。例えば、2つの予測補償器を設けてインターネット・ベースの制御システムのフィードフォワード方向とフィードバック方向のインターネット遅延を補償することができる。これらの補償器は、シミュレーションと、インターネットを介して遠隔コントローラから制御される実際の液体レベル調節プロセスの両方でランダム遅延の影響の緩和に成功することが示されている。同様に、遅延の補償は、アクチュエータ・ノードバッファと、予測コントローラ・ノードの状態推定器と、を通じて得ることもできる。コントローラは、数サンプリング期間にわたって制御動作を送信する。

0061

上記のような2要素による補償方法は、遅延の影響を緩和し、安定した制御システムをもたらす。しかし、商用システムでそのような方式を採用することは、いくつかの理由から問題がある。第1に、そのような方式は、既存の商用コントローラでは対応可能でない。第2に、2要素による補償器の実装には、追加的なハードウェアおよび/またはソフトウェアが必要となる。そのような対応は、コントローラ側の要素には無費用または最小限の費用で提供することができるが、通常は処理能力を有しないプロセス側の要素には当てはまらない。第3に、クラウドを利用するコントローラについては、演算機能をクラウドに移動しなければならず、これは上記のような補償器の設計と衝突する要件となる。本発明の一実施形態では、単一要素の補償器をクラウドにホストして往復遅延全体を補償する。補償器は、潜在能力を最大にする、現在の商用の既製コントローラで利用可能な機能を使用して実装することができる。

0062

1.1 全機能をクラウドに置くオートメーション・システム
本発明の一実施形態では、完全なオートメーションをサービスとして提供するために、オートメーション・システムの全演算機能をクラウドに移す。ハードウェア要素の中には、センサ、アクチュエータ、安全性/緊急時の運転停止制御機能など、クラウドに移動することができないものがある。図2は、オートメーション・アーキテクチャの一例を示す。以下の説明では、このアーキテクチャがどのようにしてすべてのレベルで全オートメーション機能を実現するかを説明し、このアーキテクチャと図1に示す既存のオートメーション・システムとの主な違いを強調する。

0063

まず、現場(最も低い)レベルから始めると、センサおよびアクチュエータは、Modbus/TCPやProfibus/TCPなど、TCPの上で動作する現場レベルのプロトコルを使用してクラウドに接続される。

0064

一実施形態では、ハードウェア要素のすべてまたは少なくとも1つが、直接クラウドに接続される。別の実施形態では、ハードウェア要素のすべてまたは少なくとも1つが、ローカル・エリア・ネットワークを介してクラウドに接続される。

0065

さらに他の実施形態では、ハードウェア要素のすべてまたは少なくとも1つが、通信サーバを介してクラウドに接続される。一実施形態では、通信サーバは、ハードウェア要素の近く、またはハードウェア要素が配置される場所に配置され、好ましくはハードウェア要素と同じ建物の中に配置される。

0066

セキュリティやメッセージ・レベルのスケジューリングなどの高度な機能が必要とされる場合は、ゲートウェイ・サーバをその目的専用とする。さらに、信頼性を高めるために、ゲートウェイ・サーバを複製して主サーバ故障した場合に副サーバステートフルに引き継ぐようにする。

0067

第2に、直接制御の層については、制御アルゴリズムがクラウド・サービスとして実行される。既存のオートメーション・システム(図1)では、コントローラがセンサをポーリングし、LANを通じてアクチュエータにコマンドを送信する。これに対して、本発明の一実施形態では、通信はインターネットを通じて行われる。また、既存のシステムでは、制御アルゴリズムは、制御室の筐体に収容された実際のハードウェアで実行される。これに対して、仮想化を使用するとより高い柔軟性と費用/時間の低減が得られるため、本発明の一実施形態では、コントローラは、仮想機械(VM)上で実行される。クラウドで制御アルゴリズムを実行するにはインターネットを通じた通信が必要となり、これは、インターネット遅延と、VMの故障やリンク障害によるサービス障害という2つの新たな課題をもたらす。これらの課題に対処する新しいアルゴリズムについて下記の項2.2および2.3で説明する。

0068

第3に、監視制御、人間−機械インターフェース、および他の制御室アプリケーションについては、一実施形態では、これらのアプリケーションは、サービスとしてのプラットフォームおよびソフトウェア(PaaSおよびSaaS)のモデルを通じて提供される。そのため、技術者および作業者は、シンクライアントを通じて制御室アプリケーションにアクセスすることができる。既存のオートメーション・システム(図1)では、制御室は、サーバ、ワークステーション、ネットワーク・スイッチ、およびケーブルが多量に置かれた複雑な環境である。これに対して、本発明の一実施形態では、制御室は、大幅に単純なハードウェアで動作するいくつかのシン・クライアントからなるはるかにすっきりした環境となり、複雑なハードウェアはすべてクラウドに移される。その結果、制御室のハードウェアとソフトウェアの配備がはるかに容易になり、費用が低減する。基盤設備/アプリケーションを配備し、保守維持し、改良するという困難な作業は、技術者および作業者の負担ではなくなる。その結果、技術者や作業者は、オートメーション機能に集中することができる。最後に、現場ゲートウェイ・サーバと同様に、セキュリティやメッセージ・スケジューリングなどの高度な機能を確実に実行する制御室の冗長ゲートウェイ・サーバが提案される。

0069

第4に、プラント・レベルの最適化および企業レベルの管理には、一実施形態ではSaaSモデルを利用する。直接制御および監視制御の層とは異なり、プラント・レベルの最適化および企業レベルの管理のアプリケーションは、それらの適時性と信頼性の要件が下位レベルに比べると厳しくないため、クラウドに移すことがそれほど難しくない。例えば、企業のオフィスは、数分間、さらには数時間のインターネット・サービスの停止に十分に耐えられる可能性がある。それに対して、クラウドに置かれた産業用コントローラにとって、数秒間にわたるインターネット障害は物理プロセスを数走査周期にわたって無制御の状態に放置することを意味し、これは高い安全性リスクを招く可能性がある。

0070

クラウド内部のデータ・センターの高レベルの編成図2に示し、ここではいくつかのサーバが仮想機械を実行して全レベルのオートメーションを扱う。各オートメーション層に属するアプリケーションは、同じクラウド・サーバで実行されるようにグループ化される。このグループ化は、厳格な要件ではないが、より良好なデータ・センター編成を可能にすることから推奨される。例えば、直接制御レベルの適時性の要件が厳しく、コントローラが実時間のオペレーティング・システムの上で動作する必要があるとする。その場合は、すべてのコントローラを、実時間のオペレーティング・システムを備えた同じサーバまたはサーバのグループに配置した方がよい。アプリケーションの種類を混在させると、データ・センターの管理が困難かつ/または不良になる可能性がある。サーバ間の通信は、図1に示した既存のシステムで用いられる4つのネットワークに取って代わる高速スイッチング技術を使用して処理される。本発明の一実施形態では、通信基盤設備を配備し、配線し、保守維持し、改良することに伴う時間、手間、および費用が低減される。

0071

ユーザがインテリジェントな決定支援を通じて資源を選択し、割り当て、管理するためのサービス・インターフェースが提供される。このインターフェースは図2には示していない。

0072

本発明の一実施形態では、オートメーション・システムで必要とされる演算および通信の基盤設備の一部、または好ましくはすべてをクラウドに移す。それにより、ユーザが各自のオートメーション・システムを配備、保守維持、および改良することがより容易で低費用になる。さらに、本発明の一実施形態は、すべての仮想機械をまとめて異なる提供者に移行することができるため、異なるクラウド・オートメーション提供者への切り換えを支援する。

0073

本発明の一実施形態は、仮想機械(VM)へのコントローラの割り当てを決定する以下のステップを含む方法を含む。
1)アプリケーションをVMで実行し、消費された帯域幅およびCPUの利用率を測定することにより、各アプリケーションのCPUの利用率uiおよび帯域幅特性biを求める。
2)VM Vkによって提供することが可能な最大帯域幅BkおよびCPU利用率Ukを求める。
3)図3に示す割り当てアルゴリズムに基づいてコントローラの割り当てを決定する。割り当てアルゴリズムの実行後、SkはVM Vkに割り当てられるコントローラを含んでいる。

0074

図3に示す割り当てアルゴリズムは、次のように要約することができる。アプリケーションごとにすべての利用可能なVMを調べ、そのアプリケーションを、スケジュール可能性の検査(例えばレート・モノトニック)に基づいてCPU利用率に対応することができ、かつそのアプリケーションに必要とされる最大帯域幅に対応することができる最初の利用可能なVMに割り当てる。アプリケーションがVMに割り当てられると、そのVMの負荷(CPUおよび帯域幅)が更新される。

0075

図3に示す割り当てアルゴリズムの主ルーチンを最初に実行してVM資源をコントローラに割り当てる。実行時に新しいコントローラが始動される場合は、新しいコントローラおよび割り当てSkのためにallocate()ルーチンが呼び出される。

0076

1.2インターネット遅延の緩和
本発明の一実施形態は、コントローラをクラウドに移すことによって生じるインターネット遅延に対処する方法およびシステムを提供する。従来のフィードバック制御ループを図4(a)に示す。制御されるプロセスは、プロセス変量と呼ばれる入力および出力を有する。プロセス変量はフィードバックされて、基準値または目標値とも呼ばれる所望の値と比較される。目標値とプロセス変量の差を、誤差と呼ぶ。コントローラは、誤差を入力として受け取り、その誤差を補正するために必要なコントローラ動作を算出する。

0077

図4(b)に示すように、コントローラがクラウドに移された結果、インターネットがプロセスとコントローラの間に入ることになり、これは両方向におけるループに影響する。第1に、コントローラ動作は、フィードフォワード遅延と呼ばれる時間遅延の後にプロセスに到達する。第2に、プロセス変量は、フィードバック遅延と呼ばれる時間遅延の後にクラウドに置かれたコントローラに到達する。ループは、図4(c)に示すようにモデル化することができ、ここでP(z)はプロセスの伝達関数であり、C(z)はコントローラの伝達関数であり、z−kおよびz−lはそれぞれフィードフォワード経路とフィードバック経路の遅延を表す。

0078

本発明の一実施形態では、図4(d)に示すように、目標値の入口に作為的な遅延ブロックを導入する。そのような遅延を導入することの意義については、この下位項目の最後に述べる。導入される遅延の量は、フィードバック経路の遅延z−lと等しい。単純なブロック図代数により、ループは、図4(e)に示すように、簡略化することができる。すると、クラウドを利用した制御の問題は、制御理論むだ時間または輸送遅れのあるプロセスの制御として知られるものとなる。

0079

むだ時間を伴うプロセスは、入力の適用と出力に対するその影響との間に時間遅延があるような本質的な遅延を伴うプロセスである。そのような本質的な遅延は通常、材料がアクチュエータとセンサの間のプロセス内の経路(例えば搬送ベルトや長い管)に沿って移動する時に発生する。例えば、繊維、水、および填料サイズ剤染料樹脂などの添加物がすべてプロセスの最初に混合される抄紙機を考える。その後、生成された長尺シート状の紙が長い経路で機械的に伸長されて、最終的に脱水、乾燥されて、プロセスの最後に計測できる状態になる。センサの測定値を使用して、プロセスの最初に調製される材料の混合物を制御する。混合物を投入する時からそれを計測する時までの長い時間が、そのプロセスのむだ時間である。

0080

むだ時間を伴うプロセスをより効果的に制御するために、コントローラは、通常、遅延補償器に結合される。この目的のためにいくつかの遅延補償器が提案されている。一実施形態ではスミス予測器を使用する。その理由は、スミス予測器は、大半の商用の既製コントローラ、例えばSiemensPCS7やInvensys Foxboro I/A Seriesに搭載されており、最も広く使用されている補償器の一つであるためである。これと同様に重要な点として、スミス予測器は、コントローラの設計時に遅延要素についての正確な知識を必要としない。まず、コントローラは遅延が発生しないものとして設計される。その後、遅延を測定してスミス予測器を調整する。インターネット遅延は動的に変化し、遅延は前もって知ることができないため、これはクラウドに置かれるコントローラを設計する時に有用である。

0081

標準のスミス予測器を備えたコントローラは、以下のようにして導出される。プロセスが遅延のない要素P(z)からなり、その後または前に純粋な時間遅延z−jがあるとする。最初に、遅延のないプラントを考え、コントローラC(z)を設計すると、閉ループの伝達関数は



になる。

0082

目標は、閉ループの動作が



になるように、プラントP(z)z−jのコントローラ



を見つけることであり、これは次の式を



について解くことを伴う。

0083

したがって、新しいコントローラは次のように与えられる。

0084

発明提案のクラウド・コントローラを図5に示す。図5は、(i)遅延補償器を備えたコントローラおよび(ii)インターネット遅延推定器、の2つの主要な要素を示す。図では、遅延補償器を備えたコントローラは、式3で記述されるコントローラのブロック図である点線の枠に示すが、フィードフォワード遅延とフィードバック遅延の組み合わせzk+l、すなわち往復遅延を伴う。これは、遅延のないプロセスP(z)に設計された当初のコントローラであるC(z)を使用する。また、



で表されるプロセスの近似も必要とする。実際には単純な1次または2次の近似で十分である。

0085

第2の要素を図5の黒塗りの枠に示し、この要素はプロセスとコントローラがあるクラウドとの間の往復遅延を推定する。往復遅延は遅延ブロックzk+lで使用される。本発明の一実施形態の遅延推定器は、指数重み付き移動平均(EWMA)を用いてインターネット遅延をDi=αdi+(l−α)Di−lとして推定する。Diは推定平均遅延であり、diは離散時刻iにおける測定遅延である。

0086

同様に、本発明の一実施形態では、指数重み付き移動分散(EWMV)を用いて遅延の分散をVi=α(di−Di)2+(l−α)Vi−lとして推定する。Viは離散時刻iにおける推定分散である。遅延ブロックの遅延値



に調整される。ここでTsであり、hは平均よりも大きい遅延値に対応するための正のパラメータである。したがって、推定器は、短い瞬時の遅延増大過度に反応することなく遅延の変化に順応する。

0087

再度図4(d)に示す遅延ブロックを参照すると、そのような遅延を導入することはシステムの動作にとって問題にはならない。第1に、連続制御システムの大半では、目標値はシステムの全寿命ではなくとも、極めて長い時間にわたって一定に保たれる。そのような定数機能に遅延を加えたバージョンは、それ自体は同じ定数機能になる。第2に、目標値を変更する必要がある場合には、目標値の変更は多くの場合、人間のオペレータによって手動で行われる。数十/数百ミリ秒の遅延を追加しても、オペレータの応答には問題とならない(つまみやソフトウェアのスライダに手を伸ばし、値を更新するには数秒間を要する)。目標値の変更が監視制御によって自動的に行われる場合でも、目標値の値は、通常は、インターネットの往復遅延よりもはるかに長い期間にわたって一定に保たれる。

0088

第3に、プロセスが少なくとも数秒間の時定数を有する分散制御システムのアプリケーションには、そのような目標値の遅延を導入しても実際的な性能の問題は発生しない。最後に、全く異なる文脈で、目標値の操作は遅延の緩和以外の様々な状況で行われる。例えば、目標値の漸増減を行って急な目標値の変化の望ましくない影響を平滑化し、したがって影響を緩和する。目標値の漸増減により、目標値が古い値から新しい値に次第に変化する過渡的な期間が生じる。そのような目標値の漸増減は、一定の時間遅延後に新しい値を有効にする。

0089

要約すると、1つの作為的な遅延ブロックを追加することにより、難しいクラウドの制御問題を、むだ時間を伴うプロセスを制御する問題に変える。後者は、スミス予測器を使用して解決されており、何十年にもわたって実際に使用されている。それにより、元のコントローラの設計や制御対象のプロセスを変更することなくコントローラをクラウドに移すことが可能になる。

0090

2.障害の対処
この項では、コントローラ障害のある状況で正常な動作を補償する分散故障耐性アルゴリズムを説明し、本システムの理論的な性能を分析する。この項では、大半の現実の事例で、本発明の一実施形態のアルゴリズムを使用するクラウド・フィードバック制御が、制御対象のプロセス動作に実質的に影響を及ぼさないことも示す。

0091

大半の実際のシステムでは、コントローラの障害は、業務上必須のプロセスについては、二重の冗長性または最大でも三重の冗長性によって対処される。障害が発生すると、冗長なコントローラがステートフルに引き継ぎ、目標は制御されるプロセスが障害を意識しないようにすることである。通常、冗長なコントローラ同士は近接して配置され、緊密に同期される。そのため、冗長なコントローラは、直接のリンクを通じて、通常数十ミリ秒程度の更新期間で、制御ループの状態を容易に共有する。冗長なクラウド・コントローラから同様の信頼性を提供することはかなり難しい。これは、コントローラは通常、図6に提案されるように、異なるインターネット・プロバイダを通じて(マルチホーミング)、好ましくは異なるデータ・センター、さらには異なるクラウド提供者で、異なる機械で動作するためである。異なる機械を使用すると機械の障害に耐性を有することができるのに対し、異なるデータ・センター(またはクラウド提供者)にまたがって複製し、異なるインターネット・プロバイダを使用すると、インターネット・リンク障害などの状況に対する耐性が高くなる。また、細粒度のクロック同期と、状態の一貫性を短い時間規模で維持することは、ベストエフォットのインターネットを通じて通信する地理的に遠隔に配置される機械の場合には複雑で費用を要する。

0092

提案されるフィードバック制御のクラウド・サービスで信頼性を実現するために、本発明の一実施形態は、すべての冗長なコントローラで非同期に実行される分散障害耐性アルゴリズムを組み込む。このアルゴリズムは高信頼クラウド制御(Reliable Cloud Control:RCC)として知られている。RCCは、二重またはそれより高い冗長性を支援し、以下の保証を提供する。

0093

・G1:主コントローラが故障した場合には、副コントローラが自動的にホットスワップされる。この保証はより高い冗長性に一般化することができる。例えば、三重の冗長性の場合には、主コントローラと副コントローラが故障した場合は、第3のコントローラがホットスワップされる。

0094

・G2:故障した主コントローラが復旧した場合は、主コントローラが引き継ぎ、副コントローラを強制的に停止させる。この保証は、費用節減のために副VMおよび/または副リンクが主VMおよび/または主リンクよりも品質が低くなるように選択される場合に望ましい。この保証もより高い冗長性に一般化することができる。
・G3:コントローラの引き継ぎは滑らかに行われ、望ましくない過渡応答アーチファクトを生じさせない。

0095

RCCがこのような保証を提供するために、システム状態を組(a,u1,u2,u3,...)として定義する。aはアクチュエータによって実行された最後のコントローラ動作であり、uiは冗長コントローラCiによって行われた最後の動作から経過した時間である。すべてのコントローラから見えるように、RCCは状態の組を図6に示すように制御I/Oインターフェース・モジュールのメモリに記憶する。状態の組は、I/Oインターフェースが最初に電源投入される時に初期化される。最後の動作aは、プロセス設計に応じて任意に初期化することができる。最後の動作からの経過時間uiは∞に初期化して、コントローラCiがそれまでに一度も動作していないことを示す。

0096

任意の時間に、RCCは、1つのコントローラをプロセスの制御に関与させ、その他のコントローラは待機状態(またはバックアップ)にする。待機状態のコントローラは引き続きプロセス出力読み取り、準備を行っているが、そのコントローラ自身の次の動作は保留する。RCCは、各サンプリング期間に各コントローラに、ポーリング、演算、および条件付き動作の3つの主要なステップを行う。

0097

ポーリング:各コントローラがI/Oインターフェースをポーリングして、センサの測定値と共に状態の組を求める。

0098

演算:状態および測定値に基づいて、各冗長コントローラが以下を演算する。
(i)コントローラのモード。稼働中または待機中。
(ii)コア制御アルゴリズムを実行することにより、自身の次の制御動作。

0099

条件付き動作:演算ステップで算出されたコントローラのモードに基づいて、各コントローラが自身の動作をプロセスに送信するか、保留するかを決定する。この条件を使用してコントローラの動作を連携させて、1つのみのコントローラがプロセスに動作を送信し、プロセスで維持されている状態の組を更新するようにする。すべての他のコントローラは動作を保留する。

0100

一実施形態では、RCCは、クロック同期を一切必要としない。RCCは、周期的でソフト・リアルタイムタスクであり、その相対的な期限はそのサンプリング期間に等しい。その結果、コア制御アルゴリズムはサンプリング期間ごとに実行され、次の期間が開始する前の任意の時に終了することが必要とされる。プロセスはなおサンプリング期間ごとに1つまたは複数の動作を受け取るので、同じサンプリング期間内に制御動作を遅延しても実行中の制御アルゴリズムを損なうことはない。この2つの理由から、RCCはすべてのVMで非同期に実行することができ、バックアップ・コントローラは主コントローラが起動された後の任意の時に起動することができ、コントローラをホストしているVMのクロックを同期する必要はない。

0101

2.1 詳細な動作
図7は、すべてのコントローラの上で実行されるRCCの疑似コードを示す。一番最初のサイクルに、RCCは、コントローラCiのIDiおよび稼働閾値Diを初期化して、一度に1つのみのコントローラが稼働することを保証する。IDは主コントローラには1に設定され、副コントローラには2に設定され、以下同様に設定される。また、任意のコントローラのペア(Ci,Cj)(ただしi>j)について、稼働閾値はDi>Dj≧Tsを満たさなければならない。Tsはサンプリング期間である。そして、上記の主要ステップがサンプリング期間ごとに実行される。ポーリング・ステップで、I/Oインターフェースから以下の変数を取得する。

0102

(i)ProcessVar:現在のセンサ測定値。
(ii)lastAction:状態変数aの表現。すなわちアクチュエータによって実行された最後の動作。
(iii)lastActionAge:時間カウンタ配列であり、lastActionAge(i)は、状態変数ui、すなわちCiが最後に稼働してから経過した時間を表す。

0103

ポーリング・ステップが例えばリンク障害のためにタイムアウトすると、コントローラは、firstCycleフラグをTRUEにリセットしてから現在のサンプリング期間を飛ばす。疑似コードにおけるこの行は、下記の項2.2で示すように保証G3に関連する。

0104

次いで、演算ステップでコントローラ・モードを決定する。任意のコントローラCiについて、より小さいIDを有する動作中の別のコントローラCjがある場合は、Ciは待機モードで動作することを決定する。一方、すべてのCjについて(ただしj<i)、最後の動作の経過時間ujがDiよりも古い場合は、すべてのコントローラCjが故障したと想定するため、Ciは稼働モードで動作することを決定する。したがって、RCCは、より小さいIDを有するコントローラを求めてlastActionAgeを調べるforループを使用して、フラグiAmEngagedを評価する。次いで、RCCは制御アルゴリズムcontroller()を実行し、これは通常はセンサ測定値processVarだけを必要とする。それでも、一部の制御アルゴリズムについては、保証G3は、下記の項2.2で述べるようにより多くのパラメータを渡すことを指示する。

0105

最後に、条件付き動作ステップで、iAmEngagedフラグがTRUEである場合は演算された動作をプロセスに送る。さらに、ゼロを送信して、最後の動作からの時間を示すカウンタをリセットする。そうではなく、iAmEngagedフラグがFALSEの場合は、このステップは動作を行わない。

0106

一般性を失うことなく、次いで三重の冗長性の事例に着目して、RCC下における3つのコントローラ間の対話を説明する。主コントローラのiAmEngagedフラグは、最も小さいIDを有するので、常にTRUEである。副コントローラが時間カウンタlastActionAge(l)をポーリングする際に、副コントローラは、主コントローラが生きているかどうかを継続的に確認する。

0107

主コントローラが故障した場合は、lastActionAge(l)が副コントローラの稼働閾値を超えた時に、副コントローラがその故障を検出する。その場合、副コントローラのiAmEngagedは、forループ全体にわたってTRUEのままとなる。そのため副コントローラは稼働モードで動作し、したがってI/Oインターフェース中の自身のlastActionAge(2)のエントリをリセットして、自身がたった今動作したことを示す。

0108

第3のコントローラも主コントローラの故障を検出するが、第3のコントローラの稼働閾値は副コントローラの稼働閾値よりも大きい。lastActionAge(l)の値が第3のコントローラの稼働閾値を超える前に、副コントローラがすでに動作しているはずである。そのため、第3のコントローラが次のサンプリング期間で状態をポーリングする時には、時間カウンタlastActionAge(2)はすでにδに増分されて、0<δ<Tsとなっているはずであり、その値は第3のコントローラの稼働閾値より小さく、第3のコントローラのiAmEngagedフラグを強制的にFALSEにする。

0109

第3のコントローラは、主コントローラと副コントローラの両方が使用不可能になった時かつその時に限り稼働する。これにより保証G1に対応する。主コントローラが故障から復旧すると、主コントローラは常に稼働モードで動作しているため、プロセスの制御権を得て、副コントローラを強制的に待機モードにする。主コントローラのlastActionAge(l)をリセットすると、副コントローラは、経過時間が副コントローラの稼働閾値よりも小さい最近の主コントローラの動作を検出する。その結果、副コントローラのiAmEngagedフラグはFALSEになる。したがって、副コントローラは待機モードで動作する。これと同じ事が、より小さいIDのコントローラが故障から復旧した時に任意の2つのコントローラに当てはまる。これにより保証G2を達成する。

0110

2.2 滑らかなコントローラの引き継ぎ
コントローラを切り換えると、プロセス出力に「出っ張り(bump)」が生じる可能性があり、その場合は保証3に反することになる。これは、元のコントローラ動作の最終的な値が新しいコントローラ動作の初期値と等しくない場合に発生する。この主要な理由は、冗長コントローラが必ずしも同時に始動しないためである。大半のコントローラが積分要素を有すると、各自の積分間隔が異なる開始時間を有するため、コントローラの出力は同じにはならない。

0111

クラウド・コントローラ間の滑らかな引き継ぎを実現するために、本発明の一実施形態では、クラウド・コントローラに制御理論のバンプレス切り換え(bumpless transfer)の概念を使用する。バンプレス切り換えは、元々は「手動」から「自動」制御への切り換えを支援するために設計されたものであり、業界で用いられているコントローラの90%以上に相当する大半の商用PIDコントローラサポートされている。PIDコントローラのバンプレス切り換えは、積分器の初期値を調整することによって実現することができる。他のバンプレス切り換え方法が高度な「自動」コントローラのために提案されている。

0112

図8に、図7紹介したPIDcontroller()関数の滑らかな引き継ぎバージョンを示し、これは2つ以上のPIDコントローラ間で切り換えを行う時に滑らかな引き継ぎを保証する。このアルゴリズムは、任意のコントローラからPIDコントローラに切り換える時にも機能する。

0113

図8に示す疑似コードは、標準のPID制御アルゴリズムに滑らかな引き継ぎ機能を付加するために必要な変更に着目している。ほぼすべての商用PIDコントローラが、この変更を実装するためのサポートを備えている。そのようなサポートは別の問題のために提供されるものであるが、本発明の実施形態のクラウド・コントローラに滑らかな引き継ぎをもたらすこともできる。

0114

例えば、稼働モードにあるCiと、待機モードにあるCjの2つのPIDコントローラがあるとする。最初のサンプリング期間を除いて、稼働中のコントローラCiは、if以下の文を飛ばすので、この変更を適用せずにPID制御アルゴリズムを実行する。一方、待機中のコントローラCjは、PIDアルゴリズム比例動作(P)および微分動作(D)を減算した後に、PID積分器の本来の値を強制的に最後の制御動作(稼働中のコントローラCiによって算出される)に等しくすることにより、PID積分器の本来の値を無効にする。このステップでは、Cjの積分器の逸脱を補正し、Ciの積分器と一致するようにする。その結果Cjの出力は常にCiの出力と等しくなる。この条件下で、Ciが故障し、Cjが引き継いだ場合には、CjはCiの最後の動作に等しい動作から開始する。

0115

どのコントローラも、その最初のサンプリング期間、すなわちif条件に示されるようにフラグfirstCycleがTRUEである時に、各自の積分器の初期値を補正する必要がある。それにより、a<bである場合に、復旧したCaと現在稼働中のコントローラCbの間の滑らかな引き継ぎが可能になる。この理由により、図7の疑似コードでタイムアウトすると、RCCはfirstCycleフラグをTRUEに設定する。稼働中のコントローラCaがリンク障害に遭遇し、それによりポーリング・ステップがタイムアウトし、バックアップ・コントローラCbに交換される場合を考える。リンクが復旧した場合には、復旧すると図8でCaのfirstCycleフラグがTRUEになるので、Cbから滑らかな引き継ぎを行った後にCaが再度引き継ぐ。

0116

このアルゴリズムは、以下のシナリオで適用することができる。
・クラウド・コントローラは、高い信頼性を要求するシステムにおいて物理コントローラのバックアップとして機能する。それにより、すべての物理コントローラを複製する場合と比べて大幅な費用の節減を実現することができる。
・ クラウド・コントローラを使用して一時的にシステムを管理し、その間にそのシステムの物理コントローラが障害のために改良または交換される。これは、短い期間だけ必要とされるクラウド・サービスのオンデマンド性適合する。
・ クラウド・コントローラは、プライベートのクラウドに配備して同じ会社の複数の施設にサービスすることができ、それによりすべての施設の制御機能を仮想化された資源にまたがって統合することができる。

0117

このような各事例で、iAmEngagedフラグは、現在プロセスを制御しているコントローラについてTRUEに設定される。同じフラグがすべての他のコントローラについてはFALSEに設定される。コントローラを切り換える必要がある時にはiAmEngagedフラグが反転される。直近に交換されたコントローラは最後に適用された動作と等しい動作から開始する。

0118

2.3論理的論証
次いで、クラウドに置かれるコントローラ、ホスト側のVM、ホスト側のサーバ、ネットワーク・スイッチ、およびインターネット・リンクのためのフェイルストップ障害モデルを説明する。以下の説明では保証G1〜G3を正式に証明する。

0119

定理
提案されるRCCアルゴリズムは、少なくとも1つのリンクを通じてアクセスできる動作中のコントローラが少なくとも1つある限り、制御されるプロセスの正常な動作を保証する。

0120

証明
Ψが正常なコントローラの非空集合であるとする。さらに、Cs∈Ψが最も小さいID「s」および最も小さい稼働閾値Dsを有するコントローラであるとする。正常でないすべてのコントローラCi∈/Ψかつi<sについて、Ciは状態の組を更新することができないので、最後の動作からの経過時間カウンタuiは増大し続ける。したがって、uiの値は、すべてがCsの稼働閾値、すなわちDsを超えるまで増加し続ける。Dsを超えると、iAmEngagedフラグが演算ステップでTRUEと評価されるため、Csが稼働状態になる。Csが稼働状態になると、Csは状態の組の最後の動作からの経過時間カウンタをリセットする。他の生きているコントローラCj∈Ψ\{Cs}は、カウンタ値が各自の稼働閾値Djよりも小さいので、そのリセット事象を観察する。その結果、各コントローラのiAmEngagedフラグがFALSEに設定され、それらコントローラに強制的に動作を保留させる。したがって、動作中で到達可能なコントローラが少なくとも1つある限り、常に正確に1つのコントローラがプロセスを管理していることになる。

0121

定理2
元の制御アルゴリズムが、障害のない条件下でゼロの行き過ぎ量とゼロの定常状態誤差を保証する場合、RCCアルゴリズムは、動作中の到達可能なコントローラが1つあれば、障害のある条件下で同じ行き過ぎ量と定常状態誤差の性能を保証する。

0122

証明
稼働中のコントローラCiが離散時刻n=kに故障するとする。バックアップ・コントローラCjの最初の動作は、有限数のサンプリング期間



の後にプロセスに到達する。RTTjはCjとプロセスの間の往復インターネット遅延であり、DjはCjの稼働閾値であり、Tsはサンプリング期間である。この時間中に、制御I/OインターフェースはCiから受け取った最後の動作を適用する。この動作はm[k−1]であり、m[n]はコントローラの出力信号である。

0123

以下の説明でm[k−1]が有限の値であることを証明し、m[k−1]を



サンプリング期間遅らせても行き過ぎ量または定常状態誤差に影響しないことを証明する。

0124

まず、以下の説明で、m[k−1]が有限であることを証明する。稼働中のコントローラCiが障害のない条件下でゼロの行き過ぎ量および定常状態誤差を保証すると仮定すると、プロセス変量y[n]は、振動せずにその初期値から目標値に収束する。目標値r[n]はn>0の場合には定数関数になるため、誤差信号e[n]=r[n]−y[n]は、振動せずにその有限の初期値からゼロに収束し、これは、E(z)が安定な非振動極、すなわちz平面の単位円の内側にある正の実数極を有することを意味する。誤差は入力としてコントローラに渡される。

0125

コントローラの伝達関数Ci(z)は、単位円の内側または上に正の実数極を有する。例えば、実際に使用される最も一般的なコントローラであるPIDコントローラは、単位円の外側には極を有しない(z=1、すなわち単位円上に1つのみの極を有する)。したがって、M(z)=E(z)Ci(z)であるコントローラ出力は、安定な極と、単位円のz=1に最大で1つの極を有する。これは、安定伝達関数(E(z)およびCi(z)のすべての他の安定な極)に単位ステップ入力(z=1の極)を適用した結果生じる信号と正確に等しい。

0126

したがって、コントローラ出力信号m[n]は、その有限の初期値から有限の最終値に振動せずに収束する。その結果、引き継ぎ中にI/Oインターフェースで保持される信号m[k−1]は、m[0]からlimn→∞m[n]の間になり、これらはどちらも有限である。制御動作の最終値はプロセスの行き過ぎを生じさせないため、中間の動作を遅らせてもプロセスの行き過ぎは発生しない。その理由は、大半の現実のプロセスは開ループの安定プロセスであるからである。稀ではあるが開ループの不安定プロセスの場合には、プロセス側で適切な補償が想定される。バックアップ・コントローラCjがゼロの行き過ぎ量およびゼロの定常状態値を生成する制御アルゴリズムを実行すると仮定すると、バックアップ・コントローラCjが引き継ぐ時には、振動せずに、すなわちゼロの定常状態誤差およびゼロの行き過ぎ量で、プロセス変量を中間値からその所望の最終値に制御する。

0127

定理3
1つの障害がある状況における整定時間tsの最悪の事例の増加は、インターネットの往復遅延RTTjおよびバックアップ・コントローラCjの稼働閾値Djが上限となり、



によって与えられ、Tsはサンプリング期間である。

0128

証明
この証明は当業者には単純明快なものである。簡潔のために、最終結果は微分を含めずに示す。一般性を失うことなく、単位利得システムをその支配的な時定数で表し、その支配的な時定数の10%ごとに周期的にサンプリングし、これはサンプリング期間を設計する際の経験則である。そのようなシステムのステップ応答は、y[n]=(1/11)δ[n]+u[n−1]−(10/11)n+2として導出することができる。障害がない条件下での整定時間tsは、プロセスが最終値の5%以内にとどまるのに要する時間として定義される。障害のない条件下では整定時間ts0は30サンプリング期間として得られる。離散時刻k>0に障害が発生した時に同様の分析を使用する。

0129

障害下では、tsfは3つの成分を有する。
(i)ts1。この時間中に、最初のコントローラCiが故障する前にプロセス出力を0から中間値0<α<1に制御する。その結果、ts1=log(1−α)/log(10/11)−2になる。

0130

(ii)ts2。これはCjが障害を検出し、それに応答するのにかかる時間である。この時間中、コントローラ出力はm[k−1]に保持され、プロセス出力は下限であるαになる(1次の遅れによる。プロセスは実際にはβに進み、ここで0≦α≦β≦1であり、これはより良好なシナリオである)。定理2の証明は、



であることを示す。

0131

(iii)ts3。この時間中にCjはプロセス出力をαから0.95に制御する。その結果、ts3=(log(0.05)−log(1−α))/log(10/11)−2になる。
上記から、



という結論に達する。

0132

現実のプロセスは数秒程度の時間制約があり、したがって、数百ミリ秒程度のサンプリング期間を有する。その結果、インターネットは、通常、往復遅延γTsを発生させる。ただし、γ<1である。遅延閾値を2サンプリング期間に等しく設定した場合は、整定時間の最悪事例の変化は



になる。整定時間の1サンプリング間隔の変化は1/30=3.3%の増加に相当し、これは小さな量である。大半のプロセスは動作時間の大部分は定常状態で動作し、障害は整定時間に変化を生じさせないことに注目すべきである。

0133

定理4
RCCアルゴリズムは、コントローラが復旧した時にプロセス応答に変化が生じないことを保証する。

0134

証明
コントローラCjが現在稼働中であるとする。Ci(ただし、i<j)に障害が発生したが、現在は復旧しているとする。Ciはより小さいIDを有するため、Ciが稼働し、制御I/Oインターフェースで維持されている状態の更新を開始する。Ciが復旧していることをCjが検出するのに



サンプリング期間を要する。

0135

これらのサンプリング期間各々に、プロセスは各コントローラから1つずつ、2つの制御動作を同時に受け取る。図8の滑らかな引き継ぎアルゴリズムにより、CiはCjの最後の動作から開始する。両方のコントローラが動作している全期間を通じて、両者は同じサンプリング期間内に同じ動作を送信する。したがって、応答は1つのみのコントローラが稼働している場合と変わらない。この期間の後、Cjが待機状態に切り替わるとCiは完全に引き継ぐ。

0136

3.評価
この項では、本発明により提案されるクラウドを利用した制御方式の性能を厳格に評価する。以下の説明では、本発明の一実施形態のクラウドに置かれたコントローラが8000マイル離れた場所に配置される産業用プラントをどのように効果的に制御するかを示す。以下の説明では、本発明の一実施形態がどのようにして大きなインターネット遅延を緩和し、障害時に冗長コントローラを動的に切り換えて、制御対象の産業用プラントの滑らかで確実な動作を実現することができるかも実証する。

0137

試験の目的で、本発明の一実施形態を、オートメーション産業と試験所の検査の両方で標準となっているLabVIEWソフトウェアで実装した。本発明の方式は、PID制御方法で評価した。これは、この方法が実際に使用されている最も一般的な方法であるためである。LabVIEWPIDコントローラを、Amazonクラウド2のMicrosoft Windows(登録商標) Serverのインスタンスに配置した。LabVIEWを使用して、アメリカ西海岸に配置されるサーバで中規模の産業用プラントの模擬も行った。LabVIEWによって提供される標準のModbus/TCPプロトコルをプラントのプロセスとクラウド・コントローラの間の通信に使用した。図9に示すように、2つのクラウド・コントローラを、プラントから最も遠くに配置される利用可能な(遅延の点で)Amazonクラウドの場所であるシンガポールブラジルのサンパウロに配置した。

0138

3.1実験の設定
模擬した産業用プラントは、図10に示す太陽熱発電プラントであった。太陽熱発電プラントの動作は、合成オイル・サイクル、塩サイクル、蒸気サイクル、および凝縮サイクルの4つの主要なプロセス・サイクルに分けられる。オイル・サイクルでは太陽エネルギーを集め、塩サイクルでそのエネルギーを保存して後に給熱する。蒸気サイクルと凝縮サイクルは、蒸気タービンの操作を担う。オイル・サイクルは太陽光集光ミラーで開始し、ミラーは、オイルの中を通る水平方向のパイプに沿って太陽の熱を集める。オイルがその熱を吸収し、その熱を2つに分岐して渡し、塩サイクルおよび蒸気サイクルと作用させる。

0139

塩サイクルは、蓄熱と給熱の2つのモードを有する。オイルに吸収された熱がプラントを稼働させるのに必要な量を超えると、塩が冷たいタンクから熱いタンクに供給されて過剰な熱を蓄熱する。太陽エネルギーが必要レベルを下回ると(例えば曇天のため)、塩の流れる方向を逆にしてオイルに熱を供給する。オイルは熱交換器に供給されて水を加熱して蒸気を発生させる。太陽熱と塩で供給される熱が必要レベルを下回る場合は、天然ガスの加熱器を使用して気化温度を維持する。

0140

加圧された蒸気が蒸気タービンに供給され、それにより電力網に接続された発電機を駆動する。最後のサイクルは、タービンの下流側で真空状態を作り出すために必要な蒸気の凝縮であり、これは効率的な蒸気サイクルのために必要とされる。

0141

太陽熱発電プラントを制御するために、9つの制御ループを特定し、それを図10に示す。(i)太陽光集光ミラーのための3つの角度位置ループ、(ii)3つのフロー制御ループ。2つがオイル・サイクルに、1つが蒸気サイクルに対応する。(iii)3つの温度コントローラ。1つがオイル・サイクルに、1つが蒸気サイクルに、1つが凝縮サイクルに対応する。図を簡潔にするために、追加的な制御ループ(例えばタービンに対応する)は図示していない。

0142

性能の結果は、上記3つのグループそれぞれから1つずつ、3つの代表的な制御ループから与えられる。それらループの伝達関数を導出し、各自のPIDクラウド・コントローラは、Ziegler−Nichols法を使用して設計し、試行錯誤により微調整した。制御ループごとに、制御されるプロセスの状態が周期的にサンプリングされ、対応するコントローラによって取得され、コントローラは適切な動作を算出し、そのプロセスのアクチュエータにその動作を送り返す。サンプリング期間は、通常は、プロセスの支配的な時定数の10%に設定される。大半の連続産業プロセスは、0.5〜2.0秒の範囲のサンプリング期間を有する。

0143

支配的な時定数は、評価で検討対象とした制御ループについて算出し、サンプリング期間は、控えめに1秒間の最大サンプリング期間で時定数の10%に設定した。サンプリング期間をより小さくすると、より迅速な応答が必要になるため、クラウドを利用した制御方式に負荷がかかる。プラントの性能は、通常のインターネット遅延下で調べると共に、方式をストレス試験するために模擬された大きなランダムの遅延下でも調べる。性能は、コントローラおよび/またはインターネット・リンクに障害が発生した時に分析される。プラントがステップ入力または外乱を受けた時に、最も一般的な制御理論性能の指標を検討する。それらの指標は、(i)最大行き過ぎ量の割合(Mp)、すなわち最大行き過ぎ量と最終値との正規化された差;(ii)定常状態誤差(ess)、すなわち目標値とステップ応答の最終値との差;および整定時間(ts)、すなわち最終値の5%以内にとどまるために応答が要する時間、である

0144

3.2インターネット遅延下の性能
以下の項では、クラウドを利用した制御方式の実現可能性を実証する。

0145

以下の説明では、クラウド・コントローラがローカル・コントローラと同じ性能をもたらすことを示す。制御ループのうち2つを図10に示す。(i)AC1で示される太陽光集光器の位置決めプロセスと、(ii)TC1で示される温度制御プロセスであり、温度制御プロセスでは塩が畜熱または給熱してオイルの温度を調節する。

0146

太陽光集光器の位置決
太陽光集光器は、重量1,000kgの可動部品を備える。放物トラフ・ミラーは、1mの焦点距離を有する。集光器は、ミラーの焦点軸を中心に回転する。歯車比100のギヤボックスを備える大型のDCモータが集光器を駆動する。伝達関数は、Θ(s)/Vf(s)=0.1/(s3+18s2+80s+10)として導出される。Θ(s)およびVf(s)はそれぞれ集光器の角度位置のラプラス変換関数とDCモータの界磁回路印加される電圧である。この伝達関数の支配的な時定数は7.77sである。したがって、750msのサンプリング期間を選択した。

0147

望ましい集光器の角度位置は、arccos(cos(g)sin(a))として導出される。ここで、gは太陽の高度角度であり、aはから測定された方位角である。太陽の角度の変化は、2012年7月1日にテキサスヒュストンで1時間にわたって模擬した。望ましい集光器角度は、午前10:00から午前11:00の間に44.3度から57.1度に漸進的に変化する。集光器の初期位置はゼロ度であった。風による外乱の影響を午前10:20から10:40の間に模擬したが、この影響はこの期間の前半に増加し、後半に減少する。適用された外乱は最大で7度の影響を有する。外乱の伝達関数はΘ(s)/Df(s)=75×10−5/(s2+7.6s+0.75)により近似され、Df(s)は風力外乱のラプラス変換である。

0148

図11に結果を示し、同図には所望の集光器角度(目標値)をグラフ化している。クラウド・フィードバック・コントローラ(クラウドFB)および模擬したプロセス(ローカルFB)と同じ機械で稼働するコントローラによって達成された角度はどちらも、プロセスの性能を所望の目標値に維持した。図11(a)では、開ループのコントローラで達成された角度を示すことにより、風の外乱の重要性を示している。図11(a)の結果は、クラウド・コントローラがローカル・コントローラと同等に機能したことを明確に示している。図11(b)は、最初の4分間を拡大して過渡応答を示し、一方図11(c)は、風の外乱が発生した対象期間の前半を拡大している。両図とも、本発明が提案するクラウド・コントローラ(数千マイル離れた場所に配置された)の性能が、ローカル・コントローラの性能と区別がつかないことを立証している。

0149

オイル温度の調節
上記の実験を温度制御プロセスについても繰り返したが、温度制御プロセスは太陽光集光器の位置決めプロセスとはかなり異なる。この温度制御プロセスでは、オイルの温度を調節するために、塩が畜熱するかまたは給熱するか、および畜熱/給熱する熱の量を決定する。図10のTT1で測定される温度はオイル・サイクル全体の動作に依存する。そのため、2つのオイル熱交換器の動作を模擬した。太陽光集光器は追加的な熱交換器として模擬した。熱交換器は、支配的な時定数が20〜30秒の間である伝達関数を用いて模擬した。塩の相互作用の伝達関数は、O(s)/Vp(s)=5/(25s+1)(3s+1)によって与えられる。O(s)およびVp(s)はそれぞれ排出オイル温度のラプラス変換関数とポンプモータ駆動装置に印加される電圧である。1時間にわたる一時的な曇天条件の影響も模擬した。この外乱の伝達関数は、時定数が5分間の1次システムとして近似される。プロセス全体の支配的な時定数は189秒と算出されるが、1秒の最大サンプリング期間を使用してシステムに負荷を与えた。

0150

図12(a)に13:00から15:00までの2時間の結果を示し、13:30から14:30の間に一時的な曇天の外乱が発生している。図12(a)は、クラウド・コントローラがローカル・コントローラと同じように温度を目標値に維持していることを示し、一方温度は開ループ・コントローラの下では目標値から大幅に外れている。図12(b)は、13:15から14:00までの期間を拡大して、クラウド・コントローラとローカル・コントローラが両方とも外乱に良好に対処したことを示している。2つのコントローラが取った動作をさらに説明するために、図12(c)に、曇天条件で生じた外乱を緩和するために2つのコントローラが塩の流れる方向を逆にして蓄熱する方向から給熱する方向にした様子をグラフで示す。図12(c)のy軸の負の値は畜熱を意味し、正の値は給熱を意味する。

0151

3.3 大きな作為的な遅延下の性能
システムの堅牢性を試験し、遅延補償器の効果を示すために、短い時定数でプロセスを制御する際に大きな無作為の遅延を作為的に挿入する。(100,70,500)msの(平均μ、標準偏差σ、および最大値max)の近似値を有する遅延分散を使用したが、x軸を換算係数乗算して遅延を大幅に増大させる。10、20、および40の換算係数を使用して確率分布を適切に調整し、曲線の下にある面積が1に等しい状態を保つようにする。この調整により、(μ,σ,max)の値がそれぞれ(1, 0.7, 5)秒、(2, 1.4, 10)秒、(4, 2.8, 20)秒の過剰な遅延を得る。これらの大きな遅延は、クラウド・コントローラと模擬されるプラント動作との間に加える。そのような分散下では、パケットは高変動の遅延を受け、それによりパケットは正しくない順序到着した。それらの遅延は、ルータ輻輳が発生する時の状況、過渡的なルーティング・ループの形成、またはネットワーク・リンクの障害や復旧による経路選定表の変化に相当する可能性がある。

0152

図10でFC3によって示される水の流動プロセスを評価した。3秒の短い時定数を想定し、したがって300msのサンプリング期間を使用する。挿入される遅延はサンプリング期間より一桁大きい。遅延分散ごとに、本発明の一実施形態の遅延補償器を使用した実験と使用しない実験を行う。本発明の遅延補償器の遅延ブロックは



に設定し、Tsはサンプリング期間である。したがって、検討する3種類の遅延分散について、遅延ブロックはそれぞれz−10、z−20、およびz−40に設定される。

補償を行った場合の性能と補償を行わない場合の性能を、基準となるゼロ遅延の事例と比較する。補償を行った事例については、各実験を10回繰り返し、最悪の性能を選択する。この実験の結果を3種類の遅延分散について図13に示す。図13は、加えられる遅延が大きいほど、「補償なし」のクラウドの制御ループが行き過ぎとなり(図13(a)および図11(b))、最終的に不安定になる(図13(c))ことを示している。それに対して、本発明の一実施形態の遅延補償器は、明らかな行き過ぎを起こさずに滑らかな応答を維持している。

0153

図14に示す表1は、本発明の一実施形態の遅延補償器を使用した場合の性能指標(「補償あり」)と使用しない場合の性能指標(「補償なし」)を要約したものである。

0154

最大行き過ぎ量および定常状態誤差に関しては、補償ありのコントローラは4つの分散すべてにわたって同じ性能を維持した。すなわち、本システムは、そのような極端遅延条件下で性能が低下せず、遅延がなかったかのように機能した。唯一の小さな例外は最後の分散(μ=4s,σ=2.8s,max=20s)の最大行き過ぎ量であり、これは0.3%として現れたが、これは実質的にゼロとみなされる。

0155

一方、補償しないコントローラの性能は、挿入された遅延が増大するにつれて低下し続けた。そのため、遅延のない状況のゼロの最大行き過ぎ量およびゼロの定常状態誤差から推移して、最後の遅延分散下では不安定になり、この状況では(観測可能な)最大行き過ぎ量が大幅に増大して170.9%になり、定常状態誤差は未確定になり、したがって表1の「未確定」項目となる。整定時間は、補償ありのコントローラと補償なしのコントローラの両方で挿入される遅延と共に増大したが、補償ありのコントローラは3番目および4番目の遅延分散(μ=2,4s,σ=1.4,2.8s,max=10,20s)で補償なしのコントローラに比べて大幅に良好に機能した。最後の分散については、補償なしのコントローラは不安定になり、整定状態に達することはなく、したがって表1の「未確定」整定時間となった。

0156

要約すると、本システムは、最大で20秒、すなわち300msのサンプリング期間の66倍という極端に大きい遅延の下で目標値(ステップ入力)を急激に変化させるという極端な条件下で試験した。そのような極端に困難な条件は、制御されるプロセスを不安定にするはずであり、補償のないコントローラでそれが発生した。しかし、そのような極端な条件下でも、本システムは、整定時間を増大させるだけで、被制御プロセスの行き過ぎや最終値からの逸脱を防ぐ。ただし、正常な条件下では、整定時間は、現実の遅延の実験の場合のように、(ゼロでないにしても)安定した増大を起こす。

0157

3.4障害耐性および滑らかな引き継ぎ
この項では、クラウドに置かれたコントローラが障害が発生した場合にどのように滑らかな引き継ぎを実現するかを示す。2つの冗長なコントローラを図9に示すように配置して現実の遅延を用いた実験を繰り返す。障害がある状況下でのRCCアルゴリズムの時間応答を障害のない場合と比較する。図10に示す水流プロセス(FT3、FC3)にステップ入力を導入する。5秒の支配的な時定数を想定し、したがって500msのサンプリング期間を想定する。ステップ入力はt=0sに印加される。主コントローラは、t=18sにTCP接続を無効にすることによって故障させ、主コントローラはt=170sに動作に復旧する。これらの時刻は、過渡状態中に1回の引き継ぎ事象が発生し、定常状態中にもう1回引き継ぎ事象が発生するように選択される。

0158

水流プロセスの正規化した応答をグラフ化したものを図14(a)に示す。この結果は、RCCアルゴリズムが障害の緩和に成功したことを示し、性能は障害がないかのように見える。同じグラフにRCCを用いない場合の結果を示すが、これは障害のために応答が遅延し、滑らかな引き継ぎを行う機構がないために行き過ぎが出現していることを示している。副コントローラの稼働閾値は4サンプリング期間(2秒)に設定し、そのため整定時間は障害のない条件下の78秒からRCCで対処された障害下の80秒まで2.6%増大した。

0159

滑らかな引き継ぎ方法の重要性を示すために、RCCの滑らかな引き継ぎ機能を無効にした状態で同じ実験を行い、その結果を図14(b)のグラフに示す。滑らかな引き継ぎ能力を有しないコントローラ(「RCC(滑らかな引き継ぎなし)」)は所望の目標値に近い応答を維持した。しかし、引き継ぎ事象時にプロセス出力に2回の上昇を生じさせた。したがって、滑らかな引き継ぎ機能は、障害下で滑らかな応答を保証するために重要である。

0160

4.結論
新しいクラウド・サービスとして自動的なフィードバック制御を提供することには、産業システム演算システム、および通信システムを含む多くの実用システムにいくつかの潜在的な利益を有する。クラウド・コントローラは、既存コントローラにとって代わる、またはそのバックアップとして機能し、費用の節減と機敏性を提供する。ただし、タイムリーかつ高信頼に感知動作データを通信することは大きな課題である。

0161

本発明の実施形態は、フィードバック制御をクラウド・サービスとして提供する方法およびアーキテクチャを提供する。本発明の実施形態の方法は、(i)元のコントローラ設計に影響したり、被制御システムに追加的な支援を要求したりすることなく、可変のインターネット遅延を緩和し、(ii)非同期アルゴリズムを通じて信頼性を付加して障害時にバックアップ・コントローラを自動的にホットスワップし、(iii)コントローラ間の滑らかな引き継ぎを保証する。すべての方法は現在の産業用パッケージで対応可能である。

0162

実験結果は、本発明の一実施形態が苛酷な条件すべてを緩和してローカル・コントローラと同等の性能を発揮するために、制御されるシステムが苛酷な条件の影響を受けなかったことを示している。このように、フィードバック制御のクラウド・サービスは、クラウド・コンピューティング・モデルで保証されるより低い費用と高い機敏性で同等の性能を発揮することができる。

0163

本明細書における「comprise」は、「includesまたはconsists of」を意味し、「comprising」は「includingまたはconsisting of」を意味する。

0164

本発明の実施形態の態様を実施するために利用可能な技術には以下がある(非特許文献参照)。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ