abaillargeon's comments

Our market right now is general aviation and business jets. I believe our biggest customer is the Cessna Citation Longitude (max takeoff ~40,000lbs). I noticed the NTSB abstract had some recommendations for inclusion and certification of a system on a broader range of aircraft. Larger aircraft are required to have similar safety-related systems such as terrain, reactive windshear, etc so this could be the next step.

I get excited seeing stories about aviation on HN because it's something I work on every day. I've written a few comments above but I'm developer on the system you described (and more) being used in aircraft today.

With a GPS and onboard databases of runways and taxiways, we can determine if a pilot is attempting to take off or land on a taxiway. The key is preventing nuisance alerts when the pilot is just flying around and happens to be aligned with a runway. The "11 secret herbs and spices" depend on the aircraft but are usually speed and configuration (ie landing gear) based. Approaches are fairly predictable and we can use that to sequence through a state machine that tells us the pilot intends to land.

Here's a video of the system on a G1000 (meant for smaller planes) skip to 0:45ish https://www.youtube.com/watch?v=V2bswm0w4cY

Good question. We've run into similar issues while developing a related feature that helps pilots perform a stable approach. Sometimes pilots were performing a circling approach to a different runway, and a naive approach to determining lateral deviations would have caused a nuisance alert.

For this particular system, the alerting threshold is only met when we've determined that the aircraft is "landing". As I mentioned in another comment, I'm vague about this point because it depends on the way the aircraft manufacturer has configured this state machine. Sometimes we use throttle position, altitude, speed above Vref, gear position, height above threshold, etc. You're correct that conditions can slightly modify an approach, but we're confident that we can nail down "we're landing" closely enough to mostly eliminate nuisance alerts.

We do get some nuisance alerts from time to time, and part of my job is to investigate them and determine the cause. I did investigate one recently, however, where the cause was a runway that was "one-way". Most runways have two ends and the pilot/ATC determines which one to take off. EDDF (Frankfurt) RWY18 is only used for takeoffs and was causing nuisance alerts due to the way we search for the runway in front of the aircraft.

There's another runway (I don't remember where) where the direction in our database does not match what satellite imagery shows. I don't work in the database group but I was told that this can only be fixed by asking the airport manager to re-survey the runway. Short of that, we can't fix it even if we know it's wrong.

However, It's quite rare for them to be due to a database that's out of date -- most of the time it's due to an incorrect determination that the aircraft is taking off or landing.

We actually don't use the localizer to check for an incorrect runway or taxiway landing because the pilot can choose to do so and we don't want to issue nuisance alerts. Runways don't move often and we've found that a GPS and two databases (runways and airport ground features) are sufficient to determine if the pilot is approaching a runway or not.

We use inputs like GPS position, ground track, ground speed, altitude, and a phase-of-flight state machine that's determined for individual aircraft. This allows us to tailor the criteria for determining if the aircraft is landing for different aircraft. For some, we use throttle and landing gear position and others we use speed and altitude above the landing airport.

As for accuracy, we have minimum levels of GPS figure of merit where there's enough certainty to issue alerts. I don't remember the number off the top of my head, but in the US WAAS has made GPS quite accurate.

I've been anticipating the release of this report this since I heard about the incident.

I work on an avionics product that's designed to prevent this exact scenario. We use the aircraft's position along with a database of runways and taxiways to determine if the aircraft is approaching the runway the pilot intends. If we determine the aircraft is landing, we issue a visual and aural alert to the pilot ("TAXIWAY LANDING" or "NOT A RUNWAY").

I think there's some truth to your GNS 530 theory... Pilots are not typically that interested in stylish/modern UIs, and they're not thrilled when a familiar UI changes. There are so many features now that it's a challenge to find room on the PFD. I'm curious, which other UIs do you prefer? What do you think of the G1000 NXi?

Me too. This is something that already exists today [0]. It can detect when the aircraft is not lined up with a runway and issues a "Taxiway Landing" aural and visual alert.

[0] https://buy.garmin.com/en-US/US/p/545578 , see SurfaceWatch at the bottom.

Correct, there was probably a significant amount of simulator testing. Keep in mind that these kinds of simulators use real hardware and the avionics are being given inputs just like in the aircraft (i.e. the GPS antenna is simulated, but GPS inputs and uncertainty propagate through the system just like in the actual aircraft)

Most likely there is a test mode that raises the altitude floor/projected flight path at which it takes over. You could then perform the level-off at a safer altitude.

Not true, 95% of commercial aircraft have a TAWS system [0] that can show relative terrain on their navigation displays and provides FLTA alerts (forward looking terrain avoidance) by using an onboard terrain database. This is an FAA requirement for any aircraft with 6 or more passengers.

[0] https://en.wikipedia.org/wiki/Terrain_awareness_and_warning_...

I'm interested in learning more about how the various libc's are implemented. Can someone suggest one (or other C code) that I can download and look through? I am trying to find high quality open source C to learn from. Thanks

I've seen a few comments on HN and the blog about this question -- I think it's important to note that the article mentions this question was a set of pictures:

>>One test had many rows of small pictures, and I had to choose the odd one out in each row.

So the arguments about the number of letters, the order of the letter, etc wouldn't make sense here.