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

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）もこの種のネットワークの範疇に含めることが可能である。もちろん、通信網ＮＷを社会インフラに含めることも可能である。通信網ＮＷの回線は、例えば下位層から上位層へのイベント情報の送信（アップロード）にかかるリアルタイム性を保証可能である。

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

コミュニティに関連づけて設けられた市クラウド３００の社会インフラ５１〜５ｎは、それぞれセンサ５０ａおよびアクチュエータ５０ｂを備える。センサ５０ａは、例えば各社会インフラに固有のイベント情報を検知する。あるいは、センサ５０ａは、複数の社会インフラに関係するイベント情報を検知する。要するにセンサ５０ａは社会インフラの状態を検知して数値化、あるいはデータ化可能な手段であればどのようなものでも良く、監視カメラなどもその範疇に含めることが可能である。

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

市ＭＳ３０は、実施形態に係る処理機能として制御部３０ａ、収集部３０ｂ、アップロード部３０ｃ、算出部３０ｄ、選択部３０ｅ、ダウンロード部３０ｆ、作成部３０ｇ、および設定部３０ｈを備える。
制御部３０ａは、例えば国ＭＳ１０あるいは県ＭＳ６０から与えられた制御データ、あるいは自ら生成した制御データに基づいてアクチュエータ５０ｂに制御指示を与え、社会インフラ５１〜５ｎを制御する。制御指示としては、例えば水インフラにおけるバルブの開度、あるいは公共インフラにおける空調制御用インバータの回転数などを制御するための、制御信号が挙げられる。
制御部３０ａはソフトウェアに基づいて社会インフラ５１〜５ｎを制御する。つまり市ＭＳ３０は当該ソフトウェアを備えるコンピュータである。なお、市クラウド３００に備わる処理機能として市ＭＳ３０を実装することも可能である。

収集部３０ｂは、センサ５０ａにより検知されたイベント情報を収集する。データ収集に係わる通信プロトコルとしては、ＥＣＨＯＮＥＴ（登録商標）、ＥＣＨＯＮＥＴ Ｌｉｔｅ（登録商標）、ＺｉｇＢｅｅ（登録商標）、Ｚ−Ｗａｖｅ（登録商標）、ＫＮＸ（登録商標）などを使用することが可能である。下位レイヤの通信層としてはイーサネット（登録商標）などの有線ＬＡＮ、電力線通信、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）などを使用することが可能である。

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

イベント情報は、例えばＩＰパケットのペイロードに書き込まれて通信網ＮＷに送出される。このＩＰパケットには宛先アドレスとして例えばマルチキャストアドレスが記載される。国ＭＳ１０、および県ＭＳ６０は、このＩＰパケットを受信することでイベント情報を収集することが可能である。

算出部３０ｄは、収集部３０ｂにより収集されたイベント情報を解析し、社会インフラ５１〜５ｎの特性を算出する。社会インフラの特性とは例えば立地条件、環境条件、運用条件、その他種々の、数値化することの可能な情報である。要するに社会インフラの特性を表すことの可能な情報であればどのようなものでも良い。

例えば海の近くに形成される社会インフラと、山村部に形成される社会インフラとでは当然、環境面での条件が異なる。例えば気温の変動や日照量、月ごとの平均降雨量などがそれぞれ異なるので、イベント情報にもそのことが反映される。例えば日照量の多い地域では太陽光発電システムの発電量が他の地域よりも多いことが予想されるので、エネルギー消費を最適化するためのソフトウェアには、そのことを反映する性能を特別に持たせる必要がある。

あるいは、降雨量の多い地域や近くにダムなどがある地域では、水インフラを制御するためのソフトウェアに、他の地域とは異なる性能を期待される。算出部３０ｄは収集したイベント情報を解析することにより、社会インフラごとの、あるいはコミュニティごとの特性を算出する。

あるいは算出部３０ｄは、収集部３０ｂにより収集されたイベント情報を解析し、社会インフラ５１〜５ｎそれ自体の特性、あるいは社会インフラ５１〜５ｎの対象とする領域（ドメイン）の特性を算出する。
社会インフラの対象領域とは、例えばそれぞれのインフラが制御の対象、あるいは管理の対象とする社会的な領域を意味する概念である。例えば電力インフラであれば各家庭における電力消費量やそれに基づく配電制御、電力生産量、あるいは配電ネットワークの状態などがこれに相当する。特に、社会インフラを備える地域社会を、当該社会インフラ制御システムの対象領域と捉えることが可能である。

対象領域の特性とは、例えば電力インフラにおいては電力消費量の特性、傾向などを意味し、例えばＰＶシステムの設置台数の増加に伴う戸別生産電力の増加の傾向や、逆潮流電力の量などの概念がこれに相当する。社会インフラの対象領域の特性は、地域社会の特性としても捉えることが可能であり、社会インフラそのものの特性と密接に関係すると捉えることも可能である。

選択部３０ｅは、算出部３０ｄにより算出された特性に応じたソフトウェアモジュールを、国クラウド１００のデータベース２０に蓄積されるソフトウェアモジュール群２０ｂから選択する。つまり社会インフラの特性、あるいは社会インフラの対象領域の特性に応じたソフトウェアモジュールが選択される。つまり、社会インフラに適したソフトウェアモジュールが選択される。特に選択部３０ｅは、時間の経過などに伴う特性の変化に応じて、ソフトウェアモジュールの選択を定期的に、あるいは不定期に繰り返し実行する。

ダウンロード部３０ｆは、選択部３０ｅにより選択されたソフトウェアモジュールを、データベース２０から通信網ＮＷの回線を介して市ＭＳ３０にダウンロードする。つまりソフトウェアモジュールを、データベース２０から通信網ＮＷの回線を介して取得する。作成部３０ｇは、ダウンロードされたソフトウェアモジュールを組み合わせて、制御部３０ａのソフトウェアを作成する。ここで言う作成は、アプリケーション開発におけるコンパイル（compile）、あるいはビルド（build）と共通する概念である。

特に作成部３０ｇは、例えば選択部３０ｅによりソフトウェアモジュールの選択が実施されると、そのたびごとにダウンロードされたソフトウェアモジュールにより、ソフトウェアを更新（アップデート）する。

設定部３０ｈは、選択されたソフトウェアモジュールのパラメータを、上記算出された特性に応じて設定する。つまり、多くのソフトウェアモジュールは、当該ソフトウェアモジュールの機能を調整可能なパラメータを備える。設定部３０ｈはこのパラメータを操作して、ソフトウェアを地域社会の特性にマッチさせる。

データベース４０はイベント情報４０ａを蓄積する。このうちイベント情報４０ａはセンサ５０ａで検知された情報である。つまり市ＭＳ３０は自ら収集したイベント情報４０ａを国ＭＳ１０に送信するとともに、ローカルにおいても蓄積する。

国ＭＳ１０は、市ＭＳ３０に、通信網ＮＷの回線を介して接続され、制御装置としての市ＭＳ３０に対するサーバとしての位置付けにある。国ＭＳ１０も、プログラムにより機能するコンピュータ、あるいは国クラウド１００により提供される処理機能である。国ＭＳ１０は、実施形態に係る処理機能として取得部１０ａ、および送信部１０ｂを備える。

取得部１０ａは、市ＭＳ３０から送信されたイベント情報を取得する。取得されたイベント情報はデータベース２０にイベント情報２０ａとして蓄積される。このイベント情報２０ａは複数の市クラウド３００（図２）から送信されたイベント情報の全てを集中的に蓄積したものである。

送信部１０ｂは、市ＭＳ３０から要求されたソフトウェアモジュールを市ＭＳ３０に送信する。

データベース２０は、イベント情報２０ａに加えてソフトウェアモジュール群２０ｂを蓄積する。周知のようにソフトウェアモジュールは、１つのソフトウェアを作成するためのいわば部品であり、プラグインモジュールなどとも共通するオブジェクトあるいはエンティティである。

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

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

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

図６は、図３に示されるソフトウェアモジュール群２０ｂの一例を示す図である。ソフトウェアモジュール群２０ｂはそれぞれ固有の機能を提供する複数のソフトウェアモジュール（以下、モジュールと略記する）を含む。各モジュールの実態は特定の言語で記述されたコード列であっても良いし、機械語レベルにまでデコードされたバイナリデータ、あるいはこれを暗号化したデータであっても良い。

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

各モジュールはそのベンダ（提供者）により更新あるいはバージョンアップされる。これによりソフトウェアモジュール群２０ｂは逐次拡充される。各モジュールのベンダは、モジュールがダウンロードされるごとに相応の課金をサービス受益者に課すことで利益を得るといったビジネスモデルを構築することが可能である。

各モジュールによりどのような機能が提供されるかという情報や、各モジュールを個別に特定するための通し番号、更新履歴などは、一覧表やＸＭＬデータなどの形式で市ＭＳ３０に通知される。市ＭＳ３０は、この通知された内容から、ダウンロードすべきモジュールを特定することが可能である。

図７は、市ＭＳ３０の要部の一例を示す機能ブロック図である。市ＭＳ３０は、通信網ＮＷの回線に接続可能なインタフェース部、ユーザ（オペレータ）とのヒューマンマシンインタフェースを担う表示部３４および入出力部３６、ハードディスクドライブなどのストレージユニット３５を備える。なお市ＭＳ３０は、通信網ＮＷの回線に接続されていないスタンドアロンの状態でも、実施形態に係る機能を備えることが可能である。

さらに市ＭＳ３０は、制御部３０ａ（図３）およびプログラムメモリ３２を備える。制御部３０ａはソフトウェア３１によりその機能を果たす。ソフトウェア３１は複数のモジュールを組み合わせて作成される。モジュールはプログラムメモリ３２にロードされ、図示しないＣＰＵ（Central Processing Unit）による演算処理のもとでソフトウェア３１の機能を実現する。

図８は、第１の実施形態における市ＭＳ３０の処理手順の一例を示すフローチャートである。図８において市ＭＳ３０は、センサ５０ａにより検知されたイベント情報を収集する（ステップＳ１）。次に市ＭＳ３０は、収集したイベント情報を解析し（ステップＳ２）、その結果に基づいて、社会インフラ５１〜５ｎの特性を算出する（ステップＳ３）。

次に市ＭＳ３０は、前記算出した特性に応じたモジュールを、例えば、予め通知される一覧表（図６に示されるソフトウェアモジュール群２０ｂ）から選択する（ステップＳ４）。次に市ＭＳ３０は、選択したモジュールの送信を、通信網ＮＷの回線を介して国クラウド１００に要求する。そして市ＭＳ３０は、選択したモジュールを、国クラウド１００のデータベース２０から取得する（ステップＳ５）。そして市ＭＳ３０は、取得したモジュールを組み合わせ、コンパイルやビルドなどの処理を行ってソフトウェア３１を作成する（ステップＳ６）。

作成されたソフトウェア３１は、市ＭＳ３０に対して別途設けられる、冗長コンピュータにインストールされる。そして、現用で稼働中のコンピュータからのデータの引継ぎやアドレス変更の処理などが完了したのち、冗長コンピュータを有効にすることで、サービスの中断を伴わずにソフトウェアが更新される。

図９は、実施形態に開示される概念の要点を模式的に示す図である。実施形態においては、社会システムごとにその管理・制御対象を分析することで水、熱、あるいは電気などの複数のソリューションからなる要素技術群を抽出する。そして、ソリューションごとにモジュールが蓄積される。

一方、各コミュニティ（コミュニティＡ〜コミュニティＥ）はそれぞれクラウド化されて、行政や、ベンダに属する上位クラウドに対する下位クラウドとして機能する。コミュニティは千差万別であり、多種多様な特性を持つので、必要とされるソリューションも異なる。

そこで、算出部により社会インフラの特性を算出し、これによりコミュニティの求めるソリューションを把握し、それに応じたモジュールを各クラウドにダウンロードする。これにより、いわばテイラーメイドするようにソフトウェアを作成することが可能になる。

すなわち、センサ５０ａで検知されたイベント情報をそのまま国ＭＳ１０に送信して集中的に蓄積するとともに、市ＭＳ３０においてもローカルに保持する。このイベント情報を解析して社会インフラごとの特性を算出し、その結果に応じたモジュールを選択して市ＭＳ３０にダウンロードする。そして、ダウンロードしたモジュールを組み合わせることで、社会インフラを制御するためのソフトウェアを作成するようにしている。

このようにしたので、各コミュニティでの社会システムの管理、運営に欠かせないソフトウェアをテイラーメイドするように提供できる。

しかも第１の実施形態によれば、社会システムの変化にも柔軟に対処することが可能である。つまり時々刻々と収集されるイベント情報を解析して社会インフラの特性を算出し、これを繰り返すことで社会システムの発展あるいは縮小に応じてソフトウェアをバージョンアップしてゆくことが可能になる。例えば、コミュニティの発展につれ住民の人口が増え、世帯数が増加してくると、ＰＶシステムの設置台数が増えたりして相応の制御が必要になってくる。

逆に、人口が減るとそれまでに必要であった制御が不要になったり、高齢者が増えてくると医療分野でのサービスを充実させるといった新たな需要が喚起されることもある。このような社会システムの変化は、イベント情報の解析結果に基づく閾値判定などによりマシンの側で判定することが可能である。よってこの変化を検出し、社会システムの変化に追従してソフトウェアをバージョンアップしてゆくことで、人的介入に伴うオペレータの負担を最小限に抑えながらも社会システムを最適に制御してゆくことが可能になる。

［第２の実施形態］
図１０は、第２の実施形態に係る社会インフラ制御システムの一例を示す機能ブロック図である。図１０において図３と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。
図１０に示されるシステムは、社会インフラの特性を解析する機能、およびモジュールを選択する機能を国クラウド１００の国ＭＳ１０に備えるようにしたものである。

すなわち国ＭＳ１０は、収集部１０ｃ、算出部１０ｄ、選択部１０ｅ、ダウンロード部１０ｆ、および設定部１０ｇを備える。市ＭＳ３０は、制御部３０ａ、アップロード部３０ｃおよび作成部３０ｇを備える。

収集部１０ｃは、市ＭＳ３０から送信されるイベント情報を通信網ＮＷの回線を介して収集し、データベース２０に蓄積する。算出部１０ｃは蓄積したイベント情報を解析して社会インフラ５１〜５ｎの特性を算出する。選択部１０ｅは算出された特性に応じてモジュールを選択し、ダウンロード部１０ｆは選択されたモジュールを通信網ＮＷの回線を介して市ＭＳ３０にダウンロードする。設定部１０ｇはモジュールのパラメータを調整する。

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

図１１は、第２の実施形態における国ＭＳ１０の処理手順の一例を示すフローチャートである。図１１において国ＭＳ１０は、市ＭＳ３０において取得されたイベント情報を、通信網ＮＷの回線を介して収集する（ステップＳ１１）。次に国ＭＳ１０は、収集したイベント情報を解析し（ステップＳ１２）、その結果に基づいて、社会インフラ５１〜５ｎの特性を算出する（ステップＳ１３）。

次に国ＭＳ１０は、前記算出した特性に応じたモジュールを、データベース２０のソフトウェアモジュール群２０ｂから選択する（ステップＳ１４）。そして国ＭＳ１０は、選択したモジュールをデータベース２０から取得し、通信網ＮＷの回線を介して市ＭＳ３０に送信する（ステップ１５）。モジュールを受信した市ＭＳ３０は、作成部３０ｇによりソフトウェア３１を作成する。

上記構成によれば、最適なモジュールの組み合わせが国ＭＳ１０において選択される。つまり市クラウド３００で検知されたイベント情報が国クラウド１００に集められ、国クラウド１００において必要な演算が実行される。これにより第１の実施形態と同様の効果に加え、市クラウド３００の処理負荷を軽減できるようになる。

また第１の実施形態では市ＭＳ３０が主体的に、モジュールの送信を国クラウド１００に要求した。これに代えて第２の実施形態では、国ＭＳ１０が主体となってモジュールを選択し、市クラウド３００に送信するようにしている。これにより、いわばプッシュ型のサービスを提供することが可能になる。

［第３の実施形態］
図１２は、第３の実施形態に係る社会インフラ制御システムを示す図である。図１２において図１０と共通する部分には同じ符号を付して示し、ここでは主に異なる部分について説明する。

第３の実施形態では、社会インフラの制御、管理、あるいは運営に係わるサービスの一例について、より詳しく説明する。第３の実施形態では、社会インフラを制御するためのソフトウェアを提供する事業者の存在を考慮する。この事業者をベンダと総称する。

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

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

第３の実施形態では、ベンダＭＳ８０がサーバとしての位置付けにあり、市ＭＳ３０が制御装置としての位置付けにある。

ベンダＭＳ８０は、実施形態に係る機能ブロックとして、収集部１０ｃ、算出部１０ｄ、選択部１０ｅ、作成部３０ｇ、ダウンロード部１０ｆ、カウンタ８０ａ、料金管理部８０ｂ、および、設定部１０ｇを備える。データベース９０は、イベント情報２０ａと、ソフトウェアモジュール群２０ｂとを記憶することが可能である。

第３の実施形態では特に、ソフトウェアモジュール毎に、例えばベンダによって予め単価が設定される。この単価は例えば図１３（後述）に示されるユニットごとに、またはサービス内容に応じて、あるいはサービスのランクに応じて設定されることが可能である。もちろん、無料という単価が設定されることも可能である。

ベンダＭＳ８０の収集部１０ｃは、センサ５０ａにより検知されたイベント情報２０ａを市ＭＳ３０から通信網ＮＷの回線を介して収集し、データベース９０に保存する。なお国ＭＳ１０の収集部１０ｃも、市ＭＳ３０から送信されたイベント情報２０ａを通信網ＮＷの回線を介して取得し、データベース２０に蓄積する。

算出部１０ｄはイベント情報２０ａを解析し、社会インフラ５１〜５ｎの特性を算出する。例えば、イベント情報に係わる社会インフラが電力インフラであれば、算出部１０ｄは、電力インフラの設置される地域の特性、各家庭における電力消費量やそれに基づく配電制御、電力生産量、あるいは配電ネットワークの状態などを算出する。

選択部１０ｅは、データベース９０のソフトウェアモジュール群２０ｂから、社会インフラ５１〜５ｎの特性に適するモジュールを選択する。例えば、対象とする電力インフラが都市部にあれば、例えばデマンドレスポンス制御に適するモジュールが選択される。電力インフラが晴天日の多い地域にあれば、ＰＶシステムの逆潮流制御機能を備えるモジュールが選択される場合がある。このように、社会インフラの特性に適するモジュールがソフトウェアモジュール群２０ｂから選択される。

作成部３０ｇは、選択されたモジュールに基づいて、市ＭＳ３０の制御部３０ａにインストールすることの可能なソフトウェアを作成する。すなわち作成部３０ｇは、選択部１０ｅにより選択された複数のモジュールを組み合わせ、コンパイル／リンク／ビルド、あるいはそれに類する処理を施してソフトウェアを作成する。その際、設定部１０ｇによりモジュールのパラメータを調整することも可能である。

ダウンロード部１０ｆは、作成されたソフトウェアを、通信網ＮＷの回線を介して市ＭＳ３０に送信する。すなわちダウンロード部１０ｆは、当該ソフトウェアのバイナリデータを例えば圧縮ファイルにエンコードし、市ＭＳ３０のＩＰアドレスを付与して生成したＩＰパケットを通信網ＮＷの回線に送出する。

カウンタ８０ａは、ソフトウェアが市ＭＳ３０にダウンロードされた量をカウントする。ここでいう“量”とは、ダウンロードされた数、データサイズ、バイト数など、定量的にカウント可能で課金の拠りどころとなるべき量であればどのような量であっても良い。

料金管理部８０ｂは、カウンタ８０ａによりカウントされた量を取得し、選択されたモジュールの単価に基づいて課金データ９０ａを算出する。課金データ９０ａは例えば市町村ごとにテーブル化されて管理されることが可能である。この課金データ９０ａはベンダＭＳ８０の記憶部（図示せず）、あるいはデータベース９０に記憶される。この課金データ９０ａは、例えば市ＭＳ３０の運営事業体（地方自治体など）や、住民などの受益者に課金する際に用いられ、ベンダにとっては収入源となる情報である。

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

受信部１ａは、ベンダＭＳ８０から市ＭＳ３０宛に送信されたＩＰパケットを受信する。そして市ＭＳ３０は、受信したＩＰパケットのペイロードからソフトウェアの圧縮ファイルを抽出し、この圧縮ファイルをデコードしてソフトウェアを再生して自らにインストールする。制御部３０ａは、このソフトウェアによる制御のもとで社会インフラ５１〜５ｎを制御する。

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

図１３は、図１２に示されるソフトウェアモジュール群２０ｂの一例を示す図である。ソフトウェアモジュール群２０ｂはそれぞれ固有の機能を提供する複数のソフトウェアモジュール（モジュールと略記する）を含む。各モジュールの実態は特定の言語で記述されたコード列であっても良いし、機械語レベルにまでデコードされたバイナリデータ、あるいはこれを暗号化したデータであっても良い。

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

各モジュールは、図示しないベンダ（提供者）の端末により更新あるいはバージョンアップされる。これによりソフトウェアモジュール群２０ｂは逐次拡充される。各モジュールのベンダは、モジュールがダウンロードされるごとに相応の課金をサービス受益者に課すことで利益を得るといったビジネスモデルを構築することが可能である。

各モジュールによりどのような機能が提供されるかという情報や、各モジュールを個別に特定するための通し番号、更新履歴などは、一覧表やＸＭＬデータなどの形式で市ＭＳ３０に通知される。市ＭＳ３０は、この通知された内容から、ダウンロードすべきモジュールを特定することが可能である。

図１４は、市ＭＳ３０の要部の一例を示す機能ブロック図である。市ＭＳ３０は、通信網ＮＷの回線に接続可能なインタフェース部、ユーザ（オペレータ）とのヒューマンマシンインタフェースを担う表示部３４および入出力部３６、ハードディスクドライブなどのストレージユニット３５を備える。なお市ＭＳ３０は、通信網ＮＷの回線に接続されていないスタンドアロンの状態でも、実施形態に係る機能を備えることが可能である。

さらに市ＭＳ３０は、制御部３０ａ（図１２）およびプログラムメモリ３２を備える。制御部３０ａはソフトウェア３１によりその機能を果たす。ソフトウェア３１は複数のモジュールを組み合わせて作成される。モジュールはプログラムメモリ３２にロードされ、図示しないＣＰＵ（Central Processing Unit）による演算処理のもとでソフトウェア３１の機能を実現する。

図１５は、第３の実施形態におけるベンダＭＳ８０の処理手順の一例を示すフローチャートである。図１５においてベンダＭＳ８０は、市ＭＳ３０において取得されたイベント情報を、通信網ＮＷの回線を介して収集する（ステップＳ２１）。次にベンダＭＳ８０は、収集したイベント情報を解析し（ステップＳ２２）、その結果に基づいて、社会インフラ５１〜５ｎの特性を算出する（ステップＳ２３）。

次にベンダＭＳ８０は、前記算出した特性に応じたモジュールを、データベース９０のソフトウェアモジュール群２０ｂから選択する（ステップＳ２４）。そしてベンダＭＳ８０は、選択したモジュールをデータベース２０から取得し、取得したモジュールを組み合わせ、コンパイルやビルドなどの処理を行ってソフトウェア３１を作成する（ステップＳ２５）
次にベンダＭＳ８０は、作成したソフトウェア３１を通信網ＮＷの回線を介して市ＭＳ３０にダウンロード送信する（ステップＳ２６）。そしてベンダＭＳ８０は、ソフトウェア３１が市ＭＳ３０にダウンロードされた量をカウントし（ステップＳ２７）、カウント値に基づいて課金データ９０ａを算出する（ステップＳ２８）。

このように第３の実施形態によれば、ソフトウェアベンダにより、ソフトウェアモジュール群２０ｂと、社会インフラ制御のためのソフトウェアが提供される。そして、モジュール、あるいはソフトウェアがダウンロードされるたびに課金データが算出され、この課金データはソフトウェアの受益者ごとに管理される。これによりベンダは、ソフトウェアを提供する見返りに受益者から料金を徴収することが可能になる。従ってベンダにソフトウェアを開発する動機を与えることが可能になり、サービスを順次拡充していくことが可能になる。

また、操作者（ベンダに属するオペレータなど）は、リモート端末（図示せず）などから通信網ＮＷの回線を介してベンダＭＳ８０にアクセスして、種々の処理を実施することが可能である。例えばセキュリティ認証にパスしたオペレータは、ベンダＭＳ８０のデータベース９０から課金データ９０ａを取り出すことが可能である。この課金データ９０ａは顧客別課金データや累積課金データなどに加工され、リモート端末の画面に表示することができる。あるいは、課金データ９０ａを印刷して出力したり、ＣＳＶ形式などのデータに変換して出力することも可能である。

またオペレータは、データベース９０に既に記憶されているモジュールの更新バージョンや改良バージョン、あるいは新たに開発されたモジュールを、リモート端末から通信網ＮＷの回線経由でアップロードすることもできる。このケースにおいても認証処理は必要になろうが、ソフトウェアモジュールをクラウドに置いておくことで、メインテナンスやバージョンアップにかかる種々のメリットが生まれることは明らかであろう。

［第４の実施形態］
第４の実施形態では、社会インフラを備えるコミュニティを制御の対象とする。コミュニティは、人々の暮らしを支えるエネルギーインフラ、水道インフラ、医療インフラなどの多様な社会インフラを備えている。快適性や安全性、省エネ性などを、インフラを統合制御することで実現するコミュニティは特に、スマートコミュニティと称される。

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

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

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

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

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

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

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

Ｍエリアは例えば超高層のオフィスビルが立ち並ぶビル街におけるコミュニティであり、Ｋエリアは例えば住宅街におけるコミュニティである。従ってＭエリアを制御するコンピュータ２、およびＫエリアを制御するコンピュータ２は、それぞれのコミュニティに適合（fit）する機能を持つソフトウェアを備える必要がある。

通信網ＮＷの回線には、第３の実施形態で説明したソフトウェアベンダ（ベンダクラウド５００）が接続される。各コンピュータ２にインストールされるソフトウェアは、ベンダにより提供される。

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

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

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

第４の実施形態では、ベンダＭＳ８０がサーバとしての位置付けにあり、事業者ＭＳ１が制御装置としての位置付けにある。

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

ベンダクラウド５００のベンダＭＳ８０は、実施形態に係る機能ブロックとして、収集部１０ｃ、算出部１０ｄ、選択部１０ｅ、作成部８０ｃ、ダウンロード部１０ｆ、カウンタ８０ａ、料金管理部８０ｂ、設定部１０ｇ、および、更新部８０ｄを備える。データベース９０は、イベント情報２０ａと、ソフトウェアモジュール群２０ｂと、課金データ９０ａを記憶することが可能である。

第４の実施形態では特に、各ソフトウェアモジュールに、例えばベンダによって予め単価が設定される。この単価は例えば図２０（後述）に示されるユニットごとに、またはサービス内容に応じて、あるいはサービスのランクに応じて設定されることが可能である。もちろん、無料という単価が設定されることも可能である。

収集部１０ｃは、センサ５０ａにより検知されたイベント情報２０ａを事業者ＭＳ１から通信網ＮＷの回線を介して収集し、データベース９０に保存する。
算出部１０ｄはイベント情報２０ａを解析し、社会インフラ５１〜５ｎを備えるコミュニティ７００の特性を算出する。

例えば、イベント情報に係わる社会インフラが電力インフラおよび医療インフラであれば、算出部１０ｄは、発電所、変電所、電力グリッドおよび病院などの設置される住所、これらのインフラの設置される地域の特性、住民の年齢構成、病院における電力消費量、あるいは優先的に電力を配分すべき病院に至る配電ネットワークの状態などを算出する。

選択部１０ｅは、データベース９０のソフトウェアモジュール群２０ｂから、コミュニティ７００の特性に適するモジュールを選択する。例えば、対象とするコミュニティがＭエリア（図１７）であれば、例えばＢＥＭＳ向けのデマンドレスポンスに適するモジュールが選択される。対象とするコミュニティがＫエリアであれば、例えばＨＥＭＳ向けのデマンドレスポンス制御や戸別ＰＶシステムの制御に適するモジュールが選択される。このように、コミュニティの特性に適するモジュールがソフトウェアモジュール群２０ｂから選択される。

作成部８０ｃは、選択されたモジュールに基づいて、事業者ＭＳ１の制御部３０ａにインストールすることの可能なソフトウェアを作成する。すなわち作成部８０ｃは、第１の実施形態乃至第３の実施形態と同様に、複数のモジュールを組み合わせ、コンパイル／リンク／ビルド、あるいはそれに類する処理を施してソフトウェアを作成する。その際、設定部１０ｇによりモジュールのパラメータを調整することも可能である。

ダウンロード部１０ｆは、作成されたソフトウェアを、通信網ＮＷの回線を介して事業者ＭＳ１に送信する。すなわちダウンロード部１０ｆは、当該ソフトウェアのバイナリデータを例えば圧縮ファイルにエンコードし、事業者ＭＳ１のＩＰアドレスを付与して生成したＩＰパケットを通信網ＮＷの回線に送出する。

カウンタ８０ａは、ソフトウェアが市ＭＳ３０にダウンロードされた量をカウントする。ここでいう“量”とは、ダウンロードされた数、データサイズ、バイト数など、定量的にカウント可能で課金の拠りどころとなるべき量であればどのような量であっても良い。

料金管理部８０ｂは、カウンタ８０ａによりカウントされた量を取得し、ダウンロードされたパケットのバイト数や、選択されたモジュールの単価に基づいて課金データ９０ａを算出する。

課金データ９０ａは例えば事業者あるいはコミュニティごとにテーブル化されて管理されることが可能である。この課金データ９０ａはベンダＭＳ８０の記憶部（後述）、あるいはデータベース９０に記憶される。この課金データ９０ａは、例えばコミュニティの運営事業体やコミュニティの住民などの受益者に課金する際に用いられ、ベンダにとっては収入源となる情報である。

更新部８０ｄは、算出部１０ｄにより算出された特性の変化に応じて事業者ＭＳ１のソフトウェアをアップデートする。すなわち更新部８０ｄは、社会インフラ５１〜５ｎの特性、あるいはコミュニティ７００の特性の変化に応じて事業者ＭＳ１のソフトウェアをアップデートする。

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

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

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

図１８に戻り、事業者ＭＳ１の受信部１ａは、ベンダＭＳ８０から事業者ＭＳ１宛に送信されたＩＰパケットを受信する。そして事業者ＭＳ１は、受信したＩＰパケットのペイロードからソフトウェアの圧縮ファイルを抽出し、この圧縮ファイルをデコードしてソフトウェアを再生して自らにインストールする。制御部３０ａは、このソフトウェアによる制御のもとでコミュニティ７００を制御する。

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

図２０は、図１８に示されるソフトウェアモジュール群２０ｂの一例を示す図である。ソフトウェアモジュール群２０ｂはそれぞれ固有の機能を提供する複数のソフトウェアモジュール（モジュール）を含む。各モジュールの実態は特定の言語で記述されたコード列であっても良いし、機械語レベルにまでデコードされたバイナリデータ、あるいはこれを暗号化したデータであっても良い。

各モジュールには区別のため、例えば通し番号が与えられる。また各モジュールは、例えば都市型コミュニティ、農山漁村型コミュニティ、ショッピングモール型コミュニティ、あるいはオフィス型コミュニティといった、異なるタイプのコミュニティに対応するソリューションごとにユニット化されて管理される。
さらに、ユニットごとに、例えばサービスの内容に応じてＳ，Ａ，Ｂ，…のランクを設定し、ランクごとにモジュールをまとめて管理することも可能である。このような階層化構造は多岐にわたるモジュールを管理するのに都合が良い。

各モジュールは、ベンダやソフトウェア開発者などにより更新あるいはバージョンアップされる。これによりソフトウェアモジュール群２０ｂは逐次拡充される。各モジュールのベンダは、モジュールがダウンロードされるごとに相応の課金をサービス受益者に課すことで利益を得るといったビジネスモデルを構築することが可能である。

各モジュールによりどのような機能が提供されるかという情報や、各モジュールを個別に特定するための通し番号、更新履歴などは、一覧表やＸＭＬデータなどの形式で市ＭＳ３０に通知される。事業者ＭＳ１は、この通知された内容から、ダウンロードすべきモジュールを特定することが可能である。

図２１は、事業者ＭＳ１の要部の一例を示す機能ブロック図である。事業者ＭＳ１は、通信網ＮＷの回線に接続可能なインタフェース部、ユーザ（オペレータ）とのヒューマンマシンインタフェースを担う表示部３４および入出力部３６、ハードディスクドライブなどのストレージユニット３５を備える。なお事業者ＭＳ１は、通信網ＮＷの回線に接続されていないスタンドアロンの状態でも、実施形態に係る機能を備えることが可能である。

さらに事業者ＭＳ１は、制御部３０ａ（図１８）およびプログラムメモリ３２を備える。制御部３０ａはソフトウェア３１によりその機能を果たす。ソフトウェア３１は複数のモジュールを組み合わせて作成される。モジュールはプログラムメモリ３２にロードされ、図示しないＣＰＵ（Central Processing Unit）による演算処理のもとでソフトウェア３１の機能を実現する。

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

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

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

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

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

図２３は、第４の実施形態におけるベンダＭＳ８０の処理手順の一例を示すフローチャートである。図２３においてベンダＭＳ８０は、事業者ＭＳ１において取得されたイベント情報を、図１９に示されるＩＰパケットを受信することにより、通信網ＮＷの回線を介して収集する（ステップＳ３１）。次にベンダＭＳ８０は、収集したイベント情報を解析し（ステップＳ３２）、その結果に基づいて、社会インフラ５１〜５ｎを含むコミュニティの特性を算出する（ステップＳ３３）。

次にベンダＭＳ８０は、前記算出した特性に応じたモジュールを、データベース９０のソフトウェアモジュール群２０ｂから選択する（ステップＳ３４）。そしてベンダＭＳ８０は、選択したモジュールをデータベース２０から取得し、取得したモジュールを組み合わせ、コンパイルやビルドなどの処理を行ってソフトウェア３１を作成する（ステップＳ３５）
次にベンダＭＳ８０は、作成したソフトウェア３１を通信網ＮＷの回線を介して事業者ＭＳ１にダウンロード送信する（ステップＳ３６）。そしてベンダＭＳ８０は、ソフトウェア３１が事業者ＭＳ１にダウンロードされた量をカウントし（ステップＳ３７）、カウント値に基づいて課金データ９０ａを算出する（ステップＳ３８）。

以上の手順は不定期的に、あるいは定期的に繰り返し実行されることが可能である。すなわち、時間の経過などに伴うコミュニティ特性の変化に応じて、事業者ＭＳ１のソフトウェアは不定期的に、あるいは定期的に更新される。

以上述べたように第４の実施形態によれば、ベンダＭＳ８０によりコミュニティ７００の特性を算出し、その結果に基づいて、ベンダ８０においてソフトウェアを作成するようにしている。事業者ＭＳ１は作成されたソフトウェアを受信し、自らにインストールするだけで良いのでソフトウェアを作成するための機能を備える必要が無い。これにより、ベンダＭＳ８０側で、ソフトウェアのバージョンや課金データ、ライセンス情報などを一元的に管理することが容易になる。これによりシステムベンダ、およびコミュニティ７００の事業者の双方にとり有益な社会インフラ制御システムを構築することが可能になる。

つまり第４の実施形態によれば、ソフトウェアベンダにより、コミュニティ制御のためのソフトウェアが提供される。そして、ソフトウェアがダウンロードされるたびに課金データが算出され、この課金データはソフトウェアの受益者ごとに管理される。これにより、第３の実施形態と同様のインセンティブをベンダに与えることが可能になり、コミュニティに生活する市民はもとより、ソフトウェアベンダにとっても有益な社会インフラ制御システムを提供することが可能になる。

また第４の実施形態によれば、社会システムとしてのコミュニティの変化にも柔軟に対処することが可能である。つまり時々刻々と収集されるイベント情報を解析してコミュニティの特性を算出し、これを繰り返すことでコミュニティの発展あるいは縮小に応じてソフトウェアをバージョンアップしてゆくことが可能になる。

［第５の実施形態］
第５の実施形態は、第４の実施形態のベンダＭＳ８０における更新部８０ｄの作用を詳しく開示する。
図２４は、社会インフラおよびコミュニティの発展の一例を示す模式図である。例えばＫエリア（図１７）が形成された初期の段階では、図２４（ａ）に示されるように、需要家の数、あるいはスマートメータ５の数も、初期の状態に見合った数となる。スマートメータ５はイベント情報を取得するセンサ５０ａの一例である。スマートメータ５によれば、需要家ごとの電力需要、電力消費量、ＰＶシステムの発電量などが、イベント情報として取得される。

図２４（ａ）の状態からＫエリアのコミュニティが発展していくと、図２４（ｂ）に示されるように住宅および需要家の数が増え、これに伴ってスマートメータ５の数が増える。また、初期段階ではスマートメータ５を備えていない住宅にも、後付けでスマートメータ５が取り付けられることも考えられる。このようにコミュニティの発展に伴い、センサの数が増大してゆくことは明らかである。

そこで、ベンダＭＳ８０の更新部８０ｄは、例えば事業者ＭＳ１からの要求に応じて、あるいはイベント情報に記されるセンサＩＤの数を閾値判定して、事業者ＭＳ１のソフトウェアのアップデートの要否を判定する。
アップデートが必要であると判断すると、ベンダＭＳ８０はそれまでに蓄積したイベント情報を解析し、コミュニティの新たな特性を算出する。この特性に基づいてベンダＭＳ８０はソフトウェアモジュールをデータベースから取得し、新たなソフトウェアを作成して事業者ＭＳ１にダウンロード送信する。このように第４および第５の実施形態によればコミュニティの発展に伴ってソフトウェアがアップデートされるので、コミュニティの運営事業者、あるいは需要家のニーズに柔軟に対応することが可能になる。

［第６の実施形態］
図２５は、第６の実施形態に係る社会インフラ制御システムの一例を示す機能ブロック図である。図２５において図３と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。
図２５に示されるシステムは、コミュニティの特性を解析する機能、およびモジュールを選択する機能をコミュニティクラウド６００の事業者ＭＳ１に備えるようにしたものである。

すなわち事業者ＭＳ１は、制御部３０ａ、収集部３０ｂ、アップロード部３０ｃ、算出部３０ｄ、選択部３０ｅ、ダウンロード部３０ｆ、作成部３０ｇおよび設定部３０ｈを備える。ベンダＭＳ８０は、取得部１０ａおよび送信部１０ｂを備える。

第６の実施形態では、ベンダＭＳ８０がサーバとしての位置付けにあり、事業者ＭＳ１が制御装置としての位置付けにある。

制御部３０ａは、制御データに基づいてアクチュエータ５０ｂに制御指示を与え、社会インフラ５１〜５ｎを制御する。

収集部３０ｂは、センサ５０ａにより検知されたイベント情報を収集し、データベース４０に保存する。

アップロード部３０ｃは、センサ５０ａにより検知されたイベント情報を、ベンダクラウド５００のベンダＭＳ８０に、通信網ＮＷの回線を介して送信する。つまりアップロード部３０ｃは、イベント情報を通信網ＮＷの回線を介して送信する。

算出部１０ｄはイベント情報４０ａを解析し、社会インフラ５１〜５ｎを備えるコミュニティ７００の特性を算出する。

選択部３０ｅは、データベース９０のソフトウェアモジュール群２０ｂから、コミュニティ７００の特性に適するモジュールを選択する。

ダウンロード部３０ｆは、選択部３０ｅにより選択されたソフトウェアモジュールを、データベース９０から通信網ＮＷの回線を介して事業者ＭＳ１にダウンロードする。つまりソフトウェアモジュールを、データベース９０から通信網ＮＷの回線を介して取得する。作成部３０ｇは、ダウンロードされたソフトウェアモジュールを組み合わせて、制御部３０ａのソフトウェアを作成する。

特に作成部３０ｇは、例えば選択部３０ｅによりソフトウェアモジュールの選択が実施されると、そのたびごとにダウンロードされたソフトウェアモジュールにより、ソフトウェアを更新（アップデート）する。

設定部３０ｈは、選択されたソフトウェアモジュールのパラメータを、上記算出された特性に応じて設定する。設定部３０ｈはこのパラメータを操作して、ソフトウェアをコミュニティの特性にマッチさせる。

ベンダＭＳ８０の取得部１０ａは、事業者ＭＳ１から送信されたイベント情報を取得する。取得されたイベント情報はデータベース９０にイベント情報２０ａとして蓄積される。送信部１０ｂは、事業者ＭＳ１から要求されたソフトウェアモジュールを事業者ＭＳ１に送信する。

図２６は、第６の実施形態における事業者ＭＳ１の処理手順の一例を示すフローチャートである。図２６において事業者ＭＳ１は、センサ５０ａにより検知されたイベント情報を収集する（ステップＳ４１）。次に事業者ＭＳ１は、収集したイベント情報を解析し（ステップＳ４２）、その結果に基づいて、コミュニティ７００の特性を算出する（ステップＳ３）。

次に事業者ＭＳ１は、前記算出した特性に応じたモジュールを、例えば、予め通知される一覧表（図６に示されるソフトウェアモジュール群２０ｂ）から選択する（ステップＳ４４）。次に事業者ＭＳ１は、選択したモジュールの送信を、通信網ＮＷの回線を介してベンダＭＳ８０に要求する。そして事業者ＭＳ１は、選択したモジュールを、ベンダクラウド５００のデータベース９０から取得する（ステップＳ４５）。そして事業者ＭＳ１は、取得したモジュールを組み合わせ、コンパイルやビルドなどの処理を行ってソフトウェア３１を作成する（ステップＳ４６）。

第６の実施形態では、事業者ＭＳ１においてコミュニティ７００の特性を算出し、これによりコミュニティの求めるソリューションを把握し、それに応じたモジュールをベンダクラウド５００から取得する。これにより、いわばテイラーメイドするようにソフトウェアを作成することが可能になる。

すなわち、センサ５０ａで検知されたイベント情報をそのままベンダＭＳ８０に送信して集中的に蓄積するとともに、事業者ＭＳ１においてもローカルに保持する。このイベント情報を解析してコミュニティの特性を算出し、その結果に応じたモジュールを選択して事業者ＭＳ１にダウンロードする。そして、ダウンロードしたモジュールを組み合わせることで、社会インフラを制御するためのソフトウェアを作成するようにしている。

このようにしたので、各コミュニティでの社会システムの管理、運営に欠かせないソフトウェアをテイラーメイドするように提供できる。

なお本発明は上記実施の形態に限定されるものではない。例えば、算出部３０ｄ、１０ｄにより算出された社会インフラの特性や、算出結果に基づき選択されたモジュール、あるいは作成され得るソフトウェアの性能などを視覚化し、市ＭＳ３０の表示部３４に表示するようにしても良い。

また、ソフトウェアモジュールは、ソリューションごとに唯一のものを作成しても良いし、複数のソリューションで共用するようにしてもよい。

図２７は、ソフトウェアモジュール群の分類の一例を示す図である。例えば、ホーム、ビル、工場の複数のインフラを考える。ホームインフラは家庭およびマンションを含み、ビルインフラは高層ビル、低層ビル、インテリジェントビルを含み、工場インフラは大規模工場および小規模工場を含むとする。

例えば省コストを実現するモジュールは、家庭および低層ビルにおいて特にニーズが高いとする。このようなケースでは、省コスト用のモジュールを家庭と低層ビルとで共用することも可能である。同様に、省エネルギーを実現するためのモジュールは、例えばマンション、高層ビル、インテリジェントビル、および大規模工場で共用することが可能である。このように一つのモジュールを複数のソリューションで共用するようにすれば、モジュール開発にかかるコストや労力を低減できる。

また、ソフトウェアを作成するためのモジュールの組み合わせは、唯一通りとは限らない。例えば複数とおりのモジュールの組み合わせをマシン側で選択し、各組み合わせのもとで得られるソフトウェアの性能、提供可能なサービスなどを表示してオペレータに選択させるようにしても良い。このようにすればソフトウェアの作成にあたってオペレータの意思を介入させることが可能になる。このような形態は、特に行政サービスの提供者にとっては有用であるし、ニーズも高いであろう。

また、センサ５０ａで検知されたイベント情報は国クラウド１００、県クラウド２００、市クラウド３００、あるいはベンダクラウド５００、コミュニティクラウド６００のどこに蓄積されても良い。ソフトウェアモジュール群２０ｂ、算出部１０ｄ、選択部１０ｅ、設定部１０ｇ、収集部３０ｂ、算出部３０ｄ、選択部３０ｅ、作成部３０ｇ、設定部３０ｈ、カウンタ８０ａ、課金処理部８０ｂ、作成部８０ｃ、更新部８０ｄなどの機能ブロックについても同様に、システム内の場所を問うことなくインプリメントされることが可能である。すなわちこれらの機能ブロックは、コンピュータにより実行されるプログラム、あるいはコンピュータにより読み取り可能な記録媒体に記録されたプログラムとして実現されることが可能である。

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

Claims (22)

1. ソフトウェアに基づいてコミュニティの社会インフラを制御する制御装置と、
   複数のモジュールを記憶するデータベースと、
   前記社会インフラに関するイベントを検知しイベント情報を出力するセンサと、
   前記センサからのイベント情報を収集する収集部と、
   前記収集されたイベント情報を解析して前記社会インフラまたは前記コミュニティに係る地域の特性を算出する算出部と、
   前記算出された特性に応じたモジュールを前記データベースから選択する選択部と、
   前記選択されたモジュールに基づいて前記ソフトウェアを作成する作成部とを具備する、社会インフラ制御システム。
2. さらに、前記選択されたモジュールに予め設定される単価に基づく課金データを管理する管理部を具備する、請求項１に記載の社会インフラ制御システム。
3. 前記モジュールの少なくともいずれか１つは当該モジュールの機能を調整可能なパラメータを備え、
   さらに、前記選択されたモジュールが前記パラメータを備える場合に、前記算出された特性に応じて当該パラメータを設定する設定部を具備する、請求項１に記載の社会インフラ制御システム。
4. さらに、前記特性の変化に応じて前記ソフトウェアをアップデートする更新部を具備する、請求項１に記載の社会インフラ制御システム。
5. 複数のモジュールから作成されるソフトウェアに基づいてコミュニティの社会インフラを制御する制御装置と通信可能なサーバであって、
   センサにより検知された前記社会インフラに関するイベントに係るイベント情報を収集する収集部と、
   前記収集されたイベント情報を解析して前記社会インフラまたは前記コミュニティに係る地域の特性を算出する算出部と、
   複数のモジュールを記憶するデータベースから、前記算出された特性に応じたモジュールを選択する選択部とを具備する、サーバ。
6. さらに、前記選択されたモジュールに基づいて前記ソフトウェアを作成する作成部と、
   前記作成されたソフトウェアを前記制御装置に送信する送信部とを具備する、請求項５に記載のサーバ。
7. さらに、前記選択されたモジュールに予め設定される単価に基づく課金データを管理する管理部を具備する、請求項５に記載のサーバ。
8. 前記モジュールの少なくともいずれか１つは当該モジュールの機能を調整可能なパラメータを備え、
   さらに、前記選択されたモジュールが前記パラメータを備える場合に、前記算出された特性に応じて当該パラメータを設定する設定部を具備する、請求項５に記載のサーバ。
9. さらに、前記特性の変化に応じて前記ソフトウェアをアップデートする更新部を具備する、請求項５に記載のサーバ。
10. ソフトウェアに基づいてコミュニティの社会インフラを制御する制御装置であって、
    前記社会インフラに関するイベントに係るイベント情報を収集する収集部と、
    前記収集されたイベント情報を解析して前記社会インフラまたは前記コミュニティに係る地域の特性を算出する算出部と、
    サーバに前記特性を通知する通知部と、
    前記特性の通知に応じて前記サーバから送信される前記ソフトウェアまたはモジュールを受信する受信部とを具備する、制御装置。
11. さらに、受信した前記モジュールに基づいて前記ソフトウェアを作成する作成部を具備する、請求項１０に記載の制御装置。
12. さらに、前記特性の変化に応じて前記ソフトウェアのアップデートを前記サーバに要求する要求部を具備する、請求項１０に記載の制御装置。
13. コンピュータが、コミュニティの社会インフラに関するイベントを検知するセンサから出力されるイベント情報を収集し、
    コンピュータが、前記収集されたイベント情報を解析して前記社会インフラまたは前記コミュニティに係る地域の特性を算出し、
    コンピュータが、複数のモジュールを記憶するデータベースから、前記算出された特性に応じたモジュールを選択し、
    コンピュータが、前記選択されたモジュールに基づいてソフトウェアを作成し、
    コンピュータが、前記作成されたソフトウェアに基づいて社会インフラを制御する、制御方法。
14. コンピュータが、社会インフラに関するイベントを検知するセンサから出力されるイベント情報を収集し、
    コンピュータが、前記収集されたイベント情報を解析して前記社会インフラ、または前記社会インフラを有するコミュニティに係る地域の特性を算出し、
    コンピュータが、複数のモジュールを記憶するデータベースから、前記算出された特性に応じたモジュールを選択し、
    コンピュータが、前記選択されたモジュールから作成されるソフトウェアに基づいて社会インフラを制御する、制御方法。
15. さらに、コンピュータが、前記選択されたモジュールに予め設定される単価に基づく課金データを管理する、請求項１３および１４のいずれか１項に記載の制御方法。
16. 前記モジュールの少なくともいずれか１つは当該モジュールの機能を調整可能なパラメータを備え、
    さらに、コンピュータが、前記選択されたモジュールが前記パラメータを備える場合に、前記算出された特性に応じて当該パラメータを設定する、請求項１３および１４のいずれか１項に記載の制御方法。
17. さらに、コンピュータが、前記特性の変化に応じて前記ソフトウェアをアップデートする、請求項１３および１４のいずれか１項に記載の制御方法。
18. コンピュータにより実行されるプログラムであって、
    前記プログラムは、
    コミュニティの社会インフラに関するイベントを検知するセンサから出力されるイベント情報を収集し、
    前記収集されたイベント情報を解析して前記社会インフラまたは前記コミュニティに係る地域の特性を算出し、
    複数のモジュールを記憶するデータベースから、前記算出された特性に応じたモジュールを選択する、プログラム。
19. さらに、選択されたモジュールに基づいて、コミュニティの社会インフラを前記コンピュータが制御するためのソフトウェアを作成する、請求項１８に記載のプログラム。
20. さらに、前記選択されたモジュールに予め設定される単価に基づく課金データを管理する、請求項１８に記載のプログラム。
21. 前記モジュールの少なくともいずれか１つは当該モジュールの機能を調整可能なパラメータを備え、
    さらに、前記選択されたモジュールが前記パラメータを備える場合に、前記算出された特性に応じて当該パラメータを設定する、請求項１８に記載のプログラム。
22. さらに、前記特性の変化に応じて前記ソフトウェアをアップデートする、請求項１９に記載のプログラム。

Images