JP7782207B2 - Grid computing management method and management system - Google Patents

Description

The technology disclosed herein belongs to the technical field of grid computing management methods and management systems.

Patent Document 1 discloses technology related to a grid computing system that uses computational resources installed in a vehicle. In Patent Document 1, when the processing capacity of at least one of multiple processing devices is insufficient, a management server sends an instruction to the vehicle to participate in grid computing.

Patent Document 2 discloses technology for managing the content of services provided to vehicle users for each user. In Patent Document 2, when a vehicle user uses a service, license information associated with both the vehicle ID assigned to the vehicle and the user ID assigned to the user is read from a storage unit, and the content of the service provided to the vehicle user is managed via a service management unit.

Japanese Patent Application Laid-Open No. 2020-160661 JP 2019-109816 A

When performing grid computing calculations (hereinafter also referred to as "grid calculations") using the vehicle's computational resources while the vehicle is not in operation, the objective quality of each computational resource in the grid calculation is required. Therefore, it is undesirable for grid calculations to be started or stopped without the owner or driver's intention. On the other hand, in cases such as commercial vehicles or company cars (hereinafter referred to as "commercial vehicles, etc.") or when a family shares a private car, it is expected that multiple users will share a single vehicle.

In order to improve the objective quality of computing resources, it is possible to query all members who may potentially use a vehicle each time grid computation is started or stopped, but this could become extremely cumbersome and complicated. It is also possible that the vehicle's status may not be known, and in such cases, there is the issue of not being able to make the correct decision to start or stop grid computation.

The technology disclosed here was developed in light of these issues, and aims to eliminate the hassle and complex procedures of inquiring with all members who may potentially use a vehicle, while ensuring the objective quality of computing resources in grid computing.

To solve the above problem, a first aspect of the present disclosure relates to a management method for managing grid computing that utilizes computational resources installed in a vehicle using a management server, the method comprising: a registration process in which the vehicle is equipped with a sensor that recognizes the driver, and a driver candidate for the vehicle, designated by an operator or the owner of the vehicle, is registered in a user table as a registered user; a reservation setting process in which the management server sets a vehicle usage reservation for the date and time designated by the operator or the user of the vehicle in a reservation table that manages the vehicle usage reservation status; and a management user setting process in which, when the sensor confirms that the registered user registered in the reservation table is driving the vehicle on the reservation date and time in the reservation table, the management server sets the registered user who was driving the vehicle immediately before the start of the calculation as the target user who will receive operations to approve the start and stop of grid computing calculations in the vehicle.

According to the first aspect, the target user who accepts the operation to approve the start and stop of grid computing calculations in the vehicle is set to the registered user who was driving immediately before. This ensures the objective quality of computing resources in grid computing, while eliminating the hassle and complex procedures of making inquiries to all members who may potentially use the vehicle.

A second aspect of the present disclosure relates to a management system that uses a management server to manage grid computing utilizing computational resources installed in a vehicle, wherein the vehicle is equipped with a sensor that recognizes the driver, and the management server is equipped with a control unit and a storage unit that stores a user table in which registered users are registered and a reservation table that manages the vehicle's usage reservation status, and the control unit of the management server executes the following steps: a registration process for registering a driver candidate for the vehicle designated by an operator or the owner of the vehicle as the registered user in the user table; a reservation setting process for setting a reservation for the vehicle's usage for a date and time designated by the operator or the user of the vehicle in the reservation table; and a management user setting process for, when the sensor confirms that the registered user registered in the reservation table is driving the vehicle on the reservation date and time in the reservation table, setting the registered user who was driving the vehicle immediately before the start of the calculation as the target user who will receive operations to approve the start and stop of grid computing calculations in the vehicle.

According to the second aspect, as with the first aspect, it is possible to ensure the objective quality of computing resources in grid computing while eliminating the hassle and complex procedures of making inquiries to all members who may potentially use the vehicle.

As explained above, the technology disclosed herein can ensure the objective quality of computing resources in grid computing, while eliminating the hassle and complex procedures of inquiring with all members who may potentially use a vehicle.

FIG. 1 is a schematic diagram illustrating a configuration of a system according to an embodiment. Conceptual diagram to explain grid computing A block diagram illustrating the configuration of a vehicle Block diagram illustrating a client-server configuration Block diagram showing an example of the configuration of a management server 1 is a flowchart showing an example of the operation of a grid computing system. 1 is a flowchart showing an example of the operation of a grid computing system. A flowchart showing an example of a flow for determining a grid start condition.

Embodiments will be described in detail with reference to the drawings. Identical or equivalent parts in the drawings will be designated by the same reference numerals, and repeated explanations may be omitted. Furthermore, the following embodiments will focus on configurations that are highly relevant to the contents of this disclosure. Note that the following embodiments are illustrative, and there is no intention to limit the contents of this disclosure by the presence or absence of descriptions or the numerical values used as examples.

First Embodiment
(Grid Computing System)
FIG. 1 illustrates an example of the configuration of a grid computing system 1 (hereinafter also simply referred to as "system 1") according to an embodiment.

This system 1 includes multiple vehicles 10, multiple client terminals 30, and a management server 50. These components can communicate with each other via a communication network 6. Each of the multiple vehicles 10 is equipped with a computing device 102. The management server 50 is an example of a management device.

[Grid Computing]
As shown in Figure 2, in the system 1 of the embodiment, grid computing (hereinafter also simply referred to as "grid G") is configured using multiple computing devices 102, and grid computing is performed in which an available computing device 102 among the multiple computing devices 102 executes computations on job data D1 of an application job (hereinafter also simply referred to as "job").

When the vehicle 10 is moving, the computing power of the arithmetic device 102 is required to control the driving of the vehicle 10, and the arithmetic device 102 is in an operating state. On the other hand, for example, when the vehicle 10 is parked and the power of the vehicle 10 is turned off, the computing power of the arithmetic device 102 is essentially unnecessary for controlling the driving of the vehicle. Therefore, the above grid calculation is performed when the vehicle 10 is not in operation (for example, when it is parked).

〔vehicle〕
A battery (not shown) is mounted on the vehicle 10. Power from the battery is supplied to on-board devices such as the computing device 102. 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 a communication unit 101, a computing device (processor) 102, a memory unit 103, an occupant sensor 111, a driving operation sensor 112, a vehicle state sensor 113, and a position sensor 114. In the following description, the occupant sensor 111, the driving operation sensor 112, the vehicle state sensor 113, and the position sensor 114 may be collectively referred to as the sensor group 110.

-Communications Department-
The communication unit 101 transmits and receives information and data to and from the management server 50 via the communication network 6. The information and data received by the communication unit 101 is sent to the calculation device 102.

-Arithmetic device-
The arithmetic device 102 controls each part of the vehicle 10. In this example, the arithmetic device 102 controls various actuators (not shown) in accordance with various pieces of information obtained from the sensor group 110. Note that the arithmetic device 102 may include, in addition to a arithmetic device used to control the vehicle 10, a arithmetic device dedicated to grid computing, i.e., a arithmetic device not involved in the control of the vehicle 10.

The computing device 102 has one or more processors and one or more memories. The computing devices 102 may be located in one place within the vehicle, or may be distributed throughout the vehicle. Examples of processors 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, etc.

In this disclosure, for convenience of explanation, resources available for grid computing calculations and processing within the computing device 102 will be referred to as "computing resources."

The computing resources may also be resources used to control the vehicle 10, or a CPU or GPU dedicated to grid computing that is not used to control the vehicle may be used.

Furthermore, for example, there may be separate time periods during which use as a computing resource is permitted and time periods during which use as a computing resource is restricted. In other words, a single CPU may be counted as a computing resource during certain time periods, but not during other time periods. The same applies to GPUs.

Furthermore, if a CPU is implemented with a single or multiple cores, some of the multiple cores may be counted as computing resources, and the remaining cores may not be counted as computing resources. The same applies to GPUs.

-Occupant sensor-
The occupant sensor 111 acquires information necessary for authenticating the driver. The occupant sensor 111 is not particularly limited, but may include, for example, an in-vehicle camera (not shown) installed in a position where it can capture an image of the driver's face. The image captured by the in-vehicle camera is transmitted to the arithmetic device 102. The arithmetic device 102 extracts the facial image of the driver and identifies the driver.

The method for identifying the driver is not particularly limited, but deep learning technology can be used, for example. When using deep learning, the extracted facial image and information about the identified driver are provided as input to a human model. The human model is, for example, a trained model generated by deep learning.

The occupant sensor 111 may be a biometric information sensor such as an iris recognition sensor, fingerprint sensor, voiceprint sensor, or body measurement sensor. The driver may also be identified by combining images from an in-vehicle camera with information acquired by the above sensors.

The authentication unit that authenticates the driver can be realized, for example, by an occupant sensor and the computing device 102. Note that information acquired by the occupant sensor 111 may be sent to the management server 50, and some or all of the functions of the computing device 102 may be realized by the control unit 502 of the management server 50. However, more secure processing can be achieved by completing the functions of the authentication unit within the vehicle.

- Driving operation sensor -
The driving operation sensor 112 detects the driving operation of the driver. Examples of the driving operation sensor 112 include an accelerator position sensor, a shift sensor, a brake sensor, and a steering angle sensor. The detection signal from the driving operation sensor 112 is transmitted to the arithmetic unit 102. A parking detection unit that detects the parking state can be realized by the driving operation sensor 112 and the arithmetic unit 102. For example, when a brake sensor detects that the parking brake is applied and a shift sensor detects that the shift lever is set to park, the arithmetic unit 102 determines that the vehicle 10 is in a parked state. Note that the arithmetic unit 102 may detect the parking state based on composite information, such as detection information from a position sensor 114 and a vehicle state sensor 113 (described later) in addition to the driving operation sensor 112.

- Vehicle condition sensor -
The vehicle state sensor 113 acquires the state of the vehicle 10. The vehicle state sensor 113 is composed of, for example, a vehicle speed sensor, an acceleration sensor, a yaw rate sensor, etc. A detection signal from the driving operation sensor 112 is transmitted to the arithmetic device 102. As described above, the vehicle state sensor 113 may constitute part of the parking detection unit.

The vehicle state sensor 113 includes a sensor that detects the door lock state of the vehicle 10. Specifically, the vehicle state sensor 113 includes a lid sensor that detects the open/closed state of the doors, the locked state of the doors provided on the vehicle, the open/closed state of the hood, and the position of the lift gate and the open/closed state of the trunk. The lid sensor is an example of a lock detection unit that detects the door lock state.

Note that the specific form of the lock detection unit is not limited to a lid sensor. For example, if a door lock actuator is activated based on a lock signal from a keyless entry device or immobilizer authentication device, it may be determined that the vehicle's doors are locked based on the activation of that actuator.

- Position sensor -
The position sensor 114 uses a Global Positioning System (GPS) to detect the position (vehicle position information) of the vehicle 10. The information acquired by the driving operation sensor 112 is transmitted to the computing device 102.

As mentioned above, the vehicle state sensor 113 may constitute part of the parking detection unit. Specifically, for example, the computing device 102 may determine that the vehicle is parked if the location where the vehicle is confirmed to be parked by a driving operation sensor or the like is a parking area such as a parking lot, and may not determine that the vehicle is parked if the parking area is a no-parking area such as an intersection.

-Storage part-
The storage unit 103 stores various types of information and data. The specific configuration of the storage unit 103 is not particularly limited. For example, the storage unit 103 may be realized by a memory built into a chip, a hard disk drive (HDD), a solid state drive (SSD), or an optical disc such as a DVD or a BD.

In this example, the storage unit 103 stores vehicle information D10 and user information D20. The vehicle information D10 includes basic vehicle information D11, vehicle condition information D13, and operation information D15.

<Vehicle basic information>
The vehicle basic information D11 includes vehicle identification information and resource information.

Vehicle identification information includes information for identifying the vehicle, such as the VIN.

Resource information is information related to computational resources (such as CPUs and GPUs). Resource information includes, for example, a computational resource ID assigned to each computational resource and performance information indicating the performance of each computational resource. Computational resource performance includes the computational capacity of the computational resource (specifically, maximum computational capacity), the ratio of CPUs to GPUs in the computational resource, and so on. The computational capacity of a computational resource is, for example, the amount of data that each computational resource can calculate per unit time.

<Vehicle status information>
The vehicle state information D13 is information indicating the state of the vehicle 10, and includes, for example, vehicle position information, vehicle communication information, vehicle power source information, and the like.

Vehicle position information indicates the position (latitude and longitude) of the vehicle 10. For example, the vehicle position information is obtained by the position sensor 114.

The vehicle communication information includes information indicating the communication status between the vehicle 10 and the communication network 6, and information about the communication bandwidth between the vehicle 10 and the management server 50. The vehicle communication information is updated, for example, at predetermined intervals.

Vehicle power source information includes information indicating the power source status of the vehicle 10, vehicle battery remaining capacity information, vehicle charging information, etc. For example, vehicle power source information indicates whether the ignition power is on/off, whether the accessory power is on/off, etc. Vehicle battery remaining capacity information indicates the remaining capacity of a battery (not shown) installed in the vehicle 10. Vehicle charging information indicates whether the vehicle 10 is being charged at a charging facility (not shown).

<Operation information>
The operation information D15 includes, for example, vehicle driving information indicating the driving history of the vehicle 10, operation history information indicating the operation history of the calculation device 102, and operation schedule information indicating the operation schedule of the calculation device 102.

Vehicle driving information, for example, indicates the position of the vehicle 10 in association with the time. In addition to driving history information, driving schedule information indicating future driving schedules for the vehicle 10 may also be included.

Operation history information indicates, for example, the utilization rate of the computing resources of the computing device 102 and/or the amount of job processing performed, in association with time. Operation history information includes normal operation history and grid operation history. Normal operation history is information indicating the history of operation of the computing device 102 for user use, such as providing services such as vehicle driving, car navigation, and music playback. Grid operation history is information indicating the history of operation of the computing device 102 to perform grid computing processing.

Operation plan information indicates, for example, planned usage information that indicates the future usage status of the computing device 102.

<User Information>
The user information D20 is information relating to driver candidates who may drive the vehicle (hereinafter referred to as "registered users"), and includes, for example, primary user information D21 and secondary user information D22.

The primary user information D21 is information about the primary user who is the main user registered to the vehicle 10. For example, in the case of a commercial vehicle, the primary user is the employee who primarily uses the commercial vehicle, or the employee who uses it most frequently.

The primary user information D21 includes information for identifying the primary user. Information for identifying the primary user includes, for example, a photograph of the primary user taken in advance, and the primary user's iris information, fingerprint information, and/or voiceprint information that has been registered in advance. The primary user information D21 is updated when the primary user changes. For example, in the case of a commercial vehicle, the information is updated when the driver changes. The primary user's contact information (for example, the email address of the terminal device 40 owned by the primary user) may also be registered as the primary user information D21.

Secondary user information D22 is information about users (referred to as "secondary users") other than the primary user registered to the vehicle 10 who may drive the vehicle. Secondary user information D22 includes information for identifying the secondary user. Information for identifying the secondary user includes, for example, a pre-taken photograph of the secondary user, and pre-registered iris information, fingerprint information, and/or voiceprint information of the secondary user. Secondary user information D22 can be updated by adding or deleting information. For example, the owner of the vehicle 10 can add or delete family members or friends as secondary users, or in the case of a commercial vehicle, employees who may drive the vehicle can be registered as secondary users. The secondary user information D22 may also include the secondary user's contact information (for example, the email address of the terminal device 40 owned by the secondary user).

All potential driver candidates may be managed without distinguishing between primary and secondary users. The primary and secondary users registered in user information D20 are examples of registered users.

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

As shown in FIG. 4, the client terminal 30 includes a communication unit 301, a memory unit 303, and a control unit 302.

-Communications Department-
The communication unit 301 is connected to the management server 50 so as to be capable of two-way communication, and transmits and receives information and data therebetween. The information and data received by the communication unit 301 are sent to the control unit 302.

-Arithmetic section-
The control unit 302 controls each unit of the client terminal 30. The control unit 302 has one or more processors, one or more memories, etc. The memories store programs for operating the processors, information and data indicating the processing results of the processors, etc.

-Storage part-
The storage unit 303 stores information and data. In this example, the storage unit 303 stores client information D31 and job data D1.

<Client Information>
The client information D31 is information about the client, and includes a client ID set for the client, a client terminal ID set for the client terminal 30 owned by the client, a person in charge's name, address, telephone number, etc.

<Job Data>
The job data D1 is data corresponding to a job and is processed to execute the job.

Job data D1 can be classified by calculation type. Examples of calculation types include CPU-based calculation types and GPU-based calculation types. 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 Information>
Job information D32 relating to the job is stored in association with the job data D1. The job information D32 includes, for example, job name information, job content information, job data calculation type, processing conditions, required calculation capacity, and job delivery date information.

[Management Server]
The management server 50 manages the operation of grid computing. In other words, the system 1 includes the management server 50. The management server 50 is owned by the operator that operates the system 1.

As shown in FIG. 5, the management server 50 includes a communication unit 501, a control unit 502, and a storage unit 503. The management server 50 includes one or more processors and one or more memories.

-Communications Department-
The communication unit 501 is connected to the vehicle 10 and the client terminal 30 so as to be able to perform two-way communication, and transmits and receives information and data therebetween. The information and data received by the communication unit 501 are sent to the control unit 502.

-Storage part-
Various types of information and data are stored in the storage unit 503. There are no particular limitations on the specific configuration of the storage unit 503. For example, the storage unit 503 may be realized by a memory built into a chip, a hard disk drive (HDD), a solid state drive (SSD), or an optical disc such as a DVD or BD.

In this example, the memory unit 503 stores a vehicle information table D51, a job table D53, a matching table D55, a user table D56, job data D1, and calculation result data D2.

<Vehicle Information Table>
The vehicle information table D51 is a table for managing vehicle information, and stores, for example, a list of vehicle information D10 for each vehicle.

<Job Table>
The job table D53 is a table for managing jobs requested by clients. For each job, the job table D53 registers the reception number assigned to the job, the client ID assigned to the client that requested the job, the name and content of the job, and the like. The job table D53 also registers, for each job, the calculation type and processing conditions of the job data D1 corresponding to the job, the required computing power required to calculate the job data D1, the delivery date assigned to the job, and the like. In the job table D53, each piece of job data D1 is linked so that it is clear which client requested the job.

Matching Table
The matching table D55 is a table for managing the results of matching in the matching process. For each job, the matching table D55 registers the reception number set for that job, the job data ID set in the job data D1 corresponding to that job, the vehicle identification information of the vehicle assigned to that job data by the matching process, and the like.

<User table>
The user table D56 is a table for managing registered users (e.g., primary users and secondary users) of each vehicle 10. The user table D56 stores, for example, the vehicle identification information of each vehicle, the identification information of the primary user of each vehicle, and the identification information of the secondary user of each vehicle, linked together in a list. The form of the primary user's identification information and the secondary user's identification information is not particularly limited, but may be, for example, an identification ID assigned to each user, or the name of each user. The user table also stores contact information for the primary user and secondary users.

When implementing part of the authentication unit's functions in the management server 50, it is necessary to store information equivalent to user information D20 (information necessary to identify the primary user based on data such as photographs and biometric information received from the vehicle) in the memory unit 503.

Reserved Table
The reservation table D57 is a table for managing vehicle use reservations. For example, if the vehicle 10 is a commercial vehicle or the like that a specific company allows its employees (hereinafter referred to as "users") to use, the reservation table D57 is a table for managing reservations for the use of the commercial vehicle or the like. Note that if a specific user is designated as the regular user, the user may be registered as the main user, and only the use of other users may be managed in the reservation table D57.

<Job Data>
The job data D1 stored in the storage unit 503 is data of a job accepted from a client terminal in a job acceptance process, which will be described later.

<Calculation result data>
The calculation result data D2 stored in the storage unit 503 is data of the calculation result of a job executed in each vehicle 10 by grid computing processing, which will be described later.

-Control section-
In this example, the control unit 502 has the function of executing a series of controls and processes related to the operation and management of grid computing. For example, it executes the controls and processes in the flow diagram of Fig. 7 described below. Note that in the following explanation, for the sake of convenience, the operations and processes are described with the management server 50 as the main body, but there are cases in which the control unit 502 contributes to the processes and controls.

The control unit 502 stores information and data received from the client terminal 30 in the storage unit 503. For example, when the control unit 502 receives job data D1 from the client terminal 30, it saves the job data D1 in the storage unit 503. Furthermore, when the control unit 502 receives job information D32 from the client terminal 30, it registers it in the job table D53 in the storage unit 503.

The control unit 502 stores information and/or data received from each vehicle 10 and/or the primary user's terminal device 40 in the memory unit 503. For example, when the control unit 502 receives vehicle information D10 (including vehicle driving information and resource information) from a vehicle 10, it registers the information in the vehicle information table D51 in the memory unit 503. Furthermore, when the control unit 502 receives notification of the addition/deletion of a secondary user from the primary user's terminal device 40, it updates the user information in the user table D56.

[Grid Computing System Operation]
An example of the operation of the grid computing system will be described below with reference to the flowcharts in Figures 6 to 8. Figure 6 is a flowchart that focuses on the operation of the vehicle and the control and processing within the vehicle. Figure 7 is a flowchart that describes the same operation as Figure 6 from the perspective of cooperation between the vehicle and the management device, and cooperation between the management device and the terminal device owned by the main user. In Figures 6 and 7, the same processes are assigned the same symbols. Figure 8 also shows an example of a determination flow for grid start conditions.

--Step S11 (S41, S51)--
In step S11, the driver candidate designated by the vehicle owner is registered as a registered user in the vehicle's user table.

For example, the vehicle owner may set the occupant sensor 111 installed in the vehicle cabin to a registration mode for registering registered users, and the primary user's information may be registered while the vehicle is stopped or in motion. Registration may also be performed using a terminal device 40 owned by the primary user.

The primary user's registration information is stored as user information D20 in the memory unit 103. The primary user's contact information may also be registered in the vehicle 10. There are no particular limitations on the registration method, and any conventionally known method can be used.

As shown in step S51, the management server 50 registers driver candidates designated by an operator as registered users in the user table D56 for vehicles managed by the management server 50. For example, if the management server 50 is installed in a company, the operator registers driver candidates who may drive commercial vehicles owned by the company as registered users in the user table D56. In this example, as shown in FIG. 1, primary user P11 is registered as a registered user in vehicle 11, and primary user P21 and secondary user P22 are registered as registered users in vehicle 12.

The primary user of the vehicle 10 may be registered in the management server 50 from the terminal device 40. That is, a vehicle driver candidate designated by the vehicle owner may be registered in the management server 50 as a registered user.

--Steps S12 and S13--
In step S12, the ignition power of the vehicle 10 is turned on (in the case of an electric vehicle, the drive power is turned on), and the vehicle 10 starts traveling. In the next step S13, the calculation device 102 recognizes the driver of the traveling vehicle based on input information from the sensor group 110 from the time the vehicle starts traveling until it is parked. Then, if the driver driving the vehicle matches a registered user who has been registered in advance, the driver is set as an administrative user who can perform approval procedures and change procedures for grid calculations for that vehicle.

--Step S14--
In step S14, for example, when the vehicle 10 enters a parking area in a parking lot, the ignition power is turned off (or the drive power is turned off in the case of an electric vehicle), and the vehicle changes from a traveling state to a parked state. Then, the parking detection unit (for example, the driving operation sensor 112 and the vehicle state sensor 113) detects that the vehicle is parked, and the flow proceeds to the next step S15.

--Step S15--
In step S15, the arithmetic device 102 determines whether a grid start condition is satisfied. Specifically, for example, the grid start condition is set such that, in a state where the parking detection unit detects that the vehicle is parked, after it is confirmed that the driver has exited the vehicle, the lock detection unit detects that the vehicle doors are locked.

Figure 8 shows an example of a determination flow for grid start conditions. In the example of Figure 8, the computing device 102 performs the determinations of steps S151 to S154 in parallel. In step S151, the lid sensor is used to determine whether the door is open or closed. In step S152, the lid sensor is used to determine whether the door is locked. In step S153, the lid sensor is used to determine whether the hood is open or closed. In step S154, the lid sensor is used to determine the position of the lift gate and whether the trunk is open or closed.

In the next step S155, the calculation device 102 determines the door lock status of the vehicle 10 based on the determination results of steps S151 to S154. For example, if the passenger compartment is closed and the doors are locked, the calculation device 102 determines that the door lock status determination result is OK, i.e., that the grid start condition is met. In this example, the calculation device 102 determines that the grid start condition is met if it detects that all doors are closed in step S151, all doors are locked in step S152, the hood is closed in step S153, and the lift gate is in the closed position and the trunk is closed in step S154. If the determination result in step S155 is OK, the flow proceeds to the next step S16 (see Figure 6).

--Steps S17 to S20--
6 and 7, in step S17, the computing device 102 transmits to the management server 50 a request to inquire of the management user about starting grid computing.

More specifically, in step S52 of FIG. 7, when the management server 50 receives the above-mentioned inquiry request from the vehicle 12, it references the user table D56 in the memory unit 503 and sends a confirmation message to the contact information of the registered user (management user) who was currently driving, asking whether it is okay to perform grid calculations on the vehicle 12.

In step S42, when the terminal device 40 receives the above confirmation message from the management server 50, it displays the message on the display screen and accepts a response from the administrative user. When the terminal device 40 acquires response information from the administrative user, it transmits the response result to the management server.

In step S53, when the management server 50 receives the management user's response result from the terminal device 42, it transmits the content to the vehicle 10.

In the vehicle, the next step S18 determines whether or not permission for use has been granted by the administrative user. Figure 7 shows an example in which the administrative user has granted permission for grid calculations on the vehicle 10.

In step S54, the control unit 502 of the management server 50 transmits job data D1 for the requested application job to the vehicle 12. Note that the management server 50 may transmit the job data D1 to the vehicle 12 after receiving a transmission request from the vehicle 12, as in the case of FIG. 7.

In step S22, the calculation device 102 receives job data D1 from the management server 50. Thereafter, the calculation device 102 starts grid calculation using the job data D1 (step S23). When the grid calculation is completed (step S23), the calculation device 102 transmits the calculation results to the management server 50 (step S24). When the calculation results from the calculation device 102 are received by the management server 50, the series of processes ends. Note that if there is sufficient parking time, the process of step S20 may be repeated.

On the other hand, if the response received by the management server 50 in step S53 does not permit grid calculations in the vehicle 12, a determination is made in step S18 of FIG. 6 that permission is not granted, and the process ends without grid calculations being performed in the vehicle 12.

The above embodiments may be combined as appropriate. The above embodiments are essentially preferred examples and are not intended to limit the scope of the technology disclosed herein, its applications, or its uses. In other words, the above 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 equivalent scope of the claims are within the scope of the present disclosure.

As explained above, the technology disclosed here is useful as a technology for managing grid computing.

10 Vehicle 50 Management server (management device)
101 Communication unit 111 Occupant sensor (sensor)
112 driving operation sensor (parking detection unit)
113 Vehicle state sensor (parking detection unit, lock detection unit)
501 Communication unit 503 Storage unit D56 User table D57 Reservation table

Claims (2)

A management method for managing grid computing utilizing computing resources mounted on a vehicle using a management server, comprising:
The vehicle is provided with a sensor that recognizes the driver,
a registration step in which a control unit of the management server registers a driver candidate of the vehicle designated by an operator or an owner of the vehicle in a user table as a registered user;
a reservation setting step in which a control unit of the management server sets a reservation for use of the vehicle for a date and time designated by an operator or a user of the vehicle in a reservation table that manages the vehicle use reservation status;
a management user setting step in which, when the sensor confirms that the vehicle is being driven by a registered user registered in the reservation table at the reservation date and time of the reservation table, the control unit of the management server sets the target user who is to receive an operation approving the start and stop of grid computing calculations in the vehicle to the registered user who was driving immediately before the start of calculations;
How to manage grid computing. A management system for managing grid computing utilizing computing resources mounted on a vehicle using a management server,
The vehicle is equipped with a sensor for recognizing a driver;
The management server
A control unit;
a storage unit that stores a user table in which registered users are registered and a reservation table that manages vehicle use reservation status;
The control unit of the management server
a registration step of registering a driver candidate of the vehicle designated by an operator or an owner of the vehicle in the user table as the registered user;
a reservation setting step of setting in the reservation table a reservation for use of the vehicle for a date and time designated by an operator or a user of the vehicle;
and executing an administrative user setting step of setting, when the sensor confirms that the vehicle is being driven by a registered user registered in the reservation table at the reservation date and time in the reservation table, the registered user who was driving the vehicle immediately before the start of the calculation as a target user who is to receive an operation approving the start and stop of grid computing calculation in the vehicle.
Grid computing management system.