Vehicle Protocol vs Backend Protocol: Two Separate Stacks

A charger sits between two conversations that do not meet. On one side it talks to the vehicle about how much current to take and who is paying. On the other it talks to a backend about sessions, meters and remote commands. The two use different protocols, different data models and different certification regimes.

Buyers conflate them constantly, and the conflation produces some of the most expensive misunderstandings in procurement: a specification that requires a modern backend protocol in the belief that it delivers plug and charge, or a vehicle upgrade expected to fix a billing problem. Separating the layers makes each requirement checkable on its own.

Two Stacks, Two Jobs

The lower stack runs over the charging cable. It handles the physical connection, the safety checks before power is applied, the negotiation of charging parameters, and — in its later versions — the identity of the vehicle and the certificate exchange that allows automatic authorisation.

The upper stack runs over a network connection, usually mobile data or a site LAN. It carries what the operator needs: start and stop commands, transaction records, meter values, diagnostics, firmware management and configuration. It has no direct view of the vehicle. Everything it knows about a session, it learned from the charger.

That asymmetry is the key to the whole subject. The charger is a translator with its own opinions, not a transparent pipe. What the backend records is what the charger chose to report, in the format the upper protocol defines.

Between Vehicle and Charger

The older arrangement is simple and still universal as a fallback. A pulse-width modulated signal on the control pilot conveys a maximum current, the vehicle responds by changing a voltage level, and the charger closes its contactor when the sequence permits. There is no data channel in the modern sense and no identity exchange. Authorisation happens outside the protocol, through a card reader, an app or a manual release.

The high-level protocols add a data channel. ISO 15118 and its predecessor DIN 70121 carry a structured conversation over powerline communication: the vehicle identifies itself, the two sides exchange capabilities, the vehicle states what it wants, and the charger reports what it can supply. The exchange continues throughout the session, which is why the charger can see the vehicle's request rather than only the resulting current.

The later editions of ISO 15118 extend this to certificate-based identity, which is what makes automatic authorisation possible, and to bidirectional energy transfer. Both extensions require hardware and software that a charger built only to the earlier edition does not have.

This layer is where the vehicle's characteristics enter the system. It is also where a charger's own documentation usually states two separate things: which high-level protocol it speaks to the vehicle, and which backend protocol it speaks upward.

Between Charger and Backend

The dominant protocol here is OCPP, an open standard maintained by an industry association and implemented by charger manufacturers and backend platforms independently. It defines messages for authorisation, transaction start and stop, meter values, status notifications, remote commands, firmware updates and configuration.

Later versions of OCPP add device management, improved smart charging profiles and a more structured approach to composite schedules. The practical difference for an operator is how much control the backend has over when and how fast each connector charges, and how much of that can be changed without a site visit.

What OCPP does not do is talk to the vehicle. A backend supporting the newest version still learns about the vehicle second-hand. If the charger does not report a value, the backend cannot display it, and no amount of platform sophistication recovers it.

Compliance adds a further layer of confusion. OCPP conformance is certified for a charger against a defined version, and the certification belongs to that product and that version. It says nothing about the vehicle-side protocol, and it says nothing about how well a particular backend implements the same version. Two conformant products can still fail to interoperate on the optional parts of the specification, which is why integration testing exists as a separate activity.

Why Plug and Charge Needs Both Sides

Automatic authorisation, usually described as plug and charge, is a chain rather than a feature. The vehicle presents a contract certificate over the high-level protocol. The charger validates it against a certificate chain it trusts, and either authorises locally or forwards the identity upward for a decision. The backend confirms the contract is valid and can be billed.

Every link has to be present. A vehicle without a contract certificate cannot present one. A charger without the high-level protocol and the trust store cannot read it. A backend without the corresponding certificate handling cannot settle it. When any link is missing, the session falls back to a card, an app or a QR code — which is exactly what drivers experience on networks that advertise automatic charging and deliver it only for some vehicle and operator combinations.

This is also why the feature is unevenly available in practice. It depends on the intersection of three independently updated systems, and the intersection is smaller than any one of them.

Upgrading One Does Not Upgrade the Other

Four common assumptions fail for the same reason.

That a newer backend protocol delivers automatic authorisation. It does not, because authorisation travels on the lower stack. A charger can speak the newest backend version and still require a card.

That a vehicle supporting automatic charging works on any network. It works where the charger and the backend are configured for it and the operator has a roaming or contract relationship with the vehicle's provider.

That a firmware update to the charger adds a vehicle-side capability. The charger's side of the conversation can be updated. The vehicle's cannot, from the charger.

And that one certification covers both. Certifications are issued per product, per protocol and per version, and a certificate naming one layer says nothing about the other.

A well-specified charger states the two layers separately, and products in this range typically list a backend protocol version alongside the vehicle-side protocols they support. The 120 and 180 kW station specification does this, and the separation is what makes the two requirements individually testable.

How to Write This Into a Requirement

A requirement that cannot be tested is not a requirement. Four lines make it testable.

State the vehicle-side protocol and edition the charger has to support, and whether automatic authorisation is required on that interface. State the backend protocol and version, and whether conformance has to be certified or merely declared. State the fallback behaviour when either negotiation fails, because a site that silently drops to an unauthenticated mode is a revenue problem. And state what evidence is accepted: a certificate number, a test report, or a joint test with the platform the operator intends to use.

The last of those is the one that catches most projects. Conformance testing proves a product matches a specification. Integration testing proves two products work together. Procurement documents frequently ask for the first and need the second, and the gap only becomes visible after the hardware is delivered.

The relationship between these protocols and load management is close enough to cause its own confusion: a smart charging profile delivered over the backend protocol is an instruction to the charger, which then has to honour it within whatever the vehicle accepts. That interaction is treated in the note on load management, which describes where the instruction ends and the vehicle's own limits begin.

For most operators the practical consequence is a checklist rather than a redesign. Write the two protocol requirements on separate lines, name the version for each, ask what happens when negotiation fails, and test the combination before the site opens rather than after the first complaint.