This is Garman SafeReturn, and this is its first real save.
Here's a demo.[1] It's been shipping since about 2020, originally on the Cirrus Vision Jet. There's a lot going on. The system is aware of terrain, weather, and fuel, but not of runway status. So it gives the ground a few minutes to get ready, sending voice emergency messages to ATC.
If you watch the flight track, you can see the aircraft circle several times, some distance from the airport, then do a straight-in approach. It sets up for landing, wheels down, flaps down, lands, brakes, and turns of the the engine. It doesn't taxi. Someone from the ground will have to tow or taxi the aircraft off the runway.
It's mostly GPS driven, plus a radar altimeter for landing.
The system can be triggered by a button in the cockpit, a button in the passenger area, and a system that detects the pilot isn't making any inputs for a long period or the aircraft is unstable and the pilot isn't trying to stabilize it. The pilot can take control back, but if they don't, the airplane will be automatically landed.
Famously the golfer Payne Stewart and the total of 6 people on the LearJet 35, died after a sudden loss of cabin pressure incapacitated everyone including the pilots. A system like this, would have detected it and possibly saved them.
I wouldn't expect a whole lot more detail, as that airport is often used by defense contractors like Ball Aerospace, who have a large office nearby.
There's a bit more detail today.[1] Air taxi service, plane flying with two pilots, no pax, loss of cabin pressurization, system activated automatically, crew decided to let it finish its job.[2]
Even without autoland, I've never understood why there wasn't an emergency system to handle depressurization events when it detects no pilot input. There have been enough ghost flights, even in the last 20 years, that such a system could've saved hundreds of lives. (Helios Air 552) Automatically dropping altitude, or even just changing the transponder to some automatic value, would help.
I guess in some cases lowering altitude could result in flight into terrain or possibly entering airspace where collision with other aircraft would be more likely ?
> Safe Return is an emergency system designed to be deployed by passengers in case of pilot incapacitation. But Safe Return also is programmed to activate itself when it senses the pilot has become unresponsive or succumbed to hypoxia.
Ah ok I was not aware of that. I have not flown a plane that had it (I did fly some with G1000 and autopilot but it didn't have this, I think it's only an option on the G3000). But I just saw about the activation button.
It says somewhere that the system also detects if the aircraft is unstable and the pilot has not attempted to stabilise it, or if there's no input for a long time.
My uncle was a pilot, and I asked him 15 years or so ago about the job. He was going on and on about computers and autopilot, claiming that pilots were only really needed anymore for takeoffs and landings, and they could sleep during the rest. Probably realizing the liability in what he said, he was quick to clarify that he didn't, of course.
In that short time span we now have a system that can land a plane by itself. Nothing less than magic, and huge congratulations and thanks to everyone at Garmin who made this happen.
Even take-off doesn't really need a pilot; the production Lockheed TriStar airliner had full automation and on at least one occasion ( 25 May 1972 ) flew entirely from runway to runway, across the USA, without pilot intervention.
Is there any option for passengers to chose another airport? Or for ATC to force the plane to use the next best airport? For example if the runway is under construction and severely blocked.
I would imagine it is aware of NOTAMs that indicate runways being closed when it picks where to land.
It's probably a possibility in some bizarre & unlikely set of circumstances with perfect timing, but even then it's still a better outcome than flying into the ground uncontrolled. See the Gimli Glider where a 767 flown by humans was forced to make an emergency landing at a runway that was actively being used as a dragstrip during the landing—everyone survived.
Absolutely amazing. Well done, Garmin. Imagine getting to go to work everyday to work on something that actually saves lives. Fantastic systems engineering work.
“ Imagine getting to go to work everyday to work on something that actually saves lives.”
I work on medical devices that improve and save lives but the work actually kind of sucks. You spend most of your time on documentation and develop with outdated tools. It’s important work but I would much prefer “move fast and break things”. So much more interesting.
That’s not necessarily a bad thing. I often encounter badly written or conflicting requirements. An AI may be better at detecting problems or gaps than humans.
I find the risk here that the requirements are the average of all requirements, so the exceptional things don't really get highlighted.
Because you now get this giant amount of text shoved in your face, you switch from thinking to validating. Is what's there correct, vs starting from a blank canvas. The doc already curtails your thoughts.
Kinda like all cars are starting to look the same. No one takes risks anymore.
No-one wants to / feels empowered to / has the knowledge to ask the really difficult questions.
I certainly get it. But I also am very frustrated with the snails-pace development of closed loop glucose pump system. The tech has existed for quite some time to implement them in theory. Body hackers have already done so a decade ago.
I often wonder if we have created the correct balance here. How many quality of life years have been lost due to the decades lost by being conservative? And how much of the conservative pace is done for the “right” reasons vs personal or corporate CYA?
For safety regulators, the incentives are all on the side of limiting acute downside (e.g. a plane crashing), not maximizing potential aggregate upside (e.g. millions of tons of fuel saved per year and millions of tons of C02 not in the atmosphere).
Society punishes regulators that approve products that kill people, so regulators adapt to this and as a result tend to be very conservative.
Regulators don't capture any of the upside (reputational or otherwise) when a new product enters the market and cures disease, makes cars more efficient, helps planes land on their own in an emergency, etc.
I don't know what "right" should be here, but you've hit on a good point. It's complicated.
Not to invalidate your experience, but I think both of you feel this way because “you only want what you don’t have”. There are different kinds of joy that come from being impactful, and different kinds that come from moving fast. If only we could move fast and be impactful :’(
I could be fast and impactful. Just in a negative way. The problem is that I come from the software dev side so I tend to be less interested in the medical side. It’s the same in a lot of safety critical. There is a lot of mundane work to tick the necessary checkboxes. There isn’t much that is interesting from a technological side. Maybe the result is interesting but getting there takes a lot of extremely boring work.
Maybe you should change your line of work. If you're that unhappy about what you do in spite of the fact that what you do is orders of magnitude more important than the next move-fast-and-break-things-advertising-driven-unicorn then that suggests to me that you should let someone else take over who does derive happiness from it and you get yours from a faster paced environment.
Personally, you couldn't pay me enough to do the latter and I'd be more than happy to do the former (but I'm not exactly looking for a job).
I am retiring next year. So that should solve my problem :). I don’t know how other medical device companies are working but in mine leadership is dominated by people who know medical devices from a sales or medical perspective. Software is kind of secondary to them although it’s becoming really important. A lot of our processes aren’t very good for software so we end up doing a lot of work that makes no sense and makes the product actually worse. It’s better not to fix bugs because a new release will take months of paperwork. The requirement structure doesn’t map to software but the SOP isn’t written by people who known software. It feels a little like the development speed of NASA with the SLS vs SpaceX who are basically doing everything faster and cheaper while still having high reliability . My company is NASA here. Just very frustrating
I've worked with a startup in the medical device space. Well funded. They were indistinguishable from most other startups, except in one detail: they did everything right. They made some extremely high tech stuff, very lightweight, and technology wise they were closer to watchmakers than to software and hardware people. I loved working with them and helped them to improve their yield (their QA was so strict that of their initial couple of runs more than 2/3rds of the devices got binned for the smallest infractions).
I suspect you may have just been unlucky with where you ended up. I'm getting closer to retirement myself but I no longer have to work for 'the man' so in that sense I got really lucky. But I really sympathize with how you feel. So, count the days, and look forward to something nicer. Best!
From what I have seen startups have it a little easier. They are usually focused on one product and often just get acquired before having to go to market themselves. Selling multiple products worldwide and complying with regulations is a totally different ballgame.
What you describe sounds nothing like most, safety-critical development I've heard of. Whereas, I've heard the other person's story countless times when I studied high-assurance systems. Very slow, top-down, process-heavy, paperwork-heavy, and outdated tools.
On the other hand, it sounds like the company you mentioned is worth imitating where possible. They sound awesome. Are you allowed to name them? Is there any writeup on how they balanced velocity and regukatory approval?
Unfortunately not. But the devices they make are absolute life savers and I found it one of the most interesting jobs I did in the last couple of years because I think I learned more from them than they learned from me. I was just focusing on a handful of details, they had to keep the broader picture in mind all the time and educate me to the point that my knowledge became useful to them.
You are probably right that they are uncommon, but the fact that the company was led by a scientist who was very much involved in the process and the mission and offloaded as much of the non-essentials of the CEO job to others made me feel I had gone back in time to be near HP when they were just founded. In the longer term I expect them to dominate the space.
What is in this particular case that requires outdated tools? If they are code, certainly you can write them on VS Code or whatever you likes, and only need to compile and load on the original tools, can’t you?
It’s more the library and language side. Typically you are years behind and once a version has proven to be working, the reluctance to upgrade is high. It’s getting really interesting with the rise of package managers and small packages. Validating all of them is a ton of effort. It was easier with larger frameworks
Sometimes it's because you need to support ancient esoteric hardware that's not supported by any other tools, or because you've built so much of your own tooling around a particular tool that it resembles application platform in it's own right.
Other times it's just because there are lots of other teams involved in validation, architecture, requirements and document management and for everyone except the developers, changing anything about your process is extra work for no benefit.
At one time I worked on a project with two compiler suites, two build systems, two source control systems and two CI systems all operating in parallel. In each case there was "officially approved safe system" and the "system we can actually get something done with".
We eventually got rid of the duplicate source control, but only because the central IT who hosted it declared it EOL and thus the non-development were forced, kicking and screaming to accept the the system the developers had been using unofficially for years.
You'd be even more impressed if you saw just how little resources they have to use (ram, storage, cpu), or how old of a C standard they have to work with. I have a few friends that work on this.
And also — sadly — Monkey C. I cannot imagine what possessed them to invent their own scripting language for wearable device apps. It's sort of like JavaScript but worse and with minimal third-party tooling support.
it kinda sucks, but with the constraints it's at least understandable. they wanted an extremely lightweight language with a bytecode VM which could be ported to whatever MCUs in 2015, while also strictly limiting the functionality for battery usage reasons (and, uh, product segmentation/limiting third party access).
Garmin really is setting a standard for modern engineering. Hard to think of another company that still has solid engineering for both consumer and industrial applications.
I have a Garmin "smart" watch (with every app notification etc disabled) and I love the fact that I can do almost two weeks of exercises (ride, walk, gym) without needing to charge it. The bike computers are also solid. But sadly the UX of the software on these leaves a bunch to be desired, and I've been bitten by many software and firmware bugs in the last years... Including months for which HRM would randomly and persistently drop it's value from say whatever the real value (say 145 for argument sake) to 80.
I know all of the wrist watches experience this issue, but this was extreme like drop from 145->80 for like 60+ min then rapidly shopt back up. Not like a small couple min blip.
This was a near the top end model at the time, and after complaining Garmin support owned up that this was a firmware bug impact all sensors of that generation and it would take 2+ months to fix (took like 5).
But they did send me a HRM for free and I've been using that. So I am grateful that and using it since. But for short rides (like 90 min or less) I don't always remember to think to bring the HRM.
Prior to that I had two lower end Garmin watches, and despite having theoretically lower end HR sensors they did not experience such bugs or drop outs (an unexpected blip every once in a while).
But I think the main point still stands, their software/firmware/UX has not moved in relation with the hardware. Next time I'm in the market I will be consider all the options. Feels like Coros and others have come a long way.
Prob the biggest thing keeping me in their ecosystem is multi sport (variations of bike riding types -- I do all), hiking, strength training, erg, winter sports. But even there the list of strength exercises has not been updated in like a decade.
Look at coros. Currently wearing Nomad - getting around a month of runtime on a charge WITH notifications enabled (not too many tho, only important ones). And UX is great too imho. (Not affiliated, just a happy customer)
Even the hardware is kind of stupid. They push you into basically buying a separate gps device for each and every hobby you do. It would be nice if there was one gps device that could be a bike computer, exercise watch, golf gps, etc etc. Yes, some devices have multisport mode but usually feature locked compared to the more sport specific device, and for no good reason really. I guess that would prevent them from selling you a $600 gps half a dozen times so that is why it isn’t done.
You can just strap the watch to the handlebars, no?
There’s also a mode where you can extend the display from your watch to a bike computer, for instances where you’re doing a multisport activity (or just want to record on a single device).
The one bright side is that when I switched from Apple Watch to Garmin I couldn’t stand the notifications UX. It finally got me to turn off watch notifications and I feel much freer.
Then again I understood exactly what it was saying every time, which is more than I can say for some of the other traffic on that recording. I’m not sure synthetic-sounding means bad here.
The embedded systems qualified for use in general aviation avionics have very limited hardware resources. They are severely constrained by form factor, power, and cooling. It's amazing that the developers were able to get speech synthesis working so well.
This, if it sounds too human ATC is going to try to help and possibly provide vectors, as they should, but The way the system works, ATC needs to be prioritizing clearing the runway and keeping aircraft away
This is a huge milestone, and everyone at Garmin who worked on Autoland should be patting themselves on the back, they saved some lives today and will undoubtedly save more. Amazing technology.
It's amazing what this technology can do. I wonder what the interface in the cockpit was like, who activated it and why, how it chose the runway, and other details that will likely come out in the final report if not earlier.
I think the radio call could be improved a bit though. It spends sooo much time on the letters and so little on the "emergency" part. It almost runs that sentence together "Emergencyautolandinfourminutesonrunway. three. zero. at. kilo. bravo. juliet. charlie."
>Aircraft November 4.7. Niner. Bravo. Romeo. Pilot incapacitation. Six miles southeast of Kilo. Bravo. Juliet. Charlie. Emergency auto land in four minutes on runway three zero right at Kilo. Bravo. Juliet. Charlie.
It would be nice to hear something more like:
Aircraft November-Four-Seven-Niner-Bravo-Romeo. Mayday mayday mayday, pilot incapacitation. Six miles southeast of the field. Emergency autoland in four minutes on runway three zero right at Bravo-Juliet-Charlie.
Still amazing, and successful clear communication ... but it could use some more work :)
The cockpit side is very passenger friendly, it assumes zero aviation knowledge. It's a single button and once pressed the system will show on the screens that it's active, what to expect and where it is going. The passengers just sit and watch, while it tells you via voice and on the screens what's happening. No action required apart from the single button.
It uses the navigation database (onboard) and weather data via datalink (ADS-B in the US, satellite in other places) to select an airport/runway. It looks for a long enough runway with a full LPV (GPS) approach available and favorable wind.
Some of the audio replays I heard had silence cut out, but the aircraft transmits every two minutes, for about twenty seconds each. It does share the information I'd want to hear in an uncontrolled environment, but in a busy towered class delta it likely needs to be shortened. They had plenty of advance warning of this aircraft being inbound and cleared the airspace well before it arrived, but if it had happened with less notice critical instructions may have been "stepped on" at a critical time.
The only complaint is it uses phonetics for everything multiple times in each transmission, I'm a radio guy, I would use phonetics once, then otherwise spelled out letters - aka, "whiskey lima foxtrot" and WLF the next time I needed to say it.
This is not how communication is done in aviation. Instead, it’s common to abbreviate to the last three alphanumerics of tail numbers (so “niner alpha bravo” for N789AB) after the first call — but this is conditional on not having a potentially confusing other aircraft on frequency (N129AB), and the system here can’t reasonably know that, so must take the conservative option.
I took issue with calling out the airport, multiple times in full phonetics, both at the beginning and the end of the transmission. All other callsigns, perfectly reasonable.
If anything, the tail number does not matter nearly as much. A plane with auto land presumably already has ADSb out (almost certainly 1090ES), is squawking 7700, and is probably already IFR anyway. As in this situation, the controllers knew well in advance they had an emergency inbound and who it was. At an uncontrolled field, I need something to tag (robotic "bravo-romeo" is plenty) and a relative position. Bonus if it does the math and predicts landing time, which it does.
Frankly, it should know (like I have to) if it's going to auto land at a towered field or uncontrolled, and adjust as necessary to those circumstances.
I’m not sure I agree. Not sure I disagree, either. If I’m another pilot in the air when this occurs, it feels like the most important things for me to know are (1) stay the hell away from the runway, and the announced approach, for a while; (2) only a single aircraft is doing an emergency autoland currently; (3) assume that the aircraft will need medical response while on runway (no auto-taxi) so if I was planning on landing in the next half hour or so, go to alternate. (1) and (3) are well covered, but (2) is subtle — /today/, the chance of two aircraft doing an emergency autoland at the same field at the same time is negligible, but it’s still something both I and the system designers need to think about.
I'd actually argue that Aviation is the outlier among Part 90, Amateur, and Public Safety users. The general rule in most radio services is using both phonetics and not, as to try to balance intelligibility and communications density.
It's an outlier because typically the comms cycle is very fast and only a single cycle. The radios are also quite bad and there isn't room for errors that you'd normally correct naturally in the context of a longer conversation
Can’t say “the field” in the general case; there are many places in the NAS where the same frequency is used by a few uncontrolled airports that are close together.
I'm pretty sure that every ATC already knows this automated voice and what it means.... in a year or two, after having stories and videos it will become even more well known and then people will say that repeating emergency too much or spending too much time on it is a waste of airtime.
I wonder if a human is in the loop. Obviously the software is hardly ever used (a good thing), so you wouldn't need many humans available. If communication is possible, wouldn't you hand control to a pilot on the ground?
I don't know that they could actually fly the plane - is latency too high for landing? - but they could make all the decisions and communicate with air traffic control, other planes, and the passengers.
The problem is every aircraft model flies differently. The remote pilot would need to be familiar with that particular type of aircraft to safely land it.
I'm thinking of higher-level contributions such looking at the weather and saying 'fly to this airport and use this runway'; or asking the passenger, 'what does this gauge say?' or 'look at the left engine; what do you see?'; or talking to air traffic control.
One major difference is if a uav crashes no one dies. But in china there is apparently now a commercial pilotless flying ev taxi service - which is autonomous with a human on the ground in the loop as you are suggesting.
Remote piloting for landing an aircraft that size is problematic because you need more sensors on the aircraft plus a reliable, high-bandwidth, low-latency data link. That doesn't really exist in most places. When the military lands something like an MQ-9 Reaper they typically hand off control to a pilot located within line-of-sight right at the airfield. That obviously isn't practical for civilian general aviation.
I second that. Hearing in the VASAviation video (linked by someone else in a nearby thread) the robotic voice announcing what it's doing, while it does a completely autonomous landing in an airport it autonomously decided on, with no possibility of fallback to or help from a human pilot, is one of these moments when we feel like we're living in the future promised by the so many sci-fi stories we've read as children.
Embraer has been working on their auto takeoff system, E2TS, for some time. While improved safety during a critical phase of flight is a goal, airlines are looking at the possibility that it allows increased performance (higher MTOW, shorter runways, less fuel burn.)
"You're absolutely right; that runway was decommissioned in 1974 and is now a cornfield. Would you like me to contact emergency medical services and file an accident report with the F.A.A.?"
Unfortunately there was a plane crash on Thursday of a Cessna Citation 550 that killed former Nascar driver Greg Biffle, his wife, his two kids, and both pilots. Greg Biffle himself was a certificated pilot and helicopter pilot but not flying in the crash. Incredibly sad. Hopefully technology such as this can reduce these tragedies.
What does the AF 449 crash have to do with the existence of a button to return the aircraft to wings level + zero vertical speed?
To answer your question though, LVL has been around for close to two decades now. IIRC there was a Cirrus/Garmin partnership that added it to the latter's G1000/GFC 700 and it's since trickled out to other consumer-grade autopilots.
The AF 449 was in a stall, and the pilots panicked and did exactly the wrong thing. The pilot came out of the lavatory and immediately realized what was wrong, and pushed the stick forward. But it was too late.
If the captain could figure it out, so could the computer.
I recall another crash, not so long ago, of a commuter plane where the wings iced up a bit and the airplane stalled. The crew kept trying to pull the nose up, all the way to the ground. They could have recovered if they pushed the stick forward - failing basic stall recovery training.
There are many others - I've watched every episode of Aviation Disasters. Crew getting spatially disoriented is a common cause of crashes.
No, one of the pilots put the plane into an aerodynamic stall because they had failed sensors giving them erroneous airspeed information and he kept overriding the other pilot who was doing the correct thing to recover from the stall he had put the aircraft in.
What exactly was a computer at the time supposed to figure out with unreliable data, especially after a stall had first developed?
Also in fairness I was a bit too opaque with my point, which is that 1) LVL requires the pilot to actually press it, which they are unlikely to do if like you yourself have mentioned they are clueless about what situation they're actually in, and 2) LVL is not appropriate stall recovery so I don't really see how it is relevant to a case of an aerodynamic stall.
It should be. I don't see how it couldn't be designed to do stall recovery. After all, the avionics do recognize a stall (as it activates the "pull up" stick shaker).
I will repeat this as I have had to say it before:
There is no engineering fix to AF447. You cannot protect a plane from what is essentially a rogue pilot who is not restrained.
It would have happened exactly the same in a Boeing. The problem was a supposedly trained and tested pilot responding to a somewhat normal event (loss of awareness and disorientation) by freaking the fuck out and throwing a plane into the ocean from 30k feet. The copilot knew what was going on with 3 minutes left until impact, and was trying to fix things, and was using the feature to override dual input, and was still being hampered by a pilot who was refusing to do the only safe thing he should have: Sit back and shut the fuck up.
The actual solution is regular testing of pilots in stressful simulations to ensure they react predictably in bad situations. That can never be perfect though.
My suggestion was not about overriding the "nut behind the wheel", but providing the crew with a button that says "fix it".
P.S. my lead engineer at Boeing told me they can fix everything but the "nut behind the wheel".
As I mentioned before, my dad taught instrument flying. What he'd do is go through all the maneuvers where your body gets tricked, and the student (under a blackout hood so they could only see the instruments) must recover. And they'd do it over and over, until the student stopped believing his screaming senses and trusted the instruments.
I don't know all that can be simulated in a simulator. I don't know if modern flight training is sufficient.
BTW, experiments were done with birds to see how they flew "in the soup" (zero visibility). The birds would just fold their wings and drop out of it. It seems that evolution hasn't evolved a method for navigating blind.
> a commuter plane where the wings iced up a bit and the airplane stalled. The crew kept trying to pull the nose up, all the way to the ground.
There’s probably a lot that match, but sounds like Colgan Air 3407 in 2009 (the last major commercial airline crash in the US before the mid-air collision earlier this year in DC)
> "If the captain could figure it out, so could the computer."
The autopilot had disengaged, most likely because the pitot tubes had iced over.
The aircraft system entered ALT2 mode, where bank-angle protection is lost. Protection for angle-of-attack is also lost when 2 or more input references are lost.
You might describe these circumstances as the computer saying "I don't know what the heck's going on, you humans figure it out please".
As a former engineer who worked on the 757 flight control system, I am not terribly impressed with that design.
Having 3 pitot tubes iced over means they read 0 velocity. It is reasonable for the computer to be designed to recognize that if all three pitot tubes read 0, then the pitot tubes are the problem. With the altimeter unwinding, it should be able to recognize a stall. With the turn and bank indicator, and the AOA indicator, it should be able to return to straight and level.
Recall that the captain figured it out at a glance and knew exactly what to do.
The FAA report[1] gives a more comprehensive description of events.
The pitot tubes had differential icing, and didn't all read 0kts – they reported different velocity against each tube, such as 40kts or 60kts (against an expected baseline of ~ 275kts). The computer correctly recognised the data was invalid and rejected it.
It's a common narrative that the captain immediately figured out the issue. The report and transcript of the cockpit recording[2] notes that the captain's interventions showed that he had not identified the stall, nor had the copilots.
~ cockpit recording ~
0:00 autopilot disconnects
0:01 [copilot right] "I have the controls"
0:11 [copilot right] "We haven't got a good display of speeds"
1:26 captain enters cockpit
1:30 [copilot right] "I don’t have control of the airplane at all"
1:38 [captain] "Er what are you doing?"
3:37 [captain] "No no don't climb"
4:00 [captain] "Watch out you’re pitching up there"
4:02 [copilot right] "Well we need to we are at four thousand feet"
4:23 ~ recording stops ~
[1] https://www.faa.gov/sites/faa.gov/files/AirFrance447_BEA.pdf
[2] https://bea.aero/uploads/tx_elyextendttnews/annexe.01.en.pdf
Is it possible that 40/60 kts indicates a stall? Nevertheless, the drop in altitude while the nose was up should also indicate a stall.
I know that designing avionics, and accounting for all possible scenarios is a difficult job, and we learn from the failures. But I don't buy that it was impossible/impractical for the avionics to figure out what was going on based what the other instruments were saying.
I agree that comparing the various sensor data points could allow a reasonable conclusion: e.g. IAS is variable across sensors therefore IAS is unreliable, so what additional information could allow a reasonable diagnosis?
The flight system could identify a stall and prominently alert the pilots. That's one of the recommendations from the report: to implement a dedicated stall warning. The stall warning was actually active, but disregarded/unrecognised by the pilots because of the number of other simultaneous alarms and extraneous information, including an intermittent recommendation from the Flight Director system to pitch up at 12°.
In general, Airbus aircraft don't have a dedicated AOA indicator visible to the pilots; instead AOA is visualised to the pilots by proxy via the airpeed indicator.
For AF447 the flight avionics probably had enough information to bring the aircraft back to straight and level flight without pilot input.
On the other hand the 737 Max crashes were attributed to MCAS overriding the pilot input and lowering the nose, in response to incorrect/faulty AOA sensor data.
Both were extreme examples, and the recommendations probably coalesce somewhere in the middle: better information (and alert prioritisation) for pilots and redundancy in sensors and logic.
Air Astana Flight 1388 also comes to mind. I'm not sure how a flight control system would deduct cross-connected aileron controls and adapt accordingly (without introducing other risks or failure modes). Given the glacial pace of change and approval in aviation, we're probably 20–50 years away from that level of autonomy.
IIRC, they were dealing with frozen pitot tubes or other sensors that were keeping the air data computing hardware from getting valid input. An automated "Get me out of trouble" button might have had the opposite effect.
As I mentioned elsewhere, the captain figured out what was wrong immediately, but he was too late.
BTW, my dad taught instrument flying in the AF. He said it was simple - look at the instruments. Bring the wings level, then the pitch level. Although simple, your body screams at you that it's wrong.
He carried with him a steel pipe, so he could beat a student unconscious who panicked and would not let go of the controls. This was against regulation, but he wasn't going to let a student pilot kill him.
When JFKjr's crash was on the evening news, he said two words - "spacial disorientation". Months later, that was the official cause.
they were disoriented because a sensor was frozen or something like that and the readings were not correct if I remember correctly, an automatic system would have received the same wrong information.
Awesome to see stuff like this. Light sport aircraft have parachutes. Cool to see safety being incorporated into the avionics and not just flying it, but getting her down safely.
This is one of my biggest frustrations with aviation— the certification required to get this done is hugely onerous. The whole basis of certified aircraft is that they may not change, which makes improvements like airframe parachutes, auto land systems, and even terrain awareness, engine monitoring, etc. very costly to obtain. I think there is an argument to be made that there should be a pathway to airframe recertification to allow for innovation and improvement to take place in the aviation industry.
Instead, the FAA is probably going backwards on this issue and doubling down on the regulatory framework that gave us the MAX-8 situation while narrowing any avenue for smaller firms to innovate [0]
There is simply no way to retrofit a parachute into an existing airframe. The airframe has to be designed around it from the start with appropriate stress points.
There are retrofit ballistic recovery systems available as a Supplemental Type Certificate (STC) for several existing airframes, e.g. https://brsaerospace.com/cessna/
It's not clear what caused the crash of the private jet carrying Greg Biffle and family. The Garmin Autoland system is designed to address pilot incapacitation, not mechanical failures or active pilot errors.
I know. NTSB is on it. It’s just sad. Smaller aircraft should have safety features in case of mechanical issues to be able to bring it down to land without catastrophic injuries.
Not sure why the downvotes when all I want is for someone to live. I understand it’s harder for larger aircraft but anything 8 passenger or less, this should be considered.
My wish is that one day aircraft will operate off batteries that are charged via the fuselage solar panels and that the airframe will be light enough to support “rapid deceleration pods” or other parachute like devices to bring the aircraft to the ground. Larger commercial aircraft can recharge at the gates.
Eliminating the combustible fuel in the wings is another huge win.
Very different standards - in its current form of emergency autoland it just needs to be proven to result in equal or better outcomes as a plane with no rated pilot onboard; the best case is another person that knows how to use the radio and can listen to instructions but the more likely case is a burning wreckage when the pilot is incapacitated.
To always auto land it needs to be as good as a fully trained and competent pilot, a much higher standard.
did you see the disruption to air traffic? everyone that needed to land had to go into a holding pattern. the plane was communicating to tower and was going to land since it was emergency. it was not observing other traffic, part of landing is knowing the location of other aircrafts to avoid collision. This doesn't seem to have collision detection/avoidance and space coordination with other aircrafts and entering holding pattern to delay programming yet. This is a good start.
If they designed it to be used for every landing those issues would be resolved. The rarer you use features like this, the more disruptive they will be.
That's a really big if, especially since not all traffic has a transponder, and not all airports are towered.
It would need to understand how to visually look for traffic with a camera, and understand what intentions other pilots are communicating on the radio.
Because it requires specific equipment that many airports do not have, for one. It also doesn't understand things like noise abatement procedures. It has to be setup properly. You don't want pilots forgetting how to fly the airplane. Any of a dozen other reasons.
I've confirmed with my own 2 eyes cars driving on the road without humans in them. I've also rode in a Waymo which had no driver. They definitely exist. Teslas also have self driving.
I define “self driving car” as level 5. Or at least 4. It should’ve able to drive itself under almost all circumstances. And well.
Tesla isn’t that. Nor Ford. Nor GM. Nor anyone else. Waymo is closest, but they limit the domain and clearly still have issues. Stick a Waymo in snow on rural roads is it good to go? Doubt it.
I've ridden on a King Air a few times. Surprised how fast the thing was, traveling west to east we sustained 600mph ground speed. Also pretty quiet interior given it's powered by turboprops.
There are rumors that there were 2 pilots aboard, and that one of them accidentally triggered autoland, and they couldn't figure out how to turn it off:
It's mostly GPS driven, plus a radar altimeter for landing.
The system can be triggered by a button in the cockpit, a button in the passenger area, and a system that detects the pilot isn't making any inputs for a long period or the aircraft is unstable and the pilot isn't trying to stabilize it. The pilot can take control back, but if they don't, the airplane will be automatically landed.
[1] https://www.youtube.com/watch?v=d-ruFmgTpqA
I wouldn't expect a whole lot more detail, as that airport is often used by defense contractors like Ball Aerospace, who have a large office nearby.
[1] https://avweb.com/aviation-news/garmin-autoland-activation-c...
[2] https://www.cbsnews.com/colorado/news/plane-emergency-landin...
[3] https://www.buffaloriveraviation.com/
The chances of colliding with anything else would be tiny. In case of other commercial jets zero, thanks to TCAS at the least.
TCAS = traffic alert and collision avoidance system
> Safe Return is an emergency system designed to be deployed by passengers in case of pilot incapacitation. But Safe Return also is programmed to activate itself when it senses the pilot has become unresponsive or succumbed to hypoxia.
Source: https://www.aopa.org/news-and-media/all-news/2025/june/pilot...
My uncle was a pilot, and I asked him 15 years or so ago about the job. He was going on and on about computers and autopilot, claiming that pilots were only really needed anymore for takeoffs and landings, and they could sleep during the rest. Probably realizing the liability in what he said, he was quick to clarify that he didn't, of course.
In that short time span we now have a system that can land a plane by itself. Nothing less than magic, and huge congratulations and thanks to everyone at Garmin who made this happen.
https://www.lockheedmartin.com/en-us/news/features/history/l...
"Garmin Autoland Activation Was Crew Decision" - https://avweb.com/aviation-news/garmin-autoland-activation-c...
It's probably a possibility in some bizarre & unlikely set of circumstances with perfect timing, but even then it's still a better outcome than flying into the ground uncontrolled. See the Gimli Glider where a 767 flown by humans was forced to make an emergency landing at a runway that was actively being used as a dragstrip during the landing—everyone survived.
I work on medical devices that improve and save lives but the work actually kind of sucks. You spend most of your time on documentation and develop with outdated tools. It’s important work but I would much prefer “move fast and break things”. So much more interesting.
I find the risk here that the requirements are the average of all requirements, so the exceptional things don't really get highlighted.
Because you now get this giant amount of text shoved in your face, you switch from thinking to validating. Is what's there correct, vs starting from a blank canvas. The doc already curtails your thoughts.
Kinda like all cars are starting to look the same. No one takes risks anymore.
No-one wants to / feels empowered to / has the knowledge to ask the really difficult questions.
I often wonder if we have created the correct balance here. How many quality of life years have been lost due to the decades lost by being conservative? And how much of the conservative pace is done for the “right” reasons vs personal or corporate CYA?
For safety regulators, the incentives are all on the side of limiting acute downside (e.g. a plane crashing), not maximizing potential aggregate upside (e.g. millions of tons of fuel saved per year and millions of tons of C02 not in the atmosphere).
Society punishes regulators that approve products that kill people, so regulators adapt to this and as a result tend to be very conservative.
Regulators don't capture any of the upside (reputational or otherwise) when a new product enters the market and cures disease, makes cars more efficient, helps planes land on their own in an emergency, etc.
I don't know what "right" should be here, but you've hit on a good point. It's complicated.
Personally, you couldn't pay me enough to do the latter and I'd be more than happy to do the former (but I'm not exactly looking for a job).
I suspect you may have just been unlucky with where you ended up. I'm getting closer to retirement myself but I no longer have to work for 'the man' so in that sense I got really lucky. But I really sympathize with how you feel. So, count the days, and look forward to something nicer. Best!
So it is definitely possible. But it isn't common, that's definitely true.
On the other hand, it sounds like the company you mentioned is worth imitating where possible. They sound awesome. Are you allowed to name them? Is there any writeup on how they balanced velocity and regukatory approval?
Unfortunately not. But the devices they make are absolute life savers and I found it one of the most interesting jobs I did in the last couple of years because I think I learned more from them than they learned from me. I was just focusing on a handful of details, they had to keep the broader picture in mind all the time and educate me to the point that my knowledge became useful to them.
You are probably right that they are uncommon, but the fact that the company was led by a scientist who was very much involved in the process and the mission and offloaded as much of the non-essentials of the CEO job to others made me feel I had gone back in time to be near HP when they were just founded. In the longer term I expect them to dominate the space.
Other times it's just because there are lots of other teams involved in validation, architecture, requirements and document management and for everyone except the developers, changing anything about your process is extra work for no benefit.
At one time I worked on a project with two compiler suites, two build systems, two source control systems and two CI systems all operating in parallel. In each case there was "officially approved safe system" and the "system we can actually get something done with".
We eventually got rid of the duplicate source control, but only because the central IT who hosted it declared it EOL and thus the non-development were forced, kicking and screaming to accept the the system the developers had been using unofficially for years.
I suspect a lot of aviation is the same.
Many private planes use outdated tech, carbeurated piston powered engines driving propellers.
Maintenance heavy, but all of it is well known and stable.
(please don't)
https://developer.garmin.com/connect-iq/monkey-c/
High integrity computing is full of pain staking processes, exactly because no one trusts C developers to do the right thing.
I have a Garmin "smart" watch (with every app notification etc disabled) and I love the fact that I can do almost two weeks of exercises (ride, walk, gym) without needing to charge it. The bike computers are also solid. But sadly the UX of the software on these leaves a bunch to be desired, and I've been bitten by many software and firmware bugs in the last years... Including months for which HRM would randomly and persistently drop it's value from say whatever the real value (say 145 for argument sake) to 80.
It’s annoying but a proper HR strap fixes all the issues associated with wrist based optical readers.
This was a near the top end model at the time, and after complaining Garmin support owned up that this was a firmware bug impact all sensors of that generation and it would take 2+ months to fix (took like 5).
But they did send me a HRM for free and I've been using that. So I am grateful that and using it since. But for short rides (like 90 min or less) I don't always remember to think to bring the HRM.
Prior to that I had two lower end Garmin watches, and despite having theoretically lower end HR sensors they did not experience such bugs or drop outs (an unexpected blip every once in a while).
But I think the main point still stands, their software/firmware/UX has not moved in relation with the hardware. Next time I'm in the market I will be consider all the options. Feels like Coros and others have come a long way.
Prob the biggest thing keeping me in their ecosystem is multi sport (variations of bike riding types -- I do all), hiking, strength training, erg, winter sports. But even there the list of strength exercises has not been updated in like a decade.
There’s also a mode where you can extend the display from your watch to a bike computer, for instances where you’re doing a multisport activity (or just want to record on a single device).
https://www.dcrainmaker.com/2019/06/garmins-triathlon-extend...
Also avionics aren't that underpowered these days. They have full touchscreen displays and multicore CPUs.
https://news.ycombinator.com/newsguidelines.html
I think the radio call could be improved a bit though. It spends sooo much time on the letters and so little on the "emergency" part. It almost runs that sentence together "Emergencyautolandinfourminutesonrunway. three. zero. at. kilo. bravo. juliet. charlie."
>Aircraft November 4.7. Niner. Bravo. Romeo. Pilot incapacitation. Six miles southeast of Kilo. Bravo. Juliet. Charlie. Emergency auto land in four minutes on runway three zero right at Kilo. Bravo. Juliet. Charlie.
It would be nice to hear something more like:
Aircraft November-Four-Seven-Niner-Bravo-Romeo. Mayday mayday mayday, pilot incapacitation. Six miles southeast of the field. Emergency autoland in four minutes on runway three zero right at Bravo-Juliet-Charlie.
Still amazing, and successful clear communication ... but it could use some more work :)
It uses the navigation database (onboard) and weather data via datalink (ADS-B in the US, satellite in other places) to select an airport/runway. It looks for a long enough runway with a full LPV (GPS) approach available and favorable wind.
So, "Columbia traffic, Cessna november one two three alfa bravo [N123AB], three mile final, full stop, runway one eight, Columbia traffic"
At a towered airport, you'd say "Columbia tower" instead, and you don't have to repeat it at the end of your message.
Frankly, it should know (like I have to) if it's going to auto land at a towered field or uncontrolled, and adjust as necessary to those circumstances.
I don't know that they could actually fly the plane - is latency too high for landing? - but they could make all the decisions and communicate with air traffic control, other planes, and the passengers.
Militaries have been flying UAVs for awhile now, which must have the same challenges.
I second that. Hearing in the VASAviation video (linked by someone else in a nearby thread) the robotic voice announcing what it's doing, while it does a completely autonomous landing in an airport it autonomously decided on, with no possibility of fallback to or help from a human pilot, is one of these moments when we feel like we're living in the future promised by the so many sci-fi stories we've read as children.
To answer your question though, LVL has been around for close to two decades now. IIRC there was a Cirrus/Garmin partnership that added it to the latter's G1000/GFC 700 and it's since trickled out to other consumer-grade autopilots.
If the captain could figure it out, so could the computer.
I recall another crash, not so long ago, of a commuter plane where the wings iced up a bit and the airplane stalled. The crew kept trying to pull the nose up, all the way to the ground. They could have recovered if they pushed the stick forward - failing basic stall recovery training.
There are many others - I've watched every episode of Aviation Disasters. Crew getting spatially disoriented is a common cause of crashes.
What exactly was a computer at the time supposed to figure out with unreliable data, especially after a stall had first developed?
Also in fairness I was a bit too opaque with my point, which is that 1) LVL requires the pilot to actually press it, which they are unlikely to do if like you yourself have mentioned they are clueless about what situation they're actually in, and 2) LVL is not appropriate stall recovery so I don't really see how it is relevant to a case of an aerodynamic stall.
Of course. I did say it was a button to press!
> LVL is not appropriate stall recovery
It should be. I don't see how it couldn't be designed to do stall recovery. After all, the avionics do recognize a stall (as it activates the "pull up" stick shaker).
Yep, the real design problem here is the idiocy of allowing dual input.
There is no engineering fix to AF447. You cannot protect a plane from what is essentially a rogue pilot who is not restrained.
It would have happened exactly the same in a Boeing. The problem was a supposedly trained and tested pilot responding to a somewhat normal event (loss of awareness and disorientation) by freaking the fuck out and throwing a plane into the ocean from 30k feet. The copilot knew what was going on with 3 minutes left until impact, and was trying to fix things, and was using the feature to override dual input, and was still being hampered by a pilot who was refusing to do the only safe thing he should have: Sit back and shut the fuck up.
The actual solution is regular testing of pilots in stressful simulations to ensure they react predictably in bad situations. That can never be perfect though.
P.S. my lead engineer at Boeing told me they can fix everything but the "nut behind the wheel".
As I mentioned before, my dad taught instrument flying. What he'd do is go through all the maneuvers where your body gets tricked, and the student (under a blackout hood so they could only see the instruments) must recover. And they'd do it over and over, until the student stopped believing his screaming senses and trusted the instruments.
I don't know all that can be simulated in a simulator. I don't know if modern flight training is sufficient.
BTW, experiments were done with birds to see how they flew "in the soup" (zero visibility). The birds would just fold their wings and drop out of it. It seems that evolution hasn't evolved a method for navigating blind.
There’s probably a lot that match, but sounds like Colgan Air 3407 in 2009 (the last major commercial airline crash in the US before the mid-air collision earlier this year in DC)
https://en.wikipedia.org/wiki/Colgan_Air_Flight_3407
The aircraft system entered ALT2 mode, where bank-angle protection is lost. Protection for angle-of-attack is also lost when 2 or more input references are lost.
You might describe these circumstances as the computer saying "I don't know what the heck's going on, you humans figure it out please".
Having 3 pitot tubes iced over means they read 0 velocity. It is reasonable for the computer to be designed to recognize that if all three pitot tubes read 0, then the pitot tubes are the problem. With the altimeter unwinding, it should be able to recognize a stall. With the turn and bank indicator, and the AOA indicator, it should be able to return to straight and level.
Recall that the captain figured it out at a glance and knew exactly what to do.
The pitot tubes had differential icing, and didn't all read 0kts – they reported different velocity against each tube, such as 40kts or 60kts (against an expected baseline of ~ 275kts). The computer correctly recognised the data was invalid and rejected it.
It's a common narrative that the captain immediately figured out the issue. The report and transcript of the cockpit recording[2] notes that the captain's interventions showed that he had not identified the stall, nor had the copilots.
Thank you. I had not seen the transcript before.
Is it possible that 40/60 kts indicates a stall? Nevertheless, the drop in altitude while the nose was up should also indicate a stall.
I know that designing avionics, and accounting for all possible scenarios is a difficult job, and we learn from the failures. But I don't buy that it was impossible/impractical for the avionics to figure out what was going on based what the other instruments were saying.
1. 40/60 kts on pitot tubes - could that be showing a flat spin?
2. rotating compass - flat spin?
3. altitude drop - stall
4. attitude - level, no bank
5. engines - operating normally
6. GPS - no forward progress
Does that add up to a stall?
The flight system could identify a stall and prominently alert the pilots. That's one of the recommendations from the report: to implement a dedicated stall warning. The stall warning was actually active, but disregarded/unrecognised by the pilots because of the number of other simultaneous alarms and extraneous information, including an intermittent recommendation from the Flight Director system to pitch up at 12°.
In general, Airbus aircraft don't have a dedicated AOA indicator visible to the pilots; instead AOA is visualised to the pilots by proxy via the airpeed indicator.
For AF447 the flight avionics probably had enough information to bring the aircraft back to straight and level flight without pilot input.
On the other hand the 737 Max crashes were attributed to MCAS overriding the pilot input and lowering the nose, in response to incorrect/faulty AOA sensor data.
Both were extreme examples, and the recommendations probably coalesce somewhere in the middle: better information (and alert prioritisation) for pilots and redundancy in sensors and logic.
Air Astana Flight 1388 also comes to mind. I'm not sure how a flight control system would deduct cross-connected aileron controls and adapt accordingly (without introducing other risks or failure modes). Given the glacial pace of change and approval in aviation, we're probably 20–50 years away from that level of autonomy.
BTW, my dad taught instrument flying in the AF. He said it was simple - look at the instruments. Bring the wings level, then the pitch level. Although simple, your body screams at you that it's wrong.
He carried with him a steel pipe, so he could beat a student unconscious who panicked and would not let go of the controls. This was against regulation, but he wasn't going to let a student pilot kill him.
When JFKjr's crash was on the evening news, he said two words - "spacial disorientation". Months later, that was the official cause.
Most flight instructors just keep a spare pen in their pocket to jab an uncooperative student in thigh with. (Thankfully almost never used.)
- https://www.garmin.com/en-US/blog/aviation/blue-button-helpi...
- https://pilotsupport.avidyne.com/kb/article/50-dfc90-wings-l...
Awesome to see stuff like this. Light sport aircraft have parachutes. Cool to see safety being incorporated into the avionics and not just flying it, but getting her down safely.
Instead, the FAA is probably going backwards on this issue and doubling down on the regulatory framework that gave us the MAX-8 situation while narrowing any avenue for smaller firms to innovate [0]
[0] https://avbrief.com/faa-wants-to-phase-out-ders
Not sure why the downvotes when all I want is for someone to live. I understand it’s harder for larger aircraft but anything 8 passenger or less, this should be considered.
My wish is that one day aircraft will operate off batteries that are charged via the fuselage solar panels and that the airframe will be light enough to support “rapid deceleration pods” or other parachute like devices to bring the aircraft to the ground. Larger commercial aircraft can recharge at the gates.
Eliminating the combustible fuel in the wings is another huge win.
To always auto land it needs to be as good as a fully trained and competent pilot, a much higher standard.
It would need to understand how to visually look for traffic with a camera, and understand what intentions other pilots are communicating on the radio.
I've never seen any clear info about that.
Tesla isn’t that. Nor Ford. Nor GM. Nor anyone else. Waymo is closest, but they limit the domain and clearly still have issues. Stick a Waymo in snow on rural roads is it good to go? Doubt it.
We won't get into what happens when I drive on a rural road covered with snow and ice... no, really, let's not go there. Moving right along...
We have a couple of nuclear-powered self-driving cars on Mars.
https://vansairforce.net/threads/garmin-emergency-autoland-i...
https://avbrief.com/autoland-crew-consciously-let-system-tak...