基于ARINC 661 協議的DF文件驗證方法①

崔詩嫻

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

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

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

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

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

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

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

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

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

1 Definition File

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

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

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

(3)加載DF文件.

(4)發送保活報文,監控UA狀態,管理會話和通信.

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

(1)UA頁面的架構信息,頁面之間的樹形關系.

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

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

UA開發者使用SCADE DISPLAY工具,加載由CDS開發者提供的workplace(定義了控件屬性),通過畫圖的方式,完成界面設計.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結合開發,但是并不在UA的目標機上加載,因此DF文件并不會影響UA的運行,DF文件不是UA的參數數據項.相反,部署在IDU上的ARINC 661 Server才會使用DF文件去實施UA界面的顯示,ARINC 661 Server通過ARINC 661協議和UA進行通信,實時顯示UA的控制界面,IMA和CDS的部署如圖1所示.

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

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

2 DF文件的開發和驗證

2.1 DF文件的開發流程

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

圖2 DF文件開發驗證流程圖

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

(1)自頂向下的開發流程,從系統需求到高級需求,再到低級需求和設計.

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

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

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

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

2.2 DF文件的開發流程

在系統需求開發階段,該階段的交付物是系統需求文檔,因此在該環節只需要驗證DF文件的架構定義和屬性定義.驗證人員通過評審的方式,驗證與DF文件相關的需求.評審DF文件的需求,需要結合UA軟件的系統需求,必須保證以下三點:

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

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

(3)能夠實現UA軟件的顯示需求.

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

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

圖3 XML格式的DF文件內容

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

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

圖4 BIN文件格式的DF文件驗證環境示意圖

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

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

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

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

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

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

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

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

圖5 三種格式的DF文件關系圖

HEXA文件中包含了XML文件控件的描述,同時又將該段參數轉換成了十六進制的數據,HEXA文件內容如圖6所示.

圖6 HEXA格式的DF文件內容

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

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

圖7 DF文件驗證的追蹤性

執行高級需求測試用例和低級需求測試用例,驗證BIN文件是否支持UA的功能性測試,DF文件內容定義和UA實現的一致.根據系統需求,高級需求和低級需求以及設計文檔對XML文件進行評審,對XML文件進行了驗證.同時,也完成了DF文件的追蹤性驗證.

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

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

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

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

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

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

2.3 DF文件的測試規程和結果

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

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

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

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

圖8 需求設計界面

圖9 IDU的真實顯示界面

圖10 Check Button的XML表達

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

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

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

圖11 IDU的真實顯示界面

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

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

表2 Check Button與Radio Box的表達關系

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

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

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

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

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

圖13 DF文件驗證記錄

3 結論與展望

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

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

2伊恩·莫伊爾,阿倫·西布里奇,馬爾科姆·朱克斯.飛機航空電子系統.支超有,秦成,譯.2版.北京:國防工業出版社,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陳穎,苑仁亮,曽利.航空電子模塊化綜合系統集成技術.北京:國防工業出版社,2013.

6趙志勇,毛忠陽,張嵩,等.數據鏈系統與技術.北京:電子工業出版社,2014.

7田莉蓉.機載電子產品適航工程方法.北京:航空工業出版社,2016.

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

9霍曼.飛速發展的航空電子.北京:航空工業出版社,2007.

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

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

12馮秋燕.基于UML模型的系統級測試用例生成方法.計算機應用,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]