Take a look at the details of our exciting eMobility project!

Martyna Tonia

At Solidstudio, we had some great opportunities to collaborate with numerous - small and big - eMobility companies (and not only). Some of the finished projects can be found 

However, it’s high time we start sharing exciting news about projects and great partnerships that are taking place at the moment.

With that in mind, we are more than happy to announce that Solidstudio has partnered with Zeemcoin - a startup from Malaga, Spain.

Zeemcoin took on board a daring task of creating 

the first tokenized platform in the eMobility industry.

 technology making it more efficient and transparent.

This year it is intended that they also launch an app designed to connect EV chargers across Europe using roaming. Through an implemented Gamification Module, the app will contribute to collecting the Big Data in real-time which can be later used to improve the charging infrastructure for EV drivers in EU countries.

The collaboration will take place in the form of a s

 The big goal is to solve any quality issues with POI data (Point-of- Interest: data regarding geographical locations) as well as prop up the technical aspects with our extensive knowledge on both tech and eMobility sides.

The partnership will cover all kinds of solutions: from software upgrades, through app development to UX design.

Given the dynamic nature of the eMobility industry and foreseeable changes it’s bound to witness, we are thrilled to be part of such an undertaking.

To learn more about Zeemcoin and their vision, visit their website 

Solidstudio news! Strategic partnership with Zeemcoin.

See the final lesson of our comprehensive eMobility training on OICP!

Bartłomiej Łazarczyk

 is happy to introduce you to the Open Standards course led by our e-mobility expert - Bartlomiej. Throughout the following lessons, we will uncover the technicalities and functionalities of the OICP - a protocol developed by 

 - as well as business aspects for e-Mobility Service Providers and Charge Point Operators.

Such a knowledge-pack should serve everyone operating in the e-mobility industry as it unfolds the most crucial aspects of navigating through Open Standards utilization and many more!


Subscribe to our YouTube channel to make sure you don't miss out on the upcoming training entries.

CPO eRoamingAuthorization + eRoamingReservation

CPO eRoamingEVSEdata + eRoamingEVSEstatus

CPO eRoamingDynamicPricing + eRoamingChargingNotifications

EMP eRoamingAuthorization + eRoamingReservation

EMP eRoamingEVSEdata + eRoamingDynamicPricing 

Open InterCharge Protocol Training - Lesson 9

In this module we will briefly compare the OICP protocol with another very common and popular protocol called Open Charge Point Interface. We will also present a charging terminology and topology model commonly used in Europe. We will see how OICP and OCPI protocol fit into it. Open Charge Point Interface protocol supports communication between eMobility Service Providers and Charge Point Operators. This protocol is free to use and is developed and maintained by EV Roaming Foundation. Details of OCPI protocol will not be covered in this course. We will only compare it with the OICP protocol and point out the most important features.

OCPI protocol works mostly in the peer-to-peer communication model and hub model is also offered in the latest 2.2 version. OICP, however, works only as a protocol between different partners and the hub. That influences how you implement and integrate with those two protocols. In case of OCPI, you can start implementation almost immediately and test it against any other company solution. With OICP however, you can start to build a model and write some implementation but in order to fully test integration, you need your own QA environment and access to the Hubject platform. The next difference is modules vs services approach. In OCPI, you have multiple modules. Each module covers a complete functionality over a specific aspect, like i.e. charging sessions. The division of previously mentioned aspects is more granular. Therefore it is more flexible. OICP, however, operates only on a few services which cover only the most important issues in the eMobility world. The list of required services is not so big, so in theory the implementation should be easier. In practice you will need more services than it is required in order to be effective.

The next technical difference is how the operations are modeled. In OCPI you will use multiple http methods in order to perform specific actions for EMP or CPO. In most of the modules you are not limited and you can push your data as well as pull it from others. In OICP you will use only post http method in order to model push and pull operations. What's more? Those operations are not bi-directional and valid only for the specific role. For example; EMP can push authentication data to the Hubject platform but CPO cannot pull it. OICP protocol is definitely well defined, standardized and more mature. It's clear that Hubject does not allow us to do everything, but every exposed operation is easy to understand, easy to implement and covers most of the needs. The only drawback is that introducing any kind of change to the protocol is hard and takes more time. OCPI on the other hand is more flexible, due to its structure and EV Roaming Foundation policy. They've built a community which can suggest what kind of changes are necessary and what kind of solutions may be good to introduce in the future.

One of the most important differences we have encountered is connected with previously mentioned authentication data. In OICP, CPO cannot pull EMP authentication data from the Hubject platform. While in OCPI, CPO can pull it directly from an EMP partner. But why is that so important? Let's imagine that you've built a complex CPO platform which integrates with multiple partners with OICP, OCPI and some other protocols. You may have a situation, where some end customer would like to start a charging session under a charging point with an RFID card. You as a CPO need to validate if a given user is able to do that. Therefore, you need to authorize the request in some EMP partner, but how would you know which partner is involved? If you have EMSP authentication data, you can build a simple eRoaming table and know exactly which partner is involved. Unfortunately, OICP does not allow to pull EMP authentication data. Therefore, you cannot fully build that roaming table. If you receive a request and you do not know which partner is involved, you need to treat Hubject and its authorized request as a fallback and if you have other protocols with similar behavior as in OICP, you need to perform a broadcast in order to authorize the request.

The next thing is that OCPI offers more details about ongoing charging sessions which is a crucial feature for other EMSP partners. Also, basic smart charging functionalities are offered in 2.2 OCPI version, while OICP does not cover this topic for now. The last thing is strictly business related, OCPI is more flexible, therefore it makes it easier for you to build your own business processes and business model on top of it. You can define your own rules and use functionalities offered to you in many combinations. On the other hand, OICP is designed to be compatible with processes defined by Hubject, so sometimes you need to be compliant with them in order to integrate and use full of its potential.

Now, I would like to present to you a charging topology model which is standard in Europe. At the highest level, we have a charging pool which is basically a location of a given charging spot. Each charging pool may have multiple charging stations. You can think of them as a physical stand next to the parking spot. Each charging station may have multiple charge points which represent supply equipment needed for charging, i.e. we may have two parking spots next to the one charging station with two charge points. It allows both of the electric vehicles to charge at the same time. At the lowest level we have connectors i.e. type 2. Each charging point may have multiple connectors but only one can be used at the moment.

As you can see OCPI and OICP are not fully compatible with European standard. OCPI at the highest level has a location which can be related to the charging pool. Charging station level is omitted, so the next level is EVSE. EVSE in general is the same concept as a charging point, but as far as I recall there are small differences. At the lowest level we have connectors which are almost the same as for European standard.

When it comes to OICP, Hubject introduced a similar vocabulary to the protocol by adding charging pool ID and charging station ID, but those are just IDs. Location is still a part of an EVSE and is not separated out. Also, OICP does not have a separate model for connectors. Those are present as the plugs in EVSE data model and are not separated as an entity according to the european standard. My general advice is to use vocabulary and domain model from the European standard, because there is a probability it will become a mandatory standard in the future. Of course, because of those differences it might be quite hard to bring together those three models, so everything depends on your case. If you are a CPO, then it might be good for you to have a four layered model, because you can define different logic on each layer. But if you are an EMSP it might be quite hard to present all the data in an attractive form to the end customer.

Finally, I would like to present to you some good-to-know things. First let's focus on no delete policy and using full load operation instead. The main reason for using full load operation is because Hubject is versioning every data set that was pushed to their platform. Because of that, you can see exactly how the data has changed over time and you have a possibility to roll back to some old version of the data set. The next reason is because delete operation is not the soft type. It will not create any kind of event and it's hard to keep everything consistent. It's better to use full load operation to always update the latest data set of i.e. EVSEs. Worth mentioning is that Hubject agrees on 24 hours eventual consistency. Therefore, it's possible to perform one full load operation in the night and not delete a single EVSe once it will happen.

As I’ve told you before, direct communication with Hubject may be very beneficial, but only you will understand their API better, but they can also help you in more complicated ways. For example; by providing a custom API. Let's take a look at the case with lack of authentication data for CPO. We have talked with Hubject about this problem and it turned out that this operation was exposed before, but due to some problems and misunderstandings it must have been removed from the API. Maybe they can cooperate and unlock this functionality only for your specific environment if that's what you really need.

The delta pool last call parameter cannot be combined with other filterings like i.e. search center. According to Hubject documentation, there are some corner cases where it can lead to some data inconsistency on the EMP site, but we do not know more details. Nonetheless it's definitely worth remembering.

When it comes to pagination it's good to know that the default number of records provided in paginated data response is 20 records. The maximum number of records that can be obtained in one single page is 2 000 records.

Open InterCharge Protocole Training. Lesson 9

See the eighth lesson of our comprehensive eMobility training on OICP!

Open InterCharge Protocol Training - Lesson 8

In this service, EMP has its own operation which allows them to pull EVSE static data from partner operators. This can be done with eRoaming pool EVSE data operation. Its implementation is mandatory by every EMP partner. EVSE data model used in this operation was already covered before and does not differ. worth mentioning is that from OICP2.3 version response should be in paginated format. As we have seen it before, Hubject holds the last update attribute in every record that is stored in their platform. That allows Hubject to offer filtering functionality based on the LastCall attribute added in the request. LastCall is used for fetching only those data records that have changed compared to the EVSE state at the time of LastCall value. Besides the LastCalll, Hubject includes a deltaType attribute in the response which can tell what kind of operation was performed. Unfortunately, LastCall filtering cannot be combined with other types of filtering like search center, country codes and operator IDs. Request for eRoamingPullEVSEData includes many types of filtering parameters that can be used. The only mandatory attributes are provider ID and GeoCoordinatesResponseFormat. Most of the filterings are very useful i.e. you can filter by authentication modes, accessibility, renewable energy and few more. But probably the most useful one is filtering by SearchCenter which can be provided in order to return EVSEs with any specific radius.

Response for eRoamingPullEVSEData is a list of EVSE data records. Each EVSE data record includes the last update and deltaType attributes which were mentioned before. Return the list of EVSE data records is in the paginated format.

Similar as for eRoamingEVSEdata service, this service also has EMP dedicated operation which allows them to pull EVSE in dynamic data from partner operators. This is being done with the eRoamingPullEVSEStatus operation. Its implementation is mandatory for every EMP partner. It's worth mentioning that EVSE status records are grouped per specific CPO.

Hubject offers two additional functionalities for fetching EVSE statuses built on top of eRoamingPullEVSEStatus operation. The first one is eRoamingPull EVSEStatus by ID which is used for fetching statuses based on EVSE ID list. The second one is eRoamingPullEVSEStatus by operator ID which is used for fetching statuses based on operator ID list. Both of those functionalities are very important for EMP, because those filtering criterias are very useful in practice. In eRoamingPull EVSEStatus request only provider ID is mandatory, but you can also specify EVSE status and SearchCenter filtering. If you would like to fetch statuses by EVSE IDs, then you can provide a list of IDs under EVSE ID attribute, instead of EVSE status and SearchCenter filtering. If you would like to fetch statuses based on operator IDs, then you need to provide a list of IDs under operator ID attribute instead of EVSE status and SearchCenter. Response for eRoamingPullEVSEStatus request is a list of EVSE status records. Each list of records is grouped per operator ID under operator EVSE status. Unlike eRoaming EVSE data response, the data in this response is not paginated.

When it comes to the tariffs, Hubject offers EMPs a possibility to pull pricing product information specified by CPOs in their offers with eRoamingPullPricingProductData operation. Pricing product can be per specific EMP or offered to everyone. Hubject will verify if there is a valid pricing business contract between EMP and CPO before any data is returned. Returning functionality is also offered by providing elastical parameter in request. When it comes to the request of eRoamingPullPricingProductData operation, it's very simple. You need to provide a list of operator IDs, in other words a list of CPOsthat you are interested in and eventually you can provide the LastCall parameter for filtering.

As a response for eRoamingPullPricingProductData request you will receive pricing product data details for specific operator. As an EMP, based on that information, you only know what kind of pricing products a given operator offers. You still do not know yet how to apply them to specific EVSEs. That information is a part of the next operation.

eRoamingPullEVSEPricing operation allows EMP to know exactly how pricing products are assigned to EVSE IDs by CPO. Similar as in the previous operation, Hubject will verify if there is a valid pricing business contract between CPO and EMP. Request for this operation is very simple, you need to specify your provider ID as well as a list of operator IDs, which you are interested in. Also LastCall parameter can be provided for filtering.

Response for eRoamingPullEVSEPricing request is a list of operator EVSE pricing. Each object contains a list of EVSE pricing offered by a specific operator. Each EVSE pricing object has a list of pricing products that can be assigned to given EVSE. If that offer is specific only to you, you will see your provider ideas well in this object. In case data is available to everyone, you will see an asterisk character as a value for the provider ID field.

This service does not differ between CPO and EMP almost at all, but as a reminder - charging notifications allow EMP to know more details about ongoing charging sessions, which is crucial for their customers. Logic, data model and types of notifications are the same as for CPO related service. The only difference is that EMP must be able to handle eRoaming charging notifications request and return eRoaming acknowledgement as a response.

To sum up this part, we have covered all the services from EMP perspective. When it comes to the list of mandatory services and operations, we may divide it into online EMP and offline EMP. 

 must implement: eRoamingAuthorizedStart and eRoamingChargeDetailRecord operations. 

 must implement eRoamingGetChargeDetailRecord and eRoamingPushAuthenticationData. 

 must implement eRoamingAuthorizedRemoteStart, eRoamingAuthorizedRemoteStop, eRoamingPullEVSEData, eRoamingPullEVSEStatus. Of course online EMP may use eRoamingChargeDetailRecord and eeRoamingPushAuthenticationData operation in order to take advantage of the Hubject platform and make the whole experience better.

Open InterCharge Protocole Training. Lesson 8

See the seventh lesson of our comprehensive eMobility training on OICP!

CPO eRoamingDynamicPricing + eRoamingChargingNotifications 

Open InterCharge Protocol Training - Lesson 7

Now, we are going to look deeper into previously discussed services but from an EMP perspective. For most of the parts, it's the same as for CPO, but EMP also has some operations that are unique and specific only to them. Let's start.

Of course, the first operation in eRoaming Authorization Service is eRomingAuthorizedStart. Similar as for CPO, it is used for authorizing the charging process in the Hubject platform. Its implementation is mandatory for every online EMP partner. The data model and logic is the same as for CPO related operation, the only difference is that now EMP must be able to handle AuthorizedStart request and return eRoamingAuthorizationStart response.

The next operation is eRoamingAuthorizedStop - it is used for authorizing the stop of the charging process. Again, the data model and logic is the same as for CPO related operation. EMP must be able to process AuthorizedStop request and return eRoamingAuthorizationStop response.

eRoamingAuthorizedRemoteStart operation is very important for EMP. It allows EMP customers to directly start a charging session with, for example, a mobile application. Of course, implementation is mandatory by every EMP partner. Fortunately, the data model and logic is the same as for CPO operation. This time, EMP sends eRoaming authorized remote start request which must be processed by CPO and then CPO must return eRoaming Acknowledgement which is directly forwarded to EMP.

The opposite operation is eRoamingAuthorizedRemoteStop it allows EMP customers to directly stop a charging session with i.e. mobile application. Similar as for eRoamingAuthorizedRemoteStart, implementation is mandatory by every EMP partner. Also, data model and logic is the same as for CPO related service.

As we already know from the CPO authorization service, a CDR must be sent after the charging process has been finished. In order to be an online EMP, you must implement eRoamingChargeDetailRecord operation. EMP system must be able to handle charge detail record request and return eRoaming acknowledgement as a response.

But what happens when you would like to be an offline EMP? Or when Hubject tries to communicate with your EMP system but it fails and you cannot receive a CDR? In this case, eRoamingGetChargedDetailRecord operation might be useful. It allows EMP to pull CDRs data that was sent by CPO to the Hubject platform. EMP does not have to handle CDRs in real time, instead it can build some automated process on top of that operation. It's worth to mention, that EMP can pull CDRs in case real-time processing is not possible i.e. due to technical errors. eRoamingGetChargedDetailRecord request is simple. EMP must specify a date range, what can be done by providing from and to date values. EMP may also narrow down the result by specifying a list of session IDs. Also, it is possible to provide CDR forwarded which indicates whether the results should contain only those CDRs which were successfully forwarded to EMP or maybe not. response feRoamingGetChargedDetailRecord request is a list of eRoamingChargeDetailRecord. It's good to know that the data should be paginated.

If CPO offers eRoamingReservation service EMP may subscribe to it and offer its customers a possibility to reserve a charge point of given CPO. This can be done with eRoamingAuthorizedRemoteReservationStart operation. Information if chargepoint can be reserved is included in the value-added services field in EVSE data. Hubject must create a session for every reservation, because reservation may include some costs which are not strictly connected with the charging process itself. For example, it can be a fixed fee. The logic and data model are the same as for CPO-related service.

Second operation is already known: eRoamingAuthorizedRemoteReservationStop. It allows EMP customers to end existing reservation. After finishing a reservation, CPO must generate a CDR for a session that is connected to a given reservation. Again, data model and logic is the same as for CPO related service.

This service and eRoamingPushAuthenticationData operation is dedicated only for EMPs and its implementation is mandatory for every offline EMP partner. Hubject offers a possibility to push authentication data by EMPs to the daily platform, in order to optimize the full authentication process. For an offline EMP that's the only way for their customers to authenticate, therefore this operation is mandatory. For an online EMP you can use push authentication data to optimize the process, but you can have real-time authentication data processing available at the same time. Similar as in other services, update and delete is done with an action type field. Hubject will also keep history of all authentication data records in their platform.

In eRoamingPushAuthenticationData request, you must provide a provider ID together with a list of authentication data records. In each authentication data record you may specify multiple options for customer identification, for example it can be identification by RFID card or by QR code.

Open InterCharge Protocole Training. Lesson 7

See the sixth lesson of our comprehensive eMobility training on OICP!

Open InterCharge Protocol Training - Lesson 6

Tariffs and pricing issues are very complicated and hard to model. Tariffs may differ depending which aspect is concerned. Going from top to the bottom: we may have an end user which has an individual contract with EMP. EMP can offer him favorable rates under specific conditions, but of course it depends on the charging infrastructure and fees that EMP would like to charge. In order to offer charging infrastructure to end customers, EMP must have a contract with CPO, which can specify different rates than those offered to the end users. Of course, CPO may specify different rates per EVSE, their location, per day time and of course different rates per connector type. This is just a big picture overview and a small presentation of dependencies. In practice, each partner may have its own individual business model and settlement model

Comparing the Hubject model to the model that was presented before, Hubject aims to create a common tariff interface for CPO and EMP by having a specific pricing product within a service offer that EMP can subscribe to. OICP was not designed to cover end user tariffs. Their pricing product interface should be so flexible to cover different pricing depending on charging infrastructure i.e. different rates for type 2 connectors. This solution comes with a trade-offs. If you would like to integrate with the Hubject platform, it would be harder for you to create your own business model, especially as a CPO.

Besides standard pricing and product pricing which were briefly explained before, Hubject created the flexible pricing which allows CPO to offer differentiated pricings in many dimensions. It can depend on charging facility, location, daytime and combination of all above. All of those conditions are in the form of pricing product, which can be assigned to EVSE’s. Flexible pricing offers an API which is clear and understandable between both of the parties. On top of that, Hubject also created dynamic pricing, which enables for almost real-time updates between CPO and EMP. Unfortunately, because of its nature, dynamic pricing cannot be offered to everyone. It must be a bilateral offer. CPO and EMP must agree on business and legal specifics and their system must be prepared on such frequent tariff updates for just one party.

eRoamingPushPricingProductData is an API operation that allows CPO to upload pricing product information. In order to do that, CPO must create flexible or dynamic pricing in authorization service offer. It can be offered to all or per specific EMP. Of course, Hubject will check if there is a valid flexible or dynamic pricing before accepting the request. Hubject will also keep history of all change data records similar as in other services.

eRoamingPushPricingProductData request contains a lot of information about pricing. “PricingDefaultPrice” is quite obvious. It's the default price for a charging session. “AdditionalReferences” can be used for specifying additional pricing components, like start fee, parking fee, fixed fee or minimum/maximum fee. “IsValid24Hours” is self-explanatory, but you need to remember that it is assigned to pricing product not EVSE. “MaximumProductChargingPower” is expressed in kilowatt hours. “PricePerReferenceYouNeed” is a price per reference unit, in our example per hour in product price currency in our example in euros. “ProductAvailabilityTimes” specifies when exactly a given pricing product can be applied, for example it can tell specific begin and end hour of weekday.

Second operation to perform in eRoaming Dynamic Pricing Service is eRoamingPushEVSEPricing. It is used for assigning specific pricing products to EVSE IDs. Hubject will verify if service offer was created before and if pricing product can be assigned to EVSE. Hubject will also keep a history of all changed data records.

Request for eRoamingPushEVSEPricing is pretty straightforward, you need to provide a list of EVSE IDs and then provide a list of products that should be assigned to giving EVSE.

eRoamingChargingNotification is optional, but it's very important from an EMP perspective. It covers charging session functionality similar to a session module in OCPI protocol. In general, Hubject treats any kind of event that can happen during charging as a notification. Each notification may reflect various actions i.e. charging session started, update meter value, charging session ended and different kinds of errors that can happen during charging. Hubject will forward every notification received from CPO directly to the interested EMP. That allows EMP to present more details regarding the charging session to his customers, therefore it's very important for him to receive such kind of information.

Successful authorization and plugged cable does not necessarily mean that the charging process has started and energy is flowing. OCPP protocol which covers communication between chargepoint and chargepoint operator finds a lot of scenarios for charging session start, which must be handled by CPO. If everything goes right, CPO will receive a specific message that says a charging session has started. In this case CPOmay inform EMP about that by sending eRoaming charging notification start

When a charging session has started, EMP and its customer would like to receive more details about the ongoing charging session. They would like to know what is the energy consumption, duration, charging characteristic for some visualization and maybe even some predictions. The typical scenario is that CPO will receive meter values from chargepoint every 15 minutes via OCPP protocol. Therefore CPO may notify EMP about it and send some useful charging session details with eRoaming charging notification progress. Because those notifications are not crucial and not so frequent Hubject recommends at least a five minute frequency between two progress notifications.

CPO may also notify EMP, that the charging process has stopped. It can mean that energy is not flowing and the customer may be informed that his electric vehicle has been fully charged. a notification itself that does not mean that the charging session has been finished. In order to end the charging session and unlock connector you may use authorized stop request normal or remote or CPO may finish charging session on its own and push CDR right after it happens.

Of course, during the charging session there can be a lot of unexpected events i.e. stop triggered by charge points, charging fluctuations or even charge point damage. From an EMP perspective, it's very important to know what is going on and to inform its customer that his charging session cannot be finished successfully or that it was finished before his electric vehicle has been fully charged. In this case, CPO can send an eRoaming charging notification error with some details regarding the problem.

Data model of eRoaming charging notification may differ a little bit depending on the type of notification, but for most of the parts it looks almost the same. Charging duration and consumed energy progress is calculated for the time between charging start and event occurred. Charging duration is expressed in milliseconds, consumed energy progress is expressed in kilowatt hours. Meter value in between is an object representing a list of our meter values, which can be used for specifying charging characteristics. Of course, this data will not be present in eRoaming charging notification start. For error notifications we may also see error type and error additional info, which can be used for specifying more details about charging problem that has occurred.

When it comes to the rest of the fields, we have already seen them before in other data models. So there is no need for an explanation.

To sum up we have covered all OICP services from a CPO perspective and seen how the flow, business logic and data model looks like. Although some services are mandatory in order to integrate with the Hubject platform. Here you have a list of operations network marked as a mandatory in OICP documentation for CPO those operations are
eRoamingAuthorizedStart, eRoamingAuthorizedRemoteStart, eRoamingAuthorizedRemoteStop, eRoamingChargeDetailRecord, eRoamingPushEVSEData, eRoamingPushEVSEStatus. Unfortunately OICP documentation is not perfect and definitely is not clear in many places. In case you encounter some problem, my general advice is to contact the Hubject support team directly. In the past we had a situation where we thought some implementation of operation was mandatory, but it turned out that in our case maybe it's not needed at the moment. After contacting Hubject they said we can postpone it for now and we have definitely saved some time.

Open InterCharge Protocole Training. Lesson 6

With the latest developments in our UX project-handling, we're now sharing some details!

Magdalena Betlińska

At Solidstudio, we like to keep things transparent and so, we thought it would be a good idea to share some more information about our UX process within the projects with our clients. As much as eMobility solutions are the main core of most of most of our publications and general communication, we’d like to break it down with some insights on how we work within the dev projects.

We know the importance of good UX but we’re also well aware that some may pay more or less attention to it than others. With that in mind, our UX process has been constructed in such a way as to serve both approaches.

Generally speaking, we put a lot of care into grasping what is the desired outcome and we’re trying to engage our customers into taking an active part in the creation of mockups and final UI.

Such approach serves a couple of goals, some of them being:

Transparency with our customers in regards to the UX process (not only final mock-ups)

Possibility of better price estimation during sales process

Environment optimized for designers working on a product concept (which translates into product quality)

The way we create and lead the UX within the projects can be narrowed down to 6 steps. Each of which plays a huge role in the success of the final delivery. Below, we’ll try to break them down a bit.


The kick-off of the UX workload starts with a thorough understanding of what it is that's to be made. This is where our team carefully goes through all the materials delivered by the client, analyses them and, if there’s a need, asks any necessary questions on an entry level.

This is also the time to look for the current trends, solutions implemented by others, some of the best practices and the general state of the matter as it stands on the market.

Such an in-depth analysis & research allows our designers to draw valuable conclusions and become familiar with whatever the project is.

thorough analysis of the customer’s needs

acquiring all the necessary information to kick off the project

The concluding part would be the presentation summing up what has been gathered presented to the client.

After initial analysis, the next step contains the customer workshops and whatever it takes to get them ready.

It starts with preparing all the materials necessary for a successful workshop. We prepare the Miro tables and tutorials that are to be presented to the client. Our designers and PM also figure out the agenda of the meeting in such a way as to present everything that has been established so far in the most attractive way.

The actual workshop with clients involves event stormings and user story mapping, all discussed with the clients and open for any necessary alterations.

The outcomes of this steps are as follows:

Gathering all the materials including the Miro tables

An initial walkthrough with PMs, designers and the clients

Event storming and a space for discussion

After the workshops are complete, the client gets an executive summary and previews on the project.

It might be said that this is where the actual UX work kicks in. This step is all about starting to establish the actual product and how it’s supposed to be created.

One of the main points here is determining and describing the user-flows - which is nothing short of the path of clicking it takes for someone to trigger the desired action i.e. on a mobile app. Once this is settled, the next issues on the conceptualization agenda are to create the information architecture.

This is also where the first low-fi schemes are being created.

information architecture (to be confirmed with the clients)

It must be mentioned that the work done on product’s conceptual architecture is being communicated to the client and put forward for reviews.

Based on the outcomes from the previous steps, with the wireframing we start to develop a much more advanced product.

With this step, the low-fi models are being created (in black and white for the starters). This is also where we create the clickable prototype in Figma.

The client then gets an advanced visualization to be checked. Later on, based on any feedback, our team takes time to implement any changes (if such are desired).

As much as the list of outcomes in this step is not to extensive, these are all crucial in the final design process:

Worth underlining is that with this step we require our customers to provide us with a green light in order to go further.

Despite what some people may think, the proper design only starts here, after all the above are finished and accepted.

This step includes the look&feel project. That is, the presentation of what the design is supposed to look like in terms of colors, brightness, shapes or the use of pictures and illustrations. We also prepare the moodboards that are to be shown to the customers.

Finally this step includes the UI design and the preparing of style guides for the developers.

It might be said, that here’s where the most crucial work in terms of the actual design happens, among the outcomes there are:

In this step, the client gets to see the product as it is supposed to look like in the final version. A meeting is being held to discuss the product and possibly make some final amendments.

This would be the final part and most probably the most self-explanatory.

It’s the time to run some usability testings and consult any possibilities with the developers, if needed. It’s pretty much all about the final reviews and some last minute minor changes.

Generally, it serves the purpose of making sure everything run smoothly and works in an agreed manner.

As stated before, we value a good UX as much as we value transparency with our clients. A good design is one of the key factors in creating a successful project. Well-done UX can make the difference between a user enjoying using your product or service, and a user becoming frustrated and giving up.

The offered process takes into consideration both parties, the client and the end-user equally and allows us to deliver the best solutions satisfying to all.

We would also like to point out that we’re open to any discussion and alterations in case any client believes it would suit them best. Should anyone has any questions, we’re more than happy to answer them!

Learn more about how we work! With the latest developments in our UX project-handling, we're now sharing some details!

Our UX process 

See the fifth lesson of our comprehensive eMobility training on OICP!

eRoamingAuthorization + eRoamingReservation

Open InterCharge Protocol Training - Lesson 5

From a CPO perspective this service is probably the most important one in the whole OICP protocol besides authorization service it allows CPO to push static data regarding his charging infrastructure to the Hubject platform in order to allow other EMPs to use it. This service contains only one operation: eRoaming push EVSE data. Of course implementation is mandatory by every CPO partner. Hubject will first check if there is a valid contract between him and CPO. This time Hubject platform is a subscriber to CPO not the specific EMP. Operations like ‘update’ or ‘delete’ are also handled by the same operation; it can be specified in the action type field in the request which we'll see just in a moment.

Hubject has a policy to keep history and version receive the data sets for most of the data that is pushed to their platform. Every push and every update creates a new version of data. Only the latest version of data will be used, but due to keeping history, it is possible to revert some changes on demand. History of all EVSE data records pushed by CPO is stored and versioned by Hubject. Because of that, Hubject can reconstruct static EVSE data for any point in the past. As I've told you before in eRoamingPushEVSEData request you can specify which kind of operation you would like to perform. Action type field defines whether you would like to perform a full load, insert ,update or delete operation. Also, in this request you must provide a list of EVSE data records assigned to a specific operator. EVSE data record is huge and complicated. Nonetheless, it's crucial to at least briefly know what is the structure, what are the fields and what do they represent.

Starting with accessibility, it specifies how the charging station can be accessed. Accessibility location tells us where it could be accessed. Additional info, as the name suggests, is an optional field that specifies additional information regarding charging station. Address is an object that represents a full charging station address - it contains information like country, city, postal code, street name, house number or even parking spot or floor. Authentication modes specify which kind of authentication methods are supported in a given charging station. Calibration law data availability tells us how a charging station provides metering law data. Charging facilities is a list of supported facilities it can specify whether it's AC/DC, what kind of voltage, amperage and power is supported. Charging pool ID and charging station ID are IDs related to the European charging infrastructure model. We will come back to this topic later.

Charging station names, charging station image and charging station location reference are other additional information regarding charging station. It's often presented to the end-user by EMPs. Dynamic info available specifies whether CPO is able to provide dynamic EVSE status. EVSE ID is quite obvious - it's an idea of EVSE. Energy source is a list of sources that are used to provide electric energy. Environmental impact specifies the impact that is being produced by those sources. Geocharge point entrants are geo coordinates of charge point facility entrance, it can be expressed in google, decimal degree or minute/seconds degree format. Hotline phone number and hub operator ID are self-explanatory. IsHubjectCompatible specifies whether eRoaming via intercharge network is possible. Max capacity field is in case EVSE has limited capacity, i.e. has built-in battery, values are expressed in kilowatt hours. Opening times field should be visible only when the charging station is not 24h available. Payment options, as the name suggests, is a list of payment options that are supported: it can be no payment in case of free charging, direct in case of paying by card or cash, or contract in case of for example subscription. Blocks is a list of supported plug types, i.e. type 2. Renewable energy tells us whether a charging station uses this kind of energy. Sub operator name is self-explanatory. Value added services is a list of additional services offered by a charging station: it can be for example reservation, dynamic pricing, parking sensor, maximum power charging, charging plans, roof provided and few others. DeltaType field is mostly valid for pull operations. It is strictly connected with the last call parameter, which can be provided in pull operations query. In general, it says what kind of operation was performed in the middle time compared to the last call. It can be ‘insert’, ‘update’ or ‘delete’. If you provide the last full parameter inquiry and no operation was performed in the middle time, then the given record should not be returned in response. Finally, we have the last update field which tells us when the last time record was updated.

Another EVSE related service important from CPO perspective is eRoaming EVSE status. In contrast to eRoaming EVSE data, it focuses only on dynamic EVSE data, especially status information. It's also very simple - it has only one operation. This operation is eRoaming push EVSE status. Of course, it allows us to push dynamic EVSE data to the Hubject platform. Implementation is mandatory by every CPO partner. When it comes to validation, it behaves the same as for eRoaming push EVSE data. Also, it's possible to specify the action type for a given operation. Similar as for EVSE data records, the history of all EVSE status records is stored and versioned by Hubject.

When it comes to the request of this operation, it's very simple. You need to provide a combination of EVSE ID with evs status in EVSE status records list.

Let’s read our posts

Solidstudio news! Strategic partnership with Zeemcoin.

Recommended

Unlocking eMobility platform using Open Standards - #OCPI use case

Oracle Cloud vs. AWS - Which one should you choose for your business?

OICP and OCPI protocols - open standards for CPOs and eMSPs

Open InterCharge Protocole Training. Lesson 9

Open InterCharge Protocole Training. Lesson 8

Open InterCharge Protocole Training. Lesson 7

Open InterCharge Protocole Training. Lesson 6

Our UX process

Open InterCharge Protocole Training. Lesson 5