Expert Insights on Charging Architecture 2.0

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.

However, S2 offered a cheaper, basic solution for integration, and ended up managing the entire setup, resulting in cost savings but a suboptimal user experience. This put S2’s supply chain, development, implementation, customer support, and scalability to the test. If S2 failed, it could have catastrophic consequences. Unfortunately, this scenario is all too common, not just in the EV industry

‍

Let’s examine the same hypothetical system with the Municipality strategically choosing to incorporate a fundamental, standardized element rooted in Architecture 2.0 that delivers full visibility into the flow of data.

By adhering to the standard, all systems can send and receive data effortlessly, facilitating the management of separate concerns in an optimal way. For example, when one system indicates a color change, the others will adjust accordingly. All messages are standardized, making it easy to add another piece of hardware or system in the future with minimal costs. This allows citizens to benefit fully from all the configured services within an optimal timeframe. The use of a standardized element ensures a smooth and cost-effective integration of different components.

Although the initial decision may not appear crucial at first, it will undoubtedly yield long-term benefits as service quality needs to evolve and improve. For some, it may seem like a chicken and egg decision, but for others, it represents a strategic long-term vision versus a narrow and expensive one.

‍

How does Architecture 2.0 look for EV?

By replacing the hardware components A, B, C, and D with various charger brands and S1, S2, and S3 with different software components, like Charge Station Management Systems (CPMS), we obtain an accurate representation of the value proposition that ChargeBroker brings to the electric vehicle market. The following diagram provides a detailed illustration of this concept, demonstrating how different services can be stacked together to ensure the best possible infrastructure for electric vehicle charging.

‍

Once these (eco)systems are fully deployed, several critical concepts must be addressed, particularly when the managed fleet is divided among CPMS. Basic concepts, such as:

1. Data integrity,

2. The ability to switch between CPMS,

3. and Standard compatibility with charger-specific languages like OCPP or non-OCPP, must be addressed.

However, if the split becomes more granular and deploying only one CPMS for a specific charger group or segment proves insufficient, more advanced concepts are required, including:

1.Message routing strategies,

2.Data buffering to prevent data loss or enable playback,

3.OCPP-based roaming.

‍

Why the above concept enumeration is relevant?

It is important to underline that the existence of an Architecture 2.0 ecosystem for Electric Vehicles should not be solely attributed to message multiplexing, as this feature is only instrumental in enabling multiple Services to simultaneously access multiple Chargers. The fundamental aspect of seamlessly integrating chargers with services must also possess a high degree of transparency and extensibility to cater for current and future requirements. Therefore, an EV Architecture 2.0 system must be flexible enough to evolve with the EV standards (like OCPP) and adapt to the specific demands of the services it serves.

In conclusion, we have seen how Integration based on Architecture 2.0 principles is crucial in today’s challenges, using a non-EV example as a starting point. We have learned that these principles are beneficial not only for service providers in terms of competition and quality but also for end-users in terms of their experience.

In the upcoming article, we will delve deeper into some of the technical aspects of the concepts enumerated for EV Architecture 2.0. Stay tuned for further insights as we continue our fascinating journey together to build a superior EV software infrastructure for future generations.

‍

‍

‍