Vehicle control device and control method

Abstract

Provided is a vehicle control device comprising a plurality of cores, and a storage device for storing a plurality of pieces of software for realizing an application. The plurality of applications include a basic application and an optional application. The storage device stores a number of pieces of software that cannot be simultaneously executed by using all of the plurality of cores. The vehicle control device includes: an application selection unit for selecting an application to be executed such that the execution load of a basic application to be newly executed, a basic application under execution, and an optional application under execution is within the range of performance limits of the plurality of cores when execution of the basic application is newly requested; and an application control unit for controlling execution of the selected application.

Description

Vehicle control device and control method

[0001] The present invention relates to a vehicle control device, and more particularly to a technique for controlling the execution of an application.

[0002] To improve safety and comfort, improvements are being made to the hardware performance of vehicle control devices and applications are being added.

[0003] Software for implementing applications can be added to the vehicle control device depending on the available storage capacity. However, the number of applications that can be executed simultaneously depends on the processing performance of the CPU or GPU that executes the software. Therefore, there are cases where it is not possible to execute all requested applications.

[0004] A technique described in Patent Document 1 is known as a technique relating to application scheduling.

[0005] JP 2011-100338 A

[0006] When selecting an application to be executed from among requested applications, it is important to consider safety and comfort and to select an application that will allow for effective use of computing resources.

[0007] The technology described in Patent Document 1 is a technology related to scheduling of applications whose processing does not finish within a specified period, and it is difficult to solve the above-mentioned problem.

[0008] The present invention provides a technology for selecting an application to be executed, taking into consideration safety and comfort, and for making effective use of computing resources.

[0009] A representative example of the invention disclosed in the present application is as follows: That is, a vehicle control device including a plurality of cores and a storage device storing a plurality of pieces of software that realize applications, wherein the plurality of applications include a plurality of basic applications that provide functions essential for vehicle control and a plurality of optional applications, the storage device stores a number of pieces of software that cannot be simultaneously executed using all of the plurality of cores, and the vehicle control device has an application selection unit that, when execution of a new basic application is requested, selects the application to be executed so that the execution load of the newly executed basic application, the basic application currently being executed, and the optional application currently being executed falls within the performance limit of the plurality of cores, and an application control unit that controls the execution of the application selected by the application selection unit.

[0010] According to the present invention, it is possible to select and execute an application to be executed so as to ensure maximum safety and comfort and to make effective use of computational resources.

[0011] The details of at least one implementation of the subject matter disclosed herein are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the disclosed subject matter will become apparent from the following disclosure, drawings, and claims.

[0012] 1 is a block diagram showing an example of the configuration of a vehicle control system according to a first embodiment; FIG. 2 is a block diagram showing an example of the hardware configuration of an autonomous driving ECU according to a first embodiment; FIG. 3 is a diagram illustrating an example of the data structure of data managed by application information according to a first embodiment; FIG. 4 is a diagram illustrating an example of a data flow of an autonomous driving ECU according to a first embodiment; FIG. 5 is a flowchart illustrating an example of processing executed by an application selection unit according to a first embodiment; FIG. 6 is a flowchart illustrating an example of processing executed by an application management unit according to a first embodiment; FIG. 7 is a diagram illustrating priority when selecting an application to be executed according to a first embodiment; FIG. 8 is a diagram illustrating a state condition table for selecting an application to be executed according to a first embodiment;

[0013] Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the present invention should not be construed as being limited to the description of the embodiments shown below. Those skilled in the art will readily understand that the specific configuration can be changed without departing from the spirit or intent of the present invention.

[0014] In the configuration of the invention described below, the same or similar configurations or functions are denoted by the same reference numerals, and redundant explanations will be omitted.

[0015] FIG. 1 is a block diagram illustrating an example of the configuration of a vehicle control system according to a first embodiment.

[0016] The vehicle control system is a system installed in a vehicle (not shown), and includes an autonomous driving ECU 100, a sensor ECU 101, a communication ECU 102, and a plurality of control ECUs 103.

[0017] The sensor ECU 101 acquires information representing the state of the surroundings and the interior of the vehicle using sensors (not shown) such as cameras and radars mounted on the vehicle. The communication ECU 102 communicates with devices inside the vehicle or devices or systems outside the vehicle.

[0018] The control ECU 103 performs vehicle control such as engine control, automatic transmission (AT) control, brake control, and steering control.

[0019] The autonomous driving ECU 100 performs integrated control of the vehicle. The control ECU 103 performs various types of vehicle control based on the output of the autonomous driving ECU 100. The autonomous driving ECU 100 includes a vehicle state monitoring unit 110, a control state monitoring unit 111, an application management unit 112, a fail-safe unit 113, a request arbitration unit 114, an application selection unit 115, an application control unit 116, and a storage unit 117.

[0020] The storage unit 117 stores a program for implementing the application 120 and application information 130. The application 120 provides various functions such as detecting a driving lane, detecting signs, and automatic headlights.

[0021] In this embodiment, the applications 120 are broadly classified into basic applications that provide functions essential for vehicle control (vehicle control functions) and optional applications that provide various additional functions. The basic applications can be further subdivided into basic function upgrade versions, basic functions, and basic function updates. The optional applications can be further subdivided into optional add-on functions, driver assistance functions, and passenger comfort functions. For example, a basic function upgrade version corresponds to a major functional change, such as when a basic function version changes from version 1 to 2, while a basic function update corresponds to a minor functional change, such as bug fixes. Furthermore, for example, an optional add-on function is a driving assistance function added via OTA or the like, a driver assistance function is an auto high beam that switches headlights between high and low, and a passenger comfort function is a function that more optimally controls the in-vehicle air conditioning, a function that provides a communication environment, or a function that provides entertainment content such as music and videos.

[0022] Here, a description will be given of the hardware configuration of the autonomous driving ECU 100. Fig. 2 is a block diagram showing an example of the hardware configuration of the autonomous driving ECU 100 according to the first embodiment.

[0023] The autonomous driving ECU 100 is, for example, a microcomputer having a CPU 200, a GPU 201, a ROM 202, a RAM 203, and a communication interface 204. The CPU 200 and the GPU 201 each include a plurality of cores 400 (see FIG. 4 ).

[0024] FIG. 3 is a diagram illustrating an example of the data structure of data managed by the application information 130 according to the first embodiment.

[0025] The application information 130 stores, for example, data 300 as shown in Fig. 3. One piece of data 300 exists for one application 120.

[0026] The data 300 includes an application name 301 , an execution condition 302 , a priority 303 , and a load 304 .

[0027] The application name 301 is a field for storing the name of the application 120. The execution condition 302 is a field for storing the execution condition of the application 120. For example, the running mode and the dependency relationship of other applications 120 are stored.

[0028] The priority 303 is a field for storing the priority of execution of the application 120. In this embodiment, it is assumed that an application 120 with a higher priority is executed preferentially. In this embodiment, it is assumed that the priority of the application 120 managed in the state condition table of FIG. 9 is assigned according to the priority of FIG. 8.

[0029] 8 is a diagram illustrating an example of the priority in this embodiment. Priorities are set corresponding to basic applications and optional applications, with basic function upgrade versions having the highest priority and passenger comfort functions having the lowest priority.

[0030] FIG. 9 illustrates a state condition table that defines application execution conditions. The table summarizes vehicle and system states corresponding to conditions based on vehicle, driving environment, and system state (conditions 1 to 6 in FIG. 9 ) and conditions related to functions to be executed (condition 7 in FIG. 9 ). For example, condition 1 is set for the vehicle state, with the vehicle being in motion (state 1) and stationary (state 2) as the specified states. Condition 7 is set for the functions to be executed, with the vehicle control function (state 1), driver assistance function (state 2), and passenger comfort function (state 3) as the specified states. Applications to be executed based on each condition and state are predetermined, and priorities are assigned based on the attributes of the applications (basic application or optional application). In this embodiment, FIG. 9 shows a total of 3,600 combinations of applications that operate under the driving and stationary conditions, but other conditions may also be used. Priorities are assigned to each of the 3,600 application combinations based on the attributes described above.

[0031] The data 300 may have a field for storing the type of the application 120. The load 304 is a field for storing the load at the time of execution of the application 120. For example, the usage rate of the core 400, etc. is stored.

[0032] FIG. 4 is a diagram illustrating an example of a data flow of the autonomous driving ECU 100 according to the first embodiment.

[0033] The vehicle state monitoring unit 110 acquires information about the vehicle state from the sensor ECU 101. The vehicle state monitoring unit 110 outputs the acquired information to the request arbitration unit 114. Furthermore, the vehicle state monitoring unit 110 outputs the acquired information to the application 120 as necessary.

[0034] The control state monitoring unit 111 acquires information about the execution state of the application 120. For example, the acquired information includes the load on the core 400 that executes the application 120 and the operating state of the application 120. The control state monitoring unit 111 outputs the acquired information to the fail-safe unit 113 and the application selection unit 115.

[0035] The fail-safe unit 113 identifies the application 120 in which the abnormality has occurred and determines whether to stop or restart the application 120. In this embodiment, it is assumed that the processing is performed on the basic application 120. The fail-safe unit 113 outputs the processing result to the application selection unit 115. The same applies to optional applications.

[0036] The request arbitration unit 114 identifies the applications that have been requested to be executed and the applications that have been requested to be stopped based on input from the vehicle state monitoring unit 110, the application 120, and the user (driver or passenger), as well as the application information 130.

[0037] For example, when the request arbitration unit 114 receives a request from an application 120 to start another application 120, or when executing an application 120 whose execution has been requested by a user, the request arbitration unit 114 refers to the execution conditions 302, priority 303, and load 304 included in the application information 130 based on the vehicle state, determines the application 120 to be executed or stopped, and notifies the application selection unit 115. The request arbitration unit 114 also refers to the execution conditions 302, priority 303, and load 304 of an application that is already being executed and the execution conditions 302, priority 303, and load 304 of the application whose execution has been requested, respectively, and notifies the application selection unit 115 that the application whose execution has been requested is to be started and the application that is already being executed is to be stopped. Furthermore, for an application 120 whose stop has been requested by the user, the request arbitration unit 114 notifies the application selection unit 115 that a stop request has been made.

[0038] The application selection unit 115 selects an application 120 to be executed based on inputs from the control state monitoring unit 111, the failsafe unit 113, and the request arbitration unit 114, and on application information 130. The application selection unit 115 determines the allocation of the cores 400 that execute the applications 120, and also determines which applications 120 to stop, using the input information from the control state monitoring unit 111. The application selection unit 115 outputs the processing result to the application control unit 116.

[0039] Based on input from the application selection unit 115 , the application control unit 116 controls allocation of the application 120 to the cores 400 , changes in allocation of the cores 400 to the application 120 , and activation and termination of the application 120 .

[0040] The application management unit 112 updates the application information 130 in response to addition, update, and deletion of the application 120 .

[0041] 5A and 5B are flowcharts illustrating an example of processing executed by the application selection unit 115 according to the first embodiment. In the following description, the application 120 will be referred to as the app 120.

[0042] When the application selection unit 115 receives an input from either the fail-safe unit 113 or the request arbitration unit 114, it executes the process described below.

[0043] The application selection unit 115 identifies the applications 120 to be executed and the applications 120 to be stopped based on the input (step S101). The applications 120 to be executed are managed, for example, as a list. The applications to be stopped are managed, for example, as a stopped application list.

[0044] The application selection unit 115 determines whether or not a basic application 120 is present among the applications 120 identified as applications 120 to be executed (step S102). The basic application 120 is determined based on, for example, the application name 301 or the priority 303 of the data 300.

[0045] The application selection unit 115 selects the basic application 120 to be processed (step S103). Here, the basic application 120 is selected in descending order of priority.

[0046] The application selection unit 115 determines whether the selected basic application 120 is the application 120 to be restarted (step S104). That is, it determines whether the basic application 120 has been notified by the fail-safe unit 113 as the application 120 to be restarted.

[0047] If the selected basic application 120 is the application 120 to be restarted, the application selection unit 115 determines the core 400 to which the basic application 120 is to be assigned (step S107). The application selection unit 115 then deletes the basic application 120 from the list and then returns to step S102. In this embodiment, the basic application 120 is reassigned to the core 400 that was executing the basic application 120.

[0048] If the selected basic application 120 is not the application 120 to be restarted, the application selection unit 115 determines whether there is a core 400 to which the basic application 120 can be allocated (step S105). For example, the following process is executed.

[0049] (S105-1) The application selection unit 115 refers to the application information 130 and acquires the load of the selected basic application 120.

[0050] (S105-2) The application selection unit 115 identifies the applications 120 assigned to each core 400 based on the information input by the control state monitoring unit 111. The application selection unit 115 refers to the application information 130 and calculates the amount of free resources of the core 400 based on the load of the identified applications 120. Specifically, the difference between the upper limit of the resource amount representing the performance limit and the current resource amount is calculated as the amount of free resources. The upper limit of the resource amount representing the performance limit can be set arbitrarily. Note that the load of the applications 120 to be stopped is not taken into consideration.

[0051] (S105-3) The application selection unit 115 determines whether or not there is a core 400 to which the selected basic application 120 can be allocated, based on the load of the selected basic application 120 and the amount of free resources of the core 400.

[0052] If there is a core 400 to which the selected basic application 120 can be allocated, the application selection unit 115 determines the core 400 to which the basic application 120 should be allocated (step S107), then deletes the basic application 120 from the list, and then returns to step S102.

[0053] If there are multiple cores 400 available for allocation, the core 400 with the least amount of free resources is selected as the allocation destination. This allows the cores 400 to be used as effectively as possible, and also ensures that the amount of resources necessary for executing other applications 120 is secured.

[0054] If there is no core 400 to which the selected basic application 120 can be allocated, the application selection unit 115 determines an optional application 120 to be stopped / relocated from among the running applications 120 (step S106). For example, the following process is executed.

[0055] (S106-1) The application selection unit 115 refers to the application information 130 and acquires the load of the selected basic application 120.

[0056] (S106-2) The application selection unit 115 identifies the applications 120 assigned to each core 400 based on the information input by the control state monitoring unit 111. The application selection unit 115 refers to the application information 130 and calculates the amount of free resources of the core 400 based on the load of the identified applications 120.

[0057] (S106-3) The application selection unit 115 refers to the application information 130 and identifies the optional application 120 with the lowest priority from among the optional applications 120 that are currently running.

[0058] (S106-4) The application selection unit 115 determines whether the identified optional application 120 can be moved to another core 400. This determination is made based on the amount of free resources of the core 400 and the identified optional application 120.

[0059] (S106-5) If the identified optional application 120 can be moved to another core 400, the application selection unit 115 determines the core 400 to which the optional application 120 should be assigned. If the identified optional application 120 cannot be moved to another core 400, the application selection unit 115 determines to stop the optional application 120.

[0060] (S106-7) The application selection unit 115 determines whether or not there is a core 400 to which the selected basic application 120 can be allocated. If there is no core 400 to which the selected basic application 120 can be allocated, the application selection unit 115 returns to S106-3. Note that an optional application 120 that has been selected once is excluded from the selection targets. If there is a core 400 to which the selected basic application 120 can be allocated, the application selection unit 115 ends the processing of step S106.

[0061] The application selection unit 115 determines the core 400 to which the selected basic application 120 is to be assigned (step S107). Here, the basic application 120 is assigned to the core 400 to which the optional application 120 is to be moved or stopped. The application selection unit 115 then deletes the basic application 120 from the applications 120 to be executed, and then returns to step S102. This allows control to ensure that the basic application 120 is executed.

[0062] In step S102, if there is no basic app 120 among the apps 120 identified as the apps 120 to be executed, the application selection unit 115 determines whether there is an optional app 120 among the apps 120 selected as the apps 120 to be executed (step S108).

[0063] If an optional application 120 is present among the applications 120 identified as the applications 120 to be executed, the application selection unit 115 selects the optional application 120 to be processed (step S109). Here, the optional application 120 is selected in descending order of priority. Note that an optional application 120 that has a dependency relationship with the basic application 120 may be preferentially selected.

[0064] The application selection unit 115 determines whether there is a core 400 to which the selected optional application 120 can be allocated (step S110). For example, the following process is executed. The process of step S110 is the same as the process of step S105.

[0065] If there is a core 400 to which the selected optional application 120 can be assigned, the application selection unit 115 determines the core 400 to which the optional application 120 should be assigned (step S113). Then, the application selection unit 115 deletes the optional application 120 from the applications 120 to be executed, and then returns to step S108.

[0066] If there is no core 400 to which the selected optional application 120 can be allocated, the application selection unit 115 determines whether or not there is an optional application 120 that can be stopped / relocated among the running optional applications 120 (step S111).

[0067] Specifically, the application selection unit 115 determines whether or not there is an optional application 120 that has a lower priority than the selected optional application 120 among the optional applications 120 that are currently running.

[0068] If there is no optional application 120 that can be stopped / relocated among the running optional applications 120, the application selection unit 115 deletes the optional application 120 from the list, and then returns to step S108.

[0069] If there is an optional application 120 that can be stopped / relocated among the running optional applications 120, the application selection unit 115 determines an optional application 120 to be stopped / relocated from among the running applications 120 (step S112). The process of step S112 is the same as the process of step S106. However, the optional applications 120 that have a lower priority than the selected optional application 120 are the targets for stopping / relocation.

[0070] The application selection unit 115 determines the core 400 to which the selected optional app 120 is to be assigned (step S113). Here, the selected optional app 120 is assigned to the core 400 to which the optional app 120 is to be moved or stopped. Thereafter, the application selection unit 115 deletes the selected optional app 120 from the list, and then returns to step S108.

[0071] In step S108, if there is no optional application 120 among the applications 120 identified as applications 120 to be executed, the application selection unit 115 ends the process.

[0072] The application control unit 116 executes, rearranges, and stops the application 120 based on the results of the above-mentioned processing.

[0073] FIG. 6 is a diagram illustrating an example of application selection by the application selection unit 115 according to the first embodiment.

[0074] Here, it is assumed that there is one core 400 and no applications 120 are being executed. It is also assumed that basic application A1 and optional applications a1, a2, a3, b1, b2, c1, and c2 are identified as applications 120 to be executed.

[0075] As shown in the figure, it is not possible to execute all of the applications 120. After selecting the basic application A1, the application selection unit 115 selects optional applications 120 within the performance limits of the core 400. In this example, it is assumed that optional applications a3, b2, and c1 have been selected.

[0076] When a change in the driving mode causes a request to stop basic app A1 and execute basic app A2, the application selection unit 115 determines to stop basic app A1. The application selection unit 115 also selects basic app A2 as the app 120 to be executed. The application selection unit 115 also selects optional app 120 within the performance limits of the core 400. In the drawing, it is determined that optional apps a3, b2, and c1 are to be stopped, and optional app a2, which has a dependency relationship with basic app A2, is selected.

[0077] FIG. 7 is a flowchart illustrating an example of processing executed by the application management part 112 according to the first embodiment.

[0078] When the application management unit 112 receives a request to add, update, or delete the app 120, the application management unit 112 executes the process described below. The request to add or update the app 120 may be made via a wired or wireless network, or may use a storage medium on which software is stored. The request to delete the app 120 may be made via the network.

[0079] The application management unit 112 adds, updates, or deletes the application 120 in accordance with the received request (step S201). The request to add or update the application 120 includes information on the execution condition, priority, and load.

[0080] The application management unit 112 updates the application information 130 based on the processing result of step S201 (step S202).

[0081] When an application 120 is added, the application management unit 112 adds the data 300 to the application information 130. When an application 120 is deleted, the application management unit 112 deletes the data 300 from the application information 130. When an application 120 is updated, the application management unit 112 updates the contents of the data 300. For example, the execution condition 302, the priority 303, etc. are updated.

[0082] The optimization of the execution control of the application 120 can be customized by updating the execution conditions managed in the application information 130 in accordance with the addition, update, and deletion of the application 120. Specifically, since the priority based on the function type illustrated in Fig. 8 and the priority under each condition are managed using the state condition table in Fig. 9, when one application 120 is added, updated, or deleted, the priority relative to other applications set based on the conditions set in the state condition table in Fig. 9 changes, and the state condition table is updated.

[0083] According to the first embodiment, the application selection unit 115 determines allocation to the cores 400 so that the basic applications 120 are reliably executed. In addition, the application selection unit 115 selects the optional applications 120 that are required to be executed within the performance limits of the cores 400. This ensures safety and improves user comfort as much as possible.

[0084] Since various applications 120 can be executed while ensuring safety, it is possible to improve both safety and comfort. In addition, it is possible to improve the utilization efficiency of the core 400.

[0085] The application selection unit 115 controls the execution, stopping, restarting, and relocation of the applications 120, which simplifies the design of the applications 120. Furthermore, by updating the application information 130, the selection conditions for the applications 120 can be set arbitrarily. This allows for desired optimization control.

[0086] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, with respect to part of the configuration of each embodiment, addition, deletion, or substitution of other configurations can be applied alone or in combination.

[0087] Furthermore, the above-described configurations, functions, processing units, and processing means may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations and functions may also be implemented in software by a processor interpreting and executing a program that implements each function. Information such as the program, table, and file that implements each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0088] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected.

Claims

1. A vehicle control device having a plurality of cores and a storage device storing a plurality of software programs that realize applications, wherein the plurality of applications include a plurality of basic applications that provide functions essential for vehicle control and a plurality of optional applications, and wherein the storage device stores a number of the software programs that cannot be executed simultaneously using all of the plurality of cores, wherein the vehicle control device has an application selection unit that, when execution of a new basic application is requested, selects the application to be executed so that the execution load of the newly executed basic application, the basic application currently being executed, and the optional application currently being executed is within the performance limits of the plurality of cores, and an application control unit that controls the execution of the application selected by the application selection unit.

2. A vehicle control device as described in claim 1, characterized in that the application selection unit, when there is no core capable of executing at least one of the basic applications, stops or changes the allocation of the core that executes at least one of the optional applications that is currently running, and determines the core to which to assign at least one of the basic applications.

3. A vehicle control device as described in claim 1, wherein the storage device stores application information defining the execution conditions of the application, and the vehicle control device has: an application management unit that updates the application information when the software is added, updated, or deleted; a vehicle status monitoring unit that monitors the status of a vehicle in which the vehicle control device is installed; and a request arbitration unit that identifies the application to be executed based on the application information and the status of the vehicle.

4. A vehicle control device as described in claim 1, characterized in that the application selection unit, when a request for execution of a new optional application is made and there is no core capable of executing the optional application, stops at least one of the optional applications currently being executed or changes the allocation of the core to be executed, and determines the core to which the newly executed optional application is assigned.

5. A control method executed by a vehicle control device, the vehicle control device having a plurality of cores and a storage device storing a plurality of software programs that realize applications, the plurality of applications including a plurality of basic applications that provide functions essential for vehicle control and a plurality of optional applications, the storage device storing a number of the software programs that cannot be executed simultaneously using all of the plurality of cores, the control method comprising the steps of: when execution of a new basic application is requested, a first step in which the vehicle control device selects the application to be executed so that the execution load of the newly executed basic application, the basic application currently being executed, and the optional application currently being executed is within the performance limits of the plurality of cores; and a second step in which the vehicle control device controls the execution of the selected application.

6. A control method as described in claim 5, characterized in that the first step includes: when there is no core capable of executing at least one of the basic applications, the vehicle control device stops at least one of the optional applications that is currently being executed or changes the allocation of the core that executes the optional application; and the vehicle control device determines the core to which to assign at least one of the basic applications.

7. A control method as described in claim 5, wherein the storage device stores application information defining execution conditions of the application, the control method includes a step in which the vehicle control device updates the application information when the software is added, updated, or deleted, and the first step includes a step in which the vehicle control device monitors the state of the vehicle in which the vehicle control device is installed, and a step in which the vehicle control device identifies the application to be executed based on the application information and the state of the vehicle.

8. A control method as described in claim 5, comprising: when execution of a new optional application is requested and there is no core capable of executing the optional application, the vehicle control device stops at least one of the optional applications currently being executed or changes the allocation of the core that executes the optional application; and the vehicle control device determines the core to which the newly executed optional application is to be assigned.

Images