ADELANTO, Calif. – The following is the first of three articles by: Fabio Squadrani, Senior Manager, Braking Systems of Applus IDIADA co-authored with Deaglán Ó Meachair, brake-engineering specialist of BrakeBetter.com.
Brake system development is currently facing a shift in the engineering and testing activities. Traditionally pedal feel tuning and performance refinement have been major issues, but along with electrification, the increasing level of driving automation is shifting development efforts into different directions.
For a brake system, the task of autonomous driving (with or without human presence) mandates redundancy in many subsystem elements. Therefore, a strong effort in understanding how to set targets is needed in order to correctly develop and validate reliable systems.
In this paper, the authors are initially defining a set of performance key factors, which will be used to define the global characteristics of the brake system. It is not necessary to deeply investigate the performance of the system to validate the operation of a vehicle equipped with a redundant braking system, but in the concept phase it is certainly useful to investigate how different architectures could potentially influence the vehicle performance.
Having investigated the structure of the system, the authors suggest how targets could be set for a vehicle equipped with a redundant brake system. This study is mainly focused on understanding and validating how failures affect the general performance of the vehicle. Primarily this paper shows how partial system failures (ESP, EPB, IEB) affect the general braking performance, mainly in terms of deceleration, stopping distance, front/rear modulation, on slope braking performance and finally time-to-lock.
The main output of this study is the definition of a validation matrix (a so-called Design Validation Plan), which is certainly a necessary step in order to perform a robust Vehicle Target Setting (VTS). A list of metrics is also proposed by the authors.
The target book generation needs to be as versatile as possible, in order to be adapted to the full range of available systems in the market, particularly when the systems allow automated driving levels higher than L3.
- Service Brake Concept
The brake system can be defined as a group of entities (either components or functions) that interact with each other to provide the most adequate and safe response to stop the vehicle. The brake system concept summarizes the interactions among the different entities as well as with its environment according to the system boundaries.
The system concept presents minor variations at high level when considering the different driving modes either with human driver or with robot driver and, when both modes are forced to coexist. The brake request input will depend on who or what is driving.
1.1 Human driver input
The human driver provides the brake input to the system by stepping on the brake pedal to achieve a target deceleration level on the vehicle. The system reduces the kinetic energy of the vehicle by applying a brake torque using friction brakes and/or the available regenerative torque; at the same time it provides feeling to the driver (pedal force and deceleration) to notice that vehicle speed is being reduced. During the whole process the system may dissipate part of the energy as heat to the environment or even generating audible noise; but these aspects are not considered on the project scope.
1.2 Robot driver input
The robot driver provides the brake input to the system by generating a deceleration demand to be achieved as the target deceleration level on the vehicle. As for the human driver, the system reduces the kinetic energy of the vehicle by applying a brake torque on the wheels and/or using the available regeneration energy; at the same time it provides feeling to the driver (deceleration) to notice that vehicle speed is being reduced.
1.3 Human + robot driver input
The scenario where both human and robot are interacting with the system is also possible, in that case the most restrictive brake request will be considered as priority for the brake system overriding the other input.
1.4 Primary brake unit
The primary unit is responsible to translate the brake request into the corresponding wheel torque therefore, an interaction with surrounding systems (i.e. eMotor) is required to define the brake torque split which will be considered to provide the necessary hydraulic pressure (translated to brake torque) to the wheels. The following picture summarizes all possible communication channels among entities within the primary unit and with the surrounding systems.
1.5 Secondary brake unit concept
The secondary unit is sometimes responsible to provide a safety braking response when the primary unit fails. Hydraulic Braking is available on both axles, but brake boost and modulation could only be available for one axle. While it is assumed that overall performance will be degraded compared to a fully functioning system, the Secondary Unit should fulfil all current braking regulations.
The interaction and communication among the different entities considers the scenario of full functionality as well. The performance and the functions of the primary unit under no failure scenario must be understood to decide which functions should be considered for the secondary unit when the primary is totally off, and even how both units should interact in case the primary is degraded by partial fail.
Some examples of full functionality scenarios are as follows:
- Driver brake request with regen brake ON
- Driver brake request with regen brake OFF
- ABS Intervention
- AEB Intervention
- Brake to rest
- Redundancy scenarios.
The interaction and communication among the different entities within the secondary unit has to be studied as well based on the system concept. The scenarios are assuming a failure on the primary unit therefore, the secondary is forced to act accordingly to provide wheel torque.
1.7.1. Driver Brake Request
The scenario considers a driver request of 0.2g deceleration. There is no regenerative braking because the primary unit is under failure and the secondary unit is controlling one axle, which could be a not driven axle.
The hydraulic pressure is built up to meet the required deceleration with the front wheels only, for instance. Due to the low deceleration request, there is no need for any additional boost or modulation.
1.7.2. ABS Intervention
The scenario considers a 0.2g braking where the ABS intervention is required (i.e. loss of tyre grip in one specific wheel). The brakes modulation is required to have maximum tyre control so, ABS is being activated in front wheels to ensure vehicle stability while braking. Again, as it is a low deceleration request there is no need to modulate the rear wheels to stop the vehicle.
1.7.3. AEB Event
The scenario considers again an initial 0.2g braking where AEB is suddenly requiring 1.2g. In this case it is a high demanding brake request therefore, the torque split considers either the front axle (hydraulic brakes) and the rear axle (EPB intervention, for instance). From the total brake request, the front axle will provide as much deceleration as possible due to the brake modulation is available and wheel control is feasible; it will build up hydraulic pressure to provide 1g deceleration. The remain request will be provided by modulating the EPB up to additional 0.2g in the rear wheels.
About Applus IDIADA
With more than 25 years’ experience and 2,450 engineers specializing in vehicle development, Applus IDIADA is a leading engineering company providing design, testing, engineering, and homologation services to the automotive industry worldwide.
Applus IDIADA is located in California and Michigan, with further presence in 25 other countries, mainly in Europe and Asia.
Deaglán Ó Meachair established Brakebetter.com to improve the efficiency of the planet’s electric vehicle fleet, by offering the automotive industry the insight and support required to move from legacy systems and grasp the vast potential available through electrification.