Vehicle Networks & Communication
A practical engineering reference for building, decoding, testing, simulating, and troubleshooting CAN-FD communication.
Engineering model
CAN-FD extends CAN by allowing larger frame payloads and a faster data phase. Reliable development depends on consistent frame configuration, compatible timing, correct interpretation of the DBC, and controlled validation across participating network nodes. Analysis usually combines recorded traffic or CAN dumps with database definitions and, where available, simulation and test tooling.
Core concepts
The frame configuration determines how CAN-FD communication is interpreted, including the payload capacity and the transition between the arbitration portion and the faster data phase. A mismatch can prevent communication or produce frames that cannot be decoded reliably.
CAN-FD timing must be consistent across the communicating nodes. The separate communication phases make timing configuration especially important when integrating a faster data phase with an existing CAN network.
A DBC maps message identifiers and payload contents to signals, nodes, scaling, and metadata. It is the basis for turning captured CAN-FD frames into engineering values and for checking whether generated traffic matches the intended interface.
A network development environment can combine simulation, test execution, recording, and analysis. CANoe is one supplied example of a tool used to reproduce traffic and inspect behavior around CAN-FD communication.
Treat CAN-FD development as the alignment of communication behavior, configuration, and interpretation rather than as a frame-format task alone.
A CAN-FD exchange has several dependencies: the participating nodes must agree on the communication configuration, the bus must remain stable under the selected timing, and the receiving side must interpret the payload according to the intended message and signal definitions. A valid-looking recording does not by itself prove that the software behavior is correct; the observed traffic must also be compared with expected message presence, values, timing, and routing.
Start development by making the communication assumptions explicit and verifiable on every participating node.
The arbitration portion determines how communication is coordinated on the bus, while the data phase can operate at a higher rate. The nodes therefore need compatible settings for the relevant phases, payload handling, and frame interpretation. When settings differ, symptoms may include absent frames, error indications, unstable communication, or traffic that appears in a recording but cannot be decoded as expected.
Record which messages use CAN-FD, the expected payload size, the expected communication phases, and which nodes should transmit or receive them.
Apply compatible CAN-FD and CAN settings to the communicating nodes, then verify that the selected configuration is actually active rather than only present in a project definition.
Transmit and observe frames with the intended payload sizes and timing. Check both successful reception and behavior under bus activity representative of the target use.
Use a recording or CAN dump to compare frame presence, payload interpretation, and communication stability against the defined interface.
A DBC is useful only when its definitions match the traffic and the software behavior being investigated.
Decoding connects a captured frame to a message definition and then converts payload content into signal values using the associated layout and scaling. For CAN-FD development, confirm that the message definition represents the actual frame type and payload expectations before interpreting signal values. If the identifier or payload layout is wrong, plausible numerical values can still be misleading.
| Evidence | What to verify | Typical interpretation |
|---|---|---|
| CAN-FD frame in a recording | Frame presence, identifier, payload length, and phase-related configuration | The frame was observed, but successful observation does not prove correct signal interpretation |
| DBC message definition | Message identifier, expected payload layout, signals, nodes, and scaling | The definition provides the mapping needed for decoding and interface review |
| Decoded signal value | Raw payload position and scaling against the DBC | A value is meaningful only when the selected message definition matches the observed frame |
| Repeated message behavior | Presence, sequence, timing pattern, and value changes | The traffic can be compared with expected software behavior and missing-message symptoms |
A disciplined workflow narrows CAN-FD issues by separating absence, instability, routing, and interpretation problems.
State whether the issue is a CAN message missing, CAN bus errors, a CAN gateway issue, or a broader CAN-FD communication issue. Record the expected message, affected network, and operating condition.
Gather the relevant BLF recording, ASC recording, CAN dump, and DBC. Preserve timestamps and the original files before converting or filtering data.
Check whether the expected frame appears at all. If it is absent, investigate transmission, routing, node state, or capture scope before changing signal decoding.
Look for error indications, interruptions, or bus-off events in the available evidence. Correlate their timing with the missing or malformed traffic.
Apply the DBC to frames whose identifiers and payload expectations match the database. Compare raw and decoded data rather than relying on decoded values alone.
Use simulation or a controlled test to vary one relevant condition and observe whether the expected message, signal behavior, or routing changes.
Produce an engineering analysis or CAN decoding results that identify the evidence examined, the limits of the conclusion, and the next verification step.
Simulation is most valuable when it reproduces the specific traffic and failure condition needed to test a hypothesis.
A useful CAN-FD test setup defines the messages under test, the expected node behavior, the relevant timing and payload conditions, and the evidence that will determine pass or failure. CANoe can support development, simulation, test, and analysis activities, but the quality of the result still depends on the configuration, input data, and expected behavior defined by the engineer.
| Activity | Primary question | Useful evidence |
|---|---|---|
| Simulation | Can the relevant network behavior be reproduced under controlled conditions? | Generated and observed CAN-FD traffic with the selected configuration |
| Decode check | Does the DBC produce the intended engineering interpretation? | Raw frames, DBC definitions, and CAN decoding results |
| Integration test | Does the component exchange the expected messages with surrounding nodes? | Message presence, payload behavior, and routing observations |
| Troubleshooting analysis | Where does observed behavior diverge from the expected model? | BLF recording, ASC recording, CAN dump, and documented findings |
A network gateway can change what is visible on another network, so routing must be analyzed separately from frame generation and decoding.
When a message is missing or modified, establish whether the source node produced the expected frame, whether the network gateway forwarded it, and whether the destination side observed the intended result. A message may be present on one network and absent on another, or its payload and timing may differ after routing. The DBC should be checked for the network and node context relevant to each observation.
Confirm whether the originating message appears with the expected identifier, payload, and repetition behavior.
Compare traffic before and after the network gateway when evidence from both sides is available. Look for absence, modification, or changed timing.
Verify that the receiving network observes the expected message and that the DBC used for decoding matches that network context.
If the source is correct but the destination is not, focus on gateway behavior and network conditions before changing application signal logic.
Traceable inputs make CAN-FD findings easier to reproduce and review.
| Input | Role in the workflow | Result it supports |
|---|---|---|
| BLF recording | Timestamped bus communication for detailed observation | Engineering analysis and CAN decoding results |
| ASC recording | Text-based bus communication for inspection and comparison | Engineering analysis and traffic review |
| CAN dump | Raw or exported CAN frames for focused investigation | Frame presence checks and decoding work |
| DBC | Message, signal, node, scaling, and metadata definitions | CAN decoding results and DBC review |
Engineering pitfalls
CAN-FD also introduces a faster data phase and related configuration dependencies. A payload definition alone is not enough to establish compatibility.
If the expected frame is absent, changing signal scaling or DBC definitions cannot restore communication. First determine whether the frame reached the capture point.
A DBC describes intended message and signal interpretation; it does not prove that the observed identifier, payload, transmitter, or timing matches the intended interface.
Multiple simultaneous changes destroy diagnostic evidence. Controlled changes make it easier to distinguish timing, compatibility, routing, and software behavior.
Traffic on one network does not guarantee equivalent traffic on another. Compare source and destination observations before assigning the issue to a node or decoder.
A BLF recording, ASC recording, or CAN dump reflects the selected capture point and period. Missing context can make absence or timing conclusions uncertain.
FAQ
Engineering support
Need focused support for CAN-FD analysis, decoding, simulation, testing, or gateway troubleshooting? Share the available recordings, CAN dump, and DBC for an engineering review grounded in observable traffic.