Applications / Interoperability & Charging Analysis
Find the Cause of an EV Charging Failure
When an electric vehicle and charging station fail to charge together, record their messages, voltage and current on one timeline. Find the first mismatch, test the suspected cause and repeat the session after a correction.
Test scenario: Start with the precharge mismatch
In the documented customer case, the voltage requested by the vehicle did not match the charging station’s measured precharge response. Precharge prepares the voltage before the main power connection closes. Compare the request, measured voltage and next state together, then repeat the charging attempt after the control parameters have been corrected.
When the timing looks right, inspect the electrical response.
In an anonymised EVSE (electric vehicle supply equipment, or charging station) case, the requested battery voltage and measured precharge response did not match. Reviewing communication and electrical signals together made the mismatch visible.
Why charging interoperability failures remain unresolved
The failure exists between systems. The evidence usually remains separated by system.
Reliable charging failure analysis requires more than another PCAP, vehicle log or charger trace. Effective charging failure analysis starts by rebuilding one shared technical sequence across both implementations. The decisive question is which event occurred first across communication, low-level control and electrical behaviour, and which reaction followed. Separate clocks and partial views can make the final error visible while hiding the initiating deviation.
Different clocks
Vehicle, charging station, backend and laboratory tools often record on independent time bases. Manual alignment can reverse the apparent order of events.
Partial technical views
Decoded messages alone do not show whether low-level states, voltage, current and the expected charging phase remained consistent.
Unverified assumptions
Teams discuss symptoms from separate exports. The suspected cause is often changed in software before it has been tested under the same conditions.
Passive Man-in-the-Middle measurement
Observe the real interaction without replacing either side.
The investigation begins at the physical charging interface. The real EV and real EVSE remain the active partners while a passive Man-in-the-Middle path records the relevant layers on one time base. This preserves the behaviour that actually produced the problem instead of reconstructing it later from independent logs.
Active manipulation and laboratory simulation are separate validation steps. They are introduced only after the original event has been captured and the engineering question is clear.
Cross-layer charging analysis
Showing decoded data is not the same as analysing the charging process.
Charging interoperability analysis connects protocol messages, timing, low-level states, voltage, current and the reactions of both partners. The objective is to identify the first technically meaningful deviation and place it in the context of the charging phase, not simply to collect more traces.
Check whether the complete state is consistent.
Communication
Message direction, sequence, content and timing.
Low-level state
Connection, control, signaling and stop conditions.
Electrical behaviour
Voltage, current, power transition and physical reaction.
Expected context
Charging phase, permitted combination and identified deviation.
Automated Standards Analysis can add normative or configured expectations where released. Cross-Layer State Monitoring is implemented for applicable DC CCS, CHAdeMO and DC China / GB/T DC configurations. Check the exact protocol versions, channels and evaluation rules for your selected product and capability.
One charging interoperability method
Connect. Capture. Decode. Correlate. Analyse. Validate. Reproduce. Reuse.
The complete workflow preserves the evidence chain from the real charging event to the controlled engineering decision.
- 1
Connect
Access the real EV and real EVSE at the charging interface.
- 2
Capture
Record the relevant charging layers on one synchronised time base.
- 3
Decode
Resolve protocol messages, state transitions, signals and timing.
- 4
Correlate
Relate communication to low-level and electrical behaviour.
- 5
Analyse
Identify the first deviation in the expected technical context.
- 6
Validate
Test the suspected cause through one controlled change.
- 7
Reproduce
Bring supported partner behaviour into a repeatable laboratory test.
- 8
Reuse
Preserve the case for evidence, supplier alignment and regression.
Controlled validation and field-to-lab reproduction
Test the hypothesis before changing either product.
After the initiating deviation has been isolated, change only the condition required to test cause and effect. A live gateway method can modify a selected communication condition while both real partners remain connected. A playback method can later reproduce supported charging-partner behaviour at the physical interface.
Validate live
Use Manipulating Gateway where released to test whether a selected value, message or timing condition changes the result.
Open the capability pageReproduce in the laboratory
Use Charge Playback where released to present recorded EV-side or EVSE-side behaviour to the device under test again.
Open the capability pageStart with the investigation method, then confirm supported directions, editable parameters, release limits and technical configuration on the relevant capability pages.
Keep measurements with their test conditions
Record the failure, repeat the conditions and check the fix.
Preserve the synchronised measurement, applicable expectation, identified deviation, validation condition and resulting decision in one attributable package. The value is not the number of exported files. It is the traceable connection between the original event and the verified conclusion.
- One synchronised measurement instead of isolated exports
- Expected state and deviation shown with observed behaviour
- Controlled validation condition documented
- Shared evidence for development, suppliers and laboratories
- Reusable case for release regression and variant testing
Use one technical case across development, partner alignment and field escalation.
Where the method creates leverage
Resolve integration failures before release
Understand interaction problems while vehicle and charging-station software can still be changed deliberately.
Capture the concrete pair at the site
Preserve the event that disappears when either implementation leaves the location.
Replace blame discussions with shared evidence
Use one time base, one sequence and one tested hypothesis across both implementation teams.
Reuse verified cases after changes
Repeat the relevant partner behaviour after software, parameter or hardware updates.
Continue with the decision the evidence makes possible.
From method to implementation
Choose the next route according to whether you need real-pair capture, active reproduction, configurable faults or a complete system configuration.
EVCA Interop
Concrete hardware, software, interfaces, configurations and commercial system scope for the real-pair boundary.
EVCA Multi Mobile
Broader portable measurement, simulation and multi-standard field work.
CapabilityAutomated Standards Analysis
Released standards-aware evaluation, timing analysis and user-interface proof.
CapabilityManipulating Gateway
Supported live changes, protocol scope, limits and validation conditions.
CapabilityCharge Playback
Active physical charging-partner reproduction, direction and release depth.
Conformance Test Libraries
Defined test cases, standard editions, DUT roles, verdicts and validation scope.
Conformance, interoperability and robustness
Three questions. Three test disciplines.
Conformance
Does one implementation meet a defined requirement set and standardized test cases?
Interoperability
How do two concrete implementations behave together in a real charging session?
Robustness
How does an implementation react to configured limits, timing changes and difficult behaviour?
Customer references
Real-pair investigation in practice.
The following customer experiences relate to testing with our EVCA systems.
Customer outcomeThe team describes EVCA as its most complete vehicle simulation, sniffer and man-in-the-middle system.
Customer outcomeA long-running collaboration continues with another comemso hardware upgrade for the EFECT laboratory.
Frequently asked questions
Interoperability and charging analysis
What is charging interoperability testing?
It investigates how a specific real EV and real EVSE behave together during an actual charging session. The method connects communication, low-level state, timing, electrical behaviour and the reactions of both implementations.
How does interoperability differ from conformance testing?
Conformance testing evaluates one implementation against defined requirements and test cases. Interoperability testing investigates the interaction between two concrete implementations. Both are necessary because they answer different questions.
Why can individually compliant products still fail together?
Different interpretations, optional behaviour, timing margins, certificate conditions, state transitions and error handling can interact in a way that a test of either implementation alone does not expose.
Why is passive Man-in-the-Middle measurement useful?
It preserves the real EV-to-EVSE interaction while recording the relevant layers on a common time base. Neither partner is replaced during the original field capture.
Why can communication traces alone miss an EV charging fault?
A communication trace alone cannot show whether the measured voltage and current match the values requested during charging.
In the anonymised comemso precharge case, communication timing appeared unremarkable, while the measured EVSE voltage response did not match the requested battery voltage. An experienced product specialist identified this relationship by reviewing synchronised electrical and communication evidence. This was human analysis of one vehicle–charger pairing; the account does not establish that all faults have the same cause or diagnosis time.
Can a suspected cause be tested before software is changed?
Yes, where a released live validation method supports the required controlled change. The purpose is to observe cause and effect before implementing a correction in the EV or charging station.
Real-pair investigation
Turn one charging failure into a controlled question.
Describe the EV, EVSE, observed behaviour and evidence needed to isolate the cause.