A charge point looks like a simple connected appliance from the outside. Underneath, it's a payment terminal, a safety-critical power controller, and a fleet device that has to stay online in a parking lot — at the same time.
EV charging infrastructure gets scoped like a simpler cousin of consumer IoT, and that assumption causes most of the trouble later. A charge point has to negotiate with the vehicle's own charging controller, report state to a backend in near real time, handle a payment or authorization flow, and — critically — do all of this reliably enough that a driver who shows up at 11pm in the rain doesn't find a charger stuck in an error state. That combination of real-time power electronics, financial transaction handling, and public-facing reliability is a different engineering problem than most connected products, and it's worth treating it as one from the start.
The Open Charge Point Protocol (OCPP) is the dominant standard for communication between a charge point and its backend management system, and most commercial and public charging deployments will need to speak it — typically OCPP 1.6J over WebSocket for existing fleets, with OCPP 2.0.1 adding device management, smart-charging profiles, and improved security handling for newer deployments. Choosing which OCPP version to target, and how strictly to implement the optional feature profiles (smart charging, reservation, firmware management), is a real architectural decision — supporting only the transaction-handling core is far simpler to build and certify than supporting the full smart-charging profile set, and many deployments don't need the full profile on day one. Getting this scoping decision right early avoids a rebuild later when a network operator's certification requirements turn out to need a profile that wasn't part of the original design.
When multiple charge points share a site's electrical service — a depot, a multi-bay retail lot, a commercial garage — the system has to actively manage how much current each charger draws so the site doesn't exceed its service capacity. That's dynamic load management: monitoring aggregate demand and reallocating available current across active sessions in near real time, sometimes incorporating building load and on-site generation or storage into the same allocation logic. This isn't a reporting feature bolted on afterward — it has to be part of the control architecture from the start, because getting it wrong either trips a breaker or silently throttles every vehicle on-site to a fraction of its rated charge speed.
A charge point failure isn't like a smart-speaker outage — it's a driver stranded, sometimes far from another charger, sometimes on a schedule. Network operators increasingly track and report uptime as a headline metric, and that reliability requirement pushes design decisions upstream: cellular connectivity with local fallback behavior when the backend is unreachable, watchdog and self-recovery logic that doesn't require a truck roll for a routine fault, and remote diagnostics detailed enough that a support team can often resolve or at least characterize an issue without a site visit. Designing for "what happens when connectivity drops mid-session" has to be a first-class requirement, not an edge case discovered after deployment.
Public charge points that accept payment directly — as opposed to app-only or fleet-card authorization — bring PCI DSS scope into the hardware and firmware design. The cleanest way to minimize that scope is to keep card data handling isolated to a certified payment module and design the rest of the charger's firmware and connectivity so it never touches raw payment data at all. That isolation decision belongs in the architecture from day one; retrofitting PCI scope reduction onto a system that was built without it in mind is a significant rework, not a configuration change.
Charge point hardware sits at the intersection of power electronics, safety-critical firmware, and cloud-connected fleet management — treating it as any one of those alone under-scopes the project. See our embedded hardware work and cloud & device platform work for how we approach systems that combine real-time control with fleet-scale connectivity, and our energy IoT development work for how this fits into the broader distributed-energy picture.
Related reading: the physical hardware for outdoor, publicly accessible charge points needs the same environmental discipline covered in our note on ruggedized IoT hardware design, and a charge point exposed in a public location has the same physical-access security assumptions discussed in our note on grid-edge device security.
