Transit Signal Priority (TSP) is one of the most cost-effective approaches to enhancing the effectiveness and efficiency of transit operations. However, while many TSP implementations have minimal impact on non-transit vehicle travel times, there are cases where TSP deployments have created additional delay for non-transit vehicles. In|Sync’s goal is to actively handle TSP requests to both improve transit travel time efficiency and minimize impact to normal traffic operations. It does this through the use of several priority strategies.
In|Sync supports continuous TSP signals captured through recognized I/O devices. It does not support TSP devices that produce a pulsating or intermittent signal — but pulsating signals can be converted to a continuous signal within the Priority software.
With In|Sync, traffic professionals can change TSP priority at an intersection based on the goals for the configuration, all because In|Sync treats TSP as another form of demand. It doesn’t cause traditional “transition” scenarios that some TSP solutions generate, and all coordination, early release settings, geometry restrictions, etc. are adhered to while TSP is active.
In addition, In|Sync employs a real-time, active priority strategy in only responding to actual TSP calls from an intersection in order to serve that transit vehicle. It does not support a passive strategy in which signals are adjusted based on pre-defined transit schedules.
TSP at a Local Intersection Level
In|Sync handles TSP on a local intersection level, and not at a global level. This means that if a TSP call is received at one intersection, it doesn’t affect the time along a tunnel across intersections. In|Sync’s behavior is determined by how TSP is configured within In|Sync. When TSP is activated, In|Sync performs a combination of the following behaviors:
1.Prioritize the currently active TSP phase.
In|Sync serves the phase in which the TSP signal call is received. It does this by prioritizing the sequence or by determining where extra time exists in the period and allowing extra servicing of the phase receiving the TSP call. This feature allows In|Sync to flexibly choose to prioritize the TSP phases with the goal of minimizing impact to other movements.
2. Extend the currently active TSP phase.
If time in the period and configuration allows for additional service of the TSP phase without impacting other phases, In|Sync automatically extends the currently active TSP phase. This feature allows In|Sync to “hold” the TSP phase longer than originally intended to allow the transit vehicle to get through the intersection.
3.Create demand on a phase when TSP is active but no vehicle queue exists.
In|Sync brings up the empty movement when no vehicles exist in anticipation of the arrival of the transit vehicle.
4.Eliminate extensions on non-TSP phases during TSP actuation.
In|Sync schedules time to service other phases at the intersection but does not hold additional time for late arrivals or higher-than-anticipated demand. This promotes an “early return” to green for the TSP phase. In|Sync then determines which phase demands service and serves that phase.
5.Gap out non-TSP phases during TSP actuation.
In|Sync terminates any active non-TSP phases at the intersection, allowing the system to then determine which phase requires service. This method heavily promotes an “early return” to green for the TSP phase.
In|Sync gives priority to the TSP movement as part of its normal green time allocation. It does not step out of its plan to serve a TSP movement and then struggle to get back in step with other intersections; instead, it stays coordinated throughout the TSP call and service. In normal operating conditions, the In|Sync algorithm chooses which phase pair to serve based on how many vehicles are waiting and how long they have been waiting, where more vehicles and longer wait times equals higher priority. When configuring TSP inputs within In|Sync, you assign the same type of priority of service to each type of TSP signal. In|Sync has four different TSP levels: Off, Low, Medium and High.
No special treatment
When a TSP signal is received, the phase receiving the TSP signal is extended if it is currently being served and time exists in the configuration. This serves the TSP phase sooner and allocates more time to the phase.
When a TSP signal is received, the phase receiving the TSP signal is extended if currently being served and time exists in the configuration. It also stops any other phase from extending beyond its scheduled time during a TSP call. This causes the system to serve other movements faster, cutting them off at their scheduled time, even if additional vehicles are present for that movement.
When a TSP signal is received, the phase receiving the TSP signal is extended if currently being served and time exists in the configuration. It also cuts the scheduled time for other non-TSP phases to the minimum green. This priority stops service on other phases before all demand for that movement is served.