The controller is where a charger stops being wiring and becomes a product. It runs the charging state machine, reads the meter, watches the protection interfaces, drives the contactor, manages connectivity and speaks the protocol.
That combination of real-time safety work and networked application work on one device is the central design tension, and how it is resolved shapes everything else.
What the controller must do
- Generate and monitor the control pilot, and enforce its state machine within specified timing.
- Read proximity where a detachable cable is supported.
- Drive the contactor and verify it responded.
- Read the meter and report energy accurately.
- Monitor protection interfaces and respond without waiting on anything slower.
- Manage connectivity across whichever bearers are fitted.
- Run the protocol client, including persistence and queueing.
- Apply firmware updates safely, with a path back if one fails.
Safety-critical and best-effort work do not mix well
Pilot timing and protection response have hard deadlines. Network traffic, protocol handling and firmware downloads do not. Running both on one core with a shared scheduler means the second can delay the first under load.
Designs resolve this by separating the domains, either onto separate processors or through strict priority separation with the safety path unable to be blocked by application work. Which approach is used is one of the defining architectural decisions.
The update path is a design constraint
A charger that can be bricked by a failed update is a charger that requires a site visit to recover. Preventing that requires storage capable of holding a working image while a new one is written, and a bootloader that can decide which to run.
That decision constrains memory and flash sizing, and it is difficult to retrofit because it is fundamentally about the storage layout.
Identity and secrets
The controller holds credentials that authenticate it to a backend. Where they are stored, whether they can be extracted, and how they are provisioned at manufacture are security decisions with design consequences.
A design where every unit shares a credential is easy to build and produces a single compromise that affects the fleet. Per-unit credentials require a provisioning process at end of line, which is why programming and security design are the same conversation.
Diagnosability is an architecture property
When a unit misbehaves in the field, what can be established remotely depends on what the controller records and exposes. A design that logs only errors cannot answer questions about sequences, and sequences are where intermittent faults live.
Deciding what to record, how much to retain and how to retrieve it is cheap at design time and impossible to add to a deployed fleet.
Thermal reality
The controller sits in a sealed enclosure alongside a contactor coil dissipating continuously, conductors carrying rated current for hours, and in many deployments direct sun. Component ratings must reflect the internal temperature rather than the ambient outside.
Designs validated in open air behave differently once the lid is on, which is why thermal validation happens in the actual enclosure rather than on a bench.
Buy or build
A manufacturer strong in enclosures, power paths and cables may reasonably conclude that the controller is the part to buy rather than build, because it carries the protocol maintenance obligation that never ends.
That is a legitimate architecture decision rather than an admission. What matters is that the boundary is defined: what the controller owns, what the surrounding product owns, and who is responsible when a fault crosses it.