Incorrect or mismatched DBC signal definition
The selected DBC may describe a different message, signal location, encoding, or scaling than the software and bus recording. The raw CAN frame can therefore be valid while the decoded value is wrong.
CAN troubleshooting
Incorrect CAN signal value
A decoded CAN signal is implausible or does not match the vehicle state, even though the expected frame is present. This workflow helps establish whether the fault is in the recording, DBC interpretation, signal producer, AUTOSAR COM path, or network gateway.
Start the diagnostic workflowObservable symptoms
What the failure can look like
Decoded value disagrees with the vehicle state
A signal shown by CANoe, CANalyzer, or another analysis workflow does not match the observed system condition, while the corresponding CAN frame is present in the recording or CAN dump.
Raw payload appears stable but the decoded value is implausible
The same payload bytes recur, but the interpreted engineering value is fixed, out of range, or changes in a way that does not match the problem description. Re-decoding the same frame with the intended DBC helps distinguish a definition error from changing bus data.
Different tools report different signal values
CANoe, CANalyzer, or a Python workflow produces different values from the same recording. Reproducing the result from the identical CAN frame and DBC helps separate tool configuration or decoding differences from the captured data.
The value is correct in one network path but incorrect after a gateway
A signal matches the expected state on one side of a network gateway but not on the other side, indicating that the producer data and the forwarded or mapped data need to be compared independently.
Possible causes
Boundaries worth checking first
Wrong CAN or CAN-FD interpretation
A frame captured or interpreted with the wrong bus configuration can lead to an incorrect payload or message interpretation, especially when the expected traffic uses CAN-FD characteristics. This must be separated from a signal-definition problem.
The signal producer transmits incorrect data
If the raw signal bits are already wrong relative to the vehicle state, the transmitting software or its source data may be incorrect. Decoding changes will not correct a value that is wrong at the sender.
AUTOSAR COM signal configuration does not match the intended definition
A mismatch in the COM signal configuration can alter which signal data is placed in or read from a CAN message, producing a plausible but incorrect value even when the bus frame is transmitted normally.
Network gateway mapping or forwarding changes the value
A network gateway can forward a signal with a different mapping or configured interpretation. Comparing the source and destination frames is needed before assigning the fault to the producer or decoder.
The analysis workflow uses stale or inconsistent data
A recording, CAN dump, DBC, and problem description may refer to different software or vehicle states. That mismatch can make a correct frame appear incorrect when the evidence sets are not aligned.
Ordered investigation
Diagnostic workflow
- 01
Define the mismatch and select one reproducible observation
Record the expected value, observed value, vehicle state, relevant message, and reproduction conditions from the problem description. This establishes the exact comparison before changing decoding or network configuration.
- 02
Verify that the expected frame is actually present
Locate the relevant CAN message in the CAN dump, BLF recording, or ASC recording and confirm that it occurs during the reported condition. This rules out a missing-message problem and prevents analysis of an unrelated frame.
- 03
Compare raw payload data with the active DBC definition
Inspect the raw frame and decode it with the DBC used for the reported result. Check the message identity, signal location, encoding, and scaling against the captured payload. This narrows the issue to definition or data before investigating software behavior.
- 04
Reproduce the decode independently
Decode the same frame and DBC through a second analysis path, such as CANalyzer compared with CANoe or a Python workflow. Agreement rules out many presentation and workflow differences; disagreement identifies a configuration or implementation difference to inspect.
- 05
Compare the signal at producer and gateway boundaries
When the signal crosses a network gateway, compare the source and destination CAN messages during the same vehicle state. If the source is correct and the destination is wrong, focus on gateway mapping; if both are wrong, continue toward the producer or COM configuration.
- 06
Inspect the transmitting software path
If the raw signal bits are incorrect at the source, compare the intended value with the data supplied to AUTOSAR COM and the resulting CAN message. This separates a software or COM data problem from a DBC decoding problem without assuming a specific ECU implementation.
- 07
Validate the bus configuration and repeat the capture
If the payload or message interpretation remains uncertain, verify whether the traffic is CAN or CAN-FD and repeat the least-invasive recording with the intended configuration. This rules out capture and bus-interpretation errors but does not by itself prove the signal producer is correct.
Verification gates
Technical checks
Confirm message presence and repetition
Search the BLF recording, ASC recording, or CAN dump for the expected message during the reported vehicle state and compare its successive payloads.
Expected
The expected message is present during the condition, with payload changes that correspond to the observed state or with a stable payload when the state is stable.
If failed
An absent message points toward a missing-message or capture-scope issue rather than an incorrect decoded signal value; inspect the recording conditions and message source.
Compare the active DBC with the captured message
Read the message and signal definition used for decoding and compare its identity, signal layout, encoding, and scaling with the raw CAN frame under investigation.
Expected
The DBC definition matches the captured message and produces a value consistent with the problem description.
If failed
A mismatch points to the wrong DBC, an outdated definition, or a decoding configuration error; obtain the applicable DBC and repeat the decode.
Repeat the decode from identical evidence
Use the same recording, raw frame, and DBC in CANoe, CANalyzer, or a Python analysis workflow and compare the resulting signal value.
Expected
Independent decoding paths produce the same value from the same evidence.
If failed
Different results indicate a tool, script, or configuration difference; preserve the inputs and compare the decoding steps before changing the vehicle software.
Compare source and destination gateway traffic
For a signal crossing a network gateway, compare the raw source message and destination message during the same vehicle state, including their signal values after applying the applicable DBC definitions.
Expected
The destination value preserves the intended source value according to the configured mapping.
If failed
A correct source with an incorrect destination points toward gateway mapping or forwarding configuration; incorrect values on both sides require investigation of the producer or source definition.
Check CAN versus CAN-FD interpretation
Confirm that the recording and analysis configuration matches the bus traffic type and that the relevant message is interpreted with the intended CAN or CAN-FD configuration.
Expected
The message is captured and decoded consistently under the intended bus configuration.
If failed
An inconsistency points toward capture or bus-configuration errors; repeat the recording with the correct configuration before assigning the fault to the signal definition.
Compare producer data with the transmitted signal
When the raw source signal is incorrect, compare the value intended by the transmitting software with the value placed in the CAN message through AUTOSAR COM.
Expected
The producer-side value and the transmitted signal agree for the same vehicle state.
If failed
A difference points toward the transmitting software or COM configuration; involve the responsible software or integration owner if the local evidence cannot identify the configuration change.
From evidence to action
Resolution paths
Correct the CAN database or decoding configuration
If the raw frame is valid but the interpretation is wrong, use the applicable DBC definition, correct the message or signal description, and regenerate the CAN decoding results. Preserve the original recording so the correction can be verified against identical evidence.
Align bus capture and analysis configuration
If CAN or CAN-FD interpretation is inconsistent, correct the recording and analysis setup, then repeat the capture and decode. Do not treat a corrected display value as proof that the transmitting software changed.
Correct the transmitting software or AUTOSAR COM configuration
If the source payload is wrong, align the producer data and COM signal configuration with the intended CAN message definition, then verify the transmitted value against a new recording. Changes to vehicle software may require the responsible integration or supplier team.
Correct network gateway mapping
If the source message is correct and the destination message is wrong, update the gateway mapping or forwarding configuration through the responsible vehicle-network or supplier workflow. Verify both sides after the change.
FAQ
Questions that shape the investigation
- Can a correct CAN frame still produce an incorrect signal value?
- Yes. If the DBC message, signal layout, encoding, or scaling does not match the transmitting definition, the raw frame can be valid while the decoded value is wrong.
- What should be checked first when the signal value is implausible?
- First confirm that the expected message is present during the reported condition. Then compare the raw payload with the active DBC before changing software or gateway configuration.
- How can a DBC problem be separated from a sender problem?
- Decode the same raw frame with the applicable DBC and inspect the signal bits independently of the displayed engineering value. If the raw bits are wrong at the source, the DBC alone cannot explain the failure.
- Why compare traffic on both sides of a network gateway?
- The source message may be correct while gateway mapping or forwarding produces an incorrect destination value. Boundary comparison localizes the investigation to the source path or gateway path without assuming either one is faulty.
- Does using CAN-FD explain every incorrect signal value?
- No. CAN-FD interpretation is one possible capture or message-configuration issue, but an incorrect DBC, producer value, COM configuration, or gateway mapping can create the same visible symptom.
Diagnostic support
Discuss a CAN Project
A focused engineering analysis can turn the recording, CAN dump, problem description, and DBC into verified CAN decoding results, a corrected DBC file, or a maintainable Python analysis script.