基于軟硬件協同設計的航天控制系統綜合技術

宋征宇

北京航天自動控制研究所，北京 100854

1 概述

系統綜合技術作為傳統航天控制領域一項重要的技術，已經有較長的歷史了。它的出現，是隨著航天器設計的日益復雜化以及分工的日益專業化而產生的。對一項簡單的設計，一個工程組能夠完成從方案論證到產品實現的全過程，但航天器的設計愈發復雜，以控制系統為例，至少包括系統設計和產品設計兩大類。在系統設計中，不僅包括控制算法(方案)的設計、電氣系統的設計，由于火箭是用于發射服務的，其使用性必須考慮，因此還包括測試發射控制功能的設計。而產品設計包括硬件產品設計(電路設計、結構設計)、軟件產品設計(應用軟件設計、操作系統設計)等。因此系統綜合的重要性逐漸體現出來，它的作用是在深入分析的基礎上，合理劃分各個組成部分并分配功能，最終將之組成為有機的整體。

近年來，系統綜合(或者綜合集成技術)作為一種方法論，在解決復雜巨系統的問題中愈發受到重視，錢學森[1]也曾提出了“從定性到定量綜合集成方法”，并指出綜合集成方法會起到“1+1>2”的效果。這在航天系統早有體會，也就是為什么有些設計單項技術并不先進，但整體性能卻非常優異的原因；而綜合不好的情況，則是“1+1<2”，每一項技術看似先進，但系統總是問題不斷。

航天控制系統綜合技術的發展并不快，其原因是多方面的。首先傳統的設計思想影響很深，新型號的設計可以很大程度上參照原有的型號，綜合設計的結果在許多人看來是顯而易見的，思路受到了限制，也受到了長期形成的行業分工的限制。其次綜合集成作為一門系統科學，其應用研究略顯不足，工程經驗總結還不夠，在解決實際問題的指導性上還有待加強。

本文并非是對系統綜合技術的歸納提煉，只是提出了一種可應用在航天控制系統設計中的技術，以軟硬件協同設計為基礎，對其原理、應用示例進行了闡述，從中也可以看出系統綜合技術在新形勢下所面臨的機遇和挑戰。

2 軟硬件協同的系統設計與產品實現

將系統綜合技術與軟硬件協同設計聯系在一起，重點是要突出設計初始階段的硬件與軟件并行設計工作。

常用的系統綜合技術可以稱之為“參照法”和“組合法”。參照法也就是“繼承法”，即參照原有的型號進行設計，這種方法帶有明顯的歷史痕跡，也正由于此，各個國家運載火箭具體到設備的組成上，設備的名稱、功能均各有特點，不完全相同，主要是最初始的設計方案因時、因地、因人而異，并一直延續至今[2-3]。組合法則是因技術發展帶來設備功能增強，體積、功耗降低，具備了一機多能的作用，于是可以將多臺設備組合成一臺。在絕大部分情況下，上述兩種方法應用得很好。

這種設計的主要問題是沒有將控制方案(算法)的設計與其硬件載體緊密關聯起來，尤其是在面臨新的控制方案的情況下。當在地面PC機或工作站上完成算法設計后，最終需要向性能遠遜于工作站的目標系統轉化，這樣的轉化過程存在以下風險：

1)根據主頻來選擇可接受的目標系統硬件，但主頻不完全對應具體算法的處理速度；

2)一旦可得到的最快處理器也無法滿足要求，則宣告該算法不可行，需要重新選擇方案；

3)當確需該算法且沒有更快處理器時，往往會簡單認為幾個處理器并行速度就能提高幾倍；

4)促使設計人員不自覺地從市場上找各種各樣的產品，而沒有考慮自主國產化的要求；

5)只有在硬件樣機生產出來之后才會得到驗證，由此可以想象一旦返工所帶來的巨大影響。

為避免上述風險，系統綜合設計應從一開始就選定目標系統，并能通過某種方式進行驗證和反復迭代調整。但此時還未開發出硬件和軟件產品，這種驗證必然是在仿真環境中進行的，即軟硬件協同仿真環境。由此聯想到了電子學的相關技術，因為其在超大規模集成電路(尤其是SOC)的設計中，所采取的技術與綜合設計的需求是相同的[4-5]。二者均是從頂層緊密圍繞系統需求自上而下的設計，強調前期的軟硬件協同設計和優化，也強調充分利用已有的成果和資源以降低風險。

但大系統的綜合設計畢竟不同于SOC中的芯片系統，在最終實現上，航天型號要考慮設計改進、測試、流片、驗證、量產等一系列問題，要分析各種生產、制造的實際情況以及在技術、進度上的風險，并權衡定型、產品化、長期保障等方面的因素，而這些都是“綜合”的過程。綜合的結果是選擇“適合的、可靠的、可獲得的”方案，只有最適合的才是最好的，這與SOC“更好(better)、更快(faster)、更便宜(cheaper)”的競爭目標是不同的：

1)適合的(suitable)——不追求不必要的高性能

在系統設計中有句俗語，“更好是好的敵人”，這是對“適合”這一要求最通俗的解釋。在實際設計中會采用并行技術解決運算慢的問題，如果能夠用多片成熟產品在片外并行解決，就不一定非要集成在片內；當能夠用各種IP核設計出的器件搭建板級產品完成某項功能時，也不一定要集成在一個芯片內；當可以不采用處理器時，不必選擇帶CPU的復雜方案；只在沒有其他解決方案的情況下，才有可能為某一項任務專門研制新的處理器，因為這項工作風險極大。

2)可靠的(reliable)——充分使用已經驗證的產品和技術

產品只有多用，才能加速成熟，可靠性才能得到增長。因此要盡可能增加基礎型產品或者是各種可重用的IP資源的通用性，推廣應用范圍。要避免小修小改帶來的新問題，例如在不影響功耗和體積重量的情況下，即使用不上的功能也不一定要裁剪掉；確需增加的功能可以集中起來一并處理，等等。

3)可獲得的(obtainable)——從源頭貫徹國產化要求

應優先選擇能夠自主設計和生產的IP核，確需改進時，生產制造的難度控制在一定范圍內，例如可以用多個芯片組代替的方案不一定用單個芯片實現，也不一定都設計成SOC(處理器+總線+接口……)，可能就是某種專用模塊，甚至可以用國產化可編程器件來實現?？傊紤]國內的實際情況，以及經費、進度等要求。

3 系統綜合設計平臺及設計流程

3.1 設計平臺

系統綜合設計離不開設計平臺，該平臺必須能為系統設計人員迅速搭建原型并進行驗證，這也是廣義上的“定量綜合集成”的基礎。在系統建模上，有許多卓有成效的研究，這些研究絕大部分集中在建模語言以及復雜模型的設計，如虛擬樣機技術等[6-7]，從控制系統的角度看，它們聚焦在被控對象的建模，包括飛行器的動力學模型，甚至執行機構的模型等，但對控制算法自身和硬件的實現考慮的并不多。本文研究控制系統的實現，在大系統層面的建模更多是考慮子系統或設備之間控制流與信息流的設計，原有的工程經驗仍然可以借用，通過不斷調整、反饋，最后達到最優。

系統建模之后針對具體的產品要進行軟硬件分工。在電子學領域關于如何分工才能實現最優也開展了很多研究，許多用到了智能控制的算法[8]。而在控制領域反倒不需如此復雜，可以首先選擇一個方案，如果不行再調整，因為此階段調整成本較低。為了驗證算法及其實現，需選擇某個處理器IP核，并用原型法設計出應用軟件，然后集成在一起進行仿真驗證。在設計平臺上，各種算法是在目標系統的虛擬環境中運行的，應用軟件須編譯成該CPU能夠識別的目標碼與處理器模型共同仿真，如果采用了操作系統也須一并編譯。因此系統設計平臺包括：仿真環境，建模語言，處理器的IP核，針對該IP核的交叉編譯系統，以及嵌入式操作系統。圖1是系統設計平臺的簡圖。

圖1 系統設計平臺的組成

3.2 設計流程

有了設計平臺，初步劃分了軟硬件的分工，并且編寫了可以仿真的代碼，下面就需要驗證。整個設計流程如圖2所示。如果仿真通過(在規定的時間內完成工作且有一定余量)，則方案基本確定。若覺得某些選型大材小用，可選性能稍低的處理器重復上述過程。若不能滿足要求，可以采取3種處理措施：

圖2 基于IP核的系統設計流程

1)選擇更快的處理器，但如果已經是可獲取的最快的，那只有改進算法或研制更高性能的處理器；

2)多個處理器并行，在軟硬件仿真平臺上驗證并行處理流程與算法，如果飛行軟件能夠便捷地協調各工作流程，就找到了最簡潔的解決手段，即片外并行技術。如果軟件協調并行算法太復雜，就要對原來的處理器模型進行改進，增加一些適應并行處理的功能和指令集，最終將改進后的各種核集成一個芯片。這種情況是有可能發生的，例如在圖像處理中，多個IP核之間存在大容量的數據存貯交換，片外的處理與片內共享內存相比，后者的處理速度更快捷。

3)針對瓶頸部分進行加速處理，可能是某一局部功能的并行，也可以設計專用硬件加速器實現[9]。硬件加速器的優點是首先在不占用主處理器機時的情況下提高了速度，其次針對具體應用進行針對性設計，解題效率更高[10]，第三將設計領域局限在較小范圍內，降低了設計難度。

最終選擇何種方案，是一個“綜合”的過程。

4 應用示例

4.1 時序控制系統的設計示例

考慮設計一個時序控制系統。它的作用是按照時間序列的要求發出一系列指令，完成發動機的點火、關機以及各艙段分離等功能。以某火箭助推分離時序為例，其時序圖如圖3所示。助推器以對稱的方式兩兩關機，即助推器1，3一起關機，助推器2，4一起關機，當兩對助推器均關機后，相隔0.5s點燃分離火箭(ZF)；再間隔0.1s，引爆分離爆炸螺栓(ZB)。每個時序指令在0.3s后清零。

圖3 某型號助推器分離控制時序

如果按照傳統思維，這樣的設計需要定時器以及GPIO等接口：定時器用于各種時間間隔的定時；GPIO用于輸入信號的采樣，如判斷是否兩對助推器主系統均已關機；也用于信號的輸出，如發出各種執行指令。用一個處理器并開發相應的軟件應能很容易地實現，至此我們已在潛意識中規劃出了硬件與軟件的分工。事實上許多型號也是這么做的，最簡單的設計也需要一個8031處理器。

如果我們首先進行系統建模，例如，直接用C語言建模，其代碼如表1左列所示。

表1 C語言及Verilog實現的時序控制

分析該代碼可以發現，這類應用具有以下特點：

1)沒有復雜的數學運算，以邏輯運算為主；

2)輸入/輸出的接口控制都可以等效為存貯單元的讀寫操作；

3)沒有復雜的中斷系統以及多任務需求，對事件的驅動以查詢或定時為主；

4)數據量相對較少且固定。

這種特性也可以直接用硬件描述語言來建模，如表1右列所示。當然建完模型也就意味著可直接用可編程器件實現，不必選擇CPU、編程語言、編譯器，當然它至少需要幾個定時器的IP庫。

這種設計并非只適應簡單的應用。對復雜的系統，可以用多片這樣的硬件來完成控制功能，由于這些被控對象之間的相關性不大，全部用硬件實現具有并發處理的優點，而軟件處理本質上是串行的，它反倒不符合真實世界的物理特性。

4.2 一種閉環制導控制方法的示例

考慮一種閉環制導方案的直接法求解[11]。在某種約束條件下，火箭的位置和速度有如下表達式

x(τ)=Φ(τ)x0+Γ(τ)I(τ)，

(1)

(2)

按照這種理論，火箭在剩余飛行時間內的位置、速度均可以通過當前的位置、速度和當前時刻的推力方向計算得到，由此也可以計算出入軌參數。為進一步簡化描述，將上述問題等效為如下的數學問題：

已知7個控制變量*指六維的協態向量和剩余飛行時間，其中協態向量中的P分量與推力方向矢量ib方向相同。X及其初值X0=(x10x20x30x40x50x60x70)T，經過公式(1)的運算可以得到7個目標參數*如5個軌道根數和俯仰、偏航2個姿態角。Y：Y0=(y10y20y30y40y50y60y70)T，并且可以計算出Y0與要求值Ys的偏差ΔY。我們的任務是調整X0使得ΔY趨于最小或滿足一定門限要求。

由于從推力方向計算出速度和位置需要進行積分運算，因此上述問題的求解具有非線性以及時變的特性。這類問題在地面求解有許多研究成果，包括工業控制領域的廣義預測控制[12]等技術都可以參考，一些智能控制方法已經能夠解決經典控制方法難以處理的高維時變微分方程的求解。但在箭上嵌入式計算機的硬件條件下，這些方法幾乎是不可用的。我們得出這一結論的理由是用了最直觀的主頻對比原則：如果地面計算每個周期耗時超過了飛行控制周期，那么在箭上性能更低的處理器上耗時會更大以致不能滿足實時控制的要求，這也是直接法一直難以在閉路制導飛行實時解算中應用的主要原因。但若采用軟硬件協同設計，未來解決該問題并非不可能。

針對上文提出的問題，可以首先考慮采用“閉路攝動制導”方法，即在飛行中實時求解目標參數對控制變量的一階偏導數，然后根據下式計算修正量

(3)

以X0+ΔX重復公式(1)的計算過程，并再次確認目標參數Y0(X0+ΔX)與要求值Ys是否在誤差范圍內；如果在則認為本次計算收斂，由X0+ΔX確定本控制周期推力方向，實際就是調整了飛行程序角；如果不滿足誤差要求，則需要重新迭代計算。

偏導數求解采用數值法，以x1為例，即以(x10+Δx1x20x30x40x50x60x70)T代入公式(1)，得到：(y10+Δy1y20+Δy2y30+Δy3y40+Δy4y50+Δy5y60+Δy6y70+Δy7)T，

要算出對7個控制變量的偏導數，就要進行上述7次完整的計算。因此公式(1)要計算9次，在得到49個偏導數后按照公式(3)矩陣求逆。如果硬件與軟件沒有協同設計，算法設計人員會根據在地面計算機上的計算量對目標系統提出計算速度的要求，這些運算串行完成。但在軟硬件協同設計中，我們會自然地分析出前8次公式(1)的運算并沒有相關性，只有第9次運算需要矩陣求逆后的運算結果，因此可以考慮并行處理。2種處理方法的不同如圖4所示。

并行能加快計算速度，下一步將對并行方案進一步細化。假設用的處理器只有80486(80386+80387)，則有如下3種方案：

方案1采用8個處理器并行，顯然9個486的設計非常耗費資源。80486實際上是由IU(80386)和FPU(80387)組成的，在本例中，IU并非需要并行，只是數學運算相關的處理需要加速，如果有可靠的FPU，如80387，則可以僅將FPU進行并行處理，這就是方案2的設計。與方案1相比，這種設計已經大大節省資源。

圖4 處理流程

圖5 并行處理方案

進一步分析發現，主要的運算都是矩陣運算(6*6矩陣與向量乘、7*7矩陣的求逆等)，而浮點處理器(如80387)在矩陣運算方面并沒有優勢，并且許多浮點運算功能在本項目中并不需要，此時如果有成熟的矢量運算器可以選擇，通過特殊的數據結構和指令系統，可以加速矩陣的運算，這就是方案3。此外，本示例中各個運算器之間的數據交互量很少，因此采用片外并行也是可取的，即單獨設計矢量運算器，沒有必要將之集成到486中。

以上假設方程的求解可以用一階偏導數，但實際應用中這種方法不具有對各種干擾和限制條件的普適性，因此往往要采用多種優化算法。在上述分析中，由于偏導數的求解導致積分運算重復了好多遍，因此考慮了并行處理。對其他算法而言，不同控制變量組合下的積分運算也要進行很多次，在同等時間內參數調整的頻度越多，選擇的子樣越大，找到最優解的速度也越快，因此并行處理的思路對其他算法同樣是有益的，甚至需要的運算器更多，上述示例有其示范性。

5 小結

基于軟硬件協同仿真的系統綜合設計，借鑒了SOC相關概念和技術，它需要成熟的IP核作為基礎，尤其是處理器的IP核，這可以使我們直接選擇目標系統開展設計，也自然地將國產化要求融入到設計中，這是這種設計方法最大的特點。從2個應用示例也可以看出，系統綜合的結果是考慮各種約束條件下整體最優、且最適合當前技術水平和生產能力的方案，是較為可靠和現實可行的方案。當然，軟硬件協同仿真的效率目前還不是很高，在某次工程實踐中，1s運算量的仿真需要一整天即24h的時間。但我們有理由相信，未來仿真技術的發展會進一步提高速度，而且1s的時間對確定方案也是基本夠了，畢竟1s已是幾十甚至幾百個控制周期的時間了，足夠用來仿真和評價可能最耗時的運算周期。

本文重點討論了控制系統算法設計及其硬件實現，與電子學的軟硬件協同設計以及仿真中的虛擬樣機技術等不盡相同。從分析中可以看到，它縮短了系統設計與產品實現之間的研制鏈條，使得上下游結合更加緊密，也是大幅提升系統性能的有效手段。但無論從建模以及軟硬件功能調整、驗證等工作看，均對系統設計人員的綜合素質提出了很高的要求，這可能成為限制該技術推廣應用的瓶頸。

[1] 于景元.錢學森現代科學技術體系與綜合集成方法論[J].中國工程科學.2001,11：10-18.

[2] 徐延萬.地地戰略導彈與空間運載器控制系統的發展展望[J].航天控制.1986,3.

[3] J.C.Simmons, B.M.Hall,林平，虞秀玉.德爾它運載器數字控制系統的研制[J].系統工程與電子技術.1980,8.

[4] 蔣彭龍,宋征宇.AMBA總線技術在片上系統(SOC)集成設計中的應用[J].航天控制.2006,24(3)：57-60.

[5] Michael Keating, Pierre Bricaud. "Reuse Methodology Mannual for System-on-A-Chip Designs"[M]. 3rdEdition. USA.Kluwer Academic Publishers.2002.

[6] 熊光楞,李伯虎,柴旭東.虛擬樣機技術[J].系統仿真學報.2001,1：114-117.

[7] 胡清華,鄧四二,滕弘飛.虛擬樣機若干關鍵支撐技術研究進展[J].系統仿真學報.2008,11：6186-6189

[8] 丁巖松,闞振舉,徐學航.基于SoC的嵌入式系統軟硬件協同設計[J].控制工程.2009，3.

[9] 劉亮亮,宋征宇.基于AMBA總線的SOC硬件加速器的研究[J].航天控制.2009,27(1)：61-66.

[10] 宋征宇,劉亮亮.基于硬解題的PLC設計及其在測發控系統中的應用[J].航天控制.2012,30(5)：78-82.

[11] 宋征宇.從準確、精確到精益求精——載人航天推動運載火箭制導方法的發展[J].航天控制.2013,31(1)：4-10.

[12] 胡耀華,賈欣樂.廣義預測控制綜述[J].信息與控制.2000,3.