INTERNATIONAL SCIENTIFIC JOURNAL OF ENGINEERING AND MANAGEMENT (ISJEM) ISSN: 2583-6129

VOLUME: 04 ISSUE: 05 | MAY – 2025 DOI: 10.55041/ISJEM03373

AN INTERNATIONAL SCHOLARLY || MULTIDISCIPLINARY || OPEN ACCESS || INDEXING IN ALL MAJOR DATABASE & METADATA

Design and Implementation of Unified Diagnostic

Service Protocol
Omkar Shivaji Bhagat
Student at Dr. N. A. Doshi
Department of Electronics and Professor at
Telecommunication, Department of Electronics and
SVPM College of Engineering, Telecommunication,
Baramati, Pune SVPM College of Engineering,
[email protected] Baramati, Pune
[email protected]

Abstract- Modern vehicles use the Electronics Control Unit such as Overvoltage and Under-Voltage conditions, ECU
(ECU) to control and monitor all the activities within the vehicle. power loss, and LED circuit failures. The diagnostic response
The number of ECUs are increasing as the complexity of to these failures is analyzed using a Waveshare USB-to-CAN
vehicles increases. All the ECUs present in the vehicles are module. By implementing UDS on embedded automotive
communicated with each other via CAN protocol. Any ECUs, this project aims to demonstrate the practical
malfunction in the ECU or abnormal behaviour of ECU is application of standardized diagnostic services in real-world
detected or understood by diagnostic services. CAN Protocol vehicle systems, improving the efficiency of vehicle fault
does not have advanced features like Diagnostic. The CAN detection and maintenance processes.
protocol covers only the Physical and Data link layer of the OSI
model. There is a need for a standardised diagnostic protocol II. LITERATURE SURVEY
which can use CAN as underlying technology. Standardised
diagnostic protocols used in the automotive domain are On The authors Kataria et al. focus on implementing the UDS
Board Diagnostics (OBD) and Unified Diagnostic services protocol over CAN using the ISO 15765-2 (ISOTP) transport
(UDS). UDS protocol is defined under the ISO 14229 standard layer. The study presents a robust UDS stack supporting
and provides a standardized framework for in-vehicle services like Request Download and Transfer Data,
communication and fault diagnosis. This project focuses on the highlighting ISO-TP's role in handling segmented messages.
design and implementation of the UDS protocol on an embedded It emphasizes UDS importance in advanced diagnostics and
system using STM32F407 microcontrollers. The project ECU reprogramming in modern vehicles. [1]
involves developing a diagnostic communication system between
Electronic Control Units (ECUs) Light Control Module (LCM) The authors M. Kuntoji, V. Medam and Veena Devi S. V,
and Tester tool connected over a CAN bus. focus on the design and implementation of the UDS protocol
in a fully integrated automotive electronic system. The
Keywords- Unified Diagnostic Services (UDS), ISO 14229, research explores the role of UDS in managing diagnostics,
Electronic Control Unit (ECU), Body Control Module (BCM), ECU communication, and fault code retrieval. The authors
Light Control Module (LCM), Controller Area Network (CAN), present a detailed methodology for developing a UDS stack,
Diagnostic Trouble Code (DTC), Routine Control Identifier with emphasis on key diagnostic services such as Read DTC
(RID), Data Identifier (DID), ISO-TP (Transport Protocol) Information (0x19) and Control DTC Setting (0x85). The
study also discusses the challenges faced in resource
I. INTRODUCTION (HEADING 1) constrained embedded environments, providing
In modern automotive systems, the ability to diagnose and recommendations for optimizing UDS performance in
troubleshoot ECUs efficiently is critical for ensuring vehicle modern automotive ECUs. This paper contributes to the
reliability and performance. The UDS protocol, defined by understanding of UDS implementation within realworld
ISO 14229, is widely adopted in the automotive industry to automotive systems.[2]
facilitate standardized communication between diagnostic
tools and vehicle ECUs over the CAN network. UDS enables The author S. Desai and Y. Bhateshvar explores the
functions such as fault detection, software updates, parameter implementation of the UDS protocol on an Arduino platform,
tuning, and remote ECU diagnostics, making it an essential using MATLAB to simulate and test the diagnostic services
part of vehicle maintenance and repair processes. over the CAN bus. The research demonstrates a low-cost
approach to understanding UDS by utilizing accessible tools
This paper presents the design and implementation of a such as Arduino for embedded system design. The authors
UDS-based diagnostic communication system using successfully implemented key UDS services, including
STM32F4 microcontrollers. The project involves vehicle Diagnostic Session Control (0x10) and Clear Diagnostic
ECUs Light Control Module (LCM) that communicate via Information (0x14), highlighting the flexibility of UDS for
CAN bus and respond to UDS diagnostic requests. The educational and prototyping purposes. This work provides a
system supports essential UDS services, including Read Data practical example of UDS implementation in a simplified
by Identifier (0x22), Write Data by Identifier (0x2E), Routine environment, offering insights into how UDS functions in
Control (0x31) and Read DTC Information (0x19). real time systems.[3]
To validate the robustness of the system, fault injection The paper by Chatterjee et al. (2024) investigates
techniques are utilized, simulating real-world ECU failures vulnerabilities in diagnostic protocols like UDS used in

© 2025, ISJEM (All Rights Reserved) | www.isjem.com | Page 1

 INTERNATIONAL SCIENTIFIC JOURNAL OF ENGINEERING AND MANAGEMENT (ISJEM) ISSN: 2583-6129
VOLUME: 04 ISSUE: 05 | MAY – 2025 DOI: 10.55041/ISJEM03373
AN INTERNATIONAL SCHOLARLY || MULTIDISCIPLINARY || OPEN ACCESS || INDEXING IN ALL MAJOR DATABASE & METADATA

commercial vehicle networks. It highlights how insecure and ensures that services like Request Download (0x34) and
implementations can be exploited to gain unauthorized ECU Transfer Data (0x36) can be executed seamlessly. [8]
access or disrupt vehicle functions. Building on past
automotive security research, the authors focus specifically The ISO 13400 standard specifies Diagnostic
on diagnostic service abuse and demonstrate real-world Communication over Internet Protocol (DoIP), which allows
attack scenarios. Their findings emphasize the need for UDS services to be transmitted over Ethernet instead of
stronger authentication and access controls in vehicle traditional automotive communication buses like CAN. DoIP
diagnostics.[4] offers higher bandwidth, making it ideal for modern vehicles
that require faster and more robust diagnostic
The study by Krishnamurthy (2021) provides a communication, particularly for large data transfers and
comprehensive overview of the UDS protocol used in remote diagnostics. Ethernet based diagnostic
automotive systems. It explains the structure, key services, communication provides significant advantages in terms of
and operational flow of UDS in ECU diagnostics and speed and scalability compared to CAN, making it suitable
communication. The paper serves as a technical reference for for more advanced vehicles that support high speed
understanding how UDS enables fault detection, ECU communication, such as electric and autonomous vehicles.[9]
programming, and system monitoring. It also emphasizes the
importance of proper implementation for reliable and secure The ISO 26262 standard for Functional Safety in
diagnostics.[5] automotive systems emphasizes the importance of reliable
diagnostics to ensure that vehicle systems are functioning
The ISO 142291:2013 document defines the UDS safely. While this standard is not directly related to UDS or
protocol, which standardizes communication between communication protocols like CAN or DoIP, it provides
vehicle ECU and external diagnostic tools. UDS is crucial for guidelines on ensuring that diagnostic systems, including
performing diagnostics, ECU reprogramming, and fault code UDS-based systems, meet stringent safety requirements.
management in modern vehicles. This standard defines a Implementing UDS in compliance with ISO 26262 helps
comprehensive set of services for vehicle diagnostics, such as ensure that diagnostic communication is reliable, even in
Diagnostic Session Control (0x10), ECU Reset (0x11), Read safety-critical systems, contributing to the overall functional
Data by Identifier (0x22), and Clear Diagnostic Information safety of the vehicle. [10]
(0x14). UDS operates across various communication
channels, including CAN, Ethernet, and FlexRay, enabling III. SYSTEM OVERVIEW.
diagnostic tools to interact with a wide range of vehicle A. UDS Protocol Overview
systems. The document ensures that diagnostic tools and
ECUs across different manufacturers can communicate using UDS is a high-level diagnostic communication protocol
a unified and standardized approach, promoting defined by the ISO 14229 standard. It is extensively used in
interoperability in the automotive industry.[6] the automotive industry to facilitate standardized
communication between diagnostic tools and vehicle ECU.
The ISO 11898 standard specifies the CAN protocol, UDS operates over the CAN, which serves as the underlying
which is widely used for communication between ECUs in low-layer protocol, providing the physical and data link
automotive systems. CAN enables real time, low latency layers necessary for communication.
communication in embedded systems, making it ideal for
vehicle applications where reliability and data integrity are B. Client Server Architecture
critical. The standard defines both the CAN protocol for data UDS protocol follows Client-Server architecture. In
link and physical layer specifications. CAN is particularly Client-Server architecture the diagnostic tool acts as the
suited for vehicle diagnostics because it allows multiple client, and the ECU acts as the server. The client initiates
ECUs to communicate on the same bus, reducing wiring diagnostic requests. client sends commands to the ECU for
complexity and ensuring prioritized message handling. The actions like reading data, clearing diagnostic trouble codes
combination of UDS over CAN, known as Diagnostic over (DTCs), or performing ECU reprogramming. The client is
CAN (DoCAN), allows diagnostic tools to access ECU data, typically a diagnostic scanner or testing equipment. The
read diagnostic trouble codes (DTCs), and perform other server, which is the ECU, processes the client’s requests and
essential diagnostic functions. [7] responds accordingly. It provides data or executes actions as
specified by the client’s UDS commands, such as responding
The ISO 15765-2 standard, also known as ISO Transport with vehicle status or resetting the ECU.
Protocol (ISOTP), provides a communication framework for
sending diagnostic messages over the CAN bus. Since CAN C. UDS Message Structure
frames have a limited data size (typically 8 bytes), larger UDS protocol is request Based protocol.
diagnostic messages such as UDS requests need to be
segmented and reassembled. ISOTP ensures the correct
transport of UDS messages by defining a method for
segmenting large messages, flow control, and message
reassembly. This protocol is essential for UDS over CAN, as
it enables diagnostic services to send larger payloads Fig.1. UDS Message Frame Format
efficiently, ensuring communication reliability and data ● CAN ID: The CAN ID is a unique identifier used in
integrity even with the CAN protocol’s bandwidth the CAN protocol to distinguish between different
constraints. ISOTP plays a pivotal role in making UDS messages on the network. In UDS, CAN ID used to
functional over CAN, as it handles message fragmentation identify the source and destination of diagnostic

© 2025, ISJEM (All Rights Reserved) | www.isjem.com | Page 2

 INTERNATIONAL SCIENTIFIC JOURNAL OF ENGINEERING AND MANAGEMENT (ISJEM) ISSN: 2583-6129
VOLUME: 04 ISSUE: 05 | MAY – 2025 DOI: 10.55041/ISJEM03373
AN INTERNATIONAL SCHOLARLY || MULTIDISCIPLINARY || OPEN ACCESS || INDEXING IN ALL MAJOR DATABASE & METADATA

requests and responses. CAN IDs can be either includes the original SID, followed by the NRC. Common
standard (11-bit) or extended (29-bit), depending on NRCs include
the network configuration.
● 0x10 (General Reject): The request was rejected for
● Protocol Control Information (PCI): The PCI field a general reason not covered by other NRCs.
can be 1-3 bytes long and contains information ● 0x11 (Service Not Supported): The requested
related to the transmission of messages that do not fit service is not supported by the ECU.
within a single CAN frame. PCI helps with message ● 0x12 (Sub Function Not Supported): The specified
type identification, segmentation and reassembly, sub function is not supported by the ECU.
flow control, and sequence numbering. ● 0x13 (Incorrect Message Length or Invalid Format):
The message length or format is incorrect.
● Service Identifier (SID): The SID is a unique code
that specifies the type of diagnostic service being E. Block Diagram
requested. Each service has a predefined SID, such The block diagram illustrates the architecture of the
as 0x22 for Read Data by Identifier or 0x2E for Write diagnostic communication system implemented using
Data by Identifier. The SID is crucial for the ECU to
the UDS protocol on STM32 microcontrollers. The
understand the nature of the request.
system consists of several key components connected in
● Sub-Function Byte: The subfunction byte is a single sequence to facilitate efficient communication and
byte value that follows the SID in the UDS message control.
structure. It indicates specific actions or modes
within the main service. For example, in the Routine
Control service (0x31), the subfunction byte can
specify different routines to be executed. In case the
response is positive, the tester may want to suppress
the response (as it may be irrelevant). This is done by
setting the 1st bit to 1 in the sub function byte.
Negative responses cannot be suppressed. Fig. 2. UDS implementation Block Diagram

● Data Identifier (DID): The DID identifies specific 1) Hardware Components

data elements within the ECU that are being accessed ● Computer: The computer acts as the diagnostic tool.
or modified. For example, a DID might refer to a Waveshare USB-CAN-A software tool is installed on
particular sensor reading or configuration parameter. the computer. Computer is interfacing with the
The DID ensures that the correct data is targeted by STM32 USB-CAN tool. It sends diagnostic requests
the diagnostic service. and receives responses, enabling the monitoring and
● Data Parameters: Data Parameters are additional control of the ECUs.
data elements required for the service. Parameters ● Waveshare USB-CAN-A Tool: This tool serves as
can include values to be written, conditions to be met, the interface between the computer and the CAN
or specific instructions for the ECU. They provide the network. It converts USB signals from the computer
necessary context for the SID and DID to perform the into CAN signals and vice versa, allowing seamless
requested operation. communication between the diagnostic tool and the
D. UDS Response ECUs. The Waveshare USB-CAN-A supports
various CAN baud rates and provides a reliable
In UDS protocol client trigger request and server will connection for diagnostic operations.
respond to this request as per configuration. The responses
are of two types Positive response and Negative response. ● CAN Transceiver: The CAN transceiver is
responsible for transmitting and receiving CAN
1) Positive response signals between the Waveshare USB-CAN-A tool
A positive response indicates that the requested diagnostic and the ECUs. It ensures reliable data transmission
service has been successfully executed by the ECU. The over the CAN bus.
structure of a positive response typically mirrors the request, ● STM32 Based LCM ECU: The Light Control
including the Service Identifier (SID) with an added offset of Module (LCM) ECU is based on the STM32
0x40 to distinguish it as a response. For example, if the microcontroller. It processes diagnostic requests
request SID is 0x22 (Read Data by Identifier), the positive related to lighting control and responds accordingly.
response SID will be 0x62. Positive responses may also The LCM ECU is connected to input and output
include additional data, such as the requested information or devices to perform its functions.
confirmation of the action performed.
● Potentiometer: The potentiometer is connected
2) Negative response between the LED and an output GPIO pin of the
A negative response indicates that there was an issue with the STM32 Based LCM ECU. It is used to simulate
requested diagnostic service. Negative responses include a conditions such as under-voltage and overvoltage to
Negative Response Code (NRC) that specifies the type of create faulty conditions
error encountered. The structure of a negative response

© 2025, ISJEM (All Rights Reserved) | www.isjem.com | Page 3

 INTERNATIONAL SCIENTIFIC JOURNAL OF ENGINEERING AND MANAGEMENT (ISJEM) ISSN: 2583-6129
VOLUME: 04 ISSUE: 05 | MAY – 2025 DOI: 10.55041/ISJEM03373
AN INTERNATIONAL SCHOLARLY || MULTIDISCIPLINARY || OPEN ACCESS || INDEXING IN ALL MAJOR DATABASE & METADATA

● LED: The LED is connected to the GPIO Pin of ECU

via Potentiometer. It provides visual feedback based In the flow chart for UDS Service 0x22 (Read Data by
on the potentiometer's settings, allowing for real-time Identifier), the process begins with the ECU receiving a
monitoring of light control and fault request message that includes Service ID 0x22 and a DID
(Data Identifier) to read. The ECU then checks if the
● Switch: The switch is connected to the STM32 Based requested DID is supported. If the DID is valid, the ECU
LCM ECU and serves as an input device. It is used to retrieves the corresponding data from memory or storage
turn on and off LEDs. associated with that DID and sends a positive response with
2) Software Components Service ID 0x62 followed by the DID and its value. If the
● STM32CubeIDE: STM32CubeIDE is an integrated DID is unsupported or unavailable, the ECU responds with a
development environment (IDE) provided by negative response (0x7F) and an appropriate error code. The
STMicroelectronics. It is an Eclipse-based flow then returns to an idle or wait state until a new request
development environment, offering a is received.
comprehensive platform for developing, debugging, B. Write Data By Identifier
and testing applications on STM32
microcontrollers. STM32CubeIDE supports code
generation, project management, and debugging
features.
● STM32CubeMX: STM32CubeMX is a graphical
tool that simplifies the configuration and
initialization of STM32 microcontrollers. It allows
developers to configure peripherals, middleware,
and pin assignments through an intuitive interface.
STM32CubeMX generates initialization code that
can be directly used in STM32CubeIDE,
streamlining the development process.
● Waveshare USB-CAN-A: It is a software tool by
Waveshare. This tool is used to send and receive the
CAN message on the computer. This tool can
configure baud rate of CAN protocol. This is the
interface for UDS request and Response.
IV. FLOW CHART
A. Read Data By Identifier (0x22)

Fig.4. Flowchart for Read Data by Identifier

The flow chart for the UDS Service 0x2E (Write Data by
Identifier) begins with the ECU receiving a request
containing the DID (Data Identifier) and data to write. The
ECU first validates the DID to check if it’s supported. If the
DID is valid, it proceeds to write the data to the specified
memory location or register. After writing, the ECU sends a
positive response with a response code (0x6E or 0x62),
indicating success. If the DID is invalid or the data cannot be
written, the ECU sends a negative response (0x7F) with an
error code, such as "Request Out of Range" (0x31) or "Sub-
function Not Supported" (0x12), before ending the process.
This flow ensures data integrity by verifying the DID and
handling errors gracefully.
V. RESULT
The project aims to implement a fully functional UDS
protocol over the CAN bus on an STM32 microcontroller.
The expected results include not only the correct functioning
of the UDS protocol stack but also the successful execution
Fig.3. Flowchart for Read Data by Identifier of UDS services with proper request and response handling.

© 2025, ISJEM (All Rights Reserved) | www.isjem.com | Page 4

 INTERNATIONAL SCIENTIFIC JOURNAL OF ENGINEERING AND MANAGEMENT (ISJEM) ISSN: 2583-6129
VOLUME: 04 ISSUE: 05 | MAY – 2025 DOI: 10.55041/ISJEM03373
AN INTERNATIONAL SCHOLARLY || MULTIDISCIPLINARY || OPEN ACCESS || INDEXING IN ALL MAJOR DATABASE & METADATA

Below are the key services that will be implemented, along were developed to manage and monitor BCM and LCM
with their corresponding request and response formats. functionalities, such as reading status data, configuring
parameters, and controlling routines like turning headlights
1) Read Status of LED on or off. The CAN Bus enabled reliable communication
The current status of LED can be retrieved using service read between ECUs, simulating realistic automotive diagnostic
Data by Identifier (0x22) and DID (0xF100) scenarios. Overall, this project provides a foundational UDS
setup for testing, monitoring, and troubleshooting BCM and
LCM systems within a CAN network, adhering to industry
diagnostic standards.
REFERENCES
Fig. 5. Request and Response for service (0x22) [1] [1] U. Kataria, K. Panchal, J. Puvvada, S. Kadlag and S.
Shinde, “ Implement Standard UDS Diagnostics Over
Can for Automotive Actuator ECU”, 2024 International
2) Write Software Version Number
Journal for Multidisciplinary Research (IJFMR),
The updated SW version number can be written into the Mumbai, India, E-ISSN: 2582-2160, IJFMR240217526.
Software using Write Data by identifier (0x2E) and DID [2] [2] M. Kuntoji, V. Medam and Veena Devi S. V, “
(0xF200) Design of UDS Protocol in an Automotive Electronic
Control Unit”, 2023 Recent Developments in Electronics
and Communication Systems, Bangalore, India,
doi:10.3233/ATDE221266
[3] [3] S. Desai and Y. Bateshwar, “Development of unified
Fig.6. Request and Response for service (0x2E) diagnostic services on CAN using MATLAB and
Arduino”, 2023 Materials Today: Proceedings 72 (2023)
3) Blinking LED for Testing 1935–1942, Pune, India,
To check whether the LED is working correctly or not, a https://doi.org/10.1016/j.matpr.2022.10.157
dedicated blinking led routine can be used with Routine [4] [4] R. Chatterjee, C. Green and J. Daily, “Exploiting
control SID (0x31). Diagnostic Protocol Vulnerabilities on Embedded
To start routine sub–Function SID (0x01) and to stop routine Networks in Commercial Vehicles”, 2024, Symposium
sub function SID (0x02) is used. For Blinking led with 1 sec on Vehicles Security and Privacy (VehicleSec) 2024,
delay routine is used 0x2020. USA, ISBN 979-8-9894372-7-6.
[5] [5] V. N. D. Krishnamurthy, “ Unified Diagnostic
Services (UDS) in Automotive: A technical Study”,
2021, European Journal of Advances in Engineering and
Technology, 2021, 8(6):70-73, USA, ISSN: 2394-658X
Fig.9. Request and Response for service (0x31) [6] [6] ISO-14229: International Standard - Road vehicles -
Unified diagnostic services (UDS), 2006.
4) Read DTC to Detect Fault
[7] [7] ISO 11898-1:2024 - Road vehicles – Controller area
The fault occurred because voltage and under voltage are network (CAN) — Part 1: Data link layer and physical
stored in a system with a unique number called Diagnostic coding sublayer.
Trouble Code (DTC). The fault in the system can be [8] [8] ISO 15765-2:2016 Road vehicles – Diagnostic
understood by reading the stored DTCs using Read DTC
communication over Controller Area Network (DoCAN)
service (0x19) and Sub Functional SID DTC by Status Mask
-- Part 2: Transport protocol and network layer services.
(0x01) and status mask value (0xFF). This request will read
all the DTC regardless of Status. [9] [9] ISO 13400-1:2011-Road vehicles – Diagnostic
communication over Internet Protocol (DoIP): — Part 1:
General information and use case definition. — Part 2:
Transport protocol and network layer services.
[10] [10] ISO 26262-1:2011- Road vehicles – Functional
Fig.8. Request and Response for service (0x19) Safety

VI. CONCLUSION
In conclusion, this Design and Implementation of UDS
Protocol for Automotive Diagnostic project successfully
implemented diagnostic communication on an STM32F407
controller to interface with a Body Control Module (BCM)
and a Lighting Control Module (LCM) over CAN Bus. Key
UDS services, including Read Data by Identifier (0x22),
Write Data by Identifier (0x2E), and Routine Control (0x31),

© 2025, ISJEM (All Rights Reserved) | www.isjem.com | Page 5