JP7707733B2 - Management system and method, and vehicle computing device - Google Patents

Description

The technology disclosed herein belongs to the technical fields of management systems and management methods, as well as vehicle computing devices.

In recent years, vehicles have been equipped with computing devices that have relatively high computing power for electronic control. However, such computing devices are not effectively utilized when the vehicle is not in use, such as when the vehicle is parked. In response to this situation, studies are being conducted to effectively utilize the computing devices installed in the vehicles by performing grid computing using computing devices installed in each of multiple vehicles.

For example, Patent Document 1 discloses a grid computing management server that uses a communication device mounted on a vehicle. This management server includes a signal receiving unit that receives a signal from the communication device indicating that it is possible to participate in grid computing, a state determining unit that determines whether the processing capacity of the processing device is insufficient, and a response transmitting unit that transmits an instruction to participate in grid computing to the communication device when the processing capacity of the processing device is insufficient.

Patent Document 2 also discloses a computational resource provision method that generates vehicle group resource information, which is information about the time during which a vehicle group formed by multiple vehicles can communicate with a user terminal and the computational resources that can be provided within that time, and receives a request from the user terminal to execute a task that matches the vehicle group resource information.

In Patent Document 2, while a vehicle is traveling, the distance between the user terminal and the last vehicle in the vehicle group that can directly communicate with the user terminal is calculated based on the position information of the user terminal, and whether or not the vehicle group can complete the execution of a task within the period in which it can communicate with the user terminal is calculated based on that distance. If the time required to complete the execution of the task falls short of the time in which the user terminal and the vehicle group can communicate, the execution of the task is interrupted and intermediate results are transmitted to the user terminal.

JP 2020-160661 A JP 2017-111727 A

When performing grid computing using a computing device mounted on a vehicle, it is desirable to perform job computation processing during periods when the vehicle is not in use, particularly while the vehicle is stopped, in order to improve the stability of communication between the vehicle and the server and between vehicles. In Patent Document 1, periods when the vehicle is not in use are identified based on the vehicle's usage history, and schedule information is generated that specifies the identified periods as periods during which the computing device can participate in grid computing. In Patent Document 1, it is possible to provide relatively stable computing power based on this schedule information.

However, the period during which the vehicle is not in use is not always constant, and even if it is estimated that the vehicle will not be used based on the vehicle usage history and the user's behavior history, the user may still use the vehicle, for example, to go shopping. If the vehicle is currently executing a calculation process for a job, the calculation process will be stopped. As in Patent Document 2, it is possible to interrupt the execution of the calculation process and send intermediate results to the user terminal, but in the case of a job that requires a huge amount of calculation processing, the intermediate results alone will have little utility as the calculation results.

The technology disclosed here has been developed in light of these issues, and its purpose is to stabilize job processing in grid computing using vehicle computing devices.

In order to solve the above problem, the technology disclosed herein is directed to a grid computing management system that performs job calculation processing with each of a plurality of vehicles as a calculation node when the vehicles are stopped, and includes a communication unit and a control unit. The control unit performs the following steps: compares a user arrival time, which is the time it takes for a user of a specific vehicle among the plurality of vehicles to reach the stopping position of the specific vehicle, with a job completion time, which is the time it takes for the specific vehicle to complete the calculation of the job; and, when the job completion time is equal to or less than the user arrival time, estimates that the specific vehicle is in a stable mode in which the calculation processing of the job can be stably executed, while, when the job completion time is longer than the user arrival time, estimates that the specific vehicle is in an unstable mode in which the calculation processing of the job may be stopped; and, when it is estimated that the specific vehicle is in the unstable mode, performs a delay request process to request the user of the specific vehicle via the communication unit to delay the timing of using the specific vehicle for driving when it is estimated that the specific vehicle is in the unstable mode.

In other words, when a user approaches a specific vehicle, there is a high possibility that the user will operate the specific vehicle and use it for traveling. Therefore, by estimating the user arrival time, it is possible to estimate the time during which the computing device can be used for computing processing of a job. Then, by comparing the estimated user arrival time with the job completion time, it is possible to estimate whether the user will be able to complete the job before using the specific vehicle.

When it is difficult for the user to complete the job before operating the specific vehicle, the system determines that the job is in an unstable mode and requests the user to delay the timing of operating the specific vehicle until the job calculation processing is completed. This makes it possible to urge the user not to operate the specific vehicle until the job calculation processing is completed, and the job calculation processing can be continued stably. Therefore, the job calculation processing can be stabilized.

Note that "operating a vehicle" means putting a particular vehicle into a state in which it can be driven, for example, by turning on the ignition or power.

In the management system, the information notified to the user in the delay request process may include information about the time from the current time until the job completion time.

With this configuration, the user can understand the time it will take to complete the calculation processing of the job, and can understand how much of a delay is needed before a specific vehicle can be put into operation. This makes it easier for the user to comply with a request for a delay. As a result, the calculation processing of the job can be stabilized.

In the management system, the information notified to the user in the delay request process may include information regarding a reward to be given to the user when the timing of operating the specific vehicle is delayed.

With this configuration, by presenting the user with a positive reason to comply with a request to continue computation, the user is more likely to comply with a request for a delay, thereby stabilizing the computation processing of the job.

In the management system, the information notified to the user in the delay request process may include information about the facility where the user is staying, which is obtained by the control unit via the communication unit.

This configuration makes it easier for users to consider how to spend the time until the job is completed. This makes it easier for users to comply with delay requests. As a result, the calculation processing of the job can be stabilized.

The management system may be configured to execute the delay request process when the excess time, which is the time of the job completion time that exceeds the user arrival time, is less than a predetermined time, and to execute a transfer process without executing the delay request process when the excess time is equal to or greater than the predetermined time, to transfer job data related to the job being calculated in the specific vehicle to other vehicles parked around the specific vehicle and participating in the grid computing.

In other words, if the excess time is short, the user's waiting time is short and so there is a high possibility that the user will comply with the delay request. On the other hand, if the excess time is too long, the user will feel annoyed and will not comply with the delay request. Therefore, when the excess time, i.e., the user's waiting time, is less than a predetermined time, a delay request is made, and when the user's waiting time is equal to or greater than the predetermined time, the job data is transferred to another vehicle. This allows the job calculation processing to continue in a specific vehicle when the excess time is short, and the job calculation processing to be handed over to another vehicle when the excess time is long. This makes it possible to stabilize the job calculation processing.

Another aspect of the technology disclosed herein is directed to a method for managing grid computing in which, when a plurality of vehicles are stopped, each of the plurality of vehicles is used as a computing node to perform computation processing of a job. Specifically, the management method includes a step of estimating a job completion time, which is the time it takes for a specific vehicle among the plurality of vehicles to complete the computation of the job; a step of calculating a user arrival time, which is the time it takes for a user of the specific vehicle to reach the stopping position of the specific vehicle; a mode estimation step of comparing the job completion time with the user arrival time, and estimating that the specific vehicle is in the stable mode when the job completion time is equal to or less than the user arrival time, and estimating that the specific vehicle is in the unstable mode when the job completion time is longer than the user arrival time; and a delay request step of requesting the user of the specific vehicle to delay the timing of operating the specific vehicle when it is estimated that the specific vehicle is in the unstable mode.

Even with this configuration, if it is difficult for the user to complete the job before operating the specific vehicle, the user is requested to delay operating the specific vehicle until the job calculation processing is completed. This allows the job calculation processing to continue stably until the job calculation processing is completed. Therefore, the job calculation processing can be stabilized.

Another aspect of the technology disclosed herein is directed to a vehicle computing device that becomes a computing resource for grid computing in which a plurality of vehicles are used as computing nodes to perform job computation when the vehicles are stopped. Specifically, the vehicle computing device includes a control unit that performs computation processing for the job, and the control unit executes an estimation process that compares a user arrival time, which is the time it takes for a user of the vehicle to reach the stopping position of the vehicle, with a job completion time, which is the time it takes for the vehicle to complete the computation of the job, and, when the job completion time is equal to or less than the user arrival time, estimates that the vehicle is in a stable mode in which the computation processing of the job can be stably performed, while, when the job completion time is longer than the user arrival time, estimates that the vehicle is in an unstable mode in which the computation processing of the job may be stopped, and a delay request process that requests the user of the vehicle to delay the timing of operating the vehicle when it is estimated that the vehicle is in the unstable mode.

Even with this configuration, when it is difficult for the user to complete the job before operating the vehicle, the user is requested to delay operating the vehicle until the job's calculation processing is completed. This makes it possible to urge the user not to operate the vehicle until the job's calculation processing is completed, and the job's calculation processing can be continued stably. Therefore, the job's calculation processing can be stabilized.

As described above, the technology disclosed herein can stabilize job calculation processing in grid computing using a vehicle's calculation device.

FIG. 1 is a schematic diagram illustrating a configuration of a system according to the first embodiment. FIG. 2 is a conceptual diagram for explaining grid computing. FIG. 3 is a block diagram illustrating the configuration of a vehicle. FIG. 4 is a block diagram illustrating the configuration of a user terminal. FIG. 5 is a block diagram showing the configuration of a client server. FIG. 6 is a block diagram illustrating an example of the configuration of the facility server. FIG. 7 is a block diagram showing the configuration of the management server. FIG. 8 is a flow chart illustrating a grid computing process performed by the system. FIG. 9 is a block diagram showing functional blocks for the control unit of the management system to perform the estimation process. FIG. 10 is a flowchart illustrating an estimation process of the control unit of the management system. FIG. 11 is a flowchart showing the process executed by the control unit of the management server when a specific vehicle is in the unstable mode. FIG. 12 is a diagram illustrating information exchanged between a vehicle and a user in a delay request process. FIG. 13 is a block diagram showing functional blocks for the control unit of the vehicle to perform the estimation process in the system according to the second embodiment. FIG. 14 is a flowchart showing a process executed by the control unit of the host vehicle when the host vehicle is in the unstable mode in the system according to the second embodiment.

An exemplary embodiment will be described in detail below with reference to the drawings.

[Embodiment 1]
(System Configuration)
1 illustrates an example of the configuration of a system 1 including a vehicle 10 having a computing device 105 according to embodiment 1. 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.

(Grid Computing)
2, in the system 1 of the first embodiment, grid computing is configured by the arithmetic devices 105 mounted on each vehicle 10. In grid computing, grid computing processing is performed in which job data is processed by an available arithmetic device 105 among the multiple arithmetic devices 105. In other words, the arithmetic device 105 corresponds to a computing resource of grid computing that performs arithmetic processing of a job with each of the multiple vehicles 10 as a computing node.

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 used. 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 ignition is turned off or the power 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. Basically, the computing device 105 is used as a computing resource for grid computing when the vehicle 10 is stopped, i.e., when the computing power of the computing device 105 is not being used for driving control.

(Vehicle configuration)
The vehicle 10 is a vehicle 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, and a computing device 105.

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 information used to control the vehicle 10. Examples of the sensor 12 include an exterior camera 121 (see FIG. 8) 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, a key detection sensor 122 (see FIG. 8), and an ignition sensor 123 (see FIG. 8; hereinafter referred to as the IG sensor 123).

The input unit 101 inputs information and data. Examples of the input unit 101 include a navigation system 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. The information and data input to the input unit 101 are sent to the calculation device 105.

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.

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 communication unit 103 is, for example, configured with a wireless communication device.

The memory unit 104 stores information and data.

The computing device 105 has a control unit 106 that controls each part of the vehicle 10. In this example, the control unit 106 controls the actuator 11 in response to various information obtained by the sensor 12.

The control unit 106 has a processor, a memory, and the like. Examples of the processor include a CPU (Central 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, and the like.

The number of processors constituting the control unit 106 may be one or more. The processor constituting the control unit 106 may be only one of a CPU and a GPU, or may be both a CPU and a GPU. In this example, the control unit 106 has both a CPU and a GPU. For example, the control unit 106 is composed of one or more ECUs (Electronic Control Units).

In this example, the memory unit 104 stores vehicle information D11, vehicle state information D12, driving history information D13, calculation device information D14, and driving schedule information D15.

<Vehicle Information>
The vehicle information D11 is information related to the vehicle 10. For example, the vehicle information D11 includes a vehicle ID set in the vehicle 10, a user ID set in the user who owns the vehicle 10, vehicle performance information indicating the performance of the vehicle, etc. The vehicle ID is an example of vehicle identification information that identifies the vehicle 10. The user ID is an example of user identification information that identifies the user.

<Vehicle status information>
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, etc. The vehicle position information indicates the position (latitude and longitude) of the vehicle 10. The vehicle position information can be acquired, for example, by a Global Positioning System (GPS). The vehicle communication information indicates the communication status 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, the accessory power supply is on or off, etc. 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).

<Driving history information>
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 date and time.

<Calculation device information>
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 calculation capacity indicating the calculation capacity (specifically, the maximum calculation capacity) of the arithmetic device 105, a ratio of the CPU and the GPU in the arithmetic device 105, and the like. The calculation capacity of the arithmetic device 105 is the amount of data that the arithmetic device 105 can calculate per unit time.

<Training schedule information>
The driving schedule information D15 is information indicating a usage schedule of the arithmetic device 105. For example, the schedule information indicates the date and time when the arithmetic device 105 is used for driving control. The schedule information may indicate the date and time when the arithmetic device 105 is not used for driving control. The schedule information may be input from the input unit 101 or may be input from the user terminal 20. In addition, the schedule information may indicate a driving schedule estimated based on the driving history information D13.

(Configuration of user terminal)
The user terminal 20 is a terminal device 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 laptop-type 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 audio showing information. For example, a user can operate the operation unit to access the navigation system of the vehicle 10 and thereby register a reservation for a destination. The information input to the input unit 101 is sent to the calculation device 105.

The output unit 202 outputs information and data. Examples of the output unit 202 include a display unit that outputs an image showing information, and a speaker that outputs sound showing information.

The communication unit 203 transmits and receives information and data. Information and data received by the communication unit 303 is sent to the control unit 205.

The memory unit 204 stores information and data.

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.

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

<Device Information>
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, etc. The user terminal ID is an example of user terminal identification information that identifies the user terminal 20.

<Device status information>
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, and the like.

<Schedule Information>
The schedule information D23 indicates the action history and action plan of the user who owns the user terminal 20. For example, the schedule information D23 indicates the user's location and the stay period (or the planned stay period) in association with each other. The schedule information D23 can be acquired by a schedule function installed in the user terminal 20. Specifically, the user inputs his/her action history and action plan into the user terminal 20 using the schedule function, thereby obtaining the schedule information D23 indicating the action history and action plan of the user. The schedule information D23 includes a schedule for driving the vehicle 10.

(Client-server configuration)
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. 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 showing information, and a speaker that outputs sound showing information.

The communication unit 303 transmits and receives information and data. The information and data received by the communication unit 303 is sent to the control unit 305.

The memory unit 304 stores information and data.

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.

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

Client Information
The client information D31 is information about a client. The client information D31 includes a client ID set in the client, a client server ID set in the client server 30 owned by the client, a person in charge 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>
The job data D1 is data corresponding to a job, and is data to be processed for carrying out the job.

The 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 the CPU-based calculation type tends to require complex calculations with many conditional branches, such as simulation calculations. Job data D1 of the 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 the processing conditions of the job. 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 computational resources (i.e., the computing device 105) are 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 computational resources are 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.

(Configuration of facility server)
The facility server 40 is owned by a facility. Examples of the facility include a user's workplace, a stadium, a theater, a movie theater, a supermarket, a restaurant, an accommodation facility, a ticket sales facility, etc. For a facility that requires a reservation for a visit, the user can make a reservation for a visit to the facility via the user terminal 20.

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.

Facility Information
The facility information D41 is information related to a 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, the name of a person in charge, an address, a telephone number, etc. The facility ID is an example of facility identification information that identifies a facility. The facility server ID is an example of facility server identification information that identifies the facility server 40.

<Facility Usage Information>
The facility usage information D42 indicates the usage status (usage history and planned usage) of the facility. Specifically, the facility usage information D42 indicates users who use the facility and their stay period (or planned stay period) in association with each other.

(Management Server Configuration)
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.

As shown in FIG. 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, output unit 502, communication unit 503, storage unit 504, and control unit 505 of the management server 50 are similar to the configurations of the input unit 301, output unit 302, communication unit 303, storage unit 304, and control unit 305 of the client server 30. The processing of the control unit 505, which will be described later, is executed by a processor constituting the control unit 505, using programs and data stored in the memory of the control unit 505.

In this example, the memory unit 504 stores a user table D51, a calculation 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.

<User table>
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 calculation device ID set for the calculation device 105 owned by that user, a user terminal ID set for the user terminal 20 owned by that user, and the like.

<Calculation Unit Table>
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 the arithmetic device 105, a user ID set for the user who owns the arithmetic device 105, a vehicle ID set in the vehicle 10 in which the arithmetic device 105 is mounted, and the like 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.

Client Table
The client table D53 is a table for managing clients. For each client, the client table D53 registers a client ID set for that client, a client server ID set for the client server 30 owned by the client, and the name, address, and telephone number of the person in charge of the client. The client table D53 records the usage history of grid computing for each client.

<Job Table>
The job table D54 is a table for managing jobs requested by clients. For each job, the reception number set for that job, the client ID set for the client who requested the job, the name and contents of the job, etc. are registered in the job table D54. 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 calculation capacity which is the calculation capacity required for the calculation of the job data, the delivery date set for that job, etc.

Resource Table
The resource table D55 is a table for managing the computing power in grid computing processing. Specifically, the resource table D55 is a table for managing computing power information related to the estimated computing power of the computing resource. In the resource table D55, for each computing device 105, the computing device ID set for that computing device 105 is registered.

Matching Table
The matching table D56 is a table for managing the results of a matching process that matches jobs with grid computing. In the matching table D56, for each job, a reception number set for the job, job data corresponding to the job, and a computing device ID set for each computing device 105 constituting the computing resource allocated to the job data by the matching process are registered.

<Job Data>
The job data D1 stored in the storage unit 504 is the accepted job data D1.

<Calculation result data>
The calculation result data D2 stored in the storage unit 504 is calculation result information calculated by grid computing processing, and indicates the results of the calculation.

(Grid Computing Processing)
Next, the grid computing process will be described with reference to Fig. 8. In the grid computing process, the job data D1 is processed by an available arithmetic device 105 among the multiple arithmetic devices 105. After completing the matching process, the control unit 505 performs the following processes.

First, in step S11, the control unit 505 refers to the matching table D56 and distributes the job data D1 to be subjected to the grid computing process to the computing devices 105 assigned to the job data D1 in the matching process. Specifically, the control unit 505 transmits a portion of the job data D1 to each of the computing devices 105 assigned to the job data D1. As a result, the job data D1 is processed in parallel by the computing devices 105 assigned to the job data D1.

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

Next, in step S13, the control unit 505 determines whether all of the calculation devices 105 to which the job data D1 was distributed in step S11 have completed calculation. If all of the calculation devices 105 have completed calculation, the control unit 505 proceeds to step S14, and if at least some of the calculation devices 105 have not completed calculation, the control unit 505 performs the process of step S12.

In step S14, the control unit 505 generates calculation result data D2 (calculation result data D2 indicating the result of the calculation of the 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.

Then, in step S15, the operator of system 1 grants a reward to the user who provided the computing power of the computing device 105 to the grid computing process. Examples of rewards granted to users include points, virtual currency, and product discount benefits that can be used in system 1. For example, the control unit 505 of the management server 50 performs a process for granting a reward to the user who provided the computing power of the computing device 105 to the grid computing process. Examples of the process for granting a reward include a process for registering in user table D51 a "user ID" set for the user and "points" (or virtual currency) that can be used in system 1, and a process for transmitting information indicating a product discount benefit to a user terminal 20 owned by the user.

In addition, a reward may be given by the client to a user who has provided the computing power 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 giving a reward to a user who has provided the computing power of the computing device 105 to the grid computing process.

(Vehicle Processing on Grid Computing)
In order to successfully complete the grid computing process as described above, it is necessary that the arithmetic device 105 of the vehicle 10 is stably supplied as a computational resource, that is, that each vehicle 10 is capable of stably executing the computational process of the job. The arithmetic device 105 can estimate the time period during which the vehicle 10 is stopped based on the driving schedule information D15 stored in the storage unit 104 and the schedule information D23 acquired from the user terminal 20. In other words, the arithmetic device 105 can schedule in advance the time period during which it can supply itself as a computational resource for grid computing (the time period during which it can participate in grid computing).

However, even during a time period that the computing device 105 estimates as a time period during which the vehicle 10 can participate in grid computing, the user may suddenly drive the vehicle 10, for example, to go shopping or to travel to work. For this reason, the computing device 105 must use itself for driving control while performing computational processing of a job given to it in grid computing. When this happens, the computing device 105 is forced to abort the job, which may result in the grid computing processing not being completed normally.

Therefore, in this embodiment 1, the management server 50 of the system 1 performs an estimation process for each vehicle 10 participating in grid computing to estimate whether the vehicle 10 is in a stable mode in which it can stably execute the calculation processing of the job, or in an unstable mode in which the calculation processing of the job may be stopped. Then, when the management server 50 estimates that a specific vehicle 10a among the vehicles 10 is in an unstable mode, it performs a delay request process to request the user to delay the timing of operating the specific vehicle 10a. Note that the specific vehicle 10a is one vehicle among the multiple vehicles 10 that make up the grid computing, and all of the vehicles 10 that make up the grid computing can be a specific vehicle 10a.

Note that "operating a vehicle" means putting a specific vehicle into a state in which it can be driven, for example, by turning on the ignition or power. In other words, "delaying the timing of operation" means delaying the timing of turning on the ignition or power, and does not include cases in which a user simply unlocks the doors to get into the vehicle.

Figure 9 shows the functional blocks that constitute the functions for the management server 50 to execute the estimation process.

The management server 50 has a user arrival time estimation module 551 that estimates a user arrival time _ta , which is the time it takes for a user of a specific vehicle 10a to reach a stopping position of the specific vehicle 10a. Information from the exterior camera 121, the key detection sensor 122, and the position detection module 162 of the specific vehicle 10a is input to the user arrival time estimation module 551. Travel history information D13 is input to the user arrival time estimation module 551 from the storage unit 14.

Multiple exterior cameras 121 are installed on the specific vehicle 10a so that they can capture 360-degree images around the specific vehicle 10a.

The key detection sensor 122 communicates with a keyless key or smart key (registered trademark) owned by the user of the specific vehicle 10a to detect the location of the keyless key, etc.

The position detection module 162 is a module that communicates with the user terminal 20 owned by the user of the specific vehicle 10a and detects the position of the user terminal 20. The position detection module 162 detects the position of the user terminal 20, for example, by using a GPS sensor mounted on the user terminal 20.

The user arrival time estimation module 551 estimates the distance between the specific vehicle 10a and the user based on the detection results from the exterior camera 121, the key detection sensor 122, and the position detection module 162 of the specific vehicle 10a. The user arrival time estimation module 551 estimates the time change of the estimated distance (i.e., the user's moving speed) from the estimated distance. Then, the user arrival time estimation module 551 estimates the user arrival time _ta from the estimated distance and the user's moving speed. Note that when it is difficult to obtain information from the exterior camera 121, the key detection sensor 122, and the position detection module 162, the user arrival time estimation module 551 estimates the user arrival time ta from the stopping position of the specific vehicle _10a and the driving history information D13.

The management server 50 has a job completion time estimation module 552 that estimates a job completion time _tj, which is the time required for a specific vehicle 10a (strictly speaking, a computing unit of the specific vehicle) to complete the computation of a job. The job completion time estimation module 552 estimates a job completion time tj, which is the time required for the vehicle (strictly speaking, a computing unit of the specific vehicle) to complete the computation of a job, from information from the computation resource management module 166 of the specific vehicle 10a and job data allocated to the specific vehicle 10a (hereinafter, referred to as partial job data D1a ₎ .

The computational resource management module 166 is a module that manages the current computational resources, in other words, the current computational capacity, of the computing unit of the vehicle. Information regarding the current computational capacity of the computing unit is input from the computational resource management module 166 to the stability estimation module 163.

The job completion time estimation module 552 estimates the job completion time _tj when the partial job data Da1 is processed using the current computing capacity of the computing unit obtained from the computing resource management module 166.

The management server 50 has a mode estimation module 553 that compares the user arrival time t _a obtained from the user arrival time estimation module 161 with the job completion time t _j obtained from the job completion time estimation module 552 to estimate whether the specific vehicle 10 a is in a stable mode or an unstable mode.

The mode estimation module 553 compares the user arrival time _ta with the job completion time _tj , and estimates that the specific vehicle 10a is in the stable mode when the job completion time _tj is equal to or less than the user arrival time _ta . On the other hand, the mode estimation module 553 estimates that the specific vehicle 10a is in the unstable mode when the job completion time _tj is longer than the user arrival time _ta .

Information about the mode estimated by the mode estimation module 553 is sent to the processing execution management module 554.

When the process execution management module 554 acquires information that the specific vehicle 10a is estimated to be in the stable mode, the process execution management module 554 continues the job calculation process for the specific vehicle 10a according to the schedule. On the other hand, when the process execution management module 554 acquires information that the specific vehicle 10a is estimated to be in the unstable mode, the process execution management module 554 performs processing according to the excess time, which is the time of the job completion time _tj that exceeds the user arrival time _ta . The excess time corresponds to the difference between the job completion time _tj and the user arrival time _ta .

If the excess time is less than a predetermined time, the process execution management module 554 executes a delay request process to request a delay to the user of the specific vehicle 10a. On the other hand, if the excess time is equal to or greater than the predetermined time, the process execution management module 554 does not execute the delay request process, but executes a transfer process to transfer the partial job data 1a being calculated in the specific vehicle 10a to other vehicles parked around the specific vehicle 10a and participating in the same grid computing. The predetermined time is a length of time that does not cause inconvenience to the user, and is set to, for example, 10 to 20 minutes.

When the process execution management module 551 executes the delay request process, it sends a delay request notification to the user terminal 20 via the communication unit 503. On the other hand, when the process execution management module 551 executes the transfer process, it sends a control signal to the specific vehicle 10a via the communication unit 503 to transfer the partial job data D1a to the other vehicle.

The user arrival time estimation module 551, the job completion time estimation module 552, the mode estimation module 553, the position detection module 162, the stability estimation module 163, the communication status management module 164, and the process execution management module 554 are examples of modules that constitute the control unit 505 of the management server 50. The position detection module 162 and the computational resource management module 166 are examples of modules that constitute the control unit 106 of the specific vehicle 10a.

<Flowchart of Estimation Processing>
10 is a flowchart illustrating an example of the estimation process executed by the management server 50. Note that, here, a case will be described in which the user position can be identified by the key detection sensor 122 or the like.

First, in step S21, the management server 50 acquires various information from the specific vehicle 10a.

Next, in step S22, the management server 50 detects the current location of the user of the specific vehicle 10a. Here, not only the user's two-dimensional position but also the height position, i.e., the three-dimensional position, is detected.

Next, in step S23, the management server 50 estimates the distance between the user and the specific vehicle 10a. Here, the straight-line distance between the user and the specific vehicle 10a is estimated.

Next, in step S24, the management server 50 estimates the user's moving speed. The management server 50 estimates the user's moving speed from the change in the distance between the user and the specific vehicle 10a over time.

Next, in step S25, the management server 50 estimates the user arrival time t _a using the estimated distance estimated in step S23 and the user's moving speed estimated in step S24.

Next, in step S26, the management server 50 uses the partial job data D1a and the current computing capacity of the computing unit 150 to estimate the job completion time _tj .

Next, in step S27, the management server 50 determines whether the user arrival time _ta is equal to or greater than the job completion time _tj . If the result is YES, that is, the management server 50 determines that the user arrival time _ta is equal to or greater than the job completion time _tj , the process proceeds to step S28. On the other hand, if the result is YES, that is, the control unit 106 determines that the user arrival time _ta is less than the job completion time _tj , the process proceeds to step S29.

In step S28, the management server 50 estimates that the specific vehicle 10a is in stable mode. On the other hand, in step S29, the management server 50 estimates that the specific vehicle 10a is in unstable mode. The management server 50 returns after step S28 or S29.

In this way, by estimating the user arrival time _ta from the estimated distance and the time change of the estimated distance, the user arrival time _ta can be estimated with high accuracy. That is, even if the user is located nearby, if the user's moving speed is slow, the user arrival time _ta will be long. In this way, by estimating the user arrival time _ta with high accuracy, it is possible to accurately estimate whether the specific vehicle 10a is in the unstable mode.

<Processing in Unstable Mode>
Next, the process executed by the management server 50 when the specific vehicle 10a is estimated to be in the unstable mode will be described with reference to Fig. 11 and Fig. 12. Here, the case where there are other vehicles participating in the same grid computing around the specific vehicle 10a as shown in Fig. 12 will be described. Note that the flowchart starts with the estimation process by the management server 50.

First, in step S31, the management server 50 estimates the mode of the specific vehicle 10a. In particular, the management server 50 estimates whether the specific vehicle 10a is in stable mode or unstable mode based on the flowchart in FIG. 10.

Next, in step S32, the management server 50 determines whether the specific vehicle 10a is in an unstable mode. If the management server 50 determines that the user is approaching as shown in FIG. 12 and that the specific vehicle 10a is in an unstable mode (YES), the process proceeds to step S33. If the management server 50 determines that the specific vehicle 10a is still in a stable mode (NO), the process ends.

In step S33, the management server 50 judges whether the excess time of the job completion time _tj relative to the user arrival time _ta is less than a predetermined time. If the excess time is less than the predetermined time (YES), the management server 50 proceeds to step S34. On the other hand, if the excess time is equal to or greater than the predetermined time (NO), the management server 50 proceeds to step S37.

In step S34, the management server 50 makes a delay request to the user of the specific vehicle 10a. The management server 50 sends a delay request notification to the user terminal 20. At this time, the management server 50 also notifies the user of information for increasing the possibility that the user will comply with the delay request. For example, the information notified to the user in the delay request process includes the job completion time _tj , the time from the current time to the job completion time _tj , the overtime, and information on the reward to be given to the user when the timing of operating the specific vehicle 10a is delayed. In addition, if the facility where the user is staying is a commercial facility (including a commercial complex) or a theme park, as shown in FIG. 12, the management server 50 acquires facility information from the facility server and notifies the user of the facility information. The facility information here is, for example, product advertisements, product sale information, and information on places in commercial facilities and theme parks that the user has not visited. In this way, the possibility that the user will comply with the delay request is increased by actively giving the user a reason to comply with the delay request.

Next, in step S35, the management server 50 determines whether or not the user of the specific vehicle 10a has given permission for the delay request. If the user agrees to the delay request (YES), the management server 50 proceeds to step S36. On the other hand, if the user does not agree to the delay request (NO), the management server 50 proceeds to step S37.

In step S36, the management server 50 causes the specific vehicle 10a to continue the job calculation. After step S36, the processing ends.

In step S37, the management server 50 calculates the stability of other vehicles 10 that are present around the specific vehicle 10a and participating in the same grid computing. This stability is an index showing how stable the other vehicles are in completing the computational processing of the job. It is information showing the stability calculated by the control unit 106 of the computation device 105. As shown in FIG. 12, the management server 50 obtains various information from the other vehicles 10 to calculate the stability. The stability of each vehicle 10 is calculated, for example, by a points system. The stability of the vehicle itself is calculated, for example, by the following criteria.
A longer estimated distance provides greater stability than a shorter estimated distance.
- A wider communication band provides greater stability than a narrower communication band.
- Charging is more stable when it is on than when it is off.
- A system with more computing resources is more stable than a system with fewer computing resources.
A longer period during which the computational processing of a job can be executed provides higher stability than a shorter period.
The stability is higher when there are many other vehicles participating in the same grid computing in the vicinity, compared to when there are only a few such vehicles.

Next, in step S38, the management server 50 transmits a control signal to the specific vehicle 10a to package and transfer the partial job data D1a to the vehicle with the highest stability among the other vehicles. The specific vehicle 10a that receives the control signal stops the calculation processing of the partial job data D1a and saves the partial job data D1a. The specific vehicle 10a then packages the partial job data D1a. At this time, if partial calculation result data exists, the partial calculation result data is also packaged. After packaging of the partial job data D1a is completed, the specific vehicle 10a starts transferring the partial job data D1a to the selected other vehicles. The specific vehicle 10a transfers the partial job data D1a by vehicle-to-vehicle communication via the communication unit 103. After the transfer is completed in step S38, the management server 50 ends the process.

In this manner, the management server 50 performs the delay request process or transfer process. When the user complies with the delay request, the management server 50 receives a reward from the operator of the system 1. This reward is different from the reward given to the user when the job calculation process is completed in grid computing, as described above. Examples of rewards include points that can be used in the system 1, virtual currency, and product discount benefits. If the overtime is equal to or exceeds a predetermined time or if the user does not comply with the delay request, and there is no other vehicle 10 in the vicinity to which the specific vehicle 10a can transfer the partial job data D1a, the management server 50 sends a control signal to the specific vehicle 10a to return the partial job data D1a to the management server 50.

Therefore, in this embodiment 1, the management server 50 of the system 1 is equipped with a communication unit 503 and a control unit 505, and the control unit 505 performs an estimation process to compare a user arrival time _ta , which is the time it takes for a user of a specific vehicle 10a among the multiple vehicles 10 to reach the stopping position of the specific vehicle 10a, with a job completion time _tj , which is the time it takes for the specific vehicle 10a to complete the calculation of the job, and, when the job completion time _tj is equal to or less than the user arrival time _ta , estimates that the specific vehicle 10a is in a stable mode in which the calculation processing of the job can be stably executed, while, when the job completion time _tj is longer than the user arrival time _ta , estimates that the specific vehicle 10a is in an unstable mode in which the calculation processing of the job may be aborted, and a delay request process to request the user of the specific vehicle 10a via the communication unit 503 to delay the timing of operating the specific vehicle 10a when it is estimated that the specific vehicle 10a is in an unstable mode. As a result, in the case where a user suddenly operates a specific vehicle, if it is difficult for the user to complete the job before using the specific vehicle, the system determines that the mode is unstable and requests the user to delay operating the specific vehicle until the job is completed. This makes it possible to urge the user not to operate the specific vehicle until the job is completed, and the job calculation process can be continued stably. Therefore, the job calculation process can be stabilized.

In particular, in the first embodiment, the delay request notification to the user includes information on the time from the current time to the job completion time _tj , information on the reward to be given to the user when the timing of operating the specific vehicle 10a is delayed, and facility information of the facility where the user is staying. This allows the user to understand how long to delay the use of the vehicle, and provides a positive reason for delaying the use of the vehicle. As a result, the user becomes more likely to comply with the delay request, and the calculation processing of the job can be made more stable.

In the first embodiment, when the overtime, which is the time of the job completion time _tj that exceeds the user arrival time t _a , is less than a predetermined time, a delay request process is executed, whereas when the overtime is equal to or more than the predetermined time, a transfer process is executed to transfer the partial job data D1a related to the job being processed in the specific vehicle 10a to the other vehicles 10 that are parked around the specific vehicle 10a and participating in the grid computing without executing the delay request process. As a result, when the user's waiting time is short and the user is likely to comply with the delay request, a delay request is executed, whereas when the user's waiting time is long and the user is likely to feel annoyed and not comply with the delay request, the partial job data D1a is transferred to the other vehicles. As a result, when the user's waiting time is short, the job's calculation process can be continued in the specific vehicle 10a, and when the user's waiting time is long, the job's calculation process can be handed over to the other vehicles 10. This makes it possible to make the job calculation process more stable.
[Embodiment 2]
Hereinafter, the second embodiment will be described in detail with reference to the drawings. In the following description, the same reference numerals will be used to designate the same parts as those in the first embodiment, and detailed description thereof will be omitted.

The second embodiment differs from the first embodiment in that the estimation process, delay request process, and transfer process are performed by the control unit 106 of the vehicle 10, not by the management server 50. The process of the control unit 106, which will be described later, is executed by the processor of the control unit 106 using programs and data stored in the memory of the control unit 106.

Specifically, as shown in FIG. 13, in this embodiment 2, each vehicle 10 is provided with a stability estimation module 163 that estimates the stability of the job calculation processing, including the mode of the vehicle 10. The stability estimation module 163 receives information from the exterior camera 121, the key detection sensor 122, the position detection module 162, the communication status management module 164, the charge status monitoring module 165, and the calculation resource management module 166. The stability estimation module 163 also receives driving history information D14 from the memory unit 104 and map information via the communication unit 103. The stability estimation module 163 also receives information about partial job data D1a being calculated by the vehicle itself.

The exterior camera 121, key detection sensor 122, position detection module 162, and computational resource management module 166 are the same as those in the first embodiment, so detailed explanations will be omitted.

The communication state management module 164 is a module that manages the communication band of the vehicle. Information regarding the communication band of the vehicle is input from the communication state management module 164 to the stability estimation module 163.

The charging state monitoring module 165 is a module that monitors the charging state of the vehicle. The charging state monitoring module 165 inputs to the stability estimation module 163 whether the vehicle is in a charging state or not in the form of an on/off signal.

The stability estimation module 163 estimates the user arrival time _ta and the job completion time _tj based on the input information, and estimates whether the vehicle is in a stable mode or an unstable mode. This estimation process is basically the same as in the first embodiment except that the main body is the stability estimation module 163, and the flowchart is different from the flowchart shown in FIG. 10 only in that the main body is different, so detailed description will be omitted.

The stability estimation module 163 estimates the stability of the vehicle based on the input information. The stability is calculated using the points formula as described in the first embodiment. The method of calculating the stability is basically the same as in the first embodiment, so a detailed description is omitted.

The estimation results of the stability estimation module 163 are input to the processing execution management module 167.

When the process execution management module 167 acquires information that the host vehicle is estimated to be in the stable mode, the process execution management module 167 continues the job calculation process for the host vehicle according to the schedule. On the other hand, when the process execution management module 167 acquires information that the host vehicle is estimated to be in the unstable mode, the process execution management module 167 performs processing according to an excess time, which is the time of the job completion time _tj that exceeds the user arrival time _ta . The excess time corresponds to the difference between the job completion time _tj and the user arrival time _ta .

If the excess time is less than a predetermined time, the process execution management module 167 executes a delay request process to request a delay to the user of the vehicle. On the other hand, if the excess time is equal to or greater than the predetermined time, the process execution management module 167 does not execute the delay request process, but executes a transfer process to transfer the partial job data D1a being calculated in the vehicle to other vehicles that are parked around the vehicle and participating in the same grid computing. The predetermined time is a length of time that does not cause inconvenience to the user, and is set to, for example, 10 to 20 minutes.

When the process execution management module 167 executes the delay request process, it sends a delay request notification to the user terminal 20 via the communication unit 103. On the other hand, when the process execution management module 166 executes the transfer process, it sends a control signal via the communication unit 103 to the own vehicle to transfer the partial job data D1a to another vehicle.

The position detection module 162, the stability estimation module 163, the communication status management module 164, the charging status monitoring module 165, the computational resource management module 166, and the processing execution management module 167 are examples of modules that constitute the control unit 106 of the vehicle 10.

Next, the process executed by the control unit 106 when it is estimated that the vehicle is in the unstable mode will be described with reference to FIG. 14. Note that the flowchart in FIG. 14 starts with the estimation process executed by the control unit 106. In addition, since the process is basically similar to the process described with reference to FIG. 11 in the first embodiment, a detailed description will be omitted.

First, in step S41, the control unit 106 estimates the mode of the host vehicle.

Next, in step S42, the control unit 106 determines whether the host vehicle is in an unstable mode. If the control unit 106 determines that the host vehicle is in an unstable mode (YES), the process proceeds to step S43. If the control unit 106 determines that the host vehicle is still in a stable mode (NO), the process ends.

In step S43, the control unit 106 judges whether the excess time of the job completion time _tj relative to the user arrival time _ta is less than a predetermined time. If the excess time is less than the predetermined time (YES), the control unit 106 proceeds to step S44. On the other hand, if the excess time is equal to or greater than the predetermined time (NO), the control unit 106 proceeds to step S47.

In step S44, the control unit 106 requests the user of the vehicle to delay.

Next, in step S45, the control unit 106 determines whether or not the user of the vehicle has given permission for the delay request. If the user agrees to the delay request (YES), the control unit 106 proceeds to step S46. On the other hand, if the user does not agree to the delay request (NO), the control unit 106 proceeds to step S47.

In step S46, the control unit 106 causes the vehicle to continue the job calculation. After step S46, the process ends.

In step S47, the control unit 106 acquires stability information of other vehicles that are present around the vehicle and participating in the same grid computing.

Next, in step S48, the control unit 106 packages and transfers the partial job data D1a to the vehicle with the highest stability among the other vehicles. The control unit 106 stops the calculation processing of the partial job data D1a and saves the partial job data D1a. The specific vehicle 10a then packages the partial job data D1a. At this time, if partial calculation result data exists, the partial calculation result data is also packaged. After completing packaging of the partial job data D1a, the specific vehicle 10a starts transferring the partial job data D1a to the selected other vehicles. The specific vehicle 10a transfers the partial job data D1a by vehicle-to-vehicle communication via the communication unit 103.

Then, in step S49, the control unit 106 deletes the partial job data D1a of the own vehicle as soon as the transfer of the partial job data D1a to the other vehicle is completed. After step S49, the control unit 106 ends the process.

In this manner, the calculation device 105 of the vehicle 10 performs the delay request process or transfer process. When the overtime is equal to or exceeds a predetermined time or when the user does not comply with the delay request, and there is no other vehicle nearby to which the vehicle can transfer the partial job data D1a, the calculation device 105 transfers the partial job data D1a to the management server 50.

Therefore, even if the calculation device 105 of the vehicle 10 is configured to perform estimation processing and delay request processing as in the second embodiment, the user can be prompted not to operate the vehicle until the calculation processing of the job is completed, and the calculation processing of the job can be continued stably. Therefore, the calculation processing of the job can be stabilized.

Other Embodiments
The technology disclosed herein is not limited to the above-described embodiment, and may be substituted without departing from the spirit and scope of the claims.

For example, in the above-mentioned first and second embodiments, when the overtime is equal to or greater than a predetermined time, the partial job data D1a is transferred to another vehicle. Without being limited to this, when the overtime is equal to or greater than a predetermined time, the reward given when complying with a delay request may be increased compared to when the overtime is less than the predetermined time.

The above-described embodiments are merely examples and should not be interpreted as limiting the scope of the present disclosure. The scope of the present disclosure is defined by the claims, and all modifications and variations that fall within the scope of equivalence of the claims are within the scope of the present disclosure.

The technology disclosed here is useful for performing job calculations using grid computing with multiple vehicles acting as computational nodes when multiple vehicles are stopped.

1 System 10 Vehicle 10a Specific vehicle 105 Calculation device 103 Communication unit 106 Control unit 503 Communication unit 505 Control unit D1a Partial job data

Claims (7)

A management system for grid computing in which a plurality of vehicles are used as a computing node to perform job calculation processing when the plurality of vehicles are stopped,
The Communications Department and
A control unit,
The control unit is
an estimation process for comparing a user arrival time, which is the time it takes for a user of a specific vehicle among the multiple vehicles to reach the stopping position of the specific vehicle, with a job completion time, which is the time it takes for the specific vehicle to complete the calculation of the job, and estimating that the specific vehicle is in a stable mode in which it can stably execute the calculation processing of the job when the job completion time is equal to or less than the user arrival time, and estimating that the specific vehicle is in an unstable mode in which there is a possibility that the calculation processing of the job will be aborted when the job completion time is longer than the user arrival time;
a delay request process for requesting the user of the specific vehicle via the communication unit to delay a timing of using the specific vehicle for traveling when it is estimated that the specific vehicle is in the unstable mode;
A management system comprising: 2. The management system according to claim 1,
The management system according to claim 1, wherein the information notified to the user in the delay request process includes information about the time from the current time until the job completion time. 3. The management system according to claim 1,
A management system characterized in that the information notified to the user in the delay request processing includes information regarding a reward to be given to the user when the timing of operating the specific vehicle is delayed. In the management system according to any one of claims 1 to 3,
A management system characterized in that the information notified to the user during the delay request processing includes information about the facility where the user is staying, which is obtained by the control unit via the communication unit. In the management system according to any one of claims 1 to 4,
The control unit executes the delay request processing when an excess time, which is the time of the job completion time that exceeds the user arrival time, is less than a predetermined time, and when the excess time is equal to or greater than the predetermined time, does not execute the delay request processing but executes a transfer processing to transfer job data related to the job being calculated in the specific vehicle to other vehicles parked around the specific vehicle and participating in the grid computing. A method for managing grid computing in which a plurality of vehicles are used as a computing node to perform job computation processing when the plurality of vehicles are stopped, the method comprising the steps of:
estimating a job completion time, which is a time required for a specific vehicle among the plurality of vehicles to complete a calculation of the job;
calculating a user arrival time, which is a time required for a user of the specific vehicle to arrive at a stopping position of the specific vehicle;
a mode estimation step of comparing the job completion time with the user arrival time, and estimating that the specific vehicle is in the stable mode when the job completion time is equal to or less than the user arrival time, and estimating that the specific vehicle is in the unstable mode when the job completion time is longer than the user arrival time;
A management method characterized by including a delay request process of requesting the user of the specific vehicle to delay the timing of operating the specific vehicle when it is estimated that the specific vehicle is in the unstable mode. A computing device of a vehicle that, when a plurality of vehicles are stopped, serves as a computing resource of grid computing for performing job computation processing with each of the plurality of vehicles as a computing node,
A control unit that performs calculation processing of the job,
The control unit is
an estimation process for comparing a user arrival time, which is the time it takes for a user of the vehicle to reach a stopping position of the vehicle, with a job completion time, which is the time it takes for the vehicle to complete the calculation of the job, and estimating that the vehicle is in a stable mode in which the calculation processing of the job can be stably executed when the job completion time is equal to or less than the user arrival time, and estimating that the vehicle is in an unstable mode in which the calculation processing of the job may be aborted when the job completion time is longer than the user arrival time;
a delay request process for requesting the user of the host vehicle to delay a timing for operating the host vehicle when it is estimated that the host vehicle is in the unstable mode;
A vehicle computing device that executes the above.