What is Diagnostics?

Diagnostics in automotive is a digital analysis of your vehicle’s various computer

systems and components. Vehicle diagnostic tests scan your car's components and
systems to check for issues with components like the engine, transmission, oil tank,
throttle, and many more.

What is AUTOSAR?

AUTOSAR is an open system architecture to support automotive OEMs and Tier-1

suppliers to improve ECU Software quality, reduce development costs, and avoid re-
development of similar ECU software components repeatedly for the same vehicular
applications. It is a growing and evolving standard defining a layered architecture for
software.
Why • Hardware- and software is independent of each other.

AUTOSAR? • Development processes is simplified. This reduces development

time and costs.

• Reuse of software is increased at OEM as well as at suppliers.

This enhances quality and efficiency
AUTOSAR Layered Architecture
Diagnostic Stack in AUTOSAR

-> The Diagnostic Event Manager (Dem) is responsible for processing and
storing diagnostic events (errors) and associated Freeze Frame data
-> The Diagnostic Communication Manager(DCM) provides a common
API for diagnostic services. DCM also implements UDS and OBD
standards.
-> All detected development errors in the Basic Software are reported to
Default Error Tracer (Det).
-> The module Diagnostic Log and Trace (Dlt) supports logging and
tracing of applications. It collects user defined log messages and converts
them into a standardized format.
-> FIM is responsible for providing a control mechanism for software
components and there functionality
Dem : Diagnostic Event Manager

Dem is
responsible for
It offers
processing and It stores faults
It provides fault interfaces to the
storing and related
information to application layer
diagnostic data into
the Dcm and to other
events (errors) memory
BSW modules.
and associated
data.
Important terminologies in Dem with a use case:
• A car is started by turning ignition key from off to on (This is start of an operation cycle), the car is travelling on a
highway, Suppose the car meets with an accident and suffers some small damage, for example the speed sensor got
damaged.

• The damage of the sensor is considered as a diagnostic event, there is a specific fault code for each event or a
failure , this code is termed as DTC( Diagnostic trouble code).

• Stopping of car by turning ignition key from on to off is termed as end of operation cycle.
• Every event is identified with a unique id i.e Event ID, every event is mapped to a DTC.

• The C function which handles the functionality of the sensor is termed as a Monitor.

• The vehicle conditions like speed, voltage, other sensors related data are stored at the time of fault is known as
Freeze Frame data or snapshot data is stored in memory.

• There is a specific memory in the ECU which is used to store the failed events and its freeze frame data.

• Using diagnostic tools we can find out the issues present in the car by fetching the relevant data , we have specific
UDS and OBD services which are used to get the required information needed to diagnose the faults in the car.
Diagnostic event &
Monitor definition
Dem Interaction with AUTOSAR modules

Dem interaction with other BSW modules

The status of a ‘Diagnostic Event’ represents the result of a monitor (Pass/Fail)

The Dem module uses the EventId to manage the status of the ‘Diagnostic Event’ of a
system and performs the required actions for individual test results, e.g. stores the
freeze frame.

The Dem module shall represent each Diagnostic Event by an EventId and the
related EventName.

All monitors and BSW modules use the EventId as a symbolic EventName. The Dem
configuration tool replaces the symbolic names by numbers.
Event kind:
There are two different types of events:
• BSW-related events (reported via C-API - Dem_ReportErrorStatus)
• SW-C-related events (reported via RTE operation - SetEventStatus)

Event destination in memory:

The configuration parameter DemMemoryDestinationRef (refer to DemDTCAttributes) defines the
dedicated storage location(s) of the event and its related data

Event priority:
Event priority is defined as a ranking of events based upon level of importance. It is used to determine
which fault entries may be removed from the event memory in case the number of stored events exceeds
the maximum number of memory entries (event memory is full).

Event occurrence:
Dem module shall provide an occurrence counter per event memory entry. It shall be incremented on
each failure of the event
Diagnostic Trouble Code (DTC):

A ‘Diagnostic trouble code’ defines a unique identifier (shown to the diagnostic tester) mapped to a ‘Diagnostic event’
of the Dem module. The Dem provides the status of ‘Diagnostic trouble codes’ to the Dcm module.

DTC Kind

There are two different kinds of DTCs:

• 1. UDS DTCs – 3 bytes
• 2. OBD-relevant DTCs – 2 bytes

DTC significance

• There are two different significance levels of DTCs:

 fault: classifies a failure, which relates to the component/ECU itself (and requires for example a repair action).
 occurrence: classifies an issue, which indicates additional information concerning insufficient system behavior
(and relates for example to a condition out of the ECU’s control).
• This significance level is configurable per event
Operation cycle management

If an operation cycle has started, all status reports from SW-Cs

(Dem_SetEventStatus) and BSW modules (Dem_ReportErrorStatus) for those events,
being assigned to this cycle, shall be accepted by the Dem from this point in time on.

Examples of operation cycles are:

• ignition on/off cycle
• power up/power down cycle
• OBD driving cycle
• engine warm up cycle
Event memory description

• The ‘event memory’ is defined as a set of event records located in a dedicated memory block. The
event record includes at least the extended event status and the event related data like freeze frame.

• The Dem module shall support the primary event memory.

• If configured the Dem module shall support the additional event memories (user defined, mirror,
permanent).

• The size of the different event memories is configurable in the Dem configuration.

• For storing to non-volatile memory the Dem shall use the NVRAM Manager
• Fault confirmation

• The Dem module shall provide the configuration parameter DemEventFailureCycleCounterThreshold

• per event (refer to DemEventParameter) defining
• the maximum number of tested and failed cycles, before the event becomes “confirmed”,
• i.e. enters the confirmed state.

• No. of times event is failed < DemEventFailureCycleCounterThreshold , event is in pending

state.

• No. of times event is failed >= DemEventFailureCycleCounterThreshold , event is confirmed.

Event related data

Event related data’ are additional data, e.g. sensor values or time stamp/mileage, which are stored in case
of an event.

ISO-14229-1[1] defines two different types of event related data :

• Snapshot data (freeze frames)
• Extended data.

The number or sets of stored event related data are strongly OEM / failure specific and are therefore
configurable. This data is provided by SW-C or other BSW modules.

An event is characterized by its event Id, DTC value, configured freeze frames and extended data
records, etc.
Storage of freeze frame data

• The Dem module shall support event-specific freeze frame storage.

• There are two options for freeze frame configuration:

 Non-emission related freeze frames are configured specific to one particular event. The freeze frame
records can be addressed by using relative numbers (calculated or configured), so the record numbers are
unique to an event (not globally).
 Emission related freeze frames are configured globally for a particular ECU (OBD legislation requires one
single freeze frame class).

• Note: A freeze frame is represented as a list of DIDs (refer to DemDidClass ) or PIDs (refer to DemPidClass).
• Clear DTC:

Clear DTC is a command which clears DTC and event related information from the primary memory and resets
the status bits accordingly.

Failure counter and failure threshold:

Healing:
The Dem module provides the ability to activate and deactivate indicators per event stored in the event memory.
The process of deactivation is defined as healing of a diagnostic event

Aging:
The Dem module provides the ability to remove a specific event from the event memory, if its fault conditions are
not fulfilled for a certain period of time (operation cycles). This process is called as "aging" or "unlearning".
The process of aging (counting of aging counter) starts when healing is completed (WarningIndicatorRequested
bit == 0 Upon event aging, the Dem shall remove the event related Snapshot data (Freeze frame) and extended
data records from the event memory.
statusOfDTC: Bit field name Bit
testFailed 0
Status Byte:
testFailedThisOperationCycle 1
pendingDTC 2 Every event and its mapped DTC
have status byte associated with it
confirmedDTC 3 which gives the information about
testNotCompletedSinceLastClear 4 the event.

testFailedSinceLastClear 5
testNotCompletedThisOperationCycle 6
warningIndicatorRequested 7
Debouncing of diagnostic events

• Dem module shall implement basic algorithms used for fault maturation

• Counter based debounce algorithm

In counter based debouncing, there is counter threshold of failures that needs to be met for the fault to
become mature or failed. (Once the threshold is reached bit 0 , i.e. test failed bit becomes 1).

Similarly for the event to pass a certain threshold has to be met for resetting of test failed bit to 0 from 1.

• Timer based debounce algorithm

In timer based debouncing, there is a time range, for example if a fault is present continuously for 5 mins
the fault will be matured (bit 0 -> 1).

In the other scenario if the fault is present only for initial 30 sec and the remaining 4.5 mins it is absent
then the fault will not mature (bit 0 stays 0).
 Asynchronous behavior of BSW faults

• If an Nvm block is corrupted(BSW

event , say event id 5) then Nvm will
call Dem to report the error via
below API:

• Dem_ReportErrorStatus(EVENT_
5, EVENT_FAILED);
Synchronous and asynchronous event processing
• Aging Process
Status bit transitions
General diagnostic event
storage processing
General diagnostic event retention processing
Status bit update
In case an event is qualifying, either by reporting (passed / failed) or by reaching the debounce counter thresholds,
the Dem shall perform the event status transition synchronously in the reporting function (e.g.
Dem_SetEventStatus)) at least for the following status bits:

• Bit 0 TestFailed
• Bit 1 TestFailedThisOperationCycle
• Bit 6 TestNotCompletedThisOperationCycle

Depending on the design decision (synchronous or asynchronous event processing) the status update of the below
bits may occur at a later point in time:

• Bit 2 PendingDTC
• Bit 3 ConfirmedDTC
• Bit 7 WarningIndicatorRequested
Event Storage in memory

•If DemEventMemoryEntryStorageTrigger -> DEM_TRIGGER_ON_TEST_FAILED & If an event

gets qualified as failed (UDS DTC status bit 0 changes from 0 to 1) , event will be stored in memory if memory is
available.

•If DemEventMemoryEntryStorageTrigger -> DEM_TRIGGER_ON_PENDING & If an event

gets pending (UDS DTC status bit 2 changes from 0 to 1), event will be stored in memory if memory is available.

•If DemEventMemoryEntryStorageTrigger -> DEM_TRIGGER_ON_CONFIRMED & If an event

gets confirmed (UDS DTC status bit 3 changes from 0 to 1) , event will be stored in memory if memory is available.

•If DemEventMemoryEntryStorageTrigger -> DEM_TRIGGER_ON_FDC_THRESHOLD & If an event

has DemDebounceAlgorithmClass set to DemDebounceCounterBased and the internal debounce counter reaches
the DemEventMemoryEntryFdcThresholdStorageValue by a positive increment via EventStatus set to preFailed
and , event will be stored in memory if memory is available.
Active/Passive status

If an event gets qualified as failed, it becomes

active. If the event gets qualified as passed, it
becomes passive. This status can be derived
from the UDS DTC status byte.

If the TestFailed bit is stored non-volatile, “event

active” equals to TestFailed = 1

and “event passive” equals to TestFailed = 0.

Event displacement
Event displacement means, that the most insignificant, already existing event memory entry is replaced by a new
event memory entry, which needs to be stored. During displacement, the most insignificant entry gets lost.

The Dem module provides the configuration parameter DemEventDisplacementStrategy defining whether the
existing event memory entry can be displaced or not.

•If DemEventDisplacementStrategy -> DEM_DISPLACEMENT_NONE, then the Dem module shall not displace
existing event memory entries if the event memory is full.

•If DemEventDisplacementStrategy -> DEM_DISPLACEMENT_FULL, then the Dem module displace events from
memory Based on Active/Passive status.

•If DemEventDisplacementStrategy -> DEM_DISPLACEMENT_PRIO_OCC , then the Dem module displace lower
prioritized events by higher prioritized events.
Storage of freeze frame data
•If DemFreezeFrameRecordTrigger -> DEM_TRIGGER_ON_FDC_THRESHOLD, the FreezeFrame shall be
captured each time the configured FDC threshold (DemEventMemoryEntryFdcThresholdStorageValue) is reached.

•If DemFreezeFrameRecordTrigger -> DEM_TRIGGER_ON_TEST_FAILED, the FreezeFrame shall be captured

each time the TestFailed UDS DTC status bit 0 is set (changing from 0 to 1).

•If DemFreezeFrameRecordTrigger -> DEM_TRIGGER_ON_PENDING, the FreezeFrame shall be captured

each time the Pending UDS DTC status bit 2 is set (changing from 0 to 1).

•If DemFreezeFrameRecordTrigger -> DEM_TRIGGER_ON_CONFIRMED, the FreezeFrame shall be captured

each time the Confirmed UDS DTC status bit 3 is set (changing from 0 to 1).

•If DemFreezeFrameRecordUpdate -> DEM_UPDATE_RECORD_NO, the FreezeFrame shall be stored only if the
Freeze- Frame is currently not stored in this event memory entry.

•If DemFreezeFrameRecordUpdate -> DEM_UPDATE_RECORD_YES, the FreezeFrame shall be updated with

each trigger (refer to DemFreezeFrameRecordTrigger).
Synchronous & Asynchronous capturing of freeze frame

If DemEnvironmentDataCapture -> DEM_CAPTURE_ASYNCHRONOUS_TO_REPORTING,

event-specific freeze frame and extended data shall be captured in the next cycle of the Dem_MainFunction.

If DemEnvironmentDataCapture -> DEM_CAPTURE_SYNCHRONOUS_TO_REPORTING, event-specific

freeze frame and extended data shall be captured within the reporting function (i.e. in the context of the
SetEventStatus/ReportErrorStatus function).

If DemEnvironmentDataCapture is equal to DEM_CAPTURE_SYNCHRONOUS_TO_REPORTING, a queue

could be used to store the environment data until the data is transferred to the event memory. To not loose any
reporting, the queue size needs to be configured to store all reporting between two cycles of Dem_MainFunction.

The Dem module shall use the C-callback ReadDataElement respectively the operation ReadData of the
interface DataServices_<Data> to collect all configured data elements of the respective freeze frame.
Startup behavior

The Dem module shall distinguish between a pre-initialization mode and a full-initialized mode (operation mode).

The function Dem_PreInit is called by the ECU State Manager during the startup phase of the ECU before the
NVRAM Manager is initialized. For all operation cycles having a autostart functionality by configuration parameter
DemOperationCycleAutostart, the BSW modules can start reporting of related events via Dem_ReportErrorStatus.

The function Dem_Init is called during the startup phase of the ECU, after the NVRAM Manager has finished the
restore
of NVRAM data. SW-Components including monitors are initialized afterwards. The Function Dem_Init is also used to
reinitialize the Dem module after the Dem_Shutdown was called.

The Dem module is not functional until the Dem module’s environment has called the function Dem_Init.

The primary initialization of the monitors in the application is done via Rte_Start. The
initialization of the event-specific part of the monitor can be triggered by the Dem.
Suppress DTC output
A suppressed DTC behaves in a way that it is not visible for the tester but can be processed
continuously by the diagnostic monitor. Suppressed DTCs are treated as if they are not configured
in the system.

An exemplary use-case could be that the decision to hide a DTC in a certain market is done by the
SW-C at runtime. The function Dem_SetDTCSuppression is available if the configuration parameter
DemSuppressionSupport is set to DEM_DTC_SUPPRESSION.

Configuration parameter : DemSuppressionSupport

Availability of events (visibility and computation)

In Dem there is a method to mark events as not available without removing them from the actual
configuration. An event which is not available is treated as if it was not included in the Dem
configuration.

Configuration parameter : DemEventAvailable

Interface : Dem_SetEventAvailable
Important API’s in Dem

• Dem_PreInit
• Dem_Init
• Dem_Shutdown
• Dem_ReportErrorStatus
• Dem_SetEventStatus
• Dem_ResetEventStatus
• Dem_PrestoreFreezeFrame
• Dem_ClearPrestoredFreezeFrame
• Dem_SetOperationCycleState
• Dem_GetComponentFailed
• Dem_GetEventStatus
• Dem_GetDTCOfEvent
• Dem_SetEnableCondition
• Dem_SetStorageCondition
• Dem_GetFaultDetectionCounter
• Dem_GetIndicatorStatus
• Dem_GetEventFreezeFrameData
• Dem_GetNumberOfEventMemoryEntries
• Dem_ClearDTC
Important Configurations related to Dem Event
Important Configurations related to DTCs
Important Configurations related to DemGeneral
Rte Configuration for an event

• Interface : Client Server Interface

• In Dem Service sw component below parameters are configured:

1. P Port
2. Runnable (Dem_SetEventStatus)
3. Port API option
4. Operation Invoked Event

• In ASW below parameters are configured

1. P Port
2. Runnable
3. Port API option
4. Timing event
Interaction with Software Components (SW-C)

From the viewpoint of the BSW “Cmodule” Dem, there are three kinds of dependencies
between the Service and the AUTOSAR Software Components above the RTE:
- The application accesses the API (implemented as Cfunctions) of the Dem (by
accessing the Dem Service Component).
- The application is optionally notified upon the outcome of requested asynchronous
activity (via direct/indirect RTE API by the Dem).
- An initialization function of the SWC is invoked by the Dem.

Interaction with Diagnostic Communication Manager (Dcm)

The Dcm accesses the Dem module in order to delegate those diagnostic services,
which are related to the event memory.

Interaction with Function Inhibition Manager (FIM)

Interaction with NVRAM Manager (NvM)

Interaction with Default Error Tracer (Det)
Interaction with Diagnostic Log & Trace (Dlt)
UDS
Unified Diagnostic Services (UDS) is a diagnostic communication protocol used in ECUs within automotive
electronics, which is specified in the ISO 14229-1.

Diagnostic tools are able to contact all ECUs installed in a vehicle, which has UDS services enabled.

It lets the diagnostic systems communicate with the ECUs to diagnose faults and reprogram the ECUs accordingly (if
required).
Negative Response format
Diagnostic Session Control (0x10)

UDS uses different operating sessions, which can be changed using the different sub functions of session
control.

• Default Session (0x01): On start, the control unit is by default in the "Default Session”.

• Programming Session (0x02): used to upload software

• Extended Diagnostic Session (0x03): used to unlock additional diagnostic functions, such as the
adjustment of sensors. Safety system diagnostic session, used to test all safety-critical diagnostic
functions, such as airbag tests. In addition, there are reserved session identifiers that can be defined for
vehicle manufacturers and vehicle suppliers specific use.
ECU Reset (0x11)
The service "ECU reset" is used to restart the control unit (ECU). Depending on the control unit hardware
and implementation, different forms of reset can be used,

•Hard Reset (0x01): Simulates the power-on / start-up sequence typically performed after a server has been
previously disconnected from its power supply (i.e. battery).

•key off on Rese (0x02): Simulates condition similar to the driver turning the ignition key off
and back on. This reset condition should simulate a key-off-on sequence.

•Soft Reset (0x03): Simulates condition which causes the server to immediately restart the application
program
SecurityAccess (0x27)
The purpose of this service is to provide a means to access data and/or diagnostic services, which have
restricted access for security, emissions, or safety reasons.

A typical example of the use of this service is as follows:

• Client requests the “Seed”,

• Server sends the “Seed”,
• Client sends the “Key” (appropriate for the Seed received),
• Server responds that the “Key” was valid and that it will unlock itself.

Only one security level shall be active at any instant of time.

Communication Control (0x28)
The purpose of this service is to switch on/off the transmission and/or the reception of certain messages of
server(s) (e.g. application communication messages).

• enableRxAndTx (0x00): This value indicates that the reception and transmission of messages shall be
enabled for the specified communication Type.

• enableRxAndDisableTx (0x01): This value indicates that the reception of messages shall be enabled and the
transmission shall be disabled for the specified communication Type.

• disableRxAndEnableTx (0x02): This value indicates that the reception of messages shall be disabled and the
transmission shall be enabled for the specified communication Type.

• disableRxAndTx (0x03) : This value indicates that the reception and transmission of messages shall be
disabled for the specified communication Type.
TesterPresent (0x3E)
This service is used to indicate to a server (or servers) that a client is still connected to the vehicle and that
certain diagnostic services and/or communication that have been previously activated are to remain active.

If no communication is exchanged with the client for a long time, the control unit automatically exits the current
session and returns to the "Default Session" back, and might go to sleep mode. Therefore, there is an extra
service which purpose is to signal to the device that the client is still present.
ControlDTCSetting (0x85)
The ControlDTCSetting service shall be used by a client to stop or resume the updating of DTC status bits in
the server(s).

Enable or disable the detection of any or all errors. This is important when diagnostic work is performed in the car,
which can cause an anomalous behavior of individual devices.

Sub Function Descrption

0x01 The server(s) shall resume the updating of diagnostic trouble code status bits
according to normal operating conditions

0x02 The server(s) shall stop the updating of diagnostic trouble code status bits.
ReadDataByIdentifier (0x22)

The ReadDataByIdentifier service allows the client to request data record values from the server identified by
one or more dataIdentifiers.

The format and definition of the dataRecord shall be vehicle manufacturer or system supplier specific, and may
include analog input and output signals, digital input and output signals, internal data, and system status information
if supported by the server.
ReadMemoryByAddress (0x23)
Read data from the physical memory at the provided address. This function can be used by a testing tool,
in order to read the internal behaviour of the software.
The ReadMemoryByAddress request message is used to request memory data from the server identified by
the parameter memoryAddress and memorySize. The number of bytes used for the memoryAddress and
memorySize parameter is defined by addressAndLengthFormatIdentifier (low and high nibble).

ReadDataByPeriodicIdentifier (0x2A)
With this service, values are sent periodically by a control unit. The values to be sent must be defined to only
using the "Dynamically Define Data Identifier".

DynamicallyDefineDataIdentifier (0x2C)
This service offers the possibility of a fix for a device specified Data Identifier (DID) pool to configure another
Data Identifier. This is usually a combination of parts of different DIDs or simply a concatenation of complete DIDs.
The requested data may be configured or grouped in the following manner:
•Source DID, position, length (in bytes), Sub-Function Byte: defineByIdentifier
•Memory address length (in bytes), Sub-Function Byte: defineByMemoryAddress
•Combinations of the two above methods through multiple requests.
WriteDataByIdentifier (0x2E)
The WriteDataByIdentifier service is used by the client to write a dataRecord to a server. The data is identified
by a dataIdentifier, and may or may not be secured.
Dynamically defined dataIdentifer(s) shall not be used with this service. It is the vehicle manufacturer's
responsibility that the server conditions are met when performing this service. Possible uses for this service
are:
• Programming configuration information into server (e.g., VIN number),
• Clearing non-volatile memory,
• Resetting learned values,
• Setting option content.
ClearDiagnosticInformation (0x14)
The ClearDiagnosticInformation service is used by the client to clear diagnostic information in one or multiple
servers’ memory.
The server shall send a positive response when the ClearDiagnosticInformation service is completely
processed. The server shall send a positive response even if no DTCs are stored. If a server supports multiple
copies of DTC status information in memory (e.g. one copy in RAM and one copy in EEPROM) the server
shall clear the copy used by the ReadDTCInformation status reporting service. Additional copies, e.g. backup
copy in long-term memory, are updated according to the appropriate backup strategy (e.g. in the power-latch
phase).
ReadDTCInformation (0x19)
This service allows a client to read the status of server resident Diagnostic Trouble Code (DTC) information
from any server, or group of servers within a vehicle. Unless otherwise required by the particular subfunction,
the server shall return all DTC information (e.g., emissions-related and non emissions-related). This service
allows the client to do the following:
• Retrieve the number of DTCs matching a client defined DTC status mask,
• Retrieve the list of all DTCs matching a client defined DTC status mask,
• Retrieve the list of DTCs within a particular functional group matching a client defined DTC status mask,
• Retrieve all DTCs with "permanent DTC" status.

Sub-function = 0x01 reportNumberOfDTCByStatusMask

A client can retrieve a count of the number of DTCs matching a client defined status mask by sending a
request for this service with the sub-function set to reportNumberOfDTCByStatusMask. The response to this
request contains the DTCStatusAvailabilityMask, which provides an indication of DTC status bits that are
supported by the server for masking purposes. Following the DTCStatusAvailabilityMask the response
contains the DTCFormatIdentifier which reports information about the DTC formatting and encoding.
Sub-function = 0x02 reportDTCByStatusMask
The client can retrieve a list of DTCs, which satisfy a client defined status mask by sending a request with the
sub-function byte set to reportDTCByStatusMask. This sub-function allows the client to request the server to
report all DTCs that are “testFailed” OR “confirmed” OR “etc.”

Sub-function = 0x04 reportDTCSnapshotRecordByDTCNumber

A client can retrieve captured DTCSnapshot record data for a client defined DTCMaskRecord in conjunction
with a DTCSnapshot record number by sending a request for this service with the sub-function set to
reportDTCSnapshotRecordByDTCNumber. The server shall search through its supported DTCs for an exact
match with the DTCMaskRecord specified by the client (containing the DTC number (high, middle, and low
byte)). The DTCSnapshotRecordNumber parameter provided in the client’s request shall specify a particular
occurrence of the specified DTC for which DTCSnapshot record data is being requested.
RoutineControl (0x31)
The Control service routine services of all kinds can be performed. There are three different message types:
•With the start-message, a service can be initiated. It can be defined to confirm the beginning of the execution
or to notify when the service is completed. (Sub function 0x01)

•With the Stop message, a running service can be interrupted at any time. (Sub function 0x01)

•The third option is a message to query the results of the service. (Sub function 0x03)

The start and stop message parameters can be specified. This makes it possible to implement every possible
project-specific service.
RequestDownload (0x34)

Downloading new software or other data into the control unit is introduced using the "Request Download". Here,
the location and size of the data is specified. In turn, the controller specifies how large the data packets can be.

RequestUpload (0x35)

The service "request upload" is almost identical to the service "Request Download". With this service, the software
from the control unit is transferred to the tester. The location and size must be specified. Again, the size of the data
blocks are specified by the tester.

TransferData (0x36)

For the actual transmission of data, the service "Transfer Data" is used. This service is used for both uploading and
downloading data. The transfer direction is notified in advance by the service "Request Download" or "Upload
Request". This service should try to send packets at maximum length, as specified in previous services. If the data
set is larger than the maximum, the "Transfer Data" service must be used several times in succession until all data
has arrived.

RequestTransferExit (0x37)
A data transmission can be 'completed' when using the "Transfer Exit" service. This service is used for comparison
between the control unit and the tester. When it is running, a control unit can answer negatively on this request to
stop a data transfer request. This will be used when the amount of data (set in "Request Download" or "Upload
Request") has not been transferred.
NRC – Negative Response Code
0x10 generalReject This NRC indicates that the requested action has been rejected by the server. The generalReject
response code shall only be implemented in the server if none of the negative response codes
defined in this document meet the needs of the implementation.

0x11 serviceNotSupported Server does not support the requested service.

0x12 sub-functionNotSupported The server shall send this NRC in case the client has sent a request message with a known and
supported service identifier but with "sub-function“ which is either unknown or not supported.
0x13 incorrectMessageLengthOrInvalidFormat Length of the received request message does not match the prescribed length for the specified
service or the format of the paramters do not match the prescribed format for the specified service.
0x14 responseTooLong This NRC shall be reported by the server if the response to be generated exceeds the maximum
number of bytes available by the underlying network layer.
0x21 busyRepeatRequest This NRC indicates that the server is temporarily too busy to perform the requested operation. In
this circumstance the client shall perform repetition of the "identical request message" or "another
request message". The repetition of the request shall be delayed by a time specified in the
respective implementation documents.

0x22 conditionsNotCorrect This NRC indicates that the requested action will not be taken because the server prerequisite
conditions are not met.
0x24 requestSequenceError This NRC indicates that the requested action will not be taken because the server expects a
different sequence of request messages or message as sent by the client. This may occur when
sequence sensitive requests are issued in the wrong order.
EXAMPLE A successful SecurityAccess service specifies a sequence of requestSeed and sendKey
as sub-fuctions in the request messages. If the sequence is sent different by the client the server
shall send a negative response
message with the negative response code 0x24 requestSequenceError.
0x31 requestOutOfRange This NRC indicates that the requested action will not be taken because the server has detected that
the request message contains a parameter which attempts to substitute a value beyond its range of
authority
0x33 SecutityAccessDenied This NRC indicates that the requested action will not be taken because the server's security strategy
has not been satisfied by the client.

0x35 invalidKey This NRC indicates that the server has not given security access because the key sent by the client
did not match with the key in the server's memory. This counts as an attempt to gain security. The
server shall remain locked and increment ist internal securityAccessFailed counter.

0x36 EexceedNumberOfAttempts This NRC indicates that the requested action will not be taken because the client has unsuccessfully
attempted to gain security access more times than the server's security strategy will allow.

0x70 uploadDownloadNotAccepted This NRC indicates that an attempt to upload/download to a server's memory cannot be accomplished
due to some fault conditions.
0x72 generalProgrammingFailure This NRC indicates that the server detected an error when erasing or programming a memory location
in the permanent memory device (e.g. Flash Memory).
0x78 requestCorrectlyReceived- This NRC indicates that the request message was received correctly, and that all parameters in the
ResponsePending request message were valid, but the action to be performed is not yet completed and the server is not
yet ready to receive another request.

0x7F serviceNotSupportedInActiveSession This NRC indicates that the requested action will not be taken because the server
does not support the requested service in the session currently active.
OBD
A basic OBD system consists of an ECU (Electronic Control Unit), which uses input from various sensors (e.g., oxygen sensors)
to control the actuators (e.g., fuel injectors) to get the desired performance. The “Check Engine” light, also known as the MIL
(Malfunction Indicator Light), provides an early warning of malfunctions to the vehicle owner. A modern vehicle can support
hundreds of parameters, which can be accessed via the DLC (Diagnostic Link Connector) using a device called a scan tool.
This on-board computer system collects information from the network of sensors inside the vehicle, which the system can then
use to regulate car systems or alert the user to problems.
OBD-II

OBD II is the latest version of on-board diagnostics. It monitors and tracks the vehicle’s performance by collecting various parameters
from a network of sensors. These parameters are processed by the OBD system and are stored as diagnostics trouble code (DTC)
when found beyond acceptable range. Let’s understand by taking the example of an emission control system.
If the vehicle is emitting CO at a higher rate than permissible, the sensor will send a signal to the OBD system. It will store this
piece of information in the form of a DTC, specified in the OBD II protocol. Additionally, the OBD system will also switch on the
malfunction indication light (MIL) to inform the vehicle user.

MIL: When the ECU collects a DTC code, it sends a signal to the vehicle dashboard to turn on the appropriate indicator lights.
These lights, known formally as Malfunction Indicator Lights or MILs, provide an early warning system for vehicle malfunctions.
Generally speaking, if the light turns on and stays on, the problem is minor. If the light flashes, the problem is urgent.
Mode/Service 1 - Request current powertrain diagnostic data

The purpose of this service is to allow access to current emission-related data values, including analogue inputs
and outputs, digital inputs and outputs, and system status information. The request for information includes
parameter identification (PID) value that indicates to the on-board system the specific information requested.

All data values returned for sensor readings will be actual readings, not default or substitute values used by the
system because of a fault with that sensor.
Mode 1 PID 01
A request for this PID returns 4 bytes of data, labeled A B C and D.

The first byte(A) contains two pieces of information.

•Bit A7 (MSB of byte A, the first byte) indicates whether or not the MIL (check engine light) is
illuminated.
•Bits A6 through A0 represent the number of diagnostic trouble codes currently flagged in the ECU.

The second, third, and fourth bytes(B, C and D) give information about the availability and
completeness of certain onboard tests. Note that test availability is indicated by set (1) bit and
completeness is indicated by reset (0) bit.
Mode/Service $02 – Request powertrain freeze frame data

When a monitored component/system fails, a diagnostic trouble code (DTC) is raised. For a better understanding of the failure,
by the service technician, the OBD is providing a “freeze frame”. This is a set of engine and vehicle parameters stored in the
non-volatile memory, when the DTC is raised.
For example, while driving at high speed, a DTC is raised for the exhaust catalyst. In order to understand why the failure occurred,
we are going to have the value of the engine temperature, speed, load and vehicle speed stored in the freeze frame, for the exact
moment of the failure appearance.

Note that services 01 and 02 are basically identical, except that service 01 provides current information, whereas service 02
Provides a snapshot of the same data taken at the point when the last diagnostic trouble code was set. The exceptions are PID 01,
which is only available in service 01, and PID 02, which is only available in service 02. If service 02 PID 02 returns zero,
then there is no snapshot and all other service 02 data is meaningless.
Mode/Service $03 – Request Emission-Related Diagnostic Trouble Codes
The purpose of this diagnostic service is to enable the external test equipment (scantool, tester) to obtain all the “confirmed”
emission-related diagnostic trouble codes (DTCs). A confirmed fault code is defined as the DTC stored when an OBD system
has confirmed that a malfunction exists. Usually, the confirmation is given on the second driving cycle following the malfunction
detection.
If an ECU does not have emission-related DTCs, then it shall respond with a message indicating no DTCs are stored by setting
the parameter number of DTC to 0x00.

Mode/Service $04 – Clear/Reset Emission-Related Diagnostic Information

The purpose of this service is to provide a means for the external test equipment (scantool, tester) to command ECUs to clear all
emission related diagnostic information.
Mode $04 clears/erases diagnostic trouble codes and diagnostic data, which includes:
•freeze frames
•inspection/maintainance readiness
•status of monitors
•PID for number of engine warm-ups, distance with Malfunction Indicator Lamp (MIL) ON
•data read by mode/service $06
This mode can be used by the service technicians (or other users) to turn off the MIL and erase stored DTCs after a repair has been
performed. It can be also used as a confirmation that the fault is not present anymore (after reset the DTC are read again).
Mode/Service $06 – Request On-Board Monitoring Test Results for Specific
Monitored Systems

The purpose of this diagnostic service is to allow access to the results for on-board diagnostic monitoring tests of specific
components/systems that are either continuously monitored (e.g. misfire monitoring) or non-continuously monitored
(e.g. catalyst system).
The vehicle manufacturer will define “Manufacturer Defined Test IDs” for different tests of a monitored system. Mode $06 will
provide the monitoring test values and fault (malfunction) limits for the defined tests (monitors).

The data provided by this diagnostic service can be used by service technicians to identify which monitor has failed and by how
much. Once the failed component/system has been repaired/restored, Mode $06 data can be used to validate the process.
A particular monitoring test of Mode $06 is defined for the oxygen (lambda) sensor. The test monitors the voltage output of the sensor.
Mode/Service $07 – Request Emission-Related Diagnostic Trouble Codes Detected
During Current or Last Completed Driving Cycle
The purpose of this diagnostic service is to enable the external test equipment (scantool, tester) to obtain “pending” diagnostic
trouble codes (DTCs) detected during current or last completed driving cycle for emission-related components/systems.
A pending fault code is defined as the diagnostic trouble code, stored as a result of initial detection of a malfunction (usually in the
current driving cycle), before the activation of the malfunction indicator lamp (MIL).
This operating mode is required for all diagnostic trouble codes and it’s independent of Service $03.
The intended use of this data is to assist the service technician after a vehicle repair, and after clearing diagnostic information, by
reporting test results after a single driving cycle.

Mode/Service $08 – Request Control of On-Board System, Test or Component

The purpose of this service is to enable the external test equipment (scantool, tester) to control the operation of an on-board
system, test or component. With the help of this service, the service technician can activate an on-board test mode.
The possible types of tests performed with Mode $08 are:
turn on-board system/test/component ON
turn on-board system/test/component OFF
cycle on-board system/test/component for a predefined number of seconds
Mode/Service $09 – Request Vehicle Information

The purpose of this diagnostic service is to enable the external test equipment (scantool, tester) to request vehicle specific
information such as:
Vehicle Identification Number (VIN)
Module Calibration Number (CALID)
Calibration Verification Number (CVN)
In-use Performance Ratio (IUPR) values

Mode/Service $0A – Request Emission-Related Diagnostic Trouble Codes with

Permanent Status
The purpose of this diagnostic service is to enable the external test equipment (scantool, tester) to obtain all diagnostic trouble
codes with “permanent” status. These are DTCs that are “confirmed” and are stored in the non-volatile memory of the electronic
control unit until the corresponding monitor for each DTC has determined that the malfunction is no longer present and is not
setting the MIL ON anymore.
The DTCs stored as permanent can not be cleared with the scantool using Mode $04. Permanent status codes automatically clear
themselves after repairs have been made and the related system monitor runs successfully.
OBD Services Description
1 Show current data
2 Show freeze frame data
3 Show stored Diagnostic Trouble Codes
4 Clear Diagnostic Trouble Codes and stored values
5 Test results, oxygen sensor monitoring (non CAN only)
Test results, other component/system monitoring (Test results, oxygen sensor
6 monitoring for CAN only)
Show pending Diagnostic Trouble Codes (detected during current or last driving
7 cycle)
8 Control operation of onboardcomponent/system
9 Request vehicle information
0A Permanent Diagnostic Trouble Codes (DTCs) (Cleared DTCs)
DCM
The DCM module provides a common API for diagnostic services. The functionality of the DCM
module is used by external diagnostic tools during the development, manufacturing or service.
Supports ISO14229-1 services and OBD services $01 - $0A defined in ISO15031-5 .
It is located in the Communication Services (Service Layer).
The DCM module ensures diagnostic data flow and manages the diagnostic states, especially diagnostic sessions and security states.
Furthermore, the DCM module checks if the diagnostic service request is supported and if the service may be executed in the
current session according to the diagnostic states.

The DCM module is network-independent. All network-specific functionality (the specifics of networks like CAN,
LIN, FlexRay or MOST) is handled outside of the DCM module. The PDU Router (PduR) module provides a
network-independent interface to the DCM module.

The DCM module receives a diagnostic message from the PduR module. The DCM module processes and checks
internally the diagnostic message. As part of processing the requested diagnostic service, the DCM will interact with
other BSW modules or with SW-Components (through the RTE) to obtain requested data or to execute requested
commands. This processing is very service-specific. Typically, the DCM will assemble the gathered information and
send a message back through the PduR module.
In the AUTOSAR Architecture the Diagnostic Communication Manager is located in the Communication Services (Service Layer).
• Rx flow in Diag Stack
• Tx Flow in Diag stack
Sub Modules in DCM

Diagnostic Session Layer (DSL) submodule:

The DSL submodule ensures data flow concerning diagnostic requests and responses, supervises
and guarantees diagnostic protocol timing and manages diagnostic states (especially diagnostic
session and security).

Diagnostic Service Dispatcher (DSD) submodule:

The DSD submodule processes a stream of diagnostic data. The submodule:

• Receives a new diagnostic request over a network and forwards it to a data processor.
• Transmits a diagnostic response over a network when triggered by the data processor (e.g. by the
DSP submodule).

Diagnostic Service Processing (DSP) submodule:

The DSP submodule handles the actual diagnostic service (respectively subservice) requests.
Interaction with other modules

• PduR module
 PduR module provides data of incoming diagnostic requests.
The DSL sub module triggers output of diagnostic responses.

• DSD sub module

The DSL sub module informs the DSD sub module about incoming requests and provides the data.
 The DSD sub module triggers output of diagnostic responses.

• SW-Cs / DSP sub module

 The DSL sub module provides access to security and session state.

•ComM module
The DSL sub module guarantees the communication behavior required by the ComM module
 Diagnostic Session Layer (DSL)

Request Handling Response Handling

- Forward requests from the PduR module to the - Forward responses from the DSD submodule to the
DSD submodule. PduR module.
- Concurrent “TesterPresent” (“keep alive logic”). - Guarantee response timing to tester.
- Support of periodic transmission.
- Support of ResponseOnEvent (ROE) transmission.
Security Level Handling - Support of segmented response.
- Manage security level. - Support of ResponsePending response triggered
by the application.

Session State Handling Communication Mode Handling

- Manage session state. - Handling of communication requirements (Full- /
- Keep track of active non-default sessions. Silent- / No Communication).
- Allows modifying timings. - Indicating of active / inactive diagnostic.
- Enabling / disabling all kinds of diagnostic
transmissions.

Diagnostic Protocol Handling

- Handling of different diagnostic protocols.
- Manage resources.
Forward requests from the PduR module to the DSD submodule
•PduR indicates to DCM regarding Rx of diag request by calling Dcm_ProvideRxBuffer()
•If the reception of a diag request is finished (successful or with errors), the PduR module will call
Dcm_RxIndication() to give a receive indication to the DCM module.
•The DSL shall forward Rx data to the DSD submodule only after a call of Dcm_RxIndication()
•It is allowed to have different DcmPduIds for different diagnostic communication applications. For example:
o OBD DcmRxPduId: for reception of OBD requests,
o OBD DcmTxPduId: for transmission of OBD responses,
o UDS phys DcmRxPduId: for reception of UDS physically addressed requests,
o UDS func DcmRxPduId: for reception of UDS functionally addressed requests,
o UDS DcmTxPduId: for transmission of UDS responses.

Concurrent “TesterPresent” (“keep alive logic”)

It is possible, that functional “TesterPresent” commands are sent by the tester in parallel to physical requests/
responses. This is called “keep alive logic” , the DSL shall reset the session timeout timer (S3Server).

if the request is a “TesterPresent” command with “suppressPosRspMsgIndicationBit” set to TRUE (SID equal to
0x3E, subfunction equal to 0x80), the DSL submodule shall not forward this request to the DSD submodule for
further interpretation.
Forward responses from the DSD submodule to the PduR module

•The DSD submodule shall request the DSL submodule for transmission of responses.
•After the minimum response time between Rx of diagnostic request and Tx of diagnostic response is over
(P2ServerMin) the DSL shall trigger the Tx of response to the PduR module by calling PduR_DcmTransmit (Only
length info is given to PduR).
•PduR module will call Dcm_ProvideTxBuffer() to request the DCM to provide data to be transmitted and it will call
Dcm_TxConfirmation() after the complete PDU has successfully been transmitted or an error occurred.

Guarantee timing to tester by sending busy responses

•If the Application or DSP needs additional time to finish the task and prepare the response, then the DSL shall send a
NRC 0x78 (Response pending) when reaching the response time (DcmDspSessionP2ServerMax ) .
•The number of negative responses with NRC 0x78 (Response pending) for one diagnostic request is limited by the
configuration parameter DcmDslDiagRespMaxNumRespPend.
•If NRC 78 reaches its max count, the DCM stops processing of request, and shall send NRC 0x10 (General reject).
Manage security level
•The DSL submodule shall save the level of the current active security level.
•For accessing this level, the DSL submodule provides interfaces to:
o get the current active security level: Dcm_GetSecurityLevel()
o set a new security level: DslInternal_SetSecurityLevel()
•During DCM initialization the security level is set to the value 0x00.
•Only one security level can be active at a time.

Manage session state

•The DSL submodule shall save the state of the current active session.
•For accessing this variable, the DSL submodule provides interfaces to:
o get the current active session: Dcm_GetSesCtrlType()
o set a new session: DslInternal_SetSesCtrlType()
During DCM initialization, the session state is set to the value 0x01 (“DefaultSession”).

Keep track of active non-default sessions

Whenever a non-default session is active and when the session timeout (S3Server) is reached without
receiving any diagnostic request, the DSL submodule shall reset to the default session state
(“DefaultSession”, 0x01).
Informs depending modules on session change
Whenever the value of the active session changes (initiated by UDS Service DiagnosticSessionControl
(0x10) or S3Server timeout), the DSL shall inform the Application by calling the operation
Xxx_ChangeIndication() via Rte.

Allow to modify timings

Some of the timing parameters can be modified while protocol is active with the following means:
o UDS Service DiagnosticSessionControl (0x10)
o UDS Service AccessTimingParameter (0x83)

Handling of different diagnostic protocols

•Different protocols shall be used for UDS Services versus OBD Services
•Different service tables for different protocols
•Prioritization of protocol (parameter DcmDslProtocolPriority )
•Preemption of protocol
Manage resources

Due to limited resources, the following points should be considered :

It is allowed to use and allocate only one diagnostic buffer in the DCM module. This buffer is then used for processing
the diagnostic requests and responses.
Output of NRC 0x78 (Response pending) responses is done with a separate buffer.

Communication Mode Handling

No Communication
•The ComM module will indicate the No Communication Mode to the DCM . In response, the DCM will immediately
disable all transmissions.
Full Communication
•The ComM module will indicate the Full Communication Mode to the DCM . In response, the DCM will immediately
enable all transmissions.
DSD (Diagnostic Service Dispatcher)
The DSD submodule is responsible to check the validity of an incoming diagnostic request (Verification of
Diagnostic Session/Security Access levels/Application permission) and keeps track of the progress of a service
request execution.

The DSD submodule shall only process valid requests and shall reject invalid ones.

Use cases
The following use cases are relevant and are described in detail in the following:
• Receive a request message and suppress a positive response
• Receive a request message and suppress a negative response
• Receive a request message and transmit a positive response message
• Receive a request message and transmit a negative response message
• Send a positive response message without corresponding request
• Segmented Responses
Interaction of the DSD with the DSL main functionality

Interaction of the DSD with the DSP

Functional Description of the DSD

Handling of “suppressPosRspMsgIndicationBit ”, Bit 7 of second byte of the diagnostic message.

Verification functionality

The DSD submodule will only accept a service, if the following three verifications are passed:
1. Verification of the Diagnostic Session
2. Verification of the Service Security Access levels
3. Verification of the Application environment/permission

Distribution of diagnostic message to DSP submodule

The DSD submodule shall search for the executable functionality of the DSP submodule for newly received diagnostic
Service identifier and shall call the corresponding DSP service interpreter.

Assemble positive or negative response

When the DSP submodule has finished the execution of the requested Diagnostic Service the DSD submodule shall
assemble the response.
The execution of the DSP service interpreter can have the results:
- positive Result or
- negative Result.
Following possible Responses can be assembled:
- positive Response,
- negative Response, or
- no Response (in the case of suppression of responses).
Initiate transmission

The DSD submodule shall forward the diagnostic (response) message (positive or negative response) to the DSL
submodule.

The DSL submodule shall forward the diagnostic (response) message (positive or negative response) further to the
PduR module by executing a DSL transmit functionality.

The DSL submodule shall forward the received confirmation from the PduR module to the DSD submodule.
Diagnostic Service Processing – DSP

When receiving a function call from the DSD submodule requiring the DSP submodule to process a diagnostic service
request, the DSP always carries out following basic process steps:

• Analyze the received request message,

• Check format and whether the addressed subfunction is supported,
acquire data or execute the required function call on the DEM, SW-Cs or other BSW modules
• Assemble the response

DSP module interacts with other modules depending on type of UDS or OBD request