ISO 15118 gets mentioned a lot in EV charging, usually right next to terms like Plug & Charge, bidirectional charging, and V2G. That sounds simple enough until you look closer and realize people are often talking about three different things at once: a communication standard, a user feature, and a future energy use case that still depends on a lot more than one standards label.
That is why ISO 15118 confuses people. It matters, but it does not magically make every charger smart, every EV grid-ready, or every "V2G-ready" product part of a live commercial V2G setup. The standard family mainly covers how the car and the charger talk to each other. What happens beyond that depends on hardware, software, backend systems, and whether the wider market is actually ready.
Why ISO 15118 confuses so many people
Part of the confusion is that ISO 15118 is not one single document doing one single job. It is a family of standards for digital communication between the EV and the charging equipment. That includes identification, charging control, secure communication, and in newer parts also bidirectional power-transfer communication.
Then marketing gets involved.
A charger might be described as supporting Plug & Charge. Another product might be called V2G-ready. Another page might mention ISO 15118-20 as if that alone proves real two-way energy operation already works in the field. Those are not the same claim.
A more useful way to read it is this: ISO 15118 is the language between the car and the charger. Whether that turns into simple Plug & Charge or fully working V2G depends on how much of the rest of the system is actually there.
What ISO 15118-1 does
Part 1 is the map.
ISO 15118-1 gives the foundation: terms, use cases, general concepts, and the overall framework of the family. It helps define what the system is supposed to do and how the pieces relate to each other.
For a normal reader, this is the part that tells you what game is being played. It is not the bit making your charging session happen by itself. It is the structure underneath the later parts.
So if you see ISO 15118-1 mentioned, think: overview, definitions, intended use, and system logic.
What ISO 15118-2 does
Part 2 is the first big operational protocol layer in the family.
ISO 15118-2 is where the earlier practical implementation stack becomes real for many people. This is the part most often linked to the well-known idea of Plug & Charge: the car and charger can identify each other and manage a charging session with less user friction.
That matters because Plug & Charge is one of the best-known user-facing features enabled by the ISO 15118 family. But it is worth being precise here: Plug & Charge does not suddenly appear only with ISO 15118-20. In practice, most Plug & Charge discussions trace back to the earlier implementation stack around Part 2.
So if Part 1 is the map, Part 2 is the first serious operating language for the conversation.
What ISO 15118-3 does
Part 3 is the lower-layer plumbing for the conversation.
ISO 15118-3 covers physical and data-link layer requirements. That sounds dry, because it is a bit dry, but it matters. Before the car and charger can exchange meaningful charging information, there has to be a reliable lower-level way for that communication to happen.
You can think of Part 3 as the part that helps make the connection underneath the smarter functions possible. It is not the shiny feature people advertise, but without lower-layer plumbing, the rest does not go very far.
What ISO 15118-20 does
Part 20 is where the standard family grows up for bidirectional power transfer.
ISO 15118-20 is the second-generation protocol layer in the family, with explicit support for bidirectional power-transfer communication. That is why it gets so much attention. It speaks more directly to the future-facing side of EV charging: not just energy flowing into the car, but potentially back out again.
That said, this is exactly where people start oversimplifying. Support for ISO 15118-20 does not automatically mean real-world V2G is live, approved, interoperable, and commercially running everywhere. It means the communication standard has moved further in that direction.
That is important, but it is still only one layer of the stack.
Plug & Charge vs V2G-ready vs real V2G
These terms get mashed together all the time, and they should not.
Plug & Charge is about a smoother charging experience. The car and charger recognize each other and can handle identification and session setup more elegantly.
Bidirectional charging means power can move both into and out of the vehicle.
V2G means that outbound energy is specifically used toward the grid.
V2X is the umbrella term around several directions that exported power might go, including V2G, V2H, V2B, and V2L.
Then there is the phrase V2G-ready, which is where marketing tends to get generous. V2G-ready usually means prepared for future bidirectional functionality. It does not necessarily mean the whole chain already works in practice.
Real V2G means the whole vehicle, charger, power electronics, backend, and market or regulatory setup actually works together in the field.
A simple way to put it: V2G-ready means the door is built. Real V2G means the whole house is actually connected and working.
That is why "V2G-ready" can be a fair claim, while still being a long way from saying a homeowner can plug in tomorrow and start selling power back to the grid without friction.
Where OCPP fits into the picture
This is another place where people mix up layers.
ISO 15118 and OCPP do different jobs.
If ISO 15118 is the conversation between the car and the charger, OCPP is the conversation between the charger and the management platform behind it.
That means ISO 15118 helps explain EV-to-charger communication, while OCPP helps explain charger-to-backend communication. Once you see that split, a lot of product language becomes easier to decode.
And that is also where a platform like Plugchoice makes more immediate practical sense. Its positioning is around smart charging, integrations, APIs, Plug & Charge setup, and the software layer behind charger operations rather than around inflated promises that standards support alone equals live V2G everywhere.
For readers who want the operational side of this, the backoffice layer is often where billing, access control, monitoring, and charger management become real.
What this means in practice
For most people, the useful takeaway is not "Which part of ISO 15118 sounds the most advanced?" It is: what can this charger, this car, and this platform actually do together today?
A sensible checklist looks like this:
- Does the car support the relevant communication features?
- Does the charger support them too?
- Is there backend support where needed?
- Is the product being described as Plug & Charge, bidirectional charging, or actual V2G?
- Is "V2G-ready" being used carefully, or as a shortcut for "future maybe"?
That is also why smart charging and V2G should not be treated as the same thing. Smart charging can already do a lot without turning the car into a live grid asset. If you are comparing what is available now versus what is promising for later, it helps to separate everyday smart charging from full V2G ambitions.
For technical teams, the next step is usually less about standards buzzwords and more about integrations, APIs, and backend orchestration. That is where developers and platform-level architecture start to matter.
The honest summary is this: ISO 15118 is a serious EV charging communication standard, and it is absolutely worth understanding. But it does not remove the need to ask harder questions about compatibility, deployment, and what is actually working outside the slide deck.