OENG1278 Digital Fundamentals

Project Report – Group ANY

Course Instructor: Mr. Thach Nguyen

Practical Tutor: Mr. Dinesh Rano

Student Names Student Numbers

Akshat Sejwal s4139920

Naman Khandelwal s4140000

Yuva Srivastava S4139987

School of Engineering, STEM College

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Statement of Contribution
Student Name Student Number Contribution
Akshat Sejwal s4139920 Contributed to the development of
the hardware and circuitry of the
project, which includes figuring out
important connections, grounding,
and breadboard use.

Naman Khandelwal s4140000 Had the highest contribution to the

making of the Project Report.
Contributed to the development
Truth Tables and K-Maps and all
other Boolean logic expressions.

Yuva Srivastava S4139987 Contributed to the software

development of the project, that
includes figuring out the Simulink
Logic Circuit and Stateflow model.
Also contributed to the making of
the report.

Page 2 of 23
 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

1. Introduction/Problem statement
In modern traffic management, the efficient and safe operation of traffic lights plays a
critical role in regulating traffic flow and ensuring the safety of both drivers and
pedestrians. Traditional traffic light systems operate on fixed-time cycles or simple
sensor-based triggers, which may not always be optimal, especially in dynamic and
unpredictable traffic conditions. The need for intelligent traffic control systems that adapt
to real-time traffic flow has led to the development of more sophisticated traffic light
control systems.

This project aims to design, simulate, and implement a traffic light control system using
a finite state machine (FSM) to model the different states of the traffic light sequence
(Red, Green, Yellow). The system will also incorporate sensors to detect the presence
of vehicles and adjust the light cycle accordingly, enhancing the flow of traffic and
reducing unnecessary waiting times.

1.1. State the problem

 The primary objective of this project is to develop a traffic light control system
that dynamically adjusts its operation based on real-time inputs, such as vehicle
presence or pedestrian crossings. Traditional traffic lights rely on pre-set timing,
which may not adapt well to changing traffic conditions. For example, in low-
traffic conditions, a fixed cycle may cause unnecessary delays, while in high-
traffic scenarios, vehicles may be stuck waiting for a green light on an
underserved road.

 The challenge is to design a system that efficiently manages traffic lights using a
finite state machine (FSM) model and responds to inputs from sensors. The
traffic light must adjust its state transitions in real-time based on vehicle
detection, while also ensuring safety and fairness in handling pedestrian
crossings. This will involve simulating the traffic control system

Page 3 of 23
 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

MATLAB/Simulink, designing the FSM, and validating the system through various
test cases, including edge cases and real-world traffic scenarios.

 The outcome of this project will be an adaptable and efficient traffic control
system that prioritizes vehicle flow while considering pedestrian safety and
minimizing unnecessary delays.

1.2. Input/output descriptions

1. Input Specifications

1. Vehicle Detection (Sensor):

o Overview: A sensor (infrared, ultrasonic, or similar) placed on or near the
intersection to detect the presence of vehicles.
o Type: Binary input (vehicle detected or not detected).
o Purpose: Upon detecting a vehicle, the system may adjust the light
sequence, such as keeping the green light on for longer to allow the vehicle
to pass.
2. Pedestrian Request Button:
o Overview: A button located at the intersection, pressed by pedestrians who
wish to cross the road.
o Type: Binary input (pressed or not pressed).
o Purpose: When pressed, the system changes the traffic light cycle, typically
signaling a transition to allow pedestrians to cross safely.
3. Time Interval (Optional):
o Overview: A timer or clock signal that dictates the fixed duration of each
traffic light state (Green, Yellow, Red).
o Type: Analog or digital input (time-based).
o Purpose: Used for pre-programmed, time-based control of the traffic light
cycle if sensor-based inputs are not used, ensuring predictable signal
changes.
4. Emergency Vehicle Detection (Optional):
o Overview: A sensor or special signal used to detect the presence of
emergency vehicles such as ambulances or fire trucks.
o Type: Binary input (detected or not detected).
o Purpose: When an emergency vehicle is detected, the system prioritizes
the vehicle, overriding normal cycles to grant immediate green light
passage.

Page 4 of 23
 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

2. Output Specifications

o Traffic Light Status (Red, Yellow, Green LEDs):

o Overview: LEDs representing the traffic light states: Red (stop), Yellow
(prepare to stop), and Green (go).
o Type: Digital output (on/off for each LED).
o Purpose:
o Red: Stops vehicles and signals to pedestrians that they can cross.
o Yellow: Warns vehicles that the light will change soon.
o Green: Allows vehicles to pass while pedestrians wait.
o Pedestrian Crossing Signal:
o Overview: An indicator (LED or display) showing when pedestrians are
allowed to cross the street.
o Type: Digital output (on/off).
o Purpose: Activated when the pedestrian button is pressed or when the
system enters a pedestrian crossing phase.
o Emergency Vehicle Priority Signal (Optional):
o Overview: A system output that grants priority to emergency vehicles by
altering the light sequence to clear the intersection quickly.
o Type: Digital output (on/off).
o Purpose: Overrides the normal traffic signal cycle to allow emergency
vehicles to pass through the intersection with minimal delay.
o Traffic Light Timing (Optional):
o Overview: A visual or logged output indicating the duration that each light
remains active (Green, Yellow, Red).
o Type: Analog or digital output (display/logging).
o Purpose: Provides a record or live display of the time each traffic light colour
stays on, helpful for monitoring and adjusting signal durations.
o

Summary of Inputs and Outputs

Input Output
Traffic Light Signals (Red, Yellow,
Vehicle Detection Sensor
Green LEDs)
Pedestrian Request Button Pedestrian Crossing Indicator (LED)
Traffic Light Timing Information
Time Interval (Optional)
(Optional)
Emergency Vehicle Detection (Optional) Emergency Vehicle Priority Signal

Page 5 of 23
 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

2. Algorithm design
State Allotment

The output from the program is routed into 5 different traffic lights:
Vehicular – Green, Yellow, Red
Pedestrian – Green, Red
The time variable circuit and the input receptive circuit are split individually into Part 1 and Part
2. Part 1 relies on the standard Simulink blocks for the software, while Part 2 makes use of
Simulink Stateflow. For hardware implementation, additional blocks from the Simulink Support
Package for Arduino Hardware are employed within both software programs.
States indicate the activation status of the lights, whether or not the lamp is turned on or not.
Both parts rely on the same set of states. However, the activation condition for the states varies
between the two parts.

Table 1 displays the activation and deactivation conditions for each state, where only the ‘ON’
lamps are listed.

Table 1:

Part 1 Part 2
Name State ‘ON’
Activation Exit Activation Exit
Green
Enter from After
Traffic After 7 Enter from
G cycle button
Red seconds state G
restart press
Pedestrian
Yellow
Traffic Enter from After 3 Enter from After 3
Y
Red state 1 seconds state Y seconds
Pedestrian
Red Traffic After 6
Enter from seconds Enter from After 6
R Green state 2 (cycle state R seconds
Pedestrian restart)

Page 6 of 23
 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

In Part 1, the program runs 16 seconds in a single cycle in total. The durations for each state are
decided on the basis of general traffic regulation for a road with a pedestrian crossing. 10 seconds
of traffic passing is given, where the last 3 seconds indicate vehicles that the light is about to
switch, and to slow down as such. The remaining 6 seconds permit pedestrians to pass, after
which the cycle repeats.

Figure 1: Part 1 Flowchart

Page 7 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Part 2 does not operate on a timer cycle; instead, it relies on the fulfillment of a certain set of
conditions. The 1st state’s deactivation depends on the input taken from the button connected in
the circuit. The second state and third state deactivate after certain lengths of time, similar to Part
1. Fig. 2 depicts the flow of the process:

Page 8 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Counter

The timing functionality in the initial stage of the system is implemented using a synchronous
binary counter. This approach is well-suited for microcontroller platforms such as the Arduino Uno,
which operate under limited power constraints, as binary counters offer high efficiency, low power
consumption, and robust performance. Compared to software-based integer counters, hardware-
implemented binary counters provide superior timing precision and faster response characteristics.
A free-running counter configuration is employed to function as a continuous time base. This
mode ensures uninterrupted counting without reliance on external control signals, which aligns with
the design requirement for time tracking rather than event-driven operations. The counter is
configured with a maximum value of 15, enabling a 4-bit range from 0 to 15, thus completing a full
16-step timing cycle. The Count output mode is selected, which generates an output at each
increment of the counter, as opposed to the Hit mode that only produces output upon reaching the
terminal count.

The counter output is defined with a double data type to ensure compatibility with subsequent
processing blocks. This numerical output is routed through an Integer to Bit Converter block,
which converts the scalar integer value into a 4-element binary vector. To isolate individual bit-level
signals, the binary vector is passed through a Demultiplexer (Demux) block, which outputs four
discrete logical channels corresponding to each bit. These are arranged in descending order from
Most Significant Bit (MSB) to Least Significant Bit (LSB) to preserve bit significance in
downstream logic operations.

No explicit reset signal is connected to the counter. Instead, the 'Reset input' parameter is
enabled within the counter configuration, allowing for automatic reset upon reaching the predefined
maximum value. This ensures seamless wraparound behavior and continuous operation of the
timing mechanism.

Boolean Logic Designation

Truth Table:

Given that Part 1 of the system is driven by a 4-bit binary counter, it is imperative to synthesize
combinational logic that accurately decodes each binary count into its corresponding finite state, in
accordance with the specified temporal allocation for each operational phase. The 4-bit counter
spans values from 0 to 15, and the state transitions are delineated as follows: counter values 0000
to 0110 (0–6) are mapped to State G, values 0111 to 1001 (7–9) correspond to State Y, and
values 1010 to 1111 (10–15) define State R. These temporal segments are derived based on the
desired duration of each state and are enumerated in Table 1, which outlines the functional and
timing characteristics of the states.

The counter output, a 4-bit parallel signal, is denoted with bit identifiers A through D, where A
represents the Most Significant Bit (MSB) and D represents the Least Significant Bit (LSB).
This binary vector forms the input to the state decoding logic, which utilizes combinational
expressions to determine the active state at any given time. The complete state decoding scheme
is captured in Table 2, which presents the truth table associating each binary count with its
corresponding system state. This logic serves as the foundation for the state machine
implementation in the traffic control subsystem.

Page 9 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Table 2: Truth Table

A B C D Count State
0 0 0 0 0 G
0 0 0 1 1 G
0 0 1 0 2 G
0 0 1 1 3 G
0 1 0 0 4 G
0 1 0 1 5 G
0 1 1 0 6 G
0 1 1 1 7 Y
1 0 0 0 8 Y
1 0 0 1 9 Y
1 0 1 0 10 R
1 0 1 1 11 R
1 1 0 0 12 R
1 1 0 1 13 R
1 1 1 0 14 R
1 1 1 1 15 R

Karnaugh Maps (K-Maps)

To derive optimized combinational logic expressions that map the binary counter output to
corresponding system states, Karnaugh Maps (K-maps) are utilized. K-maps provide a
systematic method for minimizing Boolean functions by visually grouping adjacent terms,
thereby reducing the complexity of digital logic circuits and minimizing hardware resource
utilization.

In this application, the 4-bit counter output is logically partitioned into two 2-bit segments:
AB (most significant bits) and CD (least significant bits). A 4×4 K-map is constructed by
assigning the possible combinations of AB to the column headers and CD to the row
headers. This configuration allows for the efficient organization and analysis of the truth
table entries corresponding to each system state.

For instance, the K-map for State G—which spans counter values 0000 to 0110 (decimal 0
to 6)—is presented in Table 3:

Table 3: Karnaugh Map for State G

Page 10 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Each entry in the K-map is populated with a logic '1' if the corresponding counter value is
associated with State G, as defined in the system’s truth table (refer to Table 2). All other
entries are assigned a logic '0'. For example, at count 4 (binary 0100), the bit groups are
AB = 01 and CD = 00, yielding a ‘1’ in the cell at column 01, row 00.

Using the completed K-map, adjacent cells containing 1's are grouped according to
standard K-map minimization rules to identify prime implicants. This facilitates the
derivation of simplified Boolean expressions that can be implemented using basic logic
gates. The resulting logic expressions provide an efficient means to detect when the
system is operating within the bounds of State G.

The K-maps for States Y and R follow the same methodology and are detailed in the
subsequent sections, serving as the basis for generating their respective logic
implementations.

Boolean Expressions

Boolean expressions are derived from Karnaugh maps (K-maps) by identifying and grouping
adjacent cells containing 1s. Each variable represents a true condition (logic 1), while its
complement (denoted by a prime symbol, e.g., A') represents a false condition (logic 0). Grouping
is based on shared conditions among the 1s to simplify the expression. Overlapping groups are
permitted if they contribute to minimizing the logic. As an example, consider the derivation for State
G:

Page 11 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

The second column of the K-map forms the green group, where both variables A and B are 0,
represented by the term A’B’. Similarly, the yellow group is formed where A and C are 0 (A’C’),
and the red group corresponds to A and D being 0 (A’D’). Each of these groupings corresponds to
cells containing 1s on the K-map, indicating that any one of these conditions will yield a logic high
(1) output. In Boolean logic, multiplication denotes an AND operation, addition represents an OR
operation, and complemented variables (e.g., A’) signify a NOT operation, which inverts the signal.
Thus, the Boolean expression formed from these groupings produces a logic high output when the
system is in State G (covering counts from 0 to 6). This logic output can be used to control a lamp,
turning it on for the 7-second duration associated with this state.

Following the same procedure, the groupings and corresponding Boolean expressions for States Y
and R are derived as follows:

An additional XOR gate is added between the output of State G and State Y. It correlates to the
red pedestrian light signal, which is common between the states. The XOR gate ensures that more
than one (one for each state) red pedestrian light is not required, as it will output 1 if either State G
or State Y is on but will return 0 if both states are inactive or active. The states should return to
inactivity once State R is ongoing, but in case of a malfunction where States G and Y are both on,
it will return 0, preventing further errors.

Page 12 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Software Solution
Once we have understood the Boolean Logic and created the K-Maps, we can work towards
developing our Simulink models.

PART 1

The above Simulink model illustrates the logic circuit that processes output signals from the
Stateflow controller to manage a traffic light system with pedestrian input. Digital signals
representing the traffic light states (green, yellow, red) and pedestrian lights are routed through a
series of logic gates (AND, OR, NOT) to ensure safe and coordinated behavior between vehicle
and pedestrian traffic. These processed signals are then sent to the Arduino Uno’s digital output
pins, which control external LEDs connected via a breadboard.

Page 13 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

PART 2

In this Stateflow-based traffic light controller, the transition from vehicular traffic flow to pedestrian
crossing is initiated through a pedestrian push button. The system begins in the _T_Green state,
where the traffic green light is ON and the pedestrian red light is active.

A transition to the _T_Red state occurs only when the pedestrian button is pressed, i.e., when the
input signal PedButton equals 1. This models real-world behavior, where pedestrian crossing is
allowed only upon explicit request. The button press acts as a conditional trigger for the state
machine, prompting the system to:

 Briefly activate the yellow light to warn vehicles,

 Then transition to the red light for vehicles and green for pedestrians.

After a fixed time interval in the _T_Red state (e.g., 5 seconds), the system automatically reverts to
_T_Green, resuming normal traffic flow. This event-driven transition ensures that pedestrian
access is safely managed without interrupting traffic unnecessarily.

Page 14 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Lamps
The outputs from each state are connected to Dashboard Lamp elements, which visually
represent the system status. Each lamp is configurable to change color based on the received
input. By default, a lamp displays grey when the input is 0, indicating the off state.

The connections are established using the ‘Connect’ feature in the simulation environment.
The green traffic lamp is linked to the output of State G, the yellow traffic lamp is connected to
State Y, and the red traffic lamp is connected to State R. The red pedestrian lamp is driven by
the output of an XOR gate, while the green pedestrian lamp shares the same input as the red
traffic light.

Figure showing the conditions of the lamps in state 1 – when

traffic light is green and pedestrian light is red

Figure showing the conditions of the lamps in state 2 – when

traffic light is yellow and pedestrian light is red

Figure showing the conditions of the lamps in state 3 – when

traffic light is red and pedestrian light is green

Page 15 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

This setup completes the software implementation for Part 1 of the project. In Part 2, a similar
approach is used; however, the system directly connects four outputs from the Stateflow chart to
the respective lamps, eliminating the need for the XOR logic.

Stateflow Chart – Part 2 Implementation

The Stateflow Chart forms the core of the control logic for Part 2 of the project. The system
operates based on three defined states, represented within the chart as State G (Green), State Y
(Yellow), and State R (Red). The chart is initialized in State G, which serves as the default starting
point.

State Variables

Traffic and pedestrian light statuses are represented using dedicated output variables:
 green: Green traffic light
 yellow: Yellow traffic light
 red: Red traffic light
 ped_right: Red pedestrian light

The green pedestrian light does not have an independent variable, as it mirrors the behavior of
the red traffic light. Therefore, it is connected externally in the circuit using the same logic signal as
ped_red.

In each state, the appropriate output variables are specified within the ‘entry’ action, as there are
no internal events that alter output during a state’s duration.

Page 16 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Transition Conditions

The transition from State G to State Y is triggered by an external user input. A Dashboard Button
is added to the model, returning a value of 1 when pressed and 0 otherwise. This input is
connected to the chart and assigned to the variable buttonState.

The transition condition is defined as:

[buttonState == 1]

Square brackets indicate that this is a conditional expression.

Further transitions use timing functions:

 From State Y to State R, the system uses the built-in after() function:

[after(3, sec)]

This maintains the yellow state for 3 seconds.

 The transition from State R back to State G uses a similar function with a longer duration:

[after(6, sec)]

This provides sufficient time for pedestrian crossing.

Outputs and Simulation

As with Part 1, lamp elements are used to visually represent outputs. However, in Part 2, the four
outputs from the State flow Chart are connected directly to the corresponding dashboard lamps.
No additional logic gates (e.g., XOR) are used in this configuration.

To simulate real-time behaviour, the simulation pacing is set to 1 second, allowing the system to
operate at human-perceivable timing during execution.

Page 17 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

3. Hardware Solution and testing

In order to demonstrate the working of the hardware for Part 1 and Part 2 we have attached 2
OneDrive Links that redirect to 2 videos we have filmed that capture the working of the model.

For Part 1, the system is automated, meaning no button is required to facilitate a change in state.

Part 1
Table: Hardware Tes ng for Part 1

States State G State Y State R

We expect the green We expect the yellow
We expect the red traffic
Desired traffic light, red traffic light, red pedestrian
light, green pedestrian light
Output pedestrian light to light to turn on for 3
to turn on for 6 seconds.
turn on for 7 seconds. seconds.

Results

Part 1 Automated No Button.mp4

Part 2
Table: Hardware Tes ng for Part 2

States State G State Y State R

After the button is Next the red traffic
Here the green traffic pressed the button light and green
light and red state changes to 1, pedestrian light will
Desired Output pedestrian light will now the yellow traffic be on for 6 seconds,
be on initially and the light and red after this the system
button state will be 0. pedestrian light will will come to its initial
be on for 3 seconds. position.

Result

Part 2 Button Adjustment.mp4

Page 18 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

Circuit Implementation

The Arduino Uno board must be configured correctly to support the software programs. All
connections are made using standard Arduino jumper wires. For both parts of the project, the
Uno’s GND pin is linked to the breadboard’s negative rail, and the 5V pin is connected to the
positive rail on the same side.

The next phase involves setting up the LEDs. To protect the LEDs from excess current, 220 Ω
resistors are added in series to limit current flow. Higher-value resistors are avoided to maintain
sufficient brightness for visibility. Each LED is powered by connecting a jumper wire from a
designated Arduino digital pin to the anode (long leg) of the LED. After passing through the LED
and resistor, the current is directed to ground, completing the circuit. The traffic light LEDs are
only activated when the corresponding software pin outputs a HIGH signal (1).

The green pedestrian LED shares the same state as the red traffic light. To replicate this
behavior, a jumper wire from the source pin is extended to the green pedestrian LED’s anode on
the breadboard.

Since Part 1 of the project involves only LED outputs, the entire hardware configuration is
managed through this setup. The push button is wired across four separate terminal strips. Power
and input jumper wires are connected on opposite strips so that when the button is pressed,
current flows from the voltage rail to the Arduino input pin, sending a HIGH signal (1) to the
software. A pull-down resistor is included to ensure the signal reads LOW (0) when the button is
not pressed.

To run the program on the Arduino Uno, the board is reset using the ‘Reset’ button to clear any
previous code. A USB 2.0 Type A/B cable connects the Uno to a laptop for uploading the software.
A sample validation sketch is used to verify the connection. Code deployment is completed by
selecting ‘Run on Board’ and then choosing ‘Build, Deploy & Start’. Once uploaded, the Uno
runs the program in a continuous loop. This process applies to both parts of the project.
In Part 2, the circuit remains largely unchanged, except for minor modifications in pin assignments
for the traffic lights. Additionally, the push button input is now routed to pin 6.

Page 19 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

3.1. Simulations and Desired Output

Table: So ware Tes ng for Part 1 and Part 2

Part 1 Part 2
State Desired Desired
Time Result Input Result
Output Output
We expect the The green
green traffic Initially traffic light
From 0
light, red the and red
G to 6
pedestrian light button pedestrian
seconds
to turn on for 7 state is 0. light will be
seconds. on.
When the
We expect the button is The yellow
yellow traffic pressed traffic light
From 7
light, red the and red
Y to 10
pedestrian light button pedestrian
seconds
to turn on for 3 state light will be on
seconds changes for 3 seconds.
to 1.
The red traffic
light and
We expect the green
red traffic light, pedestrian
From 11 State
green light will be on
R to 16 change
pedestrian light for 6 seconds,
seconds occurs
to turn on for 6 after this the
seconds system will
come to its
initial position.

Page 20 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

4. Conclusion
The results of the Simulink program for the traffic lighting system are summarized by the
observations and implications of the simulation. Briefly restating the purpose of the simulation, the
aim is to improve traffic flow and reduce congestion by testing different control algorithms. The
system serves all the intended simulation conditions stated in the problem statement. Part 1 of the
project condenses a binary counter input by utilizing K-maps and Boolean expressions to generate
an orderly program that runs green, yellow, and red traffic states for certain intervals. Part 2 makes
use of Stateflow charts to create a Finite State Machine that returns an initial state until a
pedestrian button is pressed, after which a series of states run and return to the initial state.
Results collected for the Simulink model includes data on traffic lights, pedestrian lights, wait times
and other relevant metrics. The simplicity of the Part 2 Stateflow chart indicates that expansion
with the given variables is viable for more complex networks as well.

To evaluate the effectiveness of the traffic lighting system in meeting identified objectives, ssome
of the strengths and weaknesses found during the simulation have been discussed below:

Strengths:

1. Modularity: The use of Simulink logic blocks and dashboard components allows for a modular
and visually intuitive design of a traffic light system. Each piece is easily understood and adjusted
independently.
2. Modification: A binary counter can be used to time the traffic light sequence precisely.
Parameters such as the duration of each phase can be changed easily by the counter settings.

3. Efficiency: The traffic lighting system logic can be optimized for efficiency and simplified by using
truth-table K-maps to derive Boolean expressions for each light. This can result in faster simulation
time and easier debugging.

4. Visual Interpretation: FSM logic implemented in part 2 Simulink using a Stateflow Chart Block
provides a visual representation of states, variables, and system actions. This visual model
enhances understanding and facilitates communication among team members.

Weaknesses:

1. Complexity: While the use of Simulink logic blocks and dashboard components offers flexibility,
it can also introduce complexity, especially for users who are not familiar with Simulink or Boolean
logic. This design may require a steep learning curve for some users.

2. Verification and Validation: Ensuring the correctness and reliability of the Simulink model may
require thorough verification and validation procedures. Mistakes in the design or implementation
of the traffic light logic could lead to incorrect behavior during simulation.

3. Maintenance: As the Simulink model grows in complexity or evolves over time, maintaining and
updating the model may become challenging. Changes to the traffic light sequence or system
requirements may necessitate modifications to multiple components of the model, increasing the
risk of errors.

4. Limited scalability: In Part 1 while the modular design allows for flexibility, the binary logic-based
approach may have limitations in scaling up to handle larger or more complex traffic management
systems. New conditions or additional features may have complicated design and increase the risk
of error.

Page 21 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

In order to address some of the weaknesses of the system, adjustments to schedules, revisions to
control algorithms, or implementation of new measures may be made. By adding a priority input
receptor, traffic can be conditioned to clear the way for emergency vehicles. Adding sensors will
convert it to an ITS, intelligent traffic system. Feasible sensor systems include pressure plates may
be added to detect pedestrians who want to cross the road, and infrared sensors to detect empty
lanes. And with the use of a few Indicating lights vehicles will be directed towards them. This will
clear traffic. The system will be optimized to remove delays. It can be integrated with Online Maps
to give real time traffic signal outputs which would make road travel well-ordered.
Ultimately, the project is able to present how Simulink and Arduino Uno may be utilized in
conjunction as tools in the development of traffic systems and transport technology as a whole.

5. References
[1] TRL Software, "MOVA - Microprocessor Optimised Vehicle Actuation," TRL Software. [Online].
Available: https://trlsoftware.com/products/traffic-
control/mova/#:~:text=MOVA%20is%20a%20traffic%20signal,uses%20detectors%20and%20signa
l%20controllers.

[2] Arduino, "Button," Arduino Documentation. [Online]. Available: https://docs.arduino.cc/built-in-

examples/digital/Button/.

[3] iStock, "Straight road from above Illustrations," iStock. [Online]. Available:
https://www.istockphoto.com/illustrations/straight-road-from-above.

[4] MathWorks, "Simulink Support Package for Arduino Hardware," MATLAB Central File
Exchange. [Online]. Available: https://in.mathworks.com/matlabcentral/fileexchange/40312-
simulink-support-package-for-arduino-hardware.

[5] Tinkercad, "Tinkercad Circuits," Tinkercad. [Online]. Available:

https://www.tinkercad.com/dashboard/designs/circuits.

[6] Electronics Tutorials, "Boolean Algebra Simplification," Electronics Tutorials. [Online]. Available:
https://www.electronics-tutorials.ws/boolean/boolean-algebra-simplification.html.

[7] Thimble, "How to Use a Breadboard: An In-Depth Guide," Thimble. [Online]. Available:
https://thimble.io/how-to-use-a-breadboard-an-in-depth-
guide/#:~:text=A%20breadboard%20is%20a%20plastic,components%20to%20a%20power%20so
urce.

Page 22 of 23

CRICOS provider number: 00122A | RTO Code: 3046

 Yuva, Akshat, Naman
OENG1278 Digital Fundamentals

6. Appendix
1) In order to document the working of the models, especially hardware models, we have compiled
a OneDrive storing all the Videos, Photos and Excel Sheets we used during the entire duration of
the project.

ANY RMIT Project

Page 23 of 23

CRICOS provider number: 00122A | RTO Code: 3046