![[DoCAN] Vehicle Diagnostic Communication Part 48 [UDS 9]](https://www.simulationroom999.com/blog/wp-content/uploads/2022/12/01_eyecatch-10.png)
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.
| SessionType | Value | Description |
|---|---|---|
| defaultSession | 0x01 | A session immediately after startup. If an S3 timeout occurs during another session, it will return to this session. Available services are limited. |
| ProgrammingSession | 0x02 | Session for ECU reprogramming. Transition from this session to other sessions is via ECU reset. |
| extendedDiagnosticSession | 0x03 | All diagnostic services may be available. (actually manufacturer dependent). |
| safetySystemDiagnosticSession | 0x04 | All 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
| Position | Parameter Name | Value |
|---|---|---|
| 1 | DiagnosticSessionControl Request SID | 0x10 |
| 2 | sub-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.
| Position | Parameter Name | Value |
|---|---|---|
| 1 | DiagnosticSessionControl Response SID | 0x50 |
| 2 | sub-function = [ diagnosticSessionType ] | 0x00 – 0xFF |
| 3 | P2Server_max (high byte) | 0x00 – 0xFF |
| 4 | P2Server_max (Low byte) | 0x00 – 0xFF |
| 5 | P2*Server_max (high byte) | 0x00 – 0xFF |
| 6 | P2*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.
コメント