Diagnostic learning record (1)
Diagnostic Learning Record 2 - UDS Service
Diagnostic learning record (3) UDS service list
Vehicle diagnosis requires a Tester side and an ECU side. The Tester side and the ECU side communicate in the form of questions and answers, so both the Tester side and the ECU side need to follow the same diagnostic communication protocol.
Commonly used diagnostic protocols include ISO 14230, ISO 15031, ISO 15765, and the familiar ISO 14229, which is the UDS protocol. In the protocol, the diagnostic request, the message format of the diagnostic response, and how the ECU processes the diagnostic request message are defined. and application of diagnostic services.
The full name of UDS is Unified diagnostic services, which is unified diagnostic services.
UDS mainly provides unified diagnostic functions for vehicle electronic control units, such as automatic transmissions, anti-lock braking systems, etc.
UDS includes requirements for transmission, data processing, and specific diagnostic application services. It does not only refer to a certain aspect of diagnostic services, but also includes a series of standards and standards for transmission methods, data format requirements, specific diagnostic services, etc. Interaction architecture.
As defined in the international standard ISO 14229-1, the UDS standard not only defines the usage of services and the format of the services, but also defines some standardized data. When the OEM wants to use the UDS protocol, in addition to using the services defined by the standards and In addition to standard data, it is also necessary to define specific data belonging to the OEM based on its own situation. For example, define the services to be followed, the DIDs that need to be supported, the DTCs that need to be supported, etc. In this way, the diagnostic specifications that comply with an OEM can be formed. Used for the development and verification of ECU diagnostic functions.
The following figure describes the application of UDS in the OSI seven-layer model. The first and second layers of the OSI seven-layer model define the physical layer and data link layer respectively. The third and fourth layers define the network layer and transport layer. ,The seventh layer is the application layer.
Application layer : The specific implementation of diagnostic services, used by tester/client to issue diagnostic requests, and the server (MCU) makes different responses according to the requests.
Network layer : The middle layer is a bridge for data conversion, including multi-frame data transmission, data packaging and unpacking, and coordination of upper and lower layer work; it also includes communication between peer entities, data synchronization, time management, and error management.
Data link layer : CAN bus (ISO 11898-1) The originally specified link layer protocol only included abstract requirements for the physical layer. ISO11898-1-2015 specified the classic CAN frame format and the newly introduced CAN-FD frame format. The electrical aspects (voltage, current, number of conductors) of the high-speed physical layer come from ISO 11898-2, which is currently widely accepted; the low-speed is in ISO 11898-3. However, there is no standard document to formally specify the mechanical aspects of the physical layer (type and number of connectors, colors, labels, standard output).
Physical layer : Hardware conditions required for transmission, including transceivers, terminal resistors, twisted pairs, distance limitations, sizes; which sensors' CANH and CANL are connected to the network, network communications at different rates require gateways, etc.
For example, we are familiar with the CAN bus. The physical layer and data link layer follow ISO 11898, and its transmission layer follows ISO 15765-2. The application of UDS based on the CAN bus is defined in ISO 14229-3, and now The relatively popular Ethernet, its physical layer and data link layer follow ISO 13400-3, its transport layer, that is, DoIP, follows ISO 13400-2, and its UDS application based on Ethernet is ISO 14229- 5
Description of the diagnostic process:
Client/tester: Send diagnostic requester (read and write data, start routine)
Server (server/ECU): Provider of diagnostic response-ECU sends diagnostic response (positive response, negative response)
Remote diagnosis: The client and server are not in the same network segment
Service function:
Request request: The diagnostic instrument sends a request to the ECU;
Request confirmation req_confirm: When the request is successfully received, the diagnostic tool will call req_confirm to indicate that "the request has been successfully sent correctly";
Indication: After the ECU receives the request, there will be an indication (callback) telling the upper layer of the ECU that "a diagnostic request has been received";
Response: After the ECU processes the request, a response will be returned;
Response confirmation rsp_confirm: After the diagnostic instrument receives the response, the ECU will trigger rsp_confirm, indicating that the response is sent successfully;
Confirm: When the response is sent to the network and received by the diagnostic instrument, the diagnostic instrument will have a confirmation (callback) to indicate that the request has been processed;
Services are divided into two categories: confirmed services and non-confirmed services:
- There is a confirmation service:
- No confirmation service:
Diagnosis process:
Diagnostic Learning Record (2) - UDS Service
There are two UDS addressing modes :
Functional addressing (1:N) :
A one-to-many diagnostic communication method is used between the client (Tester) and the server (ECU) . The client sends diagnostic requests for the same function address to multiple servers.
Physical addressing (1:1) :
One-to-one diagnostic communication is used between the client (Tester) and the server (ECU) .
UDS application layer services
Service primitives:
Service Request Primitive : Used by the client of the diagnostic tester diagnostic application to initiate the requested service and pass data about the requested diagnostic service to the ECU.
Service request confirmation primitive : used to indicate whether the requested service is transmitted correctly.
Service indication primitive : The application layer uses the indication primitive to pass the requested diagnostic service data to the diagnostic application program of the ECU and start the corresponding service function.
Service response primitive : used by the server in the ECU diagnostic application to start the response service and pass the response data provided by the diagnostic service to the diagnostic tester.
Service response confirmation primitive : used to indicate whether the response service is transmitted correctly.
Service Confirmation Primitives : The application layer uses confirmation primitives to pass the results of previous service requests to the diagnostic tester.
The message format of the service request primitive is as follows:
A_MType (application layer message type) :
Type: enum
范围：diagnostic，remote diagnostic
illustrate:
If diagnostic, the primitive does not contain the A_AE parameter.
If remote diagnostic, the primitive contains the A_AE parameter.
A_SA (application layer source address) :
Type: 2-byte unsigned integer
Range: 0x0000 ~ 0xFFFF
Description: Used to encode client and server identifiers.
A_TA (application layer target address) :
Type: 2-byte unsigned integer
Range: 0x0000 ~ 0xFFFF
Description: Used to encode client and server identifiers.
A_TA_type (application layer target address type) :
Type: enum
Scope: physical, function
Description: Used to describe the addressing mode of the message.
A_AE (application layer remote address) :
Type: 2-byte unsigned integer
Range: 0x0000 ~ 0xFFFF
Description: Used to extend the available address range to encode (remote) client and (remote server) identifiers.
A_Length：
Type: 4-byte unsigned integer
Range: 0 ~ 232-1
Description: The length of data to be sent/received.
A_Data：
Type: string
Range: 0 ~ 232-1
Description: Data that needs to be sent/received.
Data format of UDS application layer service :
Request Service Identifier (SID) :
Type: 1-byte unsigned integer
Range: 0x00 ~ 0xFF
SID of the requested service: (X0XXXXXX)b The 6th bit of the SID is 1
Positive response service identifier (SID) :
Type: 1-byte unsigned integer
Range: 0x00 ~ 0xFF
Positive response service identifier: (X1XXXXXX)b SID bit 6 is 1
Positive response service SID = Requesting Service Identifier + 0x40
Negative response service identifier (NR_SID) :
Type: 1-byte unsigned integer
Fixed value: 0x7F
First, let's look at the service request and response format. The "request" is sent to the ECU by the Tester. The request message contains the SID, and specific data is added according to the specific service content. The positive response format consists of "SID+40+specific data". The negative response format is a fixed format "7F + SID in the request message + one byte NRC".
Look at the two nouns, one is called Subfunction and the other is called ID. The UDS service supports the request and response format of Subfunction. "Request" is " SID + one byte Subfunction + specific data ".
The affirmative response is " SID+40+Subfunction+specific data ", but some UDS services do not support Subfunction, but support DID. DID means "data ID", so its request format is "SID+specific DID+ Data content", definitely respond to "SID+40+DID+specific data", here are two examples, one is "31 routine control service", and the other is "2F IO control service", 31 is its request In the message, there is a one-byte Subfunction and a two-byte Routine ID. The following data is related to the specific data content, or there may be no specific data. 2F is its SID + two bytes of DID + one byte of input and output control parameters (note here that this one byte of data is similar to a Subfunction, but it is not a Subfunction) + add specific data content at the end.
There is a concept in the picture above, which is the positive response inhibition bit. The positive response suppression bit is the highest bit of this byte in the Subfunction. We call it the positive response suppression bit. Only when this service supports Subfunction, it is possible to support the positive response suppression bit. When the positive response suppression bit is set to 1, all positive response suppressions will no longer be sent. When the positive response suppression bit is 0, the positive response is not suppressed. The important thing to note here is that it only suppresses positive responses, while negative responses are not suppressed.
The format of the request message sent by Tester is wrong, or the conditions for sending the request are wrong. The ECU will send a negative response. The format of the negative response is "7F+SID+NRC". The commonly used NRCs are listed here.
11 means the service is not supported;
12 subfunction is not supported;
13 The requested length is incorrect or the format is incorrect.
31 is a request out of range;
7E means subfunction is not supported in the current session.
7F means the service is not supported in the current session.
The following are time-related parameters:
After Tester sends a request to the ECU, the ECU needs to give a corresponding response within the P2Sever time. If the ECU is currently processing other tasks and other things and cannot give a corresponding response within the P2Sever time, then it first A Pending message with an NRC of 78 will be given within the P2Sever time to tell the Tester that "the ECU is busy". Then other response messages will be given within the P2Sever* time. If the response message cannot be given within the P2Sever* time, Positive response and negative response will continue to give Pending messages until the request message can be processed correctly, and the correct response message will be given.
P2 Server：
When the ECU (Server side) receives the request, it needs to respond within the P2 time. If it times out, it will report Timeout and return a negative response (0x7F+SID+0x78), indicating that the response has timed out.
In actual projects, P2 Server and P2 Client will be distinguished, where Server corresponds to ECU and Client corresponds to Tester.
P2* Server：
When the ECU receives the request and does not give a response within the P2 time, the ECU will send a negative response (0x7F+SID+0x78) and start the P2* timer. When the P2* timer arrives, if no response has been sent, a negative response (0x7F+SID+0x78) is sent again to restart the P2* timer.
In actual projects, NRC 0x78 will not be sent all the time, and the number of times to start the P2* timer is defined by the OEM.
The recommended value for P2 Server in ISO-14229-2 is 50ms, and the recommended value for P2* Server is 5000ms.
In addition, there is a time parameter S3 Server related to UDS session mode.
UDS session mode:
UDS has three session modes: default session, extended session, and programming session
The 0x10 (Session Control) and 0x11 (ECU reset) services can change the session mode of the ECU
S3 Server：
The maximum time that the S3 Server remains in the non-default session, that is, when the ECU is in the non-default session mode, if no diagnostic request is received within the S3 time, it will automatically fall back to the default session mode.
Periodically send the 0x3E (Test Present) service to maintain the ECU in non-default session mode.
The following is the conversion diagram of UDS session mode:
The diagram of S3 Server time is as follows:
