*4.3. Description of the Generated Instances*

For the numerical study conducted in this paper, we created a test instance set based on three initial graphs. These graphs are based on sections of real airport aprons but underwent minor modifications. Each graph in Figure 9 represents a certain apron layout. We refer to them as structures A, B and C. General layout A (left part of Figure 9) is an aggregate representation inspired by the conditions found at Hamburg airport, for which the initial graph was already introduced in Figure 7. The other two structures B and C (center and right part of Figure 9) were inspired by topologies found at other international airports, again without actually being isomorphic representations. Note that in these aggregate visualizations of Figure 9, an entry such as "G1" denotes an entire set of terminal gates in close proximity. Likewise, an entry "P1" represents an entire group of aircraft parking positions.

**Figure 9.** Aggregate Layout Structures. (**a**) Structure A. (**b**) Structure B. (**c**) Structure C.

We derived the initial graphs from satellite images. We set the positions for parking positions, terminal positions and intersections according to these images. Additionally, we placed intersection nodes at positions relevant to the structure (e.g., curves).

As mentioned before, we defined three instance classes of different sizes. Graphs of the instance class "small" have 55 to 65 nodes, graphs of the instance class "medium" have 100 to 120 nodes, and graphs of the instance class "large" have 180 to 200 nodes. We used different vertex (node) deletion rates and resulting link lengths to generate these instance graphs from each initial graph for structures A, B and C. The link length always specifies a maximum length since the links of the initial graph cannot always be divided without a remainder. Suppose we consider an instance graph with a link length of 100. In this case, a 250 m link of the initial graph will be divided into two links with a length of 100 m and one with a length of 50 m.

The values of deletion rates and link length are shown in Table 3. Excluding the initial graphs, this led to three different graphs per instance class and, hence, a total of nine different instance graphs.


**Table 3.** Graph Adjustments.

In the numerical analysis, we analyzed the influence of selected sets and parameters on the computation time. Therefore, the following further attributes were varied when creating the instances:


By modifying the size of the set |P| of nodes potentially hosting a PSU and the size %|R| of the set of service requests to consider, we varied the size of the problem. Therefore, we expected the computation time to increase for larger values for both attributes. However, we wanted to examine how significant the increase is. For the investment and energy parameters, only their ratios are relevant. As already explained, a high *c psu*/*c itu* ratio means that PSUs are expensive relative to ITUs. Consequently, few PSUs are expected to be built. Instead, more ITUs are built to connect all ITUs to the few installed PSUs. Thus, some ITU segments are built not because of the energy requirements of the vehicles but to produce a permissible (connected) charging infrastructure. A low *c psu*/*c itu* ratio can, on the contrary, lead to significantly more PSUs and fewer ITUs. With an *ei*/*ec* ratio close to one, energy intake and consumption are almost identical. As a result, nearly the entire infrastructure must be equipped with an ITU. An energy ratio *ei*/*ec* significantly larger than 1 indicates that the energy intake is significantly greater than the energy consumption. In such a case, only relatively few ITUs will be built. The influence of the parameters on the resulting infrastructure seems to be very clear. However, the influence on the computation time is not obvious, which is why we considered them in our analysis.

We considered three different values for every attribute, as shown in Table 4. The values were chosen to cover a wide range so that the influence of the attributes should be visible. For example, for the energy ratio *ei*/*ec*, a very low value (1.2) was selected, a value that may correspond to reality (3.24) and a particularly high value (10). We considered all different attribute combinations for all graphs. We have four attributes with three different values and thus have 3 <sup>4</sup> = 81 instances for each graph of an instance class. Since we considered nine graphs, we obtained a total number of 729 instances. We solved these instances with Python 3.8 and Gurobi 9.1.0. Considering a strategic planning problem, we used a time limit for the computation of 48 h for each of the 81 × 9 = 729 problem instances of our numerical test bed. In other words, we allowed up to about four years (!) of total Central Processing Unit (CPU) time for the entire study. All computations ran on the Dumbo subcluster of Leibniz University Hannover compute facilities, which uses an Intel

Xeon E5-4650v2 @2.40 GHz processor. Clearly, without such a cluster, the computations would not have been possible.

**Table 4.** Attributes of generated instances.

