Final Report incidente AF447 - Commenti Tecnici

[flyingbrandon]

Ammetto di non capirci un tubo di tecnicismi, ma il fatto uomo/computer l'ho capito e devo dire che in caso d'emergenza penso sia meglio avere un pilota preparato che sappia prendere in mano la situazione, che un computer....

Forse non l'hai capito perfettamente perché è proprio questo che accade.
Ciao!

[87Nemesis87]

anche Volare di Settembre ha fatto un articolo sul final report dell'incidente. Sostanzialmente è un riassunto su quando detto su questo thread. L'articolo parla di quanto evidenziato dall'ente francese investigativo e rileva anche i problemi di cui state parlando.

Vi ho allegato le tre pagine e spero le troviate interessanti

[sigmet]

anche Volare di Settembre ha fatto un articolo sul final report dell'incidente. Sostanzialmente è un riassunto su quando detto su questo thread.

Vuoi vedere che dobbiamo mettere il copyright?

[flyforever85]

Leggendo il documento che ha scritto JT8D ho capito ceh se il comando di manovra viene dato contemporaneamente dai due piloti allora questo viene sommato algebricamente. Qualcuno sa se c'e' un funzionamento analogo sui Boeing?

[lucams]

Leggendo il documento che ha scritto JT8D ho capito ceh se il comando di manovra viene dato contemporaneamente dai due piloti allora questo viene sommato algebricamente. Qualcuno sa se c'e' un funzionamento analogo sui Boeing?

No, sui boeing non ci può essere... se il PF muove il volantino a destra, anche quello del PNF si sposta a destra... quindi, entrambi sanno sempre cosa sta facendo l'altro...

su Airbus, invece, non sei in grado di vedere cosa fa la mano dell'altro, e non hai nessun feedback sullo stick. Quindi può accadere di fare due cose diverse tra loro...

[flyforever85]

Leggendo il documento che ha scritto JT8D ho capito ceh se il comando di manovra viene dato contemporaneamente dai due piloti allora questo viene sommato algebricamente. Qualcuno sa se c'e' un funzionamento analogo sui Boeing?

No, sui boeing non ci può essere... se il PF muove il volantino a destra, anche quello del PNF si sposta a destra... quindi, entrambi sanno sempre cosa sta facendo l'altro...

su Airbus, invece, non sei in grado di vedere cosa fa la mano dell'altro, e non hai nessun feedback sullo stick. Quindi può accadere di fare due cose diverse tra loro...

Ok, pero' a questo punto non capisco l'utilita' di questa azione... perche' lasciare ad entrambi i piloti la possibilita' di decidere autonomamente come muovere l'aereo?

[MarcoGT]

Leggendo il documento che ha scritto JT8D ho capito ceh se il comando di manovra viene dato contemporaneamente dai due piloti allora questo viene sommato algebricamente.

A meno che uno dei due piloti non prema il "Priority Button"

[flyforever85]

Leggendo il documento che ha scritto JT8D ho capito ceh se il comando di manovra viene dato contemporaneamente dai due piloti allora questo viene sommato algebricamente.

A meno che uno dei due piloti non prema il "Priority Button"

Si ho letto, pero' mi riesce strano pensare che si possa lasciare la guida da un aereo ad una "somma" di azioni... Mi verrebbe piu' facile pensare che quella del comandante ha sempre la priorita' sull'altra... non ne capisco l'utilita' ecco

[flyingbrandon]

Si ho letto, pero' mi riesce strano pensare che si possa lasciare la guida da un aereo ad una "somma" di azioni... Mi verrebbe piu' facile pensare che quella del comandante ha sempre la priorita' sull'altra... non ne capisco l'utilita' ecco

Che un sidestick prevalga sull'altro sarebbe estremamente pericoloso.
Ciao!

[flyingbrandon]

Si ho letto, pero' mi riesce strano pensare che si possa lasciare la guida da un aereo ad una "somma" di azioni...

Non è strano...è la cosa più "naturale". Non essendo i collegamenti meccanici , ciò che simula maggiormente un comportamento meccanico tra i due sidestick è proprio una somma algebrica. In un volantino convenzionale è la somma delle forze tra i due piloti, qua tra i due segnali. Se io con un volantino tradizionale tiro verso di me e tu lo spingi, a parità di forza, rimane fermo...ed è quello che accade anche con il sidestick attraverso la somma algebrica dei segnali....così come dx e sx. personalmente preferisco nettamente percepire il movimento dell'altro, cosa che qui non accade e trovo a volte poco istintivo dover tener premuto il tasto per intervenire...però ci si abitua.
Ciao!

[flyforever85]

Si ho letto, pero' mi riesce strano pensare che si possa lasciare la guida da un aereo ad una "somma" di azioni...

Non è strano...è la cosa più "naturale". Non essendo i collegamenti meccanici , ciò che simula maggiormente un comportamento meccanico tra i due sidestick è proprio una somma algebrica. In un volantino convenzionale è la somma delle forze tra i due piloti, qua tra i due segnali. Se io con un volantino tradizionale tiro verso di me e tu lo spingi, a parità di forza, rimane fermo...ed è quello che accade anche con il sidestick attraverso la somma algebrica dei segnali....così come dx e sx. personalmente preferisco nettamente percepire il movimento dell'altro, cosa che qui non accade e trovo a volte poco istintivo dover tener premuto il tasto per intervenire...però ci si abitua.
Ciao!

Ok forse mi mancava questo passaggio: anche negli aerei convenzionali (non fly-by-wire per intenderci) se un pilota cabra e l'altro picchia della stessa intensità, l'aereo continua ad andare dritto... giusto?

[MatteF88]

Ok forse mi mancava questo passaggio: anche negli aerei convenzionali (non fly-by-wire per intenderci) se un pilota cabra e l'altro picchia della stessa intensità, l'aereo continua ad andare dritto... giusto?

Si muovono assieme, non é che tu puoi spingerla avanti fino a fondo corsa e il tuo collega a fianco può tirarsela alla pancia....se tu spingi avanti anche l'altro va avanti, se giri il volantino lo giri a sinistra anche quello a fianco va a sinistra...se ho interpretato bene la tua domanda...oppure, comunque, se il collega al tuo fianco tira con una certa intensità e tu spingi con la sua stessa forza il volantino sta fermo...

[bigshot]

Si ho letto, pero' mi riesce strano pensare che si possa lasciare la guida da un aereo ad una "somma" di azioni...

Non è strano...è la cosa più "naturale". Non essendo i collegamenti meccanici , ciò che simula maggiormente un comportamento meccanico tra i due sidestick è proprio una somma algebrica. In un volantino convenzionale è la somma delle forze tra i due piloti, qua tra i due segnali. Se io con un volantino tradizionale tiro verso di me e tu lo spingi, a parità di forza, rimane fermo...ed è quello che accade anche con il sidestick attraverso la somma algebrica dei segnali....così come dx e sx. personalmente preferisco nettamente percepire il movimento dell'altro, cosa che qui non accade e trovo a volte poco istintivo dover tener premuto il tasto per intervenire...però ci si abitua.
Ciao!

Però manca il feedback il che toglie, a mio modesto parere di esperto di "parlare comodo dalla poltrona dietro lo schermo", il significato a quello che hai spiegato tu.

E sempre dall'alto della mia esperienza in "sputare sentenze" e, adesso seriamente, quella elettronica/informatica chiedo: è proprio così impossibile fornire questo genere di esperienza sui sidestick airbus?
Ok che con un buon addestramento si possono evitare episodi così critici ma la pratica non ha dimostrato che forse ne sarebbe valsa la pena?

[MarcoGT]

è proprio così impossibile fornire questo genere di esperienza sui sidestick airbus?

Beh dal punto di vista elettronico/informatico è semplicissimo.
Ma sarebbe comunque un force feedback finto

[lucams]

Beh, la discussione tra la filosofia di Airbus e quella Boeing è vecchia, e non mi ci voglio addentrare in questo thread, certamente io sono uno di quelli che vorrebbe "vedere" con gli occhi le mani di quello accanto cosa fanno e "sentire" con il tatto il volantino che si muove perchè l'altro lo sta muovendo...

Da un punto di vista di programmazione dei sistemi, come già detto da MarcoGT, il "force feedback" è banale. E infatti non è una questione di difficoltà tecnica, quanto di filosofia di realizzazione.

[flyforever85]

Si ho letto, pero' mi riesce strano pensare che si possa lasciare la guida da un aereo ad una "somma" di azioni...

Non è strano...è la cosa più "naturale". Non essendo i collegamenti meccanici , ciò che simula maggiormente un comportamento meccanico tra i due sidestick è proprio una somma algebrica. In un volantino convenzionale è la somma delle forze tra i due piloti, qua tra i due segnali. Se io con un volantino tradizionale tiro verso di me e tu lo spingi, a parità di forza, rimane fermo...ed è quello che accade anche con il sidestick attraverso la somma algebrica dei segnali....così come dx e sx. personalmente preferisco nettamente percepire il movimento dell'altro, cosa che qui non accade e trovo a volte poco istintivo dover tener premuto il tasto per intervenire...però ci si abitua.
Ciao!

Però manca il feedback il che toglie, a mio modesto parere di esperto di "parlare comodo dalla poltrona dietro lo schermo", il significato a quello che hai spiegato tu.

E sempre dall'alto della mia esperienza in "sputare sentenze" e, adesso seriamente, quella elettronica/informatica chiedo: è proprio così impossibile fornire questo genere di esperienza sui sidestick airbus?
Ok che con un buon addestramento si possono evitare episodi così critici ma la pratica non ha dimostrato che forse ne sarebbe valsa la pena?

Beh, la discussione tra la filosofia di Airbus e quella Boeing è vecchia, e non mi ci voglio addentrare in questo thread, certamente io sono uno di quelli che vorrebbe "vedere" con gli occhi le mani di quello accanto cosa fanno e "sentire" con il tatto il volantino che si muove perchè l'altro lo sta muovendo...

Da un punto di vista di programmazione dei sistemi, come già detto da MarcoGT, il "force feedback" è banale. E infatti non è una questione di difficoltà tecnica, quanto di filosofia di realizzazione.

E' questo il punto: penso che ognuno di noi in situazioni estreme come un aereo che perde quota o stalla vorrebbe cercare di apportare il più velocemente possibile dei cambiamenti repentini al velivolo per rigovernarlo. Quale delle due filosofie di progetto dovrebbe portare (almeno sulla carta) il maggior beneficio? mi sa che è una domanda un po' complessa...

[gibuti]

scusate l'ignoranza,da modesto pilota di monomotori a pistoni,ma veramente su un Airbus i volantini non vanno insieme??

[MarcoGT]

scusate l'ignoranza,da modesto pilota di monomotori a pistoni,ma veramente su un Airbus i volantini non vanno insieme??

Su Airbus non ci sono volantini, ma sidestick.
Non hanno collegamenti meccanici, ma solo elettrici e non sono collegati tra di loro.
Quando viene "spostato" quello del Cpt, quello del F/O resta in posizione centrale e viceversa.

[flyingbrandon]

E' questo il punto: penso che ognuno di noi in situazioni estreme come un aereo che perde quota o stalla vorrebbe cercare di apportare il più velocemente possibile dei cambiamenti repentini al velivolo per rigovernarlo. Quale delle due filosofie di progetto dovrebbe portare (almeno sulla carta) il maggior beneficio? mi sa che è una domanda un po' complessa...

Qua non ti seguo. Io posso controllato con la stessa prontezza di un volantino tradizionale. Tu prima parlavi dell'assurdità della somma algebrica degli impulsi sul sidestick...

[Happylandings]

E' questo il punto: penso che ognuno di noi in situazioni estreme come un aereo che perde quota o stalla vorrebbe cercare di apportare il più velocemente possibile dei cambiamenti repentini al velivolo per rigovernarlo. Quale delle due filosofie di progetto dovrebbe portare (almeno sulla carta) il maggior beneficio? mi sa che è una domanda un po' complessa...

Qua non ti seguo. Io posso controllato con la stessa prontezza di un volantino tradizionale. Tu prima parlavi dell'assurdità della somma algebrica degli impulsi sul sidestick...

Da quanto ho capito, dimmi se sbaglio, lui intendeva, se l'aereo fa dei cambiamenti repentini, per rimetterlo in "carreggiata" è più efficace il volantino Boeing a fondo corsa oppure un "dual imput" Airbus, con i due sidestick a fondo corsa?
Non penso sia corretto e abbia senso fare un paragone del genere, poichè il volantino è tarato per avere una certa "forza" nella virata o cabrata o picchiata, adatta per quell'aereo, il sidestick lo stesso, cambiano le sensazioni. E' comunque molto raro che sia il sidestick che il volantino vengano portati a fondo corsa, ancora più raro che entrambi i sidestick arrivino a fondo corsa assieme.
Ma in airbus quando fate il flight control check, lo fate con entrambi i sidestick o solo con uno?
Ciao

[flyingbrandon]

Ma in airbus quando fate il flight control check, lo fate con entrambi i sidestick o solo con uno?
Ciao

Uno alla volta ma entrambi.
Ciao!

[Happylandings]

Ma in airbus quando fate il flight control check, lo fate con entrambi i sidestick o solo con uno?
Ciao

Uno alla volta ma entrambi.
Ciao!

Ok, grazie
Ciao

[JT8D]

E' questo il punto: penso che ognuno di noi in situazioni estreme come un aereo che perde quota o stalla vorrebbe cercare di apportare il più velocemente possibile dei cambiamenti repentini al velivolo per rigovernarlo. Quale delle due filosofie di progetto dovrebbe portare (almeno sulla carta) il maggior beneficio? mi sa che è una domanda un po' complessa...

Qua non ti seguo. Io posso controllato con la stessa prontezza di un volantino tradizionale. Tu prima parlavi dell'assurdità della somma algebrica degli impulsi sul sidestick...

Da quanto ho capito, dimmi se sbaglio, lui intendeva, se l'aereo fa dei cambiamenti repentini, per rimetterlo in "carreggiata" è più efficace il volantino Boeing a fondo corsa oppure un "dual imput" Airbus, con i due sidestick a fondo corsa?
Non penso sia corretto e abbia senso fare un paragone del genere, poichè il volantino è tarato per avere una certa "forza" nella virata o cabrata o picchiata, adatta per quell'aereo, il sidestick lo stesso, cambiano le sensazioni. E' comunque molto raro che sia il sidestick che il volantino vengano portati a fondo corsa, ancora più raro che entrambi i sidestick arrivino a fondo corsa assieme.
Ma in airbus quando fate il flight control check, lo fate con entrambi i sidestick o solo con uno?
Ciao

Muovere contemporaneamente i due sidestick è una procedura sconsigliata, e genera anche un allarme, sia visivo che sonoro.

Paolo

[Alien]

Confesso, non ho ancora letto completamente il Report, ma se considero l’analisi e le conclusioni, posso tentare di fare qualche commento personale, e, al momento, di livello generico. L’unica cosa piuttosto certa, dal mio punto di vista di specialista FCS, è che in nessun modo si è trattato di un problema dei comandi di volo.

Il nodo del problema, come presentato nel Report, è che tutti e due i piloti (il Captain era ancora assente) hanno in qualche modo reagito alla sconnessione AP, senza rendersi conto che tale sconnessione era dovuta alle anomalie delle IAS, delle quali si sono resi conto solo a posteriori -e non è nemmeno chiaro di quanto-. Dal punto di vista umano, mi sembra perfettamente naturale che l’associazione causa-effetto venga sempre mentalmente costruita tenendo conto della successione temporale degli eventi, così come sono realizzati coscientemente. Il nostro istinto ci dice che la causa precede sempre l’effetto.

Posso quindi presumere che abbiano avuto notevoli e comprensibili difficoltà a correlare le anomalie di velocità come cause (e non effetti, come sembravano) della sconnessione dell’AP. Credo che dal loro punto di vista questa sia stata la sfortuna maggiore in assoluto. Una errata valutazione causa-effetto li ha anche portati a non considerare nel modo corretto i warning di stallo (e quindi a sottovalutarli in qualche modo).

La perdita delle velocità, in sè, non dovrebbe essere critica, ma si presuppone che i piloti eseguano la procedura prevista, e, conseguentemente, per eseguire tale procedura comprendano esattamente l’accaduto. Ogni procedura di emergenza dovrebbe essere inizializzata da una corretta valutazione dello scenario, e ogni corretta valutazione dovrebbe essere possibile a seguito di corrette indicazioni. Cosa che non è avvenuta, purtroppo, in quanto non c’è stato alcun display preciso al riguardo (salvo PITOT). La loro attenzione quindi è stata inizializzata dal warning AP, effetto e non causa del problema, e non sono riusciti in alcun modo a farsi una corretta immagine mentale dello scenario che si presentava loro.

Mi sembra poi che il PF abbia reagito correttamente al warning AP, in quanto, a seguito di perdita di quota, riprendendo il controllo manuale, ha dovuto riportare il velivolo in quota tirando lo stick a cabrare. La perseveranza successiva nel tirare a cabrare sembra essere un errore grave; potrebbero esserci diversi motivi tali per cui il PF abbia agito in tal modo. Sta di fatto che, direi, all’origine di questo comportamento potrebbe esserci la stessa motivazione precedente, e cioè una pressochè totale incomprensione dello scenario in quanto l’effetto “mascherava” la comprensione della causa.

Mi sembra di capire che la filosofia consolidata del design delle indicazioni di velocità lasci al pilota la funzione di monitoring. Normalmente, in un sistema ridondante, la funzione di monitoring (cioè di verifica di eventuali discordanze tra i valori dei singoli canali) viene implementata nei computer. Il software si deve accorgere di differenze, e segnalarle. Ma il software dei sistemi ridondati deve anche preoccuparsi di mostrare ai piloti l’informazione “votata”, cioè una informazione unica e univoca, depurata in qualche modo dei canali guasti, e comunque di un certo livello di integrità propria. In altre parole, un’informazione alla quale i piloti possano credere.

Invece, in questo sistema, l’informazione (triplex) viene presentata ai piloti come, appunto, originata dai singoli tre canali, cioè ADR1, ADR2 e ADR3. Un indicatore per il Captain e un indicatore -separato- per il FO (in aggiunta ad un altro strumento separato di “arbitrio” tra i due) provvedono le indicazioni dei canali ridondati. I piloti possono commutare l’informazione del proprio display dal proprio ADR (1 o 2 rispettivamente) ad ADR3, eseguendo così un monitoring tra il proprio canale ed il terzo canale di riserva (senza contare che possono confrontare i propri display 1 e 2 tra di loro, visivamente). Questo semplice dato di fatto, anzi di design, mi lascia capire che la funzione di monitoring, di verifica, non sia in linea di principio implementata in software, ma lasciata ai piloti. Il confronto numerico tra i dati sta ad essi. Tant’è vero che, correggetemi se sbaglio, al decollo, come in ogni fase delicata di pilotaggio manuale, i piloti debbano monitorare le velocità e accorgersi di eventuali discrepanze tra i due canali.

Il paragrafo 1.16.8.2 del Report chiaramente spiega che, come da FCOM (riporta anche la pagina, 3.02.34), la procedura “Unreliable Speed” richiede che i piloti identifichino la perdita di congruenza tra le indicazioni IAS (“the crew identifies the loss of consistency in indicated airspeeds”). Ora, questa frase sembrerebbe confermare che la funzione di monitoring delle velocità sia effettivamente lasciata ai piloti. Tant’è vero che, al secondo punto, il Report spiega che il manuale impone la procedura dei Memory Items nel caso che la sicurezza del volo sia inficiata dalle anomalie rilevate. Quindi, correttamente, i piloti devono decidere se e quanto la sicurezza del volo sia degradata ad un livello tale da richiedere l’esecuzione della procedura. Ma, ancora una volta, vorrei far notare che la decisione di eseguire oppure no la procedura viene dopo, e di conseguenza, il rilevamento di anomalie (quelle corrette). E tale monitoraggio di anomalie viene lasciato ai piloti.

Non vorrei entrare ora nel merito della bontà o meno di tale filosofia di concetto rispetto ad un altro (per esempio, nel caso che conosco meglio, cioè nei velivoli militari, il monitoring delle velocità viene affidato ai computer FCC, in quanto il sistema Air Data fa parte del FCS, e non dell’avionica). Non vorrei nemmeno entrare nel merito della bontà o meno del training effettuato dai piloti Air France (o altri) a riguardo della procedura stessa. Non è molto rilevante ai miei fini. Ammesso che i piloti fossero a conoscenza, come credo, della procedura, e ammesso che questa filosofia non sia peggiore di altri, la mia conclusione principale rimane quella che dicevo all’inizio, e cioè che la ricostruzione mentale di causa-effetto dello scenario sia stata drammaticamente fuorviata dal fatto che i piloti siano stati avvisati prima dell’effetto (AP disengage), e poi della causa (come warning richiesta di Speed Check).

A maggior ragione, risultava oltremodo difficile, se non impossibile direi, collegare un altro effetto -il warning di stallo- con la causa effettiva, che era a sua volta un effetto della causa prima. Voglio dire, il warning di stallo era stato attivato a seguito della prolungata richiesta a cabrare del pilota PF, ma tale prolungata richiesta era stata (i motivi precisi non si conoscono, ma hanno importanza relativa secondo me) fondamentalmente un effetto della causa di sconnessione AP, e quindi mentalmente vista come tale: AP disengage -> Stall warning.

Non credo di sbagliare di molto, dicendo che un requisito essenziale per la corretta applicazione di una procedura di emergenza sia una corretta comprensione del problema, seguita da una corretta ricostruzione dello scenario a partire da causa ed effetto/i.

Dopo tutta questa lunga disquisizione, il cui unico scopo è quello di raccogliere commenti, vorrei entrare in dettaglio e spiegare perchè, secondo me, la causa principale sia il problema di fondo dell’architettura del sistema (lo sospettavo già prima del Report finale), e non tanto la comprensibile confusione prodotta nelle menti dei piloti. Vorrei però utilizzare un post separato.

[sigmet]

Mi trovo daccordo con Alien e vorrei sottolineare che il quadro situazionale fosse gia' ampliamente compromesso. L'avviso dello stall warning in quelle condizioni puo' risultare un ulteriore fattore di disorientamento. A tal proposito vorrei ricordare l'incidente del 757 della Birgenair dove a causa di un pitot ostruito il Cpt non ha mai realizzato quale fosse la condizione reale nonostante le indicazioni di velocita' del CM2 fossero corrette (come anche quelle del sistema Stby). Nel caso del 330 AF la perdita della SA innescata dalla prima perdita della IAS del CM1 e' stata aggravata dalle successive indicazioni multiple di avaria ed ha portato l'equipaggio a canalizzare la sua attenzione sulla perdita di quota piuttosto che su un assetto che loro consideravano ancora volabile.La stessa situazione di unrecognized stall condition e' comune ad almeno altri tre incidenti dell'aviazione commerciale.(Dash 8 - B727- Md80)
Se lo vogliamo inquadrare da un punto di vista HFACS vediamo come una molteplicita' di elementi e di concause all'interno dell'organizzazione abbiano portato all'incidente.
A livello di Unsafe acts abbiamo l'errore a livelllo decisionale dovuto alla incorretta risposta alla situazione iniziale, e l'errore percettivo dovuto ai problemi di strumentazione gia' esposti.Sempre in questa area notiamo a livello di skill l'uso improprio dei comandi di volo, l'omissione della ck list relativa alla condizione "no reliable airspeed", e la poor technique relativa all' upset recovery.
A livello delle precondition for unsafe acts tra i fattori ambientali e' presente quello dovuto alle condizioni meteo particolarmente critiche e a quello tecnologico che ha determinato la confusione situazionale. Inoltre uno scarso CRM ha indebolito la leadership .
A livello di Unsafe supervision troviamo carenze gravi tra cui quella di non aver individuato e corretto nella maniera opportuna ed immediata un problema che gia' era noto oltre ad un addestramento inadeguato per quella situazione.
Infine tra le carenze dell'organizzazione possiamo individuare carenze nel design dell'avionica, limiti nei programmi di addestramento, difetti nei componenti impiegati e un carente risk assesment relativo al problema dei pitot.
Voglio pero' condividere i risultati di uno studio della nasa dove piloti "tradizionali" e piloti "EFIS" (passatemi il termine) sono stati messi a confronto su una situazione critica. La tendenza dei primi e' quella di volare l'aereo " raw data" mentre per i secondi e' predominante la tendenza ad affidarsi al flight director salvo disorientarsi in caso di degrado di quest'ultimo.
Le prestazioni a livello di skill manuali dei piloti EFIS e' stata sempre sotto la sufficienza.

[JT8D]

La perdita delle velocità, in sè, non dovrebbe essere critica, ma si presuppone che i piloti eseguano la procedura prevista, e, conseguentemente, per eseguire tale procedura comprendano esattamente l’accaduto. Ogni procedura di emergenza dovrebbe essere inizializzata da una corretta valutazione dello scenario, e ogni corretta valutazione dovrebbe essere possibile a seguito di corrette indicazioni. Cosa che non è avvenuta, purtroppo, in quanto non c’è stato alcun display preciso al riguardo (salvo PITOT). La loro attenzione quindi è stata inizializzata dal warning AP, effetto e non causa del problema, e non sono riusciti in alcun modo a farsi una corretta immagine mentale dello scenario che si presentava loro.

Mi sembra poi che il PF abbia reagito correttamente al warning AP, in quanto, a seguito di perdita di quota, riprendendo il controllo manuale, ha dovuto riportare il velivolo in quota tirando lo stick a cabrare. La perseveranza successiva nel tirare a cabrare sembra essere un errore grave; potrebbero esserci diversi motivi tali per cui il PF abbia agito in tal modo. Sta di fatto che, direi, all’origine di questo comportamento potrebbe esserci la stessa motivazione precedente, e cioè una pressochè totale incomprensione dello scenario in quanto l’effetto “mascherava” la comprensione della causa......


.....Non credo di sbagliare di molto, dicendo che un requisito essenziale per la corretta applicazione di una procedura di emergenza sia una corretta comprensione del problema, seguita da una corretta ricostruzione dello scenario a partire da causa ed effetto/i.

Concordo con quanto scritto da alien: in particolare sono da sottolineare le frasi da me quotate qui sopra, che dal mio punto di vista, racchiudono la questione fondamentale da studiare e analizzare.

Paolo

[Alien]

Vorrei ora focalizzare l’attenzione sui dettagli di quello che considero la causa primaria dell’incidente: la mancata descrizione/comprensione del problema. Il paragrafo 1.16.3.1 riporta la successione temporale degli eventi per quanto riguarda le IAS (la figura 67 del paragrafo 1.16.5.1 contiene le altre informazioni, tutte essenziali per il mio commento). Tutto è sostanzialmente iniziato con questi quattro eventi, due dei quali a livello di sistema, e due a livello sistema+display:

2h10m03.5 - 2h10m05

Perdita di ADR 2 nel sistema.

2h10m04 - 2h10m05

Perdita di ADR 1 nel sistema.

2h10m05

Warning ECAM: AP OFF

2h10m10

Warning ECAM: Alternate Law

Secondo me, in questo preciso istante, AF447 era stato condannato. Per il preciso motivo che esiste una discrepanza fatale tra la situazione effettiva delle velocità e quella indicata nel cockpit: due su tre sono perse, e sono proprio quelle dei display, cioè ADR 1 e 2. Ai piloti vengono indicate due velocità inaffidabili, ma non viene loro indicato che lo sono, nè tanto meno quali. Tant’è vero che, sempre da fig. 67, il PF non commuta il suo PFD da ADR 1 a ADR 3 fino a 2h10m40, cioè ben 30 secondi dopo il problema. Tra l’altro, commutare da ADR 2 a ADR 3 non migliora la situazione (anzi, peggiora la comprensione di essa) in quanto ADR 3 era inaffidabile, ed è stato confrontato con ADR 1 che nel frattempo era tornata valida (traccia verde ADR 1 in figura 67).

Il sistema però, dal proprio punto di vista, si è correttamente riconfigurato a seguito di perdita di integrità di certi parametri. Con la perdita di affidabilità dei dati aria (due persi su tre, da triplex la ridondanza diventa simplex), l’autopilota e le funzioni di protezione si devono disingaggiare. Di qui le due corrette indicazioni ECAM e Alternate Law. E queste indicazioni sono quindi state considerate come causa e non effetto nella errata fatale valutazione dello scenario.

La filosofia del sistema prevede dunque che siano i piloti a verificare l’integrità delle velocità. ma mi chiedo come facciano ad eseguire tale verifica se non li si avvisa di doverla eseguire. Al para. 1.16.3.1, si dice chiaramente che la perdita di ADR 1 e 2 è stata registrata (quindi rilevata, ovviamente) dal computer FMGEC2, ma a tale evento non era associata alcuna azione (oscuramento, o flag) sul display PFD destro. Questo significa che il sistema è stato sì in grado di riconoscere i canali guasti, come ADR 1 e 2, ma non di dirlo tramite avionica.
Nei sistemi ridondati, la bestia nera sono i guasti simultanei, o di “common mode”. Un guasto simultaneo nei diversi canali impedisce al sistema di riconoscere i canali guasti da quelli buoni. In questo caso, però, dal fatto che ci siano state sconnessioni AP e Full Law, potrei dedurre che i guasti su ADR 1 e 2 siano stati sequenziali e non simultanei. Il sistema è stato in grado di riconoscere prima un canale guasto (diciamo ADR 1, confrontandolo con 2 contro 1), escluderlo, e poi riconoscere che anche ADR 2 era guasto. In linea di principio, confrontando due soli canali (nel nostro caso ADR 2 e 3), non si sarebbe in grado di distinguere quello buono da quello guasto, ma data la particolare anomalia, un crollo del valore di velocità, presumo che il computer sia stato in grado di dire che il canale buono era quello dove non c’era una variazione brusca di velocità, che sarebbe impossibile fisicamente.

Ad ogni modo, a parte questi dettagli di implementazione, il mio punto è che il sistema era stato in grado di rilevare anomalie dei dati aria, prendere le corrette contromisure di disingaggio di funzioni “clienti” di tali parametri anomali, ma non in grado di avvisare i piloti. Eppure, il sistema è in grado di generare il warning di cui parlo: la figura 67 riporta (i tratti neri) la tempistica dei flag SPD sul display PFD, ma, purtroppo, si vede come questi siano arrivati molto, troppo tardi (sul PFD sx a 2h11m40, sul PFD dx a 2h11m45). Per quanto mi sembra di capire, il Report non spiega in dettaglio (forse Airbus non lo dice) il design del software relativo alla generazione di questi flag SPD, e dell’indicazione relativa ECAM Check Speed. L’indicazione ECAM arriva addirittura a 2h12m44 (figura 71 del Report), cioè tardissimo, ancora più tardi del già tardivo flag sui PFD.

Cioè, ricapitolando, al tempo zero (circa 2h10m04) abbiamo l’evento scatenante, al tempo t = +1 secondo avvisiamo i piloti di intervenire (con un ECAM rosso, piuttosto veloce, 1 secondo o meno), mentre l’ECAM fondamentale che spiega la causa del problema (tra l’altro blu, nemmeno ambra e non tantomeno rosso) glielo diamo a t = +2minuti 40 secondi. Mi chiedo come sarebbe stato possibile per chiunque capire che la causa dell’ECAM rosso a t = +1s era un ECAM blu arrivato DOPO, a t = +2m40s...

Non conosco l’avionica e l’ergonomia dell’Airbus, ma forse, in generale, i piloti andrebbero avvisati in qualche modo sulle cause di un warning ECAM rosso. Ipotizzo che, dopo che il PF intervenga con la corretta procedura dovuta al warning rosso AP, il PNF debba essere in qualche modo in grado di “interrogare” il warning stesso e sapere le cause di esso (in questo caso, speed o Air data anomalies). L’informazione sarebbe disponibile nei computer. Il PF prende la corrective action richiesta dal warning rosso, mentre con più calma, il PNF indaga e ricostruisce lo scenario.

Alternativamente, sempre secondo la mia opinione, il check sulle velocità andrebbe lasciato al computer invece che ai piloti. I dati aria sul display potrebbero essere quelli validi, “votati” dal computer, e non quelli direttamente in arrivo dalle sonde. I piloti, guardando i display, vedrebbero informazioni con il massimo livello di integrità, e non sarebbero indotti ad errore riferendosi, nell’esecuzione della procedura, a dati dubbi (sarebbe come nei velivoli militari). Invece, qui, abbiamo una filosofia “via di mezzo”, che non riesco a capire. Se volessero, potrebbero benissimo commutare sui valori “grezzi” delle sonde individuali, ma sapendo che, se non lo volessero fare, il display riporta comunque quanto di meglio è disponibile. E che, in mancanza di integrità sufficiente, il display si annerisce; oppure un flag, anche temporaneo, oscura i dati incerti. Io credo che sarebbe meno peggio non fornire dati incerti, piuttosto che fornirli comunque, certi o incerti.

Non voglio nemmeno entrare nel merito dell’Airmanship tra piloti di esperienze differenti (più tradizionali, o più strumentali EFIS). Sta di fatto che, se si accetta che un pilota si debba basare sull’EFIS, allora bisogna che egli abbia le informazioni corrette. Secondo me, non esiste nulla di sbagliato a delegare certe funzioni ai computer. I computer non hanno, e non devono avere, capacità decisionali: i computer devono vigilare e intervenire a livello sistema per rilevare e isolare guasti (oltre al compito, non in discussione qui, di proteggere l’aeroplano nel suo inviluppo). Infatti, sono molto più veloci degli umani nelle azioni correttive. Ma, essendo lasciata la responsabilità decisionale ai piloti, allora il problema qui diventa puramente ergonomico: bisogna presentare le informazioni in modo corretto, e disambiguo, cioè in modo tale da far sì che il pilota possa costruirsi l’immagine mentale corretta dello scenario. Io posso aver il diritto di criticare un pilota che non esegua una procedura, ma non nel caso in cui non lo metto in grado di capire che tale procedura deve essere eseguita.

[sigmet]

Secondo me invece il problema e' di carattere cognitivo ma molto piu' complesso di quanto si pensi.
L'avaria di due ADR o di due CADC e' un ipotesi tutt'altro che remota (mi e' capitata personalmente in IMC e mi e' andata bene ) tanto che viene espressamente prevista anche dal costruttore che inserisce tra le procedure di emergenza una "Unreliable airspeed indication" (o damaged radome ,etc) dove addirittura e' contemplata l'avaria di tutti e tre i sistemi. La differenza sostanziale tra un EFIS e uno strumento analogico e' che in caso di avaria sono uguali ! L'unica cosa che cambia infatti e' che la bandierina sull'EFIS viene disegnata da un pennello elettronico mentre sullo strumento analogico e' fatta di lamierino. Entrambe possono comparire subito o a distanza di secondi o minuti (come nel mio caso) oppure non comparire affatto.
Il problema e' che probabilmente succede qualcosa dopo, ovvero il processo di decision making subisce un disturbo che altera la percezione della situazione e il feedback dell'azione correttiva come nel caso del A330 dove non e' mai stato chiaro se l'aereo scendesse volando oppure stallando. Quello che puo' aver veramente fatto perdere la SA secondo me e' stato proprio l'avviso di stallo che e' intervenuto quando ancora loro leggevano (almeno pensavano di leggere) una velocita' apparentemente volabile il tutto unito ad una miriade di altri avvisi piu' o meno utili e coerenti in quel momento.Il flight director ha fatto il resto. E non e' la prima volta che succede. Basta andarsi a vedere sul tubo il filmato di National Geografic sull'incidente del B 757 della Birgenair. Del tutto identico come dinamica anche se quella volta e' bastata l'avaria di un solo impianto per fare inabissare l'aereo turco.
Ma a questo punto c'e' da chiedersi se questo avviene per complacency verso certe strumentazioni o se e' un problema di addestramento (e lo stallo per una ventina di anni e' stato trascurato un po da tutti). E' una questione di limiti umani? L'inviluppo di volo di certe macchine viene espanso artificilamente con l'FCS oltre i limiti cognitivi dell'uomo indebolendo quelle che oggi chiamiamo "ecological safety capacities" .O forse il design di questi strumenti va semplicemete rivisto ( e lo si sta gia' facendo) rendendo il pilota piu' consapevole della situazione reale. C'e' da lavorarci sopra e non bisogna fermarsi.
Tra qualche anno avremo sugli aerei computer piu' performanti che saranno in grado di parlare con i piloti in maniera multimodale. Vi saranno per esempio avvisi tattili- visivi e l'avaria verra' presentata con il criterio della risk matrix ovvero la probabilita' che questa accada per la conseguenza che questa porta in termini di gravita'.In situazioni di emergenza cambieranno morfologia e si avranno solo le indicazioni indispensabili al volo con particolare riguardo all'energia e non piu' alla velocita' e la comunicazione satellitare permettera' di avere sempre in tempo reale il monitoraggio dello stato del volo.

[CP-861]

Leggendo il report, in modo abbastanza veloce, ho notato il grande lasso di tempo trascorso tra l'ultimo contatto con ATLANTICO...
Ora, capisco che le onde HF siano meno affidabili rispetto alle VHF, ma com'è possibile che siano passate 6 ore tra l'ultimo contatto e l'inizio dell' ALERFA?
Come funzionano le OIR? (si possono chiamare così?) cosa prevedono le LoA tra Brasile e Ghana?
Sono abbastanza basito...

[sardinian aviator]

http://www.corriere.it/esteri/13_marzo_ ... 1d4a.shtml

Un'altra tessera.
Ma non sapevo che fosse stata avviata un'indagine giudiziaria: un altro caso di criminalizzazione di un incidente? Ammesso che sia vero, perché l'inchiesta tecnica non ne fa menzione?

[Hartsfield-Jackson]

Possibile che dalla frase "ho solo un'ora di sonno"(del capitano) il corriere abbia stabilito che tutto l'equipaggio aveva trascorso una notte brava? E quella frase "il comandante era così stanco che ha dovuto lasciare i comandi agli altri 2 piloti" , come se non esistessero i turni durante un volo di lungo raggio...

E' davvero in atto una procedura penale per omicidio colposo nei confronti dell'Air France?!

[sigmet]

Prima ci dicono che si possono accorciare i tempi di riposo poi ti si inchiappettano perche' non hai dormito...
Magari adesso proibiranno pure il sesso prima del volo, tanto ormai il lavoro del pilota di linea e' riservato ai masochisti... e c'e' pure chi paga per farlo..

[Hartsfield-Jackson]

Prima ci dicono che si possono accorciare i tempi di riposo poi ti si inchiappettano perche' non hai dormito...
Magari adesso proibiranno pure il sesso prima del volo, tanto ormai il lavoro del pilota di linea e' riservato ai masochisti... e c'e' pure chi paga per farlo..

Se non dormi producendo denaro e arricchendo la compagnia è tutto ok..

[Bryan]

Non so se riapro il thread corretto (spostate se necessario), volevo segnalare che stasera su National Geographic Channel (403 di sky) danno "la vera storia dell' Air France 447" , credo sia la prima volta che bene proposta la ricostruzione dell' evento. Attendiamo curiosi ...

[Valerio Ricciardi]

Voglio pero' condividere i risultati di uno studio della nasa dove piloti "tradizionali" e piloti "EFIS" (passatemi il termine) sono stati messi a confronto su una situazione critica. La tendenza dei primi e' quella di volare l'aereo " raw data" mentre per i secondi e' predominante la tendenza ad affidarsi al flight director salvo disorientarsi in caso di degrado di quest'ultimo.
Le prestazioni a livello di skill manuali dei piloti EFIS e' stata sempre sotto la sufficienza.

Se ti dicessi che la cosa non è che mi sorprenda poi troppo?