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

Resource allocation method and device, and computer program

[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.

[0002] In the case of an in-vehicle 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 in-vehicle device. In such a case, it becomes necessary to allocate other computing resources to the lost function. Patent Document 1, cited below, discloses a technology for reallocating computing resources in such a case.

[0003] Japanese Patent Application Laid-Open No. 2021-93090

[0004] A resource allocation method according to a first aspect of this disclosure is a resource allocation method 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 service providing device that has jurisdiction over 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 resources to each function of the on-board 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 has jurisdiction over the driving area of ​​the vehicle and resources of the vehicle itself to each function of the on-board 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 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 within the driving area and that cooperate with the server.

[0006] A computer program according to a third aspect of the present disclosure is a computer program that causes a computer to function as an in-vehicle device that provides a driving assistance function by communicating with a server, the in-vehicle device being a switchable in-vehicle device that switches between resources of a server that manages the driving area of ​​the vehicle equipped with the in-vehicle device and resources of the vehicle equipped with the in-vehicle device to allocate resources 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 manages the driving area of ​​the vehicle equipped with the in-vehicle device and the resources of the vehicle equipped with the in-vehicle device 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 cooperate 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 present invention taken in conjunction with the accompanying drawings.

[0007] FIG. 1 is a diagram showing the technological development stage of an in-vehicle edge server (hereinafter simply referred to as "in-vehicle edge"). 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. FIG. 3 is a diagram showing an example of a cooperative system according to the first embodiment. FIG. 4 is a hardware block diagram of a computer realizing the in-vehicle edge of the vehicle system shown in FIG. 2. FIG. 5 is a block diagram showing the functional configuration of the in-vehicle edge shown in FIG. 4. FIG. 6 is a diagram showing, in a table format, types of server configurations and their features. FIG. 7 is a diagram showing, in a table format, switching patterns of collaboration between the in-vehicle edge and the server in accordance with combinations of the types of vehicles present around the vehicle, changes in vehicle movement, and server resource status. FIG. 8 is a flowchart showing a schematic configuration of a program executed by the in-vehicle edge. FIG. 9 is a flowchart showing the control structure of a program for reallocating resources in a switchable in-vehicle edge that can switch resources between the vehicle itself and a server. FIG. 10 is a flowchart showing the first half of the control structure of a program executed when a switchable nearby vehicle is present in the flowchart shown in FIG. 9. FIG. 11 is a flowchart showing the second half of the control structure of a program executed when a switchable nearby vehicle is present in the flowchart shown in FIG. 9. FIG. 12 is a flowchart showing the first half of the control structure of a program executed when there are no switching-type surrounding vehicles in the flowchart shown in FIG. 9 . FIG. 13 is a flowchart showing the second half of the control structure of a program executed when there are no switching-type surrounding vehicles in the flowchart shown in FIG. 9 . FIG. 14 is a diagram showing, in a table format, resource allocation of real-time applications and non-real-time applications in a switching-type vehicle with respect to the configuration of a switching destination server. FIG. 15 is a flowchart showing the control structure of a program for switching resources for a certain function from the host vehicle to the server in a switching-type in-vehicle device. 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. FIG. 17 is a flowchart showing the control structure of a program for resource coordination with switching-type surrounding vehicles. FIG. 18 is a diagram showing a control structure of an edge server (hereinafter referred to as "edge").19 is a flowchart showing a control structure of a program for priority processing with switching type surrounding vehicles for real-time applications. FIG. 20 is a flowchart showing a control structure of a program for priority processing with switching type surrounding vehicles for non-real-time applications. FIG. 21 is a flowchart showing a control structure of a program for resource switching without using an edge.

[0008] [Problem to be Solved by the Present Disclosure] The technology disclosed in Patent Document 1 has the effect of being able to allocate functions to a different type of computing resource 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 problems.

[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 the Present 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 various 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. 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 for 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 has jurisdiction over a driving area of ​​a vehicle equipped with the in-vehicle device and resources of the vehicle equipped with the in-vehicle device, and allocates the 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 a service providing device that has jurisdiction over the driving area of ​​the vehicle and resources of the vehicle equipped with the in-vehicle device 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 the above (1), 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 an 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 in-vehicle device; a first determination step in which the computer determines whether or not a vehicle other than a standalone vehicle is present 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 is present 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 in-vehicle device in accordance with the resources available on 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 the above (2), 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 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 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 linked vehicles or 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 or not there will be a shortage of server resources in response to the detection or prediction of an increase in linked vehicles or switchable vehicles present in the travel 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 adjustment result.

[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 travel 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 travel area in the second detection step; and a step in which the computer adjusts the resources of the server 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 resources of the server 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 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 an excess in the server's resources in response to the detection or prediction of a decrease in the number of linked vehicles or switchable vehicles present in the travel 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 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 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 travel 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 travel 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 the server has spare resources, some of the vehicle's resources that were allocated to executing functions can be released and the server's functions can be allocated instead, reducing the burden on the vehicle and enabling the flexible provision of various functions for the vehicle.

[0029] (9) In any one of (3) to (6) above, the second reallocation execution step may include an in-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 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 travel area in the in-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 first server resource determination step.

[0030] With this configuration, when the server has spare resources, some of the vehicle's resources that were allocated to executing functions can be released and the server's functions can be allocated instead, reducing the burden on the vehicle and enabling the flexible provision of various functions for the vehicle.

[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 in response to the server configuration determination step determining that the server does not include the second server, allocating the resources of the vehicle to the second function and allocating the resources of the first server to the first function.

[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 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 be allocated to functions that do not require a fast response, thereby reducing the load on the vehicle 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] With this configuration, the vehicle's resources can be allocated to functions that require a fast response, and the first server's resources can be allocated to functions that do not require a fast response. 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 vehicle functions can be flexibly provided while reducing the load on the vehicle.

[0037] (13) In the above (12), 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 determination in the server configuration determination step that the server includes the second server.

[0038] With this configuration, the resources of the second server can be allocated to functions that require a fast response, and the resources of the first server can be allocated to functions that do not require a fast response. The resources of the vehicle can be further allocated to other functions, and various functions for the vehicle can be flexibly provided while reducing the load on the vehicle.

[0039] (14) In the above (5) or (6), the servers in the travel 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 to which resources of the second server cannot be allocated and to functions among the first functions to which neither resources of the first server nor resources of the second server can be allocated.

[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 the above (14), 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 switch-type vehicles in the traveling 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-type vehicles allows the second server's resources to be effectively used by vehicles in the driving area, while still allocating as many of the second server's resources as possible 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 in the driving area, allowing for the provision of a variety of functions.

[0043] (16) In the above (14) or (15), 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 traveling 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 result 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 travel area by coordinating with other switching-type vehicles. Furthermore, the host vehicle can allocate as many resources of the first server as possible to its own first function, 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 travel 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 in-vehicle device that provides a driving assistance function 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 mounted and resources of the vehicle itself that is the vehicle in which the in-vehicle device is mounted, and allocates the resources to each function of the in-vehicle device, and the resource allocation device includes: 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 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 a driving assistance function 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 that is the vehicle in which the in-vehicle device is installed, and allocates the resources 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 cooperate with 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 a resource allocation method and device, and a computer program 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 of 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. Since processing of the sensor data is performed at the location where the data is obtained, this method is convenient for processing that needs to be performed in real time. In this specification, the function of performing information processing for driving assistance in on-board devices in this way 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 execute both real-time apps that implement functions essential to vehicle safety and non-real-time apps that do not directly contribute to vehicle safety. A vehicle equipped with such a standalone in-vehicle edge 60 is referred to as a standalone vehicle in this specification.

[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 also has a problem in that information obtained from sensors of 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 capable of communicating 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 cooperation-type in-vehicle edge. A vehicle equipped with a cooperation-type in-vehicle edge is called a cooperation-type vehicle. The cooperation-type in-vehicle edge is provided inside an in-vehicle gateway (hereinafter referred to as an "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, other vehicles, etc. 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, it is not possible to uniformly (simultaneously) replace all in-vehicle Edges used in society with 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 the 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 and the automatic driving ECU 104, etc., to help with driving assistance.

[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] The vehicle system 50 shown in Fig. 1 does not include the wireless communication unit 106 in Fig. 2. The vehicle system 52 has the same hardware configuration as that shown in Fig. 2.

[0060] 2B Functional Configuration Below, we will explain problems that may arise in relation to the vehicle 320 equipped with the 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 defined as driving area 300. The server responsible for driving area 300 is defined as cloud 304. One of the areas adjacent to driving area 300 is defined as adjacent area 302, and the server responsible for adjacent area 302 is a combination of cloud 306 and edge 308. Cloud 306 controls a wide area of ​​adjacent area 302, while edge 308 controls 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 controlled by edge 308 is originally smaller than the area controlled by 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 within 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 grasps and manages whether the vehicles present within each area are standalone vehicles, linked vehicles, or switchable vehicles, along with vehicle information such as their locations, movement speeds, and vehicle types. Information about such vehicles is exchanged between servers responsible for adjacent areas. Therefore, each server grasps and manages at least the locations, movement directions, and speeds (collectively referred to as vehicle movement status) of vehicles present within its own area and adjacent areas, as well as the vehicle types. As a result, for example, if vehicle 320 wants to know the types 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, this 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 stores data necessary for program execution. The flash memory 406 stores a program 426 consisting of programs (including both real-time applications and non-real-time applications) for implementing functions realized by the in-vehicle edge 80, a program 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 application execution 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 resource allocation by the initial allocation unit 452 and the resource reallocation 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, thereby executing an application having equivalent functions on the server.

[0070] The allocation of resources to applications varies depending on the number of interoperable and switchable 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 Figure 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] FIG. 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 travel area and the resource status of the server.

[0073] 7 , for example, if the surrounding vehicles are only standalone vehicles and there are no cooperative or switching vehicles, when a surrounding vehicle enters the driving area, the server's resource status does not change. The same applies when a surrounding vehicle exits 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 a case where there are other 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 second and third lines of Figure 7 show the server resource status and switching patterns when the number of cooperative vehicles in the driving area of ​​the host vehicle increases and decreases, 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 the fourth, fifth, and sixth lines of FIG. 7 can be interpreted in a similar manner. 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 host vehicle. 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 required.

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

[0079] 8, this program 500 includes steps 510 and 510 for starting communication with the server upon startup, followed by step 512 for initially allocating vehicle resources and server resources for each application that realizes a function used by the in-vehicle device. The allocation process performed in step 512 may be performed by any method. For example, it is possible to query the server for available resources, allocate resources within the range permitted by the server to non-real-time applications, and allocate vehicle resources 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 the surrounding vehicles include vehicles other than standalone vehicles, i.e., switchable vehicles or linked 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-type or cooperative-type 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, the MPU 402 does not need 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 through 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 a reallocation process in which the MPU 402 reallocates the resources of the host vehicle to some or all of the applications that had previously been allocated server resources, in accordance with the adjustment result in step 588, and then ends step 556. Note that, depending on the adjustment result in step 588, there may be cases in which resources are not reallocated in step 590.

[0087] 11, when 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. When 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 which 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 in accordance with the adjustment result in step 598, and ends step 556.

[0089] 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, 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 there is a surplus in server processing resources or whether there is a prospect of a surplus in server processing resources when the determination in step 632 is positive or when the determination in 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, where MPU 402 switches some or all of the applications that had been allocated server resources to the vehicle's resources, and then 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 travel 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 accordingly. If the determination in step 644 is negative, there is no surplus in the server's processing resources, so step 558 ends. If the determination in step 644 is positive, control proceeds to step 646, where processing is performed to allocate the host vehicle's resources to the application. When step 646 is completed, step 558 ends. Details of step 646 will be described later with reference to FIG. 15.

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

[0094] 14 is a table showing the policy by which a switching-type vehicle allocates resources between real-time applications and non-real-time applications depending on the type of server configuration at the destination of the switchover. For example, if the destination server includes only a cloud (first row), the execution of real-time applications is not possible depending on the cloud. Therefore, the MPU 402 allocates the vehicle's own resources to real-time applications. On the other hand, the MPU 402 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 an edge and a 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 having both multiple edges and multiple clouds and a server having 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] 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, the 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 positive, control proceeds to step 688. A positive determination in step 682 means that the server includes both a cloud and an edge. Therefore, in step 688, the MPU 402 allocates edge resources to the real-time application, and allocates edge or cloud resources to the non-real-time application depending on the status of the edge resources, and then ends the processing of 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 server to which the switching is made. 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 (host 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 to 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 case 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 case is when the cloud can only accept 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 case 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 is a flowchart showing the control structure of a program for implementing the 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 in accordance with the result of the determination, and step 714 for allocating edge resources to the real-time application and also to the non-real-time application, 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 flow of control 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] This 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. On the other hand, 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 travel 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, according to the priority determined in step 802, an operation of allocating edge resources to real-time applications, starting with the highest priority switching vehicle, is repeated 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 priority 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] 21 shows details of step 718 in FIG. 17. Referring to FIG. 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 of the determination. If the determination in step 860 is positive, the MPU 402 allocates the host vehicle's resources to the real-time application in step 864. The MPU 402 further includes step 866, which allocates the cloud's 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 the vehicle's resources to the real-time applications. The MPU 402 further includes step 870, in which the MPU 402 executes priority processing for non-real-time applications and ends step 718. 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 ends step 718.

[0118] 3. Operation 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 (e.g., 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 (the processing start point in FIG. 8 ) (step 510 in FIG. 8 ). Based on information obtained from the server, the initial allocation unit 452 allocates resources to real-time 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 reads out applications to which server or edge resources have been allocated from the application storage unit 462 and transmits them to the server or edge via the communication processing unit 450 to request execution. In this case, the applications to which server resources have been allocated are non-real-time applications. The applications to which edge resources have been allocated may be real-time applications or non-real-time applications. If no edge exists, the real-time applications are allocated the resources of the vehicle itself. The application control unit 458 reads out the application to which the resources of the vehicle have been allocated from the application storage unit 462 and causes the application execution unit 460 to execute the application. The in-vehicle edge 80 then repeats the process of downloading information about surrounding vehicles and information about driving assistance from the server that has jurisdiction over each driving area up to this point (step 514) and reallocating resources to each application based on this information communication (step 516).

[0119] 3, it is assumed 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, vehicle 324 in driving area 300 is a standalone vehicle, and vehicle 322 is a switching vehicle. Vehicle 324 is predicted to exit driving area 300 in the near future. Vehicle 322 is traveling behind vehicle 320. Therefore, vehicle 322 is predicted not to exit driving area 300 for some time. Also, switching vehicles 326 and 328 are assumed to be present in adjacent area 302. Of these, vehicle 326 is traveling in a direction away from driving area 300. Edge 308 and cloud 306 predict that vehicle 328 will enter driving area 300 from adjacent area 302 after time t2 has elapsed from the current time. Here, t2<t1. Edge 308 also predicts that vehicle 326 will still remain in adjacent area 302 after time t1.

[0121] 5 , the change detection unit 454 of the vehicle 320 predicts that, according to the driving schedule, a switching-type vehicle 328 will enter the driving area 300 after time t2. In this case, the number of switching-type vehicles in the driving area 300 will increase from two to three. In response to detecting this change, the change detection unit 454 notifies the reallocation unit 456 of the increase in switching-type vehicles. In response to this notification, the reallocation unit 456 executes a process of reallocating resources to the real-time applications and non-real-time applications of the vehicle 320. In accordance with the result of this reallocation, the application control unit 458 requests the cloud 304 to execute those non-real-time applications to which resources of the cloud 304 have been allocated, and causes those applications to be executed on the resources of the vehicle 320.

[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, assume 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, both vehicle 326 and vehicle 320 perform reallocation of resources in cloud 306 and edge 308.

[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 Modification 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 each of the processes. The one or more processors may execute each of the processes according to the programs read from the one or more memories, or may execute each of the processes in a logic circuit designed in advance to execute each of the 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 physically separated processors may cooperate with each other to execute the processes. For example, the processors installed in the physically separated computers may cooperate with each other via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet to execute the processes. 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 then 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.

[0130] 60, 70, 80 In-vehicle edge 72, 82 Server 100 Sensor 102 ECU 104 Autonomous driving ECU 106 Wireless communication unit 108 In-vehicle GW 300 Travel area 302 Adjacent area 304, 306 Cloud 308 Edge 320, 322, 324, 326, 328 Vehicle 400 High-speed bus 402 MPU 404 SRAM 406 Flash memory 408 ROM 410 Low-speed 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 Program 450 Communication processing unit 452 Initial allocation unit 454 Change detection unit 456 Reallocation unit 458 Application control unit 460 Application execution unit 462 Application storage unit

Claims

1. A resource allocation method for 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 has jurisdiction over the driving area of ​​a vehicle equipped with the in-vehicle device and resources of the vehicle equipped with the in-vehicle device, and allocates these resources to each function of the in-vehicle device, the resource allocation method comprising: a step in which a computer executes an allocation process that allocates 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 equipped with the in-vehicle device 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.

2. The method of claim 1, wherein the re-execution step includes: a step in which a computer determines whether each vehicle present in a surrounding area including the driving area and an adjacent area adjacent to the driving 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 switchable vehicle equipped with the switchable in-vehicle device; a first determination step in which the computer determines whether a vehicle other than the standalone vehicle is present in the surrounding area; and a step in which the computer, in response to determining in the first determination step that a vehicle other than the standalone vehicle is present 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 in-vehicle device in accordance with the resources available on the server.

3. The method of claim 2, wherein the step of executing the reallocation process includes: 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 resources of the server and the resources of the host vehicle to each function of the in-vehicle device based on the result of adjustment regarding the resources of the server with the switchable vehicles present in the surrounding area and the status of 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 resources of the server and the resources of the host vehicle to each function of the in-vehicle device based on the status of resources available on the server.

4. The method of claim 3, wherein the first reallocation execution step includes: 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 the server's resources will be insufficient 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 executes adjustment of the server's resources with the 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's resources allocated to the functions of the in-vehicle device to the resources of the vehicle itself based on the result of the adjustment.

5. The method of claim 4, wherein the first reallocation execution step further includes: 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 surplus 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 resources of the server with the 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 resources of the server based on the result of the adjustment.

6. The method of claim 3, wherein the first reallocation execution step includes: 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 on-board device to resources of the server in response to a positive determination result in the third determination step.

7. The method of any one of claims 3 to 6, wherein 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 the server's resources will be insufficient 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's resources allocated to the functions of the in-vehicle device to the vehicle's resources in response to a positive determination result in the first server resource determination step.

8. The method of claim 7, wherein the second reallocation execution step further includes: 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 first server resource determination step; a second server resource determination step in which the computer determines whether there is an excess in the server's 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 vehicle's resources that were allocated to the functions of the in-vehicle device to the server's resources in response to a positive determination result in the second server resource determination step.

9. The method of any one of claims 3 to 6, wherein 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 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 will be surplus resources in the server in response to the detection or prediction of a decrease in the number of linked vehicles present in the driving area in the in-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.

10. The method of claim 5 or 6, wherein the servers in the driving 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, and the step of switching to the resources of the server includes: a server configuration determination step of determining whether the servers in the driving area further include 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 allocating the resources of the first server to the first function in response to the determination in the server configuration determination step that the servers do not include the second server.

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

12. The method of claim 5 or 6, wherein the servers in the driving 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, and the step of switching to the resources of the server includes: a server configuration determination step of determining whether the servers in the driving area further include 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 servers do not include the second server.

13. The method of claim 12, wherein the step of switching to 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 determining step determining that the server includes the second server.

14. The method of claim 5 or 6, wherein the servers in the driving area include a first server and a second server having a faster response than the first server, the functions of the in-vehicle device 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 includes 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 are not allocated resources of the second server and to functions among the first functions that are not allocated resources of the first server or resources of the second server.

15. The method of claim 14, wherein the step of allocating as many resources of the second server as the second server allows to the second function includes: 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 between other switch-type 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 a part of the second functions, and allocating as many resources of the second server as possible to the part of the second functions according to the result of the adjustment; and a step of allocating resources of the vehicle to those second functions to which the resources of the second server cannot be allocated as a result of the adjustment.

16. The method of claim 14, wherein 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 includes: 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 traveling area in response to the determination in the additional determination step that the resources of the first server cannot be allocated to at least a part of the first functions, and allocating as many resources of the first server as possible to the part of the first functions according to the result of the adjustment; and a step of allocating resources of the host vehicle to those first functions to which the resources of the first server cannot be allocated as a result of the adjustment.

17. A resource allocation device 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 ​​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 allocates these to each function of the in-vehicle device, the resource allocation device including: 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.

18. 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 ​​a vehicle equipped with the in-vehicle device and resources of the vehicle equipped with the in-vehicle device, and allocates these to each function of the in-vehicle device; and the computer program causes a computer to function as: an allocation execution unit that executes an allocation process that allocates resources of a server that has jurisdiction over the driving area of ​​the vehicle equipped with the in-vehicle device and resources of the vehicle equipped with the in-vehicle device 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.