Question:
Pourquoi les ordinateurs de vol critiques sont-ils redondants?
raptortech97
2015-03-25 02:56:20 UTC
view on stackexchange narkive permalink

Au moins dans les avions de ligne, les ordinateurs véritablement critiques sont redondants. En règle générale, trois copies identiques des calculateurs de pilote automatique fonctionnent en parallèle et comparent les résultats; si un ordinateur n'est pas d'accord avec les deux autres, sa sortie est ignorée. Le système permet à certains processeurs d'être défectueux tout en maintenant le fonctionnement de l'ensemble du système.

Mais pourquoi? Je n'ai jamais entendu parler de microprocesseurs échouant soudainement. Bien sûr, il pourrait y avoir des erreurs de fabrication, mais celles-ci auraient été détectées à l'usine. Peut-être que le programme (et sa preuve) est faux, mais ce serait faux de la même manière à travers les processeurs. De même, une mauvaise entrée entraînerait une mauvaise sortie sur les trois ordinateurs. Contre quels types d'erreurs cette redondance protège-t-elle? Les microprocesseurs font-ils parfois des erreurs de calcul?

Si un microprocesseur est surchauffé ou surchargé et tombe en panne spontanément, je m'attendrais à ce qu'il cesse de faire quoi que ce soit et ne produise aucune sortie. Pour faire face à ce type de panne, vous voudriez avoir un processeur de sauvegarde, mais vous n’avez pas besoin de comparer les sorties de trois ordinateurs - toute sortie produite serait considérée comme correcte, vous seriez donc heureux d’utiliser directement le sortie de tout processeur qui produisait une sortie.

En relation: La réponse à À quoi servent les pilotes automatiques multiples? dit simplement «redondance» avant d’expliquer comment cela est réalisé.

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.
AiligbjkcnCMT I know the Shuttle had backup software ("design diversity"), but Wikipedia claims this practice is becoming less common.
Peut-être que je suis hors de la boucle depuis environ 20 ans. BTW, je suis un ingénieur logiciel maintenant et j'ai vu des processeurs échouer et, plus souvent, des puces RAM échouent.
@Simon Mais la RAM peut avoir ECC, non? Dans le pire des cas, la duplication de la RAM est beaucoup plus facile et moins coûteuse que la duplication de l'ordinateur entier. La défaillance du processeur est beaucoup plus préoccupante. Pensez-vous que vous seriez en mesure d'écrire une réponse sur la façon dont les processeurs échouent?
Ma question est essentiellement la même que celle que je viens de mentionner. Dois-je fermer ceci comme un double de l'autre, puis ajouter une prime à l'autre? Dois-je modifier l'autre question pour me concentrer sur la façon dont la redondance est obtenue, pour mieux correspondre à la réponse?
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.
AilierawmcCMT Autopilot is not that critical; the plane can be flown by hand. The really critical systems are fly-by-wire controls. In Airbus they run on pairs of dissimilar boards (i386 and m68k) with independently written software that cross-check each other, these pairs are multiplied for fail-over and there is independent set for primary flight controls (elevator and aileron) and another for alternate (spoilers and horizontal stabilizer), so if either fails the other can still control both pitch and roll. I believe Boeing system on 777 and 787 is similar.
AiliaxjprxCMT I agree that the autopilot is not usually critical, but a failure during a Cat III autoland is considered catastrophic.
Je trouve que le choix d'utiliser 3 est un peu étrange. Pour faire face à l'un d'entre eux en échec de manière arbitraire, vous avez besoin d'une résilience byzantine, qui ne peut être obtenue avec moins de 4.
AilicsshxkCMT I might be wrong, but I think that's only when messages can be forged. With dedicated physical connections, you can't really forge messages.
@raptortech97 L'analyse des systèmes sans résilience byzantine suppose que chaque nœud fonctionne parfaitement ou a complètement cessé de communiquer. Il suffit d'un seul bitflip aléatoire pour invalider l'analyse de tels systèmes.
AilidgblflCMT 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.
AiliukxxewCMT It is only solvable if you assume that the faulty node stops sending any messages. If a single node fails in a way causing it to send inconsistent messages, you lose all guarantees.
@kasperd [continuons cette discussion dans le chat] (http://chat.stackexchange.com/rooms/22267/discussion-between-raptortech97-and-kasperd).
N'as-tu pas entendu parler du bon vieux Murphy? `Tout ce qui peut mal tourner ira mal '
[Oui, les microprocesseurs font parfois des calculs erronés.] (Http://en.wikipedia.org/wiki/Pentium_FDIV_bug)
"* Je n'ai jamais entendu parler de microprocesseurs échouant soudainement *". C'est parce que vous n'êtes pas familier avec l'électronique. Demandez [ici] (http://electronics.stackexchange.com/) et vous serez éclairé. De plus, un ordinateur de vol n'est pas uniquement constitué d'un CPU / MCU. Clavier, écran, connecteurs, mémoire, horloge, autres puces, autres composants électroniques, bloc d'alimentation ... nommez-le.
Cette question est mal exprimée - terriblement. L'enquêteur semble vouloir dire "licenciement" des ordinateurs de vol. Mais ce qu'il demande en fait est _pourquoi sont-ils obsolètes? _
Douze réponses:
pjc50
2015-03-25 16:54:16 UTC
view on stackexchange narkive permalink

Modes de défaillance à prendre en compte:

  • Surchauffe. Cela modifie les propriétés de synchronisation de la puce et entraîne finalement une erreur. Cela peut se manifester par des erreurs sur un seul bit au milieu d'un fonctionnement apparemment normal; il se plantera éventuellement , mais peut d'abord générer des données incorrectes.
  • Dégâts d'eau. Se manifeste comme une résistance parasite sur la carte et peut vous amener à mal interpréter les bits comme étant hauts ou bas. Il peut s'agir de boîtiers qui fuient, de condensation, etc.
  • Interférences électromagnétiques. (Le système est censé résister à cela, mais cela vaut la peine d'y réfléchir.)
  • Problèmes de connexion physique. Soit pendant la construction (défauts de soudure), soit induits par la suite (chaleur, vibrations). Les fissures microscopiques dans les planches ou les joints peuvent passer le contrôle qualité mais entraîner des défauts intermittents. Encore une fois, cela peut vous perdre un seul morceau à la fois. Ceci est lié au problème de "l'anneau rouge de la mort" sur Xbox.
  • Panne d'autres composants. Les condensateurs sont le suspect habituel; électrolytique, tantale, céramique ont tous des modes de défaillance différents. Encore une fois, cela peut aboutir à un système qui fonctionne principalement mais qui est enclin à mal interpréter les valeurs marginales ou souffre de dérive temporelle.
  • Bizarre science des matériaux ( "Purple plague", moustaches en étain dues à une soudure sans plomb)
  • Le contrôle qualité de la pièce peut ne pas être à la hauteur des normes que vous attendez (les fournisseurs expédient des pièces de qualité inférieure avec une fausse étiquette de «qualité aérospatiale»). Difficile à détecter même après que cela se soit produit.

Il est important de reconnaître que dans les systèmes numériques à grande vitesse, vous n’obtenez pas un «un» et un «zéro» bien nets, vous obtenez une série de les fronts montants et descendants qui sont maculés par la capacité parasite et l'inductance du câblage. Ceci est intrinsèquement vulnérable à une mauvaise interprétation dans des conditions électriques marginales.

Wow, merci pour le grand détail! Je tiens à noter que j'ai du mal à croire que les pièces n'auraient pas été conformes aux normes. Dans l'aviation, la conception originale et chaque pièce de rechange devaient être certifiées FAA, et il y a une grande trace papier pour tout suivre. L'industrie des pièces détachées factices est plutôt petite de nos jours.
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
(Anecdotally I think the majority of "worked in QA fails early in production" faults are mechanical failures of solder joints; I believe aviation/MILSPEC used to prefer wire-wrap for exactly this purpose, but that's no longer practical with tiny packages)
C'est la meilleure réponse. Le fait est que les processeurs _peuvent_ produire de mauvaises réponses et _ souvent_ le faire_ lorsqu'ils sont utilisés en dehors de leur tension / température / etc. gammes parce que cela perturbe les horaires. Une différence de temps de picosecondes peut vous amener à lire la mauvaise valeur sur une ligne. De même, une très petite différence de tension peut entraîner la lecture d'une valeur comme 1 au lieu de 0 ou vice versa. C'est pourquoi, lorsque les gens testent des overclockings, ils exécutent des tests de rodage qui font des calculs le plus rapidement possible pendant des heures et surveillent les mauvaises réponses.
Pour ce qui est de dire qu'il finira par planter ... il pourrait éventuellement planter, ou il pourrait simplement continuer à produire une mauvaise sortie. Lorsque les processeurs deviennent trop chauds, par exemple, ils continuent souvent à exécuter leur code toute la journée tout en produisant de mauvaises réponses, en particulier si un ou plusieurs ALU ou FPU fonctionnent hors spécifications, mais le décodeur d'instructions ne l'est pas (ce qui n'est pas terriblement mode de défaillance inhabituel.)
Et [latchup] (https://en.wikipedia.org/wiki/Latchup). Si de rien d'autre, alors des rayons cosmiques (comme la réponse de RedGrittyBrick l'a mentionné).
Antzi
2015-03-25 10:47:28 UTC
view on stackexchange narkive permalink

Comme une autre réponse l'a souligné: un processeur peut échouer. Soit partiellement (donnant des réponses erronées), soit totalement.

De plus, tous les ordinateurs sont soumis à des radiations cosmiques qui peuvent de temps en temps basculer un peu en mémoire (en plus d'autres sources d'erreur comme le court-circuit,. ..). C'est pourquoi les expériences scientifiques et les serveurs de longue durée utilisent la mémoire ECC. Les vaisseaux spatiaux utilisent également des processeurs renforcés spécifiques pour limiter cet effet car ils sont moins protégés contre de telles interférences. Les avions volent à haute altitude. et sont soumis à plus de ces interférences que votre ordinateur terrestre.

Même si l'événement de ce qui se produit est très rare (mais pas inconnu), vous DEVEZ vous assurer que les résultats sont précis à 100%. Un bit retourné pourrait changer le comportement de votre avion de manière imprévisible, comme inverser les commandes, inverser la loi de protection de l'enveloppe de vol, ...

Non seulement le rayonnement cosmique peut basculer un peu dans la mémoire, mais il peut également basculer un peu dans le processeur. Maintenant, ECC pour la mémoire a toujours du sens car la mémoire a beaucoup plus de bits, mais le risque existe toujours pour les CPU.
Oui, il y avait de la mémoire ECC ET des processeurs renforcés :)
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.
À titre de comparaison, il y a plus de rayonnement de fond dans un avion de passagers typique à l'altitude de croisière qu'il n'y en a aujourd'hui au point zéro à Hiroshima.
C'est ce qu'on appelle un événement unique bouleversé. Il y aura souvent 3 copies des mêmes données stockées en mémoire ainsi qu'une autre unité à prendre en charge en cas de panne critique.
RedGrittyBrick
2015-03-25 14:17:44 UTC
view on stackexchange narkive permalink

Pourquoi les ordinateurs de vol critiques sont-ils redondants?

Logiciels

Un point qui a été oublié est que les systèmes redondants sont souvent des conceptions indépendantes, en particulier le logiciel. Cela protège contre les défauts de conception (ou les bogues logiciels) qui pourraient autrement causer des problèmes dans des combinaisons de circonstances rares.

Matériel

Même si un microprocesseur est très fiable, il existe un certain nombre de facteurs qui peuvent être pertinents

  • les aéronefs volent à haute altitude où l'atmosphère offre moins de protection contre les rayons cosmiques. Cela affecte non seulement la santé de l’équipage, mais peut également interférer avec les appareils électroniques.
  • Les systèmes avioniques sont composés de plus que de simples microprocesseurs, il y en a certainement également d'autres dispositifs, plus sujets aux pannes, tels que les condensateurs. Il existe d'innombrables façons dont l'électronique peut échouer, par ex. défaillance de la mise à la terre induite par les vibrations entraînant des interférences sur les lignes de données (par exemple, à partir de capteurs analogiques).

Je n'ai jamais entendu parler de microprocesseurs en panne soudaine. strong>

Fiabilité ≠ Sécurité

  • De nombreux accidents se produisent sans aucune «défaillance» des composants
    • Causés par l'équipement fonctionnement en dehors des paramètres et des délais sur lesquels reposent les analyses de fiabilité.
    • Causé par des interactions de composants fonctionnant tous conformément aux spécifications.
    • Les composants hautement fiables ne sont pas nécessairement sûrs

De Nancy Leveson, MIT, via UCSD

"Je n'ai jamais entendu parler de microprocesseurs échouant soudainement." J'ai eu un échec dans un bureau une fois. Je tape n'importe quoi, et l'écran est devenu noir. Après les tests habituels, nous l'avons renvoyé, ils ont dit que nous avions besoin d'un nouveau processeur.
People who've never heard of CPUs failing have never gone through the AMD Athlon/Pentium4 days where frying a CPU wasn't uncommon
Merci de mentionner qu'effectivement, le logiciel n'est ** pas ** identique, mais que différentes équipes écrivent pour un matériel différent, mais avec les mêmes spécifications. La question initiale est pour le moins trompeuse.
a CVn
2015-03-25 17:51:53 UTC
view on stackexchange narkive permalink

Je sais que cette question a déjà reçu une poignée de réponses, mais aucune d'elles ne semble aborder la question de savoir pourquoi il y a trois systèmes dans l'ensemble redondant, plutôt que deux.

Tout d'abord, comme l'ont souligné Simon, Jan Hudec et RedGrittyBrick, les designs ne sont pas du tout identiques. En effet, ils sont souvent complètement différents pour une très bonne raison: la probabilité qu’un problème donné affecte tous les systèmes redondants, et surtout affecte tous les systèmes redondants de la même manière, va du "petit" au "tout à fait minuscule à la limite de l'inexistant". Comparez À quel point les ordinateurs de contrôle de vol redondants sont-ils différents?

Deuxièmement, pour pourquoi il y a trois systèmes dans chaque configuration redondante. Lorsque tout fonctionne correctement et que l'avion est en vol régulier, pour une certaine valeur et un ensemble donné d'entrées, tous les systèmes signalent qu'une correction de 0 (quelle que soit l'unité) est nécessaire. À ce stade, il n'y a pas de problème et les ordinateurs servent simplement à maintenir l'état actuel. Maintenant, l'un des systèmes de composants ne parvient pas à faire son travail correctement pour quelque raison que ce soit, et commence à signaler qu'une correction de +50 unités est nécessaire. Autrement dit, l'ensemble des réponses passe de [0,0,0] à [0,0, + 50]. Deux systèmes sont d'accord et le troisième rapporte quelque chose d'autre, donc nous pouvons probablement ignorer en toute sécurité la valeur aberrante et opter pour les deux systèmes qui rapportent la même chose: traiter le résultat comme [0,0, incorrect] et ignorer le résultat incorrect lors de l'enregistrement des détails techniques et affichant une sorte d'avertissement proéminent indiquant que les systèmes doivent être examinés dès que possible. Mais que se passe-t-il si nous n'avions que deux systèmes au départ et que l'un des deux échoue de la même manière? La correction déterminée nécessaire va de [0,0] à [0, + 50]. Vite maintenant: quelle valeur est correcte? Devez-vous maintenir l'état ou corriger de +50?

À ce stade, il n'y a aucun moyen de savoir si la correction par 0 ou +50 est la bonne marche à suivre. Vous pouvez prendre une moyenne, mais utiliser une moyenne de deux nombres (dont l'un est probablement incorrect) pourrait en fait être pire que l'une ou l'autre des valeurs en soi.

En ajoutant un troisième système à l'ensemble redondant, vous ajoutez un coupe-circuit pour la situation où il y a un système défectueux. Ce n'est que si deux des trois systèmes commencent à mal fonctionner en même temps que vous avez un problème réel, et si l'avion a des problèmes tels que deux systèmes redondants sur trois donnent des sorties erronées, alors vous avez probablement de sérieux problèmes pour commencer. .

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

La plupart des réponses ont tourné autour du potentiel d'erreurs matérielles informatiques et autres choses de cette nature. Bien que tout cela soit vrai, personne n'a mentionné ce que les ordinateurs regardent réellement.

Disons que vous êtes en approche, que vous vous préparez à faire un autoland CAT III, et que vous n'avez que deux systèmes informatiques. Les deux systèmes informatiques comparent les systèmes radioaltimétriques n ° 1 et n ° 2. Seulement, il y a un dysfonctionnement avec l'un des systèmes de radioaltimètre causant un écart d'une valeur arbitraire qui n'est pas dans les limites.

Comment l'ordinateur sait-il lequel est erroné? Un ordinateur regarde le système radioaltimétrique # 1 et voit 500 pieds. L'autre regarde le système # 2 et voit 1000 pieds. Lequel est juste et lequel est faux? Comment l'ordinateur pourrait-il prendre cette décision?

Entrez le troisième ordinateur. Si la valeur de ce qu'il voit concorde avec celle de l'un des deux autres ordinateurs, il peut effectivement "voter" la lecture invalide "hors de l'île".

Je dois noter que la plupart de ces ordinateurs ont entre deux et quatre processeurs, tous comparant leurs propres résultats. C'est la redondance INTERNE pour éviter les pannes matérielles, mais le fait d'avoir de nombreuses comparaisons croisées de systèmes externes est en grande partie la raison pour laquelle un troisième système existe.

Note: En tant que mécanicien A&P, 9 fois sur 10 c'est l'un des systèmes externes ayant échoué (radioaltimètre, erreur de comparaison MMR / ILS, etc ...) qui provoque une dégradation des capacités - PAS le ordinateur lui-même.

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

Les ordinateurs échouent, spontanément, tout le temps. Vous n'êtes pas habitué à cela car vous n'avez pas utilisé beaucoup d'ordinateurs. Mais pensez à quelqu'un comme Google, qui gère d'énormes centres de données contenant des milliers d'ordinateurs. Le logiciel qui exécute Google est conçu autour de l'hypothèse explicite que les ordinateurs échouent parce que cela se produit plusieurs fois par jour. Maintenant, un avion ne contient pas beaucoup d'ordinateurs, mais ceux qu'il contient sont essentiels à la sécurité. Ils sont donc dupliqués pour s'assurer que leur échec ne pose pas de problème.

I think the OP was especially asking about the fact that there are three which compare instead of just two in the case the hardware dies.
D'après tout ce que j'ai entendu sur les systèmes de Google, ils sont conçus pour gérer la panne totale de n'importe quel ordinateur, pas les ordinateurs qui se comportent mal
Hmm. I think dealing with malfunction rather than outright failure is implicit in my answer but you're both right that it's not very well tailored to the question. I'll have a think and either improve or delete it.
Google's systems are built around fail-and-retry as that's built into all the Internet protocols. Other large systems are similar and even embrace "crash-only" operation (see Netflix "chaos monkey"). This isn't appropriate for safety-critical real-time systems. It's an interesting contrast between a cheap system which in practice works nearly all the time versus a much harder to develop and more expensive system which can offer design guarantees.
Dave
2015-03-25 05:36:36 UTC
view on stackexchange narkive permalink

Si nous considérons cela d'un point de vue strictement technique, les microprocesseurs comme tout ont une durée de vie en cycle. D'une manière générale, c'est très long, et le PC à partir duquel vous publiez ce message sera probablement obsolète bien avant qu'il n'atteigne la durée de vie du cycle. Bien qu'un microprocesseur n'ait pas de pièces mobiles, il prend les entrées de divers capteurs. Je ne peux que supposer que les entrées sont fusionnées d'une manière ou d'une autre, mais cela ne signifie pas que les pointes sont complètement éliminées et isolées si elles se produisent. Pour ce que ça vaut, même des surtensions relativement petites feront frire un microprocesseur. En gardant cela à l'esprit, pour faire preuve de prudence, plusieurs systèmes sont utilisés. Avec la taille de plus en plus réduite de la technologie, il est devenu plus facile et moins coûteux de transporter une pièce de rechange, donc du point de vue des ventes, la tranquillité d'esprit est là. Encore une fois, il vaut mieux l'avoir et ne pas l'utiliser que de ne pas l'avoir quand vous en avez besoin.

Pour répondre directement à votre question, je travaille depuis longtemps dans le domaine des microprocesseurs, des micro-contrôleurs et autres. Pendant ce temps, j'ai eu peut-être deux ou trois échecs spontanés, généralement liés à la chaleur. Dans un avion, cela peut ne pas sembler être un problème, mais en fait, un froid extrême peut causer des problèmes ainsi qu'une chaleur extrême en ce qui concerne l'électronique. Cela étant dit, j'ai grillé d'innombrables unités en les frappant avec des entrées surchargées. Disons que votre avion a été touché par l'éclairage (je sais que les compagnies aériennes modernes sont protégées contre cela) mais pour des raisons d'argumentation, disons qu'un sol était mauvais: cela porterait facilement un toast à une unité.

Remarque: il est plus courant que les puces / lecteurs de mémoire tombent en panne de nos jours. C'est quelque chose que vous ne savez peut-être jamais car la plupart des ordinateurs modernes peuvent gérer la mémoire morte, que ce soit sur le disque ou dans la mémoire système.

L'avionique sera généralement dans la baie avionique sous le cockpit, ou dans le cockpit lui-même, donc le froid extrême ne sera pas un problème, mais avec un refroidissement inadéquat, ils pourraient surchauffer. Ce que je n'ai pas précisé, c'est que si un microprocesseur échoue spontanément, il devrait être possible de le détecter et de passer à une sauvegarde. Le système utilisé compare les trois sorties, ce qui implique qu'un microcontrôleur pourrait produire une sortie incorrecte, au lieu de simplement ne pas produire une sortie.
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.
AilicjbqxeCMT 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?
Encore une fois, je suis d'accord, mais je faisais simplement remarquer qu'il est possible de gérer une mauvaise mémoire (pas que je conseille de le faire en vol).
AiligtruayCMT 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.
AiliunnkdeCMT 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.
AilizyzwwzCMT 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

Concernant la redondance spécifique, l ' environnement d'installation de ces systèmes est probablement le facteur le plus important. Non seulement de nombreux systèmes sont entassés étroitement ensemble dans des espaces restreints, mais le flux d'air y est souvent très limité. La chaleur est un grand destructeur de nombreux microprocesseurs. Les avions vibrent également beaucoup en raison des moteurs qui tournent, des turbulences en vol et du simple atterrissage. Des joints de soudure médiocres et des travaux de sertissage inférieurs à la normale ou une coque arrière de connecteur lâche, et vous avez une mauvaise connexion, ou pire, une connexion intermittente .

Sur la redondance en général, si vous faire l'expérience d'un BSOD au travail, comparativement, ce n'est pas grave. Vous avez peut-être perdu le document sur lequel vous travailliez, mais c'est à peu près tout. Si les systèmes d'avion s'éteignent, vous avez un réel problème. C'est difficile à réaliser, mais la redondance existe car la vie de centaines de personnes en dépend .

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

Le risque de défaillance du processeur est certes très faible, mais pas nul. En cas de panne du processeur, que se passe-t-il pendant le temps de transition entre une panne et une fonctionnalité complète après le redémarrage? Avec un événement rare comme celui-ci, pourrions-nous acquérir suffisamment d'expérience pour être sûrs d'avoir testé en toutes circonstances? Nous parlons ici des nombres < $ 10 ^ {- 9} $.

Les sauvegardes sont sujettes à des échecs cachés. La sauvegarde n'est normalement pas utilisée et n'est activée que lorsque cela est nécessaire - mais a quelque chose de rouillé, ou a un moule funky niché dans un endroit chaud et confortable et provoque un court-circuit lors de l'activation? Murphy hante toujours les applications aérospatiales. La sauvegarde peut être testée avant le décollage, mais que se passe-t-il si elle secoue et le processeur principal tombe en panne? Les chances sont minces, mais tous les accidents majeurs de nos jours sont causés par des chaînes improbables d'événements comme celui-ci.

La redondance est utile car elle démontre en permanence que les principaux appareils fonctionnent correctement et elle est utilisée pour des circonstances de vol critiques . Des systèmes de secours peuvent être utilisés si vous pouvez vous passer de l'appareil principal, ou s'il est garanti que le secours fonctionnera toujours, comme l'actionnement manuel des commandes de vol.

Un pilote automatique en croisière n'est pas vol critique et peut être déconnecté sans conséquences graves. Lors d'un atterrissage CAT III où la piste ne peut être observée qu'une fois que vous roulez dessus, elles sont absolument vitales. Vous ne voulez pas que le pilote automatique se déconnecte à 10 mètres au-dessus de la piste, pas de visibilité, vent latéral en rafales - il n'y a pas le temps d'engager la sauvegarde.

J'apprécie la réponse. Notez que j'utilise les pronoms they / them, pas he / him.
J'ai remarqué et modifié.
"* Un pilote automatique en croisière n'est pas critique pour le vol, et peut être déconnecté sans conséquences graves *", en effet vrai en théorie, mais il a été une fois mortel lorsqu'il est associé à un échec d'indication de vitesse.
@mins En réalité, chaque événement comme le désengagement du pilote automatique pendant la croisière se voit attribuer un niveau de sécurité et doit répondre à ce niveau de sécurité. Le niveau de redondance et de rigueur est ajusté pour répondre au niveau de sécurité requis. Le désengagement du pilote automatique pendant la croisière est grave, oui, mais pas "catastrophique" et est donc marqué lors de l'analyse de sécurité comme un problème "mineur" ou "majeur". La même analyse de sécurité peut marquer la déconnexion du pilote automatique et l'échec de l'indication de la vitesse comme un problème commun avec des conséquences plus importantes s'il y a une interaction significative entre les deux.
NPSF3000
2015-03-26 03:24:11 UTC
view on stackexchange narkive permalink

Si un microprocesseur est surchauffé ou surchargé et tombe en panne spontanément, je m'attendrais à ce qu'il cesse de faire quoi que ce soit et ne produise aucune sortie.

Avez-vous déjà overclocké un processeur ou regardé un vieux morceau de matériel meurt? Vous pouvez obtenir toutes sortes d'artefacts étranges pendant que le processeur est toujours en cours d'exécution.

Les processeurs utilisés dans les tâches critiques pour la sécurité sont associés à un [chien de garde] (https://en.wikipedia.org/wiki/Watchdog_timer), un système (simple) similaire à l'industrie ferroviaire [dead man] (https: // en. wikipedia.org/wiki/Dead_man%27s_switch). Cela arrête / réinitialise le CPU dès qu'il n'est pas en mesure d'effectuer une prise de contact prédéfinie (par exemple, pour décharger une capacité avant qu'elle ne soit complètement chargée)
mimosa
2015-04-09 00:24:11 UTC
view on stackexchange narkive permalink

Dans un avion, la sécurité est plus importante que tout autre facteur (après cela vient le poids optimal pour l'efficacité énergétique, et le coût global est le troisième). Si l'avion n'était pas sûr, il n'y aurait pas assez de gens qui voleraient et l'industrie aérienne s'effondrerait. C'est pourquoi il y a des règlements de la FAA, et c'est pourquoi il y a tant de règles pour les compagnies aériennes. (le contrôle de sécurité de l'aéroport est un autre sujet, lié à la sécurité nationale / politique avec l'immigration, etc., donc quand nous disons `` sécurité '' de l'avion, je veux dire au niveau de l'ingénierie)

Systèmes critiques à bord (ie systèmes qui sont nécessaires pour piloter l’avion) ​​auront besoin de redondance. Comme le brûleur dans le moteur à réaction a 2 allumeurs, même si un suffit. De plus, si un moteur tombe en panne, l'autre moteur peut piloter l'avion et l'ordinateur compensera le déséquilibre des forces gauche / droite. De nombreux systèmes dans l'avion dépendent de l'ordinateur, il doit donc avoir un 'plan b' (la redondance est l'un des 'plan b')

Cela ne répond pas à la question complète. Je sais que la plupart des choses dans l'aviation sont redondantes, mais toute cette redondance a une raison spécifique - un mode de défaillance qui pourrait rendre la redondance utile. Je demandais sur quel mode de redondance des puces de panne protège.
FreeMan
2015-03-25 10:37:18 UTC
view on stackexchange narkive permalink

Parce que, bien que la théorie soit bonne, la réalité est que tous les composants informatiques ne sont pas égaux.

Un exemple spécifique du début des années 90: Intel a produit le processeur 486/33 (il était assez avancé et incroyablement rapide pour la journée). La plupart ont très bien quitté l'usine, mais certains avaient un bogue ésotérique dans le FPU qui générait des réponses incorrectes. Les magazines du jour étaient remplis de calculs que vous pouviez mettre dans votre feuille de calcul qui produiraient X si votre CPU était bon, ou Y s'il avait le bogue.

Si votre avion fonctionne avec l'un des les processeurs défectueux qu'il contient, et juste le bon ensemble de données est collecté et introduit dans l'un des programmes de contrôle de vol et se heurte à ce bogue FPU, vous serez heureux que les deux autres processeurs aient calculé la valeur correcte et lancé le un errant hors de la boucle.

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.
C'est soit le bogue Pentium FDIV comme mentionné par @DavidRicherby,, soit quelque chose comme le [problème 80386 double-sigma] (https://en.wikipedia.org/wiki/Intel_80386#Early_problems). Je ne pense pas que le 486 ait jamais eu le genre de problèmes décrits dans cette réponse.
AilixtdpjuCMTö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.
AilicnwwzvCMT [Tell that to NASA. They don't know about it.](http://space.stackexchange.com/q/247/415)
@MichaelKjörling, il s'agit de tester * les conceptions * pour la tolérance aux rayonnements, pas d'exécuter chaque échantillon de production à travers des tests opérationnels de base
@DavidRicherby, l'OP pourrait confondre le bogue Pentium FDIV avec l'origine du [486SX] (https://en.wikipedia.org/wiki/Intel_80486SX), où les 486DX avec un FPU défectueux avaient le FPU désactivé et étaient vendus comme un entier- uniquement les processeurs.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...