I. Overview
The services defined by UDS are logically divided into 6 categories. In the previous article, the diagnosis and communication management category, "data transmission category", and "storage data transmission" have been interpreted. This article will introduce the remaining three types of UDS services, namely "IO control service", "routine program service" and "upload and download service".
2. Diagnostic service content
O control services
1. InputOutputControlByIdentifier (0x2F)
$2F is a service that uses ID to control the input and output of ECU, and is often used on the production line to verify the function of parts. For example, in the final assembly stage, workers need to verify whether the various functions on the car are normal, such as whether the four windows are up and down normally. If they press the switches one by one, the efficiency is very low. If they can observe the window up and down through a diagnostic command, the efficiency is much higher.
For example, if the ECU receives an input signal A, we can use 2F to assign a value we need to this A; if the ECU controls an actuator B, we can use the 2F service and add some specific parameters to realize the control of B, such as door control to control the window lift, rearview mirror folding, etc.
The request of $2F service consists of 4 parts
The first byte: SID=0x2F
The second and third bytes: dataIdentifier (2 byte), used to identify the controlled IO object, for example, the following example 0x9B00 (inlet door position)
The fourth byte: controlOptionRecord, used to identify the control type, and several bytes of controlState used by the manufacturer. UDS clearly defines four control types
0x00 Return control to ECU, that is, end control
0x01 Set the input signal, internal parameters, output signal, etc. of the object identified by DID to the default value
0x02 Freeze the input signal, internal parameters, output signal, etc. of the object identified by DID
0x03 Setting the input signal, internal parameters, and output signal of the object identified by the DID is equivalent to starting the control of the ECU. This control type will be followed by the fifth byte, which can represent the digital or analog value of the control object.
for example:
Use 2F to control the Air Inlet Door Position (air inlet door position), and use DID (identifier) = 0x9B00 to identify the position of the air inlet door.
Air Inlet Door Position [%] = decimal(Hex) * 1 [%] , that is, use a percentage to represent this position.
step1:
The tester sends 22 9B 00 to read the current position of the air intake door, where 22 is the SID, and 0x9B00 is the second and third byte DID.
ECU returns 62 9B 00 0A, where 0x0A = 10 (dec), which means the current position is 10%
(UDS defines that the dataIdentifier used in the 2F service can be read by the 22 service, and the return value is status information. The specific status information is defined by the user.)
step2:
The tester sends 2F 9B 00 03 3C , which means to adjust the position of the air inlet door to 60%, and 0x3C = 60 (dec) means to set the analog value of the control object to 60%.
The ECU returns 6F 9B 00 03 0C, indicating that the control is accepted, and the current position of the air intake door is 12%. Because the ECU responds immediately after receiving the request, and the adjustment of the door position takes time, so it has not reached 60%.
step3:
After a while, the tester sends 22 9B 00 to read the current position of the air intake door
ECU returns 62 9B 00 3C , 0x3C = 60 (dec), indicating that the current position has reached 60%
step4:
tester sends 2F 9B 00 00 to return control to ECU
ECU returns 6F 9B 00 00 3A, indicating that the request is accepted, and the current position is 58%
step5:
The tester sends 2F 9B 00 02 to freeze the state of the air inlet door position represented by the ID 9B 00
The ECU returns 6F 9B 00 02 32, indicating that the request is accepted, and the current position remains at 50%
In addition, there is a problem with the 2F service (quoted from Zhihu author "The Flower of the Soul"). If a certain value is modified through the 2F service and the control is not returned to the ECU, then the effective time of this modification will continue? The correct way is to switch back to the default session if the extended session times out. At this time, the control right should be returned to the ECU. After all, the 03 sub-function of 2F is "temporarily taking over the control right".
routine control service
RoutineControl (0x31)
The $31 service is an interface for calling some operation sequences built into the ECU. The application of this service is very flexible, because manufacturers can define various internal operations for the ECU according to their own needs, and to execute these operations, they only need to call the 31 service. Typical uses include checking boundary conditions, clearing flash memory, verifying data, verifying software and hardware dependencies, etc., and even restoring factory settings if necessary, and many operations related to the ECU's own logic functions can also be defined.
31 service request consists of 4 parts
SID=0x31
sub-function, sub-function, start (0x01), stop (0x02), query result (0x03)
routineIdentifier, the task ID, used to identify the routine to be executed
routineControlOptionRecord, this is an optional parameter, which is used to identify the parameters required for routine execution, and each company can customize its content
for example:
Assume that the ID 0x0809 is used to represent the routine that checks whether the ECU meets the software flashing conditions (such as the vehicle speed and rotation speed are 0, KL15 is turned on, etc.).
The tester sends 31 01 08 09 to start the routine 0x0809
If all the conditions are met, the ECU returns 71 01 08 09 as the echo. If the conditions are not met, the ECU returns 71 01 08 09 XX YY ZZ, and the following XX YY ZZ indicates which conditions are not met, and the specific content is defined by the manufacturer.
Upload and Download Services
The transmission of ECU upgrade data is completed through services such as 34 (request to download), 36 (transmit data), 37 (request to exit transmission). Since the buffer size used to cache diagnostic service data in the automotive ECU is limited, when we need to read or write data exceeding the buffer size, we cannot simply use 2E and 22 services. Therefore, UDS defines several services for writing or reading large blocks of data, namely data download and upload.
The Upload Download functional unit defines a total of 5 diagnostic services, namely:
RequestDownload (0x34): The diagnostic instrument requests the ECU to download data
RequestUpload (0x35) The diagnostic instrument requests the ECU to upload data
TransferData (0x36) The diagnostic instrument transmits data to the ECU (download), or the server transmits data to the client (upload)
RequestTransferExit (0x37) Data transfer complete, request to exit
RequestFileTransfer (0x38) The operation of transferring files can be used to replace upload and download services.
The figure below shows the simplified process of data downloading. The three services 34, 36, and 37 are used. If it is uploading, the 34 service is replaced by the 35 service, and the data transmission direction is changed.
step1:
The diagnostic instrument transmits the starting address of the block and the data length information of the block through 34 services; download request;
After the ECU receives the download request of the 34 service, it notifies the diagnostic instrument through a 74 positive response message, how many data bytes should be included in each next data transmission message (36 service) of the (diagnostic instrument). The diagnostic instrument adjusts its own sending capability according to the returned parameters;
step2:
The diagnostic instrument transmits the data of this block through 36 services, and the amount of data transmitted by each 36 services is determined by the parameters in the 34 services (ie SID=0x74) returned by the ECU, see below for details.
The ECU returns a positive response to the 36 service;
The data is split and sent sequentially through 36 services, and the ECU replies with an affirmative response every time the sending of 36 services is completed. Until the block of data is all sent;
step3:
The diagnostic instrument performs a transmission exit request by sending 37 service;
The ECU makes a positive response reply.
The description of each service is as follows:
The description of each service is as follows:
RequestDownload （0x34）：
The 0x34 service is used to start the download transmission, and its function is to inform the ECU that it is ready to accept data, and the ECU tells the diagnostic instrument whether to allow the transmission and how much it can accept through the 0x74 response.
The request format of 0x34 service includes 5 parts
The first part: 1 byte SID=0x34
The second part: 1 byte dataFormatIdentifier, used to indicate the method of data compression and encryption. Among them, bits 7-4 define the compression method; bits 3-0 define the encryption method. When the byte is 0x00, it means that neither the compression method nor the encryption method is used. The definitions of other values other than 0x00 are stipulated by the car manufacturers themselves.
The third part: 1-byte addressAndLengthFormatIdentifier, which is used to indicate the number of bytes occupied by the latter two parts. The high 4 bits indicate the byte length occupied by memorySize, and the low 4 bits indicate the byte length occupied by memoryAddress. In this example I set these two values to n and m respectively.
The fourth part: memoryAddress of m bytes, indicated by the lower 4 bits in addressAndLengthFormatIdentifier. The meaning is to write the logical address of the data in the ECU.
The fifth part: the memorySize of n bytes, indicated by the high 4 bits in addressAndLengthFormatIdentifier. Meaning is the number of bytes of data to write.
After the ECU receives the request, if the transmission is allowed, it will give the following response
The first part: 1 byte Response SID=0x74
The second part: 1 byte dataFormatIdentifier as echo
The third part: maxNumberOfBlockLength, the length is variable, indicating the maximum amount of data that can be transmitted at one time through the 0x36 service.
TransferData（0x36）：
If the 34 service gets a correct response, the tester will start the data transmission process, and the 36 service is used. 36 The format of the service is as follows.
The first part: 1 byte SID=0x36.
The second part: 1 byte blockSequenceCounter, which identifies the number of data blocks currently being transmitted, that is, the frame number, or simply put, the number of times the 36 service is called.
The third part: transferRequestParameterRecord, the transferred data. The upper limit of the amount of data transmitted for the first time is the maxNumberOfBlockLength in the 34 service response.
Example: If the ECU informs the tester that maxNumberOfBlockLength = 20 (echo from the $34 service), that is to say, the tester can only send a maximum of 20 bytes each time through the 36 service, including SID and blockSequenceCounter, so in fact, the data information that can be transmitted each time is only 18 bytes. If the data to be transmitted by the tester is 50 bytes, it needs to be transmitted three times, each time transmitting 18, 18, and 14 bytes respectively, that is, calling 36 services three times.
The response of 36 is very simple, that is, one byte of Response SID plus one byte of blockSequenceCounter as echo.
RequestTransferExit（0x37）：
The $37 service is used to quit uploading and downloading. If the previous 34 and 36 services are successfully executed, then the 37 service can get the positive response from the ECU.
The format is very simple, the request is 37, and the correct response is 77, both of which are one byte.
If the previous 36 services are not executed, take the example I gave earlier, for example, the data block has 50 bytes, but the tester only sends the 36 services twice and 36 bytes, then this transmission is a failure for the ECU, so the ECU should give NRC 0x7F 37 24, indicating that there is an error in the execution of the diagnostic sequence.
3. UDS application equipment
Among the UDS diagnostic products, the most well-known and widely used CAN card VN1630/1640 of German Vector Company, together with its CANoe software, Vector products have complete functions and are suitable for system-level automotive bus development, and are adopted by most automobile manufacturers. Usually engineers first use Vector's CANdela to develop the cdd file, and then import the cdd file into CANoe.diva for functional testing. The link below is a complete set of solutions provided by Vector, and CANdesc is a UDS code generation software.
Vector products are easy to use, save development time, do not open API, and are expensive, so they are not suitable for automated testing of hardware development teams and production lines. At present, there are many CAN manufacturers on the market (such as Kvaser, ZLG, etc.) that can provide devices with low cost, small size, simple driver, and open API, which are very suitable for secondary development.
- summary
So far, the update of the UDS diagnostic protocol has been completed. The UDS protocol is obscure and complicated, and requires real experience to deepen memory and deepen understanding during use. Welcome to communicate at any time.