陸嵐 孫勇 何熊文 余晟

(北京空間飛行器總體設(shè)計部,北京 100094)

隨著航天器交會對接[1-2]等各類復(fù)雜空間任務(wù)的出現(xiàn)和發(fā)展,使得航天器之間和航天器內(nèi)部各設(shè)備之間都需進行更緊密的指令交互和協(xié)同控制。設(shè)備管理指令是大型航天器組合體內(nèi)任意設(shè)備主動發(fā)往艙內(nèi)或艙間其他設(shè)備的指令,往往需要進行一次或多次轉(zhuǎn)發(fā),每次轉(zhuǎn)發(fā)都需在指令管理設(shè)備控制下進行較為復(fù)雜的交互過程。相對于以往常見的程控指令轉(zhuǎn)發(fā),設(shè)備管理指令的轉(zhuǎn)發(fā)步驟更多,相應(yīng)的轉(zhuǎn)發(fā)時延更大。以往通用的程控指令轉(zhuǎn)發(fā)方法已經(jīng)不能滿足大型航天器設(shè)備之間指令交互的實時性要求。目前國內(nèi)航天領(lǐng)域針對1553B 總線[3-6]消息的實時調(diào)度方法已經(jīng)有了一定的成果[7-9],但還缺乏針對指令轉(zhuǎn)發(fā)全過程的分層優(yōu)化策略研究。

基于上述現(xiàn)狀,本文提出了一種設(shè)備管理指令的實時性優(yōu)化方法,在數(shù)據(jù)鏈路層[10]采用解析流程和總線反饋過程優(yōu)化,在物理層[11]進行總線消息發(fā)送序列優(yōu)化,可有效縮減設(shè)備管理指令各轉(zhuǎn)發(fā)步驟的時間延遲,并可兼容原有的硬件設(shè)計和軟件框架。

1 指令交互需求分析

大型航天器長期在軌運行期間,由于測控區(qū)限制,地面不能隨時監(jiān)測航天器組合體各艙段狀態(tài),使得在軌自主管理成為其必備的關(guān)鍵功能。由于資源互備和共享需求,各艙段間熱控、能源等重要設(shè)備的功能關(guān)聯(lián)緊密,使得航天器自主管理過程中指令交互過程成為重中之重。其中艙段間指令交互傳輸往往需經(jīng)過多次轉(zhuǎn)發(fā),對整個傳輸途徑的時延控制成為研究重點。圖1給出了在三艙指令管理設(shè)備控制下的艙間指令交互過程模型。圖中艙段1的發(fā)令設(shè)備在進行自主故障診斷后,向艙段3的某執(zhí)行機構(gòu)發(fā)出設(shè)備管理指令。該指令經(jīng)過三艙指令管理設(shè)備的三次轉(zhuǎn)發(fā)后到達終端的執(zhí)行機構(gòu)執(zhí)行,其傳輸延遲主要包括三次轉(zhuǎn)發(fā)的時延T1～T3,以及執(zhí)行機構(gòu)從接收到執(zhí)行的時延T4。三次轉(zhuǎn)發(fā)最大時延占比約為1∶1∶1,而T4的時延一般小于200 ms。大型航天器自主管理設(shè)計中多項緊急重大故障都需進行艙間設(shè)備管理指令傳輸。為進行在軌緊急故障處置和故障隔離,指令在整個傳輸途徑中的延遲不應(yīng)大于1 s。因此設(shè)備管理指令的每次轉(zhuǎn)發(fā)最大時延不應(yīng)大于266 ms。如果不進行優(yōu)化設(shè)計,以往通用的程控指令轉(zhuǎn)發(fā)方法最大延遲一般在350 ms以上,已經(jīng)不能滿足大型航天器指令交互的實時性要求。因此有必要對每次設(shè)備管理指令的轉(zhuǎn)發(fā)進行步驟分析和優(yōu)化設(shè)計,以滿足大型航天器復(fù)雜和緊急的自主管理需求。

圖1 艙間指令交互模型Fig.1 Inter-cabin command interaction model

設(shè)備管理指令格式定義與遙控空間數(shù)據(jù)鏈路協(xié)議[12-13]一致:包含主導(dǎo)頭、幀數(shù)據(jù)域和幀差錯控制域,格式如圖2所示。幀數(shù)據(jù)域又包含了一個程控指令源包,該源包由包主導(dǎo)頭、副導(dǎo)頭、應(yīng)用數(shù)據(jù)和包差錯控制域組成。傳送幀主導(dǎo)頭中包含航天器標(biāo)識(SCID)和虛擬信道(VCID)標(biāo)識。航天器標(biāo)識是用于區(qū)分不同航天器的唯一標(biāo)識;虛擬信道標(biāo)識則用于區(qū)分同一航天器上的不同設(shè)備。設(shè)備管理指令幀長固定為22 byte,即一個指令源包加上幀主導(dǎo)頭長度,以減少總線額外開銷,提高系統(tǒng)資源利用率。

圖2 設(shè)備管理指令格式Fig.2 Format of device management command

2 時序分析和優(yōu)化方法

2.1 轉(zhuǎn)發(fā)步驟和時序

設(shè)備管理指令轉(zhuǎn)發(fā)是在指令管理設(shè)備的控制下,從發(fā)送方設(shè)備獲取指令并轉(zhuǎn)發(fā)到接收方設(shè)備的過程。發(fā)送方設(shè)備準(zhǔn)備好指令后,在總線上設(shè)置服務(wù)請求;指令管理設(shè)備以固定周期發(fā)出讀取服務(wù)請求消息,并對返回的消息狀態(tài)進行判斷,如發(fā)現(xiàn)有服務(wù)請求,則發(fā)出讀取設(shè)備管理指令的消息。在接收到設(shè)備管理指令后,對指令進行校驗和轉(zhuǎn)發(fā);最后接收方接收指令。這是一次設(shè)備管理指令轉(zhuǎn)發(fā)的完整流程,圖3展示了轉(zhuǎn)發(fā)流程的步驟和時序。其中t1～t5為管理方在指令轉(zhuǎn)發(fā)流程中各主要步驟的時延。t6為從管理方發(fā)出指令到接收方收到指令的時延。

圖3 設(shè)備管理指令轉(zhuǎn)發(fā)流程Fig.3 Device management command forwarding process

將從發(fā)送方設(shè)置完服務(wù)請求到接收方收到指令的時間延遲記為tc,管理方的每個處理環(huán)節(jié)的平均運行時間記為to,可得tc＝5to＋

其中to大小由管理方設(shè)備硬件性能決定,在硬件環(huán)境不變的前提下取值固定;t1的最大值由管理方發(fā)出服務(wù)請求的間隔決定,該間隔可作為參數(shù)由軟件自行設(shè)置;而t6接收方軟硬設(shè)計決定,不屬于指令管理范疇。因此要縮減tc的時間延遲首先需考慮對t2～t5的處理時間進行優(yōu)化,也就是使得取值最小。

2.2 解析流程優(yōu)化

傳送幀格式的指令解析和轉(zhuǎn)發(fā)流程通常如圖4(a)所示,對接收到的傳送幀首先進行幀校驗,如格式正確首先進行幀解析,將具備不同SCID 或VCID 的幀存入相應(yīng)的緩沖區(qū);再對其中需進一步處理的包取出進行包校驗,正確后再進行包解析、處理和轉(zhuǎn)發(fā);最后對所有緩存中的幀一一進行判別、處理和轉(zhuǎn)發(fā)。這種方式可用于大多數(shù)實時性要求較弱的遙控注入數(shù)據(jù)和指令,但不能適應(yīng)強實時性的設(shè)備管理指令轉(zhuǎn)發(fā)要求。因此考慮優(yōu)化解析流程,在幀校驗正確后增加針對設(shè)備管理指令的判別,如為需要進行總線轉(zhuǎn)發(fā)的設(shè)備管理指令,則跳過后續(xù)幀解析和包解析環(huán)節(jié),直接進行幀處理和轉(zhuǎn)發(fā),如圖4(b)所示。該優(yōu)化措施可避免不必要的大量幀、包復(fù)制過程和模塊調(diào)用操作,縮減前文描述的t4(發(fā)出讀取設(shè)備管理指令消息到接收和處理指令)時間間隔。

圖4 解析流程優(yōu)化方法Fig.4 Analysis process optimization method

2.3 總線消息反饋過程優(yōu)化

如圖5(a)所示,指令管理方由總線進程發(fā)出讀取服務(wù)請求消息后,與其他所有類型的總線返回消息一同處置,先讀取消息并存入緩存,再將消息數(shù)據(jù)通過進程間消息傳遞方式發(fā)送到相關(guān)處理進程去處理。相關(guān)處理進程在處理后還需發(fā)出讀取設(shè)備管理指令消息,再通過消息傳遞機制發(fā)到總線進程,由總線進程再將消息發(fā)出。

考慮到兩次進程間消息傳遞的時間開銷較大,為提高實時處理能力,設(shè)計了一種鉤子函數(shù)注冊機制。由相關(guān)進程在初始化時,在共享數(shù)據(jù)區(qū)注冊專用的鉤子函數(shù),用于解析、處理并發(fā)出讀取設(shè)備管理指令的消息,如圖5(b)所示。總線進程在收到總線上返回的消息后,判斷消息類型為讀取服務(wù)請求消息,則調(diào)用注冊的鉤子函數(shù)進行處理。這種方式可避免兩次緩沖區(qū)拷貝和兩次進程調(diào)度的時間開銷,有效縮小前文描述的t2(從發(fā)出讀取服務(wù)請求消息到進行消息判斷)時間間隔。

圖5 總線消息反饋過程優(yōu)化方法Fig.5 Optimization method of bus message feedback process

2.4 總線消息發(fā)送序列優(yōu)化

完整的設(shè)備管理指令發(fā)送周期里,需要發(fā)出三種總線消息:讀取服務(wù)請求消息、讀取設(shè)備管理指令消息和轉(zhuǎn)發(fā)指令消息。傳統(tǒng)方式下,總線消息最終都要通過總線進程發(fā)送出去。本文設(shè)計的物理層優(yōu)化方法是設(shè)置不同的總線消息優(yōu)先級:將讀取服務(wù)請求消息設(shè)為優(yōu)先級3;讀取設(shè)備管理指令消息和轉(zhuǎn)發(fā)指令消息設(shè)為優(yōu)先級1。如圖6所示,總線發(fā)送進程調(diào)度后,優(yōu)先級2和優(yōu)先級3的隊列會放在當(dāng)前發(fā)送隊列的后面發(fā)送出去;而優(yōu)先級1的消息可通過相關(guān)發(fā)送進程直接打斷當(dāng)前隊列的消息,將優(yōu)先級1的消息最先發(fā)送出去。當(dāng)優(yōu)先級1的消息發(fā)送完畢后,再依序?qū)?dāng)前發(fā)送隊列、優(yōu)先級2隊列和優(yōu)先級3隊列發(fā)送出去。這種方式避免大量低優(yōu)先級的消息占用總線,可大幅縮小前文描述的t3和t5(物理層消息發(fā)送)的時間間隔。

圖6 總線物理層優(yōu)化發(fā)送序列Fig.6 Optimized sending sequence of bus physical layer

3 驗證和分析

本文提出的指令管理優(yōu)化方法已應(yīng)用于某大型航天器組合體的指令管理設(shè)備。測試系統(tǒng)由組合體某艙段上指令管理設(shè)備的真實軟硬件和地面軟件構(gòu)成,該軟件已采用文中所述優(yōu)化方法。通過地面軟件仿真某艙段1553B的指令發(fā)送方和接收方,模擬總線上設(shè)備管理指令的發(fā)送和接收。測試時設(shè)置指令管理設(shè)備發(fā)送服務(wù)請求的間隔為80 ms,隨機選擇不同的總線終端進行多次指令發(fā)送和接收,以地面軟件記錄從發(fā)送方服務(wù)請求設(shè)置到管理方指令轉(zhuǎn)發(fā)消息發(fā)出的時間間隔為10～88 ms。即tc的最大值為88 ms,根據(jù)前文分析可知通過優(yōu)化,5to＋的最大時間間隔為8 ms。對指令管理設(shè)備的軟件進行修改,不采取任何優(yōu)化的情況下,tc值實測為43～252 ms。即未優(yōu)化的情況下5to＋的最大時間間隔為172 ms?？梢娊?jīng)過優(yōu)化,設(shè)備管理指令轉(zhuǎn)發(fā)最大時延tc縮短了65%。

再對指令管理設(shè)備發(fā)送服務(wù)請求的間隔進行調(diào)整,分別設(shè)為20 ms和200 ms,實測優(yōu)化后tc值為12～88 ms和13～208 ms?？梢妰?yōu)化后5to＋的最大時間間隔穩(wěn)定為8 ms,優(yōu)化效果與服務(wù)請求間隔的大小無關(guān)。

在指令管理設(shè)備軟件中設(shè)置優(yōu)化開關(guān),對3種優(yōu)化方法分別測試其優(yōu)化效果:單獨使用解析流程優(yōu)化,優(yōu)化后tc值縮短了2～5 ms;單獨使用總線消息反饋過程優(yōu)化,使得tc值縮短了13～56 ms;單獨使用總線消息發(fā)送序列優(yōu)化,使得tc值縮短了21～107 ms。可見3種優(yōu)化方法的最大優(yōu)化效率占比約為1∶11∶21。

4 優(yōu)化方法應(yīng)用

4.1 優(yōu)勢分析

本文提出的設(shè)備間指令管理優(yōu)化方法相對于優(yōu)化前主要優(yōu)勢如下。

(1)解析流程優(yōu)化前,設(shè)備管理指令解析過程由于通用設(shè)計,必須執(zhí)行幀解析、包解析環(huán)節(jié)。優(yōu)化后這些不必要環(huán)節(jié)省略,減少了處理時間。

(2)總線消息反饋過程優(yōu)化前,發(fā)出讀取服務(wù)請求消息到進行消息判斷過程中需進行兩次消息傳遞和兩次進程調(diào)度。優(yōu)化后這些時間開銷可省略。

(3)總線消息發(fā)送序列優(yōu)化前,非重要的總線數(shù)據(jù)可能長時間占用總線,使得重要的指令消息不能及時發(fā)送。優(yōu)化后通過高優(yōu)先級消息搶占調(diào)度,可有效縮減該時間延遲。

4.2 應(yīng)用擴展思路

本文中所述方法可推廣應(yīng)用至其他高實時性需求任務(wù)的軟件優(yōu)化設(shè)計中,可供后續(xù)借鑒和參考的設(shè)計思路如下。

(1)多層次多環(huán)節(jié)優(yōu)化:在對需優(yōu)化的高實時需求任務(wù)的執(zhí)行環(huán)節(jié)及軟件實現(xiàn)層次進行全面分析并選取優(yōu)化策略,爭取各環(huán)節(jié)、各層次的處理時延都進行優(yōu)化,以獲得最佳優(yōu)化效果。

(2)應(yīng)用層優(yōu)化從應(yīng)用軟件和操作系統(tǒng)調(diào)度兩方面入手:應(yīng)用軟件中對高實時需求任務(wù)的進程進行針對性流程優(yōu)化;同時跟據(jù)操作系統(tǒng)調(diào)度策略,分析高實時需求任務(wù)的相關(guān)進程執(zhí)行時序,將不必要的進程切換和進程間消息傳遞作為優(yōu)化目標(biāo)。

(3)面向總線接口的物理層優(yōu)化基于總線調(diào)度策略展開,分析不同總線消息的傳輸實時性需求,選擇合適的總線消息調(diào)度策略以兼顧高、中、低實時性的總線消息傳輸需求。

5 結(jié)束語

本文描述了設(shè)備管理指令的轉(zhuǎn)發(fā)步驟和時序,對指令轉(zhuǎn)發(fā)時延產(chǎn)生的各個環(huán)節(jié)進行了分析,并針對每個環(huán)節(jié)給出了相應(yīng)的減少時延、提高指令轉(zhuǎn)發(fā)實時性的技術(shù)措施。最后給出了針對其他高實時需求任務(wù)的推廣應(yīng)用建議。大型航天器組合體的設(shè)備管理指令可能需要一次或多次轉(zhuǎn)發(fā)。本文所研究的指令轉(zhuǎn)發(fā)周期產(chǎn)生的時延只是一次轉(zhuǎn)發(fā)的主要時延,最終多次轉(zhuǎn)發(fā)的時間延遲還與艙間對接總線的網(wǎng)絡(luò)拓撲設(shè)計有關(guān)。但每次轉(zhuǎn)發(fā)過程都可參考文中方法進行優(yōu)化,以達到最優(yōu)的實時傳輸效果。

文中所述優(yōu)化方法在提高指令轉(zhuǎn)發(fā)實時性的同時,也會帶來一定可靠性風(fēng)險?？偩€消息發(fā)送序列優(yōu)化方法采用高優(yōu)先級搶占的總線調(diào)度策略,不同優(yōu)先級進程搶占總線資源可能導(dǎo)致訪問沖突,使得總線消息內(nèi)容錯誤或消息發(fā)送失敗。實際應(yīng)用中可通過信號量對共享的總線資源和發(fā)送緩沖區(qū)進行保護,實現(xiàn)不同進程訪問的互斥,以避免訪問沖突。文中所述優(yōu)化方法已在某大型航天器不同艙段的指令管理設(shè)備軟件中應(yīng)用,并已通過長期綜合電測驗證了其可靠性和優(yōu)化效果。