Reports: MNR engineer ‘zoned out’ prior to crash

By · Published in 2013

As more news breaks concerning Sunday’s fatal Metro-North derailment, it’s looking more and more likely that human error, rather than a train malfunction, was to blame. According to multiple reports this morning, William Rockefeller, the train’s engineer, either “zoned out” or momentarily lost consciousness as his train sped into a sharp curve at over 80 miles per hour. This development contradicts earlier reports from Sunday that the brakes failed.

The Post led with their story on the front page this morning, and it has since been picked up by DNA Info, The Daily News, and The Wall Street Journal. One source told the News that Rockefeller had no memory of the crash while another compared the engineer’s state of mind to a day dream.

“I think anybody who’s ever driven a car and sort of gotten to that place where you’re not really conscious, and then you snap yourself out of it, that’s in effect what happened,” The Journal’s source said. “That is exactly how Billy described it.”

The various reports diverge a bit in the details. The Post says Rockefeller “zoned out” and was awoken by a warning whistle that the train was going too fast. DNA Info says that the “rumbling of the train roaring through the head of the curve awakened Rockefeller.” Either way, the pendulum is swinging toward some form of inattentiveness by the engineer and human error.

We won’t know the official ruling until the National Transportation Safety Board issues its findings, and Rockefeller has unsurprisingly lawyered up. But questions are already swirling surrounding the role technology could have played in preventing this incident. A positive train control system, in the planning and funding stages, could have automatically slowed down the train in Rockefeller’s moment of distraction. Ted Mann summarizes:

Rail safety experts said that advanced train control systems would likely have prevented the accident if the derailment was a result of speeding. Systems to automatically slow or stop trains before collisions or derailments can occur are in various stages of development on commuter rail networks across the country, thanks to a federal law that requires they be installed by 2015. But many railroads, including Metro-North, say they can’t meet that deadline, citing technical complexity of the systems, lack of radio spectrum, and other pressing needs for scarce funding.

I’ll have more on railroad safety lately. For now, the latest reports indicate that PTC may not be ready until 2019, but area politicians are starting to make some noises that they aren’t happy. Needless to say, the pressure will now be on the MTA to bring some positive train control system to its railroads sooner rather than later

Categories : Metro-North

48 Responses to “Reports: MNR engineer ‘zoned out’ prior to crash”

  1. Andy K says:

    One issue – why is there a 30 mph curve on this line? This would be like a traffic light in the middle of the freeway.

  2. Jason R. says:

    As someone who frequently drives long distances on highways and has caught himself in fits of “highway hypnosis,” I’ve often wondered how much of an issue this is for train engineers. Is it conceivable that engineers might be more prone to this because of the relative monotony of rails, especially when expressing? The engineers that run the Amtrak Acela between Providence and New Haven come to mind.

    • Stephen Smith says:

      The Northeast Corridor has PTC (ACSES, I believe), so it’s not an issue.

    • Larry Littlefield says:

      Driving a train is an easy job for what you get paid except for two things:

      1) You always have to be on time. You can’t come in a half our late and work later to make up for it.

      2) You have to concentrate constantly. I’ve heard it described as watching the same movie over and over again for 8 hours a day for years, trying to pay attention to see if something is different this time.

      I understand why this could happen to a train operator, truck driver, etc. But it is their job to avoid it. If a machine could do it better…

      • SEAN says:


        A little food for thaught & this is in no way justifying the engineers actions or lack there of.

        Socially as a society, we become condissioned to multitask. This includes driving while doing something else since being more productive with ones time has become more importent than actually getting the job done correctly. Unfortunately, tragic situations like this are the result of such a mindset. Some will be in denial that what I’m describing doesn’t exist, but all you need to do is look at the people around you or at your own actions to understand what I’m saying cause we ALL do it.

        A friend of mine works in a grocery store & has told me time & time again how so many customers yack on the phone, send texts or check Facebook while on the check out line. It drives him insane as everyone else behind needs to stand & wait until that person is finished.

        • Larry Littlefield says:

          I’ll be very angry if the engineer was “multi-tasking.”

          But as another commentor noted, the possiblity of “zoning out” on a long straight highway is something I can understand. Although the personal qualities an engineer has to have is exactly to avoid that kind of loss of concentration.

  3. Kai B says:

    Does anyone know how the existing safety systems on Metro North work? From my understanding there’s a dead man’s switch and cab signaling.

    Everyone seems to focus on the lack of PTC, when, at least from my understanding, the existing systems could have performed better.

    It does appear, by some of these “anonymous source” reports, that the engineer was “woken” by a speed alert, which allowed him to at least attempt to stop the train, which may have prevented this from becoming an even greater tragedy.

    But couldn’t there have been an earlier warning if the existing systems had been programmed differently?

  4. Frank B says:

    I bet the driver was texting. Driving a train is like driving a car, you reflexively slow down when there is a curve, a traffic light or danger ahead. One just does not zone out provided there was no distraction. The train driver had to have been distracted by something like a text. He probably thought he was further from the curve than he was, looked down and read and or send a text. When he looked up, it was too late. Sorry for the folks that died. This is a tragedy. The blame is on the driver. He did not take his responsibility seriously, otherwise this would not have happened. There is no excuse.

    • Epson45 says:

      First of all, the person OPERATES a train. Secondly the sources can confirmed he did not text or made a phone call while operating the train.

      Still the person should have been drinking some coffee before operating to Grand Central.

    • aestrivex says:

      Your rather exceptionally critical comments would be completely justified if you had even the slightest substantial evidence for this speculative accusation.

    • SEAN says:

      bet the driver was texting. The drivers cell phone was taken as part of the investigation. Until the facts come out, don’t speculate.

    • BBnet3000 says:

      Ive zoned out in a car and come into a curve too fast before, though not so fast that I flew off the road…

    • Chris C says:

      I was wondering when we would get the usual uninformed ‘the driver MUST have been texting’ comment without one shred of evidence that he was.

      Read nothing into the investigators examining his phone as it is pretty much standard practice these days along with alcohol and drug tests.

      • SEAN says:

        was wondering when we would get the usual uninformed ‘the driver MUST have been texting’ comment without one shred of evidence that he was.

        When did we become so reactionary to every news story? I didn’t get the memo.

        Read nothing into the investigators examining his phone as it is pretty much standard practice these days along with alcohol and drug tests.

        Oh I know, but since the topic of texting was mentioned, I just braught it up in that particular context.

        • Chris C says:

          You know I saw on one board that the same accusation was made that the pilot of the helicopter involved in the Glasgow crash last Friday ‘must have been texting’. So yes it does appear to be standard practice these days – even if totally uninformed.

          But my response was to ‘Frank B’ rather than you.

          At least you did mention that it was too early to speculate and we should wait until the investigation was finished.

          Same with that just because someone has a drugs / alcohol test that they must have been high / boozed up. Again standard practice. Not just in the US but also in the UK and elsewhere as well.

    • Alon Levy says:

      Driving a train is like driving a car, you reflexively slow down when there is a curve, a traffic light or danger ahead.

      No. It very much isn’t. Trains decelerate far more slowly than cars, while driving faster. The Hudson Line, by no means a high-speed line, has top speeds higher than those of Interstates: 70-75 mph on the inner parts, 75-90 on the outer parts. With top-line EMUs, this translates to stopping distances approaching a kilometer. And the loco-hauled trainsets are not top-line EMUs. Trains have to have signals precisely because stopping distances are too long for the visual navigation car drivers use. By the time the train driver sees the curve, it’s usually too late, and the same is true of seeing another train on the same track.

  5. OK, here’s a question. Doesn’t MNR have at least an active train control system in place that will apply the brakes automatically if the engineer blows by a cab signal for a speed restriction? Forget the arguments about the PTC system they want to put in place. Should the technology in place now have helped prevent this? I don’t know enough about how some of this tech worked, but I kind of feel like the ATC should have forced the train to slow down. Is this something that can be bypassed by the engineer? Just throwing that out there.

    • MNCR’s ATC system only applies a penalty brake application when the MAS that that equipment runs on is exceeded by 3mph or more. In this case, it would not have taken action until the train was traveling in excess of 93 mph.

      The cab signals will chime in if the indication is anything less than Normal, but in this case, it appears that the indication was Normal so the Cab Signal system would not have done anything.

      • That seems to defeat the whole purpose of safety systems like ATC if you ask me. I thought the whole idea of it was if you’re not doing what the signal indicates is OK for you to do, then the system will stop the train.

        • Epson45 says:

          The engineer needs to be fully alert at all times. I doubt this case with the current safety equipment, wouldn’t help this tragedy at all. They would probably lower the speed limit when approaching the curve. MTA needs to get PTC rolling out all Metro-North & LIRR lines ASAP, but they are way behind schedule.

        • Alon Levy says:

          Yes… but it’s more complicated than this. Any primitive train control system can figure out if the track block ahead is occupied and automatically stop the train – the subway has such a system and to my understanding has had one since day 1, and the mainline automatic train stop (ATS) systems developed in the 1920s had a similar capability.

          Enforcing speed limits is also easy, if the speed limit is static, in this case 90 mph. There are cars today that won’t let you drive faster than 100 mph.

          Enforcing variable speeds is harder. The system needs to be able to understand multiple signal aspects, which requires a method of communication between the signals and the on-board ATS system. It’s all been done before, for decades (e.g. on the LGVs and on German mainline rail), but it’s harder. Amagasaki did not have such speed control, so when the train driver ran too fast on a curve, the ATS system didn’t stop him and the train derailed and crashed into a building.

          In addition, older train control systems can only handle pre-programmed speed restrictions – say, 30 mph, 50 mph, 70 mph, and 90 mph – whereas on American commuter lines, generally any speed in increments of 5 mph is possible. Modern signals can handle any speed, but again it’s nontrivial.

          The FRA’s PTC mandate requires an additional level of complexity: temporary speed restrictions, such as those imposed on adjacent track to a track that has workers doing on-site maintenance. The communication between the tracks and trains becomes even harder, and the most modern systems need to also distinguish different classes of trains, with different deceleration profiles, while also knowing where exactly those trains are located at any given time. GPS does not provide sufficient reliability or precision. Where there’s a mature signaling system, e.g. in Europe, transitioning to these new capabilities takes decades of work, and billions spent on IT procurement with obligatory cost overruns. Safety-critical code is hard.

          None of this means Metro-North has any excuse for dragging its feet on the PTC mandate. The hard part of developing the signaling system was already done in previous decades, with plenty of pain in Europe and at least one fatal crash in Belgium caused by non-automatic signaling during the switch from older signals to ERTMS. The US is pretty much a blank slate for modern rail; about the only special features that are modern enough not to need changing and pervasive enough to be hard to change are the platform height (which is actually good – it provides level-boarding onto high-floor single-level trains), the LIRR and Metro-North third rails (but not the 11 kV catenary, which can and should be 25 kVified), and the M7, M8, and Silverliner V fleets. The signals are all ancient, with the exception of ACSES, which is a lot like ETCS Level 1, warts and all.

          The modern system has already been developed and has a large number of vendors. In Denmark, where intercity rail is relatively undeveloped by European standards, they decided to scrap everything and replace all signals by ETCS Level 2, which is a de novo system where Level 1 is an overlay. The cost is a little more than a million euros per kilometer, exclusive of 30% contingency (link, so at Metro-North east of the Hudson, exclusive of the mainline New Haven Line, it would be about $500 million, total. Including the New Haven Line, even though that pot of money should be paid by Amtrak, it’s $650 million. That’s 6 to 8 years’ worth of salaries for ticket punchers, a job description that has no place on a modern commuter rail system.

          • Billy G says:

            And why can’t this all be done with access to military-grade GPS and wireless signalling for communication with home base? Power the unit off of local power, have secondary capture of local gauges to ensure all readings are in-line.

            All speed restrictions are stored by tight coordinate and direction of travel. If there’s a need to report the track number, that should be handled via some visual recognition sensor on the unit on the front or back of the consist.

            Why replace 1940’s technology with 1980’s technology if this is 2013??

  6. orulz says:

    He did seem to have a habit of working overtime – even looks like more than average compared with other locomotive engineers, but not egregiously so. I wonder if the question of being overworked will come into play here. I have heard some employees at MNRR and LIRR will “pad” their salary by working a lot of overtime for the last year or two before retirement, in order to secure themselves a fat pension.

  7. pete says:

    So what happened to the ATC penalty brake? Bypass switch on?

    • MNCR’s ATC system only applies a penalty brake application when the MAS that that equipment runs on is exceeded by 3mph or more. In this case, it would not have taken action until the train was traveling in excess of 93 mph.

      • Kai B says:

        So the MAS on the stretch of track directly north of the curve is 90? What about the curve itself?

        All I keep reading about in the media is a “speed limit” and that is referenced as 70 and 30 respectively. I’m guessing that’s just MNCR operating code?

        • The ATC system is set to kick in when the train is traveling at 3 mph or over the MAS. There is only one setting, so it is set to the maximum speed that train would operate in (in this case with the maxi-bomb’s, that would be 90mph).

          There are “speed limits” for every inch of the railroad. For passenger equipment, the speed leading up to the curve from MP 33 south to MP 11.5 is 75 miles per hour. At MP 11.5, the speed limit becomes 30 mph.

          There are also various permanent, temporary, and very temporary speed restrictions set in place all over the railroad. These can be in place for any variety of reason from smaller curves to lower speed interlockings, etc.

          It is the train crew’s responsibility to keep track of and run according to all of the speed limits and restrictions on the system. ATC only enforces the absolute maximum they could be traveling.

          • pete says:

            So, even in the GCT ladder switches, the electronically enforced speed (cab signal display), will say 90 mph, and unless you come up behind a train, it will be continuously 90 mph on the cab display from GCT to Poughkeepsie?

            Does MNCR part NH line have the same concept of the electronically enforced speed being 90 mph everywhere unless next block is occupied?

            That leaves majority (except for 90 mph on paper sections, which are identical to the ATC pulse code of track speed i that section) of speed limits to be defined on paper, and to be self-enforced on the honor system by engineers and supervisors, correct?

            Also, is Metro North a “4 aspect 100 hz” PRR Pulse code or not ? and the 4 aspects being, electronically enforced, 20-30-45-unlimited? or does MNCR also do 250 HZ codes?

            Next, why doesn’t Metro North set the “clear” code for a speed restricted on paper block, to the matching ATC speed if an ATC speed matches the paper restriction? If the track block has been 30 or 45 since day 1, why isn’t the maximum ATC code for the track 30/45 instead of 180ppm/270ppm (unlimited speed for MNCR fleet) codes?

            Obviously if the limit is 60 mph on paper, and under 4 aspect, there is no code for 60 mph, the electronic speed will have to be unlimited.

            • BenW says:

              I believe what Patrick was saying is precisely that the “enforced” speed is not the speed on the cab signal display—the ATC equipment functions like a governor on a diesel engine that prevents it from running at a speed that is considered unsafe for the equipment, but doesn’t prevent you from running through a school zone at 40 mph.

            • Yes, Mr. W picked up on the gist of what I was trying to say. The ASC system only physically enforces the Maximum Allowed Speed for that piece of equipment. There are four signal indications that are transmitted to the cab by the signalling system:

              N – Normal – MAS (**not necessarily 90mph, but whatever the speed limit is on the track you occupy)
              L – Limited – (45mph passenger/25 fright)
              M – Medium – (30mph passenger/15 freight)
              R – Restricting – (a speed that will permit stopping within 1/2 the range of vision, looking out for train, obstruction derail or switch improperly lined, looking out for broken rail, and not exceeding 15 MPH for the entire movement).

  8. indicadores says:

    Thank you for any other informative site. Where else may I am getting that kind of information written in such an ideal method? I have a project that I’m simply now operating on, and I’ve been at the glance out for such info.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>