Motion manager for vehicle

Abstract

To provide a motion manager for a vehicle that can, when there are different types of motion requests, reflect the different types of movement requests in the control of the vehicle.SOLUTION: A management ECU 10 is configured to receive motion requests from one or more travel applications A1 and motion requests from one or more human-machine interface (HMI) applications A2. The travel application A1 is an application for controlling acceleration of the vehicle. The HMI application A2 is an application for implementing transfer of information from the vehicle to an occupant. When receiving the motion request from the HMI application A2, the management ECU 10 calculates instruction information K for an actuator on the basis of a result of arbitration of: a selected acceleration D1X being a result of arbitration of the motion requests from the one or more travel applications A; and an HMI acceleration D2 being the motion request from the HMI application A2.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a vehicle motion manager. [Background technology]

[0002] The vehicle control system disclosed in Patent Document 1 includes multiple execution units, a motion manager, and an actuator. Each execution unit executes its own application. The motion manager accepts motion requests from multiple applications. The motion manager then arbitrates between the multiple motion requests. That is, the motion manager selects one of the multiple motion requests according to a predetermined rule. The motion manager then generates instruction information for the actuator based on the motion request that wins the arbitration. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2020-032894 A Summary of the Invention [Problem to be solved by the invention]

[0004] In the technology such as Patent Document 1, for example, an arbitration method is adopted for selecting the largest of a plurality of motion requests, such as a vehicle braking request. Here, the motion requests from the application include those for driving the vehicle and those for alerting the occupants. The magnitude of the motion request for alerting the occupants may be considerably smaller than the magnitude of the motion request for driving the vehicle. Therefore, if arbitration is performed by the above-mentioned arbitration method when these two motion requests arrive at the same time, the motion request for alerting the occupants may be buried in the motion request for driving the vehicle, and the motion request for alerting the occupants may not be realized. [Means for solving the problem]

[0005] A vehicle motion manager for solving the above problem is capable of accepting motion requests from a plurality of applications, arbitrating the accepted motion requests, calculating instruction information for an actuator of the vehicle based on a result of the arbitration of the motion requests, and outputting the calculated instruction information to a control device of the actuator, wherein one or more of the multiple applications are driving applications for controlling one or more selected from the acceleration of the vehicle and the steering angle of the vehicle, and one or more other of the multiple applications are HMI applications for realizing information transmission from the vehicle to an occupant, and when the motion request from the HMI application is not accepted, the instruction information is calculated based on the result of arbitration of the motion request from the driving application, and when the motion request from the HMI application is accepted, the instruction information is calculated based on a heterogeneous arbitration result which is a result of arbitrating the result of the arbitration of the motion request from the driving application and the motion request from the HMI application. Effect of the Invention

[0006] In the above configuration, when different types of motion requests are made, both of the motion requests can be reflected in the control of the vehicle. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a schematic diagram of a vehicle. [Diagram 2] FIG. 2 is a diagram showing an example of transitions of the selected acceleration, the HMI acceleration, and the arbitrated acceleration. [Diagram 3] FIG. 3 is a schematic configuration diagram of the management ECU. [Figure 4] FIG. 4 is a flowchart showing the procedure of the management process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] An embodiment of a vehicle motion manager will now be described with reference to the drawings. <Overall vehicle configuration> As shown in FIG. 1, a vehicle 100 includes a command ECU 50, a management ECU 10, a first actuator system 70, and a second actuator system 80.

[0009] The first actuator system 70 includes an engine 71 and an engine ECU 75. The engine 71 is a drive source for the vehicle 100. The engine 71 includes a plurality of actuators 72, such as a throttle valve, a fuel injection valve, and an ignition device. In FIG. 1, one of the plurality of actuators 72 is shown as a representative. The engine ECU 75 is a computer including a processing circuit. The processing circuit includes a CPU and a memory. The memory stores in advance various programs in which the processes to be executed by the CPU are described. The engine ECU 75 controls the actuators 72 of the engine 71 based on instruction information K from the management ECU 10. That is, the engine ECU 75 is a control device that controls the actuators 72. The engine ECU 75 controls the actuators 72, causing fuel to burn in the engine 71. At the same time, driving force is generated in the vehicle 100.

[0010] The second actuator system 80 includes a plurality of brake devices 81 and a brake ECU 85. In FIG. 1, one of the plurality of brake devices 81 is shown as a representative. The brake device 81 is provided for each wheel of the vehicle 100. The brake device 81 includes a disk that rotates integrally with the wheel, a brake pad that operates according to hydraulic pressure, and an actuator 82 that applies hydraulic pressure to the brake pad. The brake ECU 85 is a computer that includes a processing circuit. The processing circuit includes a CPU and a memory. The memory stores in advance various programs that describe the processing to be executed by the CPU. The brake ECU 85 controls the actuator 82 based on instruction information K from the management ECU 10. That is, the brake ECU 85 is a control device that controls the actuator 82. When hydraulic pressure is generated by the brake ECU 85 controlling the actuator 82, the brake pad is pressed against the disk. At the same time, a braking force is generated in the vehicle 100.

[0011] Although not shown in the figure, the vehicle 100 is equipped with an actuator system other than the first actuator system 70 and the second actuator system 80. An example of another actuator system is a steering system that adjusts the steering angle of the vehicle 100. The steering system includes an actuator that adjusts the steering angle, and an ECU that controls the actuator. The steering angle includes both the steering angle of the steering wheel and the steered angle of the steered wheels. The steered wheels are, for example, the front wheels.

[0012] <Command ECU> The command ECU 50 is a computer equipped with a processing circuit. The processing circuit includes a CPU and a memory. The memory stores in advance various programs in which processes to be executed by the CPU are described. Examples of the programs stored in the memory are multiple applications A for controlling the motion of the vehicle 100. The command ECU 50 functions as an execution device that executes the applications A stored in the command ECU 50. The command ECU 50 may execute multiple applications A simultaneously. The command ECU 50 sequentially acquires information detected by various sensors 101 mounted on the vehicle 100. The command ECU 50 refers to information acquired from the various sensors 101 when executing the application A. The various sensors 101 include devices that detect peripheral information of the vehicle 100, such as a camera and a radar. The various sensors 101 include devices that detect the running state of the vehicle 100, such as the running speed of the vehicle 100. In FIG. 1, one of the various sensors 101 is shown as a representative.

[0013] In the following, content that is actually mainly performed by the command ECU 50 may be described as being mainly performed by the application A to be executed. For example, the output of a motion request by the command ECU 50 may be described as "application A outputs a motion request," and a motion request from the command ECU 50 may be described as "motion request from application A." Note that, in this embodiment, of the multiple applications A stored in the command ECU 50, the application A related to control of the acceleration C of the vehicle 100 is described as the subject of description. The acceleration C of the vehicle 100 is positive when the vehicle 100 accelerates forward, and negative when the vehicle 100 accelerates backward.

[0014] The applications A stored in the command ECU 50 can be broadly divided into two types: a driving application A1 and an HMI application A2. The driving application A1 is an application A for controlling the driving acceleration C of the vehicle 100. The motion request from the driving application A1 is a request for the acceleration C to be realized by the vehicle 100. As information embodying this motion request, the driving application A1 outputs a requested acceleration D1. Here, when the command ECU 50 is executing the driving application A1, it repeatedly outputs the requested acceleration D1 at every predetermined control period. When outputting the requested acceleration D1, the command ECU 50 assigns a first identification value to the requested acceleration D1. The first identification value is a data identification value indicating that the content of the motion request is the requested acceleration D1.

[0015] The HMI application A2 is an application A for realizing information transmission from the vehicle 100 to the occupant. Specifically, the HMI application A2 operates the vehicle 100 to call the occupant's attention. The motion request from the HMI application A2 is a request to decelerate the vehicle 100 intermittently during the control period T when viewed in a time series. As information embodying this motion request, the HMI application A2 outputs the HMI acceleration D2 shown in (b) of FIG. 2. The HMI acceleration D2 of this embodiment is applied to the case where the vehicle 100 is traveling forward. In the HMI acceleration D2, the acceleration C alternates between zero and a designated acceleration D2A over time. The designated acceleration D2A is a negative value. The designated acceleration D2A is determined in advance by experiment or simulation as a value suitable for calling the occupant's attention. In the example of (b) of FIG. 2, the HMI acceleration D2 changes so that two decelerations are realized during the control period T. In the example of FIG. 2B, the duration of the designated acceleration D2A and the duration of the zero acceleration C are set to be the same. The control period T is predetermined as an appropriate length of time for continuing to call the attention of the occupant. The control period T is, for example, 1 second. The control period T is longer than one cycle of the above-mentioned predetermined control period. Here, when the command ECU 50 is executing the HMI application A2, it repeatedly outputs the HMI acceleration D2 during the control period T every time a predetermined condition for calling the attention of the occupant is satisfied. The command ECU 50 outputs the HMI acceleration D2 at the same control period as the driving application A1. In addition, when outputting the HMI acceleration D2, the command ECU 50 assigns a second identification value to the HMI acceleration D2. The second identification value is a data identification value indicating that the content of the motion request is the HMI acceleration D2. The second identification value is predetermined as a value different from the first identification value.

[0016] As shown in Fig. 1, the memory of the command ECU 50 of this embodiment stores only one HMI application A2. On the other hand, the memory of the command ECU 50 stores a plurality of different driving applications A1. Note that Fig. 1 shows two representative applications A1 out of the plurality of driving applications A1.

[0017] <Management ECU> As shown in FIG. 3, the management ECU 10 is a computer equipped with a processing circuit 10A. The processing circuit 10A includes a CPU 11 and a memory 12. The memory 12 stores in advance various programs W in which processes to be executed by the CPU 11 are described. The CPU 11 of the management ECU 10 executes the program W stored in the memory 12, so that the management ECU 10 functions as a motion manager of the vehicle 100. The motion manager fulfills the function of managing the motion of the vehicle 100 requested by an application A. The management ECU 10 can exchange information with the command ECU 50 and the ECUs of each actuator system via an internal bus (not shown). The management ECU 10 also sequentially acquires information from various sensors 101.

[0018] The following describes the function of the management ECU 10 as a motion manager, focusing on the acceleration C of the vehicle 100. The management ECU 10 is capable of executing management processing. The management processing is processing for centrally managing the acceleration C of the vehicle 100. As shown in FIG. 1, when executing the management processing, the management ECU 10 functions as a reception unit 20, a first arbitration unit 21, a second arbitration unit 22, and an output unit 23.

[0019] The management ECU 10 repeatedly executes the management process at the above-mentioned predetermined control period. If the management ECU 10 does not receive a motion request from any of the applications A, it ends one cycle of the management process without executing the processing of each step described below. In this case, the control of each actuator 72, 82 based on the motion request from the application A is not executed.

[0020] As shown in FIG. 4, the management ECU 10 first performs the process of step S11 in the management process. In step S11, the reception unit 20 performs the reception process. In the reception process, the reception unit 20 receives a motion request from each application A as shown in FIG. 1. That is, the reception unit 20 receives a requested acceleration D1 from the driving application A1. The reception unit 20 also receives an HMI acceleration D2 from the HMI application A2. When the reception unit 20 receives a motion request from each application A, the reception unit 20 grasps the content of the motion request based on the data identification value attached to each motion request. The memory 12 of the management ECU 10 previously stores each data identification value and the content of the motion request indicated by each data identification value in association with each other. When the reception unit 20 grasps the content of the motion request, the reception unit 20 outputs the motion request to either the first arbitration unit 21 or the second arbitration unit 22 according to the content. The reception unit 20 outputs the requested acceleration D1, which is a motion request from the driving application A1, to the first arbitration unit 21. On the other hand, the reception unit 20 outputs the HMI acceleration D2, which is a motion request from the HMI application A2, to the second arbitration unit 22. Note that the reception unit 20 may perform the process of step S11 under a situation where there is a motion request from the driving application A1 but no motion request from the HMI application A2. In this case, the reception unit 20 accepts only the motion request from the driving application A1 in step S11. Then, the reception unit 20 outputs all the accepted motion requests to the first arbitration unit 21. As shown in FIG. 4, when the management ECU 10 finishes the process of step S11, the management ECU 10 advances the process to step S12.

[0021] In step S12, the first arbitration unit 21 performs a first arbitration step. As shown in FIG. 1, the first arbitration unit 21 arbitrates the requested acceleration D1 output from the reception unit 20, that is, the requested acceleration D1 received by the reception unit 20 in step S11. The first arbitration unit 21 selects the requested acceleration D1 with the smallest value among the multiple requested accelerations D1 received by the reception unit 20. Then, the first arbitration unit 21 calculates a selected acceleration D1X, which is the selected requested acceleration D1, as a basic arbitration result. After that, the first arbitration unit 21 outputs the selected acceleration D1X to the second arbitration unit 22. After that, as shown in FIG. 4, the management ECU 10 advances the process to step S13.

[0022] In step S13, the second arbitration unit 22 performs a determination step. Specifically, the second arbitration unit 22 determines whether or not the HMI acceleration D2 has been acquired from the reception unit 20, that is, whether or not the reception unit 20 has accepted the HMI acceleration D2 from the HMI application A2 in step S11. If the second arbitration unit 22 has not acquired the HMI acceleration D2 from the reception unit 20 (step S13: NO), the second arbitration unit 22 performs the following. That is, the second arbitration unit 22 outputs the selected acceleration D1X acquired from the first arbitration unit 21 through the process of step S12 to the output unit 23 as the final arbitration result F. At the same time, the management ECU 10 skips the process of step S14, which will be described later, and proceeds to step S15.

[0023] On the other hand, when the second arbitration unit 22 acquires the HMI acceleration D2 from the reception unit 20 in step S13, that is, when the reception unit 20 accepts the HMI acceleration D2 from the HMI application A2 in step S11 (step S13: YES), the process proceeds to step S14. In this case, the second arbitration unit 22 performs a second arbitration step in step S14. As shown in FIG. 1, in the second arbitration step, the second arbitration unit 22 arbitrates between the selected acceleration D1X acquired from the first arbitration unit 21 and the HMI acceleration D2 acquired from the reception unit 20. Specifically, the second arbitration unit 22 superimposes the HMI acceleration D2 on the selected acceleration D1X. A specific aspect of this superposition will be described. In the following description, it is assumed that the selected acceleration D1X is constant at the negative specified acceleration D1A throughout the entire control period T, as shown in FIG. 2(a). The second arbitration unit 22 calculates an arbitrated acceleration D3, which is a result of the different arbitration, by adding the HMI acceleration D2 shown in FIG. 2B to the selected acceleration D1X shown in FIG. 2A. Here, the HMI acceleration D2 is either zero or the specified acceleration D2A. Therefore, as shown in FIG. 2C, the arbitrated acceleration D3 takes the value of either the specified acceleration D1A or the added value DP obtained by adding the specified acceleration D2A to the specified acceleration D1A. When the arbitrated acceleration D3 is viewed in time series, as shown in FIG. 2C, the specified acceleration D1A decreases to the added value DP twice during the control period T. As shown in FIG. 1, when the second arbitration unit 22 calculates the arbitrated acceleration D3, it outputs the arbitrated acceleration D3 to the output unit 23 as the final arbitration result F. Thereafter, as shown in FIG. 4, the management ECU 10 advances the process to step S15.

[0024] In step S15, the output unit 23 performs a calculation step. As shown in Fig. 1, in this calculation step, the output unit 23 calculates instruction information K for the actuator 82 of the first actuator system 70 and the actuator 82 of the second actuator system 80 based on the final arbitration result F. If the reception unit 20 does not receive HMI acceleration D2 from the HMI application A2 in step S11, the output unit 23 calculates the instruction information K based on the selected acceleration D1X which is the basic arbitration result. On the other hand, if the reception unit 20 receives HMI acceleration D2 in step S11, the output unit 23 calculates the instruction information K based on the arbitration acceleration D3 which is the heterogeneous arbitration result.

[0025] The output unit 23 calculates the instruction information K as follows. First, the output unit 23 determines the allocation of the final arbitration result F to the first actuator system 70 and the second actuator system 80 based on the magnitude of the final arbitration result F, which is an acceleration value. Then, the output unit 23 converts the values ​​of the final arbitration result F allocated to each of them into a unit of force. Then, the output unit 23 calculates the converted value as the instruction information K. When the final arbitration result F is a positive value, the output unit 23 calculates the instruction information K such that the driving force of the vehicle 100 increases as the final arbitration result F increases. On the other hand, when the final arbitration result F is a negative value, the output unit 23 calculates the instruction information K such that the braking force of the vehicle 100 increases as the first acceleration decreases. In this way, the output unit 23 calculates the instruction information K according to the final arbitration result F for each actuator system.

[0026] After calculating each piece of command information K as described above, the output unit 23 outputs each piece of calculated command information K to the engine ECU 75 and the brake ECU 85. After that, as shown in Fig. 4, the management ECU 10 ends the process of step S15. At the same time, the management ECU 10 ends the series of processes of the management process and executes each process of the management process again.

[0027] <Operation of the embodiment> Now, as shown in FIG. 1, it is assumed that a requested acceleration D1 from two driving applications A1 and an HMI acceleration D2 from an HMI application A2 are output. In this case, the management ECU 10 performs two-stage arbitration to arbitrate these three motion requests. First, as the first stage arbitration, the first arbitration unit 21 arbitrates the requested acceleration D1 from the two driving applications A1. That is, the first arbitration unit 21 selects the smaller of the two requested accelerations D1 as a selected acceleration D1X. After that, as the second stage arbitration, the second arbitration unit 22 calculates an arbitrated acceleration D3 by adding the selected acceleration D1X and the HMI acceleration D2 from the HMI application A2. When viewed throughout the entire control period T, the second arbitration unit 22 calculates an arbitrated acceleration D3 at each timing by intermittently decreasing the specified acceleration D1A, which is the selected acceleration D1X, according to the HMI acceleration D2 at each timing, as shown in FIG. 2(c). In response to the calculation of the arbitrated acceleration D3, the output unit 23 calculates command information K corresponding to the arbitrated acceleration D3. The output unit 23 then outputs the calculated command information K to the engine ECU 75 and the brake ECU 85. These ECUs 75, 85 then control the target actuators 72, 82 in accordance with the command information K. As a result, in the vehicle 100, a transition is achieved in which the selected acceleration D1X intermittently decreases, as shown in FIG. 2(c).

[0028] <Effects of the embodiment> (1) As described in the operation of the above embodiment, when the management ECU 10 receives motion requests from both the driving application A1 and the HMI application A2, it performs two-stage arbitration. In the second stage of the two-stage arbitration, the management ECU 10 arbitrates the different types of motion requests using a rule different from that of the first stage arbitration, which is to select one of a plurality of motion requests. In the second stage arbitration, the management ECU 10 performs arbitration in a manner that cooperates both of the different types of motion requests. In this way, the management ECU 10 can reflect the motion request from the HMI application A2 in the instruction information K without submerging it in the motion request from the driving application A1. That is, in this embodiment, when there are different types of motion requests, that is, a motion request for driving the vehicle 100 and a motion request for alerting the occupants, both of these motion requests can be reflected in the control of the vehicle 100.

[0029] (2) In the second stage of arbitration, the management ECU 10 adds the selected acceleration D1X and the HMI acceleration D2. By adding the two accelerations C in this manner, the management ECU 10 can reliably reflect the two accelerations C in the arbitration acceleration D3.

[0030] (3) As in this embodiment, when the HMI acceleration D2 that intermittently decelerates the vehicle 100 is superimposed on the required acceleration D1 for the vehicle 100 to travel, the following becomes possible. That is, for example, as shown in FIG. 2(c), the vehicle 100 can be braked intermittently while the vehicle 100 is decelerating.

[0031] <Example of change> The above embodiment can be modified as follows: The above embodiment and the following modified examples can be implemented in combination with each other to the extent that there is no technical contradiction.

[0032] The manner of superimposing the selected acceleration D1X and the HMI acceleration D2 is not limited to the example of the above embodiment. For example, multiplication may be used instead of addition to superimpose these two accelerations C. When multiplication is used as the manner of superimposition, it is possible to convert the HMI acceleration D2 into an appropriate coefficient and multiply it by the selected acceleration D1X.

[0033] The method of arbitration between the selected acceleration D1X and the HMI acceleration D2 is not limited to using superposition. The arbitration method may be any method that can reflect both the selected acceleration D1X and the HMI acceleration D2 in the heterogeneous arbitration result and, ultimately, in the instruction information K.

[0034] Regarding the motion request from the HMI application A2, the number of decelerations when intermittently decelerating the vehicle 100 can be changed as appropriate. The motion request from the HMI application A2 is not limited to a request to intermittently decelerate the vehicle 100. Any motion request may be made so that the vehicle 100 can transmit appropriate information to the occupants.

[0035] The command ECU 50 may store multiple HMI applications A2. Even in this case, a pre-processing may be configured so that the motion request of the HMI application A2 participating in the arbitration in the second arbitration step is one. Then, in the second arbitration step, the motion request from any of the HMI applications A2 and the basic arbitration result are arbitrated to calculate the heterogeneous arbitration result.

[0036] The method of arbitration between exercise requests from the running application A1 is not limited to the example in the above embodiment. It is sufficient to determine arbitration rules so that an appropriate arbitration result is obtained. The driving application A1 is not limited to controlling the acceleration C of the vehicle 100 while driving. The driving application A1 may control the steering angle of the vehicle 100 while driving. Similarly, the HMI application A2 may realize information transmission from the vehicle 100 to the occupants through a change in the steering angle of the vehicle 100. When the parameter handled by the motion request is the steering angle of the vehicle 100, as in the above embodiment, a basic arbitration result that arbitrates the motion requests of the driving application A1 is calculated, and then a heterogeneous arbitration result that arbitrates the basic arbitration result and the motion request from the HMI application A2 may be calculated. Then, instruction information for the actuator of the steering system may be calculated based on the heterogeneous arbitration result. When arbitrating the basic arbitration result and the motion request from the HMI application A2, they may be superimposed, as in the above embodiment. As long as both the basic arbitration result and the motion request from the HMI application A2 can be reflected in the heterogeneous arbitration result and thus the instruction information, any arbitration method is acceptable. When the parameter handled by the motion request is the steering angle of the vehicle 100, the motion request from the driving application A1 may be, for example, a requested steering angle of the steering wheel. The motion request from the HMI application A2 may be, for example, a request to yaw the steering wheel left and right within a predetermined control period when viewed in a time series. If the steering wheel is controlled by reflecting both of these motion requests in the instruction information, the steering wheel can be turned and yawed left and right at the same time. The steering angle may be determined, for example, as an angle from the neutral position of the steering wheel when the vehicle 100 travels straight.

[0037] The overall configuration of the vehicle 100 is not limited to the example of the above embodiment. For example, the drive source of the vehicle 100 may be a motor generator instead of or in addition to the engine 71. When the vehicle 100 is equipped with a motor generator, a control device that controls the motor generator may be installed in the vehicle. When these devices are provided in the vehicle, an actuator system including the motor generator, which is an actuator, and a control device for the motor generator is installed in the vehicle.

[0038] The processing circuit 10A of the management ECU 10 may have any one of the following configurations (a) to (c). This also applies to the processing circuits of other ECUs, such as the command ECU 50.

[0039] (a) The processing circuit 10A includes one or more processors that execute various processes according to a computer program. The processor includes a CPU and memory such as RAM and ROM. The memory stores program codes or instructions configured to cause the CPU to execute processes. The memory, i.e., computer-readable medium, includes any available medium that can be accessed by a general-purpose or special-purpose computer.

[0040] (b) The processing circuit 10A includes one or more dedicated hardware circuits for executing various processes. Examples of the dedicated hardware circuits include application specific integrated circuits, i.e., ASIC and FPGA. ASIC is an abbreviation for "Application Specific Integrated Circuit" and "FPGA" is an abbreviation for "Field Programmable Gate Array."

[0041] (c) The processing circuit 10A includes a processor that executes some of the various processes in accordance with a computer program, and a dedicated hardware circuit that executes the remaining processes among the various processes. [Explanation of symbols]

[0042] 10... Management ECU 72... Actuator 75... Engine ECU 82... Actuator 85... Brake ECU 100... Vehicle

Claims

1. accepting exercise requests from a plurality of applications; arbitrating the received exercise requests; and Calculating command information for an actuator of the vehicle based on a result of the arbitration of the motion requests; outputting the calculated instruction information to a control device of the actuator; It is possible to execute One or more of the plurality of applications is a driving application for controlling one or more selected from an acceleration of the vehicle and a steering angle of the vehicle, Another one or more of the plurality of applications is an HMI application for realizing information transmission from the vehicle to a passenger, When the motion request from the HMI application is not accepted, the instruction information is calculated based on a result of arbitration of the motion request from the driving application; When the exercise request from the HMI application is received, the instruction information is calculated based on a heterogeneous arbitration result that is a result of arbitration between the exercise request from the driving application and the exercise request from the HMI application. Vehicle motion manager.

2. The result of the arbitration of the motion request from the driving application and the result of the superimposition of the motion request from the HMI application are regarded as the heterogeneous arbitration result. The vehicle motion manager of claim 1 .

3. the motion request from the driving application is a request for acceleration to be realized by the vehicle; the motion request from the HMI application is a request to intermittently decelerate the vehicle within a predetermined control period; The acceleration indicated by the motion request of the driving application is intermittently decreased in accordance with the motion request from the HMI application, thereby calculating the heterogeneous arbitration result. The vehicle motion manager of claim 2 .

Images