JP2017092873A - コントローラおよび制御システム - Google Patents

Abstract

【課題】高機能なゲートウェイを用いずに、高い稼働率のフィードバック制御システムを実現する。【解決手段】本実施形態のコントローラは、第１のネットワークを介して、機器の状態情報を取得する機器状態取得部と、第１の役割を有するかの情報を自装置および他のコントローラごとに保持する記憶部と、第１の役割を有する場合、機器の状態情報に基づき、機器の制御を行う制御部と、第１ネットワークの通信品質に関する第１情報を測定する測定部と、第２のネットワークを介して、第１情報を他のコントローラに送信し、他のコントローラから機器との間の第３のネットワークの通信品質に関する第２情報を、第２のネットワークを介して受信する通信部と、他のコントローラの状態を判定するコントローラ状態判定部と、他のコントローラの状態と、第１情報および第２情報に基づいて、自装置および他のコントローラの中から第１の役割のコントローラを決定する決定部を備える。【選択図】図３

Description

本発明の実施形態は、コントローラおよび制御システムに関する。

ビルや工場など（以下、ビルで統一）を管理する制御システムは、フィードバック制御という制御を行う。例えば、水の流量を調整するバルブを制御する際に、フィードバック制御を使う。

フィードバック制御を実現するシステム（フィードバック制御システム）は、制御を行うコントローラと、制御される機器と、それらを接続するネットワークから構成される。

フィードバック制御とは、以下の処理を繰り返す制御である。
1. コントローラが、ネットワークを介して、機器の状態を取得
2. コントローラが、制御値に基づいて、制御値を計算
3. コントローラが、ネットワークを介して、制御値を機器に設定

フィードバック制御システムは、高い稼働率が要求される。例えば、99.999%や99.9999%である。この要求を満たすため、既存のフィードバック制御システムは、専用のハードウェアを使用して、コントローラを実装している。また、コントローラと機器は、同じビル内に存在する。したがって、ネットワークの通信遅延は小さい。

コントローラをクラウドコンピューティング環境に移行すると、フィードバック制御システムの低コスト化が期待できる。しかし、コントローラと機器の間のネットワークの遅延は大きくなる。通信遅延や、通信遅延の分散が大きくなると、フィードバック制御は困難になる。クラウドから正確なフィードバック制御を行うためには、通信遅延の把握が必要である。通信遅延を考慮して制御値を計算することで、通信遅延が大きい環境でも、正確なフィードバック制御を行える。

また、一般的なパブリッククラウドの稼働率は約99.95%や99.99%であり、一般的な長距離専用ネットワークの稼働率も同等である。したがって、パブリッククラウドを利用して、フィードバック制御システムの稼働率を99.999%や99.9999%にするためには、コントローラとネットワークの冗長化が必要となる。

コントローラをクラウドに移行する場合の関連技術として、以下のものが知られている。コントローラとネットワークの組を複数用意する。コントローラ間には、優先度が設定されており、優先度が高いコントローラが「プライマリ」となり、フィードバック制御を行う。非プライマリのコントローラは、制御は行わないが、機器の状態の取得は定期的に行う。状態を取得する際の通信時に、通信遅延を計測できるため、全コントローラが通信遅延を把握できる。そして、プライマリのコントローラに障害が発生した時には、次に優先度が高いコントローラが代わりにプライマリとなり、制御を行う。この「別のコントローラが制御を引き継ぐこと」を、一般的にフェイルオーバーと言う。

コントローラ間のフェイルオーバーを実現するために、ビルの中に、ゲートウェイを設置する。ゲートウェイは、どのコントローラが、どの機器に制御を実施したかという制御状況に関する情報を保持する。そして、コントローラが機器の状態を取得する際に、機器の状態と制御状況に関する情報を一緒に返す。これにより、コントローラ群は、「プライマリのコントローラが、制御を行っていること」を把握できる。そして、プライマリのコントローラが、しばらく制御を行っていないと判断した場合に、フェイルオーバーする。これにより、高い稼働率を達成する。

上述した関連技術は、機器に対する制御状況を記憶する高機能なゲートウェイを設置する必要がある。このことは、ゲートウェイの開発コストを増加させ、システムの低コスト化を阻害する。なぜなら、制御状況を保持するためには、そのためのＣＰＵやメモリなどの計算機リソースが必要となるからである。また、制御状況を保持する装置をビル側に設置することは、フィードバック制御システムの低コスト化・柔軟性向上を阻害する。

Industrial Automation as a Cloud Service IEEE Transactions on Parallel and Distributed Systems, No.10, Vol.26, pp.2750-2763 (2015)

本発明の実施形態は、クラウドを利用し、かつ、高機能なゲートウェイを用いずに、高い稼働率のフィードバック制御システムを実現可能にすることを目的とする。

本発明の実施形態としてのコントローラは、機器状態取得部と、記憶部と、制御部と、測定部と、通信部と、コントローラ状態判定部と、決定部とを備える。

前記機器状態取得部は、第１のネットワークを介して、機器の状態情報を取得する。

前記記憶部は、前記機器の制御を行う第１の役割を有するか否かの情報を自装置および他のコントローラごとに保持する。

前記制御部は、自装置が前記第１の役割を有する場合、前記機器の状態情報に基づき、前記機器の制御を行う。

前記測定部は、前記第１ネットワークの通信品質に関する第１情報を測定する。

前記通信部は、第２のネットワークを介して、前記第１情報を含む第１メッセージを前記他のコントローラに送信し、前記他のコントローラから前記機器との間の第３のネットワークの通信品質に関する第２情報を含む第２メッセージを、前記第２のネットワークを介して受信する。

前記コントローラ状態判定部は、前記第２のネットワークを介して前記他のコントローラと通信することにより、前記他のコントローラの状態を判定する。

前記決定部は、前記他のコントローラの状態と、前記第１情報および前記第２情報に基づいて、前記自装置および前記他のコントローラの中から、前記第１の役割のコントローラを決定する。

本発明の実施形態に係るネットワークの構成例を示す図。 本発明の実施形態に係るネットワークの他の構成例を示す図。 本発明の実施形態に係るコントローラの構成例を示すブロック図。 コントローラ情報記憶部のデータ構造例を示す。 コントローラのハードウェア構成例を示す図。 監視制御処理の一例のフローチャート。 ハートビート送信処理の一例のフローチャート ハートビート受信処理の動作フローチャートの第１の例を示す図。 ハートビート受信処理の動作フローチャートの第２の例を示す図。 生存確認用ネットワークの構成例を示す図。

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

図１に、本実施形態に係るネットワークの構成例を示す。ビルや工場など（以下、ビルで統一）に、フィードバック制御の対象となる機器１１と、ゲートウェイ１２が配置されている。図１では制御対象となる機器は１台のみ示されているが、実際には複数の機器が配置されてもよい。この場合、複数の機器のそれぞれをフィードバック制御の対象としてもよい。

ビルの外側には、複数のコントローラＣ１、コントローラＣ２、コントローラＣ３がクラウド上に分散して配置されている。これらのコントローラＣ１〜Ｃ３は、生存確認用ネットワーク２１を介して互いに接続されている。また、コントローラＣ１〜Ｃ３は、それぞれ制御用ネットワーク３１、３２、３３を介して、ビル内のゲートウェイ１２に接続されている。コントローラＣ１〜Ｃ３は、ゲートウェイ１２を介して、ビル内の機器１１と通信する。

ゲートウェイ１２は、コントローラＣ１〜Ｃ３と機器１１間のデータまたはメッセージの転送を行う。ゲートウェイ１２は、一例として、ＩＰアドレス等に基づき転送を行うルーティング機能を備える。

ゲートウェイ１２と機器１１間の通信は、ＩＥＥＥ８０２．１１規格に準じた無線ＬＡＮといった無線通信でもよいし、イーサーネット（登録商標）等の有線通信でもよい。

制御用ネットワーク３１、３２、３３は、同じネットワークでもよいし、互いに異なるネットワークでもよい。同じネットワークの例として、インターネットがある。この場合、制御用ネットワーク３１〜３３は、インターネットにおけるそれぞれ異なる経路に対応する。また、制御用ネットワーク３１〜３３は、それぞれインターネット等のネットワークに形成したＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）でもよい。この場合、制御用ネットワーク３１、３２、３３は、論理的に異なるネットワークであると言える。もちろん、制御用ネットワーク３１、３２、３３が互いに物理的に異なる（分断された）専用ネットワークであってもかまわない。

生存確認用ネットワーク２１は、一例としてネットワーク事業者がデータセンタ等に配置した通信装置を用いて形成した、プライベートなネットワークである。当該ネットワークは有線ネットワークでも、無線ネットワークでも、これらの混合のネットワークでもよい。生存確認用ネットワーク２１と制御用ネットワークは、物理的に異なるネットワークである。ただし、生存確認用ネットワーク２１は、制御用ネットワークと物理的に同じネットワークであってもよい。

図２は、運用者または管理者の端末装置Ｍを、生存確認用ネットワーク２１に接続した構成を示す図である。運用者または管理社がこの端末装置Ｍを操作することで、コントローラＣ１〜Ｃ３の設定を行ったり、コントローラＣ１〜Ｃ３の動作を確認または制御したりするなど、コントローラの運用を管理できる。

図３に、コントローラＣ１〜Ｃ３の構成例を示す。コントローラＣ１〜Ｃ３は、いずれも図３に示した構成を有する。コントローラＣ１〜Ｃ３は、監視制御部１０１、生存確認部２０１およびコントローラ情報記憶部３０１を備える。

コントローラ情報記憶部３０１は、自装置の情報と、他のコントローラの情報とを記憶する。図４に、コントローラ情報記憶部３０１に記憶されている情報の一例を示す。

“ＩＤ”は、コントローラを一意に識別する識別子である。

“通信アドレス”は、コントローラの通信アドレスである。図の例では、ＩＰアドレスが示される。通信アドレスは、ＩＰアドレスとポート番号の組でもよい。通信アドレスは、使用する通信プロトコルに応じたものを利用すればよい。

“タイムスタンプ”は、コントローラの情報を作成または更新した時刻を表す。

“役割”は、プライマリ、もしくは、非プライマリを表す。プライマリは、機器に対してフィードバック制御（以下、単に制御と呼ぶ場合もある）を実施する役割であり、プリマリのコントローラは、機器の制御を行う。機器制御を行わない（プライマリでない）コントローラは、非プライマリの役割を有する。

“制御用ネットワークの状態”は、制御用ネットワークが正常か異常かを表す。正常は、制御用ネットワークの通信品質が良い（高い）ことの一例であり、異常は、制御用ネットワークの通信品質が悪い（低い）ことの一例である。

“制御用ネットワークの遅延の平均値”は、制御用ネットワークにおけるコントローラと機器との間の通信遅延の平均値である。通信遅延の平均値が高いことは、制御用ネットワークの通信品質が良いことの一例であり、通信遅延の平均値が低いことは、制御用ネットワークの通信品質が悪いことの一例である。

“制御用ネットワークの遅延の分散”は、制御用ネットワークにおけるコントローラと機器との間の通信遅延の分散である。通信遅延の分散が低いことは、制御用ネットワークの通信品質が良いことの一例であり、通信遅延の分散が高いことは、制御用ネットワークの通信品質が悪いことの一例である。

“最新の機器状態”は、コントローラが取得した最新の機器状態の値を表す。

図４には示した項目は一例であり、これら以外の項目が存在してもよい。また、図４の項目の一部が存在しなくてもよい。

監視制御部１０１は、機器状態取得部１０２、異常判定部１０３、制御用ネットワーク状態判定部１０４、制御用ネットワーク遅延計算部１０５、制御部１１１、制御用ネットワーク遅延平均計算部１０８、制御用ネットワーク遅延分散計算部１０９、を備える。制御部１１１は、制御値送信部１０６および制御値演算部１０７を備える。

機器状態取得部１０２は、制御用ネットワークおよびゲートウェイ１２を介して、ビル内の機器１１と通信することにより、機器１１の状態を表す情報（状態情報）を取得する。一例として、機器状態取得部１０２は、一定時間毎に機器１１から状態情報を取得する。

異常判定部１０３は、機器の状態情報等に基づき、機器の制御が正常に行われているかを判定する。

制御用ネットワーク状態判定部１０４は、制御用ネットワークの状態を判定する。より詳細には、制御用ネットワークが正常か異常かを判定する。ネットワークの正常・異常の判定方法は様々である。ここでは、機器１１からの状態情報の取得が、Ｎ回連続で失敗した場合に異常であると判定する。この場合、ネットワークの通信品質が低い（悪い）といえる。

制御用ネットワーク遅延計算部１０５は、制御用ネットワークの通信遅延、より詳細には、自装置と機器との間の通信遅延を計算する。通信遅延の計算方法は様々であり、詳細は後述する。

制御用ネットワーク遅延平均計算部１０８は、制御用ネットワークの通信遅延の平均値、より詳細には、自装置と機器との間の通信遅延の平均値を計算する。

制御用ネットワーク遅延分散計算部１０９は、制御用ネットワークの通信遅延の分散、より詳細には、自装置と機器との間の通信遅延の分散を計算する。

制御部１１１は、機器状態取得部１０２で取得される機器１１の状態情報と、制御用ネットワークの通信遅延とに基づき機器１１を制御する。制御値演算部１０７は、機器１１の状態情報と、制御用ネットワークの通信遅延とに基づき、機器１１に対する制御値を計算する。フィードバック制御における制御値の計算方法は様々である。一例として、制御値演算部１０７として、スミス予測器を使用することができる。スミス予測器は、通信遅延を与えることで、ネットワークの通信遅延が大きい環境でも、フィードバック制御の品質を高めることを可能にする。

制御値送信部１０６は、制御値演算部１０７で計算された制御値を含むメッセージを、機器１１に対して送信する。機器１１の通信アドレスまたはゲートウェイ１２の通信アドレスまたはこれらの両方を事前に把握しているものとする。機器１１の通信アドレスは、コントローラが使用する通信プロトコルのアドレス（ＩＰアドレス、またはＩＰアドレスとポート番号の組）もよいし、当該通信プロトコルより上位のプロトコルの通信アドレスでもよい。

生存確認部２０１は、ＨＢ通信部２０２、ＡＣＫ（Ａｃｋｎｏｗｌｅｇｅｍｅｎｔ）通信部２０３、コントローラ状態判定部２０４およびプライマリ決定部２０５を備える。

ＨＢ通信部２０２は、生存確認用ネットワーク２１を介して、他のコントローラへ生存確認用のメッセージを送信する。以降、生存確認用のメッセージのことを、ハートビートメッセージあるいは単にハートビート（Ｈｅａｒｔ Ｂｅａｔ：ＨＢ）と記述する。またＨＢ通信部２０２は、他のコントローラからハートビートを受信する。ハートビートには、当該ハートビートを送信するコントローラにおけるコントローラ情報記憶部３０１の情報を含める。これにより、各コントローラは、他のコントローラの通信状況または制御状況に関する情報（制御用ネットワークの通信品質（正常・異常、通信遅延の平均・分散）、機器の状態情報等）を把握できる。ＨＢ通信部２０２は、他のコントローラからハートビートの受信および復号に成功すると、送達確認応答（ＡＣＫ）の生成に必要をＡＣＫ通信部２０３に渡す。ＨＢ通信部２０２は、一定時間毎にハートビートを送信する。ただし、ハートビートを送信するタイミングは、一定時間毎である必要はなく、所定のイベントが発生したときなど、任意に定めてもよい。

ＡＣＫ通信部２０３は、自装置のＨＢ通信部２０２から送信されたハートビートに対する送達確認応答（ＡＣＫ）メッセージを、送信先の他のコントローラから受信する。また、他のコントローラから送信された自装置宛のハートビートがＨＢ通信部２０２で受信され、送達確認応答（ＡＣＫ）の生成に必要な情報がＨＢ通信部２０２から渡されると、当該情報に基づきＡＣＫメッセージを生成する。ＡＣＫ通信部２０３は、生成したＡＣＫメッセージを、生存確認用ネットワーク２１を介して、ハートビートの送信元の他のコントローラに送信する。

コントローラ状態判定部２０４は、他のコントローラの状態を判定する。より詳細に、他のコントローラが、正常か異常かを判定する。判定方法は色々と考えられる。本実施形態では、以下のいずれかの状況が発生した場合に、異常と判定し、それ以外は正常と判定する。
（１）自装置から他のコントローラへのハートビートの送信がＸ回以上、連続で失敗した場合
（２）ハートビートの送信後、一定時間以内にＡＣＫが得られない状況が、Ｙ回以上、連続で発生した場合。なお、ＸとＹは同じ値でも、異なる値でもよい。

プライマリ決定部２０５は、コントローラ状態判定部２０４でプライマリの異常が検出された場合に、プライマリを変更することを決定し、次のプライマリを決定する。

一例として、本実施形態では、制御用ネットワークの状態が正常であるコントローラの中で、制御用ネットワークの通信遅延の分散が最小もしくは閾値以下のコントローラをプライマリとする。例えば、コントローラ情報記憶部３０１の状態が図４のときにおいて、プライマリの異常を検出した場合は、通信遅延の分散が最も小さいＩＤ＝４のコントローラをプライマリとして決定する。ネットワークの通信遅延の分散が小さいほど、フィードバック制御は安定し、また、広域ネットワーク、特にインターネットの通信遅延は変動する。したがって、コントローラ情報記憶部３０１の情報を適宜更新し、通信遅延の分散の小さいコントローラを選択することで、安定したフィードバック制御が期待できる。

ただし、プライマリの決定方法はこれに限定されない。例えば、通信遅延の平均値が最小または閾値以下のコントローラを選択してもよいし、通信遅延の平均値と分散とを用いた評価値の計算式を用意し、当該計算式で計算された評価値に基づきコントローラを選択してもよい。その他、背景技術の欄で述べた関連技術で述べたように、各コントローラに優先度を設定しておくことで、次のプライマリを選択することも可能である。

図５は、コントローラＣ１〜Ｃ３のハードウェア構成の一例を示す図である。コントローラは、プロセッサ４５１、メモリ４５２、ストレージ４５３、第１ネットワークインタフェース４５４、および第２ネットワークインタフェース４５５を備え、これらがバス４５６を介して接続されている。

第１ネットワークインタフェース４５４は、生存確認用ネットワーク２１に接続されるインタフェースである。一例として、ネットワークインタフェース４５４は、ＭＡＣ層等のデータリンク層および物理層のヘッダ処理、変調および復調等を行うベースバンド集積回路、ＡＤ変換回路、ＤＡ変換回路、およびアナログ処理等を行う集積回路を備えていてもよい。ネットワークインタフェース４５４に、ＣＰＵ等のプロセッサを配置してもよい。ＴＣＰ／ＩＰ等を用いる場合、ＴＣＰ／ＩＰ等の処理を当該ネットワークインタフェース４５４上のＣＰＵで行ってもよいし、バス４５６に接続されたプロセッサ４５１で行ってもよい。コントローラは、ネットワークインタフェース４５４を用いて、クラウド上の他のコントローラと通信を行う。ネットワークインタフェース４５４は、プロセッサ４５１により制御されても良い。ネットワークインタフェース４５４が、ＤＭＡ（ダイレクト・メモリ・アクセス）でメモリ４５２に直接、アクセスしてもよい。

第２ネットワークインタフェース４５５は、制御用ネットワークに接続されるインタフェースである。一例として、ネットワークインタフェース４５５は、ＭＡＣ層等のデータリンク層および物理層のヘッダ処理、変調および復調等を行うベースバンド集積回路、ＡＤ変換回路、ＤＡ変換回路、およびアナログ処理等を行う集積回路を備えていてもよい。ネットワークインタフェース４５５に、ＣＰＵ等のプロセッサを配置してもよい。ＴＣＰ／ＩＰ等を用いる場合、ＴＣＰ／ＩＰ等の処理を当該ネットワークインタフェース４５５上のＣＰＵで行ってもよいし、バス４５６に接続されたプロセッサ４５１で行ってもよい。コントローラは、ネットワークインタフェース４５５を用いて、ビル内のゲートウェイ１２および機器１１と通信を行う。ネットワークインタフェース４５５は、プロセッサ４５１により制御されても良い。ネットワークインタフェース４５５が、ＤＭＡ（ダイレクト・メモリ・アクセス）でメモリ４５２に直接、アクセスしてもよい。

メモリ４５２は、プロセッサ４５１が実行する命令、およびプロセッサ４５１が利用する各種データ等を一時的に記憶する。メモリ４５２、ＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでも、ＮＡＮＤ、ＭＲＡＭ等の不揮発性メモリでもよい。ストレージ４５３は、プログラムやデータ等を永続的に記憶する記憶装置であり、例えば、ＨＤＤまたはＳＳＤ等である。図４のコントローラ情報記憶部３０１は、メモリ４５２またはストレージ４５３またはこれらの両方によって実現できる。メモリまたはストレージが装置に外部接続されてもよい。

プロセッサ４５１は、ストレージ４５３からプログラムを読み出して、メモリ４５２に展開して、実行することで、コントローラの機能が実現される。具体的に監視制御部１０１およびその内部の各要素、ならびに生存確認部２０１およびその内部の各要素の動作が実現される。

図６に、監視制御部１０１による監視制御処理のフローチャートを示す。

機器状態取得部１０２が、制御用ネットワークを介して、機器１１と通信して、機器状態を表す状態情報を取得する（Ｓ１０１）。取得に成功したかを判断し、状態情報の取得がＮ回以上連続で失敗したなら（Ｓ１０２のＹＥＳ）、制御用ネットワーク状態判定部１０４が、制御用ネットワークの状態が異常であると判断する（Ｓ１０３）。この場合、監視制御部１０１は、コントローラ情報記憶部３０１にアクセスして、「制御用ネットワークの状態」の欄を、「異常」に更新する（元々「異常」であれば、「異常」を維持する）。なお、状態情報の取得に失敗する場合、制御用ネットワークではなく、ゲートウェイ、機器またはビル内ネットワークに異常がある場合も考えられるが、ここでは制御ネットワークに異常があると想定する。

状態情報の取得に成功したら、制御用ネットワーク状態判定部１０４が、自装置の制御用ネットワークの状態が正常であると判断する（Ｓ１０５）。監視制御部１０１は、コントローラ情報記憶部３０１にアクセスして、「制御用ネットワークの状態」の欄を「正常」に更新する（元々「正常」であれば、「正常」を維持する）。

制御用ネットワーク遅延計算部１０５が、状態情報の取得のための通信に要した時間（通信遅延）を計算する（Ｓ１０６）。通信遅延の計算方法は様々であり、特定の方法に限定されない。例えば、状態情報の取得を開始してから、状態情報を取得するまでの時間を計測し、その半分の時間を通信遅延とする方法がある。計算した通信遅延の値の履歴は、メモリ等の記憶領域に格納しておく。

また、制御用ネットワーク遅延平均計算部１０８が、ステップＳ１０６で計算された通信遅延に基づき、通信遅延の平均値を計算（更新）する（同Ｓ１０６）。平均は、単純平均でもよいし、移動平均でもよいし、重み付け移動平均でもよいし、その他の平均でもよい。監視制御部１０１は、コントローラ情報記憶部３０１にアクセスして、「制御用ネットワークの遅延の平均値」の欄を更新する。

制御用ネットワーク遅延分散計算部１０９が、ステップＳ１０６で計算された通信遅延に基づき、通信遅延の分散を計算（更新）する（同Ｓ１０６）。監視制御部１０１は、コントローラ情報記憶部３０１にアクセスして、「制御用ネットワークの遅延の分散」の欄を更新する。なお、分散は、標準偏差など、ばらつきを評価可能な指標であれば、何でも良い。

制御値演算部１０７は、自身がプライマリである場合は、ステップＳ１０１で取得した機器状態と、通信遅延（またはその平均）等に基づき、機器１１に対する制御値の計算を行う（Ｓ１０９）。そして、制御値送信部１０６は、制御値演算部１０７で計算された制御値を含むメッセージを、制御ネットワークおよびゲートウェイ１２を介して、機器１１に送信する（同Ｓ１０９）。これにより機器１１をフィードバック制御する。なお後述するように、自装置がプライマリになった直後では、自装置が保持している最新の機器状態の情報を利用する以外に、コントロール情報記憶部に記憶されているタイムスタンプが最新のコントローラに関連づけられた最新の機器状態の情報を利用してもよいし、あるいは、コントロール情報記憶部において変更前のプライマリに関連づけられた最新の機器状態の情報を利用してもよい。

一方、自装置が非プライマリである場合は、異常判定部１０３は、機器状態の推移を検証することで、機器が正しく制御されているか検証する（Ｓ１０８）。各コントローラは共通の機器に対して、同じフィードバック制御を実施するよう構成されている。したがって、各コントローラは、正しく機器の制御が行われていれば、どのように機器状態が推移するかを予測可能である。よって、実際の機器状態の推移と、予想される機器状態の推移との乖離に基づいて、正しく制御が行われているか判断できる。単純な例として、機器がエアコンであり、ある設定温度に維持する場合、その設定温度からの乖離が所定値以上になった場合に、正しく制御が実施されていないと判断できる。この場合、設定温度が、予想される機器状態に相当する。

異常判定部１０３は、正しく制御が実施されていないと判断した場合、警報動作を行ってもよい。例えば、生存確認用ネットワーク２１を介して、コントローラの管理者が操作する端末装置Ｍに、警報メール等の警報情報を送信してもよい。警報メールには、当該プライマリ（コントローラ）のＩＤと、正しく制御が行われていない機器の識別情報を含んでもよい。機器の識別情報は、機器の製品番号、型番、製品名、通信アドレスなど、機器を特定可能な任意の情報でもよい。なお、機器の制御が正しく行われていない原因として、コントローラに問題がある場合と、機器に問題がある場合が考えられる。警報メールを受け取った管理者が調査することにより、どちらに問題があるのかを特定してもよい。変形例として、警報信号をプライマリのコントローラに送信し、プライマリのコントローラが、警報信号を受信した場合に、機器１１に対する制御を停止してもよい。

監視制御部１０１は、次の取得タイミングまで待機し（Ｓ１０４）、上述した処理を繰り返す。次の取得タイミングは予め定められた時間後でもよい。この場合、一定間隔で、機器から状態情報を取得することになる。この「一定間隔」の値は、プライマリと非プライマリのコントローラで異なっていてもよい。プライマリは制御を行なうために、必要な間隔で機器状態を取得する必要があるが、非プライマリのコントローラは、プライマリよりも長い間隔で機器状態を取得してもよい。これにより、制御用ネットワークの通信量を減らせるため、通信費を削減できる。フェイルオーバー（プライマリを変更）した際に、制御品質が低下する可能性が生じるが、変更前のプライマリからのハートビートには、当該プライマリが取得した最新の機器状態が付加されているので、新たにプライマリとなったコントローラは、それを参照して機器制御を行うことで、制御品質の低下を軽減できる。なお、図６の次の取得タイミング（Ｓ１０４）は、予め定めた時間後でなく、例えば、ランダムに決めた時間後でもよいし、予め定めたイベントが発生したタイミングでもよい。

図７に、生存確認部２０１によるハートビート送信処理のフローチャートを示す。ＨＢ通信部２０２が、自装置以外の他のすべてのコントローラに、生存確認用ネットワークを介して、ハートビートを送信する（Ｓ２０１）。ハートビートは、一例として、コントローラ情報記憶部３０１の全てまたは一部の情報を含む。ハートビートは、他のすべてのコントローラのうちの一部にのみ送信するようにしてもよい。

ＡＣＫ通信部２０３は、他のコントローラからのＡＣＫの受信状況に応じて、他のコントローラの状態を判断する（Ｓ２０２）。より詳細に、当該他のコントローラが、正常か異常かを判断する。ここで、他のコントローラのうちの任意の１台を、コントローラＣｘと記述する。なお、他のコントローラの台数は少なくとも１であり、２以上でもよい。

コントローラ状態判定部２０４が、コントローラＣｘが異常であると判断し（Ｓ２０２のＹＥＳ、Ｓ２０５）、かつ、コントローラＣｘがプライマリの場合（Ｓ２０６のＹＥＳ）、プライマリ決定部２０５が、次のプライマリを決定する（Ｓ２０７）。プライマリの決定方法は前述のとおり、制御ネットワークの状態、ならびに、通信遅延またはその分散、平均値等に基づき決定すればよい。プライマリ決定部２０５によって次のプライマリが決定されたら、生存確認部２０１は、コントローラ情報記憶部３０１にアクセスして、「役割」の欄を更新する。新たにプライマリに決定されたコントローラの「役割」を「プライマリ」にし、変更前のプライマリであったコントローラの「役割」を「非プライマリ」にする。自装置がプライマリになった場合、機器の制御に当たって、自装置が保持している最新の機器状態の情報を利用してもよいし、コントロール情報記憶部に記憶されているタイムスタンプが最新のコントローラに関連づけられた最新の機器状態の情報を利用してもよい。あるいは、コントロール情報記憶部において変更前のプライマリに関連づけられた最新の機器状態の情報を利用してもよい。

コントローラ状態判定部２０４が、コントローラＣｘが正常であると判断した場合（Ｓ２０２のＮＯ、Ｓ２０３）、次の取得タイミングまで待機し（Ｓ２０４）、上述した処理を繰り返す。ステップＳ２０６でコントローラＣｘがプライマリでない場合、またはステップＳ２０７で次のプライマリが決定された場合も、次の取得タイミングまで待機し（Ｓ２０４）、上述した処理を繰り返す。次の取得タイミングが予め定められた時間後の場合、一定間隔で、ハートビートの送信を繰り返すことになる。なお、次の取得タイミングは、当該予め定められた時間後に限定されない。

図８は、生存確認部２０１によるハートビート受信処理の動作のフローチャートを示す。

ＨＢ通信部２０２は、他のコントローラからハートビートを受信し、復号に成功したら、送達確認応答メッセージ（ＡＣＫ）を生成するための情報を、ＡＣＫ通信部２０３に渡す（Ｓ３０１）。ＡＣＫ通信部２０３が、当該情報に基づき、ＡＣＫを生成し、ゲートウェイ１２および生存確認用ネットワークを介して、当該ＡＣＫを送信する（Ｓ３０２）。

生存確認部２０１は、ハートビートに含まれている他のコントローラの情報を参照する。新しいタイムスタンプに関連づけられた情報があれば、当該情報に基づき、自装置のコントローラ情報記憶部３０１の情報を更新する（Ｓ３０３）。このとき、生存確認部２０１は、タイムスタンプ以外で、更新前と更新後で変更された値があることを検出した場合、ＨＢ通信部２０２を用いて、即座にコントロール情報記憶部の情報をハートビート送信してもよい。これにより、変更された情報を、素早く、コントローラ間で共有できる。

コントローラ情報記憶部３０１の更新後、異常判定部１０３が、２つのコントローラの組毎に、「最新の機器状態」（図４参照）の差が閾値を超えているかを判断し、閾値を超えている組が存在する場合、警報メール等の警報情報を、生存確認用ネットワーク２１を介して、管理者の端末装置Ｍに送信してもよい（Ｓ３０４）。少なくともいずれかの組に対する「最新の機器状態」の差が閾値を超える場合は、当該組に属する少なくとも一方のコントローラ、または機器が、正常でない可能性があるためである。閾値を超えている組に属する各コントローラのＩＤを警報メールに含めてもよい。ここでは組毎に「最新の機器状態」の差を判断したが、これらのコントローラ間で「最新の機器状態」の分散または標準偏差等を計算し、当該分散等が閾値を超えている場合に、警報メールを送信してもよい。

上述した本実施形態では、プライマリの異常（故障）を検出した場合に、フェイルオーバーを行った（図７のＳ２０５〜Ｓ２０７）。別の形態として、制御用ネットワークの通信遅延に基づき、プライマリの制御用ネットワークの通信品質を判断し、当該通信品質が悪いと判断した場合に、フェイルオーバーの実施を決定してもよい。以下に、この場合にフェイルオーバーを実施する条件の例をいくつか示す。

（１）プライマリの制御用ネットワークの通信遅延が閾値よりも大きくなった場合に、ファイルオーバーを行うことを決定する。
（２）プライマリの制御用ネットワークの通信遅延の分散が閾値よりも大きくなった場合に、を行うことを決定する。
（３）プライマリの制御用ネットワークの通信遅延が、他のいずれかのコントローラの制御用ネットワークの通信遅延よりも大きくなった場合に、フェイルオーバーを行うことを決定する。あるいは、当該通信遅延の差分が閾値以上になった場合に、フェイルオーバーを行うことを決定する。
（４）プライマリの制御用ネットワークの通信遅延の分散が、他のコントローラの制御用ネットワークの通信遅延の分散よりも大きくなった場合に、フェイルオーバーを行うことを決定する。あるいは、当該分散の差分が閾値以上になった場合に、フェイルオーバーを行うことを決定する。

上記の（１）〜（４）のように通信遅延に基づきフェイルオーバーの実施を決定する場合の動作例を説明する。図９は、ハートビート受信処理の動作フローチャートの他の例を示す。ステップＳ３０１〜Ｓ３０３は、図８と同じであるため、説明を省略する。

ステップＳ４０１では、プライマリの制御用ネットワークの通信品質が悪いか（上記のフェイルオーバー条件を満たしているか）を判断する。上記（１）の場合、プライマリの制御用ネットワークの通信遅延に基づき、通信品質が悪いか判断する。（２）の場合、プライマリの制御用ネットワークの通信遅延の分散を計算（更新）し、分散に基づき通信品質が悪いか判断する。（３）の場合、プライマリおよび非プライマリのそれぞれの制御用ネットワークの通信遅延に基づき、通信品質が悪いか判断する。（４）の場合、プライマリおよび非プライマリのそれぞれの制御用ネットワークの通信遅延の分散を計算（更新）し、これらの分散に基づき通信品質が悪いか判断する。

ステップＳ４０２では、ステップＳ４０１で制御用ネットワークの通信品質が悪いと判断されたとき、次のプライマリを決定する。次のプライマリを決定する方法は、前述したとおりである。

本実施形態では、コントローラは、他の全てのコントローラとハートビートを送受信する形態を示した。しかしながら、これは必須ではない。各コントローラは、一部のコントローラとだけ、ハートビートを送受信してもよい。これにより、コントローラ群としての稼働率は低下するが、コントローラ間の通信量を削減できる。ただし、各コントローラが、他のすべてのコントローラの情報（すなわちコントローラ情報記憶部の情報）を把握できる必要がある。各コントローラは、ハートビートを直接送受信しない他のコントローラの情報は、直接通信可能な他のコントローラを介して得ればよい。生存確認用ネットワーク２１は、このような条件を満たす限り、任意の構成（トポロジー）でよい。

図１０（Ａ）に、本実施形態に係る生存確認用ネットワーク２１の具体例を示す。この構成では、全てのコントローラのそれぞれは、一部のコントローラに接続され、他のコントローラには接続されていない。しかしながら、当該一部のコントローラを介して当該他のコントローラの情報を取得できるため、結果として、他の全てのコントローラの情報を把握可能である。

一方、図１０（Ｂ）の構成では、生存確認用ネットワーク２１が２つに分断されているため、他の全てのコントローラのうち一部のコントローラについてはその情報を把握できない。例えばコントローラＣ２は、コントローラＣ１の情報は取得できるものの、コントローラＣ３、Ｃ４の情報を得ることができない。コントローラＣ１、Ｃ３、Ｃ４のそれぞれについても同様のことが言える。

以上、本実施形態によれば、各コントローラで保持している機器の通信状況および制御状況に関する情報をコントローラ間で共有するとともに、生存確認用のメッセージを送りあうことで、フィードバック制御の高い稼働率を維持しつつ、コントローラ間のフェイルオーバーを実現できる。

したがって、各コントローラをクラウドコンピューティング環境に配置した場合にも、稼働率の高いフィードバック制御システムを低コストで実現でき、また柔軟性を向上させることができる。例えば、ゲートウェイが故障した場合、ゲートウェイの交換のために保守員が交換に出向いたり、交換用のゲートウェイを購入するなど、人的コストが高くなるが、クラウド上のコントローラの動作が正常でなくなった場合、運用者等の端末装置からコントローラを再起動させたり、ソフトウェアのインストールを行うことで対応できることが多い（柔軟性が高い）と想定されるため、人的コストも低くて済む。仮に、コントローラのハードウェア自体の交換が必要になっても、ゲートウェイをビルに配置する場合のビル毎の台数の合計に比べて、コントローラ数が少ないと想定されるため、この点でも人的コストが低くてすむ。

また、機器制御の状況に関する情報をゲートウェイに保持する必要はないため、メモリ容量またはＣＰＵ性能またはこれらの両方等を低く抑えることができる。

尚、各実施形態のコントローラは、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、コントローラは、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、コントローラ内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。

本実施形態で用いられる用語は、広く解釈されるべきである。例えば用語“プロセッサ”は、汎用目的プロセッサ、中央処理装置（ＣＰＵ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、マイクロコントローラ、状態マシンなどを包含してもよい。状況によって、“プロセッサ”は、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラム可能論理回路 （ＰＬＤ）などを指してもよい。“プロセッサ”は、複数のマイクロプロセッサのような処理装置の組み合わせ、ＤＳＰおよびマイクロプロセッサの組み合わせ、ＤＳＰコアと協働する１つ以上のマイクロプロセッサを指してもよい。

別の例として、用語“メモリ”は、電子情報を格納可能な任意の電子部品を包含してもよい。“メモリ”は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、プログラム可能読み出し専用メモリ（ＰＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、フラッシュメモリ、磁気または光学データストレージを指してもよく、これらはプロセッサによって読み出し可能である。プロセッサがメモリに対して情報を読み出しまたは書き込みまたはこれらの両方を行うならば、メモリはプロセッサと電気的に通信すると言うことができる。メモリは、プロセッサに統合されてもよく、この場合も、メモリは、プロセッサと電気的に通信していると言うことができる。

また、用語“ストレージ”は、磁気技術、光学技術、または不揮発性メモリを利用して、永久的にデータを記憶できるに任意の装置を包含してもよい。例えば、ストレージは、ＨＤＤ、光学ディスク、ＳＳＤ等でもよい。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

Ｃ１、Ｃ２、Ｃ３：コントローラ
２１：生存確認用ネットワーク
１２：ゲートウェイ
１１：機器
１０１：監視視制御部
１０２：機器状態取得部
１０３：異常判定部
１０４：制御用ネットワーク状態判定部
１０５：制御用ネットワーク遅延計算部
１０８：制御用ネットワーク遅延平均計算部
１０９：制御用ネットワーク遅延分散計算部
１０７：制御値演算部
１０６：制御値送信部
２０１：生存確認部
２０２：ハートビート（ＨＢ）通信部
２０３：送達確認応答（ＡＣＫ）通信部
２０４：コントローラ状態判定部
２０５：プライマリ決定部
３０１：コントローラ情報記憶部
４５１：プロセッサ
４５２：メモリ
４５３：ストレージ
４５４：ネットワークインタフェース
４５５：ネットワークインタフェース
４５６：バス

Claims (16)

1. 第１のネットワークを介して、機器の状態情報を取得する機器状態取得部と、
   前記機器の制御を行う第１の役割を有するか否かの情報を自装置および他のコントローラごとに保持する記憶部と、
   自装置が前記第１の役割の場合、前記機器の状態情報に基づき、前記機器の制御を行う制御部と、
   前記第１ネットワークの通信品質に関する第１情報を測定する測定部と、
   第２のネットワークを介して、前記第１情報を含む第１メッセージを前記他のコントローラに送信し、前記他のコントローラから前記機器との間の第３のネットワークの通信品質に関する第２情報を含む第２メッセージを、前記第２のネットワークを介して受信する通信部と、
   前記第２のネットワークを介して前記他のコントローラと通信することにより、前記他のコントローラの状態を判定するコントローラ状態判定部と、
   前記他のコントローラの状態と、前記第１情報および前記第２情報に基づいて、前記自装置および前記他のコントローラの中から、前記第１の役割のコントローラを決定する決定部と、
   を備えたコントローラ。
2. 前記通信部は、前記第２のネットワークを介して、前記他のコントローラから前記他のコントローラで取得された前記機器の状態情報を含む第３メッセージを受信し、
   前記記憶部は、前記第３メッセージに含まれている前記機器の状態情報を、前記他のコントローラに関連づけて記憶し、
   前記制御部は、前記他のコントローラから自装置に前記第１の役割が変更されることが決定された場合、前記記憶部において前記他のコントローラに関連づけられた前記状態情報を用いて、前記機器を制御する
   請求項１に記載のコントローラ。
3. 前記通信部は、前記第２のネットワークを介して、複数の前記他のコントローラから複数の前記他のコントローラで取得された前記機器の状態情報とタイムスタンプとを含む第３メッセージをそれぞれ受信し、
   前記記憶部は、前記機器状態取得部で取得された前記機器の状態情報と、前記機器の状態情報が取得された時刻を表すタイムスタンプとを記憶し、複数の前記他のコントローラから受信された前記第３メッセージに含まれている前記機器の状態情報とタイムスタンプとを記憶し、
   前記制御部は、前記他のコントローラから自装置に前記第１の役割が変更されることが決定された場合、前記記憶部において最も新しいタイムスタンプに対応する前記機器の状態情報を用いて、前記機器を制御する
   請求項１に記載のコントローラ。
4. 前記測定部は、前記第１ネットワークの通信遅延を測定し、
   前記制御部は、前記第１ネットワークの通信遅延に基づいて、前記機器に対する制御値を計算し、前記第１ネットワークを介して、前記制御値を前記機器に送信する
   請求項１ないし３のいずれか一項に記載のコントローラ。
5. 前記コントローラ状態判定部は、自装置および前記他のコントローラのうち前記第１の役割を有するコントローラの前記通信遅延または当該コントローラの状態に基づいて、前記第１の役割を変更するかを決定する
   請求項１ないし４のいずれか一項に記載のコントローラ。
6. 前記決定部は、自装置および前記他のコントローラのそれぞれの通信遅延に基づいて、前記第１の役割となるコントローラを決定する
   請求項１ないし５のいずれか一項に記載のコントローラ。
7. 前記機器状態取得部は、自装置が前記第１の役割を有するかに応じて、前記機器の状態情報を取得する時間間隔を変更する
   請求項１ないし６のいずれか一項に記載のコントローラ。
8. 前記コントローラ状態判定部は、前記第１メッセージに対する送達確認メッセージの受信状況に応じて、前記他のコントローラの状態を判定する
   請求項１ないし７のいずれか一項に記載のコントローラ。
9. 前記第１メッセージは、前記機器状態取得部で取得された前記機器の状態情報を含む
   請求項１ないし８のいずれか一項に記載のコントローラ。
10. 前記他のコントローラが第１の役割を有し、
    前記コントローラ状態判定部は、前記他のコントローラが正常か異常かを判定し、
    前記決定部は、前記他のコントローラが異常の場合に、前記第１の役割を前記他のコントローラから変更することを決定する
    請求項１ないし９のいずれか一項に記載のコントローラ。
11. 前記通信部は、複数の前記他のコントローラのうちの１つから前記第２メッセージを受信した場合に、前記第２メッセージから前記第２情報を取得し、前記複数の他のコントローラのうちの別のコントローラに、前記第２のネットワークを介して前記第２情報を含む第４メッセージを送信する
    請求項１ないし１０のいずれか一項に記載のコントローラ。
12. 前記第２メッセージは、前記１つのコントローラで測定された前記機器の状態情報を含み、
    前記第４メッセージは、前記１つのコントローラで測定された前記機器の状態情報を含む
    請求項１１に記載のコントローラ。
13. 異常判定部を備え、
    前記通信部は、前記第２のネットワークを介して、前記機器の状態情報を前記他のコントローラから受信し、
    前記異常判定部は、前記機器状態取得部で取得された前記機器の状態情報と、前記通信部で受信された前記機器の状態情報との差分に応じて、警報情報を予め指定された装置に出力する
    請求項１ないし１２のいずれか一項に記載のコントローラ。
14. 異常判定部を備え、
    前記他のコントローラが前記第１の役割を有し、
    前記通信部は、前記第２のネットワークを介して、前記他のコントローラから前記他のコントローラで取得された前記機器の状態情報を時間の経過に応じて複数回受信し、
    前記異常判定部は、受信された前記状態情報が示す値の推移と予め定めた推移との乖離に応じて、警報情報を予め定めた装置に出力する
    請求項１ないし１３のいずれか一項に記載のコントローラ。
15. コンピュータに実行させるためのプログラムであって、
    第１のネットワークを介して、機器の状態情報を取得するステップと、
    前記機器の制御を行う第１の役割を有するか否かの情報を自装置および他のコントローラごとに記憶装置に保持するステップと、
    自装置が前記第１の役割の場合、前記機器の状態情報に基づき、前記機器の制御を行う制御ステップと、
    前記第１ネットワークの通信品質に関する第１情報を測定する測定ステップと、
    第２のネットワークを介して、前記第１情報を含む第１メッセージを前記他のコントローラに送信するステップと、
    前記他のコントローラから前記機器との間の第３のネットワークの通信品質に関する第２情報を含む第２メッセージを、前記第２のネットワークを介して受信するステップと、
    前記第２のネットワークを介して前記他のコントローラと通信することにより、前記他のコントローラの状態を判定するステップと、
    前記他のコントローラの状態と、前記第１情報および前記第２情報に基づいて、前記自装置および前記他のコントローラの中から、前記第１の役割のコントローラを決定するステップと
    をコンピュータに実行させるためのプログラム。
16. それぞれ第１〜第ｎネットワークを介して機器と接続された第１〜第ｎのコントローラを備え、
    前記複数のコントローラは、前記第１〜第ｎネットワークとは別のネットワークを介して互いに接続され、
    前記第１〜第ｎのコントローラのそれぞれは、
    前記第１〜第ｎのネットワークを介して、前記機器の状態情報を取得する機器状態取得部と、
    前記機器の制御を行う第１の役割を有するか否かの情報を前記複数のコントローラごとに保持する記憶部と、
    自装置が前記第１の役割を有する場合、前記機器の状態情報に基づき、前記機器の制御を行う制御部と、
    前記第１〜第ｎのネットワークの通信品質に関する第１情報を測定する測定部と、
    前記別のネットワークを介して、前記第１情報を含む第１メッセージを前記他のコントローラに送信し、前記他のコントローラから前記機器との間の前記ネットワークの通信品質に関する第２情報を含む第２メッセージを、前記別のネットワークを介して受信する通信部と、
    前記別のネットワークを介して前記他のコントローラと通信することにより、前記他のコントローラの状態を判定するコントローラ状態判定部と、
    前記他のコントローラの状態と、前記第１情報および前記第２情報に基づいて、前記第１〜第ｎのコントローラの中から、前記第１の役割のコントローラを決定する決定部と、
    を備えた制御システム。

Images