基于OSSIE的SCA波形开发设计.docx

基于OSSIE的SCA波形开发设计.docx

《基于OSSIE的SCA波形开发设计.docx》由会员分享，可在线阅读，更多相关《基于OSSIE的SCA波形开发设计.docx（25页珍藏版）》请在冰豆网上搜索。

基于OSSIE的SCA波形开发设计

《基于OSSIE的SCA波形开发方法与实现》刁茄电子科技大学2008.4.1

文章详细写了基于开源的波形组件集成开发环境（WDE）OSSIE开发平台的波形开发步骤和实现方式。

一．介绍了OSSIE0.6.1平台概述。

OSSIE0.6.1的实现主要分为五部分，对其中一些重要部分说明如下：

1.OSSIE实现：

包含OSSIE的核心文件，其中框架实现文件夹中包含了SCA标准中规定的各种接口，例如ApplicationFactory，DomainManager等的C++实现；

2.解析器中包含的是使用AmaraXML解析包对各种XML文件解析的C++文件；DTD和IDL文件夹中则是SCA标准中附带的文档类型定义和CORBA的接口定义文件。

3.标准接口库：

OSSIE对组件间通信接口的实现，例如complexShort，realChar等。

4.节点启动器：

包含nodeBooter，在OSSIE中负责启动域管理器，设备管理器，并将各个设备通过命名服务进行注册。

此外，它还负责默认的数据输出。

5.OWD：

包含OSSIE波形开发器的实现文件和启动文件wd.py。

波形加载器，包含wavLoader.py，用于波形加卸载，控制波形在核心框架中的运行等。

二．组件设计

组件设计从本节开始对OSSIE的若干关键技术进行研究。

SCA的波形开发与传统的无线电台开发最本质的区别在于，前者将软件工程的一些思想引入到对信号处理的实现上，这样SCA波形才具有软件的可配置、可移植的特性。

面向对象和封装是软件工程思想中最重要的方面，因此SCA规范只规定了组件的框架结构，而对SCA组件的具体实现方式没有也不可能进行说明。

所以，基于WDE开发SCA波形时，首先需要对组件的具体实现方式予以确定。

同时，为了研究基于OSSIE开发SCA波形的方法，需要对其组件的管理和数据传递过程加以研究和分析。

本节首先对OSSIE组件的实现结构进行说明，随后对组件涉及到的线程管理方式进行了研究。

结构设计

线程管理

三．代码生成

WDE区别于传统SCA波形开发方法的最重要特征之一是其组件代码的自动生成功能。

OSSIE的组件设计确定以后，会针对其结构自动生成一些与SCA控制管理的相关代码，称之为包装代码。

本节首先分析了OSSIE采用的自动代码生成方式，然后介绍了OSSIE在生成与安装代码目录上的考虑。

1.生成技术

代码自动生成技术是WDE的一个重要特征，OWD采用的是预定义模板的方法。

在此之前，OSSIE项目组主要考虑了其它两种方法：

一是基于统一建模语言（UnifiedModelingLanguage，UML）的图形化方式。

这也是商用WDE一般所采用的方式，在这种方式中，组件和波形的逻辑结构和配置由UML以可视化的图形方法表示。

它是一个定制代码生成流结构，也是一个基于模板的生成模型。

通过图形化建模，组件的IDL文件可以直接生成，然而考虑到整合相应软件的难度和实际使用范围，OSSIE项目组并没有选择这种方式。

第二种方法是开发一个能支持任何面向对象的类结构通用的代码生成流结构。

设计思想是有一系列的黑盒子，它们每一个都从先前的块中获得一个具体输入，最后从一个完全任意的面向对象的结构中产生源代码。

这种工具在理论上可以解决包括OSSIESDR在内的任意类型软件的组件源代码的生成问题。

但是考虑到开发的复杂性和实际需求，OSSIE项目组也没有采用这种方式。

OSSIE平台实际采用的方法是，通过预定义通用C++模板的方式来生成具体的组件代码。

因为Python内建有强大的字符串和文件处理工具，所以这种方式显得简单和易行。

具体做法是：

用IDL语言预先定义一些通用API（例如realChar），经由OmniORB的IDL编译器编译后，生成服务器和客户端的代码，然后从中抽取必要部分，形成预先定义的C++模板包装文件。

当波形建立以后，利用Python强大的字符串处理功能来针对具体的组件特性（例如名称、端口类型和个数，参数等）生成该组件的包装代码，波形开发人员只需要往包装代码中添加粘合代码和功能代码即可。

模板文件位于图3-1的OWD文件夹中。

而另外一个自动生成的XML域配置文件则采用的是调用Amara解析包的方法来产生，这里不再赘述。

2.目录

生成目录

OWD为波形生成的代码可以分为两部分，组件代码和波形代码。

组件代码主要包含组件XML文件，C++包装文件和自动编译文件。

波形代码则包括波形的域和设备XML文件以及相应的自动编译文件

安装目录为了有效的使用生成的波形代码，OSSIE还建立了一个良好的代码安装结构。

在最初的OWD设计中，每个波形是一个目录，该目录下面包含了所有的代码，包括二进制执行文件，组件和波形的XML文件。

其中波形的XML文件处于最高层，组件的XML文件和二进制执行文件位于每个以组件名命名的目录下。

这样做有两个问题：

1.不利于代码重用。

例如一个在各种波形中使用频繁的组件（例如信号发生器）需要在每个波形下面均复制一个副本。

当这个组件需要修改或添加新功能时，那么所有拥有该组件的波形就都需要修改。

2.不利于生成一个组件库。

新生成的波形不能有效的使用之前开发的各种组件，违背了SCA的初衷。

经过修改以后，OSSIE后续的版本为所有的代码提供了一个分类分层的安装方法。

安装根目录是处于开发者系统上任意位置的sca目录，其下有三个子目录：

bin、xml和waveforms。

bin目录里包含所有已安装的资源和设备的可执行二进制文件；xml目录包含所有已安装的组件XML描述文件；waveforms目录则包含了OSSIE波形的XML文件，这些文件都定位于与其名称相同的子目录下。

这种结构也就较好的解决了上述的两个问题。

四．设备分配

在波形的运行之前，按照SCA规范，需要将各个资源配置到相应的设备上。

OSSIE考虑到实际的复杂性，在设备配置方面有一些不同于SCA规范的特殊考虑，在此加以介绍和说明。

SCA规范本来规定，核心框架在加载波形时，需要根据每个组件的软件包装描述文件（SPD）所包含的信息，如处理能力（内存，处理能力等），装载信息（处理器类型，操作系统，编译器等）等依赖性信息来为给定的组件选择合适的设备，也就是SCA的动态加载特性，这也是区别于传统无线电的一个重要特征。

这种特性需要在应用工厂（ApplicationFactory）把组件分配到设备上之前，逐一检验该设备的各种性能是否符合该设备上每个组件性能的要求。

但是这样做在实际的软件实现中有较大的难度，具体来说有两个方面：

1.对每个组件的实际性能要求进行测试比较麻烦，因为这通常需要将软件下载到实际的目标硬件平台上才可以测试出来。

这在软件是加载到固定硬件平台上的时候是可行的，但是在SCA中，各种应用有可能加载到许多种设备上，这无疑增大了实现的难度。

2.目前没有很好的组件配置算法。

例如，假定第一个问题已经解决，那么每个组件对性能的要求已经精确的评估并记录在相应的SPD文件中。

现在假设有一个具有4个设备（例如两个GPP，一个DSP，一个FPGA）的波形，需要有20个组件配置到这个波形上面。

那么，用最简单的算法（即一个个比较）来寻找一个最佳的组件配置方式需要420次运算。

如果每次运算需要一个处理器1000次时钟周期（保守估计），一个3.0G的处理器大概需要42天时间才能对每个组件检查完毕。

所以，考虑到配置算法的复杂性和实际应用中并无动态配置的需要，而且最初的目标也是致力于一种快速的原型开发工具，所以OSSIE目前并不支持动态的配置组件。

但为了解决核心框架配置组件的问题，于是OWD为每个波形创建了一个专有的XML文件，设备配置序列（DeviceAssignmentSequence，DAS）。

其中，componentid标签包含了与SAD文件中的组件实例相关联的UUID（一种用于唯一的标识组件的编号）；assigndeviceid标签则包含了节点上与DCD文件中的设备实例相关联的UUID。

在加载波形的时候，DAS文件被解析给ApplicationFactory来完成波形组件的配置。

所以，基于OSSIE的波形开发需要在波形设计时就将每个组件分配到相应的设备上，这点和其它WDE是不同的。

五．波形运行流程

六．作者的开发过程（开发原则，实现内容，建模，平台搭建，开发，测试（主要是软件测试和仿真波形数据测试））并没有在硬件平台上测试。

《基于OSSIE的波形开发及API设计实现》雷刚电子科技大学2011.4

1.SCA体系结构

软件定义无线电起源于20世纪90年代，是由美国科学家JoeMitola提出，其核心思想是设计实现一个具有开放的、标准化的、模块化的通用硬件平台，将各种通信功能如调制解调方式、工作频段、数据结构、通信协议、加密方式等用软件的方式来实现，通过加载不同的波形软件实现不同的通信需求及功能。

软件通信体系结构SCA是美军联合战术无线电系统JTRS在软件定义无线电SDR（SoftwareDefinedRadio，SDR）领域的研究热点之一。

SCA设计目的是实现软件波形的可重用、跨平台、性能升级等。

作为一个开放的、独立于具体实现的结构框架，SCA规范描述了无线电台软硬件之间的交互过程。

SCA规范不是关于系统的规范，而是对无线电台系统设计的规则集合，目的是确保软件和硬件的可移植性和可配置性，从而提高设备之间的互操作性。

SCA目前最新的版本是SCA2.2.2，其目录结构如下：

1.SCA主文档：

包括了SCA硬件体系结构和软件体系结构；

2.附录SCAGLOSSARY文档：

SCA缩略语文档，涉及关于SCA的主要缩略用语；3.附录SCAAEP文档：

SCA应用环境配置文档，包含SCA兼容设备所需的环境；

4.附录SCAIDL文档：

SCA使用接口定义语言定义核心框架；

5.附录SCA域配置文件：

描述域中元素UML类图。

1.1硬件体系结构

在SCA规范中，硬件体系结构是指由域中所有硬件类组成的集合。

将硬件划分为类的关键是识别系统的硬件部分以及这些硬件如何构成相应的功能模块。

这些硬件类定义了一些通用元素，这些元素共享相同的物理属性，包括属性和接口，用于特定域平台的应用。

相同的框架结构适用于所有的域。

适当的应用需求对于不同的硬件平台有着相同的硬件模块。

图2-1列出了硬件体系结构图。

硬件模块类HWModule从SCA相关硬件类继承了系统级属性。

图中HWModule类下面的类都是继承HWModule类。

属性名定义了独立于域的硬件设备参数，这些设备参数的值是和硬件设备有关，并满足实现的需求。

实际硬件设备是这些类的实现，具有基于特定平台物理需求和采购性能要求的相关属性值。

一些属性值在波形应用创建的时候使用，由设备配置文件DeviceProfile提供，由核心框架应用程序读取。

机箱类（Chassis）具有特定的物理特性、接口、电源和外部环境属性，并且相互独立不共享。

1.2软件体系结构

SCA软件体系结构如图2-2所示，该体系结构的主要优点体现在如下几个方面：

1.现有商用协议和产品的最大化使用；

2.通过开放的商用软件架构将核心应用程序与非核心应用程序从底层硬件中分离出来；

3.通过使用CORBA实现了分布式处理环境，使软件应用具有可移植性、可重用性和可扩展性。

从图2-2中可以看出，软件体系结构定义了操作环境，这个操作环境由CF核心框架服务和框架软件组成，其中框架软件包括板级支持包、操作系统、网络协议栈串行接口服务和CORBA中间件服务等，这些都统一于SCA实现中。

在软件体系结构图中的CORBA“软总线”以上是应用层。

应用能够实现用户的通信功能，这些通信功能包括调制解调器数字信号处理、链路层协议处理、网络层协议处理、外部输入输出访问、安全等。

文章详细介绍了软件体系结构中的各个部分

2集成开发环境

SCA软件采用面向组件开发（Component-OrientedDevelopment，COD）技术。

传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流到面向对象方法都没有解决复用、分布式异构和互操作等问题。

基于组件的设计方法在软件方法学上为解决这个问题提供了机会，它把应用程序的逻辑和实现相分离，提供标准接口和框架，使得软件开发过程变成组件与组件的组合。

这种基于组件的开发方法是以接口为中心，面向行为的，基于体系结构进行设计的。

在组件模型方面，和目前主流的组件开发模式有微软公司的COM+/DCOM、SUN公司EJB（已被甲骨文收购）和以及对象管理组织（ObjectManagementGroup，OMG）的CROBA/ORB模式。

CORBA/ORB模式为CORBA组件模型（CORBAComponentModel，CCM）。

作为面向对象技术的升级，采用面向组件开发方法有许多优点：

1）组件可以替换和升级；2）降低了系统的复杂度，分而治之；3）提高复用性，对于相同的模块功能可以复用或者继承使用。

基于组件的软件目标是在系统内创建工作良好的高聚合模块，通过分离不同任务模块，降低组件耦合度。

图2-9展示了基于WDE开发SCA波形的流程。

目前SCA集成开发环境有：

1）美国Harris公司的SCACF应用框架和dmTK开发工具构成了一个软件组，为复杂的嵌入式系统（如软件无线电）特性和管理提供了一个高级的软件环境，允许用户对不同波形、协议和用户在无线电设备中的功能进行结合，使得系统设计者在设计上变得灵活，从而减少开发时间和生产无线电系统的总体成本；运行时组件包括：

域管理器DomainManager（DMRE）和一个安装服务（用于注册其他运行时程序）。

现在，Harris有唯一的SCACF的COTS应用，这符合JTRS的要求。

2）加拿大魁北克省Zeligsoft公司的CE（ComponentEnabler）SCA开发工具。

该工具是一个模型驱动开发工具，旨在加快开发，提高符合JTRSSCA标准的软件无线电的质量。

作为SCA重要的开发工具，CE为开发者提供了一种符合SCA标准的模型化方法，将SCA的复杂规则抽象化。

CE在体系层验证SCA规则，并生成正确的副本。

通过适应任何项目环境并和最高级工具协同工作，CE确保了特定域软件和非特定域软件能共同开发、集成、运行，最大地减少项目工作量。

CE的代码生成器为多种操作环境，开发流程和编码模式提供工业级的SCA组件优化代码生成。

CE的代码生成器能确保整个项目的编码质量，生成高品质，易维护具有一致性的代码。

3）PrismTech公司的SpectraSDRTools，该软件无线电开发工具提高了波形和平台开发者的生产力，提供代码自动生成、自动测试、自动生成XML文档以及框架源代码；提供一个预集成、基于标准、独立于硬件的SDR操作环境；并支持在通用目标处理器（如DSP）上互操作性和可移植性。

4）加拿大通信研究中心的SCARI++套件，提供完整的集成与测试环境。

SCARI由以下三个模块组成[16]：

A.一个完整JTRSSCA核心框架；

B.实现SCA复杂需求的组件开发库（ComponentDevelopmentLibrary，CDL）；

C.一组开发套件，该套件大大简化了SDR开发生命周期。

该工具支持SCA的资源、设备、装配波形和平台节点以及部署和测试应用程序。

5）由美国维吉尼亚大学MPRG团队于2003年开发设计的OSSIE平台。

作为一个开源波形集成开发环境，OSSIE开发平台实现了基于C++的SCA核心框架接口，其开发的首要目的是用于SDR和无线通信的研究与教学。

OSSIE目前处于频繁的开发阶段，目前的最高版本为OSSIE0.8.1。

OSSIE提供了图形化的波形开发环境以及高效的组件部署环境。

同前面四种需要授权的商业开发套件相比，开源的优势使OSSIE在软件无线电波形研究领域应用更为广泛。

本文所作的波形开发工作正是基于OSSIE开发平台。

2.1OSSIE集成开发环境

OSSIE（TheOpenSourceSCAImplementation:

:

Embedded）是维吉尼亚大学（VirginiaTech，VT）移动和可移植无线电研究小组（MobileandPortableRadioResearchGroup，MPRG）关于SCA的一个开源实现，是VirginiaTech贡献给开源社区的对软件定义无线电开发软件包[17]。

OSSIE基于C++实现了SCA的核心框架接口，提供SCA规范要求的常用功能接口。

OSSIE的首要目的是用于SDR和无线通信的研究与教学。

该软件包包含基于JTRS软件通信架构的软件定义无线电核心框架，用于快速开发SDR组件和波形应用的工具，一个预构建的组件和波形库。

2.2OSSIE集成开发环境的演进

2.3OSSIE软件结构

OSSIE的实现主要包括平台、组件开发库、系统构成、波形库以及波形开发套件等五部分组成。

在该平台上开发的设备有通用处理器GPP、USRP、声卡设备和XilinxFPGA等。

其中软件无线电通用外设（UniversalSoftwareRadioPeripheral，USRP）是Gnuradio项目设计，其设计旨在使普通计算机能像高带宽的软件无线电设备一样工作，从本质上将，它充当一个无线电通讯系统的数字基带和中频部分。

在组件库中有放大器组件、自动增益控制组件、信道组件、数字调制组件、FM解调组件等，在开发过程中开发的组件都存于组件库中，利于复用，这些组件有一部分属于开源的。

在系统目录中主要是节点启动器，波形装载器以及核心框架实现等，标准接口库实现了组件间通信接口，例如realDouble，complexChar等。

软件开发人员将较早版本中本属于工具目录的节点启动器和波形装载器放到系统目录下，是基于优化波形开发流程的考虑，从组件的设计到波形最后装载可以归结为一个最小的完整的开发流程，同时将其他工具如：

ALF，wavedash放到了工具目录下。

下面对OSSIE的软件结构说明如下，主要包括以下部分：

1）核心框架实现：

OSSIE平台的核心文件。

在核心框架实现文件中基于C++实现了SCA标准中规定的各种接口，例如：

DomainManager，ApplicationFactory等接口的C++实现；

2）操作系统：

OSSIE早期版本是基于Windows操作系统开发，研究人员考虑到可移植性的要求，将OSSIE开发到开源的Linux操作系统上。

目前采用的Linux操作系统版本是开源的Ubuntu10.4版本。

3）CORBA中间件：

OSSIE早期在Windows中采用的CORBA开发库是ACE/TAO。

这里的自适应通信环境（AdaptiveCommunicationEnvironment，ACE）是一个免费开源的面向对象框架结构，该结构实现了许多并行通信软件的核心设计模式。

ACE提供丰富的C++包装接口，以及可跨平台执行通信软件的基本任务的框架对象，提供的基本任务包括事件分离与事件处理的分发、信号量处理、服务初始化、进程间通信、共享内存管理、消息路由、分布式服务的动态配置、并发执行与同步。

TAO（TheACEObjectrequestbroker）是一个基于CORBA标准的中间件，实现了远程对象的调用，不用关心如何进行对象定位。

在OSSIE最新版本中采用的CORBA开发库是由C++和Python语言实现的omniORB开发库，omniORB实现了异构系统的异种语言软体合并、协作，远程调用对象，对客户端隐藏了底层实现细节，版本号为omniORB-4.1.4。

4）标准接口库：

在标准接口库中实现了OSSIE自定义的一些接口，包括realDouble，complexShort等，软件实现包括接口定义文件，C++实现的框架代码文件等。

5）OSSIEXML解析器：

提供在SCA文件系统中访问XML文件，XML解析器可以读取、更新、创建和操作一个XML文档。

6）波形开发器（OSSIEWaveformDeveloper，OWD）：

OWD为OSSIE提供了图形化的波形开发、加载和卸载界面；选用的图像依赖包是wxWidgets，这是一个基于C++API开发的跨平台图像化用户接口GUI。

7）Eclipse集成环境：

Eclipse是依赖C++和JAVA的开源集成开发环境，OSSIE以插件的形式集成在Eclipse中。

作为软件构成的一部分，OSSIE还需要依赖以下软件包，包括：

a）Boost库：

这是一个公共机制的一个C++库。

b）omniORBpy软件包：

为omniORB设计的Python接口[20]，在OSSIE工具和组件中需要用到，使用的版本omniORBpy-3.4；

c）wxPython软件包：

为wxWidgets图形库文件设计的Python接口，OSSIE工具需要用到，其中wxWidgets是一个开源的跨平台的C++构架库，它提供图形用户界面（GraphicalUserInterface，GUI）和其他工具。

在OSSIE中使用的版本是v2.8版本。

d）NumPy软件包：

NumericalPython是一个广为应用的Python扩展库，用于快速处理任意维数的固定类型数组。

在Ubuntu操作系统方面，OSSIE也需要如下依赖包，比如：

GNU的GCC编译器，这是linux系统下的功能强大、性能优越的多平台编译器。

GCC编译器能将C、C++语言源程序、汇编程序、和目标程序编译、连接成可执行文件，如果没有给出执行文件的名字，GCC将生成一个名为a.out的文件。

在OSSIE的组件文档结构中会生成两个后缀名为.o的文件，一个是mian.o，另一个是.o文件。

这两个文件分别由main.cpp和.cpp文件编译连接生成。

其他的一些库文件包括omniidl4-python，libboost-thread-dev等，限于篇幅不一一描述。

2.4OSSIE套件

OSSIE软件套件构成可以用图2-11所示。

1）可用资源组件开发库是一套库，提供工具类和通用的SCA组件。

CDL能帮助开发者快速生成组件的框架代码，大大减少需要手工编写开发和测试代码工作量，让开发者从编写这些代码的工作中解放出来，专注于功能代码的实现。

组件开发库是多线程的并且完全独立于OSSIE软件套件，它能够部署到其他第三方核心框架上，重要的是可以在不同SCA电台之间实现可移植性。

2）波形开发器OWD在软件结构中介绍过，它的主要作用是为各组件生成各自的C++实现的包装代码并对XML域配置文件；对组件的连接和配置提供图形化的操作界面；提供可视化的波形装配界面，在OWD中还包括可用资源组件库。

3）核心框架作为套件之一在软件结构部分做过讨论，这里就不详细叙述。

4）波形加载器：

波形加载器ALF是OSSIE新加入的一个用于波形部署的工具，用以替换老版本的wavLoader工