Multi-objective optimization for real time traffic light control and navigation systems for urban saturated networks

Abstract

A multiobjective management system for saturated traffic road networks comprising: green wave coordination of locally adaptive traffic control units, traffic movement optimization and live traffic route guidance. Current traffic congestion measurements on intersections are generated from local traffic cameras and remote air-borne conventional cameras and thermal sensing imaging cameras or satellite radar such as SAR/ISAR using optical image brightness analysis. At the first stage of traffic optimization, individual local intersection green times are computed based on current traffic congestion level. At the second stage optimization, the central traffic server uses a multiobjective approach to coordinate the current locally-optimized green times of the first stage and create input constraints for green-way coordination of plurality of traffic lights. The server updates dynamically current cycle start and green times on all network-connected traffic light controllers and also broadcasts recommended travel times, green times and green waves to all on-line client vehicle navigation units. Traffic server and individual client guidance units utilize novel time-dependent modifications of an A*-type algorithm to update current travel and recommended travel times and to execute fastest route searches.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 System Components: Network Traffic Control Configuration

FIG. 2 Local Controller and Central Server Functions

FIG. 3 Interface for Intersection Configuration

FIG. 3 b Video Image of 3D-TL Layout

FIG. 4 Flowchart of brightness B computation

FIG. 5 Graphic User Interface

FIG. 6 1^st Stage Optimization—User Input

FIG. 7 1^st and 2^nd Stage Optimization Flowchart

FIG. 8 Navigation Information Flow

FIG. 9 Navigation Travel Time Database

FIG. 10 Map Cells and Cell Distances

FIG. 11 Reference Points and Pre-calculated Distances

FIG. 12 Short Travel Time Prediction Function

FIG. 13 Short Term Prediction with a Function Fastest Route Search

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

System Components

FIG. 1 shows main system components of the proposed invention describing local and network traffic control configurations including:

Local controller functions:

• Traffic data collection (101)
• Congestion detection (102)
• Local 1^st stage optimization functions (103)Central server functions:
• Green wave coordination (104)
• 2^nd stage network optimization (105)
• Recommended Travel Time Prediction (106)
• Traffic Guidance (107)
• On-vehicle traffic guidance (108)
• Web on-line traffic guidance (109)
• Roadside traffic advisory displays (110)

Local Controller and Central Server:

FIG. 2 shows a block diagram of various components of the proposed multiobjective system and a method for controlling of at least one local traffic light (201). Traffic light (TL) at an intersection (201) is connected to traffic signal controller (202) for controlling traffic light program. Local microprocessor (203) has a logical connection to the traffic light controller and comprises video processing module (204) connected to video image collection and processing unit. This unit comprises at least one low-cost 360 panorama digital camera (204) with other optional single camera inputs (205) for more varied or detailed views, depending on topological characteristics at the intersection. Traffic cameras are used for acquiring dynamic digital image sequences of traffic data on the TL.

The image analysis with the congestion detection on specially designated approach and exit regions are performed in step (206) The microprocessor also contains a traffic light optimization unit (207) with software algorithm for optimization of current cycles, green times on each direction, recommended travel speeds etc. A local database stores current optimization data and said video image analysis. The microprocessor has an on-line two-way communication link to the central server (208) to enable real time traffic data transmission to central server and control timing data of at least one or more local TL controllers. Local server receives modified cycle lengths, green time starts and recommended speeds computed and adjusted by 2^nd stage server network optimization. The local traffic controller may also include separate radio transmitter and receiver (214) for transmitting traffic control data to and from vehicles equipped with similar two-way transmitters.

Central Server Control Functions

The central traffic control server (208) has a remote control link to at least one local traffic light comprising a system and method for central network traffic control optimization and coordination module for a two-level network traffic light optimization (209). The traffic control server module computes and adjusts green time group start-times, green-waves and recommended speeds on TLs in the network and sends out data packs to individual TL controllers (202) as required by coordinated traffic control. The traffic server is logically connected to on-line traffic navigation and client guidance system (210) which comprises means for updating client on-vehicle traffic navigation unit-databases (211) with recommended speeds, cycle durations, green waves and other live traffic data. The traffic server system also comprises communication means such as landlines or web links for updating the said navigation data to roadside traffic monitors (212) and other traffic advisory display systems (213). The control server module can also send out live travel data packs via local radio transmissions (214) to radio connected on-vehicle navigation units.

The main emphasis in the present invention is on dynamic vehicle congestion processing on all TL approach and exit directions. Ignoring the congestion loads after TL in heavy congested traffic will often result in “jam” congestion increase, adding more vehicles onto already saturated exit lanes. While other systems use vehicle loads on “stop lines” on lanes before the TLs, the present system performs traffic congestion analysis on all approaches before and after TLs for currently optimal green times.

Other standard traffic surveillance data inputs from roadside counters and statistical tables may be also included in the computations.

Traffic Data Collection

Live traffic data streaming from TL traffic cameras are stored locally on controller database. Compressed bitmap images from video and digital cameras are collected in short time sequences, i.e. one image/sec for near real time processing locally and are also stored on central server database including Geographical Information System (GIS) reference data such as local coordinates, time, etc. All cameras have average recording range of 150-200 meters and are located on central location typically above the TL intersection according to operator specifications. In the preferred embodiment the use of inexpensive digital cameras or single 360 degree panorama cameras may result in significant cost reduction in the overall system. The operator calibrates camera views for each travel direction to enable full surveillance of the entire intersection. Additional cameras may be added if necessary due to intersection topography. Monitoring of all cameras and their performance is from remote central traffic location or locally as required. All processing is in real time with direct output to each TL controller.

Traffic data collection in large urban areas is also made possible via remote airborne cameras and high resolution satellite radars such as synthetic aperture radar (SAR) and inverse synthetic aperture radar (ISAR). The system uses adaptation of the image brightness analysis to compute vehicle congestion on larger traffic areas covering 10-15 km radius simultaneously.

In this embodiment we present single TL and traffic camera configuration for local vehicle loading computations. On the larger urban scale the loading computations are done on a plurality of TLs at the same time.

FIG. 3 shows a typical 4-way TL intersection plan with GIS enabled graphic user interface inputs. It shows one centrally located panorama camera with 4 views CAM_1,2,3,4 covering all directions of the TL including approaches in all 4 directions (North, South, East, West). Each direction comprises number of road approach lanes L₁,L₂, . . . , L_n and exit ways W₁, . . . , W_j respectively. For traffic congestion computations each lane is further defined by a polygon boundary of the lane width say 3 meters and length of say 150 meters. Exit ways W_j are also defined by a polygon boundary and may contain one or more lanes per each exit, as designated by the operator.

In the system initiation stage the operator configures TL intersection using standard input interface. The operator selects appropriate geometrical layout from various intersection templates such as 2-way, 3-way, 4-way etc. and assigns allowable speeds for all road sections. The operator also assigns vehicle groups that will move during the same green time interval. Groups are designated here as Gr1, Gr2, Gr3 and Gr4 and will represent vehicle queues on individual lanes and their travel directions of the TL.

All camera views are designated by CAM ID number, camera height, azimuth and angle. Recommended heights range between 10-15 meters for unobstructed views of queues of 150-200 meter lengths.

Using TL layout interface allows the operator simple means of data entry as well as uniform system of intersection designation. The FIG. 3 also shows 3-dimensional camera view 1, 2, 3 and 4 of the TL for all direction approach and exit lanes coordinating plan and view template designations.

FIG. 3 b shows an existing TL camera view of with a 3D layout template. Lanes L1,L2,L3 and L4 designate approach lanes before TL and exit ways W1,W2,W3 and W4 after TL as defined by the operator in the TL configuration stage. Several views may be combined to provide full coverage of an existing intersection.

Traffic congestion measurement and Image Heterogeneity Analysis (Module)

This module uses image sequences from a TL video camera views to measure traffic congestion by means of image brightness heterogeneity (IBH).

The main objective of the brightness heterogeneity analysis method is to define pixel brightness variance of an image pixel strings inside the user-designated boundary polygon regions. In this analysis the regions represent approach lanes or exit ways of the intersection and are selected by the operator to asses the current traffic congestion in these areas. The amount of traffic congestion on the TL approach lane can be expressed as a degree of pixel brightness variance (heterogeneity) in the image relative to the last learning calibration period (say 15-minutes) and the minimum “learning” value obtained in that period, which the system now sets as its current “empty” or “zero” congestion level for the given region.

The color image is comprised of number of pixel-strings in the horizontal and vertical array i, j. In this patent, we define a single pixel string as a contiguous sequence of pixels in one row or one column, where the difference between the initial pixel brightness value B and each internal pixel brightness B-value does not exceed the preset tolerance level (TOL). The image brightness heterogeneity (IBH) may be defined as a sum of all pixel strings whose B-values exceeded pre-set TOL value. Experimentally we found that TOL=30 variance between two pixel strings gives the closest approximation of significant variance in the image heterogeneity for estimating traffic congestion changes.

While the color images may be also defined by their color hue H and color saturation S, besides the color brightness B, (HBS) in this invention only the pixel brightness B coefficient is used for image analysis resulting in simplified computing process.

Note: In all color images the pixel B coefficient ranges between values 0≦B≦255.

FIG. 4 shows a flowchart diagram of the method of computation of image brightness heterogeneity IBH or “B” for short, of the image.

• Step 401: Get digital image size i×j with typical resolution say 640×480 pixels where each image is represented by a matrix of pixels with 480 rows and 640 columns.
• Step 402: Get Max_i pixel rows (i.e. 480) and Max_j pixel columns (i.e. 640).
• Step 403: Set first row i=0 and first column j₀=j₁=0 where j₀ is the initial pixel of current string and j₁ is next pixel of the current string;
• Step 404: Set brightness heterogeneity tolerance value TOL.
• Step 405: Get brightness level of initial pixel in first row B_i,j0.
• Step 406: Get brightness level of next pixel in first row B_i,j1
• Step 407: Verify if the last pixel in the row has been reached where j₁=Max_j
• Step 408: Verify if absolute difference in brightness between current and initial pixel exceeds TOL value |B_i,j0−B_i,j1|>TOL.
• Step 409: If step 408 is TRUE then
  • Add 1 to total current B image brightness heterogeneity value in the row.
  • Go to step 410;
• Step 410: Set the last B as a start point and computes the next pixel B Return to step 405;
• Step 411: If the last pixel in the row on the last column has been computed, advance to the next row.
• Step 412: Verify if current pixel is in last row and last column i.e. Max_i and Max_j has been reached.
• Step 413: Advance to next column till the total B for the image has been computed.
• Step 414: Store the image final B value and ends the program.

FIG. 5 shows is an example of graphic user interface of typical intersection in traffic camera view. The B values of series of image bitmaps of the TL view are computed for a short initial calibration period T say 15 minutes. This period is a learning history parameter used by the system to establish calibration B values for the present reading. The operator can set the duration length of the learning period with average frequency of say 1 image per second. The system uses 2 polygons ABCD and DCFE pre-defined by operator in 2D plan view in FIG. 3. and fills the said polygons with single colors i.e. red and green etc. for easy boundary recognition. The operator can adjust brightness tolerance TOL threshold of say, B=30. Below this value the initial calibration designates an “empty” lane. The system finds B_max and B_min values for all images in period T and records B variance in the database. A separate template table of vehicle occupancy levels based on the B variance is used to estimate number of cars for the given polygon region ranging from minimal occupancy to the current maximum according to operator input.

The higher value of B indicates higher presence of cars. For example B value 4 may signify 1 car count, value 8 two cars etc. In this manner the operator can visually update car count template determining car multiplier value for car counts for current period T. The image parameters are re-evaluated periodically and car multiplier value re-adjusted as necessary. Factors such as time of day, weather and lighting conditions may influence car count results and the system updates the present car count template from previous rolling history values. To compute the car count in the current image for camera view CAM 1 the system first calculates current brightness coefficient value B, obtains last car multiplier factor and estimates current car count accordingly.

System Input Module

The input module routine verifies the available lists of TL intersections included in the network optimization and examines approach lanes and exit ways on each link, their main group directions and group designations. All available TL camera views and their configurations are also examined by this routine. The operator sets maximum waiting time parameter for each green light including crossing times for pedestrians as necessary, and the maximum allowable speeds for each road link.

FIG. 6 shows input steps for 1^st stage optimization using typical plan of intersection TL shown in FIG. 3. Input module routine of the above example comprises following steps:

• Step 601: Get all lanes on 4 approaches before TL:
  • Approach 1: L₁,L₂,L₃, Approach 2: L₇,L₈,L₉, Approach 3: L₁₃,L₁₄,L₁₅, and Approach 4: L₁₉,L₂₀,L₂₁.
• Step 602: Get all exit ways W₂, W₈, W₁₄, W₂₀ after TL, where each W_j defines a polygon area containing set of lanes on exits after TL, using the middle lane before TL as the dominant feeding lane of the exit way, i.e. L₂ is dominant lane of Approach 1 feeding to W₂, etc.
• Step 603: Get all traffic directions N^dir for TL as defined by operator in the preprocessing stage, where each direction Dir_ij=(L_i,W_j) comprises lane L_i before TL feeding exit way W_j after TL. In this method the system connects traffic flow of vehicle queues on lanes before TL with current vehicle queues on exit ways after TL.
• Step 604: Get list of groups of each TL, where a group Gr_n is defined as a set of all allowed directions Dir_ij on the same green light.
  • Example in FIG. 3 shows 4 groups:
  • Group Gr₁={(1,8), (2,2), (13,20), (14,14)};
  • Group Gr₂={(3,20), (15,8)};
  • Group Gr₃={(19,2), (20,20), (7,14), (8,8)};
  • Group Gr₄={(21,14), (9,2)}
  • where (L_i,W_j) is simplified to (i,j).
• Step 605: Get list of camera views 1,2,3,4 of TL where camera CAM1 shows Approach 1 lanes L₁,L₂,L₃ and the exit way W₂ and CAM2 Approach 2 lanes L₇,L₈,L₉ and the exit way W₂₀, etc.
• Step 606: Get allowable speeds on all lanes before and after TL, where allowable speeds on lanes before TL: V_i and exit way after TL: V_j
• Step 607: Get approach-lane maximum waiting time Wt_i^Max (e.g. Wt_i^Max≦3 min) according to the importance for this approach travel direction and hour of the day.
• Step 608: Get Minimum Green Time=G_i^Min for TL i^th approach
  • obtained by equation: G_i^Min=RoadWidth_i/V_PEDESTRIAN
  • where V_PEDESTRIAN is minimum pedestrian crossing speed in seconds required on this road and hour of the day and RoadWidth_i is the road width in meters.
• Step 609: Calculate maximum cycle length C^max for TL.
  • In this step the system calculates maximum cycle length for TL based on two values:
  • a) minimum of maximal waiting time Wt_i^Max on approach direction i
  • b) maximum of minimal green time value G_i^Min on direction i.

C ^Max=min_jWt_j^Max+max_jG_j^Min,j=1,2, . . . ,N^Dir

• Step 610: Calculate Index of Brightness Heterogeneity B for each TL.
  • Two images are analyzed for each direction at time t:
  • B_i^Bt is brightness of lane region L_i before TL, and B_j^At is brightness of exit way region W_j after TL,
  • maximal and minimal indices during specified time interval are as follows:

B _i ^B,Max=max_tB_i^B,t, B_j^A,Max=max_tB_j^A,t,

B _i ^B,Min=min_tB_i^B,t, B_j^A,Min=min_tB_j^A,t,i,j=1,2, . . . ,N^Dir.

• • Since the system must obtain at simultaneously both “empty” road and “road full” status, the B values for the current lighting and shade conditions of the intersection, TL, it is important to filter out any local light disturbances. For the same reason it is necessary to keep the calibration period short, say 15 minutes. We calculate brightness ranges of lane L_i before TL and of exit way:

B _i ^B,Var =B _i ^B,Max −B _i ^B,Min

B _j ^A,Var =B _j ^A,Max −B _j ^A,Min

• Step 611: Calculate current brightness heterogeneity indices B_i^B,Cur, B_j^A,Cur of TL.
• Step 612: Calculate current traffic conductivity D_i^B before TL and D_j^A after TL.

D _i ^B=1−(B_i^B,Cur−B_i^B,Min)/B_i^B,Var

D _i ^A=1−(B_j^A,Cur−B_j^A,Min)/B_j^A,Var

• • Traffic loading expresses number of vehicles on approach lanes of TL in terms of image polygon brightness.
• Step 613: Calculate Current Travel Times T for Dir_ij before and after TL;
  • In this step we compute current travel times for the TL in order to maintain and update the Travel Guidance Server Database which provides route guidance to all real time users. Travel time for individual lanes and exit ways after TL can be computed as follows:

$T_i^B=\frac{S_i^B}{V_i^BD_i^B},T_j^A=\frac{S_j^A}{V_j^AD_j^A}$

• • where S_i^B,S_j^A are distances from TL to previous TL and next TL.
  • V_i^B and V_j^A is current vehicle speed before and after TL:
  • V_i^B=V_i^B,allowD_i^B and V_i^Real,A=V_i^A,allowD_i^A before and after TL.
  • V_i^B,allow, V_i^A,allow are allowable speeds on lanes.
• Step 614: Calculate current number of vehicles on TL travel direction Dir_ij comprising number of vehicles before and after TL for direction Dir_ij:

$C_i^B=\frac{S_i^B}{\left(V_i^BD_i^B/S_d\right)·L_{\mathrm{car}}+L_{\mathrm{car}}}$ $C_j^A=\frac{S_j^A}{\left(V_j^AD_j^A/S_d\right)·L_{\mathrm{car}}+L_{\mathrm{car}}}$

• • where L_car is average length of car and S_d is recommended safe-following distance at speed V.
  • In addition the system can compute number of vehicles currently on each TL used for various historical and current traffic studies.1^st Stage Optimization Module
• Step 701: in FIG. 7 performs green phasing and timing optimization. Our goal is to maximize number of cars that will clear TL in all allowed directions during current cycle, i.e. to maximize
  • Objective function ΣG_jK_j
  • where K_j is number of cars that will clear TL for direction Dir_ij per second,
  • and G_j is unknown green time for direction Dir_ij Subject to:
  • Min green constraints

G _j ≧G min, j=1, . . . ,12

• • and Max green constraints

G _j ≦G _j ^max =T _j ^Wait +T _j ^Go.

• • Here T_j^Wait=C_j^BΔt and

$T_j^{\mathrm{Go}}=\frac{Q_j}{V_j^{\mathrm{Real},A}/2}=\frac{2Q_j}{V_j^{\mathrm{Real},A}}$

• •  where C_j^B=Q_j^B/(L_carc) is number of vehicles in queue Q_j^B,

$C_i^B=\frac{S_i^B}{\left(V_i^BD_i^B/S_d\right)·L_{\mathrm{car}}+L_{\mathrm{car}}}$ $C_j^A=\frac{S_j^A}{\left(V_j^AD_j^A/S_d\right)·L_{\mathrm{car}}+L_{\mathrm{car}}}$

• • Δt is a delay interval between two adjacent cars starting to move one after another after green light signal has been activated,
  • Q_j is queue length on direction Dir_ij before TL,
  • T_j^Wait=Q_j^B/(L_carc)Δt is a waiting time of all queued vehicles for each delay Δt,
  • T_j^go=G_j−T^Wait is time interval for last car in the queue Q_j^B to clear TL during green light.
  • Groups constraints are
  • G_j=G_k, if directions j,k belong to same group Gr_n.
  • For example: Let directions (1,8), (2,2), (13,20), (14,14) all belong to group Gr₁, so that they share the same green light which designated by
  • G₁=G₂=G₁₃=G₁₄
  • Cycle constraints are

$\sum _j^{}G_j/k_j=C^{\mathrm{cur}}$

• •  where k_j=number of directions in a group that includes direction j.
• Step 702: Get cycle and groups constraints:
• Step 703: Calculate current cycle C^Cur length:

C ^Cur =C ^Max ·B _Cur /B _TL

• • where B_TL=max_j(B_j^Max)N^Dir and

$B_{\mathrm{Cur}}=\sum _{j=1}^{N^{\mathrm{Dir}}}B_j^{\mathrm{Cur}}$

• • B_j^Max means B_i^B,Max or B_j^A,Max
  • B_Cur means B_i^B,Cur or B_j^A,Cur
• Step 704: Calculate queue lengths for direction Dir_ij:

Q _i ^L =C _i ^B L _car c and Q_j^L=C_j^AL_carc

•  where c is recommended safe-following distance at speed V i.e. it is a gap factor by which the car length L_car is multiplied in a queue that is before TL red light
  • C_i^B, C_j^A are number of vehicles in queues before and after TL
  • L_car is average length of vehicle
• Step 705: Calculate number of cars K_j that will clear TL for direction Dir_ij per second

$\begin{array}{cc}{K}_j=\frac{V_j^{\mathrm{Real},A}}{2L_{\mathrm{car}}c+V_j^{\mathrm{Real},A}\Delta t}& a)\end{array}$

• • Δt is starting-time delay between adjacent vehicles
  • V_j^Real,A is real speed after TL measured in m/sec
• Step 706: Calculate max green light per direction Dir_ij, for example if:

C _J ^B=20,L_car=3,c=1.5,V=10 m/s,Δt=0.5 sec

G _j≦20*(3*1.5*2/10+0.5)=20*1.4=28 sec then:

• • G_j is a time needed for passing 20 vehicles that were stopped before TL2nd Stage Optimization and TL Coordination Module

The purpose of 2nd stage optimization is to compute optimal green wave network coordination of start times of sequential green lights of groups of oversaturated TL intersections subject to green wave and recommended speed constraints. Current optimal green light times and cycles from linear optimization in 1^st stage are used as input constraints in the next stage coordination. The multiobjective paradigm is defined as simultaneous optimization of several, often conflicting, design objectives such as adjustments of allocation of green times control variables computed for TL_i in 1^st optimization stage.

• Step 707:

Maximize the objective function

$\sum _{i=1}^{N^{\mathrm{TL}}}\sum _{j=1}^{N^{\mathrm{Dir}}}C_{i,j}^BV_{i,j}^{\mathrm{next}}$

where C_i,j^B is number of vehicles on direction Dir_j before TL_i from 1^st stage optimization

The control variables in this problem include V_i,j^next and additional variables that do not enter explicitly into the objective function (have zero coefficients).

V_i,j^next is recommended speed on direction Dir_j after TL_i.

The additional control variables are as follows:

t_i,j is start time of next group of green light for Dir_j at TL_i;t_i,j^next is start time of current group of green light TL_next after TL_i in direction that continues Dir_j;t_i,jNext^next is start time of next group of TL_next after TL_i;χ_i,j is binary: 0 means current cycle, 1—next one;G_i,j are control variables for green times approximately computed for TL_i in 1^st optimization stage. They could receive corrected values at the 2^nd stage of optimization;δ_i,j are nonnegative control variables that relate two stages of the optimization.

The objective function above is maximized subject to the following constraints:

• Step 708: Get Green wave constraints for saturated direction zones:

t _i,j +d _i,j /V _i,j ^next >t _i,j ^next+Cycle_iχ_i,j;

t _i,j +d _i,j /V _i,j ^next >t _i,jNext ^next+Cycle_iχ_i,j;

• • d_i,j are distances from TL_i to next TL_next in Dir_j from traffic database.
  • Cycle_i are current cycles of TL_i computed at the 1^st stage.
• Step 709: Get boundary constraints for relation between start times and green times obtained from 1^st stage:

G _i,j+δ_i,j>t_i,jNext−t_i,j>G_i,j−δ_i,j,

min{G_i,j−G_min,ν·G_min}≧δ_i,j≧0

• • here δ_i,j are tolerance values for updated 2^nd stage optimal green times
  • νε(0,1) is an input parameter that defines boundaries for green times according to their optimal values computed at 1^st stage of optimization as defined by operator.
• Step 710: Get multiobjective constraint that use each TL optimal objective values for 2^nd stage optimization:

$\sum _{j=1}^{N_i^{\mathrm{Dir}}}G_{i,j}\frac{V_{i,j}^{\mathrm{Real},A}}{2L_{\mathrm{car}}c+V_{i,j}^{\mathrm{Real},A}\Delta t}\ge q_i$ $i=1,2,\dots ,N^{\mathrm{TL}}.$

•  where q_i is optimal objective value computed in 1^st optimization stage for TL_i;
  • Objective function is

$q_i=\sum _{j=1}^{N_i^{\mathrm{dir}}}G_j^iK_j^i$

• •  where Gⁱ_j optimal green time computed in 1^st stage optimization for direction j and TL_i,
  • Kⁱ_j is number of cars that will clear TL_i for direction Dir_ij per second.
• Step 711: Get Constant cycle constraints (for saturated directions only):

t _i,jLast +G _i,jLast −t _i,jInit =C ^Cur,

•  where saturated links are defined by inequality:

V_i,j^Real≦V_i,j^Allowable

•  computed in 1^st optimization stage for TL_i.
• Step 712: Get recommended speed constraints:

V_i,j^next,Real>V_i,j^next>0

• Step 713: Compute the following output variables:
  • V_i,j^next is recommended speed on direction Dir_j after TL_i
  • t_i,j is start time of next group of green light for Dir_j on TL_i;
  • t_i,j^next is start time of current group of green light TL_next after TL_i in direction that continues Dir_j;
  • t_i,jNext^next is start time of next group of TL_next after TL_i;
• Step 714: Send optimal output variables to all TL's and client units.
• Step 715: Return to 1st Stage Optimization Module.

This model is not linear due to V_i,j^next, d_i,j/V_i,j^next; however, if in the objective function we replace V_i,j^next by 1/V_i,j^next and maximize the objective function instead of minimizing it, the model becomes linear although it includes binary control variables.

Note: the above mathematical problem is mixed linear and can be solved by standard optimization tools such as LINDO or SOLVER of MS Excel.

Individual intersections in oversaturated networks almost invariably create additional traffic loads and vehicle congestion in certain directions. By definition, the optimizations of individual green lights works best with local control systems and these often fail to distribute vehicle loads towards more accessible TLs. As a result, some directions become more saturated, creating additional congestion loads on next traffic lights. In order to avoid accumulation of vehicle loads in specific traffic zones the system uses 2^nd stage optimization of traffic lights. In this stage it is essential to synchronize green times of a plurality of TL intersections in optimized sequences resulting in green wave preference to less congested directions. The proposed green wave function uses recommended speeds to drivers as means to increase or decrease traveling speeds in certain directions resulting in more green time in these directions while taking into consideration traffic demands on these directions.

In contrast to prior art, the green wave function in this embodiment is highly adaptive and not fixed in specific or preferred direction.

The proposed green wave coordination system will also result in redirecting traffic to less saturated directions as required. This process includes on-line driver-navigation systems and the fastest routes computations. Live traffic information network server updates driver's on-board vehicle navigation units and net-provided traffic guidance systems with recommended speeds on all local links and updates all green light changes in the path of travel.

Dynamic Vehicle Navigation

We consider the problem of constructing a method for finding the fastest route for a vehicle to travel between two points on a map. A map may represent a city, a group of cities, a whole county, etc. The route means a chain of road links usually between road intersections. A road link contains a directed road segment and a turn-off or a go-through segment. The fastest route implies taking into account changing traffic conditions that might include traffic lights, slowdowns, traffic jams, road closures, atmospheric conditions, etc. If we also have additional information, say, traffic light timing, that could be used in finding the fastest route.

Traditionally, optimal route search has been performed by an A* algorithm or its modification. In the present invention, we are using a route guidance method that uses novel time-dependent modifications of an A*-type algorithm in conjunction with a Navigation Travel Time Database. This Travel Time Database includes statistical travel time data, current travel time data, and predicted travel times. Our modifications of an A*-type algorithm also rely on various additional preprocessed data stored in databases, in particular graphs of the region partitioned into subgraphs or cells, intercell distances, intracell distances, lists of reference points, precalculated routes from reference points to selected points on the map and vice versa, etc. Input and output data for this problem are as follows.

Input: Static Data: Region map, coordinate info, distance info, turns info, lane info, additional data.

Dynamic Data: Limit speed info, Lane closure info, Table of statistical travel times, Table of current travel times for road links in the vicinity of the current vehicle position and Tables of travel times produced by various prediction methods.

Output: Optimal route on the map and a corresponding sequence of instructions to the driver.

FIG. 8: Navigation Information Flow is a flowchart representation of major information structures making up the traffic navigation system, showing (801) the GIS Database used as a basis, (802) Database Transformation into the Hierarchical Cell-Structured Database required in traffic navigation, (803) Hierarchical Cell-Structured Database, (804) Space-Time Database containing both topographical and time-related information, (805) real time Data Collection System providing contemporaneous traffic-related information, (806) Data Processing System that provides the information for the Travel Time Database (807), (808) Route Request originating from a driver, (809) Route Search performed by the Navigation System according to the Route Request, and (810) the Optimal Route found by the Navigation System to be sent to the driver.

The control part of the problem may be divided into 5 parts or 5 algorithms. The algorithms 3 and 4 deal directly with fastest route search and are described in detail below. The algorithms 1, 2 and 5 relate to data conversion problems known in the literature and there is no need to expand and explain them in detail. They are however necessary for constructing a data framework for searches route.

• 1. Algorithm for converting the Static Data: a given map turns data and lane data into an auxiliary graph G (units 801 to 803 in FIG. 8).
  • Input: region map, turn info, lane info, additional data.
  • Output: auxiliary graph G: nodes and edges including edge lengths (stored as tables in a database).
• 2. Algorithm for converting the Dynamic Data: Limit speed info, Lane closure info, Table of statistical travel times, Table of current travel times, etc. into space-time (dynamic) graph TG (units 805 to 807 and 804 in FIG. 8).
  • Input: Dynamic Data.
  • Output: Space-time (dynamic) graph TG (containing auxiliary graph G with associated travel time data stored as tables in a DB).
• 3. Time-Dependent Algorithm TA* containing a time-dependent evaluation function ƒ (unit 809 in FIG. 8, described below).
  • Input: Space-time graph TG, Start node s, destination node d, evaluation function h, current time T.
  • Output: Optimal path from s to d on the space-time graph TG.
• 4. Time-dependent evaluation function ƒ (unit 809 in FIG. 8, described below)
  • Input: Space-time graph TG, Table of statistical travel times: (edge, current time)→travel time, Table of current travel times: (edge, current time)→travel time
  • Output: Estimated travel time from the current node i to the destination node d: h_i(t_i).
• 5. Algorithm for converting an optimal path from s to d on the space-time graph TG into an optimal route on the map or a sequence of instructions to the driver (units 809 to 810 in FIG. 8).
  • Input: Optimal path from s to d on the space-time graph TG.
  • Output: Shortest route on the map and a sequence of instructions to the driver.

Graph Definitions and Notation

We assume that a dynamic transportation network can be represented by a space-time graph TG which is a directed graph having a set of nodes (road intersections and endpoints) N and a set of edges (arcs) A. N={(n_i,loc_i),i=1, . . . ,m} where n_i is a node, and loc_i is its location. A={(link_ij,l_ij,T_ij),i,j=1, . . . ,m} Where link_ij is a link connecting nodes n_i and n_j, l_ij is the length (travel distance) of link_ij, T_ij is the time structure that provides a travel time along link_ij as a function of leaving time t_i at node n_i. We will often denote nodes simply by i, j, s, etc.

For each node i, we have the set of successors S(i)={j:∀jεS(i),link(i,j)εA} and the set of predecessors P(i)={j:∀jεP(i),link(j,i)εA}. For specifying a fastest route problem, we have to have a start nodes, a destination node d, and a leaving time t_s at start nodes.

Navigation Travel Time Database

FIG. 9 shows three parts of the Navigation Travel Time Database: one permanent part and two temporary parts. The first permanent part stores statistical travel times for all road links as functions of day type and time of the day. A day type set is a list of types such that each day of the week belongs to exactly one type. For any two days of the same type, each road link exhibits a common travel time pattern, i.e. for any two days of the same type any road link has the same travel time at the same time of the day. Examples of a day types are: Workday, Holiday, Preholiday, and Postholiday. The second temporary part shows current travel times as they exist at any given time moment. The current travel times are in general vehicle dependent (i.e. they may be different for different vehicles) and they are prone to change at any moment. The third temporary part shows rolling predicted travel times, or short time predicted travel times. Combination or superposition of all those travel times serves as a basis for optimal travel route searches for requesting drivers.

After receiving each route request, the system checks availability and relevance (timeliness) of the second part: those elements of it that are recent and relevant are used for modifying the first part and for producing the third part which will be used in actual computations. To summarize all the sources available for getting estimates of actual travel times for all or some road links we will use a generic functional notation d_ij(t_i)=arrival_time(link_ij,t_i) where link_ij is a link of interest, t_i is the time of leaving node i, and d_ij is the earliest arrival time to node j when leaving node n_i at time t_i and traveling along a link link_ij.

Let g_i(t_s) be an estimate of earliest arrival time to node i when leaving the start node s at time t_s, and h_i=h_i(g_i) an estimate of the earliest arrival time to the destination node d when leaving the node i at time g_i. Also let f_i=h_i(g_i(t_s)) be an estimate of the earliest arrival time to the destination node d when leaving the start node s at time t_s, then going to node i, leaving the node i at time g_i(t_s) and from there going to node d.

Let OPEN be the set of nodes opened by an A*-type algorithm at any given moment, and CLOSED is the set of nodes closed at any given moment. Note that g_i=g_i(t_s), and f_i=h_i(g_i(t_s)) have already been computed for all nodes on OPEN and CLOSED. Each node i is a structure (t_s,g_i,f_i,BP_i) where g_i=g_i(t_s) and f_i=h_i(g_i(t_s)) are as defined above, and BP_i is a pointer from node i back to a predecessor of i. The lists (priority queues) OPEN and CLOSED are ordered increasing in f_i.

A solution for a problem is a chain of nodes (n_i,t_i,FP_i) for i=1, . . . ,q where n_i=s, n_q=d, and FP_i−1=n_i for i≧2, a list of travel times: g₁(t_s)=g_s(t_s)=t_s, g₂(t_s), . . . , g_q(t_s)=g_d(t_s), and the total travel time is g_d(t_s).

Algorithm

Input: Graph TG, Start node s, Destination node d, Arrival time function g, Estimation function h.

Output: Solution chain {n_i} with n_i=s and n_q=d, List of travel times.

Start of Algorithm

while OPEN ≠ Ø , do:
select i ∈ OPEN that minimizes fj // first node on queue OPEN
if i == d // solution found
extract_solution(i)
goto L // Problem solved
end (if i == d )
delete i from OPEN
put i on CLOSED
Expand(i)
end (while OPEN ≠ Ø )
if OPEN == Ø send warning ‘No solution found’
L: End
Function extract_solution(i)
Beginning from node d , reverse node back pointers to obtain forward
pointers for a solution chain {ni} with n1 = s and nq = d .
Construct list of travel times:
g1(ts) = gs(ts) = ts,g2(ts), gq(ts) = gd(ts). The total travel time is gd(ts).
Function Expand(i)
Generate list S(i)
for all j ∈ S(i), do:
Compute gc = dij(gi)
Compute fc = hj(gc) = hj(dij(gi))
If fc < fj, do:
gj = gc
fj = fc
set pointer back from j to i
if j ∈ OPEN
goto L1
elseif j ∈ CLOSED
delete j from CLOSED
end (if j ∈ OPEN )
put j on OPEN
end (If fc < fj )
L1:
end (for all j ∈ S(i) )

Estimating Functions

Let t_a denote an earliest arrival time to the destination node d leaving i at time g_i. To keep Algorithm TA* admissible, function h has to be a lower bound estimate of that earliest arrival time t_a. If Δt_a is the shortest time interval needed to arrive from node i to destination d leaving i at time g₁, then t_a=g_i+Δt_a. Provided we have a lower bound estimator on Δt_a, say, Δ{hacek over (t)}_a, we can use as h_i the quantity h_i=g_i+Δ{hacek over (t)}_a.

Estimators for Δt_a

Let r be the length of a possible travel route from node i to destination node d, and v a corresponding (hypothetical) travel speed. Denoting a lower bound estimator of r by {hacek over (r)}, and an upper bound estimator of v by {circumflex over (v)}, we can write a lower bound estimator Δ{hacek over (t)}_a as Δ{hacek over (t)}_a={hacek over (r)}/{circumflex over (v)}. To proceed, we need a means to obtain a pair of estimators {hacek over (r)} and {circumflex over (v)}.

Estimators for Travel Route r

• • 1. A naive estimator {hacek over (r)} is an Euclidean distance between node i and destination d.
  • 2. A better estimator {hacek over (r)} could be obtained based on some preprocessing performed on the TG graph.

For our purposes, preprocessing consists in precomputing various quantities related to TG graph and storing them in a database in such a way that they could be retrieved by standard queries at any moment.

Partitioned Graphs

A graph can be partitioned into a set of subgraphs also called cells or fragments. Cells are usually made of highly connected regions of the road network. Each node of the graph belongs to exactly one cell. Cell is a subgraph such that an edge connecting two nodes is in a cell if a link connecting the two nodes is in the original graph. A node is a boundary node if it belongs to more than one cell. All other nodes are internal nodes. A cell boundary is the set of all boundary nodes of the cell. The edges that connect nodes in different cells are called boundary edges.

Assume that the following quantities have been pre-computed and stored (FIG. 10):

• • 1. Minimum travel path distance from any node to the boundary of that node's cell, where minimum distance to the boundary means minimum distance among distances to all boundary nodes.
  • 2. Minimum travel path distance between boundaries of any two cells.

If two nodes n₁ and n₂ are in different cells C₁ and C₂, then a lower estimate of travel route between them may be calculated as L₁₂=S₁+S₁₂+S₂ where S₁ is the minimum travel path distance from n₁ to the boundary of C₁, S₁₂ is the minimum travel path distance between boundaries of the cells C₁ and C₂, S₂ is the minimum travel path distance from n₂ to the boundary of C₂. If the nodes n₁ and n₂ are in a common cell, then either a precalculated distance may be used if it has been stored, or an Euclidean distance as indicated above.

Estimators for Travel Speed v

• • 1. A naive upper bound estimator {circumflex over (v)} is a maximum speed in the whole database.
  • 2. A better estimator {circumflex over (v)} could be obtained by narrowing the range of potential speeds over which maximum is taken.

By speed we mean average speed at a given link; it may not correspond to an actual vehicle speed but is useful in computations. Not that under the selected setup, the database stores travel times rather than average speeds. For finding a maximum speed in the whole database, all travel distances are divided by their stores travel times.

Maximum speed estimators may be obtained as follows.

2A. Calculate maximum speed over a DB subset defined by a predicate like Day Type, or city speed limit.

2B. Calculate maximum speed over a DB subset defined by a time window [t_i,t_i+Δt] where t_i is the current time and Δt has to be determined. The period Δt should be such that (t_i+Δt) is a guaranteed arrival time to the destination d. In other words, we have to find an upper bound Δ{circumflex over (t)} on Δt.

One way of obtaining an upper bound Δ{circumflex over (t)} is as follows. Suppose, we know a travel route from the node i to the destination d. Then departing from the node i at time t_i, we can easily compute the arrival time t* to destination d by traveling along that route, and take (t*−t_i) as an upper bound Δ{circumflex over (t)}. To be able to use a travel route from the node i to the destination d, we need some precalculated quantities.

Assume that the following quantities have been precalculated and stored (FIG. 11):

• • 1. A set of geographical points (nodes) on the map.
  • 2. Shortest travel routes from any node to all selected points, and shortest travel routes from all selected points to all nodes.

Let M={m₁, . . . ,m_K} be those points. Now we can obtain a travel route from the start s to the destination d by taking a shortest travel route among the K stored routes from the start s to m_i and then from m_i to d.

Computation of Estimator h

• • 1. Compute {hacek over (r)}.
  • 2. Obtain a route from i to d. When departing i at time t_i the corresponding travel time will be used as Δ{circumflex over (t)}.
  • 3. Compute maximum speed {circumflex over (v)} in DB over the travel time window [t_i,t_i+Δ{circumflex over (t)}].
  • 4. Compute travel time estimate Δ{hacek over (t)}_a={hacek over (r)}/{circumflex over (v)}.
  • 5. Compute h_i=t_i+Δ{hacek over (t)}_a.

Computation of Function h(i,t_i)

Input: Distances between all nodes and boundaries of their cells, shortest travel routes from any node to all selected points, and shortest travel routes from all selected points to all nodes.

Output: Value of h(i,t_i)

Start of Function
Compute
if (nodes i and d are in a common cell)
set r = dist(i,d)
else
S1 = dist(i,boundary(Ci))
S12 = dist(boundary(Ci),boundary(Cd))
S2 = dist(d,boundary(Cd))
r = S1 + S12 + S2
end (if (nodes ...))
Compute Δ
for k = 1,...,K calculate dk = dist(i,mk) + dist(mk,d)
set l(D) = mink(dk) where D is the shortest route, and l is its length.
For route D , compute an arrival time ta to d starting at i at time ti .
Compute Δ  = ta − ti .
Compute maximum speed   in BD over the travel time window
[ti,ti + Δ ] .
= max ν over the time window [ti,ti + Δ ] .
Compute Δa: Δa =  /  .
Compute h(i,ti) = ti + Δa .
End of Function

Navigation Summary and Conclusions

As noted in prior art, the problem of providing optimal routes to drivers in real time using concurrent road network conditions is a difficult problem. It involves among other things processing and combining data from various sources, managing huge databases, maintaining and updating dynamic models of saturated networks, making short time predictions of traffic times, and optimal paths calculations in large graphs. Dynamic traffic navigation system in the present invention provides fastest routes by applying novel dynamic time-dependent versions of shortest path searching techniques for the system database. These include statistical travel time tables, current travel times and short time predicted travel times. To make searches fast and effective, the present invention relies on preprocessed information prepared and stored routinely in central network databases, and in particular, graphs of the regions partitioned into subgraphs or cells (mathematical presentation of regional road networks), intercell distances, intracell distances, lists of reference points, and precalculated routes from reference points to selected points on the map and vice versa.

Short Travel Time Prediction Module

Main objective of short travel time prediction module is to provide live and predictive traffic guidance for short to intermediate trip durations in congested traffic. It is designed to provide optimal departure time, total travel length and duration times in preplanning stages and on route optimal guidance to plurality of drivers and their navigation units throughout their entire trip.

In the preferred embodiment the on-line navigation server sends dynamic traffic data packets to large number of vehicle navigation units simultaneously via multiple broadcasts. Clients obtain dynamic recommended travel time tables and green times in their vehicle units for live fastest route searches and live traffic guidance.

Accurate predictions of travel times in saturated networks are in most cases very complex, involving many random traffic events. In practice, statistic or historic travel time tables are often inadequate in predicting dynamic nature of traffic loads and their influence on travel times in the network. Time-dependent predictions for specific destinations must therefore include estimation models that will take into account the changing conditions and adjust current, predicted and historical travel times accordingly. The main purpose of short to intermediate travel time predictive model is to develop a bridge between current traffic data from the traffic control server and historical statistical data used in on vehicle navigation units.

FIG. 12 shows predictive model diagram for short to intermediate travel time computations. Real time travel data from central traffic control server are accurate in the immediate radius of say 5 to 10 minutes of travel time. The system creates current travel time tables for all links for the initial 10 minute travel boundary, designated as Zone 1. The current travel time tables are updated every 2-5 minutes from traffic control center. Short term and intermediate estimated travel time predicted tables are created for all links, for 10-60 minute perimeter range designated as Zone 2. Historical or statistical travel times will be used for all travel links beyond 60 minute perimeter. In the FIG. 12 example the current vehicle traveling from Origin O′ is presently located in Zone 1 at point s (x, y, z) on-route to destination D′. Driver route request is for an intermediate trip of say, 80-100 minutes, where the fastest route algorithm uses all three levels of travel tables based on origin and destination: current travel time tables, short term predicted time tables and historical or statistical time tables to obtain the estimated fastest route dynamically.

Short Term Prediction Function with Fastest Route Search

This function creates a dynamic rolling saturation register log for each TL link based on statistical time of day. Short term prediction tables have a limit of 60 minutes rolling horizon with a continuous updates every 5 minutes. The logs are stored on the central database and can be used also in updating the statistical daily data.

FIG. 13 shows short term prediction function flowchart in central traffic navigation center.

• Step 1301: Get current travel times TT_i,j^Cur for each link from current travel time tables.
• Step 1302: Get statistical travel times TT_i,j^St from time-dependent statistical table obtained for the same current period and future 60 minutes rolling horizon with step increments of 5 minutes.
• Step 1303: Get current congestion delay index:
  • DL_i,j=TT_i,j^Cur/TT_i,j^St for each TL link. This ratio expresses current degree of congestion for each TL travel link relating to statistical data for the same period. The current delay ratio is used in estimated predicted delay within the 60 minute horizon in the next step. The 60 minute horizon limit can be adjusted by operator depending on current traffic congestion.
• Step 1304: Get estimated travel time table for link TT_i,j^Est based on current and predicted delay index DL_i,j on that link. The system obtains current travel time on each TL intersection based on current time of day and using exponential extrapolation formula:

TT _ij ^Est=min(TT_ij^StDL_ij^(DLij/ΔT),TT_ij^Cur)

•  where ΔT is a typical 5 minute time interval of 15, 20, 25, . . . 60 minutes. i.e. if TT_i,j^Cur=10:00:00 then ΔT=10:15:00, 10:20:00, 10:25:00 etc. It should be noted that in the present estimating function the current c delay DL_i,j influence is significantly reduced as the ΔT interval increases. Estimated travel time tables are updated and stored on temporary system database for each link. These tables together with current travel times will form a major part of dynamic traffic packs that are dynamically broadcasted to individual vehicle navigation units.

Next steps show the method in central server of simultaneous broadcasting current and estimated travel time tables to plurality of vehicle units on-line. In order to save storage space, the server coordinates the table updates according to x,y,z location of requesting vehicle. In FIG. 12 the navigation server first processes start node s of vehicle located in Zone 1 and destination nodes d located in Zone 2 according to the features of the present embodiment. The first circle designates all links inside Zone 1 and its boundary B using current recommended travel times TT_i,j^Cur. In the second concentric circle i.e. in the Zone 2 the system uses estimated times TT_i,j^Ext on all links.

• Step 1305: Get client GPS location if available and current start nodes and destination node d, request ID, time of request of proposed trip etc. and stores data in the navigation DB.
• Step 1306: Generate 10 minute travel time radius from current travel time data TT_i,j^Cur from GIS map and coordinates of client's start nodes and updates all current travel times on the vehicle DB^Cur in Zone 1. The current 10 min. radius boundary is updated at each subsequent route requests creating dynamic boundary rolling effect along the travel path.
• Step 1307: Generate 60 minute travel time radius from the estimated travel times TT_i,j^Ext and updates the on-vehicle unit databases with the estimated travel times TT_i,j^est in Zone 2 similar to current time updates method. In the present embodiment the central server updates all client navigation units in one to many broadcasts so that current and estimated travel tables can be grouped in packs according to vehicle GPS locations or current position requests.
• Step 1308: Perform fastest route search in the on vehicle unit after it receives the live traffic update packs. The unit processor combines all three tables and creates a temporary combined database DB^Comb which is updated dynamically at, say, 5 min. interval.
• Step 1309: Compute the fastest route search using DB^Comb time-dependent function above.
• Step 1310: Check for fastest path based on DB^Comb for OD requested by client and computes the fastest recommended path TP^Combined and compares the computed time with that of TP^Stats travel time. If the total difference of two travel path values does not exceed a preset threshold value say, 20%
• Step 1311: Display TP^Stats travel time path in fastest route computations on the on-board navigation unit.
• Step 1312: Compute fastest travel path TP^Comb based on the combined database comprising current, combined and statistical data as described above on client display in the vehicle navigation unit.

The vehicle navigation units dynamically recalculate current travel path TP^Cur and modify fastest travel routes by processing additional traffic guidance data from on-line navigation system data updates. Since all recommended speeds and directional traffic movements are monitored and updated on all links, the central server sends out live broadcasts of current traffic data to plurality of vehicle units in real time, and thus re-routing plurality of vehicles away from congested intersections.

Other methods of live traffic navigation updates are also available: local TL green times and recommended speeds are broadcasted to all passing vehicles within the local transmission range equipped with suitable antenna receivers and on-board navigation units. Current location information can also be updated at any number of on-line connected roadside displays along the travel path. Drivers stay updated by following traffic monitors advisory messages and recommended travel speeds to clear approaching traffic lights, green wave recommendations, and alternate routes, changing traffic conditions, traffic jams, road closures and atmospheric conditions reports.

Alternate Embodiment

As explained above, the overall performance of optimized traffic control in saturated networks depends on live traffic data collection and traffic congestion processing on plurality of saturated intersections in real time. The proposed patent presents basic methods of individual traffic light camera processing and image analysis for local and central traffic network optimization and green way coordination.

In this embodiment we use high resolution airborne thermal imaging cameras and satellite surveillance radar images such as synthetic aperture radar (SAR) and the inverse synthetic aperture radar (ISAR). The remote sensors are used for larger scale vehicle volume and congestion analysis. Sensor radar images from orbiting satellites provide traffic images for large urban areas and are more suitable for live network traffic monitoring. The streaming data from single, fixed radar source such ISAR provides traffic data images for large urban zones in extent of 10-30 km. The SAR or ISAR imaging while requiring specific software for data interpretation does not differ substantially from pixel images provided by other sources and are therefore suitable for brightness analysis in much the same fashion as presented above. In the infrared thermal imaging the reverse polarity (black=hot) images makes the brightness analysis even more straightforward. The plurality of intersections are designated and processed by the system according to traffic templates with operator-set parameters and are combined together with GIS road layer system and database.

The operator further designates approach lane and relevant exit regions on each intersection as described before.

The relevant series of SAR images are superimposed over GIS template coordinates and specific mathematical compensation is applied for vehicle/satellite movement corrections. Resulting vehicle congestion on plurality of traffic lights is mapped and computed in the central server in nearly real time.

According to this invention it is not necessary to generate detailed identification of individual vehicles as in prior art. User applies designated intersection template over radar or infrared images and much of the non relevant information is automatically filtered out. Computing congestion on specific approach and exit regions with short-time high and low peek-traffic calibrations significantly reduces processing time generally required for radar image and object interpretation.

Comparing several radar images from one location and using local traffic templates the processor computes relevant absolute pixel brightness variance of the images and estimates relevant vehicle parameters such as vehicle loading and general direction of vehicle travel.

Stationary radar configurations such as ISAR are better adapted for moving object detection such as road vehicles and are also suitable for showing number of vehicle travel-directions simultaneously.

The main advantage of remote traffic monitoring and road sensing systems is in that the ISAR, airborne thermal infrared cameras and to a certain extent SAR images provide live traffic data for wide urban areas simultaneously and are not affected by local weather and ground conditions. These systems also allow continuous 24-hour traffic coverage allowing full monitoring of night traffic as well.

Another advantage of the ISAR/SAR image analysis is that it can be executed in the central traffic processor in near real time. The proposed method of satellite image processing therefore significantly reduces overall costs related to traffic data collection and gathering, reliably replacing traditional data collection means from plurality of road sensors and other video or radar traffic surveillance systems.

Claims

1. A method for real time adaptive traffic light control of a plurality of intersections, the method comprising the steps of: a) evaluating traffic flow through the plurality of intersections based on 1) where and how many vehicles enter each respective intersection and 2) where and how many vehicles are blocking or causing blockage of exits of each respective intersection; andb) determining a timing of green lights for said intersections based on step a), based on the number of vehicles that need to exit the intersection so that it is not blocked and based on an ability of said vehicles to utilize said green light.

2. A method for real time adaptive traffic light control of a plurality of intersections according to claim 1, wherein steps a) and b) include the steps of: a) generating an estimated vehicle loading for each of the plurality of intersections, the vehicle loading including an approach vehicle loading in approaching lane regions of a respective intersection, and an exit vehicle loading in exiting lane regions of the respective intersection;b) processing the estimated vehicle loading for each of the plurality of intersections to separately optimize traffic light timing parameters corresponding to each of the plurality of intersections, the optimization maximizing a queue clearance through the respective intersection and reducing the vehicle loading for the respective intersection;c) processing the traffic light timing parameters corresponding to a number of intersections within the plurality of intersections to determine a timing of green lights for the number of intersections; andd) adjusting the traffic light timing parameters corresponding to the number of intersections based on the determined timing of the green lights.

3. The method according to claim 2, the method further including the steps of: e) generating recommended travel speeds for road links in order to reach a green light at a next intersection from a current intersection and current travel speeds on the said road links within the plurality of intersections; andf) generating a fastest route path guidance to client vehicle units and on-line roadside electronic displays based on the recommended travel speeds.

4. The method according to claim 2, step (a) including the step of estimating numbers of vehicles on the approaching lane regions and the exiting lane regions, respectively, of each of the plurality of intersections as a function of an approach or an exit lane length, an average car safe-following distance, an average car length and a current travel speed.

5. The method according to claim 2, step (b) including the step of, for each of the plurality of intersections, computing minimum and maximum cycle lengths for a traffic light of the respective intersection by combining a maximum of all minimal pedestrian crossing times and a minimum of maximal vehicle waiting times on all directions of the respective traffic light.

6. The method according to claim 2, step (b) including the step of using an objective function such that a number of vehicles will clear a traffic light during a whole cycle, the objective function having the constraints of: a) all green times being between a preset minimal value and a preset maximal value, b) all green times of a same group are equal and c) a sum of all green times of all groups provide together a current adaptive cycle length.

7. The method according to claim 2, wherein step (c) includes using a multiobjective optimization method for adapting the traffic light timing parameters from the number of intersections to produce a green wave coordination of traffic lights corresponding to the number of intersections.

8. The method according to claim 2, wherein step (a) includes generating an estimated vehicle congestion for each of the plurality of intersections and step (b) includes processing the estimated vehicle congestion for each of the plurality of intersections.

9. The method of claim 8, wherein a current vehicle loading and the vehicle congestion on the plurality of intersections is generated from one or more of a space borne high resolution camera, a thermal imaging camera or air satellite surveillance radar including synthetic aperture radar (SAR) or inverse synthetic aperture radar (ISAR) with high spatial resolution.

10. The method according to claim 2, step (a) including the step of estimating the vehicle loading by measuring an image brightness of a captured image for each of the plurality of intersections.

11. The method according to claim 10, wherein, for each of the plurality of intersections, the captured image includes bitmap images collected over a short calibration period and the estimated vehicle loading is generated using a pixel brightness value on specified traffic lane-regions corresponding to the approaching lane regions and the exiting lane regions in the collected bitmap images.

12. The method according to claim 10, wherein the estimated vehicle loading is computed according to a quantity of pixel strings from the captured image in horizontal and vertical directions of a region where a difference of an initial and an ending pixel brightness exceeds a pre-set tolerance brightness value.

13. The method according to claim 2, further including the step of broadcasting current, recommended and predicted travel times on all links from a traffic guidance center to all on-line connected client vehicle databases for on-vehicle fastest route guidance using the traffic light timing parameters of the plurality of intersections.

14. The method according to claim 13, wherein optimal fastest routes to on-line driver units are broadcast from the traffic guidance center according to individual start and destination requests.

15. A method of claim 13, wherein current and recommended travel times updates, and green time durations are broadcast to roadside monitor displays according to corresponding GPS coordinates.

16. The method according to claim 2, wherein step (a) includes correlating intersection video camera views with the respective approaching lane regions and the respective exiting lane regions on a GIS graphic information map and a database system.

17. The method according to claim 16, wherein the method includes constructing and maintaining a central traffic guidance database for storing and updating data on current travel times on all road links in at least one geographical region where each road link contains a directed road segment and a turn-off or a go-through segment, the method including the steps of: a) constructing and maintaining database tables for storing and updating statistical data on said travel times;b) subdividing said statistical data into finer categories according to one or more of a day of the week, a type of the day, an hour of the day, fractions of the hour of the day, or weather conditions, and storing the subdivided statistical data;c) computing real time estimates of travel times along the road links in a vicinity of at least one vehicle that has requested travel guidance;d) constructing partitioned graphs of road networks for at least one geographical region and pre-computing distances associated with the partitioned graphs; ande) combining said statistical data and said real time estimates of the travel times along the road links into a temporary combined table for use in route guidance applications.

18. The method according to claim 17, wherein time-dependent modifications of an A*-type algorithm are used in conjunction with the combined temporary table for finding an optimal route for the at least one vehicle that has requested the travel guidance from its present position to a desired destination.

19. The method according to claim 18, wherein the time-dependent A*-type algorithm uses time-dependent estimates for travel times of already covered road links and time-dependent estimation functions for the remaining travel time for destination.

20. The method according to claim 19, wherein the time-dependent A*-type algorithm uses the time-dependent estimation functions for the remaining travel time based on lower bound estimates of the remaining travel route length and on upper bound estimates of feasible travel speeds, including the steps of: a) constructing the lower bound estimates of the remaining travel route length based on the partitioned graphs of the at least one geographical region and on the pre-computed distances associated with the partitioned graphs; andb) constructing the upper bound estimates of the feasible travel speeds based on available estimates of travel times and on feasible time windows required for completing the desired route.

21. The method according to claim 2, the method including the step of, for each of the plurality of intersections, generating current travel times and speeds on the respective approach lane regions and the respective exiting lane regions as an inverse ratio of an allowable speed on the corresponding region and a respective currently measured intersection vehicle loading.

22. The method according to claim 21, including the step of predicting short-time travel times for shortest route guidance for user-specified route destinations based on the current travel times and a predicted congestion delay index on each link within a user's current geographical position.

23. The method according to claim 22, wherein short-distance travel times are computed based on the generated current travel times that are within less than a 10 minute travel-time radius of a location of the user that has requested travel guidance.

24. A method of claim 22, wherein estimated travel times are generated for at least one location of the user that has requested travel guidance for distances greater than 10 minutes of travel-time using the generated current travel times and recent historical traffic data.