Chrysler: fuzzy fingerprint on part numbers, tolerate one unseen part

[ping-dev-ui]

Title: Chrysler: fuzzy fingerprint on part numbers, tolerate one unseen part

Closes #1092

Problem

Chrysler FW responses are a Mopar part number plus a software revision (68227902AF → part 68227902, revision AF). Today only the generic fuzzy matcher runs for Chrysler, and it needs exact FW strings. A dealer flash that bumps AF → AG on any ECU therefore makes the car unfingerprintable until someone submits a new route. Simulated on the current Chrysler database (10 platforms, 652 FW versions), a known car whose ECUs report an unseen revision letter fuzzy matches in 0 of 300 trials.

Change

Add match_fw_to_car_fuzzy for Chrysler in the same shape as the Ford and Hyundai implementations:

• FW_PATTERN splits each FW into part number and revision; get_platform_codes returns the part numbers.
• Platform code ECUs are cluster, SRS, ABS and EPS. Camera, radar and powertrain are excluded: radar part numbers are shared across the Pacifica platforms, and engine/transmission part numbers change with almost every calibration.
• A candidate matches when every expected platform code ECU agrees on a known part number, except that one ECU may carry an unseen part number (or be missing), with at least two agreeing ECUs. A new model year usually swaps the cluster part number and leaves the rest of the platform alone; requiring all four ECUs would reject exactly the cars fuzzy matching exists for. Two unseen ECUs are never accepted.

Why this is safe

test_platforms_distinguishable asserts that every pair of platforms differs on at least two platform code ECUs, so tolerating one unseen ECU cannot turn one platform into its sibling. Today the closest pairs are Durango / Grand Cherokee 2019 (share ABS and EPS part numbers, differ on cluster and SRS) and Pacifica 2018 / 2020 (share EPS, differ on the other three). The test fails as soon as a future fingerprint submission breaks that margin, which is the signal to revisit the tolerance.

Simulation on the full database (script and numbers in the PR discussion):

Scenario	generic fuzzy (master)	all four ECUs required	this PR
known car, unseen revision on every ECU	0 / 300	300 / 300	300 / 300
known car, one ECU with an unseen part number	0 / 760	0 / 760	760 / 760
cross-platform false positives on known FW	0 / 1000	0 / 1000	0 / 1000

Tests

opendbc/car/chrysler/tests/test_chrysler.py, modeled on the Ford tests: every FW in the database parses; known FW and unseen revisions match exactly one platform; one unseen part number still matches and never another platform; two unseen part numbers or two missing ECUs never match; the Pacifica 2018/2020 and Durango/Grand Cherokee 2019 sibling cases with an unseen cluster; the distinguishability invariant above. print_platform_codes.py mirrors the Ford/Hyundai helper.

Validation

• Dongle ID: n/a
• Route: n/a. This changes offline fingerprint matching only; no CAN or control behavior changes. Validated with the new tests and opendbc/car/tests/test_fw_fingerprint.py, which checks the brand function never disagrees with the generic matcher on known FW.

Related: #3520 takes the same part-number approach but requires all four ECUs; the numbers above are why this PR tolerates one.

[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