Bidirectional Power Transfer for a Smart Load Management for Electric Vehicles

Abstract The global expansion of electromobility is progressing rapidly. The chinese city of Shenzhen has the world’s first and largest fleet of electric buses with more than 16,000 buses. A gigantic charging infrastructure for 5805 electric buses was established to cope with this. It reaches peak loads of 464.4 megawatts which is an enormous challenge to the grid. The use of a smart load management to avoid peak loads is indispensable. In combination with the Bidirectional Power Transfer (BPT), new perspectives open up and smart load management is efficiently enhanced.
The objective of this paper was the analysis and evaluation of the BPT for a smart load management for Electric Vehicles (EVs) regarding depot charging. This paper explains the relevant technologies and standards with respect to BPT. This was followed by the extension of Open Charge Point Protocol (OCPP) 2.0 for BPT, a prerequisite for the prototype implementation of the optimization algorithm including various strategies.
The results reveal that load management for depot charging profits substantially from BPT and that optimized planning in advance is a key factor, albeit increasing complexity. Currently, the amount of BPT-enabled EVs is marginal and certain relevant standardizations have not been adapted yet. The results of this paper contribute to an efficient and smart load management and the necessary adaptations of the standardizations towards the future growth of BPT-enabled EVs.

Index Terms E-Mobility, Smart Load Management, Bidirectional Power Transfer, ISO 15118-20 DIS, ISO 15118-2, OCPP 2.0, OSCP 2.0, OpenADR 2.0, Optimization


I. Introduction

THE global growth in e-mobility is proceeding rapidly. The number of EVs sold almost doubled to two million in 2018 compared with the previous year. The Chinese market, followed by Europe and the United States, is primarily responsible for these sales with 1.1 million EVs [10].
In 2011, a bus fleet electrification initiative was launched in the Chinese city of Shenzhen. Shenzhen was the first city to operate a fleet of approximately 16300 electric buses in 2017. A charging infrastructure of 86 depots for a total of 5805 buses was set up to cope with such an enormous amount of EVs, reaching a peak load of 464.4 megawatts. The essence of the Shenzhen program is to completely rethink the perception of electricity and vehicles. Experts in both the energy and transport sectors must embrace the insight that electric vehicles surpass mere vehicles [14].
The necessity for smart load management to minimize peak loads is therefore indispensable. In conjunction with the BPT, new perspectives open up and smart load management is effectively enhanced.
To motivate an integration of BPT into a smart load management system, a large variety of opportunities exist. Conventional load management enables power consumption of EVs at Charging Stations (CSs) to be controlled. As far as overload situations in the power grid are concerned, only the load of the EVs may be dropped, whereas BPT allows active stabilization. In addition, smart load management with BPT-enabled EVs eliminates overload situations by drawing additional power locally from other EVs. Cost-optimized load management is intensified due to BPT, as electricity can be charged inexpensively and discharged or sold profitably. In the residential sector, smart home load management offers the option of operating BPT-capable EVs as emergency power generators. The full potential of renewable energy sources are leveraged by load management with BPT since EVs provide flexible energy storage and sources. Furthermore, increasing research in accumulator technology will lead to advances in capacity as well as charging and discharging speeds. As a result, the relevance and scope of load management will expand in future.
Smart load management with BPT is only one key aspect towards achieving the aforementioned scenarios. The overall system depends on a large number of various actors requiring coordination. Currently this process remains incomplete. Therefore simplifications are made within this paper. The characteristic of smart grids to measure power consumption in low voltage grids is considered given. In addition, electro-technical aspects are simplified to a certain extent. Interaction among the affected actors is crucial to the overall function. Load management takes a key role in the respective use cases. Various use cases exist for load management, all of which lead to different solutions. In this paper, smart load management with BPT support considering the use case of depot charging is targeted.
The objective of this paper is the analysis and evaluation of this smart load management. Load management is a component of the Charging Station Management System (CSMS) or Charge Point Operator (CPO), which is illustrated in Figure 1.

PIC Figure 1.  Overview of the project objective

BPT-enabled EVs and CSs are essential prerequisites for bidirectional charging. Additionally, direct communication with the CSMS must support BPT. Communication to the CSs via OCPP 2.0 and to the Distributed System Operator (DSO) via Open Smart Charging Protocol (OSCP) 2.0 are particularly relevant. CHArge de MOve (CHAdeMO) and Guóbiao tuijiàn Standard (GB/T) communication standards are neglected despite a large market share, as they are not part of OCPP or similar protocols. Generally the use case of depot charging is the main focus and serves as a foundation to optimize load management. Accordingly, the primary task of load management is to calculate the optimum power distribution of charge and discharge of electric buses considering the demands of the DSO.

II. State of Technology

The e-mobility ecosystem consists of a variety of interrelated actors. Figure 2 depicts the relationship among the individual actors and the available communication standards with respect to BPT.

PIC Figure 2.  Overview of the e-mobility ecosystem with respect to BPT

Communication between EV and Electric Vehicle Supply Equipment (EVSE) is crucial for BPT. Currently, it is only supported by the standards CHAdeMO and International Organization for Standardization (ISO) 15118-20 Draft International Standard (DIS). According to ISO 15118-20 DIS, so-called PowerSchedules and PowerDischargeSchedules can be interchanged among an EV and an EVSE before and during charging. The Figure 3 indicates the correlation between these Schedules.

PIC Figure 3.  ISO 15118-20 DIS PowerSchedules and PowerDischargeSchedules applying for Flexible Schedule Mode

Moreover, the two control modes Flexible Schedule Mode and Dynamic Control Mode are specified. The Battery Management System (BMS) of the EV can calculate its own charge or discharge curve based on these Schedules. This curve must be within the limits of the PowerSchedules and PowerDischargeSchedules. In Dynamic Control Mode the EVSE is master of the charging procedure. It dictates a PowerSchedule to the EV, leaving the EV with no other choice. The EV can inform the EVSE about its charging needs and limits before the current flows. The parameters EVTargetEnergyRequest, EVMaximumEnergyRequest, EVMinimumEnergyRequest, EVMaximumChargePower, EVMinimumChargePower, EVMaximumDischargePower and EVMinimumDischargePower are critical for BPT in load management. Figure 4 illustrates the relations of the actual EVTargetEnergy, EVMaximumEnergy and EVMinimumEnergy as well as the corresponding Requests [11]. The blue curve in Figure 4 represents the EVCurrentEnergy over time. The differences between the respective energy levels with the EVCurrentEnergy constitute the parameters EVTargetEnergyRequest, EVMaximumEnergyRequest and EVMinimumEnergyRequest.

PIC Figure 4.  ChargingEnergyLimitations

A negative EVMinimumEnergyRequest poses an unique characteristic for BPT. In this state charging only is possible. BPT is allowed only if the EVCurrentEnergy level is within EVMaximumEnergy and EVMinimumEnergy [11].
The communication between EVSE and CPO is decisive for load management. It can be implemented by International Electrotechnical Commission (IEC) 61850-90-8, OCPP, IEC 63110 or proprietary protocols, although OCPP is most common. Essentially, the tasks consist of controlling charging procedures, configuration, maintenance, payment and monitoring of EVSEs. These protocols do not support BPT currently, thus within this paper OCPP 2.0 has been extended to include BPT. The standard ISO 15118-2 is supported by OCPP 2.0 for the first time, whereby necessary adaptations are manageable [1], [3], [8], [13].

Communication between CPO and DSO enables the grid integration of load management. Especially in the context of BPT new possibilities arise. In this environment there are a number of protocols, where Open Automated Demand Response (OpenADR) 2.0 is the most common. On the other hand OSCP has been developed by Open Charge Aliance (OCA) with respect to OCPP. In general, both protocols propagate the power provided by the DSO to affect the active charging procedures managed by the CPO. In addition, the CPO can send signals to the DSO for monitoring purposes. The integration of OpenADR 2.0 with OCPP is described within a white paper published by the OCA. OpenADR 2.0 defines the so-called Virtual Top Nodes (VTNs) and Virtual End Nodes (VENs), where one VTN can represent a VEN to another VTNs. Thereby a hierarchy can be constructed. It is recommended to define the CPO as VEN in relation to the DSO or VTN. If the DSO detects an overload situation in the power grid, it triggers the messages IEvent or the events LOAD_DISPATCH and LOAD_CONTROL. The CPO translates this information into SetChargingProfile messages to be send to the CSs [2], [4], [5], [6].

The communication among the CPO and other actors allows user management and payment. This communication is important in order to achieve a user-optimized load management, i. e. to favour or penalize certain user groups. In terms of BPT and depot charging, this is less relevant.

The electro-technical fundamentals have an enormous impact both on the requirements and the functionality of load management. The most important aspects are the Kirchhoff’s circuit laws.
The first Kirchhoff’s circuit law is known under the current law and defines the behavior of the currents in a node. A node is described as a point in an electrical circuit with at least three connections to circuit elements. The current can branch at this point. The first Kirchhoff’s circuit law formulates the sum of the incoming currents to be equal to the sum of the outgoing currents in a node of an electrical circuit.
The second Kirchhoff’s circuit law known as the voltage law defines the behavior of voltages in a mesh. A mesh is described as a closed loop in an electrical circuit with at least two branches. The second Kirchhoff’s circuit law defines the sum of the partial voltages in a mesh of an electrical circuit to be zero.
Additional crucial elements are bus bars within switch gears. Switch gears are a key component of the power grid. Switch gears form the interface between feed-in and feed-out of a network node. Their bus bars represent the network nodes connecting grids of different voltage levels. A switch gear provides the actual power distribution as well as the aggregation of consumers and generators [16].

The load management of this paper has been influenced by an existing load management. However, it did not take these concepts of bus bars into account. Nevertheless, the concept of a so-called Topology was adapted and reinterpreted. A Topology abstracts the electrical circuit elements from the grid access point to the CSs and EVs. A simplified view of an example Topology with EVs is illustrated in Figure 5.

This Topology provides an abstract model for optimization. The links between the nodes in Figure 5 are displayed in one direction only.

Figure 5.  Top down view of a sample Topology with EVs including three charging stations and five EVSEs

In reality there are two-way links to map the BPT. Figure 6 demonstrates a possible model of a bus bar (BB).

In order to improve the existing load management, the issue is reconsidered upon the integration of BPT. This can be mathematically formulated as Maximum Flow Problem. The Maximum Flow Problem can be modelled on a digraph whose edges contain maximum flow capacities between nodes.

Figure 6.  Model mapping of a bus bar into two nodes

The objective of the Maximum Flow Problem is to propagate a maximum flow within this digraph from a source s to a sink t. Figure 7 illustrates such a digraph.

Figure 7.  Example digraph representing the Maximum Flow Problem

The mathematical assignment of flow is affected by the so-called Capacity Constraints and Flow Conversation Constraints. Capacity Constraints are formulated as inequalities. They define the capacity for each edge of the digraph. Flow Conversation Constraints are equations defining the flow rate for each node except the source and sink. The sum of the flow values leading to a node must be equal to the sum of the flow values leaving that node. By means of these Flow Conversation Constraints the first Kirchhoff’s circuit law is fulfilled.

To solve the Maximum Flow Problem different methods exist, which include the Linear Optimization, the Dinic’s Algorithm and the Ford-Fulkerson Algorithm. This paper focuses on Linear Optimization.

max.       cTx
     s.t.    Ax = b
              x = 0                                         (1)

The vector x represents the variables to be determined. The vectors c and b and the matrix A define known coefficients. The objective function cTx is maximized with respect to the conditions Ax = b and x = 0. The solution set of this linear objective function resembles a convex polytope or simplex [17].

III. Results

The extension of OCPP 2.0 for BPT is the prerequisite for the integration of BPTs into load management. The messages NotifyEVChargingNeedsRequest, NotifyCentralChargingNeedsRequest and NotifyEVChargingScheduleRequest were altered and enhanced to exchange the essential BPT specific parameters among CS and CPO.
The message NotifyEVChargingNeedsRequest was extended by the EV parameters mentioned in section II, such as EvMaximumEnergyRequest and EvMaximumDischargePower. Utilizing the extensions to the message NotifyCentralChargingNeedsRequest, load management can communicate the Control Mode and one or more charging profiles for charging and discharging including price information to EV via CS. In the context of the extended message NotifyEVChargingScheduleRequest the EV informs the load management not only about the charging profile being used, but also about it’s Control Mode.

After achieving the foundation via this protocol extension, a generator for load management test scenarios was created. The generator allows to create Topologys of any complexity and number of charging procedures. BPT specific parameters relevant to load management, such as the maximum charge or discharge power of the EVs or charging stations or the desired energy amount at departure can be generated using configurable distribution functions.

By means of these generated test scenarios the strategies Priority-, Equal- and Planning-Strategy for load management developed in this paper were evaluated.
A Strategy calculates the power distribution of all active charging processes of a Topology for a certain time frame. The result of a Strategy is indicated by two lists. The first list represents the execution priority. The second list embodies the percentage of available maximum power. The charging process with the highest execution priority is processed first. The power is assigned using the percentage of the maximum power. A percentage of the maximum charging power of 100% with the highest execution priority results in the maximum charging power for this charging process in this period. A percentage of the maximum charge power of 0% with the highest execution priority results in no power in that period. Similarly, a negative percentage of the maximum discharge power will provide the corresponding discharge power for this period.
The Equal-Strategy is the simplest Strategy. It realizes an equal distribution of the power over all active charging processes. The Equal-Strategy always provides the same execution priority and a maximum power percentage of 100%. This Strategy can be extended by reducing all maximum power percentages by 100%. This reduction can be used to control the total power consumption, thus responding to current price fluctuations and grid situations. In addition, aggregation of charging processes is possible, with each group having a different percentage of maximum power. The charging processes in a group have the same maximum power percentage.

The Priority-Strategy is primarily based on execution priorities. Any external dependencies can be mapped to the power distribution, in particular existing planning and scheduling systems. Analogous to the Equal-Strategy it may be expanded, by altering the percentage maximum power. In general, the Priority-Strategy and Equal-Strategy can be mapped to each other. The grouping of the Equal-Strategy allows different percentage maximum power levels to be defined. The smaller the groups, the greater the similarity between Equal-Strategy and Priority-Strategy. The reverse is also true.

According to its name, the Planning-Strategy assigns power based on a pre-calculated plan. This plan represents a time-discrete power assignment of parallel charging processes of a Topology. The plan is calculated consisting of a two-step procedure using Linear Optimization.
In the first step, the objective function is formulated in a way that the energy charged at the beginning of the charging processes is maximized. Negative energy amounts corresponding to discharging are excluded in this step by means of constraints. In addition, further constraints ensure that the charging and discharging limits of the Topology, EVs and the charging power already assigned and the EVMaximumEnergyRequest and EVTargetEnergyRequest are not exceeded. On the basis of this result the required partial energy amounts are determined, which are necessary to reach the EVMinimumEnergy of the charging processes with positive EVMinimumEnergyRequest. In the next step, the partial energy amounts of the discrete time steps are marked as constant until the EVMinimumEnergy is reached. This prevents discharge before the EVMinimumEnergy is reached.
The second Linear Optimization thus calculates the partial energy amounts additionally charged and discharged in favor of others EVs.
The optimization of this planning offers numerous degrees of freedom, such as the factors of the objective function, the constraints or the number of variables. The factors of the objective function are crucial due to maximizing or minimizing the energy amounts to be assigned to the charging processes as well as the partial amounts of energy to be controlled within them.
For each charging process the desired power curve is adjustable, thus flat or steep power gradients are possible. Different criteria for prioritizing energy amounts of the charging processes can be used. The start or end time as well as the duration of the charging processes are possible criteria.
A higher resolution of the charging processes by means of additional time-discrete steps results in more variables. On the one hand, this increases the problem complexity and the number of possible factors of the objective function. On the other hand, the power distribution of charging processes is controlled more precisely over time. Depending on the application, constraints can be added or removed. Another factor is the planning scope. The uncertainty of the forecasts and the number of variables increases with it, which adds to the problem complexity and decreases the quality of the results.
The planning allows to consider a day-ahead price forecast of the European Energy Exchange (EEX). In contrast to the Equal-Strategy and the Priority-Strategy, planning allows to react to future price fluctuations, by modeling them by means of the factors of the objective function.

The key results are presented in the Figures 9, 10 and 11. They illustrate the calculated charging profiles of the Strategies based on a generated test scenario with twelve EVSEs divided among ten charging stations. The Figures 8 and 9 display two possible charging profiles referring to one charging process of a EV.
The sample EV is capable of charging for 11.1 hours and has a maximum charging power of 150 kilowatts (kW). Charging power is limited to 140 kW due to the Topology. The EV is capable of BPT with a maximum discharge power of 80 kW, it can charge a maximum energy of 534 kilowatt hours (kWh) and requires a total energy of 324 kWh at departure time.

PIC Figure 8.  Example charging profile based on a simple Priority-Strategy

The Figure 8 depicts a charging profile for this EV based on the Priority-Strategy. This assigns the EV the maximum power until the desired energy amount is reached based on the priority. In comparison, the Figure 9 depicts a charging profile for this EV, which was calculated using the Planning-Strategy.

PIC Figure 9.  Example charging profile based on the Planning-Strategy with additional BPT

In this case, the EV is charged up to the maximum energy amount first, which allows discharging later. Thus another EV will receive additional power and will complete charging earlier. After all, only sufficient energy is discharged until the desired energy amount is reached at departure time.

The impact of this additional energy increases significantly in sum. The Topology has a maximum power of 300 kW enabling nine EVs to charge or discharge simultaneously. Analogous to the charging profile in figure 8, each incoming EV is assigned the maximum power until the desired energy amount is reached. In Figure 10 the maximum power consumption of the Topology exceeds starting from the eighth hour after charging the first EV. This is due to too large power assignments of the EVs.

PIC Figure 10.  Aggregated power and energy of the example Topology without load management

The Figure 11 illustrates the accumulated charging profiles and charged energy of the identical Topology using the load management with the Planning-Strategy.

PIC Figure 11.  Aggregated power and energy of the example Topology with load management using the Planning-Strategy

The maximum power consumption of the Topology of 300 kW is reached, but never exceeded. The power curve fluctuates less and yet the same total energy amount is reached due to BPT.

IV. Discussion and future work

This section provides a summary and discusses comparable load managements with respect to the load management of this paper. Subsequently, an outline of future work is presented.

The developed approach and the realization emphasize the fundamental feasibility and optimization of load management by means of the support of BPT. The results not only indicate that significant optimizations can be achieved within a load management system using BPTs, but that the necessary requirements can be conceptually combined with OCPP 2.0.
The results of the standardization of the e-mobility ecosystem reveal a large number of actors involved as well as a high degree of complexity in supporting BPT for load management. As a consequence, the electro-technical fundamentals, the protocol procedures and the optimization methods play a decisive role. The extension of OCPP 2.0 is a prerequisite for the feasibility of load management including the support of BPT. Based on these findings, the special characteristics regarding the use of depot charging are formulated. In addition, the standardization has not yet been completed, new technologies are opening up further opportunities and further research work is ongoing. Due to this uncertainty, the solution presented in this paper is deliberately flexible. The development of suitable extensions for OCPP 2.0 as well as optimization strategies have been developed in the meantime.
The implementation confirms the feasibility of the software design, the strategies and the extension of the OCPP. The results underline the potential of BPT in load management for the use case of depot charging. In addition, the relevance of planning ahead in load management is emphasized.

The load management developed by Detzler is based on the evolutionary algorithm. Test scenarios with varying numbers are examined. The evolutionary algorithm, consisting of recombination, selection and mutation, is applied in the following form. First a starting population of random individuals is generated. An individual represents a sequence of charging processes including power assignments for a certain period of time. Minima and maxima of the EV ensure that the assigned charging power of an individual is always within a valid value range. The evaluation of individuals is based on a cost function involving all EVs and the energy price. The recombination process depicted in Figure 12 begins by selecting two parent individuals of the current generation. A random cross-over point is selected, which is associated with a particular charging process in the sequence of the charging processes. The child individuals are created by dividing the parent individuals at the cross-over point and assembling each one with the complementary part of the other parent individual. The mutation distinguishes between three variants, changing only the order of particular charging processes, the charging power or both [9].
In the test scenarios of Detzler it was found that the fitness value of the algorithm converges after 100 generations. In addition, charging profiles for 200 vehicles at 100 generations could be calculated within 14 seconds [9].
Due to randomness, the runtime of the evolutionary algorithm is not deterministic. The memory consumption is constant, because the number of individuals remains constant over time. However, nonlinear constraints can be mapped.

PIC Figure 12.  Recombination of two individuums (Source: [9])

The use case of BPT is not considered, so a direct comparison is not possible. In addition, Topology conditions are modelled by means of a valid value range. The Topology conditions of this paper provide dependencies between the assigned EV powers. This increases the complexity during the creation of valid individuals, thus also increasing runtime.
Basically, the approach of Detzler is similarly promising as the one presented in this paper. However, only a direct comparison, examined in future work, provides certainty. The realization of this comparison can be done with an own Strategy based on the evolutionary algorithm.

The load management of Lee, Chang, Jin, et al. relies on an infrastructure consisting of a 50 kW Direct Current (DC) Fast Charger, consumers from a garage as well as its own three-phase alternating current transformer to which 54 type-2 EVSEs of 6.6 kW are subordinated. The load management procedure is an online scheduling procedure and requires discrete time steps. In addition, the amount of available EVs, the amount of active EVs and a EV state must be defined. The state of the EVs is represented by a tuple consisting of the requested energy amount, the remaining charging time, the maximum power of the EVs and a metering of the charged energy amount until the current time. Based on this data, the algorithm is performed in the following three steps:

  1. The amount of active EVs is determined using the plugged EVs with a remaining energy demand greater than zero.
  2. It is checked whether a new schedule has to be calculated, which can be triggered by events or a timeout.
  3. A new optimal schedule is calculated by maximizing an objective function using an optimization horizon.

The optimization horizon represents the constraints. The procedure is iterative, meaning that the state parameters for the next point in time are recalculated for each point in time for each EV. The objective function is determined by operator objectives in the form of regularization and weighting factors. This optimization offers various options. Charging according to a certain curve, e.g. the generation of renewable energies, the smoothing of the charging curve by minimizing the amount between the partial powers as well as fastest possible or evenly distributed charging are enabled. In addition, auxiliary conditions are defined which ensure that the charging power between a value of zero and the EV maximum power, the energy amount charged, the power limits of the infrastructure and the prevention of charging processes after departure time are ensured. Furthermore, Lee, Chang, Jin, et al. define so-called Second Order Cone conditions that utilize specific properties of the three-phase AC transformer. The Second Order Cone conditions improve the phase imbalance in the three-phase grid. Moreover, non-ideal charging behavior is counteracted by increasing the calculation frequency [12].
 The iterative procedure is similar to the one presented in this paper. It differs in its absence of planning.. On the one hand, this results in the advantage of reduced complexity, as the calculations need to cover a short period of time. On the other hand, planned changes are difficult to consider.

The primary concern in the project by Projektplaner LEW is on use of locally produced Photovoltaic (PV) power for charging of electric vehicles. The BPT is thus represented by the PV system. The intended fields of application are fleets and car parks. In the project eight Alternating Current (AC)-CSs with two charge points of 22 kW each were installed, thus having an aggregated maximum power of 352 kW. The aggregated maximum power was limited to 100 kW by the load management. 78 % of the EVs had a standing duration between 8 and 14 hours.
 The load management calculates the charging profiles using Linear Optimization based on a cost function depending on the EEX electricity prices and the PV energy, taking into account the minimum and maximum power of the EVs. By means of an additional uncertainty factor it is ensured that the EVs are fully charged even with earlier departure. An underestimation of the actual charge duration compensates for the modelling error of a permanently constant power. Due to the charging characteristics of lithium-ion batteries, a permanently constant power is not feasible. The project involved 56 volunteers over a period of two years. During the test phase, various findings were obtained. This includes the fact that not all EVs support the ISO 15118-2, some EVs switch off at too low power and the creation of the charging profiles took longer than three minutes and thus too long. The use of PV energy was increased by more than 40 % [15], [7].
 This load management does not consider Topology conditions. In addition, the problem of skew load is not addressed. One option to counteract this is the use of OCPP in combination with charging stations, enabling to select the phase to be used. Possibly a skew load was counteracted during installation by rotating phase assignment of the charging stations to the grid. In this way, if the charging stations are used uniformly, all phases are balanced. A lesson of considering a minimum output power can be derived from this.

The paper by Wolpert and Macready proves the proposition that a universal method for solving an optimization problem does not exist considering the set of all problems. This proposition is presented in the form of the following two theorems.

The average performance of two algorithms for a set of optimization problems is independent of the algorithm selected.
If one algorithm performs better than another for one particular cost dynamics, the opposite is true for all other cost dynamics [18].
Basically these theorems confirm the results of this paper and this discussion. Depending on the use case there are different requirements and therefore different optimization problems. To develop a universal method, being optimal for all use cases, is not feasible. However, several diverse and specially adapted algorithms can provide reliable and efficient solutions. The flexibility to exchange these algorithms at runtime is key. It is ensured by the adaptability of the software design and implementation corresponding to this paper.

Finally, it should be noted that load management with the support of BPT holds enormous potential for a variety of applications, especially for depot charging. Furthermore, a successful integration into the existing e-mobility ecosystem is possible despite high complexity. Currently there is an uncertainty of the standardization, due to ongoing development of the standard ISO 15118-20 DIS and additional factors, such as the integration of other protocols like CHAdeMO or Deutsches Institut für Normung eV (DIN) 70121. The developed software design as well as the prototypical implementation thus have a high adaptability for potential changes of the standardizations. The intention in ISO 15118-20 to introduce an additional data type for the charging profiles in Dynamic Control Mode is an example of such a current new feature.
Presently, this solution provides promising results for the use case of depot charging. In particular, the BPT represents a valuable enhancement in terms of optimization compared to other load management systems. In future the extension of the generator for test scenarios is conceivable, in order to produce further use cases and detailed sample data. Additional strategies can be developed and existing ones can be optimized. By means of a simulation these can be validated in the long term. Moreover, they can be employed in a future collaboration with a DSO in order to gain practical insights.


[1] Alliance, Open Charge. 2015a. Open Charge Point Protocol 2.0: Part 2 – Specification. Open Charge Alliance.

[2] ———. 2015b. Open Smart Charging Protocol 1.0 – Interface Description Between Dso and Central System. Open Charge Alliance.

[3] ———. 2017. Open Charge Point Protocol 1.5. Open Charge Alliance.

[4] ———. 2019. Open Smart Charging Protocol 2.0 – Specification Draft Use Case Proposal. Open Charge Alliance.

[5] Alliance, OpenADR. 2012. OpenADR 2.0 Profile Specification A Profile. OpenADR Alliance.

[6] ———. 2015. OpenADR 2.0 Profile Specification B Profile. OpenADR Alliance.

[7] Carron, Virgile. 2014. Untersuchung Geeigneter Optimierungsstrategien Zur Umsetzung Eines Intelligenten Lademanagements Für Elektrofahrzeuge. Hochschule für angewandte Wissenschaften München.

[8] Commission, International Electrotechnical. 2016. Technical Report 61850-90-8: Communication Networks and Systems for Power Utility Automation – Part 90-8: Object Model for E-Mobility. International Electrotechnical Commission.

[9] Detzler, Sarah Katharina. 2017. “Lademanagement Für Elektrofahrzeuge.” PhD thesis, Karlsruher Institut für Technologie (KIT); KIT Scientific Publishing, Karlsruhe. doi:10.5445/KSP/1000057827.

[10] IEA. 2019. Global Ev Outlook 2019. IEA.

[11] ISO/IEC. 2018. “ISO/IEC DIS 15118-20: Road vehicles – Vehicle to grid communication interface – Part 2: Network and application protocol requirements.”

[12] Lee, Z. J., D. Chang, C. Jin, G. S. Lee, R. Lee, T. Lee, and S. H. Low. 2018. “Large-Scale Adaptive Electric Vehicle Charging.” In 2018 Ieee Global Conference on Signal and Information Processing (Globalsip), 863–64. doi:10.1109/GlobalSIP.2018.8646472.

[13] Mültin, Dr. Marc. 2017. IEC 63110 – Standardizing the Management of Electric Vehicle (Dis-)Charging Infrastructures. V2G Clarity.

[14] Poon, Linda. 2019. Why U.s. Cities Aren’t Using More Electric Buses. Citylab.

[15] Projektplaner LEW, LVN und FfE. 2017. Lademanagement an Park and Ride Parkplätzen. Innovations- und Technologiezentrum.

[16] Schwab, Adolf J. 2009. Elektroenergiesysteme – Erzeugung, Transport, übertragung Und Verteilung Elektrischer Energie. 2. Aufl. Berlin Heidelberg New York: Springer-Verlag.

[17] Suhl, Leena, and Taïeb Mellouli. 2013. “2 Lineare Optimierungsmodelle.” In Optimierungssysteme: Modelle, Verfahren, Software, Anwendungen, 31–76. Berlin, Heidelberg: Springer Berlin Heidelberg. doi:10.1007/978-3-642-38937-5_3.

[18] Wolpert, D. H., and W. G. Macready. 1997. “No Free Lunch Theorems for Optimization.” Trans. Evol. Comp 1 (1). Piscataway, NJ, USA: IEEE Press: 67–82. doi:10.1109/4235.585893.

JavaScript Performance optimization with respect to the upcoming WebAssembly standard

Written by Tim Tenckhoff – tt031 | Computer Science and Media

1. Introduction

Speed and performance of the (worldwide) web advanced considerably over the last decades. With the development of sites more heavily reliant on JavaScript (JS Optimization, 2018), the consideration of actions to optimize the speed and performance of web applications grows in importance. This blogpost aims to summarize practical techniques to enhance the performance of JavaScript applications and provides a comparative outlook regarding the upcoming WebAssembly standard.

Let´s jump into hyperspeed…

  1. Introduction
    1. JavaScript 
    2. Why optimize? 
  2. How can the JavaScript Speed and Performance be increased?
    1. Interaction with Host Objects
    2. Dependency Management
    3. Event Binding
    4. Efficient Iterations
    5. Syntax 
  3. Is WebAssembly replacing JavaScript?
  4. References


Back in the days, in 1993 a company called Netscape was founded in America. Netscape aimed to exploit the potential of the burgeoning World Wide Web and created their own web browser Netscape Navigator (Speaking JavaScript 2014). As Netscape realized in 1995, that the web needed to become more dynamic, they decided to develop a scripting language with a syntax similar to Java’s to rule out other existing languages. In May 1995, the prototype of this language was written by the freshly hired software developer Brendan Eich within 10 days. The initial name of the created code was Mocha, which was later changed by the marketing to LiveScript. In December 1995, it was finally renamed to JavaScript to benefit from Java’s popularity (Speaking JavaScript 2014).

Today, every time the functionality of a web page exceeds to just display static content, e.g. by timely content updates, animated graphics, an interactive map or the submission of an input formular, JavaScript is probably involved to solve the given complexity. Thus it is the third layer cake of the standard web technologies, which adds dynamic behavior to an existing markup structure (e.g. defining paragraphs, headings, and data tables in HTML), customized with a definition of style rules (e.g. defining paragraphs, headings, and data tables in CSS). If a web browser loads a webpage, the JavaScript code is executed by the browser’s engine, after the HTML and CSS have been assembled and rendered into a web page (JavaScript 2019). This ensures that the content of the required page is already in place before the JavaScript code starts to run, as seen in Figure 1.

Figure 1: The execution of HTML, CSS and JavaScript in the Browser (JS Optimization, 2018)

The script language often abbreviated as JS includes a curly-bracket syntax, dynamic typing, object orientation, and first-class functions. Initially only implemented in and for web browsers on the client side, today’s JavaScript engines are now embedded in many other types of host software, including web servers (e.g. NodeJS), databases, or other non-web use-cases (e.g. PDF software).

Why optimize?

Speaking about the performance optimization in networks, most developers think about it in terms of the download and execution cost – sending more bytes of JavaScript code takes longer, depending on the users internet connection (JS Optimization 2018). Therefore, it can be said beforehand, that it generally makes sense to reduce the transferred network traffic, especially in areas where the available network connection type of users might not be 4G or Wi-Fi. But one of JavaScript’s heaviest costs regarding the performance is also the parse/compile time. The Google Chrome browser visualizes the time spend in these phases in the performance panel as seen in Figure 2. But why is it even important to optimize this time?

Figure 2: Parse and compile time of JavaScript (JS Optimization 2018)

The answer is, that if more time is spent parsing/compiling, there might be a significant delay in the user’s interaction with the website. The longer it takes to parse and compile the code, the longer it takes until a site becomes interactive. According to a comparison in an article by Google Developer Addy Osmani, JS is more likely to negatively impact a pages interactivity than other equivalently sized resources (JS Optimization 2018). As an example seen in Figure 3, the resource processing time of 170kb JavaScript bytes and the same amount of JPEG bytes require the same amount of 3,4 seconds network transmission time. But as the resource processing time to decode the image (0,064 seconds) and rasterize paint in the image (0,028 seconds) are relatively low, it takes much longer to parse the JavaScript code (~2 seconds) and execute it (~1,5 seconds). Due the fact that website users differ not only regarding their provided network connection, but also in the hardware they have, older hardware may also have a bad influence on increased execution time. This shows how much more JS can potentially delay the interactivity of a website due to parse, compile and execution costs and proves the need for optimization.

Figure 3: The difference between JavaScript and JPEG resource processing (JS Optimization 2018)

2. How can the JavaScript Speed and Performance be increased?

The question appearing at this point is the following: What needs to be practically done during the development of JavaScript to optimize websites or web applications regarding speed and interactivity. The depths of the world wide web expose several blogs and articles about this kind of optimization. The following section aims to sum up found techniques categorized by the underlying performance problem:

Interaction with Host Objects

The interaction with “evil” host objects needs to be avoided as Steven de Salas says in his blog (25 Techniques 2012)

As described before, JavaScript code is compiled by the browser’s scripting engine to machine code – offering an extraordinary increase in performance and speed. However, the interaction with host objects (in the browser) outside this native JavaScript environment raises a loss in performance, especially if these host objects are screen-rendered DOM (Document Object Model) objects (25 Techniques 2012). To prevent this, the interaction with these evil host objects needs to be minimized. Let’s take a look at how this can be done.

Rotation via CSS

A first useful approach is the usage of CSS-classes for DOM animations or interactions. Unlike JavaScript code, solutions like e.g. CSS3 Transitions, @keyframes, :before, :after are highly optimized by the browser (25 Techniques 2012). As shown above, the rotation of the small white square can either be animated by addressing the id via document.getElementById(“rotateThisJS”), triggered by a button starting the rotate() function below…

Figure 4: Rotation via JavaScript (How not to…)

…or by adding a CSS class (as seen in Figure 5) to the <div> element which works much more efficiently, especially if the respective website contains several animations. Except from animations, CSS is also able to handle interactions like e.g. hovering elements, thus it can be said, that the way JavaScript is optimized this time is not to use it in certain cases.

Figure 5: Animation via CSS

Speaking of selectors to pick DOM elements, the usage of jQuery allows a highly specific selection of elements based on tag names, classes and CSS (25 Techniques 2012). But according to the online blog article by Steven de Salas, it is important to be aware that this approach involves the potential of several iterations through underlying DOM elements to find the respective match. He states that this can be improved by picking nodes by ID. An example can be seen in Figure 6:

Figure 6: Different ways of DOM element selection

What also increases the (DOM interaction) performance, is to store references to browser objects during instantiation. If it can be expected, that the respective website is not going to change after instantiation, references to the DOM structure should be stored initially, when the page is created not only when they are needed. It is generally a bad idea to instantiate references DOM objects over and over again. That’s why it is rather advisable to create few references to objects during instantiation which are needed several times (25 Techniques 2012). If no reference to a DOM object has been stored and needs to be instantiated within a function, a local variable containing a reference to the required DOM object can be created. This speeds up the iteration considerably as the local variable is stored in the fastest and most accessible part of the stack (25 Techniques 2012).

The general amount of DOM-elements is also a criteria with respect to the performance. As the time, used for changes in the DOM is proportional to the complexity of the rendered HTML, this should also be considered as an important performance factor (Speeding up 2010).

Another important aspect regarding the DOM interaction is to batch (style) changes. Every DOM change causes the browser to do a re-rendering of the whole UI (25 Techniques 2012). Therefore, it should be avoided to apply each style change separately. The ideal approach to prevent this, is to do changes in one step, for example by adding a CSS class. The different approaches can be seen in Figure 7 below.

Figure 7: How to batch changes in DOM

Additionally it is recommended to build DOM elements separately before adding them to a website. As said before, every DOM requires a re-rendering. If a part of the DOM is built “off-line” the impact of appending it in one go is much smaller (25 Techniques 2012). Another approach is to buffer DOM content in scrollable <div> elements and to remove elements from the DOM that are not displayed on the screen, for example, outside the visible area of a scrollable <div>. These nodes are then reattached if necessary (Speeding up 2010).

Dependency Management

Figure 8: Checking the dependency Management of

Looking at different pages in the www, e.g. the cities’s website of Stuttgart, it can be observed that the screen rendering is delayed for the user until all script dependencies are fully loaded. As seen in Figure 8, some dependencies cause the delayed download of other dependencies that in return have to wait for each other. To solve this problem the active management and reduction of the dependency payload are a core part of performance optimization.

One approach to do so, is to reduce the general dependency on libraries to a minimum (25 Techniques 2012). This can be done by using as much in-browser technology as possible. For example the usage of document.getElementById(‘element-ID’) instead of using (and including) the jQuery library. Before adding a library to the project, it makes sense to evaluate whether all the included features are needed, or if single features can be extracted from the library and added separately. If this is the case, it is of course important to check whether the adopted code is subject to a license – to credit and acknowledge the author is recommended in any case (25 Techniques 2012).

Another important approach is the combination of multiple JavaScript files to bundled ones. The reason behind this is, that one network request with e.g. 10kb of data is transferred much faster than 10 requests with 1kb each (25 Techniques 2012). This difference is caused by lower bandwidth usage and network latency of the single request. To save additional traffic, the combined bundle files can also be minified and compressed afterwards. Minification tools, such as UglifyJS or babel-minify remove comments and whitespacing from the code. Compression tools as e.g. gzip or Brotli are able to compress text-based resources to smaller memory size. (JS Optimization 2018)

A further way to optimize the dependency management, is the usage of a post-load dependency manager for libraries and modules. Tools like Webpack or RequireJS allow, that the layout and frame of a website appears before all of the content is downloaded, by post-loading the required files in the background (JS Optimization 2018). This gives users a few extra seconds to familiarise themselves with the page (25 Techniques 2012).

By maximizing the usage of caching, the browser downloads the needed dependencies only at the first call and otherwise accesses the local copy. This can be done by manually adding eTags to files that need to be cached, and putting *.js files to cache into static URI locations. This communicates the browser to prefer the cached copy of scripts for all pages after the initial one (25 Techniques 2012).

Event Binding

To create interactive and responsive web applications, event binding and handling is an essential part. However, event bindings are hard to track due to their ‘hidden’ execution and can potentially cause performance degradation e.g. if they are fired repeatedly (25 Techniques 2012). Therefore it is important to keep track of the event execution throughout various use cases of the developed code to make sure that events are not fired multiple times or bind unnecessary resources (25 Techniques 2012).

To do so, it is especially important to pay attention to event handlers that fire in quick repetition. Browser events such as e.g. ‘mouse move’ and ‘resize’ are executed up to several hundred times each second. Thus, it is important to ensure that an event handler that reacts to one of these events can complete in less than 2-3 milliseconds (25 Techniques 2012). The box below visualizes the amount of events that are fired when the mouse is moved over an element.

hover me!

Another important point that needs to be taken care of, is the event unbinding. Every time an event handler is added to the code, it makes sense to consider the point when it is no longer needed and to make sure that it stops firing at this point. (Speeding up 2010) This avoids performance slumps through handlers that are bound multiple times, or events firing when they are no longer needed. One good approach to prevent this, is the usage of once-off execution constructs like or manually adding/coding the unbind behavior at the right place and time (25 Techniques 2012). The example below, shows the usage of – an event binding on each p element that is fired exactly once and unbinds itself afterwards. The implementation of this example can be seen in Figure 9.

Click the boxes to trigger a event!
Fired once. Also fired once. This is also fired only once.
Figure 9: The usage of

A last important part of the event binding optimization is to consider and understand the concept of event bubbling. A blog article by Alfa Jango describes the underlying difference between .bind(), .live(), and .delegate() events (Event Bubbling 2011).

Figure 10: Propagation of a click event through the DOM (Event Bubbling 2011)

Figure 10 shows what happens if e.g e a link is clicked that fires the click event on the link element, which triggers functions that are bound to that element’s click event: The click event propagates up the tree, to the next parent element and then to each ancestor element that the click event was triggered on one of the descendent elements (Event Bubbling 2011). Knowing this, the difference between the jQuery functions bind(), live() and delegate() can be explained:


jQuery scans the entire document for all $(‘a’) and binds the alert function to each of these click events.


jQuery binds the function to the $(document) tag including the parameters ‘click’ and ‘a’. If the 
event is fired, it checks if both parameters are true, then executes the function.


Similar to .live(), but binds the handler to a specific element, not the document.root.

The article says that .delegate() is better than .live(). But why?

$(document).delegate(‘a’, ‘click’, function() { blah() });

$(‘a’).live(‘click’, function() { blah() });

According to the blog entry (Event Bubbling 2011), delegate() can be preferred for two reasons:

Speed: $(‘a’) first scans for all a elements and saves them as objects, this consumes space and is therefore slower.

Flexibility: live() is linked to the object set of $(‘a’) elements, although it actually acts at the $(document) level..

Efficient Iterations

The next topic is the implementation of efficient iterations. As seen in Figure 11 below, the execution time for string operations grows exponentially during long iterations (String Performance 2008). This shows why iterations can often be the reason for performance flaws. Therefore it always makes sense to get rid of unnecessary loops, or calls inside of loops (25 Techniques 2012) .

Figure 11: Comparative String Performance Analysis (String Performance 2008)

One technique to avoid unnecessary loops, is to use JavaScript indexing. Native JavaScript objects can be used to store quick-lookup indexes to other objects, working in a similar way to how database indexes work (25 Techniques 2012). As seen in Figure 12 below it also speeds up finding objects by using e.g. the name as an index. This is highly optimized and avoids long search iterations.

Figure 12: Finding Objects by JavaScript indexing

Additionally it is always a good idea to use native JavaScript array functions such as push(), pop() and shift(), especially working with arrays. These functions also have a small overhead and are closely connected to their assembly language counterparts (25 Techniques 2012).

The difference between reference and primitive value types, also comes up in terms of efficient iterations. Primitive types such as String, Boolean or Integer are copied if they are handed over to a function. Reference types, such as Arrays, Objects or Dates are handed over as a light-weight reference. This knowledge should be considered if a reference is handed over to a function, running in an iteration: Obviously, it is better to avoiding frequent copying of primitive types and pass lightweight references to these functions.


A final option to consider for optimization is the usage of correct JavaScript syntax. Writing simple function patterns without being familiar to advanced native ECMAScript can lead to inefficient code. It is recommendable to try to stay up to date and learn how to apply these constructs.

One easy example (25 Techniques 2012) regarding this, is to prefer the usage of native, optimized constructs over self-written algorithms: Functions as e.g. Math.floor()or new Date().getTime() for timestamps don’t need to be rewritten. The operator === instead of == provides an optimized, faster type-based comparison (25 Techniques 2012). Furthermore, the switch statement can be used instead of long if-then-else blocks to provide an advantage during compilation, to name just a few examples.

3. Is WebAssembly replacing JavaScript?

On the 17th of June 2015, Brendan Eich (the creator of JavaScript) announced a new project that aims to make it easier to compile projects written in languages like C and C++ to run in browsers and other web related JavaScript environments (Why we need Web Assembly). The developing team consists of members from Apple, Google, Microsoft, Mozilla and others collective under the name of the W3C WebAssembly Community Group (Why we need Web Assembly). A blog article by Eric Elliot comments on these release announcements and states that „the future of the web platform looks brighter than ever“ (What is WebAssembly?).

But what exactly is WebAssembly? Elliot further explains that WebAssembly, often shortened as WASM, is a new language format. The code defines an AST (Abstract Syntax Tree) represented in a binary format that can be edited/developed as readable text. The instruction format has been built to compile languages such as C, C++, Java, Python and Rust and allows the deployment on the web and in server applications. Through WebAssembly it is now possible to run the respective code on the web at a native speed (WASM replace JS 2018). But WASM is also an improvement to JavaScript: The performance critical code that needs to be optimized can be implemented in WASM and imported like a standard JavaScript module (What is WebAssembly?). The blog entry by Elliot additionally explains that WASM is also an improvement for browsers. Through the fact, that browsers will be able to understand the binary code that can be compressed to smaller files than currently used Javascript files, smaller payloads would lead to faster delivery and make websites run faster (What is WebAssembly?).

But listing all these advantages, does WebAssembly have the potential to replace JavaScript in the nearest future? And is WebAssembly compilation really so much faster? A blog article from Winston Chen compares the performance of WebAssembly vs JavaScript and comes to a surprising result (WASM vs JS 2018). The performed experiment involved several implementations of matrix multiplications as a simple and computationally intensive way to compare JavaScript and C++ (in WASM). In summary it can be said that JavaScript performed better than WebAssembly on smaller array sizes and WebAssembly outperformed JavaScript on larger ones. Chen concludes, that outgoing from his results, JavaScript is still the best option for most web applications. According to him, Web Assembly was therefore “best used for computationally intense web applications, such as web games” (WASM vs JS 2018).

Among different articles throughout the internet, dealing with the question whether WASM is going to replace JavaScript, it is not possible to find a precise answer or prediction. But Brendan Eich, the creator of JavaScript himself, finds a relatively clear answer to the question if he was trying to KILL JavaScript (by developing WASM): “…We’re not killing JavaScript. I don’t think it’s even possible to kill JavaScript”(Why we need wasm 2015). The JavaScript ecosystem currently supports all major browser and most developers write libraries and frameworks in it (e.g. React, Bootstrap or Angular)(WASM replace JS 2018). In order to overtake JavaScript, any competitor (as WASM) would need to provide replacement options for all these libraries. Furthermore, it is not easily feasible to replace the existing code base of JavaScript based projects. With growing popularity in calculation intense projects as browser-based games, WebAssembly can possibly decrease the market share of JavaScript, but is not able to replace these already existing JS applications. It can be said, that the native speed improvements of WebAssembly are rather a complementation of the existing JavaScript features (WASM replace JS 2018). By using both, (e.g. by using WebAsembly run alongside JS using WASM JavaScript APIs) developers can benefit from the flexibility of JS and the native speed advantages of WASM in combination. Wrapping this up, the creator was right and is very unlikely that WASM is going to overtake JavaScript – still the single, dominating language of the web.

4. References

Speaking JavaScript 2014, Axel Rauschmeyer, Speaking JavaScript: An In-Depth Guide for Programmers
Chapter 4. How JavaScript Was Created
[Accessed 24 July 2019].

WebAssembly 2015, Eric Elliot, What is WebAssembly? [Online]
Available at:
[Accessed 28 July 2019]. 

Why we need wasm 2015, Eric Elliot, Why we Need WebAssembly [Online]
Available at:
[Accessed 28 July 2019]. 

WASM replace JS 2018, Vaibhav Shah, Will WebAssembly replace JavaScript? [Online]
Available at:
[Accessed 28 July 2019]. 

WASM vs JS 2018, Chen Winston, Performance Testing Web Assembly vs JavaScript [Online]
Available at:
[Accessed 27 July 2019]. 

25 Techniques 2012, Steven de Salas, 25 Techniques for Javascript Performance Optimization [Online]
Available at:
[Accessed 27 July 2019].

JS Optimization 2018, Addy Osmani, JavaScript Start-up Optimization [Online]
Available at:
[Accessed 27 July 2019].

JavaScript 2019, Chris David Mills (MDN web docs), What is JavaScript? [Online]
Available at:
[Accessed 27 July 2019].

Speeding up 2010, Yahoo Developer Network, Best Practices for Speeding Up Your Web Site [Online]
Available at:
[Accessed 27 July 2019].

String Performance 2008, Tom Trenka, String Performance: an Analysis [Online]
Available at:
[Accessed 27 July 2019].

Event Bubbling 2011 Alfa Jango, THE DIFFERENCE BETWEEN JQUERY’S .BIND(), .LIVE(), AND .DELEGATE() [Online]
Available at:
[Accessed 24 July 2019].