Domanda:
Cosa impedisce a un jet commerciale di "resettare" elettronicamente come fa a volte un computer?
Umbrella_Programmer
2020-01-03 08:31:34 UTC
view on stackexchange narkive permalink

Ho avuto paura di volare negli ultimi anni e uno dei modi in cui si manifesta questa fobia irrazionale è la preoccupazione per il ciclo di potenza dell'aereo a mezz'aria: motori che si spengono, apparecchiature di controllo che si spengono, ecc.

Di tanto in tanto un computer o uno smartphone si arresta in modo anomalo e si riavvia o, nel peggiore dei casi, l'alimentazione o la batteria si guastano e il dispositivo non si riaccende.

Succede mai con jet commerciali? Mi aspetto che siano cablati elettronicamente in un modo fondamentalmente diverso dai computer, in modo che un guasto del sistema non influisca sul resto, ma non ho mai chiesto a un pilota.

Correlati: [Come funzionano le ridondanze nei sistemi dei velivoli?] (Https://aviation.stackexchange.com/q/21744/3573)
Correlati: [Perché i computer di volo critici sono ridondanti?] (Https://aviation.stackexchange.com/q/13447/3573)
Bene, ci sono ancora esempi di necessità di "riavviare un aereo";) A350: https://www.theregister.co.uk/2019/07/25/a350_power_cycle_software_bug_149_hours/ e 787: https://www.theregister.co .uk / 2015/05/01 / 787_software_bug_can_shut_down_planes_generators /
I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/102895/discussion-on-question-by-umbrella-programmer-what-prevents-a-commercial-jet-fro).
Sette risposte:
HiddenWindshield
2020-01-03 09:44:21 UTC
view on stackexchange narkive permalink

Sono un programmatore e un pilota privato, quindi forse posso aiutare a dissipare alcune di queste paure.

  1. I computer che fanno funzionare un aereo commerciale sono concettualmente molto più semplici di quello che gestisce il tuo telefono. Ciò significa molte meno possibilità che si verifichi un bug nel software, solo perché il programmatore deve tenere traccia di meno.

  2. Se il telefono si riavvia, non mette in pericolo la vita di nessuno . Quindi, i test e il Q.A. perché un tale dispositivo è fondamentalmente tutto ciò che l'azienda vuole fare. D'altra parte, i computer nel settore dell'aviazione vengono testati molto più a fondo prima di poter essere certificati per volare.

  3. Analogamente al punto 1, i computer di un aereo hanno ciascuno un solo lavoro . Molti degli arresti anomali su un tipico PC o smartphone provengono da app diverse che si calpestano a vicenda. (Il sistema operativo dovrebbe tenere separate ogni app in modo che non possano farlo, ma il punto 2 si applica anche ai sistemi operativi.)

  4. L'aereo non è uno singolo computer, come il tuo telefono. Sì, il tuo telefono probabilmente ha più processori, ciascuno con più core, ma sono strettamente accoppiati per formare un computer. I computer di un aereo sono collegati in rete, ma sono computer separati. Se il tuo telefono si blocca, anche se il ragazzo seduto accanto a te è sulla stessa rete, non lo influenza, vero? Allo stesso modo, se il FADEC per un motore si guasta (un evento estremamente raro, perché i FADEC sono concettualmente tra i computer più semplici), tutto ciò che accadrà è che un motore si spegnerà, senza alcun effetto sul resto dell'aereo.

  5. D'altra parte, i computer veramente importanti (come i controller fly-by-wire) hanno ridondanze multiple. Quindi, se uno fallisce, il resto di loro può riprendere il gioco. Anche il pilota non se ne accorgerebbe tranne che per la spia che si accenderebbe nella cabina di pilotaggio.

Se vuoi vedere cosa succede effettivamente quando le cose non funzionano su un aereo, prendi uno sguardo ai seguenti video:

Il pilota ha pilotato l'aereo a mano mentre ha spento e riavviato il avionica. Il volo è quindi proseguito normalmente.

Il pilota in realtà lasciò che l'autopilota lo avesse per alcuni secondi, solo per curiosità su dove li avrebbe portati. Ma una volta che ha iniziato ad effettuare operazioni bancarie più del dovuto, ha disattivato il pilota automatico e ha assunto il controllo manuale senza problemi.

Il motore è rimasto in funzione nonostante la perdita di tutta la potenza elettrica dell'intero aereo. È atterrato sano e salvo.

Modifica: solo due ore fa mentre scrivo questo, un altro video di un guasto in volo è apparso nel mio feed di YouTube:

È passato al suo generatore di backup e, a parte un fastidioso piagnucolio le cuffie, non ha avuto altri problemi con il volo.

Qualche motivo per cui hai incluso spoiler nella tua risposta?
A me, per esempio, piace la suspense di non sapere come sarebbe andata a finire ciascuna di quelle cose!
@Valay_17 Solo nel caso volessero guardare i video stessi senza sapere cosa succede.
@HiddenWindshield Ohh, non ci avevo pensato ... :)
Se aiuta, OP, le infrastrutture nazionali come le reti di telecomunicazioni utilizzano anche questo concetto di ridondanza, naturalmente. Diamine, Stack Overflow utilizza il concetto di ridondanza: può eseguire il failover in modalità di sola lettura in caso di problema. E quelle non sono nemmeno applicazioni critiche per la sicurezza! Il confronto con il tuo PC di casa è decisamente fuori base.
Credo che i punti 2 e 4 non siano validi. 2: I programmi non sono in grado di "calpestarsi l'un l'altro", anche su x86 semplici sono fortemente separati dalla modalità protetta, e avresti bisogno di un exploit ring0 per aggirare questo. Il kernel per Windows e Linux è probabilmente testato almeno quanto il kernel utilizzato nell'aviazione. 4: Un tipico PC è anche un insieme di computer "collegati in rete", ben oltre il tuo esempio di core multipli, ci sono controller per tutto, molti con capacità di bus mastering. Inoltre, i sistemi avionici hanno requisiti rigorosi in tempo reale di cui un tipico PC non soffre.
Non solo i computer fly-by-wire sono ridondanti, sono costruiti utilizzando diverse architetture e programmati da diversi team per ridurre al minimo la possibilità che un problema colpisca tutti i computer contemporaneamente. L'A320, ad esempio, ha due computer FBW Intel e due computer FBW Motorola.
@AlphaCentauri - qui sulla Terra non abbiamo bisogno di entrare in qualche altro spazio di elaborazione per "calpestarci l'un l'altro" - chiedi ad un'altra app di aprire un file con dati / nome file errati o avvia il browser sul sito con un exploit 0-day o spingere troppo oltre l'API di accessibilità ... Ci sono molti canali di comunicazione IPC ufficiali tra i processi che possono essere utilizzati per causare problemi anche involontariamente. E qui il costo dei test per gli standard dell'aviazione (o di qualsiasi criticità per la vita) è proibitivo per qualsiasi sistema operativo generico da testare per qualificarsi (almeno nella configurazione predefinita del consumatore).
Un motivo aggiuntivo, che può essere applicato solo all'Airbus A380, è che eseguono software parzialmente verificato formalmente, il che significa che è matematicamente dimostrato di essere privo di classi specifiche di bug. Credo che utilizzino un microkernel chiamato [INTEGRITY-178B] (https://www.ghs.com/products/safety_critical/integrity-do-178b.html), un microkernel RTOS conforme a DO-178B.
@AlphaCentauri - Oltre a ciò che ha detto Alexei Levenkov, un PC non è un "insieme di computer in rete". È un computer con più componenti. È vero, a volte è possibile che una scheda di rete, un disco rigido, ecc. Si arresti in modo anomalo senza influire sul resto del computer, ma questo è raro. Se il tuo disco rigido funziona, faresti meglio a sperare che nulla sia stato sostituito dalla RAM in quel momento, perché se lo fosse, il computer visualizzerà la schermata blu (o equivalente) pochi secondi dopo. E se uno dei processori principali si blocca, questo è tutto per l'intero sistema, a prescindere.
Graham
2020-01-03 17:36:31 UTC
view on stackexchange narkive permalink

Prima di iniziare, è importante dire che la tua preoccupazione non è irrazionale. Se ciò accadesse, o se i sistemi di controllo del tuo aereo dovessero funzionare male in modo pericoloso, la tua vita sarebbe davvero in pericolo.

Non sei la prima persona a pensarci, però . Per questo motivo, abbiamo una categoria di sistemi di controllo che descriviamo tecnicamente come relativi alla sicurezza e esiste un'intera branca dell'ingegneria chiamata ingegneria della sicurezza dedicato alla valutazione formale di questi sistemi e al tentativo di prevenire gli incidenti. Ciò include i sistemi di controllo degli aeroplani, ma anche i freni antibloccaggio, i dispositivi medici e qualsiasi altro sistema in cui le persone potrebbero essere danneggiate da un errore. Il grado in cui le persone possono essere danneggiate da ciò viene formalmente valutato come un livello di integrità della sicurezza in base al rischio. Il rischio è una combinazione di quanto è probabile l'evento, quanto negativo sarà il risultato e se le persone coinvolte possono intraprendere un'azione di mitigazione e viene valutato per ogni modo in cui un sistema correlato alla sicurezza può comportarsi male.

Tieni presente che questa valutazione potrebbe non essere così intuitiva come potresti pensare. Una volta ho lavorato a un sistema di erogazione di pula e razzi per aerei militari. Penseresti che il rischio di non far scattare le contromisure e di abbattere il pilota sarebbe il tuo rischio maggiore, ma la valutazione della sicurezza (abbiamo utilizzato un FMEA) ha mostrato che il pilota aveva altre opzioni di mitigazione come un'armatura e un sedile eiettabile, essere abbattuti è un'opportunità che avevano già accettato quando hanno accettato il lavoro, e il rischio che un aereo si schiantasse contro edifici era minuscolo e qualcosa che era già stato accettato istituzionalmente come parte dell'aviazione. Il rischio più grave era in realtà che il sistema si accendesse male mentre un armaiolo lo stava ricaricando, perché poi avrebbero ricevuto una scarica di 36 proiettili di fucile alla testa a distanza ravvicinata. L'armaiolo non ha accettato di correre il rischio e non c'era modo pratico per proteggerli. Di conseguenza, il nostro sistema doveva non attivarsi per impostazione predefinita in caso di discrepanze.

Esistono molti modi per garantire l'affidabilità. La ridondanza è la più diffusa. Puoi avere più sensori in più posizioni, quindi il sistema può sempre capire cosa sta succedendo se uno (o più, forse) dovesse fallire. Di solito ci sono più attuatori per importanti superfici di volo o più superfici di volo in cui l'aereo può mantenere il controllo se uno o più sono danneggiati. Gli aerei passeggeri hanno generalmente anche più motori e più serbatoi di carburante che possono essere isolati l'uno dall'altro in caso di danni. In un certo numero di casi ci possono essere più sistemi di controllo che "votano" sull'azione giusta, quindi un'unità malfunzionante verrà ignorata. Nel caso estremo, ogni sistema di controllo potrebbe anche essere stato programmato da un team software diverso, quindi è estremamente improbabile che un bug nel software di un team sia presente nel software di un altro team. E potrebbero essere presenti altri sistemi di backup come i controlli meccanici.

Un altro buon metodo di attenuazione è la formazione. È perfettamente accettabile che le cose vadano male se le persone che lo gestiscono sono in grado di affrontare quel fallimento e andare avanti. È importante non sottovalutare quanto possono essere brave le persone. Le persone possono e fanno anche causare fallimenti, quindi la formazione può anche essere un caso per dire loro "non farlo". Gli aerei di grandi dimensioni sono relativamente lenti a rispondere ai controlli, quindi è relativamente comune che i piloti possano correggere in modo eccessivo e peggiorare le cose. Per alcuni velivoli commerciali, la risposta standard insegnata ai piloti in caso di instabilità è quella di lasciare andare il bastone e consentire al velivolo di correggersi.

Vale la pena notare che entrambi questi fattori sono il motivo per cui il Boeing-737MAX i disastri sono così gravi, nella misura in cui dovrebbero esserci accuse penali contro le persone individualmente e l'organizzazione collettivamente. Il sistema in questione non utilizzava ingressi ridondanti, anche se disponibili; l'impatto della mancata risposta del sistema non è stato valutato né attenuato; e l'equipaggio non fu addestrato su come affrontare il suo fallimento, né fu nemmeno detto che esistesse. Nel Regno Unito, il crimine di "omicidio colposo aziendale" esiste per perseguire esattamente questo tipo di fallimenti.

L'altro elemento di tutto questo però è la qualità , in modo che tu cerchi di assicurarti che i sistemi non vadano male in primo luogo. L'affidabilità del software dipende quasi interamente dalla quantità di revisioni e test che hanno luogo. Attualmente sto lavorando su software per apparecchiature scientifiche e penso di dedicare circa il 10-20% del mio tempo di sviluppo ai test. PC e telefoni cellulari saranno più o meno gli stessi. Quando ho lavorato su sistemi automobilistici e aerospaziali, questo è stato completamente invertito: abbiamo calcolato di dedicare circa il 5-10% del nostro tempo alla codifica, il 10-20% del nostro tempo alla progettazione e il resto del nostro tempo è andato a rivedere e testare .

Il controllo delle modifiche è anche radicalmente più bloccato. Microsoft potrebbe rilasciare un aggiornamento e quindi controllare i danni nei pochi casi in cui si comporta in modo anomalo e introdurre alcune funzionalità extra allo stesso tempo. Nello sviluppo relativo alla sicurezza, tuttavia, non si modifica una singola riga di codice senza l'approvazione formale che (a) tutti capiscano cosa farà quella modifica, (b) che questa modifica risolva questo bug e non cambia nient'altro e (c) che questa modifica è addirittura necessaria. Molte sessioni di valutazione dei bug ci coinvolgono nell'individuazione di bug in cui alla fine decidiamo che l'impatto del bug è minimo (forse ad esempio 10 ms più tardi accendiamo una spia), ma il rischio di provare a correggere il bug potrebbe essere potenzialmente alto se ci è capitato di sbagliarci, quindi è più sicuro che questo insignificante bug permanga.

Come ci mostra il caso del Boeing-737MAX, tutti questi processi valgono un dannato solo se le persone li seguono. Tuttavia, i processi esistono e sono le migliori pratiche in un settore di decine di migliaia di ingegneri in tutto il mondo che dispone di numerosi standard formali a livello internazionale per stabilirlo. Il mancato rispetto di questi standard è quasi per definizione colpa grave e la maggior parte dei paesi dispone di leggi che consentono il perseguimento di persone e aziende che sono negligenti a questo livello. La maggior parte degli ingegneri vorrebbe comunque fare un buon lavoro; ma le leggi garantiscono che un'organizzazione nel suo insieme rimanga onesta e non tagli gli angoli.

Risposta molto buona. Potresti, se hai tempo, elaborare una o due frasi su come gli stessi * processi * di sviluppo software e hardware per sistemi critici per la sicurezza sono rigorosamente definiti per garantire la sicurezza del prodotto finito, ad es. come in [IEC 61508] (https://en.wikipedia.org/wiki/IEC_61508) e quindi norme specifiche del dominio. Per * avere * effettivamente un processo collaudato, sistematico e documentato che assicuri che i requisiti siano soddisfatti, le specifiche siano seguite, le revisioni e i test siano assicurati ecc. È la differenza più cruciale per lo sviluppo generale del prodotto.
Grazie @Peter-ReinstateMonica. Tutto molto vero, ovviamente. Ero preoccupato di essere andato avanti troppo a lungo, però! :)
Potrebbe valere la pena notare che il processo di test / qualità richiede * indipendenza * dal team che ha effettivamente implementato il codice in molti casi. (Certamente vero per DO-178 e DO-254).
kevin
2020-01-03 09:35:13 UTC
view on stackexchange narkive permalink

Le tue preoccupazioni sono ragionevoli e giustificate. Un arresto o un riavvio a mezz'aria sarebbe catastrofico per un aereo di linea. Ecco perché gli ingegneri hanno progettato i sistemi in modo tale che questo scenario sia praticamente impossibile.

Energia elettrica

Un aereo di linea ha più fonti di energia elettrica. Ogni motore a reazione ha un generatore integrato. Quando la turbina gira, viene generata elettricità. Ogni generatore può essere spento indipendentemente in caso di problemi. La maggior parte degli aerei di linea dispone anche di una unità di alimentazione ausiliaria o APU. L'APU può essere avviata in caso di emergenza per fornire energia elettrica e idraulica di riserva all'aereo, come avviene nel famoso Hudson Riving Landing.

Se tutto fallisce (ad esempio se il aereo esaurisce il carburante), l'energia elettrica limitata può essere fornita dal mulino a vento, utilizzando la Ram Air Turbine (ad es. Boeing 777) o mediante il mulino a vento delle stesse turbine (ad es. Boeing 747), poiché l'aereo lentamente scivola verso un punto di atterraggio.

Poi c'è la batteria, ovviamente, che viene caricata in ogni momento. Può fornire potenza limitata in caso di emergenza.

Computer

Tutti gli aerei di linea sono dotati di più computer di controllo di volo. Le unità sono costruite da diversi produttori, su diverse architetture di CPU e diversi codici sorgente. La possibilità che tutte le unità si guastino contemporaneamente a causa di un bug o un difetto è molto bassa. Nell'improbabile caso in cui una delle unità si guasta, i piloti possono scollegare quell'unità dal resto del sistema.

Ad esempio, l'Airbus A320 ha 2 computer con alettoni elevatori, 3 computer con elevatore spoiler e 2 computer di volo Computer di potenziamento. Ogni unità può essere disabilitata in caso di malfunzionamento.

Leverismo meccanico

Nello straordinario e improbabile evento che l'energia elettrica venga completamente persa, alcuni comandi di volo sono collegati alla cabina di pilotaggio tramite mezzi meccanici e possono essere azionati con la forza umana. Ad esempio, la procedura di emergenza per un guasto completo del computer di volo nell'Airbus A320 è di far atterrare l'aereo usando nient'altro che i colpi del timone, la ruota di trim dell'elevatore e le manette. Questo non è mai successo nella storia.

Potrei anche aggiungere che i voli oceanici lunghi come Londra a New York dovrebbero essere certificati ETOPS (aereo, equipaggio, compagnia aerea, ecc.). Ciò garantisce che ci sia sempre un posto per l'atterraggio di emergenza in qualsiasi punto del volo se qualcosa va ancora storto.
Sascha
2020-01-03 19:46:08 UTC
view on stackexchange narkive permalink

come qualcuno che ha eseguito test software su un sistema non importante (classe D, spiegherà presto) per l'approvazione di un aereo per l'atterraggio su aeroporti civili: In aereo c'è una rigida gerarchia su che tipo di funzioni software significano; sono elencati in DO-178B.

  • Si presume che i sistemi di classe A siano "esenti da guasti"; sono estremamente ben testati. Questi sistemi non sono destinati al riavvio e in genere non si spengono o eseguono altre azioni aggiuntive in caso di condizione di errore. (ad esempio, quando il controller di un motore perde la connessione alla cabina di pilotaggio, rimarrà nella sua ultima impostazione del motore) I sistemi di classe A sono sviluppati sotto una quantità elevata di test e livello di controllo.
  • ...
  • per il sistema (classe D) che ho testato la logica principale era "se ci è un errore, invia un messaggio di errore e poi recupera la rete, fermati e attendi un reset dal cockpit. Anche i test di sistema di Classe D includono procedure di test che non vengono utilizzate spesso (es. test white box con emulatori hardware). sono ancora il miglior software testato che abbia mai visto in vita mia.

La logica qui è che un arresto anomalo del sistema non importante non ostacolerà mai la funzione di sistema importante (il pilota può scegliere quando riposare questi). La maggior parte dei sistemi in un aeroplano sono a doppia ridondanza. I microcontrollori e l'architettura HW utilizzati sono progettati in modo tale che i semplici guasti su una scheda avranno un impatto limitato. Anche la rete principale (ad esempio AFDX) è ridondante e le misure sono preso nell'interfaccia che il software in esecuzione selvaggia non va al di fuori dei suoi limiti nell'uso dei bus.

Ripristino normale le procedure sono sicure rispetto a lasciare l'aereo sempre in uno stato controllabile. Un esempio di una procedura di reset errata - spegnendo entrambi i computer di controllo di volo, che non è consentito in volo, perché il pilota non era soddisfatto dei risultati del modo standard di resettare i computer - è stato Air Asia Flight 8501.

CodeCaster
2020-01-03 18:11:38 UTC
view on stackexchange narkive permalink

A volte un computer o uno smartphone si blocca e si riavvia da solo

Ciò può accadere per due motivi: un errore del software o un errore dell'hardware. Entrambi possono causare l'interruzione dell'elaborazione di nuove istruzioni da parte della CPU ( cioè un "blocco") o il riavvio della macchina. Quest'ultimo è vicino a un blocco, perché il sistema operativo rileva che non può continuare a funzionare normalmente e invia un riavvio dell'hardware.

Le possibili cause sono infinite, ma i risultati sono gli stessi: il processore non può eseguire nuove operazioni e quindi non continuare a funzionare normalmente. Questo non è ottimale se le vite umane dipendono dal suo funzionamento continuo.

Gli errori hardware possono essere causati da funzionalità degradate, danni o usura. Ad esempio un alimentatore che non è in grado di fornire sempre la potenza richiesta o un modulo di memoria danneggiato a causa di scariche elettrostatiche, provocando il "ribaltamento" di bit casuali (un 1 viene letto involontariamente come 0 o viceversa).

Gli errori del software sono causati da errori del programmatore o errori di installazione. Un'installazione pulita del sistema operativo (Windows, Linux, MacOS, ...) sul tuo computer o smartphone, con hardware ben funzionante, dato che l'hardware è supportato dal sistema operativo e sono installati i driver appropriati in modo che il sistema operativo possa comunicare correttamente con il hardware, non andrà in crash . Certo, decenni fa alcuni sistemi operativi tendevano a bloccarsi dopo essere rimasti attivi per un certo periodo di tempo, ma è il 2020 ora. Questi problemi sono stati tutti risolti dai sistemi operativi moderni.

Il problema con l'hardware e il software di livello consumer è che non è critico per la vita, non è ridondante e le persone vogliono essere in grado di installare applicazioni casuali sui propri dispositivi, distribuite da sviluppatori di software casuali. Non vedrai un pilota aprire l'App Store sul tuo Airbus a mezz'aria e installare la nuova app Christmas Lights per far lampeggiare festosamente le luci della cabina, il che capita semplicemente di fermare le pompe del carburante perché lo sviluppatore non l'ha mai testata in volo.

Allora come fanno i produttori di aeroplani a impedire che ciò accada:

  • Ridondanza: quando un sistema si ferma (o le sue uscite sono al di fuori dei valori validi), c'è un sistema di riserva che prende il sopravvento.
  • Specificità: a differenza dei computer per uso generico, i dispositivi in ​​un aeroplano hanno un obiettivo molto specifico e sono costruiti, installati, configurati e testati per tale obiettivo.
  • Test: tu potrebbe portare il tuo computer o telefono al negozio per la manutenzione quando inizia a comportarsi in modo irregolare. Potrebbe essere troppo tardi per quell'hardware, ma di solito saranno in grado di recuperare le tue immagini. Acquista nuovo hardware e / o reinstalla il sistema operativo e sei a posto. Gli aerei vengono controllati più regolarmente.
Adoro leggere questo Stack Exchange, ma non so molto sugli aerei. Conosco una o due cose sui computer, quindi spero che questa risposta sia utile e in tema.
I sistemi operativi moderni, come Windows, non vengono utilizzati nei computer di volo. Linux * potrebbe * essere utilizzato, ma penso che sia raro (a causa delle modifiche necessarie per soddisfare gli standard avionici). Più comunemente sarebbe LynxOS o VxWorks, che sono sistemi altamente specializzati progettati per funzionare su avionica ad alta affidabilità e altri sistemi industriali, e non sono un sistema operativo tradizionale come si potrebbe pensare a Windows o Linux.
@Ron non era assolutamente ciò che volevo implicare, scusate se è così! "Riavvio del controllo del motore per Windows Update ..."
@RonBeyer: oltre al certificato VxWorks, l'integrità di Greenhills viene utilizzata anche in applicazioni avioniche critiche per la sicurezza. vxWorks è anche * molto * popolare nell'avionica per applicazioni mission critical.
Un desktop tende a bloccarsi in modo che l'utente / sviluppatore possa vederlo e magari ottenere alcune informazioni sul motivo per cui si è bloccato. (O almeno il fatto che si sia schiantato). Quando si hanno altri requisiti che hanno la priorità (continuano a funzionare) come molti sistemi integrati, si include un timer watchdog che riavvia il sistema se il sistema operativo non lo colpisce ogni millisecondo o altro. I sistemi integrati in genere non richiedono molto tempo per avviarsi. Un classico esempio di qualcosa di simile è [L'errore 1202 e il riavvio associato hanno impedito il disastro all'atterraggio dell'Apollo 11?] (// space.stackexchange.com/q/37549)
forest
2020-01-04 14:13:18 UTC
view on stackexchange narkive permalink

Per quanto riguarda il ciclo di alimentazione in modo specifico (a differenza dei guasti basati sul software in generale che altre risposte hanno dettagliato molto bene), non è affatto un problema. A differenza di un tipico PC o smartphone che richiede tempo per riaccendersi e può perdere dati in caso di interruzione dell'alimentazione, i sistemi di controllo di un aereo sono generalmente progettati in modo tale da riprendere il funzionamento completo nel momento in cui viene ripristinata l'alimentazione.

Pensalo più come il monitor della temperatura interna del tuo frigorifero che come il tuo personal computer. Se lo spegni e riaccendi, inizierà immediatamente a funzionare di nuovo come se non fosse successo nulla.

In particolare, a parte il pilota automatico e il sistema di navigazione, praticamente nessuno dei sistemi fa affidamento su alcuna forma di archiviazione, nemmeno sulla RAM. Si occupano dei dati dei sensori in tempo reale. Se si ripristinano, nessun dato viene perso, perché funzionano solo con i dati che vengono comunque acquisiti in tempo reale. E un pilota automatico o un NAV che si comportano male non fa cadere l'aereo dal cielo, significa solo che la responsabilità di dove stai andando e dove ti trovi ora si sposta dal computer al pilota.
@JörgWMittag In senso stretto, hanno tutti RAM, anche se è solo di pochi kilobyte. Sebbene sia possibile eseguire un programma senza RAM, è troppo limitato anche per questi scopi. Fare calcoli sui dati dei sensori in tempo reale, o anche su operazioni aritmetiche non banali, richiede più di pochi registri generici.
Eugene Styer
2020-01-03 20:37:36 UTC
view on stackexchange narkive permalink

Anche i riavvii a volte possono essere accettabili se è possibile riavviare rapidamente senza perdere informazioni critiche. Ciò è avvenuto durante l'atterraggio dell'Apollo 11 quando hanno ricevuto l ' allarme 1202:

Si è reso conto che il 1202 era un codice che significa che il computer di guida a bordo il mezzo da sbarco si stava sovraccaricando di compiti. I programmatori avevano previsto che un giorno questo sovraccarico potesse verificarsi, e così avevano stabilito un aspetto interno del sistema che avrebbe eseguito automaticamente un riavvio veloce e poi un ripristino della memoria per cercare di rimettere in moto il computer.

ma questo non si applicherebbe affatto al volo tramite controlli ethernet che azionano le superfici di controllo reali, sicuramente?
Se viene rilevato un errore, in molti casi è meglio che il sistema sia temporaneamente inattivo durante il riavvio piuttosto che rimanere bloccato in uno stato di errore.
@Fattie certo che lo sarebbe. Meglio non fare nulla per un momento, poi fare la cosa giusta, che fare subito la cosa sbagliata.
Questo sembra più un commento, dal momento che non c'è davvero alcun confronto tra un vecchio computer con memoria a nucleo magnetico e memoria a fune e requisiti di calcolo eccezionalmente limitati e una complessa macchina moderna con centinaia di microprocessori con ISA incredibilmente complessi e milioni di righe di codice scritte più linguaggi di programmazione.
@forest: I moderni sistemi embedded hanno ancora un timer watchdog che si riavvia se il sistema si blocca, invece di restare seduto come un desktop in modo che un utente possa annotare il codice di errore (o notare che si è bloccato in primo luogo). Ma sì, la citazione in questa risposta lo fa sembrare un primitivo schema di raccolta dei rifiuti. Tuttavia, l'Apollo 11 AGC * aveva * un timer watchdog (lo chiamavano "Nightwatchman": P, ed era una delle poche cose che potevano innescare un riavvio: [In che modo il computer di guida Apollo gestiva gli errori di parità?] (//space.stackexchange.com/q/35934))


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...