Varför är kritiska flygdatorer överflödiga?

Felaktigheter att överväga:

• Överhettning. Detta ändrar chipets timingegenskaper och resulterar så småningom i fel. Detta kan manifesteras som enstaka fel i mitten av till synes normal operation; Det kommer att så småningom krascha, men kan lämna ut dåliga data först.
• Vattenskador. Manifesterar som ett parasitiskt motstånd på tavlan och kan få dig att tolka bitarna lika högt eller lågt. Kan vara läckande höljen, kondensation etc.
• Elektromagnetisk störning. (Systemet är tänkt att vara motståndskraftigt mot detta, men det är fortfarande värt att tänka på).
• Problem med fysisk anslutning. Antingen under konstruktion (lödfel) eller inducerad efteråt (värme, vibration). Mikroskopiska sprickor i skivor eller leder kan passera QA men resultera i intermittenta fel. Återigen kan detta förlora dig en enda bit åt gången. Det här är relaterat till Xbox "Red Ring of Death" problemet.
• Fel på andra komponenter. Kondensatorer är vanliga misstänkta; elektrolytisk, tantal, keramik har alla olika fellägen. Återigen kan detta resultera i ett system som för det mesta fungerar men är benäget att missförstå marginella värden eller lider av tidsstyrning.
• Kuslig materialvetenskap ( "Lila pest" , tin whiskers på grund av blyfritt lödd)
• Del QA kanske inte överensstämmer med de standarder som du förväntar dig (leverantörer levererar sämre delar med en falsk märkning av "rymdkvalitet"). Svår att upptäcka även efter det att det hände.

Det är viktigt att erkänna att i höghastighets digitala system får du inte snygg ren "en" och "noll", får du en serie stigande och fallande kanter som smutsas ut av den parasitiska kapacitansen och induktansen hos ledningar. Detta är i sig sårbart för felintolkning under marginella elektriska förhållanden.

Som annat svar påpekade: En CPU kan misslyckas. Endera delvis (ger felaktiga svar), eller helt.

Dessutom är all dator utsatt för kosmiska strålningar som en gång i taget kan vända lite i minnet (förutom andra felkällor som kortslutning, ...). Det är därför som vetenskapliga experiment och långa servrar använder ECC -minnet. Spaceships använder också specifika härdade processorer för att begränsa denna effekt eftersom de är mindre skyddade mot sådana störningar. Planen flyger på höga höjder och är föremål för mer av dessa störningar än din jordbundna dator.

Även om händelsen av detta händer är mycket ovanligt (men inte oerhört), måste du se till att resultaten är 100% korrekta. En liten omgång kan förändra ditt flygs beteende på oförutsägbara sätt, som att invertera kontrollerna, invertera skyddsrätten för flygkuvertet, ...

Why are critical flight computers redundant?

Mjukvara

En sak som missats är att de redundanta systemen ofta är oberoende mönster, speciellt programvaran. Detta skyddar mot konstruktionsfel (eller programvaruproblem) som annars kan orsaka problem vid sällan förekommande kombinationer av omständigheter.

Maskinvara

Även om en mikroprocessor är mycket tillförlitlig, finns det ett antal faktorer som kan vara relevanta

• Flygplan flyger vid hög höjd där atmosfären ger mindre skydd mot kosmiska strålar . Detta påverkar inte bara besättningshälsa men har potential att interfere med elektroniska enheter .
• Avionicsystem består av mer än bara mikroprocessorer, det finns säkert andra, mer felaktiga enheter, som kondensatorer. Det finns otaliga sätt att elektronik kan misslyckas, t.ex. vibrationsinducerat fel vid jordning som leder till störningar på datalinjer (t ex från analoga sensorer).

I've never heard of microprocessors suddenly failing.

Tillförlitlighet ≠ Säkerhet

• Many accidents occur without any component “failure”
  
  • Caused by equipment operation outside parameters and time limits upon which reliability analyses are based.
  • Caused by interactions of components all operating according to specification.
  • Highly reliable components are not necessarily safe

Från Nancy Leveson, MIT , via UCSD

Jag vet att den här frågan redan har fått en handfull svar, men ingen av dem tycks ta upp frågan om varför det finns tre system i den redundanta uppsättningen, i stället för bara två.

Först och främst, som påpekades av Simon , Jan Hudec och RedGrittyBrick , är mönstren inte identiska alls. Faktum är att de ofta är helt annorlunda av mycket bra skäl: sannolikheten för att ett givet problem kommer att påverka alla överflödiga system och särskilt påverkar alla överflödiga system på samma sätt från "liten" till "fullständigt miniscule som gränsar till obefintlig". Jämför Hur olika är överflödiga flygkontrolldatorer?

För det andra varför finns det tre system i varje redundant setup. När allt fungerar bra och flygplanet är i stadig flygning, för något värde och vissa givna uppsättningar av ingångar, rapporterar alla system att en korrigering av 0 (av vilken enhet som helst) behövs. Vid denna tidpunkt finns det inga problem, och datorerna tjänar bara för att behålla nuvarande tillstånd. Nu misslyckas ett av komponentsystemen att göra jobbet ordentligt av någon anledning, och börjar rapportera att en korrigering av +50 enheter krävs. Det vill säga, uppsättningen svar förändras från [0,0,0] till [0,0, + 50]. Två system är överens och den tredje rapporterar något annat, så vi kan sannolikt säkert ignorera outlieren och gå med de två systemen som rapporterar samma: behandla resultatet som [0,0, felaktigt] och ignorera det felaktiga resultatet när du loggar tekniska detaljer och visar någon form av framstående varning om att systemen måste ses över ASAP. Men vad händer om vi bara hade två system för att börja med, och en av de två misslyckas på samma sätt? Den nödvändiga korrigeringen som krävs är från [0,0] till [0, + 50]. Snabb nu: vilket värde är korrekt? Ska du behålla staten eller korrigera med +50?

Vid den punkten är det finns inget sätt att veta om korrigering med 0 eller +50 är rätt handlingsåtgärd. Du kan ta ett medelvärde, men att använda ett genomsnitt på två siffror (varav en är sannolikt felaktig) kan faktiskt sämre än värdet av sig själv.

Genom att lägga till ett tredje system till den redundanta uppsättningen lägger du till en slitsbrytare för situationen där det finns ett funktionsfel. Endast om två av de tre systemen börjar fungera på samma gång har du ett verkligt problem och om flygplanet har sådana problem att två av tre redundanta system ger felaktiga utgångar så har du troligen några allvarliga problem att börja med .

På specifika redundans är installationsmiljön av dessa system förmodligen den största faktorn. Inte bara är många system hopfällda nära varandra i trånga utrymmen, men luftflödet är ofta mycket begränsat däri. Värme är en stor förstörare av många mikroprocessorer. Flygplan vibrerar också mycket, på grund av snurrande motorer, turbulens i flyg och helt enkelt landning. Dåliga lödförband och sub-par-krympningsjobb eller en lös kopplingsbackshell, och du har en dålig anslutning, eller värre, en intermittent .

På redundans i allmänhet, om du upplever en BSOD på jobbet, är det relativt sakligt. Du kanske har tappat bort dokumentet du arbetade med, men det handlar om det. Om flygplanssystemen går ut har du ett verkligt problem. Det är svårt att uppnå, men redundansen är där för att hundratals människors liv är beroende av det.

Chansen att processorn misslyckas är mycket låg, men inte noll. När processorn misslyckas, vad händer under övergångstiden mellan fel och full funktionalitet efter omstart? Med en sällsynt händelse som denna, kan vi någonsin bygga upp tillräckligt med erfarenhet för att vara säker på att vi har testat under alla omständigheter? Vi pratar om < $ 10 ^ {- 9} $ tal här.

Backups är benägna att dölja fel. Säkerhetskopieringen används normalt inte och slås bara på när det behövs - men har något rostigt eller har en funkig mögel inbäddat i en bekväm varmpunkt och orsakar en kort vid aktivering? Murphy stöter fortfarande på rymdapplikationer. Backupen kan testas före start, men vad händer om det skakar loss och misslyckas huvudprocessorn? Chanserna är smala, men alla större olyckor är idag orsakade av osannolika strängar av händelser som detta.

Redundans är användbar eftersom det kontinuerligt visar att de viktigaste enheterna fungerar som de ska, och används för flygkritiska omständigheter. Back-up-system kan användas om du kan göra det utan huvudenheten, eller om det är garanterat att säkerhetskopieringen alltid kommer att fungera, som manuell aktivering av flygkontrollerna.

En autopilot i kryssning är inte flykritisk och kan kopplas från utan grav konsekvenser. I en CAT III landning där landningsbanan endast kan observeras när du kör på den är de absolut nödvändiga. Du vill inte att autopiloten ska koppla loss 10 meter över banan, ingen synlighet, gusty sidvind - det finns ingen tid att koppla in backupen.

If a microprocessor is overheated or overloaded and spontaneously fails, I would expect it to stop doing anything and produce no output.

Har du någonsin överklockat en CPU, eller tittat på en gammal maskinvara? Du kan få alla sorters konstiga saker medan cpu fortfarande körs.

I ett flygplan är säkerheten viktigare än någon annan faktor (efter det kommer optimal vikt för bränsleeffektivitet och den totala kostnaden är tredje). Om flygplanet inte skulle vara säkert skulle inte tillräckligt många människor flyga och flygbranschen skulle kollapsa. Därför finns det FAA-regler, och det är därför det finns så många regler för flygbolagen. (Flygplatsens säkerhetskontroll är ett annat ämne, relaterat till nationell / politisk säkerhet med invandring mm, så när vi säger "säkerhet" på flygplanet menar jag ingenjörskonst)

Kritiska system ombord (dvs. system som är krävs för att flyga flygplanet) behöver redundans. Liksom brännaren i jetmotorn har 2 tändare, även om man är tillräckligt. Även om en motor misslyckas kan den andra motorn flyga flygplanet, och datorn kommer att kompensera för obalansen i vänster / höger kraft. Många system i flygplanet är beroende av datorn, så det behöver ha en "plan b" (redundans är en av "plan b").

Eftersom teorin är bra är realiteten att inte alla datorkomponenter är lika.

Ett specifikt exempel från början av 90-talet: Intel producerade 486/33 CPU (det var ganska skäre och snabbt snabbt för dagen). De flesta lämnade fabriken bra, men vissa hade en esoterisk bugg i FPU som skulle ge upphov till felaktiga svar. Dagens tidningar fylldes med beräkningar du kunde lägga in i ditt kalkylblad som skulle producera X om din CPU var bra, eller Y om den hade felet.

Om ditt plan råkar vara igång med en av de felaktiga CPU: erna i den, och just den rätta uppsättningen data råkar hämtas och matas in i något av flygkontrollprogrammen och går in i denna FPU-bugg, blir du glad att de andra två CPU: erna beräknade det korrekta värdet och sparkade utjämningsenheten en ur slingan.