基于SCADE ARINC661 的座艙顯示應用軟件模型開發(fā)研究

魏石峰 程新滿 王柯云

（中國直升機設計研究所 江西省景德鎮(zhèn)市 333001）

1 引言

隨著綜合化航空電子技術的發(fā)展，航空電子系統(tǒng)的組成越來越多元化，綜合顯示系統(tǒng)的系統(tǒng)復雜度顯著增加。這使得綜合顯示軟件在添加新的子系統(tǒng)或子系統(tǒng)功能、維護更新時不得不面臨高難度高成本的問題，同時，隨著軟件規(guī)模的增加，測試難度也隨之增加，軟件安全難以保障。針對此問題，ARINC661 規(guī)范應運而生，它提出了一種CDS 軟件加UA 軟件的“客戶端-服務器”型的系統(tǒng)架構，能夠很好的解決上述問題。

在實際工程中應用該標準，必須考慮實際通訊鏈路復雜、通訊帶寬有限，從而引起的數(shù)據(jù)擁堵和丟失的問題。聶飛針對該問題提出了失效檢測算法，李回寶提出了一種基于檢測通訊數(shù)據(jù)的ARINC661 軟件測試方法。但是目前還沒有文章對初始化的過程展開過研究，ARINC661 畫面在初始化時是通訊帶寬需求的高峰，如果不進行合理的初始化管理，容易造成初始化消息丟失的風險。本文基于SCADE 建模對上述問題提出一種模型框架，可對消息發(fā)送進行有效管理，在初始化時控制發(fā)送消息長度，逐循環(huán)完成初始化消息的發(fā)送，避免造成擁堵，又能保證正常初始化功能，初始化完成后該機制也能應對顯示異常風險。

2 ARINC661軟件架構及其模型化開發(fā)方法

如圖1 所示，ARINC661 標準起源于2001 年ARINC 公司制定的“ARINC661 規(guī)范”，即：“座艙顯示系統(tǒng)到用戶系統(tǒng)的接口”規(guī)范。隨著該標準在波音、空客等公司的不斷使用和修訂，逐漸成為了行業(yè)規(guī)范。ARINC661 標準與傳統(tǒng)設計思想之間最明顯的區(qū)別在于：該標準徹底將畫圖代碼和管理可見元素的邏輯、位置及狀態(tài)等代碼分離，前者定義為座艙顯示系統(tǒng)（CDS 軟件）,后者定義為用戶應用軟件（UA軟件）。CDS 和UA 之間通過ARINC661 定義的通信協(xié)議相聯(lián)系，CDS 軟件駐留在顯示器中，UA 軟件駐留在各個子系統(tǒng)計算機中。如果處理邏輯需要更改，僅需修改對應UA軟件。另外對于CDS 軟件，當有需求更改時，除增加新的交互效果外的一般情況下僅需要修改DF 配置文件即可，不需要更新CDS 軟件。

圖1：ARINC661 顯示系統(tǒng)軟件架構

CDS 軟件定義為面向用戶的圖形顯示軟件，用于實時顯示結構化的用戶接口組件（widgets）。而顯示什么樣的組件、如何顯示由定義文件（Definition file，DF 文件）來決定。

UA 軟件主要功能包括接收顯示器交互事件并進行邏輯處理，以及為CDS 軟件提供顯示參數(shù)指令的功能。UA 軟件搭載與各個子系統(tǒng)當中，將傳統(tǒng)顯控軟件復雜的功能拆分成了許多獨立的子功能。

SCADE Suite 是一款成熟的UA 軟件開發(fā)工具，它是一種基于模型的開發(fā)與驗證工具,與傳統(tǒng)軟件開發(fā)方式相比，開發(fā)人員不需要或者僅需要少量的手工編碼過程，而通過布置邏輯塊來連接邏輯，并自動生成認證級代碼。這樣做的好處在于可以降低時間成本，降低人為錯誤，提高軟件功能清晰度和可復用性。

3 UA軟件模型架構設計

3.1 UA軟件在顯示系統(tǒng)中的功能

座艙顯示系統(tǒng)一般有多個顯示器，各顯示器差異顯示但系統(tǒng)數(shù)據(jù)相同。對于一個UA 軟件來說其系統(tǒng)架構設計如圖 2 所示。

圖2：UA 軟件系統(tǒng)架構

圖 2 中（c）表示N 個顯示器，（b）表示UA 軟件，（a）表示航電子系統(tǒng)。UA 軟件駐留在航電子系統(tǒng)中，航電子系統(tǒng)發(fā)送系統(tǒng)狀態(tài)數(shù)據(jù)給UA 軟件（數(shù)據(jù)流①）；UA軟件將人機交互產(chǎn)生的控制指令發(fā)送給航電子系統(tǒng)（數(shù)據(jù)流②）；UA 軟件發(fā)送N 份ARINC661 消息給N 個顯示器，從而修改顯示內(nèi)容（數(shù)據(jù)流③）；UA 軟件接收顯示器發(fā)來的ARINC661 消息，從而獲取人機交互事件（數(shù)據(jù)流④）。

3.2 UA軟件的架構設計

本文所設計的UA 軟件的流程圖如圖 3 所示，完成初始化后進入周期執(zhí)行過程，循環(huán)內(nèi)先后完成以下過程：

圖3：UA 軟件流程圖

接收來自顯示器的ARINC661 輸入消息，并按照顯示器號將N 份ARINC661 輸入消息暫存到內(nèi)存中。接收系統(tǒng)消息，更新系統(tǒng)數(shù)據(jù)。按照顯示器號提取ARINC661 輸入消息。將輸入消息作為控制模型的輸入，調(diào)用控制模型，得到ARINC661 輸出消息然后發(fā)送。執(zhí)行控制模型期間，如果有系統(tǒng)控制事件觸發(fā)，則發(fā)送相應的系統(tǒng)數(shù)據(jù)到子系統(tǒng)?；氐讲襟E3，共執(zhí)行N 次，處理所有CDS 的ARINC661 輸入消息。執(zhí)行完N 次后，本循環(huán)結束，等待下一周期開始。

3.3 Suite中的控制模型設計

前一節(jié)介紹了總體架構，本節(jié)介紹模型框架設計。圖 4所示的模型架構主要由三部分組成。負責處理按鍵交互事件的模型；各個顯示模塊的顯示控制模型；責將前兩個模塊的輸出轉(zhuǎn)化成ARINC661 類型的輸出的消息發(fā)送管理模塊（Emit 管理）。

圖4：Suite 中搭建的模型架構

圖5：頁面切換模型示例

按鍵事件模型采用if 或者when 操作符來完成。通過對頁面號的判斷，調(diào)用不同頁面的按鍵處理模塊，如圖 6 所示。在各個頁面的按鍵事件模型中，可以采用導入類型的操作符調(diào)用手寫代碼發(fā)送系統(tǒng)數(shù)據(jù)，例如向子系統(tǒng)發(fā)送控制指令。

圖6：按鍵事件模型示例

畫面顯示控制模型按照功能進行封裝，各個顯示控制模型的具體實現(xiàn)邏輯各不相同，但外層的模型框架設計如圖 7所示。

圖7：畫面顯示控制模型

顯示控制模型的模型輸入是系統(tǒng)狀態(tài)數(shù)據(jù)，比如獲取經(jīng)緯度狀態(tài)數(shù)據(jù)，計算得出某個圖幅的屏幕坐標屬性值結果。因為Suite 開發(fā)工具不擅長處理數(shù)據(jù)結構，所以從系統(tǒng)控制軟件獲取系統(tǒng)狀態(tài)數(shù)據(jù)的功能采用手寫代碼的方式實現(xiàn)。獲取系統(tǒng)狀態(tài)數(shù)據(jù)后，數(shù)據(jù)存儲在手寫代碼創(chuàng)建的全局變量中，Suite 中的模型再采用導入類型操作符將系統(tǒng)數(shù)據(jù)輸入到控制模型中。

得到模型輸出后，即可將輸出與圖形屬性值連接。例如圖 8 中的名稱為航線的容器的使能屬性Enable、可見屬性Visible、屏幕坐標屬性PosX 和PosY 等。而每個屬性值前都對應有一個Emit 變量（發(fā)送標志位）。每循環(huán)中Suite 會將所有Emit 值為True 的屬性值組織成ARINC661 消息進行發(fā)送，顯然控制Emit 是管理消息發(fā)送的關鍵。本文對此提出了專門的消息發(fā)送管理模型，得到Emit 值后，與控制模型輸出共同連接到控件屬性值上。

圖8：航線容器的圖形屬性值（示例）

3.4 ARINC661消息發(fā)送管理模型設計

航電系統(tǒng)具有各系統(tǒng)間通信復雜多樣、數(shù)據(jù)傳輸量大、傳輸鏈路眾多等特點。實際工程中應用ARINC661 顯示系統(tǒng)后，不得不面對因通訊帶寬有限而造成的畫面初始化問題和消息意外丟失問題。因此，ARINC661 消息必須要進行合理的管理，尤其在通訊量需求最大的初始化階段，既要保證正常的初始化功能，又要保證消息長度不超限制。進行發(fā)送管理需考慮以下三點：

（1）基本需求：當顯示控制模型的計算輸出值發(fā)生變化時，應及時將該輸出值的Emit 值置為True，組織發(fā)送該輸出，使得畫面實時有效。

（2）初始化需求：顯示器啟動后的初始化階段，UA軟件需要將所有的模型輸出進行一次有效發(fā)送，也就是需要將所有的Emit 值在初始化階段全部置為True 一次，否則ARINC661 畫面將保持DF 文件里描述的初始狀態(tài)，而該狀態(tài)可能不是準確的狀態(tài)。同時，也不可以在UA 軟件的第一循環(huán)就將所有的Emit 值全部置為True，因為如果這樣做，ARINC661 消息的長度容易超過消息發(fā)送長度上限而被丟棄。

（3）防風險需求：由于通訊系統(tǒng)復雜，消息意外丟失也有可能發(fā)生，如果只是在輸出值發(fā)生變化時，將該輸出值的Emit 值置為True，那么恰巧發(fā)生消息丟失時，畫面顯示內(nèi)容將與實際狀態(tài)不符。

對于消息發(fā)送管理模型來說，其輸入為顯示控制模型的一個控件屬性值輸出，定義為out，其輸出為該屬性值的Emit 值，定義為out_e，定義上一循環(huán)的out 值為out_last，則：

上式中，emit_manual 為主動發(fā)送的標志位，其賦值將在下文詳述。上式意思為在out 不等于out_last 或者emit_manual 為Ture 時out_e 的值為Ture。設send_cycle 表示UA主程序循環(huán)計數(shù)，設其循環(huán)計數(shù)的上限為send_cycle_up。則有下式：

上式在UA 的主循環(huán)內(nèi)調(diào)用一次。設send_times 表示一個循環(huán)內(nèi)調(diào)用Emit 管理模型的計數(shù)，其上限也為send_cycle_up。則有下式：

上式在每次調(diào)用Emit 管理模型時均調(diào)用一次，其邏輯如圖9 所示。

圖9 所示，UA 軟件一個循環(huán)內(nèi)執(zhí)行一次公式（2），假設UA軟件中有N個Emit需要賦值，則每一循環(huán)內(nèi)將會有（N/send_cycle_up）個Emit 的值被主動置為True，即便它所對應的控制模型輸出值沒有變化。那么，經(jīng)過send_cycle_up個循環(huán)后，能夠保證將所有的Emit 置為True 一次，且每個循環(huán)的ARINC661 數(shù)據(jù)長度大致均勻。

圖9：ARINC661 消息發(fā)送管理模型邏輯圖

通過該機制，我們可以通過控制send_cycle_up 值的大小來控制ARINC661 消息的長度，在初始化時可以將其賦值為較小的值，使畫面快速進行初始化，初始化結束后增大其值，減小ARINC661 消息長度。也可以將send_cycle_up，send_cycle，send_times 設置為多維數(shù)組，即可根據(jù)輸出值的關鍵程度將其Emit 進行不同級別的管理，這里我們不討論分級別的情況。

本文將send_cycle_up 的初始值設置為10，即10 個循環(huán)內(nèi)完成初始化過程，初始化完成后將send_cycle_up 的值設置為40。運行UA 軟件，記錄前100 個循環(huán)內(nèi)的ARINC661消息發(fā)送長度，如圖10 中的紅色實線所示。前10 個周期，ARINC661 消息發(fā)送長度較長，10 個周期后，畫面初始化完畢，之后的ARINC661 消息發(fā)送長度較短。

圖10：ARINC661 消息發(fā)送長度實驗結果

如果將Emit 管理模型屏蔽，僅判斷輸出值是否發(fā)生變換，變化時將Emit 置為True，則得到的ARINC661 消息長度為非主動發(fā)送的長度，如圖10 的藍色實線所示。總長度減去非主動發(fā)送的長度即為在Emit 管理模型的作用下主動發(fā)送的消息長度，如圖10 中綠色實線所示。假如某個循環(huán)內(nèi)的ARINC661 消息未能成功發(fā)送給顯示器，漏掉的模型輸出值將最遲在40 個循環(huán)后重新發(fā)送，從而應對消息丟失的風險。

4 結論

ARINC661 標準可以減小顯控軟件開發(fā)、維護成本，實現(xiàn)軟件接口標準化。在機載顯控軟件領域，本文針對多屏顯示、周遍鍵交互等需求，以及通訊帶寬有限而造成的畫面初始化問題和消息意外丟失問題，提出了一種UA 軟件框架，以及模型框架。模型框架中的ARINC661 消息發(fā)送管理模型可以有效解決畫面初始化問題和消息意外丟失而造成的顯示異常問題，為UA 軟件開發(fā)提供了解決方案。