白杰

航空電子系統(tǒng)發(fā)展經(jīng)歷了分立式航電系統(tǒng)、聯(lián)合式航電系統(tǒng)、綜合模塊化航電系統(tǒng)幾個階段，逐漸向著開放式、通用化方向發(fā)展。FACE標準規(guī)范化了可移植組件間信息傳輸格式，建立了標準的接口，減少了組件間的數(shù)據(jù)轉(zhuǎn)換，數(shù)據(jù)模型作為軟件層間交流的標準模式，為平臺間軟件模塊的通用提供了解決方案。本文在研究FACE架構(gòu)及數(shù)據(jù)模型的基礎(chǔ)上，構(gòu)建了基于FACE標準的無人機飛行管理功能數(shù)據(jù)模型。

隨著高性能計算機的發(fā)展，航電系統(tǒng)架構(gòu)由“專用”系統(tǒng)向“開放”系統(tǒng)轉(zhuǎn)變，綜合化、模塊化的程度逐步加深。模塊化開放式系統(tǒng)采用模塊化的、接口定義明確的行業(yè)接口標準的系統(tǒng)設(shè)計，在軟件架構(gòu)方面，目前的平臺軟件架構(gòu)層次不夠清晰，不夠系統(tǒng)化；另外，目前的方案沒有系統(tǒng)配置功能，不能根據(jù)不同的需求來定制不同的安全級別。因此，需要在整個軟件層面建立一套層次化、系統(tǒng)化的可移植的架構(gòu)標準，使系統(tǒng)更少的依賴于專利產(chǎn)品，可以通過更多的競爭降低價格，降低項目的風險，獲得多生產(chǎn)廠商的支持。

FACE架構(gòu)功能簡介

未來機載能力環(huán)境（ Future AirborneCapability Environment，F(xiàn)ACE）是由美國海軍航空兵電子項目辦公室在2012設(shè)計出并由FACE協(xié)會使用的技術(shù)標準，相繼發(fā)布了1.0、2.O版本，2014年發(fā)布了2.1版本。該技術(shù)標準用于軟件通用操作環(huán)境的開發(fā)，從而在整個軍事航空界推進可移植性以及軟件產(chǎn)品線的創(chuàng)建。FACE解決方案擴展了模塊化開放式系統(tǒng)的設(shè)計思想，它將一些基于軟件的功能“分層”以組件形式開發(fā)。該組件通過定義好的接口向其他組件開放，并且對特定關(guān)鍵接口及“分層”接口之間的差異進行了定義。

FACE標準作為處于硬件之上的軟件通用操作環(huán)境標準，采用層次化架構(gòu)設(shè)計，包括：操作系統(tǒng)層、輸入/輸出（l/O）服務(wù)層、特殊平臺服務(wù)層（PSS）、傳輸服務(wù)層（TSS）、可移植組件層（PCS）通過這種分層設(shè)計，很好地解決了應(yīng)用程序的可移植性的問題。同時，由于可移植組件的設(shè)計和層間接口標準化，其可移植性不光存在于可移植組件層，其他層也具有可移植性。

（1）操作系統(tǒng)層

操作系統(tǒng)位于所有部分的底層，給其他層軟件提供接口。

（2）I/0服務(wù)層

I/O服務(wù)層的軟件負責系統(tǒng)設(shè)備驅(qū)動和特定平臺服務(wù)層間的數(shù)據(jù)傳輸。這層是與底層的供應(yīng)商提供驅(qū)動交流的適配器模式，給上層FACE標準化的接口提供轉(zhuǎn)化后的數(shù)據(jù)。當編碼廢棄或者是驅(qū)動改變的情況發(fā)生時，I/O層只需更改適配器即可。由于改變所帶來的影響都被封裝在了適配器中，所以其它層軟件不需要另外的改變。

（3）特定平臺服務(wù)層

特定平臺服務(wù)層包含傳統(tǒng)軟件架構(gòu)中與特定平臺設(shè)備ICD緊耦合的那部分，規(guī)范或者封裝與FCAE系統(tǒng)相關(guān)的設(shè)備管理業(yè)務(wù)，提供的數(shù)據(jù)通過傳輸層傳輸給可移植組件，作為其平臺數(shù)據(jù)源。

（4）傳輸服務(wù)層

傳輸服務(wù)層是數(shù)據(jù)的中間傳輸層，使FACE應(yīng)用不需知道數(shù)據(jù)終端在什么地方，就可以達到數(shù)據(jù)傳輸?shù)侥康?。同時可以通過這層中間層，降低特定平臺服務(wù)層中組件變化給可移植組件層組件帶來的影響。

（5）可移植組件層

可移植組件層封裝了FACE系統(tǒng)的邏輯控制業(yè)務(wù)和與平臺無關(guān)的航電通用功能，由一系列可移植FACE應(yīng)用和通用服務(wù)組成，當這些服務(wù)一起工作時提供平臺級別的能力。

可移植組件集（Uop）

在不同平臺上使用相同功能時，可能因為供應(yīng)商不同需要重新開發(fā)，顯然這樣是不劃算的。如果任務(wù)級別功能具備可移植性，那么在需求發(fā)生改變時，就可以減少源代碼的更改，整合和維護等工作量也會相應(yīng)減少。FACE Uop的構(gòu)建符合以下標準：

（1）包括所有相關(guān)軟件、非標準編程語言運行庫、庫、程序語言框架。

（2）提供一個或多個服務(wù)或任務(wù)級別功能。

（3）一個FACE Uop只能存在于一個層或者子層中，不能跨層存在。但是可以將一些Uop打包成一個可以跨層存在的邏輯實體。

（4）一個FACE Uop只能單獨存在于一個分區(qū)中，如果Uop中包含編程語言運行庫或程序框架時，那么他們在一個單獨的分區(qū)中通過多重Uop執(zhí)行。當Uop移植到另外的分區(qū)、平臺上時，編程語言運行庫或程序框架隨之移植。

（6） FACE Uop之間在進行數(shù)據(jù)傳輸是必須使用TS接口、I/O服務(wù)接口、編程語言運行庫、程序框架接口、操作系統(tǒng)接口之一。

（7） Uop的子集在FACE不同層中執(zhí)行，在進行數(shù)據(jù)傳輸時，語言運行庫應(yīng)符合FACE相應(yīng)接口。

（8）不同層中Uop之間進行通信時使用相應(yīng)接口。

（9）非標準框架或者編程語言運行庫經(jīng)常包含于Uop中，并且符合FACE定義接口。

對于UoP間通信情況，見圖]。Uop內(nèi)部組件間通信可以使用TS接口或直接通信。F-Uop中軟件實體間使用TS接口進行通信時，就不再需要使用專用內(nèi)部通信方式。通過對整體應(yīng)用的解耦，分解成更多的Uop，可以將已存在的銷售商產(chǎn)品線遷移成更高度的模塊化產(chǎn)品，同時多種通信方式降低了轉(zhuǎn)化難度。

數(shù)據(jù)模型

FACE層間通過指令、請求、位置信息、高度信息、電壓、電流等數(shù)據(jù)進行數(shù)據(jù)交互，但是很多時候，由于數(shù)據(jù)繁多龐大，不同廠商設(shè)備或者應(yīng)用中數(shù)據(jù)格式、單位、范圍等定義不同造成接口不匹配問題，浪費開發(fā)時間。數(shù)據(jù)模型為軟件層間的交流提供了標準模式。通過嚴格定義唯一性模型，能保證它們不可被復(fù)制且能容易的添加其他的數(shù)據(jù)參數(shù)，便于開發(fā)者區(qū)分全部信息，在需要改變時，能以最少改變被處理成符合FACE數(shù)據(jù)模型的部分，消除了許多開發(fā)過程中多個供應(yīng)商之間橫向接口不匹配的問題。

FACE數(shù)據(jù)結(jié)構(gòu)實現(xiàn)過程依次為：概念到邏輯；邏輯到平臺；平臺到可移植單元；可移植單元到代碼，如圖2所示。

概念模型包括基本的概念，這些概念包括整體的屬性和整體間的關(guān)系。

邏輯數(shù)據(jù)模型實體由概念數(shù)據(jù)模型實體創(chuàng)建而來。一個概念數(shù)據(jù)模型實體可能由多個邏輯數(shù)據(jù)模型實體實現(xiàn)。邏輯數(shù)據(jù)模型基礎(chǔ)元素通過提煉概念數(shù)據(jù)模型元素創(chuàng)建，包括單位、度量、坐標系、值域、約束條件和度量精度等詳細信息。

平臺數(shù)據(jù)模型中的實體與邏輯數(shù)據(jù)模型中的實體相關(guān)。數(shù)據(jù)模型實體由邏輯數(shù)據(jù)模型實體創(chuàng)建而來。平臺數(shù)據(jù)模型支持的物理數(shù)據(jù)類型符合接口定義語言（IDL）數(shù)據(jù)類型：布爾型、字符型、枚舉等。從平臺數(shù)據(jù)模型映射到程序語言有標準的語言映射規(guī)范。語言連結(jié)為通過TS接口傳輸?shù)男畔?shù)據(jù)結(jié)構(gòu)提供了識別功能，保證了組件在API上的可移植性。

Uop模型為Uop提供了信息接口識別功能。在Uop中，信息接口識別為端口，為了識別信息類型，在平臺數(shù)據(jù)模型中信息接口表現(xiàn)為視圖。平臺數(shù)據(jù)模型中的視圖在UOP中表現(xiàn)為通過TSS API傳輸?shù)男畔ⅰ?/p>

FACE數(shù)據(jù)模型語言連結(jié)是對PDM映射到程序語言的一系列設(shè)置。不同的語言，映射過程不同。語言連接定義了如何從平臺數(shù)據(jù)模型視圖生成代碼。

基于數(shù)據(jù)模型的組件接口實現(xiàn)

典型無人機飛行管理功能主要實現(xiàn)飛控計算機、起落架控制裝置、電氣系統(tǒng)設(shè)備的控制管理。功能實現(xiàn)包括飛行管理組件、飛控控制組件、起落架控制組件、電氣控制組件、傳輸服務(wù)組件和1553B服務(wù)組件，組件間通信示意圖如下：

概念模型

飛行管理組件從飛控控制處接收起落架收放、剎車控制盒加電斷電請求，獲得高度、經(jīng)緯度等數(shù)據(jù)；向起落架控制發(fā)送起落架收、起落架放兩個標準化的指令，接收起落架狀態(tài)信息；向電氣控制發(fā)送剎車控制盒斷電、剎車控制盒加電、空速加溫器供電指令。將飛行管理功能作為Uop進行建模，概念模型如下：

飛行管理接收飛控計算機的請求、數(shù)據(jù)，向飛控計算機返回指令執(zhí)行狀態(tài)，向起落架控制發(fā)送指令，接收起落架控制返回的狀態(tài)，向電氣控制發(fā)送指令，接收電氣控制返回的狀態(tài)，所以這七個元素可作為概念元素。

邏輯模型

飛行管理向起落架控制發(fā)送的指令是復(fù)合測量值，由信息ID和指令編碼兩個獨立測量值組成，均為枚舉量，代表不同指令內(nèi)容。其他指令、請求邏輯模型構(gòu)建類似。

起落架控制向飛行管理返回狀態(tài)，狀態(tài)是復(fù)合測量值，由信息ID、指令編碼、執(zhí)行結(jié)果、工作狀態(tài)，校驗和組成，除校驗和之外幾個參數(shù)均為枚舉量。

飛控控制向飛行管理發(fā)送空速管加溫器加電、起落架收、起落架放、剎車控制盒加電、剎車控制盒斷電請求，三個請求均為復(fù)合測量值，包括信息ID、指令編碼兩個獨立測量值。

飛控控制向飛行管理發(fā)送高度數(shù)據(jù)，高度數(shù)據(jù)為獨立測量值，詳細信息如圖6所示：

飛行管理接收請求后返回請求執(zhí)行狀態(tài)，狀態(tài)是復(fù)合測量值，包括信息ID、請求編碼、執(zhí)行結(jié)果、工作狀態(tài)。

飛行管理向起電氣控制發(fā)送空速管加溫器加電指令、起落架收、起落架放指令，指令為復(fù)合測量值，由信息ID和指令編碼兩個獨立測量值組成，均為枚舉值，代表不同指令內(nèi)容。

電氣控制向飛行管理返回狀態(tài)，狀態(tài)是復(fù)合測量值，由信息ID（枚舉值）、指令編碼、執(zhí)行結(jié)果、工作狀態(tài)和校驗和組成。

平臺模型

下一步為指令的消息ID、指令編碼，請求的消息ID、請求編碼，狀態(tài)的消息ID、指令編碼等測量值創(chuàng)建平臺展示，創(chuàng)建展示測量值的IDL實例。復(fù)合測量值使用IDL結(jié)構(gòu)體實現(xiàn)。

對各組件接收請求或指令后返回狀態(tài)創(chuàng)建平臺展示，返回狀態(tài)為復(fù)合測量值，使用IDL結(jié)構(gòu)體實現(xiàn)，使用IDL實現(xiàn)狀態(tài)復(fù)合測量值中的信息ID、指令/請求編碼、執(zhí)行結(jié)果、工作狀態(tài)和校驗和測量值。

首先是飛行管理向起落架控制指令的平臺模型創(chuàng)建，指令使用IDL結(jié)構(gòu)體實現(xiàn)，兩個獨立測量值由IDL實現(xiàn)，定義其數(shù)據(jù)類型（其他指令平臺構(gòu)建過程類似），詳細信息見圖7：

飛行管理向電氣控制發(fā)送指令的平臺模型創(chuàng)建過程同上。

飛控計算機向飛行管理發(fā)送的請求使用IDL結(jié)構(gòu)體實現(xiàn)，信息ID和請求編碼兩個獨立測量值由IDL實現(xiàn)，分別定義其數(shù)據(jù)類型，定義枚舉量的個數(shù)及含義。

飛控計算機向飛行管理發(fā)送的高度數(shù)據(jù)創(chuàng)建平臺展示，使用IDL實現(xiàn)高度測量值，詳細信息如下：

然后對各組件接收請求或指令后返回狀態(tài)創(chuàng)建平臺展示，返回狀態(tài)為復(fù)合測量值，使用IDL結(jié)構(gòu)體實現(xiàn)，使用IDL實現(xiàn)狀態(tài)復(fù)合測量值中的信息ID、指令/請求編碼、執(zhí)行結(jié)果、工作狀態(tài)和校驗和測量值。

Uop模型

當測量值映射到IDL概念后，就可以創(chuàng)建組件中輸入和輸出的信息平臺視圖。飛行管理從飛控計算機處獲得請求和高度數(shù)據(jù)，從起落架控制和電氣控制處獲得狀態(tài)信息，對電氣控制和起落架控制發(fā)出指令，對飛控計算機返回狀態(tài)。為飛行管理Uop建模和確定其特征，為每個輸入輸出定義端口，描述使用端口通信的信息，將信息類型映射到端口。詳細信息如下：

使用相應(yīng)軟件實現(xiàn)代碼的映射，即可完成可移植組件層與特定平臺服務(wù)層的接口的標準化。

總結(jié)

基于FACE的無人機飛行管理功能構(gòu)建的數(shù)據(jù)模型，為軟件層間提供了標準的交流模式，數(shù)據(jù)模型使軟件分析、設(shè)計之初就是標準的模式，從而保障后續(xù)的設(shè)計、實踐、維護中軟件的復(fù)用性，更好地兼容平臺，使航電軟件更加類似于智能手機應(yīng)用，在不影響其他系統(tǒng)的情況下非常方便增加或減少一個給定的應(yīng)用，為在多個平臺上復(fù)用提供了可能。基于FACE的航電軟件數(shù)據(jù)模型構(gòu)建，對提高軟件開發(fā)質(zhì)量，增強架構(gòu)中應(yīng)用、層間數(shù)據(jù)傳輸?shù)臉藴市浴⒖蓮?fù)用性，進而降低開發(fā)成本，節(jié)約開發(fā)時間有重要指導(dǎo)意義。