Key Project Requirements

• On-premise / physical infrastructure only — no cloud storage or cloud processing of any video or metadata.

• Automatic data retention of 30 days — recordings older than 30 days shall be auto-deleted without manual intervention.

• Dashboard and search filtering by Floor, Tower, and Region/Zone.

• Detailed real-time Camera Health and Server Health monitoring.

• Fully scalable camera addition — new cameras added individually without redesigning the system.

S.No.

Item

Specification

1

General

1. The system shall offer a complete on-premise VMS solution, scalable to the required number of cameras, with cameras added on a unit-by-unit (single camera) basis without any redesign of the platform.

2. The system shall be deployed entirely on local physical servers within the organization’s own premises/data center. No video, snapshot, processed, or transmitted to any third-party cloud service.

3. An administrator with appropriate rights shall be able to create users and assign access to specific towers, floors, zones, or individual cameras based on predefined access rights.

4. The system shall provide browser-based access without requiring any additional software or plug-ins:

a. Live display of cameras

b. Live display of camera groups

c. Control of PTZ cameras

d. Playback of archived video

e. Retrieval of archived video

f. Enable / disable camera audio

5. The system shall support creation of camera groups with the following functionality:

a. Each group shall have the capability to hold any number of cameras

b. It shall be possible to include cameras from multiple towers/buildings in the same group

c. Multiple users shall be able to view the same camera group simultaneously

d. It shall be possible to dynamically create a logical group hierarchy, e.g., Region > Tower > Floor > Zone, or any other structure desired

6. The system shall provide a single dashboard showing the status of all cameras across all towers/floors, clearly identifying which specific tower, floor, or camera is offline.

7. It shall be possible to search recordings by Tower, Floor, Zone, Camera, Date, and Time.

8. The system shall support the current camera count with a clear, documented path to scale up to 1000+ cameras streaming simultaneously, without architectural change.

9. The system shall work on  Linux server operating systems.

2

Dashboard, Filtering & Monitoring

1. The system shall provide a central, real-time dashboard displaying: total cameras, cameras online, cameras offline, cameras currently recording, total storage capacity, storage used (%), and count of active alerts.

2. The dashboard, live view, and search/playback screens shall all support filtering by Floor-wise, Tower-wise, and Region/Zone-wise selection, individually or in combination, through a dropdown or hierarchical tree selector.

3. The dashboard shall visually flag, at a glance, any tower/floor/zone that has an offline camera, a stopped recording, or a storage/server issue, without requiring the operator to drill down manually.

4. The dashboard shall show a live summary panel of server health (CPU, RAM, disk, network) alongside the camera summary, on the same screen.

5. The dashboard shall maintain a rolling log/feed of the most recent alerts (camera, storage, server) visible without navigating away from the main screen.

6. The system shall allow saving of custom, frequently used filter views (e.g., ‘Tower A – Floor 5’) for quick access by operators.

7. All ai analytics shows in this dashboard

8. Analytics filter as per the ppe and requirements

9.all alerts showed in this dashboard

3

Video Recording Functions

1. The software shall support continuous (24×7) recording of video (and audio, where applicable) for every connected camera.

2. Fault-tolerant recording: if the software/server operation is interrupted (e.g., power failure), recording shall automatically resume for all cameras that were recording prior to the interruption, once the server restarts.

3. Network fault-tolerant recording: if connectivity between a Recording Server and a camera/floor switch is temporarily lost, recording shall continue locally as soon as the camera is reachable again, with no manual restart required.

4. Recording shall be written in fixed-length segments (e.g., 5-minute files) rather than one continuous file, to limit data loss on failure and to allow fast retrieval.

5. The system shall support Continuous, Scheduled, and Manual recording modes, configurable per camera.

6. Every start and stop of a recording shall be logged with a reason (Manual, Scheduled, Disconnect, Storage Full, Error) for audit purposes.

7. The system shall allow authorized users to view recordings in a timeline view on an hourly basis, and to click on any point on the timeline to jump playback to that exact minute.

8. The system shall allow authorized users to download recordings for a specific camera, date, and time range to local disk.

4

Automatic Data Retention (30-Day Auto-Delete)

1. All recorded video shall be retained on local storage for a rolling period of 30 days by default, configurable by the Administrator.

2. Recordings older than the configured retention period (30 days) shall be automatically and permanently deleted by the system on a scheduled basis, without requiring manual intervention.

3. The auto-delete process shall run on a defined schedule (e.g., daily) and shall delete only the oldest expired segments, keeping all recordings within the retention window intact.

4. The system shall allow specific recordings to be manually marked as ‘Protected’ (e.g., incident evidence) so they are excluded from the automatic 30-day deletion until unprotected by an authorized user.

5. The system shall log every automatic deletion event (camera, date range, file count, freed storage) for audit purposes.

6. In the event storage utilization approaches capacity limits before the 30-day cycle completes, the system shall raise an alert to the Administrator in addition to continuing the standard auto-delete cycle.

5

Camera Support & Scalability

1. The VMS shall support any ONVIF Profile-S compliant IP camera for both live and archived viewing.

2. The system shall support both new IP cameras and any existing analog cameras (via encoder) on the same unified platform, if applicable to the site.

3. The software shall provide Pan-Tilt-Zoom (PTZ) control directly from the web page for PTZ-capable cameras; for fixed cameras, the system shall provide e-PTZ (digital zoom/pan) functionality.

4. New cameras shall be addable to the system individually (one camera at a time) through a simple registration workflow (IP, credentials, RTSP/ONVIF details), without downtime to existing cameras.

5. The architecture shall be horizontally scalable — additional Recording Servers and storage can be added as camera count grows (e.g., 210 to 500 to 1000+ cameras) without redesigning the core VMS.

6. The system shall support grouping and assignment of newly added cameras directly into the existing Floor/Tower/Region hierarchy at the time of registration.

6

Camera Health Monitoring

1. The system shall continuously monitor the health of every connected camera at a configurable interval (e.g., every 10 seconds).

2. Camera health states shall include, at minimum: Online/Streaming, Online/No Video, Offline, and Authentication Failed.

3. The system shall notify designated users via email (and optionally SMS/dashboard popup) when a camera goes offline, when recording is deliberately or unexpectedly stopped, or when a camera reports an authentication failure.

4. The dashboard shall display a live, filterable list of camera health status by Floor, Tower, and Region, allowing an operator to instantly identify all offline cameras in a specific tower or floor.

5. The system shall maintain a historical camera uptime/availability report per camera, exportable for reporting purposes.

7

Server Health Monitoring

1. The system shall continuously monitor the health of all servers in the deployment, including Recording Servers, Database Server, and Web/Application Server.

2. Monitored server metrics shall include, at minimum: CPU utilization, RAM utilization, disk/storage utilization, network throughput, and service uptime.

3. The system shall monitor storage-specific health separately, including total capacity, used space, free space, and RAID/disk array status (Healthy, Degraded, Rebuilding, Failed).

4. The system shall raise threshold-based alerts (e.g., at 80%, 90%, and 95% storage or resource utilization) to designated Administrators.

5. Server health information shall be visible on the same central dashboard as camera health, filterable by which Recording Server/tower it corresponds to.

6. The system shall log all server-level faults (service crash, disk failure, high resource usage) with timestamps for audit and troubleshooting.

8

Storage (Physical / On-Premise Only)

1. All video recordings shall be stored exclusively on local, physical, on-premise storage (NAS/SAN) — no cloud storage of any kind shall be used at any stage.

2. Storage shall use RAID-6 (or an equivalent redundant configuration) with hot spares to protect against disk failure.

3. Storage shall be organized in a clear folder hierarchy, for example: Tower / Floor / Camera / Year / Month / Day / segment files, to support fast retrieval and simple retention cleanup.

4. The system shall support distributing camera load and storage across multiple Recording Servers so that no single server is responsible for all cameras.

5. The Storage Manager component shall track available/used capacity in real time and enforce the 30-day automatic retention/deletion policy described in Section 4.

9

Database (Local / Physical — Not Cloud)

1. The system shall use a local, physically hosted database server (e.g., PostgreSQL or equivalent) within the organization’s own infrastructure — no cloud-hosted or third-party managed database shall be used.

2. The database shall store metadata only: camera details, recording session records (start/end time, file path, stop reason), user accounts and roles, alerts, and audit logs. Raw video shall never be stored inside the database.

3. The database shall maintain an audit trail of all administrative actions: login/logout, configuration changes, manual recording start/stop, clip exports, and user management changes.

4. The database shall be backed up locally on a scheduled basis (e.g., nightly), with backups stored on-premise.

10

Security & Access Control

1. All communication between cameras, servers, and the web dashboard shall be encrypted (SSL/TLS).

2. The system shall support Role-Based Access Control (RBAC), allowing creation of any number of users with permissions scoped to specific Towers, Floors, Zones, or individual cameras.

3. The system shall support defining which users can view live video only, versus which users can access playback, export, or system configuration.

4. The system shall enforce password policies (minimum complexity, expiry) and automatic session timeout for idle sessions.

5. All login attempts (successful and failed) shall be logged with timestamp and source IP address.

11

Notifications

1. The system shall support multiple notification channels: Email, SMS (via gateway integration), and on-screen/dashboard popup.

2. Notifications shall be triggered for: camera offline, recording stopped, storage threshold breached, server health fault, and unauthorized login attempts.

3. Each user shall be able to configure which notification types they wish to receive, scoped to the towers/floors/cameras they have access to.

12

Drone Video Integration & Drone Details

1. The VMS shall support ingestion of live video feeds from drones (UAVs) used for aerial patrol/site survey, in addition to fixed IP cameras, on the same unified dashboard.

2. Drone video shall be received via the drone’s ground control station / RTMP-RTSP relay and shall be treated by the VMS as an additional live camera source, viewable in the same live grid alongside fixed cameras.

3. The system shall maintain a Drone Registry, recording the following details for each drone:

a. Drone ID and Drone Name / Call Sign

b. Make & Model, Serial Number, Firmware Version

c. Operator / Pilot assigned

d. Payload / Camera specification (resolution, zoom, thermal capability if any)

e. Battery / Flight-time rating

f. Current Status (Active / Idle / Charging / Maintenance)

4. The system shall log each drone flight/session with: Flight ID, Drone ID, Pilot, Start Time, End Time, Assigned Tower/Zone/Route covered, and total flight duration.

5. Drone video shall be recorded on the same on-premise storage as fixed camera footage, following the same segmentation, folder structure (e.g., Drones/Drone-ID/Date/), and 30-day automatic retention/auto-delete policy described in Section 4, unless a longer retention is explicitly configured for drone footage.

6. The dashboard shall provide a separate ‘Drones’ filter/category (alongside Floor-wise, Tower-wise, Region-wise filters) so operators can isolate and view drone feeds and recordings independently of fixed cameras.

7. The system shall display drone health/telemetry status where available from the drone platform, including GPS location, altitude, battery percentage, and signal strength, alongside the video feed.

8. The system shall generate an alert if a drone feed disconnects unexpectedly during an active recorded flight, consistent with the camera-offline alerting behavior described in Section 6.

9. Playback and search of drone footage shall support the same timeline, seek, export, and clip-download functionality provided for fixed camera recordings.

10. The system shall support geo-tagging of drone recordings (flight path/coordinates) where the drone platform provides GPS metadata, allowing recordings to be searched or reviewed against a map view.

11. Drone integration shall not require any cloud service — all drone video, telemetry logs, and flight records shall be stored and processed on the same local, on-premise infrastructure as the rest of the VMS.

13

Scalability Roadmap

1. Phase 1: Initial camera deployment across current towers/floors — baseline Recording Servers and on-premise storage sized to the current camera count.

2. Phase 2: Camera count expanded to additional towers/floors — additional Recording Servers and storage added in the same architecture without redesign.

3. Phase 3: Full-site rollout up to 1000+ cameras — horizontal scale-out of Recording Servers, storage, and (if required) redundant Web/Application servers.

4. At every phase, the Floor/Tower/Region filtering, dashboard, camera health, server health, 30-day auto-retention, and on-premise-only storage requirements shall remain unchanged and fully functional.