Why are U.S. Railroads resisting standardized signals?

[tree68]

I'm just guessing here, but what the heck?

As Paul suggests, there will be a number of things that will have to be considered in setting up PTC for a particular line.  Most will have to do with authorized track speed and layout, dynamics for each specific train, and, of course, track occupancy.

I should think, though, that at some point each line will have to go through a process analogous to the fellow who drives down the road and decides where the no passing zones are going to be - by seat-of-the-pants eyeballing the line.  Granted, some situations will be constantly changing, but that may be something the PTC system can process, enforcing a different set of parameters if an adjacent track is shown as occupied. 

Those areas where local geography is a factor (seasons notwithstanding) might essentially get hard coded into the system, just like any permanent track feature.

[Railway Man]

Andy -- the simple answer is, yes, it will enable "floating blocks".  The reality is that I don't think floating blocks will be implemented at first, because it requires a very significant increase in complexity of the PTC implementation (which already is quite complex).  And ultimately, I do not think that floating blocks will be implemented in the forseable future at all, except in some set-piece systems such as subways (which are not "railways" by the FRA definition) because (1) it's very hard to actually turn this feature into an actual time-saving advantage in the real world, and (2) a railway operated in such a fashion that floating blocks could be used advantageously is probably a very poorly run railway in the first place, and it's much easier and cheaper to just operate it properly and not get into this situation where floating blocks matter.

Think of it this way:  how do you put a floating block to your advantage?  If you go back and look at those presentations, they envision a railway world consisting mostly of double-track main lines of almost indefinite distance innocent of intermediate stops and speed restrictions for curves and speed losses for ascending and descending grades.  Do you know of any railways like that?  I don't.  It's the entry and exit points to the double-track where the floating block fails, because it bounds them, and the curve and grade speed losses, because those bunch up trains on the entry and stretch them out on the exit.  All the floating block enables is the bunching of trains to occur more quickly and with a little less space in between.  You can't feed trains into the system at one end at the minimum block spacing because they can't accelerate fast enough to ever catch up to the preceding train, unless for some inexplicable reason you decided to let the slowest train out first.

OK, so it does enable a fast train to come up behind a slow one.  So why are you running a slow train out in front of a fast one anyway?  So now you've saved a couple of minutes in the following train not having to wait for the preceding train to pass 2 block lengths but so what -- in a few minutes the fast following train will catch up and have to cool its heels.

And, if it's a mixed freight-passenger railway, how do you write the passenger schedule to turn this advantage into regular every-day time savings?  Only if you are predicting there will be a slow freight out there every day.  Why would you do that?

At best the floating block, in a Class 1 type railway, saves a couple minutes here or there every so often, and helps passenger trains recover from delays.  But it can't create savings in a passenger schedule, except on a subway type operation, where you can write this into the schedule and every day you have highly predictable operations.  So I don't see how the cost-benefit ratio of floating block can ever pan out for a Class 1 type railway.

The floating block concept provides value in a railway world where the trains could be beneficially operated on 8,000' headways vs. 20,000' headways, if only you had floating blocks.  But from my experience, even if you had floating blocks, it's neither practical nor economically desirable to operate a railway in such a manner as would be required to take advantage of them. 

RWM

[Railway Man]

tree68

I'm just guessing here, but what the heck?

As Paul suggests, there will be a number of things that will have to be considered in setting up PTC for a particular line.  Most will have to do with authorized track speed and layout, dynamics for each specific train, and, of course, track occupancy.

I should think, though, that at some point each line will have to go through a process analogous to the fellow who drives down the road and decides where the no passing zones are going to be - by seat-of-the-pants eyeballing the line.  Granted, some situations will be constantly changing, but that may be something the PTC system can process, enforcing a different set of parameters if an adjacent track is shown as occupied. 

Those areas where local geography is a factor (seasons notwithstanding) might essentially get hard coded into the system, just like any permanent track feature.

 

Larry and Paul:  ALL the local geography is coded into the system.   Every feature of the track configuration.  Every change in horizontal and vertical geometry.  Every signal.  Every insulated joint.

The braking algorithms are developed for the individual train's Tons Per Operative Brake and the on-board computer calculates the braking distance to a target stop on a real-time basis, because it knows where the train is in space, and the characteristics of the vertical geometry.  (It's the same calculation that I perform to space wayside signals for a given aspect system.)  The system knows where the other trains are too, and the other authorities, the position of switches, the aspects of signals, and so forth.  It calculates all this.  The architecture of the logic is not complex.  The hard part is making sure that the system for publishing updates to the onboard computers is robust and doesn't chew up too much bandwidth.

RWM

[Railway Man]

Paul_D_North_Jr

Maybe it's just me on a Monday, but I took spokyone's question as having a dose or irony or cynicism in it - the Pere Marquette reference as being to the Amtrak train that collided with a stopped NS intermodal train ahead of it, after passing a "Restricting" signal (15 MPH max., and able to stop within 1/2 range of vision, etc.) to allow it to close up on the NS train, because the Amtrak engineer mistakenly interpreted the signal as "Approach" (30 MPH max, able to stop at next signal).

So, a few clarifying questions: 

Would PTC's enabling the DS to permit 2 trains in the same block defeat the purpose of PTC and still allow this kind of accident to happen ?  My understanding is that no, it won't, because:

A)  PTC will keep a "tighter leash" on the following train when the DS allows a following train into an occupied block, by enforcing the actual speed limits of the signal - not over 15 MPH, instead of the mistaken 30 MPH (let alone the actual 40 MPH that the Amtrak train got up to); and,

B)  PTC will also "know" where the rear of the preceding train is, and so how far the head end of the following train has to go before they would collide, as well as the braking performance ("curve") of the following train.  Thus, PTC will continuously monitor the situation (via GPS, track "tags", and axle "distance" counters, etc.) and if the following train gets close to not being able to  "stop within 1/2 range of vision" for that speed, the the PTC will enforce that as well by making a brake application.

Are my understandings above correct, or am I missing something here ?

Now for the zinger:  How wil the PTC know or deal with the "range of vision calculation" ?  Suppose at 15 MPH the stopping distance for the following train is 500 ft. (made-up value for this question).  But, account of site (and sight) conditions - such as on a sharper curve and on the inside of the cruve is either a parallel retaining wall, train with high cars on an adjacent track, and/ or close  vegetation - the range of vision is less than twice that stopping distance - say, less than 1,000 ft.  Or worse yet, say the sight distance is less than the actual 500 ft. stopping distance - I could see (pun !) that happening with the train-on-adjoining-inside-track scenario.  Will the PTC be programmed to be able to take such things into account - that the sight distance might be restricted by "permanent" site conditions at certain locations such as the retaining wall, semi-permanent such as the vegetation (kind of like a temporary "slow order"*), or really temporary and transient conditions like the train on the adjoining track ?  What a programming and implementation headache/ nightmare that could / will be ?  Wow . . .

[* - not going to think about adjusting the vision range calculation for vegetation conditions as the deciduous leaves change each season - unless arborists are going to be hired as well to implement this ?    ]

Any thought or responses will be interesting, I'm sure.  Thanks.

- Paul North.

Paul: 

1. PTC enforces the authority and the track civil speed limit, not the signal aspect.  It really doesn't matter what the signal aspect is other than the absolute signal displaying "stop."  If the PTC thinks the train can operate safety at a higher speed than an intermediate aspect would otherwise allow, it knocks down the maximum so there's not a conflict with the aspect.
   
2. PTC actually works better than "limit of vision" because it knows what the track features are.  The rear end of a train is the same thing to PTC as an absolute signal indicating stop.  Both are "targets."
   
3. PTC knows what the temporary speed restrictions are (Form As, General Orders, etc.)
4. Not hard to program the system for these calculations.
5. For things like trains coupling up, e.g., a helper, the PTC system can have features such as a 5 mph restricted speed beyond a certain closing distance that's user-selected (such as, say, 500 feet.)  User in this case is the railway, not the engineer.
   

RWM

[Paul_D_North_Jr]

Railway Man

[snip; emphasis added - PDN.]  The hard part is making sure that the system for publishing updates to the onboard computers is robust and doesn't chew up too much bandwidth.

RWM

Off-the-wall - and maybe a little off-topic - but:  I'm wondering if the "system for publishing updates to the onboard computers" is analogous or comparable at all to the U.S. Army's IVIS = "Inter-Vehicle Information System" ? 

Briefly, as I understand it, IVIS keeps track of each vehicle's location via GPS and broadcasts it to all of the other vehicles so that they all know where all the others are - that's for both tactical control by the unit commanders, and to prevent "friendly fire" ("blue-on-blue") incidents.  IVIS is also part of the Combat Vehicle Command and Control System ("CVCC") also monitors the functional status of the vehicles (fuel, ammo, etc.) and communicates that to the commander and support units to make necessary logistical arrangements for resupply when necessary, etc. Additionally, the scout units can input the observed location and other data pertaining to terrain and opposition forces into IVIS, again so that all involved have that data.  Most combat vehicles (Abrams tanks, Bradley infantry fighting vehicles, artillery, scout units, etc.) were equipped with IVIS starting in the early 1990s. 

Here's a link to a reference for a publication regarding it, titled "SIMNET CVCC Software Design Document", June 1991 (61 pp.):

http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA244222

Just for what it's worth - the above is about all I know about it, but the similarity struck me, and I thought it would be interesting to ask.  Anything too technical would be over my head, and I can see where some aspects might be proprietary or senstiive, so I'm not necessarily expecting a reply - just "FYI" is all.

- Paul North. 

[Railway Man]

 Paul -- the communications technology envisioned is encrypted 802.11.  The "transmission" is not the problem so much as the collection, verification, and authentification of the data, and the implications one piece of data has on all the other pieces of data and on the system's operability. 

 For example, suppose a new industry turnout is to be cut into the main track one day.  That will require:

1. Updating the track data base with the accurate point of switch.
2. Assigning an address to the wayside interface unit
3. Testing and verifying the WIU
4. Updating the communications address database for the wayside interface unit. 
5. Deciding precisely when the WIU will start reporting to the system -- not too soon and not too late.
6. Deciding precisely when the track database will start recognizing when the switch exists.  Again, not too late (would allow an open-switch event to occur) and not too early (reaches out to poll it, can't find it, gives a system fault, trains can't be authorized over it except as stop, inspect, and proceed).
7. Deciding when the track database is to be published to locomotive onboard memory.
8. Making sure it happens to the locomotives that might pass over that turnout in the near future.  While any locomotive might go anywhere, you can't for practical reasons update every locomotive with every change everywhere, every time it happens.  Talk about bandwidth demand.  Plus, all the locomotives might not be in range of an 802.11 update device very often.
   
9. Getting the turnout information into the PTC system server in the dispatching office.
10. Turning it on, at the right moment.
11. Verifying and testing every step of the process.
12. Running the system management checks to make sure it all works -- testing in real time on an operable system.
    

All of this stuff has difficult timing sensitivities.  It's not like a retail store or an airline, where every day the whole operation stops dead, everyone runs around putting things right, and all the databases can be updated with the day's events and the next day, we turn the system back on, and start afresh.  We can't stop the railway every night, so this all has to be done in real time but it cannot have huge effects on operating efficiency and cost.  

The real problem with PTC is not the technology.  That part is reasonably straightforward.  The problem is managing the system updates in a way that is both effective and efficient.

RWM

[Paul_D_North_Jr]

Railway Man

Paul: 

1. PTC enforces the authority and the track civil speed limit, not the signal aspect.  It really doesn't matter what the signal aspect is other than the absolute signal displaying "stop."  If the PTC thinks the train can operate safety at a higher speed than an intermediate aspect would otherwise allow, it knocks down the maximum so there's not a conflict with the aspect.
   
2. PTC actually works better than "limit of vision" because it knows what the track features are.  The rear end of a train is the same thing to PTC as an absolute signal indicating stop.  Both are "targets."
   

[emphasis added - PDN; snip]

RWM

Thanks ! for the detailed reply - I'm definitely "getting understanding" here.  However, I'd like to ask for a clarification regarding how PTC works in 1., as follows: 

Suppose the track's civil speed limit is 60 MPH, but account of a train still leaving the far end of the 2nd block ahead at 45 MPH, the lineside signal's Aspect is "Approach" which indicates "30 MPH max., prepared to stop at the next signal".  My understanding from the above is that the PTC would internally reset the maximum allowed speed for the following train - "knocks down the maximum" - from the 60 civil speed limit to the 30 MPH per the signal "so there's not a conflict with the aspect".   Is this correct ?

I realize that with PTC fully implemented this may become a moot point - the lineside signals will disappear and so PTC won't have to coordinate with them and PTC's control will govern - but in the meantime this might be a useful way to understand how the logic of the PTC will work and handle such situations.

2.  After my earlier post, I thought about it some more and concluded much the same - probably the "1/2 of the range of vision" criteria of the rule for a "Restrictingg" Indication will be discarded because it's too fact-specific and vague for any location, and can be superseded by "hard data" stored in the system for anything except maybe a yard track.  For my examples above,  that may require coding in the worst-case scenario of restricted vision account of trains on adjoining tracks and the like - as Larry noted, having a guy ride the territory to log and enter those kinds of things - but that would be the conservative, predictable, and safest way to provide for those scenarios.  It just seemed like something the system would have trouble easily adapting to.  To get around that so it won't have to, we'll come up with another way that works as well or better.

Thanks again.

- Paul North.

[Paul_D_North_Jr]

RWM -

Thanks once again for the detailed reply to my "IVIS" post above.  Since I come from an industrial siding background, that is a particularly apt example for me.  The scope and details of that update is quite different - far more extensive and complicated - from what I had envisioned. 

As you said, in this instance the challenge is not the technology, it's the management and administration of the institutions and people that use and rely on it - that's not a new one, either.  Plus, the unavailability of the "Game over !" / restart / reboot freedom to the 24 x 7 railroad operations when trying to insert and synchronize this is kind of like replacing parts on an engine while it's still running, eh ?

I sincerely hope you're enjoying responding to these questions and comments as much as I'm learning from them.  Thanks again for sharing your time and knowledge with all of us.

Best regards,

- Paul North.

[petitnj]

Since I started this thread, I should say thanks to all of you for your input. There are many issues that should be considered -- which is why it remains in debate. Thanks to Andy and Paul for keeping the discussion going and all of you for putting facts out there that certainly are valuable to the discussion. Please keep up the good work and keep your thinking caps on. By the way. I am taking Amtrak through Chicago next month. Will the engineer know all the signals? And we solved this problem on our scenic railroad, the host RR took down the signals and set a speed limit through the block.

[Railway Man]

Paul_D_North_Jr

Thanks ! for the detailed reply - I'm definitely "getting understanding" here.  However, I'd like to ask for a clarification regarding how PTC works in 1., as follows: 

Suppose the track's civil speed limit is 60 MPH, but account of a train still leaving the far end of the 2nd block ahead at 45 MPH, the lineside signal's Aspect is "Approach" which indicates "30 MPH max., prepared to stop at the next signal".  My understanding from the above is that the PTC would internally reset the maximum allowed speed for the following train - "knocks down the maximum" - from the 60 civil speed limit to the 30 MPH per the signal "so there's not a conflict with the aspect".   Is this correct ?

This scenario is fairly easy to describe.   The "target" for the following train is the last red block signal behind the preceding train, not the rear of the preceding train (we're not doing floating blocks just yet).  The following train has to be at a speed at which it can stop short of that target, without fail. Signal aspect degradations are designed to provide safe braking distances for the maximum speed differential between any two possible aspects on a given pair of signals, which is usually 30 mph.

Let's assume the preceding train is dawdling out of that block so the condition is static for the following train.  In that case, in the usual 4-aspect system, the first signal aspect less favorable than Clear is (for example) Flashing Yellow, Advance Approach, reduce to 40 mph.  Some railways will set their PTC system to enforce 40 mph at the signal mast, others to enforce 40 mph after the signal mast but before it reaches the next mast.  The next signal encountered will display hard Yellow, Approach, reduce to 30 mph.  Again, some railways will set their system to enforce before the mast and some after the mast.

Thus, if there are two empty blocks between the occupied block and the block the following train is in, the two signals will be spaced each so that there is enough block distance for a train to safely brake from 30 to 0.   The only question is whether to enforce 40 mph at the mast or beyond the mast; either way, the scenario you describe where a train is traveling merrily along at 60 mph beyond the FY aspect without initiating braking isn't allowed under signal rules or under PTC because that would put it into the back of a train just beyond a red signal.

I realize that with PTC fully implemented this may become a moot point - the lineside signals will disappear and so PTC won't have to coordinate with them and PTC's control will govern - but in the meantime this might be a useful way to understand how the logic of the PTC will work and handle such situations.

2.  After my earlier post, I thought about it some more and concluded much the same - probably the "1/2 of the range of vision" criteria of the rule for a "Restrictingg" Indication will be discarded because it's too fact-specific and vague for any location, and can be superseded by "hard data" stored in the system for anything except maybe a yard track.  For my examples above,  that may require coding in the worst-case scenario of restricted vision account of trains on adjoining tracks and the like - as Larry noted, having a guy ride the territory to log and enter those kinds of things - but that would be the conservative, predictable, and safest way to provide for those scenarios.  It just seemed like something the system would have trouble easily adapting to.  To get around that so it won't have to, we'll come up with another way that works as well or better.

Thanks again.

- Paul North.

 

PTC won't be installed on yard tracks, only main tracks and controlled sidings. 

Let me repeat:  There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea.   The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target.  The computer displays the speed in the cab, and enforces if it is exceeded.  Again, I do these calculations manually on an Excel chart preprogrammed with the formulas for the specific railway by inserting the average grade between any two points, inserting the desired TPOB, and hitting "calculate."

It will be up to the railways to decide how they want to deal with signal indications for "proceed at restricted speed."  Most of them I think will simply enforce to 20 mph (or 15, or whatever they are) at the point where the train passes the signal mast, and then give a target speed beyond that signal that could well be 20 mph all the way if the computer determines there is no target beyond the signal before the next signal, or to a stop short of a target within that block, whichever is less.

In other words, the requirement that "movement must be made at a speed that allows stopping within half the range of vision short of train, engine, railroad car, men or equipment fouling the track, stop signal, or derail or switch lined improperly," might disappear on a main track.  It depends on how railways will deal with work zone limits on adjacent tracks.

RWM

[Murphy Siding]

Railway Man

Let me repeat:  There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea.   The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target.  The computer displays the speed in the cab, and enforces if it is exceeded. RWM

  Will/can the computer allow for changes in track conditions?  The only one I can think of, off the top of my head, is wet leaves on the track, or something similar that would affect braking.  Is something like that even an issue?

[Railway Man]

Murphy Siding

Railway Man

Let me repeat:  There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea.   The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target.  The computer displays the speed in the cab, and enforces if it is exceeded. RWM

  Will/can the computer allow for changes in track conditions?  The only one I can think of, off the top of my head, is wet leaves on the track, or something similar that would affect braking.  Is something like that even an issue?

 

That's an astute question.  Standard braking algorithms such as what we use for signal spacing assume worst-case conditions.  But in the real world, rarely do trains actually brake as badly as the standard algorithm.  However, the computer doesn't know that.  It knows only what a worst-case scenario is, and since it's programmed to choose the safest course possible, it will choose a worst-case scenario.  Thus, if the standard algorithm is instituted as the best-case condition (instead of relying upon the engineer's judgment as actually happens in the real world today), then the track capacity loss becomes rather significant.  Trains end up running much more slowly and further apart then they do today. 

Accordingly, there's a lot of research work ongoing into devising ways to measure a train's actual response curve along with local conditions (e.g., wet rail, presence of flange lubricators, rail head profile shape, etc.), with the goal of making braking curves more like what a good hoghead would use.  The TTCI is doing some good work on this right now.

RWM

[tree68]

Wouldn't the goal be to never actually use the override functions of PTC?

Unless we're talking about eliminating the hand of the engineer on the controls, it would seem to me that a PTC override should rarely even happen.  The system may provide the engineer with "signal indications," but if he/she is doing his job, PTC would never make a brake application because the engineer would already have the train at or below the recommended speed for the situation.

[Railway Man]

tree68

Wouldn't the goal be to never actually use the override functions of PTC?

Unless we're talking about eliminating the hand of the engineer on the controls, it would seem to me that a PTC override should rarely even happen.  The system may provide the engineer with "signal indications," but if he/she is doing his job, PTC would never make a brake application because the engineer would already have the train at or below the recommended speed for the situation.

 

If you're talking about "enforcement" when you say "override," you're correct.  The goal is to operate the train without a braking enforcement.  The railway selects the tolerance level between target speed and actual speed.  For example, at 0 mph over target speed it flashes a warning.  At 3 mph over target speed it enforces braking.  The computer knows what the condition is of the brake pipe (whether there's any reduction already made) and figures that into the speed tolerance calculation.  Thus for example if it sees a 4 mph speed overrun but knows there's already an 8-lb. reduction and calcuates that will be sufficient to stop short of the target, or reduce the train to correct speed before the entrance to a speed restriction, then it will be satisfied.

As far as system overrides by the engineer, it is possible for the engineer to turn off the PTC system using a sealed switch, otherwise, without such a switch, there's no way to move a train or locomotive that has entered into certain failure modes.

As far as system overrides by the train dispatcher, not possible and not desirable.  However, users can configure the system to allow a train dispatcher to run a train at restricted speed in close proximity to another train.  In that case the system can be configured to enforce at whatever maximum speed is chosen by the railway, e.g., 5 mph or 3 mph or 20 mph.  There can still be a low-speed collision, of course, but the likelihood of serious casualty is small.

A point made earlier that I didn't respond to previously is that "PTC knows where the rear of the train is."  Well, sort of.  It can look at the length on the trainsheet.  But I don't think anyone is going to install GPS-equipped FREDS that talk to the system and provide greater precision.  Instead, the system will be configured to be "trainsheet length plus X tolerance."  

One of the other knotty problems of PTC implementation is the requirement for trainsheet updates and accuracy to be much more reliable than at present, and done in real time too.  Otherwise the braking algorithms and length are going to be off.  Not that hard at initial terminal, but the long local that picks up and sets out all night long? -- well, that's going to be interesting to figure out how to make all those updates into the PTC system in real time quickly, efficiently, and accurately.

RWM

[tree68]

Enforcement is a better term for what I meant than override.  Override does connote action by a human.

I would think that GPS equipped EOT's would be desireable, and fairly cost effective.  Not that better records regarding train length are a bad thing (and they should certainly factor in), but GPS in the EOT gives a relatively exact location of the rear of the train, not just estimated length with a finagle factor. 

 

[Paul_D_North_Jr]

Railway Man

[snipped]

All of this stuff has difficult timing sensitivities.  It's not like a retail store or an airline, where every day the whole operation stops dead, everyone runs around putting things right, and all the databases can be updated with the day's events and the next day, we turn the system back on, and start afresh.  We can't stop the railway every night, so this all has to be done in real time but it cannot have huge effects on operating efficiency and cost.  

The real problem with PTC is not the technology.  That part is reasonably straightforward.  The problem is managing the system updates in a way that is both effective and efficient.

RWM

After thinking about the para quoted above last night, and reading the above posts about updating the frequently-changing length of a local freight train, and the "real-time" adjustment of the braking calculation algorithm to better reflect actual experience, it occurs to me that the Army's IVIS system is a better parallel or example of such a system than retail stores or airlines.  It's not that I'm enamored of all things military - but that system also has to run 24 x 7 nominally.  Then again, a lot of the armored forces prefer to operate at night, so the data stream may drop off considerably during daylight hours.  Also, the military seemingly doesn't have the same hardly any concerns about cost, though it would care about efficiency and timeliness of the updates and their possible degrading or unfulfilled effects on readiness and capability, etc.

- PDN.

[Paul_D_North_Jr]

Railway Man

Murphy Siding

Railway Man

Let me repeat:  There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea.   The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target.  The computer displays the speed in the cab, and enforces if it is exceeded. RWM

  Will/can the computer allow for changes in track conditions?  The only one I can think of, off the top of my head, is wet leaves on the track, or something similar that would affect braking.  Is something like that even an issue?

 

That's an astute question.  Standard braking algorithms such as what we use for signal spacing assume worst-case conditions.  But in the real world, rarely do trains actually brake as badly as the standard algorithm.  However, the computer doesn't know that.  It knows only what a worst-case scenario is, and since it's programmed to choose the safest course possible, it will choose a worst-case scenario.  Thus, if the standard algorithm is instituted as the best-case condition (instead of relying upon the engineer's judgment as actually happens in the real world today), then the track capacity loss becomes rather significant.  Trains end up running much more slowly and further apart then they do today. 

Accordingly, there's a lot of research work ongoing into devising ways to measure a train's actual response curve along with local conditions (e.g., wet rail, presence of flange lubricators, rail head profile shape, etc.), with the goal of making braking curves more like what a good hoghead would use.  The TTCI is doing some good work on this right now.

RWM

Previous discussion of PTC coping with the "effect of wet leaves on rails changing the braking characteristics of trains" and related topics is roughly between the 3rd post - 10-07-2008 -  from the top on Page 3 of 4, and the 1st post - 10-08-2008 - at the top of Page 4 of 4, among others, of the thread "Re: Positive Train Control - Federal Legislation Pending" at:

http://cs.trains.com/trccs/forums/t/137669.aspx?PageIndex=3 

http://cs.trains.com/trccs/forums/t/137669.aspx?PageIndex=4 

- PDN.

[erikem]

Railway Man

 Paul -- the communications technology envisioned is encrypted 802.11.  The "transmission" is not the problem so much as the collection, verification, and authentification of the data, and the implications one piece of data has on all the other pieces of data and on the system's operability. 

 For example, suppose a new industry turnout is to be cut into the main track one day.  That will require:

1. Updating the track data base with the accurate point of switch.
2. Assigning an address to the wayside interface unit
3. Testing and verifying the WIU
4. Updating the communications address database for the wayside interface unit. 
5. Deciding precisely when the WIU will start reporting to the system -- not too soon and not too late.
6. Deciding precisely when the track database will start recognizing when the switch exists.  Again, not too late (would allow an open-switch event to occur) and not too early (reaches out to poll it, can't find it, gives a system fault, trains can't be authorized over it except as stop, inspect, and proceed).
7. Deciding when the track database is to be published to locomotive onboard memory.
8. Making sure it happens to the locomotives that might pass over that turnout in the near future.  While any locomotive might go anywhere, you can't for practical reasons update every locomotive with every change everywhere, every time it happens.  Talk about bandwidth demand.  Plus, all the locomotives might not be in range of an 802.11 update device very often.
   
9. Getting the turnout information into the PTC system server in the dispatching office.
10. Turning it on, at the right moment.
11. Verifying and testing every step of the process.
12. Running the system management checks to make sure it all works -- testing in real time on an operable system.
    

All of this stuff has difficult timing sensitivities.  It's not like a retail store or an airline, where every day the whole operation stops dead, everyone runs around putting things right, and all the databases can be updated with the day's events and the next day, we turn the system back on, and start afresh.  We can't stop the railway every night, so this all has to be done in real time but it cannot have huge effects on operating efficiency and cost.  

The real problem with PTC is not the technology.  That part is reasonably straightforward.  The problem is managing the system updates in a way that is both effective and efficient.

RWM

 

Sounds like a classic database management problem, where "management" refers to the process of managing the database as opposed to a piece of software. The IT press has lots of horror stories of mismanaged databases, one recent example of parents of a recently deceased daughter getting a nastygram from the daughter's former school saying that her attendance needs to improve.

I do have a couple of comments - the standard encryption protocols for 802.11 have been embarrassingly easy to crack. Having said that, it isn't so much that the update data needs to be kept secret (with the possible exception of how the WIU authenticates itself to the system) as that the update data needs to be authenticated to the locomotives PTC unit. One way to authenticate is to hash the data (e.g. using SHA-256), encrypting the hash with a private key from a public key protocol - on the receiving end, the hash of the received data is compared to the decrypted hash.

- Erik 

[Railway Man]

erikem

I do have a couple of comments - the standard encryption protocols for 802.11 have been embarrassingly easy to crack. Having said that, it isn't so much that the update data needs to be kept secret (with the possible exception of how the WIU authenticates itself to the system) as that the update data needs to be authenticated to the locomotives PTC unit. One way to authenticate is to hash the data (e.g. using SHA-256), encrypting the hash with a private key from a public key protocol - on the receiving end, the hash of the received data is compared to the decrypted hash.

- Erik 

 

I am not a communications expert nor make any attempt to understand anything beyond the basic architecture.  There are large groups who do that.  My notes from a recent meeting say "SHA-1 HMAC will be used for all secure messages."

RWM

Normal 0 false false false MicrosoftInternetExplorer4

[aegrotatio]

I was really only talking about signal aspects when it comes to standardization for promoting safety.  Amtrak engineers spend a large amount of time on foreign rails.  You can't rely on people.  Even if they're qualified on all the roads they operate on, there will always be the quiet and subtle danger of mindset.

 

Speaking of infrastructure, someone also mentioned 802.11 and that it's easy to crack.  This has not been true for years, and the signal systems would be only using it as a communications medium--the actual signal system messages would have their own application-level protection in addition to whatever the 802.11 provides, so that argument is not relevant.

 

[Railway Man]

aegrotatio

I was really only talking about signal aspects when it comes to standardization for promoting safety.  Amtrak engineers spend a large amount of time on foreign rails.  You can't rely on people.  Even if they're qualified on all the roads they operate on, there will always be the quiet and subtle danger of mindset.

 

But we do rely upon people -- the pilot not to fly the plane into the ground on final, the paramedic to read the label on the IV bag correctly, the driver of the car behind you to see your brake lights.  And people design the safety systems.  As illustration, William Langewiche's article on the GOL 738/Embraer Legacy collision in Vanity Fair -- a collision with numerous human single-point failures as well as a very complex safety system that performed in unanticipated ways.

Speaking of infrastructure, someone also mentioned 802.11 and that it's easy to crack.  This has not been true for years, and the signal systems would be only using it as a communications medium--the actual signal system messages would have their own application-level protection in addition to whatever the 802.11 provides, so that argument is not relevant.

Yes and no.  First, signaling systems are not train-control systems, a distinction that might seem semantic but is not.   PTC is not a signaling system, it is a train-control system.  Signals transmit information, they do not control trains. There is no signal system message as an integral part of the PTC system (at least on the Wabtec platform; the ACSES is a different animal) excepting that the signal system at least until the PTC system is stand-alone has to be robust in its own right, just as it is now.

The communications requirements of PTC are complex.  The 802.11 messages are integral to the PTC system and the authentication and reliability of that communication link is mission-critical.   The 802.11 is how the software itself (and its updates) and the track database (and its updates) gets to the locomotive platform.  The locomotive platform becomes the enforcing apparatus.  Not a central computer.  All the server does is tell the locomotive the limits of where it is authorized to go (and any temporary reductions in speed); it's up to the locomotive to determine where it's boundaries are.  Bad data?  Bad results.

PTC uses existing signal systems as data input sources.  It ultimately throws away the signals as unnecessary.

RWM

[tree68]

Railway Man

PTC uses existing signal systems as data input sources.  It ultimately throws away the signals as unnecessary.

Are not the signal systems part of the important data?  Existing signal systems not only indicate track occupancy, but track integrity, and in many cases are connected to such things as slide alarms (rock slides). 

That particular line is dark, but in the case of the Watertown, NY runaways if the cars had "departed" overnight instead of in the middle of the morning, they would have travelled some 8-10 miles without the benefit of a locomotive, EOT, or even human detection, and might well have been lying in wait for the next train up the line, unnoticed.    PTC would not know they were there unless they were picked up by a track circuit.

[Railway Man]

tree68

Railway Man

PTC uses existing signal systems as data input sources.  It ultimately throws away the signals as unnecessary.

Are not the signal systems part of the important data?  Existing signal systems not only indicate track occupancy, but track integrity, and in many cases are connected to such things as slide alarms (rock slides). 

That particular line is dark, but in the case of the Watertown, NY runaways if the cars had "departed" overnight instead of in the middle of the morning, they would have travelled some 8-10 miles without the benefit of a locomotive, EOT, or even human detection, and might well have been lying in wait for the next train up the line, unnoticed.    PTC would not know they were there unless they were picked up by a track circuit.

 

Separate into pieces, and examine the pieces.  Are any of these pieces only capable of being handled by an ABS system:

1. Track circuits:  Required to detect broken rails (they are not very good at that because most breaks occur under a train now), and cars that roll out of spurs.  The better method for detecting the cars that roll out is a split-point derail with a switch-circuit controller that pings the PTC system when it's opened, creating an occupied block on which an authority can't be created and a train in that authority required to stop.  The PTC system can be written so that the car's roll-out travel potential can be calculated automatically and the train-effect distance determined.  Track circuits often don't pick up single cars anyway.  As far as the existing track circuits, they are a very expensive method of detecting broken rails.  Audio overlays and more frequent ultrasonic tests might be better and cheaper.  But all you need now is the basic track circuit with a wayside interface unit on it to ping the PTC server and the locomotive on a peer-to-peer basis.  All that relay and circuit logic so that one track circuit knows what the next one is doing?  That is no longer required.  This boils down to batteries, one charger, one adjustable resistor, and one relay, with two wires running to the WIU.
   
2. Slide fences.  The only reason some of them (not all) tie into a signal system is because it's a method of transmitting information that's already paid for.  All they need is a wayside interface unit.  Ditto for high-wide, high-water, shifted-bridge, ground movement, and WILD detectors.
3. The signal masts.  No longer needed.  Their sole purpose is to convey information to a train crew.  Now the information about track conditions ahead is conveyed on a screen in the cab.  The locomotive polls the detectors and the track circuits and the turnouts.  All clear?  Proceed.
   
4. The instrument house, track wire, insulated joints, ad infinitum.  Support for the mission.  Otherwise deliver no value.
   

ABS is a means of conveying information about track conditions ahead.  The information it conveys are occupancies, broken rails, tripped detectors, and open switches.  Train occupancies with PTC will be picked up by the train itself; the broken rail by audio overlays, and the open switches and derails by WIUs.  The only piece of the ABS system that might have continued value, for awhile, is broken-rail protection.  You can go through the cases and rip out everything but the track circuit itself.  Almost everything else has to get a WIU anyway.

CTC is an overlay on ABS that provides a means of transmitting authorities.  It additionally is interfaced with power-operated switch machines.  There's no unique value here, and everything the CTC does, the PTC does.  The power-operated switch machines remain, but a DTMF-style audio-overlay circuit can provide the route locking feature.

RWM

[Awesome!]

zugmann

petitnj

What is their problem? NTSB just nailed them to the wall for having multiple signalling systems. It that not enough of a warning? Or is the multimillions of law suits that follow cause them to make things consistent. This is not a hard problem. Upgrade all the signal systems so that yellow over red means the same in every system.

One answer: cost.  It would take billions to standardize everything.  Billions that an be better spent (IMO) elsewhere.  On all my territory yellow over red means approach (unless its a dwarf, then its a slow approach).  If I ran somewhere where it meant different, then I guess I'd have to learn it.  That's the definition of being qualified. 

IT would save Millions in the future by keeping one standard operation. We all know in the initial investment is going to be a huge chunk of $$. It the same theory of the Speed train from city to city. THe initial investment is going to huge but in the long-term is going to save more $$

[Paul_D_North_Jr]

Railway Man

aegrotatio

I was really only talking about signal aspects when it comes to standardization for promoting safety.  Amtrak engineers spend a large amount of time on foreign rails.  You can't rely on people.  Even if they're qualified on all the roads they operate on, there will always be the quiet and subtle danger of mindset.

 

But we do rely upon people -- the pilot not to fly the plane into the ground on final, the paramedic to read the label on the IV bag correctly, the driver of the car behind you to see your brake lights.  And people design the safety systems.  As illustration, William Langewiche's article on the GOL 738/Embraer Legacy collision in Vanity Fair -- a collision with numerous human single-point failures as well as a very complex safety system that performed in unanticipated ways.

[rest snipped; emphasis added - PDN]

"The Devil at 37,000 Feet" by William Langewiesche, January 2009, can be found at:

http://www.vanityfair.com/magazine/2009/01/air_crash200901?currentPage=1 

It's 8 pretty long web pages - looks interesting.  Thanks for sharing the reference.  (If you go to read it, try to concentrate on the article and not the rather nice photos of model Gisele Bundchen in the margins - compensation of sorts for having to follow the technical stuff.)

- Paul North.

EDIT - add, since my previous version was inadvertently deleted:

Thanks for referencing this - VF is not on my regular reading list.   

This article is about the much-publicized Sept. 29, 2006 mid-air collision over the Brazilian Amazon jungle of a private jet on its maiden flight to the U.S. with 2 American pilots, and a 2-week old Brazilian commercial airliner with 150+ people onboard who all died - both esssentially brand-new aircraft.

Good example of what can go wrong . . . go wrong . . . go wrong . . . with people, their systems, and the machines.  The author is not very nice to the EDIT: avionics aeronautics designers - particularly the man-machine interface.  For those of us who have to manage and worry about that kind of thing, it's troublesome.  Notably, the Brazilian airliner pilots did nothing wrong as far as I can see, and yet they were the ones who died.  One thing I didn't see addressed was if either of the 2 American pilots had military experience ?  They didn't seem to have much in the way of that 6th sense of "situational awareness" going on.  And the "check-out" procedure seemed like it was pretty lax for them to be flying such a sophisticated and elaborate piece of equipment - not like anyone could just climb in and fly it.  Good reading - just not before you fly anyplace.  I'll not spoil the plot of RWM's point about how one of the safety systems that performed in an unanticpated way - that's just chilling, when you think about it.

- PDN.

 

[jchnhtfd]

I have been following aviation and rail safety for years -- as a pilot and engineer (civil) does. Not a morbid fascination with blood and guts, but a real desire to learn what went wrong so as to, hopefully, avoid making the same mistake. One of the really serious problems in aviation today is well illustrated in Langweische's article, referred to above: the magic doesn't always work, or doesn't work the way it is expected to work, either though electronic gremlins or design or programming error or operator error. I can think of at least a dozen significant aviation accidents in the last year, never mind the last decade, wherein some sort of problem with the magic was a key link in the chain which led to the accident -- and at least one, albeit more than a decade ago -- in which the magic literally crashed the 'plane, despite the best efforts of two really fine pilots. This is not to say that the magic hasn't made aviation safer and, sometimes at least, more efficient. It has, no question about it. But it is to say that the magic hasn't, and can't, eliminate all the problems. The same thing will be true of railroading as such marvelous new toys as PTC are phased in. Railroading has, at the present time, an astoundingly good safety record, particularly when one takes into account the number of trains, the size of the trains, and the complete impossibility of keeping the tracks completely 'sterile' -- that is, free of accidental blockages (e.g. landslides, trees, moose, errant drivers, MP3 addicted pedestrians -- you get the point). I hope that whatever systems are implemented for PTC are at least as reliable as the present signalling systems and that they are at least as fail safe or fail operational as the present systems (I would note that for all of the money and effort expended, the magic in an airplane's cockpit is not particularly reliable, and certainly neither fail safe nor fail operational, unfortunately) -- a job which will take a tremendous amount of effort and thought by real railroad people, and not just desk-bound programmers and circuit designers with bright ideas. And I hope, even more, that the presence of PTC does not cause the engineers to become less aware of their surroundings and what, exactly, it is that they are doing at any given moment. Aviation magic has done exactly this to the pilot fraternity, unfortunately (not to attack pilots in general -- the vast majority are very conscientious people, and a surprising number are really good stick and rudder men and women): it is all too easy to follow the wonderful gadgetry and not pay attention to the world outside -- often with disasterous consequences.

[Railway Man]

Head-in-the-cockpit syndrome, lost in the intracacies of managing the electronics.

That thought lept to my mind the first day I saw PTC demonstrated to me in service, in the cab of a locomotive, in 2004.  Should the engineer be looking out the window or staring at a flat-screen monitor?  We were all staring at the screen waiting for it to tell us what to do next.  I didn't like that.  This still deeply concerns me. I have been striving ever since to simplify, simplify, simplify, the machine, so that the people can do their job without becoming overwhelmed by the complexity of the machine.  Same goes for the dispatching console.  It's turned into a flashing jukebox of crap laid out by people who have absolutely zero sense of graphics, clarity, readibility, functionality, and efficiency.  Why? Because they don't actually use it.  Worse, they employ user review groups who consist of cherry-picked people who will deliver the "right" answer instead of the honest answer.  The stuff works but it's about as awful as you can get.

As example of the problems that encouraging a machine to do too much creates, I just spent 30 minutes answering a very simple question:  "What happens when a locomotive can't ping its GPS satellite, and it's stationary?" It's not a simple answer -- it took me 1,000 words just to outline the basic outcomes.  The short answer is: It doesn't result in a safety fault, but it can eventually bring the subdivision to a grinding halt.  The brute-force solution is to recognize this possibility at every location where it could occur, and pre-plan for it with electronic workarounds.  The better solution by far is to simplify the machine so that it doesn't need to know so much data so often so accurately. 

Engineers and marketers, as Langweische pointed out, can fall in love with their products and enable them to do everything, just in case someone might want it someday.  One of my jobs right now is to figure out how many PTC features we can strip out, how many options we can turn off, and still make it work and meet the law.  The last PTC system I worked on, by the time I was done, I had turned off more than 95% of the features and options originally offered by the engineers.  That made me very happy!

Paul, you pointed out earlier that the problem is the machine can break.  A.C. Clarke was wrong.  The machines work fine, right within specs.  The problem is that the machine is so complex no one ever figures out why it does anything!  Have you ever figured out all the features on your cell phone?  Windows computer?  DVD Player?  ipod?  Microwave oven?  How about the toaster?  Nope!  My daughter gave me an iPod for Christmas and I still hate the stupid thing.  (I want to register a website, thisstuffsucks.com.  I will list on it everything ever made or operated by Microsoft, Apple, Chrysler, AT&T, Verizon, Sprint, Comcast, Epson, H-P, Palm, Blackberry, and Kodak.)  You just figure out barely enough to make it sort-of work, and when it does or doesn't do what you hope it will do, you're baffled.  That is precisely what Langweische was getting at: systems that no user can ever figure out why or what it's doing, and when things go wrong, no one even knows they have gone wrong.

Langweische is my favorite author, by far.  No one else gets the technical details as right, explains them as clearly, or turns a phrase so eloquently.  If the last paragraph in the "Devil at 37,000 feet" article doesn't make you shiver, you might be dead from the neck up.  Patrick Smith, the "Ask the Pilot" columnist and a 767 captain, said that Langweische made exactly one technical mistake in the "Devil" article, a very minor one, misnaming a control center, which might have been a spellcheck error in fact.  That's as impressive a recommendation as you can get. 

RWM

[spokyone]

RWM: I love your avatar. I'm thinking that must be in Texas somewhere.

[MP173]

RWM:

Add to the list digital cameras.  I purchased a Pentax 35mm without a built in light meter back in 75 and loved it.  With the digital D40, it comes down to point and shoot (which works quite well, but I havent taken the time).  My Blackberry is the same, I answer the phone, retrieve email, but most of the features are not used. 

Now it is time to read the aforementioned Vanity Fair article. 

Ed

[Railway Man]

spokyone

RWM: I love your avatar. I'm thinking that must be in Texas somewhere.

 

Beats me!  I lifted it off an email of funny signs someone sent me awhile ago.

RWM