2009 Second Asia-Pacific Conference on Computational Intelligence and Industrial Applications

The Software Communication Architecture

Specification: Evolution and Trends
Guan Jianxin Ye Xiaohui Gao Jun Liu Quan
Department of Communication Engineering
Naval University of Engineering
Wuhan, P. R. China
[email protected]

Abstract-The Software Communication Architecture (SCA) such as Software Defined Radio Forum (SDRF) and Object
is the software architecture developed as the top design by the US Management Group (OMG).
Military's Joint Tactical Radio System (JTRS) for the next
generation of radio systems. The SCA is designed to facilitate The standardization is one of the key goals of the JTRS
waveform portability and improve software reuse in Software program and the process of the standardization is realized
Defined Radio (SDR). The SCA specification is built on the through the release of the SCA specification. Up to now the
evolving commercial standards, so it keeps evolving since its birth. highest version of the SCA specification is SCA 3.0, and the
Below the evolution process of SCA specification there are some latest is the SCA 2.2.2. In the evolution process of the SCA
hidden rules which are important for related researchers. In this specification some maturing technologies are adopted and
paper the rules are revealed through summarizing the evolution some rules are revealed. This paper will analyze the evolution
process and com paring the different versions of SCA process of SCA specification and reveal the underlying rules.
specification. The trends underlying the evolution process are Based on the rules this paper will farther discuss and forecast
forecasted too, which will help the researchers to grasp the the trends of the SCA specification, which will help the
correct research directions. researchers to grasp the correct research directions.
Index Terms-Software Communication Architecture (SCA); II. THE SOFTWARE COMMUNICATION ARCHITECTURE
Software Defined Radio (SDR); SCA specification; evolution;
trends Today's rapid pace of technological advances make
communication devices obsolete shortly after they are
I. INTRODUCTION produced. To keep up with this pace, communication systems
must be designed to maximize the transparent insertion of new
Software Defined Radio (SDR) has been an active research
technologies at virtually every phase of their lifecycles. When
topic in wireless communication since it was firstly proposed
the new technologies are inserted, the upgraded devices should
by Joseph Mitola [1] in 1992. The basic concept ofSDR is that
be able to communicate with each other and with legacy
the functions are implemented through loading different
systems. The SDR is the most suitable technology to resolve
software on the universal, standard and modularized hardware
this problem. Defining the radio behavior in software lets one
platforms. In the early SDR practices such as Speakeasy [2],
add new functionality without hardware alterations during a
GloMo [3] and DMR [4], the function of the radios could be
technology upgrade.
changed through loading different software, but the software
was not built on an open, common and standard infrastructure. In order to maintain interoperability, the radio systems must
So the benefits of ideal SDR such as waveform portability, be built upon a well-defined, standardized, open architecture.
software reuse and facilitating new technologies insertion Defming an architecture also enhances scalability and provides
couldn't be obtained. In order to establish a set of consistent plug-and-play behavior for the components of a radio. The
protocols and interfaces to manage, configure and control the Software Communication Architecture is such a common
SDR systems and simultaneously facilitate the waveform specification standard and component-based software
portability between hardware platforms from different vendors, framework/architecture defined by the JTRS Joint Program
the famous Joint Tactical Radio Systems (JTRS) program was Office (JPO) for SDR. The SCA is designed to facilitate
originated by US military to address these problems. As the waveform portability between different platforms and to
common software infrastructure of the SDR system and the top leverage commercial standards, frameworks and architectures
design of the JTRS program, the Software Communication to reduce development cost and improve reuse.
Architecture (SCA) is not only adopted as military
communication standards by many countries, but also adopted The SCA defmes an Operating Environment (OE) that will
as commercial and civilian standards by those organizations be used by JTRS radios. It also specifies the services and
interfaces that the applications use from the environment. The
interfaces are defined by using the Common Object Request

978-1-4244-4607-0/09/$25.00 ©2009 IEEE PACIIA 2009

341
Broker Architecture (CORBA) Interface Definition Language complete enough to implement and apply to a fielded software
(IDL) and graphical representations are made by using Unified radio system, although there are some contents which need to
Modeling Language (UML). The OE consists of a Core be clarified and corrected in this version. The other milestone
Framework (CF), a CORBA middleware , a POSIX-based should be noticed was that the version SCA specification 2.2.1
Operating System (OS), an Application Environment Profile was released in April 2004, almost three years after the SCA
(AEP) and a Domain Profile. The OS running the SCA must 2.2. One of the significant changes was that with version 2.2.1,
provide services and interfaces that are defined as mandatory in the Log Service was removed from the SCA specification and
the Application Environment Profile (AEP) of the SCA. the OMG Lightweight Log specification was referenced
instead.
The CF is the SCA essential "core" set of open software
interfaces and profiles that provide for deployment, At the same time, issues with waveform portability were
management , interconnection, and intercommunication of being raised through the on-going JTRS Cluster programs.
software application components in distributed embedded This portability issue came to a head in late 2004, resulting in
systems, using CORBA to communicate between entities. It several special workshops called by the Joint Program Office
describes the interfaces, their purposes and their operations and (JPO) to address the DSP and FPGA portability issue. The
provides an abstraction of underlying software and hardware result of these workshops was the SCA 3.0 specification.
layers for software application developers. An SCA compatible
The SCA 3.0 changed little of the core requirements
system must implement these interfaces. The interfaces are
describing the SCA. It did, however , define additional
grouped as Base Application Interfaces, Framework Control
constraints on DSP software related to what system calls could
Interfaces and Framework Services Interfaces. The CF uses a
be used by DSP code, defined a proposed set of waveform
Domain Profile to describe the components in the system. The
components, proposed a high-level data transport design
Domain Profile depicts the packaging and deployment of SCA-
(called HAL-C), and had an Antenna API section. After the
compliant hardware device and software component
implementation into the CF domain through describing these release of this version, the general reaction in the community
was that the specification required additional work and,
components , their properties, and interconnections. It is in the
form of a series of XML files that describe the individual although the concepts and approaches were potentially useful,
more detail and analysis was required in order to achieve a set
components of a software application, interconnections of the
components, components properties and properties of hardware of descriptions that could be implemented efficiently.
device abstractions . The CORBA middleware acts as a From late 2005 to early 2006, the JPO was reorganized to
software bus for all OE CORBA-capable components, address resolution of problems with the Cluster programs
providing a location transparent means of communication more effectively and move forward. In mid-2006, version
between these distributed entities. The AEP is defined by the 2.2.2 was released. As the number implies, this is an
SCA to provide minimum operating system functionality and incremental version from the 2.2.1 version of the SCA.
promote portability of component among different OSs. It is a Furthermore , the 3.0 version is shown on the JTRS website as
subset of the POSIX.13 Real-time Controller System Profile 'not supported. ' Thus, at the time of this publication, version
(PSE52). 2.2.2 is the latest release supported by the program office .
III. THE EVOLUTIONPROCESS OF SCA SPECIFICATION In mid-2004, the OMG released its Software Radio
Specification [7]. The OMG specification was initiated by a
As stated in the foreword of the SCA specification [5],
number of the individuals who had contributed to the SCA
the SCA specification is built on evolving commercial
development. The original objective was to evolve the SCA
frameworks and architectures. As same as other new
into an industry standard rather than a military only
technologies, the SCA specification keeps evolving since the
specification. However, as the specification evolved in the
first version SCA 1.0 was released in February 2000. Up to
OMG, it took on a life of its own with the resultant OMG
now the SCA specification has evolved to the highest version
specification being significantly different from the SCA
of SCA 3.0 from the initial SCA 1.0. Since the SCA 3.0 was
specification.
released in August 2004, there was no highest SCA version,
but the latest SCA 2.2.2 was released in August 2006. In IV. THE RULES UNDERLYING THE EVOLUTIONPROCESS OF
addition the SCA 3.0 is shown as not supported on the JTRS SCA SPECIFICATION
website. The important milestones in the evolution process of
SCA specification are shown in figure I [6]. The rules and After analyzing the evolution process of the SCA
trends underlying the evolution process are worthy of notice. specification and comparing the actual contents within the
several important versions, we acquire two points of revelation
4/04 8/04
sex 2.2. 1 sex 3.0
sc
8/06
2.2.2
as follows:
1 03 II 1 05 1/ A. Thefir st revelation
January 00 December 06
5/04
6/02
Cluster I Awarded O\ 1G So ftware Radio Spec The main content of the SCA 2.2.2 has some tremendous
Dtc/04-05-04
and important changes compared with the former versions.
Figure I. The milestones inthe evolution process ofSCA specification The main content of the SCA 3.0 and the former versions
includes several main parts such as software architecture ,
In the evolution process shown in figure 1 the SCA 2.2 hardware architecture and security architecture and the
should be noticed . This version was generally considered to be software architecture has two buses (one is red bus and the

342
other is black bus) as shown in figure 2[5]. The red bus is this supplement. The researchers had to tum back to
connected with the black one through a security module. But reconsider the SCA 3.0. As the result the SCA 2.2.2 was
there is only the software architecture in the SCA 2.2.2 and the released by JTRS JPO in August 2006 and the SCA 3.0
software architecture shown in figure 3 [8] is different from quickly became superfluous. In order to resolve the software
the formers. The reason for this change is obvious and easy to portability between the special hardware, with CORBA
understand. When the community tries to implement the SDR available for DSP and FPGA , we can communicate directly to
radios, if they adopt the architecture as shown in figure 2, those devices and use the in similar fashion as for general
there will be two sets of operating environment including purpose processor (GPP).
operating system, CORBA middleware, networking stack and
serial interface services and board support package. This will V. THE FORECASTED TRENDS OF THE SCA SPECIFICATION
not only aggravate the load for hardware but also the As stated in the previous section, the SCA specification is
complexity of software. Thus this can't help to achieve the built on the evolving commercial frameworks and
goals of JTRS program and reduce the costs of development architectures, so it will evolve along with those evolving
and maintenance. commercial architectures. The research and practice on SCA-
based SDR systems will greatly promote the development of
the SCA specification. In the evolution process there have
been some forecasted trends [10- I3], in which the most
common viewpoint is that the SCA specification will become
smaller and simpler. But some opinions were not correct
proved by the practice. For example, the forecasted trend in
reference [10] was proved wrong by the succedent fact.
Because the SCA specification didn't evolve to version 3.1
from version 3.0 to support the real waveform portability
between the heterogeneous processors, the SCA 3.0 was
(ORB .\ORBk (mUl.-\OKII&
~nir," "
"""IUI&:
quickly discarded and the SCA 2.2.2 was released.
,,,bU I,..utl .\pp.,IIO'" f\ liol.II". Ir" .\pp l.UIIU-'
Taking all the factors into account, we forecast there are
four trends of SCA specification in the future.
A. Thefirst trend
Figure 2. The SCA software architecture before SCA 2.2.2 The SCA specification can adopt more commercial
standards and architectures and evolve towards the direction of
smaller size and lower complexity. The SCA specification has
completely referred those OMG specifications such as
Minimum CORBA, Naming Service, Event Service, POSIX,
UML and XML. In the future more commercial standards can
be adopted by the SCA, so the SCA core framework will be
smaller, require less testing, and eventually support ultra light
Figure 3. The software architecture inSCA 2.2.2 weight deployments in small and low-power consumption
devices. The trend has been approved by the fact that
B. The second revelation Lightweight Logging API is removed out from the SCA
specification and refers to the corresponding OMG version.
The current technologies of waveform portability
between the special hardware are not mature. The Specialized In addition the OMG "Deployment and Configuration of
Hardware Supplement (SHS) [9] to SCA 3.0 which specifies Component-Based Applications" specifications (D+C) which
how to improve portability of software for processing was created to enhance the deployment model of CORBA
elements other than general purpose processors can be applied Component Model (CCM) can affect the evolution process of
to the non-CORBA components running on the specialized the JTRS SCA specification. Currently there is an overlap
hardware. This supplement specifies a hardware abstraction between the SCA specification and the D+C (with Lightweight
layer connectivity (HAL-C) specification, a reduced POSIX CCM) specifications. Moving forward , the JTRS JPO can
AEP for DSP environments, waveform functional blocks to be choose between two points to determine the path for the
provided as part of each radio set and an application interface evolution of the SCA specification. Figure 4 shows the
for antenna interfaces. The HAL-C specifies a series of APIs relationship between the SCA and the OMG specifications, as
through abstracting the interface for the communication well as the options for SCA evolution [14].
between components running on specialized hardware. The
The first option would be to continue making minor
communication can be achieved through invoking the well
modifications to the SCA and the relevant OMG specifications
defined API. This will greatly minimizes the effect of the
through change proposals. This would bring these
hardware platform 's communication mechanisms on the
specifications closer, thus increasing the COTS content of the
software design and reduces the probability of significant
SCA CF implementations. The burden of maintenance would
component rewrites during porting. The ideal was very good,
stay the same as this approach does not necessarily reduce the
but the current technologies couldn't meet the requirement of
size of the SCA specification. More beneficial results could be

343
achieved by the second option: explicitly referencing the specification is summarized. The different SCA specification
aforementioned OMO specifications in the SCA (like the versions are analyzed and compared. The rules underlying the
current SCA references the Lightweight Logging service). evolution process are revealed as follows: the main contents
have changed greatly and the current technologies of
waveform portability between the special hardware are not
matured. In addition the future trends of the SCA specification
are forecasted too, which will help the researchers to grasp the
correct research directions.
ACKNOWLEDGMENT
The paper is sponsored by science research fund of naval
university of engineering (No. HODJJ07017). Thanks for the
support from this fund.
past present future
REFERENCES
Figure 4. The relationship between the SCA and the OMG specification, as [I] Mitola Joseph. "Software Radio: Survey, Critical Evaluation and Future
well asthe options for SCA evolution Direction". Proceedings ofNational TelesystemConference, New York,
IEEE Press, May 1992.
Altogether, in the future versions of the SCA [2] Peter G. Cook and Wayne Bonser. Architectural Overview of the
specification, D+C and Lightweight CCM can be explicitly SPEAKeasy System. IEEE Journal on Selected Areas in
referenced to take the full advanced features such as Communications, Vol. 17, No.4, April 1999, pp. 650-661.
hierarchical assemblies of components. [3] Barry M. Leiner, Robert J. Ruth and Ambatipudi R. Sastry. Goals and
challenges of the DARPA GloMo program, IEEE Personal
B. The second trend Communications, Vol.3, No.6, December 1996, pp.34-43.
The future SCA core framework will be smaller and [4] Byron Tarver, Eric Christensen, Annamarie Miller and Elisa R. Wing
Digital modular radio (DMR) as a maritime/Fixed joint tactical radio
faster. The reference [II] disproved those opinions such as system (JTRS). IEEE Military Communications Conference, No. I,
SCA is slow to boot, SCA applications are slow and SCA is October 2001 , pp.163-167.
too fat. At the same time, the author thought the goals of [5] Modular Software-programmable Radio Consortium. Software
smaller and faster core framework could be achieved through Communications Architecture Specification. MSRC-5000SCA, V2.2,
task optimization and static deployment optimization. November 17, 200 I.
Considering the author's leading status in SCA core [6] John Bard, Vincent J. Kovarik Jr. Software Defined Radio--The
framework research and development, we think this trend is Software Communications Architecture. John Wiley & Sons Press. May
2007.
completely feasible.
[7] Object Management Orgnization. PIM and PSM for Software Radio
C. The third trend Components Final Adopted Specification. May 2004.
[8] Joint Tactical Radio System (JTRS) Joint Program Executive Office
The SCA infrastructure will be restructured to allow it to (JPEO). Software Communications Architecture Specification. Version
be tailored to accommodate a wider range of deployment 2.2.2, May 15, 2006.
environments. The current SCA infrastructure is oriented [9] JTRS JPO. Specialized Hardware Supplement to the Software
towards a OPP environment. The future SCA infrastructure Communication Architecture (SCA) Specification. JTRS-5000 SP V3.0.
will be extended to support a wider set of operating 27August 2004.
environments. Candidate approaches for such extensions [IO] Jeff Smith, David Murotake and Antonio Martin. Software
include ORB utilization in non-OPP processing environments, Communication Architecture: Evolution and status update. Military
Embedded Systems. October 2005. pp.28-31.
the introduction of a FPOAIDSP container model or [II] Steve Bernier and Claude Belisle. TAKING THE SCA TO NEW
leveraging specifications targeted for system on chip design FRONTIERS. Proceeding of the SDR 06 Technical Conference and
[15]. Product Exposition. http://www.sdrforum.org/pages/sdr06/sdr06 papers
/2.6/2.6-02.pdf.
D. Thefourth trend
[12] Neli Hayes. The JTRS SCA Specification--the Past, The Present, and
JTRS API will evolve to provide a wider array of The Future. IEEE Military Communications Conference, Vo1.5, October
platform interfaces. Except the existing smart antenna API, 2005. pp.27I3-2719.
more communication domain specific APls including the [I3] S. Murat Bieer, Frank Pilhofer, Graham Bardouleau and Jeffrey Smith.
digital intermediate frequency API [16] will be proposed. Next Generation Architecture for Heterogeneous Embedded Systems.
http://www.fpx.de/Publ ications/ersa03.pdf.
VI. CONCLUSION [14] Murat Bicer, Jim Kulp and Frank Pilhofer. Increasing the COTS Content
ofthe SCA. http://www.mc.com
The SCA specification is a new thing and has not [I5] Donald R. Stephens, Brian Salisbury, Kevin Richardson. JTRS
matured until now. So it keeps evolving since its birth. Infrastructure Architecture and Standards. IEEE Military
Because the SCA specification is built on the evolving Communications Conference, October, 2006. pp.I-5.
commercial standards and architectures, it will continue [16] http://www.digital IF.org.
evolving. In this paper the evolution process of the SCA

344