Part of a series on UDS – if you missed it, check out the introduction to the protocol.
What’s a Session and Why do I Care?
UDS Service 0x10 – Diagnostic Session Control, is one of the most widely used diagnostic services and core to our understanding of the UDS protocol. Session control is a way to enter different modes of operation in the diagnostic server (located on the ECU) and to group services together into logical containers, known as sessions. Different services may or may not be allowed to operate in different sessions, and different sessions may not be allowed to be entered in different modes of operation. Hence, gating certain services behind a session ensure that they can only be executed when the operating mode of the ECU is conducive to the execution of that service.
A simple example is defining a session called Programming Session. Our intention behind defining this session is to make a container of services related to (you guessed it) programming the ECU. In order to enter programming session, we can define a set of conditions to make sure it is safe to temporarily take the ECU offline while we reprogram it. These can include, among others, the vehicle at standstill and transmission in park. By grouping several UDS services together and enabling them based on session, we can avoid redundant checks for each service. That is to say, we can check all the preconditions related to programming an ECU once as part of switching sessions. Then, all the services gated by that session can all be assumed to be operating within the same safe state.
Most UDS servers will gate services 0x34 (requestDownload), 0x35 (requestUpload), 0x36 (transferData) and 0x37 (transferExit) behind the programming session. Looking at the above diagram, that means trying to execute a requestDownload before switching to programming session will result in a negative response.
This implicitly requires every UDS service first be checked to see if it is supported in the current session as part of the UDS server implementation. This also implies that there must always be at least one diagnostic session running at all times. This second requirement manifests itself in the default diagnostic session, which is equivalent to a session idle state. See below for a typical example of the different diagnostic sessions and transitions on an ECU:
Notice how the ECU is always in the default session state unless otherwise requested. The other transitions shown above are exemplary, and are up to the system designer to specify. Note too that the above states are prescribed in ISO14229 (see table below), but they allow for custom user sessions to be defined as well.
| Parameter | Name | Description |
| 0x01 | Default Session | The idle state – this session is always active unless explicitly made to switch. |
| 0x02 | Programming Session | Session related to (re)programming the ECU or otherwise transferring data (data uploads are also usually gated by this session). |
| 0x03 | Extended Diagnostic Session | Session related to UDS services that should only be run under prescribed conditions, because they alter the behaviour of the ECU itself. |
| 0x04 | Safety System Diagnostic Session | Session related to UDS functions that, if operated incorrectly or outside of well defined conditions, may cause harm to the ECU, vehicle, or occupant. |
Finally, each session has a set of performance requirements, which are reported by the ECU back to the tester alongside a positive response when switching sessions. Specifically, these performance requirements are the P2server_max time and the P2*server_max time. P2server_max is the time requirement that the server (the ECU) has to reply to a UDS request from the client. P2*server_max is the time requirement for the ECU to send out a UDS response after it has sent out a pending response (see my post on UDS Protocol for what a pending response is). These timing requirements are reported by the ECU and are applicable for the session that the ECU is entering. Different sessions may want to have different performance requirements, which is why this option is given. For example, the default session may have P2server_max as 50ms, because we expect a speedy response for most services. But perhaps P2server_max in the programming session could be increased to 200ms, because we know that some of the UDS services related to programming may consume extra CPU load, and we’d like to give the ECU more time to form a response.
Tester Present
Why is tester present included in this discussion? To answer that, I’ll introduce one final timing parameter: S3server. This is the maximum amount of time you can be in a non-default diagnostic session without receiving a UDS message, before automatically jumping back to the default session. Put simply, each ECU is expected to maintain an internal timer as soon as it’s in any session other than the default session. Any UDS message refreshes this timer – but if S3server time elapses without receiving a message, the ECU shall jump back to the default session.
Instead of forcing the tester to constantly perform arbitrary UDS commands just so the session doesn’t time out, UDS offers a service called Tester Present (0x3E). It literally does nothing except inform the ECU that the tester is still present (hence the name). However, that UDS message is sufficient to refresh the ECU timer, and keep the session from expiring. Many automotive tools that speak UDS will automatically send a tester present message every few seconds (usually 1 second less than S3server to give some buffer) while in a non-default session.
Leaving a Session
Some of you may have noticed a loophole in the way I’ve described sessions thus far. Suppose a certain UDS service is only available in extended session. What if the tester enters extended session, starts that UDS service, and then leaves extended session?
The answer is that upon leaving any session, the ECU shall check whether the new session supports all active UDS services. If any of those services are not active, it must inhibit them from running in the new session.
For example, say we use UDS service 0x28 to turn off communication in the extended session. Upon leaving extended session, the communication must automatically turn itself back on, without the need for the UDS client to explicitly tell the ECU to do so.
Protocol Details
Let’s analyze each step in the diagram above. We see the ECU always starts in the default diagnostic session. The tester sends the UDS command 10 03. We know from the UDS Protocol that this is service ID 0x10, and parameter 0x03, which means we’d like to request the ECU to switch sessions (0x10) to extended diagnostic session (0x03). The ECU receives the request and performs the requisite logic internally to see if it is safe to switch sessions. As soon as the ECU determines its okay to switch sessions, it forms the UDS response 50 03 00 32 02 58. We decode 50 03 as positive response to the session switch command. Then 00 32 is the P2server_max time in force for the new session, and 02 58 is the P2*server_max time. These are in hex, and we can convert them to decimal to yield 50ms for P2server_max and 600ms for P2*server_max. Note that these new performance requirements are in force as soon as the ECU sends the response containing them. From the braces on the right of the diagram, we can see that the ECU is now in Extended Diagnostic Session.
Simultaneously with the positive response to switching sessions, the ECU starts its internal S3 clock. We see that the tester sends one Tester Present message to the ECU (3E 00). This resets the S3 time. In fact, any UDS request would have reset this timer.
Finally, the ECU’s timer expires, and it jumps back to the default session. The tester would now have to repeat the change session command to get the ECU back to Extended Diagnostics. Any active UDS services that aren’t allowed to run in default session must now be inhibited.
Conclusion
UDS session control is a powerful tool that we can use to group UDS services together and to gate ECU functionality on. ECU functions and UDS services can be selectively turned on or off depending on which session it is in, and any logic can be performed in the ECU to determine if its allowed to enter a session. With this we ensure the safe operation of our ECU.
Shayan Mukhtar 
Leave a Reply