Pytanie:
Dlaczego krytyczne komputery pokładowe są zbędne?
raptortech97
2015-03-25 02:56:20 UTC
view on stackexchange narkive permalink

Przynajmniej w samolotach pasażerskich naprawdę krytyczne komputery są zbędne. Zwykle trzy identyczne kopie komputerów autopilota działają równolegle i porównują wyniki; jeśli jeden komputer nie zgadza się z pozostałymi dwoma, jego wyjście jest ignorowane. System pozwala na uszkodzenie niektórych procesorów przy jednoczesnym zachowaniu działania całego systemu.

Ale dlaczego? Nigdy nie słyszałem o nagłej awarii mikroprocesorów. Jasne, mogą wystąpić błędy produkcyjne, ale zostałyby wykryte w fabryce. Być może program (i jego dowód) jest błędny, ale byłby błędny w ten sam sposób dla wszystkich procesorów. Podobnie złe dane wejściowe spowodowałyby złe wyniki na wszystkich trzech komputerach. Przed jakimi błędami chroni ta nadmiarowość? Czy mikroprocesory czasami po prostu robią błędy matematyczne?

Jeśli mikroprocesor jest przegrzany lub przeciążony i spontanicznie zawiedzie, spodziewałbym się, że przestanie robić cokolwiek i nie będzie generował żadnych wyników. Aby poradzić sobie z tego rodzaju awariami, chciałbyś mieć zapasowy procesor, ale nie musiałbyś porównywać wyników trzech komputerów - każde wygenerowane wyjście byłoby uznane za poprawne, więc z przyjemnością skorzystasz bezpośrednio z wyjście dowolnego procesora, który generował dane wyjściowe.

Powiązane: odpowiedź na pytanie Jaki jest cel wielu autopilotów? po prostu mówi „redundancja”, zanim przejdziemy do tego, jak to osiągnąć.

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.
@Simon Wiem, że Shuttle miał oprogramowanie do tworzenia kopii zapasowych („różnorodność projektów”), ale Wikipedia twierdzi, że ta praktyka staje się coraz mniej powszechna.
Możliwe, że nie interesowałem się tym przez około 20 lat. Przy okazji, jestem teraz inżynierem oprogramowania i widziałem, jak procesory zawodzą, a częściej układy pamięci RAM zawodzą.
AiliimznawCMT But RAM can have ECC, right? In the worst case, duplicating RAM is a lot easier and cheaper than duplicating the entire computer. The processor failing is much more of a concern. Do you think you'd be able to write an answer about how processors fail?
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 nie jest aż tak krytyczny; samolot można latać ręcznie. Naprawdę krytycznymi systemami są sterowanie fly-by-wire. W Airbusie działają na parach różnych płyt (i386 i m68k) z niezależnie napisanymi programami, które sprawdzają się wzajemnie, te pary są mnożone w celu przełączenia awaryjnego i istnieje niezależny zestaw dla podstawowych elementów sterujących lotem (ster wysokości i lotek) oraz inny dla naprzemiennie (spoilery i stabilizator poziomy), więc jeśli jeden z nich zawiedzie, drugi nadal może kontrolować pochylenie i przechylenie. Uważam, że system Boeing w 777 i 787 jest podobny.
@JanHudec Zgadzam się, że autopilot zwykle nie jest krytyczny, ale awaria podczas autolandu Cat III jest uważana za katastrofalną.
Uważam, że wybór 3 jest trochę dziwny. Aby poradzić sobie z niepowodzeniem jednego z nich w dowolny sposób, potrzebujesz bizantyjskiej odporności, której nie da się osiągnąć mając mniej niż 4.
@kasperd Mogę się mylić, ale myślę, że to tylko wtedy, gdy wiadomości można sfałszować. Dzięki dedykowanym połączeniom fizycznym nie można naprawdę fałszować wiadomości.
AiliqxocicCMT The analysis of systems without byzantine resilience assume that each node is either operating perfectly or has stopped communicating entirely. It only takes one single random bitflip to invalidate the analysis of such systems.
AilibrkqyrCMT that's not what in talking about. The type of Byzantine resistance analysis you suggest relies on the assumption that computers can lie and forge messages from other computers. The three-party system is solvable if you have cryptographic hashes to verify identity.
@raptortech97 Można to rozwiązać tylko wtedy, gdy założymy, że wadliwy węzeł przestaje wysyłać jakiekolwiek komunikaty. Jeśli pojedynczy węzeł ulegnie awarii w sposób powodujący wysyłanie niespójnych komunikatów, tracisz wszystkie gwarancje.
AilixjqeukCMT Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/22267/discussion-between-raptortech97-and-kasperd).
Czy nie słyszałeś o starym, dobrym Murphym? „Wszystko, co może pójść źle, pójdzie źle”
[Tak, mikroprocesory czasami robią błędy matematyczne.] (Http://en.wikipedia.org/wiki/Pentium_FDIV_bug)
„* Nigdy nie słyszałem o nagłej awarii mikroprocesorów *”. To dlatego, że nie znasz elektroniki. Zapytaj [tutaj] (http://electronics.stackexchange.com/), a zostaniesz oświecony. Ponadto komputer pokładowy składa się nie tylko z CPU / MCU. Klawiatura, wyświetlacz, złącza, pamięć, zegar, inne chipy, inne komponenty elektroniczne, zasilacz ... nazwij to.
To pytanie jest źle sformułowane - przerażające. Wydaje się, że pytający oznacza komputery pokładowe _ wdrażanie nadmiarowości_. Ale tak naprawdę pyta, dlaczego są przestarzałe?
Dwanaście odpowiedzi:
pjc50
2015-03-25 16:54:16 UTC
view on stackexchange narkive permalink

Tryby awarii do rozważenia:

  • Przegrzanie. To zmienia właściwości czasowe chipa i ostatecznie prowadzi do błędu. Może się to objawiać jako błędy jednobitowe w trakcie pozornie normalnej pracy; w końcu ulegnie awarii, ale najpierw może wyprowadzić złe dane.
  • Szkody spowodowane zalaniem. Przejawia się jako pasożytniczy opór na tablicy i może powodować błędną interpretację bitów jako wysokich lub niskich. Mogą to być nieszczelne obudowy, kondensacja itp.
  • Zakłócenia elektromagnetyczne. (System ma być na to odporny, ale nadal warto się nad tym zastanowić).
  • Problemy z połączeniem fizycznym. Albo podczas budowy (błędy lutowania), albo wywołane później (ciepło, wibracje). Mikroskopijne pęknięcia w płytach lub złączach mogą przejść kontrolę jakości, ale powodują sporadyczne usterki. Znowu to może cię stracić po kawałku. Jest to związane z problemem „czerwonego pierścienia śmierci” konsoli Xbox.
  • Awaria innych składników. Podejrzane są kondensatory; elektrolityczne, tantalowe, ceramiczne mają różne tryby awarii. Znowu może to skutkować systemem, który przeważnie działa, ale jest podatny na błędną interpretację wartości marginalnych lub cierpi z powodu dryfu czasu.
  • Dziwna nauka o materiałach ( „Purpurowa plaga”, wąsy cynowe z powodu lutu bezołowiowego)
  • Część QA może nie odpowiadać oczekiwanym standardom (dostawcy wysyłają gorsze części z fałszywą etykietą „klasa lotnicza”). Trudne do wykrycia, nawet gdy to się wydarzy.

Ważne jest, aby zdawać sobie sprawę, że w szybkich systemach cyfrowych nie otrzymujesz czystego „jedynki” i „zera”, otrzymujesz serię wznoszące się i opadające krawędzie, które są rozmazane przez pasożytniczą pojemność i indukcyjność okablowania. Jest to z natury podatne na błędną interpretację w marginalnych warunkach elektrycznych.

Wow, thanks for the great detail! I do want to note that I find it hard to believe that the parts would not have been up to standard. In aviation, the original design and every spare part had to get FAA-certified, and there's a large paper trail tracking everything. The bogus spare parts industry is rather small nowadays.
I'm coming from the electronics rather than the aviation side here, so I'm not familiar with how well the paper trail works, but you might find this interesting if you like detail: http://www.bunniestudios.com/blog/?page_id=1022
(Anegdotycznie myślę, że większość błędów „przepracowanych w QA nie udaje się na wczesnym etapie produkcji” to mechaniczne uszkodzenia połączeń lutowanych; uważam, że lotnictwo / MILSPEC preferowało owijanie drutu właśnie do tego celu, ale nie jest to już praktyczne w przypadku małych opakowań)
To najlepsza odpowiedź. Prosty fakt jest taki, że procesory _ mogą_ dawać błędne odpowiedzi i _ często robią_, gdy działają poza określonym napięciem / temperaturą / itp. zakresy, ponieważ miesza z czasami. Różnica w czasie wynosząca pikosekund może spowodować odczytanie niewłaściwej wartości z wiersza. Podobnie bardzo mała różnica napięcia może spowodować odczytanie wartości jako 1 zamiast 0 lub odwrotnie. Dlatego, gdy ludzie testują przetaktowywanie, wykonują testy wypalania, które wykonują obliczenia matematyczne tak szybko, jak to możliwe, przez wiele godzin i czekają na błędne odpowiedzi.
Jeśli chodzi o stwierdzenie, że w końcu się zawiesi ... może w końcu się zawiesić, lub może po prostu nadal generować zły wynik. Na przykład, gdy procesory stają się zbyt gorące, często szczęśliwie kontynuują wykonywanie swojego kodu przez cały dzień, generując błędne odpowiedzi, zwłaszcza jeśli jedna lub więcej jednostek ALU lub FPU działa poza specyfikacją, ale dekoder instrukcji nie działa (co nie jest strasznie nietypowy tryb awarii).
I [latchup] (https://en.wikipedia.org/wiki/Latchup). Jeśli z niczego innego, to z promieni kosmicznych (jak wspomniano w odpowiedzi RedGrittyBrick).
Antzi
2015-03-25 10:47:28 UTC
view on stackexchange narkive permalink

Jak wskazała inna odpowiedź: CPU może zawieść. Albo częściowo (udzielając błędnych odpowiedzi), albo całkowicie.

Ponadto cały komputer jest poddawany promieniowaniu kosmicznemu, które może raz na jakiś czas przerzucić się trochę w pamięci (oprócz innych źródeł błędów, takich jak zwarcie,. ..). Dlatego eksperymenty naukowe i długotrwałe serwery używają pamięci ECC. Statki kosmiczne używają również specjalnych utwardzonych procesorów, aby ograniczyć ten efekt, ponieważ są mniej chronione przed takimi zakłóceniami. Samoloty latają na dużych wysokościach i są narażeni na więcej takich zakłóceń niż komputer podłączony do ziemi.

Nawet jeśli zdarzenie to jest bardzo rzadkie (ale nie niespotykane), MUSISZ upewnić się, że wyniki są w 100% dokładne. Jeden bit odwrócony może zmienić zachowanie samolotu w nieprzewidywalny sposób, na przykład odwrócenie elementów sterujących, odwrócenie przepisów ochrony obwiedni lotu, ...

Not only can cosmic radiation flip a bit in memory, it can also flip a bit in the CPU. Now ECC for memory still makes sense as memory has far more bits, but the risk still exists for CPU's.
Tak, to była pamięć ECC ORAZ utwardzone procesory :)
I think this is the most important reason. If bad memory were the only concern, we could just triplicate the RAM but have a single CPU. But if a cosmic ray flips the wrong bit in the CPU and the CPU isn't triplicated, the result could be catastrophic.
Dla porównania, w typowym pasażerskim odrzutowcu na wysokości przelotowej jest więcej promieniowania tła niż obecnie w punkcie zerowym w Hiroszimie.
Nazywa się to niezadowalającym wydarzeniem. Często w pamięci przechowywane są 3 kopie tych samych danych, a także inna jednostka do przejęcia w przypadku krytycznej usterki.
RedGrittyBrick
2015-03-25 14:17:44 UTC
view on stackexchange narkive permalink

Dlaczego krytyczne komputery pokładowe są zbędne?

Oprogramowanie

Jeden punkt, który pominięto, to fakt, że systemy nadmiarowe są często niezależnymi projektami, zwłaszcza oprogramowania. Chroni to przed błędami projektowymi (lub błędami oprogramowania), które w przeciwnym razie mogą powodować problemy w rzadko występujących kombinacjach okoliczności.

Sprzęt

Nawet jeśli mikroprocesor jest wysoce niezawodny, istnieje wiele czynniki, które mogą mieć znaczenie

  • samoloty lecą na dużych wysokościach, gdzie atmosfera zapewnia słabszą ochronę przed promieniowaniem kosmicznym. Wpływa to nie tylko na zdrowie załogi, ale może też zakłócać działanie urządzeń elektronicznych.
  • Systemy awioniki składają się nie tylko z mikroprocesorów, z pewnością istnieją także inne, bardziej podatne na awarie urządzenia - np. kondensatory. Elektronika może zawieść na niezliczone sposoby, np. awaria uziemienia wywołana wibracjami prowadząca do zakłóceń na liniach danych (np. z czujników analogowych).

Nigdy nie słyszałem o nagłej awarii mikroprocesorów.

Niezawodność ≠ Bezpieczeństwo

  • Wiele wypadków ma miejsce bez „awarii” żadnego elementu
    • Spowodowane przez sprzęt działanie poza parametrami i ograniczeniami czasowymi, na których oparte są analizy niezawodności.
    • Spowodowane interakcjami wszystkich komponentów działających zgodnie ze specyfikacją.
    • Wysoce niezawodne komponenty niekoniecznie są bezpieczne.

Z Nancy Leveson, MIT, przez UCSD

"I've never heard of microprocessors suddenly failing." I had one fail in a desktop once. I'm typing away at whatever, and the screen just went black. After the usual testing we sent it back, they said we needed a new CPU.
Ludzie, którzy nigdy nie słyszeli o awariach procesorów, nigdy nie przeszli przez AMD Athlon / Pentium 4 dni smażenia procesora nie były rzadkością
Dziękuję za wspomnienie, że rzeczywiście oprogramowanie ** nie ** jest identyczne, ale różne zespoły piszą dla innego sprzętu, ale według tych samych specyfikacji. Pierwotne pytanie jest co najmniej mylące.
a CVn
2015-03-25 17:51:53 UTC
view on stackexchange narkive permalink

Wiem, że to pytanie doczekało się już kilku odpowiedzi, ale żadna z nich nie wydaje się odpowiadać na pytanie, dlaczego w zbiorze nadmiarowym są trzy systemy, a nie tylko dwa.

Po pierwsze, jak wskazali Simon, Jan Hudec i RedGrittyBrick, projekty wcale nie są identyczne. W rzeczywistości często są one zupełnie inne z bardzo dobrego powodu: prawdopodobieństwo, że dany problem wpłynie na wszystkie systemy nadmiarowe, a szczególnie wpłynie na wszystkie systemy nadmiarowe w ten sam sposób, wynosi od „małego” do „zupełnie malutkiego graniczącego z nieistniejącym”. Porównaj Jak różne są nadmiarowe komputery kontroli lotu?

Po drugie, dlaczego w każdej nadmiarowej konfiguracji są trzy systemy. Kiedy wszystko działa dobrze i samolot jest w stabilnym locie, dla jakiejś wartości i pewnego zestawu danych wejściowych, wszystkie systemy zgłaszają, że potrzebna jest korekta 0 (dowolnej jednostki). W tym momencie nie ma problemu, a komputery służą jedynie do utrzymania obecnego stanu. Teraz jeden z systemów składowych nie wykonuje swojego zadania poprawnie z jakiegokolwiek powodu i zaczyna raportować, że wymagana jest korekta o +50 jednostek. Oznacza to, że zestaw odpowiedzi zmienia się od [0,0,0] do [0,0, + 50]. Dwa systemy się zgadzają, a trzeci zgłasza coś innego, więc prawdopodobnie możemy bezpiecznie zignorować wartość odstającą i wybrać dwa systemy, które zgłaszają to samo: potraktuj wynik jako [0,0, nieprawidłowy] i zignoruj ​​nieprawidłowy wynik podczas rejestrowania szczegółów technicznych i wyświetlanie jakiegoś wyraźnego ostrzeżenia, że ​​systemy należy przejrzeć jak najszybciej. Ale co by było, gdybyśmy na początku mieli tylko dwa systemy, a jeden z nich zawodzi w ten sam sposób? Określona wymagana korekta wynosi od [0,0] do [0, + 50]. Teraz szybko: która wartość jest prawidłowa? Czy powinieneś zachować stan, czy poprawić o +50?

W tym momencie nie ma sposobu, aby dowiedzieć się , czy poprawianie o 0 lub +50 jest właściwym działaniem. Możesz wziąć średnią, ale użycie średniej z dwóch liczb (z których jedna prawdopodobnie będzie błędna) może w rzeczywistości być gorsze niż każda z tych wartości sama w sobie.

Dodając wartość trzeci system do zestawu redundantnego, dodajesz remis dla sytuacji, w której jest jeden nieprawidłowo działający system. Tylko jeśli dwa z trzech systemów zaczną działać nieprawidłowo w tym samym czasie, masz rzeczywisty problem, a samolot ma takie problemy, że dwa z trzech nadmiarowych systemów dają błędne wyjścia, prawdopodobnie masz poważne problemy na początku .

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

Większość odpowiedzi dotyczy potencjalnych błędów sprzętu komputerowego i tego typu rzeczy. Chociaż to wszystko prawda, nikt nie wspomniał, na co tak naprawdę patrzą komputery.

Powiedzmy, że zbliżasz się, przygotowujesz się do autolandu CAT III i masz tylko dwa systemy komputerowe. Oba systemy komputerowe porównują systemy wysokościomierzy radiowych nr 1 i 2. Jedynie występuje usterka w jednym z systemów wysokościomierza radiowego, powodująca rozbieżność pewnej arbitralnej wartości, która nie mieści się w granicach.

Skąd komputer wie, który z nich jest nieprawidłowy? Jeden komputer patrzy na system wysokościomierza radiowego nr 1 i widzi 500 stóp. Drugi patrzy na system nr 2 i widzi 1000 stóp. Który z nich jest prawidłowy, a który nie? W jaki sposób komputer mógłby podjąć taką decyzję?

Wpisz trzeci komputer. Jeśli wartość tego, co widzi, współczuje wartości któregokolwiek z pozostałych dwóch komputerów, może skutecznie „głosować” na nieważne czytanie „poza wyspą”.

Powinienem zauważyć, że większość tych komputerów ma od dwóch do czterech procesorów, z których każdy porównuje własne wyniki. To jest WEWNĘTRZNA nadmiarowość, aby uniknąć awarii sprzętu, ale liczne porównania krzyżowe systemów zewnętrznych są w dużej mierze przyczyną istnienia trzeciego systemu.

Uwaga: jako mechanik A&P 9 razy na 10 jest to jeden z systemów zewnętrznych, które uległy awarii (wysokościomierz radiowy, błędne porównanie MMR / ILS itp.), co powoduje pogorszenie możliwości - NIE sam komputer.

David Richerby
2015-03-25 13:39:25 UTC
view on stackexchange narkive permalink

Komputery cały czas ulegają spontanicznym awariom. Nie jesteś do tego przyzwyczajony, ponieważ nie korzystałeś z wielu komputerów. Ale pomyśl o kimś takim jak Google, który prowadzi ogromne centra danych zawierające tysiące komputerów. Oprogramowanie działające w Google zostało zaprojektowane w oparciu o wyraźne założenie, że komputery zawodzą, ponieważ dzieje się to wiele razy dziennie. Obecnie samolot nie zawiera zbyt wielu komputerów, ale te, które zawiera, są krytyczne dla bezpieczeństwa. Są więc duplikowane, aby mieć pewność, że ich awaria nie spowoduje problemu.

Myślę, że OP pytał szczególnie o fakt, że istnieją trzy, które porównują zamiast tylko dwóch w przypadku śmierci sprzętu.
Ze wszystkiego, co słyszałem o systemach Google, są one zaprojektowane tak, aby radziły sobie z całkowitą awarią dowolnego komputera, a nie komputerów, które działają nieprawidłowo
Hmm. Myślę, że moja odpowiedź zawiera raczej kwestię nieprawidłowego działania, a nie otwartej awarii, ale oboje macie rację, że nie jest to zbyt dobrze dostosowane do pytania. Zastanowię się i poprawię go lub usunę.
Systemy Google są zbudowane na zasadzie niepowodzenia i ponowienia, ponieważ jest to wbudowane we wszystkie protokoły internetowe. Inne duże systemy są podobne, a nawet obsługują operację „tylko po awarii” (patrz „małpa chaosu” w serwisie Netflix). To nie jest odpowiednie dla krytycznych dla bezpieczeństwa systemów czasu rzeczywistego. To ciekawy kontrast między tanim systemem, który w praktyce działa prawie cały czas, a dużo trudniejszym do opracowania i droższym systemem, który daje gwarancje projektowe.
Dave
2015-03-25 05:36:36 UTC
view on stackexchange narkive permalink

Jeśli spojrzymy na to ze ściśle inżynierskiego punktu widzenia, mikroprocesory, jak wszystko inne, mają cykl życia. Ogólnie rzecz biorąc, jest to bardzo długie, a komputer, z którego to publikujesz, najprawdopodobniej będzie przestarzały na długo przed pojawieniem się, to cykl życia. Chociaż mikroprocesor nie ma ruchomych części, pobiera dane wejściowe z różnych czujników. Mogę tylko założyć, że wejścia są w jakiś sposób zabezpieczone, ale to nie znaczy, że skoki są całkowicie wyeliminowane i izolowane, jeśli się pojawią. Co za warte, nawet stosunkowo niewielkie przepięcia usmaży mikroprocesor. Mając to na uwadze, aby zachować ostrożność, używanych jest wiele systemów. Wraz ze zmniejszającym się rozmiarem technologii noszenie części zapasowej stało się łatwiejsze i tańsze, więc z punktu widzenia sprzedaży jest to spokój ducha. Znowu lepiej go mieć i nie używać, niż nie mieć go wtedy, gdy tego potrzebujesz.

Aby bezpośrednio odpowiedzieć na Twoje pytanie, od dawna zajmuję się mikroprocesorami, mikrokontrolerami i tym podobnymi. W tym czasie miałem może dwie lub trzy awarie spontaniczne, zwykle związane z upałem. W samolocie może się to nie wydawać problemem, ale w rzeczywistości ekstremalne zimno może powodować problemy, a także ekstremalne ciepło, jeśli chodzi o elektronikę. Biorąc to pod uwagę, wypaliłem niezliczone jednostki, uderzając je przeciążonymi wejściami. Powiedzmy, że w twój samolot uderzyło piorun (wiem, że nowoczesne linie lotnicze są przed tym chronione), ale ze względu na argumenty powiedzmy, że ziemia była zła: to z łatwością wzniosłoby toast za jednostkę.

Uwaga dodatkowa: w dzisiejszych czasach częściej zdarza się, że układy / dyski pamięci ulegają awariom. To jest coś, czego możesz nigdy nie wiedzieć, ponieważ większość nowoczesnych komputerów może radzić sobie z martwą pamięcią, czy to na dysku, czy w pamięci systemowej.

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.
I find the statement that "most modern computers can deal with dead memory" dubious at best. Maybe in the strict sense that "if a memory cell goes bad, it won't immediately cause the computer to crash", but it **will** cause erratic operation as soon as that memory is actually used for something. The saving grace in a way is that in modern PCs, the lion's share of RAM is *not* actively used; it gets used for cache. Which can be equally bad if you have no way of detecting a problem (which in practice means you're using non-ECC RAM, which most desktop systems don't).
That is incorrect, PC's are capable of skipping over and ignoring bad sectors on disk see here http://en.wikipedia.org/wiki/Bad_sector likewise the linux kernel now supports badram and badmem which are capable of telling the system to skip over corrupt addresses, which is what I was referencing. You are however correct that bad memory can cause erratic behavior, however it is not always the case.
AilivvjvpoCMT And who tells the kernel to exclude that memory? certainly not the program that is currently running off from that memory. This is a purely offline last resort measure that is done after detecting that a memory bit is defective by other means than a program currently running on it. Even for bad sectors the result is *data loss*. Nothing that can be fixed mid flight by reflashing the system. Also bits might misbehave under the weirdest conditions only, that can not be detected by even the best memory test programs. Or why do you think rowhammer was only discovered recently?
Znowu się zgadzam, ale po prostu wskazałem, że można sobie poradzić ze złą pamięcią (nie żebym radził robić to w locie).
AilipoqttnCMT 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.
AilikbojfgCMT you could presumably RAID a few memory chips together and connect them to single CPU without the expense of having three memory chips and three CPUs.
AilityhciiCMT you stil need three ram modules, otherwise you have no majority vote and could at most detect that one bit went wrong. Yes you could create a custom system that uses a hamming code or other perfect higher order code, but what then? You still have possible bits that could flip in registers or caches. Hamming code these too? what to do with bitflips in the decoder? Also this would cost an awful lot more than just majority redundance. And it won't deal with things like analogue read out errors (e.g. higher impedance from sensor to adc)
Erich
2015-03-25 17:51:41 UTC
view on stackexchange narkive permalink

Jeśli chodzi o określoną nadmiarowość, środowisko instalacji tych systemów jest prawdopodobnie największym czynnikiem. Wiele systemów jest nie tylko stłoczonych blisko siebie w ciasnych przestrzeniach, ale przepływ powietrza jest tam często bardzo ograniczony. Ciepło jest wielkim niszczycielem wielu mikroprocesorów. Samoloty również bardzo wibrują z powodu obracających się silników, turbulencji podczas lotu i po prostu lądowania. Słabe połączenia lutowane i niedopracowane zaciski lub luźna tylna powłoka złącza i masz złe połączenie lub, co gorsza, przerywane połączenie.

Jeśli chodzi o ogólną redundancję, jeśli Doświadcz BSOD w pracy, stosunkowo nie jest to wielka sprawa. Mogłeś zgubić dokument, nad którym pracowałeś, ale to wszystko. Jeśli systemy samolotu ulegną awarii, masz prawdziwy problem. Jest to trudne do osiągnięcia, ale istnieje nadmiarowość, ponieważ zależy od niego życie setek ludzi .

Koyovis
2017-06-05 09:42:11 UTC
view on stackexchange narkive permalink

Prawdopodobieństwo awarii procesora jest rzeczywiście bardzo niskie, ale nie zerowe. Co się dzieje w przypadku awarii procesora w czasie przejścia między awarią a pełną funkcjonalnością po ponownym uruchomieniu? Czy w przypadku tak rzadkiego wydarzenia moglibyśmy kiedykolwiek zdobyć wystarczające doświadczenie, aby mieć pewność, że przetestowaliśmy wszystkie okoliczności? Mówimy tutaj o liczbach < o wartości 10 $ {- 9} $.

Kopie zapasowe są podatne na ukryte błędy. Kopia zapasowa nie jest zwykle używana i włączana tylko wtedy, gdy jest potrzebna - ale czy coś przerdzewiała lub ma dziwną pleśń umieszczoną w wygodnym ciepłym miejscu i powodującą zwarcie po aktywacji? Murphy nadal nawiedza zastosowania lotnicze. Kopię zapasową można przetestować przed startem, ale co się stanie, jeśli się obluzuje i zawiedzie główny procesor? Szanse są niewielkie, ale wszystkie poważne wypadki w dzisiejszych czasach są spowodowane przez mało prawdopodobne ciągi takich zdarzeń.

Nadmiarowość jest przydatna, ponieważ stale pokazuje, że główne urządzenia działają prawidłowo i jest używana w sytuacjach krytycznych dla lotu . Systemy rezerwowe mogą być używane, jeśli możesz obejść się bez głównego urządzenia lub jeśli masz gwarancję, że rezerwowe będą zawsze działać, jak ręczne uruchamianie elementów sterujących lotem.

Autopilot w rejsie nie jest lot jest krytyczny i może zostać odłączony bez poważnych konsekwencji. Podczas lądowania CAT III, gdzie pas startowy można obserwować tylko podczas jazdy po nim, są one absolutnie niezbędne. Nie chcesz, aby autopilot odłączał się 10 metrów nad pasem startowym, brak widoczności, porywisty boczny wiatr - nie ma czasu na włączenie rezerwy.

Doceniam odpowiedź. Zauważ, że używam ich / ich zaimków, a nie on / on.
Zauważyłem i poprawiłem.
„* Autopilot podczas przelotu nie jest krytyczny dla lotu i może zostać odłączony bez poważnych konsekwencji *”, co prawda w teorii, ale kiedyś był śmiertelny w połączeniu z awarią wskaźnika prędkości.
@mins W rzeczywistości każde zdarzenie, takie jak wyłączenie autopilota podczas rejsu, ma przypisany poziom bezpieczeństwa i musi spełniać ten poziom. Poziom redundancji i rygorystyczności jest dostosowany do wymaganego poziomu bezpieczeństwa. Wyłączenie autopilota podczas rejsu jest poważne, tak, ale nie „katastroficzne”, a zatem podczas analizy bezpieczeństwa jest oznaczane jako tylko „drobny” lub „poważny” problem. Ta sama analiza bezpieczeństwa może oznaczać odłączenie autopilota i awarię wskazań prędkości jako wspólny problem z poważniejszymi konsekwencjami, jeśli istnieje znacząca interakcja między nimi.
NPSF3000
2015-03-26 03:24:11 UTC
view on stackexchange narkive permalink

Jeśli mikroprocesor jest przegrzany lub przeciążony i spontanicznie zawiedzie, spodziewałbym się, że przestanie robić cokolwiek i nie będzie generował żadnych wyników.

Czy kiedykolwiek przetaktowywałeś procesor lub oglądałeś stary kawałek sprzętu umiera? Możesz uzyskać wszelkiego rodzaju dziwne artefakty, gdy procesor nadal działa.

Procesory używane w zadaniach krytycznych dla bezpieczeństwa są sparowane z [watch dog] (https://en.wikipedia.org/wiki/Watchdog_timer), (prostym) systemem podobnym do przemysłu kolejowego [dead man] (https: // en. wikipedia.org/wiki/Dead_man%27s_switch). To zatrzymuje / resetuje procesor, gdy tylko nie jest w stanie wykonać predefiniowanego uzgadniania (np. Aby rozładować pojemność, zanim zostanie w pełni naładowana)
mimosa
2015-04-09 00:24:11 UTC
view on stackexchange narkive permalink

W samolocie bezpieczeństwo jest ważniejsze niż jakikolwiek inny czynnik (po nim następuje optymalna waga zapewniająca oszczędność paliwa, a na trzecim miejscu jest całkowity koszt). Gdyby samolot nie był bezpieczny, latałoby za mało ludzi, a branża lotnicza upadłaby. Dlatego istnieją przepisy FAA i dlatego istnieje tak wiele przepisów dotyczących linii lotniczych. (kontrola bezpieczeństwa na lotnisku to kolejny temat, związany z bezpieczeństwem narodowym / politycznym z imigracją itp., więc kiedy mówimy `` bezpieczeństwo '' samolotu, mam na myśli inżynierskie)

Krytyczne systemy na pokładzie (tj. systemy, które są wymagane do latania samolotem) będą wymagały redundancji. Podobnie jak palnik w silniku odrzutowym ma 2 zapalniki, chociaż jeden wystarczy. Ponadto, jeśli jeden silnik ulegnie awarii, drugi silnik może latać samolotem, a komputer zrekompensuje nierównowagę sił lewo / prawo. Wiele systemów w samolocie opiera się na komputerze, więc musi on mieć „plan b” (nadmiarowość jest jednym z „planu b”).

To nie odpowiada na pełne pytanie. Wiem, że większość rzeczy w lotnictwie jest zbędna, ale cała ta nadmiarowość ma konkretny powód - pewien rodzaj awarii, który może sprawić, że redundancja będzie użyteczna. Pytałem, przed jakim trybem awarii chroni redundancja chipów.
FreeMan
2015-03-25 10:37:18 UTC
view on stackexchange narkive permalink

Ponieważ, mimo że teoria jest dobra, rzeczywistość jest taka, że ​​nie wszystkie komponenty komputera są równe.

Konkretny przykład z wczesnych lat 90 .: Intel wyprodukował procesor 486/33 (był całkiem nowatorski i niesamowicie szybko na cały dzień). Większość opuściła fabrykę w porządku, ale niektórzy mieli ezoteryczny błąd w FPU, który generował nieprawidłowe odpowiedzi. Dzisiejsze czasopisma były wypełnione obliczeniami, które można było wprowadzić do arkusza kalkulacyjnego, które dałyby X, jeśli twój procesor był dobry, lub Y, jeśli miał błąd.

Jeśli twój samolot leci z jednym z wadliwych procesorów, a akurat właściwy zestaw danych jest zbierany i wprowadzany do dowolnego programu sterującego lotem i napotyka ten błąd FPU, będziesz szczęśliwy, że pozostałe dwa procesory obliczyły prawidłową wartość i wykopały błędny jeden z pętli.

I think your example is misleading. First, I think you're actually talking about the [Pentium FDIV bug](https://en.wikipedia.org/wiki/Pentium_FDIV_bug). That was a design error, not a random manufacturing error. Every processor that was shipped had the bug, until the design was corrected. In that case, redundancy woudln't have helped: you'd just get multiple copies of the same wrong answer.
Jest to albo błąd Pentium FDIV, o którym wspomniał @DavidRicherby,, albo coś w rodzaju [problemu z podwójną sigmą 80386] (https://en.wikipedia.org/wiki/Intel_80386#Early_problems). Nie sądzę, żeby 486 kiedykolwiek miał problemy opisane w tej odpowiedzi.
AiliuowkrvCMTörling It sounds a lot like a conflation of the 386 double-sigma (affecting a seemingly random sample of manufactured units) and the Pentium FDIV bug (floating point and lots of public attention).
Regardless, it'd be be cheaper to thoroughly test every processor than to triplicate them.
@raptortech97 [Powiedz to NASA. Oni o tym nie wiedzą.] (Http://space.stackexchange.com/q/247/415)
AilipuofmlCMTörling that's about testing *designs* for radiation tolerance, not about running each production sample through basic operational tests
@DavidRicherby, może łączyć błąd Pentium FDIV z pochodzeniem [486SX] (https://en.wikipedia.org/wiki/Intel_80486SX), gdzie 486DX z wadliwym FPU miały wyłączony FPU i były sprzedawane jako liczby całkowite tylko procesory.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...