feat: add Canonical EXI encoding support for ISO 15118-2/-20 Plug & Charge

[jayharper]

Describe your changes

Adds opt-in Canonical EXI code generation for ISO 15118-2 and ISO 15118-20 Plug & Charge XML signature workflows (digest computation over EXI-encoded signed fragments).

When canonical_exi_enabled = 1 is set in config.py, the generator produces a 2-mode runtime system controlled by a canonical_mode field on exi_bitstream_t:

• mode=0 (EXI_MODE_STANDARD): schema-informed standard EXI — existing behavior, unchanged
• mode=1 (EXI_MODE_CANONICAL): Canonical EXI for Plug & Charge — 0x80 header, bit-packed, type-aware encoding per W3C Canonical EXI specification

The feature is disabled by default (canonical_exi_enabled = 0), so existing users are unaffected.

What changed

Generator (Python):

• canonical_exi_enabled config flag threaded through FileGenerator, tools_config, and Jinja template rendering
• W3C-compliant canonical attribute ordering in SchemaAnalyzer (xsi:type first, xsi:nil second, then lexicographic by local_name + namespace_uri)
• namespace_uri field added to Particle dataclass for attribute sort key
• Recursive schema import processing for complete fragment grammar discovery (previously only 1 level deep)

Templates (Jinja → generated C):

• exi_bitstream_t gains canonical_mode field and EXI_MODE_STANDARD/EXI_MODE_CANONICAL constants
• exi_basetypes_encoder adds exi_basetypes_encoder_string_len() for string table partition prefix encoding
• exi_types_decoder adds decode_exi_type_base64_binary() for base64Binary decoding
• DecodeTypeBase64BinarySimple.jinja fix for correct nesting depth
• New error codes (EXI_ERROR__INVALID_LEXICAL_VALUE, EXI_ERROR__NUMERIC_OVERFLOW) for canonical decoding validation
• exi_types_encoder.h added to all encoder include lists

Validation

• Byte-identical output against EXIficient reference implementation for all 8 ISO 15118-20 signed fragment types
• SHA-512 digest match and end-to-end signature verification (RSA-SHA512 + ECDSA-SHA256)
• Validated against Keysight SL1550A EVCC live hardware (byte-identical 2,247-byte canonical output)

Issue ticket number and link

Closes #116

Checklist before requesting a review

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• I read the contribution documentation and made sure that my changes meet its requirements

[kwoyhope]

Hello @jayharper ,
It seems that there're missing "exi_types_encoder.c.jinja, exi_types_encoder.h.jinja" files.
And how(where) can it be used exi_bitstream.canonical_mode?

[jayharper]

@kwoyhope Good catch — the exi_types_encoder.c.jinja and exi_types_encoder.h.jinja templates were missing. I've added them in the latest commit along with the exi_types_encoder config entry so the generator produces those files.

Regarding canonical_mode usage — the caller sets it on the exi_bitstream_t before encoding:

exi_bitstream_t stream;
exi_bitstream_init(&stream, buffer, buffer_size, 0, NULL);
stream.canonical_mode = EXI_MODE_CANONICAL;  // 1 = Canonical EXI for Plug & Charge
// ... then call the encode functions as normal

The two modes:

• EXI_MODE_STANDARD (0): default, existing behavior unchanged
• EXI_MODE_CANONICAL (1): Canonical EXI for ISO 15118-2/-20 Plug & Charge — same 0x80 header and bit-packed alignment, but with type-aware encoding paths (e.g. exi_basetypes_encoder_string_len() for string table partition prefixes)

The generated encoder code and exi_types_encoder.c functions use these modes internally where encoding differs between standard and canonical EXI.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 8 complexity . 0 duplication

Metric	Results
Complexity	8
Duplication	0

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}