1. 程式人生 > 實用技巧 >對波音787飛機持續執行51天會導致丟失飛行資料的研究

對波音787飛機持續執行51天會導致丟失飛行資料的研究

幾周前,國際監管機構釋出資訊,波音787運營商在執行51天之時,必須不間斷地完全關閉飛機的電源。美國聯邦航空局釋出了詳細說明該問題的適航指令,我很好奇這份檔案中包含了哪些細節。

我發現FAA指令中一些可用資訊,有足夠的資訊使我步入正題以瞭解問題的根本原因。這篇部落格文章將利用FAA指令中有趣的資訊來獲得有關某些航空電子概念的知識。

首先,我們需要介紹與該問題相關的787架構和系統的各個部分。FAA指令明確使用了諸如CDN或CCS之類的首字母縮寫詞,然後才需要進行根本原因分析。

0x01 通用核心系統介紹(CCS)

與使用分散式航空電子功能打包成獨立單元的聯邦航空電子體系結構相反,奇熱整合模組化航空電子(IMA)體系結構採用了高完整性的分割槽環境,該環境可在一個飛機上承載多個具有不同關鍵性的航空電子功能——共享計算平臺。波音工程師為787開發了通用核心系統(CCS),這是基於開放IMA航空電子技術的進一步增強版本。

本質上,CCS是一個硬體/軟體平臺,可提供計算、通訊和輸入/輸出(I / O)服務,以實現實時嵌入式系統。

多個託管功能在虛擬系統環境中共享平臺資源,該虛擬系統環境由依賴於VxWorks 653 3,4 OS 的分割槽機制組成,該分割槽機制是作為平臺設計的一部分實施的。

這種虛擬系統分割槽環境可確保託管功能相互隔離,因此它支援高度關鍵的應用程式,還支援較低級別的應用程式完整性。國際法規將故障條件定義為五個級別,按其對飛機,機組人員和乘客的影響進行分類

A級-Catastrophic

故障可能會導致多人喪生,通常會造成飛機損失

B級–Hazardous

故障會對安全或效能造成很大的負面影響,會因身體不適或工作量增加而降低機組人員操作飛機的能力,或者會給乘客造成嚴重或致命的傷害。

C級-Major

故障會大大降低安全裕度,或者會大大增加機組人員的工作量可能導致乘客不適(甚至輕傷)。

D級–Minor

故障會稍微降低安全裕度,或者會稍微增加機組人員的工作量例如可能導致旅客不便或更改常規航班計劃。

E級-No Effect

故障不會影響安全,飛機執行或機組人員的工作量

批准為A,B或C級的軟體高階認證,其中涉及用於驗證和可追溯性的正式流程

DO-178B 6 Level-A軟體可能與Level-E應用程式共存於同一物理共享資源中

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖1. VxWorks 653體系結構

理想情況下,無論託管功能或平臺資源中是否可能發生故障這些應用程式都不會相互干擾,這些功能是預先確定的,並通常通過XML或專有二進位制格式的可載入配置檔案傳達給平臺元件

在CCS中,我們可以找到以下主要組成部分

·通用處理模組(GPM),可滿足功能處理需求

·支援系統模擬訊號,模擬離散訊號和序列數字介面(CAN匯流排8,A429 9等)的遠端資料集中器(RDC )

·航空電子全雙工(A664-P7)交換式乙太網10網路,用於平臺元素之間的通訊

·這些元件可以包裝為線路可更換單元(LRU),也可以模組或卡的形式包裝,然後可以組合在機箱或整合的LRU中。

CCS由以下組成

·兩(2)個通用計算資源(CCR)機箱

·通用資料網路(CDN)

·21個RDC

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖2. CCS體系結構A

通用計算資源櫃

每個CCR機箱具有:

·兩(2)個功率調節模組(PCM)

·八(8)個通用處理模組(GPM)

·兩(2)個ARINC 664-P7網路機箱交換機(ACS)

·兩(2)個光纖轉換器模組(FOX)

·兩(2)個圖形生成器(Display and Alert Crew系統的一部分)

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖3.波音787 CCR機箱

每個GPM是一個獨立的計算平臺,可承載飛機系統的執行軟體,併為承載的應用程式提供基於ARINC 653標準的分割槽環境。每個GPM具有相同的硬體和核心作業系統。

這些CCR機箱中的GPM執行託管功能,例如遠端配電系統(RPDS),發電機/公共汽車電源控制單元(GCU / BPCU),13個斷路器指示和控制,起落架指示和控制,推力管理功能以及飛行管理功能。

通用資料網

CDN是使用IP定址和相關傳輸協議(UDP)的高完整性IEEE 802.3乙太網。作為符合A664-P7的網路,它還實施確定性定時和冗餘管理協議。CDN同時使用光纖電纜和銅線,並直接或通過ACS,FOX或RDC在與其連線的各種飛機系統之間移動系統資訊。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖4. 787網路架構

CDN由每個連線端節點中託管的網路端系統(ES)和多個網路交換機組成。

終端系統

在按照A664-P7規範定義的航空電子網路的範圍內,我們發現:

終端系統(ES)的主要功能是提供服務,以確保與分割槽軟體進行安全可靠的資料交換。

本質上,ES承擔著網路介面控制器(NIC)的角色,它能夠維護多個託管應用程式寫入和讀取的訊息的通訊埠(排隊,取樣或SAP)。這是通過虛擬鏈路(VL)交換乙太網幀來完成的,虛擬鏈路是一種概念上的通訊物件,它定義了從一個源到一個或多個目標ES的邏輯單向連線。VL中的業務流的形狀應設定為不超過配置的頻寬分配間隙(BAG),該頻寬表示兩個連續幀的第一位之間的最小時間間隔。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖5. CDN中的ES通訊

CDN(也在交換機中)中執行的ES與主處理器在物理上是分開的,並通過PCI匯流排進行介面。從高層的角度來看,它包括:

·一(1)個定製ASIC

·兩(2)個COTS乙太網PHY收發器

·兩(2)個序列配置儲存器

·記憶體

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖6.最終系統板的高階概述

可以通過專有API從主機配置ES。之前已使用DO-178B A級工具(ESBIN)生成了此配置資料,然後將其儲存在自定義檔案(es_config.bin)中。

CDN交換機中的ES實現了幾乎相同的功能,除了一些定址和冗餘操作。

遠端資料集中器

CCS中有21個RDC。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖7.遠端資料集中器

這些RDC提供了飛機系統之間的介面,這些系統不支援CDN中的A664-P7。

RDC將這些訊號轉換為ARINC 664資料,反之亦然,因此有效地充當了各種模擬裝置的閘道器,例如感測器或閥門,ARINC 429匯流排和CAN子網。

從A664-P7的角度來看,這些RDC對映:

·模擬訊號到引數

·A429至通訊埠

·到引數和通訊埠的CAN匯流排

結果,高階架構將如下。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖8. CCS的高階概述

為了從整體上更好地說明此體系結構,我們可以簡化其中一個託管函式,以瞭解所有部分如何協同工作。

起落架控制軟體在GPM分割槽中託管的一個CCR中執行。此託管功能分割槽通過CDN從21個RDC之一接收變速桿的上/下資料以及齒輪和齒輪門位置資料。然後,根據接收到的訊號,起落架控制軟體可以通過CDN向適當的RDC釋出起落架排序命令。然後,RDC可以將特定訊號傳遞給那些致動器,例如,這些致動器會向控制閥供能,以縮回和伸出起落架或開啟和關閉起落架艙門。

0x02 根本原因分析

FAA的指令在技術細節上很少。它僅包含對該問題的高階描述;但是,它為讀者提供了一些有助於根本原因分析的關鍵事實:

FAA已收到一份報告,指出連續開啟51天后,CCS的過時資料監視功能可能會丟失。這可能會導致CDN訊息期限驗證的未檢測到或未通知丟失,以及CDN切換失敗。CDN處理所有對飛行至關重要的資料(包括空速,高度,姿態和發動機執行),並且這種情況可能導致幾種潛在的災難性故障情況。潛在的後果包括:

·顯示兩名飛行員的誤導性主要姿態資料。

·在兩名飛行員的主要飛行顯示器(PFD)上顯示誤導性的高度。

·在兩名飛行員的PFD上顯示誤導性的空速資料,但不進行通知

·故障,失速警告丟失或超速警告。

·在兩個發動機上顯示誤導性的發動機執行指示。

如果不解決,連續上電51天,CCS的陳舊資料監視功能可能會丟失,這可能導致錯誤的飛行關鍵資料被髮送並顯示為有效資料,從而降低機組人員的能力。保持飛機的安全飛行和著陸。

我將仔細分析每個句子。

FAA已收到一份報告,指出連續開啟51天后,CCS的過時資料監視功能可能會丟失。

早在2015年,美國聯邦航空局(FAA)頒佈了類似的指令,儘管在此情況下對潛在問題的描述更為明確。

波音已向我們建議在實驗室測試中發現一個問題。

發電機控制單元(GCU)內部的軟體計數器在連續通電248天后將溢位。

因此,基本上,我們可以假設情況大致相同:波音公司在實驗室測試中發現了當前問題。

2015年美國聯邦航空局(FAA)指令還明確提到波音公司正在開發軟體補丁以解決該問題;但是,此當前指令中未提及任何即將釋出的補丁。正如我們稍後將看到的,如果漏洞與硬體相關,這是有道理的。

再次提到“ 51天”,最初是指向機箱上的某種溢位。

這可能會導致CDN訊息期限驗證的未檢測到或未通知丟失,以及CDN切換失敗。

這句話告訴我們有關問題性質的許多事情。首先,在787中未被檢測到或“未通知”的CDN中的任何災難性錯誤都是非常意外的,儘管對於我來說,尚不清楚CDN訊息時間驗證的丟失和CDN切換失敗是未被檢測到還是僅僅是第一個問題。維護工程師和飛行員都可以通過Flight Deck的維護頁面檢查CCS交換機和CDN LRU的狀態。此外,任何重大故障都將通過中央維護計算功能(CMCF)進行集中,記錄和處理。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖9.飛行甲板中的CCS狀態

同樣,飛行員可以在頂置面板上重置左右CCR。但是,正如FAA指令所述,需要完全關閉電源,因此我們可以假定CCR復位不能解決問題。這意味著問題不僅在CCR中而且在CDN的其他部分中都存在於元件的硬體中。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖10 CCR重置按鈕

所以我們有:

·CDN失去了執行能力。

·CDN切換失敗。

讓我們通過分析CDN中如何加強資料通訊完整性來縮小潛在犯罪問題的範圍。

CDN中的完整性檢查

請記住,CCS是一個非同步系統,其中每個分割槽不僅控制何時生成其資料,而且還將該操作與網路介面分離。在MAC級別,A664-P7規範要求不管PHY的狀態如何,都必須輸出輸出介面,以防止錯誤傳播或舊幀的重新傳輸。不過,在AFDX航空電子網路中,順序很重要,因此,當傳送分割槽生成某些資料時,接收方分割槽希望以相同的順序收集該資料。

另外,儘管在理論上可以將CCS配置為獨立執行,但CCS遵循具有兩個不同通道(“ A”和“ B”)的冗餘策略進行操作。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖11.幀處理邏輯

為了滿足這些要求,ES在傳送幀時在AFDX有效載荷之後新增序列號(SN)。ES重置後,此SN為0,然後為1-255。ES中收到的冗餘幀遵循“首次有效獲勝”策略。請注意,除了順序完整性外,還有一個檢測實際冗餘幀的過程,其中使用配置的常數(Skew Max)來限制兩個可能冗餘幀的有效時間視窗。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖12.常規AFDX框架

這種邏輯對於所有AFDX ES都是通用的,我認為此功能並不是真正的缺陷所在,因為任何問題都將更多地取決於流經CDN的流量,而不是特定的時間段。但是,有趣的是,ES的完整性檢查和冗餘管理中有些東西使787有點特殊:波音專有的錯誤檢測編碼(EDE)協議。

EDE協議

EDE協議在VL級別上工作,以在CDN中新增一層額外的端對端完整性檢測。

當波音(Boeing)要求使用EDE啟用VL來處理關鍵和必要資料時,傳送方ES將有效負載封裝在EDE標頭和頁尾中。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖13. EDE包裝的框架

EDE頁首和頁尾包括以下欄位:

·SN:繫結到特定COM埠的2位元組序列號。對於每個傳輸的幀,此值都會增加。

·時間戳:一個6位元組的值,使用傳送ES的本地時鐘域儲存傳送訊息的時間。

·CRC X和CRC Y:這些CRC是使用EDE源ID(僅VL中的ES傳送器和接收器才知道的32位值),EDE時間戳和有效負載來計算的。

EDE時間戳與傳送ES的時鐘域有關,因此CCS需要一種方法來集中並跟蹤所有本地時間參考,以便可以正確執行任何時間驗證。此任務由“時間管理”功能迴圈執行,該功能維護一個相對偏移量表,以及CDN中每個ES的時間參考之間的關係。這要歸功於請求/響應協議,其中每個ES中的時間代理都由時間管理器定期詢問。

然後,通過時間偏移訊息將所得的偏移表廣播到每個ES,以便ES可以在從另一個ES接收資料時執行EDE時間驗證。顯然,計算和傳播這些偏移量表所需的EDE時間管理資料包無需經過EDE時間驗證。

在EDE協議的上下文中,CDN中的時間驗證依賴於這些偏移量表的一致性。那麼,如果由於某種原因失敗了該怎麼辦?

有幾種可能的方案:

·ES未收到偏移表。 該訊息被轉發到EDE Redundancy Manager,但設定了一個標誌以指示其壽命無法驗證。

·時間大於最大配置的時間。 該訊息被直接丟棄。

·時間小於最大配置的時間。 這是預期的情況。該訊息將轉發到EDE Redundancy Manager,最終到達COM埠。

·時間不一致。 由於某種原因,該訊息似乎存在一個沒有意義的時間。例如,假設傳送ES設定的時間戳接近其環繞值。執行所需的計算後,接收方ES將獲得一個已包裝的時間戳記,因此,看起來該訊息在實際傳送之前就已被接收。該訊息已被接受,但仍可以處理,因為它的時間未知。

請記住,此功能是在ASIC中實現的,並且時間戳應該從計數器中得出,我認為整個問題可能都圍繞此邏輯。

可能的解釋

6位元組的EDE時間戳是確保CDN一切順利的關鍵。根據定義,此時間戳中的最高有效位設定為0,因此理想情況下,我們將0x7FFFFFFFFFFFF作為EDE時間戳的最大相干值。

ES通過PCI以33MHz的頻率從託管應用程式接收資料,因此以類似的時鐘頻率實現計數器是合理的,以便ASIC可以使用該時鐘參考來為準備就緒的訊息加蓋時間戳。因此,讓我們假設計數器理想情況下工作在33MHz上,並且時間戳以某種方式從該計數器匯出,同時還要考慮到不同的引數,例如由於跨不同介面(RMII,PCI等)移動資料而導致的延遲和延遲。

通過計算理想計數器(從0開始)執行的頻率,以便在51天后迴繞EDE時間戳(0x800000000000),我們獲得了〜32MHz。這非常接近我們的假設。

CDN處理所有對飛行至關重要的資料(包括空速,高度,姿態和發動機執行),並且這種情況可能導致幾種潛在的災難性故障情況。

我們之前曾介紹過DO-178B認證級別,其中A級對應於災難性故障,這阻止了持續的安全飛行或著陸。

潛在的後果包括:

·顯示兩名飛行員的誤導性主要姿態資料。

·在兩名飛行員的主要飛行顯示器(PFD)上顯示誤導性的高度。

·在兩名飛行員的PFD上顯示誤導性的空速資料,而不會提示故障,以及失速警告或超速警告的丟失。

·在兩個發動機上顯示誤導性的發動機執行指示。

美國聯邦航空局(FAA)檔案中涵蓋的後果似乎與飛行員不再相信自己的儀器的情況密切相關,在過去的事件中,這一問題已導致悲劇性後果。

在波音787中,所有這些資料都由顯示機組警報系統(DCAS)處理。該系統為飛行員提供了飛機安全執行所必需的所有音訊,觸覺或視覺指示,如下圖所示。

對波音787飛機持續執行51天會導致丟失飛行資料的研究

圖14. DCAS包括多個顯示器

如果不解決,連續上電51天,CCS的陳舊資料監視功能可能會丟失,這可能導致錯誤的飛行關鍵資料被髮送並顯示為有效資料,從而降低機組人員的能力。保持飛機的安全飛行和著陸。

最後一段,作為對本博文中闡述內容的總結。

0x03 研究總結

航空安全研究是一個複雜的領域,不僅因為圍繞這些技術的機密性,而且由於商業和公司壁壘阻礙了對所需裝置的訪問。儘管存在所有這些挑戰,但我認為促進此類研究的任何努力總能取得回報。

時機也很有趣,因為在將我們的研究報告給波音公司後將近一年,這個缺陷就暴露出來了。波音公司承認他們建立了一個功能齊全的飛機實驗室來評估我們提交的問題(涉及CDN),因此我想,他們的後續研究可能會發現這一問題。概括而言,這將是任何安全研究的良好副作用,所有這些研究都在於在人們所依賴的裝置和組織中建立適當的信任級別。

不要將我在這裡介紹的內容當作波音公司發現的問題的真正根本原因。我可能是對的,但很可能我錯了,這是為了滿足我的好奇心。

0x04 參考資訊

[A][IOActiveWhitePaper:ArmIDAandCrossCheck:Reversingthe787’sCoreNetwork](https://act-on.ioactive.com/acton/attachment/34793/f-cd239504-44e6-42ab-85ce-91087de817d9/1/-/-/-/-/Arm-IDAandCrossCheck%3AReversingthe787'sCoreNetwork.pdf)
[1]https://www.federalregister.gov/documents/2020/03/23/2020-06092/airworthiness-directives-the-boeing-company-airplanes
[2]https://www.aviationtoday.com/2007/02/01/integrated-modular-avionics-less-is-more/
[3]https://en.wikipedia.org/wiki/ARINC_653
[4][https://www.windriver.com/products/product-overviews/vxworks-653-product-overview-multi-core/vxworks-653-product-overview-multi-core.pdf](https://resources.windriver.com/vxworks/vxworks-653-product-overview)
[5]https://www.windriver.com/customers/customer-success/aerospace-defense/boeing/(404linkbroken)
[6]https://en.wikipedia.org/wiki/DO-178B
[7]http://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_WindRiver_Wilson.pdf
[8][https://en.wikipedia.org/wi](https://en.wikipedia.org/wiki/CAN_bus)[k](https://en.wikipedia.org/wiki/CAN_bus)[i/CAN_bus](https://en.wikipedia.org/wiki/CAN_bus)
[9]https://en.wikipedia.org/wiki/ARINC_429
[10]https://pdfs.semanticscholar.org/5db4/b539ed7bdec182448ac8d7219db12a8bbc12.pdf
[11]https://en.wikipedia.org/wiki/Line-replaceable_unit
[12]https://bioage.typepad.com/.a/6a00d8341c4fbe53ef0162fbf813b6970d
[13],[14]https://s3.amazonaws.com/public-inspection.federalregister.gov/2015-10066.pdf
[15],[16]https://www.instagram.com/787guide/