Run repeatable charging test campaigns
Arrange saved charging tests into a campaign and run them in sequence. Keep each run's data with its settings and repeat the same campaign after a software or hardware change.
Automate complete charging cycles
A charging test campaign establishes the simulated charging partner and runs the complete interaction. It keeps the active configuration with each run, so the measurements remain linked to the behaviour that produced them.
Six steps from one test to a repeatable campaign
Keep the test records so you can compare them with the next DUT (device under test) version.
- Create configuration
Save the charging behaviour.
- Select configurations
Choose the behaviours for the campaign.
- Define sequence
Set the order and repetitions.
- Run charge cycles
Execute the selected sequence.
- Evaluate results
Evaluate the campaign automatically.
- Reuse for regression
Repeat the campaign for the next DUT version.
Save the EV or EVSE (electric vehicle supply equipment, or charging station) behaviour, interface settings, limits, timing and evaluation context for one charge cycle.
Choose the configurations, their order and repetitions. Define the supported criteria for stopping or continuing the campaign.
Repeat the same charging test campaign after a DUT change. Compare each outcome with the configuration that produced it.
Combine baseline, robustness and field-derived behaviour in one sequence
A charging test campaign can represent different virtual vehicles, charging stations, protocol behaviours, software versions or robustness scenarios. The selected release determines which sources can be combined and repeated.
Baseline behaviour
The normal charging sequence and expected DUT response are checked before robustness variants are added.
Professional Simulation configurations
Where released, add saved content, timing and exceptional protocol behaviour without programming a new test case.
Charge Playback configurations
Where supported, include recorded charging-partner behaviour so a difficult field case remains repeatable.
Run complete charge cycles beyond normal working hours
Overnight EV testing and unattended EVSE test automation increase coverage without requiring an engineer to supervise every connection and test start. Safe operation still depends on the released system, duration, abort logic and hardware limits.
One configuration after another
The configured charging session runs, and the campaign proceeds according to the supported campaign logic.
Defined criteria when deviations occur
Record, stop, continue or retry happen only where the selected release provides the required criteria and safe-state behaviour.
Measurements stay with their test conditions
Every cycle retains configuration identity, timestamps, measurements, evaluation and reports where configured.
Link each deviation to the active configuration
For useful engineering results from automation, keep measurements, evaluations and reports linked to the active configuration and DUT version.
Each result traced to its test conditions
Retain the campaign step, charging parameters, behaviour variant and repetition number.
Measurement connected to the applicable standard requirements
Where configured, combine protocol, signals, power and automated standards analysis in the same test record.
Repeated after every product change
The same campaign and test-record structure compares results from charging regression testing.
Choose automation for campaigns, conformance tests or laboratory integration
| Selection criterion | Charge Cycle Automation | Conformance Test Libraries | External API orchestration |
|---|---|---|---|
| Primary purpose | Sequence complete saved charging behaviours | Defined standards-based test cases and verdicts | The charging system, coordinated with a wider toolchain |
| Test input | Configurations, order, repetitions and criteria | Released test procedure and parameter set | External code, triggers and system integration |
| Best fit | Regression, variants, overnight campaigns | Conformance and traceable standards testing | Exceptional laboratory or CI integration |
| Programming | Not required for the core workflow | Not required for released library execution | Usually required for the external orchestration layer |
Use the same campaign logic across development, regression and interoperability work
The next vehicle software version is tested with the same simulated charging-station configurations.
Saved EV configurations test changes in charging-station software, parameters and robustness.
The same campaign runs after every build or release candidate where integration supports the workflow.
Released unattended functions keep traceability and laboratory operating limits.
Field-derived behaviour combines with saved nominal and robustness configurations where supported.
Each verdict stays with the configuration, DUT version, measurement and report used for the decision.
Core capability
- Charge Cycle Automation sequences saved charging configurations.
- Open interfaces can support broader automation where released.
What requires project approval
- Supported EVCA systems and hardware variants.
- Repetition limits, loops, retries and abort criteria.
- Unattended duration, recovery and safe-state behaviour.
- Report content, API scope and external CI integration.
Plan the configurations, sequence and results for your campaign
DUT, simulated role, configuration sources, operating limits and evaluation criteria are defined for the Charge Cycle Automation setup.
Charge Cycle Automation FAQ
What is Charge Cycle Automation?
Charge Cycle Automation is the EVCA and comframe capability for arranging saved charging configurations into a repeatable campaign. Run them in sequence and keep each run's evidence with the active configuration. Unattended regression is supported where the selected release and hardware setup permit it.
How is Charge Cycle Automation different from simple command automation?
Simple command automation calls individual functions or sends instructions. Charge Cycle Automation runs complete charging configurations and charge cycles. It retains the sequence, communication behaviour, configured timing and evidence needed to review the DUT response.
What does one charging configuration contain?
A configuration defines the charging behaviour required for one test. Depending on the selected system and release, it can include standard EV or EVSE simulation parameters, interface settings, protocol behaviour, limits, timing, Professional Simulation settings and associated measurement or evaluation settings.
Can Professional Simulation scenarios be used in a campaign?
Yes, where Professional Simulation is released for the selected charging standard and system. A saved robustness configuration can become one campaign step, allowing normal, boundary and intentionally non-conform behaviour to be repeated without rebuilding the scenario.
Can Charge Playback scenarios be automated?
Recorded charging behaviour can be part of a repeatable workflow where Charge Playback and campaign integration are supported in the selected release. Exact playback preparation, hardware, repetition and reporting functions must be confirmed for the project.
Can the same configuration be repeated several times?
Campaigns can include repetitions where supported. The available repetition logic, loop handling and limits must be confirmed against the current software release and selected hardware configuration.
Repeatable campaigns
Configurations, order, repetitions, limits and the evaluation of each cycle are defined.