smart parking management system

Design a system that provides timely and understandable information about vacant and occupied parking slots, supports orderly parking operations, and reduces reliance on manual monitoring. The design should account for inaccurate sensor readings, communication delays, duplicate reservations, unauthorised access, and the privacy of vehicle-related data. 1.2 Objectives

• Detect or record the occupancy state of each configured parking slot.
• Display current availability through a web or mobile interface.
• Maintain parking-slot, entry/exit, and reservation records in a structured database.
• Provide administrators with tools to manage slots, review status, and generate summaries.
• Define a reproducible evaluation plan for detection quality, update delay, reliability, and usability.
• Include access control, data minimisation, fault handling, and privacy safeguards. 1.3 Scope The paper describes a proposed academic prototype for a defined parking area. It may use sensor-based occupancy detection with a microcontroller or edge device and a browser-based dashboard. Reservation, QR/RFID-based access, payments, number-plate recognition, and predictive analytics are optional extensions and are not assumed to be implemented. The system is intended to assist parking decisions rather than guarantee a space or replace local traffic and safety procedures.

Research on smart parking has explored sensor networks, IoT gateways, camera-based detection, cloud platforms, and mobile applications. Sensor-based systems can provide direct slot-level status and may be comparatively straightforward to deploy, but their performance depends on sensor placement, calibration, environmental conditions, and maintenance. Camera-based methods can observe multiple spaces with fewer devices in some layouts, although occlusion, changing illumination, and image-processing requirements can affect reliability. Jabbar et al. describe an IoT Raspberry Pi-based parking management system for smart-campus use, combining ultrasonic sensors, a camera, GPS, wireless communication, and a mobile dashboard [1]. Their work illustrates how occupancy data can be shared with users and operators. A survey of IoT-driven smart parking systems discusses occupancy sensing, reservation, user authentication, guidance, payment, and energy efficiency, while also identifying security and deployment challenges [2]. Research on fog computing proposes processing data closer to parking devices to reduce dependence on a single cloud layer and to support faster local decisions [3]. Recent approaches also combine wireless sensor networks with visual verification to improve reliability and reduce false occupancy reports [4]. Number-plate recognition can be integrated with IoT-based occupancy monitoring to automate entry and exit records, although it introduces additional privacy and recognition-error concerns [5]. These studies suggest that smart parking is not only a detection problem: status synchronisation, network reliability, usable interfaces, privacy, and operational maintenance are also important.

A practical student prototype should bring occupancy monitoring, a clear user interface, reservation-state consistency, and administrative oversight into one understandable workflow. It should also define how stale sensor readings are handled and how conflicting booking requests are prevented. Many feature-rich designs introduce additional cost and complexity; therefore, the proposed system uses a modular architecture so that essential availability monitoring can be developed first and optional functions can be added only after testing. Research basis: The literature summary is based on published work on IoT and sensor-based parking systems. The proposed design choices are a synthesis for an academic prototype, not claims that a new implementation has already been validated.

The proposed Smart Parking Management System consists of a parking-space detection layer, a controller or edge gateway, a communication layer, a backend service, a database, and user-facing interfaces. Each slot is assigned a unique identifier and an occupancy state such as vacant, occupied, unavailable, or sensor-fault. The backend receives timestamped status messages, validates them, and updates the current parking map. Users can view available spaces; an optional reservation module can temporarily hold a slot and release it when the reservation expires or is cancelled.

A prototype can use an ESP32 or similar microcontroller for sensor acquisition, a Python/FastAPI or Node.js backend for application services, and PostgreSQL or MySQL for structured records. A web interface can be implemented with React or another suitable framework. These are suggested technologies rather than mandatory components. The selected stack should match the available hardware, the team's skills, the expected number of parking slots, and the institution's deployment constraints. A sensor node sends a slot identifier, reading, and timestamp. The backend checks whether the message is valid and recent before changing the slot state. If readings stop arriving, the interface should mark the slot status as unknown or stale instead of silently displaying an old value as current. Where reservations are enabled, the backend should use a transaction or equivalent atomic operation to prevent two users from booking the same slot simultaneously.

A slot should be shown as available only when the latest valid observation indicates that it is vacant and the slot is not blocked by maintenance or an active reservation. The application should distinguish sensor status from booking status. If the sensor and reservation state disagree, the system should flag the conflict for review rather than assuming the vehicle is absent. 4. Methodology

First, define the parking area, number of slots, slot identifiers, entry and exit paths, network coverage, and intended users. Collect only information needed to operate and evaluate the prototype. For an initial test, use a small controlled parking layout and manually label slot states at known times. Any camera-based data should be collected with appropriate permission and should avoid retaining identifiable images unless essential and authorised.

Read the selected sensor or camera input for each configured parking slot.

• Apply basic validation and filtering to reduce transient or implausible readings.
• Associate each observation with a slot identifier and timestamp.
• Classify the slot as occupied, vacant, or unknown when readings are invalid or stale.
• Send status updates to the backend and retain the minimum event information required for audit and debugging.
• Allow authorised operators to flag a faulty sensor or temporarily close a slot.

The backend authenticates incoming device messages, validates the slot identifier, checks timestamp freshness, and updates the current state. The application interface reads the latest accepted state and displays the time of the last update. If reservations are included, a booking request should be validated against slot status and the reservation time window in one atomic operation. Expired reservations should be released according to a documented policy.

For a larger parking area, a recommendation module may rank vacant slots using walking distance to a destination, vehicle type, accessibility requirements, and the estimated route inside the facility. A simple prototype can use rule-based ranking; more advanced prediction should only be introduced after suitable historical data has been collected and evaluated. Accessibility-designated spaces must be handled according to applicable rules.

1. Initialise the parking-slot inventory and device configuration. 2. Receive a sensor or camera observation for a slot. 3. Validate the reading and assign a timestamp. 4. Update the slot state if the observation is valid and sufficiently recent. 5. Reconcile the physical status with any active reservation or maintenance block. 6. Publish the latest status to the user interface. 7. Record operational events and report faults or stale data. 8. Evaluate detection, latency, reliability, and usability using a documented test plan.

Use authentication and role-based permissions for users, operators, and administrators.

• Protect communications with appropriate transport security and keep device credentials private.
• Collect only necessary personal or vehicle-related information and define a retention period.
• Restrict access to camera images and number-plate information; avoid storing them unless required.
• Validate device messages and rate-limit endpoints to reduce misuse.
• Log system events without exposing passwords, tokens, or unnecessary personal information.
• Provide a safe manual override and a clear process for handling sensor or network failures.

The system should tolerate temporary loss of connectivity and recover without creating duplicate or contradictory events. Device health indicators, last-seen timestamps, and administrator alerts can help identify failures. A manual inspection procedure should remain available when the system cannot confidently determine occupancy.

A completed evaluation should examine the trade-off between installation cost and detection reliability, the impact of stale sensor readings, the effect of network latency on user decisions, and the usability of the parking interface. Sensor-based and camera-based approaches should be compared only under a documented and fair test setup.

7.1 Advantages

• Provides a central view of available and occupied parking slots. • Can reduce repeated manual checks and make parking information easier to access. • Supports modular extension to reservation, access control, analytics, or payments. • Creates structured records that can help administrators review demand and faults. 7.2 Limitations • Sensor installation and maintenance may be costly across large parking areas. • Incorrect placement, weather, occlusion, or hardware failure can produce wrong states. • Connectivity issues can make displayed information stale or unavailable. • Reservations do not guarantee that a physical slot will remain vacant without enforcement. • Camera and number-plate features introduce privacy, security, and legal considerations.

A smart parking system should collect only data necessary for occupancy management and should explain how the data will be used. Access to account details, vehicle identifiers, and camera footage should be limited to authorised purposes. Where images or number plates are processed, the project should consider consent or other applicable legal grounds, notice, retention, security, and deletion. The system should not expose identifiable data on public dashboards. Accessibility spaces and other designated parking rules must be respected, and the interface should not imply certainty when data is stale or unavailable.

Future extensions may include reservation and cancellation, QR or RFID-based entry, payment integration, automatic number-plate recognition, occupancy forecasting, indoor navigation, and integration with multiple parking facilities. Edge processing may help maintain local operation during cloud connectivity problems. A larger deployment could use historical, privacy-conscious data to estimate demand by time of day. Each extension should be evaluated for security, cost, maintainability, and user benefit before deployment. 10. Conclusion This paper proposed a Smart Parking Management System that combines parking-slot occupancy detection, a backend service, structured records, and a web or mobile interface. The design outlines modules for sensing, status validation, availability display, optional reservations, administration, and evaluation. It also identifies privacy, security, stale data, sensor reliability, and booking consistency as important requirements. The paper is a proposed academic design rather than a report of a completed experiment; its effectiveness must be established through a working prototype and documented testing.