Summary
Charging networks report uptime between 98.7% and 99.9%. Only around 71% of charging attempts succeed. Those two numbers measure different things, which is exactly why the gap between them is interesting: a charger can be powered on, connected, and reporting healthy while still failing to deliver electricity to a car.
One of the largest causes is not broken hardware. It is the car and the charger failing to agree on how to talk to each other, across public standards that every manufacturer has historically implemented separately. EVerest is the open source charging station firmware built to replace those separate implementations with a single shared one. The value is not that it costs nothing, though it doesn’t. It is that one implementation gets more reliable for everybody each time anyone fixes it.
Charger products from Zaptec, Qwello, Enteligent, Voltpost, NIDEC, Kathrein, Compleo, Amperfied (Heidelberg), SMA Solar, and Evonity ship on EVerest today or will be shipping soon.
Two numbers that measure different things
Uptime is the number the charging industry reports, and it is high. Networks put it between 98.7% and 99.9%. By that measure public charging is about as dependable as the grid behind it.
Success rate is the number drivers experience, and it is lower. Around 71% of charging attempts in the US succeed, according to ChargerHelp’s 2025 analysis, and that more than a third of failures occur on chargers appearing fully operational.
These are not contradictory findings and the difference between them is not a subtraction. Uptime asks whether the charger is powered, connected, and reporting itself available. Success rate asks whether a driver got electricity into a car. A charger can satisfy the first and fail the second, and when it does, the operator’s dashboard shows nothing wrong.
The trend is improving. J.D. Power’s 2025 US EV Experience Study found that 14% of EV owners had visited a charger and left without charging, improving from 19% the year before.
Reliability also decays with age in a way uptime does not capture. ChargerHelp found success rates averaging 85% at new stations and falling to 69.9% by year three. Hardware wears. So does the fit between a charger’s software and the vehicles pulling up in front of it, as new models, firmware versions, and protocol revisions accumulate across a deployment that will stand for a decade.
What sits between the two measurements is a conversation.
What actually happens when you plug in
A modern charging session is a negotiation, not a switch. Before any current flows, the car and the charger exchange messages to establish what each one is, how much power is available, what the car can accept, who is paying, and whether the connection is safe. That exchange runs over published international standards. ISO 15118 governs the car-to-charger dialogue. OCPP governs the charger-to-network dialogue.
The standards are public and identical for everyone. The software implementing them has not been.
Every charger manufacturer has historically written its own implementation. Each one resolves the standard’s ambiguous clauses slightly differently, handles unexpected responses differently, and times out differently. Each passes its own test suite. Put a car built against one reading in front of a charger built against another, and the negotiation stalls before power is delivered.
Operators report seeing this. In Driivz’s 2025 survey of charging network operators, respondents in North America and Europe were asked to name their top three causes of failed sessions. Vehicle-specific compatibility problems were named most often, by 45% of operators, with faulty hardware close behind at 42%. Charger-specific OCPP compliance issues were named by 39% and bad firmware updates by 33%. Because respondents chose three causes each, these are shares of operators rather than shares of failures, and they total well over 100%.
Two honest observations about that data. First, hardware faults sit only three points behind compatibility problems, well inside any survey’s margin, so this is not a story about software being the only cause. Second, it is a story about which causes are addressable at industry scale. A faulty contactor is fixed one charger at a time. A protocol disagreement between two implementations of the same public standard is fixable once, for everyone, if there is one implementation to fix.
Three ways to get charging software
Any company building a charger faces the same decision, and the tradeoffs are structural rather than technical.
Build it yourself. Full control of the result. It also means standing up a protocol engineering team permanently, because the standards do not hold still. OCPP 2.1 arrived in 2025. ISO 15118-20 added bidirectional charging. Every revision lands on your budget and your schedule, for as long as the product is on the market, to solve a problem your competitors have already solved.
License it from a supplier. Fastest route to a working product, with a single accountable partner and real depth of expertise behind it. The tradeoffs are structural: the software typically arrives as a binary, so your engineers cannot inspect or patch what they cannot read; new protocol support arrives on the supplier’s roadmap and price list rather than yours; and a charger installed today may outlive the commercial arrangement that supplies its firmware, leading to stranded assets.
Build it together. Share the implementation of the layer every manufacturer needs and none of them competes on. Nobody wins a tender because their charger parses an ISO 15118 message more elegantly. They win on power delivery, reliability, durability, design, and price. The protocol layer is a cost that every manufacturer currently pays separately for an identical result.

Image Courtesy of Pionix
What EVerest is
EVerest is an open source firmware stack for EV charging stations, hosted at LF Energy. It covers the vehicle conversation (ISO 15118, IEC 61851, DIN SPEC 70121), the network conversation (OCPP 1.6, 2.0.1, and 2.1), authorization and payment, energy management, and hardware drivers. It is licensed under Apache 2.0, so any company can use it, ship it commercially, modify it, and never pay a fee or a per-unit royalty.
The point is not that it is free. The point is that it is one implementation.
When a manufacturer ships a charger on EVerest, every interoperability problem that manufacturer finds and fixes becomes a fix for everyone else shipping on EVerest. Every testing event the community attends hardens the same code. That is a compounding return no single supplier can offer its customers, because no supplier can pool the field experience of its competitors.
The evidence is commercial rather than theoretical. Charger products from Zaptec, Qwello, Enteligent, Voltpost, NIDEC, Kathrein, Compleo, Amperfied (Heidelberg), SMA Solar, and Evonity ship on EVerest today or will be shipping soon. Over 70 organizations and more than 900 individuals contribute to it, making it the largest project in the LF Energy portfolio by contributor count. The U.S. Joint Office of Energy and Transportation actively supports the project. Pionix initiated it and contributed it to LF Energy and remains the largest contributor to the project, but the community is growing rapidly.
Why the next eighteen months matter
Three regulatory changes are turning charging software from an engineering preference into a compliance question.
Cyber Resilience Act reporting obligations began September 11, 2026. Since that date, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT. Full CRA application, including essential cybersecurity requirements, conformity assessment, CE marking, and technical documentation, follows on December 11, 2027. A charger manufacturer carries the manufacturer obligations regardless of whose software is inside the charger.
That distinction has commercial consequences. If you can read and patch your own firmware, CRA response is an engineering task you control. If you cannot, it is a support ticket, and your regulatory clock runs on someone else’s release cycle. The CRA also establishes a lighter-touch “open source steward” category for organizations providing sustained support to open source projects.
AFIR obligations continue to phase in across the EU, including ad-hoc payment requirements and the protocol support needed to meet them.
Bidirectional charging is moving from demonstration to product. ISO 15118-20 defines it. Whether a manufacturer can offer it depends on whether the capability is in their software and whether it is gated behind a separate license.
For a procurement team this converts an abstract licensing question into a concrete one: when the next mandatory protocol revision lands, who pays, and how long do you wait?
What to do with this
If you build chargers: EVerest is on GitHub with a software-in-the-loop simulator. You can clone it and run a simulated charging session on a laptop today, with no contract, evaluation license, or procurement cycle. That is the cheapest available way to test whether any of the above holds.
If you buy or operate charging infrastructure: ask your suppliers which protocol implementation is inside the product, whether you can inspect and patch it, what happens to your CRA obligations if you cannot, and what the next protocol revision costs you. You can also join the EVerest CPO Forum, a dedicated working group and exchange platform for Charge Point Operators, charger vendors, and contributors working with the EVerest ecosystem. It serves as the end user group for the EVerest project, creating a practical space where field experience can shape open development priorities.
If you work in policy: the interoperability failures drivers experience are partly a software fragmentation problem, and a shared open implementation of public standards is a market-structure response to it that requires mandating nobody’s product.
One implementation only stays strong if more than one company is building it. Every manufacturer that adopts EVerest and pushes its hardware bring-up work back upstream makes the shared layer harder to break for everyone who comes after, competitors included. That is an odd thing to find in a commercial market, and it is exactly why this works.
The gap between 99% uptime and 71% success will not close one charger at a time. It closes when the industry stops writing the same protocol layer separately and starts hardening one copy of it together. [/vc_column_text][/vc_column][/vc_row]