News   GLOBAL  |  Apr 02, 2020
A Message to Our Readers
 10K     0 
News   GLOBAL  |  Apr 01, 2020
EarthCam Time-Lapse Documents Rafael Viñoly-Designed New Stanford Hospital Construction
 42K     0 
News   GLOBAL  |  Apr 01, 2020
Resort Town
 6K     0 

TTCdinosaur said:
? 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.
Click to expand...
They are not apologetic. They just said that they are "also very frustrated".
 
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.
 
CapitalSeven said:
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.
Click to expand...
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.
 
Bordercollie said:
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.
Click to expand...
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
 
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.
 
smallspy said:
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
Click to expand...
So then how did the entire line go down?
 
Bordercollie said:
So then how did the entire line go down?
Click to expand...
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.
 
Jonny5 said:
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.
Click to expand...
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.
 
Bordercollie said:
So then how did the entire line go down?
Click to expand...
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.

Bordercollie said:
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.
Click to expand...
This is already in place. But it wasn't applicable here.

Dan
 
allabootmatt said:
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.
Click to expand...

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

toronto.citynews.ca

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 toronto.citynews.ca

AoD
 
smallspy said:
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.
Click to expand...

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...
 
KevinT said:
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...
Click to expand...
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!)
 
Not too sure where to put this, but after a service disruption this morning due to "emergency rail repairs" Kipling-bound Line 2 trains seem to have slowed down after leaving Warden once again.
 
Last edited:
You must log in or register to post here.

Back
Top