基于REST架構的總裝階段飛控測試數據集成*

韓 冰，楊 鋒，王 萍，沈 佳，孫 溢，王麗斌，方 強，魏燕定

（1.中航西安飛機工業集團股份有限公司，西安 710089；2.浙江大學機械工程學院，杭州 310027）

發展航空航天產業是增強國家核心競爭力的重要戰略措施，在國家科技部的支持下，大飛機產業正處于研究、批量化生產高交織的關鍵階段。針對飛機的測試技術是保障飛機設計、研制、生產和使用維護各個階段正常運轉的重要支撐。

總裝階段飛控測試是在完成飛機總裝后，通過飛控系統運行原理與外接口，借助測試設備進行飛控系統功能測試的過程[1]。總裝階段的飛控測試技術發展主要經過了人工測試階段、專用半自動/自動測試階段、標準接口半自動/自動測試階段、計算機與標準自動測試階段以及虛擬儀器和標準自動測試系統階段[2]。目前，總裝階段飛控測試技術正朝著測試設備綜合化、通用化、數字化、虛擬化以及設備統籌規劃、集中管控、分布式布局和縱向一體化測試方向發展[3–4]。

21世紀以來，隨著技術的進一步發展，各廠商研發出了許多測試效果良好的測試系統，如歐洲宇航防務公司提出了飛機總裝地面支持設備方案（FAL GSE Project），用于統籌整個飛機總裝過程中的所有測試設備的運行，可以完成包括飛控系統在內的多項地面測試任務。美國空軍在設計C–17運輸機的測試設備時，分析了C–17的測試需求，成功集成了當時的測試設備進行飛機測試[5]。洛·馬公司為F–35研制了LM–STAR系統，具有通用的開放式體系結構，是目前最具代表性的縱向一體化的綜合測試設備。與此同時，中國廣州航新也研發出了具有先進的總線技術、虛擬仿真以及綜合測試等功能的航新自動試驗設備（ATE）產品[6]。中國潤科通用集成測試系統采用通用化、模塊化和綜合化設計思想，基于分布式、網絡化、可擴展的柔性測試架構進行設計，基于標準的以太網技術構建測試網絡，通過測試網絡實現各測試軟件、測試 I/O 資源的交互，搭建一個軟硬件模塊易于擴展的集成驗證環境。這些測試系統雖然具有強大的功能，但是普遍操作復雜，對老舊測試設備缺乏支持，可移植性較差，系統界面也多以客戶端軟件的形式呈現，升級換代成本較高，不利于擴展。國內部分飛控測試設備甚至依舊停留在上個世紀七八十年代，因此，為了在現有條件下實現總裝階段飛控系統測試的數字化改造，需要研制操作簡單、能夠集成老舊設備且具有較低成本的測試平臺。

另一方面，在用飛控系統進行功能測試時，設備廠商通常針對單個功能需求開發專用的測試設備。然而，這些專用測試設備大多內部封閉，組件緊耦合，架構各異，數據模型也各不相同。這使得不同設備之間缺少信息交互，限制了測試設備間信息的共享和重用，從而形成了信息孤島[7]，進一步使得總裝階段飛控數字化測試中存在大量的多源異構數據，降低了飛控系統測試的擴展性和設備間的互操作性[8]。因此，為了實現總裝階段飛控數字化測試的可擴展性和可操作性，需要對總裝階段飛控數字化測試場景中各種傳感器、激勵設備、機載系統的異構數據集成進行研究。

針對上述問題，本文將對總裝階段飛控系統測試過程中的多源異構數據集成技術展開研究，設計一種基于表述性狀態轉移（Representational state transfer，REST）架構的多源異構數據集成服務，用于解決總裝階段飛控系統數字化測試過程中數據的多源異構問題，為飛控系統功能程序化、數字化測試提供技術基礎，并為最終實現飛控系統測試的自動化、高效化、標準化和專業化提供技術支撐。

飛控測試多源異構數據來源

在目前的總裝階段，飛控數字化測試中常用的主要測試設備有飛控地面維護設備、大氣數據激勵設備、無線電高度表激勵器、單軸速率轉臺和外部測量裝置等，這些設備在測試過程中放置在飛機的不同位置，并與飛機的相應測試接口連接。當需要操作這些設備時可以直接操作設備的上位機或是從這些設備預留的擴展接口進行遠程修改與讀取。

飛控地面維護設備是一種綜合化的智能檢測設備，集成了飛行控制系統計算機的檢測功能，是在飛控測試過程中讀取飛控計算機參數的重要設備。飛控地面維護設備由主飛控地面維護設備、高升力地面維護設備和自動飛行地面維護設備組成，分別用于檢測飛控計算機的不同功能。飛控地面維護設備主要用來對飛行控制操縱系統進行飛行前自檢、機上性能檢測、調式及故障定位工作。飛控地面維護設備需要連接飛控計算機的ARINC429總線、RS232和RS422接口。此外，還有離散的數字信號、模擬信號以及旋變類RVDT信號等，其連接如圖1所示。

飛控地面維護設備采集到這些信息后，通過預設的格式在屏幕顯示。用戶也可以通過飛控地面維護設備提供的以太網、USB接口等對其進行遠程控制，從而獲得飛控計算機的相關數據，這也是實現總裝階段飛控數字化測試的基礎之一。

大氣數據激勵設備是在飛控測試過程中在地面給出模擬的激勵信號以測試大氣數據機的功能以及與其他機載設備聯調測試時給出模擬數據的測試設備。該設備可以通過內置泵產生壓力和真空源、靜壓或是高度、總壓或是動壓、空速，還可以模擬高度和空速，產生爬升率、空速變化率、靜壓變化速率、動壓變化率、總壓變化率、馬赫數以及進行泄露測試等。本文所涉及的大氣數據激勵設備內置了以太網接口，支持TCP/IP協議，通過大氣數據激勵設備廠商定義的查詢方式，可以實現遠程控制。

單軸速率轉臺主要由一個可做回轉運動的平臺和固定底座組成，可以調節轉動速率、加速度等，用于角速率陀螺相關的系統功能和性能檢查。使用時通過工裝將飛機內部的角速率陀螺儀固定在轉臺上，并調節不同的轉速測試角速率陀螺儀的功能。在飛控測試中使用的單軸速率轉臺具有一個RS232接口，通過廠商給出的協議，計算機可以對單軸速率轉臺進行遠程控制。

圖1 飛控計算機與地面維護設備之間的連接Fig.1 Connection between flight control computer and ground maintenance equipment

在飛控測試過程中，需要對飛機機翼和舵面進行測試，以檢驗飛機副翼舵面、多功能擾流板、地面擾流板、前緣縫翼和后緣襟翼、升降舵、水平安定面、方向舵的功能是否滿足技術要求。然后進一步檢查舵面極限位置和舵面運動是否滿足極性、傳動以及行程等要求，該過程需要反復進行調整、檢測，直至最終滿足要求。外部測量裝置需要在不破壞飛機原狀態的基礎上完成副翼、升降舵、方向舵、襟翼、縫翼、擾流板及水平安定面等眾多舵面偏轉角度的測量以及襟翼、縫翼PDU扭力桿輸出圈數測量。外部測量裝置的傳感器測得的信號是電壓、電流等電信號，這些信號無法直接利用，需要經過上位機轉換后才能進行使用。

由上述介紹可知，總裝階段飛控系統的測試過程需要許多測試設備，這些不同的設備造成數據來源的不同，而且在總裝階段飛控數字化測試過程中，測試設備的數據存放在測試設備的上位機或是傳感器的芯片中，這些數據按照不同的標準進行設計，造成了數據的異構，為總裝階段的飛控系統測試工作帶來了大量的多源異構數據。多源異構數據的存在使得測試平臺難以滿足通用性要求。而將現有的測試設備淘汰進行整體更新換代，不僅成本較高而且浪費設備資源。為了兼容現有的測試設備，總裝階段飛控數字化測試需要實現各個測試設備之間的電氣連接和數據交換。只有將多源異構數據進行集成，才能為總裝階段飛控數字化測試提供良好的數據基礎。

設備集成試驗平臺構建

總裝階段飛控測試中的設備集成試驗平臺使用以太網作為最終的數據傳輸網絡，使用接口轉換裝置將不同設備接入以太網。

1 數據傳輸模式

總裝階段飛控數字化測試中多種總線共存，各種協議互不兼容的問題也是國內外設備集成廠商面臨的困境之一。為了解決這個問題，需要設計接口轉換裝置，將接口和協議進行轉化后，進行統一的輸出。以太網是目前使用最廣泛的一種計算機網絡，可以很方便地實現網絡的擴展，并且支持多種語言的開發。

本文采用以太網作為最終的傳輸網絡，設計接口轉換裝置將現有的設備底層協議轉換為統一的形式接入以太網，在以太網中通過TCP/IP協議進行數據傳輸。圖 2為試驗平臺中各設備的連接方式。

當測試設備、服務器、手持終端等都接入局域網后，所有的測試信息在局域網中傳遞。測試設備在現場采集的測試數據通過以太網TCP/IP通訊協議進行傳輸，服務器通過以太網TCP/IP發布測控命令并接收測試設備發送的數據。執行人員手持的終端需要通過網線連接進入以太網局域網。每個測控設備內部通訊細節對以太網屏蔽，所以，在進行測控時只需要關注具體的測控任務不需要考慮測控設備內部的執行邏輯，有利于模塊化的系統開發和功能擴展。

2 設備接口轉換

接口轉換裝置芯片將不同的設備協議進行翻譯轉換形成以太網可傳輸的協議，如TCP/IP協議。常見的如USB轉串口，USB轉以太網，串口轉以太網等。常用接口的轉換是一種較為成熟的技術，因此，大多數的接口轉換僅需要尋找合適的產品即可，對于一些自定義的接口，則需要自行開發接口轉換裝置。例如，對于無法轉換成TCP/IP協議的總線接口，可通過特定總線的板卡接入節點工控機中，工控機運行自定義的程序，該程序是根據具體通訊協議對設備數據進行解析并包裝為TCP/IP數據包的客戶端程序。因此，該工控機也可以稱為適配器。

接口進行改造后，設備得以接入以太網，其連接方式如圖 3所示。飛控地面維護設備、無線電高度表激勵器、大氣數據激勵設備都有以太網接口。但是單軸速率轉臺在設計之初就沒有預留以太網接口而只有RS232串口，因此，需要添加一個串口轉以太網的裝置完成接口的轉換。外部測量裝置的傳感器都是電信號，需要通過電信號轉以太網的裝置才能接入以太網。

圖2 試驗平臺電氣連接Fig.2 Electrical connection of test platform

基于REST架構的多源異構數據集成服務設計

REST架構，是由Fielding Roy博士提出的一種分布式軟件架構風格。它是一種面向資源的軟件架構。REST架構對不同系統具有極好的兼容性，具有平臺無關的特性，對老舊設備有著很強的可訪問性和互操作性，使得REST架構成為老舊設備改造的一種優選架構[9–12]。

對多源異構數據集成進行分層設計，設備數據視圖層是完成多源異構數據集成后的直觀成果，也是完成多源異構數據集成的基礎目標。而設備數據視圖層下又分為應用層、中間層、包裝層和設備/數據源層4層，每一層都只對相鄰層暴露接口，圖 4為基于REST架構的多源異構數據集成的整體設計。

1 設備數據視圖層

設備數據視圖層是多源異構數據集成服務對外的視圖，服務請求者可以根據REST風格的HTTP請求向設備數據視圖層請求資源，并接收JSON格式的返回值。對于服務請求者來說雖然設備的數據在物理上依舊保存在各個設備內部，但是通過虛擬的設備數據視圖層，就和向一張統一的數據表請求數據一樣。總裝階段飛控數字化測試過程中，如果步驟需要設備參與，服務器就會對設備數據視圖層進行操作，設備數據視圖層將會按照REST的風格發送HTTP請求給應用層。

1.1 設備數據視圖層URI設計

圖3 設備連接設計Fig.3 Device connection design

圖4 基于REST架構的多源異構數據集成整體設計Fig.4 Overall design of multi–source heterogeneous data integration based on REST architecture

根據REST架構的定義，需要設計統一形式的資源URI以實現通過REST形式的HTTP請求對設備進行操作，資源URI的統一形式可以設計為：http：// {IP地址}：{端口號}/device/{設備位置}/{數據類型}/{設備類別}/{資源名稱}?param={值}，其中，{IP地址}、{端口號}為多源異構數據集成服務的IP地址和端口號；{設備位置}為配置文件中定義的設備放置位置，一般以locationX的形式給出，X為地址索引號；{數據類型}分為激勵數據、外部數據和內部數據3種，分別用incentive，external，internal表示；{設備類別}為設備的接口名稱，將駝峰命名的大寫字母轉化為“_”+小寫字母的形 式，如atmosphericDataIncentive，轉化為atmospheric_data_incentive；{資源名稱}為所定義的資源的名稱，如air_height，air_speed，air_mach等；{值}根據需求填寫相應的數值。依據REST風格，可以將請求劃分成4類，如表1所示。

當服務器需要修改大氣數據激勵設備的某個參數時，如要修改位于“location1”位置，設備類型為“大氣數據激勵設備”的設備的激勵高度為100m，可以使用PUT方式發送HTTP請求，其URI可設計為：http：//xxxxxx：xx/device/locationX/incentive/atmospheric_data_incentive/air_height?param=100。

表1 REST請求方式Table 1 REST request

當服務器需要查詢大氣數據激勵設備的某個參數時，如要查詢位于“location1”位置的，設備類型為“大氣數據激勵設備”的設備的激勵高度，可以使用GET方式發送HTTP請求，其URI可設計為：http：//xxxxxx：xx/device/locationX/incentive/atmospheric_data_incentive/air_height。

1.2 面向設備應用層URI設計

為了簡化開發，設備應用層處理的URI與設備數據視圖層的URI有所不同。設備數據視圖層面向的是所有的設備，是多源異構數據集成后的視圖，而應用層的作用則是將設備的數據傳輸方式進行統一，面向單個設備，處于更低的層次。

應用層處理的URI與設備數據視圖層處理的URI相比沒有“/device/{設備位置}/{數據類型}”前綴，其形式為：http：// {IP地址}：{端口號}/{設備類別}/{資源名稱}?param={值}。

因此，在對設備資源進行抽象時可以不用考慮設備的放置位置和數據類型，而是將這部分的內容交給設備數據視圖層來決定。依舊以上述的設置和讀取大氣數據激勵設備的激勵高度為例，與設備數據視圖層的URI不同，應用層采用PUT方式發送請求，設置大氣數據激勵設備的高度激勵URI設計為：http：//yyyy：yy/atmospheric_data_incentive/air_height?param=100。

而讀取大氣數據激勵高度采用GET方式發送請求，其URI設計為：http：//yyyy：yy/atmospheric_data_incentive/air_height。其 中，yyyy：yy為上述location1位置的大氣數據激勵設備的IP和端口。可以看出應用層不關心設備數據視圖層對設備資源的定義，而是為設備所具有的資源設置好各自的統一資源標識符即可。不同URI的設計使得在進行設備應用層開發的時候可以只關注單獨的設備，提供底層的服務，而在設備數據視圖層開發時才對不同設備資源進行鏈接設計。由于設備使用了統一的URI格式，可以很方便地定位所需的設備資源，即使兩臺設備完全一樣，只是放置的位置不同也可以通過IP地址端口進行區分。

使用不同URI的另一個好處是有利于擴展開放，未來加入新的測試設備時，設計中只需要按照REST架構進行設計，不論使用了何種接口何種協議，只要預留了REST的應用程序接口即可實現快速接入和跨平臺使用。

2 應用層

應用層是與設備數據視圖層直接交互的一層，通過接收REST風格的HTTP請求進行測試意圖的分析，并返回結果。應用層和設備數據視圖層一樣，需要實現HTTP請求的解析和響應值的包裝兩大功能。應用層解析HTTP請求方式和URI，然后進行資源定位，明確操作意圖，接著調用中間層的方法控制測試設備，最后將返回值反映到設備數據視圖層上。

3 中間層

中間層用于實現對設備的操作，可以根據應用層傳入的資源信息、操作方式等參數，通過java的反射機制動態生成設備對象，之后根據需求調用包裝層的方法，最后返回所求資源。中間層是應用層和包裝層之間的橋梁，向上提供統一的調用接口，向下屏蔽底層調用細節。中間層獲得的數據屬于多源異構數據，需要經過數據映射，轉化成統一的JSON數據格式后返回應用層。

使用java的反射機制可以在運行時動態地創建實例對象。新設備加入時不需要修改源代碼，只需要增加新的實現類，然后更新配置即可，提高了系統的擴展性和穩定性。以大氣數據激勵設備、無線電高度表激勵器和單軸速率轉臺為例，根據測試需求進行設備種類的抽象，如表 2所示。

抽象工廠模式是23種設計模式中的創建型設計模式之一。抽象工廠類根據需求生成相應的設備工廠，然后根據設備型號和配置文件掃描對應的實現類通過反射生成實例對象。設備對象封裝了實現測試所需的所有功能，系統調用相應的方法與測試設備通訊，并接收返回值來判斷是否進行下一步測試。Java的反射機制可以動態生成實例對象，但是具體生成什么對象，何時生成對象，如何生成對象就需要查詢配置文件動態生成。

當應用層將設備類型、設備型號、目標參數、操作、目標值等傳入中間層后，服務查詢配置文件找到對應的設備類型的工廠類和接口實現類的全限定名，基于反射機制動態生成設備對象后，就可以與設備進行通信，實現設備的控制。這樣的好處是當需要更換、添加、升級設備時，只需要添加新的實現類，然后在配置文件中寫入映射，不必修改系統的源碼。

中間層還負責與Mysql數據庫的交互，將表征具體意義的設備數據存儲至相應數據表中。數據庫的核心數據表為device_category、device_command以及device，其中，device_category表用于存儲設備類型，不同的設備類型具有不同的設備指令；device_command表用于存儲設備指令，一條記錄對應一條設備指令，也就對應REST風格的URI；device表用于存儲具體設備信息，包括設備IP和端口號等。

表2 部分設備接口表Table 2 Partial equipment interface table

4 包裝層

包裝層的作用是對設備的通訊接口做一次封裝，將原先各不相同的底層協議進行封裝，轉化為TCP/IP協議，使設備具有統一的數據傳輸方式。

以RS232和以太網的轉換為例，本文選用了USR–TCP232–306串口服務器N520，如圖 5所示，該串口服務器支持600bps～230.4Kbps波特率范圍，支持硬件流控（RTS/CTS）和軟件流控（XON/XOFF），可將串口數據靈活分幀。將設備的串口和服務器的以太網口進行連接，串口服務器工作在TCP server模式。經過設備接口改造后，所有的接口都轉換成了以太網接口，服務器和設備使用TCP/IP協議在局域網進行通訊。

5 設備/數據源層

設備/數據源層與測試設備相關聯，是測試數據的來源，必須要使用測試設備各自的通訊、查詢、調用格式才能進行訪問。

應用實例

多源異構數據集成服務是總裝階段飛控數字化測試的數據基礎。總裝階段飛控數字化測試的服務器通過發送REST風格的HTTP請求獲得所需的數據。為了便于試驗，設計了多源異構數據集成測試界面，用于測試服務器向多源異構數據集成服務發送指令，以此驗證多源異構數據集成服務的功能。

1 設備數據源采集

為了檢驗多源異構數據集成服務是否可以實現對外提供統一的訪問接口，實現對不同設備的相同訪問方式控制，本文測試了飛控系統現場測試中常用的3個設備大氣數據激勵設備、無線電高度表激勵器以及單軸速率轉臺的通訊，將3個設備作為多源異構數據的數據源。

大氣數據激勵設備采用意大利DMA公司的MPS45，如圖6所示；無線電高度表激勵器型號為WGJ–1。兩種設備前面板均提供以太網RJ45接口，網絡通信遵守TCP/IP協議。單軸速率轉臺提供RS232串口，由架構中的包裝層進行協議封裝，利用串口服務器，轉化為以太網接口以及TCP/IP協議。

圖5 串口服務器Fig.5 Serial server

圖6 大氣數據激勵設備Fig.6 Atmospheric data incentive

表3 設備IP及端口Table 3 Equipment’s IP and port

首先需要配置設備IP及端口，將大氣數據激勵設備、無線電高度表激勵器、單軸速率轉臺與服務器、路由器、交換機，通過網線接入局域網并連入同一網段，如表3所示。3種設備會作為服務端監聽其綁定的端口，等待客戶端的連接請求。

2 測試設備控制驗證

2.1 現有資源請求

在請求設備現有資源時，3種設備在設備數據視圖層的方法類似，因此，以大氣數據激勵設備為例，對大氣數據激勵設備的“馬赫數”這一資源，即“air_mach”進行操作。使用“多源異構數據集成測試界面”進行測試，如圖 7所示。

圖7中的設備指令代表著設置馬赫數的操作，點擊按鈕即可設置，程序在后臺根據REST風格進行URI的設計，搜索配置文件可以得到設備放置在“location1”，URI設計如下，并使用PUT方式對設備數據視圖層進行HTTP請求：http：//192.168.0.101：8081/device/location1/incentive/atmospheric_data_incentive/air_mach?param=5。

設置完成后，可以看到對應設備指令的返回值。由于現有資源可以直接獲得，所以，可以直接顯示所請求資源的值，比如設置馬赫數，返回了響應的實際值0.4。在URI中192.168.0.101：8081為多源異構數據集成服務所在計算機的IP與端口。

由此可見，整個試驗平臺的數據交換暢通，每一層都按照設計進行了數據處理，對于那些現有資源，請求資源后將資源按照JSON形式封裝后即可直接獲得。試驗結果中的響應也滿足這一要求，現有資源請求功能符合預期。

2.2 邏輯資源請求

每個現有資源存在于單一設備中，設備數據視圖層在解析后調用相應的應用層URI獲得其響應即可，但是對于邏輯資源來說就需要返回所有鏈接的資源。在完成對現有資源請求的驗證后，驗證設備數據視圖層的邏輯資源請求功能。與現有資源不同，邏輯資源由多個現有資源鏈接而成。以測試設備可用狀態資源請求為例，如圖 8所示。

程序根據REST風格進行URI設計，并使用GET方式發送HTTP請求，該URI指向的是邏輯資源，所以，返回值應當是當前所有設備的可用狀態：http：//192.168.0.101：8081/device/all/all/all/status。

從圖8中可知，3種設備都處于可用狀態。僅接入了激勵數據源，連接的設備有大氣數據激勵設備、無線電高度表激勵器和單軸速率轉臺。因此，返回的數據中僅有3種設備的上電狀態，符合試驗給出的條件，邏輯資源請求符合預期。

經過對現有資源和邏輯資源的請求試驗，驗證了本文采用多源異構數據集成服務實現總裝階段飛控數字化測試中不同測試設備的多源異構數據集成的方法，使得總裝階段飛控數字化測試中可以方便地使用統一接口進行設備數據的操作。

圖7 大氣數據激勵設備資源測試頁面Fig.7 Atmospheric data incentive equipment resource test page

圖8 設備資源測試頁面Fig.8 Device resource test page

結論

本文面向飛機自動測試需求，針對現有總裝階段飛控系統測試設備所存在的多源異構數據集成問題，在對現有設備的研究和測試流程總結歸納的基礎上，構建了總裝階段飛控數字化測試中的多源異構數據集成試驗平臺，設計了基于REST架構的多源異構數據集成服務，并最終通過對大氣數據激勵設備、單軸速率轉臺和無線電高度表激勵器的數據集成服務設計，驗證了本文所提出的基于REST架構的總裝階段飛控數字化測試中多源異構數據集成方法的有效性。