特開 2024-39372 自律分散システムおよび情報交換方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024039372

(43)【公開日】2024-03-22

(54)【発明の名称】自律分散システムおよび情報交換方法

(51)【国際特許分類】

   H04L 67/10 20220101AFI20240314BHJP

   H02J 3/00 20060101ALI20240314BHJP

   H02J 13/00 20060101ALI20240314BHJP

【ＦＩ】

H04L67/10

H02J3/00 170

H02J13/00 301A

【審査請求】有

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2022143881

(22)【出願日】2022-09-09

(11)【特許番号】

(45)【特許公報発行日】2024-01-15

(71)【出願人】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(71)【出願人】

【識別番号】317015294

【氏名又は名称】東芝エネルギーシステムズ株式会社

(74)【代理人】

【識別番号】110001634

【氏名又は名称】弁理士法人志賀国際特許事務所

(72)【発明者】

【氏名】久保 喜義

(72)【発明者】

【氏名】平戸 康太

(72)【発明者】

【氏名】吉澤 晋

【テーマコード（参考）】

5G064

5G066

【Ｆターム（参考）】

5G064AC09

5G064CB08

5G064DA03

5G066AA03

5G066AE04

5G066AE09

(57)【要約】

【課題】異システム間で連携しながら動作させることができる自律分散システムおよび情報交換方法を提供すること。
【解決手段】実施形態の自律分散システムは、複数のシステムを含む自律分散システムであって、複数のシステムの各々は独立して自律的に動作し、複数のシステムの各々は、情報交換部を持つ。情報交換部は、他のシステムとの間で情報を交換する。情報は、第１情報識別子と第１属性値との組によって表現され、第１情報識別子は、「モノ」の位置の３次元座標である。
【選択図】図１

【特許請求の範囲】

【請求項1】

複数のシステムを含む自律分散システムであって、
複数の前記システムの各々は独立して自律的に動作し、
複数の前記システムの各々は、
他の前記システムとの間で情報を交換する情報交換部
を備え、
前記情報は、第１情報識別子と第１属性値との組によって表現され、
前記第１情報識別子は、「モノ」の位置の３次元座標である、自律分散システム。

【請求項2】

複数の前記システムの各々は、
交換する前記情報の表現形式としてパブリック形式とローカル形式とを有し、
前記パブリック形式では、前記情報が、前記第１情報識別子と前記第１属性値との組によって表現され、
前記ローカル形式では、前記情報が、各システムで独自に定義されている第２情報識別子と第２属性値との組によって表現され、
前記情報交換部は、外部からの要求に応じてパブリック形式とローカル形式との対応関係を交換する、請求項１に記載の自律分散システム。

【請求項3】

複数の前記システムから情報を取得して動作する情報共有システム
をさらに備え、
前記情報共有システムは、地図情報データベースである、請求項１または請求項２に記載の自律分散システム。

【請求項4】

複数の前記システムの各々は、
電力系統の系統計算を実施する算出部
をさらに備え、
前記情報交換部は、各システムが個々に作成するノード・ブランチの情報を交換する、請求項１または請求項２に記載の自律分散システム。

【請求項5】

複数のシステムを含む自律分散システムで実行される情報交換方法あって、
複数の前記システムの各々は独立して自律的に動作し、
複数の前記システムの各々は、
他の前記システムとの間で情報を交換、
前記情報は、第１情報識別子と第１属性値との組によって表現され、
前記第１情報識別子は、「モノ」の位置の３次元座標である、情報交換方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、自律分散システムおよび情報交換方法に関する。

【背景技術】

【0002】

ＤＸ(Digital transformation: DX)が進展し、社会には多種多様な情報システム（以下、単にシステム）が構築されている。従来、個々のシステムは独自に構築され、一部を除き互いに連携を取りながら動作する形態は少なかった。それらの多種多様のシステムは俯瞰的にみると、互いに意味的な関係性持つものが多くあり、相互に連携しながら動作させることにより新たな価値を生み出すことや、重複した機能の整理統合等によって、社会全体としての効率化を進められる可能性がある。ところが現状は、各システム間の連携は大きくは進んでいない。

【0003】

各システム間で連携する技術に関して、柔軟性が高く、拡張容易な業務システムが知られている（例えば特許文献１参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０２０－２０１７７１号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

本発明が解決しようとする課題は、異システム間で連携しながら動作させることができる自律分散システムおよび情報交換方法を提供することである。

【課題を解決するための手段】

【0006】

実施形態の自律分散システムは、複数のシステムを含む自律分散システムであって、複数の前記システムの各々は独立して自律的に動作し、複数の前記システムの各々は、情報交換部を持つ。情報交換部は、他の前記システムとの間で情報を交換する。前記情報は、第１情報識別子と第１属性値との組によって表現され、前記第１情報識別子は、「モノ」の位置の３次元座標である。

【図面の簡単な説明】

【0007】

【図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】実施形態の変形例２の自律分散システム１ｂの動作の一例を示すフロー図。

【図26】実施形態の変形例２の自律分散システム１ｂの動作の一例を示すフロー図。

【発明を実施するための形態】

【0008】

以下、実施形態の自律分散システムおよび情報交換方法を、図面を参照して説明する。なお以下の説明では、同一または類似の機能を有する構成に同一の符号を付す。そして、それら構成の重複する説明は省略する場合がある。

【0009】

本実施形態の自律分散システム１は、複数のシステムを含む。複数のシステムの各々は独立して自律的に動作する。自律分散システム１において、複数のシステムの各々には、他のシステムと連携しながら動作させるために必要な機能を持った「共通の言語」が確立されている。「共通の言語」に必要な機能は以下のａ）からｃ）のとおりである。
ａ）共通の文法（データ交換のインタフェースとプロトコル）
ｂ）共通のデータ表現形式（データ交換のフォーマット）
ｃ）共通の意味を共有できる識別子（特に現実の世界の個々の「モノ」に対して、意味を伴いつつ、ひとつひとつを識別する手段）

【0010】

従来、ａ）、ｂ）については多くの体系が存在している「モノ」の、ｃ）の範囲が限定的な場合が多く、将来を通じて広く普遍的に使えそうなｃ）の定義は、未だ見当たらない。

【0011】

例えば、多種多様な「モノ」の情報を異システム間で交換するケースにおいては、ａ）、ｂ）の方法は存在しても、異システム間で個々の「モノ」を同じ認識で識別する方法は限定的であった。ｃ）の例としてIEC 61360などがあるが、標準化されている範囲が限定的であり、広く普遍的に普及しているとは言えないなど、ｃ）としての機能は満たせていなかった。

【0012】

ｃ）の有力な候補として、緯度・経度・標高等の「モノ」の位置の座標データを挙げることができる。なぜならば、現実の世界の「モノ」は必ず３次元的な座標（１点で表現できない場合は座標の集合）を持っており、且つ、まったく同一の座標上に２つ以上の「モノ」は存在できないという物理的な排他原理が成り立つからである。つまり、３次元的な座標（１点で表現できない場合は座標の集合）は「モノ」の位置を表現すると共に、特に位置が変化しない静的な「モノ」をユニークに識別する識別子としての側面を持つと言える。

【0013】

従来、上記のｃ）の手段として３次元的な座標が使用されてこなかった理由は、以下のＡ）からＥ）の理由によるものと考えられる。
Ａ）この目的に合致する様な正確な精度の座標データを作成するためには、高いコストが必要だった。
Ｂ）３次元データを活用する動機が乏しかった。
Ｃ）「モノ」の位置が変化する場合には使えない。
Ｄ）「モノ」へのユニークな３次元座標の与え方が整備されていなかった。
Ｅ）魅力的な活用例の認知されていなかった。

【0014】

日本国内においては、「みちびき」などの高精度なＧＰＳ(Global Positioning System)や電子基準点の整備により、ＧＮＳＳ(Global Navigation Satellite System)測量機を用いたｃｍ単位での高精度測定が可能になってきている。また、３次元レーザースキャナ（LiDAR(Light Detection and Ranging)）技術の進展もあいまって、高精度な３次元データ作成コストが急速に低下しつつある。

【0015】

また、政府はＯｐｅｎＤａｔａの施策や、３次元空間情報基盤整備を進めようとしており、特に政府主導の入札工事物件では、工事データの３Ｄデータ化が必須化される予定であるなど、将来的には多くのデータが３次元座標に紐づいてデータ化されていく可能性が高くなっている。

【0016】

フォログラム等を用いた３Ｄ表示技術やＶＲ(Virtual Reality)技術など、実際に３次元データを活用するための基盤も急速に整ってきており、３次元データを活用する動機も高まりを見せている。

【0017】

以上の様な背景から、Ａ）、Ｂ）の懸念は払拭されつつあり、Ｃ）については、対象を位置の変化しない「モノ」に対象を限定するならば、Ｄ）、Ｅ）を解決すれば、前記のｃ）の手段として３次元的な座標データを用いることが有望な手段となり得る。

【0018】

本実施形態では、位置の変化しない「モノ」を扱うシステム間の情報連携の方法として、ａ）、ｂ）の具体例および、Ｄ）の解決手段を示すことにより、ｃ）の手段として３次元的な座標を用いることが可能であることを示す。

【0019】

図１は、本実施形態の自律分散システム１の一例を示す図である。本実施形態の自律分散システム１は、システム１００－１、システム１００－２、・・・、システム１００－ｎを備える。システム１００－１、システム１００－２、・・・、システム１００－ｎの各々は、ネットワークＮＷを介して接続される。ネットワークＮＷは、例えば、インターネット、ＷＡＮ(Wide Area Network)、ＬＡＮ(Local Area Network)、プロバイダ装置、無線基地局などを含む。

【0020】

システム１００－１、システム１００－２、・・・、システム１００－ｎの各々は、互いに相互に連携し合う。システム１００－１、システム１００－２、・・・、システム１００－ｎは、それぞれＧｅｏ－ＡＰＩ１０１－１、Ｇｅｏ－ＡＰＩ１０１－２、・・・、Ｇｅｏ－ＡＰＩ１０１－ｎを追加搭載している（アドオンしている）。Ｇｅｏ－ＡＰＩ１０１－１、Ｇｅｏ－ＡＰＩ１０１－２、・・・、Ｇｅｏ－ＡＰＩ１０１－ｎの各々は、共通の文法（データ交換のインタフェースとプロトコル）と、共通のデータ表現形式（データ交換のフォーマット）を実装するためのインタフェースである。

【0021】

また、システム１００－１、システム１００－２、・・・、システム１００－ｎは、ネットワークＮＷを介して地図情報３００、バーチャル地球儀システム４００、交通情報５００、オープンデータを利用する。オープンデータは、政府の推進するＯｐｅｎＤａｔａ施策に伴って広く公開される公共のデータであって、例えば、国土地理院が公開する地形情報（例えば、標高）や土地利用情報（例えば、土地利用区分）や、気象庁が公開する各種の気象情報（気温・風速の分布、日照分布、降雨・降雪・雷分布、地震・台風情報のリアルタイム値および／または予測値）などがある。今後、このオープンデータは増加の一途を辿ると予想される。その情報は、システム間の連携を高め新たな付加価値を生むために資するものである。

【0022】

本実施形態においては、共通の文法や共通のデータ表現形式の大枠は、既に存在する各種の定義をそのまま適用することができる。例えば、ＳＯＡＰ(Simple Object Access Protocol)、ＲＥＳＴ(Representational State Transfer)、Ｏｐｅｎ ＡＰＩ(application programming interface) ３．０(https://swagger.io/solutions/getting-started-with-oas/)などを挙げることができる。

【0023】

これらは何れも、データ交換の基本フォーマットやデータ交換の基本手順（枠組み）を定めるものであり、ｃ）に相当する定義は利用者マターとなっている。本実施形態では、一例として、ａ）ｂ）に関して新たに枠組みを新たに定義する必要はなく、既に確立しているこうした枠組みをそのまま活用する場合について説明を続ける。

【0024】

以下、システム１００－１、システム１００－２、・・・、システム１００－ｎのうち、任意のシステムを、システム１００と記載する。

【0025】

＜ａ）、ｂ）、ｃ）の具体化＞以下、前述した様なａ）ｂ）の既存の枠組みの中で、定義すべき具体的な「前提条件」、「機能定義」、「動作」を説明する。

【0026】

＜前提条件＞
１）全ての情報は、「３Ｄ座標識別子」を持った「モノ」として定義し、各「モノ」には様々な「属性値」を自由に持たせることができるものとする。
２）「３Ｄ座標識別子」には、代表的なものとして、以下の種類を設ける。
・ＰＯＩＮＴ（ポイント）（「モノ」の中心の３Ｄ座標）
・ＬＩＮＥ（ライン）（ライン形状の「モノ」の両端の３Ｄ座標）
・ＢＯＸ（ボックス）（矩形平面形状の「モノ」の矩形底面の左上座標と右下座標）
・３Ｄ－ＢＯＸ（直方体形状の「モノ」の底面の左上座標と右下座標と高さ）

【0027】

実際の「モノ」の形状は上記の様に単純なものとは限らないが、目的は「モノ」の形状を正確に３次元でデータ化することではなく、「モノ」をユニークに識別することである。このため、異なる「モノ」同士が互いに同一の識別子表現とならない範囲で形状の表現を単純化して扱うことができる。

【0028】

例えば、複雑な形状を持った変圧器があったとき、その変圧器をすっぽりと囲む直方体（３Ｄ－ＢＯＸを用いた３Ｄ座標識別子）で表現したとしても、その直方体と全く同一の３Ｄ座標識別子を有する他の「モノ」が存在しないならば、全く問題がない。勿論、実際の「モノ」の形状を詳細に３次元データでデータ化するようにしてもよい。

【0029】

なお、以上は使用頻度が多くなる代表的なものを記載したが、実際には、３次元データを取り扱う代表的なＧＩＳ(Geographic Information System)が使用している形式に習って様々なものを定義することが可能である。例えば、ＰｏｓｔＧＩＳ(https://postgis.net/docs/manual-3.0/using_postgis_dbmanagement.html#RefObject)が定義するポリゴンやＬＩＮＥＳＴＲＩＮＧ等を挙げることができる。ゆくゆくは、政府が推進している「３次元空間ＩＤ」を利用する方法も考えられる。

【0030】

３）各システム１００は配下の「モノ」を「３Ｄ座標識別子」で一意に管理するが、「３Ｄ座標識別子」とは別にそれぞれのシステム１００で固有に付与した「モノ」の識別子（以下、「ローカル識別子」と称する）を持っても良いものとする。以下、ローカル識別子と対となる表現として、「３Ｄ座標識別子」を「パブリック識別子」と称する。

【0031】

４）「モノ」を指定する際には、以下の方法を用いる。
・３Ｄ座標識別子（パブリック識別子）またはローカル識別子を直接指定する（個別指定）。
・３次元的な空間範囲を指定し、その範囲に含まれる「モノ」（Ｃｏｎｔａｉｎｓ）
・３次元的な空間範囲を指定し、その範囲と交差する「モノ」（Ｉｎｔｅｒｓｅｃｔｓ）
・ある３次元ＰＯＩＮＴに最も近い「モノ」（最近傍検索）

【0032】

本実施形態のシステム１００について説明する。図２は、本実施形態のシステム１００の一例を示す図である。システム１００は、パーソナルコンピュータ、サーバ、スマートフォン、タブレットコンピュータ又は産業用コンピュータ等の装置によって実現される。システム１００は、他のシステムとの間で情報を交換する。システム１００は、Ｇｅｏ－ＡＰＩ１０１および記憶部１１０を備える。

【0033】

Ｇｅｏ－ＡＰＩ１０１は、前述したように共通の文法（データ交換のインタフェースとプロトコル）と、共通のデータ表現形式（データ交換のフォーマット）を実装するためのインタフェースである。Ｇｅｏ－ＡＰＩ１０１は、他のシステムとの間で情報を交換する。

【0034】

Ｇｅｏ－ＡＰＩ１０１の詳細について説明する。図３は、本実施形態のシステム１００の動作の一例を示す図である。Ｇｅｏ－ＡＰＩ１０１は、機能確認、例えば、システム配下にどういう「モノ」があるかを返す。具体的には、Ｇｅｏ－ＡＰＩ１０１は、システム配下の「モノ」の一覧（３Ｄ座標識別子とローカル識別子とのペアの一覧）、および、各「モノ」の持つ属性値の識別子一覧、当該システムのカバーする３Ｄエリア範囲を示す３Ｄ－ＢＯＸを他のシステムへ返す。

【0035】

Ｇｅｏ－ＡＰＩ１０１は、特定範囲の概要確認、例えばそのシステム指定の３Ｄ空間範囲にどういう「モノ」があるかを返す。具体的には、Ｇｅｏ－ＡＰＩ１０１は、３Ｄ空間範囲を示す座標識別子、および、「モノ」の指定方法（個別／Ｃｏｎｔａｉｎｓ／Ｉｎｔｅｒｓｅｃｔｓ／最近傍）が入力された場合、当該システム配下の指定範囲の「モノ」の一覧（３Ｄ座標識別子とローカル識別子とのペアの一覧）、および、各「モノ」の持つ属性値の識別子一覧を他のシステムへ返す。

【0036】

Ｇｅｏ－ＡＰＩ１０１は、属性値読み出し、例えば指定する「モノ」の属性値を読み出す。具体的には、Ｇｅｏ－ＡＰＩ１０１は、３Ｄ空間範囲を示す座標識別子またはローカル識別子、および、「モノ」の指定方法（個別／Ｃｏｎｔａｉｎｓ／Ｉｎｔｅｒｓｅｃｔｓ／最近傍）、読み出す属性の識別子が入力された場合、指定の「モノ」の指定された属性値の一覧を他のシステムへ返す。

【0037】

Ｇｅｏ－ＡＰＩ１０１は、更新通知依頼、例えば指定範囲の「モノ」の属性値が変化したときに通知してもらう。具体的には、Ｇｅｏ－ＡＰＩ１０１は、３Ｄ空間範囲を示す座標識別子またはローカル識別子、および、「モノ」の指定方法（個別／Ｃｏｎｔａｉｎｓ／Ｉｎｔｅｒｓｅｃｔｓ／最近傍）、読み出す属性の識別子と、通知先とが入力された場合、指定の「モノ」の指定された属性値の一覧と変化時刻とを他のシステムへ返す。図２に戻り説明を続ける。

【0038】

記憶部１１０は、ＨＤＤ(Hard Disk Drive)やフラッシュメモリ、ＲＡＭ(Random Access Memory)、ＲＯＭ(Read Only Memory)などにより実現される。

【0039】

Ｇｅｏ－ＡＰＩ１０１の全部または一部は、例えば、ＣＰＵ(Central Processing Unit)などのプロセッサが記憶部１１０に格納されたプログラムを実行することにより実現される機能部（以下、ソフトウェア機能部と称する）である。なお、これらの全部または一部は、ＬＳＩ(Large Scale Integration)、ＡＳＩＣ(Application Specific Integrated Circuit)、またはＦＰＧＡ(Field-Programmable Gate Array)などのハードウェアにより実現されてもよく、ソフトウェア機能部とハードウェアとの組み合わせによって実現されてもよい。

【0040】

システム１００の動作について説明する。図４は、本実施形態のシステム１００の動作の一例を示すフロー図である。図４を参照して、主にシステム１００のＧｅｏ－ＡＰＩ１０１の動作について説明する。Ｇｅｏ－ＡＰＩ１０１は、利用者と公開用データ１１０ａとの間でフロント処理を行う（ステップＳ１－１）。フロント処理の詳細については後述する。

【0041】

公開用データ１１０ａについて説明する。図５は、公開用データ１１０ａの一例を示す図である。公開用データ１１０ａは、（１）ローカルＫｅｙ、（２）パブリックＫｅｙ、（３）パブリックＫｅｙの種類、（４）属性識別子、（５）属性の値および（６）通知先を関連付けたテーブル形式の情報である。ここで、ローカルＫｅｙとは、「ローカル識別子」のことである。ローカルＫｅｙの一例は、１、２、３、４、５、６、７、８、・・・である。パブリックＫｅｙとは「パブリック識別子」のことである。パブリックＫｅｙの一例は、（Ｘ１、Ｙ１、Ｚ１）、（Ｘ２、Ｙ２、Ｚ２）、（Ｘ３、Ｙ３、Ｚ３）、（Ｘ４、Ｙ４、Ｚ４）、Ｈ５、（Ｘ６、Ｙ６、Ｚ６）、（Ｘ７、Ｙ７、Ｚ７）、（Ｘ８、Ｙ８、Ｚ８）、（Ｘ９、Ｙ９、Ｚ９）、・・・である。パブリックＫｅｙの種類とは、「パブリック識別子」の種類のことである。パブリックＫｅｙの種類の一例は、３Ｄ－ＰＯＩＮＴ、３Ｄ－ＢＯＸ、３Ｄ－ＬＩＮＥなどである。属性識別子とは、属性を識別するための情報である。属性識別子の一例は、遮断器状態、開閉器状態、変圧器、母線、送電線、電圧有無、有効電力値などである。属性の値は、属性識別子で識別される属性に指定されている値である。属性の値の一例は、ＯＮ／ＯＦＦ、設備諸元、有／無、有効電力値である。通知先は、更新した内容を通知する先を特定する情報である。

【0042】

ローカルＫｅｙおよび通知先の少なくとも一方を含めないで公開用データ１１０ａを構成してもよい。利用者などの外部から見るとローカルＫｅｙの値自体は意味を持たない。内部（Ｇｅｏ－ＡＰＩ１０１のバックエンド処理）から見ると、ローカルＫｅｙの情報をＫｅｙとして内部の任意データにアクセスする。例えば、ＴＡＢＬＥの名称＋ＴＡＢＬＥの行を指定するＫｅｙからなる情報などをＫｅｙとして内部の任意データにアクセスする。図４に戻り、説明を続ける。

【0043】

Ｇｅｏ－ＡＰＩ１０１は、公開用データ１１０ａと内部データ１１０ｂとの間でバックエンド処理を行う（ステップＳ２－１）。バックエンド処理の詳細については後述する。例えば、Ｇｅｏ－ＡＰＩ１０１では、内部データ１１０ｂが更新されるとバックエンド処理が起動される。Ｇｅｏ－ＡＰＩ１０１は、内部データ１１０ｂの更新を、公開用データ１１０ａに反映する。Ｇｅｏ－ＡＰＩ１０１は、内部データ１１０ｂとの間で内部処理を行う（ステップＳ３－１）。

【0044】

フロント処理について説明する。図６は、本実施形態のシステム１００の動作の一例を示すフロー図である。
Ｇｅｏ－ＡＰＩ１０１は、ＡＰＩ要求を受け付ける（ステップＳ１－２）。例えば、Ｇｅｏ－ＡＰＩ１０１は、他のシステムからのＡＰＩ要求を受け付ける。Ｇｅｏ－ＡＰＩ１０１は、受け付けたＡＰＩ要求に含まれる要求種別が、概要確認、特定範囲の概要確認、属性値読み出しおよび更新通知依頼のいずれかであるかを判定する（ステップＳ２－２）。

【0045】

Ｇｅｏ－ＡＰＩ１０１は、要求種別が概要確認である場合に、配下のシステムの（１）ローカルＫｅｙ、（２）パブリックＫｅｙ、（３）パブリックＫｅｙの種類、（４）属性識別子を他のシステムへ返す（ステップＳ３－２）。Ｇｅｏ－ＡＰＩ１０１は、要求種別が特定範囲の概要確認である場合に、配下のシステムの指定座標範囲の（１）ローカルＫｅｙ、（２）パブリックＫｅｙ、（３）パブリックＫｅｙの種類、（４）属性識別子を他のシステムへ返す（ステップＳ４－２）。

【0046】

Ｇｅｏ－ＡＰＩ１０１は、要求種別が属性値読み出しである場合に、指定の識別子の（５）属性の値を他のシステムへ返す（ステップＳ５－２）。Ｇｅｏ－ＡＰＩ１０１は、要求種別が更新通知依頼である場合に、依頼内容を（６）通知先に書き込む（ステップＳ６－２）。ステップＳ３－２からＳ６－２のいずれかの終了後に、ステップＳ１－２へ戻る（ステップＳ７－２）。

【0047】

バックエンド処理について説明する。図７は、本実施形態のシステム１００の動作の一例を示すフロー図である。

【0048】

Ｇｅｏ－ＡＰＩ１０１は、更新された内部データ１１０ｂを確認する（ステップＳ１－３）。Ｇｅｏ－ＡＰＩ１０１は、更新されたデータのＫｅｙは、（１）ローカルＫｅｙにあるか否かを判定する。

【0049】

Ｇｅｏ－ＡＰＩ１０１は、更新されたデータのＫｅｙが（１）ローカルＫｅｙにあると判定した場合に（ステップＳ２－３：ＹＥＳ）、更新された内部データで、（５）属性の値を更新する（ステップＳ３－３）。Ｇｅｏ－ＡＰＩ１０１は、更新されたデータのＫｅｙが（１）ローカルＫｅｙにないと判定した場合に（ステップＳ２－３：ＮＯ）、終了する。

【0050】

Ｇｅｏ－ＡＰＩ１０１は、更新した（５）属性の値に対応した（６）通知先に通知先が登録されているか否かを判定する（ステップＳ４－３）。

【0051】

Ｇｅｏ－ＡＰＩ１０１は、更新した（５）属性の値に対応した（６）通知先に通知先が登録されている場合に（ステップＳ４－３：ＹＥＳ）、更新された内部データ１１０ｂの（５）属性の値と（１）ローカルＫｅｙとを、（６）通知先の宛先に通知する（ステップＳ５－３）。Ｇｅｏ－ＡＰＩ１０１は、更新した（５）属性の値に対応した（６）通知先に通知先が登録されていない場合に（ステップＳ４－３：ＮＯ）、終了する。

【0052】

本実施形態の自律分散システム１によれば、自律分散システム１は、複数のシステム１００を含む。複数のシステム１００の各々は独立して自律的に動作し、他のシステムとの間で情報を交換する情報交換部（実施形態では、Ｇｅｏ－ＡＰＩ１０１）を備える。情報は、第１情報識別子（実施形態では、パブリックｋｅｙ）と第１属性値との組によって表現され、第１情報識別子は、「モノ」の位置の３次元座標である。

【0053】

また、複数のシステム１００の各々は、交換する情報の表現形式としてパブリック形式とローカル形式とを有し、パブリック形式では、情報が、第１情報識別子と第１属性値との組によって表現され、ローカル形式では、情報が、各システムで独自に定義されている第２情報識別子（実施形態では、ローカルｋｅｙ）と第２属性値との組によって表現され、情報交換部は、外部からの要求に応じてパブリック形式とローカル形式との対応関係を交換する。

【0054】

本実施形態の自律分散システム１によれば、以下の効果を奏する。

【0055】

「モノ」を３次元でデータ化する際に必ずしも「モノ」の形状を正確にデータ化する必要はなく、異なる「モノ」同士が互いに同一の「３Ｄ座標識別子」とならない（重複しない）範囲で形状を単純化して扱うことができる。つまり、３Ｄデータを作成するコストを最小限に抑えることができる。

【0056】

「モノ」を３次元データでデータ化した場合、「３Ｄ座標識別子（パブリック識別子）」のサイズが大きいものとなり得るが、「３Ｄ座標識別子」と「ローカル識別子」の対応表を予め交換しておき、平常時においては、サイズの小さい「ロアウトプットーカル識別子」を用いることによって「３Ｄ座標識別子」を用いる場合と同じアウトプットを得ることができる。つまり、ネットワーク上に流れる情報量の増加を最小限に抑えることができる。

【0057】

「３Ｄ座標識別子（パブリック識別子）」と「ローカル識別子」とを併用できるため、既存システムに対しては、Ｇｅｏ－ＡＰＩをアドオンすることによって、自律分散システム１に参画することが可能であり、最初からシステムを再設計し直す必要性が無い。

【0058】

以下、本実施形態の方法によりシステム間で３Ｄ座標ベースでの情報交換が可能となった場合に、新たな付加価値を生じ得ることを２つの適用例を用いて示す。

【0059】

（実施形態の変形例１）実施形態の自律分散システム１の適用例について説明する。図８は、実施形態の変形例１の自律分散システム１ａを示す構成図である。

【0060】

自律分散システム１ａは、自律分散システム１に、情報共有システム２００を備えたものである。情報共有システム２００は、ネットワークＮＷ２を介して端末装置７００と接続される。ネットワークＮＷ２は、例えば、インターネット、ＷＡＮ、ＬＡＮ、プロバイダ装置、無線基地局などを含む。

【0061】

情報共有システム２００は、パーソナルコンピュータ、サーバ、スマートフォン、タブレットコンピュータ又は産業用コンピュータ等の装置によって実現される。情報共有システム２００は、互いに横連携が進んだシステム１００－１、システム１００－２、・・・、システム１００－ｎから情報を集めて、新たな付加価値を付与する。情報共有システム２００は、クラウドサーバであってもよい。

【0062】

情報共有システム２００は、Ｇｅｏ－ＡＰＩ２０１、データ仮想化部２０２および記憶部２１０を備える。

【0063】

Ｇｅｏ－ＡＰＩ２０１は、前述したように共通の文法（データ交換のインタフェースとプロトコル）と、共通のデータ表現形式（データ交換のフォーマット）を実装するためのインタフェースである。

【0064】

データ仮想化部２０２は、データ仮想化処理を行う。データ仮想化処理については後述する。
記憶部１１０は、ＨＤＤやフラッシュメモリ、ＲＡＭ、ＲＯＭなどにより実現される。

【0065】

Ｇｅｏ－ＡＰＩ２０１、データ仮想化部２０２およびデータ仮想化部２０２の全部または一部は、例えば、ＣＰＵなどのプロセッサが記憶部２１０に格納されたプログラムを実行することにより実現される機能部（以下、ソフトウェア機能部と称する）である。なお、これらの全部または一部は、ＬＳＩ、ＡＳＩＣ、またはＦＰＧＡなどのハードウェアにより実現されてもよく、ソフトウェア機能部とハードウェアとの組み合わせによって実現されてもよい。

【0066】

端末装置７００は、パーソナルコンピュータ、サーバ、スマートフォン、タブレットコンピュータ又は産業用コンピュータ等の装置によって実現される。端末装置７００は、ネットワークＮＷ２を介して、情報共有システム２００と接続し、情報を取得する。ネットワークＮＷとネットワークＮＷ２とが同じであってもよい。

【0067】

情報共有システム２００の動作について説明する。図９は、実施形態の変形例１の情報共有システムの動作の一例を示す図である。

【0068】

データ仮想化部２０２は、公開用データ２１０ａの初期化処理を行う（ステップＳ１－４）。初期化処理の詳細については後述する。ここで、公開用データ２１０ａについて説明する。図１０は、公開用データ２１０ａの一例を示す図である。公開用データ２１０ａは、（１）ローカルＫｅｙ、（２）パブリックＫｅｙ、（３）パブリックＫｅｙの種類、（４）属性識別子、（５）属性の値、（６）通知先、（７）参照先ＵＲＬ(Uniform Resource Locator)および（８）グローバルＫｅｙを関連付けたテーブル形式の情報である。参照先ＵＲＬは、当該行のデータを取得する為の参照先サーバのＵＲＬである。参照先ＵＲＬの一例は、ＵＲＬ－１、ＵＲＬ－２、・・・、ＵＲＬ－ｎ（ｎは、ｎ＞０の整数である）である。グローバルＫｅｙは、当該行のデータを取得する際、参照先サーバから情報を取り出すときのグローバル識別子のことである。ローカルＫｅｙおよび通知先の少なくとも一方を含めないで公開用データ２１０ａを構成してもよい。図９に戻り説明を続ける。

【0069】

Ｇｅｏ－ＡＰＩ２０１は、公開用データ２１０ａとの間でフロント処理を行う（ステップＳ２－４）。フロント処理の詳細については後述する。

【0070】

Ｇｅｏ－ＡＰＩ２０１は、公開用データ２１０ａとの間でバックエンド処理を行う（ステップＳ３－４）。バックエンド処理の詳細については後述する。

【0071】

初期化処理について説明する。図１１は、実施形態の変形例１の情報共有システム２００の動作の一例を示すフロー図である。

【0072】

データ仮想化部２０２は、公開用データ２１０ａから仮想化対象のＵＲＬ一覧を取り出す（ステップＳ１－５）。具体的には、データ仮想化部２０２は、公開用データ２１０ａの参照先ＵＲＬから仮想化対象のＵＲＬ一覧を取り出す。

【0073】

データ仮想化部２０２は、取り出したＵＲＬ一覧に含まれるＵＲＬに対して概要確認を要求する（ステップＳ２－５）。データ仮想化部２０２は、概要確認を要求によって得られた情報で公開用データ２１０ａを更新する（ステップＳ３－５）。

【0074】

データ仮想化部２０２は、個々の（１）ローカルＫｅｙに関する属性値の読み出しを要求する（ステップＳ４－５）。データ仮想化部２０２は、属性値の読み出しの要求によって得られた情報で公開用データ２１０ａを更新する（ステップＳ５－５）。データ仮想化部２０２は、個々の（１）ローカルＫｅｙに関して、更新通知依頼を要求する（ステップＳ６－５）。ステップＳ４－５からＳ６－５が繰り返され、その後ステップＳ２－５からＳ２－６が繰り返される。

【0075】

フロント処理について説明する。図１２は、実施形態の変形例１の情報共有システム２００の動作の一例を示すフロー図である。

【0076】

Ｇｅｏ－ＡＰＩ２０１は、ＡＰＩ要求を受け付ける（ステップＳ１－６）。例えば、Ｇｅｏ－ＡＰＩ２０１は、端末装置７００からのＡＰＩ要求を受け付ける。Ｇｅｏ－ＡＰＩ２０１は、受け付けたＡＰＩ要求に含まれる要求種別が、概要確認、特定範囲の概要確認、属性値読み出しおよび更新通知依頼のいずれかであるかを判定する（ステップＳ２－６）。

【0077】

Ｇｅｏ－ＡＰＩ２０１は、要求種別が概要確認である場合に、配下のシステムの（８）グローバルＫｅｙ、（２）パブリックＫｅｙ、（３）パブリックＫｅｙの種類、（４）属性識別子を端末装置７００へ返す（ステップＳ３－６）。Ｇｅｏ－ＡＰＩ２０１は、要求種別が特定範囲の概要確認である場合に、配下のシステムの指定座標範囲の（８）グローバルＫｅｙ、（２）パブリックＫｅｙ、（３）パブリックＫｅｙの種類、（４）属性識別子を端末装置７００へ返す（ステップＳ４－６）。

【0078】

Ｇｅｏ－ＡＰＩ２０１は、要求種別が属性値読み出しである場合に、指定の識別子の（５）属性の値を端末装置７００へ返す（ステップＳ５－６）。Ｇｅｏ－ＡＰＩ２０１は、要求種別が更新通知依頼である場合に、依頼内容を（６）通知先に書き込む（ステップＳ６－６）。ステップＳ３－６からＳ６－６のいずれかの終了後に、ステップＳ１－６へ戻る（ステップＳ７－６）。

【0079】

バックエンド処理について説明する。図１３は、実施形態の変形例１の情報共有システムの動作の一例を示すフロー図である。

【0080】

Ｇｅｏ－ＡＰＩ２０１は、更新された内部データ２１０ｂを確認する（ステップＳ１－７）。Ｇｅｏ－ＡＰＩ２０１は、更新されたデータのＫｅｙは、（１）ローカルＫｅｙにあるか否かを判定する。

【0081】

Ｇｅｏ－ＡＰＩ２０１は、更新されたデータのＫｅｙが（１）ローカルＫｅｙにあると判定した場合に（ステップＳ２－７：ＹＥＳ）、更新された内部データで、（５）属性の値を更新する（ステップＳ３－７）。Ｇｅｏ－ＡＰＩ２０１は、更新されたデータのＫｅｙが（１）ローカルＫｅｙにないと判定した場合に（ステップＳ２－７：ＮＯ）、終了する。

【0082】

Ｇｅｏ－ＡＰＩ２０１は、更新した（５）属性の値に対応した（６）通知先に通知先が登録されているか否かを判定する（ステップＳ４－７）。Ｇｅｏ－ＡＰＩ２０１は、更新した（５）属性の値に対応した（６）通知先に通知先が登録されている場合に（ステップＳ４－７：ＹＥＳ）、更新された内部データ２１０ｂの（５）属性の値と（８）グローバルＫｅｙとを、（６）通知先の宛先に通知する（ステップＳ５－７）。Ｇｅｏ－ＡＰＩ２０１は、更新した（５）属性の値に対応した（６）通知先に通知先が登録されていない場合に（ステップＳ４－７：ＮＯ）、終了する。

【0083】

自律分散システム１ａの情報共有システム２００が、互いに横連携が進んだシステム１００－１、システム１００－２、・・・、システム１００－ｎから情報を集めて作成する画面イメージについて説明する。図１４は、実施形態の変形例１の情報共有システム２００の動作の一例を示す図である。図１４は、例えばバーチャル地球儀システムの様な３次元データを扱える汎用ビューワー上に全てのシステムの情報を統一的な手段で地図情報を表示したものである。このように構成することによって、情報共有システム２００を、地図情報データベースとして機能させることができる。

【0084】

実施形態の変形例１によれば、自律分散システム１ａは、自律分散システム１に複数のシステムから情報を取得して動作する情報共有システム２００をさらに備える。情報共有システム２００は、地図情報データベースである。

【0085】

実施形態の変形例１は、以下の効果（付加価値）を得ることができる。

【0086】

自律分散システムに参画したシステムの全ての情報をあたかも単一のＧＩＳ上の情報の様に見せかけることができる。

【0087】

全ての情報を同じビューワー（例えば、バーチャル地球儀システム）の上で統一的に取り扱うことができる。

【0088】

地理的、座標的に近い情報をまとめて表示することができるため、情報間の相関をユーザに「気づき」として提供できる。ユーザにこうした「気づき」を元に情報活用を深耕させることができる。

【0089】

更には、より積極的に情報間の相関をシステム的に算出し、相関情報を付加価値として提供することもできる。例えば、相関分析等の統計手法を用いることで、情報間の相関をシステム的に算出できる。

【0090】

座標的に近い「モノ」が結びつくことによって、システム相互の連携が進むと、様々な相互関係が生まれ、ひいては、風が吹けば桶屋が儲かる的な思わぬ関係性（セレンティビティ）を見いだせる可能性がある。

【0091】

（実施形態の変形例２）実施形態の自律分散システム１の適用例について説明する。図１５は、実施形態の変形例２の自律分散システム１ｂを示す構成図である。

【0092】

実施形態の変形例２の自律分散システム１ｂは、自律分散システム１と、システム１００－１、システム１００－２、・・・、システム１００－ｎの代わりに、システム１００ｂ－１、システム１００ｂ－２、・・・、システム１００ｂ－ｎを備える点で異なる。システム１００ｂ－１、システム１００ｂ－２、・・・、システム１００ｂ－ｎは、互いに横連携することで情報を集めて、新たな付加価値を生成する。

【0093】

システム１００ｂ－１、システム１００ｂ－２、・・・、システム１００ｂ－ｎのうち任意のシステムをシステム１００ｂと記載する。

【0094】

システム１００ｂについて説明する。図１６は、実施形態の変形例２のシステム１００ｂを示す図である。システム１００ｂは、パーソナルコンピュータ、サーバ、スマートフォン、タブレットコンピュータ又は産業用コンピュータ等の装置によって実現される。システム１００ｂは、他のシステムとの間で情報を交換する。システム１００ｂは、Ｇｅｏ－ＡＰＩ１０１、処理部１０４、算出部１０６および記憶部１１０を備える。

【0095】

処理部１０４は、ノードとブランチに３次元座標情報を付与する処理などを行う。処理部１０４の処理の詳細については後述する。

【0096】

算出部１０６は、潮流計算、状態推定、ＯＰＦ(Optimal Power Flow)（最適潮流計算）、経済負荷配分計算、安定度計算などの系統計算を行う。算出部１０６の処理の詳細については後述する。
記憶部１１０は、ＨＤＤやフラッシュメモリ、ＲＡＭ、ＲＯＭなどにより実現される。

【0097】

Ｇｅｏ－ＡＰＩ１０１、処理部１０４および算出部１０６の全部または一部は、例えば、ＣＰＵなどのプロセッサが記憶部１１０に格納されたプログラムを実行することにより実現される機能部（以下、ソフトウェア機能部と称する）である。なお、これらの全部または一部は、ＬＳＩ、ＡＳＩＣ、またはＦＰＧＡなどのハードウェアにより実現されてもよく、ソフトウェア機能部とハードウェアとの組み合わせによって実現されてもよい。

【0098】

システム１００ｂの動作について説明する。図１７は、実施形態の変形例２のシステム１００ｂの動作の一例を示す図である。システム１００ｂの一例は、電力会社が系統運用上必要となる潮流計算や状態推定、ＯＰＦなどの系統計算を行う。具体的には、システム１００ｂは、システムＡの提供するノード・ブランチ、システムＢの提供するノード・ブランチおよびシステムＣの提供するノード・ブランチを取得し、取得したノード・ブランチに基づいて超並列で高速処理を行うことによって、潮流計算、状態推定、ＯＰＦ、経済負荷配分計算、安定度計算などを行う。

【0099】

系統計算では、設備の情報は「ノード・ブランチ」と呼ばれる抽象化されたトポロジーの形態で扱われる。系統計算のトポロジーは、ノードとノードが、“あるインピーダンス”を持ったブランチで繋がっている、という情報の集合体である。図１８は、実施形態の変形例２の自律分散システム１ｂでの設備の情報の一例を示す図である。図１８に示される例では、ノードＮＯ０１とノードＮＯ０２とノードＮＯ０３とが示される。さらに、ノードＮＯ０１とノードＮＯ０２がインピーダンスを持ったブランチＢＲ１２で繋がり、ノードＮＯ０２とノードＮＯ０３がインピーダンスを持ったブランチＢＲ２３で繋がっていることが示される。

【0100】

＜ノード・ブランチの表現方法＞図１９から図２４を参照して、ノード・ブランチの表現例について説明する。
＜ノード：母線＞図１９は、実施形態の変形例２の母線の表現例を示す図である。系統計算におけるノードとは、具体的には電力会社の変電所の「母線」と呼ばれる一定の直径を持った棒状の伝導体設備（巨大な鉄パイプの様なもの）である。左側はリアルワールドの３Ｄモデルの母線ＢＢであり、２か所の端点ＥＰを有する。右側は母線ＢＢを太線化したもの（太線化した母線ＢＢＲ）であり、２か所の端点ＥＰはリアルワールドの３Ｄモデルの２か所の端点ＥＰと同じである。ここでは棒状の母線ＢＢを一定の太さを持ったライン（３Ｄ太ＬＩＮＥ）として定義する。尤度を持たせるために敢えて少し太めのＬＩＮＥで定義する。太線化することによって端点の座標精度に尤度を持たせることができる。

【0101】

＜ブランチ：送電線＞図２０は、実施形態の変形例２の送電線の一例を示す図である。ブランチは、電力会社の変電所の「変圧器」または変電所間を繋ぐ「送電線」に対応する。一般的には開閉器や断路器等のスイッチを介して母線（ノード）に繋がっている。ここではブランチの端点ＥＰを３次元のポイント座標（３Ｄ－ＰＯＩＮＴ）で定義する。点ではなく、一定の半径を持った球体で定義しても良い。このとき半径が接続の尤度を意味するようにしてもよい。

【0102】

図２０は、リアルワールドの３Ｄモデルの送電線ＰＬを示す。この場合、リアルワールドの３Ｄモデルの送電線ＰＬをそのまま適用する。２か所の端点ＥＰはリアルワールドの３Ｄモデルの２か所の端点ＥＰと同じである。送電線ＰＬのインピーダンスはＬＩＮＥＳＴＲＩＮＧの属性値で表現される。ＬＩＮＥＳＴＲＩＮＧは荒くてもよく、端点ＥＰが重要である。

【0103】

図２１は、実施形態の変形例２の母線と送電線の一例を示す図である。図２１は、太線化した母線ＢＢＲに送電線ＰＬを接続したものである。送電線ＰＬの端点ＥＰが太線化した母線ＢＢＲで表される鉄パイプにめり込んでいる。つまり、太線化した母線ＢＢＲと送電線ＰＬとが電気的につながっていることを意味している。各ブランチとノードとの繋がり（トポロジー）は、各ブランチ端点ＥＰの３Ｄ－ＰＯＩＮＴがどのノード（３Ｄ太ＬＩＮＥ）と空間的につながっているかによって表現可能である。図２１では、簡単化の為にスイッチの存在は省略されている。

【0104】

実際の変電所でも母線と送電線は立体的に交差しながら繋がっており、この目的には３次元での表現が必要であり、これは、２次元のデータ表現では実現し得ない特徴となる。

【0105】

＜ブランチ：変圧器＞図２２は、本実施形態の変形例２の変圧器の一例を示す図である。左側はリアルワールドの３Ｄモデルの変圧器ＴＲであり、２か所の端点ＥＰを有する。右側は左側の変圧器ＴＲを抽象化したものであり、リアルワールドの３Ｄモデルの２か所の端点ＥＰをラインで繋いだものである。

【0106】

ブランチとしてのもうひとつの代表例である変圧器ＴＲについて説明する。系統計算を実施する上では、変圧器ＴＲの形状は意味を持たない。そのため、シンプルに単純なラインとして変圧器ＴＲを表現し、その両端の端点は、（３Ｄ－ＰＩＮＴ）座標で表現し、実際の変圧器ＴＲの端点（隣接設備との接続点）の座標と一致する様に定義する。３Ｄ－ＰＩＮＴは尤度を作る為に一定の半径を持った球体としても良い。

【0107】

変圧器ＴＲのインピーダンスやタップの情報は、当該ラインの属性値として表現する。変圧器ＴＲも送電線ＰＬと同様に、遮断器や断路器等のスイッチを介して母線ＢＢに接続する。よって、「隣接設備」とは、通常は遮断器や断路器等のスイッチとなる。

【0108】

＜ブランチ：スイッチ＞縮約する前のノード・ブランチの扱い。図２３は、本実施形態の変形例のスイッチの一例を示す図である。左側はリアルワールドの３Ｄモデルの遮断器ＣＢと開閉器ＬＳとが直列に接続されたものであり、２か所の端点ＥＰを有する。右側は左側の遮断器ＣＢと開閉器ＬＳとが直列に接続されたものを抽象化したものであり、リアルワールドの３Ｄモデルの２か所の端点ＥＰをラインで繋いだものである。

【0109】

スイッチは、系統計算上、その形状には意味を持たない。よって、端点ＥＰと端点ＥＰとをつなぐシンプルなラインとして定義する。その両端の端点は、（３Ｄ－ＰＩＮＴ）座標で表現し、隣接設備の端点ＥＰの座標と一致する様に定義する。スイッチの入り／切り状態は、そのラインの属性値として表現する。

【0110】

ここまではトポロジーを表す際、簡単化のためにスイッチの存在は無視して記載したが、以上の様にスイッチの存在は、変圧器ＴＲと同様の扱いとなるため、同様の考え方でトポロジーを表現することが可能である。

【0111】

＜３相設備の単相化方法＞図２４は、実施形態の変形例の電力系統設備の一例を示す図である。実際の電力系統設備は、全て３相交流を扱うための設備である為、３つの設備が常にセットで管理される。系統計算においては、この３つのセット（Ｒ相ＲＰ、Ｓ相ＳＰ、Ｔ相ＴＰ）をそれぞれ詳細に模擬して取り扱う場合（故障計算）と、３セットが全て同一の特性を持った設備との仮定の元、単相に変換して扱う場合がある（一般的な潮流計算）。後者の場合は、図２４に示すように、３つのセット（Ｒ相ＲＰ、Ｓ相ＳＰ、Ｔ相ＴＰ）として存在する設備の座標的に中心に存在する設備だけを残すことによって、単相ＭＰのトポロジーを表現できる。

【0112】

図２５は、実施形態の変形例２の自律分散システム１ｂの動作の一例を示すフロー図である。図２５を参照して、システム１００ｂが実行する初期の処理フローの一例について説明する。

【0113】

処理部１０４は、系統計算に必要な電力系統設備の設備データをデータ化する（ステップＳ１－８）。処理部１０４は、設備データ間の電気的な接続関係をデータ化する（ステップＳ２－８）。

【0114】

処理部１０４は、スイッチの状態を加味して、系統計算に必要なノード・ブランチを作成する（ステップＳ３－８）。処理部１０４は、ノード・ブランチに３Ｄ座標識別子を付与する（ステップＳ４－８）。Ｇｅｏ－ＡＰＩ１０２は、システム間でノード・ブランチに付与された３Ｄ座標識別子を交換する（ステップＳ５－８）。

【0115】

処理部１０４は、システム全体のノード・ブランチを作成する（ステップＳ６－８）。算出部１０６は、系統計算を実施する（ステップＳ７－８）。図２５によれば、既存システムに対してＧｅｏ－ＡＰＩをアドオンすることができる。

【0116】

図２６は、実施形態の変形例２の自律分散システム１ｂの動作の一例を示すフロー図である。図２６を参照して、「３Ｄ座標識別子」による効果が広く認知された後にシステム１００ｂが実行する処理フローの一例について説明する。

【0117】

処理部１０４は、系統計算に必要な電力系統設備の設備データをデータ化する（ステップＳ１－９）。処理部１０４は、３Ｄデータから設備データ間の電気的な接続関係を自動算出する（ステップＳ２－９）。

【0118】

処理部１０４は、スイッチの状態を加味して、系統計算に必要なノード・ブランチを作成する（ステップＳ３－９）。Ｇｅｏ－ＡＰＩ１０１は、システム間でノード・ブランチに付与された３Ｄ座標識別子を交換する（ステップＳ４－９）。

【0119】

処理部１０４は、システム全体のノード・ブランチを作成する（ステップＳ５－９）。算出部１０６は、系統計算を実施する（ステップＳ６－９）。図２６によれば、「３Ｄ座標識別子」によるメリットを積極的に活用できる。

【0120】

実施形態の変形例２では、自律分散システム１ｂに参画する各システム１００ｂが電力系統の系統計算を実施する場合について説明したが、この例に限られない。例えば、実施形態の変形例１と同様に、ネットワークＮＷを介して接続される情報共有システム備えるように構成してもよい。情報共有システムは、各システム１００ｂから「３次元座標識別子」で表現されたノード・ブランチの情報を取得し、取得したノード・ブランチの情報に基づいて、電力系統の系統計算を行うようにしてもよい。このように構成することによって、各システム１００ｂの処理負荷を低減できる。

【0121】

実施形態の変形例２の自律分散システム１ｂによれば、複数のシステム１００ｂの各々は、電力系統の系統計算を実施する算出部１０６をさらに備える。情報交換部は、各システムが個々に作成するノード・ブランチの情報を交換する。

【0122】

このように構成することによって、複数のシステム１００ｂの各々は、ノード・ブランチを「３次元座標識別子」で表現し、それを互いにＧｅｏ－ＡＰＩで交換できるため、自律分散システム１ｂに参画する各システム１００ｂは、自律分散システム１ｂに参画するシステム全体のノードブランチ（トポロジー）を容易に構成することが可能となる。つまり自律分散システムに参画するシステム全体の系統計算の実行が可能となる。自律分散システム１ｂに参画するシステム全体の系統計算が可能であるため、全体としてより最適な運転状態の解を求めること、例えば、運転コストの最小化ができる。

【0123】

運転コストを最小化することによって自律分散システム１ｂに参画するシステム全体として得られた運転コスト削減益を参画するシステム１００ｂにインセンティブとして分配することにより、Ｇｉｖｅ＆Ｔａｋｅの関係を成立させることができる。

【0124】

なお、同一の電力会社内であってもシステムが異なると異なる設備コード体系となっているケースも多いため、この考え方は異なる電力会社間で適用できるのみならず、同一の電力会社内の複数システム間において適用することも可能である。

【0125】

また、上述した様に、従来は系統計算の世界においても、３次元データを活用する動機が乏しかったが、系統計算の世界に３次元データを用い、さらに自律分散システム１ｂに参画するシステム１００ｂを増加させることによって、以下の効果を得ることができる。このため、３次元データ作成コスト低減に伴って、系統計算への３次元データ導入の動機は拡大しつつある。

【0126】

ＤＬＲ（ダイナミックラインレーティング）への適用メリットについて説明する。送電線容量は風況や気温等で変化する（風況が支配的）。送電線路の設置方向や３次元的な地形情報に加えて、風況や気温等のリアルタイムな分布状況を元に送電容量を動的に計算することにより、従来よりも、より正しい送電容量を計算することができる。

【0127】

ＦＬ（フォールトロケータ）の故障点算出への適用メリットについて説明する。ＦＬ装置から求まる故障点までの距離情報は、具体的な送電線の３次元的な設置情報を元に計算することができるため、より正確な位置情報として算出できる。

【0128】

系統計算を行う各種システムでは、システムの更新や統廃合の際に、設備データの移行や統合などを行うことが多い。この際、同一の実設備に対して複数の設備コードが存在する場合がある。そうしたケースでは、それが同一の設備なのか異なる設備なのかを見分けるのは容易ではないが、３次元座標識別子により、設備が同一であるか否かを明確に識別できる。

【0129】

系統計算の際、送電線のインピーダンスの情報を正確に与えることは非常に重要である。送電線設備を３次元座標識別子で定義することによって、その長さデータとインピーダンスの整合性をチェクすることができ、誤りデータを除外することができる。あるいは、長さデータから適切なインピーダンスを算出することもできる。

【0130】

系統計算を行う各種システムでは、変電所の設備や送電線設備を「単線結線図」や「系統図」という形の画面を通して抽象化して扱っている。そのため以下の手順を踏んでいる。
（１）実設備を画面上に抽象化してレイアウト表現する（画面上で２Ｄ座標を付与する）。
（２）画面上にレイアウトされた設備と実設備との対応を取る（一般的には１点１点、現地との対向試験を実施して対応を担保する）。
上記（１）（２）の作業はノードとブランチに３次元座標情報を付与することにより自動的に生成することが可能であり、結果として、（１）（２）の作業工数を減らせると共に、（２）の作業の誤りを減らすことができる。

【0131】

更には、「単線結線図」や「系統図」を画面上でも実設備の３Ｄデータをそのまま３Ｄ表示することによって、（１）の作業自体を省略することも可能である。

【0132】

系統計算を行う各種システムでは、地下変電所、地中線等、地下で立体的に構築された設備も扱う。地下設備においては、設備管理、設備計画を行う上で、データの３次元化の価値が非常に高い。

【0133】

また、実施形態の変形例２では、系統計算に必要となる設備に対して付与する３Ｄ座標を必要最低限に絞り込めると共に、３Ｄ座標の定義に多少に尤度を設けることが可能であるため、導入しやすい。

【0134】

また、系統計算におけるノードとブランチは、従来、各ベンダが各ノードやブランチにベンダ独自のコードを割り振りって扱ってきた。異なるシステム間で系統計算に必要な情報を持ち寄って、より大規模な系統計算を実施したい場合には、設備データや電気的な接続を表現するデータ形式に「統一形式」を定義し、各システムはローカルな形式から統一形式への変換を行うことから始める必要があった。この統一は容易でなく、従来、異なるシステム間での連携を阻害する大きな要因となっていた。

【0135】

実施形態の変形例２では、ノード・ブランチに「３Ｄ座標識別子」を付与するというシンプルな方法によってこれを実現する。Ｇｅｏ－ＡＰＩで交換する「３Ｄ座標識別子」は、自律分散システムに参画する各システムにとって同じ意味を共有できるものであり、隣接するシステム間で互いのノード・ブランチをマージして広域の系統計算を行うことや、より多数のシステムでノード・ブランチを交換して複数システム全体としての系統計算を行うことができる。

【0136】

以上説明した少なくとも一つの実施形態によれば、複数のシステムの各々は、他のシステムとの間で第１情報識別子と第１属性値との組によって表現された情報を交換する場合に、第１情報識別子を「モノ」の位置の３次元座標とすることができるため、「モノ」を３次元でデータ化する際に必ずしも「モノ」の形状を正確にデータ化する必要はなく、異なる「モノ」同士が互いに同一の「３Ｄ座標識別子」とならない（重複しない）範囲で形状を単純化して扱うことができる。つまり、３Ｄデータを作成するコストを最小限に抑えることができる。

【0137】

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

【符号の説明】

【0138】

１、１ａ、１ｂ…自律分散システム、１００－１、１００－２、・・・、１００－ｎ、１００、１００ｂ－１、１００ｂ－２、・・・、１００ｂ－ｎ、１００ｂ…システム、１０１－１、１０１－２、・・・、１０１－ｎ、１０１…Ｇｅｏ－ＡＰＩ、１０４…処理部、１０６…算出部、１１０…記憶部、１１０ａ…公開用データ、１１０ｂ…内部データ、２００…情報共有システム、２０１…Ｇｅｏ－ＡＰＩ、２０２…データ仮想化部、２１０…記憶部、２１０ａ…公開用データ、２１０ｂ…内部データ、３００…地図情報、４００…バーチャル地球儀システム、５００…交通情報、６００…オープンデータ、７００…端末装置

【図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】

【図26】