Chrysler: reliable fuzzy fingerprinting

[miniquinox]

Closes #1092.

The problem

Chrysler FW versions are Mopar part numbers: an 8 character base part number followed by a two letter revision, so b'68227902AF' is part 68227902 at revision AF. The revision gets bumped for running software changes that don't change the platform.

Chrysler has no brand fuzzy matcher, so it falls back to the generic one, which can only match FW strings it has literally seen. That means a dealer flash moving any ECU from AF to AG makes a known car unfingerprintable until someone submits a new route.

The change

A match_fw_to_car_fuzzy for Chrysler in the same shape as Ford and Hyundai: match on the part number, ignore the revision. Platform code ECUs are ABS, cluster and SRS, and one of them is allowed to carry an unseen part number or be missing, as long as the other two agree.

Why those ECUs, and why one is tolerated

I measured this over the whole checked-in database rather than picking. 10 platforms, 652 FW versions, 200 draws per platform per scenario, plus a replay of every commit that has ever added Chrysler FW.

platform code ECUs	tol	known FW	unseen revision	1 unseen part no.	2 unseen part nos.	false accepts	historical
abs+cluster+srs	0	2000/2000	2000/2000	0/2000	0/2000	0	20/30
abs+cluster+srs	1	2000/2000	2000/2000	1600/2000	0/2000	0	27/30
abs+cluster+srs+eps	0	2000/2000	2000/2000	0/2000	0/2000	0	18/30
abs+cluster+srs+eps	1	2000/2000	2000/2000	2000/2000	0/2000	0	25/30
cluster+srs+eps	0	2000/2000	2000/2000	0/2000	0/2000	0	18/30
cluster+srs+eps	1	2000/2000	2000/2000	2000/2000	0/2000	0	25/30
abs+cluster+srs+eps+radar	0	1984/2000	1988/2000	0/2000	0/2000	0	18/30
abs+cluster+srs+eps+radar	1	2000/2000	2000/2000	1988/2000	0/2000	0	25/30

Two things fall out of that.

Precision doesn't decide it. Every variant has zero cross-platform false accepts, so choosing ECUs on specificity grounds is choosing between ties. What actually separates them is recall on firmware we haven't seen.

The historical replay does decide it. For every commit that added FW to an existing Chrysler platform, I built the car as it would have reported afterwards and matched it against the database as it stood before that commit. abs+cluster+srs with one tolerated ECU fingerprints 27 of 30, against 20 for the same set with no tolerance and 25 for every variant that includes EPS. Zero mismatches in all eight variants, which is the number that matters: an unmatched car is the safe outcome, a wrong match is not.

The three remaining misses are genuinely new hardware, on two or more platform code ECUs at once: 7689bdd2 (2018 Grand Cherokee Trackhawk), 725fe0e8 (Pacifica 2019 hybrid), d8abecb8 (RAM 1500).

EPS and radar are excluded because their part numbers are shared between sibling platforms, and engine and transmission because they change with nearly every calibration. Neither adds discrimination here.

Why tolerating one ECU is safe

A false accept needs a car to satisfy all but one of another platform's platform code ECUs. I measured that distance for every ordered pair of platforms and the minimum is 2, so one unseen ECU can never turn a platform into its sibling. test_platforms_distinguishable asserts exactly that, and it fails the moment a future fingerprint submission erodes the margin, which is the signal to revisit the tolerance rather than finding out on a car.

The rule also degrades safely on its own. The two Pacifica hybrids have no ABS entry, so they only have two platform code ECUs and can't spare one. That's the 1600/2000 above rather than a gap.

Tests

opendbc/car/chrysler/tests/test_chrysler.py, modelled on the Ford suite, 12 tests. Every FW in the database parses (b'22DTRHD_AA' is the one that isn't a part number, and it sits on the radar, so it never contributes a platform code). A fuzz test that get_platform_codes never raises. A spot check including a trailing-space engine FW. Every platform matches only itself. Unseen revisions still match, one unseen part number still matches, two never do. And a synthetic four-ECU database that pins the tolerance itself rather than whatever the current database happens to allow.

I checked each test by reverting the thing it covers:

mutation	tests that fail
keep the revision in the platform code	4
widen PLATFORM_CODE_ECUS to every ECU	3
tolerate two unseen ECUs	1
accept on one agreeing ECU	1
require all ECUs, no tolerance	2

test_custom_fuzzy_match in test_fw_fingerprint.py stops skipping for the 10 Chrysler platforms, so the brand function is now checked against the generic one instead of being silently absent. Skips go from 702 to 692.

Validation

• ./test.sh: 3983 tests, 0 failures, up from 3971. ruff, ty, codespell, cpplint and MISRA all clean.
• Full CI green on a fork, every job: ./test.sh on ubuntu-24.04 and macos-latest, safety, safety mutation on both, all four test models shards, and car diff.
• car diff: 0 changed, 40 passed, 0 errors over 40 Chrysler segments.
• No new Request, so test_fw_query_timing's 'chrysler': 0.3 and total 8.3 are untouched.

Route

n/a. This only changes offline fingerprint matching, with no CAN or control behaviour, and the car diff replay above is the evidence for that.

🤖 Generated with Claude Code

[github-actions]

Thanks for contributing to opendbc! In order for us to review your PR as quickly as possible, check the following:

• Convert your PR to a draft unless it's ready to review
• Read the contributing docs
• Before marking as "ready for review", ensure:
  • the goal is clearly stated in the description
  • all the tests are passing
  • include a route or your device' dongle ID if relevant

[github-actions]

Car behavior report

Replays driving segments through this PR and compares the behavior to master.
Please review any changes carefully to ensure they are expected.

Testing 40 segments for: CHRYSLER_PACIFICA_2018_HYBRID, CHRYSLER_PACIFICA_2019_HYBRID, CHRYSLER_PACIFICA_2018, CHRYSLER_PACIFICA_2020

✅ 0 changed, 40 passed, 0 errors

[miniquinox]

Separate from the code review, a note on the bounty for this one.

I'd like to skip the payout entirely. No cash, no shop credit. What I'd rather have is a comma four, and I'm happy to put that in writing as a loan: if I haven't got something working in six months, I ship it back.

Here's what I want to do with it. I work as a senior software engineer at Google on hardware, and I'd like to take a run at FlexRay. I have a 2018 Range Rover Evoque Convertible with lane keep assist and adaptive cruise, which makes it a reasonable test car if the EPAS turns out to be reachable. FlexRay is the part I actually know, and it's the reason I'm asking for hardware rather than money.

I'm aware of what I'd be walking into. CARS.md says Land Rover is FlexRay and that there are no immediate plans to support it, and SupportType.INCOMPATIBLE says the same thing in code. I also know a comma four on its own isn't enough here: #2090 needed an FPGA based FlexRay interceptor sitting between the car and the panda, and that's the piece I'd expect to build or adapt. So I'm not asking anyone to change the roadmap. I'm asking for one device so I can find out whether this is tractable on a JLR car, on my own time, and report back either way.

For context on whether I'd actually finish it, this PR and commaai/openpilot#38815 are what I've contributed so far. Both are green, both came with measurements rather than assertions, and the openpilot one turned up a buffer sizing bug that had been breaking the simulator on every platform.

If GitHub isn't the right place for this, tell me where to take it and I'll move it there.