vda ad hoc ak kreuztausch · 5.1.2 fmea structure ... vda recommendation 305-100 version may 2013...

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

mailto:[email protected]

VDA Recommendation 305-100 Version May 2013

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.


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


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


Copyright: VDA

11.1 ANNEX 3.2.A1: Interface details (Functional view) ............................................. 87

11.2 ANNEX 3.2.A2: Interface details (Software view) ................................................ 95


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.


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).


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


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.


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.


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)


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.


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 &current 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


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


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


Copyright: VDA


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.


Copyright: VDA


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.).


Copyright: VDA


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


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.


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)



Table 3.1.1 T1: Definition of the host safety barrier states


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.


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-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


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


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


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


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.


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


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


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).


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.


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


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


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.


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


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.


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


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).


Environmental data PBC: Detected pulses of the wheel rotary speed sensor.


Environmental data PBC: Measured ambient temperature of the vehicle.

PbcInMasterCylinderPressure Environmental data PBC: Measured signal of the pressure sensor at the master cylinder.


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


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


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.


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


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:





AssemblyCheck


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


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


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.


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


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


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.


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


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


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


Copyright: VDA


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


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.


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


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.


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.


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


Copyright: VDA

Opening the parking brake

Ibrake

I mo

t

t

Irsh

Iload

Iidle

tend

0 t0tend

Ieff

EE_App

Requirements:




#DH3.7

Irsh = 30 A



#DH3.10 tend = 1.5 s

#DH3.11 EE_App = 9.5 As

#DH3.12 Load cycles: 100,000


Copyright: VDA

Re-clamping the parking brake

I mo

t

t

Irsh

Iload

Iidle

tendIbrake

1 2 50 t0

tend

Ieff

EE_App

Requirements:




#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:




#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


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




#DH3.19 Irsh = 30 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.


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).




#DH3.25 Irsh = 30 A


#DH3.27 Ieff_lock = 10 A

#DH3.28 tend = 3.5 s


#DH3.30

Load cycles: the dynamic deceleration function with the parking brake actuator is required a maximum of 5 times over the lifetime.


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.34 tend = 2.5 s


#DH3.36

Load cycles: distribution of load cycles in accordance with the required test program.


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




#DH3.37 Irsh = 25 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


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





#DH3.44 Load cycles: 25

Adjusting the parking brake for wear

Requirements:




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


Copyright: VDA

Parking brake pad replacement function

Requirement: worn brake pads are not exchanged for new parts




#DH3.47 Irsh = 30 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 temperature: <= 80°C

Temperature of parking brake actuator: 25°C

#DH3.53 Irsh = 25 A



#DH3.56 tend = 2.5 s


#DH3.58 Load cycles: deceleration function is needed max. 5 times over lifetime


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.


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.


Copyright: VDA

Completeness and correctness must be guaranteed through the project-specific safety analyses.

PbcOutMotorCommand

(L/R)


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)


PbcEnableLine(Lock/Release)

environmental data

system wide services

persistent

data storage

fault

management

system mode

management

diagnosis

development

message

service brake

state

PbcInMasterCylinderPressure


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


diagnosis

PbcInDiagRequest

PbcOutDiagRequestAcknowledge

PbcOutPbcSwVersion


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.


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).


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.


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


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.


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


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


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.


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.


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)


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.


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


R, A S,I HiL, VT

1.7 ENG.10

System Test

PBC SW + Brake + Actuator


I,S R, A HiL, VT 2.8 ENG.10

System Test

Host HW+Host SW


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


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.


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.


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.


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.


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.


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


Copyright: VDA



Brake-assembly OES


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


Copyright: VDA



Brake-assembly OES


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


Copyright: VDA



Brake-assembly OES


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


Copyright: VDA



Brake-assembly OES


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


53 Provision of target system, from late B-sample stage onward



Copyright: VDA



Brake-assembly OES


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.


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


Copyright: VDA



Brake-assembly OES


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


Copyright: VDA



Brake-assembly OES


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


Copyright: VDA



Brake-assembly OES


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


Copyright: VDA



Brake-assembly OES


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


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


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)


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


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)


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


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


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),


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)


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.


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


PbcInWheelPressureReliabilityFrontRight

Y in -/- 1 -/- -/- 10 Qualifier showing: Unavailable TcActive

AccActive HydraulicControlPassive


PbcInWheelPressureRe

arLeft

Y in bar 1 0 …

180

+-10

bar (if Hydra

ulicControlPassive

) 9

10 Estimated brake pressures

(wheel brakes) Reserved Values: UNAVAILABLE = 0xFF


PbcInWheelPressureRel

iabilityRearLeft

Y in -/- 1 -/- -/- 10 Qualifier showing:

Unavailable TcActive AccActive

HydraulicControlPassive


PbcInWheelPressureRearRight

Y in bar 1 0 … 180

+-10 bar

(if HydraulicCo

ntrolP

10 Estimated brake pressures (wheel brakes)



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


PbcInWheelPulseFrontLeft

Y in Draft puls

e/10 ms

1 min 40 pulse/

w_rot10

-/- 10 Wheel Speed Sensor pulses at EPB


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


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


+/-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



PbcInWheelSpeedRearRight


+/-6%

12

10 Wheel Velocity Signals Including Fault value


10

w_rot = wheel rotation

11 Bosch proposal


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)



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.


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,





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


PbcOutDiagActuationCounterLeft


PbcOutDiagActuationCounterRight


PbcOutDiagBrakeTemperatureLeft


PbcOutDiagBrakeTemp

eratureRight


PbcOutDiagRequestAckowledge

N out -/- 1 -/- -/- 10 None, OpenBrakeRearLeft,

OpenBrakeRearRight, OpenBrakeBoth, CloseBrakeRearLeft,

CloseBrakeRearRight, CloseBrakeBoth, TouchBrakeRearLeft,

TouchBrakeRearRight, TouchBrakeBoth,

QM -/-


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,



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


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 -/-


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



Copyright: VDA


Prefix Base name


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


Copyright: VDA


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”)


Copyright: VDA


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




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


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


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


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]


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]

vda ad hoc ak kreuztausch · 5.1.2 fmea structure ... vda recommendation 305-100 version may 2013...

Documents