PTC display question

After looking at the PTC display on page 7 of the April issue a question came to mind.

At first I was wondering where on this display would it show other trains on the system. But then, after some thought, I concluded that the display in MY locomotive is only interested in MY track authority. Is this assumption correct? That even if there was a train right next to me, it wouldn’t show on my display, because I don’t have authority on its track. So as far as my locomotive is concerned, the other locomotive doesn’t exist. I assume only the big computer in the sky is concerned with what other locomotives are doing, not my display. Do I understand this correctly?

I am also wondering what PTC does when two trains are put in one siding. Does PTC still calculate stopping distance as the second train creeps up on the rear of the first train or is there just an “overide mode”?

The other day I saw an northbound Amtrak pull into a siding behind another train to let a southbound Amtrak pass. It then backed out of the siding and continued north. It seemes to me that moves like this will make some hard challenges for PTC software designers. Can you guys think of some other moves that will be difficult for PTC software designers?

I stand to be corrected on this, but my understanding is that PTC systems will allow a low speed following move such as you describe.

I don’t know of any PTC users (railroads) that are attempting to show a moving track-line display with anything shown to a given train other than that train itself. The “target” that is the limit of a train’s authority might be another train, and it might be identified by train ID, or an icon, but not as a moving target. As you surmise, there’s no need to see this visual representation of another train in order to operate any train safely.

However, the PTC user can within fairly broad limits specify anything it wants to show on the cab display. It is feasible to show other trains on the display, but only if you are willing to absorb the expense of more bandwidth (which is very expensive) to transmit the additional data, and there are also some severe “real estate” restrictions on the display.

The bandwidth issue is that now you not only have to transmit information to the train about the train itself plus fixed signals, you also have to transmit information about other trains, and since other trains are both moving and have authorities and speeds that are dynamic, that is a very high information load. The bandwidth issue is a critical (i

There are at least five solutions that have been employed. One method is simply to prohibit either train from moving at more than 5 mph when both are in the same block. A collision can still occur but it will be a slow-speed one. Another method is to know where the rear of the first train lies and use that as the “target” just as if it was a stop signal. This can be done with telemetry from the rear-end device (expensive because it’s more bandwidth and something else to maintain), or with dead-reckoning from the trainsheet that (in theory) shows an accurate train length. A third method is to allow an override that is written into the PTC software for joint occupancies and keep both trains at restricted speed. A fourth method is to treat the track where this occurs as non-controlled track and operate it at restricted speed only when there are two trains in the block. A fifth method is to prohibit this type of move altogether and live with the capacity loss it just caused you. Railroads can choose from all or any of these depending upon what they want to accomplish and what kind of capacity they want to have on their systems.

The hard challenge is not software. That’s easy – it’s just writing a few lines differently. The challenge is devising the

With PTC, like everthing else in life…the devil will be in the details…and the details are myriad…just when you think you have them all covered…up will pop another 15 or 20 that will have to be integrated with everything you thought you had already put to bed.

I wonder if the RRs are thinking of portable displays rather than one in each locomotive. Just issue the train crew two displays when it leaves the originating terminal, turn them in at the end or let them ride with the new crew (or RR, ie: UP to CSX on a run thru). Just plug and go. With two displays if one dies on the road you are covered and a portable is easily replaced but if the permanently mounted one dies you may have to switch locos.

But then since this whole deal is costing billions whats twenty thousand $500 displays (only 10 million).

John

In the railroad operating enviornment your display figure is missing one or two zeros in it’s cost…the actual display unit is the easy part of the equation…the hard part is what must be displayed. Present day locomotives already have a number of computer displays.

There is no reason that you could not use a multi-function display. Airliner builders have solved that problem years ago. As a pilot the fewer the number of displays the better; just select a temp display when needed

The PTC displays ARE multifunction. You toggle between them with softkeys that the railroad can assign to whatever it wants. As far as making all the screens with all the information (air brake, speed, operating authority, etc., ) multifunction, that’s not a choice the FRA or the railroads have endorsed.

The PTC displays are also rather heavy. They must be able to tolerate a tough environment. I don’t think anyone would be enthusiastic about lugging them around in their grip. And it wouldn’t save enough money to bother with.

RWM

Everytime I think I have a handle on PTC senarios, I think of something new.

Would a small switcher on an industrial siding be included? Probably not, but what would prevent it from shoving a line of cars onto the main line in front of a fast train. A million derails to be installed? I’m sure there will always be something that just cannot be prevented. When it happens there will be a big stink.

Power derails to prevent incursions and authority excursions. Also at diamonds and ends of sidings and junctions and you name it. Not quite a million of them, but the number is large.

RWM

Probably the “split-rail”/ switch type, too, which are the most effective - and are by no means universal yet either, so they’ll have to be installed/ upgraded as well.

But when they’re called upon to do their duty, regardless of how far back they’re installed, once in a while that will occur right in front of a too-fast-moving train - just like the ConRail locomotives that ran out in front of Amtrak’s Colonial in 1987 or so. The result might well be a big pile of wreckage that flops over onto the high-speed track too late for that train to stop in time . . . And the only way to prevent that is to absolutely halt all movements which are nearby enough that they could conceivably have that result, enough in advance to provide the needed ‘window’ of safety in terms of time and distance. So the switch crew will have even more non-productive time to delay their work and to account for . . .

  • Paul North.

Double switch point not single-point.

Yes, they have to be far enough back to do some good.

Yes, there’s another yawning capital cost, maintenance cost, and capacity cost hole.

RWM

I would like to comment on a couple of different points already mentioned.

First, the display issue.

In my opinion, that is the easiest to solve. The display could be as simple as a line with a start and finish point with the relative current position of the train shown as a dot. My gps in my car does this. Does the operator need any more during normal operations? No. This simple display tells the operator that PTC is alive and well.

However, a secondary screen with perhaps a track schematic overlayed on top of a google map might be useful especially when an incident occurs in a remote place in dark territory. The bandwidth cost is manageable as it would only need to be updated when a train departs its initial terminal or when the routing changes.

Second, trains closing up.

I think we can use the current rules to solve this problem. That is, restricted speed governed by PTC. Restricted speed is the current operating practice for such events and the risks are already accepted. Could there be a major incident? Yes, but the risk is small.

To enhance a PTC system dead reckoning could be used to determine an end point of a train as conductors are supposed to keep train length up-to-date. Usually recorded train length is longer than actual train length but of course, some conductor could slip a digit and record a train length that is much shorter than actual train length. This enhancement could reduce the risk of a 15mph collision to say a 5mph collision. There will still need to be an override to allow trains to close up when conditions are very tight. Sometimes two trains in a siding are only 10 to 20 feet apart.

Not to make light of a valid solution, but decreasing capacity is a no go. All railroads spend millions every year trying to increase capacity.

So I agree with RWM with his assessment but I prefer a blended approach of restricted speed with dead reckoning as it employs current operating practice

When a train is “parked” in a siding while another is passing by, Is that train “locked” in park and immovible? Are the brakes “locked” on? If it is only parked 200ft from a switch and begins to move, I’m not sure that is enought time to update the GPS and calulate speed and braking distance before it runs the switch.

That’s what the derail is for.

But, GPS is just one of the inputs to the PTC system. There’s also an axle counter on each locomotive that will detect that the axle has begun to turn, and the PTC system is integrated with the air-brake system. So the instant motion begins, the PTC system detects that and responds. It does not need GPS to do that. GPS is the “rough approximator” of location. The axle counter gives you fine-grained location. The PTC onboard computer uses the GPS and axle counter input to map the train onto a track database stored in its memory, plus peer-to-peer inputs from wayside signaling in signaled territory. Because the track map consists of a logical system of interconnected tangents and curves, the train can’t get lost. The map knows where the train can and can’t go – in most cases, the train can only go forward and backward. It can’t turn a corner and drive off into a field and find a new track somewhere else to get on. So if the computer detects motion, and it has an initial location to work from, it can dead-reckon itself down the track system until it gets another GPS signal to compare to its internally calculated location. And in fact there are many instances where there will be no GPS signal at all, for example, if the locomotive antenna is masked by an overpass, or vegetation, or whatever. The hard part is discriminating between parallel tracks, for example, is the train on the main track or the siding 14’ to one side, and discriminating between 1" on the safe side of a fouling point or insulate

[quote user=“cptrainman”]

I would like to comment on a couple of different points already mentioned.

First, the display issue.

In my opinion, that is the easiest to solve. The display could be as simple as a line with a start and finish point with the relative current position of the train shown as a dot. My gps in my car does this. Does the operator need any more during normal operations? No. This simple display tells the operator that PTC is alive and well.

However, a secondary screen with perhaps a track schematic overlayed on top of a google map might be useful especially when an incident occurs in a remote place in dark territory. The bandwidth cost is manageable as it would only need to be updated when a train departs its initial terminal or when the routing changes.

Second, trains closing up.

I think we can use the current rules to solve this problem. That is, restricted speed governed by PTC. Restricted speed is the current operating practice for such events and the risks are already accepted. Could there be a major incident? Yes, but the risk is small.

To enhance a PTC system dead reckoning could be used to determine an end point of a train as conductors are supposed to keep train length up-to-date. Usually recorded train length is longer than actual train length but of course, some conductor could slip a digit and record a train length that is much shorter than actual train length. This enhancement could reduce the risk of a 15mph collision to say a 5mph collision. There will still need to be an override to allow trains to close up when conditions are very tight. Sometimes two trains in a siding are only 10 to 20 feet apart.

Not to make light of a valid solution, but decreasing capacity is a no go. All railroads spend millions every year trying to increase capacity.

So I agree with RWM with his assessment but I prefer a blended approach of restricted speed with dead reckoning as it

I hope the thread continues, but at this time I want to thank everybody for their input. I have learned alot and have have a better understanding just how complicated and costly the PTC system is.

+1 Interesting dialog just above - thanks to you both.

RWM, it’s a sad day when your quite prudent “disclaimer” starts to approach the length of your substantive comment . . . [sigh]

  • Paul North.