An Observer for Adaptive Intersection Control

Dr. Thomas Riedel

Conference Paper for the 8th IFAC Symposium on Transportation Systems, Chania, Greece, June 18-18, 1997

Abstract: Traditional control of intersections through traffic lights does not reach the possible flow of vehicles over the intersection. If one puts vehicle detectors around an intersection, the control program can adapt to the current traffic situation. For an optimal control of the intersection it must be possible to interpret the available measurements as well as possible: therefore position and speed of each vehicle must be determined. The paper presents a process for the continuous estimate of position and speed on driveways to intersections on which vehicle detectors are installed. Measurements in the city of Zurich are shown and discussed.

Keywords: Estimation algorithms, Observers, Simulators, Traffic Control

1. Introduction

Classic control of traffic intersections uses mostly cyclical sequences of phases, which are shown at the lights. The most important drawback of such a control is that there emerge easily empty times with green phases for driveways, for which no vehicles are available. For a more recent control of a traffic intersection, detectors can measure the traffic around the intersection (as individual traffic, public traffic, and pedestrians). Using the measurements by the detectors, the usage of street segments can be determined. These measurements, however, are used frequently only in limited extent, for instance for counters, which can quantify the inflow to the intersection. After criteria, which have been chosen at the development of the control, the lights' phase lengths and sequences are determined.

However, today's computer technology enables controllers with an unrestricted attribution of the phases, according to the state of the traffic (as traffic density, traffic speed). The intersection controller can be developed in a systematic way, so that it optimises a given objective function. This can be for example the maximisation of flow capacity of an intersection or any other criterion as the minimising of pollution. Such a systematic controller can be set up with the help of algorithms (Riedel, 1994a) using Dynamic Programming and Branch-and-Bound techniques for a rolling horizon.

On the one hand it is important, that the controller is fed with reliable information, on the other hand, that the controller receives the information in an understandable format: an algorithm can hardly be built up on the appearance of detector impulses only, but much easier on information about the quantity of vehicles and their speed in the driveways to the intersection: the controller must know the state of the intersection or the intersections, in order to be able to control the system.

2. Outline of the Observer

Image75.gif (4636 Byte)

Fig. 1: Diagram of the control of an intersection

Fig. 1 shows the situation of the observer in the controlled system. The vehicles travel over the intersection (1). The traffic is measured by detectors, whose signals are transmitted to the observer (2). The observer estimates the state of the intersection (1) using the arriving detector signals, the states of the lights and using past measurements and experiences. The state of the intersection consists of position, speed and driving behaviour of the vehicles. The observer informs the controller (3) about this state. The state is used for calculating the phase sequences of the lights of the intersection.

For estimating the state of the intersection a simulator (Riedel, 1995) is used as observer, which can synchronise the simulated reality with the outside world. For this synchronisation, measurements of different detectors are required. If the detector signals are sufficiently reliable (Riedel, 1994b), the synchronisation of vehicles makes it possible to track the vehicles individually through the system and to determine also their speeds. The determined speed is used by the observer to adjust the estimated value of the speed of vehicles which are noted for the first time.

If the detectors lie one after another in the same lane, the measurement of a detector can lead either to the generation of a new vehicle in the observer, to the synchronisation with an existing vehicle, or to the deletion of a vehicle. The synchronisation leads in most cases to a correction of position and speed of the vehicle in the observer: either the vehicle has driven less far than expected or too far. This will be shown in chapter 3.

If the detectors lay side by side in different lanes, a lane change or an inaccurate use of two detectors by the same vehicle can be detected. This will be shown in chapter 4.

The fact that each vehicle can be kept track of through the entire system, enables a subsequent evaluation of parameters, which are not measurable directly through the detectors (so the average speed or the queue length in a certain driveway for the intersection). Some graphs are shown in chapter 5.

3. Tracking Vehicles in a Single Lane

3.1 One class of vehicles

If the detectors lie one after another in the same lane (see Fig. 2), the measurement of a detector can lead to the generation (1) of a new vehicle in the observer, to the synchronisation (2) and (3) with an existing vehicle or to the deletion of a vehicle. The deletion mostly happens at the end of the system without a detector (4).

The lane where the vehicles drive is represented by the lines right of (8). Each signal measured by the real detectors reaches the observer through the squares at level (9). The rectangles right of mark (10) symbolise the synchronising elements of the observer, the "detector handlers". They are connected to the street segments through the points D (detector itself), E (entrance), and A (exit). Dotted lines transmit messages (they are called message ways), solid lines are street segments. Points or squares on a solid line are the measurement points of the observer.

The synchronisation by a detector handler leads in most cases to a correction of the position of the vehicle in the observer: if the vehicle has driven less far than expected, its position is at marks (5) or (6) before the detector; if it has driven further as expected by the simulator, it will be found behind the detector at mark (7).

Image76.gif (17663 Byte)

Fig. 2: The three modes of a synchronising detector

The input and output ports of the detector handler elements are counted clockwise from top left to the right: the arriving observer detector signals are processed as follows:

The more detectors are available, the larger the quantity of measurable information is, and the more exactly the state of the system can be described by the observer. Likewise with the increase of the number of detectors, the observer becomes more tolerant against faulty measurements.

According to the desired kind of synchronisation, not all these points have to be connected to another element available. There are three different kinds of synchronisation:

Weak and hard synchronisation can optionally stop a vehicle for a while at the detector Dn in order to wait for a synchronisation signal from a detector. After a certain time-out the detector must let go the vehicle in any case.

3.2 Different classes of vehicles

It is possible that busses and cars use the same lane, but they are detected through different detectors, whereby the car detectors recognise also the busses, but bus detectors cannot detect cars. The distinction has also to be done by the detector handlers: busses are given an identification at their generation, and bus detectors detect only vehicles with such an identification.

At the synchronisation point there can be vehicles with another (invisible) identification before the bus or the car, which should be synchronised. The detector handler must push the uninteresting vehicles away from the access to the detector or the detector itself, since the vehicles to be synchronised can not overtake other vehicles.

In Fig. 3, detector 3 synchronises a bus. In order to do so it has to push away three cars.

Image77.gif (7667 Byte)

Fig. 3: Synchronisation with different classes of vehicles: a bus behind three cars

Similarly if a detector, which is not at the beginning of a driveway, wants to generate a vehicle, although at that time a vehicle invisible to the detector is placed on it, it empties first the space where the new vehicle has to be placed. This is shown in Fig. 4.

Image78.gif (4214 Byte)

Fig. 4: Generation with an occupied detector: a bus is generated on a detector occupied by a car

4. Changing Lanes

4.1 Cross talking

If two detectors lie side by side in different lanes, a lane changing or an inaccurate driving over two detectors by the same vehicle can be recognised. A lane changing can be seen at as a cross talking of two detectors.

Image79.gif (1797 Byte)

Fig. 5: Cross talking of two detectors

In Fig. 5 vehicles drive from the left to the right, whereby they can drive either correctly in their lane or drive somehow between the lanes. Detector 2 must be able to "steal" the vehicle from the lane of detector 1, if it finds out, that the vehicle is simulated in a wrong lane. Detector 2 can force a lane change to that vehicle. Cross talking is defined by the timing of two parallel detectors, as shown in Fig. 6.

Image80.gif (2509 Byte)

Fig. 6: Timing for cross talking (for the position of detectors 3 and 4 see Fig. 9): four time intervals define the cross talking behaviour.

4.2 Large distance between detectors

If the distance between the two detectors is large, the notion of cross talking cannot be used. This situation has to be modelled with three detectors, from which two are real and the third is used for modelling of cross talking. Detector 2 can then force a lane change, without a detector parallel to it.

Image81.gif (6651 Byte)

Fig. 7: Modelling cross talking of detectors over a large distance

Such a case is shown in Fig. 7. On the left-hand side, the situation with the fictional detector 3 is shown, which lies parallel to detector 2. On the right-hand side, the situation modelled by the observer is shown with three detector handlers.

4.3 Lane changing of different classes of vehicles

Additional problems occur at parallel bus detectors: only vehicles with certain identifications are admitted for changing the lane. Fig. 8 shows a bus changing a lane.

Image83.gif (10349 Byte)

Fig. 8: Selective lane changing of a bus

5. Measurements

Synchronisation is not always possible, be it, that vehicles disappear between two detectors, be it, that new cars appear or that detectors send erroneous data or that the simulator receives wrong information (wrong distances, wrong detectors in the wrong location). The following evaluations can be used to uncover errors in synchronisation.

Detectors 14 and 20 of Fig. 9 are used as example. They can be synchronised fairly well, however, some vehicles change lanes in both directions causing errors in the individual synchronisation of the pairs 14 and 20.

All evaluations date from Friday, February 2nd, 1996.

Image84.gif (9893 Byte)

Fig. 9: Detectors and phases of the example intersection. There are four access road, each of them with two lanes. There are vehicle detectors and bus detectors in the same lane. Pedestrians do not have sensors.

5.1 Testing the estimated speed

If a vehicle drives over the detector Dn-1, it is attributed an estimated speed by the detector handler of Dn. At this speed the car should drive over detector Dn at the point in time when the detector signal is expected from the measured values (or at least not too far from it).

Fig. 10: Examination of the estimated speed in hard synchronisation; vCtr stays below vShouldBe in order to obtain a stable estimation.

There are three parameters from which a conclusion on the correctness of the estimated speed can be derived, which has been attributed to the vehicle at Dn-1:

The values of vCtrOld are always smaller than the values of vShouldBe, and vCtrNew is always larger than vCtrOld. In the case of time-outs vCtrNew is reduced successively, since soft synchronisation does not provide additional information about excessive speed.

5.2 Testing faulty synchronisation

A time-out at detector 20 is a sign of a faulty synchronisation. A time-out appears when a vehicle has appeared on the detector Dn, but no signal can be associated with the vehicle in a given interval. Then the observer releases the vehicle, documenting the circumstances of the time-out.

The other case of a faulty synchronisation is a vehicle generation. A vehicle is generated at a detector when a signal arrives from the detector which cannot be assigned.

Generations and time-outs can never be avoided completely. If they appear in pairs, i.e. a group of generations following a group of time-outs or vice versa, the synchronisation has to be examined, since the synchronisation does not associate correctly the vehicles and the signals.

From generations, time-outs and successful synchronisations we can derive density functions (how many generations or time-outs per unit of time).

Image86.gif (3977 Byte)

Fig. 11: Generations, time-out and synchronisation density for detectors 14 and 20

Time-outs occur relatively rarely after an initial peak. Generations occur more frequently, which implies that many cars change from the left to the right lane. The rate of synchronisation is shown below:

G-T (the dotted line) shows the balance between generations and time-outs. The average of this function shows a surplus of generations after the initial stabilising phase of the observer. The synchronisation rate (solid line) shows the relationship of generations and time-outs compared to all vehicles. 1 implies unsynchronised behaviour, 0 implies perfect synchronisation. The bad synchronisation at the end (60% to 70% of unsynchronised vehicles) contrasts the quite good synchronisation in the beginning of the measurement interval (the usual 40% of lane changes).

Image87.gif (4969 Byte)

Fig. 12: Rate of synchronisation

Correcting the problem of the lane changes requires the detectors 13 and 14 (announcing detectors), and detectors 19 and 20, located 15 m before the intersection, to be co-ordinated.

5.3 Synchronisation and lane changing

Three kinds of synchronisations are explored:

In the following figures the events of the recognition of vehicles are averaged over 4 minutes. Thus the maximum value of detector 20 is 450 vehicles per hour (30 vehicles per 4 min).

Fig. 13 shows how many vehicles with only hard synchronisation have been recognised, i.e. have been followed through the system.

Image88.gif (4345 Byte)

Fig. 13: Hard synchronisation

Fig. 14 shows on top of the grey shaded area (hard synchronisation) the number of vehicles which have been recognised because of weak synchronisation. It can be noted that through the introduction of weak synchronisation somewhat fewer vehicles are synchronised by hard synchronisation. This is due to the fact that the detector tries first to synchronise weakly; if this is not possible (no vehicles are found after the detector), the detector synchronises in a hard way. The entire amount of recognised vehicles is higher with both recognition schemes.

Image89.gif (5795 Byte)

Fig. 14: Hard and weak synchronisation

Fig. 15 shows, what happens, if detector 19 and 20 know each other. Lane changes are possible. The introduction of lane changing increases again the amount of correctly recognised vehicles.

Image90.gif (6629 Byte)

Fig. 15: Hard and weak synchronisation with successful synchronisation

6. Conclusions

As computing power has become cheap, the way is open for adaptive, intelligent traffic control algorithms to try to solve today's traffic problems. Control algorithms base on real-time data, provided by vehicle detectors, which are available on the market for reasonable prices and with good reliability.

The detector information has to be pre-processed in order to be useful for the algorithm. Due to limited financial resources, often the desired detector information is not available, either the detectors are not ideally placed, or there are too few detectors available in the street.

The gap between the available information and the desired information about the traffic can be closed by a traffic observer. Its output cannot only be used as input for traffic controllers, but also for data collection in order to evaluate existing control systems or to develop new control systems.

The observer has to be configured, which can turn out to be a rather difficult work. Therefore every new observer has to be validated and has to be able to adapt itself to new situations in a limited extent.

The paper has therefore shown a way of building and validating a traffic observer. The observer is used for control in the city of Zurich and it is intended to be used for evaluation purposes in some other Swiss cities. It is also used for research purposes in Japan and in the eastern part of China.

It is crucial for any further traffic control development to take into account also the negative effects of being able to increase the traffic flow over existing intersections: an increase of capacity leads to an increase of traffic. As the way presented in this paper leads to an optimum usage of the resources, after a short time of smoother traffic flow, the controlled intersections will be as congested as before, due to the induced increase of traffic.

A wise traffic planning must intend to reduce traffic together with improving the traffic control concept. This is possible by improving the sojourn times for all those who use public transportation instead of their cars. Therefore it is important that traffic control systems can not only prioritise public transportation at single intersections, but also track individual vehicles as busses and streetcars throughout the system. This shall be a next step for this project.

References

Riedel, Th. (1994a). Controlling Traffic Systems, Doctoral thesis No. 10349, Swiss Federal Institute of Technology (ETH), Zurich.

Riedel, Th. (1994b). Processing Detector Signals for Dynamic Traffic Control. In: 7th IFAC/IFORS Symposium on Transportation Systems, Vol. 3 pp. 974-977. International Federation of Automatic Control, Tianjin, China.

Riedel, Th. (1995). VS-pCoq Spy User's Guide (formerly named TCDT - A Traffic Control Development Tool), Matsushita Communication Industrial Co., Ltd., Yokohama, Japan.