Joint Tactical Radio System - Space Coast Communication Systems

Transcription

Joint Tactical Radio
System
John D. Bard, Ph.D.
Space Coast Communication Systems, Inc.
100 Rialto Place
Suite 730
Melbourne, FL 32901
W +1 (321) 951-8320
F +1 (321) 951-9920
[email protected]
http://www.spacecoastcomm.com/
Copyright 2003, Space Coast Communication Systems, Inc.
1
Table of Contents
•
•
•
•
•
•
•
•
JTRS –Today and Tomorrow
JTRS Technology Challenges
JTRS 101 - Understanding SDR
JTRS Clusters
The Software Communications Architecture
JTRS Compliance
JTRS Waveform Applications
JTRS Lessons Learned
2
JTRS Mission Statement
•
•
•
•
Provide a family of interoperable radio sets
Capable of loading multiple waveforms
Support Joint operations
Capability to transmit, receive, bridge, and gateway
between
–
–
–
–
waveforms
network protocols
across service boundaries
voice, video, and data
• Allow collaboration between commanders and staffs
• Perform the same functions and missions supported by
the legacy radios
3
A View of JTRS
Homeland Security
Space
Airborne Cluster
Cluster 3 (Maritime/Fixed site)
Cluster 2 (Handheld/Manpack)
Cluster 1 (Grd, Veh, Helo)
Subsurface
< 2 MHz
2 MHz – 2 GHz
2 - 4 GHz
4–15/45 GHz
and beyond
Object Management Group (OMG) (approx. 950 Int’l members)
Software Defined Radio Forum (SDRF) (approx. 100 members)
SCA Foundation
Definition SCA 1.0 SCA 2.0 SCA 2.1 SCA 2.2
2003,
CopyrightCopyright
2002, SDR
Forum
SCA X…n
4
Background and Current Status of
JTRS
• Architecture Study, 1998
– General Dynamics Decision Systems Team
– Raytheon Team
• Architecture Definition, Step 2A,’99-’01
– Raytheon Team, > 5 team members
• Architecture Validation, Step 2B,’00-’02
– Multiple, > 6 Awards plus Follow-On
• Cluster One Award, 2002
– Boeing - Anaheim, Prime Integrator
– H/W&S/W Providers, Collins & BAE Systems
5
Prototypes from Step 2A
Proto
Quantity
(2)
Proto-type
Name
(LRIP
Domain)
Supplier
VDM
Raytheon
(M/F,V,AS,AT)
Dismounted
(AS,AT)
2 WB +
2 NB +
GPS
Cornfield
Module:
KY-57/58,
KGV-11DAMA,
Partial KG-84,
TRANSEC: HQ,
KGV-10
KY-57, KYV-5
KGV-10,Baton
30 – 450
2WB or
2NB
+GPS
Marconi
6U
19”Rack
/CPCI
2 – 2000
4
NB/WB
+GPS
CTIC- cPCI
module
Rockwell
SEM-E,
6u
19”Rack
/VME
2 – 2000
4 NB
+GPS
External KY-100
(GFE)
(M/F,V,AS)
Airborne
(1)
3U and 225 - 1000
WB
6U 19"
rack 2 - 2000 NB
/CPCI
INFOSEC
PC-104
/PC104Plus
(V,D)
Fixed
Frequency No. of
Channels
Range
(MHz)
ITT
(2)
(1)
Form
Factor
/Bus
COTS
Processor,
Operating
System,
CORBA
Pentium
VxWorks
ORB-Express
(2.2)
Modem
DSP
Waveforms
C549
Pentium
VxWorks
ORB-Express
(2.2)
PowerPC
VxWorks
ORB-Express
(2.2)
PowerPC
LynxOS
ORB-Express
(2.2)
C54X
VHF-AM, VHF-FM,
VHF-ATC,
VHF-Public Service,
UHF-HQI/II, UHF
DAMA/DASA, ASPENWB, (HF-ALE), (Partial
SINCGARS ASIP/INC)
Partial SINCGARS
ASIP/INC,
ITT-WB
C44
VRC-99,
(VHF-FM)
C6X
HF-ALE
(VHF-FM)
6
JTRS Program Schedule
FY00
FY01
FY02
FY03
FY04
FY05
FY06
FY07
FY08
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
Concept &
Tech Devel
SCA
v1.0
Risk Reduction
& Demonstration
V2.0
Architecture Development
Lead Test Lab
Selection
System Demonstration
& Deployment
Sustainment
SCA Maintenance
V2.1, V2.2 . . .
Architecture Evolution
JTRS Waveform Application Library
Waveform
Waveform
Waveform
Waveform
Architecture Validation
Software Radio Validation
Waveform
Waveform
JTRS Step 2B / 2C Prototypes
Cluster 1 (Ground Vehicular, Rotary Wing, TACP)
MBMMR & MBITR Development
MBITR - SCA
Cluster 2 (Handheld)
Cluster 3 (Maritime/Fixed-Site)
Cluster 4 (Airborne)
Space Study
Effort
Complete
Future Cluster 5 (Embedded)
Future Cluster 6 (High Data Rate)
PolicyInc.
Change
Copyright 2003, Space Coast Communication Systems,
7
JTRS Operational Requirements
Document
• Operational Concept
– Decrease the Types of Tactical Radios
– Replace Radios Inadequate for Network Centric
Warfare
– Address Interoperability Issues
– Support Tactical Networks within the Global
Information Grid
– Support Self-organizing, self-healing networks
– Must interconnect higher level (backbone) nets to
lower level (local area) nets
– Must be flexible for future requirements
8
Document
• Key Performance Parameters (KPP’s)
– Have Internal Growth Capability in Accordance with
Joint Technical Architecture (JTA)
– Operator Reconfigurable (H/W and S/W)
– Multi-channel routing and retransmission capable
(voice, video and data)
– Support Time Critical Waveforms
– Scalable, Extensible, Interoperable Networks
– Operational Availability > 0.96 T, >0.99 O
9
Document
• Internal Growth Capability
– Open Systems Architecture
– JTA identifies specific commercial standards
– Flexible Form Factor
• Operator Configurable
– Link like-mode operational nets
• Time Critical Waveforms
– SINCGARS, HAVEQUICK, DAMA, EPLRS, etc.
– 2 MHz to 2 GHz
– Multiple full or half duplex channels
10
Document
• Scalable Networking Services
– Protocol Conversion between Dissimilar
Systems
– Accept Software Upgrades with Integrity and
Authentication over the air
• Joint Information Exchange Requirements
– 16 Types of Information Exchange Req’d
– Example: Over-The-Air Rekey (OTAR)
11
Document
• Network Extension / Reconfiguration
– Point-to-Point and Point-to-Mutli-point and
Multi-cast (<100 selected nodes)
– Support Connectivity to US Military, US
Civilian and Cell Networks
– Automated Network Reconfiguration
– Reconfigure 150 JTR Sets in 15 Minutes
– Support IP communications
– Provide tools to report network status
12
JTRS Channel Requirements
•
•
•
•
US Army
173,050 channels
US Air Force 44,854 channels
US Navy
4307 channels
US Marines 38,380 channels
Latest Considerations
• Public Safety/Homeland Security ~106 channels
13
The Role of JTRS in WIN-T
•
Warfighter Information Network - Tactical (WIN-T)
– Command, Control, Communications, Computers, Intelligence,
Surveillance, and Reconnaissance (C4ISR)
– Mobile, secure, survivable, seamless, and capable of supporting
multimedia tactical information systems
– Optimized for offensive operations
– Operates across increased strategic distances
–
–
–
–
–
Dispersed operations through global virtual teaming
Dynamically adaptive to mission, task and purpose
Connectivity with higher throughput
Interoperability for joint and coalition operations
Enable “sensor-to-shooter” networking
14
The Role of JTRS in WIN-T
JTRS and WIN-T are fully integrated
– Unified in Objective Force (OF) concepts
– JTRS reduces the commander’s dependence on lineof-sight and terrestrial relays
– JTRS gets the communication relays off the hilltops
– Seamless communications and information system Tactical Infosphere
– Increasing deployability, versatility, agility, lethality,
survivability and sustainability of Objective Force
15
Status of WIN-T
Two Vendor Teams
– Lockheed Martin
• Harris Corp., Cisco Systems Inc., ACS Defense Inc., SRI International, CACI Inc.,
Innovative Logistics Techniques Inc. and Integrated Solutions Inc
– General Dynamics
• BAE Systems, BBN Technologies, DynCorp, Northrop Grumman Information
Technology, Rockwell Collins Inc., Research Triangle Institute, Veridian Corp.
•
Three Year Contract – Two Phases
– Phase One (12 months) - define WIN-T architecture
• Focus on risk management, technology readiness
• Coordination with FCS, the Joint Tactical Radio System (JTRS)
– Phase Two (23 months)
• Test a simulation of the WIN-T architecture and
• Develop a prototype system for Army users to test.
• Early user tests ~ fiscal 2005
16
The Role of JTRS in FCS
Future Combat System (FCS)
• Develop network centric concepts for a multi-mission
combat system
• Use of an ensemble of manned and unmanned ground
and air platforms
• Optimize Balance of
–
–
–
–
Ground platform strategic, operational and tactical mobility
Lethality
Survivability
Sustainability
• System of systems design
– Accomplished using modeling, simulation & experimentation
17
• Capabilities
–
–
–
–
FCS
Autonomous robotic systems
Precision direct and indirect fires
Airborne and ground organic sensor platforms
Adverse-weather reconnaissance, surveillance,
targeting and acquisition
• Program Plan
– Concept and Technology Development (CTD)
• Boeing - Lead Systems Integrator
– System Design and Demonstration (SDD)
– Production - 2010
18
• 11 of 16 contracts awarded are communications
related
– BAE Systems, Directional antennas for LPI/AJ
– Scalable Network Technology, Inc., High-fidelity scalable network
simulation
– Collins, 35-GHz beam-former, active- array antenna, JTRS-compliant
OFDM digital receiver architecture
– Raytheon, JTRS-compliant Ultra Comm software-defined radio, media
access control (MAC) protocols that exploit directional antennas
– Northrop-Grumman, wideband, millimeter-wave radio
– BBN, Utilizing Directional Antennas for Ad-hoc Networking (UDAAN)
– Ball Aerospace, polymide microelectromechanical systems (PMEMS)
2-D scanned surface technology antenna
19
• 11 of 16 contracts awarded are
communications related (cont’d)
– Titan/Atlantic Aerospace Corporation, UHF array
over a high impedance surface
– Georgia Institute of Technology Research Institute,
micro-switched percolating reconfigurable aperture
development
– General Dynamics, high-capacity, low probability of
detection technologies
– Ipitek, low phase-noise millimeter-wave source
20
The Role of JTRS in GIG
• Global Information Grid
– Implements Joint Vision 2010
•
•
•
•
Dominant maneuver
Precision engagement
Full dimensional protection
Focused logistics
– GIG Architecture (v1.0)
– Single Architecture - Three views:
• Operational Architecture (OA) View
• Systems Architecture (SA) View
• Technical Architecture View (TA)
– The TA view is the Joint Technical Architecture (JTA)
21
The Role of JTRS in JTA
• Joint Technical Architecture
– Technical View of the Global Information Grid
– Defines the service areas, interfaces, and standards
applicable to all DoD systems
• Two Parts
– JTA Core and JTA domains
• Domains: C4ISR, Combat Support, Modeling and Simulation;
and Weapon Systems, Intelligence, Surveillance and
Reconnaissance (ISR)
• JTA standards identify commercial off-the-shelf
implementations available from multiple vendors
– Elements of JTRS SCA all called out in the JTA,
namely POSIX and CORBA
22
The Role of JTA in JTRS
• Architectural Views
– Operational, Systems & Technical
23
The Big Picture
• Interoperability Path Forward
–
–
–
–
–
WIN-T – the bandwidth to interoperate
Military Satellite Communications – key enabler
JTRS – interoperable wireless communications
ABCS SSEI – eliminating system stovepipes
FCS – the ultimate in interoperability
• Need major advances in interoperability standards
•
– current process too slow & ad hoc
– years to make changes
Testing environment needs to be standardized
– Reusable simulation / stimulation suite of tools
•
Joint Forces Command
– Interoperability experimentation before fielding
24
JTRS Responsibilities
•
SCA Management and Oversight
•
Programmable Crypto
Algorithms (29)
– Cluster 1 Crypto
• 14 Algorithms for AIM Chip only
– Sierra and Cornfield Crypto
2003,
Space
Systems, Inc.
• SDR
Required
inCoast
nearCommunication
future
CopyrightCopyright
2002,
Forum
Cluster 3
Cluster 4
A Kits
– Configuration Control
– JTeL test & certification
Cluster 2
Future
Future Cluster
Cluster
Joint Software Communications
Architecture
25
Various Weapon Platform
Portable Software Waveforms (33)
Cluster I
Joint Waveforms
Waveforms
Joint
•
Joint Crypto
Crypto Algorithms
Algorithms
Joint
– Version. 2.2
– Configuration Control
– JTeL test & certification
JTRS Compliance
• Software Communications
Architecture
– Over a thousand “shall” requirements
– SCA v2.1 has been adopted by the SDR Forum
• Partial Solution: By itself does not ensure portability
• Defining Layered Applications Program Interfaces (API’s)
– OMG has adopted slices of the SCA
1. Platform Independent Model
2. Software Radio RFP
3. Lightweight CORBA Components Model RFP
4. Deployment and Configuration RFP
5. Lightweight Log Services (Approved, Nov 2002)
26
JTRS: Test and Evaluation
• JTRS Technology Laboratory (JTeL)
– SPAWAR (San Diego and Charleston, SC)
– Responsibilities include
•
•
•
•
Complete SCA Compliance testing
Waveform Performance testing
Complete Security testing
Provide waveform repository and maintain
waveforms for their lifetime
• Provide for representative JTR Set
• Provide for pilot JTRS waveforms
• Facilitate a distributed test environment
27
Certification/Test/Support for the
Waveforms
JTRS Technical Lab (JTeL)
SPAWARSYSCEN
•
•
(Lead Lab)
NAWC-AD St. Inigoes
•
NAWC-AD Pax River
ARL/SLAD
*
•
WSMR
AFRL Rome
JITC
NRL
*
*
*
DISA-JSC
CERDEC
*
Interdisciplinary Elements
•
Develop and implement JTRS test
and acceptance strategy
Configuration Management and
maintenance of JTRS waveforms
Technical support to JTRS JPO
– During the acquisition of cluster
products and waveforms
Technology surveys
– Assure early and effective
technology insertion
Manage resources assigned to the
JTeL by the JTRS JPO
– Report on planning, execution,
and completion of assigned
tasking
Copyright
2002,
Forum
* Center
of SDR
Excellence
Selectees, to date. 28
Waveform Subject Matter Experts
• CERDEC
– SINCGARS/ VHF
– EPLRS
– HF
• ESC
– ATC/ IFF Mode S
– SATURN/ HQ I/II (FY04)
• SSC Charleston
– UHF SATCOM/LOS
– COBRA
– APCO 25
• SSC San Diego
– Link 11A/ 11B
– Link 4A/ 16(FY04)
• NRL
– WNW
29
Perspective on JTRS Compliance
• JTRS architecture employs layers of software and
hardware to achieve
–
–
–
–
–
Abstraction
Platform Independence
Portability
Modularity
Scalability
• Compliance tests are also layered
–
–
–
–
Hardware
Operating Systems Software
Middleware (including Core Framework)
Applications
30
Table of Contents
•
•
•
•
•
•
•
•
JTRS Clusters
JTRS Compliance
31
Size, Weight, Power
NTDR
JTT
DMR
Zebra
32
• Physics, Analog RF Section
• The notion of SDR requires state-of-the-art analog
performance of components from the antenna through
to the digitizers
• JTRS requires 2 MHz to 2 GHz with ALL the
sensitivity, dynamic range, bandwidth control, adjacent
channel rejection, elimination of spurious emissions,
frequency hop settling times, and terminal latencies
of ALL the Legacy terminals it replaces
33
• Improvement of Standards
–
–
–
–
–
SCA is only part of the solution for JTA Compliance
Lacking Applications Program Interface
Standardized RF Hardware Interfaces
Accommodating other (non-CORBA) middleware's
Lack of Hardware-based Timing Services
• Lack of Software and Emulator Tools
• Clear delineation of testability requirements
– Infrastructure vs. Waveforms
•
•
•
•
Lack of Metric for Infrastructure Capability/Stability
Modem development largely considered proprietary
No standards for Waveform Description
Not yet reliable enough for ATC usage (Cluster 4)
34
• Connectivity
– Attempting to connect parties that
a) don’t want to share their info
b) might be friendly today but hostile tomorrow
• Being a node in the network
– My battery life is shortened because someone else is
pushing video data through my node which I can’t even look
at because I don’t have the proper cryptography
•
•
•
•
•
Information Security vs. Open Architecture
Information Security on a COTS Operating System
Wideband data transfer with LPI/LPD
LPI/LPD for non Line-Of-Sight
IP-based networks on Geosynchronous satellites
35
Spectral Congestion
• Command Posts
2003,
CopyrightCopyright
2001, SDR
Forum
36
The Problem at the Platform Level
13 C
UHF
(H i Pw r)
3C
HQ
2 2 C
HQ
HF
AN T ,
9C
CPLR
BI
UHF
R
33C
10C
2 3C
UHF
15 C
VHF-FM
T/ R
2C
VHF 2
T /R
26C
VHF G
R
1C
U HF
A DF
28 C
12 C
UHF
HF2
2 5C
2 0C
UHF5/L-BAND
UHF1 VHF2
VHF1
SINCGARS
JT ID S
AF T
AMPL
LPF
UHF3/IFF
GPS
UHF4/L-BAND
GPS
UHF11
JTIDS/SDS
Comm 1, TACAN/ MIDS, D/L
VHF,UHF,9601220MHz
UHF6/JTIDS
SCDL [L] JTIDS
UHF10
IFF
1030MHz
1090MHz
IFF
System
SCDL [U]
VHF3
UHF12
GPS Locator
AWACS
Over 50
antennas
UHF
(H i Pw r)
JSTARS
Over 34
antennas
1 1C
But they share
only voice as
common
communications.
EPLRS
5C
HF
3T
AN T ,
2 1 C CPLR
790
740
JT ID S
FW D
AMPL
LPF
27C
4C
(H i Pw r)
SA T
CO M 2
UHF
UHF
6C
30C
670
UHF
UHF
600H+10
These are the
types of platforms
involved in
current
operations.
SA T
CO M 1 VHF1
T /R
UHF
7C
29C
HF1
UHF8
UHF7
UHF2 UHF9
GPS
1.575MHz
1.226 MHz
PIDS
L Band
VOR/ILS
108-118, 329-335 MHz
(FMS Only)
Maritime
Antenna
Copyright 2003, Space Coast Communication Systems,
Inc.
Farms
ACLS
KU,KA,X Band
Radar Altimeter
4.3 GHz
Comm 2, TACAN/ MIDS
VHF,UHF,9601220MHz
JTCTS
1710-1850MHz
ADF
100400MHz
37
Comm 1, IFF, D/L
VHF,UHF,9601220MHz
Reconfigurable Devices
• Moore’s Law is not good enough
Bit Error Rate Performance
-1
10
Uncoded PSK
-2
10
Bit Error Rate (BER)
The
push
towards
the
Shannon
Limit
is on
k=7, r=3/4 Viterbi
-3
10
Shannon
Limit
-4
10
Increasing
Complexity
-5
10
0
0.5
1
1.5
2
2.5
3
Bit Energy to Noise Ratio (Eb/N0) in dB
3.5
4
38
Table of Contents
•
•
•
•
•
•
•
•
JTRS Clusters
JTRS Compliance
39
Understanding SDR
• SDR defined (by Joe Mitola)
– “A software radio is a radio whose channel
modulation waveforms are defined in software. That
is, waveforms are generated as sampled digital
signals, converted from digital to analog via a
wideband DAC and then possibly upconverted from
IF to RF. The receiver, similarly, employs a wideband
Analog to Digital Converter (ADC) that captures all of
the channels of the software radio node. The receiver
then extracts, downconverts and demodulates the
channel waveform using software on a general
purpose processor ”
40
Understanding SDR
• SDR defined (by the FCC)
– “47 C.F.R. 2.1 (c) Software defined radio. A
radio that includes a transmitter in which the
operating parameters of frequency range,
modulation type or maximum output power
(either radiated or conducted) can be altered
by making a change in software without
making any changes to hardware components
that affect the radio frequency emissions.”
41
Understanding SDR
• Emerging Architectures - Commercial
– Sun Microsystems
• Java already used on NTT Docomo iMode phones
– Intel
• “SDR in every die within 10 years”
– Qualcomm
• BREW, Binary Runtime Environment for Wireless
– GNU Radio (the Linux movement)
• GNU Radio allows the construction of radios where
the actual waveforms transmitted and received are
defined by software
42
Understanding SDR
• Business Opportunities
– Open Architecture mandated by JPO
•
•
•
•
•
allows third-party development
productivity and development tools
new waveforms
upgrades
add-on applications
– SDR promotes technology insertion
• innovative hardware upgrades easily installed
• no modification to software
• Moore’s law
43
Understanding SDR
Economics
• Initial cost of entry high
– High performance front ends
– Large software infrastructure
– Lots of computational horsepower
– Not generally available on the open market
• IF implemented correctly …
• Recurring AND operational costs lowered
– Don’t have to bring the ships into port
– New applications on existing hardware
44
Understanding SDR
• Capability and Performance Incentives
– Interoperability
•
•
•
•
Typically implemented with redundant hardware
US inter-service not so bad
US and Allies huge problem space
Want “switchable” interoperability
– Spectral Usages
• On demand commodity
– Waveform Portability
• Waveform==Software increases portability
45
Some Current DoD
SDR Programs
• Technology Evolution 1996-present
– Programmable Modular Communication
System (PMCS) Å This is what JTRS was
called before it became JTRS
– Zebra Systems™
– Joint Combat Information Terminal (JCIT)
– Digital Modular Radio (DMR)
46
Programmable Modular Communication System
(PMCS)
Vertical Functional Partitioning
Waveforms
User
Interface
I/O
HCI
Inter Networking
INFOSEC
Modem
RF
Cosite
Power Amplifier
Antenna
Wireless
Interface
Network
Interface
Control
Framework
System Fabric (Red & Black)
2003,
CopyrightCopyright
2002, SDR
Forum
47
Current SDR DoD Programs
• Zebra Systems ™
• Multi-channel UHF SATCOM Transceiver
• Architecture: PMCS / SDR Forum
– Programmable Modular Communication System
• First production units in late ’96
• 2,4 and 8 channel versions
• Waveforms
– TIBS, TRAP/TADIXS-B, SIDS, TADIL-A, OTCIXS
• Multiple Embedded Crypto
– Railman, Hayfield, CDH
Zebra Systems is a Trademark of Mnemonics, Inc.
48
LOS
SATCOM
LNA
RS-232 Cntrl/Sts
Key Fill
ZEBRA Controller
Ethernet Data
Black Red
Side Side
Antenna Interface Unit
Bias T
LNA
Bias
User Data: OTCIXS
Decrypted
OTCIXS
PCMCIA
Card
VME Receiver
Module
(TIBS)
(Double Wide)
VME Receiver
Module
(TRAP)
(Double Wide)
VME Receiver
Module
(TADIXS-B)
Force 68040
(Double Wide)
Set Up
Black BUS
VME Receiver
Module
(TADIL-A)
Black
Controller
GAC TADIL-A
Module
(Double Wide)
Force 68040
Baseband
ZEBRA Chassis
ON-143(v)14
(OTCIXS)
Red Controller
ZEBRA Crypto
Module
Black Crypto
Serial Link
Intf
Mezz
Red BUS
SDLT
CDH
Mezz
Serial
Control/Setup
KGR-96
KG-84A
RCU
Serial Interface (8 Pairs)
Copyright1997
2003,
Copyright
IEEE
KG-40
(Serial)
49
• Technology Base
– UHF 225-400 MHz, LOS and SATCOM
– Dynamic reconfiguration of channels without loss of
operation
– VME backplane
– Bus independent, POSIX/vxWorks “compliant” code
– TCP/IP inter-processor communication (IPC)
– Published command & control interfaces
• Allows customer to use their own MMI
• Easily extensible to allow new waveforms
• TIBS waveform ported successfully to JCIT radio
– C++ Application Inheritance
50
• Technology Base
– C++ Object-Oriented
Copyright
1999
Mnemonics,
Inc. Communication Systems, Inc.
Copyright
2003,
Space Coast
51
• Joint Combat Information Terminal (JCIT)
– Naval Research Lab, 1995-present
–
–
–
–
–
–
Architecture: PMCS
8 channel, 2 MHz to 512 MHz
CPUs: Lots and Lots of them
Form factor: SEM-E, IEEE 1394 backplane
Embedded INFOSEC, 14 algorithms
Waveforms:
• TRAP, TIBS, VHF ATC, SINCGARS
52
• Joint Combat Information
Terminal (JCIT)
53
• Joint Combat Information Terminal (JCIT)
– JCIT Application Queue Library (JAQL)
– “C” library supports inter-processor communication
•
•
•
•
jcom_send()
jcom_receive()
jcom_taskSpawn()
jcom_taskEnd()
– single header file “jcom.h”
• visible in all compilation spaces
• entire message catalog, array of structs indexed by #defines
• automated tool synchronizes ICD and “jcom.h”
54
• Digital Modular Radio (DMR)
– Architecture: PMCS
– First Demonstrated: June 1999
– CPUs: G3 PPC’s, “n” proprietary single channel
modems with FPGA’s and dual ADSP 21060’s
– Form factor: Compact PCI
– INFOSEC: Advanced INFOSEC Module
– Waveforms:
• MIL-STD 188-181 and 188-183 DAMA
• Havequick, SINCGARS, Link 11 (partial)
55
• Digital Modular Radio (DMR)
– First SDR to extend CORBA into the DSP
• DSP Operating System – Liberty
• DSP ORB – custom, written in ANSI “C”
• ORB currently being upgraded to OMG compliance
– Advanced Core Framework/Infrastructure
• Application Programmers got for “free”
• Life Cycle Management
• Inter-Object / Inter-Processor Connectivity
– Application Launch and Teardown
• ANSI “C” script file, cut and paste
56
Unestricted
Int API
BIT WFs
Calibrate
Link 4A
Link 11
Satcom
LOS
Sincgars
Digital
Ext Device APIs
FW
SVCS
Platform
Audio
Infrastructure
RF
Security
Common Libraries
(com360, audio, tx, rx, gainCtrl, …)
Applications
OS
System
Apps
Radio
Control
Framework Interfaces
Services
(fw.idl, Naming, File, Event, Monitor, Loader,…)
Platform
MW
Internal APIs
Restricted 3rd Party AP
I
App Services
HaveQuick
Applications
FM
AM
DMR Layered Architecture
MiddleWare
(ORB, transport, network, link, physical)
Operating Systems & POSIX
Copyright 2002 © General Dynamics Decision Systems
57
AM Functional Decomposition
Analog
Digital
A/D
Conv
I
BPF
SATCOM
Q
Preselector
Interference
Decimator/ I
Rejection
Filter
Filter
Q
Digital
Tuner
Baseband Filter
RX
Synth
FsA/D
Harmonic
Filter
AM
Demod
Decimate
/ Filter
Squelch
Detect
FsT
AGC
une
HighPass
Filter
Decimate
/ Filter
PA
PA
Switch
COMSEC
[Bypass]
Voice
Output
Voice
Processing
[PCM]
Frequency
Tuning - Rx
Ext
RF
Half-Duplex
Controller
PostFilter
Frequency
Tuning - Tx
TX
Synth
I
BPF
BPF
Foffset21
Q
D/A
Conv
Baseband Filter
Preslctr
Rcvr
Preslctr
Xmtr
Modem
KEY
Filter
I
Q
AM
Modulator
Security
Interpolate
Filter
Interpolate
Filter
Red
Host & I/O
Black
Host & IO
COMSEC
[Bypass]
Voice
Processing
[PCM]
Digital
Analog
DMR
ITU
Analog
Input
PTT
Foffset1
Fs
D/A
Copyright 2003,
Space
Coast Communication
Systems,
Inc. Systems
Copyright
2002
© General
Dynamics
Decision
58
Table of Contents
•
•
•
•
•
•
•
•
JTRS Clusters
JTRS Compliance
59
JTRS Set Overview(Ground and Air)
VEHICULAR JTR ADAPTER
3 CH GROUND / TACP JTR
JTRS
NETWORK
MANAGER
WAVEFORM
SOFTWARE
SINCGARS
HQ
DAMA
WNW
SOFTWARE LOADER/
VERIFIER (SLV)
GND/TACP
AVIATION LRUs
TUNED/MULTIBAND/
LEGACY ANTENNAS
ILS
2-LEVEL
SUPPORT
CONCEPT
4 CH AVIATION JTR
AVIATION JTR ADAPTER
GND / TACP LRUs
EXTERNAL COSITE DEVICES
Copyright 2002, SDR Forum
60
3 CHANNEL GROUND / TACP JTR
15.3”
UNIVERSAL POWER
AMPS
NIU
UNIVERSAL
TRANSCEIVERS
9”
PA
MOUNTS
12” Depth
Copyright 2002, SDR Forum
61
4 CHANNEL AVIATION JTR
14.0”
WIDEBAND PA / RF
INTERFACE UNIT
NIU
UNIVERSAL
TRANSCEIVERS
9”
12” Depth
2003,
CopyrightCopyright
2002, SDR
Forum
62
Cr
yp
10 to
Ju Aw
l 0 ar
2 d
JTRS Cluster 2 (Handheld)
OPR: USSOCOM
Description: Provides JTRS handheld and
manpack radios
ORD IOC: FY05 Cluster IOC: FY04/5 (Blk 1)
• Spec Ops, Army, Marines, Air Force
• Initial Handheld units operate in 20-512 MHz
• Waveforms: Include SINCGARS, HQII, VHF/AMFM, UHF/AM-FM
• Provides user location in either GPS or MGRS
• No greater than 3 lbs, Waterproof to 66 ft
• Embedded programmable COMSEC
• Reduces operator combat load++
Near-Term
FY96-97
Mid-Term
FY98-03
Long-Term
FY04-07
Objective
FY08 and beyond
Objective Schedule
FY02
MX-300
SABER I/II/III
AN/PRC-126
FY03
FY04
FY05
FY06
ECP
MBITR
JTRS
Handheld
Cluster 2
EMD
JTRS
Dismounted
AN/PRC-139
Waveforms
MS C
PROD
IOC
JTRS
Manpacks
2003,
CopyrightCopyright
2002, SDR
Forum
Cluster X
63
JTRS Cluster 3 (Maritime/Fixed-site)
OPR: Navy
Description: Provides JTRS to maritime
platforms (sea only) and fixed sites
ORD IOC: FY01
Cluster IOC: FY04/5 (Blk 1)
•Navy
•Starts in FY03
• Digital, modular, software programmable
• 4 or more channel, multi-function
• Multi-band (100 KHz-2 GHz) radio system
• Standard 19” wide rack mountable
• Interoperable & backwards compatible
•w/legacy radios that it replaces
2003,
CopyrightCopyright
2002, SDR
Forum
64
JTRS Cluster 3 (Maritime/Fixed-site)
2003,
CopyrightCopyright
2002, SDR
Forum
65
JTRS Cluster 4 (Airborne)
4A – Command & Control
4B – Mobility
4C – Air-Air / Air-Ground
2003,
CopyrightCopyright
2002, SDR
Forum
66
JTRS Cluster 4 (Airborne)
OPR: Air Force
Description: Provides JTRS to land and sea
2003,
CopyrightCopyright
2002, SDR
Forum
based fixed wing and unmanned aircraft
Cluster IOC: In development
• Air Force, Navy, Marine Corps, Army
• Scalable Form Factors for various mission
families of aircraft
• Navy partnering for various form factors
• Software programmable, scalable up to 8
channels, multi-mode, multi-band (2 MHz-2 GHz)
• Standard rack mountable, no larger or heavier
than the equipment replaced
67
Joint Waveform Acquisition Schedule
FY02
FY03
FY04
Prototype
Crypto Obj
Non-Cl
Non--Cl 1
Non
CL 1 Non-Core
Non--Core
Non
Cluster 1 Core
Cluster 1 HW Stage
*SINCGARS (SCA Devel Support & Full Wf Devel)
*HAVEQUICK II
*Wideband Networking Waveform (WNW)
*EPLRS
*DAMA SATCOM 181/182/183
DAMA SATCOM 184
HF SSB & ISB w/ALE (2 Wfs)
ATC VHF Data Link (8.33&25Khz) (2Wfs)
Link 16
STANAG 4231 (SATCOM)
STANAG 5066 (HF)
STANAG 4529 (HF)
ATC HF Data Link
SATURN
UHF AM/FM PSK LOS
VHF AM/FM (2 Wfs)
Link 4/4A (TADIL C)
Link 11 (TADIL A)
Link 11B (TADIL B)
UHF FM Public Service (LMR)
VHF FM Public Service (LMR)
COBRA
STANAG 4193 Mode S Level 4/5
Soldier Radio
IBS
DWTS (Digital Wideband Transmission System)
MUOS (ANSCAI), Cellular radio &
Link 22, Mobile Satellite Service (MSS)
AIM
SIERRA
CORNFIELD
*ITALICS – KPP Waveforms,
- Waveforms devel. in Cluster 1,
FY05
EDM
FY06
LRIP
FY07
FRP
FY08
Each
Waveform
Lab Certifie
d
by JTeL
TBD
JTeL IOC
31 Jul 2003
- JPO-devel. Waveforms
JTeL – JTRS Technical Laboratory
TBD
68
- JTeL Certification
(Average Time Shown)
20030109 DAES
Table of Contents
•
•
•
•
•
•
•
•
JTRS Clusters
JTRS Compliance
69
Structure of the SCA
•
•
•
•
SCA v 2.2
– Appendices & Attachments
– Domain Profile XML, IDL
– Rose 1998/2000 UML Models
SCA FAQs
– SCA FAQ
– SCA 1.0 Technical Summary
– SCA 2.0 Technical Overview
– Implementation Table
Security Supplement, v 1.1
– 1: Security API
– A: Functional Security Requirements
– Security API IDL
SRD v 1.2 (Support and Rationale)
– A: Use Cases
– B: Examples
– C: Step 1 Report
– D: Networking Support
•
•
•
API Supplement, v 1.1
– A: Service Definition Description (SDD)
– B: Table of Services
– C: Generic Packet Building Block
– D: Physical Real Time Building Block
– E: Physical Non Real Time Building
Block
– F: Logical Link Control Building Block
– G: I/O Building Block
– Rose 2000 UML Models
API Service Definitions
– Havequick (Physical, MAC, IDL)
– HF ALE (Physical, MAC, IDL)
– SINCGARS (Physical, MAC, IDL)
– LOS (Physical, IDL)
– I/O (Physical, IDL)
Various Errata
70
Ancestry of the SCA
• SDR FORUM http://www.sdrforum.org/
– Technical Report 2.1 Architecture and Elements of
Software Defined Radio System, November 1999
• Object Management Group http://www.omg.org/
– CORBA
– CORBA Components Model
• World-Wide Web Consortium http://www.w3.org/
– XML
• IEEE
http://www.ieee.org/
– POSIX
71
• The Software Communications Architecture
– available at http://jtrs.army.mil/
• The Meat
–
–
–
–
–
Main Document, 165 pages
Appendix A, Glossary
Appendix B, SCA Application Environment Profile
Appendix C, Core Framework IDL
Appendix D, Domain Profile
72
JTRS: The Future of SDR
•
The Software Communications Architecture (SCA): Implementation
or Architecture?
– Answer: Both
– Implementation Elements
• claims to be “implementation independent” but
• mandates CORBA, a very specific implementation
• Core Framework API’s – callable interfaces
– Architecture Elements
• design constraints on applications
• building block structure, non-specific interfaces
• abstract HW classes defer implementation to procurement
specifications
73
• Hardware Structure
74
Horizontal S/W Layers (CORBA)
Common Object Request
Non-Core (Radio) Applications
Broker Architecture
Core Framework (CF)
OE
RF API
RF
RF API
Commercial Off-the-Shelf (COTS)
Non-CORBA
Security
Applications
Non-CORBA
Modem
Applications
Non-CORBA
Modem API
Modem
Modem
Applications Adapter
Modem NAPI
Non-CORBA
Host
Applications
Non-CORBA
Security API
Link, Network
Applications
Non-CORBA
Host API
Security Security
Security
Applications
Adapter
Adapter
Link, Network NAPI
Link, Network
Applications
Host
Host
Applications
Adapter
Link, Network NAPI
Core Framework IDL (“Logical Software Bus” via CORBA)
CORBA ORB &
Services
(Middleware)
CF
Services &
Applications
CORBA ORB &
Services
(Middleware)
CF
Services &
Applications
POSIX Operating System
POSIX Operating System
Network Stacks & Serial Interface Services
Network Stacks & Serial Interface Services
Board Support Package (Bus Layer)
Board Support Package (Bus Layer)
Black (Secure) Hardware Bus
Red (Non-Secure) Hardware Bus
75
• SCA Horizontal Layers
– Bus Layer
– Network & Serial Interface Layer
– Operating System Layer Application Application Application
Core Framework
Radio
– CORBA Middleware
ORB
Services
POSIX Layer
– Core Framework
Native Operating System
– Application Layer
Device Drivers and Protocol Stacks
Board Support Package
Hardware
76
• SCA Horizontal Layers, Alternate Views
applications use CF for
all File access
CORBA API
Logical Device is an Adapter for
the HW-specific devices
Application
applications' Resources,
CF Base Application
Interfaces
Core Framework:
Framework Control &
Framework Services Interfaces
Application
Core Framework
Application
Radio
ORB
Services
POSIX Layer
CORBA ORB
OS access
limited to
SCA AEP
OS access
unlimited
OS (function) that supports SCA
(unlimited proprietary APIs for system
development).
non-CORBA components
or
device drivers
OS access
unlimited
(non-CORBA
components provide
access to hardware
devices / functionality
not available on a
CORBA-capable
processor)
Native Operating System
Device Drivers and Protocol Stacks
Board Support Package
Hardware
Any vendor-provided OS
function calls
77
Layers of the SCA
• The Bus Layer
– Board Support Package
•
•
•
•
•
•
•
•
Hardware Abstraction Layer (HAL)
Layer between Hardware and OS
Allows OS to port easily from board-to-board
Device Drivers offer uniform interface to OS
Homogenizes backplane differences
Unifies memory map
Usually offered by board vendor
Want to avoid using atypical features
78
• The SCA Networking Layer
– SCA builds on commercial networking
protocols
– Low level protocol stacks provide reliable
transport over Bus Layer
– TCP/IP or 1394 might run over backplane
– PPP, SLIP run over serial bus
– CORBA can bypass the OS and directly
access these commercial layers
79
Layers of the SCA
• The POSIX OS Layer – MANDATORIES
– Unique subset of various POSIX standards
– Derived from PSE-52, ≥ 212 functions
– POSIX.1, system calls from UNIX
– POSIX.1b, real-time extensions
– POSIX.1c, threads
80
Layers of the SCA
• POSIX 1003.1
– Standard Libraries, 144 functions mandatory
– stdlib.h, string.h, math.h, etc.
– Nearly universal when you buy a compiler
• Options (i.e. not supported by vxWorks)
– fork, exec, sleep, wait, dup, pipe, etc.
– These functions specifically support Unix-style
separate (and inviolate) process spaces
81
Layers of the SCA
• POSIX 1003.1b, Real-time extensions
– MANDATORY (38 functions)
•
•
•
•
ASYNCHRONOUS_IO
MEMLOCK_RANGE
REALTIME_SIGNALS
TIMERS
• MEMLOCK
• Message Queues
• Semaphores
– OPTIONAL
• MAPPED_FILES
• MEM_PROTECTION
• PRIORITIZED_IO
• PRIORITY_SCHED
82
Layers of the SCA
• POSIX 1003.1c, thread extensions
– Thread == distinct execution sequences
within a process space
– Light-weight context switching, a.k.a. tasks
– Single memory space, no implicit protection
– All MANDATORY (~30 functions) except
• file-locking, shares and system_id
83
SCA Middleware
• … shall use middleware that provides …
– orbos/98-05-13, minimumCORBA
Common
Object
Request
Broker
Architecture
http://www.omg.org/cgi-bin/doc?orbos/98-05-13
84
SCA Middleware
• How does CORBA work?
– the syntax of CORBA = IDL
Interface Definition Language Å Language Independent
Compiles to Java or C or C++ or Ada, etc.
Processor B
OS: Linux
PPC G4
Processor A
OS: Windows
x86 processor
O
R
B
Serial Bus
Backplane
Ethernet
Smoke Signals
Rcvr
Object
O
R
B
Your Code
…
#include “rcvr_skel.h”
…
rFreq=Rcvr.getFrequency();
85
CORBA 101
#1: Define your object’s public interface (IDL)
#2: Run through an IDL compiler
Stub header file: used by client
Skeleton header file: used by server
Server implementation header file: used by you
#3: Write the “guts” (executable code) of the server
implementation
#4: Compile all of the above for processor A
#5: Write and compile a client app for processor B
Include Stub header file from Step 2
#6: Fire up the ORB’s on processor A and B
#7: Run server, just goes into a wait state
#8: Run client, sit back and watch the magic
86
SCA Middleware Services
• CORBA Naming Service shall …
– shall support CosNaming CORBA module &
NamingContext operations …
– formal/00-11-01
– optional in SCA v2.1
– MANDATORY in SCA v2.2
http://www.omg.org/cgi-bin/doc?formal/00-11-01
87
• What’s a Naming Service ?
– Adds a couple hundred kB of executable to the ORB
– Constructs large system-wide naming graphs (trees)
• NamingContexts are likened unto "directories" or "folders"
• Names are likened unto “filename”
• Synonyms allowed, an object can have more than one name
– Provides mechanism for clients to locate objects
– Look for objects with certain "externally visible"
characteristics
– All objects must register their externally visible
characteristics with Naming Service
88
• CORBA Event Service shall …
– shall support Push interfaces …
– formal/01-03-01
– not mentioned in SCA v2.1
– MANDATORY in SCA v2.2
http://www.omg.org/cgi-bin/doc?formal/01-03-01
89
• What’s an Event Service ?
–
–
–
–
Decouples communications between objects
Suppliers produce event data
Consumers process event data
Push or Pull model
• Push: Supplier initiates transfer of event data
• Pull: consumer requests event data
– Event Channel
• Intervening Object
• Allows multiple asynchronous suppliers and consumers
• Event channel is both supplier and consumer
90
What is an SCA Core
Framework?
• Set of CORBA objects that provide …
– deployment
– management
– interconnection
– intercommunication
of software application components
91
SCA Core Framework
• Core Framework == 18 Objects
1-Port, 2-Port Supplier, 3-Application, 4-Application Factory
5-Resource, 6-Resource Factory, 7-Device
8-Aggregate Device, 9-Loadable Device
10-Executable Device, 11-Life Cycle, 12-File, 13-File System
14-File Manager, 15-Testable Object, 16-Property Set
17-Device Manager, 18-Domain Manager
• Core Framework == 55 Methods
• Core Framework == 31 Attributes
• Core Framework == 31 Exceptions
92
SCA Core Framework - Inheritance
<<Interface>>
PropertySet
<<Interface>>
DomainManager
<<Interface>>
<<Interface>>
<<Interface>>
PortSupplier
LifeCycle
TestableObject
<<Interface>>
<<Interface>>
Resource
DeviceManager
<<Interface>>
<<Interface>>
Device
<<Interface>>
<<Interface>>
FileSystem
LoadableDevice
<<Interface>>
<<Interface>>
FileManager
<<Interface>>
Port
Application
ExecuteableDevice
<<Interface>>
ApplicationFactory
<<Interface>>
ResourceFactory
<<Interface>>
File
<<Interface>>
AggregateDevice
93
SCA Core Framework Dependencies
94
SCA Core Framework Aggregations
95
SCA Core Framework
• Services
– File
• 5 Methods
1-read, 2-write, 3-sizeOf
4-close, 5-setFilePointer
• 2 Attributes
1-fileName, 2-filePointer
• 2 Exceptions
1-IOException, 2-InvalidFilePointer
96
SCA Core Framework
• Services
– FileSystem
• 9 Methods
1-remove, 2-copy, 3-exists, 4-list, 5-create
6-open, 7-mkdir, 8-rmdir, 9-query
• 2 Attributes
1-SIZE, 2-AVAILABLE_SIZE
• 1 Exceptions
1-UnknownFileSystemProperties
97
SCA Core Framework
• Services
– FileManager, inherits FileSystem
• 3 Methods
1-mount, 2-unmount, 3-getMounts
• 0 Attributes
• 3 Exceptions
1-NonExistentMount, 2-InvalidFileSyste
3-MountPointAlreadyExists
98
SCA Core Framework
• Inter-object communication
– Port
• 2 Methods
1-connectPort, 2-disconnectPort
• 0 Attributes
• 2 Exceptions
1-InvalidPort, 2-OccupiedPort
99
SCA Core Framework
• Base Application Interfaces
– PropertySet
• 2 Methods
1-configure, 2-query
• 0 Attributes
• 2 Exceptions
1-InvalidConfiguration, 2-PartialConfiguration
100
SCA Core Framework
– PortSupplier
• 1 Method
1-getPort
• 0 Attributes
• 1 Exception
1-UnknownPort
101
SCA Core Framework
– LifeCycle
• 2 Methods
1-initialize, 2-releaseObject
• 0 Attributes
• 2 Exceptions
1-InitializeError, 2-ReleaseError
102
SCA Core Framework
– TestableObject
• 1 Method
1-runTest
• 0 Attributes
• 1 Exception
1-UnknownTest
103
SCA Core Framework
• Basic Components
– Resource : LifeCycle, TestableObject,
PropertySet,PortSupplier
• 2 Methods
1-start, 2-stop
• 0 Attributes
• 2 Exceptions
1-StartError, 2-StopError
104
SCA Core Framework
• Basic Components
– Device : Resource
• 2 Methods
1-allocateCapacity, 2-deallocateCapacity
• 7 Attributes
1-compositeDevice, 2-usageState, 3-adminState
4-label, 5-softwareProfile, 6-identifier,
7-operationalState
• 2 Exceptions
1-InvalidState, 2-InvalidCapacity
105
SCA Core Framework
• Children of Device
– LoadableDevice : Device
• 2 Methods
1-load, 2-unload
• 0 Attributes
• 1 Exception
1-InvalidLoadKind
106
SCA Core Framework
• Children of Device
– ExecutableDevice : LoadableDevice
• 2 Methods
1-execute, 2-terminate
• 2 Attributes
1-STACK_SIZE, 2-PRIORITY
• 4 Exceptions
1-InvalidProcess, 2-InvalidFunction,
3-InvalidParameters, 4-InvalidOptions
107
SCA Core Framework
• Children of Resource
– Application : Resource
• 0 Methods
• 6 Attributes
1-componentNamingContexts,2-componentProcessIds
3-componentDevices, 4-componentImplementations
5-profile, 6-name
• 0 Exceptions
108
SCA Core Framework
• Managers and Factories
– DomainManager : PropertySet
• 10 Methods
1-registerDevice, 2-registerDeviceManager,
3-unregisterDeviceManager, 4-unregisterDevice
5-installApplication, 6-uninstallApplication,
7-registerService, 8-unregisterService,
9-registerWithEventChannel
10-unregisterFromEventChannel
• 5 Attributes
1-domainManagerProfile, 2-deviceManagers,
3-applications, 4-applicationFactories, 5-fileMgr
• 3 Exceptions
1-ApplicationInstallationError, 2-InvalidIdentifider
3-DeviceManagerNotRegistered
109
SCA Core Framework
– DeviceManager : PropertySet, PortSupplier
• 6 Methods
1-unregisterDevice, 2-shutdown, 3-registerService
4-unregisterService, 5-getComponentImplementatonId
6-registerDevice
• 6 Attributes
1-deviceConfigurationProfile, 2-fileSys, 3-identifier
4-label, 5-registeredDevices, 6-registeredServices
• 0 Exceptions
110
SCA Core Framework
– ApplicationFactory
• 1 Method
1-create
• 2 Attributes
1-name, 2-softwareProfile
• 3 Exceptions
1-CreateApplicationRequestError,
2-CreateApplicationError,
3-InvalidInitConfiguration
111
SCA Core Framework
– ResourceFactory
• 3 Methods
1-createResource, 2-releaseResource, 3-shutdown
• 0 Attributes
• 2 Exceptions
1-InvalidResourceNumber, 2-ShutdownFailure
112
SCA Core Framework
• Aggregations
– AggregateDevice
• 2 Methods
1-addDevice, 2-removeDevice
• 1 Attribute
1-devices
• 0 Exceptions
113
SCA Services
• Log Service, new to SCA v2.2
• 15 methods / 0 attributes / 3 exceptions
• Optional or Mandatory?
– Optional
– Certain mandatory CF Objects are required to
write log records using the LogService
– In lieu of full blown LogService offerer can
write stubs to keep the CF happy.
114
SCA Domain Profile
– Definition of Domain Profile
• Describes the hardware (Device Profile) and
software (Software Profile) of the system.
• DomainManager uses this profile to build its
internal information base of
– hardware devices
– software components
– application assemblies
• Series of XML documents / files
• Based on CORBA Components specification
http://www.omg.org/cgi-bin/doc?orbos/99-07-01
115
SCA Domain Profile
eXtensible
Markup
Language
– Developed by World-Wide Web consortium
http://www.w3.org/TR/REC-xml
– “XML documents are containers for information”1
–
1 XML Elements of Style, Simon St. Laurent, McGraw-Hill, 2000
116
SCA Domain Profile
What does XML look like?
<?xml version="1.0" encoding="utf-8" ?>
- <Math cfg:package="org.openoffice.Office" xmlns:xsi="http://www.w3.org/1999/XMLSchemainstance" xmlns:cfg="http://openoffice.org/2000/registry/instance">
- <FontFormat>
<Name cfg:type="string" />
<CharSet cfg:type="short" xsi:null="true" />
<Family cfg:type="short" xsi:null="true" />
<Pitch cfg:type="short" xsi:null="true" />
<Weight cfg:type="short" xsi:null="true" />
<Italic cfg:type="short" xsi:null="true" />
</FontFormat>
- <Symbol>
<Char cfg:type="int" xsi:null="true" />
<Set cfg:type="string" />
<Predefined cfg:type="boolean">false</Predefined>
<FontFormatId cfg:type="string" />
</Symbol>
</Math>
117
SCA Domain Profile
– Elements of Domain Profile (eight)
•
•
•
•
•
•
•
•
Domain Manager Descriptor
Device Configuration Descriptor
Software Assembly Descriptor
Software Package Descriptor
Software Component Descriptor
Device Package Descriptor
Profile Descriptor
Properties Descriptor
118
SCA Domain Profile
– Domain Manager Descriptor
• refers to DomainManager Software Package
Descriptor (SPD)
<<DTDElement>>
domainmanagerconfiguration
id : ID
name : CDATA
<<DTDSequenceGroup>>
domainmanagerconfiguration_grp
(from domainmanagerconfigurati on)
0..1
{1}
<<DTDElementPCDATA>>
description
{2}
<<DTDElement>>
devicemanagersoftpkg
{3}
<<DTDElement>>
services
119
Use of UUID’s
• UUID == Universal Unique Identifier
• Uniquely identifies objects
–
–
–
–
128-bit numbers guaranteed to be unique
2^128 ≅ 3.4 x 1038
The mass of a 180 Jupiter's in micro-grams!
Guaranteed unique through combination of:
• hardware addresses
– MAC address, uniquely assigned by IEEE
• time stamps
• random seeds
• All SPD’s must have a UUID
120
SCA Domain Profile
– Software Package Descriptor (SPD)
• identifies a software component
implementations
• softpkg
• name, author, property file
• pointer to Software Component Descriptor
121
SCA Domain Profile
– Software Component Descriptor (SCD)
• Documents the component’s interface(s)
• Component Description
– resource, device, etc.
– inherited interfaces
• Message Ports
– provides port
– uses port
– port “type”: data, control, status, responses, etc.
• IDL interfaces, repository ID
122
SCA Domain Profile
– Properties Descriptor
• Component and Device Attribute Settings
• Series of
(id, type, value, units, range)
• Supports structured collections of attributes
• Select attributes can later be
– query() a.k.a. get
– configure() a.k.a set
• Controls which attributes are
– visible
– settable a.k.a. read-only
123
SCA Domain Profile
• Software Assembly Descriptor (SAD)
– assembled application
• 1..n SPD’s or components
– component placement
• tells ResourceFactory where to deploy component
– component instantiation
• tells ResourceFactory how many to deploy
– point-of-contact for start, stop, query, etc.
– interconnections
• pairs of “provides” and “uses” ports
124
SCA Domain Profile
• Device Configuration Descriptor (DCD)
– Describes:
• components initially started by DeviceManager
• how to obtain DomainManager object reference
• connections to services (Devices)
• aggregateDevices
– refers to DeviceManager’s SPD
– references SPD’s
• for S/W components started on the Device
125
SCA Domain Profile
• Device Package Descriptor (DPD)
– Contains H/W device attributes
• used by Human/Computer GUI to display info
– Uniquely identifies H/W device including
• Major & Minor version numbers
• Manufacturer
– identifies H/W class (RF, Modem, I/O, …)
– refers to Properties Descriptor for H/W
– indicates parent/child relationships
126
SCA Domain Profile
• Profile Descriptor
– Contains absolute file path for a profile
• relative to mounted FileSystem
– Used to access any kind of profile type
– Valid profile types
• SAD, SPD, DCD, DMD
127
SCA Domain Profile
– Relationship between profile elements
Domain Profile
0..n
0..n
1
<<DTDElement>>
<<DTDElement>>
DomainManager
Configuration Descriptor
Device Configuration Descriptor
1
1
1
1..n
1..n
<<DTDElement>>
1
Profile Descriptor
<<DTDElement>>
<<DTDElement>>
1
Profile Descriptor
0..1
0..n
<<DTDElement>>
0..n
0..n
<<DTDElement>>
<<DTDElement>>
Properties Descriptor
0..n
128
SCA from the Waveform Developer
Standpoint
• Radio System comes with Operating
Environment (OE)
– Operating System
– Middleware
– Core Framework
– Devices & DeviceManager
– Application & Application Factory
– Domain Profile
129
SCA per Waveform Developer
• Developer S/W inherits from CF Objects
– Automatically acquire significant functionality
•
•
•
•
•
read/write files
get, connect & disconnect Ports
create & release Resources
load and unload Devices
allocate & deallocate Device capacity
– Software Assembly Descriptor describes how
to “wire” Ports together
130
• Developer Rules of Engagement
– OS interface through MANDATORY POSIX API’s
EXCEPT file access
– All file access through Core Framework
– CORBA interface though minimumCORBA API
– Legacy (non-CORBA) interfaces must be wrapped
and appear as Devices
• called Adapters
131
• Some simple truths about SCA implementations
– Core Frameworks are not portable
– Core Framework source code is not generally
available
– Waveform Applications are portable at the source
code level if and only if
• Adapters, if used, are available in linkable object code of
the target, i.e. they appear as Devices
• All inter-processor and external interfaces are IDL
132
Use of Factories
•
Legacy Deployment Method: Hard-coding
–
–
–
–
–
–
–
–
–
Load file1 unto CPU 1, file2 unto CPU 2, file3 unto CPU3
Instantiate objects 1,2,3,4 on CPU1
Instantiate objects 1,5,6 on CPU2
Instantiate 5 object 3’s and a 2 and a 6 on CPU3
Connect output of 1 to input of 2
Connect output of 2 to input of 3
Connect output of 3 to input of 6/CPU3, etc, etc.
Set Initial Values on object 1, object 2, etc.
Issue “Start” messages to object 6, object 5, … , object 1
• Factory loads and executes a single file that nests to
other descriptor files that result in an identical
sequence of operations
133
Example FM Line-of-Sight
Waveform Deployment Diagram
Narrowband
Modem
General
Purpose
Processor
INFOSEC
Deploys
Deploys
Deploys
Non-Corba Object:
fmModemDSP
Corba Components:
logicalNarrowbandDevice
losModemAdapter
Library Components:
dspMsg
losCommon
waveform
SRA Framework Services:
logger
fileSystem
SRA Framework Control:
deviceManager
Copyright2001
2003, Space
Coast
Communication Systems, Inc.
Copyright
© SDR
Forum
General
Purpose
Processor
Audio I/O
Device
Deploys
Corba Components:
los_wf_ctrl
los_wf_ctrl_factory
logicalAudioDevice
Library Components:
dspMsg
losCommon
waveform
SRA Framework Services:
logger
fileSystem
SRA Framework Control:
deviceManager
domainManager
134
Example Domain Profile FM LOSWaveform Assembly
Aggregate relationship denotes
a direct reference to a file
<<File>>
<<File>>
FM LOS Waveform SAD
Home Properties
PRF
Using relationship denotes
a dependency on a file
1
(Referenced from any SPD)
1
1
1
1
1
<<File>>
<<File>>
<<File>>
<<File>>
<<File>>
<<File>>
FM LOS Modem
DSP SPD
Logical Narrowband
Device SPD
Logical Audio
Device SPD
LOS Modem
Adapter SPD
FM LOS WF
Controller SPD
FM LOS WF
Controller Factory SPD
1
1
<<File>>
Logical Narrowband
Device SCD
<<File>>
DSP Msg
SPD
1
<<File>>
1
<<File>>
<<File>>
<<File>>
LOS Modem
Adapter SCD
LOS Common
SPD
FM LOS WF
Controller SCD
1
<<File>>
Logical Audio
Device SCD
LOS WF Controller
Factory SCD
1
1
<<File>>
Narrowband
Device DPD
1
<<File>>
Narrowband
Device PRF
1
<<File>>
<<File>>
Waveform
SPD
FM LOS WF
Controller PRF
Audio
Device DPD
1
<<File>>
Audio
Device PRF
Copyright 2001 © SDR Forum
<<File>>
1
<<File>>
LOS WF Controller
Factory PRF
SAD - Software Assembly Descriptor
SPD - Software Package Descriptor
SCD - Software Component Descriptor
DPD - Device Package Descriptor
PRF - Property File
135
FM LOS CORBA Component
Connections
LOS::LOS_Resource
CF::Logger
Uses
Port
logger_out_port
HCI_in_
port
Provides
Port
CF::Logger
modem_ctrl_
out_port
modem_ctrl_
in_port
logger_out_port
Uses
LOS Waveform Controller
LOS::LOS_ModemResource Provides
Port
Port
(id=los_wf_ctrl_component) modem_responses_
modem_responses_
in_port
Uses
Port
CF::Resource
flow_ctrl_
out_port
Uses
Port
Provides
Port
Audio
I/O
flow_ctrl_
in_port
Uses
Port
FlowControl
flow_ctrl_
in_port
FlowControl
flow_ctrl_
out_port
Supporting
Port
Supporting
Port
Supporting
Port
LOS::LOS_ModemResponse
CF::Logger
Uses
Port
modem_
responses_
in_port
resource_
ctrl_out_port
Provides
Port
Uses
Port
modem_
ctrl_out_port
PushPorts::
UlongSeqConsumer
resource_
ctrl_in_port
PushPorts::
UlongSeqConsumer
Uses
Port
audio_data_in_port
Uses
Port
LOS Modem Adapter
(id=los_ma_component)
out_port
Logical Audio Device
audio_data_out_port
(id=logical_audio_component)
logger_out_port
Uses
Port
Provides
Port
modem_
responses_
out_port
Provides
Port
modem_data_in_port
modem_data_out_port
PushPorts::
UlongSeqConsumer
Uses
Port
PushPorts::
UlongSeqConsumer
modem_
ctrl_in_port
Provides
Port
Logical Narrowband Device
(id=logical_narrowband_
component)
Uses
Port
indicates a command and control connection
Uses
Port
Narrowband
Modem
logger_out_port
CF::Logger
indicates a data connection
indicates a response connection
indicates a Logger connection
Copyright 2003,
CoastForum
Communication Systems, Inc.
Copyright
2001Space
© SDR
indicates the external visible port for the FM LOS Assembly
136
Table of Contents
•
•
•
•
•
•
•
•
JTRS Clusters
JTRS Compliance
137
JTRS Compliance
• Current Definition of Compliance
– JTRS JPO holds authority to certify
• Authority may be transferred to a standards body
– “Testing the shalls”
• 575 shalls in the main document
• 212 mandatory OS functions, Appendix B
• No shalls in Appendix D ???
– Compliant Operating Environment (OE)
– Compliant Applications
– Compliant Service Definitions
– Compliant Hardware
138
Minimalist Interpretation
• Separate certification processes for
– Systems
– Hardware
– Software
•
•
•
•
JTRS JPO sole certifying authority (transferable)
Compliance == meeting all the requirements
Forget the API Supplements, will be superceded
Security Supplement
– 267 testable “shalls” in the Security Supplement
– Forget about the Service Definitions, will be
superceded
139
Compliance Responsibilities
140
Latest SCA Enhancements
• Requirements Hiding
– Out of 1099 reqm’ts only 465 are externally visible
•
•
•
•
•
Abstraction for Reconfigurable Devices (HAL)
Radio API’s – H/W abstractions
Software Download
Radio Services
Platform Independent Model (PIM)
#1 Goal
Backward Compatibility and Portability
141
Application Program Interface
• An API forms an agreement between two components on the
– language and semantics used to communicate
– services provided (Service Definitions)
– behavior resulting from invocation of operations
• An SCA-compliant API is described using IDL and is formed by
inheriting Interfaces derived from previously defined Building Blocks.
• Standardized APIs are essential for portability of applications and
interchangeability of devices.
• API’s guarantee Service Provider and User can communicate
regardless of OE or programming language.
• Uniquity of API definitions guaranteed via application of UUID
142
Data and Real-time
• Different Levels of API’s
Control
• Loosely based on OSI model
B Non-real-time Control,
Setup and
• Currently defined on a waveform
byInitialization,
waveform basis
from applications, other
A
levels, user interface
Network
Waveform
Application
A
A
LLC
B
MAC
B
B
LLC
A
A
A
I/O
B
Physical
B
External
Network
Connection
143
• All SCA-compliant APIs shall have their interfaces described in IDL
• Rules of Engagement for API definitions
- Use existing API.
- Create a new API via inheritance
- Translate an existing non-JTRS API to IDL
- Develop a new API based upon one or more Building Blocks.
• Rules of Engagement for API transfer mechanisms
- CORBA
- Alternate or non-CORBA transfer mechanism
- Documented in IDL, implemented in native language
- Commercial or government standard preferred
144
Portability Metrics
Portability is not a boolean it’s a continuum
Software “jumps” off
of platform A
and “lands” on
platform B
JTRS somewhere
in here
Most Portable
Least Recurring $
BEFORE JTRS:
For each platform
write everything
from scratch
Less Portable
Most Recurring $
145
SCA Compliance - INFOSEC
• Programmable Security Devices
• Three contenders
– GD’s Advanced INFOSEC Module (AIM)
– Raytheon Cornfield
– Sierra
• Legacy embedded devices being phased out
• CORBA through the Red/Black barrier tricky
–
–
–
–
Create individual proxies on both sides of barrier
Strip the CORBA packets into data/command only
Parameterize / limit vocabulary across barrier
Take a big latency hit
146
Table of Contents
•
•
•
•
•
•
•
•
JTRS Clusters
JTRS Compliance
147
Practical Guide to
Waveform Applications
• Rules of Development – NEW paradigm for SDR
– With CORBA …
• model the complete distributed environment on a PC !
• connector-level testing of all interfaces
• BEFORE target hardware arrives
– Test beds, commercial boards
•
•
•
•
careful wrapping of ALL devices and hardware
use PC software without modification, EXCEPT …
Hardware RF assist modules
ASIC’s, FPGA’s, or hand tailored assembly code
• Target hardware
– universally late
– sometimes erratic, be CONFIDENT in the software connectivity
148
Practical Guide to
• The Holy Grail : Portable Software
– avoid anything machine dependent
• in “C”, bit-fields, unions, pragmas, etc.
• in Ada, all Appendix M “features” are taboo
avoid automatic conversions
• avoid memorizing operator precedence, use parens
– use single source tree for all combinations of
• target hardware
• operating system
– when absolutely necessary
• in “C” use #if (more extensible than #ifdef)
149
Practical Guide to
• Estimating Timing and Sizing
–
–
–
–
Absolute Necessity
mis-calculation can kill your program!
margin for unforeseen circumstances
govm’t usually requires at least 100% margin
• Example
– Processor has 40 MFlops
– Run 50-point DFT, requires 5180 operations
– Data rate = 48 ksps
5180 ops
⎛ 50 samples
⎜⎜
samples
48000
sec
⎝
⎞
⎟⎟
⎠
= 5 MFlops
5
= 13 % load
40
150
Practical Guide to
• Latency and Throughput
– packet size vs. latency
• larger packet size, longer latency
– packet size vs. CPU load
• larger packet size, lower CPU load
– packet size vs. bus bandwidth
•
•
•
•
modern buses support bursty communications
bus arbitration
larger packet size fewer arbitrations
slightly longer wait states
– Bus Wait times & Bus bandwidth << OS tick timers
151
Practical Guide to
• Latency and Throughput – Operating System
– OS runs on tic-timer, < 1 msec. to 0.01 sec.
– Principal, 40 S/W engineers running on one RTOS
– Common Courtesy, complete your action and …
•
•
•
•
yield Î go to back of the queue
yield Î go to sleep until awakened by event
lock Î minimize resource locking
lock Î never lock a resource and then go to sleep
– Who pre-empted me?
– Recommend only 2 priority levels, PRI_HI & PRI_LO
– Tasks running at higher priority MUST …
• Be courteous
• Carefully contend for a resource locked by a lower task
152
Practical Guide to
• Latency and Throughput – Operating System
–
–
–
–
Always put your server object to sleep for an event
For external events Î use an interrupt
Interrupt code on target will not be portable
Can abstract interrupt behavior in sim world
• Create an interrupt object
– Alternatives
• lowest priority spinning
– slightly sluggish, prevents monitor tasks from running
• nanosleeping
– more sluggish, smallest quanta of nanosleep == OS tictime
• both methods dangerously prone to missing an event !
153
Practical Guide to
• CORBA Concurrency Models
• What’s a concurrency model?
• Describes ORB-to-ORB interactions
–
–
–
–
–
–
Blocking
Reactive
Threaded
Thread-per-Client
Thread-per-Request
Thread Pool
154
Practical Guide to
• Blocking Model
–
–
–
–
–
–
Caller blocks until action complete unless oneway
IDL “oneway” says the client expects no reply
Single-threaded version
Server can only accommodate one client at a time
Simple, low overhead
Server is not spinning off new threads every time
there is something to do
– Normally too sluggish for most RT applications
155
Practical Guide to
• Blocking Model
– The oneway myth
• IDL modifier “oneway” tells the ORB to queue the requested
action for processing but not to block the caller
• The first call to a method or object suffers a setup time while
the ORB is initiating the line of communication with the other
ORB(s)
• “Pre-connect” all time critical ORB calls during initialization
phase
• Back-to-back calls on a single object or method can block
even though they are “oneway” calls
• ORB-to-ORB “book-keeping” is highly implementation
dependent
156
Distributed Design
• CORBA eases burden of distributed, objectoriented design
– Inter-object communication
• Asynchronous in practice
• Co-located objects can bypass CORBA and use IPC
–
–
–
–
IPC = Inter-Process Communication
Shared memory with mutex semaphores
Binary semaphores
Signaling, i.e., kill() and raise() are SCA-compliant
– Flattering latency specs in the advertising, µsec
– Reality: processor-to-processor latency, ~ 10-2 sec
– Too many “little” objects, big overhead hit
157
Distributed Design
• Time Critical Functions
–
–
–
–
SCA lacks timer functions
OS timer functions tied to “tick” timer > 10-3 sec
Must use hardware-based timer/counters
Timer events should generate interrupts
• Still take latency hit on interrupt servicing
• Take another hit on pre-emptive task switch
• Total reaction time measured in hundreds of µsec
– Certain OS’s better than others
158
Distributed Design
• Hardware Latency, Interrupt Handlers
Event
Interrupts Disabled, Higher Priority Interrupts go first
OS responds, saves processor State
Context switch into handler
Your handler runs here
Context switch back into OS, OS decide that you run next
Context switch
Your application responds to event
Increasing Time
159
Distributed Design - Modem
Time Critical
High
Priority
Buffering
Background
Processing
Time Critical
Platform
Unique
Platform
Unique
High
Priority
Buffering
160
Hard vs. Soft Real-time
Hard Real-Time →
To miss a deadline is fatal and results in cessation of operation
Probability of Occurrence must approach zero
Deterministic Design and Implementation
Software need not handle violations, system is dead
OS’s:
VxWorks, Integrity, Lynux
Soft Real-Time →
To miss a deadline results in degraded performance
1 in 10-x acceptable
Probabilistic Design
Software must tolerate faults:
Exception Handlers
Big Buffers
Dynamic Allocation
OS’s:
Windows, Linux/Unix
161
Hard vs. Soft Real-time
In many, many cases ...
Hard vs Soft real-time is in the “eye of the beholder”
In a low bandwidth data acquisition system
vehicular traffic flow
seismic monitoring
10-2 soft real-time good enough
In a motion control system
In a low bandwidth communication system (< 64 kbps)
.......
In particle physics application
10-10 still not good enough
162
JTRS Waveforms
Waveform. A waveform is the representation of a signal as a plot of amplitude
versus time. In general usage, the term waveform refers to a known set of
characteristics, e.g. SINCGARS or EPLRS "waveforms". In JTR System usage, the
term waveform is used to describe the entire set of radio functions that occur from
the user input to the RF output and vice versa. A JTR System "waveform" is
implemented as a re-useable, portable, executable software application that is
independent of the JTR System operating system, middleware, and hardware.
163
JTRS Waveforms
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
* SINCGARS ESIP
* EPLRS
* Wideband Networking Waveform
(WNW)
* UHF DAMA SATCOM 181/ 182/ 183
* DAMA SATCOM 184
STANAG 4231 (SATCOM)
ATC HF Data Link
STANAG 5066 (HF)
STANAG 4529 (HF)
* HF SSB w/ ALE
HF ISB w/ ALE
*VHF For ATC (8.33)/ Data Link
* HAVEQUICK II
SATURN
* Link 16
UHF FM Public Service (LMR)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
VHF FM Public Service (LMR)
Link 11 (TADIL- A)
VHF FM
VHF AM
ATC VHF Data Link
UHF AM/ FM PSK LOS
Link 4/ 4A (TADIL- C)
Link 11B (TADIL- B)
IBS-M
STANAG 4193 Mode S
DWTS
Soldier Radio
COBRA
ANSCAI
Cellular Radio
Link 22
MSS
164
JTRS Waveforms
• Capabilities Required. The performance requirements cited
in this section are capabilities for the JTR System or as they
apply to each JTR Set configuration. Requirements are
denoted as Key Performance Parameters (KPP); Threshold
(T) and as Objective (O). These categories are to assist in the
evolutionary acquisition process by showing precedence.
165
JTRS Waveforms
•
SINCGARS ESIP (Single Channel Ground and Airborne Radio System)
– SINCGARS is a family of VHF-FM combat net radios which provides the primary
means of command and control for Infantry, Armor and Artillery Units.
– Bandwidth: 25kHz
– Center Frequency Range: 30-88 MHz
– Data Rates: 16Kbps
– Performance Requirements: K - T
– Encryption: KY-57/58, KYV-5
– Enhanced SINCGARS Improvement Program (ESIP) - analog and 16 KBPS
digital voce as well as at data rates of 75 BPS and 16 KBPS. SINCGARS will be
compliant with MIL-STD-188-220 and 241-1/2.
– Single channel (SC) or frequency hopped (FH) modes
– Cipher Text (CT) or Plain Text (PT)
– Separate Internet Controller (INC) module performs IP routing on the SINCGARS net
– ATC is developing JTRS SINCGARS for use in now and future Clusters
166
JTRS Waveforms – SINCGARS
ESIP
• DESCRIPTION: SINCGARS is a
new family of VHF-FM combat net radios which
provides the primary means of command and
control for Infantry, Armor and Artillery Units.
SINCGARS is designed on a modular basis to
achieve maximum commonality among the various
ground and airborne system configurations. A
common Receiver Transmitter (RT) is used in the
manpack and all vehicular configurations.
SINCGARS family of radios has the capability to
transmit and receive voice, tactical data and record
traffic messages and is consistent with NATO
interoperability requirements. The system operates
on any of the 2320 channels between 30-88
megahertz and is designed to survive in a nuclear
environment. COMSEC for the basic radio is
provided by use of the VINSON device. An
Integrated COMSEC (ICOM) version of the
SINCGARS is currently in production. SINCGARS
is operable in a hostile environment through use of
Electronic Counter Countermeasure (ECCM).
SINCGARS replaces the current standard manpack
and vehicular radios, AN/PRC-77 and AN/VRC-12
family, respectively. An airborne version of the
SINCGARS radio is in production and will replace
the currently standard aircraft radios, AN/ARC-114
and AN/ARC-131.
167
JTRS Waveforms
•
EPLRS
– EPLRS Operates in the 420-450 MHZ frequency range. EPLRS will operate in
the data mode at 57 KBPS VHSIC SIP and 228 KBPS VECP. EPLRS will be
compliant with CDRL-4002W-001A.
– EPLRS primary purpose is to provide the digital backbone radio frequency
communications to support connectivity of the C4I tactical data networks from
regimental to company level.
– Bandwidth: 3 MHz
– Data Rates: 57 Kbps VHSIC SIP, 114 Kbps VECP
– Waveform Type: multiple modes: CSMA, TDMA, CDMA, FDMA
– Encryption: KOK-13 (key generator), KGV-13 TRANSEC/COMSEC
– The Receiver Transmitter (RT) is a transceiver with an embedded Controlled
Cryptographic Item (CCI) module, the KGV-13. It provides for dual-level secure
data communications at either Confidential or Secret level between RTs. The RT
can be equipped with two interfaces; Army Data Distribution System Interface
(ADDSI), a subset of the X.25 protocol, and the MIL-STD 1553 interface.
– EPLRS Radio Set:
AN/PSQ-4 EPLRS Radio
168
JTRS Waveforms
•
Wideband Networking Waveform (WNW)
– Wideband Networking Waveform Exact frequency operating range and modes of
operation are being developed by the government. It is expected the waveform
will operate in the 2 MHZ to 2 GHZ frequency range at up to 5 MBPS networked
throughput. Standards for the WNW waveform are currently under development.
– Bandwidth: Government or Vendor Developed
– Center Frequency Range: Government or Vendor Developed
– Data Rates: Government or Vendor Developed
– Waveform Type: Most likely OFDM
– Encryption: TBD
– The Army objective for the JTRS WNW is to provide the lower tactical Internet
(TI) backbone. The lower TI architecture is a 2-tier architecture. The two tiers
refer to subnets as the first tier (i.e. SINCGARS nets) and the backbone refers to
the second tier connecting all the subnets together. The initial application of the
WNW would be to provide the backbone function of the lower TI. Eventually, the
WNW could replace the first tier also.
169
WNW Network Formation Steps
All nodes are off-line.
A ll n o d e s g o o n -lin e
a n d is s u e s ta g g e r e d
n e ig h b o r discovery
broadcasts.
T2
T=1
T1
T=0
C lu s te r h e a d s s e n d o u t
ro u tin g u p d a te s s o a ll
C lu s te r h e a d s a r e a w a re
o f n e tw o r k to p o lo g y .
T im e s lo t r e s e r v a tio n s
a r e m a d e b e tw e e n
C lu s te r heads, the
backbone is formed.
Cluster Member Link
Cluster
Member
Cluster
Head
Cluster
Backbone
T3
T4
T=10
T=20
JTRS_2558..2
- WNW IPT Lead
- Heterogeneous Networking
- Integrated WNW Simulation
- System Integration & Testing
- VoIP Application
- Certification
- Mobile Data Link Protocols - WNW Subnet Integration - Narrowband SiS - WNW SW Radio Porting
- WNW Intranetwork Routing
- Internetwork Routing
- JTRS WNW Network Manager
- WNW Scenario Development
- Platform Applications
- Field Test Support
- WNW Scenario Development
- Field Test Support
- WNW Data Reduction Toolset
- WNW Simulation Development
- Anti Jam SiS
- LPI/LPD SiS
170
- Wideband SiS
- WNW Security Architecture
- WNW IP COMSEC Design
- WNW TRANSEC Design
- Key Management
JTRS Waveforms
• DAMA SATCOM MIL-181/ 182/ 183
– Bandwidth: 5 and 25 kHz
– Data Rates: 75, 300, 600 Bps; 1.2, 2.4, 4.8, 9.6, 16, 19.2, 28.8, 32,
38.4, 48, 56 Kbps inclusive
– Waveform Type: FSK,SBPSK,BPSK,SOQPSK,DEQPSK,CPM
– Encryption: Various COMSEC, KGV-11 TRANSEC
•
•
181 is 5/25 kHz single channel simplex protocol
182 is 5 kHz Demand-Assigned Multiple User
– 8.96 second frame, high latency
•
183 is 25 kHz Demand-Assigned Multiple User
– 1.386 second frame, bandwidth hog
•
184 is a Link Layer Protocol
– optimizes Multi-User operation on a MIL-STD 188-181 single user channel
171
JTRS Waveforms
• ATC HF Data Link
– HF ATC Data Link VHF ATC Data Link will operate in the 2-30
MHZ frequency range. VHF ATC Data Link will support analog
voice and data at 300, 600, 1200 and 1800 BPS. HF ATC Data
Link will be compliant with RTCA DO-265, ARINC 635-3 and
735-3, FAA TSO C31d. and C32d.
– Bandwidth: 3 KHz
– Data Rates: 300,600,1200,1800 Bps
– Waveform Type: FDMA/CDMA
– Encryption: None
172
JTRS Waveforms
HF-ALE Family of Waveforms
IP Applications
Data
Ethernet
Serial
AF
Network layer
MIL-STD-188-141B
Networking ap. D and H
Data link layer
STANAG 5066 /
MIL STD 188-110B app. E
MIL STD 188-141B app. G
INFOSEC
Physical layer
Link Protection
KG 84, KY, etc
MIL STD
188-110B
STANAG
4529
Applications
Voice
MIL STD
188-148A
K
STANAG
4285
ATC HF
Data Link
ANDVT
compatible
L11
compatible
173
JTRS Waveforms
• HF-ALE Family, including Link 11 and HF TADIL-A
– Data Rates: various 75 bps to 19200 bps
– Waveform Type: Various mPSK and QAM
– Encryption: ANDVT, KG-84, KIV-7, KG-40, USC-43/KYV-5 (TECTERM),
KY-99A (MINTERM) and KY-100 (AIRTERM)
– Significant Antenna Requirements: Ground wave vs. Sky wave
174
JTRS Waveforms
• VHF For ATC (8.33)/ Data Link Modes 2 & 3
– Replaces 25 KHz spacing
– Bandwidth: 8.33 KHz
– Waveform Types : AM, CSMA, D8PSK
– Encryption: None
– Guard Channel required
175
JTRS Waveforms
• HAVEQUICK II
– Have Quick II (UHFAM/FM/PSK) operates in the 225-400 MHZ
frequency band. It will operate in the analog and 16 KBPS digital
voice as well as at data rates of 75 BPS to 16 KBPS. HQ II will
be compliant with MIL-STD-188-220 and 243 and JIEO-9120A.
– Data Rates: 16 Kbps
– Performance Requirements: K-T
– Encryption: KY-57/58
176
JTRS Waveforms
• SATURN
– SATURN will operate in the 225-400 MHZ frequency range.
SATURN will support digital voice and data rates that will be
determined by the government in the future. SATURN will be
compliant with STANAG-4372 and JIEO-9120A.
– Waveform Type: Fast Hopper
– Encryption: UK
177
JTRS Waveforms
• Link 16 (MIL-STD-6016, STANAG 5516)
–
–
–
–
–
–
Bandwidth: 3 MHz
Center Frequency Range: 960-1215 MHz
Data Rates: 118/236 Kbps w/FEC
Waveform Type: Very Fast Hopper, TDMA/CPSK
Encryption: Thornton
Fast Hopping requires fast synthesizer settling times (hard
to do with synths that tune 2 MHz to 2 GHz)
– TRANSEC expires very quickly
– TDMA slots very short
178
JTRS Waveforms
• UHF FM Public Service APCO 25(LMR)
–
–
–
–
Bandwidth: 5 and 12.5 KHz
Center Frequency Range: 380-420 MHz
Data Rates: 25 KHz, 16 Kbps
Encryption: DES-OFB
• VHF FM Public Service (APCO 25) LMR
– Bandwidth: 6.5, 12.5, 25KHz
– Center Frequency Range: 138-150.8 MHz and 162-174 MHz
– Encryption: DES-OFB
179
JTRS Waveforms
• Link 4A (STANAG 5504,TADIL C, MIL-STD-188-203-3)
– Bandwidth: 25KHz
– Encryption: none
•
TADIL C is a one- or two-way air intercept control (AIC) link that operates
in the UHF frequency spectrum. The link is unsecured, not jam-resistant,
and uses a message standard specifically developed to satisfy an AIC.
TADIL C, developed in the late 1950s for control of airborne interceptors,
includes Carrier Inertial Navigation System (CINS) and Automatic Carrier
Landing System (ACLS) capabilities
•
Very tough terminal latency requirement
180
JTRS Waveforms
• Integrated Broadcast Service Module (IBS-M)
– Bandwidth: 5 and 25KHz
– Data Rates: 19.2 Kbps (tunable 2.4, 4.8, 9.6, 19.2)
– Waveform Type: BPSK, SOQPSK, LOS or SATCOM TDMA
– Encryption: KGV-11
•
IBS is the follow on to TRIXS, TRAP/TADIXS/TDDS and TIBS
181
JTRS Waveforms
• STANAG 4193 Mode S Level 4/5
– Bandwidth: 3.5 MHz/3 MHz
– Data Rates: UK
– Performance Requirements: Low Latency
– Encryption: UK
•
Identification Friend-or-Foe (IFF) Mark XII System and Air Traffic
Control Radar Beacon System
182
JTRS Waveforms
• DWTS
– Digital Wideband Transmission System
– Data Rates: 144, 256, 288, 512, 1024, 1544, 2048 Kbps
– Performance Requirements: T
– Encryption: UK
•
Amphibious Readiness group to
U.S. Army MSE System and
shore-based U.S. Marine Corps
AN/MRC-142 System.
183
JTRS Waveforms
• Soldier Radio / WLAN Soldier Radio
– Center Frequency Range: 1.75 –1.85 GHz
– Data Rates: 16 Kbps / 1 Mbps
– Performance Requirements: T
– Encryption: UK
•
•
Supports digital 16 Kbps voice and data at 1 Mbps
WLAN Soldier compliant with IEEE 802.11b, 802.11e and 802.11g.
184
JTRS Waveforms
• COBRA (Collection of Broadcasts from Remote Assets)
– Bandwidth: N/A
– Data Rates: N/A
– Performance Requirements: TDMA, LPI/LPD
– Encryption: UK
185
Miscellaneous
JTRS Waveforms
•
•
•
•
ANSCAI
Cellular (AMPS, CDMA, GSM, etc.)
Link 22, NATO Improved Link (NILE) 11
MSS (Mobile Satellite Service)
– Center Frequency Range: 1.61 – 2 GHz
– Usage: Wireless voice, data, Internet access, PCS,mobile services
186
Table of Contents
•
•
•
•
•
•
•
•
JTRS Clusters
JTRS Compliance
187
Lessons Learned
• Life Cycle Cost Comparison
– Only a few examples to pull from
• Quantitative data not generally available
– Most concerned with post-manufacture upgrade
– Based on experience with FOUR SDR programs
– Lesson One
• All programs overran estimates ≥ Order of Magnitude
• At least a factor of two and as much as a factor of eight
– Lesson Two
• Simultaneous development of multiple waveforms on
virgin system software / hardware is a complete waste
• Lack of a uniform development model across waveforms
is a waste
188
Lessons Learned
– Lesson Three
• Infrastructure team not cognizant of Waveform
requirements
– Lesson Four
• Once deployed on target hardware don’t abandon
simulated development environment
• When hardware upgrade rolls in, must be superbly
confident in the behavior of the software in order to
isolate those nasty bus glitches, etc.
– Lesson Five
• Tried and true legacy software designs generally not
tolerant enough to large fluctuations in CORBA/TCP-IP
based communications protocols or multi-user run-time
189
Lessons Learned
– Lesson Six
• Some nasty glitches are not the fault of the APPARENT
offender. Quite often task 17 crashes because task 34
overran its stack.
• Heisenberg bugs
• A pervasive system-wide design methodology must be
enforced across all development units
• No cowboy programmers tolerated in a multi-threaded
environment
– Lesson Seven
• It is harder to shut down a waveform cleanly (i.e., no
memory leaks) than it is to bring it up.
190
Lessons Learned
• Development Environments
– Brand New Toys
• Everyone wants the latest point-n-click wiz bang tool
• Let the kids play with toys
• Make your engineers work with tools
– Bells and Whistles and Learning Curves
• Cost One:
• Cost Two:
Capitalize the new toy
Capitalize the engineer to learn about it
– Bench-marking
• Breaking in a new toy must be specific to its intended
application
• Encourage infrastructure folks to interact regularly with the
applications engineers
– Stability
• Read your EULA; it’s always your fault, never theirs
191
Lessons Learned
• Infrastructure
– For JTRS includes mature, fully characterized
Core Framework / CORBA / OS combinations
– Make/Buy
– The Pseudo-Waveform and Confidence Testing
– Usually overlaps Waveform Application
Development
– Finger pointing: Applications vs. Infrastructure
192
Lessons Learned
• Testing
–
–
–
–
–
Impossible to test every combination
Understanding what combinations are benign
Customer experience with legacy comms
Customer experiences with Microsoft
0.999 and real-time distributed software
One of the benefits of Software Radio is quick turns on bug
fixes. Best strategy is to admit outright that there will be
hundreds of bugs detected in the first few months and put
assets in place to deal with that flow.
Timeline : 15 minutes, 3 hours, overnight, over the weekend
193
Lessons Learned
• Regression Testing
–
–
–
–
Understand what combinations are benign
Memory leak / fragmentation testing a must
Marine testing a must – testing to break
Automated test scripts
• enhance turn-around
• lower recurring labor costs
– Combinations of Waveforms
• If all developers play by the rules this huge degree of
freedom goes away
194
Lessons Learned
• Regression Testing
– SDR accommodates rapid deployment of new
functionality
• Include customer in the loop
• Expect an order of magnitude MORE defect reports than in
legacy communication systems
• Build this capability in to your planning up front
– Once over-the-weekend reliability is achieved it
becomes impractical to conduct that level of testing
and still have timely updates to the customer
195
The Future
• Technology Trends - Here comes the buzz
– Unfortunately many books, products, and devices
are already “SDR Ready” or “JTRS Compliant”
– Where does it make sense to deploy S/W radio
technology?
• Large number waveforms
• Large number of channels==JTRS
– A lot of room for innovation
• Hardware Advances
• Software Method Advances
196
The Future
•
JTRS has mandated an open systems approach to communication
systems procurement
– Cost per channel is still too high for commercialization
– After DoD, Public Safety is next best beneficiary
197
Additional References
For further study
1.
2.
3.
4.
5.
6.
Communication Receivers: DSP, Software Radio, and Design,
3rd Ed., Rohde and Whitaker, 2001, ISBN 0-07-136121-9
Software Radio Technologies: Selected Readings, edited by
Mitola and Zvonar, 2001, ISBN 0-7803-6022-2
Software Radio Architecture: Object-Oriented Approaches to
Wireless Systems Engineering, Mitola, ISBN 0-471-38492-5
Software Defined Radio: Enabling Technologies, Tuttlebee,
2002, ISBN 0-470-84318-7
Software Defined Radio: Origins, Drivers and International
Perspectives, Tuttlebee, 2002, ISBN 0-470-84464-7
Software Radio: A Modern Approach to Radio Engineering,
Reed, Prentice Hall, 2002, ISBN 0-13-081158-0
198
Acronyms
ABCS
AGC
AJ
ALE
APCO
API
ASIC
ATC
BREW
C4ISR
CDH
CDMA
CF
COMSEC
CORBA
COTS
CSMA
CTD
DAMA
DISA
DMR
DPD
DSP
Army Battle Command System
Automatic Gain Control
Anti-Jam
Automatic Link Establishment
Association of Public Safety Communications Officials
Application Specific Integrated Circuit
Air Traffic Control
Binary Runtime Environment for Wireless
Command, Control, Communications, Computers,
Intelligence, Surveillance and Reconnaissance
CTIC/DS-101 HYBRID
Code Division Multiple Access
Core Framework
Communications Security
Common Object Request Broker Architecture
Commercial Off The Shelf
Carrier Sense Multiple Access
Concept and Technology Development
Demand Assigned Multiple Access
Defense Information Systems Agency
Digital Modular Radio
Digital Signal Processor
EPLRS
FEC
FCC
FCS
FPGA
GIG
GPP
HAL
HF
IDL
IEEE
IMD
INFOSEC
IP
IPC
JAQL
JCIT
JIEO
JPO
JTEL
JTRS
JTA
KPP
LOS
Enhanced Position Location Reporting System
Forward Error Correction
Federal Communication Commission
Future Combat System
Field Programmable Gate Array
Global Information Grid
General Purpose Processor
Hardware Abstraction Layer
High Frequency
Interface Definition Language
Institute of Electrical and Electronic Engineers
Inter-Modulation Distortion
Information Security
Internet Protocol
Inter Processor Communication
JCIT Application Queue Library
Joint Combat Information Terminal
Joint Interoperability and Engineering Organization
Joint Program Office (JTRS)
JTRS Technical Laboratory
Joint Tactical Radio System
Joint Technical Architecture
Key Performance Parameter
Line Of Sight
199
Acronyms
LMR
LPD
LPI
MAC
MEMS
NTDR
OE
OF
OFDM
OMG
ORB
ORD
OS
OTAR
OTCIXS
PIM
PMCS
POSIX
PSK
QAM
RFP
RT
SAD
SCA
SCD
Land Mobile Radio
Low Probability of Detection
Low Probability of Intercept
Media Access Control
Micro-Electronic Mechanical System
Near Term Digital Radio
Operating Environment
Objective Force
Orthogonal Frequency Division Modulation
Object Management Group
Object Request Broker
Operational Requirements Document
Operating System
Over The Air Rekey
Officer in Tactical Command Information Exchange Service
Platform Independent Model
Programmable Modular Communication System
Portable Operating System Interface
Phase Shift Keying
Quadrature Amplitude Modulation
Request For Proposal
Real Time
Software Communications Architecture
SDD
SDR
SEM-E
SIDS
SINCGARS
SPD
SSEI
STANAG
TADIL-A
TADIXS-B
TCP
TDMA
TIBS
TRAP
TRANSEC
UML
VHF
WIN-T
WNW
System Design and Demonstration
Software Defined Radio
Standard Electronic Module-Format E
Secondary Imagery Dissemination System
Single Channel Ground and Airborne Radio System
System of Systems Engineering and Integration
(NATO) Standardization Agreement
Tactical Data Information Link - A
Tactical Data Information Exchange System - B
Transmission Control Protocol
Time Division Multiple Access
Tactical Information Broadcast System
Tactical Related Applications
Transaction Security
Universal Modeling Language
Very High Frequency
Warfighter Information Network - Tactical
Wideband Networking Waveform
200

Joint Tactical Radio System - Space Coast Communication Systems

Transcription

Similar documents

Influences from coast to coast to coast

MIDS JTRS - Data Link Solutions

3* Saboia Hotel - Concorde Travel

Yesterday I left the ECETI Ranch, to pursue some other callings, one

CARREFOUR RICHELIEU

space coast credit union job fair space coast credit union job fair

Killigarth Manor

Autumn 2014 - Cap Juluca

CF MASONVILLE PLACE - Neo

CP31 Treyarnon Bay The Coast Path leading into the South West