**2. Background**

This section demonstrates how our design approach is unique by reviewing previous studies. We also review previous SPS evaluation metrics to highlight the relevance of our proposed metrics.

#### *2.1. Smart Parking Systems and Parking Simulations*

Modeling and simulation have been used for knowledge discovery applicable to parking systems, as well as for testing already implemented SPS. Some examples of the first approach are: testing a utility function that involves factors affecting parking choice [4], collaborative path-finding in a multi-agent context applied to an SPS [12], testing a parking planning algorithm [13,14], and an SPS evaluation considering several vehicle categories [15]. Examples of the second approach include: testing an SPS model to explore factors like distance to building entrances [16], testing dynamic prices assignment [5], and parking guidance evaluation [6].

Despite the fact that modeling and simulation techniques are often related to SPS design or evaluation [2,17–21], to the best of our knowledge efforts devoted to the simulator/simulation's development are not reutilized in SPS development. A simulator and its related SPS are generally built following distinct goals: The former's development commonly seeks a fast way to study the parking phenomenon, while the latter's development pays more attention to common software concerns like robustness, efficiency and load handling. During our work, we noticed an interesting opportunity to reuse the simulation software modules in a related SPS by combining and linking the simulator development with the development of the guidance/reservation algorithm and other software components for the SPS. The abundance and variety of available agent-based modeling toolkits [17,22] may facilitate such co-developments. The algorithms or other components required in the SPS may be implemented using the same programming tools in the simulator. In a general sense, doing so may require:


The team that developed the simulator described in this paper was also part of the team developing the targeted SPS. Its members had software design and team skills that enabled them to meet the previous requirements. The software components reutilized in this work are the parking reservation component and the components for accessing the related data and external services. Section 3 presents the selected design decisions that assured the sought-after component reutilization.

#### *2.2. Agent-Based Parking Models And Gis*

ABM applications to traffic and transportation, including parking-related phenomena, are significant and numerous [7,8], with several popular ABM toolkits being spatially explicit [23] or including extensions that provide support for GIS data usage [22]. Agents represent drivers in cars moving across an environment, which is usually composed of a network of road, target destinations, and parking spaces.

In research literature related to parking studies, the bridging of ABM and GIS is addressed either using particular spatial data formats or by having the simulation built within a GIS platform. Works like SUSTAPARK [24], TRANSIMS [25], MATSim [26], PARKGRID [27] and PARKAGENT [13,28,29] are good examples. SUSTAPARK and PARKGRID load the roads and parking data from GIS layers stored in files, e.g., in shapefile format. TRANSIMS and MATSim read their input data—e.g., network, destinations, and activity plans, from files that follow their own specification, though they include some GIS tools for importing, exporting, or visualizing other formats. PARKAGENT was implemented as an ArcGISc application so as to have direct access to GIS data and services.

Following the reutilization goal presented in Section 2.1, we decided to assure the GIS data and services were accessible online and decoupled from the simulator. This decision allowed reutilization of data access, as well as software components. A GIS server providing data access through web services enabled data sharing between several applications, and more specifically, between the simulator and the SPS, thus allowing interesting new considerations—such as running a simulation from the actual parking state detected by the SPS. Our proposal includes the parking spot information and the car and pedestrian route determination hosted as services in a GIS server. The ability to run a simulation from current parking state data, and to automatically use the latest environment information, which is provided by a GIS server, is a distinctive and novel trait of our methodology proposal.

#### *2.3. SPS Evaluation Metrics*

The metrics used for evaluating the benefits of using a Smart Parking System include parking search time [5,30], mean driving distance [31], wandering ratio [5], walking time [32], and travel density and average speed [33]. Measurements (most often distance or time) usually start when a car enters the simulated area [31], when it is near to its destination or makes a request for parking [5], or when it arrives to a parking lot [30]. In our model, agents using the SPS are guided as soon as they enter the walled university campus, a city surrogate. The use of total driving distance to achieve credible comparisons of SPS usage benefits is not recommended, given that drivers travel certain distances to their destination regardless of their SPS usage. The total distance is generally valuable, however, and simple to calculate; therefore, we devised a methodology to use the total driving distance in our experiments. Section 5 shows how we arrived at the methodology through a series of experiments using our simulator.

In our model, the driver's travel distance while trying to park might be affected not only by the driver's parking choice, destination, and parking availability. An agen<sup>t</sup> that does not use our SPS may occupy a parking spot already reserved for another agent, forcing the latter to issue a new spot reservation. The effects of reservation without a physical guarantee, i.e., nothing stopping a driver from grabbing someone's reserved spot, are not explored in the literature we reviewed, though reservation guarantee is a key aspect of SPS [5]. The literature does sugges<sup>t</sup> approaches to enforce the reservation, but they are either relatively expensive (physical barriers) or not fully effective [2,5,32]. Section 5 shows how we explored the reservation guarantee problem, and comments on the negative impact it may have for the SPS' usage. To the best of our knowledge, no previous study has hinted on the level of SPS utilization under which the reservation guarantee problem is the most notorious for a given environment.

#### **3. The SPS and the Parking Simulator**

The SPS was created and tested at the campus of the Universitat Jaume I (UJI) in Spain. It is a walled complex and has four vehicle entrances. Its parking spots are free and on-street, with some areas similar to those in a small town neighborhood and other larger areas similar to that near a sporting facility. The SPS has detection sensors, smart parking services, and client applications. The magnetic sensors detect the parking occupancy and deliver that information to the smart parking services through a wireless network. These services, exposed as REST web services, handle occupancy data storage and provide search, reservation, and routing functionalities to a smartphone client application. The application allows visualization of available parking spots, spot reservation, and driver guidance.

Our simulator represents drivers that move across the campus to reach their destinations and park in spots convenient to them. The simulator's design allows the usage of the simulated parking occupancy data as a fake (surrogate) input from the SPS sensors. Therefore, the simulator became a valuable tool for the SPS development team for testing the SPS before deployment of the actual occupancy detection sensors in the university campus. Also, the SPS' parking reservation component was implemented and tested as a part of the simulator. Therefore, any further refinement to it could be easily tested through simulations and later be directly used in the SPS. Figure 1 shows the layered design, after Fowler [34], of our simulator software. The Data layer obtains the necessary information for running the simulation. The Model layer represents the actual model (its implementation is aided by an ABM library) along with the implementation of some parts of the SPS. Finally, the Presentation layer has components that handle the model's output and user interaction. The layers vertically communicate using facades [34].

The GIS data and services were hosted using commercial, off-the-shelf GIS server software (Esri (Esri software company (http://www.esri.com/)) ArcGIS for Server, now ArcGIS Enterprise), which is used by many city governments and it is available to universities via the Esri educational institution license. At UJI, this server already hosted production-ready (properly prepared) GIS data and services regarding the university campus, collected and built for the Smart Campus system [35]. This server provided a common access point to geographical data for the simulation and the SPS. The relevant hosted GIS services for the simulation and the SPS were: (1) parking spots data, (2) building and campus entrance points data, and (3) car and pedestrian routing services on a previously digitized

street network. These services are consumed as REST web services. Under this uncoupled schema, any changes to parking spots, buildings, or routes are immediately available to the SPS, any related application, and the simulator.

**Figure 1.** Simulator's layered organization. SPS = smart parking systems; GIS = Geographic Information Systems; ABM = Agent-Based Modeling.

#### **4. Parking Simulator Details**

The simulator defines an agent-based model representing the parking occupancy created by drivers within the campus. Its implementation took into account the integration discussed in Section 2.

## *4.1. The Model*

The model represents a 'virtual week' period. For each day of the week, agents arrive to the environment, follow their activity plan, and leave. An agen<sup>t</sup> attempts to park as near to its destination point as possible. Destinations are particular entrance doors of buildings. In studies, such as Geng and Cassandras [5], destinations from the same building are aggregated and considered as one. In our model, given the dispositions of building entrance doors and parking spots, different doors (potentially far apart) of the same building were considered as distinct destinations. The criterion for measuring parking-to-destination proximity is walking distance as measured using actual pedestrian ways (sidewalks and crosswalks).

## 4.1.1. Agent Profiles

The agen<sup>t</sup> activity plans (agent profiles) define the typical cases of drivers. As an example, consider a student needing to be at a specific classroom at 09:00. At 08:45, she arrives by car to the campus through the campus entrance of her choosing. She then parks near the building door she considers is the best for her destination. After a while, when the class finishes, she walks to her car and drives to the sports complex, which is far from where her car was previously parked. She parks near a door of that complex. After completing her sporting activities she drives out of the campus.

Agents that belong to the same profile have the same type of destinations and similar arrival and departure times. A random, normally distributed variation is allowed around those times. The profiles were created considering the actual number of people from a community profile that commonly visits a building. Agent profiles consider the expected number of people actually driving to the

campus for each of those groups. Activity plans are important for transport simulation [36] and the agen<sup>t</sup> profiles addressed in this work resemble those from Horni et al. [26] and Dieussaert et al. [24]. The numbers of people defining each profile and those describing facilities' usage were obtained from the university administration services and community surveys, which is further explained in Section 5. We consider that agen<sup>t</sup> profiles built in this way is a plausible alternative to more common approaches (like car counting at parking spots and at campus entrances) as it requires considerably less effort and infrastructure.

## 4.1.2. Search Behavior

Some agents ('Guided') rely on the SPS for finding an available parking spot, while other agents ('Explorer') decide for themselves where to park. Studies like Geng and Cassandras [5] have also used these two behaviors, seeking to quantify the benefits from using an SPS. When an agen<sup>t</sup> is created, its type is randomly defined under the restrictions established by a model parameter that controls the proportion between the two types of agents. This model parameter can be dynamically adjusted. Driving behavior and parking search are complex processes [37–39] and several studies have applied realistic behaviors [3,13,19,27], even considering recent trends like driver-less vehicles [40] or specific contexts like a city center [41] and university campuses with specific policies and notable parking supply shortages [42]. We chose two simple parking search behaviors for our model because obtaining an approximate parking occupancy, rather than the most realistic one, was enough for our simulator goal.
