一種基于RPC的組態(tài)化衛(wèi)星模擬器故障注入方法*

楊善強，李華旺，常亮，高才棟，虞業(yè)濼

(1 中國科學院微小衛(wèi)星創(chuàng)新研究院， 上海 201210； 2 中國科學院大學， 北京 100049； 3 上?？萍即髮W， 上海 201210)(2019年8月9日收稿； 2019年12月4日收修改稿)

衛(wèi)星長時間運行在復雜、惡劣的太空環(huán)境中，不可避免地會出現(xiàn)故障，有的故障會對衛(wèi)星的壽命和應用造成影響[1-2]。故障注入能夠有效檢驗系統(tǒng)的容錯能力，已經(jīng)在軟件測試領域得到廣泛應用。故障注入的基本思想是：應用和環(huán)境共同組成系統(tǒng)，環(huán)境的范圍包含所有不屬于應用程序的代碼，應用和環(huán)境交互的接口處是故障的注入點，通過在故障注入點上模擬實現(xiàn)各類在真實環(huán)境中可能出現(xiàn)的故障，觀察被測對象的反應，從而檢驗其對故障的耐受能力[3-4]。

目前對故障注入不同角度和深度的研究已有很多成果，其實現(xiàn)方法和應用場景各不相同：

1)為提高模擬程度，建立基于半物理的實時仿真平臺，實現(xiàn)不同層次不同類型故障的單獨注入，更加真實地得到故障信息。然而半實物仿真測試環(huán)境需要開發(fā)硬件設備，搭建硬件連接，測試的及時性和靈活性得不到保證[5]。

2)為精確有效地實現(xiàn)故障注入，通過在源碼中添加故障注入代碼，在有故障注入請求時就進入相應分支進行故障注入。然而故障注入工具的開放性欠好，很難在此基礎上進行再開發(fā)和擴展[6]。

3)為注入任意位置任意類型的故障，提高仿真平臺的通用性，根據(jù)系統(tǒng)配置信息構建存儲所有可能的通信鏈路節(jié)點的故障庫，通過多元組或文本模型實現(xiàn)對任意位置任意時間的故障注入。但該方法只實現(xiàn)了目標系統(tǒng)鏈路的離散故障，缺少對連續(xù)故障的注入[7]。

以上方法與目標研究系統(tǒng)有較強的關聯(lián)性，但在面對新的目標系統(tǒng)時故障注入模型的復用程度低[8-11]。本文從提高故障仿真模型的可復用性角度，就衛(wèi)星系統(tǒng)的仿真測試提出一種基于RPC(remote procedure call，遠程過程調用)的組態(tài)化模擬器故障注入方法，設計一個內含故障注入的通用衛(wèi)星單機模型，可以通過通用衛(wèi)星單機模型的組態(tài)化實現(xiàn)不同的衛(wèi)星單機，同時在配置衛(wèi)星單機模型時不必考慮故障注入。進一步地，該通用單機適用于不同型號的衛(wèi)星單機，有效縮短衛(wèi)星仿真建模的周期。

1 故障注入模型設計

1.1 故障注入模型結構

故障注入模型根據(jù)功能需要由通用單機模型、故障協(xié)議與故障注入前端3部分組成。故障注入前端負責獲取用戶輸入的故障信息和顯示衛(wèi)星的信息，并且通過RPC調用模擬器的功能函數(shù)來封裝、組幀故障信息。通過模型拆分，各模塊之間通過接口實現(xiàn)，可以有效地增加整個模型的可維護性和復用性。模型體系結構如圖1所示。

圖1 故障注入模型結構圖Fig.1 Structure chart of fault injection model

1)故障注入是故障注入前端將故障信息傳遞給衛(wèi)星模擬器，然后獲取衛(wèi)星模擬器對故障信息處理的返回值的過程。為提高故障注入模型的復用性，使之適用于不同型號的單機，設計一種通用單機模型。在通用單機模型中提供模型接口，當為某型號衛(wèi)星建模時可以直接調用相應接口配置為實際的單機模型(如星敏感器、飛輪等)。

2)為提高故障注入模型的可維護性、可擴展性和代碼的易讀性，將添加故障信息過程抽象為RPC。使用RPC通信能夠使故障注入前端就像進行本地調用一樣去調用模擬器的相應函數(shù)來處理打包故障信息。

3)同時設計故障注入?yún)f(xié)議用以對故障前端輸出與接收故障信息進行控制，其規(guī)定了故障信息的封裝方式以及故障注入前端與衛(wèi)星模擬器之間通信鏈路的數(shù)據(jù)格式，是溝通故障注入前端與模擬器的橋梁。

1.2 通用單機模型設計

由于任何數(shù)據(jù)以及數(shù)據(jù)交互過程均可抽象為某種數(shù)據(jù)交互模型，在仿真環(huán)境中把數(shù)據(jù)交互模型稱為數(shù)據(jù)流模型[12]?；诖?，設計一個如圖2所示的通用數(shù)據(jù)流單機模型框架，將單機的參數(shù)與數(shù)據(jù)打包動作進行分離，通過參數(shù)庫、數(shù)據(jù)打包、邏輯控制3個功能模塊描述該通用單機模型。功能模塊之間通過接口進行信息交互，單機參數(shù)、數(shù)據(jù)打包以及邏輯動作都是由用戶定義，同時故障注入在框架內部完成。

圖2 通用單機模型結構圖Fig.2 General model structure diagram

為提高單機模型的復用性，對通用單機模型的內部模塊做如下約定：

1)參數(shù)庫中使用三元組(標識符、數(shù)據(jù)、數(shù)據(jù)鎖)定義單機的參數(shù)屬性，分別表示該單機收到的指令或遙測數(shù)據(jù)的身份標識、該參數(shù)值和該值是否可以被修改，若此時值由于故障被鎖定，則動力學數(shù)據(jù)無法寫入?yún)?shù)庫。

2)數(shù)據(jù)打包模塊從參數(shù)庫中提取數(shù)據(jù)，進行打包封裝、校驗，并且當有故障激發(fā)，在打包時進行故障注入。

3)邏輯模塊讀取和更新參數(shù)庫的內容，同時決定數(shù)據(jù)包封裝和發(fā)送的時機，還規(guī)定了發(fā)送次數(shù)。外部可以調用邏輯模塊的外部接口。

單機通用模型的3個模塊都提供外部接口函數(shù)，在搭建具體單機仿真模型時，只需調用相應的接口函數(shù)來創(chuàng)建自己的參數(shù)庫、數(shù)據(jù)更新函數(shù)、數(shù)據(jù)發(fā)送函數(shù)即可快速完成單機建模。

1.3 故障協(xié)議設計

設計一組故障協(xié)議規(guī)定模擬器對故障注入前端的故障信息的打包封裝格式。并將通用故障協(xié)議分為3層：鏈路層、任務數(shù)據(jù)層、業(yè)務控制層,如圖3所示。

圖3 故障協(xié)議層次圖Fig.3 Fault agreement hierarchy

1)鏈路層協(xié)議

鏈路層是整個故障協(xié)議的最底層，所有的上層模塊都依賴于鏈路層，其不關心實際的遠程調用邏輯，僅負責信息的收發(fā)和編解碼，同時為上層模塊提供與業(yè)務無關的基礎服務。

在鏈路層，數(shù)據(jù)是以通信幀的形式在衛(wèi)星單機各模塊間流動的，各種數(shù)據(jù)從產(chǎn)生節(jié)點到目的節(jié)點需要指定一個傳輸鏈路，并且需要規(guī)定好通信幀的格式，本文設計的通信幀格式如表1所示。此處，衛(wèi)星模擬器與故障注入前端之間通過TCP(transmission control protocol，傳輸控制協(xié)議)進行通信。

表1 通信幀格式描述Table 1 Description of communication frame format

2)任務數(shù)據(jù)層協(xié)議

任務數(shù)據(jù)層主要記錄故障注入的數(shù)據(jù)信息，同時對不同的故障信息設計不同的數(shù)據(jù)格式封裝處理，這里設計6種(協(xié)議類、單機參數(shù)類、動力學數(shù)據(jù)類、仿真控制類、指令注入類、外設類)數(shù)據(jù)格式應對不同類型的故障信息。

這6種數(shù)據(jù)格式均分為有效載荷區(qū)和數(shù)據(jù)區(qū)兩部分，有效載荷存放的是需要調用的數(shù)據(jù)交互方法和同類故障數(shù)據(jù)的組數(shù)計數(shù)器，數(shù)據(jù)區(qū)為故障前端輸入的故障數(shù)據(jù)。對不同的故障信息，數(shù)據(jù)區(qū)內部的數(shù)據(jù)結構不同，如圖4所示。

圖4 任務數(shù)據(jù)層數(shù)據(jù)格式Fig.4 Data format of task data layer

3)業(yè)務控制層協(xié)議

業(yè)務控制層定義一組數(shù)據(jù)業(yè)務，又稱為數(shù)據(jù)交互方法，衛(wèi)星模擬器通過調用不同的業(yè)務來處理故障注入前端傳來的故障信息，即將故障信息注入到衛(wèi)星仿真模型中。

由于衛(wèi)星中數(shù)據(jù)交互的任意接口位置都有可能發(fā)生故障，因此在本文中將所有的數(shù)據(jù)交互方法統(tǒng)稱為原子故障。原子故障是衛(wèi)星模擬器的最底層故障，通過原子故障可以組合共同作用實現(xiàn)更加復雜的故障，根據(jù)衛(wèi)星模擬器故障注入的需要，設計表2所示的28種原子故障實現(xiàn)衛(wèi)星模擬器的故障。

1.4 基于RPC的通信機制

為了提供未來進一步擴展和維護的可能性[13]，使用RPC完成對故障注入前端故障信息的封裝。RPC是一種基于客戶/服務模式的函數(shù)調用過程，它將一個服務的請求和執(zhí)行分別存放在客戶端和服務器之中，其本質是在客戶端要求遠程服務端運行某項服務并獲取其結果的過程，如圖5所示。它是一種進程間的通信機制，一般承擔系統(tǒng)協(xié)調與數(shù)據(jù)交互的責任，并未規(guī)定具體的實現(xiàn)方式、平臺和語言[14-15]。

表2 原子故障類型表Table 2 Atomic fault types

圖5 調用包在遠程過程調用中的傳輸Fig.5 Transmission of the call package during a RPC

通過使用RPC的通信機制，可以將故障信息的封裝與故障注入前端分離，這樣故障注入前端只需要負責捕獲用戶輸入的故障信息以及顯示功能，易于擴展新的故障。

這里將故障注入前端設定為客戶端，衛(wèi)星模擬器為服務端，提供客戶端需要的故障信息打包封裝函數(shù)。通過RPC封裝故障前端的故障信息的過程為：當使用者在故障注入前端添加故障信息后,客戶端將目標程序的規(guī)范和相關參數(shù)放置在調用信息包中，并請求RPC網(wǎng)絡鏈路將調用包發(fā)送給被調用者，即服務端。一旦服務端接收到這些信息包，服務端會將它們解包獲取任務數(shù)據(jù)，然后根據(jù)任務數(shù)據(jù)中有效載荷標識的業(yè)務方法去執(zhí)行一個完全正常的本地調用，該本地調用會調用服務端中相對應的程序去處理任務數(shù)據(jù)中的數(shù)據(jù)。與此同時，服務端的調用進程將被掛起并等待結果包的返回。當服務端中的調用完成時，它將結果包發(fā)送給客戶端，然后結果包傳送回給客戶端被掛起的進程，它們將被解包并返回客戶端的初始調用函數(shù)。

1.5 故障注入流程

基于上述設計模塊，故障注入實現(xiàn)流程如圖6所示。

圖6 故障注入流程Fig.6 Flow chart of simulating faults of satellite

1)在故障注入前端的界面上給目標單機添加故障信息后，通過RPC調用數(shù)據(jù)交互方法將故障信息、故障單機信息添加到通信幀中，然后發(fā)送給模擬器。

2)模擬器接受到通信幀后，分析通信幀的目的地(即目標單機)，向目標單機發(fā)送故障數(shù)據(jù)，而單機接收到數(shù)據(jù)后，在更新或打包單機數(shù)據(jù)時根據(jù)故障類型將故障信息封裝到單機數(shù)據(jù)中。

3)之后模擬器再將單機數(shù)據(jù)按照表1所示格式組幀，然后發(fā)送給故障注入前端，故障注入前端再將收到的通信幀解幀并且通過界面顯示。

2 實踐驗證

2.1 組態(tài)化實現(xiàn)星敏感器

通過前文設計的衛(wèi)星通用單機模型能夠組態(tài)實現(xiàn)不同型號的單機模型，由于篇幅有限，本文僅以某型號的星敏感器為例講述使用通用單機模型組態(tài)化為實際單機的過程，不同型號、不同單機只是它們的參數(shù)庫、遙測控包和觸發(fā)事件的邏輯不同，其他并無不同?；谏鲜鐾ㄓ脝螜C模型實現(xiàn)單機模型的過程是向通用單機模型框架注冊參數(shù)、數(shù)據(jù)包、邏輯，同時定義單機接口的過程。圖7所示為組態(tài)實現(xiàn)的該型號星敏感器結構圖。

圖7 星敏感器結構圖Fig.7 Star sensor structure diagram

基于通用單機模型實現(xiàn)星敏感器的過程為：

1)搭建星敏感器參數(shù)庫：輸入星敏感器的所有參數(shù)，并給這些參數(shù)賦初值。

2)構建星敏感器打包模塊：首先設置該星敏感器的參數(shù)包列表；然后給出各參數(shù)包的組成元素，即每個參數(shù)包由參數(shù)庫中的哪些元素組成，以及將這些參數(shù)打包的動作；最后設置對遙控指令幀的解幀、提取指令值的動作。

3)注冊星敏感器邏輯模塊：設置單機參數(shù)更新的時機、連接指令與打包動作、連接指令與參數(shù)包發(fā)送動作。

基于此方法實現(xiàn)星敏感器的花費資源如表3所示。

表3 新舊方法花費資源對比Table 3Resource cost comparison of new and old methods

2.2 故障注入過程示例

表2描述的原子故障是最基本的故障，通過多個原子故障組合能夠實現(xiàn)任意位置、任意組合的故障注入，表4列舉了一些常見的故障類型。

表4 故障示例Table 4 The fault samples

以2.1節(jié)組態(tài)實現(xiàn)的星敏感器為例，進行故障注入仿真過程演示，該型號有3個星敏感器，分別以A、B、C命名，除此之外并無差別，這里選取星敏感器A進行展示。

1)注入單機參數(shù)故障

圖8展示對星敏感器A注入單機參數(shù)故障前后的參數(shù)值變化，此處注入故障的參數(shù)為星敏四元素Q1。

圖8 對星敏感器注入?yún)?shù)故障的過程Fig.8 The process of injecting a parameter fault into a star sensor

在正常仿真狀態(tài)下，星敏A的星敏四元素數(shù)值變化范圍為(-1,1)，如圖8(a)所示；接下來模擬星敏四元素Q1未能正常更新的故障，在給星敏四元素Q1注入?yún)?shù)故障1000并鎖死后，觀察到Q1的值固定在1000而不再更新。當星務軟件檢測到星敏A發(fā)生了故障，根據(jù)內部算法放棄星敏A采集到的數(shù)據(jù)，改用星敏B的數(shù)據(jù)。由此判定星務軟件對星敏故障的應對措施有效。

2)注入遙測幀故障

圖9展示對星敏感器A遙測姿態(tài)包的第3、4個字節(jié)中的某些位注入故障前后姿態(tài)包信息的變化。

圖9 對星敏感器注入遙測故障的過程Fig.9 The process of injecting a telemetry fault into a star sensor

對星敏感器A發(fā)送的遙測姿態(tài)包按位進行故障注入，遙測幀故障注入格式為(幀位置、掩碼、故障值)，遙測幀故障按照下式規(guī)則進行注入。

Value=f(value,mask,fault)

=(fault&mask)|(value&～mask),

(1)

式中：value為遙測幀原值；mask為掩碼值，按位屏蔽輸入的故障值,若該位為1則屏蔽故障，為0則允許該位注入故障；fault為注入的故障值；Value為故障注入后值。

通過對姿態(tài)包第3、4字節(jié)的數(shù)值(16進制表示)按照上述規(guī)則進行計算，計算結果如圖10所示，與圖9展示的故障注入后的數(shù)據(jù)是匹配的，說明遙測故障注入有效。

圖10 數(shù)值計算結果Fig.10 Numerical calculation result

2.3 新方法使用前后對比

在設計使用本故障注入模型之前，對某通信衛(wèi)星建立仿真模型以及故障注入模型時，該通信衛(wèi)星的陀螺、反作用輪、推力器、星敏、太敏等不同單機的故障源、故障類型都不相同，某一單機的不同故障也需要單獨處理，導致該型號的仿真模型代碼冗余，一般需要一個月的時間才能完成衛(wèi)星仿真模擬器的搭建和調試。

而使用基于RPC的故障注入模型，只需調用通用單機模型的接口組態(tài)化為不同型號的不同單機模型，該方法已應用于對SVOM、某通信衛(wèi)星、某遙感衛(wèi)星的仿真建模中，為這些型號搭建仿真模擬器分別使用了兩周左右時間，為這些型號的方案設計驗證、星務代碼的測試提供了支持。

同時，使用基于RPC的故障注入方法具有故障類型豐富的特點，支持如數(shù)據(jù)風暴：同一時間點內發(fā)送大量有效數(shù)據(jù)；中斷沖突：星務軟件觸發(fā)假中斷或中斷嵌套。

使用新舊方法參數(shù)對比如表5所示。

表5 新舊方法對比Table 5 Comparison of parameters of old and new methods

3 結束語

本文設計一種基于RPC的組態(tài)化模擬器標準故障注入方法，通過對衛(wèi)星單機建立通用仿真模型，對衛(wèi)星系統(tǒng)進行故障注入。該衛(wèi)星仿真模型實現(xiàn)的功能如下：

1)虛擬化構建衛(wèi)星的硬件環(huán)境和外部數(shù)據(jù)源，等效模擬實際衛(wèi)星的運轉狀況。

2)在沒有故障注入時，故障注入前端向模擬器發(fā)送獲取數(shù)據(jù)的請求，模擬器將由動力學更新的單機數(shù)據(jù)組包發(fā)送給故障注入前端，故障注入前端將通信幀解幀獲得各單機參數(shù)并顯示在界面上。

3)在有故障信息注入時，故障注入前端通過RPC調用模擬器端的數(shù)據(jù)交互方法將故障信息組幀打包發(fā)送給模擬器端，模擬器解包通信幀獲得故障信息，在單機數(shù)據(jù)更新和打包時將故障信息注入，然后向故障注入前端發(fā)送已被故障注入的該單機數(shù)據(jù)包。

本方法投入實踐使用后，能夠有效縮短衛(wèi)星仿真模型開發(fā)周期，對型號的仿真建模從原來的一個月縮短到兩周時間。在以后的研究工作中，應繼續(xù)提煉形成更加標準化的通用模型，使得可以通過配置文本的方式建立衛(wèi)星仿真模型，進一步提高模型組態(tài)化、復用性的程度；另一方面可以從動力學模型、能源熱控模型等角度入手，提高模型的仿真精度。