*5.3. Influence of Problem Properties on the Computation Time*

The influence of the different instance attributes from Table 4 on the computation time is shown in Table 8. The computation times are divided according to structure and the attributes and averaged over 27 values. In the first cell, for example, the times are averaged over all instances that belong to the small instance class of structure A and have only one PSU candidate. They differ in the number of service requests, the energy ratio and the ratio of investments (3 × 3 × 3 = 27). In addition, the computation times of the medium-sized instances are presented graphically in Figures 12–15.


**Table 8.** Average computation times for different attributes.

In Figure 12, we see that the number of PSU candidates strongly influences the computation time. The problem is easy to solve when only one PSU candidate is considered. In this case, no decision has to be made about where to place PSUs, but only where to place ITUs. This makes the problem much easier. Increasing the number of PSU candidates increases the computation time significantly.

**Figure 12.** Influence of the number of PSU candidates on the computation time for medium sized instances of structures A, B, and C.

In Figure 13, we observe that increasing the number of service requests also leads to increased computation time. However, increasing the number of service requests leads to a much lower increase in the computation time than increasing the number of PSU candidates. On average, the increase from 30% to 70% is greater than the increase from 70% to 100%. The reason is the overlap of the requests. If all requests are included, an extremely high number of service requests is considered. Many of these requests have a high percentage of overlap. It is therefore conceivable that there are service requests that are already covered by the infrastructure requirements of other service requests. This means, for example, that if two service requests are fulfilled, a third request is automatically fulfilled as well. From the perspective of the problem, it makes no difference whether this third service request is considered or not. This effect will especially occur with a very large number of service requests. Thus, if we consider 70% of the requests, nearly all original requests are covered, and the difference between 100% is small. However, considering 30% of the requests will not cover all requests. Thus, the computation time increases substantially from 30% to 70% as more requests with no/few overlapping are added to the instance.

**Figure 13.** Influence of the percentage of considered requests on the computation time for large sized instances of structures A, B, and C.

Figure 14 shows the influence of the energy ratio on the computation time. For structure A of the medium instance, a ratio of 1.2 has the highest computation time, and for cases B and C, a ratio of 3.24. Table 8 also shows that the ratio of 3.24 mostly leads to the highest computation time. The combinatorics of the problem can explain this. An *ei*/*ec* ratio of 1.2 means that the energy intake is slightly larger than the energy consumption. Thus, almost the entire infrastructure has to be equipped with ITUs. There are few possibilities to realize this. The extreme case *ei* = *ec* illustrates this: In order to supply sufficient energy to the vehicles, the complete infrastructure must be equipped with ITUs. The only decision to be made is which PSU is to be connected. Therefore, there are only |*P*| different feasible solutions. If *ei*/*ec* is very large, then the energy intake is significantly greater than the energy consumption per distance unit of ITU passed by the vehicle. In this case, only a very small part of the infrastructure has to be equipped. For this reason, a very large part of the solutions can be excluded since they are too expensive. In the case of a medium-sized energy ratio, such as 3.24, many solutions are feasible and not too expansive, and many solutions can potentially be considered. For this reason, the computation time is usually the largest for this value.

**Figure 14.** Influence of the energy ratio on the computation time for large sized instances of structures A, B, and C.

Figure 15 shows that increasing the *c psu*/*c itu* ratio leads to lower computation times. This means a high investment in PSUs compared to ITUs lead to low computation times. As already shown, lower computing times occur if fewer PSUs are considered. If the PSUs are very expensive compared to the ITUs, it is not economical to build many of them. Rather, more ITUs would be built instead of one additional PSU. The question of how many PSUs should be built is not as difficult if the PSUs are very expensive. However, if the PSUs are less expensive, it may be useful to build multiple PSUs. In this case, there is the question of where to place the PSUs and whether it is better to build additional ITUs instead of one additional PSU. These aspects increase the combinatorial difficulty of the problem and thus the computing times.

In a final study, we re-ran the instances with the features that led to the highest computation times, but now with a CPU time limit of 200 h (as opposed to the initial 48 h). Table 9 shows the results. Optimality could not be proven for any of the three instances, even after 200 h of computation. On the other hand, the remaining integrality gaps between 3.7% and 8.4% indicate that even for those hard instances, the Gurobi solver was able to find solutions that may be acceptable from a practical point of view as their worst-case deviation from optimality is not too large.

**Figure 15.** Influence of the investment ratio on the computation time for medium sized instances of structures A, B, and C.


Finally, there is the question of what these computational results mean for real problem instances. In real problem instances, there will probably be many possible PSU locations because it is conceivable that there is a connection to the grid at every gate position. Modeling all of them would most likely make the problem intractable. However, several PSU locations close to each other could easily be represented by one PSU candidate. The justification for this approach is that we observed a very large number of equally optimal solutions, so it is non-unjustified to hope that we can drop many PSU candidate positions without losing all the optimal solutions from the solution space.

We further assume that there will be a large volume of traffic on the apron in the future. This is why we are looking at a large number of service requests. Instead of operating with a two-trip structure as in our instance generation process, we could also create instances with single-trip structures. This would reduce the number of requests to consider, making the problem numerically more tractable. On the other hand, it would lead to more infrastructure solutions that would be more expensive but more robust by giving the vehicles more charging opportunities.

As mentioned in Section 4, the energy ratio of 3.24 is based on actual data from Broihan et al. [8]. They assumed a power of 100 kW and efficiency of 80% for the wireless power transfer. Since this is still a new technology and the application is very specific, real data for the investments are difficult to find. Most applications consider a single bus. Jeong et al. [28] mentioned 500 \$/m as investment in a meter of an ITU and 50,000 \$/unit for a PSU. However, the PSU needed for this application cannot be compared to the application at the airport, where many vehicles are powered simultaneously. Nevertheless, we can summarize that real-world problems mostly have the characteristics that make the problem particularly difficult. In addition, we have made simplifications even in the graphs of the large instance class since we do not consider all gates, depots and parking positions. Furthermore, we have chosen a still very large link length. It is conceivable that there are savings with smaller link lengths. With instances of real problem size, we can therefore assume even significantly higher computation times.
