Positive Train Control - Federal Legislation Pending

[Deggesty]

Railwayman wrote (11:08 PM 10-02-2008) "There's no turnouts in the tunnel"--except in the tunnel on the Maryland side of the Potomac at Harpers Ferry. This switch is, of course, just barely inside at the west end of the tunnel.

[erikem]

Regarding the use of GPS as part of any PTC system, may I suggest reading this article.

 

GPS Spoofing

I wasn't impressed with the article. For one thing, they didn't mention spoofing counter measure - using a phased array antenna to track the satellites and reject any signal that isn't coming from the expected direction. Another advantage of a phased array antenna is reducing problems with multipath and other sources of interference.

I'd be more concerned about the communications links being spoofed. Implementing secure communications links isn't an immensely difficult problem, mainly requiring someone who knows what he/she is doing, careful with their work and has that work doublechecked. The problem is that it is really easy to overlook something that will end up being a vulnerability - and those vulnerabilities can be really subtle.

[Paul_D_North_Jr]

The system (that I'm familiar with) looks at the braking rate necessary to stop the train short of the "fence", given the speed at which it's traveling, the weight of the train (taken from the trainsheet), and the vertical profile of the track.  Then it looks at throttle position, whether the throttle is in d/b or power, and brake-pipe pressure.  If the computer calculates the train will stop short given this information, no enforcement will be applied, but it will flash an alert to the engineer that the end of the territory is approaching and an instanteous recommended maximum speed.  If the engineer doesn't brake sufficiently, the system will enforce braking. 

As you would know, railroad rules are "yes/no," that is, you are either on this side of the insulated joint or fouling point and legal, or you are on that side and illegal.  A braking curve is in effect an asymptote and not strictly compatible with a yes/no line unless the braking curve is perfect.  Accordingly, the system has a creep mode that allows a train to creep up to a end of authority.  The railroad can set the parameters however it wants.  For example, it could be set so that the train must be down to 3 mph 150 feet short of the clearance point, then allows a 3 mph creep up to the clearance point.

The system also has a memory feature (if so desired) so that it learns a train's braking characteristics.  For example, if the computer calculates that a deceleration rate ought to be X for a given grade profile, train weight, TPOB, and braking effort (both air and d/b), but it [the computer - PDN] sees that the deceleration rate is actually 1.01X, then it [the computer - PDN] recalculates its [the train's - PDN] braking rate and allowed speed as the train approaches an authority fence or temporary or permanent speed restriction accordingly.  But in no case will it [the computer - PDN] give a train a better rate than its [the train's - PDN] ideal rate, or whatever rate the railroad decides is safe.  [emphasis added and clarification inserted - PDN]

As you can see from this, configuration, and configuration management on an on-going basis, has some challenges.  CFR 239 Subpart H establishes the regulation.  Meeting Subpart H is expensive.

RWM

RWM -

An excellent explanation, as always, of something I don't know much about.  I really appreciate your contributions to the forum - this and many, many others - they obviously reflect a deep understanding of the subject, and I know it takes time to craft a logical and well-presented response, which seems to be your hallmark.  Thanks much - I hope you get as much back out of it as the rest of us do.

That said, a question on the above (and another one that I'll post separately):

What happens if the computer "learns" the train's braking characteristics on, say dry rail (which of course would be pretty quick deceleration), but the train then encounters bad weather - say, a rain shower and wet rail, or worse yet - what's really "fun" for the commuter rail systems here in the NorthEast U.S. (Philadelphia and SEPTA, in my case) at this time of year, with their inherent many starts and stops on each run - wet leaves on the rails (which supposedly can have a coefficient of friction approaching as low as that of oil), which would cause a much slower deceleration ? 

Asked another way, can the system be "faked out" by learning and adopting the train's actual braking rate under good or even optimum conditions, and then inadvertently misapply that rate when those conditions suddenly turn worse before the computer has had another opportunity to evaluate and adjust the computer's "knowledge" (data) of how the train is responding under those adverse conditions ?  (I presume the computer is not an all-knowing HAL 9000 kind of system that can take the weather into account - I'd trust it even less then !) 

Or, is the system's "learning" capability only on the "safe side" - i.e., the computer can only adjust the braking rate downward for slower deceleration rates and a greater margin of safety than the "ideal rate" that would otherwise be applicable ? 

Further, is that "ideal rate" specific to each train - such as the "deceleration rate X" in your example above - or is it a broader parameter (railroad-wide or division-wide, or even grade-specific, I suppose), say something like "the maximum calculated deceleration rate shall never exceed (be quicker than) 1 MPH per second" (just to pick a hypothetical value for that) ?

And how would/ does the PTC system deal with the "wet leaves" scenario, which can increase the braking distance / decrease the deceleration rate way beyond what rational minds would otherwise consider to be a reasonable margin of safety - and randomly, at that ?  If a commuter railroad had to operate on the basis that every train was going to encounter wet leaves at every station stop and start - even if only on the rainy and wet days - I could see the operations degenerating to about 20 MPH max. and schedules being non-existent.  Unfortunately, iot seems to me that the only alternative is to accept that particular risk and build an allowance for it into the system - a manager could decide to slow the operations down on those wet or rainy days - but sooner or later on a "good" day they're going to miss that condition someplace, sometime, and a closely following train is going to slide into a stopped one.

Any thoughts or responses on this dilemma ?

- Paul North.

[Paul_D_North_Jr]

[clip - PDN]

While some of the PTC systems haven't panned out -- generally because they were designed by non-railroaders who thought they could parachute in and tell us beknighted black-oil types how smart they were -- the systems that have found commercial acceptance have thought through these issues.  It is not necessary to have a continuous signal.  If the locomotive gets a good signal once every 5 minutes that's often plenty.  It [the locomotive - PDN] maps itself onto the track database stored in its [the locomotive's - PDN] computer when it gets a signal and [the locomotive - PDN] knows where it is not just from GPS but also dead-reckoning from the axle odometer plus any track tags it [the locomotive - PDN] passes over.  The locomotive knows where each track tag is supposed to be, and if it passes the location where one is supposed to be and doesn't find it with the tag reader, it stops.  The track tags are paired so one can be knocked off and trains aren't delayed.  The first locomotive that passes over a pair that's missing one reports it.  [emphasis and clarifications added - PDN]

[clip - PDN] 

RWM

So, why use GPS at all, if the axle odometer, track "tags", and track database are enough for the locomotive to know where it is ?  Unless it is only for a general back-up, redundancy, or "reality check" to be added to the system.

I'm in the survey business, so I'm pretty familiar with the pros and cons of GPS technology.  I don't see it as reliable or accurate enough for this purpose to use it as the primary locating method, or even for speed calculations. 

For something this complex, I can see and undersatnd that it is likely that no one system can meet all the requirements, in all the places, all the time, in all the conditions - it may take several different "tools" to accomplish the "safer train operations" (and other) goals with the desired level of comprehensive reliability, flexibility, fault tolerance, etc.  But I don't see GPS (alone) as adding a lot to that.  Instead, it seems to me that better communications and reporting from and back to the locomotives would be more useful.  As you say, the locomotives know where they are from the track tags, axle odometers, and track database, and how fast they're going, and can report that data to the system which can correlate them with other trains and even respond back with that kind of data to the same locomotives, so that all of the data for a certain region is available to all of the trains as well as the system and management.  I just don't see that GPS is an essential component to that, when it can't distinguish between which track the train is on - think multiple-track Powder River Basin territory, the many "urban canyons" of the NorthEastern Corridor, or even high-latitude railroading locations where the satellite constellation coverage/ "view"  above the horizon of those high mountain ranges is often pretty limited - think the UP's former WP Feather River Canyon line, the BNSF (former NP and GN) lines across the Rockies, and the CN and CP lines on their side of the border, esp. in the Fraser River Canyon.

Or, am I missing or misuinderstanding something here ?

- Paul North.

[tree68]

There's at least an order of magnitude more paranoia and distrust in this forum than with anyone I have to deal with in the real world. 

I suspect that it's a direct result of our relative ignorance of the state of the art in this area.  We can only comment on what we know/understand.

Now that we've had some excellent explanations of the technology, I would imagine that the collective paranoia has lessened somewhat.

[erikem]

So, why use GPS at all, if the axle odometer, track "tags", and track database are enough for the locomotive to know where it is ?  Unless it is only for a general back-up, redundancy, or "reality check" to be added to the system.

I'm in the survey business, so I'm pretty familiar with the pros and cons of GPS technology.  I don't see it as reliable or accurate enough for this purpose to use it as the primary locating method, or even for speed calculations. 

For something this complex, I can see and undersatnd that it is likely that no one system can meet all the requirements, in all the places, all the time, in all the conditions - it may take several different "tools" to accomplish the "safer train operations" (and other) goals with the desired level of comprehensive reliability, flexibility, fault tolerance, etc.  But I don't see GPS (alone) as adding a lot to that.  Instead, it seems to me that better communications and reporting from and back to the locomotives would be more useful.  As you say, the locomotives know where they are from the track tags, axle odometers, and track database, and how fast they're going, and can report that data to the system which can correlate them with other trains and even respond back with that kind of data to the same locomotives, so that all of the data for a certain region is available to all of the trains as well as the system and management.  I just don't see that GPS is an essential component to that, when it can't distinguish between which track the train is on - think multiple-track Powder River Basin territory, the many "urban canyons" of the NorthEastern Corridor, or even high-latitude railroading locations where the satellite constellation coverage/ "view"  above the horizon of those high mountain ranges is often pretty limited - think the UP's former WP Feather River Canyon line, the BNSF (former NP and GN) lines across the Rockies, and the CN and CP lines on their side of the border, esp. in the Fraser River Canyon.

Number 1 reason for using GPS is low cost, the RR buys the receiver and Uncle Sam takes care of the rest (and this is one area where the US is providing an enormous benefit to the rest of the world). For remote areas with largely single track operation (e.g. iron ore line in West Oz), accuracy of  100 feet may be more than adequate, especially if the switches are under remote control. Installation and maintenance is a lot less expensive than track tags.

Number 2 reason is having a position sanity check is always useful, especially in a safety critical systems.

I would imagine the traffic on any line justifying multiple track would make installation and maintenance of track tags economically feasible, but it may not be for lightly traveled lines.

The canyon problem may be partially solvable if you're interested in position along the line as opposed to what track am I on. With two satellites in view, the position will be known only as some point on the surface of a hyperboloid defined by the constant difference in distance between the two satellites. Chances are, that surface will only intersect the rail line at one point, and thus the position will be determined. Further enhancements with a limited number of satellites in view can be had with a high accuracy time base - a group developed a rubidium time base the size of a sugar cube and my recollection was that was good for 1 part in 10 to the 10th accuracy. 

[Paul_D_North_Jr]

 [clip - PDN]  It is not necessary to have a continuous signal. [means GPS - PDN]  If the locomotive gets a good signal once every 5 minutes that's often plenty.  It maps itself onto the track database stored in its computer when it gets a signal and knows where it is not just from GPS but also dead-reckoning from the axle odometer plus any track tags it passes over.  The locomotive knows where each track tag is supposed to be, and if it passes the location where one is supposed to be and doesn't find it with the tag reader, it stops.  The track tags are paired so one can be knocked off and trains aren't delayed.  The first locomotive that passes over a pair that's missing one reports it. [emphasis added - PDN]

[clip - PDN] 

RWM

W_A_I_T a minute, here - are you foolin' with us, or is this for real - "once every 5 minutes that's often plenty" ?  At 60 MPH, a train (Amtrak) will cover 5 miles in that time - at 40 MPH (typical intermodal or multi-level auto carriers), 3.3 miles - even at 20 MPH (average general freight and coal, etc. train speed for most carriers), 8,800 ft. = 1.7 miles, or the entire length of many sidings.  That's several orders of magnitude more than the GPS location tolerances !  And on single track, it wouldn't be close enough to even tell where the train is with respect to a siding - entering, in it, leaving, past it, etc.  So, yes, the stated concerns over GPS accuracy and reliability may not be applicable.  But I repeat my earlier question:  What for do we need GPS in a PTC system ?  I can find my location in most places (except deserts and Kansas wheat fields, etc.)  that closely by either "star shots" (and Sun in daytime) with a mariner's sextant, or with a compass and a topo map [light sarcasm]

Also, I presume that the software someplace in the PTC system will calibrate/ compensate for wheel wear, etc. in utilizing the the locomotive's axle odometer data ?  For example, if a nominal 40" diameter locomotive wheel is allowed to have wear of up to 1" before the wheel has to be replaced (note: I have no idea of the actual limit - it's not far from that, but perhaps one of the more mechanically-oriented members here could enlighten us), then right there is a potential discrepancy of as much as 2.5 %.  That may not sound like much, but in a mile (5,280 ft.) the difference would amount to about 132 ft. - in 3.3 miles about 435 ft., and in 5 miles it would be 660 ft., which more than 0.1 mile.  As long as the PTC system has that recalibration capability - probably best based on the track tag locations - then there should not be a problem.  (This would be similar to the targeting computers on the Army's M1 Abrams tanks, which I understand keep track of the number of rounds fired through each tank's gun tube's life to allow for wear tolerance and inaccuracy, and the temperature of the gun tube to compensate for the "droop" from heating from the hot propellant gasses and the resulting gravity-induced deflection downwards, etc.)

I'd be interested in a little more explanantion of how these aspects of the PTC systems work.

- Paul North.

[oltmannd]

 [clip - PDN]  It is not necessary to have a continuous signal. [means GPS - PDN]  If the locomotive gets a good signal once every 5 minutes that's often plenty.  It maps itself onto the track database stored in its computer when it gets a signal and knows where it is not just from GPS but also dead-reckoning from the axle odometer plus any track tags it passes over.  The locomotive knows where each track tag is supposed to be, and if it passes the location where one is supposed to be and doesn't find it with the tag reader, it stops.  The track tags are paired so one can be knocked off and trains aren't delayed.  The first locomotive that passes over a pair that's missing one reports it. [emphasis added - PDN]

[clip - PDN] 

RWM

W_A_I_T a minute, here - are you foolin' with us, or is this for real - "once every 5 minutes that's often plenty" ?  At 60 MPH, a train (Amtrak) will cover 5 miles in that time - at 40 MPH (typical intermodal or multi-level auto carriers), 3.3 miles - even at 20 MPH (average general freight and coal, etc. train speed for most carriers), 8,800 ft. = 1.7 miles, or the entire length of many sidings.  That's several orders of magnitude more than the GPS location tolerances !  And on single track, it wouldn't be close enough to even tell where the train is with respect to a siding - entering, in it, leaving, past it, etc.  So, yes, the stated concerns over GPS accuracy and reliability may not be applicable.  But I repeat my earlier question:  What for do we need GPS in a PTC system ?  I can find my location in most places (except deserts and Kansas wheat fields, etc.)  that closely by either "star shots" (and Sun in daytime) with a mariner's sextant, or with a compass and a topo map [light sarcasm]

Also, I presume that the software someplace in the PTC system will calibrate/ compensate for wheel wear, etc. in utilizing the the locomotive's axle odometer data ?  For example, if a nominal 40" diameter locomotive wheel is allowed to have wear of up to 1" before the wheel has to be replaced (note: I have no idea of the actual limit - it's not far from that, but perhaps one of the more mechanically-oriented members here could enlighten us), then right there is a potential discrepancy of as much as 2.5 %.  That may not sound like much, but in a mile (5,280 ft.) the difference would amount to about 132 ft. - in 3.3 miles about 435 ft., and in 5 miles it would be 660 ft., which more than 0.1 mile.  As long as the PTC system has that recalibration capability - probably best based on the track tag locations - then there should not be a problem.  (This would be similar to the targeting computers on the Army's M1 Abrams tanks, which I understand keep track of the number of rounds fired through each tank's gun tube's life to allow for wear tolerance and inaccuracy, and the temperature of the gun tube to compensate for the "droop" from heating from the hot propellant gasses and the resulting gravity-induced deflection downwards, etc.)

I'd be interested in a little more explanantion of how these aspects of the PTC systems work.

- Paul North.

You can do the whole thing without GPS.  GPS is just handy and cheap.  If you are using track transponders and wheel rotation as your primary method of knowing where you are, then GPS is just a good sanity check and every 5 minutes would seem to be more than adequate.  Track transponders and readers are pretty cheap, too.

Since the on board computer would know where all the track transponders are on the route, and how far apart they are, very accurate wheel diameter calibration is easily done.  Sliding wheels can also be taken into account since you know you have an "impossible or improbable" rate of change of rotation, you can assume constant velocity during the sliding period and dead reckon your location on the safe side.  If you had GPS, you could, perhaps improve on your dead reckonning a bit.

 

[Paul_D_North_Jr]

[clip - PDN]

There's more than one way to detect broken rails than a D.C., A.C., or coded track circuit.  You can also use audio overlay frequencies, and get a much greater range than the maybe 10,000 feet you can get with a track circuit under ideal conditions.  Secondly, the value of broken-rail protection through track circuits is greatly overrated.  [emphasis added - PDN]  Most broken rails these days are either "found by a train," that is, they break underneath the train, or are detected as flaws by ultrasonic/electromagnetic testing.  (Metallurgy isn't what it was 50 years ago, which is good and bad.)  If you really want to find broken rails, you run the detector car more often.  That's what the Pilbara lines do, on a weekly basis, for one because they have extremely high axle loads, and for two because track circuits aren't feasible there due to the high conductivity of the roadbed with all the iron fines in the ballast.  Railroads are greatly increasing the sophistication and frequency of rail testing, as Mudchicken will attest.  The quantity of detection gizmos shown off at AREMA this year was mind-boggling when you consider that 25 years ago almost none of these tools existed. 

[clip - PDN]

RWM

Concur.  Rails can have many different kinds of flaws, and "break" in many different ways.  Track circuits will detect the complete vertical break kind only - where the rail is separated into 2 pieces - not any of the other modes of failure.  The detector cars and other technologies are much better at finding those other kinds of flaws.  Other than pull-aparts of welded rail in cold-weather changes and conditions, that kind of break is less common these days (improved metallurgy and testing, as noted above).  Further, that kind of break may not always be a terribly big threat of causing a derailment - if the track is in good condition, the rail fastenings at the adjoining ties should keep the rail ends in good enough alignment to prevent the wheel flanges from catching on and climbing over the broken rail head and derailing, unless the break is in the outside rail of a sharp curve or a similar situation.

- Paul North.

[zardoz]

"Positive Train Control", done by computers, does not inspire confidence. Hopefully they will not have a Windows OS.

Of course, knowing that some train engineers are so arrogant and/or ignorant that they text on their phones while operating does not inspire confidence either.

[dehusman]

I thought locomotive manufacturers stopped using "wheel rotation" for speedometers and odometers decades ago.  I thought they were using a radar gun that accurately measures speed without having to worry about wheel slip.

Dave H.

[beaulieu]

I thought locomotive manufacturers stopped using "wheel rotation" for speedometers and odometers decades ago.  I thought they were using a radar gun that accurately measures speed without having to worry about wheel slip.

Dave H.

 

Only GM uses a Doppler Radar for wheelslip speed calculation. It is effective only above a speed of approximately 1.5 mph. Below that speed the Doppler Shift is too small to be useful in calculating speed.

[oltmannd]

Speed indicators/event recorders use wheel rotation (actually, traction motor rotation).  Slight error from wheel creep at low speeds leaves you on the safe side of the error.

[Paul_D_North_Jr]

Another update on the above, again from the Los Angeles Times' "Bottleneck Blog":

http://latimesblogs.latimes.com/bottleneck/2008/10/president-bush.html

Synopsis (note - I'm merely summarizing, not advocating):

- President Bush will sign the bill - date not certain, though;

- PTC required by 2015 on passenger and some [most ?] freight trains;

- Hours of service reductions for freight train crews;

- Amtrak will get $12 billion in funding.  [Note: Not clear if that is merely "authorized", or actually "appropriated", and over how long - stay tuned for more on that.  As the late Illinois Senator Everett Dirksen said: "A billion here, a billion there, pretty soon you're talking about some real money."  Oh, yeah . . . ]

- Paul North.

 

[Paul_D_North_Jr]

A little more info on this:

It's technically known as the "The Rail Safety Improvement Act of 2008", House of Representatives bill H.R. 2095, as enacted by Congress October 1, 2008.

A better and more detailed summary - the actual bill is 315+ pages, so a summary is all I'm interested in - can be found on the American Public Transportation Association's website at:

http://www.apta.com/government_affairs/congress/rail_safety_improvement_act.cfm

The PTC deadline is Dec. 31, 2015, and freight train crews apparently will be limited to 276 hours per month, as I previously posted.

- Paul North.

[Railway Man]

All y'all have more time to pose questions than I do to answer (and some very astute observations by Oltman and Erik, muchas gracias).

In brief, between flights here ...

1.  You can't predicate schedule or braking distances upon an expectation of good rail condition, but only upon worst conditions.  Perhaps a commuter railway is making up time on the good days by relying upon good rail conditions, and running late on the wet-leaf days.  If so I don't think I want anything to do with that railway.  PTC will select whatever the railway wants it to select, but if they're expecting to calibrate based on ideal rail conditions I'd like to see how THAT Railway Product Safety Plan gets past the FRA.  The braking performancememory feature is designed to go for the worst case, not the best, in order to make it fail-safe.

2.  I think there's a perception that the way this works is by relying upon constant communication between the PTC server and the locomotive, like a radar skin-paint for ATC.  Actually it works just like real railroading now:  the server communicates with the train when the server needs to issue the train an instruction, and the locomotive communicates when it needs to tell the server it has accepted or completed an instruction, or when it's violated its instructions.  Otherwise the locomotive is autonomous.  (This is just like timetable & train order in concept.)  The locomotive uses the GPS to map itself onto the track database stored in its memory.  A direction of movement is established.  Then it uses GPS to check its progress on the map in its database compared to time, axle counts, transponders it encounters, etc.  The database is updated everytime the locomotive passes by a fixed base station which uses encrypted WiFi, along with checking that the locomotive has the latest software uploaded.  Software uploads and map uploads occur automatically.  Generally you put the base stations at places you expect locomotives to pass by regularly, such as the entrance/exit to a major terminal.  Outlying locomotives that live out in the field for long periods will need their own base station where they regularly tie up.  The locomotive pings the server at whatever interval you decide to update its location.  If you're sitting on a good, free VHF network, then you might ping every 5-10 seconds.  If you're not any you're paying for Iridium time (thanks Erik for the correction on Iridium) then you might only ping once a minute or even once every five minutes.  It depends on your traffic density.  Sure, if you're in the NEC you might want lots and lots of pings.  If you're in the middle of the Gobi Desert, who cares?  Any time there's a condition change the locomotive pings or the server pings -- e.g., a violation, a new instruction, etc.

3.  The screen in the cab graphically displays the calculated distance to the stop.  If it's 3,000 feet calculated to the end of authority, that's what is displayed.  The screen displays a target speed instantaneously to stop short, and can display the recommended d/b position and/or brake-pipe reduction, too.

[Victrola1]

What does Positive Train Control do for the 79 MPH speed restriction on passenger trains without an automatic stop system?

Assuming this removes the old automatic stop speed restriction, will public policy makers start pressuring freight lines to let Amtrak and possibly outlying commuter services increase operating speeds?

If a Positive Train Control system, doubtless computer based, is implemented, I hope its teething problems are fewer than Micorsoft's VISTA.

[Railway Man]

What does Positive Train Control do for the 79 MPH speed restriction on passenger trains without an automatic stop system?

Assuming this removes the old automatic stop speed restriction, will public policy makers start pressuring freight lines to let Amtrak and possibly outlying commuter services increase operating speeds?

If a Positive Train Control system, doubtless computer based, is implemented, I hope its teething problems are fewer than Micorsoft's VISTA.

PTC can be permitted to meet FRA regulations to exceed 79 mph passenger.  It's an expensive and involved "proof" process.  The challenge is demonstrating how the required safety will be achieved -- it's a paperwork challenge, not a technological challenge.  That said, it will be an expensive process for each carrier that wants to make the application.

RWM

[oltmannd]

Apparently, there are two flavors of PTC, one is an overlay on existing signal systems and is termed "non-vital", the other is "vital".

Not sure that something called "non-vital" could really be "positive"?

Seems to me, PTC either grants authority to a certain location, or it doesn't.  If it does and that authority conflicts with the fixed signal system, then....?

[beaulieu]

Apparently, there are two flavors of PTC, one is an overlay on existing signal systems and is termed "non-vital", the other is "vital".

Not sure that something called "non-vital" could really be "positive"?

Seems to me, PTC either grants authority to a certain location, or it doesn't.  If it does and that authority conflicts with the fixed signal system, then....?

 

The PTC authority can not conflict with the signal authority. The only possible problem area is a Dark signal, a signal that should be green, but is dark because of a dead battery, or similar problem. 

[blue streak 1]

With NS, BNSF, UP, and now CSX on board for an open architechure inter-operable system where are the others? AMTRAK, KCS, CN, CP, METROLINK, CALTRAIN, ACE, METRA, SOUTHSHORE, NEW MEXICO RAILRUNNER, GILFORD, METRO NORTH, SEPTA, NJ TRANSIT, and others on getting in on this inter operable system?

[Railway Man]

Apparently, there are two flavors of PTC, one is an overlay on existing signal systems and is termed "non-vital", the other is "vital".

Not sure that something called "non-vital" could really be "positive"?

Seems to me, PTC either grants authority to a certain location, or it doesn't.  If it does and that authority conflicts with the fixed signal system, then....?

1.  The overlay is not on the signal system.  The overlay is on the Method of Operation, i.e., the Train Control System.  Signals are nothing more than a means of transmitting information contained within a Train Control System.  Signals are not a Train Control System in and of themselves -- the system is a logical construct which includes rules, methods of communication, and methods of transmitting information.

2.  "Vital" is a sorry word that has no meaning outside of the signaling culture.  It usually means "must work" as opposed to "would be nice if it worked most of the time."  The FRA term of art is "safety critical" and that is defined as a system that whose correct operation is critical to safety.  

3.  Overlay systems using microprocessors are required to be safety-critical, but with the proviso that if a failure should occur then the overlay system does not affect the safety criticality of the Method of Operation that they overlay, whether that be Centralized Traffic Control, Track Warrant Control, Form D, DTC, OCS, or whatever.  In other words, the FRA has promulgated a two-step certification process:  the first step is to prove the system is safety-critical as an overlay but if it fails the base Method of Operation continues en force.  This is analagous to operating trains on verbal Track & Time authority in CTC territory when the signal system fails -- CTC is in reality an overlay on Track & Time (very few people know that or understand that.)  The second step is to prove the system is safety-critical as a stand-alone system.  In reality the hardware and software is identical between "overlay" and "stand-alone" but the certification process is a very large and expensive process to address.

4.  Thus to your last point, the authority is granted in a CTC system by the CTC system.  The PTC system, if an overlay, merely enforces that authority.  If the PTC goes on the blink nothing happens to the CTC.  In a PTC stand-alone system, the PTC grants the authority.  At that point you dismantle the CTC and throw it away.

RWM

 

[oltmannd]

Apparently, there are two flavors of PTC, one is an overlay on existing signal systems and is termed "non-vital", the other is "vital".

Not sure that something called "non-vital" could really be "positive"?

Seems to me, PTC either grants authority to a certain location, or it doesn't.  If it does and that authority conflicts with the fixed signal system, then....?

1.  The overlay is not on the signal system.  The overlay is on the Method of Operation, i.e., the Train Control System.  Signals are nothing more than a means of transmitting information contained within a Train Control System.  Signals are not a Train Control System in and of themselves -- the system is a logical construct which includes rules, methods of communication, and methods of transmitting information.

2.  "Vital" is a sorry word that has no meaning outside of the signaling culture.  It usually means "must work" as opposed to "would be nice if it worked most of the time."  The FRA term of art is "safety critical" and that is defined as a system that whose correct operation is critical to safety.  

3.  Overlay systems using microprocessors are required to be safety-critical, but with the proviso that if a failure should occur then the overlay system does not affect the safety criticality of the Method of Operation that they overlay, whether that be Centralized Traffic Control, Track Warrant Control, Form D, DTC, OCS, or whatever.  In other words, the FRA has promulgated a two-step certification process:  the first step is to prove the system is safety-critical as an overlay but if it fails the base Method of Operation continues en force.  This is analagous to operating trains on verbal Track & Time authority in CTC territory when the signal system fails -- CTC is in reality an overlay on Track & Time (very few people know that or understand that.)  The second step is to prove the system is safety-critical as a stand-alone system.  In reality the hardware and software is identical between "overlay" and "stand-alone" but the certification process is a very large and expensive process to address.

4.  Thus to your last point, the authority is granted in a CTC system by the CTC system.  The PTC system, if an overlay, merely enforces that authority.  If the PTC goes on the blink nothing happens to the CTC.  In a PTC stand-alone system, the PTC grants the authority.  At that point you dismantle the CTC and throw it away.

RWM

 

Got it! Thanks.

[oltmannd]

With NS, BNSF, UP, and now CSX on board for an open architechure inter-operable system where are the others? AMTRAK, KCS, CN, CP, METROLINK, CALTRAIN, ACE, METRA, SOUTHSHORE, NEW MEXICO RAILRUNNER, GILFORD, METRO NORTH, SEPTA, NJ TRANSIT, and others on getting in on this inter operable system?

BNSF, UP and NS are counting on the 900 lb gorilla effect...