[DoCAN] Vehicle Diagnostic Communication Part 43 [UDS 4]

[DoCAN] Vehicle Diagnostic Communication Part 43 [UDS 4] 車両診断通信
[DoCAN] Vehicle Diagnostic Communication Part 43 [UDS 4]

Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/

Introduction.

Description of ISO 14229 (UDS).
In this article, the following functional units of UDS will be explained.

  • Stored Data Transmission
  • Input/Output Control

Stored Data Transmission

Stored Data Transmission is explained here.

ServiceSIDDescription
ClearDiagnosticInformation$14Clear diagnostic information (DTC, freeze data)
ReadDTCInformation$19Request diagnostic information (DTC, freeze data)

This functional unit has relatively few types.
It is a clear and request for diagnostic information.
Diagnostic Trouble Codes (DTC) and freeze data are positioned as diagnostic information.

Let me briefly explain DTCs.
Basically, DTCs are 16-bit length codes.
UDS assumes a 24-bit length format.
Both of these are defined in the SAE-J2012 standard, but the details would be quite voluminous, so I will not go into them here.

Let me also explain about freeze data.
When a failure is detected, there is a function that records a snapshot of the vehicle information along with the failure code, and this snapshot is called freeze data.

This freeze data is used to investigate the cause of the failure.
There are many things that can be predicted from DTCs.
However, if we want to investigate in more detail, we need to know what happened at the moment of failure or just before the moment of failure.
This freeze data is a hint for that.
As one would expect, it is not possible to store all kinds of data, so it is often limited to the minimum necessary major data.

Input/Output Control

Input/Output Control is explained here.
There is only one type of service.

ServiceSIDDescription
InputOutputControlByIdentifier$2FI/O Control Request

Although there is only one type of service, it is a rather troublesome type of function.
After all, since it is an I/O control request, the story does not end with the implementation of communication alone.

This service is used for inspection after assembly or parts replacement.

It’s good to have replaced parts, but isn’t it scary not knowing if the vehicle is OK or not until you drive it?
It would be useful to have a function to control some actuator in a single shot to check its operation without moving the vehicle.
This would be the role of the InputOutputControlByIdentifier Service.

This should be considered a very important service.
Without this service, it would be impossible to inspect whether the product is really safe or not even though it has been assembled at the factory, so it is a very cost-effective function.

Also, this service has severe operating conditions.
What do you think would happen if I/O control is forced while the vehicle is running?
It would be very dangerous, right?

Therefore, specifications that reject I/O control unless the vehicle speed is 0[km/h] or automatically cancel I/O control when the vehicle speed becomes other than 0[km/h] during I/O control are often included.

In this way, the service has many things to take care of other than communication.

Conclusion.

  • Stored Data Transmission Description.
    • Getting and clearing DTC and freeze data.
  • Input/Output Control Description.
    • I/O control of ECU.
    • While convenient, this service can be dangerous depending on the condition of the vehicle,so it is necessary to consider safety functions.

Click here for back issues.

コメント

タイトルとURLをコピーしました