空间软件无线电标准和体系架构研究

+ 周力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显示了不同软件架构的静态存储资源占用情况。可以看出STRS的静态存储占用远低于轻量级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.