Smart Tool Development for Customized Charging Services to EV Users

Abstract

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 flexibility 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.

1. 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₂ 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 Mining, regarding Smart EV Charging System prices and renewable energy availability, tackling a combination of the above challenges [7].

A charging problem as a Markov decision process has been modeled in [8] to reduce the charging costs; however, the approach does not consider the participation of an EV aggregator, which can interact with the transmission and distribution system operators considering their technical constraints. These methodologies are useful to minimize charging costs, but users’ preferences are not significantly considered, which can create a barrier for users to adopt EVs. In [9], a decentralized charging control is studied, where a load aggregator optimizes the charging of a plug-in EV fleet, considering price-based signals. Only a few works have considered the EV users’ preferences in their methodologies. In [10], a charging methodology is presented that jointly optimizes pricing, scheduling, and admission control of an EV charging station, based on a multi-sub-process admission control scheme. This work considers reducing the excessive waiting time for EV users; however, even if this waiting time is minimal, it can negatively impact on the EV user experience, and this work only considers the case of a charging station. In [11], an interactive charging management system for EV charging is investigated, guaranteeing EV users’ preferences. Although user convenience was maximized, these works did not consider the EV charging costs.

A smart charging model for EV aggregators, considering not only users’ preferences but also allowing EV charging at the lowest cost, is analyzed in [12]. EV users can choose among different customer choice products that meet their needs in terms of charging time. One of the main challenges for electric vehicle (EV) aggregators is the definition of a control infrastructure that scales to large EV numbers. For this purpose, an optimization framework for achieving computational scalability based on the alternating directions method of multipliers is analyzed in [13]. Real-time charging strategies, in the context of vehicle to grid technology, are needed to enable the use of electric vehicle fleets batteries to provide ancillary services. A real-time controller considering bidirectional charging efficiency has been developed to manage charging and discharging in a fleet to track an automatic generation control signal when aggregated [14].

A smart bidirectional charging algorithm has also been proposed to minimize the charging cost and maximize the customer’s profit while considering the temperature effect on lithium-ion batteries [15]. To achieve this, the algorithm considers the daily energy price, electric vehicle information, customer needs, the outside air temperature, and the temperature of the battery, to formulate and solve a non-linear constrained optimization problem. The same issues were faced by a computational framework (Charging points: https://oplaadpalen.nl/, accessed on 1 June 2022) using real-world data to answer questions like new chargers’ layout and number of chargers required to bring energy utilization to the desirable level, imposing predictions for charging station, considering that the more alternatives a user has, the higher the probability he/she will choose one of the most competitive charging stations. This framework, achieves to predict utilization of charging stations and parking spots associated to these charging stations based on historical data of charging sessions, using machine learning algorithms [16]. Identical challenges were faced by a tool using an Artificial Neural Network (ANN)-based model predicting the charging profiles of EVs connected to a building. This ANN model considered past charging profiles, initial State of Charge (SoC), and final SoC [17] for predicting the charging profile of the EVs.

A Building Energy Management System (BEMS) simulation tool was also developed using National Instruments LabVIEW software (National Instruments LabVIEW software: https://www.ni.com/en-us/shop/labview.html, accessed on 5 June 2022) to analyze the functionality of the model [18]. The researchers found that the model was able to track the changes in the power consumption due to battery aging and degradation, which may not be significant if only a few EVs are considered. However, when EVs charge in groups (typically 50–100), the changes in power consumption have a significant effect. In the same orientation, the Amsterdam University of Applied Sciences developed both the back-end and front-end of a decision support tool along with a Data Warehouse architecture. The 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 user-central 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 e-mobility. 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.

2. 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 (back-end), 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).

3. Development of TwinEV Module

3.1. 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.

• 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.
• 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).
• 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].

3.2. 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)).

3.3. 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. Inputs for the objective function for optimum charging profiles considering CPO and driver requirements.

Inputs	Description	Domain
Demandt	Non-controllable on-site demand power forecast (kW)	t ∈ [0,T − 1]
Productiont	On-site production (generation) power forecast (kW)	t ∈ [0,T − 1]
SupplyPointPMax	Limitation of total (imported) power at on-site supply point (kW)	-
SupplyPointPmin	Minimal (imported) power at on-site supply point (kW)	-
Pricet	Imported energy price (€/kWh)	t ∈ [0,T − 1]
EVSECapacityn	Total battery capacity (kWh) per EV	n ∈ [0,N − 1]
EVSESoCn	Battery initial SoC (kWh) per EV	n ∈ [0,N − 1]
EVSEPowern	EVSE nominal power (kW)	n ∈ [0,N − 1]
SupplyPointEnergyIsImportingt	Energy (kWh) that it is being imported at the end of each slot	t ∈ [0,T − 1]
SupplyPointEnergyIsExportingt	Energy (kWh) that it is being exported at the end of each slot	t ∈ [0,T − 1]
EVSEDischargePowern	EVSE discharge power (kW)	n ∈ [0,N − 1]
PreviousSlotsn	Number of slots an EVSE has been occupied prior to the execution of optimization	n ∈ [0,N − 1]
OpportunityCosts	Opportunity Cost faced per duration of the charge session (€/slot)	-
TargetSlotn	Target slot per EV (time when EV is required to be charged)	n ∈ [0,N − 1]
TargetSoCn	Target SoC (ratio of total battery capacity) required at target slot per EV	n ∈ [0,N − 1]
Flexibilityt	On-site flexibility power forecast (kW)	t ∈ [0,T − 1]

. On the other hand,

Table 2. Intermediary variables for the objective function for optimum charging profiles.

Variable	Description	Domain
SupplyPointEnergyImportedt	Energy (kWh) that it is flowing at the end of each slot	t ∈ [0,T − 1]
energyImportedCostt	Cost of the energy imported by the EVSE	t ∈ [0,T − 1]
SupplyPointEnergyIsImportedt	Energy (kWh) that it is being imported at the end of each slot	t ∈ [0,T − 1]
SupplyPointIsEnergyExportedt	Energy (kWh) that it is being exported at the end of each slot	t ∈ [0,T − 1]
EVSEEnergyn,t	Energy (kWh) to be delivered per EVSE and slot	n ∈ [0,N − 1] t ∈ [0,T − 1]
EVSESoCn,t	Electric Vehicle State of Charge (kWh) at the end of each slot	n ∈ [0,N − 1] t ∈ [0,T − 1]
TargetSoCReachedn,t	Electric Vehicle State of Charge (kWh) at the end of the charging session	n ∈ [0,N − 1] t ∈ [0,T − 1]
TargetSoCNotReachedn,t	Electric Vehicle State of Charge (kWh) at the end of the charging session	n ∈ [0,N − 1] t ∈ [0,T − 1]

centralizes the variables for the objective function.

• 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:

  $$\mathrm{F}=\mathrm{minimize}\left({\displaystyle \sum _{\mathrm{t}=0}^{\mathrm{T}-1}}{\mathrm{energyImportedCost}}_{\mathrm{t}}\right)$$

  (1)

  where energyImportedCost is a variable calculated as:

  $${\mathrm{energyImportedCost}}_t={\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}\times {\mathrm{Price}}_{\mathrm{t}}$$

  (2)

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.

$${\mathrm{EVSEEnergy}}_{\mathrm{n},\mathrm{t}}\mathrm{n}\in \left[0,\mathrm{N}-1\right]\mathrm{t}\in \left[0,\mathrm{T}-1\right]$$

(3)

$${\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}={\displaystyle \sum _{\mathrm{n}=1}^{\mathrm{N}}}{\mathrm{EVSEEnergy}}_{\mathrm{n},\mathrm{t}}+\left({\mathrm{Demand}}_{\mathrm{t}}+{\mathrm{Production}}_{\mathrm{t}}\right)·\frac{\mathrm{Ts}}{60}$$

(4)

$${\mathrm{EVSESoC}}_{\mathrm{n},\mathrm{t}}={\mathrm{EVSESoC}}_{\mathrm{n},\mathrm{t}-1}+{\mathrm{EVSEEnergy}}_{\mathrm{n},\mathrm{t}}\mathrm{n}\in \left[0,\mathrm{N}-1\right],\mathrm{t}\in \left[0,\mathrm{T}-1\right]$$

(5)

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.

$${\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}\le {\mathrm{SupplyPointEnergyIsImporting}}_{\mathrm{t}}·\mathrm{SupplyPointPMax}·\frac{\mathrm{Ts}}{60}$$

(6)

$${\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}\ge {\mathrm{SupplyPointEnergyIsExporting}}_{\mathrm{t}}·\mathrm{SupplyPointPMin}·\frac{\mathrm{Ts}}{60}$$

(7)

$${\mathrm{SupplyPointEnergyIsImporting}}_{\mathrm{t}}+{\mathrm{SupplyPointEnergyIsExporting}}_{\mathrm{t}}=1$$

(8)

Secondly, two new variables, SupplyPointEnergyImported and SupplyPointEnergyExported, 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

$$\begin{array}{l}{\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}\\ \le {\mathrm{SupplyPointEnergy}}_{\mathrm{t}}-\left(1-{\mathrm{SupplyPointEnergyIsImporting}}_{\mathrm{t}}\right)·\mathrm{SupplyPointPMin}·\frac{\mathrm{Ts}}{60}\end{array}$$

(9)

$$\begin{array}{l}{\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}\\ \ge {\mathrm{SupplyPointEnergy}}_{\mathrm{t}}-\left(1-{\mathrm{SupplyPointEnergyIsImporting}}_{\mathrm{t}}\right)·\mathrm{SupplyPointPMax}·\frac{\mathrm{Ts}}{60}\end{array}$$

(10)

$${\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}\ge 0$$

(11)

$${\mathrm{SupplyPointEnergyExported}}_{\mathrm{t}}\le \mathrm{SupplyPointPMax}·{\mathrm{SupplyPointEnergyIsExporting}}_{\mathrm{t}}·\frac{\mathrm{Ts}}{60}$$

(12)

$$\begin{array}{l}{\mathrm{SupplyPointEnergyExported}}_{\mathrm{t}}\\ \le {\mathrm{SupplyPointEnergy}}_{\mathrm{t}}-\left(1-{\mathrm{SupplyPointEnergyIsExporting}}_{\mathrm{t}}\right)·\mathrm{SupplyPointPMin}·\frac{\mathrm{Ts}}{60}\end{array}$$

(13)

$$\begin{array}{l}{\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}\\ \le {\mathrm{SupplyPointEnergy}}_{\mathrm{t}}-\left(1-{\mathrm{SupplyPointEnergyIsImporting}}_{\mathrm{t}}\right)·\mathrm{SupplyPointPMin}·\frac{\mathrm{Ts}}{60}\end{array}$$

(14)

$$\begin{array}{l}{\mathrm{SupplyPointEnergyExported}}_{\mathrm{t}}\\ \ge {\mathrm{SupplyPointEnergy}}_{\mathrm{t}}-\left(1-{\mathrm{SupplyPointEnergyIsExporting}}_{\mathrm{t}}\right)·\mathrm{SupplyPointPMax}·\frac{\mathrm{Ts}}{60}\end{array}$$

(15)

$${\mathrm{SupplyPointEnergyExported}}_{\mathrm{t}}\le 0$$

(16)

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):

$${\mathrm{EVSESoC}}_{\mathrm{n},\mathrm{t}}\ge 0\mathrm{n}\in \left[0,\mathrm{N}-1\right],\mathrm{t}\in \left[0,\mathrm{T}-1\right]$$

(17)

$${\mathrm{EVSESoC}}_{\mathrm{n},\mathrm{t}}\le {\mathrm{EVSECapacity}}_{\mathrm{n}}\mathrm{n}\in \left[0,\mathrm{N}-1\right],\mathrm{t}\in \left[0,\mathrm{T}-1\right]$$

(18)

$${\mathrm{EVSESoC}}_{\mathrm{n},{\mathrm{TargetSlot}}_{\mathrm{n}}}\ge {\mathrm{EVSECapacity}}_{\mathrm{n}}·{\mathrm{TargetSoC}}_{\mathrm{n}}\mathrm{n}\in \left[0,\mathrm{N}-1\right]$$

(19)

Power flow at supply point cannot exceed the limitation of total (imported) power at on-site supply point (20):

$${\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}·\frac{60}{{\mathrm{T}}_{\mathrm{s}}}\le \mathrm{SupplyPointPMax}\mathrm{t}\in \left[0,\mathrm{T}-1\right]$$

(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).

$${\mathrm{EVSEEnergy}}_{\mathrm{n},\mathrm{t}}\ge 0\mathrm{n}\in \left[0,\mathrm{N}-1\right]\mathrm{t}\in \left[0,\mathrm{T}-1\right]$$

(21)

$${\mathrm{EVSEEnergy}}_{\mathrm{n},\mathrm{t}}·\frac{60}{{\mathrm{T}}_{\mathrm{s}}}\le {\mathrm{EVSEPower}}_{\mathrm{n}}\mathrm{n}\in \left[0,\mathrm{N}-1\right]\mathrm{t}\in \left[0,\mathrm{T}-1\right]$$

(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:

$${\mathrm{EVSEEnergy}}_{\mathrm{n},\mathrm{t}}·\frac{60}{{\mathrm{T}}_{\mathrm{s}}}\ge {\mathrm{EVSEDischargePower}}_{\mathrm{n}}\mathrm{n}\in \left[0,\mathrm{N}-1\right]\mathrm{t}\in \left[0,\mathrm{T}-1\right]$$

(23)

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:

$$\begin{gathered} {\mathrm{SupplyPointEnergyImported}}_{\mathrm{t}}·\frac{60}{{\mathrm{T}}_{\mathrm{s}}}\le \left(\mathrm{SupplyPointPMax}+{\mathrm{Flexibility}}_{\mathrm{t}}\right) \\ \mathrm{t}\in \left[0,\mathrm{T}-1\right] \end{gathered}$$

(24)

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:

• Number of slots an EVSE has been occupied prior to the execution of the optimization (time the charge session has taken place so far, measured in slots) (PreviousSlots_n)
• Opportunity cost faced per duration of the charge session (linear cost) (OpportunityCost) (€/slot)

Additional binary variables TargetSoCNotReached are also introduced to keep track of the expected finalization of the charging sessions, thus making it possible to calculate associated opportunity costs accordingly. Given a particular EVSE and slot, the corresponding variable signals whether the charging session is finalized. The constraints that define the values of these new variables are defined in Equations (25) and (26).

$${\mathrm{TargetSoCNotReached}}_{\mathrm{n},\mathrm{t}}\le \left({\mathrm{TargetSoC}}_{\mathrm{n}}-{\mathrm{EVSESoC}}_{\mathrm{n},\mathrm{t}}\right)$$

(25)

$$\left({\mathrm{TargetSoC}}_{\mathrm{n}}-{\mathrm{EVSESoC}}_{\mathrm{n},\mathrm{t}}\right)\le {\mathrm{TargetSoCNotReached}}_{\mathrm{n},\mathrm{t}}·{\mathrm{EVSECapacity}}_{\mathrm{n}}$$

(26)

In addition, the objective function has been modified in order to introduce the opportunity costs:

$$\begin{array}{cc}\hfill F=& \mathrm{minimize}({\displaystyle \sum _{\mathrm{n}=0}^{\mathrm{N}-1}}{\mathrm{PreviousSlots}}_{\mathrm{n}}·\mathrm{OpportunityCost}+({\displaystyle \sum _{\mathrm{t}=0}^{\mathrm{T}-1}}{\mathrm{energyImportedCost}}_{\mathrm{t}}\hfill \\ & +{\displaystyle \sum _{\mathrm{n}=0}^{\mathrm{N}-1}}{\mathrm{TargetSoCNotReached}}_{\mathrm{n},\mathrm{t}}·\mathrm{OpportunityCost}))\end{array}$$

(27)

A simulation of the power status for the TwinEV module that deals with the grid operators (DSO, CPO) is depicted in Figure 3.

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.

4.1. 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.

4.2. 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 the restriction, the date of the command, if includes V2G). Only administrators can access a screen for managing users.

4.3. 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.

5. 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: Figure 7, Figure 8 and Figure 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 8 depicts the flow of actions for a reservation in case the user exceeds the time to start the charge. 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. Use case information template.

Information	Description
Module under test	The module to be tested
Elements validated	The requirement, use case, or certification rule, which is validated by the test case.
Features to be tested	List of features to be tested
Preconditions (optional)	List of conditions needed for the test execution
Previous steps (optional)	Shortlist of steps needed for preparing the test environment for test execution
Dependencies (optional)	List of test case codes defining test cases which need to be passed before the test case at hand can be started
Steps	Testing procedures
Postconditions	Status after the execution of the test
Acceptance criteria	Expected (measurable) results, allowing to unambiguously judge if the test is passed or not passed (i.e., the product requirement was validated or not validated)
Suspension criteria (Optional)	Conditions under which continuation of the test is considered pointless because testing results would be invalid

.

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. List of test cases.

Identifier	Name	Module
TWINEV_DRVR_1	Searching of charge points in an area	TwinEV for drivers
TWINEV_ DRVR_2	Reservation of a public charge point	TwinEV for drivers
TWINEV_ DRVR_3_1	Start a charge session of a reserved charge point (grid requests)	TwinEV for drivers
TWINEV_ DRVR_3_2	Start a charge session of a reserved charge point (RES integration)	TwinEV for drivers
TWINEV_ DRVR_3_3	Start a charge session of a reserved charge point (RES integration-v2g)	TwinEV for drivers
TWINEV_ DRVR_3_4	Start a charge session of a reserved charge point (minimal charge costs)	TwinEV for drivers
TWINEV_ DRVR_3_5	Start a charge session of a reserved charge point (charge time)	TwinEV for drivers
TWINEV_ DRVR_4	Start a charge session of a private charge point	TwinEV for drivers
TWINEV_ DRVR_5	Manual stop of a charge session	TwinEV for drivers
TWINEV_ DRVR_6	Automatic stop of a charge session	TwinEV for drivers
TWINEV_GRD_1	Add a new restriction	TwinEV for grid operators
TWINEV_GRD_2	Check a restriction effect	TwinEV for grid operators
TWINEV_DSHB_1	Transactions	TwinEV dashboard
TWINEV_DSHB_2	Commands	TwinEV dashboard
TWINEV_DSHB_3	System statistics reflecting actions by drivers and grid operators	TwinEV dashboard

.

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.

Figure 10, Figure 11 and Figure 12 show different situations where SCT calculates the charging profile for three EVs charging. These figures support a grid operator to manage the power demands of different assets that may vary during the day (EV charging and Battery discharging) in a centralized platform. For simplification, all vehicles are charged in the same maximal time. In all figures, the charts from top to bottom are:

• 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.
• 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.
• Charging profiles [W]. This diagram represents the fluctuation of the power supplied to each vehicle in the given period.
• 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 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.

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.

6. 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 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.