It is All about Traffic, and Programming
0 visitors online now
0 guests, 0 members

Signal Control

Adaptive Signal Control: Cyclic, or not?

At LinkedIn Group Adaptive Traffic Signal Control Systems,  Dr. Andrei Reztsov,  an applied mathematician posted a link for his new paper

Self-Organizing Traffic Lights as an Upper Bound Estimate
Andrei Reztsov, Complex Systems 24(2).


Self-organizing traffic lights (SOTL) are considered a promising instrument for the development of more adaptive traffic systems. In this paper we explain why some well-promoted results obtained with the use of SOTL should be scrutinized and carefully reviewed. Current computational research projects based on SOTL should be reviewed too.


For those interested,  Dr. Reztsov’s papers can be downloaded from SSRN.

I applaud this paper for its insights and for its logical and rigorous treatment from an mathematician to point out the methodological fallacies of SOTL or those type of second-by-second genre of real time signal control. I concur with the opinion of the paper. As far as I know, this appears the first to discuss the following aspects of adaptive signal control:

  • cyclic calculation/decision,
  • sub-cyclic calculation/decision, and
  • sec-by-sec decision.

Self-Organizing Traffic Light (SOTL), or sometimes  “Second-By-Second” control  refers to acyclic operations by internally manipulating phase force-off and phase hold commands so the signals do not operate on a cyclic basis. It is “second-by-second”,  in the sense the system monitors phases status and detectors inputs continuously,  and makes decisions to terminate or extend phases on a second-by-second or near second-by-second basis.  These are currently not within standard NTCIP C2F operations.

A centralized second-by-second control typically would result in high communication overhead due to the onerous second-by-second status monitoring at each individual phase and/or detector level. Also second-by-second control cannot be easily integrated with current NTCIP Center-2-Field framework, because  NTCIP is UDP based type of communication that cannot guarantee the receipt of data packets, thus not meeting the reliability requirement for second-by-second control. In practice it is typically implemented in a distributed manner at local controllers, and requires certain middle-tier mechanism (e.g., a field master, or a customized firmware embedded in the same cabinet, or an add-on module communicating with a standard SDLC port) to coordinate with adjacent intersections and cache the second-by-second commands without overwhelming the central system, if any.

Second-by-second type of control is flexible,  and effective when traffic demand is low to the extend of random arrivals. It is most effective when the network starts with empty streets – that is exactly where this type of control’s niche resides to best reshuffle the time resource – to accommodate the predicted arrival of platoons on a preferred route. It works well, only and only when there is time resource to exercise such “rescheduling”.

And that is  the problem.

The traffic signal optimization problem is fundamentally simple – it boils down to allocate either limited time resource (for oncoming vehicles),  or limited space resource (for queuing vehicles),  of at-grade intersections with competing traffic streams.

“At-grade intersections” means the system has to deal with competing traffic streams in a 2-D plane.  Both time and space resources are limited for at-grade intersections.  Time resource is limited,  because in practice  any at-grade intersection’s capacity will never exceed 1800 vphpl; space resource is limited, because it is constrained by available storage space.

The signal for each phase applies to the group of drivers, not an individual driver on an individual stop-release basis. When traffic is light,  the signals running second-by-second can favor the predicted on-coming traffic on a preferred route,  thus reducing perceived maximum waiting time for individual drivers, and improving individual driver satisfaction.

The challenge really comes when traffic becomes heavy and over-saturated.  In that case,  the available capacity of an intersection is not able to serve the demand, and the flexibility to shuffle the time resource for vehicle platoons is gone.

It is logical to believe that when traffic is light to the extent of pure random Poisson arrivals, SOTL behaves more like an enhanced actuated type of control; when traffic increases, SOTL would converge to cyclic no matter how the logic tries to reshuffle the time for individual vehicles.  The chain of reasoning is:

When traffic is light, the value of sec-by-sec may help individual driver  satisfaction due to its flexibility to freely terminates a phase, and due to the reduced MAX perceived delay time, but not primarily average delay. However, when demands increase, the benefits quickly diminish and average delay increases.  At certain range of traffic flow regime, sec-by-sec control  probably reduces capacity because of the increased lost-time from phase switches.  Remember,  phase switches have a cost of lost time which is non-trivia when traffic is not light.  Therefore, with traffic increasing, sec-by-sec will quickly converge to cyclic losing its point.

This explains my particular favor of a cyclic system and I found this paper is very interesting.

Convergence to cyclic and the effect of sec-by-sec of reducing MAX perceived delay instead of AVG delay renders such operation moot in practice, because:

  • When traffic is light as random arrivals, there is really not much need or systematic benefits of  running adaptive.  This is because a fully actuated setting can well handle light traffic conditions.  Favoring a route when traffic is light may well promote speeding and incur other  implications.

This also explains why sec by sec control by itself wouldn’t be working well for congested or heavy traffic, at least not as well as some of the literature reported.  It appears to me many before-and-after improvements were built on the base case of comparisons being poorly-tuned fixed time plans,  or not well-configured semi-coordinated operations.

In summary, using comments posted in the same LinkedIn Group, from Mr. Kevin Fehon:

It is logical that SOTL or similar systems must converge to a cyclical state with heavy demand and practical constraints (such as maximum wait time, driver expectations about fairness in distribution of delays, etc.). This is built-in in their operations, and  is supported by observation of existing non-cycle based systems in the field.  It appears that this convergence also cannot be as optimized as the operation of a system whose optimization assumes cyclical operation, especially when vehicle-actuated flexibility (phase re-service, phase sequence changes under different traffic conditions, etc.) is built into the system.

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).

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.

“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 – however, the designed band is still there; it doesn’t disappear, isn’t missing or is taken away by aliens whatever, it is SIMPLY THERE.  This means, any vehicle arrivals within that band will still be able to clear the intersections without stopping.

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 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 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 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 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 fix?

I guess it is not.  To me,  “early-return-to-green” is not a defect,  rather a welfare and benefit coming from actuated control.   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 get rid of  (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.



Dissecting NTCIP 1202/SNMP Message – Part 1

The National Transportation Communication for ITS Protocol (NTCIP) is a family of standards for electronic traffic control equipment.  For traffic engineers, or professionals that have to deal with traffic signal control,  NTCIP 1202 is of particular relevance as it defines the data elements and conformance requirements for actuated traffic signal controllers (ASC).

NTCIP 1202 specification document and accompanied MIBs can be downloaded from

Looking at NTCIP 1202 spec,  various objects are defined in the document in a descriptive, high-level language.  However, in order to do actual NTCIP 1202 related programming and implementation either as a application developer or system architect/designer, or some other signal control hardware-related work,  a *detailed* binary-level understanding of SNMP message is in order. 

This article serves as a personal study note on some of the key points for understanding NTCIP 1202 SNMP messages.  I have had some sort of solid years of experience in computer engineering (hardware and software), and have been working in Traffic Engineering/ITS industry for a couple of years. So I guess this post would be most helpful for someone that has a similar background , while wishing to grab a jump start to some low-level programming and development work dealing with 1202/SNMP messages.

Also I would like to thank Mr. Kenneth Vaughn (an NTCIP expert, of Trevilon Corporation) from LinkedIn NTCIP group, for some of his clarifications and explanations that had helped me a lot while I educated myself on this subject.

To start with,  let’s check out the big picture  about NTCIP framework, which is best exemplified in Figure 1. As shown in this Figure,  the framework has several levels, from the bottom physical levels up to  the topmost information level.  From top most level to the bottom level,  lower level will always add some wrappers (headers) to the higher level information.  We are only interested to levels up to Application Level, which, in the context of this post, is NTCIP 1202 SNMP message.

(Figure 1: NTCIP Framework. source:

(Figure 2: Fields in SNMP Message.  Source:

(Figure 3: A sample SNMP Message.  Source:

An  SNMP message contains a sequence of raw binary bytes, formalized in a well-defined structure (which contains several fields), as exemplified in the above Figure 2.   Figure 3 shows an actual sample of SNMP message:

1. A message starts with 0x30, indicating this is a “Sequence” type message

2.For encoding OID, the node is encoded using the 7 low-order bits of each byte. The high-order bit indicates whether there are more bytes to follow within the node number.

For example, 0x89 0x36, => 1000 1001 (high bit set, look for another byte) 0011 0110 (high bit not set, this is end). Removing high order bits, we get 000 1001 011 0110.
Putting back into two bytes 0000 0100 1011 0110, which is 0x04 0xB6 = 1206 decimal
(thanks to Kenneth Vaughn for explaining and clarifying these to me)

3. The second byte, if the highest bit is not set, i.e., 0, then the byte itself would indicate the Length (number of bytes) that follows in this message. If the highest bit is set as 1, then the low 7 bits indicate the number of bytes that follows which specify the Length of the message.

The length field is encoded as a BER length. The maximal value for this encoding is a length field that starts with the value 0xFE (0xFF is reserved) so the maximal length would be defined by a 126 byte integer, or 2^1008 – 1. (thanks to Kenneth Vaughn for explaining and clarifying these to me).

For example, 0x2C means a total of 44 bytes will follow (the entire length of the whole message, would be 44 + 2 = 46 bytes considering the first 2 bytes 0x30 0x2C)

0x82 0x01 0xB0 would indicate the length is expressed in 2 subsequent bytes, since with 0x82 the highest bit is set as 1. And that gives 0x01B0 = 432 bytes, and therefore the total number of this SNMP message would be 432 + 4 = 435 bytes.

4. Then we have the part on SNMP Version, following the format Type, Length, Value

For example, 0x02 0x01 0x00 means, Integer Type, of 1 byte, value is 0, i.e., SNMP version 1.

5. The following lists the common ASN.1 data types, relevant to SNMP:

Primitive Types


Complex Types






Octet String


GetRequest PDU




GetResponse PDU


Object ID


SetRequest PDU



Hushing the nagging screen from Syncrho Education Version

Synchro Education Edition – has a nagging screen EACH time the software is launched – Until you click “Accept”,  you will be going nowhere.

After “Accept” is clicked,  you will see the main UI water-marked with the line saying “Educational Use Only”.  Also you will experience a noticeable freezing period up to 1 or 2 seconds – the software is surreptitiously checking with a Trafficware server in Texas for any new version available, and verifying the license information.

This Fall semester I am teaching a Traffic Control & Simulation course at NYU-Poly, and get to use the Synchro academic version with some sort of frequency.  This nagging screen is becoming quite annoying to me – not to mention personally I tend to attribute this nagging trick as being somewhat paranoid and pointless, especially when the actual protection with Syncrho is shockingly weak.

I simply don’t like that each time I have to manually click the “Accept” button, in order to proceed. Don’t get me wrong,  this is not that I disagree with the terms,  just I don’t like manually doing it.  I would like to make a tool, and authorize the tool,  representing myself, to Agree and Accept to the license terms by clicking the “Accept”  button for me.

Therefore – with my tool of choice – AutoIt,  I prepared a little nifty script so that each time the software is launched, the computer itself will automatically click the button for me to Accept the terms – I don’t need to bother to move any of my fingers.

Wowooo – La!

The following is download link to the compiled version of the script, just put it anywhere on your computer’s desktop to replace the default Synchro shortcut lnkYou are still going to see the nagging screen appear, so you know what you are going to Accept,  but immediately it will be closed since the script, as authorized by you, and truly you,  automatically click the “Accept” button for you.  Besides,  the version checking window will be immediately closed as well,  and you won’t see the initial 1 or 2 seconds freezing period.  You can always to go to “Help” -> “Check for Updates” to do the explicit version check, yourself.

VISSIM Signal Control DLL SignalGUI Flow Chart

VISSIM provides quite a few interfaces for integrating external signal control logic. A user can use VAP, or, more directly, using the so-called signal control API DLL to incorporate whatever “advanced” control logic he believes.

Oh yeah, believe me, the VAP DLL actually is the same as a normal signal control external DLL, all the 3 exported functions are the same. My guess is that PTV just put an additional VAP script parser for VAP but all the underlying stuff is the same.

Also VISSIM has a RGB editor that is pretty nice but to my great surprise it was developed using .NET without any obfuscation. The Transyt 7F guys are much more wary in that they at least did a little homework obfuscating their IL code. Though obfuscation won’t stop any persistent reverser with perseverance, but still it is better than nothing!

PTV guys! Honk honk! Warning! …….

I have a previous article about the inner workings of VISSIM signal control DLL. So up till now you still don’t know what I am talking about, I whole-heartedly suggest you read that article first.

Togother with Signal Control DLL API, PTV also provide another GUI interface ( in a DLL) for configuring any parameters relevant to the signal control DLL. That is the so-called signalGUI dll.

The signal GUI DLL has pretty confusing control flow if you simply read its code. So I put a little more chart here to help those perplexed.

If you found it useful, for example save your life, save your marriage, or help finish your work quickly and make your boss happy, or get a raise, whatever, don’t forget to drop me an email!

VISSIM Signal Control API: Let’s Talk about it

– This is a re-posted article from my previous one published at Blogline, with minor modifications.

Besides VAP, PTV provides Signal Control APIs for customized external signal control. To be sure, the Signal Control APIs provided by PTV include several header files and C++ source files. These files contains a plethora of information for any interested user to get some hint about the coding style and design patterns implemented in VISSIM simulator.

After studying the source codes for a few days, I am having great fun to read through the APIs and really get a grasp of the intended ideas of PTV developer(s). And, I am willing to share some hints here.


The Signal Control APIs includes the following C++ source file

a. lsa_fehl.h/lsa_fehl.cpp: Utility functions showing various error messages are defined in these files; The messages information can be found from the string resource lsa_ra_e.rc
b. lsa_puff.h/lsa_puff.cp : Core data structures, such as T_DET, T_LSA_PUFFERare defined here.
c. lsa_rahm.h/lsa_rahm.cpp: These two files define some wrapper functions for sc_dll_functions. Mostly in German!  Oh, man! I wish I knew German – but at least, it is still C++ syntax, so couldn’t be worse than reading the bluntly sexy assembly code.
d. lsapuffr.h : Defines various Macros to facilitate the interfacing of VISSIM and the external controller. e. sc_dll_functions.h/sc_dll_functions.cpp : Various functions are defined here to provide read-write access to detector, signal controller, routing information.
f. sc_dll_main.h/sc_dll_main.cpp : the user mostly modifies the call back functions defined here to implement his control logic. This might involve calling the access functions defined in sc_dll_functions.h g. SC_Interface.h/SC_Interface.cpp : the interface functions that connect VISSIM and the controller are defined here.


The most important data structure is the sturct T_LSA_Puffer. This encapsulate Signal Controller Number, and pointers to detectors list. This struct is the building block of a LINKED LIST that contains a list of T_LSA_Puffer.


At the start of simulation, a LINKED LIST of T_LSA_Puffer will be constructed. The element of the linked list is individual T_LSA_Puffer, which corresponds to each individual signal controller, get initialized.

During the simulation, at each controller updating step, through ControllerSetValue function, VISSIM transfers a LARGE NUMBER of data, identified by the MACROS, to the signal control dll. These data is stored two places, one place the those global variables defined in lsa_puff.cpp, the other place is the LINKED LIST of T_LSA_Puffer.

It is important to NOTE, all the utility functions, and the functions defined in sc_dll_functions.h, are actually WRAPPER functions simply to facilitate the read-write of the LINKED LIST! THIS IS THE BEAUTY of the entire API package. I hope somebody can appreciate this like me.

Following this, VISSIM sequentially executes a few more call-back commands to get back the signal timing, specifically, with ControllerGetValue.


The kernel of the Signal Control APIs is actually only two files , i.e., SC_interface.cpp/SC_interface.h. All the other files are wrappers that aim to organize and facilitate the signal timing calculation, read and write of various global variables.

From these Signal Control APIs and the wrapper files, we can get a grasp of the coding style of VISSIM in general and also some hints of the underlying design patters.

Overall, from the External Driver Module APIs as well as from this Signal Control APIs, it can be seen that, the philosophy of VISSM APIs is to use call back functions to expose data while the user have NO access to the internal of the program. This means, VISSIM doesn’t EXPORT any functions that the user can call. All the user can to is to process the data and send back the data to VISSIM via callback again. This allows flexibility on the user side, as he can freely develop wrapper class on top of the data. But the entire process is totally transparent to VISSIM.