TEST ENGINEERING. KNOWLEDGE
How do you reproduce an EV–EVSE interoperability fault in the lab?
Record the real vehicle (EV) and charging station (EVSE) on a shared time base, including communication and available electrical measurements. Identify the first deviation, then reproduce the supported partner behaviour with a controlled simulator and compare the DUT response with the original event.
Test area and results
| Test area | What to define or record |
|---|---|
| Field record | Save pair identity, firmware, session and measurements. |
| First deviation | Compare request, signal and electrical response. |
| Lab reproduction | Map supported behaviour to the simulator. |
| Retest | Run the changed DUT under the same defined conditions. |
Use a captured session to define the reproduction conditions and the expected DUT response. Treat the first observed deviation as a diagnostic lead; confirm the cause by changing one controlled condition.
A repeatable test workflow
- Capture the complete charging pair. Record vehicle and station identifiers, firmware, connector, negotiated protocol, session outcome and available electrical channels. Keep the original trace, including the successful sequence before the failure.
- Locate the first divergence. Align protocol messages, control-pilot states and measured voltage/current. Work backwards from the abort to the first request, transition or measurement that differs from a successful session.
- Choose the counterpart to simulate. For a station DUT, reproduce the vehicle side; for a vehicle DUT, reproduce the station side. Map the observed values and timing to features available in the configured simulator. Document anything the laboratory setup cannot reproduce.
- Reduce the failing case. Run a known-good baseline, then vary one suspect condition, such as a delayed message or a changed requested limit. Retain the smallest sequence that still triggers the same DUT response.
- Retest the fix. Repeat the failing case with the changed firmware and compare the original and corrected traces. Add neighbouring valid cases and a recovery session to the regression set.
Define the acceptance records
| Check | Evidence for the verdict |
|---|---|
| Same conditions | The report identifies protocol, firmware, operating point and simulator settings, plus differences from the field setup. |
| Same failure signature | The laboratory trace reproduces the same first deviation and downstream DUT response; a generic abort is insufficient. |
| Observable response | The required protocol and electrical channels are captured on the agreed time base with event timestamps. |
| Verified correction | The corrected DUT passes the reproducer, nearby boundary cases and recovery under the versioned project acceptance criteria. |
Fault examples and diagnostic checks
Precharge abort
Compare requested voltage, reported voltage and measured output before the abort. Check sensing, ramp behaviour and message timing separately.
Intermittent timeout
Compare the actual request-to-response interval with the applicable requirement. Check whether the delay originates in the counterpart, DUT or test setup.
Message trace appears healthy
Inspect control-pilot, locking and available electrical channels. A protocol-only trace may miss the condition that triggered the stop.
Practical tip. Keep the untouched field trace beside the reduced test case. Label hypothetical cause, controlled experiment and confirmed cause separately so the regression case remains understandable after the firmware changes.
Design a reproducible test case
Capture the first divergence
Start with the real pair and an observable symptom: charging does not start, the session stops or the delivered behaviour differs from the request. Preserve messages, state changes and available electrical measurements on the same time base. Include the period before the user-visible failure. Compare what each partner requested with what the other partner actually did. Identify the first meaningful divergence rather than assigning responsibility from the last error message. Keep the vehicle and station identities, firmware versions, cable, adapter and operating conditions with the recording so that the investigation can be repeated.
Decide which partner to simulate
The device under test remains the real device whose response you want to investigate. Replace the other partner with supported simulated behaviour. If you are investigating a station response, define the vehicle-side stimulus; if you are investigating a vehicle response, define the station-side conditions. Check which parts of the original recording can be reproduced by the selected configuration. Communication timing, physical signals and energy transfer may have different coverage. Mark these boundaries before comparing results. A recording that can be imported for analysis is not automatically a recipe that reproduces every physical feature of the original session.
Keep the reproduction and correction distinct
First establish whether the controlled case produces the relevant failure. Then freeze that recipe and apply the intended correction to the device under test. Compare the original field recording, the controlled reproduction and the follow-up run. Preserve unsuccessful attempts as part of the diagnosis rather than selecting only the best-looking trace. Where behaviour changes between runs, account for software versions and starting conditions before attributing it to the repair. An additional normal session helps show whether the correction introduces an unwanted effect elsewhere in the sequence.
Example: a stop during a parameter change
Imagine a session that stops immediately after a charging parameter changes. The diagnostic question is which message or electrical response first departs from the expected sequence. Replay the supported counterpart behaviour with the same device under test and compare that transition. If the failure disappears, check differences in the physical setup and starting conditions before concluding that the field recording was wrong. If it is reproducible, retain the controlled case for the firmware correction. Include the time-aligned traces and the reproduction boundaries in the report. This describes an illustrative investigation, not a measured product response or a claim that every field fault can be replayed.
Questions about this test scope
Can a saved trace always be replayed directly?
Map the captured behaviour to the configured playback and simulation functions. Electrical conditions and unsupported partner states may require an additional controlled setup.
What makes the reproducer useful for a release?
It triggers the original failure before the fix, passes after the fix and includes a documented expected response, versioned setup and repeatable initial state.
Should I change several timing values at once?
Begin with one controlled change. Combined faults are useful later, once the individual trigger and expected recovery are understood.
What if the fault only occurs with the original vehicle and station?
Continue the real-pair investigation and preserve the conditions that make the fault observable. Check whether the selected simulation can reproduce the relevant interface, timing and energy-transfer behaviour. A non-reproduced fault is an unresolved diagnostic result, not proof that the original pair works correctly.
Which traces should accompany a repaired interoperability issue?
Keep the original event, the controlled reproduction where available and the follow-up result. Identify the first changed event and the firmware correction. Record the supported reproduction scope and a normal baseline so that the reviewer can distinguish a resolved fault from a different test condition.
Sources and further reading
Technical content: comemso. Updated .