The results presented in Case study I show that the SPO method improves the efficiency of an electric bus by reducing the energy consumption of the vehicle by around 11.5% and 8.5% for bus routes with slope variation within ±1% (Group I) and ± 3% (Group II), respectively, in a single round trip. Moreover, as was shown in Case study II, with the SPO method, the electric bus is able to carry out around four more round trips, compared to the baseline method introduced above, before the vehicle’s battery needs recharging (when the state-of-charge drops below a certain threshold).
The reported energy savings in Sect. 6.1 (Case study I) are within the range commonly found in the literature. However, our results are not directly comparable to those values since our baseline case is different, and more stringent: Here, the results are compared to a (quite energy-efficient) baseline case, involving autonomous operation with PID control. In other works, e.g. Dib et al.  the comparison is made with a (largely unspecified) human driving cycle, which in all likelihood would not be as energy-efficient as our baseline case, with its PID control, see e.g. Mersky and Samaras  and Pourabdollah et al. . Furthermore, as was shown in Torabi and Wahde , for vehicles with combustion engines, the SPO method outperforms DP-based methods when both method types are applied to the same situation with identical baseline cases.
Unlike DP-based methods (and MPC methods in particular), the SPO method does not require online iterative calculations. Once a speed profile has been generated for a given road profile, it can be used without any further modifications (assuming that the vehicle is able to follow the profile; see the next paragraph). Moreover, the SPO based method can be used in cases where longer optimization horizons must be considered (10 km for example) with larger speed range for the vehicle (highway driving, for instance), situations that would require heavy computations, and long running times, if DP-based methods were to be used.
Here it has been assumed that the vehicle is able to follow the speed profile without any interference from the surrounding traffic. This is a valid assumption for an increasing number of urban bus routes for which dedicated lanes are being built in city centers. Another assumption made here is that the motion of the vehicle is not interrupted by any traffic lights. However, the results can be generalized to routes involving traffic lights: For a given bus route, with known traffic light positions, a set of speed profiles can be generated to handle the binary case of traffic lights being either green or red. With n traffic lights between two stops, one could thus optimize 2n speed profiles (noting again that the optimization can be done a priori, before driving), covering all possible traffic light states, and then let the vehicle switch dynamically between profiles during driving, depending on the encountered situations. Even though the number of speed profiles grows rapidly with n, it should be no problem to handle realistic values of n, especially for the short bus routes considered here. A more difficult problem, which has not been explicitly modeled here, is the case in which the bus has to slow down or even stop due to unpredictable events (e.g. pedestrians crossing the road). In such cases, which can perhaps largely be avoided by careful city planning, one could simply revert to following the speed profile once the obstacle is gone, thus again accelerating to reach the cruising speed. Any such event would negatively impact the energy savings (regardless of the method used) but would be necessary since safety is a more important consideration.
Moreover, in Case study II, it was assumed that the vehicle’s mass is known, including the weight of the passengers, which can increase the total weight by up to 40–50% for a bus. This can for example be achieved by combining statistical data on the typical passenger weight with onboard sensors measuring the number of passengers entering or exiting (or even a camera-based system). A bank of speed profiles can then be generated for a set of different total masses, and the vehicle can then switch between profiles (much as in the traffic-light case considered above), depending on its current estimated mass. Alternatively, the speed profile (for a given mass) could be generated remotely, on demand, and then uploaded to the bus before it leaves the stop. Generating a speed profile for a 500 m stretch between two stops typically takes a few minutes on a standard desktop computer, a time interval that could be reduced to seconds using a faster, cloud-based computer resource noting also that the genetic algorithm is almost completely parallelizable.
As for the length of the acceleration (and deceleration) phases (i.e. the first and last spline; see Sect. 4.3) in a speed profile, several different values were tested before settling on a value of 50 m, which provided the best (i.e. most challenging) results for the baseline case against which our results are compared. With smaller values, the acceleration would be too high, thus resulting in excessive energy usage, and with larger values the cruising phase would be very short, again leading to increased energy usage (as well as a risk that the top speed would have to exceed the allowed maximum speed).
The average speed was chosen to be either 10 or 15 km/h in order for the autonomous bus to comply with the regulations imposed in this project. However, even without those regulations, at least the higher of those speeds is a realistic average speed for a bus operating in an urban environment . Nevertheless, the average speed can be set to higher values as well, in order to follow a specific timetable. With a different average speed setting, one would then have to rerun the simulations to calculate the energy savings.
A possible extension of this work would be to adapt the fitness measure (in the optimization) so that it increases the emphasis on regenerative braking, thus resulting in larger energy savings, but possibly at the expense of slightly larger acceleration and deceleration. Another topic for future work would be to migrate the optimization procedure to a cloud-based server, as well as running tests in real minibuses using the infrastructure and vehicles available in the Sohjoa Baltic project.