AUTOMOTIVE Diagnostics

Hey, I am Sushma B R, working as Software Engineer at Luxoft. In this article, I have tried to give a explanation about AUTOMOTIVE Diagnostics.

What is AUTOMOTIVE Diagnostics?

Based on the word we can understand it will help us to identify the cause of a problem or a situation. Whenever the ECU finds a problem, it stores that problem as a Diagnostic Trouble Code (DTC) it the EEPROM.
With the help of Diagnostic tool, we can read the DTC’s from EEPROM to find the root cause of a failure.
Protocol will work based on the set of rules for communication. The Communication will happen between tester and ECU it may also calls Client and Server based communication. Normally diagnostic protocol is used for diagnostic purpose (Means DTC’s, DID’s and UDS functionalunit).
UDS is specified in ISO 14229-1.
As per AUTOSAR the Diagnostic Stack will contains DTC’s, DID’s, Routines and Services etc.,

Why Diagnostics?

In a complex machines and if vehicle contains more ECU and it is very difficult to find the defect from which source, when we are facing failure, this type of problems diagnostics helps the tester to detect the failure from which source exact defect is available and root cause as well. Diagnostics will monitor several sensors, located throughout the engine, fuel etc.,
With the help of Diagnostics in two ways the outside world can understand whether really issue was present or not With help of warning lamp and this warning lamp will alert the driver there will be a problem in our car.
Second one with the help of DTC code service person can understand what exactly issue was present and from which source. For each DTC there will be a pre-defined definition based on that service person, developer and tester can understand the problem. The DTC will be stored in EEPROM.
With the help of diagnostics, we can download the software into the ECU without debugger connection.
Diagnostics will perform sensor calibrations and so on.

Diagnostic Communication Frame:

Two frames:-

Request frame
Response frame

1. Request Frame:-

Physical Addressing:
It is always dedicated message to a server implemented in one ECU.
Between the client and the server, the communication is always point-to-point communication when physical addressing is used.
Functional Addressing:
Whenever the functional addressing is used, the communication is broadcast communication from the client to a server implemented in one or more ECUs.

2. Response Frame:-

Positive Response : SID+40

Negative Response : 7F

Request and Response between Client ECU and Server ECU:

For positive response

Diagnostics Request

Tester ECU/Client ECU to server ECU

Diag_RQ: 0x 02 10 02

Diagnostics Response

Server ECU to Tester ECU

Diag_RS: 0x 02 50 01

For negative response

Diagnostics Request

Tester ECU/Client ECU to server ECU

Diag_RQ: 0x 02 10 02

Diagnostics Response

Server ECU to Tester ECU

Diag_RS: 0x 03 7F 10 12

UDS Protocol:
Introduction to UDS:

UDS requirements of diagnostic services, which allow a diagnostic tester (client) to control diagnostic functions in an on-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle.
UDS will implement in application layer and session layer based on OSI Reference model.
Application layer services are usually referred to as diagnostic services.
The application layer services are used in client-server-based systems to perform functions such as test, inspection, monitoring or diagnosis of on-board vehicle servers.
The application layer protocol shall always be a confirmed
message transmission, meaning that for each service request
sent from the client, there shall be one or more
corresponding responses sent from the server.
The application layer protocol shall be handled in parallel
with the session layer protocol. This means that even if the
client is waiting for a response to a previous request, it shall
maintain proper session layer timing (e.g. sending a
TesterPresent request if that is needed to keep a diagnostic
session going in other servers; the implementation depends
on the data link layer used).

Services:

Subfunctions if applicable

Transport Protocol:

CanTp:

Normally Diagnostic communication will happen via CANTP module incase of AUTOSAR or NON AUTOSAR standard.
Normally CANTP will use for a frame data size is more than 8 bytes.
But All diagnostic related PDU will flow from CANTP module irrespective of data byte size and no application PDU will flow in CANTP
CANTP Protocol designed as per the ISO 15765 – 2
CANTP will use the physical BUS as can to communicate with the tester.
In CANPT Protocol we have two types of addressing mode.
- Basic addressing
- Extended addressing

Basic addressing:

CANTP protocol basic addressing is like normal addressing mode as CAN, and we are using CAN identifiers for the CANTP message also during configuration for those messages we need to configure to CANTP module then server can understand this is related CANTP message. Advantage of this type was server can send full 8 bytes of data.

Extended addressing:

In this addressing mode CANTP will use 1st byte of CAN data as additional element for address. Due to that payload will reduce by 1 byte in CAN message. The main task of the CANTP protocol is to send data which cannot transmitted as a single message due to the length constraints. CANTP will help the server to transfer the more than 8 bytes of data in a specific message, CANTP will segmented 1 PDU to multiple PDU based on the data byte size in PDU. It will help the server can send the data as like normal CAN Messages.

Eg: Extra byte will add in payload section it reference to ECU address.
In CANTP 4 types of frames available.