Embed Size (px)
Citation preview
Internship Report—
July - December 2009
Diogo DE SOUZA DUTRA
Traffic Light PredictionA prediction algorithm to Intersafe2’s project
Mines Paristech
IMARA Team - INRIA
Contents1 About the Document 3
2 About the team 32.1 Inria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Ecole des Mines de Paris . . . . . . . . . . . . . . . . . . . . . . . 42.3 Lara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Introduction 53.1 PReVENT Project . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 INTERSAFE Project . . . . . . . . . . . . . . . . . . . . . . . . 63.3 INTERSAFE-2 Project . . . . . . . . . . . . . . . . . . . . . . . 63.4 Traffic Light Prediction Algorithm . . . . . . . . . . . . . . . . . 7
4 Traffic Light Controller Overview 84.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 Control Strategies . . . . . . . . . . . . . . . . . . . . . . 94.1.2 Detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.3 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Internal Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.1 Traffic Light . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.2 Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.3 Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.4 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.5 Actuation on Internal Parameters . . . . . . . . . . . . . . 124.2.6 Control Strategy and Internal Parameters . . . . . . . . . 13
4.3 System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3.1 Signalbau Huber . . . . . . . . . . . . . . . . . . . . . . . 144.3.2 The Inteface . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 Objectives 15
6 The Learning/Prediction Algorithm 166.1 A priori Knowledge: reverse engineering vs unniversal model . . 166.2 Theoretical Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.1 Markov Process . . . . . . . . . . . . . . . . . . . . . . . . 176.2.2 Monte-Carlo Method . . . . . . . . . . . . . . . . . . . . . 18
6.3 Unniversal Model and Algorithm . . . . . . . . . . . . . . . . . . 186.3.1 Unniversal Model . . . . . . . . . . . . . . . . . . . . . . . 186.3.2 Learning Stage . . . . . . . . . . . . . . . . . . . . . . . . 206.3.3 Traitement Stage . . . . . . . . . . . . . . . . . . . . . . . 216.3.4 Prediction Stage . . . . . . . . . . . . . . . . . . . . . . . 22
7 Results 24
8 Conclusion 24
1
A Implementation 26A.1 Traffic Light Controller Simulator . . . . . . . . . . . . . . . . . . 26
A.1.1 The API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26A.1.2 Algorithm Input Data . . . . . . . . . . . . . . . . . . . . 28
A.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.2.1 AnalyseBrute . . . . . . . . . . . . . . . . . . . . . . . . . 30A.2.2 TraficLightPred . . . . . . . . . . . . . . . . . . . . . . . . 33A.2.3 INRIA TrafficLightPrediction . . . . . . . . . . . . . . . . 35
A.3 Final Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.3.1 Learn Stage Output . . . . . . . . . . . . . . . . . . . . . 38A.3.2 Traitment Stage . . . . . . . . . . . . . . . . . . . . . . . 39A.3.3 Predition . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.3.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B Further Improvements 45B.1 Looking forward taking into account event influence . . . . . . . 45
B.1.1 Events Exploration . . . . . . . . . . . . . . . . . . . . . . 45
2
1 About the DocumentSections 2 and 3 start giving the context where this work takes place. Section2 introduces the groups and teams involved and describes their function onthis work. Section 3, otherwise, introduces and describes briefely the projectsaround this work.
Section 4 describes the system and it’s strategies, giving also some basedefinitions toward to a commom language. It presents also the interface usedto have system’s information, describing in which format this information comeand which data is neglected from the global system.
On section 5, based on previous information about the context and thesystem, some objectives are established to achieve a main goal.
On the sequence, section 5 will describe the solution designed to achieve themain goal. In a first time, some different approches are discussed and a model isproposed. In a second time, after some theorycal bases the solution is descibedon detail.
This section is followed by section A.3.4 that discuss some results came froman application of the solution proposed on 5.
And the document finishes discussing, on section 8, some conclusions andsome futures improvements that could be made toward better results.
2 About the teamThis document has as goal to present results reached by the development ofa traffic light prediction algorithm accomplished from July to December 2009within the context of Intersafe2’s project. It was performed as an Interneshipby Diogo DE SOUZA DUTRA (Engineer student at Ecole de Mines de Paris -ENSMP) on the French national institute for research in computer science andcontrol (INRIA).
As scientific steering responsables on this work Jean-Marc LASGOUTTES(INRIA)and Fabien MOUTARDE(ENSMP) were concerned about scientific guidelineson internship advancement. As internship responsable Samer AMMOUND(INRIA)was concerned about the whole work and it’s results.
Intersafe2’s project in an Europeen project concerned about increase safetyon intersections. ENSMP and INRIA are part of project team as LARA group(partnership between CAOR lab from Ecole de Mines and IMARA Team fromINRIA). On the specific case of this work, LARA group was the scientific sourceprovider. This topic will present a brief description about INRIA, ENSMP andLARA group.
2.1 InriaINRIA1, the French national institute for research in computer science andcontrol, operating under the dual authority of the Ministry of Research andthe Ministry of Industry, is dedicated to fundamental and applied research ininformation and communication science and technology (ICST). The Institutealso plays a major role in technology transfer by fostering training through
1http://www.inria.fr/inria/enbref.en.html
3
research, diffusion of scientific and technical information, development, as wellas providing expert advice and participating in international programs.
The Institute’s strategy closely combines scientific excellence with technol-ogy transfer. INRIA’s major goal for 2008-2012 is to achieve scientific andtechnological breakthroughs in seven priority domains:
• Modeling, simulation and optimization of complex dynamic systems
• Programming: security and reliability of computing systems
• Communication, information, and ubiquitous computing
• Interaction with real and virtual worlds
• Computational engineering
• Computational sciences
• Computational medicine
2.2 Ecole des Mines de ParisMINES ParisTech2 is an example of the French model of institutions for trainingengineers: the Grande École. The Grandes Écoles are teaching and researchinstitutions to which admission is highly selective. They are the equivalentof one or more university departments in the fields of the sciences, engineering,commerce and management. Their complete autonomy enables them to develophigh-level research and innovative teaching methods.
As streams of excellence, the Grandes Écoles provide France with the vitalcore of senior executives for industry and, what is more typically French, thecivil service.
2.3 LaraLa Route Automatisée3 is a joint research team between the IMARA team ofINRIA and the CAOR team of Ecole des Mines de Paris. These two groups,representing about 50 researchers, engineers and technicians, have worked to-gether for at least 10 years on the development, integration and experimentationof Information and Communication Technology (ICT) in order to improve roadtransport. They have been involved in numerous research projects financed byindustry, by the French government or by the European Commission.
The general philosophy is to assist the drivers in order to improve safety,comfort and efficiency of road transport. The ultimate goal is to remove com-pletely the driver from the control loop, at least in particular situations such asdedicated freeways and at low speed in urban situations.
2http://www.ensmp.fr/Fr/ENSMP/DocEcole/PlaquetteBilingue.pdf3http://www-roc.inria.fr/imara/lara2/en/index.php
4
3 IntroductionThe vehicle industry is a major global competitive business environment. Vehicletype approval is increasingly taking place at the European level, and requires inter-operability, harmonised development and market introduction of preventive safetyapplications.
In 2001, the European Commission adopted the White Paper on European Trans-port Policy for 2010, consisting of an analysis of the current transport and mobilitysituation and an action programme calling for a further 50% reduction of road fa-talities by 2010. These targets can only be reached by an integrated and holisticapproach. 4
3.1 PReVENT Project
The Integrated Project PReVENT is a European automotive industry activity co-funded by the European Commission to contribute to road safety by developing anddemonstrating preventive safety applications and technologies.
Preventive safety applications help drivers to avoid or mitigate an accidentthrough the use of in-vehicle systems which sense the nature and significance ofthe danger, while taking the driver’s state into account.
Depending on the significance and timing of the threat, the active and preventivesafety systems will:
• inform the driver as early as possible
• warn him or her if there is no driver reaction to the information, and
• actively assist or ultimately intervene in order to avoid an accident or mitigateits consequences.
Preventive safety applications also help drivers to:
• maintain a safe speed
• keep a safe distance
• drive within the lane
• avoid overtaking in critical situations
• safely pass intersections
• avoid crashes with vulnerable road users
and last but not least, reduce the severity of an accident if it still occurs.Preventive safety makes use of information, communications and positioning
technologies to provide solutions for improving road safety. With such technology -which can operate either autonomously on-board the vehicle or co-operatively basedon vehicle-to-vehicle or vehicle-to-infrastructure communication - the number ofaccidents and their severity can be reduced, leading to a decrease in the number ofaccidents.5
4http://www.prevent-ip.org/en/about_preventive_safety/european_context/5http://www.prevent-ip.org/en/about_preventive_safety/introduction/
5
3.2 INTERSAFE Project
Accidents at intersections happen when drivers perform inappropriate manoeuvres,fail to anticipate other drivers’ actions, or miss road signs or signals. The develop-ment of advanced sensor systems and algorithms can provide accurate localisationof the driver’s vehicle and path prediction of other road users. Combining this withsignal status communication, it will be possible to warn the driver of potentiallyhazardous situations.6
As a PReVENT subproject INTERSAFE aims to contribute to intersection safetyby the analysis of intersection-related accidents, sketches ideas for accident preven-tion and finally providing solutions for enhanced intersection safety. [4]
To achieve these aims, concrete requirements for INTERSAFE were built:
• develop a test vehicle that can provide warnings to the driver based on :
precise localisation using on-board sensors
detection, classification and path prediction of all other objects at theintersection
communication with traffic lights
high-level map information
• Create algorithms and sensor/communication requirements for next-generationintegrated intersection safety applications, based on advanced driving simula-tor evaluations for intersections
3.3 INTERSAFE-2 Project
Builds on the experiences gained in the previous INTERSAFE project (part of the6th Framework Programme) and completes on performing further steps towardsrealisation of a market-ready product, INTERSAFE-2 project aims to develop anddemonstrate a Cooperative Intersection Safety System (CISS)7 that is able to sig-nificantly reduce injury and fatal accidents at intersections.
The cooperative sensor data fusion is based on:
• state-of-the-art and advanced on-board sensors for object recognition andrelative localisation,
• a standard navigation map
and information supplied over a communication link from
• other road users via V2V if the other vehicle is so equipped
• infrastructure sensors and traffic lights via V2I if the infrastructure is soequipped
to observe the complex intersection environment.8
6http://www.prevent-ip.org/en/prevent_subprojects/intersection_safety/intersafe/
7CISS is a complex communication system between actors at an intersections. This conceptwas introduced on INTERSAFE-2 to define the techinical mean to achieve the project’s maingoal: reduce injury and fatal accidents at intersections.
8http://www.intersafe-2.eu/
6
3.4 Traffic Light Prediction Algorithm
As part of INTERSAFE project a work was made toward on the possibilities of atraffic controller to provide useful data for vehicles. These data could close infor-mation gaps the driver can not see, and warn the driver in order to avoid criticalsituations.
The Interface Adaptation of Traffic Light Control report[4], an INTERSAFEdelivrable, describes the prototypical implementation of an enhanced traffic lightcontroller for tests of the traffic light assistance function. This assistance functionis based on infrastructure-to-car (I2C) communication also described in this report.The traffic light assistance system is intended to support the driver when approach-ing an intersection equipped with traffic lights. By means of this system the drivershould be enabled to adapt his velocity according to the traffic light’s status. Incase of a possible red light violation he is warned not to pass the stop line.
At the start of the INTERSAFE project, the partners expected to get a signalplan for at least 5 to 10 seconds in advance. This might have been the easiest wayto give the driver reliable hints for action to be taken when approaching a traffic-controlled intersection. For example: best velocity, time to brake or to start and soon.
Today, however, the controllers are most often optimised by dynamic, traffic-dependent algorithms. These algorithms make it impossible to have a 100% reliableview of the next 5 to 10 seconds. In particular, priority demands of public trans-port (PT) vehicles will influence the control algorithms with unpredictable timing,because the reaction period for such an event is only about one second. Normaltraffic will also influence the time schedule within a second.[4]
As is a dificult task to have a traffic light time changing information from thecontrollers a solution is to have an embedded device programmed to learn and topredict the time of next traffic light changes.
On [4] a description of an algorithm for predicting traffic light status is given.However, as a fisrt result simple statistics approaches were used making it’s appli-cation restrict to some specific controllers.
Therefore, there is a need to improve and to enlarge this algorithm to reach themaximum of kinds of controllers, providing an useful prediction to be used on adecision maiking at an interface.
The goal of this work is, thus, to study and construct a model of traffic lightcontrol (encompassing all different controller’s strategies) permitting a time-changeprediction for all traffic lights controlled at the intersections. As result from thiswork a computer application, that fills some embedded specification, will applythe prediction algorithm. An algorithm quality analyzis will be also performed anddescribed on this work.
7
4 Traffic Light Controller OverviewTraffic signal control has become an important operational measure of roadtraffic management, in particular as it has become more and more difficult toprovide sufficient road space despite growing traffic demand.
Since traffic signal systems directly intervence in traffic by alternatively stop-ping or releasing traffic flows which share conflict zones, they have to be de-signed, implemented and operated very carefully.[1]
This section will present the traffic signal system according to "SteeringCommittee Traffic Control and Traffic Safety"[1].
4.1 System OverviewAs a controlled automatic system, a traffic signal system can be divided on:detectors, a controller and actuators. Detectors are the elements that transforma physical information in a eletrical signal that can be undestood by a controller.Actuators are the elements that transform an eletrical signal came from thecontroller in a physical actuation. The controller is the elemnet that have alllogic rules to control actuators based on signals came from the detectors.
In a traffic signal system the parts that constitute the system are:
• detectors: loops (for vehicles presence detection), pedestrian buttons (forpedestrian detection), internal clock (time detection).
• controller: traffic light controller.
• actuators: traffic lights (severals states).
The design of a traffic signal system covers the selection of the control strat-egy, i.e. the selection of severals rules to change the traffic lights based on thedetectors information. These rules are dependent on the traffic engineer de-scription of control, on the calculation of the signal program elements as wellthe road traffic engineering design of the intersection, road section or part of anetwok including the corresponding control measures.
The individual components, as for exemple the actual layout of the inter-section, the division of approaches into lanes, the direction of pedestrians andcyclists and the signalisation of the individual traffic streams have to be co-ordinated in a way that precondition for safe traffic flow are given under alloperational condition and for all traffic loads. Road space layout, traffic layoutand signalisation have to form an integrated whole.[1]
Summarizing, the controller internal logic is based on a control strategy thatwill depend on traffic stream, intersection layout and etc. Based on these studiesa control strategy is built using logic functions depending on previous signalconfigurations, time on the current signal configuration and others detectorsactivation. This logic act in two levels on traffic lights: state changing and stateperiod. See fig 1
However, as said before, the control strategy will depend on all intersectionlayout and stream, thus, the changes on time and state of a sigle traffic light hasto follow all other changes on the traffic lights at the intersection. Therefore,the control strategy has to be related to configurations of all signal groups atthe intersection et not just one especific traffic light.
8
Figure 1: controller internal logic
4.1.1 Control Strategies
Control strategy in a traffic light control can be classified in two types: regulativeand adaptative traffic control. "Regulative traffic control is preferred if a rigidoperational traffic management is desired on certain road sections. It requiresconstant traffic streams featuring only long-term changes in volume since it notmeant to react to short-term variations on traffic demand"[1]. Otherwise "Adap-tative traffic control is preferred if actuated operational traffic management isdesired, taking into account the prevailing traffic situation even at short-termvariations of volume or direction of traffic"[1].
In a Regulative traffic control the system normally consist in a controllerand his traffic lights. As only input the time will be the sigle variable usedinto the control actuation. In this strategy, as there are constant streams, otherdetectors normally are not necessary. Therefore, controller’s logic is based justin fixed times came from traffic flow studies at the intersection and it’s actuationis based on a comparation between passed time and the fixed times given bystudies.
In an Adaptative traffic control strategy other detectors are constantly usedand they will interfere in the controller logic to changes phases at the inter-section. In this strategy, not just time is used to act on the system and alldetectors, depending on priorities, can have an influence on the output.
4.1.2 Detectors
To understand what kind of influence and changes we can have in an adaptativetraffic control strategy it is necessary to know what kind of information we canmeasure. Even if to vehicles detection normally there are only loops on theground detecting vehicle presence, it’s possible to have many different variables
9
that will ifluence on the control strategy. With some different disposition orchanging loop length is possible to measure:
• time headways: Time between two vehicles.
• traffic volume: Number of cars in an specific period of time.
• period of occupancy: Time that a vehicle stayed on the detector.
• speed: With two loops in sequence is possible to measure speed.
To pedestrians detection there is a pedestrian button that detects a pedes-trian presence when he pushes the button.
Therefore, mixing time detection with presence loops it’s possible to createa series of variables that will influence f function. Thus, we have a intermediatestep between stectors and logical function on controllers (Fig. 2)
Figure 2: controller internal logic with an intermediate treatment
All these variables will be analyzed by the controller logic, it will comparethe instant variable with minimums and maximums values for this variable. Asresult, the controller will chose an actuation form. To more information aboutcontrol strategy and detectors logic see [1].
4.1.3 Actuators
As it can be seen in fig. 1 and 2 the controller logic function output will dependon all it’s input variables. Until the moment it’s known that output can influencechoosing stay at the same signals configuration (or define a duration time to thecurrent signal configuration) or change to another one. [1] defines 4 differentpossible influence but in a intermediate level, influendes that changes a internallevel on the control function.9:
9These internal levels will be discussed on section 4.2
10
4.2 Internal ParametersThis section will give some important internal controllers concepts. Conceptsdefined, it will be possible to understand how the internal logic is modeled andhow exactely the control acts, as was said in section 4.1.3. Therefore, it will bepossible to understand how the logic function f (fig 1) is designed.
4.2.1 Traffic Light
As said in 4.1 the traffic light is the actuator of the system. It can be a two(pedestrian) or three (vehicles) colors traffic light whose states can be:
• Released:
Dark
Yellow Blinking
On
Green
Green Blinking
Released
• Closed:
Red
Off
Blinking
Closed
• Transition:
Yellow
Green Blinking Transition
Red-Yellow
• Unknown in special cases.
Moreover, for some control strategies there are well defined sequece, forexemple for normal vehicle traffic the color sequence is Green-Yellow-Red anfor pedestrian traffic light is Green-Red-Green. The control strategy consists inmake choices on the traffic light state and on how much time the traffic lightwill stay on this state.
4.2.2 Phase
As was said in 4.1 a controller has to control the stream in all direction at anintersection. To achieve this goal some traffic light configurations are continu-ously repeated. These configurations are called phases. [1] gives a more rigorousdefinition: "A phase is that part of a signal program during which a certain ba-sic signalisation stage dos not change, whereby the green times of the releasedtraffic streams do not necessarily have to begin and end at the same time". For
11
exemple, in a simple intersection with 4 traffic lights10(see figure 3), a controllercan have a minimum of 2 phases (2 first phases on figure 3). It can have morephases if specific cases, as for turning left (last phase on the example on figure3), are treated. Thus, a controller stratagy has it logic for control the sequenceof possible phases and not just individual traffic lights.
Figure 3: Phases example
4.2.3 Cycle
The logic controller function will chose, depending on controller input variableson time, a sequence of phases that respect all requirements to a good road trafficmanagement (see [1]). A sequence starting on a phase "a" than over some phasescomes back to phase "a" is called cycle. A control strategy can also changes acycle depending on controller income variables.
4.2.4 Program
A group of cycles carrying the same influences (rules) by a control is called pro-gram. The program are use for long-term changes on cycles. To control strategyit’s possible classify control input variables effect in two types: macro and mi-cro affectation. Macro affectation will interfere in program changes (long-termchanges on sequence and duration time) and micro affectations will interfere onthe cycles (time and sequence of phases).
4.2.5 Actuation on Internal Parameters
As was previous said in section 4.1.3, the controller actuation has an interme-diate level actuating on the internal parameters (phase, cycle, program) beforegiving the final visual effect on traffic lights and on the traffic flow. [1] defines4 different possible influence on internal parameters (figure 4 for an overview):
10to simplify traffic lights are suposed to change between 2 states: red and green
12
• Green Periods: Changing in green times (actuation on duration times ina sequence of phases sharing the same green state in a single traffic light).
• Phase Swapping: Alter phases sequence (actuation on number of phasesin a cycle).
• Request of a demand phase: Alter number of phases and green periods(actuation on the phase number and duration time at the same time).
• Signal Program Formation: Can alter green times, phase sequence, phasenumbers and change the cycle time. (very open strategy)
For each of this affectation there are interesting application cases (see Annexeof [1]).
Figure 4: Overview of the Control Strategies - Table 2[1]
4.2.6 Control Strategy and Internal Parameters
In a Regulative traffic control all internal parameters are fixed and determinists.The programs are time-fixed, so there is a schedule that control a programchange during a day. Cycles are also time-fixed and for each program there isjust one cycle, therefore, there is a fixed sequence of phases that repeats in loop.In consequence, phases are time-fixed as traffic light states as well.
In an Adaptative traffic control strategy all previous affectations are possi-bles. There are micro and macro affectations, different cycles in a program dueto duration time changing in phases or due to phase inclusion on the middle ofa cycle.
4.3 System InterfacesTo have access to traffic light data at an intersection it is necessary to com-municate with the controller. This information access is controlled by an com-munication interface that allows an other system get traffic light informations
13
as input and use as it needs. Regarding the system as was saw until now, thesystem interface represent a huge information decrease. Thus, for an embed-ded application in a traffic controller it is necessary to define a minimum ofinformation to achieve the goal.
4.3.1 Signalbau Huber
As a partner in Intersafe-2 project, Signalbau Huber1112 was indicated to givethe technical support on traffic controller. As one of the main company occu-pation is traffic light controller devellopement, Signalbau Huber, in this work,was the entity reponsable for the integration of the embedded system into thecontroller.
As they also have the physical structure, they formulated the requirementsfor the embedded system and in a first step Signalbau Huber started devellopingan comunication interface and a traffic controller simulator serving as a base tostart the embedded system devellopment.
Requirements To facillitate the integration process, the embedded systemwas thought as just a function called by the controller each second. On this waythere is no problem concerning information changing as the embedded systemin inside the controller code.
As the traffic controller is programed in Java programming language, to theembedded system it was required an Object-oriented language as C++ or Java.However, choosing Java an other incovinient should be taken into account: thereal-time application nature of the problem13.
Concerning the physical part an Processor AMD 133Mhz, 128Mb Memory,6Mb for storage were the base configuration avaliable for the embedded system.
Communication Interface Seeing the embedded system as a function onthe controller program, the communication interface was define as two objectscalled PredictionInput and PredictionInput14 that were passed to the function.
Traffic Controller Simulator To simulate a traffic controller and to givereal data to work, an sctructure formed by buffer files, containing real trafficlight data, and an API was designed and gived to start the embedded systemdevellopment. To more details on the API see Apendix A.1.1.
4.3.2 The Inteface
With an basic idea of the final application and his structure is possible to de-fine some important informations at the project begining, however during thedevelopment could be necessary to request more information that wasn’t see asimportant before. This dialog with Signalbau Huber was essential to projectprogress.
11worldwide company supplier of traffic technology systems and solutions12http://www.signalbau-huber.de/en/home13As well know, Java’s Garbage Collector is the element that difficult real-time applications
on Java language as it takes considered time during his actuation. To outline this problemand implement the embedded system on Java an approche without objects instatiation duringprogram run is needed
14where all needed information could be accessed by their atributs
14
The informations possibles to acces through PredictionInput objetc was:
• timestamp: represents a time counter in milli-seconds.
• currentSiganlProgram: represents a program’s id.
• nextSiganlProgram: represents next signal program’s id. Some controllersare not able to give this information.
• cycleTime: represents all cycle’s duration in 10th of a second.
• programCounter: represents current program’s time counter in in 10th ofa second. It starts at 0 and goes until de cycleTime value and restarts.
• currentPhase: represents the current phase. Some controllers are notable to give this information because there are controllers that are notprogrammed using phases.
• nextPhase: represents the next phase.
• phaseCounter: represents the time in current phase in 10th of a second.
• modification: represents variables meaning values of all signal programmodifications. These flags can be used (to set/get) by the traffic engineerto influence the signal program behavior. There are 19 modifications. Thefirst three (VA, OEV, IV) are provided by the traffic control. The other16 can be customized by the traffic engineer.
• detectorState: represents variables meaning state of all detectors
• sgState: represents variables meaning state of all signal groups accordintto 4.2.1 classification status.
• outputState: represents variables meaning state of all outputs. This is thestate of actuators controlled by the traffic controller through the activesignal program. For example pedestrian signal requests can be confirmedto the requester by that mechanism.
On Appendix ?? some different PredictionInputs from severals traffic con-trollers and further information aboout input data can be founded.
5 ObjectivesAs already said in 3.4 the embedded system limitated by all requirements saidin 4.3 has to give a time-changing prediction for each traffic light status on theintesection. The main idea is an general algorithm that could be applied to anykind of traffic controller.
However, just a information as a prediction is insufficient as is not possibleto know how good is this prediction. Thus is necessary more information thena simple prediction and based on the role information is possible to make somedecisions on the utilisation of the information.
As was the case for the input informations on the begining some outputinformations can be defined, however during the devellopment some algorithmscould change the possibility of giving those informations.
The informations request and acces through PredictionOutput objetc was:
15
• nextSgStateChange: represents variables meaning the predicted time tonext signal group state change in seconds.
• nextSgStateChangeProbability: represents variables meaning the proba-bility in percent of the predicted value.
• nextSgStateChangeMin: represents variables meaning the predicted min-imal time to next signal group state change in seconds.
• nextSgStateChangeMax: represents variables meaning the predicted max-imum time to next signal group state change in seconds.
To simplify the task, the algorithm just needed to predict microaffectationsituation, i.e. into programs, prediction of a program changing could be ne-glected.
6 The Learning/Prediction Algorithm
6.1 A priori Knowledge: reverse engineering vs unniversalmodel
Two different approches could be used to achieve a model and, in a second time,a prediction algorithm: the reverse engineering approach and a universal modelapproch. Each one is linked to classical model approches, reverse enhineeringto bottom-up approach and universal model to top-down approach.
The main idea into reverse engeneering approch is to study a set of differenttraffic controllers exitents and model them into one or many system models.Normally this approch takes into acount every single different comportment,finding inn the end, a very complex model that take into acount evere singularity.
However, into unniversal model approach the main idea is to model the maincomportment of a traffic light controller. Normally this approch take into acountjust the main comportment and see exception as a noise on the system model.On that way a simple model is produced, however on singular comportmentsthe model will not give very good results.
On this work an unniversal model approach was prefered based on the re-quirement of an general algorithm that could be applied to any kind of trafficcontroller. Thus, a unniversal model should have a answer for all traffic con-trollers unlike an reverse engineering model that could not take into accounta little singularity and in consequence couldn’t assure a answer for all trafficcontrollers.
Even though, as is discussed in Appendix B.1, probably an mixed aproachto model the events could be more effective the the unniversal mode approchalone.
6.2 Theoretical BaseBefore describing how the prediction algorithm is built, it is necessary to intro-duce some statistics concepts that will be useful to justify some choices in themodeling process.
16
6.2.1 Markov Process 15
A Stochastic Process is characterized by his random function, i.e. a randomvariable family (Xs)s ε S , defined in a same probabilistic space (Ω,A, P ) andindexed by s describing S space. Thus, a random function is a 2 variablesfunction s ∈ S, and ω ∈ Ω.
X : S × Ω → <
If s fixed in S, Xs is a real random variable defined in (Ω,A, P ), otherwise withω fixed in Ω, Xw is a function variable according to s and, normally, is not aregularly function.
In the literature, when s is connected to a time, Xw is called "stochasticprocess trajectory".[2] Specifically talking, on discrete time Xw can be charac-terized by a sequence (Xn, n ∈ N) in time
Therefore, each Xn is a random variable associate to a state in a statediagram and the sequence of realizations will give a realization for the globalprocess. In this case it’s possible to define a probability P (Xn = xn) giving theprobability to reach a state xn in a time n.
In this context, we can define a Markov Process as a Stochastic Processsatisfies Markov Property and specifically, on discrete time, a Markov Processis called Markov chain. Thus, a Markov chain is a random function Xw char-acterized by a sequence od random variables (Xn, n ∈ N) satisfying MarkovProperty. Markov Property can be seen as a system’s property saying that theprobability of the next state will depend only on the current state
P (Xn+1 = xn+1/X0 = x0, . . . , Xn = xn) = P (Xn+1 = xn+1/Xn = xn),
i.e. it’s a strong property that forgets all past and says that the next step willdepend just on the last step made.
If we have a finite number of states is possible to construct a Markovian (orstochastic) Transition Matrix Q = Q(x, y/x, y ∈ E), where E is a finite statespace, x is the current state and y is the future state. Each line of the matrixrepresents a probability state change distribution and its sum should be 1.
Q(x, y) ≥ 0 (∀x, y ∈ E),∑y∈E
Q(x, y) = 1 (∀x ∈ E)
We can define the probability of going to a state xn+1 coming from a statexn as
P (Xn+1 = xn+1/Xn = xn) = Q(xn, xn+1)
Therefore it is possible, using the Markov property, not only to make onestate prediction, but a arbitrerily long state sequence prediction and even, insome cases, find a stationary state. Thus, if the current state is xn, the proba-bility for a state xn+2 passing first by xn+1 will be
P (xn, xn+2) =∑xn∈E
Q(xn, xn+1)×Q(xn+1, xn+2)
Using this method, it is possible to have all probabilities in any future timek just multiplying transition matrix k times.
15This entire section is based on [2]
17
6.2.2 Monte-Carlo Method 16
The Monte-Carlo Method is a statistical method that uses a series of randomexperiments to construct an estimator for a variable in a system where an ana-lytical method is very hard to apply.
The idea is to construct a sampling (x1, x2, x3 . . . xn) from a random variableX (following its probability density) and calculate a Monte-Carlo estimator fromthis samples.
The empirical mean fn = 1N
∑Ni=1 f(xi) is the simplest example for a Monte-
Carlo estimator, because from some samples following probability density fX ofX it’s possible to construct an estimator for the random variable.
Mont-Carlo method is applied in others different fields, as example, he isoften used to estimate areas and volumes from random points distributions inthe area (volume).
There is also a great use for Mont-Carlo Method in Markov Chain calcu-lations. To predict future states it needs some matrix multiplications, as sawin 6.2.1, and depending on the size of these matrix the calculus can be veryhard to do. It can be solved using a series of random "experiments" followingthe probability distribution on the matrix and have estimator for each possiblesequence of states.
6.3 Unniversal Model and Algorithm6.3.1 Unniversal Model
Model Base Element As it can be seen at Fig. 4 it is possible to say thatif stabilished a model to the control strategy whose the possibles "variableselements" (accorting to the table) are all variable, all others strategies can bemodeled as sub-sets of the "all variable elements" model.
Into a program will there are 3 possibles elements that could be used as anelement base to the model: traffic light, phase and cyle.
Using traffic light as the model base element a cause-effect phenomena, orthe markovian property inherent to the system, is lost. It is known that an de-termined phase may change to a finite sub-set of phases depending on it’s ownconfiguration. For exemple, taking Fig. 3 again, if the current phase is phase1 =g, r, g, rwhereg = greenr = red, taking into accaunt all possible configurations,it’s possible to find some forbiden ones, such as g, g, g, r, g, r, g, gorg, g, g, g.Even more, some times17 a traffic light controller has a fixed (deterministic)sequence, for exemple could existe always a sequence made by phase3, phase1and phase218. Therefore, for regulative traffic control all sequences are deter-ministics19 and it is possible to find all sequences (cycles). However, in anadaptative traffic control, some times it will be possible to find some determin-istic paths, but in other ones the only information that it is possible to have isa finite sub-set of possibles phases. Besides, for each element in this sub-set itwill be possible to have a probability value for the changing phase process.
16This entire section is based on [3]17always for Regulative traffic control18An intersection could be in a situation that evertime, in a main street direction at a
major street, there is a need to open a turning left green (phase3) before open the flow in the2 directions (phase1)
19see definition of cycle in regulative traffic control, section 4.2.6
18
On another hand, using a cycle as a model base element could give too muchinformation, making difficult the task of finding cause-effects phenomenas intoevents action. For a regulative traffic control, a model using a cycle as baseelement should work as a cycle is fixed in regulative traffic control. However,for adaptative traffic control, using cycle as base element could give a huge setof cycles with diferent lengths, due to non-deterministic phase-changing insidethe cycle. Therefore an analysis, comparing differences on cycles, seems to betoo complicated to implement.
Thus, using phase as base element, seems to be the best choice. Howeverit’s difficult to know, in a first approch, which degree of past phase dependencethis phenomena has. Besides, the sub-set due non-deteministic paths should besolved by the hypothesis that there is a deterministic link between an event anda choice on the sub-set phases.
Learn/Prediction Approach This markovien property inherent to the sys-tem can be studied on different aproaches. It seams, however, logic that thisalgoritm have to be at least two stages: a learn one, to classify the sub-sets ofpossible changing-phases; and a prediction one, to predict based on the previousclassification and event’s income. Two different aproches comes out: an Markovchain and a AI approach.
The statistical (Markov chain) approach is centered, in the learn stage, on acontruction of a transition matrix between all possible phases; and in predictionstage, on a set of percentages representing the probability to passe into eachphase. Otherwise the AI approach is centered, in the learn stage, on classifyingmethods 20; and in prediction stage, on research methods at the AI obejt-structure.
As saw in section 4.3.1 the is a physical memory to be respected, thus, themodel approach has to product, at the end of the learning phase not so heavymemory objects. Normally, AI objects can occupy a very huge space in memory21, otherwise statistical (Markovian) objects (tables) are very light in memory.Therefore, statistical approach seems to be more appropriate.
Time vs Phase Prediction As a first step, modelling traffic controller changesas a first order markov chain using phase as the random variable can show inwhich level of phase/event dependence the traffic controller has. However aclassical model using Markov chain do not take into account different timesduration on a state, to the classical approch the transition matrix has to behomogenous22 and each time step has the same length.
There are in literature some Markov chains applications using non-homogenoustransition matrix, changing, thus, dynamically the step time.
However, looking forward to start working with simple objects and easy toundestand, even if they do not represent the system in a best way, a secondtime step should be improve the model making complex objetcs using the firstone as base.
A simple solution found was to keep the classical Markovian chain approchusing phase as base elements an work with time into a phase separately. There-
20for exemple, binary tree or neurone network21depending on the learn stage time22time independent
19
fore, Time and Phase prediction shoud be made in parallel to achieve a fullcomportment prediction.
To manage time prediction a similar approch the transition matrix was used.It was defined TimeInPhase Matrix Λ = Λ(x, t/x ∈ Et ∈ N), where E is a finitestate space, x is the current state and t is the discrete time. Each line of thematrix represents a probability distribution for time on teh current state andits sum should be 1.
Λ(x, y) ≥ 0 (∀x, y ∈ E),∑y∈E
Λ(x, y) = 1 (∀x ∈ Eandt ∈ N)
We can define the probability of staying t seconds on current state x as
P (T = t/X = x) = Λ(x, t)
This approach to model the traffic light controller use simple tools, thus, itshould provide a safety, robust and unniversal model to make predictions. OnAppendix refsec:LearnStageOutput some Transitions and TimeInPhase matrixgenereted by the algorithm in the learn stage and further informations aboutlearn stage implementation can be found.
6.3.2 Learning Stage
As was said in section 6.3.1, phases are the choosen base alements to contructa first unniversal model to make taffic ligth predictions. It was also describedtwo elements (Transitions and TimeInPhase matrix) that were choosed to mod-elingvthe possible changes in a current phase.
Therefore, Learning Stage can be defined as an online stage 23 that constructthese two matrix.
Transition Matrix To build a transition matrix, the main idea is to countoccurences of changes from a phase x arring into a phase y. The online algorithmhas to identify the current phase and on the moment that it changes for anotherphase it should have increment the correponding cell on transition matrix. Forexemple, the current state of the algorithm idetify a current state xi and aftera few seconds keeped at this state it identify the current state as yj . At thismoment, the previous value k ∈ N of
Q(xi, yj)
is incremented and the nez value will be
Q(xi, yj) = k + 1
.At the end, learning stage gives as output an occurence phase-changing
matrix that could be also called transition matrix 24.23that works at the same time it recives data24To reach the classical Transition matrix each value in a line has to be divided by the value
of the line sum
Q′(x, y) =
n∑j=0
Q(xi, yj)∑ni=0 Q(xi, yj)
(∀x, y ∈ E)
20
The number of phases and, therefore, the transition matrix length will de-pend on the intersection configuration and has a quasi-fatorial increse dependingon the numbers of traffic lights.
TimeInPhase Matrix To build a TimeInPhase Matrix, it will be taken thesame priciple used to buit Transition Matrix. The main idea is to count oc-curences of a duration time t into a phase x. The online algorithm has toidentify the current phase and on the moment that it changes for another phaseit should have increment the correponding cell on transition matrix.For exem-ple, the current state of the algorithm idetify a current state xi and after a tjseconds keeped at this state it identify the new current state. At this moment,the previous value l ∈ N of
Λ(xi, tj)
is incremented and the nez value will be
Λ(xi, tj) = l + 1
.At the end, learning stage gives as output an occurence DurationTimeInState
matrix that could be also called TimeInPhase matrix 25.The TimeInPhase matrix length will depend also on the number of phases
but it will depend on the maximum of phase duration time.
6.3.3 Traitement Stage
It is on this intermediate and offline stage that the changing-phase model, rep-resented by Transitions and TimeInPhase matrix, is manipulated to produce aninformation closed to the prediction algorithm output. In fact, this infomationproduced will be the base for an online algorithm that, based on this informa-tion and taking into account the current state and events influence, gives allnecessary outputs.
In a first approche to build an unniversal model to events there were not somuch progress. The initials and basics hypothesis proved to be wrong leadingto some details omission on detection mechanisms and evets logic. On theAppendix B.1 some hypoteses and initial models for events are illustrated andsome ideas to be explored are proposed.
Therefore, as said on section 6.3.1 a unniversal model without take intoaccount events will have allway an prediction answer to give. However, fornon-deterministic cases the prediction has risk of been poor.
Monte-Carlo Simulation To produce an unseful information for the nextstage, for the current phase, a time prediction and a next phase estimators hasto be choosen on TimeInPhase and Transitions matrix respectively. Thereafter,comparing the two following phases, a traffic light changed set will emerge and
25To reach the defined TimeInPhase matrix each value in a line has to be divided by thevalue of the line sum
Λ′(x, t) =n∑
j=0
Λ(xi, tj)∑ni=0 Λ(xi, tj)
(∀x ∈ Eandt ∈ N)
21
for those the TimeInPhase estimator will be the time-change prediction estima-tor.
Create an estimator for each random variable, represented by its probabilisticdistribution described on each matrix, is not a very dificul task. The mostprobable value is an estimator, the mean value is an estimator also. However,these estimators are poor e do not represent well the random process.
Following what was said on section 6.2.2, the Monte-Carlo method is amethod that uses a serie of experiences, or simulations, to construct betherestimators to a random process.
Looking to the model using the two matrix, a simulation will give as outputtraffic lights time-change predictions value following the two distributions. Do-ing several simulations, a Prediction table could be constructed and each linewill represent a time-changing distribution for each traffic light.
For exemple, for each state Snn ∈ N a simulation step could be characterizedas:
1. Random choice under Sn distribution on Time Durantion Matrix;
2. Random choice under Sn distribution on Transition Matrix;
3. Accounted for the traffic changed tc from phase Sn to Sn+1 the timeduration before change;
4. Accounted global time tglobal of simulation;
5. If (tglobal>thorizon or all traffic has changed) finalize simulation, elsereturn to step 1 knowing tc;
Where thorizon is a simulation maximum time chose on the beginning ar-bitrarily. A simulation will continue until all traffic light has changed or untilthorizon had been exceeded. This condition is needed to limit the search timefor all traffic light changed state as some times a single traffic light change’sprobability is too low that a simulator could take too much time waiting onlyone and not so probable traffic light.
On appedix A.3.2 some pratical results and distributions can be seen withfurther information on the implementation of the traitment stage.
6.3.4 Prediction Stage
After two stages, the single information arriving into the prediction stage is aprediction table. For this online stage the sigle concern is about how to choosea predition among all distribution. Fig. 5 illustrates a information diagramrepresention all prediction algorithm.
Prediction choice paradigm As said before, at this stage, the online algo-rithm consist on a choice in the Prediction table. In fact, at the prediction tablefor the currente phase, the algorithm will make a conditioned choice take intoaccount the spent time into this current phase.
However, conditioned choices can be made in several ways and it will dependon the final application for the predictions data. As a simplest way of choosing,a most probable choice appear as the most logical one, however, it can make alot of bad prediction if the distribution has a second pic, after the most probavle
22
Figure 5: Prediction Algorithm Schema
one. An other exemple can be a choice guided by it’s trust value or also guidedin an fixed interval.
Based on the assumption of giving as much information as possible to aespecific choice made by the application, there is a proposition of changing thePredictionOutput to provide the prediction table insted all itens listed in section5.
However, to mesure the prediction table error it was necessary to build achoicer that respected the prediction table distribution and mesure the errorcompared to a real case. Therefore, with this choicer is possible to mesure amean error of the distribution.
Choicer following a distribution The main idea is based on taking a ran-dom number α and multiply it for the line sum of the matrix starting on thecolumn representing the duration time on this phase until the present time
v = alpha×T∑i=k
PT (ln, ti), k, n ∈ N
, where ln = traffic light n, tk = duration time on this phase until the presenttime and T = time prediction horizon.
Thereafter, this value v is used to find a prediction. From tk all occurenceson each ti are seen as weight and the prediction for this intant is the tm where
m∑i=k
PT (ln, ti) < v <
m+1∑i=k
PT (ln, ti)
.Until there is no phase changing α keeps the same value and when there is
a phase changing α will take a new random value.As said before, this choicer will predict following all destribution, it means
that the most probable value will appear more times but the second most prob-able will appear a lot of times too. Therefore, there is a kind of mean prediction.
23
7 ResultsThe idea to measure the quality of this algorithm was to measure, at the trafficlight changing instant, the error between all past preditions and the real time-changed value. There is to possible error mesurement, an absolute error and arelative one. On the relative error, an error next to the changed-time is morepunished then an error in a distant time.
On fig. 6 ti for i ∈ N represents time into a phase and for each ti there is aprediction τ(ti) related. To finish tc represents the intant where the real changeoccurs.
Figure 6: Error Schema
For an relative error, the following formula can be applied
e =1
tc − ti(
tc∑t=ti
|tc − τ(ti)|tc − t
)
,and for an absolute error
e =1
tc − ti(
tc∑t=ti
|tc − τ(ti)|)
For some final results for the algorithm see section ??.
8 ConclusionThe most part of the related literature to traffic light controller modelling werelinked to traffic light modeling to fill some specific strategy. An unniversal modelincluding all control strategies was the first challenge of this work. To reach thismodel, a very deep investigation on traffic light controller strategy had to bedonne.
After an approch on markovian model choosed, a second challenge wasproposed: How to work with markovien modeling with differents times onthe states? Some investigations on finite-state diagram and non-homogenuousmarkovian chaines were conducted, however, their application seemed to be tooelaborated and weren’t easy undertandeble. The choice on separating time andphase changing prediction allowed to arrive on an simple an robust algorithmusing Monte-Carlo method. Therefore, improvements are limited to understandthe interaction between time, phase changing and events and not on the algo-rithm.
24
This work leads space for furthers investigations on events modeling and itsintegration with the actual phase model.
25
A ImplementationLooking forward to explain an other important side of the presented work, thissection will get into implamentation issues and techinical solutions for the TrafficLight Prediction Algorithm. As said on sec. 6.1 an unniversal model was thechosen approach toward a traffic light control model, therefore, an exploratoryphase was needed to understand the control dynamics in a higher point of view.
Thereby, the conclusions that led to the chosen model, described on sec.6.3, were made thanks to learning applications that were constructed to searchlogics and corelations between the system variables. These applications wereconstructed in a open architeture that allowed an wide exploration on data and,at the same time, a future final application for the prediction algorithm. Somepratical restriction (see sec. 4.3.1) were imposed and led to some implementationchoices on the final application.
This section will be divided in 3 parts: Traffic Light Controller Simulator,Applications and Final Application. Traffic Light Controller Simulator will, ina practical/technical view, explain the simulation platform in details, i.e. theAPI and the buffer file. Applications will show the different application used tolearn and understand the traffic light comportment. Final Application sectionwill show in more details the final application described before on sec. 6.3.
A.1 Traffic Light Controller SimulatorThe provided API combined with one buffer file formed the mean tool to simu-late the traffic light control interface with the Prediction Algorithm. The bufferfile is a binary file containing several days of real data from a specific traffic con-toller. This section will explain the technical details on the API and the bufferfile. The well understanding of this part was essential to understand furthertechnical choices.
A.1.1 The API
At this section the API architecture and functionalities will be shown. A firstapproch, thus, involved an study on the API functionalities and accessibilities.A class diagram (fig. 7) was contruct for this study.
Substantially, to read the buffer file the main function on MyApp_Inria classhas to create an Application and a Prediction object and initiate the Applicationobject passing the Prediction instatiation as a parameter on function init. Atthis time an .ini file located on the root will be read and its parameters indicatesto the Application object, among others internal parameters, which buffer fileread.
The Application object, under .ini file parameters, will create several othersobjects as a Server, a Configuration, a PredictionInput, a PredictionOutputand, on this case, a DataSourceRingBuffer 26.
After run the init Application function, the next step on the main mainfunction is a while loop having a condition given by an Application functioncalled "process". This function had as goal read a new "line" on the buffer, ifthere was a line to be read it sended true and if not false, finishing the loop
26It was assumed that the DataSourceVt class was the object used to extract informationfrom another file or silulator
26
Figure 7: Class Diagram
27
while on main function. For each line read the PredictionInput was modified,simulating a reading on controller variables every time the loop while re-started.
The interface to the algorithm, thus, had to be inside this while. The func-tion "process" calls a Prediction function called "predict", where the predictionhas to be placed. It pass as function parameters a PredictionInput and a Pre-dictionOutput object, that had to be changed for each new PredictionInput.
As Prediction_Inria herits from Prediction, the prediction algorithm wasdevelloped inside the predict method on Prediction_Inria class.
A.1.2 Algorithm Input Data
A buffer file was a binary file containing several days of traffic light controllerdata. In avarage, buffer files had 20 days of data and 5 different programs.
Through the API, this buffer file could be read and some data in an specificformat was given on PredictionInput class. This section will explain in detailsthe control variables that could be accessed.
timestamp A long variable that represents a time counter in milli-seconds.On the thrid API version there was a strage comportment that jumped thetimestamps on some seconds when an API internal warning comes out. Animplementation choice was to do not treat this inconsistence.
currentSiganlProgram An int variable that represents a program’s id. Itstarted on zero for some time and changed for natural numbers indicating pro-grams’s id. There were between 4 and 7 programs on the 10 buffers files anal-ysed.
nextSiganlProgram An int variable that represents next signal program’sid. Some controllers are not able to give this information. None vertion of theAPI incorporate this information and gived always zero as value.
cycleTime An int vector variable27 that represents all cycle’s duration in 10thof a second. For each program there was a cycleTime, thus the vector lengthwas the number of the program on the controler. The vector started with zeroand it took some time, on the begining of the buffer file, to fill all columns 2829.
programCounter An int variable that represents current program’s timecounter in in 10th of a second. It starts at 0 and goes until de cycleTimevalue and restarts. In some specific parts of the program the programCounterstoped30 and it had to be treated to not count as a different cycle.
27In the first API vertion just the actual cycle was passed.28There was one buffer file that had always a empty column and it has be treated to run
correctely29When a cycleTime column stabilized it was necessary to link a program number to this
column. On that way, there was a map linking program’s numbers and its cycleTime column.30It was identified just a program transition function to this behavior but it require further
investigations
28
currentPhase An int variable that represents the current phase. Some con-trollers are not able to give this information because there are controllers thatare not programmed using phases31.
nextPhase An int variable that represents the next phase32.
phaseCounter An int variable that represents the time in current phase in10th of a second33.
modification An int vector variable that represents variables meaning valuesof all signal program modifications. These flags can be used (to set/get) bythe traffic engineer to influence the signal program behavior. There are 19modifications. The first three (VA, OEV, IV) are provided by the traffic control.The other 16 can be customized by the traffic engineer.34
detectorState An int vector variable that represents variables meaning stateof all detectors. The values were essencialy binary (zero, one), however it mean-ing weren’t well identifiable as it’s wasn’t known if what counted was the timeon a one value or the numbers of pics35.
sgState An int vector variable that represents variables meaning state of allsignal groups accordint to 4.2.1 classification status. In a first API vertion,this variable was an boolean vector representing released and closed. The lastverstion had 4 possible states (Released, Closed, Transition and Unknown).
outputState An int vector variable that represents variables meaning stateof all outputs. This is the state of actuators controlled by the traffic controllerthrough the active signal program. For example pedestrian signal requests canbe confirmed to the requester by that mechanism.36
A.2 ApplicationsAs said on sec. A, for this work it was necessary to build an opened softwarearchiteture allowing easy exploration and code modification. The basic archi-tecture designed to suport those requirements is represented on fig. 8.
The control class is the a central class that manage the other class. Thereis 4 main activities to be controled: Libray, where all kind of classification(phase, cylce and program) and counting is made; Calculus, where the threemain tables are built (Transition table, timeInPhase table and Prediction table);Prediction, where there is a choice method and; Printing, where all output filesfrom learning stage are made. In the package control there are 4 classes calledManagers that controls one pakcage each. Therefore, control class works on
31Looking foward to a unniversal model, this information has to be discarted as it was notpresent on all controllers
32As the last juficatif, this information was not used.33As the last juficatif, this information was not used.34As this information were not take into account in the model, it was not used.35For further explains see section B.136As this information were not take into account in the model, it was not used.
29
Figure 8: Basic Architecture
information changing between these 4 classes that are specialized control classfor each package.
Based on this basic architecture a toolbox of software was contruct to studyseveral aspects differently. On the end, three applications were built: Analyse-Brute, TraficLightPred and INRIATrafficLightPrediction. AnalyseBrute specif-icaly works on learn stage. TraficLightPred specificaly works on the algorithmoutput. And INRIATrafficLightPrediction is the final version with just the nec-essaries class to run the algorithm in a traffic controller.
A.2.1 AnalyseBrute
As it can be seen in fig. 9 the base architecture is used, however, as thisapplication was designed to works just on the learn stage, some specialisedpackages were introduced and other pakages, used on traitment and predictionstages, were suppresed.
In BufferAnalysis there are two classes that work especificaly to have a ovw-erview of what was study. Bufferstatics give a file as output with general staticsof the program (how many days of data, how many programs...) and gives alsothe sequence in time of programs (voir fig. 10). However, DataVisualisation isa first visualisation program that build a image file using 2 colors (green andred) to represents the signal group on a time line11.
These two output were useful to understand some comportments and theywere extremily necessary to gide the first corelarions searches.
In Lybrary package there are 2 main classes that represent different libraries:GroupManager (phase library) and CycleManager (cycle library). The thrirdclass Program is a representation of the program.
A GroupManager has, as main function, to compare the actual sgState withit GroupState library and if this sgState represented a value on the library itsent the phase ID for this sgState, if not, the phase was included on the library
30
Figure 9: Analyse Brute
Figure 10: Buffer Statistics
31
Figure 11: Data Visualisation
as a new value. The library is a simple vector of GroupState and the phase IDwas represented by the vector index.
A Cycle class is formed by a sequence of phases and, as a phase can berepresented by it’s ID on the GroupManager, it can be represented as a sequenceof phases IDs. Therefore, the CycleManager had the same principle as theGroupManager, comparing an current Cycle with its actual library.
Similarities and differeces between cycles can be searched on two diffent axes:the phase sequence or the time on each phase. To suport the two searches theCycle class was constructed with an id represented by the sequence of phases idand a vector of sub-cycles keeping time on each phase id.
A Program class, although, keeped the complete representation of the cycles(phase and time in phase) for each current cycle and put in a vector. Therefore,the program was representeng by the sequence of cycles on time.
In Printing package has 3 classes that recive all libraries from Library packageand create an stuctured file. The print process was separate of the processingpart because time processing restriction37.
On fig. 12 there is an example of a Phase lybrary (GroupState Lybrary).Each phase is represented by a lower case and a number and for each traffic lightstatus 4 different status are possible: 0 - Unknown; 1 - Closed; 2 - Released and;3 - Transition.
On fig. 13 there is an example of a cycle lybrary using the lettres definedon phase library. It show the cycle id and it’s sub-cycles with different time forthe same phase sequence. For the cycles and for each sub-cycle a number ofoccurances on the program is added.
And on fig. 14 there is an example of a program using each line as a cycle37As said on sec. 4.3.1 the predic function has to be called each second, thus, all
learn/prediction process had to be maded on this time window. A multi-file writing pro-cess could consume a considerable time
32
representing the sequence of cycles on time.
Figure 12: Phase Library
A.2.2 TraficLightPred
As it can be seen in fig. 9 the base architecture is used, however, different fronAnalyse BruteA.2.1 architecture, the learn phase just conserve a phase library38, calculus and prediction packages are implemented and there is no need fora buffer analysis.
The phase library has the same function described on sec. A.2.1.On calculus pakage there is 3 classes for different calculation means: Predic-
tionTable, StateTimeEvolution and TwoStateSwitchTable. StateTimeEvolutionand TwoStateSwitch Tables are the representation of TimeInPhase and Tran-sitions matrix (see sec.6.3.3) and as seen in fig. 5 they are produced on-line.However, the PredictionTable is calculated off-line and uses as input preciselythe StateTimeEvolution and TwoStateSwitch Tables as described on sec. 6.3.3.
Figure 15 represents TwoStateSwitchTable. Each number corresponds to atransition from a line phase to the column phase.
Figure 16 represents StateTimeEvolution. For each phase on the line, anumber of occurence corresponding to a fixed time been on this phase. Eachcolum represents the number of seconds on the phase, starting from 1 second.
38The choice of phase as center element was discussed on 6.3.1
33
Figure 13: Cycle Library
Figure 14: Program
34
Therefore, figure 17 represents the PredictionTable. There are several tableson just one file and each one is linked to a specific phase. Each table is formedby lines representing traffic lights and columns representing time on seconds(stating from 1 second). Therefore, each value on a specific table represent thenumber of times that, in a simulation, the specific traffic light, on a specificphase, took that time to change its status.
Figure 15: TwoStateSwitchTable
On the Prediction Package there is an PredictionMethod (choice method)class. This architecture allows Prediction class on control to be independ of theprediction methods, thus, different algorithms can be applying just changingthe implementation of this PredictionMethod class.
On the same Package there is a LogFile class to provide a visual outputserving to debug the algorithm. A prediction evolution on the time can beseen on fig. 18. The columns represents the traffic lights. The first line is theactual state of each traffic light. The second line represents the prediction fora state changing time to each traffic light. The tird and fourth line representsthe minimum and maximum state changing time.
The last class on the Package is ErrorPrediction where an instance of errorcalculation was built. As an output for the error a file was constructed (see fig.19).
A.2.3 INRIA TrafficLightPrediction
The last application is the final one, that just use the necessary classes, describedon the study, and provided just the necessary files. Therefore, it archtecture (seefig. 20) is formed by all classes described on the last application.
This application will be well described on the following section A.3.
35
Figure 16: StateTimeEvolution
Figure 17: PredictionTable
36
Figure 18: Prediction Log
Figure 19: Prediction Error
37
Figure 20: INRIA TrafficLightPrediction
A.3 Final ApplicationThis section has as objective to be complementary to sec. 6.3, where the finalalgorithm is explained. This section will present some results and some examplesto an Algorithm better understanding.
A.3.1 Learn Stage Output
As said on 6.3.2 two main matrix are produced on this stage: Transition anda TimeInPhase Matrix. The Transition Matrix represents a probability distri-bution for changing from a phase to another. However, TimeInPhase Matrixrepresents a probability distribution for a period of staying in a phase.
Another way to represent a transition matrix can be a finite-state machine(fig. 21). On this example, a finite-state machine is produced from the table onfig. 15 and it can be seen that there is a considerable number of deterministicpaths. The conclusion of this analysis is that the indeterminisms will comefrom time, from an higher markovien degree, from events or from a combinationbetween them.
Seeing determinismes on TimeInPhase (fig. 16) and comparing with thephase library (fig. 12) it can be realized that all transition phases 39 has a fixedtime. The others phases has different comportements on time, that could beexplain for an markovien dependency or an event arrival. As it can be seeingon the example of a line from a TimeInPhase Matrix (fig. 22) it can be noticedthat there is an important value next to the 13th second. It can be assumedthat this value is the normal comportment and the others points happen due toevents influence.
39A transition phase is a phase that has at least one traffic light in transition status
38
However, on this study the events couldn’t be implemented, thus, an impor-tante information is not take into account. If a correlation between events andthe determinisms on Transition and a TimeInPhase Matrix could be founded avery important improuvement will be seeing.
A.3.2 Traitment Stage
Using a Monte-Carlo simulation in Transition and a TimeInPhase Matrix anPrediction Matrix is produced (fig. 17). The quality of the prediction willdepend on the input matrix and on the numeber of simulations. On fig. 23a prediction distribution can be seen for a specific phase. This courv repre-sents how many time (in seconds) this specific traffic light, been on this specificphase, will change its status. There is a strong pic, representing a very regularcomportament of this traffic light on this phase.
A.3.3 Predition
After a choice algorithm on the prediction table some parameters (sec. 5) aregiven as a result of the prediction. An exemple of this output can be seen onfig. 24 (LogFile - produced on TrafficLightPred application (sec. A.2.2). As theprediction has a time horizon 40, if there is no value on prediction table, theprediction will be "more them Thorizon value" and to represent this prediction,the number 0 (zero) is used.
A.3.4 Results
Using the algorithm described on sec 6.3.4 and the differet kinds of error calcu-lation described on A.3.4 some error courvs could be contructed.
On fig. 25 a absolut error related to a specific traffic light is shown. Eachnew step represent a phase changing or a false-short prediction 41.
A courv relative to this one on a relative form can be seen on fig. 26. Morethe time is close to the changing time more the relatives erros will increase.That is the reason for relatives errors courves to have an increase courv for aconstant absolut error.
A different absolut courv is that one with a false prediction on the end (fig.28). On absolut, 8 seconds of error on the begining are nothing in a relativeform as 8 is devided per 40. A relative form of this courv can be compared tothis form (fig. 28).
40On our simulation, we used 70 seconds as time horizon41Is a prediction that said that the traffic light should be changing in one second and it
doesn’t change
39
Figure 21: Finite-State Machine for a program
40
Figure 22: TimeInPhase Matrix Line
Figure 23: Prediction Table Line
41
Figure 24: Log File
Figure 25: Absolut Error 1
42
Figure 26: Relative Error 1
Figure 27: Absolut Error 2
43
Figure 28: Relative Error 2
44
B Further Improvements
B.1 Looking forward taking into account event influenceAfter a Marvovien Model built it was possible to identify deterministic tran-sitions (see figure 21). With an hypotheses that a controller has a proceduralprogramming it’s possible, in theory, to find all determinist transitions andtimes on the model. The research, thus, focused on the events, could explainnon-deterministic time variations on a phase and/or non-determinist transi-tions on a phase change. Therefore, a good event analyzis could improve thedescribed prediction algorithm adding more deterministic time transitions andphase transitions.
The approach used to analyze events, normally, is to observe events incomeand watching the controller comportment it could be find a correlation.
On this work, simple approchs were used, but they don’t proved to be ef-fective. This section will explore some of these first hypoteses and will suggestsome possible axes to find this correlation.
B.1.1 Events Exploration
The first hypothesis were:
• an event has influence in a period of a cycle time counting from its arrival;
• there is a direct correlation between an event and a time duration on aphase;
• there is a direct correlation between an event and a phase changing
Analysing each axe independently no correlation was found. And the reasonsfor that is the need for a more complex model for the events.
The events were modeled as detector signals that could have a directly influ-ency on the changes (time or phase changing). However, as saw in [1] detectorsignals can be "treated" using diferent logics before having an influence on thepossible changes. For example, two signals detection can be used to measuretime between vehicles, a constant signal for a short time can be used to mesurevehicle time in a loop. These new variables created by a diferent mesure onsignal detection will be compared with valors choose by the traffic engineer andfrom this comparation will result a action on time or phase chaging.
To reach a event modeling diferent approches have to be used. A mixedapproche between unniversal model and reverse engineer can give some goodresults. An reverse engineer approch could be an investigation on all kinds ofdetection and variables used on traffic engineering. Another approch, continuingto use unniversal model is to work with several "base elements" and see differentreponse for an event. Choosing an event analysis on traffic lights or cycles couldgive some determinisms that can be trasposed to the first model, based onphases.
45
References[1] Guidelines for Traffic Signals, Steering Committee
Traffic Control and Traffic Safety, Edition 1992
[2] Processus Stochastiques Françoise PRÉREUX, Edition1994
[3] The Monte Carlo Method Nicholas Metropolis; S.Ulam, Journal of the American statistical association(sep.,1949)
[4] Interface Adaptation of Traffic Light Control JürgenWeingart; Matthias Nolle; Martin Zährl, Preven-tive and Active Safety Applications Integrated Project, SPDeliverable D40.61/2
46
