Examples
Examples
Four typical scenarios that come up again and again in second- and third-level support for EV chargers – and how I approach them.
These examples are synthetic: they describe typical scenarios, not customer projects. I do not name customers or fleets; manufacturers are mentioned for description only.
01
Typical scenario, not a customer reference
Intermittent offline periods with cellular connectivity
- Situation
- An EV charger with a cellular connection keeps dropping offline in the backend for a few minutes. On site there is never a visible fault; a reboot helps, but not for long.
- Possible causes
- Keepalive: heartbeat or WebSocket ping is sent too rarely to keep the connection open.
- The NAT timeout in the mobile network is shorter than the interval at which the charger sends data.
- The modem firmware loses the data connection without the charge controller noticing.
- Approach
- Correlate heartbeat gaps in the backend with device logs and modem status messages, separate patterns by network, time of day and firmware version, vary keepalive parameters in a targeted way.
- Result
- An evidenced root cause – for example a keepalive interval that is too long relative to the NAT timeout – with a containment action via configuration and a permanent corrective action in the firmware.
02
Typical scenario, not a customer reference
The charger works with backend X, but not with backend Y
- Situation
- A charge point works flawlessly with one backend. With a second backend it connects but never starts a transaction – or is not even accepted.
- Possible causes
- BootNotification is rejected or remains in “Pending” status.
- Negotiation of the WebSocket subprotocol (OCPP version) fails.
- Configuration keys or field formats differ from what the second backend expects.
- Approach
- Put the message flows with both backends side by side, check deviations against the OCPP specification, compare configurations.
- Result
- A list of deviations with a clear assignment: what changes in the firmware, what in the backend configuration?
03
Typical scenario, not a customer reference
Signed meter values are rejected after a firmware update
- Situation
- After a firmware update, the backend or the transparency software rejects the signed meter values. Charging sessions can no longer be billed.
- Possible causes
- The public key has changed or is transmitted to the backend differently.
- Format or encoding of the OCMF records has changed.
- Timestamps or time zone differ.
- Approach
- Compare OCMF records before and after the update, verify signatures against the registered public key, trace how the key reaches the backend.
- Result
- A clear statement of whether the charger, the update process or the backend configuration needs to change – and which existing records are affected.
04
Typical scenario, not a customer reference
Charging profiles are ignored after a reboot (§ 14a EnWG)
- Situation
- The grid operator limits the power. After a reboot, the vehicle charges at full power again until the backend resends the charging profile.
- Possible causes
- Charging profiles are not stored persistently.
- Validity period or stack level of the profile do not match.
- After start-up, the transaction begins before the profile is active again.
- Approach
- Analyse the timing of the boot sequence and charging profile messages, compare the behaviour with the OCPP specification and the requirements of § 14a EnWG, reproduce in a test setup.
- Result
- An evidenced root cause with actions for the firmware and the backend configuration.
What does a report look like?
A synthetic sample 8D report shows structure and level of detail, using the offline periods as an example.