面向小型设备的SCA核心框架优化设计

刘铮 施峻武 唐麒

【摘要】 本文结合在资源受限的小型化设备上实现软件无线电的应用需求，在对SCA核心框架进行深入研究的基础上，针对SCA标准级核心框架的接口冗余、灵活性较差等问题，通过裁剪修改核心框架接口和优化接口之间继承关系等方式，对SCA核心框架进行优化，设计了轻量级核心框架，提高了核心框架的灵活性。

【关键字】 软件无线电 SCA 核心框架 接口

一、引言

软件无线电的核心思想是设计标准化的硬件平台，并使用软件来描述通信系统中的各模块功能，通过在通用硬件平台上加载不同软件来实现各种通信制式功能。软件无线电克服了传统通信设备开发周期长、移植和升级成本高难度大、兼容性差、组网局限等问题，在军事和民用领域都具有广阔的应用前景，引起了军方和商业组织的广泛研究。

SCA作为一个比较成熟的规范，在软件无线电研究领域具有广泛的指导意义。然而由于功能需求的差别，将SCA完整的软件架构移植到小型设备时将产生接口冗余和资源浪费等问题，因此本文针对小型设备的应用场景研究了SCA软件架构的优化和裁剪问题，通过对SCA核心框架的优化有效节省了系统资源，并提高了系统的灵活性。

二、SCA核心框架

SCA的设计理念具有硬件通用化、软件功能化、波形模块化可移植等特点，是目前软件无线电研究的主要参考。SCA规范将软件无线电体系结构划分为三大部分：硬件平台，软件平台（操作环境），波形应用；软件平台又被分为核心框架、中间件、硬件抽象层、板级支持包、操作系统等部分。按照SCA规范，核心框架以一组开放的API接口的形式呈现，按照功能可划分成基本设备接口、基本应用接口、框架控制接口、框架服务接口四类。

以核心框架为核心构造的软件平台是应用软件与底层硬件之间的交互途径，核心框架通过开放给应用层的统一化的接口和服务，为开发者提供底层软件和硬件通用功能的高层次抽象和封装，并为上层应用波形提供了标准的开发规范。核心框架的设计给软件平台的开发提供了可靠的兼容性，软件平台只要提供了核心框架规定的接口，即可兼容支持各种基于SCA开发的波形应用；另一方面，核心框架为波形应用的开发提供了广泛的移植性，按照SCA核心框架的接口定义开发的波形组件，可以移植到所有SCA软件平台上。

目前广泛应用的SCA2.2.2版本给出了支持分布式跨平台的通信体系结构实现的指导，然而该版本体系结构为适应广泛的应用场景，忽视了具体设备和应用场景的差异性。在具体应用场景中，核心框架经常不需要支持完整的功能，不需要实现所有的操作，在实现过程中SCA核心框架的接口只会部分实现，其他很多无需使用的接口会增加系统负担，冗余而复杂的接口关系也会加大开发难度。但是，由于SCA标准级核心框架具有固定的体系结构，对接口关系和接口实现方面有强制性要求，用户不可避免地面临上述问题，灵活性受到限制。

三、SCA核心框架的优化设计

本文针对SCA应用在小型化设备时遇到的核心框架灵活性的问题，面向轻量级的应用场景对核心框架进行了优化，在保证能够满足功能需求的前提下，对不需要的接口及接口间的关系进行裁剪和调整，达到降低系统资源占用和提高系统灵活性的目的。

在改进SCA核心框架过程中，一方面，对核心框架的各类接口中的冗余接口进行裁剪，并修改了设备和服务组件的注册方式，调整了相应接口的实现以保证裁剪掉冗余接口后系统能够正常运行；另一方面，使用了选择性继承的思想优化核心框架灵活性，在细化接口功能的基础上调整了接口间的继承关系，将部分接口继承关系的选择权交给用户，使用户实现时可以根据设计需求对核心框架接口进行选择继承，这种设计不仅能提高系统的灵活性，还能减少系统资源占用。

3.1接口的裁剪

小型化设备通常由单板卡构成，功能相对单一，不需要支持复杂操作，SCA核心框架应用在这样的环境中就会显得过于庞大，支持的功能脱离实际应用，产生的接口冗余不仅降低了开发效率还会加重其资源开销的负担。因此本文在设计轻量级核心框架的过程中，着重针对标准级核心框架的接口进行了裁剪，以删除冗余的接口，降低应用开发者的开发难度，减少资源开销。主要裁剪内容包括：资源管理、设备管理器和文件服务的相关接口等。

首先， SCA设计时为了支持对复杂设备或者说设备组的抽象，在标准级核心框架的基本设备接口中提供了聚合设备（AggregateDevice）接口和父设备（ParentDevice）接口，用来描述由多个功能关联的设备聚合到一起形成的超设备。由于小型化设备上的设备组件本来就很少，而且一般都是在处理性能上独立的，没有使用聚合设备的需求，为了降低系统负担，避免浪费，在轻量级核心框架设计实现中裁剪掉了这两个接口。

SCA2.2.2规范中的Device接口提供了用于处理资源分配和回收方面功能的接口函数（如allocateCapacity和deallocateCapacity等），这些函数在使用逻辑设备加载文件和创建进程等过程中应用，以描述逻辑设备的资源占用。

一方面，由于小型化设备具有单板卡等特点，聚合设备相关接口已经被裁减掉，没有支持跨平台跨板卡的设备资源管理的需求，只需要支持本地的独立逻辑设备的资源管理。

另一方面，实际硬件设备种类较为单一，专用处理器（如DSP、FPGA）通常都不具有动态部分重构的功能，在对这类设备的资源进行管理时只存在已开销和未开销两种状态，因此对本地单个设备的资源管理方式也比较简单。因此在设计实现中将资源管理相关的接口函数剪裁掉，核心框架不再负责设备资源的管理，资源的分配和回收全权交给操作系统来完成。

其次，对于框架控制接口，本文优化了域管理器的注册管理模式。按照SCA2.2.2规范，每个板卡上的各设备组件向该板卡上的设备管理器注册，受该设备管理器管理，然后各设备管理器再向域管理器上的管理注册器注册，受域管理器管理，即设备组件采用三级注册管理模式。结合小型化设备单板卡的特点，域管理器运行在唯一的板卡上，设备管理器一级的注册失去了意义，本文在优化中使用域管理器接管设备管理器的功能，裁剪掉了设备管理器（DeviceMananger）接口，以及域管理器中与设备管理器相关的管理注册器（ManagerRegistry）、组件管理器（ComponentManager）和组件工厂（ComponentFactory），各个设备组件直接向域管理器注册并受其管理。

优化后的两级注册模式的具体实现方法是：在裁剪后的核心框架中，各设备服务组件通过描述文件直接获取域管理器上的组件注册器的对象引用，并调用组件注册器的相应接口完成注册；另一方面，调整域管理器的相关接口，域管理器在实现的时候继承负责设备组件和服务组件的注册和注销的DomComponentRegistry接口和负责波形组件的注册注销的FacComponentRegistry接口，以实现设备和服务等注册的功能，并且在设备、服务组件注册的时候域管理器还会将组件的对象引用记录在列表中，以后可以访问列表获取已注册设备、服务等的对象引用，起到管理的作用。

最后，框架服务接口中的File， FileSystem和FileManager提供了一个构建分布式文件系统的框架，可以在SCA系统中支持多个不同的文件系统，完成文件的远程访问、读写、控制等功能。

然而对于单板卡的小型设备，文件系统只有一个，而且没有分布式的处理环境，也就完全没有分布式文件系统的需求，反而冗余的结构还会使文件系统的使用过程变得复杂，给使用者带来很多不便。

另外由于一般只有一个GPP设备，文件系统的服务完全可以由GPP上的操作系统来提供，这样还可以简化很多处理。由于使用的是基于POSIX的操作系统，直接用操作系统的文件系统不会对移植性带来很大影响。所以，SCA核心框架中支持文件系统的三个接口也裁剪掉。

此外接口裁剪还包括在小型化设备上无法发挥作用的一些其他接口，由于篇幅限制不再赘述。

3.2 接口继承关系的优化

SCA核心框架的设计采用面向对象的设计思想，按照应用需求使用UML语言建模，达到对象属性抽象的目的，模型则以一组具有规则和联系的接口的形式呈现给开发者，再以接口为单位，使用IDL文件记录，IDL文件中的接口保证了核心框架的通用性和可移植性，IDL接口之间的关系则代表了核心框架的体系结构。IDL接口之间主要有继承和使用两种关系，其中继承关系很大程度上影响着接口间的耦合性，对体系结构的灵活性至关重要。

在SCA2.2.2规范设计的标准级核心框架中，为了提高系统的通用性，规范强制限定了各个接口之间的继承关系，并进行了严格封装，这种设计有很强的耦合性，开放给用户的接口受到限制，核心框架的灵活性受到很大影响。

在实际应用开发中，用户经常希望根据功能需求对核心框架的接口进行选择性实现，但是由于核心框架对接口继承关系的强制性，用户在设计时必须仍然要保留所有规定的接口函数，对于无功能需求的接口函数的处理方式只能是将其实现为空。

这种设计导致实现中存在大量的空接口函数，不仅限制了系统的灵活性，而且增加了开发者的负担。由于这些接口在实现中要经过CORBA的IDL编译器编译出了桩码和框架码，即使实现为空也会带来内存开销，造成系统浪费。因为小型设备通常功能比较单一，不需要支持丰富的操作，所以这种应用场景下空接口函数更会频繁出现。

针对以上问题，本文采用了小粒度选择性继承的思想对核心框架的接口继承关系进行了优化，以降低各接口之间的耦合性，提高了核心框架的灵活性。

一方面，对封装了较多功能函数的接口进行粒度细化，按照功能将其分裂成独立的接口，每个接口具有原来的一部分接口函数，对应某种功能特点，以解除SCA中接口封装带来的继承耦合，为选择性继承打下基础。

另一方面，调整接口间的继承关系，取消掉原来一些强制的继承关系，设计成可以根据需要选择性继承的结构，在IDL文件中描述接口继承关系的时候使用宏定义的方式，针对不同应用场景通过开关宏的方式来选择需要继承的接口，避免继承不需要的接口。最后，将选择权交给用户，不再只提供给用户集成过的接口，对用户开放更多基本接口，并由用户来决定选择继承这些接口。

这种继承关系优化方法应用在了基本应用接口和基本设备接口两类接口中。核心框架中的基本应用接口是一组描述应用组件属性的接口，应用组件可以通过继承并实现这些接口使应用组件具备对应操作。

根据SCA2.2.2规范，基本应用接口包括生命周期（LifeCycle）、端口获取器（PortSupplier）、可测试对象（TestableObject）、属性集（PropertySet）和资源（Resource）等，并设定了严格的继承关系——Resource接口强制继承了上述其他接口，具体的应用开发组件再继承Resource接口，形成了一个耦合性极强的结构，限制了子类必须继承父类的相关操作，即使子类不需要对应功能。

本文在优化设计中，首先对接口进行细化，将Resource中的函数start，stop分离出来，做成另外的可控制组件（ControllableComponent）接口，并且将Resource中的属性identifier也独立出来成为新的组件标识符（ComponentIdentifier）接口，另外Port和PortSupplier两个接口合并成了端口存取器（PortAccessor）。

其次，改变接口间的继承关系，设计Resource接口只继承所有应用都必须支持的接口（如LifeCycle），不再强制继承其他的功能性接口，而应用组件在继承Resource的同时，可以根据实际需要选择性继承ComponentIdentifier、PortAccessor、ControllableComponent、TestableObject、PropertySet这五个接口中的若干，接口继承关系如图 1所示。

类似地，基本设备接口的继承关系也按照选择性继承的思想进行了优化，具体设计由于篇幅限制不再赘述

四、结束语

本文通过接口的裁剪和接口间继承关系的优化对SCA核心框架进行了改进，实现了轻量级核心框架，降低了资源需求和开发难度，有效提高了核心框架的灵活性，使其更适合资源受限的小型化设备等应用场景。

参 考 文 献

[1] Joint Program Executive Office （JPEO） Joint Tactical Radio System （JTRS）.Software Communications Architecture Specification.Version 2.2.2.2006.

[2] Joint Program Executive Office （JPEO） Joint Tactical Radio System （JTRS）.Software Communications Architecture Specification.Version Next.2010.

[3] Joint Program Executive Office （JPEO） Joint Tactical Radio System （JTRS）.Software Communications Architecture Specification.Version 4.0.2012.

[4] 唐麒.小型化软件通信体系结构的研究与实现.学位论文.国防科学技术大学电子科学与工程学院，2011.