TTC: Other Items (catch all)

[Bordercollie]

The fact that there is only one server that operates the entire signalling system is appalling. There is no backup?
Also it would be smarter to have different parts of the system be broken down into different servers so you dont have a catastrophic failure like what happened.
Zero foresight. Zero backup plan. Horrible communication. Zero accountability. At least refund everyone who tapped their card before noon. That would be a start.

 

[TTCdinosaur]

Please see the post directly below yours:

I'd love to see Metrolinx give an analyses on why we don't have an official opening date for the crosstown and finch LRTs. Oh right they don't care.

? This is the same as them saying there are "software issues" with the signaling system on the LRT. I'm sure the TTC will follow-up with a "repair plan" as well and give me vague percentages about its progress. It's okay - after many decades I see so many TTC apologists and yet the system continues to rot and decay. And it's always the Mayor's fault, or the Premier's fault, etc.

I'm not saying Metrolinx is better - but this impulsive response to the defend the TTC is unbearable as they have proven time and time again that they don't really respect riders. Well except for the Byford era, but the union rejected that.

 

[EastYorkTTCFan]

You can tell that Rick Leary is no longer running things by this one post.

yeah it reminds me of when Breoad Ross would post just about anything when people would ask him on twitter

 

[Bordercollie]

? This is the same as them saying there are "software issues" with the signaling system on the LRT. I'm sure the TTC will follow-up with a "repair plan" as well and give me vague percentages about its progress. It's okay - after many decades I see so many TTC apologists and yet the system continues to rot and decay. And it's always the Mayor's fault, or the Premier's fault, etc.

I'm not saying Metrolinx is better - but this impulsive response to the defend the TTC is unbearable as they have proven time and time again that they don't really respect riders. Well except for the Byford era, but the union rejected that.

They are not apologetic. They just said that they are "also very frustrated".

 

[CapitalSeven]

Everything we are hearing about system problems in transit reminds me of that excellent documentary about the new space telescope. There were hundreds of points of failure, any of which could ruin the deployment. It was a miracle it succeeded.

It seems the boffins have built systems that are so safe, if anything goes wrong they all shut down. No backup, no redundancy, no run by line of sight. Just sit and do nothing. It's nearly impossible to get new lines up and running, and older ones are made less reliable for users in the name of progress. There's clearly such a thing as too much technology, and the current generation of engineering is failing us, not fit for purpose.

 

[allabootmatt]

Everything we are hearing about system problems in transit reminds me of that excellent documentary about the new space telescope. There were hundreds of points of failure, any of which could ruin the deployment. It was a miracle it succeeded.

It seems the boffins have built systems that are so safe, if anything goes wrong they all shut down. No backup, no redundancy, no run by line of sight. Just sit and do nothing. It's nearly impossible to get new lines up and running, and older ones are made less reliable for users in the name of progress. There's clearly such a thing as too much technology, and the current generation of engineering is failing us, not fit for purpose.

You've put your finger on something I have been wondering about. When it comes to transit, at least, what has the last 50 years of technological development actually gotten us? The Crosstown is apparently paralyzed by software issues and broader problems of systems integration. And yet the original Yonge and Bloor subways were built, delivered and run for decades with nothing more sophisticated than a slide rule. "Software" barely existed. Go back further, to the birth of the systems in Paris, London and New York, and it's an even bigger gulf.

OK, it's obviously good to have elevators and modern fire-suppression systems. But apart from a few safety-related changes, what are the real benefits of the current model, exactly? And if such benefits are real, but they mean every project takes 2-3x as long to build, and is then 2-3x like likelier to fail when some aspect of the tech goes down, what's the point?

I am increasingly of the view that public procurement, probably for more than just transit, needs to be re-oriented to prioritize systems that are simple, robust and above all deliverable.

 

[smallspy]

The fact that there is only one server that operates the entire signalling system is appalling. There is no backup?
Also it would be smarter to have different parts of the system be broken down into different servers so you dont have a catastrophic failure like what happened.
Zero foresight. Zero backup plan. Horrible communication. Zero accountability. At least refund everyone who tapped their card before noon. That would be a start.

The computer that failed was a dispatching computer, not a signalling one. So this failure could have just as easily happened on the B-D or Sheppard as it did on the YUS. As to why? They're looking into that.

The signalling system on the YUS is broken out into several firewalled parts, which is why when it fails only a smaller section of it goes down.

Dan

 

[evandyk]

On Tuesday evening, my packed NB train didn't stop at St. George. They said there was a "security incident" but the platform was full of people just waiting for the next trains. So a packed train gets dumped at Spadina to transfer to Line 2. Of course, the stairs to the tunnel at Spadina are being renovated so they're limited to the width of two people. I have no idea how long it would have taken for everybody on that platform to get up those stairs one by one, because I went out the Lowther exit and walked down to Bloor outside.

 

[Bordercollie]

The computer that failed was a dispatching computer, not a signalling one. So this failure could have just as easily happened on the B-D or Sheppard as it did on the YUS. As to why? They're looking into that.

The signalling system on the YUS is broken out into several firewalled parts, which is why when it fails only a smaller section of it goes down.

Dan

So then how did the entire line go down?

 

[Jonny5]

So then how did the entire line go down?

I would imagine it didn't, but if a particularly large enough section freezes at rush hour, there's no slack for trains to move forward in the scheduled service level.

Yes, you could initiate procedures to have turn-backs and such, but this sounds like it was in the grey area of the decision matrix where you are told "it will be somewhere between 15 and 45 minutes," so you have to make the decision; do you implement complex, higher risk operating procedures to arrange for turn-backs and short turns, and also make a call for shuttle buses because it could be 45 minutes, or do you decide to hold everything and wait it out in case it's only 15 minutes? You have to decide on one or the other immediately. You have 30 seconds to make the call after receiving the information. They chose to hold and wait it out.

 

[Bordercollie]

I would imagine it didn't, but if a particularly large enough section freezes at rush hour, there's no slack for trains to move forward in the scheduled service level.

Yes, you could initiate procedures to have turn-backs and such, but this sounds like it was in the grey area of the decision matrix where you are told "it will be somewhere between 15 and 45 minutes," so you have to make the decision; do you implement complex, higher risk operating procedures to arrange for turn-backs and short turns, and also make a call for shuttle buses because it could be 45 minutes, or do you decide to hold everything and wait it out in case it's only 15 minutes? You have to decide on one or the other immediately. You have 30 seconds to make the call after receiving the information. They chose to hold and wait it out.

A simple solution would be to if the delay exceeds X minutes they should initiate short turn protocol. Instead of running shuttle buses to get people down yonge st it may be smarter to help shuttle people east or west depending on where the issue is. Clearly it's a mismanagement issue more than anything. Asleep at the wheel basically.

 

[smallspy]

So then how did the entire line go down?

Because it was a dispatching system, as I said. It dispatches all of the trains along the line, and the signal system ties into it to allow for permission according to the schedule.

A simple solution would be to if the delay exceeds X minutes they should initiate short turn protocol. Instead of running shuttle buses to get people down yonge st it may be smarter to help shuttle people east or west depending on where the issue is. Clearly it's a mismanagement issue more than anything. Asleep at the wheel basically.

This is already in place. But it wasn't applicable here.

Dan

 

[AlvinofDiaspar]

You've put your finger on something I have been wondering about. When it comes to transit, at least, what has the last 50 years of technological development actually gotten us? The Crosstown is apparently paralyzed by software issues and broader problems of systems integration. And yet the original Yonge and Bloor subways were built, delivered and run for decades with nothing more sophisticated than a slide rule. "Software" barely existed. Go back further, to the birth of the systems in Paris, London and New York, and it's an even bigger gulf.

OK, it's obviously good to have elevators and modern fire-suppression systems. But apart from a few safety-related changes, what are the real benefits of the current model, exactly? And if such benefits are real, but they mean every project takes 2-3x as long to build, and is then 2-3x like likelier to fail when some aspect of the tech goes down, what's the point?

I am increasingly of the view that public procurement, probably for more than just transit, needs to be re-oriented to prioritize systems that are simple, robust and above all deliverable.

It's not the first time - remember back in 2015 when a really minor technical issue ended up bringing down the entire comms system:

All subway service has resumed, TTC says

Subway service has resumed on all lines after earlier radio communication issues, the TTC said on Monday.

toronto.citynews.ca

AoD

 

[KevinT]

They are arguably too sensitive however. Early on, a pan drop was considered a major fault and required the car to be removed from service immediately. I guess that they've finally realised that there is no damage to the pantographs when this happens, and so the car (in most cases) can switch to the pole and have its pantograph inspected later.

Isn't all the new wiring panto-only now instead of the pole-and-panto hybrid plan that had them adding ears to all the frogs? That throws a wrench into the "switch to the pole and inspect the panto later" backup plan...

 

[DSC]

Isn't all the new wiring panto-only now instead of the pole-and-panto hybrid plan that had them adding ears to all the frogs? That throws a wrench into the "switch to the pole and inspect the panto later" backup plan...

Yes, not quite all has been converted yet but in due course poles will simply not work (or only on the straight sections of overhead! (For pantos the wires are also not completely straight so that the contact point on the panto changes and it wears out all over and not in one spot. That too would probably confuse the poles!)