Introduction
Having spent over two years developing various components for one of our e-mobility partners I want to share some insights on how to cope with challenges, what to expect from IT partners when developing e-mobility components and how testing various approaches can lead you to some of the breakthroughs.
Before you start, whether you are an aspiring Charge Point Operator or e-Mobility Service Provider, here you can find some valid questions, worth answering: Is there a ready-to-apply business model for long-term prosperity in the e-mobility segment? What return could be expected for now and in the future? What in-house skills are needed and what other partners require for revenue growth? Could technology and data analytics enable the business to provide ‘smart’ solutions? If yes, how? Where is the industry heading to and what are long-term goals?
What we face now, in the era of uncertainty, is another ‘revolution’ dictated by the exhaustion of fossil fuel resources, environmental pollution, and hence the transition to green energy. The EV market, especially in Europe, is growing fast and we face the increasing need for accessible, charging infrastructure, green energy demand, and a change in consumers’ behavior. With a rapidly rising demand for investment, we have a common ground - require a change in consumer habits. Even with rapid-charging technology (50kW+), charge time takes 20 to 30 minutes to reach 80% of battery capacity. But a well-known benchmark - refueling petrol or diesel experience is still out of reach. It seems that there is still a long way to go to achieve full flow, yet without constant development and improvement of the accessible infrastructure, we won't be able to move forward. Providing consumers the multitasking opportunity for rapid EV charging, whether combined with retail sites or bespoke charging 'lounges', together with a shift from a top-up (as opposed to refuel) mentality will be necessary to aid mass adoption.
Below you can find some thoughts on obstacles you may find while developing an e-mobility platform, what to take into consideration while creating a workflow, and what to expect when you start your venture into unexplored areas.
Our experience – what we have learned?
Creating a valid data model from the beginning will be a huge time-saver
Late changes to the data model are time-consuming. MVP or initial variants of the software cover all the basics. When the system does not require a sophisticated model of the charging infrastructure it may be enough to shape the whole charge point as a flat structure. Upon this simple model, more features can be built, till your range grows, and a need to open the platform using some open standard comes up. This action requires mapping development between the internal model and the one introduced by the standard. If the existing model does not support concepts (e.g. Location and Evse) and does not follow general standards, when it comes to the format of IDs, it might demand plenty of work to perform the efficient mapping.
While working for one of our partners, mapping their existing codebase to make it available for open standards, for a team of developers took several months. In fact, if the model would match the standard from the beginning, the integration would require just a simple action, and full integration would be possible within a few weeks.
Lesson learned from this experience: The time for full integration can be significantly boosted (reducing a few months of integration to a few weeks) thanks to the implementation of a ready-made code sequence linking the standard and the platform. Once the standard is properly applied, further action will become smooth and easy.
Creating an efficient architecture of the system from the start prevents many bad decisions
Some aspects of system architecture are specific to the domain. For example:
- deciding which processes are synchronous and which are asynchronous
- the decision of whether or not some data must be immutable
Understanding incremental improvements and having in mind that not every single aspect can be predicted is crucial. However, knowing the domain certain aspects can be included early in the design process.
Lesson learned from this experience: General concepts, but taking into account these limitations from the very beginning helps to avoid making wrong decisions when designing and developing the e-mobility platform.
Knowing the details of adopted standards is the shortest way to success
OCPI is defined as an open standard. In theory, everyone ought to introduce this standard in the same way.
Lesson learned from this experience: OCPI is not always the norm. Hub Gireve, for example, extends this standard. Some concepts exist and are not part of the OCPI documentation. Some OCPI partners require a certain sequence of specific actions that are actually not part of the standard. It is worth knowing this upfront when designing the CPO/eMSP end system.
The domain knowledge provides you with solving individual cases
Having the domain knowledge within the development team allows participating in specific direct business conversations about e-mobility. Becoming familiar with general concepts, e-mobility background (CPO, eMSP/EMP, EVSE, eMI3 ID, OCPI, OICP, OCPP), ubiquitous language, different market approaches (public/private/fleet charge points), we can immediately proceed directly with the specific business issues that are to be done, rather than technical details (as a reliable tech partner we already know them).
Lesson learned from this experience: We have learned that getting to know a specific area takes time, but once explored, it allows us to catch common parts. The observations turned into concrete e-mobility solutions, thus are an improvement for the future. Combining domain knowledge with high-level technical skills provides quick integration and unlocks business processes.
Team is everything
It might sound a bit cliche, but without having great, skilled, and curious minds on board I cannot say that the progress we witnessed would be possible.
Lesson learned from this experience: In addition to specific technical skills, in such projects where many questions are asked and actions require a constant search for efficient e-mobility solutions, the spirit of a truly matched team of individuals appears.
The lessons are learned – what next?
Knowing the challenges from the scratch, making observations, and drawing conclusions for the future on how we could boost integration, we have spent a couple of weeks developing ready-to-integrate components for Open Standards. Full e-roaming is possible to achieve faster.
- OCPI Gateway – The component being an Anti Corruption Layer between any CPO/eMSP system and any OCPI partner (hub like Gireve and p2p partners like other CPOs and eMSPs). The component has the whole OCPI registration process modeled with the token-based security mechanism. It maps all OCPI calls to the internal backend API (this part is open for modification for the concrete backend system).
- OCPI Test Platform – The component and test suite allowing to execute e2e tests of the platform using OCPI protocol. Testing OCPI allows a complete test of bidirectional processes that are part of OCPI.
- OCPP Gateway – The component is an OCPP server being able to connect to the charge point using OCPP (2.0.1) protocol. It is a proxy for the whole communication between the charge point and the CPO backend system.
- OCPP Virtual Charge Point – The component is a software Charge Point that allows e2e testing and monitoring of the CPO platform.
Soon our work will be done with this extra e-mobility component:
- OICP Gateway
You know what people say
When life gives you lemons… it is up to you whether you choose to make a lemonade or order the lobster tail. If you have any concerns while developing your e-mobility platform, need advice, or wonder which directions to take when setting up your next goals feel free to reach out. Here you can find some experience and knowledge, as well as ready-to-implement e-mobility solutions.