| Session | SID 0x10 Sub-func | Services Available | Typical Use |
|---|---|---|---|
| Default (DS) | 0x01 | 0x10, 0x11, 0x19 (read DTCs), 0x22 (standard DIDs), 0x3E | Normal ECU operation; no tester interaction required |
| Extended Diagnostic (EXTDS) | 0x03 | All DS services + 0x14, 0x22 (all), 0x27, 0x28, 0x2C, 0x2E, 0x2F, 0x31 | Workshop diagnostics: reading/writing parameters, IO control, routine execution |
| Programming (PRGS) | 0x02 | 0x10, 0x11, 0x27, 0x34, 0x36, 0x37, 0x31 (erase/check) | Flash reprogramming only; no application diagnostics available |
UDS Session Types
Session Transition Rules
UDS Session State Machine
┌─────────────────────────────────────────────────────┐
│ DEFAULT SESSION (DS) │
│ • Active at power-on │
│ • Active after S3 timeout with no TesterPresent │
└──────────┬───────────────────────────────────────────┘
│ 0x10 0x03 (ExtendedDiagnosticSession)
▼
┌─────────────────────────────────────────────────────┐
│ EXTENDED DIAGNOSTIC SESSION (EXTDS) │
│ • TesterPresent 0x3E required every < S3 (5s) │
│ • SecurityAccess 0x27 here for Level 1 services │
└──────────┬───────────────────────────────────────────┘
│ 0x10 0x02 (ProgrammingSession)
│ (must pass SecurityAccess Level 2 first on many OEMs)
▼
┌─────────────────────────────────────────────────────┐
│ PROGRAMMING SESSION (PRGS) │
│ • Application software may be halted │
│ • Bootloader active; no normal ECU function │
│ • ECUReset 0x11 0x01 returns to Default Session │
└─────────────────────────────────────────────────────┘
Rules:
• Any session → DS: ECUReset (0x11) or S3 timeout
• DS → EXTDS: always allowed (no security needed)
• EXTDS → PRGS: OEM-specific; often requires SecurityAccess Level 2 first
• PRGS → EXTDS: not allowed directly; must go via ECUReset to DS firstSession Timing: S3 Server Timer
Csession_timing.c
/* DCM session timeout: S3Server = 5000ms (ISO 14229 default)
If no diagnostic request received within S3Server, ECU returns to Default Session */
/* AUTOSAR DCM: configured via DcmDspSessionRow in DCM ARXML
DcmDspSessionP2ServerMax = 50ms (P2: max time before first response)
DcmDspSessionP2StarServerMax = 5000ms (P2*: max time after NRC 0x78)
DcmDspSessionS3Server = 5000ms (session keep-alive timeout) */
/* Tester side: send TesterPresent every 2s to stay in session
Suppress positive response: Sub-function bit 7 = 1 → 0x3E 0x80
This sends TesterPresent without generating a response frame */
/* Example CAN frames:
TesterPresent request (suppress response): 7DF 02 3E 80 00 00 00 00
TesterPresent positive response (if bit7=0): 7E8 02 7E 00 00 00 00 00
ECUReset soft reset: 7DF 02 11 01 00 00 00 00
ECUReset hard reset: 7DF 02 11 03 00 00 00 00 (key-off / power cycle simulation)
Jump to Programming Session:
Request: 7DF 02 10 02 00 00 00 00
Response: 7E8 06 50 02 00 19 01 F4 (P2=25ms, P2*=500ms in response) */AUTOSAR DCM Session Configuration
XMLDcm_Sessions.arxml
DefaultSession
0x01
50
5000
5000
ExtendedDiagnosticSession
0x03
50
5000
5000
ProgrammingSession
0x02
50
5000
5000
Summary
Three sessions, three roles: Default (always-on, read-only diagnostics), Extended (workshop diagnostics with write access), Programming (reprogramming only, application suspended). The S3 server timer of 5000 ms is the session watchdog — TesterPresent with suppressed response (0x3E 0x80) is the tester's keep-alive mechanism at ≤2 s intervals. Session transitions in AUTOSAR are enforced by the DCM state machine; attempting a service in the wrong session returns NRC 0x25 (requestedActionNotAllowedInCurrentSession).
🔬 Deep Dive — Core Concepts Expanded
This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.
Key principles to reinforce:
- Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
- Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
- Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.
🏭 How This Topic Appears in Production Projects
- Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
- Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
- Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.
⚠️ Common Mistakes and How to Avoid Them
- Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
- Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
- Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
- Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.
📊 Industry Note
Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.