# Metrolink's PTC Progress



## WhoozOn1st (Mar 25, 2011)

Parsons, Metrolink's prime contractor for positive train control (PTC) technology, has enlisted a subcontractor...

Wabtec signs deal for Metrolink PTC

"The project represents the first use of interoperable PTC equipment in the transit industry under the U.S. Rail Safety Improvement Act of 2008, and Metrolink's goal is to have PTC implemented system-wide by the end of 2012, three years ahead of the federal mandate."


----------



## WhoozOn1st (Mar 27, 2011)

This 4-minute Metrolink video was somewhat off-topic when I posted it in another thread awhile back, but could hardly be more on-point here:

Metrolink Positive Train Control System

From the "Metrolink Matters" YouTube channel. There's some pretty nice operational footage included - a little Amtrak too. Animated trains are shown running in push mode, and consisting of the new Hyundai-Rotem "Guardian" crash energy management rolling stock. In fact this new equipment is currently running piecemeal in mixed consists with Bombardier bi-levels as it comes online. The video also shows a Utah Transit Authority Comet or two, but these may be gone from the system now; common for a time, but none seen recently.

Perhaps my fellow SoCal residents will enjoy a rousing game of "Name That Station!" while watching the video.


----------



## battalion51 (Apr 9, 2011)

I've watched that before, but I'm pretty sure I found an error in the video. In the two scenes around 1:45 and 2:20 where the Engineer is in the cab and his right hand is on the automatic, it looks to me like that brake handle is in the "Handle Off" position. Not really surprising since you probably don't want to be staging that sort of thing with an actual movement in progress, but a fun little "hahaifoundanerror" moment. (2 points to the first person that gets that reference).

I do have to wonder though, for the Amtrak Intercity trains and freight that are going to operate in the PTC territory, what apparatus will they have to have installed on the motors to operate in PTC territory? What sort of standardization efforts are there so that we don't end up with ACSES in the Northeast, ITCS in the Midwest, and PTC in the west, and none of the systems are compatible with each other?


----------



## jis (Apr 10, 2011)

battalion51 said:


> I do have to wonder though, for the Amtrak Intercity trains and freight that are going to operate in the PTC territory, what apparatus will they have to have installed on the motors to operate in PTC territory? What sort of standardization efforts are there so that we don't end up with ACSES in the Northeast, ITCS in the Midwest, and PTC in the west, and none of the systems are compatible with each other?


Heh heh.... they will have a tall rack in the back of the cab with slots to install modules for each signaling system, just like they do in Europe 

Of necessity a system that is automatically able to stop a long heavy freight train running at 70 max safely and one that is meant to handle fast accelerating and decelerating passenger trains on as little as 90 second headway at speeds as high as 160mph, are going to be very different. The **** that has been sold about the same PTC being usable for all is just that - ****.

Hey this country does not even have the same rulebook that works on all railroads, and even has the same signal aspect meaning completely different and dangerously different things in different rulebooks. And you expect suddenly there to be a single PTC system, even when it is known that such is physically difficult to achieve? Currently I am thanking our starts that at least all the commuter agencies in the north east have gotten their heads out of their collective dark places and decided more or less to adopt ACSES as their PTC implementation.

Actually, I'd be very pleasntly surprised if we land up with less than two different PTC systems leaving aside ACSES and ITCS for the time being.

Diesels that operate on the NEC and then through Virigna already can handle MNRR cab signal, PRR Cab Signal + ACSES, and RF&P ATS and CSX (ex NYC) ATS. So they will need a couple more modules and perhaps one more display element for being California PTC capable, though very little reason to have those installed in engines that are assigned to the east, just like California engines would have very little reason to have ACSES installed. And AFAIK none of the NEC engines have ITCS installed. But in each case taking out one system and installing another system is not a huge effort.


----------



## rrdude (Apr 10, 2011)

battalion51 said:


> but a fun little "hahaifoundanerror" moment. (2 points to the first person that gets that reference). *Conan**?*


----------



## battalion51 (Apr 11, 2011)

2 point rrdude.






I do recognize that there is a great deal of crossover ability in the Northeast (probably largely due to Conrail owning a lot of that railroad at one point in time), and it's the classic example of how it SHOULD be done. But you have come classic examples of how it SHOULDN'T be done, like ITCS in Michigan and PTC on FEC, where their system is only compatible with their system.


----------



## Devil's Advocate (Apr 12, 2011)

Is there some reason why PTC required government intervention to get the ball rolling? Seems like the railroads could have long since standardized this whole process decades ago and already have it up and running by now. Instead they sit and wait until someone else comes along and forces them to do something.


----------



## MattW (Apr 12, 2011)

daxomni said:


> Is there some reason why PTC required government intervention to get the ball rolling? Seems like the railroads could have long since standardized this whole process decades ago and already have it up and running by now. Instead they sit and wait until someone else comes along and forces them to do something.


The same could be said about the Westinghouse Air Brake. I encourage you to go read the story of its implementation.


----------



## jis (Apr 12, 2011)

battalion51 said:


> 2 point rrdude.
> 
> 
> 
> ...


Well, but at least those systems work more or less. The latest round of PTC stuff, production equipment, specially software radio components that are required, are really not even available yet and people are still furiously trying to write the software. Having worked in the software industry for my entire life I find it a dubious proposition that software for a safety critical system will be written tested and deployed in the field in less than a year. But that's just me I suppose.


----------



## Crescent ATN & TCL (Apr 18, 2011)

jis said:


> Heh heh.... they will have a tall rack in the back of the cab with slots to install modules for each signaling system, just like they do in Europe
> 
> Of necessity a system that is automatically able to stop a long heavy freight train running at 70 max safely and one that is meant to handle fast accelerating and decelerating passenger trains on as little as 90 second headway at speeds as high as 160mph, are going to be very different. The **** that has been sold about the same PTC being usable for all is just that - ****.
> 
> ...


Seems like by now with all of the interoperability, equipment pooling, interlining, through running etc. the railroads would have come together to make a universal rulebook so that everything is standardized across the board.

As far as making a system that can seamlessly handle freight and passenger trains,do something similar to what ACSES does and use train type IDs. Each type of freight/passenger train could have a type ID assigned and the computer could switch between a variety of algorithms based on what type of train is involved. Say #1 for passenger 80mph+, #2 for hot shot intermodal 70mph, #3 unit freight 60mph, #4 manifest freight 55mph, #4 local freight 50mph or less. This would limit top speed and the braking algorithm based on train type. Ideally the operating crew would be able to enter in the train weight from the manifest to get the most accurate braking algorithm.


----------



## jis (Apr 18, 2011)

Crescent ATN & TCL said:


> As far as making a system that can seamlessly handle freight and passenger trains,do something similar to what ACSES does and use train type IDs. Each type of freight/passenger train could have a type ID assigned and the computer could switch between a variety of algorithms based on what type of train is involved. Say #1 for passenger 80mph+, #2 for hot shot intermodal 70mph, #3 unit freight 60mph, #4 manifest freight 55mph, #4 local freight 50mph or less. This would limit top speed and the braking algorithm based on train type. Ideally the operating crew would be able to enter in the train weight from the manifest to get the most accurate braking algorithm.


ACSES already does exactly what you say. but it works only with freight speeds limited to 45mph and freight lengths severely limited too. but that is fine on the NEC because those are in general the operating rules anyway. ACSES actually has three classes of passenger trains, 1 of freight and 1 other. The three classes of passenger trains are roughly Acela, Regional and Commuter.

I don't know much about train control beyond what I have read and learned from the experts who do these things. They in general tell me that true high speed and heavy freight do not mix well in automatic operations for numerous reasons. they also tell me that they have dozens of conceptual ideas on how to make it work, but no one has actually gotten one to work in a cost effective and optimum fashion that does not slow things down unacceptably yet. So it is not just a matter of installing one and going with it.


----------



## battalion51 (Apr 23, 2011)

IIRC ACSES was built with four types, Type A, B, C, D. A is Acela, B is for Regionals, C is for Intercity, D is for freight. Whether a commuter train falls into type B or C depends on the trainset. For example an NJT Bi-Level would qualify as a B type, whereas MBTA would qualify as C typ.


----------



## jis (Apr 23, 2011)

battalion51 said:


> IIRC ACSES was built with four types, Type A, B, C, D. A is Acela, B is for Regionals, C is for Intercity, D is for freight. Whether a commuter train falls into type B or C depends on the trainset. For example an NJT Bi-Level would qualify as a B type, whereas MBTA would qualify as C typ.


I actually have the ACSES technical paper on my other laptop, and will have to look this detail up. Will do so later today. But AFAIR it is MARC and Amtrak Regionals that are classified as B and NJT MLVs are classified as C.


----------



## bretton88 (Apr 23, 2011)

Well, the railroads all call their PTC system something different, but they WILL be interoperable. That's part of the FRA guidelines for PTC. They even agreed on a standard last year to implement.


----------



## jis (Apr 23, 2011)

battalion51 said:


> IIRC ACSES was built with four types, Type A, B, C, D. A is Acela, B is for Regionals, C is for Intercity, D is for freight. Whether a commuter train falls into type B or C depends on the trainset. For example an NJT Bi-Level would qualify as a B type, whereas MBTA would qualify as C typ.


Here are the 5 train categories as defined in ACSES from the ACSES specification:



> · A = “Acela Express” (high-speed train) with tilt enabled,
> 
> · B = “Acela Express” (high-speed train) with tilt disabled and ‘Acela Regional’ (Metroliners),
> 
> ...


Apropos, the train category assigned to NJT trains, because none of them are allowed above 100mph, my guess is that they would be classified as C. The MARC Penn Line trains capable of 125mph would be presumably categorized B. But since in NEC South only Amtrak trains operate under ACSES where equipped, actually at present neither NJT nor MARC trains are allocated any category. MBTA is indeed category C.

BTW, the radio link in ACSES carries the following information:



> . Interlocking home signal status (stop or go)
> 
> · Civil speed limits through the interlocking based on switch positions and speed on the exit track
> 
> ...


----------



## WhoozOn1st (Apr 24, 2011)

Sorry to break up the impromptu eastoid convention in the midst of a Metrolink thread (  ), but would the new PTC system be at all compatible with the ATS now used for high(er) speed running south of L.A., or is that just a vestigial Santa Fe remnant that would be discarded in favor of entirely new technology?


----------



## jis (Apr 24, 2011)

WhoozOn1st said:


> Sorry to break up the impromptu eastoid convention in the midst of a Metrolink thread (  ), but would the new PTC system be at all compatible with the ATS now used for high(er) speed running south of L.A., or is that just a vestigial Santa Fe remnant that would be discarded in favor of entirely new technology?


In its simplest form an ATS consists of an indiuctor mounted by the track which is activated when the signal is at danger and which is "read" by the locomotive to activate the brakes.

A PTC system is typically overlayed on the existing signaling system. However, it would most likely render the specific ATS stopping function redundant. Read on if you want a little more background on why and how....

In a very simplified description a PTC system needs to know where the train is located and that it is still in one piece and the speed at which it is running. Of these, in a track circuit based system you get a crude integrity information from the track circuit, and the speed information from the speedometer. Normally the only location info you have is very crude i.e. the train is occupying a track circuit block. The train can compute more specific location info by knowing the location of signals or other marked spots on the track that it just passed and adding to it the distance traveled since then. Then given info about next signal aspect and position of next signal and hence distance to next signal, a brake curve appropriate for the train type can be applied to bring the train to a stop before passing the next signal if the signal is at danger, or speed modulated to meet whatever the signal aspect says.

Now The old Santa Fe ATS I believe is based on a signaling system which is based on track circuit and a very simple stop inductor placed associated with each signals to enforce stop. The loco basically senses the need to stop and applies full service brake (I believe - not fully familiar with that system). This works as long as trains don't travel too fast and signal inductors are placed appropriately to ensure a stop before any fouling happens.

A PTC system overlayed on such a system would typically use new technology to get integrity information. It may get location information from GPS, since the whole idea of the new PTC is to avoid placing anything on tracks. PTC systems are designed to use the signal system that is in place to get signal aspect information, i.e. they are an overlay on the existing signaling system. Signal information will be delivered to the train by radio. Given the current location, speed, next signal location and hence distance to it, and its aspect, the onboard computer will (a) display all this on the console with appropriate warnings and (b) absent appropriate action by the engineer, will enforce the necessary brake curve. So even if the ATS inductors remain in place, in a properly operating PTC situation they should never have to trigger a brake application.

The PTC installed and operational on the NEC and apparently to be installed on many connected Commuter services (MNRR, NJTransit, Springfield, Harrisburg, SEPTA, MARC Penn Line) is and will be based on enhanced coded track circuit cab signal (CTCCS) + ACSES Phase II. Enhanced CTCCS provides speed enforcement based on either the original 4 aspect or an enhanced 9 aspect cab signaling system. ACSES as an overlay provides positive train stop + enforcement of speed restrictions at a finer granularity that possible with the CTCCS, including TSRs (Temporary Speed Restrictions). This it does mostly through Transponders placed on tracks adjacent to the signals. ACSES also provides a radio link for handling TSRs and various other more esoteric functions, like granting permission to pass a failed signal at danger etc.

Incidentally, the system operating on the NEC is a close cousin of the TVM430 system that is used on the French high speed system. It is designed and delviered by the same Alstom in collaboration with Amtrak. Instead of using the more sophisticated coding used in TVM 430, an extended coding overlayed on existing PRR coding is used on the NEC.

So a head locomotive that operates on the NEC and say on CSX to Jacksonville, has to be equipped with the the appropriate antennas and on board equipment to handle ACSES and whatever hybrid system gets installed between Washington and Richmond and then furthermore whatever PTC CSX chooses to install south of there. There is some hope that at least all of the GPS based systems will be able to share a lot of equipment in common, just like all of the coded track circuit based equipment is able to share a lot of equipment in common. Incidentally Washington to Rochmond already has a coded track circuit based cab signaling system.

Now there is a specific technical issue that is still not fully resolved. The requirements of the lineside to train protocol for controlling heavy slow freight trains in relatively sparse traffic situations is quite different from that for controlling high speed passenger trains on dense traffic extremely short headway situations. For the former it is easier to use radio since time is not as much of essence there and communication latencies and occasional failures can easily be worked around. For the latter redundant communications and fall backs have to be designed carefully, or face frequent extremely sub optimal operation while the system recovers from the inevitable glitches. ERTMS 2 based on radio beacons is operational in many places in the world (outside the US) now for 200+mph operation, but that is a very different beast from what the American PTC is designed for. Hence the general comment that the same PTC system does not necessarily work for both slow freight and high speed optimally.

Well, that became quite a long answer to a short question, but as you can see, there are complexities and nuances to worry about regarding PTC, just like for any other safety and security system that is automated.


----------



## WhoozOn1st (Apr 25, 2011)

As a layman I doubt I'll ever grasp all the intricacies of PTC, it's principles and application. However I think I get the basics, and now have a somewhat better understanding of the details. I'll doubtless have to reread it several times, but thank you, Jishnu, for your detailed response.


----------



## battalion51 (Apr 28, 2011)

Point of reference, Full Service is the application that you'd get. Most brake stands have the "marks" of released, minimum, suppression, full service, handle off, and emergency. Handle off is the position that's used when an engine is parked and the parking brake is applied, or it's trailing. Most cab signal systems require you go to suppression in order to comply with a cab signal that has dropped. So if you're plugging along on a Clear signal, and your cab signal drops to Approach Limited then you would have to acknowledge, and make a suppression application until you're in compliance with the cab signal.


----------



## George Harris (Apr 30, 2011)

PTC should not be equated to air brakes. The use of air brakes and automatic couplers had huge operational advantages as well as safety. They allowed longer trains, quicker coupling and uncoupling, and reduced manpower. So far there appears to be little in the way of operational advantages to PTC. IN fact it is regarded by many as a $10 solution to a $1 problem.


----------

