基于中間件的裝備跨平臺(tái)軟件設(shè)計(jì)

楊柳 汪相國 黃勇韜

（中國電子科技集團(tuán)公司第二十九研究所 四川省成都市 610036）

1 引言

伴隨作戰(zhàn)環(huán)境、作戰(zhàn)對(duì)象和作戰(zhàn)樣式的跨越式發(fā)展，裝備從單一功能的個(gè)體演進(jìn)為攻防兼?zhèn)涞木C合協(xié)同作戰(zhàn)平臺(tái)單元。當(dāng)前面向特定的硬件平臺(tái)開發(fā)的專用軟件，軟硬件緊耦合，不能滿足綜合協(xié)同作戰(zhàn)平臺(tái)單元開放式集成、靈活部署、快速升級(jí)的需求。裝備軟件一旦設(shè)計(jì)定型，就不能遷移部署，限制了系統(tǒng)功能的橫向擴(kuò)展。硬件升級(jí)以后，軟件移植適配工作量大，系統(tǒng)縱向升級(jí)效率低。進(jìn)一步由于人工智能信號(hào)處理算法的仿真驗(yàn)證平臺(tái)通常為X86 處理器和Windows 操作系統(tǒng)，而實(shí)際裝備運(yùn)行在PowerPC 或ARM 嵌入式處理器和實(shí)時(shí)操作系統(tǒng)。這就需要屏蔽平臺(tái)差異，確保算法的仿真驗(yàn)證效能在實(shí)際電磁環(huán)境中具備一致性。

裝備軟件跨平臺(tái)設(shè)計(jì)是上述問題的有效解決方案。最基礎(chǔ)的跨平臺(tái)技術(shù)為IEEE POSIX 標(biāo)準(zhǔn)，但國產(chǎn)操作系統(tǒng)對(duì)POSIX 標(biāo)準(zhǔn)不完全兼容，諸如任務(wù)創(chuàng)建、信號(hào)量創(chuàng)建、文件管理等關(guān)鍵接口實(shí)現(xiàn)均不同。在類UNIX 系統(tǒng)中有POCO、Boost 等開源跨平臺(tái)軟件中間件，這些庫代碼規(guī)模均在10W 行以上，編譯后的執(zhí)行體10MB 以上。對(duì)于裝備計(jì)算處理資源受限條件，規(guī)模偏重，擠占裝備應(yīng)用軟件運(yùn)行內(nèi)存。并且均不提供消息通信服務(wù)，軟件開發(fā)人員仍需關(guān)注底層數(shù)據(jù)傳輸細(xì)節(jié)。

面向異構(gòu)運(yùn)行環(huán)境，本文提出了基于中間件的裝備軟件跨平臺(tái)框架。采用該框架，在飛騰FT2000A 處理器和PowerPC 處理器組成的混合計(jì)算處理硬件平臺(tái)上進(jìn)行了工程實(shí)現(xiàn)和應(yīng)用驗(yàn)證。

2 軟件中間件概述

當(dāng)系統(tǒng)越來越復(fù)雜后，必然會(huì)向分布式方向發(fā)展。軟件中間件通過提供簡(jiǎn)單、一致、集成的分布式編程環(huán)境，簡(jiǎn)化分布式應(yīng)用軟件的設(shè)計(jì)和部署。對(duì)象管理組織（OMG）發(fā)布的CORBA 和DDS 中間件技術(shù)標(biāo)準(zhǔn)，引領(lǐng)了軟件中間件技術(shù)發(fā)展趨勢(shì)，解決了分布式對(duì)象間跨網(wǎng)絡(luò)、跨操作系統(tǒng)、跨編程語言的數(shù)據(jù)交互問題。CORBA 同時(shí)也提供了基于對(duì)象請(qǐng)求代理的分布式對(duì)象訪問服務(wù)。DDS 則是利用以數(shù)據(jù)為驅(qū)動(dòng)的消息發(fā)布-訂閱模型，具備完善的數(shù)據(jù)傳輸Qos策略。

ZeroMQ通信中間件對(duì)套接字、網(wǎng)絡(luò)幀、路由進(jìn)行了抽象，支持在進(jìn)程內(nèi)、進(jìn)程間和跨機(jī)器的多種消息傳遞模式。這些模式包括管道、請(qǐng)求-應(yīng)答、發(fā)布-訂閱。上述幾種中間件在軟件化雷達(dá)、航空電子任務(wù)系統(tǒng)、火控系統(tǒng)均有應(yīng)用案例，提升了裝備互聯(lián)互通和快速反應(yīng)能力。

3 跨平臺(tái)軟件框架設(shè)計(jì)

3.1 整體架構(gòu)

吸收“開放式、分層解耦、面向服務(wù)”的思想，充分考慮“低時(shí)延、大帶寬、高可靠”的通信需求，采用軟件中間件技術(shù)，提出了裝備軟件整體架構(gòu)。該架構(gòu)通過對(duì)計(jì)算處理器和操作系統(tǒng)抽象封裝，構(gòu)建了統(tǒng)一的跨平臺(tái)軟件框架，最大化頂層應(yīng)用APP 跨平臺(tái)開發(fā)和運(yùn)行能力。軟件整體架構(gòu)分為5 層，各層次功能介紹如下：

（1）外設(shè)傳感器層：裝備內(nèi)部各種硬件模塊，包括：射頻前端、數(shù)字接收模塊、信號(hào)處理模塊等。裝備外部的綜合顯控任務(wù)系統(tǒng)、環(huán)控設(shè)備、導(dǎo)航設(shè)備等。它們通過光電接口掛接到物理總線，總線上的節(jié)點(diǎn)可以動(dòng)態(tài)改變，組網(wǎng)靈活。

（2）計(jì)算處理層：封裝底層硬件細(xì)節(jié)，實(shí)現(xiàn)對(duì)外設(shè)傳感器的操作和管理，由通用計(jì)算處理平臺(tái)GPP（General Proccess Platform）及運(yùn)行其上的板級(jí)支持包和各種總線驅(qū)動(dòng)程序組成。對(duì)每一類物理通訊接口，該層向數(shù)據(jù)傳輸服務(wù)DTS(Data Transmission Service)提供標(biāo)準(zhǔn)的初始化和讀寫接口，并且輸出格式化統(tǒng)一定義的數(shù)據(jù)幀，向各個(gè)物理設(shè)備開展個(gè)性化的物理總線驅(qū)動(dòng)適配。

（3）操作系統(tǒng)層：包含操作系統(tǒng)和數(shù)據(jù)庫軟件，提供各類操作系統(tǒng)服務(wù)、文件系統(tǒng)服務(wù)和數(shù)據(jù)庫持久化存儲(chǔ)服務(wù)。

（4）中間件層：運(yùn)行在計(jì)算處理平臺(tái)上的統(tǒng)一軟件框架，將其命名為裝備跨平臺(tái)軟件框架ECSF(Equipment Cross-platform Software Framework)。它為應(yīng)用層提供通用軟件服務(wù)，是實(shí)現(xiàn)應(yīng)用APP 跨平臺(tái)移植和復(fù)用的關(guān)鍵。

（5）領(lǐng)域應(yīng)用層：裝備軟件應(yīng)用APP 的聚合，按功能模塊劃分，包括系統(tǒng)管控APP、敵我識(shí)別APP、信號(hào)處理APP、數(shù)據(jù)融合APP 等。

3.2 框架組成

軟件框架由數(shù)據(jù)傳輸服務(wù)、應(yīng)用APP 管理服務(wù)、虛擬操作系統(tǒng)服務(wù)三個(gè)模塊組成，分別在不同維度支撐應(yīng)用APP跨平臺(tái)的設(shè)計(jì)開發(fā)和分布式運(yùn)行。根據(jù)整體架構(gòu)中的相關(guān)需求分配，框架的實(shí)現(xiàn)如圖1所示。

圖1：裝備跨平臺(tái)軟件框架ECSF 類圖

（1）數(shù)據(jù)傳輸服務(wù)：提供應(yīng)用APP 之間的控制消息和數(shù)據(jù)流統(tǒng)一傳遞接口，使應(yīng)用APP 之間的數(shù)據(jù)交互不僅具有松耦合特性，而且具有跨平臺(tái)通信的特性。應(yīng)用APP 只需要關(guān)注訂閱的控制消息或數(shù)據(jù)流，而不用關(guān)注發(fā)布方的部署位置。

（2）應(yīng)用APP 管理服務(wù)：提供應(yīng)用APP 運(yùn)行范式，應(yīng)用APP 的啟動(dòng)和運(yùn)行過程標(biāo)準(zhǔn)化，使得運(yùn)行在不同計(jì)算處理平臺(tái)的應(yīng)用APP 具有相同的CPU 資源調(diào)度方式，實(shí)現(xiàn)了軟件和具體的計(jì)算處理平臺(tái)松耦合集成。

（3）虛擬操作系統(tǒng)服務(wù)：提供應(yīng)用APP 訪問操作系統(tǒng)的統(tǒng)一標(biāo)準(zhǔn)接口，使得應(yīng)用APP 在不同操作系統(tǒng)之間的切換運(yùn)行，簡(jiǎn)化成在對(duì)應(yīng)的集成開發(fā)環(huán)境下的一鍵構(gòu)建完成快速發(fā)布。

3.3 數(shù)據(jù)傳輸服務(wù)

針對(duì)大量數(shù)據(jù)傳輸場(chǎng)景，設(shè)計(jì)了控制消息和數(shù)據(jù)流隔離的分布式并行軟總線，具有“大帶寬、低時(shí)延、可擴(kuò)展”的特點(diǎn)，通信模型如圖2所示。通訊管理及協(xié)議轉(zhuǎn)換管理器負(fù)責(zé)完成以太網(wǎng)和RapidIO 網(wǎng)絡(luò)的通信自組網(wǎng)和拓?fù)涔芾?，DDS 傳輸組件的節(jié)點(diǎn)發(fā)現(xiàn)和發(fā)布訂閱消息注冊(cè)，以及RapidIO 邏輯節(jié)點(diǎn)ID 分配和收發(fā)數(shù)據(jù)端口配置。

圖2：分布式并行軟總線通信模型

對(duì)于強(qiáng)實(shí)時(shí)的控制消息，消息的發(fā)布方遵循標(biāo)準(zhǔn)的應(yīng)用報(bào)文格式進(jìn)行打包處理，推送至控制消息總線，同步通知通訊管理及協(xié)議轉(zhuǎn)換管理器進(jìn)行后續(xù)處理。通訊管理及協(xié)議轉(zhuǎn)換管理器從控制消息總線取出一條消息，將其按照傳輸報(bào)文格式進(jìn)行打包處理，自適應(yīng)選擇傳輸協(xié)議。如果訂閱方APP和發(fā)布方APP 部署在同一個(gè)運(yùn)算平臺(tái)內(nèi)，選擇共享內(nèi)存進(jìn)行交互，不會(huì)通過物理總線進(jìn)行傳輸，提高通信效率。否則，選擇DDS 方式，發(fā)送至對(duì)端的通訊管理及協(xié)議轉(zhuǎn)換管理器，對(duì)傳輸報(bào)文進(jìn)行解包處理推送至控制消息總線。

對(duì)于高頻、大量的流式數(shù)據(jù)，單獨(dú)設(shè)置數(shù)據(jù)流應(yīng)用總線進(jìn)行處理。流式數(shù)據(jù)在通訊管理及協(xié)議轉(zhuǎn)換管理器打包處理后，將數(shù)據(jù)存放地址和長(zhǎng)度構(gòu)成的數(shù)據(jù)塊描述信息放入消息隊(duì)列，避免由于動(dòng)態(tài)開辟內(nèi)存導(dǎo)致的通信延遲。應(yīng)用報(bào)文格式中的類型標(biāo)明其為數(shù)據(jù)消息，自動(dòng)選擇RapidIO 作為跨CPU 傳輸?shù)奈锢砜偩€。RapidIO 總線提供的DMA 傳輸模式，最大支持6Gbps 的傳輸速率。

通訊管理及協(xié)議轉(zhuǎn)換管理器可擴(kuò)展至其它類型的物理總線，經(jīng)過簡(jiǎn)單適配即可快速接入飛機(jī)平臺(tái)。例如裝備升級(jí)時(shí)，由于硬件限制，無法部署DDS 傳輸組件，原運(yùn)算平臺(tái)只有FC 總線，又希望能應(yīng)用新開發(fā)的組件，節(jié)省開發(fā)時(shí)間。

3.4 應(yīng)用APP管理服務(wù)

應(yīng)用APP 管理服務(wù)提供應(yīng)用APP 跨平臺(tái)運(yùn)行的標(biāo)準(zhǔn)范式，使得應(yīng)用APP 在不同的運(yùn)行環(huán)境中，具備相同的執(zhí)行流程和結(jié)果?；谠摽蚣?，裝備軟件應(yīng)用APP 自啟動(dòng)流程如圖3所示。設(shè)備上電啟動(dòng)，首先解析系統(tǒng)配置文件，獲取軟件執(zhí)行體加載路徑、運(yùn)行入口函數(shù)名稱和消息路由關(guān)系。利用運(yùn)行入口函數(shù)名稱，在軟件執(zhí)行體中進(jìn)行符號(hào)表同步搜索，定位軟件運(yùn)行的入口地址。然后跳轉(zhuǎn)到入口地址，動(dòng)態(tài)創(chuàng)建APP 對(duì)象，并根據(jù)配置參數(shù)，完成初始化。接下來注冊(cè)控制消息和數(shù)據(jù)流，實(shí)例化APP 的輸出和輸出端口，分配端口邏輯ID，合并APP 內(nèi)部各個(gè)進(jìn)程間的消息路由關(guān)系。最后根據(jù)設(shè)定的順序，依次啟動(dòng)各個(gè)APP。應(yīng)用APP 狀態(tài)維護(hù)消息在多個(gè)物理節(jié)點(diǎn)之間進(jìn)行廣播，實(shí)現(xiàn)了應(yīng)用APP運(yùn)行狀態(tài)的相互感知和分布式啟動(dòng)停止控制。

圖3：軟件框架自啟動(dòng)應(yīng)用APP 流程

應(yīng)用APP 在運(yùn)行狀態(tài)中，周期性輪詢控制消息隊(duì)列是否非空。數(shù)據(jù)傳輸服務(wù)作為生產(chǎn)者，將訂閱的消息加入消息隊(duì)列。應(yīng)用APP 作為消費(fèi)者從消息隊(duì)列中提取出全部消息，進(jìn)行相應(yīng)的計(jì)算處理。對(duì)于數(shù)據(jù)流的處理，區(qū)別在于單個(gè)處理周期內(nèi)只取出一條數(shù)據(jù)流，并且單次最大處理時(shí)間不超過100ms。通過該設(shè)計(jì)，避免了大數(shù)據(jù)流處理長(zhǎng)時(shí)間占用CPU資源，顯著提高了軟件實(shí)時(shí)性。如果接收到停止命令，執(zhí)行垃圾回收處理，釋放占用的CPU 和內(nèi)存資源。

3.5 虛擬操作系統(tǒng)服務(wù)

虛擬操作系統(tǒng)服務(wù)對(duì)應(yīng)用APP 提供統(tǒng)一的API 訪問接口，覆蓋操作系統(tǒng)提供的各類服務(wù)，包括線程、信號(hào)量、任務(wù)鎖、文件操作相關(guān)。操作系統(tǒng)API 訪問具有跨操作系統(tǒng)特性，不同操作系統(tǒng)的相同功能的訪問接口保持一致。例如在Windows 操作系統(tǒng)中信號(hào)量創(chuàng)建的接口為CreateSemaphore，在國產(chǎn)銳化操作系統(tǒng)Reworks 該接口為SemCreate，對(duì)其進(jìn)行抽象封裝后，虛擬操作系統(tǒng)服務(wù)中提供的統(tǒng)一接口為VOS::SemCreate。

根據(jù)不同的操作系統(tǒng)分支，進(jìn)入具體實(shí)現(xiàn)對(duì)象XX_OSImpl，兼容的操作系統(tǒng)包括：Windows、Vxworks、銳華、天脈系列。具體實(shí)現(xiàn)對(duì)象XX_OSImpl 的細(xì)節(jié)對(duì)應(yīng)用APP 不可見，可以方便擴(kuò)展到其它操作系統(tǒng)，并且靜態(tài)內(nèi)存占用約100KB，靈活高效。

4 工程實(shí)現(xiàn)與應(yīng)用驗(yàn)證

4.1 計(jì)算處理硬件平臺(tái)

計(jì)算處理硬件平臺(tái)遵循OpenVPX 規(guī)范設(shè)計(jì)，用于信號(hào)處理、數(shù)據(jù)處理等通用處理運(yùn)算。為了兼容異構(gòu)處理架構(gòu)，滿足多種個(gè)性需求，采用載扣板結(jié)構(gòu)。載板由交換芯片、主控FPGA 和光模塊組成，不實(shí)現(xiàn)特定的計(jì)算架構(gòu)，支持多個(gè)扣板實(shí)現(xiàn)不同的計(jì)算需求。兩塊交換芯片可通過光連接或電連接加入全交換網(wǎng)絡(luò)，實(shí)現(xiàn)信號(hào)接入，分別綁定SRIO 協(xié)議和以太網(wǎng)協(xié)議?？郯逵蓛善w騰FT-2000A 處理器和兩片飛思卡爾T2080 處理器組成，混合異構(gòu)多核處理器滿足工程實(shí)現(xiàn)的高負(fù)荷計(jì)算要求。

計(jì)算處理硬件平臺(tái)內(nèi)部的每片處理器均有一個(gè)4X 的SRIO 接口和兩個(gè)1000Mbps 的以太網(wǎng)網(wǎng)卡，為跨平臺(tái)軟件框架的高速數(shù)據(jù)傳輸提供硬件支持。通用載板組合不同處理架構(gòu)的扣板可實(shí)現(xiàn)不同功能的計(jì)算處理單元，扣板上處理器也可靈活增加或減少，匹配各種場(chǎng)景下的運(yùn)算性能和運(yùn)算量需求。

4.2 雷達(dá)告警器軟件跨平臺(tái)運(yùn)行

將提出的框架應(yīng)用到雷達(dá)告警器設(shè)計(jì)，開發(fā)的告警系統(tǒng)軟件包括系統(tǒng)綜合管控APP、信號(hào)分選與識(shí)別APP、信號(hào)融合APP，部署在前述硬件平臺(tái)的構(gòu)型如圖4所示。其中P+V 表示運(yùn)行環(huán)境為PPC 架構(gòu)的T2080 處理器和風(fēng)河操作系統(tǒng)，F(xiàn)+R 則表示運(yùn)行環(huán)境為ARM 架構(gòu)的國產(chǎn)FT2000A處理器和銳華操作系統(tǒng)。

圖4：雷達(dá)告警器軟件部署構(gòu)型1

系統(tǒng)綜合管控APP 負(fù)責(zé)從信號(hào)處理初級(jí)處理單元周期提取經(jīng)過稀釋和去交錯(cuò)處理的原始脈沖描述字?jǐn)?shù)據(jù)流。依靠框架提供的數(shù)據(jù)傳輸服務(wù)，發(fā)送給信號(hào)分選與識(shí)別APP，進(jìn)行分離和參數(shù)匹配處理，確認(rèn)輻射源的平臺(tái)類型和工作模式等特征。信號(hào)融合APP 負(fù)責(zé)對(duì)威脅目標(biāo)進(jìn)行消失活動(dòng)管理，統(tǒng)一編號(hào)后發(fā)送給系統(tǒng)綜合管控APP。系統(tǒng)綜合管控APP對(duì)威脅目標(biāo)進(jìn)行格式轉(zhuǎn)換后，通過專用的FC 總線，發(fā)送給航電任務(wù)處理機(jī)顯示雷達(dá)輻射源態(tài)勢(shì)。

為應(yīng)對(duì)新體制雷達(dá)對(duì)象，需要對(duì)上述基礎(chǔ)業(yè)務(wù)模型進(jìn)行升級(jí)。首先對(duì)重點(diǎn)頻段雷達(dá)信號(hào)進(jìn)行單獨(dú)處理，構(gòu)成告警偵察綜合系統(tǒng)。同時(shí)需要利用多機(jī)協(xié)同的方位信息，對(duì)輻射源進(jìn)行精測(cè)向處理。依賴本框架提供的跨平臺(tái)開發(fā)和運(yùn)行能力，可以快速切換應(yīng)用APP 的運(yùn)行環(huán)境，形成擴(kuò)展業(yè)務(wù)模型，如圖5所示。

圖5：雷達(dá)告警器軟件部署構(gòu)型2

軟件總線化使得應(yīng)用APP 之間通過平臺(tái)無關(guān)的消息接口進(jìn)行交互，應(yīng)用APP 部署位置發(fā)生變換后，原有的通信模式保持不變。如果采用傳統(tǒng)的TCP 套接字通信，則需要重新配置服務(wù)器和客戶端IP 地址。

4.3 信號(hào)處理算法跨平臺(tái)驗(yàn)證

基于該框架在某型裝備研制中，實(shí)現(xiàn)了在Windows 桌面平臺(tái)對(duì)飛行記錄數(shù)據(jù)的回放，發(fā)現(xiàn)信號(hào)處理算法邏輯中存在的問題。通過在Windows 平臺(tái)修正、完成驗(yàn)證，早期部署到實(shí)裝的風(fēng)河Vxworks5.5 上，最后切換運(yùn)行到國產(chǎn)天脈1 平臺(tái)上。具體方法如下：

（1）在微軟Visual Studio 2010 環(huán)境中編譯生成信號(hào)處理APP 軟件exe 執(zhí)行體；

（2）在Windows 平臺(tái)上部署運(yùn)行信號(hào)處理APP 軟件，將飛行數(shù)據(jù)輸入給軟件；

（3）在Windows 平臺(tái)上進(jìn)行可視化的運(yùn)行和分析；

（4）發(fā)現(xiàn)軟件問題和待優(yōu)化的核心算法邏輯，在Windows 平臺(tái)上修改后閉環(huán)驗(yàn)證；

（5）在Windows 平臺(tái)驗(yàn)證完畢后，在Tornado 集成開發(fā)環(huán)境中編譯生成信號(hào)處理APP 軟件out 執(zhí)行體，部署運(yùn)行在裝備中的進(jìn)口Vxworks5.5 平臺(tái)；

（6）在LamdaE 集成開發(fā)環(huán)境中編譯生成信號(hào)處理APP 軟件rel 執(zhí)行體，部署運(yùn)行在裝備中的國產(chǎn)天脈1 平臺(tái)。

5 結(jié)論

本文基于中間件技術(shù)，構(gòu)建了裝備跨平臺(tái)軟件框架，將應(yīng)用程序、數(shù)據(jù)傳輸總線、基礎(chǔ)硬件架構(gòu)分層隔離，增強(qiáng)了應(yīng)用程序的可移植性，實(shí)現(xiàn)了一次開發(fā)、多平臺(tái)部署運(yùn)行，低成本兼容硬件處理平臺(tái)的替代換型。由于跨平臺(tái)復(fù)用的軟件標(biāo)準(zhǔn)接口封裝和代碼重用，不需要額外的軟件測(cè)試工作，軟件可維護(hù)性良好。后續(xù)可對(duì)該框架進(jìn)行功能擴(kuò)展，研究增加消息隊(duì)列的持久化存儲(chǔ)和遠(yuǎn)程通信的序列化和反序列化。