vda ad hoc ak kreuztausch · 5.1.2 fmea structure ... vda recommendation 305-100 version may 2013...
TRANSCRIPT
VDA Recommendation for integration of Electric Parking Brakes control into ESC Control Units
305-100
This non-binding recommendation by the German Association of the Automotive Industry has the following objective: Definition of a technical standard for integrating the electronic parking brake actuator into the ESC (Electronic Stability Control) system, for cooperation between different suppliers (OES) of the ESC (ESC assembly) and the brake caliper (brake assembly)
Version May 2013
VDA Ad hoc AK Kreuztausch
Publisher: Verband der Automobilindustrie Copyright
Behrenstrasse 35 Reprints and any other form D-10117 Berlin of duplication are permitted only Tel.: +49 30 897842-0 if the source is cited.
Fax: 49 30 897842-606 Internet: www.vda.de
VDA Recommendation 305-100 Version May 2013 Page 2
Copyright: VDA
Disclaimer
VDA recommendations are freely available. They offer orientation for all interested companies, but do not take into consideration any general conditions for specific cases. They have to be interpreted by the business partners involved in the processes. VDA recommendations represent the latest technology at the time of issue. Application of VDA recommendations does not relieve the users of responsibility for their own actions. In this regard, all users act at their own risk. The VDA and those involved with VDA recommendations do not accept any liability. Anyone applying VDA recommendations who identifies inaccuracies or discrepancies is requested to inform the VDA and become involved in the continuing standardization process.
VDA Recommendation 305-100 Version May 2013 Page 3
Copyright: VDA
Table of Contents
1 Introduction ................................................................................................................... 6
1.1 Integration of the EPB control unit into the ESC .................................................... 6
1.2 Content of this document ...................................................................................... 6
1.3 Procedure .............................................................................................................. 7
2 System description ....................................................................................................... 7
2.1 Requirements for an electric parking brake in relation to integration ................... 10
2.2 Division into brake assembly and host ................................................................ 10
2.3 Scope of brake assembly and PBC component .................................................. 10
2.4 Scope of the host, including EPB-specific SSM components .............................. 11
3 Basic functional architecture ....................................................................................... 13
3.1 Definition of a functional architecture .................................................................. 13
3.1.1 Host safety barrier........................................................................................... 20
3.1.2 Parameter file (PBC-ParamFile) ..................................................................... 22
3.2 Software interface definition ................................................................................ 23
3.2.1 Actuation request interface ............................................................................. 23 3.2.1.1 Interface description .............................................................................. 24
3.2.1.2 Actuation request interface requirements .............................................. 25 3.2.2 Actuator control interface ................................................................................ 26
3.2.2.1 Interface description .............................................................................. 26 3.2.2.2 Actuator control requirements ............................................................... 28
3.2.3 Hydraulic pressure support interface .............................................................. 29 3.2.3.1 Interface description .............................................................................. 29
3.2.3.2 Hydraulic pressure support interface requirements ............................... 30 3.2.4 PbcOutOutOfSpecMsg support interface ........................................................ 31
3.2.4.1 Interface description .............................................................................. 31 3.2.4.2 PbcOutOutOfSpecMsg interface requirements ..................................... 31
3.2.5 Environmental data interface .......................................................................... 32 3.2.5.1 Interface description .............................................................................. 32
3.2.5.2 Environmental data interface requirements ........................................... 33 3.2.6 Diagnostic interface ........................................................................................ 34
3.2.6.1 Interface description .............................................................................. 34 3.2.6.2 Diagnostic interface requirements ......................................................... 36
3.2.7 Data storage interface..................................................................................... 37 3.2.7.1 Interface description .............................................................................. 37
3.2.7.2 Logical structure of memory .................................................................. 38 3.2.7.3 Data storage interface requirements ..................................................... 38
3.2.8 System mode management ............................................................................ 39 3.2.8.1 Interface description .............................................................................. 39
3.2.8.2 System mode management requests.................................................... 40 3.2.8.3 Initialization and cyclical operation ........................................................ 40
3.2.9 Fault management interface ........................................................................... 41 3.2.9.1 Interface description .............................................................................. 42
3.2.9.2 Fault management requirements .......................................................... 42 3.2.10 Development message interface .................................................................... 43
3.2.10.1 Interface description .............................................................................. 43
VDA Recommendation 305-100 Version May 2013 Page 4
Copyright: VDA
3.2.10.2 Development message requirements.................................................... 43
3.3 Park brake hardware (HW) (driver stage of parking brake actuator,
measurements, required computing capacity) ............................................................ 43
3.3.1 Definition of and requirements for the parking brake electronic hardware ...... 44 3.3.2 Definition of nominal load cases relevant to circuit design .............................. 45
3.3.3 Definition of borderline load cases relevant to circuit design .......................... 51
4 Functional safety ........................................................................................................ 55
4.1 Hazards and risks relevant to the EPB ................................................................ 55
4.1.1 Too high or unintended braking torque while vehicle is in motion (max. ASIL D) 55 4.1.2 Unintended braking torque while vehicle is stationary (max. ASIL A) ............. 56
4.1.3 Too little braking torque while vehicle is stationary (max. ASIL C) .................. 56 4.1.4 Incorrect driver information (max. ASIL B) ...................................................... 56
4.2 ASIL classification of relevant signals and sub-functions .................................... 56
4.3 PBC software integration ..................................................................................... 58
4.4 System integration ............................................................................................... 58
5 Proof of safety in interchangeability ............................................................................ 59
5.1 FMEA – responsibilities, interface coordination ................................................... 59
5.1.1 General conditions .......................................................................................... 59
5.1.2 FMEA structure ............................................................................................... 59 5.1.3 Handling information at the interface between the FMEAs ............................. 61
5.2 PMHF according to ISO 26262............................................................................ 62
5.2.1 General conditions .......................................................................................... 62
5.2.2 Evaluation ....................................................................................................... 62 5.2.3 Division of failure rates between various causes ............................................ 63
5.2.4 Evaluation procedure ...................................................................................... 63
6 Test concept ............................................................................................................... 64
6.1 Test strategy........................................................................................................ 64
6.1.1 Verification ...................................................................................................... 65
6.1.2 Validation ........................................................................................................ 66 6.1.3 Test stages ..................................................................................................... 66
6.1.4 General explanations and determination of the test strategy .......................... 66 6.1.5 Requirements for the components and system tests ...................................... 66
6.1.6 Test activities .................................................................................................. 68 6.1.6.1 Test activities of the brake-assembly OES ............................................ 68
6.1.6.2 Test activities of the ESC OES ............................................................. 69 6.1.6.3 Approval recommendation for the entire scope of supply ..................... 71
6.1.6.4 Stimulation matrix.................................................................................. 71
7 Handling of faulty parts ............................................................................................... 72
8 Cooperation matrix (RASI matrix) ............................................................................... 74
8.1 Objective ............................................................................................................. 74
8.2 Structure of the RASI matrix ................................................................................ 74
8.3 RASI matrix ......................................................................................................... 74
9 Regulations and standards ......................................................................................... 84
10 Glossary ..................................................................................................................... 85
11 Annex ......................................................................................................................... 87
VDA Recommendation 305-100 Version May 2013 Page 5
Copyright: VDA
11.1 ANNEX 3.2.A1: Interface details (Functional view) ............................................. 87
11.2 ANNEX 3.2.A2: Interface details (Software view) ................................................ 95
VDA Recommendation 305-100 Version May 2013 Page 6
Copyright: VDA
1 Introduction
1.1 Integration of the EPB control unit into the ESC
An electric parking brake (EPB) consists of:
the parking brake actuators to generate the force necessary for holding the vehicle in position,
an electronic control unit (ECU) containing the EPB function software, activation of the parking brake actuators and the associated hardware.
In addition to the independent EPB control unit, it is possible to integrate the control unit into the electronic stability control (ESC) system. To date, OES-specific solutions have been used to integrate the EPB-ECU into the control unit of the ESC. OES-independent combination of ESC and EPB will require unequivocal definitions of the shares supplied by the relevant suppliers, of the responsibilities involved, and of the interface between EPB and ESC within the ECU.
1.2 Content of this document
VDA recommendation 305-100 describes and defines the integration of the activation of caliper-integrated parking brake actuators into an ESC control unit from a different manufacturer.
This VDA recommendation describes:
the portions supplied by the OES of the EPB and the ESC
the responsibilities and the associated procedure
the functional architecture
the interface with the necessary detailed information
the safeguarding of functional security.
The content of this recommendation has been selected such that the constraints permit combining EPB and ESC from different suppliers, but without restricting further product-specific development by these OES.
VDA Recommendation 305-100 Version May 2013 Page 7
Copyright: VDA
1.3 Procedure
Inquiries during the awarding of projects with integration of the EPB-ECU into the ESC-ECU have shown that a clear, unified interface definition has to be provided. VDA recommendation 305-100 contains the following:
In chapter 2: Description of the system and its components
In chapter 3: Definition of the functional architecture and requirements for the associated software and hardware
In chapter 4: Consideration of functional safety
In chapter 5: Structure of a “Failure Mode and Effects Analysis (FMEA) and the procedure within a project involving two OES
In chapter 6: Test concept
In chapter 7: Handling of faulty parts
In chapter 8: Responsibilities
In chapters 9, 10 & 11: regulations and standards, glossary and annexes
This sets out the constraints and workflows for OES-independent combination of the EPB and ESC with the EPB-ECU integrated into the ESC.
2 System description The EPB system on which this VDA recommendation is based is divided into two parts from two different suppliers. One part of the EPB system contains the parking brake actuator, the parking brake caliper and the actuation logic (parking brake controller, PBC) (see Figure 2B1, green). The second part of the EPB system, also called the host, contains the EPB power electronics and necessary peripherals, and controls the functions that the driver can experience (see Figure 2B1, blue).
VDA Recommendation 305-100 Version May 2013 Page 8
Copyright: VDA
Figure 2B1: Schematic diagram of the integrated electric parking brake
The PBC is a software component designed specifically for the parking brake actuator and is integrated into the host. The integration of the EPB as described in this VDA recommendation is distinguished by the use of a single ESC control unit. The logical representation of the components used and their allocation to the EPB and ESC systems are shown in Figure 2B2.
Figure 2B2: System network of the integrated electrical parking brake
EPB system
The wheel brakes including the parking brake actuators (left and right brake calipers)
PBC software for activating the parking brake actuators
EPB hardware for activating the EPB parking brake actuators
VDA Recommendation 305-100 Version May 2013 Page 9
Copyright: VDA
Host software for the functions that the driver will notice and the necessary peripherals (diagnosis, communication, vehicle sensors, operating system, etc.)
Common hardware contains the hardware components used jointly (e.g. microprocessor, electronic memory components, etc.)
ESC system
ESC hardware for realizing an active hydraulic pressure increase at one or all of the vehicle’s wheel brakes
ESC software for displaying the ESC functions: electronic stability control, anti-lock braking-system, etc.
Common hardware the hardware components used jointly (e.g. microprocessor, electronic memory components, etc.)
Figure 2B2 shows all the components of the brake assembly in green and those of the ESC assembly in blue. The assembly parts are explicitly different in the EPB and ESC systems (see Figure 2B2). The EPB system consists of brake-assembly and ESC-assembly components, while the ESC system consists solely of ESC-assembly components.
VDA Recommendation 305-100 Version May 2013 Page 10
Copyright: VDA
2.1 Requirements for an electric parking brake in relation to integration
The requirements placed on an electric parking brake regarding the operation and holding ability of the vehicle on inclined surfaces must satisfy at least the legal requirements and standards for parking brake systems. The requirements these documents place on parking brake system continue to be binding when a parking brake is integrated into a host system. Integration does not generate any new requirements for the mechanics or electronics of the parking brake system as compared with the system shown in Figure 2B1. The definition of the interface between the subsystems of the parking brake describes the maximum functional framework, within which manufacturer-specific levels of functionality are possible.
2.2 Division into brake assembly and host
The division into the subsystems brake assembly and host is a fundamental prerequisite for combining parking brake components from different manufacturers. The aims of this division are:
encapsulation of knowledge about particular components
clearly defined areas of responsibility
independent testing and approval of components from the different suppliers
enabling manufacturer-specific levels of functionality of the individual components.
The parking brake system is divided into the brake assembly and ESC assembly so
that these goals can be attained.
2.3 Scope of brake assembly and PBC component
The brake assembly is responsible for safe parking and correct release of the parking brake. When the vehicle is parked (parking situation), it must be held permanently in place within the specified incline range, without the driver having to be present. By contrast, when the vehicle is stopped (stopping situation) it must be held within the specified gradient range for only a strictly limited period of time by the auto-hold function, possibly with switching to the parking brake when the driver is present. Proper release describes complete opening of the parking brake so there is no longer any effective braking torque caused by the parking brake actuator.
VDA Recommendation 305-100 Version May 2013 Page 11
Copyright: VDA
The brake assembly contains the following components to cover this basic scope of the parking brake function:
service brakes with which the parking brake is realized
parking brake actuators used as control elements for the parking brake
activation software for activating the parking brake actuator. This is also called the parking brake control (PBC).
The PBC component contains the clamping force control algorithm, environment models (e.g. brake disc temperature model), safeguarding functions (e.g. re-clamping functions), diagnostic routines (e.g. brake pad replacement mode, etc.), component-specific degradation management and PBC-specific fault monitoring (fail-safe module). Furthermore, the PBC provides the host with information necessary for diagnosing the brake assembly. The PBC is integrated into the host as “black box” software. To this end, the PBC/host interface will be approved through approval of the “black box” software (see Section 6 “Test concept”). All responsibility for the PBC component rests with the manufacturer of the brake assembly.
2.4 Scope of the host, including EPB-specific SSM components
The host must provide the all the peripherals that are necessary for the brake-assembly manufacturer to implement the correct function of the parking brake. For this the brake assembly requires the following components:
hardware components o the power electronics necessary for activating the parking brake
actuator in either direction (release or apply) and the associated measurement of electric current and voltage
o the hydraulic actuator (ESC unit) for support as needed to the parking brake system for dynamic and static functions
o provision of the necessary resources for the PBC component to run: volatile and non-volatile memory computing power (run time)
o communication interface with the vehicle network
software components: o ESC functions for supporting the parking brake system in dynamic and
static functions o driver information interface o fault manager o degradation management o diagnostic interface o control software for the EPB power electronics o signal processing (recognizing signal from parking brake switch (see
Fig. 2B1), sensor and network signals) o standstill manager (SSM)
VDA Recommendation 305-100 Version May 2013 Page 12
Copyright: VDA
The SSM consists largely of functions of which the driver is aware, including functions such as:
evaluation of the state of the vehicle (static/dynamic)
request to release and apply the parking brake
comfort functions such as automatic release and application
requesting the dynamic deceleration function.
All responsibility for the host subsystem rests with the manufacturer of the ESC assembly.
VDA Recommendation 305-100 Version May 2013 Page 13
Copyright: VDA
3 Basic functional architecture
3.1 Definition of a functional architecture
The functional architecture shown below (Figure 3.1.B1) distributes the overall task of
an EPB system between the two defined OES components (ESC and brake assemblies) described in chapter 2.
PBC(EPB actuation control)
EPB HW driver controlEPB mech.
Actuator
HMI
brake
lights
ESC
control & actuator
Actuator Control(L/R)
Actuation request
SSM(EPB function control)
HPS
brake light request
persistent
data storage
Fault
management
system mode
management
Diagnosis
system wide services
Host Safety
Barier
Actuator voltage ¤t supply
EPB HW-Driver Enable
Hydraulic Actuation Request
Environmental Data
PBC-ParamFile
Bidirectional Communication
Unidirectional Communication
Development
Message
The functional architecture identifies the function blocks listed in Table 3.1.T1. Figure 3.1.B1 shows the function blocks of the EPB system in blue, which are allocated to the supplier of the ESC assembly. Taken together, the function blocks shown in blue represent the host. Integration of the host into the functional architecture of the ESC is the responsibility of the ESC-assembly supplier and is not covered by this recommendation. Integration of the host must not, however, restrict the functionality of the brake assembly. Figure 3.1.B1 shows only those connections that are necessary for explaining the integration of the PBC into the host. The parts supplied by the brake-assembly OES are shown in green in Figure 3.1.B1. Below the host and the PBC are also called “components.”
Function block Task
SSM Evaluation of the vehicle state (static/dynamic). Transfer of identified driver EPB-request to the PBC. Representation of the emergency brake functions and their allocation to either the hydraulic actuator or the mechanical actuator. Additional typical EPB-system functions, such as driving off function, standstill function, etc., form part of the SSM.
PBC Proper functioning of the EPB mech. actuator for safe parking of the vehicle and releasing the parking brake, arbitration
Figure 3.1.B1: Specimen functional architecture of the integrated EPB system including interfaces
Single unidirectional Communication
Unidirectional Communication
Bidirectional Communication
VDA Recommendation 305-100 Version May 2013 Page 14
Copyright: VDA
Function block Task
between actuation requests from diagnosis and for SSM, implementing the dynamic deceleration request via the parking brake actuators. The PBC parameter file (PBC-ParamFile) contains specific parameters of the PBC.
EPB HW driver control
Activation unit for the parking brake actuators in the direction requested and sending electric measurements to the PBC.
EPB mech. actuator Developing and archiving the electromechanical tension force; reducing the electromechanical tension force.
System-wide services
Providing services for data storage, diagnosis and monitoring of the system modes; fault management; communication of development messages.
Host safety barrier Safety mechanism for approving the EPB hardware drivers to avoid safety-critical activations of the parking brake actuators by the PBC.
HMI Control logic and actuation of driver information (e.g. warning lamps, status lamps and text messages).
Brake lights Control logic and request for brake lights
ESC control & actuator
Control logic and hardware of the hydraulic actuator
Environmental data Collecting, preparing and providing environmental data to the PBC.
Table 3.1.T2 lists the defined interfaces between the function blocks.
Interface Task
SSM 1 PBC
“Actuation request”
SSM PBC: actuation request PBC SSM: status data from the brake assembly
PBC EPB HW driver control “Actuator control L/R”
PBC EPB HW driver control: actuation command from the PBC EPB hardware driver control PBC: status information, current and voltage of the hardware driver for the parking brake actuators
EPB HW driver control EPB mech. actuator “Actuator voltage & current supply”
EPB HW driver control EPB mech. actuator: activation of the parking brake actuators in the direction requested, separate for L/R, by supplying current and voltage.
PBC System-wide service “Interface to system-wide services”
PBC System-wide service: providing internal PBC data for the ECU diagnostic interface, fault manager (FM) interface, providing data to be stored System-wide service PBC: providing stored data, transferring diagnostic requests, FM interface
1 Arrows indicate sender recipient
Table 3.1.T1: List of function blocks
VDA Recommendation 305-100 Version May 2013 Page 15
Copyright: VDA
Interface Task
PBC HMI “PbcOutOutOfSpecMsg”
Display indicating operation of the brake assembly outside the specification.
PBC ESC control & actuator “HPS”
PBC ESC control & actuator: hydraulic support request from the PBC for securing hold. ESC control & actuator PBC: status information
Environmental status information PBC
Providing environmental data to the PBC
SSM HMI “SSM/EPB driver info message”
Actuating driver information relevant to EPB (e.g. EPB status information, EPB fault information, function-based text messages)
SSM brake lights “Brake light request”
Actuating brake lights during an emergency brake request via the parking brake control unit
SSM ESC control & actuator “Hydraulic actuation request”
Requests for holding (e.g. auto-hold) and hydraulic dynamic deceleration via the hydraulic actuator.
Host safety barrier EPB HW driver control “EPB HW driver enable”
Enabling the “EPB HW driver control” for each direction separately (apply/release), for activating the parking brake actuators.
Functions are divided between the brake assembly and the ESC assembly as shown in Table 3.1T3.
EPB function Brake assy
ESC assembl
y Task
Vehicle state determination
X Determining the vehicle’s state with respect to motion; selecting and implementing the permitted EPB functions.
Brake environment model
X Brake models for carrying out the tasks of the brake assembly.
Driver information X Actuating the driver information relevant to EPB (e.g. EPB status information, EPB fault information, function-based text messages).
EPB functions when vehicle is stationary
Apply and release action
X
Activating the parking brake actuators in the direction to apply or release. Setting the tension force specified and securing correct release.
Static switch apply and release request
X Recognizing a valid driver request “Hold the vehicle at a standstill via the EPB” and
Table 3.1.T2: List of interfaces between the function blocks
VDA Recommendation 305-100 Version May 2013 Page 16
Copyright: VDA
EPB function Brake assy
ESC assembl
y Task
“Release the EPB” in the situation: operating the parking brake control unit. Transferring the recognized driver request to the brake assembly as a request.
Drive away release request
X
Recognizing a valid driver request “Release the EPB” in the situation: driving away. Transferring the recognized driver request to the brake assembly as a request.
Automatic park apply request
X
Recognizing a valid driver request “Hold the vehicle at a standstill using the EPB” in the situation: parking. Transferring the recognized driver request to the brake assembly as a request.
Engine stall apply request
X
Recognizing the necessity to “Hold the vehicle at a standstill using the EPB” if the engine stalls while pulling away. Transferring the request to the brake assembly.
External request (apply/release)
X
Recognizing valid, external requests (ACC, gearbox, etc.) to “Hold the vehicle at a standstill using the EPB” and “release the EPB”. Transferring the request to the brake assembly.
Hot brake re-clamp X
“Proactive re-clamping” Activating the parking brake actuator in the direction to apply, to ensure the holding achieved on initial application, at higher brake temperatures.
Roll-away detection re-clamp
X
“Reactive re-clamping” Activating the parking brake actuator in the direction to apply, to ensure the holding achieved on initial application, when vehicle motion is recognized.
Brake pad adjustment request
X
Recognizing the service request “Recalibrate EPB position”. Transferring the recognized service request to the brake assembly as a request.
Brake pad adjustment X
Activating the parking brake actuators in the direction to apply or release. Driving away and leaving the defined EPB recalibration positions and ensuring the correct final status, “EPB open”.
Hydraulic pressure support request
X
Recognizing the necessity of hydraulic pressure support to “Hold the vehicle at a standstill using the EPB”. Transferring the pressure request to the ESC assembly.
VDA Recommendation 305-100 Version May 2013 Page 17
Copyright: VDA
EPB function Brake assy
ESC assembl
y Task
Hydraulic pressure support
X Providing the requested hydraulic pressure in the EPB brakes.
EPB functions when vehicle is in motion
Hydraulic dynamic deceleration
X
Recognizing the driver request “Decelerate the vehicle” in the situation: operation of the parking brake control unit. Transferring the recognized driver request to the ESC control & actuator as a request.
Actuator dynamic deceleration request
X
Recognizing the driver request “Decelerate the vehicle” in the situation: operation of the parking brake control unit. Transferring the recognized driver request to the brake assembly as a request. This function is not a required part of the EPB system.
Actuator dynamic deceleration
X
Activating the parking brake actuator in the direction to apply or release. Ensuring the specified deceleration and controllability of the vehicle. Automatic “Release of the EPB” upon termination of request. This function is not a required part of the EPB system.
EPB fault recognition and fault management
Fault management X
Communicating with the diagnostic tester. Managing and saving the fault conditions of the ESC assembly and brake assembly and degradation of ESC-assembly functionality.
Monitor extension handler
X
Communicating with the ESC-assembly fault manager. Internal handling of the brake-assembly fault conditions and degradation of brake-assembly functionality.
Fault monitor host X Providing the necessary fault recognition routines for the host.
Fault Monitor BrakeAssy
X Providing the necessary fault recognition routines for the brake assembly.
EPB diagnosis (more in chapter 3.2.6)
Vehicle diagnostic X Communicating with the diagnostic tester and providing EPB-system-specific services.
Diagnostic support function brake assembly
X Providing brake-assembly-specific diagnostic functions and data relevant to diagnosis (brake status, measurements, etc.).
VDA Recommendation 305-100 Version May 2013 Page 18
Copyright: VDA
EPB function Brake assy
ESC assembl
y Task
EPB service functions
Brake pad change function request
X
Recognizing the service request “Move into position for changing brake pads” and “Leave position for changing brake pads”. Transferring the recognized service request to the brake assembly as a request.
Brake pad change function
X
Activating the parking brake actuators in the direction to release or apply. Moving into, securing and leaving the position for changing brake pads and securing the correct final status, “EPB open”.
Roller bench test function request
X
Recognizing the service request “EPB roller bench test”. Transferring the recognized service request to the brake assembly as a request.
Roller bench test function
X
Activating the parking brake actuators in the direction to apply or release. Moving into, securing and leaving the defined positions for the EPB roller bench test and securing the correct final state, “EPB open”.
Table 3.1.T3: Allocation of EPB functions to brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 19
Copyright: VDA
General requirements and definitions: Definitions and requirements for brake assembly and HOST #D3.1 The total times for locking and opening are specified between the OEM and brake-assembly
OES. The total time is determined in EPB interchangeability by the periods due to the ESC assembly and the brake assembly. The total time is the sum of the actuation time of the parking brake actuator and the operating times necessary for recognizing and implementing the driver request.
#D3.2 The operating time of the ESC assembly, including the time for recognizing the position of the parking brake control, is assumed to be 140 ms for EPB interchangeability, unless specified otherwise by the OEM.
#D3.3 The qualifiers necessary for the interface signals specified in chapter 3 are given in the table “Interface details” in Annex 3.2.A1 “Functional view” and 3.2.A2 “Software view”.
#R3.1 Neither the brake assembly nor the host may degrade without a corresponding fault entry.
#R3.2 The host may monitor the PBC only if a discrepancy exists between the PBC request and approval by the host safety barrier.
#R3.3 The PBC may monitor the HOST only if, due to this fault case, the PBC adopts the logical brake state PbcOutActuatorState = UNKNOWN.
#R3.4 Every component has its own degradation concept, which may refer only to the component-specific fault (component-specific degradation).
#R3.5 After initialization by the HOST, the PBC must be called up cyclically every 10 ms.
#R3.6 After initialization the HOST must cyclically update the PbcIn… data with valid values every 10 ms.
#R3.7 After initialization the PBC must cyclically update the PbcOut… data with valid values every 10 ms.
#D3.4
The total duration of initialization for the EPB system is to be specified by the OEM und divided between the ESC assembly and the brake assembly, which are provided by different suppliers. Recommendation: a wake event is followed by the communication of initial values on the vehicle bus after 150 ms, consistent data after 350 ms, held vehicle upon operation of the EPB control unit during standstill is less than 2 s.
#D3.5 The cycle of the PBC Init() is limited only by the total duration time of initialization specified by the OEM.
#R3.8 According to VDA recommendation, the EPB system shall be constructed to fulfill 100,000 load cycles (opening and locking) plus 2,500 re-clamping procedures, unless specified otherwise by the OEM.
#R3.9 The PBC software must be integrated into the HOST and can be programmed only in connection with the HOST.
Definitions and requirements for the PBC
#R3.10 The PBC must be developed in accordance with ASIL B (see “decomposition” in chapter 4.2).
#R3.11 The PBC must contain a strategy that enables a sensible reaction to erroneously designated interface information.
Definitions and requirements for the host
#R3.12 If there is no functional restriction of the hydraulic actuator, a dynamic braking request from the parking brake control unit must be executed via the hydraulic actuator.
#R3.13 The host has to provide a ROM section of 128 kB for the PBC.
#R3.14 The host has to provide a separate ROM section of 8 kB for the PBC parameter file.
#R3.15 The host has to provide a RAM section of 8 kB for the PBC (not including interface signals sent from the HOST to the PBC). Additionally the host has to provide a permanent, re-writable memory of 256 Byte for the PBC.
#R3.16 The host has to provide sufficient computing capacity for the PBC.
#R3.17 The PbcIn...-data shall be available unchanged during a complete calculation cycle of the PBC module.
VDA Recommendation 305-100 Version May 2013 Page 20
Copyright: VDA
Definitions and requirements for the host #R3.18 The host must display a simultaneous fault if the signal PbcInDiagOperationMode is not
“NormalMode”.
#R3.19 The host must be able to implement overall system requirements as in ASIL D.
#R3.20 The host must provide separate storage areas for the two components in order to preserve the independence of the two components as specified in ASIL B(D). (See “PBC software integration” in chapter 4.3)
#R3.21 The host shall prove the hardware resources (ROM, RAM, EEPROM, processing unit, etc.), which are used by the PBC and for the interface, for ASIL B integrity faults.
#R3.22 The host shall provide to load the PBC parameter file onto the ECU independently (without the rest of the ROM content) at any time. The aim is to avoid additional effort of integration for the ESC-assembly OES if the parameter file has been changed by the brake assembly. Within each project, other agreements can be made between the OES to increase storage efficiency.
#R3.23 The HOST shall not inhibit any PBC actuation request on the interface “PbcInApplyReleaseRequest” due to an acknowledged diagnostic request on the interface “PBCOutDiagRequestStatus”. (No component may degrade the other component.)
3.1.1 Host safety barrier
The host safety barrier enables development of the PBC according to ASIL B pursuant to the safety targets presented in chapter 4, with a maximum requirement of ASIL D. The constraints “ignition” and “key” are selected according to the requirements of ECE 13 H.
Ignition OFF/key removed Ignition ON/key inserted
v < 15 km/h PbcEnableLineLock = TRUE PbcEnableLineRelease = FALSE
PbcEnableLineLock = TRUE PbcEnableLineRelease = TRUE
v > 15 km/h and parking brake control unit in neutral or opening direction
PbcEnableLineLock = FALSE PbcEnableLineRelease = TRUE
PbcEnableLineLock = FALSE PbcEnableLineRelease = TRUE
v > 15 km/h and
parking brake control unit in locking direction (Actuator dynamic deceleration request)
PbcEnableLineLock = TRUE PbcEnableLineRelease = TRUE
PbcEnableLineLock = TRUE PbcEnableLineRelease = TRUE
Table 3.1.1 T1: Definition of the host safety barrier states
VDA Recommendation 305-100 Version May 2013 Page 21
Copyright: VDA
General requirements and definitions:
Definitions and requirements for the host safety barrier #R3.24 Approval of parking brake actuation for the specific direction shall be given via an additional
instance in the HOST (host safety barrier).
#R3.25 Approval of parking brake actuation shall be switched via the host safety barrier in accordance with table Definition of the Host Safety Barrier States.
#R3.26 In addition to the table Definition of the Host Safety Barrier States, approval of parking brake actuation shall be switched in apply direction via the host safety barrierfor 30 s after the actuation request PbcInApplyReleaseRequest = ParkApply/HoldApply/PadAdjustment/DynamicApply.
#R3.27 In addition to the table Definition of the Host Safety Barrier States, approval of parking brake actuation shall be switched in release direction via the host safety barrier for 5 s after the actuation request PbcInApplyReleaseRequest = Release or PbcInRollerbenchActive changes to FALSE or PbcInApplyReleaseRequest changes from DynamicApply to NONE.
#R3.28 In addition to the table Definition of the Host Safety Barrier States, approval of parking brake actuation shall be switched in release direction via the host safety barrier for 35 s after the actuation request PbcInApplyReleaseRequest = PadAdjustment.
#R3.29 In addition to the table Definition of the Host Safety Barrier States, approval of parking brake actuation shall be switched in release and apply direction via the host safety barrier during an actuation request PbcInApplyReleaseRequest = DynamicApply.
#R3.30 In addition to the table Definition of the Host Safety Barrier States, approval of parking brake actuation shall be switched in release and apply direction via the host safety barrier during an active factory diagnostic session.
#R3.31 In addition to the table Definition of the Host Safety Barrier States, approval of parking brake actuation shall be switched in release and apply direction via the host safety barrier for 35 s after the diagnostic actuation request PbcInDiagRequest.
#R3.32 The host shall recognize a fault in case of a not allowed actuation request from the PBC (host safety barrier lock ena or release ena = FALSE and simultaneous actuation request by the PBC).
INFORMATION: If the host safety barrier blocks implementation of the requested direction of parking brake actuation, this can be recognized by the PBC via internal mechanisms, based on the PbcInMotorDriverState information.
VDA Recommendation 305-100 Version May 2013 Page 22
Copyright: VDA
3.1.2 Parameter file (PBC-ParamFile)
The brake-assembly OES supplies, in addition to the PBC, a separate parameter file, the PBC-ParamFile, which contains parameters relevant to the function of the PBC. This brake-assembly parameter file can be uploaded to the control unit independently (without the rest of the ROM) at any time. The parameter file is supplied both to the ESC-assembly OES and to the OEM.
PBC(EPB actuation control)
PBC-ParamFile
#R3.34 The PBC parameter file shall be programmable independently with OEM-tools, provided
that the same size is given by the host, specified in EPB-Core-TechDesign_6574 (#R3.14).
#R3.35 The PBC-ParamFile must contain a CRC corresponding to the specification of the ESC-assembly OES (typically created during the software development process).
#R3.36 The PBC must carry out a compatibility check on the parameter file before it is used.
#R3.37 The PBC parameter file shall be adaptable during the developmental period. For this the relevant TOOLS shall use the ASAM standard. the necessary settings shall be provided by the ESC-assembly OES (e.g. the start address of the PBC-ParamFile in the ROM).
#R3.38 The ESC-assembly OES must ensure the integrity of parameter handling (e.g. PBC-ParamFile) in accordance with ASIL D.
Figure 3.1.2.B1: PBC-ParamFile as a separate part supplied with brake assembly
VDA Recommendation 305-100 Version May 2013 Page 23
Copyright: VDA
3.2 Software interface definition
The software interface definition describes in detail the interface between the brake assembly (here the PBC) and the ESC assembly (here the host). For clarity, in the following subsections the individual interfaces of the PBC are grouped by the identified host modules. A detailed representation of the interface can be found in the annex (Annex 3.2.A1 “Functional view” and 3.2.A2 “Software view”).
3.2.1 Actuation request interface
The actuation request interface is shown in Figure 3.2.1.B1. The actuation request interface contains a bidirectional communication between the SSM and the PBC. The tasks of the PBC and the SSM function block in relation to the interface are shown in Table 3.2.1.T1.
Figure 3.2.1.B1: Actuation request interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 24
Copyright: VDA
3.2.1.1 Interface description
Interface Task and interface content
PbcInApplyReleaseRequest SSM PBC: Transmitting EPB requests to the PBC.
None
ParkApply (apply request in “parking situation”)
HoldApply (apply request in “stopping situation”)
RollerBenchApply (apply request for the technical
examination of the parking brake function) Release
DynamicApply
PadAdjustment (brake pad wear adjustment)
PbcInRollerbenchActive SSM PBC: Transmitting a recognized roller bench situation. In this situation the brake assembly will react to a RollerBenchApply request with a brake-assembly-specific roller bench function. Upon discontinuation of the roller bench situation, an active roller bench function is terminated by release of the EPB.
PbcOutActuatorState (L/R) PBC SSM: Transmitting the current logical brake state for the individual wheels. A distinction is made between final states and transition states. Final states:
ParkApplied (parking situation, vehicle is held by EPB)
Released
Unknown (final state not defined)
HoldApplied (stopping situation, vehicle held by EPB)
CompletelyReleased Transition states:
Applying (electromechanical locking of the brake)
Releasing (electromechanical opening of the brake)
Table 3.2.1.T1: Actuation request interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 25
Copyright: VDA
3.2.1.2 Actuation request interface requirements
#R3.39 The SSM shall transmit the signal PbcInApplyReleaseRequest for more than two calculation
cycles of the PBC.2.
#R3.40 The SSM shall transmit the signal PbcInApplyReleaseRequest = DynamicApply for the complete duration of the request.
#R3.41 The PBC shall release the park brake automatically and ensure the correct final state "EPB open" if the request PbcInApplyReleaseRequest = DynamicApply was canceled.
#R3.42 The SSM shall transmit an actuation request PbcInApplyReleaseRequest = ParkApply in case of a transition from a hold situation (here: vehicle held by EPB) to a parking situation.
#R3.43 The SSM shall transmit an actuation request PbcInApplyReleseRequest = PadAdjustment for brake pad wear adjustment.
#R3.44 The parking-brake-actuator-specific conditions for actuation of the brake pad wear adjustment must be specified by the brake-assembly OES to the ESC-assembly OES.
#R3.45 The PBC shall not initiate a actuation request independently, which changes the logical final states PbcOutActuatorState “released” (=Released, CompletelyReleased) or “locked” (= Unknown, ParkApplied, HoldApplied) of the parking brake actuator.
#R3.46 The PBC shall not change the logical final states PbcOutActuatorState “released” (=Released, CompletelyReleased) or “locked” (= Unknown, ParkApplied, HoldApplied) of the parking brake actuator independently.
#R3.47 The PBC shall permanent provide the current state of the parking brake actuator PbcOutActuatorState.
#R3.48 The PBC shall only set a final state of the parking brake actuator if the current request: has not been performed (PbcOutActuatorState = “old state”) or was finally canceled (PbcOutActuatorState = unknown) or was successfully completed (PbcOutActuatorState = “new state”).
#R3.49 The SSM shall transmit PbcInApplyReleaseRequest = “RollerBenchApply” to the PBC, while the parking brake switch is in apply position and “PbcInRollerbenchActive = TRUE”.
#R3.50 The PBC shall implement all other specified requests as specified in each case while “PbcInRollerbenchActive = TRUE”.
#R3.51 The PBC shall cancle the active roller bench function and ensure the correct final state "EPB open", if “PbcInRollerbenchActive = FALSE” was transmitted.
#R3.52 The SSM shall provide the driver with the information “Vehicle held” if the PBC transmit the actuator state “ParkApplied” at both sides via PbcOutActuatorState (L/R).
#R3.53 The SSM shall provide the driver with the information “Vehicle cannot be driven safely” if the PBC transmit the actuator state “Released” not at both sides via PbcOutActuatorState (L/R).
2 Calculation cycles of the PBC
VDA Recommendation 305-100 Version May 2013 Page 26
Copyright: VDA
3.2.2 Actuator control interface
The actuator control request interface is shown in Figure 3.2.2.B1. The actuation request interface contains a bidirectional communication between the EPB hardware driver control and the PBC. The tasks of the PBC and the EPB hardware driver control function block in relation to the interface are shown in Table 3.2.2.T1.
3.2.2.1 Interface description
Interface Task
PbcInMotorCurrent (L/R) EPB HW driver control PBC: Transmitting the currently measured motor current of the parking brake actuator upon activation of the parking brake actuators.
PbcInMotorVoltage (L/R) EPB HW driver control PBC: Transmitting the currently measured voltage of the parking brake actuators to the motor connections of the ECU.
PbcInMotorDriverSupplyVoltage EPB HW driver control PBC: Transmitting the supply voltage currently measured
PbcInHostAvailability (L/R) EPB HW driver control PBC: Transmitting the current availability of the
Figure 3.2.2.B1: Actuator control interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 27
Copyright: VDA
Interface Task
electric supply lines3 of the host for the respective side. This signal gives feedback about which basic functionality of the EPB hardware driver control is still available.
None
Apply
Release
ApplyAndRelease
PbcInMotorDriverState (L/R) EPB HW driver control PBC: Transmitting the switching state of the EPB hardware driver control currently being executed
None (parking brake actuators in resting mode,
passive final stage)
Apply
Release
Stop (parking brake actuators in braking mode, active
final stage in short circuit of the parking brake actuators without provision of all electric parking brake actuator signals)
FreeRun (parking brake actuators in free run mode,
active final stage with provision of all electric parking brake actuator signals)
PbcOutMotorCommand (L/R) PBC EPB HW driver control: Transmitting the current actuation request to the EPB hardware driver control.
None (parking brake actuators in resting mode,
passive final stage) Apply
Release
Stop (parking brake actuators in braking mode, active
final stage in short circuit of the parking brake actuators without provision of all electric parking brake actuator signals)
FreeRun (parking brake actuators in free run mode,
active final stage with provision of all electric parking brake actuator signals)
PbcInPowerSupplyState EPB HW driver control PBC Transmitting the current power supply state to the PBC.
Normal
Limited (definition of “limited” and the system
reaction are to be specified by the OEM to the ESC-assembly OES and brake-assembly OES)
3 Independent of the current state of the HostSafetyBarrier
Table 3.2.2.T1: Actuator control interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 28
Copyright: VDA
3.2.2.2 Actuator control requirements
#R3.54 The host shall provide the signal PbcInMotorCurrent (L/R) cyclically every 10 ms with a data
field of ten 1 ms values.
#R3.55 PbcInMotorCurrent (L/R) must correspond to the positive actual motor current in the parking brake actuator request situations PbcOutMotorCommand (L/R) = None, Apply, Release, FreeRun.
#R3.56 PbcInMotorCurrent (L/R) does not have to correspond to the momentary physical motor current in the parking brake actuator request situation PbcOutMotorCommand (L/R) = Stop.
#R3.57 The host shall provide the voltage signal PbcInMotorVoltage (L/R) cyclically every 10 ms with a data field of ten 1 ms values.
#R3.58 PbcInMotorDriverSupplyVoltage must satisfy the requirements specified in 3.3.1.
#R3.59 The host shall provide the signal PbcInMotorDriverSupplyVoltage: signal cyclically every 10 ms.
#R3.60 PbcInMotorDriverSupplyVoltage: signal for EPB driver supply has a low pass filter with a cut-off frequency between 50 and 200 Hz and a minimum attenuation of 3 dB.
#R3.61 PbcInMotorCurrent (L/R) and PbcInMotorVoltage (L/R) signals are to be synchronized with a delay of less than 500 µs.
#R3.62 PbcInMotorCurrent (L/R) and PbcInMotorVoltage (L/R) signals must be equidistant from one another.
#R3.63 The host system must satisfy the Nyquist-Shannon theorem for the signals PbcInMotorCurrent(L/R), PbcInMotorVoltage(L/R) and PbcInMotorDriverSupplyVoltage.
#R3.64 The PBC shall inhibit the actuation request on the relevant channel or immediately cancel it (PbcOutMotorCommand = STOP and then NONE) in case of a unilateral (or bilateral) HOST unavailability (PbcInHostAvailability) and a PBC request (possibly from internal PBC functions).
#R3.65 The PBC shall be authorized to resume the actuation request in case of a uniliteral (or bilateral) Host unavailability (PbcInHostAvailability) shorter than 2 s and a PBC request (possibly from internal PBC functions), if the Host is available again.
#R3.66 The Host shall transmit its unavailability (PbcInHostAvailability) for the specific side (L/R) set as NONE in case of an unavailable PBC relevant value for PbcInMotorCurrent (L/R) or PbcInMotorVoltage (L/R).
#R3.67 The host shall actuate the final stages of the parking brake actuators with an applicable time delay between them.
#R3.68 The PBC shall transmit the requested PbcOutMotorCommand (L /R) during the duration of the actuation.
#R3.69 The PBC shall always cancel an actuation request by the actuation request PbcOutMotorCommand (L/R) = Stop.
#R3.70 The PBC shall always transmit the brake command PbcOutMotorCommand (L/R) = STOP until the parking brake actuator has come to a permanent standstill. (The duration of the brake command depends on the situation and the parking brake actuator, and is therefore the responsibility of the PBC manufacturer.) Exception: Within the parameters of the function “Actuator dynamic deceleration” a shortened stop request is accepted which must ensure that the maximum permissible starting current (see #RH27) is not exceeded during reversing.
#R3.71 The PBC shall only transmit an actuation request in apply or release direction if the parking brake actuator is stationary. Exception: Within the parameters of the function “Actuator dynamic deceleration” a shortened stop request is accepted which must ensure that the maximum permissible starting current (see #RH27) is not exceeded during reversing.
#R3.72 The state shall be set to neutral (none) if no actuation shall be executed or the actuation was canceled (stationary parking brake actuator).
#R3.73 In cases of unilateral (or bilateral) HOST unavailability (PbcInHostAvailability), on the defective channel the host must ensure that a request sent from the PBC is not implemented (intrinsic safety).
VDA Recommendation 305-100 Version May 2013 Page 29
Copyright: VDA
#R3.74 The delay between PbcOutMotorCommand (L/R) and activation of the parking brake actuators by the EPB HW driver control must be less than 20 ms.
#R3.75 The HostSafetyBarrier position NONE shall be immediately reflected by the HOST via the PbcInMotorDriverState=NONE to the PBC, but not via the PbcInHostAvailability.
#R3.76 The host shall transmit an unavailability of the EPB HW driver control to the PBC immediately via PbcInHostAvailability, independent of the HostSafetyBarrier position.
#R3.77 The signal PbcInMotorDriverState (L/R) shall provide the current switching state of the EPB HW driver control.
3.2.3 Hydraulic pressure support interface
The hydraulic pressure support interface (see Figure Hydraulic Pressure Support Interface) is required by the brake assembly in “special cases” to increase the clamping force that is generated purely electromechanically by the parking brake actuators, with the aim of ensuring the holding ability of the brake assembly. This hydraulic support is used only to build up the clamping force. The tasks of the PBC and ESC control & actuator function block relating to the interface are shown in Table 3.2.2.T1.
3.2.3.1 Interface description
Interface Task
PbcOutHpsRequest PBC ESC control & actuator: Transmitting the request for hydraulic support from the parking brake actuators
PbcOutHpsPressure PBC ESC control & actuator: Transmitting the current pressure request in the EPB brakes as absolute pressure for the hydraulic support for achieving safe vehicle holding
PbcInHpsAcknowledge ESC control & actuator PBC: Confirming that the pressure requested by the PBC via the signal PbcOutHpsPressure is
Figure 3.2.3.B1: Hydraulic pressure support interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 30
Copyright: VDA
Interface Task
achieved by the ESC assembly.
PbcInHpsAvailability ESC control & actuator PBC: Transmitting the current availability of the hydraulic actuator.
3.2.3.2 Hydraulic pressure support interface requirements
#D3.6 The hydraulic request can extend the clamping time of the EPB.
#R3.78 The ESC control & actuator must adjust the pressure in the EPB wheel brakes with a maximum tolerance of +30/-0 bar. (The basis for this tolerance are a corresponding design of the entire service brake system and of the specified operating range).
#R3.79 After initial adjustment of the PBC pressure request, the ESC control & actuator must adjust the pressure within the specified tolerance band for the duration of the PBC pressure request.
#R3.80 The PBC must request hydraulic pressure support by simultaneously setting the PbcOutHpsRequest and the desired pressure level via PbcOutHpsPressure.
#R3.81 The PBC pressure request must remain unchanged for the duration of the current parking brake request.
#R3.82 Active reduction of the pressure initiated by the driver in the EPB wheel brakes is not intended.
#R3.83 If ESC control & actuator unavailability (based on PbcInHpsAcknowledge and/or PbcInHpsAvailability) lasts longer than 2 s and a PBC pressure request exists (poss. from internal PBC functions), the PBC must cancel the existing request (PbcOutHpsPressure= 0).
#R3.84 The parking brake system is to be realized so that the total number of 1000 hydr. supports (1% of load cycles owing to the ASIL A categorization) is not exceeded.
#R3.85 The maximum pressure request for a hydraulic support is 100 bar.
#R3.86 The minimum pressure request for a hydraulic support is 30 bar.
#R3.87 If ESC control & actuator unavailability (based on PbcInHpsAcknowledge and/or PbcInHpsAvailability) lasts longer than 2 s and a PBC pressure request exists (poss. from internal PBC functions), the PBC must indicate that the target clamping force has not been achieved through a fault.
#R3.88 After completion/interruption of the current parking brake actuator request, the PBC pressure request must be cancelled.
#R3.89 The PBC expects that the pressure request is always possible within the framework specified by the host safety barrier.
Table 3.2.3.T1: Hydraulic pressure support interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 31
Copyright: VDA
3.2.4 PbcOutOutOfSpecMsg support interface
The PbcOutOutOfSpecMsg interface (see Figure 3.2.4.B1) is described in this document; however, the content has to be defined for each project. The tasks of the PBC and HMI function block in relation to the interface are shown in Table 3.2.4.T1.
3.2.4.1 Interface description
Interface Task
PbcOutOutOfSpecMsg PBC HMI: Information signal that the current vehicle state (e.g. brake temperature, gradient, etc.) lies outside the range specified for the parking brake.
3.2.4.2 PbcOutOutOfSpecMsg interface requirements
#R3.90 Must be specified by OEM and brake-assembly OES in the each customer project.
Figure 3.2.4.B1: PbcOutOutOfSpecMsg support interface between brake assembly and host
Table 3.2.4.T1: PbcOutOutOfSpecMsg support interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 32
Copyright: VDA
3.2.5 Environmental data interface
The environmental data interface is shown in Figure 3.2.5.B1. The environmental data interface contains unidirectional communication between the environmental data function block and the PBC. The tasks of the PBC and the environmental data function block in relation to the interface are shown in Table 3.2.5.T1.
PBC(EPB actuation control)
wheel speed info
service brake state
longitudinalacceleration info
ambient temp. info
PbcInLongAcceleration
PbcInWheelSpeed (FL/FR/RL/RR),
PbcInWheelPulse (FL/FR/RL/RR)
PbcInMasterCylinderPressure,
PbcInWheelPressure (FL/FR/RL/RR)
PbcInWheelPressureReliability(FL/FR/
RL/RR)
PbcInVehicleAmbientTemperature
3.2.5.1 Interface description
Interface Task
PbcInLongAcceleration Environmental data PBC: Measured longitudinal acceleration of the chassis.
PbcInWheelSpeed (FL/FR/RL/RR)
Environmental data PBC: Measured wheel speed at the respective wheel (FL/FR/RL/RR).
PbcInWheelPulse (FL/FR/RL/RR)
Environmental data PBC: Detected pulses of the wheel rotary speed sensor.
PbcInVehicleAmbientTemperature
Environmental data PBC: Measured ambient temperature of the vehicle.
PbcInMasterCylinderPressure Environmental data PBC: Measured signal of the pressure sensor at the master cylinder.
PbcInWheelPressure (FL/FR/RL/RR)
Environmental data PBC: Estimated (modeled) wheel pressure of the respective wheel brake.
PbcInWheelPressureReliability( Environmental data PBC:
Figure 3.2.5.B1: Environmental data support interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 33
Copyright: VDA
Interface Task
FL/FR/RL/RR) Additional information on the accuracy of the estimated (modeled) wheel pressure of the respective wheel brake.
3.2.5.2 Environmental data interface requirements
#R3.91 The Host shall provide PbcInLongAcceleration in accordance with interface details given in
the tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view” of the "VDA-Recommendation 305-100 Interchangeability". Unavailability shall be transmitted to the PBC via the reserved values.
#R3.92 The Host shall provide PbcInLongAcceleration with a low pass filter with a cut-off frequency of (typically) 100 Hz and a minimum dumping of 3 dB.
#R3.93 The Host shall provide PbcInWheelSpeed (FL/FR/RL/RR) in accordance with interface details given in the tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view” of the "VDA-Recommendation 305-100 Interchangeability".
#R3.94 The Host shall provide PbcInWheelSpeed (FL/FR/RL/RR) always in accordance with the current physical wheel speed. Unavailability shall be transmitted to the PBC via the reserved values.
#R3.95 The Host shall reflect the specific wheel speed direction in PbcInWheelSpeed (FL/FR/RL/RR) (if supported by the sensor system). The use of negative speeds has to be decided in the respective project.
#R3.96 The Host shall provide PbcInWheelPulse (FL/FR/RL/RR) in accordance with interface details given in the tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view” of the "VDA-Recommendation 305-100 Interchangeability".
#R3.97 The Host shall provide PbcInWheelPulse (FL/FR/RL/RR) always in accordance with the current physical wheel speed. Unavailability shall be transmitted to the PBC via the reserved values.
#R3.98 The Host shall provide PbcInVehicleAmbientTemperature in accordance with interface details given in the tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view” of the "VDA-Recommendation 305-100 Interchangeability".
#R3.99 The Host shall provide PbcInMasterCylinderPressure in accordance with interface details given in the tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view” of the "VDA-Recommendation 305-100 Interchangeability". Unavailability shall be transmitted to the PBC via the reserved values.
#R3.100 The Host shall provide PbcInWheelPressure in accordance with interface details given in the tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view” of the "VDA-Recommendation 305-100 Interchangeability". Unavailability shall be transmitted to the PBC via PbcInWheelPressureReliability (FL/FR/RL/RR).
#R3.101 The Host shall also reflect active rises and falls of pressure (TC, ACC, etc.) of each wheel in PbcInWheelPressure (FL/FR/RL/RR).
#R3.102 The Host shall provide information of active rises and falls of pressure (TC, ACC, etc.) of each wheel with the signal PbcInWheelPressureReliability (FL/FR/RL/RR).
Table 3.2.5.T1: Environmental data interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 34
Copyright: VDA
3.2.6 Diagnostic interface
The diagnostic interface is shown in Figure 3.2.6.B1. The diagnostic interface contains bidirectional communication between the diagnostic function block and the PBC. The tasks of the PBC and diagnostic function block in relation to the interface are shown in Table 3.2.6.T1.
3.2.6.1 Interface description
Interface Task
PbcInDiagOperationMode Diagnosis PBC: This signal provides information about which mode the PBC must adopt. The minimum requirement is “normal mode”. Possible additional modes include transport mode, factory mode, etc.
PbcInDiagRequest Diagnosis PBC: Diagnostic request for brake-assembly-specific diagnostic functions:
OpenBrakeRearLeft, OpenBrakeRearRight, OpenBrakeBoth,
CloseBrakeRearLeft, CloseBrakeRearRight, CloseBrakeBoth,
TouchBrakeRearLeft, TouchBrakeRearRight, TouchBrakeBoth,
Figure 3.2.6.B1: Diagnostic interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 35
Copyright: VDA
Interface Task
StepCloseRearLeft StepCloseRearRight StepCloseBoth
AssemblyCheck,
EnterMaintenanceMode, ExitMaintenanceMode
PbcInHostSoftwareVersion Diagnosis PBC: Provision of current host software version
PbcOutDiagRequestStatus
PBC Diagnosis: Status feedback about the diagnosis request from brake-assembly-specific diagnostic functions:
Idle
Started
Running
Done
Error
PbcOutDiagRequestAckowledge
PBC Diagnosis: Feedback about the diagnosis request from brake-assembly-specific diagnostic functions:
OpenBrakeRearLeft, OpenBrakeRearRight, OpenBrakeBoth,
CloseBrakeRearLeft, CloseBrakeRearRight, CloseBrakeBoth,
TouchBrakeRearLeft, TouchBrakeRearRight, TouchBrakeBoth,
StepCloseRearLeft StepCloseRearRight StepCloseBoth
AssemblyCheck
EnterMaintenanceMode, ExitMaintenanceMode
PbcOutDiagBrakeTemperatureLeft
PBC Diagnosis: Provision of brake-assembly-specific diagnosis-relevant information: brake temperature left
PbcOutDiagBrakeTemperatureRight
PBC Diagnosis: Provision of brake-assembly-specific diagnosis-relevant information: brake temperature right
VDA Recommendation 305-100 Version May 2013 Page 36
Copyright: VDA
Interface Task
PbcOutDiagActuationCounterLeft
PBC Diagnosis: Provision of brake-assembly-specific diagnosis-relevant information: actuation counter left
PbcOutDiagActuationCounterRight
PBC Diagnosis: Provision of brake-assembly-specific diagnosis-relevant information: actuation counter right
PbcOutDiagAchievedClampForceLeft
PBC Diagnosis: Provision of brake-assembly-specific diagnosis-relevant information: clamp force left
PbcOutDiagAchievedClampForceRight
PBC Diagnosis: Provision of brake-assembly-specific diagnosis-relevant information: clamp force right
PbcOutPbcSoftwareVersion
PBC Diagnosis: Provision of current version of PBC software
3.2.6.2 Diagnostic interface requirements
#R3.103 The PBC shall provide the diagnosis-relevant information continuously at the diagnostic
interface.
#R3.104 The Host shall use the diagnosis-relevant information only for diagnostic functions.
#R3.105 The PBC shall transmit "Started" at the interface PbcOutDiagRequestStatus until the state changed to "Running" or "Error".
#R3.106 The PBC shall transmit "Running" at the interface PbcOutDiagRequestStatus during the whole duration of the implementation.
#R3.107 The PBC shall transmit "Done" at the interface PbcOutDiagRequestStatus after a successfull implementation of the diagnosis request.
#R3.108 The PBC shall transmit "Error" at the interface PbcOutDiagRequestStatus if the diagnosis request was cancelled.
#R3.109 The PBC shall transmit each diagnosis request status for more than two calculation cycles at the interface PbcOutDiagRequestStatus.
#R3.110 The PBC shall transmit the current executed diagnosis request to the Host at the interface PbcOutDiagRequestAcknowledge during the whole duration of the diagnosis request.
#R3.111 The Host shall transmit each diagnosis request for more than two calculation cycles at the interface PbcInDiagRequest.
#R3.112 The PBC shall priorize a diagnosis request over a SSM request for prak brake actuation requests in accordance with OEM specifications.
Table 3.2.6.T1: Diagnostic interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 37
Copyright: VDA
#R3.113 The Host shall transmit the PbcInDiagOperationMode to the PBC continuously.
3.2.7 Data storage interface
The data storage interface is shown in Figure 3.2.7.B1. The data storage interface contains bidirectional communication between the persistent data storage function block and the PBC. The task of the interface is to secure PBC internal data for longer than one function cycle (typically shutdown and restart of the ECU). Scope and content fall within the expertise of the brake-assembly OES. Interpretation by the host is not provided for. The tasks of the PBC and the persistent data storage function block in relation to the interface are shown in Table 3.2.7.T1.
3.2.7.1 Interface description
Interface Task
PbcInDataStorageValid(1…3) Persistent data storage PBC: Validity information from the host to the brake assembly. Selective for each of the three specified ranges of stored data from the non-volatile rewritable memory.
PbcInUnexpectedPowerdown Persistent data storage PBC: Information from the host to the PBC on whether the host system has not been properly closed down. (e.g. unexpected power failure)
PbcInVariantItem Persistent data storage PBC: Coding items 1 to 64 (coding commands from the host to the PBC). The host does not have to have any knowledge of the content of the data.
PbcInDataStorageRead Persistent data storage PBC: Provision of brake-assembly-specific stored data from the non-volatile rewritable memory.
PbcOutDataStorageWrite PBC Persistent data storage:
Figure 3.2.7.B1: Data storage interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 38
Copyright: VDA
Interface Task
Provision of brake-assembly-specific data for storage in the non-volatile rewritable memory.
3.2.7.2 Logical structure of memory
The memory is part of the host and as such is divided into three areas so that data that have to be stored as soon as they are altered are separated from those that can only be stored when the host is shut down. A partition is selected in accordance with Table 3.2.7.T2.
Memory area Addresses Size Description
1 (Right) 1…N N = 8 Bytes Persistent data of right parking brake actuator
2 (Left) N+1…P N Bytes Persistent data of left parking brake actuator
3 (Other data) P+1…R 256 -2*N Bytes
Persistent data to be written in the post-run.
3.2.7.3 Data storage interface requirements
#R3.114 The Host shall not have to know the meaning of the content of the data storage interfaces.
#R3.115 The Host shall save the memory area 1 right after each change in the bit pattern.
#R3.116 The Host shall save the memory area 2 left after each change in the bit pattern.
#E3.1 The data to be stored for both memory areas 1 and 2 should be collected in a causal relationship relating to the relevant memory area and forwarded to the host within one time slice. (The aim is to minimize the writing cycles.)
#R3.117 The Host shall save the memory area 3 once after each change in the bit pattern during the ECU post-run time ("power down").
#R3.118 The Host shall provide the content of memory after a successfull storage to the PBC before the next call (e.g. Init or Cyclic).
#R3.119 The Host shall transmit a recognized read / write error (CRC or defective EEPROM) via the corresponding qualifier PbcInDataStorageValid(1...3) at the next PBC call (e.g. Init or Cyclic).
#R3.120 The Host shall transmit the signal “PbcInUnexpectedPowerDown” to the PBC if it was not shut down correctly (e.g. due to a voltage drop).
#R3.121 The Host shall also transmit the current read-out value from the memory to the PBC in case of a failure.
#R3.122 The Host shall provide a maximum number of memory commands of 1 million for each of the memory areas 1 and 2.
#R3.123 The Host shall provide a minimum number of memory commands of 100,000 for the memory area 3, but maximal as defined numbers of ignition cycles.
#R3.124 The Host shall implement a memory strategy if this is necessary for reaching the specified writing cycles.
Table 3.2.7.T1: Data storage interface between brake assembly and host
Table 3.2.7.T2: Logical memory partition
VDA Recommendation 305-100 Version May 2013 Page 39
Copyright: VDA
#R3.125 The Host shall writle 0xFF at in all PBC memory areas if the memory is in the initial delivery state.
#R3.126 The Host shall transmit valid data values of the memory areas 1 to 3 with the qualifier PbcInDataStorageValid(1...3) if the memory is in the initial delivery state.
#R3.127 The PBC parameter file must be provided by the brake-assembly OES.
#R3.128 The Host shall provide up to 64 configuration signals (items) of each 1 Byte via PbcInVariant Item.
#R3.129 The host must initialize unused configuration signals with the value 0xFF.
#R3.130 The host must be able to dynamically adjust the PbcInVariant Item configuration signals during the running time.
#R3.131 The host must provide the PbcIn… signals of the persistent data storage function block in accordance with interface details in the tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view”.
#R3.132 The PBC must provide the PbcOut… signals of the persistent data storage function block in accordance with interface details in the tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view”.
3.2.8 System mode management
System mode management monitors the activations of the PBC (PBC Init, PBC Cyclic, and PBC Exit) and provides system information. The system mode management interface is shown in Figure 3.2.8.B1. The tasks of the PBC and the system mode management function block in relation to the interface are shown in Table 3.2.8.T1.
3.2.8.1 Interface description
Interface Task
PbcInSleepTime System mode management PBC: Time between PBC Exit (last activation) and Init (first activation, e.g. in the new start-up cycle) of the PBC
PbcOutEcuPowerLatchRequest Request from PBC to host that the PBC must continue to be activated cyclically. If the PBC sends this request, the host must not terminate the cyclical activation.
Figure 3.2.8.B1: System mode management interface between brake assembly and host
Table 3.2.8.T1: System mode management interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 40
Copyright: VDA
3.2.8.2 System mode management requests
#R3.133 The Host shall call the PBC Cycle cyclic while PbcOutEcuPowerLatchRequest is
requested by the PBC, but at least for the operating time of the Host.
#R3.134 The PBC shall request the PbcOutEcuPowerLatchRequest maximal 60 min after the last actuation from "EPB open" to "EPB closed".
#R3.135 The Host shall stop the cyclical call of the PBC cycle and store a failure if the PBC requested PbcOutEcuPowerLatchRequest for longer than 60 min.
#R3.136 The Host shall provide PbcInSleepTime to the PBC at the latest 2 s after the first call of the PBC Cycle.
#R3.137 The Host shall provide the PBCInSleepTime in accordance with interface details in tables ANNEX 3.2.A1 “Functional view” and 3.2.A2 “Software view” of the "VDA-Recommendation 305-100 Interchangeability".
#R3.138 The Host shall provide the time between PBC Exit (last call) and Init (first call, e.g. in the new ignition cycle) with the signal PbcInSleepTime.
#R3.139 The Host shall transmit the specified fault value via the signal PbcInSleepTime in case of a fault.
#R3.140 The Host shall ensure that the signal PbcInSleepTime is constant during the current operating time.
3.2.8.3 Initialization and cyclical operation
The initialization of the PBC ensures the correct functioning of the PBC and should be carried out before cyclical operation. Figure 3.2.8.B2 shows the three PBC routines PBC_Init, PBC_Cyclic and PBC_Exit and the permitted transitions.
Figure 3.2.8.B2: Schematic representation of PBC routines and permitted transitions
VDA Recommendation 305-100 Version May 2013 Page 41
Copyright: VDA
General requirements and definitions: #R3.141 The Host shall already provide the persistent data (shadow storage 1 to 3), the respective
qualifiers and PbcInVariantItem for the initialization of the PBC.
#R3.142 The Host shall provide the signal PbcInUnexpectedPowerDown upon initialization immediately.
#R3.143 The PBC shall transmit all outgoing signals (PbcOut...) correctly at the interface to the Host by the completion of the PBC initialization phase.
#R3.144 The Host shall only update the shadow storage until it is in cyclical operating mode (write back).
#R3.145 The Host shall provide the valid configuration information PbcInVariantItem [64] to the PBC before the PBC initialization call.
#R3.146 The Host shall execute the PBC initialization in the context of host initialization.
#R3.147 The Host shall call the PBC functions as specified in the state diagram.
#R3.148 The Host shall not change the signal PbcInUnexpectedPowerDown and those of the shadow storage, including the respective qualifiers, during the initialization phase.
#R3.149 The PBC shall be responsible for initialization of the RAM areas which shall be written by the PBC.
#R3.150 When the PBC_Cyclic routine is activated, all the physical signals are correct and available, or are marked by appropriate qualifiers if they are not yet available due to starting delays.
#R3.151 The host must call PBC_Exit exactly once after the last PBC_Cyclic.
#R3.152 It must be possible to execute PBC_Exit exactly as the PBC_Cyclic within one program cycle.
3.2.9 Fault management interface
The fault management interface (Figure 3.2.9.B1) supports the valid standards such as ISO 14229-1 and Autosar (4.0). The PBC does not contain a fault manager of its own. The PBC contains all the necessary PBC fault monitors. The current PBC fault monitor status is transmitted to the host fault manager and handled there. Communication with diagnostic testers takes place solely via the host.
Figure 3.2.9.B1: Fault management interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 42
Copyright: VDA
3.2.9.1 Interface description
Interface Task
PbcInFaultRecoveryRequest (1…n)
Fault management PBC: Request for the relevant monitor to execute the recovery request.
PbcOutFaultStatus (1...n) PBC Fault management: Current status of the individual fault monitors
3.2.9.2 Fault management requirements
#R3.153 The HOST shall store the PBC fault status information.
#R3.154 The Host shall implement the DTC's of brake assembly in accordance to the "ZSB-Bremse-DTC-Spec" which is agreed between the OEM and the brake-assembly OES.
#R3.155 The Host shall control the warning of PBC faults.
#R3.156 The Host shall restore the warning consistent with the Host fault status after a ignition restart.
#R3.157 The Host shall implement the specified warning about a brake-assembly fault which is agreed between the OEM and brake-assembly OES for each fault.
#R3.158 The host shall provide the information "Veh cannot be driven safely” or “Veh cannot be held safely” to the driver due to the specifications agreed between the OEM and the brake-assembly OES.
#R3.159 The Host shall transmit a recovery request at least due to the following conditions: a) beginning of a new monitoring cycle b) deletion of the fault memory.
#R3.160 The PBC shall inform the Host if the responsibility for safe holding and proper release can be assumed by the brake-assembly, with the fault characteristic “EpbFullExternalRequestAvailability” which is specified in the "ZSB-Bremse-DTC-Spec".
#R3.161 The Host shall not use the fault characteristic “EpbFullExternalRequestAvailability” for suppressing actuation requests to the PBC.
#R3.162 The Host shall implement the fault characteristic “EpbFullExternalRequestAvailability” as specified by the brake-assembly OES for each fault in the "ZSB-Bremse-DTC-Spec".
#R3.163 The maximum number of possible PBC faults must not exceed 40.
#R3.164 The PBC shall set the status PbcOutFaultStatus = NotSupported for a monitor, if this fault monitor is not supported by the current selection of the vehicle configuration (but the fault is in parts supplied of the brake assembly). A status can be changed only by selecting a new configuration. All other statuses of the signal PbcOutFaultStatus (Passed, Failed, etc.) represent a supported fault monitor.
Table 3.2.9.T1: Fault management interface between brake assembly and host
Table 3.2.9.T1: Fault Management interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 43
Copyright: VDA
3.2.10 Development message interface
The development message interface (Figure 3.2.10.B1) supplies internal PBC data which can be used by the OEM during its development activities. These data are issued by the host via the bus system.
3.2.10.1 Interface description
Interface Task
PbcOutDevelopmentMessage (1…n)
PBC Development Message: Transmission of internal PBC values
3.2.10.2 Development message requirements
#R3.165 The HOST shall transmit the PbcOutDevelopmentMessages on the connected bus system.
#R3.166 The PbcOutDevelopmentMessages shall be agreed between the OEM and the brake-assembly OES.
#R3.167 The Host shall provide the development message interface with a size of 24 bytes unless specified otherwise by the OEM.
3.3 Park brake hardware (HW) (driver stage of parking brake actuator, measurements, required computing capacity)
The parking brake hardware definition describes in detail the requirements that an EPB system places on the electronic hardware. Chapter 2 of the VDA’s EPB interchangeability recommendation stipulates that the electronic hardware is to be supplied as part of the ESC assembly. This chapter sets down fundamental requirements for the electronic hardware. First, requirements for the electronic hardware and the signals are specified and, second, definitions of the load cases relevant to circuit design are listed.
Figure 3.2.10.B1: Development message interface between brake assembly and host
Table 3.2.10.T1: Development message interface between brake assembly and host
VDA Recommendation 305-100 Version May 2013 Page 44
Copyright: VDA
3.3.1 Definition of and requirements for the parking brake electronic hardware
#RH3.1
ECU operating temperature range: -40°C to 120°C, unless otherwise specified by the OEM
#RH3.2 Parking brake actuators’ operating range for voltage at the measuring point in the ECU: 9 V to 16 V, unless otherwise specified by the OEM
#RH3.3 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight must cover a lower measuring range from 0 to 23 A.
#RH3.4 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight must exhibit a minimum signal resolution of 60 mA/LSB in the lower measuring range.
#RH3.5 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight must not exceed a relative error as given in the table below in the lower measuring range: ±20% @ 0.8 A < I < 1.0 A ±15% @ 1.0 A < I < 2.0 A ±10% @ 2.0 A < I < 3.0 A ± 8% @ 3.0 A < I < Imax
#RH3.6 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight must cover an upper measuring range from 23 A to 50 A.
#RH3.7 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight must exhibit a minimum signal resolution of 80 mA/LSB in the upper measuring range.
#RH3.8 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight must not exceed a maximum relative error of 10% in the upper measuring range.
#RH3.9 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight must start from zero and rise continuously (clipping is not permitted).
#RH3.10 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight must exhibit a minimum sampling rate of 1 kHz.
#RH3.11 Parking brake actuators’ current signals PbcInMotorCurrentLeft and PbcInMotorCurrentRight are low-pass filtered with a cut-off frequency of 150 to 500 Hz and a minimum attenuation of 3 dB.
#RH3.12 Parking brake actuators’ operating voltages PbcInMotorVoltageLeft and Right: the range of the differential voltage of the signals UMxP
4 and UMxM
5 must cover a measuring range of 0
to +20 V.
#RH3.13 Actuator motor voltage PbcInMotorVoltageLeft and Right: the differential signal between UMxP and UMxM must correspond to a minimum resolution of 50 mV/LSB.
#RH3.14 Actuator motor voltage PbcInMotorVoltageLeft and Right: the differential signal between UMxP and UMxM must not exceed the maximum relative error of ±7% (8 to 20 V).
INFO Actuator motor voltage PbcInMotorVoltageLeft and Right: the differential signal between UMxP and UMxM has a minimum sampling rate of 1 kHz.
#RH3.15 Actuator motor voltage PbcInMotorVoltageLeft and Right: the differential signal between UMxP and UMxM is low-pass filtered with a cut-off frequency of 150 to 500 Hz and a minimum attenuation of 3 dB.
#RH3.16 The PbcInDriverSupplyVoltage signal for the EPB driver supply6 must cover a measuring
range from 0 to +20 V.
4 UMxP is the measuring point of the actuator voltage in the electric supply path of the parking brake actuator,
which ideally has supply voltage potential in the closing direction. This means that the parking brake actuator voltage is positive in the closing direction.
5 UMxM is the measuring point of the actuator voltage in the electric supply path of the parking brake actuator,
which ideally has mass potential. This means that the parking brake actuator voltage is positive in the closing direction.
6 "for EPB driver supply" refers to the measuring point for the EPB driver supply.
VDA Recommendation 305-100 Version May 2013 Page 45
Copyright: VDA
#RH3.17 The PbcInDriverSupplyVoltage signal for the EPB driver supply must exhibit a minimum signal resolution of 50 mV/LSB.
#RH3.18 The PbcInDriverSupplyVoltage signal for the EPB driver supply must not exceed a maximum relative error of ±6% (8 to 20 V).
#RH3.19 The signal for the EPB driver supply (PbcInDriverSupplyVoltage) must exhibit a minimum sampling rate of 100 Hz.
#RH3.20 Within all the defined operating ranges, the control units’ internal resistance between the input pins (supply voltage) and the output pins (parking brake actuators) must not exceed 70 mOhm (not incl. contact resistances, the voltage drop between input and output pins must not exceed 1.4 V – this applies to both power stage channels – and to currents of up to 20 A).
#RH3.21 The signal necessary for determining the gradient must be present with an accuracy of +/- 0.3 m/s² (for resolution, see ANNEX 3.2.A1).
#RH3.22 The right and left power stage channels for the parking brake actuators must be able to recognize fault statuses independently of each other.
#RH3.23 The host has the task of recognizing the following electrical faults: short circuit to ground, short circuit involving UBat and disconnection.
#RH3.24 The control unit must provide for an additional post-run period owing to the EPB function of at least 1000 h.
#RH3.25 After one complete actuation the control unit must be able to represent at least 4 re-clampings with a time delay of 3 s each.
#RH3.26 The internal resistance of the parking brake actuator must not exceed 200 mOhm under any circumstances.
#RH3.27 The control unit must be able to withstand a stall current in the parking brake actuator of 50 A for a period of at least 100 ms.
#RH3.28 It must be possible to actuate the right and left power stage channels for the parking brake actuators independently of each other.
#RH3.29 The right and left power stage channels for the parking brake actuators must be fully functional over the entire operating range of the parking brake actuators.
#RH3.30 For the load profiles, generally the product of EEApp= Ieff * tend applies. All profiles with an equivalent or lower value (EEApp) are permitted.
3.3.2 Definition of nominal load cases relevant to circuit design
Imot = current through the parking brake actuator Irsh = inrush current as the parking brake actuator is switched on Iload = load current as the parking brake actuator is switched off (dependent upon the parking brake actuators) Iidle = current at idle (without load) of the parking brake actuator Ibrake = current resulting when parking brake actuator slows down Ieff = effective current of the parking brake actuator for the action specified tend = time from when the parking brake actuator is switched on to when it
comes to a standstill.
VDA Recommendation 305-100 Version May 2013 Page 46
Copyright: VDA
Locking the parking brake
I mo
t
t
Irsh
Iload
Iidle
tendIbrake
0 t0tend
Ieff
EE_App
Requirements:
Parking brake actuator activation: typical/nominal
ECU supply voltage: 13.5 V
Temperature of parking brake actuator: 25°C (RT)
#DH3.1 Irsh = 30 A
#DH3.2 Ibrake = -15 A
#DH3.3 Ieff_lock = 8.9 A
#DH3.4 tend = 1.5 s
#DH3.5 EE_App = 13.4 As
#DH3.6 Load cycles: 100,000
VDA Recommendation 305-100 Version May 2013 Page 47
Copyright: VDA
Opening the parking brake
Ibrake
I mo
t
t
Irsh
Iload
Iidle
tend
0 t0tend
Ieff
EE_App
Requirements:
Parking brake actuator activation: typical/nominal
ECU supply voltage: 13.5 V
Temperature of parking brake actuator: 25°C (RT)
#DH3.7
Irsh = 30 A
#DH3.8 Ibrake = -28 A
#DH3.9 Ieff_lock = 6.3 A
#DH3.10 tend = 1.5 s
#DH3.11 EE_App = 9.5 As
#DH3.12 Load cycles: 100,000
VDA Recommendation 305-100 Version May 2013 Page 48
Copyright: VDA
Re-clamping the parking brake
I mo
t
t
Irsh
Iload
Iidle
tendIbrake
1 2 50 t0
tend
Ieff
EE_App
Requirements:
Parking brake actuator activation: typical/nominal
ECU supply voltage: 13.5 V
Temperature of parking brake actuator: 25°C (RT)
#DH3.13
The maximum energy input for a re-clamping procedure equals that of locking.
#DH3.14 EE_App = 13.4 As
#DH3.15 Cycles: 2,500
Adjusting the parking brake for wear
Requirements:
Parking brake actuator activation: typical/nominal
ECU supply voltage: 13.5 V
Temperature of parking brake actuator: 25°C (RT)
#DH3.16
The maximum energy input for a recalibration equals the sum of that for a locking operation and that for a releasing operation.
#DH3.17 EE_App = 22.9 As
#DH3.18 Load cycles: 300
VDA Recommendation 305-100 Version May 2013 Page 49
Copyright: VDA
Brake pad replacement function of the parking brake
I mo
t
t
Irsh
Iload
Iidle
tendIbrake
t0tend
Ieff
0
EE_App
Requirement: worn brake pads are exchanged for new parts
Parking brake actuator activation: typical/nominal
ECU supply voltage: 13.5 V
Temperature of parking brake actuator: 25°C (RT)
#DH3.19 Irsh = 30 A
#DH3.20 Ibrake = -15 A
#DH3.21 Ieff_lock = 5.2 A
#DH3.22 tend = 5 s
#DH3.23 EE_App = 26 As
#DH3.24
Load cycles: 6 brake pad changes under workshop conditions correspond to the nominal case plus 7 by the driver under nominal conditions.
VDA Recommendation 305-100 Version May 2013 Page 50
Copyright: VDA
Dynamic braking with the parking brake actuator
Requirement: deceleration from 30 km/h to vehicle standstill with a minimum deceleration of 0.15 g (pursuant to ECE-R 13 H --> 2.3.6).
Parking brake actuator activation: typical/nominal
ECU supply voltage: 13.5 V
Temperature of parking brake actuator: 25°C (RT)
#DH3.25 Irsh = 30 A
#DH3.26 Ibrake = -18 A
#DH3.27 Ieff_lock = 10 A
#DH3.28 tend = 3.5 s
#DH3.29 EE_App = 35 As
#DH3.30
Load cycles: the dynamic deceleration function with the parking brake actuator is required a maximum of 5 times over the lifetime.
VDA Recommendation 305-100 Version May 2013 Page 51
Copyright: VDA
3.3.3 Definition of borderline load cases relevant to circuit design
Locking the parking brake
I mo
t
t
Irsh
Iload
Iidle
tendIbrake
0 t0tend
Ieff
EE_App
Requirement: maximum actuation time and maximum Ieff
Parking brake actuator activation: borderline
ECU supply voltage: 9 V
Temperature of parking brake actuator: -40°C (TT)
#DH3.31 Irsh = 25 A
#DH3.32 Ibrake = -12 A
#DH3.33 Ieff_lock = 12 A
#DH3.34 tend = 2.5 s
#DH3.35 EE_App = 30 As
#DH3.36
Load cycles: distribution of load cycles in accordance with the required test program.
VDA Recommendation 305-100 Version May 2013 Page 52
Copyright: VDA
Opening the parking brake
Ibrake
I mo
t
t
Irsh
Iload
Iidle
tend
0 t0tend
Ieff
EE_App
Requirement: maximum actuation time and maximum Ieff
Parking brake actuator activation: borderline
ECU supply voltage: 9 V
Temperature of parking brake actuator: -40°C (TT)
#DH3.37 Irsh = 25 A
#DH3.38 Ibrake = -15 A
#DH3.39 Ieff_lock = 6.5 A
#DH3.40 tend = 2.2 s
#DH3.41 EE_App = 14.3 As
#DH3.42 Load cycles: distribution of load cycles in accordance with the required test program
VDA Recommendation 305-100 Version May 2013 Page 53
Copyright: VDA
Re-clamping the parking brake
I mo
t
t
Irsh
Iload
Iidle
tendIbrake
1 2 50 t0
tend
Ieff
EE_App
Requirement: highest number of re-clamping requests at the highest re-clamping frequency
Parking brake actuator activation: borderline
ECU supply voltage: 9 V
Temperature of parking brake actuator: -40°C (TT)
#DH3.43 EE_App = 30 As
#DH3.44 Load cycles: 25
Adjusting the parking brake for wear
Requirements:
Parking brake actuator activation: borderline
ECU supply voltage: 9 V
Temperature of parking brake actuator: -40°C (TT)
The maximum energy input for a recalibration equals the sum of that for a locking operation and that for a releasing operation.
#DH3.45 EE_App = 44.3 As
#DH3.46 Cycles: 30
VDA Recommendation 305-100 Version May 2013 Page 54
Copyright: VDA
Parking brake pad replacement function
Requirement: worn brake pads are not exchanged for new parts
Parking brake actuator activation: borderline
ECU supply voltage: 9 V
Temperature of parking brake actuator: -40°C (TT)
#DH3.47 Irsh = 30 A
#DH3.48 Ibrake = -15 A
#DH3.49 Ieff_lock = 5 A
#DH3.50 tend = 30 s
#DH3.51 EE_App = 150 As
#DH3.52 Load cycles: 2 by the driver under borderline conditions
Dynamic braking with the parking brake actuators
Requirement: deceleration from 60 km/h to vehicle standstill with a minimum deceleration of 0.6 g on a wet road surface (coefficient of friction: 0.6)
Parking brake actuators activation: borderline
ECU supply voltage: 13.5 V
ECU temperature: <= 80°C
Temperature of parking brake actuator: 25°C
#DH3.53 Irsh = 25 A
#DH3.54 Ibrake = -12 A
#DH3.55 Ieff_lock = 12 A
#DH3.56 tend = 2.5 s
#DH3.57 EE_App = 30 As
#DH3.58 Load cycles: deceleration function is needed max. 5 times over lifetime
VDA Recommendation 305-100 Version May 2013 Page 55
Copyright: VDA
4 Functional safety This VDA recommendation describes a possible division of the EPB sub-functions between the OES supplying the wheel brake and the OES supplying the ESC. Functional safety must be guaranteed with respect to the overall vehicle system. Functional safety is viewed pursuant to the requirements of the ISO 26262 standard and in the context of this chapter relates solely to the electrical and/or electronic (E/E) components of the EPB. This chapter covers the hazard and risk assessment relevant to the EPB, and the derived allocation of ASIL levels to the elements of the functional architecture of the EPB.
4.1 Hazards and risks relevant to the EPB
The hazard and risk assessment is conducted pursuant to the requirements of the standard ISO 26262:2011 (cf. ISO 26262-3:2011, chapter “Hazard Analysis and Risk Assessment”). The following subchapters list all the hazards that are classified as ASIL A or higher. The ASIL classifications are maximum levels resulting from the system variances currently known.
4.1.1 Too high or unintended braking torque while vehicle is in motion (max. ASIL D)
Hazard Risk
1a) Incorrect actuation of EPB in the locking direction when v > vkrit. ASIL D
1b) Execution of the function ‘Dynamic deceleration’ intended by the driver leads to vehicle instability when v > vkrit.
ASIL B
1c) Execution of the function ‘Dynamic deceleration via the parking brake actuators intended by the driver’ leads to vehicle instability when v > vkrit.
ASIL A
1d) Incomplete release of the EPB with residual braking torque. ASIL B
Remarks on 1b) and 1c): the ‘Dynamic deceleration’ function is the vehicle deceleration required in accordance with ECE-R 13H over alternative paths independent of the service brake operating device. It is executed pursuant to the specifications via the hydraulic actuator of the ESC. Deceleration via the parking brake actuators is the back-up option here.
VDA Recommendation 305-100 Version May 2013 Page 56
Copyright: VDA
4.1.2 Unintended braking torque while vehicle is stationary (max. ASIL A)
Hazard Risk
2a) EPB cannot be released. ASIL A
Note re 2a): Safety-critical consequences result from situations in road traffic, e.g. at intersections or railroad crossings.
4.1.3 Too little braking torque while vehicle is stationary (max. ASIL C)
Hazard Risk
3a) Incorrect EPB actuation in the direction to release (driver absent, vehicle parked, ignition off).
ASIL C
3b) Too little holding force EPB developed (driver absent). ASIL B
3c) Incorrect release of the EPB (driver absent, vehicle held, ignition on).
ASIL B
3d) Required EPB function ‘proactive re-clamping’ is either not executed, or is executed insufficiently (driver absent, vehicle parked).
ASIL A
3e) Required EPB function ‘hydraulic support’ is either not executed, or is executed insufficiently (driver absent, vehicle held)
ASIL A
4.1.4 Incorrect driver information (max. ASIL B)
Hazard Risk
4a) EPB-specific driver information on the EPB function status incorrectly signals EPB status ‘locked’ (EPB opened)
ASIL B
4.2 ASIL classification of relevant signals and sub-functions
The signals and sub-functions that are relevant in accordance with this interface specification have varying influences on the hazards listed in the previous chapter. The highest derived ASIL levels for each case are shown in Figures 4.2B1 and 4.2B2. The scope of consideration here covers the PBC function with its input and output interfaces, plus the immediately adjacent function blocks. Sub-functions in the host that come within the functional scope of the EPB, and in which the PBC module is not involved, have therefore not been assessed (e.g. driver input via an EPB button, additional securing of standstill by other measures, etc.). Safety requirements for the PBC interface signals are given in ANNEX 3.2.A1 (Interface details, functional view). The hazards with the highest risk levels are included. Therefore no explicit requirements have been defined for some signal values of discrete interface signals (e.g. enums). No safety requirements have been specified for signals classified as QM. Safety requirements for the function blocks are not given explicitly. They are derived from the requirements for the output signals generated from them. The analyses given here are to be seen as a recommendation.
VDA Recommendation 305-100 Version May 2013 Page 57
Copyright: VDA
Completeness and correctness must be guaranteed through the project-specific safety analyses.
PbcOutMotorCommand
(L/R)
PBC(EPB actuation control)
EPB HW driver controlEPB mech.
actuator
HMI
brake
lights
ESC control
& actuator
actual motorvoltage & current (L/R)
PbcOutHpsRequest
PbcOutHpsPressure
PbcInHpsAcknowledge
ESC driverinfo message
SSM CDP request& target deceleration
SSM brake light target state
ESC brake light target state
EPB driver input button state
powertrain statepowertrain& gear info
external function ext. request
PbcInRollerbench
Active
PbcOutActuator
State
(L/R)
PbcInApplyRelease
Request
SSM(EPB function control)
longitudinal
acceleration infoPbcInLongAcceleration
ambient temp. info PbcInVehicleAmbientTemperature
host
safety
barrier
PbcInHpsAvailability
wheel speed
info
PbcInWheelSpeed (FL/FR/RL/RR)
PbcInWheelPulse (FL/FR/RL/RR)
PbcEnableLine(Lock/Release)
environmental data
system wide services
persistent
data storage
fault
management
system mode
management
diagnosis
development
message
service brake
state
PbcInMasterCylinderPressure
PbcInWheelPressure (FL/FR/RL/RR)
PbcInWheelPressureReliability (FL/FR/RL/RR)
D
B(D)B(D) QM
B
B
QM
A
A
QM
AD
B
B(D)
PbcInMotorDriver
State
(L/R)
A
PbcInHostAvailability
(L/R)
A
PbcInMotorDriver
Supply
Voltage
B
PbcInMotorVoltage
(L/R)
B
PbcInMotorCurrent
(L/R)
B
DD
B
A
QM
A
B
QM
B(D)
B(D)
B
B
A
QM
A
PbcInPowerSupply
State
B
Figure 4.2B1: Overview of EPB functional architecture with relevant ASIL levels (maximum over all hazards, hazard 1a) pursuant to ASIL B(D) and ASIL B(D) decomposed).
persistent
data storage
PBC(EPB actuation control)
diagnosis
PbcInDiagRequest
PbcOutDiagRequestAcknowledge
PbcOutPbcSwVersion
PbcOutDiagRequestStatus
PbcOutDiagBrakeTemperature (L/R)
PbcOutDiagActuationCounter (L/R)
PbcOutDiagAchievedClampForce (L/R)
PbcInDiagOperationMode
PbcInDataStorageRead
PbcOutDataStorageWrite
PbcInDataStorageValid (1..3)
system mode
management PbcOutEcuPowerLatchRequest
PbcInPbcSleepTime
PbcOutFaultStatus (1..n)
PbcInFaultRecoveryRequest (1..n)fault
management
PbcInVariantItem
PbcInUnexpectedPow erdow n
development message PbcOutDevelopmentMessage (1..n)
B
B
QM
A
A
A
B(D)
QM
QM
QM
QM
QM
A
B(D)
B
QM
A
B
B
B(D)
QMQM
B
A
PbcInPbcHostVersionQM
Figure 4.2B2: Overview of EPB functional architecture with ASIL levels (maximum over all hazards, hazard 1a) pursuant to ASIL B(D) and ASIL B(D) decomposed): details of the PBC-relevant service functionalities provided
system-wide by ESC host system.
VDA Recommendation 305-100 Version May 2013 Page 58
Copyright: VDA
The EPB safety requirements implemented in the PBC module must not be greater than ASIL B, taking the interchangeability safety concept into account. To ensure this, the method of ASIL decomposition is applied for all hazards classified as ASIL C or ASIL D (cf. ISO 26262-9:2011). Hazard 1a) “Incorrect actuation of the EPB in the locking direction when v > vkrit. (ASIL D)” can occur when during motion the signals PbcEnableLineLock (leaving the ‘Host Safety Barrier’ function block) and PbcOutMotorCommand (leaving the ‘PBC’ function block) are simultaneously switched incorrectly, resulting in an unauthorized locking operation of the EPB actuator. Decomposition alternatives that assign a (decomposed) ASIL C or ASIL D to the PBC, are explicitly not in conformity with this VDA recommendation. Hazard 3a) “Incorrect actuation of the EPB in the direction to release (driver absent, vehicle parked, ignition off). (ASIL C)” can occur when in the parked state the signals PbcEnableLineRelease (leaving the ‘Host Safety Barrier’ function block) and PbcOutMotorCommand (leaving the ‘PBC’ function block) are simultaneously switched incorrectly, resulting in an unauthorized releasing operation of the EPB brake actuator. Decomposition alternatives that assign a (decomposed) ASIL C to the PBC are explicitly not in conformity with this VDA recommendation.
4.3 PBC software integration
In the interchangeability concept, the functions of the PBC function block, which are integrated into the ESC host system, are implemented in full in software. As a rule the ESC contains various additional functions with risk classifications up to a maximum of ASIL D (e.g. controllers for the lateral vehicle dynamics). Software integration of the PBC functions into the ESC host system must take the requirements of ISO 26262-6:2011 “Product Development at the Software Level” into consideration. In particular, sufficient independence of the PBC function from the other ESC functions must be ensured by means of appropriate measures (ISO 26262-6:2011, ‘criteria for coexistence’; provides evidence that the software has no retroactive effects).
4.4 System integration
Integration of the overall system into the vehicle is the responsibility of the vehicle manufacturer (pursuant to ISO 26262).
VDA Recommendation 305-100 Version May 2013 Page 59
Copyright: VDA
5 Proof of safety in interchangeability
5.1 FMEA – responsibilities, interface coordination
5.1.1 General conditions
The following general conditions apply to the parts of the system FMEA compiled by each party in EPB interchangeability:
The OES supplying the host and the OES supplying the brake assembly each draw up their own system FMEA pursuant to the functional responsibilities in EPB interchangeability and report directly to the OEM on the part of the EPB for which they are responsible.
It is recommended that the S-FMEAs (host and brake assembly) are compiled in accordance with the VDA recommendation.
Development by each OES covers only monitorings (diagnoses and detection measures in customer operation) the hardware it supplies and its own functional part of the EPB system.
The ranking scales for the FMEA, S (severity of the consequences), O (probability of occurrence of the cause of error) and D (detection of the cause, of the error itself or of the consequences), are to be agreed between OEM and partners at the beginning of the FMEA work.
S values from the vehicle FMEA are forwarded by the OEM to the interchangeability partners for each highest-rated fault in the system FMEA for the host and the system FMEA for the brake assembly, and/or agreed with the OES.
Only the OEM, and not the interchangeability partners, has the right to inspect the individual S-FMEAs.
5.1.2 FMEA structure
Each OES may determine the structure of its FMEA. It is recommended that the general principles for conducting an FMEA are applied in accordance with VDA Volume 4, ring-binder chapter 3. Special requirements of the OEM are to be considered, as appropriate. The interface between the host system FMEA and the brake-assembly system FMEA must be selected such that the interface contents are compatible. The interface between the host system FMEA and the brake-assembly system FMEA can generally be derived from the following:
a physical view (see Figure 5.1.2.B1) and
an abstract view (see Figure 5.1.2.B2). The basic architecture is described in detail in the chapters “2 System description” (see also Figure 2.B1) and “3 Basic functional architecture”. Figure 5.1.2.B1 shows the physical boundary surrounding the brake assembly and the associated responsibility at the component level.
VDA Recommendation 305-100 Version May 2013 Page 60
Copyright: VDA
Figure 5.1.2.B1: Physical boundary diagram for brake assembly
The abstract view in Figure 5.1.2.B2 shows the structure of the FMEA interface relating to exchange of signals between the host and the brake assembly. (The diagram is schematic and does not include all the signals described in chapter 3.)
ESC ECU assembly ESC assembly Brake assembly
Figure 5.1.2.B2: Abstract boundary diagram for suppliers’ parts
VDA Recommendation 305-100 Version May 2013 Page 61
Copyright: VDA
5.1.3 Handling information at the interface between the FMEAs
Data from two different directions are to be made available in the interface between the host system FMEA and the brake-assembly system FMEA. The following data are to be transmitted by the system FMEA receiving the interface signals:
S rankings
Omax_soll
Example of a cause of error on the receiver side: “PbcInMotorCurrentLeft - too high”
S = 10 (severity – incorrect “locked” parking brake state)
Omax_soll = 1 Note 1: The values entered here are merely examples and should not be regarded as real values. Note 2: Owing to the varying FMEA evaluation procedures, Omax_soll can have other
severities:
if the risk priority number (RPN) is used, Omax_soll takes into account the RPN limit set in the project and the detection measures on the receiver side,
if the risk matrix is used, Omax_soll takes into account the requirements relating to the product of B x Amax_soll.
The following data are to be transmitted by the system FMEA sending the interface signals:
description of the consequences of the highest-ranking faults,
confirmation of the requested Omax_soll values, in each case updated in line with the OEM’s approvals.
Expansion of the above example on the transmitter side:
consequences of the highest-ranking fault “PbcInMotorCurrentLeft - too high”,
Omax_soll = 1 confirmed! The information should be exchanged via an interface worksheet, e.g. as an Excel table. The Omax_soll values for the probability of occurrence for the respective other side are confirmed at the interface between the host system FMEA and brake-assembly system FMEA. The actual values are not disclosed. If the interchangeability partners cannot reach an agreement leading to a sufficiently small RPN or an acceptable B x A value, the OEM is obliged to cooperate on working on a solution.
VDA Recommendation 305-100 Version May 2013 Page 62
Copyright: VDA
Note: In the system FMEA of the signal receiver, the Omax_soll value is a forecast
value for the probability that the cause of error described will occur during customer operation. If the risk priority number is used, this value should be calculated separately from the system FMEA of the signal transmitter, taking O x D into account. The value for O from the system FMEA of the signal transmitter usually corresponds to the O value for the interface worksheet only if D = 10. Example: if severity S = 10 and there are no detection measures at the signal receiver (D = 10), then Omax_soll = 1 is deemed confirmed (and thus RPNEmpfänger = 100) if, for instance, the real occurrence probability of the relevant causes of error are at the signal transmitter O ≤ 2 and the relevant detection probabilities at the signal transmitter D ≤ 6. If the risk matrix from the FMEA values S and O is used, at the beginning of the project the OEM and the signal transmitter have to agree whether for O only the value of the occurrence probability is to be used, with/without taking into account the probability of detection by the signal transmitter.
5.2 PMHF according to ISO 26262
5.2.1 General conditions
The following general conditions apply to proving PMHF according to ISO 26262:
Allocation of safety goals to the parts supplied by each party is described in chapter 4, after decomposition there of the functions with a failure > ASIL B, which can lead to unintended activation of the EPB actuators.
Each party monitors only the hardware it supplies for the EPB system and assesses only its own measures for achieving the safety goals for diagnostic coverage according to ISO 26262.
Only the OEM, and not the interchangeability partner, has the right to inspect the individual evaluations for PMHF.
5.2.2 Evaluation
Proof of PMHF according to ISO26262-5 chapter 9.4.2 (Evaluation of Probabilistic Metric for random Hardware Failures (PMHF)) requires evidence of compliance with the limit values for the single point failure metric and for the multiple point failure metric. To this end, the following parameters should be observed:
Single point failure metric
Mean rate of single point faults SPF [FIT]
Single Point Fault Metrics SPFM [%]
Residual Faults RF
Multiple point failure metric
VDA Recommendation 305-100 Version May 2013 Page 63
Copyright: VDA
Latent Faults MPF,L [FIT]
Latent Fault Metrics LFM [%]
Diagnostic Coverage
Proportion of safe faults
Here, as for the FMEA, the faults refer to the fault causes in the interface between the FMEA of the host OES and the FMEA of the brake-assembly OES. It is recommended to manage this fault metric based on the FMEA created in an FMEDA, as it is then possible to refer to existing interfaces. Here, too, a predetermination of the failure rates out of the failure causes has to be done, which are then confirmed at the cause levels in the positive case. To protect intellectual property, explicit failure rates should not have to be passed to the respective interchangeability partner. Confirmation is only required of achievement of the necessary diagnostic coverage corresponding to the ASIL classification. Disclosure of the measures implemented for this purpose to the interchangeability partner is not envisaged.
5.2.3 Division of failure rates between various causes
If the highest-ranking fault has several causes, it is only possible to determine target failure rates after the permitted total failure rate has been broken down into the individual causes. In this case the two interchangeability partners should find a joint solution. If in individual cases the interchangeability partners are unable to agree, the OEM is obliged to cooperate on working on a solution in these individual cases.
5.2.4 Evaluation procedure
Figure 5.2.2.B1 shows the complete process for providing evidence for PMHF according to ISO 26262. Depending on the fault, either the host examines the highest-ranking fault and the brake assembly supplies the cause, or for a different fault the brake assembly examines the highest-ranking fault and the host supplies the cause for the special interface work in the interchangeability.
Figure 5.2.4.B1: Process for proving PMHF according to ISO 26262
VDA Recommendation 305-100 Version May 2013 Page 64
Copyright: VDA
6 Test concept
6.1 Test strategy
This chapter describes an option, with the EPB control unit integrated into the ESC, for testing functions and hardware independently of the supplier, so that all faults anywhere in the system continue to be detected and remedied in good time before the overall system is delivered to the OEM. The scopes of the relevant tests and approvals from the two OES are described below. Since in interchangeability the EPB system can comprise parts from two OES, approval can only be given by both OES (of the brake and ESC assemblies). This chapter describes the respective scopes of OES approval. Within interchangeability, each OES is responsible only for approving the part that it supplies. It is however ensured that before final approval the entire system, with its final software and hardware, is tested to check that it is both robust and functional. The scopes of the interchangeability-specific tests relate to the integration of software between two different OES. The requirements placed by the brake assembly on the host hardware (see chap. 3.3) should be approved by the ESC-assembly OES and regarded as a validation of the requirement by the brake-assembly OES. Within the interchangeability concept the test stages must be divided between the two OES for systematic verification and validation. Figure 6.1.B1 shows the development model (“V model”) for development and approval. This forms the basis for developing and approving the defined scopes of supply for the brake assembly and the ESC assembly, and is applied by both OES to their own scopes of supply.
VDA Recommendation 305-100 Version May 2013 Page 65
Copyright: VDA
Figure 6.1.B1: Validation and verification in the V model
6.1.1 Verification
It must be ensured that the functions required for the various development stages are implemented in line with the specifications agreed with the OEM and that faults in this implementation are identified as early as possible. This goal is achieved through an expedient, unequivocal division of the test tasks and responsibilities between the two OES, taking the common standards and quality goals into account.
VDA Recommendation 305-100 Version May 2013 Page 66
Copyright: VDA
6.1.2 Validation
It must be ensured that the specified requirements are described sufficiently precisely and completely by the relevant function so they are logical for the user. Validation is carried out for the parts supplied by each OES on the basis of the respective assembly requirements including the agreed interchangeability interfaces.
6.1.3 Test stages
Normally test stages are formed that are derived from the software development process according to the V model (see Figure 6.1.B1). The interchangeability concept does not determine distribution between the OES of the hardware-relevant test stages that therefore remain the independent responsibility of the respective OES. In the interchangeability concept the software-relevant test stages should be carried out for the respective scope of supply and are the responsibility the respective OES.
6.1.4 General explanations and determination of the test strategy
Depending on the development stage and maturity level of the project, the test activities are to be agreed by the relevant OES with the OEM and carried out by the OES. The ESC-assembly OES and brake-assembly OES are responsible for creating the test concepts on the component level for the parts they supply (see RASI ID-86 and 112).
6.1.5 Requirements for the components and system tests
As the integrated parking brake comprises the brake assembly and the EPB-relevant part of the ESC assembly (see chapter 2), there are dependencies between the ESC system and the EPB system. To enable independent development (incl. testing and approval), the respective components should be exchanged between the ESC-assembly OES and the brake-assembly OES at the agreed maturity level. The following components are required: From the OEM:
Sensor specification of sensors required for sequence control within the stimulation matrix (e.g. parking brake control unit, wheel speed sensors, longitudinal acceleration sensors) for the OES to develop the sensor simulation.
Communication matrix for residual bus simulation by the OES. (Recommendation: transfer in a common format such as dbc, Autosar XML or Fibex)
VDA Recommendation 305-100 Version May 2013 Page 67
Copyright: VDA
From the ESC-assembly OES:
ESC hardware (depending on the development status, e.g. prototypes of ESC hardware), (see RASI ID-51 and 54),
Host library (protected version, basic functions, etc.) for the brake-assembly OES o integrate the PBC software into the HOST,
Toolchain of the ESC assembly for the brake-assembly OES to integrate the
PBC software into the HOST,
Provision of the communication matrix for residual bus simulation to the brake-assembly OES in the format specified by the OEM when the commission was awarded, for each software development status.
From the brake-assembly OES:
Parking brake actuators or, alternatively, a load simulation for development purposes (see RASI ID-58, 61),
PBC software library including PBC-ParamFile.
VDA Recommendation 305-100 Version May 2013 Page 68
Copyright: VDA
6.1.6 Test activities
In interchangeability the following testing tasks arise:
Test for the respective scope of supply,
Test of the interface between the suppliers’ parts. The tests for the respective scope of supply are executed by the relevant OES. The tests of the interface are to be executed by both OES from their respective perspectives.
System No Level Test StepESC-assy
supplier
Brake-
assy
supplier
Environment System No Level Test StepESC-assy
supplier
Brake-
assy
supplier
Environment
1.1 ENG.6 SW Component Test PBC R, A SCT 2.1 ENG.6 SW Component Test Host R, A SCT
1.2 ENG.6HW Component Test PBC /
Actuator-(brake) tests PBCR, A Actuator-Bench 2.2 ENG.6
HW Component Test Host (HW
driver)R, A HW-Bench
1.3 ENG.7 SW Integration Test PBC R, A SCT 2.3 ENG.7 SW Integration Test Host R, A SCT
2.4 ENG.7
SW-Integration Test (PBC/Host SW
Interface)
(with reference PBC SW)
R, A S, I SCT, SiL
1.4 ENG.7HW Integration Test PBC /
Actuator-(brake) tests PBCR, A Actuator-Bench 2.5 ENG.7 HW Integration Test Host (HW driver) R, A HW-Bench
1.5 ENG.8SW Test PBC
(with reference PBC)R, A SiL 2.6 ENG.8
SW Test Host
(with reference PBC SW in target
integrated SW (PBC,Host,ESC) on
reference HW)
R, A S, I HiL
1.6 ENG.9
System IntegrationTest
reference PBC SW + Brake +
Actuator
(on Target Brake- and ESC-assy)
I,S R, A HiL, VT, SET 2.7 ENG.9
System Integration Test
Host HW+Host SW
(on Target Brake- and ESC-assy)
R, A S,I HiL, VT
1.7 ENG.10
System Test
PBC SW + Brake + Actuator
(on Target Brake- and ESC-assy)
I,S R, A HiL, VT 2.8 ENG.10
System Test
Host HW+Host SW
(on Target Brake- and ESC-assy)
R, A S, I HiL, VT
Legend:
R = Responsible for execution
A = Accountable (delegate and approve)
S = Support
I = Informed
Reference-SW = Host- or PBC-SW that meets the current interface specification
Reference-ECU = ECU that runs the Reference-SW
Reference-HW = HW that runs with Reference-ECU
SCT = SW Component Test
SIL = SW in the loop test environment
HIL = HW in the loop test environment
VT = Vehicle test
SET = System Endurance Test
Reference = fulfills required maturity level for EPB system
Target = fulfills required maturity level for both, ESC and EPB system
Brake assy
ESC-assy +
integration of
PBC
PBC-Host Integration Strategy
6.1.6.1 Test activities of the brake-assembly OES
The PBC OES bears sole responsibility for allocation of the test activities to the brake assembly in accordance with Table 6.2.6.T1 (see “Brake assy”). The brake-assembly OES supplies an approval recommendation to the ESC-assembly OES for integrating the PBC into the host (see RASI ID-22).
1.1 Software component test PBC (ENG.6) Software component tests are the responsibility of the brake-assembly OES. They are executed autonomously by the brake-assembly OES.
Table 6.1.6.T1: Distribution of the test activities between ZSB-Bremse OES and ZSB-ESC OES
VDA Recommendation 305-100 Version May 2013 Page 69
Copyright: VDA
1.2 Hardware component test of the parking brake actuators (ENG.6) Hardware component tests are the responsibility of the brake-assembly OES. They are executed autonomously by the brake-assembly OES.
1.3 Software integration test (integration of the PBC modules) (ENG.7) The integration tests of the PBC software modules are the responsibility of the brake-assembly OES. They are executed autonomously by the brake-assembly OES.
1.4 Hardware integration test of brake assembly (ENG.7): The hardware integration tests are the responsibility of the brake-assembly OES. They are executed autonomously by the brake-assembly OES.
1.5 Software test with reference PBC (ENG.8): Based on the reference PBC, the brake-assembly OES autonomously tests the software functions of its scope of supply.
1.6 System integration tests (ENG.9) Based on the target brake assembly and the target ESC assembly, the brake-assembly OES autonomously tests the brake-assembly function within the relevant parts of the EPB system architecture (see chap. 3 plus brake-assembly architecture). This is done by stimulating signals at the ECU interface (black box) and observing the interchangeability interface (e.g. via XCP). The ESC-assembly OES must enable the brake-assembly OES to do this (stimulation matrix with host functionalities). The measuring equipment needed for observing the interface are to be provided by the ESC-assembly OES. The ESC-assembly OES should be notified of any anomalies in the scope of supply of the ESC assembly.
1.7 System test (ENG.10): Based on the technology from 1.6, validation is performed on the part of the EPB system that is relevant to the brake-assembly OES. The ESC-assembly OES must enable the brake-assembly OES to do this (stimulation matrix with host functionalities). The measuring equipment needed for observing the interface are to be provided by the ESC-assembly OES. The ESC-assembly OES should be notified of any anomalies in the scope of supply of the ESC assembly.
6.1.6.2 Test activities of the ESC OES
The test activities listed refer to the above table. The ESC-assembly OES bears sole responsibility for the test activities given below.
2.1 Host software component test (ENG.6): Test activities for the ESC assembly are analogous to Point 1.1. Software component tests are the responsibility of the ESC-assembly OES. They are executed autonomously by the ESC-assembly OES.
VDA Recommendation 305-100 Version May 2013 Page 70
Copyright: VDA
2.2 EPB and common hardware component test (ENG.6): Hardware component tests of the EPB and common hardware are the responsibility of the ESC-assembly OES. They are executed autonomously by the ESC-assembly OES. The tests described here relate to the HOST hardware requirements, which are determined by the interchangeability.
2.3 Software integration test of host software not including PBC (ENG.7): Test activities for the host part are analogous to Point 1.3. The integration tests of the host software modules are the responsibility of the ESC-assembly OES. They are executed autonomously by the ESC-assembly OES.
2.4 Software integration test of host software including PBC (ENG.7): The tests of the integration of the reference PBC into the host software component focusing on the interface and the interplay of the individual software components (PBC, host) are the responsibility of the ESC-assembly OES. They are executed autonomously by the ESC-assembly OES. The brake-assembly OES should provide the reference PBC. The brake-assembly OES should be notified of any anomalies in the scope of supply of the PBC.
2.5 Hardware integration test of host (ENG.7):
Hardware integration tests (for the ESC assembly) are the responsibility of the ESC-assembly OES. They are executed autonomously by the ESC-assembly OES. This level includes testing the robustness of the host hardware to electrical environmental influences.
2.6 Software test of host (ENG.8): Based on the integration of the reference PBC into the reference host software, the ESC-assembly OES autonomously tests the software functions for which it is responsible. Because of the host software parts that are close to hardware, these tests must be run in conjunction with which reference hardware. The brake-assembly OES should provide the reference PBC. The brake-assembly OES should be notified of any anomalies in the scope of supply of the PBC.
2.7 System integration tests (ENG.9): Based on the reference brake assembly and the target ESC assembly, the ESC-assembly OES autonomously tests the system performance of the host functions. This is done by stimulating signals at the ECU interface (black box) and observing the PbcOut…interchangeability interface. The brake-assembly OES must enable the ESC-assembly OES to do this for the functions that can be triggered only by the brake assembly (re-clamping and HPS functions) (stimulation matrix with PBC functionalities). The brake-assembly OES should provide the reference brake assembly. The brake-assembly OES should be notified of any anomalies in the scope of supply of the brake assembly.
VDA Recommendation 305-100 Version May 2013 Page 71
Copyright: VDA
2.8 System test (ENG.10): Based on the technology from 2.7, validation is performed by the ESC-assembly OES on the part of the ESC assembly that is relevant to the EPB system. The brake-assembly OES should provide the reference brake assembly. The brake-assembly OES should be notified of any anomalies in the scope of supply of the brake assembly.
6.1.6.3 Approval recommendation for the entire scope of supply
The approval recommendation for the entire scope of supply consisting of the brake assembly and the ESC assembly cannot be issued by one OES alone. In the interchangeability concept, a recommendation to approve the entire scope of supply is communicated by the ESC-assembly OES to the OEM, based on the approval recommendations of the ESC-assembly OES for the ESC assembly and of the brake-assembly OES for the brake assembly. Approval of the entire EPB system is issued by the OEM (see RASI ID-25). Here compliance is required with the maturity levels of the two OES parts, including approval in accordance with the development stages of the OEM. In this connection, each OES has to coordinate the level of maturity of its own scope of supply with the OEM, in line with the approval stages (see RASI ID-29).
6.1.6.4 Stimulation matrix
For executing the tests of the OES part within the overall EPB system, information on the “input to output behavior” has to be provided by the respective OES. Each OES has to draw up a stimulation matrix for its scope of supply. The purpose of this stimulation matrix is not a performance test of the other scope of supply, but a robust triggering of the PBC interface signals via inputs to the ECU (black box). The interface signals for which a stimulation matrix is required are marked in Annex 3.2.A1 with a Y in the column “Relevant to stimulation matrix”. For the signals concerned, for each value a “stimulation” is necessary based on ECU input values. The simplest and most robust sequence for the stimulation matrix should be selected in each case. The sequences and a HOST that can run as defined by the sequences should be supplied to the brake-assembly OES by the ESC-assembly OES at the beginning of each development step, in line with the development schedule agreed at the beginning of the project.
VDA Recommendation 305-100 Version May 2013 Page 72
Copyright: VDA
Specimen stimulation matrix:
PBC interface Value ECU interface required
Sequence
PbcInActuationRequest ParkApply Parking brake control unit,
Wheel speed
Ignition
Ignition off,
Wheel speed (FL-RR) = 0
Parking brake control unit = Apply
7 Handling of faulty parts Goal: clear allocation of activities when a complaint/defect occurs
In accordance with the division of the EPB components in chapter 2, if a defect/fault occurs all three parties may be involved: first the OEM and second the two tier-1 OES of the EPB system. Furthermore, a subdivision is made into two time periods: that of the common development activities and that of series supply and/or the longer-lasting field observations. In general, the two OES (for the ESC and brake assemblies) are responsible for their respective scopes of supply. Faulty parts/disassembly may be carried out only at the respective OES (ESC-assembly or brake-assembly OES), and/or jointly at the OEM. All parties involved must be able to read the faults out from the ECU. The special features of the interchangeability architecture are described below. Owing to the system architecture, the diagnostic functionality, including the failure word memory, is part of the ESC assembly. Within the interface architecture responsibilities have been separated in accordance with the scopes of supply. This means that the ESC assembly monitors its components and the brake assembly also monitors its actuated components. The necessary signals are exchanged between the brake assembly and the ESC assembly (see signal descriptions in 3.3). In line with this separation, the failure words are allocated to the corresponding failure patterns. This means that when the failure words are read out it becomes clear which component (ESC assembly or brake assembly) generated them.
VDA Recommendation 305-100 Version May 2013 Page 73
Copyright: VDA
Period of joint development
During the development phase, defects may be detected in the overall system or in component products at any of the three parties involved. In the development phase the ESC-assembly OES and the brake-assembly OES draw up a fault memory containing unequivocal allocation of responsibilities:
1. Defect is detected at OEM
If the detected defect can be clearly ascribed to an OES, this OES is informed by the OEM (further regulations can be found in the respective development/warranty agreement). If no allocation is possible, or the defect is relevant to interchangeability, the OEM informs both OES. In such cases the ESC-assembly OES takes over the continuing problem management until the problem has been resolved.
2. Defect is detected at brake-assembly OES
If a defect is detected in the scope of supply of the ESC-assembly OES, the brake-assembly OES informs the ESC-assembly OES and the OEM. The ESC-assembly OES then takes over the continuing problem management until the problem has been resolved.
3. Defect is detected at ESC-assembly OES
If a defect is detected in the scope of supply of the brake-assembly OES, the ESC-assembly OES informs the brake-assembly OES and the OEM. The brake-assembly OES then takes over the continuing problem management until the problem has been resolved.
Series supply/field observation During series supply a distinction is made between the period before the vehicle is delivered to the customer and the period when the vehicle is operated by the customer. The OEM is responsible for detecting a defect from these two areas and allocating it to the corresponding OES in accordance with the present failure. A special situation occurs if, owing to the failure, allocation is initially not possible to either of the two OES. In this case the ESC-assembly OES is responsible for problem management until the problem can be clearly allocated.
VDA Recommendation 305-100 Version May 2013 Page 74
Copyright: VDA
8 Cooperation matrix (RASI matrix)
8.1 Objective
The RASI matrix describes one possible division of the duties and tasks of the companies involved in the project, i.e. the manufacturer of the ESC assembly, the manufacturer of the brake assembly and the OEM as client. If necessary, this division can be adapted for specific projects between the parties involved.
8.2 Structure of the RASI matrix
The topics are grouped into five process areas:
- General - Project management - Problem management - Prototype handling - Overall system
Each of these areas has several subsections. In addition to descriptions of the
subsections, the matrix also contains the expected results, and sets out who is responsible (R) for carrying the task out, who is accountable (A), i.e. delegates and approves, who provides support (S), and who provides information (I).
8.3 RASI matrix
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
General
1 Correct reading in, evaluation and monitoring of the driver’s request
via EPB control unit
Software signal X X
2 Situation-appropriate
determination of parking brake actuator target state
Software signal X X
3 Property-appropriate
transmission of actuation request (holding/releasing) to PBC
SW-Signal X X
4 Generation of control signal (lock and release command) for power
electronics based on the PBC component functions.
SW-Signal X X
VDA Recommendation 305-100 Version May 2013 Page 75
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
5 Correct ECU-internal
transmission and release of power stages based on control signal from PBC and
characteristic-appropriate activation of brake-assembly parking brake actuator (ECU
output)
Software signal X X
6 Transmission of current to brake-assembly parking brake actuator
Wiring harness X X X X
7 Developing/reducing clamping force at brake assembly
- X X
8 Reading in the necessary measured values of the actuation path for the parking brake
actuator and transmission to PBC
Software signal X X
9 Recognition of a fault in the parking brake actuator based on
the measured values transmitted to the PBC
Software signal X X
10 Recognition of a fault in the electrical leads
Software signal X X
11 Creating and implementing
diagnostic concept incl. PBC fault status messages (pursuant to diagnostic specifications)
For scope of brake assembly1
For scope of ESC assembly2
Specification for diagnostic
concept
X X2
X X1
12 Compilation of fault memory
concept for clear allocation of responsibilities -> for every entry there must be a person
responsible
For scope of brake assembly1
For scope of ESC assembly2
Design document, DTC list
of persons responsible
X X2
X X1
13 Implementation of fault memory
for ESC assembly pursuant to clear concept
Software X X X
14 Implementation of fault memory
for brake assembly pursuant to clear concept
Software X X X
15 Display of system states and fault states to driver
Specification for diagnostic concept
X X X
16 Standstill management incl. EPB Software and system
approval
X X X X X
VDA Recommendation 305-100 Version May 2013 Page 76
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
17 Standstill management, incl. EPB
on vehicle level (series approval)
Series approval X X X X
18 System responsibility for ESC assembly pursuant to
specifications
X X X
19 System responsibility for EPB (brake assembly) pursuant to
specifications
- X X X
20 System integration responsibility
for software component PBC
- X X X X
21 Detailed description of signal
interface for the software
component PBC
Design document X X X
22 Approval of brake-assembly scopes for each supply stage
Approval document approval recommendation
X X X X
23 Approval of ESC-assembly
scopes for each supply stage
Approval document,
approval recommendation
X X X X
25 Approval of entire system: ESC assembly + brake assembly
Approval document X X X X
Project management
26 Commissioning of ESC-assembly
by OES
Written nomination by
Purchasing
X X X X
27 Commissioning of brake-assembly OES
Written nomination by Purchasing
X X X X
29 Creation of implementation planning for EPB
Implementation plan X X X X
30 Review of implementation planning for EPB
Agreed implementation plan
X X X X
31 Implementation pursuant to
implementation planning for EPB
Software version supplied,
incl. documentation
X X X X
32 Evidence of implementation progress pursuant to
implementation planning for EPB
Test report X X X X
33 Development discussions e.g. Simultaneous Engineering (SE) teams on ESC assembly incl. PBC
topics (governed by agenda)
Agenda and minutes X X X X
VDA Recommendation 305-100 Version May 2013 Page 77
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
34 Development discussions e.g.
Simultaneous Engineering (SE) teams on brake assembly
Agenda and minutes X X X
35 Risk management for scope of delivery of ESC assembly incl.
integration of PBC
Risk list X X X
36 Timely notification of OEM (poss. escalation) if projected schedule
for scope of ESC assembly incl. integration of PBC appears jeopardized
- X X X
37 Risk management for scope of brake assembly
Risk list X X X
38 Timely notification of OEM (poss. escalation) if projected schedule for scope of brake assembly
appears jeopardized
- X X X
Problem management
39 Allocation or assignment,
pursuant to agreement, of problems during development and after SOP (fault found by
OEM): - ESC-assembly OES: scope of ESC assembly incl. integration of
PBC - brake-assembly OES: scope of brake assembly
Fault list X X
40 Carrying out problem management as far as problem
resolution for development faults that cannot be clearly allocated and after SOP
Fault list X X X X
41 Carrying out problem management as far as problem
resolution in accordance with allocation of scope of ESC assembly incl. integration of PBC
Fault list X X X X
42 Carrying out problem management as far as problem resolution in accordance with
allocation of scope of brake assembly
Fault list X X X X
43 Carrying out problem management as far as problem resolution
(fault found in the scope of supply of the ESC-assembly
Fault list X X X X
VDA Recommendation 305-100 Version May 2013 Page 78
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
OES).
44 Problem management as far as
problem resolution (fault found in the scope of supply of the brake-assembly
OES).
Fault list X X X X
45 Problem management relating to
PBC
Analysis result and
problem resolution
X X X X
46 Analysis of field returns with
ESC-assembly fault memory pursuant to FM assignment
Analysis result X X X
47 Analysis of field returns with
brake-assembly fault memory pursuant to FM assignment
Analysis result X X X
48 Analysis of field returns with the complaint: parking brake actuator
assembly
Analysis result X X X X
49 Analysis of field returns ESC assembly incl. PBC integration
without stored failure
Analysis result X X X X
50 Cover of warranty/guarantee
costs pursuant to quality process in relation to fault memory assignment (with simultaneously
present FM entries with ESC-assembly and brake-assembly assignment, that is the person
responsible for ESC-assembly solution).
- X X X X
Prototype handling
51 Provision of ESC-assembly systems incl. stimulation matrix, conforming with development
stage, appropriate to schedule and characteristics, for purposes of development and approval, to
brake-assembly OES, with the following scenarios (ID 52 to 54)
ESC-assembly system X X X X
52 Provision of hardware relevant to brake assembly from start of
development
ESC-assembly system X X X X
53 Provision of target system, from late B-sample stage onward
ESC-assembly system X X X X
VDA Recommendation 305-100 Version May 2013 Page 79
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
54 For exclusive use of future ESC
systems: provision of prototype control devices with target processor
from start of development for representation and integration of PBC as basis for brake-assembly
approval and provision of target system, from late B-sample stage onward.
ESC-assembly system X X X X
55 Agreement on requirements for prototype control devices (based on these control devices, the
brake-assembly OES must be able to issue approval for its scope of supply)
X X X X
56 Providing OEM with ESC-assembly target system
conforming with development stage, for development purposes from start of development
ESC-assembly system X X X
58 Providing ESC-assembly OES with brake assembly incl.
stimulation matrix conforming with development stage, for development purposes
EPB parking brake actuators
X X X
59 Providing OEM with EPB parking brake actuators conforming with development stage, for
development purposes
EPB parking brake actuators
X X X
61 Alternative: providing ESC-assembly OES
with load simulation conforming with development stage
Simulation data X X X X
Overall system
62 Provision of ESC-assembly specifications
Specifications e.g. in Doors eXchange format and PDF
print-out
X X X X
63 Review of ESC-assembly specifications not incl. PBC
scope of supply
Annotated specifications e.g. in Doors eXchange
format
X X X X
64 Review of only those ESC-
assembly specifications applicable PBC scope of supply
Annotated specifications
e.g. in Doors eXchange format
X X X X X
65 Provision of wheel brake
specifications
Specifications e.g. in Doors
eXchange format
X X X
66 Review of wheel brake specifications
Annotated specifications e.g. in Doors eXchange
format
X X X
VDA Recommendation 305-100 Version May 2013 Page 80
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
67 Creation of functional safety
concept for the overall system of ESC assembly
1 plus brake
assembly2, ASIL decomposition
Functional safety
specifications (FUSI) in requirement system, overall system FMEA, FTA, ETA,
etc.
X X1
X X2
68 Review of safety concept - X X X X
69 Supply of necessary functional safety evidence for each supply
status (ESC assembly) in accordance with specifications
Test report X X X
70 Supply of necessary functional safety evidence for each supply status (brake assembly) pursuant
to specifications
Formal, written confirmation
X X X X
72 Realization of test concept and implementation, pursuant to
chapter 6 – Test concept, for brake assembly
1 and ESC
assembly2
Test cases, test report X X2
X X1
71 Examination of test concept in relation to additional requirements of the OEM and
poss. joint supplementing of the tests concept
OEM-specific test concept X X X
73 Component qualification for quality purposes according to specification for ESC assembly
incl. PBC-module but w/o actuator
Qualification reports (e.g. EMC, environmental checks, initial sampling
reports, etc.), process series, etc.
X X X
74 Compilation of test report for
each supply status (ESC assembly
1 with PBC
2)
Test report X X1
X X2
75 Responsibility for parameter
tuning of SSM (excluding holding ability)
Applied software X X X
76 Responsibility for parameter tuning of PBC (incl. holding ability)
Applied software X X X
77 Creation of FMEA, FTA, etc. pursuant to functional safety requirements for ESC assembly
FMEA, FTA, etc. X X X
78 Project-specific determination of resources needed: RAM, ROM and runtime for PBC
Resources needed X X X
79 Integration of resource requirements into the specifications
Specifications e.g. in Doors eXchange format
X X X X
VDA Recommendation 305-100 Version May 2013 Page 81
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
80 Consideration of resources
needed for PBC in overall concept and compliance with specifications
Software version supplied X X X X
81 Evidence of eligibility for approval pursuant to applicable legal regulations for ESC
assembly
X X X
82 Evidence of eligibility for
approval pursuant to applicable legal regulations for brake assembly
X X X
83 Expansion of HW & SW interface for satisfying OEM-specific functional requirements (incl.
necessary measured values between PBC and HOST)
Interface specification
X X X X
84 Provision of software component
description/SSM/interface
Interface description X X X
85 Realization and provision of
integration framework pursuant to development stage planning
Integration stage
framework
X X X X
86 Creating test concept for ESC
assembly with SSM part
Test concept X X X
87 Compiling test report for each supply status for ESC-assembly
SSM + integration of PBC as black box
Test report X X X
88 Specification of customer EPB functions (SSM)
Specifications e.g. in Doors eXchange format
X X X
89 Requirements for secure
standstill (roll-away monitoring, hot-brake case)
Specifications e.g. in Doors
eXchange format and PDF
print out
X X X
90 Implementation of customer functions pursuant to
specifications in SSM
Software version supplied, pursuant to implementation
planning
X X X
91 Integration of PBC into overall software
Software version supplied, with PBC parts
X X
92 Compiling task schedule for ESC assembly, including PBC
requirements
Documented task schedule X X X X
93 Requirements placed on HW (consisting of ESC assembly and brake assembly) for whole vehicle
Requirements from specifications
X X X X
VDA Recommendation 305-100 Version May 2013 Page 82
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
94 Requirements placed on HW for
brake-assembly parking brake actuator, both nominal and for all tolerances
Requirements document for
ESC assembly in agreed format
X X X X
95 Creating HW safety concept for ESC assembly incl. actuation electronics for brake assembly
Specifications for HW safety concept
X X X
96 Developing electronic circuits for measuring current and voltage at ESC-assembly output (actuation
path)
Specifications incl. circuit diagram
X X X X
98 Developing actuation electronics
for brake assembly pursuant to design and safety requirements
Specifications X X X
99 Monitoring of brake-assembly actuation for electrical faults
Specifications and evidence from test report
X X X X
100 Creating HW safety concept for
brake assembly
Specifications for HW
safety concept
X X X
101 Developing brake assembly
pursuant to requirements
EPB parking brake actuator X X X
102 Supplying the components as described in the specifications
for the brake assembly
Qualification reports (e.g. EMC, environmental
checks, initial sampling reports etc.), process series, etc.
X X X
103 Creation of FMEA, FTA, etc. pursuant to functional safety requirements for brake assembly
FMEA, FTA, etc. X X X
104 Provision of SW toolchain of the ESC assembly
Toolchain exists at EPB OES
X X X X
105 Provision of necessary information/files for correct configuration of build
environment
Configuration documents and successful commissioning of toolchain
at brake-assembly OES
X X X
106 Generation and timely provision of PBC using available toolchain
PBC-lib, header file X X X
107 Provision of software component
description for PBC
Interface description X X X
108 Implementation of holding ability
function pursuant to specifications
Software version supplied,
pursuant to implementation planning
X X X
109 Realization of specified function
of PBC pursuant to development stage planning
PBC-lib X X X
VDA Recommendation 305-100 Version May 2013 Page 83
Copyright: VDA
ID Description/task (categories)
Result OEM ESC-assembly OES
Brake-assembly OES
R A S I R A S I R A S I
110 Planning of delivery of PBC PBC-lib X X X
111 Supply of necessary functional
safety evidence for each supply status pursuant to requirements of ESC-assembly OES
Approval document, test
report, functional safety evidence
X X X
112 Creating test concept for brake assembly
Test concept X X X
113 Creating test concept for PBC software
Test concept X X X
115 Compiling test report for each
supply status for PBC part of EPB
Test report X X X
116 Approval of PBC for each supply status and formal confirmation
that requirements are satisfied, incl. functional safety
Approval document X X X X
VDA Recommendation 305-100 Version May 2013 Page 84
Copyright: VDA
9 Regulations and standards
Development of the system in accordance with ISO 26262
ECE R-13 (EU), in particular also Annex 18
ECE R-13H (Japan), in particular also Annex 8
FMVSS 135 (USA)
CMVSS 135 (Canada)
ADR 31-00 (Australia), from 2004 ADR 31-01 onwards
ISO/TS 16949
VDA volumes 1-19
VDI/VDE Guideline 3542 Safety terms for automation systems
(Electromagnetic compatibility in accordance with ISO 11451 and ISO 11452)
Avoidance of pollutants as stipulated by vehicle manufacturer
Emissions performance as stipulated by vehicle manufacturer
For chapter 6 in particular
IEEE 829: Specified form for a test concept
IEEE 1044: fault and anomaly management
ISO 9126: Quality model for software
ISO 15504: a-SPICE (reference model)
ISO 26262 (volume 2 in particular): contains reference models for testing
VDA Recommendation 305-100 Version May 2013 Page 85
Copyright: VDA
10 Glossary 0-km operation Period before vehicle is delivered to customer ACC Adaptive cruise control (radar-based speed control) ASIL Automotive Safety Integrity Level Black box A closed system (internal structure is ignored). In this context,
only the external behavior through defined interfaces is considered. The internal structure may be known, but must not be used.
CRC Cyclic redundancy check ECU Electronic control unit EMC Electromagnetic compatibility EPB Electric parking brake ESC Electronic Stability Control (ESP, VSC, DSC, etc.) ETA Event Tree Analysis FMEA Failure Modes and Effect Analysis FMEDA Failure Modes, Effects and Diagnostic Coverage Analysis FTA Fault Tree Analysis FUSI Functional safety HIL Hardware-in-the-Loop HMI Human-machine interface HPS Hydraulic pressure support HW (Electronic) hardware ISO International Organization for Standardization LH Requirements specification L/R Left/right MoC Parking brake actuator OES Original equipment supplier OEM Original equipment manufacturer PBC Parking brake control PBC-ParamFile PBC parameter file PMHF Probabilistic Metric of Random Hardware Failures RASI Responsible Accountable Support Inform (responsibility matrix)
(R) Responsible (A) Accountable (S) Support (I) Information
Reference Meets the required maturity level for the EPB system Target Meets the required maturity level for both the ESC system and
EPB system SCT Software component test SET System endurance test SIL Software-in-the-Loop test SSM Standstill manager SW Software VDA German Association of the Automotive Industry (VDA)
VDA Recommendation 305-100 Version May 2013 Page 86
Copyright: VDA
VDI The Association of German Engineers VT Vehicle test #E Recommendation #R Requirement #D Definition #DH Definition for Host Hardware #RH Requirement for Host Hardware
VDA Recommendation 305-100 Version May 2013 Page 87
Copyright: VDA
11 Annex
11.1 ANNEX 3.2.A1: Interface details (Functional view)
Pbc inte
rface
nam
e
Rele
van
t to
stim
ula
tion
matr
ix
Unit
Resolu
tion
(S
W
inte
rface)
Physic
al ra
ng
e
(min
)
Physic
al accura
cy
(min
)
Rep
etition r
ate
(ms)
Valu
es
Max. A
SIL
Functio
na
l
safe
ty
(req
., h
azard
)
Actuation request interface
PbcInApplyReleaseReq
uest
Y in -/- 1 -/- -/- 10 None
ParkApply HoldApply RollerbenchApply
Release DynamicApply, PadAdjustment
B Avoid incorrect setting of “ParkApply”/“HoldApply” during
motion 1a), pursuant to decomposition max. ASIL B(D) Avoid incorrect setting of “Release” in parked state 3a),
pursuant to decomposition max. ASIL B(C)
PbcInRollerbenchActive Y in -/- 1 -/- -/- 10 TRUE FALSE
QM -/-
PbcOutActuatorStateLeft N out -/- 1 -/- -/- 10 Final states: ParkApplied Released
Unknown HoldApplied CompletelyReleased
Transitional states: Applying Releasing
B Avoid incorrect setting of “ParkApplied”/“HoldApplied” 4a)
PbcOutActuatorStateRight
N out -/- 1 -/- -/- 10 Final states: ParkApplied Released
Unknown HoldApplied CompletelyReleased
Transitional states: Applying
B Avoid incorrect setting of “ParkApplied”/“HoldApplied” 4a)
VDA Recommendation 305-100 Version May 2013 Page 88
Copyright: VDA
Pbc inte
rface
nam
e
Rele
van
t to
stim
ula
tion
matr
ix
Unit
Resolu
tion
(S
W
inte
rface)
Physic
al ra
ng
e
(min
)
Physic
al accura
cy
(min
)
Rep
etition r
ate
(ms)
Valu
es
Max. A
SIL
Functio
na
l
safe
ty
(req
., h
azard
)
Releasing
Actuator control interface
PbcInHostAvailabilityLeft N in -/- 1 -/- -/- 10 None Apply Release
ApplyAndRelease
A Avoid incorrect setting to “None”/”Release” 3d) Avoid incorrect setting to not “Release” 2a)
PbcInHostAvailabilityRight
N in -/- 1 -/- -/- 10 None Apply
Release ApplyAndRelease
A Avoid incorrect setting to “None”/”Release” 3d)
Avoid incorrect setting to not “Release” 2a)
PbcInMotorCurrentLeft N in A 0.01 0..50A See
#RH3.5,#RH
3.8
1 Actual measured motor current
during actuation. Measures only positive values in drive direction. Fault value: handling see
#R3.66
B Avoid incorrect signal “too low” 3b), 1d)
PbcInMotorCurrentRight N in A 0,01 0..50A See
#RH3.5,#RH
3.8
1 Actual measured motor current
during actuation. Measures only positive values in drive direction. Fault value: handling see
#R3.66
B Avoid incorrect signal “too low” 3b), 1d)
PbcInMotorDriverStateLeft
N in -/- 1 -/- -/- 10 None, Apply, Release, Stop, FreeRun
A Avoid incorrect setting to not “Release” 2a)
Avoid incorrect setting to not “Apply” 3d)
PbcInMotorDriverStateRight
N in -/- 1 -/- -/- 10 None, Apply, Release, Stop, FreeRun
A Avoid incorrect setting to not “Release” 2a)
Avoid incorrect setting to not “Apply” 3d)
PbcInMotorDriverSupplyVoltage
Y in V 0,01 0...20V,
See #RH3.
18
10 PB Actuator driver supply voltage (KL30)
Including Fault value
B Avoid incorrect signal “too low” 3b), 1d)
PbcInMotorVoltageLeft N in V 0,01 -20...20
,
See #RH1.
4
1 Voltage at ECU motor terminals (at H-Bridge)
Fault value: handling see #R3.66
B Avoid incorrect signal “too high” 3b), 1d)
PbcInMotorVoltageRight N in V 0,01 -20...20
See #RH1.
4
1 Voltage at ECU motor terminals (at H-Bridge) Fault value: handling see
#R3.66
B Avoid incorrect signal “too high” 3b), 1d)
PbcOutMotorCommandL N out - 1 - -/- 10 None, Apply, Release, Stop, B Avoid incorrect setting of “Apply” during motion 1a),
VDA Recommendation 305-100 Version May 2013 Page 89
Copyright: VDA
Pbc inte
rface
nam
e
Rele
van
t to
stim
ula
tion
matr
ix
Unit
Resolu
tion
(S
W
inte
rface)
Physic
al ra
ng
e
(min
)
Physic
al accura
cy
(min
)
Rep
etition r
ate
(ms)
Valu
es
Max. A
SIL
Functio
na
l
safe
ty
(req
., h
azard
)
eft FreeRun pursuant to decomposition max. ASIL B(D)
Avoid incorrect setting of “Release” in parked state 3a), pursuant to decomposition max. ASIL B(C)
PbcOutMotorCommandRight
N out - 1 - -/- 10 None, Apply, Release, Stop, FreeRun
B Avoid incorrect setting of “Apply” during motion 1a), pursuant to decomposition max. ASIL B(D)
Avoid incorrect setting of “Release” in parked state 3a), pursuant to decomposition max. ASIL B(C)
PbcInPowerSupplyState Y in -/- 1 -/- -/- 10 Normal, Limited tbd7 Avoid incorrect setting to “Normal”
Environmental data interface
PbcInLongAcceleration Y in m/s^2
0.01 -12,7 …
+12,7
+- 0,3 m/s^2
10 Measure longitudinal
acceleration of the vehicle
chassis Including Fault value
B Avoid incorrect signal “too low” 3b)
PbcInMasterCylinderPressure
Y in bar 1 0 … 180
+- 5 bar
10 Brake pressures (MC) Including Fault value
B Avoid incorrect signal “too high” 3b)
Avoid incorrect signal “too low” 1d)
PbcInVehicleAmbientTemperature
Y in deg °C
1°C -60 … 100
OEM-specifi
c8
1000 Ambient temperature Including Fault value
QM -/-
PbcInWheelPressureFrontLeft
Y in bar 1 0 … 180
+-10 bar
(if HydraulicCo
ntrolPassive)
9
10 Estimated brake pressures (wheel brakes)
A Avoid incorrect signal “too low” 3d)
7 ASIL depends on the use of the signal and should be determined pursuant to the OEM’s requirements. ASIL ratings should be kept to a maximum of “B”.
8 OEM-specific = accuracy depends on the OEM’s temperature measuring system
9 If the signal PbcInWheelPressureReliabilityFrontLeft or Right assumes the value HydraulicControlPassive, the specified accuracy for PbcInWheelPressureFrontLeft or Right is valid. In all other
cases this accuracy is not required. This applies likewise to the rear axle signals.
VDA Recommendation 305-100 Version May 2013 Page 90
Copyright: VDA
Pbc inte
rface
nam
e
Rele
van
t to
stim
ula
tion
matr
ix
Unit
Resolu
tion
(S
W
inte
rface)
Physic
al ra
ng
e
(min
)
Physic
al accura
cy
(min
)
Rep
etition r
ate
(ms)
Valu
es
Max. A
SIL
Functio
na
l
safe
ty
(req
., h
azard
)
PbcInWheelPressureReliabilityFrontLeft
Y in -/- 1 -/- -/- 10 Qualifier showing: Unavailable
TcActive AccActive HydraulicControlPassive
A Avoid incorrect signal “HydraulicControlPassive” 3d)
PbcInWheelPressureFrontRight
Y in bar 1 0 … 180
+-10 bar
(if
HydraulicControlP
assive) 9
10 Estimated brake pressures (wheel brakes) Reserved Values:
UNAVAILABLE = 0xFF
A Avoid incorrect signal “too low” 3d)
PbcInWheelPressureReliabilityFrontRight
Y in -/- 1 -/- -/- 10 Qualifier showing: Unavailable TcActive
AccActive HydraulicControlPassive
A Avoid incorrect signal “HydraulicControlPassive” 3d)
PbcInWheelPressureRe
arLeft
Y in bar 1 0 …
180
+-10
bar (if Hydra
ulicControlPassive
) 9
10 Estimated brake pressures
(wheel brakes) Reserved Values: UNAVAILABLE = 0xFF
A Avoid incorrect signal “too low” 3d)
PbcInWheelPressureRel
iabilityRearLeft
Y in -/- 1 -/- -/- 10 Qualifier showing:
Unavailable TcActive AccActive
HydraulicControlPassive
A Avoid incorrect signal “HydraulicControlPassive” 3d)
PbcInWheelPressureRearRight
Y in bar 1 0 … 180
+-10 bar
(if HydraulicCo
ntrolP
10 Estimated brake pressures (wheel brakes)
A Avoid incorrect signal “too low” 3d)
VDA Recommendation 305-100 Version May 2013 Page 91
Copyright: VDA
Pbc inte
rface
nam
e
Rele
van
t to
stim
ula
tion
matr
ix
Unit
Resolu
tion
(S
W
inte
rface)
Physic
al ra
ng
e
(min
)
Physic
al accura
cy
(min
)
Rep
etition r
ate
(ms)
Valu
es
Max. A
SIL
Functio
na
l
safe
ty
(req
., h
azard
)
assive
)9
PbcInWheelPressureRel
iabilityRearRight
Y in -/- 1 -/- -/- 10 Qualifier showing:
Unavailable TcActive AccActive
HydraulicControlPassive
A Avoid incorrect signal “HydraulicControlPassive” 3d)
PbcInWheelPulseFrontLeft
Y in Draft puls
e/10 ms
1 min 40 pulse/
w_rot10
-/- 10 Wheel Speed Sensor pulses at EPB
Including Fault value
QM -/-
PbcInWheelPulseFrontRight
Y in Draft pulse/10 ms
1 min 40 pulse/w_rot
10
-/- 10 Wheel Speed Sensor pulses at EPB Including Fault value
QM -/-
PbcInWheelPulseRearLeft
Y in Draft puls
e/10 ms
1 min 40 pulse/
w_rot 10
-/- 10 Wheel Speed Sensor pulses at EPB
Including Fault value
QM -/-
PbcInWheelPulseRearRi
ght
Y in Draft
pulse/10 ms
1 min 40
pulse/w_rot
10
-/- 10 Wheel Speed Sensor pulses at
EPB Including Fault value
QM -/-
PbcInWheelSpeedFrontLeft
Y in kph 0,1 0.7 - v_max
+/-6%
11 10 Wheel Velocity Signals
Including Fault value A Avoid incorrect signal “too high” 3d)
PbcInWheelSpeedFrontRight
Y in kph 0,1 0.7 - v_max
+/-6%
12
10 Wheel Velocity Signals Including Fault value
A Avoid incorrect signal “too high” 3d)
PbcInWheelSpeedRearL
eft
Y in kph 0,1 0.7 -
v_max
+/-
6%12
10 Wheel Velocity Signals
Including Fault value
A Avoid incorrect signal “too high” 3d)
PbcInWheelSpeedRearRight
Y in kph 0,1 0.7 - v_max
+/-6%
12
10 Wheel Velocity Signals Including Fault value
A Avoid incorrect signal “too high” 3d)
10
w_rot = wheel rotation
11 Bosch proposal
VDA Recommendation 305-100 Version May 2013 Page 92
Copyright: VDA
Pbc inte
rface
nam
e
Rele
van
t to
stim
ula
tion
matr
ix
Unit
Resolu
tion
(S
W
inte
rface)
Physic
al ra
ng
e
(min
)
Physic
al accura
cy
(min
)
Rep
etition r
ate
(ms)
Valu
es
Max. A
SIL
Functio
na
l
safe
ty
(req
., h
azard
)
HPS interface
PbcInHpsAcknowledge N in -/- 1 -/- -/- 10 True, False A Avoid incorrect signal “True” 3e)
PbcInHpsAvailability N in -/- 1 -/- -/- 10 True, False QM -/-
PbcOutHpsPressure Y out bar 1 0-100 -/- 10 Brake Pressure Signal A Avoid incorrect signal “too low” 3e)
PbcOutHpsRequest Y out -/- 1 -/- -/- 10 True, False A Avoid incorrect signal “False” 3e)
PbcOutOutOfSpecMsg interface
PbcOutOutOfSpecMsg N out -/- 1 -/- -/- 10 None, MessageA, MessageB,…, MessageO
QM -/-
System-wide services –
data storage interface
PbcInDataStorageRead N in -/- -/- -/- -/- EEPR
OM12
To be defined by brake-assembly supplier
B Avoid incorrect signal (incorrect data) 3b), 4a)
PbcInDataStorageValid1 N in -/- 1 -/- -/- 10 True, False B Avoid incorrect signal “True” 3b), 4a)
PbcInDataStorageValid2 N in -/- 1 -/- -/- 10 True, False B Avoid incorrect signal “True” 3b), 4a)
PbcInDataStorageValid3 N in -/- 1 -/- -/- 10 True, False B Avoid incorrect signal “True” 3b), 4a)
PbcInUnexpectedPowerDown
Y in -/- 1 -/- -/- 10 True, False B Avoid incorrect signal “False” 3b), 1d)
PbcOutDataStorageWrit
e:
N out -/- -/- -/- -/- 10 To be defined by brake-
assembly supplier
B Avoid incorrect signal (incorrect data) 3b), 4a)
PbcInVariantItem Y in -/- 1 -/- 10 Content is customer-specific (variant coding, SCN coding, etc.).
B Avoid incorrect signal (incorrect data) 3b)
System-wide services – diagnostic interface
12
Typically, the read-out of the EEPROM depends on the physical read-out speed of the EEPROM hardware used.
VDA Recommendation 305-100 Version May 2013 Page 93
Copyright: VDA
Pbc inte
rface
nam
e
Rele
van
t to
stim
ula
tion
matr
ix
Unit
Resolu
tion
(S
W
inte
rface)
Physic
al ra
ng
e
(min
)
Physic
al accura
cy
(min
)
Rep
etition r
ate
(ms)
Valu
es
Max. A
SIL
Functio
na
l
safe
ty
(req
., h
azard
)
PbcInDiagRequest Y in -/- 1 -/- -/- 10 None,
OpenBrakeRearLeft, OpenBrakeRearRight, OpenBrakeBoth,
CloseBrakeRearLeft, CloseBrakeRearRight, CloseBrakeBoth,
TouchBrakeRearLeft, TouchBrakeRearRight, TouchBrakeBoth,
StepCloseRearLeft StepCloseRearRight StepCloseBoth
AssemblyCheck, EnterMaintenanceMode, ExitMaintenanceMode
B Avoid incorrect setting in “locking” direction during motion
1a), pursuant to decomposition max. ASIL B(D) Avoid incorrect setting in “opening” direction in parked state
3a), pursuant to decomposition max. ASIL B(C)
PbcInDiagOperationMode
Y in -/- 1 -/- -/- 10 NormalMode,… (further content is OEM-specific)
A Avoid incorrect signal not “NormalMode” (OEM-specific) 2a)
PbcOutDiagAchievedClampForceLeft
N out -/- 1 -/- -/- 10 Diagnostic Interface QM -/-
PbcOutDiagAchievedCla
mpForceRight
N out -/- 1 -/- -/- 10 Diagnostic Interface QM -/-
PbcOutDiagActuationCounterLeft
N out -/- 1 -/- -/- 10 Diagnostic Interface QM -/-
PbcOutDiagActuationCounterRight
N out -/- 1 -/- -/- 10 Diagnostic Interface QM -/-
PbcOutDiagBrakeTemperatureLeft
N out -/- 1 -/- -/- 10 Diagnostic Interface QM -/-
PbcOutDiagBrakeTemp
eratureRight
N out -/- 1 -/- -/- 10 Diagnostic Interface QM -/-
PbcOutDiagRequestAckowledge
N out -/- 1 -/- -/- 10 None, OpenBrakeRearLeft,
OpenBrakeRearRight, OpenBrakeBoth, CloseBrakeRearLeft,
CloseBrakeRearRight, CloseBrakeBoth, TouchBrakeRearLeft,
TouchBrakeRearRight, TouchBrakeBoth,
QM -/-
VDA Recommendation 305-100 Version May 2013 Page 94
Copyright: VDA
Pbc inte
rface
nam
e
Rele
van
t to
stim
ula
tion
matr
ix
Unit
Resolu
tion
(S
W
inte
rface)
Physic
al ra
ng
e
(min
)
Physic
al accura
cy
(min
)
Rep
etition r
ate
(ms)
Valu
es
Max. A
SIL
Functio
na
l
safe
ty
(req
., h
azard
)
StepCloseRearLeft
StepCloseRearRight StepCloseBoth AssemblyCheck,
EnterMaintenanceMode, ExitMaintenanceMode
PbcOutDiagRequestStatus
N out -/- 1 -/- -/- 10 Idle Started Running
Done Error
QM -/-
PbcOutPbcSoftwareVers
ion
N out -/- 1 -/- -/- 10 PBC SW version QM -/-
PbcInHostSoftwareVersion
N in -/- 1 -/- -/- 10 Host SW version QM -/-
System-wide services – fault management interface
PbcInFaultRecoveryRequest (1...n)
Y in -/- 1 -/- -/- 10 NoRecoveryRequest, RecoveryRequest
QM -/-
PbcOutFaultStatus (1...n)
N out -/- 1 -/- -/- 10 NoResult PrePassed, Passed,
PreFailed, Failed, NotSupported
A Avoid incorrect signal “Passed” / “PrePassed” 2a), 3e)
System-wide services – system mode management interface
PbcInSleepTime Y in [s] 1 1 .. 7200 s
+-5 1000 Time between PBC Exit and first PBC Cyclic Reserved Values: Including Init and Fault value
A Avoid incorrect signal “too high” 3d)
PbcOutEcuPowerLatchRequest
Y out -/- 1 -/- -/- 10 True, False A Avoid incorrect signal “False” 3d)
System-wide services – development message interface
PbcOutDevelopmentMessages
N out - 1 -/- -/- 10 Content is OEM-specific QM -/-
VDA Recommendation 305-100 Version May 2013 Page 95
Copyright: VDA
11.2 ANNEX 3.2.A2: Interface details (Software view)
All signals from the Functional Interfaces are listed below, along with the characteristics relevant to their implementation in software. They have been divided into three groups:
Enumeration signals
Continuous signals (physical parameters)
Additional signals (meta information such as version identification, also non-characterized data of the permanent memory.
Enumeration signals
Interface name Enumeration values
Prefix Base name
Environmental status information -> PBC (“”)
PbcIn WheelPressureReliabilityRearLeft ENUM_CODE0:ePbcWheelPressureReliabilityUnavailable ENUM_CODE1:ePbcWheelPressureReliabilityTcActive
ENUM_CODE2:ePbcWheelPressureReliabilityAccActive ENUM_CODE3:ePbcWheelPressureReliabilityNoHydraulicControl
PbcIn WheelPressureReliabilityRearRight ENUM_CODE0:ePbcWheelPressureReliabilityUnavailable
ENUM_CODE1:ePbcWheelPressureReliabilityTcActive ENUM_CODE2:ePbcWheelPressureReliabilityAccActive ENUM_CODE3:ePbcWheelPressureReliabilityNoHydraulicControl
PbcIn WheelPressureReliabilityFrontLeft ENUM_CODE0:ePbcWheelPressureReliabilityUnavailable ENUM_CODE1:ePbcWheelPressureReliabilityTcActive
ENUM_CODE2:ePbcWheelPressureReliabilityAccActive ENUM_CODE3:ePbcWheelPressureReliabilityNoHydraulicControl
PbcIn WheelPressureReliabilityFrontRight ENUM_CODE0:ePbcWheelPressureReliabilityUnavailable ENUM_CODE1:ePbcWheelPressureReliabilityTcActive ENUM_CODE2:ePbcWheelPressureReliabilityAccActive
ENUM_CODE3:ePbcWheelPressureReliabilityNoHydraulicControl
PBC <-> ESC control & actuator ("HPS")
PbcOut HpsRequest ENUM_CODE0:ePbcHpsNotRequested ENUM_CODE1:ePbcHpsRequested
PbcIn HpsAvailability ENUM_CODE0:ePbcHpsAvailable ENUM_CODE1:ePbcHpsNotAvailable
PbcIn HpsAcknowledge ENUM_CODE0:ePbcHpsAcknowledged
ENUM_CODE1:ePbcHpsNotAcknowledged
PBC <-> system-wide service (“Fault management interface”)
PbcOut FaultStatus ENUM_CODE0:ePbcFaultStateNoResult ENUM_CODE1:ePbcFaultStatePrePassed
ENUM_CODE2:ePbcFaultStatePassed ENUM_CODE3:ePbcFaultStatePreFailed ENUM_CODE4:ePbcFaultStateFailed
ENUM_CODE5:ePbcFaultStateNotSupported
PbcIn FaultRecoveryRequest ENUM_CODE0:ePbcNoRecoveryRequest
ENUM_CODE1:ePbcRecoveryRequest
PBC <-> system-wide service (“Interface to system-wide services/data storage”)
PbcIn DataStorageValid1 ENUM_CODE0:ePbcDataStorageQualifierValid ENUM_CODE1:ePbcDataStorageQualifierInvalid
PbcIn DataStorageValid2 ENUM_CODE0:ePbcDataStorageQualifierValid ENUM_CODE1:ePbcDataStorageQualifierInvalid
VDA Recommendation 305-100 Version May 2013 Page 96
Copyright: VDA
Interface name Enumeration values
Prefix Base name
PbcIn DataStorageValid3 ENUM_CODE0:ePbcDataStorageQualifierValid ENUM_CODE1:ePbcDataStorageQualifierInvalid
PbcIn UnexpectedPowerDown ENUM_CODE0:ePbcNormalPowerdown
ENUM_CODE1:ePbcUnexpectedPowerdown
PBC <-> system-wide service (“Interface to system-wide services/diagnosis”)
PbcIn DiagRequest ENUM_CODE0:ePbcDiagRequestNone ENUM_CODE1:ePbcDiagRequestOpenBrakeRearLeft
ENUM_CODE2:ePbcDiagRequestOpenBrakeRearRight ENUM_CODE3:ePbcDiagRequestOpenBrakeBoth ENUM_CODE4:ePbcDiagRequestCloseBrakeRearLeft
ENUM_CODE5:ePbcDiagRequestCloseBrakeRearRight ENUM_CODE6:ePbcDiagRequestCloseBrakeBoth ENUM_CODE7:ePbcDiagRequestTouchBrakeRearLeft
ENUM_CODE8:ePbcDiagRequestTouchBrakeRearRight ENUM_CODE9:ePbcDiagRequestTouchBrakeBoth ENUM_CODE10:ePbcDiagRequestStepCloseRearLeft
ENUM_CODE11:ePbcDiagRequestStepCloseRearRight ENUM_CODE12:ePbcDiagRequestStepCloseBoth ENUM_CODE13:ePbcDiagRequestAssemblyCheck
ENUM_CODE14:ePbcDiagRequestEnterMaintenanceMode ENUM_CODE15:ePbcDiagRequestExitMaintenanceMode
PbcOut DiagRequestAcknowledge ENUM_CODE0:ePbcDiagRequestNone ENUM_CODE1:ePbcDiagRequestOpenBrakeRearLeft
ENUM_CODE2:ePbcDiagRequestOpenBrakeRearRight ENUM_CODE3:ePbcDiagRequestOpenBrakeBoth ENUM_CODE4:ePbcDiagRequestCloseBrakeRearLeft
ENUM_CODE5:ePbcDiagRequestCloseBrakeRearRight ENUM_CODE6:ePbcDiagRequestCloseBrakeBoth ENUM_CODE7:ePbcDiagRequestTouchBrakeRearLeft
ENUM_CODE8:ePbcDiagRequestTouchBrakeRearRight ENUM_CODE9:ePbcDiagRequestTouchBrakeBoth ENUM_CODE10:ePbcDiagRequestStepCloseRearLeft
ENUM_CODE11:ePbcDiagRequestStepCloseRearRight ENUM_CODE12:ePbcDiagRequestStepCloseBoth ENUM_CODE13:ePbcDiagRequestAssemblyCheck
ENUM_CODE14:ePbcDiagRequestEnterMaintenanceMode ENUM_CODE15:ePbcDiagRequestExitMaintenanceMode
PbcOut DiagRequestStatus ENUM_CODE0:ePbcDiagRequestStatusIdle ENUM_CODE1:ePbcDiagRequestStatusStarted
ENUM_CODE2:ePbcDiagRequestStatusRunning ENUM_CODE3:ePbcDiagRequestStatusDone ENUM_CODE4:ePbcDiagRequestStatusError
PbcIn DiagOperationMode ENUM_CODE0:ePbcDiagOperationModeNormal ENUM_CODE1:ePbcDiagOperationModeA ENUM_CODE2:ePbcDiagOperationModeB
ENUM_CODE3:ePbcDiagOperationModeC ENUM_CODE4:ePbcDiagOperationModeD ENUM_CODE5:ePbcDiagOperationModeE
ENUM_CODE6:ePbcDiagOperationModeF ENUM_CODE7:ePbcDiagOperationModeG ENUM_CODE8:ePbcDiagOperationModeH
ENUM_CODE9:ePbcDiagOperationModeI ENUM_CODE10:ePbcDiagOperationModeJ ENUM_CODE11:ePbcDiagOperationModeK
ENUM_CODE12:ePbcDiagOperationModeL ENUM_CODE13:ePbcDiagOperationModeM ENUM_CODE14:ePbcDiagOperationModeN ENUM_CODE15:ePbcDiagOperationModeO
VDA Recommendation 305-100 Version May 2013 Page 97
Copyright: VDA
Interface name Enumeration values
Prefix Base name
PBC <-> system-wide service ("Interface to system-wide services/system mode interface")
PbcOut EcuPowerLatchRequest ENUM_CODE0:ePbcPowerLatchRequested
ENUM_CODE1:ePbcPowerLatchNotRequested
PBC -> HMI (“PbcOutOutOfSpecMsg”)
PbcOut OutOfSpecMsg ENUM_CODE0:ePbcMsgOutOfSpecNone ENUM_CODE1:ePbcMsgOutOfSpecA ENUM_CODE2:ePbcMsgOutOfSpecB
ENUM_CODE3:ePbcMsgOutOfSpecC ENUM_CODE4:ePbcMsgOutOfSpecD ENUM_CODE5:ePbcMsgOutOfSpecE
ENUM_CODE6:ePbcMsgOutOfSpecF ENUM_CODE7:ePbcMsgOutOfSpecG ENUM_CODE8:ePbcMsgOutOfSpecH
ENUM_CODE9:ePbcMsgOutOfSpecI ENUM_CODE10:ePbcMsgOutOfSpecJ ENUM_CODE11:ePbcMsgOutOfSpecK
ENUM_CODE12:ePbcMsgOutOfSpecL ENUM_CODE13:ePbcMsgOutOfSpecM ENUM_CODE14:ePbcMsgOutOfSpecN
ENUM_CODE15:ePbcMsgOutOfSpecO
PBC<->EPB HW driver control (“Actuation control L/R”)
PbcIn HostAvailabilityLeft ENUM_CODE0:ePbcAvailabilityNone
ENUM_CODE1:ePbcAvailabilityApply ENUM_CODE2:ePbcAvailabilityRelease ENUM_CODE3:ePbcAvailabilityApplyAndRelease
PbcIn HostAvailabilityRight ENUM_CODE0:ePbcAvailabilityNone ENUM_CODE1:ePbcAvailabilityApply
ENUM_CODE2:ePbcAvailabilityRelease ENUM_CODE3:ePbcAvailabilityApplyAndRelease
PbcOut MotorCommandLeft ENUM_CODE0:ePbcMotorCommandNone
ENUM_CODE1:ePbcMotorCommandApply ENUM_CODE2:ePbcMotorCommandRelease ENUM_CODE3:ePbcMotorCommandStop
ENUM_CODE4:ePbcMotorCommandFreerun
PbcOut MotorCommandRight ENUM_CODE0:ePbcMotorCommandNone ENUM_CODE1:ePbcMotorCommandApply
ENUM_CODE2:ePbcMotorCommandRelease ENUM_CODE3:ePbcMotorCommandStop ENUM_CODE4:ePbcMotorCommandFreerun
PbcIn MotorDriverStateLeft ENUM_CODE0:ePbcMotorDriverStateNone
ENUM_CODE1:ePbcMotorDriverStateApply ENUM_CODE2:ePbcMotorDriverStateRelease ENUM_CODE3:ePbcMotorDriverStateStop
ENUM_CODE4:ePbcMotorDriverStateFreerun
PbcIn MotorDriverStateRight ENUM_CODE0:ePbcMotorDriverStateNone ENUM_CODE1:ePbcMotorDriverStateApply
ENUM_CODE2:ePbcMotorDriverStateRelease ENUM_CODE3:ePbcMotorDriverStateStop ENUM_CODE4:ePbcMotorDriverStateFreerun
PbcIn PowerSupplyState ENUM_CODE0:ePowerSupplyStateNormal
ENUM_CODE1:ePowerSupplyStateLimited
SSM<->PBC (“Actuation Request”)
VDA Recommendation 305-100 Version May 2013 Page 98
Copyright: VDA
Interface name Enumeration values
Prefix Base name
PbcIn ApplyReleaseRequest ENUM_CODE0:ePbcApplyReleaseRequestNone ENUM_CODE1:ePbcApplyReleaseRequestParkApply ENUM_CODE2:ePbcApplyReleaseRequestHoldApply
ENUM_CODE3:ePbcApplyReleaseRequestRelease ENUM_CODE4:ePbcApplyReleaseRequestDynamicApply ENUM_CODE5:ePbcApplyReleaseRequestRollerbenchApply
ENUM_CODE6:ePbcApplyReleaseRequestPadAdjustment
PbcOut ActuatorStateLeft ENUM_CODE1:ePbcActuatorStateParkApplied ENUM_CODE2:ePbcActuatorStateHoldApplied
ENUM_CODE3:ePbcActuatorStateReleased ENUM_CODE7:ePbcActuatorStateApplying ENUM_CODE8:ePbcActuatorStateReleasing
ENUM_CODE9:ePbcActuatorStateCompletelyReleased ENUM_CODE10:ePbcActuatorStateUnknown
PbcOut ActuatorStateRight ENUM_CODE1:ePbcActuatorStateParkApplied ENUM_CODE2:ePbcActuatorStateHoldApplied
ENUM_CODE3:ePbcActuatorStateReleased ENUM_CODE7:ePbcActuatorStateApplying ENUM_CODE8:ePbcActuatorStateReleasing
ENUM_CODE9:ePbcActuatorStateCompletelyReleased ENUM_CODE10:ePbcActuatorStateUnknown
PbcIn RollerbenchActive ENUM_CODE0:ePbcRollerbenchActive
ENUM_CODE1:ePbcRollerbenchInactive
The numerical values used in the above table for the individual alternative are defined as follows:
Identifier
Valu
e
Identifier
Valu
e
Identifier
Valu
e
Identifier V
alu
e
ENUM_CODE0 5 ENUM_CODE4 66 ENUM_CODE8 142 ENUM_CODE12 201
ENUM_CODE1 27 ENUM_CODE5 92 ENUM_CODE9 144 ENUM_CODE13 215
ENUM_CODE2 40 ENUM_CODE6 111 ENUM_CODE10 163 ENUM_CODE14 228
ENUM_CODE3 54 ENUM_CODE7 113 ENUM_CODE11 189 ENUM_CODE15 250
Continuous signals (physical parameters)
Interface name Type Scale Unit
Range of validity
(scaled values) Fault
(raw value) Prefix Basename Min Max
Environmental status information -> PBC (“”)
PbcIn WheelPulseRearLeft uint8 1 n/a 0 254 255
PbcIn WheelPulseRearRight uint8 1 n/a 0 254 255
PbcIn WheelPulseFrontLeft uint8 1 n/a 0 254 255
PbcIn WheelPulseFrontRight uint8 1 n/a 0 254 255
PbcIn WheelSpeedRearLeft sint16 0.1 kph -327.67 327.67 -32768
PbcIn WheelSpeedRearRight sint16 0.1 kph -327.67 327.67 -32768
PbcIn WheelSpeedFrontLeft sint16 0.1 kph -327.67 327.67 -32768
PbcIn WheelSpeedFrontRight sint16 0.1 kph -327.67 327.67 -32768
VDA Recommendation 305-100 Version May 2013 Page 99
Copyright: VDA
Interface name Type Scale Unit
Range of validity (scaled values) Fault
(raw value) Prefix Basename Min Max
PbcIn VehicleAmbientTemperature sint16 1 °C -40 2000 -32768
PbcIn LongAcceleration sint16 0.01 m/s/s -12.70 12.70 -32768
PbcIn MasterCylinderPressure uint16 1 bar 0 1000 65535
PbcIn WheelPressureRearLeft uint16 1 bar 0 1000 n/a
PbcIn WheelPressureRearRight uint16 1 bar 0 1000 n/a
PbcIn WheelPressureFrontLeft uint16 1 bar 0 1000 n/a
PbcIn WheelPressureFrontRight uint16 1 bar 0 1000 n/a
PBC <-> ESC control & actuator (“HPS”)
PbcOut HpsPressure uint16 1 bar 0 1000 n/a
PBC <-> system-wide service (“Interface to system-wide services/diagnosis”)
PbcOut DiagBrakeTemperatureLeft sint16 1 °C -40 2000 -32768
PbcOut DiagBrakeTemperatureRight sint16 1 °C -40 2000 -32768
PbcOut DiagActuationCounterLeft uint32 1 n/a 0 2^(32) - 1 2^(32)
PbcOut DiagActuationCounterRight uint32 1 n/a 0 2^(32) - 1 2^(32)
PbcOut DiagAchievedClampForceLeft uint16 1 N 0 65535 n/a
PbcOut DiagAchievedClampForceRight uint16 1 N 0 65535 n/a
PBC <-> system-wide service (“Interface to system-wide services/system mode interface”)
PbcIn PbcSleepTime uint16 1 s 1 65534 65535
PBC<->EPB HW driver control (“Actuation control L/R”)
PbcIn MotorCurrentLeft sint16[10] 0.01 A 0.00 50.00 n/a
PbcIn MotorCurrentRight sint16[10] 0.01 A 0.00 50.00 n/a
PbcIn MotorDriverSupplyVoltage sint16 0.01 V -20.00 20.00 -32768
PbcIn MotorVoltageLeft sint16[10] 0.01 V -20.00 20.00 n/a
PbcIn MotorVoltageRight sint16[10] 0.01 V -20.00 20.00 n/a
VDA Recommendation 305-100 Version May 2013 Page 100
Copyright: VDA
Additional signals (meta information such as version identification, but also non-characterized data in the persistent memory.
Prefix Basename Data type
PBC <-> system-wide service (“Interface to system-wide services/data storage”)
PbcIn DataStorageRead uint8[256]
PbcOut DataStorageWrite uint8[256]
PBC <-> system-wide service (“Interface to system-wide services/diagnosis”)
PbcOut PbcSoftwareVersion uint8[6]
PbcIn HostSoftwareVersion uint8[6]
PbcConst PbcVersion const uint8[64]
PbcConst PbcParameterVersion const uint8[64]
PBC <-> system-wide service (“Interface to system-wide services/system mode interface”)
PbcIn VariantItem uint8[128]