EXI — Efficient XML Interchange — is a binary encoding for XML that drastically reduces message size. ISO 15118-20 (coming soon) uses EXI for its protocol messages, replacing the verbose plain-XML approach of ISO 15118-2.
It’s a small-sounding change with significant practical impact. This article explains what EXI is, why it matters in the context of ISO 15118, and what implementers should know.
The bandwidth constraint
ISO 15118 (coming soon) messages travel between the vehicle and the charger over a HomePlug GreenPHY connection riding on the CCS pilot pin. The available bandwidth is roughly 1-2 Mbps theoretical, often 200-500 kbps effective. Not a lot.
ISO 15118-2 uses plain-text XML for its messages. A typical PaymentDetailsReq carrying a contract certificate (coming soon) can be 4-10 KB of XML. The certificate alone is large; the XML wrapper adds significantly more.
At 500 kbps, a 5 KB message takes about 80 ms to transmit. Multiplied across a session’s many messages (session setup, service discovery, payment selection, charge parameter discovery, schedule negotiation, etc.), the total comms time can easily reach 10-30 seconds before any actual charging begins.
Most of that is unnecessary. The XML format is verbose; the data being transmitted is small.
What EXI does
EXI takes the XML messages and encodes them in binary form using the XML Schema as context. Because both sender and receiver know the schema, EXI can:
- Replace tag names with short codes. An XML element like
<paymentDetailsReq>becomes a single byte (or fewer with grammars). - Encode types efficiently. A 32-bit integer becomes 4 bytes instead of however many characters its decimal representation needs.
- Use bit-level packing. Boolean values are bits, not characters.
- Eliminate whitespace and structural overhead. No need to indent, no need for closing tags.
Typical compression ratios for ISO 15118 messages: 5-10x smaller than plain XML. A 5 KB XML message becomes a 500 byte EXI message.
At the same 500 kbps, that 500-byte message takes 8 ms instead of 80 ms. Across a session, this saves seconds of total connection time.
How EXI works under the hood
A simplified view.
-
Schema-driven. Both encoder and decoder have the XML Schema (.xsd file). Without it, neither can encode or decode.
-
Grammar generation. From the schema, the EXI library generates a “grammar” — an internal representation of all the possible structures and field types.
-
Encoding. The encoder traverses an XML document, looks up each element in the grammar, and emits the corresponding compact binary representation.
-
Decoding. The decoder reads the binary bytes, consults the grammar, and reconstructs the XML structure.
The cleverness: because the grammar encodes everything that’s possible, the on-wire data only needs to identify which possibility is being used, not describe it in full text.
What this means for implementers
Building an ISO 15118-20 implementation requires EXI support.
Use a library. Don’t roll your own EXI encoder. The W3C specification is complex; mature libraries exist (some commercial, some open-source).
Schema sources. The ISO 15118 specifications include the relevant XML schemas. Use them directly; don’t recreate.
Schema versions matter. Different ISO 15118 versions have different schemas. Make sure your EXI grammar matches the version you’re targeting.
Testing. Test that your encoded EXI round-trips correctly. Encode → decode → verify the original XML is reconstructed. Catch grammar issues early.
Performance. EXI encoding/decoding has CPU cost. For embedded chargers with constrained CPUs, profile this. Usually fine but worth measuring.
What this means for ISO 15118-2 implementations
ISO 15118-2 uses plain XML. Some implementations support EXI as an optional optimization (the spec allows it), but most use plain XML in production.
If you’re building a 15118-2 implementation today, plain XML is fine. The performance is workable; the implementation is simpler.
If you’re planning to migrate to 15118-20 eventually, factor EXI work into the migration plan. Adding EXI support to an existing 15118-2 codebase is non-trivial.
Practical performance impact
A few real-world performance numbers (approximate, varying by implementation).
ISO 15118-2 PnC session establishment: typically 15-45 seconds from plug-in to power flowing. Much of this is message transit time over the slow PLC link.
ISO 15118-20 PnC session establishment with EXI: typically 10-20 seconds. The faster encoding accounts for much of the improvement.
Per-message size:
- 15118-2 ChargeParameterDiscoveryReq with EV details: ~2 KB plain XML.
- 15118-20 equivalent in EXI: ~200-400 bytes.
Total message bytes per session:
- 15118-2: ~50-100 KB total exchanged.
- 15118-20 EXI: ~10-20 KB total exchanged.
The user experience benefit is noticeable. Faster session start = better Plug & Charge UX.
Why didn’t 15118-2 use EXI?
A reasonable question. A few reasons.
Maturity of EXI in 2014 (when 15118-2 was published) was lower. The W3C spec was finalized in 2014 but tooling was nascent.
Conservatism in standards. XML was the safe choice. EXI was newer and less proven.
Implementation cost. Adding EXI required new tooling that many implementers didn’t have.
Optional in spec. 15118-2 technically allows EXI but doesn’t require it. Most implementations went with plain XML for simplicity.
By 2022 (when 15118-20 was published), EXI was mature enough to be the default. The standard’s authors made it mandatory.
EXI in the broader protocol stack
A note on where EXI sits.
flowchart TD
MSG[ISO 15118 message] --> EXI[EXI encoder]
EXI --> BYTES[Binary bytes]
BYTES --> V2GTP[V2GTP framing]
V2GTP --> TLS[TLS]
TLS --> TCP[TCP / IP]
TCP --> PHY[HomePlug GreenPHY]
PHY --> PIN[CCS pilot pin]
style EXI fill:#dbeafe,stroke:#2563ebEXI is at the application layer. It compresses the application-layer messages but doesn’t affect transport. TLS still adds overhead. V2GTP adds its own framing.
For end-to-end performance optimization, EXI is the biggest single lever. The other layers are already optimized.
Common implementation issues
A few things that come up.
Schema version mismatch. Encoder uses one schema version; decoder expects another. EXI decode fails. Common when migrating between protocol versions or with implementation bugs.
Library bugs. Some EXI libraries have edge cases that don’t round-trip correctly. Test thoroughly.
Memory pressure on chargers. EXI grammars can be large. Embedded chargers with constrained memory may struggle. Use compact-grammar options where available.
Debugging is harder. EXI binary data isn’t human-readable. Need decoder tools to inspect messages in dev/debug.
Schema completeness. If the schema doesn’t fully describe the message, EXI encoding can fail in unexpected ways. Make sure your schema matches what you’re sending.
What this means for users
A user doesn’t see EXI. The experience is just “Plug & Charge is faster on newer vehicles and chargers.”
The improvement isn’t dramatic (10-20 seconds instead of 30-45) but it’s noticeable. By the time 15118-20 is broadly deployed (2027-2028), users should see meaningfully faster Plug & Charge (coming soon) session starts.
The honest summary
EXI is the binary encoding format that makes ISO 15118-20’s faster session establishment possible. It’s a meaningful technical improvement over the plain-XML approach of 15118-2. For implementers, EXI adds complexity (libraries, schemas, debugging) but the bandwidth and latency benefits are real. For users, it’s invisible — just a slightly faster experience. As 15118-20 adoption grows, EXI will become standard infrastructure that ISO 15118 implementers take for granted.