AI BASED TRAFFIC

CONTROL AND
MONITORING SYSTEM

Session: 2021 – 2025

Submitted by:
Ghazanfar Ahmad 2021-SE-16
Muhammad Afaq 2021-SE-18
Sameer Ahmad 2021-SE-55

Supervised by:
Drakhshan Bokhat

Department of Computer Science, New Campus

University of Engineering and Technology
Lahore, Pakistan
AI BASED TRAFFIC CONTROL AND MONITORING
SYSTEM
(Session 2021 Software Engineering)

The thesis is to be submitted to the Department of Computer Science, New

Campus, University of Engineering and Technology, Lahore for the partial
fulfillment of the requirement for Bachelor of Science in Computer Science.

Supervisor
Signature:

Name:

Designation:

Chairman Dean
Signature: Signature:

Department of Computer Science, New Campus

University of Engineering and Technology

Lahore, Pakistan

i
 Declaration
I declare that the work contained in this thesis is my own, except where explicitly
stated otherwise. In addition this work has not been submitted to obtain another
degree or professional qualification.

Members Signature:

Date:

ii
 Acknowledgments
First and foremost, we are deeply grateful to the Almighty for granting us the
strength, wisdom, and perseverance to complete this project successfully.

We extend our heartfelt thanks to our respected project supervisor, Mam Drakhshan
Bokhat, Deputy Commissioner Multan, for her invaluable guidance, continuous
support, and insightful suggestions throughout this research. Her encouragement
and dedication were instrumental in shaping the direction and execution of this
project.

We are also sincerely thankful to the Chief Traffic Officer (CTO) Multan for
their collaboration, cooperation, and the real-world insights that enriched our un-
derstanding of the challenges in traffic management and helped refine our proposed
solutions.

Additionally, we would like to thank our faculty members, friends, and family for
their constant encouragement and support throughout this academic journey.

This project would not have been possible without the contributions, mentorship,
and moral support of each individual mentioned above. We are truly grateful.

...

iii
This project is dedicated to my teachers and
parents, whose support and guidance have
shaped my learning journey.

vi
Contents

Acknowledgments iii

List of Figures x

List of Tables xii

Abbreviations xiii

Abstract xiv

1 Introduction 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Assumptions and Constraints . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Real-Time Traffic Monitoring: . . . . . . . . . . . . . . . . . 4
1.5.2 Dynamic Signal Control: . . . . . . . . . . . . . . . . . . . . 4
1.5.3 Predictive Traffic Management: . . . . . . . . . . . . . . . . 4
1.5.4 Scalability and Flexibility: . . . . . . . . . . . . . . . . . . . 4
1.5.5 Data-Driven Decision Making: . . . . . . . . . . . . . . . . . 4
1.5.6 Algorithm Integration: . . . . . . . . . . . . . . . . . . . . . 5
1.5.7 Performance Monitoring: . . . . . . . . . . . . . . . . . . . . 5

2 Literature Review 6
2.1 Background study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Requirement Elicitation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . 9
2.3 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Use Case Description . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 System Design Analysis 11

3.1 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

vii
Contents viii

3.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Structure Diagram . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Circuit Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Hardware Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 System Implementation 20
4.1 BackEnd Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Experimentation and Testing 47

5.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1 Sensor Individual Count Accuracy . . . . . . . . . . . . . . . 49
5.1.1.1 Test Cases for 8 Sensors . . . . . . . . . . . . . . . 50
5.1.2 Sensor Connectivity Test . . . . . . . . . . . . . . . . . . . . 51
5.2 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.1 Combined Sensor Count Accuracy . . . . . . . . . . . . . . . 52
5.2.1.1 Test Cases for 4 Roads . . . . . . . . . . . . . . . . 54
5.2.2 Traffic Light Adjustment Test . . . . . . . . . . . . . . . . . 55
5.2.2.1 Test Cases for 3 Intersections . . . . . . . . . . . . 57
5.2.3 Real-Time Data Processing Test . . . . . . . . . . . . . . . . 57
5.2.3.1 Test Cases for 8 Scenarios . . . . . . . . . . . . . . 59
5.2.4 Power Supply Stability Test . . . . . . . . . . . . . . . . . . 60
5.2.5 Vehicle Detection on Black Road Surface . . . . . . . . . . . 61
5.2.6 Vehicle Detection on Grey Road Surface . . . . . . . . . . . 62
5.2.7 False Vehicle Detection on White Road . . . . . . . . . . . . 63
5.2.8 Decision Tree Optimization for Traffic Light Control . . . . 64
5.3 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.1 Shared Sensor Count Data Across Intersections . . . . . . . 65
5.3.1.1 Test Cases for 24 Sensors . . . . . . . . . . . . . . 67
5.3.2 Model Adaptation Test . . . . . . . . . . . . . . . . . . . . 68
5.4 Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5 Performance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.1 Standard Processing Speed Test . . . . . . . . . . . . . . . . 71
5.5.2 High Traffic Load Processing Test . . . . . . . . . . . . . . . 72
5.5.3 Low Traffic Load Processing Test . . . . . . . . . . . . . . . 73
5.5.4 Sensor Data Loss and Recovery Speed Test . . . . . . . . . . 74
5.5.5 Multiple Intersection Coordination Test . . . . . . . . . . . . 75
5.5.6 Long-Term Sensor Accuracy Test . . . . . . . . . . . . . . . 76
5.6 Security Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.6.1 Unauthorized Access Test . . . . . . . . . . . . . . . . . . . 78
5.6.2 Data Encryption Test . . . . . . . . . . . . . . . . . . . . . 79
5.6.3 Brute Force Login Protection Test . . . . . . . . . . . . . . . 80
5.6.4 Data Tampering Prevention Test . . . . . . . . . . . . . . . 81
5.7 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Contents ix

5.8 Compatibility Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6 Results and Outputs 83

6.1 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7 Conclusions and Future Direction 95

7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.2 Future Work and Direction . . . . . . . . . . . . . . . . . . . . . . . 95

References 97
List of Figures

2.1 Use Case Diagram for the Automated Traffic Light System . . . . . 10

3.1 Activity Diagram for the Automated Traffic Light System . . . . . 12

3.2 Sequence Diagram for the Automated Traffic Light System . . . . . 13
3.3 Structure Diagram for the Automated Traffic Light System . . . . . 14
3.4 Circuit Diagram for the Automated Traffic Light System . . . . . . 15
3.5 Signals Operating 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Signals Operating 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7 Traffic Counting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 Complete Hardware Diagram for the Automated Traffic Light System 19

4.1 generate traffic data . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Get congestion level . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Calculate green time . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Predict congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Update all traffic data . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 Initialize traffic signals . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Update signal status . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.8 home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.9 Should update data . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.10 get traffic data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.11 get intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.12 get traffic history . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.13 get congestion data . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.14 get rerouting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.15 get predictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.16 force refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.17 expire signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.18 System Initialization and Hardware Setup . . . . . . . . . . . . . . 35
4.19 Main Loop Execution Overview . . . . . . . . . . . . . . . . . . . . 36
4.20 processSerialData() Function Overview . . . . . . . . . . . . . . . . 37
4.21 Initialize Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.22 Handle Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.23 Lane Sequence Start Display . . . . . . . . . . . . . . . . . . . . . 40
4.24 Sequence Update Display . . . . . . . . . . . . . . . . . . . . . . . . 40
4.25 End-of-Sequence Notification . . . . . . . . . . . . . . . . . . . . . . 41

x
List of Figures xi

4.26 Rerouting Information Display . . . . . . . . . . . . . . . . . . . . . 42

4.27 Lane Green Light Control . . . . . . . . . . . . . . . . . . . . . . . 42
4.28 Lane Red Light Control . . . . . . . . . . . . . . . . . . . . . . . . 43
4.29 Control All Lanes to Red . . . . . . . . . . . . . . . . . . . . . . . . 43
4.30 count Cars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.31 Update Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.32 Initialize Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.1 Adaptive Traffic Flow Management Report . . . . . . . . . . . . . 83

6.2 Smart Traffic Rerouting . . . . . . . . . . . . . . . . . . . . . . . . 84
6.3 Traffic Flow Adjustment Map . . . . . . . . . . . . . . . . . . . . . 85
6.4 Current Traffic Density . . . . . . . . . . . . . . . . . . . . . . . . 86
6.5 Congestion Trends Over Time . . . . . . . . . . . . . . . . . . . . . 87
6.6 Signal Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.7 Recent Traffic History . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.8 Traffic Control Dashboard . . . . . . . . . . . . . . . . . . . . . . . 90
6.9 Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.10 AI Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.11 TrafficAI Alert Center . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.12 TrafficAI Admin Panel . . . . . . . . . . . . . . . . . . . . . . . . . 94
List of Tables

5.1 Sensor Individual Count Accuracy . . . . . . . . . . . . . . . . . . . 49

5.2 Test Cases for 8 Sensors . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3 Sensor Connectivity Test . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5 Test Cases for 4 Roads . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6 Traffic Light Adjustment Test . . . . . . . . . . . . . . . . . . . . . 56
5.7 Test Cases for 3 Intersections . . . . . . . . . . . . . . . . . . . . . 57
5.8 Real-Time Data Processing Test . . . . . . . . . . . . . . . . . . . . 58
5.9 Test Cases for 8 Scenarios . . . . . . . . . . . . . . . . . . . . . . . 59
5.10 Power Supply Stability Test . . . . . . . . . . . . . . . . . . . . . . 60
5.11 Vehicle Detection on Black Road Surface . . . . . . . . . . . . . . . 61
5.12 Vehicle Detection on Grey Road Surface . . . . . . . . . . . . . . . 62
5.13 False Vehicle Detection on White Road . . . . . . . . . . . . . . . . 63
5.14 Decision Tree Optimization for Traffic Light Control . . . . . . . . . 64
5.15 Shared Sensor Count Data Across Intersections . . . . . . . . . . . 66
5.16 Test Cases for 24 Sensors . . . . . . . . . . . . . . . . . . . . . . . . 68
5.17 Model Adaptation Test . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.18 Standard Processing Speed Test . . . . . . . . . . . . . . . . . . . . 71
5.19 High Traffic Load Processing Test . . . . . . . . . . . . . . . . . . . 72
5.20 Low Traffic Load Processing Test . . . . . . . . . . . . . . . . . . . 73
5.21 Sensor Data Loss and Recovery Speed Test . . . . . . . . . . . . . . 74
5.22 Multiple Intersection Coordination Test . . . . . . . . . . . . . . . . 75
5.23 Long-Term Sensor Accuracy Test . . . . . . . . . . . . . . . . . . . 76
5.24 Unauthorized Access Test . . . . . . . . . . . . . . . . . . . . . . . 78
5.25 Data Encryption Test . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.26 Brute Force Login Protection Test . . . . . . . . . . . . . . . . . . . 80
5.27 Data Tampering Prevention Test . . . . . . . . . . . . . . . . . . . 81

xii
Abbreviations

AI Artificial Intelligence

API Application Programming Interface

CPU Central Processing Unit

DT Decision Tree

FR Functional Requirement

GUI Graphical User Interface

IR Infrared

IoT Internet of Things

IT Integration Testing

MAS Multi-Agent Systems

ML Machine Learning

NR Non-Functional Requirement

PT Performance Testing

RL Reinforcement Learning

ST System Testing

SUMO Simulation of Urban MObility

UI User Interface

USB Universal Serial Bus

UT Unit Testing

Wi-Fi Wireless Fidelity

xiii
 Abstract
Efficient traffic management plays a crucial role in reducing congestion, travel de-
lays, and accidents in rapidly growing urban environments. This project presents
the design and implementation of an intelligent, automated traffic light control sys-
tem that leverages real-time data from road-side sensors to dynamically optimize
traffic signal timings at intersections. The proposed system monitors live vehicle
counts and waiting durations at each signal using sensor input and processes this
data using advanced decision-making techniques. Two primary algorithms form
the backbone of this system: Decision Trees for rule-based traffic flow control, and
Reinforcement Learning for adaptive signal management based on past traffic pat-
terns and real-time feedback. These algorithms are trained and evaluated using
realistic traffic data to ensure accuracy and adaptability. The system architecture
involves several key components. Sensor data is collected and transmitted to a cen-
tral processing unit, where algorithms process it to determine the most efficient
signal switching sequence. Technologies such as scikit-learn are used to build and
train Decision Tree models, while Keras is employed for implementing and train-
ing Reinforcement Learning agents. Additionally, NumPy, Pandas, and Matplotlib
assist in data preprocessing, analysis, and visualization. The system interface is
developed using web frameworks like Flask or Django, providing a dashboard for
real-time monitoring and manual override capabilities. For hardware-level sensor
integration and signal control, microcontrollers like Raspberry Pi or Arduino are
utilized, ensuring portability and ease of deployment. This project aims to deliver
a scalable, adaptive, and cost-effective solution to urban traffic congestion, offer-
ing real-time responsiveness and long-term learning-based improvements in traffic
flow efficiency.
Chapter 1

Introduction

1.1 Introduction
In contemporary urban traffic management, the demand for advanced, adaptive
signaling systems has increased due to the complexity of managing congestion and
optimizing traffic flow. Traditional, time-based traffic signal systems are often
inefficient, leading to unnecessary delays and traffic jams. Therefore, there is a
growing need for intelligent systems that dynamically adjust signal timings based
on real-time traffic data to ensure smoother traffic flow and reduced congestion.
This project addresses this need by implementing an automated traffic light sig-
naling system that leverages real-time data from sensors placed at intersections.
The sensors monitor vehicle counts and waiting times, and the data is processed
by machine learning algorithms, including decision trees to predict optimal sig-
nal timings. The decision-making process involves dynamically adjusting signals
based on traffic density, vehicle wait times, and the predicted impact on adjacent
signals.
The development methodology involves data collection from sensors, algorithm
selection, model training, real-time evaluation, and deployment in a user-friendly
interface that allows for easy monitoring and adjustment. Key technologies include
scikit-learn for decision trees, Flask or Django for the web interface. For
sensor integration, platforms such as ESP32 are utilized. By combining these
technologies, the system ensures scalable and efficient performance, adapting to
changing traffic conditions in real-time to optimize urban traffic management.

1
Chapter 1. Introduction 2

1.2 Objectives
• Develop a system to collect and process real-time traffic data from intersec-
tion sensors, tracking vehicle count and lane-wise waiting time for efficient
signal control.

• Implement intelligent algorithms like decision trees to dynamically adjust

signal timings based on real-time traffic flow, minimizing delays and improv-
ing system efficiency.

• Test the system in both simulated and real-world scenarios to ensure scala-
bility, adaptability, and consistent performance under varying traffic condi-
tions.

• Select and integrate effective algorithms, combining rule-based methods like

decision trees to maintain a balance between efficiency, accuracy, and prac-
tical implementation.

1.3 Problem Statement

In modern urban environments, the rapid increase in vehicle density has posed
significant challenges to traffic management systems. Traditional traffic light sys-
tems operate on fixed timing schedules or rely on basic sensor inputs, which fail
to adapt to real-time fluctuations in traffic conditions. As a result, vehicles often
experience prolonged waiting times, unnecessary signal delays, and frequent traffic
jams—especially during rush hours or at busy intersections.
These rigid systems lack the intelligence to prioritize heavily congested lanes or
dynamically reallocate green light durations based on actual traffic flow. Con-
sequently, the inefficiencies lead to wasted fuel, increased pollution levels, and
driver frustration. Additionally, emergency vehicles and public transport often
get caught in traffic, further complicating urban mobility.
To overcome these limitations, there is a pressing need for an intelligent traffic
light signaling system that can respond to real-time data. By integrating advanced
machine learning algorithms such as decision trees and collecting live data from
road-embedded sensors, the system can make data-driven decisions. This adaptive
approach can significantly reduce congestion, enhance traffic flow, and optimize
signal timing in a more responsive and scalable manner.
Chapter 1. Introduction 3

1.4 Assumptions and Constraints

1.4.1 Assumptions
• It is assumed that all intersections where the system is deployed are equipped
with functional traffic sensors capable of accurately detecting vehicle pres-
ence, count, and waiting time.

• The road infrastructure supports integration with electronic controllers (

ESP32) to manage and automate signal transitions.

• It is assumed that the environment provides a stable power supply and inter-
net or local network connectivity to ensure real-time data communication.

• Traffic patterns follow predictable behavior in most urban settings, allowing

machine learning algorithms to identify trends and optimize signal timings
effectively.

• The decision-making models (decision trees) can generalize well across differ-
ent types of intersections after being trained on representative traffic data.

• Emergency vehicle detection and prioritization are not included in the initial
system but may be considered in future enhancements.

1.4.2 Constraints
• Real-time sensor data may be subject to noise, inaccuracies, or delays, which
can impact the system’s decision-making accuracy.

• The project relies on the availability of compatible sensors and microcon-

trollers, which may limit deployment in certain areas with poor infrastruc-
ture.

• The machine learning models require initial training on traffic datasets, and
performance may degrade in highly unpredictable or unusual traffic condi-
tions.

• Deployment is limited to intersections with proper power and network infras-

tructure, restricting its applicability in remote or underdeveloped regions.
Chapter 1. Introduction 4

• The system’s decision logic must comply with local traffic laws and regula-
tions, which may vary across cities or regions.

• Hardware maintenance and calibration of sensors are required periodically

to ensure continued accuracy and efficiency of the system.

1.5 Scope
The scope of this project encompasses the design and implementation of an intelli-
gent traffic light signaling system that leverages real-time sensor data and machine
learning algorithms to enhance traffic flow in urban areas. The core features of
the system include:

• 1.5.1 Real-Time Traffic Monitoring:

Continuous collection and analysis of traffic data from strategically placed
sensors at intersections to monitor vehicle counts, waiting durations, and
flow dynamics.

• 1.5.2 Dynamic Signal Control:

Intelligent adjustment of traffic light timings using decision tree classifiers
algorithms to reduce congestion and improve overall traffic throughput.

• 1.5.3 Predictive Traffic Management:

The system anticipates upcoming traffic loads and proactively alters sig-
nal patterns to prevent bottlenecks, especially during peak hours or unpre-
dictable surges in traffic.

• 1.5.4 Scalability and Flexibility:

The system architecture supports easy integration with various types of in-
tersections and can scale across different city zones without significant mod-
ifications.

• 1.5.5 Data-Driven Decision Making:

Traffic decisions are guided by real-time analytics, enhancing the precision
and reliability of signal control logic and improving user trust in the system’s
efficiency.
Chapter 1. Introduction 5

• 1.5.6 Algorithm Integration:

Seamless incorporation of decision trees ensures that the system continuously
learns and adapts to changing traffic behaviors for optimal decision-making.

• 1.5.7 Performance Monitoring:

The system offers real-time metrics and performance reports, such as average
wait time reduction, flow improvements, and congestion analysis, allowing
for data-backed refinements and performance tuning.
Chapter 2

Literature Review

2.1 Background study

• Introduction to Traffic Management Systems: Urban traffic conges-
tion poses significant challenges for city planners and policymakers, primarily
due to increasing vehicle density and inefficiencies in existing traffic manage-
ment strategies. The need for effective management of traffic lights has led
to the exploration of intelligent traffic systems that utilize advanced tech-
nologies, including multi-agent systems and simulation tools.

• Multi-Agent Systems in Traffic Management: The use of multi-agent

systems (MAS) for traffic simulation has gained prominence as researchers
seek to develop models that reflect real-world behaviors and dynamics. Math-
ieu et al. (2024) demonstrated the effectiveness of MAS in evaluating vari-
ous traffic light management strategies using the SUMO (Simulation of Ur-
ban MObility) simulator. They emphasized that intelligent traffic lights,
equipped with sensors and artificial intelligence, can significantly reduce ve-
hicle waiting times, fuel consumption, and toxic emissions, thereby improv-
ing urban mobility [1].
The paper highlighted five distinct traffic light behaviors: timer-based switch-
ing, adaptive timing based on neighboring intersections, punitive measures
for speed violations, rewards for compliance with speed limits, and counting
the number of waiting vehicles to optimize light changes. This multi-faceted
approach allows for tailored traffic management strategies depending on spe-
cific urban contexts and objectives, such as pollution reduction or speeding
mitigation.

6
Chapter 2. Literature Review 7

• Simulation Tools for Traffic Analysis: SUMO serves as a robust plat-

form for simulating both abstract and real-world traffic scenarios. Its ca-
pability to model large road networks enables researchers to test various
configurations and strategies comprehensively. The findings indicated that
specific behaviors, like the ”Count” strategy, resulted in optimal performance
concerning waiting time, fuel consumption, and CO2 emissions, while the
”Punish” strategy effectively reduced speeding instances. This adaptability
makes MAS an essential tool for evaluating and selecting the most suitable
traffic management strategies based on urban objectives[2].

• Traffic Light Control Strategies: The findings from Bazzan (2005) and
others indicate that distributed control systems can alleviate traffic conges-
tion at intersections. Bazzan proposed a coordination approach for traffic
signal agents, which aligns with the simulation results observed by Math-
ieu et al. Both works underscore the necessity of context-sensitive traffic
management solutions that can adapt to varying traffic patterns and urban
layouts.

• Challenges and Future Directions: While MAS and simulation tools like
SUMO offer promising avenues for traffic management, challenges remain.
Ensuring real-time adaptability in dynamic urban environments is crucial.
Future research should focus on enhancing these systems’ responsiveness to
live traffic data, incorporating machine learning techniques for predictive
modeling, and exploring the integration of smart infrastructure components
such as connected vehicles and IoT devices.
Chapter 2. Literature Review 8

2.2 Requirement Elicitation

Requirement elicitation is the process of identifying and gathering user require-
ments and system expectations through various communication and research meth-
ods. In the context of this project, the goal is to understand the traffic management
challenges faced in urban areas and gather information on the expectations from
an intelligent traffic control system [3].
This involves interacting with potential users (e.g., traffic authorities, urban plan-
ners), reviewing existing systems, and identifying limitations in current traffic
light models. Techniques such as interviews, observation, document analysis, and
system prototyping are used to collect both functional and non-functional require-
ments.
The following key points were elicited during the requirement phase:

• The system must detect real-time traffic flow using sensors (e.g., IR, ultra-
sonic, or camera-based).

• It should adjust signal timings dynamically based on vehicle density.

• The system must ensure minimum wait times and reduce traffic congestion
during peak hours.

• Authorities require a web interface to monitor and configure system param-

eters.

• The system should be able to scale to different intersection types with min-
imal reconfiguration.

2.2.1 Functional Requirements

• Business requirements

• FR-01-01: The system shall collect real-time data on vehicle counts

and waiting times at intersections using appropriate sensors (e.g., vehi-
cle count sensors and cameras). [Priority 1]
• FR-01-02: The system shall dynamically adjust traffic signal timings
based on real-time data processed through machine learning algorithms
to optimize traffic flow. [Priority 1]

• User requirements
Chapter 2. Literature Review 9

• FR-01-03: The system shall integrate decision trees to determine op-

timal signal timings based on current traffic conditions. [Priority 1]
• FR-01-04: The system shall continuously monitor traffic conditions
and provide real-time adjustments to signal timings based on the col-
lected data. [Priority 1]

2.2.2 Non-Functional Requirements

Non-functional requirements specify how the system should do it. Non-functional
requirements do not affect the basic functionality of the system report. [4]

• NR-01-01: The system shall ensure seamless usability of the algorithm and
sensors despite weather conditions or environmental factors. [Priority 1]

• NR-01-02: The system shall ensure high availability and reliability, func-
tioning continuously 24/7/365 without significant downtime. Maintenance
procedures should be in place to minimize interruptions. [Priority 2]

• NR-01-03: The system shall be designed to accommodate future growth,

allowing for the addition of more sensors and integration with other traffic
management systems without significant reconfiguration or downtime. [Pri-
ority 1]

• NR-01-04: The system shall operate efficiently, with signal adjustments

occurring in real-time (within milliseconds) based on incoming data. The
processing speed should support the rapid collection and analysis of data to
ensure timely responses. [Priority 2]

• NR-01-05: The system shall include provisions for ongoing support and
maintenance. Support can be provided in-house or through remote access to
external technical resources, ensuring quick resolution of any issues. [Priority
1]

• NR-01-06: The system shall implement robust security measures to protect

sensitive traffic data, including encryption for data transmission and secure
access controls to prevent unauthorized access to system functionalities and
data. [Priority 2]

• NR-01-07: The system shall have a basic user interface to deploy the algo-
rithm. [Priority 2]
Chapter 2. Literature Review 10

2.3 Use Case Diagram

Use case diagrams give a graphic overview of the actors involved in a system, dif-
ferent functions needed by those actors, and how these different functions interact.
Use case diagrams are typically developed in the early stage of development, and
people often apply use case modeling for the following purposes:

Figure 2.1: Use Case Diagram for the Automated Traffic Light System

2.4 Use Case Description

This use case focuses on the core functionality of the system: controlling traffic
signals based on real-time traffic data. The primary actors involved include the
traffic sensors (such as infrared sensors), a microcontroller unit (ESP32), a central
server running machine learning algorithms, and the traffic light infrastructure
itself. The process begins when sensors placed at each intersection gather vehicle
count and waiting time data. This data is then transmitted to the server, which
utilizes decision trees models to determine the optimal signal switching pattern.
Based on this analysis, updated signal instructions are sent to the controllers to
regulate the lights accordingly. The use case ensures that signal timings adapt
continuously depending on current traffic flow, minimizing congestion and im-
proving intersection efficiency. In cases where the sensor data is unavailable or
inconsistent, the system falls back on default time-based control logic to maintain
basic signal operation. Overall, this use case enables intelligent, adaptive traffic
management in urban environments.
Chapter 3

System Design Analysis

The proposed smart traffic control system is designed as a modular and scalable
architecture, integrating hardware and software components to manage real-time
traffic at urban intersections. The hardware layer comprises sensors (such as IR
or ultrasonic) deployed at each lane to count vehicles and measure waiting times.
These sensors are interfaced with microcontrollers like ESP32 which act as edge
processing units, forwarding the collected data to a centralized system via Wi-Fi
or LAN.
The software layer is responsible for processing this incoming data using decision-
making algorithms. The system implements machine learning models, such as
Decision Trees for logical rule-based conditions to adapt signal timings dynami-
cally based on traffic density patterns. The backend is developed using Python,
incorporating libraries such as scikit-learn and Keras, while data handling and pre-
processing are managed using NumPy and Pandas. The processed decisions are
then communicated back to the controllers at each intersection to execute traffic
light transitions [5].
To enable user interaction and system monitoring, a lightweight interface is de-
veloped using Flask or Django, offering features such as live traffic status, system
overrides, and data analytics visualization. Additionally, the system is designed
with fail-safe mechanisms — in case of sensor or communication failure, it reverts
to a default time-based traffic signal sequence to maintain basic operations.
This layered and modular approach ensures flexibility, easy maintenance, and scal-
ability, making the system adaptable for various intersection sizes and complexi-
ties. It also supports future integration with emergency vehicle detection, pedes-
trian management, and IoT-based city infrastructure

11
Chapter 3. System Design Analysis 12

3.1 Activity Diagram

Activity diagrams represent workflows in a graphical way. They can be used to
describe the business workflow or the operational workflow of any component in a
system.

Figure 3.1: Activity Diagram for the Automated Traffic Light System
Chapter 3. System Design Analysis 13

3.2 Sequence Diagram

Sequence diagrams in UML show how objects interact with each other and the
order in which those interactions occur. It’s important to note that they show the
interactions for a particular scenario. As shown in Figure 3.2,The processes are
represented vertically, and interactions are shown as arrows.

Figure 3.2: Sequence Diagram for the Automated Traffic Light System
Chapter 3. System Design Analysis 14

3.3 Software Architecture

3.3.1 Structure Diagram
The structure diagram illustrates the overall layout of the road network, empha-
sizing the arrangement of intersections. It demonstrates how traffic data flows
through the system, connecting various intersections for synchronized traffic man-
agement. As shown in Figure 3.3, This diagram serves as a blueprint for system-
wide traffic control.

Figure 3.3: Structure Diagram for the Automated Traffic Light System
Chapter 3. System Design Analysis 15

3.3.2 Circuit Diagram

Depicts the internal structure of the traffic monitoring and control system. It
shows the relationships between hardware (sensors, controllers) and software com-
ponents (algorithms, data processors). As shown in Figure 3.4,This diagram high-
lights how each component contributes to efficient traffic management and system
integration.

Figure 3.4: Circuit Diagram for the Automated Traffic Light System
Chapter 3. System Design Analysis 16

3.4 Hardware Diagrams

The hardware diagram of the traffic monitoring and control system, as shown
in Figure 3.8, showcases key components such as traffic sensors, which monitor
vehicle counts, speed, and lane occupancy. These sensors feed real-time data to
controllers that process and adjust traffic signal timings. Communication modules
ensure smooth data exchange between sensors, controllers, and the central server.
The system is designed for scalability, allowing integration with additional devices
like traffic cameras. This hardware setup enables efficient traffic management by
optimizing signal timings based on real-time traffic data.

Figure 3.5: Signals Operating 1

Chapter 3. System Design Analysis 17

Figure 3.6: Signals Operating 2

Chapter 3. System Design Analysis 18

Figure 3.7: Traffic Counting

Chapter 3. System Design Analysis 19

Figure 3.8: Complete Hardware Diagram for the Automated Traffic Light
System
Chapter 4

System Implementation

4.1 BackEnd Code

• generate traffic data()
The generate traffic data function simulates real-time traffic patterns by gen-
erating vehicle counts for each lane, factoring in the time of day. During rush
hours, the function boosts traffic values by 40–70% to mimic increased flow, while
nighttime periods reduce it by 40–60%. To maintain realism, it ensures that at
least one lane always experiences higher-than-normal traffic levels. This function
captures the dynamic and temporal nature of traffic, making it suitable for systems
that respond to fluctuating vehicle densities throughout the day.

Figure 4.1: generate traffic data

20
Chapter 4. System Implementation 21

• get congestion level()

The get congestion level function categorizes the severity of traffic congestion
based on the number of vehicles in a lane. It uses simple thresholding logic to clas-
sify congestion as “Low”, “Medium”, or “High”, which is essential for determining
traffic signal timing and rerouting strategies in other parts of the system.

Figure 4.2: Get congestion level

Chapter 4. System Implementation 22

• calculate green time()

The calculate green time function determines how long a traffic signal should
stay green for a specific lane based on current traffic volume and congestion at the
next intersection. It calculates a base green time and adjusts it using congestion
ratios and rush hour conditions, ensuring that intersections with higher traffic
receive longer green durations, while still maintaining minimum and maximum
limits for signal times to optimize traffic flow across intersections.

Figure 4.3: Calculate green time

Chapter 4. System Implementation 23

• predict congestion()
The predict congestion function uses a simple machine learning approach to
forecast future congestion levels for a specific lane. It collects recent traffic data
patterns—such as hour, day, and current vehicle count—and stores them for train-
ing a predictive model. If enough data is available, it trains a linear regression
model to predict the next vehicle count and translates that prediction into a con-
gestion level, allowing the system to make proactive traffic control decisions.

Figure 4.4: Predict congestion

Chapter 4. System Implementation 24

• update all traffic data()

The update all traffic data() function refreshes traffic conditions by generat-
ing new data for each intersection and printing the number of vehicles in every
lane. It resets the lane turn tracker for all intersections to start a new round-robin
cycle and then processes the updated traffic data to determine signal decisions.
This function helps maintain dynamic control over traffic flow by continuously
updating and recalculating lane priorities.

Figure 4.5: Update all traffic data

Chapter 4. System Implementation 25

• initialize traffic signals()

The initialize traffic signals() function sets all lanes to red and resets sig-
nal timers. It then identifies the lane with the highest vehicle count at each inter-
section and assigns it a green signal for a duration based on the traffic load, capped
between 10 and 20 seconds. This ensures that the busiest lanes are prioritized at
startup.

Figure 4.6: Initialize traffic signals

Chapter 4. System Implementation 26

• update signal status()

The update signal status() function manages the timing and transitions of
traffic signals at each intersection. It iterates through each intersection’s signal
data, decrementing the green light timers every second. If a timer reaches zero,
it turns the corresponding signal to red, updates the lane tracking for the current
cycle, and checks if the full cycle of green lights for all lanes at the intersection has
completed. If all lanes have turned green once, the cycle is marked as complete
and reset, allowing for a balanced distribution of green light time among all lanes.

Figure 4.7: Update signal status

Chapter 4. System Implementation 27

• home()
The home() function serves as the root endpoint of the backend API, provid-
ing a simple JSON response that describes the traffic control system, its version,
documentation link, and a list of available API endpoints. This acts as an in-
formational landing point for developers or systems interfacing with the backend,
allowing them to understand and explore its functionalities without navigating the
full documentation initially.

Figure 4.8: home

• should update data()

The should update data function determines whether traffic data should be re-
freshed based on the elapsed time since the last update. It calculates the time
difference between the current time and the last recorded update time, returning
True if more than 30 seconds have passed, signaling that a new data update is
warranted to maintain the system’s responsiveness to changing traffic conditions.

Figure 4.9: Should update data

• get traffic data()

The get traffic data function is responsible for managing real-time traffic data
and signal status across intersections. If enough time has passed, it triggers a full
data update; otherwise, it updates the green light timers, rotates green signals
among lanes based on traffic density, and ensures that each intersection has ex-
actly one active green light. It also compiles and returns a detailed list of decisions
for each lane, including current signal status, remaining time, traffic load, conges-
tion, predictions, and rerouting information. Additionally, the function includes a
failsafe mechanism to correct intersections that might end up with no green lights
due to timing or traffic anomalies.
Chapter 4. System Implementation 28

Figure 4.10: get traffic data

Chapter 4. System Implementation 29

• get intersections()
The get intersections function returns a list of all intersection identifiers man-
aged by the system along with the fixed number of lanes at each intersection. It
provides a concise overview of the road network structure being controlled, which
can be useful for frontend interfaces or external services querying the system’s
topology.

Figure 4.11: get intersections

• get traffic history()

The get traffic history function allows retrieval of recent traffic data history
up to a specified limit. It returns a snapshot of the system’s previous states in-
cluding signal decisions and traffic conditions, which can be helpful for monitoring
trends, debugging, or visualizing how the system has responded to varying traffic
over time. It ensures the response does not exceed available entries and includes
metadata about the number of records returned.

Figure 4.12: get traffic history

Chapter 4. System Implementation 30

• get congestion data()

The get congestion data function handles API requests to retrieve current traffic
congestion levels. It checks if new data is needed and updates it if necessary. It
then compiles a summary of congestion levels, vehicle counts, and predictions for
each lane across all intersections. It also calculates the overall percentage of lanes
in Low, Medium, and High congestion. The response includes detailed congestion
data, a timestamp, the last update time, and the remaining seconds until the next
update.

Figure 4.13: get congestion data

Chapter 4. System Implementation 31

• get rerouting data()

The get rerouting data function is an API endpoint that gathers and returns
information about current and newly created traffic reroutes. It first checks if traf-
fic data needs to be refreshed, and if so, updates all traffic metrics. The function
then iterates over all intersections and lanes to collect existing reroutes and as-
sess whether new reroutes are needed by evaluating traffic conditions—specifically,
when moderate congestion is detected at the current intersection and high con-
gestion at the next. If conditions warrant a reroute and none exists, the function
calculates the optimal target lane with the least traffic and creates a new reroute
entry. Finally, it compiles a list of all active reroutes along with metadata like
timestamps, congestion levels, and vehicle counts.

Figure 4.14: get rerouting data

Chapter 4. System Implementation 32

• get predictions()
The get predictions function serves as an endpoint for providing AI-based con-
gestion trend predictions for each lane at every intersection. After optionally
refreshing traffic data, it compares the current congestion levels with predicted
levels, determining whether the traffic trend is increasing, decreasing, or stable. It
packages this trend information along with the current and predicted congestion
states and vehicle counts into a structured dictionary. Additionally, it returns the
model’s confidence level based on whether the prediction model has been trained,
along with timing information for the last and next data update.

Figure 4.15: get predictions

Chapter 4. System Implementation 33

• force refresh()
The force refresh function is an endpoint that forcibly refreshes all traffic-
related data, ensuring the system reflects the most current vehicle counts, con-
gestion levels, and rerouting decisions. In addition to refreshing this data, it
reinitializes the traffic signals to guarantee each intersection has at least one green
light. The function returns a response confirming the update, including a times-
tamp and a summary of the decisions made during the data refresh.

Figure 4.16: force refresh

Chapter 4. System Implementation 34

• expire signals()
The expire signals function identifies green traffic lights whose durations have
expired since the last update and changes their status to red without selecting new
green lights. It calculates the time elapsed since the previous update and scans all
intersections and lanes to find any green signals that have exceeded their allowed
active duration. These are then turned off, and a record of the modified signals is
returned to indicate which traffic lights were updated due to expiration.

Figure 4.17: expire signals

Chapter 4. System Implementation 35

• setup()
The setup function is responsible for initializing the Arduino environment and
setting up essential components. It starts by waiting for the serial port to connect,
followed by displaying a debug message indicating that the Arduino has started.
The function then initializes sensors, traffic lights, and an LCD screen, clearing
and displaying the message ”Initializing...”. Data structures are also initialized
during this process. The function sets the startup time and initializes relevant
timers such as the starting time, initial count start time, and last display update
time. Finally, it displays a startup message on the LCD, confirming the completion
of the setup, and outputs a debug message for verification.

Figure 4.18: System Initialization and Hardware Setup

Chapter 4. System Implementation 36

• loop()
The loop function is responsible for continuously executing tasks within the Ar-
duino environment. It first checks if the startup delay is complete. If the delay
is finished, the function sets the startup completion flag to true and displays the
message ”Gathering counts” on the LCD for a specified duration. If the startup is
still in progress, the function gathers the initial counts. It calculates the elapsed
time since the initial count started and determines the remaining time until the
count gathering is completed. Every second, it updates the display with the re-
maining time and current counts. Once the initial count is completed, it clears
the LCD and displays the final vehicle counts on the screen. The LCD cursor is
positioned appropriately to show the data clearly.

Figure 4.19: Main Loop Execution Overview

Chapter 4. System Implementation 37

• processserialData()
The processserialData function is responsible for handling incoming serial data,
validating its integrity, and processing decisions related to traffic control. The
function first checks for any errors and exits early if an error is detected. It then
checks if the data contains traffic control-related information, specifically looking
for a key named ”decisions.” If found, it processes each decision, extracting relevant
details such as lane number and predicted congestion. Depending on the type of
decision (e.g., ”reroute”), the function updates the lane’s rerouting parameters
accordingly. The function also processes any sequence of decisions if provided,
handling the logic behind traffic signal sequences and updating lanes as required.
The function ensures that the necessary updates to lanes, including rerouting and
adjustments, are made efficiently.

Figure 4.20: processSerialData() Function Overview

Chapter 4. System Implementation 38

• initializeHardware()
The initializeHardware function is responsible for initializing all system com-
ponents related to the traffic control system. It begins by initializing the sensors
for each lane, iterating over all the lanes and sensors to ensure proper configura-
tion. Next, the function initializes the traffic lights for each lane, iterating through
all lanes and lights. After setting up the sensors and lights, the function sets all
traffic lights to red initially to ensure the system starts in a safe and controlled
state. This ensures that no traffic light is green until further processing occurs.

Figure 4.21: Initialize Hardware

Chapter 4. System Implementation 39

• handleSequence()
The handleSequence function is responsible for managing the sequence of traffic
light changes across lanes based on a predefined pattern. It first calculates the
elapsed time since the sequence started and checks if the current lane in the se-
quence has completed its allotted green light duration. If the time for the current
lane has expired, the function moves to the next lane by setting the current lane
to red and updating the sequence index. If there are more lanes in the sequence,
it sets the next lane’s light to green and updates the display to reflect the change.
Once all lanes in the sequence have been processed, the function ends the sequence,
resets the sequence index to 0, and sets all lights to red, ensuring a safe transition
back to the initial state.

Figure 4.22: Handle Sequence

Chapter 4. System Implementation 40

• displaySequenceStart()
The displaySequenceStart function is responsible for displaying the start of a
traffic light sequence on the LCD screen. It clears the screen and prints the message
”Sequence Start” to indicate that the sequence has begun. The function then sets
the cursor position and displays the lane information, including the lane number
and the green light duration for that specific lane. The function introduces a brief
delay to allow the information to be visible before the sequence progresses further.

Figure 4.23: Lane Sequence Start Display

• displaySequenceUpdate()
The displaySequenceUpdate function is responsible for updating the LCD screen
with the current status of a traffic light sequence. It first clears the screen and
displays the current lane information, including the lane number. The function
then sets the cursor position and shows the updated green light duration for that
lane. Additionally, the function displays the vehicle count for the lane. After
displaying the information, the function introduces a brief delay to allow the user
to see the updated data before the sequence continues.

Figure 4.24: Sequence Update Display

Chapter 4. System Implementation 41

• displaySequenceComplete()
The displaySequenceComplete function is responsible for indicating the comple-
tion of a traffic light sequence on the LCD screen. It first clears the screen and
displays the message ”Sequence” to show that the sequence is ending. The func-
tion then sets the cursor to a new position and prints ”Complete” to signal the
end of the sequence. A delay is introduced to ensure the message remains visible
for a brief period before the system proceeds to the next step.

Figure 4.25: End-of-Sequence Notification

Chapter 4. System Implementation 42

• displayRerouteInfo()
The displayRerouteInfo function is responsible for displaying rerouting infor-
mation for a specific lane on the LCD screen. It first checks if the lane requires
rerouting by verifying the needsReroute flag. If rerouting is needed, the function
clears the screen and displays the message ”Reroute L” followed by the lane index
(adjusted to a human-readable format). It then shows the lane’s new reroute
destination by printing the rerouteToLane value, omitting the first character
for display purposes. The function sets the cursor to display the reroute rea-
son (rerouteReason) for the lane, followed by a delay of 2000 milliseconds to
ensure the information is visible before the system proceeds.

Figure 4.26: Rerouting Information Display

• setLaneGreen()
The setLaneGreen function is responsible for setting the traffic light of a specific
lane to green. It first turns off the red light for the specified lane by setting
the corresponding pin to LOW. Then, it activates the green light by setting the
corresponding pin to HIGH, ensuring that the traffic light for that lane is switched
to green and allowing traffic to pass through that lane.

Figure 4.27: Lane Green Light Control

Chapter 4. System Implementation 43

• setLaneRed()
The setLaneRed function is responsible for setting the traffic light of a specific
lane to red. It first turns off the green light for the specified lane by setting the
corresponding pin to LOW. Then, it activates the red light by setting the corre-
sponding pin to HIGH, ensuring that the traffic light for that lane is switched to
red, signaling vehicles to stop and preventing traffic from moving through that
lane.

Figure 4.28: Lane Red Light Control

• setAllLightsToRed()
The setAllLightsToRed function is responsible for turning all traffic lights to red.
It iterates through all the lanes (from lane 0 to lane 3) and calls the setLaneRed
function for each lane to set its traffic light to red. This ensures that all lanes are
in a safe, non-green state, effectively stopping traffic in all directions.

Figure 4.29: Control All Lanes to Red

Chapter 4. System Implementation 44

• countCars()
The countCars function is responsible for counting the number of vehicles in each
lane by reading the sensor data at specified intervals. The function checks if enough
time has passed since the last sensor reading and then iterates over each lane and
its sensors. If the sensor detects a vehicle and enough time has passed since the last
vehicle was counted, the vehicle count for that lane is incremented. The function
also updates the display with the current count for each lane, showing the number
of vehicles detected. A brief delay ensures the count remains visible before the
system proceeds with further readings.

Figure 4.30: count Cars

Chapter 4. System Implementation 45

• updateDisplay()
The updateDisplay function is responsible for updating the display with the cur-
rent status of the traffic signal sequence. If the sequence is active, it calculates the
elapsed and remaining time for the current lane in the sequence, and then updates
the display with this information, including the lane number and the remaining
time for the green light. If the sequence has completed or is not active, the func-
tion clears the screen and displays a waiting message indicating that the sequence
is ongoing or that the system is waiting for the next step. The display is updated
periodically to reflect the current state of the system.

Figure 4.31: Update Display

Chapter 4. System Implementation 46

• initializeData()
The initializeData function is responsible for initializing the data structures
used to store information about each lane. It iterates through all lanes and sets
the initial values for each lane’s data. Specifically, the status is set to ”Red”, the
remaining time is reset, the vehicle count is set to zero, the congestion level is
initialized as ”LOW”, and the predicted congestion is also set to ”LOW”. Addi-
tionally, the needs for rerouting are set to false, and the reroute destination and
reason are cleared. The sequence length for each lane is initialized as well. This
setup ensures that all lanes start with default values, ready for processing during
the traffic control system’s operation.

Figure 4.32: Initialize Data

Chapter 5

Experimentation and Testing

The goal of utilizing numerous testing methodologies in your development process

is to make sure your software can successfully operate in multiple environments
and across different platforms. These can typically be broken down between func-
tional and non-functional testing. Functional testing involves testing the appli-
cation against the business requirements. It incorporates all test types designed
to guarantee each part of a piece of software behaves as expected by using uses
cases provided by the design team or business analyst. These testing methods are
usually conducted in order and include:

• Unit testing

• Integration testing

• System testing

• Acceptance testing

Non-functional testing methods incorporate all test types focused on the opera-
tional aspects of a piece of software. These include:

• Performance testing

• Security testing

• Usability testing

• Compatibility testing

Apply all these testing techniques to your final year project under the guidance of
your supervisor and an explanation of all these testing techniques is given below.
Write down your test cases in tabular form.
47
Chapter 5. Experimentation and Testing 48

5.1 Unit Testing

Unit testing is the first level of testing and is often performed by the develop-
ers themselves. It is the process of ensuring individual components of a piece of
software at the code level are functional and work as they were designed to. De-
velopers in a test-driven environment will typically write and run the tests prior
to the software or feature being passed over to the test team. Unit testing can
be conducted manually, but automating the process will speed up delivery cycles
and expand test coverage. Unit testing will also make debugging easier because
finding issues earlier means they take less time to fix than if they were discovered
later in the testing process.Perform unit test according to your project.
Chapter 5. Experimentation and Testing 49

5.1.1 Sensor Individual Count Accuracy

Test Case ID UT-001

Name Sensor Data Collection Accuracy
Description Verify that each sensor correctly detects and counts vehicles
passing through an intersection.
Preconditions
• The sensor must be properly installed and calibrated.

• The system must be powered on and actively recording

data.

• A test vehicle should be available for passing through

the sensor’s detection range.

Test Steps
• Place a single vehicle in front of the sensor.

• Observe whether the system detects the vehicle and

records the count.

• Remove the vehicle and check if the count resets or up-

dates correctly.

• Repeat the process 10 times to ensure consistent accu-

racy.

• Compare the recorded count with the actual number of

vehicles detected.

Expected Re-
sult • The system should correctly detect and count each ve-
hicle without missing or double-counting.

• The total count should match the actual number of ve-

hicles that passed through.

Status Passed

Table 5.1: Sensor Individual Count Accuracy

Chapter 5. Experimentation and Testing 50

5.1.1.1 Test Cases for 8 Sensors

Sr. No Sensor Name Expected Result Actual

Result
1 Sensor 1 (Lane 1) Correct detection and count Passed
2 Sensor 2 (Lane 2) Correct detection and count Passed
3 Sensor 3 (Lane 3) Correct detection and count Passed
4 Sensor 4 (Lane 4) Correct detection and count Passed
5 Sensor 5 (Lane 5) Correct detection and count Passed
6 Sensor 6 (Lane 6) Correct detection and count Passed
7 Sensor 7 (Lane 7) Correct detection and count Passed
8 Sensor 8 (Lane 8) Correct detection and count Passed

Table 5.2: Test Cases for 8 Sensors

Chapter 5. Experimentation and Testing 51

5.1.2 Sensor Connectivity Test

Test Case ID UT-002

Name Sensor Connectivity Test
Description Ensure that all sensors are properly connected to the micro-
controller (ESP32) and are transmitting data correctly.
Preconditions
• All hardware components (sensors, ESP32, power sup-
ply) must be powered on.

• The microcontroller should be running and ready to re-

ceive data.

Test Steps
• Physically inspect all sensor connections to ensure
proper wiring.

• Run a diagnostic test on the microcontroller to check if

sensors are transmitting signals.

• Verify sensor data output by manually triggering each

sensor (e.g., placing an object in front of it).

• Observe system logs or serial monitor output to confirm

data reception from each sensor.

• Reconnect any faulty sensor and repeat the test.

Expected Re-
sult • All sensors should successfully transmit data to the mi-
crocontroller without any interruptions.

• No connection failures should occur.

Status Passed

Table 5.3: Sensor Connectivity Test

Chapter 5. Experimentation and Testing 52

5.2 Integration Testing

After each unit is thoroughly tested, it is integrated with other units to create
modules or components that are designed to perform specific tasks or activities.
These are then tested as group through integration testing to ensure whole seg-
ments of an application behave as expected (i.e, the interactions between units
are seamless). These tests are often framed by user scenarios, such as logging
into an application or opening files. Integrated tests can be conducted by either
developers or independent testers and are usually comprised of a combination of
automated functional and manual tests.

5.2.1 Combined Sensor Count Accuracy

Test Case ID IT-001

Name Dual Sensor Combined Count Validation
Description Verify that two sensors installed on a road accurately detect
and combine vehicle counts without duplication or missed de-
tections.
Preconditions
• Both sensors must be properly installed and calibrated.

• The system must be actively collecting and processing

data.

• A test vehicle should be available for passing through

the detection area covered by both sensors.
Chapter 5. Experimentation and Testing 53

Test Steps
• Place a vehicle in the detection zone of Sensor 1 and
observe if it registers a count.

• Move the same vehicle into the detection zone of Sensor

2 and observe if the system registers a count.

• Check if the system correctly combines both detections

into a single count, ensuring that a single vehicle is not
counted twice.

• Repeat the process with multiple vehicles (at least 5)

entering the detection area simultaneously to verify ac-
curacy under real traffic conditions.

• Compare the combined sensor count with the actual

number of vehicles that passed through the sensors.

Expected Re-
sult • The system should correctly count each vehicle only
once, even if detected by both sensors.

• The combined count should accurately reflect the actual

number of vehicles passing through.

• No duplicate or missing counts should be recorded.

Status Passed

Table 5.4: Integration Testing

Chapter 5. Experimentation and Testing 54

5.2.1.1 Test Cases for 4 Roads

Sr. No Road Expected Result Actual

Result
1 Road 1 (Sensor 1 & Sensor Accurate combined count, no du- Passed
2) plicates
2 Road 2 (Sensor 3 & Sensor Accurate combined count, no du- Passed
4) plicates
3 Road 3 (Sensor 5 & Sensor Accurate combined count, no du- Passed
6) plicates
4 Road 4 (Sensor 7 & Sensor Accurate combined count, no du- Passed
8) plicates

Table 5.5: Test Cases for 4 Roads

Chapter 5. Experimentation and Testing 55

5.2.2 Traffic Light Adjustment Test

Test Case ID IT-002

Name Traffic Light Adjustment Based on Fixed Timing
Description Verify that the AI-controlled system adjusts traffic light tim-
ings based on real-time sensor data while maintaining the
fixed timing settings.
Preconditions
• Sensors must be active and detecting vehicles.

• AI model should be running and processing sensor data.

• Traffic light controllers must be functional and correctly

configured.

Test Steps
• Introduce vehicles at different traffic levels (low,
medium, and high congestion).

• Observe if the system processes sensor data and follows

the predefined fixed signal timings.

• Verify that the signal transitions occur without devia-

tion from the set timing schedule despite changing traffic
conditions.

• Measure the response time between vehicle detection

and light transition.

• Compare the observed signal changes with the prede-

fined fixed schedule to ensure consistency.
Chapter 5. Experimentation and Testing 56

Expected Re-
sult • Traffic lights change according to the fixed timing sched-
ule, regardless of traffic levels.

• The system processes sensor data correctly but does not

alter the timing dynamically.

• No delays or unexpected variations in light transitions

occur.

Status Passed

Table 5.6: Traffic Light Adjustment Test

Chapter 5. Experimentation and Testing 57

5.2.2.1 Test Cases for 3 Intersections

Sr. No Intersection Expected Result Actual

Result
1 Chowk A Traffic lights follow fixed timing Passed
despite varying traffic levels
2 Chowk B Traffic lights follow fixed timing Passed
despite varying traffic levels
3 Chowk C Traffic lights follow fixed timing Passed
despite varying traffic levels

Table 5.7: Test Cases for 3 Intersections

5.2.3 Real-Time Data Processing Test

Test Case ID IT-003

Name Real-Time Data Processing Accuracy
Description Verify that the system accurately processes real-time traffic
data received from sensors and transmits it to the processing
unit without errors or significant delays.
Preconditions
• Sensors must be actively detecting and transmitting
data.

• The processing unit must be operational and capable of

receiving real-time input.

• The system should be connected to a stable power and

network source.
Chapter 5. Experimentation and Testing 58

Test Steps
• Feed real-time traffic data by introducing vehicles in the
sensor detection area.

• Observe the raw sensor output and verify if it correctly

reflects the number of vehicles detected.

• Compare the processed data received by the system with

the raw sensor readings.

• Check for any mismatches between detected and pro-

cessed vehicle counts.

• Measure the delay between the moment a vehicle is

detected and when the system updates the processed
count.

• Repeat the test multiple times with different traffic lev-

els (low, medium, high) to ensure consistency.

Expected Re-
sult • The processed data should match the raw sensor inputs
without any errors.

• Data transmission should occur with minimal delay

(within an acceptable threshold).

• No missing, duplicate, or incorrect vehicle counts should

be recorded.

Status Passed

Table 5.8: Real-Time Data Processing Test

Chapter 5. Experimentation and Testing 59

5.2.3.1 Test Cases for 8 Scenarios

Sr. No Scenario Expected Result Actual

Result
1 Low traffic at Chowk A Data correctly processed with Passed
minimal delay
2 Medium traffic at Chowk B Data correctly processed with Passed
minimal delay
3 High traffic at Chowk C Data correctly processed with Passed
minimal delay
4 Sudden spike in vehicles at Data correctly processed with Passed
Chowk D minimal delay
5 Mixed traffic levels at Data correctly processed with Passed
Chowk E minimal delay
6 Sensor data fluctuation at Data correctly processed with Passed
Chowk F minimal delay
7 Peak hour congestion at Data correctly processed with Passed
Chowk G minimal delay
8 Off-peak hour testing at Data correctly processed with Passed
Chowk H minimal delay

Table 5.9: Test Cases for 8 Scenarios

Chapter 5. Experimentation and Testing 60

5.2.4 Power Supply Stability Test

Test Case ID IT-004

Name Power Supply Test
Description Ensure that the system remains operational under different
power conditions, including fluctuations and low voltage.
Preconditions
• The system must be powered by a stable power source.

• Voltage fluctuation testing equipment (e.g., a variable

power supply) should be available.

Test Steps
• Run the system on standard voltage (e.g., 5V or 12V,
depending on hardware requirements).

• Introduce slight voltage fluctuations by increasing or de-

creasing the power supply within safe limits.

• Observe the system’s performance under these condi-

tions and check if sensors and controllers remain active.

• Gradually restore the voltage to normal levels and verify

if the system recovers without requiring a manual reset.

• Repeat the test multiple times to ensure stability under

different conditions.

Expected Re-
sult • The system should function without unexpected shut-
downs, resets, or failures under minor voltage fluctua-
tions.

• Sensors and the microcontroller should continue operat-

ing normally.

Status Passed

Table 5.10: Power Supply Stability Test

Chapter 5. Experimentation and Testing 61

5.2.5 Vehicle Detection on Black Road Surface

Test Case ID IT-005

Name Vehicle Detection on Black Road Surface
Description Verify that the sensor correctly detects and counts vehicles
when the road surface is black.
Preconditions
• The system must be installed on a black-colored road.

• Sensors must be calibrated and active.

• Vehicles should be available for testing.

Test Steps
• Pass a vehicle through the sensor detection area on a
black road.

• Observe if the system correctly detects and counts the

vehicle.

• Repeat the process with multiple vehicles to confirm

consistency.

• Check for false detections or missed counts.

• Compare the actual vehicle count with the system’s

recorded count.

Expected Re-
sult • The system should accurately detect and count vehicles
without errors.

• No false detections should occur due to the black road

surface.

Status Passed

Table 5.11: Vehicle Detection on Black Road Surface

Chapter 5. Experimentation and Testing 62

5.2.6 Vehicle Detection on Grey Road Surface

Test Case ID IT-006

Name Vehicle Detection on Grey Road Surface
Description Verify that the sensor correctly detects and counts vehicles
when the road surface is grey.
Preconditions
• The system must be installed on a grey-colored road.

• Sensors must be calibrated and active.

• Vehicles should be available for testing.

Test Steps
• Pass a vehicle through the sensor detection area on a
grey road.

• Observe if the system correctly detects and counts the

vehicle.

• Repeat the process with multiple vehicles to confirm

consistency.

• Check for false detections or missed counts.

• Compare the actual vehicle count with the system’s

recorded count.

Expected Re-
sult • The system should accurately detect and count vehicles
without errors.

• No false detections should occur due to the grey road

surface.

Status Passed

Table 5.12: Vehicle Detection on Grey Road Surface

Chapter 5. Experimentation and Testing 63

5.2.7 False Vehicle Detection on White Road

Test Case ID IT-007

Name False Detection on White Road Surface
Description Verify if the system falsely detects road markings or surface
reflections as vehicles when the road surface is white.
Preconditions
• The system must be installed on a white-colored road.

• Sensors must be calibrated and active.

• Vehicles should be available for testing.

Test Steps
• Test the sensor on a white road surface without any
vehicles and check if it falsely detects vehicles.

• Pass a vehicle through the sensor detection area and

observe if the count is correct.

• Repeat the process multiple times to detect inconsisten-

cies.

• Check if road reflections or markings interfere with sen-

sor accuracy.

• Compare actual vehicle count with the system’s

recorded count.

Expected Re-
sult • The system should not detect false vehicles due to the
white road surface.

• If false detections occur, calibration adjustments should

be made.

Status Passed

Table 5.13: False Vehicle Detection on White Road

Chapter 5. Experimentation and Testing 64

5.2.8 Decision Tree Optimization for Traffic Light Control

Test Case ID IT-008

Name Decision Tree Optimization for Traffic Light Control
Description Verify that the decision tree algorithm correctly classifies traf-
fic conditions and determines appropriate traffic light timing.
Preconditions
• The decision tree model must be trained and integrated
into the system.

• Real-time traffic data should be available.

• The system should have a predefined set of classification

rules (e.g., Low, Medium, High traffic).

Test Steps
• Introduce traffic data into the system with varying levels
of congestion.

• Monitor the decision tree’s classification of traffic con-

ditions (e.g., Low, Medium, High).

• Verify if the classified traffic condition matches the ac-

tual traffic scenario.

• Check the traffic light response based on the classifica-

tion result.

• Compare decision tree classifications with expected out-

puts from historical data.

Expected Re-
sult • The decision tree should accurately classify traffic levels.

• Traffic lights should adjust based on the classification

without errors or misclassification.

Status Passed

Table 5.14: Decision Tree Optimization for Traffic Light Control

Chapter 5. Experimentation and Testing 65

5.3 System Testing

System testing is a black box testing method used to evaluate the completed and
integrated system, as a whole, to ensure it meets specified requirements. The
functionality of the software is tested from end-to-end.

5.3.1 Shared Sensor Count Data Across Intersections

Test Case ID ST-001

Name Sensor Data Sharing Between Intersections
Description Verify that a sensor at one intersection correctly shares its
vehicle count data with other intersections without data loss,
duplication, or delay.
Preconditions
• Sensors must be properly installed and calibrated at all
three intersections.

• Data-sharing functionality between intersections must

be enabled in the system.

• The network connection between intersections must be

stable.

• Vehicles should be available to pass through the sensors

at different intersections.
Chapter 5. Experimentation and Testing 66

Test Steps
• Pass a vehicle through Sensor 1 at Intersection A and
observe if it registers a count.

• Verify that Intersection B and Intersection C receive the

same count data in real-time.

• Repeat the test by passing vehicles through Sensor 2 at

Intersection B and check if Intersection A and C receive
the updated shared count.

• Introduce multiple vehicles at different intersections si-

multaneously and verify if all sensors correctly update
their counts without any delay or missing data.

• Check the total shared count at all three intersections

and compare it with the actual number of vehicles de-
tected across all sensors.

Expected Re-
sult • Each intersection should correctly receive shared count
data from the other intersections.

• The total count at each location should reflect all vehi-

cles detected across the network.

• No duplicate counts, missing data, or delays should oc-

cur.

Status Passed

Table 5.15: Shared Sensor Count Data Across Intersections

Chapter 5. Experimentation and Testing 67

5.3.1.1 Test Cases for 24 Sensors

Sr. No Sensor Expected Result Actual

Result
1 Sensor 1 (Intersection A) Shared count received by B and Passed
C
2 Sensor 2 (Intersection A) Shared count received by B and Passed
C
3 Sensor 3 (Intersection A) Shared count received by B and Passed
C
4 Sensor 4 (Intersection A) Shared count received by B and Passed
C
5 Sensor 5 (Intersection B) Shared count received by A and Passed
C
6 Sensor 6 (Intersection B) Shared count received by A and Passed
C
7 Sensor 7 (Intersection B) Shared count received by A and Passed
C
8 Sensor 8 (Intersection B) Shared count received by A and Passed
C
9 Sensor 9 (Intersection C) Shared count received by A and Passed
B
10 Sensor 10 (Intersection C) Shared count received by A and Passed
B
11 Sensor 11 (Intersection C) Shared count received by A and Passed
B
12 Sensor 12 (Intersection C) Shared count received by A and Passed
B
13 Sensor 13 (Intersection A) Shared count received by B and Passed
C
14 Sensor 14 (Intersection A) Shared count received by B and Passed
C
15 Sensor 15 (Intersection A) Shared count received by B and Passed
C
16 Sensor 16 (Intersection A) Shared count received by B and Passed
C
17 Sensor 17 (Intersection B) Shared count received by A and Passed
C
Chapter 5. Experimentation and Testing 68

18 Sensor 18 (Intersection B) Shared count received by A and Passed

C
19 Sensor 19 (Intersection B) Shared count received by A and Passed
C
20 Sensor 20 (Intersection B) Shared count received by A and Passed
C
21 Sensor 21 (Intersection C) Shared count received by A and Passed
B
22 Sensor 22 (Intersection C) Shared count received by A and Passed
B
23 Sensor 23 (Intersection C) Shared count received by A and Passed
B
24 Sensor 24 (Intersection C) Shared count received by A and Passed
B

Table 5.16: Test Cases for 24 Sensors

5.3.2 Model Adaptation Test

Test Case ID ST-002

Name Model Adaptation
Description Ensure that the model adapts to changing traffic patterns and
improves over time.
Preconditions
• The model should be integrated into the system.

• The system should have a mechanism to update the

model based on new traffic data.

• Historical traffic data should be available for compari-

son.
Chapter 5. Experimentation and Testing 69

Test Steps
• Introduce traffic patterns into the system and observe
how the model initially responds.

• Allow the model to learn over multiple iterations by

exposing it to changing traffic conditions.

• Compare traffic light adjustments over time to see if the

model is optimizing its decisions.

• Check the model’s reward function and verify that it is

reinforcing better traffic flow decisions.

• Measure improvements in response time, congestion re-

duction, and efficiency after multiple learning cycles.

Expected Re-
sult • The model should improve its decisions over time.

• Traffic signals should become more efficient as the model

learns from real traffic patterns.

Status Passed

Table 5.17: Model Adaptation Test

5.4 Acceptance Testing

Acceptance testing is the last phase of functional testing and is used to assess
whether or not the final piece of software is ready for delivery. It involves ensuring
that the product is in compliance with all of the original business criteria and that
it meets the end user’s needs. This requires the product be tested both internally
and externally, meaning you’ll need to get it into the hands of your end users for
beta testing. Beta testing is key to getting real feedback from potential customers
and can address any final usability concerns.

5.5 Performance Testing

Performance testing is a non-functional testing technique used to determine how
an application will behave under various conditions. The goal is to test its respon-
siveness and stability in real user situations. Performance testing can be broken
Chapter 5. Experimentation and Testing 70

down into four types:

• Load testing is the process of putting increasing amounts of simulated de-

mand on your software, application, or website to verify whether or not it
can handle what it’s designed to handle.

• Stress testing takes this a step further and is used to gauge how your software
will respond at or beyond its peak load. The goal of stress testing is to
overload the application on purpose until it breaks by applying both realistic
and unrealistic load scenarios. With stress testing, you’ll be able to find the
failure point of your piece of software.

• Endurance testing, also known as soak testing, is used to analyze the behav-
ior of an application under a specific amount of simulated load over longer
amounts of time. The goal is to understand how your system will behave
under sustained use, making it a longer process than load or stress testing
(which are designed to end after a few hours). A critical piece of endurance
testing is that it helps uncover memory leaks.

• Spike testing is a type of load test used to determine how your software will
respond to substantially larger bursts of concurrent user or system activity
over varying amounts of time. Ideally, this will help you understand what
will happen when the load is suddenly and drastically increased.
Chapter 5. Experimentation and Testing 71

5.5.1 Standard Processing Speed Test

Test Case ID PT-01

Name Standard Traffic Light Processing Speed
Description Measure the time taken for the system to process vehicle de-
tection and execute the fixed signal timing.
Preconditions
• The system must be operational and sensors must be
active.

• Traffic lights should be functioning with a predefined

timing schedule.

• A timer or stopwatch should be available for measuring

response time.

Test Steps
• Introduce vehicles near the sensor detection area.

• Start a timer when the vehicle is detected.

• Observe if the system recognizes the detection and main-

tains the fixed signal timing.

• Stop the timer when the traffic light changes.

• Record the delay and compare it with the expected fixed

signal schedule.

Expected Re-
sult • The system should maintain the fixed signal timing and
execute changes without unexpected delays.

Status Passed

Table 5.18: Standard Processing Speed Test

Chapter 5. Experimentation and Testing 72

5.5.2 High Traffic Load Processing Test

Test Case ID PT-02

Name Traffic Light Adjustment Under High Load
Description Measure system processing speed when detecting a high vol-
ume of vehicles.
Preconditions
• The system must be operational.

• A minimum of 10 vehicles should be present near the

sensor at the same time.

Test Steps
• Introduce high-density traffic near the sensor detection
area.

• Measure the time taken for the system to register all

vehicles.

• Observe if any sensor lag occurs due to excessive data

processing.

• Compare the light adjustment timing with the standard

fixed signal schedule.

Expected Re-
sult • The system should process all vehicles without delay
while maintaining its predefined timing.

Status Passed

Table 5.19: High Traffic Load Processing Test

Chapter 5. Experimentation and Testing 73

5.5.3 Low Traffic Load Processing Test

Test Case ID PT-03

Name Traffic Light Adjustment Under Low Load
Description Verify that the system correctly detects and adjusts signals
when only a few vehicles are present.
Preconditions
• The system must be operational.

• Only one or two vehicles should be in the detection zone.

Test Steps
• Introduce a single vehicle near the sensor detection area.

• Start a timer upon vehicle detection.

• Observe if the system correctly maintains the fixed sig-

nal timing.

• Compare the actual delay with the expected signal tran-

sition time.

Expected Re-
sult • The system should follow the fixed timing schedule with-
out skipping or accelerating changes.

Status Passed

Table 5.20: Low Traffic Load Processing Test

Chapter 5. Experimentation and Testing 74

5.5.4 Sensor Data Loss and Recovery Speed Test

Test Case ID PT-04

Name Sensor Data Loss and Recovery Speed
Description Verify how quickly the system recovers from a temporary sen-
sor failure and resumes normal signal operations.
Preconditions
• The system should be operational with all sensors ac-
tive.

• Ability to manually disable and re-enable a sensor for

testing.

Test Steps
• Manually disconnect a sensor from the system.

• Observe how long the system takes to detect and re-

spond to the missing sensor data.

• Reconnect the sensor and measure the recovery speed.

• Verify if the system resumes normal signal processing

without affecting fixed timing operations.

Expected Re-
sult • The system should detect and log sensor failure quickly.

• Upon sensor reactivation, the system should resume pro-

cessing without delay.

Status Passed

Table 5.21: Sensor Data Loss and Recovery Speed Test

Chapter 5. Experimentation and Testing 75

5.5.5 Multiple Intersection Coordination Test

Test Case ID PT-05

Name Traffic Flow Coordination Across Multiple Intersections
Description Verify that the system properly coordinates traffic signals
across multiple intersections to maintain smooth traffic flow.
Preconditions
• The system should be deployed at multiple intersections.

• Sensors and traffic light controllers at all intersections

must be active and communicating.

• The network for data sharing between intersections

should be stable.

Test Steps
• Simulate vehicle movement through multiple intersec-
tions in a predefined sequence.

• Observe if traffic signals at all intersections are synchro-

nized based on shared traffic data.

• Compare actual traffic flow with expected smooth coor-

dination based on system design.

Expected Re-
sult • Traffic signals across all intersections should be coordi-
nated to minimize stops and congestion.

• There should be no unnecessary delays or conflicting

signal changes between intersections.

Status Passed

Table 5.22: Multiple Intersection Coordination Test

Chapter 5. Experimentation and Testing 76

5.5.6 Long-Term Sensor Accuracy Test

Test Case ID PT-06

Name Long-Term Sensor Accuracy Test
Description Verify if sensors maintain accuracy in vehicle detection over
extended periods of use.
Preconditions
• Sensors should be installed and actively recording traffic
data.

• A baseline accuracy reading should be recorded at the

start of testing.

• The system should be operating continuously for an ex-

tended period.

Test Steps
• Record initial sensor accuracy by comparing sensor-
detected vehicle counts with manual counts.

• Allow the system to run for an extended period (e.g.,

days or weeks).

• Check for accuracy degradation due to environmental

factors like dust, temperature, or wear and tear.

• Perform recalibration if needed and measure improve-

ment in sensor accuracy.

Expected Re-
sult • Sensor accuracy should remain high over time, with
minimal degradation.

• If accuracy declines, recalibration should restore correct

readings.

Status Passed

Table 5.23: Long-Term Sensor Accuracy Test

Chapter 5. Experimentation and Testing 77

5.6 Security Testing

With the rise of cloud-based testing platforms and cyber attacks, there is a grow-
ing concern and need for the security of data being used and stored in software.
Security testing is a non-functional software testing technique used to determine if
the information and data in a system is protected. The goal is to purposefully find
loopholes and security risks in the system that could result in unauthorized access
to or the loss of information by probing the application for weaknesses. There are
multiple types of this testing method, each of which aimed at verifying five basic
principles of security:

• Integrity

• Confidentiality

• Authentication

• Authorization

• Availability
Chapter 5. Experimentation and Testing 78

5.6.1 Unauthorized Access Test

Test Case ID ST-01

Name Unauthorized Access Test
Description Check if unauthorized users can manipulate system settings
or traffic light controls.
Preconditions
• The system must have authentication and access control
mechanisms enabled.

• Administrator credentials should be required for making

any changes.

Test Steps
• Attempt to log in using invalid credentials and observe
the system’s response.

• Try to modify traffic light settings without proper au-

thorization.

• Monitor system logs to verify if unauthorized access at-

tempts are detected and logged.

• Check if access is blocked and whether an alert is trig-

gered for unauthorized activity.

Expected Re-
sult • Unauthorized users should not be able to change traffic
light settings.

• The system should log and alert administrators about

unauthorized access attempts.

Status Passed

Table 5.24: Unauthorized Access Test

Chapter 5. Experimentation and Testing 79

5.6.2 Data Encryption Test

Test Case ID ST-02

Name Data Encryption Test
Description Verify that all traffic data is securely encrypted before trans-
mission to prevent data interception.
Preconditions
• Encryption protocols must be enabled in the system.

• A network monitoring tool should be available to check

data packets.

Test Steps
• Capture real-time data packets being transmitted be-
tween sensors and the processing unit.

• Analyze the captured data to check if it is in encrypted

form.

• Attempt to decrypt the data using unauthorized meth-

ods.

• Verify if encryption prevents unauthorized data access.

Expected Re-
sult • Data should be securely encrypted and not readable in
plain text.

• Unauthorized decryption attempts should fail.

Status Passed

Table 5.25: Data Encryption Test

Chapter 5. Experimentation and Testing 80

5.6.3 Brute Force Login Protection Test

Test Case ID ST-03

Name Brute Force Login Protection Test
Description Ensure the system blocks multiple incorrect login attempts to
prevent brute-force attacks.
Preconditions
• The system must have a login mechanism with security
measures in place.

• A user account should be available for testing.

Test Steps
• Enter incorrect passwords multiple times in rapid suc-
cession.

• Observe if the system temporarily locks the account af-

ter multiple failed attempts.

• Wait for the lockout period and check if access is re-

stored automatically or requires admin intervention.

• Try logging in after the lockout period and verify system

behavior.

Expected Re-
sult • The system should lock the account after multiple failed
attempts.

• The lockout period should be enforced as per security

policies.

Status Passed

Table 5.26: Brute Force Login Protection Test

Chapter 5. Experimentation and Testing 81

5.6.4 Data Tampering Prevention Test

Test Case ID ST-04

Name Data Tampering Prevention Test
Description Ensure that traffic data is protected from unauthorized mod-
ifications.
Preconditions
• The system must have integrity verification mechanisms
in place.

• An attempt should be made to alter stored or transmit-

ted data.

Test Steps
• Attempt to modify stored traffic data in the database
or logs.

• Observe if the system detects the unauthorized modifi-

cation.

• Check for system alerts or logs that indicate an integrity

violation.

• Verify if original data remains protected or if tampered

data is discarded.

Expected Re-
sult • Any unauthorized modification attempt should be de-
tected and logged.

• The system should either reject tampered data or re-

store the original values.

Status Passed

Table 5.27: Data Tampering Prevention Test

Chapter 5. Experimentation and Testing 82

5.7 Usability Testing

Usability testing is a testing method that measures an application’s ease-of-use
from the end-user perspective and is often performed during the system or accep-
tance testing stages. The goal is to determine whether or not the visible design
and aesthetics of an application meet the intended workflow for various processes,
such as logging into an application.

5.8 Compatibility Testing

Compatibility testing is used to gauge how an application or piece of software will
work in different environments. It is used to check that your product is compatible
with multiple operating systems, platforms, browsers, or resolution configurations.
The goal is to ensure that your software’s functionality is consistently supported
across any environment you expect your end users to be using.
Chapter 6

Results and Outputs

6.1 Outputs
• laneDisplayComponent
The laneDisplayComponent function displays a detailed list of lanes labeled from
L1-L1 to L6-L1, each marked with indicators such as ”High Congestion” and ”Ve-
hicles” to represent the current traffic status. The status for all lanes is initially
set to ”Green,” indicating normal traffic flow. Each lane entry also includes a
note stating ”Remaining Traffic directed to [next lane number] - L1,” suggesting
that traffic is being systematically redirected to subsequent lanes to manage con-
gestion. This repetitive structure implies a standardized approach to managing
traffic flow across multiple lanes, ensuring efficient congestion control and smooth
traffic direction.

Figure 6.1: Adaptive Traffic Flow Management Report

83
Chapter 6. Results and Outputs 84

• smartTrafficReroutingComponent
The smartTrafficReroutingComponent showcases the ”Smart Traffic Rerouting”
AI-based traffic control system. The component is divided into two main sections.
The first section, labeled ”AI Traffic Prediction,” displays traffic trends through
three indicators: an increasing trend at 0%, a stable trend at 12%, and a decreasing
trend at 0%, all assessed with a medium model confidence level. The second
section, labeled ”Intersection Prediction,” presents a table summarizing traffic
conditions at various intersections (I1 to I3), with subcategories for each lane (L1
to L4). This section highlights the traffic levels (e.g., High, Medium) and lane
congestion statuses (e.g., High -¿ High -¿ High) to provide a comprehensive view
of the current state at each intersection, facilitating effective traffic management
and rerouting decisions.

Figure 6.2: Smart Traffic Rerouting

Chapter 6. Results and Outputs 85

• reroutingInstructionComponent
The reroutingInstructionComponent displays a table from the ”Smart Traffic
Rerouting” system, focusing on rerouting instructions for traffic management. The
table maps specific intersections and lanes (e.g., I1-L1 to I2-L2) to new routes (e.g.,
I2-L1, I2-L3), with accompanying reasons for rerouting, such as ”Next intersection
lane is congested.” It also indicates the traffic levels at the destination intersec-
tions, marked as High or Medium, to help guide real-time traffic flow adjustments,
ensuring efficient rerouting and reduced congestion across the network.

Figure 6.3: Traffic Flow Adjustment Map

Chapter 6. Results and Outputs 86

• currentTrafficDensityChart
The currentTrafficDensityChart function generates a chart titled ”Current
Traffic Density,” which illustrates traffic levels on a scale from 0 to 60. The x-axis
represents time intervals, such as l1-L1, l1-L2, and so on, while the data is seg-
mented into categories including Traffic, Congestion, Hourly, and Signals. These
categories provide a breakdown of traffic density metrics across specific time slots.
This visualization aids in monitoring real-time traffic conditions and identifying
peak congestion periods, enabling informed decisions for traffic management.

Figure 6.4: Current Traffic Density

Chapter 6. Results and Outputs 87

• congestionTrendsOverTimeGraph
The congestionTrendsOverTimeGraph function generates a line graph titled ”Con-
gestion Trends Over Time,” which tracks congestion levels with values ranging
from 0 to 12. The x-axis displays timestamps, such as 06:09:38 and 06:14:31, cor-
responding to dates like April 16, 2025. The graph also incorporates categories
including Traffic, Congestion, Hourly, and Signals, representing the metrics be-
ing analyzed. This visualization helps in monitoring congestion fluctuations over
short intervals, providing valuable insights for trend analysis and improving system
responsiveness to dynamic traffic conditions.

Figure 6.5: Congestion Trends Over Time

Chapter 6. Results and Outputs 88

• signalDistributionChart
The signalDistributionChart function generates a pie chart titled ”Signal Dis-
tribution,” illustrating the proportion of traffic signals with 25% Green and 75%
Red. Below the chart, categories such as Traffic, Congestion, Hourly, and Signals
contextualize the data, likely reflecting signal efficiency or phase timing. This vi-
sualization emphasizes the dominance of red signals, which may be associated with
high congestion or extended wait times, helping to identify potential bottlenecks
in the traffic flow.

Figure 6.6: Signal Distribution

Chapter 6. Results and Outputs 89

• recentTrafficHistoryTable
The recentTrafficHistoryTable function generates a table titled ”Recent Traf-
fic History,” recording high-congestion events. It includes columns for Timestamp,
Total Vehicles, High Congestion (lanes affected), and Status. Vehicle counts range
from 329 to 381, with congestion impacting 10–12 lanes, all marked as ”High.”
This table offers a historical log of traffic surges, enabling the identification of
recurring bottlenecks and providing insights into system performance, aiding in
traffic management optimization.

Figure 6.7: Recent Traffic History

Chapter 6. Results and Outputs 90

• trafficControlDashboard
The trafficControlDashboard, which serves as a centralized interface for mon-
itoring traffic flow, client-specific routing, and system-wide operations. Key sec-
tions of the dashboard include the DataBoard, which features tabs like Analytics
and AI Config. The dashboard displays a ”Current Traffic Density” chart, where
lanes are labeled from I1-L1, I1-L2, etc. This chart illustrates traffic levels on a
scale from 0 to 60, with time intervals plotted along the x-axis. The data is seg-
mented into categories such as Traffic, Congestion, Hourly, and Signals, offering
a breakdown of traffic density metrics for specific time slots. This visualization
allows users to monitor real-time traffic conditions and identify peak congestion
periods.
Additionally, the ”Congestion Trends Over Time” line graph tracks congestion
levels ranging from 0 to 12. The x-axis shows timestamps from April 16, 2025,
with categories such as Traffic, Congestion, Hourly, and Signals. This graph helps
analyze short-term congestion trends, enabling improved system responsiveness
and trend analysis for more informed traffic management decisions.

Figure 6.8: Traffic Control Dashboard

Chapter 6. Results and Outputs 91

• analyticsSection
The analyticsSection function provides a visual analysis through various charts,
including Line and Bar Charts. One such chart, titled ”Current Traffic Density,”
illustrates traffic levels on a scale from 0 to 60, with time intervals labeled as l1-L1,
l1-L2, and so on, plotted along the x-axis. This data is segmented into categories
like Traffic, Congestion, Hourly, and Signals, which provide a breakdown of traffic
density metrics across specific time slots. This chart is useful for monitoring real-
time traffic conditions and identifying peak congestion periods.
Additionally, the ”Congestion Trends Over Time” line graph tracks congestion lev-
els, with values ranging from 0 to 12. The x-axis features timestamps from April
16, 2025, such as 06:09:38 and 06:14:31, while the metrics analyzed include Traffic,
Congestion, Hourly, and Signals. This graph offers valuable insights into conges-
tion fluctuations over short intervals, helping with trend analysis and improving
the system’s responsiveness.

Figure 6.9: Analytics

Chapter 6. Results and Outputs 92

• AIConfigurationSection
The AIConfigurationSection function outlines the traffic system’s AI model,
which incorporates algorithms such as LinearRegression and DecisionTree. These
algorithms have been trained on over 100 data points, achieving a prediction accu-
racy ranging from 75% to 85%. The section includes key metrics such as ”Conges-
tion Prediction Accuracy (82%)” and ”Signal Timing Efficiency (78%)” presented
in a tabular format.
Additionally, explanatory text details how the AI system analyzes temporal pat-
terns and vehicle counts to optimize traffic signals, ensuring smoother flow. This
section highlights the system’s predictive capabilities and operational logic, show-
casing its ability to adjust and manage traffic signals effectively based on real-time
data and patterns.

Figure 6.10: AI Configuration

Chapter 6. Results and Outputs 93

• TrafficAIAlertCenter
The TrafficAIAlertCenter displays real-time notifications such as ”High Con-
gestion Detected” and ”Signal Timing Adjusted,” categorized under labels like
”Traffic Congestion.” Each notification is associated with a timestamp and in-
cludes actions such as ”Mark all as read” for efficient alert management.
Below the notifications, a ”Hidden Message Details” table provides more in-depth
information, such as ”2 armed alerts,” ensuring that critical events are promptly
addressed. This interface is designed to prioritize incident response and system
maintenance, keeping operators updated in real-time to manage traffic flow effec-
tively and maintain system performance.

Figure 6.11: TrafficAI Alert Center

Chapter 6. Results and Outputs 94

• SystemSettingsPage()
The SystemSettingsPage function presents the settings for the TrafficAI dash-
board, with the last update timestamped as April 15, 2025. Key sections in the
settings page include:

• Analytics: Enabled

• AI Config: Configurable

• Alerts & Logs: Disabled

Below the settings, the system administrator’s account information is displayed,

including the email ”[email protected].” The page also features sections
for security settings, such as the option to change the password, and includes
contact details like a phone number.
At the bottom, the footer specifies the system version as ”TrafficAI System v1.0”
and a copyright notice for ”Smart Traffic Systems.” The layout is clean and func-
tional, emphasizing administrative controls and user account management for ef-
fective system operation.

Figure 6.12: TrafficAI Admin Panel

Chapter 7

Conclusions and Future Direction

7.1 Conclusion
This project presents the design and implementation of an automated traffic light
signaling system aimed at improving urban traffic flow using real-time data and
intelligent decision-making algorithms. The system integrates traffic sensors to
monitor vehicle density and waiting times, using machine learning models — such
as decision trees to determine optimal signal timings.
The solution addresses major drawbacks of traditional static signal systems by
offering adaptability, scalability, and responsiveness. With a user-friendly interface
for monitoring and a modular backend powered by platforms like ESP32, the
system ensures real-time performance in dynamic traffic conditions.
Through testing and evaluation, the system successfully demonstrated its ability
to reduce congestion, minimize vehicle idle time, and respond efficiently to varying
traffic loads. The project lays a strong foundation for smart city infrastructure
and paves the way for intelligent transportation systems in urban environments.

7.2 Future Work and Direction

After a collaborative meeting with the client and stakeholders, several key direc-
tions have been identified for future development and improvement of the system:

• Model Enhancement: The current AI models will be further trained and

optimized using more diverse and real-time datasets to improve accuracy
and adaptability.

• Sensor Replacement: The client has suggested replacing traditional IR

sensors with more advanced technologies such as LiDAR or camera-based
95
Chapter 7. Conclusions and Future Direction 96

object detection systems to improve reliability and precision under various

environmental conditions.

• Privacy-Oriented Features: Certain requirements, which are confidential

as per client agreement, have been documented privately. These will be
addressed in future iterations to comply with client-specific operational and
security needs.

• Mobile Application Integration: A companion mobile application may

be developed in future for real-time monitoring, data logging, and manual
override by authorized personnel.

• Predictive Traffic Management: The future version may also include a

prediction module that forecasts traffic patterns based on historical and live
data to pre-emptively manage congestion.

These improvements aim to evolve the system into a fully adaptive, AI-powered
traffic control solution suitable for modern smart cities.
References

[1] C. Chen and C. Wei. A hybrid traffic flow prediction model based on machine
learning techniques. IEEE Transactions on Intelligent Transportation Systems,
20(4):1482–1494, 2019. doi: 10.1109/TITS.2018.2842644.

[2] O. C. Z. Gotel and A. Finkelstein. An analysis of the requirements traceability

problem. In Proceedings of the IEEE International Symposium on Require-
ments Engineering, pages 94–101, 1994. doi: 10.1109/ISR.E.1994.32666.

[3] R. W. Hall. Traffic Flow Theory: A State-of-the-Art Report. Transportation

Research Board, National Research Council, 2014.

[4] G. Kotonya and I. Sommerville. Requirements Engineering: Processes and

Techniques. John Wiley & Sons, 1998.

[5] J. Lamm and M. Murtagh. Non-functional requirements in software engineer-

ing: An overview. Journal of Systems and Software, 137:15–26, 2018. doi:
10.1016/j.jss.2017.10.034.

97