Vehicle Network Test - UDS Diagnosis - Diagnose RID/IOID ($2F/$31)

UDS diagnosis has introduced the format of diagnostic messages in each service in the previous article, as well as some introductions of fault codes and DIDs. For the sake of completeness, this article will continue to be supplemented today to introduce RID and IOID (that is, Routine Control and IO control), seeing their full names, you should be able to understand from the literal meaning that these two are services and control, which is why I put them together for introduction. The difference between them is that one is the control software logic class, and the other is the control of the hardware IO interface. Below we will introduce the two services one by one.

Function
 

The 31 service is also called Routine Control. This service is mainly to control the internal software logic of the product, such as pre-erasing the flash when CAN/CANFD or DoIP is upgraded; or making an xcall call; playing the driver AVAS sound, etc. Function.

The 2F service is also called IO control, which is also very simple. IO is the hardware interface, and this service is to control the hardware interface, such as controlling the lifting of the car window; adjusting the rearview mirror; and controlling the internal lighting and other functions. In terms of function, these two are very similar, both are controls, the difference is that one is the control of the internal logic of the software, and the other is the control of the IO hardware interface.

command format

31 service request format: 31(service)+01/02/03(sub-service)+RoutineID+OptionRecord

All 31 services must include 31 (service) + 01/02/03 (sub-service) + RoutineID, and OptionRecord is optional 3, the data will only be added when necessary, if not the entire command is required This part is optional.

We will not introduce too much about RoutineControl Request SID and RoutineIdentifier. In 31 services, RoutineControl Request SID is fixed and 31 will change, while RoutineIdentifier will be determined at the beginning of device design according to different DUT specifications. Different IDs represent different functions. We are mainly talking about Subfunction. The 31 service mainly includes 01/02/03 3 subfunctions, where 01 stands for startroutine (start routine), 02 stands for stoproutine (stop routine), and 03 stands for requestroutineresult (get routine result) .

Among them, the startup routine must be supported. Obviously, if the routine is not started, there will be no stop and request results, so 01 must support it; the stop routine and request routine results depend on the needs of each OEM or Specific functional needs are optional. For example, turning on the backlight, this action is performed in an instant, then obviously we cannot stop it, so there is no need to stop the function of the routine, but if we are a black box test, we You can check whether the startup was successful by getting the routine request result.

Another example is erasing flash, since this process takes a while to complete, it will involve that we want to stop erasing halfway through erasing, so we can use the stop routine to terminate the operation.

 

The request format of 2F service: 2F(service)+DataID+01/02/03(sub-service)+MaskRecord

All 2F services must include 2F (service) + DataID + sub-services, and MaskRecord is optional, and the data will only be added when necessary. If there is no need for the entire command, this part is not required.

We will not introduce too much about IO Request SID and DataID. In 2F service, IO Request SID is fixed and 2F will change, while DataID will be determined at the beginning of device design according to different DUT specifications. Different IDs represent different functions. We are mainly talking about Subfunction. The 2F service mainly includes 01/02/03 3 subfunctions, among which 01 stands for ReturnControltoECU (control returns to ECU), 02 stands for stopcontrol (stop control), and 03 stands for shortterm adjustment (obtains control) .

Compared with 31 services, 2F services are commonly used in 01 and 03 sub-services. The reason is easy to understand. If you get the control of a certain hardware from other places, you must return it to others after use, otherwise other How the ECU is used.

Let's take the commonly used MIC in the car as an example. Usually the MIC is hung on the central controller, but when dialing xcall, we need to give the control of the mic to the tbox from the central controller. After the end of the xcall, control It is a normal process to return the right to the central controller. If we return it to the central controller, the central controller will not be able to use the MIC.

Acknowledgment

Affirmative response: (sessionParameterRecord is defined for each OEM)

The following figure shows the positive response format of 10 service diagnostics:

The specific meaning of sessionParameterRecord is shown in the following figure:

Negative answer:

Since each OEM has different regulations on negative acknowledgment, we will not give a full introduction here. We only say that the negative acknowledgment codes that must be supported generally include NRC 13 (command length error); NRC 12 (sub-service function is not valid). support). We confirm other negative response codes according to the specific definition of the OEM.

Guess you like

Origin blog.csdn.net/moyunzhiyin/article/details/129313980