MAS115: SEMESTER 2 GROUP PROJECT
The task
Your task for this project is to investigate strategies for the switching of
traffic lights at a road junction and the effect on the movement of traffic
through the junction by modelling the situation in R.
You will present your investigation as a group in a 9 minute talk to other
students, using Beamer slides created in LATEX. After each talk, 3
minutes will be allocated for questions.
Please note that although we would like you to investigate the efficiency of
different traffic light strategies we do not expect you to find the absolutely
optimal strategy. This is a really hard theoretical problem and we gen-
uinely don’t know the answer ourselves. We look forward to hearing your
suggestions.
A roundabout junction
with n joining roads
(similar to the uni-
versity roundabout)
A Y-style junction
(similar to that outside
the Hallamshire Hospital)
A standard junction
Figure 1. Some possible junction styles that you might choose.
Submission
You will upload your presentation as a ZIP file (containing the Beamer
presentation itself, along with any R code you wrote) via the upload system
on the course webpage. The deadline for uploading the project is
midnight at the end of Monday 2nd May 2022. More details will
follow.
1
You will receive a mark out of 20 for the project, which will contribute
to your final grade. In all but exceptional circumstances, all members of
the group will receive the same mark. We are aware that contributions are
likely to be unequal, but as a group you will take joint responsibility for
your output. There will be an opportunity to comment on exceptional cases
at the end of the project. You will find suggestions on what to investigate.
You are free to investigate things that have not been suggested, and you do
not need to cover all of the things that have been. Everyone in your group
must take turns in speaking during your presentation so you will want to
think about how you can split up your talk amongst you.
Your presentation show include some motivation to the problem and could
involve some background material to the area, but you must ensure this isn’t
plagiarised from other sources and is genuinely your own work. Any material
that relies on other sources must be properly referenced and credited to
them. It will be assumed that you attended the Week 11 presentation lecture
in Semester 1 where plagiarism was covered.
You should aim to create a self-contained presentation of the subject that
your peers who aren’t taking MAS115 would be interested in watching.
Submission
The submission of the project comes in two parts:
(1) a 9 minute presentation written in Beamer (see the lab from Week
6 in Semester 1 Beamer help) along with the R code used;
(2) a personal reflection, submitted as a PDF written in RMarkdown or
LaTeX.
Both of these submissions will be uploaded via the upload system on the
course webpage.
Late work. It is important to submit your work on time. Any work sub-
mitted after the deadline may be subject to a penalty and could be given
a mark of zero. Anybody with circumstances affecting their ability to hand
in the work must email Bryony Moody well in advance of the hand-in date.
Plagiarism. The project must be your own group’s work. You should col-
laborate with your other group members to identify the work to be done and
solve problems. You should not share material with other groups except via
the discussion board (see below). Please also ensure you have un-
derstood the material on plagiarism from the Week 11 lecture from Semester
1. Where we judge that work has been plagiarised from another source, there
is a possibility of a mark of zero being awarded for those projects. Please
bear this in mind!
Group submission. The ZIP file containing your slides for your presenta-
tion and the R code will need to be submitted to the online uploads system,
in advance of the talks themselves, by midnight at the end of Monday 2nd
May 2022. More details of the timing of the talks will follow, but they will
be Tuesday to Thursday in Week 10.
Personal reflection. The deadline for uploading your reflection is mid-
night at the end of Tuesday 10th May 2022. This will not be marked, but
failure to complete it at all, or to a reasonable standard, will result in a
penalty being applied to that individual’s overall mark. The reflection here
is just for you to think about the process of working in a group, how you
(and your colleagues) contributed, how the group operated, what you think
went well or badly, etc.
As for previous projects, University regulations on non-invigilated examina-
tions apply.
Final comments
Here are some final thoughts to help you with the project.
• Use other internet resources (e.g. Wikipedia), but don’t plagiarise.
Do link to interesting pages you have found if appropriate.
• Make use of the discussion board when you’re stuck as a
group. Sharing large chunks of material is not allowed, but help-
ing people who are stuck is a good thing. We may post up useful
things that we’ve discovered there from time to time. Questions
such as ‘How can I get my code to display properly?’ are entirely
appropriate.
• You must participate satisfactorily in all group projects in order to
pass the module.
• In your presentation, being able to show plots of your results is likely
to be very useful in explaining them. Think about what would be
good plots to show to illustrate the queue and the effects of changing
the strategy on your measure of efficiency.
• The suggestions in this document are by no means an exhaustive
list of what you might want to look at, or indeed what is required of
you. Please feel free to modify the problem if you think that other
aspects are more interesting or if there are things that we have not
considered which you feel to be important. Also please do feel free
to make your choices based upon real-life road junctions and queues.
Revision computer labs
There is a revision session on Tuesday 26th April 2022 from 11am to 12pm
in G25. Please attend if there are any concepts you feel you to need revise
to complete the project.
April 2022
Investigating queuing and a traffic light strategy
We can mathematically model any road junction as a process whereby cars
arrive at random times from each direction and have to queue at the junction
until their traffic light turns green. Once this happens, those cars can begin
to progress through the junction; at the same time traffic will start to build
up in other directions waiting for their light to turn.
As a junction designer there are lots of options for how to design the traffic
light system, and when the lights should change colour to let traffic progress
in the most efficient way. In order to find a good strategy, we can simulate
possible arrivals and the development of the queue. This way, within our
computer model, we can try out different strategies and see which work well
before implementing them in a real road junction.
Creating a model. Formally we should model this traffic system in con-
tinuous time (a car can arrive at any time) but this makes the coding quite
a bit more difficult. Instead, we can discretize the problem into small time
steps of seconds. We can then model the evolution of the junction from one
second to the next. In such a way we consider the state of the system at a
series of times t = 0, . . . , n, where in each second a new car may arrive from
any direction, a traffic light may switch colour, a car may move through the
junction and so on.
It is up to you as a group to decide what it is that you want to investigate.
We do not expect you to look at every possible scenario and would rather
see a group investigate a few interesting ideas fully as opposed to many on
a very basic level. It would be great if you actually modelled your junction
on a real life road that you know and chose parameters accordingly.
Junction types. Figure 1 shows examples of junctions that came to mind
on our walks into work. These are by no means the only junctions that you
might wish to consider. Bear in mind that just because a junction looks
non-standard it does not mean that the coding will be more complicated, so
we’d encourage you to be adventurous in your choice of junction. Remember
you are going to be giving your talks to each other, so some variation will
keep things interesting!
Arrival of traffic. We assume that at each second a car may arrive at any
road entering the junction. Specifically, we would consider the probability
of a car arriving from direction j as αj . You will need to decide upon a
suitable value of each αj based upon your experience. If you are modelling
a real life junction you might even want to go and look at the junction to
determine a realistic value based on the arrivals of real cars.
It is unlikely that any realistic junction will have equally busy roads leading
into it, so will probably want to choose different arrival rates for the different
directions.
Traffic light strategies and efficiency measures. You need to decide
upon a strategy as to when to change the colour of the traffic lights. For
example, your lights might be
• dependent solely upon time, with the lights spending a certain amount
of time allowing traffic to pass in one direction before automatically
switching to another;
• dependent upon queue length in any direction (for example, they
may change if the queue length in one direction exceeds a certain
level).
You will also need to determine how to measure efficiency for a traffic light
strategy. Some options could be the average waiting time of a car to pass
the junction or the average queue lengths at the junction, but you may think
of others.
Other considerations. In reality, changing traffic lights is not an instan-
taneous process, as lights cannot flip suddenly from red to green and vice-
versa. Whenever you change the lights there might be some dead time when
no traffic can progress in either direction. You may want to incorporate this
into your model.
Also, it is not the case that as soon as a light turns green all the traffic
queued in that direction can instantaneously pass. It will take some time
for each car to get through the junction. You may want to consider a model
whereby when the light is green it still takes 60/β seconds for each car to
pass (i.e. only β cars may get through within a minute).
Making sure queues don’t just build up. You don’t want to have
queues that build up indefinitely. Whether this will happen will depend
upon the parameters you select (and a sensible traffic light switching strat-
egy). Intuitively, you want to make sure that at every side of the junction,
the number of arrivals is less than the number of cars which can pass through
from that direction. This means that βpj > 60αj where pj is the proportion
of time that direction j has its traffic light on green. If you have created a
scenario where the traffic does build up indefinitely then you need to think
about whether that is the switching strategy or if you have just chosen an
αj that is too large or a β which is too small. If it’s the latter then you
should probably choose some more realistic values.
Coding Ideas
Setting up variables. By modelling the evolution of the junction from
one second to the next, you can update the state of the system after every
second passes, considering whether there are new arrivals, what the traffic
lights are currently doing, if a car can get through the junction and so on.
You will need to create suitable variables which contain all the information
contained in the system and also store your measure of efficiency.
How long to run the code for. You have two options as to how long
you want to run the simulation for, i.e. for how many seconds N you want
to model the junction. The first option is to choose N to be large so that
the queue reaches a steady state and the efficiency measure is stable. If
you choose this option, then you need to be aware that dependent upon the
parameters you choose, the queues could become infinitely large and never
reach their steady state.
An alternative option is to model the queue for a shorter period of time (say
perhaps an hour, i.e. N = 3600) but do so multiple times. Each individual
simulation will give you a different value for your efficiency measure, as it
will be random, but you can average them together (and perhaps include
confidence intervals). We recommend that you take this approach.