劉錚 施峻武 唐麒

【摘要】 本文結(jié)合在資源受限的小型化設備上實現(xiàn)軟件無線電的應用需求，在對SCA核心框架進行深入研究的基礎上，針對SCA標準級核心框架的接口冗余、靈活性較差等問題，通過裁剪修改核心框架接口和優(yōu)化接口之間繼承關系等方式，對SCA核心框架進行優(yōu)化，設計了輕量級核心框架，提高了核心框架的靈活性。

【關鍵字】 軟件無線電 SCA 核心框架 接口

一、引言

軟件無線電的核心思想是設計標準化的硬件平臺，并使用軟件來描述通信系統(tǒng)中的各模塊功能，通過在通用硬件平臺上加載不同軟件來實現(xiàn)各種通信制式功能。軟件無線電克服了傳統(tǒng)通信設備開發(fā)周期長、移植和升級成本高難度大、兼容性差、組網(wǎng)局限等問題，在軍事和民用領域都具有廣闊的應用前景，引起了軍方和商業(yè)組織的廣泛研究。

SCA作為一個比較成熟的規(guī)范，在軟件無線電研究領域具有廣泛的指導意義。然而由于功能需求的差別，將SCA完整的軟件架構(gòu)移植到小型設備時將產(chǎn)生接口冗余和資源浪費等問題，因此本文針對小型設備的應用場景研究了SCA軟件架構(gòu)的優(yōu)化和裁剪問題，通過對SCA核心框架的優(yōu)化有效節(jié)省了系統(tǒng)資源，并提高了系統(tǒng)的靈活性。

二、SCA核心框架

SCA的設計理念具有硬件通用化、軟件功能化、波形模塊化可移植等特點，是目前軟件無線電研究的主要參考。SCA規(guī)范將軟件無線電體系結(jié)構(gòu)劃分為三大部分：硬件平臺，軟件平臺（操作環(huán)境），波形應用；軟件平臺又被分為核心框架、中間件、硬件抽象層、板級支持包、操作系統(tǒng)等部分。按照SCA規(guī)范，核心框架以一組開放的API接口的形式呈現(xiàn)，按照功能可劃分成基本設備接口、基本應用接口、框架控制接口、框架服務接口四類。

以核心框架為核心構(gòu)造的軟件平臺是應用軟件與底層硬件之間的交互途徑，核心框架通過開放給應用層的統(tǒng)一化的接口和服務，為開發(fā)者提供底層軟件和硬件通用功能的高層次抽象和封裝，并為上層應用波形提供了標準的開發(fā)規(guī)范。核心框架的設計給軟件平臺的開發(fā)提供了可靠的兼容性，軟件平臺只要提供了核心框架規(guī)定的接口，即可兼容支持各種基于SCA開發(fā)的波形應用；另一方面，核心框架為波形應用的開發(fā)提供了廣泛的移植性，按照SCA核心框架的接口定義開發(fā)的波形組件，可以移植到所有SCA軟件平臺上。

目前廣泛應用的SCA2.2.2版本給出了支持分布式跨平臺的通信體系結(jié)構(gòu)實現(xiàn)的指導，然而該版本體系結(jié)構(gòu)為適應廣泛的應用場景，忽視了具體設備和應用場景的差異性。在具體應用場景中，核心框架經(jīng)常不需要支持完整的功能，不需要實現(xiàn)所有的操作，在實現(xiàn)過程中SCA核心框架的接口只會部分實現(xiàn)，其他很多無需使用的接口會增加系統(tǒng)負擔，冗余而復雜的接口關系也會加大開發(fā)難度。但是，由于SCA標準級核心框架具有固定的體系結(jié)構(gòu)，對接口關系和接口實現(xiàn)方面有強制性要求，用戶不可避免地面臨上述問題，靈活性受到限制。

三、SCA核心框架的優(yōu)化設計

本文針對SCA應用在小型化設備時遇到的核心框架靈活性的問題，面向輕量級的應用場景對核心框架進行了優(yōu)化，在保證能夠滿足功能需求的前提下，對不需要的接口及接口間的關系進行裁剪和調(diào)整，達到降低系統(tǒng)資源占用和提高系統(tǒng)靈活性的目的。

在改進SCA核心框架過程中，一方面，對核心框架的各類接口中的冗余接口進行裁剪，并修改了設備和服務組件的注冊方式，調(diào)整了相應接口的實現(xiàn)以保證裁剪掉冗余接口后系統(tǒng)能夠正常運行；另一方面，使用了選擇性繼承的思想優(yōu)化核心框架靈活性，在細化接口功能的基礎上調(diào)整了接口間的繼承關系，將部分接口繼承關系的選擇權(quán)交給用戶，使用戶實現(xiàn)時可以根據(jù)設計需求對核心框架接口進行選擇繼承，這種設計不僅能提高系統(tǒng)的靈活性，還能減少系統(tǒng)資源占用。

3.1接口的裁剪

小型化設備通常由單板卡構(gòu)成，功能相對單一，不需要支持復雜操作，SCA核心框架應用在這樣的環(huán)境中就會顯得過于龐大，支持的功能脫離實際應用，產(chǎn)生的接口冗余不僅降低了開發(fā)效率還會加重其資源開銷的負擔。因此本文在設計輕量級核心框架的過程中，著重針對標準級核心框架的接口進行了裁剪，以刪除冗余的接口，降低應用開發(fā)者的開發(fā)難度，減少資源開銷。主要裁剪內(nèi)容包括：資源管理、設備管理器和文件服務的相關接口等。

首先， SCA設計時為了支持對復雜設備或者說設備組的抽象，在標準級核心框架的基本設備接口中提供了聚合設備（AggregateDevice）接口和父設備（ParentDevice）接口，用來描述由多個功能關聯(lián)的設備聚合到一起形成的超設備。由于小型化設備上的設備組件本來就很少，而且一般都是在處理性能上獨立的，沒有使用聚合設備的需求，為了降低系統(tǒng)負擔，避免浪費，在輕量級核心框架設計實現(xiàn)中裁剪掉了這兩個接口。

SCA2.2.2規(guī)范中的Device接口提供了用于處理資源分配和回收方面功能的接口函數(shù)（如allocateCapacity和deallocateCapacity等），這些函數(shù)在使用邏輯設備加載文件和創(chuàng)建進程等過程中應用，以描述邏輯設備的資源占用。

一方面，由于小型化設備具有單板卡等特點，聚合設備相關接口已經(jīng)被裁減掉，沒有支持跨平臺跨板卡的設備資源管理的需求，只需要支持本地的獨立邏輯設備的資源管理。

另一方面，實際硬件設備種類較為單一，專用處理器（如DSP、FPGA）通常都不具有動態(tài)部分重構(gòu)的功能，在對這類設備的資源進行管理時只存在已開銷和未開銷兩種狀態(tài)，因此對本地單個設備的資源管理方式也比較簡單。因此在設計實現(xiàn)中將資源管理相關的接口函數(shù)剪裁掉，核心框架不再負責設備資源的管理，資源的分配和回收全權(quán)交給操作系統(tǒng)來完成。

其次，對于框架控制接口，本文優(yōu)化了域管理器的注冊管理模式。按照SCA2.2.2規(guī)范，每個板卡上的各設備組件向該板卡上的設備管理器注冊，受該設備管理器管理，然后各設備管理器再向域管理器上的管理注冊器注冊，受域管理器管理，即設備組件采用三級注冊管理模式。結(jié)合小型化設備單板卡的特點，域管理器運行在唯一的板卡上，設備管理器一級的注冊失去了意義，本文在優(yōu)化中使用域管理器接管設備管理器的功能，裁剪掉了設備管理器（DeviceMananger）接口，以及域管理器中與設備管理器相關的管理注冊器（ManagerRegistry）、組件管理器（ComponentManager）和組件工廠（ComponentFactory），各個設備組件直接向域管理器注冊并受其管理。

優(yōu)化后的兩級注冊模式的具體實現(xiàn)方法是：在裁剪后的核心框架中，各設備服務組件通過描述文件直接獲取域管理器上的組件注冊器的對象引用，并調(diào)用組件注冊器的相應接口完成注冊；另一方面，調(diào)整域管理器的相關接口，域管理器在實現(xiàn)的時候繼承負責設備組件和服務組件的注冊和注銷的DomComponentRegistry接口和負責波形組件的注冊注銷的FacComponentRegistry接口，以實現(xiàn)設備和服務等注冊的功能，并且在設備、服務組件注冊的時候域管理器還會將組件的對象引用記錄在列表中，以后可以訪問列表獲取已注冊設備、服務等的對象引用，起到管理的作用。

最后，框架服務接口中的File， FileSystem和FileManager提供了一個構(gòu)建分布式文件系統(tǒng)的框架，可以在SCA系統(tǒng)中支持多個不同的文件系統(tǒng)，完成文件的遠程訪問、讀寫、控制等功能。

然而對于單板卡的小型設備，文件系統(tǒng)只有一個，而且沒有分布式的處理環(huán)境，也就完全沒有分布式文件系統(tǒng)的需求，反而冗余的結(jié)構(gòu)還會使文件系統(tǒng)的使用過程變得復雜，給使用者帶來很多不便。

另外由于一般只有一個GPP設備，文件系統(tǒng)的服務完全可以由GPP上的操作系統(tǒng)來提供，這樣還可以簡化很多處理。由于使用的是基于POSIX的操作系統(tǒng)，直接用操作系統(tǒng)的文件系統(tǒng)不會對移植性帶來很大影響。所以，SCA核心框架中支持文件系統(tǒng)的三個接口也裁剪掉。

此外接口裁剪還包括在小型化設備上無法發(fā)揮作用的一些其他接口，由于篇幅限制不再贅述。

3.2 接口繼承關系的優(yōu)化

SCA核心框架的設計采用面向?qū)ο蟮脑O計思想，按照應用需求使用UML語言建模，達到對象屬性抽象的目的，模型則以一組具有規(guī)則和聯(lián)系的接口的形式呈現(xiàn)給開發(fā)者，再以接口為單位，使用IDL文件記錄，IDL文件中的接口保證了核心框架的通用性和可移植性，IDL接口之間的關系則代表了核心框架的體系結(jié)構(gòu)。IDL接口之間主要有繼承和使用兩種關系，其中繼承關系很大程度上影響著接口間的耦合性，對體系結(jié)構(gòu)的靈活性至關重要。

在SCA2.2.2規(guī)范設計的標準級核心框架中，為了提高系統(tǒng)的通用性，規(guī)范強制限定了各個接口之間的繼承關系，并進行了嚴格封裝，這種設計有很強的耦合性，開放給用戶的接口受到限制，核心框架的靈活性受到很大影響。

在實際應用開發(fā)中，用戶經(jīng)常希望根據(jù)功能需求對核心框架的接口進行選擇性實現(xiàn)，但是由于核心框架對接口繼承關系的強制性，用戶在設計時必須仍然要保留所有規(guī)定的接口函數(shù)，對于無功能需求的接口函數(shù)的處理方式只能是將其實現(xiàn)為空。

這種設計導致實現(xiàn)中存在大量的空接口函數(shù)，不僅限制了系統(tǒng)的靈活性，而且增加了開發(fā)者的負擔。由于這些接口在實現(xiàn)中要經(jīng)過CORBA的IDL編譯器編譯出了樁碼和框架碼，即使實現(xiàn)為空也會帶來內(nèi)存開銷，造成系統(tǒng)浪費。因為小型設備通常功能比較單一，不需要支持豐富的操作，所以這種應用場景下空接口函數(shù)更會頻繁出現(xiàn)。

針對以上問題，本文采用了小粒度選擇性繼承的思想對核心框架的接口繼承關系進行了優(yōu)化，以降低各接口之間的耦合性，提高了核心框架的靈活性。

一方面，對封裝了較多功能函數(shù)的接口進行粒度細化，按照功能將其分裂成獨立的接口，每個接口具有原來的一部分接口函數(shù)，對應某種功能特點，以解除SCA中接口封裝帶來的繼承耦合，為選擇性繼承打下基礎。

另一方面，調(diào)整接口間的繼承關系，取消掉原來一些強制的繼承關系，設計成可以根據(jù)需要選擇性繼承的結(jié)構(gòu)，在IDL文件中描述接口繼承關系的時候使用宏定義的方式，針對不同應用場景通過開關宏的方式來選擇需要繼承的接口，避免繼承不需要的接口。最后，將選擇權(quán)交給用戶，不再只提供給用戶集成過的接口，對用戶開放更多基本接口，并由用戶來決定選擇繼承這些接口。

這種繼承關系優(yōu)化方法應用在了基本應用接口和基本設備接口兩類接口中。核心框架中的基本應用接口是一組描述應用組件屬性的接口，應用組件可以通過繼承并實現(xiàn)這些接口使應用組件具備對應操作。

根據(jù)SCA2.2.2規(guī)范，基本應用接口包括生命周期（LifeCycle）、端口獲取器（PortSupplier）、可測試對象（TestableObject）、屬性集（PropertySet）和資源（Resource）等，并設定了嚴格的繼承關系——Resource接口強制繼承了上述其他接口，具體的應用開發(fā)組件再繼承Resource接口，形成了一個耦合性極強的結(jié)構(gòu)，限制了子類必須繼承父類的相關操作，即使子類不需要對應功能。

本文在優(yōu)化設計中，首先對接口進行細化，將Resource中的函數(shù)start，stop分離出來，做成另外的可控制組件（ControllableComponent）接口，并且將Resource中的屬性identifier也獨立出來成為新的組件標識符（ComponentIdentifier）接口，另外Port和PortSupplier兩個接口合并成了端口存取器（PortAccessor）。

其次，改變接口間的繼承關系，設計Resource接口只繼承所有應用都必須支持的接口（如LifeCycle），不再強制繼承其他的功能性接口，而應用組件在繼承Resource的同時，可以根據(jù)實際需要選擇性繼承ComponentIdentifier、PortAccessor、ControllableComponent、TestableObject、PropertySet這五個接口中的若干，接口繼承關系如圖 1所示。

類似地，基本設備接口的繼承關系也按照選擇性繼承的思想進行了優(yōu)化，具體設計由于篇幅限制不再贅述

四、結(jié)束語

本文通過接口的裁剪和接口間繼承關系的優(yōu)化對SCA核心框架進行了改進，實現(xiàn)了輕量級核心框架，降低了資源需求和開發(fā)難度，有效提高了核心框架的靈活性，使其更適合資源受限的小型化設備等應用場景。

參 考 文 獻

[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] 唐麒.小型化軟件通信體系結(jié)構(gòu)的研究與實現(xiàn).學位論文.國防科學技術(shù)大學電子科學與工程學院，2011.