Smart Tool Development for Customized Charging Services to EV Users

: E-mobility is a key element in the future energy systems. The capabilities of EVs are many and vary since they can provide valuable system ﬂexibility services, including management of congestion in transmission grids. According to the literature, leaving the charging process uncontrolled could hinder some of the present challenges in the power system. The development of a suitable charging management system is required to address different stakeholders’ needs in the electro-mobility value chain. This paper focuses on the design of such a system, the TwinEV module, that offers high-value services to electric vehicles (EV) users. This module is based on a Smart Charging Tool (SCT), aiming to deliver a more user-central and cooperative approach to the EV charging processes. The methodology of the SCT tool, as well as the supportive optimization algorithm, are explained thoroughly. The architecture and the web applications of TwinEV module are analyzed. Finally, the deployment and testing results are presented.


Introduction
Nowadays, the European Union (EU) is combating climate change through interventions in the transportation sector, as it is by far the biggest harmful gas emitter accounting for more than 70% of all GHG emissions from transport in 2014 [1]. Over the last 25 years, European rules have promoted the reduction of pollutants emissions through careful guidance of vehicles' manufacturers [2]. Therefore, today's focus is on the electrification of transportation, which is essential for the reduction of CO 2 emissions [3]. Electric Vehicles (EVs) will play a highly important role in the future Smart Cities, having different charging strategies that could adapt to the users' needs [4], being a flexibility resource for market actors and system operators. Leaving the charging process uncontrolled could hinder some of the present challenges in the power system, such as peak power demand at certain times [5]. Smart interactions among the smart grid, aggregators, and EVs can bring various benefits to all parties involved, e.g., improved reliability and safety for the smart gird, increased profits for the aggregators, as well as enhanced self-benefit for EV customers [6]. For this purpose, the development of a suitable charging management system is required to address different stakeholders' needs in the electro-mobility value chain, supporting the integration of RES (Renewable Energy Sources) and thus reshaping of the power demand curve.
The common challenges for such systems are: (1) overload of electrical energy distribution network, considering many EVs charging simultaneously; (2) home consumption and contractual power limitation; (3) energy prices fluctuation, in view of the demand-supply balance. A system based on a central information repository storing electricity consumption and production data has already been developed. From that data repository the extraction of knowledge is possible through a simulation tool, including various modules and Data back-end is based on a monthly update of charging data with Charge Point Detail Records and Meter Values enriched with location specific data. The design of the front-end is based on Key Performance Indicators used in the decision process for charging infrastructure roll-out. The final web application creates access to quantitative knowledge about the local performance of the charging infrastructure, thus creating the opportunity to take informed decisions [19].
The objective of this paper is to provide the required and optimized SoC of the users' EV at proper times, considering minimum charging prices and delivery of maximum green electricity supply to EV, based on local energy demand rationalization. The overall goal is to calculate the optimum charging profile, namely the amount of power that should be delivered to a given charging session at a given moment. Thus, the focus is on the development of an EV module that provides high-value services to EV users. This module is indicated as TwinEV module, due to its connection with the TwinERGY project (TwinERGY H2020 Project: https://www.twinergy.eu/, accessed on 10 May 2022). TwinEV module tackles the above challenges through the Smart Charging Tool (SCT), which is based on several inputs, providing the charging profile dynamically calculated in a more usercentral and cooperative approach. To achieve this, it collects EV user's preferences and requirements data to adjust the services and features to be provided. Using this information, TwinEV module offers a user-friendly platform for drivers and grid operators, where they can manage payments, security, quality, and configuration of other topics related to emobility. These topics include making a recommendation about the most suitable charging point (CP), based on some principles such as prices, route cost to station, the energy stock, and the waiting-charging times.
The paper is structured in four chapters. Firstly, the methodology followed is analyzed. The development of the TwinEV module is explained next, emphasizing the architecture, the data management, the Smart Charging Tool (SCT), and optimization methods. Then, the applications of the frontend part of the architecture are thoroughly explained. Finally, the deployment, testing processes, and simulation results are presented.

Methodology
This paper follows a methodological approach. Firstly, the architecture of the TwinEV module is presented, highlighting the innovative SCT tool. In brief, this architecture is structured in three layers: (1) TwinEV applications (front-end), (2) TwinEV services (backend), and (3) Twin EV adaptors, enabling a set of micro-services, each one specialized in the interaction of the services and/or urban infrastructure equipment offered by third-party entities or external systems. This layer also enables the operability of the SCT tool.
The SCT algorithm is a linear optimization model, which is a method to achieve the best outcome (such as maximum profit or lowest cost) in a mathematical model whose requirements are represented by linear relationships. Most Linear Programs (LPs), SCT tool manages inputs (invariable data), variables (data changing along the optimization process), constraints (mathematical relations that must be satisfied), and the objective function (the quantity dependent on the variables to be maximized or minimized). The inputs are sourced from the end-user, the EVs, and the grid. These data are assigned to different data models to be exploited by the SCT tool. The anticipated data protocols and standards are met. Therefore, SCT (1) processes inputs related to the grid, the battery, or demand/consumption predictions, (2) applies their constraints and finally (3) generates a charge curve approaching the objective function.
A first prototype of TwinEV module has already been deployed and tested in an isolated attempt. The TwinEV module, along with its applications, was deployed (in a simulated scenario) using Docker (Docker: https://nats.io/, accessed on 12 May 2022) technology, organizing applications in virtual boxes. The testing includes a significant amount of use cases for drivers (e.g., searching for charge points), grid operators (e.g., adding a new restriction), and dashboard variations (e.g., commands application).

Architecture
The architecture of the TwinEV module is organized in two layers (MEISTER Project: https://meisterproject.eu, accessed on 22 June 2022). They are depicted in Figure 1 and are: (1) Backend and Adaptors, (2) Applications. Each layer is described below.

1.
Backend and Adaptors: each of the applications constituting the tool correspond to back-end services, which are related to the application for individual EV drivers and offer a specialized interface, running continuously in the hosting platform. Backend is implemented as a huge set of RESTful services [20] supporting their clients with the required functionality, such as: Reservation of charge points, Management of the start and the end of transactions, SCT algorithm tool for calculating the profiles of charge for e-vehicles, and Pricing Services Management and publication of the availability of charge stations. In addition to services related to EVs, auxiliary services are included to this layer, such as: User authentication and rights management, User preference management, Data of the users as customers of the integrated service providers (contracts, terms and condition of usage, preferences), and Usage metrics, in an anonymized and aggregated way. The communication with other modules is done through the TwinERGY interoperability platform. This platform consists of a NATS (NATS: https://nats.io/, accessed on 12 May 2022) infrastructure, a messaging system where clients send and receive messages following a schema of publication and subscription: each message is published with a subject so only subscribers to that subject receive the message.

2.
The Adaptors are part of the TwinEV Backend, acting as the interpreter between the TwinEV and the Charging point communications. Adaptors are a set of micro-services, each one specialized in the interaction of the services and/or urban infrastructure equipment offered by third-party entities or external systems. They deal with the specificities of the 3rd party services, infrastructures, and data sources, and allow services, offering their functionality in a transparent manner. The Open Charge Point Protocol (OCPP)(Open Charge Alliance. Importance of Open Charge Point Protocol for the Electric Vehicle Industry. Available online: https://openchargealliance.org/, accessed on 12 July 2022) module acts as an adaptor, identifying the charging points based on the OCPP protocol (OCPP Protocol: https://www.elaad.nl/, accessed on 10 May 2022) that the charging point supports, and it translates the charger orders to the respective version in order to assess data in an integrated way. In particular, the OCPP module defines the communication between the charge point management platform and the e-charging devices. This protocol aims at allowing communications between charge stations and network to provide grid services cost-effectively. Moreover, it encourages customers to own EVs enabling uniform access to this infrastructure, roaming, and billing services. That means that it is the application protocol for communication between the Electric Vehicle Charging Stations (EVSEs) and the central management system (also called charging station network).

3.
Applications: a set of tools offering an interface for end-users and grid operators. Three applications are included in this layer: (a) a mobile application for EV drivers, supporting end-users with different services (e.g., book a charge point, reserve a shared vehicle, etc.), (b) TwinEV dashboard, a web application oriented towards the management of charge points, and (c) TwinEV web application for grid operators, where they can restrict the charge points' supply in case of grid congestions. These three applications include the communication to the TwinERGY identity server through Keycloak, which allows a unified server to manage users and sessions in all applications. Keycloak is a manager of access control based on Single Sign-On (SSO) for web apps and RESTful web services [21]. restriction), and dashboard variations (e.g., commands application).

Architecture
The architecture of the TwinEV module is organized in two layers (MEISTER Project: https://meisterproject.eu, accessed on 22 June 2022). They are depicted in Figure 1 and are: (1) Backend and Adaptors, (2) Applications. Each layer is described below. 1. Backend and Adaptors: each of the applications constituting the tool correspond to back-end services, which are related to the application for individual EV drivers and offer a specialized interface, running continuously in the hosting platform. Backend is implemented as a huge set of RESTful services [20] supporting their clients with the required functionality, such as: Reservation of charge points, Management of the start and the end of transactions, SCT algorithm tool for calculating the profiles of charge for evehicles, and Pricing Services Management and publication of the availability of charge stations. In addition to services related to EVs, auxiliary services are included to this layer, such as: User authentication and rights management, User preference management, Data of the users as customers of the integrated service providers (contracts, terms and condition of usage, preferences), and Usage metrics, in an anonymized and aggregated way. The communication with other modules is done through the TwinERGY interoperability platform. This platform consists of a NATS (NATS: https://nats.io/) infrastructure, a messaging system where clients send and receive messages following a schema of publication and subscription: each message is published with a subject so only subscribers to that subject receive the message.

Data Interchange
As can be deduced from the architecture, the correct functioning of the TwinEV module depends on the interchange of data between the top-placed applications and the backend, the applications and the identity server, the backend and the charge points, and so on. Those data are organized in four groups (Data Models): (1) Related to charging points data models including the charging point's (CP) static and dynamic information, reservations data, etc. (2) Related to users' data models are used in common backend services and validated by the Identity server, such as, identity, preferences, etc. (3) Related to vehicles data models are used for determine what stations can be used by the drive, (4) Related to the grid data models offer the potential to add restrictions to the energy injected during a charge and determine the charge profile using the SCT algorithm. This group includes the forecasting of demand and production. All the data exchanged follow the intended standards and protocols (e.g., OCPP Protocol, OCPI protocol (OCPI Protocol: https://evroaming.org/, accessed on 14 May 2022)).

Smart Charging Tool (SCT)
In this section, an algorithm implementing the smart charging of electric vehicles, termed Smart Charging tool (SCT), is presented. SCT is a smart calculator of profiles of charge for e-vehicles. SCT offers four types of smart charging to drivers. This is possible thanks to four optimal profiles: Cheap charge (Max. energy injection to vehicles when the prices of energy are lower), Fast charge (Max. energy injection to vehicles when more energy is available in the grid), Green charge (Max. energy injection to vehicles when energy is generated by renewable energy sources), and Default charge (Energy model according to restrictions in grid). SCT considers inputs including vehicle features, energy prices, limitations on the grid, or predicted RES generation, thus generating a curve indicating the charging process. SCT models one charge curve for the period that the charge session is active. For all models, the common notation is (a) Ts: timespan of each slot (in minutes), (b) T: number of slots. Time horizon of the optimization is therefore Ts × T, (c) N: number of EVSEs with active charging sessions. This charge curve is representing one of the following situations, the inputs for the objective function for each model being those noted in Table 1. On the other hand, Table 2 centralizes the variables for the objective function.

1.
Optimum charging profiles considering CPO (Charging Point Operator) and driver requirements: maximize self-consumption to minimize the cost of the energy supplied by the grid. This profile models a basic context where CPs supply energy to vehicles with an upper limit in the energy injected. Here, the smart optimization consists of a minimization of the total cost for the energy supplied to the vehicle during each slot of time: where energyImportedCost is a variable calculated as: Table 1. Inputs for the objective function for optimum charging profiles considering CPO and driver requirements.

Inputs Description Domain
Demand t Non-controllable on-site demand power forecast (kW) Limitation of total (imported) power at on-site supply point (kW) - As has been commented, the SupplyPointEnergyImported value for each slot t depends on different inputs, such as demand and production in the district, as well as the EVSE nominal powers and calculated schedules, among other variables.
The variables of smart charging with CPO requirements optimization problem are the energy to be delivered per EVSE and slot (kWh), the energy flows at supply point (kWh), and the EV battery SoC (kWh) at the end of each slot, which are calculated from Equations (2)-(5), correspondingly.
The variables for the objective function for optimum charging profiles considering CPO and driver requirements are noted in Table 2. (3) EVSEEnergy n,t + (Demand t + Production t )· Ts 60 (4) EVSESoC n,t Electric Vehicle State of Charge (kWh) at the end of each slot TargetSoCReached n,t Electric Vehicle State of Charge (kWh) at the end of the charging session TargetSoCNotReached n,t Electric Vehicle State of Charge (kWh) at the end of the charging session The SupplyPointEnergyImported variable gets disaggregated in the model in two different terms, since cost is only associated to the portion of the energy that is actually imported from the grid. This is calculated by the following additional linear constraints. Firstly, two binary variables are defined, which will state whether the energy is being imported or exported from the grid at a given slot. Equations (6)-(8) define the necessary constraints.

SupplyPointEnergyImported t ≤ SupplyPointEnergyIsImporting t ·SupplyPointPMax·
Ts 60 (6) SupplyPointEnergyImported t ≥ SupplyPointEnergyIsExporting t ·SupplyPointPMin· Ts 60 (7) SupplyPointEnergyIsImporting t + SupplyPointEnergyIsExporting t = 1 Secondly, two new variables, SupplyPointEnergyImported and SupplyPointEnergy-Exported, are defined, which hold the corresponding values if the energy at the supply point is being imported or exported, and 0 otherwise. Equations (9)-(16) define the necessary constraints At this point, the constraints are described. EV battery SoC cannot be negative or exceed battery capacity or breach target SoC requirement at disconnection slot, as demonstrated in Equations (17)-(19): EVSESoC n,TargetSlot n ≥ EVSECapacity n ·TargetSoC n n ∈ [0, Power flow at supply point cannot exceed the limitation of total (imported) power at on-site supply point (20): Energy cannot be drained from EVs (if there is no V2G support), as shown in (9), or exceed EVSE nominal power, as shown in (21) and (22). 2.
V2G schemes: use of charging stations for Vehicle to Grid (V2G) energy flow, where it is possible. This profile adds to the previous one the case where vehicles and charge pots allow V2G scheme, that is, the return of energy from EV battery to the energy network. The optimization for this model is the same one, the minimization of the total cost of the operation: With respect to the previous scheme, EVSE nominal discharge power (kW) (EVSEDischargePower n ) is set to 0 for those EVSEs with no V2G capabilities: As constraints, we consider that the energy can be drained from EVs (not considered previously), and we add this restriction that the power flows discharging from EV must not exceed EVSE discharge power: 3. Support to the grid: this scenario incorporates modifications on the charging point power flow, to adjust it to meet the "flexibility orders" given by the Distributed System Operator (DSO). This version of the model incorporates the possibility of integrating support operations to the grid. These support operations consist of modifications on the supply point power flow limit (either upper, allowing greater demand, or lower, imposing demand limitations) provided by the grid operator (so-called flexibility orders).
Respect to the V2G scheme, we include flexibility orders in kW (Flexibility t ) as new input. This input is provided by the grid operator. Those are interpreted as offsets over the maximum power at the supply point (usually the contracted power).
This implies to modify the constraint about the power flow, so power flow at supply point must not exceed the limitation, considering allocated flexibility:

4.
Trade-off between smart charge benefits and long-lasting charging sessions: in this model, "opportunity costs" are included, so the Charging Point Operator (CPO) faces an opportunity cost for every new charge session that cannot be supplied due to the World Electr. Veh. J. 2022, 13, 145 9 of 20 lack of free charging points. This cost increases along with the duration of the active sessions [22].
Previous models include an inherent effect that is contrary to the ultimate business objectives of CPOs. By only considering the energy cost in the objective optimization, an awkward phenomenon occurs. Long-lasting charging sessions are encouraged, since those provide more flexibility to CPOs to modulate the energy delivery, and therefore are associated with higher potential cost savings. Even though this is true, strictly speaking, the model so far omits the consideration that a CPO faces an opportunity cost for every new charge session that cannot be supplied due to the lack of free charging points. This cost increases with the duration of the active sessions, as shown in Figure 2. 4. Trade-off between smart charge benefits and long-lasting charging sessions: in this model, "opportunity costs" are included, so the Charging Point Operator (CPO) faces an opportunity cost for every new charge session that cannot be supplied due to the lack of free charging points. This cost increases along with the duration of the active sessions [22].
Previous models include an inherent effect that is contrary to the ultimate business objectives of CPOs. By only considering the energy cost in the objective optimization, an awkward phenomenon occurs. Long-lasting charging sessions are encouraged, since those provide more flexibility to CPOs to modulate the energy delivery, and therefore are associated with higher potential cost savings. Even though this is true, strictly speaking, the model so far omits the consideration that a CPO faces an opportunity cost for every new charge session that cannot be supplied due to the lack of free charging points. This cost increases with the duration of the active sessions, as shown in Figure 2. By introducing an opportunity cost component to the objective function, the optimization result will no longer encourage long-lasting charging sessions, pushing charging sessions to finalize at early stages, where a trade-off is reached between both types of cost.
With respect to the previous model, we introduced these inputs:  By introducing an opportunity cost component to the objective function, the optimization result will no longer encourage long-lasting charging sessions, pushing charging sessions to finalize at early stages, where a trade-off is reached between both types of cost.
With respect to the previous model, we introduced these inputs: TargetSoCNotReached n,t ≤ (TargetSoC n − EVSESoC n,t ) (TargetSoC n − EVSESoC n,t ) ≤ TargetSoCNotReached n,t ·EVSECapacity n In addition, the objective function has been modified in order to introduce the opportunity costs: A simulation of the power status for the TwinEV module that deals with the grid operators (DSO, CPO) is depicted in Figure 3. In addition, the objective function has been modified in order to introduce the opportunity costs: A simulation of the power status for the TwinEV module that deals with the grid operators (DSO, CPO) is depicted in Figure 3.

Web Applications
This section presents the three web applications included in the TwinEV module: TwinEV for drivers, TwinEV for grid operators, and TwinEV Dashboard. These applications are focused on the different roles of users.

TwinEV for Drivers
This is a mobile application where drivers can reserve charge points, manage their data, and receive suggestions about where is better to charge their vehicles. The user can directly manage the application without an account, and he/she can view a map with available EV charging stations and some minimal information about them. The list of shown stations includes only free stations with a charger compatible to the vehicle and closer than the distance marked by the user. The stations are marked with a color from red (worst option) to light green (best option), and information about the station appears when it is selected. The user can also create an account and log into the application. Therefore, several screens are accessible (e.g., Search stations and reserve, Reserve vehicles, Reservations, My profile etc.). Part of this process is explained in Figure 4.

Web Applications
This section presents the three web applications included in the TwinEV module: TwinEV for drivers, TwinEV for grid operators, and TwinEV Dashboard. These applications are focused on the different roles of users.

TwinEV for Drivers
This is a mobile application where drivers can reserve charge points, manage their data, and receive suggestions about where is better to charge their vehicles. The user can directly manage the application without an account, and he/she can view a map with available EV charging stations and some minimal information about them. The list of shown stations includes only free stations with a charger compatible to the vehicle and closer than the distance marked by the user. The stations are marked with a color from red (worst option) to light green (best option), and information about the station appears when it is selected. The user can also create an account and log into the application. Therefore, several screens are accessible (e.g., Search stations and reserve, Reserve vehicles, Reservations, My profile etc.). Part of this process is explained in Figure 4.

TwinEV for Grid Operators
This is a web application enabling grid operators to set restrictions about the amount of energy supplied by selected charge points (as shown in Figure 5), thus tackling energy issues in the grid. In this context, two user roles are recognized: the grid operator and the administrator. While the grid operator can set restrictions to the charge points, the administrator is able to manage users. When a user logs into the platform, he/she can access a single screen for the congestion management. This screen is divided in two views: one for insertion of new restrictions (tab Status), (showing a map with visible charge points, a tool of actions and the form to insert the new restriction) and another one to watch a historical of restrictions in the area (tab Historical) (showing a table with the person who ordered

TwinEV for Grid Operators
This is a web application enabling grid operators to set restrictions about the amount of energy supplied by selected charge points (as shown in Figure 5), thus tackling energy issues in the grid. In this context, two user roles are recognized: the grid operator and the administrator. While the grid operator can set restrictions to the charge points, the administrator is able to manage users. When a user logs into the platform, he/she can access a single screen for the congestion management. This screen is divided in two views: one for insertion of new restrictions (tab Status), (showing a map with visible charge points, a tool of actions and the form to insert the new restriction) and another one to watch a historical of restrictions in the area (tab Historical) (

TwinEV Dashboard
This is a web application enabling charge points managers to manage their charge stations. A map including the charging points is provided. TwinEV dashboard includes 4 screens: Transactions, Commands, Locations, and Analysis. The "Transactions" screen shows a table including current and past transactions, as well as a dialog with the transaction's details (Figure 6), including a chart with the progression of the energy delivered.

TwinEV Dashboard
This is a web application enabling charge points managers to manage their charge stations. A map including the charging points is provided. TwinEV dashboard includes 4 screens: Transactions, Commands, Locations, and Analysis. The "Transactions" screen shows a table including current and past transactions, as well as a dialog with the transaction's details (Figure 6), including a chart with the progression of the energy delivered.

TwinEV Dashboard
This is a web application enabling charge points managers to manage their charge stations. A map including the charging points is provided. TwinEV dashboard includes 4 screens: Transactions, Commands, Locations, and Analysis. The "Transactions" screen shows a table including current and past transactions, as well as a dialog with the transaction's details (Figure 6), including a chart with the progression of the energy delivered.  "Commands" screen shows a table of commands sent to each charge point from mobile application for drivers. The "Locations" screen informs about technical aspects of each charge station and its chargers, and the smart charge profiles calculated by SCT. The "Analysis" screen shows statistics about the use of the charge points for the selected month.

Deployment and Testing
The TwinEV module and its applications have been deployed using Docker [15] technology. Docker is an open-source project automatizing the deployment of applications, since it organizes applications in virtual boxes (termed "containers"), integrating all requirements and dependencies needed.
The performance of the TwinEV module is depicted in the upcoming figures: Figures 7-9. Figure 7 shows the flow of actions when a user tries an action in the interface of any of the TwinEV applications. If the user has not been validated yet, the Keycloak module asks for a validation in the TwinERGY identity server After that validation, the returned session token will be used as guarantee that all next actions are done by a valid user. "Commands" screen shows a table of commands sent to each charge point from mobile application for drivers. The "Locations" screen informs about technical aspects of each charge station and its chargers, and the smart charge profiles calculated by SCT. The "Analysis" screen shows statistics about the use of the charge points for the selected month.

Deployment and Testing
The TwinEV module and its applications have been deployed using Docker [15] technology. Docker is an open-source project automatizing the deployment of applications, since it organizes applications in virtual boxes (termed "containers"), integrating all requirements and dependencies needed.
The performance of the TwinEV module is depicted in the upcoming figures: Figures  7-9. Figure 7 shows the flow of actions when a user tries an action in the interface of any of the TwinEV applications. If the user has not been validated yet, the Keycloak module asks for a validation in the TwinERGY identity server After that validation, the returned session token will be used as guarantee that all next actions are done by a valid user.   Figure 9 shows the flow of actions for a charge session, from the moment the user reserves a charge point to he/she stop the charge. Moreover, it should be considered that the user can charge his/her vehicle in a private charge point without the reservation steps.   During the development of the TwinEV components, a long set of lab tests has been executed through simulation scenarios (use cases), with the aim of ensuring that actions are executed as expected. Each use case tested is documented in a table like Table 3.   During the development of the TwinEV components, a long set of lab tests has been executed through simulation scenarios (use cases), with the aim of ensuring that actions are executed as expected. Each use case tested is documented in a table like Table 3.  During the development of the TwinEV components, a long set of lab tests has been executed through simulation scenarios (use cases), with the aim of ensuring that actions are executed as expected. Each use case tested is documented in a table like Table 3. As the list of tests is huge, and since TwinEV module has been designed with the goal of covering the primary use cases related to electric vehicles, only some of the use cases are mentioned below. The list of use cases is presented in Table 4. The following software were used for the testing of the SCT algorithm: (a) Jupyter notebook (to process the testing), and (b) Matplotlib (to produce the charts), which are typical in Python environments. This algorithm was implemented with Pulp/CBC MILP Solver. Regarding the testing process, a series of testing cases were defined. The algorithm was tested with controlled entries so that the results produced could be compared to the forecasted ones. In those cases, when the forecasted result differs from the simulation result, the model was depurated. Then, any failure was corrected, and specifications were added to model more accurately the algorithm and cover up some situations that were not foreseen during the designing phase.
Three scenarios tested are explained and compared below. All three scenarios present a 6-h period in total, with 15 min as timespan per each time slots (Ts). Starting with a basic scenario, different changes are introduced in the optimization context with the objective of inducing relevant expected results. These scenarios correspond to three different situations: (a) Situation without relevant constraints, (b) Situation considering restrictions ordered by grid operators, and (c) Situation considering energy prices.

State of Charge-SoC [Wh]
. This graph represents the evolution of the energy stored in each EV.
Horizontal axis represents the time span (corresponding to 15 min). The first scenario, depicted in Figure 10, proposes charging 3 EVs in 6 h, with no relevant constraints. For these vehicles we considered: Supply point max. power equal to 10 kW, Supply point min. power equal to −10 kW, Maximum capacity equal to 60 kWh, SoC equal to 50 kWh, Nominal power of EVSEs equal to 7.7 kW, Nominal discharge power of EVSEs equal to 0 kW, target slots equal to 6 h and target SoCs equal to 60 kWh. The results are satisfactory according to what is expected, as the proposing charging profiles achieve the objectives fixed for the charging of the three vehicles: to transition to a State of Charge from 50 kWh to 60 kWh. It is highlighted that the vehicles are charged at the end of the time horizon and the supply power does not exceed the 10 kW limit at any time during the time horizon of the experiment. In the second scenario, the opportunity costs are introduced. The first scenario is reproduced, in this case introducing a small linear opportunity cost. The expected effect is that EVs are now charged as fast as possible. The same input was used, with the only difference of noting opportunity costs equal to 1/slot. The second scenario, depicted in Figure 11, behaves as expected. EV0 is the first vehicle getting fully charged accordingly

1.
Power [W]. In "Power" diagram we exclude the power provided by the EVs, thus power from other generators is considered equal to zero for all three scenarios. The demand forecast for all three cases is equal to zero, thus no forecasted demand for the cases is represented.

2.
Supply Point Power [W]. This diagram is the accumulative diagram for all three charging profiles, and it represents the power provided by a hypothetical charging point that could provide power to the three EVs, with a limitation of 10 kW.
to the required target. Consequently, the other EVs are delayed in terms of charging since the available power will be devoted to fulfilling the first vehicle requirement. The charging process considers alongside the power limitation of the Charging Point, so that it does not exceed the limit at any time during the experiment. All three vehicles achieve the targeted final state of charge. Figure 11. SCT output for considering restrictions ordered by grid operators.
In the third scenario, depicted in Figure 9, the following changes are introduced to observe the effect of energy prices in the composition of the charging profiles: (1) Opportunity cost is removed, (2) Energy prices are introduced, being cheaper from slot 15 onwards. The expected effects are: (1) Due to the target slot constraint for EV0, it will still be charged in the first phase of the time horizon, and (2) Due to the energy prices and more specifically the monetary reduction of the prices from slot 15, the delivery of energy to EV1 and EV2 will be allocated mainly after slot 15. Approximately the same input is used with these differences: we considered Supply point max. power equal to 8 kW, Supply point min. power equal to −8 kW, Energy price is 1 at slots 0 to 15, and 0 at slots 15 to 23 while the target slot for the first vehicle is 1.5 h instead of 6 h. It is highlighted that the limitation of power is strictly fulfilled during the experiment, achieving at the same time the target State of Charge in the three vehicles foreseen.  Horizontal axis represents the time span (corresponding to 15 min). The first scenario, depicted in Figure 10, proposes charging 3 EVs in 6 h, with no relevant constraints. For these vehicles we considered: Supply point max. power equal to 10 kW, Supply point min. power equal to −10 kW, Maximum capacity equal to 60 kWh, SoC equal to 50 kWh, Nominal power of EVSEs equal to 7.7 kW, Nominal discharge power of EVSEs equal to 0 kW, target slots equal to 6 h and target SoCs equal to 60 kWh. The results are satisfactory according to what is expected, as the proposing charging profiles achieve the objectives fixed for the charging of the three vehicles: to transition to a State of Charge from 50 kWh to 60 kWh. It is highlighted that the vehicles are charged at the end of the time horizon and the supply power does not exceed the 10 kW limit at any time during the time horizon of the experiment.
In the second scenario, the opportunity costs are introduced. The first scenario is reproduced, in this case introducing a small linear opportunity cost. The expected effect is that EVs are now charged as fast as possible. The same input was used, with the only difference of noting opportunity costs equal to 1/slot. The second scenario, depicted in Figure 11, behaves as expected. EV0 is the first vehicle getting fully charged accordingly to the required target. Consequently, the other EVs are delayed in terms of charging since the available power will be devoted to fulfilling the first vehicle requirement. The charging process considers alongside the power limitation of the Charging Point, so that it does not exceed the limit at any time during the experiment. All three vehicles achieve the targeted final state of charge. As can be seen in Figure 10, representing a situation in which there are no limitations to the energy injection, vehicles receive more energy when more energy is available, so that vehicles have a charge that is approximately linear. Figure 11, representing a situation with limitations during the last part of the charge, shows that SCT determines to charge vehicles before these limitations. Figure 12, corresponding to the lowest energy prices, depicts that SCT determines to charge vehicles mainly in this period.

Conclusions
The presented study aims to develop a suitable charging management system, TwinEV module, to address different users' needs (drivers and grid operators) in the electro-mobility value chain, providing a more user-central and cooperative approach to the EV charging processes. The TwinEV module considers real experiences and results from e-mobility agents and grid operators who exchange information to achieve optimum functional e-mobility systems. The ability of implementing smart charging strategies on charging points gives the possibility to outsource data, allowing the optimization of energyrelated costs. This is an enabler for the utilization of renewable energy sources and the participation of the active actors in the smart grid management. Considering a user-oriented approach, the usage of real-time response applications provides the user with a variety of functionalities. They allow the user to enjoy an optimum EV charging experience ensuring lower costs if flexibility requests could be applied. Additionally, the user prefer- In the third scenario, depicted in Figure 9, the following changes are introduced to observe the effect of energy prices in the composition of the charging profiles: (1) Opportunity cost is removed, (2) Energy prices are introduced, being cheaper from slot 15 onwards. The expected effects are: (1) Due to the target slot constraint for EV0, it will still be charged in the first phase of the time horizon, and (2) Due to the energy prices and more specifically the monetary reduction of the prices from slot 15, the delivery of energy to EV1 and EV2 will be allocated mainly after slot 15. Approximately the same input is used with these differences: we considered Supply point max. power equal to 8 kW, Supply point min. power equal to −8 kW, Energy price is 1 at slots 0 to 15, and 0 at slots 15 to 23 while the target slot for the first vehicle is 1.5 h instead of 6 h. It is highlighted that the limitation of power is strictly fulfilled during the experiment, achieving at the same time the target State of Charge in the three vehicles foreseen.
As can be seen in Figure 10, representing a situation in which there are no limitations to the energy injection, vehicles receive more energy when more energy is available, so that vehicles have a charge that is approximately linear. Figure 11, representing a situation with limitations during the last part of the charge, shows that SCT determines to charge vehicles before these limitations. Figure 12, corresponding to the lowest energy prices, depicts that SCT determines to charge vehicles mainly in this period.

Conclusions
The presented study aims to develop a suitable charging management system, TwinEV module, to address different users' needs (drivers and grid operators) in the electro-mobility value chain, providing a more user-central and cooperative approach to the EV charging processes. The TwinEV module considers real experiences and results from e-mobility agents and grid operators who exchange information to achieve optimum functional emobility systems. The ability of implementing smart charging strategies on charging points gives the possibility to outsource data, allowing the optimization of energy-related costs. This is an enabler for the utilization of renewable energy sources and the participation of the active actors in the smart grid management. Considering a user-oriented approach, the usage of real-time response applications provides the user with a variety of functionalities. They allow the user to enjoy an optimum EV charging experience ensuring lower costs if flexibility requests could be applied. Additionally, the user preferences are the main factor-optimizing strategies, while the desired state of charge is the definer of the timing of unplugging the EV. The proposed optimization model (1) processes inputs related to the grid, the battery or demand/consumption predictions, (2) applies their constraints, and finally (3) generates a charge curve approaching the objective function. Three scenarios are tested, corresponding to three different situations where SCT algorithm calculates the charging profile for three EVs charging: (a) Situation without relevant constraints, (b) Situation considering restrictions ordered by grid operators, and (c) Situation considering energy prices. Based on the validation, the output for a situation without relevant constraints shows that vehicles receive more energy when more energy is available, the output for considering restrictions ordered by grid operators shows that the tool determines to charge vehicles before these restrictions while the output considering energy prices depicts that the determines to charge vehicles mainly in this period. A first prototype of TwinEV module is also deployed and tested in an isolated attempt. The testing includes a significant amount of use cases for drivers, grid operators, and dashboard variations.
The smart charging strategies of the TwinEV module could be implemented in real life by different kinds of users. For example, e-mobility agents and grid operators could exchange information to achieve optimum functional e-mobility systems, while users could enjoy an optimized charging experience through the usage of real-time response applications.