空間軟件無線電標準和體系架構研究

+ 周力1,2，魏急波1,2，唐麒1,2，熊俊1,2，趙海濤1,2，習勇2

(1. 國防科技大學 電子科學學院) (2. 湖南省軟件無線電工程技術研究中心)

近年來，軟件無線電（Software Defined Radio，SDR）技術發展迅速，將SDR應用于衛星通信、測控和導航等應用開發能顯著縮短整個系統的研制和迭代周期，有效降低成本。通過構造開放的標準化硬件平臺和軟件平臺，將各種空間應用（如通信波形、組網協議、遙感遙測等）用符合標準接口規范的軟件來實現，可構建具有高度靈活性和開放性的空間SDR體系架構，進一步支撐軟件定義衛星的實現。目前，在世界范圍內，經過實踐檢驗的SDR標準化體系架構主要有軟件通信體系架構（Software Communications Architecture，SCA ）[1]和空間通信無線電系統（Space Telecommunications Radio System，STRS）[2]兩個系列。

如表1所示，SCA標準起步于2000年，經過早期幾個版本的驗證，于2006年發布了用于正式部署的版本SCA 2.2.2[3]，這也是迄今為止使用最為廣泛的標準版本。據統計，截止到2017年底，全球范圍內采用SCA 2.2.2標準的軍用和安全電臺數量已經超過了50萬部[4]，參與的國家、研究中心和項目的數量不斷增加，配套標準仍在不斷完善和發展之中。目前，SCA已成為國際標準，主要由美國國防部聯合戰術網絡中心（Joint Tactical Networking Center，JTNC）和無線創新論壇（Wireless Innovation Forum，WInnForum）主導，并在北約國家廣泛應用。2015年8月，JTNC發布了跨時代的SCA 4.1[5]，針對新技術背景下的應用需求，對SCA 2.2.2進行了大量優化（取消了對CORBA的依賴，支持功能裁剪等），并引入了諸多新特性（組件自啟動、嵌套應用、應用互連等）。2018年2月28日，美國國防部正式宣布在美軍陸海空戰術裝備中全面強制部署SCA 4.1標準，取代之前部署的SCA 2.2.2規范[1]，這標志著SCA 4.1即將在全球范圍內進入全面部署階段。

表1 SCA 標準的發展歷程

早在2002年，美國航天局（National Aeronautics and Space Administration，NASA）就啟動了空間SDR計劃，并于2006年前后嘗試將SCA 2.2.2應用于空間無線電載荷。但是受限于當時空間載荷存儲和處理資源的限制，該計劃初期進展并不順利?？紤]到空間載荷大小、重量、功耗和計算能力的限制， NASA決定定義一套適用于空間應用需求的SDR體系架構，通過采用輕量化的軟件架構設計，減少載荷資源的開銷，以適應在資源受限場景下應用SDR技術的要求。2010年，NASA將3個符合STRS標準架構的SDR載荷送入空間站，開放給學術界和工業界進行科學實驗和創新[6]。2012年，Harris公司將STRS架構應用于AppStar衛星載荷體系架構，用于通信、地理觀測、飛機和艦船跟蹤等領域[7]。2018年3月14日，NASA將標準升級到NASA-STD-4009A[8]，進一步支撐空間SDR的發展。當前，無線創新論壇已將STRS標準收錄為其系列標準之一。

從基本功能上來看，SCA和STRS這兩套標準體系架構都支持應用與平臺的解耦，支持應用組件的連接和通信。那么，當SCA發展到4.1版本的階段，其優化后的性能能否支持其在空間SDR中的應用？本文對兩種體系架構軟件平臺的功能特性和性能指標進行了研究，以探索將SCA 4.1體系架構應用于空間SDR的可能性。

圖1 SCA 4.1體系架構

圖2 STRS體系架構

表2 SCA 4.1和STRS對比

1 標準體系架構介紹

1.1 SCA 4.1體系架構

SCA 4.1體系架構如圖1所示，一般將底層驅動之上、波形應用之下的軟件統稱為運行環境（Operating Environment，OE）[4]。OE提供了管理和執行框架組件的功能，主要由操作系統、傳輸機制、核心框架控制組件、平臺設備組件和平臺服務組件組成。平臺設備組件對硬件平臺中的設備驅動進行封裝，為波形提供訪問設備資源的應用程序接口（Application Program Interface, API），設備組件需要實現基本設備API。平臺服務是平臺提供的各種非硬件的、由軟件實現的組件，如日志服務，事件服務組件等。OE還包括了實時嵌入式操作系統，用于為系統中的軟件，如應用、設備、服務等提供多線程服務。OE采用傳輸機制來提供的C/S操作。C/S通信鏈路中的客戶端和服務端可共存于同一處理器，也可分布在不同處理器當中。傳輸機制結構主要由對象請求語義、消息轉換、消息結構和消息傳輸組成。

1.2 STRS體系架構

盡管經過了幾次更迭，STRS標準體系架構并無大的變化?？偟膩砜?，STRS體系架構采用了軟件分層的思想設計，包括底層驅動、操作系統、硬件抽象層、核心框架和平臺應用等部分。各層之間主要通過標準API進行通信。其中，核心框架組件通過API對應用組件進行管理和操作，應用組件之間以及應用組件與系統服務和設備之間通過標準的波形應用API和設備接口API進行通信，硬件抽象層API為操作環境的軟件對硬件的訪問提供了設備控制API接口，POSIX子集API提供了符合POSIX規范子集的API接口，提供了應用訪問操作系統服務的統一機制。

1.3 二者比較

表2對SCA 4.1和STRS的主要特性進行了對比。從代碼實現上來看，SCA一般用C++實現，STRS一般采用C來實現。從組件間傳輸機制上來看，SCA 4.1取消了對CORBA的依賴，但是仍可以很好地兼容CORBA，STRS對傳輸機制沒有具體要求。二者在可移植性、組件化、組件部署、軟件庫、硬件抽象層、設備管理上的特性類似。此外，SCA 4.1支持功能裁剪、組件自啟動、嵌套應用和應用互連等新特性，這些都是STRS所不具備的。

2 標準接口實現

2.1 SCA 4.1標準接口

SCA 4.1核心框架以一組開放的API和服務形式，為應用軟件提供底層軟、硬件的抽象接口。核心框架的各接口之間的關系如圖3所示，具體包括以下幾類。

（1）基本應用接口：包括組件標識（Component Identifier）、端口存取器（Port Accessor）、生命周期（Life Cycle）、可測試接口（TestableInterface）、屬性集（PropertySet）和可控制接口（ControllableInterface），是應用軟件的標準基本接口，可被有選擇性地繼承和實現。

（2）框架控制接口。包括應用管理器（Application Manager）、部署屬性（Deployment Attributes）、應用工廠（Application Factory）、域管理器（Domain Manager）、域安裝器（Domain Installation）、組件注冊器（Component Registry）、完整組件注冊器（Full Component Registry）、事件通道注冊器（Event Channel Registry）和可釋放管理器（ReleasableManager），它們是系統管理和控制的標準接口。

圖3 SCA 4.1核心框架接口

圖4 STRS核心框架基本接口

圖5 STRS應用基本接口

圖6 KDZL-SDR-EL01通用硬件平臺

（3）基本設備接口。包括可管理接口（Administratable Interface）、容量管理器（Capacity Management）、設備屬性（Device Attributes）、聚合設備屬性（Aggregate Device Attributes）、可加載接口（Loadable Interface）、可執行接口（Executable Interface）和聚合設備（Aggregate Device），是硬件物理設備的標準抽象接口，可被有選擇性地繼承和實現。

（4）框架服務接口。包括文件（File）、文件系統（File System）、和文件管理器（File Manager），是系統軟件服務對象的標準接口。

2.2 STRS標準接口

STRS標準接口作為軟件架構的關鍵部件，主要用于促進目標平臺的軟件配置和控制。為了提高STRS波形應用的可移植性，STRS標準采用了四種基本的接口： STRS API、APP API、HAL API和POSIX API。STRS API是核心框架提供的API集，用于支持波形應用、服務和通信設備彼此間的互操作來，以完成波形的組件化實現和可重構功能。圖4為STRS核心框架必須實現的最小API集。APP API規范了STRS應用研發者必須實現的一組接口與功能，如圖5所示。HAL API對硬件驅動接口作了統一封裝，通過硬件抽象的方式為專用硬件提供了一種軟件視角。由于該接口的存在，使得運行在平臺專用硬件上的軟件能夠與平臺的核心框架集成，以屏蔽底層的硬件和驅動的差異。POSIX API是嵌入式操作系統提供的可移植性接口集，以便于波形應用和服務對嵌入式操作系統的訪問。

圖7 組件間通信時延示意圖

圖8 應用部署時延的流程

3 測試環境

3.1 測試環境介紹

測試環境采用的硬件平臺和相關軟件均由湖南省軟件無線電工程技術研究中心自行研發，硬件平臺型號為KDZL-SDR-EL01，如圖6所示。 KDZL-SDR-EL01是一款高性能的通用軟件無線電平臺，該平臺主要芯片型號為ZYNQ 7030，包含一個雙核ARM及一塊FPGA，型號分別為Cortex-A9 (時鐘頻率 667MHz)和Kintex-7 (邏輯單元：125K，DSP片：400)，其DDR儲存大小為1GB，操作系統采用Linux 3.17。在實驗中，標準軟件平臺和應用均部署于ARM之中，暫不考慮FPGA組件的影響。初始狀態下，軟件平臺和應用均存儲于FLASH之中。

圖9 應用切換時延的流程

在實驗中，我們分別采用了依照NASA-STD-4009和SCA 4.1實現的STRS和SCA軟件平臺，其中SCA軟件平臺包含功能完備的全量級SCA軟件平臺和精簡后的輕量級SCA軟件平臺。我們將STRS、輕量級SCA和全量級SCA標準化軟件平臺部署到同樣的測試環境，對靜態存儲占用、組件間通信時延、應用部署時延和應用切換時延進行測試對比，其中STRS和輕量級SCA采用共享內存傳輸機制，全量級SCA采用CORBA傳輸機制。

3.2 測試指標和方法

本文實驗目的在于分析和SCA和STRS體系架構的效率，選取的指標包括：靜態儲存占用、組件間通信時延、應用部署時延和應用切換時延。對于靜態儲存占用，只需要對需要部署到目標設備平臺上的文件進行統計、計算即可。對于時延測試，我們考慮了不同的數據包大小、組件數量所帶來的影響。下面介紹一下測試的方法。

（1）組件通信時延的測量

對于時延的測量，可以采用定點加入時間戳計算時延的方法，具體如圖7所示。

給定一個由N個級聯組件組成的應用，數據包從組件1依次傳到組件N。在實驗中記錄兩個時間節點：T1和TN，TN是組件N收到最后一個數據包后的計時，將所有組件內部的處理代碼屏蔽，這樣組件內的處理時延可以忽略不計，TN與T1的差值即為N-1倍組件間通信時延。

表3 實驗參數

表4 靜態存儲占用對比

表5 不同數據包大小下組件間通信時延對比

表6 不同組件數下組件間通信時延對比

表7 不同組件數下應用部署時延對比

表8 不同組件數下應用切換時延對比

應用部署時延和應用切換時延的測試方法與通信時延的測試方法一樣，應用部署時延與應用切換時延分別包括的過程如圖8和圖9所示。

應用部署時延包括從系統初始化到應用啟動的整個過程。應用切換時延包括從應用停止到應用再次發射的整個過程。由于本實驗內組件內做空處理，因此影響應用部署和切換時延的主要是組件數量，在實驗過程中分別對不同組件數量條件下進行測試，得到多組應用部署、應用切換時延，用以進行分析、研究。實驗參數如表3所示。

4 實驗結果

表4顯示了不同軟件架構的靜態存儲資源占用情況?？梢钥闯鯯TRS的靜態存儲占用遠低于輕量級SCA和全量級SCA，更適用于存儲受限的系統。

表5對比了在不同數據包大小條件下各軟件架構的組件間通信效率，組件數量為11。結果表明STRS和輕量級SCA在數據包不同的條件下，組件間通信時延性能較為接近，STRS對數據包的大小不敏感，輕量級SCA隨著數據包大小的變大緩慢增加。全量級SCA是組件間通信時延是STRS和輕量級SCA的10倍以上。

表6顯示了在不同組件數量條件下各軟件架構的組件間通信效率，數據包大小為4kb。從表中可以看出，隨著組件數的增多，單個組件連接平均時延的總體趨勢都是增大的，幅度較為平緩。

表7和表8分別給出了在不同組件數下不同軟件架構的應用部署和應用切換效率對比情況。從表中可以看出，在相同的傳輸機制下，輕量級SCA的應用部署時延和應用切換時延約為STRS的4倍，而全量級SCA的應用部署時延和切換時延是STRS的40倍以上，而且隨著應用組件數的增加，應用部署時延和切換時延增加速度加快，在組件數為11時，全量級SCA的應用部署時延和切換時延已達到是STRS的100倍。

5 結束語

本文對當前主流的SDR標準和體系架構SCA和STRS進行了研究，在功能和性能上對二者進行了對比。從功能上看，SCA具有更豐富的特性，支持更多的應用形態需求。從性能上看，輕量級SCA和STRS的組件間通信時延相當，對應用運行時的性能影響幾乎可以忽略不計，STRS的應用啟動和切換效率遠優于SCA。本文的結論可為我國空間SDR體系架構的設計和標準化工作提供一定參考依據。

[1]http://www.public.navy.mil/jtnc/Pages/home.aspx

[2]https://strs.grc.nasa.gov/

[3]“Software Communications Architecture (SCA)Specification,” JTRS Standards, Joint Program Executive Office(JPEO) Joint Tactical Radio System (JTRS), Version 2.2.2, May 2006.

[4]S. Bernier, M. Michaud-Rancourt, F. Levesque, J. Zamora Zapata, “The Enduring Myths of the Software Communications Architecture”,

[5]“Software Communications Architecture (SCA)Specification,” Joint Tactical Networking Center (JTNC),Version 4.1, August 2015.

[6]https://www.nasa.gov/mission_pages/station/research/experiments/162.html

[7]https://www.harris.com/solution/reconfigurablemultimission-payloads

[8]“Space Telecommunications Radio System (STRS)Architecture Standard, NASA-STD-4009A”, NASA Technical Standard, March 2018.