Archer

Because Emergency Mode exists.

I can't be the only one who hates Metrolinx's overuse of white for walls / ceilings / floors. It's not an operating theatre...

SSE has no bearing on T1 replacement - the SSE is being designed with block signals, albeit with some provisions for future ATC upgrades. Steve Munro covers this: https://stevemunro.ca/2022/10/11/will-line-2-renewal-ever-happen/

They literally have a full and current list of them on their website. Granted, it's not front and center on it, but they have a list they are keeping up to date: https://www.ttc.ca/service-advisories/subway-service/Reduced-Speed-Zones And of the ones on that map, the NB College to Wellesley, NB Museum to St George, EB Old Mill to Royal York, and WB Royal York to Old Mill restricted speed zones have cleared. They are out there working on them. I would have to imagine they're getting close to being done on the ones Spadina to King, given the early closures they've been doing.

I would be extremely surprised if Vancouver isn't already on that. I'm sure that they've been watching very carefully from the moment the derailment hit the news.

Testing has started - we have seen a few of the vehicles out there. They did show a graphic in the powerpoint (can't find it now, unfortunately) that shows the construction is near completion - it's the testing and systems integration that is the issue now.

Gotta say, it was a pretty nice thing they put together for the SRT today. Also heard Councillor Thompson make a remark about making sure at least one train set gets saved, so it looks like there's some political will to preserve something.

Yes you can, since both the auto entrance and main entrance are open. They have the stairs to SRT platforms barricaded off, though.

That would be why the power was turned back on.

I can see exactly where the runs are at a given time. Again, there was no such traffic going in to Kennedy at midnight on March 10. No train held for 5 minutes at VP. No train held outside Warden for 5 minutes. No train held for 4 minutes at Warden, and no one from Control would have ever told a train to "hold for 240 seconds", in those words. At no point was there a train in the tail tracks at Kennedy that night. The incident, as you have described it, did not happen. There was a backup at Kennedy at Noon, and was recorded appropriately.

I have the ability to review the real-time subway data and decided to take a look. I checked the data for last night, from 10:00PM on Friday March 10 to 2:30AM on Saturday March 11 and at no point could I find the backup that you were describing; the system ran between VP and Kennedy with no delays in that timeframe. I repeated the check for Thursday March 9 into Friday March 10, with the same times, and couldn't find this occurrence in that timeframe either. You gave a time of 12:30AM. There was no such delay at that time within the last 48 hours.

Generally speaking, once a runthrough happens on the subway, Signals will attend and determine exactly what needs to be done, and this is usually concurrent to the Supervisory investigation. Subway trains are heavy enough that they will normally shove the points to the position they need without derailing, assuming all proper guarding rails are in place. As part of the Signals work, that crew will get the switch back into the position that allows them to restore service (ie. make it safe), cut out power to the machine, and physically clamp the points closed so they can't move. TTC can usually recover from a switch runthrough within an hour or two, and passenger service will resume. Repairs won't be made until after service, so they can also perform all of the maintenance tests they need to do to certify the switch for operation again. The actual repair usually doesn't take long since most switches in the subway system do have dedicated failure points for exactly this reason. It gets significantly more complicated if it's a double-slip switch (only one on the mainline), or a movable point frog (again, only one on the mainline and it isn't traversed in normal operation), just because of the nature of those switch layouts. Note that I'm not including wye tracks as part of the mainline in this case.

It was a thing for a bit when the operator washrooms at Finch were out of service for repairs. The shuttle crew would take it so the regular operators had time to use the washrooms at Sheppard. But it wasn't pre-planned, just a reaction to emergency repairs. Exact point the tail tracks end is here: https://goo.gl/maps/abF2zbB71NGQ4Bz69

Unfortunately.

Only three mid-line crossovers, and no center/pocket tracks where you can hide a disabled train? Seems to me that they're going to constrain their operations as soon as something happens outside of "normal operations". There should at least be another crossover just west of University Ave so that you can still link up Exhibition to the University leg of Line 1 if there is an issue that takes Queen/Yonge out of the mix. I also don't see why they're putting the mainline-side terminal crossovers so far from the stations. If something happens to the tail-side crossovers, there's no way they'll be able to maintain 90 second headways (which are wildly optimistic anyways) with such large zones of conflict on the mainline side.

You put far too much faith in the Alstom engineers. My first hand experience, having worked with them, is that they are abysmal engineers and have utterly no idea how their software and control systems work. The number of times they have been unable to explain why things happen in the system is unbelievable. Now, some of that may come from the fact that TTC didn't go with the Iconis front-end, instead going with a hybridized version that is similar to the existing legacy signalling interface. But there's utterly no reason why Alstom, who made the entire interface, are utterly clueless as to how it works.

Not intentional, but it certainly isn't going to improve the workforce's opinion of the management team that just managed to lose the private, confidential information of their entire workforce.

Funny that was their priority, since they haven't bothered to try and fix the pay system to ensure that everyone gets paid properly. ?

Probably because it isn't that simple. The TTC isn't just a bunch of servers; I imagine there are thousands of desktop PCs and laptops on the network as well. All it takes is one of those machines to still be compromised, and you're back to being hacked. I imagine IT has literally pulled the plug on the network to ensure that everything is isolated from one another, and are slowly going through and checking each device one by one before even thinking about reconnecting. Plus, law enforcement is going to be involved, and are going to want forensic data to comb through, so you can't even just wipe-and-reload the servers with the backup because that'll destroy the data they want preserved. And all that assumes your backups aren't compromised to begin with...

Web development has been moving away from separate desktop & mobile versions to a unified design system, in part because you're not having to maintain two separate sites. This isn't unique to the TTC website. Unfortunately, desktop & laptop users these days are the minority. Most people looking at websites are on mobile devices; this is well known among the web development community (we have the analytics data), and designs are now reflecting that. Even my own personal website, which was designed with only desktop in mind, sees about half of it's traffic come over mobile devices.

For those interested in the signal side of things, ATC is live up to Eglinton Station as of yesterday. The crossover at St Clair is also now fully signalized and usable as part of the ATC expansion.

You can see the vent shaft surfacing at the corner of Barrington and Coleman. That shaft is just east of the platform end gate.

I think everyone needs to read this so we're all on the same page: https://www.ttc.ca/About_the_TTC/Commission_reports_and_information/Commission_meetings/2021/June_16/Reports/15_Transit_Systems_Engineering_Osgoode_Interlocking_Incident.pdf. MAN mode is a fully manual mode, even on the TRs - think Emergency Mode on the SRT, as there needs to be a mode where you can override the system completely as an absolute fallback (ie. complete loss of the signal system with trains trapped in tunnels). When a train is in MAN mode, it reports it's position and speed to the system controller. That's it. There is a speed restriction imposed on the train as well, but I believe that is done by the controller on the train. The ATC system is not able to apply the brakes when a train is in MAN mode regardless of what that train does, which is why there are stringent procedures regarding moving of trains in MAN mode. There are no hard limits in MAN mode; a MAN mode train is capable of violating any limits that might exist (red signals, switches not set for route, occupancy, etc). A degraded mode (Restricted Mode, RM) does exist, but as far as I know it is not utilized in any capacity. I don't know why it isn't used. Osgoode pocket had some level of ATC as it could see the train when the incident occurred, but couldn't operate it in any of the ATC modes. It wasn't disabled, but it also wasn't fully operational. Because 123 Run was in MAN mode when it violated the interlocking, the system was unable to stop it with a brake application. My understanding is that the system did see 123 Run violate the interlocking with the crossing the axle counters. In theory, the system could have stopped 114 Run on the mainline as it was in an ATC mode; I don't know if it did try or not. I also don't know if, realistically, it could have stopped 114 Run in time to have avoided a collision, given the momentum these trains have.

This was literally posted two posts above.

To the best of my knowledge, TYSSE was the first time that TTC did not go with tie on ballast for any of their interlockings. Anything prior to that is still tie on ballast.