TEST ENGINEERING. KNOWLEDGE
How do you test a charging station without a real vehicle?
Without a real vehicle, use a vehicle simulator as the controlled counterpart to the charging-station DUT. Define the expected communication, electrical states and supported fault conditions, then record how the station responds to each case.
Test area and results
| Test area | What to define or record |
|---|---|
| DUT | Charging station or SECC. |
| Counterpart | Configured vehicle simulation. |
| Power setup | Compatible load, ratings and protection. |
| Verdict | Compare measurements with the agreed requirement. |
Use the vehicle counterpart appropriate to the station interface and operating modes. The configured simulator supplies reproducible charging-side behaviour; power-transfer tests need suitable electrical equipment in addition to the communication setup. [1] IEC 61851-23:2023 scope for DC supply equipment
A repeatable test workflow
- Define the station configuration. Record AC/DC mode, connector, protocol profile, firmware and maximum test operating point. Identify the station functions and expected responses in the test plan.
- Connect the simulated vehicle side. Match communication and signal wiring to the interface. Define source/load, measurements and protective boundaries according to the approved test setup.
- Run a complete baseline. Capture connection, negotiation, enable, energy transfer when included, stop and disconnect. Confirm a successful sequence before adding abnormal cases.
- Vary the vehicle behaviour. Change one supported requested limit, response timing or interruption. Verify the station state, messages and measured electrical response for that case.
- Repeat after changes. Restore the same initial state, execute the saved recipe after firmware changes and compare results. Add real-vehicle interoperability cases for the field combinations of interest.
Define the acceptance records
| Check | Evidence for the verdict |
|---|---|
| Configured counterpart | Vehicle role, physical interface and negotiated services match the station test case. |
| Electrical response | The executed station transition respects its applicable limits and enable/stop conditions. |
| Fault recovery | The controlled abnormal case produces the expected response and allows the defined restart. |
| Regression evidence | The report records simulator settings, DUT firmware, library version, trace and measured verdict. |
Fault examples and diagnostic checks
Normal handshake, no output
Compare enable conditions and load/source readiness with the station state; separate signal and power-path issues.
Station ignores a changed request
Check the recorded request, acknowledgement and measured response on the same time base.
Passes once, fails after restart
Check residual session, pilot and locking states, then execute an explicitly defined reset before the next run.
Practical tip. Save a short known-good baseline with each abnormal recipe. It reveals whether a later failure comes from the DUT change or from an altered test setup.
Design a reproducible test case
Choose which part of the vehicle to replace
Start with the station's development question. A communication investigation needs a controlled charging counterpart and access to the signals and messages involved. A test that transfers energy also needs a suitable load and the electrical connections required by the selected method. Write down which vehicle functions the simulator controls and which remain outside the setup. This prevents a successful protocol session from being interpreted as evidence about insulation, available power or every possible vehicle implementation. Keep normal operation, deliberate protocol deviations and electrical fault cases as separate entries in the test plan.
Build a small, repeatable test matrix
Use a baseline session before adding faults. Record the station firmware, simulator configuration, cable or adapter, selected communication profile and any external power equipment. Then change one relevant input at a time: connection state, negotiated parameter, message timing or a supported fault. Define the expected response and the observation that will decide the result before executing the case. If the station stops unexpectedly, keep the events immediately before the stop as well as the shutdown itself. A final error code often describes the consequence rather than the first cause.
Separate simulator coverage from fleet coverage
A simulator makes selected conditions repeatable; it does not recreate the entire variety of production vehicles automatically. Use documented vehicle profiles and recorded field observations to decide which cases belong in the regression set. Keep a real-pair interoperability investigation when an issue depends on a particular vehicle implementation. After reproducing the relevant behaviour, use the simulator for the supported follow-up cases. Record how the simulated case relates to the original observation, including any signals, energy-transfer conditions or features that were not reproduced. This gives a colleague enough information to judge whether the two tests answer the same question.
Example: isolate a failed charging start
Consider a planning example in which the station completes negotiation but never starts energy transfer. Run the agreed baseline with the simulated vehicle, then compare the first changed state or message in the failing session. Check whether the station received the intended request and whether its electrical response followed the selected procedure. Do not change the firmware, profile and load together. After a correction, repeat the failing case and the unchanged baseline. The report should link both runs, retain the original traces and identify the evaluated requirement. This is an illustrative diagnostic workflow, not a recorded customer result or a universal timing limit.
Questions about this test scope
Why use simulation when a real vehicle is available?
Simulation permits controlled, repeatable partner conditions, including configured abnormal responses that are difficult to produce deliberately with a real vehicle.
Do I still need real-vehicle tests?
Use relevant real pairs to confirm field interactions. Simulation supplies controlled coverage; the two methods answer complementary questions.
Does a simulator supply the charging load?
Identify the configured electrical architecture. Communication and signal simulation alone do not establish the source/load capability for energy-transfer tests.
When do I need a physical load as well as an EV simulator?
When the test objective includes real energy transfer or electrical behaviour that depends on the load. Confirm the required ratings, response and connections for that test method. A communication-only counterpart cannot by itself demonstrate how the station behaves under the intended charging power.
How do I turn a simulator test into a regression test?
Save the configuration, initial conditions, stimulus and decision rule with the trace. Reuse that controlled recipe after the change and retain an unchanged baseline case. Document any updated library or interface condition so that a different setup is not mistaken for a firmware improvement.
Sources and further reading
Testing a wallbox: procedure, standards, limits and test report
Technical content: comemso. Updated .