How to design and develop the eMobility Service Platform to manage interoperability?

After founding Solidstudio, Pawel was an originator in terms of pursuing expertise in eMobility. With the build-up of a solid knowledge-base on industry’s needs & wants, he now keeps a close eye on products’ development. He’s also hugely responsible for the business’ side and designs the business models for our products.

Paweł Małkowiak

When operating on the e-mobility market or considering becoming an eMobility Service Provider, the key is to identify and design the right flow. In this article, as a group of professionals developing such concepts, we want to share a verified methodology. This supports the setup of key components of major importance while developing a secure, stable, and functional eMobility Service Platform. We have already tested these principles and decided to share our insights, hoping some might find them helpful.

When deciding to operate in a booming e-mobility market, apart from doing extensive research - and taking the first necessary steps toward a feasibility study, it’s worth adopting some good, tested, and proven practices.

One of the efficient methods that prove that the solution will serve is 

. It’s the concept, widely used in IT, that helps organize the structure and language of software code matching the business domain. To develop the notable outcomes, there's Event Storming to offer a helping hand.

Note: Individual event names may differ (it's more of a naming issue), but the workflow’s general idea is always followed.

 , to generate a widely appreciated service, you need to set in the center the final user’s needs. Keep that in mind while Event Storming. The general idea is to think about each step that needs to happen seamlessly to the subsequent one. And how each must be secured to ensure the entire flow is stable and smooth. Before you start the discovery process, make sure all the participants are familiar with the methodology and necessary tools are provided. This will help develop a final roadmap for a proper eMobility Service Platform and guarantees a smooth flow of the workshop. You’ll need:

sticky notes in five various colors, it’s up to you which colors to choose

a large surface for modeling (e.g., A large sheet of paper taped to the wall works well)

step-by-step view of the process on an extra board for a clear overview of the Event Storming process

a lead person (facilitator) who will keep the entire process running smoothly

a group of people representing various domains, e.g., business, IT, marketing

The workshop can also be attended remotely. When the conditions do not allow participants to gather together in one place, the workshop can be conducted by distance. You can use a tool like miro in the digital variant - an online visual collaboration platform for teamwork that will solve the markers, post-its, and surface puzzle. The digital approach can also be seen as more environmentally friendly since we can create and edit each piece online without wasting paper. After all, the Event Storming outcomes must be digitalized, so the digital tool may be a good idea. Whichever variant you choose, each approach - remote or stationary - will be efficient.

Now briefly, let's clarify the roles of individual components.

Each color represents a different area. This is why diverse colors will help visually and logically picture particular subject areas. ‘True’ Event Storming purism 

 the colors for you, here we suggest the following:

Orange color - is used at the first step to define each event that should happen on the path to accomplishing the operation. Note: Events should always be described in the past tense, e.g., Invoice was generated, Charging has stopped.

Yellow color - used at the second stage of the storming to define ‘actors’ - people involved in an event or process. The goal is to recognize if external involvement is needed, e.g., Portal user, Support team member.

Purple color - being used at the third stage of storming, representing the system, external or internal, involved in the process. The objective is to highlight external involvement. e.g., Third-party API, Billing system.

Red color - represents the next step taken in the process - defining hot spots - indicating the lack of precise knowledge, doubts, or bullet points - a spot of disagreement between participants. The objective is to mark areas that need deeper insight, e.g., automatic price calculation, events order.

Green color - identifying opportunities - to specify areas where something works well and could be improved or space for fast growth. It can be a good support for the hotspot cards (red color), demonstrating a problem-solving approach, e.g., applying 

The lead person (a facilitator) guides participants through the process, keeps everything in order, and groups into aggregates.

The storming group - representatives of various areas: business, development, and marketing. The more diverse the group is, the outcome might be richer. Note: it’s not about the quantity, but rather the quality. And by quality, we mean the representation of different areas of business. The good idea is to make sure the most influential and knowledgeable people on the studied topic are invited. They are supposed to have some domain expertise (but seen from various perspectives). In this particular case, the idea is to meet IT requirements with business-related goals to provide an efficient, stable eMobility Service Platform.

Brainstorming: should take about 10-20% of the time, it is suggested to give participants ca. 15 minutes for individual work. Break: 5-10 minutes.

Verifying the ideas and backward walkthrough: about 60-80% of the time. You can make a short break about 5-10 min. between verifying ideas and backtracking events. Identifying Hotspots, commands, and actors: max 5-10% of the time.

Depending on the project’s size, in this particular case, working on eMobility Service Platform Functional Requirements, the Event Storming should take +/- one hour.

The actual storming phase starts when all needed components are set. The Lead (facilitator) should do a brief introduction to ensure all participants understand the following steps and outcomes. When it comes to brainstorming the eMSP, our outcome will be a service platform offering easy and secure access to the charging infrastructure. This is why the information board should be provided and handily arranged for the group.

In this phase, each participant defines events - all the steps that sequentially have to happen to complete the action. In our case, it will be to describe the user’s path to use a service - to charge an EV successfully.

Note: Participants should be familiar with the user’s profile - an EV owner who needs to charge the vehicle smoothly.

The Brainstorming starts with a brief individual defining. This should be a round of 15 min. Separately, all partakers are intended to distinguish the required steps. The aim here is not to specify each step, rather gather all interactions necessary for the flow.

After Brainstorming, the Lead (facilitator) asks each participant to present individual outcomes. This is the part when the group forms together with the roadmap. Identified steps can (and should) come up repeatedly. That’s ok. It shows common parts recognized individually. It also indicates that the group was selected properly and is familiar with the general idea of the flow that needs to be shaped. At this stage, because our team is diverse, each described actions may vary, depending on what area is represented. That’s perfectly fine.

Having formed the initial roadmap, the facilitator takes charge. With the storming group, the duty is to do the actual verification. A vital part of event storming, when developing an idea, is to begin from the end and backtrack event by event to check if no significant action was overlooked. The general scheme for backtracking is asking such questions:

What has happened before X?
Is X a consequence of Y?
Is there something more happening between X and Y?

Post-its in yellow, purple, red, and green color will be needed for the following steps.

Step three: identifying red spots, defining commands and actors

By analyzing and stepping back, the Lead (facilitator) with the group ask repetitive questions, like ‘are we sure this is all we need to complete the action?’, ‘is this step secured?’, ‘how will it be secured?’, ‘are there any other options available?’, ‘how do we want to handle the billing - externally or internally?’. The objective is to identify three areas:

Hotspots (here we suggest using red post-its - from a psychological point of view, red color is one of the most visible colors in the spectrum, has the ability to grab people’s attention instantly, hence is often used to warn of impending danger. For a good reason, the term ‘red flag’ is used to indicate warning signs)
When developing an idea, it’s good to indicate areas for improvement strongly. In our case, enhancing the emerging platform, to know what might be concerning. The sooner such areas are mapped out, the more time and resources will be saved when developing the project. If we identify a considerable number of such spots, it may also be a signal to consider engaging external agencies with specific domain expertise.

Commands & actors will need 2 extra post-it colors to mark commands like ‘execute payment,’ ‘issue invoice’, and actors, simply defining if the external or internal system is responsible for the command execution. This step helps decision making and provides extra insight into our roadmap. At this stage, we consider which parts of the process will be executed by our system and which will be on the side of e.g. CPO or payment system.

Having defined all requirements, the last step is to identify which area might be the biggest issue (causing the most problematic - interfere with the smooth flow of the overall manner, e.g., calculating the price, storing the CDR, executing the critical step when the process failed ‘no-show payment.’ At this point, again, each participant defines the area which they feel is a contentious one).

Note: Additionally, while identifying hotspots, commands, and actors, opportunities might be spotted. When we acknowledge we have the know-how or already witnessed similar issues and solved them, we can point out these opportunities, e.g., Areas where we can apply automation, or use a well-working, already tested solution (taking this step, you’ll need an extra post-it color).

When the Event Storming is done, it’s time to digitize the outcome. A well-conducted storming session should result in a roadmap, providing a sharp picture of what we want to achieve, obstacles we may encounter, and areas where we can recognize some opportunities.

Note: a key to reach any complete roadmap is to define at the beginning a clear goal. People tend to lose track when the scope is not specified enough. This helps to avoid the occurrence of insignificant events. This also explains why Event Storming needs a good Lead (facilitator). Keeping an eye on the storming’s smooth flow, focusing on a language, asking specific questions, detecting significant details and unclear aspects (e.g., marking hotspots), forming the main path and sidetracks.

The event is done, participants are tired but also satisfied after being creative, collaborative, and effective. After the storming, the domain architect steps in to discover and validate the subdomains.

Determining emerging subdomains cannot be omitted. There are dozens of heuristics and techniques for developing, and none of them are universal. Here are a few worth mentioning: company structure, domain expert division, domain expert language, business value, business process steps.

Event storming shapes our process, clarifying each step that must be taken to complete the session. As mentioned initially, on top of our service is the final user - an EV driver. Having the storming session done, subdomains defined, and the Big Picture, we can move more confidently to the next steps of the eMSP platform development. Successful execution of such a Storming Event will allow you to build a feasible timeline, identify areas that may be challenging, and help better estimate the financial outlay. In consequence - design and develop the eMobility Service Platform and drive interoperability.

Note: when having doubts about whether you will be able to carry out such workshops on your own, you can ask for guidance from an agency focusing on designing and conducting such events or a partner specializing in software development and domain support.

Psst! On the right, you can spot a box - drop your e-mail to check and verify a key eMSP Platform Functional Requirements.

List - eMSP Platform Functional Requirements

Research data, latest achievements, and statistics on e-mobility development

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

Research explanation of e-Mobility as a Service

Before the digital revolution and user-centric approach, the concept of accessible, new forms of transportation was the future vision of what life could be like. With the rapid growth of technology, mobile devices, enhanced battery capacities, wide Internet connection, investments in new unexplored forms of service delivery, and quick social adaptation in the last ten years we have witnessed a great transformation.

Raising enthusiasm boosted consumption and proved that rapid adaptation is possible and widely accepted. New economic models have begun to take into account sharing concepts and value the tangible benefits of such solutions. In a sharing economy, not used assets such as parked cars and extra bedrooms can be rented out. We transferred from owning to renting. And this concept widely approved first by Uber users moved to other transport areas offering new possibilities. In the Alternative Journal article, 

 , Ray Tumulty (2014) the sharing economy is described as a clearly urban phenomenon. To achieve economies of scale for shared economy services satisfactory population density is required. Moreover, these services are seen as an extra option, not a replacement for traditional sectors. Ridesharing is used along with public transportation in cities.

With the growing success of rented items and services, new forms of transportation options come to the market. The mobility concept grew to form a comprehensive ecosystem offering numerous moving variants, such as city bikes, electric scooters, car rides, ticket purchasing options, city traffic monitoring, planning the most convenient route, parking options, integrated payments, and available charging options for ‘e’ users. All available in real-time from the mobile app on one’s phone. This progress developed the term 

 , which covers a wide range of mobility services available on the market, and its integral part becomes a shared economy providing extra value for participants.

On a high-level, the MaaS ecosystem includes transport infrastructure, transportation services, transport information, and payment services. Within the ecosystem, the common objective is the delivery of a seamless mobility experience and transportation network improvement by utilizing the benefits of each service - public and private. Besides, other participants such as local authorities or data administration companies can collaborate to smooth the operation of the services and improve their profitability.

One of the MaaS ecosystem examples was presented by the Siemens Mobility Division in 2016 for Tampere City, Finland. The ecosystem is build of 4 main elements: service providers; a business-to-business (B2B) platform; mobility retailers; and the users. The intention of the project was to unite the existing and upcoming transport services with the operations of the local paratransit services.

A similar approach on a high level was presented by König project ‘Mobility As A Service for Linking Europe’. Four different levels define the public and regulatory level, the transport and logistics service providers level, the mobility service level, and the end-user level. On the basis of similar concepts and definitions, a framework for Mobility as a service was developed.

From a business perspective, MaaS is described by Kamargianni and Matyas in the paper ‘The Business Ecosystem of Mobility-as-a-Service’[1](2017) as ‘the wider network of enterprises that influences how a dominant company, in this case, the MaaS provider, creates and capture value’.

To support theoretical premises on shared mobility, a survey conducted by McKinsey&Company (2017) provides some insight into the consumer’s opinion on ride-hailing and car-sharing. Respondents were asked how their usage of ride-hailing and car-sharing services will change within the next two years. In both cases, over 60% responded that it will increase or increase significantly. Shared mobility is mostly favored in urban areas, but seems to be less attractive for running errands or multi-stop shopping trips.

We are an integral part of the next global transformation, where alternative fuels and green energy takes charge. The concept explained above has been extended with ‘e’ - a possibility to travel in an eco-friendly way, where ‘e’ stands for electric solutions.

Electric Mobility as a service combines Mobility as a Service (MaaS), Electric Mobility Systems (EMS), and Shared Electric Mobility Services (SEMS) [2]. As a concept eMaaS operates upon MaaS, where the last one became one of the complementary components. With that defined, all MaaS participants become, as a consequence, eMaaS attendees. Providing they offer electric mobility solutions.

Electric Mobility System (EMS) covers technologies (batteries, charging technologies, drivetrains, and EVs), infrastructure (physical and organizational of charging stations, electricity grid, information and communication technology), and users (manufacturers, suppliers, end-users, service providers, governments, and agents).

Shared Electric Mobility Services’ (SEMS) applies to a new economy implementation, where instead of ownership there is an on-a-need basis share connected by the technology with users and providers. SEMS replies to the environmental, social, financial, and transportation-related benefits that had already been correlated to emobility and shared mobility practice connecting both. Five business approaches are proposed:

Membership-based (e.g. e-bike sharing, e-car sharing, e-ridesharing, e-ride hailing, e-scooter sharing, e-bus sharing),

Peer-to-Peer(e.g. e-car sharing, e-bike sharing, e-scooter sharing),

Non-membership-based (e.g. e-car rental, elimousine rental),

For-hire (e.g. e-car/bike/scooter sharing, e-ridesharing e-carpooling),

Mass transit systems (e.g. e-Public Transport, airport autonomous shuttles).

As a part of a wider concept, combined with two other components MaaS & EMS, together provides multiple eco-friendly transportation possibilities. Successful implementation of such a concept requires multi-level support, well-designed system architecture, and an extensive network in public structures.

The user-centric approach will always be foreground. It applies to the development of the widely recognized concept of e-mobility as a service. From accessible payment methods for single ticket purchasing, subscriptions, to well-developed charging networks and various means of transport access. At each stage of the proposition should be declared value.

We are still in the early stages of what could be called e-Mobility as a service. Most customer journeys are under development, and achieving overall flow is still in its infancy. There is a lot of research to be done, but there is room for the general necessary approaches. Each of the participants, in order to achieve success and remain successful in this growing market, should remember the needs and behavior of the end-customers - have in mind that ½ users are likely to bail on service or purchase because of a single bad experience.

One of the success factors will be easy, integrated payments, giving preferable plan or demand models.

Plan option: Participants pay a monthly fee befitted to their transportation needs. Such plans can be split into an urban commuter, family, business, and casual. They include all public transport options as well as taxi, rideshare, carshare, etc, to cover individual needs.

Pay on-demand alternative: Paid as traveled with the difference that the payment is for the whole trip in one go independent of transport means. So if in need to take the train, bus, and then taxi on one trip, it’s all included in one, joint payment, executed automatically via smartphone.

Technology changed the way people consume goods and services. With handy devices, ¾ of consumers expect the service within five minutes from the initial contact. The same share wants ‘the simple experience’. From all players, customers expect immediate action, personalization, and convenience. This requires a broader view focusing on journeys, not only touchpoints, which will become a framework for further expansion.

When it comes to user preferences, whether it applies to simple app development or complex system design, it’s been always about developing a complete value proposition that answers the needs of the user and delivers a convenient solution. With a unique experience, trust, and the right technology that supports EV drivers, e-mobility participants can succeed.

E-mobility revolution driven by technology

The entire development of various e-mobility solutions is powered by rapid smartphone penetration. Since the handy device gives us access to countless possibilities, the way people consume goods and services changed. As a matter of fact, smartphones enable and will be a core factor for rapid growth in eMaaS concepts and Smart City solutions. Among the technologies being developed electric cars, route optimization resolutions, car-to-car communication will change the way we commute itself.

In search of efficiency, communication will become a smart blend of technology, infrastructure, and users. Electromobility and autonomous driving development are considered to be the catalyst for changes taking place in urban consumption. E-mobility secures eco-friendly and efficient vehicles on the roads. E-driving became globally a high priority. Climate change, oil shortage (Statistical Review of World Energy 2017 estimates that the world’s currently known oil reserves will last +/- 50 years given current levels of consumption), and air pollution brought forward the development of green solutions. As long as the power is received from renewable sources e-cars and hybrids represent the most efficient and environmentally friendly ways of driving.

Core components of business and technology are connectivity solutions, integrating components, user interface, infrastructure development, battery technology, driving software and product design, high accuracy maps, secure solutions, data storage and processing, between-vehicle communication. Well-developed services build upon a user-centric approach, providing integrated, smart, handy assistance.

According to a survey conducted by Otonomo [3] among the citizens of European countries, most car owners think that manufacturers collect their data for product improvement or development, advertising, segmentation driver types, and learning more about habits, reliability, usage, or preventative maintenance.

Consumers declare that they would love to have access to data generated by their cars. Three-quarters of survey respondents showed an interest in receiving data held by OEMs (Original Equipment Manufacturer) more than twice a month and nearly 50% of respondents would love to receive data frequently (even up to once a day).

Additional information consumers would love to receive are car alerting about dangerous conditions ahead (72%), early necessary maintenance and repairs detection (59%), car knowing the traffic and suggesting an alternative route (59%), an app that allows deliveries to be made to your car’s trunk (51%), car suggesting nearby, available parking (48%) and software that allows having fuel delivered (46%). So, not only drivers do not mind gathering information but also would appreciate receiving feedback and insights.

One of the widely appreciated models by the 2 billion consumer segment is car sharing [4]. Generation Y (born between 1977 and 1994) desires connectivity and convenience. Having numerous transportation options Millennials are more likely to choose on-demand services instead of ownership. New mobility service providers connect seamlessly drivers with passengers (carpooling, taxi) or passengers to cars (car-sharing).

The latter one, powered by technology and finest logistics, offers great value for one-way trips, as well as planned round-routes. Without bearing the cost and effort of car ownership Millennials can get a unique feeling of driving. The sharing economy provides favorite conditions with a blend of technology and service without exhausting the possibilities. Car sharing leads in big cities where scale effect is easy to achieve by, among other things, cost reduction and lifestyle changes. To confirm this, in 2019 Global Car Sharing market value was 2.5B USD (Global Growth Trends) and is expected to grow up to 9B USD globally in the next 6 years.

Car sharing quickly became outstanding among other mobility services thanks to a wide range of business models applied, offering different experiences and pricing systems. One of the success factors is the flexibility provided with usage areas and distances to be traveled. On the basis of a well-known car rental model, three concepts were developed: 

free-floating, stationary, and peer-to-peer car sharing

. The latter business model, where individuals can offer their car rental to private users via a platform, successfully conquered the French market. P2P offers long-distance transportation mode for longer routes and became an alternative for short-term rental or carpooling.

Allows to pick up the vehicle and return anywhere within a certain area, operates mostly in the city centers, usually providing smaller cars, in cooperation with local authorities providing dedicated parking spaces. When it comes to car sharing in a free-floating model, many providers see the investment as a strategic step, as a new promotional channel, and direct access to customers’ insights.

Free-floating business model success factors are:

location (high density to reach the scale),

cooperation with local authorities or private sector (e.g. in Poland IKEA offered dedicated parking spaces for Traficar as a part of yet another transport service), and

convenience (the majority of the fleet consists of city driving cars).

E.g. In France free-floating cars, according to a study by Les Échos newspaper, represent 26% of carsharing vehicles. Among these, 44% are electric. Free-floating electric car-sharing in Paris emerged in late 2018 with the following launches of Free2Move, Car2Go, and Zity. Over 1,400 electric vehicles were deployed across the French capital by these companies.

What is interesting, on the basis of free-floating, other urban transportations are offered, such as electric scooters, city bikes, e-bikes, and mopeds.

The oldest model with the start and endpoint at the same station, dedicated to round routes. With different needs, the lack of flexibility is being replaced with a wide fleet variety. Stationary car providers usually operate in smaller cities and rural regions. What is interesting, they do not operate globally (with one exception Flinkster by Deutsche Bahn Rent). Success is linked to extensive local market knowledge and customers' needs understanding. They often rely on other providers' cooperation, creating broader networks offering free-floating alike experience on a long-distance driving.

Key success factors in this oldest, but nourished with fine technology, are:

location in medium-sized cities and rural areas

availability (often located by the airports or train stations)

pricing based on hourly rates or distance

wide fleet selection for various purposes

Some global players see the opportunity in free-floating, e.g. in 2011 as a joint venture of BMW and Sixt established DriveNow, other invest in stationary car sharing, e.g. Volkswagen by investing took over 60% of Greenwheels in 2013.

In February 2020, Daimler AG and BMW announced yet another car-sharing services partnership under a new brand, 

 . By merging Car2Go and DriveNow, 'ShareNow’ became a market leader, being present in 20 European cities with a fleet of over 20 000 vehicles. ShareNow actually is a mix of both concepts mentioned - a combination of stationary car-sharing and free-floating. Various paths of car sharing are being tested, thanks to a broad range of possibilities offered by technology. In October 2020, Toyota launched its new car-sharing service to provide a wide range of mobility services for short-term use on the Japanese market. Based on these few examples we can only expect new services to be tested and developed. Combining traditional concepts with modern technologies may soon influence consumer behavior, look at certain aspects of e-mobility as well as create new businesses. Hence, the theoretical aspects of emobility presented earlier reflect the real changes.

P2P seems to be a niche market, is the only concept where private individuals offer their own vehicles. The exchange takes place via a dedicated platform, offering insurance and telematic equipment to provide smooth access. The car must be returned the same day within the pick-up area and used for round trips. The pricing provides a great alternative to car rentals or stationary car sharing. A decentralized fleet offers a wide range of brands and models.

Being called a niche, drivy initially operated in the French market, quickly converted to 

 , and operates now in the UK, Germany, Austria, France, Spain, Belgium, and the USA. Undoubtedly, the P2P car-sharing success happened due to most favored factors among consumers, similar to Airbnb, unique value combined with technology resulting in a great alternative to other, more traditional services. A prime technology - the platform and telematics ease the use. Thanks to one of the shared economy principles, P2P car sharing offers a diverse, accessible network, quickly spreading to new markets, providing value to each participant. Moreover, the P2P concept getaround is empowered by well-designed insurance policies to cover lending concerns.

The increasing traffic congestion in urban districts doubled with overloaded public transport facilities is boosting the car-sharing market revenue. The emergence of electric vehicles in public areas will be accelerating in order to reduce gas emissions. Attracted by extra benefits, such as incentives, 

 , parking spaces in exclusive, centered areas, providers will enhance the electric cars fleet.

Although the concept of car sharing is enthusiastically acclaimed this doesn’t mean that ‘ownership’ will go into a niche. Today’s consumer profile on the EV market is evolving from early adopters to mass adoption. According to a survey conducted by Accenture [5] in 2019 in China, Europe, and the US, respondents declared that they expect to own a car in the future. When asked if they would resign from possessing in favor of services, nearly 50% would consider giving up ownership in favor of integrated mobility services. What is more interesting in Europe, 55% of premium car owners and 41% of non-premium owners are more likely to switch.

One more factor may place a sharing idea further afield. A 

 conducted in June 2020 by cars.com showed that 70% of respondents declared the coronavirus has led to a reduction in commuting, and 49% reported their commute has been greatly reduced or become nonexistent. 58% who previously commuted via a public vehicle - carpool, taxi, ride-share, or bus - 44% of them said they’ve had a reduced the need, and 15% reported having no need to commute. 38% stated they usually rely on a bus to commute to work, 42% declared they’re riding less and 15% said they aren’t riding the bus at all. More than 55% of respondents actively consider buying or leasing a car, and 7% actually acquired a vehicle due to the pandemic. What is more, the pandemic became a reason to consider buying a car for 20% of respondents. The decisions were strictly dictated by the concerns about public transportation and the sanitation of ride-sharing vehicles.

Electric Vehicle market is going mainstream

Although the term electromobility or e-mobility applies to all means of transport powered by electric energy such as e-bikes or pedelecs, electric motorbikes, e-buses, and e-trucks we focused on e-cars. Several factors contributed to rapid EV penetration in Europe. From governmental declaration to achieve zero-emission goals by 2050, research and development, a wide range of possibilities to scale up fast provided by technology to raising environmental awareness. In this paper, we provide all the necessary information but starting from the beginning. Among the available options for electric cars, we have:

Hybrids (HEV) - Hybrid contains both an electric and combustion engine. The battery is charged via the engine while driving and stores the braking energy at the same time.

Plug-in Hybrid (PHEV) - The battery stores the braking energy in plug-in hybrids. Plus the car can be charged via the grid.

Range Extended Electric Vehicle (REEV) - is efficiently an all-electric vehicle, with all the motive power provided by an electric motor, but with a small internal combustion engine present to generate additional electric power. I.e. it might be viewed as a series hybrid with a much larger battery, namely, 10–20 kWh;

Battery Electric Vehicle (EV or BEV) - The vehicle is fully powered by the battery charged via the grid.

Two-way charging technology. When EV is charged, AC (Alternating Current) from the grid is converted to DC (Direct Current) power. Possible to be implemented by the EV’s owner or charger’s converter. What is more, this technology allows the energy stored in batteries to powerhouse/external load (V2H) or send it back to the grid (V2G).

Nothing new here, but some may not know that EVs wireless charging is possible. The vehicle’s battery can be empowered wirelessly by parking the car on a spot with a charger on the ground. Just like wireless phone chargers. Although, the amount of exchanged energy in these wireless systems notably outpaces a wireless cell phone charger, seems like a great challenge for startups developing them. These innovations must be 100% safe, certified solutions. One of the examples of a park & charge solution is Canadian startup ELIX.

A fully charged car in 20-60 minutes is possible, although the ultimate goal is to fully charge a vehicle in less than 10 minutes. Just like gasoline at the petrol station. For example, GBatteries is working on advanced super-fast charging technology without the influence of battery life. The pioneers like Tesla, ABB, ChargePoint, EVbox, and other OEMs and networks offer fast-charging stations. Among other obstacles associated with handling the huge power demanded, if not done correctly, fast charging can lead to faster battery degradation.

Similarly, just like power banks for mobile phones, startups are building portable charging systems for EVs. For example, SparkCharge offers stackable batteries that can deliver up to 60-75 miles per full stack and work together to deliver the exact amount of range needed.

Since the most comfortable ways of charging EV is still overnight, for those who don’t have a garage or access to any charging station nearby, British startup ZUMO offers a solution for those who own or want to own an EV but lack a driveway. They pick up the car, bring it to a charging station, and bring it back to the owner the following morning, fully charged and ready to go solving the issue of charging in big cities.

With the technology that uses copper coils embedded under roads and connected to the electricity grid, along with receivers installed under vehicles the dynamic charging is being in deployment in Sweden for E-bus with a Super- Capacitor battery and a heavy Duty E-Truck with a Li-Ion battery. Yet another EV charging resolution proposed by Electreon. Similar projects also take place in Germany and Israel. Recently Italy joined the testing phase with a one-kilometer examination section of the A35 highway between Brescia and Milan. If the pilot becomes successful the entire 62-kilometer (both ways will be approx. 150 km) length of the A35 freeway will follow.

This allows to intelligently manage EV charging by connecting it to the grid. Smart charging is all about connecting charging points with users and operators. Each time an EV is plugged in, the charging station sends information (i.e. charging time, speed, etc.) via Wi-Fi or Bluetooth to i.e. a centralized cloud-based management platform. Smart charging can provide additional data such as information about the local grid’s capacity and how energy is currently being used at the charging site (house, office building, supermarket, etc.). The gathered data is being analyzed and visualized in real-time by the software behind the platform. With smart charging, charging operators can control and regulate energy usage easily and remotely through one platform, or mobile application. EV owners can benefit by using a mobile app to monitor and pay for their charging sessions from anywhere, any time. Smart charging offers power-sharing, dynamic power-sharing, and power boost. It also allows vehicle owners, businesses, and network operators to control how much energy EVs are taking from the grid and when. For example, Wallbox offers such a solution. A wall-mounted box can be installed in a private garage or a condominium or company parking lot. Wallbox is being recommended by several electric vehicle manufacturers, e.g. Renault.

With the most common charging option on the market comes three main types of EV charging: rapid, fast, and slow. These represent the power outputs, and hence charging speeds, available to charge an EV. Each charging device type has an associated set of connectors that are designed for low- or high-power use, and for either AC or DC charging.

 enable to recharge an EV up to 80% in 20 min to 1 hour, depending on the battery capacity. With 50 kW DC charging is possible on one of two connector types using either the CHAdeMO or CCS charging standards, 43 kW AC charging on one connector - Type 2 standard, 100+ kW DC ultra-rapid charging is possible on one of two connector types: CCS or CHAdeMO. All rapid units have tethered cables.

The growing concept of e-Mobility as a Service

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

Open Charge Point Protocol migration from 1.6 to 2.0.1

Keeping IT systems up-to-date, even with basic tasks like dependencies or newly coming company-wide best practices is challenging. Even if all components are maintained in-house, it’s time-consuming to keep all areas updated. This applies also to keeping up-to-date external protocols our system uses. Whether we are integrated with Stripe over HTTP API, or with thousands of charging stations over OCPP, it’s good to know what the latest API version introduces. All this in order to examine if there are new opportunities upfront our business that can be supported by the newest version of the protocol we use. Or maybe our market requires covering long-waited, flow enabling updates. Let’s dive deeper into the new features introduced in OCPP 2.0.1 to see if it’s worth spending time upgrading your CPO platform.

OCPP 2.0.1 introduced business-oriented features but also technical improvements like device management or security. Those aspects are likewise very important, but this article gathers the latest OCPP updates focusing on the business angle.

More sophisticated support for smart charging is OCA’s (Open Charge Alliance) answer for a growing interest in this area. Energy cost fluctuates during the day. Also, the amount of energy available on different levels (charging station, building/parking, grid) changes according to the current consumption, production, and network capabilities.

Having that fact in mind we can use it to plan the charging process, buy cheaper energy for the end-user, and not overload the network. We need to know when energy is cheaper or the network load is too high. It’s out of the scope of OCPP, but once we have such information, we should inform the charging station how to apply it to finally reduce the cost of charging and limit network load.

OCPP 2.0.1 introduced business-oriented features but also technical improvements.

eMSP planning and development

30 JANUARY 2021 • 12 MIN READ