Guided

An agen<sup>t</sup> with a 'Guided' behavior requests a parking spot reservation from the SPS's reservation component, which chooses the best available spot for its destination. It then follows the optimal route to the spot and occupies it. The reserved spot will not be offered to any other agen<sup>t</sup> until the occupying agen<sup>t</sup> explicitly releases it. As the reservation process is logical, not physical, before a 'Guided' agen<sup>t</sup> arrives to its reserved parking spot, an 'Explorer' agen<sup>t</sup> might find that spot and occupy it. When the 'Guided' agen<sup>t</sup> notices that situation, it asks for a new parking spot and heads for it.

## *4.2. The Simulator*

The chosen ABM library for model formalization and implementation was MASON [44], which facilitated the process of creating an integrated simulation. We additionally used the GeoMASON extension [45], which incorporates support for vector and raster geospatial data. The final implementation followed the software design shown in Figure 1.

The *Data* layer loads the simulation's configuration (including agen<sup>t</sup> profiles) from files, reads the GIS data—which is principally campus cartography—from the GIS Server, and reads parking place status from the SPS. The GIS data for parking spots and entrances are loaded at simulation start, but the routing services are used on-demand. The parking place status information are also loaded at simulation start, thus enabling us to simulate the parking occupancy from a known starting point or from an SPS-provided parking occupancy.

Figure 2 provides an overall, simplified view of the *Model* layer design, which includes model notifications, agents' behavior, model configuration and smart parking artifacts implementation. Any component interested in receiving notifications of model changes must subscribe to the appropriate updater. Distinct agen<sup>t</sup> behaviors are achieved through the basic parking agen<sup>t</sup> specialization. The SPS's reservation component, though it is known and used by the simulator, is implemented independently from the simulation core, thus allowing for easy substitution. By implementing model controllers it is possible to set up the necessary relations, e.g., updaters, according to the target application platform.

**Figure 2.** Main classes of the Model layer and their relation.

The *Presentation* layer has components that are notified when the model changes. These components inform the SPS about those changes (Smart Parking Communication) or show them (UI Components) in applications that wrap the simulator. The Smart Parking Communication component delivers occupancy state changes. Three implementations of the simulator's UI Components have resulted in three distinct applications: (1) A desktop version that uses MASON visualization utilities (Figure 3) and shows the parking availability and the agen<sup>t</sup> moving across the campus, (2) a console version for simplified and faster runs, and (3) a web-hosted version. Having three different interfaces for different purposes highlights the flexibility of the approach used for building the simulator. A video showing a simulation run is available online (Demonstration Video: https://youtu.be/gZj21WtOmio).

**Figure 3.** One of the simulator applications running in the foreground, while in the background a web map shows the parking spots' current status as stored in the SPS. In the simulator, black squares represent parked agents. In the web map, red squares represent occupied parking spots.

#### *4.3. Parking Reservation Component*

The parking reservation component serves reservation requests in the order they are received. Several studies have proposed advanced reservation algorithms that take into account, e.g., current driver travel time, parking pricing, and reservation updates when the parking availability changes [2,21,32]. As the reservation algorithm was not among this study's main goals, the reservation component uses a simple heuristic that only takes into account the parking spots availability and the walking distance from the spots to the specified destinations. In experimental measurements, network communication lags for car and pedestrian routing requests had medians of 0.43 and 0.08 s, respectively. Car route requests are only made when a car starts moving, thus they do not add a significant burden if made on-demand. An agent's parking reservation request requires determination of the available parking spot that is the closest (according to walking distance) to an agent's destination. To avoid on-demand pedestrian routing requests associated with parking reservation requests, the parking reservation component calculates beforehand, then sorts and stores the distances from every parking spot to every destination. This approach is feasible because the number of destinations (buildings' doors) and parking spots is 225 and 3809, respectively. Therefore, the time for finding the closest available spot only depends on the total number of parking spots.

#### *4.4. Final Development Considerations*

The simulator development presented in the previous sections also requires additional minor design and development decisions (All code is shared in a public repository: https://goo.gl/GmWyt1), such as development platform or execution environment. Furthermore, although the usage of resulting simulator software artifacts is straightforward, some additional steps are required if an SPS development is initiated from those artifacts.

The choice of the development platform (and programming language) depends mainly on preferences from the development team and additional design considerations (e.g., related to the SPS design). As can be inferred from Kravari and Bassiliades [17], Crooks et al. [22], it is possible to accommodate model specification (using an ABM library) to the chosen development platform. The usage of an ABM library for model implementation implies coding driver behaviors following the library specifications. For example, using MASON (which is Java-based), driving behavior is coded in methods from a class. An agen<sup>t</sup> is created as an object from that class, and a method from it is executed by a discrete event scheduler. In the case of models considering very complex driving behaviors, the required coding effort may be significant. For those models, a benefit trade-off between re-usability and coding effort should be considered.

The development platform may also influence the way remote services are consumed. The REST architectural style is widely used and its support spans most development platforms. The communication with those services is eased if SDKs exist for the targeted GIS server. For example, the software company Esri provides several runtime SDKs for client applications to access services published by Esri ArcGIS Enterprise, as well as for map visualization and geometrical/geodesic operations. Other SDKs alternative sources could be Mapbox [46] or Geotools [47]. For models that cover large and congested areas (which simultaneously include several thousands of drivers), a large number of network requests are issued, which could potentially overload the GIS server especially if that server already supports multiple users for other purposes. In such situations, a different design (routing operations computed in the simulation) may be preferable.

For the integration of the simulator core components into an application, already mentioned in Section 4.2 for the web or desktop versions, most of the effort is devoted to creating a proper presentation/usage of simulation output and controlling the simulation execution. For example, the web version wraps the simulator core components with REST web services. A thin web client uses them to obtain the simulation state (occupancy) and to display it on a map, and to control the simulation (starting/stopping the simulation and parameters configuration).

Once the simulator is built and tested, the following elements are ready for reuse in an SPS:


The combination of the enumerated elements with an occupancy detection system (e.g., magnetic sensors and its communication components) and a user (mobile) application can produce a relatively simple, ye<sup>t</sup> functional SPS. As an example, the occupancy or availability state storage, the computation of vehicles routing indications and the maps for visualization are provided by elements in (1). Elements from (2) can be reused to create a web application that provides a gateway for occupancy state discovery and update. The update operations are used by the occupancy detection system. The discovery operations are used by the client application, which also uses elements from (1), and by a web dashboard to monitor the SPS state, which can also reuse elements from (4). The reservation component (3) is vital for the SPS and can be readily used in the SPS as it is isolated from the simulation.

#### **5. Case Study: Exploration of SPS Expected Usage**

Several experiments were performed to demonstrate the simulator's potential use and to explore likely benefits of SPS usage. The model parameters' values are presented in Table 1.


**Table 1.** Model parameters values.

Model parameters *maxWalkDist*, *criticalRatio*, and *criticalReduc* were already explained in Section 3. Parameter *visDistance* indicates the distance for which 'Explorer' agents consider their detected parking occupancy for deciding whether to park or not. Parameter *carSpeed* sets agents' movement velocity. Agent profile values are not presented here because of their large number of details. The simulator includes other relevant parameters that are not model parameters, for example, the GIS data and routing services, and whether to initialize the simulation with the current SPS occupancy state.

To define destinations, times, and amounts of distinct profiles (groups) of people coming to the campus by car, a set of root behaviors was created based on actual university data for a typical academic month. The root behaviors act as templates used to automatically create agen<sup>t</sup> profiles, which in turn are used as templates for creating agents during a simulation run. The root behaviors used in the experiments considered the main distinct groups of the university members. They defined tasks in which the first drivers arrived to the campus around 08:00 and the last ones leaved the campus around 20:00. The root behaviors included a main task, which was going to a building, and subsequent optional tasks. Optional tasks were added to agen<sup>t</sup> profiles randomly, complying with the expected facilities usage. The optional tasks were going to a sport facility, to the library, or to a distant building, if the optional task's destination was not already the main task's destination. We obtained the typical quantities of each group accessing each facility and their typical staying times, although for profile creation a group-dependent random variation was applied to staying times. Through driver surveys, we also estimated the likelihood for each group to use a car inside the campus. By creating agen<sup>t</sup> profiles automatically from root profiles, we achieved a rich set of over 300 profiles, which is important in transport simulation [36].

Each experiment consisted of 15 simulation runs with the same parameters. Each experiment was run for a specific proportion *p* between 'Explorer' and 'Guided'. It also used a profile set created using the root behaviors and considering a specific proportion *c* of people actually using their car on campus. The maximum amount ( *N*) of people expected to come to the campus on a typical day is about 15,000. Each root behavior (people profile) *b* accounts for some part *Nb* of that amount of people. For an experiment run using 0.1 as value for *c*, the number of agents created for root behavior *b* is 0.1 *Nb*, and the expected total amount of agents is (about) 1500. Parameters *p* and *c* allow exploration of situations with different levels of SPS usage and parking demand, respectively. The measured total driving distance of each agen<sup>t</sup> considered all stretches of its multi-destination journey. With *<sup>D</sup>*(*p*, *c*) denoting the set of all traveled distance measurements for a particular experiment, then:

$$D(p,c) = D\_G(p,c) \cup D\_E(p,c)\tag{1}$$

$$p \in P = \{20\%, 50\%, 80\%\}$$

$$c \in \mathbb{C} = \{0.1, 0.2, \dots, 1.0\}\_{\prime}$$

where *DG*(*p*, *c*) and *DE*(*p*, *c*) denote subsets that contain measurements only from 'Guided' agents or from 'Explorer' agents, respectively. We denote the mean values of previous sets as *<sup>D</sup>*(*p*, *<sup>c</sup>*), *DG*(*p*, *<sup>c</sup>*), and *DE*(*p*, *c*).

Figure 4 presents the case for *<sup>D</sup>*(*p*, *c*). It shows that the SPS usage should reduce the parking searching time. There is a drop in mean value for 'Guided' agents from proportions 0.1 to 0.2. This may be due to the fact that with proportion 0.1, only a few agents, or no agents at all, have as destinations buildings with a low number of people and located near campus entrances.

**Figure 4.** Variation of the mean traveled distance.

The mean traveled distance remained stable in spite of the growing number of drivers. The parking reservation component reserves parking spots that are uniformly distanced from a building target door, causing their mean distance to remain stable for 'Guided' agents. For 'Explorer' agents, we have identified two likely reasons: (1) Parking demand is spread over the day and across several building doors, and (2) when some drivers arrive to campus (most likely after midday), others have already left. Furthermore, parking demand and supply are not heterogeneous across the campus; in a similar way they differ in other scenarios [27], leading to divergences from the expected increase in the parking search time when the parking demand increases. The relation between parking search time and parking demand is not trivial [48].

Figure 5 presents another way to use the mean traveled distance for meaningful comparisons. Each data point *d*(*p*, *c*) of the series is calculated as:

$$d(p, c) = \overline{D\_E(p, c)} - \overline{D\_G(p, c)}.\tag{2}$$

**Figure 5.** Variation of the mean traveled distance, as expressed by the difference between the mean distance of 'Explorer' and 'Guided' populations.

Figure 5 indicates that the 'Explorer' agents have longer driving distances. The difference stabilizes and stays around 700 m, which may hint at the minimum expected difference in the mean traveled distance in the campus scenario. An unsuccessful parking search across the parking spaces that surround a campus' building would add a value to the accumulated search distance of an agen<sup>t</sup> that, on average, is above 600 m.

When considering all measurements from all experiments, the mean value was 1737 m and the standard deviation was 1174, approximately. The two metrics explored so far in this subsection (*DG*(*p*, *<sup>c</sup>*)*andDE*(*p*, *c*) and *d*(*p*, *c*)) are affected by the distribution of buildings (and their doors), parking spots, and campus' entrances. To avoid that issue, instead of using the mean value, we considered using percentiles values. First, two sets are defined as follows:

$$T\_E(p) = \bigcup\_{c \in \mathbb{C}} \{ D\_E(p, c), p \in P \} \tag{3}$$

$$T\_G(p) = \bigcup\_{c \in \mathbb{C}} \{ D\_G(p, c), p \in P \}.$$

Let *nE*(*<sup>i</sup>*, *p*) and *nG*(*<sup>i</sup>*, *p*) denote the *ith* percentiles of *TE*(*p*) and *TG*(*p*), respectively. The data points of Figure 6 are those percentiles values, considering three levels of usage of the SPS. The chart allows comparisons of distance categories, and it suggests that 'Explorer' agents are strongly affected by high parking demand situations, regardless of the usage level of the SPS. In addition, to compare different levels of usage of the SPS within the same chart, we defined new data points as follows:

$$d(i, p) = n\_E(i, p) - n\_G(i, p), p \in P. \tag{4}$$

Figure 7 shows the data points *d*(*<sup>i</sup>*, *p*). The metric value of each proportion *p* ∈ *P* for a percentile are very similar to each other for percentiles below 40, but it significantly differs for the percentiles at about 80. The difference for the highest percentiles is higher for 80% of SPS usage, which is also noticeable in Figure 6. The reason for the higher difference in high SPS usage situations is that 'Guided' agents 'discover' and thus take the remaining spots faster than 'Explorer' agents.

**Figure 6.** Difference in traveled distance between 'Explorer' and 'Guided' agents, as seen using percentiles and considering *p* = 20%, *p* = 50%, and *p* = 80%.

**Figure 7.** Difference in traveled distance, as expressed by the difference of same percentile values of the 'Explorer' and 'Guided' populations.

Figure 8 shows that the occurrence of the reservation guarantee problem grows as the competition for parking spaces increases. It is most notable when the 'Guided' to 'Explorer' proportion value is 50%. The guarantee problem is more notable for proportion of 75% than 25% because in the former case there are more agents whose reserved spaces are susceptible to be 'stolen'. Drivers declining to use the real SPS may be an issue for those who use it. When a driver has its reserved spot 'stolen' by another driver, the former needs to keep driving to locate an available spot. Depending on the parking demand, such additional search may take a long time. Furthermore, regardless of the amount of time devoted to the additional search, the reservation violation creates discomfort for the driver, which may lead to a decline in SPS usage. The 'reservation' term in an SPS that does not make physical reservation enforcement could be misleading for a driver, and 'suggestion' term should be used instead. When a parking spot is 'stolen' and given the occupancy detection capability of the SPS, a driver that was suggested to take that spot should be alerted and provided with an alternative spot and a new route indication to it. To avoid alternatives far away from the original suggestion, the latter could be determined taken into account the availability of other parking spots close to it, an idea that resembles heuristics applied in PGI systems [2].

**Figure 8.** The reservation guarantee problem, explored for several levels of parking demand and agen<sup>t</sup> types proportions.

## *Single Building Analysis*

To study a specific high parking demand situation, e.g., in the case of a notorious event hosted in a campus facility, we ran simulations for which agents tried to park near a randomly chosen entrance of a particular building during a 'virtual' day period. We made them arrive at the campus at similar times. The parking demand significantly exceeded the parking supply around the building, and the agents had to park around other buildings. As presented in Figure 9, in the case of the 'Explorer' agents, the worst result corresponds to the proportion of 'Guided' agents *p* = 20%, which is a result not only from competition, but also from the fact that the 'Explorer' agents that try to park near the same building's entrance follow similar routes while searching for parking, which makes them go through the least favorable paths. In the case of the 'Guided' agents, the worst results correspond to the proportion *p* = 50%, which corresponds to when they are the most affected by the reservation guarantee problem.

**Figure 9.** Traveled distance when considering only one campus building.

The correspondence between larger traveled distance and higher parking demand for the 'Explorer' agents is in line with the results presented in previous studies [27]. Likewise, the steady behavior for 'Guided' agents corresponds to already reported benefits of parking reservation systems [2]. However, the comparison between the three studied levels of SPS usage for 'Explorer' agents reveals insights different to those obtained when considering the simulations campus-wide during an entire week. The difference between the two study cases is an indication that the traveled distance does not only depend on the demand and level of usage of the SPS, but also on the scenario. The campus traveled distance analysis results from this work should be applied with caution to other distinct scenarios. The campus has a large amount of parking spots, while in a different scenario, e.g., a city center, the number of parking spots may be rather small. Depending on the scenario, the analysis might have to be performed on small extents. The reservation guarantee problem is, however, inherent to on-street parking, and it should be expected to be the most significant when the numbers of people using and refusing to use an SPS are similar.

A simple driver model and a simple parking reservation heuristic were used in this work to show that an SPS development team could be able to assume the simulation development without significant effort. Having agents with parking search behaviors more advanced than those used in this work would decrease the traveled distance numbers in the campus scenario, e.g., using learning to avoid places that are usually crowded. However, we consider that more general results, like the 'Guided' agents having lower traveled distances than the 'Explorer' agents, and the reservation problem being

the most significant when the number of the two agen<sup>t</sup> types are similar, should remain true even when a new a parking search behavior is considered.
