02016_15_04619_1.0_DC_TI_703_TS_UDS_Configuration_Baseline_3_0_Filtre_DAE_EMP2v3_31072015.doc

TS UDS Configuration
RÉFÉRENCE IND PROJECT PAGE
02016_15_04619
1.0 DAE EMP2v3
1
Baseline : 3.0 31
THIS DOCUMENT IS THE PROPERTY OF PSA AND MAY NOT BE REPRODUCED OR DISCLOSED WITHOUT ITS AUTHORIZATION
Reference:
02016_15_04619
Identification:
GEN-CONFIG-ST-
Applicable to project:
DAE EMP2v3
Title:
SCOPE: Extract Word based on the DC_TI_703 – Baseline 3.0.
Filtre_DAE_EMP2v3_31072015.
Author(s):
Name :
SOUCHET Sébastien
Entity:
DSEE/CIAE/CA2E/PRDO
Date:
31.07.2015
Signature:
Inspector(s):
Name :
GEORGES Emmanuel
Entity:
DSEE/CIAE/CA2E/PRDO
Date:
31.07.2015
Signature:
Approved By:
Name :
LOPEZ Thierry
Entity:
DSEE/CIAE/CA2E/PRDO
Date:
31.07.2015
Signature:
This document is stored in tool DOORS with the address:
doors://DOORS:36677/?version=2&prodID=0&urn=urn:telelogic::1-
0000000000000000-B-0024b221-1000004
PSA designation code:

02016_15_04619
1.0 DAE EMP2v3
2
Baseline : 3.0 31
Table of contents
Table of contents.......................................................................................................................................... 2
1 PURPOSE............................................................................................................................................ 4
2 SCOPE................................................................................................................................................. 5
2.1 General description of the system................................................................................................ 5
3 QUOTED DOCUMENTS ................................................................................................................... 6
3.1 Reference documents................................................................................................................... 6
3.2 Applicable documents.................................................................................................................. 6
4 TERMINOLOGY ................................................................................................................................ 7
4.1 Glossary ....................................................................................................................................... 7
5 REQUIREMENTS............................................................................................................................... 7
5.1 CONFIGURATION PROCEDURES.......................................................................................... 7
5.1.1 Secured Variant coding.......................................................................................................... 7
5.1.1.1 General description......................................................................................................... 7
5.1.1.2 Control unit delivery requirements................................................................................. 8
5.1.1.2.1 Variant coding index .................................................................................................. 9
5.1.1.2.2 Value of parameters at delivery ................................................................................. 9
5.1.1.2.3 Configuration protection mechanism....................................................................... 10
5.1.1.3 Description of the function........................................................................................... 10
5.1.1.4 The possible variants .................................................................................................... 11
5.1.1.5 Encoding method.......................................................................................................... 11
5.1.1.6 The programmed variants............................................................................................. 11
5.1.1.6.1 Programmed variables.............................................................................................. 12
5.1.1.6.2 Remote encoding number......................................................................................... 12
5.1.1.7 Checks of variant coding parameters............................................................................ 13
5.1.1.8 Interfunctionnal ............................................................................................................ 13
5.1.1.9 Sequence of variant coding procedure.......................................................................... 14
5.1.1.9.1 Phase 0, preparing for variant coding....................................................................... 14
5.1.1.9.2 Phase 1, entry in extended session ........................................................................... 14
5.1.1.9.3 Phase 2, using the protection mechanism................................................................. 14
5.1.1.9.4 Phase 3, variant coding............................................................................................. 15
5.1.1.9.5 Phase 4, checks......................................................................................................... 15
5.1.1.9.6 Phase 5, end of communication................................................................................ 15
5.1.1.10 Protection mechanism................................................................................................... 15
5.1.1.11 Reading command of variant coding parameters ......................................................... 16
5.1.1.12 Writing command of variant coding parameters .......................................................... 16
5.1.1.13 Flow chart of variant coding writing request................................................................ 18
5.1.1.14 Post-equipment specific requirements.......................................................................... 19
5.1.1.15 Secured variant coding of post-equipment parameters for ABS-ESP.......................... 19
5.1.2 Injectors characterization..................................................................................................... 19
5.2 DIAGNOSTIC MANAGER FOR NO POWERTRAIN AND NO OBD ECU ........................ 19
5.2.1 Faults memory ..................................................................................................................... 19
5.2.1.1 Size of memory............................................................................................................. 19
5.2.1.2 Type of memory used................................................................................................... 19
5.2.2 Clearing faults...................................................................................................................... 19
5.2.2.1 Automatic clearing ....................................................................................................... 19

02016_15_04619
1.0 DAE EMP2v3
3
Baseline : 3.0 31
5.2.2.2 Forced clearing ............................................................................................................. 20
5.2.2.2.1 Diagnostic tool request............................................................................................. 20
5.2.2.2.2 Frame « integration electronic » (CAN identifier : 092h)........................................ 20
5.2.3 DTCAgingcounter................................................................................................................ 21
5.2.4 Read faults codes by status mask......................................................................................... 22
5.2.5 Management of faults memory............................................................................................ 23
5.2.5.1 Storage of faults codes.................................................................................................. 23
5.2.5.2 Induced faults ............................................................................................................... 23
5.2.5.3 Storage faults during a diagnostic session.................................................................... 23
5.2.5.4 Memory full.................................................................................................................. 24
5.2.6 DTCSnapshotRecordData.................................................................................................... 24
5.2.6.1 Definition...................................................................................................................... 24
5.3 ALLOCATION OF CAN FRAME IDENTIFIERS FOR USE of CAN CCP/XCP PROTOCOL
25
5.3.1 Purpose................................................................................................................................. 25
5.3.2 Problem................................................................................................................................ 25
5.3.3 Recommended solution........................................................................................................ 25
5.4 FAULT MANAGEMENT......................................................................................................... 28
5.4.1 Details on clear DTC information........................................................................................ 28
5.4.2 Signalling a commissioning non-conformity....................................................................... 29
5.5 Operational requirements........................................................................................................... 29
5.5.1 Mission profile..................................................................................................................... 29
5.5.2 Service life ........................................................................................................................... 29
5.5.3 Fail safe operation................................................................................................................ 29
5.5.3.1 Reliability ..................................................................................................................... 29
5.5.3.2 Maintainability.............................................................................................................. 29
5.5.4 Product quality..................................................................................................................... 29
5.5.5 Protection against hostility................................................................................................... 29
5.5.6 System resources.................................................................................................................. 29
5.5.7 Documentary requirements.................................................................................................. 30
5.6 Constraint requirements............................................................................................................. 30
5.6.1 Regulation and consumerism............................................................................................... 30
5.6.2 Weight and other physical specifications ............................................................................ 30
5.6.3 Design and manufacturing................................................................................................... 30
5.6.3.1 Studies and/or imposed solutions ................................................................................. 30
5.6.3.2 Materials ....................................................................................................................... 30
5.6.3.3 Manufacturing .............................................................................................................. 30
5.6.3.4 Marking of the products ............................................................................................... 30
5.6.4 Traceability and configuration management ....................................................................... 30
5.6.5 Transportability, storage and packaging.............................................................................. 31
5.6.6 Flexibility and extension...................................................................................................... 31
5.6.7 Withdrawal from service...................................................................................................... 31
5.6.8 Environment conditions....................................................................................................... 31

02016_15_04619
1.0 DAE EMP2v3
4
Baseline : 3.0 31
1 PURPOSE
The purpose of this document is to define the procedures of configuration (variant coding,
characterization of injectors...) of ECUs having UDS protocol and to supply the requirements to be met
by the implementation of the management ECUs diagnostic.
This specification applies to all Automobiles PEUGEOT and Automobiles CITROEN vehicles.
HISTORY
Index Date Nature of changes
1.0 05/04/2013 Creation of a major baseline
2.0 01/12/2013 Rewording of the requirement Gen-CONFIG-ST-11,
Rewording of the requirement Gen-CONFIG-ST-14,
Paragraph 5.1.1.2: "MIL switched On" replaced by "SERVICE and STOP indicators blinking",
Gen-CONFIG-ST-114: adding of the example "for engine control unit, SERVICE and STOP
indicators blinking",
Paragraph 5.1.1.8: adding of a note,
Paragraph 4.1: Adding of CBVV, ID_TLC, ID_CAR in the glossary table,
Paragraph 5.1.1.3: replace "We suggest" by "The ECU shall implement",
Paragraph 5.1.1.4: rewording of the paragraph.
3.0 03/07/2014 - Update of applicable documents [10] for immo function.
- Gen-CONFIG-ST-106: Rewording, deletion of “fault is memorized” and “of them”, change of
“weakest” by “lowest”.
- Gen-CONFIG-ST-119: New requirement. Text changed in requirement.
- Gen-CONFIG-ST-120: New requirement concerning injectors characterization datas storing.
- Gen-CONFIG-ST-24: Adding of IUAV upstream requirement EX_GEN_IUAV_005(3).
- Gen-CONFIG-ST-71: Change of “turn on the EOBD lamp” by “blink the SERVICE and STOP
warning lights”.
- Gen-CONFIG-ST-114: Rewording by deleting the example specific for engine control units.
- Gen-CONFIG-ST-121: New requirement for specific case of engine control units (warning lights
SERVICE and STOP blinking for signalling a commissioning non-conformity).
- Gen-CONFIG-ST-122: New requirement for variant coding data order reading response
- Gen-CONFIG-ST-38: Following comment added to this requirement
- Paragraph 5.1.1.14: rewording of the paragraph
- Gen-CONFIG-ST-42: Deletion of this requirement which is redondant with Gen-CONFIG-ST-47
- Paragraph 5.1.2.1: rewording of the paragraph

02016_15_04619
1.0 DAE EMP2v3
5
Baseline : 3.0 31
2 SCOPE
Documentary diagram: in bold the coverage of the document.
(*): The PDX format is defined in document « Authoring Guidelines PSA » [12].
This document corresponds only to the integration of requirements linked to the Configuration and
maintenance generic mechanisms.
2.1General description of the system
This document contains requirements about :
- the procedure of configuration (variant coding, characterization of injectors) used in Factory
and After-Sales.
- the interfaces with diagnostic manager for the ECUs.
The development context of the system is defined in each paragraph of this document.

02016_15_04619
1.0 DAE EMP2v3
6
Baseline : 3.0 31
3 QUOTED DOCUMENTS
3.1Reference documents
3.2Applicable documents

02016_15_04619
1.0 DAE EMP2v3
7
Baseline : 3.0 31
4 TERMINOLOGY
4.1Glossary
5 REQUIREMENTS
5.1CONFIGURATION PROCEDURES
5.1.1 Secured Variant coding
5.1.1.1 General description
The variant coding does not call into question the use of the download in Flash Eprom as a software
transmission means, but complements it.
The general purpose is to significantly decrease the number of Hardware references and software freezes
of the series computers.

02016_15_04619
1.0 DAE EMP2v3
8
Baseline : 3.0 31
This principle allows the use of the same engine multifunction ECU (a single reference) with several
vehicles fitted with different hardware configurations. The ECU contains in memory an application
software (envelope software), and several calibration clearances selectable through the remote encoding
operation made in the assembly output or in after-sales.
To comply with the regulatory request, the implementation of a protection mechanism of the remote
encoded configuration has been decided. The purpose is to guarantee as a manufacturer that measures
have been taken against an "accidental" modification of the homologated configuration.
To do this, we will use a function similar to the one encoded in the computers within the software
download procedure (application and/or calibration). The encryption functions already implemented will
be made available, but the services will be specific to the protection of the remote encoded data (see
paragraph 7.1.10).
To not interfere with the production flow of our terminal plants (operations limited to the bare minimum
in order not to increase the range period), we have decided that the remote encoding of a computer
delivered non remote encoded (remote encoding number equal to 0) would remain possible without
preliminary use of the protection mechanism of the remote encoded configuration.
5.1.1.2 Control unit delivery requirements
Exi : Gen-CONFIG-ST-0 (1.0) Type :
Générique
Exi amont :
At delivery, the non variant coded control unit should be functional, the vehicle should run but for safety
reasons the control unit works in degraded mode to indicate to driver that variant coding was not carried
out again.
Générique
Exi amont :
The project is in charge to define the associated limp-home.
For example, with an engine control unit, the vehicle should run with a limited engine speed and also the
SERVICE and STOP indicators blinking.
Générique
Exi amont :
An associated fault code should indicate that the variant coding operation has not been carried out.
Générique
Exi amont :
A diagnostic service should not be able to delete the variant coding fault.
Générique
Exi amont :
At the time of the success of the variant coding operation, the control unit software automatically erases
the fault code associated with the operation present in memory and inhibit the associated limp home.

02016_15_04619
1.0 DAE EMP2v3
9
Baseline : 3.0 31
5.1.1.2.1Variant coding index
Générique
Exi amont :
A variant coding index called ID_TLC is written in the control unit memory (Flash Eprom) when the
latter is programmed (at the supplier at the time of the computer manufacture or by PSA when the ECU is
re-programmed).
Générique
Exi amont :
This variant coding index refers to the format of requests available in ODX files to be used for the
selected ECU.
Note: the factory or After-Sales tools could from this ID_TLC index (available with the variant coded
data read service) easily retrieve the format of the remote encoding parameters and services without
having to manage a list of control unit for each index of ODX file.
Générique
Exi amont :
On a request to write new variant coding configuration into memory, the ECU shall check that the variant
coding index received (also available in the write service) is the same as the index available in the
application software.
5.1.1.2.2Value of parameters at delivery
Générique
Exi amont :
The following value specifies defaults values for xPR variables for ECUs that are delivered by supplier
without variant coding:
- All programmed variables, xPR : 0xFF
- Variant coding number, NUM : 0x00
Générique
Exi amont :
Any control unit delivered in factory or in after-sales should have a CLEF_APPLI (see paragraph
5.1.1.10) different from 0xFFFF (for a flash eprom technology where the bytes are 0xFF after clearing).
This key which is also used for the protection of the download function is written in memory by the
control unit supplier.

02016_15_04619
1.0 DAE EMP2v3
10
Baseline : 3.0 31
5.1.1.2.3Configuration protection mechanism
Générique
Exi amont :
At delivery, when the variant coding number (NUM) is set 0x00, the variant coding operation should be
possible without preliminary use of the protection mechanism (see paragraph 5.1.1.10).
Générique
Exi amont :
When the variant coding number (NUM) is different from 0x00 and the ECU is unlocked, the ECU shall
reactivate the protection mechanism (ECU locked) by a cut-off of the +APC or the loss of the "main
wakeup" status for the RCD ECUs, or a change of session (due to change of session service or by the
timeout).
5.1.1.3 Description of the function
The ECU shall implement an EQUipment encoding area (Z.EQU) made up of two parts, the first
containing the possible variables (xPO = possibilities acknowledged by the software), the second
containing the variables programmed (xPR = choice made) that allows the storage of the following
information:
The format vary according to variant coding index

02016_15_04619
1.0 DAE EMP2v3
11
Baseline : 3.0 31
5.1.1.4 The possible variants
For each control unit, it is necessary to distinguish :
- the variants which are supported (xPO variables not impacted by the variant coding operation),
- the variants which are programmed (xPR variables written at the time of the variant coding operation).
Générique
Exi amont :
Each possible variables is represented with a 8 or 16 or 24 or 32 bits word and is used to define the
supported possible configurations.
Example:
Comment 1: It will be necessary to set to ‘1’ bits unused in possible variants.
Comment 2: The variant configuration diversity UC possible (UCPO) is a structure made up of several
fields. It will be necessary to set to ‘1’ bits unused in each field of the variant.
5.1.1.5 Encoding method
Générique
Exi amont :
The bits corresponding to the configurations that the control unit software is likely to support should be
set to "0".
Example :
Let’s assume that we have a control unit that supports for the gearbox variant, gearboxes 0 and
1(BVPO.0 & BVPO.1).
The encoding in flash eprom (partie I Z.EQU) should be the following BVPO = 0xFC
Générique
Exi amont :
These xPO type variables are not impacted by a variant coding operation. They are calibration datas
programmed by the supplier of the control unit, at the time of the download of the application software.
Générique
Exi amont :
The xPO variables are therefore accessible to the operator in read only mode and it must not be possible
to modify them.
5.1.1.6 The programmed variants
The programmed variants are of the same type as the possible variants, but we will set only one bit to "0"
in each programmed (variant coded) variant corresponding to a desired choice.

02016_15_04619
1.0 DAE EMP2v3
12
Baseline : 3.0 31
Comment: The structure UCPR is a sum of variants; therefore a bit set to "0" in each field will be
possible.
5.1.1.6.1Programmed variables
Générique
Exi amont :
The programmed parameters (xPR) are represented by a 8 or 16 or 24 or 32 bits word of the same type as
the possible configuration (xPO). For all xPR parameters except UCPR, a single bit will be set to "0" to
indicate the chosen configuration. Other bits shall be set to 1.
For UCPR, since it is a structure gathering different variants, a "0" in each of the diferent field shall be
accepted.
Example: the control unit accepts the gearboxes 0 and 1 and we would like to program it with gearbox 1.
We set the adequate bit to 0 and we get BVPR = 0xFD
5.1.1.6.2Remote encoding number
Générique
Exi amont :
The variant coding number (NUM) is managed internally by the electronic control unit.
Générique
Exi amont :
The ECU should update the variant coding number variable (incrementation by 1) in case of acceptance
of the request (after checks, see paragraph 5.1.1.7).
Générique
Exi amont :
The variant coding number (NUM) should be reset to 0x00 if the software update forces the variant
coding operation to be carried out again.
Générique
Exi amont :
When the variant coding number (NUM) equals 0x00, the variant coding fault should be present in the
ECU memory, the associated limp home should be activated.
Générique
Exi amont :
Deleted.

02016_15_04619
1.0 DAE EMP2v3
13
Baseline : 3.0 31
Générique
Exi amont :
When the variant coding equals 0xFF, the following variant coding operation will be accepted (if
accepted after checking by the ECU) but the NUM variable remains freeze.
5.1.1.7 Checks of variant coding parameters
Générique
Exi amont :
The ECU should guarantee that the remote encoding index of the parameters' write service is the same as
the one it has in memory and carry out the checking of the following logic functions :
xPO or xPR = xPR
With each xPR variable a single bit is set to "0".
For the structure diversity UC, the checks makes by field, the calculator must carry out the checking of
the following logic equation:
With for each field one and only one bit set to ‘0’, if it used.
Générique
Exi amont : EX_GEN_IUAV_005(3)
The ECU must also check that programmed configuration has been written in non volatile memory.
If these tests are checked and if the configuration is reread in non-volatile memory, we consider that the
remote encoding has been successfully completed. In this case, any anti-scanning delay is inhibited.
Otherwise, the control unit will reply to the write service of the frame to remotely encode by a frame of
the type “negative response” (see paragraph 5.1.1.12).
5.1.1.8 Interfunctionnal
The control unit's variant coding is done if the vehicle dynamic conditions are safety (for example for a
CMM engine stopped).
Générique
Exi amont :
All requests for unlocking the variant coding function while the vehicle dynamic conditions are not
safety, should get a response of the negative type "ConditionsNotCorrect".
NB: The negative code response “conditionsNotCorrect” must be replaced by a negative response code
more detailed if the information is available.

02016_15_04619
1.0 DAE EMP2v3
14
Baseline : 3.0 31
Générique
Exi amont :
All requests for writing a configuration in memory while the vehicle dynamic conditions are not safety,
should be rejected by the ECU.
Générique
Exi amont :
If the control unit detects a loss in the Eeprom memory of the area which contains the programmed
variant coding data, the ECU should consider that the variant coding is no longer operable and should
reset itself to the delivery status (see paragraph 5.1.1.2).
5.1.1.9 Sequence of variant coding procedure
(*) : Operation no necessary when the variable NUM=0x00.
5.1.1.9.1Phase 0, preparing for variant coding
The variant coding parameters are stored in DOTEs (Variant coding data table) and archived in a
database (Borneo or CADOT for the after-sales). A DOTE is linked to a software reference linked itself
to a functional product reference.
However, the variant coding parameters can also be defined manually by an user of the tool.
5.1.1.9.2Phase 1, entry in extended session
The entry in extended session carries out thanks to DSC service (see document [3]).
Générique
Exi amont :
Deleted.
5.1.1.9.3Phase 2, using the protection mechanism
The use of the protection mechanism is not compulsory at the time of the first variant encoding (control
unit delivered non variant coded or without the update of the software which requires a new varaint
coding operation).

02016_15_04619
1.0 DAE EMP2v3
15
Baseline : 3.0 31
5.1.1.9.4Phase 3, variant coding
The variant coding tool prepares the write request according to the variant coding index and the
parameters to send (the writeDataByIdentifier service is described in document [3]).
5.1.1.9.5 Phase 4, checks
The control unit carries out the checks described in paragraph 6.1.7 before declaring as valid the variant
coding operation (the declaration is valid on acceptance of the positive response to the write service, see
paragraph 5.1.1.7).
5.1.1.9.6Phase 5, end of communication
A transition to the default session ends the procedure.
Générique
Exi amont :
Deleted.
5.1.1.10 Protection mechanism
The protection mechanism of the vairant coded configuration is of the same nature as that used for the
protection of the access to the code within the files download procedure.
The “Unlocking” of the ECU is carried out by two request/response couples between the tool and the
control unit. The detail of mechanism is described in document [3].
The authentication of the tool is ensured by the encryption of a “Seed” (random seed). This encryption is
carried out jointly by ECU and by the tool.
TECHNICAL DETAILS
“Seed” generation by the ECU:
The “Seed” is a number encoded on 4 bytes. Its composition is detailed in documents [8] and [9].
Calculation of the result by the tool and the ECU:
The encryption function used is the same as that which is already used for the protection of the code
downloaded in a control unit.

02016_15_04619
1.0 DAE EMP2v3
16
Baseline : 3.0 31
The calculation of the result is made with the same CLEF_APPLI variable as the one used for the
downloading function.
It is available both in the control unit and in each download file (S1 header frame) for the application of
the download procedure for the security ECUs.
Générique
Exi amont :
When the CLEF_APPI value stored in the control unit equals 0xFFFF (case of the delivery of the
ETUDE ECU), the protection mechanism is inhibited and the configuration change possible, irrespective
of the values of the parameters KEY1, KEY2, KEY3 and KEY4 sent by the tool.
Générique
Exi amont :
When the CLEF_APPLI value stored in the control unit equals 0xFFFF no anti-scanning timeout of 10
seconds (see document [3]) should be activated, irrespective of the values of the parameters KEY1,
KEY2, KEY3 and KEY4 sent by the tool.
5.1.1.11 Reading command of variant coding parameters
This service will be used to read the information linked to the variant coding of the control unit (possible
variants and programmed variants). See in the ODX file of project the “read data by data identifier”
service in DID $2100 and $2101.
Générique
Exi amont :
When the tool sends a variable with a length higher than a byte, the low-byte (LSB) should be sent first,
followed by the high-byte (MSB).
5.1.1.12 Writing command of variant coding parameters
The write service allows the configuration of the calculator, namely to make a choice on each variant.
See in the ODX file of project the “write data by data identifier” service the DID $2101 for the
programmed configuration data.
Générique
Exi amont :
The writing in memory of the ECU of the configuration should be possible without preliminary use of the
requests associated with the protection mechanism when the NUM variable equals 0x00.
Générique
Exi amont :
When the tool sends a variable with a length higher than a byte, the low-byte (LSB) should be sent first,
followed by the high-byte (MSB).
Générique
Exi amont :
When a variable is not used in an application (because there is no associated diversity) the corresponding
value in the write request frame is filled in with 0xFF because all the bytes are mandatory.

02016_15_04619
1.0 DAE EMP2v3
17
Baseline : 3.0 31
Générique
Exi amont :
The ECU must respond RequestOutOfRange (NRC $31) if DID contained in write request is out of range
or if data associated with DID is not valid.
Comment : for the checks made on the data associated with DID, see paragraph 5.1.1.7.
Générique
Exi amont :
The ECU must respond securityAccessDenied (NRC $33) if NUM is different of $00 and that the ECU
was not previously unlocked with SecurityAccess service.
Générique
Exi amont :
The ECU must respond generalProgrammingFailure (NRC $72) if it detects an error (for example : an
error of writing in RAM) when programming in a memory area of the ECU.
Générique
Exi amont :
The calculator must respond ConditionsNotCorrect (NRC $22) if safety conditions are not met.
The negative response “ConditionsNotCorrect” is to be changed by a code more detailed if information is
available (NRC $80 to $FF).

02016_15_04619
1.0 DAE EMP2v3
18
Baseline : 3.0 31
5.1.1.13 Flow chart of variant coding writing request

02016_15_04619
1.0 DAE EMP2v3
19
Baseline : 3.0 31
5.1.1.14 Post-equipment specific requirements
5.1.1.15 Secured variant coding of post-equipment parameters for ABS-ESP
5.1.2 Injectors characterization
5.2DIAGNOSTIC MANAGER FOR NO POWERTRAIN AND NO OBD ECU
5.2.1 Faults memory
5.2.1.1 Size of memory
Générique
Exi amont :
The calculator sends a maximum of 10 DTC on after-sales tools.
Comment: It is possible to have several failures for a same DTC.
Générique
Exi amont :
For each fault the ECU shall store a fault code, its status, DTC Aging counter and DTC snapshot record
data linked to DTC.
Comment 1 :
For each recording fault, the supplier is free to store additional information for its own needs.
Comment 2 :
Each fault contained in memory has its own fault code and associated status, its own aging counter and
its own snapshot data. These data are not shared between several faults.
5.2.1.2 Type of memory used
The type of memory used to store fault codes and associated information is in non volatile memory.
Générique
Exi amont :
Each DTC must be managed (recording, clearing…) apart from others faults stored in memory.
5.2.2 Clearing faults
There are several possibilities to erase the faults stored in the ECU’s memory.
5.2.2.1 Automatic clearing
To avoid loading unnecessarily the memory, the history of the faults is limited to 40 operation cycles
consecutive without new occurrence of the fault.

02016_15_04619
1.0 DAE EMP2v3
20
Baseline : 3.0 31
Générique
Exi amont :
If the bit 2 (pendingDTC) and the bit 0 (confirmedDTC) of statusOfDTC are set to 0 since more 40
operation cycles consecutives then the calculator clears automatically the whole information linked to
DTC and reinitialize the status of DTC.
5.2.2.2 Forced clearing
5.2.2.2.1Diagnostic tool request
The diagnostic tool can force the clearing information related to DTC by sending to ECU a clear request
(see document [3]).
Générique
Exi amont :
On receipt of a clear diagnostic information request, the control unit must return in nominal mode
(rehabilitation of degraded modes).
Générique
Exi amont :
The clear diagnostic information request must follow the reception of the request sent by the diagnostic
tools. It should not be necessary to make a reset of the calculator to cause the release of the memory.
Générique
Exi amont :
The clear diagnostic information request should not be conditioned by the preliminary reading of the
memorized defects.
5.2.2.2.2Frame « integration electronic » (CAN identifier : 092h)
The « electronic integration » input/output frame (described in the document [4]) allows burst clearing of
the faults codes of all the calculators connected to the network CAN I/S.
Générique
Exi amont :
When the control unit receives an “integration electronic” frame in which option CLRDTC is selected,
the calculator must erase the whole information associated with the DTC
Générique
Exi amont :
When the calculator receives an “integration electronic” frame in which option CLRDTC is selected, the
calculator must return in nominal mode (rehabilitation of the degraded modes and help).
Exceptions :
Some DTC (see requirements GEN-CONFIG-ST-114), which are used like flags showing that an
operation is not carried out, are not cleared in the case describes above paragraph 5.2.2. (frame or
request).

02016_15_04619
1.0 DAE EMP2v3
21
Baseline : 3.0 31
The erasing conditions of these DTC are described in paragraph 5.4.2.
5.2.3 DTCAgingcounter
The DTC Aging counter (erase counter) is associated to each stored DTC.
Générique
Exi amont :
The DTCAgingCounter is set to 40 when the pendingDTC and the confirmedDTC (respectively bit 2 and
bit 3 of statusOfDTC) switch to ‘1’.
Générique
Exi amont :
The DTC Aging Counter decrements after completing an operation cycle in which test did not fail (see A,
C and D).
See the statusOfDTC definition in document [3].
Générique
Exi amont :
When the counter (DTC Aging Counter) reaches the value 0, the calculator must clear automatically all
information linked to DTC (DTCsnapshotrecord, counter, status) (see E and F).
Générique
Exi amont :
Before than DTCAgingCounter reaches 0 if testFailed (bit 0 of statusOfDTC) switch to ‘1’ then the
counter reset to 40 and the pendingDTC (bit 2 of statusOfDTC) set to ‘1’.
Comment 1:
The rehabilitation of the degraded modes (or recovery modes) can be managed independently of the
aging counter. For example, the limp-home can be rehabilitated before the aging counter reaches 0 and
that the DTC doesn’t disappear from the memory of the defects.
The below diagram shows the DTCAgingcounter operations according to the bits of statusOfDTC.

02016_15_04619
1.0 DAE EMP2v3
22
Baseline : 3.0 31
A DTCAgingCounter is decremented after completing an operation cycle in which test did not fail
B pendingDTC is set to zero after test completes and passed, if test did not fail during the last
completed operation cycle
C DTCAgingCounter is decremented after completing an operation cycle in which test did not fail
D DTCAgingCouter continues to decrement because test is not failing during these operation cycles
E confirmedDTC set to zero when aging criteria is fully satisfied (DTCAgingCounter reaches a
specific value 0)
F DTCAgingCounter reaches 0 at which time the confirmedDTC bit is cleared
5.2.4 Read faults codes by status mask
The diagnostic tool can read the faults code and their status stored in the memory of the ccontrol unit by
sending the read DTC information request with the ReportDTCByStatusMask sub-function (see
document [3]).

02016_15_04619
1.0 DAE EMP2v3
23
Baseline : 3.0 31
Générique
Exi amont :
On receipt of read DTC information service from diagnostic tool, the control unit sends all DTC which
have one of the bit from statusOfDTC matching to DTCStatusMask from tool, even the faults appeared
during the operation cycle in progress.
Générique
Exi amont :
If during the reading of the DTC, occurs a new fault, this one will be taken into account by the control
unit but will be visible only during the next reading of the defects.
5.2.5 Management of faults memory
5.2.5.1 Storage of faults codes
Générique
Exi amont :
When the confirmedDTC switch to ‘1’ (bit 3 of StatusOfDTC), the whole of information associated with
the DTC (status, snapshot data) must be stored in the fault memory of the control unit. If the memory is
saturated then apply requirement GEN-CONFIG-ST-106.
Générique
Exi amont :
Whenever the moment when main wale up information is lost (or the +APC), the control unit must
guarantee that the faults confirmed present during the operation cycle will be saved in nonvolatile
memory.
5.2.5.2 Induced faults
Some faults (known as inductors) can cause the appearance of new faults (known as induced) whose the
presence obstruct the memory unnecessarily and does not bring significant assistance to the repairing
service.
Générique
Exi amont :
PSA requires the supplier to filter by software the faults identified as being induced by other faults.
Comment: The supplier will communicate to PSA the list of faults concerned
5.2.5.3 Storage faults during a diagnostic session
The detection of certain faults could be inhibited during the execution of certain diagnostic commands.
Example: During a sequence of piloting of the actuators, the application software of the logic controller
must inhibit the diagnosis of outputs temporarily in order to avoid to them false detections of faults.

02016_15_04619
1.0 DAE EMP2v3
24
Baseline : 3.0 31
5.2.5.4 Memory full
Procedure to be followed when the faults memory is full:
Générique
Exi amont :
When the faults memory is saturated and that a new fault appears:
Case n°1: If all the faults stored in the memory of the control unit are their DTC Aging counter = 40, we
erase:
- the fault with the lowest priority (*),
- if they are several, the last memorized fault.
Case n°2: If there is at least one defect whose the DTC Aging Counter is different from 40 in the
memory of the control unit, among these faults we erase:
- the fault with the lowest priority (*),
- if they are several, that whose aging counter is weakest,
- if they are several, the last memorized fault.
(*): If a level of priority exists between the various categories of faults.
5.2.6 DTCSnapshotRecordData
5.2.6.1 Definition
The DTCSnapshotRecordData are composed of the environment parameters (physical measurements)
memorized from the occurence of a fault (ex: speed vehicle, engine speed…). This information brings a
help to the repairing by indicating the circumstances of the appearance of the fault.
The number and the nature of the parameters of SnapshotData are defined by each project. They can be
identical for all the faults, or specific to a group of faults even to each fault.
Générique
Exi amont :
The control unit must capture the DTC snapshot record data seen during the first occurrence of the fault
(before filtering and confirmation).
The purpose is to obtain environment the most representative during the occurrence.
Générique
Exi amont :
The parameters of DTCSnapshotRecordData should not be updated when the DTCAgingCounter linked
to DTC decrements.
Générique
Exi amont :
The parameters of DTCSnapshotRecordData should not be updated when DTCAgingCounter linked to
DTC switch again to 40 (testFailed is set to ‘1’).
The reading of these snapshot is done using the read DTC information service with the sub-function
ReportDTCSnapshotRecordByDTCNumber (see document [3]).

02016_15_04619
1.0 DAE EMP2v3
25
Baseline : 3.0 31
5.3ALLOCATION OF CAN FRAME IDENTIFIERS FOR USE of CAN CCP/XCP
PROTOCOL
5.3.1 Purpose
The purpose of this paragraph is to define the CAN identifiers which are reserved for the CAN CCP or
XCP protocol needed for development, validation and expert assessment of a PSA series ECUs.
5.3.2 Problem
The problem is PSA’s method of allocating its CAN identifiers for intersystems messaging, given:
- use of the 11-bit physical addressing in use,
- the number of controllers connected to the CAN network,
- migration of controller communication from the serial bidirectional K line (complies with ISO14230)
to the CAN bus (ISO15765), where the choice of identifiers has had to be made according to “gaps”
available in the existing functional messaging, and according to defined priorities,
- the renewal of transverse controllers fitted to virtually all of our vehicle range,
- the desire to organize a packet messaging system where identifiers defined for one vehicle are retained
over all those to which the product is fitted so as not to create additional diversity,
- the requirement upon us to guarantee the uniqueness of all CAN identifiers for a vehicle,
We cannot meet the current requirement from our controller suppliers to reserve a number of identifiers
for the use of the CAN CCP/XCP protocol for each controller connected to the CAN network.
However, the real need to have a number of communication protocols (CAN CCP/XCP and ISO15765)
coexist alongside the different tools connected to the vehicle’s central diagnostics connector leads us to
propose the solution which is set out below.
5.3.3 Recommended solution
In operation, the CAN CCP/XCP protocol requires two identifiers for tool/controller requests and
responses, and up to four additional identifiers to be used by the controller to send physical reading
parameters.
The solution consists in allowing the use of the same identifiers within a single controller for requests /
responses both for the CCP/XCP protocol and for the ISO15765 protocol; however, for this to work, they
will need to be swapped.
Générique
Exi amont :
The frame identifier used by the tool to send a request to the controller under ISO15765 will also be used
by the controller to respond to the tool’s request via CAN CCP/XCP.
This idea is more easily understood through the following two diagrams:
The case of a motor controller using identifiers 0x6A8 and 0x688

02016_15_04619
1.0 DAE EMP2v3
26
Baseline : 3.0 31
Protocole ISO15765 :
Protocole CAN CCP/XCP :
Important: the need for the protocols to coexist side by side within a single ECU does not imply that they
can be used simultaneously, given that only a single tool can be connected to the network. In other
words, with such a system, it is perfectly possible to use either one or other of the communication
protocols alternately.

02016_15_04619
1.0 DAE EMP2v3
27
Baseline : 3.0 31
Générique
Exi amont :
It is necessary to develop an auto-detection function for each onboard controller, to detect the protocol
being used by the tool according to the frame identifier sent to open the session. Such a function can be
represented by the following flowchart:
Example: processing of a request in the case of a motor controller using identifiers 0x6A8 and 0x688.

02016_15_04619
1.0 DAE EMP2v3
28
Baseline : 3.0 31
This principle makes it possible to obtain a level of priority which is to all intents and purposes
equivalent between the requests sent, whichever protocol is being used over the CAN bus (0x6xx in the
context of our motor controller example), such that requests coming from the tool have the least possible
influence on functional exchanges between controllers.
Identifiers assigned to the CAN CCP/XCP protocol with thus be defined within the same ranges as those
which have been chosen for series tools. These identifiers are specified in each intersystems messaging
setup for the unit concerned.
Générique
Exi amont :
Where the additional frames required by the CAN CCP/XCP protocol for readings are concerned, the
following frame identifiers shall be used, regardless of the controller:
- 0x7CC (IS_REP1_OUTIL_PRTCLE_CCP_7CC),
- 0x7CD (IS_REP2_OUTIL_PRTCLE_CCP_7CD),
- 0x7CE (IS_REP3_OUTIL_PRTCLE_CCP_7CE),
- 0x7CF (IS_REP4_OUTIL_PRTCLE_CCP_7CF).
It should be noted that these frames can only be sent by a controller from the moment that a CAN
CCP/XCP communication session becomes active.
Example for a motor controller:
- Sync frame: 0x7CC,
- 10 ms frame: 0x7CD,
- 100 ms frame: 0x7CE,
- 1000 ms frame: 0x7CF.
5.4FAULT MANAGEMENT
5.4.1 Details on clear DTC information
Générique
Exi amont :
Generally speaking, DTC information are cleared using four possible mechanisms:
 clearance request by OBD service from a Scan Tool or an After-Sales tool. The request and the
actions it triggers as defined in document [24].
 clearance request by diagnostics service from an After-Sales tool. The request and the actions it
triggers as defined in document [3].
 automatic clearance mechanism. The associated actions are defined by the TS [6] for OBD ECU
or paragraph 5.2 for no OBD and no powertrain ECU.
 delivery of a “electronic integration” frame with the option “clearing faults” selected in
accordance with the document [4].
Some special fault codes are provided that come under none of these mechanisms. They and their
clearance mechanisms are described in this document.

02016_15_04619
1.0 DAE EMP2v3
29
Baseline : 3.0 31
5.4.2 Signalling a commissioning non-conformity
To be conform and operational, the ECU must be configured to the vehicle it is fitted. A signaling is
provided if this has been overlooked.
Générique
Exi amont :
A warning light or a message must be displayed by ECU on the vehicle's instrument unit in the following
cases:
- download not performed
- variant coding not carried out,
- learning not performed (by request),
- power-latch not performed.
A DTC is associated at each situation. Each DTC (as many DTC as of learning to be realized) is
automatically erased by the software only when the operation is carried out successfully. None of these
DTC can be erased by a clear request sent by a tool.
5.5Operational requirements
5.5.1 Mission profile
Not applicable
5.5.2 Service life
Not applicable
5.5.3 Fail safe operation
5.5.3.1 Reliability
5.5.3.2 Maintainability
Not applicable
5.5.4 Product quality
Not applicable
5.5.5 Protection against hostility
Not applicable
5.5.6 System resources
Not applicable

02016_15_04619
1.0 DAE EMP2v3
30
Baseline : 3.0 31
5.5.7 Documentary requirements
Not applicable
5.6Constraint requirements
5.6.1 Regulation and consumerism
Not applicable
5.6.2 Weight and other physical specifications
Not applicable
5.6.3 Design and manufacturing
5.6.3.1 Studies and/or imposed solutions
Not applicable
5.6.3.2 Materials
Not applicable
5.6.3.3 Manufacturing
Not applicable
5.6.3.4 Marking of the products
Not applicable
5.6.4 Traceability and configuration management
Générique
Exi amont :
The project will record the requirements of this document in the model of the
table below and will indicate in the corresponding box if the requirements are accepted, validated or
derogated:

02016_15_04619
1.0 DAE EMP2v3
31
Baseline : 3.0 31
5.6.5 Transportability, storage and packaging
Not applicable
5.6.6 Flexibility and extension
Not applicable
5.6.7 Withdrawal from service
Not applicable
5.6.8 Environment conditions
Not applicable

02016_15_04619_1.0_DC_TI_703_TS_UDS_Configuration_Baseline_3_0_Filtre_DAE_EMP2v3_31072015.doc

Recommended

Recommended

More Related Content

Similar to 02016_15_04619_1.0_DC_TI_703_TS_UDS_Configuration_Baseline_3_0_Filtre_DAE_EMP2v3_31072015.doc

Similar to 02016_15_04619_1.0_DC_TI_703_TS_UDS_Configuration_Baseline_3_0_Filtre_DAE_EMP2v3_31072015.doc (20)

More from azrfdstgdgdfh

More from azrfdstgdgdfh (20)

Recently uploaded

Recently uploaded (18)

02016_15_04619_1.0_DC_TI_703_TS_UDS_Configuration_Baseline_3_0_Filtre_DAE_EMP2v3_31072015.doc