多窗口傳輸協議及其在航空電子系統大數據傳輸中的應用

譚博

(航空工業第一飛機設計研究院 綜合航電系統設計研究所，西安 710089)

0 引 言

隨著航空電子系統整體架構向著模塊化、分布式的方向快速發展，傳統的采樣和隊列數據傳輸方式已經不能完全滿足現代航空電子系統的數據傳輸需求。隨著用戶需求和技術手段的更新，航空電子系統數據傳輸出現了大數據傳輸需求，這類傳輸需求通常具有以下兩個特點：一是傳輸數據量大且長度不定，大數據量使得在航空電子系統內完成數據的實時傳輸非常困難，而且與傳統的采樣或隊列消息傳輸需求不同，傳輸的大數據無法在系統設計階段以系統接口控制文件(Interface Control Document，簡稱ICD)的方式進行控制，進而對其長度、內容、格式等進行限定，而需要在系統運行時進行動態的適配；二是大數據傳輸必須在系統在線運行時進行，與系統可在離線狀態下加載的數據不同，系統內傳輸的大數據通常會影響系統功能運行的正確性，因此無法像應用程序或配置表等數據那樣，在系統離線狀態下以專用設備進行一對一的數據傳輸。

目前，航空電子系統大數據傳輸有多種實現思路。徐克等[1]給出了一種利用系統提供的可高速訪問的資源，以數據共享的方式在分區間進行大數據傳輸，應用該方式可在分區間以高速率和高穩定性完成數據傳輸，但是這種方式僅適用于系統內單個結點內部的數據傳輸，無法滿足系統內各結點之間以及系統間的大數據傳輸需求，此外，該方式的實現依靠操作系統，限制了其應用范圍，不具有普適性；李文濤等[2]給出了一種利用FTP(File Transfer Protocol)協議將大數據存儲為文件后進行傳輸的方式，該方式技術成熟，速率和性能較好，但是使用FTP協議需要操作系統支持，且需要在系統中增加文件服務器結點，這將限制系統內硬件平臺和操作系統的選擇，并影響航空電子系統的架構，為系統設計引入了額外的成本；志超有等[3]指出，現代機載總線能夠提供很高的傳輸速率，因此，另一種實現思路是直接利用機載總線將大數據通過網絡數據分包的方式進行直接傳輸，但是在實際使用時，因機載網絡無法在單次傳輸中完成大數據的全部數據傳輸，存在阻塞應用程序的情況，會影響航空電子系統的正常功能和系統安全性。此外，經查閱ARINC653標準[4-6]，發現大數據傳輸服務并不是標準的服務/接口，以Vxworks操作系統為例，在其操作手冊和配置手冊[7-8]中，均未針對大數據傳輸應用場景提供對應的服務或接口。

本文結合工程實際，發現在目前的航空電子系統中存在大數據傳輸需求的應用場景有限，可以使用網狀通訊結構構建滿足大數據傳輸的系統網絡架構，并通過流量控制的方式完成大數據的傳輸；重點研究窗口協議在大數據傳輸中的應用前景，并給出一種可高效穩定傳輸大數據的改進窗口協議。

1 航空電子系統大數據傳輸

首先需對本文大數據傳輸的概念進行簡單定義。因各航空電子系統的網絡選型、總線類型、硬件設備等存在差異，所以各系統對大數據的長度定義不盡相同。本文在以下描述中，定義系統大數據傳輸為：傳輸數據量超過最小任務調度周期內能夠完成傳輸的最大數據量的數據傳輸。

一種典型的模塊化航空電子系統的架構如圖1所示，系統內各節點的應用軟件與其分區操作系統(Partition Operating System，簡稱POS)聯合，形成系統中的一個邏輯節點。其中，應用軟件負責完成邏輯節點分配的功能，分區操作系統通過應用/執行接口(Application Executive，簡稱APEX)，向應用程序提供硬件資源操作的接口。邏輯節點可在系統內任意模塊進行部署，各邏輯節點之間通過機載網絡進行數據傳輸，完成節點狀態和數據的同步。

航空電子系統內，大部分數據以采樣數據(例如傳感器采集數據、設備狀態、引導參數等)或隊列消息(例如人機交互指令)的方式進行傳輸，這兩類數據傳輸的內容、格式和長度都可以在系統的設計階段明確并限制。但是，隨著技術的發展和需求的增加，出現了僅依靠這兩類數據所無法完成的應用場景。以某型飛機航空電子系統中飛行管理分系統(以下簡稱為飛管)為例，該分系統采用模塊化架構，由三個運行分區組成，部署于標準的硬件模塊上。使用時，航空電子系統對系統內的主從飛管有數據同步的需求，要求在任意飛管完成飛行計劃編輯并確認后，將數據同步至另一飛管。在該應用場景中，需要同步的數據依據飛行計劃的長度而有所差異，若在每次同步時均指定依據最大長度進行傳輸，則會導致編輯完成后同步時間過長，嚴重影響用戶使用體驗，若指定長度小于實際長度，又會造成數據傳輸不完整，影響功能的正確性。如何高效穩定地傳輸這類長度不定的大數據，是本文希望解決的問題。

2 窗口傳輸協議

為了解決航空電子系統大數據傳輸的問題，一種有效的思路是依靠系統隊列消息傳輸的能力，引入窗口傳輸協議，將待傳輸數據進行分組并以異步傳輸的方式完成大數據的收發。該思路具有以下優點：

(1) 易于實現。窗口協議的數據分組和窗口收發操作，可以通過隊列消息的傳遞實現。因此，一般航空電子系統都具備通過窗口傳輸來實現大數據傳輸的條件。此外，窗口協議傳輸大數據可以在系統的應用層實現，避免對系統設計方案和架構進行更改。

(2) 易于監控。傳輸數據最終通過隊列消息收發實現，傳輸過程對于應用層可見可控。

(3) 輕量級。窗口協議傳輸只實現數據傳遞的功能，所需的系統資源少。

以下列舉三種典型的窗口協議，并對其在航空電子系統中的應用情況進行說明和分析。

2.1 停止等待協議

停止等待協議的發送和接收窗口大小均為1，即每次只傳遞一個數據分組，其實現容易且能夠保證傳輸數據的正確性，是目前實際中使用的大數據傳輸方式之一。但該協議網絡利用率低，傳輸耗時隨數據量增長明顯，難以滿足大數據傳輸的速率要求。

2.2 回退協議

回退協議的發送窗口大小通常為大于1的整數，接收窗口大小為1。發送方將窗口內的數據分組依次發出，接收方在接收到錯誤數據分組后向發送方反饋，隨后從出錯的數據分組重新進行傳輸。應用時，該協議在環境不穩定時進行大量重發，易造成網絡通訊擁堵，對機載網絡和接收端的性能有較大影響。

2.3 重傳協議

重傳協議的發送和接收窗口大小相同，通常為大于1的整數。發送方將窗口內的數據分組依次發出，接收方在接收窗口填滿或到達最大間隔后，反饋接收狀態。發送方依據反饋，將未正確收到的數據進行重傳，或繼續發送下一窗口。應用時，該協議在環境不穩定時發送速率明顯降低。

3 多窗口協議

現有的典型窗口協議在應用時，存在傳輸效率、穩定性等多方面的不足，為了解決這些問題，本文提出一種多窗口傳輸協議，與傳統的窗口協議相比，在網絡環境不穩定時，它同時進行多個窗口傳輸，在提高傳輸效率的同時，避免了發送大量冗余數據，具有更好的穩定性和傳輸效率。

本文方法的核心思路是，在網絡環境不穩定時，發送端用未正確接收的數據分組和待發送的數據分組盡量填充發送的邏輯窗口，提高數據發送的效率；接收端在接收到新邏輯窗口的數據分組時，開辟多個數據緩存區，對應接收各邏輯窗口的數據，并在邏輯窗口數據填滿或達到設置最大接收時間窗口后，向發送端發送ACK確認，達到減少冗余數據的目的。

本文的多窗口傳輸協議(如圖2所示)的一般過程為：

(1) 設置數據分組大小不超過網絡最大傳輸單元長度，邏輯窗口大小不超過隊列長度；

(2) 將待傳輸數據依據邏輯窗口大小和數據分組大小劃分為i個邏輯窗口(W1,W2,…,Wi)；

(3) 發送方將當前邏輯窗口Wa內的數據分組(Pa1,Pa2,…,Paj)依次發送；

(4) 接收方接收到數據后，將接收數據分組(Pa1,Pa2,…,Paj)存入Wa對應的緩存區，并在接收到帶有新邏輯窗口編號的數據分組Pbk時，申請新緩存存儲Wb的數據分組，啟動相應的窗口計時；

(5) 在任意邏輯窗口填滿，或任意時間窗口滿足后，反饋對應邏輯窗口的接收狀態；

(6) 發送方依據接收狀態，將邏輯窗口內Wa未被正確接收的數據和之后的邏輯窗口Wb內待發送的數據組成臨時窗口發送(Pai,…,Paj,Pbk,…,Pbl)；

(7) 重復執行流程(3)～(6)，直至數據發送完畢或超時退出。

(a) 發送方活動圖

(b) 接收方活動圖圖2 多窗口協議活動圖Fig.2 Activity diagram of multiple window protocol

從傳輸過程可以看出：多窗口傳輸協議在數據劃分時，除數據分組序號外還增加了邏輯窗口序號，以便在多窗口數據分組傳輸時進行區分。當網絡環境穩定時，本協議等同于重傳協議，具有與重傳協議相同的傳輸效率；當網絡環境不穩定時，與其他窗口協議相比，多窗口協議通過多緩存區的方式同時接收多個邏輯窗口的數據，達到最大化的網絡利用率，充分利用傳輸的時間窗口，提高了傳輸效率。這一特點也使得多窗口傳輸協議需要更多的系統資源支持。

此外，多窗口協議采用隊列消息異步通訊的方式實現數據傳遞，避免了收發過程中阻塞應用程序。在應用層中實現的特點，也使得采用多窗口協議不必對原有的系統硬件架構和軟件架構進行更改，可以用于方案和架構難以調整的航空電子系統中進行大數據傳輸。

4 試驗過程及結果

以某型飛機航空電子系統的飛管數據同步應用場景為例，任意一側飛管在編輯完成后，向對側飛管同步新的當前計劃和備份計劃，以保證兩側數據的一致性。飛行計劃長度依據包含的航線和航路點的數目變化，最長情況下可達到110 496字節，因此，單次傳輸的最大數據量為220 992字節(當前計劃和備份計劃均達到最大長度時)，網絡傳輸的最大傳輸單元為1 204字節，據此設置數據分組大小為1 204字節，其中頭信息占4字節，包含邏輯窗口號和窗口內的分組號，傳輸信息占1 200字節。

參考文獻[9]～[13]設計了此次試驗的仿真數據總線并建立了試驗環境，依據文獻[14]～[15]確定通過對傳輸任務調度周期進行計數的方式分析傳輸效率和健壯性的方式。最終在航空電子系統試驗室中對本文協議及三種典型的窗口協議進行測試，待傳輸的數據大小為220 992字節，劃分為185個分組。測試中，除停止等待協議的邏輯窗口大小為1外，其余協議的邏輯窗口大小均設置為5，航空電子系統試驗結果如表1～表4所示，表中各欄計量單位為個，表示傳輸任務的調度周期和傳輸的窗口計數。其中，最小傳輸周期、最大傳輸周期和平均傳輸周期為完成單次傳輸所需的調度周期計數，發送窗口數(平均)、接受窗口數(平均)為完成20次試驗中，單次傳輸過程中收發窗口計數的平均值，丟棄分組數(平均)為完成20次試驗中，單次傳輸過程中丟棄的冗余或無效數據分組計數的平均值。

4.1 傳輸速率測試

系統正常運行，進行飛行計劃同步，同步期間，不進行其他操作。在此條件下進行20次數據同步，以第一組數據分組發出傳輸完成ACK為止的收發任務調度次數作為傳輸耗時，統計各窗口協議在網絡環境良好情況下的傳輸速度，統計結果如表1所示。

表1 傳輸速率測試結果

從表1可以看出：試驗過程中，系統中、測試中、運行過程中的周期性數據收發、異常處理等情況無法完全屏蔽，導致每次傳輸的耗時有部分差別；總體看來，在網絡環境良好情況下，協議均以最佳速度進行傳輸，其中，因停止等待協議每個調度周期只收發一個數據分組，其傳輸速率明顯低于其他三種協議，其他三種協議在網絡環境良好時，傳輸速率基本一致，沒有明顯差異。

4.2 健壯性測試

實際機載網絡環境存在丟失、延遲、重復發送等各類故障情況，因此，健壯性也是應用時必須考慮的因素。通過在測試網絡環境中注入故障的方式，對四種窗口協議的健壯性進行測試。

設置網絡丟包率為10%，測試結果如表2所示。

表2 丟包情況傳輸速率測試結果

設置網絡亂序發生概率為10%，測試結果如表3所示。

表3 亂序情況傳輸速率測試結果

設置網絡數據重傳發生概率為10%，測試結果如表4所示。

表4 重傳情況傳輸速率測試結果

從表2～表4可以看出：在網絡故障影響下，多窗口協議受到的影響最小，在四種協議中傳輸效率和健壯性最好，而且沒有多余數據傳輸，對機載網絡和接收端的負載影響小。

4.3 試驗總結

綜合傳輸速率和健壯性試驗的結果，可得：

(1) 停止等待協議在網絡傳輸丟包故障發生后，僅請求重傳丟失的一個數據分組，沒有額外的數據分組傳輸，因此，受丟包故障影響較小，在丟包率為10%的情況下，平均傳輸時長增長約28.8%。但是，其傳輸效率明顯低于其他幾種協議，因此在數據量較大的應用場景中，停止等待協議難以滿足數據傳輸的速率要求。

(2) 回退協議和重傳協議的邏輯窗口內包含的數據分組多，因此，在網絡存在丟包故障時，窗口發送失敗的概率與停止等待協議相比更高，受到的影響更大，在丟包率為10%的情況下，平均發送時長增長約116%。此外，回退協議在數據重發時會將丟失的數據分組及之后的全部數據分組重新傳輸，造成網絡上存在大量的冗余數據，對網絡和接收端的影響較大。

(3) 回退協議對數據到達的順序有要求，數據順序錯誤會導致接收端請求重傳最后一組有效數據分組及之后的數據分組，使得通訊鏈路上存在大量的冗余數據，對機載網絡和接收端的影響較大。而其他三種協議對數據到達順序沒有要求，因此不受數據順序錯誤的影響。

(4) 四種協議的接收方都會丟棄接收到的重復數據分組，因此網絡數據重傳故障對四種協議的傳輸效率基本沒有影響，僅會略微影響接收端的性能。

(5) 本文提出的多窗口協議受各類網絡故障的影響最小，在故障情況下，與重傳和回退協議相比，多窗口協議的平均傳輸周期更短，冗余數據量更少。

5 結 論

本文提出的多窗口數據傳輸協議，可以在不對系統配置、操作系統或硬件進行修改的前提下，僅對應用程序進行變更，達到為具有隊列消息傳輸能力的航空電子系統提供大數據傳輸功能支持的目的。這種解決方案相比目前使用的文件傳輸協議和停止等待傳輸協議，所需消耗的人力、資源和時間成本更少，且能達到較高的傳輸速率，具有穩定的傳輸性能，可為航空電子系統后續功能的擴展和更新提供支持。