Installation Guide for MOVA

traffic systems and signing

© Crown Copyright 2005

First published 1990

Printed and published by the Highways Agency

traffic systems and signing

MCH 1542 Issue C

September 2005

Installation Guide for MOVA

MCH1542 C Installation Guide for MOVA

September 2005

(This page is intentionally left blank)


September 2005

REGISTRATION OF AMENDMENTS

Amend No

Page No

Signature & Date of Incorporation of Amendments

Amend No

Page No Signature & Date of Incorporation of Amendments


September 2005

(This page is intentionally left blank)

MCH1542 C Installation Guide for MOVA Contents

Spetember 2005

Contents Chapter Page No. 1. INTRODUCTION

1.1 General................................................................................................................. 1 1.2 Scope ................................................................................................................... 1 1.3 Application ........................................................................................................... 1 1.4 Development of MOVA......................................................................................... 2 1.5 Glossary of Terms ................................................................................................ 3

2. MOVA OPERATION 2.1 Improvements over System-D VA control ................................................................4 2.2 MOVA fundamentals .................................................................................................4 2.3 MOVA Control principles............................................................................................8 2.4 Special MOVA features for junctions with flared approaches ................................11 2.5 Cycle-time control ...................................................................................................14

2.6 Other facilities in MOVA ...........................................................................................14 2.7 High-speed sites .....................................................................................................18 2.8 Facilities for emergency and priority vehicle control ...............................................21 2.9 Other uses of Emergency and Priority Links ..........................................................23 2.10 Time-of-day features in MOVA ................................................................................24 2.11 Benefits expected from MOVA installation ..............................................................25 3. DESIGN CONSIDERATIONS 3.1 Introduction ........................................................................................................ 26

3.2 Design Process................................................................................................... 28 3.3 Site characteristics ............................................................................................. 29 3.4 Site Measurements ............................................................................................ 30 3.5 Stages and stage order ..................................................................................... 32 3.6 Link/Lane relationships ...................................................................................... 33 3.7 Pedestrian/Priority links ..................................................................................... 33 3.8 Traffic detector positions and functions ............................................................. 35 3.9 Drawing ............................................................................................................. 41 3.10 Communications ............................................................................................... 41 3.11 MOVA Design Process For Traffic Signal Junctions........................................... 42 3.12 Dataset preparation (MOVA-SETUP) ................................................................. 44 3.13 Example sites…………………………………………………………………………..50

4. IMPLEMENTATION

4.1 Loop layout and specification ............................................................................ 84 4.2 Duct work............................................................................................................ 90 4.3 Factory acceptance test...................................................................................... 90 4.4 Configuring the Controller................................................................................... 92 4.5 Supply and fitting of MOVA hardware................................................................. 94 4.6 New Sites - fall-back mode ................................................................................. 99

MCH1542 C Installation Guide for MOVA Contents

Spetember 2005

Chapter Page No. 5. COMMISSIONING 5.1 Introduction......................................................................................................... 98

5.2 Pre-commissioning ............................................................................................ 98 5.3 Switch to MOVA control ..................................................................................... 99 5.4 After commissioning ........................................................................................ 101 5.5 Post-Commissioning Validation ........................................................................ 102 5.6 Completing commissioning............................................................................... 104 5.7 Commissioning problems ................................................................................. 104 5.8 Error messages: Why and when they occur, what they mean and what to do............................. 106

6. MAINTENANCE AND FAULT FINDING

6.1 Introduction ...................................................................................................... 110 6.2 Routine attention and maintenance .................................................................. 110 6.3 Remote Access and Remote Monitoring .......................................................... 111 6.4 MOVA contacts the Instation ............................................................................ 111 6.5 Problems Achieving Remote Access ............................................................... 111 6.6 Dataset Maintenance - is any required? ........................................................... 112 6.7 Assessment Log and Assessment Periods....................................................... 112 6.8 Historical Flow Log ........................................................................................... 114 6.9 Quality Assurance............................................................................................. 114 6.10 Training............................................................................................................. 114

7. REFERENCES

7.1 General............................................................................................................ 115 7.2 Specifications and instructions ......................................................................... 115 7.3 Other publications............................................................................................. 115

8. HISTORY ...................................................................................................................... 116

MCH1542 C Installation Guide for MOVA Introduction

September 2005 1

1. INTRODUCTION 1.1 General These Guidelines supersede MCH 1542B, from the date of issue and have been up-issued to reflect the enhancements to MOVA since MCH 1542B was issued to provide users with a comprehensive and informative guide to the MOVA method, its application and use, and in the design and implementation. Although technically superseded, the information contained in MCH 1542A still remains valid for the old Ferranti add-on units still in use (believed to be up to about 50 in number at date of issue of this Guide). MOVA is being used by many Highway Authorities who have responsibility for traffic signals, and is a requirement of Technical Directive TD 35 for new signal installations and major refurbishments on all purpose trunk roads. . 1.2 Scope This document provides technical advice on the main elements of installing MOVA, including:

• junction design in terms of how MOVA will work and data requirements and detector layouts,

• creating the MOVA data from the information and measurements collected,

• validation after commissioning is complete. Important to check/modify the site data to ensure optimum results.

• on-site commissioning to help arrive at a working system on-site,

• maintenance,

• faultfinding.

1.3 Application MOVA is particularly well suited to junctions experiencing the following conditions:

• Sites with high traffic flow, particularly where these are seasonal or intermittent (for instance, motorway diversion routes and holiday routes).

• Sites experiencing capacity difficulties

under VA control with congestion on one or more approaches.

• Sites with high speed approaches

and/or red compliance problems. • Where additional capacity is required,

for instance, to enable improved pedestrian facilities without detriment to vehicular users, to allow the introduction of dedicated right-turn facilities or to increase capacity to enable development.

• Where more than one junction is

situated too close to be considered as isolated, there are ways in which two or more junctions can be linked by the use of MOVA control. Partially signalised roundabouts are a good example of a MOVA linking opportunity.

• Puffin crossings where MOVA changes

in favour of pedestrians with improved efficiency over VA is able to take account of the length of time that pedestrians have been waiting.

Note: MOVA can only be used on a single stream (but check with the signal controller supplier), although it can be used on one of the streams at a multiple-stream junction Other streams can be linked to the stream MOVA is controlling. It can also be used where more than one junction operates on a single stream. It may be possible to reduce the control to a single stream for effective MOVA control, or to link MOVA units controlling each stream individually. MOVA can be used in conjunction with any controller with conforming to Departmental Specifications TR 2210, TR 0141, or TR 2500 (with standard UTC interface) and is available in one of the following forms: • ‘Add-on’ unit that connects to the

controller via the standard UTC interface


September 2005 2

• ‘Semi integral’ where MOVA and the Controller are separate but have a dedicated communication link

‘Integral’ where the MOVA kernel software is incorporated into the Controller’s operating firmware (although MOVA still effectively remains a separate functional component). 1.4 Development of MOVA The development of MOVA is continuously active through direct funding from the the MOVA Development Group and licence revenue income from sales of the MOVA kernel software. A number of facilities that have been added since the original site trials in 1989/90. Some of the more important ones are • Bus and emergency vehicle priority

control • Control of linked, multiple and

separately controlled pedestrian crossing movements

• Automatic stage sequence selections at

junctions with separately signalled right turn movements

• Automatic ‘double green stage

sequence selection • PUFFIN-style pedestrian facilities • Linked MOVA for closely spaced

junctions (including roundabouts) • Crossings with light rail systems At the date of issue of this Guide the latest version of MOVA is M5 in which a number of new facilities have been added. The more important ones include the following: • A ‘Compact’ version of MOVA, which will

be able to accommodate urban situations where there are restrictions in siting the standard ‘IN-detectors’

• Improved data handling capability,

making it easier for engineers to use different time of day configurations in MOVA

• The ability to download site

configuration data from a remote instation to a MOVA M5 unit

• The ability to upload site configuration

data from a MOVA M5 unit either locally or remotely

• Support for datasets with up to 10

stages, 30 lanes, 60 links, 64 detectors and 31 confirm channels for stages and phases

• Enhanced error handling (especially to

trace problems in the MOVA program itself), including the ability to assign values to specific errors

• Consolidation of bug fixes and existing

experimental enhancements, for instance for Puffins, where wait-light channels and kerbside detectors can be combined more flexibly

• The MOVA Setup program is now

backwards compatible with earlier versions of MOVA and works under all recent Microsoft Windows operating systems

• The MOVA communications program

(MOVA Comm) has been completely rewritten to include a Windows user interface, improved functionality for displaying the MOVA message log, and flexible terminal settings (any COM port, speeds up to 57 600 baud, support for serial-USB adaptors)

The user is also referred to the TRL Application Guides AG 44 and AG 45 (see Chapter 7 ‘References’). TRL Application Guides AG10, AG11, AG12 have now been withdrawn. MOVA Setup, MOVA Comm and the updated Application Guides can be downloaded from the TRL software website, www.trlsoftware.co.uk. For information about MOVA updates, cost and any queries referring to the TRL.


September 2005 3

Application Guides please refer any enquiries to: Software Bureau TRL Limited Old Wokingham Road Crowthorne Berkshire RG45 6AU Tel: 01344 770758 Fax: 01344 770864

1.5 Glossary of Terms A comprehensive glossary of terms is given in Highways Agency document TA84 Code of Practice for Traffic Control and Information Systems for Public Highways. A glossary of the MOVA terms is included in TRL’s Application Guides.

Email: [email protected]

MCH1542 C Installation Guide for MOVA MOVA Operation

September 2005 4

2. MOVA OPERATION This chapter describes the key features of MOVA control, both the theoretical principles and its facilities. A fuller description is available in AG 44. 2.1 Improvements over System-D

VA control MOVA is designed to replace the standard UK isolated junction vehicle-actuated (VA) control strategy built into Controllers meeting the specification TR 2210A (Previously TR 0141C). Although VA is usually more efficient than isolated fixed-time control when correctly implemented and all the detectors are working, certain deficiencies are apparent: • VA decisions to extend or terminate a

green stage do not take account of the size of traffic queues currently receiving a red signal (a single vehicle queuing has the same effect as many vehicles). This may cause a less than optimal stage change.

• VA extensions of the green may occur

when traffic is discharging at below full saturation flow rate. This is not usually optimal at busy periods or at multistage junctions.

• It is difficult to set VA phase maximum-

green times to meet continually changing traffic conditions, yet this is necessary to retain a balance between delays on conflicting phases.

MOVA aims to overcome the above deficiencies: • MOVA takes full account of all traffic on

all approaches when making decisions. MOVA uses more accurate lane-by-lane counting detectors to estimate dynamically a) flow rates for traffic approaching green signals, and b) sizes of queues waiting at red signals.

• MOVA extend/terminate decisions are

more optimally made and maximum greens need no longer be set so

precisely. MOVA includes special control features for flared approaches.

2.2 MOVA fundamentals 2.2.1 Signal control - stages and phases MOVA signal control is based primarily upon a preset sequence of stages which in turn receive the green signal; provided that the traffic situation satisfies specified conditions, a stage will be 'demanded'. Although MOVA operates with an apparently rigid sequence of stages, the use of appropriate conditional demands allows stages to be included or omitted depending on traffic conditions at the time. This provides control that can be made to be, in effect, equivalent to phase based control. MOVA itself does not handle the timing of phase-to-phase intergreens, minimum greens etc. All this is taken care of by the Controller, even in the case where MOVA is integral. MOVA simply requests a stage-change which the controller responds to, ending current greens and starting new ones appropriately. MOVA however, does need to know about phases overlapping part or all of any interstage periods. This is taken care of by programming phase confirmations that are made available to MOVA. In certain cases (see AG 45 Section 3.7 ‘Stage and Phase Data’), confirmations can be automatically generated. 2.2.2 Lane-based traffic detection and

modelling For MOVA signal control, each approach to a junction must be clearly marked-out in one or more separate traffic lanes. The modelling of traffic behaviour and associated calculations are then carried out for each lane individually on an approach. MOVA requires vehicle detection by inductive loop (to TR 0100 specification) or equivalent detectors that provide both vehicle counts and presence information. Each traffic lane approaching the junction has one or more detectors. Actual positioning of MOVA detectors depends upon the 'cruise speed' of approaching traffic as explained in Chapter 3; locations will therefore vary from site-to-site


September 2005 5

and arm-to-arm, unlike the earlier fixed positions with VA System-D detection. Figure 2.1 shows an example, for typical urban conditions, of the siting of detectors on an approach with two full traffic lanes. Each traffic lane has its own separate detectors. The detector located at about 3.5-seconds1 cruise time (plus 5 metres) before the stopline is known as the X-detector (by analogy with the naming of the detector in the current UK System-D). The detector sited at a nominal 8-seconds cruise time before the stopline is called the IN-detector. See Figure 4.1 for a guide to expected distances.

1 At very high speed sites, the X-detectors can be quite distant from the stopline and MOVA’s variable minimum green calculation may not always be ideal. Exceptionally, it may be necessary to move the X-detector nearer to the stopline in such cases.

Figure 2.1 : Standard detector arrangement for MOVA

7 to 10s + 5m

3.5s + 5m

X-detectors IN-detectors

Detectors sited according to cruise time from stopline


September 2005 6

2.2.3 Flared approaches On some approaches to signal-controlled junctions, the carriageway may have been widened locally to provide more lanes near to the junction than there are further back. Known as flared approaches, Figure 2.2 shows an example with lane markings and detector locations. In MOVA, lanes are defined as follows: • 'long lane' - a lane with both IN and X-

detectors • 'short lane' - a lane with an X-detector but

no IN-detector If a lane on a flared approach is very short (say less than about 25m back from the stopline) it would not normally have an X-

detector (although there may be exceptions, see next paragraph). For the purposes of MOVA control it is considered not to be a lane and is described as a “bay”. Alternatively stated, a lane must have an X-detector to be treated as a 'lane' in MOVA. There may be occasions where an X-detector closer than 25m is necessary. For example, where a dedicated right-turn movement is involved and an X-detector is needed to extend the stage in the absence of any other suitable detector. However, an X-detector located at less than 25m, or even 30m before the stopline, would be much less effective at control as vehicles that close to the stopline are unlikely to stop if presented with a leaving amber anyway.

Figure 2.2 : Detector arrangement for a flared approach

X - detectorsIN - detector

Lane 2

Lane 1


September 2005 7

2.2.4 MOVA traffic links (lane groups) and phases

For MOVA it is necessary to specify data for each traffic lane on an approach. Also, data is needed for each traffic 'link' on an approach. In MOVA a traffic link consists of 1, 2, or 3 lanes that cater for the same ‘stream’2. A single controller phase may cater for a single traffic stream (link) or it may cater for 2 or more MOVA links where distinctly different queuing situations are controlled as a single phase (e.g. where two lanes on the same phase cater for different movements). A link will normally represent a single lane unless the queuing characteristics across two 2 Stream of traffic as distinct from controller stream

or three lanes are similar, in which case a single link should be used to represent two or three lanes. Queuing characteristics are considered similar if traffic (hence queues) behaves in a similar way during the same green periods. The main pre-requisite for this is that any directional-arrow lane-markings do not discourage the traffic in these lanes from forming roughly equal length queues. Normally this at least requires that adjacent lanes share a common movement. A multi-lane link should, therefore, be specified where the majority of the drivers are not restricted from joining whichever lane has the shortest queue. Figure 2.3 shows the link/lane structure for an example site.

Link Movements on link

1 2 3 4 5

Lane 1 ahead only Lane 2 R.T. only Lanes 3 & 4 ahead L.T. All pedestrian crossings Lane 5 L.T. & R.T.

Figure 2.3 : Example traffic and pedestrian links in MOVA

6m

Lane 3

Ped. Detector No 7 43m 93m

Lane 4

Lane 5

Lane 2

Lane 1

44m 95m

35m

70m

1 3 2

Ped.

4


September 2005 8

2.2.5 Pedestrian links At many junctions, the signal control provides for pedestrians to receive a green-man signal when it is safe to cross. If the green-man indication is given automatically without pedestrian push-buttons, then it is not necessary to represent pedestrians in MOVA. The more common practice in the UK is for pedestrians to demand the green-man facility by operating push-buttons. In this case, pedestrians must be represented in MOVA by a 'pedestrian link'; this is necessary solely to allow the push-buttons to demand a fixed-time green phase during which pedestrians can cross. Figure 2.3 shows an example site where a pedestrian link would be used. No optimisation of the pedestrian green period by MOVA is possible. It is possible, however, to combine MOVA fixed-green control with PUFFIN-style variable clearance periods using on-crossing pedestrian detectors. (Variable-clearance TOUCAN crossings can be controlled similarly). The way to do this is to put the wait-light signal onto the UTC interface (or make it available to MOVA in some other way). Then specify the pedestrian link ‘ltype’ as having an unlatched detector (100 + MOVA detector number). In MOVA M4, an additional link will also be needed with ltype = 124. In MOVA M5, no further action is necessary. It is further possible, by setting the stop penalty value for the link to either 64 or 65 to include time weighting for pedestrians which can, in some circumstances, reduce the waiting time for pedestrians. 2.3 MOVA Control Principles MOVA adopts different forms of control depending on whether traffic conditions show the junction to be under or over-saturated. Broadly, if queues clear each cycle, the junction is under-saturated; when appreciable numbers of vehicles are left in a queue at the end of green, the junction is over-saturated. First of all there are two actions early in the green which are common. For each link receiving green, MOVA gives:

i) An absolute minimum green period for the current green stage specified by the user in the MOVA data (also set in the Controller and cannot be overridden).

ii) A possible extra (variable-length)

minimum green period for each link designed to clear vehicles counted into the queue between the X-detector(s) and the stopline, and needing more than the absolute minimum green.

After this, the action MOVA takes will depend on whether a junction is judged to be over or under saturated as follows: a) Under-saturated: MOVA minimises

vehicle delay and vehicle stops for the whole junction (see Section 2.3.1).

b) Over-saturated: MOVA maximises

capacity on congested (over-saturated) approaches (see Section 2.3.2).

MOVA chooses a) or b) automatically. 2.3.1 Minimising stops and delay When MOVA is minimising stops and delays, it takes the following action. After the calculated (or fixed) minimum green has expired, there is a possible further period when the queue on the link is judged to be still discharging at saturation-flow. After the variable minimum green for a link, traffic is usually moving freely over the X-detector in each lane. By examining the size of the time 'gap' between successive vehicles crossing the X-detector, the end of saturation flow is decided for each lane. As soon as any one lane of a link has ended saturation flow, which occurs when a gap greater than a preset critical gap is found, then the whole link is judged to have reached the ’end-saturation’ condition.

Once saturation flow has ended for all 'relevant' links (those links which are going to lose right-of-way when the change to the next stage is made), MOVA then decides whether to end or continue the green stage on the basis of minimising delay and stops for the junction. Note that if saturated flow continues for a long time, MOVA does not simply hold on to the green – the exact way it behaves


September 2005 9

depends on a number of factors (see AG 44 Section 4.2 and AG 45 Sections 3.7 (MAX) and 3.8 (ESLMAX)). Once the current green stage has reached end-saturation, the queues on all the relevant links should have discharged and traffic should be flowing freely. MOVA then makes use of models representing traffic on each lane separately. Each lane model is updated from IN- and X-detector information every half-second; it represents both the position of vehicles on the approach and their movements towards the stopline assuming free flow conditions at 'cruise speed'. Queuing is not represented in the model, but MOVA separately maintains a check on the numbers of vehicles currently queuing at red signals around the junction. MOVA uses the lane models to calculate which vehicles will benefit if the current green is extended, and estimates the delay they would save compared with waiting for green in the next cycle. Vehicles passing through the extended green without stopping produce a further benefit based on the assumption that each vehicle-stop saved is equivalent to a user-specified number (P) of vehicle-seconds of delay. From the queue counts and the measured average arrival flows expected to join these queues in the future, MOVA estimates the losses which an extension of the current green stage will cause. A performance index equal to the net delay saving plus weighted stops for all relevant links is calculated. If the performance index falls to zero or below, MOVA makes the decision to change to the next stage; if the performance index is positive, the current green is extended. Performance Index = Benefits - Losses Benefits = Delay saved + (P x Stops avoided)

if green extended Losses = Extra delay to vehicles receiving

longer red signal

2.3.2 Maximising capacity Once significant queues persist at the end of green, detector information is no longer adequate for MOVA's delay-and-stops-minimising process (Section 2.3.1). Thus, during over-saturated periods, a substitute control process involving capacity maximisation is used instead. See AG 44 for fuller details. Definition within MOVA of over-saturation Over-saturation occurs when a significant traffic queue on a lane has failed to discharge fully at the end of the green period. A lane is identified as being over-saturated shortly after the start of a red signal, and this information is then used to influence control action during subsequent greens. MOVA defines a lane to be over-saturated if either of two independent tests is satisfied: i) checks the rate of queue build-up

after the end of the green; if the queue of vehicles after a certain time reaches or exceeds a pre-set number (the over-saturation critical count, OSATCC in the data set), then the lane is over-saturated.

ii) checks whether the IN-detector (or

X-detector on a short lane) has been 'on' for an excessive time during a certain period following end of green. A detector which is occupied for at least (usually) 6-seconds indicates over-saturation; either the vehicles queuing for the green just ended have failed to move, or a new queue has formed abnormally quickly.

Maximising capacity for over-saturated links If any one of the 1, 2, or 3 lanes on a link is over-saturated, then the link as a whole is judged over-saturated and MOVA adopts the alternative capacity-maximisation process for deciding the link green time. An over-saturated link will first receive the normal variable minimum green time (Section 2.3). After this, MOVA no longer checks for the end of saturation flow in the normal way, nor does it use the delay-and-stops-minimisation process. Instead, it


September 2005 10

assesses the efficiency of use of the green and decides whether capacity is likely to be maximised by continuing this green or not. For links which maintain full saturation flow during long greens, capacity will be maximised by continuing the green as long as possible (subject to maximum limits). The signals will operate to long cycles and time lost due to changing from stage to stage through the cycle will be minimised. For other links, the rate of discharge may be high early in the green but decrease later. In such cases, capacity may be maximised by ending the green as soon as the discharge falls below the initial saturation flow value, or it may be better to continue the green despite the discharge at a rate which is less than the full saturation flow. Every half-second, MOVA estimates a 'flow efficiency factor' for the current green time, and hence determines the approximate capacity-maximising green time. The procedure tends to tolerate reduced rates of discharge for longer at junctions where there is a large amount of lost time (lost time may be thought of here as the normal sum of the effective interstage times; more detail is given in (AG 45 Section 3.8) and hence a greater penalty in frequent changing from stage to stage. Lane weighting when more than one approach is over-saturated At some sites, due to constraints on queuing space or for various traffic management or policy reasons, it may be that preference needs to be given to clearing queues on particular approaches. MOVA can be made to switch capacity towards over-saturated approaches by applying lane weighting factors greater than the normal unity. If a lane weighting factor is increased by 5 (e.g. 6 instead of the usual 1), this will be equivalent to having an additional oversaturated lane on the stage when MOVA considers the relative merits of each stage. The total of all weighting factors must not exceed 64. If the total green time (TOTALG) in MOVA is curtailing green times in oversaturated conditions, the lane weighting factors will also influence the distribution of the green between stages.

Control of under-saturated links when a junction is over-saturated Although one or more links at a junction may be over-saturated, there will normally be other links that remain under-saturated. MOVA controls such links so as to just clear queues but no more. Thus, MOVA determines the end of saturation flow for under-saturated links (Section 2.3.1), using somewhat more severe criteria than normal, and omits the optimisation process (Section 2.3.1) which might normally extend the green further.


September 2005 11

2.4 Special MOVA features for junctions with flared approaches

Some approaches may have been widened to provide more lanes near to the junction than further away (Section 2.2.3). Such flaring leads to a more complex optimisation problem as follows: (a) Saturation flow may be higher during

the early part of a green due to both long and short lanes discharging; later, the short-lane queues will have cleared and saturation flow will correspond to a lower rate for the long-lanes only.

(b) The situation in a) occurs when both

long and short lanes receive the same green signals and can both discharge freely at the same time.

The matter becomes more complex if the long and short lanes do not receive identical greens or if a lane (usually a right-turn lane in the UK) receives green but is unable to discharge freely due to opposing traffic which has priority.

The way MOVA is structured to cater for flaring is described below. 2.4.1 'Bonus green' calculations Figure 2.4a shows an approach where both lanes receive the same green signals. The saturation flow across the stopline might be as illustrated in Figure 2.4b. The extra capacity provided by the short-lane (shown as the shaded area) is equivalent to 'extra effective green' or a 'bonus green' for the main long lane.

Figure 2.4b : Variable saturation flow and the ‘bonus’ effect

10 200

0

Rate for lane 2 = S

Rate for lane 1 + 2

Saturation flow (vehicles/second)

Bonus green = n/S seconds

Bonus = n vehicles per green

Green time (seconds)

Figure 2.4a : Example of a flared approach

X - detectorsIN - detector

Lane 2

Lane 1


September 2005 12

Each signal cycle, MOVA updates the bonus by comparing the counts over the X-detectors (lanes 1 and 2) with an expected count for just the long-lane (lane 2). This updating is done after sufficient green time (at a pre-set 'bonus recalculation time', BONTIM in the data set) to ensure that the full bonus is measured; MOVA then converts the bonus count into an equivalent amount of 'bonus-green time'. Thus, in Figure 2.4b, if the bonus capacity (n) is 7 vehicles per green and the long-lane saturation flow (s) is 0.5 vehicles per second, the bonus green will be (n/s) 14 seconds. If a bonus link has several long lanes, the value of 's' in the above calculation is the sum of the saturation flows for the long lanes. Thus, for a bonus of n vehicles, the bonus green reduces in proportion to the number of long lanes. Bonus greens tend, therefore, to have a significant effect on control decisions mainly for links with a single long lane. Although less simple to illustrate than the above example, MOVA also estimates the bonus green when short and long lanes have differing green times, and also for situations involving 'sinks' (see Section 1.5 ‘Glossary’). 2.4.2 The effect of bonus green upon

the end-saturation decision For situations such as that shown in Figure 2.4, theory suggests that the end-saturation decision should depend on the relationship between the link bonus green and the lost time. Normally (Section 2.3.1) the green for a link is extended at least until the end of saturation flow is reached. For flared approaches, MOVA distinguishes between two cases: i) bonus green = L or > L

(L = junction lost time) end-saturation takes place no later

than the time in the green corresponding to the maximum capacity condition, at the time when the full bonus has been gained (BONTIM), even if the main, long-lane traffic is still discharging at saturation rate.

ii) bonus green = 0 or < L

end-saturation is not automatically

judged to occur at BONTIM; end-saturation will be decided only when the discharge flow from the lane, or a combination of long and short lanes (see Section 2.4.3), has fallen below single lane saturation flow.

2.4.3 'Combined detectors' to measure

flared-approach saturation flow On unflared approaches, the end-saturation decision is made by examining gaps between vehicles at the X-detector for each lane individually. However, where short lanes are present (as in Figure 2.5) traffic discharging at single-lane saturation flow rate from a long lane (lane 2) may distribute itself over two or three separate lanes at the X-detectors. If so, none of the three lanes would be likely to maintain full saturation flow for very long, and the green might be curtailed. However, when the bonus green is less than the lost time (Section 2.4.2 case ii), the end-saturation decision should not be made until the long lane feeding the short lanes has itself ceased to discharge at saturation flow rate. It has therefore been arranged in MOVA that the X-detector for a long lane (e.g. Lane 2 in Figure 2.5) may be specified as forming a 'combination X-detector' together with one or two short-lane 'associated X-detectors' (e.g. those for Lanes 1 and 3 in Figure 2.5). The combination X-detector is 'on' if one or more of the constituent X-detectors is 'on', and is 'off' only if all the constituent X detectors are “off”. Initially, while the flare is discharging, MOVA treats each lane separately to make the end-saturation checks lane-by-lane. After a pre-set 'combination detector time' (COMTIM in the data set) MOVA examines the gap between successive vehicles in two or three lanes together using the combination X-detector. Important: Combination X-detectors include only those associated X-detectors for short lanes which discharge freely at the same time as the long lane feeding them. For example, a short lane for opposed right-turning traffic would be excluded. Figure 2.6 later gives another example.


September 2005 13

2.4.4 Short-cycle control to maximise

capacity with flares If the bonus green for a link exceeds the lost time (Section 2.4.2 case i), and the junction is under-saturated, MOVA will judge end-saturation to take place when the short lanes providing the bonus have fully discharged (BONTIM). MOVA takes no further positive action to maximise capacity either for the link with the bonus or others. Other link(s) sharing the same green stage as the bonus link may themselves extend the green until they are independently judged to have reached end-saturation; the green stage may then be extended further by the delay-and-stops optimiser. Once a bonus link becomes over-saturated, the situation changes, and MOVA positively imposes short-cycle control on the junction (Section 2.5), provided the bonus green is sufficient (>lost time) and the conditions set by the “BONCUT” data are satisfied. 2.4.5 More complex 'bonus' situations Conflicts of interest can occur in some situations and must be resolved by the user choosing priorities when setting-up MOVA data by use of “BONCUT” values. A bonus link requiring short-cycle control may share the same green stage with other, over-saturated links having a zero or small bonus, which therefore require longer green times to maximise their capacity: neither short nor long cycles will satisfy all the links, so the

user must specify whether short cycle control shall be introduced, or not, when the bonus link satisfies the required conditions. This can be achieved most simply by setting the BONCUT value to 1 which will force the cutting of the of the normal stage maximum to the reduced LOWMAX value. Forcing short-cycle operation may disbenefit links (if any) which receive green in the same stage(s) as this link L but which do not have the advantage of a bonus. This problem can be avoided by setting BONCUT for link L to the value -N, where N is the number of a link which shares the same green as link L. MOVA will then force short-cycle control only if link N is not oversaturated. In this way, link L can benefit from short cycling, except when link N is experiencing difficulties. However, there are a number of restrictions which are dealt with in AG 45, Section 3.11 The examples discussed in 2.4.2 and 2.4.4 consider the need for short-cycle control when the bonus on a single link exceeds the junction lost time. Other cases occur where short-cycles are justified by a combination of bonuses on links receiving green in different stages, when, collectively, several bonuses exceed the junction lost time. MOVA is able, in some but not all cases, to combine bonuses from several stages to instigate short-cycle control. The user specifies which link bonuses may be combined, and may make this conditional upon other links not being over-saturated (AG 45 Section 3.11).

Figure 2.5 : Combination X-detectors for flared approaches

IN - detector

Lane 1

Lane 3

Lane 2

X - detector

Combined det.is “on” if one or more of these 3 dets is “on”


September 2005 14

In a few cases, the user may wish to impose particular stage maximum greens during short-cycle control in order to achieve a policy objective of giving priority to special links. This is possible by use of suitable user-set LOWMAX values. Unless the user has special reasons for setting LOWMAX values, it is recommended that MOVA be allowed to determine the LOWMAX values which will then vary according to traffic conditions. 2.5 Cycle-time control Section 2.3 defines how the green time for a stage is determined in under-saturated or over-saturated conditions. The cycle time which results from the normal sequence of stages is thus dependent upon the duration of the separate stage greens. The cycle time is not normally controlled in any other way, and it will usually be found that MOVA operates perfectly acceptable cycle times. 2.5.1 User-imposed cycle time control -

drifting maximum greens Sometimes, the traffic engineer might wish to impose an upper-limit on the cycle time; this might be needed if traffic conditions would otherwise produce a consistently longer cycle than is desirable. Long cycles can be unsuitable for several reasons: Pedestrians may cease to wait for a safe time to cross; very long greens with a continuous saturated discharge may cause exit blocking; opposed right-turn traffic which needs to clear during intergreens may receive insufficient opportunities to turn. A user-imposed cycle limit, if adopted, applies during normal (under-saturated) control and also during over-saturated control (Section 2.3). Unlike existing systems, it is not necessary with MOVA to limit the cycle by rigidly setting maximum green times. MOVA maximum greens can continue to be set generously long (e.g. 50% above usual). The user merely specifies a desired upper limit to the total green available (TOTALG) for distribution between the stages (AG 45 Section 3.6); this in turn limits the cycle time. MOVA constrains the stage greens automatically using 'drifting maximum greens' to achieve the required total green. The

drifting maxima are continually adjusted to suit changes in traffic conditions. This feature is particularly useful where peak flows are highly variable, either by time of day, day of the week, or seasonally, and normal maximum greens would be difficult to set well. 2.5.2 MOVA-imposed short-cycle control

for bonus situations If MOVA decides that short-cycle control is justified by a large enough bonus (Section 2.4), and this is permitted by the specified BONCUT values, then MOVA automatically calculates the necessary shorter cycle. To maximise the capacity of the bonus link, its stage green is limited to the time (BONTIM) when the bonus link is judged to have ended multi-lane saturation flow. Because the stage with the bonus green is kept to a shorter green, MOVA calculates 'drifting maximum greens' for the other stages (Section 2.5) within a shorter-than-normal cycle. In this way, the bonus link receives its full bonus as frequently as possible consistent with maintaining the current capacities (the same proportion of green in the cycle) for the other stages. 2.6 Other facilities in MOVA 2.6.1 MOVA control of right-turn early-

cut-offs A common facility for right-turning (RT) traffic is known in the UK as a RT early-cut-off (ECO): initially RT traffic receives a full green signal during a stage when it is permitted to turn through gaps in the opposing traffic; subsequently the opposing flow is stopped (cut-off early) and RT traffic is given a right-turn indicative green arrow (RTIA) signal during a stage when it is able to turn freely. Figure 2.6 shows an example junction where stage 3 is an ECO for the benefit of Lane 3. Compared with VA methods of controlling the ECO stage, MOVA uses an improved method for deciding whether or not the free-RT stage (stage 3 in Figure 2.6) is needed. The method requires a detector located just upstream of the stopline, known as an OUT-detector (on Lane 3 in Figure 2.6). MOVA uses the vehicle counts from the X-detector and the OUT-detector to keep an estimate of


September 2005 15

the number of RT vehicles queuing between the two detectors. Whenever this number equals or exceeds a pre-set minimum (usually set to 2 vehicles, including the vehicle at the stopline) the exclusive RT stage is demanded. The reason for having the detector upstream of the stopline is because any vehicles waiting to turn right downstream of the stopline should make their manoeuvre during the interstage and do not need the ECO stage. The pre-set minimum is normally set to 2 as this has been found to work well in practice. A value of 1 can make the calling of the stage slightly erratic as a single free-flowing vehicle can cause the stage to run unnecessarily if it arrives just at the point of the stage-change. During stage 2 in the example, up to the point where the ECO stage is called (stage 3) some RT vehicles may turn through gaps in the opposing flow whilst others may add to the queue. The RT queue may therefore vary all the time stage 2 is running. Unless the pre-set minimum number of vehicles is detected at the point where MOVA decides a stage-change is required, the ECO stage will be omitted from the cycle with resulting delay savings to traffic on other stages. In case MOVA under-estimates the number of vehicles queuing, the free-RT stage will also be demanded if the X-detector indicates a queue reaching this position. Underestimates of the RT queue can result from over counting by the OUT detector, possibly due to either a high sensitivity setting counting vehicles in an adjacent lane or to interference leading to the detector “chattering”. At some sites, RT traffic requiring an ECO must share a lane with straight or left-turn traffic. If so, the MOVA system for ECO control is unsuitable, and a version of the

original call/cancel method has to be substituted. Full details of this and treatment of other RT situations are given in AG 44 Section 7.1.


September 2005 16

Link Lanes on link

1 2 3 4 5 6

Lane 1 Lane 2 Lane 3 Lane 4 Lanes 5 & 6 Lanes 7 & 8

Figure 2.6 : Example site with OUT-detector (for early-cut-off) IN-sink detector and combination X-detectors for a flared approach

Lane 1

Lane 3

Lane 2

Lane 7

Lane 8

40m

100m

40m 100m

45m

55m

110m

Combination X-detector is ‘on’ ifX-detector on Lane 4 or 5 is ‘on’

110m

80m

45m

Lane 4

N

Lane 6

Lane 5

IN-sink detector in slip road counts traffic leaving Lane 7

OUT-detector in Lane 3 controls early-cut-off (Stage 2 ---> Stage 3)

1 2 3

Combination detector


September 2005 17

2.6.2 Situations involving traffic 'sinks' Sometimes, traffic leaves an approach by an unsignalled exit after having been detected by the IN or X-detector on a lane. Such an unsignalled exit is known as a 'sink' in MOVA. There are many possibilities for individual vehicles to leave an approach before reaching the stopline (e.g. turning-off into private drives or shop forecourts). These minor exits are not important in MOVA. However, it may be desirable to install extra 'sink-detectors' to provide MOVA with counts of vehicles leaving a lane via unsignalled exits used more frequently. Sink detectors are used mainly where there is a left-turn slip-road, or a bay which is too short to be a MOVA 'lane' with an X-detector of its own. Figure 2.6 shows an example 'IN-sink' detector on the south arm used to count traffic which crosses the IN-detector in Lane 7 but not the X-detector. Another type of sink, downstream of an X-detector, is called an X-sink. Further details concerning sinks are given in AG 45 Section 3.9 and most of the examples in 3.13 have sink-detectors. Sink detectors allow the queue sizes to be assessed more accurately for minimum-green and delay optimisation calculations. They also allow MOVA to calculate the bonus-green effect due to use of slip roads or bays; this occurs in much the same way as for short-lane situations (Section 2.4) but is less obvious. If an approach is oversaturated, with long queues, then vehicles leaving approach lanes via slip roads or bays during the red or initial part of the green are effectively providing extra capacity for the approach to help clear queues. A large bonus green means MOVA may adopt short-cycle control to maximise capacity as in Section 2.5. 2.6.3 Detector checking and 'suspect'

detectors Any vehicle-actuated control system is heavily dependent on its detectors for efficient control. This is particularly true of MOVA which relies on the detectors for counting traffic flows and estimating queues lane-by-lane. In consequence, a large proportion of the MOVA computer program is

made up of extra logic to identify when detector information is likely to be unreliable and what alternative action to take. MOVA checks the detectors every cycle. Detectors which have remained 'on' for at least one complete cycle of the signals, or have remained 'off' for a calculated critical time (which depends on flows – lower flows mean the critical time is longer) are flagged as being 'suspect'. The check involving a long 'off' period is unreliable when flows are very low, and is therefore omitted when the historical flow matrix (Section 2.6.4) shows an expected flow rate of 150 vehicles/hour or less. The 'suspect' condition does not necessarily mean that the loop or detection equipment has failed to operate correctly. It will more usually mean that vehicles have parked on or near to a detector and other traffic is not able to cross the detector normally. Suspect detectors are returned to the normal 'acceptable' state once they begin to count vehicles again. 2.6.4 Substitute information when

detector(s) are suspect While a detector is flagged as suspect, MOVA will in most cases ignore that detector completely, and will try to substitute information from one or more alternative detectors, or will try to carry-out substitute decision-making logic as detailed in AG 44. If the alternative detectors are also suspect and therefore unusable or if there are no suitable alternate detectors, MOVA will revert to using the historical flow value which has previously been stored in a flow matrix. This matrix saves a flow estimate for each half-hour of each day of the week and updates it weekly if the detector is operating correctly. MOVA thus always has a lane flow estimate for its various calculations, such as those used in the delay and stops optimisation process. MOVA works well even when there are several detectors not working. Despite MOVA’s high tolerance of detector failure, prompt action should be taken to repair detector faults. The historical flows provide valuable data for traffic planning purposes at no cost.


September 2005 18

2.6.5 Assessment of site performance The traffic engineer may wish to assess the performance of a new traffic-control installation, but resources are often limited. To help, a method has been built into the standard MOVA system which readily provides an indication of junction performance (Young, 1988). The automatic assessment method uses the detectors which are installed for MOVA control (X and IN detectors), but uses them in an independent way to give a figure-of-merit for the signal control system then operating. Broadly speaking, a poor control system which produces long delays will cause queues of stationary vehicles to form for long periods over the detectors; this will give a high average occupancy (or 'on' time) per detector. In contrast, a good control system will produce shorter queues and lower occupancy. Provided queues are not excessively long or short , then there is a linear relationship between mean occupancy and mean delay per vehicle. The user can select up to 12 periods of the day for separate analysis; details are given in AG 45 Section 3.12. 2.7 High-speed sites MOVA has been designed for use at all types of isolated intersections, including those on the highest speed all-purpose roads such as rural dual-carriageway Trunk roads. There is a particular concern at high-speed sites that drivers approaching the junction may get trapped in the ‘dilemma zone’ (where stopping is uncomfortable with the risk that following vehicles may crash into them, but continuing can mean crossing the stopline during the early part of the red). 2.7.1 MOVA and speed assessment/

discrimination equipment Signals controlled by D-system VA have been supplemented by either 'speed assessment' (SA) or 'speed discrimination equipment’ (SDE) (Department of Transport 1984) in an attempt to address the above problem at signals on high-speed roads. For reference the relevant equipment specifications are TR2210 and MCE0108.

The problem with VA when combined with SA/SDE is that, in all but the very lightest of traffic intensities, the signals frequently change when a maximum timer has been reached, as opposed to finding a big enough gap(s) in the traffic in which to change safely. With such arbitrary changes there is a chance that vehicles will be caught in the dilemma zone. The reason for the propensity to change arbitrarily at maximum is because gaps have to be very big for D-system VA with SA/SDE to change before reaching the maximum. What happens is that the SA/SDE system provides extensions to ‘fast’ vehicles which allow them to reach the system-D X, Y, Z loops. These loops then give further green extensions to allow vehicles to cross the stopline before changing to amber. SA works differently from SDE. With SA, it will be necessary for a gap in the traffic arrivals to be about five seconds before the signals change (given an extension time from the Z loop of 1.5s). With the less sophisticated SDE, the gap in traffic arrivals needed for the signals change is similar for both double and triple SDE, and varies slightly with speed. At lower speeds the gap will be around six seconds. At higher speeds it would be nearer 4.5 seconds. All of this means that gaps in the traffic need to be very big for the signals to change. To compound the problem, the gaps need to occur simultaneously on all lanes and in all directions that are equipped with SA/SDE, currently on green and will lose right of way together. A study by TRL (Baguley and Ray, 1989) of the effectiveness of SA and SDE, counted the numbers of vehicles crossing the stopline after the onset of the red signal ("red runners"). In addition, an assessment of hazardous incidents ("conflicts") was made. It was concluded that SA/SDE appeared to reduce red runners and conflicts only at junctions with low flows, and high speeds. These were defined as approximating to sites with less than 20,000 total vehicle inflow per 10 hours 08.00-18.00, and with 85-percentile free speed during green in excess of 90km/h.


September 2005 19

2.7.2 MOVA operation at high-speed sites

A key difference between MOVA and VA+SA/SDE is that MOVA operates without speed-measuring detection. It is, for this reason, important to measure carefully the average 'cruise speed' on each approach (see Sections 3.4.1 – 3.4.3), and hence to correctly locate both the IN and X detectors. As explained in Section 2.3.1 MOVA models free-flowing traffic to estimate the position of each vehicle as it travels down a lane from IN-detector to X-detector to stopline. First, MOVA discounts those vehicles approaching a green signal which are judged to be fully committed to continuing through the junction even if the lights change to amber now. Such vehicles will necessarily treat some or all of the amber as if it were effectively green. MOVA assumes that vehicles within a specified number of seconds from the stopline (GAMBER in the data set) and depending on the cruise speed (see AG 45) are already near enough to continue if the lights change to amber. See Figure 2.7. MOVA then examines the vehicles further upstream, considers the benefits in reduced delay and stops if these vehicles receive an extension of the green to allow them to continue through the junction. It is thus important that the user correctly sets the 'stop-penalties' in the MOVA data (AG 45 Section 3.8).

Vehicles are represented by in the example lane model in Figure 2.7. Each box corresponds to 0.5 second cruise time. Like VA + SA/SDE, MOVA can choose to end green when a gap is found in the arrival flow. By discounting already committed vehicles, MOVA has a greater probability than VA+SA/SDE does of finding such a gap. Alternatively, in busy periods, rather than wait for a complete absence of vehicles, MOVA can and normally will decide that a suitable time to end the green occurs when the 'included vehicles' correspond to an arrival rate below average. Thus, the number of vehicles present, that might potentially jump the red, is also below average. 2.7.3 Comparisons of MOVA and speed-

assessment performance The above arguments support the view that MOVA should have a lower likelihood than VA+SA/SD of 'red runners', and this has been confirmed by trials carried out at two sites on major Trunk Roads. Results were separated into periods when the VA+SA system was frequently reaching maximum green limits, and lighter-flow periods (when gaps in the arrivals were common) and the VA+SA could perform as intended. At very low flows near to midnight, the two methods of control gave very similar results. Otherwise, MOVA gave substantially fewer red-runners (Vincent et al. 1987, 1988).

Overall, MOVA reduced red-runners by an estimated 50,000 vehicles per year per site. These numbers represent reductions of between 30 and 50 per cent depending on site and time-of-day.

IN

Figure 2.7: MOVA’s lane model STOPLINE

GAMBER

Included vehiclesexcluded vehicles

X


September 2005 20

2.7.4 Safety of MOVA at high speed sites

The safety of MOVA compared with VA has been the subject of two studies. Nineteen of the sites in the original 20 site trial were reviewed for safety. Overall there was no difference between MOVA and VA, except at the four high speed sites where MOVA did reduced injury accidents by 30% but with only 90% confidence. Nevertheless, the result was encouraging. The second study was carried out in 2000/01 and looked at 31 high speed sites that were previously equipped with VA + SA/SDE. This study concluded that MOVA was as safe as VA + SA/SDE, but not more so. The result was unexpected and further research is to be carried out as to why the expected safety improvement did not materialise. One aspect where there is a notable difference between the two studies was TRL’s involvement in the site data generation along with all the on-street measurements needed. TRL did all the work for the 20 sites trial, but were not involved in any of the 31 sites in the second study. At this stage it is not known how significant this factor could be, but MOVA can be difficult to set up to a high standard and there could be some aspect of this that may have had a negative influence on the result. The importance of thorough validation after commissioning is again stressed as a key element of achieving good results. 2.7.5 Advice on intergreen settings at

high speed sites Before offering advice on intergreen settings when using MOVA at high speed sites, it should be noted that the SA/SDE green-extensions cannot be incorporated in any way: MOVA should be allowed to control the signals entirely without interference from green extensions from any other sources, including SA/SDE. Interfering with MOVA operation will reduce MOVA’s ability to locate the best gap in the traffic in which to change stage. The issue of the intergreen at high speed sites arises because, when SA/SDE is used and a maximum change is made, the all-red time is extended by 2 seconds to help ensure

drivers can pass through the junction ‘safely’. MOVA cannot control this, which makes it necessary for site authorities to consider whether it is better to have the all-red extension (or a proportion of it) configured to appear every cycle or to do without it altogether – these are the only choices. Note that TRL have considered how MOVA could control the all-red extension, but, in theory, every stage-change decision MOVA makes could result in drivers being caught in the dilemma zone. Therefore there is no obvious condition under which the all-red should be extended or not under MOVA control. To help in this choice, knowledge of MOVA operation is needed. When MOVA is in its delay optimising mode, it tends normally to change stage at times when there are gaps in the traffic. When this is the case, the all-red extension would not normally be needed, especially since high-speed sites tend to have longer intergreens anyway. Note, however, that although MOVA has been proven to substantially reduce the number of red-runners compared with SA/SDE control, red running will still occur. Under heavy traffic conditions MOVA can make stage-change decisions that largely ignore the precise location of individual vehicles, even if the arrival rate is below average. Thus drivers may be caught in the dilemma zone even if the stage change has not occurred at an arbitrary maximum. This could happen regularly at saturated junctions and/or junctions with a very low TOTALG. Here it may be argued that an all-red extension is needed. Given that MOVA is most likely to make such changes when there is a fair amount of traffic present, speeds should generally be lower and extending the all-red should be less important. In fact, regular long intergreens will be inefficient which might encourage red-running by always giving drivers a safety cushion. Another factor to consider is the nature of the site and the sort of speeds experienced. Higher speeds generally give more opportunity for serious accidents to result from misjudgements. The all-red extension may give a larger margin for error which might be considered more necessary at the really high-speed sites. Other sites that only just get into the ‘high-speed’ category may benefit more (in safety terms) from efficient


September 2005 21

control – long intergreens (which are known to cause safety problems at urban crossroads) being unhelpful possibly. Finally, it has to be said that no one has really established whether the all-red extension has a positive safety benefit or not. It could be that, by making it possible to red-run safely at some sites, red-running is encouraged at all sites, giving an overall safety disbenefit. 2.8 Facilities for emergency and

priority vehicle control Emergency and priority vehicle signal control is implemented fully within the MOVA system, without the need to shift to another Controller 'mode' (see TR 2210). Separate control functions are available for two levels of control: Priority is implemented by means of

special-vehicle detectors (SVDs) responding solely to emergency and priority vehicle passage; presence detection of stationary emergency and priority vehicles is not needed. The detectors will generally be of the buried inductive loop variety, but any type of detection/location system capable of accurately locating the bus/emergency vehicle can be used, including AVL systems. A maximum of three consecutive detectors per approach lane are accommodated; two are demand and extend detectors (second one optional), and the third (optional) acts as a cancel-detector for priority-extensions, etc.

Emergency/priority links are specified in

the MOVA data to represent the various emergency/priority movements. Such links will not themselves have lane(s) but will have selective detectors associated with the links.

Special control options include existing

green 'hold' and 'extend' features, plus rapid changes to selected stages when intervening stages are 'truncated' (cut short) or 'skipped' (omitted) as necessary.

2.8.1 Emergency-vehicle control Green extensions and stage demands are actioned as absolute first priority, as soon as possible. Emergency demand: a demand for an immediate right-of-way for an emergency link, originating from emergency-vehicle detector(s); subject only to safety constraints of minimum, intergreens and banned stage changes, plus a pre-existing emergency hold or extension which takes precedence. Emergency hold period: a setable minimum duration of the green for an emergency link following an emergency change, which period cannot be overridden. This period differs from the normal link minimum green also specified for any MOVA link, which applies when the link receives green other than with an emergency demand present. An emergency hold can be cancelled by action of an appropriate cancel detector at the link stopline. Emergency extension: maintenance of an existing green for an emergency link having right-of-way when an emergency-vehicle detection is received, and limited by an emergency-extension maximum running period; can otherwise be overridden only by an emergency-extension cancelling detector. 2.8.2 Priority-vehicle control Extensions and stage demands are actioned as second priority, and subject to user-selected constraints if desired; extensions always serviced before stage demands. Priority demand: a demand for an immediate right-of-way for a priority link, originating from priority-vehicle detector(s); potentially subject to user-selectable and/or traffic-related constraints, in addition to normal safety constraints of minimum, intergreens and banned stage changes; emergency action and priority holds/ extensions take precedence. If a priority demand requiring stage skipping is not actioned immediately, due to minimum-green or other constraints, the system shall accept, and action first, another priority call which requires an intervening stage.


September 2005 22

Priority hold period: a setable minimum duration of the green for a priority link following a priority change, which can be overridden by an emergency demand for another stage. This period differs from the normal link minimum green that applies when the link receives green other than with a priority demand present. A priority hold can be cancelled by action of an appropriate cancel detector at the link stopline. Priority extension: maintenance of an existing green for a priority link having right-of-way at the time a priority-vehicle detection is received, and limited by a setable priority-extension maximum running period. This can otherwise be overridden solely by emergency demands for another stage, or by a suitable cancel detector. 2.8.3 Constraints on priority-vehicle

control Some of the constraints on priority demands are dependent upon the previous history of truncations/skips by earlier emergency or priority changes. When a stage is truncated or skipped by such action, any link which receives green in an affected stage is flagged as having been truncated or skipped, by setting an indicator which is relevant for the following cycle. The flags are set for traffic links only if priority action curtails traffic still discharging at saturation rate. The use, if any, which is made of truncation and skip flags is determined by the user-selected facilities which are detailed in AG 45. These allow priority demands to be inhibited for one cycle from truncating or skipping selected stages. Inhibits can also be made dependent upon whether traffic on the stage in question is oversaturated or not. These facilities therefore determine the degree of priority given to priority vehicles. It should be noted that no "compensation period" (as used in earlier UK bus-priority systems) is provided in the MOVA system. The usual MOVA features designed to identify and deal with congestion will automatically operate to deal with problems which may have occurred due to emergency or priority action. Nor is a fixed "inhibit period" specified. The use of truncation and skip link indicators allows priority changes to be inhibited only to the extent that previously

disadvantaged links are prevented from suffering again immediately. The "inhibit period" which totally inhibited the priority demand was less selective. 2.8.4 Results from research TRL has carried out studies at four sites to assess the use of bus priority in MOVA. The first trial was carried out at a site in Harlington, SW London. Buses benefited from large delay reductions of between 21 and 44 seconds with priority MOVA control. It proved necessary to use the ‘inhibit’ facility as traffic on one stage initially experienced large delays in the morning peak. At the second site in Hanworth, SW London, benefits were small (3.5 to 5.7s) due largely to an inherent conflict between buses on opposing stages. Somewhat longer queues with priority control cause extra delay to buses in reaching their bus-stops, and hence reaching the SVDs which were downstream of the bus stop. At the third site, in Winchester, all buses requiring priority arrived on the same stage, so there were no conflicts between buses. Two bus-priority variants were tested. The first required all stages to receive at least a minimum green before being truncated (as used in the London sites), while the second also allowed skipping of the least important traffic stage. The second system used a reordering of the stage sequence to place the main general traffic stage immediately after the stage giving buses priority. It also successfully used and tested a new optional facility to prevent severe oversaturation due to repeated priority calls. The first system reduced mean bus delays by 5 seconds (26%) whilst the second reduced them by 11 seconds (56%). The latter also reduced variability to one third of the previous value. At the fourth site in Merton, changes to delays were statistically insignificant, due almost entirely to the small proportion (15%) of buses detected on key turning routes, although these movements did appear to suffer from blocking by opposed RTs running in the same stage. Other bus movements did benefit from reduced delays (10s) but, overall, there was little benefit because of the


September 2005 23

small numbers of buses fitted with the priority detection equipment. Overall, the benefits are very site dependent. The facilities in MOVA were well exercised by the trials and offer features needed to give buses priority and to prevent excessive disruption to other traffic. However, issues to do with where (and how many) buses are detected and the extent of conflicting bus priority requirements will have a large bearing on the effectiveness of MOVA bus priority facilities. 2.9 Other uses of Emergency and

Priority Links 2.9.1 'PREVENT' Facilities It may sometimes be desirable to use an advance detector to prevent a change to a stage other than that later to be required by an emergency/priority vehicle. Such a facility is sometimes known as a 'prevent' in that it sets up the required stage, but does not attempt to immediately truncate the running stage. An 'emergency prevent' can be arranged as follows. The data is set to include an additional (pseudo) priority link, actuated by an emergency-vehicle detector placed in advance of those detectors used for the genuine emergency link. This advance detector would demand the stage required (later) by the emergency link, but, unlike the emergency link, would be subject to the priority-demand facilities which could be set up (priority facility code –6, see AG 44 Appendix C) to not allow truncations, but to allow skipping once a stage had ended normally. The priority demand would thus override any other normal demands which might otherwise try to change to a stage unsuitable later for the emergency vehicle. This feature can be varied, for example, to prevent changes except to a certain specified stage - say, the one before that needed by the emergency vehicle. 2.9.2 Hurry Call facilities using queue

detectors Traffic engineers sometimes wish to influence the signal control at a junction in response to detection of a queue.

Sometimes, it is necessary to cut short a green, and change to an alternative stage, due to traffic being unable to leave the junction because it is blocked by the detected queue on an exit. In other cases, it may be necessary to demand a special stage to give extra time to clear a queue detected on an approach to the junction. In both these cases, MOVA can be set up to respond appropriately by inclusion of data for a pseudo emergency or priority link. The queue detector is connected as though it were an emergency/priority detector, but it must be set up to provide a signal which is 'on' only after a continuous period of occupancy, typically of 6 seconds. This detector input to MOVA can then trigger a demand for a particular stage, and/or stage truncation and/or skipping. 2.9.3 'CANCEL' facilities The simple extension/hold-cancelling feature, (detailed in AG 44, Appendix C.4.3), operates well when only a single emergency/priority vehicle is likely to approach the junction at any time. However, this system will ignore the second of any closely-following emergency/priority vehicles. When the first vehicle operates the stopline cancel detector, any extension/hold from the second vehicle will simply be cancelled. If it is likely that close-following emergency or priority vehicles will be common, the facility can be made somewhat more discriminating, as follows. As before, the approach is equipped with two demand/ extend detectors D1, D2 in fig 2.8, and one cancel detector C, but now, these are used on two emergency/priority links for the same approach: Link i) uses both demand and extend

detectors D1, D2, and also the cancel detector C. The extensions/hold are set generously long, for cancellation of any excess time by the cancel detector as the vehicle leaves the stopline. This ensures that enough time will be given in heavily congested conditions. Link ii) uses just the demand and extend detectors D1, D2, and does not specify any cancel detector.


September 2005 24

Thehold time and the extension from D1 is set generously long to reach the second detector D2 and adequate for reaching the stopline in normal conditions. The extension from D2 is set adequately long to reach the stopline in normal conditions. In this way, without a cancel detector, excessive extension/hold times are not generated, but equally cannot be cancelled by the departure of the first emergency/priority vehicle.

Figure 2.8 Thus, even if a first emergency/priority vehicle reaches the stopline and cancels any hold/extension for link (i), a subsequent vehicle will still have a hold/extension provided by link (ii) that should be adequate in most circumstances. If the second vehicle is between D1 and D2, when the first cancels, then the second vehicle will again demand/extend for link (i) when it reaches D2. If the second vehicle is between D2 and C when the first cancels, then the second vehicle relies on the normally adequate extension from D2 on link (ii) to clear the stopline. 2.9.4 ‘Linked’ MOVA The question of whether MOVA can be used at more than one junction close to one another is often asked. To a large extent, it was assumed that any closely spaced junctions likely to benefit from co-ordination of signal timings would not work properly if separate MOVA systems were used. With the introduction of emergency-priority facilities, it was thought possible to introduce some linking between two otherwise separate MOVA controlled junctions. This is achieved by taking the confirm output of one of the junctions and connecting it to a priority detector in the other. This gives a master-slave relationship that can be set up to give a loose form of co-ordination between the two junctions.

Research was carried out to look into the potential of this idea. There were two main conclusions from both the early research and from more recent installations. Firstly, it was found that MOVA works much more effectively at closely spaced junctions than was first thought. Secondly, there are occasions when linking is a useful feature that helps to co-ordinate junctions when there are strong directional movements. See Example 7 and Example 8 for more information. 2.10 Time-of-day features in MOVA MOVA is flexible enough to cater for wide variations in flows; this considerable flexibility means that it is seldom necessary to timetable the changing of maximum greens familiar to VA users. MOVA does, nevertheless, have provision for three or four (depending on version and manufacturer) different data sets or 'plans'. Each plan can be timetabled to operate during specified periods of the day and days of the week. Infrequently, these plans may be used to change individual data elements. To ensure that no problems occur when MOVA switches from one plan to another, the following key data items must be the same in each of the three data sets: - the number of stages at the junction - the number of lanes approaching the

junction - the number of links (lane-groups) - for a link, the numbers of the constituent

lanes Note: Stage 1 is required to be a stage which is normally demanded every cycle in each plan. The plan change then takes place at the start of the next stage 1 green after the timetabled time. This avoids potential difficulties due to prohibited stage changes and stages which are not demanded in particular plans, which might otherwise lock up the signals. Any other MOVA data can be changed from plan to plan. Examples of common uses are (also see AG 45): • Changes in priorities. • Lane weighting factors. • Stage maximum greens (e.g. for fixed-

time stages such as late releases).

C D2 D1


September 2005 25

• Controlling cycle time using the total green limit.

• “BONCUTS” to define if a particular link bonus may cause automatic switching to short cycle control (Section 2.5.2).

Where stage sequences are to be varied by time of day, all plans must contain all the stages that are ever used, even though some stages may not be used in particular plans. Variations in stage usage are achieved by selectively omitting one or more stages from the 'master' sequence by use of the SDCODE matrix. Other data variations: some junctions may experience a large variation in traffic composition between (say) peaks and off- peaks. It may be necessary to timetable variations in saturation flow headway-time and start-up lost time. This is important, as these two values are used to derive other quantities in the data set (see AG 45 Section 10) and inaccuracies may have a significant impact on the effectiveness of control peaks. 2.11 Benefits expected from MOVA

installation In the early stages of MOVA implementation it was installed at 20 trial sites in the UK (6 in the Greater London area). Using MOVA’s assessment logs, TRL were able to compare

the performance of MOVA against D-system VA (Peirce and Webb, 1990). During the 20-site trial it was found that, on average, MOVA gave a reduction in delay of 13% (which generally equates to about 2-3% improvement in capacity). However, the benefits over D-system VA varied depending on the exact nature of the site. Sites with large numbers of lanes and heavy traffic benefited the most with ‘smaller’ and less congested sites gaining less (though still very worthwhile generally). There were exceptions and it is difficult to generalise on the reasons for the small benefits where they occurred. Gauging how effective MOVA is likely to be at any one junction is difficult. For authorities installing several sites, the overall figure is meaningful as this is what would be expected when all the sites are considered. However, authorities trying MOVA for the first time, or having few suitable sites, would often like to be able to predict the benefits rather more accurately or would like to know which site(s) to convert first. With this in mind, TRL are intending to produce a modernised version of MOVANALYSIS that allows the comparison of MOVA against VA using the occupancy method (Young 1988). In time, more widespread use of this tool should lead to a better method of predicting the benefits of MOVA at specific junctions.

MCH1542 C Installation Guide for MOVA Design Considerations

September 2005 26

3. DESIGN CONSIDERATIONS

3.1 Introduction This chapter concentrates on the information required for the setting up of a

MOVA site at existing or new traffic signal junctions. The designer is encouraged to follow the design process as summarised in the following flow chart which shows the various stages that the designer will need to pass through. An approximation of the time needed for each stage is shown.

Using flows and turning movements consider and update physical layout and stages

Specify and Order equipment – for example:

• controller • UTC interface • Add-on MOVA

unit • Telephone line

Revise lane-lines arrows and other road markings Decide on detector • locations • sizes

Measure • cruise speeds • saturation flows • short lane lengths

etc. Consider: • parking • minor roads • sources/sinks • vehicle paths • number of lanes at detector

sites.

Review and Consider traffic usage of lanes. • Check rules for separate

links. Define link structure.

Specify and Implement civil engineering changes

1 2 3

4 – 8 hours

variable

4 – 8 hours

4 – 8 hours

~1 hour/lane

~4 hours

4 – 8 hours

4 – 8 hours

Key:

Compulsory Usually relevant

MOVA installation flowchart


September 2005 27

Y

N

Install equipment loops and ducts etc

Is MOVA operation

satisfactory?

MMOOVVAA iinnssttaallllaattiioonn ccoommpplleettee

N

Y

1 3 2

Commission site Install/download MOVA data

Use MOVA diagnostics to • check detector channels and polarities • stage and phase confirms & CRB • check operation of force bits • check basic operation is correct (including any

pedestrian requirements) • etc (see commissioning sheet)

Is commissioning complete?

Create MOVA data set(s)

Post commissioning validation Observe on street for satisfactory behaviour Use MOVA messages to check key points of

operation in peaks and off-peaks

Is junction structure

satisfactory?

Is problem fundmental?

Y

YN

N

Handover responsibility for site

Carefully make changes to relevant

MOVA data and download

4 – 8 hours

4 – 8 hours

MOVA installation flowchart (Continued)


September 2005 28

3.2 Design Process Site characteristics Before embarking on the design of a MOVA installation the site should be visited so that the conditions and behaviour of vehicles and pedestrians can be observed. In particular: • Watch traffic movements and lane

utilisation, the paths taken by vehicles. • Note where traffic queues form at

different times of day and where gaps are left, such as keep clear areas.

• Are there any multiple lane queuing situations where queuing is approximately even (or you want it to be even) across two or three lanes?

• Are there any side roads located close to the junction or small bays, filter lanes or flares used?

• Are there (or will there be) facilities provided for pedestrians and are they currently controlled?

• Are there any parked vehicles and any parking restrictions present, if so what impact will they have?

• Are there any bus stops (and do buses require any priority treatment)?

• Are there any private accesses close to the junction (after the X loop) which might require a stopline detector (note it would not be required on the revert stage approaches).

• Are there any other situations that might require a stopline detector.

Drawing Produce a schematic drawing of the site showing: • Links, Lanes, Detectors with associated

distances and numbering. • Staging arrangements diagram. • Link/Lane and Stage table. Site measurements The schematic drawing, should be used to clearly identify the different approaches and to note data as it is collected. To begin with,

the diagram should show the existing stage and phase diagram: A few key data items need to be measured on-street • Determine the 15th percentile cruise

speed (i.e. the speed that 85 percent of vehicles exceed) for each traffic lane on each approach. The TRL program ‘MOVASPEED’ is recommended for this.

• Determine the saturation flow of each lane. The use of the TRL program ‘SATFLOW’ is recommended, which will also produce the start up lost time.

• Measure and note the following • Direction markings • Destination markings • Lengths of bays or flares • Features around the expected

positions of the X and IN detectors which may affect their positioning

• Side road locations • The location of any other relevant

traffic behaviour, such as where queuing normally starts to form in two rows.

Lane and road markings • Review existing lane usage. • Can existing lane discipline be improved

by use of arrow markings? • Do lane markings need extending? • Do lane lines need re-painting? • Do direction arrows need revising? Stages and stage order • Use any existing traffic flow data that

may be available. • Review existing stages and their order. • Determine whether additional stages are

required. • Consider whether alternative stages can

be used, such as pedestrians with traffic or traffic only.

• Do right turning vehicles require control, and if so which option should be used?


September 2005 29

• Is this a ‘double-right-turn’ situation that could benefit from MOVA’s optional stage sequence optimisation?

• Is the junction likely to benefit from repeating the main-road green and if so would optimised single/double greening be appropriate?

Link/lane relationships • Decide which lanes are MOVA lanes or

bays. • Allocate a number to lanes. • Which lanes go in which links? Pedestrian links • Are there pedestrian links and will they

be separate or combined? • Determine detector locations and

numbers. Emergency/priority • Are facilities required for Priority or

Emergency vehicles and what links will they use?

Note: EP links are additional non-traffic links and normal traffic links cannot be specified as EP links. Traffic detector positions and functions • Determine which lanes are long lanes

(with both IN and X detectors) and which are short lanes (with just an X detector).

• Calculate distances for ‘X’ and ‘IN’ detectors from cruise speed data.

Note: Remember to add 5 metres to the calculated distance to account for vehicle length • Determine whether ‘SINK’, ‘COMBX’,

‘OUT’ or ‘STOPLINE’ detectors are required.

• Determine numbers for traffic detectors.

Controller configuration • Draw up configuration details for the

UTC interface (for ‘Add on’ facilities only) and Controller.

MOVA data set-up • Utilise the above information to prepare

MOVA data set using ‘MOVASETUP’. Update schematic drawing • Complete the schematic drawing with

information such as detector numbers and location (replacing anticipated distances with calculated ones once detector positions have been determined).

3.3 Site characteristics 3.3.1 Observations An important first step in the process the designer is involved with will be in visiting the site. Some preparation is useful. A schematic diagram can be used for making notes and a small scale site layout diagram is also invaluable when on site. A copy of the TR0141 or TR2210 forms will also be of assistance. Site visits should be made as often as necessary to observe both traffic and pedestrian behaviour and to collect the necessary data required for input to MOVA. The visits should take in various times of day to note differing behaviour, and may need to include weekends and/or evening periods. The designer should be aware of any existing facilities for pedestrians present at the junction, and how they are currently controlled. Undertaking a manual classified count at the junction can be helpful. More important is understanding where queues tend to develop at different times of day and how the traffic behaves during less busy times. Also be aware that behaviour may be modified as a result of poor signal timings or a controller fault.


September 2005 30

3.3.2 Road layout The layout of the junction is important and the designer needs to be aware of the different paths taken by vehicles moving through or about the junction, particularly in relation to differing turning movements. Also important is queuing behaviour in relation to lanes and if discharging traffic tends to leave noticeable gaps due to, for example, ‘KEEP CLEAR’ markings. The survey should include the lengths of any filter or flared lanes and the existence of any minor junctions located close to the main junction. A survey of existing road markings is required to identify the number of lanes and the length and form of the markings at the junction. It is normally assumed that existing hazard lane markings will need to be extended further back to where the position of the ‘IN’ detectors will be placed in order to ensure that vehicles will be guided over the loops. With MOVA control it is necessary that lane markings are used to guide traffic unambiguously into various lanes. In this way, vehicles detected at an ‘IN’ detector are subsequently assumed to pass mainly over particular ‘X’ detectors. Therefore existing road markings at the junction may need to be extended further away from the junction in order to achieve this. Therefore, lanes should contain clear lane arrow markings where this will encourage correct lane discipline, and will particularly assist with the placement of MOVA loops. Account will need to be taken of how vehicles divide into lanes both in congested and uncongested conditions. Substandard (narrow) lanes may help encourage separate queues to form in congested conditions, but lane-straddling may occur in uncongested conditions if this is taken too far. 3.3.3 Parked vehicles Consideration should be given to parking/loading regulations between the ‘IN’ loop and stopline. Parking is likely to vary by time-of-day and day-of-week and it may be necessary to have different MOVA

configuration data to suit different parking characteristics. If there is an opportunity to modify parking by further restrictions, try to arrange it so that the X-detectors at least are unaffected by parking in peak periods to ensure good saturation flow with greens extended appropriately. If, however this cannot be achieved, careful consideration should be given to where loops would be located, both in relation to the stopline and their position across the carriageway. 3.3.4 Existing traffic signal junction Where the junction being converted to MOVA is already being controlled by traffic signals, all existing duct and loop positions together with Controller details such as the staging and phasing arrangements should be confirmed. 3.4 Site Measurements 3.4.1 Cruise speed definition A key parameter to be determined by the designer is the ‘cruise speed’ for each approach lane. This speed is the 15th

percentile of free flow speed distribution (i.e. the speed below which 15 percent of non-queuing vehicles travel). The reason for choosing a low percentile speed is so that MOVA cautiously assumes approaching vehicles are present for slightly longer than is actually the case for most vehicles: only the slowest vehicles will take longer than assumed to reach the stopline. 3.4.2 Method of measuring the cruise

speed The cruise speed refers to vehicles travelling between the ‘IN’ detector (or, if none, the ‘X’ detector) and the stopline. This is measured during the time period after saturation flow at the stopline is judged to have ended, but before the relevant traffic signal green ends – this is the period when MOVA is optimising for stops and delays for the whole junction. For major roads, carrying substantial flows, where it would be reasonable for the green to continue 20 or 30 seconds after the initial queue has cleared, speeds can be measured throughout this period. For low flow minor approaches, where delay optimisation is unlikely to extend the green by more than a


September 2005 31

few seconds after the initial queue has cleared, then the speed measurements should be concentrated in the period when the queue has just cleared. It is important to ensure, therefore, that speeds are measured only during these periods. In some cases it may be useful to switch the signals to fixed time control during the measurements, to help ensure that there will be periods during the green signal when traffic will be flowing freely. Ideally the average speed over the whole distance from the ‘IN’ detector to the stopline should be measured. As noted previously speeds are normally measured over a central stretch of between 30 and 50 metres in length. Note: The use of a radar gun is not recommended in the measurement of speeds as it will provide spot speeds only, which are themselves severely modified by the presence of someone using such a device! Use of the program MOVASPEED is recommended. Measurement of cruise speeds takes patience but it is essential to do it as well as possible, especially at higher speeds sites. Ideally, vehicles should be selected for measurement by a random process so that the resultant average speed reflects the mix of traffic in the particular lane. The off peak periods are the most appropriate times for making the measurements both because there will be more non-queuing vehicles and because MOVA uses the cruise speeds values mainly at uncongested times. The number of vehicles that you need to measure will depend on the variability of speeds, but it is likely to at least 20 vehicles per lane and possibly as many as 50.. TRL’s ‘MOVASPEED’ program advises the user when sufficient measurements have been made.

3.4.3 The ‘MOVASPEED’ program The program ‘MOVASPEED’ has been produced by TRL and is now available on Personal Data Assistant (PDA) devices such as the Palm series of machines. It operates on the simple principle of the user timing vehicles over a pre-measured length of road. The program has advantages over a stop watch in that it displays the speed of

individual vehicles directly, and also performs various statistical calculations which can be printed out. The latest version indicates when acceptable statistical significance has been reached, and further unnecessary measurements can be avoided.

Before measurements can commence, information about the approach needs to be entered. It is important to do this otherwise, back at the office, it can be difficult to know which results apply to which approach and which lane. The user must then enter the distance (in metres) over which vehicles are to be timed. Changes in surface or markings on the road are useful for delineating the area to be measured. It is however not advisable to use street furniture, such as lamp posts, as this could result in significant parallax errors. The best place to measure cruise speeds is around the X-detector as there is lower variability than there is nearer the IN-detector.

For the program and examples of the input and output data see AG 45 ‘Traffic Control manual’ Appendix D – ‘Guide to Measuring Cruise Speeds’. 3.4.4 Saturation flow

At the start of green, traffic starts to discharge over the stopline. After a short initial period, the discharge becomes steady and this is the saturation flow rate. The initial period, known normally as either the start-up lost-time (which is where STLOST in MOVA comes from) or start displacement would often be between 1 and 3 seconds. Saturation flow continues until the last stationary vehicle in the queue crosses the stopline and is usually expressed in vehicles per hour or PCUs per hour. If there are still stationary vehicles at the end of green, the green is said to be fully saturated. In MOVA, saturation flow is measured as vehicles/hour (not PCUs) and is converted to an average headway time (3600/saturation flow) known in MOVA as SATINC. Ideally, saturation flow should be measured for each lane as the value can be quite variable across lanes, even if it is consistent for any one given lane. It may even vary by time of day. Saturation flow can be measured using TRL’s ‘SATFLOW’


September 2005 32

computer program also now available for PDA devices. A well saturated lane will normally need about 30 minutes worth of recording to obtain acceptable statistical significance in the results. Saturation flow can also be estimated using TRL Research Report 67 ‘The prediction of saturation flows for road junctions controlled by traffic signals’ 1986, when direct measurement is not possible e.g. lanes with insufficient traffic to form worthwhile queues. In future versions of MOVA an automated method for measuring saturation flow will be available. This will remove the likelihood of human error when collecting data. In addition there will be no requirement to recalibrate if conditions at the junction change in the future. 3.5 Stages and stage order 3.5.1 General With existing traffic signal junctions the number of stages and stage order will have already been identified. The opportunity should be taken to review the existing order, particularly to overcome the deficiency in older Controllers, which could not end a phase without closing the stage and therefore had additional stages to accommodate demand dependant pedestrian phases. Once again the designer should take the opportunity to review the stage composition and stage sequence with the considerations being fundamentally the same as those for signal control by traditional gap seeking strategies. Usually stage 1 will be the most frequently called stage and will often be the reversionary stage as well. There may well be a number of stages that are called sequentially, one after the other, and a stage will be omitted only if there is no traffic requiring that stage. In other cases, however, further conditions may be applied to the stage demands so that stages may be omitted for other reasons. For MOVA the user must specify a ‘master’ sequence of stages which includes all possible stages which might occur in the cycle, allowing for a maximum of 10 stages (8 with version M4 and before). MOVA allows for conditional demands for some stages. At complex junctions conditions can

be applied to all stage demands. In practice, if more than just a few conditional demands are included, this makes it difficult to predict the future stage sequence and to optimise green times. Note: It is recommended to minimise the use of conditional stages. 3.5.2 Alternative stages Double greening It is possible to repeat a stage within a cycle (known as double-greening) provided the stage is given two different numbers. Thus, to achieve a sequence A-B-A-C it is necessary to set up MOVA as a 4 stage junction where stages 1 and 3 in the order 1,2,3,4 both refer to the same traffic stage on the road. This can be a very effective solution in some situations, but possibly at the expense of a longer cycle time (which may disadvantage pedestrians). MOVA M5 has the ability to automatically choose whether to use single or double greens at a junction based on the balance of traffic demand. However, TRL should be consulted before this is used. Time of day stage-sequence variations Similarly, time of day variations in stage sequence such as ACD and ABD would use the same 4 stage ‘master’ sequence from which (in this case) stages 2 and 3 would be included/omitted as required. Note: In all cases where alternative stage sequences are to be used:

a) All the stages must be included in all the data sets;

b) stage 1 must be included and regularly called as it is needs to run for a 'time of day' plan change to occur.

c) The controller configuration must permit any stage to run at any time of day, to avoid problems near plan change times caused by slight differences in the controller’s and MOVA’s clocks.

3.5.3 Right turning early cut-off situations


September 2005 33

The designer needs to determine whether right turning traffic will need to be controlled and, if so, what method to use. The control of right turning traffic has already been discussed in 2.6.1. 3.6 Link/Lane relationships 3.6.1 General Definitions of what constitutes lanes and links has been dealt with in Section 2.2 ‘MOVA fundamentals’ and the designer should be conversant with the principles laid down in that section. Once long and short lanes have been determined links can be defined also; a traffic link will consist of one, two or three lanes. 3.6.2 Traffic links A link will consist of a single lane, unless traffic in two or three lanes forms a common queue. Such a situation exists if the lanes discharge in a similar way during the same green period, and directional arrow road markings do not prevent traffic in the lanes from forming equal length queues. Consider each of the common traffic movements at a normal junction where the roads intersect at right angles. The following definitions are used for each traffic movement: LT – left turners, SA – straight ahead, RT – unopposed right turn, RT(opp) opposed right turners. 3.6.3 Single movement lanes If 2 or 3 lanes cater for the same single movement and are equally usable, they comprise a single link, as noted in the examples given below: LT LT = 2 lane link SA SA SA = 3 lane link RT RT = 2 lane link If one of the movements on a lane is a right turn opposed movement, RT (opp) then that lane will usually be a single lane link. This is because the straight ahead movement may be held back by the opposed right turner waiting for gaps in the opposing priority

stream, and cannot discharge freely during a green. (SA + RTopp) = 1 lane link The designer should take care in assessing the use of lanes. In some cases they may appear equally useable but drivers may prefer a certain lane or avoid a lane because of poor alignment or problems downstream. If so, a multi lane link may not be appropriate. 3.6.4 Mixed use lanes It is common for traffic making different movements to share a lane. Examples of sharing are (LT+SA), or (SA+RT), or even (LT+RT) at a T junction. As can be seen in the following examples a mixed lane can form part of a multi lane link, provided that one movement can use any lane and tend to equalise the queues. Thus, the following are possible lane groups forming a single link: (LT+SA) SA SA = 3 lane link (LT+SA) (SA+RT) = 2 lane link (LT+RT) RT = 2 lane link 3.6.5 Allocating a number to each lane

and link Once the lanes and links have been determined the designer should then allocate a number to each of these. There is no rigid system for numbering of lanes and links. However, the designer should ensure that the information is recorded on the drawing as shown in Figures 2.3, 2.6 and the other examples contained at the rear of this chapter. A logical sequence is best with a link to the phase order often being useful – it helps in setting up commissioning, when a disorganised or illogical system can easily confuse and lead to errors. 3.7 Pedestrian/Priority links 3.7.1 Pedestrian links The designer needs to identify whether pedestrian links will be required. If pedestrians will receive a green man signal automatically, as part of a vehicle stage, without the need for the use of push-buttons, then it is not necessary to represent pedestrian phases as links in MOVA.


September 2005 34

Note: Users should check the information in this section with their suppliers, as there are differences in the manufacturers’ MOVA implementations in this area. Pedestrians phases that are operated by a push-button, to demand a green man must, however, be represented in MOVA by a pedestrian link. This is necessary solely to allow the pedestrian detectors to demand a fixed time green period for the pedestrians. At the time of writing, no optimisation of the green-man invitation period is possible. 3.7.2 ‘PUFFIN’ type pedestrian facilities In traditional pedestrian situations, where the push of a pedestrian button latches a demand for a pedestrian phase, any other pedestrian phases that run in the same stage(s) should be combined as a single link with a single detector. As many push-buttons as necessary can be commoned up to form a single pedestrian detector. Pedestrian movements that run in different stages to each other should have their own separate links and detectors. MOVA version M4 and later have the capability of dealing with PUFFIN type situations, both at the true PUFFIN mid-block type crossing, and other situations known colloquially as PUFFIN facilities, where some or all the PUFFIN features are adopted at junction pedestrian phases. Two points need to be considered. Firstly, if there are on-crossing detectors, the pedestrian phase can be extended outside MOVA’s direct control. MOVA can tolerate a difference between the minimum and the maximum stage length of 30 seconds which is likely to be sufficient in the majority of cases. Secondly, if kerbside detectors are used to verify, and cancel when necessary, the pedestrian demand, it is necessary to use the unlatched pedestrian demand option in MOVA. There is more than one way of doing this and the options are even greater when MOVA M5 is included. Ignoring MOVA for a moment, a ‘PUFFIN’ phase is demanded by a pedestrian having pushed the button and also being detected by the kerbside detector which is used to

confirm the demand. If the pedestrian crosses before the phase runs, the demand is removed. The controller takes care of the confirming and cancelling of demands. In MOVA M4 and later, an unlatched pedestrian demand facility is available. In version M4, what is needed for MOVA to demand a pedestrian phase is for the detector number specified for the pedestrian link to be ‘on’ and for channel 24 also to be ‘on’.

In MOVA M4 This can be achieved in two ways: either

a) Connect the kerbside detector(s) to the pedestrian channel and the wait signal to channel 24; or

b) Connect the wait signal to the required pedestrian detector channel and channel 24 wired permanently ‘on’.

Method (b) has to be used whenever there is more than one unlatched pedestrian phase.

For single PUFFIN crossings, it is possible to specify a pedestrian time-weighting factor whereby the disbenefit to pedestrians waiting to cross is included in MOVA stops and delay optimisation. To achieve this, use method (a) above with the detectors from each side connected to different channels. This way the weighting is doubled when there are demands on both sides of the crossing. Note that the time weighting feature does not work where there are more than two stages. In MOVA M5 either method will be applicable, but this time the restriction on using channel 24 will be removed. Instead it will be possible to specify a confirm channel for each pedestrian link and more than one pedestrian link will be able to share the same confirm. This will allow the time weighting-feature to be used, which now will work correctly over a complete cycle regardless of the number of stages, and therefore will enable pedestrian delay to be included in the delay optimisation at junctions. If the confirming channel is not required, it will be possible to simply connect the wait-light signal that has already been processed in the controller without the need for any extra confirm channels.


September 2005 35

Note: When the wait signal is used to confirm demands, it is important to make sure that both MOVA and the controller see the same pedestrian demands in order to avoid MOVA cancelling a demand that the controller thinks is still present. 3.7.3 Priority or emergency vehicles Facilities for priority and emergency vehicles have previously been discussed in Section 2.8. The designer needs to determine whether facilities are required for Priority or Emergency vehicles. Firstly, consider the possibility that the improved junction operation afforded by MOVA may eliminate the need for any vehicles to have priority in the first place. If Priority or Emergency action is still required, identify each lane that the vehicles will be using and then decide where to locate special ‘selective vehicle detectors’ (SVDs) to demand, extend and cancel the facility (SVDs can be any type, including AVL where this is in use). Further details on the siting and positioning of Priority and Emergency detectors are given in AG 44, Appendix C. 3.8 Traffic detector positions and

functions 3.8.1 Determine which lanes are long

and short lanes The designer should have determined in Section 3.6 the various lanes and links that will be used in the design. All of which will be either long or short lanes depending on whether or not they are long enough to have an 'IN' detector. 3.8.2 X-detector loops The loops, one per lane, should ideally be positioned at 3.5 seconds journey time plus 5 metres from the stopline (based on the measured cruise speeds). The extra 5 metres is added to allow for the fact that there should be 3.5 seconds between the rear of a vehicle leaving the detector (when the detector will cease to detect) and the front of a vehicle crossing the stopline (when no more effective-

green time is required for the vehicle). No allowance needs to be made for the fact that some drivers continue during the first one or two seconds of amber, since this is taken into account by the MOVA logic. Therefore, DX = (3.5 * CRUISESPEED)+5 DX (the distance from X-detector to stopline) is shown diagrammatically in Figure 3.1. The above formula need not be applied rigidly, and compromises may be needed for one or more of the following reasons:

i) At the highest speeds, there may need to be upper limits on the DX distances. The greater the number of vehicles which can queue down-stream of the X-detector, the greater will be the potential error in calculating the minimum green time required to discharge those vehicles: At urban sites, where the traffic discharge during green is liable to be disrupted by sporadic events, a sensible maximum DX distance is 45 metres from the stopline. At "clean" non-urban sites, the normal limit is 55 metres from the stopline. Exceptionally, if the junction approach in question is such that the calculation of the minimum green time is less critical than the need to deal safely with high speed vehicles, then the DX distance can be up to 65 metres.

ii) The loops should normally be alongside one another so that straddling vehicles are detected by one, and only one, loop (where traffic streams are sufficiently segregated the rule can be relaxed a little, if necessary). As the speeds are likely to be different in adjacent lanes, it follows that the DX position cannot be ideal for every lane. However, it is recommended that no X-detector should ever be more than 4.0 seconds cruise time from the stopline.

iii) To position the loops downstream of a significant traffic source or sink (such as a busy side road), a balance has to be drawn between the relative size of the source/sink, and the compromise on the DX distance.


September 2005 36

At junctions with sharply flared approaches, it may be that there are more lanes at the stopline than there are at the X-detector location. However, this is not a good reason for moving the X-detectors closer to the junction, unless the move is marginal, e.g. changing DX by less than 15 percent. Normally, it is better to position the X detectors in their correct speed-related positions, and install an "X-sink" detector in

any additional short "bays" downstream of the DX point. In MOVA, a bay is not treated as a lane in its own right, and its sole function is to accommodate an X-sink detector to count vehicles leaving the main lane alongside it. For details of sink detectors, see Section 3.8.5.

Figure 3.1 Speed - related X and IN detector distances.

“OUT” detector immediately upstream of stopline

D X

D IN

Stopline to X-detector distance

Stopline to IN-detector distance


September 2005 37

3.8.3 IN-detector loops IN-detectors, one per long lane, should ideally be positioned at 8.0 seconds journey time from the stopline (based on the measured cruise speeds). As with the X-detectors, an extra 5 metres is added to allow for the length of an "average vehicle". Therefore, DIN = (8.0* CRUISESPEED) + 5 DIN (the distance from IN-detector to stopline) is shown diagrammatically in Figure 3.1. As with the X-detectors, this ideal distance sometimes has to be a compromise. When compromising, a range of 7.5 to 10.0 seconds cruise time should be aimed for. However, please note that a cruise time of 10.0 seconds is the absolute upper limit, which may never be exceeded. Reasons for compromising the ideal 8.0 seconds cruise time include the following: i) To keep the IN-detector loops

alongside one another (when one lane has a noticeably different cruise speed than the other) which minimises the counting problems caused by straddling vehicles;

ii) To position the loops downstream of

a major source or sink of traffic. Such as a side road contributing at least 20 percent of the traffic arriving at the stopline, or sinking at least 20 percent of traffic before reaching the stopline;

iii) To position the loop(s) upstream of

the neck of a flare, such that there are more lanes at the X-detector point than there are at the IN-detector point (see Figure 3.2). This means that the flaring effects will be taken into account within the MOVA model, enabling it to operate shorter signal cycles when there is sufficient use of the extra flared area to warrant it.


September 2005 38

Figure 3.2 Junction showing various MOVA loops.

OUT detector

X - detector ANDIN - sink detector(combined role)

X - sink detectors

X - detectors

IN - detector

X - detector

1

3

2


September 2005 39

3.8.4 "OUT" detector loops OUT detector loops record the presence of right-turning vehicles at the stopline, and count them out as they proceed over the stopline. They are used only to control right-turners in early cut-off (ECO) situations, where such vehicles can receive two (or more) green stages: First stage in which right-turners are

opposed by conflicting traffic Next stage ECO, in which right-turners

can turn freely (usually, a green arrow is shown)

The OUT detector is used to decide:

i) Should the Next Stage, in which right turns have priority, be demanded?

ii) If Next Stage runs, how long

should its variable minimum be?

(The answer to both questions may change every half second). An OUT-detector is not needed in lanes where right-turners are fully controlled and are never opposed by other traffic. (However, it is recommended that such lanes should have a "stopline demand detector" - see Section 3.8.6). There are two distinct uses for OUT detectors: With a dedicated RT lane or bay In the early cut-off situation described above, right turners usually have one or more dedicated lanes. In such situations, there should be a separate OUT detector for each of the right turn lanes, positioned immediately upstream of the stopline, and as close as possible to it (see Figure 3.2 and 4.4 for greater detail). The detector is located where it is because it is assumed that vehicle(s) waiting downstream of the stopline will complete their manoeuvre during the intergreen. Note: OUT detectors must count as accurately as X and IN detectors, so, unlike

stopline demand detectors the detector should be set to medium sensitivity. Vehicles are counted out as they cross the stopline (after being counted in by the X-detector) and, once counted out, a right-turner will not demand or extend the dedicated right-turn stage. An alternative is to call the ECO stage only when there is queuing on the X-detector. This can be useful, for example, where the RT occasionally causes problems and needs to be dealt with when they do, but, on average, do not require an ECO stage and to call it would be too detrimental to other traffic. To achieve this, MIXOUT has to be set to 99. Single lane with mixed RT and straight-on traffic – call cancel facility An early-cut off sequence is sometime used on single-lane approaches, with mixed straight-ahead plus right-turning traffic. In such situations, the OUT detector uses occupancy time to decide whether to demand the ECO, Stage N+1. If or when the mixed stream becomes blocked due to the opposed right turners, the detector will be occupied for longer than if traffic was free flowing. In MOVA, the early cut-off stage will be demanded if the detector is on (in Stage N) for 5 seconds. Subsequently, the demand can be cancelled if the detector is off for 3 seconds. To activate this call/cancel feature, the value of MIXOUT has to be set to ‘–99’. In such situations, the OUT detector should be positioned so as to give early warning of a traffic stream being blocked by opposed right-turners, immediately upstream or downstream of the stopline (see Figure 4.4). It should not be positioned so far downstream as to be crossed by vehicles from other approaches. The advantage of positioning the loop upstream of the stopline is that vehicles can be detected during the red period, and (with the detector also specified as a stopline detector) a demand registered in the event of failure of other detectors. The loop does not have to be the normal MOVA diamond shape to perform this function.


September 2005 40

3.8.5 Sink detector loops A sink detector loop should be installed in situations where traffic crosses an IN-detector, or an X-detector, then leaves "the system". Usually this means that vehicles do not arrive at the stopline. (The loops are referred to as IN-sink detectors and X-sink detectors respectively). The reason for not crossing the stopline is almost invariably because vehicles use a filter lane that does not have a stopline (though may have a give-way line). Only in very exceptional cases should a sink detector be used to count vehicles turning into a side turning, because it is usually impossible to position them such that they will not count spurious vehicles. Uni-directional detectors may be an option, but RTs into the side turning could be counted spuriously. In certain special cases an approach may flare out close to the stopline, such that there are more queues at the stopline than at the X-detector point. In such cases, an X-sink detector should be installed in the bay to count vehicles leaving the main lane. The main lane is the one carrying the greater amount of traffic, and the associated bay carries the lesser amount of traffic. Although sink vehicles arrive at the stopline, they have left the system in the sense that they do not require extra green time. See Figure 3.2 for an example of an X-sink detector in a short bay. In all cases, sink detectors are positioned as far upstream as possible, consistent with reliable counting, to give MOVA as much notice as possible that a vehicle has departed from a MOVA lane. 3.8.6 Stopline demand detector loops The function of these detector loops is simply to register the presence of a demand. They do not need to count accurately. As such, they perform best when their sensitivity is set to maximum. The loop shape and dimensions are designed to detect bicycles in addition to other vehicles. They should be positioned just upstream of the stopline. They may span more than one lane, providing that vehicles in all lanes demand the same stage. An overhead infra-red detector may be used instead of a buried loop, if required. Any type of detector capable of registering the

presence of stationary vehicles (including bicycles) and whose detection zone can be satisfactorily controlled may be used. Stopline demand detectors should always be considered on approaches which are not in the revert stage and must be installed where vehicles may become trapped due to: (i) Arriving downstream of the X-

detectors (e.g. private dwellings with an access between the 'X' loop and the stopline, or an exit from a car park);

(ii) Slowing down more than usual after

crossing the X-detectors, for example where a turn is involved, such that it has left MOVA’s model but in reality it is still present and needs green again. For this reason, it is strongly recommended that a stopline demand detector is used in right-turn lanes where the right turning traffic has its own dedicated stage.

(iii) Swapping lanes after crossing the X-

detector, for example from a straight-ahead lane to a right-turn lane that is catered for in a different stage.

If there is enough other traffic to demand the stage required by the trapped vehicle, before it has to wait too long, there is less need for a stopline demand detector. It is not usually necessary to equip all lanes. 3.8.7 Determine numbers for traffic

detectors The information provided below acts a guide for the designer to use as there are different ways of numbering detectors. The designer should however always ensure that, whatever numbering system is adopted, it should be clearly marked on drawings for others to follow. The guiding principle in the numbering of detectors is to use a system which makes it easy to remember where detectors are, and what purpose they serve. For smaller sites, with less than 10 lanes, one suggestion is that ‘X’ detectors are numbered from 1 to 10, corresponding to the lane number in which they are situated. The ‘IN’ detectors are then numbered by adding 10 to the lane


September 2005 41

number (e.g. Detector 14 would relate to an ‘IN’ detector in lane 4). OUT detectors and stopline demand detectors can be given appropriate numbers in the range 21 – 30. For sites with more than 10 lanes, a suitable alternative numbering system must be used. It is suggested, however, that the ‘X’ detectors should still correspond to the lane numbering system identified above. Another system is also commonly used whereby numbers start at 1 and are numbered in ascending order by phase, so that for instance if phase A is a two lane approach, the IN detectors are 1 and 2 and, the X detectors are 3 and 4 (hence they will be in the same pack). This has found favour because the resulting physical location of channels in detector packs reduces the chances of cross-talk. 3.9 Drawing The designer has now passed through the various design processes. The information obtained previously now needs to be presented, in the form of a drawing, so that it can easily be understood by others, in checking and implementing the work, and in later maintenance operations. The drawing should clearly indicate the following information: • Numbered Lanes

• Links (generally shown as table with associated lanes)

• Detectors with associated distances and numbering

• Staging arrangements diagram

• Lane movement arrows

Previous Figures 2.3 and 2.6 indicate the general type of layout diagram used. However, the designer is not restricted to using this concise layout and is encouraged to examine other ways of improving the information, such as adding detector schedules and stage intergreen tables. Additional examples of drawings and associated coding sheets of working sites are contained in Section 3.13, which will be both helpful and instructive.

3.10 Communications 3.10.1 Controllers There are three different types of MOVA equipment available known as follows: • Add-on where stage and phase

information is exchanged between the MOVA unit and the signal controller via a UTC interface – all detector signals are fed directly into MOVA; for detailed information about the UTC interface and configuring the Controller see Section 4.4.

• Semi-integral where there is a dedicated serial link between the signal controller and the MOVA unit – all the information is exchanged via the serial link including detector information which is fed into the MOVA unit from the controller;

• Integral where the MOVA functionality is included within the controller.

For information about the latest developments please consult the signal manufacturers.

3.10.2 PSTN connection At most existing traffic signal installations a PSTN connection will already exist. This can be utilised for use with the MOVA equipment. This will allow the MOVA unit to be remotely monitored. With some manufacturers’ equipment the Controller can also be monitored from the same phone line. It also allows MOVA to “phone home” in the event of a wide range of fault conditions. 3.10.3 Communications with MOVA There are a number of software packages available for two-way communications between the user and MOVA. This can be undertaken either at the site or remotely via the telephone line. All traffic signal companies providing the equipment will have their own software package, which will generally be provided free of charge to the designer, as part of the overall equipment package. Whilst the front ends of each software package may look different, they are generally based upon the


September 2005 42

TRL MOVACOMMS program and are, essentially, terminal emulation programs with extra features specifically for use with MOVA.

When the order for the equipment is placed it should include provision of all necessary software, and the appropriate manuals.

3.11 MOVA Design Process For Traffic Signal Junctions STAGE DESIGN PROCESS Check

SITE CHARACTERISTICS • Obtain and peruse the site layout diagrams and TR2210 controller

specification forms

• Visit site and observe conditions and behaviour of vehicles and pedestrians.

• Watch traffic movements and the paths taken by vehicles

• Note where traffic queues form at different times of day and where gaps are left, such as keep clear areas.

• Is there multiple lane queuing?

• Are there any side roads located close to the junction or small bays, filter lanes or flares used?

• Are there any facilities provided for pedestrians and are they currently controlled?

• Are there any parked vehicles and any parking restrictions present?

2 SITE MEASUREMENTS • Determine the cruise speed for each traffic lane on each approach

using ‘MOVASPEED’.

• Determine the saturation flow of each lane, using ‘SATFLOW’, which will also produce the start up lost time.

3 LANE AND ROAD MARKINGS • Review existing lane usage • Can existing lane discipline be improved by use of arrow markings?

• Do lane markings need extending?

4 STAGES AND STAGE ORDER • Use any existing traffic flow data that may be available

• Review existing stages and their order

• Determine whether additional stages are required • Consider the use of alternative stages, such as pedestrians with

traffic or traffic only.

• Do right turning vehicles require control, and if so which option should be used

5 LINK/LANE RELATIONSHIPS • Decide which lanes are MOVA lanes • Allocate a number to them

• Which lanes go in which links?


September 2005 43

STAGE DESIGN PROCESS Check6 PEDESTRIAN/PRIORITY LINKS

• Are there pedestrian links and will they be separate or combined?

• Are facilities required for Priority or Emergency vehicles and what links will they use?

• Determine pedestrian and/or priority detector locations and numbers

7 TRAFFIC DETECTOR POSITIONS AND FUNCTIONS • Determine which lanes are long or short lanes

• Calculate distances for ‘X’ and ‘IN’ detectors from cruise speed data.

• Determine whether ‘SINK’, ‘COMBX’, ‘OUT’ or ‘STOPLINE’ detectors are required

Determine numbers for traffic detectors.

8 DRAWING • Prepare schematic drawing showing: • Links, Lanes Detectors with associated distances and numbering

• Staging arrangements diagram

• Link/Lane and Stage table

9 COMMUNICATIONS • Provide UTC interface (for ‘Add on’ facilities only) and Controller

Configuration • Provide telephone line to MOVA

10 CREATE DATASET • Utilise the above information to prepare MOVA data set using

‘MOVASETUP’


September 2005 44

3.11 Dataset preparation (MOVA- SETUP)

3.12.1 General The data set-up program allows the designer to create a new MOVA data set, or to edit and change an old one. The program simplifies creation of the data set by giving a brief description of the required input for each data type, and offers the user default values where appropriate.

For MOVA M5 the program will have two modes of operation:

(1) CREATE - Creating a data set

producing files with ‘Dx’ and ‘PRx’ extensions where x = T, 1, 2, 3 or 4.

(2) AMEND - Amending existing data files with ‘Dx’ and ‘PRx’ extensions.

A third option was also available for MOVA version M4 and before, the data had to be ‘processed’ before it could be downloaded into MOVA RAM (version M5 will use the Dx file directly).

(3) PROCESS – Preparation of data file with a 'Px' extension for transferring into MOVA RAM area.

3.12.2 Overview of the data set-up

process In CREATE mode the program runs through all the data categories, providing default values for many entries. The user is advised to work carefully through the full data set in one session. Terminating the session, before all data has been entered, will require the rest of the data to be entered in AMEND mode. The user should then check through the data to see if there are any errors.

Before using MOVASETUP the designer is encouraged to use the coding form to manually pass through each section of the sheet. Enter the junction, stage, link, detector and lane data using guidance from the TRL Application Guide AG 45 – ‘Guide to MOVA Data Set-up and Use’, information collected on site, traffic signal calculations and other factors. Figure 3.3 (see pages 46-49) is provided as additional information to the TRL Application

Guides. It shows the designer a number of very simple junction layouts indicating how links between the method of control and the coding of LGREEN, LPHASE and SDCODE can be made. A number of examples of working sites, with coding sheets, are provided in the next section to assist the designer in this process.


September 2005 45

Link between LGREEN, LPHASE and SDCODE Figure 3.3 shows five simple examples of how the LGREEN, LPHASE and SDCODEs can look for some straightforward situations. Note that there is often more than one way of specifying the SDCODEs. Abbreviated definitions of LGREEN, LPHASE and SDCODEs are presented below: LGREEN

0 if this link is red during this stage 1 if this link has its only green in this

stage 2 if this link has green in more than

one stage 3 if this link is shown a RTIA in this

stage 4 if this link is a right turn link

opposed in this stage, but receives an RTIA in a subsequent stage

LPHASE

Note: LPHASE not required in some MOVA implementations – check with your MOVA supplier. For links which have green across intergreens (links which "overlap" an interstage) First link which overlaps an intergreen has an LPHASE of the last stage number +1. Second link which has an overlap has an LPHASE of last stage number +2 etc

In the UTC interface, phase reply bits start after the stage green confirmation bits. Enter phases which overlap as the same number bit as the LPHASE entry.

SDCODE

The matrix has an entry in each cell which has an entry in the LGREEN matrix:

• All 0 and 1 entries in LGREEN matrix

are replicated in the SDCODES matrix (automatically by the MOVASETUP program).

• Only need to prepare an SDCODE

for LGREEN cells with a code of 2 or above.

• When LGREEN is 2 for a non-right turn link there are a number of issues to consider. In the simplest case, decide which stage the link should call in the absence of any other traffic; for instance, where ahead links are adjacent to a right turn link and have green in two stages. Normally such links would call only the main road two-way stage unless there is a demand for the adjacent right turn and no demand for the opposite approach. In that stage SDCODE enter "1x" “x” being the stage catering for the right turners. In the other stage a "0".

• Where LGREEN is 3 or 4, right turn

indicative arrow links, enter SDCODEs "1x" and "2y" as follows:

In the cell with LGREEN 4, code "1x" where x is the following stage in which the RTIA appears, In the cell with LGREEN 3, code "2y" where y is the previous full green ahead stage in which this link is opposed.


September 2005 46

Figure 3.3 Examples of LGREEN, SDCODE and LPHASE use Simple T junction LGREEN Links 1 2 3 Stages 1 1 1 0 2 0 0 1 1 = Link is green in stage, 0 = link is red in stage SDCODE Links 1 2 3 Stages 1 1 1 0 2 0 0 1 1 = Link demands stage unconditionally, 0 = link does not demand stage Simple cross roads LGREEN Links 1 2 3 4 Stages 1 1 0 1 0 2 0 1 0 1 1 = Link is green in stage, 0 = link is red in stage SDCODE Links 1 2 3 4 Stages 1 1 0 1 0 2 0 1 0 1 1 = Link demands stage unconditionally, 0 = link does not demand stage

2 1Lk 1 Lk 2

Lk 3

2 1

Lk 1

Lk 2

Lk 3

Lk 4


September 2005 47

Full green right turn LGREEN Links 1 2 3 4 1 2 0 1 0 Stages 2 2 1 0 0 3 0 0 0 1 1 = Link is green in stage, 2 = Link runs in this and at least one other stage, 0 = link is red in stage. LPHASE 4* 0 0 0 * since link has overlap between S1 and S2, ‘4’ is first available channel after last stage confirm channel. SDCODE Links 1 2 3 4 1 12 0 1 0 Stages 2 0 1 0 0 3 0 0 0 1

Lk 3

Lk 4

Lk 2 Lk 1

1 2 3


September 2005 48

Early Cut Off to benefit link 2 LGREEN Links 1 2 3 4 1 2 4 1 0 Stages 2 2 3 0 0 3 0 0 0 1 1 = Link is green in stage, 2 = Link runs in this and at least one other stage, 0 = link is red in stage. LPHASE 4* 0 0 0 * since link has overlap between S1 and S2, ‘4’ is first available channel after last stage confirm channel. SDCODE Links 1 2 3 4 1 1* 1** 1 0 Stages 2 0 21 0 0 3 0 0 0 1 * ‘12’ if change from stage 3 straight to stage 2 was permitted ** ‘0’ if change from stage 3 straight to stage 2 was permitted

Lk 3

Lk 4

Lk 2 Lk 1

1 2 3


September 2005 49

Signalled left filter LGREEN Links 1 2 3 4 5 1 2 0 1 2 0 Stages 2 2 1 0 0 0 3 0 0 0 2 1 1 = Link is green in stage, 2 = Link runs in this and at least one other stage, 0 = link is red in stage. LPHASE 4 0 0 5 0 Overlaps for links 1 and 4. ‘4’ for link 1(S1 and S2) and ‘5’ for link 4 (full green in S1 and filter in S3) SDCODE Links 1 2 3 4 5 1 12 0 1 13** 0 Stages 2 0 1 0 0 0 3 0 0 0 0* 1 *does not demand S3 ever, S3 only runs for demands from link 5. ** link demands S1 (giving green to links 1,3, 4) unless S3 already demanded by link 5 See other examples in AG 45

Lk 3Lk 2 Lk 1

Lk 4

Lk 5

1 2 3


September 2005

50

3.13 Example Sites Examples of a number of working sites are provided in this section. 3.13.1 Example Site 1

The first example shows the designer a standard junction with four approaches. This particular example uses repeated main road greens in stages 1 and 3 and the designer is directed to the SDCODES used for these twin stages.

1

2 12

11

19

Lane 9

89

18

Lane 8

Lane 4 4

3 13

14

5 6 7

15 16

90m

35m

42m 115m

40m

83m

2

4 3

1

43m 120m

Link Movements on Link

1 2 3 4 5

Lanes 1&2 Lanes 3&4 Lane 5 Lanes 6&7 Lanes 8&9

Lane 3

Lane 1

Lane 2

Lane 6

Lane 7

Stages:

10 20

Example site 1

Lane 5


September 2005

51

MOVA DATA - Example Site 1 MOVA DATA MCH Ex 1.DT 15:45 19/12/2002 ------------------------------------------------------JUNCTION DATA-------------------------------------------------------------- STAGES NLANES NLINKS MAINST TOTALG 4 9 5 0 100 (seconds) OPTYPE DETON STAGON PHASON STGDEM 0 1 0 0 1 ------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 2 2 0 0 0 2: 0 0 1 1 0 3: 2 2 0 0 0 4: 0 0 0 0 1 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 0 0 0 0 0 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 344 344 0 0 0 2: 0 0 1 1 0 3: 322 322 0 0 0 4: 0 0 0 0 1 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 7.0 7.0 7.0 7.0 MAX 50 30 50 30 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 6 -1 6 2: -1 -1 5 6 3: -1 6 -1 6 4: 6 6 -1 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 0 0 0 0 EMXMAX 0.0 0.0 0.0 0.0 PRXMAX 0.0 0.0 0.0 0.0 ------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 ------- seconds -------> LMIN 7.0 7.0 7.0 7.0 7.0 LLATOT 2 2 1 2 2 LLANES 1 1 3 5 6 8 2 2 4 0 7 9 3 0 0 0 0 0 ------- seconds -------> ESLMAX 120 120 120 120 120 LOSTIM 10 10 19 19 19 STOPEN 31 31 18 19 22 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 EPDET(2) 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 CANDET 0 0 0 0 0 ------------------------------------------------------DETECTOR DATA-------------------------------------------------------------- LANE NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X 1 2 3 4 5 6 7 8 9 DX 43 43 42 42 35 35 35 40 40 IN 11 12 13 14 15 16 0 18 19 DIN 120 120 115 115 90 90 0 83 83 DSHORT 0 0 0 0 0 0 50 0 0 OUT 0 0 0 0 0 0 0 0 0 IN SINK 0 0 0 0 0 0 0 0 0 COMB X 0 0 0 0 0 17 0 0 0 X SINK 0 0 20 0 0 0 0 0 0 STOPLINE 0 0 0 0 0 10 0 0 0 ALT UP X 11 12 13 14 15 16 0 18 19 ALT DWN X 0 0 0 0 0 0 0 0 0 ASSOCD 1 0 0 0 0 0 7 0 0 0 ASSOCD 2 0 0 0 0 0 0 0 0 0


September 2005

52

------------------------------------------------------LANE DATA------------------------------------------------------------------ ------- metres/second -------> CSPEED 14 14 19 19 14 14 14 16 16 ------- seconds -------> SATINC 2.2 2.0 2.1 2.0 2.2 1.9 1.9 2.0 1.9 STLOST 1.8 1.5 0.5 0.5 1.0 1.0 1.0 0.5 1.0 COMTIM 0.0 0.0 0.0 0.0 0.0 13.0 13.0 0.0 0.0 LANEWF 1 1 1 1 1 1 1 1 1 ------------------------------------------------------BONUS DATA----------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK data ------- seconds -------> BONTIM 0 18 0 19 0 BONCUT 0 -1 0 -3 0 LANE data ------- vehicles -------> BONBC 0 0 9 10 0 11 0 0 0 STAGE data ------ seconds -------> LOWMAX 50 30 50 30 ------------------------------------------------------DERIVED DATA--------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK derived data -------> MIXOUT 0 0 0 0 0 LANE derived data ------- seconds -------> MAXMIN 16.5 15.0 14.0 13.5 13.0 11.0 11.0 13.0 12.5 CRUSIN 8.0 8.0 6.0 6.0 6.0 6.0 0.0 5.0 5.0 CRUSX 2.5 2.5 2.0 2.0 2.0 2.0 2.0 2.0 2.0 MOVQIN 39.5 39.5 38.0 38.0 29.5 29.5 0.0 27.5 27.5 MOVEQX 19.5 18.0 17.0 17.0 16.0 14.0 14.0 16.0 16.0 QMINON 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 XOSAT 0 0 0 0 0 0 1 0 0 ------- vehicles -------> OSATCC 7 8 6 6 5 6 3 5 5 ------- seconds -------> GAMBER 2.0 2.0 2.5 2.5 2.0 2.0 2.0 2.5 2.5 SATGAP 1.5 1.4 1.4 1.4 1.5 1.4 1.4 1.4 1.4 CRITG 3.5 3.4 3.4 3.4 3.5 3.4 3.4 3.4 3.4 ------------------------------------------------------CONSTANT DATA-------------------------------------------------------------- ------- seconds -------> NDETS SCAN MINEXT MAXEXT ADDGAP SUBGAP 20 0.5 3.0 8.5 0.5 0.5 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK constant data -------> MINPCS 50% 50% 50% 50% 50% SHORTL 0 0 0 0 0 NMAINL 2 2 1 1 2 - - - - - - - - - - - - - - - - ASSESSMENT TIMES - - - - - - - - - - - - - - - - START 6: 0 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 STOP 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 0: 0 telephone number:- 0 0 0 0 0 255 0 0 0 0 0 0 0 0 0 0 ------------------------------------------------------VARIABLES------------------------------------------------------------------ LASTAG SNEXT WARMUP MARKER PREMRK JUNSMF SMCYCL TOTLAM 8 8 -1 1 1 75 990 75 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 STAGE variables -------> STADEM 0 0 0 0 LAMBDA 31 19 31 19 STCYCL 5 5 5 5 MERITV 100 100 100 100 DRIFMX 500 300 500 300 ALTLAM 31 19 31 19 LINK variables --------> CYCLTM 5 5 5 5 5 LINDEM 1 1 1 1 1 LINGRE 5 5 5 5 5 YVALUE 62 62 19 19 19 LSMFLO 36 36 18 36 36 EXTRAG 5 5 5 5 5 PRENSA 1 1 1 1 1 LANE variable ---------> SMFLOW 18 18 18 18 18 18 18 18 18 CHECKSUM OF "FIXED" DATA CHKSM1 = 43084 CHECKSUM IS THE SUM OF ALL DATA CHKSUM = 47648


September 2005

53

3.13.2 Example Site 2 The second example shows the use of an 'early start' where the right turning movement (stage 2) is allowed to run unopposed. The design uses a fixed duration for stage 2, during a particular plan.

The use of link 4 for the pedestrian link allows links 5 & 6 to be for lanes 5 & 6, retaining the simplicity of the one to one correspondence between link and lane numbers.

Example site 2

4

3

14

13

Lane 1 11

12 1

2

15

5

Ped.

35m

91m 43m

44m 100m

43m

80m


1 2 3 4 5 6

Lane 1 Lane 2 Lanes 3&4 Ped. Lane 5 Lane 6

Lane 2

Lane 4

Lane 3

Lane 6

Lane 5

1 3 2

7

6


September 2005

54

MOVA DATA - Example Site 2 MOVA DATA CHESTER.DT 11:59 19/12/2002 ------------------------------------------------------JUNCTION DATA-------------------------------------------------------------- time of day changes in data sets 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 24:00 | | | | | | | | | | | | | SAT 22222222 22222222 22222222 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 22222222 SUN 22222222 22222222 22222222 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 22222222 MON 22222222 22222222 22222222 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 22222222 TUE 22222222 22222222 22222222 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 22222222 WED 22222222 22222222 22222222 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 22222222 THU 22222222 22222222 22222222 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 22222222 FRI 22222222 22222222 22222222 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 22222222 STAGES NLANES NLINKS MAINST TOTALG 3 6 6 0 90 (seconds) OPTYPE DETON STAGON PHASON STGDEM 0 1 1 1 1 ------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 0 0 0 1 1 1 2: 2 3 0 0 0 0 3: 2 4 1 0 0 0 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 4 4 0 0 0 0 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 0 0 0 1 1 1 2: 1 1 0 0 0 0 3: 1 1 1 0 0 0 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 10.0 9.0 7.0 MAX 40 9 60 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 9 -1 2: -1 -1 5 3: 7 -1 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 0 0 0 EMXMAX 0.0 0.0 0.0 PRXMAX 0.0 0.0 0.0 ------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 8 0 0 ------- seconds -------> LMIN 7.0 4.0 7.0 10.0 7.0 7.0 LLATOT 1 1 2 0 1 1 LLANES 1 1 2 3 0 5 6 2 0 0 4 0 0 0 3 0 0 0 0 0 0 ------- seconds -------> ESLMAX 120 120 120 0 120 120 LOSTIM 13 13 28 0 15 15 STOPEN 22 17 19 0 17 10 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 EPDET(2) 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 CANDET 0 0 0 0 0 0


September 2005

55

------------------------------------------------------DETECTOR DATA-------------------------------------------------------------- LANE NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X 1 2 3 4 5 6 DX 43 43 44 44 43 18 IN 11 12 13 14 15 0 DIN 91 91 100 100 80 0 DSHORT 0 0 0 0 0 999 OUT 0 0 0 0 0 0 IN SINK 0 0 0 0 0 0 COMB X 0 0 0 0 0 0 X SINK 0 0 0 0 0 0 STOPLINE 0 0 0 0 7 0 ALT UP X 11 12 13 14 15 0 ALT DWN X 0 0 0 0 0 0 ASSOCD 1 0 0 0 0 0 0 ASSOCD 2 0 0 0 0 0 0 ------------------------------------------------------LANE DATA------------------------------------------------------------------ ------- metres/second -------> CSPEED 12 12 11 13 8 8 ------- seconds -------> SATINC 1.9 2.3 2.1 2.0 2.3 3.0 STLOST 1.0 1.3 0.9 1.3 1.0 1.5 COMTIM 0.0 0.0 0.0 0.0 0.0 0.0 LANEWF 1 1 1 1 1 1 ------------------------------------------------------BONUS DATA----------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK data ------- seconds -------> BONTIM 0 0 0 0 0 0 BONCUT 0 0 0 0 0 0 LANE data ------- vehicles -------> BONBC 0 0 0 0 0 0 STAGE data ------ seconds -------> LOWMAX 0 0 0 ------------------------------------------------------DERIVED DATA--------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK derived data -------> MIXOUT 0 0 0 0 0 0 LANE derived data ------- seconds -------> MAXMIN 13.5 17.0 15.5 15.0 16.5 9.5 CRUSIN 7.0 7.0 8.5 7.5 9.5 0.0 CRUSX 3.0 3.0 3.5 3.0 5.0 1.5 MOVQIN 30.0 30.0 33.0 33.0 26.5 0.0 MOVEQX 17.0 20.0 18.5 18.0 19.5 12.5 QMINON 6.0 6.0 6.0 6.0 6.0 6.0 XOSAT 0 0 0 0 0 1 ------- vehicles -------> OSATCC 7 6 8 8 8 2 ------- seconds -------> GAMBER 2.0 2.0 2.0 2.0 1.5 1.5 SATGAP 1.4 1.5 1.4 1.4 1.5 1.7 CRITG 3.4 3.5 3.4 3.4 3.5 3.7 ------------------------------------------------------CONSTANT DATA-------------------------------------------------------------- ------- seconds -------> NDETS SCAN MINEXT MAXEXT ADDGAP SUBGAP 15 0.5 3.0 10.0 0.5 0.5 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK constant data -------> MINPCS 50% 50% 50% 50% 50% 50% SHORTL 0 0 0 0 0 1 NMAINL 1 1 2 0 1 1 - - - - - - - - - - - - - - - - ASSESSMENT TIMES - - - - - - - - - - - - - - - - START 6: 0 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 STOP 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 0: 0 telephone number:- 0 0 0 0 0 255 0 0 0 0 0 0 0 0 0 0


September 2005

56

------------------------------------------------------VARIABLES------------------------------------------------------------------ LASTAG SNEXT WARMUP MARKER PREMRK JUNSMF SMCYCL TOTLAM 8 8 -1 1 1 75 990 75 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 STAGE variables -------> STADEM 0 0 0 LAMBDA 37 8 55 STCYCL 5 5 5 MERITV 100 100 100 DRIFMX 400 90 600 ALTLAM 37 8 55 LINK variables --------> CYCLTM 5 5 5 5 5 5 LINDEM 1 1 1 1 1 1 LINGRE 5 5 5 5 5 5 YVALUE 63 63 55 37 37 37 LSMFLO 18 18 36 0 18 18 EXTRAG 5 5 5 5 5 5 PRENSA 1 1 1 1 1 1 LANE variable ---------> SMFLOW 18 18 18 18 18 18 CHECKSUM OF "FIXED" DATA CHKSM1 = 37458 CHECKSUM IS THE SUM OF ALL DATA CHKSUM = 41691


September 2005

57

3.13.3 Example Site 3 The third example has heavily flared approaches on most arms, allowing for bonus green data to be employed. The designer should note the use of 'COMBX' detectors on most approaches, and the use of an 'IN-SINK' detector for lane 6 (this is because the

adjacent lane cannot discharge freely during stage 2). Fixed time S5 (Min=Max) allows a short period for pedestrian to cross the westbound exit. Stages 1 to 4 all allow traffic into the westbound exit.

Lane 10

95m

11

12

1

2

44m 80m


1 2 3 4 5 6 7 8 9 10

Lane 1 Lane 2 Lane 3 Lane 4 Lane 5 Lane 6 Lane 7 Lane 8 Lane 9 Lane 10

10

8

9 19

44m

16

44m

4 3

100m

13

Lane 9

Lane 8

Lane 1

Lane 2

44m

115m

Lane 5 Lane 6

Lane 7

Lane 4

Lane 3

21

5 6 7

‘OUT’ detector

Example site 3

2 3

4 5

1

Short lane length = 60m

COMBX 14 = 3+4

COMBX 18 = 8+9+10


COMBX 15 = 5+6



September 2005

58

MOVA DATA - Example Site 3 MOVA DATA EX3.D1 11: 8 23/12/2002 ------------------------------------------------------JUNCTION DATA-------------------------------------------------------------- STAGES NLANES NLINKS MAINST TOTALG 5 10 10 1 160 (seconds) OPTYPE DETON STAGON PHASON STGDEM 0 0 0 0 1 ------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 2 2 0 0 2 0 0 0 0 0 2: 0 0 1 1 2 2 4 0 0 0 3: 0 0 0 0 2 2 3 0 0 0 4: 0 0 0 0 0 0 0 1 1 1 5: 2 2 0 0 0 0 0 0 0 0 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 6 6 0 0 7 8 8 0 0 0 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 0 0 0 0 2 0 0 0 0 0 2: 0 0 1 1 13 13 13 0 0 0 3: 0 0 0 0 0 0 241 0 0 0 4: 0 0 0 0 0 0 0 1 1 1 5: 1 1 0 0 0 0 0 0 0 0 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 1.0 7.0 4.0 7.0 7.0 MAX 60 60 30 50 7 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 6 6 5 -1 2: -1 -1 5 6 5 3: -1 -1 -1 6 5 4: -1 5 6 -1 7 5: 0 -1 -1 -1 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 0 0 0 0 0 EMXMAX 20.0 20.0 20.0 20.0 20.0 PRXMAX 20.0 20.0 20.0 20.0 20.0 ------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 0 0 0 0 0 ------- seconds -------> LMIN 7.0 7.0 7.0 7.0 7.0 7.0 4.0 7.0 7.0 7.0 LLATOT 1 1 1 1 1 1 1 1 1 1 LLANES 1 1 2 3 4 5 6 7 8 9 10 2 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 ------- seconds -------> ESLMAX 40 60 60 60 40 40 30 40 40 40 LOSTIM 20 20 20 20 11 16 20 20 20 20 STOPEN 28 28 28 28 28 28 24 24 24 24 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 0 0 0 0 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 EPDET(2) 0 0 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 CANDET 0 0 0 0 0 0 0 0 0 0


September 2005

59

------------------------------------------------------DETECTOR DATA-------------------------------------------------------------- LANE NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X 1 2 3 4 5 6 7 8 9 10 DX 44 44 44 44 44 44 44 44 44 44 IN 11 12 13 0 0 16 0 0 19 0 DIN 80 80 100 0 0 115 0 0 95 0 DSHORT 0 0 0 60 80 0 80 70 0 70 OUT 0 0 0 0 0 0 21 0 0 0 IN SINK 0 0 0 0 0 7 0 0 0 0 COMB X 0 0 14 0 0 15 0 0 18 0 X SINK 0 0 0 0 0 0 0 0 0 0 STOPLINE 0 0 0 0 0 0 0 0 0 0 ALT UP X 11 12 13 0 0 16 0 0 19 0 ALT DWN X 0 0 0 0 0 0 21 0 0 0 ASSOCD 1 0 0 4 0 0 5 0 0 8 0 ASSOCD 2 0 0 0 0 0 0 0 0 10 0 ------------------------------------------------------LANE DATA------------------------------------------------------------------ ------- metres/second -------> CSPEED 12 12 11 11 11 11 10 11 12 10 ------- seconds -------> SATINC 2.3 2.0 2.5 2.0 2.4 2.1 2.5 2.5 2.0 2.5 STLOST 1.0 1.0 1.0 1.0 2.0 1.0 3.0 1.1 1.3 1.2 COMTIM 0.0 0.0 22.0 0.0 0.0 25.0 0.0 0.0 20.0 0.0 LANEWF 1 1 1 1 1 1 1 1 1 1 ------------------------------------------------------BONUS DATA----------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK data ------- seconds -------> BONTIM 0 0 28 0 0 31 0 0 26 0 BONCUT 0 0 1 0 0 -3 0 0 1 0 LANE data ------- vehicles -------> BONBC 0 0 13 0 0 16 0 0 15 0 STAGE data ------ seconds -------> LOWMAX 60 60 30 50 7 ------------------------------------------------------DERIVED DATA--------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK derived data -------> MIXOUT 0 0 0 0 0 0 2 0 0 0 LANE derived data ------- seconds -------> MAXMIN 17.0 14.5 18.5 14.5 18.5 15.5 20.5 18.5 15.0 18.5 CRUSIN 6.5 6.5 8.5 0.0 0.0 10.0 0.0 0.0 7.5 0.0 CRUSX 3.5 3.5 3.5 3.5 3.5 3.5 4.0 3.5 3.5 4.0 MOVQIN 26.5 26.5 33.0 0.0 0.0 38.0 0.0 0.0 31.5 0.0 MOVEQX 20.0 17.5 21.5 17.5 21.5 18.5 23.5 21.5 18.0 21.5 QMINON 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 XOSAT 0 0 0 1 1 0 1 1 0 1 ------- vehicles -------> OSATCC 6 7 7 5 5 10 4 4 8 5 ------- seconds -------> GAMBER 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 SATGAP 1.5 1.4 1.6 1.4 1.5 1.4 1.6 1.6 1.4 1.6 CRITG 3.5 3.4 3.6 3.4 3.5 3.4 3.6 3.6 3.4 3.6 ------------------------------------------------------CONSTANT DATA-------------------------------------------------------------- ------- seconds -------> NDETS SCAN MINEXT MAXEXT ADDGAP SUBGAP 21 0.5 3.0 10.5 0.5 0.5 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK constant data -------> MINPCS 50% 50% 50% 50% 50% 50% 50% 50% 50% 50% SHORTL 0 0 0 1 1 0 1 1 0 1 NMAINL 1 1 1 1 1 1 1 1 1 1 - - - - - - - - - - - - - - - - ASSESSMENT TIMES - - - - - - - - - - - - - - - - START 6: 0 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 STOP 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 0: 0 telphone number:- 0 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0


September 2005

60

------------------------------------------------------VARIABLES------------------------------------------------------------------ LASTAG SNEXT WARMUP MARKER PREMRK JUNSMF SMCYCL TOTLAM 8 8 -1 1 1 75 990 75 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 STAGE variables -------> STADEM 0 0 0 0 0 LAMBDA 29 29 14 24 3 STCYCL 5 5 5 5 5 MERITV 100 100 100 100 100 DRIFMX 600 600 300 500 70 ALTLAM 29 29 14 24 3 LINK variables --------> CYCLTM 5 5 5 5 5 5 5 5 5 5 LINDEM 1 1 1 1 1 1 1 1 1 1 LINGRE 5 5 5 5 5 5 5 5 5 5 YVALUE 32 32 29 29 72 43 43 24 24 24 LSMFLO 18 18 18 18 18 18 18 18 18 18 EXTRAG 5 5 5 5 5 5 5 5 5 5 PRENSA 1 1 1 1 1 1 1 1 1 1 LANE variable ---------> SMFLOW 18 18 18 18 18 18 18 18 18 18 CHECKSUM OF "FIXED" DATA CHKSM1 = 48499 CHECKSUM IS THE SUM OF ALL DATA CHKSUM = 54262


September 2005

61

3.13.4 Example Site 4 The fourth example has fully signalled right turn movements. It also has five pedestrian links, which are demanded by detector numbers 22 to 25 which relate to the push-buttons for each link. All but one of the pedestrian links are served by more than one stage. If using standard (i.e. non PUFFIN) type pedestrian facilities, the designer is encouraged to examine how the SDCODEs are used to determine the special conditions under which a specific pedestrian link demand results in a stage demand. Consider also how pedestrians can progress across an approach served by more than one phase and whether tidal pedestrian flows need to be catered for. One pedestrian link (link 9, detector 23) serves two phases as they run in the same stages, and link 8 (phase H) runs in just the all-red stage (stage 4). There are options as to how the pedestrian links are handled in the latest versions of MOVA especially now that PUFFIN type facilities are sometimes used at junctions. Before PUFFIN facilities were available, pedestrian detectors were normally processed by the controller before the signal was passed to MOVA. MOVA would then register the demand for a pedestrian phase, and this would be a latched demand. In MOVA version M4 and later, the call-cancel feature of PUFFIN type facilities can be accommodated. The easiest way of doing this is to let the controller combine the wait button and the kerbside detector(s) before passing the signal to MOVA (and the method illustrated in this example). Then, in MOVA data, the pedestrian detectors need to be specified as ‘unlatched’ by adding 100 to them (so LTYPE 22 would become 122). This way, MOVA will take away (unlatch) the demand for the pedestrian phase if the signal had gone

before the phase had run. The SDCODEs can be ‘3’ in any or all stages that satisfies a pedestrian demand, or could be ‘0’ if some other stage is preferred. (If a non-preferred stage happens to run before the preferred stage, the demand will be removed for the preferred stage.) Note: If any unlatched detectors are specified in this way in MOVA M4, detector channel 24 has to be included as a pedestrian link, and it has to be permanently ‘on’, but with ‘0’ for all LGREEN and SDCODE entries. Contact TRL if more advice is needed, or upgrade to a newer version of MOVA.

In MOVA M5 and later, it is possible to have the kerbside detectors and the wait confirm connected to MOVA separately. The kerbside detectors are specified as above, but the wait confirms are specified in a new array called PedConfirm. The reason for taking this approach is to allow pedestrian weighting to be included for each kerbside detector separately. Pedestrian weighting can be specified by entering ‘64’ or (for higher weighting) ‘65’ in ‘STOPEN’ for pedestrian links which then includes pedestrians in the delay optimisation algorithm such that the longer pedestrians wait, the greater the disbenefit of not servicing them. With the kerbside detectors connected separately, the weighting will be in proportion to the number of kerbside detectors currently active. The wait confirm channels would normally be included in PedConfirm more than once, i.e. once for each kerbside detector using the same phase. Lane 4 is a long lane, as indicated by the inclusion of an IN detector (No 14) at 100 metres. Because the IN detector of lane 3 is at 155 metres, Detector 14 is also an IN-SINK detector for lane 3.


September 2005

62

Example site 4

3

45m


7

5

6

Lane 7

16

15

9

1

2

4

13

12

8

I

G

E

H

D

F

19

18

17 Lane 6

Lane 5

Lane 2

Lane 3

Lane 1

Lane 4

Lane 8

Lane 9

92m

46m155m

95m

45m

45m 115m

2 3

4 5

1E

D D

FE

G

Peds only

F

EI

D G

I

G

H

100m

14

20

10

1 2 3 4 5 6 7 8 9 10 11 12

Lane 1 Lane 2&3 Lane 4 Lane 5&6 Lane 7 Lane 8 Lane 9 Ped (H). Ped (D & E). Ped (F). Ped (G). Ped (I).

22

23 25

23 24

26 WAIT

WAIT

WAIT

WAIT

WAIT

WAIT


September 2005

63

MOVA DATA - Example Site 4 MOVA DATA MCH-EX4.DT 11:32 12/12/2002 ------------------------------------------------------JUNCTION DATA------------ STAGES NLANES NLINKS MAINST TOTALG 5 9 12 1 90 (seconds) OPTYPE DETON STAGON PHASON STGDEM 1 1 0 0 1 ------------------------------------------------------STAGE DATA--------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK 1: 1 1 0 1 0 0 0 0 0 0 0 0 2: 0 0 2 0 1 0 0 0 2 0 0 0 3: 0 0 2 0 0 0 0 0 2 2 2 0 4: 0 0 0 0 0 0 0 1 2 2 2 2 5: 0 0 0 0 0 1 1 0 0 0 2 2 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO 0 0 6 0 0 0 0 0 7 8 9 10 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK 1: 1 1 0 1 0 0 0 0 0 0 0 0 2: 0 0 13 0 1 0 0 0 3 0 0 0 3: 0 0 0 0 0 0 0 0 0 3 0 0 4: 0 0 0 0 0 0 0 3 0 3 0 0 5: 0 0 0 0 0 1 1 0 0 0 3 3 - - - - sec - - - - MIN 7.0 8.0 1.0 7.0 7.0 MAX 50 30 30 7 50 CHANGES(to Stage,from Stage) sec FROM TO STAGE STAGE 1: -1 8 8 8 8 2: 8 -1 8 8 8 3: 8 8 -1 8 8 4: 8 8 8 -1 8 5: 8 8 8 8 -1 PFACIL 0 0 0 0 0 EMXMAX 0.0 0.0 0.0 0.0 0.0 PRXMAX 0.0 0.0 0.0 0.0 0.0 ------------------------------------------------------LINK DATA---------------- LTYPE 0 0 0 0 0 0 0 122 123 124 125 126 - - - - - - - sec - - - - - - - LMIN 7.0 7.0 7.0 7.0 7.0 7.0 7.0 8.0 7.0 7.0 7.0 7.0 LLATOT 1 2 1 2 1 1 1 0 0 0 0 0 LLANES 1 1 2 4 5 7 8 9 0 0 0 0 0 2 0 3 0 6 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 - - - - - - - sec - - - - - - - - ESLMAX 120 120 38 120 120 120 120 0 0 0 0 0 LOSTIM 33 33 27 33 33 33 33 0 0 0 0 0 STOPEN 10 26 17 14 13 8 10 64 64 64 64 64 EPDET(1) 0 0 0 0 0 0 0 0 0 0 0 0 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 seconds EPDET(2) 0 0 0 0 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 seconds HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 seconds CANDET 0 0 0 0 0 0 0 0 0 0 0 0 ------------------------------------------------------DETECTOR DATA------------ DETS LANE X 1 2 3 4 5 6 7 8 9 DX 46 46 46 46 45 45 45 45 45 IN 0 12 13 14 15 16 17 18 19 DIN 0 155 155 97 115 115 115 92 95 DSHORT 97 0 0 0 0 0 0 0 0 OUT 0 0 0 0 0 0 0 0 0 IN SINK 0 0 14 0 0 0 0 0 0 COMB X 0 21 0 0 0 0 0 0 0 X SINK 0 0 0 0 0 0 0 0 0 STOPLINE 0 0 0 20 0 0 10 0 0 ALT UP X 0 12 13 14 15 16 17 18 19 ALT DWN X 0 0 0 0 0 0 0 0 0 ASSOCD 1 0 1 0 0 0 0 0 0 0 ASSOCD 2 0 0 0 0 0 0 0 0 0 ------------------------------------------------------LANE DATA---------------- - - - - - - - m/sec - - - - - - - - - CSPEED 16 16 18 17 12 14 13 10 11 - - - - - - - - sec - - - - - - - - - - SATINC 2.0 1.7 1.8 2.0 1.9 1.7 1.8 2.1 2.1 STLOST 1.5 1.0 0.5 0.5 1.0 1.0 1.0 0.5 1.0 COMTIM 0.0 21.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 LANEWF 1 1 1 5 1 1 5 1 1


September 2005

64

------------------------------------------------------BONUS DATA--------------- - - - - - - sec - - - - - - - BONTIM(Links) 0 31 0 0 0 0 0 0 0 0 0 0 BONCUT(Links) 0 -4 0 0 0 0 0 0 0 0 0 0 - - - - - - - vehicles - - - - - - - - BONBC(Lanes) 0 20 19 0 0 0 0 0 0 - - - - sec - - - - LOWMAX(Stages) 50 30 30 7 50 ------------------------------------------------------DERIVED DATA------------- MIXOUT(Links) 0 0 0 0 0 0 0 0 0 0 0 0 Data for lanes - - - - - - - - sec - - - - - - - - - - MAXMIN 16.0 13.0 13.5 15.0 14.5 13.0 13.5 15.5 16.0 CRUSIN 0.0 9.5 8.5 5.5 9.0 8.0 8.5 8.5 8.0 CRUSX 2.5 2.5 2.5 2.5 3.5 3.0 3.0 4.0 3.5 MOVQIN 0.0 51.0 51.0 32.0 38.0 38.0 38.0 30.5 31.5 MOVEQX 19.0 18.5 18.5 18.5 18.0 18.0 18.0 18.5 19.0 QMINON 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 XOSAT 1 0 0 0 0 0 0 0 0 - - - - - - - vehicles - - - - - - - - OSATCC 4 11 9 6 9 9 9 8 8 - - - - - - - - sec - - - - - - - - - - GAMBER 2.5 2.5 2.5 2.5 2.0 2.0 2.0 2.0 2.0 SATGAP 1.4 1.3 1.3 1.4 1.4 1.3 1.3 1.4 1.4 CRITG 3.4 3.3 3.3 3.4 3.4 3.3 3.3 3.4 3.4 ------------------------------------------------------CONSTANT DATA------------ - - - - - - - sec - - - - - - - NDETS SCAN MINEXT MAXEXT ADDGAP SUBGAP 26 0.5 3.0 10.0 0.5 0.5 MINPCS(Links) 50% 50% 50% 50% 50% 50% 50% 50% 50% 50% 50% 50% SHORTL(Links) 1 0 0 0 0 0 0 0 0 0 0 0 NMAINL(Links) 1 2 1 2 1 1 1 0 0 0 0 0 - - - - - - - - - - - - - - - - ASSESSMENT TIMES - - - - - - - - - - - - - - - - START 6: 0 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 STOP 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 0: 0 telphone number:- 0 1 3 4 4 7 7 0 4 8 7 210 0 0 0 0 ------------------------------------------------------VARIABLES---------------- LASTAG SNEXT WARMUP MARKER PREMRK JUNSMF SMCYCL TOTLAM 8 8 -1 1 1 75 990 75 - - STAGES - - - STADEM 0 0 0 0 0 LAMBDA 30 18 18 4 30 STCYCL 5 5 5 5 5 MERITV 100 100 100 100 100 DRIFMX 500 300 300 70 500 ALTLAM 30 18 18 4 30 - - - - - LINKS - - - - - - CYCLTM 5 5 5 5 5 5 5 5 5 5 5 5 LINDEM 1 1 1 1 1 1 1 1 1 0 1 0 LINGRE 5 5 5 5 5 5 5 5 5 5 5 5 YVALUE 30 30 36 30 18 30 30 40 22 52 34 4 LSMFLO 18 36 18 36 18 18 18 0 0 0 0 0 EXTRAG 5 5 5 5 5 5 5 5 5 5 5 5 PRENSA 1 1 1 1 1 1 1 1 1 1 1 1 - - - - - - - - LANES - - - - - - - - SMFLOW 18 18 18 18 18 18 18 18 18 CHECKSUM OF "FIXED" DATA CHKSM1 = 51671 CHECKSUM IS THE SUM OF ALL DATA CHKSUM = 56105


September 2005

65

3.13.5 Example Site 5 The fifth example shows a more complex junction with many opposed right turns. The designer should note the different treatment being given for lanes 2,4,6 and 8 which are all opposed, compared with lane 10, which is not.

The former lanes have 'X' detectors, which are treated as 'IN-SINK' detectors from the adjacent main lane. They cannot be used as 'COMBX' detectors, like D10 (lane 10) since they cannot discharge freely at the same time as the main lane.

Example site 5

7 8

43 13

Lane 5

15

1

2

Lane 1 11

17

910

20

43m

Link 1 2 3 4 5 6 7 8 9

Movements on Link Lane 1 Lane 2 Lane 3 Lane 4 Lane 5 Lane 6 Lane 7 Lane 8 Lane 9

Lane 2

Lane 4

Lane 3

Lane 9

Lane 10

Lane 8 Lane 7

Lane 6

140m

43m 105m

43m

43m

43m

130m

130m

1 3 2

56

DETS 2, 4, 6, 8 act as “IN – SINK” as well as ‘X ‘dets.

COMBX 19 = 9+10


September 2005

66

MOVA DATA - Example Site 5 MOVA DATA NOTTS.DT 12:23 19/12/2002 ------------------------------------------------------JUNCTION DATA-------------------------------------------------------------- STAGES NLANES NLINKS MAINST TOTALG 3 10 10 1 90 (seconds) OPTYPE DETON STAGON PHASON STGDEM 0 1 1 1 1 ------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 1 1 1 1 0 0 0 0 0 0 2: 0 0 0 0 1 1 1 1 0 0 3: 0 0 0 0 0 0 0 0 1 1 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 0 0 0 0 0 0 0 0 0 0 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 1 1 1 1 0 0 0 0 0 0 2: 0 0 0 0 1 1 1 1 0 0 3: 0 0 0 0 0 0 0 0 1 1 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 7.0 7.0 7.0 MAX 45 45 25 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 7 6 2: 6 -1 6 3: 6 6 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 0 0 0 EMXMAX 0.0 0.0 0.0 PRXMAX 0.0 0.0 0.0 ------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 0 0 0 0 0 ------- seconds -------> LMIN 7.0 7.0 7.0 7.0 7.0 7.0 7.0 7.0 7.0 7.0 LLATOT 1 1 1 1 1 1 1 1 1 1 LLANES 1 1 2 3 4 5 6 7 8 9 10 2 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 ------- seconds -------> ESLMAX 120 120 120 120 120 120 120 120 120 120 LOSTIM 16 16 16 16 16 16 16 16 16 16 STOPEN 27 23 26 29 31 35 29 31 24 25 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 0 0 0 0 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 EPDET(2) 0 0 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 CANDET 0 0 0 0 0 0 0 0 0 0 ------------------------------------------------------DETECTOR DATA-------------------------------------------------------------- LANE NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X 1 2 3 4 5 6 7 8 9 10 DX 43 43 43 43 43 43 43 43 40 40 IN 11 0 13 0 15 0 17 0 0 20 DIN 110 0 105 0 140 0 130 0 0 110 DSHORT 0 50 0 50 0 100 0 45 45 0 OUT 0 0 0 0 0 0 0 0 0 0 IN SINK 2 0 4 0 6 0 8 0 0 0 COMB X 0 0 0 0 0 0 0 0 0 19 X SINK 0 0 0 0 0 0 0 0 0 0 STOPLINE 0 0 0 0 0 0 0 0 0 0 ALT UP X 11 0 13 0 15 0 17 0 0 20 ALT DWN X 0 0 0 0 0 0 0 0 0 0 ASSOCD 1 0 0 0 0 0 0 0 0 0 9 ASSOCD 2 0 0 0 0 0 0 0 0 0 0


September 2005

67

------------------------------------------------------LANE DATA------------------------------------------------------------------ ------- metres/second -------> CSPEED 13 13 13 13 16 16 15 15 13 13 ------- seconds -------> SATINC 1.9 2.3 1.9 2.3 1.9 2.3 1.9 2.3 1.9 1.9 STLOST 1.0 1.5 1.0 1.5 1.0 1.5 1.0 1.5 1.0 1.0 COMTIM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 21.0 LANEWF 1 1 1 1 1 1 1 1 1 1 ------------------------------------------------------BONUS DATA----------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK data ------- seconds -------> BONTIM 19 0 19 0 20 0 18 0 0 29 BONCUT 1 0 -1 0 -7 0 1 0 0 1 LANE data ------- vehicles -------> BONBC 11 0 11 0 11 0 10 0 0 16 STAGE data ------ seconds -------> LOWMAX 45 45 25 ------------------------------------------------------DERIVED DATA--------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK derived data -------> MIXOUT 0 0 0 0 0 0 0 0 0 0 LANE derived data ------- seconds -------> MAXMIN 13.5 17.0 13.5 17.0 13.5 17.0 13.5 17.0 12.5 12.5 CRUSIN 8.0 0.0 7.5 0.0 8.5 0.0 8.5 0.0 0.0 8.0 CRUSX 3.0 3.0 3.0 3.0 2.5 2.5 2.5 2.5 2.5 2.5 MOVQIN 36.5 0.0 34.5 0.0 46.0 0.0 43.0 0.0 0.0 36.5 MOVEQX 17.0 20.0 17.0 20.0 17.0 20.0 17.0 20.0 16.0 16.0 QMINON 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 XOSAT 0 1 0 1 0 1 0 1 1 0 ------- vehicles -------> OSATCC 8 0 8 0 9 0 9 0 0 8 ------- seconds -------> GAMBER 2.0 2.0 2.0 2.0 2.5 2.5 2.0 2.0 2.0 2.0 SATGAP 1.4 1.5 1.4 1.5 1.4 1.5 1.4 1.5 1.4 1.4 CRITG 3.4 3.5 3.4 3.5 3.4 3.5 3.4 3.5 3.4 3.4 ------------------------------------------------------CONSTANT DATA-------------------------------------------------------------- ------- seconds -------> NDETS SCAN MINEXT MAXEXT ADDGAP SUBGAP 20 0.5 3.0 9.0 0.5 0.5 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK constant data -------> MINPCS 50% 50% 50% 50% 50% 50% 50% 50% 50% 50% SHORTL 0 1 0 1 0 1 0 1 1 0 NMAINL 1 1 1 1 1 1 1 1 1 1 - - - - - - - - - - - - - - - - ASSESSMENT TIMES - - - - - - - - - - - - - - - - START 6: 0 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 STOP 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 0: 0 telephone number:- 0 0 0 0 0 255 0 0 0 0 0 0 0 0 0 0 ------------------------------------------------------VARIABLES------------------------------------------------------------------ LASTAG SNEXT WARMUP MARKER PREMRK JUNSMF SMCYCL TOTLAM 8 8 -1 1 1 75 990 75 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 STAGE variables -------> STADEM 0 0 0 LAMBDA 39 39 22 STCYCL 5 5 5 MERITV 100 100 100 DRIFMX 450 450 250 ALTLAM 39 39 22 LINK variables --------> CYCLTM 5 5 5 5 5 5 5 5 5 5 LINDEM 1 1 1 1 1 1 1 1 1 1 LINGRE 5 5 5 5 5 5 5 5 5 5 YVALUE 39 39 39 39 39 39 39 39 22 22 LSMFLO 18 18 18 18 18 18 18 18 18 18 EXTRAG 5 5 5 5 5 5 5 5 5 5 PRENSA 1 1 1 1 1 1 1 1 1 1 LANE variable ---------> SMFLOW 18 18 18 18 18 18 18 18 18 18 CHECKSUM OF "FIXED" DATA CHKSM1 = 50226 CHECKSUM IS THE SUM OF ALL DATA CHKSUM = 54474


September 2005

68

3.13.6 Example Site 6 ‘Double-right-turn’ situation

40m

160m45m

7 8

6 5

74m

42m

85m

106m

45m

9 10

19

18

17

16

11

20

4

2223

24

21123

121314

45m

40m

125m

2625

Lane 1 Lane 2

Lane 11

Lane 4 Lane 3

Lane 8 Lane 7 Lane 6 Lane 5

Lane 9 Lane 10


1 2 3 4 5 6 7 8

Lane 1 Lanes 2&3 Lane 4 Lanes 5,6&7 Lane 8 Lane 9 Lane 10 Lane 11

2

4 3

1

5


September 2005

69

Example 6 shows a site that has what is known as a ‘double right turn’ where (in this case) the main road has a segregated, separately signalled right-turn lane on each approach. The key issue in this case is that the optimum stage sequence depends on the balance of flows. Commonly, it would be the two straight-ahead flows running first, followed by one or other of the right-turns together with the adjacent straight-ahead flow. Lastly (if needed) both right-turns would flow together. Which sequence is best, and whether the intermediate stage is needed (and if so, which direction) depends on how many want to turn right. In many cases, the preferred sequence is chosen by time-of-day. Indeed, MOVA is able to implement alternative sequences by time of day if necessary. However, since MOVA version M4, there has been a facility for the choice of stage sequence to be made by MOVA on-line. The first point to note when choosing this option is the basic stage sequence. All possible stages have to be included, as is always the case with MOVA, but the stage in which the two right turn movements alone run has to be the first in the sequence (see stages 1 – 4 in the above diagram). Running this stage first allows MOVA to determine which of the two straight-plus-right-turn stages to run next, if any, before moving to stage 4. It could be thought of as running stage 1 until one of the right turns runs out of traffic, then continuing to the next stage catering for the right turn still having traffic, plus the straight-ahead movement. It is not actually that simple as MOVA takes account of the balance of demand, including the straight-ahead flows. The data below shows how this feature is implemented. The SDCODE matrix starts off with entries that would normally be expected in this situation. The matrix has added to it the ‘6MRR’ code. The ‘6MRR’ code is used solely in one (Stage, Link) position in the SDCODE matrix. Unlike other codes, it is placed in the row for stage S, in which link L does not receive green; this ensures that the matrix position is free from other codes. stage (S) - must be the first stage in the 4-

stage sequence of main road greens (stage 1 in Example 6).

link (L) - the (arbitrarily chosen) first Main road (M1) straight-ahead (SA) link (link 4 in Example 6)

‘6’ identifies the code as a double

right-turn optimisation code M2 is he link number of the second

Main road SA link (link 2 in Example 6) in the opposite direction to, in this case, link 4

R1 is the link number of the first

right-turn (RT) link (link 5 in Example 6) adjacent to link M1

R2 is the link number of the second

RT link (link 3 in Example 6) adjacent to link M2

Thus, for Example 6, the 6MRR code = 6253 in the position corresponding to stage 1 and link 4 in the SDCODE matrix. Notes: (a) The sequence of 4 stages must be in

increasing stage number order without intervening stages (e.g. 1,2,3,4 as in Example 6, or (say) 3,4,5,6 at some other site, but not 5,6,1,2).

(b) Links M2, R1, R2, must be given single-

digit link numbers in range 1-9. (c) The stages and sequence must be as in

Example 6 or equivalent: i.e. with R1 & R2 in stage 1, M1 & R1 in stage 2, etc, as the selection logic works only for a known sequence. Incidentally, this gives any spare time to stage 4 (i.e. the stage giving green to both main-road ahead movements)

(d) The stage minimum greens for the four

stages concerned should be set to 1-second, leaving link minima to ensure safety.

The special 6MRR code is used only while all four of the specified Main-road links (L = M1, M2, R1, R2) are demanded; otherwise, the normal codes shown in the SDCODE matrix are used by MOVA to set stage demands for just one or two of the four stages.


September 2005

70

MOVA DATA - Example Site 6 ------------------------------------------------------JUNCTION DATA-------------------------------------------------------------- STAGES NLANES NLINKS MAINST TOTALG 5 11 8 4 200 (seconds) OPTYPE DETON STAGON PHASON STGDEM 0 1 0 0 1 ------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 0 0 2 0 2 0 0 0 2: 0 0 0 2 2 0 0 0 3: 2 2 2 0 0 0 0 0 4: 2 2 0 2 0 0 0 0 5: 0 0 0 0 0 1 1 1 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 6 6 7 8 9 0 0 0 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 0 0 326253 33 0 0 0 2: 0 0 0 0 11 0 0 0 3: 0 0 11 0 0 0 0 0 4: 13 13 0 12 0 0 0 0 5: 0 0 0 0 0 1 1 1 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 1.0 1.0 1.0 1.0 10.0 MAX 40 40 40 120 60 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 6 6 6 6 2: 8 -1 8 6 8 3: 8 8 -1 6 8 4: 8 8 8 -1 8 5: 8 7 8 8 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 0 0 0 0 0 EMXMAX 20.0 20.0 20.0 20.0 20.0 PRXMAX 20.0 20.0 20.0 20.0 20.0 ------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 0 0 0 ------- seconds -------> LMIN 7.0 7.0 5.0 7.0 5.0 10.0 10.0 10.0 LLATOT 1 2 1 3 1 1 1 1 LLANES 1 1 2 4 5 8 9 10 11 2 0 3 0 6 0 0 0 0 3 0 0 0 7 0 0 0 0 ------- seconds -------> ESLMAX 120 120 40 120 40 60 60 60 LOSTIM 19 19 19 19 19 19 19 19 STOPEN 12 23 7 28 7 8 8 12 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 0 0 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 EPDET(2) 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 CANDET 0 0 0 0 0 0 0 0 ------------------------------------------------------DETECTOR DATA-------------------------------------------------------------- LANE NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X 1 2 3 4 5 6 7 8 9 10 11 DX 45 45 45 40 45 45 45 40 42 42 45 IN 12 13 14 0 16 17 0 18 19 0 20 DIN 125 125 125 0 160 160 0 74 85 0 106 DSHORT 0 0 0 45 0 0 70 0 0 60 0 OUT 0 0 0 0 0 0 0 0 0 0 0 IN SINK 0 0 4 0 0 18 0 0 10 0 0 COMB X 0 0 0 0 0 15 0 0 0 0 0 X SINK 21 0 0 0 22 0 0 0 23 0 24 STOPLINE 0 0 0 25 0 0 0 26 0 0 0 ALT UP X 12 13 14 0 16 17 0 18 19 0 20 ALT DWN X 0 0 0 25 0 0 0 26 0 0 0 ASSOCD 1 0 0 0 0 0 7 0 0 0 0 0


September 2005

71

ASSOCD 2 0 0 0 0 0 0 0 0 0 0 0 ------------------------------------------------------LANE DATA------------------------------------------------------------------ ------- metres/second -------> CSPEED 12 15 17 10 16 18 19 10 11 11 13 ------- seconds -------> SATINC 2.0 1.7 1.5 2.0 1.7 1.8 1.5 1.8 1.9 2.0 1.7 STLOST 1.3 1.3 1.7 0.9 1.1 0.8 1.3 0.7 0.7 1.3 1.4 COMTIM 0.0 0.0 0.0 0.0 0.0 17.0 17.0 0.0 0.0 0.0 0.0 LANEWF 1 1 1 9 1 1 1 9 1 1 1 ------------------------------------------------------BONUS DATA----------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK data ------- seconds -------> BONTIM 0 13 0 29 0 21 0 15 BONCUT 0 -4 0 1 0 0 0 0 LANE data ------- vehicles -------> BONBC 11 9 10 0 15 9 12 0 13 0 10 STAGE data ------ seconds -------> LOWMAX 40 40 40 120 60 ------------------------------------------------------DERIVED DATA--------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK derived data -------> MIXOUT 0 0 0 0 0 0 0 0 LANE derived data ------- seconds -------> MAXMIN 15.5 13.0 12.0 13.0 13.0 13.5 11.5 11.5 13.0 14.5 13.0 CRUSIN 10.0 8.0 7.0 0.0 9.5 8.5 0.0 7.0 7.5 0.0 8.0 CRUSX 3.5 2.5 2.5 3.5 2.5 2.0 2.0 3.5 3.5 3.5 3.0 MOVQIN 41.5 41.5 41.5 0.0 53.0 53.0 0.0 24.5 28.0 0.0 35.0 MOVEQX 18.5 18.0 18.0 16.0 18.0 18.0 18.0 16.0 17.0 17.5 18.0 QMINON 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 XOSAT 0 0 0 1 0 0 1 0 0 1 0 ------- vehicles -------> OSATCC 10 9 9 4 11 9 4 8 8 5 9 ------- seconds -------> GAMBER 2.0 2.0 2.5 2.0 2.5 2.5 2.5 2.0 2.0 2.0 2.0 SATGAP 1.4 1.3 1.2 1.4 1.3 1.3 1.2 1.3 1.4 1.4 1.3 CRITG 3.4 3.3 3.2 3.4 3.3 3.3 3.2 3.3 3.4 3.4 3.3 ------------------------------------------------------CONSTANT DATA-------------------------------------------------------------- ------- seconds -------> NDETS SCAN MINEXT MAXEXT ADDGAP SUBGAP 26 0.5 3.0 10.5 0.5 0.5 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK constant data -------> MINPCS 50% 50% 50% 50% 50% 50% 50% 50% SHORTL 0 0 1 0 0 0 1 0 NMAINL 1 2 1 2 1 1 1 1 - - - - - - - - - - - - - - - - ASSESSMENT TIMES - - - - - - - - - - - - - - - - START 6: 0 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 STOP 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 0: 0 telphone number:- 5 5 5 5 5 5 5 220 0 0 0 0 0 0 0 0 ------------------------------------------------------VARIABLES------------------------------------------------------------------ LASTAG SNEXT WARMUP MARKER PREMRK JUNSMF SMCYCL TOTLAM 8 8 -1 1 1 75 990 75 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 STAGE variables -------> STADEM 0 0 0 0 0 LAMBDA 13 13 13 40 20 STCYCL 5 5 5 5 5 MERITV 100 100 100 100 100 DRIFMX 400 400 400 1200 600 ALTLAM 13 13 13 40 20 LINK variables --------> CYCLTM 5 5 5 5 5 5 5 5 LINDEM 1 1 1 1 1 1 1 1 LINGRE 5 5 5 5 5 5 5 5 YVALUE 53 53 26 53 26 20 20 20 LSMFLO 18 36 18 54 18 18 18 18 EXTRAG 5 5 5 5 5 5 5 5 PRENSA 1 1 1 1 1 1 1 1 LANE variable ---------> SMFLOW 18 18 18 18 18 18 18 18 18 18 18 CHECKSUM OF "FIXED" DATA CHKSM1 = 58383 CHECKSUM IS THE SUM OF ALL DATA CHKSUM = 64637


September 2005

72

3.13.7 Example 7 - Linking two MOVA junctions

70m 45m

45m 45m

70m

70m 45m

70m

55m

55m

55m

55m

1 2 3 4

4 3 2 1

11 10 9 8

8 9 10 11

12 13 14

7 6 5

7 6 5

12 13 14

17 18 19 20

20 19 18 17

27 26 25 24

24 25 26 27130m

130m

130m

130m

23 22 21

IN-Dets 28 29 30

IN Dets

28 29 30

IN-Dets 23 22 21

1 2

3 5 4

Junction South East

1 2

3 4

Junction North West

Lane numbers correspond to X det numbers


September 2005

73

In Example 7, a large signalised roundabout is shown with four arms, all of which are signal controlled. The junction is controlled with two separate controllers, each controlling two junctions. Effectively this means the signal phases are fixed from each of the motorway off-ramps to the next downstream junction. The controllers can, however operate separately. The two controllers are perfectly able to accommodate two separate MOVA units and run the two halves of the roundabout separately. However, this may not necessarily be appropriate. If traffic flows are such that there are significant platoons of vehicles between the signals, then it is likely that co-ordinating the signals would be beneficial. Note that there are detectors on the slip roads – the only reason for these being present is to allow analysis of the performance of the complete junction for experimental purposes; being included in MOVA means their occupancy data is included in MOVAs assessment log data. They play no part in the control of the signals, and are not needed for the MOVA control, unless required as IN-SINK detectors. For the sake of clarity, the following MOVA data are extracts from the full data files for each of the junctions. In particular the following issues are exemplified. There are two MOVA data sets for each of the two controllers. The only difference is the TOTALG time. In both cases the time is quite restrictive with the peak-flow time being somewhat higher. The time needs to be restrictive in order to keep the two junctions operating at approximately the same cycle time. Appropriate times are often found by trial and error. At this site there is one ‘master-slave’ arrangement with the Southeast site being the slave and having the priority data. Some priority data relates to links (in this example link 9) and some to stages. There are four parts to the data as described below: SDCODE – the code 4TT (see AG 45, Section 3.7 ’Stage and Phase Data’) applies for link 9, stage 5. This code causes a priority demand to be made for stage 5 whenever there is demand on link 9 (detector 16, see below). The demand is delayed by 5 seconds as given by ‘TT’ = ‘05’. PFACIL- the priority-facility code applies to stages (see AG 45 Section 3.7 ’Stage and Phase Data’).

The code ‘4’ means the stage can be truncated, but not skipped (i.e. it must run if demanded but can be cut to the absolute minimum). This truncation can occur every cycle. The code ‘-5’ allows both truncation and skipping, so the stage can be truncated if it is running when the priority demand appears, or skipped completely if the demand appears before the stage runs. This can occur every cycle. Stage 4 has ‘0’ which means that no priority action occurs in this stage and it will run as a normal MOVA stage. Stage 5 is the stage required by the priority call and has a ‘0’. PRXMAX – this limits the amount of green this stage can run after the normal maximum green time – in this case it is 30 seconds but probably unlikely to reach this due to upstream movements (see AG 45 Section 3.7 ’Stage and Phase Data’). LTYPE – is ‘99’ for link 9 to indicate where the priority demand will come from (AG 45 Section 3.8 ’Link Data’). EPDET - is the detector number associated with the priority link (in this case just one detector) (see AG 45 Section 3.8 ’Link Data’) EPEXT – the amount by which the stage is extended by a vehicle running over a detector (see AG 45 Section 3.8 ‘Link Data’) HOLDTM – the minimum length of the stage after being called by priority action (see AG 45 Section 3.8 ’Link Data’). With the data set as given, the Northeast junction will cause stage 5 to run at the Southeast junction at an appropriate offset. The demand for the stage is generated by connecting the phase confirm for link 5 (lanes 6 and 7) for the Northeast junction.


September 2005

74

MOVA DATA - Example Site 7 Time of day plan changes have to be synchronised for both junctions. In this case it is not vital that the changes occur at precisely the same time, but it may be important at other sites, especially if the master-slave arrangement was being reversed time of day changes in data sets 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 24:00 | | | | | | | | | | | | | SAT 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 SUN 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 22222222 MON 22222222 22222222 22222222 22211111 11111112 22222222 22222222 22222211 11111111 11222222 22222222 22222222 TUE 22222222 22222222 22222222 22211111 11111112 22222222 22222222 22222211 11111111 11222222 22222222 22222222 WED 22222222 22222222 22222222 22211111 11111112 22222222 22222222 22222211 11111111 11222222 22222222 22222222 THU 22222222 22222222 22222222 22211111 11111112 22222222 22222222 22222211 11111111 11222222 22222222 22222222 FRI 22222222 22222222 22222222 22211111 11111112 22222222 22222222 22222211 11111111 11222222 22222222 22222222

North West site stage and link data STAGES NLANES NLINKS MAINST TOTALG 4 14 8 1 75 (seconds) OPTYPE DETON STAGON PHASON STGDEM 1 0 0 0 1 1------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 2 2 0 0 0 2 2 2 2: 0 2 2 2 0 2 2 2 3: 0 2 2 2 2 2 0 0 4: 2 2 0 0 2 2 0 0 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 5 0 6 6 7 0 8 8 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 1 123 0 0 0 123 1 1 2: 0 0 0 0 0 0 0 0 3: 0 0 1 1 1 0 0 0 4: 0 0 0 0 0 0 0 0 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 25.0 7.0 11.0 7.0 MAX 80 20 40 20 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 7 7 5 2: 5 -1 5 5 3: 7 7 -1 5 4: 7 7 5 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 0 0 0 0 EMXMAX 0.0 0.0 0.0 0.0 PRXMAX 0.0 0.0 0.0 0.0 1------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 0 0 0 ------- seconds -------> LMIN 7.0 7.0 7.0 7.0 7.0 7.0 7.0 7.0 LLATOT 2 1 2 2 2 1 2 2 LLANES 1 13 12 10 8 6 5 3 1 2 14 0 11 9 7 0 4 2 3 0 0 0 0 0 0 0 0 ------- seconds -------> ESLMAX 100 160 60 60 60 160 100 100 LOSTIM 12 12 12 12 12 12 12 12 STOPEN 25 10 15 15 25 10 15 15 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 0 0 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 EPDET(2) 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 CANDET 0 0 0 0 0 0 0 0


September 2005

75

South East site stage and link data STAGES NLANES NLINKS MAINST TOTALG 5 14 9 2 65 (seconds) OPTYPE DETON STAGON PHASON STGDEM 1 0 0 0 1 1------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 2 2 0 0 0 2 2 2 0 2: 0 2 2 2 0 2 2 2 2 3: 0 2 2 2 2 2 0 0 2 4: 2 2 0 0 2 2 0 0 0 5: 0 2 2 2 0 2 2 2 2 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 6 0 7 7 8 0 9 9 7 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 1 0 0 0 0 0 0 0 0 2: 0 113 311 311 0 113 311 311 0 3: 0 0 0 0 1 0 0 0 0 4: 0 0 0 0 0 0 0 0 0 5: 0 0 334 334 0 0 334 334 405 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 7.0 1.0 7.0 7.0 1.0 MAX 30 50 40 20 30 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 7 7 5 7 2: 5 -1 5 5 0 3: 7 7 -1 5 7 4: 7 7 7 -1 7 5: 5 0 5 5 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 4 -5 4 0 0 EMXMAX 0.0 0.0 0.0 0.0 0.0 PRXMAX 0.0 0.0 0.0 0.0 30.0 1------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 0 0 0 99 ------- seconds -------> LMIN 7.0 7.0 7.0 7.0 7.0 7.0 7.0 7.0 1.0 LLATOT 2 1 2 2 2 1 2 2 0 LLANES 1 6 5 3 1 13 12 10 8 0 2 7 0 4 2 14 0 11 9 0 3 0 0 0 0 0 0 0 0 0 ------- seconds -------> ESLMAX 100 160 60 60 60 160 100 100 0 LOSTIM 10 10 10 10 10 10 10 10 0 STOPEN 25 10 15 15 25 10 15 15 0 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 0 0 16 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 EPDET(2) 0 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 CANDET 0 0 0 0 0 0 0 0 0


September 2005

76

3.13.8 Example 8 – Linked MOVA

40m

1

95m

21211

15m 3

40m 106m

1445

640m

91m 16

88m 40m

15144

5

3

12

6

16

40m

95m

40m 120m

40m

92m 13

1211

1 2

3 4

21

3

Lane numbers correspond to X det numbers

N

26 26

23Combx 15


September 2005

77

In example 8, there are two separately controlled MOVA junctions close together (about 100m apart). The junction operates a single master-slave arrangement with the western junction being the slave. Shown below are the link, lane and detector data for the two junctions. Example 7 describes the priority data as used when linking two MOVA sites. In this case, the main difference is that the SDCODE ‘4’ is used for link 9 (the priority link) to demand stage 1. The ‘4’ gives an unlatched demand for the stage, unless the link is already green.


September 2005

78

MOVA DATA - Example Site 8 West (slave) junction MOVA data MOVA DATA ULV-SL4A.D2 14:59 23/12/2002 ------------------------------------------------------JUNCTION DATA-------------------------------------------------------------- STAGES NLANES NLINKS MAINST TOTALG 3 6 9 1 50 (seconds) OPTYPE DETON STAGON PHASON STGDEM 0 1 0 0 1 ------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 1 1 0 1 0 0 2 0 1 2: 0 0 0 0 0 2 2 1 0 3: 0 0 1 0 1 2 0 0 0 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 0 0 0 0 0 -1 -1 0 0 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 1 1 0 1 0 0 12 0 4 2: 0 0 0 0 0 0 0 1 0 3: 0 0 1 0 1 12 0 0 0 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 18.0 5.0 7.0 MAX 60 5 60 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 10 8 2: 7 -1 8 3: 7 9 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 0 0 4 EMXMAX 0.0 0.0 0.0 PRXMAX 20.0 0.0 0.0 ------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 31 30 29 99 ------- seconds -------> LMIN 7.0 7.0 7.0 7.0 7.0 5.0 5.0 5.0 7.0 LLATOT 1 1 1 2 1 0 0 0 0 LLANES 1 1 2 3 4 6 0 0 0 0 2 0 0 0 5 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 ------- seconds -------> ESLMAX 60 60 60 60 60 0 0 0 0 LOSTIM 20 20 20 20 20 0 0 0 0 STOPEN 20 20 10 20 10 0 0 0 0 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 0 0 22 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 EPDET(2) 0 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 20.0 CANDET 0 0 0 0 0 0 0 0 0


September 2005

79

------------------------------------------------------DETECTOR DATA-------------------------------------------------------------- LANE NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X 1 2 3 4 5 6 DX 40 40 40 40 40 40 IN 11 12 13 14 15 16 DIN 120 120 92 88 88 95 DSHORT 0 0 0 0 0 0 OUT 0 0 0 0 0 0 IN SINK 0 0 0 0 0 0 COMB X 0 0 0 0 0 0 X SINK 0 0 0 0 0 0 STOPLINE 0 0 23 0 0 26 ALT UP X 11 12 13 14 15 16 ALT DWN X 0 0 0 0 0 0 ASSOCD 1 0 0 0 0 0 0 ASSOCD 2 0 0 0 0 0 0 East (Master) junction data MOVA DATA ULV-SL5B.D2 10:49 24/12/2002 ------------------------------------------------------JUNCTION DATA-------------------------------------------------------------- STAGES NLANES NLINKS MAINST TOTALG 4 6 10 1 50 (seconds) OPTYPE DETON STAGON PHASON STGDEM 0 1 0 0 1 ------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 1 1 0 1 0 0 0 0 2 0 2: 0 0 0 0 0 0 2 1 2 0 3: 0 0 0 0 0 1 2 0 2 0 4: 0 0 1 0 1 0 2 0 0 1 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 0 0 0 0 0 0 -1 0 -1 0 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 1 1 0 1 0 0 0 0 123 0 2: 0 0 0 0 0 0 0 1 0 0 3: 0 0 0 0 0 1 0 0 0 0 4: 0 0 1 0 1 0 123 0 0 1 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 20.0 5.0 7.0 7.0 MAX 60 5 7 60 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 12 7 6 2: 8 -1 8 11 3: 5 8 -1 6 4: 7 8 8 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 0 0 0 0 EMXMAX 20.0 20.0 20.0 20.0 PRXMAX 20.0 20.0 20.0 20.0 ------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 23 31 30 29 22 ------- seconds -------> LMIN 7.0 7.0 7.0 7.0 7.0 7.0 5.0 5.0 5.0 1.0 LLATOT 1 1 1 2 1 0 0 0 0 0 LLANES 1 1 2 3 4 6 0 0 0 0 0 2 0 0 0 5 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 ------- seconds -------> ESLMAX 60 60 60 60 60 0 0 0 0 0 LOSTIM 21 21 21 21 21 0 0 0 0 0 STOPEN 20 20 10 20 10 0 0 0 0 0 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 0 0 0 0 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 EPDET(2) 0 0 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 CANDET 0 0 0 0 0 0 0 0 0 0


September 2005

80

------------------------------------------------------DETECTOR DATA-------------------------------------------------------------- LANE NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X 1 2 3 4 5 6 DX 40 40 15 40 40 40 IN 11 12 0 14 0 16 DIN 95 95 0 106 0 91 DSHORT 0 0 999 0 80 0 OUT 0 0 0 0 0 0 IN SINK 0 0 0 0 0 0 COMB X 0 0 0 15 0 0 X SINK 0 0 0 0 0 0 STOPLINE 0 0 0 0 0 26 ALT UP X 11 12 0 14 0 16 ALT DWN X 0 0 0 0 0 0 ASSOCD 1 0 0 0 5 0 0 ASSOCD 2 0 0 0 0 0 0

3.13.9 Example 9 – A bus priority site

SVD (to detect buses)

3

13

17

1 2

11

6 4 5

14 16

21

22 23

24

1 32

18

19


September 2005

81

Example 9 shows a bus priority site with buses on three of the approaches and two (conflicting) stages. The priority links in this case are 7 and 8, which run in stage 1 only, and link 9 which runs in both stages 2 and 3. The SDCODEs are ‘1’ for links 7 and 8 which enters a latched demand for them whenever the selective vehicle detectors (SVDs) are activated. This will be in addition to the normal demands that will be inserted by the IN and X detectors. Link 9, on the other hand, has an SDCODE of ‘3’ which demands stage 3. If the bus manages to clear the junction in stage 2, it will no longer demand stage 3 as it is not needed. The demand for the stage can be cancelled (as can the priority action itself) when the bus activates the cancel detector number 24. Stages 1 and 2 have a PFACIL code ‘5’ which which allows truncation of those stages in every cycle. Stage skipping is not allowed. The PFACIL code for stage 3 is ‘-5’ which allows both truncation and skipping every cycle (see AG 45). Stages 1 and 2 have been given PRXMAX values of 30 seconds (which allow the stages to run for up to 30 seconds after any normal maximums have expired), (Section 3.5).

Link 7 has one EPDET number 21. Associated with this link is the HOLDTM value of 18s, which ensures the stage runs for a minimum of 18s once the priority detector has been activated. Any further activations of the SVD will extend the stage by 11s. These values have been chosen to allow buses to clear the junction before any stage changes. Link 8 operation is similar in principle but with slightly different timings (because the SVD is closer to the stopline). Link 9 is again similar to links 7 and 8, but this time a cancel detector is employed. This cancels the priority action mainly to cancel the requirement for stage 3 if the bus has cleared in stage 2. In practice, the PFACIL codes were varied to arrive at a workable solution. In particular, it was necessary to try codes that prevented priority action if oversaturation was occurring or to avoid giving priority every cycle. This was because oversaturation meant that buses were unable to reach their SVDs to activate priority action, and were not always seeing any overall benefit.

MOVA DATA - Example Site 9 MOVA DATA BP2529.D1 12: 3 24/12/2002 ------------------------------------------------------JUNCTION DATA-------------------------------------------------------------- STAGES NLANES NLINKS MAINST TOTALG 3 6 9 2 150 (seconds) OPTYPE DETON STAGON PHASON STGDEM 1 1 0 0 1 ------------------------------------------------------STAGE DATA----------------------------------------------------------------- LGREEN(Link,Stages) LINK HAS RED WHEN ARRAY ENTRY IS 0 STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 1: 0 0 1 0 0 1 1 1 0 2: 2 4 0 1 1 0 0 0 4 3: 2 3 0 0 0 0 0 0 3 LPHASE(Link) LINK HAS GREEN DURING STAGE-TO-STAGE INTERGREENS IF PHASE IS NON-ZERO NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------- 4 4 0 0 0 0 0 0 4 SDCODE(Link,Stage) DEMANDS DEMAND ON STAGE LINK NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------------------------------------- 1: 0 0 1 0 0 1 1 1 0 2: 13 0 0 1 1 0 0 0 0 3: 0 22 0 0 0 0 0 0 3 MIN & MAX GREENS in seconds STAGE= 1 2 3 4 5 6 7 8 9 10 MIN 7.0 7.0 3.0 MAX 75 75 35 CHANGE(to Stage,from Stage) Interstage times in seconds TO STAGE FROM 1 2 3 4 5 6 7 8 9 10 STAGE 1: -1 7 7 2: 7 -1 4 3: 7 8 -1 Emergency & Priority Link Data (MAXs in seconds) PFACIL 5 5 -4 EMXMAX 0.0 0.0 0.0 PRXMAX 30.0 0.0 30.0


September 2005

82

------------------------------------------------------LINK DATA------------------------------------------------------------------ LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LTYPE 0 0 0 0 0 0 99 99 99 ------- seconds -------> LMIN 7.0 7.0 7.0 7.0 7.0 7.0 7.0 7.0 7.0 LLATOT 1 1 1 1 1 1 0 0 0 LLANES 1 1 2 3 4 5 6 0 0 0 2 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 ------- seconds -------> ESLMAX 95 95 75 75 75 75 0 0 0 LOSTIM 12 13 15 15 15 15 0 0 0 STOPEN 10 10 9 9 9 7 0 0 0 Emergency/priority vehicle data - EXTensions & HOLDs in seconds LINK NUMBER= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 EPDET(1) 0 0 0 0 0 0 21 22 23 EPEXT(1) 0.0 0.0 0.0 0.0 0.0 0.0 11.0 9.0 12.0 EPDET(2) 0 0 0 0 0 0 0 0 0 EPEXT(2) 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 HOLDTM 0.0 0.0 0.0 0.0 0.0 0.0 18.0 16.0 18.0 CANDET 0 0 0 0 0 0 0 0 24 ------------------------------------------------------DETECTOR DATA-------------------------------------------------------------- LANE NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X 1 2 3 4 5 6 DX 47 47 43 43 43 40 IN 11 0 13 14 0 16 DIN 101 0 93 93 0 85 DSHORT 0 65 0 0 55 0 OUT 0 17 0 0 0 0 IN SINK 2 0 0 5 0 0 COMB X 0 0 0 0 0 0 X SINK 0 0 18 0 0 0 STOPLINE 0 0 19 0 0 0 ALT UP X 11 0 13 14 0 16 ALT DWN X 0 17 0 0 0 0 ASSOCD 1 0 0 0 0 0 0 ASSOCD 2 0 0 0 0 0 0 ------------------------------------------------------LANE DATA------------------------------------------------------------------ ------- metres/second -------> CSPEED 12 12 11 11 11 10 ------- seconds -------> SATINC 2.1 2.3 2.0 1.8 2.3 2.2 STLOST 1.5 3.0 1.8 1.5 1.5 1.0 COMTIM 0.0 0.0 0.0 0.0 0.0 0.0 LANEWF 1 1 1 1 1 1 ------------------------------------------------------BONUS DATA----------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK data ------- seconds -------> BONTIM 26 0 18 18 0 0 0 0 0 BONCUT -4 0 -6 1 0 0 0 0 0 LANE data ------- vehicles -------> BONBC 14 0 10 12 0 0 STAGE data ------ seconds -------> LOWMAX 75 75 35 ------------------------------------------------------DERIVED DATA--------------------------------------------------------------- Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK derived data -------> MIXOUT 0 2 0 0 0 0 0 0 0 LANE derived data ------- seconds -------> MAXMIN 17.0 20.0 15.0 13.5 17.0 14.5 CRUSIN 8.0 0.0 8.0 8.0 0.0 8.0 CRUSX 3.5 3.5 3.5 3.5 3.5 3.5 MOVQIN 33.5 0.0 30.5 30.5 0.0 28.0 MOVEQX 20.0 23.0 18.0 17.0 20.0 17.5 QMINON 6.0 6.0 6.0 6.0 6.0 6.0 XOSAT 0 1 0 0 1 0 ------- vehicles -------> OSATCC 8 5 8 9 5 7 ------- seconds -------> GAMBER 2.0 2.0 2.0 2.0 2.0 2.0 SATGAP 1.4 1.5 1.4 1.3 1.5 1.5 CRITG 3.4 3.5 3.4 3.3 3.5 3.5


September 2005

83

------------------------------------------------------CONSTANT DATA-------------------------------------------------------------- ------- seconds -------> NDETS SCAN MINEXT MAXEXT ADDGAP SUBGAP 30 0.5 3.0 8.5 0.5 0.5 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LINK constant data -------> MINPCS 50% 50% 50% 50% 50% 50% 50% 50% 50% SHORTL 0 1 0 0 1 0 0 0 0 NMAINL 1 1 1 1 1 1 0 0 0 - - - - - - - - - - - - - - - - ASSESSMENT TIMES - - - - - - - - - - - - - - - - START 6: 0 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 STOP 7:30 9: 0 10:30 12: 0 13:30 15: 0 16:30 18: 0 19:30 21: 0 22:30 0: 0 telphone number:- 0 1 3 4 4 7 7 0 4 8 7 210 0 0 0 0 ------------------------------------------------------VARIABLES------------------------------------------------------------------ LASTAG SNEXT WARMUP MARKER PREMRK JUNSMF SMCYCL TOTLAM 8 8 -1 1 1 75 990 75 Link/Lane/Stage NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 STAGE variables -------> STADEM 0 0 0 LAMBDA 41 41 19 STCYCL 5 5 5 MERITV 100 100 100 DRIFMX 750 750 350 ALTLAM 41 41 19 LINK variables --------> CYCLTM 5 5 5 5 5 5 5 5 5 LINDEM 1 1 1 1 1 1 1 1 1 LINGRE 5 5 5 5 5 5 5 5 5 YVALUE 60 60 41 41 41 41 41 41 60 LSMFLO 18 18 18 18 18 18 0 0 0 EXTRAG 5 5 5 5 5 5 5 5 5 PRENSA 1 1 1 1 1 1 1 1 1 LANE variable ---------> SMFLOW 18 18 18 18 18 18 CHECKSUM OF "FIXED" DATA CHKSM1 = 44205 CHECKSUM IS THE SUM OF ALL DATA CHKSUM = 49345

MCH1542 C Installation Guide for MOVA Implementation

September 2005

84

4. IMPLEMENTATION 4.1 Loop layout and specification 4.1.1 General The traffic-model that is at the heart of MOVA is used to estimate what is happening on street and allows calculations about stops, delays and vehicle positions to be carried out and used towards making effective stage-change decisions. The model takes information from the vehicle detectors in the road to update the model. MOVA has been designed to work with detectors at particular locations based (mainly) on approach speeds. Whilst there is some flexibility as to the exact position of detectors, once they are in position, MOVA needs to know precisely where they are. For example, at a cruise speed of 10 metres/second, an IN-detector can be positioned (in the absence of any other constraints) at between 85 and 105 metres from the stopline. Once the detector has been installed, MOVA needs to know how far from the stopline it is to ±1metre. The model also depends on detecting vehicles individually on a lane-by-lane basis (i.e. it needs to be able to accurately count vehicles). In this respect, MOVA differs from the earlier System-D VA operation, which depended merely on recording the absence

or presence of a vehicle(s). Because of this, it is important to size and position MOVA detector loops to permit accurate counting without missing or double-counting vehicles. With the exception of stopline demand loops all MOVA detectors should be set to medium sensitivity to eliminate the chances of detectors ‘chattering’ and minimise the possibility of a vehicle “straddling” between lanes being counted twice. 4.1.2 Relationship with vehicle speeds Vehicle speeds must be measured before arranging the layout of detector loops, because their position is speed-dependent. The speed required, for every lane, is the 15th percentile speed that is exceeded by 85 percent of cruising vehicles. These speeds are therefore lower than mean cruise speeds. A ‘cruising’ vehicle is one which is not delayed - either by having to slow down for a red traffic light or by being part of a discharging queue. A look-up table relating cruise speeds to detector positioning is given in Figure 4.1, but this is only a guide; please refer to more detail in Chapter 3. For details of measuring cruise speeds using the "MOVASPEED" program, see Chapter 3.


September 2005

85

CRUISE X-detector distance (m) IN-detector distance (m) SPEED Centre of loop to stopline Centre of loop to stopline metres/sec. Ideal maximum Ideal Maximum ■ 3.5 seconds 4.0 seconds 8.0 seconds 10.0 seconds 8.0 33 37 69 85 8.5 35 39 73 90 9.0 37 41 77 95 9.5 38 43 81 100 10.0 40 45 85 105 10.5 42 47 89 110 11.0 44 49 93 115 11.5 45 51 97 120 12.0 47* 53 101 125 12.5 49* 55 105 130 13.0 51* 57 109 135 13.5 52* 59 113 140 14.0 54* 60 117 145 14.5 55* 60 121 150 15.0 125 155 15.5 129 160 16.0 133 165 16.5 137 170 17.0 141 175 17.5 145 180 18.0 149 185 18.5 153 190 19.0 157 195 19.5 161 200 20.0 165 205 20.5 21.0 21.5 22.0 22.5 23.0 23.5 24.0 24.5 25.0

At cruise speeds in excess of 15ms-1 the distance from the stopline for X-detectors may depend more on other factors as described in sub-section 3.8.2

Cruise speeds above 20ms-1 are higher than would normally be expected even on the fastest of roads. Seek expert advice before placing detectors beyond the above distances

* At urban sites, where traffic discharge may be sporadically disrupted, the maximum recommended X-detector distance is 45 metres from the stopline. ■ 10 seconds is an ABSOLUTE maximum that must NEVER be exceeded.

Figure 4.1 Look-up table for MOVA detector loop locations

30

40

70

60

50

Likely cruise speeds for speed limit


September 2005

86

4.1.3 Detector design The size, shape and location of various detector loops used by MOVA is shown in Figures 4.2 - 4.4 Apart from stopline-demand detectors all MOVA loops are used for accurate lane-by-lane counting, and also for measuring the presence time of each individual vehicle as it passes (or stops on) the detector (including the OUT-detector which is not a stopline-demand detector). At the present time, the buried inductive loop is best suited for these purposes. Overhead detectors are generally unsuitable irrespective of where they are mounted, not only because of masking problems, but also because they cannot be set up to give the correct occupancy time for every vehicle passing through the area of detection. One exception is that an infra-red device could be used in place of a loop, as a stopline demand detector if there are over-riding reasons to do so. It should be carefully aimed to ensure it only detects vehicles in the required lane(s). It has been found that, for a given sensitivity, a diamond-shaped loop is best in that it minimises the risk of spuriously detecting unwanted vehicles in adjacent lanes and maximising the chances of detecting straddlers on one and only one detector. When space is particularly restricted the basic diamond shape can be compromised slightly in order to maximise the area of the loop (which is always beneficial, provided vehicles in adjacent lanes are not then detected). (AG 44 Appendix B). Loops of less than 8 metres perimeter (the vast majority) should be 3-turns. Loops of more than 8 metres perimeter should be 2-turns. All diamond loops should be nominally 1.7 metres in the direction of travel. Their lateral dimension varies, and is determined by the positioning of adjacent kerbs, lane lines and carriageway-dividing lines. The gaps between the point of the diamond and an adjacent lane line or carriageway dividing line should be 0.8 metres and 0.6 metres respectively (see Figure 4.2). If vehicles are guided solely by the lane markings the above dimensions are probably

optimum, but it is important to watch what vehicles actually do at the loop site. For example, vehicles travelling on the opposite carriageway may pass closer than usual to the carriageway dividing line (e.g. to pass a line of parked cars). In this case, it would be necessary to increase the 0.6 metre gap from loop corner to carriageway dividing line.


September 2005

87

Standard loop design and spacing (all dimensions are metres)

Ensure that placement of loops corresponds to normal vehicular paths

Watch lane discipline!

Figure 4.2 Standard loop design and lateral spacing

Kerb Laneline

C’way dividingline

Loop can be closer than

usual to carriageway

0.8

1.7

0.6

0.4

0.8

0.4

Note


September 2005

88

Figure 4.3 Stopline demand detector loop

STOPLINE

0.4 1.0 Metres

0.6

Carriageway - dividing line


September 2005

89

Figure 4.4 The “OUT” detector

Alternative positionmay be used only if OUT detector

is call / cancel type(see Section 3.8.4)

OUT detector

1 32


September 2005

90

4.2 Ductwork Engineers will be well aware of the issues to be considered when deciding on ductwork but they are repeated here for completeness. Account should be taken of : i) Future maintenance costs, including

the disruption to traffic when carrying out repairs;

ii) The relative ease and speed of

carrying out repairs if ducts are used. MOVA is more tolerant than SYSTEM-D of faulty detectors, since it has alternative detectors and/or historic flow logs to fall back on, and the immediate repair of any failed loops is less critical to effective operation. However, whilst this means repairs can be programmed as normal maintenance rather than emergency work, they will still need the same level of care in installation if maintenance costs are to be kept under control. At a new site, where traffic signals are being installed for the first time, there is one important advantage of using ducts to carry the loop feeders. Accurate cruise speeds cannot be measured until the traffic signals are in operation, because vehicles usually slow down on the approach to signals, even if they are showing green and there is no queue ahead. So there will be some uncertainty about the position of the MOVA detectors. The position of X-detectors is likely to be acceptable even if the cruise speed estimates are somewhat inaccurate, but the position of the IN-detectors, if done in accordance with a ‘guesstimated’ speed, could be significantly in error. Preparing ducts enables the exact position of the IN-detectors to be decided at a later date, when the traffic signals have been operating under interim VA control from the X loops with suitable extension times, before MOVA becomes operational (see Section 4.6). 4.3 Factory acceptance tests In addition to normal tests which would be carried out on the traffic signals, whichever method of signal control was envisaged, the MOVA system specifically requires additional checks of the signals passing from Controller to MOVA (Reply signals) and from MOVA to

Controller (Control signals). If the MOVA system is an "add-on" unit, these signals pass via the UTC interface i.e. are wired up across terminal blocks; with a MOVA-integrated Controller they are more direct (this is an internal function). A third option, known as semi-integral, uses an add-on MOVA unit connected to the controller via a dedicated serial link. In addition, the operation of pedestrian push-buttons must be checked. An example of a Factory Acceptance Test checklist is given at the end of this chapter. 4.3.1 Reply signals MOVA receives these signals from the Controller to indicate, for example, the state of the traffic phases. Checks must be carried out to confirm that the reply signals are being received by MOVA; it is not sufficient to simply check that they are being sent by the Controller. All MOVA systems have a facility available from the main menu to enable the user to see, directly, the status of reply channels and the detector channels feeding into MOVA. Thus it is possible to check : i) Is a signal being received? ii) Is it on the correct channel? iii) Is it the correct polarity? 4.3.1.1 Controller ready bit Check that the Controller returns a "Controller ready bit" (CRB) whenever it is not switched to a higher priority mode. The polarity of the signal is not a user-option; the CRB bit must be in the form of a closed-switch when active (ready to control) and open-switch when not ready to control. The CRB must be received on Channel 32 (16 for MOVA M4 and before) of the MOVA reply channels. Check that the Controller does not return a CRB whenever it is switched to a higher priority mode (e.g. manual). Also check that the mode the controller returns to after a power failure generates the CRB, otherwise MOVA will not come back on control.


September 2005

91

4.3.1.2 Signal reply bits Unlike the CRB signal, the polarity of these signals is optional, although it is virtually universal practice that they should be normally closed, open when active. In any case: i) The polarity of all of them must be the

same. ii) Their polarity must be consistent with

the ‘STAGON’ and ‘PHASON’ flags defined in the MOVA dataset.

iii) Phase confirms are as important as

stage confirms as incorrect confirms can lead to poor control by MOVA .

Under all control modes in which traffic signals can be seen by drivers (e.g. Manual, FT, MOVA, etc) : Stage confirms : Check that signal stages

are confirmed correctly on the UTC reply bits (G1 .. Gn). Check that these signals are received correctly on the MOVA confirm channels 1 to n.

Phase confirms : MOVA generally

requires a confirmation signal for any phases which are green during an inter-stage period, either because they run through two consecutive stages, or because they have an early-start, or phase lag. Prior to factory acceptance testing, it will have been decided which phases need to be confirmed in this way, and on which reply channels they should appear. This information is contained in the "LPHASE" array of the MOVA dataset.

Check that all phases defined by

"LPHASE" data in the MOVA data-set are confirmed on the correct channels.

In conditions in which traffic signals cannot be seen by drivers (i.e. the lamps have failed or been switched off) : Stage confirms : Check that MOVA

receives a G1 plus G2 reply bit. This multiple-stage-confirmation will indicate to MOVA that there is a fault condition.

4.3.2 Vehicle and pedestrian detector signals

All MOVA systems have a facility available from the main menu to enable the user to see, directly, the status of detector channels feeding into MOVA. There is little point in checking vehicle detector inputs at the factory, as these must be checked, in any case, when the Controller is installed on site. However, the pedestrian detectors, as seen by MOVA, should be checked at the F.A.T. The channels on which MOVA should see the various pedestrian demands are defined by the "LTYPE" data in the MOVA data-set. Generally, several push-buttons are used to put a demand on the same MOVA pedestrian link. These push-buttons are normally connected and commoned in the controller (not MOVA) before, in effect, the WAIT lamp signal is output on the UTC interface and connected to the specified MOVA detector channel. Every push-button must be checked individually to ensure that it results in a signal on the appropriate detector channel. Also, check that the demand signal disappears when the pedestrian is served. In the case of a ‘Puffin’ crossing, use of the WAIT signal is essential either as direct input to an unlatched MOVA channel or to corroborate the output from the kerbside detector(s). This allows the demand for a pedestrian phase to be cancelled if the pedestrian goes before the phase appears. (For full explanation, see AG 45 Section 3.8) 4.3.3 Control signals All MOVA systems have a facility available to send, directly, control signals (force bits) from MOVA to the Controller, to allow forced stage changes to occur. When testing in this way, the ‘takeover’ signal is also produced. The takeover signal is normally used to, in effect, confirm that MOVA is operating correctly and is removed when MOVA detects a fault. Check that the Controller always obeys a force signal from MOVA, subject only to the following conditions :


September 2005

92

i) The Controller has a "takeover" signal active (supplied by the MOVA system).

ii) The mandatory minimum green time of

the current stage has elapsed. iii) A stage change which is prohibited in the

controller (or is specified as a 'via' move) is disallowed.

Check that the Controller does not obey force signals when the ‘takeover’ signal is absent. To test this, disconnect the TO wire temporarily whilst forcing a stage. 4.4 Configuring the Controller 4.4.1 Controller versus MOVA clock At some sites, different stage sequences are required to run at different times of day, or different days of the week. If so, the Controller time plans should be set up under VA fallback mode only. Under MOVA control, the Controller specification must be set up to allow all stages which ever run, and all stage changes which are ever made, at any time, to be permissible at all times in MOVA mode. The changes in stage sequence are enforced by the MOVA data set, not by the Controller configuration. Otherwise, problems will occur due to differences in the Controller clock and MOVA's clock; MOVA may try to change to a stage, which the Controller does not allow at that time, and MOVA will detect a fault condition, and drop off control. 4.4.2 MOVA/Controller interface signals In cases where MOVA is implemented using an add-on unit fitted to a signal Controller (excluding semi-integrated), all of the stage

and phase connections between MOVA and the Controller are via the UTC interface (see Figure 4.5). The Controller specification forms include a UTC interface data sheet where the signals between Controller and MOVA are specified. For example, a three stage junction where phases B and F overlap (Table B). TO is the "take-over" signal which is received on the UTC interface from channel 12 (10 in MOVA M4 and before) of the MOVA unit; for consistency, it is specified as channel 12(10) on the UTC interface. CRB is the Controller ready bit, which is sent to channel 32 (16 in M4) of the MOVA unit; again, for consistency, it is specified as the same channel number on the UTC interface. PB and PF are the confirmation signals for phases which are green during an inter-stage period, either because they run through two consecutive stages, or because they have an early-start, or phase lag. The phases, which must be specified, and the channels on which they should appear, must correspond to the "LPHASE" data in the MOVA data-set. For example, referring to the table above, if the green time of MOVA link numbers 2 and 5 correspond to Phase B, and the green time of MOVA link 3 corresponds to Phase F, then the LPHASE array in the MOVA data set would be as shown in Table C.

Green confirmation for links 2 and 5 appear on channel 4 of the reply word. Green confirmation for link 3 appears on channel 5 of the reply word.

Table B – Control and Reply words

Table C – LPHASE values Link number 1 2 3 4 5 6 7 8 9 10 11 12 LPHASE 0 4 5 0 4 0 0 0 0 0 0 0

Bit No. (Channel) 1 2 3 4 5 6 7 8 9 10 11 12 13 32

Control bits F1 F2 F3 HI To

Reply bits G1 G2 G3 PB PF CRB


September 2005

93

Figure 4.5 Connections between Controller and add-on MOVA

MOVA

DETECTOR

INPUTS

MOVA REPLY

INPUTS

REPLY CHANNEL 1REPLY CHANNEL 2REPLY CHANNEL 3REPLY CHANNEL 4

REPLY CHANNEL X REPLY CHANNEL Y REPLY CHANNEL Z

REPLYCHANNEL 16

MOVA CONTROL OUTPUTS

FORCE CHANNEL 1FORCE CHANNEL 2 FORCE CHANNEL 3 FORCE CHANNEL 4

etc

UTC

INTERFACE

CONT ROL L E R

PEDESTRIAN DETECTORS

(“WAIT” LIGHTS)

G1 G2 G3 G4 etc.

PA PD PF

CRB

F1 F2 F3 F4 etc.

DIRECT TO CONTROLLER

FOR DFM AND VA FALLBACK

MODE. (OPTIONAL)

MMOOVVAA VEHICLE

DETS.

DIRECT INTO MOVA (NOT VIA

UTC I/F)


September 2005

94

4.5 Supply and fitting of MOVA hardware

As already mentioned, MOVA can be • An add-on unit that connects to the

controller via the standard UTC interface,

• A ‘Semi integral’ where MOVA and the

Controller are separate but have a dedicated communication link,

• Integral where the MOVA kernel

software is incorporated into the Controller (although MOVA still effectively remains a separate component).

Detector units can be installed at the loop sites with their signal outputs fed back to the Controller, but it is preferable and more convenient for maintenance purposes to install the detector units within the Controller - IN loops are never that far away to prevent the detector pack in the Controller detecting transitions. The detector units used for MOVA loops should be set to medium sensitivity (one of the most common errors is to set the sensitivity too high, and cause over-counting). The only exception is stopline loops, which are set to high sensitivity to maximise the detection of bicycles. Multi-channel detector units often have problems with cross-talk. As far as possible, they should all be set to different frequencies and loops on the same feeder should be served by the same pack. The detector numbering system can be used to help avoid this (Section 3.8.7). A standard phone line is essential for communicating with the MOVA unit from a base station. This needs to be ordered as soon as possible, because it may take a long time to get a phone line installed. In MOVA M5, it is possible to carry out remote data set downloads. In some cases, although the detectors may be physically connected to the MOVA system, it is necessary to load special software to enable the communication to take effect. This should be checked with the supplier of the MOVA system.

MOVA hardware, and its associated communications software, is available from the signal equipment manufacturers. The software needed will depend on the hardware specified. The types of software which may be required include :

i) Set up software to allow MOVA data

sets to be prepared (e.g. MOVASETUP);

ii) Communications software for two-

way communication between user and the MOVA system, both on-site and via phone line (e.g. MOVACOMMS);

iii) Instation software; (iv) Detector handling software, to

"enable" the communication between the detector hardware and the MOVA software.

4.6 New sites - fall-back mode At a new site, where traffic signals are being installed for the first time, it is an advantage to install X-detectors some time before the IN-detectors, and to operate the signals in VA from the X-detectors alone (an alternative is to use fixed-time operation). This is particularly true if the IN-detector feeders are to be carried in pre-installed ducts. The reason is that the cruise speeds need to be measured when traffic signals are in operation, and these speeds determine the position of detectors. The position of the X-detectors will not be far from optimum if cruise speeds are estimated, whereas the position of the IN-detectors may be far from optimum if the cruise speeds are not measured with the signals operating. In fall-back mode the X-detectors, although primarily intended to serve the MOVA system, can be configured to operate a "pseudo SYSTEM-D" if MOVA ceases to control the signals because a serious error has been detected. In this mode, the X-detectors give a fixed extension time of between about 3.5 and 4.5 seconds. Note that this is intended as a fallback-in-emergency system and may not behave in quite the same way as true D-system VA.


September 2005

95

FACTORY ACCEPTANCE TEST SHEET

ITEM TEST PASS FAIL COMMENTS

1 Modes available from manual panel? Manual: can select all Stages and All Red? MOVA (or UTC if an add-on unit) Manually Selected Fixed Time Normal: VA

Mode Priority (Hurry Calls are highest priority)

Manual MOVA or UTC if an add-on unit

Manually selected FT Normal (which mode?) Check mode on handset and LED display Check function of Stage LEDs in all modes

2

Phase intergreen times from handset: A B C D E F G H I J A - B - C - D - E - F - G - H - I - J - Consistent with MOVA changes matrix values?

3

Check phase minimum values Check phase min values are same as link minimum’s in MOVA – if not, why not?

4

5 Revert Revert in normal mode:

same as revert in MOVA?

Normal Stage Sequence Sequence in normal mode Sequence in MOVA mode If different, OK?

6


September 2005

96

ITEM TEST PASS FAIL COMMENTS Vehicle Actuated Mode Stage Transitions: 0 1 2 3 4 5 6 7 8 0 X 1 X 2 X 3 X 4 X 5 X 6 X 7 X 8 X Permitted moves correct?

7

8 Prohibited moves 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 Check all moves can be achieved:

Indicate any prohibited moves

When leaving MOVA /UTC mode check that demands are inserted for all phases

Check all prohibited moves or ‘vias’ are prohibited in MOVA (can only be done by inspecting MOVA data)

9 UTC mode checks for an add-on MOVA unit

Mode changes when a force is sent? No mode changes when a TO is sent? No mode changes when a force & TO is sent? Yes

- stage Confirm bits all present and correct? - phase confirm bits all present and correct?

- stage Force bits all present and correct? - CRB presence? - CRB operation?

(check using manual panel mode switch)

- check TO actuation changes mode - stage change logic correct? - send multiple forces – OK? - G1/G2 returned when lamps off?


September 2005

97

ITEM TEST PASS FAIL COMMENTS

10 Special Conditioning: Aux LEDs: Higher priority mode LED active when

in UTC/MOVA mode?

Any other requirements specified? Any which would affect MOVA?

11 Detector inputs Detector inputs are correct and operate? Dets have correct functions? (latch, call/cancel) Dets demand/extend the relevant stage? Revert stage if no demands present? Max reversion correct for each phase? Check operation with pd’s all round. Outputs to MOVA correct?

MCH1542 C Installation Guide for MOVA Commissioning

September 2005

98

5 COMMISSIONING 5.1 Introduction This chapter explains how to commission MOVA (assuming the signals have already been commissioned in the fallback mode), what to look for, what problems could arise, how to identify what might be wrong and how to resolve it. The following issues are dealt with: • Pre-commissioning • Switch to MOVA control • After commissioning • Post-commissioning validation • Completing commissioning • Commissioning problems • Error messages Is your Maintenance Contractor present? Commission only with a Signal Engineer and the Maintenance Engineer present, particularly if MOVA is provided by an “add-on” unit, to assist in resolving any problems or specification inconsistencies between the Controller UTC interface and MOVA, and to ensure the Maintenance Contractor will accept responsibility for the installation. Check the Maintenance Contractor is competent to handle MOVA and accept the completed installation, and has the equipment and skills to do so - at a complex installation he may need some additional explanation of how the site operates and/or training to do so (the Health and Safety file should do this!). Before commissioning, check both yourself and the Maintenance Contractor have the appropriate software to connect to and communicate with the MOVA unit, and to amend the dataset; this should be supplied by the manufacturer. Also ensure handsets to access the controller are available. 5.2 Pre-commissioning 5.2.1 Check the Controller and the

installation of an add-on unit: • Is the fallback method of control (usually

VA) OK? Check for any faults in the controller fault log or any operational

faults, which may affect MOVA’s ability to control the junction correctly.

• PSTN: connected and operational? • Check the line for a dial tone • If dial tone present, dial out, for instance

to your office • Get someone to dial you back to check

the two-way operation of the line, to check the site can be contacted by telephone

• (If you don’t know the telephone number of the site, dial to a phone, which displays the number of the incoming call - most mobiles!)

• Configure Instation and check it can contact site

• As well as being taken direct into MOVA (from the other terminal on the pack, or from the input side of the Controller – not from the output side because of the additional delay created), check all the MOVA detectors are also taken into the Controller to be included in the Controller Detector Fault Monitoring (DFM), especially if there is no remote monitoring.

• Check detectors have been installed at the distances specified in the dataset

• Add-on units: Should be hard-wired to the mains via a fused spur, not just plugged in!

• ‘TRN’ cable (if specified) should be installed/connected. A TRN (transmission) cable is used by some manufacturers to connect an add-on MOVA unit to the Controller handset port, enabling remote monitoring of the Controller over the telephone via the MOVA unit.

• Check any enabling software or licence information has been loaded.

5.2.2 Before switching to MOVA

control, check: • Are the detectors operating, and wired in

the correct sense? (see procedure for checking detectors and DETON sections 5.7.2 & 5.7.4, below)

• Check the CRB (Controller Ready Bit – previously referred to as the RTC, Ready To Control bit) is active: on the manual panel, switch the Controller to ‘normal’ mode, then watch the CRB on the MOVA display: when the Controller is switched to manual or manually


September 2005

99

selected VA, the CRB should change state, and should return to its active state when the Controller is switched back to normal.

• Confirm bits - check confirm bits confirm correct stages and phases - may need to insert pedestrian or detector demands (using the detector pack switches) to check all stages.

• Force bits - force stages - watch Controller’s mode indication on handset. Check correct stages are forced.

• TO bit: should have been checked at FAT (see pages 94-95), and should be checked again on site. If no FAT was carried out then these checks must be carried out on site. MOVA is configured to send both a force and TO bit: check that a force alone is not sufficient to change mode, both a force and a TO must be sent to force the Controller into UTC/MOVA mode and force a stage, and that all the stages can be forced - use a handset in the Controller port to watch the Controller mode.

• Check that the Assessment Log and the Hourly Flow Log are switched on if required.

5.3 Switch to MOVA control Only when the above checks have been completed, ‘enable’ MOVA and check that MOVA takes control - MOVA has a warm-up procedure (see AG 45 Section 4.2). The warm-up flag starts at -1, increments upwards by one at each stage change, counting up to the number of stages plus one before taking over. Check that MOVA stays on - serious faults will often be immediately obvious because MOVA will stick and then fail at the end of the first stage, or run stages which have no demands (ensure all the detectors have seen a demand and call all the pedestrian phases). 5.3.1 Check that control is “workable”. • MOVA takes Control? Watch the

manual panel LED (if it is configured), the Controller mode on the handset, or the “On Control”, “Ready”, and “MOVA” flags – see the “LF” Option in the TRL menu

• Stage changes – reference the stage diagrams in TR2210 controller specification forms and know what stage changes to look for.

• Check MOVA Operation - calls appropriate stages, in appropriate sequence (determined by SD codes)

• Leave operational, but only if operation is satisfactory!

After installation, if you wish to commission MOVA immediately, remember that the half-hourly flow log requires a full week to develop a record of backup ‘historical’ data to use in the event of detector failure to enable MOVA to maintain normal operation. 5.3.2 When commissioning, the

supplier should demonstrate: • Detector inputs are connected and

functioning correctly, that packs are not “chattering”, the detector presence time (3 to 5 minutes) and sensitivity. Checking detectors are connected and functioning correctly takes a while, requires patience and suitable traffic conditions and is best done at a quiet time, either before or after commissioning - see post-commissioning checks below.

• Ask the supplier to check DFM timeouts on quiet approaches, to avoid DFM setting detectors permanently active (this should not affect MOVA if you have taken the detector inputs to MOVA from the input side of the Controller).

• Confirms: As each stage runs, MOVA should see the correct stage being confirmed

• CRB bit: Should change state when Controller is switched from “normal” to manual or fixed time modes, and back on when returned to normal mode.

• CRB bit should also come back on after a power outage.

• Forces: Check (carefully!) that MOVA forces the correct stage

• Check that control is “workable”. The Contractor will probably be satisfied when MOVA is operational, and leave you to check operation, on the basis that the dataset (which is the Engineer’s responsibility) controls MOVA operation - make sure that you are satisfied before he leaves site!


September 2005

100

Figure 5.1: Commissioning sheet

TEST PASS FAIL COMMENTS Check confirms:

Each stage and phase receives the correct confirm

Check CRB: • Switch Controller to normal, then watch CRB on MOVA

display: Check it shows “active” • Switch Controller to manual or manually selected VA

CRB should change state to “inactive” • Switch Controller back to normal

CRB should return to its active state • If possible, remove power from controller and check the

mode it returns to, and if CRB returns to active. Otherwise, check the power-up mode specified and check that in this mode CRB is active.

Check Force bits: Check that each MOVA stage force forces the correct Controller stage. Do this at time that a change is not otherwise expected, to ensure it is the force bit which makes the change. Also check that force bits can hold stages beyond when they would otherwise change to ensure they have full control.

MOVA warm-up procedure

Check that MOVA takes control

Check that MOVA stays on

When MOVA is operational, check that: Manual Panel Higher Priority mode LED is on when

MOVA is running Check all pedestrian demands are satisfied Control is correct/workable Assessment Log is switched on Hourly Flow log is switched on

Before leaving site, check: DA and DF logs are starting to accumulate data- need a complete hour to see this Error Log has been “cleared” MOVA clock is correct Save to disk a copy of the CN and DS output for QA purposes MOVA left operational?


September 2005

101

5.3.3 What to look for to understand why MOVA instructed a stage change

See AG 44 Section 4 and AG 45 Section 10.3

• Interstages

♦ Remember that MOVA only demands and holds (“forces”) Stages.

♦ The Controller is responsible for the Intergreen timing.

♦ Interstages must be 30 seconds or less for MOVA version M4.0 and later; this may be 15 or 20 seconds in older versions of MOVA (depending on implementation).

• MOVA has a fixed stage minimum you entered in the dataset, normally the phase and link minimum: remember that MOVA cannot override the Controller phase minimums.

• MOVA has a variable stage minimum to ensure that vehicles between the X loop and stopline can escape in the green - look for “SMIN”, the variable stage minimum, and “LMIN”, the variable link minimum

• MOVA satisfies the fixed then variable minimums

• Beyond the min, MOVA next looks for end of saturation flow (determined by the “SATINC” values) - look for “ESLI” - see AG 44 Section 4.2 and AG 45 Section 9.3.

• After end of saturation flow, MOVA then optimises competing demands - look for “OPT BDR” (see AG 44 Section 4.3 and AG 45 Section 8.8), provided the junction is not over-saturated. If the junction has one or more links over-saturated, MOVA operates in capacity maximising mode (look for “OSAT+ES” messages).

• “ESLMAX” can be used to constrain a link with an overlapping green period, for instance at sites with right turn facilities to set end of saturation on the ahead link that has the overlap without closing the stage, which will not occur until the adjacent right turn link has reached end of saturation (see AG 45 Section 3.8)

• MOVA can change at a stage “max”: this could be the time entered in the dataset or, more likely, it could have reached the

drift-max plus extra-max if the cycle limiting feature is in use - look for “max change” message (see AG 45 Section 10.4)

• MOVA can be constrained by “TOTALG”, the total green time in a single cycle (see AG 44 Section 4.5)

• Did you set up your data set to encourage short cycling? When busy, does it? Look for “CUTMX” >= 1 messages (see AG 44 Section 6.4 and AG 45 Section 10.4 “CUTMX”).

5.4 After commissioning 5.4.1 After switch on: • Check view messages • Check the Error log • Suspect or (24 hours later) faulty

detectors • Clear error log, check error log for faults

thereafter.


September 2005

102

-at end of minimum, optimisation produced an immediate change – “OPT BDR” message -at end of saturation (links 1, 2, 4 and 5; note that link 4 was last to end sat) optimisation made an immediate change – “OPT BDR” message -whilst optimising, balance of benefits and disbenefits changed – “OPT BDR” message -change at end of saturation flow, and some links are oversaturated - “OSAT+ES” message -Stage maximum has been reached – “MAX CHANGE” message, which could be caused by a stage or drift max. Figure 5.2: Endstage Output Message Examples 5.5 Post-Commissioning Validation Post-commissioning validation consists of checking the detectors have been installed correctly and observing traffic and the “View Messages” output to confirm the operation and performance of the dataset. This requires observation of performance in all conditions, including the evening and

morning peaks, during the interpeak and in the off-peak. First, check the detectors – using a laptop connected to the MOVA unit, compare the detector display output by MOVA with vehicles crossing the detectors; it is easiest to check at a quiet time of day.

75 SMIN11 LMIN 0 0 0 0 011 8 8 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0RCX 3 0 4 0 9 0 2 2 2 5 0 0 0 0 0 0 0 0 0 0115 NX 3 ESLI000001 000000 000000 000000 10LA 48 38 0 115 NX 3 11: 9: 2 OPT BDR 0 70 93 CF214 DEM111111 010000 000000 000000 RCX 3 1 5 1 9 0 2 2 2 6 0 0 0 0 0 0 0 0 0 0

180 NX 4 ESLI110010 000000 000000 000000 1LA 41 0 0 2LA253 54 0 3LA 27 43 0 4LA 16 43 0 6LA 14 10 0 7LA 14 10 0 200 NX 4 ESLI110010 000000 000000 000000 1LA 41 18 0 2LA253 74 0 3LA 59 0 0 4LA 59 0 0 6LA 14 30 0 7LA 14 30 0 205 NX 4 ESLI110110 000000 000000 000000 1LA 41 23 0 2LA253 79 0 3LA 59 5 0 4LA 59 5 0 6LA 14 35 0 7LA 14 35 0 205 NX 4 11: 7:33 OPT BDR -4 36 155 CF263 DEM111111 000000 000000 000000 RCX11 4 91011 710 8 1 2 0 0 0 0 0 0 0 0 0 0

160 NX 4 BDR 65 24 111 1LK -13 80 47 4 2LK 129 144 47 10 4LK 149 218 47 7 5LK -12 0 47 16 180 NX 4 BDR 95 25 114 1LK 59 144 47 4 2LK 216 218 47 12 4LK 148 218 47 9 5LK -12 0 47 18 200 NX 4 BDR 36 25 114 1LK -13 80 47 5 2LK -36 0 47 14 4LK 82 160 47 10 5LK 63 72 47 20 220 NX 4 BDR 73 25 114 1LK 56 144 47 6 2LK -37 0 47 16 4LK 146 218 47 11 5LK 112 120 47 22 240 NX 4 11:20:56 OPT BDR 24 25 114 CF238 DEM111111 011000 000000 000000 RCX10 311 3 8 1 610 0 4 0 0 0 0 0 0 0 0 0 0

200 NX 4 ESLI000000 000000 000000 000000 7LA 11 6 0 220 NX 4 ESLI000000 000000 000000 000000 7LA 6 14 0 235 NX 4 ESLI000010 000000 000000 000000 7LA 6 29 0 235 NX 4 8:56: 7 OSAT+ES, PCS 0 0 0 0 0 0 DEM112110 000000 000000 000000 RCX 7 5 6 4 2 716 0 0 0 0 0 0 0 0 0 0 0 0 0 IG: 8 SDEM22022100 00000000 BON 018 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 RCIN13 5 8 0 1 13 1 0 0 0 0 0 0 0 0 0 0 0 0 0

220 NX 6 ESLI001000 000000 000000 000000 1LA 20 18 6 2LA 82 6 6 3LA 34 20 3 4LA 34 20 3 5LA188148 0240 NX 6 ESLI001000 000000 000000 000000 1LA 22 10 6 2LA 15 6 6 3LA 34 1 5 4LA 34 40 5 5LA188168 0260 NX 6 ESLI001000 000000 000000 000000 1LA 14 10 8 2LA 15 26 8 3LA 34 21 5 4LA 34 60 5 5LA188188 0275 NX 6 8:56:41 MAX CHANGE, DMX+MXP= 275 DEM111110 000000 000000 000000 RCX141111 8 0 7 4 0 0 0 0 0 0 0 0 0 0 0 011


September 2005

103

The main part of post commissioning validation is to compare your observations of traffic with the “View messages” output by MOVA: • SDCODE - Watch NX indicator on view

messages screen - you will be able to see which stage MOVA will call next, and any changes as they arise, for instance, in demand for Right Turn Indicative Arrows. Check stage selection, stage sequence selection if there is a choice in your SDCODES, and changing selection before end of stage, particularly at RTIAs. Watch the next stage indicator, “NX” (see AG 45 Section 8).

• Satflow - Whilst the queue is clearing, watch “View Messages” for end of saturation flow indicators on each link (“ESLI”), and if you suspect that they are not correct, adjust SATINC values in dataset (see AG 45 Section 10). SATINC values affect a number of other values, so this may be an iterative process. Careful though, as in busy situations, ‘saturation flow’ can continue (i.e. gaps continue to be small between vehicles) even after true saturation flow ended and trying to adjust for this could lead to premature ending of saturated flow when gaps are only slightly larger than normal.

• ‘SAT’ counter – watch the ‘SAT’ counter message at the start of each stage – normally it will be ‘0’ unless there is congestion. It should reflect the number of consecutive over-saturated cycles for each lane (see OSATCC in the dataset and AG 45 Section 10, AG 45 Section 3.12, SAT message, AG 45 Section 8.4, and OSAT+ES message, AG 45 Section 8.8).

• Cruise Speed - When optimising, watch stage closing for individual vehicles, check that the end of stage output shows an optimised stage-change, and check if the leaving amber was presented too late or too early, if so, re-measure Cruise Speed values and change in them in the dataset (see AG 45 Appendix D).

• Stage maximums • ‘Balance’ - Adjust stop penalties,

effective only during optimisation, and lane weighting factors, effective only

when the lane in question is oversaturated, as necessary.

• “Short Cycling” - If you code the dataset to enable MOVA to short cycle when conditions are appropriate (when bonuses are sufficiently large), does it? Check in the peak hour - watch the OSAT counters, and CUTMX (non zero when short cycling is operating). This may need several peak hours to confirm to your satisfaction (see AG 44 Sections 6.4 and 6.5 and AG 45 Section 9). The first check to make is to see if the data is correct. Check that at least one of the BONCUT values is non-zero

• Emergency/Priority vehicle control - check it works to your satisfaction: It may be ineffective due to some factor you had not anticipated, for instance, junction blocking, or it is unnecessarily or unacceptably disruptive to other traffic.

• Look for any “suspect detectors”, which might indicate a detector or pack problem.

It is insufficient to implement a dataset without checking that operation is satisfactory, and many MOVA sites are not operating correctly because this wasn’t done. Carefully refine the dataset as needed, download and retest as often as necessary to make the junction perform to your requirements. This requires at least a day’s work on site. It is particularly important to check operation throughout both peak periods! Note: However, although continued adjustment of parameters in an attempt to cure apparently poor performance may give the impression that you have dealt with the problem, in fact you may have either seen an improvement purely by chance and/or have caused poor operation during times you are not aware of. Remember, MOVA is complex and altering parameters can have undesirable side effects in addition to the desirable effect that was expected by making a change.


September 2005

104

5.6 Completing commissioning 5.6.1 After post-commissioning

checking: • Prepare “As-built” drawing • After a week or so: Check error log and

look for faulty detectors • Check the Comms with Instation are

OK. • Review fallback mode data: In due

course, check and adjust fallback mode data in RAM, particularly VA phase maximums and maxset timetable change times, on basis of MOVA stage times from DA log.

• Finally, when the dataset is satisfactory, it is necessary with some manufacturers equipment to convert the final RAM dataset to EPROM by supplying a copy on disk to the manufacturer to enable a revised EPROM to be supplied and fitted – often by the Maintenance Contractor. Alternatively, where the dataset is held in non-volatile RAM, it is necessary to make a clear note of the final/current dataset in the Controller log book, keep a copy of the dataset on disk in the Controller, and ensure the Maintenance Contractor has a copy and the ability to download it, or you may have considerable downtime (running fallback mode) in the event of a Controller printed circuit board fault requiring replacement of the board.

Commissioning is then complete and the site can safely be handed over to the Highway Authority and the Maintenance Contractor and routine maintenance can begin. 5.7 Commissioning problems Has the MOVA supplier had all the information he needs to configure the site? To configure and install MOVA, the MOVA supplier needs a site layout diagram showing phase/stage arrangements, a link/lane diagram and loop positions and numbers, a dataset and the TR2210 forms, and for an add-on unit, the Controller Specification. In particular the add-on unit supplier needs all this information; without it, expect problems at commissioning! Another

common problem is that the installer, often a third party sub-contractor, has not read/followed the site specification/diagram. A number of dataset problems tend to recur, and first become apparent at, or immediately after, commissioning (the common mistakes!), as follows. 5.7.1 Phase “Overlaps”: Phases which remain on during an intergreen, for instance, the ahead lanes adjacent to a right turn phase, which remain on through the intergreen before the right turn appears. In the dataset, each link which remains on during an intergreen should have an “LPHASE” value. In the UTC interface, each phase which remains on during an intergreen should have a phase confirm. The value coded in the dataset LPHASE should be the same as the overlapping phase confirm bit number. 5.7.2 Detectors: The most frequent

problems when commissioning MOVA sites:

• Detector Numbering: • Are detectors numbered correctly? A

number may have been used twice. • Are the detector numbers the same on

site as on your drawing and in the data set(s)?

• Check NDETS is equal to, or higher than, the highest number.

• Are detectors connected correctly? • Installer may not have had the correct

site drawing. • Is detector sensitivity OK? • Are detectors functioning correctly? • Are the detector packs functioning

correctly? Look and listen for detector packs chattering; get the supplier to retune the packs and if he does not succeed to your total satisfaction reject the packs and fit ones which don’t chatter – if not completely resolved, this can create spurious stage demands and stages running to the end of the variable minimum (maxmin: see AG 45 Section 3.8), and consequently very poor operation on a intermittent and permanent basis, often difficult to diagnose (look for suspect detectors).

• Check detectors are not being called by vehicles in adjacent lanes/vehicles travelling in opposite directions -


September 2005

105

particularly where on-street parking restricts carriageway half width and drivers cross the centre line, or there are stopline loops and long/fast vehicles turning cross a stopline loop as they leave the junction.

• Check detector operation at quiet times, particularly at busy sites and at sites with a lot of detectors - normally included within the post-commissioning checks, to identify these problems.

5.7.3 Pedestrian inputs: • LTYPE entry for pedestrian link must be

either a detector number or 100+ detector number for ‘PUFFIN’ detectors.

• Inputs must be a mimic of the wait lamp (unless using kerbside detectors).

• If using kerbside detectors as input (version M5 and after), the wait lamp mimic must be connected and specified in the PedConfirm array.

5.7.4 DETON: At add-on installations, the most frequent problem has been determining the DETON status - DETON relates to sense of detectors and is determined by whether the detectors are normally closed or normally open. It should be • Zero if detectors are normally closed

circuit, opening when a vehicle is detected; (the preferred option)

• One if detectors are normally open circuit, closing when a vehicle is detected;

It is normally an option on detector packs as to which sense detectors are, but it is essential that they are all the same sense, including any pedestrian or other non-traffic detectors. 5.7.5 SDCODES: When the correct stages are not being called, or the sequence is not what you expect, having first checked that the detectors are correctly connected, then look to the SDCODES as the problem area.

5.7.6 Others: • When new signals are introduced,

approach speeds on the main road fall significantly, because traffic is no longer in free-flow. X and IN detectors positions based on speeds before signals are introduced give loop positions much too far from the junction, and often loops have to be recut - expensive, particularly because of the extra ductwork which isn’t needed! The solution is to commission the signals fallback VA (often from only X loops at 3.5 second travel distance from, the stopline, with 3.5 to 4.5 second extension times), then measure cruise speeds a few weeks after the signals are switched on and speeds have stabilised, to specify the IN loop positions, and then cut the loops.

• When introducing MOVA at existing signal junctions the tendency has been to omit some of the necessary modifications from the design and/or quotation, e.g. TR2210 prom mods, additional detector packs/backplanes, civils work to cable-up, particularly if the existing junction is not fully ducted, and the ductwork/duct boxes.

• “Premature” End of Saturation: Approaches with two (or more) lanes are often coded as a single link. MOVA determines end of saturation when the first lane reaches end of saturation (see AG 45 Section 2.3, third paragraph, first sentence, and AG 44 A.3). Coding as a single link may not be appropriate, since as soon as the offside lane has cleared, MOVA end of saturation occurs, even though there may still be a considerable flow in the nearside lane. This problem is often obvious; on a dual carriageway, when a queue is regularly and significantly unbalanced (for instance, where the approach is uphill, where there are lorries in the nearside lane, or where there is a short merge taper), then you should consider the possibility of separating the lanes into individual links.

• Controller “Special Conditioning” problems - preferably, there should be no Special Conditioning affecting UTC mode.

• Suspect or faulty detectors? Possibly won’t show straight away.


September 2005

106

• MOVA reverts to or via wrong stage? If continuous, recheck detector connections and detector packs, and if not, look for spurious demands, especially from stopline loops.

• The phone number in the dataset - should be the Instation, not the site number! It also needs to be a real instation that can accept the incoming call, otherwise MOVA tries repeatedly to deliver its message!

Time of day (ToD) plan changes: Unlike D-system VA, MOVA does not normally need plan changes just to deal with changes in traffic by time of day. MOVA has the flexibility built in to cope with that. Hitherto, changes in traffic patterns have been a reason why users have thought, initially, that ToD changes may be needed, only to move on, realise that MOVA can cope with changing flow patterns automatically, and believe that ToD changes are needed only exceptionally. However, there are any number of other reasons why ToD changes might be beneficial. Some examples are:

To vary TOTALG, for example to accommodate pedestrian requirements

To account for noticeably different saturation flows or STLOST by time-of-day/day-of-week

To account for varying proportions of HGVs

To account for varying cruise speeds (e.g. at high speed sites you might want to account for much faster speeds in the ‘dead-of-night’ to help discourage red-running)

To allow different SDCODEs for different stage sequences or just to modify the way stages are called

Where there is bonus data to allow for different dominant/subordinate combinations (i.e. to allow for “Tidal” flows in peak periods).

It is not necessary to change data just because something varies, and you would not want to have to accommodate small variations. However, it is worth considering if the benefits of accommodating changes are large. Considering the benefits of ToD plan changes is often overlooked – the best advice is to know what happens at your

junction during day, night, peaks, off-peaks and weekends. Consider safety as well as junction efficiency. Problems appear at commissioning or within a few weeks, and most problems can be/should be resolved when commissioning and in the extensive post-commissioning checks necessary immediately after commissioning … don’t close the job for at least a fortnight after commissioning. 5.8 Error Messages: Why and

when they occur, what they mean and what to do

MOVA has a relatively comprehensive error checking mechanism which, if the problem is serious, can disable MOVA, so the Controller must have a fall back mode. The fall back mode is usually VA - often run only from the MOVA X loops located at 3.5 second travel distance from the stopline, with 3.5 to 4.5 second extension times, together with any stopline loops. MOVA error conditions are set out in AG 45 Sections 9 and 10. Suspect and faulty detectors: MOVA has its own logic for dealing with detectors not performing as they usually do. “Suspect” detector messages are shown in the view messages output, and “faulty” detectors as shown in the error log, as follows: 5.8.1 Suspect detectors • “View messages” output includes

“suspect detector” message • A detector is declared suspect if it is

permanently on for at least one complete cycle (‘SUS’ is set to 2), or permanently off for a calculated predetermined period that depends on the backup flow value (‘SUS’ is set to 1).

• Suspect detectors can be caused by a pack sticking or chattering, a parked vehicle, etc.

• Normal operation resumes as soon as the detector resumes normal operation.

• When a detector is suspect, either an alternative detector as specified in the data or “historic data” is used to maintain as normal operation as possible (see AG 44 Section 10.2b and DF Log, below).


September 2005

107

• Often appears at commissioning, particularly on quiet approaches - ensure all detectors have changed state, if necessary by pressing the pack reset button, and check that the detector packs are not interfering with each other (chattering - you can often hear this before you see its effect). See AG 44 Section 10, AG 45 Section 9.3 (SUS message) and Section 10.

5.8.2 Faulty detectors A detector is declared “faulty” if it remains either permanently on or off for 24 hours. • Faulty detector messages appear in the

MOVA “error log”. • Faulty detector messages will not be

obvious at commissioning because they do not appear for 24 hours!

• This is one of the few faults that create a phone-home fault report

• Also activates the detector faulty LED which your Maintenance Contractor may note. See AG 45 Section 9.3.2

Suspect detectors: In “View Messages”, look for the “SUS” message: (SUS Messages, which appear at start of stage, show that detectors 2 and 8 are suspect, see Fig 5.3).

Faulty detectors: are identified in the TRL menu Error Log (DE): FAULTY DETECTOR NO 19 AT 14/ 2/97 8:19 FAULTY DETECTOR NO 29 AT 14/ 2/97 8:20

5.8.3 Error log fault messages Many of these are UTC interface/intergreen control issues, particularly likely at Add-on sites: • 30-SEC IG FAILS TO END. OFF-LINE

AT 18/ 6/98 19:18 ERR= 5 MOVA BACK ON-LINE AT 18/ 6/95 20: 2 ERR= 4 MOVA intergreen must be less than 30 seconds:

See range limit of “CHANGE” value, AG 45 Section 3.7.

Any intergreen longer than 30 seconds will cause MOVA to drop off

Usually caused by an Extending All Red or long pedestrian stage change

Unfortunately, it doesn’t help by telling you which intergreen

• MULTIPLE STAGE CONFIRMATIONS -

MOVA STOPPED AT 22/12/98 16:35 The inevitable message if there is a

mains failure and the Controller is configured to send “G1 and G2” reply bit

if lamps are off, and a feature of error logs at part time sites - every time the lamps go off! Together with the “CRB ON” message, it is useful confirmation of when the lamps were on! This message is quite often triggered by maintenance work on the controller/MOVA system.

S4 7:46: 0 SUS01000001 00000000 00000000 00000000 SMF 11 20 10 17 10 15 4 0 0 0 0 0 SMCYC 861 DMX1630 385 670 350 0 0 0 0 MXP 0 DEM000010000000 LAM 5 77 BON 0 0 65 SMIN= 65 LMIN= 0 0 0 0 65 0 0 0 0 0 0 0 RCX= 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 RCIN= 0 65 NX1 ESLI000000000000 ESLA00000000 00000000 65 NX1 7:46: 6 OPT BDR 0 1 20 CF100 DEM010010000000 RCX 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 S1 7:45:44 SUS01000001 00000000 00000000 00000000 SMF 11 20 10 17 10 15 4

Figure 5.3: Suspect and faulty detectors


September 2005

108

• WRONG STAGE SNO= 1 DEM= 2 AT 19/ 5/98 13: 2 ERR= 5

Wrong stage is being confirmed; MOVA has demanded stage 2, but stage 1 has appeared. If this appears at Commissioning, suspect a wiring fault; and can also appear at (an unsuccessful) manual switch on. If a part-time site, is not a fault; as it can appear at lamps off, an inevitable consequence of the Controller resuming control to shut-down.

• STAGE NOT ENDED, S3-1 OFF-LINE

5/ 9/98 16:37 ERR= 5 After dropping a force bit, MOVA waits 5

seconds for the stage confirm bit to end, so invariably a Controller problem (a sticking reed-relay on a reed-buffer board or I/O card), which may initially be an intermittent fault. This is very rare.

• STAGE 1 STUCK FOR 5 MIN 29/ 2/99

1:27 ERR= 0 Usually in the early hours of the morning

when there is no demand, and the site is “at rest” due to an absence of demand; there is no fault and MOVA will take control again immediately there is any demand. (message applies to MOVA M2.9 only)

• PROGRAM ERROR AT 1/ 1/92 0: 0

CODE= 50 RVL= 0 Common at switch on, and an

apparently random event at other times. Usually indicates a program failure, possibly a divide by zero error. MOVA M5 has the ability to log some information when a divide error has occurred. This information should be reported back to TRL for further investigation.

• MPU DET COMMS FAIL, OFF-LINE AT

1/ 5/99 1:10 ERR= 4 FAULTY DETECTOR NO 2 AT 1/ 5/99

1:10 FAULTY DETECTOR NO 12 AT 1/ 5/99



1:10

At add-on units, a communications failure: The MOVA unit cannot see any detector transitions, because of a Comms failure: MOVA couldn’t see detectors changing state, so switched itself off. Usually followed by a convenient list of all the detectors. Clear the Error Log and then check whether MOVA is seeing the detectors changing state - if not, try resetting the unit on the reset switch (but beware - if you are running any RAM datasets they will probably be lost), if it’s an add-on unit, try switching the unit off and on, and if that fails, at some manufacturers sites a software download may be needed from the Instation. If still no joy, call the Maintenance Contractor - it’s probably a hardware fault. • DATE&TIME> 1- 1-1992 0: 0: 0. 0 DAY

NO = 1 At add-on units, a loss of software,

usually requiring a software download from the Instation. The date is always 1-1-92.

• CONTROLLER-READY BIT "ON" AT 3/

3/99 11:22 ERR= 0 Means the Controller Ready Bit (CRB)

went off and came back on at this time, so can mean the Controller lost mains power (a “brown out”), it was switched to manual control, or there was a hardware failure (rare). When the CRB returns, MOVA will restart its “warm up” procedure and take over after a couple of minutes - but it may wait until the start of the next hour to do so!


September 2005

109

At this site, lamps are timetabled to come on at 7.00am, off at 9.30 am, on at 3.30pm, and off at 6.30pm on weekdays, and may come on at any other time if a queue develops. 5.8.4 The error count: The error count increments to 21 in units of 4 or 5 according to which error has occurred (see the examples in the paragraph above –look for ‘ERR=’). The count is decremented by 1 at the start of every hour when MOVA reviews its status and at that time (and at no other time) attempts to regain control, usually successfully, if the error count is less than 20. However, when the count exceeds 19, MOVA will not attempt to regain control, and therefore then requires user intervention to identify and rectify the fault (although it does attempt to ‘phone home’). It is typical

to see a message in the error log that MOVA switched itself off because of a fault, and back on at the start of the next hour (see the first example in the paragraph above) . The error count can be manually reset to zero, but MOVA will not automatically restart until the start of the next hour. The normal way to restart MOVA is to reset the MOVA/VA flag to 1. Another useful way to try to restart MOVA is to change mode on the manual panel from and back to ‘normal’ since this usually restarts the warm-up procedure. See AG 45 Section 6 ’MOVA Flags’ and AG 45 Section 9, especially 9.3.14 ‘MOVA restarted’, and AG 45 Section 10.

MOVA RESTARTED AT 3/ 3/99 7: 2-Lamps went on at 7am, after its warm-up MOVA started 2 minutes later MULTIPLE STAGE CONFIRMATIONS - MOVA STOPPED AT 3/ 3/99 9:33 -Lamps went off at 9.33am, two green bits were sent to confirm lamps off MOVA RESTARTED AT 3/ 3/99 1:15 -Lamps went on in the off-peak (called from queue loops) WRONG STAGE SNO= 1 DEM= 2 AT 3/ 3/99 1:20 ERR= 1 -Lamps off in stage 1 just as MOVA demands stage 2 MULTIPLE STAGE CONFIRMATIONS - MOVA STOPPED AT 3/ 3/99 1:20 -Lamps off after the minimum 5 minute on time – note two messages sent MOVA RESTARTED AT 3/ 3/99 15:32 -Lamps on at 3.30pm, after its warm-up MOVA started 2 minutes later WRONG STAGE SNO= 1 DEM= 2 AT 3/ 3/99 18:33 ERR= 1 -Lamps off in stage 1 just as MOVA demands stage 2 MULTIPLE STAGE CONFIRMATIONS - MOVA STOPPED AT 3/ 3/99 18:33 -Lamps off at 6.33pm, two green bits sent to confirm lamps off

Figure 5.4: An Error Log from a part-time signals site (with explanatory notes)

MCH1542 C Installation Guide for MOVA Maintenance and Fault Finding

September 2005

110

6. MAINTENANCE AND FAULT FINDING

6.1 Introduction 6.1.1 Chapter 6 sets out maintenance

considerations: • The Maintenance Contractor and

Contract responsibilities • Routine Attention and Maintenance • Remote Access and Remote Monitoring • MOVA ‘Phones Home’ • Problems Achieving Remote Access? • Dataset Maintenance • The Assessment Log and Assessment

Periods • The Flow Log • Quality Assurance • Training This chapter discusses maintenance, what is required on a routine basis, remote access to and monitoring of MOVA sites, and what MOVA provides to assist in understanding MOVA performance. 6.1.2 The maintenance contractor: Is

your maintenance contractor competent:

• To assess whether MOVA is

operational? • If MOVA is off, to identify the nature of

the fault? • If the fault is in the cabling between the

Controller and the add-on unit? • To maintain the hardware himself, or is

the manufacturer or a third party Contractor required?

• What if the Maintenance Contractor cannot get a satisfactory response from the add-on manufacturer?

6.1.3 Contract responsibilities: • Is MOVA included in your Contract

Maintenance? • For hardware/software? • Who is responsible for maintenance? • Maintenance Contractor for the

hardware? • Highway Authority for the dataset?

• It is not reasonable to expect the Maintenance Contractor to validate the dataset performance, or whether it is optimum.

6.2 Routine attention and

maintenance Once commissioned to a Highway Authority’s satisfaction, MOVA should require relatively little attention (time spent by the Signal Engineer in subsequent inspection, checking performance and responding to complaints from the public or intervention, unlike VA, which needs periodic review of both phase maxes and maxset appearance times). In the long run MOVA needs much less Engineer time - if the equipment is reliable. The only programmed routine maintenance would occur at a Periodic Inspection; what should the Maintenance Contractor check at a PI? • That MOVA is on • The active dataset, which should be

recorded in the site log book • The error log contents, and take any

necessary remedial action • That the assessment and flow logs are

switched on At any casual or add-hoc inspection, either when visiting or dialling up the site, when first contacting the MOVA unit, the logical sequence to satisfy yourself of operation is as follows: • Controller mode - the most basic check,

useful if you can only access the Controller

• Check MOVA is on - particularly at add-on sites - Watch the manual panel LED (if it is configured), the Controller mode on the handset, or the “On Control”, “Ready”, and “MOVA” flags – see the “LF” Option in the TRL menu

• Check the Error Count - should be zero if no problems

• Check the Error Log - the recent history of errors is shown

• At add-on sites - check RAM dataset still present/active (TRL menu ‘CN’ option)

• Watching VM for a couple of minutes can quickly give comfort that all is well.


September 2005

111

6.3 Remote Access and Remote Monitoring

The Signal Engineer has the ability to dial up a MOVA installation and to check many aspects of its operation (remote access), and many MOVA sites are remote monitored, offering a dial-back facility in the event of certain faults arising. Is Remote Monitoring necessary? It is operationally advantageous, particularly at remote sites, to have automatic dial-back if there has been a failure of MOVA control, particularly because of the difference in performance between MOVA and the fallback mode. On trunk roads, Remote Monitoring is a requirement on roads with a speed limit of 40mph or more (TD 24/97, 2.2.1), and most Signal Engineers seek remote monitoring on remote or critical sites. It is strongly advised that all MOVA sites should be equipped with a PSTN line. The MOVA equipment manufacturers have each taken different approaches to the provision of remote access and remote monitoring, and each manufacturer’s equipment has different capabilities. 6.4 MOVA contacts the Instation If you have a phone line connected to the MOVA unit (many are connected to remote monitoring units), it will let you know when a fault occurs: • If a detector becomes faulty (see faulty

detectors, above) • If the units goes off-line for whatever

reason (see AG 45 Section 9.1) If and when the unit goes back on line, no corresponding confirmation is sent. Customers with only a single phone line may prefer to connect it to a remote monitoring unit rather than to MOVA, to monitor all Controller functions.

6.5 Problems Achieving Remote Access

6.5.1 A number of things can prevent

successful remote access: • No telephone line fitted to the MOVA

unit! • MOVA was left in the TRL menu after a

site visit; with some manufacturer’s equipment, this can prevent remote access, and it will be necessary to revisit the site and properly close the TRL menu with the ‘FI’ command.

• A hardware fault, or mains off. 6.6 Dataset Maintenance – is any

required? If properly commissioned and optimised to suit site conditions, there is no need to review the dataset, unless there has been a significant change in operating conditions or in traffic flows or turning movements. MOVA adjusts stage times and cycle times continuously according to prevailing conditions, and once set up properly, change is only necessary when there are significant changes at the junction. It has been shown that MOVA reacts so well to varying conditions, that if it goes off for any reason and the site reverts to fallback mode, the first indication of the problems is that the public phone in to report uncharacteristic delays/queuing where there was none before. MOVA therefore requires little engineer inspection or intervention, unlike VA, which needs periodic review for both phase maxes and maxset appearance times. In the long run, MOVA needs much less Engineer time than VA.

6.7 Assessment Log and

Assessment Periods The Assessment Log should default to ’on’ at Commissioning. Assessment periods: Additionally to the information automatically stored if the Hourly Flow record is switched on, you can summarise traffic flow, signal stage appearance and average duration time, and MOVA on/off information over “Assessment


September 2005

112

Periods”, specified by you in the dataset (up to 12 periods are available): • Default values already set up in the

dataset are 0600-0730, 0730-0900, etc - 90 minute periods over the working day, of limited value to the Traffic Engineer.

• More practicable periods consisting of hourly periods in the peaks and giving full 24 hour coverage are shown in Fig 6.1

6.7.1 The information output for each

“Assessment Period” is: • The date and assessment time period • XFL: The total flow over all the X

detectors • OCC: The average “occupancy” time per

vehicle in seconds crossing the detectors - the total “occupancy” time (in seconds) over all the X and IN detectors divided by the total number of vehicles counted over those detectors during the assessment period.

• F=1 if MOVA has been running (F shows the alternative dataset number in MOVA M4 and later), F=0 if it has not (and can be used therefore to compare the relative performance of VA and MOVA for the junction as a whole: see AG 45 Section 10).

S/TM Stage appearance/duration information for each stage, the number of times the stage ran, and the average stage duration during that assessment period. For instance, “1=36/15” means

stage 1 ran 36 times for an average duration of 15 seconds during that assessment period. Look for stages not appearing as frequently as expected or not at all. If activated, the Hourly Flow Assessment record provides hourly information for each hour of every day over the preceding month (hour ending): TOTIN: The total flow over all the IN

detectors TOTX: The total flow over all the X

detectors XFL: The total flow over each X detector This assessment log information can, for instance, show when and how often pedestrian crossing stages are used, and how often side road stages appear. The hourly flow data is useful to those requiring traffic count data, giving more detail than a single count of morning and evening peak, including Saturday data and flows per lane, over an entire month. This data, stored in the DA log, is available from the TRL menu DA command and can be saved to disk. If the hourly flow log is on, the log will hold about 10 day’s worth of data. With just the assessment log on, the log can hold about 1 month’s worth. See AG 45 Sections 5, 6 and 8, also AG 44 Section 9.


September 2005

113

In the Dataset, Assessment time can be set as (these are non-default values):

- - - - - - - - - - - - - - - - ASSESSMENT TIMES - - - - - - - - - - - - START 0: 0 6: 0 7: 0 8: 0 9: 0 12: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 STOP 6: 0 7: 0 8: 0 9: 0 12: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 23:59 _______________________________________________________________________ In the TRL menu, call the DA option – data for each hour and each assessment period: Display Assessment log <DA> DA

9/ 6 12:00 TOTIN= 527 TOTX= 512 XFL= 59 118 57 168 45 7 55 3 9/ 6 13:00 TOTIN= 793 TOTX= 771 XFL= 72 167 97 240 74 8 106 7 9/ 6 14:00 TOTIN= 904 TOTX= 867 XFL= 96 196 87 281 110 5 89 3 9/ 6 15:00 TOTIN=1020 TOTX= 994 XFL= 104 176 114 325 145 11 117 2 9/ 6 9: 0-16: 0 XFL= 4106 OCC=0.638 F=1 S/TM 1=274/33 2=23/9 3=245/9 4=37/10 9/ 6 16:00 TOTIN= 999 TOTX= 984 XFL= 87 189 127 312 142 5 101 21 9/ 6 16: 0-17: 0 XFL= 1076 OCC=0.704 F=1 S/TM 1=52/38 2=7/7 3= 44/9 4=16/11 9/ 6 17:00 TOTIN=1074 TOTX=1058 XFL= 94 217 134 319 182 10 91 11 9/ 6 17: 0-18: 0 XFL= 1046 OCC=0.455 F=1 S/TM 1=49/46 2=4/9 3=46/9 4=3/9 9/ 6 18:00 TOTIN=1069 TOTX=1056 XFL= 96 223 128 345 158 8 93 5 9/ 6 18: 0-19: 0 XFL= 900 OCC=0.541 F=1 S/TM 1=52/42 2=3/10 3=49/9 4=7/11

Total count for all IN dets

Total count for all X dets

Counts by lane

Mean detector occupancy/veh

No. of times stage called/average length of stage

6444447444448

Time and date F=1,2,3 or 4=plan active, =0 MOVA off control

Assessment log output Flow log output

Figure 6.1: The Assessment Log


September 2005

114

6.8 Historical Flow Log For each X detector, for every half-hour, MOVA saves a smoothed historical flow per lane measured at the X detector - two thirds of the flow from the same time period last week, and one third of the current half-hour flow, for use next week at this time if the X detector is suspect or faulty - known as the ‘historic’ flow (see AG 44 Section 10.2b). This flow is recorded in the DF Log (flows

shown are divided by 10: so 45 means 450 vehicles per hour rate for the half hour period, and 1 means 10 or less; lanes not in use have 0 entries). (See Fig. 6.2) See AG 45 Section 5, Display Average Flows. In the TRL menu, call the DF option – data for each half-hour:

6.9 Quality Assurance The data in these logs, and other aspects of MOVA records, can be saved to disk or to the Instation, information which is then available for Quality Assurance purposes (to provide proof of consistent performance - useful here is the F=1 indication that MOVA is/has been on!), for any subsequent investigation of junction performance.

6.10 Training MOVA is complex in several respects, including dataset design, communications on-site (especially for dataset downloads), and in hardware maintenance; both Signal and Maintenance Engineers benefit from training to achieve competence and confidence in operation.

DF Enter day number {1=Mon,2=Tue,3=Wed,4=Thu,5=Fri,6=Sat,7=Sun} ? 1 MON LANE Time 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 0:30 7 1 6 1 1 1 0 0 0 0 0 0 0 0 0 0 1:00 5 1 3 1 1 1 0 0 0 0 0 0 0 0 0 0 1:30 4 1 3 1 1 1 0 0 0 0 0 0 0 0 0 0 2:00 3 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 2:30 3 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 3:00 1 1 2 1 1 1 0 0 0 0 0 0 0 0 0 0 3:30 4 1 2 1 1 1 0 0 0 0 0 0 0 0 0 0 4:00 4 1 2 1 1 1 0 0 0 0 0 0 0 0 0 0 4:30 6 1 4 1 1 1 0 0 0 0 0 0 0 0 0 0 5:00 8 1 4 1 1 1 0 0 0 0 0 0 0 0 0 0 5:30 10 2 6 1 1 1 0 0 0 0 0 0 0 0 0 0 6:00 15 4 13 2 1 4 0 0 0 0 0 0 0 0 0 0 6:30 22 8 5 3 1 4 0 0 0 0 0 0 0 0 0 0 7:00 27 11 23 12 1 10 0 0 0 0 0 0 0 0 0 0 7:30 32 26 28 23 1 18 0 0 0 0 0 0 0 0 0 0 8:00 35 39 41 41 1 40 0 0 0 0 0 0 0 0 0 0

etc up to midnight

Figure 6.2: The Flow Log

MCH1542 C Installation Guide for MOVA References

September 2005

115

7. REFERENCES 7.1 General This Guide incorporates, by dated or undated reference, provisions from other publications. Where appropriate, these references are cited at relevant places in the text and the publications listed hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply to this standard only when incorporated in it by amendment or revision. For undated references the latest edition of the publication referred to applies. A number of other relevant publications listed here are for further reference and information purposes. 7.2 Specifications and Instructions MCE0108 Siting of Inductive Loops for

Vehicle Detecting equipment at Permanent Road Traffic Signal Installations

TR 2210/2500 Traffic Signal Controller. 7.3 Other Publications TRL MOVA Traffic Control Manual (AG

44). TRL Guide to MOVA Data Set-Up and

Use (AG 45). TRL Bundle 3 User Guide (for

SATFLOW & MOVASPEED)

MCH1542 C Installation Guide for MOVA History

September 2005

116

8. HISTORY Issue A May 1990 Issue B December 1999 Issue C September 2005 Traffic Signals and Road Lighting Safety Highways Agency Temple Quay House The Square Temple Quay Bristol BS1 6HA

Mike Smith Team Manager Traffic Signals and Road Lighting Safety

Installation Guide for MOVA

Documents

Transcript of Installation Guide for MOVA