JP7675332B2 - Management system and management method - Google Patents

Description

The present invention relates to a management system and a management method for managing grid computing implemented in multiple computing devices installed in multiple vehicles.

Technology for applying multiple vehicles to grid computing has been proposed in the past (see, for example, Patent Document 1). The system described in Patent Document 1 is composed of a management server connected to a communication network and a computing device mounted on multiple vehicles. In this system, the management server distributes job data (computation jobs) to the multiple computing devices via the communication network and performs computation processing, thereby realizing grid computing.

The computing device can provide stable quality computing power when the vehicle is in an inoperative state (e.g., the ignition is off or the vehicle power is off). For this reason, the management server in Patent Document 1 predicts the period during which each vehicle can participate in grid computing based on the usage history of each vehicle. Then, based on this prediction, the management server selects a computing device suitable for distributing job data. In other words, the management server selects a computing device of a vehicle that is likely to be in an inoperative state throughout the computation period during which the job data is executed.

JP 2020-160661 A

However, when implementing grid computing using multiple computing devices installed in multiple non-operating vehicles, it is considered desirable for these vehicles to be located in close proximity to each other for the following reasons.

When multiple vehicles equipped with computing devices are gathered in close proximity, vehicle-to-vehicle communication can be performed during grid computing, allowing computation data to be properly transferred between the multiple computing devices. In addition, gathering multiple vehicles in close proximity in this way makes it possible to standardize the communication environment with the management server among the multiple computing devices. Furthermore, gathering multiple vehicles in close proximity and forming a vehicle group at a specific location with the multiple vehicles is effective for running multiple computing devices simultaneously for a relatively long period of time. Running multiple computing devices simultaneously in this way makes it possible to efficiently perform, for example, distributed computing (a calculation method in which individual parts of a program are executed simultaneously on multiple computing devices, and processing proceeds as a whole while each of them communicates with each other via a network).

From the above, it is believed that by gathering multiple vehicles equipped with computing devices in a short distance to perform grid computing, it is possible to effectively secure stable and highly reliable computing resources (computing capacity of the computing device) for grid computing. However, the system described in the above-mentioned Patent Document 1 was not able to gather multiple vehicles in a short distance to perform grid computing.

On the other hand, when gathering multiple vehicles in a short distance for grid computing as described above, using the parking area of a designated commercial facility (e.g., supermarket, shopping mall, stadium, theater, restaurant, accommodation facility, movie theater, store, etc.) is thought to contribute to the operation of the facility. For example, by gathering multiple vehicles in a short distance in the parking area of a facility, congestion in the parking area can be alleviated by managing (controlling) the parking positions of each vehicle. In addition, prior to managing the parking positions in this way, information such as the length of time visitors stay at the facility and the number of visitors can be obtained and this information can be used in the operation of the facility.

The present invention has been made to solve the above-mentioned problems, and aims to provide a management system and method that can secure highly reliable computing resources and contribute to the operation of a designated commercial facility by gathering multiple vehicles equipped with computing devices in close proximity in a parking area of the designated facility to perform grid computing.

In order to achieve the above object, the present invention provides a management system for managing grid computing that causes multiple arithmetic units mounted on multiple vehicles to process job data, comprising a storage device that stores information about multiple arithmetic units and/or multiple vehicles equipped with arithmetic units, and a control device configured to realize grid computing by distributing job data to each of the multiple arithmetic units and having them process the job data based on the information stored in the storage device. The control device is configured to receive a planned stay date and time, including a planned stay date and planned stay time period, designated in advance by a user of a vehicle equipped with a arithmetic unit to book a visit to a specific commercial facility having a parking area, on which the user plans to stay at the specific facility, based on the planned stay dates and times of the multiple users, set designated parking positions in which each of the multiple vehicles should be parked in the parking area so that multiple vehicles of multiple users who have the same planned stay date and overlapping planned stay time periods are located within a range in the parking area where vehicle-to-vehicle communication is possible, transmit the designated parking positions to the users of the multiple vehicles, and realize grid computing by having the arithmetic units mounted on each of the multiple vehicles process the job data when the multiple vehicles are parked in the parking area in response to the transmission of the designated parking positions.

In the present invention thus configured, the management system sets the designated parking positions of each vehicle based on the planned stay date and time designated in advance by multiple users to reserve a visit to a specified facility (in other words, reserve parking of the vehicles in the parking area of the specified facility) so that multiple vehicles with overlapping planned stay times on the same day are located within a vehicle-to-vehicle communication range in the parking area (for example, within 50 meters). In this way, grid computing is realized by the computing devices mounted on the multiple vehicles with overlapping planned stay times at the specified facility, with these vehicles parked within a vehicle-to-vehicle communication range in the parking area.
As a result, vehicle-to-vehicle communication can be performed during grid computing, and computation data can be appropriately transferred between multiple computation devices. In addition, the communication environment with the management system can be standardized among the multiple computation devices, allowing job data and the like to be appropriately transferred. Furthermore, by forming a vehicle group in a parking area of a specified facility using multiple vehicles, multiple computation devices can be operated simultaneously for a relatively long period of time. This makes it possible to appropriately realize, for example, distributed computing in grid computing. As described above, according to the present invention, when performing grid computing using multiple computation devices mounted on multiple vehicles that are not in operation, stable and highly reliable computation resources can be effectively secured.

In addition, according to the present invention, a user specifies the planned date and time of stay in advance to book a visit to a specific facility, so the number of vehicles (i.e., the number of computing devices) for each time period of the day can be determined based on the planned dates and times of stay specified in advance by multiple users. As a result, it becomes easy to estimate and adjust the amount of job data that can be calculated in a day in grid computing.

In addition, according to the present invention, by gathering multiple vehicles in a short distance (within a range where vehicle-to-vehicle communication is possible) in a parking area of a specified facility for grid computing, it is possible to contribute to the operation of the facility. For example, by managing (controlling) the parking positions of each vehicle in order to gather multiple vehicles in a short distance in a parking area, congestion in the parking area can be alleviated. Furthermore, by grasping information such as the length of time visitors (users) stay at the facility and the number of visitors before managing the parking positions in this way, this information can be used for the operation of the facility and management of the parking area.

In the present invention, preferably, the storage device stores a parking position table in which designated parking positions are associated with each of a plurality of stay time periods during which a user can stay at a specified facility, the designated parking positions being set so that a plurality of vehicles with overlapping stay time periods can be located within a range in a parking area where vehicle-to-vehicle communication is possible, and the control device is configured to refer to the parking position table stored in the storage device, set a designated parking position associated with a stay time period corresponding to the user's planned stay time period, and transmit this designated parking position to the user.
According to the present invention configured in this manner, by using a parking position table in which multiple designated parking positions to be set for each stay time period are predefined, it is possible to assign an appropriate designated parking position to each of multiple vehicles.

In the present invention, the parking position table preferably has designated parking positions set so that multiple vehicles with overlapping stay times are located within a range in the parking area where vehicle-to-vehicle communication is possible, and each of the multiple vehicles is located adjacent to each other in the parking area.
According to the present invention configured in this manner, a group of vehicles in which each vehicle is positioned close to each other can be formed in a parking area, thereby making it possible to obtain advertising effects from the group of vehicles formed for grid computing.

In the present invention, the control device is preferably configured to identify the number of vehicles that will have overlapping planned stay times on the day based on the planned stay date and time received by the day before the day the user visits a specified facility, estimate the amount of job data that can be calculated on the day in grid computing based on this number of vehicles, and distribute this amount of job data to multiple computing devices for processing.
In the present invention thus configured, the number of vehicles that will overlap in the planned time period of stay on the day is identified based on the planned stay date and time specified in advance by the user when reserving a visit to a specific facility. By estimating the job data amount based on the number of vehicles thus identified (i.e., the number of computing devices), it is possible to obtain an accurate job data amount.

In the present invention, the control device is preferably configured to estimate the amount of job data based on the number of vehicles obtained by subtracting from the number of identified vehicles the number of vehicles for which users are expected to cancel reservations to visit a specified facility on that day and/or the number of vehicles for which the computing device is expected to interrupt processing of the job data while it is processing the job data.
According to the present invention thus configured, even if a reservation for a facility visit is canceled or processing of job data is interrupted, the amount of job data that can be calculated reliably on that day can be found.

In the present invention, preferably, the control device is configured to pre-select a reserve user from among a plurality of users who have specified the planned date and time of stay to reserve a visit to a specified facility, and when a user cancels a reservation to visit the specified facility and/or when the computing device interrupts processing of job data while it is processing the job data, thereby distributing the job data to the computing device installed in the reserve user's vehicle and having the computing device process the job data, thereby realizing grid computing.
According to the present invention configured in this manner, even if a reservation for a facility visit is canceled or processing of job data is interrupted, grid computing can be reliably realized by redistributing the job data to the computing device of a pre-set spare user.

In another aspect, in order to achieve the above object, the present invention provides a management method for managing grid computing, by a computer, in which job data is processed by a plurality of computing devices mounted on a plurality of vehicles, the management method including: a storage step for storing information relating to the plurality of computing devices and/or the plurality of vehicles mounted with the computing devices; and a control step for realizing grid computing by distributing job data to each of the plurality of computing devices and causing them to process the job data based on the information stored in the storage step, the control step including: a step of determining whether or not a user of the vehicle mounted with the computing devices has stayed at a predetermined commercial facility having a parking area, the step being designated in advance to reserve a visit to the predetermined facility. receiving a planned stay date and time including a planned stay date and planned stay time zone for the multiple users; setting designated parking positions at which each of the multiple vehicles should be parked in the parking area based on the planned stay dates and times of the multiple users, so that multiple vehicles of multiple users who have the same planned stay date and overlapping planned stay time zones are located within a range in the parking area where vehicle-to-vehicle communication is possible, and transmitting the designated parking positions to each user of the multiple vehicles; and realizing grid computing by having a computing device mounted on each of the multiple vehicles process job data when the multiple vehicles park in the parking area in response to the transmission of the designated parking positions.
With the present invention configured in this manner, when performing grid computing using multiple computing devices installed in multiple vehicles that are not in operation, it is possible to effectively secure stable and highly reliable computational resources, and to contribute to the operation of specified facilities, etc.

The management system and management method according to the present invention allows multiple vehicles equipped with computing devices to be gathered in close proximity in a parking area of a designated commercial facility to perform grid computing, thereby securing highly reliable computing resources and contributing to the operation of the designated facility.

1 is a schematic diagram showing a configuration of a system according to an embodiment of the present invention. FIG. 1 is a conceptual diagram for explaining grid computing according to an embodiment of the present invention. 1 is a block diagram showing a configuration of a vehicle according to an embodiment of the present invention. FIG. 2 is a block diagram showing a configuration of a user terminal according to an embodiment of the present invention. FIG. 2 is a block diagram showing a configuration of a client server according to an embodiment of the present invention. 2 is a block diagram showing a configuration of a facility server according to an embodiment of the present invention. FIG. 2 is a block diagram showing a configuration of a management server according to an embodiment of the present invention. FIG. 5 is a flowchart showing a job reception process according to an embodiment of the present invention. FIG. 4 is a schematic diagram showing an image of a job reception screen according to an embodiment of the present invention. 4 is a flowchart showing a parking position designation process according to an embodiment of the present invention. 1 shows an example of an input screen (reservation screen) for inputting planned stay dates and times according to an embodiment of the present invention. 1 is a table illustrating an example of a designated parking location assignment according to an embodiment of the present invention. 1 illustrates an example of a parking layout according to an embodiment of the present invention. 13 shows an example of a designated parking position notification screen according to an embodiment of the present invention. 4 is a flowchart illustrating a grid computing process according to an embodiment of the present invention.

The following describes a management system and a management method according to an embodiment of the present invention with reference to the attached drawings.

[system]
1 illustrates an example of the configuration of a system 1 according to the present embodiment. The system 1 includes a plurality of vehicles 10, a plurality of user terminals 20, a client server 30, a facility server 40, and a management server 50. These components are capable of communicating with each other via a communication network 5. Each of the plurality of vehicles 10 is equipped with a computing device 105. Note that the system 1 may be provided with a plurality of client servers 30. Similarly, the system 1 may be provided with a plurality of facility servers 40.
The system 1 corresponds to an example of a "management system" in the present invention. In particular, in this embodiment, the facility server 40 and the management server 50 function as the "management system" in the present invention, and are entities that execute the "management method" in the present invention.

As shown in FIG. 2, in the system 1 of this embodiment, grid computing is configured with a plurality of computing devices 105, and grid computing processing is performed in which an available computing device 105 among the plurality of computing devices 105 processes job data.

When the vehicle 10 requires the computing power of the arithmetic device 105, the arithmetic device 105 enters an operating state, and the computing power of the arithmetic device 105 is utilized. For example, when the vehicle 10 is traveling, the computing power of the arithmetic device 105 is required for the traveling control of the vehicle 10, and the arithmetic device 105 enters an operating state.

On the other hand, when the computing power of the arithmetic device 105 is no longer needed in the vehicle 10, the arithmetic device 105 is stopped, and the computing power of the arithmetic device 105 is no longer used. For example, when the vehicle 10 is stopped and the power supply of the vehicle 10 is turned off, the computing power of the arithmetic device 105 is no longer needed, and the arithmetic device 105 is stopped.

Here, when the computing power of the computing device 105 is not required in the vehicle 10, the computing power of the computing device 105 can be provided for grid computing processing, thereby making it possible to effectively utilize the computing power of the computing device 105.

[vehicle]
The vehicle 10 is owned by a user. The user drives the vehicle 10. In this example, the vehicle 10 is a four-wheeled automobile. The vehicle 10 is also equipped with a battery (not shown). Power from the battery is supplied to on-board devices such as the computing device 105. Examples of such a vehicle 10 include an electric vehicle and a plug-in hybrid vehicle.

As shown in FIG. 3, the vehicle 10 includes an actuator 11, a sensor 12, an input unit 101, an output unit 102, a communication unit 103, a memory unit 104, a computing device 105, and a lighting device 110.

The actuator 11 includes a drive system actuator, a steering system actuator, a braking system actuator, etc. Examples of drive system actuators include an engine, a transmission, and a motor. An example of a braking system actuator is a brake. An example of a steering system actuator is a steering wheel.

The sensor 12 acquires various types of information used to control the vehicle 10. Examples of the sensor 12 include an exterior camera that captures images outside the vehicle, an interior camera that captures images inside the vehicle, a radar that detects objects outside the vehicle, a vehicle speed sensor, an acceleration sensor, a yaw rate sensor, an accelerator opening sensor, a steering sensor, and a brake oil pressure sensor.

The input unit 101 inputs information and data. Examples of the input unit 101 include an operation unit that is operated to input information corresponding to the operation, a camera that inputs an image showing information, and a microphone that inputs sound showing information. Examples of the operation unit include an operation button or a touch sensor of a car navigation device. The information and data input to the input unit 101 are sent to the calculation device 105. For example, in this embodiment, the input unit 101 accepts instructions from a user to provide the computing power of the calculation device 105 of the vehicle 10 for grid computing processing.

The output unit 102 outputs information and data. Examples of the output unit 102 include a display unit that outputs an image showing information, and a speaker that outputs sound showing information. An example of a display unit is the display of a car navigation device. An example of a speaker is the speaker of a car navigation device.

The communication unit 103 transmits and receives information and data. The information and data received by the communication unit 103 is sent to the calculation device 105. The lighting device 110 has exterior lamps (headlights, tail lights, brake lights, turn signals, etc.), room lamps, etc.

As described above, the computing device 105 provides its computing power to grid computing processing. Specifically, the computing device 105 processes distributed job data so as to realize grid computing. The computing device 105 is a computer having a processor, memory, etc. Examples of a processor include a CPU (Central Processing Unit), an MPU (Media Processing Unit), and a GPU (Graphics Processing Unit). The memory stores programs for operating the processor, information and data indicating the processing results of the processor, etc.

The number of processors mounted on the arithmetic device 105 may be one or more. The processor mounted on the arithmetic device 105 may be only one of the MPU, CPU, and GPU, or may be two or more of the MPU, CPU, and GPU. In one example, the arithmetic device 105 is configured with one or more ECUs (Electronic Control Units) and controls each part of the vehicle 10. In this example, the arithmetic device 105 controls the actuator 11 and the lighting device 110 in response to various information obtained by the sensor 12, in addition to processing job data for the above-mentioned grid computing. In another example, the arithmetic device 105 may be a computer different from such an ECU (i.e., separate from the ECU). In this example, the arithmetic device 105 mainly processes job data for grid computing without controlling each part of the vehicle 10.

The storage unit 104 stores information and data. In this example, the storage unit 104 stores vehicle information D11, vehicle state information D12, driving history information D13, computing device information D14, and operation history information D15.

Vehicle information D11 is information related to vehicle 10. For example, vehicle information D11 includes a vehicle ID set for vehicle 10, vehicle performance information indicating the performance of the vehicle, and the address registered for vehicle 10. The vehicle ID is an example of vehicle identification information that identifies vehicle 10. The user ID is an example of user identification information that identifies a user.

The vehicle status information D12 indicates the status of the vehicle 10. For example, the vehicle status information D12 includes vehicle position information, vehicle communication information, vehicle power information, vehicle battery remaining information, vehicle charging information, and the like. The vehicle position information indicates the position (latitude and longitude) of the vehicle 10. For example, the vehicle position information can be acquired by a GPS (Global Positioning System). The vehicle communication information indicates the communication state of the vehicle 10. The vehicle power information indicates the state of the power supply of the vehicle 10. For example, the vehicle power information indicates whether the ignition power supply is on or off, whether the accessory power supply is on or off, and the like. The vehicle battery remaining information indicates the remaining charge of a battery (not shown) installed in the vehicle 10. The vehicle charging information indicates whether the vehicle 10 is being charged in a charging facility (not shown).

The driving history information D13 is information that indicates the driving history of the vehicle 10. For example, the driving history information D13 indicates the position of the vehicle 10 in association with the time. The driving history information D13 may also include information such as the guide route and destination set in the navigation (route guidance) of the vehicle 10.

The arithmetic device information D14 is information related to the arithmetic device 105. For example, the arithmetic device information D14 includes an arithmetic device ID set in the arithmetic device 105, a vehicle ID set in the vehicle 10 in which the arithmetic device 105 is mounted, arithmetic device performance information indicating the performance of the arithmetic device 105, and the like. The arithmetic device ID is an example of arithmetic device identification information for identifying the arithmetic device 105. The performance of the arithmetic device 105 indicated in the arithmetic device performance information includes a computing capacity indicating the computing capacity (specifically, the maximum computing capacity) of the arithmetic device 105, the ratio of the CPU and GPU in the arithmetic device 105, and the like. The computing capacity of the arithmetic device 105 is the amount of data that the arithmetic device 105 can calculate per unit time.

The operation history information D15 is information that indicates the operation history of the computing device 105. For example, the operation history information D15 indicates the utilization rate of the computing capacity of the computing device 105 in association with time.

[User terminal]
The user terminal 20 is owned by a user. The user operates the user terminal 20 to use various functions. The user can also carry the user terminal 20. Examples of such user terminals 20 include smartphones, tablets, and notebook personal computers.

As shown in FIG. 4, the user terminal 20 includes an input unit 201, an output unit 202, a communication unit 203, a memory unit 204, and a control unit 205.

The input unit 201 inputs information and data. Examples of the input unit 201 include an operation unit that is operated to input information corresponding to the operation, a camera that inputs an image showing information, and a microphone that inputs sound showing information. Examples of the operation unit include an operation button and a touch sensor. The information input to the input unit 201 is sent to the arithmetic device 105. For example, in this embodiment, the input unit 201 accepts instructions from a user to provide the computing power of the arithmetic device 105 of the vehicle 10 for grid computing processing.

The output unit 202 outputs information and data. Examples of the output unit 202 include a display unit that outputs an image representing information, and a speaker that outputs sound representing information. The communication unit 203 transmits and receives information and data. Information and data received by the communication unit 303 are sent to the control unit 205.

The control unit 205 controls each part of the user terminal 20. The control unit 205 has a processor, a memory, etc. The memory stores programs for operating the processor, information and data indicating the processing results of the processor, etc.

The storage unit 204 stores information and data. In this example, the storage unit 204 stores terminal information D21, terminal status information D22, and schedule information D23.

The terminal information D21 is information related to the user terminal 20. For example, the terminal information D21 includes a user terminal ID set in the user terminal 20, user terminal performance information indicating the performance of the user terminal 20, and the like. The user terminal ID is an example of user terminal identification information that identifies the user terminal 20.

The terminal status information D22 is information indicating the status of the user terminal 20. The terminal status information D22 includes user terminal position information indicating the position of the user terminal 20, user terminal communication status information indicating the communication status of the user terminal 20, etc.

Schedule information D23 indicates the behavior history and planned behavior of the user who owns the user terminal 20. For example, schedule information D23 indicates the user's location in association with the period of stay (or planned period of stay). Note that schedule information D23 can be acquired by a schedule function installed in the user terminal 20. Specifically, when a user uses the schedule function to input his or her own behavior history and planned behavior into the user terminal 20, schedule information D23 indicating the user's behavior history and planned behavior is obtained.

[Client Server]
The client server 30 is owned by a client. The client requests the calculation of job data. Examples of such clients include companies, research institutes, and educational institutions.

As shown in FIG. 5, the client server 30 includes an input unit 301, an output unit 302, a communication unit 303, a memory unit 304, and a control unit 305.

The input unit 301 inputs information and data. Examples of the input unit 301 include an operation unit that is operated to input information corresponding to the operation, a camera that inputs an image showing information, and a microphone that inputs sound showing information. Examples of the operation unit include an operation button, a touch sensor, a keyboard, and a mouse. The information and data input to the input unit 301 is sent to the control unit 305.

The output unit 302 outputs information and data. Examples of the output unit 302 include a display unit that outputs an image representing information, and a speaker that outputs sound representing information. The communication unit 303 transmits and receives information and data. The information and data received by the communication unit 303 are sent to the control unit 305.

The control unit 305 controls each part of the client server 30. The control unit 305 has a processor, a memory, etc. The memory stores programs for operating the processor, information and data indicating the processing results of the processor, etc.

The storage unit 304 stores information and data. In this example, the storage unit 304 stores client information D31 and job data D1.

Client information D31 is information about a client. Client information D31 includes a client ID set for the client, a client server ID set for the client server 30 owned by the client, a person in charge's name, address, telephone number, etc. The client ID is an example of client identification information that identifies the client. The client server ID is an example of client server identification information that identifies the client server 30.

Job data D1 is data corresponding to a job, and is data that is processed to execute the job. Job data D1 can be classified by calculation type. Examples of calculation types include CPU-based calculation type and GPU-based calculation type. Job data D1 of CPU-based calculation type tends to require complex calculations with many conditional branches, such as simulation calculations. Job data D1 of GPU-based calculation type tends to require a huge amount of simple calculations, such as image processing and machine learning.

Job data D1 can also be classified according to processing conditions. Examples of processing conditions include processing conditions that require constant communication and processing conditions that do not require constant communication. Job data D1 with processing conditions that require constant communication requires that the computing device 105 is always able to communicate in grid computing processing. Job data D1 with processing conditions that do not require constant communication does not require that the computing device 105 is always able to communicate in grid computing processing.

The storage unit 304 may store job information related to a job. The job information includes job name information indicating the name of the job, job content information explaining the content of the job, job data information related to the job data corresponding to the job, job delivery date information indicating the delivery date of the job, etc. The job data information indicates the calculation type, processing conditions, required calculation capacity, etc. of the job data.

[Facility server]
The facility server 40 is owned by a facility that the user visits. Examples of such facilities include supermarkets, shopping malls, stadiums, theaters, restaurants, accommodation facilities, movie theaters, retail stores, etc. The user may be allowed to make a reservation to visit the facility.

As shown in FIG. 6, the facility server 40 includes an input unit 401, an output unit 402, a communication unit 403, a memory unit 404, and a control unit 405. The configurations of the input unit 401, output unit 402, communication unit 403, memory unit 404, and control unit 405 of the facility server 40 are similar to the configurations of the input unit 301, output unit 302, communication unit 303, memory unit 304, and control unit 305 of the client server 30.

In this example, the memory unit 404 stores facility information D41 and facility usage information D42. The facility information D41 is information related to the facility. The facility information D41 includes a facility ID set for the facility, a facility server ID set for the facility server 40 owned by the facility, facility location information indicating the location (latitude and longitude) of the facility, information on the company that operates (or manages) the facility, the name of the person in charge, an address, a telephone number, etc. The facility ID is an example of facility identification information that identifies the facility. The facility server ID is an example of facility server identification information that identifies the facility server 40.

In addition, in this embodiment, the facility information D41 also includes parking position information regarding multiple parking positions in a parking area provided in the facility. This parking position information includes a map (defined by latitude and longitude, for example) showing the multiple parking positions, and parking numbers assigned to each of the multiple parking positions. Note that the multiple parking positions are defined in a predetermined area in a parking area prepared in advance for parking vehicles 10 that realize grid computing, for example. Furthermore, in this embodiment, the facility information D41 also includes a parking position table in which the parking positions (designated parking positions) at which each of the multiple vehicles 10 should be parked in the parking area are associated with each of multiple candidate stay time periods (defined by entry and exit times) during which a user can stay in the facility, so that the multiple vehicles 10 with overlapping stay time periods are located within a range in the parking area where vehicle-to-vehicle communication is possible.

Facility usage information D42 indicates the usage status (usage history and planned usage) of the facility. In this embodiment, facility usage information D42 is information that indicates in association with a user (specifically, a user ID) visiting the facility and information about the user's planned stay at the facility. In this embodiment, this planned stay information is information about the planned stay date and time, including the planned stay date and planned stay time period (defined by the planned entry time and planned exit time) on which the user plans to stay at the facility, which are designated in advance by the user to book a visit to the facility.

[Administration Server]
The management server 50 manages the operation of the system 1 in which grid computing is implemented. The management server 50 is owned by the operator who operates the system 1.

7, the management server 50 includes an input unit 501, an output unit 502, a communication unit 503, a storage unit 504, and a control unit 505. The configurations of the input unit 501, the output unit 502, the communication unit 503, the storage unit 504, and the control unit 505 of the management server 50 are the same as the configurations of the input unit 301, the output unit 302, the communication unit 303, the storage unit 304, and the control unit 305 of the client server 30.
In addition, the memory unit 504 of the management server 50, together with the memory unit 404 of the facility server 40 described above, functions as an example of a "memory device" in the present invention, and the control unit 505 of the management server 50, together with the control unit 405 of the facility server 40 described above, functions as an example of a "control device" in the present invention.

In this example, the memory unit 504 stores a user table D51, a computing device table D52, a client table D53, a job table D54, a resource table D55, a matching table D56, job data D1, and calculation result data D2.

The user table D51 is a table for managing users. For each user, the user table D51 registers a user ID set for that user, a vehicle ID set for the vehicle 10 owned by that user, a computing device ID set for the computing device 105 owned by that user, a user terminal ID set for the user terminal 20 owned by that user, and the like.

The arithmetic device table D52 is a table for managing the arithmetic devices 105. In the arithmetic device table D52, for each arithmetic device 105, a arithmetic device ID set in that arithmetic device 105, a user ID set for the user who owns that arithmetic device 105, a vehicle ID set in the vehicle 10 in which that arithmetic device 105 is installed, etc. are registered.

The arithmetic unit table D52 also registers, for each arithmetic unit 105, the performance of that arithmetic unit 105 (such as computing capacity and the ratio of CPU to GPU), the operating status of that arithmetic unit 105 (operating history and operating schedule), and the like. In other words, the arithmetic unit table D52 includes operating status information D5 indicating the operating status of each of the multiple arithmetic units 105, and performance information D6 indicating the performance of each of the multiple arithmetic units 105. The performance information D6 includes computing capacity information D7 indicating the computing capacity of each of the multiple arithmetic units 105.

The client table D53 is a table for managing clients. For each client, the client table D53 registers the client ID set for that client, the client server ID set for the client server 30 owned by the client, the name, address, and telephone number of the client's contact person, etc.

The job table D54 is a table for managing jobs requested by clients. For each job, the job table D54 registers the reception number set for that job, the client ID set for the client who requested the job, the name and content of the job, and so on. In addition, for each job, the job table D54 registers the calculation type and processing conditions of the job data corresponding to that job, the required computing power that is the computing power required to calculate the job data, the delivery date set for that job, and so on.

The resource table D55 is a table for managing the computing power in grid computing processing. Specifically, the resource table D55 registers, for each computing device 105, the computing device ID set for that computing device 105, the predicted results of the temporal change in the computing power available for the grid computing processing of that computing device 105, and the like. The matching table D56 registers, for each job, the reception number set for that job, the job data corresponding to that job, the computing device ID set for the computing device 105 assigned to that job data, and the like.

The job data D1 stored in the memory unit 504 is job data D1 accepted by the job acceptance process described below. The calculation result data D2 stored in the memory unit 504 is job data calculated by the grid computing process described below, and indicates the results of the calculation.

Next, the updating of the user table D51 will be described. The user table D51 is updated by the control unit 505 of the management server 50. For example, when a new user joins the system 1, the control unit 505 updates the user table D51 by registering information related to the new user in the user table D51. Specifically, the control unit 505 sets a new user ID for the new user, associates the "user ID" set for the new user with the "vehicle ID" set for the vehicle 10 owned by the user, the "computing device ID" set for the computing device 105 mounted on the vehicle 10, and the "user terminal ID" set for the user terminal 20 owned by the new user, and registers them in the user table D51.

In addition, by communication between the vehicle 10 owned by the new user and the management server 50, it is possible to obtain a "vehicle ID" and a "computing device ID" related to the new user. In addition, by communication between the user terminal 20 owned by the new user and the management server 50, it is possible to obtain a "user terminal ID" related to the new user.

[Update the arithmetic unit table]
Next, the update of the arithmetic device table D52 will be described. The arithmetic device table D52 is updated by the control unit 505 of the management server 50. For example, when a new arithmetic device 105 joins the system 1, the control unit 505 updates the arithmetic device table D52 by registering information related to the new arithmetic device 105 in the arithmetic device table D52. Specifically, the control unit 505 associates the "arithmetic device ID" set in the new arithmetic device 105, the "user ID" set in the user who owns the arithmetic device 105, the "vehicle ID" set in the vehicle 10 in which the arithmetic device 105 is mounted, and the "performance" and "operation status" of the arithmetic device 105, and registers them in the arithmetic device table D52.

In addition, by communication between the vehicle 10 equipped with the new arithmetic device 105 and the management server 50, it is possible to obtain the "arithmetic device ID", "vehicle ID", "performance", and "operation status" related to the new arithmetic device 105. In addition, by referring to the user table D51, it is possible to obtain the "user ID" related to the new arithmetic device 105.

[Periodic update of the calculation unit table]
In addition, the “operation status” of the arithmetic device 105 registered in the arithmetic device table D52 is periodically updated. In other words, the operation status information D5 included in the arithmetic device table D52 is periodically updated. This periodic update is performed by the control unit 505 of the management server 50.

(First update process)
For example, the "operation status" of the arithmetic device 105 in the arithmetic device table D52 (in other words, the operation status information D5) may be periodically updated based on the "operation history information D15" of the vehicle 10. Specifically, the control unit 505 may execute the following first update process for each arithmetic device 105 registered in the arithmetic device table D52.

In the first update process, the control unit 505 requests the vehicle 10 equipped with the calculation device 105 to access the "operation history information D15". In response to the request, the calculation device 105 of the vehicle 10 allows access to the "operation history information D15". The control unit 505 updates the "operation history", which is the past operation status, of the "operation status" of the calculation device 105 registered in the calculation device table D52, based on the operation history of the calculation device 105 indicated in the operation history information D15.

(Second update process)
Furthermore, the "operation status" of the arithmetic device 105 in the arithmetic device table D52 (in other words, the operation status information D5) may be periodically updated based on the "travel history information D13" of the vehicle 10. Specifically, the control unit 505 may execute the following second update process for each arithmetic device 105 registered in the arithmetic device table D52.

In the second update process, the control unit 505 requests the vehicle 10 equipped with the calculation device 105 to access the "driving history information D13". In response to the request, the calculation device 105 of the vehicle 10 allows access to the "driving history information D13". The control unit 505 estimates the operation history of the calculation device 105 based on the driving history of the vehicle 10 indicated in the driving history information D13. Next, the control unit 505 updates the "operation history", which is the past operation status, of the "operation status" of the calculation device 105 registered in the calculation device table D52 based on the estimated operation history of the calculation device 105.

(Third Update Process)
Furthermore, the "operation status" of the arithmetic device 105 in the arithmetic device table D52 (in other words, the operation status information D5) may be periodically updated based on the "schedule information D23" of the user terminal 20. Specifically, the control unit 505 may execute the following third update process for each arithmetic device 105 registered in the arithmetic device table D52.

In the third update process, the control unit 505 requests the user terminal 20 owned by the user who owns the arithmetic device 105 to access "schedule information D23". In response to the request, the control unit 205 of the user terminal 20 allows access to "schedule information D23". The control unit 505 detects the behavioral status related to the vehicle 10 in which the arithmetic device 105 is mounted from the behavioral status of the user (behavioral history and behavioral plan) shown in the schedule information D23. For example, from the behavioral history, which is a past behavioral status among the user's behavioral status, a behavioral history in which the user has boarded the vehicle 10 is detected, and from the behavioral plan, which is a future behavioral status among the user's behavioral status, a behavioral plan in which the user plans to board the vehicle 10 is detected.

Next, the control unit 505 estimates the driving status (driving history and driving schedule) of the vehicle 10 based on the detected behavioral status of the user. Next, the control unit 505 estimates the operating status (operating history and operating schedule) of the calculation device 105 based on the estimated driving status of the vehicle 10. Then, the control unit 505 updates the "operating status" of the calculation device 105 registered in the calculation device table D52 based on the estimated operating status of the calculation device 105.

(Fourth update process)
Furthermore, the "operation status" of the calculation device 105 in the calculation device table D52 (in other words, the operation status information D5) may be periodically updated based on the "facility usage information D42" of the facility server 40. Specifically, the control unit 505 may execute the following fourth update process for each calculation device 105 registered in the calculation device table D52.

In the fourth update process, the control unit 505 requests the facility server 40 to access the "facility usage information D42". In response to the request, the facility server 40 permits access to the "facility usage information D42". The control unit 505 detects usage related to the vehicle 10 in which the calculation device 105 is mounted from the usage status (usage history and usage plans) of the facility indicated in the facility usage information D42. For example, from the usage history, which is the past usage status among the facility usage status, usage history in which the user boarded the vehicle 10 is detected, and from the usage plans, which are the future usage status among the facility usage status, usage plans in which the user plans to board the vehicle 10 are detected.

The control unit 505 then estimates the driving status (driving history and driving schedule) of the vehicle 10 based on the detected facility usage status. The control unit 505 then estimates the operating status (operating history and operating schedule) of the calculation device 105 based on the estimated driving status of the vehicle 10. The control unit 505 then updates the "operating status" of the calculation device 105 registered in the calculation device table D52 based on the estimated operating status of the calculation device 105.

[Update Client Table]
Next, an explanation will be given of updating the client table D53. The client table D53 is updated by the control unit 505 of the management server 50. For example, when a new client joins the system 1, the control unit 505 updates the client table D53 by registering information related to the new client in the client table D53.

Specifically, the control unit 505 sets a new client ID for the new client, associates the "client ID" set for the new client with the "client server ID" set for the client server 30 owned by the new client, and the "person in charge," "address," and "telephone number" of the new client, and registers them in the client table D53.

In addition, through communication between the client server 30 and the management server 50, it is possible to obtain the "client server ID," "contact person," "address," and "telephone number" for a new client.

[Processing according to this embodiment]
Next, the processes performed in this embodiment will be specifically described. In this embodiment, a job reception process, a parking position designation process, and a grid computing process are mainly performed.

(Job acceptance processing)
8, a job reception process performed by the control unit 505 of the management server 50 in this embodiment will be described. In the job reception process, job data D1 for which a calculation is requested by a client is received. For example, the control unit 505 of the management server 50 performs the following process each time a calculation of the job data D1 is requested by a client.

First, in step S1, the management server 50 accepts a job request from a client. Specifically, the client server 30 responds to an operation by a person in charge of the client and sends a job request application to the management server 50. In response to the application, the control unit 505 of the management server 50 performs the following processing.

The control unit 505 requests the client server 30 to send information required to accept the job (specifically, client information about the client requesting the job and job information about the job). In this example, the control unit 505 sends image data of the job acceptance screen to the client server 30. The control unit 305 of the client server 30 reproduces the image of the job acceptance screen from the image data, and outputs (displays) the image on the output unit 302 (display unit).

As shown in FIG. 9, the job reception screen is a screen for inputting information required to accept a job. The job reception screen is provided with a client name input field R101 for inputting the client name, a person in charge name input field R102 for inputting the client's person in charge name, an address input field R104 for inputting the client's address, a job name input field R111 for inputting the name of the job, a job content input field R112 for inputting a description of the job content, a calculation type input field R113 for inputting the calculation type of the job data corresponding to the job, a processing condition input field R114 for inputting the processing conditions of the job data, a required calculation capacity input field R115 for inputting the required calculation capacity of the job data, a delivery date input field R116 for inputting the delivery date of the job, and a registration button B100.

The client staff operates the input unit 301 (operation unit) of the client server 30 to input the necessary information into the job reception screen. This inputs client information about the client requesting the job and job information about the job. Then, once input of this information is complete, the client staff operates the input unit 301 (operation unit) of the client server 30 to press the registration button B100 on the job reception screen. When the registration button B100 is pressed, the control unit 305 of the client server 30 sends the information (client information and job information) input into the job reception screen to the management server 50. The control unit 505 of the management server 50 receives the client information and job information.

Next, the control unit 505 requests the client server 30 to send job data D1 corresponding to the job. In response to the request, the control unit 305 of the client server 30 sends job data D1 corresponding to the job to the management server 50. The control unit 505 of the management server 50 receives the job data D1.

Next, in step S2, the control unit 505 of the management server 50 analyzes the job data D1 received in step S1. Specifically, the control unit 505 analyzes the calculation type, processing conditions, required calculation capacity, etc. of the job data D1. Then, the control unit 505 corrects the job information received in step S1 based on the results of the analysis of the job data D1. Note that if the job information received in step S1 is sufficiently reliable, the processing of step S2 may be omitted.

Next, in step S3, the control unit 505 of the management server 50 associates the client information received in step S1 with the job information corrected as necessary in step S2 (or the job information received in step S1) and registers them in the job table D54. The control unit 505 also stores the job data D1 received in step S1 in the memory unit 504.

(Parking position designation process)
Next, the parking position designation process according to this embodiment will be described with reference to Fig. 10 to Fig. 14. Fig. 10 is a flowchart showing the parking position designation process according to this embodiment, Fig. 11 shows an example of an input screen (reservation screen) for the planned stay date and time according to this embodiment, Fig. 12 is a table showing an example of the allocation of designated parking positions according to this embodiment, Fig. 13 shows an example of a parking layout according to this embodiment, and Fig. 14 shows an example of a notification screen of the designated parking position according to this embodiment.

The parking position designation process according to this embodiment is executed by the control unit 505 of the management server 50 and the control unit 405 of the facility server 40. To give an overview of this parking position designation process, the control unit 405 of the facility server 40 sets in advance a parking position table in which a designated parking position is associated with each of a plurality of candidate stay time periods during which the vehicle 10 can stay at a specific facility in which the facility server 40 is installed, and stores this parking position table in the storage unit 404. In addition, the control unit 405 of the facility server 40 receives a planned stay date and time including a planned stay time period, which is previously designated by a user of the vehicle 10 equipped with the computing device 105 to reserve a visit to a specific facility (in other words, to reserve parking the vehicle 10 in the parking area of the specific facility), and refers to the parking position table stored in the storage unit 404 to set a designated parking position associated with a stay time period corresponding to the user's planned stay time period, and transmits this designated parking position to the user.

On the other hand, the control unit 505 of the management server 50 identifies the number of vehicles 10 whose planned stay times overlap on the day based on the planned stay dates and times received by the day before the day the user visits the specified facility, and estimates the amount of job data (meaning the amount of original job data before being assigned to each computing device 105; the same applies below) that can be calculated on the day in grid computing based on this number of vehicles 10. In addition, when a user cancels a reservation for a visit on the planned stay date and time, the control unit 505 of the management server 50 adds a pre-set spare user from among multiple users who specified the same planned stay date and time as a user for distributing and processing the job data D1 in place of the canceled user, thereby realizing grid computing. In addition, the control unit 505 of the management server 50 determines whether each of the multiple vehicles 10 whose designated parking positions have been transmitted is parked in the designated parking position, and determines whether a vehicle group of the multiple vehicles 10 is formed.

Specifically, when the parking position designation process of FIG. 10 is started, first, in step S11, the control unit 405 of the facility server 40 pre-sets a parking position table in which a designated parking position is set so that a plurality of vehicles 10 with overlapping stay times are located within a range in the parking area where vehicle-to-vehicle communication is possible (within 50 m) for each of the candidates for a plurality of stay time periods (defined by the entry time and the exit time) during which the vehicle can stay in a specified facility (see FIG. 12), and stores this parking position table in the storage unit 404 as facility information D41. In particular, the control unit 405 sets the designated parking positions in the parking position table so that a plurality of vehicles 10 with overlapping stay time periods (typically the same stay time period) are located within a range in the parking area where vehicle-to-vehicle communication is possible, and each of the plurality of vehicles 10 is located adjacent to each other in the parking area. Note that the conditions for setting the designated parking positions in the parking area are presented in advance from the management server 50 to the facility server 40.

Next, in step S12, the control unit 405 of the facility server 40 determines whether or not it has received a planned stay date and time including a planned stay date and a planned stay time period, which is specified in advance by the user of the vehicle 10 equipped with the computing device 105 to reserve a visit to a specific facility. In one example, the facility server 40 receives the planned stay date and time input by the user using the reservation site (a site managed by the facility server 40) for reserving a visit to a specific facility using the user terminal 20 and the reservation page of this reservation site. In this example, the user refers to the input screen (reservation screen) displayed on the output unit 202 as a display unit in the user terminal 20, and inputs the planned stay date and time using the input unit 201 as a touch sensor in the user terminal 20 (see FIG. 11). In the example of the input screen shown in FIG. 11, the user selects one planned stay time period (for example, "11:00 to 13:00") from multiple candidates of the planned stay time period displayed for a specific date corresponding to the planned stay date in order to reserve a visit to a movie theater (in other words, to reserve parking the vehicle 10 in the parking area of the movie theater). On this screen, a planned stay time slot marked with "◯" indicates a time slot that can be reserved, and a planned stay time slot marked with "X" indicates a time slot that cannot be reserved. The control unit 405 associates the received planned stay date and time with the user ID (which may include the vehicle ID) and stores the same in the storage unit 404 as facility usage information D42. In another example, the facility server 40 may receive a planned stay date and time that the user inputs on a PC or vehicle 10. If the control unit 405 of the facility server 40 determines that the planned stay date and time has been received (step S12: Yes), it proceeds to step S13, and if it determines that the planned stay date and time has not been received (step S12: No), it repeats the determination of step S12.

In step S13, the control unit 405 of the facility server 40 refers to the parking position table stored in the storage unit 404 as facility information D41 in step S11, assigns to the user a designated parking position associated with the planned stay date and time corresponding to the planned stay time included in the planned stay date and time received in step S12, and transmits this designated parking position to the user. Each time the control unit 405 receives a planned stay date and time from multiple users, it assigns the user to each designated parking position set in the parking position table, and stores the information in which the designated parking position is assigned to the user in the storage unit 404 as facility information D41 or facility use information D42. In one example, the facility server 40 transmits the designated parking position assigned to the user to the user terminal 20, and the user terminal 20 displays a notification screen of the designated parking position on the output unit 202 as a display unit (see FIG. 14). In the example of the notification screen shown in FIG. 14, in addition to the planned stay date and planned stay time, a parking number indicating the designated parking position is displayed. In another example, the facility server 40 may transmit the designated parking location to the user's PC or vehicle 10 and notify the user of the designated parking location via the PC or vehicle 10.

Now, a specific example shown in Figures 12 and 13 will be described. In this example, the control unit 405 of the facility server 40 assigns designated parking positions A1 to A7 to users a, b, d, f, g, j, and k who have the same planned stay time period (corresponding to the stay time period in the parking position table) from 11:00 to 13:00, and assigns designated parking positions B1 to B5 to users c, e, h, i, and l who have the same planned stay time period from 13:00 to 14:00 (see Figure 12). Each of these designated parking positions A1 to A7 and designated parking positions B1 to B5 is located within a range in the parking area where vehicle-to-vehicle communication is possible, and in particular, the entire positions including designated parking positions A1 to A7 and designated parking positions B1 to B5 are adjacent to each other (see Figure 13).

The control unit 405 of the facility server 40 pre-sets a spare user from among a plurality of users for each planned time period of stay (see FIG. 12). The spare user is set in this way in order to realize grid computing by the calculation device 105 mounted on the vehicle 10 of the spare user when the user cancels a reservation for a visit at the planned time period of stay or when the calculation device 105 interrupts the processing of the job data D1 at the time of the planned time period of stay. From this perspective, the control unit 405 specifies the number of spare users to be set for each planned time period of stay based on the number of vehicles 10 (in other words, the number of users) for which the user is expected to cancel a reservation for a visit at the planned time period of stay and the number of vehicles 10 (in other words, the number of users) for which the calculation device 105 is expected to interrupt the processing of the job data D1 while it is processing it. For example, the number of spare users for each planned time period of stay is specified based on the actual values obtained for each day of the week and time period for the past month (the number of vehicles 10 that canceled and the number of vehicles 10 that the calculation device 105 interrupted the processing of). In the example shown in FIG. 12, the control unit 405 sets two spare users, users j and k, for the planned stay time slot from 11:00 to 13:00, and sets one spare user, user l, for the planned stay time slot from 13:00 to 14:00. In addition, for example, the control unit 405 sets the user who made the latest reservation time (time) among multiple users who have reserved the same planned stay time slot as the spare user.

Returning to FIG. 10, in step S14, the control unit 405 of the facility server 40 associates at least the planned stay date and time and the designated parking location with a user ID (which may include a vehicle ID) and transmits them to the management server 50 in order to share with the management server 50 the planned stay date and time of the user acquired in step S12 and the designated parking location set in step S13. As a result, the management server 50 associates the received information such as the planned stay date and time and the designated parking location with the user ID and stores them in the storage unit 504. The facility server 40 also transmits the user ID (which may include a vehicle ID) of the spare user set as described above to the management server 50, and the management server 50 stores the spare user information in the storage unit 504 in association with the user ID. For example, the control unit 505 of the management server 50 stores the information received from the facility server 40 in the user table D51 of the storage unit 504.

On the other hand, in step S21, the control unit 505 of the management server 50 identifies the number of vehicles 10 whose planned stay times overlap on the day based on information about multiple planned stay times received from the facility server 40 by the day before the day the user visits the specified facility, and estimates the amount of job data that can be calculated on the day in grid computing based on this number of vehicles 10. Specifically, the control unit 505 uses the average computing power (predetermined) of a general computing device 105 to calculate the amount of job data according to the identified number of vehicles 10 (i.e., the number of computing devices 105). For example, the control unit 505 calculates the amount of job data according to the number of vehicles 10 for each of multiple planned stay times on the same day, and calculates the total amount of job data calculated for each of the multiple planned stay times as the amount of job data that can be calculated on the day.

In addition, the control unit 505 estimates the amount of job data based on the number of vehicles 10 that is obtained by subtracting from the number of vehicles 10 identified for each planned stay time period as described above the number of vehicles 10 for which users are expected to cancel their reservations for visits at the planned stay time and date on that day and the number of vehicles 10 for which the calculation device 105 is expected to interrupt the processing of the job data D1 while it is processing the job data D1. The number of vehicles 10 to be subtracted in this way is specified for each of the multiple planned stay time periods, and is basically the same as the number of reserve users described above. In other words, the number of vehicles 10 to be subtracted is set based on, for example, the actual values obtained for each day of the week and time period for the past month (the number of vehicles 10 that were canceled and the number of vehicles 10 for which the calculation device 105 interrupted the processing). In one example, when the number of vehicles 10 that have reserved a certain planned stay time slot is seven, and the ratio corresponding to the past performance value (specifically, the ratio of the number of vehicles 10 that have been canceled and the number of vehicles 10 for which the calculation device 105 has suspended processing to the total number of reserved vehicles) is 20%, the control unit 505 subtracts two from seven to use five vehicles, and estimates the amount of job data that can be calculated by these five calculation devices 105.

Next, in step S22, the control unit 505 of the management server 50 judges whether or not the position where the vehicle 10 was actually parked in the parking area of the specified facility on that day (hereinafter referred to as the "actual parking position") has been received from the vehicle 10. In this case, when the vehicle 10 is in a non-operating state (for example, a standby state such as a state where the ignition power is off or the accessory power is off) in the parking area of the specified facility, the control unit 505 of the management server 50 transmits the vehicle status information D12 (including the vehicle position information indicating the position (latitude and longitude) of the vehicle 10 as described above) to the management server 50, and the control unit 505 of the management server 50 uses the vehicle position information included in this vehicle status information D12 as the actual parking position. If the control unit 505 judges that the actual parking position has been received (step S22: Yes), it proceeds to step S23, and if it does not judge that the actual parking position has been received (step S22: No), it repeats the judgment of step S22.

In step S23, the control unit 505 of the management server 50 determines whether the vehicle 10 has been parked in the designated parking position set by the facility server 40 based on the designated parking position received from the facility server 40 and the actual parking position received from the vehicle 10. Specifically, the control unit 505 determines that the vehicle 10 has been parked in the designated parking position when the actual parking position matches the designated parking position. In addition, in determining whether the vehicle 10 has been parked in the designated parking position, instead of comparing the actual parking position with the designated parking position in this manner, in another example, the control unit 505 may make this determination based on the result of reading a marker (that can identify the parking position) that is provided in advance at each parking position in the parking area using a camera or the like of the vehicle 10. In yet another example, a sensor such as a camera may be provided in the parking area, and the control unit 405 of the facility server 40 may make this determination by acquiring the license plate number or the like of the parked vehicle 10.

In step S24, the control unit 505 of the management server 50 determines whether the user has canceled the reservation for the visit at the planned stay date and time. For example, the user accesses the above-mentioned reservation site with the user terminal 20 and performs an operation input to cancel the reservation for the planned stay date and time using the reservation page of this reservation site. Then, the facility server 40 transmits information related to the reservation cancellation thus obtained via the reservation site (including the user ID of the user who canceled the reservation) to the management server 50, and when the management server 50 receives this information, it determines that the user has canceled the reservation (step S24: Yes). In this case, the control unit 505 of the management server 50 proceeds to step S25 and performs a process to add a spare user. That is, the control unit 505 sets the calculation device 105 of the vehicle 10 of the spare user as a target for realizing grid computing by distributing and processing the job data D1 instead of the user who canceled the reservation. In this case, when performing the process of step S25, the control unit 505 uses the information of the spare user (particularly the user ID of the spare user) stored in the user table D51 of the storage unit 504 as described above.

Next, in step S26, the control unit 505 determines whether a vehicle group has been formed by multiple vehicles 10 that have reserved the same planned stay time period parking in their designated parking positions, based on the parking position determination result in step S23. As a result, if the control unit 505 determines that a vehicle group has been formed (step S26: Yes), it ends the processing flow of FIG. 10. On the other hand, if the control unit 505 does not determine that a vehicle group has been formed (step S26: No), it returns to step S21. In this case, the control unit 505 repeats the processing of steps S21 to S26 until a vehicle group is formed.

The order of steps S22 and S23 and steps S24 and S25 may be reversed. That is, in the above embodiment, the decision to cancel the reservation is made after the decision to determine the parking location, but in other examples, the decision to cancel the reservation may be made after the decision to determine the parking location. In still other examples, these decisions may be made in parallel.

(Grid Computing Processing)
Next, the grid computing process performed by the control unit 505 of the management server 50 in this embodiment will be described with reference to Fig. 15. In the grid computing process, the control unit 505 of the management server 50 causes the arithmetic devices 105 mounted on each of the multiple vehicles 10 that form a vehicle group as a result of the parking position designation process in Fig. 10 to process the job data D1. For example, the control unit 505 performs the following processes after the job acceptance process and the parking position designation process.

First, in step S31, the control unit 505 of the management server 50 predicts the computing capacity of the computing device 105 mounted on each of the multiple vehicles 10 constituting the vehicle group. Specifically, the control unit 505 predicts the computing capacity (calculation amount), calculation type, and computable schedule as the computing capacity of each computing device 105 of the vehicle group based on the computing device table D52 stored in the storage unit 504 of the management server 50 and the vehicle state information D12 received from the vehicle 10. The calculation type is the ratio of CPU and GPU included in the computing device table D52, and the computable schedule is specified by the computable time based on the battery state according to the vehicle battery remaining amount information and vehicle charging information included in the vehicle state information D12. Then, the control unit 505 registers the information on the computing capacity of the entire vehicle group as computing grid information based on the computing capacity of each of the multiple computing devices 105 predicted in this way.

Next, in step S32, the control unit 505 assigns the job data D1 to be subjected to grid computing processing, which was accepted in the above job acceptance process (FIG. 8), to each of the computing devices 105 constituting the grid of the vehicle group, based on the computing capacity of each computing device 105 predicted in step S31. The job data D1 thus assigned to each computing device 105 is job data corresponding to the same job. Then, in step S33, the control unit 505 distributes (transmits) a portion of the job data D1 to each computing device 105 based on the assignment result of step S32.

After this, the arithmetic device 105 of each of the vehicles 10 constituting the vehicle group processes a part of the distributed job data D1. At this time, in a preferred example, the control unit 505 of the management server 50 may transmit a request to the vehicle 10 to turn on the lighting device 110 of the vehicle 10 equipped with the arithmetic device 105 performing grid computing in the parking area. Then, in response to this request, each of the vehicles 10 constituting the vehicle group may turn on the lighting device 110 in a predetermined manner so that it is clear that a process related to grid computing is currently being performed. For example, each of the vehicles 10 (vehicle group) parked adjacent to each other in a certain parking area turns on the lighting device 110 as an exterior lamp. In this case, it is preferable to turn on the exterior lamp in a specific color (such as green). In another example, the room lamp may be turned on in a specific color (such as blue) instead of the exterior lamp. In this way, by turning on the lighting devices 110 of the multiple vehicles 10, an advertising effect can be obtained by the vehicle group formed for grid computing.

Next, when each of the computing devices 105 completes the calculation of the data (part of the job data D1) sent to that computing device 105, it sends the partial calculation result data obtained by that calculation to the management server 50. In step S34, the control unit 505 of the management server 50 receives the partial calculation result data sent from the computing device 105 and stores the partial calculation result data in the memory unit 504.

Next, in step S35, the control unit 505 determines whether the arithmetic device 105 has interrupted the processing of a part of the distributed job data D1 while the arithmetic device 105 was processing the part, that is, whether any user has left while the arithmetic device 105 was calculating a part of the job data D1. For example, when the vehicle 10 on which the arithmetic device 105 is mounted changes from a non-operating state to an operating state (in one example, a state in which the ignition power is turned on) while the arithmetic device 105 is calculating a part of the job data D1, the control unit 505 determines that any user has left in the middle of the calculation because the arithmetic device 105 interrupts (ends) the processing. In this case, the control unit 505 makes such a determination based on the vehicle state information D12 transmitted from the vehicle 10. If the control unit 505 determines that any user has left in the middle of the calculation (step S35: Yes), it proceeds to step S36, and if the control unit 505 does not determine that any user has left in the middle of the calculation (step S35: No), it proceeds to step S37.

In step S36, the control unit 505 distributes the job data D1 that was distributed to the computing device 105 of the user who left midway to the computing device 105 of the spare user set as described above. In this way, a part of the job data D1 is newly distributed to the computing device 105 of the spare user for processing, thereby realizing grid computing. In this case, the control unit 505 refers to the spare user information stored in the user table D51 of the storage unit 504, and determines the spare user to which the job data D1 is to be newly distributed (specifically, the spare user who has booked the same planned stay date and time as the user who left midway).

Next, in step S37, the control unit 505 determines whether all of the calculation devices 105 to which the job data D1 was distributed in step S33 have completed calculations. If the control unit 505 determines that all of the calculation devices 105 have completed calculations (step S37: Yes), the control unit 505 proceeds to step S38, and if the control unit 505 does not determine that all of the calculation devices 105 have completed calculations (step S37: No), the control unit 505 returns to step S34.

Next, in step S38, the control unit 505 generates calculation result data D2 (calculation result data D2 indicating the result of the calculation of job data D1) corresponding to the job data D1 that is the target of the grid computing process by combining the partial calculation result data stored in the storage unit 504. Then, the control unit 505 transmits the calculation result data D2 corresponding to the job data D1 that is the target of the grid computing process to the client server 30 of the client that requested the calculation of the job data D1.

Next, in step S39, the control unit 505 calculates a reward to be given by the operator of the system 1 to the user who provided the computing power of the computing device 105 to the grid computing process. Examples of rewards include points, virtual currency, and product discount benefits that can be used in the system 1. Specifically, the control unit 505 determines a reward to be given to the user according to the amount of calculation that the computing device 105 provided to the grid computing process. In this case, the control unit 505 gives a larger reward to the user the greater the amount of calculation provided to the grid computing process.

Next, in step S40, the control unit 505 performs a process for granting the reward calculated in step S39 to the user. Examples of the process for granting the reward include a process for registering in the user table D51 a "user ID" set for the user and "points" (or virtual currency) available in the system 1 in association with each other, and a process for transmitting information indicating a product discount benefit to the user terminal 20 owned by the user. The information indicating the reward may be registered for each job in the job table D54. A reward may be granted by the client to a user who has provided the computing capacity of the computing device 105 to the grid computing process. For example, the control unit 305 of the client server 30 may execute a process for granting a reward to a user who has provided the computing capacity of the computing device 105 to the grid computing process. In addition, if the computing device 105 of the spare user processes part of the job data D1 because the user has left in the middle of the process (step S35: Yes → step S36), the reward for the user who has left may be granted to the spare user.

[Action and Effects]
Next, the operation and effect of this embodiment will be described. In this embodiment, the control unit 405 of the facility server 40 receives a planned stay date and time including a planned stay date and a planned stay time period for staying at a facility, which is designated in advance by a user of the vehicle 10 equipped with the arithmetic device 105 to book a visit to a specific facility, and sets a designated parking position where each of the multiple vehicles 10 should be parked in the parking area based on the planned stay dates and times of the multiple users so that the multiple vehicles 10 having the same planned stay date and overlapping planned stay time periods are located within a range (for example, within 50 m) in the parking area where vehicle-to-vehicle communication is possible, and transmits the designated parking position to each user of the multiple vehicles 10. On the other hand, when the multiple vehicles 10 are parked in the parking area in response to the transmission of such a designated parking position, the control unit 505 of the management server 50 causes the arithmetic device 105 equipped in each of the multiple vehicles 10 to process job data, thereby realizing grid computing.

According to this embodiment, grid computing is realized by the arithmetic devices 105 mounted on a plurality of vehicles 10 whose planned stay times overlap, in a state where the vehicles 10 are parked within a range in a parking area where vehicle-to-vehicle communication is possible. As a result, during grid computing, vehicle-to-vehicle communication can be performed, and computation data can be appropriately transferred between the plurality of computation devices 105. In addition, the communication environment with the management server 50 can be uniformed among the plurality of computation devices 105, and job data and the like can be appropriately transferred. Furthermore, by forming a vehicle group in a parking area of a specified facility using the plurality of vehicles 10, the plurality of computation devices 105 can be operated simultaneously for a relatively long period of time. As a result, for example, distributed computing can be appropriately realized in grid computing. As described above, according to this embodiment, when grid computing is performed using the plurality of computation devices 105 mounted on the plurality of vehicles 10 that are not in operation, stable and highly reliable computation resources can be effectively secured.

In addition, according to this embodiment, a user specifies the planned date and time of stay in advance to book a visit to a specific facility, so that the number of vehicles 10 for each time period of the day can be determined based on the planned dates and times of stay specified in advance by multiple users. As a result, it becomes easy to estimate and adjust the amount of job data that can be calculated in a day in grid computing.

In addition, according to this embodiment, by gathering multiple vehicles 10 in a short distance (within a range where vehicle-to-vehicle communication is possible) in a parking area of a specified facility for grid computing, it is possible to contribute to the operation of the facility. For example, in order to gather multiple vehicles 10 in a short distance in a parking area, congestion in the parking area can be alleviated by managing (controlling) the parking positions of each vehicle 10. Furthermore, prior to managing the parking positions in this way, by understanding information such as the length of time visitors stay at the facility and the number of visitors, this information can be used in the operation of the facility.

Furthermore, in this embodiment, the storage unit 404 of the facility server 40 stores a parking position table in which designated parking positions are associated with each of a number of possible stay time periods during which vehicles 10 can stay at a specified facility, and are set so that the vehicles 10 with overlapping stay time periods are located within a range in the parking area where vehicle-to-vehicle communication is possible, and the control unit 405 of the facility server 40 refers to this parking position table to set designated parking positions associated with stay time periods corresponding to the planned stay time periods designated by the user. In this way, by using a parking position table in which the designated parking positions to be set for each stay time period are predefined, it is possible to assign appropriate designated parking positions to each of the multiple vehicles 10.

Furthermore, in this embodiment, the parking position table sets the designated parking positions so that multiple vehicles 10 with overlapping stay times are located within a range in the parking area where vehicle-to-vehicle communication is possible, and each of the multiple vehicles 10 is located adjacent to each other in the parking area. According to such a parking position table, by positioning each of the multiple vehicles 10 adjacent to each other in the parking area, it is possible to obtain an advertising effect by using a group of vehicles formed for grid computing.

Furthermore, in this embodiment, the control unit 505 of the management server 50 identifies the number of vehicles 10 whose planned stay times overlap on the day based on the planned stay dates and times received by the day before the day the user visits the specified facility, estimates the amount of job data that can be calculated on the day in grid computing based on this number of vehicles 10, and distributes this amount of job data to multiple calculation devices 105 for processing. This makes it possible to appropriately identify the number of vehicles 10 whose planned stay times overlap on the day based on the planned stay dates and times specified in advance by the user to reserve a visit to the specified facility, and as a result, it is possible to obtain an accurate amount of job data according to the number of vehicles 10 (i.e., the number of calculation devices 105).

Furthermore, in this embodiment, the control unit 505 of the management server 50 estimates the amount of job data based on the number of vehicles 10 identified by subtracting from the number of identified vehicles 10 the number of vehicles 10 for which users are expected to cancel reservations for visits at the planned stay date and time on that day, and the number of vehicles 10 for which the computing device 105 is expected to interrupt processing of job data while it is processing the data. This makes it possible to determine the amount of job data that can be calculated reliably on that day, even if reservations for the planned stay date and time are canceled or processing of job data is interrupted.

Furthermore, in this embodiment, the control unit 505 of the management server 50 pre-selects a reserve user from among multiple users who have specified a planned date and time of stay to reserve a visit to a specific facility, and when a user cancels a reservation for a visit at the planned date and time of stay, or when the computing device 105 interrupts processing of job data while it is in the middle of processing the job data, the control unit 505 of the management server 50 distributes the job data to the computing device 105 installed in the reserve user's vehicle 10 and has the processing device 105 process the job data, thereby realizing grid computing. As a result, even when a reservation for the planned date and time of stay is canceled or processing of job data is interrupted, grid computing can be reliably realized by redistributing the job data to the computing device 105 of the pre-selected reserve user.

[Modification]
In the above embodiment, the facility server 40 sets a parking position table in advance, refers to the parking position table, sets a designated parking position corresponding to the planned stay date and time received from the user, and transmits the designated parking position to the user. In another embodiment, the management server 50 may perform at least one of these processes instead of the facility server 40. In one example, the management server 50 may set a parking position table in advance, and when it receives a planned stay date and time from the user, refers to the parking position table, sets a designated parking position corresponding to the planned stay date and time, and transmits it to the user. In this example, only the management server 50 corresponds to the "management system,""storagedevice," and "control device" in the present invention. In another example, the facility server 40 sets a parking position table in advance and sets a designated parking position based on the parking position table, while the management server 50 receives a planned stay date and time from the user and transmits the planned stay date and time to the facility server 40, and also receives a designated parking position from the facility server 40 and transmits the designated parking position to the user. In this example, the facility server 40 and the management server 50 correspond to the "management system,""storagedevice," and "control device" in the present invention.

REFERENCE SIGNS LIST 1 System 10 Vehicle 20 User terminal 30 Client server 40 Facility server 50 Management server 104 Storage unit 105 Arithmetic device 404 Storage unit 405 Control unit 504 Storage unit 505 Control unit D1 Job data

Claims (7)

A management system for managing grid computing that causes a plurality of computing devices mounted on a plurality of vehicles to process job data, comprising:
A storage device that stores information about a plurality of computing devices and/or a plurality of vehicles equipped with the computing devices;
a control device configured to distribute the job data to each of a plurality of computing devices and cause them to process the job data based on the information stored in the storage device, thereby realizing the grid computing;
The control device includes:
receiving a planned stay date and time, the date and time including a planned stay date and a planned stay time period, which is designated in advance by a user of a vehicle equipped with the computing device in order to reserve a visit to a commercial facility having a parking area, on which the user plans to stay at the facility;
based on the planned stay dates and times of a plurality of users, set designated parking positions at which each of the plurality of vehicles should be parked in the parking area such that the vehicles of the plurality of users whose planned stay dates overlap on the same day are located within a range in the parking area where vehicle-to-vehicle communication is possible, and transmit the designated parking positions to the respective users of the plurality of vehicles;
When a plurality of vehicles are parked in the parking area in response to the transmission of the designated parking positions, the job data is processed by the arithmetic device mounted on each of the plurality of vehicles, thereby realizing the grid computing.
The management system is configured as follows. the storage device stores a parking position table in which the designated parking positions are associated with a plurality of stay time periods during which the vehicles can stay in the specified facility, the designated parking positions being set so that a plurality of vehicles having overlapping stay time periods are positioned within a range in the parking area where vehicle-to-vehicle communication is possible;
The control device is configured to refer to the parking position table stored in the storage device, set the designated parking position associated with the stay time period corresponding to the user's planned stay time period, and transmit the designated parking position to the user.
The management system according to claim 1 . The management system of claim 2, wherein the parking position table sets the designated parking positions so that the multiple vehicles with overlapping stay times are located within a range in the parking area where vehicle-to-vehicle communication is possible, and each of the multiple vehicles is located adjacent to each other in the parking area. The management system according to any one of claims 1 to 3, wherein the control device is configured to identify the number of vehicles whose planned stay times overlap on the day on which the user visits the specified facility based on the planned stay dates and times received by the day before the day on which the user visits the specified facility, estimate the amount of job data that can be calculated on the day in the grid computing based on this number of vehicles, and distribute this amount of job data to multiple computing devices for processing. The management system according to claim 4, wherein the control device is configured to estimate the amount of job data based on the number of vehicles obtained by subtracting from the number of identified vehicles the number of vehicles for which users are expected to cancel reservations to visit the specified facility on the day and/or the number of vehicles for which the computing device is expected to interrupt processing of the job data while the computing device is processing the job data. The management system according to any one of claims 1 to 5, wherein the control device is configured to realize the grid computing by setting in advance a reserve user from among a plurality of users who have specified the planned stay date and time to reserve a visit to the specified facility, and distributing the job data to the computation device mounted on the vehicle of the reserve user for processing when a user cancels the reservation to visit the specified facility and/or when the computation device interrupts the processing of the job data while it is processing the job data. A management method for managing grid computing, in which job data is processed by a plurality of computing devices mounted on a plurality of vehicles, by a computer, comprising the steps of:
storing information about the plurality of computing devices and/or the plurality of vehicles equipped with the computing devices;
and a control step of distributing the job data to each of a plurality of computing devices based on the information stored in the storage step, and causing the computing devices to process the job data, thereby achieving the grid computing,
The control step includes:
receiving a planned stay date and time, the planned stay date and time including a planned stay date and a planned stay time period, which is designated in advance by a user of a vehicle equipped with the computing device in order to reserve a visit to a commercial facility having a parking area, the planned stay date and the planned stay time period, during which the user plans to stay at the facility;
a step of setting designated parking positions at which each of the plurality of vehicles should be parked in the parking area based on the planned stay dates and times of the plurality of users, such that the plurality of vehicles of the plurality of users whose planned stay dates overlap on the same day are located within a range in the parking area where vehicle-to-vehicle communication is possible, and transmitting the designated parking positions to the respective users of the plurality of vehicles;
When a plurality of vehicles are parked in the parking area in response to the transmission of the designated parking positions, the computing device mounted on each of the plurality of vehicles processes the job data, thereby realizing the grid computing;
The management method according to claim 1,

Images