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.
Charging failure analysis reconstructs the event sequence across communication, low-level control and electrical behaviour. Separate PCAP files, vehicle logs and charger traces can expose the final error 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.
A passive Man-in-the-Middle path records the relevant layers at the physical charging interface on one time base. The real vehicle and charging station remain active partners, preserving the interaction that produced the problem.
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 correlates protocol messages, timing, low-level states, voltage, current and both partners’ reactions to identify the first meaningful deviation in the context of the charging phase.
Check whether the complete state is consistent.
Message direction, sequence, content and timing.
Connection, control, signaling and stop conditions.
Voltage, current, power transition and physical reaction.
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.
- 1Connect
Access the real EV and real EVSE at the charging interface.
- 2Capture
Record the relevant charging layers on one synchronised time base.
- 3Decode
Resolve protocol messages, state transitions, signals and timing.
- 4Correlate
Relate communication to low-level and electrical behaviour.
- 5Analyse
Identify the first deviation in the expected technical context.
- 6Validate
Test the suspected cause through one controlled change.
- 7Reproduce
Bring supported partner behaviour into a repeatable laboratory test.
- 8Reuse
Preserve the case for evidence, supplier alignment and regression.
Controlled validation and field-to-lab reproduction
Test the hypothesis before changing either product.
After isolating the initiating deviation, change only the condition needed to test cause and effect. A live gateway keeps both real partners connected; playback later reproduces supported 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.
Manipulating GatewayReproduce in the laboratory
Use Charge Playback where released to present recorded EV-side or EVSE-side behaviour to the device under test again.
Charge PlaybackStart 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.
Keep the synchronized measurement, applicable expectation, detected deviation, validation condition and resulting decision in one attributable package, linking the original event to 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.
Concrete hardware, software, interfaces, configurations and commercial system scope for the real-pair boundary.
Broader portable measurement, simulation and multi-standard field work.
CapabilityReleased standards-aware evaluation, timing analysis and user-interface proof.
CapabilitySupported live changes, protocol scope, limits and validation conditions.
CapabilityActive physical charging-partner reproduction, direction and release depth.
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.
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 the charging failure into a testable case.
Identify the real vehicle–charger pair and reproduce the reported condition. Decide which synchronised signals and measurements are needed to isolate the cause before selecting the analysis hardware.