New Red and Orange Line Cars

Just to play devil's advocate... they couldn't have used any other track?


Erm...yeah. That's a question that's never sufficiently been answered by the official explanations. I'm kerfuzzled as to why the equal-length Cabot leads couldn't do exactly the trick, but the FCMB claims otherwise.
 
I've been wondering about this too. I don't remember the T building a dedicated test track when the 1800s were delivered. Did they just plonk them onto the rails and send them off?
 
I've been wondering about this too. I don't remember the T building a dedicated test track when the 1800s were delivered. Did they just plonk them onto the rails and send them off?

Cabot leads were how the 01700's and 01800's were tested. It's about 1.2 miles of running track if staying out of the way of Columbia Jct. and the carhouse switches, and has crossovers to keep from fouling other non-revenue movements. That's slightly longer than Track 61 and has actual interlockings on it for signal test.

I'm really not sure why a full running-speed touchup of the lead tracks with maybe another set of crossovers and upgrading the Von Hillen St. unpowered Maintenance of Way yard into a powered inspection shed pocket track wouldn't have sufficed.

But...the FCMB presentations kept saying it must be so. At least it's not useless. If freight service resumes after the re-conversion to FRA-profile rails they'll have spankin' new infrastructure.
 
Still waiting to hear exactly when the new trains will be in use for the Orange Line. Looks like they are taking their sweet time!! :x:x
 
Still waiting to hear exactly when the new trains will be in use for the Orange Line. Looks like they are taking their sweet time!! :x:x

You've got CRRC to blame for that. I have a buddy who is working on validating these, and according to him, this is one issue where the T's only fault is contracting out to CRRC.
 
You've got CRRC to blame for that. I have a buddy who is working on validating these, and according to him, this is one issue where the T's only fault is contracting out to CRRC.


I understand that they had to go with the lowest bidder, but this is too ridiculous!! I'm so sick of these damn delays!! Seem to be ruining everything!! :cry:
 
If the new orange line cars don't enter service in the next few weeks, I think we can safely say that the MBTA is late.
 
If the new orange line cars don't enter service in the next few weeks, I think we can safely say that the MBTA is late.


They already are! First they were supposed to be into revenue service in the fall of last year, then they were delayed until the spring of THIS year, now they're delayed yet again, this time for the summer.

MBTA, get your act together!! These new trains have been long-awaited to make their grand debut, so that we can see the old ones go, & all you're doing is stalling things along to the hilt!!
 
If the new orange line cars don't enter service in the next few weeks, I think we can safely say that the MBTA is late.

Summer officially ends September 23rd... So I expect to see them September 22nd at the earliest... But that "accidental" website update that said end of 2019 wasn't optimistic, hope that wasn't a Freudian slip of sorts...
 
With a more serious tone, I am really hoping that the OL get the new train started already. I have been forgiving based on their reasons they gave. I even see an ironic gain where since the software issue doesn't stop delivery of more train sets, the release of the new trains will have a more impactful feel with the possibility of several rather than just like one trainset joining the fleet.

But patience can only hold up so long. The new trains are just sitting there. We are told no more than it is just software issues but no additional information that let us clue the amount of programming or QA that needs to be done left. We don't know what's failing. We've seen mention of a certification issue but nobody has exactly noted what kind certification is needed currently (I mean what does "internal certification" require exactly - how many ways to test and document results - unless it has been failing critical tests). When it's getting into the 9th month of testing, it's been past the point of just a few failed issues. At this point, they need to fix the hold issue or be honest with whatever issue that keeping the train being used.

In a few weeks, we either getting a very critical sigh of relief that is much need morale booster. Or I think we going to see a level of hostility and anger in our discourse that we haven't seen before. We've been irritated and annoyed by the MBTA's state for a long time, but I do feel public angst and discourse have really risen since the derailment.
 
With a more serious tone, I am really hoping that the OL get the new train started already. I have been forgiving based on their reasons they gave. I even see an ironic gain where since the software issue doesn't stop delivery of more train sets, the release of the new trains will have a more impactful feel with the possibility of several rather than just like one trainset joining the fleet.

But patience can only hold up so long. The new trains are just sitting there. We are told no more than it is just software issues but no additional information that let us clue the amount of programming or QA that needs to be done left. We don't know what's failing. We've seen mention of a certification issue but nobody has exactly noted what kind certification is needed currently (I mean what does "internal certification" require exactly - how many ways to test and document results - unless it has been failing critical tests). When it's getting into the 9th month of testing, it's been past the point of just a few failed issues. At this point, they need to fix the hold issue or be honest with whatever issue that keeping the train being used.

In a few weeks, we either getting a very critical sigh of relief that is much need morale booster. Or I think we going to see a level of hostility and anger in our discourse that we haven't seen before. We've been irritated and annoyed by the MBTA's state for a long time, but I do feel public angst and discourse have really risen since the derailment.

Age of Software in Everything, Everywhere you turn and its consequences

But patience can only hold up so long. The new trains are just sitting there. We are told no more than it is just software issues but no additional information that let us clue the amount of programming or QA that needs to be done left.

Unfortunately we are in the leading edge of the transition from hardwired and mechanical systems which we have learned about over the centuries and which can be Exhaustively Tested -- to systems relying upon extremely complex real-time software -- Which by dint of their complexity -- Can Not be Exhaustively Tested

Take a look at the Boeing Max 737 which has been promised that it is really ready for passengers how many times in the past few months

A slight digression -- a couple of observations about system complexity and reliability:

Class One:
The system is mechanical or electrical in its intrinsic nature [even if there are embedded computational components within individual electro-mechanical modules]. The number of parts that can fail is finite and the result of a single component failing is in general bound-able. Though even in pure mechanical or electro-mechanical systems cascading failures can and do occur -- think bridges and building collapses, trains derailing because of bad wheels or rails, or old-style electric power outages caused by falling wires.

Class Two:
The system while having mechanical and electrical elements [for its external physical interactions] is primarily composed of hundreds of software modules each of which is in turn composed of other modules and ultimately millions of lines of code. The mechanical response of the system depends on the proper measurements being made by a large number of sensors and the resultant real-time digital information being properly processed and the results of all of this computation being used to control a large number of electro-mechanical actuators -- [very simple example: think the anti-lock brakes on a passenger car. The number of individual components while still finite is so massive -- that the number of combinations of interacting pairs of components becomes astronomical. Unfortunately, the possible modes of failure of any one of the enormous number of the individual components to respond correctly to a similarly massive range of sensor inputs [system stimuli] becomes multiplicatively enormous. Now because the interactions occur inside computer memory the potential for cross-connected failure modes [even in just pairs of components] is nearly uncountable. Testing is only able to explore a very small part of the system space with failures of minor software "parts" often bringing everything down. This includes the introduction of replacement modules [designed to fix known local problems] -- Think your experience with Microsoft Windows on any device.
"Don't turn off your PC the system is updating X_XX modules"

Today's systems of all types are rapidly becoming All Class Two with implications for reliability and testing which we are not yet coming to grips both professionally and society-wise. Now we throw into this mix the exposure of the system to external interconnections and the corresponding external inputs [both accidental and intentional] -- think the Internet of Everything aka Hacker Heaven .

The T is replacing all of the old and reliable -- if getting "long in the tooth" -- Class One equipment with sparkling, jazzy Class Two trains, switches, signaling, etc., -- all the replacement being motivated by the the promises of: improved efficiency, lower operational costs, easier maintenance, and increased capacity. However with all that comes the issues of testability and unpredictable failures due to interactions of myriads of lines of embedded software with the outputs of a multiplicity of sensors and external network stimuli.

The alternative is to go back to the PCC era of the Green Line when you could "smell the failing parts" as they heated up.
 
Last edited:
FWIW, David Perry, an MBTA (commuter rail?) project manager hinted at this month (August) for the first revenue service on his Twitter last week. https://mobile.twitter.com/FramWorMBTA/status/1157079975390044164

More from Dave Perry today. Apparently a station attendant told a little kid maybe this week:

https://twitter.com/FramWorMBTA/status/1160232489895505921?s=20

David Perry @FramWorMBTA
Leave it to the little kids to get the inside scoop... (re: in-service date for new orange line trains) https://twitter.com/nofunfinn/status/1160211375580430336
Twitter | Today at 12:52 PM

Finn @nofunfinn
@FramWorMBTA @spoftak There's one currently berthed at Oak Grove. My four year old asked if we could ride it; the staffers there said possibly this week(!)
 
So this weekend the T has been running a new train set on the Orange Line, including ferrying some T employees between stations.

Good News: new train set running on the line (not revenue service).

Bad News: the trains were slotted into the service schedule just like a passenger service train. So announcements seemed to indicate a revenue service train in say 9 minutes. But then the train that arrived is not ridable. I got hit by this twice yesterday, resulting in 20 minute waits for a passenger service train! WTF MBTA!
 
Makes you miss the old "Driven by Customer Service" thread title :lol:
 
Yep, some people on Twitter found them out yesterday running and testing through the switches b/t Ruggles and Mass Ave since there is a weekend shutdown from Ruggles to Forest Hills and trains have to short turn there... Correctly headsigned, appeared on tracking apps and countdown signs, so close to ready but I can't wait to get my hopes dashed tomorrow at the FMCB meeting. If there's good news it'll be during the GM report at the beginning, if there's bad news it'll be hidden in the written submittal for the RL/OL program update. Both are on the agenda currently
 
:eek:
Age of Software in Everything, Everywhere you turn and its consequences



Unfortunately we are in the leading edge of the transition from hardwired and mechanical systems which we have learned about over the centuries and which can be Exhaustively Tested -- to systems relying upon extremely complex real-time software -- Which by dint of their complexity -- Can Not be Exhaustively Tested

Take a look at the Boeing Max 737 which has been promised that it is really ready for passengers how many times in the past few months

A slight digression -- a couple of observations about system complexity and reliability:

Class One:
The system is mechanical or electrical in its intrinsic nature [even if there are embedded computational components within individual electro-mechanical modules]. The number of parts that can fail is finite and the result of a single component failing is in general bound-able. Though even in pure mechanical or electro-mechanical systems cascading failures can and do occur -- think bridges and building collapses, trains derailing because of bad wheels or rails, or old-style electric power outages caused by falling wires.

Class Two:
The system while having mechanical and electrical elements [for its external physical interactions] is primarily composed of hundreds of software modules each of which is in turn composed of other modules and ultimately millions of lines of code. The mechanical response of the system depends on the proper measurements being made by a large number of sensors and the resultant real-time digital information being properly processed and the results of all of this computation being used to control a large number of electro-mechanical actuators -- [very simple example: think the anti-lock brakes on a passenger car. The number of individual components while still finite is so massive -- that the number of combinations of interacting pairs of components becomes astronomical. Unfortunately, the possible modes of failure of any one of the enormous number of the individual components to respond correctly to a similarly massive range of sensor inputs [system stimuli] becomes multiplicatively enormous. Now because the interactions occur inside computer memory the potential for cross-connected failure modes [even in just pairs of components] is nearly uncountable. Testing is only able to explore a very small part of the system space with failures of minor software "parts" often bringing everything down. This includes the introduction of replacement modules [designed to fix known local problems] -- Think your experience with Microsoft Windows on any device.

Today's systems of all types are rapidly becoming All Class Two with implications for reliability and testing which we are not yet coming to grips both professionally and society-wise. Now we throw into this mix the exposure of the system to external interconnections and the corresponding external inputs [both accidental and intentional] -- think the Internet of Everything aka Hacker Heaven .

The T is replacing all of the old and reliable -- if getting "long in the tooth" -- Class One equipment with sparkling, jazzy Class Two trains, switches, signaling, etc., -- all the replacement being motivated by the the promises of: improved efficiency, lower operational costs, easier maintenance, and increased capacity. However with all that comes the issues of testability and unpredictable failures due to interactions of myriads of lines of embedded software with the outputs of a multiplicity of sensors and external network stimuli.

The alternative is to go back to the PCC era of the Green Line when you could "smell the failing parts" as they heated up.

Also, in the case of the lithium batteries on the Boeing 787 -8 Dreamliner, where the batteries kept heating up & catching fire. They had to come with a quick & permanent fix to keep the plane safe, or they would end up grounding it forever!! :eek:
 

Back
Top