基于抽象工廠模式的機(jī)載總線數(shù)據(jù)通用化處理方法研究

楊萍，文信峰

（航空工業(yè)北京青云航空儀表有限公司飛控設(shè)計部，北京 100029）

0 引言

機(jī)載數(shù)據(jù)總線技術(shù)是飛機(jī)的電傳操縱系統(tǒng)和航空電子系統(tǒng)綜合化的關(guān)鍵技術(shù)之一，它的發(fā)展與航空電子技術(shù)的發(fā)展密切相關(guān)，先后經(jīng)歷了四個時代：第一代航空電子系統(tǒng)是分立式結(jié)構(gòu)；第二代是聯(lián)合式航空電子系統(tǒng)，采用的是數(shù)字式數(shù)據(jù)總線網(wǎng)絡(luò)；第三代是綜合式航空電子系統(tǒng)，采用了高速數(shù)據(jù)總線；第四代是先進(jìn)綜合式航空電子系統(tǒng)，采用統(tǒng)一航空電子互聯(lián)網(wǎng)絡(luò)。機(jī)載總線技術(shù)的發(fā)展，也是航空電子系統(tǒng)的發(fā)展，是為了滿足航空電子系統(tǒng)數(shù)據(jù)量日趨龐大，數(shù)據(jù)交聯(lián)關(guān)系多樣化、復(fù)雜化的需求［1］。

在軍用航空電子系統(tǒng)中，快速、準(zhǔn)確地進(jìn)行數(shù)據(jù)傳輸尤為重要，數(shù)據(jù)傳輸和處理對航空電子系統(tǒng)的性能影響很大，可以說是現(xiàn)代航空電子系統(tǒng)的支柱，因此可靠、高速的數(shù)據(jù)處理是航空電子系統(tǒng)設(shè)計的關(guān)鍵技術(shù)。為了滿足這個需求，我國航空電子系統(tǒng)中使用了各種機(jī)載數(shù)據(jù)總線，以

RS232/422/485，MIL-STD-1553B，ARINC429，AFDX等類型為主。在進(jìn)行總線數(shù)據(jù)處理時既要考慮總線的技術(shù)特點，又要兼顧協(xié)議標(biāo)準(zhǔn)。在日常開發(fā)中經(jīng)常遇到總線類型多、信號量大的處理問題，當(dāng)系統(tǒng)功能更新迭代時需要擴(kuò)展總線或者增加信號時，就會導(dǎo)致之前的軟件模塊無法使用，需要重新開發(fā)，因此不僅導(dǎo)致工作量的增加，而且會導(dǎo)致不同版本之間維護(hù)困難，經(jīng)常出現(xiàn)調(diào)用混亂的情況。而計算機(jī)設(shè)計模式中的抽象工廠模式正是采用一種通用化的處理方法，使總線處理標(biāo)準(zhǔn)化、通用化，大大簡化了不同總線數(shù)據(jù)的處理過程，提高程序的模塊化和可復(fù)用性，實現(xiàn)高效、準(zhǔn)確的數(shù)據(jù)處理和傳輸，突破了以往對于數(shù)據(jù)處理的固有方案，提高了機(jī)載軟件的可復(fù)用性和可靠性［2］。

1 抽象工廠模式

設(shè)計模式是將解決重復(fù)發(fā)生問題的方案核心總結(jié)成固定的模式，給出特定場景下問題的通用解決方案。一般用類關(guān)系和對象之間的通信方式描述軟件方案。抽象工廠模式是設(shè)計模式中用得比較多的一種對象創(chuàng)建型模式，將對象實例化過程抽象到一組接口的創(chuàng)建中。目的在于不指定具體類類型的情況下創(chuàng)建一系列相關(guān)的類對象。可以將大量有共同接口的類實例化，并可動態(tài)決定將哪一個類實例化［3］。圖1是抽象工廠模式的類關(guān)系圖，對外提供抽象工廠的類定義，掩蓋了具體使用類的類型，從而使客戶僅需要與抽象類定義的接口交互，而不必使用特定的具體類的接口［4］。

圖1 抽象工廠模式類關(guān)系圖Fig.1 Class diagram of abstract factory pattern

抽象工廠模式不指定具體的類，僅僅提供創(chuàng)建若干有依賴的對象的接口，抽象工廠模式可以避免客戶端和具體的產(chǎn)品耦合，方便以后對產(chǎn)品庫的擴(kuò)展。

2 在機(jī)載總線數(shù)據(jù)處理中的應(yīng)用

2.1 機(jī)載總線數(shù)據(jù)的特點

隨著航空電子系統(tǒng)向指揮、控制、通信和計算機(jī)智能化處理方向的發(fā)展，對數(shù)據(jù)總線構(gòu)成了強(qiáng)大的需求牽引，機(jī)載數(shù)據(jù)總線正在朝著數(shù)據(jù)傳輸高速化、網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)分布式、傳輸協(xié)議多樣化、通信介質(zhì)光纖化的方向發(fā)展，在此發(fā)展過程中，機(jī)載數(shù)據(jù)總線本身的傳輸多樣性、協(xié)議標(biāo)準(zhǔn)內(nèi)容多、交聯(lián)關(guān)系復(fù)雜等特點更加突出。

原來對于總線數(shù)據(jù)的處理方案是基于具體信號實現(xiàn)的，因為信號數(shù)量有限、交聯(lián)關(guān)系簡單，所以每個總線信號都是按照協(xié)議標(biāo)準(zhǔn)和技術(shù)特點進(jìn)行單獨的數(shù)據(jù)處理。當(dāng)測試需求發(fā)生改變時，基于整個測試系統(tǒng)相對簡單，所以維護(hù)單個信號或者單獨一類總線的工作相對也簡單，而且不容易出錯，此時對測試系統(tǒng)的通用性、可復(fù)用性的需求也并不明顯。

但是隨著20世紀(jì)八九十年代第三代綜合式航空電子系統(tǒng)的出現(xiàn)，航空電子系統(tǒng)所接收和產(chǎn)生的信息種類和數(shù)量不斷增長，機(jī)載數(shù)據(jù)總線上傳輸?shù)男盘柫考ぴ觯宦?lián)關(guān)系復(fù)雜多樣，而且測試系統(tǒng)的迭代更新加快，型號研制任務(wù)加重，在如此快速的變化中，原有的總線數(shù)據(jù)處理方案出現(xiàn)了很大的局限性，信號量不能實現(xiàn)快速擴(kuò)充，交聯(lián)關(guān)系轉(zhuǎn)換復(fù)雜，測試系統(tǒng)迭代更新時工作量大，設(shè)計開發(fā)用時久等缺陷都急需一種新的數(shù)據(jù)處理方案來解決［5］。

2.2 抽象工廠模式在數(shù)據(jù)處理中的應(yīng)用

經(jīng)過第1節(jié)對計算機(jī)設(shè)計模式中抽象工廠模式的分析，我們提出可以將抽象工廠模式的優(yōu)點用于機(jī)載總線數(shù)據(jù)的處理中。將機(jī)載數(shù)據(jù)總線的共同操作抽象為對外接口，所有的總線操作集合作為抽象工廠類，具體工廠類可以有兩種劃分方式：一種是以總線分類作為具體產(chǎn)品工廠，對應(yīng)的產(chǎn)品是具體類型的總線；一種是將總線的操作集合作為具體工廠，對應(yīng)的產(chǎn)品是某種具體類型總線的對應(yīng)操作。不管使用哪種劃分方式，抽象工廠模式在機(jī)載總線數(shù)據(jù)處理過程中都可以分為三層結(jié)構(gòu)：具體產(chǎn)品、具體工廠和抽象工廠層，如圖2所示。每一層之間相互協(xié)作，但是彼此在實例化的過程中又相互獨立，對外只表現(xiàn)為一個接口［6-7］。

圖2 抽象工廠的三層關(guān)系圖Fig.2 Three layer relationship diagram of abstract factory

這種模式可以保證在外部需求不斷變化的時候，比如增加了新類型的總線，只需要增加具體的總線處理，不需要修改對外的接口，從而使對外接口能夠更加穩(wěn)定。例如當(dāng)增加一種新類型的總線數(shù)據(jù)時，只需要在具體產(chǎn)品層實現(xiàn)對應(yīng)總線的各種操作，在調(diào)用層實現(xiàn)某種操作時，選擇對應(yīng)類型具體產(chǎn)品即可，從而達(dá)到接口不需要做任何改動，也不需要感知底層具體產(chǎn)品形態(tài)就可以完成新類型總線的擴(kuò)展。

我們將抽象工廠模式應(yīng)用于機(jī)載總線數(shù)據(jù)處理的時候，將機(jī)載總線按照總線類型進(jìn)行分類。同一類型總線數(shù)據(jù)所遵循的技術(shù)特點和協(xié)議標(biāo)準(zhǔn)是一樣的，具有共同的協(xié)議接口，可以按照抽象工廠模式將這些操作接口抽象作為對外的統(tǒng)一接口。

不同的總線類型，對應(yīng)于不同的具體產(chǎn)品，有幾種總線就創(chuàng)建幾個實例工廠，每個實例工廠又抽象出來自己的抽象產(chǎn)品和實例產(chǎn)品。本文以ARINC429和MIL-STD1553B兩種機(jī)載總線數(shù)據(jù)處理為例，介紹抽象工廠模式的實現(xiàn)方案。

2.3 應(yīng)用方案的設(shè)計和實現(xiàn)

航空電子的地面測控系統(tǒng)由硬件平臺和測控軟件組成。硬件平臺由各類機(jī)載總線板卡和數(shù)據(jù)采集卡構(gòu)成，對航電系統(tǒng)中的各設(shè)備信號進(jìn)行仿真；測控軟件屬于應(yīng)用軟件，對底層協(xié)議層的操作是驅(qū)動硬件平臺進(jìn)行數(shù)據(jù)收發(fā)和處理，對應(yīng)用層的操作是完成人機(jī)交互，實時監(jiān)控、顯示硬件平臺的數(shù)據(jù)和工作狀態(tài)。由此可見，測控軟件協(xié)議層負(fù)責(zé)機(jī)載總線數(shù)據(jù)的處理［8-10］。

采用面向?qū)ο蟮募夹g(shù)對機(jī)載總線數(shù)據(jù)進(jìn)行通用化處理，是為了應(yīng)對需求的改變，將總線的共性抽象出來便于以后開發(fā)復(fù)用，將測試流程通過抽象工廠模式設(shè)計使得用戶可以方便地修改和擴(kuò)充。在面向?qū)ο箢I(lǐng)域，有兩種最基本的軟件復(fù)用方式：類庫和框架。類庫以靜態(tài)或動態(tài)的鏈接方式，為我們提供了一組可以調(diào)用的類。框架可以認(rèn)為是類庫的一種擴(kuò)展形式，除了提供可以被應(yīng)用程序調(diào)用的類，還可以驅(qū)動應(yīng)用程序中的功能組件，完成特定的操作流程。

機(jī)載總線數(shù)據(jù)的通用處理即建立通用的可復(fù)用的類，并一個組件集成到類庫中，再對類庫進(jìn)行擴(kuò)展，既可以清晰地描述機(jī)載總線的工作流程，還可以作為一個樣本被納入以后的框架設(shè)計，用UML類圖表示如圖3所示。

圖3 機(jī)載總線數(shù)據(jù)通用處理UML類圖Fig.3 UML class diagram of data general processing of airborne bus

按照圖3所示，框架分為三層結(jié)構(gòu)進(jìn)行設(shè)計。第一層是將機(jī)載總線數(shù)據(jù)獨立于系統(tǒng)進(jìn)行設(shè)計，即作為設(shè)計模式的第一層—抽象工廠。在該層設(shè)計中，按照總線類型創(chuàng)建抽象工廠，每種總線抽象為一個工廠，以面向?qū)ο蟮拈_發(fā)工具M(jìn)FC開發(fā)為例，下面是在MFC中創(chuàng)建抽象工廠的方式［11］：

CDrv429Control m_pDrv429；//創(chuàng)建ARINC429總線對象

CDrv1553Control m_pDrv1553；//創(chuàng) 建1553B總線對象

如果創(chuàng)建的是ARINC429總線，則需要用抽象工廠的接口創(chuàng)建出ARINC429總線的產(chǎn)品：

CDrv429Control m_pDrv429=factory.CreateProduct429Control（）；

新建CDrv429Control類作為ARINC429總線的抽象工廠，m_pDrv429底層對應(yīng)的是創(chuàng)建ARINC429總線相關(guān)的操作，包括數(shù)據(jù)封裝、解析和數(shù)據(jù)收發(fā)等操作。

第二層結(jié)構(gòu)是創(chuàng)建實例工廠。對第一層結(jié)構(gòu)創(chuàng)建的抽象工廠進(jìn)行實例化擴(kuò)展，擴(kuò)展依據(jù)是總線技術(shù)特點和協(xié)議標(biāo)準(zhǔn)，為了實現(xiàn)通用化的處理需求，可以將總線的技術(shù)特點和協(xié)議標(biāo)準(zhǔn)寫成配置信息表，從而將擴(kuò)展過程簡化為對配置信息表的修改過程。下面是在MFC中MIL-STD-1553B總線配置信息表的部分內(nèi)容：

＜ElementRoot＞

＜dev_nums＞1＜/dev_num＞//1553設(shè)備ID

＜MY_CARD_NUM1＞0＜/MY_CARD_NUM1＞//1553通道ID

＜api_bc1_mbuf＞

＜name＞PFAF0100＜/name＞//數(shù)據(jù)塊名稱

＜messno＞0＜/messno＞//消息number

＜control＞0x509＜/control＞//控制字

＜messno_next＞1＜/messno_next＞//下 一 個 消 息nmber

＜mess_command1＞

＜rtaddr＞14＜/rtaddr＞//RT地址

＜subaddr＞1＜/subaddr＞//RT子地址

＜tran_rec＞0＜/tran_rec＞//T/R標(biāo)志

＜wcount＞12＜/wcount＞//數(shù)據(jù)量

＜/mess_command1＞

＜gap_time＞20＜/gap_time＞//間隔時間

＜/api_bc1_mbuf＞

在1553B總線協(xié)議芯片提供的驅(qū)動函數(shù)、或者1553B總線板卡提供的API函數(shù)中調(diào)用配置信息表，完成1553B總線測試系統(tǒng)的搭建。該系統(tǒng)運行以后，1553B總線開始啟動測試，其對外接口即配置信息表［12-13］。

第三層結(jié)構(gòu)是創(chuàng)建實例產(chǎn)品。該層結(jié)構(gòu)是用戶操作的主要對象，包括總線數(shù)據(jù)接口和總線數(shù)據(jù)操作，如果說前兩層結(jié)構(gòu)完成的是機(jī)載數(shù)據(jù)總線運行，那么第三層結(jié)構(gòu)完成的就是總線上究竟有哪些數(shù)字信號、對應(yīng)哪些物理信號以及數(shù)字信號的傳輸方式。在該層設(shè)計中，我們利用第二層對外接口中關(guān)于總線消息定義的模塊來完成信號的定義和操作。下面是第二層結(jié)構(gòu)中分別關(guān)于ARINC429總線和1553B總線消息定義的結(jié)構(gòu)體：

typedef struct_DATA_STRUCTURE_429

｛

char name［100］；//信號名稱

UINT type；//數(shù)據(jù)類型

FLOAT lsb；//數(shù)據(jù)精度

UINT startbit；//數(shù)據(jù)低位

UINT endbit；//數(shù)據(jù)高位

UINT signbit；//是否有符號

UINT channel；//傳輸通道

UINT lable；//lable

UINT rate；//傳輸速率

UINT id；//數(shù)據(jù)塊中的id

UINT source；//源標(biāo)識

｝DATA_STRUCTURE_429；

typedef struct_DATA_STRUCTURE_1553

｛

char name［50］；//信號名稱

UINT type；//數(shù)據(jù)類型

FLOAT lsb；//數(shù)據(jù)精度

UINT startbit；//數(shù)據(jù)低位

UINT endbit；//數(shù)據(jù)高位

UINT signbit；//是否有符號

UINT Value；//數(shù)字信號值

UINT messno；//消息號

UINT index；//消息塊中的索引位置

FLOAT initialD；//初始物理值

char comment［50］；//物理意義

｝DATA_STRUCTURE_1553；

用戶可以將總線數(shù)據(jù)接口文件按照提供的結(jié)構(gòu)體格式，形成第三層結(jié)構(gòu)設(shè)計的配置信息表，總線數(shù)據(jù)操作是對該配置信息表的數(shù)據(jù)元素進(jìn)行操作。至此，完成機(jī)載總線數(shù)據(jù)的通用化處理。由上述設(shè)計過程可見，每一層設(shè)計都是獨立的，但是又與其他層互為對象，抽象工廠模式將處理單個總線數(shù)據(jù)的規(guī)則，通用化得應(yīng)用到了整個這一類總線對象中，從而形成這一類總線的一個實例工廠，便于維護(hù)，也便于在需求發(fā)生改變或擴(kuò)展時，提高可移植性和復(fù)用性。

本文提出的基于抽象工廠模式的機(jī)載總線數(shù)據(jù)通用處理方法，是根據(jù)所有機(jī)載總線的協(xié)議標(biāo)準(zhǔn)和總線數(shù)據(jù)的傳輸特點進(jìn)行的共性分析處理，不受板卡工作方式、接口信號物理定義的限制，在方案設(shè)計中的第二層和第三層實例產(chǎn)品設(shè)計中包含了目前航電系統(tǒng)常用的所有種類的機(jī)載總線。

該方案的通用程度，在數(shù)據(jù)層、協(xié)議層、儀器層三個層面上不盡相同。首先在數(shù)據(jù)層和協(xié)議層兩方面，該方案是完全通用的，這兩個層面屬于應(yīng)用程序級，完全可以復(fù)用方案中所設(shè)計的結(jié)構(gòu)體、配置信息表等實例產(chǎn)品。其次在儀器層方面通用化程度會受一定程度的限制。而第一層設(shè)計的目標(biāo)是建立各總線的硬件操作對象，每個平臺的配置不同、硬件不同，使得該層設(shè)計與測試平臺的硬件密不可分。除此之外，在第二層和第三層是完全可以通用的，因為任何機(jī)載總線數(shù)據(jù)的協(xié)議傳輸特點和接口信號特點都被包含在這兩層設(shè)計的實例產(chǎn)品中。綜上分析，該方案的通用程度很高，能夠?qū)崿F(xiàn)的軟件可復(fù)用率也很高。

該處理方案的有效性體現(xiàn)在軟件模塊實現(xiàn)了可復(fù)用。原來的數(shù)據(jù)處理方案是針對具體項目的每一個接口信號來處理的，而本文所提方案是針對這一類總線協(xié)議的數(shù)據(jù)的；軟件在進(jìn)行數(shù)據(jù)處理時的開發(fā)、運行和維護(hù)，原來是在每個信號的代碼上進(jìn)行的，而經(jīng)過抽象工廠模式的共性特征提取后，軟件的數(shù)據(jù)處理變成了只需要維護(hù)與總線協(xié)議相關(guān)的配置信息表以及接口信息表，而協(xié)議層和數(shù)據(jù)層的工作則是由可復(fù)用模塊來完成［14］。設(shè)計模式對總線數(shù)據(jù)協(xié)議和數(shù)據(jù)處理部分進(jìn)行了重構(gòu)，使類模塊之間更加解耦，模塊內(nèi)部更加內(nèi)聚。不僅代碼總量上有明顯的減少，而且模塊之間的層次更加分明。對于使用者來說不需要關(guān)心內(nèi)部的處理方式，只需要根據(jù)需要做相應(yīng)的配置變更，使用更加簡單。該模塊已通過測試和驗證，可以被安全復(fù)用，提高了軟件開發(fā)的效率，降低了維護(hù)成本，增強(qiáng)了安全性和可靠性［15］。

3 結(jié)論

應(yīng)用抽象工廠模式對機(jī)載總線數(shù)據(jù)進(jìn)行通用化處理，使設(shè)計更靈活、更模塊化。當(dāng)總線需求發(fā)生變化時，數(shù)據(jù)處理的最大障礙是對被實例化的類進(jìn)行硬編碼，而抽象工廠的設(shè)計模式提供了多個不同接口，從實例化它們的代碼中除去對這些類的顯式引用。航空電子系統(tǒng)復(fù)雜多樣的交聯(lián)關(guān)系通過抽象工廠模式的設(shè)計，可以實例成各類總線的接口，從而將原來按部件設(shè)計的接口關(guān)系圖，重新按照總線類型設(shè)計，形成一個靈活易維護(hù)的接口控制文件（ICD），不僅可以完成機(jī)載總線數(shù)據(jù)處理這樣的基礎(chǔ)工作，還可以進(jìn)行測控系統(tǒng)設(shè)計、半實物仿真平臺搭建等更多、更具擴(kuò)展性的系統(tǒng)設(shè)計開發(fā)。因此抽象工廠模式的思想不僅解決了機(jī)載總線數(shù)據(jù)通用化處理的問題，還給測控系統(tǒng)的設(shè)計提供了一種方法，使得測控系統(tǒng)能夠與航空電子系統(tǒng)的快速發(fā)展相適應(yīng)。