譚博

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

0 引 言

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

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

本文結(jié)合工程實際，發(fā)現(xiàn)在目前的航空電子系統(tǒng)中存在大數(shù)據(jù)傳輸需求的應(yīng)用場景有限，可以使用網(wǎng)狀通訊結(jié)構(gòu)構(gòu)建滿足大數(shù)據(jù)傳輸?shù)南到y(tǒng)網(wǎng)絡(luò)架構(gòu)，并通過流量控制的方式完成大數(shù)據(jù)的傳輸；重點研究窗口協(xié)議在大數(shù)據(jù)傳輸中的應(yīng)用前景，并給出一種可高效穩(wěn)定傳輸大數(shù)據(jù)的改進(jìn)窗口協(xié)議。

1 航空電子系統(tǒng)大數(shù)據(jù)傳輸

首先需對本文大數(shù)據(jù)傳輸?shù)母拍钸M(jìn)行簡單定義。因各航空電子系統(tǒng)的網(wǎng)絡(luò)選型、總線類型、硬件設(shè)備等存在差異，所以各系統(tǒng)對大數(shù)據(jù)的長度定義不盡相同。本文在以下描述中，定義系統(tǒng)大數(shù)據(jù)傳輸為：傳輸數(shù)據(jù)量超過最小任務(wù)調(diào)度周期內(nèi)能夠完成傳輸?shù)淖畲髷?shù)據(jù)量的數(shù)據(jù)傳輸。

一種典型的模塊化航空電子系統(tǒng)的架構(gòu)如圖1所示，系統(tǒng)內(nèi)各節(jié)點的應(yīng)用軟件與其分區(qū)操作系統(tǒng)(Partition Operating System，簡稱POS)聯(lián)合，形成系統(tǒng)中的一個邏輯節(jié)點。其中，應(yīng)用軟件負(fù)責(zé)完成邏輯節(jié)點分配的功能，分區(qū)操作系統(tǒng)通過應(yīng)用/執(zhí)行接口(Application Executive，簡稱APEX)，向應(yīng)用程序提供硬件資源操作的接口。邏輯節(jié)點可在系統(tǒng)內(nèi)任意模塊進(jìn)行部署，各邏輯節(jié)點之間通過機載網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳輸，完成節(jié)點狀態(tài)和數(shù)據(jù)的同步。

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

2 窗口傳輸協(xié)議

為了解決航空電子系統(tǒng)大數(shù)據(jù)傳輸?shù)膯栴}，一種有效的思路是依靠系統(tǒng)隊列消息傳輸?shù)哪芰Γ氪翱趥鬏攨f(xié)議，將待傳輸數(shù)據(jù)進(jìn)行分組并以異步傳輸?shù)姆绞酵瓿纱髷?shù)據(jù)的收發(fā)。該思路具有以下優(yōu)點：

(1) 易于實現(xiàn)。窗口協(xié)議的數(shù)據(jù)分組和窗口收發(fā)操作，可以通過隊列消息的傳遞實現(xiàn)。因此，一般航空電子系統(tǒng)都具備通過窗口傳輸來實現(xiàn)大數(shù)據(jù)傳輸?shù)臈l件。此外，窗口協(xié)議傳輸大數(shù)據(jù)可以在系統(tǒng)的應(yīng)用層實現(xiàn)，避免對系統(tǒng)設(shè)計方案和架構(gòu)進(jìn)行更改。

(2) 易于監(jiān)控。傳輸數(shù)據(jù)最終通過隊列消息收發(fā)實現(xiàn)，傳輸過程對于應(yīng)用層可見可控。

(3) 輕量級。窗口協(xié)議傳輸只實現(xiàn)數(shù)據(jù)傳遞的功能，所需的系統(tǒng)資源少。

以下列舉三種典型的窗口協(xié)議，并對其在航空電子系統(tǒng)中的應(yīng)用情況進(jìn)行說明和分析。

2.1 停止等待協(xié)議

停止等待協(xié)議的發(fā)送和接收窗口大小均為1，即每次只傳遞一個數(shù)據(jù)分組，其實現(xiàn)容易且能夠保證傳輸數(shù)據(jù)的正確性，是目前實際中使用的大數(shù)據(jù)傳輸方式之一。但該協(xié)議網(wǎng)絡(luò)利用率低，傳輸耗時隨數(shù)據(jù)量增長明顯，難以滿足大數(shù)據(jù)傳輸?shù)乃俾室蟆?/p>

2.2 回退協(xié)議

回退協(xié)議的發(fā)送窗口大小通常為大于1的整數(shù)，接收窗口大小為1。發(fā)送方將窗口內(nèi)的數(shù)據(jù)分組依次發(fā)出，接收方在接收到錯誤數(shù)據(jù)分組后向發(fā)送方反饋，隨后從出錯的數(shù)據(jù)分組重新進(jìn)行傳輸。應(yīng)用時，該協(xié)議在環(huán)境不穩(wěn)定時進(jìn)行大量重發(fā)，易造成網(wǎng)絡(luò)通訊擁堵，對機載網(wǎng)絡(luò)和接收端的性能有較大影響。

2.3 重傳協(xié)議

重傳協(xié)議的發(fā)送和接收窗口大小相同，通常為大于1的整數(shù)。發(fā)送方將窗口內(nèi)的數(shù)據(jù)分組依次發(fā)出，接收方在接收窗口填滿或到達(dá)最大間隔后，反饋接收狀態(tài)。發(fā)送方依據(jù)反饋，將未正確收到的數(shù)據(jù)進(jìn)行重傳，或繼續(xù)發(fā)送下一窗口。應(yīng)用時，該協(xié)議在環(huán)境不穩(wěn)定時發(fā)送速率明顯降低。

3 多窗口協(xié)議

現(xiàn)有的典型窗口協(xié)議在應(yīng)用時，存在傳輸效率、穩(wěn)定性等多方面的不足，為了解決這些問題，本文提出一種多窗口傳輸協(xié)議，與傳統(tǒng)的窗口協(xié)議相比，在網(wǎng)絡(luò)環(huán)境不穩(wěn)定時，它同時進(jìn)行多個窗口傳輸，在提高傳輸效率的同時，避免了發(fā)送大量冗余數(shù)據(jù)，具有更好的穩(wěn)定性和傳輸效率。

本文方法的核心思路是，在網(wǎng)絡(luò)環(huán)境不穩(wěn)定時，發(fā)送端用未正確接收的數(shù)據(jù)分組和待發(fā)送的數(shù)據(jù)分組盡量填充發(fā)送的邏輯窗口，提高數(shù)據(jù)發(fā)送的效率；接收端在接收到新邏輯窗口的數(shù)據(jù)分組時，開辟多個數(shù)據(jù)緩存區(qū)，對應(yīng)接收各邏輯窗口的數(shù)據(jù)，并在邏輯窗口數(shù)據(jù)填滿或達(dá)到設(shè)置最大接收時間窗口后，向發(fā)送端發(fā)送ACK確認(rèn)，達(dá)到減少冗余數(shù)據(jù)的目的。

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

(1) 設(shè)置數(shù)據(jù)分組大小不超過網(wǎng)絡(luò)最大傳輸單元長度，邏輯窗口大小不超過隊列長度；

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

(3) 發(fā)送方將當(dāng)前邏輯窗口Wa內(nèi)的數(shù)據(jù)分組(Pa1,Pa2,…,Paj)依次發(fā)送；

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

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

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

(7) 重復(fù)執(zhí)行流程(3)～(6)，直至數(shù)據(jù)發(fā)送完畢或超時退出。

(a) 發(fā)送方活動圖

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

從傳輸過程可以看出：多窗口傳輸協(xié)議在數(shù)據(jù)劃分時，除數(shù)據(jù)分組序號外還增加了邏輯窗口序號，以便在多窗口數(shù)據(jù)分組傳輸時進(jìn)行區(qū)分。當(dāng)網(wǎng)絡(luò)環(huán)境穩(wěn)定時，本協(xié)議等同于重傳協(xié)議，具有與重傳協(xié)議相同的傳輸效率；當(dāng)網(wǎng)絡(luò)環(huán)境不穩(wěn)定時，與其他窗口協(xié)議相比，多窗口協(xié)議通過多緩存區(qū)的方式同時接收多個邏輯窗口的數(shù)據(jù)，達(dá)到最大化的網(wǎng)絡(luò)利用率，充分利用傳輸?shù)臅r間窗口，提高了傳輸效率。這一特點也使得多窗口傳輸協(xié)議需要更多的系統(tǒng)資源支持。

此外，多窗口協(xié)議采用隊列消息異步通訊的方式實現(xiàn)數(shù)據(jù)傳遞，避免了收發(fā)過程中阻塞應(yīng)用程序。在應(yīng)用層中實現(xiàn)的特點，也使得采用多窗口協(xié)議不必對原有的系統(tǒng)硬件架構(gòu)和軟件架構(gòu)進(jìn)行更改，可以用于方案和架構(gòu)難以調(diào)整的航空電子系統(tǒng)中進(jìn)行大數(shù)據(jù)傳輸。

4 試驗過程及結(jié)果

以某型飛機航空電子系統(tǒng)的飛管數(shù)據(jù)同步應(yīng)用場景為例，任意一側(cè)飛管在編輯完成后，向?qū)?cè)飛管同步新的當(dāng)前計劃和備份計劃，以保證兩側(cè)數(shù)據(jù)的一致性。飛行計劃長度依據(jù)包含的航線和航路點的數(shù)目變化，最長情況下可達(dá)到110 496字節(jié)，因此，單次傳輸?shù)淖畲髷?shù)據(jù)量為220 992字節(jié)(當(dāng)前計劃和備份計劃均達(dá)到最大長度時)，網(wǎng)絡(luò)傳輸?shù)淖畲髠鬏攩卧獮? 204字節(jié)，據(jù)此設(shè)置數(shù)據(jù)分組大小為1 204字節(jié)，其中頭信息占4字節(jié)，包含邏輯窗口號和窗口內(nèi)的分組號，傳輸信息占1 200字節(jié)。

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

4.1 傳輸速率測試

系統(tǒng)正常運行，進(jìn)行飛行計劃同步，同步期間，不進(jìn)行其他操作。在此條件下進(jìn)行20次數(shù)據(jù)同步，以第一組數(shù)據(jù)分組發(fā)出傳輸完成ACK為止的收發(fā)任務(wù)調(diào)度次數(shù)作為傳輸耗時，統(tǒng)計各窗口協(xié)議在網(wǎng)絡(luò)環(huán)境良好情況下的傳輸速度，統(tǒng)計結(jié)果如表1所示。

表1 傳輸速率測試結(jié)果

從表1可以看出：試驗過程中，系統(tǒng)中、測試中、運行過程中的周期性數(shù)據(jù)收發(fā)、異常處理等情況無法完全屏蔽，導(dǎo)致每次傳輸?shù)暮臅r有部分差別；總體看來，在網(wǎng)絡(luò)環(huán)境良好情況下，協(xié)議均以最佳速度進(jìn)行傳輸，其中，因停止等待協(xié)議每個調(diào)度周期只收發(fā)一個數(shù)據(jù)分組，其傳輸速率明顯低于其他三種協(xié)議，其他三種協(xié)議在網(wǎng)絡(luò)環(huán)境良好時，傳輸速率基本一致，沒有明顯差異。

4.2 健壯性測試

實際機載網(wǎng)絡(luò)環(huán)境存在丟失、延遲、重復(fù)發(fā)送等各類故障情況，因此，健壯性也是應(yīng)用時必須考慮的因素。通過在測試網(wǎng)絡(luò)環(huán)境中注入故障的方式，對四種窗口協(xié)議的健壯性進(jìn)行測試。

設(shè)置網(wǎng)絡(luò)丟包率為10%，測試結(jié)果如表2所示。

表2 丟包情況傳輸速率測試結(jié)果

設(shè)置網(wǎng)絡(luò)亂序發(fā)生概率為10%，測試結(jié)果如表3所示。

表3 亂序情況傳輸速率測試結(jié)果

設(shè)置網(wǎng)絡(luò)數(shù)據(jù)重傳發(fā)生概率為10%，測試結(jié)果如表4所示。

表4 重傳情況傳輸速率測試結(jié)果

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

4.3 試驗總結(jié)

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

(1) 停止等待協(xié)議在網(wǎng)絡(luò)傳輸丟包故障發(fā)生后，僅請求重傳丟失的一個數(shù)據(jù)分組，沒有額外的數(shù)據(jù)分組傳輸，因此，受丟包故障影響較小，在丟包率為10%的情況下，平均傳輸時長增長約28.8%。但是，其傳輸效率明顯低于其他幾種協(xié)議，因此在數(shù)據(jù)量較大的應(yīng)用場景中，停止等待協(xié)議難以滿足數(shù)據(jù)傳輸?shù)乃俾室蟆?/p>

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

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

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

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

5 結(jié) 論

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