Hacker News Reader

Comment by ww520 | Hacker News Reader

I've worked on two PTC projects, one successful and one failure, after hundreds of millions dollars. The successful one took about 6 years and is still on a trial basis. The failed one had an aggressive schedule but ran out of money after 3 years going nowhere. This thing is not as easy as it seems.

View on HN

I'm interested in your experience, what makes it so hard? The PTC roll-out is not new but delays seem common, it's obviously hard but why? Once we figure it out in one place can that experience be applied elsewhere easily?

Yeah, this is really weird to me. They're talking about installing sensors on particular tracks and the like, after saying that it's GPS-based, but... why? Stick a GPS on the engine, load a database of maximum speeds, get instant safety. What'm I missing?

(Yeah, you have to integrate with the engines themselves, but that seems like not a 6-year project, and especially not once it's been designed and tested. It probably also won't account for "stop, there's something else on the tracks", but just speed-checking seems like it would be a massive reduction of risk with very little complexity...)

Even an app on the driver’s phone that alerts when they’re exceeding the speed limit would have prevented many of the recent crashes because the drivers weren’t incapacitated - just distracted or confused. Many recent cars also know when you’re driving over the speed limit and display an alert. Not billions of $

An AP Press reprint: http://www.dailyfreeman.com/general-news/20171219/engineer-i...

> Engineer in fatal Amtrak derailment might have been distracted by trainee in locomotive

> Investigators are looking into whether the Amtrak engineer whose speeding train plunged off an overpass, killing at least three people, was distracted by the presence of an employee-in-training next to him in the locomotive, a federal official said Tuesday.

> The official, who was not authorized to discuss the matter publicly and spoke on condition of anonymity, said investigators want to know whether the engineer lost “situational awareness” because of the second person in the cab.

Just distracted or confused is a real possibility that is being looked into.

In which case a standard attention system would have worked. The ancient ATS that just stops the train when not cleared.

There is a publicly visible website referenced in some of these articles that showed the trains speed moments before the crash. I believe they also have speed limit information. I wonder if it's possible to write a simple service that consumes this data, compares live train speeds to speed limits and sends an email to Amtrak. Could it be done in the time it takes to ride the train from Seattle to Portland? Quite possibly.

Allowed speed is not as simple as just where you are; it also depends on the trackside signals and how the track in front of you is lined and/or occupied. For example, if you are 1 mile from an interlocking you might be able to proceed at track speed because you will be going straight through it (clear signal) or you might need to slow down to, I.e., 20 mph as you are going to go through a switch to another track (approach diverging signal). One of the main complexities of PTC is getting all that signaling data onto the locomotive, combined with the route and rules, so that it can actually make the right decision. (Keep in mind that on the US's relatively slow freight railroads "cab signals"; I.e. seeing signal indications in the cab of the locomotive, is relatively uncommon. Signals are generally trackside only and are also often 50+ years old. They work fine, but they're not exactly networked in any modern sense. Updating all this trackside equipment is one of the primary costs of implementing PTC.)

I'm going from some old bits I wrote nearly 20 years ago about software estimation here... but some of it may be applicable to other projects.

A bit more recent on it can be read at http://www.qsm.com/blog/2016/impossible-region-revisited

Given the estimate of how long something takes, and dividing it up amongst the people who can do it, and then say... we're going to deliver it in 75% of the optimal time (based on the size of the project - increasing the speed of getting it done by adding people and having a more aggressive schedule)...

Well, for the data set of 20,000 projects there were 750 that were trying to deliver in less than 75% of the optimal time. Of those 750, none were able to be completed in that time.

Granted, that was for software projects. But I suspect that beurocratic projects have similar problems. Need it done faster? Add more people. Have more people? Need more meetings. Have more tasks going on at once? More likely that someone is going to be waiting on another task getting complete because of a bad (overly optimistic) estimate / deadline. Have more people doing nothing at any given time? Spend money faster... and run out of budget all that much faster.

I don't disagree but I was hoping for something more compelling than "bad project management".

I'm sure there are other complexities added in when there are pieces of iron rather than silicon involved... and safety regulations start chewing up time and reworks.

But overall, the "if it is possible to do, but someone put too low of a cost in the budget or tried to get it done faster than the engineers said it was doable"... well, isn't that bad project management that promised too much and underdelivered... and then got a canceled project? Is there something else it could be?

There are a number of reasons, typical of large projects. Scope creep, mismatched of experience/expertise/organization-setup, unrealistic expectation, insufficient funding, complex vendor/system integration, and long testing cycle.

Funding for PTC inevitably is politically motivated. There are petty projects or requirements tacked onto the main project by various stakeholders, in regardless of technical feasibility.

Railroads are usually operation centric companies focusing on day to day operation. Their expertise is not at designing, engineering, or building things. Outside vendors are brought in to bid on the PTC project. Due to high risk and high liability, only a few companies have the financial backing to put up the surety bond to bid on the project. Sometimes there's only one bidder. The competent ones know the high cost and long time to build the thing and decide to stay put. The less competent one misjudges the time and cost, provides the lowest bid, and becomes the general contractor.

Nobody has a complete set of technologies to implement the entire PTC project. The general contractor has the financial mean but not the technologies. Numerous subcontractors bid on various parts of the project to join the party. The selection of these subcontractors and their technologies sometime are political. The general contractor might not like a sub but is forced to take on the sub because of pressure. A working combination might not be transferable to different railroads due to different vendor/technologies winning the bids.

Pretty much all the vendor technologies are proprietary, and integration among them is a nightmare. Some of them sound good on paper and on promise but fall short when the rubber meets the road. In the failure case I cited above, one fortune 500 company acting as a sub provides a critical part which simply cannot be integrated with the rest of the system. It was too late and too expensive to pick another vendor and the project went into limbo due to running out of funding.

The testing cycle is very long. You are retrofitting a busy daily running railroad live, with people's lives at stake.

Reply on news.ycombinator.com