JP2023045180A - 制御クラウドサーバ - Google Patents

Abstract

【課題】制御システム内で得られた情報を、１つの制御システムを超えて活用することができる制御クラウドサーバを提供する。【解決手段】実施形態の制御クラウドサーバは、クラウドコントローラとクラウドコントローラのコントロール対象機器とで構成される複数の制御システムごとの発報ルールとが登録された発報ルールテーブルを記憶する。また、制御クラウドサーバは、複数の制御システムの各々に含まれる複数のクラウドコントローラから、複数の制御システムごとの構成および運転状態に関する制御システム情報を取得する。制御クラウドサーバは、制御システム情報により発報ルールテーブルを参照して複数の制御システムごとの発報の要否、発報が要の場合のアクセス先、およびアクセス先への送信内容を特定し、特定したアクセス先に、送信内容を送信する。【選択図】図１

Description

本発明の実施形態は、制御クラウドサーバに関する。

従来、産業プラント（以下、単に「プラント」という）を制御するコントローラおよびＨＭＩ（Human Machine Interface）等を含む制御システムは、各プラントのローカル環境に設けられていた。

特開２０１１－２１５８３２号公報

しかしながら、従来技術においては、制御システム内で得られた情報の活用はローカルの制御システム内での利用に留まっていた。

実施形態の制御クラウドサーバは、クラウドコントローラとクラウドコントローラのコントロール対象機器とで構成される複数の制御システムごとの発報ルールとが登録された発報ルールテーブルを記憶する。また、制御クラウドサーバは、複数の制御システムの各々に含まれる複数のクラウドコントローラから、複数の制御システムごとの構成および運転状態に関する制御システム情報を取得する。制御クラウドサーバは、制御システム情報により発報ルールテーブルを参照して複数の制御システムごとの発報の要否、発報が要の場合のアクセス先、およびアクセス先への送信内容を特定し、特定したアクセス先に、送信内容を送信する。

図１は、実施形態に係る管理システムの全体構成の一例を示す図である。 図２は、実施形態に係る発報ルールテーブルの一例を示す図である。 図３は、実施形態に係るメールによる発報の一例を示す図である。 図４は、実施形態に係るＨＭＩによる発報の一例を示す図である。 図５は、実施形態に係るＷｅｂベースＨＭＩによる発報の一例を示す図である。 図６は、実施形態に係る基準情報生成処理の流れの一例を示すフローチャートである。 図７は、実施形態に係る故障予測の発報の処理の流れの一例を示すフローチャートである。 図８は、実施形態に係る故障予測の発報の処理の流れの一例を示すフローチャートである。 図９は、実施形態に係る更新情報の発報の処理の流れの一例を示すフローチャートである。 図１０は、実施形態における通常運用時の制御クラウドサーバとローカルＩ／Ｏシステムとの通信の一例を示す図である。 図１１は、実施形態における非通常運用時の制御クラウドサーバとローカルＩ／Ｏシステムとの通信の一例を示す図である。 図１２は、実施形態に係るリモートＩ／Ｏに入力されたセンサデータの値を時系列に示すグラフの一例である。

（実施形態）
図１は、実施形態に係る管理システムＳの全体構成の一例を示す図である。図１に示すように、管理システムＳは、クラウド環境１に設けられた制御クラウドサーバ１２、複数のクラウドコントローラ１１ａ～１１ｎ、および複数のローカルＩ／Ｏ（Input Output）システム２ａ～２ｎを含む。また、クラウド環境１には、メールサーバ４１およびＷｅｂベースＨＭＩ４２が設けられる。メールサーバ４１およびＷｅｂベースＨＭＩ４２は、管理システムＳに含まれてもよいし、含まれなくともよい。ＷｅｂベースＨＭＩ４２は、クラウドＨＭＩまたはＯＩＳ（Operator Interface Station）と呼ばれてもよい。

管理システムＳに含まれるクラウドコントローラ１１ａ～１１ｎ、およびローカルＩ／Ｏシステム２ａ～２ｎの数は特に限定されるものではない。以下、個々のクラウドコントローラ１１ａ～１１ｎを特に区別しない場合には、単にクラウドコントローラ１１という。また、個々のローカルＩ／Ｏシステム２ａ～２ｎを特に区別しない場合には、単にローカルＩ／Ｏシステム２という。ローカルＩ／Ｏシステム２は、本実施形態におけるローカルシステムの一例である。

制御クラウドサーバ１２、および複数のクラウドコントローラ１１ａ～１１ｎを総称して、制御クラウドサービス１０という。

クラウドコントローラ１１ａ～１１ｎは、ローカルＩ／Ｏシステム２ａ～２ｎを制御する。具体的には、クラウドコントローラ１１ａは、ローカルＩ／Ｏシステム２ａを制御し、クラウドコントローラ１１ｎは、ローカルＩ／Ｏシステム２ｎを制御する。

より詳細には、クラウドコントローラ１１は、制御プログラムの一種であるＰＯＵ（Program Organization Unit）を実行することにより、ローカルＩ／Ｏシステム２に含まれるリモートＩ／Ｏ２３１ａ，２３２ａ，２３１ｎ，２３２ｎを制御する。

制御主体であるクラウドコントローラ１１と、制御対象であるローカルＩ／Ｏシステム２とは１対１で対応する。１組のクラウドコントローラ１１とローカルＩ／Ｏシステム２の組み合わせを、制御システム３という。例えば、制御システム３ａは、クラウドコントローラ１１ａとローカルＩ／Ｏシステム２ａを含む。また、制御システム３ｎは、クラウドコントローラ１１ａとローカルＩ／Ｏシステム２ｎを含む。

ローカルＩ／Ｏシステム２ａ～２ｎは、それぞれ、ローカル環境に設けられる。ローカル環境とは、ローカルＩ／Ｏシステム２ａ～２ｎの制御対象である産業プラント（以下、単に「プラント」という）内に物理的に設けられた環境である。つまり、ローカルＩ／Ｏシステム２ａ～２ｎに含まれる各種の装置は、プラント内に物理的に設けられる。

これに対して、クラウドコントローラ１１ａ～１１ｎ、制御クラウドサーバ１２、メールサーバ４１、およびＷｅｂベースＨＭＩ４２を備えるクラウド環境１は、プラント内ではなく、一例としてデータセンター等の遠隔地に設けられる。ローカルＩ／Ｏシステム２と、クラウド環境１とはインターネット５等のネットワークを介して接続する。なお、クラウド環境１上に設けられる各装置（制御クラウドサーバ１２、クラウドコントローラ１１、メールサーバ４１、およびＷｅｂベースＨＭＩ４２）は、１台のコンピュータが複数の装置として機能しても良いし、複数のコンピュータが１つの装置として仮想的に機能しても良い。クラウド環境を物理的に構成するコンピュータは、例えば、ＣＰＵ等の制御装置と、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等の記憶装置と、ＨＤＤ（Hard Disk Drive）等の外部記憶装置とを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、図１における破線の矢印は、各装置間の通信接続関係を示す。

図１に示す例では、ローカルＩ／Ｏシステム２ａは、ＨＭＩ２１ａ、通信モジュール２２ａ、リモートＩ／Ｏ２３１ａ，２３２ａ、および故障診断モジュール２５ａを備える。ローカルＩ／Ｏシステム２ａは、ＨＭＩ２１ａ、通信モジュール２２ａ、リモートＩ／Ｏ２３１ａ，２３２ａ、および故障診断モジュール２５ａは、Ｉ／Ｏバス２０ａにより接続する。また、ローカルＩ／Ｏシステム２ｎは、ＨＭＩ２１ｎ、通信モジュール２２ｎ、リモートＩ／Ｏ２３１ｎ，２３２ｎ、および故障診断モジュール２５ｎを備える。ローカルＩ／Ｏシステム２ｎは、ＨＭＩ２１ｎ、通信モジュール２２ｎ、リモートＩ／Ｏ２３１ｎ，２３２ｎ、および故障診断モジュール２５ｎは、Ｉ／Ｏバス９０ｎにより接続する。

また、ローカルＩ／Ｏシステム２は、さらに、クラウドコントローラ１１で実行されるＰＯＵを生成するエンジニアリングツールを備えても良い。エンジニアリングツールは、例えば、ＣＰＵ等の制御装置と、ＲＯＭやＲＡＭ等の記憶装置と、ＨＤＤ等の外部記憶装置とを備える通常のハードウェア構成を備えるＰＣでもよいし、専用端末でも良い。

ＨＭＩ２１ａ，２１ｎは、クラウドコントローラ１１で実行される処理の状況等を、オペレータが監視するために用いられる装置である。以下、個々のＨＭＩ２１ａ，ＨＭＩ２１ｎを特に区別しない場合には、単にＨＭＩ２１という。

通信モジュール２２ａ，２２ｎは、クラウドコントローラ１１とインターネット５を介して通信接続する。以下、個々の通信モジュール２２ａ，２２ｎを特に区別しない場合には、単に通信モジュール２２という。

リモートＩ／Ｏ２３１ａ，２３２ａ，２３１ｎ，２３２ｎは、プラントに設けられたセンサおよびその他の機器との間で信号の入出力をするためのインタフェースである。リモートＩ／Ｏ２３１ａ，２３２ａ，２３１ｎ，２３２ｎは、クラウドコントローラ１１からインターネット５および通信モジュール２２を介してリモート制御される。センサおよびその他の機器からリモートＩ／Ｏ２３１ａ，２３２ａ，２３１ｎ，２３２ｎに入力されたデータは、通信モジュール２２およびインターネット５を介してクラウドコントローラ１１に送信される。以下、個々のリモートＩ／Ｏ２３１ａ，２３２ａ，２３１ｎ，２３２ｎを特に区別しない場合には、単にリモートＩ／Ｏ２３という。

故障診断モジュール２５ａ，２５ｎは、ローカルＩ／Ｏシステム２における情報を収集し、収集した情報に基づいて、ローカルＩ／Ｏシステム２で発生した故障を検知する。故障診断モジュール２５ａ，２５ｎは、故障を検知した場合に、制御クラウドサーバ１２に当該故障に関する故障情報を送信する。以下、個々の故障診断モジュール２５ａ，２５ｎを特に区別しない場合には、単に故障診断モジュール２５という。なお、本実施形態における故障とは、ハードウェアの故障に限定される、ソフトウェア的なエラー、および動作不具合等を含んでも良い。

故障診断モジュール２５が収集する情報は、例えば、ローカルＩ／Ｏシステム２の運転データ、ローカルＩ／Ｏシステム２で発生したアラーム、およびＲＡＳ（Reliability， Availability and Serviceability）情報等である。ローカルＩ／Ｏシステム２の運転データは、例えば、クラウドコントローラ１１で実行されたＰＯＵによりリモートＩ／Ｏ２３が動作した動作履歴である。

故障診断モジュール２５ａ，２５ｎは、通信モジュール２２ａ，２２ｎを介さずに制御クラウドサーバ１２と通信可能である。また、故障診断モジュール２５ａ，２５ｎは、インターネット５だけではなく、電話回線（不図示）により制御クラウドサーバ１２と通信しても良い。

なお、故障診断モジュール２５ａ，２５ｎは、例えば、ＰＬＣ（Programmable Logic Controller）、またはＤＣＳ（分散制御システム、Distributed Control System）のコントローラとしての機能を備えても良い。例えば、クラウドコントローラ１１がダウンまたはエラーにより機能しない場合に、故障診断モジュール２５ａ，２５ｎがＰＯＵを実行しても良い。この場合、クラウドコントローラ１１の記憶部１２０に保存されているＰＯＵが、故障診断モジュール２５ａ，２５ｎ内の記憶部（不図示）にも保存されており、故障診断モジュール２５ａ，２５ｎが当該ＰＯＵを実行可能であるものとする。以下、個々の故障診断モジュール２５ａ，２５ｎを区別しない場合には、単に故障診断モジュール２５という。

制御クラウドサーバ１２は、複数のクラウドコントローラ１１ａ～１１ｎから、複数の制御システム３ａ～３ｎの構成および運転状態に関する制御システム情報を取得する。

制御システム情報１２１は、例えば、複数の制御システム３ａ～３ｎに含まれる機器の構成、複数のクラウドコントローラ１１ａ～１１ｎで実行されるＰＯＵ、制御システム３ａ～３ｎに含まれる機器の使用期間、制御システム３ａ～３ｎで使用されるＩ／Ｏバス２０ａ～２０ｎの規格、制御システム３ａ～３ｎに含まれる機器のファームウェアのバージョン、制御システム３ａ～３ｎに含まれる機器のファームウェアのバージョンの最新の更新日、制御システム３ａ～３ｎに含まれる機器のファームウェアの更新者、制御システム３ａ～３ｎの運転データ、制御システム３ａ～３ｎを操作するオペレータのオペレーション記録、制御システム３ａ～３ｎで発生したアラーム、故障情報、ＲＡＳ情報、オペレータの操作に関する動画、およびオペレータの操作に関する音声のうち少なくとも１つを含む。より詳細には、本実施形態においては、制御システム情報１２１は、少なくとも、複数の制御システム３ａ～３ｎに含まれる機器の構成、機器の使用期間、および複数の制御システム３ａ～３ｎに含まれる機器のファームウェアのバージョンを含むものとする。また、複数の制御システム３ａ～３ｎのいずれかにおいて機器の故障が発生した場合には、制御システム情報１２１は、さらに、故障が発生した機器の型番と使用期間を含む故障情報を含むものとする。なお、システム情報１２１に故障情報が含まれるとは、規定のフォーマットのシステム情報１２１に故障についての記録が含まれていることであってもよいし、規定のフォーマットのシステム情報１２１に加えて、故障情報が別途送信されることでもよい。

また、制御システム情報１２１は、オペレータまたはエンジニア等により手動で入力されても良い。

Ｉ／Ｏバス２０ａ～２０ｎの規格は、例えばＤｅｖｉｃｅＮｅｔ（登録商標）等であるが、これに限定されるものではない。

制御システム３ａ～３ｎの運転データは、例えば、ＰＯＵの実行ログおよびリモートＩ／Ｏ２３の入出力データが時系列に記録されたデータである。

故障情報は、制御システム３で発生した故障に関する故障情報である。主として、ローカルＩ／Ｏシステム２で発生した故障を対象としても良い。

また、制御システム情報は、さらに、エンジニアリングツールで生成された各種の情報を含んでも良い。

オペレータの操作に関する動画、およびオペレータの操作に関する音声は、例えばオペレータが使用する管理室に設けられた不図示のカメラおよびマイクにより収集される。動画および音声は、ローカルＩ／Ｏシステム２の通信モジュール２２を介して制御クラウドサーバ１２に送信されてもよいし、ローカルＩ／Ｏシステム２を介さずに、制御クラウドサーバ１２に送信されてもよい。

メールサーバ４１は、制御クラウドサーバ１２の制御の下、各プラントのオペレータ、および各プラントに制御システム３を導入したシステムインテグレータ等にメールを送信する。

ＷｅｂベースＨＭＩ４２は、オペレータが画面操作をするためのヒューマンインタフェースである。ＷｅｂベースＨＭＩ４２は、クラウド環境１上で動作する。例えば、インターネット５経由でＷｅｂベースＨＭＩ４２と接続するＰＣまたはタブレット装置のディスプレイに、ＷｅｂベースＨＭＩ４２で生成された画面が表示される。ＷｅｂベースＨＭＩ４２にアクセスするＰＣまたはタブレット装置は、ローカルＩ／Ｏシステム２外に設けられてもよい。なお、ＷｅｂベースＨＭＩ４２は、クラウド環境１ではなく、ローカル環境に設けられてもよい。

制御クラウドサーバ１２は、複数のクラウドコントローラ１１ａ～１１ｎから取得した各クラウドコントローラ１１ａ～１１ｎの制御システム情報１２１を、記憶部１２０に保存する。また、制御クラウドサーバ１２の記憶部１２０は、各クラウドコントローラ１１ａ～１１ｎの基準情報１２も記憶する。また、制御クラウドサーバ１２は、複数の故障診断モジュール２５ａ～２５ｎのいずれかから故障情報が送信された場合、当該故障情報も記憶部１２０に保存する。また、記憶部１２０は、制御システムごとの発報手法と発報先とが登録された発報ルールテーブル１２２を記憶する。なお、記憶部１２０は、物理的にはクラウド環境１を構成するコンピュータのＨＤＤ等の外部記憶装置により実現される。

本実施形態においては、制御クラウドサーバ１２は、複数のクラウドコントローラ１１ａ～１１ｎおよび複数の故障診断モジュール２５ａ～２５ｎから取得した情報を集約して保存する。本実施形態において、異なる制御システム３間では、制御クラウドサーバ１２を介さない直接的なデータのやり取りは行われないものとする。例えば、クラウドコントローラ１１ａとクラウドコントローラ１１ｎとは直接的に情報の送受信は行わない。

制御クラウドサーバ１２は、複数の制御システム３ａ～３ｎの基準情報１２３と複数のクラウドコントローラ１１ａ～１１ｎから収集された制御システム情報とを比較して変化点がある場合に、発報する。一例として、制御クラウドサーバ１２は、制御システム情報から複数の制御システム３ａ～３ｎの各々の標準の状態を規定する基準情報１２３を生成する。そして、制御クラウドサーバ１２は、基準情報１２３の生成後に新たに取得した制御システム情報と基準情報１２３を比較して新たに取得した制御システム情報に変化点がある場合、後述の発報ルールテーブル１２２を参照して変化点がある制御システム情報に対応する制御システム３に対応付けられたアクセス先、および当該アクセス先への送信内容を特定し、特定したアクセス先に、当該アクセス先に対応付けられた送信内容を送信する。

基準情報１２３は、複数の制御システム３～３ｎの各々の標準の状態を規定する。標準の状態とは、制御クラウドサーバ１２による発報の対象とならない状態である。基準情報１２３は、複数の制御システム３ａ～３ｎごとに定められる。

具体的には、基準情報１２３は、平常時における制御システム情報であっても良い。この場合、平常時における制御システム情報が基準情報となる。

例えば、基準情報１２３が平常時における制御システム情報である場合、変化点は、平常時における制御システム情報と、収集された制御システム情報との差異である。例えば、平常時において「エラーによるアラームが発生していないこと」が基準である場合、いずれかのクラウドコントローラ１１から収集された制御システム情報にエラーによるアラームが含まれる場合は、基準情報１２３と制御システム情報１２１とに差異があるため、当該アラームの発生が変化点となる。また、平常時におけるセンサ値の値が、基準情報１２３であってもよい。この場合、制御クラウドサーバ１２は、複数のクラウドコントローラ１１ａ～１１ｎの各々から取得した制御システム情報の運転データに含まれるセンサ値から、平常時におけるセンサ値を取集して基準情報１２３として登録する。その後、新たに取得した制御システム情報の運転データに含まれるセンサ値が基準情報１２３として登録されたセンサ値と規定の閾値以上異なる場合、制御クラウドサーバ１２は、センサ値に変化点が発生したと判定する。

また、基準情報１２３が、制御システム３の管理者等により更新される場合がある。例えば、ファームウェアの新しいバージョンがリリースされた場合、制御システム３の管理者が最新のファームウェアのバージョンを、基準情報１２３として追加登録する。なお、本実施形態においては、基準情報１２３に新たな情報を追加すること、および基準情報１２３登録済みの内容を変更することを、基準情報１２３を更新する、という。クラウドコントローラ１１から収集された制御システム情報に含まれるファームウェアのバージョンが最新ではない場合、ファームウェアのバージョンの差異が変化点となる。

また、基準情報１２３として、制御システム３の運転データの閾値または範囲が定められていても良い。例えば、制御システム３に含まれるリモートＩ／Ｏ２３に入力されたデータが基準情報１２３として定められた閾値を超えた場合、当該データの発生が変化点となる。なお、単にデータが閾値を超えた場合だけではなく「連続してｎ回閾値を超えた場合」等の条件が基準情報に含まれても良い。

また、基準情報１２３が、「制御システム３に故障がないこと」である場合、いずれかの制御システム３に故障が発生した場合、当該故障が変化点となる。制御クラウドサーバ１２は、クラウドコントローラ１１または故障診断モジュール２５から故障情報を取得した場合、発報する。

また、制御クラウドサーバ１２がクラウドコントローラ１１または故障診断モジュール２５から収集した制御システム３の運転データ等から故障の発生を検知した場合、当該故障の発生の検知が変化点となる。この場合にも、制御クラウドサーバ１２は、発報する。制御クラウドサーバ１２による故障の検知の手法は特に限定されるものではなく、例えば、深層学習等のＡＩ（Artificial Intelligence）技術を採用してもよい。一例として、制御クラウドサーバ１２は、ＡＩ技術により、制御システム３ごとに、制御システム３が問題なく動作している状況における過去の制御システム情報を学習することにより、基準となる制御システム情報のパターンを特定する。そして、制御クラウドサーバ１２は、クラウドコントローラ１１から取得した制御システム情報が学習によって得られた基準となる制御システム情報に合致しない場合、故障の発生を検知する。

また、制御クラウドサーバ１２は、いずれかの制御システム３における故障を検知した場合であって、他の制御システム３において同様の故障が発生する可能性が高い場合、当該故障の発生の予測が変化点となる。この場合、制御クラウドサーバ１２は、故障が予測される他の制御システム３のＨＭＩ２１、当該他の制御システム３のオペレータ宛のメールの送信、またはＷｅｂベースＨＭＩ４２による表示により発報する。

より具体的には、複数の制御システム３ａ～３ｎのうちのいずれかの制御システム３で故障が発生した機器と同じ型番、かつ故障が発生した機器と使用期間が近い機器が存在することが変化点となる。故障が発生した機器と使用期間が近い機器とは、例えば、当該機器の使用期間と、故障が発生した機器の使用期間との差異が閾値以下の機器である。閾値は特に限定されるものではないが、例えば故障の種類に応じて変化しても良い。また、故障が発生した機器と使用期間との近さではなく、規定の使用期間以上使用されている機器を対象としても良い。例えば、規定の使用期間以上使用されている機器は、経年劣化による故障の可能性が高くなる。なお、機器別の規定の使用期間が制御クラウドサーバ１２の記憶部１２０に保存されていても良い。

また、いずれかのクラウドコントローラ１１がダウンしている場合、当該ダウンが変化点となる。例えば、制御クラウドサーバ１２は、定期的にクラウドコントローラ１１にアクセスし応答を受けることにより、クラウドコントローラ１１が動作していることを確認する。制御クラウドサーバ１２は、クラウドコントローラ１１から応答がない場合、クラウドコントローラ１１がダウンしていると判定し、発報する。なお、ダウンの判定は、クラウドコントローラ１１から規定の回数以上連続して応答がない場合であってもよい。

また、いずれかの故障診断モジュール２５から取得した故障情報と、当該故障診断モジュール２５と同じ制御システム３に含まれるクラウドコントローラ１１から取得した故障情報とに差異が発生している場合、当該差異の発生が変化点となる。

より詳細には、制御クラウドサーバ１２は、複数の故障診断モジュール２５ａ～２５ｎから取得した故障情報と、複数の故障診断モジュール２５ａ～２５ｎと同じ制御システム３に含まれる複数のクラウドコントローラ１１ａ～１１ｎから取得した故障情報と、を比較する。例えば、制御クラウドサーバ１２は、故障診断モジュール２５ａから取得した故障情報とクラウドコントローラ１１ａから取得した故障情報とを比較する。また、制御クラウドサーバ１２は、故障診断モジュール２５ｎから取得した故障情報とクラウドコントローラ１１ｎから取得した故障情報とを比較する。

故障診断モジュール２５から取得した故障情報と、当該故障診断モジュール２５と同じ制御システム３に含まれるクラウドコントローラ１１から取得した故障情報とが一致する場合、当該故障情報の信頼性が高い。この場合、制御クラウドサーバ１２は、当該故障情報に基づいて、発報する。

また、故障診断モジュール２５から取得した故障情報と、当該故障診断モジュール２５と同じ制御システム３に含まれるクラウドコントローラ１１から取得した故障情報とが不一致の場合、クラウドコントローラ１１がダウンしている、あるいはクラウドコントローラ１１とローカルＩ／Ｏシステム２との通信が途絶した可能性がある。

故障診断モジュール２５から取得した故障情報と、当該故障診断モジュール２５と同じ制御システム３に含まれるクラウドコントローラ１１から取得した故障情報とが不一致の場合であって、当該クラウドコントローラ１１がダウンしている場合、制御クラウドサーバ１２は、当該クラウドコントローラ１１を含む制御システム３のオペレータ宛のメールの送信、またはＷｅｂベースＨＭＩ４２による表示により発報する。

また、故障診断モジュール２５から取得した故障情報と、当該故障診断モジュール２５と同じ制御システム３に含まれるクラウドコントローラ１１から取得した制御システム情報に含まれる故障情報とが不一致の場合であって、当該クラウドコントローラ１１がダウンしていない場合、制御クラウドサーバ１２は、当該クラウドコントローラ１１に、制御信号を送信してダウンさせる。これは、クラウドコントローラ１１とローカルＩ／Ｏシステム２との通信の途絶など何らかの不具合が発生している可能性のある状態でクラウドコントローラ１１が動作を継続することを防ぐためのフェールセーフ機能である。また、この場合、制御クラウドサーバ１２は、当該クラウドコントローラ１１を含む制御システム３のオペレータ宛のメールの送信、またはＷｅｂベースＨＭＩ４２による表示により発報する。

なお、変化点は上述の各例に限定されるものではない。

どのような変化点の場合に発報するか否かは、各制御システム３ごとに、オペレータおよびエンジニア等が個別に設定可能である。各制御システム３ごとの発報の要否は、制御クラウドサーバ１２の記憶部１２０の発報ルールテーブル１２２に登録される。

本実施形態においては、発報の手法として、メールの送信、ローカルＩ／Ｏシステム２に含まれるＨＭＩ２１による表示、およびＷｅｂベースＨＭＩ４２による表示、の３つの手法がある。

メールの送信の場合、制御クラウドサーバ１２は、メールサーバ４１に、発報ルールテーブル１２２に予め設定された宛先にアラートメールを送信させる。

また、ＨＭＩ２１による表示の場合、制御クラウドサーバ１２は、発報対象の制御システム３に含まれるクラウドコントローラ１１に発報ルールテーブル１２２に登録された送信内容を送信する。この場合、クラウドコントローラ１１は、対応するＨＭＩ２１に当該送信内容に基づくアラートを表示させる。ＨＭＩ２１での表示動作もクラウドコントローラ１１の管理対象であるため、制御クラウドサーバ１２から直接的にＨＭＩ２１を制御することはしないものとする。

また、ＷｅｂベースＨＭＩ４２による表示の場合、制御クラウドサーバ１２は、クラウド環境１に設けられたＷｅｂベースＨＭＩ４２に制御信号を送信することにより、ＷｅｂベースＨＭＩ４２で提供される画面にアラートを表示させる。これにより、ＷｅｂベースＨＭＩ４２にアクセスしたＰＣおよびタブレット装置のディスプレイに、当該アラートが表示される。

発報の手法は、各制御システム３ごとおよび変化点の種類ごとに、オペレータおよびエンジニア等により定められる。例えば、各制御システム３ごとおよび変化点の種類ごとの発報の手法は、制御クラウドサーバ１２に保存された発報ルールテーブル１２２に登録される。

図２は、本実施形態に係る発報ルールテーブル１２２の一例を示す図である。発報ルールテーブル１２２は、複数の制御システム３ごとの発報ルールが登録されたテーブルである。より詳細には、図２に示すように、発報ルールテーブル１２２は、制御システム３を特定可能な制御システム番号と、監視対象と、発報要否と、アクセス先と、送信内容とが対応付けられたテーブルである。

監視対象は、発報の対象となる事象である。図２では、故障予測、異常値、エラー発生、クラウドコントローラダウン、およびファームウェアの更新情報を監視対象として例示しているが、監視対象はこれらに限定されるものではない。監視対象は、変化点の種類ともいう。

発報要否は、監視対象ごとの発報の要否の設定である。

例えば、制御システム番号“１”の制御システム３では、当該制御システム３に故障が予測される場合、当該制御システム３で異常値が検知された場合、当該制御システム３でエラーが発生した場合、当該制御システム３に含まれるクラウドコントローラ１１がダウンした場合、および当該制御システム３に含まれる装置で使用されるファームウェアの新しいバージョンがリリースされた場合に発報をすることが設定されている。

また、制御システム番号“２”の制御システム３では、当該制御システム３で異常値が検知された場合、該制御システム３でエラーが発生した場合、および当該制御システム３に含まれるクラウドコントローラ１１がダウンした場合に発報をすることが設定されているが、当該制御システム３に故障が予測される場合、および当該制御システム３に含まれる装置で使用されるファームウェアの新しいバージョンがリリースされた場合には発報をしないことが設定されている。

アクセス先は、発報要否が“要”である場合に、制御クラウドサーバ１２がアクセスする装置である。例えば、発報手段がメールの場合、アクセス先はメールサーバ４１となる。また、発報手段がＨＭＩ２１による表示の場合、アクセス先は発報対象の制御システム３に含まれるクラウドコントローラ１１となる。また、発報手段がＷｅｂベースＨＭＩ４２による表示の場合、アクセス先はＷｅｂベースＨＭＩ４２となる。

送信内容は、制御クラウドサーバ１２がアクセス先に送信する内容である。送信内容は、アクセス先によって異なる。例えば、アクセス先がメールサーバ４１である場合、送信内容はメールの宛先のメールアドレスとメッセージの内容である。また、アクセス先がクラウドコントローラ１１である場合、送信内容はＨＭＩ２１で表示するためのメッセージである。また、アクセス先がＷｅｂベースＨＭＩ４２である場合、内容はＷｅｂベースＨＭＩ４２で表示するためのメッセージである。なお、図２に示す送信内容は一例であり、これに限定されるものではない。例えば、制御クラウドサーバ１２は、単に変化点の種類を表すコードをクラウドコントローラ１１またはＷｅｂベースＨＭＩ４２に送信し、クラウドコントローラ１１またはＷｅｂベースＨＭＩ４２側で発報メッセージ等を決定してもよい。

例えば、制御システム番号“１”の制御システム３では、当該制御システム３に故障が予測される場合、当該制御システム３に含まれるクラウドコントローラ１１がダウンした場合、および当該制御システム３に含まれる装置で使用されるファームウェアの新しいバージョンがリリースされた場合においては、アクセス先がメールサーバ４１に設定されている。制御システム３に含まれるクラウドコントローラ１１がダウンした場合には、制御クラウドサーバ１２からクラウドコントローラ１１を介してＨＭＩ２１に表示させることができない。このため、制御システム３に含まれるクラウドコントローラ１１がダウンした場合には、ＨＭＩ２１による発報以外の手法が設定される。また、監視対象の種類に応じてメールの送信先アドレスが異なっても良い。例えば、故障予測およびクラウドコントローラ１１のダウンについては制御システム３のオペレータまたは制御システム３の所有者である企業の管理責任者等のメールアドレスが設定されてもよい。また、ファームウェアの更新情報については、制御システム３の導入および保守担当のシステムインテグレータのエンジニアのメールアドレスが設定されてもよい。また、制御システム番号“１”の制御システム３では、制御システム３で異常値が検知された場合、およびエラーが発生した場合には、ＨＭＩ２１による表示が設定されている。

制御クラウドサーバ１２は、制御システム情報により発報ルールテーブル１２２を参照して複数の制御システム３ごとの発報の要否、発報が要の場合のアクセス先、およびアクセス先への送信内容を特定し、特定したアクセス先に、特定した送信内容を送信する。

なお、図２では、１つの変化点につき１つのアクセス先および送信内容が設定されている例を図示したが、発報要否が“要”の場合、少なくとも１つのアクセス先および送信内容が設定されていれば良い。例えば、１つの監視対象に対して、メール、ＨＭＩ２１、およびＷｅｂベースＨＭＩ４２のうちの２つ以上による発報が実行されてもよい。

なお、図２では発報ルールテーブル１２２を１つのテーブルとして図示したが、変更点別の発報の要否と、アクセス先と、送信内容とがそれぞれ異なるテーブルに登録されても良い。

次に、発報の具体例を図３～図５を用いて説明する。図３に示す各発報は、ある制御システム３に含まれる通信モジュール２２が経年劣化による故障が予測される場合の例である。

図３は、本実施形態に係るメールによる発報の一例を示す図である。図３に示すメール４１１は、ある制御システム３に含まれる通信モジュール２２が経年劣化による故障が予測される場合のメールの一例である。例えば、制御クラウドサーバ１２の記憶部１２０に、変化点ごとのメール文面の定型文が保存されており、制御クラウドサーバ１２は、変化点が発生した制御システム３の識別情報および通信モジュール２２の識別情報を、メール文面の定型文に追加して、メールサーバ４１に送信させる。

図４は、本実施形態に係るＨＭＩ２１による発報の一例を示す図である。例えば、制御クラウドサーバ１２は、発報対象の制御システム３に含まれるクラウドコントローラ１１に発報内容を送信し、クラウドコントローラ１１によりＨＭＩ２１のディスプレイ２１１に当該発報内容を表示させる。例えば、制御クラウドサーバ１２の記憶部１２０に、変化点ごとのＨＭＩ２１表示用のメッセージの定型文が保存されており、制御クラウドサーバ１２は、変化点が発生した制御システム３の識別情報および通信モジュール２２の識別情報を、当該定型文に追加することにより、メッセージＭ１を生成する。なお、メッセージＭ１の文面はクラウドコントローラ１１またはＨＭＩ２１が生成しても良い。

図５は、本実施形態に係るＷｅｂベースＨＭＩ４２による発報の一例を示す図である。例えば、制御クラウドサーバ１２は、ＷｅｂベースＨＭＩ４２に制御信号を送信することにより、ＷｅｂベースＨＭＩ４２で提供される画面に発報内容を表示させる。これにより、ＷｅｂベースＨＭＩ４２にアクセスしたＰＣおよびタブレット装置のディスプレイ４２１に、当該発報内容が表示される。例えば、制御クラウドサーバ１２の記憶部１２０に、変化点ごとのＷｅｂベースＨＭＩ４２表示用のメッセージの定型文が保存されており、制御クラウドサーバ１２は、変化点が発生した制御システム３の通信モジュール２２の識別情報を当該定型文に追加することにより、メッセージＭ２を生成する。なお、メッセージＭ２の文面はＷｅｂベースＨＭＩ４２が生成しても良い。

次に、以上のように構成された、制御クラウドサーバ１２で実行される処理の流れについて説明する。

図６は、本実施形態に係る基準情報生成処理の流れの一例を示すフローチャートである。

まず、制御クラウドサーバ１２は、各クラウドコントローラ１１ａ～１１ｂから、制御システム情報１２１を取得する（Ｓ１）。

そして、制御クラウドサーバ１２は、取得した制御システム情報１２１から基準情報１２３を生成する（Ｓ２）。

なお、基準情報１２３は、複数回にわたって取得された制御システム情報１２１から生成されてもよい。例えば、制御クラウドサーバ１２は、ＡＩ技術により、制御システム３ごとに、制御システム３が問題なく動作している状況における過去の制御システム情報を学習することにより、基準となる制御システム情報のパターンを特定することにより、各制御システム３におけるセンサ等の「異常値」を判定するための基準を決定し、基準情報１２３に登録する。なお、基準情報１２３のうち、ファームウェアの更新情報など、制御システム情報１２１から生成されない情報については、空欄のままとしてよい。

図７は、本実施形態に係る変化点の検知処理の流れの一例を示すフローチャートである。

まず、制御クラウドサーバ１２は、各クラウドコントローラ１１ａ～１１ｂから、制御システム３ごとの制御システム情報１２１を取得する（Ｓ１０１）。制御クラウドサーバ１２は、取得した制御システム情報１２１を記憶部１２０に保存する。

そして、制御クラウドサーバ１２は、取得した制御システム３ごとの制御システム情報１２１を、制御システム３ごとの基準情報１２３と比較する。制御システム情報１２１がいずれかの基準情報１２３と一致しない制御システム３が存在する場合（Ｓ１０２“有”）、発報ルールテーブル１２２を参照して、対象の制御システム３における制御システム情報１２１と一致しない基準情報１２３に関する変化点の種別に対応する発報要否を特定する（Ｓ１０３）。

発報ルールテーブル１２２において、該当の変化点の発報ルールにおいて発報要否が“要”になっている場合（Ｓ１０４“要”）、制御クラウドサーバ１２は、発報ルールテーブル１２２から、対象の制御システム３におけるアクセス先を検索する（Ｓ１０５）。

発報ルールテーブル１２２に登録されたアクセス先が“クラウドコントローラ”である場合（Ｓ１０６“クラウドコントローラ”）、制御クラウドサーバ１２は、発報対象の制御システム３に含まれるクラウドコントローラ１１に発報ルールテーブル１２２に登録されたＨＭＩ表示用メッセージを送付することにより、ＨＭＩ２１に発報させる（Ｓ１０７）。

発報ルールテーブル１２２に登録されたアクセス先が“メールサーバ”である場合（Ｓ１０６“メールサーバ”）、制御クラウドサーバ１２は、発報ルールテーブル１２２に登録された宛先メールアドレスおよびメッセージをメールサーバ４１に送付することにより、当該メールアドレス宛にメールを送信させる（Ｓ１０８）。

発報ルールテーブル１２２に登録されたアクセス先が“ＷｅｂベースＨＭＩ”である場合（Ｓ１０６“ＷｅｂベースＨＭＩ”）、制御クラウドサーバ１２は、発報ルールテーブル１２２に登録された表示用メッセージをＷｅｂベースＨＭＩ４２に送付することにより、ＷｅｂベースＨＭＩ４２に発報させる（Ｓ１０９）。

また、制御システム情報１２１がいずれかの基準情報１２３と一致しない制御システム３が存在しない場合（Ｓ１０２“無”）、制御クラウドサーバ１２は、発報をしない（Ｓ１１０）。また、発報ルールテーブル１２２において、対象の制御システム３における発報要否が“否”になっている場合にも（Ｓ１０４“否”）、制御クラウドサーバ１２は、発報をしない。

次に、本実施形態に係る故障予測の発報の処理の流れについて説明する。

図８は、本実施形態に係る故障予測の発報の処理の流れの一例を示すフローチャートである。

まず、制御クラウドサーバ１２は、各クラウドコントローラ１１ａ～１１ｂから、制御システム３ごとの制御システム情報１２１を取得する（Ｓ１２１）。制御クラウドサーバ１２は、取得した制御システム情報１２１を記憶部１２０に保存する。

そして、制御クラウドサーバ１２は、取得したシステム情報１２１に故障情報が含まれる場合（Ｓ１２２“Ｙｅｓ”）、「故障情報に含まれる故障が発生した機器（例えば通信モジュール２２）の型番と同じ型番かつ当該故障が発生した機器の使用期間と規定の閾値以下の範囲の使用期間の機器を含まないこと」を、各制御システム３の基準情報１２３に追加する（Ｓ１２３）。

当該故障情報は、例えば、通信モジュール２２が経年劣化に伴い故障したことを示す情報とする。具体的には、故障情報は、故障した通信モジュール２２が含まれる制御システム３の識別情報、故障した通信モジュール２２の型番および経過年数を含む。なお、いずれの制御システム３においても故障が発生していない場合には、システム情報１２１には故障情報が含まれない。

そして、制御クラウドサーバ１２は、Ｓ１２３で追加した基準情報１２３と、各制御システム３の制御システム情報１２１とを比較する。制御システム情報１２１がＳ１２３で追加した基準情報１２３と一致しない制御システム３がある場合（Ｓ１２４“有”）、制御クラウドサーバ１２は、発報ルールテーブル１２２から、当該制御システム３における故障予測の発報要否を検索する（Ｓ１２５）。

発報ルールテーブル１２２において、当該制御システム３における故障予測の発報要否が“要”になっている場合（Ｓ１２６“要”）、制御クラウドサーバ１２は、発報ルールテーブル１２２から、対象の機器を含む制御システム３における故障予測のアクセス先を検索する（Ｓ１２７）。

発報ルールテーブル１２２に登録されたアクセス先が“クラウドコントローラ”である場合（Ｓ１２８“クラウドコントローラ”）、制御クラウドサーバ１２は、発報対象の制御システム３に含まれるクラウドコントローラ１１に発報ルールテーブル１２２に登録されたＨＭＩ表示用メッセージを送付することにより、ＨＭＩ２１に故障予測について表示させる（Ｓ１２９）。

発報ルールテーブル１２２に登録されたアクセス先が“メールサーバ”である場合（Ｓ１２８“メールサーバ”）、制御クラウドサーバ１２は、発報ルールテーブル１２２に登録された宛先メールアドレスおよびメッセージをメールサーバ４１に送付することにより、当該メールアドレス宛に故障予測についてのメールを送信させる（Ｓ１３０）。

発報ルールテーブル１２２に登録されたアクセス先が“ＷｅｂベースＨＭＩ”である場合（Ｓ１２８“ＷｅｂベースＨＭＩ”）、制御クラウドサーバ１２は、発報ルールテーブル１２２に登録された表示用メッセージをＷｅｂベースＨＭＩ４２に送付することにより、ＷｅｂベースＨＭＩ４２で提供される画面に故障予測についての情報を表示させる（Ｓ１３１）。

また、いずれの制御システム３の制御システム情報１２１も、Ｓ１２３で追加した基準情報１２３と一致する場合（Ｓ１２４“無”）、制御クラウドサーバ１２は、発報をしない（Ｓ１３２）。また、発報ルールテーブル１２２において、当該制御システム３における故障予測の発報要否が“否”になっている場合にも（Ｓ１２６“否”）、制御クラウドサーバ１２は、発報をしない。

ここで、このフローチャートの処理は終了する。

なお、図８では、故障情報は制御システム情報１２１に含まれるものとしたが、故障情報は、故障診断モジュール２５から制御クラウドサーバ１２に送信されてもよい。あるいは、制御システム３のオペレータまたは品質管理担当者が、通信モジュール２２が経年劣化に伴い故障したことを示す故障情報を、制御クラウドサーバ１２に入力しても良い。

次に、更新情報の発報の場合に、制御クラウドサーバ１２で実行される処理の流れについて説明する。

図９は、本実施形態に係る更新情報の発報の処理の流れの一例を示すフローチャートである。

まず、制御クラウドサーバ１２は、ユーザによるファームウェアの新たなバージョンの入力を受け付ける（Ｓ１４１）。制御クラウドサーバ１２のユーザは、例えば、制御クラウドサーバ１２およびクラウドコントローラ１１の開発運用会社の技術担当者等である。具体的には、制御システム３ａ～３ｎのうちのいずれかに含まれる機器のファームウェアの新しいバージョンがリリースされた場合、制御クラウドサーバ１２およびクラウドコントローラ１１の開発運用会社の技術担当者等が、制御クラウドサーバ１２へファームウェアが更新される機器の型番およびファームウェアの最新バージョン等のモジュール情報を制御クラウドサーバ１２に入力する。

この場合、制御クラウドサーバ１２は、入力されたファームウェアの新たなバージョンを、各制御システムの基準情報１２３に追加する（Ｓ１４２）。これにより、入力されたファームウェアの新たなバージョンが、複数の制御システム３の各々の標準の状態として規定される。

そして、制御クラウドサーバ１２は、記憶部１２０に保存された制御システム情報１２１を参照し、制御システム情報１２１と、Ｓ１４２で追加した基準情報１２３とを比較する。例えば、制御クラウドサーバ１２は、制御システム情報１２１に登録された制御システム情報１２１に含まれる機器のうち、ファームウェアのバージョンが基準情報１２３に登録された最新バージョンと異なる機器がある場合（Ｓ１４３“有”）、制御クラウドサーバ１２は、発報ルールテーブル１２２から、当該機器を含む制御システム３におけるファームウェアの更新情報の発報要否を検索する（Ｓ１４４）。以下、ファームウェアのバージョンが基準情報１２３に登録された最新バージョンと異なる機器を、更新対象の機器という。

発報ルールテーブル１２２において、当該制御システム３におけるファームウェアの更新情報の発報要否が“要”になっている場合（Ｓ１４５“要”）、制御クラウドサーバ１２は、発報ルールテーブル１２２から、更新対象の機器を含む制御システム３におけるファームウェアの更新情報のアクセス先を検索する（Ｓ１４６）。Ｓ１４７～Ｓ１５０の発報の処理は、図７で説明したＳ１０６～Ｓ１０９の処理と同様である。

また、更新対象の機器がない場合（Ｓ１４３“無”）、制御クラウドサーバ１２は、発報をしない（Ｓ１５１）。また、発報ルールテーブル１２２において、当該制御システム３におけるファームウェアの更新情報の発報要否が“否”になっている場合にも（Ｓ１４５“否”）、制御クラウドサーバ１２は、発報をしない。

ここで、このフローチャートの処理は終了する。

次に、故障診断モジュール２５と制御クラウドサーバ１２との関係について図１０～図１２を用いて説明する。

図１０は、本実施形態における通常運用時の制御クラウドサーバ１２とローカルＩ／Ｏシステム２ａとの通信の一例を示す図である。図１０においては、ローカルＩ／Ｏシステム２ａで故障が発生しておらず、かつローカルＩ／Ｏシステム２ａとクラウド環境１との間のインターネット５の通信が途絶していない。この場合、クラウドコントローラ１１ａとローカルＩ／Ｏシステム２ａの通信モジュール２２ａとがインターネット５を介してデータの送受信をする。

具体的には、クラウドコントローラ１１ａは、ＰＯＵを実行することによりリモートＩ／Ｏ２３１ａ，２３２ａへの制御信号を、インターネット５を介して通信モジュール２２ａに送信する。また、通信モジュール２２ａは、リモートＩ／Ｏ２３１ａ，２３２ａに入力されたセンサデータを、インターネット５を介してクラウドコントローラ１１ａに送信する。

ここで、仮に、ローカルＩ／Ｏシステム２ａで故障が発生、または、ローカルＩ／Ｏシステム２ａとクラウド環境１との間のインターネット５の通信が途絶したとする。

図１１は、本実施形態における非通常運用時の制御クラウドサーバ１２とローカルＩ／Ｏシステム２ａとの通信の一例を示す図である。図１１に示す例では、制御クラウドサーバ１２とローカルＩ／Ｏシステム２ａとの通信が途絶し、かつ、ローカルＩ／Ｏシステム２ａで故障が発生している。

この場合、クラウドコントローラ１１ａと通信モジュール２２ａとの間の制御信号とセンサデータの送受信ができないため、クラウドコントローラ１１ａ側ではローカルＩ／Ｏシステム２ａの故障が検知されない。

この場合、故障診断モジュール２５ａは、通信モジュール２２ａを介さずに、制御クラウドサーバ１２に故障情報を送信する。故障診断モジュール２５ａは、電話回線（不図示）により制御クラウドサーバ１２と通信しても良い。

この場合、制御クラウドサーバ１２は、故障診断モジュール２５ａから取得した故障情報と、クラウドコントローラ１１ａから取得した制御システム情報とを比較する。クラウドコントローラ１１ａ側ではローカルＩ／Ｏシステム２ａの故障が検知されていないため、クラウドコントローラ１１ａから故障情報は送信されない。このため、制御クラウドサーバ１２が故障診断モジュール２５ａから取得した故障情報とクラウドコントローラ１１ａから取得した制御システム情報とに差異が生じる。

この場合、制御クラウドサーバ１２は、クラウドコントローラ１１ａをダウンさせる制御信号を送信することで、制御システム３ａを停止させる。また、制御クラウドサーバ１２とローカルＩ／Ｏシステム２ａとの通信が途絶していることにより、クラウドコントローラ１１ａがダウンしてもローカルＩ／Ｏシステム２ａ側が停止しない場合には、制御クラウドサーバ１２は、故障診断モジュール２５ａに、ローカルＩ／Ｏシステム２ａを停止させる制御信号を送信する。この場合、故障診断モジュール２５ａは、リモートＩ／Ｏ２３１ａ，２３２ａを制御してローカルＩ／Ｏシステム２ａを停止させる。

ここで、ローカルＩ／Ｏシステム２ａで発生するエラーについて、図１２を用いて説明する。

図１２は、本実施形態に係るリモートＩ／Ｏ２３ａに入力されたセンサデータの値を時系列に示すグラフの一例である。センサデータは例えばアナログ値とするが、これに限定されない。

図１２では、説明のため、エラーの基準を単純化して説明する。例えば、クラウドコントローラ１１ａおよび故障診断モジュール２５ａは、リモートＩ／Ｏ２３ａが１０ｍｓごとに入力するセンサデータが１００回連続で上限値（Ｂ）を超えた場合にエラー（故障）と判定するものとする。

ここで、時刻ｔ０～ｔ１の間、クラウドコントローラ１１ａと通信モジュール２２ａとの間の通信が途絶したとする。クラウドコントローラ１１ａと通信モジュール２２ａとの間の通信が途絶した場合、途絶中にセンサデータが上限値（Ｂ）を超えたとしてもクラウドコントローラ１１ａへ異常値は伝達されない。

例えば、時刻ｔ０～ｔ１の間、１．５秒にわたってセンサデータが上限値（Ｂ）を超えたとする。この場合、センサデータは１５０回連続で上限値（Ｂ）を超える。故障診断モジュール２５ａはローカルＩ／Ｏシステム２ａに含まれるため、クラウドコントローラ１１ａと通信モジュール２２ａの通信が途絶していても、センサデータの収集を継続する。このため、故障診断モジュール２５ａは、センサデータが上限値（Ｂ）を１００回連続で超えた時点、つまりセンサデータが上限値（Ｂ）を最初に超えてから１秒経過時点でエラーを検知する。この場合、故障診断モジュール２５ａは、検知したエラーを示す故障情報を、クラウドコントローラ１１ａに送信する。

また、時刻ｔ１の時点でクラウドコントローラ１１ａと通信モジュール２２ａとの間の通信が復帰しても、既にセンサデータは上限値（Ｂ）以下となっているため、通信の復帰後も、クラウドコントローラ１１ａはエラーを検知しない。このような場合に、故障診断モジュール２５ａからクラウドコントローラ１１ａに送信される故障情報と、クラウドコントローラ１１ａからクラウドコントローラ１１ａに送信される制御システム情報とに不一致が生じる。

なお、故障情報の不一致が発生する状況は、上述の例に限定されるものではない。例えば、クラウドコントローラ１１ａと故障診断モジュール２５ａの両方が制御クラウドサーバ１２に故障情報を送信した場合において、クラウドコントローラ１１ａが送信した故障情報の内容と故障診断モジュール２５ａが送信した故障情報の内容とに差異がある場合もある。この場合、制御クラウドサーバ１２は、クラウドコントローラ１１ａに対してクラウドコントローラ１１ａをダウンさせる制御信号を送信する。

このように、本実施形態の制御クラウドサーバ１２は、複数のクラウドコントローラ１１ａ～１１ｎから、複数の制御システム３ａ～３ｎの構成および運転状態に関する制御システム情報１２１を取得し、取得した御システム情報１２１に基づいて複数の制御システム３ａ～３ｎごとの基準情報１２３を生成し、取得された複数のクラウドコントローラ１１ａ～１１ｎから収集された制御システム情報１２１と基準情報１２３とを比較して変化点がある場合に、発報ルールテーブル１２２に登録された発報手法により制御システム情報１２１ごとの発報先へ発報する。このため、本実施形態の制御クラウドサーバ１２によれば、クラウド環境１に設けられた制御クラウドサーバ１２で複数のクラウドコントローラ１１ａ～１１ｎの制御システム情報を集中管理して発報を行うことにより、制御システム３内で得られた情報を制御システム３への関係者への発報のために有効活用することができる。

例えば、従来、制御システムの制御対象のプラントのローカル環境はクローズドであることが一般的であったため、ローカル環境に設けられたコントローラ自体に不具合が生じた場合、制御システムのシステム情報の解析および管理することが困難になる可能性があった。これに対して、本実施形態の制御クラウドサーバ１２はクラウド環境１において複数のクラウドコントローラ１１ａ～１１ｎの制御システム情報を集中管理するため、ＢＣＰ（Business Continuity Planning）対策に寄与することができる。

また制御システムの制御対象のプラントのローカル環境がクローズドである場合、制御システムに含まれている機器のファームウェアのメーカー側がリリースしたファームウェアの更新情報を、制御システムのオペレータ、および当該制御システムの開発および保守を担当するシステムインテグレータのエンジニアが把握するために手間がかかる場合があった。これに対して、本実施形態の制御クラウドサーバ１２はクラウド環境１においてファームウェアの更新情報も管理するため、オペレータ、およびエンジニアが容易にファームウェアの更新情報を把握することができる。

また、本実施形態の制御クラウドサーバ１２と同様の機能サーバを個別のプラントのローカル環境に物理的に設置する場合と比較して、初期導入および更新のコストの低減に寄与する。

また、本実施形態の制御クラウドサーバ１２は、複数の制御システム３ａ～３ｎのうちのいずれかで故障が発生した場合に、他の制御システム３の故障の発生を予測し、故障の発生が予測される制御システム３のオペレータまたはエンジニア等へ発報する。このため、本実施形態の制御クラウドサーバ１２によれば、複数の制御システム３ａ～３ｎの情報を制御クラウドサーバ１２で一括管理することにより、ある制御システム３で発生した故障の情報を、他の制御システム３の故障予測の情報提供に活用することができる。

また、本実施形態の制御クラウドサーバ１２は、故障診断モジュール２５から取得した故障情報と、当該故障診断モジュール２５と同じ制御システム３に含まれるクラウドコントローラ１１から取得した制御システム情報に含まれる故障情報とが不一致の場合であって、当該クラウドコントローラ１１がダウンしていない場合、当該クラウドコントローラ１１に、制御信号を送信してダウンさせる。このため、本実施形態の制御クラウドサーバ１２によれば、不具合が発生している可能性のある状態でクラウドコントローラ１１が動作を継続することを低減することができる。また、本実施形態の制御クラウドサーバ１２は、故障情報を、故障診断モジュール２５とクラウドコントローラ１１の両方から取得することにより、故障情報の信頼性を向上させることができる。

なお、本実施形態においては、制御システム３に含まれている機器のファームウェアの新しいバージョンがリリースされた場合、制御クラウドサーバ１２が発報するものとしたが、ファームウェアの新しいバージョンがリリースされた場合の処理はこれに限定されない。例えば、制御システム３に含まれている機器のファームウェアの新しいバージョンがリリースされた場合、制御クラウドサーバ１２がクラウドコントローラ１１に発報し、クラウドコントローラ１１が当該ファームウェアの新しいバージョンを対象の機器に自動更新しても良い。

本実施形態の制御クラウドサーバ１２で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、本実施形態の制御クラウドサーバ１２で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の制御クラウドサーバ１２で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。
また、本実施形態の制御クラウドサーバ１２で実行されるプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

本実施形態の制御クラウドサーバ１２で実行されるプログラムは、上述した各処理を実行可能なジュール構成となっている。各処理の例としては、取得ステップ、発報ステップ、検索ステップ、比較ステップ、および出力ステップが挙げられる。実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体から本実施形態の制御クラウドサーバ１２で実行されるプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、各処理を実行可能なジュールが主記憶装置上に生成されるようになっている。

本発明の実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ クラウド環境
２，２ａ～２ｎ ローカルＩ／Ｏシステム
３，３ａ～３ｎ 制御システム
５ インターネット
１０ 制御クラウドサービス
１１，１１ａ～１１ｎ クラウドコントローラ
２２，２２ａ～２２ｎ 通信モジュール
２５，２５ａ～２５ｎ 故障診断モジュール
４１ メールサーバ
１２０ 記憶部
１２１ 制御システム情報
１２２ 発報ルールテーブル
１２３ 基準情報
２１１ ディスプレイ
４１１ メール
４２１ ディスプレイ
２３，２３１ａ，２３２ａ，２３１ｎ，２３２ｎ リモートＩ／Ｏ
Ｍ１，Ｍ２ メッセージ
ＰＯＵ 当該
Ｓ 管理システム

Claims (5)

1. クラウドコントローラと前記クラウドコントローラのコントロール対象機器とで構成される複数の制御システムごとの発報ルールとが登録された発報ルールテーブルを記憶し、
   複数の制御システムの各々に含まれる複数のクラウドコントローラから、前記複数の制御システムごとの構成および運転状態に関する制御システム情報を取得し、
   前記制御システム情報により前記発報ルールテーブルを参照して前記複数の制御システムごとの発報の要否、発報が要の場合のアクセス先、および前記アクセス先への送信内容を特定し、特定した前記アクセス先に、前記送信内容を送信する、
   制御クラウドサーバ。
2. 前記制御システム情報から前記複数の制御システムの各々の標準の状態を規定する基準情報を生成し、
   新たに取得した前記制御システム情報と前記基準情報を比較して新たに取得した前記制御システム情報に変化点がある場合、前記発報ルールテーブルを参照して前記変化点がある前記制御システム情報に対応する前記制御システムに対応付けられたアクセス先、および前記アクセス先への送信内容を特定し、特定した前記アクセス先に、前記送信内容を送信する、
   請求項１に記載の制御クラウドサーバ。
3. 前記制御システム情報は、少なくとも、前記複数の制御システムに含まれる機器の構成、前記機器の使用期間、および前記機器の故障に関する故障情報を含み、
   前記制御システム情報に故障情報が記録されている場合、当該故障情報に含まれる故障が発生した機器の型番と使用期間から、当該型番と同じ型番かつ当該使用期間と規定の閾値以下の範囲の使用期間の機器を含まないことを定義する前記複数の制御システムの各々の前記基準情報を生成し、
   前記複数の制御システムのうち、前記基準情報と一致しない制御システムが存在する場合、前記発報ルールテーブルを参照して当該制御システムに対応付けられた前記アクセス先に、前記送信内容を送信する、
   請求項２に記載の制御クラウドサーバ。
4. 前記制御システム情報は、少なくとも、前記複数の制御システムに含まれる機器のファームウェアのバージョンを含み、
   前記ファームウェアの新たなバージョンの入力を受け付け、
   前記発報ルールテーブルを参照して、前記制御システム情報に含まれる前記機器のファームウェアのバージョンが入力された前記新たなバージョンと一致しない制御システムに対応付けられた前記アクセス先に、当該制御システムに対応付けられた前記送信内容を送信する、
   請求項１から３のいずれか１項に記載の制御クラウドサーバ。
5. 前記複数の制御システムの各々は、前記複数の制御システムに故障が発生した場合に前記制御クラウドサーバに故障情報を送信する、前記クラウド環境外に設けられた故障診断モジュールを含み、
   前記複数の制御システムのいずれかに含まれる前記故障診断モジュールから故障情報を取得した場合であって、当該故障診断モジュールと同じ制御システムに含まれるクラウドコントローラから取得した制御情報に故障情報が含まれていない、または当該故障診断モジュールと同じ制御システムに含まれるクラウドコントローラから取得した制御情報に含まれる故障情報と前記故障診断モジュールから取得した故障情報とに差異がある場合、
   当該故障診断モジュールと同じ制御システムに含まれるクラウドコントローラに対して、当該クラウドコントローラをダウンさせる制御信号を出力し、
   前記発報ルールテーブルを参照して当該クラウドコントローラを含む前記制御システムに対応付けられた発報手法および発報先を特定し、
   特定した発報手法により、特定した発報先へ発報する、
   請求項１から４のいずれか１項に記載の制御クラウドサーバ。

Images