Exercise manager, brake device control device, and control method

Abstract

To reduce a load on development of an application.SOLUTION: A motion manager 91 includes a reception part 92, an arbitration part 93, a generation part 94, and a storage part 95. The reception part 92 receives a motion request corresponding to an application 63 from each application 63. The arbitration part 93 arbitrates a motion request received by the reception part 92. The generation part 94 generates an index value of an operation request output to a brake control part 96, on the basis of the arbitration result by the arbitration part 93. The storage part 95 previously stores type information TI of an actuator 44 as a control object by the brake control part 96. The generation part 94 generates the index value of the operation request, using the type information TI of the actuator 44 stored in the storage part 95.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention relates to a motion manager, a control device for a braking device, and a control method.

Background Art

[0002] Patent Document 1 describes a motion manager. The motion manager is mounted on a vehicle. The motion manager includes a reception unit, a mediation unit, and a generation unit. The reception unit receives requests from a plurality of applications. The mediation unit mediates the plurality of requests received by the reception unit. The generation unit generates, based on the mediation result by the mediation unit, an instruction value of a motion request to be output to, for example, a brake control unit.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The motion manager described in Patent Document 1 may receive a plurality of preliminary braking requests from a plurality of applications. When each application makes a preliminary braking request, the instruction value for realizing the preliminary braking differs depending on the type and structure of the braking device, etc. Therefore, when developing an application, it must be designed so that, for each application, a preliminary braking request can be output in a manner adapted to the type and structure of the braking device, etc. Therefore, the burden of developing the application is large. In addition, although the preliminary braking of the braking device was used as an example above, the same problem exists when the braking device performs an operation other than the preliminary braking, and also in the case of a device other than the braking device.

Means for Solving the Problems

[0005] To solve the above problems, one aspect of the present disclosure is a motion manager mounted on a vehicle, comprising: a receiving unit capable of receiving motion requests corresponding to individual applications from said applications; an arbitration unit that arbitrates the motion requests received by the receiving unit; a generation unit that generates instruction values ​​for operation requests to be output to a control unit mounted on the vehicle based on the arbitration results by the arbitration unit; and a storage unit that stores in advance type information of actuators to be controlled by the control unit, wherein the generation unit generates the instruction values ​​using the actuator type information stored in the storage unit.

[0006] To solve the above problems, one aspect of the present disclosure is a control device for controlling a vehicle's brake system, comprising: a receiving unit capable of receiving motion requests corresponding to individual applications; an arbitration unit that arbitrates the motion requests received by the receiving unit; a generation unit that generates instruction values ​​for operation requests to be output to a control unit mounted on the vehicle based on the arbitration results by the arbitration unit; and a storage unit that stores in advance type information of actuators to be controlled by the control unit, wherein the generation unit generates the instruction values ​​using the actuator type information stored in the storage unit.

[0007] According to the above configuration, the memory unit pre-stores actuator type information. The generation unit can then use this actuator type information to generate instruction values ​​for motion requests. Therefore, even if the motion requests received from the application are not in a manner that matches the type or structure of the braking device, the system can generate instruction values ​​for motion requests to realize the mediated motion requests. Thus, when developing applications, development can be carried out using a unified standard. In other words, there is no need to develop an application for each type and structure of actuator.

[0008] To solve the above problems, one aspect of the present disclosure is a control method executed by a computer mounted on a vehicle, comprising: receiving motion requests corresponding to individual applications from said applications; mediating the received motion requests; and generating an instruction value for an operation request to be output to a control unit mounted on the vehicle based on the mediation result, wherein the instruction value is generated using actuator type information stored in advance by the computer.

[0009] According to the above configuration, the generation process can generate instruction values ​​for motion requests using actuator type information that the computer has pre-stored. Therefore, even if the motion requests received from the application are not in a manner that matches the type or structure of the braking device, instruction values ​​for motion requests can be generated to realize the mediated motion requests. Thus, when developing applications, development can be carried out using a unified standard. In other words, there is no need to develop an application for each type and structure of actuator. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 is a schematic diagram showing the vehicle's basic structure. [Figure 2] Figure 2 is a schematic diagram showing the brake ECU and brake system. [Figure 3] Figure 3 is a flowchart showing the control method for the braking system. [Modes for carrying out the invention]

[0011] (One embodiment) The following describes one embodiment of a motor manager, a control device having a motor manager, and a control method. The control device having a motor manager will be described below with reference to the drawings.

[0012] <Vehicle Overview> As shown in Figure 1, the vehicle 10 is equipped with an internal combustion engine 20, a steering system 30, a braking system 40, and a control device 50.

[0013] The internal combustion engine 20 is the power source for the vehicle 10. The internal combustion engine 20 has multiple actuators, such as a throttle valve, a fuel injector, and an ignition device, although these are not shown in the diagram. The internal combustion engine 20 burns fuel and drives the vehicle 10 by controlling each of the above actuators by the control device 50.

[0014] The steering device 30 changes the steering angle of the steering wheels of the vehicle 10. The steering device 30 has electric power steering. The electric power steering assists the driver's steering operation by controlling actuators via the control device 50. In addition, the electric power steering can fine-tune the amount of steering input by the driver or adjust the steering angle independently of the driver's input by controlling actuators via the control device 50.

[0015] The brake system 40 is installed on each wheel of the vehicle 10. The brake system 40 is a disc brake that generates braking force using hydraulic pressure. As shown in Figure 2, the brake system 40 has a disc 41, a brake pad 42, and an actuator 44 that applies hydraulic pressure to the brake pad 42. In other words, the actuator 44 outputs hydraulic pressure. The disc 41 is a rotating body that rotates integrally with the wheel of the vehicle 10. The brake pad 42 is a friction material supported by the body of the vehicle 10. The hydraulic pressure from the actuator 44 is controlled by the control device 50. The brake system 40 generates braking force on the vehicle 10 by bringing the disc 41 and the brake pad 42 into contact.

[0016] As shown in Figure 1, the control unit 50 includes an advanced safety ECU 60, an engine ECU 70, a steering ECU 80, and a brake ECU 90. Each ECU can exchange signals with each other via an internal bus (not shown).

[0017] The advanced safety ECU 60 implements functions related to the driving assistance of the vehicle 10. Specifically, the advanced safety ECU 60 includes a CPU 61 and a ROM 62. The ROM 62 stores multiple applications 63. Each application 63 is a program that implements the functions of the advanced driver assistance system. An example of an application 63 is an ACC (Adaptive Cruise Control) application for following a vehicle while maintaining a constant distance from the vehicle in front. The ACC application requests acceleration and deceleration from each actuator mounted on the vehicle 10 so that the vehicle 10 can drive while maintaining a constant distance from the vehicle in front.

[0018] Another example of application 63 is an ASL (Auto Speed ​​Limiter) application that recognizes the speed limit and maintains the vehicle 10's speed below that limit. Furthermore, another example of application 63 is a collision mitigation braking application, also known as an AEB (Autonomous Emergency Braking) application, which automatically applies the brakes to reduce the damage of a collision with vehicle 10. Another example of application 63 is a lane keeping assist application, also known as an LKA (Lane Keeping Assist) application, which maintains the lane in which vehicle 10 is traveling.

[0019] The CPU 61 acquires detection values ​​from multiple sensors (not shown) mounted on the vehicle 10. Using the detection values ​​from the sensors, the CPU 61 executes each application 63 stored in the ROM 62. When the CPU 61 executes each application 63, it outputs a motion request corresponding to that application 63 so that the functions of that application 63 can be realized. The CPU 61 may execute multiple applications 63 simultaneously. In this case, the CPU 61 outputs a separate motion request for each application 63 that is executed.

[0020] The CPU 61 outputs each motion requirement to an ECU having a control unit for an actuator that requires control in realizing the functions of each application 63. Specifically, the CPU 61 outputs the motion requirement to one or more selected from the engine ECU 70, the steering ECU 80, and the brake ECU 90.

[0021] Here, the motion requirement output by the CPU 61 is a signal indicating the magnitude of the required output for each of the actuators of the internal combustion engine 20, the steering device 30, and the brake device 40 actuator 44. For example, the types of motion requirements for the brake device 40 are divided step by step in descending order of the magnitude of the braking force output by the brake device 40: emergency braking, medium braking, weak braking, first standby braking, second standby braking, and third standby braking. Note that the hydraulic pressure output by the actuator 44 of the brake device 40 decreases step by step in the order of emergency braking, medium braking, weak braking, and standby braking.

[0022] The first standby braking, the second standby braking, and the third standby braking are to make the distance between the disk 41 and the brake pad 42 in the brake device 40 smaller than in the state where the actuator 44 is not outputting hydraulic pressure. Specifically, the first standby braking is to make the distance between the disk 41 and the brake pad 42 zero. And the second standby braking and the third standby braking are such that although the disk 41 and the brake pad 42 are separated, the distance between them is smaller than in the state where the actuator 44 is not outputting hydraulic pressure. And the third standby braking is to make the distance between the disk 41 and the brake pad 42 larger than the second standby braking. Therefore, when these first standby braking, second standby braking, and third standby braking are executed, the operation delay until the brake device 40 can exert braking force becomes smaller. And this operation delay increases in the order of the first standby braking, the second standby braking, and the third standby braking.

[0023] As described above, the motion request output by the CPU 61 does not directly indicate, for example, the command value output to the actuator 44 of the braking device 40. That is, the motion request is common for the braking device 40, for example, and does not change according to the type of the braking device 40. On the other hand, the motion request is different for each device with a different function, such as the internal combustion engine 20, the steering device 30, and the braking device 40.

[0024] The engine ECU 70 is a computer including a CPU and a ROM, not shown in the figure. The CPU of the engine ECU 70 controls the internal combustion engine 20 by executing the program stored in the ROM. That is, the engine ECU 70 is a control device for controlling the internal combustion engine 20. In particular, the engine ECU 70 controls the internal combustion engine 20 based on the motion request from the advanced safety ECU 60.

[0025] The steering ECU 80 is a computer including a CPU and a ROM, not shown in the figure. The CPU of the steering ECU 80 controls the steering device 30 by executing the program stored in the ROM. That is, the steering ECU 80 is a control device for controlling the steering device 30. In particular, the steering ECU 80 controls the steering device 30 based on the motion request from the advanced safety ECU 60.

[0026] The brake ECU 90 is a computer including a CPU and a ROM, not shown in the figure. The CPU of the brake ECU 90 controls the braking device 40 by executing the program stored in the ROM. That is, the brake ECU 90 is a control device for controlling the braking device 40. In particular, the brake ECU 90 controls the braking device 40 based on the motion request from the advanced safety ECU 60.

[0027] <Brake ECU> Hereinafter, the operation when each application 63 stored in the advanced safety ECU 60 is executed will be described taking the case of the brake ECU 90 as an example.

[0028] As shown in Figure 2, the brake ECU 90 includes a motion manager 91 and a brake control unit 96. Although not shown in the figure, the brake ECU 90 also includes a CPU and ROM. The CPU of the brake ECU 90 executes programs for the motion manager and brake control stored in the ROM, thereby realizing the functions of the motion manager 91 and the brake control unit 96.

[0029] Specifically, as shown in Figure 3, the CPU of the brake ECU 90 executes the reception process S11, the arbitration process S12, the generation process S13, and the control process S14 by executing a program stored in ROM. Therefore, the CPU of the brake ECU 90 functions as the reception unit 92, arbitration unit 93, and generation unit 94 in the motion manager 91. In addition, the CPU of the brake ECU 90 functions as the brake control unit 96.

[0030] The ROM of the brake ECU 90 stores type information TI of the actuator 44 of the brake device 40 that the brake control unit 96 controls. The type information TI is information used to identify the type of brake device 40 that is actually installed in the vehicle 10 from among several types of brake devices 40 that may be installed in the vehicle 10. The ROM of the brake ECU 90 also stores multiple instruction value maps that associate each motion request with the instruction value of the operation request to realize that motion request. This instruction value is a signal that indicates the magnitude of the hydraulic pressure output by the actuator 44. The ROM of the brake ECU 90 stores an instruction value map for each type information TI.

[0031] As shown in Figure 3, when the brake ECU 90 receives a motion request from the advanced safety ECU 60 in order to realize the functions of the advanced driver assistance system, it starts controlling the brake device 40. When control of the brake device 40 is started, the brake ECU 90 first performs the reception process S11. In the reception process S11, the reception unit 92 performs the processing.

[0032] As shown in Figure 2, the reception unit 92 is capable of receiving motion requests corresponding to individual applications 63 from the advanced safety ECU 60. Specifically, each motion request is a signal indicating the magnitude of the braking force to be requested. As mentioned above, the advanced safety ECU 60 may also execute multiple applications 63 simultaneously. In this case, the reception unit 92 receives multiple motion requests and outputs multiple motion requests to the arbitration unit 93.

[0033] Subsequently, as shown in Figure 3, the brake ECU 90 proceeds to the arbitration process S12. In the arbitration process S12, the arbitration unit 93 performs the processing. As shown in Figure 2, the mediation unit 93 mediates the movement requests received by the reception unit 92. If the reception unit 92 has received only one movement request, the mediation unit 93 selects that movement request. On the other hand, if the reception unit 92 has received multiple movement requests, the mediation unit 93 mediates the multiple movement requests by selecting the movement request that will produce the greatest braking force.

[0034] Subsequently, as shown in Figure 3, the brake ECU 90 proceeds to the generation step S13. In the generation step S13, the generation unit 94 performs the processing. In the generation step S13, the generation unit 94 generates an instruction value for an operation request to be output to the brake control unit 96 mounted on the vehicle 10, based on the arbitration result by the arbitration unit 93. At this time, the generation unit 94 generates the instruction value for the operation request using the actuator type information TI stored in the memory unit 95 and the instruction value map corresponding to that type information TI.

[0035] Here, for example, suppose that the arbitration unit 93 selects a first pre-braking as the motion request. Even with the same first pre-braking, the instruction value required to implement the first pre-braking may differ depending on the type of actuator 44. For example, the instruction value required to implement the first pre-braking for actuator 44 of "Type A" may be "X value," while the instruction value required to implement the first pre-braking for actuator 44 of "Type B" may be "Y value." Therefore, the generation unit 94 identifies an instruction value map corresponding to the type information TI. Then, the generation unit 94 identifies a value corresponding to the motion request arbitrated by the arbitration unit 93 in the identified instruction value map and generates it as the instruction value for the motion request.

[0036] Subsequently, as shown in Figure 3, the brake ECU 90 proceeds to the control process S14. In the control process S14, the brake control unit 96 performs the processing. As shown in Figure 2, the brake control unit 96 outputs the instruction value of the operation request generated by the generation unit 94 to the actuator 44 of the brake device 40. As a result, the brake control unit 96 controls the brake device 40 by driving the actuator 44. After that, the brake ECU 90 completes the series of processes.

[0037] (Effect of the embodiment) According to the above embodiment, each application 63 outputs to the brake ECU 90 one of several types of motion requests, rather than a specific instruction value for the actuator 44 of the brake device 40. The motion manager 91 outputs an instruction value for the operation request to the actuator 44 in order to satisfy the requested motion request, depending on the type of brake device 40.

[0038] (Effects of the embodiment) (1) According to the above embodiment, the memory unit 95 stores the type information TI of the actuator 44 in advance. The generation unit 94 then uses the type information TI of the actuator 44 to generate instruction values ​​for operation requests. Therefore, the motion requests received from the application 63 do not need to be specific instruction values ​​that match the type and structure of the brake device 40, but can be any of a predetermined set of motion requests. Thus, when developing the application 63, development can be carried out using a unified standard that corresponds to the above motion requests. In other words, there is no need to develop separate applications 63 that can output appropriate specific instruction values ​​for each type and structure of the actuator 44.

[0039] (2) According to the above embodiment, the actuator 44 is included in the brake device 40. The brake device 40 is likely to receive motion requests from each application 63 that realizes the functions of the advanced driver assistance system. Moreover, there are countless types of brake devices 40 depending on the type of vehicle 10. For this reason, it is particularly preferable to adopt the configuration of the above embodiment for the application 63 that realizes motion requests by operating the brake device 40.

[0040] (3) According to the above embodiment, the actuator 44 outputs hydraulic pressure. The instruction value for requesting operation to the actuator 44 is a signal indicating the magnitude of the hydraulic pressure output by the actuator 44. When the output of the actuator 44 is hydraulic pressure, the waiting time for operation due to the braking force or pre-braking output by the brake device 40 is greatly affected by the type and structure of the brake device 40. For this reason, it is preferable to have the storage unit 95 store the type information TI of the brake device 40.

[0041] (4) According to the above embodiment, when the receiving unit 92 receives multiple motion requests, the mediation unit 93 mediates the multiple motion requests by selecting the motion request that will result in the largest hydraulic pressure indicated by the instruction value of the motion request. Therefore, when braking force is required, the mediation unit can select a motion request that will result in a greater braking force. Also, when only preliminary braking motion requests are received, the mediation unit can select a motion request that will result in a shorter waiting time for the action. Thus, it is possible to prevent insufficient braking force or excessively long waiting times for the action.

[0042] (5) The instruction value for the motion request to operate the brake device 40 to match the required waiting time for the motion request varies depending on the type and structure of the brake device 40. Therefore, in developing the application 63, more detailed information on the type and structure of the brake device 40 is required to realize pre-braking with different waiting times compared to main braking which generates braking force. Specifically, the correspondence between a certain instruction value for the motion request and the resulting gap between the disc 41 and the brake pad 42 strongly depends on the type and structure of the brake device 40. According to the above embodiment, the motion request type of the application 63 includes multiple pre-braking operations where the braking force is zero. The generation unit 94 can then generate instruction values ​​to request from the actuator 44 for pre-braking using the type information of the actuator 44 of the brake device 40 stored in the memory unit 95. Thus, the development burden of the application 63, which may become larger when making motion requests for pre-braking, can be reduced.

[0043] (Other embodiments) The above embodiment can be implemented with the following modifications. The above embodiment and the following modifications can be combined with each other to the extent that they do not contradict each other technically.

[0044] The vehicle 10 may be equipped with a motor that serves as the driving source for the vehicle 10, in addition to or instead of the internal combustion engine 20. In this case, the control device 50 may be equipped with a motor ECU that controls the motor, in addition to or instead of the engine ECU 70.

[0045] The type and structure of the brake device 40 are not limited to the structure of the embodiment described above. If the storage unit 95 stores the type information TI of the actuator 44 of the brake device 40, the motion manager 91 can generate operation requests that match the type and structure of the brake device 40.

[0046] The actuator 44 is not limited to one that outputs hydraulic pressure. It can be changed to a different type as appropriate to match the braking force generated by the brake device 40. Even in this case, if the memory unit 95 stores the type information TI of the brake device 40, the generation unit 94 can generate an appropriate output value for the operation request.

[0047] In the above embodiment, the brake ECU 90 includes a motion manager 91, and the control of the brake device 40 was described as an example, but the ECU that includes the motion manager is not limited to this. For example, the motion manager may be provided in at least one of the engine ECU 70 and the steering ECU 80, in addition to or instead of the brake ECU 90. In this case, for example, in the case of a motion manager included in the engine ECU 70, the memory unit of the motion manager only needs to store type information of each actuator of the internal combustion engine 20. The generation unit of the motion manager then needs to use the type information of the actuators of the internal combustion engine 20 stored in the memory unit to generate instruction values ​​for operation requests.

[0048] The motion manager 91 is not limited to being included in the brake system 40, even when it controls the brake system 40. For example, the motion manager 91 may be included in the advanced safety ECU 60. Also, for example, the control device 50 may have a management ECU that manages the internal combustion engine 20, the steering system 30, and the brake system 40 together, in which case the motion manager 91 may be included in the management ECU.

[0049] The control device 50 may be divided into a device having a motion manager 91 and a device having a brake control unit 96. In other words, the CPU that performs the reception process S11, the arbitration process S12, and the generation process S13 may be different from the CPU that performs the control process S14.

[0050] In the above embodiment, it was assumed that multiple applications 63 in the advanced safety ECU 60 are executed on the same CPU 61, but this is not limited to this. Individual applications 63 may be executed on different CPUs.

[0051] Application 63 is not limited to the applications exemplified in the above embodiments. For example, application 63 may be an ISA (Untelligent Speed ​​Assistance) application that controls the speed of the vehicle 10 so as not to exceed the upper speed limit.

[0052] The motion request output to the motion manager 91 by executing application 63 is not limited to a signal indicating the magnitude of the braking force. This motion request can be appropriately changed depending on the type of ECU to which the motion request is output. For example, if the motion request is for the steering device 30, it should be a signal indicating the magnitude of the steering angle.

[0053] The arbitration unit 93 does not have to arbitrate the motion requests based on the magnitude of the output values ​​of the motion requests. For example, the arbitration unit 93 may arbitrate by selecting the signal from the application 63 with the highest urgency. More specifically, for example, when the receiving unit 92 receives motion requests from the AEB application and the LKA application, it may arbitrate by selecting the motion request from the AEB application with the highest urgency.

[0054] Each application 63 may output the requested acceleration as a motion request if the magnitude of the braking force is greater than zero among the motion requests. In other words, in this case, the technology of the above embodiment may be applied only to the motion requests for the first to third pre-braking, where the magnitude of the braking force is zero. In this case, the burden on developing the application 63 that makes motion requests for pre-braking can be reduced.

[0055] In the above embodiment, the generation unit 94 generates the instruction value for the operation request using the instruction value map stored in the storage unit 95, but it is not limited to this. For example, instead of using the instruction value map, the generation unit 94 may generate the instruction value by multiplying a reference value by a coefficient corresponding to the type of actuator 44. [Explanation of symbols]

[0056] 10... Vehicles 20... Internal combustion engine 30… Steering gear 40…Brake system 50…Control device 60…Advanced safety ECU 61…CPU 62...ROM 63…Application 70…Engine ECU 80... Steering ECU 90...Brake ECU 91... Sports Manager 92... Reception Department 93...Mediation Department 94...Generation section 95...Storage section 96...Brake control unit S11... Reception process S12…Arbitration process S13…Generation process

Claims

1. A vehicle-mounted motion manager, A reception unit capable of receiving movement requests corresponding to each application from individual applications, A mediation unit that mediates the exercise requests received by the reception unit, A generation unit generates an instruction value for an operation request to be output to a control unit mounted on the vehicle, based on the arbitration result by the arbitration unit, The control unit has a storage unit that stores information about the type of actuator to be controlled in advance, Equipped with, The generation unit generates the instruction value using the actuator type information stored in the storage unit. Sports manager.

2. The actuator is included in a braking system that applies braking force to the vehicle. The exercise manager according to claim 1.

3. The actuator outputs hydraulic pressure, The indicated value is a signal indicating the magnitude of the hydraulic pressure output by the actuator. The exercise manager according to claim 2.

4. When the receiving unit receives multiple motion requests, the mediation unit mediates the multiple motion requests by selecting the motion request that will result in the largest hydraulic pressure indicated by the indicated value. The exercise manager according to claim 3.

5. A control device for controlling the brake system of a vehicle, The motion manager comprises: a receiving unit capable of receiving motion requests corresponding to individual applications; an arbitration unit that arbitrates the motion requests received by the receiving unit; a generation unit that generates instruction values ​​for operation requests to be output to a control unit mounted on the vehicle based on the arbitration results by the arbitration unit; and a storage unit that stores information on the type of actuator to be controlled by the control unit in advance. The generation unit generates the instruction value using the actuator type information stored in the storage unit. Brake system control device.

6. A control method performed by a computer installed in a vehicle, The system accepts movement requests corresponding to each application from individual applications, To mediate the aforementioned requests for action that have been received, Based on the mediation results, the system generates an instruction value for an operation request to be output to the control unit installed in the vehicle, Equipped with, In generating the aforementioned instruction value, the computer uses the actuator type information that it has stored in advance to generate the instruction value. Control method.

Images