空戰(zhàn)訓(xùn)練機載前端信息采集系統(tǒng)設(shè)計

朱金冬，孫繼平

（1.航空工業(yè)沈陽飛機設(shè)計研究所，遼寧 沈陽 110035；2.天津津航計算技術(shù)研究所，天津 300308）

1 背景和組成

空戰(zhàn)訓(xùn)練系統(tǒng)是世界各國空軍在進行空戰(zhàn)對抗訓(xùn)練時普遍采用的訓(xùn)練裝備之一，它以飛機外掛或內(nèi)置設(shè)備形式投入使用，不影響原機系統(tǒng)的操作，能夠在空戰(zhàn)對抗訓(xùn)練過程中對空戰(zhàn)態(tài)勢、訓(xùn)練安全等進行有效的監(jiān)視，更主要的是能夠?qū)崿F(xiàn)機載武器的模擬攻擊仿真計算，在不投放真實武器的情況下訓(xùn)練飛行員熟悉飛機平臺和武器系統(tǒng)，理解復(fù)雜戰(zhàn)場環(huán)境，掌握空戰(zhàn)技術(shù)和戰(zhàn)術(shù)[1]。

空戰(zhàn)訓(xùn)練系統(tǒng)主要分為機載空戰(zhàn)綜合訓(xùn)練分系統(tǒng)（簡稱機載系統(tǒng)）和地面評估顯示分系統(tǒng)（簡稱地面系統(tǒng)）兩大部分。機載系統(tǒng)安裝于參與空戰(zhàn)訓(xùn)練的各架飛機，地面系統(tǒng)位于地面站，它們之間通過鏈路端機以無線組網(wǎng)通信技術(shù)完成所有數(shù)據(jù)傳輸[2-3]。

空戰(zhàn)訓(xùn)練系統(tǒng)組成和信息通訊如圖1 所示。

圖1 空戰(zhàn)訓(xùn)練系統(tǒng)組成和信息通訊圖

在空戰(zhàn)對抗訓(xùn)練過程中，具體傳輸數(shù)據(jù)有機載系統(tǒng)實時下傳至地面系統(tǒng)的飛機時空定位數(shù)據(jù)、武器投放數(shù)據(jù)、仿真武器彈道數(shù)據(jù)、武器攻擊解算結(jié)果，用于實現(xiàn)戰(zhàn)場態(tài)勢監(jiān)控，并防止安全事故發(fā)生。同時當(dāng)機載系統(tǒng)模擬武器解算結(jié)果為“命中”時，實時告知目標(biāo)機，以便目標(biāo)機知悉已被“命中”。地面系統(tǒng)可根據(jù)實際情況實時向各機載系統(tǒng)發(fā)送導(dǎo)調(diào)指令，用于控制管理各架參與空戰(zhàn)訓(xùn)練的飛機。

2 采集系統(tǒng)重要性

上述各種數(shù)據(jù)信息的源頭，基本都在機載系統(tǒng)中采集和生成。雖然空戰(zhàn)訓(xùn)練系統(tǒng)傳輸數(shù)據(jù)信息種類按已有協(xié)議已經(jīng)固定，但實際各型飛機的飛行、武器等總線架構(gòu)和通訊協(xié)議完全不同。如果各機型通用的彈道仿真和裁決模塊直接與各型飛機交聯(lián)，將造成采集與仿真裁決分工不清晰，維護工作困難等技術(shù)問題。因此在機載系統(tǒng)中需要一種前端信息采集系統(tǒng)，它負責(zé)將通信架構(gòu)和協(xié)議不同的所有異形飛機信息轉(zhuǎn)換為格式相同的通用信息，并將其傳送給后續(xù)模塊，是空戰(zhàn)訓(xùn)練系統(tǒng)實現(xiàn)統(tǒng)型化工作的重要基礎(chǔ)。前端信息采集系統(tǒng)在機載系統(tǒng)中與其他模塊信息交聯(lián)關(guān)系如圖2 所示。

圖2 機載系統(tǒng)中前端信息采集系統(tǒng)交聯(lián)關(guān)系圖

機載系統(tǒng)的前端信息采集系統(tǒng)直接面向載機火控、武控、航行航姿、電抗和飛行員直接操作的駕駛桿、油門桿等系統(tǒng)，硬件與載機各系統(tǒng)的信息輸出線路交聯(lián)，采集訓(xùn)練過程中機載系統(tǒng)所需要的原始數(shù)據(jù)，將原始數(shù)據(jù)解析后，提取其中有意義的信息，并在軟件上按各項協(xié)議規(guī)定的格式，傳送給機載系統(tǒng)其他需要該信息的模塊[4]。

3 采集系統(tǒng)一般設(shè)計要求

對于前端信息采集系統(tǒng)，在滿足硬件線路正確可靠連接，硬件接口電路讀寫正確，同時提供足夠容量接收緩存的前提下，軟件要實現(xiàn)的工作可概括為在第一時間完成數(shù)據(jù)搬運與轉(zhuǎn)換，且不丟數(shù)、不錯數(shù)，為空戰(zhàn)訓(xùn)練系統(tǒng)其他模塊實現(xiàn)實時評估和事后評估提供可靠基礎(chǔ)保障。數(shù)據(jù)經(jīng)過硬件緩存與軟件處理和搬運流程如圖3 所示，采集系統(tǒng)通過RS422總線給記錄器傳送數(shù)據(jù)實現(xiàn)事后評估；通過LBE 總線雙口緩存給彈道仿真裁決模塊傳送數(shù)據(jù)實現(xiàn)實時評估。

圖3 數(shù)據(jù)經(jīng)過硬件緩存與軟件處理和搬運流程圖

第一時間完成數(shù)據(jù)搬運，意味著軟件主循環(huán)周期應(yīng)盡可能小，最大限度發(fā)揮CPU 的能力，盡量避免CPU 空跑。因為各路數(shù)據(jù)硬件接收接口緩存里隨時會有新的數(shù)據(jù)到達，軟件應(yīng)保證在硬件緩存未填滿之前，將緩存所有新收到數(shù)據(jù)取走并盡快完成下一步轉(zhuǎn)換處理，最終將數(shù)據(jù)搬運至硬件輸出接口緩沖里，硬件可自動在軟件運行同時并行完成數(shù)據(jù)發(fā)送操作。

數(shù)據(jù)轉(zhuǎn)換的要求是，軟件應(yīng)該按ICD 文件定義對接收到的數(shù)據(jù)進行解析，并能夠應(yīng)對異常的輸入數(shù)據(jù)，保持軟件運行邏輯不受異常數(shù)據(jù)干擾。當(dāng)解析后的數(shù)據(jù)超過正常值范圍時，軟件應(yīng)當(dāng)給予必要的限值處理，保證不錯數(shù)。軟件運行時，要時刻保證硬件輸入緩存從未被填滿，數(shù)據(jù)時刻保持按時被軟件取走并處理，且輸出緩存也從未被填滿溢出，才能實現(xiàn)數(shù)據(jù)不丟失。

為保證軟件可靠完成任務(wù)，在設(shè)計過程中需要統(tǒng)籌規(guī)劃，按下面思路設(shè)計：①明確所有硬件接口電路提供的接口種類和數(shù)量，明確軟件操作硬件的接口方式、邏輯、地址范圍等軟件編程過程中必須使用的技術(shù)輸入，以滿足軟件可編程的方式給出。②軟件輸入功能要依照硬件分類劃分清晰，每個輸入模塊（如429 和422）處理數(shù)據(jù)要邏輯完整，自成一體，能妥善應(yīng)對正常數(shù)據(jù)和異常數(shù)據(jù)輸入。當(dāng)處理完正常輸入數(shù)據(jù)后，將詳細信息提取出來，供軟件后續(xù)模塊使用。數(shù)據(jù)種類和數(shù)量基本與硬件保持一致。③軟件內(nèi)部維持一套輸入模塊產(chǎn)生的實時備份數(shù)據(jù)，根據(jù)實際需要保存轉(zhuǎn)換前和轉(zhuǎn)換后兩種格式數(shù)據(jù)，供輸出模塊使用，供測試和排故維護工作使用，為其提供可靠的依據(jù)。④輸出模塊以硬件實際接口為基礎(chǔ)，將輸入模塊產(chǎn)生的實時備份數(shù)據(jù)按輸出協(xié)議進行打包輸出。打包模塊的各個子模塊要考慮復(fù)用性，協(xié)議包內(nèi)的每個字段生成功能相互獨立、過程清晰，便于軟件維護和轉(zhuǎn)交。⑤軟件在初始化過程中，要將各硬件電路已經(jīng)接收到的數(shù)據(jù)清除，以免產(chǎn)生對后續(xù)正常執(zhí)行的影響。⑥在軟件的主體架構(gòu)，即每周期的循環(huán)過程中，要考慮將數(shù)據(jù)輸入模塊放置在前，且調(diào)用周期盡量縮短，保證第一時間完成輸入數(shù)據(jù)的處理。數(shù)據(jù)輸出模塊調(diào)用周期可適當(dāng)加長，即湊一段時間數(shù)據(jù)后再一起打包發(fā)走，避免頻繁打包增加不必要的協(xié)議頭尾數(shù)據(jù)。

4 采集系統(tǒng)技術(shù)關(guān)鍵點

結(jié)合交聯(lián)關(guān)系圖，以某型機的機載系統(tǒng)為例，將前端信息采集系統(tǒng)設(shè)計過程中的技術(shù)關(guān)鍵點進行逐一介紹。

4.1 ARINC429 總線解析技術(shù)難點

根據(jù)空戰(zhàn)訓(xùn)練系統(tǒng)信息需求，需要從載機各系統(tǒng)實時采集載機當(dāng)前時刻的飛行姿態(tài)，傳感器跟蹤目標(biāo)狀態(tài)、武器發(fā)射等信息。由于上述幾種信息在載機內(nèi)部設(shè)備之間實際通訊過程中采用ARINC429 總線（以下簡稱“429 總線”），通訊拓撲屬于點對點結(jié)構(gòu)，因此需要在硬件層面將每一路429總線以類似三通方式匯集到采集系統(tǒng)的429 總線硬件接口電路，且不影響原機設(shè)備通訊。

軟件方面主要思路是結(jié)合已有的總線接口ICD 文件進行信息解析。對于一次性指令信息，一般是1 個Bit 位，按ICD 定義進行有效和無效解析，如雷達是否截獲等；對于有符號和無符號數(shù)值信息，一般是若干個Bit 位，按補碼將其轉(zhuǎn)換為10 進制數(shù)值，再按ICD 定義的最小比例尺相乘，可解析出實際真實物理值，如目標(biāo)方位角、俯仰角等。

在軟件解析429 總線數(shù)據(jù)過程中，存在如下兩大技術(shù)難點：①429 總線數(shù)據(jù)理論上存在線上格式和編程格式兩種格式[5]。每一個32 位429 字的低8 位為LABEL 碼，其余為數(shù)據(jù)部分。碼和數(shù)正常排列不反轉(zhuǎn)為線上格式，都反轉(zhuǎn)為編程格式。但兩種格式可能衍生出碼轉(zhuǎn)數(shù)不轉(zhuǎn)和數(shù)轉(zhuǎn)碼不轉(zhuǎn)，一共存在四種格式。前期設(shè)計需要精確論證確定實際載機設(shè)備和總線ICD 文件采用哪種格式。不同格式LABEL 碼的認讀方式不同，如果不能確定，將會影響軟件后續(xù)對所有信息解析的正確性。②對于火控系統(tǒng)的429 總線，其LABEL 碼以固定規(guī)律循環(huán)發(fā)送，每一次循環(huán)包含16 個429 字并代表一個數(shù)據(jù)組，機載設(shè)備以此方式來表達載機火控系統(tǒng)當(dāng)前狀態(tài)。軟件需要具備相應(yīng)解析邏輯，先識別數(shù)據(jù)組的組號，再結(jié)合ICD 內(nèi)容和實際需要信息對該數(shù)據(jù)組的某1Bit 位或某若干個Bit 位進行解析。

4.2 ARINC429 總線解析解決方案

針對第一個技術(shù)難點，通過圖4、圖5 進行說明。

通過對比可以發(fā)現(xiàn)圖4 上半部分是線上格式，它與總線ICD 實際內(nèi)容每一個429 字的每一位有明確的一一對應(yīng)關(guān)系，如第32 位都是校驗位，第31 和30 兩位存在對應(yīng)關(guān)系。由此可初步認為總線ICD 采用的是線上格式，非編程格式，因為編程格式的校驗位在第9 位，與總線ICD 實際內(nèi)容對應(yīng)不上。

線上格式的LABEL 碼認讀方式為從第1 位向第8 位讀。每個429 字LABEL 碼的拆分如表1 所示。

圖4 429 總線數(shù)據(jù)線上格式（上）和編程格式（下）對應(yīng)關(guān)系圖

圖5 ICD 中可直接通過LABEL 碼解析的數(shù)據(jù)內(nèi)容

表1 每個429 字LABEL 碼的拆分

后期經(jīng)過實際載機下發(fā)數(shù)據(jù)驗證，與總線ICD 內(nèi)容完全符合。因此第一個技術(shù)難點通過確定429 總線數(shù)據(jù)格式為線上格式得以解決。由此除火控系統(tǒng)外其余各條429 總線內(nèi)容可按ICD 定義的LABEL 碼進行解析。為機載系統(tǒng)實現(xiàn)精確的時空定位和武器建模仿真以及地面系統(tǒng)的顯示與回放工作做好充分的準(zhǔn)備。

針對第二個技術(shù)難點，結(jié)合圖6 進行說明。

火控系統(tǒng)429 總線上的數(shù)據(jù)以循環(huán)數(shù)據(jù)組的形式傳輸，每個數(shù)據(jù)組包含16 個32 位字，字號1～16 的LABEL 碼依次為 200～207、210～216、277。從圖 6 得知，其中 LABEL200字第29～24 位包含該數(shù)據(jù)組的組號X，跟隨其后的15 個32位字屬于該數(shù)據(jù)組X的內(nèi)容，實際X為1～60，即所有可能存在的數(shù)據(jù)組的組號范圍為1～60。

因此，所有數(shù)據(jù)組包含的信息能否正常被軟件識別，關(guān)鍵在于能否順利接收一個完整的數(shù)據(jù)組，并識別該數(shù)據(jù)組的第一個32 位字的數(shù)據(jù)組號。如果識別出有效的數(shù)據(jù)組號，則可以把該數(shù)據(jù)組其他32 位字的各數(shù)據(jù)位按ICD 內(nèi)容對號入座并解析。

圖6 ICD 中某循環(huán)數(shù)據(jù)組的頭字內(nèi)容

軟件采用如下流程可識別不同數(shù)據(jù)組：①沒收到頭字時，尋找頭字LABEL200。②收到頭字后，正常接收，并尋找尾字LABEL277。③在沒有收到尾字前，如果收到下一個頭字，將前一個頭字后面的數(shù)據(jù)全部保存到全局變量里，供以后使用。④在沒有收到尾字前，如果接收到32 位字累計達到16 個字或以上，將整個16 個字廢棄。這代表曾收到錯誤的不是16 個有效LABEL 碼的錯誤32 位字。⑤在累計接收到小于等于16 個32 位字，且收到尾字時，將已收到的全部32 位字根據(jù)頭字內(nèi)容保存在某數(shù)組里，供后續(xù)使用。一共有60 個數(shù)組，對應(yīng)保存1～60 數(shù)據(jù)組的內(nèi)容。數(shù)據(jù)組號由LABEL200 字的28～23 位2 進制數(shù)對應(yīng)的數(shù)值來確定。⑥軟件其他部分根據(jù)實際需要，按數(shù)據(jù)組A、字號B、數(shù)據(jù)起始位C、數(shù)據(jù)終止位D 的形式提取具體數(shù)據(jù)內(nèi)容。⑦數(shù)據(jù)更新頻率以實際從429 總線接收到的數(shù)據(jù)更新頻率為準(zhǔn)，有新的數(shù)據(jù)組正常接收到時，將覆蓋原有的舊數(shù)據(jù)組內(nèi)容。

軟件按上述流程解析，經(jīng)過實踐證明，可以正常識別每一個數(shù)據(jù)組，數(shù)據(jù)組內(nèi)容與實際載機操作保持一致。

4.3 SLIP 協(xié)議收發(fā)技術(shù)

機載系統(tǒng)不同設(shè)備之間的RS422 接口電路軟件層面采用的是SLIP（Serial Line Internet Protocol，串行線路因特網(wǎng)協(xié)議）協(xié)議進行通信[6]。SLIP 是一個簡單的面向字符的協(xié)議。在每個用戶信息幀的首尾各加一個特殊的標(biāo)志字節(jié)END，封裝成為SLIP 幀，如圖7 所示。標(biāo)識字節(jié)END 的編碼為（0xC0）。

圖7 SLIP 封裝示意圖

在發(fā)送的數(shù)據(jù)幀時，SLIP 協(xié)議將進行轉(zhuǎn)義工作：幀中0xC0 字節(jié)換成0xDB、0xDC；幀中0xDB 字節(jié)換成0xDB、0xDD。在接收數(shù)據(jù)幀時，SLIP 協(xié)議對幀中的數(shù)據(jù)做相反的轉(zhuǎn)義工作，即將0xDB、0xDC 換成0xC0，將0xDB、0xDD換成0xDB。

結(jié)合圖7 可知，對于發(fā)送數(shù)據(jù)，軟件在將數(shù)據(jù)寫到硬件RS422 接口緩存前，需要對原始被發(fā)送數(shù)據(jù)進行格式轉(zhuǎn)換，再將標(biāo)識字節(jié)0xC0 填加到數(shù)據(jù)的首尾；對于接收數(shù)據(jù)，軟件需要先尋找0xC0 字節(jié)并定位用戶信息幀的開頭，然后再尋找（可能需要等待硬件接收數(shù)據(jù)）下一個0xC0 字節(jié)，以確定一個完整用戶信息幀。接下來再進行格式轉(zhuǎn)換，可還原成原始數(shù)據(jù)。

軟件發(fā)送操作過程如圖8 所示。軟件接收操作過程如圖9 所示。

5 實驗及結(jié)果

現(xiàn)以某次飛行記錄文件為例介紹前端采集系統(tǒng)在實際實驗過程中的性能表現(xiàn)和結(jié)果分析。

數(shù)據(jù)流向如圖10 所示。

圖8 軟件發(fā)送SLIP 協(xié)議數(shù)據(jù)流圖

圖9 軟件接收SLIP 協(xié)議數(shù)據(jù)流圖

圖10 記錄器記錄三個文件的數(shù)據(jù)流圖

在前端采集系統(tǒng)中，軟件將火控系統(tǒng)1、2 的每個429字直接轉(zhuǎn)換為對應(yīng)4 個字節(jié)從RS422 總線發(fā)送至記錄器。軟件將武控系統(tǒng)和航行航姿一共6 路429 總線的數(shù)據(jù)合并為一路RS422 數(shù)據(jù)發(fā)送至記錄器，在此期間軟件需要完成原始429 數(shù)據(jù)的挑選、轉(zhuǎn)換與合成SLIP 協(xié)議數(shù)據(jù)包操作。數(shù)據(jù)挑選是將事后評估需要的429 數(shù)據(jù)挑選出來發(fā)送記錄器，以便節(jié)省發(fā)送422 線路的通訊資源。所有的429 總線波特率為50 000 bit/s，RS422 總線波特率為 921 600 bit/s。

記錄文件名稱為：cok1.bin、cok2.bin、dt2.bin，在飛行兩個多小時時間內(nèi)它們各項參數(shù)如表2 所示。

表2 記錄文件與串口資源占用率

根據(jù)表2 可知：cok1 和cok2 兩路火控系統(tǒng)數(shù)據(jù)發(fā)送的兩路422 線路通訊百分比為3.4%，代表這兩路422 線路上數(shù)據(jù)發(fā)送基本處于空閑狀態(tài)；而由于第3 路422 總線的源頭是6 路429 總線數(shù)據(jù)，數(shù)據(jù)量合成在一起可達50K×6=300 Kbit/s，再加上SLIP 協(xié)議包裝數(shù)據(jù)，實際數(shù)據(jù)量將更大，占用通訊資源百分比可達32%以上。

為了節(jié)省通訊資源，軟件采用必要措施進行優(yōu)化：將不必要原始429 數(shù)據(jù)剔除；以合適的固定時間間隔T發(fā)送合成后的SLIP 協(xié)議數(shù)據(jù)包，不采用收到即轉(zhuǎn)發(fā)的方式。因為生成一個SLIP 協(xié)議數(shù)據(jù)包需要至少在有效數(shù)據(jù)之外增加10 個字節(jié)，具體有數(shù)據(jù)長度，檢驗和之類的附加字節(jié)。如果每個429 字對應(yīng)的4 個字節(jié)都生成一個SLIP 包，最終通信量將至少擴大至原始的（10+4）/4≈3 倍以上，很有可能超過422線路的最大通訊容量92 160 Byte/s。

采用上述措施，軟件最終生成的數(shù)據(jù)量占通訊資源百分比為23.5%。代表實際422 線路有3/4 的時間處于空閑狀態(tài)，硬件發(fā)送緩存有3/4 的時間沒有數(shù)據(jù)，可靠完成數(shù)據(jù)發(fā)送。

6 總結(jié)

本文講述了空戰(zhàn)訓(xùn)練系統(tǒng)中機載系統(tǒng)的前端采集系統(tǒng)的作用意義、實現(xiàn)要求、實現(xiàn)技術(shù)關(guān)鍵點和解決技術(shù)方案，并通過已經(jīng)完成的實驗數(shù)據(jù)驗證了技術(shù)方案的可行性。對以往的工作進行詳細技術(shù)總結(jié)，對此后的工作具有借鑒和指導(dǎo)意義。

雖然前端采集系統(tǒng)在整個空戰(zhàn)訓(xùn)練系統(tǒng)中不屬于頂層核心系統(tǒng)，但它在底層擔(dān)負著所有信息通訊的關(guān)鍵任務(wù)，并將各型飛機不同通訊架構(gòu)的信息轉(zhuǎn)換為統(tǒng)一的消息口徑向其他統(tǒng)型化模塊提供服務(wù)。其數(shù)據(jù)量龐大，數(shù)據(jù)種類和協(xié)議繁雜，對軟件整體規(guī)劃和細節(jié)功能實現(xiàn)處都提出嚴(yán)格要求。采集系統(tǒng)可靠完成數(shù)據(jù)搬運工作是整個空戰(zhàn)訓(xùn)練系統(tǒng)正常運轉(zhuǎn)基石。