sca next part 1 - software defined radio (sdr) webcast slides
DESCRIPTION
SCA To Date and Motivation for Change. These slides will discuss why the JTRS Program Executive Office (JPEO) is aggressively procuring Software Defined Radio (SDR) consortium and industry assistance to spearhead a high impact evolution of the Software Communications Architecture (SCA) intended to deliver better radio performance along with a smaller footprint for waveforms and radio software. The webcast audience will learn about innovative SCA change proposal details and identified opportunities for near term radio performance impact with rapid market availability of these new capabilities via highly motivated COTS SDR software and development tool vendors.TRANSCRIPT
The Evolution of the SCA
SCA Next
November 10, 2010
Outline
Personal Introduction
Objectives
Background and History
SCA Next Overview
Overview of SCA Next Changes
Summary
PrismTech Products
References and Resources
Contact Information
2
Vince Kovarik
Academic and Publications:B.S & M.S. Computer Science, Ph.D. Computer Engineering
Co-author with John Bard “Software Defined Radio: The Software Communications Architecture”, Wiley and Sons
Chapter author for “Cognitive Radio Technology”, by Dr. Bruce Fette
Awarded three patents
1980s: Harris and Software Productivity SolutionsExperience in Natural Language Understanding, Knowledge Representation and Acquisition and Temporal Reasoning.
Initial OO design with Rumbaugh OMT, Booch OOD, and Jacobsen Use Cases.
Development work in Smalltalk, LISP Flavors, and C/C++
1990s: STI/ExigentInitial CORBA work as Chief SW Architect for the Ground Segment of Satellite Command and Control System for IRIDIUM, a large-scale distributed system.
Started work in SDR in late 90’s as a member of the MSRC.
Domain Management ToolKit (dmTK) product manager, the first commercially available implementation of the SCA.
2001: Harris purchases ExigentdmTK used as initial reference implementation by JTeL and Aeronix for JTAP development.
SW Architect for the insertion of the DARPA XG DSA software into the Falcon III Tactical Radio and demonstration.
Member of the Government Reference Architecture (GRA) team developing a SysML/UML reference model for SATCOM terminal systems.
Member of the SDR Forum Wireless Innovation Forum since 2000. Currently chair of the Technical Committee on Advanced Wireless Networking and Infrastructure.
3
Objectives
This is the first of a series of technology-oriented presentations on the SCA and SDR.
The objective of this presentation is to provide:
a historical overview of the SCA and
an overview of the SCA Next initiative
Presentations on PrismTech’s products in support of the SCA Next and other technology topics will be forthcoming.
4
Background
Despite rumors of its demise, SCA is alive and well.
SCA has been applied successfully to a variety of radio systems including:
JTRS programs of record
International radio systems
Independently developed products
The international community has been moving forward with SCA, e.g. ESSOR and other programs.
5
However…
The successes have not been without some problems.
Limited portability of waveforms
Inadequate abstraction of DSP and FPGA
Non-standard Device interfaces for common radio devices, e.g. AudioPort
Footprint and performance
6
A (partial) SCA/SDR History
1990 2000 2010
Bo
och
‘91
Ru
mb
au
gh
OM
T-1
OO
PS
LA
Un
ifie
d M
eth
od
0.8
Un
ifie
d M
eth
od
0.9
OM
T-2
Bo
och
‘93
Jaco
bso
nO
OS
E
UM
L 1
.0
OO
SD
RA
rch
Sp
ea
kEa
sy-1
Sp
ea
kEa
sy-2
MS
RC
JCIT
SC
A 2
.2CO
RB
A
CC
M
CO
RB
AS
vcs
UM
L 2
.0
MD
A
MO
F
Sys
ML
1.0
Sys
ML
1.1
CO
RB
AII
OP
GN
UR
ad
io
US
RP
UM
L 2
.3
WD
L
So
C
MA
RT
E
LW
Lo
g
FM
3T
RIm
pl
FM
3T
R
OM
G
SD
RF
oru
m
CO
RB
A 2
JTR
S
SC
A 2
.2.2
SC
A C
FIm
pl
Co
gn
itive
Ra
dio
DS
A
OC
L
OM
G
an
dN
CO
SE
SC
A 2
.2.1
7
???
A (partial) SCA/SDR History – Enablers
1990 2000 2010
Bo
och
‘91
Ru
mb
au
gh
OM
T-1
OO
PS
LA
Un
ifie
d M
eth
od
0.8
Un
ifie
d M
eth
od
0.9
OM
T-2
Bo
och
‘93
Jaco
bso
nO
OS
E
UM
L 1
.0
OO
SD
RA
rch
Sp
ea
kEa
sy-1
Sp
ea
kEa
sy-2
MS
RC
JCIT
SC
A 2
.2CO
RB
A
CC
M
CO
RB
AS
vcs
UM
L 2
.0
MD
A
MO
F
Sys
ML
1.0
Sys
ML
1.1
CO
RB
AII
OP
GN
UR
ad
io
US
RP
UM
L 2
.3
WD
L
So
C
MA
RT
E
LW
Lo
g
FM
3T
RIm
pl
FM
3T
R
OM
G
SD
RF
oru
m
CO
RB
A 2
JTR
S
SC
A 2
.2.2
SC
A C
FIm
pl
Co
gn
itive
Ra
dio
DS
A
OC
L
OM
G
an
dN
CO
SE
SC
A 2
.2.1
8
???
Early SDR work.
Early OO Modeling and Design
Methodologies.
Enabling standards and organizations.
A (partial) SCA/SDR History – Critical Mass
1990 2000 2010
Bo
och
‘91
Ru
mb
au
gh
OM
T-1
OO
PS
LA
Un
ifie
d M
eth
od
0.8
Un
ifie
d M
eth
od
0.9
OM
T-2
Bo
och
‘93
Jaco
bso
nO
OS
E
UM
L 1
.0
OO
SD
RA
rch
Sp
ea
kEa
sy-1
Sp
ea
kEa
sy-2
MS
RC
JCIT
SC
A 2
.2CO
RB
A
CC
M
CO
RB
AS
vcs
UM
L 2
.0
MD
A
MO
F
Sys
ML
1.0
Sys
ML
1.1
CO
RB
AII
OP
GN
UR
ad
io
US
RP
UM
L 2
.3
WD
L
So
C
MA
RT
E
LW
Lo
g
FM
3T
RIm
pl
FM
3T
R
OM
G
SD
RF
oru
m
CO
RB
A 2
JTR
S
SC
A 2
.2.2
SC
A C
FIm
pl
Co
gn
itive
Ra
dio
DS
A
OC
L
OM
G
an
dN
CO
SE
SC
A 2
.2.1
9
???Modular Software Radio Consortium:
Circa late 1990sInitial origins of the SCA
Early work on waveform and OO SDR architectures
and design.
Stable design formalism.
A (partial) SCA/SDR History – Initial Projects
1990 2000 2010
Bo
och
‘91
Ru
mb
au
gh
OM
T-1
OO
PS
LA
Un
ifie
d M
eth
od
0.8
Un
ifie
d M
eth
od
0.9
OM
T-2
Bo
och
‘93
Jaco
bso
nO
OS
E
UM
L 1
.0
OO
SD
RA
rch
Sp
ea
kEa
sy-1
Sp
ea
kEa
sy-2
MS
RC
JCIT
SC
A 2
.2CO
RB
A
CC
M
CO
RB
AS
vcs
UM
L 2
.0
MD
A
MO
F
Sys
ML
1.0
Sys
ML
1.1
CO
RB
AII
OP
GN
UR
ad
io
US
RP
UM
L 2
.3
WD
L
So
C
MA
RT
E
LW
Lo
g
FM
3T
RIm
pl
FM
3T
R
OM
G
SD
RF
oru
m
CO
RB
A 2
JTR
S
SC
A 2
.2.2
SC
A C
FIm
pl
Co
gn
itive
Ra
dio
DS
A
OC
L
OM
G
an
dIN
CO
SE
SC
A 2
.2.1
10
???
Circa 2002 JTRS Program initial award of
Cluster 1 – Ground Mobile Radios (GMR)
Stable release of SCA released in November 2001
Development of Meta-Object Facility
Collaboration initiated with International Council on Systems Engineering to develop Systems
Modeling Language (SysML)
A (partial) SCA/SDR History - Maturation
1990 2000 2010
Bo
och
‘91
Ru
mb
au
gh
OM
T-1
OO
PS
LA
Un
ifie
d M
eth
od
0.8
Un
ifie
d M
eth
od
0.9
OM
T-2
Bo
och
‘93
Jaco
bso
nO
OS
E
UM
L 1
.0
OO
SD
RA
rch
Sp
ea
kEa
sy-1
Sp
ea
kEa
sy-2
MS
RC
JCIT
SC
A 2
.2CO
RB
A
CC
M
CO
RB
AS
vcs
UM
L 2
.0
MD
A
MO
F
Sys
ML
1.0
Sys
ML
1.1
CO
RB
AII
OP
GN
UR
ad
io
US
RP
UM
L 2
.3
WD
L
So
C
MA
RT
E
LW
Lo
g
FM
3T
RIm
pl
FM
3T
R
OM
G
SD
RF
oru
m
CO
RB
A 2
JTR
S
SC
A 2
.2.2
SC
A C
FIm
pl
Co
gn
itive
Ra
dio
DS
A
OC
L
OM
G
an
dN
CO
SE
SC
A 2
.2.1
11
???
•SCA 2.2 refined and stable. •JTRS APIs developed.•Initial field testing of JTRS radios.•Development of SCA compliant and JTRS certified radios not developed independently of JTRS program.
Development of SysML to bridge gap between System and Software Engineering.
UML Profiles extend capabilities to capture more domain-specific modeling.
A (partial) SCA/SDR History – Now
1990 2000 2010
Bo
och
‘91
Ru
mb
au
gh
OM
T-1
OO
PS
LA
Un
ifie
d M
eth
od
0.8
Un
ifie
d M
eth
od
0.9
OM
T-2
Bo
och
‘93
Jaco
bso
nO
OS
E
UM
L 1
.0
OO
SD
RA
rch
Sp
ea
kEa
sy-1
Sp
ea
kEa
sy-2
MS
RC
JCIT
SC
A 2
.2CO
RB
A
CC
M
CO
RB
AS
vcs
UM
L 2
.0
MD
A
MO
F
Sys
ML
1.0
Sys
ML
1.1
CO
RB
AII
OP
GN
UR
ad
io
US
RP
UM
L 2
.3
WD
L
So
C
MA
RT
E
LW
Lo
g
FM
3T
RIm
pl
FM
3T
R
OM
G
SD
RF
oru
m
CO
RB
A 2
JTR
S
SC
A 2
.2.2
SC
A C
FIm
pl
Co
gn
itive
Ra
dio
DS
A
OC
L
OM
G
an
dN
CO
SE
SC
A 2
.2.1
12
SCA Next
•Initiation of SCA Next activity in Wireless Innovation Forum.•Participants represent a cross section of the SCA community.•Collaboration with the JTRS Joint Program Executive Office (JPEO)
•Initial joint meeting of JTRS JPEO and WInF held August 2010 in Washington, DC•Initial SCA Next rollout at the WInF SDR10 conference
Les
son
s L
earn
ed
SCA Next Goals and Objectives
Reduce Development ResourcesModification to support more reusability
Reduce Test and Certification TimeThe cost of certification is substantial and labor intensive.
Improve PerformanceStreamline initialization and deployment
Incorporate Lessons LearnedApply knowledge gained through experience on existing programs
13
Independent Effort
SCA Next is not a formal project
Strong support within the communityJTRS participants
Wireless Innovation Forum
Independent contributors
Approximately 60 changes were submitted23 selected for resolution
14
Focus Areas
Platform Independent Specification
Increase Compliance Points
Better Component / Interface Separation
Better Integration of Systems and Software
Address Recurring Issues in Design and Deployment
15
Active Change Requests
Requirements Revision
Enhance Automated Testing
Deployment Optimization
Lightweight Components
CORBA Neutral / Evolution
Architecture Consistency
Application Enhancements – Nested Apps
16
Active Change Requests
Application Enhancements – Interconnected Applications
Recommended C++ Features
Interface Definition Language (IDL) Refactoring
Lightweight AEP
Service Deployment and Initialization
Component Model
Developer’s User Guide
17
Requirements Revisions
Enhanced Automated Testing
Reviewed 123 of 484 OE requirements that do not have an automated test in JTAP and assigned to one of three categories:
Automatable (29 w/ 1 approved)
Consider for re-write (58 may not be possible)
Consider for removal (27 w/ 3 approved)
18
Automated Testing Issues
Some requirements are difficult if not impossible to force the test condition, e.g.
Raise FileException error on remove operation when a file-related error occurs.
Early versions of JTAP attempted to induce a file-related error by removing the file through a O/S command after opening through the CF::FileSystem.
File is not removed until all processes that have an active handle to the file exit.
19
Push Registration and Static Ports
One of the more significant areas of proposed changes.
Basic concept is to provide all necessary data with the registration call rather than utilize “pull” calls from the component receiving the registration call.
Provides Ports may be defined as “static”, i.e. the lifecycle of the Port is tied to the lifecycle of the component and registered with the CF on instantiation.
20
Static Deployment
Optimize deployment for “known” radio systems and waveforms.
Generate a static IOR for the Provides Port as part of the build process that maps to the target platform.
The static IOR provides a priori knowledge during system boot and waveform instantiation eliminating lookup in the Name Service or other repository.
Application instantiation time is streamlined by directly connecting the components through the static IORs.
Impact to tools, build process and core framework.
21
CORBA Neutral Representation
Remove CORBA specific wording
Modify SCA interface representation (UML) to one that can be mapped to other technologies
Define mapping rules to create existing SCA equivalent.
Define mapping rules for a alternate technology.
22
CORBA Neutral Challenges
Refactor the current specification into a well-formed UML model.
Developed the initial transformation of the UML-based model into the equivalent CORBA model (PIM PSM)
Develop second transformation that accurately maps into an alternate technology
23
CORBA Evolution
Objectives are to define profiles that: Reduce resources,
Allow more freedom to platform designers while still promoting portability
Include widely used features
The profiles would apply to applicationsThe CF, Devices and Services may use (and may require) additional features.
Starting point is Minimum CORBA and CORBA/e
24
Full and Lightweight Profiles
Two profiles planned.
Full – Provides features for general platforms and applications
Lightweight – Provides minimal features for highly constrained resources.
25
Summary of Features
Allow additional ORB_init parameters to create a rootPOA with static, non-default policy settings.
Any type only allowed in Full profileDeprecate use of Any and other complex types
26
Full Profile
Similar to CORBA/e with some minor features removed
Some features added such as:Thread Pools
Sever Security Model
Server and Client ProtocolPolicy
Many of the added features are supported by current ORB vendors including PrismTech
27
Lightweight Profile
Eliminates the Any type and, consequently, does not support the Resource or PropertySet interfaces
Only CORBA/e Basic types are recommended – intended to enhance compatibility with FPGAs.
Minimum management calls supported.
28
Lightweight Components
Basic concept is to support only those interfaces required for a particular object implementation.
Considered optional Realization and Inheritance relations.
Preferred approach was to use optional inheritance to a common base interface, e.g. Resource.
The waveform component would Realize the Resource interface which would have optional inheritance of other interfaces.
29
Resource Interfaces
Lightweight components provide an optional cardinality [0..1] to the generalization/specialization association.
Additional interface changes and refactoring of IDL is proposed within this area.
Potential impact may be significant.
30
class Resource Interface
«CORBAInterface»Resource
+ identifier: string
+ start() : void+ stop() : void
«CORBAInterface»PropertySet
+ query(configProperties :Properties) : void+ configure(configProperties :Properties*) : void
«CORBAInterface»PortSupplier
+ getPort(name :string) : Object
«CORBAInterface»LifeCycle
+ initialize() : void+ releaseObject() : void
«CORBAInterface»TestableObject
+ runTest(testid :unsigned long, testValues :Properties*) : void
Wav eform Component
Optional inheritance
IDL Refactorization – Current IDL 31
class CF Interfaces
«CORBAInterface»PropertySet
«CORBAInterface»Dev ice
«CORBAInterface»Dev iceManager
«CORBAInterface»Resource
«CORBAInterface»LifeCycle
«CORBAInterface»PortSupplier
«CORBAInterface»LoadableDev ice
«CORBAInterface»ExecutableDev ice
«CORBAInterface»ApplicationFactory
«CORBAInterface»ResourceFactory
«CORBAInterface»File
«CORBAInterface»FileSystem
«CORBAInterface»FileManager
«CORBAInterface»Port
«CORBAInterface»AggregateDev ice
«CORBAInterface»Application
«CORBAInte...TestableObject
«CORBAInterface»DomainManager
uses
uses
uses
uses
uses
uses
uses
IDL Refactorization
The OMG SW RADIO specification used as a starting point
Develop separate IDL files for various elements, e.g. Device, LoadableDevice, etc.
Minimize the amount of CORBA stub code generated and thereby reduce footprint
Retain backward compatibility with the current IDL by incorporating the individual files in a “CF” module
32
Summary
SCA Next represents a significant shift in the SCA community.
It has been initiated and performed largely by individuals and companies involved with the SCA or the JTRS program.
It has been a collaborative effort between the industry participants and the JTRS JPEO.
It is intended to be an open, international standard.
More work is required to bridge the gap between a recommendation and incorporation into the standard
33
Spectra Support for SCA Next
ORBCORBA/e Profile
Enhanced performance through zero copy
High-Performance transport
C and C++ ORB support
Core FrameworkStatic deployment and device assignment sequence
IDL refactorization
Static deployment
Push registration
Spectra CX Development ToolCORBA neutral representation
C/C++ code generation
Testing automation
34
Spectra CX Tool 35
Spectra OE Studio 36
DSP
e*ORBC & C++
FPGA
e*ORB C ICO
Spectra OE Flexible ArchitecturesSpectra OE Flexible Architectures
Extensible Transport FrameworkExtensible Transport Framework
Waveform Component
Waveform Component
Waveform Component
GPP DSP FPGA
CoreFramework
DSP
e*ORBC & C++
FPGA
e*ORB C ICO
Spectra OE Flexible ArchitecturesSpectra OE Flexible Architectures
Extensible Transport FrameworkExtensible Transport Framework
Waveform Component
Waveform Component
Waveform Component
GPP DSP FPGA
CoreFramework
DSP
e*ORBC & C++
FPGA
e*ORB C ICO
Spectra OE Flexible ArchitecturesSpectra OE Flexible Architectures
Extensible Transport FrameworkExtensible Transport Framework
Waveform Component
Waveform Component
Waveform Component
GPP DSP FPGA
CoreFramework
DTP4500 Architecture 37
DTP4500 Hardware 38
Mistral Board with OMAP 35xx
TransceiverRF Front End
References and Resources 39
SCA: http://sca.jpeojtrs.mil/sca.asp
SCA Next: http://sca.jpeojtrs.mil/scanext.asp
JTRS APIs: http://sca.jpeojtrs.mil/api.asp
JTRS Portability Guidelines: http://sca.jpeojtrs.mil/_downloads/20091228_1.2.1_NEDTE_PORT_GUIDE.pdf
Note: This is a single, large PDF file.
Next Technology Webcast
When: January 2011
Objective: Explore one or two SCA Next topics in more detail.
Discuss impact and interaction with tooling, development and deployment
Your input is appreciatedForward questions and topic suggestions to:
With “SCA Next Webcast” in the subject
40
For Information on Products and Services: 41
E-mail:[email protected]
www:www.prismtech.com/spectra
Your PrismTech account manager
42
Thank You
Any Questions?