Vehicle Networks & Communication
Trace AUTOSAR COM behavior from software component interfaces to CAN communication, separating signal interpretation, configuration, routing, and system integration faults.
Engineering model
AUTOSAR COM provides signal-oriented communication services between software components and lower communication layers. Debugging therefore requires tracing the same signal through the RTE, COM configuration, PDU Router, and CAN, while checking the ARXML, DBC, and requirements against observed behavior. The key question is whether the defect is in the software value, the configured communication path, the CAN representation, or a network gateway transformation.
Core concepts
COM transports signal values, but the producing software component, the RTE interface, the COM configuration, and the DBC each describe different parts of the path. A useful investigation keeps the application value separate from its encoded CAN representation.
PduR connects upper and lower communication layers. Its configured route determines whether a PDU can leave or enter the expected path, making it central when a signal is correct in software but absent or incorrect on CAN.
ARXML, DBC, and requirements provide related but non-identical views of communication behavior. Debugging depends on checking identifiers, signal definitions, direction, and expected behavior across these inputs rather than trusting one artifact in isolation.
A network gateway can receive communication on one CAN network and transmit it on another, potentially routing or modifying messages. A gateway investigation must compare the source message, the configured route, and the destination message.
Start with the complete path rather than with the first implausible value seen on CAN.
Use the requirements to state which software component produces or consumes the signal, the expected value, and the intended CAN communication behavior.
Use the RTE model to identify the application-facing interface and determine whether the observed value is already incorrect before COM processing.
Confirm that the signal belongs to the intended communication structure and that its configured direction and association match the intended behavior.
Check that PduR connects the relevant upper and lower communication layers and that the route leads to the expected CAN path.
Use the DBC to decode the transmitted message and compare the decoded signal with the software-side value and the requirement.
The same visible symptom can result from an incorrect value, a missing route, or a mismatch between communication descriptions.
| Observation | Likely investigation focus | Reasoning |
|---|---|---|
| The software-side value is already implausible | RTE interface and producing software component | The communication stack may be transporting an input that was incorrect before COM processing. |
| The software-side value is correct but CAN is incorrect | COM configuration and DBC interpretation | The value may be associated with the wrong communication definition or represented differently than expected. |
| The signal is absent from CAN | PduR route and lower communication path | A missing or incorrect route can prevent the expected PDU from reaching CAN. |
| The source CAN message is correct but the destination is wrong | Network gateway route and gateway transformation | The fault may be between the source and destination CAN networks rather than in the original signal producer. |
Treat each observation as evidence about a boundary. A mismatch appearing for the first time between two boundaries narrows the investigation; a mismatch already present at the first boundary points toward the producing side or its requirement interpretation.
Configuration defects often arise because related artifacts describe the same communication behavior with different identifiers or assumptions.
An implausible or unexpected decoded value should be reduced to a comparison between the requirement, software value, configured communication, and DBC result.
Capture the expected value from the requirements, the value at the software-facing interface, and the value decoded from CAN.
Determine whether the RTE-facing value already differs from the requirement or system state.
Verify that the software signal is connected to the intended communication definition and not to a different configured signal or PDU.
Revisit the DBC message and signal definition used to decode the observed CAN communication.
Test a condition with a known expected value and compare all available observations again, recording whether the discrepancy moves or remains at the same boundary.
Avoid correcting the DBC merely because the decoded value looks wrong. First establish whether the DBC disagrees with the requirements and ARXML, or whether the implementation is producing a value that the DBC is correctly decoding.
Gateway issues require separate checks for reception, routing, transformation, and transmission on the destination CAN network.
| Gateway observation | What it establishes | What remains unproven |
|---|---|---|
| Source message is absent | The fault is upstream of destination transmission | Whether the gateway route itself is configured correctly |
| Source message is present; destination message is absent | The issue is after source reception or before destination transmission | Whether the source and destination definitions are compatible |
| Destination message is present with an unexpected value | The destination path is active | Whether the gateway or the destination decoding caused the discrepancy |
| Destination message matches the expected value | The observed path behaved correctly for that test condition | Whether other conditions or signals have the same behavior |
A compact evidence record prevents configuration changes from obscuring the original failure and makes integration support more useful.
List the ARXML, DBC, and requirements versions or revisions used for the investigation.
Capture the relevant RTE-facing value, COM observation, PduR route result, source CAN message, and destination CAN message when a gateway is involved.
Identify the earliest boundary where observed behavior diverges from the expected behavior.
When configuring or implementing a correction, keep the test condition and comparison points stable.
Confirm whether the same incorrect CAN signal value or CAN gateway issue remains, and note any new discrepancy separately.
This record supports both debugging and integration support because it distinguishes an observed failure from an unverified assumption about the communication path.
A correction is credible only when the complete path behaves as required, not merely when one observation looks plausible.
Engineering pitfalls
A CAN trace shows the network representation, not necessarily the value at the RTE or COM boundary. Trace the value backward before changing the DBC or CAN-facing configuration.
ARXML models AUTOSAR configuration and DBC defines CAN messages and signals. Compare their intended relationships; do not assume one artifact validates the other automatically.
An absent signal may indicate a PduR or gateway path problem rather than an incorrect application value. First establish whether the expected PDU was transmitted at all.
A matching name does not prove that source and destination CAN definitions, communication direction, or gateway behavior are equivalent.
Multiple simultaneous changes remove the boundary evidence needed to locate the first mismatch. Isolate changes and retest the original condition.
A correct value under one condition does not prove that the complete COM path or gateway route is correct. Repeat the comparison against the stated requirements.
FAQ
Engineering support
Need focused COM debugging support? Get help tracing signal paths, reviewing ARXML and DBC consistency, and isolating CAN integration faults.