Domanda:
Perché i computer di volo critici sono ridondanti?
raptortech97
2015-03-25 02:56:20 UTC
view on stackexchange narkive permalink

Almeno negli aerei di linea, i computer veramente critici sono ridondanti. In genere tre copie identiche dei computer autopilota vengono eseguite in parallelo e confrontano i risultati; se un computer non è d'accordo con gli altri due, il suo output viene ignorato. Il sistema consente ad alcuni processori di essere difettosi mantenendo il funzionamento dell'intero sistema.

Ma perché? Non ho mai sentito parlare di microprocessori che si guastano improvvisamente. Certo, potrebbero esserci errori di produzione, ma quelli sarebbero stati rilevati in fabbrica. Forse il programma (e la sua prova) è sbagliato, ma sarebbe sbagliato allo stesso modo su tutti i processori. Allo stesso modo, un input errato causerebbe un output errato su tutti e tre i computer. Da che tipo di errori protegge questa ridondanza? I microprocessori a volte fanno solo errori matematici?

Se un microprocessore è surriscaldato o sovraccarico e si guasta spontaneamente, mi aspetto che smetta di fare qualsiasi cosa e non produca alcun output. Per affrontare questo tipo di guasto, vorresti avere un processore di backup, ma non avresti bisogno di confrontare gli output di tre computer: qualsiasi output prodotto sarebbe considerato corretto, quindi saresti felice di usare direttamente il output di qualsiasi processore che stava producendo output.

Correlati: la risposta a Qual è lo scopo di più autopiloti? dice semplicemente "ridondanza" prima di vedere come si ottiene ciò.

I will wait for authoritative answers, but on the systems I have been involved with, the 3 computers ran different software, produced by independent teams and proven to generate the same outputs for the same inputs.
AiliqehytkCMT I know the Shuttle had backup software ("design diversity"), but Wikipedia claims this practice is becoming less common.
It might be, I've been out of the loop for about 20 years. BTW, I'm a software engineer now and have seen processors fail and, more commonly, RAM chips fail.
@Simon Ma la RAM può avere ECC, giusto? Nel peggiore dei casi, duplicare la RAM è molto più semplice ed economico che duplicare l'intero computer. Il guasto del processore è molto più preoccupante. Pensi che saresti in grado di scrivere una risposta su come i processori falliscono?
My question is essentially the same as the question I just linked. Should I close this as a duplicate of the other, and then add a bounty to the other? Should I edit the other question to focus on how the redundancy is achieved, to better match the answer?
In my opinion, your question is valid as it is, and I'm interested in the answers. As to how processors fail, it's not worth an answer. I've seen 2 from memory. One was a fan failure, and the chip just fried itself and the other was unknown. Manifested itself as increasingly weird errors and blue screens followed by a total failure. RAM will almost certainly have ECC but that can only correct single bit errors and report double bit errors. If more bits fail, which is easy with a physical error, then ECC is of no use.
@raptortech97: Autopilot non è così critico; l'aereo può essere pilotato a mano. I sistemi veramente critici sono i controlli fly-by-wire. In Airbus funzionano su coppie di schede dissimili (i386 e m68k) con software scritto in modo indipendente che si incrocia l'un l'altro, queste coppie vengono moltiplicate per il failover e c'è un set indipendente per i controlli di volo primari (elevatore e alettone) e un altro per alternato (spoiler e stabilizzatore orizzontale), quindi se uno dei due fallisce l'altro può comunque controllare sia il beccheggio che il rollio. Credo che il sistema Boeing su 777 e 787 sia simile.
@JanHudec Sono d'accordo che l'autopilota di solito non è critico, ma un guasto durante un autoland Cat III è considerato catastrofico.
Trovo che la scelta di usare 3 sia un po 'strana. Per affrontare uno di questi fallimenti in modo arbitrario è necessaria la resilienza bizantina, che non può essere raggiunta con meno di 4.
@kasperd Potrei sbagliarmi, ma penso che sia solo quando i messaggi possono essere falsificati. Con connessioni fisiche dedicate, non puoi davvero falsificare i messaggi.
@raptortech97 L'analisi dei sistemi senza resilienza bizantina presume che ogni nodo stia funzionando perfettamente o abbia interrotto completamente la comunicazione. Basta un singolo bitflip casuale per invalidare l'analisi di tali sistemi.
@kasperd non è di questo che si parla. Il tipo di analisi della resistenza bizantina che suggerisci si basa sul presupposto che i computer possano mentire e falsificare messaggi da altri computer. Il sistema a tre parti è risolvibile se si dispone di hash crittografici per verificare l'identità.
@raptortech97 È risolvibile solo se si presume che il nodo difettoso smetta di inviare messaggi. Se un singolo nodo si guasta in un modo che gli causa l'invio di messaggi incoerenti, si perdono tutte le garanzie.
@kasperd Cerchiamo [di continuare questa discussione in chat] (http://chat.stackexchange.com/rooms/22267/discussion-between-raptortech97-and-kasperd).
Non hai mai sentito parlare del buon vecchio Murphy? "Tutto ciò che può andare storto andrà storto"
[Sì, i microprocessori a volte sbagliano la matematica.] (Http://en.wikipedia.org/wiki/Pentium_FDIV_bug)
"* Non ho mai sentito parlare di microprocessori che si guastano improvvisamente *". Questo perché non hai familiarità con l'elettronica. Chiedi [qui] (http://electronics.stackexchange.com/) e sarai illuminato. Inoltre un computer di volo non è costituito solo da una CPU / MCU. Tastiera, display, connettori, memoria, orologio, altri chip, altri componenti elettronici, alimentatore ...
Questa domanda è espressa male, in modo spaventoso. Il richiedente sembra intendere che i computer di volo _ impiegano la ridondanza_. Ma quello che in realtà chiede è _perché sono obsoleti? _
Dodici risposte:
#1
+30
pjc50
2015-03-25 16:54:16 UTC
view on stackexchange narkive permalink

Modalità di guasto da considerare:

  • Surriscaldamento. Ciò modifica le proprietà di temporizzazione del chip e alla fine genera un errore. Questo può manifestarsi come errori a bit singolo nel mezzo di operazioni apparentemente normali; alla fine si bloccherà, ma prima potrebbe produrre dati non validi.
  • Danni causati dall'acqua. Si manifesta come una resistenza parassita sulla lavagna e può farti interpretare erroneamente i bit alti o bassi. Possono essere presenti perdite negli alloggiamenti, condensa, ecc.
  • Interferenza elettromagnetica. (Il sistema dovrebbe resistere a questo, ma vale comunque la pena pensarci).
  • Problemi di connessione fisica. O durante la costruzione (difetti di saldatura) o indotti successivamente (calore, vibrazioni). Le crepe microscopiche nei pannelli o nei giunti possono superare il QA, ma provocare guasti intermittenti. Anche in questo caso questo può farti perdere un po 'alla volta. Ciò è correlato al problema dell '"anello rosso della morte" di Xbox.
  • Guasto di altri componenti. I condensatori sono il solito sospetto; elettrolitico, tantalio, ceramica hanno tutti diversi modi di guasto. Anche in questo caso, questo può risultare in un sistema che principalmente funziona ma è incline a interpretare erroneamente i valori marginali o soffre di deriva temporale.
  • Scienza dei materiali strana ( "Purple plague", baffi di stagno a causa della saldatura senza piombo)
  • La parte QA potrebbe non essere all'altezza degli standard previsti (i fornitori spediscono parti inferiori con un'etichetta fasulla "grado aerospaziale"). Difficile da rilevare anche dopo che è accaduto.

È importante riconoscere che nei sistemi digitali ad alta velocità non si ottengono "uno" e "zero" puliti, si ottiene una serie di bordi di salita e discesa che sono macchiati dalla capacità parassita e dall'induttanza del cablaggio. Questo è intrinsecamente vulnerabile a essere interpretato male in condizioni elettriche marginali.

Wow, grazie per l'ottimo dettaglio! Voglio sottolineare che trovo difficile credere che le parti non sarebbero state all'altezza degli standard. Nell'aviazione, il design originale e ogni pezzo di ricambio dovevano ottenere la certificazione FAA, e c'è una grande traccia cartacea che traccia tutto. L'industria dei pezzi di ricambio fasulli è piuttosto piccola oggigiorno.
Vengo dall'elettronica piuttosto che dal lato dell'aviazione qui, quindi non ho familiarità con quanto bene funzioni la traccia cartacea, ma potresti trovarlo interessante se ti piacciono i dettagli: http://www.bunniestudios.com/blog /? page_id = 1022
(Aneddoticamente penso che la maggior parte dei guasti "lavorati in QA fallisca all'inizio della produzione" sono guasti meccanici dei giunti di saldatura; credo che l'aviazione / MILSPEC preferisse il wire-wrap esattamente per questo scopo, ma non è più pratico con piccoli pacchetti)
Questa è la migliore risposta. Il semplice fatto è che le CPU _possono_ produrre risposte sbagliate e _ spesso lo fanno_ quando vengono utilizzate al di fuori della loro tensione / temperatura / ecc specificata. varia perché incasina i tempi. Una differenza temporale di picosecondi può farti leggere il valore sbagliato su una riga. Allo stesso modo, una differenza di tensione molto piccola può far sì che un valore venga letto come 1 invece di 0 o viceversa. Questo è il motivo per cui quando le persone testano gli overclock, eseguono test di burn-in che eseguono calcoli il più rapidamente possibile per ore e ore e cercano risposte sbagliate.
Per quanto riguarda il fatto che prima o poi andrà in crash ... forse _ potrebbe_ finire in crash, o potrebbe continuare a produrre un cattivo output. Quando le CPU si surriscaldano, ad esempio, spesso continuano felicemente a eseguire il loro codice tutto il giorno mentre producono risposte sbagliate, specialmente se una o più ALU o FPU funzionano fuori dalle specifiche, ma il decodificatore delle istruzioni non lo è (il che non è terribilmente modalità di guasto non comune.)
E [latchup] (https://en.wikipedia.org/wiki/Latchup). Se non altro, allora dai raggi cosmici (come menzionato nella risposta di RedGrittyBrick).
#2
+27
Antzi
2015-03-25 10:47:28 UTC
view on stackexchange narkive permalink

Come sottolineato da un'altra risposta: una CPU può fallire. O parzialmente (dando risposte errate), o totalmente.

Inoltre tutti i computer sono soggetti a radiazioni cosmiche che possono occasionalmente capovolgere un po 'nella memoria (oltre ad altre fonti di errore come il cortocircuito,. ..). Ecco perché esperimenti scientifici e server di lunga durata utilizzano la memoria ECC. Le astronavi utilizzano anche specifiche CPU rinforzate per limitare questo effetto poiché sono meno schermate da tali interferenze. Gli aerei volano ad altitudini elevate. e sono soggetti a più di queste interferenze rispetto al tuo computer terrestre.

Anche se l'evento che si verifica è molto raro (ma non inaudito), DEVI assicurarti che i risultati siano accurati al 100%. Un po 'capovolto potrebbe cambiare il comportamento del tuo aereo in modi imprevedibili, come invertire i controlli, invertire la legge sulla protezione dell'inviluppo di volo, ...

Non solo la radiazione cosmica può capovolgere un po 'nella memoria, ma può anche capovolgere un po' nella CPU. Ora ECC per la memoria ha ancora senso poiché la memoria ha molti più bit, ma il rischio esiste ancora per le CPU.
Sì, c'era memoria ECC E CPU rinforzate :)
Penso che questa sia la ragione più importante. Se la cattiva memoria fosse l'unica preoccupazione, potremmo semplicemente triplicare la RAM ma avere una sola CPU. Ma se un raggio cosmico capovolge il bit sbagliato nella CPU e la CPU non viene triplicata, il risultato potrebbe essere catastrofico.
A titolo di confronto, c'è più radiazione di fondo in un tipico aereo passeggeri a quota di crociera rispetto a oggi al punto zero a Hiroshima.
Questo è chiamato un singolo evento sconvolto. Ci saranno spesso 3 copie degli stessi dati salvati in memoria e un'altra unità da sostituire in caso di guasto critico.
#3
+11
RedGrittyBrick
2015-03-25 14:17:44 UTC
view on stackexchange narkive permalink

Perché i computer di volo critici sono ridondanti?

Software

Un punto che è stato perso è che i sistemi ridondanti sono spesso progetti indipendenti, soprattutto il software. Questo protegge da errori di progettazione (o bug del software) che potrebbero altrimenti causare problemi in combinazioni di circostanze che si verificano raramente.

Hardware

Anche se un microprocessore è altamente affidabile, ci sono un certo numero di fattori che possono essere rilevanti

  • gli aerei volano ad alta quota dove l'atmosfera fornisce meno protezione contro i raggi cosmici. Ciò non solo influisce sulla salute dell'equipaggio, ma ha il potenziale di interferire con i dispositivi elettronici.
  • I sistemi avionici sono composti da più di semplici microprocessori, ci sono sicuramente anche altri dispositivi più soggetti a guasti, come i condensatori. Esistono innumerevoli modi in cui l'elettronica può fallire, ad es. guasto della messa a terra indotto da vibrazioni che porta a interferenze sulle linee dati (ad esempio da sensori analogici).

Non ho mai sentito parlare di microprocessori che si guastano improvvisamente.

Affidabilità ≠ Sicurezza

  • Molti incidenti si verificano senza alcun "guasto" dei componenti
    • Causato dalle apparecchiature funzionamento al di fuori dei parametri e dei limiti di tempo su cui si basano le analisi di affidabilità.
    • Causato da interazioni di componenti che funzionano tutti secondo le specifiche.
    • Componenti altamente affidabili non sono necessariamente sicuri

Da Nancy Leveson, MIT, tramite UCSD

"Non ho mai sentito parlare di microprocessori che si guastano improvvisamente." Una volta ho avuto un errore in un desktop. Sto digitando qualsiasi cosa e lo schermo è diventato nero. Dopo i consueti test, l'abbiamo rimandato indietro, hanno detto che avevamo bisogno di una nuova CPU.
Le persone che non hanno mai sentito parlare di guasti alle CPU non sono mai passate attraverso i giorni AMD Athlon / Pentium4 in cui friggere una CPU non era raro
Grazie per aver detto che in effetti il ​​software ** non ** è identico, ma diversi team scrivono per hardware diverso, ma con le stesse specifiche. La domanda originale è fuorviante, per non dire altro.
#4
+11
a CVn
2015-03-25 17:51:53 UTC
view on stackexchange narkive permalink

So che questa domanda ha già ricevuto una manciata di risposte, ma nessuna sembra affrontare il problema del perché ci sono tre sistemi nell'insieme ridondante, anziché solo due.

Prima di tutto, come è stato sottolineato da Simon, Jan Hudec e RedGrittyBrick, i design non sono affatto identici. In effetti, sono spesso completamente diversi per un'ottima ragione: la probabilità che un dato problema influisca su tutti i sistemi ridondanti, e specialmente influenzi tutti i sistemi ridondanti allo stesso modo, va da "piccolo" a "assolutamente minuscolo che rasenta l'inesistente". Confronta Quanto sono dissimili i computer per il controllo di volo ridondanti?

Secondo, sul perché ci sono tre sistemi in ciascuna configurazione ridondante. Quando tutto funziona correttamente e l'aereo è in volo costante, per un certo valore e un dato set di input, tutti i sistemi segnalano che è necessaria una correzione di 0 (di qualsiasi unità). A questo punto non ci sono problemi ei computer servono solo a mantenere lo stato attuale. Ora, uno dei sistemi componenti non riesce a svolgere correttamente il proprio lavoro per qualsiasi motivo e inizia a segnalare che è necessaria una correzione di +50 unità. Ovvero, l'insieme delle risposte cambia da [0,0,0] a [0,0, + 50]. Due sistemi sono d'accordo e il terzo riporta qualcos'altro, quindi possiamo probabilmente ignorare in sicurezza il valore anomalo e andare con i due sistemi che riportano lo stesso: considera il risultato come [0,0, errato] e ignora il risultato errato durante la registrazione dei dettagli tecnici e mostrando una sorta di avvertimento evidente che i sistemi devono essere esaminati al più presto. Ma cosa succederebbe se all'inizio avessimo solo due sistemi e uno dei due fallisse allo stesso modo? La correzione determinata necessaria va da [0,0] a [0, + 50]. Veloce adesso: quale valore è corretto? Dovresti mantenere lo stato o correggere entro +50?

A quel punto, non c'è modo di sapere se la correzione di 0 o +50 è la linea di condotta corretta. Potresti prendere una media, ma usare una media di due numeri (uno dei quali probabilmente non è corretto) potrebbe effettivamente essere peggiore di entrambi i valori da solo.

Aggiungendo un terzo sistema al set ridondante, si aggiunge un tie breaker per la situazione in cui è presente un sistema malfunzionante. Solo se due dei tre sistemi iniziano a funzionare male allo stesso tempo si ha un problema reale, e se l'aereo ha problemi tali che due sistemi ridondanti su tre forniscono uscite errate, è probabile che tu abbia dei seri problemi con .

#5
+5
Frank
2017-06-05 13:56:14 UTC
view on stackexchange narkive permalink

La maggior parte delle risposte ha ruotato attorno al potenziale di errori hardware del computer e cose del genere. Sebbene tutto ciò sia vero, nessuno ha menzionato ciò che i computer stanno effettivamente guardando.

Supponiamo che ti stia avvicinando, ti stai preparando per fare un autoland CAT III e hai solo due sistemi di computer. Entrambi i sistemi informatici confrontano i sistemi di radioaltimetro n. 1 e n. 2. Solo c'è un malfunzionamento con uno dei sistemi di radioaltimetro che causa una discrepanza di qualche valore arbitrario che non rientra nei limiti.

Come fa il computer a sapere quale è sbagliato? Un computer guarda il sistema radioaltimetro n. 1 e vede 500 piedi. L'altro guarda il sistema n. 2 e vede 1000 piedi. Quale è giusto e quale è sbagliato? Come potrebbe il computer prendere questa decisione?

Inserisci il terzo computer. Se il valore di ciò che vede è commiserato con quello di uno qualsiasi degli altri due computer, può effettivamente "votare" la lettura non valida "fuori dall'isola".

Dovrei notare che la maggior parte di questi computer ha da due a quattro processori che confrontano i propri risultati. Questa è la ridondanza INTERNA per evitare guasti hardware, ma avere numerosi confronti incrociati di sistemi esterni è in gran parte la ragione per cui esiste un terzo sistema.

Nota: in qualità di meccanico A&P, 9 volte su 10 è uno dei sistemi esterni che si è guastato (radioaltimetro, miscomparare MMR / ILS, ecc ...) che causa un degrado delle capacità - NON il computer stesso.

#6
+4
David Richerby
2015-03-25 13:39:25 UTC
view on stackexchange narkive permalink

I computer si guastano, spontaneamente, continuamente. Non ci sei abituato perché non hai usato molti computer. Ma considera qualcuno come Google, che gestisce enormi data center contenenti migliaia di computer. Il software che esegue Google è progettato intorno al presupposto esplicito che i computer non funzionino perché accade più volte al giorno. Ora, un aereo non contiene molti computer, ma quelli che contiene sono fondamentali per la sicurezza. Quindi vengono duplicati per assicurarsi che il loro fallimento non causi problemi.

Penso che l'OP chiedesse in particolare il fatto che ce ne sono tre che si confrontano invece di solo due nel caso in cui l'hardware muoia.
Da tutto quello che ho sentito sui sistemi di Google, sono progettati per gestire il guasto totale di qualsiasi computer, non i computer che si comportano male
Hmm. Penso che affrontare il malfunzionamento piuttosto che il fallimento totale sia implicito nella mia risposta, ma entrambi avete ragione sul fatto che non è molto ben adattato alla domanda. Ci penserò e lo migliorerò o lo cancellerò.
I sistemi di Google si basano su fail-and-retry in quanto integrato in tutti i protocolli Internet. Altri sistemi di grandi dimensioni sono simili e abbracciano anche il funzionamento "solo crash" (vedi Netflix "scimmia caos"). Questo non è appropriato per i sistemi in tempo reale critici per la sicurezza. È un interessante contrasto tra un sistema economico che in pratica funziona quasi sempre e un sistema molto più difficile da sviluppare e più costoso che può offrire garanzie di progettazione.
#7
+2
Dave
2015-03-25 05:36:36 UTC
view on stackexchange narkive permalink

Se guardiamo a questo da un punto di vista strettamente ingegneristico, i microprocessori come qualsiasi altra cosa hanno un ciclo di vita. In generale è molto lungo e il PC da cui lo stai postando molto probabilmente sarà obsoleto molto prima che arrivi il ciclo di vita. Sebbene un microprocessore non abbia parti mobili, riceve input da vari sensori. Posso solo presumere che gli ingressi siano fusi in qualche modo, ma ciò non significa che i picchi siano completamente eliminati e isolati se si verificano. Per quello che vale, anche picchi relativamente piccoli friggeranno un microprocessore. Tenendo presente questo, per errare sul lato della cautela vengono utilizzati più sistemi. Con le dimensioni sempre più ridotte della tecnologia è diventato più facile ed economico trasportare un ricambio, quindi dal punto di vista delle vendite la tranquillità è lì. Anche in questo caso è meglio averlo e non usarlo che non averlo quando ne hai bisogno.

Per rispondere direttamente alla tua domanda, mi occupo di microprocessori, microcontrollori e simili da molto tempo. In quel periodo ho avuto forse due o tre fallimenti spontanei, di solito legati al caldo. In un aereo questo potrebbe non sembrare un problema, ma in realtà il freddo estremo può causare problemi oltre al caldo estremo quando si tratta di elettronica. Detto questo, ho tostato innumerevoli unità colpendole con input sovraccarichi. Diciamo che il tuo aereo è stato colpito da un fulmine (so che le compagnie aeree moderne sono protette da questo) ma per amor di discussione diciamo che un terreno era cattivo: questo brinderebbe facilmente a un'unità.

Nota a margine: oggigiorno è più comune che i chip / le unità di memoria si guastino. Questo è qualcosa che potresti non sapere mai poiché la maggior parte dei computer moderni può gestire la memoria morta sia nel disco che nella memoria di sistema.

The avionics will generally be in the avionics bay below the cockpit, or in the cockpit itself, so the extreme cold won't be an issue, but with inadequate cooling they could overheat. What I didn't clarify was that if a microprocessor spontaneously fails, it should be possible to detect that and switch to a backup. The system in use compares the three outputs, implying that a microcontroller could produce an incorrect output, as opposed to simply failing to produce any output.
Trovo dubbia nel migliore dei casi l'affermazione che "la maggior parte dei computer moderni può gestire la memoria morta". Forse nel senso stretto che "se una cella di memoria si guasta, non causerà immediatamente il crash del computer", ma ** ** causerà un funzionamento irregolare non appena quella memoria viene effettivamente utilizzata per qualcosa. La grazia salvifica in un certo senso è che nei PC moderni, la maggior parte della RAM * non * viene utilizzata attivamente; viene utilizzato per la cache. Il che può essere altrettanto negativo se non hai modo di rilevare un problema (il che in pratica significa che stai utilizzando RAM non ECC, cosa che la maggior parte dei sistemi desktop non fa).
Non è corretto, i PC sono in grado di saltare e ignorare i settori danneggiati sul disco, vedere qui http://en.wikipedia.org/wiki/Bad_sector allo stesso modo il kernel Linux ora supporta badram e badmem che sono in grado di dire al sistema di saltare indirizzi corrotti, che è ciò a cui mi riferivo. Hai comunque ragione sul fatto che una cattiva memoria può causare un comportamento irregolare, tuttavia non è sempre così.
@user16230: E chi dice al kernel di escludere quella memoria? certamente non il programma che sta attualmente scappando da quella memoria. Questa è una misura di ultima istanza puramente offline che viene eseguita dopo aver rilevato che un bit di memoria è difettoso in modo diverso da un programma attualmente in esecuzione su di esso. Anche per i settori danneggiati il ​​risultato è * perdita di dati *. Niente che possa essere risolto durante il volo riflettendo il sistema. Anche i bit potrebbero comportarsi male solo nelle condizioni più strane, che non possono essere rilevate nemmeno dai migliori programmi di test della memoria. O perché pensi che il martello da guerra sia stato scoperto solo di recente?
Anche in questo caso sono d'accordo, tuttavia mi limitavo a far notare che è possibile affrontare la cattiva memoria (non che io consiglio di farlo in volo).
AilijotjnxCMT You are still not getting the point. It is not possible to deal with bad memory, if you have no idea that it is bad, or will get bad in 5 minutes. You need means to detect bad memory, recover stored data and remap. This is not only far more expensive than having three redundant systems, it is also totally impossible for all failure scenarios. As such dealing with memory failures mid flight might be possible, but you have to plan for the events where it is not possible, by implementing majority vote decisions, which have a far lower rate of error.
@PlasmaHH potresti presumibilmente mettere in RAID alcuni chip di memoria insieme e collegarli a una singola CPU senza la spesa di avere tre chip di memoria e tre CPU.
@raptortech97: hai ancora bisogno di tre moduli ram, altrimenti non hai la maggioranza e potresti al massimo rilevare che un bit è andato storto. Sì, potresti creare un sistema personalizzato che utilizza un codice hamming o un altro codice di ordine superiore perfetto, ma cosa poi? Hai ancora possibili bit che potrebbero capovolgersi nei registri o nelle cache. Hamming codifica anche questi? cosa fare con i bitflip nel decoder? Anche questo costerebbe molto di più del semplice licenziamento maggioritario. E non si occuperà di cose come errori di lettura analogica (ad es. Impedenza maggiore dal sensore all'adc)
#8
+2
Erich
2015-03-25 17:51:41 UTC
view on stackexchange narkive permalink

Su una ridondanza specifica, l ' ambiente di installazione di questi sistemi è probabilmente il fattore più importante. Non solo molti sistemi sono stipati strettamente insieme in spazi ristretti, ma spesso il flusso d'aria è molto limitato. Il calore è un grande distruttore di molti microprocessori. Anche gli aeroplani vibrano, molto, a causa dei motori in rotazione, delle turbolenze in volo e del semplice atterraggio. Giunti di saldatura scadenti e lavori di crimpatura sub-par o un guscio posteriore del connettore allentato e hai una cattiva connessione, o peggio, una intermittente .

Sulla ridondanza in generale, se tu sperimentare un BSOD al lavoro, in confronto non è un grosso problema. Potresti aver perso il documento su cui stavi lavorando, ma questo è tutto. Se i sistemi degli aerei si spengono, hai un vero problema. È difficile da ottenere, ma la ridondanza c'è perché la vita di centinaia di persone fa affidamento su di essa .

#9
+2
Koyovis
2017-06-05 09:42:11 UTC
view on stackexchange narkive permalink

La possibilità di guasto del processore è davvero molto bassa, ma non pari a zero. In caso di guasto del processore, cosa succede durante il tempo di transizione tra guasto e piena funzionalità dopo il riavvio? Con un evento raro come questo, potremmo mai accumulare abbastanza esperienza per essere sicuri di aver testato in tutte le circostanze? Stiamo parlando di < $ 10 ^ {- 9} $ numeri qui.

I backup sono soggetti a errori nascosti. Il backup normalmente non viene utilizzato e viene acceso solo quando necessario, ma ha qualcosa arrugginito o ha uno stampo funky annidato in un punto caldo confortevole e causa un cortocircuito dopo l'attivazione? Murphy perseguita ancora le applicazioni aerospaziali. Il backup può essere testato prima del decollo, ma cosa succede se si allenta e il processore principale si guasta? Le possibilità sono scarse, ma oggigiorno tutti gli incidenti gravi sono causati da stringhe improbabili di eventi come questo.

La ridondanza è utile perché dimostra continuamente che i dispositivi principali funzionano correttamente e viene utilizzata per circostanze critiche di volo . I sistemi di backup possono essere utilizzati se è possibile fare a meno del dispositivo principale o se è garantito che il backup funzionerà sempre, come l'attivazione manuale dei controlli di volo.

Un pilota automatico in crociera non lo è volo critico e può essere disconnesso senza gravi conseguenze. In un atterraggio CAT III in cui la pista può essere osservata solo una volta che ci si guida, sono assolutamente vitali. Non vuoi che l'autopilota si disconnetta a 10 metri sopra la pista, nessuna visibilità, vento laterale rafficato: non c'è tempo per attivare il backup.

Apprezzo la risposta. Nota che io uso loro pronomi, non lui / lui.
L'ho notato e modificato.
"* Un autopilota in crociera non è critico per il volo, e può essere disconnesso senza gravi conseguenze *", vero in teoria, ma una volta è stato letale se accoppiato con il guasto dell'indicazione della velocità relativa.
@mins In realtà a ogni evento come il disimpegno dell'autopilota durante la crociera viene assegnato un livello di sicurezza e deve soddisfare quel livello di sicurezza. Il livello di ridondanza e rigore viene regolato per soddisfare il livello di sicurezza richiesto. Il disimpegno dell'autopilota durante la crociera è grave, sì, ma non "catastrofico" e quindi viene contrassegnato durante l'analisi della sicurezza come un problema "minore" o "maggiore". La stessa analisi di sicurezza può contrassegnare la disconnessione dell'autopilota e il guasto dell'indicazione della velocità come un problema congiunto con conseguenze maggiori se c'è un'interazione significativa tra i due.
#10
+1
NPSF3000
2015-03-26 03:24:11 UTC
view on stackexchange narkive permalink

Se un microprocessore è surriscaldato o sovraccarico e si guasta spontaneamente, mi aspetterei che smetta di fare qualsiasi cosa e non produca alcun output.

Hai mai overcloccato una CPU o guardato un vecchio pezzo di hardware muore? Puoi ottenere tutti i tipi di strani artefatti mentre la cpu è ancora in esecuzione.

Le CPU utilizzate in attività critiche per la sicurezza sono accoppiate a un [watch dog] (https://en.wikipedia.org/wiki/Watchdog_timer), un (semplice) sistema simile all'industria ferroviaria [dead man] (https: // en. wikipedia.org/wiki/Dead_man%27s_switch). Questo arresta / ripristina la CPU non appena non è in grado di eseguire un handshake predefinito (ad esempio per scaricare una capacità prima che sia completamente carica)
#11
+1
mimosa
2015-04-09 00:24:11 UTC
view on stackexchange narkive permalink

In un aereo, la sicurezza è più importante di qualsiasi altro fattore (dopo di che arriva il peso ottimale per l'efficienza del carburante e il costo complessivo è il terzo). Se l'aereo non fosse al sicuro, non volerebbe abbastanza gente e l'industria aerea crollerebbe. Ecco perché ci sono regolamenti FAA, ed è per questo che ci sono così tante regole per le compagnie aeree. (il controllo di sicurezza aeroportuale è un altro argomento, relativo alla sicurezza nazionale / politica con immigrazione, ecc., quindi quando diciamo "sicurezza" dell'aereo, intendo ingegneristico)

Sistemi critici a bordo (es. sistemi necessari per far volare l'aereo) avranno bisogno di ridondanza. Come il bruciatore del motore a reazione ha 2 accenditori, anche se uno è sufficiente. Inoltre, se un motore si guasta, l'altro motore può far volare l'aereo e il computer compenserà lo squilibrio di forza sinistra / destra. Molti sistemi dell'aereo si basano sul computer, quindi deve avere un "piano b" (la ridondanza è uno dei "piano b")

Questo non risponde alla domanda completa. So che la maggior parte delle cose nel settore dell'aviazione sono ridondanti, ma tutta questa ridondanza ha una ragione specifica: una modalità di guasto che potrebbe rendere utile la ridondanza. Stavo chiedendo da quale modalità di guasto protegge la ridondanza del chip.
#12
-1
FreeMan
2015-03-25 10:37:18 UTC
view on stackexchange narkive permalink

Perché, nonostante la teoria sia buona, la realtà è che non tutti i componenti del computer sono uguali.

Un esempio specifico dei primi anni '90: Intel ha prodotto la CPU 486/33 (era piuttosto all'avanguardia e incredibilmente veloce per la giornata). La maggior parte ha lasciato la fabbrica senza problemi, ma alcuni avevano un bug esoterico nell'FPU che avrebbe generato risposte errate. Le riviste del giorno erano piene di calcoli che potresti inserire nel tuo foglio di calcolo che produrrebbe X se la tua CPU fosse buona, o Y se avesse il bug.

Se il tuo aereo funziona con uno dei le CPU difettose in esso, e solo il giusto set di dati viene raccolto e inserito in uno qualsiasi dei programmi di controllo di volo e si imbatte in questo bug della FPU, sarai felice che le altre due CPU abbiano calcolato il valore corretto e calciato il uno errante fuori dal giro.

Penso che il tuo esempio sia fuorviante. Innanzitutto, penso che tu stia effettivamente parlando del [bug del Pentium FDIV] (https://en.wikipedia.org/wiki/Pentium_FDIV_bug). È stato un errore di progettazione, non un errore di produzione casuale. Ogni processore fornito presentava il bug, fino a quando il progetto non è stato corretto. In tal caso, la ridondanza non avrebbe aiutato: si otterrebbero solo più copie della stessa risposta sbagliata.
È o il bug Pentium FDIV come menzionato da @DavidRicherby, o qualcosa di simile al [problema del doppio sigma 80386] (https://en.wikipedia.org/wiki/Intel_80386#Early_problems). Non credo che il 486 abbia mai avuto il tipo di problemi descritti in questa risposta.
@MichaelKjörling Suona molto come una fusione del 386 double-sigma (che colpisce un campione apparentemente casuale di unità prodotte) e del bug Pentium FDIV (virgola mobile e molta attenzione pubblica).
Indipendentemente da ciò, sarebbe più economico testare a fondo ogni processore piuttosto che triplicarli.
@raptortech97 [Dillo alla NASA. Non lo sanno.] (Http://space.stackexchange.com/q/247/415)
@MichaelKjörling si tratta di testare * progetti * per la tolleranza alle radiazioni, non di eseguire ogni campione di produzione attraverso test operativi di base
@DavidRicherby, l'OP potrebbe fondere il bug del Pentium FDIV con l'origine del [486SX] (https://en.wikipedia.org/wiki/Intel_80486SX), dove 486DX con un FPU difettoso avevano l'FPU disabilitato e sono stati venduti come integer- solo CPU.


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