How to Read a Truck

Why — The bus was never the boundary

The reason for doing this

A CAN bus is a pair of twisted wires that every module on the vehicle shouts onto. It has no access control and never has. Anyone with a fifty-dollar adapter and a paperclip can listen to all of it.

What they cannot do is understand it — because the file that says which bits mean what has always stayed with the manufacturer. That is the whole control: not a lock on the wire, a dictionary kept in a drawer.

Which makes the status quo strange when you say it plainly. The operator owns the truck, the truck describes itself continuously, and the operator cannot read the description. They buy a subset back — a telematics box forwarding perhaps twenty signals once every ten seconds, out of the several hundred the vehicle is already broadcasting a hundred times a second.

We already publish the CAD for this vehicle. This is the same idea one layer up: if you own the machine, you should be able to read what it says about itself.

What — It moves the line to where it belongs

What it actually changes

The interesting part is not that data becomes available. It is where the security boundary ends up.

Withholding the dictionary was never a real control — it is obscurity, and it fails against anyone motivated enough to spend a fortnight with a logic analyser. Meanwhile it fails completely in the other direction: it stops the legitimate owner, the independent workshop and the fleet engineer, every single time.

Splitting the database by direction rather than by document puts the boundary somewhere defensible. Reading a vehicle never changes it; commanding one does. The read half is published. The write half — torque, gear and gate commands, and the checksum and rolling-counter rules that make a forged command acceptable — stays closed, and now it is closed for a reason rather than by default.

What this is worth in practice: a workshop with a sixty-dollar adapter can watch motor speed, gearbox output shaft speed and wheel speed at once, and tell a controller fault from a motor fault from a broken axle — without flying anyone in, and without a tool that has no distributor on their continent.

Anatomy — How eight bytes become seven facts

The whole mechanism, in one frame

There is no encryption here and no key. A signal is defined by four numbers: where it starts, how long it is, what to multiply it by, and what to add. That is the entire trick.

byte 2 = C0, byte 3 = 8F     little-endian  →  0x8FC0 = 36,800
36,800 × 0.5 + (−16,000)     =  2,400 rpm
          scale     offset

byte 4 = 10, byte 5 = A4     little-endian  →  0xA410 = 42,000
42,000 × 0.1 + (−3,000)      =  1,200 N·m

byte 6 = DC = 220
220 × 5 + (−600)             =  500 N·m

byte 7 = 42 = 0100 0010

  bits 56–59  0010  =  2   →  motor mode      Torque mode
  bits 60–61    00  =  0   →  fault class     No fault
  bit  62        1        →  IGBT gate       ON — closed
  bit  63        0        →  HV loop         OK

Budget — Why sixteen bits, and not eight or thirty-two

Two questions people ask, and they are different questions

Why write it in hex rather than ordinary decimal? Because the machine counts in 256s — a byte at a time — and sixteen is the only convenient window onto that. 256 = 16², so one byte is exactly two hex characters, every time, with no remainder. Decimal never lines up: a byte holds 0–255, which needs three decimal digits, but three decimal digits reach 999 — three quarters of the room wasted, and no visible seam between one byte and the next. You can see two separate bytes in C0 8F. You cannot see them at all in 192 143.

Why sixteen bits for the speed? That one is not a convention. It is arithmetic:

That last row is the real constraint. A classic CAN frame carries sixty-four bits and no more. Precision bought for one signal is precision taken from another. This frame is exactly full:

So a signal is never given a round number of bits out of habit. The width is ⌈log₂(range ÷ resolution)⌉, and the proof that this is done signal by signal is that the same database uses nine different widths — 1, 2, 3, 4, 5, 8, 12, 16 and 32 bits.

Motor speed at sixteen bits and gearbox output shaft speed at twelve is the pair that shows it best. Both are speeds. One sits before the reduction gear and one after, so one needs a range an order of magnitude larger — and the four bits saved go to somebody else in the same sixty-four.

Scale — Roughly twenty thousand values a second

How much data this actually is

The file is 42 KB. What it unlocks is not.

For comparison: the regulatory telematics box on the same vehicle uplinks on the order of a hundred values every ten seconds. This is roughly three orders of magnitude more resolution — on data the truck was already broadcasting to nobody.

Reach — What the truck says, what a fleet box hears

Where the 458 signals sit inside the whole vehicle

The published file is one read channel. The vehicle itself carries about twenty CAN buses under four domain controllers, and the numbers below are counted from the full internal signal matrix, not from this file.

The gap that matters is the third tile. A fleet box plugged into the FMS connector is classic CAN — eight-byte frames at 250 kbit/s — and the vehicle’s richest data (battery alarms, cell temperatures, charging state, cumulative energy) travels in CAN FD frames of up to 64 bytes that such a box physically cannot receive. So today it hears 66 messages out of 565.

We are closing that gap from the vehicle side. The vehicle controller will repack the FD content into standard eight-byte frames and broadcast the full telemetry set on the FMS connector: 3,459 signals in about 331 frames, fast dynamics at 10 Hz and everything else at 1 Hz, which fits in 17–41 % of the connector’s bandwidth. The decoding file for those frames will be published here in the same DBC format, so the truck stays compatible with every classic-CAN telematics device already in service. To see how the buses and gateways connect inside the vehicle, open the Truck CAN Meridian.

Reuse — Some of it works on any truck

Whether this is useful beyond our vehicles

Eleven of the forty-eight messages are standard SAE J1939. Those 57 signals are defined by the standard rather than by us, and they decode on any J1939 commercial vehicle — truck, bus, trailer or off-highway machine, whoever built it. Speed, distance, torque, gear, wheel speeds and brake state are all in there.

The remaining 37 messages and 401 signals are ours: our message IDs, our bit layouts, our network design. They will not decode anything on another manufacturer's vehicle — and by the same token, nothing in this file is a security concern for anybody else's product.

Within our own range this is the E700 platform matrix. The regional variants share the great majority of it; charging, some driver assistance and regional telematics differ. Accurate for the platform — verify the market-specific messages against the vehicle in front of you.

We could not find another vehicle manufacturer that has published its own production CAN database. The closest things that exist are community reverse-engineering projects — whose own documentation warns the files “should be regarded as completely untrustworthy” — and industry standard subsets, which are not any one manufacturer’s matrix. If you know of a counterexample, we would genuinely like to see it.

How hard — Four things that were genuinely difficult

What the work actually consisted of

Publishing a file is easy. Deciding what belongs in it is not, and most of the effort went there rather than into the release.

1. The line does not fall between documents

   The first instinct is to publish some files and withhold others. That fails immediately: the same message set contains both what the vehicle reports and what the vehicle is told. The split had to be made inside the files, by direction of information flow — message by message rather than folder by folder.

2. The write path hides in small signals

   Removing the obvious command frames is not sufficient. Nearly every safety-relevant message carries a checksum and a rolling counter, and their definitions are precisely what separate a valid command from a rejected one. Forty-two such signals had to come out — none of them interesting to read, all of them load-bearing for anyone trying to write.

3. Not all of it is ours

   A vehicle is an assembly of other companies' engineering. The diagnostic specifications for the brake, suspension and steering electronics arrived under technical agreements and cannot be redistributed, however much we would like the release to be complete. What we publish is what we designed.

4. The source was less authoritative than expected

   Bus bit rates turned out not to exist anywhere in the communication matrix — they live only in the legend of a network topology drawing. Connector pin numbers were unreadable until the drawing was rendered at 800 dpi, and two revisions of it disagreed. The human-readable labels in the machine-readable source had been corrupted and had to be rewritten. Publishing forces a level of verification that internal use quietly tolerates skipping, which is on its own a good argument for publishing.

Use — Any tool that reads a DBC

Getting started

The format is DBC — plain text, defined by Vector in the 1990s, understood by every CAN tool in existence: SavvyCAN, BusMaster, CANoe, TSMaster, python-can.

import cantools, can

db  = cantools.database.load_file('E700_Open_Telemetry.dbc')
bus = can.Bus(channel='can0', interface='socketcan')   # listen-only

for msg in bus:
    try:
        print(db.decode_message(msg.arbitration_id, msg.data))
    except KeyError:
        pass

Configure the interface in listen-only / silent mode. This database describes a read channel; a tool that transmits on a live vehicle bus can disturb it regardless of what it sends.

Glossary — The words used above

Plain definitions