TEST ENGINEERING. KNOWLEDGE
What does CharIN CCTS validation mean – and what does it not cover?
CCTS validation means a statement about a test system and the defined CharIN charging-system profile it can execute. It does not automatically certify every charger tested with that system, every system configuration or unrelated electrical-safety and metrology requirements.
Test area and evidence
| Test area | What to define or record |
|---|---|
| Validated subject | Named test-system configuration. |
| Profile | Published Basic or Extended DC EVSE scope. |
| Charger result | Its own executed test cases and certification route. |
| Other domains | Safety, installation and metrology need their own scope. |
CharIN lists validated systems against defined charging-system application profiles and distinguishes them from recognised laboratories and approved charging products. Its public list includes comemso for Basic and Extended DC EVSE profiles. [1] CharIN conformance systems, laboratories and product evidence
A repeatable test workflow
- Identify the validated subject. Record the named test system, hardware/software configuration and CharIN application profile. Match the ordered setup to its current published listing and release documentation.
- Define the DUT test objective. Separate development regression from a formal product conformance route. Identify the DUT variants, protocol support and certification owner.
- Map the required cases. Use the applicable profile documents and released implementation to list executable cases, preconditions and expected results. Mark cases outside the selected configuration.
- Execute with controlled versions. Record DUT firmware, test system settings, library version, measurements and verdicts. Retain failed and repeated cases with their conditions.
- Route the conclusion correctly. For the product conformance route, agree the process with the recognised laboratory. Keep other safety, installation and metrology assessments as separately identified work.
Define the acceptance evidence
| Check | Evidence for the verdict |
|---|---|
| Documentation matches the setup | The validated system/profile statement corresponds to the configuration used in the report. |
| DUT identity | Executed cases identify the actual charging product, firmware and variant. |
| Profile coverage | The case list states executed, failed, not applicable and open cases for the agreed profile. |
| Correct conclusion | System validation, laboratory recognition and product approval are described as distinct outcomes. |
Fault examples and diagnostic checks
System logo used as charger certificate
Replace the conclusion with the executed DUT results and the correct product-conformance evidence.
Basic and Extended mixed
Check the profile and case version for every verdict before combining them in a release statement.
Configuration changed after validation
Compare the changed hardware/software with the validated scope and obtain the relevant release documentation.
Practical tip. Add a one-line subject/profile/configuration statement at the start of the report. It prevents a test-system qualification from being mistaken for a tested-product approval.
Design a reproducible test case
Read the validation as a configuration statement
Identify the validated test system, the named profile and the hardware and software configuration covered by the published listing. Check whether the intended test uses that configuration or a documented extension. A product-family name is useful for finding the system, but it is not a replacement for the validation scope. Keep the relevant documents with the laboratory's setup record and link it to the executed test recipe. Where the configuration differs, describe the difference and determine what additional proof is needed before relying on the validation statement in a customer report.
Separate the test-system claim from the charger verdict
A validated test capability concerns the defined tests that the system can execute. The charger under test still needs its own executed cases, observations and results. Name the unit, firmware and applicable profile in that report. Distinguish a system validation document, a laboratory test result and a certification decision; each answers a different question. Avoid turning a validation badge into a statement that every connected charger is certified. Where an external acceptance body is involved, agree the required configuration and report content with that body before using these records for a formal decision.
Plan changes to an established laboratory setup
Treat hardware replacement, software updates and library changes as configuration changes that need review. Compare them with the covered setup and retain the outcome in the laboratory record. Decide which baseline checks or repeated cases establish that the intended test remains reproducible. Preserve earlier results with the configuration under which they were obtained instead of silently relabelling them as output of the latest release. This is particularly useful when different teams use related systems: the same product name should not obscure a different profile, interface option or released test-library version.
Example: selecting evidence for a new charger release
Suppose an engineer prepares a test report for a new station firmware release. First identify the requested profile and the compatible test configuration. Execute the agreed cases and retain the charging observations and verdicts for that actual firmware. Attach or reference the test-system validation document where it applies. List additional electrical-safety, interoperability or metrology work as separate records rather than extending the validation badge to those areas. This is an illustrative documentation workflow, not a certification decision or a claim that the example station passed. The report should let a reviewer distinguish what was validated about the tool from what was tested about the charger.
Questions about this test scope
Is comemso listed for both DC EVSE profiles?
CharIN’s public list names comemso for Basic and Extended DC EVSE application profiles. Match the specific configuration and released cases to that listing.
Who issues the charging-product result?
Agree the formal route with the recognised laboratory and the responsible product owner. The test-system listing is a separate qualification.
What should a development team keep?
Keep the profile, configuration, DUT firmware, case versions, traces and verdicts so failed conditions can be reproduced after a change.
Can a validation badge replace the executed charger test report?
No. The report must identify the charger, firmware, test configuration and executed results. The badge supports the defined test-system capability; it does not supply the station's missing measurements or verdicts. Keep the two kinds of proof connected without treating them as interchangeable.
What happens when the validated configuration is updated?
Review the actual hardware, software and profile change against the documented scope. Retain the previous configuration identity and determine the required repeat checks or further evidence. Do not assume either that every update is covered or that every previous result becomes unusable without that review.
Sources and further reading
Technical content: comemso. Updated .