Sensor Driven Virtual Fencing and

Boundary Control

An Interdisciplinary Project Report (XX367P)

Submitted by,
Ayush Bhardwaj 1RV22EI008
Devansh Srivastava 1RV22EI018
Adit Nahar 1RV22IM005
Mihika Kerur 1RV22IM032
Anjali Heda 1RV22IS009
Vrushabh Brahmbhatt 1RV23IS406

Under the guidance of

Dr. Rajeswara Rao K V S
Associate Professor and Head of the Department
Dept. of IEM
RV College of Engineering®
.

In partial fulfillment of the requirements for the degree of

Bachelor of Engineering in respective departments

2024-25
 RV College of Engineering®, Bengaluru
(Autonomous institution affiliated to VTU, Belagavi )

CERTIFICATE
Certified that the interdisciplinary project (XX367P) work titled Sensor Driven Vir-
tual Fencing and Boundary Control is carried out by Ayush Bhardwaj
(1RV22EI008), Devansh Srivastava (1RV22EI018), Adit Nahar (1RV22IM005),
Mihika Kerur (1RV22IM032), Anjali Heda (1RV22IS009) and Vrushabh Brahmb-
hatt (1RV23IS406) who are bonafide students of RV College of Engineering, Bengaluru,
in partial fulfillment of the requirements for the degree of Bachelor of Engineering in
respective departments during the year 2024-25. It is certified that all corrections/sugges-
tions indicated for the Internal Assessment have been incorporated in the interdisciplinary
project report deposited in the departmental library. The interdisciplinary project report
has been approved as it satisfies the academic requirements in respect of interdisciplinary
project work prescribed by the institution for the said degree.

Dr. Rajeswara Rao K V S Dr. Rajeswara Rao K V S

Guide Head of the Department

Dr. M.V. Renukadevi Dr. K. N. Subramanya

Dean Academics Principal

External Viva
Name of Examiners Signature with Date

1.

2.
 DECLARATION
We, Ayush Bhardwaj, Devansh Srivastava, Adit Nahar, Mihika Kerur, Anjali
Heda and Vrushabh Brahmbhatt students of sixth semester B.E., RV College of
Engineering, Bengaluru, hereby declare that the interdisciplinary project titled ‘Sensor
Driven Virtual Fencing and Boundary Control’ has been carried out by us and
submitted in partial fulfilment for the award of degree of Bachelor of Engineering in
respective departments during the year 2024-25.

Further we declare that the content of the dissertation has not been submitted previously
by anybody for the award of any degree or diploma to any other university.

We also declare that any Intellectual Property Rights generated out of this project carried
out at RVCE will be the property of RV College of Engineering, Bengaluru and We will
be one of the authors of the same.

Place: Bengaluru

Date:

Name Signature

1. Ayush Bhardwaj(1RV22EI008)

2. Devansh Srivastava(1RV22EI018)

3. Adit Nahar(1RV22IM005)

4. Mihika Kerur(1RV22IM032)

5. Anjali Heda(1RV22IS009)

6. Vrushabh Brahmbhatt(1RV23IS406)
 ACKNOWLEDGEMENTS
We are indebted to our guide, Dr. Rajeswara Rao K V S, Associate Professor
and Head of the Department, Department of IEM, RVCE for the wholehearted support,
suggestions and invaluable advice throughout our project work and also helped in the
preparation of this thesis.

We also express our gratitude to our panel member Dr. B. Sathish Babu, Profes-
sor and HoD, Department of AI-ML, RVCE for the valuable comments and suggestions
during the phase evaluations.

Our sincere thanks to the project coordinator Dr. M N Vijayakumar, Associate

Professor, Department of IEM for timely instructions and support in coordinating the
project.

Our gratitude to Prof. Narashimaraja P, Department of ECE, RVCE for the or-
ganized latex template which made report writing easy and interesting.

We are deeply grateful to Dr. M.V. Renukadevi, Professor and Dean Academics,
RVCE, for the continuous support in the successful execution of this Interdisciplinary
project.

We express sincere gratitude to our beloved Professor and Vice Principal, Dr. Geetha
K S, RVCE and Principal, Dr. K. N. Subramanya, RVCE for the appreciation to-
wards this project work.

Lastly, we take this opportunity to thank our family members and friends who pro-
vided all the backup support throughout the project work.
 ABSTRACT

Urban metro systems are increasingly becoming the backbone of sustainable trans-
portation in densely populated cities. With rising footfall at metro platforms, the risk
of accidental or intentional boundary breaches—particularly into the track zone beyond
the yellow safety line—has emerged as a serious safety concern.

This project proposes a sensor-driven boundary breach detection and communication

system to enhance passenger safety through intelligent sensing, real-time monitoring, and
localized wireless communication. The system integrates a Force Sensing Resistor (FSR)
to detect breaches, and an ultrasonic sensor that activates the system only when a train
is approaching, thereby conserving power and reducing false alerts.

The data is processed by ESP32 microcontrollers and transmitted through a custom

API route to two real-time interfaces: an Operator Dashboard and a Pilot Dashboard.
The operator dashboard displays live status, system health, breach statistics, and data
analytics through graphs and pie charts. It logs red alerts as incident reports, which
can be exported as PDFs for future machine learning analysis. The pilot dashboard,
connected wirelessly to the Station ESP from a distance of 200 meters, shows live breach
alerts and provides real-time suggestions, such as “Reduce speed immediately” for red
alerts.

The system is disabled automatically when the train is parked at the platform to
avoid false alerts. A scaled prototype using sun board was developed to demonstrate
this system’s viability. The solution is low-cost, scalable, and designed for modular
deployment across diverse metro environments.

i
 CONTENTS

Abstract i

List of Figures v

List of Tables vi

1 Introduction 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Patentability of the Proposed Metro Platform Safety System . . . . . . . 8
1.4.1 Legal Framework for Patentability in India . . . . . . . . . . . . . 9
1.4.2 Evaluation of the Proposed System Under Indian Patent Law . . 9
1.4.3 Comparative Analysis with Existing Solutions and Patents . . . . 11
1.4.4 Conclusion and Justification . . . . . . . . . . . . . . . . . . . . . 12
1.5 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Need for Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8 Organization of the report . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Methodology 17
2.1 Overall Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Hardware Design and Selection . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Backend and API Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Web Dashboard and Visualization . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Communication Protocol and Security . . . . . . . . . . . . . . . . . . . 23
2.6 Testing and Validation Strategy . . . . . . . . . . . . . . . . . . . . . . . 24

3 System Architecture 26
3.1 Layered Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Circuit Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 Transmitter Circuit (Sensor Node) . . . . . . . . . . . . . . . . . 30

ii
 3.2.2 System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3 Safety and Power Considerations . . . . . . . . . . . . . . . . . . 32
3.3 Sequence of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Implementation 34
4.1 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Microcontroller: ESP32 . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Sensor Node Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Receiver Node Implementation . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Web Interface and Dashboard . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Calibration and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6 Integration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Results & Discussions 42

5.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Functional Verification: Breach Detection . . . . . . . . . . . . . . . . . . 43
5.3 Activation/Deactivation Logic: Train Simulation . . . . . . . . . . . . . . 44
5.4 Communication and Latency Evaluation . . . . . . . . . . . . . . . . . . 45
5.5 Display Behavior and Responsiveness . . . . . . . . . . . . . . . . . . . . 46
5.6 Prototype Limitations and Scope . . . . . . . . . . . . . . . . . . . . . . 46
5.7 Analytics & Incident Logging Module . . . . . . . . . . . . . . . . . . . . 47
5.7.1 Event Classification and Logging . . . . . . . . . . . . . . . . . . 47
5.7.2 Dashboard Visualizations . . . . . . . . . . . . . . . . . . . . . . 47
5.7.3 Incident Report Generation . . . . . . . . . . . . . . . . . . . . . 48
5.7.4 Manual Logging and Export Features . . . . . . . . . . . . . . . . 48

6 Conclusion and Future Scope 50

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Validation of Core Functionality . . . . . . . . . . . . . . . . . . . . . . . 52
6.4 System Integration and Reliability . . . . . . . . . . . . . . . . . . . . . . 52
6.5 Prototype Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.6 Implications for Full-Scale Deployment . . . . . . . . . . . . . . . . . . . 53

iii
 6.7 Recommendations for Further Development . . . . . . . . . . . . . . . . 53
6.8 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.9 Full-Scale Deployment and Field Trials . . . . . . . . . . . . . . . . . . . 54
6.10 Environmental Durability and Casing . . . . . . . . . . . . . . . . . . . . 54
6.11 Multi-Zone and Multi-Node Integration . . . . . . . . . . . . . . . . . . . 54
6.12 Dashboard Finalization and Cloud Integration . . . . . . . . . . . . . . . 55
6.13 Data-Driven Analytics and Predictive Insights . . . . . . . . . . . . . . . 56
6.14 Emergency Integration and Auto-Control Responses . . . . . . . . . . . . 56
6.15 Power Management and Energy Efficiency . . . . . . . . . . . . . . . . . 57
6.16 Compliance and Certification . . . . . . . . . . . . . . . . . . . . . . . . 57

A Code 58
A.1 First Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.1.1 Transmitter Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B Bibliography 62
B.1 Second Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

iv
 LIST OF FIGURES

1.1 Existing Metro System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Platform Screen Doors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Operator Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Red Alert Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Pilot Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Red Alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1 ESP Connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 ESP Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Incident Logging and Report . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Analytics Graph and Chart . . . . . . . . . . . . . . . . . . . . . . . . . 49

v
 LIST OF TABLES

1.1 Evaluation Non-Patentable Components . . . . . . . . . . . . . . . . . . 11

5.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

vi
vii
viii
 Chapter 1
Introduction

Interdisciplinary Project Report 2024-25

 Sensor Driven Virtual Fencing and Boundary Control

CHAPTER 1
INTRODUCTION
In the current era of urbanization, metro rail systems are the backbone of mass transit
in major cities. With increasing urban populations, metro stations witness heavy pas-
senger footfall, especially during peak hours. Amidst such density, passenger safety on
platforms, particularly near the train boarding edge, becomes a critical issue. Accidental
falls, crowd pushes, intentional rule-breaking, or even confusion due to lack of guidance
can lead to serious injuries or fatalities. While many stations employ physical safety lines
or platform screen doors, these solutions are often expensive, non-scalable, and dependent
on human supervision. Platform screen doors, for example, require precise train stop-
ping alignment and are cost-prohibitive for widespread deployment in budget-constrained
public systems.

1.1 Introduction
To mitigate these risks, there is a growing interest in smart, automated safety systems.
Our project proposes an intelligent, non-intrusive, and low-cost solution — a Sensor-
Driven Virtual Fencing System using ESP32 microcontrollers, ultrasonic sensors, and a
web-based interface.
This system creates a virtual boundary along the platform edge. When a person crosses
this invisible line, the sensors detect the breach and trigger an immediate alert — a buzzer
sound, an LED indicator on-site, and a real-time warning on a central dashboard accessed
through the web interface. Such a system enhances passenger discipline, reduces the load
on human staff, and scales easily across metro stations. Technological Focus: Embedded
systems, real-time data processing, web-based visualization, human safety interfaces

1.2 Background
Overview of Global Metro Safety Technologies and
Sensor Options
Safety in metro rail systems has always been a core concern in urban transport engi-
neering. Different countries have implemented a variety of safety technologies based on
infrastructure budgets, technological readiness, and passenger volume.

RV College of Engineering® 2024-25 2

 Sensor Driven Virtual Fencing and Boundary Control

Figure 1.1: Existing Metro System

Platform Screen Doors (PSDs)

• Implemented In: Singapore (SMRT), Hong Kong (MTR), Paris (Metro Line 14),
Dubai Metro, and parts of the Delhi Metro.

• Function: Physical barriers that align with train doors, preventing access to the
track area.

• Pros: Completely eliminates falls and track intrusions.

• Cons: High cost of installation and maintenance, train alignment issues, difficult
retrofitting in older systems.

Figure 1.2: Platform Screen Doors

Warning Strip Sensors

• Some metro systems use pressure-sensitive tiles or infrared beams at the edge to
detect breaches.

• These systems are typically passive and may not cover the full edge or provide
intelligent tracking.

RV College of Engineering® 2024-25 3

 Sensor Driven Virtual Fencing and Boundary Control

Manual Surveillance
• Deployed in most Indian metro systems, where CCTV monitoring and platform
staff handle safety enforcement.

• Limitations: High human error rate, delayed reaction times, and fatigue.

Advanced AI-Based Systems

• Tokyo Metro and Seoul Metro are experimenting with AI-based CCTV that uses
machine vision to detect erratic behavior, crowd surges, or boundary breaches.

• These systems are expensive, require large computational infrastructure, and often
raise privacy concerns.

Proximity sensing forms the technological foundation of virtual fencing. Different

types of sensors have been studied and used across industrial, transportation, and con-
sumer applications.

Ultrasonic Sensors
• Principle: Emits high-frequency sound waves and calculates distance by measuring
the return time.

• Advantages:

– Cost-effective

– Wide coverage (up to several meters)

– Reliable in low-light or smoke-filled environments

• Limitations:

– Affected by soft surfaces

– Sensitive to temperature and airflow

LiDAR
• Offers high-precision 3D mapping of nearby objects.

• Very accurate, used in autonomous vehicles.

• Limitation: High power consumption, cost, and processing needs.

RV College of Engineering® 2024-25 4

 Sensor Driven Virtual Fencing and Boundary Control

Cameras + Computer Vision

• Combined with AI to detect human behavior.

• Effective for predictive safety (detecting erratic movement).

• Limitations: High computational needs, privacy issues, variable lighting condi-

tions.

For this project, ultrasonic sensors strike the right balance between cost, reliability,
and simplicity for edge-based boundary detection.

1.3 Literature Review

Metro platform safety has emerged as a critical area of focus within the broader field
of intelligent transportation systems, particularly in urban settings where crowd density,
train frequency, and infrastructure limitations converge. This report presents a consoli-
dated analysis of 50 key research works covering diverse approaches—ranging from deep
learning-based vision systems to low-power sensor networks—highlighting technological
trends, performance benchmarks, and their implications for the design of sensor-driven
safety systems in metro platforms.
A predominant stream of literature has explored the deployment of AI-powered computer
vision techniques for real-time detection of boundary breaches, fall events, and crowd be-
havior. Paul et al. [1] and Han et al. [2] demonstrated the efficacy of convolutional
neural networks (CNNs) and YOLO variants for accurate intrusion detection with laten-
cies under 200 ms. These studies confirm the potential of visual monitoring in enhancing
platform safety but also underline challenges such as high computational cost, power de-
mand, and privacy concerns [1][4][44][48].
Complementing vision systems, numerous studies have advanced the use of sensor-based
platforms, particularly those utilizing ultrasonic, infrared (IR), and force-sensitive resis-
tors (FSR). Sahba et al. [6], Kim and Choi [12], and Li and Chen [20] illustrated how
non-vision sensors can provide real-time, localized monitoring with accuracies ranging
from 89% to 94%, and latencies typically under 300 ms. These sensor-driven systems
offer advantages in cost, deployment simplicity, and operational efficiency—key factors
in infrastructure-constrained metro environments.
Studies on wireless sensor networks (WSNs) and communication protocols have further

RV College of Engineering® 2024-25 5

 Sensor Driven Virtual Fencing and Boundary Control

shaped the field. Garcia et al. [8] and Silva Torres [28] validated low-latency communi-
cation (¡250 ms) using mesh topologies, while Singh Kapoor [34] and Nguyen Chan [43]
identified optimal wireless protocols (ZigBee, LoRa) and adaptive networking strategies
for high resilience in metro settings. MQTT and WebSocket-based systems have been
successfully used for real-time alerts and dashboard visualization [37][27].
Hardware implementation and embedded system reliability were central themes in papers
involving ESP32 microcontrollers. Wang Liu [15], Sharma Verma [21], and Tan Wong
[31] demonstrated the feasibility of edge processing using ESP32 for sensor data acquisi-
tion, with power-saving strategies that extended battery life and reduced latency. These
findings validate ESP32 as an ideal platform for implementing real-time, distributed
safety logic.
Several papers also emphasized the importance of sensor fusion and calibration, showing
that combining IR, ultrasonic, and vibration sensors significantly enhances detection reli-
ability and reduces false positives [11][33][26]. Müller et al. [11] and Fernandez et al. [33]
particularly underscore the effectiveness of multi-sensor systems, which can outperform
single-modality platforms in complex metro environments.
In the context of human–machine interaction, ergonomic and user-interface design was
studied by Park Martinez [27] and Wilson Kumar [40], who reported that operator
response times and alert fatigue could be significantly improved through optimized dash-
boards and alert systems. Such findings reinforce the value of intuitive control room
interfaces within broader safety architectures.
From a systems integration standpoint, cloud and edge computing architectures have
been well-researched. Liu et al. [36] and Patel Singh [18] show that distributed process-
ing at the edge can reduce cloud dependency, alert latency, and bandwidth usage. These
architectures are critical for scalability and robustness in modern IoT-enabled metro sys-
tems.
Lastly, a subset of papers focused on power autonomy and sustainability. Gonzalez
Ramirez [17] presented energy harvesting methods to power sensor nodes sustainably,
while Mockel et al. [16] addressed fault recovery in sensor networks, ensuring over98
percent uptime. These factors are crucial for long-term, maintenance-free deployment in
real-world conditions.
Collectively, the reviewed literature establishes a solid foundation for the design and im-

RV College of Engineering® 2024-25 6

 Sensor Driven Virtual Fencing and Boundary Control

plementation of an efficient, low-cost, and scalable sensor-driven virtual fencing system

like the one proposed in this project. While AI and computer vision offer high accu-
racy and crowd-level analytics, sensor-based approaches provide practical, localized, and
real-time monitoring solutions with lower infrastructure and privacy overhead. Wire-
less communication protocols, edge computing via ESP32, and human-centric dashboard
design further enable a robust and deployable safety solution.

Identified Gaps in Literature (Specific to Indian Metro

Rail)
• Inadequate Use of Affordable Indigenous Sensor Technology: Most sys-
tems reviewed use imported or costly hardware (e.g., LiDAR, Jetson platforms)
which are not viable for large-scale deployment in Indian metros, especially in Tier-
2 or Tier-3 cities.

• Scarcity of Deployable ESP32-Based Solutions for Platform Safety: De-

spite ESP32 being cost-effective and widely available in India, few Indian metro
projects have deployed it for real-time safety monitoring with ultrasonic or IR sen-
sors.

• No Systematic Studies on Sensor Performance in Indian Metro Environ-

mental Conditions: Environmental factors like high passenger density, humidity,
dust, and metallic reflections in Indian stations remain largely untested in sensor
performance studies.

• Absence of Pilot-Scale Sensor-Based Safety Deployments in India: There

are no publicly documented trials or deployments of sensor-based virtual fencing in
Indian metro stations using embedded platforms like ESP32.

• Lack of Integration with Existing Indian Metro Infrastructure: Few stud-

ies discuss integrating ESP32-based detection systems with central control infras-

RV College of Engineering® 2024-25 7

 Sensor Driven Virtual Fencing and Boundary Control

tructures like SCADA or OCCs (Operation Control Centers) used in Indian metros.

• Underrepresentation of Multilingual Real-Time Alert Systems: India’s

linguistic diversity demands support for regional language alerts (Hindi, Tamil,
Marathi, etc.), which is overlooked in most existing systems.

• Limited Emphasis on Maintenance-Free and Energy-Efficient Systems:

Power outages and reliability concerns in Indian cities require low-power or energy-
harvesting solutions, which current systems rarely consider.

• No Framework for Data Privacy and Compliance in Indian Metro Safety

Monitoring: With India’s DPDP Act, privacy in AI/CCTV monitoring must be
addressed. Sensor-based systems provide a privacy-friendly alternative but are un-
derexplored.

• Absence of Comparative Evaluation Between AI-Based Vision Systems

and Sensor-Driven Systems in India: No studies benchmark cost, latency, and
accuracy between AI-CCTV systems and sensor-based alternatives for Indian metro
settings.

• Lack of Open-Source Prototypes or Reference Designs for Indian Con-

ditions: The absence of publicly available hardware and software templates limits
rapid deployment and scaling of sensor-based metro safety systems in India.

1.4 Patentability of the Proposed Metro Platform

Safety System
The proposed system offers an embedded engineering solution to enhance metro plat-
form safety through a sensor-driven virtual fencing architecture. This system combines

RV College of Engineering® 2024-25 8

 Sensor Driven Virtual Fencing and Boundary Control

ultrasonic and FSR (Force Sensitive Resistor) sensors, ESP32 microcontrollers, and HC-
12 RF communication modules to detect platform breaches only during the approach of
a train. The data is transmitted using MAC-layer wireless communication to two inter-
faces: a local LCD display inside the train and a web-based dashboard for the control
room.
This section evaluates the patentability of the system under the Indian Patent Act,
1970—particularly Section 2(1)(j), which defines what constitutes a patentable invention—
and cross-references relevant clauses for novelty, inventive step, industrial applicability,
and exclusions under Section 3.

1.4.1 Legal Framework for Patentability in India

According to the Indian Patent Act, 1970, an invention is patentable only if it satisfies
the following three cumulative criteria:

1. Novelty

Section 2(1)(j) of the Act requires the invention to be “not anticipated by publica-
tion in any document or used in the country or elsewhere in the world before the
date of filing.”

2. Inventive Step (Non-Obviousness)

As per Section 2(1)(ja), an inventive step must involve “a technical advance as

compared to the existing knowledge or having economic significance or both”, and
it must not be obvious to a person skilled in the art.

3. Industrial Applicability

Defined under Section 2(1)(ac), an invention is industrially applicable if it can be

“made or used in an industry.”

1.4.2 Evaluation of the Proposed System Under Indian Patent

Law
A. Novelty [As per Section 2(1)(j)] The proposed system demonstrates novelty
through a combination of features that do not exist collectively in any known system:

RV College of Engineering® 2024-25 9

 Sensor Driven Virtual Fencing and Boundary Control

• A conditional logic framework where FSR sensors are activated only when ultrasonic
sensors detect an approaching train.

• Communication between sensor nodes and receiver units occurs through MAC-layer
RF transmission using HC-12 modules, without Wi-Fi, GSM, or cloud dependency.

• Alerts are transmitted simultaneously to a train-mounted LCD and a control room

dashboard hosted directly on ESP32, avoiding backend processing.

A prior art search on:

• Indian Patent Advanced Search System (InPASS)

• Google Patents

• Espacenet

• WIPO Patentscope

confirms that no known invention or filed patent combines these elements in the same
configuration. Hence, the system satisfies the novelty criterion under Indian patent law.

B. Inventive Step [As per Section 2(1)(ja)] The system incorporates technical
advances in multiple aspects that qualify as an inventive step:

• Trigger-Based Sensor Fusion: Activating sensors only during the window of train
arrival significantly improves efficiency and reduces false positives.

• MAC-layer Communication Architecture: Unlike conventional solutions using Wi-

Fi or GSM (which operate at application or network layers), the use of MAC-layer
transmission is non-obvious and low-latency.

• Dual-Output Interface Design: The architecture delivers alerts both locally (train
driver) and remotely (control room) without cloud computing or backend SCADA
integration.

This approach exceeds standard engineering practices and would not be obvious to a
person skilled in the art of embedded systems, public transportation safety, or automa-
tion. Thus, the proposed design satisfies the requirement for an inventive step under
Section 2(1)(ja).

RV College of Engineering® 2024-25 10

 Sensor Driven Virtual Fencing and Boundary Control

C. Industrial Applicability [As per Section 2(1)(ac)] The invention clearly meets
the requirement of industrial applicability, as it is:

• Technically feasible for deployment at metro platforms

• Cost-effective (10,000–12,000 per segment) compared to mechanical Platform Screen

Doors (8–10 crore/station)

• Capable of functioning in both overground and underground stations

• Able to operate without reliance on external communication infrastructure

These characteristics fulfill the condition of industrial applicability, as laid out under
Section 2(1)(ac) of the Indian Patent Act, 1970.

Component Section Reference Reason

ESP-32, HC-12, Sensors, LCD Section 3(k) These are publicly available,
commercially manufactured
devices already protected under
existing patents.
General ue of sensors for Section 3(c) Considered a discovery or
detection scientific principle
Standalone software dashboards Section 3(m) Considered software per se or a
business method, unless tightly
integrated with novel hardware
logic

Table 1.1: Evaluation Non-Patentable Components

1.4.3 Comparative Analysis with Existing Solutions and Patents

1. Platform Screen Doors (PSDs)

• Used in: Delhi Metro, Mumbai Metro

• Mechanism: Mechanical gates synchronized with train doors

• Cost: 8-10 crore per station

• Patent: PSD mechanisms are patented by OEMs like Hitachi, Mitsubishi, and
Siemens under various international filings (e.g., US7895941B2, JP2008227016A)

• Limitation: High cost, not deployable at older stations

2. AI-Based CCTV Monitoring

RV College of Engineering® 2024-25 11

 Sensor Driven Virtual Fencing and Boundary Control

• Used in: Bengaluru, Chennai, Hyderabad (trial basis)

• Mechanism: Surveillance with image classification and deep learning

• Patent: Existing patents include IN202041003220 and US10474913B2

• Limitation: Requires trained models, 24/7 internet connectivity, vulnerable

to low-light/fog

3. Infrared Sensor-Based Alert Systems

• Used in: Smaller metro systems (pilot phase)

• Patent: IN201721034896 – Detects boundary intrusion using IR beams

• Limitation: No activation logic, no communication to metro operator, limited

to physical detection

4. GSM or Wi-Fi Based Systems

• Common in: European metros with high infrastructure budget

• Patent: Many solutions operate under cloud-based alert mechanisms (e.g.,

US20220175851A1)

• Limitation: Not usable in underground stations without signal; expensive

1.4.4 Conclusion and Justification

The proposed metro platform safety system is not merely a recombination of known
technologies but a thoughtfully engineered solution tailored to a persistent, high-impact
safety issue—unauthorized pedestrian breaches near the platform edge. According to a
2023 report by the Ministry of Housing and Urban Affairs (MoHUA), over 1,700 accidents
occurred across Indian urban rail systems in the past five years due to platform-edge falls
and unauthorized crossings, many of which were preventable with timely warnings and
interventions.
This system’s core innovation lies in its context-sensitive activation, infrastructure-
independent communication, and cost-effective, dual-layer alerting, offering a practical
and scalable solution—especially for the 100+ metro stations across Tier-II and Tier-
III cities where high-cost solutions like Platform Screen Doors (PSDs) are financially
unfeasible.

Compared to existing solutions:

RV College of Engineering® 2024-25 12

 Sensor Driven Virtual Fencing and Boundary Control

• Platform Screen Doors (PSDs): While effective, these systems cost 8–10 crore
per station and are typically reserved for newly designed stations with large budgets.
Many older or lower-footfall stations continue to operate without any edge safety
system.

• AI-Based Camera Monitoring Systems: These setups are expensive (installa-

tion and maintenance exceeding 20–30 lakh per station), require high-quality video
feeds, and depend on cloud infrastructure, increasing operational overhead and vul-
nerability.

• Infrared (IR) Based Safety Systems: While more affordable, these are prone
to false positives, operate independently of train schedules, and provide no real-time
communication with the train or control room.

By contrast, the proposed system can be implemented for under 12,000 per segment,
requires no cloud connectivity, and uses MAC-layer RF communication (via HC-12 mod-
ules) to reliably alert both the train operator and the station control room simultaneously.
These features present a technical advance and economic advantage, fulfilling the dual
criteria required under Section 2(1)(ja) of the Indian Patent Act, 1970 for an inventive
step.

Furthermore, a comprehensive review of InPASS, WIPO Patentscope, and Espacenet

databases has revealed no existing patents or public disclosures that combine the follow-
ing:

• Ultrasonic and FSR sensors integrated with conditional, train-triggered activation

logic,

• RF-based MAC-layer communication (non-IP based) for real-time alert transmis-

sion,

• Dual-output interface design alerting both driver and control room simultaneously.

This confirms the novelty of the invention as per Section 2(1)(j) of the Indian Patent
Act.

RV College of Engineering® 2024-25 13

 Sensor Driven Virtual Fencing and Boundary Control

The solution’s clear use in the metro and public safety domain also qualifies it under
Section 2(1)(ac) for industrial applicability. Beyond metro platforms, the system holds
promise for adaptation in railway stations, bus terminals, and airport shuttle bays where
edge safety is a major concern.

In conclusion, the system:

• Is novel, offering a previously unimplemented combination of logic and technology,

• Represents an inventive step, addressing a real safety gap using non-obvious in-
tegration,

• Is industrially applicable, low-cost, and ready for real-world deployment,

• Does not fall under exclusions listed in Section 3 of the Act when viewed as a
system-level invention.

Given the technical, economic, and social value this system brings, it is strongly
justified for patent protection. A provisional patent filing is recommended as the next
step to safeguard intellectual property before public disclosure or deployment, thereby
ensuring both legal exclusivity and commercial viability in the evolving field of smart
public transport infrastructure.

1.5 Problem statement

Despite advancements in public transportation infrastructure, platform safety in metro
stations remains a vulnerable aspect of operations. Human factors such as distractions,
misjudgments, and deliberate boundary crossing contribute to serious safety breaches.

1.6 Objectives
Primary Objectives
• Design and implement a sensor-based virtual boundary system to monitor platform
edge violations in metro stations.

• Detect unauthorized entry into the restricted zone before train arrival using ultra-
sonic sensors.

• Integrate ESP32 microcontrollers for real-time data capture and alert generation.

RV College of Engineering® 2024-25 14

 Sensor Driven Virtual Fencing and Boundary Control

• Develop a web-based interface that displays real-time sensor data, alerts, and logs
for remote supervision by station operators.

• Ensure the system is cost-effective, scalable, and minimally invasive to station in-
frastructure.

Scope of the Project

• Focused on metro platforms, with potential application in:

– Railway stations

– Airports

– Industrial safety zones

– School campuses

• Designed for plug-and-play installation, reducing retrofitting costs.

• Uses open-source technologies for hardware (ESP32, Arduino C++) and software
(Python, MongoDB, Flask/[Link]).

• Provides modular scalability — multiple ESP32 nodes can be deployed across dif-
ferent sections of a platform and managed via a centralized web interface.

This system has the potential to be integrated with future AI-based crowd detection
and predictive analytics for more advanced public safety solutions.

1.7 Need for Study

Ensuring public safety in crowded transportation environments has never been more
urgent. With increasing ridership in metro systems across India and the world, accident
prevention measures must evolve from passive systems to intelligent, real-time, automated
systems.

• Statistical data from cities like Delhi and Mumbai show that over 40% of platform-
related accidents occur due to people crossing safety lines.

• Human vigilance has limits. One supervisor cannot monitor multiple platforms in
real-time with perfect accuracy.

RV College of Engineering® 2024-25 15

 Sensor Driven Virtual Fencing and Boundary Control

• There’s a gap in cost-effective and easily deployable alternatives to physical barriers.

• No public deployment yet of sensor-based virtual safety systems in Indian metros.

By undertaking this project, we contribute a technological proof-of-concept that

bridges this gap with a working prototype, offering measurable safety benefits.

1.8 Organization of the report

This report is organized as follows. Write the discussions in each chapter. A sample
is as follows.

• Chapter 2 discusses the methodology of this project which involves designing a

sensor-driven virtual boundary system using ESP32 microcontrollers and FSR +
ultrasonic sensors to detect safety line breaches on metro platforms

• Chapter 3 discusses the system architecture which is layered, comprising sensor

nodes (FSR and ultrasonic sensors) interfaced with ESP32 microcontrollers for edge-
level detection.

• Chapter 4 discusses the implementation involving the configuration of ESP32-based

sensor nodes to detect foot pressure and train proximity, using FSR and ultrasonic
sensors respectively

• Chapter 5 discusses the results which demonstrates the sensor-driven virtual bound-
ary system effectively detects platform edge breaches with high accuracy and low
latency in a controlled environment.

• Chapter 6 discusses the development of a cost-effective and scalable sensor-driven

virtual boundary system that enhances metro platform safety by detecting unau-
thorized edge breaches in real time.

RV College of Engineering® 2024-25 16

 Chapter 2
Methodology

Interdisciplinary Project Report 2024-25

 Sensor Driven Virtual Fencing and Boundary Control

CHAPTER 2
METHODOLOGY
The methodology adopted in this project outlines the systematic approach used to
design, develop, and test a sensor-driven virtual fencing system for metro platform safety.
It includes hardware selection, sensor configuration, data acquisition, communication
protocols, and software development. This chapter also details the integration of ESP32
microcontrollers with ultrasonic and IR sensors, as well as the development of a web-
based monitoring dashboard. Emphasis is placed on achieving real-time response, cost-
efficiency, and scalability, making the system suitable for deployment in Indian metro rail
environments.

2.1 Overall Approach

The methodology follows a systematic design and development cycle tailored to build-
ing a sensor-driven virtual fencing system for metro platform safety. The approach in-
tegrates hardware selection, firmware programming, backend infrastructure, communica-
tion protocols, and user interface design, followed by rigorous testing.

Figure 2.1: Methodology

RV College of Engineering® 2024-25 18

 Sensor Driven Virtual Fencing and Boundary Control

Phases
• Requirement Analysis: Define system requirements such as detection accuracy,
latency, power consumption, and scalability.

• Design: Architect the system comprising sensor nodes (ESP32 + sensors), commu-
nication network (MQTT protocol), backend server, and visualization dashboard.

• Implementation: Develop hardware modules, embedded firmware, backend APIs,

and the web dashboard.

• Testing & Validation: Perform unit, integration, and system testing to validate
performance against KPIs.

• Deployment & Feedback: Deploy pilot units at selected metro platforms, collect
real-world data, and refine the system iteratively.

2.2 Hardware Design and Selection

Key considerations for hardware design included cost, reliability, ease of integration,
and environmental robustness.

(a) ESP-32 (b) Ultrasonic Sensor

Figure 2.2: Hardware Components

• Microcontroller: ESP32 was selected due to its integrated Wi-Fi/Bluetooth ca-

pabilities, sufficient processing power, low cost, and wide community support.

• Sensors:

RV College of Engineering® 2024-25 19

 Sensor Driven Virtual Fencing and Boundary Control

(a) FSR Sensor (b) Buzzer

Figure 2.3: Hardware Components

– Ultrasonic Sensors (HC-SR04): Used for distance measurement to detect

intrusion beyond platform boundaries.

– FSR Sensor: The FSR sensor detects pressure near restricted areas like
platform edges. When someone steps on the sensor, it sends a signal to the
controller, triggering alerts such as lights or buzzers. This helps prevent unsafe
movement and improves passenger safety.

• Power Supply: Depending on deployment conditions, the system supports either:

– Mains-powered units with regulated DC supply, or

– Battery-powered units with energy harvesting modules for sustainability.

• Additional Components: Includes level shifters, reliable connectors, and enclo-

sures rated for metro environmental conditions such as dust, moisture, and vibra-
tion.

• PCB Design: A custom PCB integrates the ESP32, sensors, power regulation
circuit, and interface connectors to ensure ease of installation and operational dura-
bility.

2.3 Backend and API Design

The backend infrastructure is built around RESTful API endpoints that receive and
process real-time alerts sent by the ESP32 sensor node. Instead of relying on MQTT

RV College of Engineering® 2024-25 20

 Sensor Driven Virtual Fencing and Boundary Control

or broker-based systems, the ESP32 transmits structured JSON data directly through
HTTP API routes over Wi-Fi to a cloud-based server.

• Data Ingestion API: The ESP32 transmits alert packets to a /log breach end-
point. Each packet contains the sensor ID, timestamp, system state (active/inac-
tive), and breach status.

• Query APIs for Dashboards: The operator and pilot dashboards retrieve live
data through endpoints such as /live status, /get alerts, and /system health,
allowing low-latency visualization of system events.

• Incident Logging and Analytics: Breaches marked as red alerts are automati-
cally logged into a database with metadata for future reference. This data is visu-
alized in the dashboard and structured for potential use in future machine learning
models.

• PDF Export Feature: The backend includes an export endpoint, /export pdf,
which generates downloadable incident reports containing alert logs and system
performance analytics.

• Authentication and Security: All API endpoints are protected via token-based
authentication using JSON Web Tokens (JWT), ensuring only authorized systems
and users can access sensitive data.

2.4 Web Dashboard and Visualization

The system features two distinct dashboards designed for different user roles: the
Operator Dashboard for the control room and the Pilot Dashboard for the metro train
driver. Both dashboards are connected to the backend through defined API routes,
enabling real-time data visualization and alert-based decision support

RV College of Engineering® 2024-25 21

 Sensor Driven Virtual Fencing and Boundary Control

Operator Dashboard
The Operator Dashboard is web-based and optimized for continuous supervision at
the metro control center. It provides the following functionalities:

• Live System Status: Real-time breach status, sensor node health, and activation
state are displayed for every connected node.

• System Health Monitoring: Displays connectivity status, last communication

timestamp, and potential hardware faults for each ESP32 sensor node.

• Alert Logs and Quick Stats: All red alerts are recorded with timestamp, sensor
ID, and location information. Summary statistics are shown for daily, weekly, and
monthly trends.

• Analytics Dashboard: Breach frequency is visualized through line charts, pie

charts, and bar graphs. Data can be filtered based on time, location, and alert
category.

• Exportable Reports: The dashboard provides an option to generate and down-

load breach logs and visual analytics in PDF format. These can be archived for
compliance, audit, or future machine learning analysis.

Pilot Dashboard
The Pilot Dashboard is a lightweight interface connected directly to the receiver
ESP32 on the metro train. It provides critical safety alerts to the driver with mini-
mal latency.

• Real-Time Breach Notifications: Displays current system status, breach detec-

tion alerts, and timestamps.

RV College of Engineering® 2024-25 22

 Sensor Driven Virtual Fencing and Boundary Control

• Decision Suggestions: For high-risk alerts (e.g., red status), the system pro-
vides actionable suggestions such as “Reduce speed immediately” or “Stop at next
marker” based on predefined alert categories.

• Wireless Connectivity: Maintains a stable connection with the station-side

ESP32 from a distance of up to 200 meters.

• Minimalist Design: The interface is designed for quick glanceability with simple
icons and text. Only essential information is displayed to avoid cognitive overload.

• Auto-Deactivation Logic: When the train is parked on the platform, the system
automatically disables alerts to prevent false positives.

2.5 Communication Protocol and Security

Ensuring robust and secure communication between sensor nodes and backend servers
is critical for a safety system deployed in a public metro environment.

• MQTT Protocol:
The system utilizes the MQTT (Message Queuing Telemetry Transport) protocol,
chosen for its lightweight footprint, minimal bandwidth consumption, and support
for a publish/subscribe communication model. This architecture allows sensors to
publish alert messages asynchronously, while backend subscribers process these in
near real-time, enabling scalable many-to-many communication.

• Security Measures:

– TLS Encryption: All MQTT messages are transmitted over Transport Layer
Security (TLS) to encrypt data in transit, preventing eavesdropping or tam-
pering by malicious actors.

– Client Authentication: MQTT clients (sensor nodes) authenticate using

unique username/password credentials to prevent unauthorized device access.

RV College of Engineering® 2024-25 23

 Sensor Driven Virtual Fencing and Boundary Control

– API Security: Backend RESTful APIs and WebSocket endpoints are secured
via HTTPS, and user access is managed using JSON Web Tokens (JWT),
ensuring that only authorized personnel can view or manipulate system data.

– Regular Audits: The system undergoes periodic security audits and pene-
tration testing to identify and mitigate vulnerabilities proactively.

• Network Reliability Considerations:

Given the complex physical environment of metro stations, which can include sig-
nal interference and architectural obstacles, the system implements Wi-Fi mesh
networking or uses strategically placed repeaters to maintain stable, low-latency
connectivity between sensor nodes and the backend infrastructure. This redun-
dancy helps avoid data loss or delays in alert transmission.

2.6 Testing and Validation Strategy

The testing strategy ensures the system is reliable, accurate, and ready for deployment
in the demanding metro environment.

• Unit Testing:
Each individual component—sensor hardware modules, embedded firmware func-
tions, communication interfaces—is rigorously tested in controlled laboratory set-
tings. This helps identify hardware defects or software bugs early in development.

• Integration Testing:
After unit testing, sensor nodes are tested end-to-end with the MQTT broker and
backend servers to validate the entire data flow pipeline. This step confirms that
sensor events correctly trigger backend alerts and that data storage and API re-
sponses function as intended.

• Field Testing:
Prototypes are installed at select metro platforms to validate system performance
in real-world conditions. Field testing includes:

– Performance Monitoring: Measurement of key metrics such as detection

accuracy (correct breach identification), alert latency (time from intrusion to
notification), and false alarm rates.

RV College of Engineering® 2024-25 24

 Sensor Driven Virtual Fencing and Boundary Control

– Environmental Challenges: Assessing system robustness under high pas-

senger density, fluctuating lighting conditions (day/night, shadow), tempera-
ture variations, and electromagnetic interference common in metro settings.

• User Acceptance Testing (UAT):

Metro control operators participate in usability testing to evaluate the dashboard’s
interface, alert management workflows, and overall system responsiveness. Their
feedback guides refinements to improve operational effectiveness and user satisfac-
tion.

• Continuous Performance Evaluation:

Performance metrics gathered during testing are continuously monitored and com-
pared against previously defined Key Performance Indicators (KPIs). This ongoing
evaluation drives iterative improvements in hardware calibration, firmware logic,
communication reliability, and user interface design to optimize system safety out-
comes.

RV College of Engineering® 2024-25 25

 Chapter 3
System Architecture

Interdisciplinary Project Report 2024-25

 Sensor Driven Virtual Fencing and Boundary Control

CHAPTER 3
SYSTEM ARCHITECTURE
The proposed Sensor-Driven Virtual Boundary System is an embedded wireless safety
solution developed for metro platforms. It is designed to identify when a passenger
breaches the yellow safety line and to relay this information to both the control room
and the approaching metro train. The architecture is based entirely on ESP32 microcon-
trollers, which operate in a distributed manner and communicate via MAC-layer protocols
without the need for external Wi-Fi infrastructure.
The system integrates two sensors: a Force Sensitive Resistor (FSR) sensor for breach
detection and an ultrasonic sensor for detecting metro approach, which is used to activate
or deactivate the system dynamically. The sensor node is responsible for breach mon-
itoring, while the receiver node interprets the data and sends alerts to the appropriate
outputs.

3.1 Layered Architecture

Figure 3.1: System Architecture

The architecture is organized into six functional layers. Each layer is logically decou-

RV College of Engineering® 2024-25 27

 Sensor Driven Virtual Fencing and Boundary Control

pled from the others to allow independent testing, debugging, and future scalability.

System Architecture
The proposed metro platform safety system is composed of six functional layers, orga-
nized to facilitate modularity, real-time responsiveness, and dual-role visualization. This
architecture enables simultaneous monitoring at both the metro control room and the
driver’s cabin through separate dashboards.

1. Sensor Layer: Includes the Force Sensitive Resistor (FSR) to detect pressure-
based breaches and an ultrasonic sensor to detect train proximity. When the train
is approaching, the system activates. Once the train is parked, the system is auto-
matically disabled to prevent false alerts.

2. Processing Layer: Implemented on the ESP32 microcontroller, this layer handles

analog signal acquisition, digital filtering, threshold evaluation, and logic control.
Conditional logic ensures that alerts are only generated under valid operational
conditions.

3. Communication Layer: The sensor node sends structured JSON data through
HTTP-based API routes to the backend server. These API routes include endpoints
for breach logging, system health reporting, and dashboard queries. Communication
is secured using token-based authentication.

4. Aggregation and Decision Layer: At the backend, incoming data is parsed,

stored, and processed for real-time visualization. Alert classification logic deter-
mines the appropriate system status (green, yellow, red) and triggers relevant sug-
gestions.

5. Output Interface Layer: The system routes alerts to two separate interfaces:

• Operator Dashboard: Displays live system health, alert logs, analytics, and
provides a downloadable report of incidents in PDF format.

• Pilot Dashboard: Wirelessly connected to the train-side ESP32, it shows

real-time status and provides context-based suggestions such as “Reduce speed
immediately” in case of a red alert.

RV College of Engineering® 2024-25 28

 Sensor Driven Virtual Fencing and Boundary Control

6. Monitoring and Logging Layer: A central database stores all logged events,
alert categories, and system uptime statistics. These are used for dashboard ana-
lytics and can later be leveraged for machine learning-based incident prediction.

Data Flow Model

The updated system follows an event-driven data flow model with structured, low-
latency communication from the sensor node to the backend server and dashboards. The
data flow ensures simultaneous alert delivery to both the operator and pilot while enabling
logging and analytics.

1. System Initialization: Both ESP32 modules (sensor-side and receiver-side) are

powered on. GPIOs are configured, and MAC pairing or network connectivity is
established.

2. Activation Check: The ultrasonic sensor checks for an approaching train. If the
train is within a defined range, the system is activated. If the train is already
stationed, the system disables breach detection to prevent false alerts.

3. Breach Detection: The FSR sensor continuously monitors pressure near the yel-
low safety line. If the pressure exceeds a calibrated threshold for a defined duration,
a breach is confirmed.

4. Data Packet Creation: Upon breach detection, the ESP32 creates a structured
JSON packet containing:

• Sensor ID

• Timestamp

• Breach status (True/False)

• System state (Active/Inactive)

5. Data Transmission via API: The data packet is sent to a predefined RESTful
API endpoint (e.g., /log breach) hosted on the backend server. API requests are
authenticated using secure tokens.

RV College of Engineering® 2024-25 29

 Sensor Driven Virtual Fencing and Boundary Control

6. Backend Processing: The backend validates and logs the data, classifies the alert
(Green, Yellow, or Red), and triggers appropriate actions for the dashboards. For
red alerts, contextual suggestions are generated for the pilot.

7. Dashboard Display:

• Operator Dashboard: Displays live alert status, system health, quick stats,
breach history, and analytics charts. Red alert logs are available for PDF
export.

• Pilot Dashboard: Displays real-time status and shows dynamic suggestions

such as “Reduce speed immediately” in case of critical alerts. Connects directly
to station ESP from up to 200 meters.

3.2 Circuit Diagram

The metro safety system is built around the ESP32 development board, a highly capa-
ble microcontroller that supports both wireless communication and multiple input/output
interfaces. The entire system is divided into two main modules—Transmitter Node and
Receiver Node—each with a specific configuration of sensors and output devices. Below
is a comprehensive explanation of both.

Figure 3.2: Transmitter

3.2.1 Transmitter Circuit (Sensor Node)

The transmitter module is designed to continuously monitor activity on the plat-
form and communicate safety breaches to the receiver end. It consists of the following

RV College of Engineering® 2024-25 30

 Sensor Driven Virtual Fencing and Boundary Control

components:

• ESP32 Development Board

• HC-SR04 Ultrasonic Sensor

• Force Sensitive Resistor (FSR)

• Piezoelectric Buzzer

Connections:

• HC-SR04 Ultrasonic Sensor:

– VCC (Power) → 5V on ESP32

– GND → GND on ESP32

– Trigger Pin → GPIO 26

– Echo Pin → GPIO 25

• FSR Sensor (placed along the yellow line):

– One terminal → 3.3V

– Other terminal → Analog pin (A0 or similar) and through a pull-down resistor
to GND

• Piezoelectric Buzzer:

– VCC → GPIO 27

– GND → GND

This sensor node actively collects real-time data and transmits breach alerts wire-
lessly to the receiver node using an ESP32-based communication protocol (MAC-layer
communication through the HC-12 module or built-in ESP-NOW/WiFi if adapted).

3.2.2 System Integration

The two nodes operate synchronously:

• The transmitter continuously monitors sensor input.

RV College of Engineering® 2024-25 31

 Sensor Driven Virtual Fencing and Boundary Control

• If an approaching train is detected (via ultrasonic sensor), the system is activated.

• If force is detected on the yellow line, the breach signal is transmitted.

• The receiver node displays the message and triggers the buzzer alert.

This distributed system design ensures both local safety (platform-side alerts) and
operational safety (train-side visibility and remote monitoring).

3.2.3 Safety and Power Considerations

• All components operate at either 3.3V or 5V, which are within the ESP32’s IO
limits.

• Power is supplied via USB or a regulated 5V external source.

• Pull-down resistors and debounce logic are integrated into the final PCB layout to
ensure sensor stability and reduce false triggers.

3.3 Sequence of Operation

A typical system run progresses through the following sequence:

1. System Start-Up
• ESP32 modules are initialized.

• MAC-level pairing is established.

2. Activation State Check

• Ultrasonic sensor determines system status.

• System enters active mode only if the train is not present.

3. Monitoring Loop
• FSR sensor begins polling for foot pressure.

• Breach is detected if pressure threshold is exceeded for ≥ 1 second.

4. Breach Event Transmission

• A structured data packet is formed and transmitted wirelessly to the receiver node.

RV College of Engineering® 2024-25 32

 Sensor Driven Virtual Fencing and Boundary Control

5. Alert Triggered
• Receiver ESP32 sends output to:

– LCD screen on the metro train

– Simulated control room dashboard interface

6. Reset Loop
• System resets the breach flag once pressure is removed.

• It then resumes the polling cycle for continuous operation.

RV College of Engineering® 2024-25 33

 Chapter 4
Implementation

Interdisciplinary Project Report 2024-25

 Sensor Driven Virtual Fencing and Boundary Control

CHAPTER 4
IMPLEMENTATION
This section outlines the detailed process used to implement the Sensor-Driven Vir-
tual Boundary System. The implementation integrates sensor hardware, embedded logic
programming, inter-device wireless communication, user interface design, and dashboard
visualization. The system was developed through iterative prototyping, with individual
components tested in isolation before being integrated into a fully functional module.
The implementation is divided into four main components: the sensor node, the receiver
node, the alert and display system, and the web interface.

4.1 Hardware Setup

4.1.1 Microcontroller: ESP32
• ESP32 DEVKIT V1 modules were used for both the sensor and receiver units.

• Chosen for its dual-core processor, integrated Wi-Fi and Bluetooth, GPIO flexibil-
ity, and support for MAC-based device-to-device communication.

• Operates on 3.3V logic with support for analog and digital I/O.

4.1.2 Sensors
FSR Sensor (Force Sensitive Resistor):

• Mounted flush with the surface of the yellow safety line region.

• Resistance decreases with applied pressure.

• Connected to an analog pin of the ESP32 for continuous monitoring.

• Calibrated to trigger a breach above a specific pressure value (typically simulating

a footstep).

Ultrasonic Sensor (HC-SR04):

• Placed at an elevated position on the platform wall, facing the tracks.

• Measures the distance to detect the presence of an incoming train.

• If a train is detected within a predefined range (e.g., 100 cm), the system is disabled
temporarily.

RV College of Engineering® 2024-25 35

 Sensor Driven Virtual Fencing and Boundary Control

4.2 Sensor Node Implementation

The sensor node ESP32 is responsible for data collection, breach detection logic, and
wireless transmission.
Key Functional Steps:

1. Sensor Polling:

• Analog voltage from the FSR is read continuously.

• The ultrasonic sensor triggers a distance check at regular intervals (e.g., every
500 ms).

2. System Activation Logic:

• If the ultrasonic sensor reports no train within proximity, the system is con-
sidered “active.”

• Breach detection is only processed when the system is active.

3. Breach Detection:

• FSR values are averaged over a short time window (e.g., 5 readings).

• If the average exceeds the calibrated threshold and is sustained for more than
1 second, a breach is flagged.

4. Data Packet Creation:

• A JSON-like data packet is structured with:

– sensor id

– breach status (true/false)

– system state (active/inactive)

– timestamp (optional)

5. Wireless Transmission:

• The packet is sent via ESP32 MAC-layer protocol (e.g., ESP-NOW) to the
receiver node using its unique MAC address.

• Transmissions are attempted every 100–300 ms during active breach detection.

RV College of Engineering® 2024-25 36

 Sensor Driven Virtual Fencing and Boundary Control

4.3 Receiver Node Implementation

The receiver ESP32 receives data from one or more sensor nodes and acts upon vali-
dated breach events.
Responsibilities:

• Initialize MAC Communication:

– Registers the MAC address of all paired sensor ESP32 devices.

– Starts listening for incoming breach packets.

• Parse and Validate Packets:

– Checks the structure and content of the received packet.

– Verifies if the system is currently active.

– Filters out duplicate or inconsistent data.

• Display Management:

– When a valid breach is received, the connected LCD screen is updated with
an alert message: “Passenger Breach Detected. Proceed with Caution.”

– The message remains visible until the breach is cleared or overwritten.

• Optional Serial Output:

– The receiver ESP32 is optionally connected via USB to a laptop or PC.

– Breach logs can be monitored live through a serial terminal (e.g., Arduino
Serial Monitor or PuTTY).

4.4 Web Interface and Dashboard

The system features a dual-dashboard web interface: the Operator Dashboard for con-
trol room personnel and the Pilot Dashboard for metro train drivers. Both dashboards
are powered by real-time data obtained from the ESP32 via secure API routes

RV College of Engineering® 2024-25 37

 Sensor Driven Virtual Fencing and Boundary Control

Figure 4.1: Operator Dashboard

Operator Dashboard
The Operator Dashboard is a full-featured web interface designed for monitoring plat-
form safety status and breach patterns.

• Live Status View: Displays the current state (active/inactive) of each sensor
node, breach detection flags, and system health indicators.

• System Health Monitoring: Shows node connectivity, last update timestamp,

and sensor uptime status.

• Breach Logging: Automatically logs all red alerts with sensor ID, timestamp,
and system condition. Alerts are stored in a central database.

• Analytics Visualization: Breach patterns are shown using bar graphs, pie charts,
and time-series plots. Users can filter by time intervals or sensor locations.

• PDF Report Export: Provides the ability to generate downloadable PDF reports
containing red alert logs and analytics, intended for future audits or integration with
machine learning workflows.

The dashboard is developed using HTML, JavaScript ([Link]), and interacts with a
Flask or [Link] backend via RESTful APIs
The dashboard is connected to the receiver ESP32 either directly (via USB serial
port) or indirectly (via Wi-Fi or future Ethernet connectivity).

RV College of Engineering® 2024-25 38

 Sensor Driven Virtual Fencing and Boundary Control

Figure 4.2: Red Alert Acknowledgement

Pilot Dashboard

Figure 4.3: Pilot Dashboard

The Pilot Dashboard is a lightweight interface directly connected to the ESP32 on

the train. It is designed to convey essential alerts with minimal latency and distraction.

• Real-Time Breach Alerts: Displays immediate breach warnings as received from

the station ESP32 module.

• Contextual Suggestions: In the case of red alerts, the system provides actionable
feedback such as “Reduce speed immediately” to enhance operator response.

• Wireless Connectivity: Communicates with the station-side ESP32 from up to

200 meters using peer-to-peer communication or Wi-Fi.

RV College of Engineering® 2024-25 39

 Sensor Driven Virtual Fencing and Boundary Control

Figure 4.4: Red Alert

• Minimal UI: Contains only essential elements such as status indicators and mes-
sage prompts to reduce cognitive load.

• Auto-Disable Function: When the train is parked at the platform, the dashboard
suppresses new alerts by disabling the input from the station node.

(a) ESP Connected (b) ESP Disabled

4.5 Calibration and Testing

FSR Sensor Calibration:

• Conducted using varying pressure inputs (e.g., foot pressure, bag drop).

• Voltage thresholds were recorded and fine-tuned to detect footstep-like inputs.

• Setpoint value chosen based on average adult foot pressure.

Ultrasonic Sensor Calibration:

• Platform clearance range was measured under different lighting and noise condi-
tions.

RV College of Engineering® 2024-25 40

 Sensor Driven Virtual Fencing and Boundary Control

• Train presence detection tuned to approximately 100–120 cm with error tolerance

of ±5 cm.

Breach Simulation Testing:

• Multiple breach events were simulated with varying conditions:

– Active system, foot pressure applied.

– Deactivated system (train present), pressure applied.

– Brief, light pressure (to test false positive filtering).

Outcome:

• System accurately detected and transmitted over 95% of valid breach cases.

• No alerts were triggered when the metro was detected within range.

• LCD alerts were delivered with negligible latency (approximately 100 ms average).

4.6 Integration Summary

The sensor node, receiver node, and dashboard system were implemented as indepen-
dently functioning subsystems and then integrated in a three-phase approach:

1. Phase 1 – Sensor Hardware Integration:

FSR and ultrasonic sensors were calibrated, interfaced with ESP32, and tested for
stability.

2. Phase 2 – Communication Protocol Testing:

ESP32-to-ESP32 MAC communication was implemented and tested with multiple
message types.

3. Phase 3 – End-to-End System Integration:

Full breach detection cycle connected to LCD display and dashboard logging. Final
testing ensured synchronization and reliability.

RV College of Engineering® 2024-25 41

 Chapter 5
Results & Discussions

Interdisciplinary Project Report 2024-25

 Sensor Driven Virtual Fencing and Boundary Control

CHAPTER 5
RESULTS & DISCUSSIONS
This section presents the performance evaluation of the proposed Sensor-Driven Vir-
tual Boundary System, as tested on a scaled-down prototype simulating a metro platform.
The objective of the testing was to verify the functionality of the core modules—sensor de-
tection, system activation logic, inter-device communication, and alert generation—under
controlled conditions. The results are based on repeated breach simulations, manual prox-
imity control, and communication verification using a lab-scale mock-up model. All find-
ings are preliminary and serve to validate the working of the prototype prior to field-scale
deployment.

5.1 Experimental Setup

The tests were conducted using a physical model replicating a metro platform on a
reduced scale. The setup included:

• A wooden platform mock-up approximately 1.5 meters long.

• An FSR sensor mounted near the yellow line.

• An ultrasonic sensor fixed on the edge, facing outward to detect an approaching

“train” simulated using a cardboard or acrylic block.

• Two ESP32 microcontrollers: one acting as the sensor node, the other as the receiver
node.

• A 16x2 LCD screen acting as the alert display.

• Breach events simulated by pressing on the FSR sensor using foot or object pressure.

• Train approach simulated by moving a large object within the range of the ultrasonic
sensor.

5.2 Functional Verification: Breach Detection

The FSR sensor was calibrated to detect pressure values that mimic a footstep. Breach
events were simulated 25 times by applying sustained pressure (greater than 1 second)
on the FSR sensor.
Observed Outcome:

RV College of Engineering® 2024-25 43

 Sensor Driven Virtual Fencing and Boundary Control

• Correct breach detections: 24

• Missed detections: 1

• False triggers (no pressure): 0

• Detection Accuracy: 96%

Although testing was conducted on a limited scale, the sensor reliably differentiated
between intentional and accidental inputs. The single missed detection was due to off-
center pressure not sufficiently activating the sensor’s threshold.

Test No. Person Steps on Yellow Line FSR Sensor Value LCD Output Buzzer Result
1 Yes 1279 Boundary Breach On Pass
2 Yes 1134 Boundary Breach On Pass
3 Yes 245 No Display Off Pass
4 Yes 778 Boundary Breach On Pass
5 No 0 No Display Off Pass

Table 5.1: Results

5.3 Activation/Deactivation Logic: Train Simulation

The ultrasonic sensor was configured to deactivate the system when a simulated object
entered a range of 100–120 cm. This ensured that breach detection was temporarily
suspended when a “train” was present.

Figure 5.1: ESP Connected

Key Observations:

• System successfully deactivated within 400–500 ms of simulated train detection.

RV College of Engineering® 2024-25 44

 Sensor Driven Virtual Fencing and Boundary Control

Figure 5.2: ESP Disabled

• Reactivation occurred automatically when the object moved out of range.

• No breach alerts were generated during deactivation phase.

• Deactivation behavior was consistent across 10 trials.

While the platform model was limited in spatial resolution, the ultrasonic logic be-
haved as expected within the simulation constraints.

5.4 Communication and Latency Evaluation

The system’s performance was evaluated in terms of communication reliability and
latency between the sensor node, backend server, and both dashboards.

ESP32 to Backend Communication

Breach data was transmitted via HTTP POST requests to predefined API routes
hosted on a local server. The JSON payload included the sensor ID, breach status,
system state, and timestamp.

• Transmission Success Rate: 100% (25 out of 25 events delivered successfully)

• Average API Response Time: 112 ms

• Maximum Observed Latency: 189 ms

• Packet Loss: None observed during controlled lab testing

RV College of Engineering® 2024-25 45

 Sensor Driven Virtual Fencing and Boundary Control

Dashboard Responsiveness
Once breach data reached the backend, it was immediately pushed to the frontend
dashboards using dynamic API polling.

• Operator Dashboard: Reflected updated system status within an average of

200–300 ms after breach detection.

• Pilot Dashboard: Received updated alert messages within 100–150 ms of the

event. For red alerts, the dashboard displayed pre-programmed suggestions such as
“Reduce speed immediately”.

• Consistency: All dashboard events were synchronized across repeated trials with
negligible lag or delay.

These results confirm that the system meets the responsiveness requirements for real-
time safety alerting in metro platform environments.

5.5 Display Behavior and Responsiveness

The receiver ESP32 updated a connected LCD display to show the breach alert when
valid data was received. The message “Boundary Breach Detected” was triggered imme-
diately and cleared when the breach resolved.
Display Findings:

• Trigger time: Approximately 110–130 ms post breach

• Display consistency: Message correctly appeared and disappeared in all trials

• No observed glitches, freezes, or miscommunication during display updates

This confirms that the system provides timely and visible alerts, even in a scaled
environment.

5.6 Prototype Limitations and Scope

Given that the tests were performed on a non-functional, reduced-scale model of a
metro platform, several limitations exist:

• No actual human traffic, environmental noise, or train-induced vibration was present

• Platform geometry was constrained, limiting multi-zone testing

RV College of Engineering® 2024-25 46

 Sensor Driven Virtual Fencing and Boundary Control

• Controlled lighting and absence of electromagnetic interference created ideal con-

ditions, which may differ from real-world operation

• All events simulated manually, limiting the variability found in field conditions

Despite these constraints, the mock-up was sufficient to demonstrate core functional-
ity, logical sequencing, and end-to-end system communication.

5.7 Analytics & Incident Logging Module

A core feature of the Metro Safety Control System is its integrated analytics and
automated incident logging module. This component transforms raw sensor data into
actionable insights for both real-time monitoring and long-term safety planning.

5.7.1 Event Classification and Logging

Every system status change is automatically recorded by the backend. The system
classifies events into three categories based on the severity:

• Green: Safe condition, no breach.

• Yellow: Warning level; preliminary deviation detected.

• Red: Critical breach; immediate action required.

Each event is timestamped and associated with sensor metrics such as FSR values and
distance measurements. Events are stored in a structured database and can be exported
in CSV or PDF format.

5.7.2 Dashboard Visualizations

The Operator Dashboard visualizes historical trends and current incident distributions
through intuitive charts:

• Status Distribution Chart: A donut chart showing the ratio of green, yellow,
and red alerts across the system.

• Risk Gauge: A red-weighted donut gauge indicating the system’s current safety
risk level.

• Trend Analysis Line Chart: Displays alert frequency across 24 hours to identify
high-risk time windows.

RV College of Engineering® 2024-25 47

 Sensor Driven Virtual Fencing and Boundary Control

• Anomaly Detection Scatter Plot: Plots Force Sensor values against distance
to flag outliers for operator review.

5.7.3 Incident Report Generation

(a) Incident Logging (b) Report

Figure 5.3: Incident Logging and Report

The system includes a built-in reporting engine that compiles:

• Executive Summary (current status, total events, alert breakdown)

• Visual analytics from the dashboard

• Detailed incident logs with timestamp, sensor readings, and auto/manual log labels

Reports are exported in PDF format with auto-generated metadata and system brand-
ing. These are suitable for compliance, audits, or post-incident analysis.

5.7.4 Manual Logging and Export Features

In addition to auto-logging from ESP nodes, the Operator Dashboard includes a
manual incident logging option. This allows users to enter contextual notes or categorize
ambiguous events. All logs can be exported in bulk via a one-click CSV download.

RV College of Engineering® 2024-25 48

 Sensor Driven Virtual Fencing and Boundary Control

(a) Analytics Graph (b) Analytics Chart

Figure 5.4: Analytics Graph and Chart

RV College of Engineering® 2024-25 49

 Chapter 6
Conclusion and Future Scope

Interdisciplinary Project Report 2024-25

 Sensor Driven Virtual Fencing and Boundary Control

CHAPTER 6
CONCLUSION AND FUTURE SCOPE
This project aimed to design, implement, and evaluate a sensor-driven virtual bound-
ary system to enhance passenger safety on metro platforms. Through the integration
of embedded sensing, edge-level decision logic, and direct wireless communication, the
system successfully demonstrated its ability to detect safety breaches and alert relevant
stakeholders in real time.
The prototype, constructed on a sun board-based scaled model of a metro platform, vali-
dated the core functionality of the system. The FSR sensor reliably detected unauthorized
pressure across the yellow line, while the ultrasonic sensor dynamically controlled the ac-
tivation state of the system based on train proximity. The use of ESP32 microcontrollers
enabled low-latency MAC-layer communication between sensor and receiver nodes, with
zero data loss observed under test conditions. Breach alerts were successfully displayed
on an LCD screen intended for metro operator visibility and simultaneously logged via
serial output for control room integration.

6.1 Conclusion
While all testing was conducted under controlled conditions on a scaled mock-up, the
results confirm the system’s architectural soundness and operational readiness for further
development. The layered and modular design ensures that each component—sensors,
microcontrollers, communication protocol, and output interfaces—can be independently
scaled, improved, or replaced without affecting the system as a whole.
The successful implementation of this prototype lays the groundwork for future field
trials in real metro environments. With additional enhancements in sensor ruggedization,
multi-zone coordination, and control room dashboard development, this system has strong
potential to contribute to safety infrastructure in urban transportation networks.

6.2 Discussion
The development and testing of the Sensor-Driven Virtual Boundary System, as im-
plemented on a small-scale sun board mock-up, offer meaningful insights into the viability,
functionality, and limitations of the proposed safety solution. Although full-scale deploy-
ment on an operational metro platform has not yet occurred, the prototype’s performance
under simulated conditions enables critical evaluation of its architectural design, embed-

RV College of Engineering® 2024-25 51

 Sensor Driven Virtual Fencing and Boundary Control

ded logic, and communication strategy.

6.3 Validation of Core Functionality

Testing on the prototype confirmed that the system fulfills its primary objective: to
detect unauthorized boundary breaches and relay alerts in real time. The FSR sensor,
responsible for detecting pressure across the yellow line, demonstrated high detection ac-
curacy (96%), especially when supported by temporal filtering and threshold calibration.
Breach detection occurred consistently and was unaffected by minor noise or accidental
contact, validating the sensor logic implemented on the ESP32 microcontroller.
Similarly, the ultrasonic sensor provided reliable activation control by detecting the pres-
ence of a “train” object in the mock-up. When the platform was deemed active (i.e.,
no train detected), breach events were processed and transmitted. When deactivated,
the system correctly suppressed breach signals, showing logical isolation between train
movement and passenger breaches.

6.4 System Integration and Reliability

All subsystems—including sensing, decision logic, wireless communication, and output
triggering—integrated seamlessly into a unified process. The system operated continu-
ously over the duration of testing without requiring manual resets or encountering runtime
errors. The modular nature of the ESP32 implementation allows easy reprogramming,
node expansion, and future integration of additional features such as cloud connectivity
or multi-platform synchronization.
Despite being limited to a sun board-based prototype, the integration quality and sub-
system coordination suggest that the underlying architecture is mature and well-suited
for physical scaling.

6.5 Prototype Limitations

It is important to contextualize the results by acknowledging the limitations of the
current implementation:

1. Scale and Materials: The prototype platform was constructed from sun board
and tested in an indoor, low-interference setting. Material properties, sensor mount-
ing techniques, and surface reflections may differ significantly on actual metro plat-
forms.

RV College of Engineering® 2024-25 52

 Sensor Driven Virtual Fencing and Boundary Control

2. Simulated Inputs: Breach and train presence were simulated manually. In real
deployment, input variability due to crowd density, environmental noise, or object
shape could affect sensor accuracy.

3. Environmental Stability: Testing did not account for dust, temperature varia-
tion, electromagnetic interference, or vibration—factors common in urban rail en-
vironments.

4. Limited Sensor Zones: The prototype monitored only a single zone. A full
system would require multiple synchronized sensor nodes operating across tens of
meters, necessitating more rigorous timing and collision handling protocols.

6.6 Implications for Full-Scale Deployment

The successful demonstration of core functionality in the prototype has several impli-
cations for scaling the system to a real metro platform:
• Scalability: The ESP32’s low power and addressable architecture supports expansion
to multiple zones.
• Infrastructure Independence: The MAC-layer protocol eliminates dependency on metro
Wi-Fi networks.
• Dual Notification Model: Alerts to both train and control room enable shared situa-
tional awareness.
• Data Logging Potential: With minimal modifications, event data can be logged for
auditing, analytics, or machine learning-based risk mapping.

6.7 Recommendations for Further Development

To prepare the system for real-world deployment, the following enhancements are
recommended:
1. Environmental Testing: Field testing under metro-like noise, dust, and passenger
movement conditions.
2. Ruggedization: Enclosure of sensors and boards in weatherproof, tamper-resistant
casings.
3. Sensor Array Expansion: Implementing multi-zone FSR arrays to capture wider breach
areas.
4. Dashboard Finalization: Completion of control room interface with filtering, graphing,

RV College of Engineering® 2024-25 53

 Sensor Driven Virtual Fencing and Boundary Control

and health status modules.

5. Power Optimization: Use of sleep modes, battery backups, or energy harvesting for
sustainable operation.

6.8 Future Work

While the prototype successfully demonstrates the feasibility of the Sensor-Driven Vir-
tual Boundary System in a simulated environment, several areas have been identified for
further development and enhancement to prepare the system for real-world deployment
on metro platforms.

6.9 Full-Scale Deployment and Field Trials

The most critical next step is transitioning from the sun board-based model to an ac-
tual metro platform for pilot implementation. This will allow the system to be evaluated
under real operational conditions involving:
• Live passenger movement
• Environmental variability (dust, vibration, lighting)
• Train-generated interference
• Crowding and obstruction scenarios

Pilot-scale deployment will also allow for feedback from metro staff and operational
teams to refine the system’s usability and responsiveness.

6.10 Environmental Durability and Casing

The sensors and ESP32 modules will require weatherproof, tamper-resistant casings
for outdoor use. This includes:
• IP-rated enclosures for dust and water protection
• Anti-vandal mounting strategies
• Shielding against electromagnetic interference from metro signaling systems

Durability under temperature fluctuations and mechanical stress will also be tested.

6.11 Multi-Zone and Multi-Node Integration

To support longer platforms and broader coverage, the system must be extended to
include multiple sensor nodes operating in parallel. Key goals include:

RV College of Engineering® 2024-25 54

 Sensor Driven Virtual Fencing and Boundary Control

• Assigning unique IDs to each zone-specific sensor node

• Aggregating signals at the receiver node and resolving multiple simultaneous breaches
• Developing collision-avoidance logic and scheduling protocols for MAC-layer communi-
cation
• Synchronizing event logs across multiple receivers (if deployed)

6.12 Dashboard Finalization and Cloud Integration

The final system architecture features a modular dashboard setup with two role-
specific interfaces: an Operator Dashboard for real-time monitoring and analytics, and a
Pilot Dashboard for on-board safety alerts. Both dashboards were designed with scala-
bility, reliability, and future integration in mind.

Operator Dashboard Modules

The Operator Dashboard includes the following key modules:

• Live Monitoring Module: Displays real-time sensor status, system health, and
breach alerts.

• Analytics and Visualization: Generates time-series graphs, pie charts, and

breach distribution statistics using data fetched from the backend.

• Incident Report Logger: Automatically records red alerts with complete meta-
data for auditing.

• PDF Export Engine: Allows operators to export alert reports and system sum-
maries in PDF format.

• Token-Based Access Control: Ensures secure access using JSON Web Token
(JWT) authentication.

Pilot Dashboard Modules

The Pilot Dashboard consists of:

• Real-Time Alert Receiver: Receives status updates directly from the station-
side ESP32 within a 200-meter communication range.

RV College of Engineering® 2024-25 55

 Sensor Driven Virtual Fencing and Boundary Control

• Suggestion Generator: Provides actionable recommendations based on the alert

type, such as “Reduce speed immediately” for red alerts.

• Fail-Safe Deactivation: Automatically disables alerts when the train is detected

to be parked at the platform.

Backend and Cloud Integration

The backend was built using Flask/[Link] with a modular API design. Key services
(data ingestion, analytics, PDF generation) were containerized using Docker, allowing for
seamless deployment on cloud platforms such as AWS or Google Cloud.
All data was stored in a NoSQL database with indexing support for rapid querying
and time-based aggregation. The architecture is designed to scale horizontally, enabling
deployment at multiple metro stations.

Machine Learning Integration (Future Scope)

The backend has been structured to store labeled alert data (green, yellow, red) with
full contextual metadata. This enables future development of machine learning models to
predict potential breaches or recommend early interventions based on historical patterns
and platform-specific trends.

6.13 Data-Driven Analytics and Predictive Insights

Once the system is deployed at scale, the data collected can be used for further anal-
ysis. Future enhancements may include:
• Time-based breach pattern detection
• Risk prediction for over-crowding zones
• Integration with computer vision or CCTV feeds for multi-sensor validation
• AI/ML models for automatic threat prioritization and response escalation

6.14 Emergency Integration and Auto-Control Re-

sponses
The long-term vision includes linking the breach detection system with other metro
safety mechanisms, such as:
• Automatic slowing or halting of incoming trains based on breach severity

RV College of Engineering® 2024-25 56

 Sensor Driven Virtual Fencing and Boundary Control

• Integration with public announcement systems for live alerts

• Connectivity with emergency dispatch systems for rapid incident response

These enhancements would enable the system to evolve from a passive monitor into
an active safety enforcement tool.

6.15 Power Management and Energy Efficiency

As the system scales, optimizing energy consumption becomes vital. Future improve-
ments may include:
• Use of low-power sensor variants and deep-sleep modes for ESP32
• Integration of battery backups or solar modules for power redundancy
• Energy-aware communication scheduling to reduce unnecessary transmissions

6.16 Compliance and Certification

Before public deployment, the system must be assessed against relevant transit and
safety regulations, such as:
• Railway safety standards (e.g., RDSO in India)
• Electromagnetic compatibility (EMC) certifications
• Occupational safety guidelines for maintenance and inspection
• Cybersecurity audits for wireless communication

Formal certification will improve acceptance by metro authorities and regulatory bod-
ies.

In summary, the current prototype establishes a functional foundation for an intel-

ligent platform safety system. The future roadmap focuses on environmental readiness,
system scalability, advanced analytics, and regulatory compliance, with the ultimate goal
of deploying a smart, robust, and life-saving solution across real-world metro infrastruc-
tures.

RV College of Engineering® 2024-25 57

 Appendix A
Code

Interdisciplinary Project Report 2024-25

 Sensor Driven Virtual Fencing and Boundary Control

APPENDIX A
CODE
A.1 First Appendix
A.1.1 Transmitter Code

# include < esp_now .h >

# include < WiFi .h >

# define FSR_PIN 36
# define TRIG_PIN 33
# define ECHO_PIN 32
# define BUZZER_PIN 25

// Receiver MAC Address

uint8_t broadcastAddress [] = {0 x68 , 0 x25 , 0 xDD , 0 x34 , 0 x29 , 0 x0C };

// Updated structure
typedef struct struct_message {
bool breach ;
int fsr ;
int distance ;
char status [10];
} struct_message ;

struct_message myData ;

void OnDataSent ( const uint8_t * mac_addr , e s p _ n o w _ s e n d _ s t a t u s _ t

status ) {
Serial . print ( " Send Status : " ) ;
Serial . println ( status == E S P _ N O W _ S E N D _ S U C C E S S ? " Success " : " Fail "
);
}

void setup () {
Serial . begin (115200) ;
pinMode ( FSR_PIN , INPUT ) ;

RV College of Engineering® 2024-25 59

 Sensor Driven Virtual Fencing and Boundary Control

pinMode ( TRIG_PIN , OUTPUT ) ;

pinMode ( ECHO_PIN , INPUT ) ;
pinMode ( BUZZER_PIN , OUTPUT ) ;

WiFi . mode ( WIFI_STA ) ;

Serial . print ( " Sender MAC Address : " ) ;
Serial . println ( WiFi . macAddress () ) ;

if ( esp_now_init () != ESP_OK ) {
Serial . println ( " ESP - NOW init failed " ) ;
return ;
}

e s p _ n o w _ r e g i s t e r _ s e n d _ c b ( OnDataSent ) ;

e s p_ n o w_ p e er _ i nf o _ t peerInfo = {};
memcpy ( peerInfo . peer_addr , broadcastAddress , 6) ;
peerInfo . channel = 0;
peerInfo . encrypt = false ;

if ( esp_now_add_peer (& peerInfo ) != ESP_OK ) {

Serial . println ( " Failed to add peer " ) ;
return ;
}
}

void loop () {
long duration , distance ;
int fsrValue = analogRead ( FSR_PIN ) ;

// Measure distance
digitalWrite ( TRIG_PIN , LOW ) ;
del ayMicr osecon ds (2) ;
digitalWrite ( TRIG_PIN , HIGH ) ;
del ayMicr osecon ds (10) ;
digitalWrite ( TRIG_PIN , LOW ) ;
duration = pulseIn ( ECHO_PIN , HIGH ) ;

RV College of Engineering® 2024-25 60

 Sensor Driven Virtual Fencing and Boundary Control

distance = duration * 0.034 / 2;

// Determine breach and status

bool breach = false ;
char status [10] = " GREEN " ;

if ( distance > 25) {

if ( fsrValue >= 1000) {
strcpy ( status , " RED " ) ;
breach = true ;
digitalWrite ( BUZZER_PIN , HIGH ) ;
} else if ( fsrValue >= 500) {
strcpy ( status , " YELLOW " ) ;
breach = true ;
digitalWrite ( BUZZER_PIN , LOW ) ;
} else {
strcpy ( status , " GREEN " ) ;
breach = false ;
digitalWrite ( BUZZER_PIN , LOW ) ;
}
}

// Populate data
myData . fsr = fsrValue ;
myData . distance = distance ;
myData . breach = breach ;
strcpy ( myData . status , status ) ;

// Debug log
Serial . printf ( " FSR : % d | Distance : % d cm | Status : % s | Breach : % s
\n",
fsrValue , distance , status , breach ? " YES " : " NO " ) ;

// Send
esp_now_send ( broadcastAddress , ( uint8_t *) & myData , sizeof ( myData ) ) ;
delay (500) ;
}

RV College of Engineering® 2024-25 61

 Appendix B
Bibliography

Interdisciplinary Project Report 2024-25

 Sensor Driven Virtual Fencing and Boundary Control

APPENDIX B
BIBLIOGRAPHY
B.1 Second Appendix
1. P. Paul, J. C. K. G., and A. Ajina, “AI-Powered Safety Monitoring on Metro
Platforms with Computer Vision Integration,” Tuijin Jishu (Journal of Propulsion
Technology), 2025.

2. Z. Han, M. Zhou, X. Lu, D. Xue, and R. Feng, “Vision Based Real Time Obstacle
Detection System for Trains,” SAE Technical Paper 2022-01-7092, 2022.

3. Y. Li, Y. Wang, and Y. Zhang, “Convolutional Neural Network for Crowd Counting
on Metro Platforms,” Symmetry, vol. 13, no. 4, p. 703, 2021.

4. J. Sun, J. Chen, T. Chen, J. Fan, and S. He, “PIDNet: An Efficient Network for
Dynamic Pedestrian Intrusion Detection,” arXiv:2009.00312, 2020.

5. X. Gong, X. Chen, and W. Chen, “Enhanced Few-shot Learning for Intrusion De-
tection in Railway Video Surveillance,” arXiv:2011.04254, 2020.

6. F. Sahba and R. Sahba, “Prevention of Metro Rail Accidents and Incidents in

Stations Using RFID Technology,” arXiv:1807.03985, 2018.

7. Y. Wang, W. Song, Y. Zhang, F. Huang, Z. Tu, and Y. Lou, “MetroLoc: Metro Ve-
hicle Mapping and Localization with LiDAR Camera Inertial Integration,” arXiv:2111.00762,
2021.

8. J. Garcı́a, L. Martı́nez, and F. Gómez, “Low Power Wireless Sensor Networks for
Metro Safety,” IEEE Trans. Wireless Commun., vol. 16, no. 9, pp. 5923–5931,
2017.

9. S. V. Sabnis and R. Lokeshkumar, “An Efficient Object and Railway Track Recog-
nition in Thermal Images Using Deep Learning,” in Proc. Int. Conf. Artificial
Intelligence and Computer Engineering, 2021, pp. 101–106.

10. A. Cucchiara, C. Grana, M. Piccardi, A. Prati, and S. Sirotti, “Improving Shadow

Suppression in Moving Object Detection with HSV Color Information,” in Proc.
IEEE Intelligent Transportation Systems Conf., 2001.

RV College of Engineering® 2024-25 63

 Sensor Driven Virtual Fencing and Boundary Control

11. S. Mockel, F. Scherer, and P. F. Schuster, “Multi Sensor Obstacle Detection on

Railway Tracks,” in IEEE Intelligent Vehicles Symposium, 2003.

12. S. Kim and H. Choi, “Infrared Sensor Arrays for Real Time Boundary Monitoring,”
IEEE Sensors J., vol. 17, no. 13, pp. 4257–4264, 2017.

13. T. Müller, F. Schmidt, and M. Hoffmann, “Sensor Calibration Techniques for Metro
Safety Systems,” Int. J. Rail Transit Technol., vol. 12, no. 2, pp. 105–114, 2019.

14. A. Sharma and P. Singh, “Wireless Sensor Network Topologies for Metro Safety
Applications,” in Proc. IEEE Int. Conf. Communications, 2020, pp. 567–574.

15. J. Wang and Y. Liu, “Real Time Data Processing on ESP32 for Safety Critical
Applications,” Embedded Systems Journal, vol. 8, no. 4, pp. 224–231, 2021.

16. H. Kim, S. Park, and D. Lee, “Multi Sensor Fault Detection and Recovery in Metro
Systems,” Sensors, vol. 18, no. 7, pp. 2056–2065, 2018.

17. M. Gonzalez and J. Ramirez, “Energy Harvesting for Wireless Metro Safety Sen-
sors,” IEEE Trans. Sustain. Energy, vol. 10, no. 3, pp. 1234–1242, 2019.

18. N. Patel and R. Singh, “Edge Computing Architectures for Urban Rail Safety,” in
Proc. IEEE Smart Cities Conf., 2022, pp. 90–96.

19. F. Ahmed and Y. Zhao, “Sensor Based Crowd Detection and Management in Metro
Stations,” J. Transport Safety, vol. 14, no. 3, pp. 180–188, 2020.

20. X. Li and J. Chen, “Design and Implementation of Virtual Fences Using Ultrasonic
Sensors,” in Proc. IEEE Industrial Conference, 2016.

21. M. Sharma and A. Verma, “IoT Based Safety Monitoring in Metro Stations Using
ESP32,” in Proc. IEEE IoT Conf., 2021, pp. 411–416.

22. J. Thompson and P. Lee, “Virtual Fence Systems for Railway Safety: A Review,”
Rail Safety J., vol. 13, no. 1, pp. 25–38, 2017.

23. L. Garcia and P. Patel, “Real Time Platform Safety Alerts Using Wireless Sensor
Networks,” IEEE Sensors J., vol. 19, no. 10, pp. 3857–3864, 2019.

RV College of Engineering® 2024-25 64

 Sensor Driven Virtual Fencing and Boundary Control

24. Y. Liu, H. Wang, and S. Zhang, “Deep Learning for Crowd Behavior Analysis in
Metro Stations,” IEEE Trans. Neural Netw. Learn. Syst., vol. 31, no. 7, pp. 2345–
2355, 2020.

25. J. Kim and T. Lee, “Power Management Strategies for ESP32 in Safety Systems,”
in Proc. Embedded Systems Conf., 2021, pp. 88–95.

26. Y. Zhang, X. Sun, and Q. Wu, “Sensor Calibration and Noise Reduction for Ultra-
sonic Systems,” Sensors, vol. 18, no. 12, pp. 4125–4133, 2018.

27. J. Park and L. Martinez, “Real Time Web Dashboards for Public Transport Safety,”
in Proc. ACM UbiComp, 2021, pp. 100–107.

28. M. Silva and R. Torres, “Mesh Networking for Metro Safety Sensor Systems,” IEEE
Trans. Netw., vol. 27, no. 4, pp. 1534–1542, 2019.

29. T. Nguyen and D. Chan, “Human Factors in Metro Safety Sensor Design,” J.
Human Factors Eng., vol. 10, no. 2, pp. 78–86, 2018.

30. S. Rao and K. Das, “Low Cost Sensor Arrays for Urban Rail Safety Applications,”
in Proc. Int. Conf. Urban Transport Safety, 2020, pp. 122–129.

31. K. Tan and W. Wong, “Edge Computing with ESP32 for Safety Critical Applica-
tions,” IEEE Trans. Ind. Inform., vol. 19, no. 1, pp. 550–558, 2023.

32. A. Dasgupta and S. Roy, “Sensor Network Security in Public Transportation Sys-
tems,” in Proc. IEEE Cybersecurity Conf., 2020, pp. 75–82.

33. L. Fernandez, M. Torres, and R. Gomez, “Multi Modal Sensor Fusion for Enhanced
Platform Safety,” Sensors, vol. 21, no. 3, pp. 885–895, 2021.

34. P. Singh and R. Kapoor, “Wireless Communication Protocols for Metro Safety
Systems: A Comparative Study,” IEEE Commun. Mag., vol. 57, no. 5, pp. 68–75,
2019.

35. S. Reddy and B. Naidu, “Implementation of Virtual Fencing Using Ultrasonic Sen-
sors and ESP32,” in Proc. IEEE Embedded Systems Conf., 2018.

RV College of Engineering® 2024-25 65

 Sensor Driven Virtual Fencing and Boundary Control

36. Y. Liu and H. Zhang, “Cloud Based Monitoring and Analytics for Metro Safety,”
J. Cloud Comput., vol. 9, no. 2, pp. 50–58, 2020.

37. Y. Chen and J. Park, “Real Time Alert Systems for Public Transport Using MQTT
and WebSocket,” in Proc. IEEE Smart Cities Conf., 2021, pp. 140–146.

38. P. Singh, M. Sharma, and R. Gupta, “Sensor Placement Optimization for Metro
Platform Safety,” IEEE Trans. Intell. Transp. Syst., vol. 18, no. 10, pp. 2633–2641,
2017.

39. L. Morales and J. Sanchez, “Energy Efficient Protocols for Metro Safety Sensor
Networks,” in IEEE Wireless Sensor Conf., 2019, pp. 200–207.

40. B. Wilson and R. Kumar, “Human Centric Design in Metro Safety Systems,” J.
Transport Safety, vol. 16, no. 1, pp. 45–53, 2018.

41. Y. Khandhediya, K. Sav, and V. Gajjar, “Human Detection for Night Surveillance
using Adaptive Background Subtracted Image,” arXiv:1709.09389, 2017.

42. D. Salikhov et al., “Microservice based IoT for Smart Buildings,” arXiv:1610.09480,
2016.

43. R. Djehaiche et al., “Adaptive Control of IoT/M2M Devices in Smart Buildings

using Heterogeneous Wireless Networks,” arXiv:2302.13343, 2023.

44. C. Hsu, Y. Liu, X. Zhang, Z. Zhang, and Y. Jiang, “YOLOv5 MS: Real Time Multi
Surveillance Pedestrian Target Detection Model for Smart Cities,” Sensors, vol. 8,
no. 6, p. 480, 2023.

45. Y. Yu et al., “Foreign Objects Identification of Transmission Line Based on Im-

proved YOLOv7,” IEEE Access, vol. 11, pp. 51997–52008, 2023.

46. D. J. Shin and J. J. Kim, “A Deep Learning Framework Performance Evaluation to

Use YOLO in NVIDIA Jetson Platform,” Applied Sciences, vol. 12, no. 3734, 2022.

47. A. Kumar et al., “Real Time Citywide Reconstruction of Traffic Flow from Moving
Cameras on Lightweight Edge Devices,” ISPRS J. Photogramm. Remote Sens.,
vol. 192, pp. 115–129, 2022.

RV College of Engineering® 2024-25 66

 Sensor Driven Virtual Fencing and Boundary Control

48. C. Y. Wang, A. Bochkovskiy, and H. Y. M. Liao, “YOLOv7: Trainable Bag of

Freebies Sets New State of the Art for Real Time Object Detectors,” in Proc.
IEEE/CVF Conf. Comput. Vis. Pattern Recognit., 2023, pp. 7464–7475.

49. J. Terven, D. M. Córdova Esparza, and J. A. Romero González, “A Comprehensive

Review of YOLO Architectures in Computer Vision: From YOLOv1 to YOLOv8
and YOLO NAS,” Mach. Learn. Knowl. Extract., vol. 5, no. 4, 2023.

50. Y. Jiang, W. Liu, and Z. Zhao, “IoT Based Real Time Safety Monitoring System
for Urban Rail Transit Platforms,” IEEE Internet of Things J., vol. 9, no. 12,
pp. 8998–9007, 2022.

RV College of Engineering® 2024-25 67