ISO 15118 Testing Tools and Approaches

ISO 15118 is a complex protocol with many failure modes. Building solid implementations requires rigorous testing — both during development and as ongoing regression coverage. Unlike OCPP where you can have a fairly complete test setup with just a CSMS and a charger simulator, ISO 15118 testing benefits from a richer tooling ecosystem. If you are new to the standard, start with what ISO 15118 is ^{(coming soon)} before diving into test strategy.

This article covers the tools, simulators, and testing approaches that work for ISO 15118 development.

The testing layers

ISO 15118 testing happens at several layers.

Unit testing — your application-layer code (state machines, certificate handling, message generation).

Protocol-level integration — your implementation talking to a counterpart implementation over a simulated link.

Physical-layer integration — your implementation talking to real hardware over real PLC.

Conformance testing — formal validation against the ISO 15118 specification.

Interoperability testing — your implementation talking to other vendors’ implementations.

Each layer catches different bugs. A full development program covers all of them.

flowchart TD
  U[Unit tests] --> P[Protocol integration]
  P --> PH[Physical layer]
  PH --> C[Conformance]
  C --> I[Interoperability]
  style U fill:#e3f2fd,stroke:#1976d2
  style I fill:#e8f5e9,stroke:#388e3c

Software simulators

A few simulators that exist for ISO 15118.

RISE-V2G

Open-source Java-based reference implementation of ISO 15118-2. Originally developed by Dresden University. Can act as either vehicle or charger.

Pros:

• Open source, freely available.
• Reference quality — closely matches the spec.
• Good for learning the protocol.

Cons:

• Java-based, may not integrate easily with non-JVM stacks.
• 15118-2 focused; 15118-20 support varies.
• Development pace can be slow.

EVerest

Open-source charge point firmware platform. Includes ISO 15118 support.

Pros:

• Modern, actively developed.
• Modular architecture.
• Supports OCPP + ISO 15118 + other protocols.
• Increasingly used by major OEMs as a base.

Cons:

• Larger commitment to learn / integrate.
• Charger-side focused (less for vehicle-side testing).

Josev (also from RISE-V2G family)

Newer Python-based ISO 15118 implementation. More accessible for development.

Pros:

• Python-based, easier to integrate with modern dev workflows.
• Active development.
• 15118-2 + 15118-20 support.

Cons:

• Newer; may have rough edges.

Commercial simulators

Several commercial products exist. European vendors include Vector Informatik, dSPACE, TÜV SÜD, and Comemso; North American offerings come from labs and vendors such as Keysight, Intertek, and DEKRA’s North American operations. Higher cost; often used by automotive OEMs for vehicle-side development.

Pros:

• Professional-grade tooling.
• Often include hardware-in-the-loop options.
• Vendor support.

Cons:

• Expensive.
• Less open to community improvement.

CharIN conformance testing

CharIN (the Charging Interface Initiative) is the industry body that maintains the CCS-and-ISO-15118 ecosystem. They publish conformance test specifications and operate certification programs.

A typical conformance test:

1. Submit your implementation to an accredited test laboratory.
2. Lab runs the test suite — typically a few hundred test cases covering normal flows, error handling, edge cases, security.
3. Lab issues a report. Pass / fail per test, with detail on any failures.
4. You fix issues, retest as needed.
5. Certification issued once passing.

Cost: tens of thousands of euros for a full test cycle. Time: months including iteration.

Not every implementation needs formal certification. For commercial deployment with major networks or OEMs, it’s often required. For experimental or in-house implementations, you can use the test methodology without formal certification.

Test specifications

CharIN publishes test specifications that detail the conformance tests. Available to members.

You can also use these as a development checklist — implementing against the test cases ensures your code handles all the cases the spec covers.

Hardware-in-the-loop testing

For automotive OEMs and serious charger developers, hardware-in-the-loop (HIL) testing is standard.

A typical setup:

• Vehicle side: vehicle’s actual ECU connected to a simulated charger.
• Charger side: charger’s actual control board connected to a simulated vehicle.
• Test orchestrator: drives test scenarios, captures responses, evaluates results.
• Physical-layer simulation: simulates the PLC link with realistic conditions (noise, attenuation, etc.).

HIL catches integration issues that pure software testing misses — timing, signal integrity, real ECU behavior.

Multi-vendor interoperability testing

ISO 15118’s interoperability requires testing across implementations. Common patterns.

Plugfest events

Industry organizations periodically host “plugfest” events where multiple vendors bring their implementations and test against each other.

A vehicle OEM brings a car; a charger OEM brings a charger; a CSMS vendor brings their back-end; they connect and test PnC flows.

Issues discovered: many. Plugfests are where the practical interop bugs surface.

Continuous interop

For serious implementations, ongoing testing against a panel of reference implementations is valuable. Not just at point-in-time plugfests but as routine CI.

This is operationally more complex but catches regressions early.

What to test

A list of test scenarios to cover.

Happy path

• Plug in, ISO 15118 session establishment, payment selection (External or Contract), authentication, parameter negotiation, charging, end.

Authentication paths

These scenarios map directly onto the Plug and Charge flow end to end ^{(coming soon)}, where certificate handling is the most common failure point.

• External payment with no certificate.
• Contract certificate present and valid.
• Contract certificate expired.
• Contract certificate revoked.
• Contract certificate from untrusted root.
• Contract certificate signature invalid.
• Vehicle without any contract certificate (provisioning needed).
• Multiple contract certificates; correct one selected.

Service negotiation

• Service discovery returns expected services.
• Selecting different services (charging, contract certificate management, etc.).
• Service not supported by counterpart.

Schedule negotiation

• Vehicle requests specific energy by specific time.
• Charger offers schedule; vehicle accepts.
• Charger offers schedule; vehicle counter-proposes.
• Schedule renegotiation mid-session.

Failure modes

• Network drops mid-session.
• Vehicle disconnects unexpectedly.
• Charger faults.
• Power loss.
• Certificate expires during session.

Security

• TLS handshake with mismatched certificates.
• Replay attacks.
• Malformed messages.
• Buffer overflow attempts.

Edge cases

• Maximum-length messages.
• Maximum number of certificates.
• Empty optional fields.
• Boundary values on numeric fields.

A thorough test suite covers many scenarios per protocol version, and the count grows with each edition — the differences between ISO 15118-2 and 15118-20 ^{(coming soon)} mean you often maintain separate suites. The test specifications from CharIN cover most cases; supplement with your own.

Common bugs caught by testing

A few patterns that recur across implementations.

Certificate chain validation. Implementation accepts certificates without fully validating the chain. Security issue.

Schedule miscalculation. Vehicle requests X kWh by Y time; charger computes a schedule that doesn’t actually deliver X by Y. User unhappy.

Race conditions on session end. Vehicle and charger have different ideas about session state at the end. Reconciliation issues.

EXI encoding bugs. Some messages encode incorrectly in EXI. Round-trip test catches.

Handshake timing. Implementations time out on slow counterparts. Production has variable latency; allow for it.

Vendor-extension handling. One vendor sends optional vendor-specific data; counterpart crashes parsing it. Should ignore unknown fields gracefully.

Cross-language type coercion. Java sends a long; C++ counterpart parses as int; overflow. Get the spec types right.

Setting up a dev environment

A practical recipe for ISO 15118 development.

1. Choose a stack based on your implementation language (Josev for Python, EVerest for embedded, etc.).
2. Run the stack as a vehicle simulator AND charger simulator locally. Test interactions.
3. Generate test certificates using openssl or a test PKI. Avoid using real PKI for dev work.
4. Set up a CI pipeline that runs your unit tests + protocol-level integration tests on every commit.
5. Get one piece of real hardware for periodic full-stack testing. A development charger or a development vehicle simulator with actual PLC hardware.
6. Attend plugfests when possible. Real-world interop is irreplaceable.

When to invest in conformance testing

A few signals.

Targeting commercial deployment with major networks: yes, you need conformance.

Selling chargers to OEMs: OEMs often require conformance certification.

OEM building vehicles for sale: definitely need conformance.

Research / experimental work: probably not.

Internal-only deployments: depends; some operators require conformance from vendors regardless.

Budget for conformance early. It’s expensive and time-consuming; don’t surprise your project with it at the end.

The honest summary

ISO 15118 testing requires deliberate investment. Software simulators (RISE-V2G, EVerest, Josev) get you far in development. CharIN conformance testing validates against the spec formally. Plugfests catch interop bugs. Hardware-in-the-loop catches integration bugs that software alone misses. Plan for all of these in any serious ISO 15118 implementation — the cost of skipping testing is bugs that manifest in field deployment, which is much more expensive to debug.