JP7778485B2 - SoS (System of Systems) and method - Google Patents

Description

Embodiments of the present invention relate to SoS and methods.

In recent years, technologies have been developed that analyze data collected in real space (physical space) in cyberspace and utilize the results of that analysis in various industrial fields.

Furthermore, with this technology, it is thought that higher quality services can be provided by deploying at least one server device known as a horizontal SoS (System of Systems) that oversees multiple systems (server devices) belonging to different industrial fields, and by comprehensively utilizing information generated based on data collected in these multiple systems.

However, as mentioned above, there are cases where information cannot be exchanged smoothly between multiple systems (server devices) belonging to various industrial sectors, which could result in the inability to provide high-quality services. Furthermore, for example, even under the current Personal Information Protection Act, the use of personal information for public interest purposes is considered permissible in certain cases, but to date, such use has not been actively carried out, and there has been insufficient promotion of the use of personal information to benefit the entire nation, such as by resolving social issues.

Patent No. 6612450

The problem that one embodiment of the present invention aims to solve is to provide an SoS and method that enables smooth exchange of information between multiple server devices belonging to various industrial fields.

According to an embodiment, a method is provided that is executed by a horizontal SoS (System of Systems) that manages a first server device belonging to a first industrial domain and a second server device belonging to a second industrial domain different from the first industrial domain. The method includes: when the horizontal SoS confirms that a first condition is satisfied, the horizontal SoS determines a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device; and when the first server device is determined as the first system and the second server device is determined as the second system, the horizontal SoS transmits information to the first server device and the second server device to permit transmission of first information from the first server device to the second server device. The first information includes personal information about natural persons collected by the first server device from one or more first edges. The transmission of the first information is permitted when a second condition is satisfied, even if the consent of the natural persons is not obtained. The horizontal SoS transmits information for specifying the terms of use of the first information to at least one of the first server device and the second server device, where the terms of use of the first information are determined by the horizontal SoS and may differ from the terms of use previously agreed upon by the natural person.

FIG. 1 is a diagram showing an example of a network configuration of an integrated system according to an embodiment. FIG. 1 is a diagram showing an example of a system configuration of a horizontal SoS. FIG. 1 is a diagram for explaining the relationship between an edge, a CPS server, and a water-based SoS. FIG. 10 is a diagram for explaining an example of the operation of the integrated system. FIG. 1 is a diagram showing an example of a system configuration for exchanging information. 10 is a flowchart showing an example of a processing procedure of the integrated system when an increased risk of a socially difficult situation is detected. FIG. 10 is a diagram showing an example of a real-time hazard map. FIG. 1 is a diagram for explaining a mobile phone management system connected to a resilience SoS. 10 is a flowchart showing an example of a processing procedure of the integrated system when a flood actually occurs. 10 is a flowchart showing an example of a processing procedure for information transmission permission processing. 10 is a flowchart showing another example of the processing procedure of the information transmission permission process. A diagram for specifically explaining the operation of the integrated system when personal information of users held by the mobile phone management system is used to provide resilience solutions. FIG. 10 is a diagram for explaining a case where personal information of a user is transmitted to a medical system. A diagram for specifically explaining the operation of the integrated system when personal information of users held by a mobility SoS is used to provide resilience solutions. 10 is a diagram for explaining a case where image data is transmitted from a mobility SoS to a river, levee, and dam management CPS server. FIG. FIG. 10 is a diagram for explaining a case where EV information is transmitted from a mobility SoS to a VPP power transmission and distribution CPS server. A diagram to explain the overview of digital twins. A diagram showing that the resilience SoS has storage, viewing, and automatic deletion functions. FIG. 10 is a diagram showing an example of the data structure of basic information included in permission content information. FIG. 10 is a diagram showing an example of the data structure of detailed information included in permission content information.

Hereinafter, embodiments will be described with reference to the drawings.
1 shows an example of a network configuration of an integrated system according to this embodiment. As shown in FIG. 1, the integrated system includes a plurality of edge devices (edge terminals) 11 and 12, and a plurality of server devices 21 and 22.

Each of the multiple edges 11 and 12 is communicatively connected to the server devices 21 and 22 corresponding to the edges 11 and 12. Each of the multiple edges 11 and 12 is configured to collect data measured periodically by various sensors installed (mounted) on the edges 11 and 12, for example, and to transmit the collected data to the server devices 21 and 22 corresponding to the edges 11 and 12.

Each of the multiple server devices 21 and 22 is configured to provide various services using data transmitted from the edges 11 and 12 corresponding to the server devices 21 and 22. Furthermore, each of the multiple server devices 21 and 22 is configured to control the operation of the edges 11 and 12 corresponding to the server devices 21 and 22 so that desired data can be received from the edges 11 and 12.

In the example shown in Figure 1, each of the multiple edges 11 corresponds to each of the multiple server devices 21, and each of the multiple edges 12 corresponds to each of the multiple server devices 22.

Each of the multiple edges 11 and 12 is an electronic device that incorporates a control unit that controls the operation of the edge in accordance with the content of communication with, for example, the multiple server devices 21 and 22. Potential examples of each of the multiple edges 11 and 12 include various electronic devices such as electric vehicles (EVs), smartphones, machine tools, battery control units, control units for renewable energy power generation equipment, and infrastructure monitoring devices. For ease of explanation, Figure 1 shows one edge per server device; however, it is common for multiple edges (i.e., a group of edges) to be connected to one server device.

Furthermore, each of the multiple server devices 21 and 22 in this embodiment is referred to as a CPS (Cyber Physical System) server. CPS refers to a system that creates added value by collecting data in real space (physical), analyzing the results using digital technology in cyberspace (i.e., information generated from the collected data), and feeding the results back to the real space. Note that a CPS server may have a function known as a digital twin, which accumulates data received from an edge or the like corresponding to the CPS server and digitally reproduces real space (i.e., cyberspace). In the following description, for convenience, server devices such as the multiple server devices 21 and 22 will be referred to as a CPS server.

Note that while it is assumed here that each of the multiple edges 11 and 12 can communicate directly with each of the multiple server devices 21 and 22, each of the multiple edges 11 and 12 and each of the multiple server devices 21 and 22 may also be able to communicate via other devices.

In this embodiment, for example, the above-mentioned multiple CPS servers 21 and multiple CPS servers 22 belong to different industrial domains. In the example shown in Figure 1, multiple CPS servers 21 belong to a first industrial domain, and multiple CPS servers 22 belong to a second industrial domain.

In this embodiment, an "industrial domain" may refer to any domain that can be classified as a single industry. For example, medical care, education, industry, welfare, and legal affairs may each be considered an industrial domain. Furthermore, the connected industry's key domains, "Smart Life (healthcare through precision medicine, purchasing management using smart receipts, etc.)," "Autonomous Driving and Mobility Services (EV sharing, etc.)," "Manufacturing and Robotics (Factory Automation, Smart Manufacturing)," "Bio/Materials," and "Plant and Infrastructure Security" may each be considered industrial domains. Furthermore, the above-mentioned "Plant and Infrastructure Security" may be divided into, for example, the energy sector and the infrastructure sector. In other words, the above-mentioned examples of industrial domains may be further subdivided into multiple industrial domains. Furthermore, some of the above-mentioned examples of industrial domains may be merged into a single industrial domain. Furthermore, the classification of each industrial domain is not limited to the above examples; industrial domains may have different definitions depending on the corporation, government, or public organization.

Specifically, for example, a first industry domain to which multiple CPS servers 21 belong may be "autonomous driving/mobility services," and a second industry domain to which multiple CPS servers 22 belong may be "plant/infrastructure security (energy field)."

As described above, if the first industrial domain is "autonomous driving/mobility services," the multiple CPS servers 21 belonging to the first industrial domain are, for example, multiple CPS servers installed in each area where mobility services are provided. In this case, the multiple edges 11 corresponding to the multiple CPS servers 21 include EVs (electric vehicles), etc.

On the other hand, if the second industry domain is "Plant and Infrastructure Security (Energy Field)," the multiple CPS servers 22 belonging to the second industry domain include, for example, a VPP (Virtual Power Plant) power generation CPS server installed at each power generation facility and a VPP power transmission and distribution CPS server installed at each area subject to power transmission and distribution. In this case, the multiple edges 12 corresponding to the multiple CPS servers 22 include control units for various power generation facilities and power meters installed in homes or buildings.

Here, the integrated system in this embodiment includes a System of Systems (SoS) that orchestrates multiple server devices belonging to each of the above-mentioned industrial domains.

In this embodiment, for example, each of the multiple CPS servers 21 connected to each of the multiple edges 11 is configured to be able to operate independently as a single system, and each of the multiple CPS servers 22 connected to each of the multiple edges 12 is configured to be able to operate independently as a single system, but SoS provides functions (services) that cannot be realized by the single systems, for example, by managing these geographically dispersed systems.

In addition, in this embodiment, "controlling multiple systems" includes one or more of the concepts of executing processing to bring the multiple systems as a whole closer to an optimal state, exchanging information between the multiple systems, or controlling each of the multiple systems. In other words, the processing executed to control the multiple systems may be, for example, control for partial optimization in each system, from the perspective of optimizing the multiple systems as a whole controlled by the SoS. Furthermore, the processing executed to control the multiple systems may be, for example, processing to realize a function that is completely different from the function provided by each of the multiple systems being controlled.

In this embodiment, SoS is classified into vertical SoS and horizontal SoS depending on the number of industrial domains to which the multiple systems it oversees belong.

A vertical SoS oversees multiple CPS servers (systems) belonging to a single industrial domain. In the example shown in Figure 1, a vertical SoS 31 oversees multiple CPS servers 21 belonging to a first industrial domain, and a vertical SoS 32 oversees multiple CPS servers 22 belonging to a second industrial domain are shown. Although not shown in Figure 1, the integrated system may further include a vertical SoS configured to oversee multiple vertical SoSs belonging to the same industrial domain, for example.

A horizontal SoS oversees multiple CPS servers (systems) belonging to two or more different industrial domains. In this case, the horizontal SoS may be configured to directly oversee multiple CPS servers belonging to two or more industrial domains, or may be configured to oversee multiple vertical SoSs that oversee multiple CPS servers belonging to each of the two or more industrial domains. Furthermore, the horizontal SoS may be configured to oversee the vertical SoSs, thereby indirectly overseeing the CPS servers overseen by the vertical SoSs. In the example shown in Figure 1, the integrated system includes a horizontal SoS 40 that oversees a vertical SoS 31 that oversees multiple CPS servers 21 belonging to a first industrial domain and a vertical SoS 32 that oversees multiple CPS servers 22 belonging to a second industrial domain. Although not shown in Figure 1, the integrated system may further include a horizontal SoS configured to oversee multiple horizontal SoSs.

In this embodiment, the multiple CPS servers 21, 22, vertical SoSs 31, 32, and horizontal SoS 40 are each realized by one or more server devices (computer resources), and may be realized, for example, by IaaS (Infrastructure as a Service), PaaS (Platform as a Service), etc.

FIG. 2 shows an example of the hardware configuration of the horizontal SoS 40 shown in FIG. 1 . As shown in FIG. 2 , the horizontal SoS 40 includes a CPU 40a, a nonvolatile memory 40b, a main memory 40c, and a communication device 40d. While FIG. 2 illustrates an example of a hardware configuration included in a single computer, the horizontal SoS 40 may be realized by multiple computers. The CPU 40a is a hardware processor that controls the operation of each component within the horizontal SoS 40. The CPU 40a may be a single processor or may be configured with multiple processors. The CPU 40a executes programs loaded from the nonvolatile memory 40b, which is a storage device, to the main memory 40c. These programs include an operating system (OS) and various application programs. The application programs executed by the CPU 40a include application programs for implementing the various functions (and processes) provided by the horizontal SoS 40, as described below.

Non-volatile memory 40b is a storage medium used as an auxiliary storage device. Main memory 40c is a storage medium used as a main storage device. Although only non-volatile memory 40b and main memory 40c are shown in Figure 2, horizontal SoS 40 may also include other storage devices, such as an HDD (Hard Disk Drive) and an SSD (Solid State Drive).

The communication device 40d is a device configured to perform wired or wireless communication with external devices (e.g., vertical SoSs 31 and 32) of the horizontal SoS 40.

In Figure 2, the system configuration of horizontal SoS 40 is explained, but the multiple CPS servers 21 and 22 and vertical SoSs 31 and 32 shown in Figure 1 also have a system configuration similar to that of horizontal SoS 40.

Next, referring to Figure 3, an example of the relationship between the functions of the multiple edges 11 and 12, multiple CPS servers 21 and 22, and vertical SoSs 31 and 32 shown in Figure 1 will be described. As shown in Figure 1 above, the integrated system comprises multiple edges 11 and 12, multiple CPS servers 21 and 22, and multiple vertical SoSs 31 and 32, but for convenience, the relationship between one edge 11, one CPS server 21 corresponding to that edge 11, and the vertical SoS 31 that oversees the multiple CPS servers 21 will be described here.

Edge 11 has a control function that controls the operation of the edge 11, a function based on the IoT (Internet of Things) perspective.

The control functions possessed by the edge 11 include a communication function for communicating with the CPS server 21, an analysis function for performing various analyses on the edge 11 side, a state change function for changing the state of the edge 11, a sensing function for measuring data using sensors installed on the edge 11, and an actuation function for operating the edge 11.

The CPS server 21 (platform) has data functions, analysis functions, and operation functions based on the IoT (Internet of Service) perspective.

The data functions of the CPS server 21 include a master data function that stores master data related to the specifications, blueprints, maintenance history, etc. of the edge 11, and a data lake function that stores (accumulates) data received (collected) from the edge 11 via the IoT bus. The data held by the CPS server 21 through the data function is data on the edge group including the edge 11 and data related to the edge group. The master data function may also store data related to the usage environment of the edge 11 (or the edge group including the edge 11).

The analysis functions of the CPS server 21 include a statistical processing function that performs statistical processing to analyze data stored by the data function, a machine learning function that performs analysis using AI (artificial intelligence) generated by machine learning and deep learning, etc., and an optimization function that optimizes the operation of the system (edge 11 and CPS server 21).

The operation functions of the CPS server 21 include, for example, a monitoring and diagnostic function that monitors and diagnoses the operation of the edge 11, and a management function that manages the edge 11. Operation information for the edge 11 is generated using data stored by the data function, data derived by the analysis function (i.e., analysis results obtained by analysis), or manually entered data. The operation information includes, for example, information for operating the communication function, edge analysis function, state change function, sensing function, and actuation function included in the control functions of the edge 11 described above, and is transmitted to the edge 11.

The functions of the edge 11 and CPS server 21 described above enable the following operations to be realized. The edge 11 transmits data collected by the edge 11 to the CPS server 21 and receives operation information from the CPS server 21. The operation of the edge 11 is controlled based on the operation information received from the CPS server 21. In this case, the edge 11 transmits data collected by the edge 11 (i.e., measured by a sensor) to the CPS server 21 in response to changes in the state of the edge 11 based on the operation information, for example, and receives further operation information from the CPS server 21. By repeating this control loop (CPS loop) through the exchange of data and operation information, control of the edge(s) 11 is achieved based on data accumulated on the platform (data stored by the data function of the CPS server 21) and the results of analyzing that data.

Note that while the CPS server 21 has been described here as having data functions, analysis functions, and operation functions, it is sufficient for the CPS server 21 to have at least a data function. In other words, the CPS server 21 may be configured to have only a data function, or only a data function and analysis function, or only a data function and operation function.

Vertical SoS 31 (Enterprise Services) has SoS functions provided by the SoS.

The SoS function includes an SoS API, service function, and control function, and controls multiple systems (multiple CPS servers 21) based on data stored in the CPS servers 21 and the analysis results of that data. The data stored in the CPS servers 21 and the analysis results of that data are collected via the SoS API. The SoS function can also transmit the analysis results of the data stored in the CPS servers 21 (information generated from that data) to other domains (for example, horizontal SoS 40, vertical SoS 32 or CPS servers 22 that belong to an industrial domain different from vertical SoS 31).

Furthermore, in the integrated system, server devices other than the CPS server 21 and vertical SoS 31 may have service functions used by the system management side (system administrators, etc.) and business management functions for managing the business.

Service functions include functions for implementing business operations and maintenance, as well as man-machine interaction functions, such as an intelligent heuristic engine function, an interface function providing various interfaces such as an API (Application Programming Interface) and a UI (User Interface), and logic and workflow functions. Service functions incorporate the Internet of People (IoP) perspective through these functions. For example, data stored in the CPS server 21 and the analysis results of that data are acquired via an API, and the acquired data and analysis results are then verified programmatically or by an administrator. This enables the status of the CPS loop to be inspected and changed based on the program's automatic judgment results and the administrator's knowledge. Furthermore, the administrator inspects and audits the status of the CPS loop based on their expert human knowledge (IoP) to detect AI errors (CPS loop abnormalities) caused by abnormalities or attacks. In other words, the administrator can visually confirm whether the system is operating properly. If an administrator detects (perceives) an abnormality in the CPS loop, they may troubleshoot the CPS loop via the service function (or other function).

Business management functions are functions for realizing specific business requirements within the entire system, and include functions such as CRM (Customer Relationship Management), ERP (Enterprise Resources Planning), PLM (Product Lifecycle Management), and EAM (Enterprise Asset Management). Business management functions are used to manage the status of the business based on data accumulated in the CPS server 21, the results of analysis of that data, detection results (check results) by administrators using service functions, and administrator operations based on those detection results.

Here, the service functions and business management functions have been described as being possessed by a server device different from the CPS server 21 or the vertical SoS 31, but the service functions and business management functions may, for example, be possessed by the CPS server 21 or the vertical SoS 31. Furthermore, the SoS functions may be possessed by the horizontal SoS 40 rather than the vertical SoS 31.

Furthermore, at least one of the above-mentioned edge 11, CPS server 21, and vertical SoS 31 has a common service function. The common service function includes a security function, a logging function, and a billing function. The security function is a function that ensures the security of each of the edge 11, CPS server 21, and vertical SoS 31, and the security of communications between the edge 11, CPS server 21, and vertical SoS 31. The logging function is a function that records, as a log, the operation of each of the edge 11, CPS server 21, and vertical SoS 31, and the history of communications between the edge 11, CPS server 21, and vertical SoS 31. The billing function is a function for issuing invoices, processing payments, and checking itemized statements in accordance with the use of services provided by the vertical SoS 31 and CPS server 21.

Note that the arrows shown in Figure 3 represent communication or data transfer between the functions connected by the arrows. Also, in Figure 3, the mark 21a attached to the operation function of the CPS server 21 and the mark 31a attached to the SoS function of the vertical SoS 31 indicate that manual operation by an administrator is possible. The same applies to the marks identical to mark 31a attached to the service function and business management function shown in Figure 3.

The functions of the edge 11, CPS server 21, and vertical SoS 31 described in Figure 3 are examples, and may be changed as appropriate depending on the services provided in the integrated system.

In Figure 3, we have explained the edge 11, CPS server 21, and vertical SoS 31, but the same applies to other edges, CPS servers, and vertical SoSs.

Next, an example of the operation of the integrated system in this embodiment will be described with reference to Figure 4. In Figure 4, it is assumed that the integrated system provides a resilience solution.

In this case, the integrated system is assumed to include a resilience SoS40 corresponding to horizontal SoS40 shown in Figure 1, a first mobility SoS31A and a second mobility SoS31B corresponding to vertical SoS31, and a VPP SoS32 corresponding to vertical SoS32.

Note that Figure 4 assumes a case in which two vertical SoSs (i.e., first mobility SoS 31A and second mobility SoS 31B) are provided as vertical SoSs 31 belonging to the first industry domain described above. First mobility SoS 31A is a vertical SoS that oversees multiple CPS servers (hereinafter referred to as first mobility CPS servers) 21A that provide "autonomous driving/mobility services" by, for example, company A. On the other hand, second mobility SoS 31B is a vertical SoS that oversees multiple CPS servers (hereinafter referred to as second mobility CPS servers) 21B that provide "autonomous driving/mobility services" by, for example, company B.

VPP SoS 32 is also a vertical SoS that oversees multiple CPS servers (hereinafter referred to as VPP CPS servers) 22A and 22B.

In other words, the resilience SoS 40 shown in Figure 4 is a horizontal SoS that oversees the first mobility SoS 31A, second mobility SoS 31B, and VPP SoS 32 described above.

Here, the resilience SoS (horizontal SoS) 40 can also manage systems other than the vertical SoS. For this reason, Figure 4 shows an example in which the resilience SoS 40 manages an infrastructure management system 33 in addition to the first mobility SoS 31A, second mobility SoS 31B, and VPP SoS 32 described above. Note that the infrastructure management system 33 is realized by one or more server devices (their computer resources) and is configured to manage multiple CPS servers (hereinafter referred to as infrastructure CPS servers) 23A-23C that belong to an industrial domain (e.g., a third industrial domain) different from the first mobility SoS 31A, second mobility SoS 31B, and VPP SoS 32 described above. The infrastructure management system 33 shown in Figure 4 is not an SoS as described above, but rather a system that collects information from multiple infrastructure CPS servers 23A-23C, visualizes the current status of the various infrastructures managed by each of the multiple infrastructure CPS servers 23A-23C, and controls their operation and maintenance.

Note that, for example, each of the multiple first mobility CPS servers 21A controlled by the first mobility SoS 31A is assumed to be installed in a different region (area), but they may be installed in the same region to distribute the processing load, or they may be installed for each function realized by the first mobility SoS (multiple first mobility CPS servers 21A). While multiple first mobility CPS servers 21A (i.e., multiple CPS servers controlled by the first mobility SoS 31A) have been described here, the same applies to the other multiple CPS servers controlled by the second mobility SoS 31B, VPP SoS 32, and infrastructure management system 33.

As described above, the integrated system shown in Figure 4 provides resilience solutions. Resilience solutions refer to services that provide solutions to prevent, for example, socially difficult situations from occurring, minimize damage or adverse impacts on society if they do occur, and facilitate post-event recovery. In this embodiment, "socially difficult situations" may be based on, for example, various weather events (typhoons, tornadoes, gusts of wind, heavy rain, linear rain bands, lightning, hail, heavy snow, etc.), various natural disasters such as earthquakes or tsunamis. Furthermore, "socially difficult situations" may be based on accidents, terrorism, crime, infectious diseases, power shortages, water shortages, etc.

In this embodiment, the resilience SoS 40 controls the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, and infrastructure management system 33, which belong to three industrial domains (mobility, energy, and infrastructure), to perform control to enhance resilience to the above-mentioned socially difficult situations. Although not shown in FIG. 4, the resilience SoS 40 may also be configured to control vertical SoSs and other systems in various industrial domains other than the three industrial domains described above, such as "smart life" and "manufacturing/robotics (factory automation, smart manufacturing)," to perform control to enhance the resilience of society as a whole.

As mentioned above, in this embodiment, the integrated system (horizontal SoS 40) is described as providing a resilience solution, but the application of this horizontal SoS 40 may be anything that can create new social value by integrating vertical SoS and other systems belonging to different industrial fields.

Although omitted in Figure 4, each of the multiple CPS servers 21A, 21B, 22A, 22B, and 23A-23C shown in Figure 4 is communicatively connected to an edge corresponding to that CPS server, such as the multiple edges 11 and 12 described in Figure 1.

This embodiment is intended to provide resilience solutions in response to the occurrence of socially challenging situations. First, we will explain an example of the normal operation of the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, and infrastructure management system 33.

First, we will explain the first mobility SoS 31A. The first mobility SoS 31A manages multiple first mobility CPS servers 21A. The first mobility SoS 31A and multiple first mobility CPS servers 21A provide services that provide means and routes for user mobility or services that assist in selecting such means and routes (hereinafter referred to as mobility services). Note that mobility services are services that move users from a starting point to a destination using at least one of various modes of transportation, such as walking, bicycle, automobile, train, bullet train, and airplane. Note that bicycles, which are one mode of transportation, may include, for example, shared electric bicycles. Furthermore, automobiles, which are one mode of transportation, may be privately or corporately owned automobiles or automobiles used for car sharing. Various automobiles can be used, such as electric automobiles, hybrid automobiles, gasoline-powered automobiles, and hydrogen-powered automobiles.

In order to provide the mobility services described above, the first mobility SoS 31A and the multiple first mobility CPS servers 21A may have functions such as selecting routes to avoid congestion or automatically driving multiple vehicles (such as automobiles) in the same area at the same time in a synchronized manner to avoid congestion (hereinafter referred to as a synchronized driving function). The synchronized driving function may, for example, prohibit vehicles from entering school zones during school hours or drive vehicles to reduce noise pollution. Furthermore, the first mobility SoS 31A and the multiple first mobility CPS servers 21A may have functions such as reducing environmental impact by prioritizing the selection of transportation modes with a low environmental impact. Furthermore, the first mobility SoS 31A and the multiple first mobility CPS servers 21A may provide functions for implementing dynamic pricing based on supply and demand or dynamic pricing in response to environmental impact and social impact when providing the mobility services described above.

The following describes a case in which the first mobility SoS 31A and multiple first mobility CPS servers 21A provide mobility services by controlling, for example, electric vehicles with autonomous driving capabilities that are shared by users. Note that the first mobility SoS 31A and multiple first mobility CPS servers 21A may also control other mobility means.

Here, each of the multiple first mobility CPS servers 21A managed by the above-mentioned first mobility SoS 31A is a CPS server that provides mobility services in, for example, different areas (hereinafter referred to as service provision areas), and we assume that a user uses mobility services in the service provision area of one of the multiple first mobility CPS servers 21A (hereinafter simply referred to as first mobility CPS server 21A).

In this case, for example, the smartphone used by the user functions as an edge corresponding to the first mobility CPS server 21A, and the first mobility CPS server 21A performs control to support the autonomous driving functions of each electric vehicle based on data acquired by the smartphone. Specifically, the first mobility CPS server 21A receives the departure point, desired departure time, and destination point, desired arrival time input by the user on the smartphone (edge), for example, and transmits to the smartphone electric vehicles selectable by the user, (information about) the route the electric vehicle is scheduled to travel, the scheduled departure time, and the scheduled arrival time.

In addition, the edges corresponding to the first mobility CPS server 21A include the electric vehicles mentioned above. The first mobility CPS server 21A holds the specifications of each electric vehicle as master data, and receives and analyzes data from each electric vehicle under the control of the first mobility CPS server 21A regarding the surrounding conditions when the electric vehicle is running or stopped, as well as data regarding the operation and various controls of the electric vehicle. Based on the results of this analysis, the first mobility CPS server 21A performs control to assist the operation of the electric vehicle from the starting point to the destination.

Note that the control performed by the first mobility CPS server 21A to support the autonomous driving function may differ depending on the level (range of support) of the autonomous driving function installed in each electric vehicle.

Specifically, depending on the model of electric vehicle, autonomous driving control may be completed solely on the edge (i.e., the electric vehicle itself). In this case, the electric vehicle may receive information about the area surrounding the route it plans to take immediately after its current location, and use this information to control the driving of the electric vehicle.

On the other hand, if autonomous driving control is achieved through collaboration between the electric vehicle (edge) and the first mobility CPS server 21A, the electric vehicle can run, for example, on highways using only the autonomous driving function installed in the electric vehicle, and on urban roads using the autonomous driving function based on control by the first mobility CPS server 21A.

In addition, electric vehicles may be controlled to drive taking into account traffic congestion forecasts around the route, information on residents or facilities, etc.

Data regarding the conditions around the electric vehicle may be acquired using sensors (such as LiDAR or millimeter-wave radar) or cameras mounted on the electric vehicle, or may be acquired using stationary surveillance cameras or sensors, or may be acquired by other electric vehicles in the vicinity of the electric vehicle.

Here we have explained the case where a user uses a mobility service in the service area of one first mobility CPS server 21A, but the same applies when a user uses a mobility service in the service area of another first mobility CPS server 21A, for example.

The first mobility SoS 31A, which controls the multiple first mobility CPS servers 21A operating as described above, receives information on the accurate future travel schedules of electric vehicles (edges) under the control of the multiple first mobility CPS servers 21A, data on the surrounding conditions of the electric vehicles, etc. As a result, the first mobility SoS 31A can provide each first mobility CPS server 21A with optimal transportation selection and route information based on the travel schedules of a wider range and larger number of electric vehicles than when each first mobility CPS server 21A operates alone. This makes it possible, through control by the first mobility SoS 31A and at least one of the multiple first mobility CPS servers 21A, to completely match the travel speeds of all electric vehicles under the control of the first mobility CPS server 21A that exist within a specific area, thereby providing a synchronized driving function that prevents traffic congestion. Furthermore, in situations where pedestrian entry into a specific area can be controlled, automatic and synchronized driving of all-electric vehicles can be achieved in an environment without traffic lights by controlling the first mobility SoS 31A and at least one of the multiple first mobility CPS servers 21A.

Note that while the operation of the first mobility SoS 31A (and the multiple first mobility CPS servers 21A) has been described above, the same applies to the operation of the second mobility SoS 31B (and the multiple second mobility CPS servers 21B). That is, the second mobility SoS 31B and the multiple second mobility CPS servers 21B operate to provide the same mobility services (mobility-related services) as the first mobility SoS 31A and the multiple first mobility CPS servers 21A. However, the relationship between the first mobility SoS 31A and the second mobility SoS 31B is such that the company (corporation) managing the first mobility SoS 31A and the multiple first mobility CPS servers 21A and the company (corporation) managing the second mobility SoS 31B and the multiple second mobility CPS servers 21B are in competition with each other, and it is assumed that at least a portion of their service areas overlap.

Next, we will explain the VPP SoS 32. As shown in FIG. 4, the VPP SoS 32 manages multiple VPP CPS servers 22A and 22B. For example, the VPP CPS server 22A is a VPP power generation CPS server (hereinafter referred to as the VPP power generation CPS server 22A), and the VPP CPS server 22B is a VPP power transmission and distribution CPS server (hereinafter referred to as the VPP power transmission and distribution CPS server 22B).

The VPP power generation CPS server 22A is a CPS server for performing maintenance and management of power generation facilities such as wind power generation facilities and solar power generation facilities, and is installed for each such power generation facility. The VPP power generation CPS server 22A may also be configured to collectively control all renewable energy power generation devices and facilities in a specific region.

Here, the edge corresponding to the VPP power generation CPS server 22A includes controllers installed in various types of power generation equipment, such as renewable energy wind power generation equipment, solar power generation equipment, geothermal power generation equipment, and hydroelectric power generation equipment. In this case, the VPP power generation CPS server 22A acquires data on the operating status and power generation history of the power generation equipment from the controller (edge) in order to operate and maintain the various types of power generation equipment described above, and controls the power generation equipment based on the acquired data.

Here, we have described renewable energy-related wind power generation facilities, solar power generation facilities, geothermal power generation facilities, and hydroelectric power generation facilities as power generation facilities, but the VPP power generation CPS server 22A may also be configured to control, for example, thermal power generation facilities or nuclear power generation facilities.

The VPP power generation CPS server 22A may receive information regarding the balance of power supply and demand from the VPP power transmission and distribution CPS server 22B by transmitting the power generation amount and its predicted value of each power generation facility to the VPP power transmission and distribution CPS server 22B, and may control the power generation amount of each power generation facility based on the information from the VPP power transmission and distribution CPS server 22B. Note that the transmission of the power generation amount and its predicted value to the VPP power transmission and distribution CPS server 22B and the reception of information regarding the balance of power supply and demand from the VPP power transmission and distribution CPS server 22B may be performed via the VPP SoS 32, or may be performed directly between the VPP power generation CPS server 22A and the VPP power transmission and distribution CPS server 22B.

The VPP power generation CPS server 22A may also control the power electronics circuit to convert the power generation output (DC voltage and DC current) from renewable energy sources into AC current that matches the grid, and may also control the orientation of wind power generation equipment according to wind direction based on the surrounding environment (weather conditions, etc.) in order to maximize power generation. Furthermore, the VPP power generation CPS server 22A may control the orientation of solar power generation panels to promote efficient power generation. The VPP power generation CPS server 22A may also perform abnormality detection for each power generation equipment, and may also formulate plans for operation, shutdown, and maintenance of each power generation equipment.

The VPP electricity transmission and distribution CPS server 22B is a CPS server for providing electricity transmission and distribution services (services for transmitting and supplying electricity), and is assumed to be installed, for example, for each region that is the target of the electricity transmission and distribution. In this case, the areas where the services are provided by each VPP electricity transmission and distribution CPS server 22B installed for each region may partially overlap, and there may be multiple VPP electricity transmission and distribution CPS servers in the same region that provide services from different companies (corporations).

Here, the edges corresponding to the VPP power transmission and distribution CPS server 22B include, for example, watt-hour meters (or smart meters) installed at power consumption locations such as individual homes, apartment complexes, buildings, and commercial facilities. In this case, the VPP power transmission and distribution CPS server 22B receives the power generation amount and its predicted value of each power generation facility from the VPP power generation CPS server 22A, and receives the power usage amount and its predicted value at each power consumption location from the above-mentioned watt-hour meters. The VPP power transmission and distribution CPS server 22B also holds master data on the costs related to the transmission and distribution of power between each power generation facility and each power consumption location. The VPP power transmission and distribution CPS server 22B executes control for power transmission and distribution based on the power generation amount and its predicted value of each power generation facility, the power usage amount and its predicted value at each power consumption level, and the costs related to power transmission and distribution.

The VPP electricity transmission and distribution CPS server 22B also has functions related to the sale and purchase of electricity based on power consumption values (for individual homes, apartment buildings, buildings, commercial facilities, etc.). Specifically, the VPP electricity transmission and distribution CPS server 22B may transmit the selling price, buying price, and predicted value of electricity at each date and time to each electricity meter (edge) for the purpose of selling or purchasing electricity, and may receive information on the amount of stored electricity (dischargeable amount) and current or future electricity purchase requests from the electricity meter. Furthermore, the VPP electricity transmission and distribution CPS server 22B may store (i.e., accumulate) electricity in a secondary battery (such as an SCiB (registered trademark) or LiB) when it is assumed that the total amount of electricity generated by each power generation facility received from the VPP power generation CPS server 22A is greater than the total amount of electricity used in each electricity consumption area. In this case, electricity may be converted into hydrogen or the like (P2G: Power to Gas) or carbon dioxide may be converted into fuel using electricity (P2C: Power to Chemical).

The VPP electricity transmission and distribution CPS server 22B may also have a demand response function. Demand response is defined as changing the electricity consumption pattern of consumers to curb their electricity usage in response to electricity rate settings or incentive payments, for example, when market prices rise or grid reliability declines. If the total amount of electricity generated by each power generation facility received from the VPP power generation CPS server 22A is assumed to be smaller than the total amount of electricity used in each power consumption area, the VPP electricity transmission and distribution CPS server 22B may determine whether or not to transmit or distribute electricity from outside the power consumption area, or whether or not to discharge stored electricity within or near the power consumption area. This allows power consumption to be reduced through demand response.

VPP SoS32 oversees multiple VPP power generation CPS servers 22A and multiple VPP power transmission and distribution CPS servers 22B, and performs control to meet power demand using renewable energy. VPP SoS32 receives power generation history and power generation forecast values for each power generation facility from multiple VPP power generation CPS servers 22A, and receives power consumption history and power consumption forecast values for each power consumption area from multiple VPP power transmission and distribution CPS servers 22B. The amount of power generated by renewable energy fluctuates over time due to natural factors, and power consumption in each power consumption area also fluctuates over time depending on the trends of consumers. Considering these circumstances, in order to match the supply and demand at each time, the VPP SoS 32 can perform control for efficient storage of power when there is a power surplus, efficient discharge of power when there is a power shortage, and interchange of power between power consumption areas based on the power generation history and predicted power supply amount of each power generation facility, which covers a wider range than each VPP power generation CPS server 22A and each VPP power transmission and distribution server 22B, as well as the consumption history and predicted power demand of each power consumption area.

Next, we will explain the infrastructure management system 33. The infrastructure management system 33 is a system for managing infrastructure provided by, for example, the national government and local public organizations, and in the example shown in FIG. 4, manages multiple infrastructure CPS servers 23A-23C. Here, the infrastructure CPS server 23A is a bridge/road management CPS server (hereinafter referred to as bridge/road management CPS server 23A), the infrastructure CPS server 23B is a river/levee/dam management CPS server (hereinafter referred to as river/levee/dam management CPS server 23B), and the infrastructure CPS server 23C is a water supply/sewerage CPS server (hereinafter referred to as water supply/sewerage CPS server 23C). Note that each of the bridge/road management CPS server 23A, river/levee/dam management CPS server 23B, and water supply/sewerage CPS server 23C is installed for each management unit (i.e., region) such as a country, prefecture, city, ward, town, or village, and may be shared by multiple organizations.

Edges corresponding to the bridge/road management CPS server 23A include, for example, sensors or monitoring units installed on bridges, roads, or cliffs or slopes adjacent to the roads. In this case, the bridge/road management CPS server 23A can analyze data collected by such sensors or monitoring units, such as displacement of the bridge and road positions and changes in internal pressure. Furthermore, if the edge corresponding to the bridge/road management CPS server 23A is a camera installed on various vehicles, including inspection vehicles, or a surveillance camera installed near the bridge or road, it can analyze data such as the usage status of the bridge or road and cracks and flaws on the surface of the bridge or road captured or measured by the camera. The bridge/road management CPS server 23A sequentially estimates the condition of the bridge and road based on the results of these analyses and generates information for operating and maintaining the bridge, road, and its surrounding areas.

The bridge/road management CPS server 23A may also identify the occurrence or risk of abnormalities (such as collapse, collapse, sinkholes, heavy rain, heavy snow, and dense fog) in bridges, roads, and their surrounding areas, and issue warnings by displaying the occurrence or risk of the abnormality on digital signs or by contacting various vehicles (edges), or may generate information for formulating bridge and road construction or repair plans.

In addition to the data collected from the edges described above, the bridge/road management CPS server 23A can also be used as a database that collects data based on feedback from residents. In this case, the bridge/road management CPS server 23A can store data on locations where there are many complaints about noise from vehicles traveling on the road, locations where there are many complaints about exhaust fumes, locations with a high risk of accidents (near miss reports from residents), school zones, etc., and use this data in combination with the data collected from the edges.

Edges corresponding to the river, levee, and dam management CPS server 23B include sensors (including rain gauges) or surveillance cameras installed on (or near) rivers, levees, and dams. In this case, the river, levee, and dam management CPS server 23B uses these sensors or surveillance cameras to acquire data such as meteorological information (such as rainfall history measured by rain gauges), the history of water usage or release at the dam, changes in the dam's water level, and changes in water level at each location on the river. By analyzing the data acquired by the above-mentioned edges and future weather forecast information received from a weather information cloud service, the river, levee, and dam management CPS server 23B can transmit information for controlling the release amount of water stored in the dam to a gate (edge) installed at the dam, for example.

The river/levee/dam management CPS server 23B may also analyze data such as displacement of water level position and changes in internal pressure of structures (levee or dam walls) collected by sensors or monitoring units (edges) installed on levees or dams, or data such as cracks and fissures on the surface of levees or dams captured or measured by monitoring cameras (edges), to sequentially estimate the condition of levees or dams and generate information for operating and maintaining the levees or dams.

Furthermore, the river/levee/dam management CPS server 23B may analyze future weather forecast information and data such as the current water level of the dam and changes in water level at each location on the river to understand the condition of the levee or dam and identify risks such as collapse or overflow. The river/levee/dam management CPS server 23B may also generate information for formulating construction plans for reinforcement or expansion of levee or dams that are at high risk of collapse or overflow.

The edges corresponding to the water supply and sewerage CPS server 23C include sensors or monitoring units that acquire data on the usage status and usage history of various equipment (filters, pipes, valves, etc.) at the water purification plant and sewage treatment plant, or data on flow rates at each location, for the operation and maintenance of the water purification plant and sewage treatment plant (i.e., water supply and sewerage). The water supply and sewerage CPS server 23C controls the various equipment (edges) at the water purification plant and sewage treatment plant based on the data acquired by such sensors or monitoring units.

The water supply and sewerage CPS server 23C may also store digital twin information for various facilities at water purification plants and sewage treatment plants, for example, and use this information to generate information for formulating plans for the maintenance, upkeep, and new construction of various facilities at water purification plants and sewage treatment plants.

Furthermore, the water supply and sewerage CPS server 23C may implement dynamic pricing (dynamic price setting) for water charges and drainage charges according to drainage volume based on data obtained from the above-mentioned edges.

The infrastructure management system 33 obtains information from the bridge/road management CPS server 23A, river/levee/dam management CPS server 23B, and water/sewerage CPS server 23C, including the latest status of infrastructure such as bridges, roads, rivers, levee, dams, and water/sewerage systems, the status of operation and maintenance, the risk of abnormalities and anticipated damage for each type of infrastructure, and information necessary for formulating plans for infrastructure maintenance. The infrastructure management system 33 lists and organizes the different needs for new construction, renewal, renovation, repair, and maintenance for different types of infrastructure, and generates information that forms the basis for plans for renovation, expansion, and renewal of the entire infrastructure in the relevant area. The information generated in this way is provided to the infrastructure management corporation, the national government, prefectures, cities, towns, and villages, etc.

Note that, while the infrastructure management system 33 has been described here as managing the bridge/road management CPS server 23A, the river/levee/dam management CPS server 23B, and the water supply/sewerage CPS server 23C (i.e., managing bridges, roads, rivers, levee, dams, and water supply/sewerage), the infrastructure managed by the infrastructure management system 33 may also include various facilities, such as government offices and hospitals.

The second mobility SoS 31B described above can optimize the entire mobility service provided by the second mobility SoS 31B and the multiple second mobility CPS servers 21B, improving efficiency, even if it only manages multiple second mobility CPS servers 21B. However, as shown in Figure 4, it may also communicate with the VPP SoS 32.

When electric vehicles are controlled by the mobility service provided by the second mobility SoS 31B (and multiple second mobility CPS servers 21B), the electric vehicles consume large amounts of power when charging. For example, if multiple electric vehicles are charging at the same time, the total amount of power consumed by charging the electric vehicles may exceed the total amount of power generated by each power generation facility (the total amount of power that can be provided by the VPP), creating a risk of power outages and other disruptions. Furthermore, expanding power generation facilities to accommodate situations where multiple electric vehicles are charging at the same time would increase the environmental burden.

For this reason, second mobility SoS31B receives from VPP SoS32 information on the history and predicted value of electricity prices in each region (electricity consumption area) during each time period, as well as information on the history and predicted value of the difference between the total maximum amount of electricity that can be supplied and the total amount of electricity consumed in each region during each time period. In other words, second mobility SoS31B receives from VPP SoS32 information on the amount of electricity available for charging electric vehicles in each region during each time period. Based on the information received from VPP SoS32 in this way, second mobility SoS31B formulates a plan regarding the time period, location, and amount of charge for each electric vehicle. Note that locations where each electric vehicle can be charged include, for example, EV stands, homes, commercial facilities, and public facilities. This plan is formulated from the perspective of minimizing the risk of each electric vehicle running out of power (the battery becoming depleted and the electric vehicle becoming unable to move), minimizing the total electricity costs required to charge all electric vehicles, and cooperating with controls to avoid failures (power outages) at each power generation facility (for example, preventing the total power demand in a given area from exceeding the total available power supply). Cooperation with controls to avoid failures at each power generation facility can be achieved, for example, by staggering the charging times of each electric vehicle, or by staggering the charging times of electric vehicles from peak power usage times at homes, commercial facilities, public facilities, and business facilities.

In other words, by configuring communication (i.e., the exchange of information) between second mobility SoS31B and VPP CPS32, the peak amount of power that must be supplied by each power generation facility (VPP) can be effectively reduced as the number of electric vehicles controlled by second mobility SoS31B increases. Therefore, when second mobility SoS31B and VPP SoS32 cooperate, the risk of failure at each power generation facility can be reduced, and the amount of power generation facility required can be reduced, thereby reducing the environmental impact.

In the example shown in Figure 4, the first mobility SoS 31A does not communicate with the VPP SoS 32. In this case, the first mobility SoS 31A formulates a plan for the time period, location, and amount of charge for each electric vehicle, regardless of the state of the VPP, from two perspectives: minimizing the risk of each electric vehicle running out of power, and minimizing the total electricity cost required to charge all electric vehicles.

On the other hand, even if the first mobility SoS 31A only manages multiple first mobility CPS servers 21A, it is possible to optimize the entire mobility service provided by the first mobility SoS 31A and multiple first mobility CPS servers 21A and improve efficiency, but it may also communicate with the infrastructure management system 33 as shown in Figure 4.

The first mobility CPS server 21A, managed by the first mobility SoS 31A, receives data from sensors (such as LiDAR and millimeter-wave radar) and cameras installed on numerous electric vehicles under its control, allowing it to continuously collect up-to-date information about the road environment as numerous electric vehicles travel. The road environment information can be generated from data obtainable by sensors and cameras on the edge (such as electric vehicles), and can be used, for example, to detect dirt, damage, and aging of roads, signs, guardrails, electric lights, and convex mirrors, or to detect abnormalities in the orientation of signs, guardrails, electric lights, and convex mirrors. Furthermore, the road environment information can be based on sensing data about people, objects, stores, etc. present around the road at each time and location, and may also include information indicating the current state of society. Furthermore, the first mobility CPS server 21A can collect driving logs for numerous electric vehicles (groups). By analyzing the driving logs of many electric vehicles using AI, etc., it is possible to identify (information about) locations where traffic jams are frequent, where acceleration and deceleration occur frequently, where there is a high risk of accidents, where there is a high risk of running out of battery, and where there is a high risk of vehicles (autonomous vehicles and vehicles driven by people) driving in an illegal manner.

In this case, the first mobility SoS 31A transmits the above-mentioned information about the road area and the driving logs of a large number of electric vehicles to the infrastructure management system 33. By analyzing this information and driving logs, the infrastructure management system 33 can generate information for formulating maintenance and repair plans for roads, signs, guardrails, electric lights, convex mirrors, etc. Furthermore, the infrastructure management system 33 may generate information for formulating more beneficial infrastructure maintenance, repair, and new construction plans based on the above-mentioned information indicating the current state of society.

In other words, with a configuration in which communication (i.e., the exchange of information) is performed between the first mobility SoS 31A and the infrastructure management system 33, as the number of electric vehicles controlled by the first mobility SoS 31A increases, it becomes possible to formulate and implement infrastructure maintenance, renovation, and new construction plans that more accurately grasp the current state of society. Therefore, when the first mobility SoS 31A and the infrastructure management system 33 work together as described above, it is possible to improve the contribution of mobility to society as a whole and contribute to reducing environmental impact.

The resilience SoS 40 shown in Figure 4 oversees the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, and infrastructure management system 33, and provides resilience solutions. The resilience SoS 40 provides information useful for dealing with socially difficult situations to various systems (such as SoSs, CPS servers, and other systems operated by various corporations and organizations). The resilience SoS 40 can provide information for changing the control and processing in various systems and the exchange of information (or data) between these systems from a resilience perspective.

In addition, under normal circumstances, the resilience SoS 40 continuously executes processing to detect the occurrence of socially difficult situations. For example, assuming that the socially difficult situation is a natural disaster, the resilience SoS 40 is communicatively connected to a cloud server (hereinafter referred to as the weather system) 50 that provides meteorological information (information about weather conditions) and information about earthquake and tsunami predictions. The resilience SoS 40 sequentially receives information provided by the weather system 50, predicts the occurrence of various natural disasters (weather disasters, earthquake and tsunami disasters, etc.), and detects an increase in the risk of the occurrence of such natural disasters or the occurrence of such natural disasters. Note that the weather system 50 in this embodiment may include, for example, multiple server devices (systems) operated by multiple companies (or corporations, etc.).

In this case, the resilience SoS 40 may receive from the first mobility SoS 31A and second mobility SoS 31B information about the surroundings of electric vehicles, information about the occurrence of abnormal traffic congestion (such as an abnormal concentration of electric vehicles in a specific location), and information about abnormal trends of electric vehicles (such as an abnormal evacuation of electric vehicles from a specific location), which is obtained based on data collected by the first mobility SoS 31A, multiple first mobility CPS servers 21A, second mobility SoS 31B, and multiple second mobility CPS servers 21B, and may predict the occurrence of natural disasters from the received information.

The resilience SoS 40 may also receive from the VPP SoS 32 information indicating abnormal (e.g., excessive) power usage based on data collected by the VPP SoS 32 and multiple VPP CPS servers (VPP power generation CPS server and VPP power transmission/distribution CPS server) 22A and 22B, information regarding the risk (or prediction) of demand exceeding supply, information regarding the risk (prediction) of power line breaks due to fallen trees, etc., and information regarding the risk (prediction) of underground power line breaks due to fault displacement, and may predict the occurrence of natural disasters from the received information.

Furthermore, the resilience SoS 40 may receive from the infrastructure management system 33 information indicating that the infrastructure is in a dangerous state or that a failure has occurred in the infrastructure, which information is obtained based on various sensor data and surveillance camera image data collected by the infrastructure management system 33 and multiple infrastructure CPS servers (bridge and road management CPS server, river, levee and dam management CPS server, and water supply and sewerage CPS server) 23A-23C, and may predict the occurrence of a natural disaster from the received information.

Here, we assume the occurrence of a socially difficult situation such as a natural disaster, but the resilience SoS 40 may also detect the occurrence of a socially difficult situation such as an accident, terrorism, or crime from data collected by the first mobility SoS 31A, the multiple first mobility CPS servers 21A, the second mobility SoS 31B, the multiple second mobility CPS servers 21B, the VPP SoS 32, the multiple VPP CPS servers 22A and 22B, the infrastructure management system 33, and the multiple infrastructure CPS servers 23A-23C.

In this way, the resilience SoS 40 collects information not only from various SoSs (in the example shown in Figure 4, the first mobility SoS 31A, the second mobility SoS 31B, the VPP SoS 32, and the infrastructure management system 33) that communicate with each other via the SoS API, but also from other systems (including the media, the government and public agencies, local governments, etc.), and performs processing to detect the occurrence of socially difficult situations.

In addition, when resilience SoS40 detects an increased risk of a socially difficult situation occurring, the operation of resilience SoS40 is switched from the above-mentioned normal control to high-risk control. Furthermore, when resilience SoS40 actually detects the occurrence of a socially difficult situation, the operation of resilience SoS40 is switched from high-risk control to control when a socially difficult situation occurs.

In the example shown in Figure 4, horizontal SoS 40 is resilience SoS 40, and this resilience SoS 40 has been described as providing a resilience solution for socially difficult situations such as sudden or infrequent natural disasters. However, resilience SoS 40 may be implemented in a manner that can execute processing to detect the risk of a socially difficult situation occurring during normal times and the occurrence of that socially difficult situation. Also, in the example shown in Figure 4, horizontal SoS 40 may be an SoS for a specific purpose or function other than resilience.

In the above-mentioned Figure 4, it was explained that information is exchanged by executing communication between the second mobility SoS 31B and the VPP SoS 32, and information is exchanged by executing communication between the first mobility SoS 31A and the infrastructure management system 33. However, below, with reference to Figure 5, an example of a system configuration for the exchange of information performed in this embodiment will be described.

The system configuration shown in Figure 5 shows a system 61 that provides information (hereinafter referred to as the information providing system) and a system 62 that receives the information (hereinafter referred to as the information receiving system). The information providing system 61 is assumed to be the first mobility SoS 31A and VPP SoS 32 shown in Figure 4, but the information providing system 61 may be any SoS (horizontal SoS or vertical SoS), CPS server, edge, or other system that constitutes an integrated system. Similarly, the information receiving system 62 is assumed to be the second mobility SoS 31B and infrastructure management system 33 shown in Figure 4, but the information receiving system 62 may be any SoS (horizontal SoS or vertical SoS), CPS server, edge, or other system that constitutes an integrated system.

The system configuration shown in Figure 5 also includes an authentication server 63 and an intermediary server 64. As mentioned above, information generated (created) via SoS, CPS servers, edges, etc. is valuable to its holders or sovereigns, namely, countries (governments), local governments, companies (corporations), or individuals. For this reason, the authentication server 63 and intermediary server 64 evaluate and authenticate the information providing system 61 and information receiving system 62 (entities) from various perspectives before information is exchanged.

Specifically, the administrator or management organization (such as a national or local government or company) of the information providing system 61 and the information receiving system 62 obtains prior certification from the certification server 63 in order to participate in a mechanism (platform) for the exchange of information via the intermediary server 64. Requirements for obtaining certification need only be those that confirm that appropriate and secure information exchange is possible while respecting information sovereignty. Examples of requirements for obtaining certification include, for example, that the administrator or management organization of the information providing system 61 (hereinafter simply referred to as the information providing side) can receive appropriate compensation from the administrator or management organization of the information receiving system 62 (hereinafter simply referred to as the information receiving side), that the information receiving side complies with the rules established by the information providing side (such as the purpose and form of use), that the security of the information receiving system 62 is guaranteed, and that the information providing system 61 and the information receiving system 62 handle information in accordance with the laws, regulations, ordinances, and cabinet orders of the country of origin, country of use, region of origin, and region of use.

Furthermore, the usage patterns included in the rules established by the information provider include, for example, the manner in which the information is processed, the scope of disclosure, and whether or not it can be provided to third parties. Furthermore, ensuring the security of the information receiving system 62 includes ensuring that the information receiving system 62 is configured sufficiently to prevent unintentional information leaks and unauthorized access to the information.

It is assumed that the administrators or management organizations (i.e., the information providers and information recipients) of the SoS, CPS servers, edges, and other systems that make up the integrated system shown in Figure 4 meet the requirements for obtaining authentication described above and have obtained authentication from the authentication server 63.

Here, we have explained that the information provider and information recipient have obtained authentication from the authentication server 63, but the administrator or management organization (intermediary side) of the intermediary server 64 also obtains authentication from the authentication server 63.

In other words, only entities that have obtained authentication from the authentication server 63 can become information providers, information recipients, or intermediaries.

In practice, the above-mentioned certification may be carried out after a certification authority official or other person audits each system itself and the organization that manages each system, and confirms its track record, etc.

The intermediary server 64 has the function of mediating the exchange of information (i.e., information transactions) between information providers and information recipients who have received authentication from the authentication server 63. In this case, the intermediary server 64 registers supplementary information (hereinafter referred to as metadata) related to information that is held by the management organizations and administrators of the SoS, CPS servers, edges, and other systems that have received authentication from the authentication server 63 and that can be provided to other management organizations or administrators (hereinafter referred to as provideable information). Note that the provideable information for which metadata is registered in the intermediary server 64 may be, for example, information that includes at least a portion of the data collected from the edges described above, and may also be information generated from that data (information obtained by processing that data), etc.

This metadata includes the content, type, quantity, quality, freshness, acquisition method, format, type, and guarantees of the available information, as well as the conditions required by the information provider for providing the available information. The amount of available information included in the metadata refers to the capacity and size of the available information, but may also refer to, for example, the capacity and size per hour. The freshness of available information included in the metadata indicates, for example, the time lag between the creation of the available information and its provision. The format of the available information included in the metadata includes, for example, file format and extension, as well as whether it complies with specific standards, specifications, and rules. The type of available information included in the metadata indicates whether the available information is personal information, anonymously processed information (information in which the name of personal information has been anonymously processed), or pseudonymized information (information in which the name of personal information has been pseudonymized). The conditions included in the metadata include the consideration (amount) for providing the available information, rules established by the information provider (holder), and matters to be observed by the information provider and information recipient. These conditions may be set by the owner of the available information, by an information provider commissioned by the owner, by a person who collects information other than the owner, or a combination of one or more of these.

The intermediary server 64 has the function of listing and presenting the registered metadata as described above, and serves as an information trading marketplace.

Here, we consider a case where the information receiving system 62 receives information from the information providing system 61 (receives information). In this case, the information receiving system can access the intermediary server 64 and specify specific information that can be provided by the information providing system in the marketplace described above. Note that if the information providing system 61 is a VPP SoS 32 and the information receiving system 62 is a second mobility SoS 31B, the information receiving system 62 will specify information such as the amount of electricity available for charging electric vehicles in each region during each time period.

As a result, when an agreement is reached between the information providing system 61 (information providing side) and the information receiving system 62 (information receiving side) that information specified by the information receiving side will be provided from the information providing side to the information receiving side, the intermediary server 64 permits the information providing system 61 to transmit (provide) that information (hereinafter referred to as provided information) to the information receiving system 62. In this case, the intermediary server 64 transmits information (hereinafter referred to as permission information) to the information providing system 61 and the information receiving system 62 to permit the transmission of the provided information.

In this embodiment, the permission information is, for example, information permitting the transmission of specific provided information from a specific information provider to a specific information recipient. However, it may be any information that enables the exchange of provided information between the information providing system 61 (information providing side) and the information receiving system 62 (information receiving side). Specifically, the permission information may be information indicating the range (use range) of provided information that is permitted to be transmitted, information indicating the period (use period) during which the transmission or use of the provided information is permitted, or security information for securely transmitting the provided information. Note that the security information may be, for example, information specifying a communication method for ensuring security (public key cryptography, quantum cryptography, etc.), or information using a security token or security parameters (information specifying an encryption method and encryption key), etc. The permission information sent to the information providing system 61 and the permission information sent to the information receiving system 62 may be of any type as long as it allows the transmission of specific provided information from the information providing system 61 to the information receiving system 62; the same information may be sent to the information providing system 61 and the information receiving system 62, or different information may be sent to the information providing system 61 and the information receiving system 62.

The above-mentioned permission information is transmitted to the information providing system 61 and the information receiving system 62 after the intermediary server 64 confirms that the information providing and receiving parties have agreed to provide (transfer) information or that the conditions between the information providing and receiving parties for the provision of the information have been met (or that the parties intend to meet those conditions). The intermediary server 64 may also confirm that the conditions between the information providing and receiving parties have been met or that the parties intend to meet those conditions by confirming that the payment procedures for the fee for the provision of the information have been completed or that there is an intention to pay (including, for example, agreement to continue to pay the fee for the period during which the provided information can be used).

Furthermore, instead of or in addition to confirming payment of compensation for the provision of information, the intermediary server 64 may confirm the intention to use the provided information for a specific purpose. Specific purposes for using the provided information include, for example, purposes related to resilience response, highly public purposes such as providing information to national and local governments for the formulation of infrastructure renovation plans, and purposes from which the information provider can directly or indirectly benefit.

The intermediary server 64 may also be configured to confirm that there is an intention to fulfill obligations under specific alternative conditions. Specifically, intentions to fulfill obligations under specific alternative conditions include, for example, an intention to fulfill obligations that will have a positive impact on the information provider's business, and an intention to comply with the SDGs (Sustainable Development Goals) or specified guidelines that require a separate contract to be concluded for the fulfillment of obligations that differ from laws, etc. Furthermore, for example, if the information providing system 61 is a VPP SoS 32 and the information receiving system 62 is a second mobility SoS 31B, the intermediary server 64 may be configured to confirm agreement to an obligation to cooperate with demand response or to reduce peak electricity usage by staggering the charging of electric vehicles.

Note that while it has been explained here that various matters, including the completion of the payment procedures described above, are confirmed in order to confirm whether the conditions between the information provider and the information recipient regarding the provision of information are met or whether the parties intend to meet those conditions, it is also possible to confirm matters other than those described here, or to confirm a combination of two or more of the matters described here.

Here, when the information providing system 61 (e.g., VPP SoS 32) and the information receiving system 62 (e.g., second mobility SoS 31B) receive permission information from the intermediary server 64, P2P (direct) communication is established between the information providing system 61 and the information receiving system 62, and the information providing system 61 begins sending provided information to the information receiving system 62. The provided information sent from the information providing system 61 to the information receiving system 62 (e.g., information on the amount of power available for charging electric vehicles in each region during each time period) is updated continuously, including, for example, past history and future predictions, and the information providing system 61 and the information receiving system 62 regularly and continuously communicate directly within the scope (scope of use and period of use) permitted by the intermediary server 64.

For example, if the information providing system 61 is a VPP SoS 32 and the information receiving system 62 is a second mobility SoS 31B, the condition that the second mobility SoS 31B must satisfy to receive information from the VPP SoS 32 may be payment of a fee, or handling of the information in accordance with the laws, regulations, ordinances, and cabinet orders of the country of origin, country of use, region of origin, and region of use. Furthermore, the condition that the second mobility SoS 31B must satisfy to receive information from the VPP SoS 32 may be cooperation in reducing peak power usage and distributing power usage by controlling the time periods for charging electric vehicles based on information on the difference between the total maximum amount of power that can be supplied in each region during each time period and the total amount of power consumed.

Furthermore, the information providing system 61, the intermediary server 64, or another cloud server (not shown) may provide the format of the provided information transmitted from the information providing system 61 to the information receiving system 62 and information for interpreting the provided information together with the provided information. In this way, even if information based on different formats or different data definitions is held between the information providing system 61 and the information receiving system 62, or between multiple information providing systems 61, the provided information can be appropriately used in the information receiving system 62 by converting and unifying the format using the information for interpreting the provided information. The format conversion and unification may be performed by at least one of the information providing system 61, the information receiving system 62, the intermediary server 64, or a cloud server providing services related to format conversion and unification. The information receiving system 62 may receive information related to format conversion and unification from the intermediary server 64, etc.

Here, we have mainly explained the case where the information providing system 61 is a VPP SoS 32 and the information receiving system 62 is a second mobility SoS 31B, but the exchange of information between the information providing system 61 and the first mobility SoS 31A and the information receiving system 62 and the infrastructure management system 33 can also be realized according to the scheme described in Figure 5.

In this case, the first mobility SoS 31A transmits provided information (e.g., information about the road area and driving logs of multiple electric vehicles) to the infrastructure management system 33. The provided information is transmitted (provided) sequentially, for example, when an infrastructure abnormality is detected by at least one of the multiple infrastructure CPS servers 23A-23C managed by the infrastructure management system 33. Furthermore, when the provided information from the first mobility SoS 31A is used for the purpose of maintaining and inspecting roads, signs, guardrails, electric lights, convex mirrors, etc., the provided information may be transmitted from the first mobility SoS 31A to the infrastructure management system 33 approximately once a day. Furthermore, when the provided information is used for future infrastructure planning (urban planning), etc., the information obtained up to that time may be transmitted in bulk, for example, once every month, every three months, or every six months.

Note that the exchange of information between the resilience SoS 40 and the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, and infrastructure management system 33 shown in FIG. 4 may also be realized using the scheme described in FIG. 5. The same applies to communication between each SoS and each CPS server, and communication between each CPS server and the edge.

Here, in Figure 4 above, the operation of the integrated system during normal times was described, for example. However, if an increased risk of a socially difficult situation is detected, the operation of the integrated system (Resilience SoS40) will switch from normal control to high-risk control, as described above.

Below, with reference to the flowchart in Figure 6, we will explain an example of the processing steps of the integrated system when an increased risk of a socially difficult situation is detected. Note that in the following explanation, "socially difficult situations" refer to concentrated heavy rain caused by a typhoon and the resulting flooding, inland flooding, power outages, etc. (hereinafter simply referred to as flood damage).

First, the integrated system (resilience SoS 40, first mobility SoS 31A, multiple first mobility CPS servers 21A, second mobility SoS 31B, multiple second mobility CPS servers 21B, VPP SoS 32, multiple VPP CPS servers 22A and 22B, infrastructure management system 33, multiple infrastructure CPS servers 23A-23C, and edges corresponding to each of the CPS servers) executes the process shown in FIG. 6 while repeating the operations described above in FIG. 4.

In this case, the resilience SoS40 determines whether the risk of flooding is high based on continuous and periodic predictions of the risk of occurrence of the above-mentioned flooding (hereinafter simply referred to as flood risk) (step S1).

Note that flood risk prediction may be performed by the resilience SoS 40 based on weather information provided by the weather system 50, for example, or may be performed by another system or server device (e.g., the weather system 50). For example, if flood risk prediction is performed by the weather system 50, the resilience SoS 40 simply receives the flood risk prediction results (or information for identifying increased flood risk, etc.) from the weather system 50.

If it is determined that the risk of flooding is not high (NO in step S1), the process returns to step S1 and is repeated.

On the other hand, suppose that the weather system 50 predicts that a typhoon will hit a specific area in a few days, and information for identifying an increased risk of flooding is received from the weather system 50. In this case, the resilience SoS 40 detects the increased risk of flooding and determines that the risk of flooding is high (YES in step S1).

If it is determined in step S1 that there is a high risk of flooding, the following processing from step S2 onwards is executed, but the operations described in Figure 4 above will continue. This allows, for example, the prediction of the occurrence of socially difficult situations other than flooding and the identification of risks other than flooding risks to continue.

Next, the resilience SoS40 predicts the nature of the flood risk (step S2). In this case, the resilience SoS40 predicts the likelihood of what types of risks occurring in each region based on the meteorological information held by the weather system 50 (future precipitation forecasts for each region, typhoon paths, predicted locations of sudden heavy rain, etc.) and information about infrastructure held by the infrastructure management system 33 (water storage capacity of dams, drainage capacity of each drainage facility, etc.). As mentioned above, the (types of) flood risk include, for example, flood risk, inland flooding risk, and power outage risk.

Regarding flood risk, areas predicted to be inundated due to levee breaches and overflows are set as flood warning areas, based on, for example, the results of regular checks of levee facilities, locations predicted to be prone to levee breaches (i.e., locations with a high risk of breaches) and locations on the levee that are close to the river water level and predicted to be prone to overflows when the river rises (i.e., locations with a high risk of overflows). Areas surrounding flood warning areas may also be set as flood alert areas.

Regarding the risk of inland flooding, for example, areas that are predicted to be flooded when rainfall exceeds the drainage capacity of drainage facilities (sewer storm drains and pump facilities) and water cannot be discharged are set as inland flooding warning areas. In addition, areas surrounding inland flooding warning areas may also be set as inland flooding caution areas.

Regarding the risk of power outages, for example, based on the location where power lines are predicted to be cut by fallen trees (i.e., the location where the risk of power line breakage is high), the area where a power outage is predicted to occur when the power line is cut is set as the power outage warning area. The area surrounding the power outage warning area may also be set as the power outage caution area.

Resilience SoS40 creates a hazard map (hereinafter referred to as a real-time hazard map) as a result of the prediction made in step S2. Note that the infrastructure management system 33 holds hazard maps for each region, for example, and Resilience SoS40 creates a real-time hazard map (information) based on the hazard map by reflecting the prediction results for each type of risk described above. Furthermore, the basic information required to create the real-time hazard map (map information including the locations of homes, commercial facilities, infrastructure, etc., and information on the height of each piece of land) can be obtained from the hazard map held by the infrastructure management system 33 described above, but may also be obtained from a source other than the infrastructure management system 33.

Figure 7 shows an example of the real-time hazard map described above. In the example shown in Figure 7, a slide bar is provided at the bottom of the real-time hazard map. In other words, the real-time hazard map is created so that, by operating the slide bar, it is possible to provide information on current and future flood risk based on each time period, such as now, 1 hour, 2 hours, 3 hours, half a day later, 1 day later, 2 days later, 3 days later, and several days later, based on the current time. Note that the real-time hazard map in this embodiment may also be created to provide information on past flood risk in addition to information on current and future flood risk.

Next, the resilience SoS 40 provides (transmits) the flood risk (flood risk, inland flooding risk, and power outage risk) prediction content obtained in step S2 to the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, and infrastructure management system 33 managed by the resilience SoS 40 (step S3). The prediction content provided in step S3 may be the real-time hazard map itself, or a portion of information extracted from the real-time hazard map. In other words, the prediction content provided in step S3 may differ depending on the recipient. Furthermore, the flood risk prediction content may be provided to systems other than the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, and infrastructure management system 33.

Once the processing of step S3 is executed, the resilience SoS40 collects information corresponding to the flood risk predicted in step S2 (step S4). In this case, the resilience SoS40 collects information on people, vehicles, facilities, electricity, etc. present within the above-mentioned flood alert area (flood warning area), inland water flooding alert area (inland water flooding warning area), and power outage alert area (power outage warning area).

Here, the resilience SoS 40 is assumed to be communicatively connected to a system 70 that manages mobile phones (hereinafter referred to as the mobile phone management system) as shown in Figure 8. Mobile phones managed by the mobile phone management system 70 are assumed to be, for example, smartphones with GPS (Global Positioning System) functionality, but the mobile phones may also be conceptually understood to include mobile terminals such as tablet computers with GPS functionality.

Note that the mobile phone management system 70 in this embodiment may include multiple server devices (systems) operated by multiple companies (or corporations, etc.). Note that Figure 8 is the same as Figure 4 except for the addition of the mobile phone management system 70, so a detailed description of it will be omitted here.

The above-mentioned person information is collected, for example, from the mobile phone management system 70 based on location information from mobile phones or smartphones. The person information collected in this way makes it possible to identify the number of people present within each of the alert areas and caution areas set in relation to the above-mentioned flood risk. The person information collected from the mobile phone management system 70 also includes demographic information (attribute information) such as age and gender.

In this case, the risk of a power outage can be calculated (predicted) based on the estimated power restoration period based on the number of people in the power outage alert area and power outage warning area, and the amount of power required by each person in the power outage alert area and power outage warning area. Note that the amount of power required by each person is assumed to be stored in advance in the VPP SoS 32 or VPP CPS servers 22A and 22B, etc.

Furthermore, flood risk and inland flooding risk can be calculated (predicted) by taking into account, for example, the number of people present in a flood warning area, flood warning area, inland flooding warning area, and inland flooding warning area, and the likelihood of evacuation in the event of an emergency based on the demographic information of each person present in the flood warning area, flood warning area, inland flooding warning area, and inland flooding warning area. Note that the demographic information in this case may also include information on the need for assistance (such as whether or not care is required or whether or not the person has a disability).

Note that the information about people collected from the mobile phone management system 70 here does not need to be information that can identify individuals (i.e., personal information), but rather information that includes each person's location and demographic information (anonymously processed information or pseudonymized information, etc.).

Vehicle information is collected from the first mobility SoS31A and the second mobility SoS31B based on the location information of electric vehicles (and other vehicles). In this case, vehicles present in each alert area, each caution area, and their surrounding areas can be used as a means of evacuation and transportation, and the number of people that can be accommodated for each area (region) (the number of people who can be evacuated using vehicles) is identified (predicted). The vehicle information may also include image data captured by cameras mounted on vehicles present in each alert area, each caution area, and their surrounding areas. Note that mobility means such as electric vehicles controlled by the first mobility SoS31A and the second mobility SoS31B can be used as a means of transportation in the same way as under normal circumstances until actual damage occurs (flooding occurs) or until such damage is imminent.

Facility information is collected from the infrastructure management system 33 based on the location information of each facility (government offices, hospitals, etc.). Based on the facility information collected in this way, flood risk can be calculated (predicted) taking into account that in the event of a flood (flood, inland water inundation, or power outage), normal operation at each facility will be impossible, or that some functions will have to be reduced due to reliance on emergency power equipment. The facility information may also include, for example, image data captured by surveillance cameras installed within the facility.

Power information is collected from VPP SoS32 based on the location information of various power generation facilities and the areas subject to power transmission and distribution. It includes, for example, the status of power generation facilities within each alert area and each caution area, the status of power transmission and distribution, the status of power storage, and forecasts of supply and demand in the event of a power outage. This power information makes it possible to calculate (predict) flood risk by considering the difference between the amount of power generated by power generation facilities installed within each alert area and each caution area under normal circumstances and the amount of power generated in the event of a flood. Power generation facilities that will be unavailable in the event of a flood or inland flooding can be determined based on the installation location and height of the facility and its related facilities. Power generation facilities that will be unavailable in the event of a power outage can be determined based on whether they are facilities that cannot operate without grid power, or whether they have a function (black start function) that allows them to operate even during a power outage (when there is no power supply to the grid).

Resilience SoS40 calculates (predicts) flood risk, including flood risk, inland flooding risk, and power outage risk, for all alert and caution areas based on four perspectives: people, vehicles, facilities, and electricity, for each region (for example, an area divided into a 100m mesh or an area based on units such as cities, wards, towns, and villages). Note that various methods can be applied to calculate flood risk (flood risk, inland flooding risk, and power outage risk), and AI (deep learning, machine learning, etc.) may be used, for example. Resilience SoS40 may collect information other than those mentioned above and may consider (calculate) risks other than those mentioned above.

Once step S4 is completed as described above, the process returns to step S2 and is repeated. In this case, through the exchange of various information described above with the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, infrastructure management system 33, meteorological system 50, and mobile phone management system 70, the resilience SoS 40 can sequentially predict flood risk (flood risk, inland flooding risk, and power outage risk) for each region, from detecting an increased risk of flooding due to a direct hit from a typhoon to eliminating the risk of flooding due to a significant shift in the typhoon's path or the typhoon passing by, and provide real-time hazard maps to relevant organizations, etc. Providing such real-time hazard maps is useful for encouraging voluntary early evacuation and proactive measures.

As described above, when an increased flood risk is detected, the resilience SoS 40 must sequentially update the real-time hazard map, which is created based on information regarding all alert and caution areas. The resilience SoS 40 operates to collect various information even under normal circumstances, but when an increased flood risk is detected, it operates to continuously and periodically receive a large amount of information at a higher frequency than under normal circumstances. In other words, when an increased flood risk (risk of a socially difficult situation occurring) is detected in the integrated system of this embodiment, the exchange of information between the horizontal SoS, vertical SoS, and other systems becomes more intensive. Meanwhile, communication between the resilience SoS 40 and the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, infrastructure management system 33, etc. under normal circumstances may be less frequent than when an increased flood risk is detected.

Based on the predictions of various natural disasters and the risk levels of those natural disasters, the manner in which information is exchanged between the resilience SoS 40 and each of the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, infrastructure management system 33, weather system 50, and mobile phone management system 70 is determined in advance. In other words, when the integrated system is configured as shown in FIG. 8, for example, the preparatory procedures (including contracts, etc.) for enabling the reception of information on (identifying) increased risks of various natural disasters from the weather system 50 and the reception of real-time human information, which is basic information for predicting (calculating) risks in the event of a natural disaster, from the mobile phone management system 70 have been completed in advance according to the scheme described above in FIG. 5. In other words, the weather system 50 and the mobile phone management system 70, like the resilience SoS 40, are systems (i.e., systems that constitute the integrated system) that have obtained authentication from the authentication server 63 shown in FIG. 5.

When the process shown in Figure 6 is executed, steps S2 to S4 are repeatedly executed to collect a large amount of information about each area (alert area and caution area), and the accuracy of information about various risks and information about anticipated damage (e.g., real-time hazard maps) can be improved based on this large amount of collected information. This large amount of collected information corresponds to information that can be used to construct a digital twin, for example.

Although not shown in FIG. 6, if the accuracy of the above-mentioned risk information and information on anticipated damage reaches a certain level, the resilience SoS 40 may execute processing (control) for disaster mitigation. Whether the accuracy is above a certain level can be determined based on, for example, the number of times the processing of steps S2 to S4 shown in FIG. 6 is executed, but it may also be determined from other perspectives.

In this case, the resilience SoS 40 can prepare for securing power in the event of a flood by prioritizing charging of all electric vehicles via the first mobility SoS 31A and the second mobility SoS 31B, and can also guarantee (improve) the possibility of evacuation by gathering electric vehicles in advance near each alert area and each caution area for evacuation in the event of an emergency. However, if a flood risk of a certain level or higher is confirmed, all vehicles, including electric vehicles, may be evacuated outside of each area (alert area and caution area).

The Resilience SoS 40 also suppresses power consumption by raising electricity rates via the VPP SoS 32, and promotes the accumulation of electricity (i.e., charging stationary storage batteries installed in individual homes, apartment complexes, commercial facilities, and public facilities, converting electricity to hydrogen using P2C at hydrogen stations, etc.) in conjunction with this suppression of power consumption. This allows for advance preparations to ensure power is available in the event of a natural disaster, so that stored electricity can be discharged even in the event of a power outage. It is also possible to store electricity according to the characteristics of each area (alert area and caution area). In this case, for areas with a high risk of flooding, for example, electricity can be stored in high-ground equipment (such as stationary storage batteries) or priority can be given to charging electric vehicles. Furthermore, for areas (regions) that would be isolated in the event of a power outage, priority can be given to storing electricity in equipment capable of providing power to the area.

Furthermore, the resilience SoS 40 can reduce the risk of flooding in each area (alert area and caution area) if the dam is opened after the water level rises due to heavy rain, for example, by reducing the amount of water stored in the dam (i.e., opening the dam) via the infrastructure management system 33 (river/levee/dam management CPS server 23B). In addition, processing may be performed to maximize the drainage capacity of wastewater treatment facilities in each area (alert area and caution area).

Here, the disaster mitigation processing has been described as being performed by the resilience SoS 40, but as described above, the first mobility SoS 31A, second mobility SoS 31B, VPP SoS 32, and infrastructure management system 33 may each perform disaster mitigation processing (control) based on the real-time hazard map sequentially provided by the resilience SoS 40.

Furthermore, while it has been explained here that disaster mitigation processing is executed when the accuracy of information related to risk and anticipated damage reaches a certain level, executing the above-mentioned disaster mitigation processing places a heavy burden on society when the probability of a natural disaster (for example, flooding) occurring is low. For this reason, disaster mitigation processing may be executed when it is determined that a flood risk is imminent based on meteorological information provided by the weather system 50 (that is, for example, there is an extremely high probability that a typhoon will hit directly in the next few days). However, since it is preferable to complete disaster mitigation processing before a natural disaster actually occurs, it is executed taking into account the time allowance between the detection of an increased risk of flooding due to a direct typhoon hit and the actual typhoon hitting.

Figure 6 explains the operation of the integrated system when an increased risk of flooding (risk of a socially difficult situation occurring) is detected, but if the occurrence of such flooding is actually detected, the operation of the integrated system described above will switch to control for when such flooding occurs.

Below, we will explain an example of the processing procedures of the integrated system in the event of an actual flood disaster, with reference to the flowchart in Figure 9. Note that the above-mentioned normal operations and operations (processing) when an increased risk of flood disaster is detected are assumed to be performed continuously, separate from the processing shown in Figure 9.

First, the resilience SoS40 determines whether a flood (natural disaster) has actually occurred (step S11). As described above, if flooding includes flooding, inland flooding, and power outages, in step S11, it is determined that a flood has occurred if at least one of flooding, inland flooding, and power outages occurs.

Whether or not a flood has actually occurred can be determined from the information provided by the weather system 50 described above, as well as data on the damage situation related to the occurrence of floods collected by, for example, the national and local governments, police, fire departments, and news organizations.

If it is determined that no flood damage has occurred (NO in step S11), the process returns to step S11 and is repeated.

On the other hand, if it is determined that a flood has occurred (YES in step S11), the resilience SoS40 identifies the area where the flood (damage caused by the flood) occurred (hereinafter referred to as the flood-occurred area) and the area surrounding the flood-occurred area (hereinafter referred to as the flood-surrounding area) (step S12).

In step S12, the flood-prone area is identified by receiving information from the national and local governments, police, fire departments, and news organizations, etc., to identify the area where flooding (flooding, inland flooding, and power outages) has occurred.

The flood-prone area may be identified based on, for example, image data captured by cameras mounted on electric vehicles and received via the first mobility SoS 31A and the second mobility SoS 31B, and image data captured by surveillance cameras installed in various public facilities and received via the infrastructure management system 33. The flood-prone area includes an area where flooding has occurred (hereinafter referred to as a flood-prone area), an area where inland flooding has occurred (hereinafter referred to as an inland flooding area), and an area where a power outage has occurred (hereinafter referred to as a power outage area).

In addition, if it is determined that a flood has occurred as described above (i.e., if the occurrence of a flood is detected), the above-mentioned disaster mitigation processing may be performed for the flood-proximate area identified in step S12.

Hereinafter, Resilience SoS40 collects information regarding the flood-prone area and surrounding flood-prone areas identified in step S12 described above, but when a flood occurs, it is preferable to obtain more information than during normal times or when an increased flood risk is detected.

Here, in the event of a flood, identifying the flood-prone area and people in the surrounding area with water can be useful information for rescuing the user.

In this case, since the mobile phone management system 70 holds personal information (personal information related to natural persons) of users who own mobile phones managed by the mobile phone management system 70, it is conceivable that the resilience SoS 40 could use, for example, personal information of users located in the flood-affected area and surrounding areas from the mobile phone management system 70 in providing resilience solutions. However, even if advance procedures have been implemented to enable the receipt of personal information such as location information and demographic information (anonymously processed information or pseudonymized information) from the mobile phone management system 70 in accordance with the scheme described above in Figure 5, the resilience SoS 40 would not be able to use the personal information described above.

For this reason, as mentioned above, it is preferable to carry out advance procedures in accordance with the scheme described in Figure 5 in order to use personal information held by the mobile phone management system 70 to provide resilience solutions in the event of a flood, for example.

However, while the law requires prior consent from users (those with jurisdiction over the personal information) before providing personal information to third parties, it would be difficult to obtain prior consent from all users who may reside within the flood-prone and flood-prone areas described above. Furthermore, the scope of the exceptions in the Personal Information Protection Act that exempt third parties from requiring consent is unclear. In such cases, it would be possible to obtain consent from users residing within flood-prone and flood-prone areas before using their personal information in the Resilience SoS40. However, obtaining consent from each user is not practical in the face of socially challenging situations such as flooding. On the other hand, using the personal information of users for whom prior consent has been obtained but not the personal information of users for whom prior consent has not been obtained (i.e., not including it in information on people needing rescue or damage information, etc.) would be considered unethical.

Here we have explained the personal information of users held by the mobile phone management system 70, but from the perspective of providing high-quality resilience solutions in the event of a socially difficult situation such as a flood, it is preferable for information to be exchanged flexibly between the SoS, CPS server, edge and other systems that make up the integrated system.

In this embodiment, when a socially difficult situation such as a flood occurs, the resilience SoS40 executes a process (hereinafter referred to as the information transmission permission process) to permit specific information (provided information) to be used for a specific purpose to be sent (provided) from a specific information providing system to a specific information receiving system, in accordance with the scheme described in Figure 5 (step S13). Details of the information transmission permission process will be described later.

When the processing of step S13 is executed, the resilience SoS40 collects various information regarding the flood-prone area and surrounding flood-prone area identified in step S12, including the specific provision information permitted for transmission in step S13 (step S14). The information collected in step S14 is used to provide resilience solutions.

Once step S14 is executed, the process returns to step S12 and is repeated. In this case, steps S12 to S14 are repeatedly executed until, for example, the flood and the damage related to the flood (i.e., the socially difficult situation) are resolved.

Next, an example of the processing steps for the information transmission permission process described above will be explained with reference to the flowchart in Figure 10.

In the information transmission permission process, resilience SoS 40 operates as the intermediary server described above. In this case, resilience SoS 40 confirms that a specific information providing system and a specific information receiving system have been authenticated by the authentication server (step S21).

Next, the resilience SoS40 sets the usage conditions for the specific provided information according to the purpose and usage form of the specific provided information (step S22). The usage conditions set in step S22 include the range within which the specific provided information can be used (usage range) and the period during which the provided information is transmitted from the information providing system to the information receiving system (usage period).

The terms of use set in step S22 may differ from the terms registered (set) by the information providing system (information providing side) or the authority of the specific provided information described in FIG. 5 above. In this embodiment, the authority of the specific provided information is, for example, the person who has the right to make the final decision regarding the use of the provided information. If the specific provided information is personal information, the individual (natural person) is the authority of the provided information. On the other hand, if the specific provided information is information about a corporation, the corporation is the authority of the provided information, and if the specific provided information is information about a government or local public entity, the government or local public entity is the authority of the provided information. The terms registered (set) by the authority may also include terms of use agreed to in advance by the authority (e.g., a natural person). Note that the information provider and the authority may differ, for example, in cases where the information provider (system administrator or management organization) is simply the entity that collects the information.

When the processing of step S22 is executed, the resilience SoS40 assumes that the specific information provider and the specific information recipient have agreed to the terms of use set in step S22 (i.e., that the terms of use between the information provider and the information recipient for the provision of the specific information have been confirmed to be met) (step S23).

When the processing of step S23 is executed, resilience SoS40 generates permission information to permit the transmission of specific provided information and transmits the permission information to the specific information providing system and the specific information receiving system. The permission information generated by resilience SoS40 includes the usage conditions, etc., set in step S22. In other words, the permission information includes information for specifying the usage conditions of the specific provided information. The permission information is transmitted to the specific information providing system and the specific information receiving system, but the information for specifying the usage conditions of the specific provided information may be transmitted to at least one of the specific information providing system and the specific information receiving system.

As described above, a specific information providing system that receives the permission information transmitted from resilience SoS 40 transmits the specific provided information to the information receiving system in accordance with the permission information. On the other hand, a specific information receiving system that receives the permission information transmitted from resilience SoS 40 receives the specific provided information transmitted from the specific information providing system. The specific provided information received by the specific information receiving system in this way is used in accordance with the usage conditions (i.e., information that specifies the usage conditions) and the like included in the permission information transmitted from resilience SoS 40.

Here, in the above-mentioned Figure 10, the resilience SoS 40 is described as operating as the intermediary server, but the intermediary server may be something other than the resilience SoS 40 (i.e., there may be an intermediary server other than the resilience SoS 40).

Below, with reference to the flowchart in Figure 11, we will explain an example of the processing steps for information transmission permission processing when there is an intermediary server other than the resilience SoS 40.

In this case, the resilience SoS40 sets the usage conditions for the specific provided information according to the purpose and usage form of the specific provided information (step S31). The usage conditions set in step S31 are the same as the usage conditions set in step S22 shown in Figure 10 above.

Next, the resilience SoS40 assumes that the specific information provider and the specific information recipient have agreed to the terms of use set in step S31 (i.e., that the terms of use between the information provider and the information recipient for the provision of the specific information have been confirmed to be met) (step S32).

When step S32 is executed, resilience SoS40 transmits information (hereinafter referred to as instruction information) to the intermediary server instructing the intermediary server to permit the transmission of the specific provided information (step S33). The instruction information transmitted in step S33 includes an instruction to overwrite the usage conditions set in step S31 as the usage conditions for the specific provided information, and an instruction that the specific information provider and the specific information recipient have agreed to the usage conditions.

When the intermediary server receives the instruction information sent from the resilience SoS 40 as described above, it performs processing similar to that shown in Figure 10 in accordance with the instructions from the resilience SoS 40 contained in the instruction information.

The information transmission permission process described above follows the scheme described in Figure 5 (i.e., the same procedure as a normal marketplace), but skips time-consuming procedures such as payment of fees, allowing Resilience SoS 40 to permit (or instruct permission for) the transmission of specific provided information from a specific information providing system to a specific information receiving system.

In this embodiment, the exchange of specific provided information (provided information used for a specific purpose) between a specific information providing system and a specific information receiving system is determined by Resilience SoS40. However, the specific provided information, specific information providing system, and specific information receiving system (combination) may be predetermined in association with, for example, a type of socially difficult situation (e.g., flooding), or may be dynamically determined by analyzing information indicating the status of the flood-prone area and surrounding areas using AI or the like. Furthermore, the specific provided information, specific information providing system, and specific information receiving system may be determined in consideration of the specifications of the system including the SoS, CPS server, and edge, whether or not authentication has been performed by an authentication server, legal compliance status, security level, information in possession, and information that may be obtained in the future. It is assumed that Resilience SoS40 has prior knowledge of the information necessary to determine the specific provided information, specific information providing system, and specific information receiving system.

Furthermore, since this embodiment is configured to exceptionally permit the exchange of specific provided information in response to the occurrence of a socially difficult situation, the provided information, information providing system, and information receiving system will be determined so that the scope of use and disclosure of the provided information described above is kept to the minimum necessary.

The above-mentioned information transmission permission process (determination of specific provided information, specific information providing system, and specific information receiving system) may be executed at the initiative of resilience SoS 40. Specifically, resilience SoS 40 can execute the information transmission permission process (decide to send specific provided information from a specific information providing system to a specific information receiving system) without receiving a request from the specific information receiving system for permission to send the specific provided information. Resilience SoS 40 can also execute the information transmission permission process without receiving a request from either the information providing system or the information receiving system for permission to send the provided information. The information transmission permission process may also be executed in accordance with a request (demand) from the SoS, CPS server, edge, and other systems that make up the integrated system.

Furthermore, the determination of the above-mentioned specific provided information, specific information providing system, and specific information receiving system (i.e., the determination of whether to send specific provided information from a specific information providing system to a specific information receiving system) may be made when the satisfaction of a predetermined condition is confirmed by the resilience SoS40. The satisfaction of this predetermined condition may include, for example, the occurrence of a flood or the expansion or contraction of a flood-affected area. Furthermore, the satisfaction of a predetermined condition may include, for example, an indication that the occurrence of a flood has been confirmed or an indication that specific information needs to be shared (i.e., manual input of specific information).

Below, we will explain a specific example of how the integrated system will operate in the event of an actual flood. First, with reference to Figure 12, we will explain how personal information of users held by the mobile phone management system 70 is used to provide resilience solutions.

The resilience SoS 40 transmits information for identifying the above-mentioned flood-prone areas (flood-prone areas, inland flooding areas, and power outage areas) and surrounding flood areas to the mobile phone management system 70, and receives from the mobile phone management system 70 the personal information of users who own mobile phones located within the flood-prone areas and surrounding flood areas.

In this case, by executing the above-mentioned information transmission permission process, it is assumed that permission has been granted to send the user's personal information from the mobile phone management system 70 to the resilience SoS 40. Note that the specific provided information (provided information used for a specific purpose) in the information transmission permission process in this case is the user's personal information used to identify people in need of rescue in a flood and to understand the damage situation related to the flood. Furthermore, the specific information providing system and specific information receiving system in the information transmission permission process are the mobile phone management system 70 and the resilience SoS 40, respectively.

As described above, the user's personal information received from the mobile phone management system 70 includes, for example, the user's name, age, gender, address, email address, mobile phone number, location information of the mobile phone, the time the location information was acquired, and at least some of the user's activity level, estimated health level, estimated evacuation status, etc. based on changes in the location information over time.

Note that while the location information included in the user's personal information is assumed to be obtained, for example, by a GPS function (or a gyro sensor, etc.), the location information may also be information indicating a location estimated from the location of the base station with which the mobile phone communicates and connects. In other words, the location information may be information that indicates the location of the mobile phone with a certain degree of accuracy.

Furthermore, for example, in areas experiencing power outages, it is expected that a mobile phone will lose contact due to a disruption in communication between the mobile phone and a base station. Similarly, in flood-prone areas and areas subject to inland flooding, a mobile phone may lose contact due to a base station malfunction or failure, or the mobile phone may lose contact due to being submerged in water. In such cases, personal information including location information indicating the location of the mobile phone immediately before it lost contact may be received from the mobile phone management system 70.

Resilience SoS 40 can use the personal information of users whose mobile phones are located in the flood-affected area or surrounding areas, received (collected) from the mobile phone management system 70 as described above, to provide resilience solutions. In this case, Resilience SoS 40 transmits rescue needer information indicating those in need of rescue and damage information indicating the damage situation in response to the occurrence of flooding to a server device (hereinafter referred to as the firefighting system) 80 installed in a facility to which emergency teams and fire brigades belong, for example. In this case, an information transmission permission process is executed in which the specific provided information is the user's personal information, the specific information providing system is Resilience SoS 40, and the specific information receiving system is the firefighting system 80. Note that the firefighting system 80 is authenticated by the authentication server described above.

Here, the firefighting system 80 is assumed to be composed of multiple server devices installed, for example, in each region. In this case, the destination of the user's personal information is assumed to be limited to the server device that has jurisdiction over the flood-affected area and the surrounding area. Furthermore, instead of transmitting all of the user's personal information described above, it is also possible to transmit only a portion of the information necessary for emergency services and firefighting, for example.

In addition, while the information transmission permission process has been described here as being executed with the specific provided information being the user's personal information, the specific information providing system being the resilience SoS 40, and the specific information receiving system being the fire protection system 80, if it is assumed that the user's personal information will be transmitted (transferred) from the resilience SoS 40 to the fire protection system 80, permission information for permitting the transfer of the personal information to the fire protection system 80 may be transmitted to the resilience SoS 40 in the information transmission permission process with the specific provided information being the user's personal information, the specific information providing system being the mobile phone management system 70, and the specific information receiving system being the resilience SoS 40. In this case, the conditions for use of the personal information included in the permission information transmitted to the resilience SoS 40 may include, for example, information that can identify one or more other server devices (here, the fire protection system 80) to which the personal information (at least a portion of it) can be transmitted.

In light of the fact that flood-prone areas are less urgent than flood-occurring areas, for users whose mobile phones are located within such flood-prone areas, anonymously processed information or pseudonymized information in which the names have been processed may be sent to the firefighting system 80 as information on future rescue recipients (future damage prediction information) rather than personal information including names, etc.

The personal information of users who own mobile phones located within the flood-affected area and surrounding flood-affected areas is used as information on people in need of rescue, and may be transmitted to a server device (hereinafter referred to as the medical system) 90 installed in a medical institution such as a hospital, as shown in Figure 13. In this case, an information transmission permission process is executed in which the specific provided information is the user's personal information, the specific information providing system is the resilience SoS 40, and the specific information receiving system is the medical system 90. Note that the medical system 90 is assumed to have been authenticated by the authentication server described above.

If the above-mentioned medical system 90 is composed of multiple server devices installed in each region, for example, the destination of the user's personal information will be limited to the server device that has jurisdiction over the flood-affected area and the surrounding area. Furthermore, instead of transmitting all of the above-mentioned user's personal information, for example, only a portion of the information necessary for the user's treatment may be transmitted.

Next, with reference to Figure 14, we will explain the case where user personal information held by first mobility SoS31A and second mobility SoS31B is used to provide resilience solutions.

First mobility SoS31A and second mobility SoS31B provide mobility services as described above, and are assumed to hold personal information of users receiving the mobility services. The personal information of users held by first mobility SoS31A and second mobility SoS31B includes, for example, the user's name, age, gender, address, email address, and mobile phone number.

In this case, the resilience SoS40 transmits information for identifying the flood-prone area and flood-surrounding area to the first mobility SoS31A and the second mobility SoS31B, and receives information on mobility (e.g., electric vehicles) present within the flood-prone area and flood-surrounding area (hereinafter referred to as EV information) from the first mobility SoS31A and the second mobility SoS31B.

The EV information received from the first mobility SoS31A and the second mobility SoS31B includes personal information of users receiving the mobility services described above (i.e., users currently using the electric vehicles). The transmission of users' personal information from the first mobility SoS31A and the second mobility SoS31B to the resilience SoS40 is permitted by the execution of the information transmission permission process described above. The specific provided information (information used for a specific purpose) in this information transmission permission process is personal information of users used to understand the latest status of people in need of rescue in the event of a flood. Note that the specific provided information is not the personal information of all users currently using electric vehicles, but is limited to the personal information of users currently using electric vehicles whose current location is within a flood-prone area or surrounding flood areas (particularly areas surrounding flood-prone areas and inland flooding areas) or whose destination is within a flood-prone area or surrounding flooding area. Furthermore, the specific information providing systems in the information transmission permission process are first mobility SoS 31A and second mobility SoS 31B, and the specific information receiving system is resilience SoS 40.

As explained above, EV information includes personal information of users using electric vehicles. However, the EV information also includes the electric vehicle's departure point, destination, current location, remaining battery power, and other information, such as the vehicle's driving range and status. The status included in the EV information may include, for example, whether or not the service is being provided (the user is using the vehicle), and if the user is using the vehicle, the information may indicate the user's situation (i.e., the user's status).

Resilience SoS 40 can use the EV information received (collected) from first mobility SoS 31A and second mobility SoS 31B to provide resilience solutions. Below, we will explain an example of a resilience solution that uses EV information.

First, if the current location of an electric vehicle in use is within a flood-prone area (particularly a flood or inland flooding area) or a surrounding area of the flood-prone area (particularly an area surrounding a flood or inland flooding area), and the destination is outside the flood-prone area or the surrounding area, Resilience SoS40 can infer that the user of the electric vehicle is evacuating. Such a user is set as a person in need of rescue, and the user's status can be updated during evacuation.

Furthermore, if the current location of an electric vehicle in use is outside the flood-prone area or surrounding area, and the electric vehicle's destination is within the flood-prone area or surrounding area, Resilience SoS40 (or First Mobility SoS31A and Second Mobility SoS31B, etc.) will prompt the user to change the destination, except in special circumstances such as when the user is a rescue team. In this case, control may be exercised to forcibly change the electric vehicle's destination.

Furthermore, if the current location and destination of an electric vehicle in use are both within a flood-prone area or surrounding area, Resilience SoS40 (or First Mobility SoS31A and Second Mobility SoS31B) may prompt the driver to change the destination based on predictions of future changes in flood risk, etc.

Here, Resilience SoS40 can receive (collect) information about electric vehicles (EV information) from the first mobility SoS31A and the second mobility SoS31B, for example, when the current location and destination of the electric vehicle in use are both outside the flood-prone area and surrounding area. Note that this EV information does not need to include the user's personal information. Such electric vehicles whose current location and destination are both outside the flood-prone area and surrounding area can be used as mobility for rescue, relief, and evacuation in the flood-prone area. Therefore, Resilience SoS40 (or the first mobility SoS31A and the second mobility SoS31B) may secure and operate the electric vehicle as mobility for rescue, relief, and evacuation in the flood-prone area as soon as the electric vehicle whose current location and destination are both outside the flood-prone area and surrounding area is no longer in use. In this case, the destination of the electric vehicle that has been discontinued may be automatically set to a location near the flood-prone area and surrounding area.

Note that the resilience solution using the resilience SoS40 (or the first mobility SoS31A and second mobility SoS31B) described above is an example, and the resilience SoS40 may be configured to perform other operations (controls).

In addition, Resilience SoS 40 may transmit personal information of users whose electric vehicles are currently in use within the flood-prone area or surrounding area and whose destination is outside the flood-prone area or surrounding area to the fire department system 80 as rescue recipient information. In this case, an information transmission permission process is executed in which the specific information to be provided is the user's personal information, the specific information providing system is Resilience SoS 40, and the specific information receiving system is the fire department system 80.

The first mobility SoS 31A and the second mobility SoS 31B each oversee multiple mobility CPS servers 21A and 21B, and control a large number of mobilities (electric vehicles, etc.). Therefore, when a large number of electric vehicles traveling different routes according to the travel needs of each user capture images of the environment around the electric vehicle using cameras (imaging devices) mounted on the electric vehicle, the captured image data provides useful information for understanding the damage situation in the event of a flood.

For this reason, Resilience SoS40 may transmit information identifying the flood-prone area and surrounding areas to First Mobility SoS31A and Second Mobility SoS31B, and receive image data captured by electric vehicles located in the flood-prone area and surrounding areas from First Mobility SoS31A and Second Mobility SoS31B. In this case, Resilience SoS40 may transmit the image data (still images or video) received from First Mobility SoS31A and Second Mobility SoS31B, or damage information indicating the latest damage situation based on the image data, to, for example, Infrastructure Management System 33 and Fire Protection System 80, or may provide the information to national or local governments, etc. Note that the image data received from First Mobility SoS31A and Second Mobility SoS31B may be accompanied by information such as the time and location at which the image data was captured. Furthermore, the image data received from the first mobility SoS31A and second mobility SoS31B may be, for example, a range image or range video that can be obtained using LiDAR or millimeter wave radar.

Here, the amount of information and data volume of image data received from a large number of electric vehicles becomes enormous, and there are concerns that this could further worsen the communication environment, which is expected to be strained during floods (disasters). For this reason, it is preferable to reduce the number of communications during floods, for example.

In this case, when determining the specific provided information, specific information providing system, and specific information receiving system in the information transmission permission process described above (i.e., generating permission information or instruction information), the resilience SoS 40 may prevent itself from receiving the provided information to be exchanged. In other words, it is preferable for the resilience SoS 40 to receive information necessary for the resilience SoS 40 to understand the current flood risk and damage situation (for example, to create a digital twin related to the damage situation), but other information may be exchanged directly between the SoS, CPS server, edge, and other systems that make up the integrated system, without going through the resilience SoS 40. Whether or not to include the resilience SoS 40 in the information exchange path may be individually and specifically selected based on the provided information (contents) to be exchanged, etc.

Specifically, for example, when the above-described information transmission permission process is executed with the mobile phone management system 70 as the specific information providing system and the fire protection system 80 as the specific information receiving system, it is possible to transmit the user's personal information directly from the mobile phone management system 70 to the fire protection system 80.

Here, for example, consider a case where one of the multiple infrastructure CPS servers managed by the infrastructure management system 33 is a river, levee, and dam management CPS server 23B. As shown in FIG. 15, consider a case where image data captured by a camera mounted on an electric vehicle located in the vicinity of (or traveling in the surrounding area of) a location where a levee managed (maintained) by the river, levee, and dam management CPS server 23B is located within a flood-prone area and its surrounding areas is transmitted from the first mobility SoS 31A and the second mobility SoS 31B to the river, levee, and dam management CPS server 23B.

In this case, if the advance procedures for exchanging image data between the first mobility SoS 31A and second mobility SoS 31B and the river, levee and dam management CPS server 23B are not carried out, the river, levee and dam management CPS server 23B will not be able to receive the image data from the first mobility SoS 31A and second mobility SoS 31B, even though the image data is useful information for understanding the damage status of the levee and carrying out maintenance.

In this case, the resilience SoS40 can provide specific information (information used for a specific purpose) as image data of the area around the levee in the flood-prone area and surrounding areas used to check the latest status of the levee (damage status, etc.), and by executing an information transmission permission process with the first mobility SoS31A and second mobility SoS31B as the specific information providing system and the river, levee, and dam management CPS server 23B as the specific information receiving system, it can enable (permit) the exchange of image data between the first mobility SoS31A and second mobility SoS31B and the river, levee, and dam management CPS server 23B.

Note that while a river, levee, and dam management CPS server 23B is installed, for example, in each region, the destination of image data from the first mobility SoS 31A and the second mobility SoS 31B is limited to the river, levee, and dam management CPS server 23B that manages levees within flood-prone areas and flood-prone areas.

Here, we assume that the first mobility SoS 31A and the second mobility SoS 31B manage image data captured by multiple electric vehicles controlled by multiple mobility CPS servers 21A and 21B, for each predetermined area (region). In this case, the first mobility SoS 31A and the second mobility SoS 31B can transmit (provide) image data selected from all managed image data (i.e., redundant image data) based on criteria such as high pixel count, images that are not out of focus, and the most recent time of capture (i.e., image data that has undergone processing to eliminate redundancy) to the river, levee, and dam management CPS server 23B. The river, levee, and dam management CPS server 23B can receive the image data transmitted from the first mobility SoS 31A and the second mobility SoS 31B and perform control such as levee maintenance based on the image data.

The image data described above may also be sent directly to the river, levee, and dam management CPS server 23B from one of the multiple mobility CPS servers 21A and 21B, for example, a mobility CPS server that controls electric vehicles located in the flood-prone area and surrounding areas. In this case, an information transmission permission process may be executed in which the specific provided information (information used for a specific purpose) is image data of the area around the levee in the flood-prone area and surrounding areas used to check the latest status of the levee (damage status, etc.), the specific information providing system is the mobility CPS servers 21A and 21B, and the specific information receiving system is the river, levee, and dam management CPS server 23B.

In this configuration, where image data is sent directly from mobility CPS servers 21A and 21B to river, levee and dam management CPS server 23B, image data that has not yet been processed to eliminate redundancy by first mobility SoS 31A and second mobility SoS 31B is received by river, levee and dam management CPS server 23B, and therefore processing equivalent to the process to eliminate this redundancy must be performed on the river, levee and dam management CPS server 23B side. However, in this case, there is no need to send image data from mobility CPS servers 21A and 21B to first mobility SoS 31A and second mobility SoS 31B, thereby reducing communication costs.

Also, as shown in Figure 16, consider a case where information about electric vehicles (EV information) located in a power outage area (limited area) and the surrounding area of the power outage area is transmitted from the first mobility SoS 31A and the second mobility SoS 31B to the VPP power transmission and distribution CPS server 22B.

In this case, if the pre-procedures for exchanging EV information between the first mobility SoS 31A and the second mobility SoS 31B and the VPP electricity transmission and distribution CPS server 22B are not carried out, the VPP electricity transmission and distribution CPS server 22B will not be able to receive the EV information from the first mobility SoS 31A and the second mobility SoS 31B, even though the EV information is useful for utilizing the electricity stored in the electric vehicle's storage battery.

In this case, the resilience SoS 40 can enable (permit) the exchange of EV information between the first mobility SoS 31A and the second mobility SoS 31B and the VPP electricity transmission and distribution CPS server 22B by executing an information transmission permission process in which specific provided information (information used for a specific purpose) is information on electric vehicles (EV information) located in the power outage area and surrounding areas used to resolve the power outage, and the specific information providing system is the first mobility SoS 31A and the second mobility SoS 31B, and the specific information receiving system is the VPP electricity transmission and distribution CPS server 22B.

Note that while a VPP electricity transmission and distribution CPS server 22B is installed, for example, in each region, the destination of EV information from the first mobility SoS 31A and the second mobility SoS 31B is limited to the VPP electricity transmission and distribution CPS server 22B (i.e., the VPP specific region electricity transmission and distribution server) whose electricity transmission and distribution area is the area where the power outage occurred (i.e., which transmits and distributes electricity to the area where the power outage occurred).

In this configuration in which EV information is sent from the first mobility SoS 31A and the second mobility SoS 31B to the VPP electricity transmission and distribution CPS server 22B, for example, electric vehicles with high battery levels can be gathered in the area where the power outage has occurred, and under the control of the VPP electricity transmission and distribution CPS server 22B, the power stored in the batteries installed in those electric vehicles can be simultaneously discharged, temporarily resolving the power outage in the area where the power outage has occurred.

Here, we have explained the case where the first mobility SoS 31A and the second mobility SoS 31B (multiple mobility CPS servers 21A and 21B) control an electric vehicle as a form of mobility, but if, for example, an electric vessel or drone is controlled as a form of mobility, it is also possible to use the electricity stored in the storage battery installed on the electric vessel or drone.

Although detailed explanation will be omitted, the weather system 50, mobile phone management system 70, firefighting system 80, and medical system 90 described in this embodiment may be managed by the resilience SoS 40.

As described above, in this embodiment, when the resilience SoS 40 confirms that the objective conditions are met, the resilience SoS (horizontal SoS) 40 determines, for example, whether to transmit first information including at least a portion of data collected by a first server device belonging to a first industrial domain from one or more first edges to a second server device belonging to a second industrial domain, or whether to transmit second information including at least a portion of data collected by the second server device from one or more second edges from the second server device to the first server device (i.e., a combination of specific provided information, a specific information providing system, and a specific information receiving system). If the resilience SoS 40 determines that the first information should be transmitted from the first server device to the second server device, the resilience SoS 40 transmits information to the first server device and the second server device to permit the transmission of the first information from the first server device to the second server device. On the other hand, if resilience SoS 40 determines that the second information is to be transmitted from the second server device to the first server device, resilience SoS 40 transmits information to the first server device and the second server device to permit the transmission of the second information from the second server device to the first server device.

In this embodiment, this configuration enables smooth exchange of information between multiple server devices belonging to different industrial domains.

Specifically, the resilience SoS 40 has the function of authorizing the transmission (exchange) of the provided information (provided information used for a specific purpose) according to the combination of the specific information provider system and the specific information recipient system. This allows the resilience SoS 40, a horizontal SoS overseeing multiple industrial domains, to collect useful information from vertical SoSs overseeing each of the industrial domains, such as the first mobility SoS 31A, the second mobility SoS 31B, and the VPP SoS 32, as well as other systems such as the infrastructure management system 33. This allows for a bird's-eye view across multiple industrial domains, facilitating the exchange of information necessary for resilience solutions. When information is collected from multiple industrial domains (vertical SoSs, CPS servers, edge systems, and other systems) as described in this embodiment, it is possible to use the collected information to construct a digital twin that recreates the real-world (real-space) situation of each industrial domain (e.g., mobility, energy, and infrastructure) in cyberspace (virtual space), as shown in Figure 17. Furthermore, if the processing of steps S12 to S14 shown in Figure 9 above is repeated, the accuracy (level of detail) of this digital twin can be improved, making it possible to provide high-quality resilience solutions using this digital twin.

Note that Resilience SoS 40 has the functionality of an intermediary server in the scheme (information exchange scheme) described in Figure 5. Generally, the intermediary server confirms that the conditions for providing information set by the information provider are met, and then transmits permission information to the information providing system and the information receiving system to authorize the provision (transmission) of information.

However, when a socially difficult situation such as a flood (disaster) occurs, confirming the fulfillment of conditions for information provision, which is equivalent to a consensus (such as the conclusion of a contract) between the information provider and the information recipient, goes against the demand for a rapid response. Furthermore, it is not realistic to ensure a consensus in advance for all combinations of corporations, systems, and servers that may exchange information in the event of a flood. Furthermore, simply achieving a consensus in advance may not be enough to respond to cases where unexpected information provision is required. For this reason, the resilience SoS 40 of this embodiment allows the transmission of information when a specified condition such as a flood occurs, assuming that the conditions for information provision set by the information provider have been met.

The above-mentioned first server device includes a first CPS server (e.g., a first mobility CPS server 21A and a second mobility CPS server 21B, etc.) and a first vertical SoS (e.g., a first mobility SoS 31A and a second mobility SoS 31B, etc.) that oversees the first CPS server, and the above-mentioned second server device includes a second CPS server (e.g., a VPP power generation CPS server 22A and a VPP power transmission and distribution CPS server 22B, etc.) and a second vertical SoS (e.g., a VPP SoS 32, etc.) that oversees the second CPS server, and the resilience SoS 40 is configured to oversee the first and second vertical SoS. That is, the above-mentioned first information may be transmitted from the first vertical SoS to the second vertical SoS, from the first vertical SoS to the second CPS Server, from the first CPS Server to the second vertical SoS, or from the first CPS Server to the second CPS Server. Also, the above-mentioned second information may be transmitted from the second vertical SoS to the first vertical SoS, from the second vertical SoS to the first CPS Server, from the second CPS Server to the first vertical SoS, or from the second CPS Server to the first CPS Server.

Furthermore, when resilience SoS40 determines that the first information is to be transmitted from the first server device to the second server device as described above, resilience SoS40 transmits permission information specifying the conditions of use of the first information to at least one of the first server device and the second server device. These conditions of use of the first information are determined by resilience SoS40 and may differ from the conditions of use set by the administrator of the first server device (i.e., the information provider) or the sovereign of the first information (e.g., a user, etc.). On the other hand, when resilience SoS40 determines that the second information is to be transmitted from the second server device to the first server device, resilience SoS40 transmits permission information specifying the conditions of use of the second information to at least one of the first server device and the second server device. These conditions of use of the second information are determined by resilience SoS40 and may differ from the conditions of use set by the administrator of the second server device or the sovereign of the second information. More specifically, if the first information or second information includes a user's personal information (personal information related to a natural person), the terms of use of the first information or second information are determined by the resilience SoS 40 and may differ from the terms of use previously agreed to by the user (natural person).

In this embodiment, with this configuration, even if the resilience SoS (horizontal SoS) 40 allows the transmission of information, the limited information is used only in a specific, limited information receiving system under limited conditions, thereby preventing the information from being used for fraudulent purposes, etc.

Note that the usage conditions included in the permission information transmitted from the resilience SoS 40 to the first and second server devices include, for example, the scope or period of use of the information, but the permission information need only be information for permitting the transmission (transmission) of information. Specifically, the permission information may be information that indicates that the conditions for the transmission and reception of information have been satisfied, or may be information necessary for the transmission and reception of information, or may further include the type, quantity, quality, freshness, acquisition method, format, and type of the provided information to be transmitted and received. Furthermore, the usage conditions included in the permission information may include, for example, information that identifies one or more other servers to which the second server device can transfer part of the provided information.

Furthermore, if the permission information sent from Resilience SoS 40 to the first and second server devices does not include a usage period, when it is determined that the flood and flood-related damage (i.e., the socially difficult situation) has subsided, Resilience SoS 40 may send information to the information providing system and the information receiving system to stop the exchange of information (i.e., the transmission of information from the information providing system to the information receiving system) or the use of information (i.e., the use of information already received in the information receiving system), or may send information to the intermediary server instructing the exchange or use of information to be stopped.

Furthermore, when the resilience SoS40 generates the permission information, at least a portion of the information used to generate the permission information may be received from another system or may be manually entered. Note that at least a portion of the information used to generate the permission information may include, for example, specific provided information (specific purpose), information on a specific information providing system, and information on a specific information receiving system. Furthermore, at least a portion of the information used to generate the permission information may include, for example, information on whether or not to generate permission information.

Here, we have described a case in which resilience SoS (horizontal SoS) 40 operates as an intermediary server, but it is also possible to configure a system in which an intermediary server separate from the resilience SoS 40 is installed. Specifically, when it is decided that first information will be transmitted from the first server device to the second server device, the resilience SoS 40 simply transmits instruction information to the intermediary server (third server device) to instruct the intermediary server to permit transmission of the first information from the first server device to the second server device. On the other hand, when it is decided that second information will be transmitted from the second server device to the first server device, the resilience SoS 40 simply transmits instruction information to the intermediary server to instruct the intermediary server to permit transmission of the second information from the second server device to the first server device.

In this case, the intermediary server receives instruction information (request) from resilience SoS40, considers that the conditions for information provision set by the information provider have been met, and sends permission information to the information providing system and the information receiving system to permit the exchange (transmission) of the information.

For the sake of convenience, the first and second server devices have been described here as being a vertical SoS and a CPS server, but the first and second server devices may be at least one of the horizontal SoS, vertical SoS, CPS server, edge, and other systems that make up the integrated system described above. Furthermore, while this embodiment has been described primarily as the horizontal SoS overseeing the vertical SoS, the integrated system may be configured without a vertical SoS, and the horizontal SoS may be configured to oversee at least multiple CPS servers.

Furthermore, in this embodiment, the horizontal SoS (resilience SoS 40) is described as executing the information transmission permission process (i.e., when certain conditions are confirmed, the information providing system decides to transmit the provided information to the information receiving system), but the function for executing the information transmission permission process (i.e., the function related to permission to transmit information) may be realized, for example, on the vertical SoS side. Furthermore, in this embodiment, the horizontal SoS is described as overseeing a first server device belonging to a first industrial domain and a second server device belonging to a second industrial domain different from the first industrial domain, but the first industrial domain and the second industrial domain may be different or the same.

As mentioned above, this embodiment includes a configuration that allows the exceptional exchange of specific provided information in response to the occurrence of a socially difficult situation, so it is preferable that the fact that the exchange of this specific provided information has been permitted be transparent.

For this reason, the resilience SoS40 is further equipped with the storage function, viewing function, and automatic deletion function shown in FIG. 18.

The storage function is a function for storing information (hereinafter referred to as permission content information) indicating that the exchange of specific provided information (i.e., specific information provided from a specific information providing system to a specific information receiving system for a specific purpose) is permitted when the above-mentioned permission information or instruction information is generated in Resilience SoS40. Note that Resilience SoS40 is equipped with a storage device (server) that stores information collected in the integrated system and information generated by Resilience SoS40 in response to each of the following situations: during normal times, when an increased risk of flooding is detected, and when flooding occurs, and the above-mentioned permission content information is also stored in this storage device.

The permission information stored by the storage function is explained below. The permission information includes basic and detailed information regarding the permission to send and receive the specific provided information described above.

Figure 19 shows an example of the data structure of basic information included in permission content information. As shown in Figure 19, the basic information includes type, information providing system, information receiving system, permission date and time, event, purpose, and deletion status.

The type indicates the type of specific provided information that is permitted to be exchanged, such as personal information, anonymously processed information, and pseudonymized information.

The information providing system refers to the system that provided the specific provided information that is permitted to be exchanged (i.e., the providing system). The information receiving system refers to the system that received the specific provided information that is permitted to be exchanged (i.e., the receiving system).

The permission date and time indicates the date and time when permission information or instruction information for permitting the exchange (transmission) of specific provided information was generated. The permission date and time may be the date and time when the permission information was sent from the resilience SoS 40 or the intermediary server to the information providing system and the information receiving system, or the date and time when the instruction information was sent from the resilience SoS 40 to the intermediary server.

The event indicates the background event (i.e., the type of socially difficult situation), such as a flood, that led to the Resilience SoS40 allowing the exchange of specific information.

The purpose indicates the purpose for which specific provided information is permitted to be sent from the information providing system to the information receiving system (i.e., the reason for providing the information). Examples of purposes include identifying people in need of rescue in a flood, understanding the damage situation, or resolving a power outage. This purpose corresponds to the conditions for use, such as the scope of use of the specific provided information.

The deletion status indicates whether specific provided information sent (provided) from the information providing system to the information receiving system has been deleted in the information receiving system.

Note that Figure 19 shows the permission content information (basic information included therein) stored by the storage function when permission information for permitting the transmission of a user's personal information from the mobile phone management system 70 to the resilience SoS 40 or instruction information for instructing permission for such transmission is generated, as described above. However, the permission content information is stored in the storage device each time permission information or instruction information is generated.

Furthermore, for example, as described above, if the information providing system or information receiving system is limited (restricted) in the scope in which specific provided information is exchanged based on the flood-affected area or flood-prone area (region), etc., it is preferable that the permission content information be stored in a manner that clearly indicates that the information providing system or information receiving system is limited. Furthermore, the basic information included in the permission content information may include various pieces of information based on various pieces of information stored in the storage device, and may further include, for example, (information about) the period of use of specific provided information, etc.

Figure 20 shows an example of the data structure of detailed information included in permission content information. Detailed information is information that indicates details of specific provided information that was actually exchanged. The example shown in Figure 20 shows that provided information including name, age, gender, address, email address, mobile phone number, mobile phone location information, and the time the location information was acquired was sent from the information providing system (mobile phone management system 70) shown in Figure 19 above to the information receiving system (resilience SoS 40). Note that depending on the type of provided information, such as personal information, anonymously processed information, and pseudonymized information, some or all of the detailed information may be in a format that has undergone various data processing, such as anonymization or pseudonymization.

The viewing function presents the permission content information (basic information and detailed information) stored by the storage function in response to an external request (i.e., makes it possible to view permission-related information from outside). Note that if the exchange of a user's personal information held by the mobile phone management system 70 is permitted as specific provided information, the viewing function can be used, for example, by the user (the user himself/herself).

In this case, for example, a user accesses a website related to resilience solutions using a smartphone or other device and enters the ID and password assigned to the user. If the Resilience SoS40 (its viewing function) determines that the personal information of the user identified by the entered ID, password, etc. (viewing request) is being sent (provided) as specific provided information from the information providing system to the information receiving system, it generates viewing screen information for displaying permission information (basic information and detailed information) indicating that the exchange of the user's personal information has been permitted, and sends the viewing screen information to the user's smartphone. On the smartphone side, a viewing screen containing the permission information is displayed based on the viewing screen information, allowing the user to view (confirm) the permission information.

Whether the personal information of a user who entered an ID and password has been sent (provided) from the information providing system to the information receiving system as specific provided information can be determined, for example, by comparing the user's name or mobile phone number, etc., identified by the ID and password, with the name or mobile phone number in the detailed information included in the permission content information. Alternatively, without comparing the information included in the permission content information, it may be determined whether the user's personal information has been sent (provided) from the information providing system to the information receiving system as specific provided information, for example, by linking it with the user's ID registered in the information providing system.

In addition, as described above, if specific provided information is exchanged without going through resilience SoS40, the information providing system or information receiving system included in the permitted content information (basic information) may be inquired as to whether the user who accessed the website related to resilience solutions (the user who entered the ID and password) is a user who is authorized to view the permitted content information.

As described above, in this embodiment, the specific information provided that is permitted to be exchanged by Resilience SoS40 may include personal information for which prior consent has not been obtained for provision to a third party. However, the viewing function makes it possible to confirm the circumstances under which specific information, including personal information, was provided to a third party (information provider, information recipient, content, timing, etc.).

It is preferable that the information providing system and information receiving system displayed on the viewing screen described above be displayed in a way that allows users to understand that specific information has been exchanged within a limited scope. For example, by displaying the event and purpose of the information on the viewing screen, it becomes possible to understand that information has been exchanged within the limited scope of responding to the occurrence of a socially difficult situation such as a water disaster (e.g., a flood).

Here we have explained the case where the viewing function is used by a user who is authorized to exchange personal information, but the viewing function can also be used by the information provider (i.e., the administrator or management organization of the information provider system).

The automatic deletion function is a function that controls the automatic deletion of specific information sent from an information providing system to an information receiving system by the information receiving system.

In this case, after Resilience SoS40 decides to transmit specific provided information from the information providing system to the information receiving system, Resilience SoS40 determines whether the intended use of the specific provided information has been achieved. For example, if the socially difficult situation is a flood, whether the intended use of the specific provided information has been achieved can be determined based on the damage situation related to the flood based on meteorological information and other information. Furthermore, whether the intended use has been achieved may also be determined based on set usage conditions, such as whether the usage period included in the above-mentioned permission information or instruction information has elapsed.

When resilience SoS40 determines that the purpose of use of the specific provided information has been achieved, it sends information to the information receiving system requesting the deletion of the specific provided information (hereinafter referred to as the "deletion request") and confirms whether the specific provided information has been deleted by receiving a response to the deletion request (e.g., a response indicating whether the provided information has been deleted) from the information receiving system. Note that the deletion request may include, for example, information that enables the information receiving system to identify the deadline for deleting the specific provided information. In this case, for example, the information receiving system can delete the specific provided information when the deadline for deleting the specific provided information has arrived, and send a response (response to the deletion request) to resilience SoS40 indicating that the provided information has been deleted.

When it is confirmed that specific provided information has been deleted, the deletion status of the basic information included in the above-mentioned permission information is updated. This deletion status is displayed as permission information on the viewing screen described above, so the user can understand that, for example, their personal information has been used only within the limited scope of responding to the above-mentioned socially difficult situation, and has been appropriately deleted by the information receiving system.

As described above, by having storage, viewing, and automatic deletion functions, Resilience SoS40 can disclose that the specific information it has authorized for transmission and reception will only be used in emergencies such as when a socially difficult situation arises, providing a sense of security to users whose personal information, for example, has been provided without their prior consent.

In this embodiment, the explanation has been primarily focused on providing resilience solutions for socially difficult situations such as flooding. However, the resilience SoS 40 may also provide resilience solutions to prepare for social issues such as food waste, poverty alleviation, traffic accidents, and greenhouse gas emissions (decarbonization). However, unlike flooding, food waste, poverty alleviation, traffic accidents, and greenhouse gas emissions (decarbonization) are likely to occur frequently even under normal circumstances. Therefore, it is preferable that the resilience SoS 40 (horizontal SoS) be configured to maintain constant and close communication with various vertical SoSs, CPS servers, edges, and systems, and to perform orchestration to optimize the entire integrated system.

Furthermore, the application or use of the horizontal SoS according to this embodiment is not limited to resilience, and the horizontal SoS may also be used for vertical SoS or CPS server collaboration between different industrial domains.

While several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These embodiments can be implemented in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are within the scope of the invention and its equivalents as defined in the claims, as well as the scope and spirit of the invention.

11, 12...Edge, 21, 21A, 21B, 22, 22A, 22B, 23A-23C...CPS server (server device), 31, 31A, 31B, 32...Vertical SoS (server device), 33...Infrastructure management system, 40...Horizontal SoS (server device), 40a...CPU, 40b...Non-volatile memory, 40c...Main memory, 40d...Communication device, 50...Weather system, 61...Information providing system, 62...Information receiving system, 63...Authentication server, 64...Intermediary server, 70...Mobile phone management system, 80...Fire fighting system, 90...Medical system.

Claims (24)

A method executed by a horizontal SoS (System of Systems) that manages a first server device belonging to a first industry domain and a second server device belonging to a second industry domain different from the first industry domain, the method comprising:
When the horizontal SoS confirms that a first condition is satisfied, the horizontal SoS determines a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device;
When the first server device is determined as the first system and the second server device is determined as the second system, the horizontal SoS transmits, to the first server device and the second server device, information for permitting transmission of first information from the first server device to the second server device;
the first information includes personal information about natural persons collected by the first server device from one or more first edges;
The transmission of the first information is permitted even without the consent of the natural person if a second condition is met ;
the horizontal SoS transmits information for defining a use condition of the first information to at least one of the first server device and the second server device;
The conditions of use of the first information are determined by the horizontal SoS and may differ from the conditions of use previously agreed upon by the natural person . A method executed by a horizontal SoS (System of Systems) that controls a first server device belonging to a first industry domain and a second server device belonging to a second industry domain different from the first industry domain, the method comprising:
When the horizontal SoS confirms that a first condition is satisfied, the horizontal SoS determines a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device;
When the first server device is determined as the first system and the second server device is determined as the second system, the horizontal SoS transmits, to the first server device and the second server device, information for permitting transmission of first information from the first server device to the second server device;
the first information includes at least a portion of data collected by the first server device from one or more first edges;
the horizontal SoS transmits information for defining a use condition of the first information to at least one of the first server device and the second server device;
The method, wherein the conditions of use of the first information are determined by the horizontal SoS and may differ from the conditions of use set by an administrator of the first server device or a sovereign of the first information. the first server device is a first vertical SoS that controls first CPS servers belonging to the first industrial domain;
The method of claim 1 or 2, wherein the horizontal SoS dominates at least the first vertical SoS. the first server device is a first CPS server managed by a first vertical SoS belonging to the first industry domain,
The method according to claim 1 or 2, wherein the horizontal SoS controls at least the first CPS server by controlling the first vertical SoS. the first information includes personal information relating to a natural person;
The method of claim 2 , wherein the terms of use of the first information may differ from terms of use previously agreed to by the natural person. 3. The method according to claim 1 , wherein the conditions for use of the first information include information that enables the second server device to identify one or more other servers to which the second server device can transfer at least a portion of the first information. the horizontal SoS transmits information to the second server device requesting deletion of the first information;
The method according to claim 1 , wherein the information for requesting the deletion of the first information includes information that enables the second server device to identify a deadline for deleting the first information. 8. The method of claim 1, wherein the horizontal SoS determines the first system and the second system when it confirms satisfaction of the first condition without receiving a request for permission to transmit information from either the first server device or the second server device . 8. A method according to any one of claims 1 to 7, wherein the horizontal SoS determines the first server device as the first system and determines the second server device as the second system when it confirms satisfaction of the first condition without receiving a request from the second server device to send the first information from the first server device to the second server device. The method according to claim 1 , wherein the horizontal SoS presents first permission information indicating that transmission of the first information is permitted in response to an external request. A method executed by a horizontal SoS (System of Systems) that controls a first server device belonging to a first industrial domain and a second server device belonging to a second industrial domain different from the first industrial domain, and is capable of communicating with a third server device that permits data transmission between at least the first server device and the second server device, the method comprising:
When the horizontal SoS confirms that a first condition is satisfied, the horizontal SoS determines a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device;
When the first server device is determined as the first system and the second server device is determined as the second system, the horizontal SoS includes transmitting, to the third server device, information for instructing the third server device to permit transmission of first information from the first server device to the second server device;
the first information includes personal information about natural persons collected by the first server device from one or more first edges;
The transmission of the first information is permitted even without the consent of the natural person if a second condition is met ,
the horizontal SoS transmits information for defining a use condition of the first information to at least one of the first server device and the second server device;
The terms of use of the first information are determined by the horizontal SoS and may differ from terms of use previously agreed upon by the natural person . A method executed by a horizontal SoS (System of Systems) that controls a first server device belonging to a first industrial domain and a second server device belonging to a second industrial domain different from the first industrial domain, and is capable of communicating with a third server device that permits data transmission between at least the first server device and the second server device, the method comprising:
When the horizontal SoS confirms that a first condition is satisfied, the horizontal SoS determines a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device;
When the first server device is determined as the first system and the second server device is determined as the second system, the horizontal SoS includes transmitting, to the third server device, information for instructing the third server device to permit transmission of first information from the first server device to the second server device;
the first information includes at least a portion of data collected by the first server device from one or more first edges;
the horizontal SoS transmits information for defining a use condition of the first information to at least one of the first server device and the second server device;
The method, wherein the conditions of use of the first information are determined by the horizontal SoS and may differ from the conditions of use set by an administrator of the first server device or a sovereign of the first information. the first server device is a first vertical SoS that controls first CPS servers belonging to the first industrial domain;
The method of claim 11 or 12 , wherein the horizontal SoS dominates at least the first vertical SoS. the first server device is a first CPS server managed by a first vertical SoS belonging to the first industry domain,
The method according to claim 11 or 12 , wherein the horizontal SoS controls at least the first CPS server by controlling the first vertical SoS. the first information includes personal information relating to a natural person;
The method of claim 12 , wherein the terms of use of the first information may differ from terms of use previously agreed to by the natural person. 13. The method according to claim 11 , wherein the conditions for use of the first information include information that enables the second server device to identify one or more other servers to which the second server device can transfer at least a portion of the first information. the horizontal SoS transmits information to the second server device requesting deletion of the first information;
The method according to any one of claims 11 to 16 , wherein the information for requesting the deletion of the first information includes information by which the second server device can identify a deadline for deleting the first information. 18. The method of claim 11, wherein the horizontal SoS determines the first system and the second system when it confirms satisfaction of the first condition without receiving a request for permission to transmit information from either the first server device or the second server device . 18. A method according to any one of claims 11 to 17, wherein the horizontal SoS determines the first server device as the first system and determines the second server device as the second system when it confirms satisfaction of the first condition without receiving a request from the second server device to send the first information from the first server device to the second server device. 20. The method according to claim 11 , wherein the horizontal SoS presents first permission information indicating that transmission of the first information is permitted in response to an external request. In a SoS (System of Systems) that controls a first server device belonging to a first industrial domain and a second server device belonging to a second industrial domain,
a processing means for determining, when a first condition is confirmed to be satisfied, a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device;
a transmitting means for transmitting, when the first server device is determined as the first system and the second server device is determined as the second system, information for permitting transmission of first information from the first server device to the second server device to the first server device, to the first server device and the second server device;
the first information includes personal information about natural persons collected by the first server device from one or more first edges;
The transmission of the first information is permitted even without the consent of the natural person if a second condition is met ;
the transmitting means transmits information for defining a use condition of the first information to at least one of the first server device and the second server device;
The terms of use of the first information are determined by the SoS and may differ from terms of use previously agreed upon by the natural person . In a SoS (System of Systems) that controls a first server device belonging to a first industrial domain and a second server device belonging to a second industrial domain,
a processing means for determining, when a first condition is confirmed to be satisfied, a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device;
a transmitting means for transmitting, when the first server device is determined as the first system and the second server device is determined as the second system, information for permitting transmission of first information from the first server device to the second server device to the first server device, to the first server device and the second server device;
the first information includes at least a portion of data collected by the first server device from one or more first edges;
the transmitting means transmits information for defining a use condition of the first information to at least one of the first server device and the second server device;
The SoS, wherein the conditions of use of the first information are determined by the SoS and may be different from the conditions of use set by an administrator of the first server device or a sovereign of the first information. In a SoS (System of Systems) that controls a first server device belonging to a first industrial domain and a second server device belonging to a second industrial domain and is capable of communicating with a third server device that permits data transmission between at least the first server device and the second server device,
a processing means for determining, when a first condition is confirmed to be satisfied, a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device;
a transmitting means for transmitting, when the first server device is determined as the first system and the second server device is determined as the second system, information to the third server device for instructing the third server device to permit transmission of first information from the first server device to the second server device,
the first information includes personal information about natural persons collected by the first server device from one or more first edges;
The transmission of the first information is permitted even without the consent of the natural person if a second condition is met ;
the transmitting means transmits information for defining a use condition of the first information to at least one of the first server device and the second server device;
The terms of use of the first information are determined by the SoS and may differ from terms of use previously agreed upon by the natural person . In a SoS (System of Systems) that controls a first server device belonging to a first industrial domain and a second server device belonging to a second industrial domain and is capable of communicating with a third server device that permits data transmission between at least the first server device and the second server device,
a processing means for determining, when a first condition is confirmed to be satisfied, a first system that will be an information provider and a second system that will be an information receiver from among a plurality of server devices including at least the first server device and the second server device;
a transmitting means for transmitting, when the first server device is determined as the first system and the second server device is determined as the second system, information to the third server device for instructing the third server device to permit transmission of first information from the first server device to the second server device,
the first information includes at least a portion of data collected by the first server device from one or more first edges;
the transmitting means transmits information for defining a use condition of the first information to at least one of the first server device and the second server device;
The SoS, wherein the conditions of use of the first information are determined by the SoS and may be different from the conditions of use set by an administrator of the first server device or a sovereign of the first information.