However, the second (maybe bigger) problem is that its deployment has been resolved to confusing and difficult ways of managing data and services. In this article, I’ll try to demonstrate how EV Architecture 2.0 solves these issues and enables further sustainable and scalable growth of the software ecosystem around chargers.
So the first question is: how was it possible that a critical component became a problem?
As the EV industry has evolved, most charge station manufacturers have become increasingly opportunistic, sometimes also partnering with non-EV software companies, and creating large monolithic systems that is marketed commercially as a “complete turnkey solution”.
As my colleague in the e-mobility space, Patrick is often explaining:
“The result is buggy and vulnerable end-to-end solutions that do not scale. In start-up markets, they live off the fact that their customers don’t have to skills to distinguish between good and bad solutions and don’t have a clear vision yet of how their needs will evolve (so what will be important in the future). As the market matures there is less room to play for such solutions, but those that have already made this (wrong) choice continue to try to repair/fix/extend the intrinsically wrong architecture until they realize that this is a dead road.”
In this space companies such as ETrux (supplying smart energy solutions) or QVend (supplying smart payments for chargers) are locked/ pushed out because their services need to be integrated over and over again with the “turnkey solution” supplier. Conversely, the same supplier that deploys a closed ecosystem also pursues a monopoly over services. As a result, they may push for their own alternate services or cause delays. This limited progress on higher-level qualitative services created a problematic environment with very few options left for the beneficiaries.
Charging Architecture 2.0 is a disruptive innovation that addresses the architectural issues in this landscape.
To explain Architecture 2.0, I will use the example of traffic lights to demonstrate how the infrastructure elements are currently deployed.
Let’s consider a hypothetical system of a pedestrian crossing that had two traffic lights, A and B, on each side. They were managed by a software system called S1, built by a private company. When the municipality saw that more traffic was coming, they added another traffic light, C, managed by a different software system called S2. S2 only offered the C type of traffic light, but it could control the other lights, making it an attractive option for the municipality. Over time, the municipality wanted to improve the safety of the crossing by adding devices that used sound to indicate when it was safe to cross. The new devices, type D, were managed by a different system called S3, which was specialized in creating the best user experience.