[DoCAN] Vehicle Diagnostic Communication Part 56 [UDS 17]

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

Introduction.
ReadDataByIdentifier service
Usage scenarios for the ReadDataByIdentifier service
Vehicle status monitoring
Forced operational status monitoring during vehicle assembly
Freeze data acquisition at the time of fault detection
Conclusion

Introduction.

Explanation of ISO 14229, UDS.
This article explains the ReadDataByIdentifier service.

ReadDataByIdentifier service

This article explains the ReadDataByIdentifier service.

This service enables reading of vehicle control information.
In reality, not only control information, but also fault information, identification information, and various other information can be read.

There are specific usage scenarios for this as well.
However, there are too many to list here, so I will try to explain them briefly.

Usage scenarios for the ReadDataByIdentifier service

Usage scenarios are roughly as follows

Vehicle status monitoring (verification during development, failure analysis after market release)
Forced operation status monitoring during vehicle assembly
Freeze data acquisition at the time of failure detection

Compared to the use scenarios of the services up to now, this would seem to be a wide range of use.
Since the function is to read out some kind of information, the service will always appear in situations where the desired information is available.

What is the nature of the data that can be obtained in each scene?
This is a manufacturer-dependent question.
Let me talk about the scope of my experience.

Vehicle status monitoring

Vehicle status monitoring can include vehicle speed, engine RPM, water temperature, ignition timing, fuel injection time, and so on.
It is good to think of it as information that shows how the vehicle is moving.

IG on/off, acceleration/deceleration, fuel cutoff, braking, etc. are all important.
These are triggers that may cause a malfunction or abnormal values to appear.
When a malfunction or abnormal value is detected, it must be analyzed.
Therefore, it is necessary to have data that can identify the cause of the problem.

Forced operational status monitoring during vehicle assembly

This would be a story of cooperation with the InputOutputControlByIdentifier service, an I/O control request.

For example, the following usage is possible.

When an engine valve is opened or closed using the InputOutputControlByIdentifier service, the ReadDataByIdentifier service is used to read the data and check whether the valve is working properly.

If combined properly, automatic confirmation is also possible.
(In reality, I think visual checks are done as well…)

Freeze data acquisition at the time of fault detection

Freeze data can be read by OBD, and the concept is the same.
However, it is better to assume that what is read out by the ReadDataByIdentifier service includes many manufacturer-dependent parameters.
Since the purpose of the ReadDataByIdentifier service is to obtain more detailed information in case of failure, it is determined based on past failure cases and control characteristics.
Therefore, there is no one particular parameter that is always used.

In the next article, I will explain the actual message of ReadDataByIdentifier service.

Conclusion

Explanation of the usage scenario of the ReadDataByIdentifier service.
- Vehicle status monitoring (verification during development, failure analysis after market release).
- Forced operation status monitoring during vehicle assembly.
- Freeze data acquisition at the time of failure detection.

Click here for back issues.