Freezing rain today.

So, what does that mean for trains and passengers?
 
For trains, it means the electric window defrosters need to be 100% working. When drivers switch ends, the trailing cab gets no intervention from the operator. Ice buildup is a visibility issue.
 
The windshields have electric defrosters and forced air hvac systems to keep them clear.

Trains have sanders at the wheels to throw grit on rails for added traction.
 
The trains may get some ice buildup on exterior windows. Stay back from platforms as trains enter, you may get thin ice falling from the roof or windows as the doors open. I noticed this mostly in the tunnel last year. Nothing major, but it's something to look for.
 
The tracks themselves don't see much in the way of ice buildup. Our headways run at about 4 minutes, so the tracks get de-iced by the wheels of the trains. Switch crossing can be a little noisier at the lesser used switches.
 
The switches have forced air heating, and are pretty efficient at clearing themselves from falling snow and ice. The metal rails stay warm and clear around the moving rails.
 
Platform surfaces at stations are also heated, and should be ice-free. Staff is on site to report degrading conditions, and RTM has staff dedicated to clearing snow and ice.
 
You may notice some arcing from the overhead wires as trains pass by. Some ice buildup always occurs on the overhead wires, and these little buildups create gaps that cause arcing. It looks pretty cool at night!
 
I fielded a phone call about arcing a few weeks ago explaining the power gap to a customer near Hurdman. It's normal on an overhead system. Small gaps create flashes. At night, those flashes are bright full of colour.
 
Overall, the trains should run way better than the road traffic on a big ice day.
 
 

Ever wonder... Who's that fine folk at the front of the train, and what do they do anyway?
 
We call them EROs. Electric Rail Operator, fully completely. All are long time transit pros who took a real career risk giving up the perks of bus seniority to take a highly scrutinized, highly regulated position in rail.
 
Like bus drivers, these folk are the front line decision makers for the service. They are the eyes, ears, and hands of the system. Each decision made on the line flows through the ERO. They are highly trained and highly skilled.
 
It all begins with Rail Rules. I remember my first meeting with the chief safety officer about becoming an ERO. He told me that the rules of rail are written in blood.
 
Each rule has a story from another rail system behind it, and some of those stories are obituaries. It's a sobering thought, and a good reminder of what safety means in different contexts.
 
Once an ERO is rules trained, the skills needed to drive a train are developed. Some simulator work, lots of driving on tracks, and plenty of troubleshooting training is next.
 
Like any train, there is no steering wheel. On the Citadis train, the ERO uses a traction handle to move the train forward and to brake. Push it forward, it applies traction (think gas pedal). Pull it back, it applies braking.
 
During regular service, our trains run a CBTC signaling system. What this means for the ERO is that they can allow traction and braking to be automatically micromanaged by train, while they focus on making the safety decisions for the service.
 
EROs receive training in standard first aid as well as mental health first aid, suicide prevention and services advocacy.
 
EROs will brake the train when necessary and take over any time they see an issue, such as a passenger acting oddly on a platform or a person on the tracks.
 
EROs will make completely manual movements too, both as practice and in times when troubleshooting is needed, or tracks need to be swept for possible problems.
 
Troubleshooting is a huge part of their job. Brake faults, door faults, medical emergencies, resets of systems.. All things that an ERO does to keep you moving. When an ERO comes across a problem that can't be reset, Alstom steps in.
 
EROs are experts in infrastructure too. They report any issues with tracks and power systems. Their knowledge is key to maintaining the system.
 
When a delay occurs, EROs coordinate to switch drivers at terminus to make up time and get the system back on schedule. This usually comes at the expense of their recovery time.
 
We work with some outstanding and dedicated EROs. I'll introduce you to a couple of them soon.

You just never know who is driving you to work each day.
 
 

Anatomy of a delay thread…

It’s 15:55, and a train has a door fault at PIM. At 16:00, our ERO has exhausted troubleshooting and we need help from Alstom to get this door closed and the train rolling. What now?
 
The minute the door fault occurs, I’m on the SCADA desk in the control room troubleshooting with the ERO. I call Alstom right away, and they are on their way from TUN. I see the tech arrive at 16:00, good luck for us and an GR8 job in getting there quick. 5 minutes has passed.
It’s the furthest door from the lead train of course, and at 16:03 the ERO and Alstom tech work together to get the door locked in place. I can see the ERO running back up to the cab on CCTV. He keys back in by 16:05, 10 minutes after the door went pooch.
 
The mainline controller sent a single train down the east track to start clearing TUN, but the delay is still +10 minutes. from the schedule.
 
So at 16:09 the lead train begins his trip 13 minutes behind the next train in line, or +10 minutes from his schedule. The delay wheel starts to turn. Crowding at LYO, PAR, and RID. We have 3 trains heading east a station apart, but the lead train is getting kicked in the teeth.
 
He’s lost a minute more by the time he hits UOT, but RTM has advised us that we have a 14th train as a spare to launch into the gap to try and get that 10 minute gap monster cut. We launch it. The gap has shifted east now, it’s 16:32, and the train is still 10 min off schedule.
 
The schedules are set to minimize dwells during peak periods, so we don’t get much advantage at the terminus as the train turns back. A quick walk from end to end saves us about a minute, but the train is still +9 minutes over his normal 4 minute headway. He goes back west.
 
The gap has been cut a bit, as our spare train is in his spot, but it’s rush hour and that means his spot is still 9 minutes ahead of him and that means more crowding to slow him down.
 
By the time he gets back to TUN near 17:00, he’s turned around with a fresh driver and shaved another 90 seconds off his headway. Now he’s +7 minutes from where he should be. This continues to BLA, he shaves off another 2 minutes. It’s 17:40.
 
At TUN he shaves more time off and we are down to 5 minutes late. BLA has him back to 3 minutes late. When he gets back to TUN, he flips and is still 3 minutes late as he saw some pretty good action through the tunnel.
 
He’s back on time after 2 hours of aggressive turnarounds and drivers giving up the few minutes they get at terminus.
 
The Gap travels around in front of him, but a passenger waiting for a train outside the gap would have no idea there is a delay. The rest of the trains are on time. Outside the gap it's running well.
Picture a wheel. There are three trains travelling in a pack, The Gap, and 10 trains running on schedule. Our 14th train lessens the gap but can’t make the late train faster. It just needs a few terminus flips to catch up to its spot.
It takes time to fix the gap, but that 2 hours of delay that my colleagues tweet about means there’s a gap revolving around the circle that shrinks a bit every time your driver changes ends.

So if you were wondering, that’s what that is.
 

About switches... So, this morning there was what is being described as "Switch communication issues", and I thought a trainsplainer thread about switches might be wanted to those folks that might be interested.
 
First off, switches are the moving tracks that allow trains to leave one track and travel to another track. Each switch has it's own switch motor, and it's own controller connected to the control room. It's the moving parts that create the communication error.
 
In the control room, we see the switches move via a graphical image that has 4 states. Tangent (train goes straight) Turnout (train switches tracks) Travel (switch is currently moving) and Disturbed (system cannot verify switch position).
 
The communication error described means the system cannot verify that the moving parts of the switch have been locked into place as they should be. This is a Disturbed Switch.
 
So what happens when a switch goes Disturbed? Trains can't go over them. The switches need to be precisely aligned, and locked into position to safely travel over them. The system blocks the switch itself, and the other side of the switch from train travel.
 
We will not route trains over disturbed switches unless a technician locks them onsite with a switch clamp.
 
First thing we do as controllers, we try to manually swing the switches a few times in case debris has been caught in the moving tracks, which could absolutely Disturb a switch. If that doesn't clear it, we call in the Guideway Techs.
 
Debris can come from many sources. I've seen everything from kids throwing rocks on tracks to a nest of mice that infiltrated the switch heaters and brought all kinds of nesting material to the switch zone. Broom it out, swing it, problem solved!
 
It could be a software issue, that a tech can fix onsite by intervening on the programming side. This usually a quick fix. It can be a power issue to the switch motors. It can be an overheated motor at a busy switch. Just many factors.
 
All factors mean trains do not cross that switch, and at the Blair crossover, that means R1 service. Service from TUN-STL is status quo, and BLA-STL uses buses.
 
We could run a shuttle along one track, but travel time is 4+ mins BLA-STL, so a single train would provide an 8 minute headway plus loading time. Likely 10 minute service out of BLA, and that's not ideal.
 
Disturbed switches are really pretty uncommon over the past year. You'd expect it to be the ones that don't get used much. Techs get to the switch and clear them, they get status, and we roll. I'm off today, so unsure what caused it. This one swings every 4 minutes. Odd!
 
Anyway... that's what communication errors are on switches. It's not something I'd expect to be a regular occurence. Was shocked to see it in my inbox this morning.

Thanks all. That's Switches 101, take your quiz home and submit it on Monday.
 
 

Interesting watching a story develop yesterday about a train going out of service at Blair. I was in the control room, and we start getting calls about a broken down train at Blair.

News so fresh, we were running the service, and hadn't even heard it.

So what happened? Read on.
 
All our trains run on a loop. Picture a circle with 13 dots spaced around it. Each dot has a run number, each run has it's own schedule, and each run is assigned a train. Simple, yes?

At around 18:00, 13 trains goes to 11 trains. At around 21:30 11 trains goes to 6 trains.
 
So once in awhile, the maintainers need a train back at the 18:00 reduction that isn't currently assigned to one of the runs that is supposed to come in at that time.

So we need to switch runs on the trains.
 
Yesterday, a train needed a run switch. As luck would have it, the train that needed to come in earlier was right in front of a train assigned to a run that was scheduled to come in at that time.

So, we switched them.
 
The lead train parks at Blair, the rear train comes in about 3 minutes later. We clear the lead train, load the rear train, and the rear train leaves without the 4 minute dwell it usually has, departing on the lead train's schedule.

Then the lead train leaves on the new run.
 
No impact to service, other than a train waiting extra time, and a train doing what we call a Turn and Burn, loading and leaving.

This is normal operational stuff. It's going to happen in the future. It happened again about 60 minutes after the one that made the news.

OC Twitter reporting a train immobilized on track 1 at UOT.

What's going on, how controllers deal with this, and what to expect as a passenger.

Track 1 is the westbound track. We have switches just before Hurdman station, and switches just after UOT.

So with a train stopped at UOT, we need to use track 2 (eastbound track) for both directions between those switches.
 
It takes about 7 minutes for a single train to travel from the switch before HUR, service the stations, and pass the switch after UOT. This means that trains heading east need to wait 7 minutes at RID for trains heading west, and vise versa.
 
What happens with 11 trains on the track is that two or three trains will stack up at the stations behind the diversion, and we will release 2 trains across in each direction as the track becomes available.
 
The service still runs, but you get chunky headways, and the information displays get a little confusing, because the system cannot accurately predict when a train will be released across a diversion.
 
Your trip from BLA could look like this... Train arrives, its smooth sailing to TRE. Then, you're waiting anywhere from 5-14 minutes as trains cross the diversion. You start rolling again when the diversion opens up, and your trip crosses to track 2 for 3 stations.
 
From TUN, you're likely to get 2 delays, as more trains are west of the diversion than are east. You might see a delay at PIM, then again at RID because there's likely more than 2 trains ahead of you looking to cross the diversion.
 
These delays and diversions usually get cleared up within an hour, but the chunky headways continue until the service does a few end-to-end flips.
 
Those end-to-end flips fix the headway by using the dwell times at terminus stations. Essentially, your drivers give up their breaks to fix the headways over an hour or more.
 
At the single-track stations, you need to pay attention to where your train just came from.
 
Everyone, east and west, are on the same platform at HUR, LEE, and UOT. If your train came from downtown, it's going east!
 
The moral of the story here... it's delayed, not stopped. Trains still run, it'll take you as much as 20 extra minutes to go end-to-end, but it's running!

First things first, we can't beat passengers to Twitter. The people on trains are seeing things in real time. Trains stop, they tweet.

But what do we see in the control room?
So let's consider a door fault as our example.

Typically, a door fault means the ERO cycles the doors manually and the fault clears. This is the outcome 99% of the time. Maybe a 60 second delay. Train moves, we all flag it for tracking. No comms needed.
 
The next escalation is that the door doesn't clear. So, the next step is door isolation. This typically takes about 3-4 minutes. The ERO leaves the cab, pushes the doors closed, locks them with an isolation switch. The controller notifies comms that trains are held for maybe 4min
By this time, Twitter is afire. The event train has been stopped for 3-4 minutes, and now there are trains being held further down the line by us in the control room because the possibility exists that diversions may be needed.
 
What comms are needed here, at this point? Delays, yes. A diversion is a possibility, but not imminent. We don't want to send out a diversion message yet because that decision isn't made, but we've notified the bus side to consider options for R1.
 
The decision on diversions doesn't get made until the isolation process fails. That's already 3-4 minutes into the event, and let's face it, the ERO will try for a few extra minutes before we evacuate a train and start diverting train traffic. Diversion isn't a snap decision.
 
At this point, people in my job make the decision that the trains must divert to keep moving. The event train has moved from troubleshooting to obstacle. Time to get the diversion message out about an event that has been on Twitter for 6-10 minutes already. Trains are backed up.
Diversions mean single tracking, moving people from one platform to the other, and getting that messaging out about where you need to go to catch your train. In certain sections and certain times, it means R1.
 
The R1 decision may come 6-8 minutes into the event because it's a last resort solution. It takes time to get buses to R1 stops. As an example, last week during the medical at PIM, R1 arrived just as the medical cleared up. These buses need to drive to R1 stops.
 
Many times, R1 is pulled from existing service. So they have to organize this when we first call about the fault. The planning begins, but the buses still need time to get there.
 
So you can see how the passenger experience differs from the operator's experience. A passenger sees the stoppage, then after waiting gets new information that may change in minutes because resolution has occurred.
 
The controller sees escalation of the event with each passing minute, and each escalation has it's own response, meaning the information we want to push out is changing with each change in event status.
 
It's difficult to figure out what to tell our customer service department to push out. What we predict will happen in any given event changes by the minute. Our decisions have real consequences, and as controllers, we don't take that lightly.
 
One door fault is resolved in 60 seconds. The next time it's 3 minutes. This is supposed to be the worst case scenario every time. Then one occurs that results in a train not being able to move for 10 minutes or longer.
 
Comms isn't easy when this happens. Especially with moving targets and the public's ability to see things before they can.