<figure><img src="image_1.png" /></figure>

HAL
open science

# Intelligent Traffic Surveillance System

Gérard Scémama

► To cite this version:

Gérard Scémama. Intelligent Traffic Surveillance System. 57th Annual meeting, Institute of Transportation Engineers, Aug 1987, New York, France. pp.333-337. hal-04276809

HAL Id: hal-04276809

https://univ-eiffel.hal.science/hal-04276809v1

Submitted on 9 Nov 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC0 1.0 - Universal - International License
<figure><img src="image_3.png" /></figure>

COMPENDIUM
OF
TECHNICAL PAPERS
## INTRODUCTION

The elaboration of an experimental software for traffic surveillance and control in central Paris [1] gave us the opportunity of making an in-depth analysis of the traffic surveillance task in an Urban Traffic Control Centre.

At the beginning, the matter was to solve the problem of congestion and understand why the automated system became inadequate, the processing of congestion remaining the privileged field of human intervention. Then it appeared that:

- the nature of the problem to be solved made us leave the framework of conventional automation (algorithmic processing based on the current state of detectors),

- the display of information inside the traffic control system had a non-negligible influence on the way to solve the congestion problem. Thus, if it appears important to try and model the congestion process, it is quite as primordial to build convivial and intelligent man-machine interfaces. We must wonder about the knowledge used by the operator, about his way of apprehending the process. These analyses allowed us to know what kind of information to make available to the operator.

Technological progress made during the last few years (coming of workstations with environmental ergonomics: multiwindows, bit-mapped graphics display screen and mouse) let us foresee what the "cockpit" of urban traffic control would look like tomorrow. In this framework, a design prototype, called SAGE (Systeme d'Aide a la Gestion des Embouteillages, ie System of aids to congested traffic) has been achieved in work station (Apollo DN300).

## THE OPERATOR IN THE FACE OF CONGESTION

In urban areas, the modelling of the congestion process is relatively difficult[2]. This is due mainly to the "network" aspect of congestion spreading. Firstly, oversaturation induce a serious lack of equilibrium into the values of the detectors serving the selection or adjustment of the traffic signal plans in real time. Secondly, we state that if we want to act on the process, we should follow the chaining of events. This necessity of a time analysis makes us leave a little the framework of usual automation.

However, one of superiorities of the operator resides just in his faculty of memory of events. In fact, the reasoning used is not necessarily complex.

It is based on the identification of the congestion causes (transverse route oversaturated, insufficient capacity of a junction, illegal parking, accident, ...). Then the operator uses his information at the right time in order to make a decision adapted to the situation.

The actions are of two types: they consist in favouring a route at one or several intersections or in holding excess demand on the specific links of the network, called "reservoir areas". In fact, the remedy often resides in a judicious combination of these two types of action.

**Example.**- When the operator makes the decision to favour a congested axis, he takes into account:

- The traffic situation downstream of the junction,

- the penalizing effect that this action will necessarily have on the transverse route upstream.

The considerations of free-flow traffic and absence of congestion causes downstream of the axis to be favoured are items that make the decision lean towards the action. Still, in order to be sure of its relevancy, we must have verified that the events having caused the former downstream congestion have quite disappeared.

The taking into account of the penalizing effect serves the modulating of the action and the fixing of the limits of repercussion authorized by the operator. This last clause can be blinded by the statement of congestion downstream of the penalized transverse routes. So we can see that the operator makes an appreciation of upstream and downstream congestion of the route to be favoured as well as of the penalized transverse routes.

## THE SAGE EXPERT SYSTEM

The reasoning mode of the operator is a process that is scarcely algorithmic. Then, in order to enter a human expert's knowledge into a computer, we had recourse to an Artificial Intelligence[3]. The Expert System (ES) technique consists in the elaboration of a knowledge base containing the expertness (rules and facts) of the field concerned. One of its main attractions is that knowledge is represented in an declarative way, which gives great suppleness to the evolution of software.

The modelling adopted in SAGE allows it to be carried to other sites: to make it run, it is sufficient to enter the new description of the network. The ES is composed of three main parts:
**The inference engine.-** SAGE is written in SNARK2[4,5], an inference engine. This part of the system is in charge of activating the reasoning procedures, selecting which rule dominates over the others and matching the rules with the facts of the knowledge base. SNARK2 was developed in order to take into account the necessity of functioning with the cycle of data acquisition (every 3 minutes). The real time aspect raised a lot of software problems (response time, storage memory, restart of reasoning procedures), most of which have been solved[6]. Let us quote some of the functions of this engine appearing essential for the development of this type of application:

- forward-chaining with exhaustive search allowing to deduce all the consequences of a network situation,

- first-order logic allowing to express the rules with variables,

- non monotonic logic allowing that a fact becomes false (change of the state of a sensor),

- incremental compilation dissociated from run. (It is necessary at each end of a cycle to compile only the new states,

- a garbage collector recovering the locations of former facts in the memory.

SNARK2 is written in PASCAL. In view of this first experiment, INRETS is developing a new AIDA[7] engine in the ADA language, still more directed towards real-time applications.

**The fact base.-** It includes both the description of the network with its permanent object -JUNCTION, LINK, ROUTE, ACTION, CAMERA- and the objects created by the very ES in its reasoning -CHAIN, CAUSE, INTENTION-. Each fact describes a property of the object and expresses itself in form of a triplet `<object, relation, value>`

coutellerie-932 class,LINK;
coutellerie-932 belongs, renard-st-jacques;
coutellerie-932, origin, C267;
coutellerie-932, congested-threshold, +3.000000E+01;
coutellerie-105, end, C105;
coutellerie-932, successor, coutellerie-105;
coutellerie-932, state, free-flow;
coutellerie-932, new_state, congested;

The objects are linked together by means of relations. Thus, in SAGE, we have the network of relation shown in Figure 1 between permanent objects.

<figure><img src="image_4.png" /><figcaption>Figure 1: Relations between permanent objects</figcaption></figure>

**The rule base.-** This part of the knowledge base contains the very reasoning in form of production rules. The rules belong to packages that will be

activated one after the other (notion of context). Thus, the reasoning takes place in several fundamental steps.

A production rule has the form "IF P1 & P2 ... & Pn THEN C1 & C2 ... & Cm"

rule : new�
properties;
priority : 0
comment : Generation of saturated chain along a
route
end properties;

{new_state(!link1) = congested
successor(!link1) = ?link2
state(?link2) = congested} ; ("not equal")
THEN
  create [fact_base,%chain]
  first(%chain) <-- !link1
  starting-junction(%chain) <-- end(!link1)
  belongs(!link1) <-- %chain
end rule;

!link1, ?link2 are respectively universal and existential register which can be assigned by any object of the network. %chain is a local register. "create" and "<--" are two functions of SNARK2: the first allows to create an object in the fact base, the second is an assignment.

Thus, if coutellerie-932 is congested and if the state of its successor, coutellerie-105, is not, the ES will generate, by means of the rule new�, a new object (Figure 2).

<figure><img src="image_5.png" /><figcaption>Figure 2: Saturated chains of the network</figcaption></figure>

This chain object, noted $S1$, will represent the congestion of the renard-st-jacques route at the starting-junction C932.

## THE SURVEILLANCE FUNCTION

The surveillance function in SAGE tries to meet the objective stated at the beginning of this paper. That is to say, we must be able to:
- detect the origin of oversaturation, make a diagnosis of it, asses its importance and evolution

- signal and restitute the background to the operator.

The ES reasons on concentration data delivered by detectors. These are transformed into states of free-flow traffic, congested traffic, unknown (in case of failures or absence of detectors) and only the "new states" are communicated to the ES. In order to meet the objective stated, the ES will create the "saturated chains" (set of congested or unknown links of the same route) and the cause objects.

<figure><img src="image_6.png" /><figcaption>Figure 3: Relations between the objects CAUSE, CHAIN, LINK, JUNCTION</figcaption></figure>

**Generation of chains.**- The creation of saturated chains allows us to detect the starting-junction of congestion (cf. the new chain rule). These chains can be modified according to the hypotheses that we want to make about links in an unknown state.

**Generation of causes.**- When the origin of congestion has been determined, SAGE will search for possible causes of forming these chains. The diagnosis elaborated is elementary. It resides in stating that a junction exit, starting-point of the chain, is congested. In this case, the ES creates a cause object pointing both the victim ant the guilty links (Figure 2, 3). If no guilty link can be found (this is the case when automatic data are not sufficient: there may be oversaturation in non-represented networks, double parking, an accident, ...), a cause object is still created in order to represent this unknown cause.

**Elaboration of chains.**- If a chain contains the link guilty of congestion of another chain, these chains are coupled together by a parental relation. The scheme of parents elaborated in this way is in general a tree of causes. These parents also serve the assessment of the extent of congestion of a chain (number of links whose congestion is due to this chain).

**Transmission of information** Then we transmit to each link the chain to which it belongs and its congestion causes passed through it. Each link points by its relation (current-cause) to the cause objects associated with it. If a new cause appears, the information is passed on to all the links of the chains. This property of information transfer is another part of modelling by chains.

**Memory management.**- Thanks to this principle, each link stores in the memory the different causes passed through it, whatever may be the evolution of congestion. The principle of memory storage adopted

is the following one:

- If a cause belongs to the unknown cause category, it will be kept in the memory as long as there exists a link of a congested state referring to it in terms of current cause.

- If a cause belongs to the identified cause category, it will be kept in the memory as long as the guilty link remains congested. When traffic on this link becomes free-flow, the links refer to it in terms of former cause. When there exists no more congested links pointing to the cause in terms of former cause and current cause, this cause object is removed from the fact base.

### ACTION CONTROL

A second function of SAGE is to ensure the processing of congestion. To do this, it has a certain number of pre-defined and pre-planned action means. A model was elaborated allowing the user to programm multiple objective actions combining favour and retain actions in several places of the network. We will not describe this model in detail, but we note that it allows the operator well to consider the example of paragraph 1: we are led to describe the constraints of the place where action is taken.

**Specific characteristics of action control.**- In the present version of SAGE, control mastering belongs to the operator: the system is presented as a tool of aids to decision-making. However, the level of development reached tends towards automation. The integration of an Expert System into a control loop is an aspect that has still been but little dealt with in the literature[8]. If this question can be dealt with here, it is due mainly to the particularity of the traffic process: it is slow and, on the other hand there are no safety preoccupations. The feasibility was also made during the elaboration of SAGE. The ES takes 30 secondes to make the processing of traffic control area in Paris (180 junctions). In this context, it is important to precise some of the specific characteristics of the control modelling adopted. Each action is supposed to take a finite number of states (passive, force1, force2, ...), corresponding to a gradation of the measure to be taken. So the ES activity will consist in determining the transitions to be made for these actions (Figure 4).

<figure><img src="image_7.png" /><figcaption>Figure 4: Graph of state transitions</figcaption></figure>

The control thus made can be compared to that of a finite automaton. In the meaning drafted in the ES, it is the control run (The ES knows when and how to act). The particularity of the system resides in the decision-making calculation using production rules and taking into account both current and memory-stored contexts. The memory and the
complexity of the decision-making process sets the intelligence level of the expert system compared with other type of modelling.

SAGE has no physical model of congestion process evolution, so it is not capable of predecting or anticipating the evolution of this process (there exists, however, an implicit anticipation in form of the taking into account of presatuated states of links and the consideration of excepted action effects). In the same way, this ES has no optimizing activities allowing it to adjust the control instructions. Adaptation is made only according to the intentions associated to the action context.

**Intentions.**- The decision making procedure is based upon:

- the generation of intentions associated with each action completing its static description. These intentions relate current or memory-stored contexts, characteristic of the situation of the action compared with its environment.

- a solution of conflicts between these different intentions leading to the decision-making.

The model that we propose for describing the operation of actions by means of their intention network can in reality apply to a great number of situations. When you question an individual about his way of operating, he rarely can give a satisfying answer that can be reproduced by a software programm. In fact, our individual can more easily answer the following questions:

- When to start an action?

- When not to start?

- When to stop an ongoing action?

- When to increment it?

- When to decrement it?

Answering all these questions allows us in fact to describe a great number of conduct activity. We can then set up the following listg of intentions associated with action: to start, not to start, to stop, to increment, to decrement.

**Example.**- Let us consider the action the action consisting in favouring a junction entrance:

- an answer to the first question can be "when the entrance is congested"; an intention to start will be then generated as soon as this state is observed.

- an intention not to start can be "when the dowstream of the entrance is congested".

We can see that, provided we have well "delimited the system", we are able well to describe the action to modelled by means of this texture. This example is rather illustrative of the expert system approach, which is much closer to our way of reasoning than quantitative approach. In order to cross a street, you do not make a learned calculation of the course of the arriving vehicle. You act in the same way as describe above, that is to say you have predetermined constraints generating an intention to start if the distance is judged long enough taking into account the estimated speed of the vehicle, not to start or even to stop if the distance is judged too small, to increment, or to decrement (that is to say accelerate or to decelerate) for immediate distances or when there are new events during the actions (stopping of the vehicle).

The decision-making about a transition is obtained by the analysis of existing intentions. If, for instance, there are simultaneously two contradictory intentions to start and not to start, the system will propose no action.

## THE SURVEILLANCE STATION

The ES having to examine exhaustively the traffic situation during a three-minute cycle cannot be interrupted. It results from this that there can be not direct dialogue between the operator and the ES. In fact, the ES cannot wait for a hypothetical answer of the operator. Moreover, the operator cannot have access to the trace of reasoning for the same reason and also because of its volume (some hundreds pages per time step).

The solution adopted[1,5] consists in separating the cyclical part of the operator system interface task. The user has two synoptics available. The first one is part of the cyclical tasks. The second one is accessible to the user. These two synoptics (identical at the starting of the system) represent the traffic control network. The links are divided into two categories:

- links without detectors, represented in white,

- links with detectors. They are represented if there is free-flow traffic on them, in red if they are congested, in blue if their detectors are out of order.

Some static information can appear (locations of video cameras, junction numbers, ...). Finally, symbols indicate to the operator the existence of "messages" from the ES.

**SAGE conclusions.**- The ES elaborates messages to the destination of the operator.

- Alarms signalling the starting-junction of a congested chain, its cause(s), its background, the cameras allowing to observe the situation. The alarms are displayed in form of junction numbers.

- Action proposals and follow-up of current actions. These are displayed in their application places with symbols indicating the nature and "state" of action (active, inactive, to be stopped). In the text of the message, the ES indicates the justifications of its proposals. These messages are elaborated by the ES. Their transfer to the interface task is made by means of a file.

**System-operator communications.**- The function of the "cyclical" synoptic is to display all the current message symbols to the ES. Thus, the operator has permanently under his eyes a syntetical view of the momentaneous situation. To him, the "interactive" synoptic is neither necessarily complete (possibility to make a zoom) nor necessarily updated (it is operator who commands the up-dating). The operator-interface dialogue is based on "commands" (accessible by means of the keyboard) and the possibility of "picking" graph entities on the synoptic (using the mouse). Thus, the interrogation of the ES messages goes by picking symbols. By return, the operator sees the corresponding message text being printed in the dialogue window.

**Operator-system communications.**- The operator has the possibility of giving information to the ES. He can force the state of a link. For instance, he can
indicate that such a link without detector is
congested after having stated this thanks to the
video camera network. He can also indicate to the
system the congestion cause. He will find this
information again in the corresponding message, in
the following step. These informations are
communicated to the ES at the beginning of a cycle,
in the same time as the automatically collected data
 detector states, starting and stopping of traffic
signal plans).

CONCLUSION

The experimentation of this prototype will be
achieved at the end of 1987. This step will allow us
to assess the system in real use conditions and
possibly rectify some aspects from the viewpoints
both of modelling the reasoning and facility of use
(interface). Then the system can be integrated into
the area traffic control of the City of n Paris
completing the existing tools. On the other hand,
nothing hinders us from writing an interface by return
between SAGE and the present traffic control system
in order to apply automatically the recommended
actions. An agreement was made between INRETS and an
industry company (CGA-HBS), an automation specialist,
in order to make them ensure marketing.

REFERENCES

1- B. Forasté, G. Scemama, "Surveillance and congested traffic control in Paris by expert system",

Proceedings of 2nd International conference on Road Traffic Control IEE 1986.

2- "Traffic Control in saturated conditions", OCDE report 1981.

3- J. Barnett, M. Berstein, "Knowledge-based systems: a tutorial", System developpement corporation TM (L), 5903, 1977.

4- J.L. Lauriere, "Un langage declaratif: SNARK", Technique et Science Informatiques, vol. 5, no 3, p.173-186, 1986.

5- B. Schnetzler, " SNARK2 (Symbolic Normalized Acquisition and Representation Knowledge) ", I.N.R.E.T.S report, August 1985.

6- B. Foraste, G. Scemama, "A real-time expert system for traffic control", Proceedings of the 6th International Workshop on Expert System and their applications Avignon 1986.

7- B. Schnetzler, "Unification dans une logique non monotone", (Pattern matching in a non monotonic logic), I.N.R.E.T.S report, January 1987.

8- James F. Allen, "Towards a General Theory of Action and Time", Artificial Intelligence 23, p.123-154, 1984.