WuPiN G XiN BloG

It is All about Traffic, and Programming



0 visitors online now
0 guests, 0 members

A cute example of Aimsun scripting

Aimsun is traffic simulation software developed by Transport Simulation System (TSS). It has a very powerful python-based scripting engine.  Though other traffic simulation software, e.g., PTV Vissim or Caliper TransModeler provides scripting functionality as well – yet Aimsun’s scripting engine has some unique features that make the scripting work not only productive, but also quite fun 😆 .

One such feature is the so-called live-binding of  a script to any selected object type.  

In Aimsun framework,  all elements of the simulation task – from network geometry,  control devices, script,  to menus, dialogs, projects, scenarios, algorithms …. everything … anything – is an “object”,  derived from a base class GKBaseObject which is rooted from Qt’s QObject.  The entire Aimsun software is built upon a Model-View-Controller (MVC) framework taking advantage of Qt framework.  This framework is well exposed to end users via its SDKs, APIs, and the Scripting Engine.  Apart from being a  comprehensive traffic simulation tool,  Aimsun presents itself as an excellent example of  modern design patterns and software engineering. It has very small memory footprint as well.

The following example comes with default Aimsun installation, i.e.,  the sample script No. 30 “Copy Control Plan”.

Please note, the latest Aimsun 8.0.x versions have some internal changes breaking the scripts that once had worked with Aimsun version 7.x. TSS releases  these scripts with the official Version 8.0.x without upgrading those scripts,  and you’ll have to fix them yourself.   (UPDATE: Aimsun 8.0.8 released on March 19, 2015 has fixed this.)

The following is the original script Copy Control Plan that comes with Aimsun official 8.0.x installation:


In the above,  Line 3 – Line 7 should be replaced as follows:


So, the script after the fix should look like the following:


Some notes:

  • The object that the script binds to is represented by the name “target”. Therefore,  if the script is bound to node-type objects (e.g., the script is added to the context menu of node objects),  “target” would refer to the subject node object.  To bind a script to another  object,  you simply right click the script, select “Properties”. Then from “Settings” tab –> “Add Script to a Menu”, select an object type in the drop-down list “To Context Menu for Object Type” .  See the figure below.


  • getControlPlan is called twice, at Line 11, and at Line 14. At Line 11,  it is called to get the source control plan object. At Line 14, it is called to get the destination control plan object.
  • GAnyObjectChooserEditor and GAnyObjectChooser are two interesting classes.  GAnyObjectChooserEditor is a later-addition.  Originally there was only GAnyObjectChooser class.  The helper class GAnyObjectChooserEditor is added to separate the chooser class and the editor class – a better design/refactoring but breaking some of the existing scripts .  Basically,  as its name indicates, it provides a user interface to choose an object of the specified type in Aimsun framework.  You can see it in action in the following figure:


  •   chooser.setType is the one responsible for specifying what type of objects that the Editor dialog should present.

In summary – Aimsun python scripting engine are able to:

  1. Dynamically bind a script  to any objects during run-time;
  2. Inside the script engine, Aimsun provides ready-made UI elements to facilitate the interactions between the end user and the Aimsun host.  This allows productive and efficient workflow of simulation projects with the creative minds of a traffic modeler.
  3. Agree?  Any thoughts, or Aimsun scripting experience to share?

Brain-Wave Controlled Traffic Simulation: Control a Vissim Simulated Car (2)–Open Box

Emotiv  EPOC Neuroheadset  (Special LImited Edition) is priced a little over $400, and shipped in a nice box.  The package includes the headset, a sensor box with 16 sensors, a USB wireless receiver, and a charger. If you are willing to pay a little more, you can get an enhanced edition with firmware providing the raw EEG data. But I chose not to.


The following picture shows the package box.  The design is nice and the model in the picture looks cool.



As you can see, the headset is sleek and looks with some Sci-Fi taste.  Can you see the he sensor sockets?


This picture shows how it looks after all the sensor pads are put into the sockets.  They have to be soaked with the supplied saline liquid.



This picture shows the SDK control panel. The diagram shows the sensor signals.


The picture below shows the real-time charts of my brain activities, the Y axis represents the intensity of the signal. Different color of charts represents different emotions such as frustration, excitement, meditation etc.



Clearly, the EEG data of my brain activities suggest I am amidst  potpourri emotions including frustration, excitement, boredom and others. Gee, I think I love this little Gadget.


(to be continued).

Brain-Wave Controlled Traffic Simulation: Control a Vissim Simulated Car (1)

Ever watched the movie “Carrie”, a classic produced in 1976 from Stephen King’s 1974’s horror novel?  An abused 17-year-old girl with telekinesis, gets pushed to the limit by a humiliating prank,  and finally took her revenge with her power – turning her school’s prom into a bloody night of killing.

You might want to develop telekinesis on your own,  so as to get back on whoever you get pissed of with – Good Luck on That!  Here is a nice tip on How to Develop Telekinesisjust let me know how it works!!

What we are going to talk about today is the so-called Brain-Computer-Interface (BCI), which is about using your brain wave patterns to train a computer program, while the latter directs some device doing some nice, dirty, and/or even horny (you wish!)  jobs for you   😆  

Here is an excerpt from Wikipedia:

A brain–computer interface (BCI), sometimes called a mind-machine interface (MMI), or sometimes called a direct neural interface (DNI), synthetic telepathy interface (STI) or a brain–machine interface (BMI), is a direct communication pathway between the brain and an external device. BCIs are often directed at assisting, augmenting, or repairing human cognitive or sensory-motor functions.

BCI uses Electroencephalography(EEG), which detects voltage fluctuations resulting from ionic current flows within neurons of brain. Whenever your neurons fire,  weak electrical signals in millisecond-range resolution propagates all the way to the scalp.This signal is at higher resolution than CT or MRI.

Therefore, BCI is pretty much about signal processing, machine learning and pattern recolonization recognition.

EEG was invented in early 1900’s, hence it is not something new.  However, when the time comes to 2010’s,  the industry has come out with cost-effective and portable EEG devices (unlike those used in medical applications).  Novel applications are thus enabled.  The following pictures (source:http://emotiv.com/) illustrate a conventional EEG and a portable EEG device.

compare1 compare2

The following picture shows Emotiv EPOC EEG device, manufactured by Emotiv, featuring

16 wet electrodes, 14 EEG electrodes read brain waves, two-axis gyroscope to read head movements, 4 mental states, 13 conscious thoughts or facial expressions, 4 processing suites

The wonderful thing is, this little device sells for only $399 desktop or $499 for Bluetooth Smart, with full programming SDKs. You can even integrate it with wearable devices (such as Google Glass).


And, that is what I am gonna do.  I am going to use this little gadget, and its SDKs to interface with VISSIM microscopic traffic simulator via its COM interface and Driver API – so I can:

  • Command a simulated car to brake, accelerate and stop,  using my brain wave – termed otherwise,  by simply staring at my computer screen like a dork 😯 .

That is right.  I am going to present an interesting demo here that Brain-Computer-Interface for the first time,  being used in traffic simulation to control a simulated car…… (I really wish one day I could use the same to command my boss to pay me more  😈 )

Stay tuned. It is going to be realllllly FUN.

(to be continued)

Adaptive Signal Control for Diamond Interchanges

A new adaptive signal control deployment for a total of 15 intersections at freeway diamond interchanges go live yesterday Oct 10, 2014, in Staten Island of New York.

Diamond interchange is characterized by two closely spaced intersections, with left turns on the common approach connecting the two intersections. The common approach generally is a short block fed by movements from various phases.

Traffic signal control at diamond interchange can be viewed as a special type of over-saturated control with unique geometric features. The primary goal is to facilitate vehicle movements, while preventing queuing back to other approaches and ensuring pedestrian safety. Generally small cycles are preferred over long cycles.

Conventionally, adaptive traffic signal control primarily targets progression optimization or delay minimization in unsaturated conditions, with its insufficiency dealing with over-saturated traffic.

This system is powered by the ACDSS adaptive control technology developed by KLD, integrated with TransCore TransSuite TCS.  Thanks to its unique design of the so-called Signal Optimization Repository,  ACDSS is capable of  addressing the real time signal optimization for diamond Interchanges, urban CBD grid, arterials, and cluster of intersections.  It can be either running as cycle-based, or second-by-second (cycle-free).

The same system has been deployed controlling more 300 intersections in Manhattan of New York City, and being installed in other states including California as well.

Advanced Aimsun API Programming (2)

Aimsun MicroAPI has a total of 444 functions,  in three header files:

  • AKIProxie
  • ANGConProxie
  • CIProxie

These functions are ported to Delphi language, and the following shows a demo of obtaining vehicle information:

Aimsun API-Delphi Demo 1: Obtaining Vehicle Information

  • First the exported functions are defined in the project file, as follows:
// AIMSUN API  Delphi Interface
// Ported by Wuping Xin
// Last Update @2014-03-21 20:23:55

library AAPI_veh_info;

  AAPI in 'AAPI.pas',
  AAPI_Util in 'AAPI_Util.pas',
  AKIProxie in 'AKIProxie.pas',
  ANGConProxie in 'ANGConProxie.pas',
  CIProxie in 'CIProxie.pas';

{$R *.res}


  • Second,  the exported functions are actually implemented in unit AAPI.pas file, as follows:
unit AAPI;

  function AAPILoad: Integer; cdecl;
  function AAPIInit: Integer; cdecl;
  function AAPIManage(aTime: Double; aTimeSta: Double; aTimeTrans: Double;
      aSimStep: Double): Integer; cdecl;
  function AAPIPostManage(aTime: Double; aTimeSta: Double; aTimeTrans: Double;
      aSimStep: Double): Integer; cdecl;
  function AAPIFinish: Integer; cdecl;
  function AAPIUnLoad: Integer; cdecl;

  function AAPIEnterVehicle(aVehID: Integer; aSectionID: Integer): Integer; cdecl;
  function AAPIExitVehicle(aVehID: Integer; aSectionID: Integer): Integer; cdecl;
  function AAPIEnterVehicleSection(aVehID: Integer; aSectionID: Integer; aTime:
      Double): Integer; cdecl;
  function AAPIExitVehicleSection(aVehID: Integer; aSectionID: Integer; aTime:
      Double): Integer; cdecl;
  function AAPIInternalName: PAnsiChar; cdecl;

  function AAPIPreRouteChoiceCalculation(aTime: Double; aTimeSta: Double):
      Integer; cdecl;


  SysUtils, AKIProxie, ANGConProxie, CIProxie;

  function AAPIEnterVehicle(aVehID: Integer; aSectionID: Integer): Integer; cdecl;
    Result := 0;

  function AAPIEnterVehicleSection(aVehID: Integer; aSectionID: Integer; aTime:
      Double): Integer; cdecl;
    Result := 0;

  function AAPIExitVehicle(aVehID: Integer; aSectionID: Integer): Integer; cdecl;
    Result := 0;

  function AAPIExitVehicleSection(aVehID: Integer; aSectionID: Integer; aTime:
      Double): Integer; cdecl;
    Result := 0;

  function AAPIFinish: Integer; cdecl;
    Result := 0;

  function AAPIInit: Integer; cdecl;
    Result := 0;

  function AAPIInternalName: PAnsiChar; cdecl;
    Result := 'AAPI_veh_info';

  function AAPILoad: Integer; cdecl;
    Result := 0;

  function AAPIManage(aTime: Double; aTimeSta: Double; aTimeTrans: Double;
      aSimStep: Double): Integer; cdecl;
    lvVehInfo: InfVeh;
    lvNumOfSections, lvNumOfVehs, lvNumOfJunctions: Integer;
    lvSectionIdx, lvVehIdx, lvJunctionIdx: Integer;
    lvSectionID, lvJunctionID: Integer;
    lvVehInfoStr: string;
      lvNumOfSections := AKIInfNetNbSectionsANG;

      for lvSectionIdx := 0 to lvNumOfSections - 1 do
        lvSectionID := AKIInfNetGetSectionANGId(lvSectionIdx);
        lvNumOfVehs := AKIVehStateGetNbVehiclesSection(lvSectionID, True);

        for lvVehIdx := 0 to lvNumOfVehs - 1 do
          lvVehInfo := AKIVehStateGetVehicleInfSection(lvSectionID, lvVehIdx);
          lvVehInfoStr := Format('Vehicle %d, Section %d, Lane %d, CurrentPos %f, CurrentSpeed %f',


      lvNumOfJunctions := AKIInfNetNbJunctions;

      for lvJunctionIdx := 0 to lvNumOfJunctions - 1 do
        lvJunctionID := AKIInfNetGetJunctionId(lvJunctionIdx);
        lvNumOfVehs := AKIVehStateGetNbVehiclesJunction(lvJunctionID);

        for lvVehIdx := 0 to lvNumOfVehs - 1 do
          lvVehInfo := AKIVehStateGetVehicleInfJunction(lvJunctionID, lvVehIdx);
          lvVehInfoStr := Format('Vehicle %d, Node %d, From %d, To %f, CurrentPos %f, CurrentSpeed %f',



      Result := 0;

  function AAPIPostManage(aTime: Double; aTimeSta: Double; aTimeTrans: Double;
      aSimStep: Double): Integer; cdecl;
    Result := 0;

  function AAPIPreRouteChoiceCalculation(aTime: Double; aTimeSta: Double):
      Integer; cdecl;
    Result := 0;

  function AAPIUnLoad: Integer; cdecl;
    Result := 0;


 The above demo and the ported Aimsun API in Object Pascal can be downloaded from here.



Initial Setting up of Vissim COM in .NET environment

VISSIM’s kernel is pretty much written using  C++ (a lot of template programming),  including its COM part.  Its UI is written in .NET for a better user experience, though. The VISSIM COM API manual is mostly about using it with Visual Basic or VBA,  which has long been depreciated by Microsoft since Visual Studio 6.0.

For .NET environment,  no detailed description is provided as to how to import the COM lib.   Anyway, here are the list of the snapshots to show how to import Vissim type lib in .NET (VS 2012), to start VISSIM COM client programming.  It applies to all .NET languages, such as C# or VB.NET.

1. Create a new C# (or VB.NET project).


2. You will see something like below.


3. Right click “References”,  choose “Add Reference”..



4.  Choose “Browse”.


5. Browse to where Vissim is installed,  select “Vissim.exe” . Click “Add” , and click “OK”.


6. You will now see “VISSIMLIB” is added to the references list.  From this point on,  you can start referencing VISSIMLIB interfaces as in the C# example of the VISSIM manual.  Have fun.


VISSIM 6 SP11 Memory Leak – False Alarm

VISSIM 6.0 has some nice features as advertised by PTV sales – but the truth is it presents itself  with more headaches than convenience for its existing users.  To name a few – almost a complete re-design of new user interfaces,  frustrating performance (VERY slow execution even on a high-spec machine),  menu items of placeholders of functionalities not implemented yet ,  and so many other annoying glitches…

The latest Service Pack 11 was released a couple of days ago, and I noticed that it has a major memory leak issue (see below updated information abut this matter) – I am referring to VISSIM 32bit  on Windows 7 x64 OS (I didn’t check the 64bit version) – to replicate,  simply launch four instances, and close the instances one after another by either click the Close button on the upper right corner,  or from File->Exit.  No need to load network files.

NOTE: VISSIM only supports up to 4 concurrent instances.

Now, open the Task Manager, and you will see the 4 Vissim instances dangling there, forever, each consuming approximately 200 MB RAM, and 22 threads, and 131  GDI objects. To make it worse,

  • You will NOT be able to launch any new Vissim instances because of these 4 invisible dangling zombie Vissim instances.


  • You COM client applications will be screwed up as they will get confused when trying to connect Vissim instances and they will never succeed, causing the COM applications freezing out there.




**********************          UPDATE         ***************************

This “memory leak” turns out to having nothing to do with Vissim.  It is a ridiculous non-tech problem.

I was traveling in China, and I was using Vissim North American edition.  When the Vissim 6.0 software was launched and closed,  Vissim 6.0 will try to connect to some “foreign” servers that were probably on the “white list” of the Chinese ISP  (if you don’t know about China’s Golden Shield System, a.k.a known as Great Wall Firewall system and its DNS hijacking – please google).  That caused the very slow loading up, and never-end-closing of Vissim instances (sometimes, this doesn’t happen at all, but most of the time, it did)




Running VISSIM from within MATLAB

Vissim has a very nice COM-based programming interface – that a user can use any COM-compliant languages (as COM client)  to programmingly invoke Vissim (as out-of-proc COM server),  and performs some customized task.  Typically,  a user can use Excel/VBA, C#, Java,  Fortran, Delphi, C++ etc as his preferred language.

Matlab is a comprehensive computation platform with a lot of readily available numerical algorithms (e.g., Genetic Algorithms,  Support Vector Machine, Wavelet, Kalman Filtering etc.)  that can be very useful in simulation studies, research and development on customized and sophisticated simulation experiments.

Matlab provides very good support for COM – hence it is, in my opinion, probably the best Vissim COM programming environment if you have an academic minds and wish to do some cool prototypes and interesting simulation experiments.

  • For industry applications,  it is probably an overkill,  and the performance hit is a problem – Matlab essentially works the same way as Excel/VBA – this means all method invocations are “interpreted” – the stack frame is created by first querying a dictionary of method names to get the right function pointer,  amongst the mess of the inter-process marshaling.   C++, C# or any compiled language would be much faster as the stack frame is created directly from function pointer without the  querying step.  Wait – strictly speaking, C# is a bit different from other native language like C++, Delphi, or Fortran, as .NET/COM inter-op is via Common Language Runtime (CLR)’s P/Invoke which is another layer, rather than the pure native way.

Vissim User Manual doesn’t mention how to use Vissim COM wih Matlab.  It is not complicated but there is some catch to make it work, so I just put the procedures here – and,  if you find it helpful,  a loud “Thank You” would make me HAPPY!

First thing first,  in order to run Vissim COM,  you would need to know Vissim’s ProgID, which is a string-based name saved in Windows system registry, together with some other information (such as the path to Vissim.exe).  Here is an excerpt you need to read carefully from Vissim COM manual:

When working with Vissim  manually it is possible to start several instances of Vissim. You
can  also  start  several  different  versions  (e.g.  Vissim  5.40  and  Vissim  6.0).  The  same
applies  when  working  with  COM:  If  the  version  number  is  not  specified  (i.e.
CreateObject (“Vissim.Vissim”)),  the  Vissim  version  which  has  been  registered  as  COM
server most recently is started.  Specifying the version number during the call allows you to
start  a  specific  version  of  Vissim:  CreateObject (“Vissim.Vissim.540”)  for  Vissim  5.40  or
CreateObject (“Vissim.Vissim.600”)  for Vissim 6. If you have installed a 32-bit and  a  64-bit
edition,  you  can  use  “Vissim.Vissim-32.600”  or  “Vissim.Vissim-64.600”  to  start  a  specific
edition. A Vissim instance started via COM is automatically closed as soon all COM objects
are set to nothing.

This is kind of twisty, so let me rephrase it, with some simplifications:

  • If you only have one Vissim version installed, ProgID = “Vissim.Vissim”
  • If you have multiple Vissim version installed, ProgID = “Vissim.Vissim.XXX”, where XXX is the version number, e.g., 540 for version 5.40, or 600 for version 6.00. Please note,  service packs doesn’t count for version number, so service pack 1, 2, … n for the same version have the same ProgID
  • If you have multiple Vissim versions,  for 32bit and 64bit, then the ProgID = “Vissim.Vissim-YY.XXX”, where YY is 32, or 64, corresponding to 32bit or 64bit edition, XXX is the version number such as 540, or 600.

With ProgID in mind, and a Vissim COM interface online manual in front of you,  now you need to

  • Launch Matlab (in my example I am using Matlab 2013b), but I believe any Matlab version after 7.0 will do;
  • In the Matlab Command Window, type
    vissim = actxserver('Vissim.Vissim.600')

    Note here a ProgID string ‘Vissim.Vissim.600’,  with an explicit version number 600 is used. This is because on my computer I have two Vissim versions (540 and 600) installed. actxserver is a Matlab command that returns the default interface of the COM server, which in our case,  is IVissim interface.

  • Immediately you will see a Vissim 600 instance being launched automatically, and the main GUI shows up;
  • The Matlab variable, “vissim” is a handle to IVissim interface. From this point on,  you can use “vissim” to call various other interfaces, for example,
    vissim.LoadNet(‘whatever.inpx’), vissim.Simulation.RunContinuous, simulation = vissim.Simulation
  • You can do whatever you like now with Matlab,  including invoke  Genetic Algorithm routines or something else;
  • Finally, when you are done,  to destroy “vissim” (which is a reference-counted handle of IVissim interface),  simply put this line
    vissim = 0,  or alternatively,  vissim.Release

    then the vissim instance will be destroyed (to be more accurate  – released to decrement ref_count,  and destroyed if ref_count drops to zero) and the main GUI disappears from the screen.

Last, there are two little tricks working Vissim in Matlab environment , you can use .get to list all properties of an interface, and .methods to list all methods of an interface, for example:

You can immediately recognize that these are all listed in Vissim COM Manual – but it is good to verify by using .get  and .methods.



I found another good source of information on this subject is a white paper of Dr. Tamas Tettamanti, which provides a more detailed step-by-step document for Vissim-Matlab integration –



“Early-Return-to-Green”–What is the Big Deal?

Just returned from the Transportation Research Board (TRB) 93rd Annual Meeting , a.k.a TRB.  Meandering through the jungles of  papers, presentations and committee meetings — this has been my 8th attendance to TRB.

I felt I did have gleaned some gems, meeting some really smart people and humbled by some of the brightest brains.  Handshakes,  beers and a little catching up with old friends.  Ah!  Never before had I reflected so much on the profession that I have devoted myself to.


An interesting subject that I picked up from this TRB,  is an “issue” called “Early-Return-of-Green”, which is some sort of glitches coming out of Actuated Signal Control.   The following is an excerpt from FHWA website:


One of the consequences of coordinated, actuated control is the potential for the coordinated phase to begin earlier than expected. This “early return to green” occurs when the sum total of the time required by the non-coordinated phases is less than the sum total of the vehicle splits coded for the phases. While this may reduce delay at the first intersection, it may increase system delay because of inefficient flow at downstream intersections or, most important, the critical intersection of the network. Figure 6-26 illustrates this within a time-space diagram, that vehicles in coordinated phases that begin early may be forced to stop at one or more downstream intersections until they fall within the “band” for that direction of travel. This can result in multiple stops for vehicles and a perception of poor signal timing.


There are also quite a few papers and references in the past years discussing this,  some recent ones trying to revisit the “issue” using the so-called “high-resolution event-based signal data”.


To recap,  the “issue” is  nothing but that non-coordinated phases, with their actual green time being determined by vehicle actuations, may terminate early (gap-out)  without hitting the force-off points (which are defined by their splits).  The extra greens are then simply awarded to the coordinated phases.  As a result,  the coordinated phases start green earlier than the time that is defined by their splits.

This has been cited as a “BIG” problem that could damage arterial signal coordination in various publications.  Several serious methodologies, formulations and equations, or frameworks have been proposed trying to diagnose and “fix” the problem.


To tell you a little secret about myself – I am a die-hard big fan of the late Henry Barnes,  known for the “Barnes Dances”.  One of my favorite quotes of Mr. Henry Barnes was

“In this business there are very few problems that can’t be solved with some yellow paint and a little bit of common sense.”

Without resorting to pretty LaTeX-typesetted equations  (as an ego-satisfying proof that I am reeeeeally good at the so-called analytical thinking to interprété simple things in a complicated way,  if nothing else 😛 😉 😛 ) —  my “little bit of common sense” now begins churning and cries out loud:

What is the Bigggggg DEAL?

Not a big deal, at all – and here is my chain of logic as a quick-and-dirty Traffic Engineer:

First,  granted,  for a coordinated arterial the initial formation, and  coherence of the formed platoon,  with some of the intersections having this “early-return-to-green”,  might be temporarily impacted/compromised – however, the designed band is still there; it doesn’t disappear, isn’t missing or is taken away by light of lightening whatever, it is SIMPLY BEING THERE.  This means, any vehicle arrivals show up within that band will still be able to clear the intersections without stopping (in most of the cases during off peak time).

Second,  as long as NOT ALL intersections have “early-return-to-green”,  there must be AT LEAST ONE intersection running according to the designed band,  where vehicles (that have arrived out of the extra-green time from the upstream intersections)  have to stop.  Contrary to someone’s belief that this is the “bad thing”,  my opinion is,  this is  GOOD instead,  as it provides THE  OPPORTUNITY for re-shaping the platoons. Stated otherwise,  the platoon might be impacted initially (see my first point), yet the platoon would be reorganized and reshaped sooner or later – the traffic system by nature is capable of self-organanizing by itself,  isn’t that beautiful?

Third, even if all intersections have “early-return-to-green”,  so what?   Those vehicles being stopped due to the out-of-band arrivals would  have to be stopped anyway, regardless “early-return-to-green” occurs or not.   “Early-return-to-green” will not significantly increase stops or total delay — because it simply re-distributes the stops at various internal intersections.  Or, put it more precisely,  “early-return-of-green”,  though seemingly disrupts the designed progression,  will NOT significantly increase number of stops, nor increase the total delay as compared to the normal situation.  It will not make things any worse, if not making them better.

The “issue” is even more trivia, if the arterial has a high platoon ratio (i.e., the percentage of through traffic volume all  the way from the first intersection to the last),  while the boundary intersections have high minor street demand thus eliminating “early-return-to-green” at the boundary intersections – this essentially results in the platoon formed at the boundary, progressing through the designed green band regardless of whether other intersections in-between having “early-return-to-green” or not.

Last,  it is worth noting that, early-return-to-green might help increase the arterial capacity by helping shared-lane turning vehicles,  largely due to the largess of extra green saved from minor phases.  And, that is the beauty of the actuated control.

Some papers proposed some methodologies, and showed that the new offsets proposed by the methodologies resulted in  less delays and number of stops.

Actually, to me, this proves nothing relevant to early-return-to-green.  It only proves that previous offsets are not optimal.  In my opinion, to verify whether early-return-to-green really screws things up, we would need to check — for the same demand pattern and the same offsets and everything else controlled — whether delay and/or number of stops increase with early-return-to-green vs. no early-return-to-green (i.e., put max recall on minor streets so the minor phases are always forced out). My telling is, no, it will not screw progression as some of the papers have assumed. At least, it will not make things worse, if not better.

In my conclusion,  “early-return-to-green” is mostly not a bad thing for the designed arterial progression.  It even has some advantages that were not explicitly noted before.  The benefits of the “early-return-to-green” comes from the benefits of actuated control, while,  at the worst  the potential impact on the designed coordination pattern is probably just the unjustified driver perception of “bad” signal timing, and at best the extra green saved from minor streets help increase intersection capacities, especially when the arterial direction has heavy volumes already.   It might also help shared turning vehicles.

So for “early-return-to-green”, is there really something calling for a serious fix?

I guess it depends, mostly not.  To me,  “early-return-to-green” is not a defect or curse of Actuated Control,  rather it is a welfare and benefit coming from Actuations.  Its impact on the arterial progression is probably not a serious “issue”  or a real problem,  albeit – it renders a good Don Quixotes‘ windmill for some type of exercises of the academic minds.

Agree? Disagree?


Updated on Jan 21, 2014 – admittedly this is a compounding and convoluted problem  –   especially if all possible shock wave paths and nuances considered.  But that is my point and there is a simple engineering solution to obviate (well,  largely to some extent) the complexities:

1.  Explicitly, do NOT allow early-return-to-green at the boundary intersection(s) ( plural,  if both directions are considered).  This makes sure that the primary platoons are formed and will be progressing in the band width, as designed.

2. Secondary platoons can surely take advantage of the “early green”, to get out of the way for the primary platoon. If the secondary platoons have to stop (in front of the primary platoon), so be it, they have to stop anyway because…because that is what they called – i.e., “secondary”…., even without those early greens. This is exactly why I say, “early-return-to-green” will not make things any worse, if not better.