Accessing diagnostic session control (uds service 0x10)

The service 10 (0x10) or Diagnostic Session Control (DSC) is a Unified Diagnostic Session (UDS) service for controlling the Diagnostic Session of the ECUs or control modules within the car. This service is used to change from a current diagnostic session to a different one in an ECU.

Different diagnostic sessions can be configured in the ECU, but the four (4) main sessions, or subfunctions, of the Service ID 10 are:

• When the car is running and no specific diagnostic communication is happening outside the ECU, then we are in default session 0x01.
• When a flashing tool is connected and a new program is being flashed into the ECU, we are in programming mode 0x02.
• When a tester or tool is connected and there are some extra functionalities (for instance, activation tests), we are in extended version 0x03.
• The safety session 0x04 is used to test all safety critical diagnostic functions, such as airbag deployment, braking system, etc. This session has a security access service to protect against unauthorized activation of emergency systems that could lead to damage of people or the car itself (deployment of airbags, for instance). This system works with an exchange of seed and key. No access should be possible without the algorithm to calculate the key, given a specific seed.

Transition from one session to another can occur only in a specific way, as shown in the following diagram:

This means that we can move from the default session to the programming or extended sessions, but we can’t, for instance, move from the extended session to the programming one. For this, we would need to change from the extended session to the default one first, and then move from the default session to the programming one.

We are in default session and want to move to the extended session:

Now, if we want to move to the programming session, we will receive a negative response and a code explaining the reason for it:

The timers P2 and P2* indicate the timeframe between the moment we send the request to a session, and the moment we get a response from the module. P2 indicates the maximum time in ms in which the ECU is supposed to send a response, whether positive, negative, or a request for more time (NRC 0x78). P2* indicates the maximum time, in total, to receive a positive response (multiplied by 10ms).

P2 is the 3rd and 4th byte in the response.

P2* is the 5th and 6th byte in the response.

Example:

Request:

• 02 indicates a single frame message, 2 bytes long.
• Request to enter Service 10.
• 03 Extended session.

Response:

• 06 indicates a single frame message, 6 bytes long.
• 50 is the positive response to the SID 10.
• 03 Extended session.
• Timers as shown in the table below.

This means that after the request is sent, the ECU has 50ms (P2) to send a response back, whether positive or negative. If the ECU needs more time, it will send back a RCR-RP (0x78) or Request Correctly Received-Response Pending, and another 50ms cycle will take place. This cycle will repeat until the total time reaches P2*, 5 sec. After this, we will receive a negative response with its corresponding NRC.

In some cases, the positive response does not necessarily need to show, which means that we will get into the corresponding session without seeing a direct positive response.

The negative response codes for the diagnostic control sessions can be:

To summarize, understanding the Diagnostic Session Control (DSC) service, particularly within the context of Unified Diagnostic Session (UDS) for automotive electronic control units (ECUs), is vital for effective diagnostics and maintenance of vehicles. The four primary sessions – Default, Programming, Extended, and Safety – serve distinct purposes and come with specific access conditions. The transition between these sessions follows well-defined rules and timing constraints, enforced by timers P2 and P2*. Additionally, the negative response codes (NRC) provide valuable insights into potential issues or limitations during session control.