AUTOSAR & Automotive Platform Software
A practical engineering model for locating defects across ARXML, RTE, BSW, MCAL, communication modules, diagnostics, and integrated ECU behavior.
Engineering model
Classic AUTOSAR debugging is the process of separating configuration, interface, implementation, and integration faults across a statically configured ECU software stack. The visible symptom may appear in an application interface, communication path, or diagnostic response while the cause resides in ARXML consistency, RTE mapping, BSW configuration, MCAL behavior, or an incorrectly connected module. Effective investigation follows the data and control path from the observed behavior through each configured boundary rather than treating the first failing module as the root cause.
Core concepts
ARXML and generated configuration define many of the connections, identifiers, directions, and parameters that determine how Classic AUTOSAR behaves. A debugging investigation therefore checks model consistency before assuming that source code is defective.
RTE, BSW, and MCAL divide responsibility across application-facing interfaces, middleware services, and microcontroller peripherals. Identifying which layer owns each transition prevents changes in one layer from masking a defect in another.
A signal or diagnostic message must remain consistently connected as it crosses COM, PduR, CanTp, and lower communication boundaries. Matching identifiers, directions, and transport expectations is central to isolating communication failures.
DCM handles diagnostic communication while DEM manages diagnostic events and trouble-code status. A diagnostic symptom can therefore result from a communication path problem, an event-state problem, or an incorrect connection between the two responsibilities.
Debugging becomes repeatable when the engineer states the expected behavior, identifies the first boundary where it differs, and tests one dependency at a time. This approach distinguishes configuration defects from implementation and integration defects.
Start by translating the symptom into a path through the Classic AUTOSAR architecture.
Describe the observed behavior in terms of an input, an expected transition, and an actual result. Then identify the narrowest path that should carry that behavior. For a software-component interaction, this commonly begins at the RTE. For a signal-oriented communication issue, follow the configured path through COM and PduR. For segmented communication, include CanTp. For a diagnostic issue, separate the DCM communication path from DEM event handling.
Record the expected interface, direction, value or request, response, and relevant operating condition without assuming which module is at fault.
Map the behavior across ARXML-defined interfaces and the involved RTE, BSW, or MCAL responsibilities.
Determine the earliest boundary where the actual behavior differs from the expected behavior; later symptoms may only be consequences.
Change or inspect a single configuration, interface, or implementation assumption before drawing a conclusion about the complete path.
Many Classic AUTOSAR defects are consistency problems between exchanged models, configured parameters, and existing source code.
Treat ARXML as an engineering input to review, not merely as a file passed through a generation step. Compare the relevant interfaces, directions, identifiers, references, and module relationships against the requirements and interface specification. Then verify that the generated configuration and existing source code use the same assumptions. A source-level investigation can be misleading when the generated connections do not represent the intended model.
Communication debugging is most effective when each layer is checked for the same message intent and boundary contract.
| Layer | Primary responsibility | Debugging question |
|---|---|---|
| COM | Signal-oriented communication services | Are the intended signals associated with the expected communication object and direction? |
| PduR | Routing between upper and lower communication layers | Does the configured route connect the intended source and destination without a mismatched reference? |
| CanTp | Segmented communication over CAN | Do the transport expectations match the message path and the observed request or response behavior? |
| MCAL | Abstraction of microcontroller peripherals | Does the lowest configured software boundary expose the expected peripheral behavior to the upper layers? |
When a communication path fails, begin with the first layer whose expected handoff is absent or incorrect. Do not infer that PduR is defective simply because an upper-layer message is missing; an incorrect COM association can prevent the expected route from ever being selected. Likewise, a transport symptom should be analyzed against CanTp expectations before changing unrelated signal configuration.
Diagnostic investigations need two parallel questions: can the diagnostic communication path process the interaction, and is the underlying event state correct?
DCM is responsible for diagnostic communication, while DEM manages diagnostic events and trouble-code status. A request that does not receive the expected response may indicate a DCM path or configuration issue. A response that reports an unexpected event state may instead require examination of DEM event handling and its configured relationships. Treat these as related but distinct investigations until evidence connects them.
Decide whether the failure concerns diagnostic communication itself, event status, or the relationship between the diagnostic result and an event.
Review the configured diagnostic interface, request handling expectations, and response behavior without assuming a particular unsupported service or response code.
Verify that the intended event is defined, connected, and updated according to the requirements and existing implementation.
Determine whether DCM is exposing an incorrect DEM state or whether the diagnostic interaction fails before event information can be evaluated.
Layer ownership provides a disciplined way to choose the next inspection point without prematurely changing lower-level software.
The same symptom can cross several layers. For example, an absent value at an application-facing boundary does not by itself establish an RTE defect; the producing path may be misconfigured or an underlying BSW or MCAL boundary may not provide the expected input. Record the first failed contract and preserve the evidence that rules out earlier boundaries.
Use a controlled sequence that reduces the risk of correcting a downstream symptom while leaving the actual defect unchanged.
Write the expected and actual behavior using the relevant interface, message, event, or diagnostic interaction.
Use the applicable requirements, interface specification, ARXML, and existing source code as the reference set.
Place the involved RTE, BSW modules, communication modules, diagnostic modules, and MCAL boundary in their expected order.
Compare names, identifiers, directions, references, and parameter assumptions across the path.
Use observations at each boundary to determine where the expected behavior stops being preserved.
Change the artifact that owns the failed contract, then reassess the complete path rather than only the original symptom.
Record the evidence, rejected hypotheses, changed configuration or source code, and remaining uncertainty in engineering documentation.
This workflow is intentionally conservative. In a statically configured system, a local change can affect generated interfaces or routing assumptions elsewhere, so the final check should include all connected boundaries rather than only the edited module.
A debugging result is more useful when another engineer can reproduce the reasoning from the same artifacts.
| Evidence category | What to record | Why it matters |
|---|---|---|
| Requirement | Expected behavior and operating condition | Defines what correctness means before implementation details influence the conclusion. |
| Interface specification | Names, directions, message or API expectations, and participating components | Provides the contract used to compare ARXML and source code. |
| ARXML | Relevant model elements, references, and configured relationships | Shows whether the intended architecture is represented in the exchanged model. |
| Existing source code | Implementation branch, ownership, and assumptions at the first failed boundary | Helps distinguish an implementation defect from a configuration mismatch. |
| Integration result | Observed behavior after the correction and remaining limitations | Prevents a local fix from being mistaken for proof that every connected path is correct. |
Keep conclusions proportional to the evidence. A confirmed mismatch at one interface supports a specific correction, but it does not establish that all related modules are correct. Mark unresolved dependencies explicitly so later testing and integration work can target them.
Engineering pitfalls
An error observed through DCM, COM, or the RTE does not prove that module owns the defect. Trace backward to the first failed contract and inspect configuration and upstream inputs.
ARXML can be structurally acceptable while expressing the wrong connection, direction, or identifier. Review the model against requirements and the interface specification.
Simultaneous edits to RTE, BSW, and MCAL remove the evidence needed to identify which assumption was wrong. Make the smallest justified change and reassess the path.
DCM communication behavior and DEM event status have different responsibilities. Analyze whether the interaction failed or whether the returned event state is incorrect.
Individually plausible artifacts can still disagree at their interfaces. Compare references, directions, and ownership across the complete configured path.
A missing value or unexpected diagnostic result may be a downstream effect of an earlier routing or configuration defect. Locate the earliest divergence before modifying implementation code.
FAQ
Engineering support
Use focused engineering support to investigate Classic AUTOSAR configuration, integration, and debugging issues across firmware modules and engineering documentation.