基于ARINC 661 協(xié)議的DF文件驗證方法①

崔詩嫻

(中電科航空電子,成都 611731)

在開發(fā)駐留在IMA系統(tǒng)中的UA軟件時,需要對UA本身的人機界面進行定義和設(shè)計,并且開發(fā)負責與IDU通信的ARINC 661協(xié)議模塊以及存儲和管理界面控件的模塊.同時負責生成一個符合A661協(xié)議的DF文件,包括了所有UA定義的圖形控件,用于IDU加載,使得該UA的界面得以顯示.UA代碼中對圖形控件的定義和加載在IDU上的DF文件中的定義必須一致,UA才能提供完善的功能供飛行員使用.DF文件由UA開發(fā)人員創(chuàng)建,卻加載在CDS開發(fā)人員提供的IDU上.因此,對于和DF相關(guān)的需求和驗證,就應該由UA開發(fā)者和CDS開發(fā)者共同承擔,這就是當前國內(nèi)民機項目研制時,需要解決的,且在國外民機項目中所沒有的問題.對于有豐富的民用航空系統(tǒng)研發(fā)經(jīng)驗的Rockwell Collins,Honeywell和GE等公司來說,他們參與的民用飛機項目中,是將DF文件的所有開發(fā)和驗證,全部交由CDS開發(fā)者完成.根據(jù)業(yè)界的經(jīng)驗總結(jié),這樣的解決方案會出現(xiàn)以下這些普遍性問題:

(1)UA開發(fā)者和CDS開發(fā)者的溝通不當,如UA需求的理解或表達不當,會導致CDS開發(fā)者開發(fā)的DF文件不能支持UA的功能.

(2)UA功能的頻繁更新,導致DF文件的更新不一致.

(3)CDS開發(fā)者更新控件庫,UA開發(fā)者不能同步修改相關(guān)功能以及控件屬性.

(4)UA開發(fā)者只能等待DF文件開發(fā)完成后,才能進行自己的界面交互功能驗證,在驗證執(zhí)行中,多以接口(ICD)方式進行驗證,這種驗證方式不直觀,不能準確表達飛行員的真實感受.

(5)CDS開發(fā)者工作量巨大,需要完成所有UA的DF文件設(shè)計,并且在等待UA開發(fā)者完成開發(fā)后,才能進行DF文件和UA的聯(lián)調(diào),開發(fā)周期較長.

綜上所述,傳統(tǒng)的DF文件開發(fā)方式,容易出現(xiàn)多次的異步同步問題,導致開發(fā)周期延長,追蹤性不完整,工作協(xié)調(diào)復雜,耗費大量人力物力.因此,我們在國內(nèi)民用飛機系統(tǒng)中,首次嘗試由UA開發(fā)者承擔DF文件的開發(fā)任務(wù).UA開發(fā)者可以按照軟件的需求,開發(fā)滿足需求的DF文件,最后將DF文件交付給CDS開發(fā)者,統(tǒng)一進行集成測試.

由于DF文件并不是可執(zhí)行代碼,因此,驗證方式與典型的民用航電系統(tǒng)軟件方式有所不同.為了達到DO-178C的要求和CAAC對軟件的審定要求,DF文件的驗證必須采取分析,評審和測試的綜合方式,達到最終的驗證目的.民用飛機的研制是一個巨大的系統(tǒng)和工作,包括波音和空客,均采用全球供應商模式,類似于DF文件這樣需要多個供應商共同承擔驗證的情況日益趨多,本文介紹的僅僅是UA開發(fā)者對DF文件的驗證方式[1,2].

1 Definition File

目前,主流的民用飛機采用的是CDS來進行顯示控制.CDS包括多個IDU,每個IDU提供一個ARINC 661 Server.ARINC 661 Server的主要工作包括:

(1)定義界面大小,位置,形狀等公共窗口屬性.

(2)發(fā)送握手協(xié)議,與UA建立會話,維護通信.

(3)加載DF文件.

(4)發(fā)送保活報文,監(jiān)控UA狀態(tài),管理會話和通信.

由于民用飛機航電系統(tǒng)軟件的高安全性的特性,C級以上的軟件多數(shù)都有顯示備份,UA可以和兩個或兩個以上的IDU進行通信.通信并不表示可以顯示,只是該IDU具備了顯示該UA的配置.一般情況下同一個UA界面可以同時在2個或2個以上的IDU上進行顯示.ARINC 661 Server負責管理顯示事件,IDU在系統(tǒng)配置時,獲得顯示某個UA權(quán)限后,將與UA建立通信,在收到顯示事件后,加載該UA的DF文件.需要在IDU上進行顯示的UA,直接和相應的IDU上的ARINC 661 server進行通信.DF文件就是用于UA和IDU進行通信的靜態(tài)非可執(zhí)行代碼數(shù)據(jù).因此,DF文件必須包含以下內(nèi)容:

(1)UA頁面的架構(gòu)信息,頁面之間的樹形關(guān)系.

(2)每一個頁面的控件信息及其屬性.

(3)頁面之間的邏輯關(guān)系,頁面之間的跳轉(zhuǎn),按鈕鏈接的界面信息.

UA開發(fā)者使用SCADE DISPLAY工具,加載由CDS開發(fā)者提供的workplace(定義了控件屬性),通過畫圖的方式,完成界面設(shè)計.SCADE DISPLAY工具自動生成DF文件,生成的DF文件有三種格式,分別是Binary,XML和Hexa,同時生成記錄DF文件生成過程的日志文件.

首先需要說明的是,參照DO-178C的section 2.5.1,“A data set that influences the behavior of software without modifying the Executable Object Code and is managed as a separate configuration item is called Parameter Data Item”.盡管DF文件是和UA結(jié)合開發(fā),但是并不在UA的目標機上加載,因此DF文件并不會影響UA的運行,DF文件不是UA的參數(shù)數(shù)據(jù)項.相反,部署在IDU上的ARINC 661 Server才會使用DF文件去實施UA界面的顯示,ARINC 661 Server通過ARINC 661協(xié)議和UA進行通信,實時顯示UA的控制界面,IMA和CDS的部署如圖1所示.

駐留在IMA上的UA與相應的ARINC 661 Server進行通信,通常使用ARINC 664接口(空客稱之為“AFDX”接口)傳輸ARINC 661報文.DF文件預先根據(jù)系統(tǒng)配置,存放在相應的IDU上.當ARINC 661 Server在收到來自UA的顯示事件后,會加載該UA的DF文件,對該UA進行顯示.這樣的部署,達到了靈活備份,減少冗余和快速切換的目的.比如UA可以在IDU1,IDU3和IDU6上進行顯示,但是同時只能在兩個IDU上進行顯示.那么,這三個IDU將配置該UA的DF文件,當UA已經(jīng)在IDU1和IDU3上進行顯示時,IDU6將不會加載UA的DF文件,不允許UA的顯示.當UA在IDU1上的顯示失效后,IDU6上將收到UA的顯示事件,加載UA的DF文件,UA將在IDU3和IDU6上進行顯示.UA維持所有獲得顯示權(quán)限的A661 Server的通信會話,只發(fā)出允許顯示的界面?zhèn)€數(shù)的顯示事件[3,4].

圖1 IMA,CDS和DF文件的部署圖

2 DF文件的開發(fā)和驗證

2.1 DF文件的開發(fā)流程

DF文件的開發(fā)既然是結(jié)合UA同時進行,那么UA開發(fā)和驗證的所有階段,都將對DF文件進行同時開發(fā)和驗證.如圖2所示,

圖2 DF文件開發(fā)驗證流程圖

在系統(tǒng)需求階段,需要將DF文件的結(jié)構(gòu)和屬性定于在系統(tǒng)需求中.比如DF文件中所包含的界面的layer ID的定義,以及l(fā)ayout的定義.在軟件高級需求和設(shè)計(低級需求)的開發(fā)中,需要將DF文件中各個控件的具體參數(shù)定義.比如一個控件的屬性是button還是data entry,字體的style set值(用于定于字體的顏色和大小)等.編寫代碼的同時,根據(jù)需求和設(shè)計,通過SCADE DISPLAY工具,完成DF文件的開發(fā).DF文件的開發(fā)同樣需要滿足民機航電系統(tǒng)開發(fā)的基本要求:

(1)自頂向下的開發(fā)流程,從系統(tǒng)需求到高級需求,再到低級需求和設(shè)計.

(2)雙向追蹤性,DF文件中的代碼數(shù)據(jù)可以逆向追蹤到低級需求的控件的定義.

(3)覆蓋率測試滿足DO-178C的要求,不出現(xiàn)dead code,inactive code等.

(4)根據(jù)相應的軟件等級,滿足開發(fā)和驗證的獨立性.

(5)DF文件的開發(fā)需要和UA代碼同步進行,同步更新和驗證.

2.2 DF文件的開發(fā)流程

在系統(tǒng)需求開發(fā)階段,該階段的交付物是系統(tǒng)需求文檔,因此在該環(huán)節(jié)只需要驗證DF文件的架構(gòu)定義和屬性定義.驗證人員通過評審的方式,驗證與DF文件相關(guān)的需求.評審DF文件的需求,需要結(jié)合UA軟件的系統(tǒng)需求,必須保證以下三點:

(1)符合UA軟件系統(tǒng)需求對軟件顯示層次的要求.

(2)對DF文件的框架屬性定義完整,所有需求和UA的軟件高層界面需求一致.

(3)能夠?qū)崿F(xiàn)UA軟件的顯示需求.

在高級需求和設(shè)計(低級需求)開發(fā)階段,DF文件中的參數(shù)定義已經(jīng)明確,界面需求已經(jīng)完善.該階段的交付物是高級需求,設(shè)計文檔(包括低級需求),因此,在該環(huán)節(jié)需要驗證的是DF文件中控件的定義,邏輯關(guān)系以及各種屬性參數(shù)值.同樣,該階段也必須結(jié)合UA相應的需求,必須與UA所定義的界面需求保持一致.

在經(jīng)過編碼階段后,code和DF文件都已經(jīng)完善.驗證人員需要結(jié)合軟件系統(tǒng)需求,軟件高級需求,軟件低級需求和軟件設(shè)計文檔,對SCADE DISPLAY工具產(chǎn)生的具有可讀性的XML格式的DF文件進行評審,XML格式的DF文件內(nèi)容如圖3所示.

圖3 XML格式的DF文件內(nèi)容

依據(jù)需求文檔,對XML文件中的控件參數(shù)進行review,查看框架結(jié)構(gòu)(控件對象繼承性)和控件參數(shù)是否和需求一致.其次,需要進行覆蓋率驗證,XML文件必須覆蓋所有需求定義的層次,結(jié)構(gòu),控件和參數(shù),同時不能有多出需求定義的表達.

在驗證UA的代碼是否符合UA的高級需求和低級需求的測試中,會將UA運行在目標機IMA上,SCADE DISPLAY工具產(chǎn)生的BIN文件會加載到IDU上.在此過程中,只要IDU能夠正確顯示UA界面,并且支持完成所有的UA驗證,我們認為BIN文件通過測試.UA的功能驗證和BIN文件驗證的環(huán)境圖,如圖4所示.

圖4 BIN文件格式的DF文件驗證環(huán)境示意圖

通過鍵盤和鼠標對IDU輸入數(shù)據(jù),輸入數(shù)據(jù)通過ARINC 664接口,封裝為ARINC 661協(xié)議,傳輸至IMA上的UA.UA接收并處理這些數(shù)據(jù)后,UA做出相應的功能響應,同時將界面的顯示處理反饋至IDU,IDU上的ARINC 661 Server處理該反饋信息后,更新DF文件的運行數(shù)據(jù),更新界面的顯示.IDU上的界面實時顯示數(shù)據(jù),通過獲取DF文件的運行數(shù)據(jù)得到,DF文件的運行數(shù)據(jù)和UA本地存儲的界面數(shù)據(jù)一致,實現(xiàn)對UA用戶界面的實時顯示.

但是,通過加載DF的BIN格式文件,結(jié)合UA的功能測試驗證DF文件的驗證方式會出現(xiàn)以下問題:

(1)UA開發(fā)者并不會購買SCADE DISPLAY的DF文件生成器的認證包(價格相對昂貴),但又必須驗證DF文件的正確性.

(2)加載的BIN文件不具備可讀性,無法通過評審和分析的形式進行驗證.

(3)無法將DF文件的非可執(zhí)行代碼追蹤到相應的需求.

(4)即使正確支持了UA所有的功能測試,也不能說明DF文件的開發(fā)完全符合需求定義.

(5)不能對BIN格式的DF文件進行覆蓋率測試和靜態(tài)代碼走查

但是,只要能驗證BIN文件和已經(jīng)通過評審的XML文件信息一致,就可以說明BIN文件也滿足需求定義.那么便需要對BIN格式的DF文件和XML格式的DF文件進行一致性驗證.由于BIN文件是二進制格式,而XML文件是可讀字符,二者無法進行直接的驗證.那么,此時需要應用SCADE DISPLAY產(chǎn)生的HEXA格式的DF文件作為中間件,驗證BIN和XML文件的一致性,驗證文件關(guān)系如圖5所示.

圖5 三種格式的DF文件關(guān)系圖

HEXA文件中包含了XML文件控件的描述,同時又將該段參數(shù)轉(zhuǎn)換成了十六進制的數(shù)據(jù),HEXA文件內(nèi)容如圖6所示.

圖6 HEXA格式的DF文件內(nèi)容

在驗證了XML文件和HEXA文件的描述字段和參數(shù)一致后,將HEXA文件的十六進制數(shù)據(jù)和BIN文件的二進制數(shù)據(jù)進行匹配,只要數(shù)據(jù)一致,那么一致性便得到了驗證.

由于XML文件是根據(jù)需求進行評審,BIN文件根據(jù)需求進行測試,測試用例分別基于高級需求和低級需求進行開發(fā),XML文件和BIN文件又通過HEXA文件,進行了一致性驗證,那么就可以得到如圖7所示的追蹤關(guān)系.

圖7 DF文件驗證的追蹤性

執(zhí)行高級需求測試用例和低級需求測試用例,驗證BIN文件是否支持UA的功能性測試,DF文件內(nèi)容定義和UA實現(xiàn)的一致.根據(jù)系統(tǒng)需求,高級需求和低級需求以及設(shè)計文檔對XML文件進行評審,對XML文件進行了驗證.同時,也完成了DF文件的追蹤性驗證.

綜上所示,UA開發(fā)者負責的DF文件的驗證具有以下特點:

(1)DF文件驗證具有獨立性,同時結(jié)合了UA的功能性驗證,保證了雙向的數(shù)據(jù)關(guān)系一致.

(2)DF文件的驗證具備完善的追蹤性,適航證據(jù)完整.

(3)DF文件的驗證從系統(tǒng)需求階段開始,貫穿了整個軟件開發(fā)流程.

(4)通過完善的追蹤性,能夠達到UA界面需求跟新,DF文件需求更新,到DF文件同步更新的目的.

(5)最終得到的DF文件,交付至CDS開發(fā)者后,CDS開發(fā)者只需將其作為ARINC 661 Server的參數(shù)項進行驗證,與UA功能無關(guān).

2.3 DF文件的測試規(guī)程和結(jié)果

在使用SCADE DISPLAY工具后,產(chǎn)生了XML,HEXA,和BIN格式的DF文件.將UA運行在IMA上,BIN文件加載在IDU上,通過功能測試,驗證IDU顯示的界面是否符合需求定義.例如需求中定義的界面如圖8所示.

此時通過IDU顯示出來的界面,如圖9所示.

CDS開發(fā)者提供的workspace與設(shè)計需求文檔中的界面,因為實際使用的畫圖工具的差別,會出現(xiàn)細微的差別.此時,通過功能驗證,目測界面的顏色字體,能夠符合最終的系統(tǒng)成員規(guī)范,此時的DF文件便可以通過測試.

第二步是根據(jù)需求評審XML文件.例如ATIS界面的一個控件描述,如圖10所示.

圖8 需求設(shè)計界面

圖9 IDU的真實顯示界面

圖10 Check Button的XML表達

在完成XML文件的評審后,進行HEXA文件和XML文件的一致性驗證,與上圖對應的ATIS界面的一個控件的HEXA表達,如圖11所示.

將XML中的表達和HEXA的二進制對應的映射表,如表1所示.

值得注意的是,在控件身份表達中,增加了一個Parent Identity.它是SCADE DISPLAY給該控件添加的父節(jié)點屬性,在XML文件中并沒有表達出來,因為XML文件是按照樹結(jié)構(gòu)進行組織的,樹形結(jié)構(gòu)便可以表達出子節(jié)點和父節(jié)點的繼承關(guān)系.而二進制表達式無法顯示樹形結(jié)構(gòu),便添加父節(jié)點屬性來體現(xiàn)控件對象的繼承性.在對DF文件的覆蓋率驗證中,必須說明類似Parent Identity這樣的參數(shù)存在的原因,才能通過覆蓋率的測試和分析.

圖11 IDU的真實顯示界面

表1 Check Button控件的XML和HEXA表達的一致性對照

如表2所示,對于Check Button來說,Radio box就是他的父控件,所以在定義Check Button時,需要將Radio Box的WidgetIdent 0082賦值給ParentIdent來體現(xiàn)對象的繼承性.

表2 Check Button與Radio Box的表達關(guān)系

驗證了XML文件和HEXA的一致性后,需要驗證BIN文件和HEXA文件的一致性.在BIN文件中找到相應的二進制內(nèi)容,如圖12所示.

陰影部分,便是上述控件Check Button的二進制表達.

通過上述驗證過程,將驗證結(jié)果記錄到EXCEL表格中,形成測試記錄,如圖13所示.

XML文件的評審驗證了控件參數(shù)是否符合需求,BIN文件的加載和UA的功能驗證,驗證了控件是否支持UA的操作性功能,BIN文件和XML文件的一致性驗證,完善了DF文件的追蹤性驗證,同時進行的覆蓋率分析,全面驗證了DF文件,最后通過形成測試記錄,提供了DF文件的驗證證據(jù).使得DF文件的驗證符合了DO-178C的要求,同時又能通過CAAC的適航審定[5-10].

圖12 Check Button在BIN文件中的表達

圖13 DF文件驗證記錄

3 結(jié)論與展望

本文所闡述的基于ARINC 661協(xié)議的DF文件的驗證,解決了UA開發(fā)者對軟件代碼以外的附屬交付物的驗證問題.在民用航電系統(tǒng)的集成測試中,IMA上集成了幾十個大大小小的軟件,并且由多個開發(fā)者分別負責一個或多個軟件的開發(fā),對基于ARINC 661協(xié)議的DF文件的驗證,是普遍存在的問題.使用本文的驗證方式,減輕了CDS開發(fā)者對來自于不同UA開發(fā)者提供的DF文件的驗證工作.按照本文的驗證方式驗證通過的DF文件,排除了UA開發(fā)者引起的兼容性,一致性和完整性的錯誤,CDS開發(fā)者直接使用和加載DF文件,將DF文件視為參數(shù)數(shù)據(jù)項進行驗證.這種DF文件的驗證方法規(guī)范了UA開發(fā)者的DF文件的驗證流程,提高了DF文件的驗證質(zhì)量,縮減了CDS的開發(fā)周期,同時減少了UA和CDS開發(fā)者在購買SCADE DISPLAY的DF生成器上的巨大開銷.在民用航電系統(tǒng)快速發(fā)展的時代,不同開發(fā)者,站在不同角度,使用不同方式,共同承擔一個產(chǎn)物的開發(fā)和驗證的模式必將成為大的趨勢,這樣的驗證方式也將逐步趨于成熟和完善[11-13].

1劉天華.民用飛機數(shù)據(jù)鏈通信管理技術(shù).電訊技術(shù),2010,50(5):84-88.

2伊恩·莫伊爾,阿倫·西布里奇,馬爾科姆·朱克斯.飛機航空電子系統(tǒng).支超有,秦成,譯.2版.北京:國防工業(yè)出版社,2015.

3RTCA.RTCA/DO-178C Software considerations in airborne systems and equipment certification.RTCA,2011.

4ARINC.ARINC Specification 661-4,Cockpit display system interfaces to user systems.ARINC,2010.

5陳穎,苑仁亮,曽利.航空電子模塊化綜合系統(tǒng)集成技術(shù).北京:國防工業(yè)出版社,2013.

6趙志勇,毛忠陽,張嵩,等.數(shù)據(jù)鏈系統(tǒng)與技術(shù).北京:電子工業(yè)出版社,2014.

7田莉蓉.機載電子產(chǎn)品適航工程方法.北京:航空工業(yè)出版社,2016.

8郭艷穎,吳洪坤,劉志剛.航空電子技術(shù)基礎(chǔ).西安:西北工業(yè)大學出版社,2016.

9霍曼.飛速發(fā)展的航空電子.北京:航空工業(yè)出版社,2007.

10中航工業(yè)成都凱天電子股份有限公司.機載設(shè)備適航工作指南.北京:航空工業(yè)出版社,2014.

11崔詩嫻,陳春曉,宮偉祥.GUI自動化測試工具在民用航空數(shù)據(jù)鏈系統(tǒng)集成中的應用.計算機系統(tǒng)應用,2016,25(7):66-71.[doi:10.15888/j.cnki.csa.005249]

12馮秋燕.基于UML模型的系統(tǒng)級測試用例生成方法.計算機應用,2014,34(1):276-280.[doi:10.11772/j.issn.1001-9081.2014.01.0276]

13谷多玉,申浩,葉曙光,等.基于圖的航空圖像與GIS模型匹配算法.計算機工程,2003,39(10):187-191.[doi:10.3321/j.issn:1002-8331.2003.10.061]