Manager, electronic control unit, system, control method, control program, and vehicle

Abstract

To provide a manager etc. that can mediate so that requests of drivers are not responded in a system configuration in which multiple ADAS applications are implemented in the same ECU when any of the multiple ADAS applications that are operating functions is in a state in which it should not respond to requests of drivers.SOLUTION: A manager that is installed in a vehicle includes a first reception unit that receives multiple action plans and identification information of ADAS applications from multiple ADAS applications, and a first mediation unit that mediates the multiple action plans received by the first reception unit; the first reception unit receives the action plans and control statuses indicating the implementation states of the control in the ADAS applications from one electronic control unit in which two or more ADAS applications are implemented.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a manager and the like installed in a vehicle. [Background technology]

[0002] In recent years, vehicles have been equipped with a plurality of advanced driver assistance system (ADAS) applications that realize autonomous driving functions such as autonomous driving and autonomous parking. Patent Document 1 discloses a control device (manager) that receives requests output from the plurality of ADAS applications, arbitrates the requests received from the plurality of ADAS applications, and outputs a request to drive an actuator (such as a steering device or a braking device) based on the arbitration result.

[0003] One ADAS application is an automatic parking application that realizes the function of automatic parking of a vehicle. In this automatic parking application, if the driver requests an input to change the shift range (shift operation) while the automatic parking function is operating, the automatic parking control will be immediately stopped without responding to this shift operation.

[0004] One ADAS application is a parking support brake (PKSB) application, which provides a function to assist braking during low-speed driving, such as parking. In this PKSB application, if the driver shifts gears while the PKSB function is operating, the PKSB function maintains its operating state while responding to the shift operation. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Publication No. 2020-032894 Summary of the Invention [Problem to be solved by the invention]

[0006] In a system configuration in which the ADAS application and the PKSB application are implemented in separate electronic control units (ECUs), even if the PKSB function is activated later while the automatic parking function is in operation, each ECU outputs identification information (application ID) that can uniquely identify the ADAS application that receives the request. Therefore, the manager can determine that both the automatic parking function and the PKSB function are in operation by receiving each application ID. Therefore, in this case, even if the driver shifts gears while both the automatic parking function and the PKSB function are in operation, the manager can arbitrate by giving priority to the automatic parking function and not responding to the shift operation.

[0007] However, in a system configuration where the ADAS application and the PKSB application are implemented in the same ECU, if the PKSB function is activated later while the automatic parking function is in operation, the ECU will only output the PKSB function request and application ID as the most recent output. Therefore, even though the manager can determine that the PKSB function is in operation based on the received application ID, it cannot determine whether the automatic parking function is in operation or has ended. Therefore, in this case, if the driver shifts gears while both the automatic parking function and the PKSB function are in operation, the manager may perform arbitration to respond to the shift operation.

[0008] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a manager or the like that can mediate so that an ADAS application does not respond to a driver's request when any of the multiple ADAS applications that are operating functions is in a state where it should not respond to a driver's request in a system configuration in which multiple ADAS applications are implemented in the same ECU. [Means for solving the problem]

[0009] In order to solve the above problem, one aspect of the disclosed technology is a manager mounted on a vehicle, which receives a plurality of action plans from a plurality of ADAS applications and an ADAS application. Control status indicating the implementation status of control and a first arbitration unit that arbitrates the plurality of action plans accepted by the first acceptance unit, When a first ADAS application in which a state exists in which the request of its own function should be prioritized over the request of the driver and a second ADAS application in which the request of the driver is prioritized over the request of its own function are implemented in one electronic control unit, From one electronic control unit No. 1 ADAS Applications of Control status Always Acceptable, manager. [Effects of the Invention]

[0010] According to the present disclosure, the manager receives a control status indicating the implementation state of control from an ADAS application. In a system configuration in which multiple ADAS applications are implemented in the same ECU, the manager can arbitrate so that an ADAS application does not respond to a driver's request when the ADAS application is in a state in which it should not respond to a driver's request among the multiple ADAS applications that are operating functions. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a schematic diagram illustrating a configuration example of a system according to an embodiment of the present disclosure. [Figure 2] Flowchart of the arbitration control process executed by the arbitration unit of the manager DETAILED DESCRIPTION OF THE INVENTION

[0012] The manager of the present disclosure acquires information indicating the control status of the automatic parking function from the ECU in which at least the automatic parking application and the PKSB application are implemented, in addition to the identification ID of the application that realizes the requested function. This information allows the manager to understand the automatic parking control that is operating behind the scenes, such as PKSB control, and therefore can refuse to respond to driver requests that are undesirable for the automatic parking control. Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the drawings.

[0013] <Embodiment> [composition] Fig. 1 is a schematic diagram showing an example configuration of a system 1 mounted on a vehicle according to an embodiment of the present disclosure. The system 1 illustrated in Fig. 1 includes a manager 10, a driving assistance system 20, an actuator system 30, a shift operation sensor 40, and a shift control unit 50, and each component is communicatively connected via an in-vehicle network 100. Examples of the in-vehicle network 100 include a CAN (Controller Area Network) and Ethernet (registered trademark).

[0014] The driving assistance system 20 is configured to execute implemented applications to realize various functions for assisting vehicle driving, including at least vehicle drive control and braking control. Examples of applications implemented by the driving assistance system 20 include one or more ADAS applications, such as an autonomous driving application that realizes an autonomous driving function and a driving assistance application that realizes various functions related to vehicle driving assistance. The autonomous driving application includes an automatic parking application that realizes an automatic parking function for the vehicle. Examples of driving assistance applications include a PKSB application that realizes a function to assist braking during low-speed driving such as parking, an application that realizes a collision avoidance assistance (PCS, etc.), an application that realizes an adaptive cruise control (ACC, etc.) function that maintains a constant distance from a vehicle in front, an application that realizes a lane keeping assistance (LKA, LTA, etc.) function that maintains the vehicle in its lane, an application that realizes a collision mitigation braking (AEB, etc.) function that automatically applies the brakes to mitigate collision damage, and an application that realizes a lane departure warning (LDW, LDA, etc.) function that warns the vehicle of departure from its lane.

[0015] Each application of the driving assistance system 20 outputs to the manager 10, as an application request, an action plan request that ensures the functionality (marketability) of the application alone, based on vehicle information (such as recognition sensor information) acquired (input) from various sensors (not shown). This action plan includes a request regarding the longitudinal acceleration / deceleration to be generated in the vehicle, and a request regarding the setting of the shift range (required shift range value). Each application of the driving assistance system 20 also outputs, along with the action plan, identification information (application ID) that can uniquely identify the application to the manager 10. This application ID is uniquely determined in advance for each application. Furthermore, a specific application in the driving assistance system 20 outputs a control status (control status signal) that indicates the control status of the function of the application to the manager 10. The specific application and the control status will be described later.

[0016] The driving assistance system 20 is realized by a computer such as an electronic control unit (ECU) having a processor such as a CPU, a memory, and an input / output interface (output section). The number of ECUs constituting the driving assistance system 20 and the number of applications implemented by the ECUs are not particularly limited. For example, the driving assistance system 20 may be provided with one or more ECUs on which multiple applications are implemented together, or one or more ECUs on which a single application is implemented. For example, part or all of the driving assistance system 20 may be configured with an ECU on which both an automatic parking application and a PKSB application are implemented, or part or all of the driving assistance system 20 may be configured with an ECU on which the automatic parking application is implemented and an ECU on which the PKSB application is implemented.

[0017] The actuator system 30 is one of the realization systems for realizing the requirements of the action plan output by the driving assistance system 20. Although FIG. 1 shows an example in which only one actuator system 30 is connected to the in-vehicle network 100, the number of actuator systems 30 installed in the vehicle is not particularly limited. Examples of the actuator system 30 include a system that includes a brake actuator (such as an electric brake device) that can generate braking force on the vehicle and realizes the requirements of the action plan (acceleration requirements) by controlling the operation of the brake actuator, and a system that includes a shift actuator that can operate a shift mechanism and realizes the requirements of the action plan (shift range requirement value) by controlling the operation of the shift actuator.

[0018] The shift operation sensor 40 is configured to detect a change in the shift range operated by the driver as a request from the driver of the vehicle. The detection result of the shift operation sensor 40 is output to the manager 10.

[0019] The shift control unit 50 is configured to control the setting of the shift range (shift position) of the vehicle based on a request (shift range request value) from the manager 10 and / or a request (shift operation) from the driver based on the action plan output by the driving assistance system 20. The shift control unit 50 is incorporated into, for example, a shift ECU and controls a shift actuator.

[0020] The manager 10 determines the control content related to the vehicle motion based on the action plan request received from the driving assistance system 20, and outputs a necessary request based on the determined control content to the actuator system 30. The manager 10 also issues instructions to the shift control unit 50 required for setting and controlling the shift range based on the application ID of the application and the control status of the application acquired together with the action plan request from the driving assistance system 20.

[0021] The manager 10 functions as an ADAS-MGR or a Vehicle-MGR related to the vehicle's motion, or as a part of the ADAS-MGR or the Vehicle-MGR, and controls the vehicle's motion. The manager 10 includes a reception unit 11, an arbitration unit 12, a calculation unit 13, and a distribution unit 14.

[0022] The reception unit 11 (first reception unit) receives an action plan request, an application ID, and a control status output by one or more applications of the driving assistance system 20. Examples of the action plan in this embodiment include acceleration related to the longitudinal (longitudinal) movement of the vehicle and a shift range request value. The reception unit 11 (second reception unit) also receives a shift operation detected by the shift operation sensor 40 as a driver request. The action plan request, application ID, and driver request (shift operation) received by the reception unit 11 are output to the arbitration unit 12.

[0023] The arbitration unit 12 (first arbitration unit) arbitrates requests for multiple action plans received by the reception unit 11 from the applications of the driving assistance system 20. An example of this arbitration process is selecting one action plan from multiple action plans based on a predetermined selection criterion (e.g., Min selection). Alternatively, the arbitration process may involve setting a new action plan based on the multiple action plans. Note that the arbitration unit 12 may arbitrate requests for multiple action plans further based on information indicating availability obtained from the actuator system 30.

[0024] Furthermore, the arbitration unit 12 (second arbitration unit) determines whether or not to respond to the driver's request (shift operation) based on the control status received by the reception unit 11 from the application of the driving assistance system 20 and the detection result from the shift operation sensor 40. The determination of whether or not to respond to the driver's request (determination of whether to maintain the status quo or change) will be described later. Then, based on this determination, the arbitration unit 12 issues instructions to the shift control unit 50 necessary for setting and controlling the shift range.

[0025] The calculation unit 13 calculates a motion request based on the result of arbitration of the action plan requests by the arbitration unit 12. This motion request is a physical quantity for controlling the actuator system 30, and is different from the physical quantity of the action plan request. For example, if the action plan request (first request) is acceleration, a driving force or driving torque can be calculated as the motion request (second request). This converts the acceleration request into a driving force or driving torque request.

[0026] The distribution unit 14 distributes the motion request calculated by the calculation unit 13 to at least one actuator system (actuator system 30 or another actuator system not shown).

[0027] The above-described configurations of the devices mounted on the vehicle and the configuration of the manager 10 are merely examples, and additions, substitutions, changes, omissions, and the like are possible as appropriate. Furthermore, the functions of each device can be integrated into one device or distributed among multiple devices as appropriate. For example, among the functions of the reception unit 11 of the manager 10, a function (second reception unit) for receiving a shift operation detected by the shift operation sensor 40 may be implemented in a device other than the manager 10, or in the shift control unit 50. Furthermore, among the functions of the arbitration unit 12 of the manager 10, a function (second arbitration unit) for determining whether or not to respond to a driver's request based on the control status may be implemented in a device other than the manager 10, or in the shift control unit 50.

[0028] [control] Further referring to FIG. 2, the control executed by the manager 10 according to this embodiment will be described. FIG. 2 is a flowchart illustrating the processing procedure of arbitration control related to the shift range executed by the arbitration unit 12 of the manager 10. In this flowchart, arbitration control will be described using as an example a case in which the driver's request is a shift operation, a specific application in which a state exists in which the shift request of its own function should be prioritized over the driver's request, and a non-specific application in which the driver's request is prioritized over the shift request of its own function are implemented in the same ECU. An example of the driver's request is a shift operation, an automatic parking application is an example of the specific application, and a PKSB application is an example of the non-specific application.

[0029] The arbitration control shown in FIG. 2 is started, for example, when a shift operation is performed by the driver, which is a driver request.

[0030] (Step S201) The arbitration unit 12 acquires, via the reception unit 11, from an ECU that implements an automatic parking application, the application ID of the application for which the ECU requests the manager 10 to provide an action plan, the shift range request value requested by the application in the action plan, and the control status of the application. The acquired control status includes at least a control status indicating the control state of the automatic parking function realized by the automatic parking application, which is a specific application. Note that the arbitration unit 12 may acquire the control status of all applications implemented in the ECU. The arbitration unit 12 acquires the application ID, shift range request value, and control status from the ECU whenever necessary for arbitration, not just when requested by the driver. When the application ID, shift range request value, and control status are acquired from the ECU that implements the automatic parking application, the process proceeds to step S202.

[0031] Examples of the control status of the automatic parking function include "out of control," which indicates that the automatic parking function is not operating; "in control," which indicates that the automatic parking function is operating; "control suspended," which indicates that the automatic parking function is operating but processing is temporarily suspended; and "control termination processing in progress," which indicates that post-processing is being performed until the automatic parking function has completed vehicle movement and terminated operation. Note that the control status classifications are not limited to those described above. For example, a new control status classification may be added, such as "control start processing in progress," which indicates that pre-processing is being performed until the automatic parking function is activated and the vehicle starts moving, or "control termination processing in progress" may be included in the "in control" classification.

[0032] (Step S202) The arbitration unit 12 determines whether the automatic parking function realized by the automatic parking application is operating. This determination may be made based on whether the app ID acquired from the ECU is that of the automatic parking application, or whether the control status of the dynamic parking function acquired from the ECU is "control in progress," "control suspended," or "control termination processing in progress." If the arbitration unit 12 determines that the automatic parking function is operating (step S202, Yes), the process proceeds to step S203. If the arbitration unit 12 determines that the automatic parking function is not operating (step S202, No), the arbitration control ends.

[0033] (Step S203) The arbitration unit 12 determines whether the app ID acquired from the ECU that implements the automatic parking application is for an application other than the automatic parking application (such as the PKSB application). For example, if another function is selected while the automatic parking function is in operation (if another control intervenes), the app ID temporarily becomes that of an application other than the automatic parking application. If the arbitration unit 12 determines that the app ID is that of an application other than the automatic parking application (Yes in step S203), it is not possible to determine from the app ID whether the automatic parking function is stopped or in operation, and the process proceeds to step S204. On the other hand, if the arbitration unit 12 determines that the app ID is not that of an application other than the automatic parking application (No in step S203), the app ID becomes that of the automatic parking application, and the process proceeds to step S207.

[0034] (Step S204) The arbitration unit 12 determines whether the control status of the automatic parking function is "out of control." If the arbitration unit 12 determines that the control status is "out of control" (step S204, Yes), the automatic parking function is not operating and the driver's request can be accepted, so the process proceeds to step S205. On the other hand, if the arbitration unit 12 determines that the control status is not "out of control" (step S204, No), the automatic parking function is operating and the driver's request cannot be accepted (the automatic parking function takes priority), so the process proceeds to step S207.

[0035] (Step S205) The arbitration unit 12 permits the driver to perform the shift operation as requested by the driver, and then the process proceeds to step S206.

[0036] (Step S206) The arbitration unit 12 sets the shift range to be instructed to the shift control unit 50 to the latest requested value. The latest requested value is set based on arbitration between the shift range requested value requested by an application other than the automatic parking application (such as the PKSB application) and the requested value according to the shift operation by the driver. Once the shift range instruction is set, this arbitration control ends.

[0037] (Step S207) The arbitration unit 12 does not permit (disallows) the shift operation by the driver, which is the driver's request. Then, the process proceeds to step S208.

[0038] (Step S208) The arbitration unit 12 sets the shift range to be instructed to the shift control unit 50 to the shift range request value requested by the automatic parking application. When the shift range instruction is set, this arbitration control ends.

[0039] <Actions and Effects> As described above, in a system according to one embodiment of the present disclosure, when a specific application (automatic parking application) in which a state exists in which the request of its own function (shift range request) should be prioritized over the request of the driver (driver's shift operation) and a non-specific application (PKSB application) that prioritizes the driver's request over the request of its own function (shift range request) are implemented in the same ECU, the ECU constantly outputs a control status indicating the control state of the function (automatic parking function) realized by the specific application to the manager.

[0040] This control status allows the manager to easily understand that a specific application's function (automatic parking function) is operating in the background of a function control (PKSB control) realized by an unspecified application. This allows the manager to refuse to respond to an input driver's request even if it does not obtain the application ID of the specific application.

[0041] In the above embodiment, an automatic parking application has been described as an application in which a state exists in which a request from the function itself should be prioritized over a request from a driver. However, similar processing can also be applied to applications other than the automatic parking application (e.g., an automatic driving application) in which a state exists in which a request from the function itself should be prioritized over a request from a driver.

[0042] In a system in which the ECU can output multiple appli IDs corresponding to multiple applications running on one ECU to the manager, the ECU may output the appli ID to the manager instead of the control status. Furthermore, when the ECU outputs the appli ID to the manager, the ECU may add information about whether the app ID's function can respond to a specific driver request, and the manager may store and retain that information in a storage unit or the like, thereby enabling similar processing.

[0043] The above describes one embodiment of the disclosed technology, but the present disclosure can be understood as not only a manager installed in a vehicle, but also an electronic control unit, a system including an electronic control unit and a manager, a control method executed by a manager equipped with a processor and memory, a control program, a computer-readable non-transitory storage medium storing a control program, or a vehicle equipped with a manager. [Industrial Applicability]

[0044] The present disclosure is useful for a manager mounted on a vehicle or the like. [Explanation of symbols]

[0045] 1 System 10. Manager 11 Reception 12 Mediation Department 13 Calculation section 14 Distribution section 20 Driving assistance systems 30 Actuator System 40 Shift operation sensor 50 Shift control section 100 In-Vehicle Network

Claims

1. A manager mounted on a vehicle, a first receiving unit that receives a plurality of action plans from a plurality of ADAS applications and a control status indicating an implementation state of control in the ADAS applications; a first arbitration unit that arbitrates the plurality of action plans accepted by the first acceptance unit, When a first ADAS application in which a state exists in which a request of its own function should be prioritized over a request of a driver and a second ADAS application that prioritizes the request of the driver over a request of its own function are implemented in one electronic control unit, the first reception unit always receives the control status of the first ADAS application from the one electronic control unit. Manager.

2. A second reception unit that receives a request from the driver; a second arbitration unit that arbitrates between the request of the driver received by the second reception unit and the arbitration result by the first arbitration unit, the second arbitration unit rejects a response to the driver's request accepted by the second acceptance unit based on the control status of the first ADAS application. The manager of claim 1 .

3. the first ADAS application includes an autonomous driving application; the second ADAS application includes a driving assistance application; The manager of claim 2 .

4. The autonomous driving application is an autonomous parking application that assists with parking, the driving assistance application is a PKSB application that assists in braking operation during low-speed driving, The driver's request is a request to control the setting of a shift range. The manager of claim 3 .

5. a storage unit that stores information indicating a relationship between the control status and whether or not a response to the driver's request is possible; A manager according to any one of claims 2 to 4.

6. 1. A system comprising: an electronic control unit for implementing two or more ADAS applications onboard a vehicle; and a manager, the electronic control unit includes an output unit that outputs to the manager an action plan of the ADAS application and a control status indicating an implementation state of control in the ADAS application; The manager: a receiving unit that receives the plurality of action plans and the plurality of control statuses from the electronic control unit; a mediation unit that mediates the plurality of action plans received by the reception unit, When the electronic control unit is equipped with a first ADAS application in which a state exists in which a request of its own function should be prioritized over a request of a driver, and a second ADAS application in which the driver's request is prioritized over a request of its own function, the electronic control unit constantly outputs the control status of the first ADAS application from the output unit to the manager. system.

7. A control method executed by a manager computer mounted on a vehicle, comprising: receiving, from one electronic control unit in which two or more ADAS applications are implemented, a plurality of action plans and a control status indicating an implementation state of control in the ADAS applications; and reconciling the received plurality of action plans; When a first ADAS application in which a state exists in which a request of its own function should be prioritized over a request of a driver and a second ADAS application in which a request of the driver is prioritized over a request of its own function are implemented in the one electronic control unit, the receiving step constantly receives the control status of the first ADAS application from the one electronic control unit. Control method.

8. A control program to be executed by a manager computer mounted on a vehicle, receiving, from one electronic control unit in which two or more ADAS applications are implemented, a plurality of action plans and a control status indicating an implementation state of control in the ADAS applications; and reconciling the received plurality of action plans; When a first ADAS application in which a state exists in which a request of its own function should be prioritized over a request of a driver and a second ADAS application in which a request of the driver is prioritized over a request of its own function are implemented in the one electronic control unit, the receiving step constantly receives the control status of the first ADAS application from the one electronic control unit. Control program.

9. A vehicle equipped with the manager according to any one of claims 1 to 5.

Images