基于FACE的無人機飛行管理功能數據模型構建

白杰

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

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

FACE架構功能簡介

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

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

（1）操作系統層

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

（2）I/0服務層

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

（3）特定平臺服務層

特定平臺服務層包含傳統軟件架構中與特定平臺設備ICD緊耦合的那部分，規范或者封裝與FCAE系統相關的設備管理業務，提供的數據通過傳輸層傳輸給可移植組件，作為其平臺數據源。

（4）傳輸服務層

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

（5）可移植組件層

可移植組件層封裝了FACE系統的邏輯控制業務和與平臺無關的航電通用功能，由一系列可移植FACE應用和通用服務組成，當這些服務一起工作時提供平臺級別的能力。

可移植組件集（Uop）

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

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

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

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

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

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

（7） Uop的子集在FACE不同層中執行，在進行數據傳輸時，語言運行庫應符合FACE相應接口。

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

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

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

數據模型

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

FACE數據結構實現過程依次為：概念到邏輯；邏輯到平臺；平臺到可移植單元；可移植單元到代碼，如圖2所示。

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

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

平臺數據模型中的實體與邏輯數據模型中的實體相關。數據模型實體由邏輯數據模型實體創建而來。平臺數據模型支持的物理數據類型符合接口定義語言（IDL）數據類型：布爾型、字符型、枚舉等。從平臺數據模型映射到程序語言有標準的語言映射規范。語言連結為通過TS接口傳輸的信息數據結構提供了識別功能，保證了組件在API上的可移植性。

Uop模型為Uop提供了信息接口識別功能。在Uop中，信息接口識別為端口，為了識別信息類型，在平臺數據模型中信息接口表現為視圖。平臺數據模型中的視圖在UOP中表現為通過TSS API傳輸的信息。

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

基于數據模型的組件接口實現

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

概念模型

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

飛行管理接收飛控計算機的請求、數據，向飛控計算機返回指令執行狀態，向起落架控制發送指令，接收起落架控制返回的狀態，向電氣控制發送指令，接收電氣控制返回的狀態，所以這七個元素可作為概念元素。

邏輯模型

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

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

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

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

飛行管理接收請求后返回請求執行狀態，狀態是復合測量值，包括信息ID、請求編碼、執行結果、工作狀態。

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

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

平臺模型

下一步為指令的消息ID、指令編碼，請求的消息ID、請求編碼，狀態的消息ID、指令編碼等測量值創建平臺展示，創建展示測量值的IDL實例。復合測量值使用IDL結構體實現。

對各組件接收請求或指令后返回狀態創建平臺展示，返回狀態為復合測量值，使用IDL結構體實現，使用IDL實現狀態復合測量值中的信息ID、指令/請求編碼、執行結果、工作狀態和校驗和測量值。

首先是飛行管理向起落架控制指令的平臺模型創建，指令使用IDL結構體實現，兩個獨立測量值由IDL實現，定義其數據類型（其他指令平臺構建過程類似），詳細信息見圖7：

飛行管理向電氣控制發送指令的平臺模型創建過程同上。

飛控計算機向飛行管理發送的請求使用IDL結構體實現，信息ID和請求編碼兩個獨立測量值由IDL實現，分別定義其數據類型，定義枚舉量的個數及含義。

飛控計算機向飛行管理發送的高度數據創建平臺展示，使用IDL實現高度測量值，詳細信息如下：

然后對各組件接收請求或指令后返回狀態創建平臺展示，返回狀態為復合測量值，使用IDL結構體實現，使用IDL實現狀態復合測量值中的信息ID、指令/請求編碼、執行結果、工作狀態和校驗和測量值。

Uop模型

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

使用相應軟件實現代碼的映射，即可完成可移植組件層與特定平臺服務層的接口的標準化。

總結

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