runaway stabiliser A320.
 

Gents,

These days flying the A320 series I am trying to wrap my head around the fact that there is no mentioning anywhere on the bus wrt a potential runaway stabiliser (only jammed stab).
I have flown multiple types in the past (Boeings/MD-80 etc) and all had stab cutout switches / runaway stab proc.

Is it correctly understood that, on the A320, in case of stabiliser issues, (ELAC2 malfunction?) the ELAC2 will fail or disconnect itself and ELAC1 will take over stab responsibility? (and consequently SEC2/SEC1 in that order).

Just curious, as I can not find any such info anywhere in the official Airbus manuals.

Thanks in advance,

SR

My uneducated guess is that it’s because the A320 has no trim switches.

I assume the runaway stab would come from defective trim switches on the yoke of a Boeing. As the trim order is electronically generated, this failure mode is negated.

Standing by for some educated person to point out the flaw in my logic 🙂

What documented accidents or incidents in history, have occurred on the Airbus fleet with "runaway stabilizer" ? There is no such procedure in the FCOM, nor an ECAM associated with "runaway stabilizer."

I came across one where two AoA sensors froze and, because they agreed, voted the correct one off the island. As other conditions changed, the aircraft began applying AND trim, causing the plane to pitch down. The pilot response was to pull the breakers for computers.

Of interest is recent news that Airbus has made a change to detect exactly this condition - two AoA sensors in close agreement, but not changing in reading, and to deselect them and use the remaining sensor instead.

I’ve wondered this myself and came to the conclusion that it just can’t happen. Worst case is that grabbing the trim wheel will (in theory!) block any stabiliser movement. The architecture was investigated in detail following a near fatal accident on a training flight and you’ll find it in the official report.

The 787 also has a set of stabiliser cutout switches and associated procedure. Whether this is actually necessary - since the trim switches don’t move the thing anyway except in direct mode - or just to maintain fleet commonality is a different question.

The problem wasn’t the trim though, the trimming was just a result. The problem was the envelope protection applying nose down flight control inputs. So there was no runaway trim, the trim worked as intended.

That's correct. Same for elevator control...
THS runaway is monitored by the computer controlling it, so there is no need to add switches...

Maybe a little detail regarding the topic:
In SEC runaway and jamming is detected the following:
SEC MON is computing a theoretical THS position, that is basically the commanded THS position out of the C*law through a filter, the filter acts like a "THS model". This position is compared to the actual position of the THS. In case they differ to much and this condition is true for a little time (If you are interested I look it up for you, the margin and the time) a potential runaway is issued. In case the override mechanism is active, pilot manual overriding, nothing happens other than the THS slaving is stopped.

Runaway and blocking is threated the same and only conclude to a final failure if the override mechanism isn't active.

Microswitches are signaling the computers if the mechanism is active. BTW. the error is also computed in COM. The RA failure flag from MON is send to COM via the Xtalk bus and there compared to the override input.