Resource allocation method and device, and computer program

Abstract

This resource allocation method can flexibly provide various functions. The resource allocation method provides a driving assist function to a vehicle-mounted device through communication with a server. The vehicle-mounted device is of a switch-type and switches between resources of a service-providing device with jurisdiction over an area traveled by the vehicle in which the vehicle-mounted device is mounted, and vehicle resources, which are the resources in the vehicle, and allocates the resources for functions of the vehicle-mounted device. The resource allocation method includes: a step in which a computer executes an allocation process for allocating resources of a server, which is a service-providing device with jurisdiction over an area traveled by the vehicle, and resources in the vehicle for functions of the vehicle-mounted device; and a step in which the computer re-executes the allocation process in response to the detection or prediction of a change in the number of vehicles that are present in a travel area and that are linking to the server.

Description

[Technical Field]

[0001] This disclosure relates to a resource allocation method and apparatus, and a computer program. This application claims priority to Japanese Patent Application No. 2022-093583, filed on June 9, 2022, and incorporates by reference all of the contents of that application. [Background technology]

[0002] In the case of an on-board device having a driving assistance function, the available computing resources may change. For example, if a part of a vehicle's equipment breaks down, the function that the equipment was responsible for becomes unavailable from the on-board device. In such a case, it becomes necessary to allocate other computing resources to the lost function. Patent Document 1, listed below, discloses a technology for reallocating computing resources in such a case. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-93090 Summary of the Invention

[0004] A resource allocation method according to a first aspect of this disclosure is a resource allocation method in an in-vehicle device that provides driving assistance functions by communicating with a server, wherein the in-vehicle device is a switchable in-vehicle device that switches between resources of a service providing device that is in charge of the driving area of ​​the vehicle in which the in-vehicle device is installed and resources of the vehicle itself, which is the vehicle in which the in-vehicle device is installed, and allocates these to each function of the in-vehicle device, and the resource allocation method includes a step in which a computer executes an allocation process that allocates resources of a server that is the service providing device that is in charge of the driving area of ​​the vehicle in question and resources of the vehicle itself to each function of the in-vehicle device, and a step in which the computer re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the driving area and that cooperate with the server.

[0005] A resource allocation device according to a second aspect of the present disclosure is a resource allocation device in an on-board device that provides driving assistance functions by communicating with a server, wherein the on-board device is a switchable on-board device that switches between resources of a server that is in charge of the driving area of ​​the vehicle on which the on-board device is mounted and resources of the vehicle itself, which is the vehicle on which the on-board device is mounted, and allocates these to each function of the on-board device, and the resource allocation device includes an allocation execution unit that executes an allocation process that allocates the resources of the server that is in charge of the driving area of ​​the vehicle itself and the resources of the vehicle itself to each function of the on-board device, and an allocation re-execution unit that re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the driving area and that cooperate with the server.

[0006] A computer program according to a third aspect of this disclosure is a computer program that causes a computer to function to allocate resources in an in-vehicle device that provides driving assistance functions by communicating with a server, wherein the in-vehicle device is a switchable in-vehicle device that switches between resources of a server that is in charge of the driving area of ​​the vehicle in which the in-vehicle device is installed and resources of the vehicle itself that is the vehicle in which the in-vehicle device is installed, and allocates these to each function of the in-vehicle device, and the computer program causes the computer to function as an allocation execution unit that executes an allocation process that allocates the resources of the server that is in charge of the driving area of ​​the vehicle itself and the resources of the vehicle itself to each function of the in-vehicle device, and an allocation re-execution unit that re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the driving area and that are in communication with the server. The above and other objects, features, aspects and advantages of the present invention will become apparent from the following detailed description of the invention taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a diagram showing the technological development stages of an in-vehicle edge server (hereinafter simply referred to as an "in-vehicle edge"). [Figure 2] FIG. 2 is a block diagram showing a schematic configuration of a vehicle system of a vehicle participating in a cooperative system according to a first embodiment of the present disclosure. [Figure 3] FIG. 3 is a diagram illustrating an example of a cooperative system according to the first embodiment. [Figure 4] FIG. 4 is a hardware block diagram of a computer that realizes the in-vehicle edge of the vehicle system shown in FIG. [Figure 5] FIG. 5 is a block diagram showing a functional configuration of the in-vehicle edge shown in FIG. [Figure 6] FIG. 6 is a diagram showing types of server configurations and their characteristics in a table format. [Figure 7] FIG. 7 is a diagram showing, in a table format, switching patterns of cooperation between the in-vehicle edge and the server according to combinations of the type of vehicle present around the vehicle, the change in the state of vehicle movement, and the state of server resources. [Figure 8] FIG. 8 is a flowchart showing a schematic configuration of a program executed by the in-vehicle edge device. [Figure 9] FIG. 9 is a flowchart showing a control structure of a program for reallocating resources in a switchable in-vehicle edge device that can switch resources between the host vehicle and a server. [Figure 10] FIG. 10 is a flowchart showing the first half of the control structure of the program executed when there is a switching type nearby vehicle in the flowchart shown in FIG. [Figure 11] FIG. 11 is a flowchart showing the second half of the control structure of the program executed when there is a switching type nearby vehicle in the flowchart shown in FIG. [Figure 12] FIG. 12 is a flowchart showing the first half of the control structure of the program executed when there is no switching type nearby vehicle in the flowchart shown in FIG. [Figure 13] FIG. 13 is a flowchart showing the second half of the control structure of the program executed when there is no switching type nearby vehicle in the flowchart shown in FIG. [Figure 14] FIG. 14 is a diagram showing, in a table format, resource allocation for real-time applications and non-real-time applications in a switching-type vehicle with respect to the configuration of the server to which switching is made. [Figure 15] FIG. 15 is a flowchart showing a control structure of a program for switching a resource for a certain function from the host vehicle to the server in a switching-type in-vehicle device. [Figure 16] FIG. 16 is a diagram showing, in a table format, the server resource status and resource allocation for real-time applications and non-real-time applications for resource coordination with surrounding vehicles. [Figure 17] FIG. 17 is a flowchart showing a control structure of a program for performing resource coordination with switchable surrounding vehicles. [Figure 18] FIG. 18 is a flowchart showing a control structure of a program for switching resources using an edge server (hereinafter referred to as an "edge"). [Figure 19] FIG. 19 is a flowchart showing a control structure of a program for priority processing with switchable surrounding vehicles, related to the real-time application. [Figure 20] FIG. 20 is a flowchart showing a control structure of a program for priority processing with switchable surrounding vehicles, related to non-real-time applications. [Figure 21] FIG. 21 is a flowchart showing a control structure of a program for switching resources not using edges. DETAILED DESCRIPTION OF THE INVENTION

[0008] [Problem to be solved by this disclosure] According to the technology disclosed in Patent Document 1, it is possible to obtain an effect that functions can be allocated to a computing resource of a different type from the computing resource that has become unavailable to the in-vehicle device.

[0009] However, it is predicted that the spread of in-vehicle devices with driving assistance functions will accelerate in the future. Meanwhile, it is also expected that the functions required of in-vehicle devices will become more diverse. For example, due to limitations on vehicle hardware, it is conceivable that functions will emerge that cannot be realized depending on the computing resources available to the in-vehicle device. The technology disclosed in Patent Document 1 cannot adequately address such issues.

[0010] Therefore, an object of this disclosure is to provide a resource allocation method and device, and a computer program, that can flexibly provide various functions.

[0011] [Effects of this disclosure] As described above, according to this disclosure, it is possible to provide a resource allocation method, device, and computer program that can flexibly provide a variety of functions.

[0012] [Description of the embodiments of the present disclosure] In the following description and drawings, the same components are denoted by the same reference numerals, and therefore detailed description thereof will not be repeated. Note that any one or more of the following features may be combined.

[0013] (1) A resource allocation method according to a first aspect of this disclosure is a resource allocation method in an in-vehicle device that provides driving assistance functions by communicating with a server, wherein the in-vehicle device is a switchable in-vehicle device that switches between resources of a service providing device that is in charge of the driving area of ​​the vehicle in which the in-vehicle device is installed and resources of the vehicle itself that is the vehicle in which the in-vehicle device is installed, and allocates these resources to each function of the in-vehicle device, and the resource allocation method includes a step in which a computer executes an allocation process that allocates resources of a server that is the service providing device that is in charge of the driving area of ​​the vehicle and resources of the vehicle itself to each function of the in-vehicle device, and a step in which the computer re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the driving area and that cooperate with the server.

[0014] This configuration allows for flexible allocation of resources between the server and the vehicles to realize each function in response to changes in the number of vehicles that are connected to the server within the travel area, making it possible to flexibly provide a variety of functions for the vehicles.

[0015] (2) In (1) above, the re-execution step may include a step in which the computer determines whether each vehicle present in the surrounding area, including the driving area and the adjacent area adjacent to the driving area, is a standalone vehicle that does not cooperate with the service providing device, a cooperative vehicle that cooperates with the service providing device using a fixed allocation of resources, or a switchable vehicle equipped with a switchable on-board device; a first determination step in which the computer determines whether or not a vehicle other than a standalone vehicle exists in the surrounding area; and a step in which the computer, in response to the determination in the first determination step that a vehicle other than a standalone vehicle exists in the surrounding area, executes a process to reallocate the resources of the vehicle and the resources of the server to each function of the on-board device in accordance with the resources available in the server.

[0016] This configuration allows for flexible allocation of resources between the server and the vehicles to realize each function depending on the number of vehicles that are linked to the server, regardless of the number of standalone vehicles in the surrounding area, making it possible to flexibly provide a variety of functions for the vehicles.

[0017] (3) In (2) above, the step of executing the reallocation process may include a second determination step in which the computer determines whether there are any switchable vehicles other than the host vehicle in the surrounding area; a first reallocation execution step in which the computer, in response to a positive determination in the second determination step, executes a process to reallocate the server resources and the host vehicle resources to each function of the in-vehicle device based on the result of adjustment regarding the server resources with the switchable vehicles present in the surrounding area and the status of the resources available on the server; and a second reallocation execution step in which the computer, in response to a negative determination in the second determination step, executes a process to reallocate the server resources and the host vehicle resources to each function of the in-vehicle device based on the status of the resources available on the server.

[0018] This configuration allows the server and the vehicle to flexibly allocate resources for implementing each function according to the number of nearby inter-vehicles, regardless of the number of independent vehicles and cooperative vehicles in the driving area, thereby enabling a variety of functions to be flexibly provided for the vehicle.

[0019] (4) In the above (3), the first reallocation execution step may include a first detection step in which the computer detects or predicts an increase in the number of linked vehicles or switchable vehicles present in the driving area in response to a positive determination in the second determination step; a third determination step in which the computer determines whether or not there will be a shortage of server resources in response to the detection or prediction of an increase in the number of linked vehicles or switchable vehicles present in the driving area in the first detection step; and a step in which the computer adjusts the server resources with switchable vehicles present in the surrounding area in response to a positive determination result in the third determination step, and switches at least a portion of the server resources allocated to the functions of the in-vehicle device to resources of the vehicle itself based on the results of the adjustment.

[0020] With this configuration, regardless of the number of standalone vehicles in the driving area, in response to detecting or predicting an increase in the number of switchable vehicles and linked vehicles in the driving area, server resources that are predicted to decrease can be adjusted between vehicles and the vehicle's resources can be allocated to some functions. As a result, by cooperating with other switchable vehicles, resources for realizing each function can be flexibly allocated between the server and the vehicle. As a result, various functions can be flexibly provided for the vehicle.

[0021] (5) In the above (4), the first reallocation execution step may further include a second detection step in which the computer detects or predicts a decrease in the number of linked vehicles or switchable vehicles present in the driving area in response to a positive determination in the second determination step; a fourth determination step in which the computer determines whether there will be spare resources in the server in response to the detection or prediction of a decrease in the number of linked vehicles or switchable vehicles present in the driving area in the second detection step; and a step in which the computer adjusts the server resources with switchable vehicles present in the surrounding area in response to a positive determination result in the fourth determination step, and switches at least a portion of the resources of the vehicle that were allocated to the functions of the in-vehicle device to the server resources based on the results of the adjustment.

[0022] With this configuration, regardless of the number of standalone vehicles in the driving area, when a decrease in the number of switchable vehicles and linked vehicles in the driving area is detected or predicted, the server adjusts and distributes the surplus resources between the vehicles, thereby newly allocating server resources to some of the functions that were previously allocated to the host vehicle. As a result, resources for realizing each function can be flexibly allocated between the server and the host vehicle, reducing the burden on the host vehicle. As a result, various functions can be flexibly provided for the vehicle.

[0023] (6) In the above (3), the first reallocation execution step may include a second detection step in which the computer detects or predicts a decrease in the number of linked vehicles or switchable vehicles present in the driving area in response to a positive determination in the second determination step; a third determination step in which the computer determines whether there will be spare resources in the server in response to the detection or prediction of a decrease in the number of linked vehicles or switchable vehicles present in the driving area in the second detection step; and a step in which the computer switches at least a portion of the resources of the vehicle that were allocated to the functions of the in-vehicle device to the resources of the server in response to a positive determination result in the third determination step.

[0024] With this configuration, regardless of the number of standalone vehicles in the driving area, when a decrease in the number of switchable vehicles and linked vehicles in the driving area is detected or predicted, the server adjusts and distributes the surplus resources between the vehicles, thereby newly allocating server resources to some of the functions that were previously allocated to the host vehicle. As a result, resources for realizing each function can be flexibly allocated between the server and the host vehicle, reducing the burden on the host vehicle. As a result, various functions can be flexibly provided for the vehicle.

[0025] (7) In any one of (3) to (6) above, the second reallocation execution step includes an area increase detection step in which the computer detects or predicts an increase in the number of linked vehicles present in the driving area in response to a negative determination in the second determination step; a first server resource determination step in which the computer determines whether or not there will be a shortage of server resources in response to the detection or prediction of an increase in the number of linked vehicles present in the driving area in the area increase detection step; and a step in which the computer switches at least a portion of the server resources allocated to the functions of the in-vehicle device to resources of the vehicle in response to a positive determination result in the first server resource determination step.

[0026] With this configuration, regardless of the number of standalone vehicles in the driving area, when an increase in the number of linked vehicles in the driving area is detected or predicted, the server's resources that are predicted to decrease can be adjusted and allocated among the vehicles, thereby newly allocating the vehicle's resources to some of the functions that were previously allocated to the server's resources.As a result, even if the number of linked vehicles in the driving area increases, the resources for realizing each function can be flexibly allocated between the server and the vehicle, reducing the server's burden.As a result, various functions can be flexibly provided for the vehicles.

[0027] (8) In the above (7), the second reallocation execution step may further include an area decrease detection step in which the computer detects or predicts a decrease in the number of linked vehicles present in the travel area in response to a negative determination in the first server resource determination step; a second server resource determination step in which the computer determines whether there is an excess of server resources in response to the detection or prediction of a decrease in the number of linked vehicles present in the travel area in the area decrease detection step; and a step in which the computer switches at least a portion of the resources of the vehicle that have been allocated to the functions of the in-vehicle device to the resources of the server in response to a positive determination result in the second server resource determination step.

[0028] With this configuration, when there is a surplus in the server's resources, some of the vehicle's resources that were allocated to executing the function are released, and the server's resource As a result, the burden on the vehicle can be reduced and various functions for the vehicle can be flexibly provided.

[0029] (9) In any one of (3) to (6) above, the second reallocation execution step may include an area decrease detection step in which the computer detects or predicts a decrease in the number of linked vehicles present in the driving area in response to a negative determination in the second determination step; a first server resource determination step in which the computer determines whether there is an excess of server resources in response to the detection or prediction of a decrease in the number of linked vehicles present in the driving area in the area decrease detection step; and a step in which the computer switches at least a portion of the resources of the vehicle that were allocated to the functions of the in-vehicle device to the resources of the server in response to a positive determination result in the first server resource determination step.

[0030] With this configuration, when there is a surplus in the server's resources, some of the vehicle's resources that were allocated to executing the function are released, and the server's resource As a result, the burden on the vehicle can be reduced and various functions for the vehicle can be flexibly provided.

[0031] (10) In any one of (5), (6), (8) and (9) above, the server in the travel area may include at least a first server, the functions of the in-vehicle device may include a first function and a second function that requires a faster response than the first function, and the step of switching to the server resources may include a server configuration determination step of determining whether the server in the travel area further includes a second server that has a faster response than the first server, and a step of allocating the resources of the vehicle to the second function and the resources of the first server to the first function in response to the determination in the server configuration determination step that the server does not include the second server.

[0032] This configuration allows the resources of the second server, rather than the vehicle itself, to be allocated to functions that require a fast response, thereby reducing the load on the vehicle itself and enabling the flexible provision of various functions for the vehicle.

[0033] (11) In any one of (5), (6), (8) and (9) above, the step of switching to the server resources may further include a step of allocating the resources of the first server to the first function and the resources of the second server to the second function in response to the server configuration determination step determining that the server includes a second server.

[0034] This configuration allows the resources of the second server, rather than the vehicle itself, to be allocated to functions that require a fast response, and the resources of the first server to functions that do not require a fast response, thereby reducing the load on the vehicle itself and enabling the flexible provision of various functions for the vehicle.

[0035] (12) In any one of (5), (6), (8) and (9) above, the server in the travel area may include at least a first server, the functions of the in-vehicle device may include a first function and a second function that requires a faster response than the first function, and the step of switching to the server resources may include a server configuration determination step of determining whether the server in the travel area further includes a second server that has a slower response than the first server, and a step of allocating the resources of the first server to the first function and the second function in response to the determination in the server configuration determination step that the server does not include the second server.

[0036] This configuration allows the vehicle's resources to be allocated to functions that require a fast response, and the first server's resources to functions that do not. By allocating the first server's resources to functions that do not require a fast response, the vehicle's resources can be effectively used for functions that do require a fast response. As a result, various functions for the vehicle can be flexibly provided while reducing the load on the vehicle.

[0037] (13) In (12) above, the step of switching to the server resources may further include a step of allocating the resources of the second server to the first function and the resources of the first server to the second function in response to the server configuration determination step determining that the server includes a second server.

[0038] This configuration allows the resources of the second server to be allocated to functions that require a fast response, and the resources of the first server to be allocated to functions that do not require a fast response. This allows the vehicle's resources to be allocated to other functions, reducing the load on the vehicle and enabling the flexible provision of various functions for the vehicle.

[0039] (14) In (5) or (6) above, the server in the driving area may include a first server and a second server having a faster response than the first server, and the functions of the in-vehicle device may include a first function and a second function requiring a faster response than the first function, and the step of switching to the server resources may include a step of allocating as many resources of the second server as the second server allows to the second function, a step of allocating as many resources of the first server and resources of the second server as the first server and the second server allow to the first function, and a step of allocating resources of the vehicle to functions among the second functions that cannot be allocated resources of the second server and to functions among the first functions that cannot be allocated resources of either the first server or the second server.

[0040] This configuration allows the second server's resources to be allocated as much as possible to functions that require a fast response. Furthermore, the first server and the second server's resources can be allocated as much as possible to functions that do not require a fast response. This reduces the load on the vehicle, allowing the vehicle's resources to be allocated to other functions. As a result, various functions for the vehicle can be flexibly provided.

[0041] (15) In (14) above, the step of allocating as many resources of the second server as the second server allows to the second functions may include an allocation determination step of determining whether the resources of the second server can be allocated to all of the second functions; a step of allocating the resources of the second server to all of the second functions in response to the determination in the allocation determination step that the resources of the second server can be allocated to all of the second functions; a step of adjusting the allocation of the resources of the second server with other switchable vehicles in the driving area in response to the determination in the allocation determination step that the resources of the second server cannot be allocated to at least some of the second functions, and allocating as many resources of the second server as possible to some of the second functions in accordance with the result of the adjustment; and a step of allocating resources of the vehicle to those second functions that cannot be allocated resources of the second server as a result of the adjustment.

[0042] As a result of this configuration, if the resources of the second server can be allocated to all of the second functions that require a fast response, the resources of the second server can be allocated to all of the second functions without the need for coordination with other vehicles. This leaves excess resources in the host vehicle, allowing for the realization of a variety of other functions. Even if the resources of the second server cannot be allocated to some of the second functions, coordination with other switching vehicles allows the second server's resources to be effectively used for vehicles within the driving area, and as many of the second server's resources as possible can be allocated to the functions of the host vehicle. As a result, the resources of the second server can be effectively used not only for the host vehicle but also for other vehicles within the driving area, allowing for the provision of a variety of functions.

[0043] (16) In (14) or (15) above, the step of allocating as many resources of the first server and resources of the second server to the first function as the first server and the second server allow may include an additional determination step of determining whether the resources of the first server can be allocated to all of the first functions; a step of allocating the resources of the first server to all of the first functions in response to the determination in the additional determination step that the resources of the first server can be allocated to all of the first functions; a step of adjusting the allocation of the resources of the first server between other linked vehicles and switchable vehicles in the driving area in response to the determination in the additional determination step that the resources of the first server cannot be allocated to at least some of the first functions, and allocating as many resources of the first server as possible to some of the first functions in accordance with the results of the adjustment; and a step of allocating resources of the vehicle to those first functions that cannot be allocated resources of the first server as a result of the adjustment.

[0044] As a result of this configuration, if the resources of the first server can be allocated to all of the first functions, the resources of the first server can be allocated to all of the first functions without the need for coordination with other vehicles. This leaves spare resources in the host vehicle, allowing for the realization of a variety of other functions. Even if the resources of the first server cannot be allocated to some of the first functions, the resources of the first server can be effectively used for vehicles within the driving area by coordinating with other switching vehicles. Furthermore, the host vehicle can allocate as many resources of the first server as possible to the first function of the host vehicle, and then allocate its own resources to the remaining first functions. As a result, the resources of the first server can be effectively used not only for the host vehicle but also for other vehicles within the driving area, allowing for the provision of a variety of functions, including the first function.

[0045] (17) A resource allocation device according to a second aspect of this disclosure is a resource allocation device in an on-board device that provides driving assistance functions by communicating with a server, wherein the on-board device is a switchable on-board device that switches between resources of a server that is in charge of the driving area of ​​the vehicle on which the on-board device is mounted and resources of the vehicle itself, which is the vehicle on which the on-board device is mounted, and allocates these to each function of the on-board device, and the resource allocation device includes: an allocation execution unit that executes an allocation process that allocates the resources of the server that is in charge of the driving area of ​​the vehicle itself and the resources of the vehicle itself to each function of the on-board device; and an allocation re-execution unit that re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the driving area and that cooperate with the server.

[0046] This configuration allows for flexible allocation of resources between the server and the vehicles to realize each function in response to changes in the number of vehicles that are connected to the server within the travel area, making it possible to flexibly provide a variety of functions for the vehicles.

[0047] (18) A computer program according to a third aspect of this disclosure is a computer program that causes a computer to function to allocate resources in an in-vehicle device that provides driving assistance functions by communicating with a server, wherein the in-vehicle device is a switchable in-vehicle device that switches between resources of a server that has jurisdiction over the driving area of ​​the vehicle in which the in-vehicle device is installed and resources of the vehicle itself, which is the vehicle in which the in-vehicle device is installed, and allocates these to each function of the in-vehicle device, and the computer program causes the computer to function as an allocation execution unit that executes an allocation process that allocates the resources of the server that has jurisdiction over the driving area of ​​the vehicle itself and the resources of the vehicle itself to each function of the in-vehicle device, and an allocation re-execution unit that re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the driving area and that are linked to the server.

[0048] This configuration allows for flexible allocation of resources between the server and the vehicles to realize each function in response to changes in the number of vehicles that are connected to the server within the travel area, making it possible to flexibly provide a variety of functions for the vehicles.

[0049] [Details of the embodiments of the present disclosure] Specific examples of resource allocation methods, devices, and computer programs according to embodiments of the present disclosure will be described below with reference to the drawings. Note that the present disclosure is not limited to these examples, but is defined by the claims, and is intended to include all modifications within the meaning and scope of the claims.

[0050] 1. First embodiment 1. Background to the disclosure Some driving assistance systems have sensors mounted on vehicles, and all information processing of the sensor data is performed by on-board devices. Because processing of the sensor data is performed at the location where the data is obtained, this method is convenient for processing that must be performed in real time. In this specification, the function of performing information processing for driving assistance in on-board devices is called an on-board edge.

[0051] FIG. 1 schematically shows the technological development stages of a vehicle system equipped with an in-vehicle edge. Referring to FIG. 1, an initial vehicle system 50 includes a standalone in-vehicle edge 60 that is isolated from other vehicles and various sensors (not shown). The standalone in-vehicle edge 60 includes apps that process sensor data from these sensors. These apps run both real-time apps that implement functions essential to vehicle safety and non-real-time apps that do not directly contribute to vehicle safety. In this specification, a vehicle equipped with such a standalone in-vehicle edge 60 is referred to as a standalone vehicle.

[0052] However, such an in-vehicle edge 60 has a problem in that it cannot utilize wide-area information for driving assistance, for example, and there is also a problem in that information obtained from sensors in a vehicle equipped with the in-vehicle edge 60 cannot be used for driving other vehicles.

[0053] The vehicle system 52 in the next development stage compensates for the shortcomings of the standalone vehicle system 50 described above, and includes, in addition to sensors (not shown), an in-vehicle edge 70 that can communicate with a server 72 that has jurisdiction over a predetermined area. The in-vehicle edge 70 executes a real-time application. Meanwhile, the server 72 executes a non-real-time application using sensor data transmitted from the in-vehicle edge 70. The server 72 transmits the execution results of the non-real-time application to the in-vehicle edge 70. The in-vehicle edge 70 uses this information for driving assistance.

[0054] In this way, the in-vehicle edge 70 performs driving assistance processing in cooperation with the server 72. Therefore, the in-vehicle edge 70 is called a cooperative in-vehicle edge. A vehicle equipped with a cooperative in-vehicle edge is called a cooperative vehicle. The cooperative in-vehicle edge is provided inside an in-vehicle gateway (hereinafter referred to as "in-vehicle GW (Gateway)") that communicates between each part in the vehicle and the outside.

[0055] A vehicle system 54 at a more advanced stage than the vehicle system 52 can be considered to be equipped with a switching-type in-vehicle edge 80 capable of communicating with a server 82 and other vehicles. The in-vehicle edge 80 can switch between executing real-time applications and non-real-time applications on the in-vehicle edge 80 or on the server 82. For this purpose, the in-vehicle edge 80 includes a resource control unit for controlling whether to allocate resources of the vehicle (referred to as the host vehicle) equipped with the in-vehicle edge 80 or resources of the server 82 to those applications. A vehicle equipped with such a switching-type in-vehicle edge 80 is called a switching-type vehicle.

[0056] As such, while there are stages of technological development for in-vehicle edge, the in-vehicle edges currently in use in society cannot be uniformly (or simultaneously) replaced by more advanced in-vehicle edges. It is conceivable that vehicles equipped with standalone, linked, and switched in-vehicle edges will coexist on the road. In such cases, various problems may arise regarding server resources.

[0057] 2. Configuration 2A Hardware Configuration For example, the vehicle system 54 shown in FIG. 1 has the following schematic configuration. Referring to FIG. 2, the vehicle system 54 includes a sensor 100, an ECU (Electronic Control Unit) 102, an autonomous driving ECU 104, a wireless communication unit 106 for communicating with a server 82, and an in-vehicle gateway 108 for relaying and distributing communications between each unit of the vehicle system 54 and the server 82 via the wireless communication unit 106. The in-vehicle gateway 108 includes an in-vehicle edge 80. The in-vehicle edge 80 is connected to the sensor 100, the ECU 102, the autonomous driving ECU 104, and the wireless communication unit 106. The in-vehicle edge 80 processes sensor data from the sensor 100 within the in-vehicle edge 80, transmits the sensor data to the server 82 via the wireless communication unit 106, and receives the results of application execution by the server 82. The in-vehicle edge 80 provides such information to the ECU 102, the autonomous driving ECU 104, and the like to assist driving.

[0058] 2 shows only one sensor 100 and one ECU 102. However, in reality, there are one or more different sensors as the sensor 100, and there are one or more ECUs with different functions as the ECU 102. The ECU 102 is essentially a computer, and has the function of executing a specified program and outputting the results to another ECU, or of controlling various parts of the vehicle by executing a program.

[0059] 1 does not include the wireless communication unit 106 in FIG. 2. The vehicle system 52 has the same hardware configuration as FIG.

[0060] 2B Functional configuration Below, we will explain problems that may arise in relation to a vehicle 320 equipped with an in-vehicle edge 80 according to this first embodiment. In the following embodiments, the area in which the vehicle 320 is traveling is referred to as the traveling area. Areas adjacent to the traveling area that are under the jurisdiction of other servers are referred to as adjacent areas. The traveling area and adjacent areas are collectively referred to as the surrounding area. Vehicles traveling within the surrounding area are referred to as surrounding vehicles. There are two types of servers: cloud servers (hereinafter simply referred to as "cloud") and edge servers (hereinafter simply referred to as "edge"). Clouds often handle larger areas than edges. Edges handle smaller regions. Therefore, edges can process requests from each vehicle faster than clouds.

[0061] Referring to FIG. 3 , the driving area of ​​vehicle 320 is assumed to be driving area 300. The server responsible for driving area 300 is assumed to be cloud 304. One of the areas adjacent to driving area 300 is assumed to be adjacent area 302, and the server responsible for adjacent area 302 is assumed to be a combination of cloud 306 and edge 308. Cloud 306 is responsible for a wide area of ​​adjacent area 302, and edge 308 is responsible for a narrow area within adjacent area 302. Cloud 306 processes processing requests from vehicles in adjacent area 302 that cannot communicate with edge 308. Cloud 306 also processes processing requests from edge 308. The area of ​​jurisdiction of edge 308 is originally narrower than the area of ​​jurisdiction of cloud 306, and the time required for communication between each vehicle and edge 308 is also shorter than the time required for communication between each vehicle and cloud 306. Therefore, edge 308 responds to processing requests from each vehicle faster than cloud 306.

[0062] In the example shown in FIG. 3 , other vehicles 322 and 324 exist within vehicle 320's driving area 300. Vehicles 326 and 328 also exist within adjacent area 302. Thus, vehicles other than vehicle 320 that exist within vehicle 320's driving area and other driving areas adjacent to that driving area are, as described above, peripheral vehicles for vehicle 320. At least the server responsible for each area determines whether the vehicles within each area are standalone vehicles, linked vehicles, or switchable vehicles, along with vehicle information such as their location, movement speed, and vehicle type. Information about such vehicles is exchanged between servers responsible for adjacent areas. Therefore, each server determines and manages at least the location, movement direction, and speed (collectively referred to as vehicle movement status) of vehicles within its own area and adjacent areas, as well as their vehicle types. As a result, for example, if vehicle 320 wants to know the type and vehicle movement status of peripheral vehicles, it can simply inquire of cloud 304.

[0063] FIG. 4 shows the hardware configuration of an MCU (Micro Controller Unit) constituting the in-vehicle edge 80. Referring to FIG. 4, the MCU includes an MPU (Micro-Processing Unit) 402, which is a processor; a high-speed bus 400 to which the MPU 402 is connected; an SRAM (Static Random Access Memory) 404 connected to the high-speed bus 400; a flash memory 406 connected to the high-speed bus 400; and a ROM (Read-Only Memory) 408 connected to the high-speed bus 400. The SRAM 404 holds data necessary for program execution. The flash memory 406 stores a program 426 including programs (including both real-time applications and non-real-time applications) for implementing functions realized by the in-vehicle edge 80, programs for resource control, and the like. The ROM 408 stores a boot-up program for the MPU 402 and the like.

[0064] The MCU further includes a low-speed bus 410 connected to the high-speed bus 400 via a bridge 412, a serial I / F (Interface) 414, an ADC (Analog-to-Digital Converter) 416, a timer / counter 418, a clock generator 420, a power supply control unit 422, and a general-purpose I / F 424, all of which are connected to the low-speed bus 410.

[0065] The operation of the MCU is well known, and what is meaningful in the embodiment is the function of the program that it executes, so the operation of the MCU itself will not be described below.

[0066] 5 is a block diagram showing the functional configuration of the in-vehicle edge 80. Referring to Fig. 5, functionally, the in-vehicle edge 80 includes an initial allocation unit 452 for initially allocating resources of the vehicle or a communicable server to each function realized by the in-vehicle edge 80 when the in-vehicle edge 80 is started up, and a communication processing unit 450 connected to the wireless communication unit 106 shown in Fig. 2.

[0067] The in-vehicle edge 80 further includes a change detection unit 454 connected to the communication processing unit 450 for detecting or predicting changes (increases and decreases) in the number of switchable vehicles and linked vehicles within the driving area 300, and a reallocation unit 456 for reallocating the resources of the vehicle and the server to the apps provided by the in-vehicle edge 80 in accordance with the changed situation in response to the change detection unit 454 detecting or predicting a change.

[0068] The in-vehicle edge 80 further includes an application storage unit 462 for storing real-time applications and non-real-time applications, and an application control unit 458 for controlling the execution of applications so that the applications read from the application storage unit 462 are executed by the allocated resources (the vehicle or the server) in response to the initial allocation of resources by the initial allocation unit 452 and the reallocation of resources by the reallocation unit 456. The in-vehicle edge 80 further includes an application execution unit 460 for executing applications designated by the application control unit 458 to be executed by the resources of the vehicle. The application execution unit 460 includes, for example, the ECU 102 and the autonomous driving ECU 104 shown in FIG. 2 .

[0069] An application designated by application control unit 458 to be executed on the server is transmitted to the server via communication processing unit 450 and wireless communication unit 106 shown in Fig. 2, and executed on the server. Alternatively, application control unit 458 transmits an identifier of the application to the server, whereby an application having equivalent functions is executed on the server.

[0070] The allocation of resources to applications varies depending on the number of linked and switched vehicles in the driving area, and the server configuration. Figure 6 shows in table format the server configuration, the delay characteristics for each server configuration, whether real-time applications can be executed, and the size of the target area (the area under the jurisdiction of the server).

[0071] As shown in FIG. 6, in this embodiment, the server configuration can be any combination of cloud only, cloud and edge, one edge only, and multiple edges and multiple clouds. When using only the cloud, the delay is large, and when using the edge, the delay is small or medium. When using a combination of multiple clouds and multiple edges, the delay varies depending on the combination. Therefore, when the server configuration includes only the cloud, it is not possible to execute a real-time application.

[0072] Figure 7 shows in table format how resources should be switched for each type of vehicle included in the surrounding vehicles, depending on the changes and predictions of vehicle movement related to the driving area and the resource status of the server.

[0073] Referring to the first row of Figure 7, for example, if there are only standalone vehicles and no cooperative or switching vehicles, when a nearby vehicle enters the driving area, the server's resource status does not change. The same applies when a nearby vehicle leaves the driving area, when the host vehicle moves from the driving area to one of the adjacent areas, or when such movement is predicted. Therefore, there is no need to switch resources in the host vehicle (switching vehicle).

[0074] On the other hand, consider the case where there are cooperative vehicles among the surrounding vehicles. Here, the surrounding vehicles may include other independent vehicles, but do not include switching vehicles. In this case, the server resource status and switching patterns when the number of cooperative vehicles in the driving area of ​​the host vehicle increases and decreases are shown in the second and third lines of Figure 7, respectively.

[0075] An example of an increase in the number of linked vehicles in the driving area of ​​the vehicle is when a linked vehicle in an adjacent area enters or is predicted to enter the driving area. Another example is when the vehicle moves or is predicted to move from the current driving area to another adjacent driving area, and there are more linked vehicles in the new area than there are in the current driving area. In this case, the resources available to the server generally decrease, and in some cases, the server resources become unavailable. In this case, the app that was previously allocated server resources must be reallocated to server or vehicle resources, that is, the app must be switched to processing in the vehicle.

[0076] A decrease in the number of linked vehicles in the driving area of ​​the host vehicle occurs, for example, when a linked vehicle in the driving area exits or is predicted to exit the driving area. Another example is when the host vehicle moves or is predicted to move from the current driving area to another adjacent driving area, and the number of linked vehicles in the destination area is fewer than the number of linked vehicles in the current driving area. In this case, the available resources on the server generally increase. In this case, it may be possible to allocate server resources to a non-real-time application that was previously allocated the host vehicle's resources. Therefore, if the server has spare resources, the server's resources can be reallocated to the application that was previously allocated the host vehicle's resources, that is, the application can be switched to processing on the server.

[0077] The information in lines 4, 5, and 6 of Figure 7 can be interpreted in a similar way. However, in this case, other inter-switching vehicles are involved. The other inter-switching vehicles will also attempt to reallocate resources in the same way as the vehicle itself. This may result in conflicts in the reallocation of server resources between inter-switching vehicles. In such cases, resource coordination between inter-switching vehicles is necessary.

[0078] 2C Program Structure FIG. 8 and subsequent figures show the control structure of a program executed by MPU 402 shown in FIG. 4 to realize each function of in-vehicle edge device 80 shown in FIG.

[0079] 8, program 500 includes step 510, which starts communication with the server upon startup, and step 512, which follows step 510 and involves initial allocation of vehicle resources and server resources for each application that implements a function used by the in-vehicle device. The allocation process performed in step 512 may be performed by any method. For example, available resources may be inquired of the server, and resources within the range permitted by the server may be allocated to non-real-time applications, with vehicle resources allocated to the remaining applications. It is assumed that when program 500 is started, the server with which the in-vehicle device starts communication is cloud 304 shown in FIG. 3.

[0080] The program further includes step 514 of downloading vehicle information for a surrounding area including the travel area from the server, and step 516 of re-executing the resource allocation process and returning control to step 514 in response to a change being detected or predicted in the number of cooperative vehicles or switch-type vehicles in the travel area based on the information downloaded in step 514. If no change is involved in the number of cooperative vehicles or switch-type vehicles in the travel area, control returns to step 514.

[0081] 9, step 516 for re-executing the allocation process shown in Fig. 8 has the following control structure: Step 516 includes step 550 for observing and determining the types of edge devices of the surrounding vehicles based on the vehicle information downloaded in step 514, and step 552 for determining, based on the determination result of step 550, whether or not there are any vehicles other than standalone vehicles, i.e., switchable vehicles or linked vehicles, among the surrounding vehicles, and branching the control flow according to the result.

[0082] If it is determined in step 552 that a switching-type vehicle or a cooperative vehicle is present among the surrounding vehicles, control proceeds to step 554. In step 554, the MPU 402 branches the control flow according to whether or not a switching-type vehicle is present among the surrounding vehicles. If a switching-type vehicle is present, control proceeds to step 556, where the MPU 402 executes processing for when a switching-type surrounding vehicle is present, and then ends step 516. If no switching-type vehicle is present, control proceeds to step 558, where the MPU 402 executes processing for when no switching-type surrounding vehicle is present, and then ends step 516.

[0083] If it is determined in step 552 that there are no switching or cooperative vehicles among the surrounding vehicles, the surrounding vehicles are only standalone vehicles and vehicles without an on-board edge. These surrounding vehicles do not use the server's resources. Therefore, there is no need for the MPU 402 to reallocate resources to each function of the host vehicle. Therefore, in this case, the MPU 402 ends the processing of step 516.

[0084] 10, step 556 in Fig. 9 has the following control structure. Step 556 includes step 580, which branches the control flow based on whether the host vehicle is scheduled to move within the area, and step 582, which branches the control flow based on whether the number of switch-type vehicles and linked vehicles in the destination area is equal to or greater than a threshold value when the determination in step 580 is positive. Step 556 further includes step 584, which branches the control flow based on whether a switch-type vehicle or linked vehicle has entered or is expected to enter the traveling area when the determination in step 580 is negative.

[0085] If the determination in step 582 is positive, or if the determination in step 584 is positive, control proceeds to step 586. In step 586, MPU 402 determines whether the server's processing resources are full or are expected to be full, and branches the flow of control accordingly. If the determination in step 586 is negative, step 556 ends. That is, in this case, no resource reallocation is performed.

[0086] If the determination in step 586 is positive, control proceeds to step 588. In step 588, the MPU 402 adjusts the allocation of resources with the switching-type surrounding vehicle. Control then proceeds to step 590, where the MPU 402 performs reallocation processing to allocate the resources of the host vehicle to some or all of the applications that had been allocated the server resources in accordance with the adjustment result in step 588, and ends step 556. Note that, depending on the adjustment result in step 588, there may be cases where resources are not reallocated in step 590.

[0087] 11, if the determination in step 584 in Fig. 10 is negative, control proceeds to step 594 in Fig. 11. In step 594, the MPU 402 determines whether a switching-type vehicle or a linked-type vehicle has exited or is expected to exit the traveling area, and branches the control flow according to the result. If the determination in step 594 is negative, the MPU 402 ends the processing of step 556.

[0088] This program further includes step 596, which is executed when the determination in step 582 shown in Fig. 10 is negative or when the determination in step 594 in Fig. 11 is positive, and determines whether there is or is likely to be a surplus in resources in the server, and branches the control flow according to the result. If the determination in step 596 is negative, the MPU 402 ends step 556. If the determination in step 596 is positive, the MPU 402 adjusts the allocation of switchable surrounding vehicles and server resources in step 598. Furthermore, in step 600, the MPU 402 allocates server resources to part of the application according to the adjustment result in step 598, and ends step 556.

[0089] Fig. 12 shows the control structure of a program that implements step 558 shown in Fig. 9. Referring to Fig. 12, step 558, which implements processing when no switching-type peripheral vehicles are present, includes step 630, which branches the control flow depending on whether the host vehicle is scheduled to move to another driving area, and step 632, which, when the determination in step 630 is positive, determines whether the number of linked vehicles present in the destination area is equal to or greater than a threshold, and branches the control flow depending on the result. Step 558 further includes step 634, when the determination in step 630 is negative, which determines whether a linked-type peripheral vehicle has entered or is expected to enter the driving area, and branches the control flow depending on the result.

[0090] Step 558 further includes step 636, which branches the flow of control depending on whether the server processing resources are full or expected to be full when the determination in step 632 or step 634 is positive. If the determination in step 636 is negative, step 558 ends. If the determination in step 636 is positive, control proceeds to step 638, in which MPU 402 switches some or all of the applications that had been allocated server resources to the vehicle's resources, and step 558 ends.

[0091] Referring to FIG. 13, step 558 further includes step 642, which is executed in response to a negative determination in step 634 of FIG. 12, and branches the flow of control depending on whether the coordinated vehicle has exited or is predicted to exit the driving area.

[0092] If the determination in step 632 is negative or the determination in step 642 is positive, control proceeds to step 644. In step 644, the MPU 402 determines whether there is or is expected to be a surplus in the server's processing resources, and branches the flow of control. If the determination in step 644 is negative, there is no surplus in the server's processing resources, and step 558 ends. If the determination in step 644 is positive, control proceeds to step 646. serverWhen step 646 is completed, step 558 ends. Details of step 646 will be described later with reference to FIG.

[0093] If the determination at step 642 is negative, step 558 is completed.

[0094] Fig. 14 shows in table format the policy by which a switching-type vehicle allocates resources to real-time applications and non-real-time applications depending on the type of server configuration at the switching destination. For example, if the switching destination server includes only a cloud (first row), some clouds may not be able to execute real-time applications. Therefore, the MPU 402 allocates its own vehicle's resources to real-time applications. On the other hand, it generally allocates cloud resources to non-real-time applications.

[0095] As shown in the second row, when the server has a two-tier structure with edge and cloud, the edge can execute real-time applications. Therefore, the vehicle with a switchable architecture allocates edge resources to real-time applications. On the other hand, non-real-time applications can be processed on either the edge or the cloud. Therefore, depending on the available resources, edge resources or cloud resources are allocated to non-real-time applications.

[0096] The fifth line shows the resource allocation policy for a combination of a server with both multiple edges and multiple clouds and a server with only multiple clouds. In this case, when the server configuration includes edges, real-time applications can be executed on the server side (edge). Therefore, the MPU 402 allocates edge resources to real-time applications. However, when the server configuration includes only clouds, real-time applications cannot be executed on the server side. Therefore, in this case, the MPU 402 allocates vehicle resources to real-time applications. In either case, the MPU 402 allocates available server-side resources to non-real-time applications.

[0097] Fig. 15 shows the control structure of the program executed in step 646 of Fig. 13. Referring to Fig. 15, step 646 of switching the resources allocated to the application to the server side includes step 680 of determining whether the server configuration includes an edge and branching the control flow according to the result, and step 684 of allocating the vehicle's resources to the real-time application and the cloud's resources to the non-real-time application in response to a negative determination in step 680. In step 684, it is assumed that the server that has jurisdiction over the driving area of ​​the vehicle equipped with MPU 402 includes the cloud.

[0098] If the determination in step 680 is positive, control proceeds to step 682. In step 682, the MPU 402 determines whether or not the server configuration includes a cloud, and branches the flow of control according to the result.

[0099] If the determination in step 682 is negative, control proceeds to step 686. A negative determination in step 682 means that the server configuration is edge-only. Therefore, in step 686, MPU 402 allocates edge resources to real-time applications and also allocates edge resources to non-real-time applications, and then ends the processing of step 646.

[0100] On the other hand, if the determination in step 682 is affirmative, control proceeds to step 688. If the determination in step 682 is affirmative, the server composition Therefore, in step 688, the MPU 402 allocates edge resources to real-time applications, and allocates edge or cloud resources to non-real-time applications depending on the edge resource situation, and then ends the processing in step 646.

[0101] FIG. 16 shows in table format how a switching-type vehicle allocates resources to each application depending on the resource status of the destination server. Referring to FIG. 16, for example, the first row shows a case where the edge can accept all requests when the MPU 402 makes a resource allocation request to the edge or the cloud. In this case, the cloud does not need to accept the requests. The switching-type vehicle allocates edge resources to real-time applications. The switching-type vehicle also allocates edge resources to non-real-time applications.

[0102] The second line shows the case where the edge can only accept a part of the allocation request. In this case, for real-time applications, the switching-type vehicle (own vehicle) adjusts the priority of resource allocation with the switching-type surrounding vehicles. Based on the adjustment result, the switching-type vehicle allocates edge resources to the part of the real-time application for which edge resources can be allocated. The switching-type vehicle allocates its own vehicle resources to the remaining real-time application.

[0103] On the other hand, when the edge can only accept a portion of the allocation requests, the situation for non-real-time applications can be further divided into three cases depending on the cloud situation. The first is when the cloud can accept all allocation requests. In this case, the switching vehicle allocates cloud resources to all non-real-time applications. The second is when the cloud can accept only a portion of the resource allocation requests. In this case, the switching vehicle adjusts the priority of resource allocation with surrounding switching vehicles. Based on the result of this adjustment, the switching vehicle further allocates cloud resources to the portion of non-real-time applications that the cloud can accept. The switching vehicle allocates its own resources to the remaining non-real-time applications. The third is when the cloud cannot accept the resource allocation requests. In this case, the switching vehicle allocates its own resources to all non-real-time applications.

[0104] The third line shows when the edge cannot accept a resource allocation request. In this case, the vehicle's resources are allocated to all real-time applications regardless of whether the cloud can accept all resource allocation requests. For non-real-time applications, resource allocation differs depending on whether the cloud can accept all, some, or none of the allocation requests. When the cloud can only accept some of the resource allocation requests, the switching vehicle adjusts priorities with surrounding switching vehicles. Based on the results of this adjustment, the switching vehicle allocates cloud resources to the portion of the non-real-time applications for which cloud resources are available. The switching vehicle allocates its own vehicle's resources to the remaining non-real-time applications.

[0105] Fig. 17 shows, in flowchart form, the control structure of a program for implementing switch-type priority adjustment with surrounding vehicles, which is executed in step 588 of Fig. 10 and step 598 of Fig. 11. Referring to Fig. 17, this program includes step 710 for determining whether the edge can accept all resource allocation requests and branching the control flow according to the result of the determination, and step 714 for allocating edge resources to real-time applications and non-real-time applications as well, and terminating the process, when the determination in step 710 is affirmative.

[0106] This program further includes step 712, in which, if the result in step 710 is negative, it is determined whether the edge can only partially accept the resource allocation request, and the control flow branches according to the result. If the determination in step 712 is positive, control proceeds to step 716. In step 716, the MPU 402 allocates resources so as to use the edge. If the determination in step 712 is negative, control proceeds to step 718. In step 718, the MPU 402 allocates resources so as not to use the edge.

[0107] Fig. 18 shows a control structure of a program for realizing the process of allocating resources to use edges, which is performed in step 716 of Fig. 17. Referring to Fig. 18, this program includes step 750 for determining whether the cloud can accept all resource allocation requests and branching the control flow according to the result of the determination, step 754 for making allocations related to real-time applications when the determination in step 750 is positive, and step 756, which follows step 754, for allocating cloud resources to non-real-time applications and ending step 716.

[0108] The program further includes step 752, which branches the control flow according to whether the cloud can accept only a portion of the resource allocation request when the determination in step 750 is negative. When the determination in step 752 is positive, the control proceeds to step 758. When the determination in step 752 is negative, the control proceeds to step 762.

[0109] In step 758, the MPU 402 performs priority processing for real-time applications. In the following step 760, the MPU 402 performs priority processing for non-real-time applications, and then ends step 716. Meanwhile, in step 762, the MPU 402 performs priority processing for real-time applications. In the following step 764, the MPU 402 allocates vehicle resources to the non-real-time applications, and then ends step 716.

[0110] Fig. 19 shows details of a priority processing program for real-time applications that the MPU 402 executes in steps 754, 758, and 762 in Fig. 18. Referring to Fig. 19, this program includes step 800 for exchanging information necessary for determining priorities with switch-type vehicles present in the driving area, and step 802 for determining the priority of each vehicle using the information received from other switch-type vehicles in step 800 and information related to the vehicle itself.

[0111] Various criteria can be used to determine the priority here. For example, one method could be to assign the highest priority to emergency vehicles, the next highest to business vehicle vehicles, and the lowest to private vehicles. Another method could be to charge each vehicle owner a fee for using the server. In this case, the higher the fee, the higher the priority. Another method could be to compare the available resources for each vehicle and assign a higher priority to vehicles with fewer resources. Another method could be to assign a higher priority to vehicles that will be traveling for a longer period of time within the area managed by the server. Another possible method would be to arbitrarily combine these criteria to calculate a score, and assign a higher priority to vehicles with a higher score.

[0112] This program further includes, following step 802, a step 804 in which, following the priority determined in step 802, an operation is repeated to allocate edge resources to real-time applications, starting with the highest priority switching vehicle, as long as edge resources are available, and in the process, edge resources are allocated to the real-time applications of the vehicle itself; and, following step 804, a step 806 in which vehicle resources are allocated to those real-time applications of the vehicle that cannot be allocated edge resources, and the process is terminated.

[0113] Fig. 20 shows details of the priority processing for non-real-time applications executed in step 760 of Fig. 18. Referring to Fig. 20, step 760 includes step 830 in which the MPU 402 exchanges information for determining priorities with other switch-type vehicles in the travel area and other switch-type vehicles predicted to enter the travel area, and step 832 in which the MPU 402 determines the priority of each switch-type vehicle based on the information exchanged in step 830.

[0114] Step 760 further includes step 834 of allocating cloud resources to non-real-time applications in order from the highest priority vehicle to the lowest priority vehicle according to the priorities calculated in step 832, as long as cloud resources are available; and, following step 834, step 836 of allocating vehicle resources to those non-real-time applications of the vehicle that cannot be allocated cloud resources, thereby terminating step 760.

[0115] Figure 21 shows details of step 718 in Figure 17. Referring to Figure 21, step 718 includes step 860, which determines whether the cloud can accept all allocation requests and branches the control flow according to the result. If the determination in step 860 is positive, the MPU 402 allocates vehicle resources to the real-time application in step 864. The MPU 402 further includes step 866, which allocates cloud resources to the non-real-time application in step 866 and ends step 718.

[0116] If the determination in step 860 is negative, the MPU 402 further branches the control flow in step 862 according to whether the cloud can accept only some of the allocation requests. If the determination in step 862 is positive, the control proceeds to step 868. In step 868, the MPU 402 allocates vehicle resources to the real-time application. The MPU 402 further includes step 870, in which priority processing for non-real-time applications is performed and step 718 is terminated. Step 870 is the same as step 760 shown in FIG. 20 .

[0117] If the determination in step 862 is negative, the MPU 402 allocates the vehicle's resources to the real-time application in step 872. The MPU 402 then allocates the vehicle's resources to the non-real-time application in the following step 874, and then ends step 718.

[0118] 3 operations The in-vehicle edge 80 (see FIG. 5), the configuration of which has been described above, operates as follows. Referring to FIG. 8, the initial allocation unit 452 of the vehicle 320 starts communication with a server (for example, the cloud 304 shown in FIG. 3) that has jurisdiction over the area in which the vehicle 320 is located when the in-vehicle edge 80 starts operating (when the processing in FIG. 8 starts) (step 510 in FIG. 8). Based on information obtained from the server, the initial allocation unit 452 performs a process of allocating resources to real-time applications and non-real-time applications of the vehicle 320 by some method (step 512). In accordance with this allocation result, the application control unit 458 Cloud Alternatively, the application to which the edge resource is allocated is read from the application storage unit 462 and transmitted via the communication processing unit 450. Cloud Or send it to the edge and request execution. Cloud An application to which resources of the vehicle are allocated is a non-real-time application. An application to which resources of the edge are allocated may be either a real-time application or a non-real-time application. If there is no edge, the real-time application is allocated resources of the vehicle itself. The application control unit 458 reads out the application to which resources of the vehicle are allocated from the application storage unit 462 and causes the application execution unit 460 to execute it. Thereafter, the in-vehicle edge 80 repeats the process of downloading information about surrounding vehicles and information about driving assistance from the server that has jurisdiction over each driving area (step 514) and reallocating resources to each application based on this information communication (step 516).

[0119] 3, assume that a vehicle 320 is traveling within a travel area 300 and is predicted to move to an adjacent area 302 after a time t1 in its travel schedule. The travel area 300 is under the jurisdiction of a cloud 304. The adjacent area 302 is under the jurisdiction of a cloud 306 and an edge 308 in cooperation with each other.

[0120] In the situation shown in FIG. 3, for example, assume that vehicle 324 within driving area 300 is a single type, and vehicle 322 is a switching type. Vehicle 324 is predicted to exit driving area 300 in the near future. Vehicle 322 is driving behind vehicle 320. Therefore, it is predicted that vehicle 322 will not exit driving area 300 for some time. Also assume that there are switching type vehicles 326 and 328 in adjacent area 302. Among these, vehicle 326 is driving in a direction away from driving area 300. It is predicted by edge 308 and cloud 306 that vehicle 328 will enter driving area 300 from adjacent area 302 after a time t2 has elapsed from the current time. Here, let t2 < t1. Also, it is predicted by edge 308 that vehicle 326 will still remain within adjacent area 302 even after time t1.

[0121] Referring to FIG. 5, change detection unit 454 of vehicle 320 predicts that switching type vehicle 328 will enter driving area 300 after time t2 according to the driving plan. In this case, the number of switching type vehicles within driving area 300 increases from 2 to 3. In response to detecting this change, change detection unit 454 notifies reallocation unit 456 of the increase in switching type vehicles. In response to this notification, reallocation unit 456 executes a resource reallocation process for the real-time app and non-real-time app of vehicle 320. According to the result of this reallocation, app control unit 458 requests the app to which the resource of cloud 304 is allocated among the non-real-time apps to execute on cloud 304, and requests the app to which the resource of vehicle 320 is allocated to execute the app on that resource.

[0122] Similar processing is also performed for vehicles 322 and 328 and vehicle 326 shown in FIG. 3. When vehicle 328 enters driving area 300 from adjacent area 302, the number of switch-type vehicles in vehicle 328's driving area increases from two to three. Therefore, the same processing as for vehicle 320 is performed for vehicles 322 and 328 as described above. For vehicle 326, the number of switch-type vehicles in its driving area decreases from two to one. Therefore, resource reallocation is also performed for vehicle 326. In this case, although it depends on the applications to which vehicle 328 has allocated the resources of cloud 306 and edge 308, vehicle 326 will generally allocate the resources of cloud 306 and edge 308 to more applications.

[0123] Furthermore, suppose that after vehicle 328 enters driving area 300, vehicle 320 moves to adjacent area 302. In this case, the driving area for vehicle 320 changes from driving area 300 to adjacent area 302. The number of switch-type vehicles in vehicle 320's driving area changes from 3 to 2. Therefore, vehicle 320 performs resource reallocation processing. Similarly, vehicle 326 detects that the number of switch-type vehicles in adjacent area 302 has increased from 1 to 2 and performs resource reallocation processing. During this process, priorities are calculated between vehicle 326 and vehicle 320, and based on the results, resources of cloud 306 and edge 308 are reallocated in both vehicle 326 and vehicle 320.

[0124] On the other hand, as a result of vehicle 320 moving to adjacent area 302, the number of switch-type vehicles in driving area 300 decreases from 3 to 2. As a result, resource reallocation processing is also performed for vehicles 322 and 328.

[0125] If the vehicle moving between areas is a standalone vehicle, there will be no change in the resources available to the server. Therefore, in this case, resource reallocation processing will not be performed in the switching vehicle. On the other hand, the situation is different if the vehicle moving between areas is a linked vehicle. If the vehicle entering an area is a linked vehicle, a fixed amount of server resources will be allocated to that linked vehicle. Conversely, if the vehicle leaving an area is a linked vehicle, a fixed amount of server resources will become available. Therefore, in either of these cases, if a linked vehicle is present in the area, resource reallocation processing will be performed.

[0126] As described above, according to this embodiment, in the switching-type vehicle, reallocation of server resources for applications and vehicle resources is performed in response to changes in the number of linked vehicles and switching-type vehicles present in the driving area. As a result, by flexibly allocating server resources among the applications of the vehicles, it is possible to effectively utilize server resources, reduce the processing load on each vehicle, and flexibly provide various functions.

[0127] Second Variation In the above embodiment, the switching vehicle obtains information such as vehicle movement status of surrounding vehicles through a server. However, this disclosure is not limited to such an embodiment. The switching vehicle may obtain information such as vehicle movement status of surrounding vehicles directly through so-called vehicle-to-vehicle communication with other vehicles. In this case, however, for standalone vehicles and vehicles that do not even have an on-board edge, at least the vehicle movement status must be obtained through a server or calculated based on sensor data of the vehicle itself. Alternatively, the switching vehicle may obtain information such as vehicle movement status of other vehicles through communication with so-called infrastructure equipment such as roadside devices.

[0128] Each process (each function) in the above-described embodiments is realized by a processing circuit including one or more processors. The processing circuit may be configured by an integrated circuit that combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute the respective processes. The one or more processors may execute the respective processes according to the programs read from the one or more memories, or may execute the respective processes using logic circuits pre-designed to execute the respective processes. The processor may be any of various processors suitable for computer control, such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), or an ASIC (Application Specific Integrated Circuit). Note that the plurality of physically separate processors may execute the respective processes in cooperation with each other. For example, the processors mounted on a plurality of physically separated computers may cooperate with each other to execute the above processes via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, etc. The program may be installed into the memory from an external server device or the like via the network, or may be distributed in a state stored on a recording medium such as a CD-ROM (Compact Disc Read-Only Memory), a DVD-ROM (Digital Versatile Disc Read-Only Memory), or a semiconductor memory, and installed into the memory from the recording medium.

[0129] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present disclosure is not defined by the detailed description of the disclosure, but by the claims of the appended claims, and is intended to include all modifications within the scope and meaning equivalent to the wording of the claims. [Explanation of symbols]

[0130] 60, 70, 80 Automotive Edge 72, 82 servers 100 sensors 102 ECU 104 Autonomous Driving ECU 106 Radio Communication Department 108 Automotive GW 300 driving area 302 Adjacent Area 304, 306 Cloud 308 Edge 320, 322, 324, 326, 328 vehicles 400 Express Bus 402 MPU 404 SRAM 406 Flash Memory 408 ROM 410 Slow Bus 412 Bridge 414 Serial I / F 416 ADC 418 Timer Counter 420 Clock Generator 422 Power supply control unit 424 General-purpose I / F 426, 500 programs 450 Communication Processing Unit 452 Initial Allocation Section 454 Change Detection Unit 456 Reassignment Department 458 Application control unit 460 Application execution unit 462 App Memory

Claims

1. A resource allocation method in an in-vehicle device that provides a driving assistance function through communication with a server, comprising: the in-vehicle device is a switching-type in-vehicle device that switches between resources of a service providing device that has jurisdiction over a driving area of ​​a vehicle equipped with the in-vehicle device and resources of the vehicle itself that is the vehicle equipped with the in-vehicle device, and assigns the resources to each function of the in-vehicle device; The resource allocation method includes: a step of executing an allocation process by a computer to allocate resources of a server that is a service providing device that has jurisdiction over the driving area of ​​the vehicle and resources of the vehicle to each function of the in-vehicle device; A resource allocation method comprising a step in which the computer re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the driving area and that are linked to the server.

2. The step of re-executing includes: A step in which a computer determines whether each vehicle present in a surrounding area including the travel area and an adjacent area adjacent to the travel area is a standalone vehicle that does not cooperate with a service providing device, a cooperative vehicle that cooperates with a service providing device using a fixed allocation of resources, or a switched-type vehicle equipped with the switched-type on-board device; a first determination step in which the computer determines whether or not a vehicle other than the standalone vehicle is present in the surrounding area; 2. The method of claim 1, further comprising: a step in which, in response to determining in the first determination step that a vehicle other than the standalone vehicle is present in the surrounding area, the computer executes a process of reallocating resources of the vehicle and resources of the server to each function of the in-vehicle device in accordance with resources available in the server.

3. The step of performing the reallocation process includes: a second determination step in which the computer determines whether or not there is another switching-type vehicle other than the host vehicle in the surrounding area; a first reallocation execution step in which, in response to a positive determination in the second determination step, the computer executes a process of reallocating the resources of the server and the resources of the host vehicle to each function of the in-vehicle device based on a result of coordination regarding the resources of the server with the switch-type vehicles present in the surrounding area and a status of resources available in the server; 3. The method according to claim 2, further comprising: a second reallocation execution step in which, in response to a negative determination in the second determination step, the computer executes a process of reallocating the resources of the server and the resources of the vehicle to each function of the in-vehicle device based on the status of resources available in the server.

4. The first reallocation execution step includes: a first detection step in which the computer detects or predicts an increase in the number of the cooperative vehicles or the switch-type vehicles present in the traveling area in response to a positive determination in the second determination step; a third determination step in which the computer determines whether resources of the server will be insufficient in response to the detection or prediction of an increase in the number of the cooperative vehicles or the switchable vehicles present in the traveling area in the first detection step; 4. The method of claim 3, further comprising: a step in which, in response to a positive judgment result in the third judgment step, the computer performs coordination regarding the server's resources with the switchable vehicles present in the surrounding area, and switches at least a portion of the server's resources allocated to the functions of the in-vehicle device to the resources of the vehicle based on the result of the coordination.

5. The first reallocation execution step further includes: a second detection step in which the computer detects or predicts a decrease in the number of the cooperative vehicles or the switchable vehicles present in the travel area in response to a positive determination in the second determination step; a fourth determination step in which the computer determines whether there is a surplus in the server's resources in response to the detection or prediction of a decrease in the number of the linked vehicles or the switchable vehicles present in the traveling area in the second detection step; 5. The method of claim 4, further comprising a step in which, in response to a positive determination result in the fourth determination step, the computer executes coordination regarding the server's resources with the switchable vehicles present in the surrounding area, and switches at least a portion of the vehicle's resources allocated to the functions of the in-vehicle device to the server's resources based on the results of the coordination.

6. The first reallocation execution step includes: a second detection step in which the computer detects or predicts a decrease in the number of the cooperative vehicles or the switchable vehicles present in the travel area in response to a positive determination in the second determination step; a third determination step in which the computer determines whether there is a surplus in the server's resources in response to the detection or prediction of a decrease in the number of the linked vehicles or the switchable vehicles present in the traveling area in the second detection step; 4. The method according to claim 3, further comprising a step of: in response to a positive determination result in the third determination step, switching at least a portion of the resources of the vehicle that were allocated to the functions of the in-vehicle device to resources of the server.

7. The second reallocation execution step includes: an in-area increase detection step in which the computer detects or predicts an increase in the number of the cooperative vehicles present within the traveling area in response to a negative determination in the second determination step; a first server resource determination step in which the computer determines whether or not resources of the server will be insufficient in response to the detection or prediction of an increase in the number of linked vehicles present within the travel area in the area increase detection step; 7. The method according to claim 3, further comprising: a step in which, in response to a positive determination result in the first server resource determination step, the computer switches at least a portion of the resources of the server that were assigned to the functions of the in-vehicle device to resources of the vehicle.

8. The second reallocation execution step further includes: an in-area decrease detection step in which the computer detects or predicts a decrease in the number of the cooperative vehicles present within the traveling area in response to a negative determination in the first server resource determination step; a second server resource determination step in which the computer determines whether there is a surplus in the server resources in response to the detection or prediction of a decrease in the number of linked vehicles present within the travel area in the area decrease detection step; 8. The method according to claim 7, further comprising a step of: in response to a positive determination result in the second server resource determination step, switching at least a portion of the resources of the vehicle that were allocated to the functions of the in-vehicle device to resources of the server.

9. The second reallocation execution step includes: an in-area decrease detection step in which the computer detects or predicts a decrease in the number of the cooperative vehicles present within the traveling area in response to a negative determination in the second determination step; a first server resource determination step in which the computer determines whether there is a surplus in the server resources in response to the detection or prediction of a decrease in the number of the cooperative vehicles present in the traveling area in the area decrease detection step; 7. The method according to claim 3, further comprising: a step in which, in response to a positive determination result in the first server resource determination step, the computer switches at least a portion of the resources of the vehicle that were allocated to the functions of the in-vehicle device to the resources of the server.

10. The servers in the travel area include at least a first server; the functions of the in-vehicle device include a first function and a second function that requires a faster response than the first function; The step of switching to the resource of the server comprises: a server configuration determination step of determining whether the servers in the travel area further include a second server having a faster response than the first server; 7. The method according to claim 5, further comprising: in response to determining in the server configuration determination step that the server does not include the second server, allocating resources of the vehicle to the second function and allocating resources of the first server to the first function.

11. 11. The method of claim 10, wherein the step of switching to the resources of the server further includes a step of allocating the resources of the first server to the first function and the resources of the second server to the second function in response to the server configuration determination step determining that the server includes the second server.

12. The servers in the travel area include at least a first server; the functions of the in-vehicle device include a first function and a second function that requires a faster response than the first function; The step of switching to the resource of the server comprises: a server configuration determination step of determining whether the servers in the travel area further include a second server whose response is slower than that of the first server; 7. The method of claim 5, further comprising: in response to determining in the server configuration determination step that the server does not include the second server, allocating resources of the first server to the first function and the second function.

13. 13. The method of claim 12, wherein the step of switching to the resources of the server further includes the step of allocating resources of the second server to the first function and resources of the first server to the second function in response to the server configuration determination step determining that the server includes the second server.

14. the servers in the travel area include a first server and a second server that has a faster response than the first server; the functions of the in-vehicle device include a first function and a second function that requires a faster response than the first function; The step of switching to the resource of the server comprises: allocating as many resources of the second server as the second server allows to the second function; allocating to the first function as many resources of the first server and the second server as the first server and the second server allow; 7. The method of claim 5 or claim 6, further comprising a step of allocating resources of the vehicle to functions among the second functions to which resources of the second server are not allocated, and to functions among the first functions to which resources of neither the first server nor the second server are allocated.

15. The step of allocating resources of the second server to the second function as much as the second server allows, an allocation determination step of determining whether resources of the second server are allocated to all of the second functions; a step of allocating resources of the second server to all of the second functions in response to a determination that resources of the second server are allocated to all of the second functions in the allocation determination step; a step of adjusting allocation of the resources of the second server among other switch-type vehicles in the traveling area in response to the determination in the allocation determination step that the resources of the second server are not allocated to at least a part of the second function, and allocating as many of the resources of the second server as possible to the part of the second function according to a result of the adjustment; The method according to claim 14 , further comprising the step of allocating resources of the host vehicle to functions among the second functions to which resources of the second server are not allocated as a result of the adjustment.

16. The step of allocating resources of the first server and resources of the second server to the first function as much as the first server and the second server allow, an additional determining step of determining whether all of the first functions are allocated resources of the first server; a step of allocating resources of the first server to all of the first functions in response to the determination in the additional determination step that resources of the first server are allocated to all of the first functions; in response to the determination that the resources of the first server are not allocated to at least a part of the first function in the additional determination step, adjusting allocation of the resources of the first server among the other linked vehicles and the switch-type vehicles in the traveling area, and allocating as many of the resources of the first server as possible to the part of the first function according to a result of the adjustment; The method according to claim 14 , further comprising the step of: allocating resources of the host vehicle to functions among the first functions to which resources of the first server are not allocated as a result of the adjustment.

17. A resource allocation device in an in-vehicle device that provides a driving assistance function through communication with a server, the on-board device is a switching-type on-board device that switches between resources of a server that has jurisdiction over a driving area of ​​a vehicle equipped with the on-board device and resources of the vehicle itself, which is the vehicle equipped with the on-board device, and assigns the resources to each function of the on-board device; the resource allocation device, an allocation execution unit that executes an allocation process to allocate resources of a server that has jurisdiction over the driving area of ​​the host vehicle and resources of the host vehicle to each function of the in-vehicle device; and an allocation re-execution unit that re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the travel area and that are linked to the server.

18. A computer program that causes a computer to function to allocate resources in an in-vehicle device that provides a driving assistance function through communication with a server, the on-board device is a switching-type on-board device that switches between resources of a server that has jurisdiction over a driving area of ​​a vehicle equipped with the on-board device and resources of the vehicle itself, which is the vehicle equipped with the on-board device, and assigns the resources to each function of the on-board device; The computer program causes a computer to: an allocation execution unit that executes an allocation process to allocate resources of a server that has jurisdiction over the driving area of ​​the host vehicle and resources of the host vehicle to each function of the in-vehicle device; A computer program that functions as an allocation re-execution unit that re-executes the allocation process in response to detecting or predicting a change in the number of vehicles that are present in the travel area and that are linked to the server.

Images