A Live Smart Parking Demonstrator: Architecture, Data Flows, and Deployment ^†

Abstract

Smart Parking is essential for any future smart cities due to the tremendous growth of the car fleet. Such infrastructures require a certain amount of equipment. Indeed, smart parking integrates a lot of actors, to manage the parking its equipment must be managed accordingly. Here, is proposed a distributed architecture to manage them by collecting efficiently their data. Two types of data relating to the parking must be collected: those coming from the deployed equipment in the parking and those coming from the internet due to remote users. Thus, a system of two main servers based on the multi-agent concept is proposed. This system manages the parking platform. The first server is dedicated to the parking equipment data collection (Processing Server–PS). The second server (Processing Web Server–PWS) collects the users’ online data such as reservation, and it is responsible for pricing policies, and receive post-processed data from the Processing Server. The parking equipment integrates a lot of commercial solutions, an intelligent multi-platform application based on this two server philosophy is developed and can be used for parking operation by users and parking managers. The flowcharts of the agents from the two mains servers are presented. These flowcharts are currently used in our demonstrator and still under improvements. Here, we present the architecture (hardware and software) of our smart parking demonstrator developed by our department and suitable for the experimentation of our future work related to this hot topic.

1. Introduction

Casablanca is a city that shines with its modernity. It is the most populous in the Kingdom of Morocco and enjoys a car fleet that has nothing to envy to great metropolises. However, its infrastructures (roads, parking, etc.) are not up for this density of vehicles. Thus, congestion is common and parking spaces are sorely lacking. Despite the insufficient number of parking spaces, the haphazard construction of the new parking lot will not solve the problem. It is in this context that the city aims to move towards a smart city.

Although there is no standard definition of smart cities, the concept unanimously benefits from a smart six-dimensional vision: Mobility, Environment, People, Living, Economy, and Governance. In this vision, smart mobility represents an important part. According to literature, in populated cities finding a parking spot represent a real daily challenge. Nevertheless their countries, drivers spent a great amount of time on parking operation. Indeed, in 2012, the consulting firm McKinsey & Company [1] reported that a Parisian driver would lose an average of four years throughout his life for parking spot cruising. Article [2] authors said that 30% of urban traffic congestion is due to vehicles looking for a parking space, which results in, on average for a vehicle, an additional time of 7.8 min to find a parking space. This cruising, besides, to increase traffic jams, contributes to engender more pollution said Shoup in [3]: in the district areas of Los Angeles, cars that run for parking purposes would create the equivalent of 38 trips around the world and would produce about 730 tons of CO${}_2$.

Hence, proposing efficient parking management by providing drivers real-time information on the parking occupancy while helping them to find a vacant spot as quickly as possible seems to reduce parking issues in currents and future cities. Recently, investment in parking increases and it scores at 3.5 out of 5 in European estate market investment prospects 2020 [4]. Although such parking includes a lot of aspects, the fondness remains the data fusion from their equipment. To be available remotely via a computer application or smartphones, parking information must be firstly collected locally and processed. Besides, this local collection allows updating parking indoor automatic signaling and display screens.

Our laboratory sets among its objectives to build up the first smart parking solution usable in the city of Casablanca by developing a pilot solution implemented in the university parking lot. Deployed at city scale we expect that such parking will help to mitigate congestion, to reduce pollution due to cars, and to propose to drivers real-time information about parking availability.

1.1. Paper’s Main Contributions

Our main contributions include the following:

• Improving the parking operation for drivers: The smart parking must represent for drivers a friendly and welcoming space with features that guarantee its optimal utilization. To achieve this objective, the car park must be equipped with a payment system intended for both subscribed and non-subscribed users. For subscribers, payment may be automatic through a personal badge while for non-subscribers payment is manual via dedicated terminals (electronic payment is always possible too). On the other hand, smart parking must allow a remote reservation of a parking spot via a computer application on mobile equipment. Finally, the parking will offer guidance, vehicle location, etc. to guarantee a better reception and quality of experience of the drivers.
• Improving the parking security: To guarantee the security of parked vehicles and drivers, the car park must be equipped with an effective and complete security system which concerns two aspects: Security against external intrusions and internal security. This system must ensure events’ traceability especially when problems occur. These securities systems are ensured by a set of cameras and an alarm system.
• Improving the environment respect: Environment respect is an important constraint in our project’s design. For this purpose, the car park must manage efficiently its energy consumption and production (from solar energy) which will ensure its energy autonomy. On the other hand, the radio equipment used in the parking must not disturb unnecessarily the environment by electromagnetic interference. Finally, the car park must integrate green spaces with efficient management of the watering system which ensures minimum consumption of water resources.
• Proposal of a global architecture (equipment and software) of our smart parking demonstrator. This proposal includes all the equipment which may be involved in a smart parking deployment. Besides, the flowcharts of some keys equipment and features (services) are presented.
• The agent-based software architecture of our smart parking is also introduced using the concept of agents. This architecture is based on a structure with two processing servers. This structure allows modular development depending on the agents involved and allows a Processing Web Server (PWS) development independently of the equipment present in the car park, in particular thanks to the communication agent.
• Decoding the deployed sensors in the smart parking is the foundation of such infrastructure. Thus, we have proposed a local decoding flowchart saving money for parking operators. Indeed, without this local parsing, the parking operators must subscribe to a cloud platform for such decoding.

1.2. Paper Organization

The remainder of this paper is as follows: the next section presents generalities on smart parking and agent-based approach. Our demonstrator’s equipment architecture and the parking management philosophy are exposed in Section 3. The demonstrator software architecture is exposed in Section 4 followed by the keys flowcharts presented in Section 5. A discussion on our parking approach is introduced in Section 6. Last, the conclusion and perspectives close the paper.

2. Related Work

2.1. Parking in General

The parking lot is a central node in urban transportation. Indeed, vehicles pass there, on average, more time than on the roads. Smart parking can be defined as a classic one with additional smart functionalities (reservation, payment, guidance, monitoring, and forecasting of availability …). In [5,6,7], an exhaustive state-of-art on smart parking is presented. Two main groups of parking can be distinguished: garage parking and roadside parking lots. These latter ones are very extensive and correspond to a more or less contiguous arrangement of parking spaces along the roads, they are generally easy to access. The birth of the current concept of parking is strictly linked to one of the automobiles. The first mention of parking in the patent system appears in 1928, it was filed by Roger W. Babson for an ingenious park meter that gets its energy by using the power of the parked vehicle (US1731839A (https://patents.google.com/patent/US1731839A (accessed on 21 January 2021))). This parking meter remains an idea and was never created. The first operational park meter, commercially called Park-O-Meter No.1 but initially titled Coin controlled parking meter, was patented (US2118318A (https://patents.google.com/patent/US2118318A (accessed on 21 January 2021))) for Carl Magee in 1935. The equipment relating to the roadsides parking are generally the parking meters and sometimes detectors to know the spaces’ status (vacant/occupy). Since all the vehicles can’t be parked in these places, garage parking has been developed to compensate. Garage parking can be covered or not (in this case, they are called outdoor parking), but are generally protected and access-controlled. These car parks integrate more equipment. Our car park falls into this category.

A common challenge that concerns all parking types, especially garage parking, is their ability to inform about their availability, to guide the drivers to vacant spots, to control entrance and exit, etc. To deal with these challenges, multiple types of equipment were developed by different manufacturers. This equipment ranges from barriers (entrance/exit), signaling display, ticket terminal, IoT sensors for spot status determination, etc.

In [8,9] only parking IoT sensor network was addressed by using an elementary platform. Article [9] proposes to drivers vacant parking spots at the cheapest cost. Few studies integrating parking management algorithms are available in the literature. There are some which deal with parking wireless sensor networks, others addressed signaling but when handling the hole parking system only some commercial solutions exist with pros and cons. The main limitation of these commercials parking is the fact that they seem to use exclusively only their products and difficult or impossible to extend. In our parking, equipment comes from different manufacturers and are successfully managed by our approach.

In [7], all equipment that can be used for IoT smart parking are included in the physical layer. This layer also touches on urban planning aspects of (parking slots arrangements, parking type, parking location, etc.), detection systems for vehicles and users, sensors for parking spot status determination (available/occupied).

Regarding parking type, Ref. [10] presents fenced and non-fenced car parks, while [11,12] deal with roadside car parks. Besides, Refs. [13,14] speak about garage parking. So, we distinguish three main types of car parks: indoor (garage or fenced) car parks, outdoor (access-controlled or not) parks, and on-street (roadside) car parks. We introduce parking types because it has a direct impact on the parking equipment choices. Our demonstrator is outdoor access-controlled parking.

As for hardware equipment involved in the parking operation, we have In Parking equipment and those installed at the user level.

Among in Parking equipment, there are deployed in the parking. It concerns equipment dedicated to the control and monitoring of access to the car park, those dedicated to detection (vehicles, users, and places’ state), and those dedicated to payment. In [15], authors present some security risks of parking meters reported by the Australian media. These meters are used on all parking types, even they are more critical on roadside parking since they are used to collect parking fees. Knowing their securities risks help to better secure these meters. Several commercial models have been developed. Manufacturers such as Nice (www.niceforyou.com/en/solutions (accessed on 21 January 2021)), Came (www.came.com/en/public/solutions/parking-systems (accessed on 21 January 2021)) and Axipark (www.colas.com/smart-mobility/axipark-centre-commercial.html (accessed on 21 January 2021)) are offering control access and payment solutions for car parks.

Sometimes, equipment (RFID tags) are provided to users or installed on the vehicle to provide additional services (e-payment, GPS guidance via the vehicle’s embedded system, user identification, etc.) We exploit features of users’ equipment either as a means of detection or as a tool for location and guidance [16]. Articles [6,17] propose to exploit the fact that outdoor car parks are exposed to the sun by using solar panels to power chargers for electric vehicles.

As reminded in [18] a smart parking has generally three components: physical, network and applicative [18]. For the physical part, literature mainly focuses on sensors deployed. In [18], the authors present a review of smart parking from technological aspects. We can notice that a wide range of types of sensors is deployed for parking. In fact, this aspect is crucial for any smart parking since it’s responsible for spot status (vacant or occupied) determination, namely to know the car park’s state and its evolution in real-time (Sensing). The main techniques are crowdsourcing, image processing, and IoT sensors network.

Crowdsourcing consists to collect parking information from users and process them to know the car park occupancy state. This technique presents an exceptional advantage, in some cases, to avoid sensors’ deployment at least inside parking. The crowdsourcing concept is simple: when the user occupies or releases or notices a place, he reports its status to the parking management platform via an application. Then, it requires “trust” in users and a sincere collaboration from them, hence the notion of smart people evoked in the smart city vision. In [19], the user has to scan, with his phone through a dedicated app, a QR code located in the parking space to indicate its status. Authors of the article [20] propose to use sensors integrated into drivers’ smartphones which in addition to determine parking spot status can even help to locate a user in multi-level parking. Article [21] outlines extensively the uses, benefits, and limitations of crowdsourcing in transportation and smart-city solutions in general. Indoor car parks (especially underground ones) introduce new problems relating to the transmission of information that smartphones must transmit to the management server. Thus, these works [13,22] address crowdsourcing for internal car parks. Ref. [22] has the advantage of informing users in a specific way and offering them optimal paths. This study uses “cellular automata” for transmissions between smartphones and servers. In crowdsourcing, users (via its equipment) play the role of sensors. Thus, crowdsourcing offers the possibility of making smart car parks at a very low cost. However, the reliability/accuracy of such solutions is limited so they are often associated with other techniques such as image processing.

Image processing is also used to determine parking spots’ status. It involves equipping the car park with a set of cameras to ensure fully parking coverage. Then, we proceed to the processing of images (computer vision) from these cameras. As the study [2] specifies, this technique requires the use of wire and is therefore intrusive. Some articles offer new algorithms specifically dedicated to cameras. By implementing these algorithms, cameras become the processing unit and will no longer send a video stream to the servers but only a few bits (smart cameras). Thus, Ref. [23] proposes a decentralized and efficient solution based on convolutional neural networks (CNN) for the visual detection of parking occupancy. Even in this case, those sensors must be externally wire powered and are very energy consuming! Some companies, like Dahua, and Tattile offer smart parking cameras with embedded processing. With an approach claiming 99% of accuracy, the study [12] proposes to use the existing public video surveillance network to propose in real-time the state of roadsides parking. This technique can allow realizing smart parking at high or middle cost (when cameras are already deployed). However, the main problems related to image processing techniques are multiple: the important amount of data to process, requiring the use of a wired network (at least for power supply) which are intrusive and not very scalable [2]. On the other hand, the processing algorithms will be more complex and subject to false-positives and false-negatives results according to the conditions of illumination, rain, etc.

In previous solutions, parking sensing is vision-sensing or “sensorless” (crowdsourcing). Other more practical types of sensors are used with regard to articles [2,24,25,26,27], etc. which use an RFID based sensors network. Article [28] compares the IR (Infrared) and LDR (Light Dependable Resistor) sensor and concludes that the IR sensor outperforms the LDR sensor in terms of accuracy to detect vacancies and vehicle detection under different environmental conditions. Authors of the article [26] have combined the IR to RFID for their smart parking solution. While using the IR as a slot detection network, RFID is used to detect vehicles entering or exiting the car park. The magnetic sensors are the best among the most used sensors technologies in IoT smart parking according to their cost and accuracy [7]. Article [2] proposes a battery-assisted Passive RFID sensor for better detection and energy autonomy thanks to the panels inserted into the sensors. As vehicles are ferromagnetic, some articles [13,29] have exploited the magnetic principle to detect them with multiple configurations. These deployment configurations are intended to minimize the cost of sensors in the realization of an IoT smart parking and can be utilized regardless of sensor type. Three main configurations are to be noted and they are described in article [29]:

• Survey/counting in/Out: In this case, sensors generally inductive loops or magnetic sensors or IR are placed at the entry and exit points of the car park, so we can know with more or less precision the level of occupancy of the car park. However, it is difficult to know exactly the occupied places which can lead to spinning in large scale parking such as airports or supermarkets!
• Zoning: In this scenario, in addition to ensuring the monitoring and counting in/out, the parking area is divided into several areas (zones) and vehicle entry/exit is monitored in these zones. The smaller the areas, the better internal guidance is possible and the cost is still lower compared to the last configuration.
• Full monitoring: In this configuration, each parking space is equipped with a sensor allowing to know exactly, in “real-time”, the occupancy status of the car park. This last configuration is relatively expensive compared to the two other solutions, but it is the most recommended for large scale car parks because of its efficiency and the lot of possibilities it offers. Our demonstrator adopts this configuration.

Regarding the network part, it concerns communication protocols used to transport parking data. Since these data are needed both by drivers (parking users) and the parking processing servers, it’s common to distinguish between two types of network. Each of these types may use different communication protocols mainly due to the type of data and its amount. So, in [18] article talks about user network and sensor network. In the beginning, in old fashion parking only wired protocols were used for the two sides. Currently, with IoT advancements, for sensors network mainly wireless protocols (e.g., LoRaWAN, ZigBee, LPWAN …) are used for sensors network while large data rate protocols (e.g., Wi-Fi, wired, 3G, and above) are needed for users side network and in the sensors data transmissions to parking processing servers. As we can notice in article [18], for parking data management (applicative aspect), there isn’t a complete solution presented in literature since studies mainly focus on smart parking features (as reservation, guidance, …) and not how to handle the all set.

2.2. Agent-Based Approach for Parking

When we talk about smart parking, we are not referring to simple parking spaces, but rather an entire ecosystem that aims to improve drivers’ quality of experience. Indeed, smart parking is a group of equipment collecting information making it possible to present the parking offer in real-time as well as other services to users to minimize search time, limit traffic jams, etc. Due to the high numbers of actors involved in a parking operation, to conceive its management software, the use of agent notion is adequate. From a software point of view, parking can be considered as a decision-based environment depending on the cases encountered with heterogeneous data. And as we wish to reduce human intervention for its operation, we have adopted the notion of agent and more precisely the notion of multi-agent systems (MAS) which is part of the artificial intelligence (AI) field. Indeed, the use of the notion of agents will, moreover, allow us to have possibilities to overcome the experimental limits by imitating human behaviors towards internal and external factors to predict the different scenarios that can occur in the parking.

According to Woorldridge, an agent is an autonomous and proactive entity that acts in an environment and can interact with other agents in a MAS and the environment to meet its objectives [30]. In [31], Shoham defines the agent as an entity that functions continuously and autonomously in an environment where other processes take place and other agents may exist.

Each agent is endowed with several attributes such as belief, desire, intentions, etc. allowing them to perform actions on their environment to achieve their goals. These attributes can be modified or improved thanks to experiences. The BDI (Beliefs, Desires, and intentions) architecture depicted in Figure 1 is the most used to modeling an agent.

Building on these strengths and skills, we have conceived different agents to form a communicative and cooperative system. Indeed, any entity communicating with its entourage will have coordination and cooperation issues, this entity can be either human, animal, or even computers, the latter even in a multi-computer environment benefit from very limited and strict communication and/or cooperation. So if we cannot effectively establish coordination and cooperation between computers, we can hardly speak of negotiation. To increase the power of the systems, a branch of artificial intelligence has emerged, distributed AI, to provide the system with sophisticated interactions so that they can communicate, cooperate and negotiate flexibly and efficiently in all situations [32].

In reality, a single agent cannot reproduce human behavior because it is more complex and unpredictable, hence it results in the need to use several agents interacting with each other in the same system. According to Chaib-Draa et al. [33], a multi-agent system is a distributed system composed of a set of agents interacting, most often, in modes of cooperation, competition, or coexistence.

Guessoum [34] in his turn, defines a multi-agent system as a set of entities (physical or virtual) called agents, sharing a common environment (physical or virtual), which they can perceive and act upon. Perceptions allow agents to acquire information on the evolution of their environment, and their actions allow them, among other things, to modify this environment.

In the article [35], the authors proposed a multi-agent model adapted to parking management within a city. This is designed to help drivers to find a parking spot that meets a group of criteria, predefined in the requests, by offering a better parking service to the public. The multi-agent model developed is integrated into the SensCity platform process, dedicated to the development and operation of the SensCity platform and the deployment of Machine-to-Machine (M2M) systems. The city is divided into several parking areas that are equipped with sensors, which are responsible for transferring data to and from the parking spaces.

A better parking management profit to parking operators (optimize their gain) and citizens by reducing cars’ ecological footprint.

The agent representation is used in [36], but it remains partially addressed in the literature.

Table 1. Parking agents presented in some literature articles compared to our paper.

	Parking Agents
Refs	Parking Equipments Managment Agents				Parking Smart Features Agents
	Entry/Exit	WSN	Signaling	Barrier	Booking	Pricing	Guidance	Availability	Decision
Our Paper	✓	✓	✓	✓	✓	✓	✓	✓	✓
[9]	✗	✓	✗	✗	✓	✓	✓	✓	✓
[37]	✗	✓	✗	✗	✓	✓	✓	✓	✓
[38]	✗	✓	✗	✗	✗	✓	✗	✗	✗
[39]	✗	✗	✗	✗	✗	✓	✓	✗	✓
[40]	✗	✗	✗	✗	✗	✗	✓	✓	✓
[41]	✗	✗	✗	✗	✓	✓	✓	✓	✓
[42]	✗	✗	✗	✗	✗	✗	✗	✓	✗
[43]	✗	✗	✗	✗	✗	✓	✓	✗	✓
[44]	✗	✓	✗	✗	✓	✗	✓	✗	✓
[45]	✗	✓	✗	✗	✓	✓	✓	✓	✓
[46]	✗	✓	✗	✗	✓	✗	✓	✗	✗

represents some agents presented in literature studies compared to our work.

“Smart parking systems are not easy to build due to their dynamic and sometimes chaotic environments” [47]. So this article’s authors use the MAS concept for parking but their architecture includes only drivers and parking sensors agents. Using a direct negotiation protocol between parking spots and drivers, they arrived to reduce the time spent by drivers in parking operation. Due to the use of only two agents, the complexity is reduced.

The MAS concept is combined with the cyber-physical system concept for parking architecture modeling in [38]. In this paper too, only two agents represent the whole parking: driver and spot agents. When the drivers’ agents have as objectives to get a parking spot at the cheapest cost the spot agents try to maximize parking operators gain.

By using only two agents, these articles hide a little bit the multiplicity of actors intervening in parking operation and despite this, the interactions can still be challenging.

In this paper [39], an explicit spatially agent-based approach is used to optimize parking for drivers at a city scale (Tel Aviv). They integrate three parking types: on-street, private, and off-street parking places. For this large-scale implementation, the agent-based approach allows them to simulate and analyze each driver’s behavior facing parking and optimize search time and walking distance.

MAS concept is used in [40] to propose to drivers an assistant agent for the search of parking spots in an urban area. They use three agents: communication, itinerary, and decision. The communication agent broadcasts parking data availability to drivers when the itinerary agent estimates the bests parking routes and duration at each specific parking in the city, finally, the decision agent proposes parking choices. To avoid or reduce issues like multiple drivers chasing the same spot, a radius is introduced to limit the broadcast range.

Here [41], authors propose an agent-based model for smart parking in Mauritius. Multiple drivers-driven agents are introduced which allow them to consider drivers’ profile (destination, past parking behavior …) when allocating a parking spot. Parking operators agents seem ignored in the study.

Although the MAS concept is not explicitly used in [42] a deep learning concept (long short term memory network) is used to predict parking spot availability presenting some similarities with the MAS concept.

Autonomous vehicles (AVs) will reshape parking operations and parking constraints since they can drive users to their destination and then proceed to a parking search. An interesting use is done of MAS concept adapted to AVs parking in [43]. The considered agents are only AVs and parking internal management is ignored.

Authors in [44,45] optimize parking reservation. Ref. [44] only considering each vehicle as the agents to constitute their multi-agent system. Each agent optimizes its parking search time, parking fee, walking distance, travel time … In [45] more actors are introduced in their MAS but just to handle reservation and parking equipment agents are missing.

In [46], authors define smart parking as is an intelligent system that manages efficiently the interface between the driver and the parking spot, so only two main agents are defined (spots agent and drivers agent).

In [37], a point to point transportation management by integrating explicitly parking step for drivers is proposed for Tunis city. To do so, the authors use MAS to model their network but only some drivers’ side agents are developed.

SimMobility an agent-based urban mobility simulator useful for transportation from a multi-modal viewpoint is used to simulate parking use impact for heavy vehicles in [48]. This simulator represents vehicles and parking by agents. Neither parking internal management, nor pricing has been estimated in the simulation. So far, we can say some agent-based approaches for parking exist but they mainly integrate parking features and parking equipment agents are completely ignored in the vast majority of articles.

This work presents an agent-based architecture for our live demonstrator integrating both agents for parking equipment and some smart parking features agents.

3. Demonstrator General Architecture and Management Philosophy

3.1. Smart Parking Equipment Architecture

Our smart parking demonstrator (Figure 2) was introduced in a previous work [6]. Here, its architecture is reminded and deepened in (Figure 3). This architecture includes all equipment involved in our parking realization and can be divided into four modules interconnected through a local area network (LAN). These four modules are presented as follows:

• Parking entrance/exit system: This module includes identification equipment (radio frequency identification (RFID), license plate recognition (LPR) and ticket terminals), access barriers, parking wireless sensors network (WSN), displays for signaling, and indoor guidance. Our demonstrator is a garage parking and its accesses are controlled by physical barriers. The parking web automate (PWA) module controls these barriers and also serves to detect the vehicles’ presence at the parking entrance and exit. It’s equivalent to a programmable logic controller with an embedded web server. The PWA has some digital inputs (DI) and digital outputs (DO). It will act as an actuator. The DIs are used to connect cameras DO, barrier photocell protection relays, etc. The DOs are useful to command Barriers’ opening. To monitor the parking occupancy a set of IoT sensors form the parking WSN. For identification, it worth noting that it is possible to identify either drivers or vehicles. Vehicles identification is done through plate numbers and RFID tags stuck to the car windshield. Subscribed drivers can be identified through a personal card managed by the terminal ticket board. For a visitor driver, he can get access to the parking only through the ticket terminal by withdrawing a ticket. RFID only allows subscribed users identification. The LPR can identify both (visitors and subscribers). Indeed, the license plate is one of the identifiers available on all vehicles. To retrieve these identifiers, specific cameras equipped with optical character recognition technology are used. The car park may have two: one at its entrance and another at its exit. The data are available at the equipment level and are collected and processed by PS, then transmitted to PWS.
• Internet users management interface system: Drivers can follow the parking status remotely via a web page or through a dedicated application on their smartphones. Parking subscribed users will also have payment, reservation, and guidance features, etc. This part ensures the development of these interfaces. Here, the PWS collects and processes users’ data to decide and indicate its access status to PS.
• Parking Security System: To guarantee the security of goods and people, the car park is equipped with an effective and complete security system which includes two aspects: security against external intrusions (protection of access walls by photocells) and internal security. This system must ensure the traceability of incidents. The central alarm system provides security against intrusions and the video surveillance system mainly monitors internal events.
• Power supply system: Environment respect is an important constraint in the design of our demonstrator parking. So, the car park must be energy-autonomous by ensuring efficient management of its energy consumption. Therefore, the car park has its own green electrical grid network and offers recharge to electric vehicles. Besides, the equipment present in the demonstrator will avoid as much as possible electromagnetic-environment interference.

Each of these modules is studied by one or more teams in our laboratory. In this paper, the main focus concerns the parking entry/exit management system and the services available for drivers.

3.2. Smart Parking Management Philosophy

Security and easy access are mandatory for the our demonstrator. For this purpose, we have designed optimal operating scenarios. At a vehicle’s arrival at the parking entrance, it is handled according to the the flowchart in Figure 4. The driver can read the general display screen to find out if there are available places (This can be done remotely too). Indeed, there is not a vacant spot, it is unnecessary to try to get access to the parking lot! In case of availability, two cases have to be considered: the user is subscribed or not (visitor). For a subscribed user, either his car will be equipped with an RFID tag, or the driver will have a personal parking card. Issued identification activates the opening of the barrier by triggering the PWA desired digital output. At the same time, the license plate recognition (LPR) and panoramic cameras collect information related to the car and the driver. When the user is not a subscriber, he must first withdraw a ticket from the ticket terminal, at the same time the LPR and panoramic cameras collect information related to the car and the driver, once the ticket is issued the barrier opens. When the user gets in the parking, he is assisted by the combination of the ground marking and the signaling system to guide him in a row with vacant spots. Once the car parks at a spot, the concerned sensor reports its status to the gateway, and the concerned display screens are updated. For some particular drivers (persons with reduced mobility, electric car owners), personalized guidance is proposed to drive them to the appropriate spots (reserved for persons with reduced mobility or places equipped with charging stations). For some reasons (non-payment, non-respect of assigned spots, repeated reservation violation, etc.) a subscribed user can be banned (blacklisted) to access the parking. Parking security is ensured by cameras that closely observe all the events taking place inside, and to prevent intrusions, a couple of infrared transmitters/receivers equip each of the vulnerable segments accessible from the outside. When the user starts their exit, for a subscriber the exit barrier is raised after reading the vehicle’s tag or driver’s card. For a non-subscribed user, the barrier opens after the presentation, at the exit terminal, of the issued ticket at the entrance to ensure parking fee payment. Thanks to the RFID antennas or the ticket terminals at entrance and exit, the parking duration can be computed and billed accordingly. The exit scenario workflow is exposed in Figure 5.

Both at the entrance and the exit in case of problems, an intercom is available to request assistance from the security guard or by app phone if required.

4. Parking Software Management Architecture

To implement the above scenarios, the parking equipment must interact with each other accordingly. In Figure 6, the software architecture of the demonstrator’s equipment data collection is presented. While the article [36] was focused on collecting data from user interfaces, this paper focuses on collecting data from parking lot equipment and uses a multi-agent system representation.

On the processing server (PS) side, around six agents are developed as follow:

• Identification Agent: This agent is responsible to identify users and vehicles entering and exiting the car park. For our smart parking, it includes three sub-agents (RFID, LPR, and Tickets terminal) as follow:
  • RFID Agent: This agent will communicate with RFID equipment, and forward these data to the data collector agent. At each arrival, this agent wakes up and checks if any RFID tag is in range.
  • LPR Agent: When a vehicle is detected, this agent will try to retrieve its plate number. When a plate is present, it’s read and transmitted to the data collector agent.
  • Tickets terminal Agent: For a visitor user, without RFID tag on the vehicle and personal card, to allow access to (or exit from) the parking, the driver must withdraw a ticket which will be presented at the exit for payment purpose. When the driver has a personal card, it can be read by this terminal. This agent reports ticket and personal card data to the data collector agent.
• WSN Agent: This agent is the fondness of smart parking. It monitors each parking spot and reports its status (vacant/occupy) to the collector agent. It manages the set of sensors and their gateway.
• Parking display screens Agent: In the parking, the interaction messages with all drivers (subscribed and visitors) through screens are displayed according to this agent. It is responsible to update screens messages according to availability (global at the entrance, by parking row once inside...) Thus, this agent ensures global indoor guidance since it can’t specify exactly the vacant spots, only availability by row is displayed.
• Parking Watchdog Agent: Ideally, everything is done without errors. This agent enables human intervention when suspicious or unexpected events occur. When a user tries to quit without payment (it’ll be blocked at the exit, which may induce a queue), or when there is any inconsistency between the number of entry/exit and occupied places... It monitors permanently the parking agents to report equipment state (working well or not).
• Barriers Agent: Our parking accesses are always restricted through physical barriers. This agent manages its operations. When it receives an opening request, this agent executes it. It executes a closing process only if it is ensured to not cause damage to cars or drivers.
• Data Collector Agent: All the previous agents’ data are collected and stored in the database ($DB1$) after being processed. This agent is responsible for this storage and processing. It also manages the interaction with the communication agent.

PS and PWS must exchange their data accordingly. Thus, a transverse agent (communication agent) is deployed to allow communication between these two servers.

• Communication agent: The PWS knows users’ status (subscribed, visitors, payment, account balance, authorized …) while the parking PS collects identification information and parking availability information. The decision agent must be aware of this information. e.g., during reservation, the booking agent must ensure that the driver will find a spot at his desired slot time. The communication agent allows the required data exchange for parking operation. In our case, three sub-communication agents are considered: one for entrance, one for the exit, and one to send parking spot status to the PWS. These agents use socket communication.

There are around seven agents on the PWS. Data from these agents are due to remote users and are collected and processed on PWS. Here, some definitions:

• Preference agent: This agent is responsible to update the user’s preferences (profile). It determines customer preferences based on their usage history. Hence, it defines users’ profiles and allows parking to avoid overbooking, to detect users who may exceed their parking time, detect earlier/late arrivals or departures behavior, etc.
• Booking agent: Reservation is an important feature for smart parking. The booking or reservation agent offers to subscribed users the possibility to book a parking spot. The success of a reservation is the guarantee of finding a place during the reserved slot time.
• Billing agent: Whenever a subscribed user benefits from parking service, he must settle the payment. This agent allows to debit the user account for parking costs or credits it when the user operates a recharge. This agent also manages the parking pricing policy. It improves the parking’s profitability by optimizing the reservations.
• Guidance agent: For subscribed users, they can be assisted to the parking and/or to a vacant spot through their phone application. This guidance is handled by this agent. Two types of guidance can be proposed: external and internal. For external guidance, drivers are guided to the most optimal parking lot according to its preferences while internal guidance intervenes once the driver is in the car park and guides him to the most suitable parking spot. As we have proved in a previous work [49], internal guidance can contribute to improving parking sensors’ lifetime.
• Availability agent: For all remote users, this agent displays parking availability information. This information can be accessed via a web page or phone application without any subscription. This agent combines information from the WSN agent and booking agent to present accurate information to drivers.
• Decision Agent: It’s responsible to grant the parking access or exit to vehicles. According to the identification data, the availability, the reservation, the payment status, etc. this agent sets a flag which will be considered by the barriers agent.
• User Management Agent: This agent collects and manages all data from users via applications. They are stored in the database ($DB2$) after being processed.

So far, we have presented our demonstrator equipment and software architecture. In the following, we propose to present the flowcharts of keys equipment and features of our live platform.

5. Flowcharts

To guarantee proper operation, and to avoid the malfunctioning of all the services at the parking level, we have chosen to divide its architecture Figure 7 into two parts: Physical and Application part each one having its sub-parts. This architecture will allow the system to be dynamic, flexible, robust, and adaptable to any user request. Each part includes its agents, and there may be common agents between each sub-layer.

Here, we will look at the flowcharts of some keys equipment and services to demonstrate how cooperation between agents takes place.

5.1. Flowcharts at Processing Server Level

5.1.1. RFID Flowcharts

To grant parking access, vehicles must be identified and parking availability ensured. For identification, it is done in our parking through RFID, LPR cameras, and terminal ticket. RFID Entrance and exit application are based on the flowchart in (Figure 8 and Figure 9) The parking RFID system includes a controller with an internal antenna and is able to manage three other external antennas. Only one of these external antennae is used for the parking exit. We access the RFID equipment data by its controller through socket communication. Although the RFID system is externally-powered, to avoid unnecessary power consumption and radio interference we choose to turn off antennas (internals and externals) when no vehicle is at the entrance or exit. The concerned antenna will be turned on when a vehicle is detected at the controlled zone (entrance or exit). This detection could be done through a sensor, but since we want to monitor drivers at entrance and exit we adopt to use cameras’ digital output (DO). These DO are linked to one of the PWA digital input (DI) and will be triggered when a vehicle is detected in the camera field. The tag verification (Is tag recognize) is done by the entrance/exit management server application and a flag is settled accordingly to the tag status. The vehicle entered/exited can be known by the barriers embedded photocell relays connected to one of the PWA DI.

5.1.2. Tickets Terminal Flowcharts

When the user is not subscribed or does not have his usual car, to grant an entry/exit access, his vehicle must be identified somehow. The terminal ticket is the responsible equipment for that. In this case and when there is availability, a ticket is withdrawn at the entrance and at the exit, the same ticket is swallowed and a parking fee receipt is withdrawn. Tickets terminal flowcharts are dressed in (Figure 10 and Figure 11). Only the entrance flowchart is presented because the exit flowchart is the same. The only difference is in the payment verification. This is done by the terminal itself by setting a flag in its database which is accordingly analyzed. A new event in terminals can be detected by monitoring their database size. When this size increases, we retrieve the last entries and process them. As for RFIDs, the vehicle entered/exited can be known by the barriers embedded photocell relays connected to PWA DI. To avoid the infinite loop cases which may occur when a car decides to give up entrance or exit, after barrier opening, entry/exit, the vehicle entered/exited condition will be combined with a delay of around 10 s.

5.1.3. Parking Web Automate Flowcharts

This is the controller system depicted in (Figure 3). It must be manageable according to its inputs status and other parking events (RFID presence, tickets issued, etc.)

Figure 12 can read PWA inputs and command its outputs. But these inputs statuses are coded and must be decoded Figure 13 for entrance and Figure 14 for exit) to allow PWA to react consequently. So, when the inputs are read they are stored in a file that is in parallel analyzed by the bellow flowchart to decodes PWA data and sets corresponding flags.

5.1.4. Parking IoT Sensors Network Flowchart

To know exactly the status (vacant or occupied) of each parking spot, a network of IoT sensors is deployed in the demonstrator. These sensors use magnetic technology as it offers the best detection outcomes. Regarding communication (transmission and reception), our demonstrator’s sensors use the LoRaWAN protocol. It’s worth remembering that Sigfox protocol is also available but it doesn’t offer the same flexibility since private networks can’t be deployed. These sensors are from the manufacturer Libelium (https://www.libelium.com/products/smart-parking/ (accessed on 21 January 2021)). Since Sigfox is a proprietary network that does not allow the deployment of a private network, only the LoRaWAN communication protocol has been enabled in our platform. Thus, to collect information from sensors we use a LoRaWAN gateway from manufacturer Multitech (https://www.multitech.com/brands/multiconnect-conduit-ip67 (accessed on 21 January 2021)). This gateway has an estimated coverage of 15 km in line of sight condition. Each sensor wakes up at regular frequencies to determine its spot’s status. To improve the sensor’s autonomy, transmissions are made only when the status has changed. Normally, the base station is supposed to transmit its data to a cloud platform (to which the parking operator is supposed to be subscribed). Then, through an API the decoded information can be recovered. In our case, a local parser has been developed. In this case, instead of sending our base station information to a cloud platform for parsing, the parsing is performed locally by the WSN agent. It monitors the gateway, which reports to it each communication. Our parser allowed us to represent the state of the parking lot in Figure 15.

The local parser simplified flowchart is presented in (Figure 16). It considers the parking sensors network which counts 51 places each equipped by a wireless sensor [6]. Each sensor has a unique identifier. The base station acts as a gateway to collect this sensor network data. These data are decoded and signaling system information are updated accordingly. At each new event in the sensors network (arrival, departure, information frames, etc.) the corresponding sensor sends a frame to the gateway, this frame is processed and parking signaling screens and log files are updated accordingly. Parking status can be viewed in PS as in (Figure 15). This status reflects the parking map. Besides, this decoded data are transmitted to PWS, so the parking status is also available on users’ side equipment (computer, phone, etc.)

5.2. Flowcharts at Parking Web Server Level: Some Services

Here, we mainly present the reservation service. The guidance service flowchart is introduced but was exposed deeply in [49]. The rest of the services and interfaces will be detailed in future works.

5.3. Reservation Flowchart

Reservation is one of the most important and interesting services which can be offered efficiently by smart parking. Indeed, many parking guidance systems have been deployed, but these systems have limitations such as blindly searching for parking spaces, inefficient information sharing, or several cars looking for the same space. To reduce the traffic caused by searching for parking spaces, the reservation option has been suggested in which drivers make their reservations via the system. If the reservation is successful, then the driver can park in the reserved parking lot without having to search for it. Reservation is a service that brings together the different sub-layers of the systems, either hardware or application. At the application layer a so-called “reservation agent” manages the different reservations. Its flowchart is dressed in Figure 17. This agent collects information about the reservation via a web interface by entering the date and time of entry and exit and the vehicle or driver’s identity (license plate, RFID tag, personal parking card). After upon, the agent has to check the availability and the history of the car park during the chosen date to confirm/refuse the reservation. If the chosen period is occupied, in this case, the reservation agent has to propose an available time interval close to the chosen one, if the driver validates it then the reservation is confirmed. After confirmation, the booking data is then communicated to the booking agent. This one communicates with the preference agent to have the best seat to be reserved for this user (electric car, a person with reduced mobility, etc. …). Two types of reservation are offered to the drivers:

• Closed reservation: The driver indicates the time of arrival and departure and makes the payment. In this case, it is sufficient to arrive within the indicated interval for the driver to be able to access the car park.
• Open reservation: The driver only indicates the arrival time, in this case, the system will reserve the place for him only 15 min after the indicated time, if he does not show up, his place will be lost.

5.4. Guidance Flowchart

Regarding the guidance, two types must be distinguished Figure 18: internal and external. For external, it consists to guide drivers to parking slot through an optimal path according to their criteria. Once in the parking, internal guidance can be used to guide the driver to a suitable vacant spot. In this case, drivers are invited to read signaling screens and use the phone app (if subscribed) to reach a suitable spot affected to them.

6. Discussion

Here, the architecture data flow and flowcharts for our live smart parking demonstrator were presented. These architecture and flowcharts are currently deployed in our demonstrator, and still under improvement. This framework can be extended easily without changing the operation for the existent agents and if the equipment is not used in the parking, its agent can just be ignored.

We have used modular development which results in a multitude of programs, and since these are sometimes interdependent, a set of files promotes communication between them. As these files can be accessed outside the programs, it can constitute a security issue. This will be easily resolved through multi-threading programming in future versions. In this case, the exchanges will be done within the main program without going through temporary files.

Another advantage of our approach is its capacity to work without a cloud subscription. Indeed, the WSN data are collected, decoded, and stored locally. Thus, we will be able to develop our data analysis algorithm for our demonstrator. The first results during our tests did not show any noticeable delays due to parsing. Indeed, as soon as the sensor registers a change (depends on its configurable sleep time), it was immediately updated on the interface Figure 15. Thus, the maximum delay recorded is only due to the sleep duration of the sensor. However, our demonstrator has only 51 spaces, this delay may increase due to collisions when the number of sensors becomes very high (this case has not yet been treated). A simulation with a large number of sensors may be useful and can be envisaged in future works. No delay was neither recorded in granting entry or exit access. By handling, entrance, and exit by different agents, it avoids unnecessary queues at these levels.

Our demonstrator is suitable for testing algorithms and approaches designed by the different teams of our laboratory. At the level of our demonstrator, we present different services, but these services are offered to drivers who are looking for a spot and have decided to choose this parking to benefit from these services. In a network of smart parking competing to maximize their chances of having drivers, it will be interesting to simulate the behavior of drivers looking for a spot according to specific criteria (walking distance, price, etc.) by a dedicated agent so-called “driver agent”. Its mission will be to negotiate with the Preference Agent for each car park. The two agents will be in a state of pure individual competition, their goals are compatible, the driver agent must look for a place and the other must receive it at the parking level, their capacities and resources must be sufficient. These two agents must interact to negotiate and achieve their goals.

7. Conclusions and Perspectives

With the extraordinary car fleet growth and transportation impact in current and futures cities’ economy, smart mobility management will offer better life quality to citizens. Smart parking is one of the elements which can contribute to better smart mobility management. Here, the equipment and software architectures of a live smart parking demonstrator have been presented. The data collection flowcharts of different keys equipment for parking were exposed. Additionally to the parking entrance/exit scenarios and flowcharts, we have proposed an open-source local parser for the IoT parking sensors which enable us to successfully retrieve and decode these data. This is the data collection framework of the first pilot deployed smart parking in Casablanca. Our demonstrator is still under improvement and since it’s a pilot project, there are still some ongoing works on it. For example, based on the concept of agents, and more specifically coordination and cooperation, we will improve our demonstrator’s ability to reduce the time spent searching for a parking space. Thanks to a network of intelligent agents, future smart features can be proposed: searching for a vacant space, booking and guiding to the parking space. This solution can contribute to reduce congestion and improve traffic flow, minimizing the time spent looking for a parking space and therefore minimizing the number of cars in urban areas. As described all along in the paper, despite the multiple types of equipment, parking smart management is still possible thanks to the coordination of multiple applications each one managing one or a set of parking equipment.

The challenges of smart parking are numerous. Our teams are still improving the flowcharts, we are also working on new features such as charging for electric and autonomous vehicles, guidance (internal and external), network parking …