特許 6382225 制御システム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6382225

(24)【登録日】2018年8月10日

(45)【発行日】2018年8月29日

(54)【発明の名称】制御システム

(51)【国際特許分類】

   G05B 9/03 20060101AFI20180820BHJP

   H04M 11/00 20060101ALI20180820BHJP

   H04Q 9/00 20060101ALI20180820BHJP

   H04Q 9/02 20060101ALI20180820BHJP

   G05B 13/04 20060101ALI20180820BHJP

【ＦＩ】

   G05B9/03

   H04M11/00 301

   H04Q9/00 321B

   H04Q9/00 331Z

   H04Q9/02 C

   H04Q9/00 321D

   G05B13/04

【請求項の数】19

【全頁数】37

(21)【出願番号】特願2015-556405(P2015-556405)

(86)(22)【出願日】2013年4月26日

(65)【公表番号】特表2016-519344(P2016-519344A)

(43)【公表日】2016年6月30日

(86)【国際出願番号】EP2013058792

(87)【国際公開番号】WO2014124701

(87)【国際公開日】20140821

【審査請求日】2016年2月26日

(31)【優先権主張番号】1302534.1

(32)【優先日】2013年2月13日

(33)【優先権主張国】GB

(73)【特許権者】

【識別番号】514318046

【氏名又は名称】カタール・ファウンデーション

【氏名又は名称原語表記】ＱＡＴＡＲ ＦＯＵＮＤＡＴＩＯＮ

(74)【代理人】

【識別番号】100118913

【弁理士】

【氏名又は名称】上田 邦生

(74)【代理人】

【識別番号】100112737

【弁理士】

【氏名又は名称】藤田 考晴

(74)【代理人】

【識別番号】100136168

【弁理士】

【氏名又は名称】川上 美紀

(72)【発明者】

【氏名】タミル エー． ヘガジー

【審査官】 稲垣 浩司

(56)【参考文献】

【文献】 特表２００４−５１１８４５（ＪＰ，Ａ）

【文献】 特開２００１−２４２９３０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０５Ｂ ９／０２ − ９／０３

Ｇ０５Ｂ １３／０４

Ｇ０５Ｂ ２１／０２

Ｈ０４Ｍ １１／００

Ｈ０４Ｑ ９／００ − ９／０２

(57)【特許請求の範囲】

【請求項1】

制御システムであって、
第１のハードウェア要素と、
第２のハードウェア要素と、
前記第１および第２のハードウェア要素から遠隔に配置されるサーバであって、前記第１および第２のハードウェア要素が前記サーバと通信状態にあり、前記第１および第２のハードウェア要素と前記サーバとの間で現場レベルのプロトコルを使用してデータを通信することができる、サーバと、
該サーバで実行されるサービスとして実装される主制御モジュールであって、前記制御システム内の直接制御層の一部を形成し、前記現場レベルのプロトコルを使用して前記第１および第２ハードウェア要素と通信して前記第１および第２のハードウェア要素のうちの少なくとも１つを制御するように動作することができる主制御モジュールと、
前記サーバで実行されるサービスとして実装される副制御モジュールであって、前記第１および第２のハードウェア要素と通信して前記第１および第２のハードウェア要素のうちの少なくとも１つを制御するように動作することが可能な副制御モジュールとを備え、
各制御モジュールは、前記第１および第２のハードウェア要素に制御動作を送信しない待機モードと、前記第１および第２のハードウェア要素に制御動作を送信する稼働モードとで動作するように構成され、
各制御モジュールは、通信して他方の制御モジュールの動作モードを確認するように動作することができ、他方の制御モジュールが前記稼働モードで動作していない場合は、一方の制御モジュールが前記稼働モードに切り替わるように動作することが可能であり、
前記システムの初期化時に、前記主制御モジュールが前記稼働モードで動作し、前記副制御モジュールが前記待機モードで動作する制御システム。

【請求項2】

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

【請求項3】

前記第１および第２のハードウェア要素の１つが、センサおよびアクチュエータのうちの少なくとも１つである請求項１に記載の制御システム。

【請求項4】

前記第１および第２のハードウェア要素および前記サーバが、クラウドネットワークの一部を形成する請求項１に記載の制御システム。

【請求項5】

前記サーバと通信状態にあり、ユーザが前記サーバと対話して前記主制御モジュールを監視および制御できるようにするユーザ・インターフェースを備え、
該ユーザ・インターフェースが、サービスとしてのプラットフォーム（ＰａａＳ）またはサービスとしてのソフトウェア（ＳａａＳ）として実装される請求項１に記載の制御システム。

【請求項6】

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

【請求項7】

前記第１および第２のハードウェア要素が、プロセス変量を出力し、
前記プロセス変量を前記主制御モジュールの入力に伝達するフィードバック・ループと、
前記プロセス変量を遅延補償値によって修正して、前記主制御モジュールと前記第１および第２のハードウェア要素との間の通信の遅延を補償する遅延補償モジュールと、
前記プロセス変量を受け取る第１の入力および基準値を受け取る第２の入力とを含む比較装置とを備え、
該比較装置は、前記プロセス変量を前記基準値と比較し、前記主制御モジュールの入力に比較値を出力し、
前記遅延補償モジュールは、前記プロセス変量または誤差値を前記遅延補償値によって修正する、請求項１に記載の制御システム。

【請求項8】

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

【請求項9】

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

【請求項10】

前記主制御モジュールと前記第１および第２のハードウェア要素のうちの少なくとも１つとの間の通信の往復時間遅延を推定するように動作することが可能な遅延推定モジュールを備える請求項７に記載の制御システム。

【請求項11】

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

【請求項12】

入力／出力（Ｉ／Ｏ）インターフェースを備え、
各制御モジュールが、前記Ｉ／Ｏインターフェースと通信するために接続され、
前記Ｉ／Ｏインターフェースは、各制御モジュールが最後に稼働して前記第１および第２のハードウェア要素のうちの少なくとも１つに制御データを通信してからの時間を示す時間値を記録するように動作することが可能な時間記録モジュールを含み、
各制御モジュールは、所定のサンプリング期間にわたって前記Ｉ／Ｏインターフェースをポーリングして、他方の制御モジュールの時間記録モジュールによって記録された前記時間値を判定するように動作することが可能である請求項１に記載の制御システム。

【請求項13】

前記主制御モジュールに第１のＩＤ番号が割り当てられ、
前記副制御モジュールに、前記第１のＩＤ番号よりも大きい第２のＩＤ番号が割り当てられ、
最も小さいＩＤ番号を有する制御モジュールが、前記稼働モードで動作するように構成される請求項１に記載の制御システム。

【請求項14】

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

【請求項15】

少なくとも１つの制御モジュールが、その他の制御モジュールのうちの少なくとも１つとは異なるサーバであり、かつ／または、前記その他の制御モジュールのうちの少なくとも１つとは異なる地理的場所に配置されたサーバで実行されるサービスとして実装される請求項１４に記載の制御システム。

【請求項16】

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

【請求項17】

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

【請求項18】

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

【請求項19】

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

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】Ｔ． Ａｂｄｅｌｚａｈｅｒ， Ｙ． Ｄｉａｏ， Ｊ． Ｌ． Ｈｅｌｌｅｒｓｔｅｉｎ， Ｃ． Ｌｕ， ａｎｄ Ｘ． Ｚｈｕ． Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｃｏｎｔｒｏｌ Ｔｈｅｏｒｙ Ａｎｄ Ｉｔｓ Ａｐｐｌｉｃａｔｉｏｎ ｔｏ Ｃｏｍｐｕｔｉｎｇ Ｓｙｓｔｅｍｓ Ｐｅｒｆｏｒｍａｎｃｅ Ｍｏｄｅｌｉｎｇ ａｎｄ Ｅｎｇｉｎｅｅｒｉｎｇ． Ｉｎ Ｐｅｒｆｏｒｍａｎｃｅ Ｍｏｄｅｌｉｎｇ ａｎｄ Ｅｎｇｉｎｅｅｒｉｎｇ， ｃｈａｐｔｅｒ ７， ｐａｇｅｓ １８５−２１５． Ｓｐｒｉｎｇｅｒ ＵＳ， ２００８．

【非特許文献2】Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｍｏｄｂｕｓ ＴＣＰ／ＩＰ （ｗｈｉｔｅ ｐａｐｅｒ）． ｈｔｔｐ：／／ｗｗｗ．ａｃｒｏｍａｇ．ｃｏｍ／ｓｉｔｅｓ／ ｄｅｆａｕｌｔ／ｆｉｌｅｓ／Ａｃｒｏｍａｇ＿Ｉｎｔｒｏ＿ＭｏｄｂｕｓＴＣＰ＿７６５Ａ．ｐｄｆ， ２００５．

【非特許文献3】Ｍ． Ｂａｎｄｙｏｐａｄｈｙａｙ． Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔｈｅｏｒｙ ａｎｄ Ｐｒａｃｔｉｃｅ． Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ ｏｆ Ｉｎｄｉａ， ２００６．

【非特許文献4】Ｊ． Ｂｅｎｄｔｓｅｎ， Ｊ． Ｓｔｏｕｓｔｒｕｐ， ａｎｄ Ｋ． Ｔｒａｎｇｂａｅｋ． Ｂｕｍｐｌｅｓｓ ｔｒａｎｓｆｅｒ ｂｅｔｗｅｅｎ ａｄｖａｎｃｅｄ ｃｏｎｔｒｏｌｌｅｒｓ ｗｉｔｈ ａｐｐｌｉｃａｔｉｏｎｓ ｔｏ ｐｏｗｅｒ ｐｌａｎｔ ｃｏｎｔｒｏｌ． Ｉｎ Ｐｒｏｃ． ｏｆ ＩＥＥＥ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄｅｃｉｓｉｏｎ ａｎｄ Ｃｏｎｔｒｏｌ， ｖｏｌｕｍｅ ３， ｐａｇｅｓ ２０５９−６４， Ｄｅｃ ２００３．

【非特許文献5】Ｓ． Ｂｈａｔｔａｃｈａｒｙｙａ， Ａ． Ｄａｔｔａ， ａｎｄ Ｌ． Ｋｅｅｌ． Ｌｉｎｅａｒ Ｃｏｎｔｒｏｌ Ｔｈｅｏｒｙ： Ｓｔｒｕｃｔｕｒｅ， Ｒｏｂｕｓｔｎｅｓｓ， Ａｎｄ Ｏｐｔｉｍｉｚａｔｉｏｎ． ＣＲＣ Ｐｒｅｓｓ， ２００９．

【非特許文献6】Ｍ． Ｂｊｏｒｋｑｖｉｓｔ， Ｌ． Ｃｈｅｎ， Ｍ． Ｖｕｋｏｌｉｃ， ａｎｄ Ｚ． Ｘｉ． Ｍｉｎｉｍｉｚｉｎｇ ｒｅｔｒｉｅｖａｌ ｌａｔｅｎｃｙ ｆｏｒ ｃｏｎｔｅｎｔ ｃｌｏｕｄ． Ｉｎ Ｐｒｏｃ． ｏｆ ＩＥＥＥ ＩＮＦＯＣＯＭ， ２０１１．

【非特許文献7】Ｙ． Ｃｈｅｎ， Ｚ． Ｄｕ， ａｎｄ Ｍ． Ｇａｒｃｉａ−Ａｃｏｓｔａ． Ｒｏｂｏｔ ａｓ ａ ｓｅｒｖｉｃｅ ｉｎ ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ． Ｉｎ Ｐｒｏｃ． ｏｆ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ｓｙｓｔｅｍ Ｅｎｇｉｎｅｅｒｉｎｇ， ２０１０．

【非特許文献8】Ｚ． Ｃｈｅｎ， Ｌ． Ｌｉｕ， ａｎｄ Ｘ． Ｙｉｎ． Ｎｅｔｗｏｒｋｅｄ ｃｏｎｔｒｏｌ ｓｙｓｔｅｍ ｗｉｔｈ ｎｅｔｗｏｒｋ ｔｉｍｅ−ｄｅｌａｙ ｃｏｍｐｅｎｓａｔｉｏｎ． Ｉｎ Ｐｒｏｃ． ｏｆ Ｉｎｄｕｓｔｒｙ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｎｆｅｒｅｎｃｅ， ｖｏｌｕｍｅ ４， ｐａｇｅｓ ２４３５−４０， ２００５．

【非特許文献9】ＤＳ２ ：Ｄｅｌａｙ Ｓｐａｃｅ Ｓｙｎｔｈｅｓｉｚｅｒ． ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｒｉｃｅ．ｅｄｕ／〜ｂｏｚｈａｎｇ／ｄｓ２／．

【非特許文献10】Ｌ． Ｄｅｓｂｏｒｏｕｇｈ ａｎｄ Ｒ． Ｍｉｌｌｅｒ． Ｉｎｃｒｅａｓｉｎｇ ｃｕｓｔｏｍｅｒ ｖａｌｕｅ ｏｆ ｉｎｄｕｓｔｒｉａｌ ｃｏｎｔｒｏｌ ｐｅｒｆｏｒｍａｎｃｅ ｍｏｎｉｔｏｒｉｎｇ−Ｈｏｎｅｙｗｅｌｌ’ｓ ｅｘｐｅｒｉｅｎｃｅ． Ｉｎ Ｐｒｅｐｒｉｎｔ ｏｆ Ｃｈｅｍｉｃａｌ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ， ２００２．

【非特許文献11】Ｖ． Ｇａｂａｌｅ， Ｐ． Ｄｕｔｔａ， Ｒ． Ｋｏｋｋｕ， ａｎｄ Ｓ． Ｋａｌｙａｎａｒａｍａｎ． ＩｎＳｉｔｅ： ＱｏＥ−ａｗａｒｅ ｖｉｄｅｏ ｄｅｌｉｖｅｒｙ ｆｒｏｍ ｃｌｏｕｄ ｄａｔａ ｃｅｎｔｅｒｓ． Ｉｎ Ｐｒｏｃ． ｏｆ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ ＱｏＳ， ２０１２．

【非特許文献12】Ｘ． Ｇａｏ ａｎｄ Ｌ． Ｓｃｈｕｌｍａｎ． Ｆｅｅｄｂａｃｋ ｃｏｎｔｒｏｌ ｆｏｒ ｒｏｕｔｅｒ ｃｏｎｇｅｓｔｉｏｎ ｒｅｓｏｌｕｔｉｏｎ． Ｉｎ Ｐｒｏｃ． ｏｆ ＡＣＭ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｐｒｉｎｃｉｐｌｅｓ ｏｆ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｐｕｔｉｎｇ， ２００５．

【非特許文献13】Ｍ． Ｇｏｐａｌ． Ｄｉｇｉｔａｌ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅｅｒｉｎｇ． Ｎｅｗ Ａｇｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ， １９９８．

【非特許文献14】Ｍ． Ｇｏｐａｌ． Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍｓ： Ｐｒｉｎｃｉｐｌｅｓ ａｎｄ Ｄｅｓｉｇｎ． Ｔａｔａ ＭｃＧｒａｗ−Ｈｉｌｌ， ２００６． Ｒｅｐｒｉｎｔｅｄ ｆｒｏｍ ｔｈｅ ２００２ ｏｒｉｇｉｎａｌ．

【非特許文献15】Ｕ． Ｈｅｒｒｍａｎｎ， Ｂ． Ｋｅｌｌｙ， ａｎｄ Ｈ． Ｐｒｉｃｅ． Ｔｗｏ−ｔａｎｋ ｍｏｌｔｅｎ ｓａｌｔ ｓｔｏｒａｇｅ ｆｏｒ ｐａｒａｂｏｌｉｃ ｔｒｏｕｇｈ ｓｏｌａｒ ｐｏｗｅｒ ｐｌａｎｔｓ． Ｅｎｅｒｇｙ， ２９（５−６）：８８３−９３， Ａｐｒ ２００４．

【非特許文献16】Ｓ． Ｋｕｍａｒ， Ｓ． Ｇｏｌｌａｋｏｔａ， ａｎｄ Ｄ． Ｋａｔａｂｉ． Ａ ｃｌｏｕｄ−ａｓｓｉｓｔｅｄ ｄｅｓｉｇｎ ｆｏｒ ａｕｔｏｎｏｍｏｕｓ ｄｒｉｖｉｎｇ． Ｉｎ Ｐｒｏｃ． ｏｆ ＳＩＧＣＯＭＭ ＭＣＣ ｗｏｒｋｓｈｏｐ ｏｎ Ｍｏｂｉｌｅ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ， ２０１２．

【非特許文献17】Ｗｈｙ Ｕｓｅ ＬａｂＶＩＥＷ？ ｈｔｔｐ： ／／ｗｗｗ．ｎｉ．ｃｏｍ／ｗｈｉｔｅ−ｐａｐｅｒ／８５３６／ｅｎ．

【非特許文献18】Ｃ． Ｌｕ， Ｙ． Ｌｕ， Ｔ． Ａｂｄｅｌｚａｈｅｒ， Ｊ． Ａ． Ｓｔａｎｋｏｖｉｃ， ａｎｄ Ｓ． Ｓｏｎ． Ｆｅｅｄｂａｃｋ ｃｏｎｔｒｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ ｄｅｓｉｇｎ ｍｅｔｈｏｄｏｌｏｇｙ ｆｏｒ ｓｅｒｖｉｃｅ ｄｅｌａｙ ｇｕａｒａｎｔｅｅｓ ｉｎ ｗｅｂ ｓｅｒｖｅｒｓ． ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｐａｒａｌｌｅｌ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ， １７（７）， Ｓｅｐｔ ２００６．

【非特許文献19】Ｋ． Ｎａｔｏｒｉ ａｎｄ Ｋ． Ｏｈｎｉｓｈｉ． Ａ ｄｅｓｉｇｎ ｍｅｔｈｏｄ ｏｆ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｄｉｓｔｕｒｂａｎｃｅ ｏｂｓｅｒｖｅｒ ｆｏｒ ｔｉｍｅ−ｄｅｌａｙ ｃｏｍｐｅｎｓａｔｉｏｎ， ｔａｋｉｎｇ ｔｈｅ ｄｙｎａｍｉｃ ｐｒｏｐｅｒｔｙ ｏｆ ｎｅｔｗｏｒｋ ｄｉｓｔｕｒｂａｎｃｅ ｉｎｔｏ ａｃｃｏｕｎｔ． ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｉｎｄｕｓｔｒｉａｌ Ｅｌｅｃｔｒｏｎｉｃｓ，５５（５）：２１５２−６８， Ｍａｙ ２００８．

【非特許文献20】Ｐ． Ｐａｔｒａｓ， Ａ． Ｂａｎｃｈｓ， ａｎｄ Ｐ． Ｓｅｒｒａｎｏ． Ａ ｃｏｎｔｒｏｌ ｔｈｅｏｒｅｔｉｃ ｓｃｈｅｍｅ ｆｏｒ ｅｆｆｉｃｉｅｎｔ ｖｉｄｅｏ ｔｒａｎｓｍｉｓｓｉｏｎ ｏｖｅｒ ｉｅｅｅ ８０２．１１ｅ ｅｄｃａ ｗｌａｎｓ． ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｍｐｕｔｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ， ８（３）：２９：１−２９：２３， Ａｕｇ ２０１２．

【非特許文献21】Ｊ． Ｒｏｓｓｉｔｅｒ． Ｍｏｄｅｌ−Ｂａｓｅｄ Ｐｒｅｄｉｃｔｉｖｅ Ｃｏｎｔｒｏｌ： Ａ Ｐｒａｃｔｉｃａｌ Ａｐｐｒｏａｃｈ． ＣＲＣ Ｐｒｅｓｓ， ２００４．

【非特許文献22】Ｊ． Ｓｈｅｒｒｙ， Ｓ． Ｈａｓａｎ， Ｃ． Ｓｃｏｔｔ， Ａ． Ｋｒｉｓｈｎａｍｕｒｔｈｙ， Ｓ． Ｒａｔｎａｓａｍｙ， ａｎｄ Ｖ． Ｓｅｋａｒ． Ｍａｋｉｎｇ ｍｉｄｄｌｅｂｏｘｅｓ ｓｏｍｅｏｎｅ ｅｌｓｅ’ｓ ｐｒｏｂｌｅｍ： ｎｅｔｗｏｒｋ ｐｒｏｃｅｓｓｉｎｇ ａｓ ａ ｃｌｏｕｄ ｓｅｒｖｉｃｅ． Ｉｎ Ｐｒｏｃ． ｏｆ ＳＩＧＣＯＭＭ， ２０１２．

【非特許文献23】Ｓｍｉｔｈ Ｐｒｅｄｉｃｔｏｒ ｆｏｒ Ｃｏｎｔｒｏｌ ｏｆ Ｐｒｏｃｅｓｓｅｓ ｗｉｔｈ Ｄｅａｄ Ｔｉｍｅｓ． ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ａｕｔｏｍａｔｉｏｎ． ｓｉｅｍｅｎｓ．ｃｏｍ／ＷＷ／ｖｉｅｗ／ｅｎ／３７３６１２０７， ２００９．

【非特許文献24】Ｇ． Ｓｍａｒａｇｄａｋｉｓ， Ｎ． Ｌａｏｕｔａｒｉｓ， Ｉ． Ｍａｔｔａ， Ａ． Ｂｅｓｔａｖｒｏｓ， ａｎｄ Ｉ． Ｓｔａｖｒａｋａｋｉｓ． Ａ ｆｅｅｄｂａｃｋ ｃｏｎｔｒｏｌ ａｐｐｒｏａｃｈ ｔｏ ｍｉｔｉｇａｔｉｎｇ ｍｉｓｔｒｅａｔｍｅｎｔ ｉｎ ｄｉｓｔｒｉｂｕｔｅｄ ｃａｃｈｉｎｇ ｇｒｏｕｐｓ． Ｉｎ Ｐｒｏｃ． ｏｆ ＩＦＩＰ−ＴＣ６ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｎｅｔｗｏｒｋｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ， Ｓｅｒｖｉｃｅｓ， ａｎｄ Ｐｒｏｔｏｃｏｌｓ， ２００６．

【非特許文献25】Ｏ． Ｓｍｉｔｈ． Ｃｌｏｓｅｒ ｃｏｎｔｒｏｌ ｏｆ ｌｏｏｐｓ ｗｉｔｈ ｄｅａｄ ｔｉｍｅ． Ｃｈｅｍｉｃａｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｐｒｏｇｒｅｓｓ， ５３（５）：２１７−９， Ｍａｙ １９５７．

【非特許文献26】Ｓｏｌａｒ ｐｌｏｔｓ． ｈｔｔｐ：／／ｗｗｗ．ｓｏｌａｒｐｌｏｔｓ．ｉｎｆｏ／．

【非特許文献27】Ｈ． Ｗａｄｅ． Ｂａｓｉｃ ａｎｄ Ａｄｖａｎｃｅｄ Ｒｅｇｕｌａｔｏｒｙ Ｃｏｎｔｒｏｌ： Ｓｙｓｔｅｍ Ｄｅｓｉｇｎ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎ． ＩＳＡ， ２００４．

【非特許文献28】Ｔ． Ｗｏｏｄ， Ｅ． Ｃｅｃｃｈｅｔ， Ｋ． Ｒａｍａｋｒｉｓｈｎａｎ， Ｐ． Ｓｈｅｎｏｙ， Ｊ． ｖａｎ ｄｅｒ Ｍｅｒｗｅ， ａｎｄ Ａ． Ｖｅｎｋａｔａｒａｍａｎｉ． Ｄｉｓａｓｔｅｒ ｒｅｃｏｖｅｒｙ ａｓ ａ ｃｌｏｕｄ ｓｅｒｖｉｃｅ： ｅｃｏｎｏｍｉｃ ｂｅｎｅｆｉｔｓ ＆ ｄｅｐｌｏｙｍｅｎｔ ｃｈａｌｌｅｎｇｅｓ． Ｉｎ Ｐｒｏｃ． ｏｆ ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｈｏｔ Ｔｏｐｉｃｓ ｉｎ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ， ２０１０．

【非特許文献29】Ｘ． Ｘｕ． Ｆｒｏｍ ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ ｔｏ ｃｌｏｕｄ ｍａｎｕｆａｃｔｕｒｉｎｇ． Ｒｏｂｏｔｉｃｓ ａｎｄ Ｃｏｍｐｕｔｅｒ−Ｉｎｔｅｇｒａｔｅｄ Ｍａｎｕｆａｃｔｕｒｉｎｇ， ２８（１）：７５−８６， Ｆｅｂ ２０１２．

【非特許文献30】Ｓ． Ｙａｎｇ， Ｘ． Ｃｈｅｎ， Ｌ． Ｔａｎ， ａｎｄ Ｌ． Ｙａｎｇ． Ｔｉｍｅ ｄｅｌａｙ ａｎｄ ｄａｔａ ｌｏｓｓ ｃｏｍｐｅｎｓａｔｉｏｎ ｆｏｒ ｉｎｔｅｒｎｅｔ−ｂａｓｅｄ ｐｒｏｃｅｓｓ ｃｏｎｔｒｏｌ ｓｙｓｔｅｍｓ． Ｔｒａｎｓａｃｔｉｏｎｓ ｏｆ ｔｈｅ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｍｅａｓｕｒｅｍｅｎｔ ａｎｄ Ｃｏｎｔｒｏｌ， ２７（２）：１０３−１８， Ｊｕｎｅ ２０１２．

【非特許文献31】Ｙ． Ｙａｎｇ， Ｙ． Ｗａｎｇ， ａｎｄ Ｓ．−Ｈ． Ｙａｎｇ． Ａ ｎｅｔｗｏｒｋｅｄ ｃｏｎｔｒｏｌ ｓｙｓｔｅｍ ｗｉｔｈ ｓｔｏｃｈａｓｔｉｃａｌｌｙ ｖａｒｙｉｎｇ ｔｒａｎｓｍｉｓｓｉｏｎ ｄｅｌａｙ ａｎｄ ｕｎｃｅｒｔａｉｎ ｐｒｏｃｅｓｓ ｐａｒａｍｅｔｅｒｓ． Ｉｎ Ｐｒｏｃ． ｏｆ ＩＦＡＣ， ｖｏｌｕｍｅ １６， ２００５．

【発明の概要】

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

【0005】

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

【0006】

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

【0007】

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

【0008】

好ましくは、ハードウェア要素は、Ｍｏｄｂｕｓ／ＴＣＰおよびＰｒｏｆｉｂｕｓ／ＴＣＰからなる群から選択されるプロトコルを使用してサーバと通信する。
好都合には、ハードウェア要素はインターネットを介してサーバと通信する。
有利には、サーバは、クラウドの一部を形成するサーバである。

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

好ましくは、ハードウェア要素は、Ｍｏｄｂｕｓ／ＴＣＰおよびＰｒｏｆｉｂｕｓ／ＴＣＰからなる群から選択されるプロトコルを使用してサーバと通信する。
好都合には、ハードウェア要素はインターネットを介してサーバと通信する。
有利には、サーバは、クラウドの一部を形成するサーバである。

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【図面の簡単な説明】

【0048】

【図1】従来の産業用オートメーション・システムを示す概略図である。

【図2】本発明の一実施形態のクラウドを利用する制御システムの要素を示す概略図である。

【図3】仮想機械にコントローラを割り当てるアルゴリズムの疑似コードを示す図である。

【図4】（ａ）〜（ｅ）本発明の一実施形態におけるインターネット遅延を緩和するフィードバック制御ループを示す図である。

【図5】本発明の一実施形態のクラウドを使用する制御システムの概略図である。

【図6】３つの別個のクラウド提供者によって提供されるシステムでサービスとして実行されるクラウドに置かれた複数のコントローラを示す概略図である。

【図7】本発明の一実施形態の高信頼クラウド制御（ＲＣＣ）アルゴリズムの疑似コードを示す図である。

【図8】本発明の一実施形態の滑らかな引き継ぎアルゴリズムの疑似コードを示す図である。

【図9】本発明の一実施形態の試験時における２つのクラウド・コントローラの位置を示す概略図である。

【図10】本発明の実施形態の試験でその模擬を使用した太陽熱発電プラント制御システムの概略図である。

【図11】（ａ）〜（ｃ）本発明の一実施形態の試験時における太陽光集光器の角度のグラフを示す図である。

【図12】（ａ）〜（ｃ）本発明の一実施形態の試験時における太陽熱発電プラントの制御結果を示すグラフである。

【図13】（ａ）〜（ｃ）遅延を導入した場合の本発明の実施形態の制御システムの試験結果を示すグラフである。

【図14】本発明の一実施形態の遅延補償器を使用した性能指標を要約した表である。

【図15】（ａ）〜（ｂ）滑らかな引き継ぎを行う場合と行わない場合のＲＣＣアルゴリズムの性能を示すグラフである。

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

【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】

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

【数1】

になる。

【0082】

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

【数2】

になるように、プラントＰ（ｚ）ｚ^−ｊのコントローラ

【数3】

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

【数4】

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

【数5】

【0083】

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

【数6】

【0084】

本発明提案のクラウド・コントローラを図５に示す。図５は、（ｉ）遅延補償器を備えたコントローラおよび（ｉｉ）インターネット遅延推定器、の２つの主要な要素を示す。図では、遅延補償器を備えたコントローラは、式３で記述されるコントローラのブロック図である点線の枠に示すが、フィードフォワード遅延とフィードバック遅延の組み合わせｚ^ｋ＋ｌ、すなわち往復遅延を伴う。これは、遅延のないプロセスＰ（ｚ）に設計された当初のコントローラであるＣ（ｚ）を使用する。また、

【数7】

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

【0085】

第２の要素を図５の黒塗りの枠に示し、この要素はプロセスとコントローラがあるクラウドとの間の往復遅延を推定する。往復遅延は遅延ブロックｚ^ｋ＋ｌで使用される。本発明の一実施形態の遅延推定器は、指数重み付き移動平均（ＥＷＭＡ）を用いてインターネット遅延をＤ_ｉ＝αｄ_ｉ＋（ｌ−α）Ｄ_ｉ−ｌとして推定する。Ｄ_ｉは推定平均遅延であり、ｄ_ｉは離散時刻ｉにおける測定遅延である。

【0086】

同様に、本発明の一実施形態では、指数重み付き移動分散（ＥＷＭＶ）を用いて遅延の分散をＶ_ｉ＝α（ｄ_ｉ−Ｄ_ｉ）^２＋（ｌ−α）Ｖ_ｉ−ｌとして推定する。Ｖ_ｉは離散時刻ｉにおける推定分散である。遅延ブロックの遅延値が

【数8】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

提案されるフィードバック制御のクラウド・サービスで信頼性を実現するために、本発明の一実施形態は、すべての冗長なコントローラで非同期に実行される分散障害耐性アルゴリズムを組み込む。このアルゴリズムは高信頼クラウド制御（Ｒｅｌｉａｂｌｅ Ｃｌｏｕｄ Ｃｏｎｔｒｏｌ：ＲＣＣ）として知られている。ＲＣＣは、二重またはそれより高い冗長性を支援し、以下の保証を提供する。

【0093】

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

【0094】

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

【0095】

ＲＣＣがこのような保証を提供するために、システム状態を組（ａ，ｕ_１，ｕ_２，ｕ_３，．．．）として定義する。ａはアクチュエータによって実行された最後のコントローラ動作であり、ｕ_ｉは冗長コントローラＣ_ｉによって行われた最後の動作から経過した時間である。すべてのコントローラから見えるように、ＲＣＣは状態の組を図６に示すように制御Ｉ／Ｏインターフェース・モジュールのメモリに記憶する。状態の組は、Ｉ／Ｏインターフェースが最初に電源投入される時に初期化される。最後の動作ａは、プロセス設計に応じて任意に初期化することができる。最後の動作からの経過時間ｕ_ｉは∞に初期化して、コントローラＣ_ｉがそれまでに一度も動作していないことを示す。

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

２．１ 詳細な動作
図７は、すべてのコントローラの上で実行されるＲＣＣの疑似コードを示す。一番最初のサイクルに、ＲＣＣは、コントローラＣ_ｉのＩＤｉおよび稼働閾値Ｄ_ｉを初期化して、一度に１つのみのコントローラが稼働することを保証する。ＩＤは主コントローラには１に設定され、副コントローラには２に設定され、以下同様に設定される。また、任意のコントローラのペア（Ｃ_ｉ，Ｃ_ｊ）（ただしｉ＞ｊ）について、稼働閾値はＤ_ｉ＞Ｄ_ｊ≧Ｔ_ｓを満たさなければならない。Ｔ_ｓはサンプリング期間である。そして、上記の主要ステップがサンプリング期間ごとに実行される。ポーリング・ステップで、Ｉ／Ｏインターフェースから以下の変数を取得する。

【0102】

（ｉ）ＰｒｏｃｅｓｓＶａｒ：現在のセンサ測定値。
（ｉｉ）ｌａｓｔＡｃｔｉｏｎ：状態変数ａの表現。すなわちアクチュエータによって実行された最後の動作。
（ｉｉｉ）ｌａｓｔＡｃｔｉｏｎＡｇｅ：時間カウンタ配列であり、ｌａｓｔＡｃｔｉｏｎＡｇｅ（ｉ）は、状態変数ｕ_ｉ、すなわちＣ_ｉが最後に稼働してから経過した時間を表す。

【0103】

ポーリング・ステップが例えばリンク障害のためにタイムアウトすると、コントローラは、ｆｉｒｓｔＣｙｃｌｅフラグをＴＲＵＥにリセットしてから現在のサンプリング期間を飛ばす。疑似コードにおけるこの行は、下記の項２．２で示すように保証Ｇ３に関連する。

【0104】

次いで、演算ステップでコントローラ・モードを決定する。任意のコントローラＣ_ｉについて、より小さいＩＤを有する動作中の別のコントローラＣ_ｊがある場合は、Ｃ_ｉは待機モードで動作することを決定する。一方、すべてのＣ_ｊについて（ただしｊ＜ｉ）、最後の動作の経過時間ｕ_ｊがＤ_ｉよりも古い場合は、すべてのコントローラＣ_ｊが故障したと想定するため、Ｃ_ｉは稼働モードで動作することを決定する。したがって、ＲＣＣは、より小さいＩＤを有するコントローラを求めてｌａｓｔＡｃｔｉｏｎＡｇｅを調べるｆｏｒループを使用して、フラグｉＡｍＥｎｇａｇｅｄを評価する。次いで、ＲＣＣは制御アルゴリズムｃｏｎｔｒｏｌｌｅｒ（）を実行し、これは通常はセンサ測定値ｐｒｏｃｅｓｓＶａｒだけを必要とする。それでも、一部の制御アルゴリズムについては、保証Ｇ３は、下記の項２．２で述べるようにより多くのパラメータを渡すことを指示する。

【0105】

最後に、条件付き動作ステップで、ｉＡｍＥｎｇａｇｅｄフラグがＴＲＵＥである場合は演算された動作をプロセスに送る。さらに、ゼロを送信して、最後の動作からの時間を示すカウンタをリセットする。そうではなく、ｉＡｍＥｎｇａｇｅｄフラグがＦＡＬＳＥの場合は、このステップは動作を行わない。

【0106】

一般性を失うことなく、次いで三重の冗長性の事例に着目して、ＲＣＣ下における３つのコントローラ間の対話を説明する。主コントローラのｉＡｍＥｎｇａｇｅｄフラグは、最も小さいＩＤを有するので、常にＴＲＵＥである。副コントローラが時間カウンタｌａｓｔＡｃｔｉｏｎＡｇｅ（ｌ）をポーリングする際に、副コントローラは、主コントローラが生きているかどうかを継続的に確認する。

【0107】

主コントローラが故障した場合は、ｌａｓｔＡｃｔｉｏｎＡｇｅ（ｌ）が副コントローラの稼働閾値を超えた時に、副コントローラがその故障を検出する。その場合、副コントローラのｉＡｍＥｎｇａｇｅｄは、ｆｏｒループ全体にわたってＴＲＵＥのままとなる。そのため副コントローラは稼働モードで動作し、したがってＩ／Ｏインターフェース中の自身のｌａｓｔＡｃｔｉｏｎＡｇｅ（２）のエントリをリセットして、自身がたった今動作したことを示す。

【0108】

第３のコントローラも主コントローラの故障を検出するが、第３のコントローラの稼働閾値は副コントローラの稼働閾値よりも大きい。ｌａｓｔＡｃｔｉｏｎＡｇｅ（ｌ）の値が第３のコントローラの稼働閾値を超える前に、副コントローラがすでに動作しているはずである。そのため、第３のコントローラが次のサンプリング期間で状態をポーリングする時には、時間カウンタｌａｓｔＡｃｔｉｏｎＡｇｅ（２）はすでにδに増分されて、０＜δ＜Ｔ_ｓとなっているはずであり、その値は第３のコントローラの稼働閾値より小さく、第３のコントローラのｉＡｍＥｎｇａｇｅｄフラグを強制的にＦＡＬＳＥにする。

【0109】

第３のコントローラは、主コントローラと副コントローラの両方が使用不可能になった時かつその時に限り稼働する。これにより保証Ｇ１に対応する。主コントローラが故障から復旧すると、主コントローラは常に稼働モードで動作しているため、プロセスの制御権を得て、副コントローラを強制的に待機モードにする。主コントローラのｌａｓｔＡｃｔｉｏｎＡｇｅ（ｌ）をリセットすると、副コントローラは、経過時間が副コントローラの稼働閾値よりも小さい最近の主コントローラの動作を検出する。その結果、副コントローラのｉＡｍＥｎｇａｇｅｄフラグはＦＡＬＳＥになる。したがって、副コントローラは待機モードで動作する。これと同じ事が、より小さいＩＤのコントローラが故障から復旧した時に任意の２つのコントローラに当てはまる。これにより保証Ｇ２を達成する。

【0110】

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

【0111】

クラウド・コントローラ間の滑らかな引き継ぎを実現するために、本発明の一実施形態では、クラウド・コントローラに制御理論のバンプレス切り換え（ｂｕｍｐｌｅｓｓ ｔｒａｎｓｆｅｒ）の概念を使用する。バンプレス切り換えは、元々は「手動」から「自動」制御への切り換えを支援するために設計されたものであり、業界で用いられているコントローラの９０％以上に相当する大半の商用ＰＩＤコントローラでサポートされている。ＰＩＤコントローラのバンプレス切り換えは、積分器の初期値を調整することによって実現することができる。他のバンプレス切り換え方法が高度な「自動」コントローラのために提案されている。

【0112】

図８に、図７で紹介したＰＩＤｃｏｎｔｒｏｌｌｅｒ（）関数の滑らかな引き継ぎバージョンを示し、これは２つ以上のＰＩＤコントローラ間で切り換えを行う時に滑らかな引き継ぎを保証する。このアルゴリズムは、任意のコントローラからＰＩＤコントローラに切り換える時にも機能する。

【0113】

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

【0114】

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

【0115】

どのコントローラも、その最初のサンプリング期間、すなわちｉｆ条件に示されるようにフラグｆｉｒｓｔＣｙｃｌｅがＴＲＵＥである時に、各自の積分器の初期値を補正する必要がある。それにより、ａ＜ｂである場合に、復旧したＣ_ａと現在稼働中のコントローラＣ_ｂの間の滑らかな引き継ぎが可能になる。この理由により、図７の疑似コードでタイムアウトすると、ＲＣＣはｆｉｒｓｔＣｙｃｌｅフラグをＴＲＵＥに設定する。稼働中のコントローラＣ_ａがリンク障害に遭遇し、それによりポーリング・ステップがタイムアウトし、バックアップ・コントローラＣ_ｂに交換される場合を考える。リンクが復旧した場合には、復旧すると図８でＣ_ａのｆｉｒｓｔＣｙｃｌｅフラグがＴＲＵＥになるので、Ｃ_ｂから滑らかな引き継ぎを行った後にＣ_ａが再度引き継ぐ。

【0116】

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

【0117】

このような各事例で、ｉＡｍＥｎｇａｇｅｄフラグは、現在プロセスを制御しているコントローラについてＴＲＵＥに設定される。同じフラグがすべての他のコントローラについてはＦＡＬＳＥに設定される。コントローラを切り換える必要がある時にはｉＡｍＥｎｇａｇｅｄフラグが反転される。直近に交換されたコントローラは最後に適用された動作と等しい動作から開始する。

【0118】

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

【0119】

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

【0120】

証明
Ψが正常なコントローラの非空集合であるとする。さらに、Ｃ_ｓ∈Ψが最も小さいＩＤ「ｓ」および最も小さい稼働閾値Ｄ_ｓを有するコントローラであるとする。正常でないすべてのコントローラＣ_ｉ∈／Ψかつｉ＜ｓについて、Ｃ_ｉは状態の組を更新することができないので、最後の動作からの経過時間カウンタｕ_ｉは増大し続ける。したがって、ｕ_ｉの値は、すべてがＣ_ｓの稼働閾値、すなわちＤ_ｓを超えるまで増加し続ける。Ｄ_ｓを超えると、ｉＡｍＥｎｇａｇｅｄフラグが演算ステップでＴＲＵＥと評価されるため、Ｃ_ｓが稼働状態になる。Ｃ_ｓが稼働状態になると、Ｃ_ｓは状態の組の最後の動作からの経過時間カウンタをリセットする。他の生きているコントローラＣ_ｊ∈Ψ＼｛Ｃ_ｓ｝は、カウンタ値が各自の稼働閾値Ｄ_ｊよりも小さいので、そのリセット事象を観察する。その結果、各コントローラのｉＡｍＥｎｇａｇｅｄフラグがＦＡＬＳＥに設定され、それらコントローラに強制的に動作を保留させる。したがって、動作中で到達可能なコントローラが少なくとも１つある限り、常に正確に１つのコントローラがプロセスを管理していることになる。

【0121】

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

【0122】

証明
稼働中のコントローラＣ_ｉが離散時刻ｎ＝ｋに故障するとする。バックアップ・コントローラＣ_ｊの最初の動作は、有限数のサンプリング期間

【数9】

の後にプロセスに到達する。ＲＴＴ_ｊはＣ_ｊとプロセスの間の往復インターネット遅延であり、Ｄ_ｊはＣ_ｊの稼働閾値であり、Ｔ_ｓはサンプリング期間である。この時間中に、制御Ｉ／ＯインターフェースはＣ_ｉから受け取った最後の動作を適用する。この動作はｍ［ｋ−１］であり、ｍ［ｎ］はコントローラの出力信号である。

【0123】

以下の説明でｍ［ｋ−１］が有限の値であることを証明し、ｍ［ｋ−１］を

【数10】

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

【0124】

まず、以下の説明で、ｍ［ｋ−１］が有限であることを証明する。稼働中のコントローラＣ_ｉが障害のない条件下でゼロの行き過ぎ量および定常状態誤差を保証すると仮定すると、プロセス変量ｙ［ｎ］は、振動せずにその初期値から目標値に収束する。目標値ｒ［ｎ］はｎ＞０の場合には定数関数になるため、誤差信号ｅ［ｎ］＝ｒ［ｎ］−ｙ［ｎ］は、振動せずにその有限の初期値からゼロに収束し、これは、Ｅ（ｚ）が安定な非振動極、すなわちｚ平面の単位円の内側にある正の実数極を有することを意味する。誤差は入力としてコントローラに渡される。

【0125】

コントローラの伝達関数Ｃ_ｉ（ｚ）は、単位円の内側または上に正の実数極を有する。例えば、実際に使用される最も一般的なコントローラであるＰＩＤコントローラは、単位円の外側には極を有しない（ｚ＝１、すなわち単位円上に１つのみの極を有する）。したがって、Ｍ（ｚ）＝Ｅ（ｚ）Ｃ_ｉ（ｚ）であるコントローラ出力は、安定な極と、単位円のｚ＝１に最大で１つの極を有する。これは、安定伝達関数（Ｅ（ｚ）およびＣ_ｉ（ｚ）のすべての他の安定な極）に単位ステップ入力（ｚ＝１の極）を適用した結果生じる信号と正確に等しい。

【0126】

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

【0127】

定理３
１つの障害がある状況における整定時間ｔ_ｓの最悪の事例の増加は、インターネットの往復遅延ＲＴＴ_ｊおよびバックアップ・コントローラＣ_ｊの稼働閾値Ｄ_ｊが上限となり、

【数11】

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

【0128】

証明
この証明は当業者には単純明快なものである。簡潔のために、最終結果は微分を含めずに示す。一般性を失うことなく、単位利得システムをその支配的な時定数で表し、その支配的な時定数の１０％ごとに周期的にサンプリングし、これはサンプリング期間を設計する際の経験則である。そのようなシステムのステップ応答は、ｙ［ｎ］＝（１／１１）δ［ｎ］＋ｕ［ｎ−１］−（１０／１１）^ｎ＋２として導出することができる。障害がない条件下での整定時間ｔ_ｓは、プロセスが最終値の５％以内にとどまるのに要する時間として定義される。障害のない条件下では整定時間ｔ_ｓ０は３０サンプリング期間として得られる。離散時刻ｋ＞０に障害が発生した時に同様の分析を使用する。

【0129】

障害下では、ｔ_ｓｆは３つの成分を有する。
（ｉ）ｔ_ｓ１。この時間中に、最初のコントローラＣ_ｉが故障する前にプロセス出力を０から中間値０＜α＜１に制御する。その結果、ｔ_ｓ１＝ｌｏｇ（１−α）／ｌｏｇ（１０／１１）−２になる。

【0130】

（ｉｉ）ｔ_ｓ２。これはＣ_ｊが障害を検出し、それに応答するのにかかる時間である。この時間中、コントローラ出力はｍ［ｋ−１］に保持され、プロセス出力は下限であるαになる（１次の遅れによる。プロセスは実際にはβに進み、ここで０≦α≦β≦１であり、これはより良好なシナリオである）。定理２の証明は、

【数12】

であることを示す。

【0131】

（ｉｉｉ）ｔ_ｓ３。この時間中にＣ_ｊはプロセス出力をαから０．９５に制御する。その結果、ｔ_ｓ３＝（ｌｏｇ（０．０５）−ｌｏｇ（１−α））／ｌｏｇ（１０／１１）−２になる。
上記から、

【数13】

という結論に達する。

【0132】

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

【数14】

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

【0133】

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

【0134】

証明
コントローラＣ_ｊが現在稼働中であるとする。Ｃ_ｉ（ただし、ｉ＜ｊ）に障害が発生したが、現在は復旧しているとする。Ｃ_ｉはより小さいＩＤを有するため、Ｃ_ｉが稼働し、制御Ｉ／Ｏインターフェースで維持されている状態の更新を開始する。Ｃ_ｉが復旧していることをＣ_ｊが検出するのに

【数15】

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

【0135】

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

【0136】

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

【0137】

試験の目的で、本発明の一実施形態を、オートメーション産業と試験所の検査の両方で標準となっているＬａｂＶＩＥＷソフトウェアで実装した。本発明の方式は、ＰＩＤ制御方法で評価した。これは、この方法が実際に使用されている最も一般的な方法であるためである。ＬａｂＶＩＥＷ ＰＩＤコントローラを、Ａｍａｚｏｎクラウド２のＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒのインスタンスに配置した。ＬａｂＶＩＥＷを使用して、北アメリカの西海岸に配置されるサーバで中規模の産業用プラントの模擬も行った。ＬａｂＶＩＥＷによって提供される標準のＭｏｄｂｕｓ／ＴＣＰプロトコルをプラントのプロセスとクラウド・コントローラの間の通信に使用した。図９に示すように、２つのクラウド・コントローラを、プラントから最も遠くに配置される利用可能な（遅延の点で）Ａｍａｚｏｎクラウドの場所であるシンガポールとブラジルのサン・パウロに配置した。

【0138】

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

【0139】

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

【0140】

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

【0141】

太陽熱発電プラントを制御するために、９つの制御ループを特定し、それを図１０に示す。（ｉ）太陽光集光ミラーのための３つの角度位置ループ、（ｉｉ）３つのフロー制御ループ。２つがオイル・サイクルに、１つが蒸気サイクルに対応する。（ｉｉｉ）３つの温度コントローラ。１つがオイル・サイクルに、１つが蒸気サイクルに、１つが凝縮サイクルに対応する。図を簡潔にするために、追加的な制御ループ（例えばタービンに対応する）は図示していない。

【0142】

性能の結果は、上記３つのグループそれぞれから１つずつ、３つの代表的な制御ループから与えられる。それらループの伝達関数を導出し、各自のＰＩＤクラウド・コントローラは、Ｚｉｅｇｌｅｒ−Ｎｉｃｈｏｌｓ法を使用して設計し、試行錯誤により微調整した。制御ループごとに、制御されるプロセスの状態が周期的にサンプリングされ、対応するコントローラによって取得され、コントローラは適切な動作を算出し、そのプロセスのアクチュエータにその動作を送り返す。サンプリング期間は、通常は、プロセスの支配的な時定数の１０％に設定される。大半の連続産業プロセスは、０．５〜２．０秒の範囲のサンプリング期間を有する。

【0143】

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

【0144】

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

【0145】

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

【0146】

太陽光集光器の位置決め
太陽光集光器は、重量１，０００ｋｇの可動部品を備える。放物トラフ・ミラーは、１ｍの焦点距離を有する。集光器は、ミラーの焦点軸を中心に回転する。歯車比１００のギヤボックスを備える大型のＤＣモータが集光器を駆動する。伝達関数は、Θ（ｓ）／Ｖ_ｆ（ｓ）＝０．１／（ｓ^３＋１８ｓ^２＋８０ｓ＋１０）として導出される。Θ（ｓ）およびＶｆ（ｓ）はそれぞれ集光器の角度位置のラプラス変換関数とＤＣモータの界磁回路に印加される電圧である。この伝達関数の支配的な時定数は７．７７ｓである。したがって、７５０ｍｓのサンプリング期間を選択した。

【0147】

望ましい集光器の角度位置は、ａｒｃｃｏｓ（ｃｏｓ（ｇ）ｓｉｎ（ａ））として導出される。ここで、ｇは太陽の高度角度であり、ａは南から測定された方位角である。太陽の角度の変化は、２０１２年７月１日にテキサス州ヒューストンで１時間にわたって模擬した。望ましい集光器角度は、午前１０：００から午前１１：００の間に４４．３度から５７．１度に漸進的に変化する。集光器の初期位置はゼロ度であった。風による外乱の影響を午前１０：２０から１０：４０の間に模擬したが、この影響はこの期間の前半に増加し、後半に減少する。適用された外乱は最大で７度の影響を有する。外乱の伝達関数はΘ（ｓ）／Ｄ_ｆ（ｓ）＝７５×１０−^５／（ｓ^２＋７．６ｓ＋０．７５）により近似され、Ｄ_ｆ（ｓ）は風力外乱のラプラス変換である。

【0148】

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

【0149】

オイル温度の調節
上記の実験を温度制御プロセスについても繰り返したが、温度制御プロセスは太陽光集光器の位置決めプロセスとはかなり異なる。この温度制御プロセスでは、オイルの温度を調節するために、塩が畜熱するかまたは給熱するか、および畜熱／給熱する熱の量を決定する。図１０のＴＴ１で測定される温度はオイル・サイクル全体の動作に依存する。そのため、２つのオイル熱交換器の動作を模擬した。太陽光集光器は追加的な熱交換器として模擬した。熱交換器は、支配的な時定数が２０〜３０秒の間である伝達関数を用いて模擬した。塩の相互作用の伝達関数は、Ｏ（ｓ）／Ｖ_ｐ（ｓ）＝５／（２５ｓ＋１）（３ｓ＋１）によって与えられる。Ｏ（ｓ）およびＶ_ｐ（ｓ）はそれぞれ排出オイル温度のラプラス変換関数とポンプ・モータの駆動装置に印加される電圧である。１時間にわたる一時的な曇天条件の影響も模擬した。この外乱の伝達関数は、時定数が５分間の１次システムとして近似される。プロセス全体の支配的な時定数は１８９秒と算出されるが、１秒の最大サンプリング期間を使用してシステムに負荷を与えた。

【0150】

図１２（ａ）に１３：００から１５：００までの２時間の結果を示し、１３：３０から１４：３０の間に一時的な曇天の外乱が発生している。図１２（ａ）は、クラウド・コントローラがローカル・コントローラと同じように温度を目標値に維持していることを示し、一方温度は開ループ・コントローラの下では目標値から大幅に外れている。図１２（ｂ）は、１３：１５から１４：００までの期間を拡大して、クラウド・コントローラとローカル・コントローラが両方とも外乱に良好に対処したことを示している。２つのコントローラが取った動作をさらに説明するために、図１２（ｃ）に、曇天条件で生じた外乱を緩和するために２つのコントローラが塩の流れる方向を逆にして蓄熱する方向から給熱する方向にした様子をグラフで示す。図１２（ｃ）のｙ軸の負の値は畜熱を意味し、正の値は給熱を意味する。

【0151】

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

【0152】

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

【数16】

に設定し、Ｔｓはサンプリング期間である。したがって、検討する３種類の遅延分散について、遅延ブロックはそれぞれｚ−１０、ｚ−２０、およびｚ−４０に設定される。

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

【0153】

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

【0154】

最大行き過ぎ量および定常状態誤差に関しては、補償ありのコントローラは４つの分散すべてにわたって同じ性能を維持した。すなわち、本システムは、そのような極端な遅延条件下で性能が低下せず、遅延がなかったかのように機能した。唯一の小さな例外は最後の分散（μ＝４ｓ，σ＝２．８ｓ，ｍａｘ＝２０ｓ）の最大行き過ぎ量であり、これは０．３％として現れたが、これは実質的にゼロとみなされる。

【0155】

一方、補償しないコントローラの性能は、挿入された遅延が増大するにつれて低下し続けた。そのため、遅延のない状況のゼロの最大行き過ぎ量およびゼロの定常状態誤差から推移して、最後の遅延分散下では不安定になり、この状況では（観測可能な）最大行き過ぎ量が大幅に増大して１７０．９％になり、定常状態誤差は未確定になり、したがって表１の「未確定」項目となる。整定時間は、補償ありのコントローラと補償なしのコントローラの両方で挿入される遅延と共に増大したが、補償ありのコントローラは３番目および４番目の遅延分散（μ＝２，４ｓ，σ＝１．４，２．８ｓ，ｍａｘ＝１０，２０ｓ）で補償なしのコントローラに比べて大幅に良好に機能した。最後の分散については、補償なしのコントローラは不安定になり、整定状態に達することはなく、したがって表１の「未確定」整定時間となった。

【0156】

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

【0157】

３．４ 障害耐性および滑らかな引き継ぎ
この項では、クラウドに置かれたコントローラが障害が発生した場合にどのように滑らかな引き継ぎを実現するかを示す。２つの冗長なコントローラを図９に示すように配置して現実の遅延を用いた実験を繰り返す。障害がある状況下でのＲＣＣアルゴリズムの時間応答を障害のない場合と比較する。図１０に示す水流プロセス（ＦＴ３、ＦＣ３）にステップ入力を導入する。５秒の支配的な時定数を想定し、したがって５００ｍｓのサンプリング期間を想定する。ステップ入力はｔ＝０ｓに印加される。主コントローラは、ｔ＝１８ｓにＴＣＰ接続を無効にすることによって故障させ、主コントローラはｔ＝１７０ｓに動作に復旧する。これらの時刻は、過渡状態中に１回の引き継ぎ事象が発生し、定常状態中にもう１回引き継ぎ事象が発生するように選択される。

【0158】

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

【0159】

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

【0160】

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

【0161】

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

【0162】

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

【0163】

本明細書における「ｃｏｍｐｒｉｓｅ」は、「ｉｎｃｌｕｄｅｓまたはｃｏｎｓｉｓｔｓ ｏｆ」を意味し、「ｃｏｍｐｒｉｓｉｎｇ」は「ｉｎｃｌｕｄｉｎｇまたはｃｏｎｓｉｓｔｉｎｇ ｏｆ」を意味する。

【0164】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】