Keeping electric car chargers online and up to date
An electric car charger is a public piece of equipment that people depend on, usually outdoors, often in a car park nobody visits daily. The controller inside it, very often a small Linux board, runs software that has to be updated: new payment or authorisation flows, protocol fixes, bug fixes, security patches. The hard part is doing that without ever leaving a charger broken.
Why a charger is different
A failed update on a website costs a few minutes. A failed update on a charger means a driver stuck with a flat battery and an engineer on the road. So the update process matters more than the update itself. Three properties are worth insisting on:
- Atomic switching. The new version is installed beside the old one and activated in one step. A power cut at any moment leaves a working charger.
- A health check before commitment. The new release only becomes the one to keep once its services answer correctly. If not, the controller returns to the previous release.
- Signed releases. The device verifies a signature before running anything, so only releases you published can ever run on a charger.
Roll out by site and by risk
Groups and tags let you update a depot before a motorway service station. Start with a small percentage, watch the fleet, then widen. You can also pin a particular charger to a release while an engineer investigates it, or hold updates on one device altogether.
tuna push chargers --notes "fix connector lock timing" --percent 10
tuna use 42 --percent 50Run the supporting services side by side
A charger controller is rarely one program. A typical release has the charge-point protocol client, a local database for sessions, and a small status service. Describing them together means they start in the right order and the whole set is rolled back together if one fails.
{"services": {
"db": {"command": "./db/run.sh", "cwd": "volume"},
"ocpp": {"command": "./ocpp/run.sh", "dependsOn": ["db"], "healthPath": "/health", "port": 9000},
"status": {"command": "./status/run.sh", "dependsOn": ["ocpp"], "port": 8080, "expose": true}}}Connectivity is never perfect
Chargers sit behind mobile modems and shaky Wi-Fi. A device keeps doing its job while offline, queues its reports and catches up with a randomised delay when the network returns, so a whole region reconnecting after an outage does not stampede the hub.
An audit trail for operators
Every release, rollout change and command is logged with who did it and when, which makes post-incident reviews and compliance conversations much shorter.