PPRuNe Forums - View Single Post - Ethiopian airliner down in Africa
View Single Post
Old 16th Mar 2019, 22:40
  #1666 (permalink)  
StuntPilot
 
Join Date: Mar 2009
Location: EHAM
Posts: 41
Likes: 0
Received 0 Likes on 0 Posts
My thoughts about MCAS as a hardware designer:

1. Aircraft are nonlinear/unstable systems that can only be stabilized by control laws in a small (linear perturbations) part of the parameter space. A deep stall is an example of non-linearity.
2. Complexity explodes exponentially with state (autopilot mode, AOA vane failure detected etc.), an important design goal is to reduce state. State includes any if... then... in software.
When software initiates a state change on its own (autopilot switches off, systems disabled because of a broken sensor, stall recovery deployed) this should be announced to the pilot by aural warning. A pilot should always know exactly what the control state of the aircraft is, 'what is it doing now?' is not a good thing to wonder about up in the air.
3. There is unavoidable state that relates to the physics of flying: flaps, trim, gear = configuration. If automation is allowed to mess with configuration there must be cutouts and self-checks (cross checks against other sensors, stick position, whether data is consistent) to prevent instability.
4. MCAS has a very specific control function in a specific part of the flight envelope. It is easy to cross check with other sensors whether this part of the flight envelope is entered and how large a control input is required.

It puzzles me that, at complete odds with this, MCAS was given an integrating control function without bounds on a crucial flight control surface. Without data validity check. Without aural deployment warning. Without aural and visual AoA disagree warning. Without control input cross check. Without adiru cross check.

With safety critical subsystems there should always be at least 2 barriers before handing things over to a human as the last line of defense to prevent an incident.
StuntPilot is offline