GB/T DC Charger Conformance and Interoperability Testing

Freeze the applicable GB/T editions

Identify the target-market requirement, charger firmware and exact editions named by the test plan. Connector, charging communication, interoperability and protocol-conformance documents can change on different schedules, so a general statement of GB/T support is not a sufficient test boundary.

Create a requirement matrix that links each case to its source clause, initial state, simulated BMS behavior and expected charger response. Mark optional functions and project-specific limits separately so they are not reported as universal requirements.

• ✓ List every applicable document and edition
• ✓ Record charger hardware and firmware
• ✓ Separate mandatory and optional cases

Exercise the complete charging sequence

Cover physical connection, handshake, parameter configuration, charging, controlled stop and completion states. Retain CAN messages and timing together with output voltage and current so the reviewer can see whether the charger followed the requested state and electrical limits.

Add controlled abnormal cases only after a repeatable normal session is available. Examples may include message timing deviations, values outside the declared operating envelope, insulation-related conditions or interrupted communication, but the exact stimuli and limits must come from the selected test specification.

Distinguish conformance from interoperability

Conformance testing checks observed implementation behavior against a defined test suite. Interoperability testing checks whether the charger completes representative sessions with another implementation. Passing one activity increases confidence but does not replace the other.

Use stable case identifiers, exportable traces and explicit pass or fail rules. When firmware or the applicable standard edition changes, perform an impact review and repeat affected cases instead of combining results from incompatible configurations.

• ✓ Keep conformance and interoperability results separate
• ✓ Use stable case identifiers
• ✓ Repeat cases affected by revisions