UDS is another protocol system that must be used in all ECUs across all Tier-1 OEMs. As the name suggests, UDS is responsible for enabling diagnostics in a unified manner, offering services such as diagnostics, firmware updates, routine testing and much more in the automotive electronic control units (ECUs).
Why did UDS become a mandatory protocol?
The automotive industry might have evolved as a whole, but in the very basic, it consists of many different manufacturers advancing their technology daily. More and more companies are coming into picture, every day, and they all use different architecture for their vehicles and software for their ECUs. Also, even if we talk about a single manufacturer, it is evident that they will not be manufacturing all the ECUs that they are using in their automobiles. Mostly, these ECUs are procured by various other manufacturers. This could have made running diagnostics on each of them simultaneously tricky or, to be very accurate, quite impossible.
UDS - Block Diagram
There was a need to use a unified standard for diagnostics to which all the ECUs responded, despite being from different manufacturers. Then came the ISO- I14229 standard, which standardized the diagnostics across all the manufacturers and other communication protocols such as CAN, KWP 2000, Ethernet, LIN etc. UDS is a commonly defined protocol for both Off-board and Onboard diagnostics. And it finds existence on the Application layer of the OSI model, where:
· ISO 14229-1 specifies, Specifications and Requirements.
· ISO 14229-3 specifies, UDS on CAN.
· ISO 14229-4 specifies, UDS on FlexRay.
· ISO 14229-5 specifies, UDS on IP.
· ISO 14229-6 specifies, UDS on K-Line.
· ISO 14229-7 specifies, UDS on LIN.
UDS Working topology:
UDS functions in an elementary Client-Server topology. Where a ‘Tester’ requests for service, hence termed as a ‘client’, and the ECU responds or serves to the request made by the’ Tester’, hence known or termed as a server.
Tester/Client:
The Tester/Client uses the diagnostic functions and other functions such as database management, specific interpretations, and human-machine interface. A system that controls functions such as inspection, monitoring, testing or diagnostics on and on-vehicle ECU, and it may be dedicated to a specific type of operator: o An off-board scan tool dedicated to garage mechanics. o An onboard tester tool dedicated to assembly plants, etc.
Server:
The Server functions as a part of an ECU and provides diagnostics services. ECU contains at least one server. UDS differentiates between the server and ECU so that the standard remains independent from the implementation. Includes ABS (Anti-Lock Braking System) and engine management systems.
Every server or ECU in the vehicle must be able to communicate with the tester tool as per the UDS protocol. The tester can trigger various actions in the ECU in the form of service requests. Such as,
- Initiate diagnostics session.
- Read or clear the diagnostics trouble code.
- Troubleshooting vehicle issues.
- Extracting parameter data values.
- Test safety-critical issues.
- Requesting for data.
- Writing some data.
- Running tests on components and getting back the results.
- Flashing a program.
- Clearing memory.
- Setting a schedule, etc.
UDS defines many diagnostic services which can be requested by a tester as a client and performed by an ECU as a server:
- Available services.
- Format request message.
- Format response messages.
- What must be the timing parameters?
- Service handling by tester and ECUs, nodes, etc.
UDS Service Request: Format
By now, it must be clear that UDS is a collection of diagnostic services. Each service has a pre-defined ‘Service Identifier (SID)’ assigned to it.
Service request message for UDS
i. SID or Service identifier:
This is a 1-Byte hexadecimal code that values from 0x00 to 0x3E. This identifier allows the server (ECU) to understand which service is requested by the client/tester. This is a mandatory field as, without the service identification number, the service request will not be understood by the ECU.
ii. SubFn or Sub Function: tells the server which sub-functionality is requested for a given service. This is also 1-byte long and belongs to a single server. For example,
· 01 - Request service
· 02 - Start service.
· 03 - Stop the service.
· 04 – Request results. Etc.
Sub-functions filed is an optional field as these are needed for some selected services only. Some services that need reading or writing data by the identifier require no sub-functions.
iii. DID or Data Identifier: The client and server communicate using only numbers in a basic format. A number must be assigned for all the data elements that the tester reads, known as the data identifier for that particular data element. Did is 2-byte long in UDS, and different elements are identified using different data identifiers by both the server and the client.
· OBD - in Onboard diagnostics, DIDs are standardised globally.
· UDS – Car manufacturers define their own DIDs; only the tester tools from the OEM can read these DIDs
The data identifiers field is completely optional, as there are services that do not need DIDs at all. Or, a single or multiple data identifier can also be present in a single message. These can be Data-oriented (DID), routine Oriented/controlled (RID), MID, or UID.
iv. Data Req or Data Request Filed: This field consists of the mete-data related to the data identifier of a specific message. This is n-bytes long and can be optional or mandatory as per the service request.
Response:
i. Positive Response Message: (Server to Client) Once the service request message is received by the server, it checks the request message. If everything is fine, the server performs the service requested and sends a positive response message.
Positive response message
· PR SID or Positive Response Service Identifier: this is the same as the service identifier in the request message and is also 1 byte long. It ranges from hexadecimal 0x40 to 0x7E. Its value can always t=be determined by adding 0x40 (hexadecimal) to SID.
For example,
If
SID = 0x1E,
Then
PR SID = 0x1E + 0x40 = 0x5E
· Sub Fn: 1- byte, optional.
· DID: same as in SR message. 1-byte long and optional.
· Data Req.: optional, extremely customized to the service.
ii. Negative Response Message: (Server to Client) if a certain requested service cannot be performed by the server, it responds to the server with a negative response message.
Negative response message
This can occur for many reasons, such as wrong request format, unsuitable working conditions, specific security reasons etc.
· NR-SID: 1-byte pre-define 0x7E marks the negative response.
· SID RQ: 1-byte long Id of the service that cannot be performed.
· NRC: 1-byte long, indicates the reason for not performing the requested service. In UDS, various NRCs are pre-defined under which the server can reject to perform the service.
Website link for NRCs:
Check out our UDS-compatible devices!
Data loggers are ideal for vehicle engineering teams that use XCP or UDS protocols.
Data logger configuration tool with integrated data analysis
Module Analyser is a 5 in 1 easy to use CAN bus analyser
References: