[DoCAN] Vehicle Diagnostic Communication Part 54 [UDS 15]

[DoCAN] Vehicle Diagnostic Communication Part 54 [UDS 15] 車両診断通信
[DoCAN] Vehicle Diagnostic Communication Part 54 [UDS 15]

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

Introduction.

Explanation of ISO 14229, the UDS.
This article describes the TesterPresent service.

What is TesterPresent Service?

This article explains the TesterPresent service.

What functionality does the TesterPresent service provide?
The answer is: “Nothing.”
You may be thinking, “What does it mean?
It is really a “do nothing” function.

So, the question is, “Is it something we don’t need?” The answer is “something very important”.
(Again, “What do you mean?” you might have wondered…)

Need for TesterPresent service

It is true that there is no specific process for receiving a message with the TesterPresent service.
So, it would be better for you to know in what kind of scene it is used.

The following are the scenes.

  • Confirmation of communication
  • Node presence/absence check
  • Session maintenance

You must be thinking, “This is just like ping, isn’t it?”
It is true that it is similar.
You can use the same image to confirm the communication and the presence or absence of a node.

TesterPresent Service and Session Relationships

This section explains the session maintenance of the previous usage scenario.
Session maintenance means maintaining the state of transition to non-defaultSession.

Now, do you remember what happens to the session when it returns to defaultSession?
The answer is as follows.

  • DiagnosticSessionControl service requests defaultSession transition
  • S3 time elapses
  • IGoff

The TesterPresent service is used to suppress the second S3 time lapse.

Note that it is not necessary to be a TesterPresent to suppress S3 time elapsed.
Any other valid diagnostic communication can be used to suppress S3 time elapsal.
Therefore, another service may be used to maintain the session.
However, the problem is that it is necessary to know in advance which service will reliably respond.
Furthermore, it is desirable to have a service that does not affect internal processing when requested.

As a possible service, the DiagnosticSessionControl service is a candidate.
It could be said that this service is always supported because of session transitions.

However, this method cannot be adopted.
Even if the same Session is specified in the DiagnosticSessionControl service, it is considered a transition request, and the security unlocking returns to the locked state again.

This is why the TesterPresent service is appropriate for session maintenance.

The question is whether the TesterPresent service is always supported.

No need to worry.
ISO 14220-1 specifies that it is a service that must be supported.
This is a very well thought-out specification.

Conclusion.

  • There is a service called TesterPresent service that does nothing.
  • The TesterPresent service has the following usage scenarios.
    • Checking for communication.
    • Node presence/absence check.
    • Session maintenance.
  • The TesterPresent service is a service that must be supported.

Click here for back issues.

コメント

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