JP7413471B1 - Autonomous decentralized system and information exchange method - Google Patents

Abstract

An object of the present invention is to provide an autonomous decentralized system and an information exchange method that allow different systems to operate in cooperation with each other. An autonomous distributed system according to an embodiment is an autonomous distributed system including a plurality of systems, each of which operates independently and autonomously, and each of the plurality of systems has an information exchange unit. have The information exchange unit exchanges information with other systems. Information is expressed by a pair of a first information identifier and a first attribute value, and the first information identifier is the three-dimensional coordinates of the position of the "thing". [Selection diagram] Figure 1

Description

Embodiments of the present invention relate to an autonomous decentralized system and an information exchange method.

As DX (Digital transformation: DX) progresses, a wide variety of information systems (hereinafter simply referred to as "systems") are being built in society. In the past, individual systems were built independently, and with some exceptions, there were few systems that operated in coordination with each other. If you look at these various systems from a bird's-eye view, there are many that have semantic relationships with each other, and it is possible to create new value by operating in cooperation with each other, or by organizing and integrating overlapping functions. , there is a possibility that the efficiency of society as a whole can be improved. However, at present, the coordination between each system has not progressed significantly.

Regarding technology for linking systems, highly flexible and easily expandable business systems are known (for example, see Patent Document 1).

JP2020-201771A

The problem to be solved by the present invention is to provide an autonomous decentralized system and an information exchange method that allow different systems to operate in cooperation with each other.

The autonomous distributed system of the embodiment is an autonomous distributed system including a plurality of systems, each of which operates independently and autonomously, and each of the plurality of systems has an information exchange unit. The information exchange unit exchanges information with other systems. The information is expressed by a pair of a first information identifier and a first attribute value, and the first information identifier is the three-dimensional coordinates of the position of the "thing".

FIG. 1 is a diagram showing an example of an autonomous decentralized system 1 according to the present embodiment. FIG. 1 is a diagram showing an example of a system 100 according to the present embodiment. The figure which shows an example of operation of the system 100 of this embodiment. FIG. 2 is a flow diagram showing an example of the operation of the system 100 of the present embodiment. A diagram showing an example of public data 110a. FIG. 2 is a flow diagram showing an example of the operation of the system 100 of the present embodiment. FIG. 2 is a flow diagram showing an example of the operation of the system 100 of the present embodiment. FIG. 3 is a configuration diagram showing an autonomous decentralized system 1a according to a first modification of the embodiment. FIG. 7 is a flow diagram illustrating an example of the operation of the information sharing system 200 according to modification 1 of the embodiment. A diagram showing an example of public data 210a. FIG. 7 is a flow diagram illustrating an example of the operation of the information sharing system 200 according to modification 1 of the embodiment. FIG. 7 is a flow diagram illustrating an example of the operation of the information sharing system 200 according to modification 1 of the embodiment. FIG. 7 is a flow diagram illustrating an example of the operation of the information sharing system 200 according to modification 1 of the embodiment. The figure which shows an example of operation of the information sharing system 200 of the modification 1 of embodiment. FIG. 7 is a configuration diagram showing an autonomous decentralized system 1b according to a second modification of the embodiment. The figure which shows the system 100b of the modification 2 of embodiment. The figure which shows an example of operation of the system 100b of the modification 2 of embodiment. The figure which shows an example of the information of the equipment in the autonomous decentralized system 1b of the modification 2 of embodiment. FIG. 7 is a diagram illustrating an example of expressing a generatrix according to modification 2 of the embodiment. The figure which shows an example of the power transmission line of the modification 2 of embodiment. The figure which shows an example of the bus line and the power transmission line of the modification 2 of embodiment. The figure which shows an example of the transformer of the modification 2 of embodiment. FIG. 7 is a diagram illustrating an example of a switch according to modification 2 of the embodiment. The figure which shows an example of the electric power system equipment of the modification 2 of embodiment. FIG. 7 is a flow diagram showing an example of the operation of the autonomous decentralized system 1b according to Modification 2 of the embodiment. FIG. 7 is a flow diagram showing an example of the operation of the autonomous decentralized system 1b according to Modification 2 of the embodiment.

Hereinafter, an autonomous decentralized system and an information exchange method according to an embodiment will be described with reference to the drawings. In the following description, components having the same or similar functions are given the same reference numerals. Further, redundant explanations of these configurations may be omitted.

The autonomous decentralized system 1 of this embodiment includes a plurality of systems. Each of the multiple systems operates independently and autonomously. In the autonomous decentralized system 1, a "common language" is established in each of the plurality of systems, which has the necessary functions to operate in cooperation with other systems. The functions necessary for a "common language" are as follows a) to c).
a) Common grammar (data exchange interfaces and protocols)
b) Common data representation format (data exchange format)
c) Identifiers that can share a common meaning (particularly a means of identifying each "thing" in the real world with a meaning attached to it)

Conventionally, there have been many systems for a) and b), but the scope of c) has often been limited, and a definition of c) that is likely to be widely and universally applicable in the future is still lacking. Not found.

For example, in a case where information on a wide variety of "things" is exchanged between different systems, even if methods a) and b) exist, there is a method for identifying individual "things" with the same recognition between different systems. was limited. An example of c) is IEC 61360, but the scope of standardization is limited and it cannot be said that it has been widely and universally used, so it does not fulfill the function of c).

As a promising candidate for c), coordinate data of the location of "things" such as latitude, longitude, and altitude can be cited. This is because "things" in the real world always have three-dimensional coordinates (or a set of coordinates if they cannot be represented by a single point), and two or more "things" on exactly the same coordinates This is because the physical exclusion principle holds true that it cannot exist. In other words, three-dimensional coordinates (or a set of coordinates if it cannot be represented by a single point) not only expresses the position of a "thing" but also serve as an identifier that uniquely identifies a static "thing" whose location does not change. It can be said that it has.

Conventionally, the reason why three-dimensional coordinates have not been used as the means for c) above is considered to be due to the following reasons A) to E).
A) High costs were required to create accurate coordinate data that would meet this purpose.
B) There was little motivation to utilize 3D data.
C) Cannot be used when the position of the "thing" changes.
D) There was no established way to give unique three-dimensional coordinates to "things."
E) Attractive usage examples were not recognized.

In Japan, the development of high-precision GPS (Global Positioning System) such as ``Michibiki'' and electronic reference points has made it possible to perform high-precision measurements in cm units using GNSS (Global Navigation Satellite System) surveying equipment. It's coming. In addition, with advances in 3D laser scanner (LiDAR (Light Detection and Ranging)) technology, the cost of creating highly accurate 3D data is rapidly decreasing.

In addition, the government is promoting OpenData measures and the development of 3D spatial information infrastructure, and in the future, it is planned that converting construction data into 3D data will be mandatory, especially for government-led bid construction properties. It is highly likely that much data will be linked to three-dimensional coordinates and converted into data.

The infrastructure for actually utilizing 3D data, such as 3D display technology using holograms and VR (Virtual Reality) technology, is rapidly being developed, and the motivation to utilize 3D data is increasing.

From the above background, concerns about A) and B) are being dispelled, and regarding C), if we limit the target to "things" whose position does not change, then D) and E) must be resolved. For example, using three-dimensional coordinate data as the means for c) above may be a promising means.

In this embodiment, as a method of information coordination between systems that handle "things" whose position does not change, we will show specific examples of a) and b), and a means of solving D), and as a means of c) three-dimensional This shows that it is possible to use specific coordinates.

FIG. 1 is a diagram showing an example of an autonomous decentralized system 1 of this embodiment. The autonomous decentralized system 1 of this embodiment includes a system 100-1, a system 100-2, . . . , a system 100-n. Each of the systems 100-1, 100-2, . . . , 100-n is connected via a network NW. The network NW includes, for example, the Internet, a WAN (Wide Area Network), a LAN (Local Area Network), a provider device, a wireless base station, and the like.

The systems 100-1, 100-2, . . . , 100-n mutually cooperate with each other. System 100-1, System 100-2, ..., System 100-n are additionally equipped with Geo-API101-1, Geo-API101-2, ..., Geo-API101-n (add-on are doing). Geo-API101-1, Geo-API101-2, ..., Geo-API101-n each have a common grammar (data exchange interface and protocol) and a common data representation format (data exchange format). This is an interface for implementation.

Further, the systems 100-1, 100-2, . . . , 100-n use map information 300, virtual globe system 400, traffic information 500, and open data via the network NW. Open data is public data that is widely released in accordance with the OpenData policy promoted by the government, and includes, for example, topographic information (e.g. elevation) and land use information (e.g. land use classification) published by the Geospatial Information Authority of Japan. and various weather information published by the Japan Meteorological Agency (temperature/wind speed distribution, sunshine distribution, rainfall/snowfall/lightning distribution, real-time values and/or predicted values of earthquake/typhoon information), etc. It is expected that this open data will continue to increase in the future. This information contributes to increasing coordination between systems and creating new added value.

In this embodiment, various existing definitions can be applied as they are to the general framework of the common grammar and common data expression format. Examples include SOAP (Simple Object Access Protocol), REST (Representational State Transfer), and Open API (application programming interface) 3.0 (https://swagger.io/solutions/getting-started-with-oas/). be able to.

All of these define the basic format for data exchange and the basic procedure (framework) for data exchange, and definitions corresponding to c) are user matters. In this embodiment, as an example, a case will be continued in which there is no need to newly define a framework regarding a) and b), and the already established framework is utilized as is.

Hereinafter, any system among system 100-1, system 100-2, . . . , system 100-n will be referred to as system 100.

<Concrete implementation of a), b), and c)> Hereinafter, specific "preconditions", "function definitions", and "operations" to be defined within the existing framework of a) and b) as described above. Explain.

<Prerequisites>
1) All information is defined as a "thing" with a "3D coordinate identifier", and each "thing" can be freely given various "attribute values".
2) The following types of "3D coordinate identifiers" are provided as typical ones.
・POINT (3D coordinates of the center of the "thing")
・LINE (3D coordinates of both ends of a line-shaped “thing”)
・BOX (upper left coordinates and lower right coordinates of the rectangular bottom of a rectangular planar "thing")
・3D-BOX (upper left coordinates, lower right coordinates and height of the bottom of the rectangular parallelepiped "thing")

Although the shape of an actual "thing" is not always as simple as shown above, the purpose is not to accurately convert the shape of the "thing" into three-dimensional data, but to uniquely identify the "thing". It is. Therefore, the shape representation can be simplified and handled within the range where different "things" do not have the same identifier representation.

For example, if there is a transformer with a complicated shape, even if it is expressed as a rectangular parallelepiped (3D coordinate identifier using 3D-BOX) that completely surrounds the transformer, a 3D coordinate identifier that is exactly the same as the rectangular parallelepiped will be used. If there are no other "things" that you have, there is no problem at all. Of course, the shape of the actual "thing" may be converted into detailed three-dimensional data.

In addition, although the above describes the typical ones that are used frequently, in reality, various things are defined following the format used by the typical GIS (Geographic Information System) that handles three-dimensional data. It is possible to do so. Examples include polygons and LINESTRING defined by PostGIS (https://postgis.net/docs/manual-3.0/using_postgis_dbmanagement.html#RefObject). Eventually, it may be possible to use the ``3D spatial ID'' promoted by the government.

3) Each system 100 uniquely manages the "things" under its control using "3D coordinate identifiers," but apart from the "3D coordinate identifiers," each system 100 uniquely assigns "thing" identifiers (hereinafter referred to as " local identifier). Hereinafter, the "3D coordinate identifier" will be referred to as a "public identifier" as a pair with the local identifier.

4) When specifying "things", use the following method.
- Directly specify the 3D coordinate identifier (public identifier) or local identifier (individual specification).
・Specify a three-dimensional spatial range and "things" included in that range (Contains)
・Specify a three-dimensional spatial range and create "things" that intersect with that range (Intersects)
・The “thing” closest to a certain 3D POINT (nearest neighbor search)

The system 100 of this embodiment will be explained. FIG. 2 is a diagram showing an example of the system 100 of this embodiment. The system 100 is realized by a device such as a personal computer, a server, a smartphone, a tablet computer, or an industrial computer. System 100 exchanges information with other systems. The system 100 includes a Geo-API 101 and a storage unit 110.

As described above, the Geo-API 101 is an interface for implementing a common grammar (data exchange interface and protocol) and a common data expression format (data exchange format). Geo-API 101 exchanges information with other systems.

The details of the Geo-API 101 will be explained. FIG. 3 is a diagram showing an example of the operation of the system 100 of this embodiment. The Geo-API 101 returns function confirmation, for example, what kind of "things" exist under the system. Specifically, the Geo-API 101 provides a list of "things" under the system (a list of pairs of 3D coordinate identifiers and local identifiers), a list of identifiers of attribute values that each "thing" has, and a list of the covers of the system. A 3D-BOX indicating the 3D area range to be used is returned to the other system.

The Geo-API 101 returns an overview of the specific range, for example, what kind of "things" are present in the system-specified 3D spatial range. Specifically, when a coordinate identifier indicating a 3D space range and a method for specifying "thing" (Individual/Contains/Intersects/Nearest Neighbor) are input, Geo-API 101 specifies " A list of "things" (a list of pairs of 3D coordinate identifiers and local identifiers) and a list of identifiers of attribute values of each "thing" are returned to other systems.

The Geo-API 101 reads attribute values, for example, reads the attribute value of a specified "thing". Specifically, when the Geo-API 101 inputs a coordinate identifier or local identifier indicating a 3D space range, a method of specifying "thing" (Individual/Contains/Intersects/Nearest Neighbor), and an identifier of the attribute to be read, Returns a list of specified attribute values of a specified "thing" to another system.

The Geo-API 101 requests an update notification request, for example, to receive a notification when the attribute value of a "thing" in a specified range changes. Specifically, the Geo-API 101 specifies the coordinate identifier or local identifier indicating the 3D space range, the method of specifying the "thing" (Individual/Contains/Intersects/Nearest Neighbor), the identifier of the attribute to be read, and the notification destination. If input, a list of specified attribute values and change times of the specified "thing" are returned to the other system. Returning to FIG. 2, the explanation will be continued.

The storage unit 110 is realized by an HDD (Hard Disk Drive), a flash memory, a RAM (Random Access Memory), a ROM (Read Only Memory), or the like.

All or part of the Geo-API 101 is a functional unit (hereinafter referred to as a software functional unit) that is realized by a processor such as a CPU (Central Processing Unit) executing a program stored in the storage unit 110. be. Note that all or part of these may be realized by hardware such as LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), or FPGA (Field-Programmable Gate Array), and the software function section and hardware It may also be realized in combination with clothing.

The operation of the system 100 will be explained. FIG. 4 is a flow diagram showing an example of the operation of the system 100 of this embodiment. Referring to FIG. 4, the operation of the Geo-API 101 of the system 100 will be mainly described. The Geo-API 101 performs front processing between the user and the public data 110a (step S1-1). Details of the front processing will be described later.

The public data 110a will be explained. FIG. 5 is a diagram showing an example of the public data 110a. The public data 110a is in a table format in which (1) local keys, (2) public keys, (3) types of public keys, (4) attribute identifiers, (5) attribute values, and (6) notification destinations are associated. It is information. Here, the local key is a "local identifier." Examples of local keys are 1, 2, 3, 4, 5, 6, 7, 8, . A public key is a "public identifier." Examples of public keys are (X1, Y1, Z1), (X2, Y2, Z2), (X3, Y3, Z3), (X4, Y4, Z4), H5, (X6, Y6, Z6), (X7 , Y7, Z7), (X8, Y8, Z8), (X9, Y9, Z9), . The type of public key is the type of "public identifier." Examples of types of public keys include 3D-POINT, 3D-BOX, and 3D-LINE. An attribute identifier is information for identifying an attribute. Examples of attribute identifiers include circuit breaker status, switch status, transformer, bus bar, power transmission line, presence or absence of voltage, and active power value. The value of the attribute is the value specified for the attribute identified by the attribute identifier. Examples of attribute values are ON/OFF, equipment specifications, presence/absence, and active power value. The notification destination is information that specifies the destination to which updated content is to be notified.

The public data 110a may be configured without including at least one of the local key and the notification destination. When viewed from outside, such as a user, the value of the local key itself has no meaning. From the inside (back-end processing of the Geo-API 101), internal arbitrary data is accessed using the local key information as a key. For example, internal arbitrary data is accessed using information consisting of the TABLE name+Key specifying the TABLE row as a key. Returning to FIG. 4, the explanation will be continued.

The Geo-API 101 performs back-end processing between the public data 110a and the internal data 110b (step S2-1). Details of the back-end processing will be described later. For example, in the Geo-API 101, back-end processing is activated when the internal data 110b is updated. The Geo-API 101 reflects the update of the internal data 110b in the public data 110a. The Geo-API 101 performs internal processing with the internal data 110b (step S3-1).

Front processing will be explained. FIG. 6 is a flow diagram showing an example of the operation of the system 100 of this embodiment.
Geo-API 101 accepts the API request (step S1-2). For example, Geo-API 101 accepts API requests from other systems. The Geo-API 101 determines whether the request type included in the received API request is one of summary confirmation, specific range summary confirmation, attribute value reading, and update notification request (step S2-2).

When the request type is summary confirmation, Geo-API 101 returns (1) local key, (2) public key, (3) public key type, and (4) attribute identifier of the subordinate system to other systems. (Step S3-2). When the request type is an overview of a specific range, the Geo-API 101 requests (1) local key, (2) public key, (3) type of public key, and (4) attribute of the specified coordinate range of the subordinate system. The identifier is returned to the other system (step S4-2).

When the request type is attribute value reading, the Geo-API 101 returns the value of the (5) attribute of the specified identifier to the other system (step S5-2). When the request type is an update notification request, the Geo-API 101 writes the request content to (6) the notification destination (step S6-2). After completing any one of steps S3-2 to S6-2, the process returns to step S1-2 (step S7-2).

Backend processing will be explained. FIG. 7 is a flow diagram showing an example of the operation of the system 100 of this embodiment.

The Geo-API 101 checks the updated internal data 110b (step S1-3). The Geo-API 101 determines whether the key of the updated data is in (1) the local key.

If the Geo-API 101 determines that the key of the updated data is (1) local key (step S2-3: YES), it updates (5) the attribute value with the updated internal data ( Step S3-3). When the Geo-API 101 determines that the key of the updated data is not in (1) the local key (step S2-3: NO), it ends.

The Geo-API 101 determines whether a notification destination is registered in (6) notification destination corresponding to the updated (5) attribute value (step S4-3).

If the notification destination is registered in the (6) notification destination corresponding to the updated (5) attribute value (step S4-3: YES), the Geo-API 101 updates (5) of the updated internal data 110b. The value of the attribute and (1) the local key are notified to the (6) notification destination (step S5-3). The Geo-API 101 ends when the notification destination is not registered in the (6) notification destination corresponding to the updated (5) attribute value (step S4-3: NO).

According to the autonomous decentralized system 1 of this embodiment, the autonomous decentralized system 1 includes a plurality of systems 100. Each of the plurality of systems 100 operates independently and autonomously, and includes an information exchange unit (Geo-API 101 in the embodiment) that exchanges information with other systems. Information is expressed by a set of a first information identifier (public key in the embodiment) and a first attribute value, and the first information identifier is the three-dimensional coordinates of the position of the "thing".

Furthermore, each of the plurality of systems 100 has a public format and a local format as expression formats for information to be exchanged, and in the public format, information is expressed by a pair of a first information identifier and a first attribute value, In the local format, information is expressed by a pair of a second information identifier (local key in the embodiment) and a second attribute value that is uniquely defined in each system, and the information exchange unit responds to external requests. The correspondence between the public format and the local format is exchanged accordingly.

According to the autonomous decentralized system 1 of this embodiment, the following effects are achieved.

When converting "things" into three-dimensional data, it is not necessarily necessary to accurately convert the shape of the "thing" into data, but as long as different "things" do not have the same "3D coordinate identifier" (do not overlap). Shapes can be simplified and handled. In other words, the cost of creating 3D data can be minimized.

When converting "things" into three-dimensional data, the size of the "3D coordinate identifier (public identifier)" may be large, but it is necessary to exchange the correspondence table between "3D coordinate identifier" and "local identifier" in advance. , in normal times, by using the small-sized "low output local identifier" it is possible to obtain the same output as when using the "3D coordinate identifier". In other words, the increase in the amount of information flowing on the network can be minimized.

Since the "3D coordinate identifier (public identifier)" and "local identifier" can be used together, it is possible to participate in the autonomous decentralized system 1 by adding Geo-API to an existing system. There is no need to redesign the system.

Hereinafter, it will be shown using two application examples that new added value can be generated when information exchange based on 3D coordinates is enabled between systems using the method of this embodiment.

(Modification 1 of the embodiment) An application example of the autonomous decentralized system 1 of the embodiment will be described. FIG. 8 is a configuration diagram showing an autonomous decentralized system 1a according to modification 1 of the embodiment.

The autonomous decentralized system 1a includes an information sharing system 200 in addition to the autonomous decentralized system 1. Information sharing system 200 is connected to terminal device 700 via network NW2. The network NW2 includes, for example, the Internet, WAN, LAN, provider device, wireless base station, and the like.

The information sharing system 200 is realized by a device such as a personal computer, a server, a smartphone, a tablet computer, or an industrial computer. The information sharing system 200 collects information from the systems 100-1, 100-2, . Information sharing system 200 may be a cloud server.

The information sharing system 200 includes a Geo-API 201, a data virtualization section 202, and a storage section 210.

As described above, the Geo-API 201 is an interface for implementing a common grammar (data exchange interface and protocol) and a common data expression format (data exchange format).

The data virtualization unit 202 performs data virtualization processing. The data virtualization process will be described later.
The storage unit 110 is realized by an HDD, flash memory, RAM, ROM, or the like.

All or part of the Geo-API 201, the data virtualization unit 202, and the data virtualization unit 202 are functional units (hereinafter referred to as (referred to as the software function section). Note that all or part of these may be realized by hardware such as LSI, ASIC, or FPGA, or may be realized by a combination of a software function unit and hardware.

The terminal device 700 is realized by a device such as a personal computer, a server, a smartphone, a tablet computer, or an industrial computer. The terminal device 700 connects to the information sharing system 200 via the network NW2 and acquires information. Network NW and network NW2 may be the same.

The operation of the information sharing system 200 will be explained. FIG. 9 is a diagram illustrating an example of the operation of the information sharing system according to modification 1 of the embodiment.

The data virtualization unit 202 performs initialization processing of the public data 210a (step S1-4). Details of the initialization process will be described later. Here, the public data 210a will be explained. FIG. 10 is a diagram showing an example of public data 210a. Publication data 210a includes (1) local key, (2) public key, (3) public key type, (4) attribute identifier, (5) attribute value, (6) notification destination, and (7) reference destination. This is table-format information that associates a URL (Uniform Resource Locator) and (8) global key. The reference destination URL is the URL of the reference destination server for acquiring the data of the row. Examples of reference destination URLs are URL-1, URL-2, ..., URL-n (n is an integer where n>0). The global key is a global identifier used to retrieve information from a reference server when acquiring data for the row. The public data 210a may be configured without including at least one of the local key and the notification destination. Returning to FIG. 9, the explanation will be continued.

The Geo-API 201 performs front processing with the public data 210a (step S2-4). Details of the front processing will be described later.

The Geo-API 201 performs back-end processing with the public data 210a (step S3-4). Details of the back-end processing will be described later.

The initialization process will be explained. FIG. 11 is a flow diagram illustrating an example of the operation of the information sharing system 200 according to the first modification of the embodiment.

The data virtualization unit 202 extracts a list of URLs to be virtualized from the public data 210a (step S1-5). Specifically, the data virtualization unit 202 extracts a list of URLs to be virtualized from the reference URLs of the public data 210a.

The data virtualization unit 202 requests summary confirmation for the URLs included in the retrieved URL list (step S2-5). The data virtualization unit 202 updates the public data 210a with the information obtained by requesting summary confirmation (step S3-5).

The data virtualization unit 202 requests reading of attribute values regarding each (1) local key (step S4-5). The data virtualization unit 202 updates the public data 210a with the information obtained in response to the attribute value read request (step S5-5). The data virtualization unit 202 requests an update notification request for each (1) local key (step S6-5). Steps S4-5 to S6-5 are repeated, and then steps S2-5 to S2-6 are repeated.

Front processing will be explained. FIG. 12 is a flow diagram illustrating an example of the operation of the information sharing system 200 according to the first modification of the embodiment.

Geo-API 201 accepts the API request (step S1-6). For example, the Geo-API 201 accepts an API request from the terminal device 700. The Geo-API 201 determines whether the request type included in the received API request is one of summary confirmation, specific range summary confirmation, attribute value reading, and update notification request (step S2-6).

When the request type is summary confirmation, the Geo-API 201 returns (8) global key, (2) public key, (3) public key type, and (4) attribute identifier of the subordinate system to the terminal device 700. (Step S3-6). Geo-API 201 provides (8) global key, (2) public key, (3) type of public key, and (4) attribute of the specified coordinate range of the subordinate system when the request type is an overview confirmation of a specific range. The identifier is returned to the terminal device 700 (step S4-6).

When the request type is attribute value reading, the Geo-API 201 returns the value of the (5) attribute of the specified identifier to the terminal device 700 (step S5-6). When the request type is an update notification request, the Geo-API 201 writes the request content to (6) the notification destination (step S6-6). After completing any one of steps S3-6 to S6-6, the process returns to step S1-6 (step S7-6).

Backend processing will be explained. FIG. 13 is a flow diagram illustrating an example of the operation of the information sharing system according to modification 1 of the embodiment.

The Geo-API 201 checks the updated internal data 210b (step S1-7). The Geo-API 201 determines whether the key of the updated data is in (1) the local key.

When Geo-API 201 determines that the key of the updated data is (1) local key (step S2-7: YES), it updates (5) the attribute value with the updated internal data ( Step S3-7). When the Geo-API 201 determines that the key of the updated data is not in (1) the local key (step S2-7: NO), it ends.

The Geo-API 201 determines whether a notification destination is registered in (6) notification destination corresponding to the updated (5) attribute value (step S4-7). If the notification destination is registered in the (6) notification destination corresponding to the updated (5) attribute value (step S4-7: YES), the Geo-API 201 updates (5) of the updated internal data 210b. The value of the attribute and (8) the global key are notified to the (6) notification destination (step S5-7). The Geo-API 201 ends if the notification destination is not registered in the (6) notification destination corresponding to the updated (5) attribute value (step S4-7: NO).

A screen image created by the information sharing system 200 of the autonomous decentralized system 1a by collecting information from the systems 100-1, 100-2, . FIG. 14 is a diagram illustrating an example of the operation of the information sharing system 200 according to the first modification of the embodiment. FIG. 14 shows map information displayed using a unified means for all system information on a general-purpose viewer that can handle three-dimensional data such as a virtual globe system. With this configuration, the information sharing system 200 can function as a map information database.

According to the first modification of the embodiment, the autonomous decentralized system 1a further includes an information sharing system 200 that operates by acquiring information from a plurality of systems. The information sharing system 200 is a map information database.

Modification 1 of the embodiment can obtain the following effects (added value).

All information of systems participating in an autonomous decentralized system can be made to appear as if it were information on a single GIS.

All information can be handled uniformly on the same viewer (for example, virtual globe system).

Since information that is geographically and coordinately close can be displayed together, the correlation between pieces of information can be provided to the user as a "notice". Users can be encouraged to use information more deeply based on these "awarenesses."

Furthermore, it is also possible to more proactively calculate correlations between information in a systematic manner and provide correlation information as added value. For example, correlations between information can be calculated systematically by using statistical methods such as correlation analysis.

As mutual coordination between systems progresses by connecting "things" that are close in coordinates, various mutual relationships will be created, and there is a possibility of discovering unexpected relationships (serenity) such as when the wind blows, the cooper shop becomes profitable. There is.

(Modification 2 of Embodiment) An application example of the autonomous decentralized system 1 of the embodiment will be described. FIG. 15 is a configuration diagram showing an autonomous decentralized system 1b according to a second modification of the embodiment.

The autonomous decentralized system 1b of the second modification of the embodiment includes a system 100b-1, a system 100b-2 instead of the autonomous decentralized system 1, and the system 100-1, system 100-2, ..., system 100-n. , . . . differs in that they include systems 100b-n. The systems 100b-1, 100b-2, . . . , 100b-n collect information and generate new added value by collaborating horizontally with each other.

Any system among the systems 100b-1, 100b-2, . . . , 100b-n will be referred to as a system 100b.

The system 100b will be explained. FIG. 16 is a diagram showing a system 100b according to a second modification of the embodiment. The system 100b is realized by a device such as a personal computer, a server, a smartphone, a tablet computer, or an industrial computer. System 100b exchanges information with other systems. The system 100b includes a Geo-API 101, a processing section 104, a calculation section 106, and a storage section 110.

The processing unit 104 performs processing such as adding three-dimensional coordinate information to nodes and branches. Details of the processing by the processing unit 104 will be described later.

The calculation unit 106 performs system calculations such as power flow calculation, state estimation, OPF (Optimal Power Flow), economic load distribution calculation, and stability calculation. Details of the processing by the calculation unit 106 will be described later.
The storage unit 110 is realized by an HDD, flash memory, RAM, ROM, or the like.

All or part of the Geo-API 101, the processing unit 104, and the calculation unit 106 are realized by a processor such as a CPU executing a program stored in the storage unit 110 (hereinafter referred to as a software function unit). ). Note that all or part of these may be realized by hardware such as LSI, ASIC, or FPGA, or may be realized by a combination of a software function unit and hardware.

The operation of the system 100b will be explained. FIG. 17 is a diagram illustrating an example of the operation of the system 100b according to the second modification of the embodiment. An example of the system 100b performs power flow calculation, state estimation, OPF, and other system calculations required for power system operation by an electric power company. Specifically, the system 100b obtains a node branch provided by system A, a node branch provided by system B, and a node branch provided by system C, and performs massively parallel processing based on the obtained node branches. By performing high-speed processing, it performs power flow calculations, state estimation, OPF, economic load distribution calculations, stability calculations, etc.

In system calculations, equipment information is handled in the form of an abstracted topology called "node branches." The topology of system calculations is a collection of information that nodes are connected by branches with "certain impedance." FIG. 18 is a diagram illustrating an example of equipment information in the autonomous decentralized system 1b of the second modification of the embodiment. In the example shown in FIG. 18, node NO01, node NO02, and node NO03 are shown. Furthermore, it is shown that node NO01 and node NO02 are connected by a branch BR12 having impedance, and node NO02 and node NO03 are connected by a branch BR23 having impedance.

<Method for representing nodes and branches> Examples of representing nodes and branches will be described with reference to FIGS. 19 to 24.
<Node: Generatrix> FIG. 19 is a diagram showing an example of expression of the generatrix in Modification 2 of the embodiment. Specifically, a node in power system calculations is a rod-shaped conductor facility (like a giant iron pipe) with a certain diameter called a "busbar" at a power company's substation. The left side is the generatrix BB of the real world 3D model, which has two end points EP. The right side is a thicker generatrix BB (thicker generatrix BBR), and the two end points EP are the same as the two end points EP of the 3D model in the real world. Here, the bar-shaped generating line BB is defined as a line (3D thick LINE) with a constant thickness. I purposely define it as a slightly thicker LINE to give it more likelihood. By making the lines thicker, the coordinate accuracy of the end points can be given a likelihood.

<Branch: Power Transmission Line> FIG. 20 is a diagram showing an example of a power transmission line according to Modification 2 of the embodiment. A branch corresponds to a "transformer" at a power company's substation or a "transmission line" that connects substations. Generally, it is connected to a busbar (node) via a switch such as a switch or disconnector. Here, the end point EP of the branch is defined by three-dimensional point coordinates (3D-POINT). It may also be defined as a sphere with a fixed radius instead of a point. At this time, the radius may mean the likelihood of connection.

FIG. 20 shows a real-world 3D model power transmission line PL. In this case, the power transmission line PL of the real world 3D model is applied as is. The two end points EP are the same as the two end points EP of the 3D model in the real world. The impedance of the power transmission line PL is expressed by the attribute value of LINESTRING. LINESTRING may be rough, and the end points EP are important.

FIG. 21 is a diagram illustrating an example of a bus bar and a power transmission line in Modification 2 of the embodiment. In FIG. 21, the power transmission line PL is connected to the thick bus line BBR. An end point EP of the power transmission line PL sinks into an iron pipe represented by a thick bus line BBR. In other words, it means that the thick bus line BBR and the power transmission line PL are electrically connected. The connection (topology) between each branch and a node can be expressed by which node (3D thick LINE) the 3D-POINT of each branch end point EP is spatially connected to. In FIG. 21, the presence of switches is omitted for simplicity.

Even in actual substations, busbars and transmission lines intersect and connect three-dimensionally, and this purpose requires three-dimensional representation, which is a feature that cannot be achieved with two-dimensional data representation. .

<Branch: Transformer> FIG. 22 is a diagram showing an example of a transformer according to modification 2 of the present embodiment. On the left is a real-world 3D model of the transformer TR, which has two end points EP. The right side is an abstraction of the transformer TR on the left, which is a line connecting the two end points EP of the real world 3D model.

The transformer TR, which is another typical example of a branch, will be explained. When performing system calculations, the shape of transformer TR has no meaning. Therefore, the transformer TR is simply expressed as a simple line, and the end points at both ends are expressed in (3D-PINT) coordinates, which match the coordinates of the actual end point (connection point with adjacent equipment) of the transformer TR. Define it as follows. 3D-PINT may be a sphere with a fixed radius to create likelihood.

Information on the impedance and tap of the transformer TR is expressed as an attribute value of the line. Similarly to the power transmission line PL, the transformer TR is also connected to the bus bar BB via a switch such as a circuit breaker or a disconnector. Therefore, "adjacent equipment" usually refers to switches such as circuit breakers and disconnectors.

<Branch: Switch> Handling of nodes and branches before contraction. FIG. 23 is a diagram showing an example of a switch according to a modification of this embodiment. The left side shows a 3D model of the real world in which a circuit breaker CB and a switch LS are connected in series, and has two end points EP. The right side is an abstraction of the circuit breaker CB and the switch LS connected in series on the left, and is a line connecting the two end points EP of the 3D model of the real world.

The shape of a switch has no meaning in terms of system calculations. Therefore, it is defined as a simple line connecting end points EP to end point EP. The endpoints at both ends are expressed in (3D-PINT) coordinates and defined to match the coordinates of the endpoint EP of the adjacent equipment. The on/off state of a switch is expressed as an attribute value for that line.

Up to this point, when expressing the topology, we have ignored the presence of switches for simplicity, but as mentioned above, the presence of switches is treated in the same way as transformer TR, so we can express the topology using the same concept. It is possible to express.

<Method for converting three-phase equipment to single-phase equipment> FIG. 24 is a diagram showing an example of power system equipment according to a modification of the embodiment. Since all actual power system equipment is equipment for handling three-phase alternating current, three pieces of equipment are always managed as a set. In system calculations, these three sets (R-phase RP, S-phase SP, T-phase TP) are handled by simulating each in detail (failure calculation), and when all three sets are handled with equipment having the same characteristics. Based on assumptions, it may be converted to a single phase and handled (general power flow calculations). In the latter case, as shown in Fig. 24, single-phase MP can represent the topology of

FIG. 25 is a flow diagram illustrating an example of the operation of the autonomous decentralized system 1b of the second modification of the embodiment. An example of the initial processing flow executed by the system 100b will be described with reference to FIG. 25.

The processing unit 104 converts equipment data of power system equipment necessary for system calculation into data (step S1-8). The processing unit 104 converts the electrical connection relationship between the equipment data into data (step S2-8).

The processing unit 104 takes into consideration the states of the switches and creates nodes and branches necessary for the system calculation (step S3-8). The processing unit 104 assigns a 3D coordinate identifier to the node/branch (step S4-8). The Geo-API 102 exchanges 3D coordinate identifiers given to nodes and branches between systems (step S5-8).

The processing unit 104 creates node branches for the entire system (step S6-8). The calculation unit 106 performs systematic calculation (step S7-8). According to FIG. 25, Geo-API can be added on to an existing system.

FIG. 26 is a flow diagram illustrating an example of the operation of the autonomous decentralized system 1b according to the second modification of the embodiment. With reference to FIG. 26, an example of a processing flow executed by the system 100b after the effects of the "3D coordinate identifier" are widely recognized will be described.

The processing unit 104 converts equipment data of power system equipment required for system calculation into data (step S1-9). The processing unit 104 automatically calculates the electrical connection relationship between the equipment data from the 3D data (step S2-9).

The processing unit 104 creates nodes and branches necessary for the system calculation, taking into account the states of the switches (step S3-9). The Geo-API 101 exchanges 3D coordinate identifiers given to nodes and branches between systems (step S4-9).

The processing unit 104 creates node branches for the entire system (step S5-9). The calculation unit 106 performs systematic calculation (step S6-9). According to FIG. 26, the merits of the "3D coordinate identifier" can be actively utilized.

In the second modification of the embodiment, a case has been described in which each system 100b participating in the autonomous decentralized system 1b performs grid calculation of the power system, but the present invention is not limited to this example. For example, similarly to the first modification of the embodiment, the information sharing system connected via the network NW may be configured. The information sharing system may acquire node/branch information expressed by "three-dimensional coordinate identifiers" from each system 100b, and perform system calculations of the power system based on the acquired node/branch information. good. With this configuration, the processing load on each system 100b can be reduced.

According to the autonomous decentralized system 1b of the second modification of the embodiment, each of the plurality of systems 100b further includes a calculation unit 106 that performs system calculation of the power system. The information exchange unit exchanges information on nodes and branches that are individually created by each system.

With this configuration, each of the plurality of systems 100b can express a node/branch with a "three-dimensional coordinate identifier" and exchange these with each other using Geo-API, so each system participating in the autonomous decentralized system 1b can 100b makes it possible to easily configure the node branches (topology) of the entire system that participates in the autonomous decentralized system 1b. In other words, it becomes possible to perform system calculations for the entire system participating in the autonomous decentralized system. Since it is possible to perform systematic calculations for the entire system participating in the autonomous decentralized system 1b, it is possible to obtain a solution for a more optimal operating state as a whole, for example, to minimize operating costs.

A give & take relationship can be established by distributing the operating cost reduction benefit obtained by the entire system participating in the autonomous decentralized system 1b as an incentive to the participating system 100b by minimizing the operating cost.

Note that even within the same power company, there are many cases where different systems have different equipment code systems, so this concept is not only applicable between different power companies, but also applies to multiple systems within the same power company. It is also possible to apply between

Furthermore, as mentioned above, there has traditionally been little motivation to utilize 3D data even in the world of system calculations. By increasing the number, the following effects can be obtained. Therefore, as the cost of creating three-dimensional data decreases, the motivation for introducing three-dimensional data into system calculations is increasing.

The merits of application to DLR (dynamic line rating) will be explained. Transmission line capacity changes depending on wind conditions, temperature, etc. (wind conditions dominate). By dynamically calculating power transmission capacity based on real-time distribution conditions such as wind conditions and temperature, in addition to the installation direction of power transmission lines and three-dimensional topographical information, it calculates power transmission capacity more accurately than before. be able to.

The merits of applying FL (fault locator) to failure point calculation will be explained. Distance information from the FL device to the failure point can be calculated based on specific three-dimensional installation information of the power transmission line, so it can be calculated as more accurate position information.

In various systems that perform system calculations, equipment data is often migrated or integrated when the system is updated or consolidated. At this time, multiple equipment codes may exist for the same actual equipment. In such a case, it is not easy to distinguish whether the equipment is the same or different, but the three-dimensional coordinate identifier can clearly identify whether the equipment is the same or not.

When performing system calculations, it is very important to accurately provide information on the impedance of transmission lines. By defining power transmission line equipment using three-dimensional coordinate identifiers, the consistency of its length data and impedance can be checked, and erroneous data can be excluded. Alternatively, an appropriate impedance can also be calculated from length data.

In various systems that perform power grid calculations, substation equipment and power transmission line equipment are treated abstractly through screens in the form of ``single line diagrams'' and ``system diagrams.'' Therefore, we are taking the following steps.
(1) The layout of the actual equipment is abstracted and expressed on the screen (assigning 2D coordinates on the screen).
(2) Check the correspondence between the equipment laid out on the screen and the actual equipment (generally, one-by-one tests are conducted face-to-face with the site to ensure correspondence).
The work in (1) and (2) above can be automatically generated by adding three-dimensional coordinate information to nodes and branches, and as a result, the man-hours for work in (1) and (2) can be reduced, as well as , (2) errors can be reduced.

Furthermore, it is also possible to omit the step (1) by directly displaying the 3D data of the actual equipment on the screen as a "single line diagram" or "system diagram".

Various systems that perform system calculations also handle underground substations, underground cables, and other three-dimensional underground facilities. In underground facilities, the value of 3D data is extremely high for facility management and facility planning.

In addition, in the second modification of the embodiment, it is possible to narrow down the 3D coordinates given to the equipment required for system calculation to the minimum necessary, and to provide some likelihood in the definition of the 3D coordinates. , easy to implement.

Furthermore, nodes and branches in system calculations have traditionally been handled by each vendor by assigning its own code to each node or branch. If you want to carry out larger-scale system calculations by bringing together the information necessary for system calculations between different systems, define a "unified format" for the data format that expresses equipment data and electrical connections, and then had to start by converting from a local format to a unified format. This unification is not easy and has traditionally been a major factor hindering cooperation between different systems.

In the second modification of the embodiment, this is achieved by a simple method of assigning a "3D coordinate identifier" to a node/branch. The "3D coordinate identifier" exchanged with Geo-API can share the same meaning for each system participating in the autonomous decentralized system, and it is possible to merge each other's nodes and branches between adjacent systems to perform wide-area system calculations. You can perform system calculations for multiple systems as a whole by exchanging nodes and branches in a larger number of systems.

According to at least one embodiment described above, each of the plurality of systems, when exchanging information expressed by a pair of a first information identifier and a first attribute value with another system, 1 information identifier can be the three-dimensional coordinates of the position of the "thing", so when converting the "thing" into three-dimensional data, it is not necessarily necessary to accurately convert the shape of the "thing" into data, and different "things" Shapes can be simplified and handled within the range where objects do not have the same 3D coordinate identifier (do not overlap). In other words, the cost of creating 3D data can be minimized.

Although the embodiments of the present invention and their modifications have been described above, these embodiments and their modifications are presented as examples, and are not intended to limit the scope of the invention. These embodiments and their modifications can be implemented in various other forms, and various omissions, substitutions, changes, and combinations can be made without departing from the gist of the invention. These embodiments and their modifications are included within the scope and gist of the invention, as well as within the scope of the invention described in the claims and its equivalents.

1, 1a, 1b...autonomous distributed system, 100-1, 100-2,..., 100-n, 100, 100b-1, 100b-2,..., 100b-n, 100b...system, 101- 1, 101-2,..., 101-n, 101...Geo-API, 104...processing unit, 106...calculating unit, 110...storage unit, 110a...public data, 110b...internal data, 200...information sharing System, 201...Geo-API, 202...Data virtualization unit, 210...Storage unit, 210a...Publication data, 210b...Internal data, 300...Map information, 400...Virtual globe system, 500...Traffic information, 600...Open Data, 700...terminal device

Claims (5)

An autonomous decentralized system including multiple systems,
each of the plurality of systems operates independently and autonomously;
Each of the plurality of systems includes:
an information exchange unit that exchanges information with other systems;
The information is expressed by a pair of a first information identifier and a first attribute value,
The autonomous decentralized system, wherein the first information identifier is the three-dimensional coordinates of the position of the "thing". Each of the plurality of systems includes:
The information to be exchanged has a public format and a local format as expression formats,
In the public format, the information is expressed by a pair of the first information identifier and the first attribute value,
In the local format, the information is expressed by a set of a second information identifier and a second attribute value that are uniquely defined in each system,
2. The autonomous decentralized system according to claim 1, wherein the information exchange unit exchanges a correspondence relationship between a public format and a local format in response to an external request. further comprising an information sharing system that operates by acquiring information from a plurality of the systems,
The autonomous decentralized system according to claim 1 or 2, wherein the information sharing system is a map information database. Each of the plurality of systems includes:
It further includes a calculation unit that performs system calculations of the power system,
3. The autonomous decentralized system according to claim 1, wherein the information exchange unit exchanges information on nodes and branches that are individually created by each system. There is an information exchange method performed in an autonomous decentralized system that includes multiple systems.
each of the plurality of systems operates independently and autonomously;
Each of the plurality of systems includes:
exchanging information with other said systems;
The information is expressed by a pair of a first information identifier and a first attribute value,
The information exchange method, wherein the first information identifier is a three-dimensional coordinate of the position of the "thing".

Images