Amazon cargo plane crashes in Texas
wsbtv.com
wsbtv.com
When this is all over, we'll know exactly what went wrong. We'll see the FAA issue guidance or rule changes that will ensure it doesn't happen again. And then we'll somehow see an even further reduction in airline crashes.
I hope that in a few more years, as more companies join the industry, we may see a similar pattern start to evolve in the space launch industry.
http://nickfoy.com/blog/2018/4/7/good-intentions-dont-work
For example, if an admin bungles a copy/paste shell command and it causes an outage, instead of punishing the admin for not wanting hard enough to do it correctly, they'll change the process so it doesn't rely on admins copy/pasting shell commands.
I've found it very beneficial, and the concepts we learned have helped me inn almost every aspect of understanding the complicated world we live in. I've taken these concepts to two other companies now to great effect.
https://www.amazon.com/Field-Guide-Understanding-Human-Error...
https://codeascraft.com/2012/05/22/blameless-postmortems/
https://codeascraft.com/2016/11/17/debriefing-facilitation-g...
https://www.oreilly.com/library/view/velocity-conference-201...
Every time there's a data breach, an agency would investigate with the same thoroughness they do in aviation.
Then, National Geographic could have a spin off show called Data Breach Investigation (their aviation show is called Air Crash Investigation in the UK, I think it's called different things in different Countries.)
A man can dream...
The problem with software, which makes it so unlike hardware, is that we can use so much of it, the diversity is huge.
Everything is software now. So much firmware (which is software), and so much hardware that cannot run without software. Your refrigerator, your dishwasher, your car, airliners -- the trend is for everything to be software now.
It is easy to build a finite state machine for a dishwasher that is fairly reliable. Likewise, consumer jet code that hits safety considerations is heavily tested and audited...and the FAA cares about it whenever it causes a plane to crash, leading to a lot of regulations on how the code is vetted.
Gun regulations are a great example of good intentions, bad implementation due in part to ignorance, and industry resistance/interference. Another is PCI which is a self regulation that's often to vague or specific to be useful.
I’m not sure what the right balance is - the more standards and compliance there are, the more innovation suffers. On the other hand, without standards or legal responsibility, it makes sense for companies to play fast and loose with security, privacy, and stability in favor of features - a consumer is going to pick a better product based on UX, features, and cost, not based on security they have no way of judging.
We know some very good ways to build reliable software. It's just that most industries can't / don't want to pay the costs associated with doing so.
The don't-know / don't-want distinction is functionally irrelevant, but I have a minor tick about it because asserting the former is often used to avoid admitting to the later.
Legacy IBM and ATT, for all their cluster%_$^!s, were amazing at engineering reliable systems (software and hardware). Maybe that's not practical nowadays, outside of heavily regulated industries like military / aerospace, because markets have greater numbers of competitors. But we do know how.
An accurate and modern truth would probably be "We don't know how to quickly build reliable software at low cost."
And so you’re right, maybe my statement is a little bit of a simplification, but not by much. The amount of man hours it would take to prove that the Linux kernel had no bugs according to some specification would require an absolutely prohibitive amount of time. As such formal verification is so prohibitive that only the most trivial systems could ever be proved.
This is pretty similar to saying that we don’t know how to build bug-free code. We need a paradigm change for things to get better, and I’m not sure it will happen or if it’s even possible.
You don’t need anything fancy – but you do need to understand your requirements and thoroughly simulate and verify the intended behavior.
Would that be a better world?
Sure, I hate it when my word processor crashes. On the other hand, I really like having a word processor at all. It has value for me, even in a somewhat buggy state, more value than a typewriter does. Would I give up having a word processor in order to have, say, a much less buggy OS? I don't think I would.
I hate the bugs. But the perfect may be the enemy of the "good enough to get real work done".
It goes without saying that if we had more time, there would be fewer bugs.
But there are also things (tooling, automation, code development processes) that can decrease the amount of bugs without ballooning development time.
Things that decrease bugs_created per unit_of_development_time.
Automated test suites with good coverage, or KASAN [1, mentioned on here recently]. Code scanners, languages that prohibit unsafe development operations or guard them more closely, and automated fuzzing too.
[1] https://www.kernel.org/doc/html/v4.14/dev-tools/kasan.html
I worked as a mechanic years ago, and I feel the same way about cars as you (and I) do about software. Everything is duct taped together and it's a miracle any of it works as well as it does.
Safety regulations and tests are gamed to all hell, reliability almost always seems to come from an evolutionary method of "just keep using what works and change what doesn't" with hastily tacked on explanations as to why it works, and marketing is so divorced from reality that people assume significantly more is happening in the car than really is.
Now I don't know anything about civil engineering or aricraft, but I have a hunch it's not as well put together as it may seem at first glance.
I still think that software is behind those other fields, and I'm honestly still on the fence if regulations would significantly help or would just slow things down, but it's absolutely the "wild west" in software.
I work as a developer and everyday I feel like this isn't the right the way to do it. I'm not sure what the right way is, but being a software developer I probably have less faith in it then the general population. Something just feels wrong about it, how we do things..
Of course for most commercial software correctness is so irrelevant that it's left undefined. All that matters is pleasantness, that is to say does it generally please the user, perhaps by attracting customers or investors.
It's clear in IT we always choose faster and cheaper. No one went to jail for the Equifax hack except that one low level manager for insider trading.
The first commercial aviation company was formed in 1909 (https://en.wikipedia.org/wiki/Airline#History), the FAA was founded in 1958 and the NTSB in 1967....
At some point the "we're in our infancy" stage has to end.
If planes were as reliable as software they would be the leading cause of death in the world.
...in the United States. I definitely recall watching multiple episodes of Air Disasters [1] where surviving pilots in crashes in other countries that killed passengers went to jail for things that in the US would have at most resulted in a suspended license and demotion or termination from their airline.
For example, Air France Flight 296 in 1988. Another example is Gol Transportes Aéreos Flight 1907 in 2006 in Brazil.
[1] AKA Air Emergency, Mayday, or Air Crash Investigation, depending on what country you watch in and what channel it is on.
You'd better stay away from any company that requires FDA approval. Believe it or not, every change is signed. By you. By the FDA compliance person. Etc etc. I'll give you two guesses as to how they decide who goes to prison if God forbid something in the software is shown to have caused a fatality? Or, worse, a series of fatalities?
That sort of regulation happens even in the software industry. It just depends on the purpose of the software.
Would you mind just telling us instead? Thanks.
The whole process from requirements, specifications, high and low level design, implementation, validation and verification and the rest of the lifecycle requires stringent oversight, including documentation and signoffs. The signatures on those documents have legal meaning and accountability for the engineers who did the analysis and review at each stage.
Source: Worked in FDA-regulated software for six years, at two different places.
There are large sectors in this industry where rigorous engineering effort isn't really applicable. It seems to me, though, that this has effectively been used as an excuse to avoid any genuine rigor. It isn't helpful that so many programmers have such huge egos.
What we don’t know is how to write reliable software while also delivering an MVP for antsy VCs and shipping feature updates every week.
And that’s fine. Not all software needs extreme reliability. The problem is that a lot of software gets categorized as “doesn’t need it” when it really shouldn’t be, like all those systems holding sensitive personal information.
1. Data Breach disclosures 2. Reporting/Public statements if the vulnerability or path that caused the breach has been fixed.
Note, this might seem a little weird (like "of course we've fixed the breach!") but often data breaches aren't detected for _months_ after they occur. There's plenty of companies who didn't know they were breached until they were on HaveIBeenPwned.
It's not NTSB level thoroughness, but I think it's a healthy start in that direction.
Even when it was new, the AP-101 was part of a family of flight computers that NASA had already been using, and the same is true for the HAL/S compiler used for most of the code.
If you want to explore how it all worked, this SE thread contains some great information and also serves as a good launching point for further research:
https://space.stackexchange.com/questions/19006/what-operati...
It's about a guy doing similar things, with model rocketry.
It seems though that the resiliency is all due to field tests/ spectacular failure in the latter. (It doesn't detract from the project at all though).
How would you solve that? The FAA can issue all sorts of regulations requiring rest breaks, fatigue detection, etc. -- be sure you're ready for that level of intervention before you ask for this level of investigation.
For instance, how many people ride in the car? What is the average car trip length? Why and when are people driving? Speed profiles, line of site in both car and environment. Does traffic all flow one way, can a car ever land in incoming traffic if it loses control, are traffic barriers designed to bring an out of control car safely to rest with good line of sight to the accident? Are features keeping drivers alert or distracting them?
The difference between lots of fender benders with a bit of panel beating and constant fatalities can come down to multiple causes, many outside of engineering a safe car.
There's no good reason not to, for example, have every car use a breathalyzer to start the engine -- those driving drunk on occasion would protect themselves from DUIs, lives would be saved, etc. Or to implement other, similar deep regulations. But the ideology around cars ("freedom"), vs. planes ("safety"), is too different to allow for such levels of intervention.
The way they are implemented now would be similar to only installing seatbelts in cars where the driver has already been in an accident. Similar sentiment was around when seatbelt laws were put in place, "I'm a good driver." but the seatbelt protects you from yourself crashing as well as when someone else crashes into you!
In the same way, breathalysers (ignition interlocks) for everyone wouldn't be "for you" as much as for everyone to prevent them from drinking and crashing into you.
I hadn't thought about widespread ignition interlocks, and obviously there would be a lot of public pushback, and it would be quite intrusive, but I could see it helping reduce traffic fatalities dramatically.
What I would support is a further reduction in the allowed BAC, and stricter enforcement of traffic laws in general.
Almost all crashes are ultimately caused by driver error. Doing FAA/NTSB-style investigation on them would be pointless, because that's exactly what they'd find: people were driving recklessly, inattentively, etc. And there's nothing that can be done about that, because we as a society absolutely refuse to have serious driver training and any standards for driver conduct. We can't even agree on whether the left lane is for passing or not! Try driving in Germany sometime and you'll find that what we accept from drivers here in the US is really quite awful.
Graduated drivers license laws for young drivers, age-21 drinking laws, smart airbag technology, rear high-mounted brake lights, commercial drivers licenses, and improved school bus construction standards all came about at least partially due to NTSB recommendations.
In software, you can poke/prod away at the running application to get it to do something it shouldn't. To me, this is a bit like yanking wires that you know are important to see what happens to plane in mid flight. Another anecdote I use is to image pulling the steering wheel off a car while someone's driving it.
I think modern software testing and security analysis is probably far away better than what the ntsb provides because we've already systems in place to cope with crashes.
(Although they still do their best to make the software reliable, they do not bet lives on its reliability.)
Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html
Designing Safe Software Systems part 2 https://www.digitalmars.com/articles/b40.html
There are tech shops that use these sorts of techniques for every major incident, and for collections of related near-misses. If you want to improve past 4 9s reliability, or if you're considering taking traffic that could wreck a life if it availability or secrecy fail, that only seems appropriate.
New MITPress web page is: https://mitpress.mit.edu/books/engineering-safer-world
Since the book is open access, the direct link to the book (again from MITPress webpage) is https://www.dropbox.com/s/dwl3782mc6fcjih/8179.pdf?dl=1
I think it’s also important to emphasize that getting to this level of safety is so much more cultural than technical. The ability to be open about failure and for people to feel safe in communicating to investigators is critical. The Navy would run two parallel investigations into an incident, one focused on Safety, where anything said was confidential and couldn’t be used in the administrative investigation (FNAEB) that could result in career ending consequences.[2]
Though I worry a bit with the constant wars and punishing deployments this culture may be heading in the wrong direction. [3] One of my XOs said, “One generation of Admirals will make their names breaking the Navy, and the next will make their names putting it back together.”
I have immense respect for the FAA and NTSB. They are trying to infuse this safety ethos into the fledgling drone industry. No easy task.
1. https://en.wikipedia.org/wiki/Swiss_cheese_model 2. https://www.airwarriors.com/community/threads/my-fnaeb-exper... 3. https://www.theatlantic.com/technology/archive/2018/10/the-n...
Maybe 'constant wars' is already the wrong direction.
My first introduction to it was watching a documentary on air crash investigation as a child, and I've never forgotten it since.
I don't even work in 'safety' per se(currently I do analytical and data work for banks and financial regulation, so one could argue that is a kind of safety), but it just keeps coming up again and again because in the real world, most big human disasters are multi-causal chains, because evolution (in a social sense) will breed out those disasters that are both big in their detriments and simple in their causes.
The Safety Investigation Board is separate, and privileged.
FNAEB investigates the crew, and usually follows a Class A mishap ($2m damage or hull loss, or death/permanent disabling injury) but can be triggered by near-miss or pilot flathatting etc.
A friend is a retired Naval aviator, said the #1 reason aviators get permanently grounded from the fleet, is refusal to accept responsibility for mistakes that they were clearly responsible for. Things like forgetting to set the altimeter correctly before takeoff, causing a serious near-miss or pilot deviation. Honestly and fully admitting their mistakes, is more likely to result in a FNAEB returning them to the fleet. Asoh Defense comes to mind.[0]
[0] https://en.wikipedia.org/wiki/Japan_Airlines_Flight_2#The_%2...
...for instance, Zipline is doing amazing things in Rwanda improving the medical (okay, blood) logistics system drastically. They're legitimately saving lives regularly. But what they're doing is practically illegal in the US due to the way safety regulations are put together (although they have indeed achieved a very high degree of safety and work closely with ATC, etc... it's not the wild west). Some of that is logical... Rwanda is a developing country with a great need that overcomes a lot of safety concerns. But doubtless lives could be saved if similar drones were allowed in the US.
Second: FAA regulations have already slowed the development of electric aircraft in the US which has significant climate consequences and thus can indirectly lead to lives lost...
...that all said, I think the NTSB and FAA do a good job. Particularly the NTSB.
[1] https://www.interdrone.com/news/dan-elwell-speaks-to-audienc...
[2] https://unmanned-aerial.com/drone-industry-responds-to-draft...
[3] https://www.utm.arc.nasa.gov/upp-industry-workshop/UTM%20PP%...
Certification costs have been going up as a portion of overall development costs[1], this leads to more expensive planes, less competition and technological development.
There's some amount of safety that's counterproductive, since people will just opt for e.g. driving which is much less safer, but the way these agencies are set up means they can't ever address that question. They're never going to declare a system as unreasonably too safe and expensive.
So we really should be careful to wish that aviation safety be applied to other industries.
1. https://aviationweek.com/commercial-aviation/what-certificat...
For example, the hydgrogen overpressure in the reactor (caused by previous failures) was vented through an overpressure valve into a pipe. The pipe exited into the enclosed reactor building, which lead to an explosion.
The pipe should have been vented to the exterior. The cost of that would have been insignificant, like numerous other zipper-stops.
Deepwater Horizon was a big zipper, too, none of which would have been costly to prevent.
Etc.
Most are related to human intervention such as terrorism, pilot error, fuel error and only a very small amount are mechanical errors. Of the 12 problems, only 5 were mechanical error. I wonder what the cause of this will be.
Landing a 767 without power, not so much... https://youtu.be/GlkCofOyxUA
> "The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces and controls working in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying immediately and disastrously. There is no such thing as a gliding helicopter. This is why being a helicopter pilot is so different from being an airplane pilot and why, in general, airplane pilots are open, clear eyed, buoyant extroverts, and helicopter pilots are brooders, introspective anticipators of trouble. They know that if something bad has not happened, it is about to."
-Harry Reasoner
Then there is the challenge of landing a Harrier Jump Jet on an aircraft carrier.
Then there is the challenge of landing a Harrier Jump Jet on an aircraft carrier that happens to be postage stamp sized and in the South Atlantic high seas during an actual war, the Falklands War.
Helicopter turbine engines operate on exactly the same principles at the 90,000lb thrust turbofan under the wing of a 777. They are incomprehensibly reliable.
Things that lead to helicopter autororation are usually mechanical failure of the transmission.
This still seems amazing and unbelievable to me.
Here’s one with an outside view, which I think is easier to grasp for non-pilots: https://youtu.be/twGid07JR9s
Basically, the helicopter “falls” down and slightly forward, driving the main rotor disc (potential energy turning into disc rotational energy), then the pilot flares the helo, slowing the forward speed and taking energy from the rotor disc to slow the vertical descent, finally resulting in the aircraft settling to the Earth at a slow speed. Just like gliding an airplane, it’s a one-shot kind of a thing (except in training where you generally keep the engine running and available).
Note that the rotor disc is connected to the engine via a one-way clutch, so the engine can drive the rotor but not vice-versa. Otherwise, a seized engine would result in a rotor disc stoppage (and an uncontrolled descent).
https://www.youtube.com/watch?v=BTqu9iMiPIU&feature=youtu.be...
That's a bit misleading. The Gimli Glider landed without thrust but almost certainly had electrical and hydraulic power. Same deal with the British Airways 777 that crashed at Heathrow.
Meanwhile, LATAM landed a 777 with no electrical power[1] not that long ago. That's a whole different ballgame.
the pilots were initially punished (which is outrageous), then lauded, for their skills.
When mistakes happen by accident, they tend to give people lots of slack to encourage honest accounts so that they and the rest of the community can learn from the mistake. This is the reason behind things like the NASA form, which is sometimes seen as a "get out of jail free" card. You write a detailed account of what happened after certain kinds of accidents/incidents, and if they conclude that you weren't being too stupid, or it wasn't a repeat issue that you should have learned from, they'll skip certain minor enforcement actions against you.
Keep in mind that the U.S. is not the only place where measures are mixed. If anything, British people end up using more measures than Americans. Here in Canada, we have a lot of things read out in both, because of the immense sticking power of customary measures.
U.S. organizations are actively encouraged and (for the most part) fully allowed to adopt SI measures, but it's not like switching road sides, where everything makes sense after you hear "drive on the right now".
Keep in mind that powered flight was basically entirely developed by Americans and pre-SI Brits, and already had more than fifty years of history by the time either pioneering country adopted SI in any significant way. It should not surprise you in the slightest that an American plane expected to hear fuel mass given as weight in pounds; in fact, it should astonish you that anyone is trying to measure it in kilograms in North America.
Even in Britain, in almost all engineering contexts, SI units would be assumed. Your point about Americans assuming imperial units is precisely wwhy it's so dangerous that metrification hasn't happened there.
If the US went metric, then there would no longer be any need to assume anything but metric anywhere, and it would be safer for it.
Yes, there's a long standing tradition, but it only takes a couple of generations to completely change, and that would likely be hastened by being the last large country to do so and having a large cultural footprint on the rest of the world.
If the US did convert to metric, in 3 or 4 generations the whole world would be metric, and there wouldn't be any "wrong assumptions", and it is making bad assumptions that lead to preventable failures.
If China can manage to go metric, the US can too.
This is true in the United States as well, but fueling a commercial airplane is not an academic, scientific, or even an engineering exercise. It is as routine and pedestrian as refueling a bus.
> Your point about Americans assuming imperial units is precisely wwhy it's so dangerous that metrification hasn't happened there.
Or maybe it's an argument for why "metrification" is itself dangerous. The problem is the transition, not being on either side of the fence. It seems to me that the only safe mode of transition is first to dual readout, and only then to SI-exclusive.
Don't get me wrong, I like SI units, I use them every day, and I don't long to spend any time multiplying and dividing by irregular fractions; I just don't like the dismissive "shoulda been metric" rhetoric that floats around everywhere; as though you can just stop selling letter paper and force everyone to use A-series compatible envelopes, and convert the clean (if baroque) markings on the paper products to bizarre decimal fractions of a g/m² without any empathy for the old guard.
Some people care about how Britain still drives on the wrong side of the road, but that doesn't mean they should berate you every time a drunk roadtripping Frenchman turns out into oncoming traffic.
> as though you can just stop selling letter paper and force everyone to use A-series compatible envelopes, and convert the clean (if baroque) markings on the paper products to bizarre decimal fractions of a g/m² without any empathy for the old guard.
The first part was done in Britain in the 1950s, but with the weights rounded to convenient metric numbers.
Refuelled in litres, but with efficiency measured in miles per gallon. It's kind of a mess.
All three British bus manufactures give all measurements except speed in metric, although none give an actual fuel consumption. (Just "20% better" etc.)
[1], as the first reference I can find, uses both l/100km and mpg.
[1] https://www.whatdotheyknow.com/request/fuel_consumption_of_p...
That might be a tiny bit optimistic. I'm in my mid 50s, and UK schooling taught me nothing but metric. I vaguely remember some sort of half-hearted campaign and leaflets about it, I think that was before we joined the EU. In 2019, and we are still not there yet.
I'm not sure the last popular holdouts are ever likely to change at this point.
I'm surprised, but thankful, that the Brexit lunacy hasn't (yet) brought calls to return to Imperial and £sd. :)
Unfortunately:
Return of pounds and ounces? Britain might allow firms to use imperial measures after Brexit https://www.telegraph.co.uk/news/2017/02/17/return-pounds-ou...
EXCLUSIVE: Experts Slam "Bonkers" Proposal To Re-Introduce Imperial Measurements After Brexit, In Letters To Government http://www.gizmodo.co.uk/2017/04/exclusive-experts-slam-bonk...
Now that we are to be a sovereign nation again, we must bring back imperial units https://www.telegraph.co.uk/news/2017/04/01/now-sovereign-na...
The french played a very dominant role as well.
As far as I've known, that largely involved a tremendous number of English channel crossings, but I will look more into that so I don't stay ignorant; thanks. ;- )
Aviation: https://en.wiktionary.org/wiki/aviation
Aéroplane: https://en.wiktionary.org/wiki/aeroplane
Hélicoptère: https://en.wiktionary.org/wiki/helicopter
Here are a few places for you to begin your research:
https://en.wikipedia.org/wiki/Aviation_in_the_pioneer_era
https://en.wikipedia.org/wiki/Grande_Semaine_d%27Aviation_de...
https://en.wikipedia.org/wiki/Louis_Blériot
https://en.wikipedia.org/wiki/Soci%C3%A9t%C3%A9_pour_l%27avi...
https://en.wikipedia.org/wiki/A%C3%A9ro-Club_de_France
https://en.wikipedia.org/wiki/Cornu_helicopter
https://en.wikipedia.org/wiki/L%27A%C3%A9rophile
https://en.wikipedia.org/wiki/History_of_the_Arm%C3%A9e_de_l...
Aside: How many American-made components do you see with big bold French labels on them? https://en.wikipedia.org/wiki/File:Fdr_sidefront.jpg
Also, that description sounds like tracing a bug through a few layers of software where there wasn't proper error handling along the way, just trusting the data being passed around.
[0] https://business.financialpost.com/transportation/air-canada...
The surprising part of that story was the seemingly endless string of fuck-ups that resulted in them running out of fuel mid-flight.
You must have been really lucky.
Sure, planes are perfectly capable of gliding to a safe landing after losing power. The problem is that there usually isn't a safe place nearby on the ground to land them at. So instead of a smooth, safe landing on some tarmac, they have a horrible crash-landing onto some kind of ground, if they're lucky. If they're not lucky, there's only mountains around and they just crash into them.
The nice thing about helicopters losing power is that a helicopter only needs a very small patch of level ground to land safely. Airplanes need an airstrip of some kind, and big airplanes need really long ones. Usually, if they're lucky, there's a decently straight highway close by.
Value Jet went down in the Everglades due to a similar reason
The last readout they were at an altitude of 1325ft, with a vertical descent of 29504 feet per minute (~335mph). So that reading was (probably) roughly 2-3 seconds before hitting the ground.
My go-to is this YouTube channel, which highlights various bits of ATC communication and overlays maps as it happens https://www.youtube.com/channel/UCuedf_fJVrOppky5gl3U6QQ
There's several references. Around 27:09 you can hear them talk about looking for a lost aircraft.
If I understand correctly, a foggy day + “cleared for takeoff” is all that’s needed for a malicious actor to kill hundreds of people
Only if the real ATC really, really drops the ball.
It's happened a few times, and leads to an immediate "who the fuck was that on this frequency?", and that's likely to result in the pilots in the area treating it like a comms outage.
See https://aviation.stackexchange.com/questions/44279/what-prev...
Too many things in that chain can go wrong, especially so given this would all need to happen in just a few seconds. A sophisticated attacker might even be able to jam the signal right after they give the fake clearance or (not entirely certain this is possible) use a highly directional transmitter that would allow the targeted plane to receive the message but not others.
I’m definitely not an expert in this area, so I wouldn’t be surprised if I missed something, but if I didn’t, this appears to be an astonishingly large vulnerability.
When was the last time you authenticated that construction worker directing traffic on the ground?
Pilots fly without a control tower all the time. They’re also the final authority to the safe operation of that aircraft. If anything is amiss, we’ll do something else. Maybe that’ll mean contacting a different facility on a different frequency, or declare lost comms via transponder and go to our filed alternate while things are worked out.
Try listening to LiveATC for an uncontrolled field on a nice weekend day. (Or even a towered airport like KCMA on a Saturday at noon.) It’s controlled chaos and yet we all make it work.
ATC to ignore the false transmission and take no action.
The departing pilots to accept a new voice and a clearly inferior/weak radio clearance as fact without verifying.
The departing pilots to not have situational awareness of an aircraft previously cleared to land on their runway.
The departing pilots to still not check final approach on the just-falsely-cleared runway before taxiing into position.
The landing pilots to have ignored the false transmission (also from a weak/inferior radio and new voice) clearing an aircraft onto their intended runway.
The landing pilots to not be watching the runway when they break out at minimums. (assuming your foggy day is a worst-case scenario)
The departing aircraft to have already started a takeoff roll and be more than 1,000' down the runway. (aircraft "touchdown zone" is not at the beginning of the runway)
Possible? Yes. Not in my top ten fears as a pilot. Much of ATC is a collaboration between professionals, not a dictatorship. It's really an amazing thing to participate in.
It was featured in an Air Crash Investigation episode named “Fatal Delivery”. https://en.wikipedia.org/wiki/UPS_Airlines_Flight_6
The crash scene extends over a distance of 3 miles in shallow waters up to 5 feet deep.
When I lived near a major cargo airport for Fedex, I often got Prime stuff delivered via Fed Ex, which I assumed was intermingled. I didn't realize Amazon also had it's own literal fleet.
Edit: They must have contingency plans for such scenarios. That's part of the job. But I think that it is not possible to keep to the initial schedule, so I'm guessing that the plan is to re-despatch ASAP to minimise delays while displaying the standard "delayed-apologises" to customers.
Remember also that the total loss of the plane impacts more that this single flight. Like airlines, I am sure it had an utilisation schedule, and now it's gone so they'll have to account for that.
That's why they do have contingency plans... And that's why they develop them with a cool head. Because when disaster strikes people tend to get emotional.
Edit: Wikipedia says that Amazon Air operates 39 planes. Sudden loss of one has to have an impact that has to be planned.
Anyone who operates a whole fleet of 767 has a plan in case of a crash. That's the most elementary professionalism.
That's certainly smaller than Delta's ~800 planes, but they're certainly not tiny.
Grounded for unknown timespan due to some kind of severe damage = does happen from time to time (good thing, because otherwise, crashes would become more likely...)
Since the effect on the logistics chain is identical (at least apart from that single shipment in question), you just use the contingency plan for the latter when the former happens. And for the latter, you MUST have a plan.
As far as I know, zero customers complained about the obviously tragic and unusual circumstances of the delay.
For Amazon, they almost surely know with immediate certainty what was on the plane, and are mostly selling from stock, making the resolution easier in some ways (though larger scale on the other hand).
We treated this response as an ad-hoc process and have zero plans to systemize the response to a once every few decades issue.
That said, Amazon is a logistical beast and regularly deals with transport failures (semi-crashes, lost containers, train derailments, fires, etc) so I don't feel that this would necessarily warrant any out of normal response.
https://i.imgur.com/FqitEhc.jpg
And they typically elevate stories based on reader interest, so the fact that it's so thoroughly minimized (to the right, in red) shows how little anyone cares relative to the other stories.
Commercial air travel in the US has a pretty enviable track record. As far as I am aware, outside of the fluke accident that killed one passenger last year when a piece of the engine went through the fuselage, the last fatalities were in 2009, Colgan Air Flight 3407. [1]
[0] https://en.wikipedia.org/wiki/List_of_fatal_accidents_to_com...
[1] https://en.wikipedia.org/wiki/List_of_accidents_and_incident...
For US-based carriers, you are correct. Ignoring international carriers operating in the US strikes me as slightly disingenuous (though lots of people do it), as the international carriers should be subject to most of the same regulations as US carriers (when operating in the US). And as a consumer, I'm as likely to be on BA, KLM, or somebody else as I am United when flying internationally.
Not that much harder, you still need FAA approval to fly in the United States. For instance, Air India has run afoul of the FAA in the past and most Indonesian airlines have been banned from EU airspace at one time or another. Currently VietJet (I think) is working to get FAA approval to fly in the US.
The problem is that it's inappropriate to say "your lack of safety culture is a problem" before there are deaths. Korean Air had to hire submit to a bunch of training by Delta Airlines after a series of wrecks. It's not a particularly uncommon opinion to look at the culture of deference and respect for elders/seniors you see in East Asia as being detrimental to safety. I agree. The Asiana wreck showed this (there were three people in the cockpit, two of whom called for a go around, the other one ignored the calls). KLM showed what happens when you're unwilling to question a senior officer back in the 70s in Tenerife.
I remember finding out that if a pilot has a "conflict of personality" with another pilot they can just check a box on a form and they never end up on the same crew. This was after one difficult pilot bullied his young co-pilot until the latter made an error (failed to read the altitude) that cost the lives of all people on the plane.
The rule likely applies to every airline flying in the US. But actually enforcing it is a lot harder to enforce half way around the globe or somewhere where that safety culture you mention is different. There's a chance the punitive measures are also applied differently, where in the US someone might go to prison for failing to properly apply regulation.
It's not though. Canada, for instance, has far more lax work time limits on its pilots. Guess who else has had problems at SFO? If you guessed Air Canada you'd be correct. There are plenty of regulations that are different for foreign carriers operating on American soil (it probably comes down to mutually agreed ICAO rules).
Instead, it some bullshit story involving hollywood actors
That sleep loss contributes to accidents and is therefore relevant to the discussion (if true) is in no way speculative: https://www.ncbi.nlm.nih.gov/pubmed/?term=accident+sleep+los...
Discussion of specific issues is interesting, but they're better discussed in extra threads instead of as speculations on a case nothing concrete is known about.
This specific subthread starts with either speculation or unsourced claims of lack of sleep: That alone is an interesting topic of discussion, but better placed on a submission about a specific case where this is known to have been a factor, or some general article about it, not here.
Exactly - the idea that the crew had any sleep loss is speculative. I doubt anyone would suggest that lack of sleep doesn't contribute to accidents.
I don't think it's too different from reading a story about a murder investigation and idling throwing out 'could be Bob that did it - I hear he gets angry sometimes' without knowing Bob, knowing whether he usually gets angry or not, whether or not he was angry or not at the time, or whether anyone was angry at all in the situation or even if Bob had anything to do with it in the slightest.
And the requirements are different between passenger and cargo operators.