\chapter{Java Implementation}
Java programming language was developed by Sun Microsystems company in 1995. Nowadays, it is one of the most common programming languages due to many features it provides. The most remarkable advantage is with no doubt platform independence. Java is an interpreted language, applications are compiled into byte code and therefore it can run on any Java Virtual Machine. This enables us to develop our application also for portable devices and implement it for example in Android operating systems. Java is strictly object oriented. Compared to C/C++, the constructions are simpler and the garbage collector is also introduced which prevents many programming bugs. These are the main reasons we have chosen Java. Of course, there are more points to discuss. However, it is not the main purpose of this chapter.

In this chapter, you will find the description of Java implementation of the Moving Average and the Dynamic Programming algorithms as well as simulation results and analysis. 

\section{Code Structure}
\label{sec:CodeStructure}
Java is object oriented programming language, therefore the code structure plays an important role in code execution and facilitates code orientation and implementation to the developer. In figure~\ref{fig:EnManClassStructure} is shown the structure\footnote{Legend: Every box represents a class. A filled gray box represents the class for which the graph is generated. A dark blue arrow is used to visualize a public inheritance relation between two classes. A purple dashed arrow is used if a class is contained or used by another class. The arrow is labeled with the variable(s) through which the pointed class or struct is accessible.} of the main class providing the energy optimization.

\begin{figure}[ht]
    \center
    \includegraphics[scale=0.7]{images/java/energy_management__coll__graph__brief.png}
    \caption{Energy management class structure.}
    \label{fig:EnManClassStructure}
\end{figure}

As you can see, EnergyManagement class encapsulates other help classes to calculate the optimal Power-Split-Ratio between batteries and super-capacitors and to determine final States-of-Charge. First, we have to know the vehicle parameters (air density, windward area, Reynolds coefficient, mass etc.) which are encapsulated in the Vehicle class. This class does not provide any methods. Once we have these parameters, we will use it to compute vehicle's power demand profile via DrivingCycle class. DrivingCycle class encapsulates all the information about the cycle (velocity, altitude, road slope, power profile etc.) and provides methods to calculate vehicle power profile within the driving cycle from velocity and slope grades or the altitude profile of the driving cycle.

In order to proceed the optimization algorithm, we need to know the parameters and initial states of the vehicle's components which are batteries, super-capacitors and DC/DC converter. From the class structure in figure~\ref{fig:EnManClassStructure} is visible, that classes Batteries and SuperCapacitors inherit from HEVComponent class. This is due to the fact, that these two components have the same parameters structure like initial SoC, capacity, voltage etc. They differ only in the component's energy calculation as it is going to be explained later in section~\ref{sec:BattScEnCalc}. Because the efficiency of these components is a bivariate function of power and SoC, the Efficiency2DMap class is used to compute efficiencies. On the contrary, DC/DC converter's efficiency is a univariate function of power and that is why DcDcConverter class uses Efficiency1DMap only.

Obviously, the Batteries and SuperCapacitors classes encapsulate information about batteries and super-capacitors. Because the optimization algorithms are energy and state-of-charge based, these classes provide also conversion between these quantities for each component. Also, component's efficiency calculation methods are provided. In short, all the components processing should be able to do by intermediary of this classes. DC/DC converter does not keep his state values (SoC and energy). This is why only efficiency calculation is provided by the DcDcCoverter class.

\subsection{Interface}
To facilitate the work with the EnergyManagement class and to make it more universal, the class interface was developed. This interface provides basic methods for energy optimization such as profile settings, initial states settings and of course Power-Split-Ration and final SoC calculation. The detailed list and description can be found in IEV.java file.
% in appendix~\ref{lst:EnergyManagementInterface}.

The interface is defined in the IEV class. We have written two implementation classes EVMA and EVDP for Moving Average and Dynamic Programming algorithm respectively. As you can see from the inheritance graph~\ref{fig:InterfaceInheritation}, these classes inherit from abstract class EV which implements common methods for both cases (i.e. initial states or profile settings). Therefore, EVMA and EVDP implement only the specific optimization method. 

\begin{figure}[ht]
    \center
    \includegraphics[scale=0.7]{images/java/interfacehev__inherit__graph.png}
    \caption{Interface implementation inheritance graph.}
    \label{fig:InterfaceInheritation}
\end{figure}

From figure~\ref{fig:EVMAEVDPInheritance} is visible, that both EVMA and EVDP classes implements IEV interface while inheriting from EV implementation and using common EnergyManagement class which provides both algorithms.

\begin{figure}[ht]
	\begin{center}$
		\begin{array}{cc}
			\includegraphics[scale=0.7]{images/java/evma__coll__graph.png} &
			\includegraphics[scale=0.7]{images/java/evdp__coll__graph.png}
		\end{array}$
	\end{center}
	\caption{EVMA (Moving Average) and EVDP (Dynamic Programming) class inheritance graph.}
	\label{fig:EVMAEVDPInheritance}
\end{figure}

%\subsection{Exceptions}
%To complete...

\section{XML Input Data Format}
As we have described in section~\ref{sec:CodeStructure}, the EnergyManagement class needs input parameters for calculation. It is desired to have the possibility to change these parameters without having to recompile all the application. That is why we proposed to parse input parameters from XML configuration file. 

\lstset{language=XML, caption=Structure of XML configuration file, label=lst:XMLConfig, basicstyle={\lstbasicfont\scriptsize}}
	\lstinputlisting{code/config.xml}
	
The EnergyManagement class uses DOM (Document Object Model) parsing method. This method is more resource intensive, because all the XML structure is in memory, however we suppose that the configuration file is not very large in our case.
	
In source code~\ref{lst:XMLConfig} is shown the structure of XML configuration file which must be respected in order to guarantee correct input parameters parsing. The file must contain the root element \textit{<parameters>} which encapsulates all input parameters. Although the order of elements within the root element is not important, let's start with the \textit{<vehicle>} element.

The \textit{<vehicle>} element contains vehicle parameters in form of pair tag elements with appropriate names. These elements are \textit{<air-density>} (air density in $kg.m^{-3}$), \textit{<windward-area>} (windward area in $m^2$), \textit{<reynolds-coef>} (Reynolds coefficient in $kg.m^3$), \textit{<rolling-resistance-coef>} (rolling resistance coefficient), \textit{<mass>} (mass in $kg$) and \textit{<equiv-moment-inertia>} (equivalent moment inertia in $kg.m^2$).

Next element within the \textit{<parameters>} is the \textit{<components>} element which shall contain \textit{<batteries>}, \textit{<super-capacitors>} and \textit{<converter>} elements in any order.

The \textit{<batteries>} element shall contain following elements: \textit{<number>} (number of batteries), \textit{<soc-min>} (initial State-of-Charge in $\%$), \textit{<soc-max>} (maximal State-of-Charge in $\%$), \textit{<capacity> (single battery capacity in $A.h$)}, \textit{<voltage> (single battery voltage in $V$)}, \textit{<power-max-neg> (maximal negative single battery in $W$)}, \textit{<power-max-pos>}  (maximal positive single battery in $W$) and \textit{<efficiency-2D-map>} (2D efficiency map - see bellow for details).

The next element \textit{<super-capacitors>} has exactly the same structure as \textit{<batteries>}. The difference is that the \textit{<capacity>} element determines single SC capacity in $Farads$. 

Last element between the \textit{<components>} elements is \textit{<converter>}. It shall contain \textit{<power-max-neg> (maximal negative single battery in $W$)}, \textit{<power-max-pos>}  (maximal positive single battery in $W$) and \textit{<efficiency-1D-map>} (1D efficiency map - see bellow for details).

The fundamental parameters are efficiency values. In the case of \textit{<converter>}, the efficiency is univariate function and the values are in \textit{<efficiency-1D-map>} element. This element shall contain \textit{<map-power>} (comma separated power values in $W$ in ascending order) and \textit{<map-efficiency>} (comma separated corresponding efficiency values in interval 0-1) elements. The number of values within these two elements must be equal. Finally, in the case of \textit{<batteries>} and \textit{<super-capacitors>}, the efficiency is bivariate function and must be specified by \textit{<efficiency-2D-map>} element. It's required elements are \textit{<map-power>} (comma separated power values in $W$ in ascending order), \textit{<map-soc>} (comma separated State-of-Charge values in $\%$ in ascending order) and \textit{<map-efficiency>}. The last element shall contain \textit{<map-efficiency-line>} elements. The number of \textit{<map-efficiency-line>} elements is determined by number of values specified in \textit{<map-soc>}. Each \textit{<map-efficiency-line>} element corresponds to one value of \textit{<map-soc>}. Furthermore, \textit{<map-efficiency-line>} contains comma separated efficiency values in interval 0-1 corresponding to \textit{<map-power>} values. For instance, according to the configuration file example~\ref{lst:XMLConfig}, we can say, that for battery $SoC=20~\%$ and power demand $P=180~W$, the efficiency is 0.77.


\section{Code Example}
In the source code~\ref{lst:CodeExample} is shown how to deal with energy optimization java interface. The sample chooses the algorithm according to the \textit{dynProg} boolean value, initializes batteries and super-capacitors and sets the driving profile. After that the optimization algorithm is performed and also the Power-Split-Ratio is obtained.

\lstset{language=Java, caption=Energy optimization interface code example., label=lst:CodeExample}
	\lstinputlisting{code/example.java}


\section{Execution Time Optimization}
After performing Dynamic Programming algorithm simulations in Matlab, we discovered, that the approach described in section~\ref{sec:SoC} is very time consuming because the algorithm must calculate a lot of unnecessary operations. Firstly, the algorithm generates one grid for whole horizon. For large horizons, it means that it searches for the optimal trajectory also in unreachable SoCs in the actual step. Furthermore, the algorithm evaluates all the transitions even if they are forbidden.

The first optimization step in Java implementation was the grid generation modification. Now, the grid is not generated for the whole horizon, but for every step within the horizon, we generate a new vector of possible SoCs. Firstly, we determine the optimal final battery SoC value as

\begin{equation}
SoC_{Bf} = SoC_{BInit} - E_{Horiz}/E_{BFull}\cdot100
\end{equation}

where $SoC_{BInit}$ is initial battery SoC at the beginning of the horizon, $E_{Horiz}$ is the energy of the horizon and $E_{BFull}$ is the energy of fully charged battery.

From this value, we are iterating backwards. To cover all the possible SoCs in the previous step, we must generate a vector in interval from $SoC_{Bf}$ to $SoC_{Bf}+\Delta SoC_{max}$. $\Delta SoC_{max}$ corresponds to the maximal power that can be delivered by battery. In the next steps, we proceed analogically. 

Once we have generated the grid by this method, it does not still guarantee that all the transitions between SoCs in two consecutive steps will be permitted. The transitions must respect these two conditions: 
\begin{itemize}
	\item SoC in the actual step must be greater or equal to the SoC in the next (future step). This corresponds to the fact, that the battery cannot be recharged. That is why, the SoC is the semi-negative function.
	\item The difference $\Delta SoC$ between SoC in the actual step and the future step cannot be greater than $\Delta SoC_{max}$. This corresponds to the fact, that the battery has some limitations and the maximal power it can provide can be transformed in time to maximal delivered energy which corresponds to  $\Delta SoC_{max}$.
\end{itemize}

If these conditions are not respected, the transitions are automatically ignored, which speeds up significantly the calculation process. The schematic example of grid generation and permitted transitions is shown in figure~\ref{fig:PosTransSoCGrid}.

\begin{figure}[ht]
    \center
    \includegraphics[width=12cm]{images/java/SoC_Grid.png}
    \caption{Possible transitions in the SoC grid.}
    \label{fig:PosTransSoCGrid}
\end{figure}


\section{Modeling Implementation}
\subsection{Power Profile Calculation}
For determining the power profile, we use the formulas described in section~\ref{subsec:long_model}. We suppose, that the velocity and altitude profile values are already the functions of position, so there is no need to do the ``time-to-position'' transformation. This supposition is based on the fact, that we predicted and read these values from a static map and not from sensors in a real situation. Therefore, equation~\ref{eq:Pd} is used to calculate the power demand.

For the velocity derivation, we use the discrete approximation written as:

\begin{equation}
\frac{dv}{ds} = \frac{v(s+h)-v(s)}{h}
\end{equation}

where $v(s+h)$ is the velocity in the next step, $v(i)$ is the velocity in the current step and $h$ is the interval between these two values.

\subsection{Conversion between Power and Energy}
\label{subsec:P2En}
The input parameter of the optimization algorithm is the power profile. However the algorithm calculates with energy based SoCs. That is why we need to perform conversion between power and energy. Energy is defined as:

\begin{equation}
E = \int P(t)\cdot dt
\end{equation}

Nevertheless, power profile is a function of position and not of time. We define the energy in discrete form as:

\begin{equation}
E = \sum P(s)\cdot \delta_{s2t}(s)
\end{equation}

where 

\begin{equation}
\delta_{s2t}(s) = \frac{h}{v(s)}
\label{eq:deltas2t}
\end{equation}

or an approximation can be used in form

\begin{equation}
\bar{\delta}_{s2t} = \frac{h}{\bar{v}}
\end{equation}

where $h$ is the discretization interval and $\bar{v}$ is the average velocity value.

During the driving cycle, the velocity can be zero, which is for calculation of the conversion coefficient impossible. In these cases, we make an approximation by replacing the zero velocity by average velocity.

\subsection{Battery and SC Energy Calculation}
\label{sec:BattScEnCalc}
At the beginning of the energy optimization, we must determine the energies of fully charged batteries and super-capacitors. In the case of batteries, the energy of the whole battery pack is defined as:

\begin{equation}
E = (C \cdot U \cdot 3600) \cdot n
\end{equation}

where $C$ is single battery capacity in $A.h$, $U$ is single battery voltage in $V$ and $n$ is the number of batteries in the pack.

In the case of SCs, the energy of the whole SC pack is defined as:

\begin{equation}
E = (\frac{1}{2}C \cdot U^2) \cdot n
\end{equation}

where $C$ is single SC capacity in $F$, $U$ is single SC voltage in $V$ and $n$ is the number of SCs in the pack.


\subsection{State-of-Charge Discretization Interval Determination}
After introducing the power to energy conversion described in section~\ref{subsec:P2En} and while using the conversion coefficient defined by equation~\ref{eq:deltas2t}, a constant SoC discretization interval does not necessarily correspond to constant power after a conversion from energy within one step. This is due to the fact, that the conversion coefficient is in this case a function of velocity which may not be constant.

To reduce battery power demand variations, we introduced another way to determine the SoC discretization interval. We proceed from the other side. It means, we choose a constant power discretization interval, this interval is converted to energy and finally to SoC. This method calculates in every step different SoC discretization interval as function of conversion coefficient, which corresponds to constant predefined power value.

Although this method significantly reduces battery power demand variations, it does not enable us to determine only a limited number of power levels dividable by power discretization interval. The reason is that the future already calculated SoCs in the grid are determined for another conversion coefficient and they are not necessarily on the same levels. This is why the transitions' SoC variations won't be constant.


\subsection{Interpolation}
For the optimization purposes, we need to calculate the efficiencies. The algorithms use static efficiency maps which means, that in the case we need to determine the exact efficiency value, we must interpolate within the efficiency grid.

In our Java implementation, we have used third party open source mathematical library provided by Apache Software Foundation. This library is available on-line at: http://commons.apache.org/math/ .

The class Efficiency2DMap uses BivariateRealFunction class to store efficiency function. Interpolation of this bivariate function provides SmoothingBicubicSplineInterpolator class which generates a bicubic interpolation function. Prior to generating the interpolating function, the input is smoothed using polynomial fitting. The Apache mathematical library does not provide bilinear interpolation. However the SmoothingBicubicSplineInterpolator can replace it in the case of linear function because of using the smoothing method.

The class Efficiency1DMap uses UnivariateRealFunction class to store efficiency function. Interpolation of this univariate function provides UnivariateRealInterpolator class.



\section{Simulations and Analysis}
Even thought the algorithm principles are the same, the exact implementation changed after rewriting to Java language. In order to check previous Matlab simulations results, we have performed the same type of simulations with Java algorithms. The reference vehicle is as in the previous simulations a bus with parameters shown in table~\ref{tab:vehicle_params}.

\begin{figure}[ht]
    \center
    \includegraphics[width=12cm]{images/java/sim_vel_slope_pow.png}
    \caption{Velocity, road slope and power profile of the driving cycle.}
    \label{fig:sim_vel_slope_pow}
\end{figure}

In figure~\ref{fig:sim_vel_slope_pow} are shown the velocity, road slope and calculated power profile of the driving cycle. We have simulated more situations. In the first case, the power to energy conversion coefficient was calculated from instant velocity (table~\ref{tab:java_algs_compar_1}). After the approximation was made by calculating the coefficient from average velocity (table~\ref{tab:java_algs_compar_2}). For details about power to energy conversion, see section~\ref{subsec:P2En}.

The best contribution of Java implementation is certainly significant execution time improvement of Dynamic Programming algorithm. Previous simulations of this algorithm in Matlab shows, that for a driving cycle of the same length (270 points, 5400 m), for the same look-ahead interval (whole cycle) and for grid discretization 30~kW, the execution times are approximately 330 seconds (5.5 minutes). However, execution times of optimized DP Java algorithm under same conditions are around 78 milliseconds, which is more than 4000 times less. Also if we triple the discretization to 10~kW, the execution times are still around 156 milliseconds. Therefore, the algorithm is fairly usable in real applications, because the computational burden is not very high (see Computational Burden subsection in section~\ref{subsec:comp_burd}).

Comparing the simulations figures bellow, it is visible, that the battery power demand is more stable when using the approximation of power to energy conversion coefficient. Obtained results are nearly the same as for the case without approximation. However, we must keep on mind, that this is only artificial simulation and driving profile estimation. That is why, it is necessary to test these algorithms in real situations or under more sophisticated simulations conditions, where the driving profile can change dynamically during the journey. In this situations can happen, that the approximation will be too erroneous. Nevertheless among others, from figures~\ref{fig:sim_DP_instDelta} and \ref{fig:sim_DP_constDelta_10kW} is visible, that if the grid is discretized more precisely, we can decrease the battery power demand variations.

From tables~\ref{tab:java_algs_compar_1} and \ref{tab:java_algs_compar_2}, we can see, that still the algorithm with best results is Dynamic Programming algorithm. However the execution times are slightly higher than in the case of Moving Average algorithm. For that reason, we could i.e. use DP with coarse sampling or MA algorithm in the situations the quick decisions has to be made and than use DP with finer sampling to precise the results.


\begin{table}[!ht]
\centering
\small
\begin{minipage}[c]{\textwidth}
\centering
\begin{tabular}{|l|c|c|c|c|c|c|c|c|}
	\hline
	$\Delta s$ [m] & \multicolumn{8}{l|}{20} \\
	\hline
	n (=L/$\Delta s$) & \multicolumn{8}{l|}{270} \\
	\hline
	Route distance L [m] & \multicolumn{8}{l|}{5400} \\
	\hline
	Look-ahead horizon & \multicolumn{8}{l|}{270} \\
	\hline
	Initial/final SC SoC [\%] & \multicolumn{8}{l|}{100/$\approx$100} \\
	\hline
	Algorithm & \multicolumn{2}{c|}{DP 30~kW} & \multicolumn{2}{c|}{DP 10~kW} & \multicolumn{2}{c|}{MA} & \multicolumn{2}{c|}{Battery only} \\
	\hline
	Initial battery SoC [\%] & 100 & 30 & 100 & 30 & 100 & 30 & 100 & 30 \\
	\hline
	Final battery SoC [\%] & 93.9 & 22.8 & 94.0 & 23.0 & 93.4 & 22.2 & 92.9 & 21.3 \\
	\hline
	$SoC_B$ difference [\%] & 6.1 & 7.2 & 6.0 & 7.0 & 6.6 & 7.8 & 7.1 & 8.7 \\
	\hline
	Average C-rate $[h^{-1}]$ & 0.43 & 0.42 & 0.43 & 0.42 & 0.46 & 0.46 & 0.54 & 0.68 \\
	\hline
	\cratemax{Maximal C-rate $[h^{-1}]$} & \cratemax{0.97} & \cratemax{0.97} & \cratemax{0.80} & \cratemax{0.75} & \cratemax{1.21} & \cratemax{1.21} & \cratemax{2.57} & \cratemax{3.8} \\
	\hline
	\cratestd{C-rate std. dev. $[h^{-1}]$} & \cratestd{0.24} & \cratestd{0.24} & \cratestd{0.21} & \cratestd{0.20} & \cratestd{0.25} & \cratestd{0.25} & \cratestd{0.48} & \cratestd{0.65} \\
	\hline
	\improvement{Improvement\footnote[1]{Compared to the battery only power source} [\%]} & \improvement{14.3} & \improvement{17.4} & \improvement{15.1} & \improvement{19.1} & \improvement{7.5} & \improvement{10.5} & \improvement{---} & \improvement{---} \\
	\hline
	Maximal comp. time [ms] & 78 & 78 & 156 & 156 & 15 & 15 & --- & --- \\
	\hline
\end{tabular}
\end{minipage}
\caption{\label{tab:java_algs_compar_1} Algorithms comparison (power to energy coefficient calculated from instant velocity).}
\end{table}

\begin{table}[!ht]
\centering
\small
\begin{minipage}[c]{\textwidth}
\centering
\begin{tabular}{|l|c|c|c|c|c|c|c|c|}
	\hline
	$\Delta s$ [m] & \multicolumn{8}{l|}{20} \\
	\hline
	n (=L/$\Delta s$) & \multicolumn{8}{l|}{270} \\
	\hline
	Route distance L [m] & \multicolumn{8}{l|}{5400} \\
	\hline
	Look-ahead horizon & \multicolumn{8}{l|}{270} \\
	\hline
	Initial/final SC SoC [\%] & \multicolumn{8}{l|}{100/$\approx$100} \\
	\hline
	Algorithm & \multicolumn{2}{c|}{DP 30~kW} & \multicolumn{2}{c|}{DP 10~kW} & \multicolumn{2}{c|}{MA} & \multicolumn{2}{c|}{Battery only} \\
	\hline
	Initial battery SoC [\%] & 100 & 30 & 100 & 30 & 100 & 30 & 100 & 30 \\
	\hline
	Final battery SoC [\%] & 93.9 & 22.7 & 94.0 & 23.0 & 93.6 & 22.5 & 92.9 & 21.3 \\
	\hline
	$SoC_B$ difference [\%] & 6.1 & 7.3 & 6.0 & 7.0 & 6.4 & 7.5 & 7.1 & 8.7 \\
	\hline
	Average C-rate $[h^{-1}]$ & 0.41 & 0.41 & 0.41 & 0.41 & 0.43 & 0.43 & 0.54 & 0.68 \\
	\hline
	\cratemax{Maximal C-rate $[h^{-1}]$} & \cratemax{1.16} & \cratemax{1.16} & \cratemax{0.77} & \cratemax{0.77} & \cratemax{1.21} & \cratemax{1.21} & \cratemax{2.57} & \cratemax{3.8} \\
	\hline
	\cratestd{C-rate std. dev. $[h^{-1}]$} & \cratestd{0.29} & \cratestd{0.29} & \cratestd{0.20} & \cratestd{0.20} & \cratestd{0.22} & \cratestd{0.22} & \cratestd{0.48} & \cratestd{0.65} \\
	\hline
	\improvement{Improvement\footnote[1]{Compared to the battery only power source} [\%]} & \improvement{14.1} & \improvement{16.2} & \improvement{15.9} & \improvement{19.5} & \improvement{9.8} & \improvement{13.1} & \improvement{---} & \improvement{---} \\
	\hline
	Maximal comp. time [ms] & 78 & 78 & 156 & 156 & 15 & 15 & --- & --- \\
	\hline
\end{tabular}
\end{minipage}
\caption{\label{tab:java_algs_compar_2} Algorithms comparison (power to energy coefficient calculated from average velocity).}
\end{table}


\begin{figure}[ht]
    \center
    \includegraphics[width=12cm]{images/java/sim_MA_constDelta.png}
    \caption{Moving Average algorithm SoCs and power demands (power to energy conversion coefficient is calculated 								from average velocity).}
    \label{fig:sim_MA_constDelta}
\end{figure}

\begin{figure}[ht]
    \center
    \includegraphics[width=12cm]{images/java/sim_MA_instDelta.png}
    \caption{Moving Average algorithm SoCs and power demands (power to energy conversion coefficient is calculated 								from instant velocity).}
    \label{fig:sim_MA_constDelta_2}
\end{figure}

\begin{figure}[ht]
    \center
    \includegraphics[width=12cm]{images/java/sim_DP_constDelta.png}
    \caption{Dynamic Programming algorithm SoCs and power demands (power to energy conversion coefficient is calculated 								from average velocity). Grid discretization is 30~kW.}
    \label{fig:sim_DP_constDelta}
\end{figure}

\begin{figure}[ht]
    \center
    \includegraphics[width=12cm]{images/java/sim_DP_instDelta.png}
    \caption{Dynamic Programming algorithm SoCs and power demands (power to energy conversion coefficient is  										calculated from instant velocity). Grid discretization is 30~kW.}
    \label{fig:sim_DP_instDelta}
\end{figure}

\begin{figure}[ht]
    \center
    \includegraphics[width=12cm]{images/java/sim_DP_constDelta_10kW.png}
    \caption{Dynamic Programming algorithm SoCs and power demands (power to energy conversion coefficient is calculated 								from average velocity). Grid discretization is 10~kW.}
    \label{fig:sim_DP_constDelta_10kW}
\end{figure}

\begin{figure}[ht]
    \center
    \includegraphics[width=12cm]{images/java/sim_DP_instDelta_10kW.png}
    \caption{Dynamic Programming algorithm SoCs and power demands (power to energy conversion coefficient is  										calculated from instant velocity). Grid discretization is 10~kW.}
    \label{fig:sim_DP_instDelta_10kW}
\end{figure}