WO2012173189A1 - 情報統合制御システムと情報処理プログラム、社会インフラ運用システム、運用方法、ローカル装置、サーバ装置およびプログラム - Google Patents

Abstract

　社会インフラ１２Ａ，１２Ｂ，…、行政用サーバ１３から電力需要予測情報、交通渋滞情報、事故発生情報、気象情報等を収集し、住民用サーバ１４から家屋内各種センサ（電気メータ、ガスメータ、保安センサ）等の住民情報を収集してデータベース１１５にＫＶＳ形式で格納し、定期的に更新する。算出部１１４では、データベース１１５に格納された情報から、予め与えられた指標または行政側から新たに与えられた指標に基づいてＫＰＩを算出し、算出されたＫＰＩに基づいて各社会インフラに関する運転計画の策定を行う。最終的に、この運転計画に沿って社会インフラ１２Ａ，１２Ｂ，…及び住民用サーバ１４へ運転内容を指示する。

Description

情報統合制御システムと情報処理プログラム、社会インフラ運用システム、運用方法、ローカル装置、サーバ装置およびプログラム

　本発明の実施形態は、国、市、町といった所定領域又は地域の各種インフラストラクチャ（インフラ）に関する管理・計測情報等のインフラ情報を収集して統合し、これらに基づき、様々なニーズに応じて作成される最適化情報を提供する情報統合制御システムとこのシステムに用いられる情報処理プログラムに関する。

　また本発明の実施形態は、社会インフラストラクチャ（以下、インフラと略称する）を運用するための社会インフラ運用システム、社会インフラの運用方法、ローカル装置、サーバ装置およびプログラムに関する。

　従来の社会システムでは、複数の社会インフラは、基本的にそれぞれ独立して管理、運営されていた。例えば省エネルギーのための最適化処理は、個々のインフラ単体で実施されるにとどまるものであった。よって、国単位ではもとより、地域レベル、あるいは戸別家庭レベルでの最適化制御は未だ実現されていなかった。

特開２０１１－０６１９３１号公報

　地域社会と、この地域社会に備わる社会インフラとを合わせて一つのコミュニティとして捉える考え方がある。そして、社会インフラだけでなく、コミュニティにいる人々との関係にも配慮した新たな管理、運営の手法が望まれている。

　そこで、目的は、情報統合制御システムと情報処理プログラム、社会インフラ運用システム、運用方法、ローカル装置、サーバ装置およびプログラムを提供することにある。

　実施形態によれば、情報統合制御システムは、収集部と、記憶部と、生成部とを具備する。収集部は、社会インフラに係わるインフラ情報と、社会インフラを利用する利用者に関する利用者情報と、社会インフラ及び利用者を管理する管理者の管理情報とを収集する。記憶部は、収集されたインフラ情報、利用者情報、および、管理情報を記憶する。生成部は、記憶部に記憶されたインフラ情報、利用者情報、および、管理情報に基づいて、社会インフラに対する制御情報を生成する。

図１は、実施形態に係わる情報統合制御システムの一例を示すブロック図である。 図２は、図１に示される実施形態の社会インフラ及び住民への運転指示を実施する場合の運用例を示すフローチャートである。 図３は、図１に示される実施形態のＫＰＩ表示における最適化処理例を示すフローチャートである。 図４は、図１に示される実施形態の情報収集処理において、ＫＶＳ形式で記憶する手順を示すフローチャートである。 図５は、図１に示される実施形態のＫＰＩ算出における最適化処理例を示すフローチャートである。 図６は、図１に示される実施形態の複数の中間値によるＫＰＩが並列処理されている場合の運転計画の算定を行う処理の流れを示すフローチャートである。 図７は、図１に示される実施形態の複数のＫＰＩ算出結果を統合し最適化する処理の流れを示すフローチャートである。 図８は、既存の技術によりＥＶの走行計画を策定する手順の一例を示す概念図である。 図９は、実施形態に係わるシステムによりＥＶの走行計画を策定する手順の一例を示す概念図である。 図１０は、第２の実施形態に係わる社会インフラ運用システムの一例を示すシステム図である。 図１１は、第２の実施形態に係わる社会インフラ運用システムの要部を示す機能ブロック図である。 図１２は、第２の実施形態におけるローカル装置３１の処理手順の一例を示すフローチャートである。 図１３は、サーバ装置１８による運転計画の策定に係わる処理手順の一例を示すフローチャートである。 図１４は、サーバ装置１８による運転計画の策定に係わる処理手順の他の例を示すフローチャートである。

　［第１の実施形態］
　図１は、第１の実施形態に係わる情報統合制御システムの構成例を示すブロック図である。このシステムは、情報通信基盤１１、複数種類の社会インフラ（電気、水道、交通、医療、その他の設備）１２Ａ，１２Ｂ，…、行政（施政者）用サーバ１３、住民（受益者）用サーバ１４を備え、それぞれの入出力部１２１，１３１，１４１をネットワーク接続することによって相互通信可能になっている。ここで、「住民」とは複数種類の社会インフラ１２Ａ，１２Ｂ，…が設けられた領域又は地域に住む者を意味する。「利用者」とは、社会インフラ１２Ａ，１２Ｂ，…を利用する者の意味であり、住民をも含む広い概念である。「行政」とは、複数種類の社会インフラ及び住民（利用者）を管理する管理者とする。

　上記情報通信基盤１１は、各種社会インフラのそれぞれに関連して収集されるインフラ情報を統合し、要求に対して情報を最適化し提供する。この種の機能は、複数のサーバやデータベースなどを備えるクラウドコンピューティングシステムにインプリメントすることが可能である。情報通信基盤１１は、ＫＰＩ（Key Performance Indicator：業績評価指標）算出部１１４、データベース１１５、表示最適化部１１６、および、指示作成部１１７を備える。

　各社会インフラ１２Ａ，１２Ｂ，…において設備装置１２２から収集されるインフラ情報（利用状況、機器の状態）、行政用サーバ１３からの行政情報（社会システム全体の運転状態を示すＫＰＩ（人口、出生率、経済指標などの統計値や、省エネルギー率、アンケート結果などの各種数値））、住民用サーバ１４からの住民情報（家屋等に設置されている各種センサからの取得情報を含む）は、入出力部１１１～１１３を介して収集され、データベース１１５に格納される。

　データベース１１５は、例えば分散型のストレージメディアであり、種々の情報やデータを例えばＫＶＳ（Key-Value Store：キー－バリュー・ストア）型で記憶する。つまりデータベース１１５は、例えば社会インフラ１２Ａ，１２Ｂ，…、行政用サーバ１３及び住民用サーバ１４から送られてくる情報をキー（標識）とバリュー（値）とのペアの形式で格納する。キーは、各情報を識別するための標識であり、バリューはキーごとに対応付けられる情報の中身（値）である。

　キー－バリュー・ストア型データベースは、スケーラブルに拡張可能で、一定時間の探索時間での応答を保証することが可能であるという、特徴を備える。よって例えば、毎秒ギガバイトレベルの膨大な容量のデータをリアルタイムで格納することが可能である。情報を格納する際には、情報をそのままの状態で格納する場合と、社会インフラ側で加工された状態の情報が格納されることがあり得る。またさらに、インフラを運営する事業者に関する情報が任意で付与される。また、住民情報は、インフラ事業者の設備から取得される場合と、住民が家庭内に他の目的で設置した設備から取得される場合と、住民が利用する他のサービスから取得される場合とが想定される。

　ＫＰＩ算出部１１４は、データベース１１５に記憶された異なる社会インフラ１２Ａ，１２Ｂ，…から取得されるインフラ情報、行政用サーバ１３からの行政情報、および、住民用サーバ１４からの住民情報に基づいて、ＫＰＩを算出する。　
　指示作成部１１７は、算出されたＫＰＩに基づいて、社会インフラ１２Ａ，１２Ｂ，…、住民用サーバ１４に対する最適な指示情報を算出する。

　インフラ情報は、一度比較可能な中間値に変換され、さらにＫＰＩ算出部１１４によりＫＰＩに変換されてもよい。このＫＰＩ算出部１１４の処理には、定められた時間内に、例えば数千個以上にもおよぶ異なる指標に対する多変量解析を行う必要があるため、並列処理が可能なクラウドコンピューティングシステムを利用することが可能である。つまりＫＰＩ算出部１１４は、クラウドコンピューティングシステムに実装され、ＫＰＩを算出する処理は、このクラウドコンピューティングシステムにより提供されるサービスとして実現されることができる。

　データベース１１５に情報を記憶する際に、異なる社会インフラ等でも比較可能な中間値に変換するが、この中間値の概念は、「仮想的なコスト」のイメージだけでなく、コストに換算できない値も含まれる。中間値としては、例えば、「個人別の１時間、１日の環境負荷値」、「個人別の１時間、１日の利便性評価値」等があげられる。中間値は、都市のＫＰＩのサブセットのような値であってもよい。

　表示最適化部１１６は、ＫＰＩ算出部１１４で算出されたＫＰＩを、人が評価検証を行うための見やすい形式に変更する。形式の変更されたＫＰＩを、指示情報として用いるようにしても良い。ＫＰＩは、それぞれ社会インフラ、住民、行政に対する情報として入出力部１１１～１１３を経由して、社会インフラ１２Ａ，１２Ｂ，…、行政用サーバ１３、住民用サーバ１４に送られ、それぞれの表示装置で表示される。

　尚、施政者が入出力部１３１を経由してＫＰＩを設定することも可能である。その場合、表示と逆の経路で、社会インフラ１２Ａ，１２Ｂ，…や住民用サーバ１４に制御情報が伝播する。

　上記のシステム構成において、以下に運用例について説明する。

　図２は社会インフラ及び住民への運転指示を実施する場合の運用例を示している。図２において、社会インフラ１２Ａ，１２Ｂ，…、行政用サーバ１３から電力需要予測情報、交通渋滞情報、事故発生情報、気象情報等を収集し、家屋内各種センサ（電気メータ、ガスメータ、保安センサ）により検知された種々の住民情報を住民用サーバ１４から収集してデータベース１１５にＫＶＳ形式で格納し、定期的に更新する（ステップＳ１１）。

　算出部１１４は、データベース１１５に格納された情報から、予め与えられた指標または行政側から新たに与えられた指標に基づいてＫＰＩを算出する（ステップＳ１２）。算出部１１４は、算出されたＫＰＩに基づいて各社会インフラに関する運転計画を策定する（ステップＳ１３）。最終的に、この運転計画に沿って社会インフラ１２Ａ，１２Ｂ，…及び住民用サーバ１４へ運転内容を指示することができる。

　図３はＫＰＩ表示における最適化処理例を示すもので、上記のように収集されてデータベース１１５に格納された情報（ステップＳ２１）に基づいて、ＫＰＩが算出されると（ステップＳ２２）、算出されたＫＰＩは表示最適化部１１６にてグラフ、図表、文章等による比較しやすい表示内容に変換される（ステップＳ２３）。これにより、本システムの利用者は、常時最適化された形式でＫＰＩが表示されるため、指標評価の判断が容易となる。

　図４は上記情報収集処理において、ＫＶＳ形式で記憶する手順を示すもので、インフラ情報／住民情報／行政情報が収集されると（ステップＳ３１）、これらの情報は標識と値のペアによる形式に変換され（ステップＳ３２）、さらに相互比較が容易な中間値に変換された後（ステップＳ３３）、ＫＶＳ形式の情報としてデータベース１１５に格納される。

　図５は上記ＫＰＩ算出における最適化処理例を示すもので、データベース１１５からＫＶＳ形式で格納された中間値１～Ｎの情報を取り出し（ステップＳ４１）、ＫＰＩに基づく処理の分割を実行し（ステップＳ４２）、分割結果に基づいて各中間値１～ＮそれぞれについてＫＰＩに対応する処理を実行し（ステップＳ４３１，…Ｓ４３Ｎ）、再度集約して（ステップＳ４４）、ＫＰＩ処理された中間値１’～Ｎ’を算出し、データベース１１５に格納する。このように、ＫＰＩの算出を実行する際に、分割してＫＰＩの算出を行い、それを集約することにより、膨大なデータにおいても、常に最適な情報処理が可能となる。

　図６は複数の中間値によるＫＰＩが並列処理されている場合（ステップＳ５１）に、個々のＫＰＩを比較して（ステップＳ５２）、優先度等のパラメータに従った運転計画の算定を行う（ステップＳ５２）仕組みを示している。また、図７はデータベース１１５に格納されている中間値から複数のＫＰＩが算出された場合に（ステップＳ６１）、表示最適化処理Ｓ６２で複数のＫＰＩ算出結果を統合し最適化する（ステップＳ６２）仕組みを示している。

　以上のように、第１の実施形態のシステムでは、各社会インフラ、行政、住民それぞれの収集情報を一定の探索時間での応答が保証されているＫＶＳ形式でデータベース１１５に格納しておき、任意のタイミングでデータベース１１５から情報を読み出して規定のＫＰＩを算出し、最適な表示形式で提供するようにしているので、各種インフラの管理・計測情報を的確に収集し、その膨大な情報を効率よく蓄積し、要求に沿った適切な情報処理を実行することが可能となり、スマートコミュニティの実現を飛躍的に高めることができる。

　周知のように、電気、水道、交通、通信、行政などの従来の社会インフラは、その種類ごとに運営組織（行政など）と住民間の契約、手続きがなされた上でサービスが提供されていた。各インフラにおいて、サービス提供の際に蓄積、収集される情報は、それ自身のサービスで利用されるのみで、基本的に他のサービスの向上のために用いられることはない。そこで、スマートコミュニティは、社会インフラを含む社会システム全体を情報通信で連携し、例えば以下に示される（１）～（３）を満たせるような設計を求められる。

　（１）インフラ事業者は効率的な社会インフラの整備と運営を進めることができる。　
　（２）施政者（行政）は社会システム全体に対する運営改善を継続的に実施することができる。　
　（３）住民は利便性を損なうことなくサービスを受益できる。　
　そこで実施形態では、クラウドコンピューティング技術を活用し、社会システム全体のインフラ情報および住民情報および行政情報を、クラウド上のデータベース１１５に格納し、ＫＰＩ算出部１１４にて社会インフラ計画や住民の利用計画を算出するような構成とする。これにより、社会インフラとそれを運営する施政者、事業者、および住民それぞれに利益をもたらすことができる。

　次に、第１の実施形態で実現されるシステムを通して情報をやり取りすることにより、車両（一例として電気自動車（ＥＶ）とする）を運用する交通設備と、住民（運転者）、および施政者への利益を与えることの可能な例について説明する。もちろん、車両ＥＶも社会インフラの一例である。

　まず、住民用サーバ１４側から収集される情報は、ＥＶの充電残量、目的地までの距離とする。社会インフラ１２Ａ，１２Ｂ，…側から収集される情報は、電気設備によって決定される、地域、時間帯によって変動する電気料金、交通設備によって決定される充電器の位置、行政用サーバ１３から収集される情報は、交通を最適化するための交通規制であるとする。

　図８は、既存の技術によりＥＶの走行計画を策定する手順の一例を示す概念図である。図９は、実施形態に係わるシステムによりＥＶの走行計画を策定する手順の一例を示す概念図である。　
　従来のＥＶの走行計画によると、図８に示すように、充電残量と目的地までの距離を参考に、途中で停止せずに目的地まで到達できるかどうかを、ＥＶの運転者が推量して充電することになる。この場合、充電器がこの先にあるかどうかがわからなければ、不十分な情報を元に、念のために充電する運転者が、或る割合で存在する。充電の際に、電気の供給が需要に対して逼迫している状況の場合には、電気設備の余力が少なくなるために非効率な運転を強いられるという不利益が設備事業者に発生する。同時に、高い電気料金となるために、ＥＶ運転者（住民）の不利益ともなる。

　もしここで、他の設備から取得されたインフラ情報を１箇所から参照することが可能となれば、図９に示すように、交通設備（設備側情報）から取得される次の充電器位置により、充電残量を使い切り、より少ない停止回数で充電するための運転計画が策定可能となる。また、電気設備１，２から取得される電気料金により、より低コストに充電できる充電器を選択する運転計画が策定可能となる。さらに、行政より提供される交通規制情報（走行速度など）により、運転計画が成立するか判断することが可能となる。

　これらを実現するために、第１の実施形態のシステムでは、住民、行政、社会インフラそれぞれから情報を取得するための情報収集処理と、１箇所にまとめて短時間で必要な情報を参照可能とするためのデータベース１１５と、最適化するための計算を短時間に行うためのＫＰＩ算出部１１４を備えており、様々な社会インフラの柔軟かつ的確な運転指示が可能となる。

　以上のように第１の実施形態によれば、各種インフラに関する管理・計測情報等のインフラ情報を収集し、要求に沿った適切な情報処理を実行することができる。

　［第２の実施形態］
　図１０は、第２の実施形態に係わる社会インフラ運用システムの一例を示す図である。図１０において、社会インフラの例として電力インフラ１１０、新エネルギーインフラ１２０、道路交通インフラ１３０、鉄道インフラ１４０、水処理インフラ１５０、および医療インフラ１６０を示す。つまり社会インフラ運用システムは、種別の異なる複数の社会インフラを対象とすることができる。社会インフラはこれらに限らず熱供給インフラ、通信インフラ、ビル（ビルディング）インフラなど多種多様に存在する。図１０と図１との対比では各インフラ１１０～１６０（図１０）が社会インフラ１２Ａ，１２Ｂ，…（図１）に対応する。

　電力インフラ１１０は発電所および発電プラント、送配電網などを含むことができる。新エネルギーインフラ１２０は蓄電ＳＣＡＤＡ（Supervisory Control And Data Acquisition）、ＰＶ（Photovoltaic）システムなどの、再生可能エネルギーに係わるインフラである。道路交通インフラ１３０は信号機や高速道路網、一般道路網などを含むことができる。

　鉄道インフラ１４０は鉄道網、車両、チケット予約センタなどを含むことができる。水処理インフラ１５０は上下水道、浄水場などを含むことができる。医療インフラ１６０は、病院、病院内の設備、各種モダリティ（ＣＴスキャナ、Ｘ線診断装置、ＭＲＩ撮影装置など）、病院内ネットワークなどを含むことができる。各インフラ（社会インフラ）１１０～１６０はいずれも、それぞれ固有の制御対象を備える。以下、各インフラにおける制御対象を被制御対象と総称する。

　各インフラ１１０～１６０は通信ネットワーク１７に接続される。クラウドコンピューティングシステム１０００は、ゲートウェイ（ＧＷ）１００を介して通信ネットワーク１７に接続される。実施形態における通信ネットワーク１７は、通信速度を保証可能なギャランティ型ネットワークである。

　つまり実施形態では、クラウドコンピューティングシステム１０００と各インフラ１１０～１６０間とは、通信帯域を保証可能なネットワークを介して接続される。この種のネットワークの一例としては光通信技術を応用した専用回線のほか、例えばＩＰ（Internet Protocol）ネットワークに構築したＶＰＮ（Virtual Private Network）もある。この種の通信ネットワークを利用することで、情報伝送にかかるリアルタイム性を保証することが可能になる。

　通信ネットワーク１７には行政用サーバ１３が接続される。行政用サーバ１３にシステムの上位層の機能を持たせることにより、対象とする社会システムを統括的に制御することも可能になる。このようなケースでは行政用サーバ１３は例えばＳＣＭＳ（Smart Community Management System）サーバと称されることもある。

　通信ネットワーク１７には、さらに、複数の世帯（以下、加入者宅１６と表記する）が接続される。例えば、各加入者宅１６に備わるパーソナルコンピュータに、住民用サーバ１４（図１）の機能をインプリメントすることが可能である。あるいは、各家庭に形成されるエネルギー管理システムであるＨＥＭＳ（Home Energy Management System）のサーバ装置に、住民用サーバ１４の機能を持たせるようにしても良い。もちろん、加入者宅１６、およびＨＥＭＳも社会インフラの一つである。

　クラウドコンピューティングシステム１０００は、例えば実施形態に係わるサービスを提供する事業者（ベンダ）により構築される。その一例としては例えばデータセンタを挙げることができる。クラウドコンピューティングシステム１０００は、サーバ装置１８とデータベース１１５とを備える。

　サーバ装置１８は、単体のコンピュータ、又は複数のコンピュータの総体として構成することが可能である。データベース１１５は一つのコンピュータに備えられていても、複数のコンピュータに分散配置されていてもよい。実施形態ではサーバ装置１８およびデータベース１１５が複数備わる形態を考える。このような形態ではサーバ装置１８はクラウド通信網３００を介して相互に接続される。

　ところで、実施形態では、各インフラ１１０～１６０はローカル装置３１を備える。ローカル装置３１は、必要に応じてそれぞれのインフラ１１０～１６０をローカルで制御することができる。つまりローカル装置３１は、被制御対象をインフラごとに制御するための、固有の制御機能を備える。　
　なお、行政用サーバ１３、住民用サーバ１４、ローカル装置３１、および、サーバ装置１８のいずれも、ＣＰＵ（Central Processing Unit）を備えるコンピュータである。

　例えば電力インフラ１１０においては、ローカル装置３１は、需要者ごとの電力の分配を制御する機能を備える。新エネルギーインフラ１２０においては、ローカル装置３１は、ＰＶシステムの発電量を気象情報に基づいて予測する機能を備える。道路交通インフラ１３０においては、ローカル装置３１は、道路の交通管制を行う機能を備える。

　鉄道インフラ１４０においては、ローカル装置３１は、鉄道の運行管理などを行う機能を備える。水処理インフラ１５０においては、ローカル装置３１は、上水道の流量を制御したり、灌漑用水やダムの貯水量を制御する機能を備える。医療インフラ１６０においては、ローカル装置３１は、データ入力インタフェース、読影モニタ、病院内ＬＡＮに係わる各種制御、あるいは各種医用データの蓄積などの機能を備える。

　各ローカル装置３１は通信ネットワーク１７に接続され、サーバ装置１８と相互に情報通信したり、データベース１１５から各種データを取得したり、サーバ装置１８を介してデータベース１１５に各種データを蓄積したりすることができる。つまりローカル装置３１とサーバ装置１８とは、通信ネットワーク１７を介して接続されて相互に情報通信が可能である。

　サーバ装置１８は、ローカル装置３１に被制御対象を制御するための各種の指示情報（コマンド、制御データを含む）を与える機能を備える。つまりサーバ装置１８は、ローカル装置３１、あるいは各インフラ１１０～１６０に対して、上位層の位置づけにある。

　データベース１１５は、社会インフラに係わるインフラ情報（センシングデータ）を蓄積する。インフラ情報としては、スマートメータ、各種センサ、ネットワーク監視装置、ＭＤＭＳ（Meter Data Management System）、基幹システム（Billing System）などの各種監視制御システムからのメータデータ、センサデータ、トラフィック、ＧＰＳ（Global Positioning System）データ、ライフログなどが例として挙げられる。つまり、インフラ情報は、何らかの計測手段により計測される量、あるいは人間によりシステムに与えられる情報である。これらのデータは、膨大な量に及ぶことから、クラウドコンピューティングの関係する分野ではBigData（ビッグデータ）とも称される。

　図１１は、第２の実施形態に係わる社会インフラ運用システムの要部を示す機能ブロック図である。図１１において、社会インフラとしての電力インフラ、および医療交通インフラが主に関係するケースを採り上げる。

　電力インフラのローカル装置３１、および医療インフラのローカル装置３１は、実施形態に係わる処理機能としてモニタ部３１ａ、アップロード部３１ｂ、受信部３１ｃ、および、ヒューマンマシンインタフェース（ＨＭＩ）部３１ｄを備える。　
　モニタ部３１ａは、制御対象とする社会インフラに係わるインフラ情報をモニタする。アップロード部３１ｂは、上記インフラ情報を通信ネットワーク１７を介してサーバ装置１８にアップロード送信する。受信部３１ｃは、制御対象とする社会インフラの運転計画をサーバ装置１８から受信する。ＨＭＩ部３１ｄは、受信された運転計画を例えばグラフィカルに表示するなどして、社会インフラのユーザ（システムオペレータなど）に通知する。

　行政用サーバ１３は、実施形態に係わる処理機能として、アップロード部３１ｂ、受信部３１ｃに加え、情報入力部１３ａ、およびユーザインタフェース（ＵＩ）部１３ｂを備える。情報入力部１３ａは、地域住民に係わる住民情報などの、例えば行政サービスの遂行に要する情報を入力する。つまり、社会インフラの構築される地域における自治体により管理される情報を、住民情報として捉えることも可能である。

　住民情報はインフラ情報と同様に取り扱われ、アップロード部３１ｂによりサーバ装置１８にアップロード送信される。ＵＩ部１３ｂはＨＭＩ部３１ｄと同様に、サーバ装置１８から受信した運転計画をグラフィカルに表示するなどして、社会インフラのユーザ（行政係官など）に伝達する。

　住民用サーバ１４も同様に、情報入力部１３ａ、アップロード部３１ｂ、受信部３１ｃ、およびユーザインタフェース（ＵＩ）部１３ｂを備える。住民用サーバ１４においては、情報入力部１３ａは上記住民情報などに加え、加入者宅１６（住民宅）に備えられる電気機器（エアコン、照明、テレビ、在宅医療設備などのいわゆる家電機器、ＰＶシステム、燃料電池、蓄電池など）に係わる情報を入力するために用いられる。これらの情報（家電機器情報）はインフラ情報と同様に取り扱われ、アップロード部３１ｂによりサーバ装置１８にアップロード送信される。ＵＩ部１３ｂは、サーバ装置１８から受信した運転計画をグラフィカルに表示するなどして、在宅ユーザ（加入者など）に伝達する。

　サーバ装置１８は、その処理機能として取得部１８ａ、収集部１８ｂ、策定部１８ｃ、送信部１８ｄ、ＫＰＩ算出部１１４、および、変換部１８ｅを備える。　
　取得部１８ａは、社会インフラのそれぞれからアップロード送信されたインフラ情報を、通信ネットワーク１７を介して各ローカル装置３１、行政用サーバ１３、住民用サーバ１４から取得する。取得されたインフラ情報はデータベース１１５に蓄積される（インフラ情報１１５ａ）。なお行政用サーバ１３から取得された設定情報もデータベース１１５に蓄積される（設定情報１１５ｂ）。設定情報は、例えば道路交通インフラ１３０における信号機の制御などに係わる情報である。

　収集部１８ｂは、住民情報を行政用サーバ１３、住民用サーバ１４から通信ネットワーク１７を介して収集する。収集された住民情報はデータベース１１５に蓄積される（住民情報１１５ｅ）。　
　住民情報には、例えば世帯主名、住所、家族構成および家族の年齢などの情報を含めることが可能である。これらの情報は自治体により管理される住民基本台帳（または住民戸籍情報）に基づく情報であり、行政用サーバ１３からアップロードされることが可能である。これに加えて住民の趣味、嗜好に係わる情報や、家電機器情報の一部（機器名称や特殊な設定情報など）などを、住民情報の一つの形態として住民用サーバ１４から直接システムにアップロードすることができる。そのインタフェースとしてはＣＧＩ（Common Gateway Interface）技術を用いたＷｅｂページなどを用いることができる。

　また収集部１８ｂは、上記家電機器情報１１５ｆ、およびプレゼンス情報１１５ｇを住民用サーバ１４から収集してデータベース１１５に蓄積する。プレゼンス情報とは加入者宅における住民の在／不在などを示す情報である。この種の情報は近年普及の著しいＩＰ（Internet Protocol）電話システムでは著名なＳＩＰ（Session Initiation Protocol）を用いれば容易に収集することが可能である。プレゼンス情報を用いれば、在／不在に加えて、電話中／コンピュータ使用中／会議中などの状態も区別することが可能である。

　策定部１８ｃは、データベース１１５に蓄積されるインフラ情報１１５ａ、設定情報１１５ｂ、住民情報１１５ｅ、家電機器情報１１５ｆ、およびプレゼンス情報１１５ｇの少なくとも一つを用いて、家電機器を含む各インフラの運転計画を策定する。送信部１８ｄは、策定された運転計画を、行政用サーバ１３、住民用サーバ、ローカル装置３１に送信する。

　ＫＰＩ算出部１１４は、データベース１１５に蓄積されるインフラ情報１１５ａ、設定情報１１５ｂ、住民情報１１５ｅ、家電機器情報１１５ｆ、およびプレゼンス情報１１５ｇの少なくとも一つに基づいて、業績評価指数としてのＫＰＩを算出する。算出されたＫＰＩはデータベース１１５に蓄積される（ＫＰＩ１１５ｃ）。

　変換部１８ｅは、各ローカル装置３１、行政用サーバ１３、住民用サーバ１４から取得したインフラ情報を、少なくとも電力インフラ、および、医療インフラ間で相互に比較することの可能な中間値に変換する。算出された中間値はデータベース１１５に蓄積される（中間値１１５ｄ）。

　なお策定部１８ｃは、ＫＰＩ１１５ｃに基づいて運転計画を策定するようにしても良い。また策定部１８ｃは、中間値１１５ｄに基づいて、電力インフラ、および医療インフラからの各インフラ情報、および、行政、住民からの設定情報、住民情報に基づいて、各社会インフラごとの運転計画を策定するようにしても良い。例えば、図９を用いて説明した、充電器の発見から充電の判断に至るまでの車両ＥＶの運転計画は、車両ＥＶ、電力インフラ、道路交通インフラ、および行政サービスから提供される各インフラ情報を総合的に反映する。

　なお上記構成において、サーバ装置１８にＳＣＭＳサーバ２００を接続し、対象とする社会システムを統括的に制御できるようにしても良い。ＳＣＭＳサーバ２００は、例えばクラウドコンピューティングシステム１０００のベンダにより運用される。次に、上記構成における作用を説明する。

　図１２は、第２の実施形態におけるローカル装置３１およびサーバ装置１８の処理手順の一例を示すフローチャートである。図１２において、例えば医療インフラ１６０のローカル装置３１は、制御対象に係わるインフラ情報を収集し、収集されたインフラ情報を通信ネットワーク１７を介してサーバ装置１８にアップロード送信する（ステップＳ１）。サーバ装置１８は、ローカル装置３１から送信されたインフラ情報を取得する（ステップＳ２）。　
　住民用サーバ１４は、住民の住民情報を通信ネットワーク１７を介してサーバ装置１８にアップロード送信する（ステップＳ３）。サーバ装置１８は、住民用サーバ１４から送信された住民情報を収集する（ステップＳ４）。

　サーバ装置１８は、取得されたインフラ情報（インフラ情報１１５ａ）および収集された住民情報（住民情報１１５ｅ）をデータベース１１５に蓄積する（ステップＳ５）。データベース１１５に設定情報１１５ｂ、家電機器情報１１５ｆ、プレゼンス情報１１５ｆも蓄積されることは図１１に示されるとおりである。

　次にサーバ装置１８は、医療インフラの運転計画を策定するのに要するインフラ情報と、住民情報とをデータベース１１５から読み出し、運転計画を策定する（ステップＳ６）。次にサーバ装置１８は、作成した運転計画をローカル装置３１および住民用サーバ１４に送信する（ステップＳ７）。

　ローカル装置３１は、サーバ装置１８から送信された運転計画を受信し（ステップＳ８）、内部メモリなど（図示せず）に記憶する。そしてローカル装置３１は、受信した運転計画をディスプレイに表示するなどして、ユーザに伝える（ステップＳ９）。さらにローカル装置３１は、運転計画に基づいて医療インフラ１６０における各社会インフラを制御する（ステップＳ１０）。

　一方、住民用サーバ１４は、サーバ装置１８から送信された運転計画を受信し（ステップＳ１１）、内部メモリなど（図示せず）に記憶する。そして住民用サーバ１４は、受信した運転計画をディスプレイに表示するなどして、ユーザに伝える（ステップＳ１２）。

　図１３は、図１２に示されるステップＳ６におけるサーバ装置１８の処理手順の一例を示すフローチャートである。サーバ装置１８は、データベース１１５に蓄積されるインフラ情報１１５ａおよび住民情報１１５ｅに基づいて、業績評価指数としてのＫＰＩ１１５ｃを算出する（ステップＳ５１）。そしてサーバ装置１８は、算出されたＫＰＩ１１５ｃに基づいて、社会インフラの運転計画を策定する（ステップＳ５２）。

　図１４は、図１２に示されるステップＳ６におけるサーバ装置１８の処理手順の他の例を示すフローチャートである。サーバ装置１８は、データベース１１５に蓄積されるインフラ情報１１５ａに基づいて、当該インフラ情報１１５ａの中間値１１５ｄを算出する（ステップＳ５３）。そしてサーバ装置１８は、算出された中間値１１５ｄと、住民情報１１５ｅとに基づいて、社会インフラの運転計画を策定する（ステップＳ５４）。

　なお、ステップＳ６における運転計画の策定のたびに、インフラ情報の取得および住民情報の収集を繰り返す必要はない。例えば運転計画が３０分周期で策定されるとすれば、インフラ情報は１時間周期またはそれよりも長い周期で取得し、住民情報は１日またはそれよりも長い周期で収集するようにしても良い。さらには、インフラ情報および住民情報が変化したときにのみ、サーバ装置１８に通知するようにしても良い。次に、図１２における処理手順につき詳しく説明する。

　第２の実施形態では、インフラ情報と住民情報とをクラウドコンピューティングシステム１０００にアップロードし、これらの情報に基づいて、社会インフラの運転計画をクラウドコンピューティングシステム１０００において算出するようにしている。その一例について、インフラを制御するにあたり重要な概念であるリアルタイム制御との関連を持たせて以下に説明する。

　電力インフラ１１０に係わる制御態様として、デマンドレスポンスが知られている。デマンドレスポンスは、電力の需要に対する供給能力が逼迫した場合に、電力の供給者から需要者に節電を要求し（デマンド）、需要者がそれに応える（レスポンス）仕組みである。例えば突然の災害により発電所が破損したなどのケースでは、広範囲にわたる停電を防ぐため、デマンドレスポンスに特にリアルタイム性を要求される。

　第２の実施形態では、ギャランティ型の通信ネットワーク１７により社会インフラおよび住民に係わる情報を収集し、クラウドコンピューティングシステム１０００の能力により運転計画を算出するようにしているので、リアルタイム制御を実現すること自体は可能である。

　しかしながら需要者への電力を盲目的に削減するとなれば、個々の住民の事情によっては人命に係わる事態が生じうる。例えば老人、あるいは要介護者が住む住宅に対して電力節減のための運転計画を投入すると、医療機器までもが停止してしまうような事態の起こる虞がある。

　そこで第２の実施形態では、住民情報をも考慮して運転計画を算出するようにしている。例えば、電力会社から省エネの要請（デマンド）が生じた際、老人や病人の住む家庭、病院、ビルなどに電力を優先的に分配し、これらを除く範囲での最適な運転計画を策定して個別制御を行うことが考えられる。

　住民情報には、既に述べたように、家屋等に設置されている各種センサなどから取得される情報、世帯主名、住所、家族構成および家族の年齢などの情報、住民の趣味、嗜好に係わる情報、家電機器情報などに加え、住民の健康状態や、かかりつけ医、入院／通院している病院の名称、飲んでいる薬の名称などの情報も含めることが可能である。これらの情報は医療インフラ１６０からクラウドコンピューティングシステム１０００にアップロードされた情報を利用するようにしても良い。あるいは、例えば体温や血圧などの情報は、体温計、血圧計に備わる通信手段を用いてＨＥＭＳに一旦集積されたデータを、クラウドコンピューティングシステム１０００にアップロードするようにしても良い。

　デマンドレスポンスに際して優先度を決めるための情報は、住民基本台帳に示される情報のほか、住民用サーバ１４を介して与えられる情報であって良い。例えば住民用サーバ１４を用いて、節電要請を受諾する／しないの意思表示をシステムに与えておき、その旨がデータベース１１５に登録されるようにすれば、自宅における医療機器の有無に寄らずとも、受諾しないユーザに、電力を優先して配分することが可能にある。ただしこのような優先制御に際しては、公平性の観点から行政によるチェックを要するであろう。

　このように第２の実施形態によれば、住民の生活の実態までも反映したデマンドレスポンスを実現すること、いわば、条件つきのデマンドレスポンスを実現することが可能になる。ひいては、より精密な住民情報に基づき、より高度かつきめ細かなコミュニティサービスを実現することが可能になる。

　以上述べたように第２の実施形態によれば、社会インフラのユーザは、クラウドコンピューティングシステム１０００のリソースを利用する形で、最適な運転計画の提供を受けることが可能になる。上記デマンドレスポンスのほかに、例えば第１の実施形態で説明したように、車両ＥＶの運転者（ユーザ）はナビゲーションシステム（ローカル装置３１）を操作して、最適な充電計画の提供を受けることが可能になる。

　さらに、クラウドコンピューティングシステム１０００のベンダは、それぞれの社会インフラのユーザに運転計画を提供する際に課金することで利益を得るといったビジネスモデルを構築することも可能である。もちろん、社会インフラをスマート化するうえで、コミュニティに属する住民への配慮が無視されることもない。これらのことから、社会インフラをスマート化することの可能な社会インフラ運用システム、運用方法、ローカル装置、サーバ装置およびプログラムを提供することが可能になる。 
　［第２の実施形態の変形例］
　図１２のフローチャートにおいては、運転計画をローカル装置３１に表示したのち（ステップＳ９）直ちに社会インフラを制御する（ステップＳ１０）ようにした。これに代えて、ステップＳ９とＳ１０との間に、運転計画に基づく制御の許可、または許可せずの判断を人間に問い合わせるための手順を入れるようにしても良い。例えば、運転計画とともに、その運転計画を承認するためのインタフェース（例えばクリッカブルな承認ボタン）を併せて表示器の画面上で表示し、承認ボタンがクリックされることによってはじめて、運転計画に基づく制御が開始されるようにしてもよい。ここで、運転計画に承認を与える者としては、対象とする社会インフラのオペレータであっても良い。あるいは行政係官が、運転計画の承認／非承認を判断するようにしてもよい。このケースでは、運転計画はローカル装置３１のＨＭＩ部３１ｄだけでなく、行政用サーバ１３のユーザインタフェース（ＵＩ）部１３ｂにも表示される。そして、行政用サーバ１３のＵＩ部１３ｂだけに承認ボタンを表示するようにすれば、運転計画の承認／非承認を、行政係官の判断にゆだねることが可能になる。さらに、複数の運転計画を算出し、そのうちのいずれかを選択的に指定できるようにしても良い。

　なお本発明は上記実施形態に限定されるものではない。例えば図１１では変換部１８ｅをサーバ装置１８に備え、インフラ情報を中間値に変換する処理をサーバ装置１８において実施するようにした。これに代えて、変換部１８ｅをローカル装置３１、行政用サーバ１３、住民用サーバ１４に備えるようにし、ローカルで生成した中間値をサーバ装置１８にアップロードするようにしても良い。

　また第２の実施形態では、個別家庭や建物を対象とするデマンドレスポンスにつき説明した。これに代えて、エリアごと(病院あるいは高齢者住民の多いエリア)、あるいはコミュニティごとの最適化制御も可能である。

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

　１１…情報通信基盤、１２Ａ，１２Ｂ，…社会インフラ（電気、水道、交通、医療、その他）、１３…行政用サーバ、１４…住民用サーバ、１２１，１３１，１４１…入出力部、１１４…ＫＰＩ（Key Performance Indicator：業績評価指標）算出部、１１５…データベース、１１６…表示最適化部、１１７…指示作成部、１１０…電力インフラ、１２０…新エネルギーインフラ、１３０…道路交通インフラ、１４０…鉄道インフラ、１５０…水処理インフラ、１６０…医療インフラ、１６…加入者宅、１７…通信ネットワーク、１００…ゲートウェイ（ＧＷ）、１０００…クラウドコンピューティングシステム、１８…サーバ装置、３００…クラウド通信網、２００…ＳＣＭＳサーバ、３１…ローカル装置、３１ａ…モニタ部、３１ｂ…アップロード部、３１ｃ…受信部、３１ｄ…ヒューマンマシンインタフェース（ＨＭＩ）部、１３ａ…情報入力部、１３ｂ…ユーザインタフェース（ＵＩ）部、１８ａ…取得部、１８ｂ…収集部、１８ｃ…策定部、１８ｄ…送信部、１８ｅ…変換部、１１５ａ…インフラ情報、１１５ｂ…設定情報、１１５ｃ…ＫＰＩ、１１５ｄ…中間値、１１５ｅ…住民情報、１１５ｆ…家電機器情報、１１５ｇ…プレゼンス情報

Claims (25)

1. 　社会インフラに係わるインフラ情報と、前記社会インフラを利用する利用者に関する利用者情報と、前記社会インフラ及び利用者を管理する管理者の管理情報とを収集する収集部と、
   　前記収集されたインフラ情報、利用者情報、および、管理情報を記憶する記憶部と、
   　前記記憶部に記憶されたインフラ情報、利用者情報、および、管理情報に基づいて、前記社会インフラに対する制御情報を生成する生成部とを具備する、情報統合制御システム。
2. 　さらに、前記記憶部に記憶された前記情報に基づいて業績評価指標を算出する算出部と、
   　前記業績評価指標に基づいて、前記社会インフラに関する指示情報、前記利用者に対する利用者指示情報、および、前記管理者に対する管理者指示情報の少なくともいずれか１つを作成する指示作成部とを具備する、請求項１に記載の情報統合制御システム。
3. 　前記記憶部は、収集された情報を、当該情報を識別するためのキーと、当該キーに対応付けられるバリューとのペアで格納する、キー－バリュー・ストア型データベースである、請求項１に記載の情報統合制御システム。
4. 　前記算出部は、クラウドコンピューティングシステムに実装される、請求項１に記載の情報統合制御システム。
5. 　前記記憶部は、前記インフラ情報を、複数の社会インフラ間で相互に比較することの可能な中間値に変換して記憶する、請求項１に記載の情報統合制御システム。
6. 　さらに、前記業績評価指標を表示に適する形式に変換する表示最適化部を具備する、請求項１に記載の情報統合制御システム。
7. 　コンピュータにより実行される情報処理プログラムであって、
   　前記コンピュータに、
   　社会インフラに係わるインフラ情報と、前記社会インフラを利用する利用者に関する利用者情報と、前記社会インフラ及び利用者を管理する管理者の管理情報とを収集させ、
   　前記収集されたインフラ情報、利用者情報、および、管理情報を記憶部に記憶させ、
   　前記記憶部に記憶されたインフラ情報、利用者情報、および、管理情報に基づいて、前記社会インフラに対する制御情報を生成させる、情報処理プログラム。
8. 　社会インフラに設けられるローカル装置と、
   　前記ローカル装置に通信ネットワークを介して接続されるサーバ装置とを具備し、
   　　前記ローカル装置は、
   　前記社会インフラに係わるインフラ情報を前記通信ネットワークを介して前記サーバ装置にアップロードするアップロード部と、
   　前記社会インフラの運転計画を前記サーバ装置から受信する受信部とを備え、
   　　前記サーバ装置は、
   　前記インフラ情報を前記通信ネットワークを介して前記ローカル装置から取得する取得部と、
   　前記社会インフラの係わる地域における住民の住民情報を前記通信ネットワークを介して収集する収集部と、
   　前記取得されたインフラ情報と、前記収集された住民情報とを蓄積するデータベースと、
   　前記データベースに蓄積されるインフラ情報および住民情報に基づいて前記運転計画を策定する策定部と、
   　前記策定された運転計画を前記ローカル装置に送信する送信部とを備える、社会インフラ運用システム。
9. 　前記住民情報は、前記地域における自治体により管理される情報を含む、請求項８に記載の社会インフラ運用システム。
10. 　前記住民情報は、住民宅に設置される電気機器に係わる情報を含む、請求項８に記載の社会インフラ運用システム。
11. 　前記サーバ装置は、さらに、前記データベースに蓄積されるインフラ情報および住民情報に基づいて業績評価指数を算出する算出部を備え、
    　前記策定部は、前記算出された業績評価指数に基づいて前記運転計画を策定する、請求項８に記載の社会インフラ運用システム。
12. 　前記サーバ装置は、さらに、前記取得された前記インフラ情報を、種別の異なる複数の社会インフラ間で相互に比較することの可能な中間値に変換する変換部を備え、
    　前記データベースは、前記中間値に変換されたインフラ情報を蓄積し、
    　前記策定部は、前記中間値に基づいて、前記複数の社会インフラごとの運転計画を策定する、請求項８に記載の社会インフラ運用システム。
13. 　前記サーバ装置は、前記データベースを備えるクラウドコンピューティングシステムに備えられる、請求項８に記載の社会インフラ運用システム。
14. 　社会インフラに設けられるローカル装置と、前記ローカル装置に通信ネットワークを介して接続されるサーバ装置とを具備する社会インフラ運用システムに適用可能な運用方法であって、
    　　前記ローカル装置は、
    　前記社会インフラに係わるインフラ情報を前記通信ネットワークを介して前記サーバ装置にアップロードし、
    　前記社会インフラの運転計画を前記サーバ装置から受信し、
    　　前記サーバ装置は、
    　前記インフラ情報を前記通信ネットワークを介して取得し、
    　前記社会インフラの係わる地域における住民の住民情報を前記通信ネットワークを介して収集し、
    　前記取得されたインフラ情報と、前記収集された住民情報とをデータベースに蓄積し、
    　前記データベースに蓄積されるインフラ情報および住民情報に基づいて前記運転計画を策定し、
    　前記策定された運転計画を前記ローカル装置に送信する、運用方法。
15. 　前記住民情報は、前記地域における自治体により管理される情報を含む、請求項１４に記載の運用方法。
16. 　前記住民情報は、住民宅に設置される電気機器に係わる情報を含む、請求項１４に記載の運用方法。
17. 　前記サーバ装置は、さらに、前記データベースに蓄積されるインフラ情報および住民情報に基づいて業績評価指数を算出し、
    　前記策定することは、前記算出された業績評価指数に基づいて前記運転計画を策定する、請求項１４に記載の運用方法。
18. 　前記サーバ装置は、さらに、前記取得された前記インフラ情報を、種別の異なる複数の社会インフラ間で相互に比較することの可能な中間値に変換し、
    　前記策定することは、前記中間値に基づいて、前記複数の社会インフラごとの運転計画を策定する、請求項１４に記載の運用方法。
19. 　社会インフラに設けられるローカル装置において、
    　前記社会インフラに係わるインフラ情報を、通信ネットワークを介して接続されるサーバ装置に、前記通信ネットワークを介してアップロードするアップロード部と、
    　前記社会インフラの係わる地域における住民の住民情報を前記通信ネットワークを介して前記サーバ装置に送信する送信部と、
    　前記社会インフラの運転計画を前記サーバ装置から受信する受信部とを具備する、ローカル装置。
20. 　社会インフラに設けられるローカル装置に通信ネットワークを介して接続されるサーバ装置において、
    　前記社会インフラに係わるインフラ情報を前記通信ネットワークを介して前記ローカル装置から取得する取得部と、
    　前記社会インフラの係わる地域における住民の住民情報を前記通信ネットワークを介して収集する収集部と、
    　前記取得されたインフラ情報と、前記収集された住民情報とを蓄積するデータベースと、
    　前記データベースに蓄積されるインフラ情報および住民情報に基づいて前記運転計画を策定する策定部と、
    　前記策定された運転計画を前記ローカル装置に送信する送信部とを具備する、サーバ装置。
21. 　さらに、前記データベースに蓄積されるインフラ情報および住民情報に基づいて業績評価指数を算出する算出部を備え、
    　前記策定部は、前記算出された業績評価指数に基づいて前記運転計画を策定する、請求項２０に記載のサーバ装置。
22. 　さらに、前記取得された前記インフラ情報を、種別の異なる複数の社会インフラ間で相互に比較することの可能な中間値に変換する変換部を備え、
    　前記策定部は、前記中間値に基づいて、前記複数の社会インフラごとの運転計画を策定する、請求項２０に記載のサーバ装置。
23. 　コンピュータにより実行されるプログラムであって、
    　　前記プログラムは、
    　社会インフラに係わるインフラ情報を、当該社会インフラに設けられるローカル装置から取得し、
    　前記社会インフラの係わる地域における住民の住民情報を前記ローカル装置から収集し、
    　前記取得されたインフラ情報と、前記収集された住民情報とをデータベースに蓄積し、
    　前記データベースに蓄積されるインフラ情報および住民情報に基づいて、前記社会インフラの運転計画を策定し、
    　前記策定された運転計画を前記ローカル装置に送信する、プログラム。
24. 　さらに、前記データベースに蓄積されるインフラ情報および住民情報に基づいて業績評価指数を算出し、
    　前記策定することは、前記算出された業績評価指数に基づいて前記運転計画を策定する、請求項２３に記載のプログラム。
25. 　さらに、前記取得された前記インフラ情報を、種別の異なる複数の社会インフラ間で相互に比較することの可能な中間値に変換し、
    　前記策定することは、前記中間値に基づいて、前記複数の社会インフラごとの運転計画を策定する、請求項２３に記載のプログラム。

Images