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.
