3. Project Requirements Specification

Contents
3. Project Requirements Specification
  3.1) Road Network Designer
  3.2) Traffic Modelling Tool
  3.3) Visual Simulation
  3.4) Application Results
  3.5) Documentation
  3.6) Further Project Modules
  3.7) Estimated Project Problems
  3.8) Project Limits

The focus of the project is the graphical animation of traffic simulation results. The projects complexity should be kept as low as possible by choosing to implement the simplest traffic model or programming technique wherever there is a choice. The project will therefore not involve the kind of realism that existing commercial simulations implement but will allow easy interpretation of results to untrained observers.

• Four application components
  • Road Network Designer
  • Traffic Modelling Designer
  • Visual Simulation
  • Application Results
• A documentation component
• And further project modules.

3.1. Road Network Designer

• The application should be to-scale (e.g. x screen pixels per metre).
• The application should start by showing a drawing panel as a blank designing area (representing a x*x m square area).
• Assume terrain is always flat (a simplification).
• Start by simulating only one type of vehicle (Use Ford escort dimensions approx. 4.3*1.6m). More vehicle types could be added later.
• Road lanes are simplified to a constant width (e.g. 2.5m).

• Lanes are drawn on the panel in straight-line sections. Each new section of the lane follows on from the previous section.
• The panel has an invisible grid that both ends of a lane-section snap to.
• A lane section is only valid if it starts and ends at either a junction or the edge of the panel.
• Lanes are the building blocks of all roads. For example a two-way traffic road is made from lanes of opposite direction side-by-side.
• Any existing lane should be able to be extended with another identical lane next to it (space permitting).
• The maximum number of lanes in any direction is four (a simplification).
• Existing lanes should be able to be deleted.

• When the ends of three or more lane-sections overlap a junction should form.
• The default junction should be a give-way model.
• The two possible junction types are give-way and signalled junctions (traffic-lights). Roundabouts will not be in the scope of the project.
• Lanes should also be able to pass over or under other lanes. Therefore there are 4 options at any point where lanes cross other lanes.
• A junction should be able to be toggled to any of the 3 other options available (if suitable).
• A give-way junction is composed of a main route and either one incoming or one outgoing slip road (or both i.e. a crossroads) (i.e. give-way junctions involve a maximum of 4 roads). The main route always has a greater or equal number of lanes to a slip road. The main route will follow a roughly straight line through the junction whereas the slip road will come at an angle to the main road. A general rule which may not fit every case is: If the slip road is joining the main road the angle will be 90? or larger and if the slip road is bleeding off the main road the angle will be 90? or smaller. Slip-roads have a maximum of 2 lanes. This description is sufficient to cover double lane roads changing to one lane.
• At a give-way junction the default mode will restrict slip-road traffic to enter or leave only the inner lane of a main road. If other behaviour is required (e.g. in the case of a crossroads) the user is required to draw a directed arrow from every junction input lane to any other junction output lane that is a option for the traffic to take.
• At a traffic light junction the user must specify legal turning options for traffic to take. The user must draw a directed arrow from every junction input lane to at least one junction output lane. The system will determine sets of traffic-lights and signal timing intervals automatically.
• Two lanes can never touch without resulting in one of the four road options (over-pass, under-pass, signalled junction, give-way junction).
• For simplicity, at any point on the map only one junction can occur. (e.g. you can't have a over-pass going over a signalled junction).

• There should be buttons for: create Lane, create Road, Add Lane, Delete Lane.
• There should be an Undo and a Redo Button.
• Road designs should be able to be saved and loaded.

• Obeys all the rules stated above.
• All junctions fully specified.

3.2. Traffic-Modelling Tool (Pre-condition: a valid road network.)

• A junction has inputs and outputs.
• Each junction has unique input and output traffic-flow intensities.
• The input traffic-intensity of one junction will be a function of the output traffic-intensities of other junctions.
• A road network is a composition of junctions with connecting roads linking junction with junction.
• A certain amount of cars will enter the system according to some kind of control element.
• A car can start at any input into the system and go to any output.
• All cars should eventually exit the system (No infinite loops).

• For each input to the system users should be able to specify the average or exact number of cars per minute that will enter. This will require labelling of the roads in the designed road network.
• There should be an option to randomise the car input data each time the simulation is run, or otherwise the simulation will run with precisely the same data (the same number of cars enter at the same time).
• For each junction of the road-network users should be able to specify a relationship between the individual inputs and the individual outputs (i.e. for each input to a junction the user must specify the percentage of cars that will go to each output). An Example: At junction J, cars entering at lane L have the possibility of going straight on to exit E1 or can turn left to exit E2. If it is not the case that 50% go left and 50% go straight on then the user must adjust the settings. These settings are an important tool for the user but may introduce unexpected behaviour. One example of this is for slip roads onto main routes, unrealistic congestion may occur in the outer-lanes of the main route if the junction is not properly specified. Another example is that a user may specify that a lane is never reachable.

• Traffic-flow models should be able to be saved and loaded.
• Saving a traffic-flow model should mean that the model can be applied to any road network with the same labelled inputs. Any road-network that uses a loaded traffic-flow model should be able to run with precisely the same data (the same number of cars enter at the same time).

3.3. Visual Simulation (Pre-condition: A valid road network.)

• Cars obey a speed limit. This is their "top speed". An example maybe between 50 and 60 kilometres/hour (31-37mph).
• Cars enter the system at top speed at positions and times according to a set traffic-model specified by the "traffic-modelling tool".
• Cars do not collide.
• Cars can only enter the system if they are in a valid position. (Not a collision).
• Cars can only change lanes at junctions. (No U-turns).
• Cars will always try to go at their top speed when possible but their speed is governed by the "car-following model" described below.
• Cars can only change speed by accelerating or decelerating. Acceleration will be a constant value (for example 5m/s2). De-acceleration measures should be sensible (i.e a car should not be able to stop in no time).
• Cars do not take independent decisions. A car travel route and the lane it is in depends entirely on its starting position and the statistical decisions of the junctions it passes through.

• A Car will travel at its top speed limit unless it is within 10m of another car.
• It must de-accelerate to match the other cars speed by the time there is a 3m distance.
• It must never go within 1m of another car on the same lane.

• Cars follow this model when pulling up to red lights, give-way signs or if there is stopped traffic ahead.
• At a suitable distance before the obstruction the car will de-accelerate with a constant value to stop in time.

• The project is simplified to not include overtaking.
• A car will only change lane at junctions according to the junction traffic-model statistics.

• Cars on the main route are unaffected and travel as normal according to the car-following model.
• Cars on the slip roads "pull up" to the give-way line to check for oncoming traffic.
• Cars on the slip-road can join the main-route if they aren't going to obstruct the cars on the main-route. I.e. there must be a suitably large clear section of traffic on the main route. This is the gap-acceptance model.

• Signals are independent for each input lane.
• Cars will "pull-up" to the stop line if the signal is red.
• The signal is two-phase. Go is green, stop is red.
• On a green signal the car is specified an output lane (according to the traffic-model of the junction) and will travel to the output lane in a direct route.
• Traffic light timing intervals will be initially split fairly between different sets. Later, traffic lights can be re-programmed to be more intelligent.
• The colour of a traffic light will be conveyed on the screen by the colour of the stop line at a particular lane. In addition if the light for a lane is green there should be arrows displayed on the junction specifying where cars have the option of going.

• For each input to the system there should be a control to increase or decrease the traffic entering at that input.

3.4. Application Results

• Each input and output of the system should have a log of how many cars passed through.
• Every junction should log how many cars passed through each input and output lane.
• Each traffic-light junction should store the timing intervals of each light.
• There should be traffic flow data for the system as a whole. (Number of cars passed through per second).
• There should be a value estimating total surface area of road surface used in the current network design.

This data should be accessible at any point in the animation. When it is requested the animation should pause, the results presented and the animation should continue when specified.

3.5. Documentation

• An on-line users guide.
• An on-line tutorial and example run-through.
• A project final report, documenting all issues of the project.
• A project logbook, documenting progress and problems.

• An online design document.
• On-line JavaDocs explaining classes and methods.
• On-line viewable commented code.

3.6. Further Project Modules

• Allow the user to specify timing intervals.
• Use vehicle-actuated signals.
• Compute optimal timing intervals for single junctions.
• Implement central control of multiple junctions to try and co-ordinate the green lights for multiple junctions.

3.7. Estimated Project Problems:

• If a car is being slowed by the car in front and the lane next to it is clear of traffic and going in the same direction, then it should change to the clear lane.
• Changing lanes should only be done if it does not obstruct other traffic.

The specification says that at signalled junctions, on a green signal a car will travel to the output lane in a direct route. This may look odd or produce unrealistic results:

• The car behaviour model at junctions will have to be modified so cars follow a more complex route from their input lane to their output lane.

3.8. Project Limits

• Vehicle overtaking models.
• Vehicle collisions.
• Individual driver behaviour (e.g. differing speeds and acceleration, erratic driving, speeding, advertisement slow-downs, etc).
• User definable speed limits.
• User definable traffic-light timing intervals and positions.
• Real-time presented result data.
• Smooth corners and car turning circles.
• Extendable simulation area with zooming in and out.
• Dynamic time control.
• Roundabouts.
• Mixed Traffic vehicles (trucks, buses, bicycles, mini's etc)
• Pedestrian crossings.
• Sloping terrain and different weather conditions.
• Environmental measures of fuel consumption and emissions.
• Safety-critical data, measurements and results.