UDS Protocol Introduction (Unified Diagnostic Services)

A Deep Dive into Unified Diagnostic Services and its implementation

On our earlier introductory article on the Automotive UDS Protocol, the overall picture of the protocol is given including its applications, network architecture, etc. It has been shown that a Client-Server based protocol capable of running on different transport layers including CAN, Ethernet, FlexRay, LIN etc.

In this article, we will take a closer look at the internals of the Unified Diagnostic Services protocol, message structure and UDS services list being defined as part of ISO 14229. We will also explore the design considerations for the Automotive UDS protocol implementation and highlight Embien’s services for Unified Diagnostic Services development.

UDS Application Layer Services

The UDS Protocol provides Application layer services also called diagnostic services to the higher-level application. They are broadly classified as Confirmed Services or Unconfirmed Services based on whether response is expected from the server.

While there are many services defined, all of them share a common packet format. There are 6 service primitives to be provided to support any of these services. These primitives are typically callbacks/APIs that are used by the UDS layer to send/receive packets. The primitives are

Service Primitive

Originator

Description

Request

Client Application

Initiates the specific Diagnostic service

RequestConfirm

Client Transport

Indicates the request has been successfully delivered to the server

Indication

Server Transport

Indicates reception of request to the server

Response

Server Application

Response is ready to be transmitted

Confirmation

Client Transport

Response is successfully received from the server

ResponseConfirm

Server Transport

Response is successfully delivered to client

The typical flow of service primitives for a confirmed service is as follows.

Similarly for an unconfirmed service, it is as follows.

As can be seen, whether the response is needed for the service or not, it is essential to have the transport acknowledge the transmission and successful delivery of the message to the other party.

Message Structure In Unified Diagnostic Services

The Unified Diagnostic Services Protocol defines high-level message structure that is common across the low-level transport protocols. The typical format looks like as depicted below.

Some of the major fields in message structure are:

Message Type :

Indicates the type of message and could be one of diagnostics, remote diagnostics, secure diagnostics or secure remote diagnostics.

Source Address :

16-bit address indicating the application layer source address.

Target Address :

16-bit address that could be the target physical address (uses point to point communication to the client) or the functional address (uses broadcast communication that will be responded to be intended client).

Target Address Type :

Indicates if the target address is physical or functional.

Remote Address :

Optional field to extend the available address space if necessary.

Length :

Indicates the length of the parameter field.

Service ID :

1 byte value that represents the service that the request or response corresponds to.

Parameters :

A variable length field that has sub functions and other service specific parameters. Both the Request and Response messages follow the same structure and are differentiated by the value of the Service ID – the responses have their 6th bit set (Request | 0x40). For example, the ECU Reset service has a service ID 0x11 and its response will have the service ID 0x51.

The below picture depicts the frame format for the ECU Reset service (only the application PDU part)

The response ID is simply the sixth bit set of the requested value. As the response message has 2 bytes, the length is also updated accordingly.

UDS Services List

The Automotive UDS Protocol defines scores of services that can be used to perform a variety of operations on the server. These services include diagnostic session control, communication control, and routine control packets. The diagnostic session control service is used to establish and terminate a diagnostic session with the vehicle. It allows the diagnostic tool to switch between different diagnostic modes, such as default session, programming session, extended session, etc.

The communication control service is responsible for managing the communication flow between the diagnostic tool and the vehicle's ECUs. It provides mechanisms for flow control, error detection, and error recovery. The routine control service is used to initiate diagnostic routines, such as reading or writing specific data, executing tests, or configuring vehicle parameters.

Some of the major UDS services list along with their IDs is captured below.

Function group

Service

Service ID

Description

Diagnostic and Communications Management

ISO 11898

ISO 17897

ISO 17458

IEEE 802.3bw

ISO 21806

Physical Layer

2 Wire bus

1 Wire bus

2 or 4 Wire bus

2 Wire bus

Optical or 2 Wire bus

Throughput

125 Kbps/1Mbps

20 Kbps

10 Mbps

100/1000BASE-T1

25/50/150 Mbps

Transfer Trigger

Event

Event

Event & Time

Event & Time

Event & Time

Cost

Medium

Low

Medium

High

Very High

Max Nodes

127

16

64

30+

64

Master

Multi-master

Single-master

Multi-master

Multi-master

Multi-master

Bus Topology

Linear, star, or hybrid

Linear bus

Linear, star, or hybrid

Linear, star, ring or mesh

Daisy-chain

Applications

Soft real-time – wide

Body Control

Hard real-time Power Train

Soft real-time - Wide

Media

A special value of 0x7F is used to indicate negative response when an error occurs during the course of the service execution by the server.

These high-level services in the UDS services list form the backbone of the Automotive UDS Protocol and enable effective communication and diagnostics.

Design Considerations For Automotive UDS Protocol Implementation

The UDS protocol implementation requires careful consideration of various design aspects to ensure optimal performance and compatibility. Some key design considerations include:

Hardware and Software Compatibility :

The protocol should be implemented in a way that ensures compatibility with the vehicle's hardware and software. This includes selecting appropriate hardware components and implementing software modules that support the protocol's requirements.

Communication Interface :

The communication interface between the diagnostic tool and the vehicle's ECUs should be designed to support the protocol's communication requirements. This may involve selecting the appropriate communication protocols, such as CAN or Ethernet, and implementing the necessary drivers and interfaces.

Security and Authentication :

To ensure secure communication, the implementation should incorporate robust security mechanisms, such as encryption and authentication. This helps prevent unauthorized access and protects against data tampering.

Error Handling and Recovery :

The implementation should include mechanisms for error detection, error handling, and error recovery. This ensures reliable communication and prevents data loss or corruption in the event of communication errors.

Performance Optimization :

Optimizing the protocol implementation for performance is crucial to ensure efficient diagnostics and minimize delays in communication. This may involve optimizing data transfer rates, reducing overhead, and implementing efficient algorithms.

By considering these design aspects, automotive manufacturers and developers can create robust and effective implementations of the Automotive UDS Protocol.

Our Services For UDS Protocol Implementation

At Embien, we offer comprehensive services for Automotive UDS protocol implementation. Our team of experienced engineers and developers specializes in designing and implementing communication protocols for vehicle diagnostics. We have extensive knowledge and expertise in the Automotive UDS Protocol and can assist automotive manufacturers and developers in integrating the protocol into their vehicles. Our services include:

Firmware Design and Development :

We can help design and develop customized implementations of the Unified Diagnostic Services protocol tailored to specific vehicle requirements on any MCU or platform. Our team works closely with clients to understand their needs and has provided efficient and reliable solutions on top of Renesas, NXP, STM32 and Android platforms.

ECU Firmware Update :

Embien can provide support to perform update of ECUs in the vehicle network. We have helped achieve this capability for a wide range of devices using the UDS protocol. We have created gateways that download update images, act as a client and update other ECUs in the bus.

Integration and Testing :

We offer integration services to seamlessly integrate the Automotive Unified Diagnostic Services Protocol into existing vehicle systems and diagnostic tools. Our rigorous testing processes ensure compatibility, reliability, and performance.

Optimization and Performance Enhancement :

Our team can optimize the performance of the Automotive UDS Protocol implementation, improving data transfer rates, reducing latency, and enhancing overall efficiency.

Support and Maintenance :

We provide ongoing support and maintenance services to ensure the continued reliability and performance of the Automotive UDS Protocol implementation. Our team is available to address any issues or provide assistance as needed.

With our expertise and dedication to quality, we aim to deliver effective and robust implementations of the Automotive UDS Protocol, both server and client, enabling our clients to enhance their vehicle diagnostics capabilities.

Conclusion

This article explained the intricacies of the UDS protocol including the message structure and UDS services list. Our services at Embien can assist in the development, integration, and optimization of the protocol, ensuring reliable and efficient vehicle diagnostics. Contact us today to learn more about how we can help with your Automotive UDS Protocol development needs.

4 UDS Protocol Software Services that Every Automotive Product Development Team Should Know

July 8, 2025

Unified Diagnostic Services (UDS) is an automotive protocol that lets the diagnostic systems communicate with the ECUs to diagnose faults and reprogram the ECUs accordingly (if required).

It is called unified because it combines and consolidates all the standards like KWP 2000, ISO 15765 and others.

UDS services facilitate nuanced interactions with the vehicle’s control units, enabling precise identification and rectification of issues, efficient real-time data processing, and streamlined firmware updates.

Such capabilities are crucial in an era where vehicles are not just modes of transport but complex networks of integrated electronic systems.

The UDS Protocol transcends basic diagnostic capabilities, offering a suite of UDS services that cater to complex needs like ECU programming, real-time data monitoring, and fault diagnosis. For instance, the ‘ECU Reset’ service is crucial for ensuring proper function post-update or repair.

In this article, we will delve into four critical UDS services that are indispensable for any automotive product development team.

These UDS services are central to modern vehicle diagnostics, enabling accurate fault detection, real-time data access, and reliable ECU communication to ensure safety and performance.

What are UDS services?

UDS services are diagnostic functions defined in the Unified Diagnostic Services protocol (ISO 14229). They enable standardized communication between a diagnostic tester (e.g., scan tool, test bench) and an ECU.

Think of UDS services as a set of commands—like buttons on a remote—that let you interact with your vehicle’s Electronic Control Units (ECUs).

Just as a TV remote lets you change channels, adjust volume, or reset settings, UDS services allow engineers and technicians to perform diagnostic actions like reading data, resetting the ECU, or flashing new firmware.

Each service is identified by a unique hexadecimal Service ID (SID). These services support operations like reading sensor values, resetting ECUs, writing configurations, and flashing firmware.

Each UDS service is identified by a unique Service ID (SID) and performs a specific task.

Common UDS services include:

Service ID

UDS Service Name

Description

Typical Use Case

0x10

Diagnostic Session Control

Switches ECU to different diagnostic modes

Flashing, deep diagnostics

0x11

ECU Reset

Performs software or hardware reset

Post-update, memory reset

0x22

Read Data By Identifier

Reads ECU internal data

Sensor values, VIN, software version

0x2E

Write Data By Identifier

Writes configuration data to ECU

Updating calibration/config values

0x27

Security Access

Grants access to restricted services

Flashing, protected parameter changes

0x19

Read DTC Information

Retrieves diagnostic trouble codes

Fault diagnostics

0x31

Routine Control

Runs internal ECU routines

Self-tests, checksum verifications

0x34/0x36/0x37

Request Download / Transfer Data / Request Transfer Exit

Flashing process steps

ECU firmware update

How Do UDS Services Come Together: UDS Protocol Architecture

The UDS architecture is designed based on the Open System Interconnection (OSI) Reference Model. Hence, the UDS software stack has a layered architecture.

OSI Layer

UDS Stack Component

Function

Example Protocol

Application

UDS Services

Executes diagnostic functions (e.g., Read DTCs)

ISO 14229

Transport

Transport Layer Protocol

Segments and reassembles data

ISO 15765-2

Network

Network Layer (if applicable)

Routing between ECUs

Optional

Data Link

CAN/Ethernet Protocols

Handles frame transmission and flow control

CAN, DoIP

Physical

Bus Line/Connector

Electrical signaling and transmission medium

CAN, Ethernet

One of the major functions of the UDS software stack is to store the fault code in the ECU memory for every issue that occurs in the vehicle and transfer it (to the client side) as and when required.

The diagnostic tester tool has a GUI that connects to the ECU, retrieves the fault code and displays it.

These fault-related operations are handled by specific UDS services, such as 0x19 – Read DTC Information, which are implemented in the application layer of the UDS software stack. UDS services reside in the ECU's diagnostic software and are configured by the vehicle manufacturer or Tier-1 supplier based on system requirements.

Each service is mapped to a specific Diagnostic Identifier (DID), Routine Identifier (RID), or DTC, depending on the function it supports. Configuration is typically done through diagnostic specification files (e.g., Open Diagnostic eXchange), which define which UDS services are available, what parameters they handle, and how they behave during various diagnostic sessions (default, extended, or programming).

For example, a service like 0x22 – Read Data By Identifier will be configured to fetch specific ECU parameters such as engine speed or coolant temperature, while 0x2E – Write Data By Identifier allows certain parameters to be updated under secure access.

These UDS services, once configured and integrated into the ECU firmware, enable seamless communication between the tester and the ECU.

Why Do We Need Unified Diagnostics Services?

As OEMs integrate/assemble automotive ECUs and components from different suppliers, the need for a set of standardized unified diagnostic services was felt.

This is because, prior to a set of UDS services, OEMs and suppliers had to deal with compatibility issues between different diagnostic protocols like KWP 2000, ISO 15765, and diagnostics over K-Line.

• Unified Diagnostic Services (UDS) is the preferred choice of protocols for all off-board vehicle diagnostic activities. Off-board diagnostics refers to the examination of the vehicle parameters when the car is at servicing in the garage (while the vehicle is stationary).

• ECU flashing and reprogramming can also be performed efficiently with the help of a UDS stack.

• Additionally, UDS protocol is quite flexible and is capable of performing more detailed diagnostics as compared to other protocols like OBD and J1939.

List of Categories of UDS Services Offered by Unified Diagnostics Protocol

Unified Diagnostic Services has made stellar strides in simplifying ECU diagnostics.

Services like Diagnostic Session Control provide the flexibility to establish sessions tailored to specific testing needs, while ECU Reset facilitates seamless reinitialization for precise evaluations.

The Read Data by Identifier service allows direct access to critical data points, enabling real-time monitoring of sensor values and essential parameters.

Additionally, UDS-based Read Diagnostic Trouble Codes service enables prompt identification of potential issues, expediting the troubleshooting process. Let’s learn about them in more detail.

New Meta- Let’s know UDS protocol a little better! How about unravelling its pivotal services in our detailed article? We will learn how different UDS services enhance vehicle diagnostics and ECU management, making automotive technology safer.

1. Data Transmission Capabilities: The data transmission capabilities of a UDS Protocol Stack enable the clients to read or write any information to or from the ECU.The data can be read or written on the basis of identifiers and periodic identifiers. The client can also read data from the physical memory at the specified address.

   • The information can range from static info like ECU serial number to some real time data like the current status of the sensors, engine speed, etc.

   • If the client wants the ECU to send periodic service values, then ‘Read Data By Identifier Periodically’ service will be required. The client can also write data by identifier and address. Using the write service, certain parameters such as threshold values and angles can be changed.

   • Usually, the permission to write some sensitive data to the ECU can be controlled by restricting the access using ‘Security Access Service’. Such permissions are reserved by the OEMs, as writing data to the ECU can interfere with the security and overall functioning of the vehicle.

2. Diagnostic and Communications Management in UDS Protocol: This services group primarily focuses on managing the communication flow between the tester (diagnostic tool) and the electronic control units (ECUs) within a vehicle. Below is an overview of the services under this category:

   • Diagnostic Session Control (Service 0x10): Initiates different diagnostic sessions, each with unique communication and diagnostic capabilities.

   • ECU Reset (Service 0x11): Resets the ECU to its default state, useful after updates or error recovery.

   • Security Access (Service 0x27): Secures ECU functions via a challenge-response mechanism for protected access.

   • Communication Control (Service 0x28): Manages ECU communication, controlling message transmission and reception.

   • Tester Present (Service 0x3E): Keeps the diagnostic session active by signaling the ECU that the tester is still connected.

   • Access Timing Parameter (Service 0x83): Adjusts timing parameters like message timeouts and intervals for optimized communication.

   • Secured Data Transmission (Service 0x84): Adds a security layer to the data exchanged between the tester and ECU.

   • Control DTC Setting (Service 0x85): Enables or disables the generation of Diagnostic Trouble Codes (DTCs) during diagnostics.

   • Response On Event (Service 0x86): Configures the ECU to automatically respond to specific events for real-time monitoring.

   • Link Control (Service 0x87): Adjusts the data transfer rate between the tester and ECU to suit diagnostic needs.

Note: DTC Snapshot data gives additional information about the engine’s parameters at the time of occurrence of the fault.

The DTC information along with other data stored in the server can be erased if need be. Clear Diagnostic Information service can be invoked to delete all such diagnostics data stored in the server.

Once the fault codes are retrieved, the problem can be diagnosed efficiently, and repair work can follow.

1. Upload/Download Capabilities: As highlighted earlier, UDS protocol also supports ECU reprogramming. ECU reprogramming refers to updating the ECU software. This is required to resolve any existing bug or add newly developed modules in the ECU.Using the upload and download capabilities of UDS protocol, large packets of data can be sent and received from the car’s ECU for ECU reprogramming purpose.The client can invoke RequestDownload and TransferData service to initiate a data transfer to the server (ECU) from the client (diagnostic tester) using a tester device.

   • The server upon receiving the request will take all necessary actions to receive the data.

   • A positive response message is sent when the server has successfully received the message.

Likewise, a RequestUpload service is used by the client to request data packets from the server.

1. • One of its practical examples can be configuring the parameters related to the vehicle’s variant code. It implies that the client can download or upload the settings/configurations in order to change or adapt a particular variant.

   • Suppose a car has two variants and one of them has Anti-lock braking system (ABS) and the other doesn’t. The ECU of the variant with the ABS will need to be updated with configurations and settings to control the ABS. A task like this can be performed using this service.

2. Remote Routine Activation: Vehicle Diagnostics may require testing the faulty component in a given range of parameters. Moreover, during the testing phase of the vehicle, some system tests may be required to run over a period of time.

For all such tasks, UDS service named ‘remote routine activation’ is used.

1. • In order to perform a test, a routine is triggered by the client in the server’s memory. There are two methods for ending this routine - one is where the client interrupts the routine to stop it, and the other is when the server/ECU finishes the routine after a specified time frame.

   • Using this UDS service, the client can start a routine, stop a routine and also check the result that the routine produced after successful execution.

For instance, the service personnel at the garage may use this service to run the engine fan for a certain period of time and record the results. This would help him understand a particular issue well and rectify it without using any hit and trial method.

The Final Word

UDS is one of the most advanced and flexible diagnostic protocols in the automotive domain. It enables detailed, standardized diagnostics across vehicle systems. Its future remains strong, thanks to its ability to work independently of the underlying communication medium—whether CAN, K-Line, or FlexRay.

Introduction to Automotive UDS Protocol: Understanding the Basics for Effective Vehicle Diagnostics

In today's technologically advanced automotive industry, effective vehicle diagnostics are essential for ensuring optimal performance and diagnosing issues accurately. One of the key protocols used for vehicle diagnostics is the Automotive UDS Protocol – The Unified Diagnostic Services Protocol. In this article, we will take a closer look at the basics of the Automotive UDS Protocol, its functionalities, high-level packets, features supported, and the need for its implementation. The details of the underlying communication, packet structures, services supported etc. will be covered in another article - A Deep Dive Guide to Automotive UDS Protocol: How the Unified Diagnostic Services Work

The Need For Automotive UDS Protocol

In the automotive industry, the need for an effective and standardized diagnostic protocol is crucial. The complexity of modern vehicles, with numerous electronic control units and advanced systems, requires a robust communication protocol that can handle the diverse diagnostic requirements. The Automotive UDS Protocol fulfills this need by providing a standardized approach to diagnostics, ensuring compatibility across different vehicle models and manufacturers.

By implementing the UDS diagnostic protocol, automotive manufacturers can streamline their diagnostic processes, reduce development costs, and improve the overall quality of their vehicles. Service technicians benefit from a unified diagnostic approach, enabling them to diagnose and resolve issues more efficiently. Additionally, the protocol promotes interoperability between different diagnostic tools and software applications, facilitating collaboration and knowledge sharing within the industry.

What Is Automotive UDS Protocol?

The Automotive UDS Protocol, also known as Unified Diagnostic Services, is a communication protocol used in the automotive industry for diagnostics, debugging, and vehicle communication. It provides a standardized way for electronic control units (ECUs) in vehicles to communicate with diagnostic tools and software applications. The protocol is based on the ISO 14229 standard and is widely used by automotive manufacturers and service technicians.

Each of the ECU in the vehicle consumes and generates a lot of information. It is essential for both operational and diagnostics purposes that these data be available for other ECU’s or parties in a standardized way. The UDS protocol precisely serves this purpose where it could be used in one of the following scenarios.

Here the client, who originates the requests for diagnostics information, can be communicating with a standalone server. Or it can communicate with a server that acts as a gateway for one or more servers. With this, information from add-on vehicles such as trailers can be acquired by a gateway in the main vehicle and sent to other ECUs such as TCU or IPU etc.

UDS Communication Protocol OSI Layer Mapping

Before we take a deep dive into the UDS communication protocol, it is important to understand where it sits in the overall scheme of things. Standardized as ISO 14229, the UDS protocol sits on the Application layer of the standard OSI model.

The UDS can in fact run on any of the underlying physical layers such as CAN, Ethernet, LIN, FlexRay etc., though the picture covers only CAN and IP components. The core UDS communication protocol specification ISO 14229-1is independent of the transport with few extensions defined based on the transport such as ISO 14229-3 for CAN, ISO 14229-5 for IP and ISO 14229-7 for LIN. The UDS layer expects a reliable path for communication to be provided by the transport layer including packet segmentation and reassembly based on the underlying physical layer characteristics. While this article will focus entirely on the UDS application layer, the others will cover the transport specific DoCAN and DoIP.

Overview Of UDS Communication Protocol

As mentioned earlier, the UDS communication protocol employs a Client-Server mode of communication. The entity that is going to originate the communication is called the Client or Tester and the responding ECU is called the server. Typically, each of the servers has a unique address for which it will respond to.

Each of the communications is in form of a service request and response where the client initiates the service request and server responds to it. There are numerous services defined in the UDS protocol along with a Service ID. The response bits will have the 6th bit of the service ID set. A special value of 0x7F is used to indicate negative response i.e., error response.

Typically, a session is established using a service request and multiple services sent over the same session. Let us see with few examples below.

Flow of messages in UDS diagnostic protocol

Let us assume that the Client or Tester wants to read data corresponding to ID 0xF18C. Now typical flow of service messages will be as follows:

• Set up the session using the Diagnostic Session Control (0x10) service with sub function as

• Read the Data ID using the Read Data By Identifier (0x22) request with parameter as 0xF18C. For reading a DTC code, the services will be invoked in the following order:

• Set up the session using the Diagnostic Session Control (0x10) service.

• Set up the session using the Diagnostic Session Control (0x10) service.

Similarly for a Firmware Update use case the sequence of message will be:

• Set up the session using the Diagnostic Session Control (0x10) service.

• Set up the session using the Diagnostic Session Control (0x10) service.

Features Supported by UDS diagnostic protocol

The UDS diagnostic protocol supports a wide range of features that enhance vehicle diagnostics and communication. Some of the key features include:

• Diagnostic Trouble Code (DTC) Management: The protocol allows for the reading and clearing of DTCs, providing valuable information about vehicle faults and malfunctions.

• Real-time Data Monitoring: Technicians can retrieve real-time data from different ECUs, enabling them to monitor the performance of various vehicle systems.

• Bi-directional Communication: The protocol supports bi-directional communication, allowing for the execution of diagnostic tests, configuration of vehicle parameters, and activation of specific components.

• Programming and Reprogramming: With the UDS diagnostic protocol, ECUs can be programmed or reprogrammed, enabling software updates and enhancements.

• Security and Authentication: The protocol incorporates security mechanisms to ensure secure communication between the diagnostic tool and the vehicle's ECUs. Authentication and encryption techniques are used to prevent unauthorized access and tampering.

• Diagnostic Services: The protocol defines a range of diagnostic services that enable specific diagnostic operations, such as reading and writing data, executing tests, and retrieving information about supported services.

The various features supported by the automotive UDS communication protocol make it a powerful tool for vehicle diagnostics and communication.

Conclusion

The Automotive UDS Protocol plays a crucial role in the automotive industry, enabling effective vehicle diagnostics and communication. Its standardized approach, wide range of functionalities, and support for advanced features make it a preferred choice for automotive manufacturers and service technicians. While the protocol has its limitations, it continues to evolve, addressing emerging diagnostic challenges and supporting new vehicle technologies.

By understanding the basics of the UDS diagnostic protocol, its functionalities, and design considerations, automotive manufacturers and developers can leverage its benefits to enhance their diagnostic capabilities and improve overall vehicle performance. For more details on the UDS protocol internals, refer to the article on A Deep Dive Guide to Automotive UDS Protocol: How the Unified Diagnostic Services Work.

Introduction to Automotive UDS Protocol: Understanding the Basics for Effective Vehicle Diagnostics

In today's technologically advanced automotive industry, effective vehicle diagnostics are essential for ensuring optimal performance and diagnosing issues accurately. One of the key protocols used for vehicle diagnostics is the Automotive UDS Protocol – The Unified Diagnostic Services Protocol. In this article, we will take a closer look at the basics of the Automotive UDS Protocol, its functionalities, high-level packets, features supported, and the need for its implementation. The details of the underlying communication, packet structures, services supported etc. will be covered in another article - A Deep Dive Guide to Automotive UDS Protocol: How the Unified Diagnostic Services Work

The Need For Automotive UDS Protocol

In the automotive industry, the need for an effective and standardized diagnostic protocol is crucial. The complexity of modern vehicles, with numerous electronic control units and advanced systems, requires a robust communication protocol that can handle the diverse diagnostic requirements. The Automotive UDS Protocol fulfills this need by providing a standardized approach to diagnostics, ensuring compatibility across different vehicle models and manufacturers.

By implementing the UDS diagnostic protocol, automotive manufacturers can streamline their diagnostic processes, reduce development costs, and improve the overall quality of their vehicles. Service technicians benefit from a unified diagnostic approach, enabling them to diagnose and resolve issues more efficiently. Additionally, the protocol promotes interoperability between different diagnostic tools and software applications, facilitating collaboration and knowledge sharing within the industry.

What Is Automotive UDS Protocol?

The Automotive UDS Protocol, also known as Unified Diagnostic Services, is a communication protocol used in the automotive industry for diagnostics, debugging, and vehicle communication. It provides a standardized way for electronic control units (ECUs) in vehicles to communicate with diagnostic tools and software applications. The protocol is based on the ISO 14229 standard and is widely used by automotive manufacturers and service technicians.

Each of the ECU in the vehicle consumes and generates a lot of information. It is essential for both operational and diagnostics purposes that these data be available for other ECU’s or parties in a standardized way. The UDS protocol precisely serves this purpose where it could be used in one of the following scenarios.

Here the client, who originates the requests for diagnostics information, can be communicating with a standalone server. Or it can communicate with a server that acts as a gateway for one or more servers. With this, information from add-on vehicles such as trailers can be acquired by a gateway in the main vehicle and sent to other ECUs such as TCU or IPU etc.

UDS Communication Protocol OSI Layer Mapping

Before we take a deep dive into the UDS communication protocol, it is important to understand where it sits in the overall scheme of things. Standardized as ISO 14229, the UDS protocol sits on the Application layer of the standard OSI model.

The UDS can in fact run on any of the underlying physical layers such as CAN, Ethernet, LIN, FlexRay etc., though the picture covers only CAN and IP components. The core UDS communication protocol specification ISO 14229-1is independent of the transport with few extensions defined based on the transport such as ISO 14229-3 for CAN, ISO 14229-5 for IP and ISO 14229-7 for LIN. The UDS layer expects a reliable path for communication to be provided by the transport layer including packet segmentation and reassembly based on the underlying physical layer characteristics. While this article will focus entirely on the UDS application layer, the others will cover the transport specific DoCAN and DoIP.

Overview Of UDS Communication Protocol

As mentioned earlier, the UDS communication protocol employs a Client-Server mode of communication. The entity that is going to originate the communication is called the Client or Tester and the responding ECU is called the server. Typically, each of the servers has a unique address for which it will respond to.

Each of the communications is in form of a service request and response where the client initiates the service request and server responds to it. There are numerous services defined in the UDS protocol along with a Service ID. The response bits will have the 6th bit of the service ID set. A special value of 0x7F is used to indicate negative response i.e., error response.

Typically, a session is established using a service request and multiple services sent over the same session. Let us see with few examples below.

Flow of messages in UDS diagnostic protocol

Let us assume that the Client or Tester wants to read data corresponding to ID 0xF18C. Now typical flow of service messages will be as follows:

• Set up the session using the Diagnostic Session Control (0x10) service with sub function as

• Read the Data ID using the Read Data By Identifier (0x22) request with parameter as 0xF18C. For reading a DTC code, the services will be invoked in the following order:

• Set up the session using the Diagnostic Session Control (0x10) service.

• Set up the session using the Diagnostic Session Control (0x10) service.

Similarly for a Firmware Update use case the sequence of message will be:

• Set up the session using the Diagnostic Session Control (0x10) service.

• Set up the session using the Diagnostic Session Control (0x10) service.

Features Supported by UDS diagnostic protocol

The UDS diagnostic protocol supports a wide range of features that enhance vehicle diagnostics and communication. Some of the key features include:

• Diagnostic Trouble Code (DTC) Management: The protocol allows for the reading and clearing of DTCs, providing valuable information about vehicle faults and malfunctions.

• Real-time Data Monitoring: Technicians can retrieve real-time data from different ECUs, enabling them to monitor the performance of various vehicle systems.

• Bi-directional Communication: The protocol supports bi-directional communication, allowing for the execution of diagnostic tests, configuration of vehicle parameters, and activation of specific components.

• Programming and Reprogramming: With the UDS diagnostic protocol, ECUs can be programmed or reprogrammed, enabling software updates and enhancements.

• Security and Authentication: The protocol incorporates security mechanisms to ensure secure communication between the diagnostic tool and the vehicle's ECUs. Authentication and encryption techniques are used to prevent unauthorized access and tampering.

• Diagnostic Services: The protocol defines a range of diagnostic services that enable specific diagnostic operations, such as reading and writing data, executing tests, and retrieving information about supported services.

The various features supported by the automotive UDS communication protocol make it a powerful tool for vehicle diagnostics and communication.

Conclusion

The Automotive UDS Protocol plays a crucial role in the automotive industry, enabling effective vehicle diagnostics and communication. Its standardized approach, wide range of functionalities, and support for advanced features make it a preferred choice for automotive manufacturers and service technicians. While the protocol has its limitations, it continues to evolve, addressing emerging diagnostic challenges and supporting new vehicle technologies.

By understanding the basics of the UDS diagnostic protocol, its functionalities, and design considerations, automotive manufacturers and developers can leverage its benefits to enhance their diagnostic capabilities and improve overall vehicle performance. For more details on the UDS protocol internals, refer to the article on A Deep Dive Guide to Automotive UDS Protocol: How the Unified Diagnostic Services Work.

Diag1.0

Hello everyone, so today we will discuss about the line setup and also about the DVC file. So let

me first go through the DVC file. So before coming to this class, before going to this recording,

make sure that you have gone through the rain light sensor video plus the rain light sensor PDF

and the textual information about the project.

So those videos and the textual information, the literature covers what is rain light sensor, how

does it work, why do we need it and how does it interface with the other modules in the car. So

before starting this particular recording, probably go through the videos, pictures and then you

will be ready to understand this recording. So to start with the DVC file, I think before this you

would have already gone through the recording of CAN basics and then both class 1 and class

2. So those classes will give you some idea about how CAN protocol works, then what are the

different training areas and different concepts involved in CAN communication.

So now whatever I am showing you on the screen is called the DVC file. This file basically

structures how and what kind of messages, what kind of signals are transmitted, different

modes of the CAN channel in the car. So at the lowest level, you will understand that in a CAN

frame, there can be a maximum of 8 bytes.

And those 8 bytes will be having a combination of data. So this data can vary from 1 bit

information to let's say 2 to 4 bytes of information. So information like ambient temperature,

information like engine on or off, ABS, anti-lock braking system, active or active or non-active.

Brake pedal pressing on or off, which gear the vehicle is moving on, whether the AC is on or

not, whether the infotainment channel is on or not, are you using active cruise control or not,

whether your brake pedal is pressed or not, whether your parking brake, hand parking brake is

active or not. So all this information flows around between different ECUs in the car in the form

of signals which are clubbed into the system. So why do we need this information to flow? So

that the different ECUs get the right kind of information.

And based on that information, they can perform their functionality. So at the lowest level,

there would be signals. The screen I am showing you just a few signals.

These signals will vary in size. If you see the length here, it is between 16 and 32 bits. The

signals will vary in size.

Multiple signals would be clubbed into a message. And then when these signals are clubbed

and the maximum length of 8 is achieved, then there would be a message ID assigned to that

message. And then each and every message will have a transmitter and it will have a receiver.

So signals, multiple signals combining two messages. Here you are seeing messages. Then

there are different messages.

3F, 30F, 30E. That means these messages are having different combinations of these signals in

their 8 bytes of data. And these messages are attached to the nodes in terms of DX messages

and RX messages.

So here you see there is a debugger which is transmitted by the network. And there is a

message called 30B which is received by the worker control. Worker control is the project that

we will discuss.

And these nodes are attached to the network. That means CAN channels. Every node will be

attached to at least one CAN channel.

Each node would have multiple DX and RX messages. These DX and RX messages would have

message IDs. In our case, this is 30F and 30E as an example.

And each of these messages would have signals. You see here, double click on this message.

You see signal layout like this.

Which is a matrix of 8x8. Why it is 8x8? Because there can be 8 bits in a byte. And there can be

maximum 8 bytes in a message.

So the layout of the information can be represented in 8x8 bit. It is not necessary that every

message has to carry 8 bytes. But at maximum, it can carry 8 bytes.

And it is advised that we use messages to the maximum capacity. So that once the arbitration is

done, is won by a node, then the maximum information can be sent or be transmitted to

receiver in one shot. Otherwise, if we design the messages in such a way that only few signals

are clubbed into messages, then every time the signals are to be transmitted, then the node

has to win the arbitration.

But suppose if these arbitration IDs are of lower quality, then there could be a lot of delay in

sending the information. So possibly the network architecture tries to club as much information

in 8 bytes. So that once the arbitration is won, the maximum payload of the information can be

transmitted from the sender to the receiver.

So just to summarize, signals which are independent variables of variable sizes from 1 bit to 4

bytes can be clubbed into 8 bytes of data frame. And that frame would have a message ID.

Multiple messages can be formed for a node.

Those messages would be classified as PX message and RX message. Because every message

would have a transmitter. And there would be at least one receiver of that transmitter message.

If let's suppose a node is transmitting a message, but no other node is receiving it, then there is

no point of that transmission. It can also be removed. There is no need of that transmission.

So every message would have at least one transmitter. Or would have only one transmitter. Not

at least.

Will have only one transmitter. And then it can be received by one node or multiple nodes. And

these messages are attached to the nodes.

To the transmitting ECU. And every node would have PX message. And they would also receive

some messages.

Each of the nodes would be linked to at least one network in that N line. So messages. So the

hierarchy goes like this.

Signals clubbed into messages. Messages attached to the nodes. And nodes attached to the N

lines.

So this particular layout that you are seeing on the screen, is given as an input to the supplier

by the OEM. So OEM, the original equipment manufacturer, basically companies like Tata

Motors, who are making the vehicle cars, they have a team of system engineers and network

engineers. Decides what are the different ECUs in the car.

And how these ECUs would communicate to each other. And what kind of information will flow

between these. So that every node gets the inputs at the right time.

So each of these messages also have a transmission time. At what periodicity they will be

transmitted. So that the other nodes keep on receiving the information at the appropriate time.

So information which is very critical for the functionality of the whole vehicle, is transmitted at

10 millisecond, 20 millisecond time stamp. And the information which is not that critical, can be

transmitted at 0.1 millisecond, 1 second kind of time frame. But all of these messages that we

have discussed so far, they are application messages, because they are needed by the different

application ECUs to work properly.

And most of them and all of them are periodic messages. That is they have a periodicity. And

like if you see here, there is a name, then there is an ID, then DLC, transmitter, and cyclic time.

Here they have given for example 0, but here exactly you put the transmitter time. So there is a

transmitter of this module, and there is a receiver. So every message will have periodicity.

So these are called application messages. These are used for transmission of, which are used

for transmitting the signals from one node to another, and needed by the application to work

properly. Another kind of messages are which are used for diagnostics, which are event-based

messages.

Why event-based? Because diagnostics is not something that will be continuously done during

the running of the vehicle. So those messages are event-based. Whenever there is a problem,

the vehicle will be taken to the garage, and the tester tool will be connected to the OBD line or

the CAN line through the OBD connector, and then the diagnostic messages will take place.

So those are event-based messages. Whatever you are seeing on the screen, this particular file

is for application messages. So OEM would provide this information to every supplier, and the

supplier has to make sure that their ECUs transmit and receive information according to this

configuration, these parameters, and their ECUs are able to provide optimum functionality by

meeting these parameters' deadlines.

So this is how the DPC file looks like and the utility of the DPC file. So after this, we will discuss

about the setup on the bench. How would you simulate or do the testing in your bench setup?

Now this particular slide that you see is basically how will the setup look like in a bench, in a lab

environment.

As you have seen earlier that every node that you are having on the CAN line would have a CAN

controller, and then it will have a CAN transceiver. Since our laptop does not have a CAN

controller and a CAN transceiver, it will need an external hardware to play a part of it, part of

the controller, and then ultimately the transceiver. That is where this CAN case is ultimately

used.

The host PC, which would be a laptop or a desktop, will have a GUI tool in which you can

formulate the messages to be sent to the CAN line, and you can also simulate different nodes

which are present on the vehicle. So in our actual testing, we will only have one ECU, which we

are supplying to the customer or for which we are doing testing. All the other ECUs from which

this node would be taking inputs or probably supplying outputs would be simulated in the host

PC.

In this particular example, the host PC will have a canoe installed. So that is an interface

software which will help you to create the nodes or simulate the nodes which are there on the

vehicle, which are needed for your device under test to work properly. And you can simulate or

create diagnostic messages on the host PC and send it on the CAN line.

But how would you send it on the CAN line without a CAN controller? So that is where this box

CAN case comes into picture. This CAN case is supplied by a company called Vector Informatics.

So form your test tool, form your host PC which is laptop or a desktop, which is connected to a

CAN case through a USB wire.

One end goes to the laptop, another goes to the CAN case. Through that wire, the information

from host PC, laptop or a desktop or the number of messages that needs to be transmitted or

the message that we have formulated and that needs to be transmitted or received would be

sent to the CAN case. So the CAN case has a CAN controller which will formulate those

messages inside the CAN controller and through the transceiver it will put it on the CAN line.

So the CAN line which is being manipulated by transceiver will carry the electrical signal to the

device which is under the test. So this device which is in our case on the screen is an

infotainment issue would also have a CAN connection. So those wires from the infotainment

cluster goes into the or connects to the CAN line of the CAN case.

And that is why they are able to communicate on CAN. This IC or instrument cluster will also

have a connection for battery high and low and then a connection that is not shown in the

diagram. So this is more for the CAN connection how it takes place.

The main thing to understand from this is that in the lab environment we will only have one

ECU. It could be instrument cluster, it could be a braking system or it could be rain light sensor,

e-locker. Whatever the ECU that we are trying to test that will only be present with us.

And this testing is called as HIL hardware in loop. Because you are actually having a hardware

that is what you are trying to test. So this is hardware in loop testing.

This hardware here which I have shown on the screen is the device which is under the test. So it

will have connection for CAN line high and low. And it will have a battery connection.

Battery high and low plus ignition connection. Ignition means that when we switch on the car

we plug in the key right. So that is the ignition connection which is also shorted to that.

With that it will have a CAN line which connects to the CAN case. And CAN case on the other

side connects to the host machine, the laptop. So the software inside the laptop basically acts

both as a simulator for your car.

So that the signals that are needed by the instrument cluster or the device under test can be

sent from the host machine. And if we are doing some diagnostic testing then we can also

simulate the diagnostic scan tool through this host machine. So it acts both as a simulator for

the car.

Issues that are inside the car and the diagnostic scan tool which is ultimately used in the garage

for diagnostics. But here the lab environment is simulated using this particular CAN-O-E tool. So

that is how the diagnostic setup looks like.

So now we will go to the project that is in discussion. Here we have listed two different projects.

Before starting this recording make sure that your instructor has shared with you the literature

and the videos related to this project.

And then only it will make sense for you to come and watch this recording and this video so

that you already have a base of what exactly is this diagram. So this particular diagram on the

screen that you are seeing is called electrical interface or system level diagram for your ECU. So

as explained earlier, your rail light sensor is the project that will be in discussion throughout the

duration of this course.

And why we have taken this project? Because it kind of simulates a real time ECU. It covers all

the complexity of the automotive ECU and probably not very complex in working so that you

can understand the functionality in an easier way. So the rail light sensor ECU on an electrical

level would have a battery connection which will work between 8 to 16 volts.

This battery is the battery that is used in the car. Basically works between 8 to 16 volts. But the

normal working voltage in the car would be anything between 12 to 13 volts.

But the range is from 8 to 16 volts. Below 8 volts, all the functionalities of the ECU might not

work. And above 16 volts, it will be also not adequate.

And for that also there would be an ETC set or a fault code set. Then there is an ignition line

which is shorted to battery type. And this short happens when your key is plugged into the

steering column and the cranking is done.

Even though this connection is always there, but the ignition becomes active only when the key

is plugged in. As you see in the car, most of the ECUs which are battery fed ECUs or ignition fed

ECUs, they are always connected to the battery. But they start working only when the ignition

signal is given, only when the key is plugged in.

In our home environment, household environment, you can relate this to your fan which is

always connected to the electricity, but it starts working only when the switch is on. Same way,

the ECU is always connected to the battery, to the power source, and it only works when the

ignition is given. It only switch on when the ignition is given.

So in the lab environment, the battery is the variable power supply which converts your AC

voltage of 220 volts to a DC voltage that is between 5 volts to 20 volts and probably more. So

that is basically a variable power supply which has a knob through which you can convert the

output voltage or change the output voltage for anything between 5 to 16 volts. So coming

back to the ECU, so ECU has a CAN controller, it has a transceiver, and obviously it has other

components also which are irrelevant for our discussion.

So that is why I have not put it. But it's not that only CAN controller and transceiver is there.

There are so many other components that are connected.

But for simplicity, I have only highlighted what is relevant for discussion on CAN and ICS. So

drain light sensor ECU is connected to the wiper motor. This wiper motor basically controls the

wiper on your windshield.

So it has a motor high and motor low connection which rotates at three different speed, high,

medium, low, depending on the amount of rain that is falling on the windshield. So how do you

detect the amount of rain that is falling on the windshield? It is through the drain by light

sensor. So this sensor works on the principle of heat fracture which is explained in the video

that has been sent to you.

It has some diodes which measure the amount or intensity of light that is coming back after

refraction when it is going from the glass to the water. So that concept can be understood from

the video. Basically, depending on the amount of water that is falling on the windshield, the

drain light sensor output will vary and it will be given to the ECU.

So in the lab environment, this sensor is in a real car. This sensor is plugged into the windshield

of the vehicle so that the amount of water that is falling can be measured by the drain light

sensor. In the lab environment, we might not use this sensor, even though we might have it,

but we will not use it because we don't want to put the sensor into the water or we don't want

to play around with water in the lab environment.

That is why we replaced this sensor which is providing analog voltage which is converted into

digital counts by the microcontroller by a potentiometer. So in the potentiometer, you can

change the resistance of the potentiometer to change the output of the potentiometer or input

to the ECU in terms of the voltage and at different voltages, the wiper motor is commanded

with different speeds. So this feature is there in the luxury segment cars and in the normal cars,

it has to be controlled manually.

So there is a knob below the steering column which controls the drain light, which controls the

wiper motor speed and the driver manually controls it. On the high-end cars, this is automated.

So the wiper will start wiping and will change its speed based on the amount of drain that is

falling.

And detection of the rain and the light is done by this. So the wiper motor or the wiper speed is

automatically controlled based on the input of the sensor which is attached to the windshield.

And I spoke about the rain till now, but why it is rain and light both? Because based on the light,

the ambient light, your front headlamps can also be controlled.

Let's take a scenario in which you are going through a tunnel and you would have experienced

that inside the tunnel, the visibility is very low. Sometimes during the rainy season, the visibility

drastically goes down suddenly. So in a manual operation, the light has to be switched on.

But when you have an automatic rain light sensor issue, this sensor also detects the ambient

light. And based on the ambient light, it will try to send a signal to the PCM module which will in

turn send or enable the headlamps which are placed at the left and the right. So the ambient

light, if goes down suddenly, would trigger a signal to rain light sensor issue through this

sensor.

And the rain light sensor issue will send a DX message which will be received by body control

module PCM. And it will switch on the lights, the front lights, left and right headlamps. And the

other way is also true.

If it is sunny, bright, and you are driving, then probably the sensor output would trigger a

switch off signal to the rain light sensor issue. And through the DX message, the PCM will be

contacted to switch off the lights. Why PCM? Why it is not directly connected? Because body

control module basically controls all the outputs of the car.

And based on the proximity also, it makes sense to have a physical connection from body

control module to the lights because the PCM is usually placed on the bonnets. And that is why

this wiring cost can be saved. That is why the PCM controls the lights.

But the command to control the lights is given by the rain light sensor. And it is automatically

switched on and off. So that is how the physical connection works.

So electrically, if you see, there are only six connections. Two in the motor, high and low. Two in

the rain light sensor issue.

And then two in the battery, one in the ignition. Other than that, there is a CAN signal, CAN

connection on the CAN line which is terminated by 120 ohms resistance. And there are two

modes which the rain light sensor issue actually takes input from.

So one of that is ABS and other is PCM. So PCM, why? Because it controls the headlamps which

are physically connected to PCM. And then PCM also supplies the rain light sensor issue, the

ambient temperature.

Ambient temperature means outside temperature. So that outside temperature is measured by

the PCM. So why do we need outside temperature? So outside temperature is needed in

scenarios when let's say you are in a place where there is a lot of snow.

And when you wake up in the morning, the whole car is covered by the snow. Now, during that

situation, if the rain light sensor or the wiper motor is commanded by the automatic system,

then because there is so much of snow on the windshield, there are high chances that wiper

will break. So this sensor connected to the PCM, which is the ambient temperature sensor,

would detect that your outside temperature is lower than the inside temperature.

That means there are high possibilities that snow is there on the windshield. So based on the

ambient temperature and the inside temperature, ambient means outside temperature and the

inside temperature of the car, the rain light sensor issue might decide not to enable the wiper

motor so that it can start the heater first, help the snow to melt down and then start controlling

the wipers. So that is where the ambient temperature plays a role for the rain light sensor

issue.

And it sends the ambient temperature to the rain light sensor issue through this RX message,

which is shown in the diagram as RX ABS and RX DC. So why ABS? So ABS is basically anti-lock

braking system. It has all the four speeds from the wheels and sends that information on the

bus.

And based on the wheel speed, it calculates the vehicle speed and that is also sent to the car.

How does the speed help rain light sensor issue? You would notice that same rain when you are

standing on a place might not affect you, but if the intensity of the rain remains the same and

you are running at a high speed, then it will look relatively higher than standing at a place. So

your relative speed of the wiper should be moduled or controlled based on the speed at which

you are driving the vehicle.

So that kind of manipulation or the control of wiper can be done to know the vehicle speed. So

that is why you need all four speeds and vehicle speed from ABS module to the rain light sensor

to work properly. So that is why that RX message is received in BCM, sorry from ABS and BCM.

So since in the lab environment, you would neither have ABS module nor you will have BCM

module, you will only have rain light sensor issue. Both of these ABS and BCM, they are

simulated in the laptop through the Canoe AI chip block, which you will learn later. And that

information is passed through CAN kits to the CAN line.

So when your laptop, the Canoe tool, which you will install it in your laptop, down the line, you

simulate the messages from ABS and BCM and send it on the bus. Then the rain light sensor

has no way of finding whether these are simulated messages or whether it is actually attached

to BCM and ABS module. And that is why the rain light sensor will feel and work as it is in the

car and it will give the functionality as it is actually running in the vehicle.

So that is how this kind of setup is very close to the actual working environment. And through

the laptop and probably the CAN case, you will simulate all the messages and the nodes which

the rain light sensor issue is communicating to. And also you will send diagnostic messages

through the laptop Canoe window to the CAN case and then ultimately the rain light sensor

issue.

So through the laptop you are simulating the vehicle nodes and you are also simulating the

diagnostic tool. That is done in the Canoe window. And since the laptop doesn't have a CAN

module or a transceiver, the CAN case, which was shown in the previous slides, would help you

to formulate the CAN message, change the voltage level of the CAN line and help in

transmission and reception of the CAN messages, both from rain light sensor and ABS and BCM

module.

So that is how the setup is made in the lab environment. Coming back to or going forward to

differential locker. So you would have seen the videos of differential locker.

Electrically if you compare differential locker with the rain light sensor issue, I would say

electrical connection remains the same. Power supply with battery voltage and then instead of

wiper motor there is electromagnetic coil. And then a sensor which detects the proximity of the

coil or the movement of the coil, whether it has reached the desired distance when it is

triggered.

And if that distance is reached, then a feedback would be given by the sensor. And through the

CAN message, the indication would be given to the BCM. And the switch which is there on the

backboard is triggered on.

So just to give you what the differential locker does in the real-time functionalities, real-time

working. You would have seen the videos and you would realize that a differential basically

helps you to have different speed of rotations of the inner and outer wheels during the turning

situation. Now if there is a vehicle, then depending on whether it is rotating right or left, you

would realize that the outer wheel will cover more distance compared to inner wheel.

And that is why you need a mechanism such as differential so that both of those wheels are

able to rotate at differential speeds when they are different between the curvature of the inner

wheel and the outer wheel. And when they are going on the same plain road, in a straight road,

then both of them would be rotating at the same speed. So that is the functionality of the

differential.

What is the problem that arises with this differential rotation? You would have seen in a lot of

scenarios, sometimes one of the tires gets stuck in mud. Or one of the tires can start rotating

on an icy surface. Or one of the tires can start rotating on an oily surface.

Basically, wherever the coefficient of friction reduces, which is called as mu. So in those kinds of

situations, in order to come out of the slipping scenario, the driver applies a lot of acceleration

on the acceleration pedal. Once the torque is increased, the acceleration is increased, or the

power is given to the accelerator, all the torque goes to the slipping wheel.

And the wheel that is not slipping, standing, it will keep on standing there only. But the slipping

will start rotating more faster. And the vehicle remains there only, it doesn't go forward.

And the wheels start slipping. Most of the times this happens in an off-roading condition. And

in the snow areas, and in countryside terrain, you will see a lot of this happening.

Or even on beaches, where one of the wheels is stuck in the sand or mud. So the solution for

this problem is that inside the differential, there is a magnetic coil. When the driver sees that

one of the wheels is slipping, this is usually applied to the rear wheels.

And in our discussion, we will keep it to the rear wheels only. So when the driver sees that there

is a slip in the rear wheel, and since the rear wheel is slipping, then the vehicle is not able to go

forward. If it is a rear wheel driven vehicle, like most of the SUVs and trucks and buses, most of

them are rear wheel driven vehicles.

The engine is there in the front, but the torque is given from the rear to propagate the vehicle.

Once the driver sees that the rear wheels are slipping, one of the rear wheels is slipping, then

there is a button given on the dashboard. And that button is basically an instruction to the

differential locker that it should energize the magnetic coil and lock the differential.

So once the magnetic coil is energized, then it will do a lateral movement. And then with that

movement, the grooves between the left and the right would be tightened. You would have

seen that in the diagram also.

So by energizing the magnetic coil, there is a magnetic flux created. And through that

movement, the coil makes sure that the left and the right get intact. The grooves from the left

or the right goes into the grooves of the other side.

And then the whole system is on its path. After energizing the coil, whether the coil has traveled

the desired distance and whether those grooves are intact or not, that is judged by the sensor,

which is the proximity sensor. And the feedback is completed and given to the e-locker ECU.

If the feedback is completed, then the locker would take that information and pass it on to the

ECM module and ultimately to the e-locker switch. Before the locking mechanism, there is a

small LED on the e-locker switch, which is just a normal switch as we use it in our homes,

normal press switch. There would be a red LED blinking in an unlocked situation.

And once the locking mechanism completes, then that red color would be converted into green

color. That means the locker is engaged. So once the locker is engaged, and now if you press

the accelerator, the left and the right wheels will be given equal torque.

The torque distribution would be equal. And because of the wheel which is not in the mud, the

other side, it will move ahead and that will also drag the mud or slipping forward. That is how

the vehicle will move out of the slip condition.

So usually in an unlocked differential, the torque or the power goes to the slipping wheel. But

after the locking mechanism, the torque and the power would be equal.

Diag1.1

of the wheel which is not in the mud, the other side, it will move ahead and that will also drag

this wheel which is stuck in the mud or slipping forward and that is how the vehicle will move

out of the slip condition. So usually in an unlocked differential, the torque or the power goes to

the slipping wheel but after locking mechanism, the torque and the power would be given to

both the wheels. The whole axle will behave at a solid bar and that is when one tire moves

forward, the other tire will also be dragged forward and once they come out of the slipping

condition, then they will be unlocked again and both will start moving as earlier.

So that is how an e-locker is working. One of the, what do you say, important safety mechanism

that is implemented here is that when the driver sees that one of the wheel is slipping, he

should stop the vehicle and then try to lock the differential. If the driver tries to lock the

differential when the wheels are rotating, then due to the inertia and the momentum, if the

magnetic coil is energized when one part is moving at a very high speed and other side of the

gear is not rotating, then there are high chances that the gear will break and that is why to

provide safety to the mechanical part, e-locker internally implements a safety mechanism in

which the magnetic coil will not be energized unless and until the wheels are rotating at less

than 5 kilometers per hour speed and because of that, we need ABS module to interact with the

differential locker because the ABS module provides the speed of left and right and the whole

vehicle, so that is why you will see ABS module on the tandem and the BCM is needed because

the e-locker switch is connected to the BCM module because of proximity and then when the

switch is commanded, the BCM sends a message to the e-locker to magnetize the coil and

based on the wheel speed and the vehicle speed, the e-locker takes the command and sees the

speed and then tries to energize the electromagnetic coil.

If the one of the wheels is slipping, it is rotating at a very high speed and even though the

switch is pressed by the driver, then the command would be ignored so that it avoids the

breaking of the mechanical parts. In order to have the magnetic coil work and probably both

the left and the right part of the differential gears to synchronize, both of them should be

running or should be there at the same speed. Their rotatory movement cannot be on the

different speeds, so that is the safety mechanism implemented.

So on the mechanical interface or electrical interface, it remains same as the rain light sensor.

There is a battery, high and low, shorted with the ignition wire. The electromagnetic coil again

has high and low, plus and minus sensor is for the feedback again high and low.

So here sensor basically gives a digital value which kind of signifies whether the

electromagnetic coil, after energizing, it actually locked the differential or not, so that is the

feedback mechanism. If the locking happened, then the e-locker light will go from red to green

and then that change of LED would be done by the PCM module. So the indication of locking

complete is given through a DX message to the PCM and PCM displays that on the e-locker

switch.

An ABS module is needed so that the wheel speeds and the vehicle speeds can be determined

and the locking mechanism can happen appropriately. Another safety mechanism is that when

the differential is locked and suppose the driver forgets to unlock when it starts driving on a

normal road, as soon as the vehicle speed goes beyond 5 km or 10 km depending on the

threshold, the e-locker issue will automatically de-energize the magnetic coil so that both the

left and the right can move at a variable speed. So that is another safety mechanism, otherwise,

if you try to run on a high speed with a locked differential and take a turn, there are high

mechanism that the outer or the inner wheels would drag or they might break the gears inside

the differential, so that is the second safety mechanism.

And again, during the lab environment, we use CAN case to communicate to the e-locker issue

and through the CAN-OE window, we simulate the ABS and PCM module and this e-locker

switch can be simulated with a CAN message coming from PCM to the e-locker and the e-locker

will be sending the status of the magnetic coil to the PCM through the DX message. So that is

how the e-locker mechanism works. So physically, if you see, both of these projects, electrically,

they have the same connections and that is why it is easier to remember and easier to

understand and overall, they have kind of same set of all problems, so this is about the

functionality of rain light sensor differential locker.

The next class when we come in, we will start discussing about the rain light sensor issue and

the diagnostic requirement. So during the discussion, we will use one of the issues for

discussion. Everything would remain the same in terms of diagnostic requirements and

wherever there is a difference, the difficulty will cover that.

Okay, thank you and I will see you in the next class.

Diag2.0

Now we have covered TAN protocol, we have seen what the PC file is, we have discussed about

the two projects that will be used throughout the discussion of the course that is the In-Light

Sensor and the E-Locker and today we would be discussing about the E-Diagnostics protocol.

So, the Diagnostics or UDS 14229 document is a universal protocol that kind of governs the

communication between the scan tool which is called as the tester and the issues that are

present in the scan line, so the exercise that you are seeing on the screen is basically having all

the relevant diagnostics requirements for a particular issue. So this particular exercise has the

minimal requirement that should be implemented in any issue irrespective of whatever the

kind of application it is supporting, so here the information is given to you in an excel format, it

could also be given to you in a word format or a PDF format but at the least the minimal

information that you need to get the diagnostic working is mentioned here.

So, don't worry about the format, you will receive a similar kind of document from the

customer, when I say customer if you are working in a tier 1 company then it would be the OEM

and if you are working in a service company then it could be any company for which you are

trying to test the product. So, writing the requirements for the products is the responsibility of

the system engineers or the requirement engineers, so they will formulate both the diagnostic

testing and the functional testing and you would be given something like this as a requirement

document. Don't worry about the naming conventions and the numbers given in this particular

sheet, this information it could vary from product to product or supplier to supplier but the

concepts are very important irrespective of any issue that you do the testing for, this concept

could be readily used.

So, let's start with the diagnostics requirements, so if you see the first requirement say

diagnostics database is CAN-C that means this particular issue for which we are trying to do the

testing is attached to a CAN network which is named as CAN-C, so vehicle can probably have

multiple CAN networks and they can be named as A, B, C, there is no logic to the naming

convention, it's just a mere number of products used for signifying different CAN channels on

the vehicle. So, we are assuming for now that all these requirements are for inline sensor and

similarly for e-locker and both of those issues are attached or nodes are attached to CAN

channel C. So, if there is a CAN channel then obviously there will be a baud rate on which they

will communicate, 500 or 512 kbps is the baud rate of this CAN channel. So, as you know in the

CAN the baud rate can go to maximum 1 mbps and it can start from 128 to 512 to 256 kbps and

of those I would say 512 is the slow CAN network and 1 mbps is the fast CAN network, so this

issue is attached to 512 kbps baud rate CAN channel which is called as CAN-C.

Then it says diagnostic requirement ID and diagnostic response ID. So, diagnostic request ID

779. Now, what do you mean by diagnostic ID? So, as soon as the vehicle is taken to the garage

because of any problem as we already discussed there would be a scan tool which will be

connected through the OBD connector to the CAN line of the vehicle.

This scan tool will send multiple requests to different issues or single issue. So, each of those

requests would go on the CAN and ultimately it will go through a CAN ID, message ID. When it

comes to lab environment that message of diagnostic would be simulated in the laptop and

through CAN case it will be sent to the rain light sensor ECU.

So, in the lab environment we are trying to simulate the diagnostic tool with the help of CANary

tool software and the CAN case as a hardware. So, the request which ultimately will go from the

tested tool in the garage are sent to each ECU or a particular ECU. So, for that we need a

message ID and that number we have assumed to be 779.

So, in your laptop you will simulate a message 779. It will be a diagnostic message very similar

to how it will go on the garage to the diagnostic tool. And if that request is going to a particular

message ID, particular ECU, in our case rain light sensor ECU, then it is called as physical

address.

What do I mean is that the message from your diagnostic tool is going to a particular ECU and

that addressing is called as physical address. 779 is the message name from the diagnostic tool

going to a message ID, going to a rain light sensor ECU. And the rain light sensor ECU will

respond to the diagnostic tool using a message ID 778.

Don't worry about this message numbers 779 and 778. These are arbitrary numbers that I have

chosen. They can vary from ECU to ECU and they can vary from configuration to configuration.

I have just taken some numbers. When the communication happens between the tester tool

and the ECU one to one, then it is called as physical address. And for that kind of

communication, 779 and 778 would be used.

779 would be used by the tester tool to send the message to the rain light sensor ECU or the

local ECU. And 778 would be used by the eLocker or rain light sensor ECU to respond to the

tester tool. But suppose there is a situation in which the tester tool wants to communicate to all

the ECUs on the CAN line.

Let's say the car goes into the garage and the tester tool is connected. And the tool wants to

read fault codes or scan the fault codes, the problems in all the ECUs. Then one way would be

to send a request to each and every ECU and get the response.

So that would really kind of repeating the same command to multiple ECUs, multiple times. So

that will be wastage of time and also resource in terms of time. So what is the other way? The

other way would be that the tester tool sends a single command or a single message on the

CAN line.

And all the nodes which are there on the CAN line understand that this command is for all of

them. This message is for all of them. The request is for all of them.

And they respond to the tester tool with their respective IDs. So if the tester tool wants to

communicate or send a command to all the ECUs, then 551 is the request ID. So irrespective of

whether the message is or the request is coming on 779 or 551, your Rainlight Center or

eLocker ECU will respond with 778 only.

So the response is always from the ECU to the tester tool. That is why the message ID remains

the same. The response ID remains the same.

But since the request can be coming one-to-one or it can be coming from one to many, that

means tester tool to many ECUs, that is why it can be having different message IDs, which is

779 and 551. So when I say message ID, you will notice or understand that this message ID is

nothing but the arbitration ID. Like in the CAN classes, you would have read about the message

ID, arbitration ID, message number.

So these are the message IDs, message arbitration numbers. Typically, the diagnostics

message IDs are lower in priority. And application message IDs, like application when I say, like

we discussed in the earlier class also, these messages which are floating around from APS to

PCM, between APS, PCM and Rainlight Center, during the normal working of the ECU, those are

application messages.

So application messages typically have a higher priority than the diagnostic messages because

the application messages are needed for regular working of the ECUs and they have a higher

priority. Diagnostic messages typically have low priority because the diagnostic messages are

rarely used during the lifetime of the vehicle. What does it mean? It means to say that when the

vehicle, something goes wrong in the car, the car is taken to garage, then only the diagnostic

messages will come into picture.

And since during the lifetime of the vehicle, the number of times the car visits the garage and

the tester tool is actually connected to the OBD connector and ultimately the CAN line is not

even 0.1% of the lifetime. So that is why the diagnostic messages are given lower priority. So

that if at all they are used, there could also be instances in which the car has never visited

garage and gone wrong.

So in those sense, if you give diagnostic messages a higher priority, then you might base the

message IDs because it will never be used during the lifetime of the vehicle. So that is why the

diagnostic IDs are typically lower priority as compared to application messages. Now let's get to

the next level of information on diagnostics.

So as I said, UDS is a diagnostics protocol. What do you mean by protocol? Protocol is basically

a set of, it is a mutual understanding between the sender and the receiver about how that

information will flow. Every language that we are using is a protocol.

Every alphabet when combined into letters forms a particular meaning. So that's the protocol.

Similarly, on CAS, how the diagnostic information will flow from tester tool to the ECU and the

ECU to the tester tool is controlled and defined by UDS protocol, Unified Diagnostic Services.

Unified Diagnostic Services is an off-board protocol. The diagnostic protocol can be divided into

two types. One is called as on-board diagnostics.

Other is called as off-board diagnostics. On-board diagnostics typically was implemented

before UDS protocol. OPD is nothing but an on-board diagnostics.

So before UDS, on-board diagnostics was implemented in all the emission related ECUs. Mostly

the Indian ECUs which do the diagnostics and kind of stores that information and displays on

the dashboard. But that is only relevant to exhaust related ECUs.

UDS which is Unified Diagnostic Services is an off-board diagnostic mechanism. Why off-board?

Because it stores the information and through a diagnostic tool also you can read the

information. That is why it is off-board diagnostics.

And it is applicable to each and every ECU. Because if the diagnostic is not implemented, then

there is no other way for anybody to read the information from the ECUs. And if something

goes wrong in any of the electrical peripherals that are attached to the ECUs, there is no way of

finding out what exactly has gone wrong.

So that is why the off-board diagnostic is so important. UDS protocol is mandated by law. So

irrespective of whether the car is manufactured in India, China, America, the UDS has to be

implemented in each and every ECU.

And it is mandated by law. So that is why this is a universal protocol. Now whatever we will talk

about in the UDS, the service IDs which are these, nothing but the commands.

And each command is represented by a number. Like in a company we have employee names,

then employee numbers. In UDS, we have service IDs, service names, and then we have service

IDs.

So each of these services represents a particular command or a particular request. And all

these commands ultimately travel in CAN through those 8 bytes of data frame. So just

remember that everything we are talking about in diagnostics is ultimately flowing from your

diagnostic tool to the ECUs through the 8 bytes of data frames which are going from the tester

to the ECU, to the tester through a particular message ID.

And in our case, that is done through 779 and 778. So let me explain how this particular Excel

sheet is, or this requirement document is structured. Now you will see that there are categories

of commands, and then each category, each SID has a name, and beside that I have written

primary, default, programming, and extended.

And then functional and security. I will explain to you later what this default, programming, and

extended means, but functional I think I have already explained. It basically says that this

particular request can be given to all the ECUs by the tester tool in one shot.

Functional addressing means, can a particular request or a message can be sent to all the ECUs

in one shot. So if Diagnostic Session Control has a X mark here, that means this request can be

sent by the tester tool to all the ECUs in one request. That is possible, that is supported.

And when that will happen, it will obviously happen with the functional ID, which is message ID

number 551. That is the meaning of functional. Probably what is security access we will cover in

the next few classes.

Another thing that you will notice is that each of these SIDs, either they have listed in which

kind of session they are supported to them, default and extended, or they are marked as grey.

So when they are marked as grey, that means even though they are supported by 2DS, those

will not be covered in this course. Why are these not covered in this course? Because they are

rarely used by suppliers.

What do I mean to say? Unified Diagnostic Services or the UDL document, standard ISO 14229,

UDL 14229 or ISO 14229 document, is basically an umbrella protocol in which there are lists

and requirements of all the requests, that means SID, that can be supported. Each of the

supplier and the manufacturer of the ECU or the application selects what of all those is

applicable to a particular ECU that they are manufacturing. So there could be a possibility that

whatever is mentioned in the UDS document might not be applicable to the product as it is.

So not everything given in the UDS document, 14229 is implemented by the supplier and

whatever is implemented is given in a document like this from the OEMs to the suppliers or

from the suppliers to the OEMs, saying that this particular product, we have implemented these

many diagnostic features. The ones which are marked as grey, that means these are the kind of

requests or the SIDs which are rarely implemented by any supplier. That means even though

they are mentioned in the UDS document, we would not be covering those in this particular

course.

And if in the discussion and anybody asks why were these not implemented, just say they were

not applicable or there was no requirement related to these SIDs. And there cannot be any

questions on why they were not implemented, because they were not applicable, that is why

they were not implemented. At least whatever I have seen in my career of so many years, rarely

these were implemented and that is why these are removed from the syllabus of this course so

as to avoid unnecessary confusion about these SIDs.

And once we start going to the point where we start representing this in other resumes, we will

make sure that whatever we are covering in this course is what is mentioned in the resumes

and that should be good enough to understand the UDS diagnostic functionality and totality. So

to start with, we will start the class with diagnostic session control, which is called SID 10. So

now this SID is the basic SID that is there in the UDS.

So before we get into the details of this, I will try to correlate this example to the real-time

scenario. So diagnostic ultimately means giving access to the internal information of the ECU.

But at different stages of diagnostics, different kind of information is required.

And secondly, not all the information is needed for doing diagnostics. So the stage at which you

are doing the diagnostics, you probably need different kind of information and not all the

information is relevant at all the time. What do I mean by this? Let's say take a realistic scenario

or a real-time scenario in which somebody is not feeling well and he or she goes to the hospital.

Same way, the car is not doing good and it is taken to the garage. Now when somebody gets

into the hospital, as soon as we get in, there would be a registration desk and then somebody

sitting on the desk would ask for very preliminary information, like your name, address, initial

symptoms and then what exactly has happened. So with that information, we are trying to

come to a conclusion of what kind of medical assistance is needed and which department they

should forward you.

So that is very basic information. If at that point, if you show some blood report to the

receptionist, they will not be able to make any sense out of it. So probably that is not the right

information for them.

Same way, when the car is taken to the garage and the tester tool is connected to the OBD and

the CAN line. So initial set of information the tester tool tries to read is very basic and this can

be given by all the ECUs without getting into a detailed level of access or giving any confidential

information. So that would be the first level of access to the ECU and that is called as default

diagnostic testing.

Now, one step forward, you give the basic information to the receptionist and then they guide

you to a particular department based on what kind of problem you are facing. So if it is related

to heart, then heart surgeon would be called in or the respective nurse would come in. If it is

related to some other part, then the respective specialist or that department head or nurse

would come in.

And then the kind of information that they need would be entirely different from what the

receptionist needs. They would have more detailed level of information. They might describe

you some blood test, some scans, MRI scan or CT scan and a different level of information is

needed which is much more confidential and very specific to you.

So that kind of access is the second level of access to your internal functionality and internal

body. Same way, once the diagnostic tool is connected, after getting the basic information from

all the ECUs, the tester tool will try to get some specific information from a specific ECU where it

sees the problem could be. It can be one ECU or multiple ECUs.

But the kind of questions that the tester tool will ask, would be CAT messages which would be

much more detailed. There could also be some situations in which the tester tool might try to

do some manipulation so as to resolve the problem. That way, the behavior of the ECU can also

be changed.

As in, when you go to the next level of diagnostics, CT scan, MRI scan, they will also take your

blood samples and other samples to understand the symptoms of the problem. Similarly, in the

extended mode, they might do some functionalities which can affect the behavior of the vehicle

temporarily. So that would be an advanced level of information.

So, in order to access that kind of information from the ECU, we need to get into extended

mode. Now, what is programming? The third one. So, based on the CT scan, MRI scan, the

sample reports and everything, there would be a specialist called MD doctor or somebody who

leads that particular domain.

In a real-time scenario, it could be either a prescription of a medicine or there could be a realtime

operation. So, that is very similar to programming. There, the individuals are kind of reinitialized.

They are kind of operated to close the problem that you are having and diagnose the problem.

Similarly, in a garage environment, by doing the information, by doing the diagnostics, and by

reading the information in default and extended sessions, they find out that the problem that is

there in the ECU is not a hardware problem. It is a problem that needs re-flashing of the

software or re-initialization of the software or replacing the old software with the new software,

applying a new version of the software.

Then, the ECU would get into programming mode. During the programming mode, the ECU

software would be re-flashed, reprogrammed. If you see in our mobiles, every now and then we

get messages that a new version of OS is available and it can be downloaded.

In the same way, in the car, it is not easy to do that kind of flashing and replacements. Because

the risk, if something goes wrong, is on the higher side. Somebody could drive that vehicle and

maybe hit somebody.

But in a mobile kind of environment, maximum, the cell phone will not work and it can be taken

to the service station. It can be re-flashed again. So, that is why in an automobile kind of

environment or cars, the programming session is used for re-flashing the applications inside

the ECU.

But it should be done very carefully so that the right application resides inside the ECU. If there

is a bug, then it can be re-flashed. So, that kind of access is given in the programming mode.

Diagnostics can be done in three different modes, which is default, extended and

programming. Default is for getting the basic level of information. Programming is for getting

real-time access to the memory of the ECU, where you might want to program the old

application with the new application.

And an extended level of diagnostics would be to get the access to the ECU confidential

information, identifiable information. And then it could be a state in which ECU behavior can be

changed for a temporary duration of time. So, that is how the three levels of access work.

Now, in order to understand how the whole request and response sequence work, we have to

go to the next sheet. So, here it says SID details. Now, if you go to SID details, if you look for

diagnostic switch and control, it says 10.0.1, 10.0.2 and 10.0.3. Somehow, I am not able to get it.

Now, if you see, how will the structure look like? How will the request and response look like?

So, as I told you, the request will always go from 7.7.9 or 5.5.1. So, let's say in this case, the

request is going physical to the rainlights and satellites. So, 7.7.9 is the message. Then what is

the SID? SID would be 10.0.1 is for the default session.

That would be half of the command. And before 0.1, you have to write number of bytes that are

valid after this byte. So, after this byte, you have to write how many bytes are valid.

2 bytes are valid. So, 0.2. Just to keep this into perspective, what we are trying to say is that the

command would be looking like message ID. Then you will have PCI information.

Then SID and then support. So, in our case, 7.7.9 is the message ID. PCI is for Program Control

Information.

SID is 10.0.1. So, 0.1 is for default session. So, if you are trying to get into default session, when

you switch on the car, you will be automatically in a default session. All the issues will be

automatically in default session.

So, this command could be used when you are trying to move from extended session to default

session or programming session to default session. That is when you will have this request.

Otherwise, when you start the car, you will already be in default session.

So, mostly you will use command to get into extended session or programming session. So, a

request in UPS would basically look like this. There would be a message ID 7.7.9. PCI

information 0.2. 0.2 means there are 2 bytes valid after this byte.

So that somebody who processes this command knows how many bytes they have to process.

Then there is SID number which is SID 10. And sub function to get into default is 0. So, what

would be the response? The response would be 7.7.8. That means from issue to the message to

be tested to the message ID would be 7.7.8. The 10 will become 50.

Why? Because in UDS, the positive response is basically represented by adding 40 to the

request ID, message ID. And 01 would come back as 01. For which sub function? 01 for sub

function, this is a positive response.

And what will come here? It will be again 0.2. Why 0.2? Because after 0.2, there are 2 bytes valid.

So, this is how a request and response sequence will work for a particular command or request

in UDS. Similarly, if you try, why 40 is added? There is a logic to it.

Basically, they want to enable the 6th bit of the SID number. And that is why they are having 40

added. I will send you one more video after this class where you can get that information.

Similarly, if you want to have positive request and response for other sub functions, 0.2 and 0.3,

it will look like this. So, just understand that all these 3 bytes that you are seeing are basically on

the 8 bytes of the dataframe. So, this 779 becomes a dataframe in which there are 8 bytes at

maximum.

And DLC is usually kept as 8. And in those 8, these 3 bytes are transmitted. Similarly, 778

becomes a dataframe in which there are 8 bytes. And out of those 8 bytes, these 3 bytes are

used.

So, this would be what is seen inside. This will be what will be seen on the CAN trace window.

You will see the messages going and coming on a trace window like this.

Internally, what will happen inside the Rainlight Sensor is that there would be a state machine

maintained. And the state machine would transition from default to extended and extended to

programming based on these commands that are received. And that transition would be

internal to the issue.

That means the functionality can be supported in extended. As you get the command to move it

to extended, those would be enabled inside the program, inside the issue. So, it might not be

visible from the outside.

Outside, you will just see the request and responses. But internally, that transition is

happening. Another thing to understand is, let's suppose I am in default.

Every issue is in default. Default diagnostic session, when it boots up, and it gets into extended

session. So, let's say you move from diagnostics default session to extended session.

How long will this issue be in the diagnostic session? How long will it continue to remain in

extended session? Suppose you are moving from default session to extended or you are

moving from default to programming. How long will be the issue in the programming mode or

extended mode? Will it be for lifelong? No. Why? Because if it is for lifelong, then probably there

are high chances that somebody might try to access the confidential data of the car.

Visualize a condition where you are doing a net banking. What happens in net banking? Once

you log in, then if you don't click on any of these links inside the net banking website, it gets

you out within a time. Let's say after the last click, it waits for 5 minutes.

And if there are no activities in 5 minutes, then it locks you out of the website. Why it is done? It

is done to save the confidentiality information. So that nobody else can just come into that

window and access your data.

Similarly, the characteristics of the vehicle changes or parameter changes or the properties of

the diagnostic session changes are made as soon as the request is received and the response is

given back for a particular time. If there is no activity after some time, then from extended to

default and from programming to default, it automatically bounces back. It's like when you get

into the office, it bounces back.

By default, the door closes after some time. If somebody keeps on coming in, then he will again

keep on touching the car. And if the time at which the door is closing down, it will keep on

resetting.

But from the last person who has entered, after that, it will wait for a particular time. And after

that, it will reset and close. Same as in banking website, on the last click, it will wait for 5

minutes and then it will log you out.

Similarly, when you change the properties of the diagnostic sessions, when you go from default

to extended or programming, the issue will remain in extended and programming for a

particular time.

Daig2.1

Today, I am going to talk about the issue of extended and programming access, and if there is

no activity in that duration, then the ECU will remove the extended and programming access,

push the ECU into default again. When I say activity, there could be two types of activity. One

activity would be within that time, another message is sent, that means another request is sent

from any of the SIDs, or there is a specific command, which is called as test represent, which

resets the timer.

If you see here, the SID information, test represent. The test represent functionality is just to

reset the time, which will probably, after which probably all the properties are reset. So that I

will explain to you later, just to give you an idea.

So, anytime there is no activity, then it will log you out, or it will bounce you back to default

session, and that timer is basically called as S3 timer. In UDS, it is called as session timer. S3 is

called as session timer.

How long the session would remain in that access? It is only going from default to non-default,

in which non-default in our case is extended and programming. If it goes to extended and

programming, if there is no activity after getting a positive response, then it will wait for 5000

milliseconds, and it will again go to default. So that it avoids anybody else accessing the

information.

So this is the case when there is a positive response. There could also be a situation in which,

let's say the vehicle, the ECU is not able to get into extended, or the vehicle is not able to get

into programming mode, then the ECU will give a negative response. Let's see what is the

negative, how does the negative response look like.

So again, the command to get into extended would be 020303, and then if there is a negative

response, then in that case, the bytes will change. So 10 would be replaced by 7f, 7f is called as

negative response SID, and for which SID there is a negative response, it will be 10. Then what

will come here, it will be 502, because after this byte, there are two bytes which will be valid.

After this byte, there is also something called as negative response code. What is negative

response code? Now let's say if we tested two sensors, 7f and 10, so I will understand that this

particular message, this particular command or SID, it did not get a positive response, that

means it was not able to get into extended, and that is what I can infer from this information.

But what I will do after this, why did it not get into extended is not known to me.

So that Y is basically represented by a negative response code. What are the different negative

response codes supported? Let's go to this analysis sheet. And for now, initial discussion, we

take these three analysis sheets.

11, 12, and 13. 11 is, I will just write it here. 11 is service unsupported, 12 is function

unsupported.

13 is message, message. I'm just taking some basic examples to introduce this concept to you.

Later we'll understand what is the meaning of each of these negative responses and how are

they applicable.

So, just going back to the example. And this particular case, it says that this is a negative

response, and it is a negative response for SID 10. But why it is a negative response? Why did

we get this? In those cases, it will give one of these responses, 11, 12, and 13.

When you will get 11, you will get 11. When instead of somebody, let's say, instead of 10, I have

written 15. So, it will take 15, it will scan through this list of SID.

In this list, there is no 15. So, that is when it will give me 7F, 15, and it will say service not

supported. So, as soon as the tester 2 sees that service not supported, then it will understand

probably there is something wrong with the SID that I have requested.

And then when the tester 2 or tester 2 basically will not make this mistake because it is

programmed and tested and all. But during the manual testing that we are doing in the lab, we

might write this information. We might accidentally put this number from 10 to 15.

Accidentally write a wrong SID. Then in that case, it will give us a negative response, 11. That

means service not supported.

This particular number, SID, is not supported, is not in the list of supported SIDs. So, that is

what the negative response code will help you with. So, in this case, this will become a 0. But

there are 3 bytes which are valid after this.

Let's see another example. Now, let's see how will you get 12. It says the sub-function is not

supported.

In our case, we have 3 sub-functions. 1, 2, and 3. 1 for default. 2 for programming.

3 for extension. Let's say during the testing, somebody puts a right SID number. But instead of

3, they write 6 here.

Or something other than 1, 2, 3. So, when you get the negative response, instead of 11, you will

get 12. With 12, you understand sub-function is not supported. That means we only supported

0, 1, 2, and 3. But this is something other than 0, 1, 2, and 3. So, the person who is testing the

requirements will understand that I have given a wrong command.

And then he will write 0, 3, 0, 1, or 0, 3, and test it again. So, as a validation engineer, our

responsibility is not only to get the positive response. Yes, the issue should behave the way it is

expected to.

But the issue should also be able to understand the wrong commands. And then give the

direction to the tester tool that what is wrong. For a right question, you should write the right

answer.

But for a wrong question, you should be able to identify that this is a wrong question. This is a

wrong request. And then how would the issue tell whether this is a wrong request? By negative

response codes.

Instead of 6, then you would write 3 and get a positive response. Another example is incorrect

messages. Let's say 3 is also right and 10 is also right.

But instead of 2, they write 5 and 4 here. So, in that case, we will get 30. Because the issue

knows that if there is a 10, then there is only one byte that is valid after it.

Because 10 has only one sub-function. It has three sub-functions can be placed here. So, there

are only maximum two bytes.

So, in that case, it will give 7 and then it will give the SID number and then it will give the

negative response code. So, that is how the negative responses are received. If all these three

negative responses occur, let's say the length is wrong.

SID is also wrong. And sub-function is also wrong. Possibly, anybody can make this mistake.

Then in those cases, the SID number with the lowest value takes the precedence. So, the

response would be 7F, 15 and then 11. So, even the negative responses are prioritized.

That means, they would be received based on the number. The lower number has a higher

priority. The negative responses, the lower number has a higher priority.

What do I mean by that? In this list, the numbers which are coming in the top, they have a

higher priority than the numbers which are coming in the last. So, let's suppose during a

command, 13 and 22 both occur. First, 13 would be given and then 22.

So, in this case, we have taken an example. So, in this case, first they will give 11. That means

somebody would go back and correct this.

And then the EC will say your sub-function is not supported. Then the EC will say service is not

supported. So, when they say service is not supported, somebody will go and make this 10, 15

to 10.

So, if the service gets corrected, then it will say sub-function is not supported. And then

somebody would go here and change it to 3. And then at last, it will say message incorrect. So,

if there is 10 and 3 is correct, then the EC knows that here it should be only 2. So, this is how the

positive and negative response code varies.

So, as a validation engineer, the whole purpose of this validation engineer or responsibility of

this validation engineer is to make sure all the SIDs that are listed here, they give positive

responses according to the requirement that is mentioned. So, they should be supported in

default programming language. They should get the response for functional.

And then if the request is not correct, then they should get all the negative responses that are

supported. So, just to introduce you to this particular document 14229, how do we read this

document based on the Excel sheet? Because this Excel sheet is basically a subset of the 14229

document. Now, if you see this particular document, this is the whole document.

The real SID starts from here, page number 36. Probably, you can directly come to page

number 36. Now, if you want to come to page number 36, let's go to it.

This is the start diagnostic for service ID. The way this document is structured is that every SID

is listed in this document below this SID 10. And then for every SID, there is a service

description like this.

And then after service description, there are definitions of sub-functions. Like I have mentioned

default, programming, extended. And there are other sub-functions also mentioned.

But as I said, we can restrict our discussion to what is mentioned in this Excel sheet. Here, if you

go, I have only mentioned default, programming, and extended. And that is what you have to

read from this document.

Default, programming, and extended. So, take the base SID from the Excel sheet. Go through

the service description.

Go through the parameter details, definitions, and the information from this document. And

then after you have gone through the sub-function list, it will show you how the positive

response will come. And then it will show you the negative response codes.

And then it will show you the examples of some positive responses. And the next SID. So, the

way you have to link these two documents is probably go to the SID.

And then go to SID details. See the sub-functions that are implemented. And go to the Excel

sheet.

Read only about those sub-functions. There could be many more sub-functions which are

implemented here. But according to the Excel sheet, in our case it is default, programming, and

extended that we are discussing.

So, go and read about default, programming, and extended. And very, very important is to read

about this NRCS. What NRCS can be supported by each of these SIDs is what you need to keep

on understanding.

So, if you want to make notes, probably the right way would be take a full-fledged double-page

notebook. And once I write the SID number, then write each of these sub-functions supported.

How would you get those positive responses? And then what are the negative responses for

each of these SIDs? And how are these negative responses received? In what scenario they will

be received? How will you get sub-functions not supported? How would you get messages

incorrectly? How would you get conditions not fulfilled? Because each and every negative

response would be important.

And you should understand why you are getting those negative responses. Then go to the next

double-page and use it for the next SID. Leave some of the pages blank so that once you keep

on coming back to the SID, you find new information to keep on adding to those pages.

So, that is how you have to structure your studies. So, I think for today, we will stop here. And in

the next class, we will come back and read about these SIDs.

See you next time.

DTC1

Welcome back everyone. So today we will start discussing about the Diagnostic Trouble Code

DTCs. So DTCs are basically the crux of the whole diagnostic system.

Each and every fault that is present in the car is represented by a diagnostic trouble code. So as

you know and I think I explained in the starting that once you get your car into the garage or

any of the warning lamp indicator on the dashboard, then the tester tool will connect to the

can-line of the vehicle and then scan the DTCs. And through these DTCs, they will understand

DTCs, diagnostic trouble codes, fault codes.

They will understand what exactly has gone wrong, which physical component is not working,

what is the electrical failure, what is the can-related failure. And for each of the DTCs, there is a

set of instruction given to the service tool engineer to really diagnose the problem. And by

following those instructions, the problem would be diagnosed, the part would be repaired or

replaced, and then the vehicle will be restarted to check and make sure that the problem

doesn't exist further.

So whole of that concept, how we are replicating in a lab environment is what we are going to

see in this class. Probably this will be the first of the two series lectures in which we'll try to

understand what are DTCs, what are the logging mechanism, how the DTC status is stored in

the issue, and then what are the different types of DTCs we have, and what are the different

SIDs that we are using for reading the information about the DTCs, clearing them, and probably

enabling or disabling the DTC logging algorithm. So basically, clear DTC information as ID 14,

read DTC information as ID 19, and then control DTC settings as ID 85.

This is what we will study as a whole. I think it would make more sense to have this listed in this

section, but for now, let's keep it here only. So controlling DTC setting is basically to enable and

disable the DTC logging algorithm, and then clearing DTC information is to remove the fault

codes from the memory, and read DTC information as ID 19 is to read the problems or the fault

code that exists in the system.

So you will understand this slowly as we go into the details further down. So going to the DTC

tab here, we have listed a list of all the DTCs that can exist in the system. So it would make

sense to probably have this particular diagram copied here that we understand what DTCs are

we talking about.

Now DTCs are nothing but an indication of problem that could occur in the system. So the

problem could be electrical problem or it could be can related problems. So just to give you

some idea about DTC numbers, so DTC numbers can be represented in a hex format, which is

typically a 3 byte of data, hex data, or it can be represented in a J2012 format, which is again 4

bytes of data, 4 bytes of number, but typically a hex value is used in any of the any of the any of

the tools.

So 6, 3, 3 bytes of hexadecimal number is represented in the DTC. So if you specifically see

these numbers, if you see this 61, 81, 20, 61, 81, 21, now 6A, 20, 6A, 21, 6AB, 20, 6AB, 21, there

you will notice that each of these the combination of these have same number, then these two

have same numbers, and these two have probably have same numbers. So out of these three

bytes, first two bytes represent the part in which the problem has occurred.

So battery related DTCs are 61, 81, and this 20 and 21 represent the fault type. So above

threshold and below threshold is the fault type. And now if you see motor short to battery,

motor short to ground, so motor related faults are 61A, 20 is short to battery, and 21 is short to

ground.

Rain light sensor issue, 61A, 20, 61A, AB, 21. So 61AB is representing the rain then rain sensor

short to battery and short to ground. So this is the topology of conventional naming

mechanisms of the DTCs.

So what exactly is the DTC? DTC represent what problem are faced by a particular issue. So in a

lab environment, how would you create this DTC? So when you are seeing this battery voltage,

this battery, as I mentioned earlier, in our lab, there would be a 220 volts AC voltage, right? And

our whole system is running on AC voltage. So there will be a power supply, program power

supply, which you will have a knob.

With the help of the knob, then control that output of the power supply between 8 to 20 volts.

But usually in a normal world, the AC works on a voltage of 12 volts. And even the battery that

is connected on the vehicle requires a whole battery.

So if you make the battery by rotating the knob to less than 8 volts, then it will set a DTC, which

is called as battery voltage below threshold. And when you make it beyond 60, it is battery

voltage above threshold. So there was a question asked in one of the discussions.

Let's say you are rotating the battery and making voltage less than 8 volts. How do you really

know whether that particular voltage is actually going below it or not? So in that case, you can

plug a multimeter into the positive and negative of the wires which are going to the ECU and

check the battery voltage, whether it's actually going beyond less than 8 or more than 16, what

is indicated in the power supply. So that is how you can cross check.

So that is one kind of electrical failure that can occur in the rain light sensor ECU or in your light

setup. So what are the other electrical connections? The other electrical connections are wiper

motor and rain light sensor. So again, wiper motor has two wires, motor high and motor low.

If you short this one of these wires to battery high, then it is short to battery. Or if you short it

to negative or low, then it is short to ground. If you short it to ground, then it is short to

ground.

And if you short it to battery high, then you short it to battery. So you can just take the wire and

short it to battery high. So that is shorted to battery.

And then that is motor short to battery short to ground. So here, by doing a physical shorting,

you are simulating these faults inside the lab environment. In a real-time working of the car,

this might happen accidentally due to breakage of the wire or maybe improper working or

shortage of the wire or shortage of the PCB.

Whatever the physical failure occurs in the real-time, this could be something that can happen.

Same way, if you want to create a fault on the sensor, then you can take one of the wires of the

sensor and short it to battery. And then it will be rain light sensor shorted to battery DTC.

And then if you short it to ground, then it will be rain light sensor shorted to ground. So that is

how the DTCs are created on the bench. So battery above and below threshold, motor short to

battery short to ground, rain light sensor short to battery short to ground.

This is how these DTCs are created on the bench. There is another issue, internal performance

DTC, which is mostly related to RAM and ROM failure. So internally inside the issue, there is an

algorithm implemented to check the validity or integrity of the ROM and RAM.

So those kind of failures typically lead to the replacement of these. So that is why it is difficult.

You rarely see these kind of DTCs.

But once they occur, since these are more of an internal microcontroller problem, they don't

demature or go by themselves. They cannot be repaired. Mostly they are replaced.

The issue is replaced. So that is how the physical, electrical DTCs are tested. So in discussion, in

the interview, they can ask you what are the electrical DTCs that you are testing in your system

or are applicable to your system format.

So you have to say battery short to battery below threshold. Battery above threshold can be

related to the power supply and then motor short to battery, motor short to ground, by

shorting your respective battery higher, battery ground, and then green light sensor shorted to

battery and shorted to ground. That is how you are creating those DTCs on the bench setup.

After that, you will see CAN related DTCs. So CAN related DTC, one of the DTCs is CAN bus of

DTC, either by shorting CAN high to CAN low, or by shorting CAN high to battery low, or by

shorting CAN low to battery high. So basically, by disturbing the voltage level of CAN high and

CAN low bus, you can create CAN bus of DTC.

So as we discussed earlier, when we say bus of, it basically means all the transmitting nodes,

their DEC counters are going beyond 256 in number because of regular failure in the

transmission. So once the bus of occurs, then there is no transmission on the CAN line. So that

is how it's physically created.

Okay. Now, another type of error that can occur in the CAN line is related to loss of

communication DTCs. That would occur when the bus of is not there.

If the bus of is there, that means there is a physical failure on the bus. That means there is no

question about loss of communication. So if the bus of is there, obviously there is no being

received or transmitted.

So that is why loss of communication could not be obtained. But once the bus is working fine,

but then also the messages are not coming from ABS or PCM to rain light sensor issue, then it

is loss of communication with ABS or loss of communication with PCM. So this is how the DTCs

are formulated.

So when I say loss of communication, it means that rain light sensor is saying that it is not

receiving any message from ABS module. Okay. So how are we simulating this particular failure

is that we go to the CANOE tool and the interactive generator where we are trying to simulate

the messages for ABS and PCM, we stop those messages being sent on the CAN line.

And when we stop them being sent on the CAN line, then the rain light sensor issue sets loss of

communication with ABS and PCM. So here you need to remember that the periodicity of the

messages from ABS and PCM is let's say 20 millisecond. Then it will not set the DTC or fault

code by the first message when it is lost.

It will wait for at least three messages to be gone, and then only it will set loss of

communication DTC. Why? Because due to latency and probably due to arbitration, there could

be a possibility that 20 millisecond message might not go exactly on 20 millisecond. Right.

So in order to give that kind of variance, it is decided that loss of communication messages

would not be set right away. They would be set when at least 2.5 times of the periodicity. So at

least three messages should be gone.

Then only loss of communication would be confirmed. So same goes the loss of communication

with ABS and then loss of communication with PCM. These numbers are not important.

You do not have to remember the DTC numbers. Whenever they say, for taking an example,

probably names are important. Those numbers can be assumed anyway.

But when you assume also, just make sure that they follow this pattern that the first two

numbers represents the type of electrical component you're talking about. And the last byte

represents the exact fault code. So first, if you're talking about motor, then first two numbers

should be motor short to battery and short to ground.

The last byte can be taken as 19, 20, 21, depending on whatever example you're taking. So

these DTCs can pass off DTC, loss of communication DTCs. They are hierarchical DTCs.

Hierarchical means if one occurs, the other will not occur. If the pass off is occurring, then

obviously there is loss of communication. That means the message will not be received by the

inline sensor from the other issues.

So that goes without a saying, but it cannot be seen physically on the memory. The loss of

communication of the ABS and DCM will only be seen when there is no canvass of DTC. If the

bus is working fine, then only we can say the messages are lost.

If the bus itself is not working fine, then there is no point in saying that the messages are lost.

That goes without saying that the message would be lost. So either of these would occur at a

time when both cannot be seen.

Matured or confirmed or present at the same time. And then the third type of DTC in CAN is

impossible data. What is the meaning of impossible data? Impossible data means the data that

is coming from the ABS and DCM is invalid.

Why it can be invalid? Let's suppose ABS module is sending wheel speeds for all these all the

four wheels. But the ABS module knows that one of those wheel speed sensors have gone

wrong. And then it is sending an invalid data.

It knows that data is invalid and that is why it is sending invalid data on the CAN line. So if the

data is invalid, it is already known that it is impossible data. The literal meaning of impossible is

valid.

The invalid data is received from the ABS or DCM module, then it will send impossible data. So

impossible data can only be sent when there is loss of communication DTC is not there. That

means messages are being received, but the data is not correct.

So first CAN bus stop means there is an electrical problem in the CAN line. And then second loss

of communication means the wire is working fine, the CAN line is working fine, but the

messages are not coming from respective issues. The third type of DTC which is impossible

data signifies that the messages are coming fine, but the data is not working.

The data is not correct. So those are the categories of CAN related DTCs. So overall, electrical

DTCs, CAN related DTCs, what we are covering in the rain light sensor issue as well as E-Locker.

Probably everything remains the same. Instead of motor short to battery, there you can say coil

short to battery and short to block. And then instead of rain light sensor, you can say proximity

sensors.

Other than that, everything remains the same conceptually. So another thing that you need to

understand, DTCs can be classified into four types. Network related, then power train related,

then chassis related and body related.

B, C and F is how they are denoted as. So C is chassis related and then C is network, network,

power train, chassis and body. So those are the four types of classifications that are used for

classifying the DTCs.

So just to give you a more better understanding of how exactly this DTC algorithm works or

DTC logging mechanism works. Now, this diagram which is showing a conceptual

representation of rain light sensor issue. Let us assume that the blue background is the rain

light sensor issue and this particular block represents the executable code.

So whole of the executable code can be divided into two types, two functionalities. The whole

executable code basically controls two functionalities. One is the normal working on the issue.

Basically, the functionality when the rain is falling, the wiper should be moving. When the light

goes down, the headlamp should be on. So all the functional related code would be one piece

of algorithm and the other piece of algorithm would be diagnostics related.

Both of these functionality and diagnostics, they run in the whole loop cycle. What is loop cycle?

Loop cycle is the minimum time in which whole code can execute once. So during every loop

cycle, both of these pieces work together.

One piece of code works, takes care of the functionality and the other piece of code takes care

of the diagnostics. So when I say diagnostics, basically means that it is checking for the validity

of each and every component that is providing the input to the issue because if the inputs are

not right, then obviously the output will never be right. So the rain light sensor issue, in a loop

cycle, there would be functional algorithm working, there would be diagnostic algorithm

working.

And functional algorithm controls the functionality of the issue. The diagnostic algorithm

controls the diagnostics part. That means each and every peripheral that is connected to the

issue would be checked for their integrity and whether they are working properly or not.

So that it makes sure that it is able to take inputs which are valid. And then if the inputs are

right, then obviously the output can be predictable. So when I say inputs, here in rain light

sensor you will see that there is an input from battery, there is an input from, there is an

electrical connection into the motor, there is an electrical connection in the sensor, and then

there is a communication in the channel.

So these inputs and outputs connections are to be working fine for the rain light sensor issue to

give proper functionality. So during every loop cycle, each of these input and output peripherals

are tested for their integrity, whether they are working fine, they are able to, they are

electrically valid, and if the input can be taken and that data can be used or not. So if you see

here, in diagnostics, we have motor, sensor, can and battery.

So each of these components is corrected, is checked for its validity, every loop cycle, and the

status of each of these components is stored in an array-like structure which holds 8 bits which

signifies the status of that particular peripheral. So for motor there would be 8 bit of status

data, for sensor there would be 8 bit of status data, then for can there would be 8 bit of status

data, and then for battery there would be 8 bit of status data. So that is stored in array where

each array, each bit is updated in every loop cycle for all the diagnostics, for all the diagnostic

peripherals.

Now let's suppose the motor is shorted, motor becomes shorted, so this 8 bit data is stored,

called as the DTC status, symbolically becomes faulted, one bit which represents fault is made

on, and then the at which the DTC is detected, the environmental parameter at that point of

time is stored in a block which is called as a snapshot data. So what is snapshot data? Snapshot

data is the environmental parameter at which the first instance of the DTC has occurred. What

do I mean by that? Now in a real-time scenario, if you relate this situation to a disease, usually

when we say that person has, the person met with a heart attack, so as soon as the heart attack

occurred, at that time what was the state of the body, what was the BP, what was the sugar

level, and different parameters of the body, they were recorded, and why they were recorded is

because by those parameters the doctor would try to understand why exactly this problem

occurred.

Same way in an ECU environment, in an electronic environment, when the first DTC occurred,

when the first problem occurred, and it was noticed, and it was faulted, then at that time what

were the vehicle parameters, what was the speed of the vehicle, what was the ambient

temperature, what was the engine temperature, what was the odometer, then what was the

wheel speed, what was the vehicle speed, so these parameters are stored snapshot data. So

with help of that data, it would be easier for the engineers to understand why this problem

occurred. Did this problem occur because of driving at a high speed? Did this problem occur

because of ambient temperature? The vehicle was driven in a temperature for which it was not

made, it was too cold or too hot.

Did this problem occur because the vehicle has driven more than the warranted kilometers? So

all that kind of diagnostics can be done depending on the log that is stored during the first

occurrence of the DTC. So that data is called a snapshot data. As soon as the first fault has

occurred in the input or output peripherals, and first time the problem occurred, at that

instance what were the parameters of the vehicle, what was the odometer, what was the

battery voltage, what was the ambient temperature, what was the wheel speed, what was the

vehicle speed, and other important parameters that were there are stored in the snapshot data.

Now let's suppose this DTC occurred once, and then it did not occur again. Then what will

happen? After 40 ignition cycles, the snapshot data would be removed from the memory. Why?

Because the system is assuming that if this problem did not occur again in next 40 ignition

cycles, then probably the problem has gone permanently and it might not be a permanent

problem.

It was a temporary problem and that is why there is no point in keeping this data in the

memory and the data is also removed from the memory. So that concept is called as aging or

healing. Self-healing or aging means if the DTC has not occurred for 40 ignition cycles, then that

DTC probably has cured by itself, the problem has already cured by itself, and then there is no

point in storing that information in the memory and that information is also removed from the

memory.

So that is aging or healing concept. But suppose the DTC occurred once and then the DTC

dematured and again the same DTC occurred after 2 ignition cycles. So when the first time the

DTC has occurred, the information was stored in snapshot DTC.

The next time the DTC occurred, all the environmental parameters were again stored in

extended data. And let us say after 2 ignition cycles the DTC occurred and then again after 3

ignition cycles the DTC occurred again. So the extended data will keep on being overwritten by

the latest instance of the DTC and the snapshot data will always have the first instance of the

DTC.

The environmental parameters at the first instance of the DTC are written in the snapshot data.

Environmental parameters after the last instance of the DTC are written in the extended data.

And since extended data and the snapshot data, the snapshot data and the extended data, they

are linked to DTC.

They cannot exist independently because storage of snapshot data and extended data is

triggered by a fault. That is why both of these data are linked to a DTC. Both of these would be

removed from the memory after 40 ignition cycles from the last instance of the DTC.

Let's suppose the DTC occurred in the first ignition cycle and then it occurred in the fifth

ignition cycle. In the first ignition cycle, snapshot data would be stored. In the fifth ignition

cycle, the extended data would be stored.

And let's say again after 5 ignition cycles, again the extended DTC occurred. That means on the

10th ignition cycle, the extended data would be again overwritten with the new information.

And then on the 10th ignition cycle, if the DTC did not get confirmed again for 40 ignition

cycles, then the 50th ignition cycle, then the data both snapshot and extended would be

removed from the memory.

So that concept is called as aging or healing. So why this is, why the data is removed? Because if

some problem is not occurring for so long, that means it has self-healed, right? There are a lot

of DTCs for which they might occur because of let's say shorting of the wire or maybe because

of the fatigue or maybe because of some moisture in the vehicle. So that kind of environment

can also lead to setting of the DTCs.

So that is how the DTCs are dematured and the data is removed from the memory. But

suppose the DTC keeps on maturing every ignition cycle, then the snapshot data and extended

data will keep on overwritten. The snapshot data captured once will never be overwritten.

The next instance of the DTC occurring will overwrite the extended data. So by using SID19, you

should be able to read the snapshot data and extended data for a particular DTC. So I hope

with this, you are clear with the DTC bits, status bits, and then what is snapshot data, what is

extended data, what is the concept of aging and self-healing.

And then we will move, we will see the details of how these eight bits are important in

capturing the state of the DTC, which are updated every loop cycle in the memory. So to view

that, we have to go back and understand this. So the eight bits that I was talking about are

these bits.

So you know, it says test field. First bit says test field in this monitoring cycle. Second bit says

pending and third bit says confirmed.

This is the most important bit that is used in DTC, used in reading the DTCs. Confirmed means

that problem has occurred. When you talk about DTCs, there are multiple concepts that are or

multiple terminologies that is being used.

So DTCs can be confirmed, DTCs can be matured, and DTCs can be locked. Okay. All of this is

the same.

Confirmed means that problem is existing in the system. Matured means the DTC has come

alive, that problem has started occurring, and you can see that problem. DTC is locked also

means that problem is existing in the current system.

So DTC confirmed, locked, matured, all of that is the same thing. So these are the eight bytes

which we referred in this diagram as eight bit of status bit. So this is the DTC status that is

stored in every, that is stored for every DTC.

So first four are important, probably test fail, test fail in this monitoring cycle, pending and

confirmed. And for now, forget about these three. And the last one is very important, warning

lamp indicator.

This means that when this DTC occurs, you want to show that on the dashboard to the driver

because not every DTC is so exhaustive or intensive that it needs a repair. Similarly, like in real

time, not every time we are having a fever and cough and we go to the doctor, right? When the

problem or the disease is severe, then only we go to the doctor. Same way, not every DTC will

lead to a lamp on the dashboard.

So whether for a particular DTC you want to show it and show a lamp on the dashboard is

decided by this particular bit for that particular DTC. Let's understand this in detail so that we

understand how they are used in storing the status and representing the status of the DTC.

Now let's take this particular diagram.

So this is the ignition cycle and this is the end of the ignition cycle. When I say ignition cycle, you

have a key and you plug it into the steering column and you crank the engine and start it. So

let's say this is the DTC initially.

So let's say this is loss of communication DTC. The concept applies for loss of communication

DTCs or invalid DTCs or electrical DTCs. So let's say that you were receiving ABS messages and

then there was no DTC locked at that time.

So 0th bit which says test failed in this ignition cycle, this particular bit and the first bit test

failed in this monitoring cycle. Both of them are zero here. At this point 0th bit and first bit both

were one.

They both were zero because test has not failed. That means the messages are coming and that

is why the test has not failed. And then test failed in this monitoring cycle is also zero.

Both of them are zero. As soon as we miss a message, the test has failed and since the test has

failed in this monitoring cycle, that will also become one. So both will go from zero to one at the

first instance of loss of message.

Now since the DTC will not be confirmed till three messages are missed, that is why till that

time you will keep on making 0th bit and first bit as one. After three messages are missed, then

your pending and confirmed would also become one. When you say confirmed, that means this

particular fault is now a failure.

It is now a DTC. That is why you are making confirmed as one. Usually the confirmed bit and

pending bit are going hand in hand for most of the DTCs.

Some of the DTCs in which you don't want to log or say that it is confirmed like the electrical

DTC, the one which I mentioned here. These kind of DTC you don't want to say that DTC has

occurred when you see the DTC first time because it might be an accidental DTC or it might be

triggered due to false reason. So in those cases when the first time the DTC is seen, the

pending would be set to one and confirmed would still remain to zero.

And this confirmed would be set to one the next ignition cycle if the DTC occurs again. So

electrical DTCs in which the cost of debugging that particular DTC is on the higher side and

probably the impact is also on the higher side. The confirmation of the DTC does not happen in

the same ignition cycle.

So that time the pending bit is used. The first pending bit is made to one and confirmed bit is to

zero. The next ignition cycle when the DTC occurs again, then the confirmed bit is set to one so

that we are sure that that DTC is there and the issue can be replaced.

But other than that, for normal scenarios, both pending and confirmed DTCs go hand in hand.

So once three messages are lost at this point, your zeroth bit, first bit, second bit and third bit

all become one. Now let's say after some time you start receiving the message one.

Then you receive the first message, you receive the second message, you receive the third

message. That means your failure that was occurring, your failure that was occurring basically

becomes zero. That means test failed is zero, that test has not failed.

Since test has already failed once in the ignition cycle, once this first bit goes to one, it will

always remain one throughout the life cycle of the ignition cycle. And then your pending bit

becomes zero and confirmed bit becomes zero. That means the current status of the DTC is

that it is not confirmed, it is not locked and the test has not failed.

When I am saying that the DTC is not confirmed, it doesn't mean that this DTC is not there in

the memory. The snapshot data for that DTC is created. The snapshot data is created, but then

it is waiting for 40 ignition cycles to remove this snapshot data from the memory.

So confirmed zero doesn't mean that the memory, the DTC is also removed from the memory.

Even though this is confirmed as zero, it will wait for 40 ignition cycles to remove the snapshot

data and extend the data from the memory. So this is how the status of the DTC is captured and

updated every cycle to make this information relevant to the ECU.

So just to re-summarize, the status of the DTC is maintained in eight bits. The first bit is test

failed, second is test failed in this ignition cycle, this monitoring cycle, third is pending and

fourth is confirmed. All these four can be ignored and fifth is whether for this particular DTC

you want to set a warning lamp indicator on the dashboard or not.

So how these four DTCs are capturing the status of the DTCs? Let's suppose there is an ignition

cycle and then as soon as the ignition cycle occurs, test failed and test, your test failed and test

failed in this monitoring cycle will be zero. Okay. So at this point of time, this point, the test

failed and test failed in this monitoring both are zero.

But as soon as the message is lost, I'm taking an example of a LAN related DTC because of

communication. As soon as the first message is lost, test failed will also become one and test

failed in this monitoring cycle will also become one. This bit, test failed, first bit, once it

becomes one in a monitoring cycle or ignition cycle, it will remain one throughout the ignition

cycle.

From here till here, it will remain one only. Okay. But this bit, zeroth bit, gives the result of the

test during each boot cycle.

Okay. So when the first message is lost, boot becomes one. And after three messages are lost,

then the pending and the confirmed will also become one because that time you are sure that

loss of communication has happened because you have missed three messages from ABS or

BCM module.

Okay. Pending and confirmed usually go hand in hand. But in some of the DTCs in where it is

very crucial DTCs like the one I showed you earlier about the electrical DTC which is related to

memory, RAM and ROM, if that DTC occurs, those kind of instances, your pending and

confirmed might be different.

Okay. The first ignition cycle of the DTC occurred, the pending bit is set and the confirmed still

remains zero. If the next ignition cycle also the DTC occurs, then the confirmed bit will be set.

That means now the issue has to be replaced. Right. So in high priority DTCs where we know

that if this particular problem occurs, then it will call for a replacement of the issue which are

higher in cost, then we try to confirm the DTC only after we are sure that this is really a

problem.

Okay. That is why the pending and confirmed could be different. But in normal scenarios, the

pending and confirmed go hand in hand.

Okay. So after the loss of three messages, both pending and confirmed. Confirmed means

matured, logged and confirmed on the way that this problem or this DTC exists in the system

right away.

So as soon as the DTC becomes confirmed, there would be a snapshot data created for that

DTC. Okay. Now in this snapshot data, all the information would be logged.

And then once we start getting the messages, once we receive three messages, we come to this

point where your test fail bit becomes zero. Test failed in ignition cycle would still remain one

since once it is set to one, then it will remain one throughout the ignition cycle and both your

pending and confirmed bit goes to zero. That means this DTC is not logged in and is not

confirmed as of now.

That means it is not there in the system as of now. So that is the meaning of confirmed going to

zero. Okay.

When confirmed goes to zero, that doesn't mean there is no data in memory as snapshot for

particular DTC, that data still exists. If this DTC remains unconfirmed or the confirmed bit

remains to zero in next 40 ignition cycles, then this snapshot data would be removed from the

memory. This snapshot data would be removed from the memory and the self-healing concept,

okay, aging or self-healing.

And that should happen in 40 ignition cycles. Okay. So this is how the DTCs are updated in the

memory.

What is the difference between snapshot data and extended data? What are the eight bits that

are storing the status of the DTCs? And then what are the different DTCs? How they are typically

numbered and how each of these DTCs can be simulated or created in the lab format is what

we have discussed today. This is very important information. No interview would go without

discussing about the DTCs, about the electrical connections, electrical DTCs can relate to DTCs.

So my request would be to probably go through this video again, recording again to clarify your

doubts. And once we come back for the next time, we will concentrate on how we would read

the confirmed DTCs, how we will clear the DTCs and probably how we can disable and enable

this DTC algorithm so that we can stop locking the DTCs when we don't want to lock the DTCs.

So that kind of enabling and disabling of DTC algorithm is also possible.

So that would be covered in the next class. Okay. Thank you for joining and I'll see you in the

next class.