eMobility and EV Charging Protocol Testing Guide

Select the interface and communication test scope

EV charger communication protocol testing starts with the connector and protocol revision. GB/T and CHAdeMO workflows can involve CAN communication; CCS workflows can involve PLC communication. Specify the actual charger implementation, required messages and test cases rather than assuming one analyzer covers every interface.

Use the product configuration as the equipment boundary: AST-9000 provides an integrated laboratory route, ST-9980EA-HPC is a portable CCS2 option with optional PLC capture, and ST-6680CA-DC addresses CHAdeMO testing. Confirm capture, decoding, fault-injection and measurement options separately with the engineer.

• ✓ Identify connector and protocol revision
• ✓ Confirm CAN or PLC capture requirements
• ✓ Define normal, timeout and termination cases

Build a synchronized charging timeline

Begin by recording the physical connection, pilot state and communication startup. For CAN-based or PLC-based charging, capture the raw traffic together with timestamps and charger measurements. A decoded message table is useful, but it should not replace the original data because timing, repetition and malformed fields can explain behavior that a summary hides.

Mark the transition into parameter negotiation, readiness, current demand, active charging and shutdown. Compare requested voltage and current with charger output and tester measurements at each stage. This makes it possible to distinguish a communication disagreement from an electrical response problem.

• ✓ Retain raw messages and timestamps
• ✓ Record pilot and contactor transitions
• ✓ Align requests with measured output

Test faults without losing context

A protocol fault test should change one controlled condition and define the expected recovery or shutdown behavior before execution. Examples include a delayed message, an out-of-range parameter, a communication interruption or a simulated insulation condition. Avoid changing several signals together because the resulting shutdown cannot be attributed confidently.

Capture data before the injection, during the abnormal condition and after recovery. The surrounding messages often show whether the charger detected the intended fault, reacted to a secondary condition or continued using stale state information.

Example: diagnose a charger that stops during negotiation

Save a normal reference session, then reproduce the stopped session using the same charger firmware and tester configuration. Identify the last completed charging state and compare the parameter exchange, pilot behavior and measured output with the reference.

If a communication timeout is suspected, check the raw message interval and the charger response before drawing a conclusion. If messages continue but power transfer does not begin, review readiness conditions and electrical measurements. Set pass or fail limits from the applicable test procedure; a missing charging session alone does not identify the cause.

• ✓ Save a normal reference capture
• ✓ Find the first state that differs
• ✓ Retest after the corrective change

Turn captures into repeatable evidence

Store the tester configuration, software version, charger identity, standard version and test-case revision with every capture. A useful engineering report links the test step to message evidence, electrical measurements and the observed charger response. When a failure is reproduced, the same setup should produce a comparable timeline rather than a screenshot without context.

• ✓ Record protocol and software versions
• ✓ Link raw evidence to each test step
• ✓ Repeat the sequence after corrective action