Check out our series of articles on e-mobility fundamentals and learn more about EVs' eco aspects.

Being an eMobility leader in various projects across multiple startups, Piotr was responsible for OCPI and OCPP integration as well as EMP and CPO platforms development. With extensive expertise in the open standards field and eMobility tech solutions, he is leading teams of experienced developers and contributing with invaluable knowledge and experience.

Piotr Majcher

Until now, we’ve been majorly focusing on the technical aspects of eMobility, especially in terms of the software solutions. However, it would be hard not to mention the ecological aspects of eMobility at some point, especially given the Earth Day was just a while ago.

The impact of electric vehicles on the environment is one of the most fundamental and widely discussed topics related to eMobility. It’s also the primary inducement of the broadly-promoted mass adoption and various governmental undertakings in the pursuit of it.

Certainly, at this point it’s to no one’s surprise that internal combustion engines, which have been at the forefront of transportation, account for inordinate amounts of pollution emitted to air via exhausts. With current, heavily climate-oriented stances, it becomes clear to many policymakers that the time to take action has come in full might.

In order to even start talking about the impact of EVs on the environment, it must be understood to what extent ICE (internal combustion engine) cars have previously affected it and why they are problematic.

The process of converting fossil fuels into energy through the burning of fuel in an engine causes several harmful byproducts, including 

carbon dioxide, nitrogen oxide, and other greenhouse gases

. These gases are released into the atmosphere, where they contribute to climate change, smog, and other environmental problems.

Despite a temporary decrease in 2020, caused by the pandemic and global travel downtime, the levels of greenhouse gases released by transportation account for (depending on the source and criteria) approximately 25-35% of all emissions, making the transport industry the biggest polluter, even given the record Covid19 decrease. According to Statista up to 41% of transport emissions come from passenger vehicles alone. That’s more than shipping and aviation combined (sic!).

With numbers of that scale, it’s pretty evident that the whole industry as it stands right now should (and most probably) will undergo massive changes towards more eco-friendly means.

Here is where the situation gets tricky. Namely, the entire eco-friendly aspect of electric vehicles (much like of any other type of vehicles actually) gets frequently questioned, over/under-estimated or even simply denied.  As a matter of fact, it would seem that each point of view has its rights and wrongs and the whole issue is not as straightforward as it may seem at first glance.

There’s certainly quite a bit to unpack here. As it must be remembered - looking at the environmental impact goes beyond just zero-emission driving. It also includes manufacturing, batteries and the charging process.

In terms of the way an EV is manufactured - there isn’t much difference to what it looks like with an ICE car. It starts with raw materials that are then being appropriately processed, made into components, transported to warehouses and finally assembled into finished products.

manufacturing an EV emits more emissions than an ICE car.

 Why is that?  It is mostly due to the production of an electric vehicle battery.

Let’s take a closer look at the batteries. EVs are charged and powered with the use of lithium-ion batteries. Lithium (much like i.e. nickel or cobalt) falls under the spectrum of 

. REE are being extracted from below the surface of the Earth. Mining of such, tends to be a rather polluting and difficult process. Amongst top lithium miners, some have already risen many controversies with their environment-damaging actions. This includes the Thacker Pass owned by Lithium Americas (Nevada, USA) or the infamous Nornickel mine in Russia, which had to pay a record 2.5billion fine for an Arctic oil spill.

In short, as much as it’s hard to find definite data and proven figures, the manufacturing of an EV seems in fact slightly less sustainable than it would be for an ICE car.

The good news around batteries is that currently a lot of work is being put into their energy-storage capacities. Second-hand batteries are being looked at as a potential new way to reduce the environmental impact of manufacturing. Reusable and recyclable, these scraps can be resold for use in technological innovations and become a great energy source or the fueling mechanism.

In terms of the utilization of an EV (aka driving) as much as it leaves no greenhouse gases, eMobility pessimists strike with THE question: There is no emission, but what about the electricity used to charge a car? It pollutes!

As much as it’s a valid point and equally valid question, the controversies and debates here seem to cancel out the even greater question: But what about the electricity needed for combustion engine cars, or more specifically what about oil extraction, doesn’t it need a tonne of electricity?

Yes, electric cars are not entirely clean. As much as driving itself emits no greenhouse gases, the electricity used to charge a car produces quite a bit of pollution (unless, of course, it comes from renewable sources like wind or water).

However, let’s briefly analyze what it looks like with ICE and EV cars. Here are some facts:

It has been previously established that the manufacturing process may be cleaner for ICEs.

It’s evident that driving an ICE vehicle itself releases quite a lot of carbon dioxide and other greenhouse gases.

Driving-based emissions are not the case for EVs

EVs pollute indirectly from electricity used to power them

If we stopped here, the match would be a tie-in game, as both options have their advantages and drawbacks. However, let’s look at the bigger picture - 

the electricity it takes to power an ICE car.

But combustion engines use fuel and not electricity!

Yes, however the electricity it takes to make fuel may shock some people.

Neither gasoline, nor petrol can be found naturally. They’re both produced from oil that is being extracted from the ground (usually rather deep). The oil comes from 

 through the use of electricity-ran machines called 

. For those who may wonder how many pump jacks there are in the world - data from 2021 saying that the market for them is estimated to grow from $3 billion to $5.2 billion in the span of just 10 years may put things into perspective.

Certainly most people know that apart from ground, the oil is also being extracted from under the sea by offshore drilling. It is said that there are currently close to 1500 

 around the world, these are being powered by generators using inordinate amounts of diesel per day.

The monthly electricity used to run oil-retrieving pump jacks and offshore rigs could most likely power an equivalent of a few million EVs. And that’s only on getting the oil out of the ground!

 which again use a lot of electricity on a daily basis. In cases, where the pipeline is of no use, the oil would be shipped via massive ships which often use the cheapest fuel to cut the costs, polluting the air into oblivion. (not-so-fun fact: current length of oil and gas pipelines combined is estimated to be enough to circle the Earth even 30 times).  The pipelines and the ships lead to 

 - where oil is heated up to 420 degrees centigrade in the refinement process - making the refineries the biggest polluters in the areas they are - not only in terms of electricity used, but also in terms of greenhouse gases emissions.

With that in mind, if all the electricity used to extract oil, transport it and finally refine, was to be put just to charge electric vehicles, the chances are that millions and millions of people around the world could drive EVs with the same use of electricity it takes only to make fuel.

What’s the point if the electricity is being used anyway? The point here is that EVs do not produce further pollution while driving as they do not require burning of all this fuel which transforms into hazardous greenhouse gases.

Ecological aspects of eMobility - post scriptum

The ecological aspects of eMobility are definitely a whole different level of task to handle in terms of the amount of data, knowledge and sources it takes to understand the bigger picture. And yes, they are not entirely clean even when charged with renewable sources of electricity, as the battery production left an environmental footprint anyway. However, it must be taken into account that as of now, there are no means of transport that cause no harm whatsoever on each level: manufacturing, utilization, source of power or waste management.

Although, it doesn’t mean that electric vehicles are worse or even equal to ICE cars. In times where more money is being put into renewables than ever, the energy gets cleaner and cleaner, all the introduced eco-friendly solutions (including EVs) are there for a reason and keep on undergoing massive changes for the better. We get to witness a transformation that’s bound to reach a level where fuel-powered vehicles are to be labeled outdated and deemed no longer of use, even if humankind is yet to find a mean of transportation that’s clean from start to finish.

Check out our series of articles on e-mobility fundamentals and find out more about EVs' eco aspects.

eRoaming Hubs explained

Get our comprehensive PDF packed with knowledge on eRoaming, hubs and protocols!

Certainly, roaming is something known to everyone at this point. However, what that has to do with eMobility?

Being a broad term for services allowing for connection outside of the usual network, roaming turns out to be an on-point solution for EV charging. With many players in the eMobility game (i.e. Charging Point Operators, eMobility Service Providers), some type of a connector is a must. Here’s exactly where eRoaming comes into play allowing for multi-dimensional connection between operators and EV drivers.

In short, eRoaming can be established via the use of hubs and protocols. A hub here can be an open platform which, after subscribing, can be used by many operators, who operate on common terms. This all happens in such a way that a certain charging pool introduced to a common hub can then be easily used by clients (EV drivers) of different providers. Such a solution allows electric vehicle users to charge their car across cities/countries with limited hussle.

In order to facilitate such a solution, the hubs developed their own open protocols, which are essentially responsible for the connection. They also define the functionalities of each eRoaming platform.

Amongst the existing hubs, we can differentiate three major ones. They all come with their own open standards and unify hundreds of CPOs and EMPs as well as millions of EV drivers.

The three biggest hubs and their protocols are:

(eMobility Inter-Operation Protocol - eMIP)

Apart from the proprietary protocols coming from hubs, it’s worth mentioning that there's also an independent one - 

Open Charge Point Interface Protocol (OCPI)

. It allows for eRoaming between the hubs as well as peer-to-peer connection.

To learn more about eRoaming, hubs & protocols, their importance and functionality as well as the future of eMobility - take a look at our exclusive paper covering all that needs to be covered on the topic!

Replay and transcript of eMobility Open Standards webinar.

Krzysztof is our Head of Products and he leads the technical development behind the suite of our ready-made solutions. Throughout the years in Solidstudio, he gained an invaluable insight into the eMobilty industry’s requirements and is now more than qualified to share his knowledge with others.

Krzysztof Ciombor

On October 14th Piotr Majcher and Krzysztof Ciombor led a webinar in which they discussed open standards applied in emobility. Below you can find a video recording of the presented use case, and a transcript for those of you who prefer the written form.

Unlocking eMobility platform using Open Standards - video:

Unlocking eMobility platform using open standards - transcript:

 Hello and welcome to our meeting about the emobility. We'd like to talk today about unlocking the eMobility platform using open standards. OK. Two important things worth sharing before we start. The first one is, as you can see in the topic, we'd like to talk today about 

, but not only. We'd like to also mention different approaches to unlock mobility platform, which are, for instance, OICP by Hubject. And other different protocols allowing to do the same, but in a different way. And the second important thing, we would like to show you, is that we are going to talk about the use case. It's not going to be a theoretical presentation. We would like to show you a step by step description of how we unlock mobility platform using open standards. Let me just quickly go through the agenda. We'll start from the short introduction and just off ahead, we'll go through the description of how we open eMobility platform using the open standards. We'll start from the initial state of the project. That was the point when we decided to introduce open standards to the platform. Then we'll go a bit deeper into technical details. We will describe the transition process and at the end of that part, we will tell you a bit about the challenges and risks. The last part of the presentation is about the results. So, actually what we achieved by opening the platform using open standards. I'm Piotr Majcher and I am a CTO and co-founder of Solidstudio. Three years ago, I and my partner decided to stop working as consultants and we started a software house.

 Now, apart from being IT experts, we are also focused on the EV market, especially in the field of the integration between different components and different partners in that market. Here with me is Krzysztof Ciombor. Krzysztof, can you say a few words about you?

 Yes. Hello, everyone. I am Krzysztof. I've been working with Solidstudio for almost two years now. I am the lead developer in eMobility project. I was primarily a backend developer specializing in JVM technologies and I particularly love the Kotlin programming language

 Thanks Krzysztof. Just let me add a few more things about us. So, why do we share these insights? We have been cooperating with one of the European EV leaders for two years and we have experience in developing both sides of this market. So we were responsible for delivering features normally recognized as something delivered by eMobility service provider. But we are also responsible for the development of the charge point operating platform, and we were involved in the integration between the partners using both approaches. So we were using open standards like OCPI standards and OICP, but we are also using custom APIs.

I'd like to show you a few numbers about the EV market now and in the future. I'd like to focus only on the first number. As you can see here, in 2018 in the UK, almost two percent of all cars sold were electric. I've seen quite hot Twitter news a few days ago that in Norway last month, more than half of the cars sold were electric. I think it proves that the movement of introducing electricity into transport is 

. And there's no question ‘if we should do that’, but ‘how should we do that effectively?’. Before we go to the technical description of our journey from closed to open platform...

 ...let’s talk a bit about the benefits of open standards. I'd like to start with the question. So the first benefit is business model optimization. The question I'd like to ask you is ‘what limits you and your company when making a decision about the integration with partners?’ We have a technical background, but we are working with sales and other business teams.

So how does it work? Normally, the ideas about integration with the partner are brought by the sales reps to the company. They have ideas, because they see some potential benefits from integrating with network parties. But before making the decision about integration, they have to know the time needed to deliver that. They have to somehow involve the delivery team, and in general, integrations with other partners are time-consuming tasks, because we have to remember about two things. If we are integrating with another company using a custom API, we are synchronizing two things. We are synchronizing models and we are synchronizing work of two teams working in a separate organization.

When it comes to the model, we know that the same things can be molded in a different way. For instance, one CPO (Charging Point Operator) may use only sockets and that's enough for their business. But another company may use a much more sophisticated model of charging infrastructure. They may use location, charge points, maybe electric vehicle supply equipment, connectors. And when we are doing the connection between those two different boards, we need to establish some common language. So we have to synchronize our models to be able to talk to each other. And the second point is synchronizing two teams and it's always challenging, even inside one company. My experience says that integrating using custom APIs is a matter of months, not weeks or days. The business knows the answer and that is let's assume three months. That starts during the calculation because they need to compare possible benefits coming from the integration of the partner with the cost of the delivery of such integration. And we just realized that in some cases, business decisions are driven by the cost of technical, by the cost of the delivery of the integration. That's, of course, not good.

Now, imagine a different scenario. Imagine that business doesn't have to ask tech teams about the estimation because they already know that integration with the partners normally takes four days. And for instance, there are some cases when no code has to be changed because everything is done on the platform. Such flexibility to our business can be brought by introducing open standards. The second point, our OCPs are also very important. And the point is our users. We believe that no matter what we are doing, so if you are the CPO, ESP (eMobility Service Provider), or as we are Solidstudio, a software house, users are the central point of our business. It's because scaling in most cases means that more and more users can benefit from our services.

So I’d like to start again from the question, what can make our users' life easier? According to the surveys, users are still worried about not having enough access to efficient charging stations. This is recognized as one of the most serious barriers to purchase EVs. Imagine that the user of the platform, which is not integrated with many partners, is somehow locked to the infrastructure provided. We can compare that to the situation of traditional cars. In order to buy gasoline, you are forced to look for the petrol station of the partner that you have a contract signed with. That's, of course, not a user-friendly approach. But by introducing open standards and by integrating more and more partners, with a quick integration, we can change that. And we can open as a CPO, our charge points to be used by any user on the market. And on the other hand, from the ESP perspective, we can allow our user to charge at any charge point. That brings us to that next point, which is, I believe, a long term goal for the whole market, so it's building a real European charge point network.

I think that the current state of the charge point network in the world can be compared to what we saw in the early years of electricity. There were a lot of small power plants and they produced energy without any kind of standards. Now we have one single grid in Europe and the end-user is not even aware of all those technical details under the hood. Any device can be plugged in and in any place in Europe and it just works. On the other hand, multiple power plants are also connected to the same grid. We can build the same type of experience by introducing more and more operators and mobility service providers into the same network.

I think that we can conclude the introduction now. And now we'd like to dip a bit deeper into the transitional process.

Initial state of the project - scattered, custom-made API

 Thank you very much, Piotr. OK, now we'll talk a little bit more about the technical details, starting with the initial state of the project, which we had a couple of years ago. And it was actually the point where we started to wonder if we can do better. We had many custom-made APIs exposed specifically to the partners that we were integrating with. And it quickly became apparent that this solution is not going to work for the future and it's not going to be maintainable. So let's start with the initial state of the project. As I said, we had multiple custom-made APIs. Those APIs were very limited in the scope of the data that we were exposing. Those APIs were only capable of exposing basic static data out to charge points, which means including the location data, for example.

But it definitely did not support full e-raming flow. And moreover, there were no real-time updates. So whenever a partner wanted to have the current state of the charge points, for example, they had to do it in a polling fashion, which is, of course, not very efficient. Also, we had multiple different APIs exposed to our partners. And as I said, this solution was not very scalable.

Main challenge with this approach was that we had to implement monitoring in multiple places in order to make sure that our APIs work correctly. We also wanted to have those APIs secured. But since we had contractual obligations different in the set up with every partner, we had to have multiple different security mechanisms in place, and we had to test every one of them independently to make sure it worked correctly

Finally, as I already mentioned, the maintainability was not so high, because any change done to our system would then need to be propagated and updated in every single one of those APIs. So, as you can imagine, this leads to an exponential explosion of the cases that we need to cover.

We need to make sure that we test them and we are exposing the correct things in production. And the biggest issue with that approach was also something that we already mentioned from a business perspective. Since we did not have the opportunity to create new integrations in short time This leads to scaling problems because we are only limited to a single user group, which are actually the users that have contracts signed directly with us. As, for example, CPO, use our touchpoints. And we can not extend this to a larger group of people that will be able to use our charge points.

So let's briefly talk about the transformation process and how we applied those changes from a technical perspective.

The transformation process itself is relatively simple. We first decided on the open standards that we want to use and then implemented the simple use case to confirm that the standard is really suited for our needs and we can actually implement it correctly. Then we added successive modules to enrich the API and exposed new functionalities. And finally, we achieved this huge milestone, which is the full e-roaming functionality.

This allows us to open our charged points to more external users and more external integrations. And this is like the full e-roaming functionality is beneficial for both the MSP (Mobility Service Providers) because the MSPs want to attract more users by having more access to more charging networks. This approach is also very attractive for CPOs because we want to increase the utilization of our charge points, and if we are exposing them to a much larger user base, and this means that the utilization will eventually grow, and our charge points will be used more and more. And finally, we can apply the testing and monitoring staff directly to these open standards and have centralized in one place.

As you probably are aware and you have probably seen this picture many times before, there are basically four open standards available on the current market. Of course, for the purpose of this presentation, we are focused mostly on the CPO and MSP connection, which may or may not include the clearinghouse in between. In this area, we have basically four open protocols which are widely used across Europe. This includes the OICP protocol, the Open Intercharge Protocol, which is a proprietary protocol, developed by Hubject, we have the OCPI, which is actually a peer to peer protocol, but it also can be used in a peer to hub fashion and this is currently maintained by the EV Roaming Foundation (previously, it was maintained by a Dutch company). We have the eMIP, the eMobility Interoperation Protocol, which is a kind of proprietary protocol developed by a GIREVE platform. They are a French market player and it also is a hub connection to their platform. And finally, we have the OCHP protocol. Again, to a clearing house and is maintained by the e-Clearing Net Foundation.

So even though those protocols are very similar to the functionalities they expose, like every single one of them allows you to do, the basic authorization exposes the charge information, has a possibility to get information about the session and CDR, and finally, support for e-roaming info. We still need to decide which bridge protocol suits our use cases the best. Having selected the protocol, we can continue with the step by step implementation.

It's important to realize that most of those protocols and in particular OCPI protocol allows us to do the integration step by step. What I mean by that is that OCPI protocol exposes so-called modules which can be implemented basically independently, and that allows us to start with a very simple use case. Then out successive modules along the way for the simple use case, we selected POI data sharing. This, even though it comes with the initial spike in the development effort, because we need to, for example, implement the credentials module in order to perform the full handshake flow.

After completing that once for the first partner, we can basically reuse the implementation for any successive integration with any new partner. And POI data is only about a single module, which in OCPIs the locations module. And in our OICP for Hubject, we can use EVSE data exchange in order to achieve basically the same result. So even though this process is simple, we can already see after completing that, we can already see the benefits, because we can expose to POI data, which can then be used, for example, for display purposes on external partner modules.

Having done that, as I said, we can continue with our successive model implementation along with the new requirements that come from new integrated partners and for this purpose. We can then start, for example, sharing the CDR if a partner is interested in that and finally complete the e-roaming milestone, which for OCPI I would include command sessions and CDR module and remote start-stop session for Hubject OICP protocol. By doing that, we can already start switching existing partners and deprecating the legacy integrations in favor of using open standards. This allows us to successfully remove those custom made APIs and centralize everything within this one open protocol. But that's not the end. We can push it even further and include additional modules like, for example, tariffs, token and charging profiles to improve this platform even more and expose more functionalities to our users.

OK, let's talk about the challenges or risk factors that we encountered along the way and explain what are the main problems and what you should be aware of? OK, so first of all, this is a brief overview of the challenges we encountered. The situation may be different for your company, but in general, we believe that those are accurate representations of everything that everyone is trying to use open platform struggles with. This includes actually a standard selection, many internal processes and data models to the open standards, applying some modifications and extensions to the standard, migrating to a newer version. And finally, the necessity of supporting multiple open standards and open standard versions.

First of all, accurate standards, selection, as we described. There are multiple standards available on the market. So it's important to realize which standard you should implement. This is, of course, dictated by two factors. If we want to achieve wide market coverage, we should probably support the standards which are used by most of the players on the market. But it quickly turned out that this is actually difficult to find out. And it may come only from experience or by, for example, being a member of this larger EV market or EV platform. For example, the EV Roaming Foundation, if you are a member, they may have some data about that. This is particularly important for OCPI where the latest version is 2.2, the 3.0 is in progress, but actually, the most used one is still the 2.1.1 Version.

Selecting the appropriate variant is also important,if you want to apply additional features that are needed for your company, like, for example, supporting the charging profiles and thus enabling the smart charging because this is available only in OCPI 2.2 and it's actually not supported in previous versions. So depending on the use cases in your company, you may want to implement a different standard.

When it comes to matching internal processes and data models to the standard, it comes in two ways.

So first of all, as we already mentioned, you for your purposes internally may model the data differently and the OCPI or OICP or any other open standard requires you to do so. That may need additional transformation/mapping layers in between your internal data models and the open protocol itself. So even though this representation you may already have in your system, in order to fulfill the open standards requirements, you will probably need to remap them to comply with the schema, when it comes to the process adjustments. This is particularly important for the CPI protocol, where this protocol is bi-directional. That means that it supports both a push and pull source. This is not usually the case for developing rest APIs.

For example, where it is mainly about getting the data and there is no active push. However, by doing the bi-directional communication, we achieve real-time updates where we can immediately push, for example, the EVs status change to our partners. And thus they can, for example, show it to the user if a charge point is available or not. I also want to mention the data quality, and this is a part of the processes adjustments since we want to ensure the best experience for both our integrations and our partners, but also for our users.

We want to make sure that the data we're exposing is actually of high quality, which includes, for example, checking the location data, if it's accurate, checking the street name, if correct, et cetera. So some partners are already doing that on their side. For instance, Gireve has their own team, which handles data quality. But for some integration, it is up to you to make sure that the data you're exposing is of high quality.

When it comes to standard modifications and extensions, this is again driven by both sides. It can be driven by us or it can be driven by our partner. What we mean by driven by us is that sometimes we actually want to expose more data than the standard provides. Imagine a case where you as a CPO have a platform for gathering telemetry data from a charge point, and you want to share it with telemetry data with your partner. But there is no property for doing that inside the open standards. If there is an agreement between you and your partner, you can proceed with extending the protocol and thus exposing more data for this particular integration. This is very useful in some cases, but the modification itself can be also driven by our partner, which is a very prominent case in OCPI 2.1.1 where there is actually a slight gap in the standard itself. Basically, there is no property to properly connect CDR to a session. So some partners are forcing you to adjust the standard and again. For Gireve for example, they introduced their own property called authorization idea, which they're using for these purposes. But it means that you will need to adopt the standard on your side and comply with those requirements if you want to integrate with Gireve when it comes to new standard migration.

So, as we already mentioned, the OCPI 2.1.1. version is the most widely used and adopted version on the market. Both version 2.2 Introduces some major changes, which, for example, enabled the smart charging, so you may be tempted to do the upgrade to the latest version. But this also needs to be coordinated properly with the partner you want to integrate with. And it's not always so simple.

Finally, we want to mention that there will be at least for the next couple of years it will be necessary to support several open standards for two reasons. The first reason is that those standards are constantly evolving and they serve different purposes. So if you want to integrate, for example, with Hubject you are basically forced to use OICP protocol. But the other reason would be to enable more peer to peer integrations. You would want to go with OCPI, but the reality for the next couple of years is probably that we either end up with this status quo where we need to have our support for multiple standards.

There are a couple of predictions that it may happen that there will be some kind of unification of the standards, and that will be one open standard. It's up to discussion whether or not this is a probable scenario. But if not, and if the open standards are there on the market, we may need to support them for the future.

So to conclude this section, we want to compare this current status with the status that we had before. So all of the issues we had previously are now solved. For monitoring, we have a single centralized place where we can monitor our APIs and make sure that we are not doing anything wrong. For security, it's not only about a single entry point but also about the unified mechanism where previously every single API of ours could be secured using a different mechanism like basic authorization. Some API can use authorization talk and now they're all forced to use the authorization mechanism provided by the standard. And finally, maintainability. And it should be pretty obvious any change applied directly in our system, can be updated only in one place and propagated to all our partners. It also includes easier testing because we can use some open-source testing tools. We can use interoperability tools to confirm that our APIs are working. Finally, there are also some events called plugfests where everybody gathers and tests their integrations all together to make sure that everything works. If everyone is speaking the same language, which is in our case the open protocol, they can communicate seamlessly and confirm that their APIs are working correctly.

 Thank you Krzysztof for taking us on a journey of opening the platform, using open protocols. I'm sure that this type of information would be very useful before someone decides to introduce open protocols onto their platform.

This is actually the last thing we'd like to share with you, and these are the results of what we did. And we needed four months in order to introduce OCPI into the charge point operation platform. And after that, we were asked by the business ‘How long does it take to integrate the next partner?’ and we estimated the effort to several days. It was about four days. It means that we reduce effort to integrate a partner by 95 percent.

I think that does answer the question that I asked you when we started, how to make our business not limited by the technology. Thank you. That's the end of our presentation and we still have the space for the questions. So if you have any questions, please, use the chart on the right side, and we will do our best to answer.

OK, so you see the first question from Chris. Could you briefly describe some main differences between, OICP and OCPI. How about the cost effectiveness of OCPI? Is it worth a shot? I think this is a question for Krzysztof

 Sure, I can try to explain. So the main difference between OICP and OCPI would be the connection type because OICP's strictly pure to hub connection and Hubject in this example. Where the OCPI is an open protocol which allows both peer to peer and peer to hub connection. Now, in terms of the properties that are exchanged through those protocols, the OCPI is actually more flexible and includes more data. This is especially important, for example, for the German market, where we need to have the signed meter values included in the standard for Eichrech conformity, which is a German specific case, but it's still needed for the open protocols when it comes to the cost effectiveness.

This is rather a question of what is your use case and how you want to integrate with the partner. If you can do a peer to peer connection and this suits you best, it's probably good to try the OCPI. But if you want to integrate the subject, there's no other way. And to use the OICP.

 Thank you Krzysztof. And I hope that answered the question. Here we have another question from Michael. Do you operate on your own network or do you support other networks in those integrations? Solidstudio is a software house and we are supporting our partners, who are looking for technical support. So we have an 

 so we know how to do that, but we don't have ours as a Solidstudio, we don't have our own network. Please let me know if that answers your question.

And we can go to another one from Adam. Question: What is the adoption of OCPI among EV charger manufacturers or suppliers? As Krzysztof mentioned, in order to know such details, we would have to be the member of some bigger organization, some organization that connects similar companies. We know that those four open standards that were presented are widely used, and we have an experience that since we introduced that OCPI into the company, we already have a few other partners that are willing to use that. We also have one partner that used our custom API and now is willing to switch. So I only can say that the adoption is quite, quite big, but I can't give you an exact number.

OK. And the next question: in your opinion, what are the missing features you would like to see in the future of OCPI versions?

 So first of all, I think the standard is relatively good for the cases that we are apparently trying to do, considering the whole EV market. But for the future, they would definitely need to be supported for the upcoming things like the new ISO 15118 standard, which is about the plug and charge functionality, which basically means that you can skip the whole authorization process because the car itself will be authorized within the charge point. So I would like to see OCPI supporting that, maybe not for the features of the OCPI, but I would really like to have a well-defined testing suit and maybe some testing plasma for OCPI because from our perspective, especially, the handshake flow is pretty tweaking OCPI and a lot of people make a lot of mistakes there. It would be nice to have it improved for future integration.

 Thank you Krzysztof. That was the last question we have for now. Let's wait five minutes more. And we have another question, from the US? Some are saying there are problems with PKI governance. Can you please discuss the role of PKI in OCPI?

So by PKI, I mean Private Key Infrastructure. So it's not included, at least in the version 2.1.1 OCPI defines the shape of the data that are replaced by their partners. So it's rather the definition of the in short, JSON's that they're sent from one partner to another and also defines something else. OK, so the concern is with the PKI in OCPP. Well, OCPI, but you know, OCPP. So OCPP is a bit above what is the scope of our webinar. So we are talking about the integration. OK. Sorry for interrupting, but I'm getting more and more information from Michael. So the first question was for the PKI in the context of OCPI, but it's in the OCPP. So is there a similar concept OCPP. OK.

 I would try to clarify that. I already mentioned that while telling you about differences between OCPI and OICP in version 2.2, we do have support for signed meter values which can be used to exchange those authorization data, and also assigned data through the OCPI protocol. As I mentioned, this is required for German conformity. But is still up to our partners to decide on the standard of the encryption and the key exchange, but it's technically supported in OCPI 2.2 but as far as I know, there are plans to improve these OCPI 3.0. I hope that answers your question.

 Thank you, Krzysztof for the support. OK. So if there are no questions. Please feel free to reach us out using our emails. If you have any questions regarding our presentation or in general if you'd like. If you are looking for support in those topics that we presented, do not hesitate to contact us. Thank you very much again for your time for being with us here. And see you next time, hopefully in the next webinar by Solidstudio.

Replay and transcript of eMobility Open Standards webinar. Click to learn more.

Unlocking eMobility platform using Open Standards - #OCPI use case

See our series of on e-mobility fundamentals and find out about the types of mutual connections

Knowing the industry complexity, at Solidstudio, we thought it would be a good idea to launch a series of blog entries on e-mobility fundamentals. The articles are to shed light on some of the topics that may not necessarily be clear to everyone.


This time, we’ll aim to unfold the differences between peer-to-peer connection and eRoaming via hub. The cases are certainly known to e-Mobility Service Providers and Charge Point Operators, yet even for them might pose some sort of a hurdle.

However, clear or not, such connection and its vise choosing remains crucial for all operational matters and defines the future way of working and conducting a business.

A peer-to-peer (abbreviated P2P) computer network is a distributed application architecture that partitions tasks or work loads between peers (here: partners).

A peer-to-peer network is a form of service where users can interact directly with each other and share data peer-to-peer instead of getting the data from a centralized server like in client–server architecture. In such scenario, two partners, connected via a peer-to-peer network, transfer data between them without running it through a ‘core system’. This means that they have to rely on each other to transfer the data.

It allows the partners to define the settlement's matters without third party impositions, which may speed up the data exchange process.

On the other hand, eRoaming uses a centralized system in order to connect multiple partners. With such a solution, the user agrees to a certain type of service offer and then authenticates himself to the central server (hub). The hub also charges a fee for the connection.

In this scenario, all the partners operate in a unified, mutually-agreed manner, which allows for a negotiation-free, seamless charging experience. It also opens the way for EMPs and CPOs to a bigger audience.

With eRoaming, the secret lies in the unification and interoperability, as all partners must agree on common terms. With the centralized system it is also more likely that the data exchange may take slightly longer, than when just two partners communicate with each other.

Now let's analyze eRoaming through a scenario: a user is connected to a company's central server, trying to download a file from another peer in the hub. The central server will send this peer the IP of a corporation and they will connect to each other.

Peer-to-peer vs eRoaming - the comparison

Before we get into details, let’s first compare the two in a very simplified way:

A peer-to-peer connection is like having two people in the same room that are communicating with each other. They both must have first got in touch and agree with each other that they’re willing to have a conversation. The conversation is then entirely up to them. eRoaming is like having one person in an enormous room with multiple people where they can reach out to everyone who is located in the same room. The person must have paid a fee to enter the room and signed a document stating the terms on which they can communicate.

Now let’s break it down in a more detailed way.

To begin with, it must be mentioned that peer-to-peer connection would turn out less costly, as it does not require a fee, unlike with the hub authorization. It also leaves out the necessity to rely on a third party and obey their mandates. However, it requires some negotiations and debates on finding the common terms with a partner as they are not strictly regulated.

With eRoaming the user gets access to a much bigger platform with multiple partners. This leads to a broader client base and more growth opportunities. From a CPO perspective such a solution allows i.e. to display their charging stations in other providers’ apps. For EMPs it gives many more chargers available to their customers. However, it comes at a price and integration matters that need to be handled.

From the consumer perspective, eRoaming may be a lot more attractive as it does not require keeping up to date with numerous providers, due to high levels of interoperability and unification. Such a customer-centric approach to a great extent explains the popularity of Hubject - currently the biggest eRoaming platform that is used by many operators. Given the ever-growing demand for electric vehicles and upcoming legislatives advocating for mass adoption, hubs will eventually become obligatory in ensuring a seamless, customer-friendly communication.

To see more on Hubject's integration and the business perspective you can check out our training session 

Check out our series of articles on e-mobility fundamentals and find out about the types of mutual connections