Not configured looks exactly
like no problem at all.

A diagnostic failure has no stack trace

Every other layer of an ECU tells you when it breaks. A pointer bug traps. A missing module fails the link. A wrong configuration throws at startup. The diagnostic layer does not do any of that: the ECU boots, the tester connects, the session opens, and then a request comes back 0x31 requestOutOfRange — or a DID answers with a payload three bytes shorter than the spec says, and the tool happily shows you garbage with a label on it.

The reason is structural. The two sides are written by different people in different tools:

Nothing compares them. There is no build step, no schema that spans both, no CI that would notice. Change a CAN address in the CDD and the ECU keeps listening on the old one forever, because nothing in the pipeline connects the two documents.

Two sources for the same number

Before the bug, the structure. A CDD stores diagnostic addresses in two different places, and the difference matters more than it looks:

  Some_ECU
       




          
    CAN.ReqCanId
  

Type 1 is configuration. Type 2 is what CANdelaStudio put there when the template was created, and it exists whether or not anyone ever filled in the CAN tab. The parser reads type 1. So when a project is created by saving a template and the CAN page is left empty, the attribute map comes back with no CAN entries at all — and the file still parses perfectly, still has 53 DIDs, still has 129 DTCs, still has every routine.

That combination is what made the bug invisible for a whole release: the document is structurally valid, and the only thing missing is the part nobody looks at when the DID list matches.

Eight checks that skipped in silence

The comparison block looked like this. Read the second and third lines again — they are the whole bug:

for code, sev, attr, role, label in id_map:
    cdd_val = cdd.attrs.get(attr)
    if not isinstance(cdd_val, int):
        continue          # <-- no value? skip the check. say nothing.
    arx_val = arx.canif_ids.get(role)
    ...

Three addressing checks (CDX-010/011/012) and five timing checks (CDX-020 through CDX-024) all guarded themselves the same way. With no CAN attributes, all eight hit continue. The report came back with DID findings, DTC findings, routine findings, and a small tidy summary — and no mention of CAN ids anywhere.

Those two states are the same string on a terminal. A run where all 53 DIDs, all 129 DTCs and all 4 routines matched reads like a complete review. In fact the CDD had 0 of the 3 required CAN addresses configured — and the template defaults that sat there instead were placeholder values that no ECU on that bus listens for.

Worse: the placeholder values are not random. They are 0x700 / 0x600 / 0x750, which looks plausible enough that nobody questions it, and exporting ODX from that CDD produces a tester that sends every request to 0x700.

The fix that is not a fix

The obvious repair is to fall back to the template value and compare anyway. Do not do that. It produces a confident verdict about a number that is not this ECU's address — and a confident wrong verdict is worse than a stated gap, because the reader will act on it.

So the gap itself became a finding. Two new codes:

Both name the checks that did not run. And the template defaults are kept in a separate field — attrs_template rather than attrs — so they can never be silently mistaken for configuration downstream. That separation was the actual fix; the two codes only make it visible.

Which side is wrong

This is the part that makes the tool worth writing. A diff can tell you that the CDD says 0x738 and CanIf says 0x72F. It cannot tell you which one to change, and the person reading the report is usually the owner of exactly one of those two files.

There is a tie-breaker, and it is in the ARXML: the hardware acceptance filter. The CAN controller does not deliver every frame to the software — it filters on CanHwFilterCode and CanHwFilterMask, and a frame passes only when:

(frame_id & mask) == (code & mask)

Evaluate both candidate ids against every filter in the configuration. Three outcomes, and only one of them licenses a verdict:

On a real project this resolved to a single filter out of 51, with mask 0x7FE. The mask has one don't-care bit, which is why 0x738 and 0x739 both land in that mailbox — and why 0x72F does not:

0x738 & 0x7FE = 0x738   == code 0x738   -> accepted
0x72F & 0x7FE = 0x72E   != code 0x738   -> rejected

So the controller only hands 0x738 frames upward. The CanIf PDU configured for 0x72F therefore describes an address that cannot reach the software — and the answer is not "the two files disagree", it is "change CanIfRxPduCfg_Phys_Req.CanIfRxPduCanId to 0x738".

One honest caveat, because the tool used to overclaim it. On that project CanIf hardware-software filtering was disabled (CanIfHrhSoftwareFilter = false), so CanIf does not re-validate the id in software. The wrong value is therefore a latent defect rather than an immediate failure: it works today by accident, and breaks the day someone enables the software filter, changes the HRH routing, or turns on an integration-test assertion.

A Phy is not a phys

CanIf PDU naming differs per supplier, so roles are detected by keyword rather than by an expected name. The first version looked for phys:

if 'func' in name.lower():    role = 'func_req'
elif 'phys' in name.lower():  role = 'phys_req'
elif 'resp' in name.lower():  role = 'resp'

Then a project arrived with RX_PDU_UDS_DiagPhyReq_LDLP. 'phys' in 'diagphyreq' is False. So the physical request PDU was never found, and the tool reported "the CDD defines a physical request CAN id but CanIf has no corresponding diagnostic PDU" — while that PDU sat in the file under a name that was three letters shorter.

The failure direction is the bad one. A missed mismatch leaves a real defect unreported; a false mismatch sends someone to create a PDU that already exists, and then they have two.

Fixed by matching phy, phys and physical. Trivial line, but it is the class of bug that only appears when the third supplier's naming convention shows up — and by then the tool has been trusted for months.

Proving 0 error is real

A checker that reports nothing is indistinguishable from a checker that broke. The only way to tell them apart is to plant known defects and confirm they still get caught — and specifically, to confirm that a passing fixture and a skipping fixture produce different output.

The self-test therefore has two fixtures:

The second fixture also asserts that attrs stays empty while attrs_template is populated. Without that assertion, the fix itself could regress into "read the template values into attrs" — which passes the first two assertions and reintroduces the confident-wrong-verdict problem.

Two real projects

The bug was not found by reading the code. It was found by running the tool on a second project whose CDD happened to be a template save with an empty CAN page — and noticing something was off about the report.

What noticed it was not a check. It was the probe output looking different from the previous run: the line that used to report CAN.ReqCanId under diagnostic parameters was simply gone. A missing line and an empty line look the same on a terminal, which is exactly why the probe now prints the gap explicitly.

The first row is the one worth staring at. Before the fix it reported 1 warn and looked fine. After the fix it reports 2 warns and one of them says a check did not run. The configuration did not change — only the honesty of the report did.

What the second project actually contained

Beyond the missing addresses, three ordinary findings that would each have cost a bench session:

The last row is the direction that matters. The three DIDs were named like SystemSupplierInternalECUHardware and ReadOnlyTest. Two are OEM-reserved identifiers that should not appear in an after-sales spec at all, and one is a leftover from the configuration tool's demo project. The correct action may well be to delete them from Dcm, not to add them to the CDD.

What it cannot see

Twenty-five checks passing is not the same as correct diagnostics, and the failure mode of a checking tool is that people stop reading the caveats. So the caveats are printed as part of every report, not buried in documentation.

The last row is the honest limit of the whole approach. If the CDD says 0x738 and the filter also says 0x738 but the vehicle actually uses 0x739, no amount of cross-checking between these two files will find it. Cross-checking finds disagreement, not wrongness.

Results and method

python skills/cdd-arxml-consistency/scripts/cdd_arxml_check.py probe  ecu.cdd ecuconfig.xml
python skills/cdd-arxml-consistency/scripts/cdd_arxml_check.py check  ecu.cdd ecuconfig.xml
python skills/cdd-arxml-consistency/scripts/cdd_arxml_check.py matrix ecu.cdd ecuconfig.xml -o inv.csv
python skills/cdd-arxml-consistency/scripts/cdd_arxml_check.py selftest

Exit codes are 0 / 1 / 2 — no error, errors found, bad arguments — so it drops into CI without a wrapper. 25 codes, 10 error / 12 warn / 3 info. Standard library only, read-only, Python 3.8+.

Four things here generalise past this tool: