Control device, manager, electronic control unit, system, and control method

Abstract

The present invention relates to a control device, a manager, an electronic control unit, a system, a control method, a computer-readable non-transitory storage medium storing a program, and a vehicle. The manager is mounted on a vehicle and comprises: a receiving unit for receiving multiple action plans from multiple ADAS applications; a coordination unit for coordinating the multiple action plans; a calculation unit for calculating motion requests based on the coordination results of the coordination unit; and a distribution unit for distributing the motion requests to at least one actuator system. The receiving unit receives information related to coordination targets in the coordination unit from the ADAS applications.

Description

Technical Field

[0001] The present disclosure relates to a control device, a manager, an electronic control unit, a system, a control method, a non-transitory storage medium storing a program and readable by a computer, and a vehicle. Background Art

[0002] In recent years, multiple vehicles have been equipped with advanced driver assistance systems (ADAS) that implement autonomous driving features such as automated driving and automatic parking. Japanese Patent Application Laid-Open No. 2020-032894 discloses a manager (control device) that accepts requests from these multiple ADAS applications, coordinates these requests, and, based on the coordination results, outputs requests to drive actuator systems (including powertrain actuators, brake actuators, and other systems).

[0003] Such a manager sometimes has the following basic function: to ensure the safest and most secure vehicle control, when receiving multiple requests from multiple ADAS applications, it selects the smallest request among them. However, when receiving both an existing request that is about to be output and a new request that is being output from multiple ADAS applications, this basic function may cause the new request to be delayed until the existing request is completed, resulting in control delays (perceiving a sense of delay for the occupants). Summary of the Invention

[0004] The present disclosure has been made in view of the above-mentioned problems, and an object of the present disclosure is to provide a manager and the like that can suppress the occurrence of control delays.

[0005] A control device according to one embodiment of the present disclosure is a control device mounted on a vehicle. The control device includes one or more processors. The processors are configured to: receive multiple action plans from multiple ADAS applications, coordinate the multiple action plans, calculate motion requests based on the coordination results, distribute the motion requests to at least one actuator system, and receive information related to the coordination targets from the ADAS applications.

[0006] A vehicle according to one embodiment of the present disclosure is a vehicle equipped with the control device of the above embodiment.

[0007] A manager according to one embodiment of the present disclosure is mounted on a vehicle. The manager includes: a receiving unit for receiving multiple action plans from multiple ADAS applications; a coordination unit for coordinating the multiple action plans; a calculation unit for calculating motion requests based on the coordination results of the coordination unit; and a distribution unit for distributing the motion requests to at least one actuator system. The receiving unit receives information related to coordination targets from the ADAS applications.

[0008] An electronic control unit according to one embodiment of the present disclosure is mounted on a vehicle and is equipped with one or more ADAS applications. The electronic control unit is configured to output an action plan of the ADAS application and information related to coordination targets in coordination processing of the action plan to a manager.

[0009] A system according to one embodiment of the present disclosure comprises: a plurality of ADAS applications mounted on a vehicle and installed in one or more electronic control units; and a manager. The one or more electronic control units are configured to output a plurality of action plans requested by the plurality of ADAS applications to the manager. The manager is configured to receive the plurality of action plans from the plurality of ADAS applications, coordinate the plurality of action plans, calculate motion requests based on the coordination results, distribute the motion requests to at least one actuator system, and receive information related to the coordination objects from the ADAS applications.

[0010] A control method according to one embodiment of the present disclosure is executed by a computer mounted on a vehicle manager. The control method includes: receiving action plans and information related to coordination targets in coordination processing of the action plans from multiple ADAS applications; coordinating the received action plans; calculating a motion request based on the coordination results; and distributing the motion request to at least one actuator system based on the information.

[0011] One embodiment of the present disclosure relates to a computer-readable non-transitory storage medium having a program stored therein. When executed by a computer mounted on a manager of a vehicle, the program causes the manager to perform the following processing: accepting action plans and information related to coordination targets in coordination processing of the action plans from multiple ADAS applications; coordinating the accepted action plans; calculating a motion request based on the coordination results; and distributing the motion request to at least one actuator system based on the information.

[0012] According to the present disclosure, since an existing request that is about to be outputted is excluded from the coordination targets, it is easy to select a new request through coordination, and the occurrence of control delay can be suppressed. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Hereinafter, features, advantages, technical and industrial significance of exemplary embodiments of the present invention will be described with reference to the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0014] Figure 1 This is a schematic diagram showing a configuration example of a system according to one embodiment of the present disclosure.

[0015] Figure 2 This is a flowchart showing the steps of the coordination process performed by the manager.

[0016] Figure 3 This is a diagram illustrating an example of coordination processing of a plurality of requested accelerations (action plans).

[0017] Figure 4 This figure explains an example of coordination processing of multiple acceleration requests (action plans).

[0018] Figure 5 This is a flowchart showing the steps of the restriction processing performed by the manager.

[0019] Figure 6 This figure explains an example of limiting the driving force (motion request)

[0020] Figure 7 This is a diagram for explaining another example of limiting the driving force (motion request). DETAILED DESCRIPTION

[0021] If multiple conflicting requests from an application occur, and if the multiple action plans include a scheduled action plan that will terminate the request, the manager of the present disclosure performs coordination excluding the action plan that will terminate the request. This avoids situations where a request for another action plan is not selected before the request for the scheduled action plan is terminated. An embodiment of the present disclosure is described in detail below with reference to the accompanying drawings.

[0022] <Implementation Method>

[0023] [constitute]

[0024] Figure 1 It is a schematic diagram showing a configuration example of a system 1 mounted on a vehicle according to one embodiment of the present disclosure. Figure 1 The system 1 illustrated in FIG includes a manager 10, a driving support system 20, and a plurality of actuator systems 30 and 40. The components of the system 1 are communicably connected via an in-vehicle network 100. Examples of the in-vehicle network 100 include CAN (Controller Area Network) and Ethernet (registered trademark).

[0025] The driving assistance system 20 is a system for implementing various functions for assisting with vehicle driving, including at least vehicle drive control and braking control, by executing installed applications. Examples of applications installed in the driving assistance system 20 include autonomous driving applications, automatic parking applications, and advanced driver assistance systems (ADAS) applications. ADAS applications include those that implement collision avoidance assistance (e.g., PCS (Pre-crash Safety)), those that implement vehicle-following driving (e.g., ACC (Adaptive Cruise Control)), those that maintain a constant distance from the preceding vehicle, lane keeping assistance (e.g., LKA (Lane Keeping Assist) and LTA (Lane Tracing Assist)), those that automatically apply brakes to minimize collision damage (e.g., AEB (Automated Emergency Braking)), and those that warn the vehicle if it leaves its lane (e.g., LDW (Lane Departure Warning) and LDA (Lane Departure Alert)).

[0026] Each application in the driving assistance system 20 outputs a request for an action plan that ensures the application's unique functionality (commerciality) to the manager 10 based on vehicle information (identification sensor information, etc.) obtained (input) from various sensors (not shown). This action plan includes, for example, a request regarding the forward and backward acceleration / deceleration of the vehicle. Furthermore, each application in the driving assistance system 20 can output identification information (application ID) that uniquely identifies the application, along with the action plan, to the manager 10. This application ID is uniquely determined in advance for each application.

[0027] Furthermore, each application of the driving assistance system 20 outputs information indicating that the generation of the currently requested action plan has been scheduled to be completed to the manager 10. This information can be, for example, a flag, and by setting the flag to an active (ON) state for a predetermined period before the generation of the action plan is terminated, the manager 10 can be notified in advance of the completion of the generation of the action plan. Since such action plans scheduled to be completed are considered to have low priority, the flags assigned to them will be referred to as "low priority flags" hereinafter. As an example, for an ACC application that is currently outputting acceleration as an action plan, when implementing a reduction process to gradually bring the requested acceleration closer to the lower limit of the driving force that can be generated by the actuator systems 30 and 40 in order to terminate its own request, the low priority flag can be set to an active state and output to the manager 10 from the time the reduction process is just started until the acceleration request is stopped.

[0028] The driving assistance system 20 is implemented by a computer such as an electronic control unit (ECU) having a processor such as a CPU (Central Processing Unit), a memory, and an input / output interface (output unit). The number of ECUs constituting the driving assistance system 20 and the number of applications installed on the ECUs are not particularly limited. In addition, as the driving assistance system 20, a separate ECU can be set for each application. For example, the driving assistance system 20 can be composed of an automatic driving ECU installed with an automatic driving application, an automatic parking ECU installed with an automatic parking application, and an ADAS-ECU installed with an advanced driving assistance application. In addition, multiple ADAS applications can be installed on multiple ECUs, such as an ECU installed with an ADAS application that implements the ACC function, an ECU installed with an ADAS application that implements the LKA function, and an ECU installed with an ADAS application that implements the AEB function.

[0029] The multiple actuator systems 30 and 40 are one of the implementation systems for implementing the action plan request output by the driving assistance system 20. As an example, the actuator system 30 includes a powertrain actuator (such as the engine and transmission) that can generate braking force for the vehicle, and the action plan request is implemented by controlling the operation of the powertrain actuator. Furthermore, as an example, the actuator system 40 includes a brake actuator (such as a hydraulic brake and an electric parking brake) that can generate braking force for the vehicle, and the action plan request is implemented by controlling the operation of the brake actuator. The number of actuator systems installed in the vehicle is not particularly limited.

[0030] The manager 10 determines the control details related to the vehicle's motion based on the action plan request received from the driving assistance system 20, and outputs the necessary requests to the actuator systems 30 and / or 40 based on the determined control details. Furthermore, the manager 10 distributes the motion requests to the plurality of actuator systems 30 and / or 40 based on the low priority flag received from the driving assistance system 20 along with the action plan request.

[0031] The manager 10 functions as a so-called ADAS-MGR (Manager) or Vehicle-MGR related to vehicle motion, or as a part of an ADAS-MGR or Vehicle-MGR, to control vehicle motion. The manager 10 includes a reception unit 11 , a coordination unit 12 , a calculation unit 13 , and an allocation unit 14 .

[0032] The receiving unit 11 receives requests for action plans and low priority flags output by multiple applications of the driving assistance system 20. As an action plan in this embodiment, the acceleration related to the front-to-back direction (longitudinal) movement of the vehicle can be exemplified. In addition, the receiving unit 11 receives the lower limit of the driving force that can be generated (lower limit of availability) from the actuator system 30 including the powertrain actuator. The lower limit of the driving force refers to the lower limit value (minimum driving force) of the driving force that can be achieved by the powertrain actuator at the current speed ratio (gear) in the fully closed state of the accelerator pedal without being stepped on. The request for the action plan, the low priority flag and the lower limit of the driving force received by the receiving unit 11 are output to the coordination unit 12.

[0033] The coordination unit 12 coordinates the requests for multiple action plans received by the acceptance unit 11 from the various applications of the driving assistance system 20. As an example of this coordination process, one action plan can be selected from multiple action plans based on a predetermined selection criterion (e.g., Min selection). In addition, as another coordination process, a new action plan can be set based on multiple action plans. In this case, the coordination unit 12 coordinates the requests for multiple action plans based on the low priority flag received by the acceptance unit 11 from each application and the lower limit of the drive force that can be generated obtained by the manager 10 from the actuator system 30. This coordination will be described later.

[0034] Furthermore, there are cases where the action plans accepted by the acceptance unit 11 from each application have a predetermined priority for coordination. In such a case, when coordinating the action plans, the coordination unit 12 may coordinate the multiple action plans by applying a lower priority flag than the predetermined priority, or may coordinate the multiple action plans after temporarily changing the priority based on the lower priority flag.

[0035] The calculation unit 13 calculates a motion request based on the coordination results of the action plan request in the coordination unit 12. This motion request is a physical quantity used to control the actuator system 30 or 40 and is different from the physical quantity requested in the action plan. For example, if the action plan request is acceleration, the driving force or driving torque can be calculated as the motion request. This converts the acceleration request into a driving force or driving torque request.

[0036] Furthermore, the calculation unit 13 can perform a predetermined restriction process on the motion request calculated by itself based on the low priority flag received from each application and the lower limit of the generative driving force obtained by the manager 10 from the actuator system 30. This restriction process will be described later.

[0037] The distribution unit 14 distributes the motion request calculated by the calculation unit 13, or the motion request that has been calculated and subjected to restriction processing, to at least one actuator system 30 and / or 40. For example, when the brakes are not in use, the distribution unit 14 distributes the motion request only to the actuator system 30 including the powertrain actuators. Alternatively, when both the engine and the brakes are in use, for example, the distribution unit 14 appropriately distributes the motion request to the actuator system 30 including the powertrain actuators and the actuator system 40 including the brake actuators.

[0038] The configurations of the manager 10, driving assistance system 20, and actuator systems 30 and 40 mounted on the vehicle described above are merely examples, and additions, replacements, changes, omissions, etc., can be appropriately implemented. Furthermore, the functions of each device can be integrated into a single device or distributed across multiple devices.

[0039] [control]

[0040] Further reference Figures 2 to 7 The control performed by the manager 10 according to this embodiment will be described.

[0041] (1) Coordination / computation processing

[0042] Figure 2 This is a flowchart explaining the steps of the coordination / calculation process performed by the coordination unit 12 and the calculation unit 13 of the manager 10. When the reception unit 11 of the manager 10 receives a request for an action plan from an application of the driving assistance system 20, the action plan is started. Figure 2 The coordination / calculation process shown. As an action plan, acceleration can be exemplified.

[0043] (Step S201)

[0044] The coordination unit 12 checks the number of action plans received from the application by the reception unit 11. If there are two or more action plans (step S201, two or more), the process proceeds to step S202. If there is only one action plan (step S201, one), the process proceeds to step S206.

[0045] (Step S202)

[0046] The coordination unit 12 determines whether there is an action plan with a low priority flag turned on among the two or more action plans accepted by the acceptance unit 11 from the application. That is, the coordination unit 12 determines whether the multiple action plans requested from each application include a low-priority action plan that is degenerate and wants to end the output. Hereinafter, the action plan with the low priority flag turned valid is referred to as a "low priority action plan". When there are more than one low priority action plan with a low priority flag turned valid (step S202, yes), the processing proceeds to step S203 (mode [A]). On the other hand, when there is no low priority action plan with a low priority flag turned valid (step S202, no), the processing proceeds to step S204 (mode [B]).

[0047] (Step S203)

[0048] The coordination unit 12 excludes the low-priority action plan marked as valid from the two or more action plans accepted by the acceptance unit 11, and coordinates the remaining action plans excluding the low-priority action plan. An example of the coordination process is to select the action plan with the lowest request value among the action plans to be coordinated. If coordination of the action plans is completed, the process proceeds to step S205.

[0049] (Step S204)

[0050] The coordination unit 12 coordinates all action plans received from the application by the reception unit 11. As an example of the coordination process, a method of selecting an action plan with the minimum request value among all action plans can be exemplified. Once the action plans are coordinated, the process proceeds to step S205.

[0051] (Step S205)

[0052] The calculation unit 13 calculates a motion request based on the coordination result of the coordination unit 12. A driving force can be exemplified as the motion request. The calculated motion request is output to the distribution unit 14 of the manager 10 as a motion request to be distributed to at least one actuator system 30 and / or 40. Once the motion request is calculated, the coordination / calculation process ends.

[0053] (Step S206)

[0054] The calculation unit 13 calculates the motion request based on the action plan received from the application by the reception unit 11. The action plan is the action plan selected as a result of the coordination by the coordination unit 12. The motion request can be exemplified by driving force. Once the motion request is calculated, the process proceeds to step S207.

[0055] (Step S207)

[0056] The calculation unit 13 determines whether the low priority flag of the action plan for which the motion request is calculated is valid. In other words, the calculation unit 13 determines whether the request of the action plan is decreasing and about to end. If the low priority flag of the action plan is invalid (OFF) (step S207, no), the motion request calculated in the above step S206 is output to the distribution unit 14 as a motion request allocated to at least one actuator system 30 and / or 40, and this coordination / calculation processing ends (mode [C]). On the other hand, if the low priority flag of the action plan is valid (step S207, yes), the processing enters step S208 (mode [D]).

[0057] (Step S208)

[0058] The calculation unit 13 applies a predetermined restriction process to the motion request calculated in step S206. This restriction process will be described later. The new motion request resulting from the restriction process applied to the motion request calculated in step S206 is output to the distribution unit 14 as a motion request to be distributed to at least one actuator system 30 and / or 40, thus completing the coordination and calculation process.

[0059] Thus, if there is a low-priority action plan that is expected to terminate the request soon among the multiple action plans received from each application, the low-priority action plan is excluded from the coordination. Thus, since action plans other than the low-priority action plan are selected, the occurrence of control delay can be suppressed.

[0060] Furthermore, in the above embodiment, the coordination unit 12 and the calculation unit 13 each independently determine whether the low priority flag of the action plan is valid. However, this determination may be performed by another structure (e.g., a flag determination unit), and the determination result may be output to the coordination unit 12 and the calculation unit 13, respectively.

[0061] Reference Figure 3 as well as Figure 4The coordination and calculation processing performed by the manager 10 will be specifically described. In this specific example, the case where each application of the driving assistance system 20 requests acceleration in the forward and backward directions as an action plan and the minimum acceleration is selected from multiple accelerations during the coordination process (Min selection) will be described.

[0062] Figure 3 An example is shown in which the low priority flag of application A's request becomes valid after both an action plan requested by application A (hereinafter referred to as "application A request") and an action plan requested by application B (hereinafter referred to as "application B request") are generated.

[0063] During the time period T<t1 requested by application A only, the acceleration requested in the action plan of application A (hereinafter referred to as "application A requested acceleration") is selected by coordination ( Figure 2 model [C]).

[0064] During the period t1≤T<t2 of the period t1≤T<t3 during which the request of application A conflicts with the request of application B, the low priority flag of the request of application A is still in the invalid state. Therefore, the acceleration of the request of application A is selected as the minimum value by the coordination ( Figure 2 model [B]).

[0065] During the period t2 ≤ T < t3 of the time period t1 ≤ T < t3 during which the request of application A conflicts with the request of application B and the time period t2 ≤ T < t3 are negotiated, the low priority flag of the request of application A is in the valid state, and the acceleration requested by application A is excluded from the coordination target. Therefore, the acceleration requested in the action plan of application B (hereinafter referred to as "the acceleration requested by application B") is selected by the coordination. Figure 2 mode [A]).

[0066] During the time t3≤T when the request of application A ends and only the request of application B is made, the acceleration requested by application B is selected through coordination.

[0067] Figure 4 This shows an example in which the low priority flag of the application A request generated before the application B request is generated becomes valid.

[0068] During the period T<t1 of the period T<t2 requested by application A only, the acceleration requested by application A is selected by coordination ( Figure 2 model [C]).

[0069] During the period of time t1 ≤ T < t2 in which only application A requests, similarly to the period of time T < t1, the acceleration requested by application A is selected by coordination. However, since the low priority flag of the application A request is in the valid state, the driving force (motion request) calculated based on the acceleration requested by application A is subjected to the restriction process described later ( Figure 2 mode [D]).

[0070] During the time t2≤T<t3 when the request of application A conflicts with the request of application B and the negotiation is performed, since the low priority flag of the request of application A is valid, the acceleration request of application A is excluded from the negotiation object, and the acceleration request of application B is selected through the negotiation ( Figure 2 mode [A]).

[0071] During the time period t3≤T when only the application B makes a request, the acceleration requested by the application B is selected through coordination.

[0072] As in the example above, when multiple applications are requesting conflicting requests, requests from applications with low-priority flags enabled are excluded from coordination. This prevents coordination from selecting an action plan for an application that requests an extremely low acceleration rate due to a fallback process, thereby minimizing control delays.

[0073] (2) Restriction of processing

[0074] Next, refer to Figure 5 The following describes the restriction process ( Figure 2 Step S208). Figure 5 This is a flowchart illustrating the procedure of the restriction process executed by the manager 10 .

[0075] (Step S501)

[0076] The manager 10 determines whether the vehicle is currently performing braking control (currently in progress). Whether braking control is currently in progress can be determined by whether the actuator system 40 is operating the brake actuator. If braking control is currently in progress (step S501: Yes), the process proceeds to step S502. On the other hand, if braking control is not currently in progress (step S501: No), the process proceeds to step S503.

[0077] (Step S502)

[0078] The manager 10 maintains the braking control execution state. Specifically, the allocation unit 14 of the manager 10 appropriately allocates the motion request to the actuator system 40 so that the braking control by the brake actuators continues as is. If the braking control execution state is maintained, the process proceeds to step S504.

[0079] (Step S503)

[0080] The manager 10 maintains a state in which braking control is not being executed. Specifically, the allocation unit 14 of the manager 10 limits (or prohibits) the allocation of motion requests to the actuator system 40 so that no new braking control by the brake actuator is generated. If the state in which braking control is not being executed is maintained, the process proceeds to step S505.

[0081] (Step S504)

[0082] The calculation unit 13 of the manager 10 limits the motion request calculated based on the coordination results of the action plan based on a specified lower limit value. In the case where the motion request is driving force, the specified lower limit value can be the lower limit value of the driving force that can be achieved by the powertrain actuator at the current gear ratio (driving force lower limit). The manager 10 can obtain the driving force lower limit by receiving feedback input from the actuator system 30 including the powertrain actuator. The motion request limited by the driving force lower limit is distributed to the actuator system 30 and / or 40 by the distribution unit 14. If the motion request is limited based on the driving force lower limit, the process proceeds to step S506.

[0083] (Step S505)

[0084] The calculation unit 13 of the manager 10 does not impose any restrictions on the motion request calculated based on the coordination result of the action plan. In other words, the allocation unit 14 allocates the unrestricted motion request to the actuator system 30 and / or 40. The process then proceeds to step S506.

[0085] (Step S506)

[0086] The manager 10 determines whether the existing action plan request received by the acceptance unit 11 from the application has ended, or whether the acceptance unit 11 has received a new action plan request from another application. If the existing action plan request has ended or there is a new action plan request (step S506, yes), the process proceeds to step S508. On the other hand, if the existing action plan request has not ended and there is no new action plan request (step S506, no), the process proceeds to step S507.

[0087] (Step S507)

[0088] The manager 10 determines whether the low priority flag in the existing action plan request received from the application by the reception unit 11 has been invalidated. If the low priority flag in the existing action plan request has been invalidated (step S507: Yes), the process proceeds to step S508. On the other hand, if the low priority flag in the existing action plan request remains valid (step S507: No), the process proceeds to step S506.

[0089] (Step S508)

[0090] The manager 10 cancels the hold state of the brake control performed in step S502 or S503 and the restriction state of the motion request performed in step S504. If the hold and restriction states are canceled, the restriction process ends.

[0091] In this way, if only one action plan is received from the application, and that action plan is a low-priority action plan whose request is about to end due to reduction, the motion request calculated based on the action plan is limited to a predetermined lower limit. This, for example, by limiting the motion request, which serves as driving force, to the lower limit of the driving force that can be generated by the powertrain actuator (driving force lower limit), prevents the requested driving force from fluctuating beyond the driving force lower limit. This can prevent the brake actuator from frequently switching between actuated and inactive states, which could lead to a decrease in vehicle ride comfort.

[0092] Next, refer to Figure 6 as well as Figure 7 The following specifically describes the restriction process executed by the manager 10. In this specific example, the case where the calculation unit 13 of the manager 10 calculates the driving force as the motion request will be described.

[0093] Figure 6 An example is shown in which the low priority flag of the action plan requested from application A (hereinafter referred to as “application A request”) is in the valid state while the brake control by the brake actuator is not being executed (not executed).

[0094] exist Figure 6 In the example, since braking control by the brake actuator was not executed when the low priority flag became active (time t1), this state of braking control remains inactive. Therefore, even if the requested driving force (solid line) subsequently falls below the lower limit of the driving force of the powertrain actuator (single-dotted dash line) (time t2 ≤ T ≤ t3), braking control is not executed (the brake actuator does not operate). In other words, the driving force requested by application A (as is) is distributed to the powertrain actuator until the application A request disappears or the low priority flag becomes inactive (time t4).

[0095] Figure 7 The example shown is that the low priority flag of the application A request is in the valid state while the brake control by the brake actuator is being executed (being executed).

[0096] exist Figure 7 In the example, at the moment (time t1) when the driving force requested by application A (solid line) is lower than the lower limit of the driving force of the powertrain actuator (single-dot chain line), braking control is performed. Then, at the moment when the low priority flag becomes valid (time t2), the braking control is kept in the execution state. In addition, the requested driving force is limited to not exceeding the lower limit of the driving force. Due to this limitation, even if the application A request is to request a driving force that exceeds the lower limit of the driving force (dashed line), the driving force can be properly allocated to the brake actuator and the powertrain actuator so as to continue the execution of the braking control. Therefore, the braking control being executed will not stop (the brake actuator will not switch to inaction) until the application A request disappears or the low priority flag becomes invalid (time t4).

[0097] <Function / Effect>

[0098] As described above, in a system according to one embodiment of the present disclosure, when multiple action plan requests are generated due to application conflicts, if a scheduled action plan (low-priority action plan) that is a request to end is included among the multiple action plans, the action plan that is scheduled to end is excluded from coordination. This makes it easier to select action plans other than the scheduled action plan that is scheduled to end (for example, the action plan of an application that requests an extremely low acceleration due to a reduction process). Therefore, it is possible to avoid situations where requests for other action plans are not selected before the request to end the scheduled action plan is completed, thereby suppressing the occurrence of control delays.

[0099] Furthermore, in the system according to this embodiment, even if only one action plan is received from the application, if that action plan is a low-priority action plan, the motion request calculated based on the low-priority action plan is limited to a predetermined lower limit. This, for example, by limiting the motion request, which serves as driving force, to the lower limit of the driving force that can be generated by the powertrain actuator, prevents the motion request from fluctuating beyond the lower limit. This can prevent the brake actuator from frequently switching between actuated and inactive states, which could degrade vehicle ride comfort.

[0100] An embodiment of the technology disclosed herein has been described above, but the present disclosure can be understood not only as a manager mounted on a vehicle, but also as an electronic control unit, a system including an electronic control unit and a manager, a control method executed by a manager having a processor and a memory, a control program, a computer-readable non-temporary storage medium storing a control program, or a vehicle having a manager, etc.

[0101] The present disclosure is useful in a manager or the like mounted on a vehicle or the like.

Claims

1. A control device mounted on a vehicle, characterized in that: The control device includes one or more processors, and the one or more processors are configured as follows: Accept multiple action plans from multiple ADAS applications, Coordinating the multiple action plans, calculating a motion request based on a coordination result of the coordination, assigning the motion request to at least one actuator system, receiving information related to the coordination object in the coordination from the ADAS application, The information related to the coordination target is information indicating that the action plan is a low-priority action plan having a low priority as the coordination target. The low priority action plan includes the action plan for which the ADAS application is scheduled to generate an end, The one or more processors are configured to coordinate the remaining action plans except the low priority action plan.

2. The control device according to claim 1, characterized in that In the action plan that the ADAS application is scheduled to generate and terminate, a reduction process is performed.

3. The control device according to claim 2, characterized in that The reduction process is a process of gradually bringing the action plan closer to the lower limit of the driving force that can be generated by the actuator system.

4. The control device according to claim 1, characterized in that The one or more processors are configured to output the low-priority action plan as a coordination result when only the low-priority action plan is received from the plurality of ADAS applications. The motion request calculated based on the low-priority action plan as a result of the coordination is limited according to an execution state of brake control and based on a lower limit of a driving force that can be generated from the actuator system.

5. The control device according to claim 4, characterized in that The one or more processors are configured to limit the motion request based on a lower limit of a driving force that can be generated by the actuator system while the braking control is being executed.

6. The control device according to any one of claims 3 to 5, characterized in that: The driving force lower limit is the lower limit value of the driving force that can be achieved by the powertrain actuator at the current speed ratio. The at least one actuator system includes a powertrain system including the powertrain actuator.

7. A manager mounted on a vehicle, characterized in that: include: The acceptance department accepts multiple action plans from multiple ADAS applications; A coordination department, responsible for coordinating the multiple action plans; a calculation unit that calculates a motion request based on a coordination result of the coordination; as well as a distribution unit that distributes the motion request to at least one actuator system, in, The receiving unit receives information related to the coordination object in the coordination from the ADAS application, The information related to the coordination target is information indicating that the action plan is a low-priority action plan having a low priority as the coordination target. The low priority action plan includes the action plan for which the ADAS application is scheduled to generate an end, The coordination unit is configured to coordinate the remaining action plans except the low-priority action plan.

8. An electronic control unit, mounted on a vehicle and equipped with one or more ADAS applications, characterized in that: The electronic control unit is configured to output the action plan of the ADAS application and information related to the coordination object in the coordination process of the action plan to the manager, The information related to the coordination target is information indicating that the action plan is a low-priority action plan having a low priority as a coordination target. The low priority action plan includes the action plan for which the ADAS application is scheduled to generate an end, The coordination unit of the manager is configured to coordinate the remaining action plans except the low-priority action plan.

9. A system, characterized in that: include: Multiple ADAS applications are installed in vehicles and in more than one electronic control unit; and Manager, in, The one or more electronic control units are configured to output a plurality of action plans requested by the plurality of ADAS applications to the manager, The manager is composed of: receiving the plurality of action plans from the plurality of ADAS applications, Coordinating the multiple action plans, calculating a motion request based on a coordination result of the coordination, assigning the motion request to at least one actuator system, receiving information related to the coordination object in the coordination from the ADAS application, The information related to the coordination target is information indicating that the action plan is a low-priority action plan having a low priority as the coordination target. The low priority action plan includes the action plan for which the ADAS application is scheduled to generate an end, The manager is configured to coordinate the remaining action plans except the low priority action plans.

10. A control method, executed by a computer of a manager mounted on a vehicle, characterized in that: include: receiving, from a plurality of ADAS applications, action plans and information related to coordination targets in coordination processing of the action plans; Coordinating the plurality of action plans received; calculating a motion request based on a result of the coordination; and assigning the motion request to at least one actuator system based on the information, The information related to the coordination target is information indicating that the action plan is a low-priority action plan having a low priority as the coordination target. The low priority action plan includes the action plan for which the ADAS application is scheduled to generate an end, Coordination is performed on the remaining action plans except for the low priority action plans.

11. A non-transitory storage medium storing a program and readable by a computer, characterized in that: When the program is executed by a computer of a manager mounted on a vehicle, the manager is caused to execute the following processing: receiving, from a plurality of ADAS applications, action plans and information related to coordination targets in coordination processing of the action plans; Coordinating the plurality of action plans received; calculating a motion request based on a result of the coordination; and assigning the motion request to at least one actuator system based on the information, The information related to the coordination target is information indicating that the action plan is a low-priority action plan having a low priority as the coordination target. The low priority action plan includes the action plan for which the ADAS application is scheduled to generate an end, The manager is configured to coordinate the remaining action plans except the low priority action plans.

12. A vehicle, characterized in that: The control device according to any one of claims 1 to 6 is mounted.

Images