Automotive

Industry
AUTOSAR Diagnostics Stack
 “If horses had controlled investment
decisions, there would have been no auto
industry.”

— Warren Buffett
 01
Overview of
Diagnostics Protocols
The way I drive, the way I handle a car, is an
expression of my inner feelings.
Lewis Hamilton
 Introduction

● Diagnostics in the Automotive domains is the analysis of different functionalities of various

components of the vehicle , which is normally done to find out if the components are operating properly
or are faulty and require repair

● Standardization committees presented some standards that specify the operations and services that
can be used , in order to serve different use cases of automotive diagnostics
○ Unified Diagnostics Protocol (UDS) - ISO - 14229 (Commonly used in all ECUs)
○ Onboard Diagnostics Protocol (OBD) - ISO - 15031 (Only used in few ECUs)

● AUTOSAR provides standard , well-defined and modular specifications for implementing most
commonly used Diagnostics protocols (e.g. DCM , DEM , …)
 Diagnostics Protocols
● Diagnostic system model consists of:
○ Diagnostic tool
○ Ecu(s) to be diagnosed
○ Communication channel between the diagnostics tool and diagnosed ECU(s) e.g. CAN , LIN …

● The diagnostic tool requests a service and the ECU responds with results

● The response can be positive or negative

 Diagnostics Protocols
● Diagnostics protocols “ISO Standard” define set of services used for diagnostics purposes
throughout the whole automotive life cycle :
○ Development
○ Production
○ Maintenance

● The service definition contains

○ Request definition
○ Possible positive responses definitions
○ Possible negative responses definitions
○ Examples
 Diagnostics Protocols
● Protocol Frames :

○ Service Request

SID Data

○ Service Positive Response

SID +0x40 Data

○ Service Negative Response

0x7F SID NRC

 Diagnostics Protocols
● Physical Addressing
○ Request sent to a specific ECU

● Functional Addressing
○ Broadcasting a request to all ECUs

● The ECU response behavior depends on the addressing format of the request
○ Physical Addressing : Respond if required
○ Functional Addressing : Some negative responses are suppressed (e.g.
ServiceNotSupported (0x11) , SubFunctionNotSupported (0x12) ,
RequestOutOfRange(0x31)
 02
UDS Services
I love fast cars… and to go too fast in them.
Lara Flynn Boyle
 UDS Services
● Most Common UDS Services

○ Diagnostic Session Control (0x10)

○ ECU Reset (0x11)
○ Security Access (0x27)
○ Tester Present (0x3E)
○ Read Data By Identifier (0x22)
○ Write Data By Identifier (0x2E)
○ Read DTC Information (0x19)
○ Clear Diagnostic Information (0x14)
○ Control DTC Settings (0x85)
○ Routine Control (0x31)
 UDS Services
● Diagnostic Session Control (0x10)
● Session is a mode of operation with a specific timing parameters and specific services that
can be executed
● Example of sessions : Default Session , Extended Session , Programming Session …e.g.
Programming session : Enables all diagnostics services related to memory programming of the
server (ECU) for software update
● Only one session can be active at a time in the server
● During system startup , the default session is started by default
● Session transition can be done either by service 0x10 or S3Server timeout (5 secs)
● S3Server : Time for the server to keep a diagnostic session other than the default session
active while not receiving any diagnostic request message
● DCM is responsible for notifying the application layer with the session transition
 UDS Services
● Diagnostic Session Control (0x10)
○ Request Format

Sub-function
SID 0x10
(Session Type)

● Sub-function :
○ Default Session (0x01)
○ Programming Session (0x02)
○ Extended Session (0x03)

○ Response Format

Sub-function Session
RSID 0x50
(Session Type) Parameter Record
 UDS Services
● Ecu Reset (0x11)
○ Ecu Reset service allows the external tester to request server reset
○ DCM is responsible for requesting system reset from application layer
○ DCM shall send the service positive response before performing the server reset
○ After a successful reset , the DCM shall activate the default session
○ Examples of Ecu Reset
■ Hard Reset : Simulates the power on sequence typically performed after the server got
connected from the power supply
■ Soft Reset : This is implementation specific reset type , typically used to restart the
application layer without re-initializing the basic software
 UDS Services
● Ecu Reset (0x11)
○ Request Format

Sub-function
SID 0x11
(Reset Type)

● Sub-function :
○ Hard Reset (0x01)
○ KeyOffOn Reset (0x02)
○ Soft Reset (0x03)

○ Response Format

Sub-function
RSID 0x51
(Reset Type)
 UDS Services
● Security Access (0x27)
○ Access to some services needs to be restricted for security matters

○ Security Access service is used to grant access to such protected services

○ The following procedures shall be followed to unlock security levels

1. Client requests the “seed” i.e. random number
2. Server sends the “seed”
3. Client sends the “key” (corresponding for the “seed” received)
4. Server responds that the “key” was valid and that it will unlock itself

○ Only one security level can be unlocked at a time

 UDS Services
● Security Access Control (0x27) - Request Seed
○ Request Format

Request Seed
SID 0x27
0x01,0x03, ...

● Sub-function :
○ “Request Seed” for security level 1 ( 0x01)
○ “Request Seed” for security level 2 (0x03)
○ …..

○ Response Format
Request Seed
RSID 0x67 Security Seed
0x01,0x03, ...
 UDS Services
● Security Access Control (0x27) - Send Key

○ Request Format
Send Key
SID 0x27 Security Seed
0x02,0x04, ...

● Sub-function :
○ “Send Key” for security level 1 (0x02)
○ “Send Key” for security level 2 (0x04)
○ …..

○ Response Format
Send Key
RSID 0x67
0x02,0x04, ...
 UDS Services
● Read Data By Identifier (0x22)

○ Client uses RDBI service to request one or more “two bytes data identifiers” (DID) that
identify data records

○ DIDs with read access type can be used with RDBI service

○ DIDs can be used to represent data from application or from BSW modules

○ Examples of RDBI service

■ Read the vehicle identification number
■ Read the current software version
 UDS Services
● Read Data By Identifier (0x22)

○ Request Format

SID 0x22 DID #1 MSB DID #1 LSB

○ Response Format

RSID 0x62 DID #1 MSB DID #1 LSB Data

 UDS Services
● Write Data By Identifier (0x2E)
○ Client uses WDBI service to request one or more “two bytes data identifiers” (DID) that
identify data records

○ DIDs with write access type can be used with WDBI service

○ DIDs can be used to represent data from application or from BSW modules

○ Examples of WDBI service

■ Write calibration data into ECU
■ Clearing non volatile memory block
 UDS Services
● Write Data By Identifier (0x2E)

○ Request Format

SID 0x2E DID #1 MSB DID #1 LSB Data

○ Response Format

RSID 0x6E DID #1 MSB DID #1 LSB

 UDS Services
● DTC related services :
○ DTCs are Diagnostic trouble codes configured , managed and stored in the DEM module
○ Diagnostics tool uses DCM module to communicate with the DEM module
○ DCM offers the following DTC related services :
■ Read DTC Information (0x19)
■ Clear DTC Information (0x14)
■ Control DTC Settings (0x85)
○ DCM role in DTC related services is to receive the request , validate the request , call the
DEM module for the request execution , assemble the output into the response message and
transmit it
○ Only service and subservice needs to be configured in DCM , other DTC configurations are
done in DEM module
 03
Diagnostic Modules

The fact is I don’t drive just to get from A to B. I enjoy

feeling the car’s reactions, becoming part of it.
Enzo Ferrari
Diagnostics modules
 Diagnostics modules
● DCM Module Functionality
○ The Diagnostic Communication Manager (DCM) is an AUTOSAR-Basic SW module responsible
for implementing a common APIs for using diagnostics services
○ The details of the diagnostic services with their corresponding request/response and error
codes are defined in the following ISO standards
■ Unified Diagnostics Standards “UDS”
■ On Board Diagnostics “OBD”
○ The DCM module depends on other Com stack modules to be able to receive/transmit
diagnostics requests/responses
○ The Dcm module is network independent , it works over different types of networks (CAN ,
FlexRay … ) by using PduR module independent interfaces
 Diagnostics modules
● DCM Module Functionality

○ Supervise and guarantee protocol timings ( e.g. S3Server , P2Sever , P2*Server …)

○ Manage diagnostic sessions

○ Manage security levels locking/unlocking

○ Check the validity of an incoming request

○ Forward the request to application

○ Assemble and transmit response

DCM Timing Parameters
● P2ServerMax : Maximum time value before which the response should be available at
client side
● P2*ServerMax : Maximum time value before which the NRC 0x78 should be available
at the client side
 Diagnostics modules
● DEM Module Functionality

○ Dem stands for Diagnostic Event Manager

○ SW-C and BSW modules monitor the run-time behavior and report the monitoring results to
the Dem module
○ Diagnostic Events are tests performed by SW monitors and reported to the Dem module
○ The status of diagnostic event represents the status reported from SW monitors (BSW or
SW-C)
○ Dem module is responsible for processing and storing diagnostic events reported by SW-C
and BSW modules
○ Diagnostic tools use Dcm services to read fault information from Dem module using DTCs
○ DTC stands for Diagnostic Trouble Code , Its is a code defined by the manufacturer to identify
the error , it is the interface between Dem and DCM
 Diagnostics modules
● DEM Module Functionality
○ Example :
■ Vehicle needs to store some information in case of harsh de-acceleration (Accident)
■ An event is needed to represent the harsh de-acceleration occurrence
■ A DTC is needed , so that the event is represented by trouble code , that will be used
by Dcm module to retrieve event related information
■ Information related to the vehicle environment (e.g. vehicle timestamp , speed , tire
condition ….) can be represented and stored using snapshots(freeze frame)
■ At the vehicle service center , the diagnostic tool can read all these information by
requesting Dcm service 0x19 (ReadDtcInformation) which is responsible for getting
these information from the Dem , assemble it into diagnostic data frame and send it
back to the diagnostic tool
Diagnostics modules
 Diagnostics modules
● DEM Module Functionality
○ Dem provides API for reporting Diagnostic events
■ Dem_SetEventStatus(EventID , EventStatus)
○ Result of the event monitoring is reported through Event status
■ Passed
■ Failed
■ Pre-Passed
■ Pre-Failed
○ Dem event is linked to operation cycle that should be started before reporting event status
■ Power cycle
■ Ignition cycle
■ Driving cycle
 Diagnostics modules
● DEM Module Functionality
○ Event debouncing
■ Time-Based
■ Counter-Based

● Time-Based Algorithm:
○ Time based algorithm monitors functions with timeout
○ Dem starts the internal debounce time to qualify events as failed, when monitors reported
PREFAILED status
○ When the configured DemDebounceTimeFailedThreshold value is reached , the event is
qualified as failed
○ Dem starts the internal debounce time to qualify events as passed , when monitors report
PREPASSED status
○ When the configured DemDebounceTimePassedThreshold value is reached , the event is then
qualified as passed
 Diagnostics modules
● DET Module Functionality

○ DET stands for Development Error Tracer

○ BSW modules and SW components report all detected development errors to the Det

○ Det reporting shall be disabled in production phases

○ Det provides the API Det_ReportErro for tracing the occurrence of the error and it’s related
information

○ Error related information are passed as arguments to the API as follows :

■ Module where error has been detected
■ API where error has been detected
■ Error ID (type of error)
 THANK YOU!
DOES ANYONE HAVE ANY QUESTIONS?

www.imtschool.com
www.facebook.com/imaketechnologyschool/