Bug identified after Alaska Airlines planes bump runway while taking off
adn.com
adn.com
The airline completely grounded their entire fleet while they investigated this issue, so I don't really understand why you're trying to act like nobody took this seriously. The article makes it quite clear this was handled as a serious problem and steps taken.
The Alaska Airlines' pilots union is both qualified to have an opinion AND looking out primarily for their members (i.e., pilots), and they had this to say:
> The data “confirms that the airplane was safely airborne with runway remaining and at an altitude by the end of the runway that was well within regulatory safety margins,” said the union’s Alaska unit chair, Will McQuillen, in a statement.
If the union was unhappy with the remediation steps taken, they'd say so. That is quite literally their primary function.
No. The margin for error in jets is very small. Jets are much less forgiving than Cessna 172s. The difference between a tail strike and a failed takeoff is very small, easily under the threshold of human perception until it's too late. Also, the whole point of using this software in the first place is so that every takeoff is done right on the hairy edge of minimal performance. It is a catastrophe waiting to happen. This was a wakeup call.
> If the union was unhappy with the remediation steps taken, they'd say so.
It is quite possible that no one in the union appreciates the broader implications. Pilots are generally not software engineers.
[0] https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Not just for that reason. I'm also not bound by the political constraints that union leaders are. They have to pick their battles. I'm free to say whatever I want about this with little risk to my career.
But yes, I think I understand software -- and particularly software risks -- better than most pilots, and I think I understand flying better than most software engineers, so I think that makes my opinion better informed than most. (It is nonetheless just an opinion.)
> Are you familiar with the Dunning–Kruger effect
Yes. Are you familiar with the ad hominem fallacy?
It doesn't apply. When an argument is backed by someone's qualifications (in this case PPL and software developer), discussing the merit of those qualifications for the discussion domain is absolutely relevant. Your first reply to this thread started off with:
> Private pilot here.
And now that I'm calling into question how relevant that is, or more to the point if you're in a position to know better than the pilot union/airline/etc, it is suddenly Ad hominem.
Cannot have it both ways, either your qualifications make your opinion more relevant or they don't. But pick a lane.
The implication with calling it Ad hominem though is that your qualifications aren't relevant, which I happen to agree with, and actually that was my point.
"The Dunning–Kruger effect is a cognitive bias whereby people with low ability, expertise, or experience regarding a certain type of task or area of knowledge tend to overestimate their ability or knowledge."
In other words, by invoking D-K, you have implicitly said that you think I am a person "with low ability, knowledge, or expertise" regarding the matter at hand. But I am a licensed private pilot with 30 years of flying experience, and a software engineer with a Ph.D. and over 40 years of professional experience, including over 15 years working at NASA and at an aerospace startup I co-founded. Those are all just facts. In the face of those facts, an implicit and unsupported assessment that I am a person of "low ability, expertise, or experience" is an ad hominem, essentially saying, "Yeah, you have all these credentials, but you still might be an idiot." Well, yeah, I might be. There are lot of idiot pilots out there, and there are a lot of idiot software engineers out there, and I may well be a member of both groups. One of the big problems with idiocy is that it does not yield readily to introspection. (And you might want to mull that over a few times before you respond.)
As long as I'm pointing out your logical fallacies, here's another one:
> your point is that professional airline pilots, their union, or an airline are less qualified to understand the safety implications of this incident
No, that is not my point, which makes this a straw-man [1]. The fact that neither the union nor the airline have publicly expressed the same concern that I have in no way implies a lack of expertise on their part. There are many other possibilities, one of which is that they agree with me, but they are savvy enough to realize that there is nothing to be gained by saying so publicly.
So you have the lowest pilot qualification who can even solo, and no jet qualifications at all. But you know better than the pilots union at a commercial airline, who are run by commercial airline pilots? Or the FAA who haven't stepped in after TWO reportable events? So, yes, absolutely Dunning–Kruger applies here, and the fact you don't seem to see that is a problem.
Heck, you think "I am a software developer" means anything in this context is also a mystery to me.
> In the face of those facts, an implicit and unsupported assessment that I am a person of "low ability, expertise, or experience"
You are though. You only have PPL, and seemingly don't even know what it is that you lack in terms of expertise. The fact you think you know better than people who are demonstratively more qualified to have an opinion is problematic, it is textbook Dunning–Kruger.
If you knew more you'd be embarrassed but what you're saying here.
> The fact that neither the union nor the airline have publicly expressed the same concern that I have in no way implies a lack of expertise on their part.
They did express that concern, it is in the article. They even shut down the airline for a period because they were so concern at not insignificant cost to them.
First, that's not true. Student pilots can fly solo, and there is also a sport pilot rating with is in some sense "lower" than a PPL. So the PPL is actually right in the middle of the primary rating hierarchy.
But more importantly, your characterization of a PPL as the "lowest pilot qualification" implies a pretty profound misunderstanding of how pilot ratings work and in particular how they relate to operational knowledge. It is possible to fly a jet with a PPL, and it is possible to get an ATP without ever flying anything beyond a Piper Arrow. There are also all kinds of orthogonal ratings like an instrument rating, seaplane rating, multi-engine rating, and instructor rating. And absolutely none of those things have anything to do with flying jets. For that you have "type ratings" [1], which are more or less orthogonal to all of the others.
> You only have PPL
That is also not true. I have additional ratings beyond the PPL, I just haven't mentioned them because they are not relevant. What is relevant is that I actually fly airplanes, and so in general I probably understand the process of flying an airplane better than someone who does not fly airplanes, and I have actually written and deployed software in mission-critical situations, and so in general I probably understand mission-critical software and its attendant risks better than someone who has not.
> They even shut down the airline for a period
No, "they" did not shut down the airline. A single individual, Bret Payton, shut it down.
> If you knew more you'd be embarrassed but what you're saying here.
Could be. But at least I know the difference between "but" and "about".
--
Then when stating the authority of pilots and their unions you are not attacking the argument with a counter argument. Instead you claim you are right because of the authoroty of the union. Hence argument from authority.
Fallacious arguments. Clearly.
https://www.dynamicsource.se/service/ds-weight-balance/
https://aviation.stackexchange.com/questions/32888/is-the-fo....
Looks like lots of people were very very luck here. Plus finding a bug and correction to production in 5 hours? That is at the same time good and bad..
"Analysis of aircraft weight and balance related safety occurrences" - https://reports.nlr.nl/server/api/core/bitstreams/9dc15cb9-a...
In a car, you hit a bump, you keep going. In a plane, something unexpected happens and that plane is grounded. The utility function is just too skewed to take even a slight risk in this regard.
- Pulled over onto the shoulder,
- Passed around a pad to collect everyone's contact information,
- Summoned a replacement bus, and
- Called the provincial police to escort us along the shoulder to the replacement bus.
In the moment, all of this felt a little over the top, and the total delay of about 20mins total was pretty frustrating given that I ended up missing a connection. But at the end of the day, it builds my trust in the safety of that system that the fitness of any particular piece of equipment is not up to the individual drivers to judge— part of paying for a ticket on the state-run transit system is expecting a higher level of safety than, say, what you might get on a Chinatown bus line (https://en.wikipedia.org/wiki/Chinatown_bus_lines#Accidents). And I think I was also glad that it hadn't happened to me in my personal vehicle, where I would have to be the one to assess fitness and then deal with the insurance and so-on in the aftermath.
If I felt a bumper or tire bump when I was parking I would not care.
Inspections after abnormals are fairly common and many amount to nothing more than “inspected tail skid and aft fuselage, no defects founds, return to service”.
I was pointing out that the article described a course of action that, in fact, sounds serious to a layperson. It seems to me that "land and have a required inspection" is an indication of seriousness, not an indication of downplaying the severity.
You said, "The article downplayed the seriousness of a tail strike." I was pointing out that the thing they described multiple times did not sound like downplaying to me, as a layperson. "They immediately landed," sounds serious. "They grounded the fleet," sounds serious. "The planes required inspection before being allowed to fly," sounds serious. Nothing in the article reads to me, as a layperson, as if they were saying a tail strike is not serious.
In that case, we're both right about different things. I was referring to the article, and you were referring to the airline.
The airline absolutely did the right thing and took the tail strikes seriously. As for the article, it focused on the strong reaction to the error in the software. The article did not discuss the serious consequences of a tail strike. Considering that multiple aircraft (and many lives) have been lost due to tail strikes, I was surprised that it was not mentioned.
It is.
We could certainly operate an aviation industry with a lot less regulation and a lot less care for safety. Operated that way, air travel would be noticeably cheaper. But it would also be more dangerous.
Frankly, I like the trade-off we have chosen.
I am saying that the article said things that sound severe, as a direct response to the claim that the article downplayed the seriousness.
I know that metal fatigue is the primary limiter of aircraft lifespan. How many years does an aircraft typically live for today?
Aircraft age isn't in years, but in number of pressurisations (takeoff/landing cycles). A low cost airline optimising their schedule to squeeze every second of their airframe with constant short distance hopping around would result in much more of those compared to a legacy airline's widebody that is flown daily on a very long flight. So it depends on aircraft type/size and usage patterns, but Ryanair's 737 will be able to handle less years than DHL's 767Fs.
So for the 747 in the story, 22 years is on the long end, but not unheard of.
Climate can matter a bit, since it can exacerbate other issues and cause faster corrosion than expected.
For small non-pressurized aircraft that people do their initial training in, it's very normal to learn in a plane that is more than 60 years old.
https://admiralcloudberg.medium.com/shattered-in-seconds-the...
> On the morning of Jan. 26, as two Alaska Airlines flights from Seattle to Hawaii lifted off six minutes apart, the pilots each felt a slight bump and the flight attendants at the back of the cabin heard a scraping noise.
> ...a software bug was sending bad takeoff weight data to its crews...
> ...To determine the thrust and speed settings for takeoff, Alaska’s pilots and others use a performance calculation tool supplied by a Swedish company called DynamicSource. It delivers a message to the cockpit with crucial weight and balance data, including how many people are on board, the jet’s empty and gross weight and the position of its center of gravity. In a cockpit check before takeoff, this data is entered into the flight computer to determine how much thrust the engines will provide and at what speed the jet will be ready to lift off.
> [!!] the bug [..] only presented when many aircraft at the same time were using the system.
This implies that the calculations are done externally to the plane? That seems... interesting.
If you are going to factor the rest of the world into it, why do you need to isolate the calculatons to the plane?
I have the idea that a captain is responsible for its flight, and thus want to have as much information as possible. I think flights have their own full manifest anyway, so they have all the information you mentioned?
As to "how", I'm not sure I understand the issue, can't the same computations be done locally? The computations you mention doesn't sound too computing intensive.
I concur with sibling "Why does this seem so absurd to you?". You probably know real reasons for this not to be done from aircraft, and we're curious to see some.
Sure, the pilot could plug those numbers into the same computer the dispatcher does before they board, or disembark and use the computer and re-board, but it would be one more thing to do before you can start boarding. They could install that computer on every plane, but that's one more piece of equipment to go wrong/need to be certified, etc...
Why not have a helper who has access to networked systems with all of the cargo and passenger information available do it for the pilot, and access to complex software that they are specifically trained in, and have the calculations printed out and done for the pilot to review? Well, that's exactly what they do.
The pilot could probably do the calculations by hand (it is something you have to demonstrate knowledge of for small plane licenses, which all these pilots have), but that would take an hour at least.
While the calculations aren't compute intensive, there are a LOT of variables. Off the top of my head: passenger count, altitude and temperature at both departure and destination, cargo, cargo distribution, fuel, fuel distribution, reserve fuel needed for the weight carried and destination and routing.
What you end up with is that you want someone whose job it is to exclusively know how to correctly load the planes, and brief the pilots on how they've done it.
So what happens is exactly that. There's a room full of people for any given airline who figure out the weather, the cargo they need to to move, how full flights are, etc. and do all the math and hand the pilot a ream of paperwork that says that we loaded the plane factoring all these things in, here's the proof of work. And the pilot says: looks good. A person with more tools and information and expertise than me on loading has proven they did their job, I trust them in the same way that I trust the mechanic who rebuilt this engine, and the fuel guy who pumped the correct amount of fuel into the correct tanks, and the flight crew who have checked that the doors are latched and armed.
Which would you rather have, a software error on the ground that results in a minor incident, or a software error while in flight, resulting in a possibly fatal crash?
Pilots carried a paper performance manual for the aircraft and did the necessary calculations during preflight, I believe - though they stopped doing this because the computerised figures were much more accurate and reliable.
To reduce the risk of this sort of thing happening. I imagine aircraft software standards are a bit better than whatever standards this software uses, if it failed simply due to high load.
> and how?
I'm pretty sure the computer on an aeroplane can handle this simple computation.
Which bit do you think is wrong? Planes have flight computers, or the software that runs on them is very thoroughly verified.
Edit: And even still, international regulations will vary and so the aircraft carrying two different sets of regulations seems complicated I would think?
It’s Fortran so fixed array sizes might be to blame. Being Fortran they’re probably using matrices to parallelize the calculations.
How the heck do you end up with a concurrency bug in a system where the calculations appear to be logically independent?
> That morning, a software bug in an update to the DynamicSource tool caused ...
This says when the bug happened, not when the update was made.
Would have thought lower than ideal safety margins on takeoff speed (the calculations were apparently <20% off the true value) were a more concerning problem
And 90% of those sources are ancient balls of mud that spit out stuff that looks like
!ORD 06/001 ORD RWY 04L/22R CLSD 2106231700-2106232300
or KAUS 092135Z 26018G25KT 8SM -TSRA BR SCT045CB BKN060 OVC080 30/21 A2992 RMK FQT LTGICCCCG OHD-W MOVG E RAB25 TSB32 CB ALQDS SLP132 P0035 T03020210 =The fact that a lot of this output is almost complete inscrutable means you have to build a tool or something to translate it from that back to something a human can quickly read/grasp... and translation mistakes can happen there too :/
TaaS -> Tailstrikes as a Service...
`KAUS 092135Z 26018G25KT 8SM -TSRA BR SCT045CB BKN060 OVC080 30/21 A2992`
That is a very concise way of conveying a lot of information about the weather. It doesn't take long to learn it, and at a glance I can tell you that the weather is kind of shitty for flying at KAUS, and I can plug it into any flight app and read it in plain text if I really want.
Both were lighter than expected (so if it was a swap with another aircraft we wouldn't necessarily know - possible that 4 aircraft got the wrong data and we don't know the other two).
But it feels more likely that the sums just failed and they incorrectly caught the failures instead of letting it fall out. catch(e){} is a bug factory for sure.
Also this would mean some other aircraft had a particularly powerful departure, since both aircraft had lower-than-true weight calcs.
There is still the matter of dealing with mutable stores like databases, but well-written code would make that impossible as well, plus permit tests to run concurrently
If the plane was told how much weight was onboard, and it knows what throttle it was at... then it should know what acceleration it was expecting.
If it accelerated slower than expected, then there must be something wrong! So abort the takeoff...
Planes should have alerts for this kind of thing. If, 1 second after throttle is applied, the plane hasn't achieved the predicted speed, then the takeoff should be aborted - by this stage, you'll be well under the maximum abort speed, so you can stay safely on the ground and figure out whats wrong. Being overweight is just one possible cause - it might instead be that an engine isn't producing sufficient thrust, and that would probably doom the plane.
If you are using approximations in that calculation (such as the average weight of a passenger), then that same approximation can be used in calculating the acceleration profile, and if you are falling significantly short, then it shows that the calculation of the power setting needed for a safe takeoff is unsound in some way. That alone is sufficient to justify an abort.
Basically, I'm saying the plane should have an internal mathematical model of what it expects to happen, and anytime that sufficiently differs from reality, it should trigger an abort - especially if you're still on the ground at the time!
It's often a judgement call when things don't happen quite right and I don't think our technology is anywhere near ready to hand the abort process over to the plane's programming.
Having said that, a speed-at-distance rule like the one you give here, especially if it was evaluated at a distance before you expect to reach V1, would be perfectly good. There is a rule-of-thumb for small-plane pilots saying you should have reached 80% of the rotation speed before you are halfway down the runway (though that speed is also weight-dependent - as demonstrated in these incidents.) There is a tacit assumption here that your deceleration after choosing to abort will exceed your acceleration up to that point.
One possible reason might be a usually well-justified concern over adding complexity which could, if it fails, be worse than the problem it solves - but what would it take to measure the load on each undercarriage leg? something to measure its extension? Strain gauges on the structure the legs are attached to? I would really appreciate the input from an aero structures engineer here (paging Walter Bright...)
One other issue this would help is with is ensuring that the center of gravity is within limits (after the crash of Air Midwest Flight 5481, where this was a significant cause, the rule for estimating passenger weights was revised.)
On the other hand, an acceleration test will detect a lot of other problems beyond being overweight. There was a Citation crash near Hartford CT last year where it is suspected that the parking brake did not fully disengage. Why not have both, if they are feasible?
It's not that they don't tend to, it's that airlines don't want this — training management and recertification on behavioral changes is costly for them. See Southwest influencing 737 MAX development—MCAS was a result to try to reduce the characteristic changes between aircraft & engine variants. (Band-aid driven development!)
I sincerely hope that the 737 MAX incidents change the industry mentality to encourage safety features to be backported to older airframes, even if it seems untenable now. For example, the 737 MAX uses older crew alerting methods—annunciator lights—not EICAS, which can be thought of as a centralized actionable list of anomalies.
The fact that it was not communicated in the training and manuals was a result of lobbying by the airlines.
Ultimately the issue was noticed not because a single plane suffered a failure (one that’s expected to occur occasionally, and where multiple mitigations exist to ensure the failures are safe), but because two planes one after the other suffered an identical failure, a failure that’s only expected to occur rarely.
So ultimately the unexpected event was two closely spaced expected failures. Not the expected failures themselves, which kinda indicates that aborting to prevent the expected failures would have quite a high false positive rate. Aborts and alerts with high false positive rates are themselves safety issues which need to be avoided, so a trade off needs to be made. The fact that the individual tail strikes themselves were completely safe, if not ideal, and the larger issue was rapidly recognised and corrected, strongly indicates the right trade offs have been made.
I have no idea whether Boeing has the same. It's an emerging area, sometimes called a Take Off Performance Monitoring System.
There are only two hard problems in computer science:
- cache invalidation
- naming things
- off-by-one errors
- concurrency/race conditions
- concurrency/race conditions
The nature of the bug was that if it couldn't find a usable runway, it would lower the weight until it did fit the runway it could find.
That's right, the software would say, "oh, the aircraft can't take off on the runway with this weight, let me just lower the weight so it can". Apparently the runway data was missing or wrong, but instead of saying, "no, you can't take off from there" the software said "here's a solution allowing you to take off, but at this lower weight".
I'm not sure how/if that was caused by a concurrency bug, but that's what I know.
If you are flying out of Denver (high altitude) on a summer day, you need a TON of runway to get off the ground. There are some aircraft that simply can't take off fully loaded from high altitude with the runways that exist.
The solution is to not take off fully loaded (lower the weight) So you either don't fully fuel up, or you remove cargo/passengers. It's very common, and by design. The software exists so that you know not to fully load the cargo bays if the conditions don't allow it (cargo makes airlines a lot of money).
You've got to be kidding me..
> Subsequently, a test of the software under high demand was developed.
This is wild that a basic kind of load test would not be done given the delicate nature of this system
Inaccurate weight and balance data is no joke, with the potential to cause much more serious issues.
I always try to permanently repair the software when I find bugs.
Sure, estimates are good... But why not just weigh the whole plane just before takeoff?
Simple strain gauges in the suspension struts would give you all the info you need. And then you can still use the old system of weighing all the stuff you put on the plane as a backup/sanity check if you want to.
You don't get to know the top-bottom weight distribution, but that is rarely an issue in aviation.
As another commenter has pointed out, there may be an issue with wind, as the whole point of the airplane is that it efficiently converts a relative air velocity into an apparent change in weight.
I have a hunch that this same issue might be even more of a problem for an airplane.
Source: Just supposition, but I was on a completely full flight (on an Embraer 175) last week and they held us on the tarmac while ground crews drove a 200lb ballast weight to us which was placed in the forward cargo area. To decide this was an issue after having pulled away from the gate implies to me that the issue was raised by instruments on the plane.
Source: I was personally loading cargo on an Embraer 175 two days ago. Also this link gives a good overview of weight sensors in planes.
https://aviation.stackexchange.com/questions/1850/do-some-ai...
That only raises further questions!
1) Why would a condition ever ONLY occur then? That is a huge red flag that your whole system is fucked. 2) Why didn’t you test that!?
Errrr what?
How do you even get this type of bug?! These scare me more than just a calculation error
Edit: on second thought this looks more like of some race condition on inputting the data, or maybe some query that fails and gets replaced by a 0
https://www.dynamicsource.se/recruitment/quality-assurance-m...
Is anyone else just absolutely astounded by how short that response time was?
>That morning, a software bug in an update to the DynamicSource tool caused it to provide seriously undervalued weights for the airplanes.
The real issue question here is how often do they patch this software? Airline control software should not be optimized for feature velocity. It should be optimized for quality and change really slowly.
Ideally, we would have as few updates to this software as possible. We're the pilots informed that the software had updated that morning?
I worry that our increasing comfort with updating constantly broken software bleeds into systems like this that matter for people's lives. Apple has me updating almost weekly because they can't seem to write exploit free software, but my iPhone is not going to kill me. That attitude is not Ok for airplanes.
This is the key point. I imagine the stakeholders here do not think the weight software is that critical, when in fact it could be. This is a common issue with complex systems.
Even though the software does not directly interface with the plane, its outputs are used to make key decisions on takeoff. Normally, there would be a large margin of error allowed, but in this case, due to the desire for max efficiency, the behavior of the aircraft is sensitive to the outputs.
The solutions are to (1) go back to having a large error margin, which of course should be cross-checked for sanity by the pilots, or (2) consider that the software is safety-critical, and should meet the same quality standards as the in-built flight systems.
The article says the software bug was fixed in 5 hours, but it’s not clear to me if that was a bug fix or a rollback.
Yes, they take a significant amount of extra fuel, but that significant amount is very carefully calculated because carrying more than legally required adds up to a loss quickly, especially if your competitors are sharper at calculating these figures.
The are ~100 parameters that go into these calculations, ranging from almanacs with tables of various trade winds and densities to engine types, consumption at various altitudes and power settings and so on. And then the required hold time, first alternate, second alternate and legal reserve required on landing.
Getting that code certified still makes me break out in sweat, but good thing that this kind of thing is reviewed very strictly. That also makes me wonder how wise it was to have the software this article is about as a SaaS rather than something more integrated and less easy to mess up using an update. Maybe doing it as a SaaS is a kind of loophole that avoids certification? (not current on this stuff).
I would suspect that certification would break down at some point; does a plain old calculator need to be certified? Certainly not, but I'd imagine the FAA or whoever if asked would prefer pilots use calculators than do everything by hand.
I'm curious about EFBs as well - I run W&B for my little bugsmasher in Foreflight. Has that gone through certification? Certainly someone from the FAA wouldn't have to review every release for that if so...
So when does certification come into play versus it just being another tool that pilots are responsible for validating?
One of the bigger problems I encountered was that the original software wasn't perfect, so the first step was to replicate it, bugs and all and only then to fix the bugs. So the FAA never entered into it but the Dutch equivalent did. Also, I think there is a big difference in stuff in use in GA versus that which is used for commercial aviation. We're talking early 90's or so, so the details are a bit hazy by now.
Interesting job though, that's for sure, lots of good lessons from that one. I'd never been sent back four or five times by an auditor because my work wasn't up to their standards and every time they sent me back they had a valid point, it wasn't bs just to check a box somewhere, they had valid concerns and I had to rework some of it quite extensively. At the level of "I don't care if the answer is correct, I need to understand why it is correct".
Every time there is a plane inspection, software update, at least 1 random person of the mechanical or software team for each party that directly touched either the plane or ground systems must be a passenger on the maiden operating flight for that plane/airport.
This would apply to all parties involved.
I'm sure the FAA can compensate and the FAA already has rules that are far costlier than this
Anecdotal, and probably just a result of software being more widespread in general, but it feels like incidents like these are becoming more frequent.
Finally I read the article. That was a bucket of cold water...
I also thought it was a new kind of bug somewhere in Alaska.
Presented with the words "bug" and "airplane", "bug" is mostly associated with the insect kind, not the software kind.
It’s really interesting, that there are no standardized systems, that interface with the planes directly.
>“The goal is to lower the power used on takeoff,” he said. “That reduces engine wear and saves money” on fuel and maintenance.
Cost cutting can do more harm than good, and occasionally puts lives in danger - they need to teach that in MBA classes.
> It's not like Airlines are making huge profits out of it too.
True, but airline margins are also very thin, so there is some incentive to "pinch pennies." And I do not put it past management to cost cut as much a possible for those sweet, sweet quarterly stock increases.
Given the recent record of lately in terms of safety, timely service, cancellations, forced retirements for pilots, etc, the trends are not looking good for the airline consumer.
> "The bug was identified quickly in part because some flight crews noticed the weights didn’t seem right and asked for manual validation of the figures....The Alaska captain said that, as for many things in aviation, pilots routinely use an acronym when they do the pre-takeoff “sanity check”: TLAR, which means “That Looks About Right.”"
Keeping well-trained humans in the loop in all partially or highly automated systems is important for this reason - and although corporate bean-counters in the overly finacialized US economy, whose prime motivation is to maximize shareholder profits by cutting labor costs, may not like to hear this, that mentality is the central reason behind the Boeing MAX debacle.
Pilots use LGTM too.
For example in that incident in Ireland where crew erroneously told their jet plane it was very, very cold, and then (cold air is dense, less power needed) they barely had enough thrust to take off before they ran entirely out of runway - that was partly caused (Swiss cheese model) by the pilots being issued with software that didn't make it easy for them to cross check the facts they can eyeball. Is it certain they'd have realised if their software did show this information - like the software issued to similar crews with other outfits? No, but that's one more opportunity for everybody to not die, and the whole point of the Swiss cheese model is that lots of things have to go wrong or else you're fine.
One of the other potential mitigations for that incident illustrates where human eyeballs don't help. In principle a human pilot could realise they aren't accelerating enough. In practice humans are lousy at estimating acceleration to the tolerance needed so this isn't effective unless you use the same strip so often that your brain learns exactly how things ought to look.
However thanks to GPS a machine can measure acceleration very well, and it can know how long your chosen runway is and what its take off speed is - so it can estimate if you're accelerating enough and the latest models can announce "Caution: Acceleration" early in the take off roll, before V1, which means the crew can abort and check why they didn't have the intended acceleration - regardless of the cause.
[0] https://www.businessinsider.com/boeing-outsourced-737-max-re...
[1] https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-...