Trailer Fingerprint Software (TFS)
Hello.
I started working on TFS because I kept coming back to a persistent mosquito-idea I’ve had: can the information already being exchanged between a tractor and trailer be used to tell which trailer is actually connected without proprietary permissions or tools? That question turned into a Zig project, but the project really started with the problem, not with me looking for something to build in Zig.
The question/problem introduced also has security implications for reasons I will not go into on this initial post. Rather than let that prevent me from exploring the problem, I decided TFS should be conservative about what it claims and explicit about what the available evidence actually supports.
Right now TFS is focused on reading and making sense of trailer network data, especially J1708/J1587 traffic, after it has already been pulled off the PLC/J2497 side. I’ve been using real captures and protocol documentation to figure out what information is actually there, what can be trusted, and where the evidence stops. I’ve been trying to avoid turning an interesting byte pattern into a claim before I can support it.
The bigger problem I’m interested in is trailer identity and continuity. Fleets can lose track of trailers, hook the wrong equipment, replace controllers, or end up with records that don’t line up cleanly with the physical trailer. My background in heavy-duty parts replacement makes that problem hard for me to ignore. I’m exploring whether the network information that is already there can become one more piece of evidence for recognizing equipment and spotting when something has changed, without requiring a driver to go through complicated or inconvenient identification processes, ultimately reducing some of the contributors to downtime.
Zig was the language I wanted to keep learning, and this gave me a real problem to use it on instead of another isolated exercise. Those have become increasingly difficult for me to push through because of how abstract they can feel. TFS can now ingest capture and logger files, parse J1708/J1587 traffic reassemble multi-section messages, and decode a small set of supported identity and metadata fields. I’ve also tried to keep unsupported or ambiguous traffic explicit instead of forcing it through a decoder. A lot of the challenge has turned out to be less about “can I parse these bytes?” and more about “what can I actually justify saying these bytes mean?”.
I also want to be upfront that I use ChatGPT heavily while working on this. It helps me organize research, work through unfamiliar protocol material, review code, and keep track of questions I’m trying to answer. I don’t treat generated answers as evidence, though. If something is going to become a claim in the project, I try to tie it back to documentation, source material, or an actual capture first.
I tend to work through technical problems better in smaller pieces than by trying to explain everything at once, so TFS has developed pretty incrementally. I’m posting this partly because I’d like outside eyes on the way I’m approaching the problem, especially where my assumptions might be weak or where there’s a better way to structure the Zig side of it. I’m not really looking to “promote” the repo as much as I am trying to make the work better.
One of the more useful things so far has actually been a capture that didn’t give me the answer I wanted. An authentic J1708 logger capture contained plenty of trailer-brake requests, but no response traffic that I could honestly use to establish identity. Instead of trying to manufacture an answer from it, TFS reports that the physical equipment identity was not established.
Right now I’m digging further into a WABCO Trailer TCS II path involving proprietary J1587/PID 254 traffic, because it appears to be one promising place to look for stronger component-identity evidence. There are still pieces of that exchange I don’t understand well enough to implement, so for now I’m treating that as a research question rather than a supported feature.
The feedback I’d value most is on the Zig side of the project and on the way I’m separating parsing, protocol interpretation, and higher-level identity reasoning. I’m especially interested in places where I may be making the design more complicated than it needs to be, overlooking a more idiomatic Zig approach, or failing to make an evidence boundary clear enough. I’m also happy to hear from anyone who has worked with J1708/J1587, J2497, trailer ABS systems, or similar embedded vehicle networks.
The repo is here if anyone wants to take a look: f-drakeland/trailer-fingerprint
I’m still learning a lot as I go, but this has become the first project where the Zig work and the problem I’m trying to solve feel tethered.
Supported Zig versions
Currently developed and tested against Zig 0.16.0.
AI / LLM usage disclosure
I use ChatGPT extensively throughout this project. It has helped me research unfamiliar protocol material, organize findings, reason through design decisions, review and troubleshoot Zig code, and at times generate or revise code with me. I test the code locally and try to understand what is being added rather than treating generated output as authoritative.
For the research side of TFS, I do not treat LLM output as evidence. Claims about protocols, captures, or equipment identity are checked against documentation, source material, authentic captures, and observed behavior before I consider them supported.