*4.2. Design of the Instance Generation Process*

For our numerical study, we need to be able to create many instances systematically. Therefore, we developed an instance generator that was implemented in Python 3.8. The procedure to generate instances can be divided into the three main steps of (i) creating a so-called initial graph, (ii) deriving from this initial graph a so-called instance graph, and (iii) adding further sets and parameters to arrive at a complete description of a planning instance.

In our case, the initial graph is created using the Python graph modeling package NetworkX and based on real airport apron structures. With the help of a satellite image, as presented in Figure 6 for a small part of Tokyo Airport Haneda, Japan, the graph nodes can be set according to the real airport's intersections, gates and parking positions. The weights of the edges correspond to the road segment's lengths of the real airport. An example of a complete initial graph is given in Figure 7; Hamburg Airport, Germany, inspires this one.

**Figure 6.** Comparison between excerpt of satellite image and excerpt of generated initial graph. Source: Tokyo Airport Haneda [online], 35◦33016.4100 N 139◦47017.4200 E, Height 6 m, Google Earth ©, URL: http://www.google.com/earth on 11 July 2022.

In the second step, we derived from the initial graph different instance graphs classes by deleting and adding nodes and edges to create instances that differ concerning the granularity of the modeled topology, resulting in instance classes denoted as "small", "medium" and "large". Graphs of the small instance class have only a small number of nodes and links. Thus, we must delete nodes and edges of the initial graph to adapt it to the small instance class. For the large instance class, we need to add nodes and edges to the initial graph. Within an instance class, the graphs derived from different initial graphs should have a comparable number of nodes and links. Since the initial graphs have different sizes, the number of links and nodes to be deleted or added differs for each initial graph. In the following, we will explain the mechanisms for deleting and adding nodes to create comparable instance graphs based on very different initial graphs.

Graph reduction is done by deleting gates, depots and parking positions and their associated intersections. For this purpose, the user specifies the portion of these positions to be deleted (deletion rate). The positions are then deleted at regular distances. Figure 8 shows an excerpt from the initial graph introduced in Figure 7 for different deletion rates. The figure at the top shows the result of a deletion rate of 0% (i.e., the initial graph), in the middle that of a deletion rate of 50%, and at the bottom the result of a deletion rate of 75%.

In addition to deleting nodes and edges, it is also possible and may be necessary to add them as explained in Section 4.1 and Figure 5 to achieve a finer granularity of the modeled topology and, hence, economically more efficient solutions.

In the third step, we generate the final instances for each instance graph. To this end, different parameters and sets are required, as indicated by the notation in Table 1. Table 2 summarizes how we derived the sets and parameters of the DICP. The set of links L and nodes V are directly taken from the instance graph. We consider all links to be candidates to host an ITU. Limiting the consideration to heavily trafficked sections of the road network would be possible. However, in this case, there is a risk that not all service requests can be served. This is particularly true if service requests do not use these route sections. For this reason, we consider all links as ITU candidates. We determine the PSU candidate positions P from the set of all depots and gate positions to achieve a predetermined number of candidate positions so that those positions are evenly spread over the set of depots and gate positions. We assume that each PSU can supply each link. For this reason, L*<sup>v</sup>* equals L for all PSU candidates. Conversely, this also means that every PSU can supply every link and, thus, P*<sup>l</sup>* equals P for all links. Again, this is a simplified assumption. In reality, it would be conceivable that PSUs could not supply ITUs at any distance. This could be realized in our model if we consider in the set L*<sup>v</sup>* only the ITUs within a certain distance from the PSU *v*.

**Figure 7.** Example of an initial graph (Hamburg Airport).

**Figure 8.** Reducing an initial graph with deletion rate 0% (**top**), 50% (**mid**) and 75% (**bottom**).

Modeling the service requests is a crucial aspect of setting up problem instances. In all instances, we use the two-way request structure described in Broihan et al. [8]. Thus, a request starts at a terminal position (gate or depot), takes the shortest path to an aircraft parking position and ends again at a terminal position. All combinations of starting points (terminal positions), aircraft parking positions and endpoints (terminal positions) form the complete set of possible requests. Consequently, even in medium-sized instances, we get a very large set of requests. For the case of the initial graph in Figure 7, we have 31 passenger gates plus one bus depot and 30 outside aircraft parking positions. As a result, we have (31 + 1) × 30 × (31 + 1) = 30,720 different two-way requests, leading to 30,720 constraints (2) in the DICP (1)–(6). For other (larger) airports the number of requests and corresponding model constraints may be substantially larger. However, these service requests often overlap, so it can be sufficient to consider only a part of them. Hence, we operate with different proportions of all possible requests. According to the given proportion, the requests for the set R to be considered in the model are randomly selected from all possible requests for the given instance graph. We assume that the vehicles take the shortest path for each request and, hence, used shortest path algorithms to determine the set L*<sup>r</sup>* of links over which a vehicle travels as it serves request *r*. In addition, a set Γ*lv* represents the predecessor of a link *l* on the shortest path to a PSU *p*. This set is determined using the Python package NetworkX in the preprocessing step to determine the shortest paths for all the requests.


**Table 2.** Instance derivation from given data.


We assume that the investment *c psu <sup>v</sup>* in a PSU at node *v* is equal for all *v* ∈ P and is provided by the user. The investment *c itu l* to equip link *l* with an ITU is derived by multiplying the investment in ITU per meter with the link length. Similarly, the energy intake *ei<sup>l</sup>* is determined by multiplying the energy intake per meter with the link length and the energy consumption *ec<sup>r</sup>* by multiplying the energy consumption per meter with the request length. The length of the request is determined by adding the lengths of all links contained in this request.
