## 3 Simulation-Based System Architecture
### Intemodal Simulator  
The Intemodal Simulator evaluates the use case based on simulation. This component has been developed based on the MaaS Simulator, an exclusive ride-pooling service simulator implemented by PTV Group and available for internal developments, which has been adapted to the characteristics of the intermodal scenario researched here.  
This simulator performs an event-scheduling and agent-based simulation with two types of agents: vehicles and customers. The vehicle agent represents a vehicle moving between pick-up and drop-off (PUDO) locations, whereas the customer agent represents a customer booking and performing a trip. In the original implementation of the MaaS Simulator, customers could only experience Pure-RP trips in an immediate dispatch approach (requests were answered immediately with a Pure-RP journey or rejected if no feasibility was found). Thus, it has been extended to the new intermodal scenario so that it could simulate these combined trips that consist of a set of different legs of RP and PT modes. A representation of the resulting customer's agent states is illustrated in Figure 3 with the areas in black (original) and pink (intermodal extension with the integration of public transport). The blue and green extensions are discussed in the later sections of this document.  
Figure 3: States in the customer agent’s model and related functionalities.  
Batch Dispatching Scheduler  
Instead of processing the requests individually, one at a time, as soon as they come, gathering them in small groups (batch) has been shown to be computationally more efficient while giving the opportunity to obtain better quality solutions for the system. On the other hand, the system's response is delayed by the time required to form a batch. Taking this into account, the batch dispatching approach adopted can be considered a hybrid, since it limits the batch size up to a maximum number of requests or closes the batch after a given time period (i.e., 30 s) is elapsed. The requests in the so-formed batch are passed to the Outer Dispatcher for processing them using a dispatching algorithm (described next in Section 4). In case the dispatching algorithm provides a journey to the request, the simulation of it will proceed. Otherwise, if no feasible journey is found, the request can either be discarded or it can wait until the next batch request is received (details on the actions after a failed dispatch are described in Section 3.4.4). This batch dispatching approach appears reflected in the customer agent states, as shown in blue in Figure 3.  
For the configuration of the batch dispatching strategy, a period of 30 s is assumed, which is frequently used in cases of exclusive ride-sharing scenarios, as it appears in [13; 14; 15]. This value is related to the quality of the service, since on the one hand, it prevents clients from waiting long for a response, and on the other hand, it allows the system to group requests optimising system resources. The batch size, on the other hand, is more related to the performance of our system and the number of requests it can handle in a reasonable amount of time. In this case, a maximum request limit of 30 is set merely to protect the system during peaks of demand.