reaperexpress
Senior Member
I'm using general phrases for any batch processing.
What the City now has (at least for King Street) is a *fixed time frame sequence* as best as I can gather, the intersection signal times are fixed in duration, with any 'priority; having to be a further time division within that fixed parameter. Not considering other dynamic and real-time needs.
Sort of. The signals operate with pre-programmed green times when there is no streetcar around.
If there is a streetcar, the priority system is designed to abandon the normal timings and take whatever actions it has been permitted to take to get the streetcar through faster. The only limitations on the actions are those dictated by the City at the particular intersection (well, that and the amount of data storage space in the signal timer for that particular parameter so technically you can't program more than a 255-second green extension or something). Typically streetcars are permitted to extend the green by up to 30 seconds. At some intersections, signals are only permitted to take certain low-impact actions (such as a short green extension), but is not allowed take other actions such as shortening the green for the cross-street, changing the order of phases, inserting extra phases etc. That way the signal maintains pretty much its 'normal' signal operation even during priority requests. Meanwhile at other intersections such as the high-priority ones I listed above, the priority system is pretty much unrestricted.
I'll try and find the City's actual details and methodology for their King pilot area intersections. There may be magnetic loop sensors that have some input, whether that is time division within fixed frames or actually a dynamic elasticity to stretch and shrink those frames on an input sensing basis is a good question, and layered on that: What input does the TTC now have save for a priority (keyed or not) in the light sequence?
This presentation covers the basic technical elements of the TTC's signal priority system. Basically, there are loop-shaped antennas in the ground which listen for a radio signal from the transponders installed on the bottom of all TTC streetcars and buses. Next time you're walking downtown keep an eye out for a black rectangle in the crosswalk between the streetcar tracks - that's usually the 'cancel' loop for that intersection, which tells the signal that the streetcar has successfully entered the intersection and normal signal operation can resume. There's a corresponding 'call' loop in advance of the intersection that tells the signal that a streetcar is on its way (the signal's actions are based around an estimate of how long it will take the streetcar to get from this loop to the cancel loop).
The timings for signals are sort of quasi-public. You can request any signal's timing from the City, but you have to pay for it to cover the administrative costs. But then again, you could just film the signal for an hour during the time of day you want to figure out, then measure the green times when during a period where there hasn't been a streetcar for a while and there isn't one approaching (i.e. the normal timing), then compare to what the signal does when there is a streetcar that sits there for a long time, maxing out the priority system.
Let me project farther from that: To affect optimal flow and efficiency of the King streetcars will necessitate *over-riding* entire assigned sequences at intersections. This may only be needed for the occasional need to get an interrupted or otherwise out of synch King schedule/headway/interval back onto what is deemed 'optimal'. That would be a dynamic correction, and it adds another depth of control to otherwise limited proactive abilities on King at present, or during the pilot.
I leave it at that until I can get more info on what is extant and what is needed to bring this pilot into the here and now...
The current system already does what you describe, by over-riding the signal timings and synchronization if necessary (and often even when not necessary, given the unpredictability of near-side stops), then getting back into sync after the streetcar leaves. This is known as 'pre-emption', as the City's policy calls it (large PDF). However it does not receive information about the streetcar, such as its route, headway, schedule adherence etc. The signal can calculate the headway, by timing since the last streetcar went through, but this doesn't account for the fact that there are different streetcar routes with different scheduled headways along King. Maybe the compromise would be to grant priority to streetcars with a headway of a least 90 seconds or so. That way streetcars are mostly able to stick to the irregular shape of the schedule, but they are prevented from getting particularly close to each other. This would be a lot like the basic subway block signals, which are always green unless you start to get really close to the train in front (except at timing points, where the signals actually dispatch trains based on the schedule/headaway).
Last edited: