We've been building OCPP-compliant EV charger firmware for several years now, across AC and DC platforms, for clients in Europe, India, and the Gulf. Passing the OCPP conformance tests is the easy part. Surviving a year in a Dubai parking garage — that's where things get interesting.

Design for offline first

OCPP runs over WebSocket. Persistent TCP connection between the charger and the Central System. Sounds reliable. Except chargers lose connectivity all the time: cellular dropouts, Wi-Fi interference from neighboring equipment, SIM billing issues, network maintenance windows.

When the connection drops, the charger has to keep working. People still need to charge. The spec says: cache all transaction messages and replay them when connectivity returns. Simple enough.

Except: how much storage do you allocate? What happens during a power outage while you're already offline? What if the RTC drifts because you can't reach NTP?

Our chargers have a 4MB QSPI flash partition dedicated to transaction journaling. Circular buffer, CRC-protected writes, power-loss-safe commit. Every meter value, every state transition gets logged. When power and connectivity come back, the journal replays in order. We've stress-tested this: 72 hours offline, 200+ transactions queued, zero data loss.

Smart charging is harder than it sounds

OCPP 2.0.1 lets the Central System send charging schedules — power limits over time. A garage with 50 chargers on a 500 kW supply can't let everyone draw 22 kW at once. Makes sense.

But the charger firmware has to balance three constraints simultaneously: the OCPP schedule (what the backend wants), local electrical limits (what the RCBO is rated for), and safety limits (what the hardware can actually handle at current temperature).

We use a three-tier priority system. Safety limits are hardware-enforced — firmware can't override them. Local electrical limits come next. OCPP schedule sits on top. The most restrictive limit wins. Always.

The charger reports its actual applied limit back to the Central System so it can redistribute power to other chargers. It's a feedback loop — and it only works if everyone tells the truth about their actual capacity.

Security isn't just TLS

OCPP 2.0.1 mandates TLS and introduces security profiles. Profile 3 requires mutual TLS — the charger and server authenticate each other. Good.

But the charger is a physical device sitting in a public parking lot. TLS protects data in transit. It doesn't protect the box itself. We've done security audits where we found: USB ports accessible through the maintenance panel, JTAG headers still populated on production boards, firmware stored unencrypted in flash, and default bootloader passwords.

Our production hardening: disable all debug interfaces, signed bootloader chain (secure boot), AES-256 encrypted firmware at rest, ATECC608B secure element for private key storage, and physical potting of debug headers. Every charger gets this. It's not optional.

Thermal design determines reliability

A 22 kW charger dissipates 500-800W of heat internally. In a Dubai summer, ambient is 50°C. Without proper thermal design, internal components hit 85°C+ and the charger starts derating — reducing power output to avoid damage.

The Central System sees a charger that delivers less power than expected, or faults randomly. It looks like a firmware bug or a hardware defect. It's usually thermal design.

We design for 55°C ambient, passive cooling where possible — aluminum heatsink extrusions integrated into the enclosure shell, chimney-effect ventilation slots. For higher power ratings, forced air with filtered fans. Every new design does a 72-hour thermal soak at 55°C ambient, full rated power, before we sign off on production.

The chargers that survive their first summer are the ones that were designed for it.

Key Takeaways

• Offline-first architecture with flash-based transaction journaling prevents data loss during connectivity gaps
• Smart charging needs a three-tier priority: safety (hardware) > local electrical > OCPP schedule
• Physical security matters as much as TLS — secure boot, encrypted firmware, potted debug ports
• Design thermal management for 55°C ambient. Everything else follows from that.