Hacker News Reader

Comment by Johnny555 | Hacker News Reader

If the sensor fails, the plane fails

I don't believe that's true - if the sensor gives an erroneous reading, it's up to the pilot to recognize uncommanded trim and disable it by shutting off power to the system that moves the stabilizer.

Really, flying by instrumentation is what you're saying is the problem and that's the truth

Flying by faulty instruments is clearly bad, but flying by (working) instruments is much better than the alternative, every pilot going through instrument training learns very quickly that he needs to trust the instruments when flying in poor visibility, his senses don't work.

They could at least have both sensors active as a failsafe in case one is acting up

If you have two sensors and one is acting up, how do you know which one is true and which one is false?

View on HN

> If you have two sensors and one is acting up, how do you know which one is true and which one is false?

Typically it is possible to determine this by looking at reading stability. If one sensor is constantly stuck or changes values too fast (0-100% several times per second) or too slow, you know it's faulty. Those sensors should be engineered so that you can know if it's faulty. If you can't detect faulty sensor, it's just bad engineering.

If you have 2 sensors, how do you reliably detect that one of them is bent or installed incorrectly and gives an inaccurate, but stable, reading?

If the sensor is completely malfunctioning it's easier to detect, but what about when it's just wrong?

> how do you reliably detect that one of them is bent or installed incorrectly

During standard pre-launch or manufacturing tests. It should be verified by applying some change and checking that this change is measured correctly.

Generally for critical sensors, you can add some circuitry or even mechanical means of checking (eg heater on temperature sensor). If mechanical side fails, whole sensor module is marked as failed. Critical sensors should be designed in a way that you know when it fails.

You can also have 3 sensors and use a simple 2 of 3 check. The likeliness of 2 failing at the same time would probably be pretty low.

For many sensors especially critical ones there are multiple independent ones (like indicated airspeed). If they deviate there are standard procedures to determine which one(s) are faulty. For IAS you basically set a determined thrust at a determined pitch. Then you have a table which gives you IAS for the altitude you are at. This will determine the faulty pitot tube. I think for other sensors there are similar procedures.

> it's up to the pilot to recognize uncommanded trim and disable it by shutting off power to the system that moves the stabilizer.

You have other things to do on that flight stage (right after flaps have been set to 0)

Then you ought to react pretty quickly to disable the malfunctioning system that's going to force you into into a crash so you can continue flying the plane.

Yeah you have no idea of what you're talking about. An aircraft is not like your PC where you just click "ok" to some spurious popup and everything is fine

Cognitive load is a factor in many accidents. You don't have the plane doing something stupid during a critical stage (like take-off) with the excuse that you can "just disable it".

If a plane has an issue in keeping a stable flight but instead wants to point up or down beyond flight limits it is defective.

Edit: https://twitter.com/SarahTaber_bww/status/110525655715412787...

Isn't handling unexpected conditions the entire reason for having a pilot onboard?

If the pilot is not expected to detect and respond to something like a faulty sensor that causes an unwanted control surface movement, then why have the pilot onboard at all? Why not just let the plane fly itself?

Unexpected conditions is not to mean "the aircraft software design is stupid and will try to kill you".

Surely autopilot failure is a predictable fault regardless of the underlying cause?

There isn't one predictable manifestation of autopilot failure you can train over.

Oh please. Go read about some of the rudder hard-over failures the 737 suffered over the years. A pilot should be able to fly out of these things. I think unfortunately the children of the magenta line are the ones truly trying to kill us.

"Unexpected conditions" are different from "a plane that actively tries to commit suicide"

And if you think all pilots do is respond and detect to fault, I suggest you learn more about their duties on the cockpit.

The 37 max was designed to change stabilizer pitch in a key moment of unstable flight and that trim is not able to be overridden by elevator input. You have to disengage a thing a t a critical altitude when flaps 0 happens at only 1000’ or so agl on a system you didn’t know exsisted and only activates under a few uncommon parameters to counteract the large rotation moment that the forward engines give. You really don’t quite know what you are talking about. 1000’ per min vertical speed is not uncommon for a controlled descent.

While you seem to know what you're talking about, you're not very good at expressing it at all (lack of proper grammar doesn't help).

it was on mobile, sorry.

perhaps this is more clear:

The 37-max was designed to change the stabilizer to be more nose down in attitude in a key moment of unstable flight and that nose down stabilizer trim is not able to be overridden by elevator input on the yoke because of the design. To fix it, you have to disengage the runaway trimming of the stabilizer at a critical altitude when you disengage flaps at about 1000’ or so agl(above ground level) on a system you didn’t know existed. To further complicate this, it only activates under a few uncommon parameters(max thrust, high angle of attack, steep bank angle, flaps retracted, autopilot disengaged) to counteract the large rotation force that the forward engines give. 1000’ per min vertical speed is not uncommon for a controlled descent so you don't have much time to fix it. You really don’t quite know what you are talking about.

If the pilots don't have the cognitive load to take over manual control at any time, let alone react to the question of sensors that are returning impossibly divergent readings, surely they are already overloaded.

For that and other reasons I don't know if it's as difficult as you say; these sort of things are where very intelligent UX design can play a major role.

For impossibly divergent sensors as there were in this particular case, if the difference between divergent sensors is between a normal flying pattern and a crazy disastrous scenario, two things should happen— (1) both sensors should be considered untrustworthy and their use in automation should be suspended, and (2) the pilots should be asked the straightforward question "are you in a normal flying pattern" and if so, re-enable the sensor which fits this pattern.

Additionally/alternatively, they could fit a few off-the-shelf commodity accelerometers/gyros directly to the circuit board of the flight computers and use their readings exclusively to predict which "real" sensors is most likely correct. For example if one "real" sensor suddenly swings and the other one didn't, has there been any corresponding shift in the accelerometers? This would be a perfect candidate for machine learning with a few thousand hours of flight simulator data with simulated sensor failures based on known sensor failure modes.

> and (2) the pilots should be asked the straightforward question "are you in a normal flying pattern"

How do you do this when the pilots can't see outside?

I’m not saying that answering the question is mandatory. But if they’re cruising and everything seems fine, or if they’re mid takeoff and everything seems fine... probably the sensor which is indicating a nosediving is probably fine.

If they respond with “no” then they should be given maximal control of the aircraft with the computer not restricting control or making any large scale adjustments itself.

Reply on news.ycombinator.com