Mastère Professionnel Co-

Construit M2 Ingénierie
Automobile et Aéronautique

Automotive
Technologies

Omar Triki Lecture 5 2023-2024

The error codes (DTCs) used today are based on the flashing codes of control units that were measured
by counting. With the increasing complexity of electronics and thus more and more complicated error
conditions, such proprietary diagnostic procedures are no longer sufficient. Thus, the development led to
the currently known 2-byte (OBD legislated codes) and 3-byte DTCs (UDS standardized).

With the data obtained during diagnosis, the cause of the fault and its effect on vehicle functions can be
analyzed. This is done in order to enable efficient and effective troubleshooting and to be able to
continue to operate or repair the vehicle, possibly with restrictions.

Due to the existing cost pressure, it makes sense for vehicle manufacturers and their suppliers to
cooperate and use common exchange formats. Furthermore, the diagnostic content is not being defined
and developed in a unified and standardized format. In most cases, the data is defined in vendor-
specified tooling formats. However, OEMs are increasingly realizing the need for data standardization
and aligning their development strategies with industry-defined standards like the DEXT format of
AUTOSAR and, for off-board diagnostics, the comparable ODX format of ASAM.
Classic Autosar
Diagnostic Flow

Autosar Software Layers

Diagnostic Flow over Autosar Software

Layers
Within the AUTOSAR framework, there are several key components or modules, including diagnostic
components, that play a critical role in ECU software. The main diagnostic AUTOSAR components
implemented in an ECU software are:

 Diagnostic Communication Manager (DCM): DCM is a core module in AUTOSAR responsible for
managing communication between an ECU and external diagnostic tools. It handles diagnostic
protocols such as UDS (Unified Diagnostic Services), OBD (On-Board Diagnostics), and more. DCM
provides services for reading and clearing diagnostic trouble codes (DTCs), as well as performing
other diagnostic tasks.

 Diagnostic request handling is performed by DCM module

 DCM validates incoming request, and process valid/invalid request by means of positive/negative
response
 DCM check security level and session access
 Check service is supported or not
 Validate length
Diagnostic Communication Manager (DCM)
has the following sub parts:
 Diagnostic Session Layer (DSL):
 Implement concurrent tester present logic
 Keep track of current session
 Handling different diagnostic protocols
 Responsible for pending response handling NRC
0x78
 Protocol timing parameters P2 and P2*
 Diagnostic Service Dispatcher (DSD):
 Check security and session access of incoming
request
 Send positive/negative response or suppress
response
 Check whether service is supported or not
 Collect positive/negative response form DSP, adds
diagnostic service identifier and response data
returned by application and forward diagnostic
response message to DSL.
 Diagnostic Service Processor (DSP):
 Once the message is received from DSD, it checks
the message format (NRC 0x13)
 Check sub function supported or not (NRC 0x12)
 Service implementation
 Diagnostic Event Manager (DEM): The DEM monitors and manages diagnostic events and
diagnostic processes in the ECU. It handles the event memory and diagnostic data processing,
including the decision to set, store, or clear DTCs. DEM is closely related to DCM, as it provides the
data that DCM needs to report to external diagnostic tools.

DEM has the following functionalities:

 Diagnostic event processing
 Storing event related data in memory
 Read event related data from memory
 DEM module defines DTCs. DTCs are
associated to events (e.g. event of sensor
fault).
 SWC or BSW modules can report event
status to DEM module.
 Events reported to the DEM, need to be first
qualified to ensure that whether it is a fault
(failure of a component) or just an occurrence
(irregular system behavior).
After the event is qualified, DEM records the event data and communicates with DCM for event handling
and FIM for functional control. If event fails, DEM will set DTC status byte and request NVM to store event
and event related data to NVM.
SWCs communicate with DEM module
through RTE, using Client Server port or
Sender receiver port.

SWC communicates to report status of

event to DEM and DEM reads data from
SWCs to collect snapshot data.

DCM module communicates with DEM

and vice versa using AUTOSAR interface
to read Diagnostic information (i.e.
Service No. 19 Read DTC status or Read
Snapshot data).

DEM communicates with NVM using

AUTOSAR interface. DEM uses NVM to
read and write diagnostic information into
memory.

Other BSW modules communicates to

DEM module to report BSW event status
whether event is passed or failed.
Battery Example
Consider a software component which monitors a health of battery (monitored by monitor function) .

One diagnostic event is associated with battery health. Monitor function will report a status of event to
DEM.

Event id is assigned to an event (This event id is unique per event). Event ids are assigned by DEM
module.

SWCs or BSW modules reports event status to DEM using event id. e.g. event id 27 is associated with
battery health event.
Diagnostic trouble code (DTC) is associated with an event. When event is reported as passed or failed,
status of DTC changes. DCM uses DTC number to read information about diagnostic event and DTC (e.g.
19 02 or 19 04 service). e.g. DTC C08088 is assigned to event battery health. As per UDS (ISO 14229)
protocol, DTC status is stored in a byte called DTC status byte.

In short, monitor function (a runnable entity in SWC) monitors an event and reports event status to DEM
module (event passes/failed) through RTE call. Based on event status DTC status changes.

AS per ISO14229-1 for each diagnostic event, DEM module maintains a UDS DTC status byte information.
Diagnostic Events

The events of the monitors are assigned to the specific DTC and are transported to the DM via Middleware.
Error codes are primarily intended for the Aftersales Service and depend on the respective diagnostic
strategy. Typically, the OEM determines the DTC to be used uniformly for its vehicles.

Several events can also be assigned to the same DTC. The two events “EventOverVoltage” and
“EventUnderVoltage” could be assigned to two different DTCs or have only one common DTC, such as
“PowerSupply”.

An authoring tool should link the events of the monitors with the DTC of the respective OEM for an ECU.
Since not every monitor has to send an event, but every DTC in DM needs at least 4 bytes of memory,
unused DTC must be removed.
There are three types of event debouncing mechanism provided by DEM module.
1. Time Based Debouncing
2. Counter Based Debouncing
3. Monitor Internal Debouncing

Time based and counter based debouncing is implemented by DEM, while monitor internal is implemented
by software component. Event is tested and considered as failed if debouncing condition mentioned above
(maturation criteria) is satisfied.

Debouncing of the events

Not every small fault should immediately generate a DTC and thus trigger the associated fault reaction. If, for
example, the battery voltage is too low for a few seconds, then switching off the ABS is simply an
overreaction. For this reason most events are debounced.
After all there are three different strategies, which differ considerably in their definition.
Time-based debouncing:
In this case, an error must be present for a certain time in order to become effective as DTC (Confirmed).
Counter-based debouncing:
Here an error counter is incremented with different step sizes up to 127 for “Confirmed” or down to -128 for
“Passed”. This way a precisely granular de-bouncing behavior can be modulated.
Internal debouncing:
There is no debouncing by the DM and the monitor delivers already de-bounced events.
In addition to the 3 debouncing strategies described above, there are numerous other settings in DEXT
which influence the exact behavior of a DTC. Examples are the saving of the debounce counter in non-
volatile memory, the reset of the debounce counter at ClearDTC and the reset at a new operation cycle.
Function deactivation, Function Inhibition Manager (FIM)

If a DTC is stored as confirmed, the vehicle must react appropriately to this error. The vehicle manufacturer
analyses such faults and their effects during the development of the vehicle. This is typically described with
the aid of an FMEA (Failure Mode and Effects Analysis) and the corresponding reactions of the vehicle are
deter-mined. The FIM ultimately implements the parts of the FMEA in the control unit.

The Operation-Cycle

The operation cycle is a defined cycle in the vehicle and the pulse for DTC. It ensures that DTC are created
and also recover again.

Driven and dependent on this pulse, each DTC has a dynamic status defined in ISO 14229-1:2013 (UDS
standard). Bits 0 to 6 of the StatusOfDTC describe where the

DTC is currently located in its life cycle.

In ISO14229-1 DTC status byte is defined. Bit 0 to Bit 7 represents DTC status. Test Failed means monitor
has evaluated error condition and debouncing is performed (i.e. maturation criteria is met)

Bit 0 : Test Failed

Bit 1 : This Failed This Operation Cycle
Bit 2 : Pending DTC
Bit 3 : Confirmed DTC
Bit 4 : Test Not Completed Since Last Clear
Bit 5 : Test Failed Since Last Clear
Bit 6 : Test Not Completed This Operation Cycle
Bit 7 : Warning Indicator Requested
DTC Readout: The ECUs respond to the request by providing a list of DTCs that may be present in
the vehicle's control systems. These DTCs can be categorized into different states, including:

• Confirmed DTCs: These are fault codes that have been detected and verified as active faults in
the vehicle's systems. They represent current issues that need attention.
• Pending DTCs: Pending DTCs are potential issues that have been detected but have not yet
been verified as active faults. They may require further monitoring or testing to confirm if they
should transition to confirmed DTCs.
• Historic DTCs: Historic DTCs are codes for faults that were previously present but have since
been resolved or are no longer active. These codes are stored for reference and historical
analysis.

DTC Status Transition: DTCs can transition between these states based on the vehicle's operation
cycle and diagnostic tests. Here's a general outline of how this transition can occur:

• Detection: When a fault is detected by an ECU, it may initially be categorized as a pending

DTC because the fault needs further confirmation or monitoring.
• Confirmation: If the fault is confirmed through additional tests or after a specific number of
drive cycles, it can transition from pending to confirmed status.
• Resolution: When the fault condition is no longer detected and verified through subsequent
tests or drive cycles, a confirmed DTC can transition to historic status.
The error memory (Event-Memory)
An error code with status is only
sufficient for simple errors. For more
complex errors, the environmental
conditions such as speed, temperature,
velocity and possibly other internal
information are also required for a more
precise analysis of an error.

DTC Snapshot Data (FreezeFrames)

The retrieval of measured values is
already possible without DTC via the
ReadDataByIdentifier UDS service. For
a meaningful analysis, the measured
values must also match the exact time
of the triggering event. If a monitor
reports “Failed”, the relevant DIDs are
temporarily stored with their measured
values.
The data structure of a snapshot record corresponds to a sequence of individual DIDs from the
ReadDataByIdentifier service. There is a large overlap with ODX. If the DID used for a DTC and their data
structures are known, the ODX data for readDataByIdentifier and readDTC can be generated from the DEXT
information and vice versa.
Extended Data

The Extended Data Block contains

additional information about a DTC such
as cycle counters, aging counters, time
of last occurrences, … and dynamic
data of algorithms that are not already
contained in the FreezeFrame data.
Similar to the DIDs, a 1-byte record
number specifies the data structure of
the Extended Data block.

Up to 255 stored ExtendedDataRecords can exist for a DTC. The interpretation of the data is unambiguously
determined by its RecordNumber.

The description of snapshot data and extended data are in principle very similar for ODX and DEXT. There
is, however, a large amount of additional information in DEXT, such as severity, debouncing, malfunction
indicator, function inhibit, which is not contained in ODX, but is mandatory for a DTC in an ECU.

The last step on the way to the tester is the DCM, which is responsible for encoding and transmitting the
data to the tester. With the ReadDTC (0x19) UDS service, a DTC is encoded as a two or three-byte value
according to the set DTC format and transmitted via the vehicle bus.
When event is failed then event related data can be stored into NVM. ISO14229-1 defines two kinds
of event specific data : 1. Snapshot data 2. Extended data. When battery health monitoring DTC is set,
you may want to store battery voltage, battery current, this is what snapshot data.

To store snapshot data and extended data trigger is required. Trigger condition can be when test failed
bit is set or confirmed DTC bit is set.

Freeze frame/Snapshot data contains a DID or multiple DIDs. DID is a number assigned to identify a data.
When DTC is set and data need to store into NVM. Data is battery voltage and battery current. Then one
DID is assigned to battery voltage (e.g. DID FD22) and one DID is assigned to battery current (e.g. DID
D025).

Size of DID is user defined. It may be 1 byte or may be 8 bytes. These DIDs are assigned to snapshot
data/freeze-frame. Freeze-frame may have a number associated with it (Depends on configuration). DIDs
are required for Extended data also.

When Snapshot data need to store into memory, from where it is collected?
Snapshot data is made-up of DIDs. So DEM (BSW) will read each DID from application using client server
port interface and DEM will act as client and application as server.

To set an event client server port interface is used. DEM acts as server while SWC acts as client. SWC uses
DEM API Dem_SetEventStaus() to report an event status to BSW.