| HN Mirror

There's value in simplicity. Every decision that a flight computer makes is based on a leaky abstraction of the world, and it's important to be able to reason about those states without excessive complexity.

If a programmer, engineer, or pilot needs to think about when the aircraft will transition to "on ground" mode, and the answer is "when the weight on wheels sensors say the landing gear is not fully extended", that's simple. You can even extend this to reason about what might happen when the landing gear is not fully extended, or what happens if it does a belly crash-landing with the gear not deployed, or if it hops, etc. Furthermore, it's a perpetual signal, rather than an edge-triggered condition: You don't have to develop and remember and think about a state machine that transitions to the on-ground state, or worry about what happens if the flight computer gets reset, you can check the sensor state at any instant.

Yes, there are a myriad of checks and alternate modes you could do, or information items you could communicate to the pilot - radar altimeters, GPS altimeters, barometric altimeters, indicated airspeed, speed over the ground, weight on wheels, landing gear deployment, accelerometer/gyro/IMU history, stick position, flight model response to control inputs, brake response, ABS wheel speed sensors (if they have those, which I doubt), cameras...the list goes on.

With more data, you can potentially be more accurate if one or more sensors malfunctions. "Aircraft On Ground" could actually mean the aircraft is on the ground, rather than the abstract state that occurs when the weight-on-wheels sensors say the landing gear is not fully extended. But the more complexity you add, the more it gets difficult to understand!

I deal with this all the time - I'm an industrial controls engineer, working with robots and CNCs and assembly equipment rather than aircraft. But the machines still need to reason about the world. It's an important judgement, borne out of years of experience, to decide when you need to have a laser distance sensor or inductive proximity switch that confirms the part is present in the fixture. Sometimes you can reason about it and assert that if the part was in the previous fixture and the machine cycled, it must be in the new fixture, sometimes you need to put together multiple sensors or live information like CNC spindle torque to confirm that you're actually cutting steel. But usually, when you've got an operator or maintenance tech 600 miles away, looking at the machine you programmed 2 years ago, calling on the phone to ask why the machine is stuck on "Step 34: Wait for Part Present in Fixture B, then start CNC job O312" (or conversely, why it's skipping past this check and cutting air if the sensor is covered in swarf) everyone involved in reasoning about this equipment for the next decade would rather it be just a digital part present sensor.

This works in industrial automation where you can demand that the equipment's environment be precisely controlled, I'm less convinced that it will work well in fly-by-wire aircraft or (more pertinent to the average human) in level 3/4 self-driving cars. Simplicity has value, complexity adds cost..but is this cost worth the risk when there's a pilot who now has a thoracic spine fracture or a pedestrian crossing the road? I don't know.