題:
為什麼關鍵的飛行計算機是多餘的?
raptortech97
2015-03-25 02:56:20 UTC
view on stackexchange narkive permalink

至少在飛機上,真正重要的計算機是多餘的。通常,自動駕駛儀計算機的三個相同副本並行運行並比較結果。如果一台計算機與其他兩台計算機不同意,則忽略其輸出。該系統允許某些處理器出現故障,同時保持整個系統的運行。

為什麼?我從未聽說過微處理器突然發生故障。當然,可能會有製造錯誤,但這些錯誤會在工廠被發現。也許程序(及其證明)是錯誤的,但是在處理器之間以相同的方式將是錯誤的。同樣,錯誤的輸入將導致所有三台計算機上的錯誤輸出。這種冗餘可以防止什麼樣的錯誤?微處理器有時是否只是在做數學上的錯誤?為了解決這種故障,您需要一個備用處理器,但是您不需要比較三台計算機的輸出-假定產生的任何輸出都是正確的,因此您很樂意直接使用任何產生輸出的處理器的輸出。

相關:多個自動駕駛儀的目的是什麼?在進行說明之前簡單地說“冗餘”。

我將等待權威的答案,但是在我所涉及的系統上,這三台計算機運行的軟件不同,由獨立團隊生產,並被證明可以為相同的輸入生成相同的輸出。
@Simon我知道Shuttle擁有備份軟件(“設計多樣性”),但是Wikipedia聲稱這種做法正變得越來越不普遍。
可能是,我已經退出循環大約20年了。順便說一句,我現在是一名軟件工程師,並且看到處理器出現故障,更常見的是RAM芯片出現故障。
@Simon但是RAM可以具有ECC,對嗎?在最壞的情況下,複製RAM比複製整個計算機要容易得多,而且便宜得多。處理器故障更值得關注。您認為您能夠寫出有關處理器如何發生故障的答案嗎?
我的問題與我剛才鏈接的問題基本相同。我應該將其作為另一個的副本關閉,然後向另一個添加賞金嗎?我是否應該編輯另一個問題以關注如何實現冗餘以更好地匹配答案?
我認為您的問題是正確的,我對答案很感興趣。至於處理器如何失敗,這是不值得回答的。我從內存中看到了2。一個是風扇故障,芯片本身炸了,另一個是未知的。表現為越來越怪異的錯誤和藍屏,接著是完全失敗。 RAM幾乎肯定會具有ECC,但只能糾正一位錯誤並報告兩位錯誤。如果出現更多位失敗(這很容易發生物理錯誤),那麼ECC就沒有用了。
@raptortech97:自動駕駛儀並不那麼關鍵;飛機可以用手飛行。真正關鍵的系統是電傳操縱。在空中客車公司中,它們在成對的異種板(i386和m68k)上運行,並帶有相互交叉檢查的獨立編寫的軟件,這些成對的乘以進行故障轉移,並且主要飛行控制(電梯和副翼)有獨立的設置,另一組用於獨立的飛行控制。備用(擾流板和水平穩定器),因此如果其中一個發生故障,另一個仍然可以控制俯仰和橫滾。我相信波音777和787的系統是相似的。
@JanHudec我同意自動駕駛通常並不重要,但是在Cat III自動降落期間發生的故障被認為是災難性的。
我發現使用3的選擇有些奇怪。為了以任意方式處理其中之一的故障,您需要拜占庭式的彈性,而小於4則無法實現。
-1
@raptortech97對沒有拜占庭彈性的系統進行分析時,會假設每個節點運行狀況良好或已完全停止通信。只需要一個隨機的位翻轉就可以使此類系統的分析無效。
這不是在談論@kasperd。您建議的拜占庭抵抗性分析的類型基於以下假設:計算機可以說謊並偽造其他計算機的消息。如果您具有用於驗證身份的加密哈希,則該三方系統是可解決的。
@raptortech97僅當您假設故障節點停止發送任何消息時,才可以解決。如果單個節點發生故障而導致發送不一致的消息,則您將失去所有保證。
@kasperd讓我們[在聊天中繼續此討論](http://chat.stackexchange.com/rooms/22267/discussion-between-raptortech97-and-kasperd)。
你沒聽說過好老墨菲嗎? `任何可能出錯的地方都會出錯`
[是的,微處理器有時會做錯數學。](http://en.wikipedia.org/wiki/Pentium_FDIV_bug)
“ *我從未聽說過微處理器突然發生故障*”。那是因為您不熟悉電子產品。詢問[這裡](http://electronics.stackexchange.com/),您將得到啟發。此外,飛行計算機並非僅由CPU / MCU組成。鍵盤,顯示器,連接器,內存,時鐘,其他芯片,其他電子組件,電源單元...命名。
這個問題表達得很差,令人震驚。查詢者似乎是指飛行計算機_employ Redundancy_。但他實際上問的是_為什麼它們已過時?
十二 答案:
pjc50
2015-03-25 16:54:16 UTC
view on stackexchange narkive permalink

要考慮的故障模式:

  • 過熱。這會改變芯片的時序屬性,並最終導致錯誤。在看似正常的操作過程中,這可能表現為單位錯誤。它最終會崩潰,但可能會首先輸出錯誤數據。
  • 水災。表現為板上的寄生電阻,可能會導致您誤認為位是高還是低。可能是外殼漏水,結露等。
  • 電磁干擾。 (系統應該對此具有抵抗力,但是仍然值得考慮)。
  • 物理連接問題。在施工期間(焊接故障)或之後引起的(熱,振動)。木板或接縫中的細微裂紋可以通過質量檢查,但會導致間歇性故障。再一次,這可能一次讓您失去一點點。這與Xbox的“死亡紅圈”問題有關。
  • 其他組件失敗。電容器通常是可疑的。電解,鉭,陶瓷都有不同的失效模式。同樣,這可能會導致系統主要工作,但易於誤解邊際值或遭受時間漂移的影響。
  • 奇怪的材料科學(“紫色瘟疫”,由於無鉛焊料導致的錫須)
  • 零件質量檢查可能未達到您期望的標準(供應商以劣質的“航空級”標籤運送劣質零件)。

很重要的一點是要認識到,在高速數字系統中,您得不到很好的“一”和“零”,因此會得到一系列上升和下降沿會被佈線的寄生電容和電感所抹去。這天生就容易在邊際電氣條件下被誤解。

哇,謝謝你的詳細介紹!我確實要指出,我很難相信這些零件不會達到標準。在航空領域,原始設計和每個備件都必須獲得美國聯邦航空局(FAA)的認證,並且有大量的紙張痕跡可以追踪所有內容。如今,虛假的備件行業規模很小。
我來自電子行業,而不是航空行業,所以我不熟悉紙質記錄的工作原理,但是如果您想了解細節,您可能會發現這很有趣:http://www.bunniestudios.com/blog /?page_id = 1022
(有趣的是,我認為大多數“質量保證工作在生產初期都會失敗”的故障是焊點的機械故障;我相信航空/ MILSPEC曾經更傾向於為此目的使用繞線,但是對於小包裝不再可行)
這是最好的答案。一個簡單的事實是,CPU在超出其指定的電壓/溫度/等條件下運行時,會產生錯誤的答案,並且經常會出錯。範圍,因為它與時間混亂。皮秒的時間差會導致您從一行讀取錯誤的值。類似地,非常小的電壓差會導致將值讀取為1而不是0,反之亦然。這就是為什麼當人們測試超頻時,他們會運行老化測試,以便在數小時內盡可能快地進行數學運算,並註意錯誤的答案。
就說它最終會崩潰...可能會最終崩潰,或者它可能只會繼續產生不良的輸出。例如,當CPU變得過熱時,它們通常會整天快樂地繼續運行其代碼,同時產生錯誤的答案,尤其是如果一個或多個ALU或FPU的運行超出規範,但指令解碼器卻無法運行(這並不是很糟糕)罕見的故障模式。)
和[latchup](https://en.wikipedia.org/wiki/Latchup)。如果沒有別的,那麼來自宇宙射線(如RedGrittyBrick的回答所述)。
Antzi
2015-03-25 10:47:28 UTC
view on stackexchange narkive permalink

其他答案指出:CPU可能會發生故障。

此外,所有計算機都受到宇宙輻射的影響,該輻射有時會翻轉內存中的一些信息(此外還有短路等其他錯誤源)。 ..)。這就是為什麼科學實驗和運行時間較長的服務器使用 ECC內存的原因。太空飛船還使用特定的加固CPU來限制這種影響,因為它們不受此類干擾的影響。

即使發生這種情況非常少見(但並非聞所未聞),您也必須確保結果是100%準確的。翻轉一點可能會以無法預測的方式改變飛機的行為,例如反轉控件,反轉飛行包絡保護法則,...

宇宙輻射不僅可以翻轉內存中的一點,還可以翻轉CPU中的一點。現在,隨著存儲器具有更多的位,用於存儲器的ECC仍然有意義,但是CPU的風險仍然存在。
是的,那是ECC內存和加固的CPU了:)
我認為這是最重要的原因。如果僅擔心內存不足,我們可以將RAM加倍,但只有一個CPU。但是,如果宇宙射線將CPU中的錯誤位翻轉而未將CPU進行三倍運算,則結果可能是災難性的。
相比之下,典型的客機在巡航高度時的背景輻射要比今天廣島零地面時的背景輻射更多。
這稱為單事件失敗。通常,同一數據的3個副本存儲在內存中,並在發生嚴重故障時接管另一個單元。
RedGrittyBrick
2015-03-25 14:17:44 UTC
view on stackexchange narkive permalink

為何關鍵飛行計算機具有冗餘性?

軟件

缺少的一點是冗餘系統通常是獨立的設計,尤其是軟件。這樣可以防止在很少發生的情況組合下可能導致問題的設計錯誤(或軟件錯誤)。

硬件

即使微處理器是高度可靠的,也有很多可能與飛機相關的一些因素

  • 飛機在高空飛行,其中大氣層對宇宙射線的防護作用較小。這不僅影響機組人員健康,而且具有干擾電子設備的潛力。
  • 航空電子系統不僅由微處理器組成,而且肯定有還有其他更容易發生故障的設備-例如電容器。電子產品可能有數不清的故障方式,例如振動引起的接地故障導致對數據線的干擾(例如來自模擬傳感器的干擾)。

我從沒聽說過微處理器突然發生故障。 strong>

可靠性≠安全

  • 發生許多事故,沒有任何“故障”組件
    • 由設備引起在可靠性分析所依據的參數和時間限制之外進行操作。
    • 由均按照規范運行的組件相互作用引起的。
    • 高度可靠的組件不一定安全

來自麻省理工學院 Nancy Leveson,通過UCSD sup>

“我從未聽說過微處理器突然發生故障。”我一次在台式機上失敗了。我不管什麼都在打字,屏幕變黑了。經過常規測試後,我們將其退回,他們說我們需要一個新的CPU。
從未聽說過CPU出現故障的人從未經歷過AMD Athlon / Pentium4天的煎炸事件並不少見
感謝您提到軟件確實“不相同”,但是不同的團隊為不同的硬件編寫了相同的規格。至少可以說,最初的問題具有誤導性。
a CVn
2015-03-25 17:51:53 UTC
view on stackexchange narkive permalink

我知道這個問題已經收到了很少的答案,但是似乎沒有一個能解決為什麼冗餘集中有三個系統而不是兩個的問題。

首先,正如 Simon Jan Hudec RedGrittyBrick所指出的那樣,設計完全不同。確實,它們常常完全不同,這有很好的理由:任何給定問題將影響所有冗餘系統,並且尤其以相同方式影響所有冗餘系統的可能性,從“小”到“完全不存在”。比較冗余飛行控制計算機有何不同?

第二,關於為什麼每個冗餘設置中有三個系統。當一切正常,並且飛機處於穩定飛行狀態時,對於某些值和某些給定的輸入值,所有系統均報告需要校正0(無論任何單位)。在這一點上沒有問題,並且計算機僅用於維持當前狀態。現在,一個組件系統由於任何原因無法正常工作,並開始報告需要修正+50個單位。也就是說,響應集從[0,0,0]變為[0,0,+ 50]。兩個系統都同意,第三個系統報告了其他內容,因此我們可以放心地忽略異常值,並選擇兩個報告相同的系統:將結果視為[0,0,incorrect],並在記錄技術詳細信息時忽略不正確的結果,顯示某種顯著的警告,表明需要盡快檢查系統。但是,如果我們只有兩個系統,而其中兩個之一卻以相同的方式失敗,那該怎麼辦呢?確定的所需校正從[0,0]變為[0,+ 50]。現在快說:哪個值正確?您應該維持狀態還是將其修正為+50?

到那時,沒有辦法知道是將0校正還是+50校正是正確的做法。您可以取一個平均值,但使用兩個數字的平均值(其中一個可能不正確)實際上比每個值本身都更糟糕。

通過添加一個將第三個系統添加到冗餘集,則在出現一個系統故障的情況下添加一個決勝分局。只有當三個系統中的兩個同時開始出現故障時,您才有實際問題,並且如果飛機出現這樣的問題,即三個冗餘系統中有兩個給出錯誤的輸出,那麼您可能會遇到一些嚴重的麻煩

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

大多數答案都圍繞著潛在的計算機硬件錯誤和此類問題而展開。儘管這都是真的,但沒有人提到計算機的實際用途。

假設您正在使用方法,準備進行CAT III自動著陸,並且您只有兩台計算機系統。兩種計算機系統都比較了#1和#2無線電高度儀系統。僅無線電高度計系統之一發生故障,導致某些任意值的差異不在限制之內。

計算機如何知道哪一個是錯誤的?一台計算機查看無線電高度儀系統#1的高度為500英尺。另一台計算機查看系統#2的高度為1000 ft。哪一個是正確的,哪個是錯誤的?計算機可能如何做出決定?

輸入第三台計算機。如果所看到的值與其他兩台計算機的值相稱,則可以有效地“投票”無效的“離島”讀數。

我應該注意,這些計算機中大多數都具有兩個到四個處理器之間的任意位置,它們都比較它們自己的結果。這是內部冗餘以避免硬件故障,但是外部系統的大量交叉比較在很大程度上是第三個系統存在的原因。

注意:作為一名A&P機械師,十分之九的外部系統發生故障(無線電高度計,MMR / ILS比較不正確等),從而導致性能下降-並非計算機本身。

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

計算機始終自發地發生故障。您不習慣這種做法,因為您沒有使用很多計算機。但是考慮一下像Google這樣的人,他運行著包含數千台計算機的大型數據中心。運行Google的軟件是基於這樣的明確假設而設計的:計算機每天都會發生多次故障,因此會發生故障。現在,一架飛機並沒有太多的計算機,但是它包含的計算機對安全至關重要。因此,將它們複製以確保其失敗不會引起問題。

我認為OP尤其在問這樣一個事實:在硬件死機的情況下,有三個比較而不是兩個。
從我所聽到的有關Google系統的所有信息中,它們旨在處理任何計算機的整體故障,而不是處理行為異常的計算機的全部故障。
嗯我認為在我的回答中隱含了處理故障而不是徹底的故障,但您都說得很對,因為它不是非常適合該問題。我會考慮並改善或刪除它。
Google的系統是基於失敗和重試的,因為它已內置在所有Internet協議中。其他大型系統與此類似,甚至包含“僅崩潰”操作(請參閱Netflix“混亂的猴子”)。這不適用於對安全至關重要的實時系統。這是一個廉價的系統,它實際上幾乎可以一直工作,而開發難度更大的系統和可以提供設計保證的更昂貴的系統之間,是一個有趣的對比。
Dave
2015-03-25 05:36:36 UTC
view on stackexchange narkive permalink

如果從嚴格的工程學角度來看這一點,那麼像任何東西一樣的微處理器都具有循環壽命。通常來說,它很長,您發布此PC的PC很可能會過時,直到達到生命週期為止。儘管微處理器沒有活動部件,但它確實從各種傳感器獲取輸入。我只能假設輸入以某種方式融合,但這並不意味著尖峰確實消除並隔離。就其價值而言,即使相對較小的浪湧也會使微處理器炸毀。請記住,要謹慎使用多個系統。隨著技術規模的不斷縮小,攜帶備件變得越來越容易和便宜,因此從銷售的角度來看,您可以放心。同樣,擁有它而不使用它比在需要時沒有它更好。

要直接解決您的問題,我已經在微處理器,微控制器等領域工作了很長時間。在那段時間裡,我可能自發地發生了兩到三個故障,通常與熱量有關。在飛機上,這似乎不是問題,但實際上,對於電子產品,極冷會導致問題以及極熱。話雖這麼說,我已經用超負荷輸入擊中了無數單位。假設您的飛機被照明擊中(我知道現代航空公司對此有所保護),但出於爭論的緣故,我們要說一個地面不好:這很容易舉起一個單位。

側面說明:如今,內存芯片/驅動器發生故障的可能性更大。這可能是您永遠不會知道的,因為大多數現代計算機都可以處理磁盤或系統內存中的死內存。

航空電子設備通常位於駕駛艙下方的航空電子設備艙中,或者位於駕駛艙本身中,因此不會出現極端寒冷的情況,但是如果冷卻不充分,它們可能會過熱。我沒有澄清的是,如果微處理器自發地發生故障,應該可以檢測到該故障並切換到備份。使用中的系統會比較這三個輸出,這意味著微控制器可能會產生錯誤的輸出,而不是僅僅無法產生任何輸出。
我發現“最多現代計算機可以處理內存不足”這一說法可疑。從嚴格意義上來說,也許是“如果一個內存單元壞了,它不會立即導致計算機崩潰”,但是一旦該內存實際用於某件事,它將**導致不穩定的操作。在某種程度上,節省的好處是,在現代PC中,沒有積極使用RAM的最大份額。它用於緩存。如果您無法檢測到問題(這實際上意味著您使用的是非ECC RAM,而大多數台式機系統則沒有),那麼這同樣很糟糕。
這是不正確的,PC能夠跳過並忽略磁盤上的壞扇區,請參見此處http://en.wikipedia.org/wiki/Bad_sector,同樣,Linux內核現在支持badram和badmem,它們能夠告訴系統跳過損壞的地址,這就是我所引用的地址。但是,您會錯記錯的內存會導致行為不穩定,這是正確的,但是並非總是如此。
@user16230:誰告訴內核排除該內存?當然不是當前正在從該內存運行的程序。這是一種純離線的最後手段,它是通過檢測存儲位是否有故障(不是通過當前正在運行的程序)來執行的。即使對於壞扇區,結果也會導致*數據丟失*。重新刷新系統無法解決飛行中的所有問題。同樣,位可能僅在最奇怪的條件下才會發生異常,即使是最好的內存測試程序也無法檢測到。還是為什麼您認為rowhammer是最近才發現的?
再次,我同意,但是我只是指出可以處理不好的記憶(不是我建議在飛行中這麼做)。
@user16230:您仍然不明白這一點。如果您不知道它是不好的,或者在5分鐘內會變壞,就不可能處理不好的內存。您需要檢測內存不足,恢復存儲的數據並重新映射的方法。這不僅比擁有三個冗餘系統要昂貴得多,而且對於所有故障情況也是完全不可能的。因此,處理內存故障可能是可能的,但您必須通過實施多數表決決定來計劃不可能發生的事件,該決定的錯誤率要低得多。
@PlasmaHH您大概可以將幾個內存芯片RAID在一起,然後將它們連接到單個CPU,而不必花費三個內存芯片和三個CPU。
@raptortech97:您仍然需要三個ram模塊,否則您將沒有多數票,最多只能檢測出一個錯誤。是的,您可以創建一個使用漢明碼或其他完美的高階代碼的自定義系統,但是那又如何呢?您仍然有可能翻轉寄存器或緩存的位。海明碼這些嗎?解碼器中的位翻轉怎麼辦?同樣,這將花費不僅僅多數冗餘的費用。而且它不會處理類似模擬讀數錯誤(例如,從傳感器到ADC的更高阻抗)
Erich
2015-03-25 17:51:41 UTC
view on stackexchange narkive permalink

在特定冗餘方面,這些系統的安裝環境可能是最大的因素。不僅許多系統在狹窄的空間內緊密地擠在一起,而且那裡的氣流通常非常有限。熱量是許多微處理器的巨大破壞者。由於發動機旋轉,飛行中的湍流以及簡單的降落,飛機也會產生很大的振動。不良的焊點和低於標準的壓接工作或鬆動的連接器後蓋,或者連接不良,或更糟的是,斷續

通常,如果您需要冗餘,則在工作中體驗BSOD,相對而言沒什麼大不了的。您可能會丟失正在處理的文檔,僅此而已。如果飛機系統失靈,您將面臨真正的問題。這很難實現,但是存在冗餘是因為數百人的生活都依賴它

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

處理器故障的可能性確實很小,但不為零。處理器出現故障時,在故障和重新引導後的全部功能之間的過渡時間內會發生什麼?如果發生這樣的罕見事件,我們是否可以積累足夠的經驗來確保我們已經在所有情況下進行了測試?我們在這裡談論的是< $ 10 ^ {-9} $數字。

備份很容易出現隱藏的故障。通常不使用備份,僅在需要時才打開備份-備份後的東西生鏽了,或者時髦的模具緊貼在舒適的熱點中,導致啟動時短路?墨菲仍然困擾著航空航天應用。備份可以在起飛前進行測試,但是如果搖晃 並且主處理器出現故障怎麼辦?機會很小,但是如今所有重大事故都是由類似這樣的不太可能的事件引起的。 。如果您可以在沒有主設備的情況下使用備用系統,或者可以保證備用系統始終可以正常工作,例如手動操作飛行控制,則可以使用備用系統。

巡航中的自動駕駛儀並非如此飛行關鍵,可能會斷開連接而不會造成嚴重後果。在CAT III降落中,只有在您駕車上才能看到跑道,它們絕對至關重要。您不希望自動駕駛儀在距跑道10米的地方斷開連接,沒有能見度,一陣陣陣側風-沒有時間進行後備飛行。

我很欣賞答案。請注意,我使用它們的代詞,而不是他/他。
我注意到並修改了。
“ *巡航中的自動駕駛不是關鍵性的飛行,可以斷開而不會造成嚴重後果*”,理論上確實如此,但是一旦與空速指示失敗相結合,就會致命。
@mins實際上,在巡航過程中,每個事件(例如自動駕駛儀脫離接合)都被賦予安全等級,並且必須達到該安全等級。調整了冗餘度和嚴格度,以滿足所需的安全等級。是的,在巡航過程中自動駕駛儀脫離是嚴重的,是的,但不是“災難性的”,因此在安全分析期間被標記為僅是“次要”或“重大”問題。如果兩者之間存在重大交互作用,則相同的安全分析可能會將自動駕駛儀斷開連接和空速指示失敗標記為共同問題,從而帶來更高的後果。
NPSF3000
2015-03-26 03:24:11 UTC
view on stackexchange narkive permalink

如果微處理器過熱或過載並自發地發生故障,我希望它停止執行任何操作並且不產生任何輸出。

您是否曾經超頻CPU或觀看舊的硬件死了嗎?當CPU仍在運行時,您會獲得各種奇怪的工件。

安全關鍵任務中使用的CPU與[看門狗](https://en.wikipedia.org/wiki/Watchdog_timer)配對,這是一個類似於鐵路行業[死人](https:// en。 wikipedia.org/wiki/Dead_man%27s_switch)切換。一旦無法執行預定義的握手(例如,在充滿電之前先釋放容量),CPU將立即停止/復位
mimosa
2015-04-09 00:24:11 UTC
view on stackexchange narkive permalink

在飛機上,安全比任何其他因素都更為重要(此後才是實現燃油效率的最佳重量,而總成本則排在第三位)。如果飛機不安全,就不會有足夠的人飛行,航空業就會崩潰。這就是為什麼有FAA規定的原因,也就是為什麼有這麼多航空公司規定的原因。 (機場安全檢查是另一個主題,與移民的國家/政治安全等相關,因此,當我們說飛機的“安全性”時,我指的是工程方面的信息)

機載關鍵系統(即需要飛行飛機的系統)將需要冗餘。就像噴氣發動機中的燃燒器有2個點火器,即使一個也足夠。同樣,如果一個引擎發生故障,另一個引擎可以使飛機飛行,並且計算機將補償左右力的不平衡。飛機上的許多系統都依賴計算機,因此它需要一個“計劃b”(冗餘是“計劃b”之一)

這不能回答完整的問題。我知道航空中的大多數事物都是冗餘的,但是所有這些冗餘都有特定的原因-某種故障模式可能會使冗餘有用。我在問哪種故障模式可以防止芯片冗餘。
FreeMan
2015-03-25 10:37:18 UTC
view on stackexchange narkive permalink

因為,儘管理論是好的,但事實是並非所有計算機組件都是平等的。

上世紀90年代初的一個具體例子:英特爾生產486/33 CPU(這是非常先進的而且一天的速度非常快)。大多數人都離開工廠就好了,但是有些人在FPU中有一個深奧的錯誤,可能會產生錯誤的答案。當天的雜誌中充斥著各種計算結果,您可以將這些計算結果放入電子表格中,如果您的CPU良好,則將生成X;如果存在錯誤,則將生成Y。

如果您的飛機碰巧在其中一個運行中其中有故障的CPU,恰好收集到正確的數據集並將其輸入到任何飛行控製程序中,並遇到此FPU錯誤,您會很高興其他兩個CPU計算出正確的值並將其踢出錯誤地退出循環。

我認為您的榜樣令人誤解。首先,我認為您實際上是在談論[Pentium FDIV錯誤](https://en.wikipedia.org/wiki/Pentium_FDIV_bug)。那是設計錯誤,而不是隨機的製造錯誤。在糾正設計之前,出廠的每個處理器都存在錯誤。在這種情況下,冗餘將無濟於事:您只會得到同一錯誤答案的多個副本。
這可能是@DavidRicherby,提到的Pentium FDIV錯誤,也可能是[80386 double-sigma問題](https://en.wikipedia.org/wiki/Intel_80386#Early_problems)之類的東西。我認為486從未遇到此答案中描述的問題。
-1
無論如何,全面測試每個處理器要比使它們重複三次要便宜。
@raptortech97 [告訴NASA。他們對此一無所知。](http://space.stackexchange.com/q/247/415)
@MichaelKjörling是關於測試*設計*的輻射耐受性,而不是通過基本的操作測試來運行每個生產樣本
OP的@DavidRicherby,可能會將Pentium FDIV錯誤與[486SX](https://en.wikipedia.org/wiki/Intel_80486SX)的來源混為一談,其中486DX的FPU有問題而禁用了FPU,並作為整數出售-僅CPU。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...