空戰訓練機載前端信息采集系統設計

朱金冬，孫繼平

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

1 背景和組成

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

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

空戰訓練系統組成和信息通訊如圖1 所示。

圖1 空戰訓練系統組成和信息通訊圖

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

2 采集系統重要性

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

圖2 機載系統中前端信息采集系統交聯關系圖

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

3 采集系統一般設計要求

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

圖3 數據經過硬件緩存與軟件處理和搬運流程圖

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

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

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

4 采集系統技術關鍵點

結合交聯關系圖，以某型機的機載系統為例，將前端信息采集系統設計過程中的技術關鍵點進行逐一介紹。

4.1 ARINC429 總線解析技術難點

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

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

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

4.2 ARINC429 總線解析解決方案

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

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

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

圖4 429 總線數據線上格式（上）和編程格式（下）對應關系圖

圖5 ICD 中可直接通過LABEL 碼解析的數據內容

表1 每個429 字LABEL 碼的拆分

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

針對第二個技術難點，結合圖6 進行說明。

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

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

圖6 ICD 中某循環數據組的頭字內容

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

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

4.3 SLIP 協議收發技術

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

圖7 SLIP 封裝示意圖

在發送的數據幀時，SLIP 協議將進行轉義工作：幀中0xC0 字節換成0xDB、0xDC；幀中0xDB 字節換成0xDB、0xDD。在接收數據幀時，SLIP 協議對幀中的數據做相反的轉義工作，即將0xDB、0xDC 換成0xC0，將0xDB、0xDD換成0xDB。

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

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

5 實驗及結果

現以某次飛行記錄文件為例介紹前端采集系統在實際實驗過程中的性能表現和結果分析。

數據流向如圖10 所示。

圖8 軟件發送SLIP 協議數據流圖

圖9 軟件接收SLIP 協議數據流圖

圖10 記錄器記錄三個文件的數據流圖

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

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

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

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

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

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

6 總結

本文講述了空戰訓練系統中機載系統的前端采集系統的作用意義、實現要求、實現技術關鍵點和解決技術方案，并通過已經完成的實驗數據驗證了技術方案的可行性。對以往的工作進行詳細技術總結，對此后的工作具有借鑒和指導意義。

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