Autocharge starts a charging session the moment the driver plugs in, with no RFID card or app involved. It predates ISO 15118 Plug & Charge and is far cheaper to deploy, which is why it's still widely used across Europe today.
What is Autocharge?
When an EV is plugged into an Autocharge-capable AC station, the charge point and the vehicle establish a powerline communication (PLC) link over the Control Pilot line. The handshake is SLAC (Signal Level Attenuation Characterization), the same one ISO 15118 uses to pair a station with a vehicle. ISO 15118 Plug & Charge carries on from there into a full EXI-encoded, certificate-based mutual authentication exchange. Autocharge stops one step earlier: the station reads the MAC address of the vehicle's PLC modem out of that handshake and treats it as the driver's identity.
There are no certificates, no PKI, and no back-office contract data exchange. The station uses a hardware identifier it already has the moment the cable is connected.
How the OCPP flow works
The charge point formats the MAC address as an OCPP idTag and sends it in an Authorize.req, exactly as it would for a scanned RFID card. From the request alone, the CSMS cannot tell whether the identifier came from a badge or from a vehicle's network interface. It is expected to recognize the MAC-shaped idTag because the driver registered that vehicle against their account beforehand, typically during onboarding in the CPO's mobile app, and it answers with one of the usual four statuses: Accepted, Blocked, Expired, or Invalid.
Two details make this format-sensitive in practice.
- Formatting varies by vendor. Some stations send the MAC with colons (AA:BB:CC:DD:EE:FF, 17 characters) and others strip them (AABBCCDDEEFF, 12 characters), and upper versus lower hex isn't consistent either. OCPP 1.6's idTag field is capped at 20 characters, so both forms fit, but a CSMS that only normalizes one of them will silently fail to match the other.
- An unrecognized MAC isn't a protocol error. It is the expected outcome for any vehicle whose owner never registered it for Autocharge. The station needs a deliberate fallback here, usually a prompt for an RFID tap or an app-based start rather than leaving the driver at a blank screen. That fallback is easy to leave untested until a real driver hits it in the field.
Why it's hard to test with real hardware
Reproducing this end to end normally means owning both an Autocharge-capable charge point and a vehicle whose PLC modem MAC is already known and registerable, then repeating the plug-in cycle for every status your CSMS is supposed to handle: Accepted, Blocked, Expired, Invalid, and the case where the CSMS is unreachable. That is a lot of hardware and a lot of physical plug and unplug cycles to exercise one idTag value your Authorize handler needs to branch on correctly.
Simulating Autocharge with SimItNow
SimItNow lets you set an arbitrary idTag on a simulated EV, so you can reproduce the exact request an Autocharge station would send without the PLC/SLAC layer below it:
- Configure a simulated EV with an idTag formatted as a MAC address. Try both the colon and no-colon forms, and mixed case, to check your CSMS normalizes them the same way.
- Connect the EV to a connector and confirm the charge point sends Authorize.req with that exact idTag. Then drive your CSMS through each response status (Accepted → StartTransaction proceeds; Blocked/Expired/Invalid → session must not start) and confirm the simulated station reacts correctly to each one.
- Use an idTag your CSMS has never seen to exercise the unregistered-vehicle path, and check that the fallback is what you actually want a driver to see.
- Combine this with local authorization list and cache configuration (see our authorization testing article) to see what happens when a previously-Autocharged vehicle plugs in again while the CSMS is unreachable.
You can run all of this with a CSMS, an idTag string, and a plug-in event, without an Autocharge-certified charger or a car with a known PLC MAC. Get started free.