Hacker News new | past | comments | ask | show | jobs | submit login
The Case of the Missing Fuel: The story of the Stockport air disaster (admiralcloudberg.medium.com)
94 points by yarapavan on Oct 25, 2022 | hide | past | favorite | 46 comments



Admiral Cloudberg's write-ups are excellent. The MH 370 one is a fascinating read as well, but I'll recommend my favorite air disaster writeup: https://admiralcloudberg.medium.com/lesser-of-two-evils-the-...

Nobody dies, the pilots do exactly the right thing, and the system works! Also, the failure mode and investigation is super in-depth.


That is definitely an amazing one. Here's a redacted summary of the story, to convince everyone to click:

We teach pilots never to do X. The pilot of this doomed flight decided to do X. There is no doubt whatsoever that by doing X, he saved the lives of 116 people who otherwise would have died, and doing X was therefore praiseworthy. That said, not only will we continue to teach pilots never ever to do X, we'll also convince you that this is still the right thing to teach!

(Also shout-out to the pilot monitoring who upon realizing the PF was doing X, exclaimed, "[expletive]! Don't do that!", and then proceeded to help with X, without which help not all the lives would have been saved. An example of where sometimes CRM does mean "blindly follow".)

This is an excellent introduction to the intellectual field of aviation disaster avoidance and learning from disasters.


I love their write-ups, but I hadn't seen that one before. Crazy story!

It's easy to imagine how scared/shocked Gruseus must've been by a new-to-him pilot trying to abort that late... glad he trusted him in the moment.


This story raises a question I have idly wondered - why do runways seem only just long enough for their intended purpose? That is, I see planes that seem to takeoff fairly close to the end of the available road.

I want to assume there is some good reason that is not, "we didn't want to pay for more runway".


One reason is that the planes are taking off with reduced thrust, which produces less noise, uses less fuel, is easier on the engines, etc. That is, they can calculate and use a thrust setting towards the minimum required given the available runway length, rather than full trust to get airborne as soon as possible.


I don't see that, airplanes lift off with plenty of room.

BTW, bombers in combat would typically be overloaded with bombs and fuel. They needed every inch. If the runway was longer, they'd just get more bombs and fuel put on. Any hiccup in the engines meant certain fiery death.

My dad (AF pilot) would always hang the tail over the back of the runway, as he wanted every inch. Old habits never died :-)


They tend to follow precise regulations based on what planes will use it, altitude, ambient temperature etc.

https://www.faa.gov/regulations_policies/advisory_circulars/...


> "we didn't want to pay for more runway".

It is a factor (a normal factor of engineering), alongside “there’s no space for more runway” (because you also need blast pads, stopways, clearways, … which are not the runway itself), and also for noise and efficiency concerns a plane is not going to do a full-out takeoff if it doesn’t need to.


> I want to assume there is some good reason that is not, "we didn't want to pay for more runway"

This is how the entire world of engineering works. Overbuilding everything is much worse for society due to the massive costs.

Doubling runway lengths cumulatively would consume hundreds of thousands of acres in the US alone. Many of these airports are right in cities so you’re talking about displacing hundreds of thousands of people.

If you could stomach that, airlines with real engineers would just calculate that they can now land much larger and/or heavier loaded planes and do such.


It doesn't seem the NTSB recognized that the root cause is a choice of V2 and runway length too short to reach V2, try to rotate for 3 seconds, think about the problem (reaction time), and then apply reverse thrust and brake to a standstill while still on the runway.


V1 is the takeoff decision speed. Vr is the rotation speed. V2 is the initial climb speed.

V1 is the speed that’s relevant here and I think the crew decision to abort well past V1 is both completely appropriate and unusual. There often isn’t enough runway to reach a chosen V1 then Vr then try to rotate them realize you’ve got an unflyable airplane then start the abort and still stop on the pavement or EMAS overrun.

Normalizing post-V1 aborts would almost surely cost more lives than it saves. Taking a problem into the air is often the safest course of action.


In this accident, because of gusty conditions, the pilots had decided to delay rotation until the aircraft had reached V2.


They delayed rotation until a Vr higher than computed, which might have incidentally been the same number as the computed V2 speed.


They deliberately chose V2.

https://www.youtube.com/watch?v=61_TqeITE3I (see about 5:30 in the video)

Not sure the point you are making: it wasn't V2, just a number equal to V2? What?


Aviation speeds are named by their operational purpose. In computing, if I share a password between site A and site B, when I login to site B, I'm still logging in using my site B password.

Start at 5m20s where the definitions are given. V1 is the decision speed. Vr is rotation speed. V2 is climbout speed.

What this crew did was compute based on a given headwind to find a V1, Vr, and V2 and then chose an operational Vr that was the same numeric value as the computed V2. That doesn’t make the speed at which you rotate no longer the Vr, but rather the value of Vr be the value of the previously computed V2.

This is laid out at 6m34s where the presenter says they picked the Vr to be the value of the computed V2.


There's actually an interesting philosophical issue here that has applications to type theory and computer science.

https://en.wikipedia.org/wiki/Extensionality


Mentour Pilot has an episode on that accident.

https://www.youtube.com/watch?v=61_TqeITE3I


When you look at an older artifact (tool, airplane, source code), and ask yourself: Why did they do it this way?

A lot of times, they just made things work. They didn't understand the optimal solution or they didn't have access to resources to implement an optimal solution.

Airplanes up until the 1960s (and some beyond) had very few automatic systems because there was simply no way to automate them (aside from some mechanical computers and small amounts of electronics). The aircrew were physically moving control surfaces (sometimes with assistance) or as in this case, physically moving a knob that rotated a valve.


Sure, but automation wasn't so much the problem here - this was mostly a human factors/human-machine interaction problem. Quite a few people died due to similar problems over the history of aviation - here, they just needed to have the levers a bit more visible, and/or having it click into the closed position (a little notch and a spring on the lever) and it would make it very difficult to make the same error. Other times it was putting important levers too close to each other, having one warning bell that sounds too much like a different one, etc. Like much of aviation, a lot of these lessons were learnt through a lot of accidents and fatalities.


I remember reading something similar before, where I think the B-17 had very similar flaps/landing gear controls, and placed close together on the panel, where pilots on short final would pull one lever rather than the other https://ww2aircraft.net/forum/threads/b-17-crashes-due-to-co...


One wonders how many WWII planes were lost in 'freak' accidents like these during the war, the cause never being investigated thoroughly since, heck, there was massive carnage going on all the time in the skies and as long as the accident rate was low enough it was acceptable.


I've read at least one writeup from 1960s about A-3 Skywarrior ending up crashing while practicing touch-and-go (where you touchdown, then immediately take off again to do another practice round).

The pilot has accidentally released the drag chute instead of stowing landing gear, because the controls for both were a) similar b) located near each other c) not clearly visible from left seat.

Afterwards, the drag chute release was moved way elsewhere.


I thought his might be another case [1] where there was an imperial to metric conversion problem that led to insufficient fuel on board and a semi miraculous glide down landing where thankfully everyone walked away. The story is far more nuanced on examination and for those interested Tim Harford [2] has an excellent Cautionary Tales podcast episode outlining the details within a wider context.

[1] https://www.nytimes.com/1983/07/30/us/jet-s-fuel-ran-out-aft...

[2] https://timharford.com/2022/09/cautionary-tales-when-the-pla...


But that podcast gets the story horribly wrong. It wasn't a metric-to-imperial conversion error; it was a metric-to-metric conversion error ... The pilots and ground crew had to convert from litres to kilograms and made a mistake by using the wrong conversion factor (they used pounds to kilograms if I recall correctly).

It's crazy that he brings an "expert" on to the show and they still get it wrong.


In defense of Tim and his scrupulous due diligence, the podcast is very clear wrt to the issue but perhaps the precision of my language was less so on examination I should have called it an "imperial vs metric" conversion error as in one of substitution not one of the math involved which my language allowed you to assume I was talking about. Not sure if it rises to the level of getting the story horribly wrong but you are entitled to an opinion.


I listened to the episode (a while ago, not when I saw your post), and I'm 90% sure they stated quite explicitly that "they made a mistake converting between imperial and metric and only filled up half the tank".

I'm going to allow some possibility that I got it horribly wrong and the podcast did, in fact, get it right, but I don't believe that's the case.


More to do justice to the story and its twists and turns this is courtesy of an AI transcription running on my podcast player (Snipd) :

>This story is a bit like an onion. It's got layer er on the most superficial level, that sort of papery outer layer of the story, if you like.

Why did this plane have too little fuel? The very simple reading is

Speaker 1 They had a unit conversion error. So the people who were meant to be fueling the aircraft saw a number. They assumed it was pounds of fuel, when in fact, it was kilograms of fuel. And the reason they're even doing this in mass because if you fill up a car, you don't put the fuel in by mass, you do it by volume.

Volume changes based on the ambient temperature. As things warm up, they tend to expand if they cool down, they tend to shrink. And if you're flying in aircraft, it's important you have the amount of fuel you're supposed to have. And so they made sure, instead of using the straightforward volume, they were going to use mass instead.

And sadly, it was that attempt for extra precision that opened up the door for tis unit conversion era.

...

>Speaker 1 And it was even obscured by one layer, because when they were doing the calculations, they weren't actually doing it in terms of the direct mass. They were using something called the specific gravity, which is tha cod measure of the density of the fuel. And so they used that to get back to the volume that they then had to put into the plane. And because there was this extra one layer of an opaque bit of putting it into a slightly different way of looking at it.

They didn't realize that the units behind the specific gravity were based on kilograms,

Speaker 2 And they assumed that they were based the old weigh on pounds.


The Wikipedia article on it says they accidentally used the pounds/litre conversion factor instead of the kilograms/litre one.


Yes, that’s an error converting metric to metric by accidentally using an imperial/metric pair.


See also the Azores Glider, where a fuel leak was made worse by rebalancing the fuel between tanks -- resulting in both engines dying instead of just one.

Fortunately the story of the Azores Glider has a happy ending; that set a record for the longest unpowered glide in a passenger aircraft, at 121 km, and made a successful emergency landing with no fatalities and only two serious injuries.


"this result was so unexpected and bizarre that the pair concluded they must have made a calculation error and decided not to report the details of the incident to the airline" I'm no pilot but my gut reaction to reading this is <insert facepalm emoji>.


In his (also excellent) article about the AF447 crash, the same author explains that the stall warning on the Airbus 330 went off when airspeed dropped below 60kt, because such a speed was considered impossible in flight.

This is believed to have been a contributing factor to the confusion of the pilot flying: the more he pitched up, the more he stalled (as would be expected)... yet it made the warning go off.

It's only natural to shy away from outlier values. I think the reason is that we want to place any input into a system, and outlier values don't fit, so we simply ignore them.

It takes a special mindset to focus on outliers or even to accept them.


I hate it when articles do this. 90% of the story, with a cockteasing line about why the plane went down, then CUT to the full story in extremely deep detail. I understand that the author is trying to circumvent short attention spans with a short version to draw the reader into a longer article, but please don’t information bait

give the information in the beginning and then I’ll decide if I want to know a detailed history of the company the plane was owned by, or all the alternative names of the model


It sounds like you are looking for a single cause [0]. Increasing safety in air travel means deeply examining whole systems.

0. This is not meant as an accusation, it's just how I read your comment.


my issue is with how the article is structured. tell the story in miniature with a teasing line about the crux of the technical failure, then plough into acres and acres of detail with the teased information buried somewhere underneath. it’s unpleasant and unnecessary

yes the failure as a whole may have been structural, but that doesn’t change how the author withholds information in order to keep your attention on what are in fact largely extraneous details


In paragraph 106,

> it was possible to accidentally transfer fuel between the Argonaut’s eight fuel tanks, potentially cutting off one or more engines from its fuel supply, without anyone noticing


These kind of incidents are why most commercial-use three/four engine planes usually had flight engineers. The DC-3 and DC-4 were exceptions; the Boeing 307 and 377, DC-6, DC-7, and Constellation reciprocating engine models all required engineers. Likewise many early three and four engined jets also were flown with engineers. See: Boeing 707, 727, early 747, DC-8, DC-10, L-1011.



Looks like a study of adding more controls vs likelihood of screwing things up. Are modern fuel transfer systems this complicated?


We've learned a lot in interface design since then and partially because of accidents like this. There's a couple reasons a situation like this is probably highly unlikely; on a 737-800 for example the fuel pump controls and panel are now part of the overhead controls [0] now, the feed controls aren't analogue so you can't accidentally have it partially open to the crossfeed position, and finally the fuel levels and operation are computer monitored now so if you were getting dangerously low on fuel you'd get warnings.

[0] https://i.stack.imgur.com/vw59I.png


>We've learned a lot in interface design since then and partially because of accidents like this

But if you have any illusions that such a thing couldn't happen again look no further then the 737 MAX disasters. It shows how decades of stringent safety standards and lessons learned can be ignored in order for a company to earn a few dollars.


Sure issues can recur but this specific problem is highly unlikely to because the issues that lead to it don't exist. Valves aren't directly actuated any more so it's impossible to leave them in a cross-feed configuration without leaving the switch in that position. Also planes can fly with half their engines out now so even if you did lose an engine to accidentally starving it of fuel today the plane would still make it back to land. So much of the design and engineering that lead to this problem just don't exist in modern planes.

The MAX problem also wasn't a recurring problem it was a new one driven by money because of the huge incentive to maintain type compatibility so Boeing or it's customers wouldn't need to completely retrain all the pilots with 737-* type ratings. That combined with the flimsy regulation and oversight provided by the FAA let a safety critical system through with only one sensor driving it's function.


> Sure issues can recur but this specific problem is highly unlikely to because

These days the automated system to maintain fuel to the engines would fail when the sensor in the fuel tanks malfunctions. It would pump fuel overboard trying to pump fuel from an empty tank into a full one.

Obviously I made that up. The 737-max debacle shows us that we are past peak safety of aeroplanes. We rely too much, now, on automated computer systems which we (computer programmers) know are very expensive to get right. It is much cheaper to have them "almost perfect".


> we are past peak safety of aeroplanes

I'd bet against that. Deaths per passenger mile have been decreasing continually for decades: https://en.wikipedia.org/wiki/File:Fatalities_per_revenue_pa...


> Deaths per passenger mile

I prefer deaths per journey.

Aeroplanes fly huge distances, journeys that would not be made otherwise. Makes " Deaths per passenger mile" daft IMO


I suspect that looks pretty similar?

Might actually be getting better, since takeoff and landing are the most risky and with ETOPS we're doing a lot more point to point and a lot less hub and spoke.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: