TEST ENGINEERING. KNOWLEDGE
What is an EV simulator and what is an EVSE simulator?
An EV simulator acts as the vehicle counterpart when the charging station is the device under test. An EVSE simulator acts as the charging-station counterpart when the vehicle or charging controller is the device under test. The selected role determines which signals, messages and electrical conditions these simulators control.
Test area and results
| Test area | What to define or record |
|---|---|
| EV simulator | Station or SECC DUT. Simulated vehicle. |
| EVSE simulator | Vehicle or EVCC DUT. Simulated station. |
| Interop analyser | Two real partners. Observe their interaction. |
| Configuration | Agree interfaces, protocol, faults and power scope. |
Choose the simulator from the DUT role, then specify which communication signals and power conditions it must control. A communication interface and a source/load are separate parts of the test architecture.
A repeatable test workflow
- Identify the DUT. Write down whether the DUT is the station/SECC, vehicle/EVCC or a controller with a reduced interface. List the physical connector and the protocol services to test.
- Assign the opposite role. Use a simulated vehicle for the station DUT and a simulated station for the vehicle DUT. For two real partners, select an analysis setup and identify which quantities can be observed.
- Separate signal and power paths. Draw the communication, measurement, source/load and protective boundaries. Specify the electrical operating range and which equipment supplies or absorbs the energy.
- Run normal and controlled abnormal cases. Start from a successful connection and charging sequence. Add supported partner-limit changes, delayed responses and interruptions individually; observe the DUT response.
- Package the result. Store DUT and simulator versions, settings, trace, expected transitions and verdict. Confirm that the initial state can be restored before the next run.
Define the acceptance records
| Check | Evidence for the verdict |
|---|---|
| Correct role | The simulator controls the counterpart signals rather than the DUT outputs. |
| Interface agreement | Connector, communication medium, protocol profile and test-library edition match the project. |
| Electrical boundary | The source/load and measurement ratings cover the executed operating point; signal-only results are labelled accordingly. |
| Repeatable restart | A completed or interrupted session returns to the defined initial state before the next test. |
Fault examples and diagnostic checks
Two vehicle roles connected
No station-side counterpart is present. Recheck the role assignment before diagnosing protocol behaviour.
Handshake succeeds, transfer fails
Check the power architecture and enable conditions separately from the communication session.
Only one real vehicle works
Use controlled counterpart variants to isolate supported service selection, timing or limits rather than relying on that vehicle alone.
Practical tip. Use a small role/interface diagram in the test report. It makes clear which side is real, which is simulated and where the electrical measurements were taken.
Design a reproducible test case
Use the DUT role to name the simulator
Begin with a simple sketch showing the real device and the controlled counterpart. When the charging station is the device under test, the counterpart acts as the vehicle. When the vehicle or its charging controller is the device under test, the counterpart acts as the charging station. Name the electrical interface and communication profile beside each connection. The word simulator describes a role in this setup; it does not establish the available voltage, current, fault depth or protocol features. A configurable platform can serve different roles, but each executed test still needs one documented configuration.
Distinguish analysis, simulation and power
Analysis observes what the partners do. Simulation controls selected counterpart behaviour. Energy transfer adds a power path with its own ratings and response requirements. List these capabilities separately when comparing systems. A message trace is useful evidence for communication, but it is not the same measurement as the physical output current or voltage. Likewise, a load that draws power is not automatically a complete vehicle communication simulator. The relevant question is whether the combined setup controls and measures the quantities required by your test, with the necessary timing and a traceable result.
Specify the fault instead of asking for all faults
Describe the input you need to vary, the phase of the charging sequence, the expected response and the signal that will be evaluated. Separate normal boundary conditions from deliberate deviations. Identify which faults the selected hardware can physically introduce and which cases are implemented in the released software or test library. Save this capability map with the test plan. It helps prevent a software feature name from being interpreted as an electrical fault capability, and prevents an electrical interface option from being treated as support for every application-layer service.
Example: the same charging issue, two roles
For a station that rejects a valid vehicle request, a vehicle-side simulator lets the engineer control that request and inspect the station response. For a vehicle that rejects a charging-station offer, a station-side simulator lets the engineer control the offer instead. These tests may look similar in a message log, but the real device, controlled stimulus and power path differ. Document the chosen role in the report title and configuration record. Reuse the same labels in automation and saved recipes. This is a setup example, not evidence that the two simulator roles have identical hardware or cover the same faults.
Questions about this test scope
Is an EV simulator a complete vehicle?
It reproduces the configured charging-side behaviour required by the test. Vehicle-specific mechanics, battery dynamics and unrelated controllers need their own scope.
When do I need a real charging pair?
Use a real pair to investigate the interaction encountered in practice, then use controlled simulation to isolate and repeat a selected condition.
Can communication-only testing be useful before power testing?
Yes. It allows protocol and signal sequences to be checked early. Add the electrical and power measurements required for the later release decision.
Is an EV emulator a different device category from an EV simulator?
The terms are often used for the same vehicle-counterpart role. Compare the documented functions rather than the label: interfaces, signals, protocol services, power arrangement and supported faults. Confirm whether the offered configuration performs the specific case you need to control and record.
Can one setup switch between EV and EVSE simulation?
A platform may offer both roles through suitable configurations. Check the actual interface hardware, connections, power equipment and software release for each role. Record the selected role for every run; the presence of both options in a product family does not make every installed configuration equivalent.
Sources and further reading
Technical content: comemso. Updated .