What a DBC file is
A DBC file is a plain text description of what travels on a CAN bus. For every message it lists the identifier, the payload length, the sender, and then every signal inside that payload: name, start bit, length, byte order, scale, offset, unit, and allowed range. Tools such as CANoe, CANalyzer, Kvaser, python-can and cantools all read the same format, which is why it is the practical way to hand tire data from a supplier to a customer's engineering team.
What a DBC file is not: it is not firmware, and it is not a specification of behaviour. It describes where the bits are. It cannot tell you when an alarm fires, what happens when a sensor goes missing, or which physical wheel "position 37" is. Those belong in a companion document, and a supplier who sends only the DBC has handed you half the interface.
For a TPMS project, that distinction matters more than usual. Tire data is not one fixed frame with one meaning. It is many wheels, several conditions, and a state that changes when a sensor stops reporting.
Why TPMS DBC files look different from engine DBC files
On a powertrain bus, a signal like engine speed appears once, at a fixed position. Tire data repeats, and there is no single industry convention for how.
Three layouts are common:
- One message per wheel. Simple to read, but message count grows with the machine. Fine for four to eight wheels, awkward at 160.
- One message carrying several wheels. Efficient, and the usual choice for large machines. The tradeoff is that a single lost frame loses several wheels at once.
- Position-indexed or multiplexed messages. A selector field says which wheel group the payload describes. Compact, but it makes decoding stateful, and it is where careless integrations break.
Whichever one you receive, the DBC should say so explicitly. If the layout is multiplexed and the multiplexer signal is not modelled, your parser will read plausible but wrong pressures, which is worse than reading nothing.
What a usable TPMS DBC must contain
Check these items line by line. Each one has caused a real integration delay somewhere.
1. Message identifiers with the extended flag. CAN 2.0B allows 11-bit and 29-bit identifiers. If the DBC omits the extended attribute, some tools silently decode the wrong frames.
2. Payload length (DLC) for every message, and it should be 8 for standard frames.
3. Cycle time as an attribute, not as prose. Tooling reads the cycle time attribute; a sentence in an email does not reach the analyser. Our receivers use a 500 ms data cycle as the default, so the attribute should reflect the configured value.
4. Sender node name, so it is obvious that the receiver is the transmitter and your controller is the listener.
5. Byte order per signal. Little-endian and big-endian signals are both legal and they look identical until you decode a frame. This is the single most common cause of "your TPMS reads nonsense".
6. Scale and offset, with the raw range. Pressure in kPa and temperature in °C should be readable directly rather than with a mental multiplication.
7. Value tables for status signals. A status byte whose 0 means "normal", 1 means "low pressure", 2 means "rapid leak" and 3 means "sensor missing" is far more useful than a bare number.
8. Units on every physical signal, declared in the unit field rather than implied by the name.
If those eight are present, the file is mechanically usable. Whether it is useful is a different question.
What is usually missing
The gaps are predictable, and they are the reason DBC review is worth twenty minutes of your time.
Alarm semantics. A DBC can carry a flag; it cannot say what the thresholds are or how to change them. Ask for a written table of flags, thresholds and default values, and ask which of them the customer can configure.
Position mapping. Nothing in a DBC says that signal instance three is the front-left outer wheel on axle two. You need a mapping table that relates every monitored position to a physical wheel, agreed before commissioning and stable afterwards.
Timeout and missing-sensor behaviour. When a sensor stops reporting, does the receiver keep sending the last value, send zero, clear a validity bit, or stop sending that wheel entirely? All four exist in the field. Only one is right for your controller, and you cannot tell from the DBC which one you have.
Validity and battery flags. A low sensor battery is not a tire problem, but it will become one. Make sure it appears as its own signal.
Version binding. Ask for the DBC revision to be tied to a firmware version. A file that matches no release is a file you cannot trust six months later.
A twenty-minute review
You do not need a test rig to sanity check a TPMS DBC. Load it into cantools or a CAN tool and do five things.
1. Does it parse? Tools reject malformed files loudly. A file that opens cleanly has already cleared the cheapest hurdle.
2. Does the message list match the documentation? Count messages and compare with the interface document. A mismatch means one of the two is stale.
3. Decode a sample frame. Ask the supplier for a captured frame with known values. Decode it and compare with the numbers in the document. If the supplier cannot provide one, that is itself a finding.
4. Check scaling limits. Multiply the raw maximum by the scale and add the offset. The result should be a physically plausible pressure, not ten times too large.
5. Look for overlaps. Two signals starting at the same bit position is legal to a parser and fatal in practice.
If you want to see how this looks on real hardware, the CAN bus TPMS integration page describes the interface layers we document, and the TR100 receiver page lists the protocols and electrical details in between.
What to ask for alongside the file
A DBC alone is not a handover. Ask for the message map in human-readable form, the alarm and threshold table, the position mapping template, the connector pinout, and a configuration tool for wheel count, sensor IDs and thresholds. If the receiver also has a serial output, ask for the register map, because Modbus RTU and RS485 integrations need it just as much.
It is also fair to ask who wrote the firmware. A supplier who owns it can change a signal or add a flag when your project needs one. A supplier who assembles third-party modules will forward your request and return an answer that is slower and less certain.
How we handle it
GZVIA develops the sensor, receiver, repeater, display and cloud platform in house in Shenzhen, which means the message map and DBC come from the same team that writes the firmware. For a serial integration we supply the register map; for a CAN integration we supply the frame layout, the alarm semantics and the configuration tool. We have delivered a 160-wheel beam carrier as two receivers, twelve repeaters and 160 sensors, and our largest single instrumented machine carries 224 wheels across 28 axles, so the long-vehicle cases are familiar rather than theoretical.
Send us the controller you are reading tire data into, the bus it speaks, and the wheel count, and we will send back a DBC for review before you commit to anything. Ask for a sample DBC.