“Need ISO 15118 Plug & Charge Before Fleet Launch”: Is the Integration Request Scopeable?
Turn an ISO 15118 Plug & Charge request into a scopeable integration record by identifying vehicles, chargers, protocol path, certificate roles, backend, test environment and launch owner.
Signals to watch
- Vehicle and charging-station models and software versions are named
- ISO 15118 protocol path and certificate responsibilities are stated
- Backend, test environment and fleet-launch acceptance date are connected
An ISO 15118 Plug & Charge request is scopeable only when it connects five responsible parties—vehicle, charging station, mobility or contract service, charge-point backend and certificate/trust operation—to a named test configuration and acceptance date. “Need Plug & Charge before launch” is urgent language, but it is not yet an integration scope.
The reader is an EV charging software business-development lead watching charge-point-operator, fleet, charging-hardware and e-mobility developer Telegram groups the company intentionally connected and may access. The sought Signal is a team that needs implementation, certificate integration or interoperability testing. Seeing the post a day late can mean missing a limited test-lab slot or the vendor shortlist before a fleet launch.
First establish what Plug & Charge means in this request
ISO 15118 is a family of standards for the digital communication interface between an electric vehicle and charging equipment. Plug & Charge uses digital identities and certificates so participating systems can authenticate and authorize a charging contract after the cable is connected, without requiring a separate card or app action at the charger.
That is an end-to-end behavior, not a sticker on one component. A vehicle may implement one protocol path while a charger, backend or contract environment implements another. Public statements of support do not prove that two named products work together.
ISO lists ISO 15118-20:2022 as a published part covering second-generation network and application protocol requirements, including bidirectional power-transfer communication. CharIN publishes industry material about Plug & Charge, certificate handling and interoperability. These sources define the technical domain; they do not certify a specific fleet configuration.
The five-party responsibility map
Before discussing price, put an owner beside every row:
| Party | Evidence needed | Typical Unknown |
|---|---|---|
| Electric vehicle | model, model year, software and supported protocol path | feature enabled for this market or build |
| Charging station | model, controller and firmware | configured feature and certificate state |
| Mobility/contract service | contract identifier and enrollment workflow | who provisions and revokes contracts |
| Charge-point backend | operator, interfaces and charging-session handling | roaming, billing and error ownership |
| Certificate/trust operation | certificate roles, trust anchors and responsible operator | onboarding, renewal, revocation and test credentials |
One company may own several rows. That does not remove the interface between them.
Start with the acceptance event, then work backward
Ask what must be demonstrated before the fleet launch:
- automatic contract recognition for named vehicle models;
- successful authorization on named charging stations;
- charging-session record delivered to the required backend;
- expected handling of an invalid, expired or revoked credential;
- fallback when Plug & Charge is unavailable; and
- a result accepted by a named fleet, operator or integration owner.
“Works with ISO 15118” is not an acceptance test. “Vehicle model A on software B starts a session on charger C/firmware D, using test contract E, and the backend records the authorized session” is testable.
Give the event a date and time zone. If the only date is the public fleet launch, ask for the last integration build, lab test and acceptance-review dates. The day the vehicles enter service is too late to discover an ownership gap.
Identify the exact vehicle side
Collect the vehicle model, model year or build, software version and stated ISO 15118 capability. Ask whether the feature must be enabled or provisioned for the target market.
Do not infer support from the connector alone. A physical connector and a communication protocol are related parts of the charging system but not the same evidence. Likewise, a demonstration involving one vehicle does not establish an entire fleet’s software state.
If the fleet cannot name the vehicles yet, route the request to architecture discovery rather than an interoperability test quote.
Identify the charging-station and firmware side
Record the charging-station manufacturer, model, controller and firmware version. Ask who can change its configuration and load test credentials.
A product page may state a capability, but the deployed firmware and site configuration decide what can be tested. The charge-point operator must also identify the backend connection used during the test. Current public information cannot confirm a particular charger’s enabled functions or site settings.
Pin down the ISO 15118 path and certificate roles
Avoid writing only “15118 compliant.” Ask which standard part and implementation path the project targets, what the vehicle and charger already support, and whether the goal includes unidirectional charging, bidirectional communication or another defined function.
For Plug & Charge, map who handles:
- provisioning the charging contract credential;
- installing or delivering it to the vehicle;
- charger and ecosystem trust relationships;
- certificate renewal and revocation;
- test credentials versus production credentials; and
- operational incident ownership.
These are security and lifecycle responsibilities. A sales lead should capture the owners, not design the public-key infrastructure. PKI means public key infrastructure: the roles, systems and rules used to issue, validate, renew and revoke digital certificates.
Name the backend and commercial record
The charging session must reach the systems responsible for authorization, charging operations and commercial records. Ask for the charge-point management backend, mobility-service relationship and any roaming or settlement dependency the poster is permitted to disclose.
Do not promise billing compatibility from a vehicle-to-charger handshake. Authentication, authorization, session records, tariffs and settlement are connected but distinct concerns, with different owners and evidence.
Define the test environment before offering a lab slot
A useful test request contains:
- exact vehicle and charger versions;
- backend build or environment;
- test and production certificate boundary;
- network and site conditions;
- positive and negative test cases;
- log owners on each side;
- defect triage owner; and
- acceptance authority and date.
If hardware cannot reach the same site, state whether a conformance tool, hardware-in-the-loop setup or staged interoperability event is proposed. A lab or qualified technical team must decide which setup can answer the project’s question.
Composite example: urgent, but not ready yet
This is an illustrative industry case, not a real customer or result:
“Need ISO 15118 Plug & Charge across 40 fleet vehicles before launch on 1 October. Chargers are already installed. Looking for an integration partner with a test slot next week.”
Known:
- 40 vehicles are claimed;
- chargers are reportedly installed;
- requested capability is Plug & Charge;
- a 1 October launch and next-week test request are stated.
Unknown:
- vehicle models, builds and software;
- charger models, controller and firmware;
- ISO 15118 path implemented on each side;
- certificate, contract and trust operators;
- backend and commercial-service owners;
- installed-site access and logs;
- acceptance tests and decision owner.
The request is worth fast human review because it contains a count and dates. It is not ready for a fixed integration quote. Send the five-party map and ask for the exact vehicle/charger versions plus the person who owns test acceptance. If those answers arrive, a technical discovery or lab-slot conversation can be scheduled.
Completion standard
The Signal record is complete enough to route when it names:
- vehicle configuration;
- charging-station configuration;
- protocol and certificate responsibilities;
- backend, contract and fallback path; and
- test environment, acceptance owner and dates.
Unknowns remain explicit. Neither the group post nor an AI score establishes conformance, cybersecurity, legal compliance or production readiness.
TOP Prospect can surface and deduplicate these requests from Telegram groups a user intentionally connected and is authorized to access. It preserves original text, source, time, summary, reasoning and suggested verification action. It does not read private chats or unauthorized groups, contact the author, validate certificates or run interoperability tests.
Use the EV fleet charging qualification workflow for the upstream depot and load questions, B2B lead-intent stages to distinguish research from active vendor selection, and the Telegram business Signal workflow to send the record to a human owner.
Frequently asked questions
Does saying “ISO 15118 supported” prove Plug & Charge will work?
No. End-to-end operation depends on the vehicle, charging station, protocol implementation, certificate and trust-chain roles, charging backend, contract setup and tested configuration.
What is the minimum first question for an integration request?
Ask for the vehicle models and software, charging-station models and firmware, target ISO 15118 path, certificate or contract owner, backend provider, test environment and launch acceptance date.
Is Plug & Charge the same as plugging in and charging without identification?
No. In ISO 15118 usage, Plug & Charge relies on digital identities and certificates so the participating systems can authenticate and authorize a charging contract without a separate user action at the charger.
Can TOP Prospect confirm interoperability or certificate validity?
No. It can organize authorized group requests and rank them for review. Interoperability, certificate trust, security, billing and vehicle or charger compatibility require controlled tests and confirmation by the responsible technical parties.
