[DoCAN] Vehicle Diagnostic Communication Part 48 [UDS 9]

[DoCAN] Vehicle Diagnostic Communication Part 48 [UDS 9] 車両診断通信
[DoCAN] Vehicle Diagnostic Communication Part 48 [UDS 9]

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

Introduction.

Explanation of ISO 14229, UDS.
In this article, I will explain the service DiagnosticSessionControl used in the UDS simulation.

DiagnosticSessionControl details

This section explains DiagnosticSessionControl(Serviec$10).

You are probably aware that it is a service that performs session transitions.
(It’s even in the name.)

Let’s take a look at what kind of sessions are specified in ISO 14229-1.

SessionTypeValueDescription
defaultSession0x01A session immediately after startup. If an S3 timeout occurs during another session, it will return to this session. Available services are limited.
ProgrammingSession0x02Session for ECU reprogramming. Transition from this session to other sessions is via ECU reset.
extendedDiagnosticSession0x03All diagnostic services may be available. (actually manufacturer dependent).
safetySystemDiagnosticSession0x04All services may be available (especially for safety systems). (especially for safety systems).

Naturally, in addition to these services, each manufacturer can define its own sessions.

The ProgrammingSession part may be a bit difficult to understand.
ProgrammingSession is a bit special.
It is mainly a session for reprogramming ECUs.
Reprogramming is a process that we don’t know how the ECU is programmed, so if we allow other sessions to be moved, we don’t know what will happen to the ECU.
Therefore, the specification of returning to the default session via ECU reset is allowed.

By the way, reprogramming refers to the rewriting of FlashRom in which the microcontroller program is written.

Request message for DiagnosticSessionControl

The request message specification is as follows

PositionParameter NameValue
1DiagnosticSessionControl Request SID0x10
2sub-function = [ diagnosticSessionType ]0x00 – 0xFF

In other words, the first byte is the SID, 0x10, and the second byte is the number of the session to be transitioned.
The expression here is the same as ISO14229-1.

Response message for DiagnosticSessionControl

The response message specification is as follows.

PositionParameter NameValue
1DiagnosticSessionControl Response SID0x50
2sub-function = [ diagnosticSessionType ]0x00 – 0xFF
3P2Server_max (high byte)0x00 – 0xFF
4P2Server_max (Low byte)0x00 – 0xFF
5P2*Server_max (high byte)0x00 – 0xFF
6P2*Server_max (Low byte)0x00 – 0xFF

You may have noticed that the first SID is 0x50.
The rule for the Response SID is to set the Request SID to 0x40 ORed with the Request SID.
In this case, the SID is 0x10, so the Request SID is calculated as follows.

0x10 | 0x40 = 0x50

The second byte, diagnosticSessionType, is the session type specified in the request.

After the third byte, P2 something is lined up.
This refers to P2 time and P2* time.

P2 time has been explained previously.
It is the timeout value between receiving a request message and returning a response message.

Now, what is P2* time?

It would be better to explain ResponsePending in P2* time.
If a normal response is called a PositiveResponse, a NegativeResponse is returned in case of an error.
In the NegativeResponse, there is a ResponsePending.

Since this is also a rather complicated topic, I will explain it next time.

Conclusion

  • Explains the session as defined in the ISO for DiagnosticSessionControl
  • Request message of DiagnosticSessionControl.
  • Response message of DiagnosticSessionControl.
    • P2 time and P2* time of the relevant session can be obtained.

Click here for back issues.

コメント

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