1 sec:Introduction↩︎

Transport models are developed to simulate the performance of different components of the transport system. In these models, the mobility of transport system users broadly falls into three categories based on the degree of abstraction: (1) flow-based mobility; (2) queue-based mobility; and (3) interaction-based mobility. Flow-based mobility models represent movement as numeric flows between road network nodes [1], [2]. It is inspired from fluid dynamics, where at each modelled time step, vehicles are moved across nodes representing flows. Queue-based mobility models allow the movement to be based on road capacities. If a road link is at maximum capacity, the moving entities (vehicles, buses etc) only enter the road when there is space [3]. In this case, these entities can remain in the road for the period needed to move through it assuming no congestion. Interaction-based mobility represents the temporal micro-scale movement on road networks. This allows for simulating the process of reducing speed to avoid collisions. In this case, the focus is the moving entities’ behaviours, and congestion becomes an emergent pattern. Individual-based models are particularly relevant in these applications, particularly agent-based models [4].

To deploy these models, the trips made in the system are first generated. The trips can be generated broadly through two approaches: (1) supply and demand approach; and (2) activity-based approach. The supply and demand approach estimates the number of trips based on the attraction of spatial zones (demand) and the available transport services given the transport network (supply) [5]. The activity-based approach estimates the number of trips based on the activities that each individual aims to make during a day [6]. Once trips are defined, the trip modes and routes are selected and optimised to match the initially defined activity schedules. This limits the capacity of the activity-based approaches to account for potential uncertainties in the assigned activities. To address this gap, [7] proposes an activity scheduling framework for calibrating mobility models while modifying activities across the population. To support this framework, we introduce the Multi-Activity Transport and Mobility (MATraM) Agent-Based Model (ABM) framework. MATraM expands on activity-based mobility models by allowing activity modification requests in case of sub-optimal trip times. MATraM is developed in NetLogo [8], and it is available in the following public repository: https://github.com/YahyaGamal/MATraM.

This paper introduces MATraM following the Objectives, Design principles and Details (ODD) protocol [9], [10]. Section 2 focuses on the purpose and patterns. Section 3 focuses on the entities and state variables. Section 4 focuses on the scheduling of events in MATraM. Section 5 focuses on the design concepts. Section 6 focuses on the initialisation of the model. Section 7 highlights the input data formats and provides sample inputs. Section 8 introduces the submodels deployed during the model runs.

2 Purpose and patterns↩︎

The purpose of MATraM is to simulate the mobility patterns of individuals following their daily activity schedules through different modes of transport, particularly cars, buses and walking. It also aims to allow individuals to request to modify their daily activities if their trips are not achieved within their tolerance of high trip times. Daily activity schedules are heterogenous, hence the model generates variable flow patterns across road networks. This yields different patterns of congestion across the system. These congestion patterns contribute to different rates of activity modification requests, alongside the heterogenous tolerance thresholds to long trips.

3 sec:Entities4432state32variables32and32scales↩︎

MATraM includes a set of entities that can be categorised into agents, objects, spatial units and an environment. First, the model includes three types of agents: (1) cars; (2) pedestrians; and (3) buses. Agents have a set of behaviours and actions that they undertake each time step (see sections 8). Second, the model includes two objects: (1) bus templates; and (2) buildings. Both are spatially static and perform no actions. Third, two types of spatial units exist: (1) nodes; and (2) road links. Spatial objects are vector-based geometries representing street networks, where nodes are connection points between road links. As the model is developed in NetLogo, the spatial units are overlaid on square cells that are used as the model’s unit length (e.g., a node of length 10 has a length of 10 square cells). This measuring unit is transformed to miles at initialisation as indicated in section 6. Lastly, the model includes an observer environment [8], which manages the execution of functions temporally and the global state variables. A full list of the state variables for the aforementioned entities are shown in Table [tab:1].

4 sec:Process32overview32and32scheduling↩︎

At initialisation, the observer applies six steps involving executing a set of submodels. A more detailed description of all the submodels is available in sections 6 and 8. First, the observed executes the submodel. This generates the nodes and links representing the road network through which cars and pedestrians will move. Second, the observed executes the submodel. This involves generating the building objects and assigning their IDs, types and positions. It also involves assigning their closest node. Third, the observed executes the submodel. This generates the bus templates and assigns their frequencies and routes as per a set of input parameters, which can be informed from empirical data. Fourth, the observed initialises the bus parameters in the networks. It assigns dummy data to the parameter in road links through which no buses pass. Fifth, the observer executes the and submodels. This generates a number of agents based on the global parameters and . If the model is using empirical data, this submodel is skipped. Instead, the observer generates the population from input data. The submodel handling this process is an additional module that can be added based on the data format used.

During the runs, the observer executes four key steps involving three major submodels. First, the observer requests all the cars and buses to apply the submodel. This initialises the car trips when needed from the vehicles origin to the activities’ destination. It initialises the bus trips at the correct times from their stop-points. It also manages the movement of cars and vehicles during their trips across the road network while avoiding collisions. Second, the observer requests from all the pedestrians to apply the submodel. This initiates the pedestrian trips from their origins to the next activity destination when needed. It assures pedestrians who consider public transport compare alternatives and decide on their route. It also moves pedestrians currently moving to a stop-point or a final destination across the network at their . Third, the observer applies the submodel. This creates the buses at the time step when they should start their route from their initial stop point. Lastly, the observer monitors whether all the cars and pedestrians have finished their full daily activities or not. If so, the observer terminates the model run and signals its completion.

5 sec:Design32concepts↩︎

5.1 sec:Basic32principles↩︎

The model builds on three key modelling concepts: (1) activity-based modelling; (2) optimal route finding; and (3) mobility modelling. First, activity-based modelling is applied during the assignment of activity schedules. This involves generating sequences of activities that require movement from an origin to a destination in space through a mode of transport. Second, for route finding, the model deploys shortest weighted path algorithms to optimise the trip times. The follows an assumptions that individuals are aiming to minimise their disutility by minimising their trip times. It should be noted that this principle can be modified and expanded by substituting the route finding algorithm in the and submodels. Third, mobility modelling is applied to simulate the movement of vehicles space as they aim to complete their trips within time restrictions. MATraM follows a detailed vehicle interaction simulation approach. It simulates vehicle behaviours including speeding down to avoid collisions, rather than using road capacities or queue systems (see section 1).

5.2 sec:Emergence↩︎

The model shows emergence in two aspects: (1) congestion patterns; and (2) trip time distributions. Congestion patterns emerge from the individual vehicle’s behaviours as each tries to avoid collisions [11]. For instance, a singular slow vehicle can lead to periodic congestions on road networks. Trip time bimodal distributions emerge as an outcome in case of random allocation of trip times, origins and destinations in cities. Initial investigations indicate that this is due to the spatial distribution of potential destinations in central city regions, alongside the emergent congestion in central areas. Overall, this yield a high number of moderately long trips going to central areas (initial distribution peak) and increases the trip times of longer trips that pass through the central areas (second distribution peak).

5.3 sec:Adaptation↩︎

Agents adapt to a set of stimuli to achieve their objectives. First, cars adapt to other vehicles ahead on their road link. If the car’s leads to a collision in the next time step, the car decreases stops and decreases its to zero. This directly achieves the objective of avoiding collisions. Cars also identify the quickest routes to reach their activity destination while considering congestion. In doing so, they update their which may imply starting their trip earlier to make up for expected congestions. This is in alignment with the two objectives: make the trip in the shortest time; and reach the activity destination on-time or early.

Second, pedestrians adapt their mode of transport choice based on the available alternatives. Pedestrians consider their surrounding stop-points and all the bus alternatives; they use the to dictate the region in which stop-points are considered. If no stop points are found, they adapt by increasing the search region by a . An alternative bus route that yields the quickest trip is then selected. Further, they compare the quickest bus trip to a normal walk trip, and select the quickest alternative. These adaptations align with the objective to make the trip in the shortest time. Pedestrians also adapt their start time to bus schedules – in case of using buses. They access the of the stop-point from which they will take the bus. They select the latest bus that will arrive to their activity at the required . Individuals adapt their trip start time to ensure they catch the preferred bus. This aligns with the objective to reach the activities on-time or early.

Third, buses adapt their moving time from stop-points based on the . If a bus reaches a stop point earlier than required in the , the bus waits until the required arrival time. This achieves the objective that buses aim to be maintain the stop-point , including avoiding leaving earlier that stated.

5.4 sec:Objectives↩︎

The model includes three key objectives, relevant to different types of agents: (1) minimise trip times (cars and pedestrians); (2) arrive on-time or early to activities (cars and pedestrians); (3) maintain stop-point schedules (buses) and (4) avoid collisions (cars and buses).

First, minimising trip times is a direct objective that is achieved by considering alternative routes and modes of transport where possible (see section 5.3). In all cases, agents consider an objective measure of expected trip times and select the minimum value as the best alternative. This follows a utility maximisation concept if long trip times are framed as a disutility (a negative utility value) – it should be noted that the agents do not calculate a utility value when making the decisions.

Second, arrival on-time or early is achieved by adjusting the trip start time to the of the respective trip. In doing so, agents consider starting the trip each time step, generating an alternative per time step. The selected alternative is temporally the first one satisfying the condition in equation 1 . \[\label{eq:1} T + p_{i,j\rightarrow j+1|T} + b_{i,j+1} \geq t_{i,j+1}\tag{1}\] where \(T\) is the current time step, \(p_{i,j\rightarrow j+1|T}\) is the expected period incurred by an agent \(i\) to move from the activity \(j\) to the activity \(j+1\) at \(T\), \(t_{i,j+1}\) is the target arrival time step to the activity \(j+1\) and \(b_{i,j+1}\) is the for arriving earlier than the actual activity start time.

5.5 sec:Prediction↩︎

First, prediction is explicitly applied to support the decision of when to start a trip. Cars and pedestrians select and update their optimum routes, and accordingly predict the of their trips. These predictions consider the current congestion patterns for cars and buses, and accordingly can vary across different time steps. Based on that prediction, cars and pedestrians move at time periods that are expected to assure they reach their activity destinations at the .

Second, prediction is explicitly used to avoid collisions. Cars and buses predict collisions given their current speed trajectory and their surrounding vehicles. Based on that prediction, they stop to avoid colliding with ahead vehicles.

Lastly, prediction is also implicitly applied when buses wait to maintain the of stop-points. Buses implicitly predict that when they move on-schedule from a stop-point, they will reach the next stop-point at on-time. This may deviate due to low or high congestion rates. This is partly corrected in subsequent stop-points where possible by repeating the wait behaviour.

5.6 sec:Sensing↩︎

Sensing represents the agents’ awareness of the positions and state variables of their surrounding entities.

First, cars and pedestrians sense the road network congestion patterns. Cars achieve this by gaining access to the state variable of the roads. They find the best route in the system that minimises the trip time (i.e., minimises the total if the route). Pedestrians access the and road state variables. These are used to find the bus and walk trips yielding the shortest trip time to the destination (i.e., lowest total route for trips including buses and lowest route for walk trips).

Second, cars and buses sense the road link length as they move on it. They access the road state variable, which represents the road length, and compare it to their distance from the road link nodes. This is used to identify when the car or bus reach the end of the current road link.

Third, cars and buses sense the position of other cars and buses ahead on the same road network. This information is used to avoid collision by stopping.

5.7 sec:Interaction↩︎

Cars and buses directly interact with each other as they move on street networks. Each vehicle senses others on the road network and stops if the trajectory given its will lead to a collision. This interaction at an agent level yields macro-scale congestion patterns.

Pedestrians directly interact with buses by taking up a unit of when they use a bus. This is a mediated interaction between pedestrians as they consume the limited bus resource. When the bus reaches maximum capacity, pedestrians at stop points are unable to board the bus. This has an impact on their trip time.

5.8 sec:Stochasticity↩︎

Stochasticity is only applied in MATraM during the initialisation phase if no input synthetic population is provided. In that case, the model randomly assigns cars and pedestrians to residential buildings ( ). For each car and pedestrian, it randomly generates a set of parameters. First a series of activities ( ) with a sequence of random arrival times ( ) and destinations ( ) are generated. The minimum number of activities is one activity, and the maximum is based on the input parameter . Second, a randomly generated is assigned to represent variance in the time an agent moves earlier to reach its activity destination. The buffer period ranges from zero to the input . Third, a random to long trips parameter is generated. This assures a heterogenous representation of agents that may request an activity modification at a different threshold.

It must be noted that some of the aforementioned stochastically generated parameters are bypassed based on the initialisation input. First, if a synthetic population is provided as an input, the stochastic initialisation of activity sequences, target arrival times and destinations is bypassed. This is because a synthetic population is expected to include information on the , and . Second, the parameter is not stochastically generated if its empirical inputs are provided. This can be attached as a parameter in the synthetic population.

5.9 sec:Collectives↩︎

Collectives are represented in the model during the commute of pedestrians in buses. Pedestrians create spatial links with the buses they are currently using. Accordingly, they move in the same direction and at the same speed of the bus. This creates a collective of pedestrians in each bus on the road network.

5.10 sec:Observation↩︎

These observations are selected in alignment with the aim to support an activity scheduler framework including activity modifications. The activity modification requests in MATraM are an input to the activity scheduler framework. These requests are dependent on the trip times and delays in arrival to activities. According, MATraM focuses on three key observation metrics: (1) trip time; (2) delay period; and (3) activity modifications. First, mean trip time considers the incurred trip times of all the trips made in the system until a given time step. It is visualised as a time series graph for meant trip times each time step. A histogram of trip times is also generated to show potential emergent distributions. Second, delay time ( ) is the number of time steps between the actual arrival and the of each activity. It is visualised as a histogram to identify the distributions of and potentially link them to the activity modification requests. Third, activity modifications indicate the number of instances a car or a vehicle requested an activity modification due to high that exceed their for long trips. This is generated as a time series of the total number of activity modifications until each respective time step.

6 sec:Initialisation↩︎

The initialisation in MATraM is designed to allow for transferability across different contexts. It follows three key steps: (1) generate the spatial context; (2) generate the buses; and (3) generate the cars and pedestrians. A set of initialisation submodels are applied sequentially as described in sections 6.1-6.5 – the sequence of submodels during initialisation is also briefly described in section 4. A sample initial state for Tillydrone, Aberdeen, UK is shown in Figure 1.

6.1 Submodel: sec:load-buildings↩︎

The submodel initialises building objects. It uses input data including the x and y positions of residential and non-residential building (see section 7). Based on that, the spatial locations and types of buildings are assigned ( ). The submodel also identifies the closest node to each building. It identifies the node with the shortest Euclidean distance from the building, and it assigns it as the .

6.2 Submodel: sec:load-network↩︎

The submodel initialises the node objects and road links. It uses input data including the x and y positions of each node, the IDs of the connected nodes through road links and whether the node is a bus stop point or not (see section 7). First, the submodel generates nodes and assign their spatial location. It also initialises its bus related state variables as empty lists, namely , , , , , and . These state variable lists are later assigned values in the submodel. Second, the submodel creates undirected road links between the nodes with linked IDs in the input data. It calculates the length of each link and assigns the value to the state variable. This involves finding the distance between the nodes and transforming it from the model units to miles. Then, it assigns each road link an ID ( ) and a maximum speed ( ) in miles/hour. Based on the and the , the submodel assigns the of the road network. At initialisation, this period reflects the time taken by a car moving at the maximum speed to move through the road network. It is later updated during the runs to reflect potential congestion patterns. The submodel also initialises the state variable as an empty list. This is assigned values as vehicles move across the road links during the runs, and it is used to support the route choice process in the submodel.

6.3 Submodel: sec:load-buses↩︎

The submodel initialises the bus templates. It uses input data including the service number, the sequence of stop points, the time period taken to move from one stop point to the next and the bus frequency (see section 7). The submodel initialises a bus template object and locates it spatially at its initial stop point. It also draws from the input data the state parameters , , and . It also initialises a set of parameters with standard values as shown in Table 1.

6.4 Submodel: sec:cars-init↩︎

The submodels generate the car agents. This defaults to a stochastic generation of car parameters unless a synthetic population is provided. It must be noted that the generation process of cars based on synthetic populations is not included in this model as data input formats can vary across different contexts. Section 7 outlines the key parameters required in a synthetic population for MATraM.

First, the submodel creates a number of cars as per the . It assigns each car to a random residential building. It assures the car is labelled as active ( ), at an activity ( ) and an the initial step ( ). It then generates a set of stochastic parameters, including the activity sequences ( ), based on their respective input variables as shown in Table 2. The rest of the parameters are initialised as empty lists, and they are addressed in the next submodel steps.

Second, the submodel iterates through each generated activity and assigns a random building as their destination – this generates the list . It then identifies the route yielding the lowest total from the car’s first activity (home) to the second activity. Accordingly, it assigns a list of links to the state variable of the car. The submodel then deploys the and sub-submodels per activity. Both sub-submodels identify the shortest routes, based on the road links’ , from an activity to its subsequent one. The sub-submodel returns an expected time period to reach an activity assuming a vacant system, and this value is assigned to the state variable. The reports a target time step to reach an activity. This is based on the reported expected period and a randomly generated period of time to spend at each activity as shown in equation 2 . \[\label{eq:2} t_{j+1} = t_{j} + p_{j\rightarrow j+1} + p_{j+1}\tag{2}\] where \(t_{j+1}\) and \(t_{j}\) are the target times to reach the destination and \(j + 1\) \(j\) given that \(t_j = 0\) for the first activity, \(p_{j\rightarrow j+1}\) is the time period needed to move from activity \(j\) to activity \(j+1\) and \(p_{j+1}\) is a randomly generated period to stay in activity \(j+1\) between 0 and the .

Third, the submodel then addresses a set of activity related state variables. These variables are lists whose indices are aligned with the indices in the state variable. Table 3 shows the generated values for an element in each of these lists, where each list has the same length as the list state variable.

Lastly, the submodel calculates the actual cancel period per activity (equation 3 ). It then calculates a normalised activity weight per activity (equation 4 ). These values are assigned as lists to the parameters and , and they provide further information on the thresholds of requesting an activity modification. \[\label{eq:3} c_j = c^\%_j.p_j\tag{3}\] \[\label{eq:4} w_j = 1 - \frac{c_j}{max_{j'\in J}(c_{j'})}\tag{4}\] where \(c_j\) is the cancel-period for activity \(j\), \(c^\%_j\) is the for activity \(j\), \(p_j\) is the period spent at activity \(j\), \(w_j\) is the activity weight and \(J\) is the set of activities planned by the agent

6.5 Submodel: sec:pedestrians-init↩︎

The submodel generates the pedestrian agents following a similar logic to the submodel. It defaults to a stochastic generation of pedestrians unless a synthetic population is given as an input. The synthetic population pedestrians generation process is not developed in MATraM as data formats vary across different applications. For further details on the required information in a synthetic population for MATraM, see section 7.

First, the submodel creates a number of pedestrians based on the . Similar to cars, it assigns each pedestrian a random residential building as its home. It labels the individual as active ( ), at the initial time step ( ) and at an activity ( . It then generates a set of stochastic parameters as shown in Table 4. The state variables of and are initialised as , and the rest of the parameters are initialised as empty lists.

Second, the submodel iterates through the state parameter, assigns each activity a building and accordingly generates the list. The shortest route from home to the first activity is then identified assuming pedestrians do no use public transport. This can be later modified during the runs in the submodel if a bus trip is deemed more optimum than a walk trip (see section 8.8). The submodel then deploys the and sub-submodels. Both sub-submodels assume pedestrians do not use public transport, and accordingly find the shortest walk routes between each activity and its subsequent one based on the . The provides the expected time period to reach each activity assuming no use of public transport. These walk periods represent the longest time a pedestrian takes to reach an activity, as public transport is only used if it yields shorter times during the runs. Further, unlike cars, the pedestrians’ trip times remain the same in a vacant or a congested system during the runs. Accordingly, the reported walk periods at initialisation assure the generation of achievable in the sub-submodel. The calculation of is applied similar to the submodel as shown in equation 2 .

Third, the submodel addresses the , and state variables. These state variables are lists whose indices reflect the indices in the state variable. Each list element is assigned values similar to the submodel as previously shown in Table 3.

Lastly, the submodel calculates the cancel periods and activity weights for each activity similar to the submodel (equations 3 and 4 ). The calculated values are assigned to the and variables.

7 sec:Input32data↩︎

The model requires input data related to four entities in the model: (1) buildings; (2) nodes; (3) road links; and (4) buses. The data is provided in table format, with columns including necessary information to initialise each entity. The required information for each entity are described hereafter. It must be noted that the table input files must be named as mentioned in this section, and the order of the columns must match the sample table data shown for each entity.

7.1 Buildings input data↩︎

Buildings require spatial information on their x- and y- positions in space. This spatial information must be normalised from 0 to 1 so that the submodel can correctly assign the building locations. To clarify, for instance, if the model space dimensions are 10 x 10 spatial units, then the an x-position of 0.6 translates to 6 spatial model units in the x direction.

To define the building typology, the x and y positions are provided in two separate tables. The table defines homes, and the defines non-residential buildings. Table 5 shows a sample input data for either houses or buildings.

7.2 Nodes input data↩︎

Nodes require spatial information on their ID, x and y positions and whether they are stop points or not. First, the node IDs can be provided in any string or numeric format, and they are referred to in the road links input data (section 7.3). Second, similar to buildings, the spatial information must be normalised from 0 to 1. Third, the stop points are indicated through providing an ID where a negative ID indicates the node is not a stop point and positive ID indicates otherwise. The positive ID is later used to indicate the stop points each bus service visits (section 7.4). This information is provided in a table to the model. A sample of the tabular data is provided in Table 6.

7.3 Road links input data↩︎

Road links require information on their IDs, the IDs of their connecting nodes and their maximum speed in miles per hour. First, similar to nodes, the IDs can be any string or numeric values. Second, the connecting nodes IDs refer to the IDs of the nodes provided in the nodes input data (section 7.2). The node IDs are provided as start and end points in the input tabular data. Third, the maximum speed must be provided as a string in the following format: "<digits> mph". If the maximum speed is provided as a "None" string, the road is assumed to have no speed cap. Table 7 shows a sample tabular data provided in the to the model.

7.4 Buses input data↩︎

Buses require information on (1) their service number, (2) the sequence of the stop point IDs they stop at, (3) the period taken to move from one stop point to its subsequent one, (4) the service frequency at each stop point and (5) whether the stop point is where the bus service starts or not. Unlike the previously mentioned input data, the buses tabular data does not refer to a bus per entry (row). Instead, each entry refer to a stop point visited by a specific bus – hence one bus service is expected to have multiple entries.

First, the service number can be a numeric or string value. Second, the sequence of stop points refer to stop point IDs indicated in the nodes input data (see section 7.2). Each row entry indicates one stop point for the service number with the given ID in that row. Accordingly, the row entries with the same service number dictate the sequence of the stop points for that service number. Third, the time period needed to reach the stop point from the previous one is provided as a numeric value in minutes. If a stop point is the first one, its time period must be zero. Fourth, the frequency is provided as numeric value in minutes, and it represents that time between the arrival of two buses with the same service number at each stop point. Fifth, the indication of whether the stop point is where the service starts is indicated through a binary value; 1 indicates the service starts at this stop point and 0 otherwise.

The data is provided to the model in a file named . For clarity, Table 8 shows a sample input data including two services.

8 sec:Submodels↩︎

As stated in the process overview and scheduling (section 4), MATraM includes two key submodels during the runs: (1) ; and (2) . These submodels manage the behaviours of cars, buses and pedestrians. A detailed description of each submodel and its respective sub-submodels is provided hereafter.

8.1 Submodel: vehicles-move↩︎

The submodel manages both cars and buses. For cars, if a car is active ( ), it calls the sub-submodel (section 8.2). For buses, it calls the sub-submodel (section 8.3).

8.2 Sub-submodel: sec:cars-travel↩︎

The sub-submodel is executable for cars. Its flowchart logic is shown in Figure 2 and described hereafter. First, the sub-submodel addresses cars currently undergoing an activity ( ) in its respective . For each of those cars, the submodel iterates through the subsequent activity in the state variable. It identifies the shortest route from the nearest node of the current car location to the nearest node of the respective activity building in the list. This shortest route minimises the total between the nodes, rather than trip times. The generates an ordered list of links (route) are assigned to the state variable of the car. If the includes no list, this implies the current and next activity has the same nearest node – therefore, the car does not need to move. In this case, the submodel skips this activity, proceeds to the next one and repeats the same process of finding routes and defining trips. This is repeated until an activity with a trip including at least one road link is found, or until no subsequent activities exist. The outcome of this process is an assigned trip for the next activity of a car. The sub-submodel then checks if the car’s trip does not include any links and if the car is at its last . In that case, the car is deemed as inactive ( ). This ensures that the car is no longer addressed in this sub-submodel or in submodel in the next time steps. The sub-submodel then iterates through road links in the generated trip. For each road link, it accesses the . It then calculates the sum of the values of all the links in the . This replaces the for the next activity, which implies the car considers the effect of current congestion patterns on trip time. The sub-submodel then calculates the period at which the car will cancel the trip for the next activity as per equation 3 . This value replaces the element in the variable at the respective next activity index. This ensures that the are updated based on the current congestion patters. The sub-submodel then identifies whether the car should start moving to the next destination or not. It compares the target arrival time \(t\) to the next activity current time step (\(T\)), the (\(b\)) and the current expected period (\(p\)) as per equation 1 . If the condition in equation 1 is satisfied, the submodel moves the car to the nearest node of its current location if no other cars are currently at that node, and it labels it as not at an activity ( ). This assures that no unintended collisions occur at the beginning of the car’s trip.

Second, the sub-submodel addresses the cars currently not engaged in an activity ( ). These cars are currently making a trip on the road network to their next activity. The sub-submodel initiates the of the car as its . It then initiates the sub-submodel as described in section 8.5. This modifies the of the car to assure no collisions occur. Subsequently, the sub-submodel is executed as described in section 8.7. The sub-submodel then checks if the car reached end of its current road link in the . This is applied by calculating the length of the road link to the distance the car made from the origin node of the road link. If the is higher than length of the road link, then the car had reached the end of that link. In that case, the sub-submodel updates the of the car as the current time step. It then assigns the of the completed road network as shown in equation 5 . \[\label{eq:5} r_k = a_{i,n_1} - a_{i,n_2}\tag{5}\] where \(r_k\) is the a car takes to move across the road link \(k\), \(a_{i,n_1}\) is the representing the time step at which a car \(i\) reached the start node \(n_1\) of the road network \(k\) and \(a_{i,n_2}\) is the representing the time step at which a car \(i\) reached the end node \(n_2\) of the road network \(k\).

The sub-submodel then checks the of the car. If the includes links, meaning the car has to continue its trip, the sub-submodel is executed as described in section 8.6. This modifies the , allocates the car’s new road link start node ( ) and end node ( and ensures any progress distance made beyond the previous road end node is not lost. If the includes no links, meaning the car finished its trip, the car is moved to its current . The car adds the period it took to reach the activity to its list. It also calculates the delay as per equation 6 and adds it to the list . \[\label{eq:6} y_{i,j} = T - a_{i,j}\tag{6}\] where \(y_{i,j}\) is the delay time steps for incurred by the car \(i\) to reach the activity destination \(j\) and \(a_{i,j}\) is the arrival time at the activity destination \(j\)

The car then checks if the period to taken to reach the activity is higher than its respective cancel period (in the state variables). If so, the car adds the modifies the respective element in the to its list to "cancel", and it flags it requests an activity modification ( ). The car then checks if its current is the last building in its list. If so, the car flags itself as at an activity ( ) and inactive . Otherwise, the car increments its to refer to the next activity index, updates its and flags itself as at an activity ( ). The car then finds the shortest route to its next and assigns the sequence of road links to its .

8.3 Sub-submodel: sec:buses-travel↩︎

The sub-submodel addresses buses, and it follows a similar logic to the sub-submodel (section 8.2). The flowchart of the sub-submodel is shown in Figure 3 and described hereafter.

First, the sub-submodel addresses buses currently at a stop point ( ). For each of those buses, the sub-submodel finds the shortest route from their current stop point (the bus’s ) to the next stop point (the bus’s next item in . The sub-submodel assigns the sequence of links of the shortest route’s to the bus’s state variable. It then iterates through the road links in the to access each link’s . This allows the sub-submodel to identify the total expected period for the trip and update the respective element in the bus’s list. The calculated expected period is then used to identify the expected arrival time of the bus in the next stop point as shown in equation 7 . \[\label{eq:7} a_{s+1} = T + p_{s\rightarrow s+1}\tag{7}\] where \(a_{s+1}\) is the arrival time at stop point \(s+1\) and \(p_{s\rightarrow s+1}\) is the period taken to travel from stop point \(s\) to stop point \(s+1\).

The sub-submodel then checks the condition \(a_{s+1} \leq t_{s+1}\) – where \(t_{s+1}\) is the target arrival time to the next stop point. If this condition is satisfied, the bus is expected to either arrive on-time \(a_{s+1} = t_{s+1}\) or late \(a_{s+1} > t_{s+1}\) to the next bus stop. In both cases, the of the next stop point is modified to reflect the expected arrival time. This assures that pedestrians plan their trip in case of a late bus arrival. The bus then executes the sub-submodel as described in section 8.6. This manages the and allocates the start and end nodes of the first road link as the and respectively.

Second, the sub-submodel addresses buses currently making a trip from one stop point to another. It assigns the of the bus as its . The sub-submodel is then executed as described in section 8.5. This updates the of the buses to avoid collisions. Following this, the sub-submodel is applied as per section 8.7. The sub-submodel then compares of the bus to the length of the road link it is currently travelling on. If the is higher, then the car has reached the end point of that road. Accordingly, the sub-submodel updates the of the bus (destination refers to the road link end node). It also assigns the of the road link as per equation 5 . This assures that cars and buses planning their next trips consider updated travel times reflecting congestion patterns. The is then checked. If it includes links, the sub-submodel is applied as per section 8.6. This assures the bus moves to the next link in the and modifies the accordingly. It also assures any made beyond the length of the previous road link is incurred in the next road link. If the does not include include any links, the bus moves to its target signalling an end to its current trip. The bus updates its to include the time period it took to reach the .

The bus then checks if the reached stop point ( ) is its last stop point (last item in ). If the condition satisfied, the bus is removed from the simulation system. Otherwise, the bus increments its to refer to the next item in . It accordingly updates its , and it also removes the previous stop point from the . The bus flags it is currently at a stop point . It also finds the shortest route to its next stop point from its current location. The sequence of road links are assigned to the state variable.

8.4 Sub-submodel: sec:buses-start-SPs↩︎

The addresses the bus templates to create buses. The sub-submodel accesses the stop point nodes from which buses should start this time step (i.e., nodes with ). It extracts a list of these starting bus service numbers and accesses their respective bus templates. Accordingly, it updates the of each respective stop point node as the of the respective bus’s template. This assures that the next bus will be created at the correct time step. The sub-submodel then creates buses which inherit the state variables of their respective bus templates. The bus template state variables values are shown in the sub-model (section 6.3), and the input data to indicate the number and of the model are described in section 7.

8.5 Sub-submodel: sec:check-ahead↩︎

The sub-submodel is applicable for both cars and buses (labelled as vehicles). The sub-submodel considers one vehicle at a time. First, it finds the set of vehicles that satisfy five conditions: (1) the vehicle is not at an activity ( ); (2) the node of the car or bus is the same as the of the considered vehicle; (3) the car or bus made more progress ( ) on the road link than the considered vehicle; (4) the direction the car or bus is facing is the same as that of the considered vehicle; and (3) the car or bus is within one model space unit distance from the considered vehicle. Out of all the cars and buses satisfying the aforementioned conditions, the closest one to the considered vehicle is selected. This is assigned as the nearest car or bus from the considered vehicle travelling in its same direction.

Second, it addresses the of the considered vehicle (labelled \(i\)) based on the of and distance from the closest car or bus (labelled \(i'\)). If the closest car or bus is not moving ( ), the considered vehicle also stops. If the closest car satisfies the condition \(D_{i\leftrightarrow i'} > 2.v_{i}\), the considered vehicle stops – where \(D_{i\leftrightarrow i'}\) is the distance between \(i\) and \(i'\) and \(v_{i}\) is the speed of \(i\) per time step. If the closest satisfies the condition \(D_{i\leftrightarrow i'} > 3.v_{i}\), the considered vehicle checks the of the closest bus or car \(i'\). If \(v_i > v_{i'}\), the considers vehicle lowers its \(v_i\) to match that of the ahead vehicle \(v_{i'}\).

8.6 Sub-submodel: sec:set-destination↩︎

The sub-submodel is executable for both cars and buses (vehicles). It is called once a vehicle reaches the end node of the road link it is currently moving through or when the vehicle is starting its trip. The sub-submodel extracts the first element of the list, which is a road link. It then defines the as the road node where the vehicle is at, and it defines the as the other road node. It then removes the first element of the state variable. This assures the represents the remaining road links to reach the activity destination, excluding the current one.

8.7 Sub-submodel: sec:move-at-correct-speed↩︎

The sub-submodel is applicable for both cars and buses. First, it assures the vehicle’s is the lower of two values: the of the current road; and the of the vehicle. Second, it spatially moves the vehicle forward the distance covered at its per time step. This distance varies on changing the input global state variable. Third, it updates the of the car to reflect the distance between the vehicle and the road node after the vehicle moved.

8.8 Submodel: sec:pedestrians-move↩︎

The sub-submodel manages pedestrians. If a pedestrian is active ( ), it calls the sub-submodel as described in section 8.9.

8.9 Sub-submodel: sec:pedestrians-travel↩︎

The follows a similar logic to the sub-submodel (section 8.2) for walk trips, and it deviates for bus trips. A flowchart of the logic of the sub-submodel is shown in Figure 4 and described hereafter.

First, the sub-submodel addresses pedestrians currently at an activity ( ). For each of those pedestrians, the shortest route to the next activity in the list state variable is identified. The sequence of road links in that route are assigned to the . If the happens to not have any links, this implies that the next activity has the same nearest node on the road network as the current location of the pedestrian. Accordingly, the sub-submodel skips this activity and iterates to the subsequent one. This is repeated until a with at least one road link is found or until there are no subsequent activities. If it is the latter case, the pedestrian moves to its last building in the list and it is flagged as inactive ( ). Inactive pedestrians are no longer addressed in this sub-submodel.

The sub-submodel then finds the optimum trip, including potential use of buses. If the pedestrian uses buses ( ), the sub-submodel finds two optimum trips: a trip including one bus and a trip including walking only. For the bus trip, the sub-submodel identifies the stop point surrounding the pedestrian’s location (origin stop points) and surrounding the pedestrian’s activity destination (destination stop points) within the . The bus services linking the origin and destination stop points are then identified – these are viable bus routes for the pedestrian’s trip. If no viable bus routes are found, or if no origin or destination stop points are found in the first place, the radial search region is expanded by the . This process is repeated until at least at least one viable bus route is found. The sub-submodel then finds the quickest trip given the alternative viable bus routes. It subdivides the trip into three legs: (1) a walk leg to the origin stop point; (2) a bus trip from the origin stop point to the destination stop point; and (3) a walk leg to the activity destination. The walk legs are defined as the quickest route from each respective origin and destination. To find this route, the shortest route yielding the lowest is defined. The expected travel period for that route is assured to be the lowest as pedestrians are not restricted to the of the road links. The expected period is calculated for each leg as shown in equation 8 . \[\label{eq:8} p_{i,m_1\rightarrow m_2} = \frac{\sum_{l\in L_{m_1\rightarrow m_2}}d_{l}}{v_i}\tag{8}\] where \(p_{i,m_1\rightarrow m_2}\) is the walk travel period from an origin \(m_1\) to a destination \(m_2\), \(L_{m_1\rightarrow m_2}\) is the set of road links connecting \(m_1\) and \(m_2\) through the shortest route, \(d_l\) is the length of the road link \(l\) in the set of road links \(L_{m_1\rightarrow m_2}\) and \(v_i\) is the speed of the pedestrian \(i\).

The bus leg is defined as the quickest route from the origin stop point to the destination stop point. That is, the route that includes the sequence of road links incurring the lowest sum of state variables. For each three legged trip, the total time period to finish the three legs is calculated, and the trip with the lowest time period is selected as the optimum bus trip. Following this, the pedestrian identifies the shortest walk route from its location to the activity destination. That is, the route including the road networks incurring the lowest sum of . The travel period across that walk trip is calculated as previously described in equation 8 . The sub-submodel then compares the two optimum full walk and bus trips, and it selects the one with the lowest travel period. This decision indicates whether the pedestrian will use buses or not. Accordingly, the (list of road links per leg), ("walk" or "bus") and (expected time needed to finish each leg) are updated. It should be noted that a bus trip element in the is defined as a list indicating the origin stop point, the bus template for the used bus service and the destination stop point.

If the pedestrian does not use buses ( ), the shortest route is identified as per the walk only trip for pedestrians considering buses. The trip parameters are also updated as previously mentioned.

The sub-submodel then checks whether each pedestrian should move from its location or not to arrive at the destination of its first trip leg. If the pedestrian has a full walk trip, it compares the to the and as shown in equation 1 . If the condition in equation 1 is satisfied, the considered pedestrian moves to the first node in its first trip leg and executes the sub-submodel as described in section 8.10.

If the pedestrian is planning to use a bus, the sub-submodel traces its trip back from the last leg in the state variable. For the last leg, the sub-submodel considers the latest time the pedestrian must start walking from the destination stop point to the activity as per equation 9 . \[\label{eq:9} t'_{i,s_2} = t_{i,j+1} - p_{i,s_2\rightarrow j+1} + b_{i,j+1}\tag{9}\] where \(t'_{i,s_2}\) is the latest time to start moving from the destination stop point \(s_2\) to arrive to the next activity \(j+1\), \(t_{i,j+1}\) is the target arrival time to the next activity \(j+1\), \(p_{i,s_2\rightarrow j+1}\) is the time period taken to walk from the destination stop point \(s_2\) to the activity \(j+1\) and \(b_{i,j+1}\) is the buffer period.

The sub-submodel then accesses the of the destination stop point for the selected bus service. It identifies the latest time satisfying the condition \(a_{s+2}\leq t'_{i,s_2}\) – where \(a_{s+2}\) is the arrival time of the selected service at the destination stop point. Given \(a_{s_2}\), the sub-submodel traces the respective arrival time of the same bus at the origin stop point of the pedestrian \(a_{s_1}\) – where \(s_1\) is the origin stop point. Accordingly, the arrival time to the destination of the first leg (i.e., the origin stop point \(s_1\)) is considered as \(a_{s_1}\). The sub-submodel considers a similar condition to equation 1 as shown in equation 10 . \[\label{eq:10} T + p_{i,j\rightarrow s_1} + b_{i,j+1} \geq a_{s_1}\tag{10}\] where \(p_{i,j\rightarrow s_1}\) is the time period taken to walk from the activity \(j\) to the origin stop point \(s_1\).

If the condition in equation 10 is satisfied, similar to the full walk trip pedestirans,it moves to the first node of its first trip leg and executes as per section 8.10.

Second, the sub-submodel addresses pedestrians currently making a trip to an activity destination. These pedestrians fit into three categories: (1) walking, (2) on a bus; (3) and waiting for a bus. If the pedestrian is walking (current ), it executes the sub-submodel as described in section 8.11. If the pedestrian is on a bus or waiting for a bus (current ), it executes the sub-submodel as described in section 8.12. This addresses the behaviours of pedestrians waiting for a bus ( ) and pedestrians on a bus ( ). If the pedestrian is waiting for a bus, it takes no action.

The sub-submodel then considers pedestrian who made more than the length of its current road links for the three aforementioned pedestrians categories. If the pedestrian is walking and still has subsequent links in its , it executes the sub-submodel as described in section 8.10. The pedestrian then executes the as described in section 8.11. This assures the state variable is updated to reflect the remaining links in the current leg. It also assures the made beyond the length of the road link is not lost. If the pedestrian is walking, has no subsequent links in its and is on its final trip leg, it implies it reached its activity destination. Accordingly, it moves to the respective building in its and updates its accordingly. It also adds the time period it took to reach the activity to its list. It then calculates the delay, similar to cars, as indicated in equation 6 . The pedestrian then checks if the period incurred to reach the activity is higher than the respective cancel period in the state variable. If so, the pedestrian flags an activity modification by updating the respective item to "cancel" and setting . The pedestrian then checks if it has no subsequent buildings in its list. If so, the pedestrian indicates it is inactive and that it is at an activity . Otherwise, the pedestrian finds the shortest route to the next item in the list. This is adjusted in a later time step to find the optimum walk or bus trip. If the pedestrian is walking, has no subsequent links in its and is not on its its final trip leg, this implies it reached its origin stop point. In this case, it moves to that stop point (in case it made more at its last link), and it flags it is waiting for a bus . If the pedestrian is on a bus, has no subsequent links in its and is not on its final trip leg, this implies it reached its destination stop point. In this case, it updates its to reflect the next walk trip in its . If the trip happens to include no links, this implies that the destination stop point is the closest node to the activity destination. In this case, the pedestrian updates its and to that stop point – this prepares the pedestrian to execute the in the next time step. If the walk trip includes links, the pedestrian executes the to assure it updates its , (start node of the first trip link) and (end node of the first trip link). If the pedestrian is on a bus, it takes no action as all the movement is managed in the previously executed sub-submodel.

8.10 Sub-model: sec:pedestrians-set-destination↩︎

The sub-submodel is executable for pedestrians, and it follows a similar logic to the sub-submodel (section 8.6). It is called if a pedestrian is starting a walk trip leg or has reached the end node of its current road link on a walk trip leg. The extracts the first road link in the . It then defines the and as the start and end road link nodes from the pedestrian’s perspective. It then updates the to not include that road link to ensure it represents the remaining links in the trip only. It should be noted that the sub-submodel is separated from the one to allow for flexibility with assigning different behaviours for pedestrians and vehicles in future expansions of MATraM.

8.11 Sub-submodel: sec:move-at-pedestrians-speed↩︎

The sub-submodel is applicable for pedestrians. It follows a similar logic to the (section 8.7) except that it does not consider road links . It spatially moves the pedestrian forward the distance covered at its maximum speed while considering the time step scale . It also updates the of the pedestrian to reflect the remaining distance to the end node of the current road link.

8.12 Sub-Submodel: sec:move-in-bus↩︎

The sub-submodel is applied for pedestrians waiting for a bus ( ) and on a bus ( ). If the pedestrian is waiting for a bus, it identifies the bus services that connects its origin stop point and destination stop point. It then checks if any of those services are currently at its origin stop point (i.e., its ). If it finds one, it increments the of that bus by 1, and it creates a passenger link with the bus. This link ties the movement of the pedestrian spatially with that bus. The passenger then updates its , flags that it is on a bus ( ) and flags it is no longer waiting for a bus ( ). It updates its as the , and it updates its as its destination stop point. It also updates the to only include the destination stop point – noting that the for a bus trip is initiated with the origin stop point, the bus template and the destination stop point.

If the pedestrian is on a bus, and the bus has reached the pedestrian’s stop node destination, the passenger deletes the passenger link with the bus. It flags it is no longer on a bus ( ) and it is no longer waiting for a bus ( ). It downgrades the bus by 1 and updates its as none.

9 sec:Discussion↩︎

The development of MATraM highlights both the potential and the current limitations of activity-based transport modelling. By introducing an agent-based framework capable of structuring daily activities while explicitly simulating mobility, this work seeks to overcome a well-recognised rigidity in existing approaches. Conventional activity-based models typically rely on fixed daily schedules, which constrains their ability to reflect behavioural adaptation. This rigidity has important implications. It complicates model calibration, as uncertainties embedded in initially assigned activity schedules are effectively ignored, and it limits the capacity of models to explore how individuals might respond to changes in the urban environment, such as policy interventions or infrastructure disruptions.

MATraM addresses these challenges through a flexible mechanism for identifying and responding to sub-optimal travel conditions. By enabling the flagging of activity modifications when trips deviate from expected performance, the model introduces a dynamic feedback between mobility outcomes and activity scheduling. This represents an important conceptual shift, as it allows behaviour to evolve endogenously rather than being imposed ex ante. As a result, MATraM is better positioned to capture the interplay between individual decision-making and system-level dynamics, particularly under conditions of uncertainty or change.

A key strength of the framework lies in its transferability. The parameters governing activity modification are not restricted to travel time alone but can be extended to incorporate alternative behavioural drivers. For example, frameworks such as OASIS [6] provide complementary parameterisations that could be embedded within MATraM to reflect broader activity generation and decision-making processes. While these extensions will require further empirical work to define appropriate thresholds and probabilities for behavioural change, the modular design of MATraM enables such integration, underscoring its value as a flexible modelling platform.

There remain several avenues for future research. Enhancing the representation of traffic dynamics, including lane-level interactions, would improve the realism of simulated mobility. Expanding the model to include additional transport modes, such as cycling, and incorporating mode-specific routing constraints would further broaden its applicability. In addition, closer integration with emerging activity modification frameworks, including recent GeoAI-based approaches [7] offers a promising direction for strengthening the behavioural realism of the model. Collectively, these developments would support the evolution of MATraM into a more comprehensive tool for analysing transport systems and their response to interventions.

References↩︎