Made with Xodo PDF Reader and Editor

Smart Car Parking Monitoring & Alert System

You are required to design and implement a Smart Car Parking Monitoring & Alert System using
Django (Backend) and React (Frontend).

This system simulates a real-world parking facility where multiple parking zones and slots are monitored
through connected devices that continuously send operational data. The software must ingest this data,
process it using meaningful business logic, detect abnormal conditions, and present insights in a
monitoring dashboard.

This is an intentionally challenging assessment, designed to evaluate your ability to:

x understand a domain problem,

x design clean data models,

x implement correct business logic,

x and deliver a working system under strict time constraints.

Focus on clarity, correctness, and structure, not on implementing every possible feature.

Time Limit

20 Hours (Strict)
No extensions will be granted.

Technology Stack (Mandatory)

x Backend: Django + Django REST Framework

x Frontend: React (any UI framework optional)

You are free to choose:

x Database (SQLite / MySQL / PostgreSQL)

x Styling method

x Project structure

Case Scenario: Smart Car Parking Facility

A commercial building operates a multi-zone parking facility with areas such as Basement-1, Basement-
2, Outdoor, and VIP parking.

Each parking slot is monitored by a small device (sensor/controller). These devices periodically send
telemetry data to the backend system. The management wants a software platform that can:
 Made with Xodo PDF Reader and Editor

x Monitor parking slot usage in near real time

x Track historical usage and trends

x Detect device failures or abnormal behavior

x Measure parking efficiency against predefined targets

The system is not responsible for payments or reservations.

System Objectives

You need to build a system that can:

x Store telemetry data sent by parking slot devices

x Store parking usage / occupancy events

x Compute usage and efficiency metrics

x Detect abnormal conditions and generate alerts

x Present monitoring information in a dashboard

Backend Requirements (Django + DRF)

Data Modeling

Design models that represent the parking structure and data flow.
At minimum, your system should conceptually support entities such as:

x Parking Facility (or Site)

x Parking Zone (e.g., B1, B2, VIP)

x Device (attached to a parking slot)

x Telemetry Data (time-series data from devices)

x Parking / Occupancy Log

x Alert

You may add additional models if they make your design clearer.

Telemetry Data Ingestion

Endpoint:
POST /api/telemetry/

Sample Payload:

"device_code": "PARK-B1-S005",
 Made with Xodo PDF Reader and Editor

"voltage": 220.5,

"current": 5.2,

"power_factor": 0.92,

"timestamp": "2026-02-01T10:30:00"

Requirements:

x Validate that the device exists

x Reject invalid timestamps

x Store operational / energy-related data

x Prevent duplicate telemetry for the same device and timestamp

Parking Usage / Occupancy Data

Endpoint:
POST /api/parking-log/

Sample Payload:

"device_code": "PARK-B1-S005",

"is_occupied": true,

"timestamp": "2026-02-01T10:45:00"

This data represents when a parking slot becomes occupied or free.

You may add fields if required to support your logic.

Dashboard Summary API

Endpoint:
GET /api/dashboard/summary/?date=YYYY-MM-DD

The response should include:

x Total parking events

x Current occupancy count

x Number of active devices

x Number of alerts triggered

x Basic efficiency indicators

Business Logic Requirements

Implement logic to:

x Calculate hourly parking usage

x Calculate average occupancy per zone

x Detect and record alerts such as:

R Device offline (no data received for more than 2 minutes)

R Abnormally high power usage

R Invalid or inconsistent data patterns

You may define reasonable assumptions and thresholds.

Parking Target & Efficiency Calculation

The system should support parking usage targets.

Requirements:

x Define a daily target (e.g., expected occupancy or usage count) per zone or per device

x Calculate:

R Target vs actual usage

R Efficiency percentage

x Include these values in the dashboard summary

Alert Severity & Persistence

Enhance the alert system with the following rules:

x Alerts must have severity levels:

R INFO

R WARNING

R CRITICAL

x Alerts must be:

R Stored in the database

R Queryable via API

x Duplicate alerts for the same condition must be prevented

Device Health Scoring

Implement a simple device health score (0–100).

The score may consider:

x Frequency of received data

x Number of alerts generated

x Offline duration

You are free to define the logic, but you must explain it clearly in the README.

Bulk Telemetry Ingestion

Devices may send telemetry in bulk.

Create:

x POST /api/telemetry/bulk/

The payload may contain multiple telemetry records.

Focus on:

x Validation

x Correctness

x Reasonable performance

Perfection is not required.

Frontend Requirements (React)

Dashboard

The dashboard should provide:

x Summary cards (key metrics)

x Zone-wise or slot-wise performance table

x Device heartbeat / last-seen information

x Status indicators:

R OK

R Warning

R Critical
 Made with Xodo PDF Reader and Editor

Live Monitoring

x Poll the backend every 10 seconds

x Display:

R Device status

R Last received timestamp

R Current alert state

Filters & Reports

Support filtering by:

x Parking facility

x Zone

x Date range

Include:

x Sorting

x Search

x Download options (CSV / Excel / PDF)

Alert Management Panel

Provide a basic alert panel that allows:

x Listing active alerts

x Filtering by severity

x Marking alerts as acknowledged

Performance Visualization

Add at least one meaningful chart, such as:

x Hourly usage vs target

x Occupancy trend over time

x Device health trend

Optional Enhancements (Bonus)

You may implement additional features that improve clarity or usability.

Scalability Thought Exercise (No Code Required)

In the README, answer the following:

“What changes would you make if this system had 5,000 devices sending data every 10 seconds?”

This is a reasoning exercise. Code is not required.

Submission Instructions (Mandatory)

x Submit a Git repository link only

x Do not submit ZIP files

Your repository must include:

x A complete, runnable application

x A [Link] containing:

R Setup instructions

R Completed features

R Incomplete features

R What you would implement next with more time

 Missing README or broken setup instructions will result in rejection.

Restrictions

x Do not hardcode data

x Do not use mock APIs

x Do not submit copied tutorial projects

x Do not over-engineer at the expense of clarity

Evaluation Criteria

Your submission will be evaluated based on:

x Architecture and data modeling

x Business logic correctness

x Backend and frontend integration

x Code readability and structure

x Documentation and reasoning

Completing all features is not required.