NOTE: ARCADY 8, ARCADY 9 and ARCADY 10 include an Entry Lane Simulation feature which allows you to explicitly study the effect of unequal lane usage. The rest of this article refers to EARLIER versions of ARCADY.

The fact that one queue may be shorter than another is necessarily a problem - even one car waiting at a give-way line is enough to ensure that capacity is not being lost. There can however be a problem with some roundabout designs, or flow patterns, which should not be overlooked. Such problems occurs only if there is persistent entry-starvation – the queue in a particular lane is zero or very low when there is queueing in other lane(s). Traffic engineers will be aware that there are a variety of causes of this unfortunate situation (such as restricted exits, heavily uneven flows, inappropriate lane markings), but they all boil down to the fact that spurious “entry capacity” has been provided - in other words, there is potential capacity which cannot be used for a significant proportion of the modelled time period. In cases where zero (or near zero) occupancy of lane(s) is expected to occur at the give-way line, a trivial solution is to ignore the unused part of the roadway, and measure the geometric parameters based on the used part of the roadway. If entry starvation occurs, but the flow on the lightly used lane(s) cannot be described as “near zero” then there are two possibilities:

1. The lightly used part of the approach contains only vehicles turning left (i.e. at the first exit from the roundabout). Again, delete from the model the lightly used part of the roadway and the left-turning traffic using it.

2. The lightly used part of the approach contains straight-ahead or right-turning traffic. This is not so straightforward to handle. The aim would still be to delete the lightly used part of the roadway, but the traffic using it cannot be deleted because that would affect the derived circulating flows, which in turn affects all other entry flows. Several “dummy arm” based solutions have been suggested, but they all have significant deficiencies. A capacity adjustment to the entire approach arm by means of an “intercept correction” is one method of handling this situation. If this correction cannot be measured directly, it will need to be derived by scaling down the full approach capacity by an “appropriate amount” to account for the lost capacity due to entry starvation. Unfortunately, there is no global method of choosing an appropriate amount - it varies from case to case, and will always be a matter of judgement. Therefore caution must always be applied if considering such methods.

ARCADY 8 includes an Entry Lane Simulation feature which allows you to explicitly study the effect of unequal lane usage. The methods above refer to earlier versions of the software.

The arm labelling does make a difference, because if they are labelled incorrectly then the circulating flows past each of the entry arms will be calculated incorrectly.

If modelling a drive-on-the-left roundabout, arms are numbered in a clockwise order. For drive-on-the-right roundabouts, things switch over and arms are numbers in a counter-clockwise order.

In ARCADY 7 and above, arms can be labelled in a more freeform manner. However, the program still needs to know the order of the arms, for the reason given above. In general you don't need to worry about this because the program will set up the correct default ordering for you. If you happen to insert a new arm after having started a file, use the Junction Diagram to check whether the arm is in the correct position relative to the other arms. If the arm is in the wrong position, you can either type in the correct arm order in 'Arm Order' field of the junction, or, alternatively, move the end of the arm to the correct position in the diagram and then click 'Tools>Set roundabout ordering from diagram'.

It may be useful to bear in mind that the ICD is intended to represent the “size of the junction as perceived by an approaching driver”. This is admittedly an imprecise definition, which is why there is no set of precise rules to cover every set of circumstances, when the junction is not symmetrical in its design. But there are a few basic (and as precise as possible) guidelines:

1. Ignore lane-splitting or carriageway-dividing islands. Ignore any lane markings. These details do not have any bearing on the ICD. Delete them from your drawing if it makes it any easier to assess the size of your roundabout. If the roundabout is approximately circular there is no problem - use the measurement method described in the Application Guide. Similarly, if it’s oval there will be two ICDs, and each arm will be assigned to the smaller or larger of them.

2. If the roundabout is a symmetric or unusual in some way, you will need to consider, for each arm, the “size of the junction as perceived by a driver arriving on that arm”. First, it is sometimes useful to use a flexicurve to draw around the outer perimeter of the junction, touching all the kerblines. You don’t need to be too pedantic about this process, because it’s only to give a guide. Examine your flexiline afterwards to see how well it reflects the overall size and shape of the junction - there is usually some trial and error before producing a line that looks “reasonable”. The figure shows this treatment applied to a five-arm large roundabout. Note that all islands and give-way lines have been deleted from the drawing.

Then draw circular curves for each arm, guided by the flexiline but entirely within it, centred somewhere on the central island. Each curve should encompass the arm in question, and should aim to touch the kerb at points closest to the centre of the junction on either side of the arm. For example, in the figure, the ICD for Arm B aims to pass through point AB and BC. Similarly, the ICD for Arm C aims to pass through points BC and CD ... etc. The centres of these curves need not be at the same points on the central island - in the example shown you will see that they’re not. Often, it is not possible for a single radius curve to touch both points whilst remaining within the flexiline - you will need one radius to pass through one point, and another to pass through the other point. In this case, use the smaller radius as the ICD.

Finally, check that the comparative ICDs look correct. For example, in the figure, drivers approach on Arm E in an area where the radius of the junction is relatively large, whereas the radius is relatively small for drivers approaching on Arm D. So Arm E should have a larger ICD than Arm D.

Your data files indicate runs for 2005 and 2012. The 2012 is heavily oversaturated (queues of 700 veh+) and is grade-separated. The flow have been scaled for 2012 (from the base year of 2005). The CIRFLOW values (i.e. the peak 30-minute circulating flow) have been automatically calculated - here lies the problem! The initial automatic calculation of these values does NOT take account of suppressed demand and so the values used in the 2012 case are effectively wrong. The values for this case needs to be manually calculated as described in the Appendix of the Application Guide, taking account of the suppressed demand. The values for 2005 are probably OK. This will remove the effect described - i.e. increased delay in the 2012 case.

While on the subject of the effect of increasing demand flows, it is worth pointing out that increasing flows only on certain entries can have the effect of improving capacity on one or more entries. Let us take, for example, a simple three-arm roundabout where you are interested in the capacity of Arm A. An increase of entry traffic on Arm C will tend to increase the capacity on Arm A simply because traffic passing Arm B will be increased, which in turn, will reduce the capacity available to traffic entering on Arm B. This can reduce the circulating flow past Arm A hence result in an improvement in capacity on this arm. To summarise, if the changes in demand flow results in lowering the circulating flow past a particular arm, then the capacity for that arm will increase.

The difference between these crossing types is most noticeable at low pedestrian flows and where there are also low vehicle flows, as shown in the chart (for medium vehicular flow).  At low pedestrian flows, the vehicular capacity is highest with a zebra crossing.  In this region, if a signalised crossing is being used, a puffin will give better performance than a pelican.  At higher pedestrian flows, using any sort of signalised crossing is the best option, and the difference between a pelican and puffin becomes negligible.  Of course, there are many other considerations such as safety and layout options.

ARCADY and PICADY include "point-to-point journey times" which combine queueing delay at the give-way line, the time taken to negotiate the junction (geometric delay) and also the time to travel in a straight line from a user-defined upstream point to the 'start' of the junction and similarly on the exit. This gives a reasonable estimate for the total time taken, on average, to travel through the junction.

Note that this is only an estimate, because there are some elements of delay which may be counted in both the queueing delay and the geometric delay. For instance, drivers slow down on the approach to a roundabout, and this consists of both slowing down to a safe speed to negotiate the junction, and also decelerating to a speed slow enough to check whether there is a gap on the controlling traffic stream. Because some of the geometric characteristics of the junction contribute to both the geometric delay and also to the empirically derived capacity (and hence queueing delay), it can be seen that there is some overlap between the two types of delay. However, the overlap is usually small.

Figure 3 – Characteristics of a cycle-friendly roundabout

A number of studies have been carried out in the past concerning cycle accidents, and it would seem that the main problem is due to circulating cyclists being hit by vehicles entering the roundabout; these certainly result in the most serious injuries. It would seem that entering drivers sometimes don’t “see” circulating cyclists, or at any rate do not notice them. We need to find out which (if any) design features will help cyclists to be noticed. The aim of the study is to produce design guidelines for roundabouts where cycle “friendliness” is thought to be an important issue. For example, at junctions where there are expected to be a larger than normal number of cyclists, or where cycling is particularly encouraged by other measures on the adjacent road network. However, such treatment would be appropriate only at junctions with low or moderate flow levels, where a roundabout has been installed more as a traffic-calming measure than as a flow-handling measure. Although cycle accident data are insufficient to be able to incorporate a full cycle safety prediction model into ARCADY, it is hoped that it may be feasible to incorporate “rule of thumb” guidance as to the likely cycle-safety of a particular design being modelled. “Continental” design features, so called because they are far more prevalent in continental Europe than in the UK, are being studied in particular. Such designs have minimal traffic weaving because they have single lane entries and exits, and the circulating carriageway tends to be narrower than on conventional UK designs. Also the entry angles tend to be larger, so drivers have a more sudden change of direction at the give-way line, rather than a shallow merge into the circulating carriageway. Older readers may recall that UK roundabouts used to be a bit like this!

I am evaluating a grade-separated roundabout using ARCADY. After comparing runs for 2006 and for 2013 I am getting some results that suggests that despite increased flows in the future one of the approaches actually benefits.Can this be right?

Changes in flows can have this effect for two reasons. Firstly, changes of demand can alter the circulating flows that flow past each arm. This is because when one arm reaches saturation it will not be able to deliver any more traffic while other more lightly loaded approaches can continue to increase their contribution to the circulating carriageway. In turn, this has the effect of changing the turning proportions past each arm and can occasionally result in an improvement despite the general rise of traffic demand on each approach (see diagram). This effect is often not seen simply because the general increase of traffic will often swamp the reduction effect and all the user will see is a smaller reduction in capacity on one arm compared to the reduction on the others.

In this particular example the reason for the improvement is due to a second, entirely different, effect which is specific to large or grade-separated roundabouts. In 2013 the junction is heavily oversaturated with excessive queuing on all approaches. The flows have been scaled up for 2013 from the base year of 2006. The CIRFLO values (i.e. the mean circulating flow past each arm for thecentral 30 minutes of the modelled time period) have been calculated automatically – and here lies the problem! The initial automatic calculation of these values does NOT take account of suppressed demand and so the values used in the 2013 case are wrong. The values for this year need to be manually calculated, taking account of the suppressed demand (see Appendix H of the Application Guide AG49). The values for 2006 may also be wrong and should also be calculated in the same way. This is likely to remove the effect described, i.e. Arm A queues less in 2013 than in 2006.

Remember – Going out on-site and collecting CIRFLO data is the most accurate and robust method. When this is not possible, say, when using predicted data for future years, the calculation of CIRFLOW is a manual iterative process as described in Appendix H. For this situation, ARCADY only works out the values for the first iteration – the rest are up to you. Thankfully the number of iterative steps is usually very small.

This is not as easy as it sounds. This is because the time segments in the internal ARCADY model are not independent; the queues from one segment feed into the queues for the next segment.

ARCADY results include an output titled "Average delay per arriving vehicle", which represents the time taken for an average vehicle to clear the queue. This takes account of the effect mentioned above.

Cyclists have a greater effect on the circulating carriageway than on the entry. Ideally you would like to say that each bicycle is worth 0.2 PCU on entry but, say, 1.0 PCU when on the circulating carriageway. This can't be done - but a workaround can help to achieve a similar result. First, run the model with both 0.2 and 1.0 values. The run that uses 1.0 PCU for a cyclist should then be used, setting the site-specific intercept correction to adjust the capacity of the entries upwards to compensate for the fact that the cyclists have a 0.2 PCU effect rather than 1.0 on the entries. i.e. using the difference in capacity between the two runs.

The slope of the linear capacity relationship cannot be changed in ARCADY hence why you want to use a PCU value for cyclists which is appropriate for the CIRCULATING carriageway. N.B. This should work quite well, but it should be remembered that the site-specific variation is making a FIXED difference in the entry capacities - if the geometries change the difference between the two different PCU runs may change. If significant geometric or flow changes are made the process should be repeated.

If the arm is “in effect” an entry-only arm. You should measure the separation between the centres of the entry and the previous ENTRY (on a previous arm). If the separation is greater than 160 metres, 160 should be entered.

ALL arms of ‘large’ or grade-separated junctions should have a separation distance entered.

When you specify that “Grade Separated Entries passing over/under roundabout” the analysis program uses different capacity relationships from those used normally. They should also be used for large roundabouts (>130 metres). The relationships used are those defined in “The capacity of entries to very large roundabouts” (Marie Semmens, 1988).

The core ARCADY model will give optimistic predictions of the capacity of each individual roundabout of a ring, even if the queues do not interlock. Any interactions between any junctions will have an effect. ARCADY predictions assume that traffic arriving on an approach is free to gain access to the give-way line, thereby being free to take advantage of any gaps which appear in the circulating traffic. Any form of bottleneck on an approach will create “holes” in the arriving traffic, and POTENTIAL gaps in the circulating flow sometimes cannot be taken advantage of; the net result is that a percentage of the POTENTIAL capacity of a give-way line is lost. You need to take some account of these effects in the model, but I’m afraid we cannot quote a figure; it obviously depends on the individual junction.

Fortunately, the Lane Simulation Mode that was introduced in ARCADY 7 and continued through into ARCADY 10 allows you to take account of these "holes" in arriving traffic due to restrictions upstream of the give-way line (in this case another roundabout) and will also take account of the blocking back effects too, if these occur.

As an aside to this question, on the “plus” side, TRL has some anecdotal “evidence” that ring junctions work well, because of its involvement with a trial of one of these junctions many years ago. The first day wasn’t good because drivers didn’t know what they were supposed to do, but subsequently the junction worked very well in terms of capacity.

Even if your data is exclusively in PCU, it’s still a good idea to enter heavy vehicle proportions, even if you just enter an estimate for the whole junction. This is because some parts of the ARCADY model work with PCU and others use vehicles, so the program always needs to be able to convert between vehicles and PCU. If you do not enter HV percentages, there is risk in particular that queue and delay results may not be accurate.

You can see this effect very easily for yourself as follows. Set up a new file, enter some flows in PCU/hr and run the model. Now enter a HV percentage of, say, 50%, and re-run the model. The RFC will stay the same, but the queue and delay values will change. If using Level of Service outputs, these depend on the delay per vehicle, which will increase. Also note that you can choose whether to display results in terms of PCU or Vehicles, independently of the units used for inputs. If comparing before/after results, be careful to use consistent units.

When a roundabout is specified as large, grade separated, or terminates in a dual carriageway or motorway ARCADY uses a slightly different equation to calculate the capacity. This equation uses the two new parameters, Qr (Mean Circulating Flow) and SEP (Separation Distance). The mean circulating flow can, in fact have the effect of either increasing or reducing the capacity – it all depends on the instantaneous value of Qc which is calculated within the model from the demand data and geometric data. If the instantaneous value of Qc is high then the effect of a high Qr is lightly to increase the capacity and vice-versa if Qc is low.

The effect on the entry capacity is thought to be due to drivers behaving according to the conditions they become accustomed to encountering at the junction in question, e.g. if they have to contend with high circulating flows on a regular basis they may be more aggressive towards finding a gap in the traffic.

Measuring queues seems to be the obvious way of checking a model, because queue lengths are one of the main outputs from the programs. In fact some traffic engineers, and their customers, insist on such checks being carried out. If so, they should understand the implications of what they are doing. Apart from the practical difficulties of measuring mean queues over successive time intervals there are also mathematical problems to consider.

During peak periods (when the flow/capacity ratios are high) there is a large daily variation in queue lengths even if the average flow for each time segment does not vary from day to day. To take a typical example, a mean queue of 26 pcu would be derived from queues which varied between 5 pcu and 50 pcu from day to day. In fact, on 1 day in 20 the queue would be outside even this large envelope of possible values. So you can see that many days of queue measurements would have to be taken to obtain a reliable estimate of mean queues. The junction model predictions are based on an infinite number of days! It is surprising how many people think that one day is enough - yet they wouldn’t dream of predicting the result of the next General Election after canvassing one person chosen at random (OK maybe this is a more extreme case!)

The routine within the junction models which calculates mean queues is more accurate than the capacity-predicting routine, which of necessity gives average results which ignore the effects of site peculiarities and location. The queue calculation is almost certainly more accurate than your best estimate of demand flows. So if you do go to the trouble and expense of measuring queues, and find a difference between the model predictions and your observations, then you might pause to consider whether perhaps the model is correct and your queues are not. Even if your measured discrepancy is genuine, you will have achieved nothing other than to demonstrate that the demand flows are inaccurate or that the model’s capacity prediction is not taking account of all the local circumstances. So time would be better spent tackling these issues.

Consider the accuracy of the demand flow estimates in the model (bear in mind that the HOUR profile type (ODTAB in older versions of ARCADY) is the least accurate method of specifying them but the most frequently used). The accuracy of the model’s capacity prediction can be significantly improved by carrying out a “site specific capacity correction” - refer to the Application Guide for details. Such on-site measurements are much easier and cheaper than trying to measure queues properly!

If the flows and capacity-predictions are correct, the queue predictions will be correct.

NOTE: ARCADY 7 onwards provides options for the direct modelling of double roundabouts and other systems of linked roundabouts. This modelling uses approximate methods and is less rigorous than the empirically based core model of ARCADY, but, provides a convenient way to automate the suggestions given below which are aimed at users of previous versions.

Each junction can be modelled separately but the models will always overestimate the capacity of the internal links (C1 and C2 in the diagram). Then there will be a knock-on effect on other traffic streams (A1, B1, A2, B2). The capacity of the internal give-way lines will always be less than that of a similar isolated junction, because the upstream junction creates “holes” in the traffic, and there will not always be vehicles at the give-way line able to take advantage of gaps in the priority traffic.

Having modelled two junctions independently, there is a method of calculating by what percentage (approximately) the capacity of the give-way line has been overestimated. Take, for example, the traffic flowing from Junction 1 to Junction 2. There are two sequential bottlenecks, C2SERVER(1) and C2SERVER(2) each with its own capacity. The “capacity” of the exit from Junction 1 is not related to exit geometry alone; it is simply the actual traffic flow down the exit (after negotiating the capacity restrictions of A1 and B1). The capacity of the give-way line, C2SERVER(2), can be obtained from the independent model of Junction 2 in isolation. Using standard queueing theory, the overall capacity of two sequential bottlenecks can be expressed as some proportion, P, of the capacity of the give-way line alone, where:

P = (R(N+2) – R) / (R(N+2) – 1)

where R is the ratio of the two individual capacities, C2SERVER(1) / C2SERVER(2)

and N is the number of pcus in the internal link (5 pcus in this example) (generally about 1 pcu per 10 metres)

If, for example, the capacity of the upstream bottleneck, C2SERVER(1) = 800 pcu/hour and the capacity of the give-way line,

C2SERVER(2) = 500 pcu/hour

then R = 800/500 = 1.6 ,

and N = 4 pcu (see diagram)

P = (1.66 – 1.6) / (1.66 – 1) = 15.177 / 15.777

so = 0.962

thus the overall capacity of the system

= 500 * 0.962 pcu/hour.

Having revised the capacity of the give-way line, you may find that the queue stretches back to beyond the upstream junction. This is a second type of interaction between two junctions, which the above method does not take into account. You need to study mean queues and queue variability to see if it occurs, but the effect of blocking-back is too random to be capable of a mathematical solution. You have to either manually “guesstimate” the effect or, better still, design the internal links with enough storage capacity to prevent the problem occurring.

How to obtain the values of C2SERVER(1) and the similar C2SERVER(2).

This article says that the value is "simply the actual traffic flow down the exit..." and is likely to be written in response to a real user's enquiry and as such the solution works for that particular situation but not all, i.e. the article is not 'general' enough. EG. The capacity of the Junction 1 'bottleneck' I.e. C2SERVER(1) is the actual traffic flow down the exit, only when there is significant queueing on both A1 and B1. If, for example there was no traffic on arms A1 and B1 the traffic flow on the exit would be near zero and would obviously not represent the capacity of the situation. I have suggested that the entries should be loaded with sufficient entry flows to establish sizeable queues on all entries and that the combined capacities can then be summed to provide a value. Said another way: if the upstream links have a demand flow that does not make full use of the available capacity the downstream links will have capacities which relate to the upstream demand, and as such cannot be summed to get a value for C2SERVER(1). This is because the upstream demand determines the downstream capacities. Note however, that if the combined capacities of the upstream links exceed those expected of the connecting exit link then you have just proved that the need for any capacity adjustment of the downstream entry is probably unnecessary.

Caveat

Please note that this suggested solution has not been subjected to the same rigorous validation that is associated with those features built into ARCADY itself.

ARCADY 7 onwards provide options for setting up entry and exit restrictions on arms, which can be used to model bottlenecks directly.  ARCADY 10 also includes the option of modelling chicanes/build-outs/one-way bridges, and so on.  The advice below is aimed at users of older versions of ARCADY.  

Although a Zebra crossing doesn't have exactly the same effect as any other bottleneck on a vehicle-by-vehicle basis, over the longer term it should be a good proxy.

The formula for the vehicular capacity of a Zebra crossing, as used in ARC/PIC, was first derived by J. D. Griffiths (Transportation Science, Vol 15, No. 3, August 1981). By using this formula (see below) you can fabricate a dummy Zebra crossing with any vehicular capacity you wish (i.e. that of the bottleneck) - the most obvious way of doing this is to adjust the pedestrian flow rate. If you are going to use this technique, it is advisable to create a spreadsheet based on this formula, particularly given the units.

Where :

C is vehicular capacity of Zebra crossing (Vehicles/Second)

U is two-way pedestrian flow on crossing (Peds/Second)

A is mean crossing time of pedestrian (Seconds)

(ARC/PIC assume a mean crossing speed of 1.4 metres/second)

B is mean time headway of vehicles when there are no pedestrians crossing (Seconds) (the reciprocal of vehicles per second saturation flow)

e = 2.7183 (to four decimal places)

One problem is that the bottleneck generally applies to traffic in one direction only. For example, if you insert a dummy Zebra crossing on one arm of a roundabout because of an exit restriction, you will also affect the entry capacity on that arm. Fortunately there is an easy solution:

Model the dummy Zebra as a two-stage crossing with central refuge. Make the distance between the crossing and the junction exit equal to the true value, but the distance between the crossing and junction entry equal to some huge number. In that way, the program assumes that the Zebra is a very long way from the junction entry, and therefore has virtually no effect on entry capacity.

Caveat

Please note that this suggested solution has not been subjected to the same rigorous validation that is associated with those features built into ARCADY itself.

(updated Oct 2008)

If you find that ARCADY or PICADY predicts queues that are significantly different to what you have observed, there are several things to consider:

How reliable are the observed queue measurements?

If queues have been observed on one day only, they may be unreliable because queue lengths have a large daily variability even with the same levels of traffic demand. The queues shown in ARCADY/PICADY are what you would expect to see if you averaged observations from many days. So ideally you should measure queues on several 'typical' days, and average the results. Otherwise, you need to be as sure as you can that the measured queues are a good representation of typical behaviour at the site. (If possible, visit the site to check that the level of queueing roughly corresponds with the queue survey data.)

Has demand been measured correctly?

ARCADY/PICADY need to know the volume of traffic that wants to use the junction - i.e. the demand. This should be measured upstream of any queueing. If, instead, you count vehicles crossing the give-way line, you have measured the throughput instead of the demand. If you enter this as the demand then the predicted queues will be very small, because you will just be telling ARCADY/PICADY that the amount of traffic wanting to use the junction is the same as the amount that you have observed flowing through it.

The most common demand profile type in ARCADY/PICADY is "ONE HOUR". This takes an origin-destination matrix and then assumes that the traffic rises and falls in a specific way over a 90-minute period, to represent a typical peak period. This often gives reasonable results, but relies on a number of assumptions that may not be true at your junction. Alternatively, you can directly enter the demand for each time segment.

Are geometries correct?

Check that the geometries have been measured and entered correctly. If there is unequal lane usage, for example if traffic on one or more arms consistently uses one lane more than another, then consider using Lane Simulation mode.

Check units and other options

Check that the correct units are being used (e.g. PCU/hr versus PCU/time segment) and that you don't have any scaling factors or other options accidentally switched on.

Consider applying calibration factors (intercept adjustments)

If all else fails then you can apply factors to calibrate the model. Usually this is via intercept adjustments applied to one or more arms. These adjust the capacity predicted by the model up or down by an amount you specify - e.g. -75 PCU/hr to reduce the predicated capacity by 75 PCU/hr. If you have measurements of the throughput on the arm, under saturated conditions (i.e. whilst there is queueing) then you can use these to directly calculate a correction, using the Calibration screen. This is considered the best method you can employ.

Alternatively you can find intercept corrections by a process of trial and error. Corrections are intended to account for factors at the junction which make the junction different to the 'average' junction with the same geometries, such as poor visibility, gradient, driver hesitation, unusual layout, and so on. Usually these factors apply at all times of day and in current and future years. If you find that you need to apply very large adjustments to reproduce the observed queues, this suggests that there is something wrong with the model data and it's worth checking the points above again.

This message indicates that a junction does not satisfy the requirement necessary to carry out Accidnet Analysis. The inscribed circle diameter, as entered in Geometric Data for each arm, must be at least 10 metres greater than the central island diameter, as entered in the accident data. In other words, the road width at each point around the roundabout must be at least 5 metres. The phrase “roundabout is non-circular” maybe confusing, but it is indicative of the fact that this message appears, more often as not, when the roundabout isn’t circular, i.e. the width of the circulating carriageway within the proximity of a particular arm is less than that of the other arms.

I have entered turning counts for each 15-minute time segment but the results look far too high/low. What am I doing wrong?

The answer to this and similar questions is that you should always check which units each screen uses. All relevant screens always show the current units at the top of the screen or next to each data item. You can customise the units at any time, but it’s important to note that this affects ALL relevant screens. To change units, select Data>Units from the main menu and then choose from the various options. The choice of units is saved with the file.

When you start a new file, all flows are in PCU/hr. Even if looking at an individual 15-minute time-segment, in the flows, results or turning counts screens, the flow is still in PCU/hr. For example, if 100 PCU are counted in 15 minutes, this is 400 PCU/hr. Using the same units in this way makes it easier to work with rates in a consistent way. If you prefer to enter actual counts per time-segment, simply change the Traffic Flows option in the Units screen to ‘per time segment’. (You can change back and forth as many times as you like, and any previously input data will automatically be displayed in the new units.)

I have entered turning counts/flows using the wrong units. When I change units, the values in the screens change. How can I change the data into the correct units?

As an example, say you have a count of 100 PCU in a 15-minute time segment, and enter this directly as 100, not realising that ARCADY is in PCU/hr mode. ARCADY would interpret the value as 100 PCU/hr, whereas you wanted 100 PCU per 15 minutes, or 400 PCU/hr.  If you have made this kind of mistake, then simply changing the units used, does not work, because Junctions automatically converts the existing data into the new units when you change units.  However, as an alternative to changing the units and re-entering all the data by hand, you can select Edit>'Copy/Paste all Demand Sets / Time segments' from the main menu and select the option you need, in order to paste all the data you have onto the clipboard.  Simply change the units before going back to the 'Copy/Paste all' screen; select the 'Paste' option, and paste the OD data back into your file.

If you only need to change the data for one grid then you can simply click in one of the cells in the OD data grid; click 'copy' on the horizontal toolbar; change the units and click 'paste' to return your data to the grid.  Your data will now be in the correct units.

Alternatively, since you know that all the flows need to be made 4 times bigger, you could simply enter a flow scaling factor of 400% for each arm. (This is only possible if you’re not already using the flow scaling factor.)

Why does the Summary Results screen only show one set of outputs?
Why does the Summary Results screen have lots of blank sections?

By default, this screen only shows the results for the currently selected Analysis and Demand Set pair.  To shows results for all sets, click Mode>Show All Analysis and Demand Sets from within the Summary Results screen.  Note that this option is saved as a user preference rather than in the file.

The Summary Results screen automatically lays out rows and columns according to your naming of Analysis and Demand sets.  Different Analysis Sets (e.g. existing/proposed layouts) form different sections.  The Time Period Names of Demand Sets (e.g. AM/Off-peak/PM) form the columns.  Finally the Scenario Names of Demand Sets (e.g. 2021, 2026) form rows.

There is nothing to stop you using the Scenario Name to fully describe the Demand Set (e.g.  ‘2021 Off-peak’) but you may then find that the Summary Results screen shows a large grid that is mostly empty, because the program wouldn’t know how to separate the time period from the year and other information.  In this case it would be better to separate the '2009' and the 'Off-peak' into the Time Period Name and the Scenario Name respectively.

For full details, please see the Junctions User Guide, which lays out a variety of examples.

If you can’t find a way to measure a sight distance, you should enter zero. In this case a slightly different form of the geometric delay calculations is automatically used, to allow for the unknown parameter, so this is not the same as just entering a very low value.

Generally values of 0.85 for unsignalled junctions have been used extensively and many modelling products pander to this by setting defaults that, of course, encourage it even more.

Although it is understandable why such values are popular, and genuinely have their place, there may be a tendency for these values to become the ONLY goal, at the expense of evaluating situations in a more thorough and useful way.

There are a number of reasons why you should not rely on just one single acceptable maximum value of RFC. For example:

RFC values vary throughout a peak, and can rise and fall sharply or slowly.
The consequences of a high RFC depend on the flow. An RFC value of 1.2 might not matter with a very low flow whereas a value of 0.8 might be disastrous with a high flow.

The important criteria for judging the success of a design (from the point of view of congestion) are the total delay to all vehicles, and the mean delay per vehicle on each of the approaches. The latter is a question of “fairness” and “politics”. Is it acceptable for some drivers to suffer twice as much delay as others? How about ten times as much? That is a matter of opinion.

Revised by Jim Binning (Jan 2011)

The ARCADY User Guide covers the “normal” 99 percent of roundabout approaches, where the approach width is measured just upstream of the point where local flaring begins, and therefore the approach is parallel-sided. The “width of the approach before the roundabout was built” is a convenient way of visualising the measurement required.

Sometimes, however, an approach might widen from (say) one lane to two lanes, at a significant distance upstream of the give-way line. The number of lanes is irrelevant, but the point is that the approach is parallel-sided from P1 to P2, and is also parallel-sided from P3 to P4.

Does the “local flaring” begin at P1 or at P3? Is the approach width equal to V1 or to V2? Would your answer be different if the two-lane section in the diagram was (say) 5 kilometres long rather than 20 metres long? Here is how to decide where to measure V in the real situations which will lie between these two extreme cases:

Run the model with V1 as your approach width. Check if:

(a) the mean queue on the approach is at all times contained well within the two lane section. Assume that 1 PCU plus the gap occupies 10 metres of queueing space – this is an overestimate, but it will allow for the random variability of queues.

(b) the capacity of the give-way line is not greater than the capacity of the link bottleneck at point P3 on the diagram. This is unlikely, because although the road at P3 is narrower than the give-way line, drivers at P3 are not having to stop and give-way. The capacity at P3 will simply be the saturation flow rate at that point. If the road at P3 is so narrow that the saturation flow at P3 is less than the roundabout give-way capacity, then V2 will be acting as the limiting factor and should be used as the approach width.

If both conditions (a) and (b) are met, then using V1 as the approach width is appropriate. Otherwise, you should use V2 as the approach width, and re-run the model. The queues from this 2nd run will probably be much bigger than in the first run, but this will be the correct model to use. N.B. Adjust flare details accordingly.

NOTE: in ARCADY 8 and above, you can use Entry Lane Analysis mode to explicitly set up this sort of lane configuration. You would set up two lane levels, with a zero (or minimal) flare in each lane level.

ARCADY 8 and above includes an Entry Lane Simulation feature, which does take account of the number of lanes on an approach.

A certain amount of variable lane usage is built into the original empirical ARCADY model. The original research looked at a large amount of data and investigated whether including the number of lanes made the model any more accurate, and found that it did not; the main geometric features such as entry width were far more important.

However, if there is persistent and obvious unequal lane usage (for example if a dedicated left-turn lane is not used because there are no left-turning vehicles), this is NOT included in the model, and must be accounted for by the user. We would recommend the use of ARCADY 8 or above in Lane Simulation mode to investigate such behaviour.

When I try to save a file it shows an "out of memory" error

Unfortunately this problem can occasionally happen if you have a file with a lot of Demand Sets and/or Analysis Sets, particularly if you are also using Lane Simulation mode and if your file contains several junctions.  The problem is not with the file itself but with how it is converted into a different format for saving to disk.

Junctions 9.5 and above includes an option in File>Export>Save file without results.  This will save the file with all results stripped out, resulting in a smaller file size.  This option is triggered automatically in Junctions if you try to save a file and an out-of-memory error is encountered.

Otherwise, the workaround generally is to split the file into two or more files, where for example one file contains all the ‘With Development’ scenarios or similar.

If you can’t save the file then things to try are:

• Turn off Lane Simulation mode, if it’s on
• Close down any other running applications
• Try deleting the last Demand Set and seeing if you can then save the file
• If not, you may have to delete more of them until you can save the file.
• Also, as long as you’re not entering traffic demand for each time segment, try editing the Demand Sets so that they only have a single time segment.  If you save the file you can subsequently split it into two or more files as mentioned above and then change back to the real number of time segments.
• Try deleting any other items in the file that you can find that could easily be recreated.
• You can also go to a screen of interest, e.g. the OD matrix screen, then go to Edit>Copy/Paste All and use one of the ‘all Demand Sets’ option.  This will copy all demand data to the clipboard and you can paste into Excel.  If you do need to recreate the file, you can then do this operation in reverse to paste the data back into your Junctions 9 file.

I want to add a growth factor to the base model, so that it automatically calculates the future growthed traffic flows.

In Junctions 9 this can be done using Demand Set Relationships and, optionally, Growth Factors. Some example uses are shown below.

Suppose you have a Demand Set D1, representing base year traffic flows and then want to have a second set D2 for future year traffic. Assume to begin with that the traffic growth is a uniform 20% for all movements on all approaches.

• Go to the properties of the D2 Demand Set, where you can enter its name, start/finish time and so on. Make sure that you are in Advanced Mode (turn this on via the main Data menu if needed).
• Tick the Use Relationship property.
• In the Relationship box, enter "D1 * 1.2".
• When you look at the OD matrix when D2 is the active demand set, you should see that it is read-only and that the values in the OD matrix are automatically filled in as 120% of the base year values. They will update automatically if you alter the base year flows.
• This assumes use of the ONE HOUR profile (the default option). If using different profile types you may need to use different types of relationship - please contact us for details.

It is also possible to save one or more growth factors in the file:

• In the Data Outline, find the Growth Factors section (this comes after the Demand Sets). Right-click on it to add a new Growth Factor, which you can then edit.
• You can directly type in the growth factor value - for instance, enter 1.2 to use the 20% example from above.
• Then, in the D2 Demand Set, enter the Relationship as "D1 * G1". The G1 will be replaced by the actual growth factor value when you view the D2 traffic.
• The advantage of this method is that you can enter a description explaining the source of the growth factor. By entering several growth factors you can also manage different scenarios such as high growth and low growth and so on.
• Optionally, if you tick the Use TEMPRO option, and then click the Calculate link, you can calculate TEMPRO growth factors based on the location, future year, road type etc. (This requires that you have the TEMPRO databases available on your PC or network.)

Now suppose that you have a separate development matrix representing additional future year traffic for each OD movement.

• Use D1 for the base year traffic, and D2 as the future year, as above
• Create a third Demand Set to store the development matrix. You can enter anything you like for the Demand Set ID, so this Demand Set could be labelled as D3, or as D999, or as D_DEV, or any other notation that you find useful. Simply enter the ID in the Demand Set's properties. For this example assume it's labelled as D_DEV.
• Make D_DEV active and enter the development traffic in the OD matrix.
• Edit D2 and set its Relationship to be "D1 + D_DEV". The OD matrix for D2 should then be the sum of the base and development matrices.
• The development matrix can include negative values.
• If the development matrix is in the form of factors (e.g. 25% additional traffic for A-B), you can enter these as factors in the development matrix (e.g. 1.25) and then use a multiplication relationship (e.g. "D1 * D_DEV")

You can combine relationships between multiple Demand Sets and the relationship can be any formula. For instance, "D1 * G1 + D2 * 0.5" is a valid relationship.

For more details, please see the User Guide.

NOTE: you can also quickly adjust traffic flows by editing the Network Flow Scaling Factor property on the current Analysis Set, and/or the scaling factors shown for each arm in the Demand Screen.

There are several different types of error and warning in Junctions.   Generally, most of them can be seen at any time by clicking on the Errors button on the main toolbar (this may also be referred to as "Task List").  In Junctions 9, this button will light up orange if there are any warnings in the file, and red if there are any errors.  Click on it to show a list of all warnings/errors in the file.

I would like to see graphs showing the relationship between different geometric parameters and capacity results.  Can you give the model a range for a parameter and then do a quick test to see how it affects RFC?

You may sometimes need to re-order the arms at an ARCADY roundabout, for example if adding a new arm which should be inserted between the existing arms.

For example, say you have a roundabout with three arms 1,2,3, and then wish to add a fourth arm between Arm 1 and Arm 2.

Start by adding the fourth arm in the usual way (use the Data Outline to add a new arm, or, right-click on an existing arm in the Junction Diagram and click 'Add another arm').  This will add a new Arm 4, which will be positioned after Arm 3.

There are then two ways you can change the arm order, as follows:

1. In the Junction Diagram, click on the name of the new arm and drag it to the new position.  (Dragging the arm name in this way will rotate the arm around the centre of the junction.)  Then on the main program toolbar click Tools>Set roundabout arm ordering from diagram.  The new arm order (1,4,2,3) will now be reflected in the diagram, in the Data Outline, in all other screens and in the traffic model itself.  In the diagram you may wish to press Auto-arrange to snap the arms to be evenly spaced.
2. Alternatively: go to the junction's properties in the Data Outline and edit the Arm Order data field directly.  In this case, you would change the order "1, 2, 3, 4" to "1, 4, 2, 3. You will probably then want to also move the arm's position in the Junction Diagram (or click Auto-arrange) so that it visually looks correct.

You can of course rename an arm at any time by simply editing its ID or Name.

NOTE:  if the arm order at an ARCADY junction is incorrect, then the traffic model results will be wrong, because the circulating flow calculations will be wrong.

NOTE:  you cannot change the arm order at PICADY junctions; the PICADY arms A,B,C,D are fixed and explicitly represent the major and minor arms.   At OSCADY junctions, in contrast, the arm order and positioning is entirely arbitrary.

Junctions 9 and above, includes a feature specially designed for setting up links between Excel spreadsheets and Junctions.  For full details, please see the Junctions User Guide, Section "Reading Demand Set flow data from Excel".  Using this mode, you can tell Junctions where in the Excel spreadsheet the traffic data is located and Junctions can then automatically pull the data from Excel, switching to different Excel worksheets as needed.

Additionally, you can copy and paste between individual screens and Excel using a method which is also available in previous versions of Junctions, as follows.

• There are Copy and Paste buttons on the main toolbar in Junctions, and corresponding options in the Edit menu.   Most screens respond to these buttons.
• For example, if you display the OD Matrix screen, and then press the Copy button on the main toolbar, the OD Matrix data will be copied to the clipboard.  If you then go to Excel and paste this data, you will see the format data.  You can then mark the pasted area in a different colour to indicate the area that you can subsequently grab and paste back into Junctions once you've edited it.  Then go back to Junctions, display the OD Matrix and then press the Paste button on the main toolbar.
• If you try to paste in data that contains the wrong number of rows or columns, Junctions will usually show an error message.
• The same system applies to most screens.   For instance, you can display the Demand screen, click in the lower grid and then paste in suitably formatted data from Excel.  Or you can show a Data Grid of arm geometries, and copy/paste the data.
• Note that with some screens, there are several 'levels' of copy/paste.  On the Data Editor, for example, you can copy individual pieces of text as with any other program.  However, if you display the Data Editor and then click the Copy button on the main toolbar, then all data currently shown in the Data Editor will be copied to the clipboard in a format that can neatly be pasted into Excel or any other program, or, copied between different Junctions files.
• Similarly, in the Summary Results screen, you can manually select text and then right-click and select Copy.  Alternatively, clicking Copy on the main toolbar will grab the entire contents of the Summary Results in a format that you can paste into Word.

In Junctions 9 and above, the system above is extended so that you can copy/paste data from a given screen for all Demand Sets and/or time segments:

• Click on the screen of interest - for example, the OD Matrix screen.
• Go to Edit>Copy/Paste All
• Tick 'Copy' and then tick, for instance, "current time segment, all Demand Sets".  This option can be used if there is only one time segment's worth of data, such as if using a single OD matrix for the whole period (the default option for new files).
• Click 'Go'.   Then go to Excel and paste the data.  We recommend that you then immediately set the colour or other formatting of the pasted selection so that you can easily re-select it later on.   The data in this example will be the OD matrix for each Demand Set.
• Edit the data in Excel.
• Grab the same area, copy it to the clipboard and then use the same process as above to paste it back into Junctions, this time selecting the 'Paste' option of course.
• Once familiar with the format, you can start new files by entering the traffic data directly into Excel, and then pasting into the Junctions file.  Note however that you will firstly need to create the blank Demand Sets in the Junctions file, otherwise the pasted data will be ignored.

When combining demand sets, Junctions effectively works out the actual number of HVs for each demand set and then combines them all together into a single set. For example, say one demand set has 10% HVs and a flow of 1000 veh/hour and another set has 5% HVs out of 500 veh/hour.  Junctions will know that the flow contains 125 (i.e. 100 + 25) heavy vehicles and 1375 light vehicles. This is equivalent to 250 PCUs due to the heavy vehicles (one HV is equivalent to two Passenger Car Units) and 1375 PCUs due to the light vehicles, giving a total of 1625 PCU.

In Junctions 8 and above, if you set up demand set relationships, you can see the calculated HV percentage in the resultant demand set by viewing the Vehicle Mix screen.

Can I view reports in Excel?

When you generate a report in Junctions it appears in a HTML viewer, from where you can use the Convert menu to save it as a PDF or Word document.  You can also view the report in Excel as follows:

1. Generate the report
2. Click in the report, then press CTRL+A to select everything, then press CTRL+C to copy the contents to the clipboard
3. Go to Excel and press CTRL+V to paste the report

The formatting, font sizes and etc will not be perfect but if you scroll past the banner section, the tables themselves should be readable and you can easily select all in Excel and then change the font size and column widths and so on.

You can also copy and paste data from individual screens to Excel, using the normal Windows clipboard functions.   In the general, the Copy button on the main toolbar in Junctions will copy ALL data from the screen that you last clicked on.

You can also copy data for all Demand Sets and/or Time Segments, by clicking Edit>Copy/Paste all Demand Sets/Time Segments.  The data copied will be from the screen last clicked on before clicking this option (i.e. the currently active screen).  For full details please see the User Guide.

When using Junctions 8 or above, you can very quickly set up an ARCADY or PICADY model. If you are using the most common options, then you can ignore most of the more advanced options and settings that the program offers. Instead, you only need to use a few screens to set up the junction geometry and flows and then see the results.

If you are using Junctions 9 or Junctions 10, please navigate to the "How to use Junctions" chapter of the main User Guide, where you will find the latest "Quick start" guide.

If still using Junctions 8, here is a Quick-start guide

This "Quick start" guidance summarises the steps needed to set up a basic model for a 3-arm roundabout using the ONE HOUR (ODTAB) traffic profile type. Setting up a PICADY model follows the same steps.

For those with a product that is provided by subscription, during a login or reset of a password you may be presented with a scripting error, like this...

This will not affect the operation of the program and can be bypassed by simply clicking the "Yes" button, and continuing to enter your login credentials.

This issue is already fixed, and will be sent out as part of the next scheduled releases for both TRANSYT 16 and Junctions 10.

When entering geometries, is there a way to see reminders on what to measure, rather than having to open the User Guide and have it alongside?

Yes, you can use the Glossary Screen for this purpose.

To do this, firstly click the Glossary icon on the main program toolbar (or click Help>Glossary).  This will display a screen which will initially be blank.  Then go to the item that you are editing (e.g. the entry width for a roundabout arm) on any data editing screen and click on it.  The Glossary Screen will then display information about that item, including diagrams if appropriate.

Please note that the Glossary Screen doesn't contain information for every data field, but it does cover the main ARCADY and PICADY geometries.  Also note that the Glossary is based on the User Guide and doesn't contain anything extra to the User Guide.

When using ONE HOUR (ODTAB) profiles, why does the total vehicles/hour in the final table of the ARCADY output file not match entered hourly counts?

Example: The hourly total count on an arm for, say, 08:00-09:00 is entered as 1000 PCU/hr, and a ONE HOUR (ODTAB) profile selected.

ARCADY will synthesise a peak demand profile that covers the central hour plus an extra 15-minute block either side of the central hour. The demand synthesised by ARCADY for each 15-minute time segment will therefore look something like this:

07:45-08:00 753 PCU/hr
08:00-08:15 899
08:15-08:30 1101
08:30-08:45 1101
08:45-09:00 899
09:00-09:15 753

The average over the central hour, i.e. 08:00-09:00, is (899+1101+1101+899) / 4 = 1000, which is the entered hourly count.

The average over the whole 90 minutes is slightly less: 918 PCU/hr. In other words, the average over the whole 90 minutes is slightly less than the entered hourly count because the synthesised profile includes a period either side of the central hour where the traffic demand is assumed to be lower than that measured during the central hour.

Using this profile type implies a number of assumptions, and of course the real demand profile at the junction may be completely different. For this reason, the ONE HOUR (ODTAB) profile should only be used if you know that the traffic profile at the junction follows a normal, typical peak period pattern.

Is there a way of graphically representing queue/delay? A visual depiction would be useful when comparing scenarios.
This depends on what type of junction you're modelling and what mode you're in, but here are some tips:

• The Junction Diagram screen has several overlays and graphical modes. For instance, after running a file, go to to the Junction Diagram and click Overlays>Show Queues>End Queues. This will show red bars on each junction arm corresponding to the time segment queues. These will change as you select different time segments or Demand Sets. To change the scale of the bars, click Show>Scale, then right-click on the scale line and choose Adjust Scale.
• You can see a graphical depiction of the flows through the junction by clicking Overlays>Flows By Entry, and then choosing Flows>Actual Flows. The widths of the coloured lines will correspond to the calculated throughput for each movement. The relative widths can be adjusted by going to the Options screen and then adjusting Graphical overlays>Overlay width.
• If using Lane Simulation mode, there are various animations and overlays available, when the Junction Diagram is shown. These are available at the bottom of the Lane Simulation screen. Drag the Time slider to see the queues at different times.
• Various other overlays are available in the Junction Diagram; please see the User Guide for details.
• If generating reports in Junctions, the report will contain one copy of the diagram, which will include any currently selected overlays. It is not possible for reports to show the diagram separately for each Demand Set. However, you can copy the diagram by right-clicking in it and choosing Copy and can then paste it into your own report, for any Demand Set.
• You can also use the Analyser Screen to show charts of queue lengths or any other output. For example, click the Analyser button on the main vertical toolbar, then go to the Time Graph tab, and use the Common time graphs menu to choose one of the built-in graphs. (See the User Guide for details of how to select other items.) Then press the Line or Bar button at the top to generate a chart showing how the queue (or whichever output you chose) varies over time.
• If available, you can click the Save Graph button at the bottom of the Analyser screen to save graph definitions. When generating reports, you can then tick the Graphs option in the Report Viewer, choose the graph, and then refresh the report. The graph will then be generated (for each Demand Set, if required) whenever you refresh the report.

Example: The hourly total count on an arm for, say, 08:00-09:00 is entered as 1000 PCU/hr, and a ONE HOUR (ODTAB) profile selected.

ARCADY will synthesise a peak demand profile that covers the central hour plus an extra 15-minute block either side of the central hour. The demand synthesised by ARCADY for each 15-minute time segment will therefore look something like this:

07:45-08:00 753 PCU/hr
08:00-08:15 899
08:15-08:30 1101
08:30-08:45 1101
08:45-09:00 899
09:00-09:15 753

The average over the central hour, i.e. 08:00-09:00, is (899+1101+1101+899) / 4 = 1000, which is the entered hourly count.

The average over the whole 90 minutes is slightly less: 918 PCU/hr. In other words, the average over the whole 90 minutes is slightly less than the entered hourly count because the synthesised profile includes a period either side of the central hour where the traffic demand is assumed to be lower than that measured during the central hour.

Using this profile type implies a number of assumptions, and of course the real demand profile at the junction may be completely different. For this reason, the ONE HOUR (ODTAB) profile should only be used if you know that the traffic profile at the junction follows a normal, typical peak period pattern.

Data entry windows keep going behind the diagram (or other windows) so I can't see them and have to keep reloading them.
The behaviour depends on the version of Junctions that you're using, but, assuming use of Junctions 9.5, here are some tips:

• If you double click on the title bar of any window, it will come out of the main Junctions window and will stay on top of all other windows. To put the window back inside Junctions, double click its title bar again. If you have two monitors you can in this way take the diagram (or any other window) onto your second monitor, away from the main window, so that it doesn't interfere with other windows.
• You can often re-focus windows by clicking on their icon in the main toolbar. For example, if the OD matrix is behind other windows, simply click the OD matrix button on the toolbar to bring it back to the top. NOTE: if the screen is padlocked, then clicking the toolbar button will create a new instance of the window.
• Consider using the Window Layouts feature. This lets you save the current arrangement of windows, including their position and size, and then quickly restore that layout at any time. You can save several different layouts and can exchange them with colleagues. For full details please see the User Guide.
• You can quickly close all windows, taking you back to a blank slate, by clicking Windows>Close all windows.

OSCADY Classic: You cannot model a situation where traffic stream A both opposes and is opposed by traffic stream B. If you need to model this situation, then you should either separate the turning movements out into separate traffic streams, or, if this is not possible, model one of the traffic streams as unopposed and reduce its saturation flow to compensate.

OSCADY PRO: From OSCADY PRO v1.1, a mutual opposition model is included in the program, and this will automatically activate if a mutual opposition situation is identified.

The Copy button on the main toolbar will copy data to the clipboard from most screens. Data is copied from the OSCADY PRO screen you last clicked on, and the exact format depends on the particular screen. See section 5.10 of the User Guide for details. In addition, some screens have their own copy and paste buttons, such as the Traffic Flows screen, which allow you to paste data in directly from a spreadsheet.

A situation where traffic stream A both opposes and is opposed by traffic stream B is a complex modelling problem. However, from OSCADY PRO v1.1, a mutual opposition model is included in the program, and this will automatically activate if a mutual opposition situation is identified.

Alternatively, you should either separate the turning movements out into separate traffic streams, or, if this is not possible, model one of the traffic streams as unopposed and reduce its saturation flow to compensate.

Often you will wish to compare the performance of several different stage sequences, or variations on a junction design. You can use the rows in the Summary Results screen to switch between sequences, but you can also switch between files by using the blue file selector bar at the foot of the screen. You can create 'copies' of the current file by clicking File>Copy Into New File, and then switch between them using the file selector bar. In this way you can, for example, enter a fixed stage sequence and run OSCADY PRO, then create a copy of the file and generate new sequences, and then compare the results. This is very convenient for experimenting with different stages or layouts, and of course at any point you can choose to save any of the files to disk.

Currently there is no way in OSCADY PRO to adjust default parameters. You cannot, for example, change the default phase minimum green. However, when you create a new item (a new phase, stage, traffic stream, lane, etc), then the new item will inherit its properties from the last entered item.

So, if you set up Phase A with your desired minimum green, etc, then click on Phase A and select Add Another Phase, then the new Phase B will have the same properties as Phase A. In this way you can use the existing items as templates for new items.

If you need to delete all stages (e.g. to get back to a 'clean slate'), then you can delete them one by one in the Data Outline, but there is also a shortcut: simply display the Intergreen Matrix screen, click the Edit Matrix button, and then click the Clear>> button and choose Remove All Stages. (You can also use this button to quickly clear the intergreen matrix). As usual you can always use the Undo button to reverse this change.

For ODTAB flows to work correctly, you must specify turning movements on each lane, via the Nearside Movement etc data item fields for each lane. This is so that the ODTAB flows can be allocated across traffic streams according to the left/straight/right movements on the lanes in the traffic streams.

For the turning proportions to be correctly calculated, you must set up the arms to follow the naming convention used in OSCADY Classic, that is, each numbered arm must be positioned clockwise from the previous arm for drive-on-the-left or counter-clockwise for drive-on-the-right. Otherwise, the turning proportions grid will be inconsistent with the ODTAB grid.

Furthermore, ODTAB can only be used when there are either three or four arms in the junction. If your junction has more than four arms and you need to use ODTAB, you could consider merging two close together arms into a single OSCADY PRO arm. (You can then use the Keep traffic streams on each arm together option in the Junction Diagram screen to allow the individual traffic streams to be moved separately.)

The arm numbering convention for ODTAB is shown below, where A = Arm 1 etc.

In more complex cases, it may be better to use the DIRECT data option and input individual flows for each traffic stream.

Reports are affected by the options you choose on the Report Setup screen, and you can also choose which sequences/objectives to include in reports by right-clicking on the grid in the Summary Results screen - see section 10.2.5 of the User Guide for more details.

I am having problems opening any OSCADY PRO files. I keep getting the following message: "The following error has occurred: Module:subFillTreeview. Error: Object variable or With block variable not set. Abort Retry Ignore. "

The fault you describe is caused by changes by Microsoft to how Windows handles XML – This is why it breaks the data outline first, as this is XML.

Fortunately this has been fixed in a later release of OSCADY PRO (v1.3.1).

To get OSCADY PRO to work you will need to update your version.

The Critical Cycle Time objective calculates signal timings which give the shortest cycle time that allows the junction to operate within capacity. Usually, therefore, the PRC for this objective should be precisely zero. However, when using integer phase timings, rounding effects can lead to the PRC being slightly less than zero. We expect to improve this for future releases of the program but, in the meantime, to obtain more accurate results, go to the View>Options screen and turn off the Integer Phase Timings option.

The original sequence column shows the 'original' stage sequence, either manually input or produced by the Sequence Generator. This may or may not bear much resemblance to the Final Sequence, which is what you see in final outputs and phase/stage timings. The original sequence can be considered as an 'initial guess', which the optimiser then refines and adjusts. (If you are forcing stages, however, the original and final sequences should match.) Generally, the final sequence is a subset of the initial sequence.

This is illustrated in the PHASE CONSTRAINTS screenshot example. For the active solution (Sequence 2, Minimum Delay), the original stage sequence was 1,4,5,6,3,2. This is shown in the upper Junction Diagram. (See the User Guide for details of how to set up the Junction Diagram to show stage sets. Note that the diagram shows its current mode in yellow at the foot of the diagram.) The final sequence, however, is 1,4,6,2, as shown in the phase timings diagram and in the lower sequence diagram; i.e. stages 5 and 3 have 'dropped out' of the solution. This is because the optimiser has found that they are not necessary for the optimised solution. For example, stage 5 represents a transition between stages 4 and 6 and so is 'merged' with the surrounding stages.

Of course, where you wish to force a stage sequence, and prevent any such merging, you can do so easily by entering a non-zero minimum green on the stage.

For ODTAB flows to work correctly, you must specify turning movements on each lane, via the Nearside Movement etc data item fields for each lane.  This is so that the ODTAB flows can be allocated across traffic streams according to the left/straight/right movements on the lanes in the traffic streams.

For the turning proportions to be correctly calculated, you must set up the arms to follow the naming convention used in OSCADY Classic, that is, each numbered arm must be positioned clockwise from the previous arm for drive-on-the-left or counter-clockwise for drive-on-the-right.  Otherwise, the turning proportions grid will be inconsistent with the ODTAB grid.

Furthermore, ODTAB can only be used when there are either three or four arms in the junction.  If your junction has more than four arms and you need to use ODTAB, you could consider merging two close together arms into a single OSCADY PRO arm.  (You can then use the Keep traffic streams on each arm together option in the Junction Diagram screen to allow the individual traffic streams to be moved separately.)

In more complex cases, it may be better to use the DIRECT data option and input individual flows for each traffic stream.

Whenever you run a file in OSCADY PRO, the Summary Results screen is updated. A grid of results is shown where each row represents a signal sequence, and the three columns represent each of the three optimiser objectives: critical cycle time, maximised capacity and minimised delay.

For a given signal sequence, the optimiser can adjust individual phase timings so that they give the shortest possible cycle time, or maximise capacity, or minimise delay at the junction. These are the three optimiser objectives.

As an example, in the MINIMUM DELAY screenshot, the highlighted grid cell (in yellow) is for the minimised delay column for Sequence 3. The number (12.30) is the minimised rate of delay, in units of PCUs, for Sequence 3. (See the User Guide for full details of units.) For the same sequence, the maximum possible capacity is 33.87%, and the shortest possible cycle time that is within capacity is 64s.

Other sequences may perform better or worse, in terms of delay, or capacity. OSCADY PRO highlights in blue the 'best' sequence for each objective. In the screenshot, Sequence 2 gives the smallest cycle time and the highest capacity, but Sequence 3 gives the lowest junction delay.

The grid cell highlighted in yellow is known as the Active Sequence/Objective, or the active solution. So if, in the MINIMUM DELAY sreenshot example, you now click on the buttons to show phase timings diagrams or detailed results tables, all the data will refer to the results for the minimised delay solution for Sequence 3. If you click in a different cell, then all other results screens will auto-matically update to reflect the results for this new solution. You can only view one solution at a time. All solutions are generated with each run of the file; the Summary Results screen lets you examine each of them.

Whichever row and column you click on, the Performance Indicators in the centre of the screen always show the cycle time, PRC and delay for the highlighted solution.

When you run a file for the first time, the active solution always resets to its 'default' position at the top-left, so that the Critical Cycle Time solution for Sequence 1 is always highlighted – as shown in the CRITICAL CYCLE TIME screenshot. This is unlikely to be the solution you are interested in; therefore you should always remember to click within the grid to make sure you have selected the sequence and objective of interest.

If you run a file whilst the Summary Results screen is already displayed, then the active solution will stay the same. E.g. if you highlight Sequence 3, Minimum Delay, then make a change to traffic flows and re-run the file, all results screens will still show results for Sequence 3, Minimum Delay.

An obvious question is: why can't the Summary Results screen automatically jump to and highlight the best solution? The answer is that it could, but that it may not always be possible to define what is meant by 'best'. In addition, allowing the program to automatically select solutions could be confusing when you are trying to study the effect of changes on a given solution. However, we will look at an implementation of this idea for future versions of the program.

Please click here for other OSCADY PRO articles/examples.

Generally if the banned movement is one that is NOT a controlling flow - e.g. a left turn from a minor road (B-C) - then the fact that it is banned can be modelled by simply specifying that the movement has zero demand.

However if the banned movement is one that another movement would ordinarily give way to, then this WILL affect the results. Traffic giving way to a movement with no traffic on it, is not the same as banning that movement. Drivers have to check that they can proceed and that entails an element of delay which is a component of the queueing delay that PICADY calculates (and also part of geometric delay). This 'checking delay' is absent if an otherwise controlling movement is banned. For instance, if your junction is such that the C-B movement is not allowed, and this is clearly indicated (or implied by the layout), then traffic leaving the minor arm will not need to check to see if there is any approaching C-B traffic. As mentioned, this is not the same as simply have zero demand on the C-B stream. It may, however, be a matter of judgement as to whether the banned movement is obvious to the controlled traffic, or whether drivers still check that the road is clear in the same way that they would do at a normal junction.

In any case, you cannot specify this situation in PICADY. The good news though is that, because this effect is not taken account of, your PICADY results will be slightly pessimistic rather than optimistic.

Traffic from C-B blocks C-A traffic: This is the most important parameter when considering right turners. There is more info on this in the User Guide, but the basic principle is that: when right turners are specified as blocking straight ahead traffic, the capacities of each traffic stream are modified, and thus the output from the model will differ significantly from the non-blocking case. Whether the right turning traffic is blocking or not depends on the particular nature of the junction rather than the geometry as entered into the program. This is why the program asks you to input this value rather than computing it from the geometries and flow information.

The reason that 2.2m is entered for the right-turn lane when there is no actual right-turn lane is that PICADY always uses an 'effective' right-turn lane, whether one physically exists or not. In the case of a single physical lane, the 2.2m simply represents the average road width taken up by traffic turning right. A better definition is "lane width for non-priority streams"; it is important to remember that, in general, PICADY operates in terms of traffic streams rather than lanes. This means that as far as PICADY is concerned, it is irrelevant whether the various traffic streams are segregated into different lanes or not. (Also remember that PICADY assumes that the priority streams are uninterrupted (or rather, are either 'blocked' or 'non-blocked'), does not calculate their capacities and so does not need to know the width of each individual lane.)

Where islands are present, the measurement of the carriageway width does exclude the right turn lane, because in these cases the right-turn lane is a separate, distinct feature of the junction that exclusively carries right-turning traffic and so is not incorporated into the general model of the junction. They also affect the minor arm capacities, as mentioned below.

All stream capacities depend on the total carriageway width, but only the traffic turning right from the MINOR road (B-A) is affected by the central reserve width (if any). When you specify that "Traffic from C-B blocks C-A traffic", these equations are modified to take account of the extra delay experienced. This is all based on evidence used in the original research to formulate the models.

The upshot of all this is that to PICADY, a T-junction with a right-turning lane of width 2.2m is identical to a T-junction without a right-turning lane, assuming that the total carriageway width is the same.

It is quite common for the first two vehicles on a minor arm to queue side by side, especially if the turning proportions are fairly well balanced.

In such cases the PICADY model would normally be set up with a short flare, length = 1 vehicle. This is as it should be, but the result may be unexpected. It might be expected that even a short double-queue would have a greater capacity than if vehicles were queueing in a single file, but PICADY sometimes predicts otherwise.

Visibility is the problem. Each vehicle at the give-way line is obstructing the visibility of the driver alongside, making people slower and more reluctant to emerge from the side road. PICADY accounts for this loss of visibility, which does indeed occur in “real life”. So don’t be too surprised if your extra little bit of flaring at the give-way line makes the junction less efficient ! If you can find room for, say, three or more vehicles side-by-side it is a different matter entirely.

Strictly speaking, it is not possible to do this since the definition of queuing delay has an element of geometric delay in it. The element of overlap is the delay associated with drivers checking that it is safe to enter a junction. It can be argued that this delay is both an element of queueing delay AND geometric delay and hence ARCADY is in fact correct to show it the way it does, included in both. Clearly this does not help those wishing to obtain a combined figure for total delay. However, It should be noted that, if the geometric delay was to be re-defined in ARCADY and PICADY to exclude this overlap it would then not be possible to measure the queueing delay as is currently possible! I would suggest that anyone facing a request for a total value of delay should provide both the queueing and geometric delay tables separately with an explanation of the fact that there is an overlap. Alternatively there is an approximate representation of driver checking time given in TRL Supplementary Report SR810, although at the time of writing this, I have not sourced the origins of this ‘estimate’ of driver checking time and so cannot comment further on its usefulness. Furthermore, the size of the overlap (the ‘checking delay’) will tend to relatively small in comparison with the queueing delay.

The 10 metre visibility position comes from the original regression analysis carried out by TRL. In the original study the measurement of visibility was measured from a number of different points. The measurement of 10 metres was found during the analysis to provide the strongest link between it and the capacity.

Unfortunately this does not match up with the values that most traffic engineers will have. There is unfortunately no possible way to translate this value so that it represents the visibility from another point as it depends on the proximity of the obstructions that make the parameters the value it is. You can use, say, a scale diagram but it is always best to do measurements on-site if possible so that ALL obstacles that are present during the time period you are interested in are taken account of. E.g. high-sided vehicles parked throughout the modelled time in such a way to reduce visibility should be taken account of, if you wish to gain accurate results.

On a diverge lane, which cannot be modelled explicitly by PICADY, it is reasonable to assume that the inhibiting effect of left turners will be significantly reduced. By how much depends on the geometry of the diverge lane, so there can be no hard and fast “rule”. In an extreme case, if drivers entered the diverge lane 300 metres from the junction, and were physically prevented from leaving it, they would have no effect whatsoever on traffic emerging from the side road. Conversely, if drivers enter the diverge lane very close to the junction, their inhibiting effect may not be reduced very much.

To take account of the fact that left turners are using a diverge lane, you have to “manually adjust” the model. You should NOT adjust any O/D flows because these affect many different traffic streams, and are interactive. To adjust the model in this case:

1. Determine the sensitivity of Arm B capacity to the left turning A_B flow (by doing two runs at different flow levels)
2. You then know what capacity increase is equivalent to a reduction (or elimination) of left turning A_B flow.
3. Adjust the model by manually increasing the capacity of Arm B, rather than reducing the flow of A_B.
4. The capacity can be manually adjusted in several ways, but the most sanitary is to apply a site-specific intercept correction.
5. The value of the intercept correction needed can be calculated, but it is quicker in the long run to do it by trial and error. Carry out a series of runs until you get the Arm B capacity required (as determined by Point 2).

The junction can be modelled by specifying the minor road (Arm B) demand flows and the measured geometry as normal. The main carriageway demand for arm A (both A -> C and A -> B) should also be specified as normal, but the demand on Arm C should be set to zero flow. The main carriageway width should be measured in the usual way except for the width on arm A which should exclude the width of the near-side lane which is in effect being ignored, e.g. if the widths are as follows: offside exit lane on Arm A = 3m; entry lane on Arm A = 3.2m; exit lane on Arm C = 2.8m; entry on arm C = 3.1m then the approach road half width, W = (3 + 3.2 + 2.8 + 3.1) / 2.

Note: PICADY may tend to underestimate the capacity of the minor arm as drivers KNOW they do not have to giveway to traffic travelling along the main carriageway from C -> A. Specifying zero flows on the main carriageway is not the same as there IS a difference between giving way to zero flows and not having to give-way at all. On the other hand the merging effect on the main carriageway downstream of the junction is likely to have a detrimental effect on the minor road capacity and hence the two effect MAY cancel each other out. If concerned about these effects the best option is to carry out site observations (if possible) and use them to calculate site-specific adjustment factors.

In order to decide whether a single lane approach is appropriate or not you should look at what is happening at the giveway line. If vehicles at the giveway are queuing side-by-side, and not just behind each other within the acceleration lane, this constitutes two traffic streams and hence it should be modelled as either a ‘one lane + flare’ or ‘two-lane’ situation as appropriate. If the queueing within the acceleration lane is simply one vehicle behind the other, then only one traffic stream exists and hence it is best modelled as a single lane. If the junction does not yet exist professional judgement will be needed to determine the most likely scenario.

When modelling a staggered crossroads on a dualled section of road, does the width of the central reserve has any bearing on PICADY understanding of the manoeuvre and that vehicles turning from B to A can store in the central reserve?

The original research that defines what PICADY does contains the following paragraphs:

“At dual-carriageway sites right-turning minor road vehicles can interrupt their manoeuvre at the central reserve. In principal this might to some extent ‘decouple’ the traffic interactions on either side of the major road carriageway and weaken the dependence of the max flow of B-A on C-A traffic. In practice, however, it has not proved possible to detect a significant difference in the traffic interactions determining the capacity of the single- and dual-carriageway sites.”

"The width of the central reserve did influence the B-A capacity, but independently of the C-A traffic, simply modifying the saturation flow."

"At busy dual-carriageway sites in peak periods ... the benefits of increasing the central reserve width are about half of those of increasing the carriageway width by the same amount."

So, increasing the central reserve width makes all relevant manoeuvres easier for drivers, in a similar way that widening the road in general would. But it is NOT the case that PICADY explicitly models vehicles as stopping in the central reserve.

Of course, if you increase the stagger distance then eventually the junction would be better described as two linked T-junctions. Using PICADY 9 this can be modelled using Lane Simulation mode, and this WILL model the separate components of the journey from one minor arm to another.

Unfortunately there is no research that compares the capacity of a give-way line and that of a stopline in the context of a PICADY junction. The difference may however be minimal if drivers continue to regard the junctions as give-ways. Furthermore, it is likely that any effect on capacity will be negligible in the very situations where it is necessary to assess capacity in the first place (when the RFC is high), as most of the traffic will be moving off from a queued position.

If using PICADY to assess a junction that has stoplines instead of give-way lines, all you can really do is to model the junction as usual and then assume that the real capacity will be slightly lower, i.e., the PICADY results will be on the optimistic side (everything else being equal).

Although the original empirical research that PICADY is based on did not explicitly consider one-way roads, it is possible to model them as follows:

1. Make sure that the turning counts are correct (e.g. if one-way in the C-A direction, there should be zero traffic travelling towards C)

2. In PICADY 8 or later: Enter the 'Major Road Direction' for the junction and the physical kerb-to-kerb width, and the program will then automatically carry out any conversion necessary. Do NOT double any widths.

2b. In PICADY 5 only: Measure the physical kerb-to-kerb width of the major road, and then double it before entering in PICADY. E.g. if the physical width of the one-way road is 4m, then enter 8m into the program. This is because the traffic model always thinks that the road is two-way, and so expects that 'half' of the entered width is actually available for any given movement. This is true regardless of the direction of the one-way flow.

3. If there are multiple lanes on the major road, then it may be that some of those lanes have zero effect on the junction. This would be true if, for example, a lane carries only straight-through traffic, and, due to geometry, is unavailable to traffic emerging from the minor road. In this case, you could consider removing these lanes from the model altogether.

NOTE: When modelling one-way junctions, care should always be taken to check that the results look ‘reasonable’, and (if at all possible), comparable to any similar operating junctions. The core PICADY model is calibrated only for two-way junctions.

The newest versions of PICADY provide options for setting up entry and exit restrictions on arms, which can be used to model bottlenecks directly.  PICADY 10 also includes the option of modelling chicanes/build-outs/one-way bridges, and so on.  The advice below is aimed at users of older versions of PICADY.  

Although a Zebra crossing doesn't have exactly the same effect as any other bottleneck on a vehicle-by-vehicle basis, over the longer term it should be a good proxy.

The formula for the vehicular capacity of a Zebra crossing, as used in ARC/PIC, was first derived by J. D. Griffiths (Transportation Science, Vol 15, No. 3, August 1981). By using this formula (see below) you can fabricate a dummy Zebra crossing with any vehicular capacity you wish (i.e. that of the bottleneck) - the most obvious way of doing this is to adjust the pedestrian flow rate. If you are going to use this technique, it is advisable to create a spreadsheet based on this formula, particularly given the units.

Where :

C is vehicular capacity of Zebra crossing (Vehicles/Second)

U is two-way pedestrian flow on crossing (Peds/Second)

A is mean crossing time of pedestrian (Seconds)

(ARC/PIC assume a mean crossing speed of 1.2 metres/second)

B is mean time headway of vehicles when there are no pedestrians crossing (Seconds) (the reciprocal of vehicles per second saturation flow)

e = 2.7183 (to four decimal places)

One problem is that the bottleneck generally applies to traffic in one direction only. For example, if you insert a dummy Zebra crossing on one arm of a roundabout because of an exit restriction, you will also affect the entry capacity on that arm. Fortunately there is an easy solution:

Model the dummy Zebra as a two-stage crossing with central refuge. Make the distance between the crossing and the junction exit equal to the true value, but the distance between the crossing and junction entry equal to some huge number. In that way, the program assumes that the Zebra is a very long way from the junction entry, and therefore has virtually no effect on entry capacity.

Why does the core model not allow me to model scenarios such as when there is a crossing on a road that blocks straight-ahead traffic?

The core models used in PICADY have some restrictions which mean that it is difficult to combine the various sub-models which handle, for instance, major road blocking and pedestrian crossings.

However, in Junctions 9 and Junctions 10 you can turn switch into Lane Simulation mode and then you CAN turn on various features at the same time. This is also often the case for other situations in ARCADY, PICADY or OSCADY where there are difficulties with the core models; Lane Simulation can often be used as an alternative.

For details of Lane Simulation Mode in PICADY, ARCADY or OSCADY, please see the User Guide.

You do not need to make any special provision for this as it is implicit in the capacity model used in PICADY. On the minor arm, the nearside lane capacity is reduced to take account of visibility being reduced when vehicles are queueing in the offside lane.

The traffic flows in my PICADY output file do not add up – the total demand from Arm C is not the same as the input for that arm – the total entering on this arm is smaller than it should be, and the proportion turning right is higher than I’ve specified. Can this be right?

The flows DO add up. The confusion comes from the way the flows are labelled. The flows associated with streams C-AB and C-A are added together to give the total. C-A is NOT a subset of the flow on C-AB. Traffic arriving on arm C and leaving on arm A is split between the two streams. A proportion of this straight-ahead traffic gets blocked by right-tuning traffic on the main carriageway and ends up in the CAB stream while some gets through unimpeded and this remaining flow is in the C-A traffic flow - i.e. the flow is 'mutually exclusive'. The C-A traffic stream you will notice has no queue and no delay associated with it as it goes through the junction uninterrupted.

In this example (see diagram) you are best to model lane 1 as a flare of lane 2. If the number of buses is high, it will be disruptive to traffic flow on lane 1 not only when a bus is stopped at the bus stop but also at any time it is in the bus lane. If you were to model the lanes as separate lanes you would need to reduce the sat flow on lane 1 to compensate but for this you would really need to know the flows on each lane separately to have any chance of selecting a suitable value of sat flow.

A compromise is needed to compensate for the fact that the flare is not always a flare! I suggest you increase the flare length of lane 1 to compensate. By how much you do this is the tricky bit. As a starting point, I would be inclined to compensate by looking at the proportion of time in which you consider lane 1 flow to be disrupted and then weight the link length and the space in front of the bus lane by the proportion, e.g. if lane one is affected by the presence of a bus for, say, a third the time then you could make the flare length equal to (2/3 x link length) + (1/3 x the space in front of the bus stop), or something similar. Then see if it is giving you reasonable results.

The answer is yes they can – vehicles on oversaturated links are delayed on those links so their delay is included in the model.

In the latest TRANSYT 16, you simply switch off the following Traffic Stream parameter "Has Saturation Flows".  This gives it an infinite capacity, therefore avoiding any queueing. This feature is particularly useful when adding exit links to your network which you don't want queues forming on, nor influence the network timings.

If using TRANSYT 14 or TRANSYT 15 you can set the link saturation flow to "unrestricted".

If using TRANSYT 13 you need to set the saturation flow to a high value to avoid unrealistic queueing.

Question: Can I use TRANSYT to model a single isolated junction? I’ve always assumed I’d need to buy OSCADY PRO or an equivalent product to do this.

Answer: Yes! - You can use TRANSYT to model individual junctions. Since TRANSYT 14, TRANSYT has had the features and functionality to do this, and has the added convenience of being able to model both signalled and unsignalled scenarios in the same TRANSYT file.

TRANSYT 15 now offers a full set of priority objects, allowing unsignalled roundabouts, crossroads and T-junctions to be modelled within a network or on their own. These have the same data requirements as the standard ARCADY and PICADY models - The data is stored conveniently within the one network file. With TRANSYT allowing different cycle times to exist within the one file, TRANSYT has the capability to model different signalled and unsignalled scenarios within the one data file.

Note that OSCADY PRO still offers a simple alternative to using TRANSYT, at the expense of not containing any of the advanced networking capabilities that TRANSYT has. Both products will give similar results for the situations that they both can model. Of course, TRANSYT's capabilties stretch well beyond that needed to model single junctions, and now includes easy-to-use phase-optimisation as well!

TRANSYT can be easily extended to model the effects of adjacent junctions if it subsequently becomes know that they are affecting the performance of your initial junction. The new merging function and set of library files, makes it very easy to merge individual junctions into other TRANSYT networks.

NEW: Follow the link to a video that provides a detailed guide on modelling a single signalised junction with TRANSYT 15 and also demonstrates how quickly a single junction can be built using the library file system.

If you notice that network performance has reduced significantly when you have changed one or more traffic streams or links in your network from PDM to CTM the most likely reason for this is the fact that CTM models blocking back effects within the network, while the PDM does not.

Another reason can be due to a network coding mistake if you have any unrestricted traffic streams or links in your network. When switching from PDM to CTM the Traffic Stream data item 'Cell Saturation flow' is used by TRANSYT 14, and must be set to a value appropriate for the number of lanes. If you forget to set these and have unrestricted traffic streams representing more that one lane, you can be erroneously restricting traffic flow. This restricted traffic also has the potential of blocking back into the network causing considerable blocking effects.

If unsure what value to set for the Cell Sat Flow, a good starting point would be to set the values to what RR67 would give you if all traffic was assumed to be going straight ahead, summed for each lane represented by the traffic stream. You can also take account of the standard RR67 reduction for a kerbside lane. Using this method will ensure that the relatively high initial capacities that are achieved at the upstream end of the downstream traffic streams (due to short headways) are modelled. However, you may wish to use a lower cell saturation flow, that more realistically reflects the overall capacity of the traffic stream.

Traffic stream capacity (as opposed to stopline capacity) is determined by 'headway' - which is affected by many factors including, but not limited to, vehicle speed, lane width, road works, parked vehicles, % of heavy vehicles, weather conditions. Taking account of these effects can improve the accuracy of your model. You may find TA 79/99 "Traffic Capacity of Urban Roads" a useful reference.

Collections/routes allow you to obtain results for a subset of links or traffic streams within the network. These can be particularly useful at times, but care needs be taking regarding the interpretation of what the results are telling you.

It is recommended that if you are not familiar/knowledgeable about the output results from collections, that you bring up the TRANSYT Glossary screen (see Main Menu > Help > Glossary Screen). Whenever you select a data item in the data editor the glossary screen will present information about that particular item. Importantly, in the context of collections, it tells you how the value is derived - is a SUM, AVERAGE, WEIGHTED AVERAGE, or 'SPECIAL' calculation. This helps you to understand what the collection output represents.

However, even with the help of the glossary, there is still some scope for misunderstanding. For example, one of the commonest misunderstandings is to fail to realise that collection results will be PER LINK.

An example of this is the output value "Journey time per PCU". Collections simply average or sum the values that you obtain for each link in the collection. This has the unfortunate effect of suggesting that journey times along a route can be obtained in this way. What the "journey time per PCU" actually represents is a "weighted average" (see glossary) of all the journey times on ALL links in that collection. This means that the times relate to journeys PER LINK within this subset of links. It also means it includes ALL movements of ALL traffic - not just those that are taking a particular route through the network. So in this context "journey Time Per PCU" represents... "Journey Time Per PCU per link within the collection and for all traffic movements within this collection".

All is not lost however - You CAN obtain good accurate journey time results of you use an OD Matrix to allocate traffic flows to your network. As well as making it easier to get flows into TRANSYT, OD Matrices also report journey times. The journey times between each of the LOCATIONS within the OD Matrix is reported. These are genuine journey times for the traffic making that particular journey. Please note that summing multiple OD Matrix journey times to make up longer overall journeys will again result in inaccuracy due to the fact that the overall journeys will include data associated with traffic that only completes part of the journey, which may experience slightly different delays. However, in most cases the inaccuracy is likely to be relatively small compared with the overall journey times.

Here we have a situation where one link feeds two downstream links that share a common movement.

This is illustrated in the link diagram below,where link 15 feeds links 24 and 25. Assuming that there is good reason why links 24 and 25 have been separated, there is the potential for these links to be used differently depending on whether traffic from link 15 receives green or red. It may be that, during green, only one of the links is used; conversely the links may both be usable (though not necessarily equally so) during red.

Generally speaking, the assignment of traffic during green is of little consequence compared to correct assignment during red, where queueing behaviour, queue-lengths and the discharge rate of the queue are the main concerns. During green, the ‘OUT’ profile of the traffic on links 24 and 25 is governed by the ‘OUT’ profile on link 15 and not any characteristic of links 24 and 25. It does not matter whether traffic uses the nearside or offside lane, or even straddles the lane marking, the model retains its integrity.

However there may be something to look at when both upstream entries (links 10 and 15) are considered. It may be that the majority of traffic on link 10 is turning right at the next stop line; hence needs to use just link 25. Traffic from link 15 may be split in its required destination such that links 24 and 25 are equally useable on average. If the traffic from link 10 hits red on link 25, it might form a significant queue on that one link. When traffic from link 15 reaches that approach, drivers will naturally choose the lane with the smallest queue until both queues are about equal in length, thus tending to use link 24 more than link 25. On the other hand, if it is traffic from link 15 that hits the red first, it will queue evenly (or less unevenly) on both links. Hence the assignment could be different depending on the coordination.

If this presents a problem, a possible solution would be to assume that both links 24 and 25 are used by traffic from link 15 (equally or unequally as appropriate) and see whether the timings from TRANSYT mean that this traffic hits red before traffic from link 10 or not. If the traffic from link 10 hits red first, you may need to increase the proportion of link 15 traffic entering link 24. If after running TRANSYT once more, the coordination changes so that link 15 hits red first, you need to choose which of the two timings you prefer, assign traffic as required, and fix the offsets by grouping the two nodes. This way the assignment will remain correct for optimised timings produced in further runs. Notice in the solution that we are still concentrating on what happens during red and not green. Which of the links is used during green is, as before, of little consequence.

Update (2015): Although this FAQ is illustrated using a LINK structure, the issues it raises are still valid for a Traffic Stream one, and relevant to all versions of TRANSYT. The difference is that it simply easier to adjust how much traffic is using which PATH through the network when using Traffic Streams and their associated OD Matrix.

TRANSYT 16, 15, and 14: An alternative method can be used to model this kind of situation, by setting up explicitly the lane and traffic stream structure and using the "Flare" traffic model appropriately to represent the short bays that might block back.

TRANSYT 13 and earlier:

The diagram depicts an entry four-arm roundabout where the nearside lane splits into two: a bay for left-turners only, and the main lane catering for both straights and lefts. There are two objectives in modelling this stop line, which, as we shall see, conflict. Firstly the capacity of the approach requires that all traffic is modelled, which ideally requires the flare parameters to be specified in CT33. However, if variable saturation flow was modelled, arrival patterns on the down-stream link would be ‘nose heavy’. In reality, the down-stream arrival pattern would be constant because all left-turn traffic will have left the system, leaving straight-ahead traffic only to be modelled on the next link.

Modelling this uniform saturation flow correctly requires a single entry link on which the left-turners are ignored and the saturation flow is reduced by the proportion of the total traffic that travels straight-ahead (i.e. 500/850). Modelling the situation as described would be sufficient, unless left-turners either; (a) needed to be modelled further downstream, and/or (b) dominate the capacity of the approach.

In case (b) two TRANSYT runs would be required; the first would include the left turners, thereby deducing the green time required by that entry for capacity reasons; and the second would fix on that green time, and, by ignoring left-turners, calculate optimum offsets between junctions.

Also shown in the diagram is a situation where the main lane bays share common movement, as in the previous example. Unlike the previous example though, all the traffic in these lanes travels onto the next down-stream link; hence the variable saturation flow model will be required.

The difficulty here is that because the bay and main lane share the right-turn movement, right-turners can choose to queue in either. But, because the straight-ahead traffic is not free to choose, not only will the utilisation of the bay be under 100%, but it will also be unpredictable. In this example the bay is relatively short and a sensible guess at a utilisation figure would be acceptable (e.g. 3 per cycle). However, with longer bays, observed values ought to be used.

I have two parallel links (with the same link length) - one is for general traffic and the other is an adjacent bus-only link. Having looked at the relative cruise times I have noticed that despite accounting for different crusie speeds and the bus stopped- time there is still a discrepancy in the cruise times shown in the output. Why is this?

On top of the user-specified standing time of the buses on that particular link, TRANSYT adds on additional time (to the cruise time) to account for the deceleration and subsequent acceleration back up to the cruise speed on links that have bus stops. This time depends on the link length and cruise speed specified. E.g. the time taken to accelerate and decelerate is deemed to take about 16 seconds as long as the link can fully accommodate this manoeuvre within its length. For short links this time will not be accommodated and hence the additional time lost due to acceleration/deceleration will be less as a result. With a specified cruise speed of 30 km/h on a link which is over 60 metres long, this extra time is close to 9 seconds.

The default values used in TRANSYT are those dating back to 2003. For anyone wishing to use more up-to-date values the following new values have been calculated by TRL with reference to WebTAG data for Year 2012.

Monetary value of delay = £14.61 per pcu-hour (2012)

Monetary value of 100 stops = £2.00 (2012)

See the relevant sections of the TRANSYT User Manual for more details about how stop and delay values are used by the software.

No restrictions.

Clearly if all the junctions in the model were a mile apart, TRANSYT would be of little use. The longer the links are the more dispersion will occur and there will be an associated reduction in the potential benefit gained by good coordination of traffic signals. The mean modulus of error (MME) value, reported in the cyclic flow profile (CFP) graphs in the TRANSYT output is a measure of how far the profile of arrival flow deviates from the mean. This gives an indication of the benefit of good coordination - a value of zero indicates no benefit. The spread of the CFP of the flow up to the stopline (i.e. the IN-profile) will also indicate the spreading out of the traffic by the time it has reached the downstream link.

Do we need signals? This is a fundamental question maybe we should be asking ourselves, given the costs involved.

Traffic signals can breed more traffic signals as once one set goes in, it may seem natural to also signalise adjacent junctions in order to gain coordination benefits from the situation. Therefore, is there an easy way to assess whether or not adjacent UNSIGNALLED junctions NEED to be signalled?

The performance of the unsignalled junctions are likely to change due to the presence of the upstream signals platooning the traffic which feeds them. This can introduce regular gaps in traffic which may allow several approaches to the unsignalled junctions to benefit.

One of the great things about TRANSYT is that it can model fully unsignalled junctions within a network, so it can be used to model the effects described above.

There are a number of YouTube Videos that will help you get to grips with TRANSYT.   At least one of these covers the basics of setting up a a simple network and running it.   Others cover more specific features of the product such as how to model priority junctions, and how to optimise for arterial routes within networks.

www.youtube.com/TRLSoftwareChannel

Some of the videos are recordings of our series of Webinars.   To find out when our next ones are please go to www.trlsoftware.com

TRANSYT 16, TRANSYT 15 and TRANSYT 14:

These versions of TRANSYT allow a full intergreen matrix, and phase delays to be specified, so that start and end lags are no longer required. Early phase starts are now represented using these features, in a more intuitive and conventional traffic engineering way.

There are also various options available to make modelling adjustments to green times when necessary, either on a phase or directly on traffic streams and links. For example, in TRANSYT 16.1.4 onwards you can add traffic stream "green start adjustments" and "green end adjustments".  These adjustments have a variety of uses.

TRANSYT 13 and earlier:

With normal data, the minimum possible intergreen time would be 1 second. Should an intergreen time of less than 1 second be required, the global start-displacement value can be set to zero and the start-lags for any links starting early can be set as required. If the lowest start lag was used (1 second), it would, in effect, give an intergreen of minus 1 second (see diagram) because the effective green and real green are starting at the same time; normally the effective green (as determined by the global start-displacement value). Remember that, if doing this, all the link start-lags have to be set to account for the fact that the start-displacement is now zero rather than 2; normally this would mean adding 2 seconds to start lags. Also remember that real green times would start earlier than TRANSYT says they do. (see ’TRANSYT greens’ in the diagram.

(Updated 2023)

Question: Bottlenecks sometimes can appear to have excessively high arrival flow rates on the downstream links. How do i fix this?

Answer: In fact the problem is not related to the bottleneck mechanism at all, but is perhaps most likely to be recognised there. Bottlenecks are used to constrain traffic to lower saturation flows than would otherwise occur – e.g. platoons passing over a narrow bridge.

A brief statement of how TRANSYT matches up differing values of total link inflow and outflow is helpful. There is no requirement in TRANSYT for the sum of inflows and the total link flow to be the same; after all they are different junctions and will almost certainly have been measured on different days.

TRANSYT handles this situation by assuming that the link total flow is accurate, and factoring the inflows such that the sum of the factored inflows is equal to the specified total link flow.

This system is fine if the inflows and outflows are roughly equal, which is of course normally the case. If however there is a gross mis-match in the inflows, then the factoring process will of course not only raise the total flow value, but also proportionately raise the flow in each individual step. The modelling is such that the increase (or decrease) has to occur by factoring the flow in each step, and not by spreading the increased (decreased) flow across more (less) time steps. The figure shows how, in a very simple case, a link outflow profile can be higher than the previous link saturation flow due to the effects of factoring.

Thus, despite the effects of dispersion, it is possible to get traffic arriving at a downstream stop line at a higher rate than the saturation flow at the upstream stop line. This is clearly impossible, and warns that the model needs to be checked. First check that all inflows have been specified – if one is missing, this can cause substantial factoring of the others! Otherwise it is just a matter of reconciling the flow differences.

TRANSYT 16.1.4 or later:

Bonus greens and other adjustments to effective green times that may be needed, can be modelled most easily by applying a traffic stream or link "green start adjustment" or "green end adjustment".

N.B. The ability to apply phase-based "relative start displacement" or "relative end displacement" is retained. However, for some scenarios, such as bus setbacks, you will find the new "green start adjustment" or "green end adjustment" easier to use.

TRANSYT 15 and up to TRANSYT 16.1.3:

Bonus greens can be modelled by changing the phase-based "relative start displacement" or "relative end displacement" values in order to differentiate between 'actual' green time and 'effective' green time.  Within the TRANSYT model, these values 'combine' with the network wide start and end displacement values - which are often set to 2 seconds and 3 seconds respectively.   "Relative start displacement" and "relative end displacement" values can be either negative or positive, and are specified as part of the PHASE DATA.

Note: In situations where two traffic streams are controlled by the same phase, but require different displacement values, the phase should be copied, and set to control just the one traffic stream.  The displacement values can then be changed as required on just that particular phase, leaving the other phase (whose actual green times will be the same as the other phase) with the original start/end displacement.

(Updated - June 2023)

Question: I’d like to know how to fix the length of a stage that has traffic on it. The particular stage mostly has pedestrian phases running but also has a vehicular traffic phase running too; hence the need to ensure the optimiser does not try to favour traffic during optimisation.

Answer: TRANSYT 16, 15 and 14 only: Although you cannot add a stage maximum, you can set a maximum green time for the relevant phase. This should be sufficient for you to resolve this issue.

There are a number of ways you can find out about TRANSYT's capabilites:

1. This website obviously - There are a number of pages dedicated to TRANSYT and its related products such as Junctions, and UTC Powered by SCOOT 7.

2. Training: TRL offer standard training courses, and occasionally upgrade courses too.  Scheduled ones are advertised here: http://www.trlsoftware.com/support/training.  TRL also offers to run bespoke courses for clients either here at TRL head office or at any suitable location in the UK or overseas.

3. Webinars are a great way to learn more about TRANSYT. Scheduled webinars are advertised here: https://www.trlsoftware.com/webinars

4. Contact TRL Software ([email protected]) by email or phone and ask us! - TRANSYT's Product Owner will be happy to provide the information you may need to assist you in deciding if TRANSYT satisfies your specific requirements.

TRANSYT 16, 15 and 14:  Although the below (described for TRANSYT 13) also applies to TRANSYT 16, 15 and 14, the use of OD Matrices to allocate traffic to the network should ensure the consistency of the flows within each OD Matrix 'zone'.  Inconsistency of flows at the boundary of two OD Matrices however can still occur and should be checked for.  The same scaling of flows occurs (as described below) where inconsistencies are present.

TRANSYT 13, and TRANSYT 12:   Typically the flows specified in TRANSYT can be inconsistent simply because they are often obtained from on-street measurements made at different times. TRANSYT automatically increases or decreases by the same proportion ALL source (upstream) link entry flows so that their combined value is the same as the link’s "Total Flow". This effectively means that the upstream entry flows are not used directly within TRANSYT and are simply defining the PROPORTION of the total flow for that link that is coming from the specified source (upstream) link, e.g. doubling all the source entry flows on a particular link would produce the same TRANSYT results.

TRANSYT works out what factor to multiply the total flow on a source link by, in order to provide the downstream link with the right flow (based on the relevant proportion of the Total Flow for the downstream link).

Both TRANSYT 12 and TRANSYT 13 indicate when discrepancies occur, but show the data slightly differently and have different 'trigger' points. e.g.

TRANSYT 12:  If a link U flows into several downstream links, TRANSYT checks to see if the flow to any individual link is greater than twice the total flow on link U and if so produces a warning message. See the example below:

e.g. This scenario (see diagram) would produce the following warning:

LINK 5 IS MULTIPLYING UPSTREAM FLOW ON ENTRY 2 BY 327 PER CENT

TRANSYT 13:  If a link U flows into several downstream links, TRANSYT checks to see if the flow to any individual link is greater than 125% of the total flow on link U and if so produces a warning message. Therefore, please note how TRANSYT 13 more-readily produces warnings of this type.

On the Task List:   Link 33: downstream flow apparent gain = 68.36 (327.87%)

TRANSYT does NOT check to see if the sum of all flows out of U is greater than twice the reported flow on U. Therefore, whether a warning is given will depend on the total flow for U, and so it's possible that for a given downstream link D, a warning may get written for some upstream links but not others.  N.B. TRANSYT only stops a run and produces an error message (instead of a warning) when any upstream flow is scaled by a factor of 6000%!TRANSYT is multiplying link 33 total flow by 3.27 in order that it provides link 5 with the traffic flow it is expecting, i.e. 100 / (100 + 205) * 300. N.B. The reference to ENTRY 2 in the error message is simply referring to the second defined upstream link of Link 5 (in this case Link 33) and is NOT a link number.

Question: How does the time-segment length affect TRANSYT results? Does it have the same effect as the “simulated time period” in TRANSYT 12?

Answer:  In TRANSYT 16 (and 15,14,13), the TRANSYT 12 “simulated time period” is now called “modelled time period”.  As you will probably know, these newer versions of TRANSYT allow varying traffic conditions over time (segments) to be modelled.  This means that the “modelled time period” is no longer entered directly by the user, but is simply calculated by TRANSYT as “Number of Time Segments” x “Time Segment Length”, which ARE both user-specified.  The “modelled time period” works in the same way as the original “simulated time”.  E.g. most of the TRANSYT outputs reflect the average (e.g. Mean Max Queue”) value over the modelled time period.

N.B. A previous article explained how you could use the simulated time to give an estimate of the MMQs at the END of the time period rather than the average.  This process is no longer necessary for this particular need, as the TRANSYT results now include an output value (see excerpt from the Link Results table: Queue and Blocking below) called “Mean Max Queue EoTS”.  EoTS stands for “End of Time Segment”.  Obviously when you have just one segment, this value is also the MMQ at the end of the modelled time period.  When using multiple segments there will be one for each segment.

Link Results: Queues And Blocking

Furthermore, please remember that most TRANSYT outputs are shown as ‘rates’ - usually per hour – and as such need to be scaled by the time-period if you wish to know absolute values for the time period being modelled. E.g. If the segment length is 30 minutes the total flows and saturation flows are entered by the user, and output by TRANSYT as hourly values.  To work out the total flow over a stop line during a 30 min segment, you will need to divide the results by two.  However, even when segment lengths are fractions of an hour, it is normally easiest to continue to work with rates throughout rather than absolute values.

(Article updated - June 2023)

Problem: I cannot correct flows to reflect the allocation of flows that I want. Using either Lane-balancing or Path-equalisation appears to help a little, but still does not allocate some flows as I would like and each fails to allow me to even correct entry flows into the network to match local matrix totals.

Answer: There is never a guarantee that the allocation method used will suit ALL situations – so there is the facility to overwrite whichever allocation of flows (to each path) you don’t like. This is done using the “Paths” tab – see screen shot (and AG65 Section 11.3.3). The allocation type is defaulted to “Normal” which basically means it will use whatever of the two automatic allocation methods you have chosen – either “path allocation” or “lane balancing”. If neither of these is working as you want them to, then you can change from “normal” to one of the other allocation types – “Fixed” (flow), “percentage” or even “disable” paths that you consider no traffic would use to make that journey. This offers as much flexibility in the allocation process as you should need.

If you are finding it hard to come up with signal timings that work for the traffic flows you need to accommodate, here are a few tips that might help you towards a solution:

1.  Try a wider variety of cycle times, not just units of 10 seconds.

2. If you have any multiple cycled controllers, make sure the option "Equal Length Multiple Cycling is switched off.  This gives the optimisers the greatest freedom to find a solution.

3. Use either of TRANSYT's alternative optimisers - Shotgun hill-climb or Simulated Annealing:

Both optimisers take significantly longer to run, but will give better results in the majority of cases.  note also that both optimisers have parameters that can also be varied - for Simulated Annealing the higher the temperature and the slower it is set to cool will increase the time to run but will improve the chances of the best result.  For Shot-gun hill-climb the only parameter is how many starting points (runs) that you want - 10 runs will increase the time to run by 10, and so on.  Increasing the number of start points will increase the chances that a better solution is found.

4. If you don't have the latest version of TRANSYT or any version since TRANSYT 14, you are of course more limited in what you can do, but you can still increase the number of hill-climb increments, or if you have TRANSYT 13 or later, use the "Enhanced Optimisation" option which forces TRANSYT to repeat the full set of hill-climb increments until no further improvement occurs in the PI.  The "Extended -offsets and green splits" optimisation level option can also be used as this adds extra items to the hill-climb list that makes bigger incremental changes to the green times - This increases the time to run only marginally, but the benefits are also relatively modest on average - The main reason for use of this option is for linking to microscopic models to ensure they react enough to the changes being made.

5. Try different stage sequences: New sequences can be easily added and stored in TRANSYT 14 or later.  These newer versions of TRANSYT have also inherited functionality from OSCADY PRO so phase and stage sequence optimisation can now be carried out on junctions within a TRANSYT network.  From the Timings Diagram use the menu option "Tools/Phase Optimiser/This Controller".  This is a very powerful function that allows you to find the best solution for each individual controller.

Question: I want to call up a pedestrian cycle in alternative stages. I am not sure how to input this into the model.

Answer:  You have either one or two options how to do this, depending on the version of TRANSYT you are using, and is relatively easy to set up.

(1) The first option, which is available in all versions of TRANSYT is this, and here are the steps involved if using TRANSYT 16:

1. Double-click on the controller in the Network Diagram - That will bring up the Controller Streams data screen
2. Select the "Stage Sequences" tab, and change "Multi-cycling" to "Double"
3. Open the Phase "Timings Diagram" (if not already open) - There is a shortcut (button) on the Controller Streams data screen to do that
4. Press the "repair timings" button to repair the stage timings
5. Select Tools > "Convert all stages to base stages". This means you now have every stage running twice within the cycle - N.B. you may need/want to double the cycle time at this stage. The need to convert the stages to "base stages" is to allow you to remove one of the stages which runs your pedestrian phase.
6. (N.B. The following assumes you have at least 3 stages)
7. In the Timings Diagram, right-click on the first or second stage that is running your pedestrian phase, and select "Remove Stage".
8. Press the "repair timings" button again, to repair the stage timings

You now have your pedestrian phase running every second cycle in effect - technically you have all but the stage containing the pedestrian phase, running twice in one cycle.

Through the use of triple or quadruple cycling, you can choose to model a pedestrian stage that comes in every second, third or fourth cycle, in effect.

N.B. alternatively, you can create the required new stages manually using the data outline and data editor, and then change the stage sequence that TRANSYT is currently using. Both methods result in the same file data, but it will often be quicker to do it in the way set out above.

(2) The second option, which is only available in TRANSYT 16, makes use of a relatively new facility provided through the use of TRANSYT's "Simulation Model".  Please note that in Simulation signal timings cannot be optimised.

1. Switch your model into Simulation, by clicking the "Simulation" button on the left-hand vertical toolbar
2. Navigate via the Data Outline to the "Library Stage" that is your pedestrian stage
3. Click "Allow intermittent occurrence"
4. For the stage, you now have the option of getting it to "Run every N cycles" or entering a "Probability of running".
5. We do not recommend selecting both, so either leave "Run every N cycles" = 1, or "Probability of running" = 100%
6. By changing one of these parameters you can control what happens - either your pedestrian stage will run regularly every N cycles, or it will run randomly (i.e. be skipped sometimes) such that on average it will run in X percent of the cycles

This second offer offers, at the expense of not being able to optimise timings, a more accurate portrayal of your pedestrian crossing, and hence give better results.

(Article updated - June 2023)

Question: What if I wish to optimise the node offsets of a network, but do not wish to change some specific green times?

Answer: In TRANSYT 16 and TRANSYT 15, under "Controller Stream N > Optimisation (OFF/ON)" you can simply deselect the box "Allow Green Split Optimisation". This will ensure that the green times on Controller Stream N will not change.

In TRANSYT 14, under "Network Options > Optimisation Options" you can add the controller stream ID to a comma-separated list of "Locked Green Splits". This will ensure that the green times on the controller streams listed will not change.

In TRANSYT 13 it not quite so easy to lock green splits, but you can still manage it relatively easily. If you specify your previously-established green times as “User Stage Minimums” for each stage of the node, this along with your intergreens, will define the whole of the cycle (which you have to enter). As a result the TRANSYT optimiser will no longer be able to adjust green times and can only adjust the offset.

TRANSYT 16, TRANSYT 15  and TRANSYT 14: This issue is now redundant in these versions.  You simply define the number of conflicts that you have and then set for each conflict, whether or not ALL the traffic is opposed or just a particular movement.  Same flexibility also extends to the opposing traffic.

TRANSYT 13 and earlier: LOGICALLY you might think that setting two controlling links and then specifying that 100% of the traffic gives way to just the first link would be the same as specifying only one link in the first place.  However, the TRANSYT model is affected by whether or not one or two controlling links are specified and hence TRANSYT may give slightly different results. Therefore, when specifying the number of controlling links in TRANSYT that a give-way has to give way to, only specify two controlling links if some or all of the give-way traffic gives way to both links.

Question: When collecting data for TRANSYT models by what method do TRL measure on-street SATFLOWS? Or is there an industry standard method by which this is done?

Answer: Road Note 34, which describes a methodology involving recording flow rates over 6 second intervals can be used.  RN34 requires a minimum of 12 seconds effective green to be useable. You may find you need to adopt a different method if saturation flow does not last very long.

An alternative is to measure all of the sat flow excluding the first two vehicles at the start of green, by simply counting the vehicles until satflow ends and then recording the length of time the recording was for. This method however has its drawbacks as it does not allow you to analyse the data for each 6- second period so you may miss the fact that you might be recoding far too long in each cycle such that the flow has dropped below satflow.

A TRL mobile software application is available that implements the RN34 methodology.  This is part of TRL Mobile Traffic Apps.

In all versions since TRANSYT 13, the maximum limits are 1000 links and 200 nodes.  The 1000 link limit also affects the number of traffic streams in TRANSYT 14 and more recent versions.

In TRANSYT 12 the maximum limits are 500 links and 100 nodes.

After the start of green, vehicles arriving on a link add to the back of the queue, whilst other vehicles clear the stop-line from the front of the queue. Where blocking back may be a problem, the time when the back of the queue is most likely to interfere with an upstream junction occurs around the time when the queue is finally clearing. The last delayed vehicles will come to a stop for just a few seconds in the TRANSYT model (a partial stop), whereas real vehicles would merely slow down as they join the tail of the clearing queue, before accelerating away again. The MMQ is the estimated mean number of vehicles (or pcus) which have added onto the back of the queue up to the time when the queue finally clears.

This part of the TRANSYT model is not fully realistic. Modelled traffic is taken to travel the full length of the link at cruise speed before adding onto the queue. This may best be thought of as traffic adding onto a vertical heap at the stop-line, rather than the real situation in which the queue stretches back up the link towards the upstream junction. Consequently, the time in the green at which the maximum queue occurs is somewhat later in TRANSYT than in reality.

The other difficulty in interpreting the MMQ value is due to it being a mean value. It will therefore be exceeded in 50% of cycles during the period being modelled. The shape of the distribution of queues about the MMQ is not known, nor is its standard deviation. It is not possible to quote the value for the queue which will occur in (say) the worst 5% of cycles. One reason for this lack of a predictive formula for the distribution of queues is that it depends partly on the degree of saturation of the feeding links. If the upstream feeder links are nearly 100% saturated, then there is less scope for cycle-to-cycle variation in arrival flow downstream. The converse is true for feeder links with low degrees of saturation.

As a rule of thumb, and it is no more than that, extreme queues could well be 50-100% bigger than the mean value output; the 100% extra being for small MMQ values (single-digit MMQs).

The MMQ value is particularly designed for use with the Limit Queue facility which is set up using a card type 38. Allowance for cycles with more extreme queues than the mean will be necessary when choosing a limit queue. A value of two-thirds or half the actual storage capacity of a link is often used so that, if the MMQ can be accommodated within this limit, there is still some extra storage for more extreme queues.

For links which are more than 100% saturated, the MMQ is the mean of a queue which is steadily increasing over the modelled period. Thus, at the end of the period, the final mean queue will approximate to twice the MMQ given in the output. You will need to look carefully for such problems when interpreting your results. This is when you have to earn our reputation as traffic signal engineers: TRANSYT is a tool and not a wonder black box which always gives the right answers!

In one case, it appears that a customer subsequently specified that a signal system on a roundabout should be designed so that the MMQs were never more than 50% of the available queueing space on circulating links.

The article was intended to explain the meaning of the MMQ, and did not attempt to define precisely how TRANSYT should be used in the design process to produce timing plans. Often, practical constraints mean that any solution may be less than ideal. It is up to the design engineer to understand the modelling and optimisation process, and to make use of the various facilities (such as Limit Queues and Link Weighting Factors) to produce the best, acceptable solutions.

Defining what are, or are not, likely to be practical working solutions requires experience and judgement. The design engineer must examine the results that are output from TRANSYT to see when precisely the build-up of queues on critical links takes place, in relation to the red and green times.

Sometimes, the designer of signal plans for roundabouts/gyratories will find that MMQs which exceed the normal limit queues can be tolerated provided that the cycles when bigger-than-average queues occur do so when any blocking-back merely inhibits for a short time the passage of more traffic entering the system. Conversely, if they occur when blocking-back would inhibit the passage of circulating traffic, then this is usually unacceptable because it is likely to cause lock-up of the roundabout. What one is particularly looking out for is the well known shock-wave effect where an arriving platoon experiences a brief delay while a standing queue clears downstream. Such shock-waves cause large MMQs in the TRANSYT results, which may or may not be tolerable depending on their timing.

The diagram shows the layout of the most common type of bus set-back, and it is straightforward to model.

Traffic Stream network structure (TRANSYT 16):

The buses can be modelled on a bus lane using a separate traffic stream. Simply specify the traffic stream "traffic type" as "Bus" and set the bus stopped time and (bus) average cruise speed. The flow is just the buses flowing along that bus lane.

A setback looks like a flared approach to non-bus traffic and can be modelled as such. The average utilisation of the 'bay' needs to be estimated. Buses will start off later as a result of having to wait for any traffic in front to discharge. This can be modelled easily with a "green start adjustment" on the bus traffic stream (within the "Signals" tab of the "Traffic Streams" data screen).  This will be approximately 2 seconds per vehicle that has been estimated as queuing in front of the bus on average.

Link Network Structure (TRANSYT 16):

The first important point to note is that two separate links should be used - one for each lane.  This is not a scenario where shared links (a 'link-share') can be used, as the two lanes have very different uses. You need to set the "Traffic type" of the link representing the bus lane to "Bus".  This will then allow you to enter (under the Link Data screen "Flows" tab > "Sources" tab) the bus "free running speed (or time)" and "stationary time", i.e. the time spent at bus stop(s).

Next, the link for the other traffic takes the form of a flared approach and can be modelled as such in TRANSYT.  Decide how many vehicles, on average, will use the space between the end of the bus lane and the stop line; then estimate the saturation flow of the short lane or bay (TRANSYT is not especially sensitive to this value). Enter these into the TRANSYT model.

Finally, you need to add a "green start adjustment" (see the "Signals" tab) to take account of the time it will take (again on average) for the first bus to cross the stop line after the start of green.  This will be about two-seconds for each vehicle between the bus and the stop line.

Earlier versions of TRANSYT (prior to TRANSYT 16.1.4):  Traffic Stream and Link "Green start adjustments" do not exist, so contact TRL Software for details on how to make the necessary equivalent green time adjustments to the model.

The mechanics of a funnel are of interest. Let’s start by considering a two-into-one situation under ideal conditions where both entry lanes are fully used. As the lights turn green, traffic will move freely. As the first cars reach the point of restriction, a ‘shock wave’ will start to work back to the stop line as the funnel fills. When this reaches back to the stop line, the capacity will be limited to single lane saturation flow (approximately). This is the same sort of effect that a flare has on capacity.

What is the best way to model this? Firstly, it is necessary to highlight one way that is NOT acceptable. In OSCADY, the exit width restriction looks to be an obvious way to account for funnels. It isn’t. This value is designed to account for situations where the lanes are a little narrower on the exit than at the stop line; it does NOT account for a reduction in the NUMBER of lanes. In fact, attempting to use the exit width restriction value to model a two-into-one situation (say) leads to a very modest reduction in the capacity predicted by OSCADY when compared to a situation with no funnel, far more modest than you might expect in reality.

The question is how best to model funnels. One way is by using the flared approach modelling facilities (and this applied equally to TRANSYT and OSCADY). Simulation testing has indicated that a value to use for the number to enter for the storage of the flare is the number of extra vehicles that fit into the funnel. This works for the idealised situation (described above). However, this idea will need adjusting when the approach lanes are used unequally, as is usually the case. Then it would seem logical to use the flare approach model again, but decide the storage value on the basis of which side of the junction is restricting capacity most. If, on average, the queue on the feeder lanes is less than the funnel can cope with, then the storage will be the average utilisation of the least-used lane. On the other hand, if the funnel is regularly filled, the storage value should be the number of vehicles that can use the extra space in the funnel.

Further complications to think about are the effect of turning traffic and where the two (or more) lanes on the approach have to be modelled as separate links. Solutions in these cases are likely to be quite specific.

The first situation that has been tested is where a single entry link gives way to either one or two circulating (major) links. The two models have been made to be equivalent in the following way. In Figure 1a, link 30 is giving way to link 31: the only give-way coefficient required in this case is A1. In figure 1b, link 35 is giving way to 31 and 32: in this case two give-way coefficients are required, A1 and A2. For the two situations to be exactly equivalent, A1 and A2 in 1b must both be the same value as A1 in 1a (not half or any other contrived value). ARCADY would normally be used to obtain the parameters. When modelled in this fashion, the results for link 30 are exactly the same. Shared links can be added as needed in either situation, although it is essential that the entry link gives way to only the master link(s). Specifying a minor link as a priority link will give the wrong results, but it will not lead to any run-time error or warning.

The second situation is the reverse of the above, where the give-way entry is split into two links (see Figure 2). Using two links to model the entry has been considered by some to be more correct when traffic forms distinct queues in separate lanes. We have not been sure that this is the case and have for some while now wanted to see if a priority approach can be modelled with two or more give-way links.

To consider this I have split the single give way link (link 30 in Figure 1a) into two give-way links (links 35 and 36 in Figure 2). To engineer the two situations to be equivalent, the maximum flow values on links 35 and 36 need to total to the maximum flow on link 30. The coefficients on links 35 and 36 need to be reduced in proportion to the maximum flows. In the model set up for comparison, I halved both the maximum flow and coefficient for links 35 and 36 as compared with link 30. With half the traffic flows as well, the results from the two models might be expected to be similar. It turns out that the capacity of the two situations is, indeed the same, with identical degrees of saturation. The uniform component of delay is also the same. However, differences occur in the random-plus-oversaturation part of the calculations, which, with two links instead of one, make the two-link model predict higher stops, delays and queue lengths. There are examples of figures from the final TRANSYT output table shown at the foot of this page.

As can be seen, the differences between the two models are quite marked with the two-link model significantly worse in delay terms. It should be noted, however, that these two models probably are not directly equivalent after all. In this single link example, all lanes are equally used with queues being nearly equal. In the above two-link model, the average queue will be the same for both lanes, but the randomness of arrivals will mean that the links will ‘take it in turns’ to have the longer queue. Such unequal queueing is likely if lanes are used for different destinations, in which case the more pessimistic two-link model may be more appropriate. A single link model will be appropriate when adjacent lanes share a common movement so giving the opportunity for drivers to choose between two or more lanes. When using a two link model it will be necessary to derive the maximum flow and give-way coefficients using ARCADY by, in effect, modelling the two parts on an approach as separate entries. This will give the two sets of parameters required.

The final issue concerns the two-link model again (Figure 2). It might be argued that a nearside lane does not give way to all the circulating traffic, because drivers can see that some of the circulating traffic is not going to impede them. If using a single link model with parameters derived from ARCADY, this will not be an issue because ARCADY will have already accounted for this effect (if it exists). For a two-link model, it might be reasonable to increase the capacity of an entry if (and only if) it is clear that the nearside lane will not in practice have to give way to all the circulating traffic. However, you will need to be confident of this as there has been no work that we are aware of to calibrate or test this. It would, perhaps, be more justifiable to reduce the give-way coefficient for the nearside lane, rather than simply say it only gives way to a sub-set of the circulating traffic. How much to reduce it by needs careful thought, unless you are prepared to go to the trouble of measuring it on-street (and how to do that is a story for another day!)

In conclusion:

• There is no difference between modelling the circulating traffic with either one or two (master) links
• The give-way entry can be modelled with one, two or even more links, depending on how much choice drivers have as to which lane to use to reach their intended exit

There is little research as yet about whether any particular entry stream gives way to some or all of the circulating traffic streams and whether it is acceptable to modify the parameters because (for example) a nearside entry lane can ignore (partially or wholly) traffic in a particular circulating lane.

The presentation of this paper led me to think that the model TRANSYT uses for priority situations may not be fully understood.

Firstly, let me explain, briefly, how we suggest (but not insist) a priority approach is dealt with on a signalised roundabout. To begin with, the coefficient and max flow needs to be deduced. The easiest way of achieving this is by using ARCADY. Enter all the geometric details of the junction under consideration and you will obtain a value for the yintercept (the max flow in TRANSYT) and the slope (the coefficient in TRANSYT). It is necessary to know how ARCADY works to do this, of course. Having deduced the parameters for the priority approach this way, it is necessary to specify which link is to oppose the entry traffic. For this it is important to use just one link to model all the traffic that has priority. This may seem odd at first because you may be modelling two or more traffic streams, or lanes, and if the approach was signalled, you would need more than one link. However, using a single link is acceptable in this situation because it is unsignalled and we are not interested in how queues form and discharge: only the pattern of traffic as it passes the priority arm is needed. If it is necessary to model different movements on this link you can still use shared links, and you can use them to model different lanes if necessary in this case (but don’t even think of doing that on any signal controlled approaches!) Specify the master link as the priority link in the give-way data.

When the priority model has been specified, it is important to appreciate how it works. The relationship that is given by the give-way parameters is used in each step of the cycle, separately, to calculate the potential flow out of the give-way arm during each step. Thus, when there is little traffic on the circulating link, there should be (potentially) more flow getting out of the give-way link (assuming that there is traffic demand present). Conversely, when there is a larger flow on the circulating link, there is a limit to what can enter. This way a new cyclic profile is built up from the circulating and entry profiles to feed downstream links. The new profile will generally look like the circulating profile with the gaps filled in.

Figure 1 - Stage sequence

What the method above doesn’t necessarily consider is the way upstream signals affect traffic behaviour, especially when long intergreens are injected to produce gaps that allow downstream give-way traffic to enter. When this is the case, it is likely that the give-way traffic can see that upstream traffic has been halted, anticipate the impending gap, and be able to discharge across the give-way line, almost as if it was a signal controlled stopline. Under these circumstances, it may be worth considering Stuart Maxwell’s method as an alternative to the normal give-way model. But the consideration has to be careful and the way to model it needs some additional explanation. Below I have suggested a method that should cover all eventualities. It is not the only way, but it combines give-way and signalled parameters.

In the diagrams below, arms (or phases) A and B (see Figure 1) are the circulating and entry arms at a signal controlled junction 1. These feed arm C which is a signal controlled arm associated with node 1 (not 2). D is in fact a bottleneck link and node 2 doesn’t actually exist in the TRANSYT data. However, this bottleneck link also gives way to arm C. Now we can specify signal data on arm C that makes it red for the induced gap and arm D will use the specified standard saturation flow value during that period. The rest of the time, arm D will use the give-way parameters, with the (usually) lower maximum flow.

Figure 2 shows the timings to use when the journey time between nodes 1 and 2 is 7 seconds and the induced gap is 5 seconds (the time that A and B are both red). Both need to be adjusted to model each situation. Note that the example deals with the situation when there is one induced interstage. If there are to be two periods, simply insert another all-red stage in the way illustrated, using the second-green facility to model phases A and B.

The main advantages of this method is that both the normal priority situation and the alternative ‘neo signal controlled’ situation are both modelled together, in an automatic fashion. It can be used to set the intergreen length to the minimum required, and allow a more accurate model of platoons further downstream. Make sure that you use the cyclic flow profile graphs to see how the model is working and adjust the lags and all-red time as necessary.

Figure 2 - Timings for a 7 second induced gap

In TRANSYT a number of task list messages are presented as "Warnings" if auto-redistribute is enabled, and as an error when it is not. This is because there is an expectation that the auto-redistribution process will fix the timings prior to the main optimisation process starting. As long as there only warnings reported, TRANSYT will not prevent the optimiser running, irrespective of the outcome of the auto redistribution process. This means that it is entirely possible that the optimised solution can still exhibit unresolved phase constraints. Stage minimums can never be broken by the optimiser, so these are not an issue here.

This all leads me to the advise in the title of this FAQ - If after optimising the network, these phase constraints are still broken, then this suggests that either there is no solution out there that satisfies the various signal timing constraints, e.g. cycle time, inter-stages and stage minimums, or a solution is too hard for the optimiser to find. In this situation you should be treating these warnings, as errors that require attention. After all you set these constraints on the model - if you still believe them to be correct why would you accept timings that break them?

The solution is to re-examine the various constraints and ensure that they are all required at the values used, e.g. can a phase minimum be reduced? or can the cycle time be increased to accommodate all the constraints? You can use the "Repair Timings" timing diagram option to check if there is a solution that does not break the constraints, as this is equivalent to the auto-redistribution process.

A queue consists of three components, namely “Uniform”, “Random”, and “Oversaturation”.  Although the TRANSYT analysis takes account of all three components, the graphs display only the “Uniform” component. Therefore, one cannot use the graphs to predict blocking problems.

Alongside each graph is the “UMMQ” value, i.e. the “Uniform Mean Maximum Queue”. This figure will always be less than the “MMQ” value given elsewhere in the TRANSYT output, which includes all three components of queue. The “MMQ” value should always be used as a basis for predicting queue blocking, and even then should make allowance for variations from day to day

When shared links are specified there is only one DOS and one MMQ value for the combination of one major link and its associated minor links. The values are repeated next to each minor link purely for convenience. Therefore, the values have not been divided between the links, and so should not be summed together. Also note that the choice of which link is the major link is an arbitrary decision – it has no effect on the results.

From the above it can be seen that the value of saturation flow dictates how many vehicles can get across a given stopline within the green time (hence capacity). Stated the other way, the saturation flow dictates the length of green time needed to cater for a specific vehicular flow-rate.

TRL is only too aware of the controversial nature of saturation flows: in Research Report RR274 – ‘The use of TRANSYT at signalised roundabouts’ there were two examples quoted of saturation flows as measured at a particular roundabout. These ‘examples’ seemed to become the de-facto standard for many. There have been many occasions when engineers have asked for confirmation that they are the values to use whilst others would want us to confirm that higher values were acceptable! Our advice now is to refer to the revised text that appears in the latest TRANSYT User Guide.  The guide does not refer at all to saturation flow values, leaving it up to the traffic engineer to decide what values to use and to argue the case as necessary.

We are also often asked (as we were at the User Group meeting) whether RR67 ‘The prediction of saturation flows for road junctions controlled by traffic signals’ gives sensible answers for most situations, given the age of the data it was based upon (now more than 20 years old) on the one hand, but on the other its seemingly optimistic values that some argue are not normally seen in practice One point to remember about the data collected for RR67 is that all the sites used were classified as ‘good’ or ‘average’ as originally suggested by Webster and Cobbe in their book ‘Traffic Signals’ published in 1966. The following table is a slightly modified version of the one produced by those Authors all those years ago.

Webster and Cobbe also related the expected saturation flow of good and poor sites with average: good sites would be expected to be 20% better than average, and poor sites 15% worse. The saturation flow per ‘standard’ lane for an average site at the time (mid 1960s) was 1,800 pcu/hour. However, RR67 data was based on a combination of average and good sites. Therefore the standard lane (which is defined in RR67, but not in Webster and Cobbe) value of saturation flow of 2,080 pcu/hour is likely to apply to an approach which is better than average, but not as good as ‘good’.

Therefore, when it comes to estimating the saturation flow, a ‘rule-of-thumb’ for today’s conditions might work as follows:

• For a site that is definitely poor, a value calculated from RR67 may need to be reduced by something in the range 15 to 25 percent
• For a site that is average, a value calculated from RR67 may need to be reduced by something like 5 to 10 percent
• For a site that is clearly good, the range may be from the value calculated by RR67 to a value possibly greater by 10 percent

Some sites may be better classified by approach rather than site – there are situations where the main road is ‘good’ but the side roads poor. Main road straight-ahead traffic may have a saturation flow higher than the side roads or main-road turning traffic, if it has dedicated straight-ahead lanes.

[UPDATE - Since the release of TRANSYT 14, the required RR67 parameters can be specified for each lane and stored within the data file, allowing the saturation flow to be calculated by TRANSYT.  As part of this new feature, the site quality factor can also be specified, and will affect the calculated saturation flow.]

MOVA sites may also have a noticeably higher saturation flow – MOVA is believed to have quite a noticeable effect on saturation flow. It appears that, over time, drivers change their behaviour, probably subconsciously, as they try to ensure they get through the current green. Saturation flows of around 2,500 pcu/hour are believed to be achieved at ‘good’ MOVA sites (and TRL measured 2,800 pcu/hour on one lane at the old Hockley cross roads near Winchester, before the M3 link between there and Southampton was completed!)

Is the above of much help when deciding what saturation flow is appropriate for any given situation? Well, the idea is to provide food for thought and ideas that you can use to back-up your own judgement, which, ultimately you will have to use. We would fight shy of giving anything that is more prescriptive than that as it can be taken in the wrong way, sometimes wantonly, other times through lack of understanding perhaps. However, we are happy to debate the issue, and if anyone cares to share any measured data that they may have collected, it may be possible to refine the way saturation flow is estimated in the future.

I am getting conflicting information regarding the measurement of cruise time/speeds. By definition cruise times in TRANSYT are undelayed travelled times and therefore there is a tendency for cruise time measurements to be undertaken usually during off peak periods (early morning or late evening) when there is virtually very little traffic on the network. However, as a result, measurements made at these times do not reflect existing traffic conditions.

The problem I think is the interpretation of what represents undelayed travel time. Does undelayed travel time represent free flow under existing traffic conditions (even in peak traffic conditions) where there are no delays due to signals or queuing traffic? Currently, I am working on a model where cruise times have been measured on a very busy link during the off peak period (when there is free flow of traffic). The proposals improve traffic flow during peak periods but no changes have been made to cruise times since this is not expected to change. There has been a suggestion that cruise time in the proposed model should be modified on account of improved traffic flow in the proposed model. Should this be the case?

Cruise times should not be changed to reflect improvements that simply reduce queueing and delay as the cruise times are already meant to represent free-flow conditions. However, if the improvements mentioned involve changes that impact on the cruise speed then cruise times should be re-measured. E.g. examples of this would be stopline-to-stopline distances changing, reduction of parked vehicles and changes in lane widths and introduction of any speed reducing features/street furniture etc. (as these all affect skin friction which affects speeds). Also changes in the mix of traffic (vehicles should be selected for measurement by a random process so that the resultant cruise speed or time reflects the mix of traffic) will have an effect.

Please note that the measurement of cruise times is best carried out during off-peak periods but should avoid very lightly loaded conditions as they will tend not to be typical.

Firstly, note that an opposed right-turn link has to have both signal control data and give-way data. In the situation where right-turners do not benefit from an unopposed stage, they will turn in gaps in the opposing flow, and those waiting in front of the stopline at the end of the green will clear during the intergreen. In such cases the end lag (found in the signal control data) needs to be used to model the potential of vehicles clearing during the interstage. The end-lag time is specified in seconds and should be set as long as necessary to clear the number of vehicles able to store in front of the stopline (or, to put another way, the number that would store in front of the stopline if the approach was fully saturated). This would normally be (3600/saturation flow) x (number of vehicles stored) where the saturation flow is that specified in the signal control data (not the give-way max flow because the right-turners are unopposed during the end-lag period). Note that the end lag is a modelling feature that extends the TRANSYT effective green. It does not affect the actual green used on-street.

We often get asked what give-way parameters should be used in such a case. We normally suggest starting with a coefficient of 50 and a max flow of 900-1000. These are not to be taken as any standard figure. You should feel free to alter them in the light of experience or better knowledge if necessary. However, a right-turn movement that does not have the luxury of an unopposed period would not normally survive unless it was non-critical (i.e. very low flow) and so the give-way parameters themselves should never be critical. If they are, it probably would not be wise to persevere without an unopposed stage.

Moving on to a specific situation, consider the case where there is a single lane on the approach to the signals, with no bays or flaring, and the right-turners share road-space with other movements. In this situation, it is possible in TRANSYT to specify other movements as giving way to ‘nothing’ (leaving just right-turners giving way to ‘something’). It models the stream as-a-whole and takes account of the blocking of other movements caused by those waiting to turn. In doing so it correctly models the combined effects of other movements discharging at the signal-controlled saturation flow rate and the right turners discharging at the give-way max-flow rate. It does not allow for the fact that, normally, one or two right-turners can move into the centre of the junction out of the way of other movements (even though you can model their discharge during the intergreen with end lag). Consequently, this modelling technique may underestimate the situation. This underestimation ought not to be a concern because, if the situation is sensitive to the data, it may well be time to consider the addition of an unopposed stage for the right turners.

Whilst on the subject of opposed right turn situations, one thing you positively cannot do in TRANSYT is to have a link specified as opposed that is itself a priority link for some other opposed link (i.e. mutually opposed). Often, TRANSYT will not tolerate this and fail to run correctly. However, sometimes TRANSYT will run: if it does run, the results certainly should not be trusted. When this mutual opposition exists, it is necessary to model the capacity of one of the links (usually the one with the least right-turning traffic) by suitable adjustment of the saturation flow. The saturation flow can be calculated by using OSCADY or RR67 formulae and it is still possible to use the end lag to model turning during the intergreen. (Note that, in such cases, the end lag time calculated by (3600/saturation flow) x (number of vehicles stored) may seem excessively long when the saturation flow is low and you may need to be prepared to defend it).

In Part 2, I will continue with this theme, covering situations where right-turn bays exist and where there are two (or more) lanes involved, which adds whole new dimensions to the problem.

When a bay is added and it is dedicated to the right-turn movement, the extra space is used to store vehicles that want to make that manoeuvre. When the right-turners (RTs) are opposed, the extra space normally accommodates some vehicles out of the way of the other traffic on the same approach who can make their manoeuvre unimpeded as a result for at least part of the cycle (ie until the right-turners queue upstream of the start of their bay and stop the other straight-on traffic).

Firstly, consider the case where there is no early cut-off or late-release stage in the cycle for the RTs. Normally, the recommended method of modelling this situation depends on whether the RT traffic blocks back at all or not; even so the suggested methods are not ideal. They are:

a) If the RT traffic does not block back, use two separate links: the disadvantage is that TRANSYT models two separate queues whereas in reality you have one-and-a-bit queues. This means that the saturation flow of the straight-ahead lane has to be reduced in proportion to the number of RTs in the flow upstream of the bay. It also means that the RT ‘OUT’ pattern will be unrealistic in shape, but this probably does not matter too much as the capacity is modelled with reasonable accuracy.

b) If the RT traffic blocks back and restricts the straight-ahead traffic, it is better to model this approach as a single link along the lines described in the first article in TSN No 20. The problem here, however, is that it is necessary to compensate for the extra capacity afforded by the fact that some straight-ahead traffic will be able to make their manoeuvre freely before the RTs block back. To do this the saturation flow needs to be increased so that it is a time-weighted average of the value before and after blocking occurs, averaged over the relevant green time.

It might be thought that this ‘step’ in the saturation flow can be modelled with the flared approach parameters. It can’t! Flared approach data is ignored whenever a link is specified as a give-way (whether or not it is also a signal controlled link).

Introducing a new method…

Whilst writing this article, I tried something that I have not used before which may be of significant value:

If you split the approach with the RT bay into two short links, and then have a single feeding link to model the queue upstream of the start of the bay (see figure 2) it is possible to, at the very least, find out accurately how many vehicles are likely to use the RT bay. The principle of this method is to control the OUT pattern of link 10 by suitable start and end-lag adjustments. Firstly, make all the links belong to the same node (you can still feed flow from link 10 to links 11 and 12). Then consider the following

• Normal start lag (integreen), I
• Number of vehicles (pcus) that can physically store on link 11
• Time for maximum queue on link 11 to discharge, t
• Journey time along link 11, j

Then the start lag for link 10 = I + t – j.

The end lag needs to be adjusted until the queue predicted in the TRANSYT output is just enough to fill the space on link 11 and no more. Note that the end-lag value will remain the same from one run to the next for uniform-flow entry links, but may differ markedly for internal links depending on the OUT patterns from feeding links.

With all the data in place, the maximum expected queue for link 12 is shown in the output and you can determine whether blocking back will occur or not from it. If there is no blocking back, the resulting model will be an accurate representation of real-life. If there is blocking back, experimentation with the model by, for example, using the limit-queue facility and trying early-cut-off and late-release stages, will allow you to see if blocking back can be avoided. It may also be useful for modelling situation where the RT movement is catered for in a different stage.

If blocking back is unavoidable, method b) above would be the traditional method of modelling the situation. However, it might be possible to extend the new method in some way to take account of the change in capacity before and after blocking occurs. Firstly you need to work out the point in the cycle where the blocking occurs. Then you could specify link 10 as a flare with parameters that give a suitably ‘high’ saturation flow before blocking occurs, and a low one after. This isn’t an easy method as working out the low saturation flow value is not trivial, and the point in the cycle where blocking occurs will be different every time new timings are used. Nevertheless, it may offer a useful alternative if applied very carefully.

In conclusion, right-turn bays present particular modelling problems and I have presented the traditional methods of modelling them, plus a new method which does at least give an accurate figure for the size of the RT queue. I must make a small disclaimer for the new method though: myself and a colleague have looked over the method carefully and believe it does as explained, provided it is used in the way described. However, we have not presented the method in any way as a de-facto standard - you need to justify its use to your own and to clients’ satisfaction.

In the next part I will deal with approaches with two or more lanes.

‘Standard’ two-lane approach
Firstly, consider the situation where there are two lanes on an approach without ‘bays’ or flares, with an opposed right-turn movement. The main consideration is whether the offside lane will contain just right turners, or a mix of traffic. If the lane is marked for right-turners only, it would normally be expected to carry just right-turning traffic. A separate link for this movement would be required in this case. If, however, straight-ahead traffic is permitted to use the lane, then it is a question of how much right-turn traffic there is: light demand will allow straight-ahead traffic easier access to the lane, whereas heavy right-turn demand will discourage straight ahead traffic from using it. You have to decide, either by on-street observation or by some common-sense based calculation, what the mix of traffic on that lane will be. Where there is a high proportion of right turners in the offside lane, some straight-ahead traffic might be able to get to the front of the queue ahead of right-turners who might otherwise block them. The number able to do this (on average) depends on the proportion of straight-aheads to right-turners, and also on driver behaviour. But it might be enough to give a small increase in capacity which might be worth modelling with an increase in saturation flow for example. On the other hand, even if straight-ahead traffic is unimpeded by the right turners, the saturation flow will still be reduced as the right-turners divert and leave gaps in the traffic flow.

Having decided the mix of traffic in the offside lane, you need to specify the give-way parameters for the opposed movement. The way this is done was covered in the first article in this series – in this case we can (usually) effectively ignore the presence of the nearside lane.

Considering the opposition
Where there are two lanes on the approach with the opposed right-turn movement, there is a high chance that there will be two lanes opposing the right turners and these lanes might form two separate links. However, you can only specify one link as the opposing link in this situation. This might not be satisfactory; but there is a way this can be overcome. If you feed the traffic from the two (or more) opposing links into a single ‘dummy’ link, the dummy link can be specified as the opposing link (see figure 1). In some cases you may need to keep the flows into the dummy link separate in order to model them separately on the next links. This can be achieved by making the dummy link a shared link in which case only the main link needs to specified in the give-way parameters. This automatically means the opposing flow is made up of the combined main and shared link(s). To ensure the dummy link has no undesirable consequences during optimisation, or on the performance index, it may be advisable to set the stops and delay to zero. The signal timings for the dummy link have to be the same as the two feeding links. This is to ensure that TRANSYT switches from using the give-way parameters to the signal control parameters at the appropriate time (usually when either an end-lag or an unopposed stage has be specified). Set this ‘stub’ link to 10 metres in length with a high (ie non-limiting) saturation flow. Ensure you look at the cyclic flow profile graphs to confirm that the model behaviour is satisfactory and understood.

When a right-turn bay is present
Sometimes, a multi-lane approach may have a right-turn bay. If so, you need to know whether the bay is large enough to store all of the right-turn demand or not. The previous article provided a means by which the queue length can be estimated.

Once you have decided whether the bay can cope with the demand or not, the link structure can be set. If the bay can cope with the right-turn demand, the approach could be specified as two, or maybe three links. Whichever way it is modelled, the capacity of the offside lane will be affected by the proportion of right-turners in the stream. The greater the number of right turners, the fewer straight-ahead vehicles in the lane. If the right turn is not especially critical, it would be possible to use three links, with the saturation flow of the ‘middle’ lane reduced in proportion to the number of right turners. The fact that right turners can then queue in their own link in TRANSYT, whereas in reality they might not all be able to reach the stopline, may not matter too much. If, however, the proportion of right-turning traffic is high (but still not enough to fill the bay) it might be better to model the situation as shown in article 2 with one link feeding two further links representing the bay and the adjacent portion of the main lane.

If the bay does fill up, it will effectively make the offside lane a right-turn only lane (see Figure 2). The main difference between this situation and the similar situation above (ie without the bay) is that there will be some space ahead of the point where the right turners divert into their bay. This extra space can be fully used by the straight ahead traffic (whether they actually use the space is another matter).

In many cases it may prove difficult to find an ideal modelling solution to your problem. However, with the application of common sense and experience it should be possible to find a solution that meets your particular requirements.

Introduction
TRANSYT is a tool for the evaluation of traffic network performance for a given set of traffic demands, road conditions and signal settings. The evaluation results may then be used for signal optimisation and/or for road scheme assessments.

At the core of TRANSYT are different types of traffic models, including a platoon dispersion model (PDM) and its variants, a ‘congested’ platoon dispersion model (CPDM), and a Cell Transmission Model (CTM).

TRANSYT 16 introduces a new type of model, known simply as TRANSYT Simulation, which uses a simulation technique to model traffic.  This provides a way to get the benefits of microsimulation, with fast runtimes and without the need for complex modelling or the costs usually associated with producing microsimulation models.   Existing TRANSYT users can benefit without the need to create new models – in the vast majority of cases, existing models can be used without any modification.

Traditional TRANSYT traffic models
The traditional traffic models in TRANSYT are macroscopic models, meaning that they deal with aggregate flows of traffic rather than individual vehicles. For example, at a given time, the model may know that the quantity of traffic emerging from a certain road is 500 vehicles per hour, and the traffic entering another road is 200 vehicles per hour.  These aggregate flows interact with each other and form the basis of the traffic model.  Representing traffic in this way makes the models computationally efficient, albeit at the expense of them being unable to model individual vehicle behaviour and interactions.  It is not possible, for instance, for the model to know where in the network a particular vehicle is at a given time.

The macroscopic TRANSYT models also assume that traffic behaviour is cyclic, based on a common signal cycle time for the network. The network must operate using fixed-time signal control (although TRANSYT does allow for multiple cycling and different cycles for different subnetworks). With this cyclic assumption, the traffic model is run only up to the point when traffic has settled to a cyclic state, with most model results being based on averages over the cycle. This provides an indication of average performance over the modelled period.  If the network is under-saturated, then the behaviour in a given signal cycle repeats over and over, so that the last cycle in the modelled time period (e.g. one hour) is essentially the same as that of the first cycle.  If the network is oversaturated, with queue and delay increasing over time, this is estimated by TRANSYT but not modelled in detail.

Simulation model in TRANSYT 16
In TRANSYT 16, a Simulation Model is available.  In this model, individual vehicles are simulated, and so the model is closer to a microscopic model.  However, the TRANSYT Simulation differs from conventional microscopic simulations such as Vissim or Aimsun in that it uses a simplified representation of vehicle movements on the road.  Detailed behaviour such as car-following, acceleration and gap-accepting are not modelled.   Instead, TRANSYT Simulation is mainly concerned with queueing behaviour and travel time along road links while taking into account traffic demand and available road capacities.  This capability facilitates the modelling of blocking back and other effects whilst remaining relatively computationally efficient, and reducing time to produce representative, and accurate models.

In the TRANSYT Simulation model, the cyclic assumption described previously is not relevant. The TRANSYT Simulation model runs explicitly for the entire modelled period, allowing the network performance to be examined in detail at any point in time. This feature is useful for the investigation of congestion caused by blocking back effects which propagate backwards quickly (average model results would not be very helpful here). Unlike the existing TRANSYT models, the TRANSYT Simulation model can simulate accurately the full effect of controller streams operating on different cycle times.  It is also useful for modelling demand-dependent scenarios using intermittent stages.  A particular stage may be set either to run every N cycles (e.g., to mimic bus priority systems), or to run on a given probability to mimic pedestrian crossings triggered by random arrival of pedestrians.

In TRANSYT Simulation the “resultant” signal timings data and vehicle positions are logged during the simulation run and are available for the user to inspect in for the form of animations and diagrams.

Random arrivals of vehicles at the boundary of the network (i.e. entry links) and on give-way links are modelled in a more explicit way than the traditional TRANSYT models.  This means that random brief bursts of vehicle arrivals or departures are modelled, plus their effects on upstream/downstream links.  This behaviour can be seen by the user by carefully watching the simulation animations.

The TRANSYT Simulation can model situations which are not possible using the existing TRANSYT traffic models, such as complex flare situations. Of the traditional models, the CPDM model has an additional ‘blocking’ capability as well as modelling blocking back in general, which handles namely the randomness in blocking in flared situations. However, this functionality may be applied only to specific flare structure: one PDM link feeding two or three signal controlled PDM links that are shorter than 30 meters. For more general flared cases, either CTM or TRANSYT Simulation can be used, bearing in mind that the CTM does not allow for randomness in blocking whereas TRANSYT Simulation does.

The TRANSYT Simulation does not currently model platoon dispersion. However, when blocking back effects need to be modelled these will also be the very situations where modelling of dispersion will be less important. When the network involves both short and long links, mixed PDM / CTM / CPDM should be used. On the other hand, when it is desirable to study the behaviour of an oversaturated network, the TRANSYT Simulation is ideal, because it models the whole modelled time period – not just an average single cycle.

Using the Simulation Mode in TRANSYT 16
A TRANSYT Simulation model has very few parameters to define in addition to those already in a TRANSYT model. Generally speaking, any existing TRANSYT network data file can be run in TRANSYT Simulation mode without making any changes.  All that is necessary is to turn on ‘Use Simulation’ for the relevant Analysis Set, or to click on the ‘Simulation’ button on the main toolbar.

Note however that Simulation mode is only available for networks that use traffic streams, and not for link-based networks, and that certain network features may be ignored or not modelled in Simulation mode.

One important feature of TRANSYT Simulation is its balance between model performance and complexity.  Because it is not a full microsimulation, it typically runs quickly.  When the simulation is started, a random seed is used to trigger the process of vehicle generation and a single “trial” of the simulation is run, covering the modelled period of, say, 08:00-09:00.  Run times depend on the network size and complexity and the number of vehicles in the network, but a single trial will typically take less than a second.  The results from a single trial are usually enough to reveal the approximate network behaviour and for the network animations to show visually how vehicles progress through the network or where there are inefficiencies in the network.  Running a second trial will show similar results but there will be some differences due to using a different random seed.  Usually, therefore, several trials are run, each using a different random seed, and the results from these trials averaged together.  By default this continues until the results are considered to have “converged” but the process can be stopped at any time by the user, including after a single trial.   Typically, signalised links are more deterministic and so will tend to converge faster than give-way links or other regions where randomness is an important factor.

Examples
Shown below is a snapshot from the individual vehicle animation available after running a TRANSYT Simulation model for a signalised roundabout.  Each coloured block represents a vehicle, with the colours signifying the vehicle destinations (coloured locations at the edge of the network).  The animation shows both queued vehicles waiting at stop lines, and also a representation of vehicles moving at their cruise speed along links and connectors.

The animation snapshot below shows examples of blocking and lane starvation.   The vehicles are colour-coded by destination, and also show the path ID assigned to each vehicle.  On the southern arm, there is a blue vehicle in the upstream queue but it cannot enter the appropriate downstream lane because it is blocked by queueing red vehicles in front.  (In this example, the turning proportions are such that most vehicles turn right, headed to Location 2).  Due to this, the lane for left-turners on the southern arm is mostly empty and under-utilised. The simulation results and animations will help to reveal whether this is an occasional occurrence or whether it happens regularly.

Similarly, on the eastern arm, the blue vehicle in the upstream lane, waiting to travel straight-ahead to Location 1, won’t be able to enter its lane until the green left-turning vehicles have cleared.

The traditional TRANSYT models would model these effects to some extent but the additional visualisation tools that simulation provides makes it much easier to see graphically what is happening and to get more reliable results about “where” the queues are.  If the situation is more complicated, with the blocking being transmitted to further upstream links, then TRANSYT Simulation will model this without any modification whereas the traditional models may require some thought.

TRANSYT 16, TRANSYT 15 or TRANSYT 14:  Subject to an ARCADY licence, you can specify your roundabout geometries directly in TRANSYT, allowing  partial-signalled, fully signalled or unsignalled roundabout models to be compared without touching ARCADY.

TRANSYT 13 or earlier:  If you are modelling a give-way within a partially signalled roundabout within TRANSYT, you will need to obtain give-way coefficients (TRANSYT maximum flow and slope coefficients) from somewhere outside of TRANSYT.

These parameters represent the slope and intercept of a priority/give-way stream capacity relationship and these are exactly the numbers which ARCADY provides in its output. So accurate give-way parameters ("Card Type 30” in TRANSYT 12) can be obtained by modelling the give-way part(s) of the roundabout using ARCADY.  You do not need to model the whole of the roundabout, or bother about the flows – ARCADY only needs to know the geometry of the entry arm in question in order to calculate the slope and intercept of the capacity relationship.

Note 1:
For grade-separated/very large roundabouts, circulating flows for the central 30 minutes are required in addition to the normal geometric parameters (other flows can be any value).

Note 2:
Where the roundabout entry has lanes marked for different movements, this, in itself, causes no problem. However, if the entry is starved of traffic to any extent (by vehicles being stuck in the queue unable to reach the give-way line) then ARCADY can be optimistic about capacity. Note that starvation has to be substantial for significant overestimation – even if a single vehicle can reach the give-way to form a ‘queue’ in the least-used lane, is enough for the entry to reach full capacity. Where there is sustained starvation, modelling just part of the give-way would be one way of compensating. However, as far as using the ARCADY results in TRANSYT is concerned, a good estimate should suffice for most situations since the priority junction would not normally be one of the critical factors in determining good signal timings; important junctions would normally be signalled.

It's been a long time since TRANSYT first introduced signal "phases" in addition to "stages" - Introduced way back in TRANSYT 13 in fact. This simplified the specifying of signal arrangements considerably. However, there is one aspect of TRANSYT that is often overlooked - the specification of a second phase that controls a traffic stream or link. Part of the reason may lie with the User Guide, which hardly mentioned this facility - this will change however in future issues.

A second phase can be added via the "Signals" tab of the Traffic Stream Data screen, by selecting the "Phase2" option and referencing the second (associated) phase. Although the TRANSYT model only makes use of the second green time within the model and otherwise does not explicitly know what is being modelled, the specifying of a second phase is still useful when you wish to explicitly indicate to others that you are modelling, say, a left-turn filter situation. The green time of the traffic stream or link will be the combined green time of both phases. It isn't actually necessary to model a filter in this way, as you could simply redefine a single phase to run over the same length of time as the two separate phases but this is more of a 'modelling-only' solution as the phasing arrangement would then differ significantly from that found within the controller.

N.B. When using a second phase to model a filter, the filter phase would be set up in TRANSYT to run till the end of the associated phase (although in reality the left turn arrow would be extinguished as soon as the main green started).

Finally, assuming the "phase" type has been set to "filter" then the file preference "Use phase colours in timing diagram" will allow you to more-easily see the presence of the filter in the timing diagram.

The pedestrian behaviour model allows you to predict the number of pedestrians that will cross during the red man as well as during the green man, i.e. the level of non-compliance is predicted. Given the high proportion of pedestrians that do no comply, the new model allows far more accurate calculations of pedestrian delay than would have been possible previously, when TRANSYT would have simply assumed pedestrian would only cross during the green man.

The model has been derived from research based on the extensive analysis of pedestrian behaviour in London. A mechanism has also been added to allow some calibration to the model - this allows some site-specific differences to be accounted for and also offers a mechanism to adjust the model for use outside of London where pedestrian behaviour may well be different.

TRANSYT 13 onwards: TRANSYT has the option of specifying Initial Queue lengths on entry links. These influence the mean queue and delay calculations reported by TRANSYT. Queues are also passed from time-segment to time-segment when more than one time segment is specified.

TRANSYT 12: TRANSYT ignores any queues and delays before the start of the model. It assumes that flows are constant during the modelled period, and tells you the queues and delays for the modelled period only.

(This article has been updated since the release of TRANSYT 16)

In fact, it makes no sense to quote a maximum value because:

• RFC varies throughout a peak, and can rise and fall sharply or slowly.
• The consequences of a high RFC depend on the flow. An RFC value of 1.2 might not matter with a very low flow whereas a value of 0.8 might be disastrous with a high flow.

The important criteria for judging the success of a design (from the point of view of congestion) are the total delay to all vehicles, and the mean delay per vehicle on each of the approaches. The latter is a question of “fairness” and “politics”. Is it acceptable for some drivers to suffer twice as much delay as others? How about ten times as much? That is a matter for opinion.

Question: I have a small network of signalised junctions that are quite a distance from each other. Is there a particular distance (or rule of thumb) beyond which coordinating the signals using TRANSYT is of no benefit?

Answer: No – there is no particular distance. The usefulness of TRANSYT will depend not on the distance between junctions but on how much the platooning of traffic remains intact along the link by the time it reaches the downstream stop line. Platooning is affected not just by distance but also by the amount of skin-friction along the link due to characteristics such as the presence of parked cars, bends or minor sources and sinks. The presence of more significant priority junctions can also contribute to this if they add significantly to the traffic already on the link. Although in this case you would probably want to model the give-way within TRANSYT too. Platooning is also significantly affected by the nature of the upstream junction. Good platooning is likely only if there is a dominant movement at that junction.

The only sure way to know how intact platoons remain along a link is to go out on-street and see what is actually happening by measuring cyclic flow profiles on street. The degree of platooning is easily seen from the data collected. Within TRANSYT itself the degree of platooning is indicated by the value of MME (Mean Modulus of Error). The MME value is given in the cyclic flow profile graphs. Whilst platoon dispersion due to differing speeds is modelled by TRANSYT, skin friction effects are not. So MME is a theoretical value. A value of MME close to its maximum of 2 indicates a high level of platooning so good coordination will be effective while a value of 0 indicates no platooning at all and hence no coordination benefits are possible. A ‘rule-of-thumb’ is that for any link with a MME value of 0.3 or less, it is probably not worth coordinating the signals. However, if on links, whether short or long, skin friction effects are significant, the MME value is not likely to be meaningful.

N.B. This article revised - Nov 2008

There are two reasons for this – one due to the repeated use of  EQUISAT and the other to do with how the TRANSYT signal optimiser works.

TRANSYT 13:

1. Looking first at EQUISAT.Some TRANSYT 13 users may have noticed that when a file is imported from TRANSYT 12 that has EQUISAT switched on, they are informed that EQUISAT has been switched off.  The reason for this is that in TRANSYT 12 the selection of EQUISAT did not always result in EQUISAT being run, while in TRANSYT 13 it is always run if requested.  It is assumed that a file being imported will have already been run in TRANSYT 12, so will contain either EQUISAT, optimised, or fixed timings already.  This means that in TRANSYT 12 if the file was re-run EQUISAT would not run – to match this behaviour in TRANSYT 13 the program switches off EQUISAT.

If optimisation is selected, the resultant optimised timings will become the starting point for the next run. Although EQUISAT now always runs when selected and it will always overwrite the existing timings, EQUISAT is still influenced by which stage comes first in the cycle which might have changed during optimisation.  This means that even when EQUISAT is ON and overwriting the timings these timings may not be exactly the same as those produced by the previous EQUISAT calculation.  This different starting point can occasionally produce different optimised results.  Note however that all the results are ‘good results’ and the differences are likely to be small.  The effect usually reveals itself as a set of two or sometimes even three slightly different results which loop round as TRANSYT is repeatedly run.  If this occurs you can simply select your preferred result when it appears and then switch off EQUISAT.  Alternatively, you could choose to only ever run EQUISAT once in order to get a set of timings.

2. The second reason that repeatedly pressing the run button can result in better results is nothing new to TRANSYT, and is simply due to the optimiser being given a second chance to determine improved timings.With EQUISAT switch off, the optimised timings from one run automatically become the starting set of timings for the next run.  If they are different from the previous timings then again the optimised results from this run can again be better.  N.B. This effect will never produce worse timings than the previous run.  This procedure can be automated by selecting the new “Enhanced Optimisation”option in the Signals Options screen.

TRANSYT 16, TRANSYT 15 and TRANSYT 14:

Pressing Run twice in TRANSYT can produce better results as described above for reason 2, but for reason 1 the effect won't happen as the EQUISAT routine has been replaced by a new "re-distribute" option.

Furthermore, regarding what is said above regarding different starting points, a new optimiser called "shotgun hill-climb" now exists in TRANSYT.  This allows multiple runs of TRANSYT to be carried out, each with a different starting point (in terms of timings).  Since the starting point can have an influence on the final timings, this allows TRANSYT to produce better timings for those who are happy to let TRANSYT take longer to produce a set of results.  This feature is described in full in the TRANSYT User Guide.

Question: Why is the default simulated time in TRANSYT 16 and TRANSYT 15 set to 60 minutes and to 120 minutes in TRANSYT 12?  How is it related to the 60 minute period you are normally providing flows for?

Answer: The one-hour flow data specified is, of course, only a 'flow rate' shown in the units "PCU/hour" and notthe flow over a one hour period - It is the 'simulated time’ that determines the modelled time period.

The simulated time takes account of the build-up of queues over the simulated time - It only affects the results when there is over-saturation within the network.  A simulated time of 60 minutes of a 60-second cycle will give the average values for 60 cycles of the network.  The simulated time in TRANSYT set to 120 minutes is neither correct nor incorrect.  It depends really on what you want to do in TRANSYT.  In TRANSYT 15 it was decided to switch the starting value to the more commonly required value, rather than the more conservative value used in TRANSYT 12.  It is not a 'default' to be left as it is - it should be 'set for purpose'. It just so happens that 60 minutes is commonly used, and hence it is what TRANSYT 15 is set to, to start with.  For example, if you simply wish to obtain the average results for a 60 minute period, then 60 minutes is what you need.

Historically, in TRANSYT 12, if you had interest in the final queue lengths at the END of a 60 minute period for a heavily congested network (i.e. significant number of links over-saturated), then 120 minutes allowed you to see approximately the situation at the end of the 60 minute period.

This is because the TRANSYT results are an average over the modelled time period, and when the network is congested the queues will be made up mostly by random (due to cycle-to-cycle variation) and oversaturated components. To get an idea of the queue lengths at the end of the 60 minutes you needed to double the simulated time to 120 minutes (assuming that the average value will then equate to approximately the queues half-way through the time period.  This is not totally right of course, as the final queues also contain the uniform (due the typical cycle) queue component, but it will give a reasonable estimate of the value wanted.  The values affected by changing the simulated time are the delays, queue lengths, and PI values. It does not affect the optimisation process however, so the green times and offsets remain the same as do the degree of saturation values.   Note that since TRANSYT 15 there is additional outputs in the form of some EoTS (End of Time-Segment) results.  These negate the need to do any of this.

If you find that some traffic flows in your wide-area matrix are not being assigned to the local matrices, this can be due to one of the following reasons:

1.  Paths connecting the two locations have not been established, probably due to a missing connector between two traffic streams (or links).  Note that this applies equally to local matrix flow allocation.  You can use the "Show Downstreams" network diagram option to check that the connections you have ensure traffic reaches all the locations it should do.  You can also use the flow allocation paths "filter" to systematically check that all the paths you think should exist have been created.

2. Paths have been disabled.  N.B. bus and tram paths are, by default, "Disabled" and need to be enabled for them to carry traffic.

3. A wide-area matrix "Location" has been connected to a local matrix location which is not itself attached to an ENTRY traffic stream (or link).  This is an absolute requirement - if the local location is not feeding an ENTRY traffic stream (or link) the flows will not be assigned from the wide-area matrix for that movement.

TRANSYT 16, TRANSYT 15  and TRANSYT 14

If using the platoon dispersion model (PDM or Quick PDM) In TRANSYT you simply need to set the "Exclude from PI calculation" flag in the "Modelling" section of the "Link data or “Traffic Stream” data.  This will ensure that optimised timings will excluded the PI for this link from the performance index calculation, and timings will therefore be the same as before you added the exit links.  Instead of excluding the results from the P.I. alternatively you can define the exit link or traffic stream as having no restricted flow (e.g. by adding an unrestricted link or traffic stream in NetCon).  This ensures that traffic remains unimpeded no matter what level of flow travels along it.

If the exit link or traffic stream is modelled using the cell transmission model (CTM) you need to be aware that CTM restricts traffic naturally at both ends of the link (e.g. at the stopline, give-way line AND also at the upstream end of the link or traffic stream.  This upstream restriction (cell saturation flow) determines the maximum amount of traffic that can enter and travel along the link (as opposed to the saturation flow – that defines any restriction at the downstream end).  Therefore it is recommended that a suitable cell saturation flow is selected to reflect the number of lanes it represents.  It follows that even if the link or traffic stream is defined as being excluded from the P.I. calculation AND/OR has no restricted flow (at the downstream end) it can still act as a restriction to traffic entering and can result in blocking back .  This, of course, is correct (modelling-wise), but if you do not want this restriction to occur you should set an overly high cell saturation flow to remove this effect.

Please note that, in order to avoid mistakes regarding the setting of Cell Saturation Flow values, a warning message is reported if a traffic stream that represents two or more lanes also has a cell saturation flow left set to the TRANSYT default of 1800 PCU per hour.

TRANSYT 13

In TRANSYT 13 you simply need to set the "Exclude from PI calculation" flag in the "Modelling" section of the "Link Data".  This will ensure that optimised timings will excluded the PI for this link from the performance index calculation, and timings will therefore be the same as before you added the exit links.

Please note however that if using the Cell Transmission Model (instead of the platoon dispersion model), traffic can be restrained from entering the link at its upstream end - this is part of the nature of CTM and why it can model blocking back.

TRANSYT 12

In TRANSYT 12 adding a new link WILL affect the results, but as long as you specify the link as a bottleneck and specify zero stop and delay weightings (i.e. -9999 values) you will obtain the same signal timings.

N.B. Some values related to the total length of the network, such as "distance travelled" through the network will be very-slightly different.  Setting the link to be as short a link as possible will reduce this effect to a minimal difference.

In NetCon simply right-click on the network background and select Tools/Adjust Link Spacing. The spacing is increased by selecting a value more than 100% and reduces in by selecting a value less than 100%.

Similarly, you can quickly spreadout the whole network by selecting Tools/Adjust Network Spacing.

Yes! - Since TRANSYT 13 you have been able to do this.  The latest version of TRANSYT has an integrated Network Diagram that includes simple-to-use tools to build networks from scratch, or edit existing ones.

Using the mouse, network artefacts (traffic streams, controller streams, etc.) can be created in any order and then easily linked together - All within the interactive diagram.

A useful tool allows you to rename all items using specific naming conventions, so for example the names of Traffic Streams will reference, say, the controller that controls them, and/or the direction of travel using the eight points of the compass.

TRANSYT 13: Yes - All releases since 13.1.1 indicate the presence and number of flares in NetCon (The network diagram).  Additionally, you can use the NetCon user options to set one of the link text values to the Flare Storage value, allowing you to see the length of the flare.  A non-zero value also indicates the actual presence of a flare.

TRANSYT 16, 15, and 14: Note that these versions of TRANSYT have two methods for modelling flares: "Quick flares" (which are the same as for TRANSYT 13 and earlier versions) and CTM/CPDM flares, which allow more complex situations to be modelled such as where each lane of the flare is controlled by different phasing.  Quick flares show up in the same way as in TRANSYT 13's network diagram.  CRM/CPDM flares are evident from the presence of a traffic stream feeding more than one downstream traffic stream AND the fact that these downstream traffic streams have their the traffic model "Flare" - A network overlay will can be used to reveal this on the network diagram.  Depending in the circumstances, TRANSYT makes use of either the CTM or CPDM underlying traffic model.

(Updated 2023)

TRANSYT includes options to add 'user arrows' on links. These can be turned on/off by right-clicking on the link and then choosing from the menu (shown below). Alternatively - you could add an extra downstream bottleneck to any link on which you wish to show the route of traffic exiting the network. If you have TRANSYT 13 you can avoid the new link affecting the Performance Index by setting the link option "Exclude from calculation". If you have TRANSYT 12 the stop and delay values should be set to -9999 to indicate zero weighting. Also the link length should be set to the minimum to minimise any effect on the mean speed within the network.

Link network structures:

The way to consider queue lengths in a master/shared link combination (a 'link-share' as we like to call it nowadays), and indeed all the data in the final output table, is as a single link. Hence, if a queue is output as being 10 (and the same value will appear for the master and shared links) then the queue is 10 over the combined links: if the link represents one lane, the queue will be 10 per lane, if two lanes are modelled, the queue will be 5 per lane, etc. It is a key to using TRANSYT that the master link and shared link(s) are NOT used to model lanes separately. The reason for using master and shared links is to allow cyclic flow profiles to be kept separate - for roundabouts this is to keep OD movements intact.

In the TRANSYT 12 output ‘PRT’ file the queue associated with the shared link combination is repeated on each of the shared links. In the Network Construction Editor (NetCon) it was decided to display the queue just once and position it on the major link since there will only ever be one major link defined (for a shared link combination).

Additionally, In TRANSYT 13 and later, the repeated values associated with minor shared links are shown inside brackets to remind users that they are NOT to be added together to give a total queue length. - They ARE the total.

Traffic stream network structures:

The use of traffic streams have the same benefit of using link-shares, as they create, behind the scenes, a fully populated link structure - These 'links' are referred to in this context as 'path segments' as contiguous chances of these are used to establish 'paths' for traffic from each O-D origin to each O-D destination within a local O-D matrix.  The use of traffic streams hide the complexity of the link structure. It also allows TRANSYT to have a one-to-one relationship between a real lane and a lane in the model, while retaining the benefits of the link structure, such as keeping CFPs separated so that flows of traffic are modelled accurately.

(Updated 2023)

Yes! You can do this in all versions since TRANSYT 13 - Rather than create custom tables within the report itself, you need to use the Data Grid. Open the grid you want and then simply right-click on the any of the grey headers to add or remove any columns in the table (see Image1 below).

Image 1 - Design your own table

N.B. Any Data Grid can be edited, but if you wish to be able to select all link data related items you need to first ensure the heading is LINK (as shown above), e.g. if you have highlighted a subset of “Link” such as ”Modelling” you will only be able to add or remove items associated with link “Modelling”. The mixing of input data and output results is also possible.

Having added or deleted the columns to your liking, you need to select the menu item “Column Layouts/Store Current Column Layouts” (see example below) in order to store the image. You can now use the menu item “Manage Stored Column Layouts” to set the “UseInReports” flag. From now on your beautifully crafted table will appear in all subsequent reports (see Image 3 below).

Image 2 – Store your design and add to the report

Image 3 – Your new table within the Report

An alternative quick way to create your own table is to start from scratch by firstly using the Column Layouts option “Remove All columns”.  Then populate your table using the “Add columns from Data Editor” to select each column one-by-one, simply by clicking on the Data Editor items you wish to add.

Problem: Trying to open an old TRANSYT 12 file in TRANSYT 13 and in TRANSYT 14 causes an error message.

Answer:

TRANSYT 15 and TRANSYT 16: Since the above problem could catch people out, this method has been changed since TRANSYT 15. To open a file produced with earlier versions of TRANSYT, you simply select the file via the "Open" command.  N.B. Imports from third-party products are still carried out using the "Import" menu options.

TRANSYT 13 and TRANSYT 14: To open a file produced with earlier versions of TRANSYT such as TRANSYT 12, in either TRANSYT 13 or TRANSYT 14 you need to use the menu item "Import" and not the "Open" command.  You can tell from the windows Open dialog box that the only file type the program is looking for is either a ".T13" file (if using TRANSYT 13) and a ".T14 file (if using TRANSYT 14).

I have the same problem of constantly changing registration code with all TRL software protected using the ERIS copy-protection system. This includes TRANSYT, ARCADY, PICADY and OSCADY PRO. I am using Windows 7. How can I fix it?

Please ensure that you have not installed any of the applications as Virtual Applications under Windows 7.  This method creates a temporary copy of the registry which causes ERIS to lose any registration data.

To avoid this, please ensure that you use the Windows right-click "run as administrator" option when launching the program for the first time and while registering the software.  This will stop the application from being mysteriously unregistered.  N.B. you MUST do this irrespective of whether or not you are logged in as an administrator at the time you are registering the software.

Versions of TRANSYT prior to TRANSYT 13 were in ASCII format and could be read by any text editor.  Since TRANSYT 13 the files are saved in a binary format and cannot be read other than using TRANSYT.  However, you do not need to have a registered version of TRANSYT to open TRANSYT files.  A demonstration versions of TRANSYT (available on this website) can be downloaded for free and will act as a viewer of TRANSYT files.  Files can be opened in the demo version and the complete contents of the files are readable - input data and output results can be examined, reports created, animations set in motion, etc.

Please note that each major version of TRANSYT behaves differently…

TRANSYT 15.5 and TRANSYT 16: Once you open your file, you will be able to examine the input data and most of the results.  If you wish to carry out any animations, or you wish to ensure the results are up-to-date, you can carry out an evaluation run at any time.  When using multiple analysis sets, you can choose to run each one individually or all at once using the evaluation run drop-down option. This is only possible because, unlike previous versions, TRANSYT can store the results of all analysis sets within the TRANSYT file.

This demo version allows a small number of changes to be made to the file before further changes are prevented.  This feature has been added to allow you to gain better understand of the product's capabilities prior to purchase.

TRANSYT 14 and TRANSYT 15 (Prior to 15.5): When a TRANSYT file is opened, you will be offered the chance to carry out an evaluation run of TRANSYT. This is because TRANSYT 14 and TRANSYT 15 files do not contain the full output animation data, so the demo version allows the file to be run in order to create this. Saying YES to this question will allow you to read the full output results of TRANSYT.

Because TRANSYT only stores the last run of the model in the file, if multiple analysis sets are used in the file, you will only be able to see the results associated with one set.  However, you will still be able to access the input data for ALL analysis sets.

This demo version does not allow input or output results to be changed – You will need to have a fully registered version of TRANSYT to do this.

TRANSYT 13: The contents of a TRANSYT 13 file that you can read using the Demo, depends on how the data file has been saved - A standard TRANSYT file does not contain the animation data associated with a run of TRANSYT. In order to ensure the animation data is available to users of the demo version, you need to save the file in TRANSYT 13 using the “Save with Full Run Data” option. Even without this additional information, you will still have read-only access all the input data and standard results.

Because TRANSYT only stores the last run of the model in the file, if multiple analysis sets are used in the file, you will only be able to see the results associated with one set.  However, you will still be able to access the input data for ALL analysis sets.

This demo version does not allow input or output results to be changed – You will need to have a fully registered version of TRANSYT to do this.

(Updated - June 2023)

Due to the significant enhancements associated with using multiple analysis and demand sets, the TRANSYT 15.5 file format is substantially different to that of TRANSYT 15.1.1 and other earlier releases of TRANSYT 15. Therefore, files imported into TRANSYT 15.5 and re-saved cannot subsequently be opened in earlier versions of TRANSYT.

If you have a client or colleague that needs to view the contents of a TRANSYT 15.5 file and has not yet upgraded, they can download the demo version for TRANSYT 15.5 and view and (evaluate) run the files using that version straight-away. Please note that unlike previous "Demo and Viewer" versions of TRANSYT, you can now carry out evaluation runs (i.e. using existing timings) of all analysis sets within the file using TRANSYT 15.5. This change ensures you will have full access to all the results and all associated network diagram animations.