Jeg så nylig en dokumentasjon om XL Airways Germany Flight 888T . Dette fikk noen spørsmål til å stige i tankene mine:
To AOA-sensorer sviktet (fryset) samtidig. Fra Wikipedia:
To av tre angrepssensorer har blitt frosset og gjort ubrukelige. Systemlogikken er designet for å avvise sensorverdier som avviker betydelig fra de andre. I dette spesifikke tilfellet førte dette prinsippet til avvisning av den ene operative vinkelen til angrepssensoren, og til aksept av de to defekte, som ga lignende verdier, men som har sittet fast siden cruiseturen.
Airbus «stengte» datamaskinene på grunn av ulogiske verdier og viste USE MAN PITCH TRIM. Men som nevnt ovenfor, avviste Airbus den tredje sensoren og godtok de to fungerende sensorene.
- Hva fikk datamaskiner til å deaktivere og bytte til manuell modus?
Sammenligner man de ytre AOA-sensorene med gyrodataene (takk til brukeren «minutter» for å avklare forskjellen mellom AOA-sensor og kunstig horisontadata, men kanskje bruker Airbus Gyro-data som en mindre rangert AOA-referanse, som strømmer inn i påvisning av en defekt AOA-sensor)
- Hvorfor bytter ikke Airbus-datamaskiner til noe som alternativ lov automatisk, i stedet for å deaktivere FBW og vise en liten advarsel?
Det var veldig vanskelig å danne spørsmålene mine, og jeg er sikker på at jeg har glemt noe. Men jeg vil sette pris på det hvis du kan svare på spørsmålene.
Kommentarer
Svar
Tl; dr det var i direkte lov fordi luftdata var inkonsekvente og landingsutstyret var nede.
For et fullstendig svar på hvorfor flyet gjorde det de gjorde, vil jeg svare på noen spørsmål en om gangen.
Hvorfor avviste flycomputere den gode sensoren og brukte frosne?
Sensorenes verdier blir matet til kontrolldatamaskinene av ADIRU (luftdata og treghetsreferanseenhet). Det er tre ADIRUer som hver tilsvarer tre overflødige sensorsystemer. En del av ADIRU er ADR (luftdatareferanse). ADR er ansvarlig for å bestemme gyldigheten av verdiene som kommer fra luftdatasensorene (pitotrør, statisk port og AoA-vinger), og korrigere disse verdiene fra lokale AoA til fly AoA og mate verdiene til kontrolldatamaskinene. ( lokal AoA på sensorplasseringen er ikke nødvendigvis den samme som den totale fly AoA på grunn av deres plassering i flyet.) Hver ADR bruker to resolver for hver sensor og sammenligner disse verdiene for konsistens. Sammen med verdien sender den også til kontrolldatamaskinene en indikasjon på om verdiene er gyldige eller ikke.
ELAC (elevator / aileron computer), som styrer bevegelsen til flyflatene, tar verdiene fra hver ADIRU og sammenligner dem med medianverdien. Hvis en sensor avviker fra medianverdien forbi en viss terskel, antar den sensorfeil og avviser inngangen. Den bruker deretter gjennomsnittsverdien til de to andre.
Dessverre for mannskapet på XL888t forventer denne metoden en enkelt sensorfeil.Når to sensorer svikter med samme eller lignende verdi, vil systemet avvise den fungerende sensoren. Det er virkelig ingen måte å overvinne dette, men å ha to sensorer svikter med samme verdi er ekstremt usannsynlig.
Hvorfor forverret kontrollovene?
Dette er egentlig kjernen i spørsmål. ELAC er det som bestemmer kontrollovene. Den bruker informasjon fra flykonfigurasjonen (klaffer, lameller, luftbremser, understell) og utgang fra ADIRU for å bestemme hvordan pilotens kontrollinnganger skal tolkes. Den bruker denne informasjonen til å bestemme α-beskyttelseshastighetene (α-prot, α-gulv og VLS) og når de automatiske konvoluttbeskyttelsene skal aktiveres.
Normalt når flyet bremser, øker AoA med mindre det gis en nese ned. I tilfelle XL888t forsøkte pilotene med vilje flyet inn i en bod for å demonstrere α-beskyttelsen. Heisen og stabilisatoren var i full posisjon og motorene ble bremset. ELAC vil tillate denne posisjonen til den når de beregnede verdiene for α-beskyttelse. I dette tilfellet var AoA endres ikke. Når parametrene ELAC bruker, kommer så langt ut av terskelverdiene, kan ELAC ikke lenger foreta de nødvendige beregningene, så α-beskyttelsen blir deaktivert og kontrolloven blir nedbrutt til alternativ.
Så hvorfor gikk det i alvorlig ct-lov?
Testen mannskapet utførte den gangen var sjekk med lav hastighet i landingskonfigurasjon. » Landingskonfigurasjon indikerer åpenbart at landingsutstyret er nede. I alternativ lov er rullestyring i direkte lov, men pitchkontroll er fremdeles som den er i vanlig lov, med automatisk trim osv., Unntatt uten α-beskyttelse. Men når landingsutstyret er nede, skifter pitchkontrollen til direkte lov og autotrim blir koblet ut. Advarselen «BRUK MAN PITCH TRIM» vises på PFD. Det er piloter som ikke unnlater å legge merke til denne advarselen som resulterte i krasj.
Om hvorfor kontrollovene er utformet slik kan jeg ikke si. Kanskje noen andre kan forklare hvorfor Airbus tok det valget .
Merk: All denne informasjonen er hentet fra BAE-sluttrapport .
Kommentarer
- Takk! Besvarte spørsmålet mitt perfekt, og jeg kunne lære mange nye ting om Airbus Systems.
- “Det er egentlig ingen måte å overvinne dette” —no , men jeg forventer at det i det minste forteller pilotene at det skjedde. For flyhastighet gjør det det, og det er en upålitelig flyhastighetsprosedyre som skal følges når det skjer. Men for AoA-vinger gjør det ikke det.
- @JanHudec Jeg antar at Airbus tenker slik BEA gjør. Fra BEA-rapporten: » Angrepsvinkelen, selv om den er viktig for studiet av den aerodynamiske situasjonen til flyet, er ikke en pilot parameter. »
Svar
Hva som skjedde med flycomputerne er oppsummert tilstrekkelig på Wikipedia :
Noen av flyets datamaskiner mottok motstridende informasjon og opererte i degradert modus der noen beskyttelser ikke var tilgjengelige.
Mer nøyaktig: to av tre angrepssensorer har blitt frosset og gjort ubrukelige. Systemlogikken er designet for å avvise sensorverdier som avviker betydelig fra de andre. I dette spesifikke tilfellet førte dette prinsippet til avvisning av den ene operative vinkelen til angrepssensoren, og til aksept av de to defekte, som ga lignende verdier, men som har sittet fast siden cruiseturen. Dette førte igjen til uregelmessige beregninger av grensehastigheter. Dessuten var stalladvarsel i normal lov ikke mulig.
Alt det ovennevnte resulterte i svekket funksjonalitet til automatiserte systemer, noen stallbeskyttelsesfunksjoner var ikke tilgjengelige. Stalladvarsel var imidlertid fremdeles tilgjengelig, og har blitt utløst i løpet av den siste fasen av flyvningen.
Funnene fra offisiell rapport legger ikke skyld på hvordan systemene er designet. Alle funnene under » faktorer bidro til ulykken » er handlinger / beslutninger tatt av flybesetningen og » fravær av konsistens i skyllingsoppgaven i flyrenseprosedyren «.
Det er imidlertid en anbefaling angående flycomputere:
At EASA [skal] foreta en sikkerhet studere med sikte på å forbedre sertifiseringsstandardene for varslingssystemer for mannskaper under omkonfigurering av flykontrollsystemer eller opplæring av mannskaper i å identifisere disse omkonfigurasjonene og bestemme de umiddelbare operasjonelle konsekvensene. div>
USE MAN PITCH TRIMrefererer til, direkte lov. Flycomputeren burde ha blitt værende i normal lov fordi det ikke var noen logisk feil. Hva jeg vil vite: Hva fikk flycomputeren til å bytte til direkte lov? Dette skjer når det er en logisk feil. Hva var denne logiske feilen?