，， ， ，

(中國航空工業(yè)集團(tuán)公司成都飛機(jī)設(shè)計(jì)研究所，成都 610091)

0 引言

航空機(jī)載軟件驗(yàn)證工作貫穿機(jī)載系統(tǒng)從研制、使用到升級維護(hù)的整個生命周期，涉及不同的學(xué)科和領(lǐng)域，相互交叉。近年來，隨著科學(xué)技術(shù)的迅速發(fā)展以及高新技術(shù)在新一代戰(zhàn)斗機(jī)中的大規(guī)模運(yùn)用，航空機(jī)載系統(tǒng)的能力不斷提升，系統(tǒng)的綜合化程度和復(fù)雜度也越來越高，導(dǎo)致機(jī)載軟件驗(yàn)證也成為了一項(xiàng)復(fù)雜的工作[1]。因此，航空機(jī)載軟件的驗(yàn)證應(yīng)與軟件的設(shè)計(jì)同計(jì)劃、同實(shí)施，建立有效的技術(shù)及管理手段，以保證航空機(jī)載軟件整個生命周期的驗(yàn)證工作順利開展。

文獻(xiàn)[1]指出，大部分的錯誤是在系統(tǒng)綜合、項(xiàng)目試飛及使用維護(hù)階段發(fā)現(xiàn)的。為減少系統(tǒng)綜合、地面試驗(yàn)以及試飛的壓力，應(yīng)在軟件配置項(xiàng)、系統(tǒng)級對軟件邏輯、接口、性能等技術(shù)指標(biāo)進(jìn)行充分的驗(yàn)證。目前，機(jī)載軟件配置項(xiàng)、系統(tǒng)測試主要依賴各專業(yè)的半實(shí)物仿真綜合試驗(yàn)臺，試驗(yàn)臺搭建過程中主要考慮的是設(shè)計(jì)調(diào)試及系統(tǒng)綜合驗(yàn)證的要求，對軟件驗(yàn)證要求的支持不充分；仿真綜合試驗(yàn)臺除支持企業(yè)內(nèi)專業(yè)完成科研任務(wù)外，還需為其他單位的系統(tǒng)綜合集成，定型鑒定測評提供支撐，受硬件資源限制，試驗(yàn)臺資源十分緊缺；機(jī)載軟件系統(tǒng)級驗(yàn)證涉及電、液、油等專業(yè)交叉仿真，開環(huán)驗(yàn)證系統(tǒng)已經(jīng)無法滿足系統(tǒng)交互需求，需要考慮構(gòu)建一套多學(xué)科聯(lián)合仿真的機(jī)制來保障驗(yàn)證效果。

軟件驗(yàn)證是機(jī)載軟件研制生命周期的重要一環(huán)，應(yīng)提倡盡早開展軟件測試，從軟件需求分析階段開始，同步開展軟件測試工作，即軟件開發(fā)與驗(yàn)證的協(xié)同。但是傳統(tǒng)的機(jī)載軟件驗(yàn)證大多仍采用的是V模型或螺旋迭代模型的方式，軟件測試滯后于開發(fā)，即系統(tǒng)設(shè)計(jì)、軟件需求分析、軟件設(shè)計(jì)、軟件編碼期間，軟件驗(yàn)證部門可能無法從事任何工作；只有軟件研發(fā)部門將軟件需求、設(shè)計(jì)或代碼移交給軟件驗(yàn)證部門，才能進(jìn)行下一步的工作。

隨著虛擬仿真技術(shù)的日漸成熟及工程中的大量應(yīng)用，飛機(jī)數(shù)字化功能樣機(jī)、虛擬飛行試驗(yàn)、飛機(jī)虛擬維護(hù)保障等在行業(yè)內(nèi)早已不是新聞。通過虛擬仿真技術(shù)，被測軟件可完全脫離真實(shí)目標(biāo)機(jī)運(yùn)行在虛擬目標(biāo)系統(tǒng)中，能充分進(jìn)行有效的軟件驗(yàn)證；在資源或進(jìn)度緊缺的情況下，利用虛擬仿真系統(tǒng)可以使軟件開發(fā)驗(yàn)證工作協(xié)同并行，加快軟件研制周期?？梢灶A(yù)見全數(shù)字、虛擬化是未來機(jī)載軟件驗(yàn)證技術(shù)發(fā)展的趨勢。機(jī)載系統(tǒng)仿真相關(guān)學(xué)科發(fā)展可謂迅速，飛機(jī)設(shè)計(jì)所各專業(yè)均逐步建立起所研制系統(tǒng)的全數(shù)字仿真環(huán)境，為實(shí)現(xiàn)各部門之間的仿真環(huán)境資源共享及軟件開發(fā)驗(yàn)證協(xié)同，作為軟件測試部門，重新開發(fā)實(shí)現(xiàn)所有專業(yè)的全數(shù)字仿真環(huán)境難度較大。針對現(xiàn)狀，最好的方案是在保持原有各專業(yè)的仿真系統(tǒng)自治的情況下，實(shí)現(xiàn)系統(tǒng)之間的信息交互。

針對以上問題，需充分發(fā)揮飛機(jī)設(shè)計(jì)所各專業(yè)的優(yōu)勢，設(shè)計(jì)一套開放的互聯(lián)架構(gòu)，實(shí)現(xiàn)專業(yè)已有資源和經(jīng)驗(yàn)的整合，構(gòu)建基于全數(shù)字仿真的軟件驗(yàn)證執(zhí)行環(huán)境；為實(shí)現(xiàn)軟件測試自動化，多學(xué)科聯(lián)合仿真，需在執(zhí)行環(huán)境之上，構(gòu)建軟件驗(yàn)證主控環(huán)境[2]；為實(shí)現(xiàn)軟件開發(fā)驗(yàn)證協(xié)同，需將軟件驗(yàn)證過程納入企業(yè)內(nèi)精益研發(fā)平臺進(jìn)行管理，需打通已有測試管理平臺與主控環(huán)境的數(shù)據(jù)接口，重新制定軟件開發(fā)驗(yàn)證的協(xié)同流程，并將已有數(shù)據(jù)進(jìn)行融合。

本文提出了一種全數(shù)字航空機(jī)載軟件驗(yàn)證平臺的設(shè)計(jì)方案，機(jī)載軟件驗(yàn)證平臺分為執(zhí)行層、主控層和管理層。在執(zhí)行層，基于企業(yè)內(nèi)各專業(yè)已有的全數(shù)字仿真系統(tǒng)、多學(xué)科仿真模型，設(shè)計(jì)了一套以數(shù)據(jù)為中心的框架，實(shí)現(xiàn)系統(tǒng)之間的互聯(lián)互通；在主控層，考慮軟件測試要求及測試的可讀性、可維護(hù)性需求，提出了采用基于測試場景的測試用例設(shè)計(jì)方法，實(shí)現(xiàn)測試場景與測試用例數(shù)據(jù)的分離，這對驗(yàn)證工作的分工安排、工作交接維護(hù)具有較大的意義；在管理層，對已有的企業(yè)級測試管理系統(tǒng)進(jìn)行擴(kuò)展，增加開發(fā)、驗(yàn)證人員協(xié)同工作模塊，打通軟件需求、設(shè)計(jì)、測試項(xiàng)、測試場景、測試用例的關(guān)聯(lián)關(guān)系，實(shí)現(xiàn)開發(fā)驗(yàn)證的協(xié)同管理。

1 機(jī)載軟件驗(yàn)證平臺應(yīng)用場景

假定某單位的系統(tǒng)室A、軟件室B、軟件測評中心C需要及時交互信息從而完成某機(jī)載系統(tǒng)的軟件研制工作。部門之間的業(yè)務(wù)交互關(guān)系如圖1所示。交互需求為：

圖1 部門業(yè)務(wù)場景圖

1)系統(tǒng)室A負(fù)責(zé)某系統(tǒng)的設(shè)計(jì)工作。

2)軟件室B負(fù)責(zé)該系統(tǒng)的軟件需求分析、設(shè)計(jì)及代碼實(shí)現(xiàn)工作。

3)軟件測評中心C負(fù)責(zé)該系統(tǒng)軟件的測試工作。

4)系統(tǒng)室A向軟件室B提供系統(tǒng)環(huán)境用于軟件開發(fā)設(shè)計(jì)工作。當(dāng)系統(tǒng)室A對系統(tǒng)環(huán)境發(fā)生更改時，需要將及時將更改情況反饋給軟件室B，以保證系統(tǒng)與軟件技術(shù)狀態(tài)的一致性。

5)軟件室B使用系統(tǒng)環(huán)境進(jìn)行軟件需求、設(shè)計(jì)、代碼實(shí)現(xiàn)工作。軟件室B與系統(tǒng)室A確認(rèn)軟件開發(fā)產(chǎn)品符合要求后，將系統(tǒng)軟件交付給軟件測評中心C進(jìn)行測試。當(dāng)軟件室B對該系統(tǒng)軟件發(fā)生需求、設(shè)計(jì)或代碼更改時，需要及時地把系統(tǒng)及軟件的信息反饋給軟件測評中心C。軟件室B接收軟件測評中心C反饋的測試狀態(tài)及問題單，如果問題修改涉及到系統(tǒng)，則把問題單反饋給系統(tǒng)室A；如果問題不涉及系統(tǒng)，則軟件室B把問題進(jìn)行處理，然后將問題單處理情況反饋給軟件測評中心C。

6)軟件測評中心C對軟件室B交付的軟件工作產(chǎn)品進(jìn)行技術(shù)狀態(tài)確認(rèn)后，在系統(tǒng)環(huán)境上進(jìn)行軟件的相關(guān)驗(yàn)證工作。軟件測評中心C在驗(yàn)證工作過程中，同步將測試項(xiàng)與軟件需求、設(shè)計(jì)的追蹤關(guān)聯(lián)、測試用例、軟件問題等過程數(shù)據(jù)反饋到測試管理系統(tǒng)。軟件測評中心C通過測試管理系統(tǒng)跟蹤確認(rèn)軟件問題的處理情況。軟件測評中心C調(diào)用測試管理系統(tǒng)進(jìn)行回歸測試。

另外，在型號不同的研制階段，軟件驗(yàn)證場景包括以下：

1)C階段。該階段軟件需求、代碼C型件初步確定，系統(tǒng)真件仍在驗(yàn)證過程中。在真件未能到位的情況下，使用全數(shù)字仿真方式，能夠模擬被測系統(tǒng)的硬件環(huán)境，有利于軟件測試的盡早介入，可盡早明確測試功能及運(yùn)行環(huán)境的需求、進(jìn)一步確定測試方法，開展測試項(xiàng)分解、測試場景設(shè)計(jì)工作。

2)S階段。該階段軟件需求，代碼S型件需反復(fù)迭代開發(fā)驗(yàn)證。并且系統(tǒng)真件已交付到軟件專業(yè)，主要用于軟件開發(fā)調(diào)試及系統(tǒng)試驗(yàn)等工作。這時軟件開發(fā)、測試存在測試資源上的沖突，可能會導(dǎo)致軟件測試工作進(jìn)度受到影響。通過全數(shù)字仿真與快速原型系統(tǒng)(RCP)相結(jié)合的方式，具有不受被測系統(tǒng)真實(shí)環(huán)境印象，易于實(shí)施、易于復(fù)制，環(huán)境需求低、成本相對較低的特點(diǎn)，在此基礎(chǔ)上加入多學(xué)科仿真，將外圍交聯(lián)系統(tǒng)的仿真模型與虛擬仿真目標(biāo)機(jī)一起，形成閉環(huán)的軟件驗(yàn)證系統(tǒng)，軟件配置項(xiàng)、系統(tǒng)級的功能、接口的驗(yàn)證工作可以在全數(shù)字仿真與RCP環(huán)境開展，一定程度緩解測試環(huán)境資源沖突的問題。

3)D及P階段。該階段軟件需求、代碼基本穩(wěn)定。軟件及其成品進(jìn)入定型及批產(chǎn)階段。為保證與真實(shí)環(huán)境一致性，軟件確認(rèn)測試、軟件定型大多數(shù)采用半實(shí)物仿真方式開展。但該階段飛機(jī)各項(xiàng)科研試飛工作仍在繼續(xù)，軟件仍需排故、升級及維護(hù)保障。該階段時間要求比較緊，專業(yè)希望系統(tǒng)確認(rèn)與軟件驗(yàn)證工作能夠同時進(jìn)行。使用全數(shù)字仿真環(huán)境，能夠?qū)⒋蟛糠周浖δ茯?yàn)證工作在虛擬仿真條件完成，不受真實(shí)環(huán)境影響。

2 機(jī)載軟件驗(yàn)證平臺架構(gòu)

由于各專業(yè)的全數(shù)字仿真目標(biāo)系統(tǒng)、多學(xué)科仿真模型、分布式軟件應(yīng)用以及測試管理系統(tǒng)采用的軟件架構(gòu)、操作系統(tǒng)、通信方式不相同，系統(tǒng)之間無法直接進(jìn)行交互，所以，需要在這些目標(biāo)機(jī)、模型、軟件應(yīng)用及系統(tǒng)之下，建立一套通信機(jī)制，實(shí)現(xiàn)現(xiàn)有試驗(yàn)資源的數(shù)據(jù)交互，并且具備兼容性，兼容其他設(shè)備的數(shù)據(jù)網(wǎng)絡(luò)，具備可配置性，支持模型、設(shè)備的動態(tài)加載。

數(shù)據(jù)分發(fā)服務(wù)DDS(Data Distribution Service)是對象管理組織(OMG)在HLA及CORBA等標(biāo)準(zhǔn)的基礎(chǔ)上制定的新一代分布式實(shí)時通信中間件技術(shù)規(guī)范，DDS采用發(fā)布/訂閱體系架構(gòu)，強(qiáng)調(diào)以數(shù)據(jù)為中心，提供豐富的Qos服務(wù)質(zhì)量策略，能保障數(shù)據(jù)進(jìn)行實(shí)時、高效、靈活地分發(fā)，可滿足各種分布式實(shí)時通信應(yīng)用需求[3]。

基于對以上型號機(jī)載軟件驗(yàn)證場景的分析，作者從組織級軟件開發(fā)驗(yàn)證協(xié)同、統(tǒng)籌角度出發(fā)，考慮發(fā)揮企業(yè)專業(yè)優(yōu)勢，整合已有全數(shù)字仿真系統(tǒng)、仿真模型資源，結(jié)合飛機(jī)設(shè)計(jì)所軟件測評質(zhì)量流程等因素，提出并實(shí)現(xiàn)了面向新機(jī)的機(jī)載軟件驗(yàn)證平臺方案。機(jī)載軟件驗(yàn)證平臺按照功能劃分，自底向上分為：執(zhí)行層、主控層、管理層。平臺架構(gòu)圖如圖2所示。

圖2 平臺架構(gòu)圖

3 機(jī)載軟件驗(yàn)證平臺執(zhí)行層設(shè)計(jì)

執(zhí)行層是軟件配置項(xiàng)、系統(tǒng)級驗(yàn)證、多學(xué)科仿真驗(yàn)證的執(zhí)行環(huán)境,為軟件驗(yàn)證提供全數(shù)字仿真目標(biāo)系統(tǒng)、仿真模型以及節(jié)點(diǎn)之間的交互，并實(shí)現(xiàn)與主控層的數(shù)據(jù)通信[4]。

各專業(yè)的仿真目標(biāo)系統(tǒng)、仿真模型在進(jìn)行交互的過程中，存在以下特點(diǎn)：所使用的協(xié)議及數(shù)據(jù)類型大多有所差異，總線通信的數(shù)據(jù)格式存在多樣性；仿真目標(biāo)機(jī)、仿真模型通常分布在不同區(qū)域或網(wǎng)段，且存在動態(tài)加載的需求，傳統(tǒng)的網(wǎng)絡(luò)通信模型不能滿足要求；嵌入式軟件驗(yàn)證對實(shí)時性要求高，精度要求達(dá)到微秒級，那么要求仿真目標(biāo)機(jī)、仿真模型及驗(yàn)證主控層之間保持良好的同步要求[5]。

使用開源項(xiàng)目OPEN DDS實(shí)現(xiàn)執(zhí)行層的中間件。針對以上的特點(diǎn)，為保證驗(yàn)證執(zhí)行層的有效運(yùn)行，需要統(tǒng)一系統(tǒng)之間的消息格式；建立基于發(fā)布、訂閱的通信適配機(jī)制，支持執(zhí)行層、主控層、管理層各節(jié)點(diǎn)的動態(tài)加載，以及節(jié)點(diǎn)之間的實(shí)時通信。

3.1 統(tǒng)一消息格式

統(tǒng)一消息格式是指建立一張全局的、涉及所有仿真系統(tǒng)、模型的系統(tǒng)參數(shù)表，并為每個參數(shù)分配唯一的ID。在配置完成訂閱發(fā)布機(jī)制后，主控層根據(jù)系統(tǒng)參數(shù)表生成相應(yīng)的配置表，并將該配置表發(fā)送到對應(yīng)的仿真目標(biāo)系統(tǒng)及模型，從而建立起接口信號表參數(shù)與配置表的映射關(guān)系，實(shí)現(xiàn)數(shù)據(jù)的交互。

表1～4說明了接口信號表、系統(tǒng)參數(shù)表及子系統(tǒng)配置表的轉(zhuǎn)換關(guān)系說明。

表1 接口信號表

源目的地信號名稱信號標(biāo)識號燃油機(jī)電計(jì)算機(jī)油溫狀態(tài)Msg0機(jī)電計(jì)算機(jī)燃油伺服閥1控制信號Msg1機(jī)電計(jì)算機(jī)燃油伺服閥2控制信號Msg2

表2 全局?jǐn)?shù)據(jù)參數(shù)表

表3 機(jī)電計(jì)算機(jī)配置表

表4 燃油系統(tǒng)配置表

3.2 建立基于發(fā)布/訂閱的適配機(jī)制

機(jī)載軟件驗(yàn)證平臺的執(zhí)行層、主控層、管理層通過DDS通信技術(shù)進(jìn)行交互。由于主控層、管理層的已有應(yīng)用程序使用企業(yè)服務(wù)總線(ESB)作為總線，那么將采用DDS通信技術(shù)的執(zhí)行層接入到ESB總線時，必然要面對簡單對象訪問協(xié)議(SOAP)消息與DDS報(bào)文間的消息轉(zhuǎn)換問題。因此需要設(shè)計(jì)一種通信轉(zhuǎn)換的適配器作為ESB與DDS總線間連接的橋梁，實(shí)現(xiàn)SOAP消息與DDS之間的信息轉(zhuǎn)換。適配器設(shè)計(jì)結(jié)構(gòu)如圖3所示[6]。

圖3 適配器結(jié)構(gòu)

4 機(jī)載軟件驗(yàn)證平臺主控層設(shè)計(jì)

相當(dāng)長一段時間內(nèi)，國防軍用軟件的驗(yàn)證工作都是“研制能力推動”。特別是在軟件配置項(xiàng)測試、系統(tǒng)測試環(huán)節(jié)上，基本上是研制出什么軟件試驗(yàn)環(huán)境，軟件自測試、軟件定型/鑒定測評就用什么環(huán)境。

在機(jī)載軟件驗(yàn)證平臺中提出主控層的概念，目的是將型號軟件驗(yàn)證要求固化到主控層的流程和方法中, 增強(qiáng)軟件驗(yàn)證工作的獨(dú)立性。主控層對上承接管理層，為軟件開發(fā)驗(yàn)證協(xié)同管理提供數(shù)據(jù)支持；對下調(diào)度執(zhí)行層的各仿真目標(biāo)系統(tǒng)和仿真模型，執(zhí)行軟件測試及仿真。

主控層通過Eclipse集成開發(fā)環(huán)境搭建框架，集成了商用軟件測試工具進(jìn)行功能實(shí)現(xiàn)。

主控層的主要功能包括測試場景、測試用例設(shè)計(jì)、測試腳本發(fā)布、測試結(jié)果記錄、仿真系統(tǒng)構(gòu)型管理等功能。

4.1 測試自動化

主控層集成了某商用測試工具實(shí)現(xiàn)機(jī)載軟件配置項(xiàng)測試場景、測試用例的分離設(shè)計(jì)、執(zhí)行。

具體步驟如下：

1)分析典型測試場景，制定軟件測試場景建模規(guī)范。嵌入式軟件系統(tǒng)中常見的4種場景模式包括：基本場景模式、關(guān)鍵事件驅(qū)動場景模式、定時事件驅(qū)動場景模式和時間片事件驅(qū)動場景模式[7]。通過使用場景建模規(guī)范，將相似的場景歸類到相應(yīng)的場景模式中，可指導(dǎo)測試設(shè)計(jì)人員進(jìn)行測試場景建模。

2)場景分析建模。這個過程等價于軟件測試項(xiàng)分解過程。測試設(shè)計(jì)人員依據(jù)被測軟件的文檔進(jìn)行分析，對被測系統(tǒng)進(jìn)行軟件測試場景建模，并構(gòu)建測試場景樹。測試場景樹的結(jié)構(gòu)與軟件需求的組織形式類似，以被測系統(tǒng)作為場景樹的根節(jié)點(diǎn)，每個不能再分解的測試子項(xiàng)作為場景樹的葉子節(jié)點(diǎn)。測試場景通過轉(zhuǎn)換，生成對應(yīng)的場景狀態(tài)如圖4所示。

3)測試用例生成。測試執(zhí)行人員基于場景狀

態(tài)圖設(shè)計(jì)并生成測試用例，測試用例的覆蓋率應(yīng)滿足邏輯路徑覆蓋的準(zhǔn)則。

4.2 仿真系統(tǒng)構(gòu)型管理

執(zhí)行層通過DDS將分布式的仿真目標(biāo)系統(tǒng)及仿真模型關(guān)聯(lián)在一起，由于執(zhí)行層面向組織級的機(jī)載系統(tǒng)軟件驗(yàn)證工作，不同的系統(tǒng)在進(jìn)行軟件驗(yàn)證時，會用到相同的目標(biāo)系統(tǒng)及仿真模型，這些相同的目標(biāo)系統(tǒng)及仿真模型，有可能中間件的要求是不一樣。因此，需要按照邏輯將執(zhí)行層劃分為若干個仿真系統(tǒng)構(gòu)型節(jié)點(diǎn)，并通過主控層的仿真系統(tǒng)構(gòu)型管理模塊進(jìn)行配置。仿真系統(tǒng)構(gòu)型如圖5所示。

圖5 仿真系統(tǒng)構(gòu)型示意圖

5 機(jī)載軟件驗(yàn)證平臺管理層設(shè)計(jì)

飛機(jī)設(shè)計(jì)所軟件測試管理系統(tǒng)是為面向型號機(jī)載軟件驗(yàn)證而建立，包括型號測試管理、項(xiàng)目管理、計(jì)劃管理、實(shí)施管理、測試數(shù)據(jù)監(jiān)控分析、測試過程資產(chǎn)管理等功能。

機(jī)載軟件驗(yàn)證平臺的管理層是在原有企業(yè)級測試管理系統(tǒng)的基礎(chǔ)上，根據(jù)飛機(jī)設(shè)計(jì)所軟件研制業(yè)務(wù)流程，增加軟件開發(fā)驗(yàn)證協(xié)同管理模塊，增加測試管理平臺與主控層的接口交互功能，測試用例、軟件問題、軟件測試項(xiàng)等測試過程數(shù)據(jù)的交互。管理層結(jié)構(gòu)如圖6所示。

圖6 管理層結(jié)構(gòu)圖

軟件開發(fā)協(xié)同管理模塊為業(yè)務(wù)流程的各個角色提供一個集需求分析、設(shè)計(jì)、仿真、數(shù)據(jù)管理及知識管理的一體化測試工作臺面。對用戶來說，實(shí)現(xiàn)驗(yàn)證過程所涉及的干系人在統(tǒng)一工作平臺的高效協(xié)同工作，將測試數(shù)據(jù)、人員、業(yè)務(wù)緊密集成在一起，形成項(xiàng)目和測試活動可追蹤、可控制和可重復(fù)的管理機(jī)制。實(shí)現(xiàn)基于仿真分析、多學(xué)科優(yōu)化的軟件測試過程；實(shí)現(xiàn)基于機(jī)電、飛管、任務(wù)系統(tǒng)軟件最佳驗(yàn)證實(shí)踐的封裝，以及基于測試模板的快速標(biāo)準(zhǔn)測試流程構(gòu)建。

6 平臺搭建以及實(shí)現(xiàn)

為了驗(yàn)證本文設(shè)計(jì)的軟件驗(yàn)證平臺的高效，將其應(yīng)用于某型號機(jī)載機(jī)電軟件開發(fā)及驗(yàn)證的全生命周期中。在C階段，利

軟件測評中心C應(yīng)用其全數(shù)字仿真方式，模擬被測系統(tǒng)的硬件環(huán)境，使軟件測試工作盡早介入。在S階段，通過全數(shù)字仿真與快速原型系統(tǒng)(RCP)相結(jié)合，并在此基礎(chǔ)上加入多學(xué)科仿真，完全滿足了軟件驗(yàn)證的需求，并緩解了測試環(huán)境資源沖突的問題[8]。在D及P階段，前期采用全數(shù)字仿真環(huán)境，將大部分軟件功能驗(yàn)證工作在虛擬仿真條件完成，后期的軟件確認(rèn)測試、軟件定型則采用半實(shí)物仿真方式或者在真實(shí)機(jī)載環(huán)境中開展。經(jīng)驗(yàn)證，此驗(yàn)證平臺的搭建與之前軟件設(shè)計(jì)、開發(fā)與驗(yàn)證脫離的模式相比，極大地提高了軟件驗(yàn)證效率以及軟件質(zhì)量安全性[9]。

7 結(jié)論

用全數(shù)字仿真技術(shù)及數(shù)據(jù)分發(fā)服務(wù)，建設(shè)全數(shù)字航空機(jī)載軟件驗(yàn)證平臺，可以大大緩解企業(yè)的綜合試驗(yàn)臺的壓力，使得企業(yè)內(nèi)測試資源得到最大程度的合理利用；可以收集型號軟件測試過程數(shù)據(jù)，建立型號軟件驗(yàn)證知識經(jīng)驗(yàn)庫；對成品單位及軟件測評單位，可開展多地遠(yuǎn)程協(xié)同軟件驗(yàn)證。這對飛機(jī)設(shè)計(jì)所提升軟件管理水平、研制能力，優(yōu)化測試資源配置有著深刻的意義。

參考文獻(xiàn)：

[1] 蒲小勃.現(xiàn)代航空電子系統(tǒng)與綜合[M].北京：航空工業(yè)出版社，2013.

[2] 陳真勇, 唐 龍, 唐澤圣, 等. 以魯棒性為目標(biāo)的數(shù)字多水印研究[M]. 北京：北京化學(xué)出版社，2002.

[3] 卞華星，陳 丹，莊 毅.DDS在飛機(jī)協(xié)同設(shè)計(jì)系統(tǒng)中的應(yīng)用[J].計(jì)算機(jī)與現(xiàn)代化，2015(5)：35-39.

[4] 任昊利，等. 數(shù)據(jù)分發(fā)服務(wù)——以數(shù)據(jù)為中心的發(fā)布/訂閱式通信[M].北京：清華大學(xué)出版社,2014.

[5] 蔡建平.嵌入式軟件測試實(shí)用技術(shù)[M].北京：清華大學(xué)出版社,2010.

[6] 鄭 凱.飛機(jī)綜合航電系統(tǒng)集成驗(yàn)證平臺互聯(lián)技術(shù)研究[J].航天科學(xué)技術(shù)，2015(36)：43-44.

[7] 韓德強(qiáng)，馮云賀，王宗俠，高雪園.基于Simics的嵌入式系統(tǒng)的研究與開發(fā)[J].航天科學(xué)技術(shù)，2015(2)：32-34.

[8] 楊廣華，齊 璇，施寅生.基于場景模式的嵌入式軟件測試用例設(shè)計(jì)[J].計(jì)算機(jī)工程，2010(15)：89-91.

[9] 熊志剛，李 晶，蘇振揚(yáng)，等. 一種DDS 與ESB 通信轉(zhuǎn)換的適配器模型[J].計(jì)算機(jī)工程，2015(2).