JP2017004573A - インフラ制御システム、サーバ、制御方法およびプログラム - Google Patents

Abstract

【課題】 インフラ制御システムを提供すること。【解決手段】 インフラ制御システムは、複数の第１サーバと、第２サーバとを具備する。第１サーバは、地域に応じて設けられ、センサで検知した地域のインフラに関するイベント情報に基づいてインフラを制御する。第２サーバは、第１サーバから受信したイベント情報より、第１サーバでの制御に係るデータを生成する。そして第１サーバは、イベント情報に基づく地域に応じたインフラ制御を独自に行いつつ、第２サーバから受信したデータに基づく制御を行う。【選択図】 図３

Description

本発明の実施形態は、インフラを制御するインフラ制御システムに関する。

人々が生活する社会（コミュニティ）は、例えば電力、水道、交通、鉄道、通信、およびビルなどの多様なインフラによって支えられている。

従来の社会システムでは、インフラは基本的に個々に独立して管理、運営されていた。例えば電力インフラを例に挙げてみても、国単位はもとより、自治体（市町村）ごと、地域ごと、あるいは戸別家庭ごとの最適化制御は未だ実現されていない。
そこで、目的は、インフラ制御システム、サーバ、制御方法およびプログラムを提供することにある。

インフラ制御システムは、複数の第１サーバと、第２サーバとを具備する。第１サーバは、地域に応じて設けられ、センサで検知した地域のインフラに関するイベント情報に基づいてインフラを制御する。第２サーバは、第１サーバから受信したイベント情報より、第１サーバでの制御に係るデータを生成する。そして第１サーバは、イベント情報に基づく地域に応じたインフラ制御を独自に行いつつ、第２サーバから受信したデータに基づく制御を行う。

図１は、実施形態に係わるシステムの一例を示す図である。 図２は、第１の実施形態に係る社会インフラ制御システムの一例を示す概念図である。 図３は、第１の実施形態に係る社会インフラ制御システムの一例を示す機能ブロック図である。 図４は、センサと社会インフラとの関係を示す模式図である。 図５は、センサ５０ａにより検知されるイベント情報の一例を示す図である。 図６は、国クラウド１００のデータベース２０に蓄積される、イベント情報２０ａの一例を示す図である。 図７は、最適化されたイベント情報の一例を示す図である。 図８は、最適化されたイベント情報の他の例を示す図である。 図９は、クラウドにおける自律制御について模式的に示す図である。 図１０は、第１の実施形態における情報およびデータの流れを模式的に示す図である。 図１１は、第２の実施形態に係る社会インフラ制御システムの一例を示す概念図である。 図１２は、図１１に示されるシステムの要部を模式的に示す図である。 図１３は、第２の実施形態に係る社会インフラ制御システムを示す図である。 図１４は、事業者ＭＳ１からベンダＭＳ１に通信網ＮＷの回線を介して送信されるイベント情報の一例を示す図である。 図１５は、第３の実施形態に係る社会インフラ制御システムの一例を示す図である。 図１６は、図１５に示されるアルゴリズムライブラリ９０ｂの一例を示す図である。 図１７は、図１５に示されるベンダＭＳ８０の一例を示す機能ブロック図である。 図１８は、第３の実施形態におけるベンダＭＳ８０の処理手順の一例を示すフローチャートである。

図１は、実施形態に係わるシステムの一例を示す図である。図１は、いわゆるスマートグリッドとして知られるシステムの一例を示す。既存の電力網（grid）では原子力、火力、水力などの既存発電所と、一般家庭や、ビル、工場といった多種多様な需要家とが電力網によって接続される。次世代の電力系統（Power grid）ではこれらに加えて太陽光発電（Photovoltaic Power Generation：ＰＶ）システムや風力発電装置などの分散型電源や蓄電装置、新交通システムや充電スタンドなどが電力系統に接続される。これら多種多様な要素は通信グリッドを介して通信することが可能である。

エネルギーを管理するシステムは、エネルギーマネジメントシステム（Energy Management System：ＥＭＳ）と総称される。ＥＭＳはその規模などに応じて幾つかに分類される。例えば一般家庭向けのＨＥＭＳ（Home Energy Management System）、ビルディング向けのＢＥＭＳ（Building Energy Management System）などがある。このほか、集合住宅向けのＭＥＭＳ（Mansion Energy Management System）、コミュニティ向けのＣＥＭＳ（Community Energy Management System）、工場向けのＦＥＭＳ（Factory Energy Management System）などがある。これらのシステムが連携することできめ細かなエネルギー最適化制御が実現される。

これらのシステムによれば既存の発電所、分散型電源、太陽光や風力などの再生可能エネルギー源、および需要家の相互間で高度な協調運用が可能になる。これにより自然エネルギーを主体とするエネルギー供給システムや、需要家と事業者との双方向連携による需要家参加型のエネルギー需給といった、新規かつスマートな形態の電力供給サービスが生み出される。

社会システムは、上記スマートグリッドに代表される社会インフラにより社会生活に快適さや便利さを提供する。これからの社会システムは情報処理技術や通信技術などを利用して、多種多様な社会インフラを有機的に結合させることで、省エネルギー化などの社会的な目標を達成できるようにすることを求められている。以下ではこのような課題を解決可能な実施形態に係る社会インフラ制御システムにつき、説明する。

［第１の実施形態］
図２は、第１の実施形態に係る社会インフラ制御システムの一例を示す概念図である。実施形態では社会インフラ制御システムを、論理的な階層構造に形成する。図２においては上位層、および下位層に加え、上位層よりも下位、下位層よりも上位の中位層を備える形態を示す。階層化の段階は３に限られるものではなく、中位層をさらに多層化したアーキテクチャも実現可能である。逆に、上位層および下位層だけを備える社会インフラ制御システムも形成することが可能である。図２においては上位層を国、中位層を都道府県、下位層を市町村の、階層的な行政区分に対応させて示す。

実施形態では、各層をクラウド化した形態を考える。周知のようにクラウドコンピューティングシステムはコンピュータ（２）とデータベース（ＤＢ）とを備える。コンピュータ２は単体でも複数でも良い。データベースは一つのコンピュータ２に備えられても、複数のコンピュータ２に分散して配置されてもよい。

図２において、下位層には、社会インフラを備え、地域に対応して設けられるローカルシステムがある。例えばＡ市、Ｂ市、Ｈ町、Ｉ郡の地域ごとにクラウドが形成され、クラウドごとにコンピュータ２とデータベースＤＢが備えられる。各地域クラウドは通信網ＮＷの回線を介して接続され、層内において相互の連携を保っている。

中位層にあるクラウドコンピュータは、論理的な上位層として下位層にあるクラウドコンピュータを制御する。例えばＡ市とＢ市のクラウドコンピュータはＸ県のクラウドコンピュータにより制御され、Ｈ町とＩ郡のクラウドコンピュータはＹ県のクラウドコンピュータにより制御される。Ｘ県およびＹ県もクラウド化され、それぞれコンピュータ２およびデータベースＤＢを備える。Ｘ県のクラウドコンピュータおよびＹ県のクラウドコンピュータも通信網ＮＷの回線を介して接続され相互の連携を保っている。

上位層にあるクラウドコンピュータは、論理的な上位層として中位層にあるクラウドコンピュータを制御する。例えばＸ県とＹ県のクラウドコンピュータは国のクラウドコンピュータにより制御される。国のコンピュータもクラウド化される。さらに、上位層には他の国にあるクラウドコンピュータと位置づけることができ、これら複数の国は通信網ＮＷの回線により互いに相互の連携を保つことが可能である。上位層のクラウドに符号１００を付して国クラウド１００と表記する。中位層のクラウドに符号２００を付して県クラウド２００と表記する。下位層のクラウドに符号３００を付して市クラウド３００と表記する。

国クラウド１００、県クラウド２００、市クラウド３００のいずれも社会インフラを有することが可能である。例えば市クラウド３００の社会インフラを国クラウド１００または県クラウド２００から制御する形態を考えると、市クラウド３００をローカルシステム、国クラウド１００または県クラウド２００を上位制御システムと捉えることが可能である。また、県クラウド２００の社会インフラを国クラウド１００から制御する形態を考えると、県クラウド２００をローカルシステム、国クラウド１００を上位制御システムと捉えることが可能である。図２は、ローカルシステムが複数の階層に階層化される形態の一例を示す。

図３は、第１の実施形態に係る社会インフラ制御システムの一例を示す機能ブロック図である。国クラウド１００は国レベル管理システム１０と、データベース２０を備える。県クラウド２００は都道府県レベル管理システム６０と、データベース７０を備える。市クラウド３００は、市町村レベル管理システム３０と、データベース４０と、複数の社会インフラ５１〜５ｎを備える。

煩雑を避けるため以下では、管理システムをＭＳ（Management System）と表記する。国レベル管理システム１０を国ＭＳ１０と表記する。都道府県レベル管理システム６０を県ＭＳ６０と表記する。市町村レベル管理システム３０を市ＭＳ３０と表記する。管理システムＭＳは、実施形態におけるサーバとして位置付けられる。管理システムＭＳは、ハードウェアとしてのコンピュータを備える。コンピュータは単体でも複数でも良い。

社会インフラ５１〜５ｎは、例えば水道網、冷熱源プラントシステム、電力網、交通網、医療システム、店舗ネットワーク、ビルディング（ビル）システム、家庭（ホーム）エネルギーマネジメントシステム、工場システム、コンテンツ配信システム、あるいは鉄道網などである。なお社会インフラはこれらに限られるものではない。例えば複数の社会インフラを含むショッピングモールやコミュニティなども社会インフラとして理解することが可能である。

国クラウド１００、県クラウド２００、および市クラウド３００は通信網ＮＷの回線を介して相互に接続される。通信網ＮＷは、要求される通信帯域（通信容量）を保証可能なギャランティ型ネットワークである。この種のネットワークとしては例えば光通信技術を応用した専用回線が挙げられる。あるいはＩＰ（Internet Protocol）ネットワークに形成したＶＰＮ（Virtual Private Network）もこの種のネットワークの範疇に含めることが可能である。もちろん、通信網ＮＷの回線を社会インフラに含めることも可能である。

第１の実施形態において通信網ＮＷの回線は、少なくとも下位層から上位層へのイベント情報のアップロードにかかるリアルタイム性と、上位層から下位層へのデータの取得にかかるリアルタイム性とを保証可能とする。

イベントとは、各社会インフラ５１〜５ｎの短期的又は長期的な状態変化や、状態そのものを意味する。また、イベント情報とは、各社会インフラ５１〜５ｎに備わるセンサ５０ａにより検知され、このセンサ５０ａから出力される信号又はこの信号に基づき作成される全ての情報を示す。

市クラウド３００の社会インフラ５１〜５ｎは、それぞれセンサ５０ａおよびアクチュエータ５０ｂを備える。センサ５０ａは、例えば各社会インフラに固有のイベントを検知する。あるいは、センサ５０ａは、複数の社会インフラに関係するイベントを検知する。

図４は、センサと社会インフラとの関係を示す模式図である。例えばセンサ５０ａ−１は電力網に固有のイベントを検知するセンサであり、例えば各家庭における電力消費量を計測する電力量計（スマートメータ）がその一例として挙げられる。またセンサ５０ａ−２は電力網と鉄道網とに関係するイベントを検知するセンサであり、例えばパンタグラフの電圧計などが考えられるであろう。このほか、電力網、水道網、交通網に関係するイベントを取得するセンサ５０ａ−３、あるいは電力網、水道網、交通網、および鉄道網の全てに関係するイベントを取得するセンサ５０ａ−４を考えることもできる。要するにセンサ５０ａは社会インフラの状態を検知してイベント情報として数値化、あるいはデータ化可能な手段であればどのようなものでも良く、監視カメラや、気象情報を取得する気象レーダなどもその範疇に含めることが可能である。

図３に戻り、アクチュエータ５０ｂは与えられる制御信号に基づいて制御対象を制御する。アクチュエータ５０ｂは例えば水道インフラの浄水場システムに備わるバルブを開閉するモータである。アクチュエータ５０ｂは、バルブの開度を指示する制御信号に基づいてモータを駆動して、バルブの開度および水の流量を制御する。

市ＭＳ３０は、機能オブジェクトとしてアップロード部３０ａ、取得部３０ｂ、および制御部３０ｃを備える。
アップロード部３０ａは、センサ５０ａにより検知されたイベント情報を、国クラウド１００の国ＭＳ１０、および県クラウド２００の県ＭＳ６０に、通信網ＮＷの回線を介してアップロードする。ここで、回線は公衆回線でも専用線でも良く、イベント情報に係る信号が伝送可能な線路（信号線）であれば良い。

取得部３０ｂは、社会インフラ５１〜５ｎの制御に要する制御データを国ＭＳ１０、または県ＭＳ６０から取得する。

制御部３０ｃは、取得部３０ｂにて取得した制御データに基づいてアクチュエータ５０ｂに制御指示を与える。または、制御部３０ｃは、センサ５０ａにより検知したイベント情報に応じてアクチュエータ５０ｂに制御指示を与える。つまり、制御部３０ｃは、上位層から取得された制御データ、またはローカルで取得されたイベント情報のいずれかに基づいて、社会インフラ５１〜５ｎを制御する。

制御部３０ｃは、ローカルで取得されたイベント情報に基づく制御よりも、上位層から取得された制御データに基づく制御を優先する。このように、上位システムからの制御の優先度を高くすることで、システム全体の最適性を優先的に確保することができる。

通信網ＮＷの回線に障害が生じるなどして国ＭＳ１０、あるいは県ＭＳ６０との通信に障害が生じた場合は、制御部３０ｃは、自ら収集したイベント情報４０ａのみに基づいて社会インフラ５１〜５ｎを制御する。

データベース４０は、イベント情報４０ａおよびカスタマイズデータ（customized data）４０ｂを蓄積する。このうちイベント情報４０ａは、センサ５０ａで検知されたイベントに応じてこのセンサ５０ａより出力された情報である。国ＭＳ１０にアップロードされる情報は、センサ５０ａより出力された情報のうち必要な情報が、適宜、取捨選択される。カスタマイズデータ４０ｂはイベント情報を既定の基準に基づいて処理したデータであり、例えば社会インフラ５１〜５ｎの制御ニーズに特化したデータ（制御データ）である。カスタマイズデータ４０ｂは国ＭＳ１０から取得される。

国ＭＳ１０は、収集部１０ａ、データ処理部１０ｂ、送信部１０ｃ、および管理部１０ｄを備える。また、簡略のため図示しないが県ＭＳ６０も国ＭＳ１０と同様に、収集部１０ａ、データ処理部１０ｂ、送信部１０ｃ、および管理部１０ｄを備える。
収集部１０ａは、市ＭＳ３０からアップロードされたイベント情報を収集する。収集されたイベント情報はデータベース２０にイベント情報２０ａとして蓄積される。このイベント情報２０ａは市クラウド３００（図２）からそれぞれアップロードされたイベント情報を集中的に蓄積するものである。

データ処理部１０ｂは、市ＭＳ３０が社会インフラ５１〜５ｎを制御するのに必要とするデータを、データベース２０に蓄積されるイベント情報２０ａを処理して生成する。特に、データ処理部１０ｂは、アップロードされたイベント情報を国クラウド１００、県クラウド２００、および市クラウド３００の階層化のレベル、あるいは各クラウドにおける個別のニーズに応じて処理し、クラウドごとに最適化されたカスタマイズデータ２０ｂを生成する。最適化には、例えばクラウドごとに必要とされるデータの抽出や、平均値の算出などの付加価値を生成することなどが含まれる。生成されたカスタマイズデータ２０ｂはデータベース２０に蓄積される。

最適化の方法としては次のような手法がある。例えば、データ処理部１０ｂは、受信したイベント情報に基づいて需要データを算出する。次にデータ処理部１０ｂは、需要データに基づいて既定の評価関数（例えば「電力」など）を最適化する最適化計算を実行する。最適化計算には線形計画法を利用することができる。これにより得られる負荷予測結果（例えば「電力需要熱量」など）と最適化計算結果とを、クラウドごとのカスタマイズデータとして利用することが可能である。

送信部１０ｃは、データ処理部１０ｂにより生成されたデータを市ＭＳ３０に送信する。管理部１０ｄは、市ＭＳ３０からアップロードされた社会インフラ５１〜５ｎごとのイベント情報に基づいて、各社会インフラ５１〜５ｎを管理する。

上記構成において、市ＭＳ３０、県ＭＳ６０、および国ＭＳ１０は、インタフェース部６を介して通信網ＮＷの回線に着脱可能に接続されるコンピュータである。このコンピュータは単体でその機能を果たすことが可能である。あるいは、クラウドコンピューティングシステムに備わる複数のコンピュータの連携処理により、市ＭＳ３０、県ＭＳ６０、および国ＭＳ１０の機能を実現することも可能である。アップロード部３０ａ、取得部３０ｂ、制御部３０ｃ、収集部１０ａ、データ処理部１０ｂ、送信部１０ｃ、および管理部１０ｄを如何にしてシステムにインプリメントするかは、当業者によれば容易に理解されることが可能であろう。

図５は、センサ５０ａによりイベントが検知され、出力されるイベント情報の一例を示す図である。センサ５０ａとしてスマートメータを例に採れば、例えばそのスマートメータの識別情報（センサＩＤ：IDentification）、設置される地点の位置情報（緯度、経度）、電力消費量の計測値および計測時点のタイムスタンプを、イベント情報の項目の例として挙げることが可能である。

図６は、国クラウド１００のデータベース２０に蓄積される、イベント情報２０ａの一例を示す図である。図６に示されるようにイベント情報２０ａは、各センサ５０ａによりイベントが検知され、各センサ５０ａから出力されたイベント情報をそのまま、いわば生のままのデータを一元的に蓄積するデータベースである。従ってデータベース２０には特に大容量のストレージデバイスを必要とする。単独のストレージデバイスでなく、クラウド上に分散配置される複数のストレージデバイスを用いてデータベース２０を構築する形態が好ましい。この種の大容量のデータベースはBigDataと称されることもある。

図７は、最適化されたイベント情報の一例を示す図である。図７に示されるイベント情報は図６に示されるイベント情報２０ａを時間について集約したもので、例えば県クラウド２００におけるデータベース７０に蓄積される。図７においては、図６における３０秒間隔でのタイムスタンプが１時間単位にまとめられ、１時間内における電力消費量の平均値が示される。このようにイベント情報２０ａは、例えば階層化のレベルに応じて集約される。これにより中位層における県ＭＳ６０は必要最小限のデータを保持すればよくなるので、処理速度の向上などのメリットを得られる。

図８は、集約されたイベント情報の他の例を示す図である。図８に示されるイベント情報は図７に示されるイベント情報をさらに集約したものである。図８には、例えば地区ごとの、日単位での電力消費量の平均値が示される。

つまり図７のテーブルにおける集約化の基準が時間であったのに対し、図８のテーブルにおける集約化の基準は、時間および場所である。図７に示されるデータに比べて、図８に示されるデータの量はさらに少ない。従って下位層における市ＭＳ３０は必要最小限のデータを保持すればよくなる。これにより処理速度の向上や記憶デバイス容量の節約などのメリットを得られる。

なお各層におけるイベント情報の集約化の基準は上記のような階層化のレベルに応じたものに限られることはなく、例えばイベント情報をセンサの種別ごとに集約化したり、様々な基準に基づいて情報をサマライズすることができる。

図９は、クラウドにおける自律制御について模式的に示す図である。図３の説明で述べたように市ＭＳ３０の制御部３０ｃは、障害などにより上位層あるいは中位層との通信が不調になると、自ら収集しているイベント情報のみに基づいて社会インフラ５１〜５ｎを制御する。これにより少なくとも一定期間の間は、社会システムの運営に破綻をきたすことを防止することができる。つまり必要最低限のデータは各クラウドに保持されているので、各ＭＳは自らのクラウドに閉じたかたちで制御を継続することができる。

また、そのようなケースに備えてアクチュエータ５０ｂ自体にも自律運転機能を持たせておくようにして、システムの更なる安定的な稼動を期待できることも可能である。

図１０は、第１の実施形態における情報およびデータの流れを模式的に示す図である。Ａ市およびＢ市はそれぞれＳＣＭＳ（スマートコミュニティＭＳ）３０（市ＭＳ３０）を備える。電力網、水道網、鉄道網、および交通網はＡ市とＢ市とに跨って構築されており、通信網ＮＷの回線により互いに関係付けられる。煩雑を避けるため以下では電力網、水道網について説明する。

電力網、水道網のいずれもセンサ５０ａ、アクチュエータ５０ｂを備える。このうち電力網のセンサ５０ａで検知されたイベント情報は、市町村レベルよりも上位層のクラウド、例えば国クラウド１００の電力ＭＳ５００に全てアップロードされる。電力ＭＳ５００は、イベント情報を処理して社会インフラを制御するためのデータを生成する。このデータはＡ市の市ＭＳ３０、Ｂ市の市ＭＳ３０にそれぞれ送信される。

Ａ市の市ＭＳ３０は、取得したデータおよび自ら収集したイベント情報に基づいて電力網のアクチュエータ５０ｂを制御する。同様にＢ市の市ＭＳ３０も、上位層から取得したデータおよび自ら収集したイベント情報に基づいて電力網のアクチュエータ５０ｂを制御する。

水道網についても同様である。すなわち水道網のセンサ５０ａから出力されたイベント情報は水道ＭＳ６００に全てアップロードされる。水道ＭＳ６００は収集したイベント情報を処理して社会インフラを制御するためのデータを生成する。このデータはＡ市の市ＭＳ３０、Ｂ市の市ＭＳ３０にそれぞれ送信される。

Ａ市の市ＭＳ３０は、取得したデータおよび自ら収集したイベント情報に基づいて水道網のアクチュエータ５０ｂを制御する。同様にＢ市の市ＭＳ３０も、上位層から取得したデータおよび自ら収集したイベント情報に基づいて水道網のアクチュエータ５０ｂを制御する。

以上のように第１の実施形態では、センサ５０ａでイベントが検知され、出力されたイベント情報をそのまま国ＭＳ１０にアップロードして集中的に蓄積する。そして、国ＭＳ１０に集約されたデータから、中位層および下位層の階層化のレベルに応じて最適化したイベント情報２０ａを生成する。生成されたイベント情報２０ａは、上位層から下位層に送信される。イベント情報２０ａの最適化、あるいは集約化の基準は、社会システムの階層化のレベル、あるいは社会システムの個別の要求（個別ニーズ）を反映する。

すなわち、第１の実施形態では、センサによりイベント検知され出力されたイベント情報を下位層の制御システムから上位層の制御システムに集め、下位の制御システムにおいては制御データを上位層から取得し、この制御データにより社会インフラを制御する。また下位の制御システムは、自ら収集したイベント情報に基づいて、上位層の制御システムに依存せず社会インフラを独自に制御することができる。従って全体とローカルとの両面からの最適性を担保することができる。特に、特定の行政区域、例えば国や県の中に複数の市又はコミュニティに対応して下位層の制御システムが複数存在する場合は、この特定行政区域全体と、個々の市又はコミュニティとの両方の最適化が可能となる。

第１の実施形態は、例えば電力料金のリアルタイムプライシングへの応用などにも適することができる。つまり現在の状況をモニタしながら社会インフラの運用に係わるパラメータを制御できるので、きめ細かな制御を実現することが可能になる。

なお、センサ５０ａでイベントが検知され出力されたイベント情報は、国ＭＳ１０にアップロードされると共に、県ＭＳ６０にもアップロードされ、各ＭＳ１０，６０において蓄積される。イベント情報を受信した県ＭＳ６０は、国ＭＳ１０と同様にして、最適化したイベント情報２０ａを生成する。生成されたイベント情報２０ａは、中位層から下位層に送信される。イベント情報２０ａの最適化、あるいは集約化の基準は、社会システムの階層化のレベル、あるいは社会システムの個別の要求（個別ニーズ）を反映する。

［第２の実施形態］
第２の実施形態では、社会インフラを備えるコミュニティを制御の対象とする。コミュニティは、人々の暮らしを支えるエネルギーインフラ、水道インフラ、医療インフラなどの多様な社会インフラを備えており、社会インフラの集合体として捉えることが可能な概念である。コミュニティ自体を社会インフラのひとつの形態として理解することも可能である。快適性や安全性、省エネ性などを高いレベルで実現するコミュニティは特に、スマートコミュニティと称される。

近年では、デベロッパー、管理会社、あるいは一括受電請負会社などにより管理される形態のコミュニティが増えてきている。この種のコミュニティでは、電力会社から一括で受電した電力をコミュニティ内の複数の需要家に分配供給するといった形態が一般的である。この種のコミュニティとしてはショッピングモール、マンション、工業団地、あるいは住宅街などを挙げることができる。この種のコミュニティも社会インフラの一例として捉えることが可能である。

第２の実施形態では、コミュニティを管理、運営するデベロッパーなどの、事業者の存在を考慮する。例えば、電力を電力会社から一括受電してコミュニティに分配する業者などを、事業者の一例として理解することが可能である。そして、このコミュニティを運営する事業者に、ベンダがソフトウェアを有償で提供することの可能な形態を開示する。

図１１は、第２の実施形態に係る社会インフラ制御システムの一例を示す概念図である。図１１は、図２に示される市町村レベルの階層をさらに細分化したものに相当する。図１１において、Ｋ県が上位層に位置する。Ｋ県の県クラウド２００は、通信網ＮＷの回線を介して国クラウド１００、およびＹ市、Ｐ市の各市クラウド３００に接続される。

このうちＹ市の市クラウド３００は、通信網ＮＷの回線を介して複数のエリアクラウド４００に接続される。図１１においてはＫエリア、Ｍエリア、Ｙエリアの各クラウドが示される。Ｋエリア、Ｍエリア、ＹエリアはＹ市により制御される。

Ｋエリア、Ｍエリア、Ｙエリアのいずれも、Ｙ市に属する自治体、あるいは自治体群として捉えることが可能である。つまりＫエリア、Ｍエリア、Ｙエリアは、例えば人々の生活する、或る広さ（例えば３ｋｍ四方圏）を持つ区域、工場地帯、オフィス街区などとして理解することが可能である。要するにＫエリア、Ｍエリア、Ｙエリアはコミュニティである。

Ｋエリアのエリアクラウド４００、Ｍエリアのエリアクラウド４００、Ｙエリアのエリアクラウド４００は、それぞれコンピュータ２およびデータベースＤＢを備える。各エリアクラウド４００は通信網ＮＷの回線を介して接続され相互の連携を保っている。

図１２は、図１１に示されるシステムの要部を模式的に示す図である。Ｙ市の市クラウド３００は、通信網ＮＷの回線を介してＭエリア、Ｋエリア（およびＹエリア）に接続される。各エリアはそれぞれのエリアを受け持つ事業者により使用される、コンピュータ２を備える。

Ｍエリアは例えば超高層のオフィスビルが立ち並ぶビル街を有するコミュニティであり、Ｋエリアは例えば住宅街を有するコミュニティである。従ってＭエリアを制御するコンピュータ２にはＭエリアに特化したデータを与える必要があるし、Ｋエリアを制御するコンピュータ２にはＫエリアに特化したデータを与える必要がある。

通信網ＮＷの回線には、ベンダクラウド５００が接続される。各エリアのコンピュータ２に与えられるデータは、最上位層のベンダにより管理される制御システムより提供される。

図１３は、第２の実施形態に係る社会インフラ制御システムを示す図である。図１３に示されるシステムは、最上位層にあるベンダクラウド５００を備える。ベンダクラウド５００は通信網ＮＷの回線に接続されることが可能である。ベンダクラウド５００は、ベンダにより管理、運営されるクラウドコンピューティングシステムであり、ベンダＭＳ８０およびデータベース９０を備える。ベンダクラウド５００は例えばサーバ機能を備えるコンピュータ、あるいはコンピュータ群である。コンピュータは、実施形態に係る機能を実現するプログラムを記憶するメモリと、当該プログラムを実行する制御部とを備える。

ベンダＭＳ８０はコンピュータそのもの、コンピュータによる処理機能の一つ、あるいは、データセンタなどのかたちで実現されることが可能である。データベース９０はベンダＭＳ８０に備わるストレージデバイスに記憶されても良いし、ベンダＭＳ８０に接続される別のコンピュータに記憶されても良い。

一方、図１３において、例えばＫエリア、Ｍエリア、あるいはＹエリア（図１１）に対応するコミュニティ７００はコミュニティクラウド６００により管理される。コミュニティクラウド６００は、事業者ＭＳ１を備える。事業者ＭＳ１は例えばコンピュータ２（図１１）であり、コミュニティクラウド６００に備わるデータベース４０に接続される。

コミュニティ７００は複数の社会インフラ５１〜５ｎを備える。社会インフラ５１〜５ｎは例えば水インフラ、熱インフラ、電気インフラ、交通インフラ、ビルインフラ、等、である。社会インフラ５１〜５ｎは、それぞれセンサ５０ａ、アクチュエータ５０ｂを備える。

ベンダクラウド５００のベンダＭＳ８０は、実施形態に係る機能ブロックとして、収集部１０ａ、データ処理部１０ｂ、送信部１０ｃ、および、管理部１０ｄを備える。データベース９０は、イベント情報２０ａと、カスタマイズデータ２０ｂとを記憶することが可能である。

収集部１０ａは、センサ５０ａによりイベントが検知され出力されたイベント情報２０ａを事業者ＭＳ１から通信網ＮＷの回線を介して収集し、データベース９０に保存する。
データ処理部１０ｂは、事業者ＭＳ１が社会インフラ５１〜５ｎを制御するのに必要とするデータを、データベース９０に蓄積されるイベント情報２０ａを処理して生成する。特に、データ処理部１０ｂは、コミュニティ７００における個別のニーズに応じて処理し、コミュニティごとに最適化されたカスタマイズデータ２０ｂを生成する。最適化には、例えばコミュニティごとに必要とされるデータの抽出や、平均値の算出などの付加価値を生成することなどが含まれる。生成されたカスタマイズデータ２０ｂはデータベース９０に蓄積される。

例えば、対象とするコミュニティがＭエリア（図１２）であれば、例えばＢＥＭＳ向けのデマンドレスポンスに適するデータが生成される。対象とするコミュニティがＫエリアであれば、例えばＨＥＭＳ向けのデマンドレスポンス制御や戸別ＰＶシステムの制御に適するデータが生成される。このように、コミュニティの特性に適するデータがイベント情報２０ａから生成される。

送信部１０ｃは、データ処理部１０ｂにより生成されたデータを事業者ＭＳ１に送信する。管理部１０ｄは、事業者ＭＳ１からアップロードされた社会インフラ５１〜５ｎ、あるいはコミュニティごとのイベント情報に基づいて、各社会インフラ５１〜５ｎやコミュニティを管理する。

一方、事業者ＭＳ１は、アップロード部３０ａ、取得部３０ｃ、および制御部３０ｃを備える。アップロード部３０ａは、センサ５０ａによりイベントが検知され、出力されたイベント情報をベンダＭＳ８０、国ＭＳ１０および県ＭＳ６０に、通信網ＮＷの回線を介して送信する。

さらに、通信網ＮＷの回線には県クラウド２００、市クラウド３００などが接続されることができる。簡略化のため図示しないが、図１３に示される県クラウド２００は図３に示される県クラウド２００と同様の構成を備え、県ＭＳ６０およびデータベース７０を備える。県ＭＳ６０が国ＭＳ１０と同様の構成を備えることも図３と同様である。また、図１３に示される市クラウド３００は、図３に示される市クラウド３００と同様の構成を備え、市ＭＳ３０およびデータベース４０を備える。

図１４は、事業者ＭＳ１からベンダＭＳ８０、国ＭＳ１０および県ＭＳ６０に通信網ＮＷの回線を介して送信されるイベント情報の一例を示す図である。イベント情報は、例えばＩＰパケットの形態で通信網ＮＷの回線に送出される。ＩＰパケットのペイロードには、センサ５０ａにより検知されたセンシングデータと、当該センシングデータに係わる社会インフラの種別と、この社会インフラを備えるコミュニティ７００を識別するための情報（Identification：ＩＤ）とが例えば記載される。

ＩＰパケットのヘッダには、送信元（事業者ＭＳ１）のＩＰアドレスと、マルチキャストアドレスとが例えば記載される。ベンダＭＳ８０、国ＭＳ１０、県ＭＳ６０、および市ＭＳ３０は、このＩＰパケットを受信することでイベント情報を収集することが可能である。ＩＰパケットのペイロードにセンシングデータとインフラ種別とを記載する形態は第１の実施形態においても同様に適用することが可能である。

図１３に戻り、取得部３０ｂは、社会インフラ５１〜５ｎの制御に要するデータ（カスタマイズデータ４０ｂ）をベンダＭＳ８０から取得する。

制御部３０ｃは、取得部３０ｂにて取得した制御データに基づいてアクチュエータ５０ｂに制御指示を与える。または、制御部３０ｃは、センサ５０ａにより検知したイベント情報に応じてアクチュエータ５０ｂに制御指示を与える。つまり、制御部３０ｃは、上位層から取得された制御データ、またはローカルで取得されたイベント情報のいずれかに基づいて、社会インフラ５１〜５ｎを制御する。

制御部３０ｃは、ローカルで取得されたイベント情報に基づく制御よりも、上位層から取得された制御データに基づく制御を優先する。このように、上位システムからの制御の優先度を高くすることで、システム全体の最適性を優先的に確保することができる。

通信網ＮＷの回線に障害が生じるなどしてベンダＭＳ８０との通信に障害が生じた場合は、制御部３０ｃは、自ら収集したイベント情報４０ａのみに基づいて社会インフラ５１〜５ｎを制御する。

データベース４０は、イベント情報４０ａおよびカスタマイズデータ４０ｂを蓄積する。このうちイベント情報４０ａは、センサ５０ａで検知されたイベントに応じてこのセンサ５０ａより出力された情報である。ベンダＭＳ８０にアップロードされる情報は、センサ５０ａより出力された情報のうち必要な情報が、適宜、取捨選択される。

カスタマイズデータ４０ｂはイベント情報を既定の基準に基づいて処理したデータであり、例えば社会インフラ５１〜５ｎを備えるコミュニティの制御ニーズに特化したデータである。カスタマイズデータ４０ｂはベンダＭＳ８０から取得される。

このように事業者ＭＳ１は、ベンダＭＳ８０から取得したカスタマイズデータに基づいてコミュニティ７００の各インフラ５１〜５ｎのセンサ５０ａ、アクチュエータ５０ｂを制御し、コミュニティ７００における市民の快適かつ安全な生活を支援する。

以上のように第２の実施形態によれば、上位層にあるベンダにより管理されているベンダＭＳ８０で、それより下位層にある各制御システムから受信したイベント情報に基づきコミュニティ７００向けに最適化したカスタマイズデータが生成され、またこのデータを受信した事業者ＭＳ１の制御部３０ｃは、ベンダＭＳ８０から取得したデータに基づいてコミュニティ７００を制御する。このようにすることで、ベンダは、下位層の制御システムに対応するコミュニティの事業者に対して、カスタマイズデータを与える見返りに課金を施すなどのビジネスモデルを構築することが可能になる。

また下位の制御システムは、自ら収集したイベント情報に基づいて、上位層のベンダＭＳ８０に係わる制御システムに依存せず社会インフラを独自に制御することができる。従って全体とローカルとの両面からの最適性を担保することができる。

［第３の実施形態］
第３の実施形態では、ベンダがコミュニティごとに最適化したカスタマイズデータを作成する手順について説明する。
図１５は、第３の実施形態に係る社会インフラ制御システムの一例を示す図である。図１５に示されるシステムは、ベンダクラウド５００を備える。ベンダクラウド５００は通信網ＮＷの回線に接続されることが可能である。ベンダクラウド５００は、ベンダにより管理、運営されるクラウドコンピューティングシステムであり、ベンダＭＳ８０およびデータベース９０を備える。ベンダクラウド５００は例えばサーバ機能を備えるコンピュータ、あるいはコンピュータ群である。コンピュータは、実施形態に係る機能を実現するプログラムを記憶するメモリと、当該プログラムを実行する制御部とを備える。

ベンダＭＳ８０はコンピュータそのもの、コンピュータによる処理機能の一つ、あるいは、データセンタなどのかたちで実現されることが可能である。データベース９０はベンダＭＳ８０に備わるストレージデバイスに記憶されても良いし、ベンダＭＳ８０に接続される別のコンピュータに記憶されても良い。

一方、図１５において、例えばＫエリア、Ｍエリア、あるいはＹエリア（図１１）に対応するコミュニティ７００はコミュニティクラウド６００により管理される。コミュニティクラウド６００は、事業者ＭＳ１を備える。事業者ＭＳ１は例えばコンピュータ２（図１１）であり、コミュニティクラウド６００に備わるデータベース４０に接続される。

コミュニティ７００は複数の社会インフラ５１〜５ｎを備える。社会インフラ５１〜５ｎは例えば水インフラ、熱インフラ、電気インフラ、交通インフラ、ビルインフラ、等、である。社会インフラ５１〜５ｎは、それぞれセンサ５０ａ、アクチュエータ５０ｂを備える。

ベンダクラウド５００のベンダＭＳ８０は、実施形態に係る機能ブロックとして、収集部１０ａ、データ処理部１０ｂ、送信部１０ｃ、呼び出し部８０ｃ、カウンタ８０ａ、料金管理部８０ｂ、および、管理部１０ｄを備える。データベース９０は、イベント情報２０ａ、カスタマイズデータ２０ｂ、アルゴリズムライブラリ９０ｂ、および、課金データ９０ａを記憶することが可能である。

収集部１０ａは、センサ５０ａによりイベントが検知され、出力されたイベント情報２０ａを事業者ＭＳ１から通信網ＮＷの回線を介して収集し、データベース９０に保存する。
データ処理部１０ｂは、事業者ＭＳ１が社会インフラ５１〜５ｎを制御するのに必要とするデータを、データベース９０に蓄積されるイベント情報２０ａを処理して生成する。特に、データ処理部１０ｂは、コミュニティ７００における個別のニーズに応じて処理し、コミュニティごとに最適化されたカスタマイズデータ２０ｂを生成する。最適化には、例えばコミュニティごとに必要とされるデータの抽出や、平均値の算出などの付加価値を生成することなどが含まれる。生成されたカスタマイズデータ２０ｂはデータベース９０に蓄積される。

例えば、対象とするコミュニティがＭエリア（図１２）であれば、例えばＢＥＭＳ向けのデマンドレスポンスに適するデータが生成される。対象とするコミュニティがＫエリアであれば、例えばＨＥＭＳ向けのデマンドレスポンス制御や戸別ＰＶシステムの制御に適するデータが生成される。このように、コミュニティの特性に適するデータがイベント情報２０ａから生成される。
送信部１０ｃは、データ処理部１０ｂにより生成されたデータを事業者ＭＳ１に送信する。

呼び出し部８０ｃは、データ処理部１０ｂが制御データの生成に要するアルゴリズムをアルゴリズムライブラリ９０ｂから呼び出す。すなわち呼び出し部８０ｃは、制御データを生成するために必要なアルゴリズムを、データ処理部１０ｂの対象とするコミュニティ（ローカルシステム）ごとに、アルゴリズムライブラリ９０ｂから呼び出す。

特に呼び出し部８０ｃは、対象とするローカルシステムの最適化アルゴリズムを、当該ローカルシステムの個別のニーズに応じてアルゴリズムライブラリ９０ｂから呼び出す。また呼び出し部８０ｃは、複数のローカルシステムが複数の階層に階層化される場合（例えば図２）に、対象とするローカルシステムの最適化アルゴリズムを当該ローカルシステムの階層に基づいて呼び出す。呼び出されたアルゴリズムはデータ処理部１０ｂに渡され、制御データの生成の都度、使用される。

図１６は、図１５に示されるアルゴリズムライブラリ９０ｂの一例を示す図である。アルゴリズムライブラリ９０ｂは、ローカルシステム（社会インフラ、またはコミュニティ）ごとの最適化アルゴリズムを記録するライブラリである。

すなわちアルゴリズムライブラリ９０ｂは、センサ情報から制御データ（カスタマイズデータ）を生成するための演算アルゴリズムを、社会インフラごとに、あるいはコミュニティごとに対応付けて記録するライブラリである。各アルゴリズムの実態は例えば最適化関数を特定の言語で記述したコード列であっても良いし、機械語レベルにまでデコードされたバイナリデータ、あるいはこれを暗号化したデータであっても良い。

各アルゴリズムには区別のため、例えば通し番号が与えられる。また各アルゴリズムは例えばそれぞれのエリアに備わる社会インフラごとにユニット化されて管理される。また、ユニットごとに、例えばサービスの内容に応じてＳ，Ａ，Ｂ，…のランクを設定し、ランクごとにアルゴリズムをまとめて管理することも可能である。このような階層化構造は多岐にわたるアルゴリズムを管理するのに都合が良い。

各アルゴリズムはそのベンダ（提供者）により更新あるいはバージョンアップされる。これによりアルゴリズムライブラリ９０ｂは次第に充実したものになる。各アルゴリズムの開発者は、自ら提供したアルゴリズムに基づく制御データがダウンロードされるごとにサービス受益者に相応の課金を課すといったビジネスモデルを構築することが可能である。

各アルゴリズムがどのような演算機能を提供するかという情報や、各アルゴリズムを個別に特定するための通し番号、更新履歴などは、一覧表やＸＭＬデータなどの形式で管理可能である。ベンダＭＳ３０は、この通知された内容から、選択すべきアルゴリズムを特定することが可能である。

図１５に戻り、データ処理部１０ｂは、呼び出し部８０ｃによりアルゴリズムライブラリ９０ｂから呼び出されたアルゴリズムに基づいてイベント情報２０ａを最適化して、ローカルシステムごとに制御データを生成する。

カウンタ８０ａは、コミュニティの制御に要する制御データが事業者ＭＳ１にダウンロードされた量をカウントする。ここでいう“量”とは、ダウンロードされた数、データサイズ、バイト数など、定量的にカウント可能で課金の拠りどころとなるべき量であればどのような量であっても良い。

料金管理部８０ｂは、カウンタ８０ａによりカウントされた量を取得し、予め定められた単価に基づいて課金データ９０ａを算出する。課金データ９０ａは例えばコミュニティごとにテーブル化されて管理されることが可能である。この課金データ９０ａはベンダＭＳ８０の記憶部（図示せず）、あるいはデータベース９０に記憶される。この課金データ９０ａは、例えばコミュニティクラウド６００の事業者や住民などの受益者、に課金する際に用いられ、ベンダにとっては収入源となる情報である。

管理部１０ｄは、事業者ＭＳ１からアップロードされた社会インフラ５１〜５ｎ、あるいはコミュニティごとのイベント情報に基づいて、各社会インフラ５１〜５ｎやコミュニティを管理する。

一方、事業者ＭＳ１は、アップロード部３０ａ、取得部３０ｃ、および制御部３０ｃを備える。アップロード部３０ａは、センサ５０ａにより検知されたイベント情報をベンダＭＳ８０、県ＭＳ６０および市ＭＳ３０に、通信網ＮＷの回線を介して送信する。通信網ＮＷの回線には県クラウド２００、市クラウド３００などが接続される。

取得部３０ｂは、社会インフラ５１〜５ｎの制御に要するデータ（カスタマイズデータ４０ｂ）をベンダＭＳ８０から取得する。
制御部３０ｃは、取得部３０ｂにて取得した制御データに基づいてアクチュエータ５０ｂに制御指示を与える。または、制御部３０ｃは、センサ５０ａにより検知したイベント情報に応じてアクチュエータ５０ｂに制御指示を与える。つまり、制御部３０ｃは、上位層から取得された制御データ、またはローカルで取得されたイベント情報のいずれかに基づいて、社会インフラ５１〜５ｎを制御する。

制御部３０ｃは、ローカルで取得されたイベント情報に基づく制御よりも、上位層から取得された制御データに基づく制御を優先する。このように、上位システムからの制御の優先度を高くすることで、システム全体の最適性を優先的に確保することができる。

また、通信網ＮＷの回線に障害が生じるなどしてベンダＭＳ８０との通信に障害が生じた場合は、制御部３０ｃは、自ら収集したイベント情報４０ａのみに基づいて社会インフラ５１〜５ｎを制御する。

データベース４０は、イベント情報４０ａおよびカスタマイズデータ４０ｂを蓄積する。このうちイベント情報４０ａはセンサ５０ａで検知されたイベントに応じてこのセンサ５０ａより出力された情報である。ベンダＭＳ８０にアップロードされる情報は、センサ５０ａより出力された情報のうち必要な情報が、適宜、取捨選択される。

カスタマイズデータ４０ｂはイベント情報を既定の基準に基づいて処理したデータであり、例えば社会インフラ５１〜５ｎを備えるコミュニティの制御ニーズに特化したデータである。カスタマイズデータ４０ｂはベンダＭＳ８０から取得される。

さらに、通信網ＮＷの回線には県クラウド２００、市クラウド３００などが接続されることができる。簡略化のため図示しないが、図１５に示される県クラウド２００は図３または図１３に示される県クラウド２００と同様の構成を備え、県ＭＳ６０およびデータベース７０を備える。県ＭＳ６０が国ＭＳ１０と同様の構成を備えることも図３および図１５と同様である。また、図１５に示される市クラウド３００は、図３または図１３に示される市クラウド３００と同様の構成を備え、市ＭＳ３０およびデータベース４０を備える。

図１７は、図１５に示されるベンダＭＳ８０の一例を示す機能ブロック図である。ベンダＭＳ８０は、入出力部１４、インタフェース部６、記憶部１３、Central Processing Unit（ＣＰＵ）１１、およびプログラムメモリ１２を備える。すなわちベンダＭＳ８０は、プログラムメモリ１２に記憶されたプログラムをＣＰＵ１１が実行することで機能するコンピュータである。

入出力部１４は、オペレータなどにより操作されるヒューマンマシンインタフェース（操作パネルやスイッチなど）である。入出力部１４は、Graphical User Interface（ＧＵＩ）環境を形成してユーザによる情報入力を受け付け、また、ユーザに情報を提供する。

インタフェース部６は通信網ＮＷの回線、およびデータベース９０に接続され、通信網ＮＷの回線および各クラウド５００，２００，３００，６００との通信機能を担う。記憶部１３は、課金データ９０ａ、およびアルゴリズムライブラリ９０ｂを記憶する。

プログラムメモリ１２は、この実施形態に係わる処理機能に必要な命令を含むプログラムとしての、収集プログラムＰ１、データ処理プログラムＰ２、送信プログラムＰ３、呼び出しプログラムＰ４、カウントプログラムＰ５、料金管理プログラムＰ６、および、管理プログラムＰ７を記憶する。これらのプログラムは、ＣＤ−ＲＯＭなどのリムーバブルメディア（記録媒体）に記録することも、通信回線（通信網ＮＷの回線を含む）を介してダウンロードすることも可能である。

ＣＰＵ１１はプログラムメモリ１２から各プログラムを読み出してハードウェアによる演算処理を行うもので、その処理機能として、上記説明した収集部１０ａ、データ処理部１０ｂ、送信部１０ｃ、呼び出し部８０ｃ、カウンタ８０ａ、料金管理部８０ｂ、および、管理部１０ｄを備える。

図１８は、第３の実施形態におけるベンダＭＳ８０の処理手順の一例を示すフローチャートである。図１８においてベンダＭＳ８０は、事業者ＭＳ１において取得されたイベント情報を、通信網ＮＷの回線を介して収集し（ステップＳ１）、データベース９０に蓄積する（ステップＳ２）。

次にベンダＭＳ８０は、ステップＳ３〜ステップＳ１０の間に含まれるループを実行する。ループ内においてベンダＭＳ８０は、対象とするコミュニティに対応する最適化アルゴリズムをアルゴリズムライブラリ９０ｂから選択する（ステップＳ４）。選択の基準は先に述べたように、例えば、対象とするコミュニティの個別のニーズに応じたアルゴリズムを選択する、という基準である。あるいは、コミュニティ（クラウド）が階層化されていれば、選択の基準は、例えば対象とするコミュニティ（クラウド）の階層に基づいてアルゴリズムを選択する、という基準である。次にベンダＭＳ８０は、ステップＳ４で選択されたアルゴリズムを呼び出す（ステップＳ５）。

次にベンダＭＳ８０は、呼び出されたアルゴリズムを用いて、イベント情報２０ａから制御データを算出する（ステップＳ６）。次にベンダＭＳ８０は、算出した制御データを通信網ＮＷの回線を介して事業者ＭＳ１にダウンロード送信する（ステップＳ７）。そしてベンダＭＳ８０は、制御データが事業者ＭＳ１にダウンロードされた量をカウントし（ステップＳ８）、カウント値に基づいて課金データ９０ａを算出する（ステップＳ９）。

ステップＳ３〜ステップＳ１０のループは、例えばベンダＭＳ８０の対象とするコミュニティの全てについて、例えば順次実行される。ループから出ると、処理手順は再びステップＳ１に移行し、ベンダＭＳ８０はイベント情報の収集からの処理を繰り返す。なお、イベント情報の収集および蓄積と同時並行的に、ステップＳ３〜ステップＳ１０のループを実施することも可能である。

以上述べたように第３の実施形態によれば、データベース９０に蓄積されたイベント情報２０ａを、コミュニティ７００のニーズ、あるいは階層化レベルに応じて最適化し、コミュニティのそれぞれに応じた制御データを生成するようにしている。事業者ＭＳ１は生成された制御データを取得し、この制御データを用いて社会インフラ５１〜５ｎを制御すれば良い。これにより、クラウド（ベンダクラウド５００）のリソースを利用してコミュニティごとの制御データを生成することが可能になり、コミュニティの運営者（事業者）にとっては社会インフラ５１〜５ｎを制御するためのリソースの節約などの利益を得ることが可能になる。

また、下位クラウドで生じたイベント情報２０ａを上位クラウドで管理するようにしているので、耐障害性能の向上などのメリットも得られる。また、データのアップロードおよびダウンロードに係わるリアルタイム性を保障可能な通信網ＮＷの回線を利用しているので、社会インフラ５１〜５ｎの制御に係わる遅延を最小限にすることもできる。

また、コミュニティごとに適切なアルゴリズムを用いてイベント情報２０ａを集約化しているので、各コミュニティは、社会インフラ５１〜５ｎの制御にあたり必要最小限の制御データを取得するようにすれば良い。つまり各コミュニティは、社会インフラ５１〜５ｎの末端の機器の時定数に追従するために必要最小限のデータを取得できれば、制御のリアルタイム性を失うことなく、社会インフラ５１〜５ｎを制御することができる。

また、制御データが生成されダウンロードされるたびに課金データが算出され、この課金データは制御データの受益者ごとに管理される。これにより、ベンダに制御データを生成し、アルゴリズムを更新するインセンティブを与えることが可能になり、コミュニティに生活する市民はもとより、ソフトウェアベンダにとっても有益な社会インフラ制御システムを提供することが可能になる。

また下位の制御システムは、自ら収集したイベント情報に基づいて、上位層の制御システムに依存せず社会インフラを独自に制御することができる。従って全体とローカルとの両面からの最適性を担保することができる。

また第３の実施形態によれば、社会システムとしてのコミュニティの変化にも柔軟に対処することが可能である。つまり時々刻々と収集されるイベント情報を解析してコミュニティの特性を算出し、これを繰り返すことでコミュニティの発展あるいは縮小に応じてアルゴリズムライブラリを拡充してゆくことが可能になる。

なお本発明は上記実施の形態に限定されるものではない。例えば実施形態では、下位層からアップロードされたイベント情報を上位層において集中的に蓄積することを可能にした。つまり最下位層で生じたイベント情報はそのまま最上位層にアップロードされ、最上位層が全てのデータを保持する。これに代えて中位層において全てのデータを保持するようにしても良い。要するに全てのデータは、いずれかのクラウドにおいて集中的に蓄積、管理されれば良い。

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

Claims (23)

1. 地域に応じて設けられ、センサで検知した前記地域のインフラに関するイベント情報に基づいて前記インフラを制御する複数の第１サーバと、
   前記第１サーバから受信した前記イベント情報より、前記第１サーバでの制御に係るデータを生成する第２サーバとを具備し、
   前記第１サーバは、前記イベント情報に基づく前記地域に応じたインフラ制御を独自に行いつつ、前記第２サーバから受信した前記データに基づく制御を行う、インフラ制御システム。
2. 地域のインフラに関するイベント情報を検知するセンサと、
   前記センサで検知された前記イベント情報に基づいて前記インフラを制御する第１サーバと、
   前記イベント情報を前記地域について最適化したデータを生成する第２サーバとを具備し、
   前記第１サーバは、前記イベント情報に基づく制御よりも、前記第２サーバから送信された前記データに基づく制御を優先する、インフラ制御システム。
3. 第１サーバと、第２サーバとを具備し、
   前記第１サーバは、
   地域のインフラに関するイベント情報を出力するセンサと、
   前記第２サーバに前記イベント情報をアップロードするアップロード部と、
   前記イベント情報に基づいて前記インフラを制御する制御部とを備え、
   前記第２サーバは、
   前記アップロードされたイベント情報を前記地域について最適化したデータを生成するデータ処理部と、
   前記第１サーバに前記データを送信する送信部とを備える、インフラ制御システム。
4. 前記第２サーバは、複数の最適化アルゴリズムを記憶する記憶部から、対象とするインフラの最適化アルゴリズムを呼び出す呼び出し部を備え、
   前記データ処理部は、前記イベント情報を前記呼び出された最適化アルゴリズムに基づいて最適化して、前記インフラごとに前記データを生成する、請求項３に記載のインフラ制御システム。
5. 前記呼び出し部は、前記対象とするインフラの最適化アルゴリズムを当該インフラの個別のニーズに応じて呼び出す、請求項４に記載のインフラ制御システム。
6. さらに、前記送信されるデータに関して予め設定される単価に基づく課金データを管理する料金管理部を備える、請求項１乃至３のいずれか１項に記載のインフラ制御システム。
7. 前記第２サーバは、前記イベント情報を蓄積するデータベースを備えるクラウドコンピューティングシステムに備えられる、請求項１乃至３のいずれか１項に記載のインフラ制御システム。
8. 前記センサは、種別の異なる複数のインフラごとに前記イベント情報を検知し、
   前記アップロード部は、前記複数のインフラごとに検知されたイベント情報をアップロードし、
   さらに、前記アップロードされた前記複数のインフラごとのイベント情報に基づいて前記複数のインフラを管理する管理部を備える、請求項３に記載のインフラ制御システム。
9. 地域に応じて設けられ、センサで検知した前記地域のインフラに関するイベント情報に基づいて前記インフラを独自に制御する複数の下位サーバを有するインフラ制御システムで利用されるサーバであって、
   前記下位サーバから前記イベント情報を収集する収集部と、
   受信した前記イベント情報より、前記下位サーバでの制御に係るデータを生成する生成部と、
   前記生成部で生成したデータを前記下位サーバに送信する送信部とを有し、
   前記下位サーバに対し、前記前記地域に応じたインフラ制御を独自に行いつつ、前記送信した前記データに基づく制御を行わせる、サーバ。
10. さらに、複数のローカルシステムごとの最適化アルゴリズムを記憶する記憶部と、
    対象とするローカルシステムの最適化アルゴリズムを前記記憶部から呼び出す呼び出し部とを具備し、
    前記生成部は、前記イベント情報を前記呼び出された最適化アルゴリズムに基づいて最適化して、前記ローカルシステムごとに前記データを生成する、請求項９に記載のサーバ。
11. 前記呼び出し部は、前記対象とするローカルシステムの最適化アルゴリズムを当該ローカルシステムの個別のニーズに応じて呼び出す、請求項１０に記載のサーバ。
12. さらに、前記送信されるデータに関して予め設定される単価に基づく課金データを管理する料金管理部を備える、請求項９に記載のサーバ。
13. 受信した地域のインフラに関するイベント情報から制御に係るデータを生成する上位サーバを有する、インフラ制御システムで利用されるサーバであって、
    前記地域に応じて設けられ、センサで検知した前記地域のインフラに関するイベント情報に基づいて前記インフラを制御する制御部を有し、
    前記制御部は、前記イベント情報に基づく前記地域に応じたインフラ制御を独自に行いつつ、前記上位サーバから受信した前記データに基づく制御を行うことを特徴とするサーバ。
14. 前記上位サーバで生成された前記データを受信する受信部を具備する、請求項１３に記載のサーバ。
15. 地域のインフラに関するイベント情報を検知するセンサと、
    前記イベント情報を前記地域について最適化したデータを受信する受信部と、
    前記センサで検知された前記イベント情報に基づいて前記インフラを制御する制御部とを具備し、
    前記制御部は、前記イベント情報に基づく前記地域に応じたインフラ制御を独自に行いつつ、前記受信された前記データに基づく制御を行う、サーバ。
16. 前記データを生成する装置に前記イベント情報をアップロードするアップロード部を具備する、請求項１３乃至１５のいずれか１項に記載のサーバ。
17. 地域のインフラに関して設けられたセンサで検知されたイベント情報に基づいて前記インフラを制御するサーバの制御方法であって、
    前記サーバと通信可能な装置が、前記イベント情報を前記地域について最適化したデータを生成することと、
    前記サーバが、前記イベント情報に基づく前記地域に応じたインフラ制御を独自に行いつつ、前記装置から受信された前記データに基づく制御を行う、制御方法。
18. センサが、地域のインフラに関するイベント情報を検知することと、
    サーバが、前記センサで検知された前記イベント情報に基づいて前記インフラを制御することと、
    前記サーバと通信可能な装置が、前記イベント情報を前記地域について最適化したデータを生成することと、
    前記サーバが、前記イベント情報に基づく前記地域に応じたインフラ制御を独自に行いつつ、前記装置から送信された前記データに基づく制御を行う、制御方法。
19. センサが、地域のインフラに関するイベント情報を出力することと、
    サーバが、当該サーバと通信可能な装置に前記イベント情報をアップロードすることと、
    前記サーバが、前記イベント情報に基づいて前記インフラを制御することと、
    前記装置が、前記アップロードされたイベント情報を前記地域について最適化したデータを生成することと、
    前記装置が、前記サーバに前記データを送信することとを含む、制御方法。
20. 前記生成することは、
    複数の最適化アルゴリズムを記憶する記憶部から、対象とするインフラの最適化アルゴリズムを呼び出すことと、
    前記呼び出された最適化アルゴリズムに基づいて前記イベント情報を最適化し、前記インフラごとに前記データを生成することとを含む、請求項１７乃至１９のいずれか１項に記載の制御方法。
21. さらに、前記装置が、前記送信されるデータに関して予め設定される単価に基づく課金データを管理する、請求項１７乃至２０のいずれか１項に記載の制御方法。
22. 前記サーバが、前記データを受信していない状態で前記インフラを自律的に制御することを含む、請求項１７乃至２１のいずれか１項に制御方法。
23. 請求項１７乃至２２のいずれか１項に記載の方法をコンピュータに実行させるための命令を含む、プログラム。