Vehicle motion manager, vehicle control method, and vehicle control program

Abstract

To prevent the situation where a kinetic request without degeneration is not achieved for a long time from continuing.SOLUTION: A kinetic manager of a vehicle comprises: a reception part 11 which can receive acceleration request value with degeneration from a first application and acceleration request value without degeneration from a second application; a mediation part 12 which selects the minimum value of the acceleration request among the acceleration request values received by the reception part 11; a degeneration part 15 which outputs, when the mediation part 12 selects the acceleration request value with degeneration, a degeneration value which makes the acceleration request value come to an end value determined in advance with the lapse of time; and an output part 13 which outputs indicated value according to the acceleration request value selected by the mediation part 12 or the degeneration value into an actuator of a vehicle. When and after the mediation part 12 selects the acceleration request value with degeneration, the reception part 11 receives the degeneration value instead of the acceleration request value with degeneration from the first application.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present invention relates to a vehicle motion manager, a vehicle control method, and a vehicle control program. [Background Art]

[0002] The vehicle control system disclosed in Patent Document 1 includes a plurality of execution units, a motion manager, and an actuator. Each execution unit executes an individual application. The motion manager receives motion requests from a plurality of applications. The motion manager then arbitrates between the plurality of motion requests. That is, the motion manager selects one of the plurality of motion requests. Then, the motion manager generates a command value for the actuator based on the motion request that won the arbitration. [Prior Art Literature] [Patent Literature]

[0003] [Patent Document 1] Japanese Unexamined Patent Publication No. 2020-032894 [Summary of the Invention] [Problem to be Solved by the Invention]

[0004] Some motion requests from applications require degradation depending on the vehicle state. Here, degradation of a motion request means, for example, when the motion request is an acceleration request, gradually bringing the requested acceleration value closer to a predetermined end value over time. Assume that as a result of arbitrating motion requests from a plurality of applications, a motion request requiring degradation wins the arbitration. In this case, the motion manager gradually degrades the motion request according to the vehicle state, so it can eventually terminate the control of the actuator. However, even in a situation where a driving request requiring degradation wins the arbitration, there may be situations where it is necessary to implement a motion request from another application without terminating the control of the actuator. [Means for solving the problem]

[0005] A vehicle motion manager for solving the above problems includes: a receiving unit that can receive acceleration request values ​​requiring degeneracy from a first application and acceleration request values ​​that do not require degeneracy from a second application; an arbitration unit that selects the smallest acceleration request value from among the acceleration request values ​​received by the receiving unit; a degeneracy unit that, when the arbitration unit selects an acceleration request value requiring degeneracy, outputs a degeneracy value that approaches a predetermined endpoint over time; and an output unit that outputs an instruction value corresponding to the acceleration request value selected by the arbitration unit or the degeneracy value to the vehicle's actuators. When the arbitration unit selects an acceleration request value requiring degeneracy, the receiving unit accepts the degeneracy value instead of the acceleration request value requiring degeneracy from the first application.

[0006] A vehicle control method for solving the above problems is a vehicle control method using a computer mounted on the vehicle, wherein the computer receives acceleration request values ​​requiring degradation from a first application and acceleration request values ​​not requiring degradation from a second application, selects the smallest acceleration request value from the received acceleration request values, outputs a degraded value which is the acceleration request value approached a predetermined end value over time if an acceleration request value requiring degradation is selected in the selection of acceleration request values, outputs an instruction value corresponding to the acceleration request value selected in the selection of acceleration request values ​​or the degraded value to the vehicle's actuator, and further, triggered by the selection of an acceleration request value requiring degradation in the selection of acceleration request values, accepts the degraded value in place of the acceleration request value requiring degradation from the first application.

[0007] A vehicle control program for solving the above problems is a program for a computer mounted on the vehicle, which causes the computer to receive acceleration request values ​​requiring degradation from a first application and acceleration request values ​​not requiring degradation from a second application, to select the smallest acceleration request value from the received acceleration request values, to output a degraded value which is an acceleration request value that approaches a predetermined end value over time if an acceleration request value requiring degradation is selected in the selection of acceleration request values, and to output an instruction value corresponding to the acceleration request value selected in the selection of acceleration request values, or the degraded value, to the vehicle's actuators, and further, triggered by the selection of an acceleration request value requiring degradation in the selection of acceleration request values, the computer receives the degraded value instead of the acceleration request value requiring degradation from the first application.

[0008] In each of the above technical concepts, if the acceleration request value requiring degeneracy from the first application wins the arbitration, the degeneracy value, which approaches the endpoint value over time, is received by the reception unit. Eventually, the acceleration request value from the second application will win the arbitration. As a result, the situation in which the motion request from the second application cannot be fulfilled for an extended period of time is prevented. [Brief explanation of the drawing]

[0009] [Figure 1] This is a schematic diagram of the vehicle's configuration. [Figure 2] This is a schematic diagram of the management ECU. [Figure 3] This is a schematic diagram illustrating the period during which a specific process is to be executed. [Figure 4] This is a flowchart illustrating the processing steps for management tasks. [Figure 5] This is a flowchart illustrating the processing steps for determining whether or not degradation is necessary. [Figure 6] This is a schematic diagram illustrating the flow of information between each functional unit in a specific process. [Figure 7]This figure shows an example of the change in acceleration requirement values ​​during the execution of degraded processing. [Modes for carrying out the invention]

[0010] Hereinafter, an embodiment of the vehicle's motion manager, vehicle control method, and vehicle control program will be described with reference to the drawings. <Overall vehicle configuration> As shown in Figure 1, the vehicle 100 includes a command ECU 50, a management ECU 10, a first actuator system 70, and a second actuator system 80.

[0011] The first actuator system 70 comprises an engine 71 and an engine ECU 75 that controls the engine 71. The engine 71 is the power source for the vehicle 100. The engine 71 is equipped with multiple actuators 72, such as a throttle valve, fuel injector, and ignition device. In Figure 1, only one of the multiple actuators 72 is shown as a representative example. The engine ECU 75 is a computer equipped with a CPU, non-volatile memory, and volatile memory. The non-volatile memory pre-stores various programs that describe the processes that the CPU should execute. The engine ECU 75 controls each actuator 72 of the engine 71 based on instruction values ​​from a higher-level device, such as a management ECU 10. As each actuator 72 is controlled, fuel is burned in the engine 71. At the same time, driving force is generated in the vehicle 100. Thus, the first actuator system 70 includes actuators 72. The engine 71 is equipped with various sensors to understand the operating status of various parts, including the actuators 72. The engine ECU 75 sequentially acquires the detection values ​​from these various sensors. Based on the information acquired from these sensors, the engine ECU 75 detects any malfunction in the engine 71.

[0012] The second actuator system 80 comprises a plurality of brake devices 81 and a brake ECU 85 that controls each brake device 81. In Figure 1, only one of the plurality of brake devices 81 is shown as a representative example. A brake device 81 is provided for each wheel of the vehicle 100. Each brake device 81 comprises a disc 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 equipped with a CPU, non-volatile memory, and volatile memory. The non-volatile memory pre-stores various programs that describe the processes that the CPU should execute. The brake ECU 85 controls the hydraulic pressure of the actuator 82 based on instruction values ​​from a higher-level device, such as a management ECU 10. When the brake pad is pressed against the disc in accordance with the hydraulic pressure control, braking force is generated in the vehicle 100. Thus, the second actuator system 80 includes actuators 82. Each brake device 81 is equipped with various sensors to understand the operating status of various parts, including the actuator 82. The brake ECU 85 sequentially acquires the detection values ​​from these various sensors. Based on the information acquired from the various sensors, the brake ECU 85 detects a malfunction in the brake system 81.

[0013] Although not shown in the diagram, vehicle 100 is equipped with other actuator systems in addition to 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 steering wheels of vehicle 100.

[0014] <Outline configuration of the command ECU> The command ECU 50 is a computer equipped with a CPU, non-volatile memory, and volatile memory. The non-volatile memory pre-stores various programs that describe the processes to be executed by the CPU. Examples of programs stored in the non-volatile memory are multiple application APs for controlling the motion of the vehicle 100. The command ECU 50 functions as an execution device that executes these application APs that it has stored. When the command ECU 50 executes a particular application AP, it outputs a motion request for the application AP to be executed. The command ECU 50 may execute multiple application APs simultaneously. The motion request includes an acceleration request value, which is the requested value of the acceleration to be generated in the vehicle 100. The acceleration request value can be positive or negative. The command ECU 50 treats the acceleration when the vehicle 100 is accelerating forward as a positive value. The command ECU 50 also sequentially acquires information detected by various sensors (not shown). The command ECU 50 refers to the information acquired from these various sensors when executing the application APs. The various sensors include devices that detect the driving status of vehicle 100, such as the vehicle's speed. The various sensors include devices that detect information about the vehicle's surroundings, such as cameras and radar. The various sensors include devices that detect the vehicle's current position coordinates.

[0015] In the following, even though the command ECU 50 is actually the main component, the content may be described as being primarily from the perspective of the application AP being executed. For example, acceleration requests from the command ECU 50 may be referred to as acceleration requests from the application AP, and the acceptance of acceleration requests from the command ECU 50 may be referred to as accepting acceleration requests from the application AP.

[0016] The application APs stored in the command ECU 50 can be broadly classified into two types: first applications and second applications. The first applications are application APs that output acceleration request values ​​requiring degradation when a malfunction is detected in the vehicle 100. Degradation is the process of gradually bringing the acceleration request value from the application AP closer to a predetermined end value over time. In this embodiment, the first applications are limited to application APs that output negative acceleration request values. One of the first applications stored in the command ECU 50 is a so-called collision damage mitigation brake application that applies the brakes to the vehicle 100 to reduce collision damage to the vehicle 100. Hereafter, this application AP will be referred to as AEB (Autonomous Emergency Braking) application AP1. There are other first applications besides AEB application AP1, but their explanation will be omitted here. The second applications are application APs that output acceleration request values ​​that do not require degradation, regardless of whether a malfunction is detected in the vehicle 100 or not. One of the second applications stored in the command ECU 50 is an application AP that realizes the function of autonomous driving. In the following, this application AP will be referred to as AD (Autonomous Driving) application AP2. By running AD application AP2, vehicle 100 can be driven unmanned. There are other second applications besides AD application AP2, but their explanation will be omitted here. Regardless of whether it is the first or second application, each application AP is pre-assigned a unique identifier.

[0017] <Overview of the Management ECU configuration> As shown in Figure 2, the management ECU 10 is a computer including a CPU 21, a non-volatile memory 22, and a volatile memory 23. The non-volatile memory 22 previously stores various programs W describing processes to be executed by the CPU 21. The management ECU 10 can exchange information with a command ECU 50 and ECUs of respective actuator systems via an internal bus (not shown).

[0018] When the CPU 21 of the management ECU 10 executes the program W stored in the non-volatile memory 22, the management ECU 10 functions as a motion manager that manages the motion of the vehicle 100 requested by an application AP. That is, the management ECU 10 is the control entity in the control method for the vehicle 100. Hereinafter, the processing performed by the management ECU 10 will be described, targeting acceleration request values among motion requests from the application AP.

[0019] The management ECU 10 can execute management processing for integrated management of acceleration request values from the application AP. As shown in Figure 1, the management ECU 10, by executing the program W, functions as a receiving unit 11, an arbitration unit 12, and an output unit 13 to implement the management processing. The receiving unit 11 can receive acceleration request values from each application AP. There are the following three types of acceleration request values that the receiving unit 11 can receive. The three types of acceleration request values are: an acceleration request value requiring degradation from a first application, an acceleration request value not requiring degradation from the first application, and an acceleration request value not requiring degradation from a second application. The arbitration unit 12 selects the smallest acceleration request value from among the plurality of acceleration request values received by the receiving unit 11. Note that the arbitration unit 12 may also select a degradation value, which is a type of acceleration request value. The degradation value will be described later. The output unit 13 outputs the acceleration request value selected by the arbitration unit 12, or an instruction value corresponding to the degradation value, to the actuator system.

[0020] As shown in Figure 3, there are two types of management processes: normal processes and specific processes. Normal processes are those performed under normal circumstances when no fault is detected in the vehicle 100. Specific processes are those performed when a fault is detected in the vehicle 100, and are specifically for fault situations. More specifically, specific processes are those performed during the execution period N of the degradation process described later. The management ECU 10 realizes the acceleration request value from the application AP by performing one of these processes. The management ECU 10 performs specific processes when the arbitration unit 12 selects an acceleration request value that requires degradation during normal processes. In specific processes, the receiving unit 11 of the management ECU 10 receives a degraded value instead of an acceleration request value that requires degradation from the first application.

[0021] The management ECU 10 is capable of executing a degradation process as a process to achieve the degradation of the acceleration request value related to the first application. As shown in Figure 1, the management ECU 10 functions as a degradation unit 15 that realizes this degradation process by executing program W. The degradation unit 15 performs the degradation process as part of a degradation necessity process that determines whether or not degradation is necessary. In the degradation process, when the arbitration unit 12 selects an acceleration request value that requires degradation in the normal process, the degradation unit 15 outputs a degraded value that approaches a predetermined termination value over time.

[0022] The management ECU 10 continuously acquires information about the presence or absence of malfunctions in various parts of the vehicle 100 as fault information. This fault information is sent from ECUs that control various parts of the vehicle 100, such as the engine ECU 75 and the brake ECU 85. As explained in relation to the engine ECU 75 and the brake ECU 85, each ECU detects faults based on sensor readings and other factors.

[0023] <Management Table> The management ECU 10 has a management table stored in advance. The management table is a table that summarizes whether or not acceleration request values ​​from application APs need to be reduced. The management table has the following four items defined for each application AP. The four items are the type of application AP, the identification value of the application AP, whether or not acceleration request values ​​need to be reduced according to each failure type, and the characteristics of the reduction defined for cases where reduction is necessary. The type of application AP is information that indicates whether it is the first application or the second application. The characteristics of the reduction are information for calculating the final value when reducing the acceleration request values. The characteristics of the reduction include information such as, for example, to what magnitude the acceleration request values ​​should be reduced. The contents defined in the management table differ between the first application and the second application as follows: In the first application, it is defined that reduction may be necessary depending on the failure type. On the other hand, in the second application, it is defined that reduction is not necessary regardless of the failure type.

[0024] <Normal processing> The normal processing will be described in detail. As a prerequisite for explaining the normal processing, the command ECU 50 repeatedly outputs the identification value of the target application AP and the acceleration request value of the target application AP to the management ECU 10 in a predetermined first cycle while a specific application AP is being executed.

[0025] In this embodiment, the management ECU 10 starts normal processing in response to the command ECU 50 starting the AD application AP2. The management ECU 10 repeatedly performs normal processing in a predetermined second cycle while the command ECU 50 continues to execute the AD application AP2, that is, while the vehicle 100 is performing autonomous driving. The second cycle is, for example, the same as the first cycle.

[0026] As shown in Figure 4, in normal processing, the management ECU 10 first performs the process in step S11. In step S11, the reception unit 11 performs the reception process. In the reception process, as shown in Figure 1, the reception unit 11 receives the latest acceleration request value from the application AP along with the application AP identification value. The arrows in Figure 1 indicate the flow of information exchange between each ECU and each functional unit. As described above, the command ECU 50 may execute multiple application APs simultaneously. In this case, the reception unit 11 receives multiple acceleration request values, including the acceleration request value from AD application AP2. In the reception process, in addition to receiving the acceleration request values, the reception unit 11 checks the current fault information. Then, based on the fault information and the management table, the reception unit 11 determines whether or not degradation is necessary for each acceleration request value from each application AP. Then, the reception unit 11 determines how to handle each received acceleration request value according to whether or not degradation is necessary. For example, the reception unit 11 treats the acceleration request value from AD application AP2 as an acceleration request value that does not require degradation. For example, when the reception unit 11 receives an acceleration request value from the AEB application AP1, it handles this acceleration request value as follows: If a vehicle fault corresponding to the AEB application AP1 is detected, the reception unit 11 treats the acceleration request value from the AEB application AP1 as an acceleration request value requiring degradation. On the other hand, if no vehicle fault corresponding to the AEB application AP1 is detected, the reception unit 11 treats the acceleration request value from the AEB application AP1 as an acceleration request value that does not require degradation. When the reception unit 11 receives an acceleration request value in this manner, it generates reception data that consists of the received acceleration request value, information indicating whether degradation is necessary, and the identifier of the application AP. The reception unit 11 generates reception data for each application AP that has received an acceleration request value. The reception unit 11 then outputs all the generated reception data to the arbitration unit 12. As shown in Figure 4, when the management ECU 10 outputs the reception data, it proceeds to step S12.

[0027] In step S12, the arbitration unit 12 performs the arbitration process. In the arbitration process, the arbitration unit 12 arbitrates the acceleration request values ​​received by the reception unit 11. If the reception unit 11 has received only one acceleration request value from the AD application AP2, the arbitration unit 12 selects that acceleration request value. On the other hand, if the reception unit 11 has received multiple acceleration request values, the arbitration unit 12 selects the acceleration request value with the smallest value from among the multiple acceleration request values ​​received. As shown in Figure 1, once the arbitration unit 12 has selected an acceleration request value, it outputs the reception data containing that acceleration request value to both the output unit 13 and the degraded unit 15. After this, as shown in Figure 4, the management ECU 10 proceeds to step S13.

[0028] When the management ECU 10 proceeds to step S13, it performs an output process. This output process is performed by the output unit 13. As shown in Figure 1, in the output process, the output unit 13 outputs instruction values ​​to each actuator system according to the acceleration request value selected by the arbitration unit 12. At this time, the output unit 13 distributes the acceleration request value selected by the arbitration unit 12 to the first actuator system 70 and the second actuator system 80. The output unit 13 then calculates instruction values ​​by converting the distributed values ​​into units of force. If the acceleration request value selected by the arbitration unit 12 is a positive value, the output unit 13 calculates instruction values ​​such that the larger the acceleration request value, the greater the driving force of the vehicle 100. If the acceleration request value selected by the arbitration unit 12 is a negative value, the output unit 13 calculates instruction values ​​such that the smaller the acceleration request value, the greater the braking force of the vehicle 100. The output unit 13 calculates instruction values ​​for each actuator system in this manner. The output unit 13 calculates each instruction value and outputs the calculated instruction value to each actuator system. After this, as shown in Figure 4, the management ECU 10 temporarily terminates the series of processes of normal operation. Then, the management ECU 10 performs the process of step S11 again.

[0029] <Processing to determine whether or not degradation is necessary> Before explaining the specific processing, let's explain the degradation necessity processing. The degradation unit 15 performs the degradation necessity processing each time the mediation unit 12 performs the mediation process in normal processing.

[0030] As shown in Figure 5, in the degradation necessity processing, the degradation unit 15 first performs the processing in step S100. In step S100, the degradation unit 15 obtains the latest arbitration result output by the arbitration unit 12. That is, as shown in Figure 1, the degradation unit 15 obtains reception data including the acceleration request value selected by the arbitration unit 12. When the degradation unit 15 obtains new reception data, it clears the previously obtained reception data. As shown in Figure 5, once the degradation unit 15 obtains reception data, it proceeds to step S110.

[0031] In step S110, the degeneration unit 15 determines whether the acceleration request value selected by the arbitration unit 12 is an acceleration request value that requires degeneration. The degeneration unit 15 makes this determination by referring to the information indicating the necessity of degeneration included in the received data. If the acceleration request value selected by the arbitration unit 12 is not an acceleration request value that requires degeneration (step S110: NO), the degeneration necessity processing is terminated.

[0032] On the other hand, in step S110, if the acceleration request value selected by the arbitration unit 12 is an acceleration request value that requires degeneration (step S110: YES), the degeneration unit 15 proceeds to step S120.

[0033] In step S120, the degradation unit 15 calculates an end value, which is the final target value for calculating the degradation value in the subsequent degradation process. The degradation unit 15 understands the following by referring to the management table, the application AP identifier included in the reception data, and fault information. Specifically, the degradation unit 15 understands the characteristics of degradation required under the current fault conditions for the first application that is the target of the degradation process. As mentioned above, the characteristics of degradation are one of the pieces of information included in the management table. Once the degradation unit 15 understands the characteristics of degradation, it calculates an end value based on these characteristics of degradation and the current driving state of the vehicle 100. The driving state of the vehicle 100 includes, for example, the driving speed of the vehicle 100 and the braking force applied to the vehicle 100. Here, due to the settings of the first application, the acceleration request value obtained by the degradation unit 15 in step S100 is a negative value. The degradation unit 15 calculates an end value that is greater than this acceleration request value. The end value can be a positive value, a negative value, or zero. The termination value is basically set to be greater than the acceleration request values ​​from application APs other than the application AP that is being subjected to the degraded processing. Once the degraded unit 15 calculates the termination value, it proceeds to step S130.

[0034] In step S130, the degeneration unit 15 executes the degeneration process. At this time, the degeneration unit 15 switches the degeneration flag, which indicates that the degeneration process is in progress, from off to on. Then, the degeneration unit 15 starts the degeneration process. In the degeneration process, the degeneration unit 15 repeatedly calculates the degeneration value in a predetermined third cycle. The third cycle is, for example, the same as the second cycle. The degeneration unit 15 calculates the degeneration value as follows. The degeneration unit 15 uses the acceleration request value obtained in step S100 as the initial value of the degeneration value. As described above, due to the settings of the first application, the initial value is a negative value. When calculating a new degeneration value, the degeneration unit 15 adds a predetermined positive value to the previous value of the degeneration value. Then, the degeneration unit 15 uses the obtained value as the new degeneration value. In this manner, the degeneration unit 15 repeatedly calculates the degeneration value. The degeneration unit 15 repeats the calculation of the degeneration value until the degeneration value reaches the final value. The degradation unit 15 terminates the calculation of the degradation value when the degradation value reaches the end value. During the degradation process, the degradation unit 15 outputs the calculated degradation value to the reception unit 11 each time it is calculated. When outputting the degradation value, the degradation unit 15 outputs degradation data, which is a set of data consisting of the degradation value, information indicating that it is a degradation value, and the identifier of the first application that was the target of the degradation process. When the degradation unit 15 finishes calculating the degradation value in accordance with the end value, it terminates the degradation process. At the same time, the degradation unit 15 switches the degradation flag from on to off. Then, the degradation unit 15 terminates the degradation necessity processing.

[0035] <Specific Processing> The specific processing will be described in detail. As a premise, in this embodiment, if the degradation flag is on, the command ECU 50 continues execution of the AD application AP2. Also, if the degradation flag is on, the command ECU 50 continues execution of the first application that is the target of the degradation process. For example, if a specific first application, such as the AEB application AP1, is the target of the degradation process, the command ECU 50 repeatedly outputs the acceleration request value which is the initial value for the degradation process. For example, by outputting degradation execution information to the command ECU 50 while the degradation unit 15 is executing the degradation process, the command ECU 50 can grasp the processing content of the management ECU 10 and reflect it in its own processing. The degradation execution information includes information that the degradation flag is on and the identifier of the first application that is the target of the degradation process. The command ECU 50 may terminate the execution of the first application that is the target of the degradation process in the middle of the period during which the degradation flag is on. In this case, only during the period when the degradation flag is on, the management ECU 10 performs the following pseudo-handling. In other words, the management ECU 10 treats the above initial values ​​as being output from the first application that is the target of the degraded processing.

[0036] The management ECU 10 performs a specific process instead of normal processing, provided that the degradation flag is turned on. That is, as shown in Figure 3, the management ECU 10 performs the specific process during the execution period N of the degradation process. The execution period N of the degradation process is the target period L of the specific process, and the period other than the execution period N of the degradation process is the target period T of normal processing. The management ECU 10 repeats the specific process in the above second cycle during the execution period N of the degradation process. The content of the specific process is basically the same as that of normal processing. Therefore, the following will mainly describe the specific process in terms of the parts that differ from normal processing.

[0037] As shown in Figure 4, in a specific process, the management ECU 10 first performs a reception process in step S11. In the reception process, the reception unit 11 of the management ECU 10 receives acceleration request values ​​from each application AP along with the application AP identifier, just as in normal processing. At this time, as illustrated in Figure 6 with AEB application AP1, the reception unit 11 receives the latest degraded value output by the degradation unit 15 instead of the acceleration request value from the first application that is the target of the degradation process. The situation in which the specific process is performed is when a vehicle failure corresponding to the first application that is the target of the degradation process has been detected. Therefore, the acceleration request value from the first application that is the target of the degradation process is an acceleration request value that requires degradation. That is, in the reception process, the reception unit 11 receives a degraded value instead of an acceleration request value from the first application that requires degradation. Now, in the reception process, the reception unit 11 cancels the reception of acceleration request values ​​from first applications other than the first application that is the target of the degradation process if the acceleration request value requires degradation. The reception unit 11 determines which acceleration request values ​​to accept and which to reject by referring to the application AP identifier, management table, and fault information contained in the degraded data output from the degraded unit 15. The reception unit 11 outputs the acceleration request values ​​received in this manner to the arbitration unit 12 as reception data in the same format as normal processing. The reception unit 11 will output reception data corresponding to at least two items to the arbitration unit 12: the acceleration request value from AD application AP2 and the degraded value. In addition, for reception data related to the degraded value, the reception unit 11 sets the information indicating whether degradation is necessary to indicate that degradation is required. That is, the reception unit 11 treats the degraded value as a type of acceleration request value that requires degradation. Here, the degraded value is the acceleration request value from the first application calculated by the management ECU 10 on behalf of the command ECU 50 according to the action plan defined in the first application.Furthermore, in the situation where specific processing is performed, as described above, a vehicle failure corresponding to the first application, which is the target of the degradation processing, has been detected. Therefore, the degradation value is the acceleration request value from the first application that requires degradation. As shown in Figure 4, when the management ECU 10 outputs each received data, it proceeds to step S12.

[0038] In step S12, the arbitration unit 12 of the management ECU 10 performs the arbitration process. Similar to normal processing, the arbitration unit 12 selects the smallest acceleration request value from among the multiple acceleration request values ​​received in the reception process. Then, as shown in Figure 6, the arbitration unit 12 outputs the selected acceleration request value to the output unit 13. After this, as shown in Figure 4, the management ECU 10 proceeds to step S13.

[0039] In step S13, the output unit 13 of the management ECU 10 performs an output process. As shown in Figure 6, in the output process, the output unit 13 outputs an instruction value to each actuator system corresponding to the acceleration request value selected by the arbitration unit 12, similar to normal processing. Note that the actuator systems are not shown in Figure 6. If the arbitration unit 12 selects a degraded value, the output unit 13 outputs an instruction value to each actuator system corresponding to the degraded value. The degraded value corresponds to the acceleration request value from the first application that requires degradation, as explained in the reception process above. That is, if the arbitration unit 12 selects an acceleration request value from the first application that requires degradation, the output unit 13 outputs an instruction value corresponding to the degraded value. On the other hand, if the arbitration unit 12 selects an acceleration request value from the second application, the output unit 13 outputs an instruction value to each actuator system corresponding to the acceleration request value from the second application. Note that the method of calculating the instruction value is the same as in normal processing, so the explanation is omitted. As shown in Figure 4, once the management ECU 10 outputs the instruction value, it temporarily terminates the series of processes for the specific process. Then, the management ECU 10 performs the process in step S11 again.

[0040] <Operation of the Embodiment> Let's assume that AD application AP2 is currently running. Let's also assume that the management ECU 10 continues to select the acceleration request value from AD application AP2 through normal processing. In other words, vehicle 100 is in autonomous driving mode. Let's assume that during this autonomous driving of vehicle 100, a situation arises where vehicle 100 should be subjected to emergency braking. Let's assume that AD application AP2 outputs a negative acceleration request value. Let's assume that AEB application AP1 is also activated at this time. In this case, due to the settings of each application AP, AEB application AP1 outputs a negative acceleration request value that has a larger absolute value than the acceleration request value from AD application AP2. Let's assume that a vehicle fault corresponding to AEB application AP1 is detected at this time. In this case, during the acceptance process of normal processing, the management ECU 10 accepts the acceleration request value from AEB application AP1 as an acceleration request value that requires degradation. Then, during the arbitration process of normal processing, the management ECU 10 selects the smaller of the acceleration request values ​​from AD application AP2 and AEB application AP1, which is the acceleration request value from AEB application AP1. Based on this selection result, the degradation unit 15 of the management ECU 10 starts the degradation process. The degradation unit 15 then repeatedly calculates the degraded value of the acceleration request value of the AEB application AP1. In Figure 7, the degraded value from time T1 to time T2, which is the initial stage of the degradation process, is shown by a solid line. As shown by this solid line, the degraded value approaches the final value Y as time progresses.

[0041] When the management ECU 10 starts the degradation process, it cancels the normal process and performs the specific process. As shown in Figure 6, in the acceptance process for the specific process, the management ECU 10 receives the acceleration request value from the AD application AP2 and the degradation value calculated by the degradation unit 15 during the degradation process. Here, in the initial stage of the degradation process, the degree of degradation of the degradation value is small. Therefore, as shown in Figure 7, during this initial stage from time T1 to time T2, in the arbitration process for the specific process, the management ECU 10 selects the smaller of the acceleration request value from the AD application AP2 (shown by the dashed line) and the degradation value (shown by the solid line). Then, in the output process, the management ECU 10 outputs an instruction value corresponding to this degradation value to the actuator system. Note that Figure 7 shows an example where the acceleration request value from the AD application AP2 is constant.

[0042] As described above, between time T1 and time T2, the degenerate value approaches the endpoint value Y as time progresses. In conjunction with this, at time T2, the degenerate value becomes larger than the negative acceleration request value of AD application AP2. In Figure 7, from time T2 onward, the acceleration request value of AD application AP2 is shown by a solid line, and the degenerate value is shown by a dashed line. When the degenerate value becomes larger than the acceleration request value of AD application AP2, as in the case from time T2 onward, the management ECU 10 performs the following in the arbitration process of a specific process. That is, the management ECU 10 selects the smaller of the acceleration request value of AD application AP2 and the degenerate value, which is the acceleration request value of AD application AP2. Then, in the output process, the management ECU 10 outputs an instruction value corresponding to the acceleration request value of AD application AP2 to the actuator system. In general, from time T1 onward, the management ECU 10 selects the acceleration request value shown by the solid line in Figure 7. Note that the degraded values ​​and acceleration request values ​​from AD application AP2 shown in Figure 7 are merely examples to illustrate the operation of the embodiment and do not necessarily correspond to actual results.

[0043] In the configuration of AEB application AP1, the output of acceleration request values ​​from AEB application AP1 stops at the stage when the degraded processing is completed or at the stage immediately preceding it. Therefore, when the management ECU 10 resumes normal processing upon completion of the degraded processing, it continues to output instruction values ​​corresponding to the acceleration request values ​​of AD application AP2 to the actuator system, as it did from the middle of the degraded processing onward.

[0044] <Effects of the Embodiment> (1) As described above, when the management ECU 10 selects an acceleration request value that requires degradation from the first application during the arbitration process of normal processing, it performs specific processing thereafter. The reception unit 11 then receives a degradation value that approaches the end value as time progresses during the reception process. The arbitration unit 12 then selects an acceleration request value from the AD application AP2 during the arbitration process. The output unit 13 outputs an instruction value that reflects this selection result to the actuator system. Therefore, with the configuration of this embodiment, it is possible to prevent a situation in which the request from the AD application AP2 cannot be fulfilled for a long time. For example, even if the braking request is forced to be degraded in a situation where emergency braking is required, the vehicle 100 can be reliably braked by the request from the AD application AP2 without having to terminate the braking control midway.

[0045] (2) When no malfunction is detected in the vehicle 100, the reception unit 11 accepts acceleration requests from the first application as acceleration requests that do not require degradation. Therefore, it is possible to prevent the arbitration process from rejecting requests from the first application even when no malfunction is detected in the vehicle 100.

[0046] <Example of changes> The above embodiment can be modified as follows. The above embodiment and the following modifications can be combined and implemented to the extent that they do not contradict each other technically.

[0047] In the above embodiment, the output unit 13 outputs an instruction value to the actuator system corresponding to the acceleration request value selected by the arbitration unit 12 during normal processing. If this embodiment is adopted, the processing content of the output unit 13 in specific processing may be changed as follows. That is, in specific processing, the output unit 13 does not have to output an instruction value to the actuator system corresponding to the acceleration request value or degenerate value selected by the arbitration unit 12. For example, in specific processing, if the arbitration unit 12 selects a degenerate value, the output unit 13 may output an instruction value to the actuator system corresponding to the acceleration request value which is the initial value of the degenerate processing, rather than an instruction value corresponding to this degenerate value. Thus, if the normal processing of the above embodiment is performed as the basic processing, the output unit 13 may output an instruction value corresponding to a value other than the acceleration request value or degenerate value selected by the arbitration unit 12 during specific processing.

[0048] As described in the above example of modification, the content of the specific processing is not limited to the example of the above embodiment. The specific processing can be configured such that the receiving unit 11 accepts a degraded value in place of an acceleration request value that requires degradation from the first application.

[0049] The timing of the termination of the degradation process is not limited to the examples of the above embodiment. For example, the degradation process may be terminated when the degradation value becomes greater than the acceleration request value from the second application.

[0050] The method for calculating the degraded value in the degradation process is not limited to the examples of the above embodiment. For example, the predetermined value used to calculate the degraded value may be gradually increased or decreased during the execution of the degradation process. The predetermined value may be set to a different value for each application AP. As long as the acceleration request value can be brought closer to the end value over time, the method for calculating the degraded value is not limited.

[0051] The method for calculating the termination value is not limited to the example of the above embodiment. In the above embodiment, the management table contained information about the characteristics of degeneration. The command ECU 50 may output this information about the characteristics of degeneration when executing the first application. That is, when the command ECU 50 executes a particular first application, it may calculate the information about the characteristics of degeneration along with the acceleration request value and output them to the management ECU 10. Alternatively, the command ECU 50 may calculate and output the termination value itself when executing the first application. In this case as well, the program content of the first application should be configured so that an appropriate termination value can be calculated based on the driving conditions of the vehicle 100. The management ECU 10 should then determine the termination value based on the information from the command ECU 50. The termination value only needs to be predetermined at the time the degeneration value is calculated.

[0052] It is not mandatory for the information output by the command ECU 50 when executing an application AP to include the identification value of the application AP being executed. For example, the command ECU 50 may output various information other than the application AP identification value, which was included in the management table of the above embodiment, along with the acceleration request value from the application AP. Then, based on that information, the management ECU 10 may make the same decisions as in the above embodiment and implement each process.

[0053] Regardless of whether or not there is a malfunction in the vehicle 100, acceleration requests from the first application may always be accepted as acceleration requests that require degradation. For example, among a plurality of first applications, some application APs may be configured to accept requests in this manner, while others may be configured to accept requests in the same manner as in the above embodiment. An appropriate acceptance method may be set according to the function of each first application.

[0054] - The specific processing may be performed only if a pre-specified first application among several first applications becomes the target of the degradation process. In this case, if a first application other than the specified first application becomes the target of the degradation process, the actuator system may output an instruction value corresponding to the degradation value until the degradation value reaches the termination value during the execution of the degradation process. Depending on the combination of application APs stored in the command ECU 50, it may be necessary to complete the degradation of control. The application APs for which the execution of the specific processing is specified may be one or more.

[0055] In the above embodiment, normal processing was performed while AD application AP2 was running. However, normal processing may also be performed when AD application AP2 is not running. And, as in the above embodiment, when an acceleration request value requiring degradation is received from the first application during normal processing, the process may transition to a specific process.

[0056] It is not mandatory that the application AP stored in the command ECU 50 includes the AEB application AP1. Similarly, it is not mandatory that the application AP stored in the command ECU 50 includes the AD application AP2. The above embodiment is effective not limited to these application APs, but when an acceleration request value requiring degradation is received from the first application and an acceleration request value that does not require degradation is received from the second application.

[0057] • It is possible that among the application APs stored in the command ECU 50, there is one that outputs a positive acceleration request value as the first application. In this case, while the degraded processing targeting this application AP is being executed, the system may be configured to perform other appropriate processing instead of the specific processing to output the optimal instruction value to each actuator system.

[0058] Instead of configuring the command ECU 50 and the management ECU 10 as separate processing units, a single processing unit may be configured to perform both the functions of the command ECU 50 and the management ECU 10. Similarly, for example, the ECU of an actuator system may be configured to perform the functions of the management ECU 10.

[0059] • A motor generator may be installed in the vehicle 100 as a power source for the engine 71, either in place of or in addition to the engine 71. In this case, an actuator system including a motor generator, which is an actuator, and an ECU that controls the motor generator may be installed in the vehicle 100.

[0060] The management ECU 10 is not limited to one equipped with a CPU and memory and executing software processing. In other words, the management ECU 10 can have any of the following configurations: (a), (b), and (c). The same applies to the other ECUs.

[0061] (a) The management ECU 10 has one or more processors that perform various processes according to a computer program. The processors include a CPU and memory such as RAM and ROM. The memory stores program code or instructions configured to cause the CPU to perform processes. The memory, i.e., computer-readable media, includes any available media that can be accessed by a general-purpose or dedicated computer.

[0062] (b) The management ECU 10 includes one or more dedicated hardware circuits that perform various processes. Examples of dedicated hardware circuits include application-specific integrated circuits, i.e., ASICs or FPGAs.

[0063] (c) The management ECU 10 includes a processor that executes some of the various processes according to a computer program, and dedicated hardware circuits that execute the remaining processes of the various processes. [Explanation of Symbols]

[0064] 10…Management ECU 11…Reception Department 12...Mediation Department 13…Output section 15...Degenerate section 72… Actuator 82… Actuator 100...vehicles

Claims

1. A receiving unit capable of receiving acceleration request values ​​that require degradation from the first application and acceleration request values ​​that do not require degradation from the second application, The arbitration unit selects the smallest acceleration request value from among the acceleration request values ​​received by the reception unit, When the arbitration unit selects an acceleration request value that requires degeneracy, the degeneracy unit outputs a degeneracy value that approaches a predetermined termination value over time, An output unit that outputs an acceleration request value selected by the arbitration unit, or an instruction value corresponding to the degeneracy value, to the vehicle's actuator, Equipped with, When the arbitration unit selects an acceleration request value that requires degradation, the receiving unit accepts the degraded value from the first application in place of the acceleration request value that requires degradation. Vehicle motion manager.

2. The output unit outputs an instruction value to the actuator corresponding to the degraded value when the arbitration unit selects an acceleration request value from the first application that requires degradation, while outputting an instruction value to the actuator corresponding to the acceleration request value from the second application when the arbitration unit selects an acceleration request value from the second application. The vehicle motion manager according to claim 1.

3. When a vehicle malfunction is detected, the receiving unit receives the acceleration request value from the first application as an acceleration request value that requires degradation. A vehicle motion manager according to claim 1 or 2.

4. A method of controlling a vehicle using a computer installed in the vehicle, The aforementioned computer, The system accepts acceleration requests that require degradation from the first application, and acceleration requests that do not require degradation from the second application. Select the smallest acceleration request value from among the received acceleration request values, When selecting an acceleration requirement that requires degeneracy, the system outputs a degenerated value that approaches a predetermined endpoint over time. The process involves outputting the selected acceleration requirement value, or an instruction value corresponding to the degenerate value, to the vehicle's actuator, Furthermore, when selecting an acceleration requirement that requires degeneracy, the system accepts the degeneracy value instead of the acceleration requirement that requires degeneracy from the first application. A method for controlling a vehicle.

5. A program intended for a computer installed in a vehicle, To the aforementioned computer, The system accepts acceleration requests that require degradation from the first application, and acceleration requests that do not require degradation from the second application. Select the smallest acceleration request value from among the received acceleration request values, When selecting an acceleration requirement that requires degeneracy, the system outputs a degenerated value that approaches a predetermined endpoint over time. The system outputs the selected acceleration requirement value, or an instruction value corresponding to the degenerate value, to the actuator of the vehicle, and performs the following actions: Furthermore, when selecting an acceleration requirement that requires degradation, the system will accept the degraded value instead of the acceleration requirement that requires degradation from the first application. Vehicle control program.

Images