In linea di principio, non ci sarebbe molta differenza, ma ho un paio di considerazioni che secondo me fanno la differenza.Zapotec ha scritto: Perchè maggiore ? Non credo che cambi come concetto, dipende solo dove questa validazione viene effettuata. Farla in uscita dalle ADIRU o in ingresso ai PRIM non ne vedo la differenza (nei confronti della validazione, ripeto).
Se la fai in uscita delle ADIRU, il tuo requisito di validazione sarebbe solamente quello di coprire i modi di guasto peculiari del sistema Dati Aria/Inerziale (e, tra l'altro, al cockpit invieresti dati corretti evitando quegli sballonzolamenti a uno dei piloti). In ingresso ai PRIM avresti da coprire solamente i guasti di trasmissione intersistema (ADIRU->FCS). Avresti due validazioni separate, disegnate ad hoc per modi di guasto diversi.
Se non la fai in uscita alle ADIRU, allora devi disegnare la validazione nei PRIM dovendo tenere conto di uno spettro più ampio di casistiche da coprire con lo stesso software, che risulta più incasinato (o dovrebbe esserlo) del necessario.
Senza contare che, senza validazione in uscita ADIRU, hai contravvenuto al principio ingegneristico di evitare per quanto possibile la "failure propagation". La failure nel sistema ADIR mi ha provocato anche dei warning FCS che in realtà non dovrebbero esserci. Non c'è motivo di accendere un warning FCS se il guasto risiede nell'Air Data. Gli confondi le idee, in un momento di tensione. Gli fai credere che il guasto sia nel FCS mentre risiede nell'ADIR.
Qui si vede che gioco nella squadra FCS, e non in quella ADIR
Comunque, i dati in uscita dall'ADIRU avrebbero integrità migliore, questo è matematico. E, come detto, le indicazioni nel cockpit ne risentirebbero positivamente. Non sono un pilota, ma scommetto che quegli sballonzolamenti dei display danno oltremodo fastidio.
Insomma, fornire dati aria corretti è pur sempre responsabilità del sistema ADIR, no? Aggiungerei ancora che nel SSJ russo che sto seguendo questo discorso risulta particolarmente importante in quanto i due sistemi sono responsabilità di fornitori diversi (rispettivamente Thales e Liebherr). E, quindi, sorge il problema di integrare i due sistemi.
Certamente, ma sono sempre angoli di flusso locali. I sensori misurano angoli di flusso locali, non l'Alfa del velivolo. Sta agli ADIRU calcolare l'Alfa velivolo in funzione dei vari angoli di flusso locali in ogni sensore. Poi, l'Alfa velivolo può essere inviato al FCS.Zapotec ha scritto: L'AOA credo che generi valori diversi non tanto per calibrazione, ma perchè in funzione degli assetti di volo possono realmente assumere posizioni diverse.
Questo intendo con "calibrazione".
Concordo.Zapotec ha scritto: Anche io ti do ragione su tutto quello che hai scritto... però filtro per filtro... io mi chiedo, se un valore di un sensore AOA (che poi non capisco... anche lì c'è un sistema ridondante.. due canali dello stesso sensore, un pò come il pedale dell'acceleratore delle auto moderne insomma.. due potenziometri "sfasati" tra le cui misure DEVE esistere una correlazione altrimenti il dato viene già scartato), se il campionamento precedente da 0 e il successivo -50, ma perchè mai devo far passare il -50 ? non credo che il ritardo di qualche mS (se cioè scarto qualche dato per questa verifica) possa influenzare in qualche modo i sistemi successivi. Comunque anche questo è un filtro... la gabola è in agguato
Indipendentemente dalla ridondanza, che io abbia tre valori o anche due o uno solo, da qualche parte dovrebbe esserci un "rate limiter" che mi trasforma uno spike su un dato aria (fisicamente impossibile) in una rampa. Il report ATSB parla di rate limiters piazzati nel FCS per filtrare le variazioni di Alfa dovute a turbolenza, ma qui stiamo parlando di una cosa diversa.
E comunque, di nuovo, un rate limiter che filtri gli spike su Alfa o sui dati aria dovrebbe essere piazzato negli ADIRU. Esiste qualcosa del genere?
Ciao,