Request routing
DCM depends on PduR to connect diagnostic communication with the configured DCM endpoints. A request that never reaches DCM must be investigated differently from one that reaches service processing and fails there.
Vehicle Diagnostics
DCM Debugging Guide
A practical engineering model for diagnosing failures in the Diagnostic Communication Manager, from request routing and session handling to DID data and diagnostic event integration.
Engineering model
How DCM fits together
The Diagnostic Communication Manager (DCM) governs how an ECU receives diagnostic requests, validates their context, executes supported behavior, and produces positive or negative responses. Its behavior depends on configuration, UDS service handling, PduR integration, application data providers, and interaction with the Diagnostic Event Manager (DEM). Effective debugging separates transport and routing problems from DCM state, configuration, callback, and data-validity problems.
Core concepts
The parts of a practical DCM setup
Diagnostic session state
The active diagnostic session controls which diagnostic behavior is available and how requests are interpreted. Session entry, persistence, and transition conditions must be checked as stateful behavior rather than as isolated requests.
Service and data handling
UDS service processing connects request parameters to configured DIDs, routine control behavior, security access handling, and response construction. A valid request can still fail because the configured data source or application callback is incomplete.
Diagnostic event integration
DTC-related behavior depends on the relationship between DCM and DEM. DCM may expose diagnostic event information while DEM owns event state and trouble-code status, so a response problem may originate outside DCM service logic.
Configuration consistency
ARXML, ODX, requirements, and existing source code describe different aspects of the expected diagnostic behavior. Debugging requires checking that identifiers, permissions, lengths, session rules, and implementation agree across those inputs.
How DCM behavior is layered
Start by locating the failing boundary before changing service configuration or application code.
A diagnostic exchange can be viewed as a chain: an external request reaches the ECU communication path, PduR routes it toward DCM, DCM evaluates the request against its configured diagnostic session and service rules, service-specific logic obtains or changes data, and DCM constructs the response. DEM participates when the requested behavior concerns diagnostic events or trouble-code status. Each boundary can fail independently.
| Boundary | What to establish | Typical debugging question |
|---|---|---|
| Routing | The request reaches the configured DCM path | Is the request entering DCM, or is it stopped before service processing? |
| DCM state | The ECU is in the required diagnostic session | Did the ECU enter the expected session and remain there? |
| Service configuration | The requested service and identifier are configured consistently | Does DCM recognize the request, identifier, length, and access conditions? |
| Application or DEM integration | The configured callback or diagnostic data provider returns usable data | Is the failure in DCM decision logic or in the provider of the requested result? |
| Response construction | The response matches the configured data and status | Is the response absent, negative, truncated, or structurally inconsistent? |
Inputs and expected behavior
Use the available engineering artifacts to define one consistent diagnostic contract before tracing execution.
Requirements describe intended behavior, ODX describes diagnostic data and service expectations, ARXML describes AUTOSAR configuration, and existing source code shows what the integrated implementation actually does. None of these artifacts alone proves runtime behavior. Compare them for the same diagnostic session, DID, routine control path, security access condition, or DTC-related request.
- 01
Select one failing request
Record the request purpose, active diagnostic session, identifier or service context, expected response, and observed result. Keep the first investigation narrow.
- 02
Trace the configured identity
Follow the relevant identifier or service from ODX and requirements into ARXML and then into existing source code. Check spelling, values, lengths, permissions, and associated implementation points.
- 03
Separate configured from implemented behavior
Mark each expected action as configuration, DCM logic, application callback, PduR routing, or DEM behavior. This prevents a missing implementation from being treated as a routing defect.
- 04
Define an observable checkpoint
Choose a point such as request arrival, session transition, callback invocation, DEM result retrieval, or response construction. Use it to determine whether the next layer was reached.
- Treat ODX and ARXML as related but distinct artifacts: one describes diagnostic data expectations, while the other represents AUTOSAR configuration.
- Check requirements against both the configured behavior and the implementation rather than assuming either artifact is authoritative at runtime.
- Preserve the exact failing request and response evidence so later configuration changes can be compared against the original behavior.
Debugging a failed UDS request
A request failure is easiest to diagnose by classifying what the ECU did, not only what the tester expected.
For a UDS request that does not complete as expected, first determine whether DCM received it, whether it rejected the request during session or access evaluation, whether service processing started, and whether a response was constructed. A missing response suggests an earlier communication, routing, or state problem, while a negative response indicates that some request evaluation path was reached. A positive response with incorrect content shifts attention toward data production or response assembly.
- 01
Confirm arrival and routing
Establish whether the request reaches the DCM path through PduR. If it does not, inspect the configured connection and routing relationship before changing service behavior.
- 02
Confirm diagnostic session
Verify that the ECU entered the session required by the request and that the session did not revert before the request was processed.
- 03
Check request recognition
Compare the requested service, DID, routine control context, or security access context with the configured definitions and expected requirements.
- 04
Trace service execution
Determine whether DCM invokes the expected implementation or data provider. For DEM-related behavior, establish whether the request reaches DEM-facing logic and what result is returned.
- 05
Inspect response construction
Compare response contents and length with ODX, requirements, and configured data definitions. Distinguish an invalid source value from an incorrectly assembled response.
Diagnostic session and security behavior
Session failures are state-machine problems: the relevant question is what state the ECU was in at each request boundary.
When a diagnostic session does not start or does not remain active, inspect the complete transition sequence rather than testing only the session request. Check the response to the transition request, the next request that depends on the new session, and any condition that may cause the ECU to leave or reject that session. Security access should be analyzed as a prerequisite relationship: determine whether the configured access state was established before a protected operation was attempted, without assuming that a successful earlier exchange remains valid indefinitely.
| Observation | Likely investigation focus | Reasoning |
|---|---|---|
| Session request has no response | Routing, request reception, or early communication handling | The session transition may not have reached DCM service evaluation. |
| Session request is rejected | Session configuration, request context, or transition conditions | DCM may be operating correctly but refusing the requested transition. |
| Session response is positive, later request is rejected | Session persistence, access state, or request-specific permissions | A positive transition does not prove every later operation is permitted. |
| Protected request fails after session entry | Security access state and configured access rules | The active session and the required access condition may be separate prerequisites. |
- Record the sequence of requests and responses, not just the final failure.
- Check whether the expected session is still active at the time of the dependent request.
- Compare configured session and access conditions with requirements and ODX expectations.
- Avoid inferring proprietary security details from a failure; focus on observable state transitions and configured prerequisites.
DID reads and returned data
A DID read can fail at recognition, permission, provider execution, length handling, or data validity.
For a DID read failure, first separate identifier recognition from data retrieval. DCM may reject an unknown or inaccessible DID before invoking its data provider. If the provider is invoked, inspect whether it returns the expected status, supplies the configured number of bytes, and obtains data from the intended application source. A positive response is not sufficient evidence that the value is correct; validate representation, length, update timing, and consistency with the requirement.
- 01
Verify the DID definition
Compare the DID value, access conditions, expected length, and diagnostic description across ODX, ARXML, requirements, and existing source code.
- 02
Verify session and access prerequisites
Read the DID in the required diagnostic session and establish whether security access or another configured condition is required.
- 03
Confirm provider invocation
Determine whether DCM calls the implementation responsible for the DID. If not, keep the investigation in recognition, permission, or configuration.
- 04
Check provider result
Inspect status handling, returned length, and the source value. Do not treat uninitialized, stale, or default data as a valid diagnostic result.
- 05
Compare encoded response with the contract
Check that the response contains the expected value and exact data length defined by the diagnostic description and requirements.
DTC and DEM interaction
DTC-related debugging requires a clear ownership boundary between DCM request handling and DEM event state.
DCM handles the diagnostic communication path, while DEM manages diagnostic events and trouble-code status. When a DTC-related request produces an unexpected result, check whether DCM received the request and asked for the intended DEM information, then inspect the event state and result supplied by DEM. Do not correct DCM response logic to compensate for an event state that is wrong at its source.
- Confirm that the requested diagnostic operation is configured to use the intended DEM-facing behavior.
- Check the mapping between the diagnostic representation and the DEM event or trouble-code state.
- Distinguish an empty or unexpected result from a response-format defect.
- Verify that the observed event state is reproducible under the same test conditions.
- Keep DCM response assembly and DEM event ownership separate when assigning the defect.
| Symptom | DCM question | DEM question |
|---|---|---|
| DTC-related request has no response | Did DCM receive and process the request? | Was DEM queried at all? |
| Response is structurally valid but contains unexpected status | Was the DEM result copied and encoded correctly? | What event state did DEM provide? |
| Only one event is missing | Is the configured mapping present? | Is the event configured and reporting the expected state? |
A repeatable DCM debugging workflow
Use a staged workflow that narrows the fault without changing several layers at once.
- 01
Reproduce with a minimal sequence
Use the smallest request sequence that demonstrates the failure, including only the session or security access steps required by the expected behavior.
- 02
Classify the observable result
Label the outcome as no response, negative response, unexpected positive response, invalid data, or incorrect diagnostic state.
- 03
Trace the earliest missing checkpoint
Check routing, DCM reception, session evaluation, service dispatch, provider invocation, DEM interaction, and response construction in that order.
- 04
Compare artifacts
Use requirements, ODX, ARXML, and existing source code to identify the first disagreement in identifier, length, permission, state, or implementation.
- 05
Change one boundary at a time
Make the smallest corrective change in the layer that owns the defect, then rerun the same request sequence.
- 06
Add regression coverage
Capture the expected request, session context, response result, and data assertions in an automated test suite where the behavior can be exercised repeatedly.
The workflow is deliberately conservative. It avoids treating a changed response as proof of a root cause and preserves evidence for defects that reappear after integration changes.
Engineering pitfalls
Common mistakes
Debugging the service before proving routing
Engineers sometimes change DCM service configuration when the request never reaches DCM. First establish the PduR and communication path to the DCM entry point.
Treating a session request as a stateless operation
A positive session response does not prove that the session remains active for subsequent requests. Debug the complete request sequence and session state at each boundary.
Assuming a configured DID is implemented
An identifier can exist in ODX or ARXML while its provider is missing, returns the wrong length, or supplies invalid data. Confirm provider invocation and result handling.
Blaming DCM for DEM-owned state
Unexpected DTC status may originate in DEM event state or mapping. Separate DCM request and response handling from DEM event ownership.
Changing multiple layers before retesting
Simultaneous changes to configuration, source code, and integration make the first defect difficult to identify. Change one ownership boundary and repeat the same evidence-based test.
Using a positive response as the only assertion
A positive response can contain stale, default, incorrectly sized, or otherwise invalid data. Assert response structure and diagnostic content as well as status.
FAQ
DCM questions
- What should be checked first when a UDS request fails?
- First determine whether the request reaches DCM through PduR. Then check the active diagnostic session, request recognition, service execution, provider or DEM interaction, and response construction in that order.
- How can a DID read be separated into configuration and implementation problems?
- Compare the DID identity, access conditions, and expected length across ODX, ARXML, requirements, and existing source code. Then establish whether DCM invokes the provider and whether the provider returns the expected status, length, and value.
- Why can a diagnostic session appear to work and then fail?
- The transition request may succeed while the session later changes, expires, or does not satisfy the conditions of the dependent request. Record the complete sequence and verify session state when each request is processed.
- Is every negative response evidence of a DCM defect?
- No. A negative response may be the configured result of an unsuitable session, access state, identifier, or diagnostic condition. The relevant question is whether the response matches the configured and required behavior.
- How should DCM and DEM be divided during debugging?
- Check DCM for request recognition, service processing, DEM interaction, and response encoding. Check DEM for event ownership, event state, trouble-code status, and the result returned to DCM.
Engineering support
Discuss a DCM Project
Need focused DCM investigation or repeatable diagnostic tests? Get engineering support for configuration analysis, integration debugging, and automated test development.