Aggiornamento Airbus A320, a che punto siamo? Intervento quasi completato sulla flotta globale

Beh, buono a sapersi. Sarebbe carino capire come abbiano fatto, anche se presumo che si siano "limitati" ad aggiungere ridondanza e checkum sui dati del computer.

E, per la cronaca, i 737Max non erano precipitati a causa di un malfunzionamento del software, che ha funzionato esattamente come previsto, ma a causa alla parte addestrativa di Boeing, che non ha fornito le informazioni necessarie ai piloti per l'utilizzo del nuovo sistema MCAS e neanche eventuali procedure di emergenza, dato che differivano dalle procedure el 737 standard.

In parole povere, il 737 Max e' un modello modificato del 737, con motori piu' piccoli ed efficienti dal punto di vista del consumo di carburante. Pero' non avevano le stesse caratteristiche dei motori originali, quindi e' stato necessario modificare il software per la gestione dello stallo.

In pratica, quando il 737Max decollava, cabrava ed acquisiva velocita'. Se per qualche motivo la velocita' risultava troppo bassa, per cercare di aumentarla i software abbassava automaticamente il muso. Questa cosa non era stata segnalata ai piloti, il quale si trovavano un aereo che puntava verso il basso, e quindi tentavano di cabrare, controbilanciando la manovra automatica. Ma questo riduce ancora la velocita'. Nel 737 originale non c'era bisogno di farlo perche' la maggior potenza dei motori permetteva di acquistare velocita' in maniera piu' efficiente. Magari dovevano avere un angolo di attacco diverso da quello del 737 originale in fase di decollo, questo non lo so, ma lo posso ipotizzare dati i motori meno potenti. Quindi il software funzionava perfettamente, ma c'erano due problemi: quello sicuro sul mancato addestramento al nuovo strumento, per cui l'aereo si comportava diversamente a quanto i piloti si aspettavano, e quello emerso da alcune indagini (che non ho mai approfondito se fossero vere o meno), che davano la colpa anche all'aereo, non tanto al software, quanto ad alcuni sensori che in certe condizioni potevano dare input errati al software. Anche se alcune indagini avevano notificato la cosa, non sono sicuro che un eventuale malfunzionamento dei sensori sia effettivamente un'altra causa degli incidenti.

Tutto cio' e' stato dovuto ad uno sviluppo accelerato del programma, e quindi senza seguire tutte le normali procedure di progettazione, sviluppo, addestramento e documentazione, perche' da quel che ricordo Airbus stava guadagnando quote di mercato per aver gia' in servizio un aereo con simili caratteristiche. Ricordo che ai tempi delle indagini si diceva che girassero mail di ingegneri che si lamentavano molto della gestione del progetto da parte di manager. Quindi si, la colpa era di Boeing, ma non per il software in se'.

piccola correzione il max 8 aveva motori più grossi non più piccoli (più grossi > % bypass > efficenza) ma questo sbilanciava l'aereo in quanto progettato per motori più piccoli da li la necessità di sviluppare l'mcas

la parte criminale di questo piano è stata
1) non ridondare le pitot per ridurre i costi
2) far passare la modifica come un intervento minore che non richiedeva riaddestramento dei piloti (per ridurre i costi)

è stata la voglia di lucrare il più possibile di boeing a far schiantare quegli aerei, modifica a budget minimo per non perdere concorrenzialità con i più moderni airbus

in che modo un software può fare qualcosa per la radiazione solare?

controlli e ridondanza, non annulla l'effetto della radiazione solare ma compensa gli effetti (aka scarta il dato alterato)

Guarda caso sono appena sceso da un A320 e fra un paio d'ore ne devo prendere un altro. Spero non sia uno di quei 100...

Due tecniche "semplici"

[LIST]
[*]Invece di avere una sola istanza dell'algoritmo di calcolo, puoi avere piu' istanze identiche su "thread" separati (anche se i thread non sono molto ben visti in aviazione ma usiamoli per semplificare il concetto) che ricevono gli stessi input. Questi algoritmi dagli stessi input dovranno per forza dare gli stessi output. Dato che anche se identici sono istanze diverse, ogni thread lavorera' sulla sua porzione di memoria, quindi un raggio cosmico che altera un bit, lo altera solo per quel thread. Quindi se hai ad esempio tre thread che fanno i calcoli, e due danno risultati identici mentre uno da un risultato diverso perche' una variabile in memoria e' stata alterata dal raggio cosmico, quell'output verra' scartato e non preso in considerazione. Ovviamente il problema si presenta anche se non si modifica una variabile ma un'istruzione del programma (anche le istruzioni stanno in memoria), ma il concetto e' lo stesso
[*]Si esegue un checksum per assicurarsi che i dati non siano corrotti: ad esempio dopo aver caricato il programma in memoria puoi fare il checksum del suo dump, e verificarlo periodicamente, per assicurarti che le istruzioni non siano cambiate a causa di un raggio cosmico, ed in caso ricarichi il programma (o la porzione modificata). Fai anche il checksum delle variabili utilizzate, scrivendo il checksum di ogni variabile quando la modifichi, e leggendolo subito prima di utilizzare quella variabile per assicurarti che nel frattempo non sia stata modificata in maniera non autorizzata. In caso rifai i calcoli o "scarti" il frame, a seconda della logica del programma.
[/LIST]

Diciamo che la prima soluzione e' piu' fattibile, perche' richiede meno modifiche al codice (se fatto come si deve). Ovviamente sono esempi basilari, sono sicuro che loro avranno fior fiore di ingegneri che implementeranno lo stato dell'arte a riguardo, era solo per farti due esempi facili per capire.

Non credo, quelli non aggiornati sono ancora a terra mi sa.

...dai notizie una volta atterrato !

se non raggiunge la velocità smodata, non corri alcun pericolo

Pensate un mondo tutto controllato dalla IA e un periodo lungo di tempeste solari.
Cosa intendo:ospedali controllati e gestiti dalla IA,sistema elettrico mondiale, sistema idrico mondiale,fabbriche si produzione, agricoltura......