Technical Articles & Engineering Insights
OBC DBC Files and CAN Matrices: What to Expect Inside
A DBC file is a signal dictionary, not a communication spec. What a charger DBC should contain, what it never describes, and how to validate it before the sample arrives.
Three documents arrive in a normal charger integration package, and they are routinely confused with each other:
• a pin definition table, which says what each wire does;
• a CAN matrix, usually a spreadsheet, which says what each message and signal means;
• a DBC file, which encodes that matrix in a format a CAN tool can read.
Only the third one can be loaded into a test bench and used. Only the second one is readable by a human without tooling. Neither is a specification of how the charger behaves, and that gap is where most integration schedules are lost.
What the DBC File Can and Cannot Tell You
A DBC file answers one question precisely: given these bytes on the bus, what number does this signal represent?
It contains, for each signal: the message it belongs to, its start bit, its length, its byte order, its scaling factor and offset, its minimum and maximum, its unit, and its receivers. That is a complete answer to the decoding question.
It contains nothing about:
• when a message is sent, beyond a nominal cycle time;
• what happens when a message stops arriving;
• which state the charger must be in to accept a command;
• who is allowed to send a charge request in the first place;
• what a fault code means in terms of operator action.
A team that receives a DBC file and treats it as the interface definition will build a vehicle controller against a dictionary and discover that nobody wrote the grammar.
The Signal Set a Charger Interface Usually Needs
Message naming and IDs are assigned per program - no supplier can hand you a universal set - but the functional content is fairly stable. If a matrix is missing one of these groups, the interface is incomplete regardless of how tidy the spreadsheet looks.
Group | Typical signals | Direction |
Charge control | Charge enable request, target voltage, current limit | VCU or BMS → charger |
Charger status | State (standby, handshake, charging, fault, done), actual output voltage, actual output current | Charger → VCU |
Limits and derating | Available power, derating reason, input voltage present | Charger → VCU |
Fault reporting | Fault code or fault bitfield, severity, resettable flag | Charger → VCU |
Liveness | Heartbeat or rolling counter, message counter | Both directions |
Two groups are commonly under-specified, and both cause field problems rather than bench problems.
Derating reason. A charger that reports "available power: 1.8 kW" without saying why is undiagnosable. High ambient, input voltage sag, connector temperature, battery limit - each of those leads to a different fix, and only one of them is the charger's problem.
Liveness. A rolling counter or checksum on command messages protects against a controller that has hung while still transmitting a plausible stale frame. Without it, a frozen VCU can hold a charge request indefinitely and nothing in the system notices.
Scaling, Sign, and Byte Order
These three fields account for a large share of "the charger ignores my command" reports, and all three are visible in the DBC before any hardware exists.
Scaling. A voltage request defined as 1 V per bit on one side and 0.1 V per bit on the other produces a charger that reads either 0 V or a number far outside its range. Neither side is malfunctioning; they disagree.
Sign. A current limit that should be signed and is declared unsigned turns a regeneration request of −10 A into 65526. The charger, correctly refusing an impossible current, declines to charge. On the bench this looks like a dead unit.
Byte order. Multi-byte signals declared Motorola (big-endian) on one side and Intel (little-endian) on the other produce values that look plausible at low magnitude and become erratic at high state of charge - which is exactly when nobody is watching a laptop.
Check all three in the file, not in the hardware. A DBC can be diffed in seconds; a mis-scaled signal in a running vehicle can take a week to find.
Bitrate, Termination, and Sample Point
The physical layer is not in the DBC either, and it fails more often than the decoding does.
• Bitrate. 250 kbit/s and 500 kbit/s are both common in light vehicle platforms. A mismatch gives you a bus that reports errors and no communication at all - the easy case. The hard case is a marginal bus that works on the bench and drops frames in the vehicle.
• Termination. Two 120 Ω terminators, one at each physical end. A third node added to a stub, or a terminator left off a short harness, produces reflections that only show up at length.
• Sample point and topology. At 500 kbit/s with a long harness, sample point location matters. Ask whether the charger's transceiver was validated on a bus of similar length and node count, not on a 1 m bench cable.
Where Do You Validate It, and When
The useful moment to validate a DBC is before the sample ships, using a restbus simulation.
Load the DBC into a CAN tool - Vector CANoe, a PCAN or Kvaser interface with a scripting layer, or an open-source stack - and simulate the charger's side of the conversation. Then point your own VCU at it. What you are testing is your controller's logic, against the file the supplier says is correct:
• Does your VCU send the enable frame at the right moment in its own start-up sequence?
• Does it scale the current limit correctly at the extremes, not just at nominal?
• Does it handle the charger's state transitions, including the one where charging ends because the battery is full?
• What does it do when you stop the charger's heartbeat - hold, retry, or fault?
This runs on a desk with no charger present. Every question it answers is one you would otherwise answer with a prototype in a cold workshop.
A second, cheaper check: convert the DBC back to a human-readable listing and read the whole thing once. Files assembled by hand across two organizations routinely contain a signal with the wrong receiver, a duplicated signal name, or a message with no sender. None of these appear as errors when loaded.
Version Control Is Not Optional
Put the DBC in the same repository as your vehicle controller code, name it with the revision, and treat a change to it as a code change that needs review. The PDF attached to an email thread is not a specification, and by the third build the version on the bench is rarely the version in the vehicle.
Ask the supplier for the revision letter in the file name and confirm it in writing when you receive it. A program that cannot say which DBC revision a given vehicle was built against cannot debug a communication fault that appears in the field six months later.
If the Supplier Only Sends a PDF Matrix
This is common and it is workable. What you need from the PDF, minimally, to build a usable DBC yourself:
• Message identifier, name, length in bytes, sender, and nominal cycle time.
• For each signal: start bit, length, byte order, factor, offset, minimum, maximum, unit, and receivers.
• The bit numbering convention used (the most common source of an off-by-one that moves an entire signal).
Ask for the spreadsheet rather than the PDF if it exists - a PDF loses the bit numbering convention and the exact spelling of signal names, and reconstructing forty signals by hand is a day of work that produces a file nobody trusts.
Then send your reconstructed file back to the supplier and ask them to confirm it. A supplier who reviews it has a firmware team that understands the interface; one who ignores the request has told you something useful before the purchase order.
What to Send the Supplier
The interface is a two-way document, and the fastest way to get a good one is to contribute half of it:
• your vehicle's CAN bitrate, topology, and the node that will own charge enable;
• the voltage and current window your battery will accept, including the taper behaviour near full;
• your VCU's start-up and shutdown sequence, with the timing of each state;
• whether your software stack expects a specific higher-layer protocol. Where an OEM stack is AUTOSAR-based and expects diagnostics over UDS, say so at enquiry - the 6.6 kW dual-input charger supports both, but a platform built around a plain CAN 2.0 message set is a different conversation;
• the fault states your vehicle can display, so the mapping has somewhere to go.
For who is allowed to command what, and how a hardware enable interacts with a CAN enable, see OBC and DC-DC enable pin requirements. For the checklist of items to confirm before integration, see what to confirm before integrating an OBC with CAN. This article covers the artefact itself - the file, its contents, and how to prove it before hardware arrives.
Frequently Asked Questions
Is a DBC file enough to integrate a charger?
No. It defines how signals decode, not how the system behaves. You need the communication specification or interface control document alongside it for state machine, timing, timeout and fault handling. The DBC is the part you can automate; the document is the part you have to read.
Can I generate a DBC from the supplier's spreadsheet?
Yes, and it is often the fastest route. A matrix with bit positions, lengths, factors and offsets contains everything the format needs. The risk is the bit numbering convention, so confirm one message by hand against the charger's own documentation before generating the rest.
The charger's CAN works on the bench but not in the vehicle. Where do I look first?
Bitrate and termination, then bus length, then the timeout configuration. Decoding errors usually appear as wrong values rather than silence; a bus that goes quiet in the vehicle and worked on the bench is almost always physical layer or a node that never woke up.
Conclusion
A DBC file settles decoding and nothing else. Read it as a dictionary, demand the state machine and timeout behaviour separately, check scaling, sign and byte order before hardware exists, and simulate the charger on a desk so that your own controller logic is proven before a prototype is built around it.
Integrating a charger into a vehicle network? Our platforms - including the 3.3 kW OBC on 72 V and 96 V, the 6.6 kW standalone charger and the 2 kW OBC with 1 kW DC-DC - ship with CAN 2.0 communication and program-specific matrix documentation. Send your bitrate, node list and expected signal set to our engineering team for a review before the purchase order.
About Echelon Charger
Echelon Energy Technology specializes in onboard chargers, DC/DC converters, and integrated EV power solutions for commercial and specialty electric vehicles.
For technical discussions, product selection, or OEM/ODM cooperation:
✉️ Email: nancy@tici-energy.com 💬 WhatsApp: +86 18114665311
For CAN matrix, DBC files, pin definition tables and interface control documents, use our contact page.
