Upload
real-time-innovations-rti
View
458
Download
1
Tags:
Embed Size (px)
Citation preview
Mark Swick – RTI Webinar
Principal Applications Engineer, RTI
Two Approaches You Must Consider when Architecting Radar Systems
© 2015 RTI
Agenda
• Background– Radar (sensor) systems
• Architecture Commonality– Generic system components
• Data Centric Design Patterns– DDS patterns uniquely suited to data
requirements
• Data Commonality– Making sense of it all
• Summary
© 2015 RTI
Background
What is a Radar?
© 2015 RTI
Defintion
• radar (rāˈdär)
(an acronym derived from the phrase RAdio
Detection And Ranging)
1. a device or system for determining the
presence and location of an object by
measuring the direction and timing of radio
waves.
© 2015 RTI
© 2015 Real-Time Innovations, Inc.5
Air Search Radar
RADAR
© 2015 Real-Time Innovations, Inc.6
Air Search Ground Radar
RADAR
© 2015 Real-Time Innovations, Inc.7
Ships and Radars
RADAR
© 2015 Real-Time Innovations, Inc.8
Aircraft and Radar
RADAR
© 2015 Real-Time Innovations, Inc.9
Ground Portable Radar
RADAR
© 2015 Real-Time Innovations, Inc.10
Long Lived Radar
RADAR
© 2015 Real-Time Innovations, Inc.11
Dish /= Radar
RADARNOTRADAR
© 2015 Real-Time Innovations, Inc.12
Passive Listening
NOTRADARRADAR
© 2015 Real-Time Innovations, Inc.13
Radar inside
RADAR
Software Architecture
What do these systems have in
common?
© 2015 RTI
Commonality in Architecture
© 2013 RTI
Receiving Subsystem
Transmitting Subsystem
UserSubsystem
Signal Processing Subsystem
Command and Control Subsystem Time and
Position Subsystem
StorageSubsystem
Tracking Subsystem
Front End(Harder Real-Time)
Back End(Softer Real-Time)
Point to Point Communications Architecture
© 2013 RTI
Receiving Subsystem
Transmitting Subsystem
Tracking Subsystem
Command and Control Subsystem
UserSubsystem
Signal Processing Subsystem
Time and Position
Subsystem
CooperatingSystem
StorageSubsystem
?
Data Centric Communications Architecture
© 2013 RTI
Receiving Subsystem
Transmitting Subsystem
Tracking Subsystem
Command and Control Subsystem
UserSubsystem
Signal Processing Subsystem
Time and Position
Subsystem
CooperatingSystem
StorageSubsystem
TIME
SENSO
R
DATA
TRA
CK
S
STATE
PO
SITION
CO
MM
AN
D
DISP
LAY
DDS DDS
Non-real-time Soft real-time Hard real-time Extreme real-time
Java/RMIJava/JMS
CORBA
MPI
Java RTSJ (soft RT) RTSJ (hard RT)
Web Services
Mes
sag
ing
Tec
hn
olo
gie
s a
nd
Sta
nd
ard
s
Data Distribution Service / DDS
RT CORBA
Adapted from NSWC-DD OA Documentation
RTI Data Distribution Service spans a
very wide spectrum of application needs
© 2015 RTI
Open Systems
• Open Systems– Are defined sufficiently that
so that multiple organizations can work cooperatively on the same or separate sub-components
– Have requirements which are stable over a sufficient length of time to allow for concurrent development
– Are documented fully and openly to the development community
– Are not under the control of any one firm or vendor.
© 2015 RTI
© 2015 Real-Time Innovations, Inc.20
Key Non-Functional Requirements for a System
• Interchangeability
(Portability)
• Replaceability
• Extensibility
• Integratability
System
System A
System B
System
System B
System C
F(A,B) Results inX
F(C,B)Results inX
A and C provideEqual Capability
© 2015 Real-Time Innovations, Inc.21
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• Extensibility
• Integratability
System
System A
System B
System
System B
System C
F(A,B)Results inX, Y, Z
F(C,B) Results inY, Z, W
C is NOT an Equal Capability, but it Is a suitable substitute
© 2015 Real-Time Innovations, Inc.22
System
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• Extensibility
• Integratability
System
System B
System C
F(A,B) Results inX
F(A,B,C)Results inX and Y
System A
System
System B
System A
System C
F(C) Results inY
© 2015 RTI
© 2015 Real-Time Innovations, Inc.23
System C
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• Extensibility
• Integratability
System B
F(A)Results In X
F(A,B)Results inZ, where Z=G[f(X), g(Y)]
System A
System B
System A
F(B)Resultsin Y
© 2015 RTI
Infiniband
Subsystem B
Data Centric Integration Solution
1/30/2015 24
• Technical
Interoperability
– Infrastructure & Protocol
• Syntactic
Interoperability
– Common Data Structure
• Semantic
Interoperability
– Common Data Definition
TRA
CK
S
STATE
CO
MM
AN
D
DISP
LAY
DDS DDS
Shared Memory
Subsystem A
TIME
SENSO
R D
ATA
STATE
PO
SITION
CO
MM
AN
D
DISP
LAY
DDS DDS
IPv6
Subsystem C
TIME
SENSO
RD
AA
A
TRA
CK
S
STATE
PO
SITION
CO
MM
AN
D
DISP
LAY
DDS DDS
TIME
STATE
PO
SITION
DISP
LAY
DDS DDS
Mediation Mediation
Mediation
IPv4
© 2015 RTI
Core ArchitectureBuilt on Standard and Open Interfaces
RTI Connext DDS
Professional, Micro or Cert
Operating System (Linux, LynxOS, Windows, VxWorks, QNX, ….)
Optional FACE Transport Services API to DDS Mapping
25
Intra-process
Sharedmemory
ARINCPorts
SocketsOther/CustomR
TI T
SS L
ibra
ry
FACE Transport Services (TS) API
RTI transport API
OMG DDS API
DDS-RTPS protocol
Pluggable transports
© 2015 RTI
Optimized, Location-Independent Communication
• Physical transport(s) configurable at integration time
• Applications can use multiple transports concurrently
• Transport(s) configured per application
26
Transport Use
Intra-process Within the same address space (process)
Shared memory Between processes in the same partition
ARINC ports Within a node; within or between partitions
Sockets(UDP unicast or multicast)
Within or between nodes, including over Ethernet
Low-bandwidth Over satellite or radio links (no IP requirement)
Custom Over custom networks or busses (via plug-in API)
© 2015 RTI
Connection Mechanism Comparison
27
RTI
DD
S
CO
RB
A
Sock
ets
PO
SIX
Qu
eu
es
Shar
ed
me
mo
ry
Qu
eu
ing
po
rts
Sam
plin
g p
ort
s
Proximity Intra-partition ● ● ● ● ● ● ●
Inter-partition ● ● ● ● ●
Inter-node ● ● ●
Multiple concurrently ●
Distribution One-to-one ● ● ● ● ● ● ●
One-to-many ● ● ● ● ●
Many-to-one ● ● ●
Many-to-many ● ●
● Unreliable
© 2015 RTI
DDS Design Patterns
How do they apply?
© 2015 RTI
Data Centric Interoperability
TIME
SENSOR DATA
TRACKS
STATE
POSITION
COMMAND
DISPLAY
DD
SD
DS
Time/Position Subsystem
ExternalSubsystem
Track Subsystem
Med
iatio
n
Med
iati
on
© 2015 RTI
Mediation : RTI Routing Service
30
Custom-DDS Translate – Routing Service
CustomPlugin-In DW
Mode:ON_DOMAIN
Mode:ON_ROUTE
<<input>> <<output>>
<<participant_1>> <<participant_2>>
Route
Data Flow
DDS-DDS Translate – Routing Service
DR DW
Mode:ON_DOMAIN
Mode:ON_ROUTE
<<input>> <<output>>
<<participant_1>> <<participant_2>>
Route
Data Flow
DDS/RTPS Source DataDDS/RTPS Source Data
© 2015 RTI
© 2015 Real-Time Innovations, Inc.31
Data Distribution Design Patterns
TIME
SENSOR DATA
TRACKS
STATE
POSITION
COMMAND
DISPLAY
DD
SD
DS
Objective/State
One-to-Many
High Throughput
© 2015 Real-Time Innovations, Inc.32
Objective/State Design Pattern
3 States:1. Current
2. Objective
3. Requested Objective
2+ Roles (special case of Observer pattern):1. Effector
• Provides Current State and Objective State
• Observes Requested Objective State
2. Requester• Provides Requested Objective State
• Observes Current State and Objective State
3. (Observer—with respect to any state)
Current
State
Objective
Statechange
Effector executes this
Requested
Objective
State
Requester
changes
this
32
Objective/State with DDS
© 2012 RTI • COMPANY CONFIDENTIAL
RequesterEffector
Durability QoS policy:– Current, Objective: Transient_Local– (Requested) Objective: Volatile
History QoS policy:– Current, Objective: Keep Last n– Requested Objective: Keep Last 1
Data Bus
if long-running
if short-running
Current
State
write
Objective
State
write
Requested
Objective
State
read,
filter
request processed?
feedback
Current
State
read,
filter
Objective
State
read,
filter
same typesame or different types same key
Requested
Objective
State
write
© 2015 Real-Time Innovations, Inc.34
One-To-Many Design Pattern
Observation: More common in naturally data-centric interactions
– “Hey, look at this” vs.
– “Hey you: do this”
Consumer
Consumer
Consumer
…
Producer
1
2
n
© 2015 Real-Time Innovations, Inc.35
One-To-Many : Multicast Benefits
• Communicate to many consumers at the same time much more cheaply than one-to-one to each of them
– Less network traffic
– Lower latency (fewer socket sends)
– Lower writer-side CPU
• Can be reliable or “best effort”
– Configurable using DDS Quality of Service
© 2015 Real-Time Innovations, Inc.36
One-To-Many : Multicast Challenges
One-to-many reliability isn’t free
Actual RTI multicast results
Number of Readers
20
0-B
yte
Sam
ple
s p
er S
eco
nd
Why?1. Slow consumers throttle writer2. Reliability bandwidth overhead
Unicast expectation
Perfect multicast expectation
High Throughput Design Pattern
• Do samples arrive continuously or at a
high periodic rate?
• Is the transport saturated?
High Throughput Periodic Data
• RTI Connext…
– Sends synchronously by default
– Supports batching for high periodic rates
– Supports multiple reliability paradigms
– Supports receive processing in receive thread
or application thread
High Throughput over Constrained Network
• RTI Connext…
– Supports configurable MTU sizes
– Supports batching in a manner with reduces protocol header overhead
– Supports a Low-Bandwidth network plugin with header and data compression
– Supports a “multi-channel” feature to send data over different NICs as a function of data content
Reliable High Throughput
• Lots to consider– Writer must keep data for potential retransmission
– Latency unpredictability
– Readers must behave
– Design for desired behavior if data lost…• Declare failure and stop
• Report error and keep going
• Delay writing for readers to catch up
• Do nothing
• …
The Data Matters
How do you Define & Design it?
© 2015 RTI
MODEL
A model is anything used in any way to represent something
else
42© 2015 RTI
DATA MODEL
A data model is a representation that describes the data about
the things that exist in your domain
43© 2015 RTI
Model and Implementation
• Model provides the Context and Semantics
– Containment and relationships
– May not necessarily be in the messages
• Messages can be compact
– Use the model for context
– ‘Know’ the association between a command and a status
• Using machine readable context
– Can generate the system appropriate mediation
– Really only need the ID of ‘what’ in the message
I© 2015 RTI
DDS Natively Supports Interoperable Data Models
• DDS messages are strongly typed
• OMG IDL basis for native DDS Data Model schema– XML, XSD, also supported
– Apps use target code generated by RTI’s IDL compiler
• DDS natively understands data– Type safety
– Heterogeneous interoperability (languages, CPUs)
– Wire efficiency (minimizes metadata)
– Enables middleware-level filtering (including at source)
– Eases integration (explicit interfaces)
45
Platform Data Model
RTI IDL Compiler
C
C++
Java
Ada
Include in application source
© 2015 RTI
Summary
What were those two things, anyway?
© 2015 RTI
Create an Architecture Consistent with Life Cycle
• Radar systems are often extremely long-lived
– Much longer than consumer product life-cycle
– Actively design for change with Data Centric
architecture
• Anticipate Multiple Technical Refresh cycles
– Open architectures and standards are key to
cost containment
– Know your data
I© 2015 RTI
Focus on Domain Expertise
• Mechanical Design
• Algorithm Design
• Custom Hardware Design
• Compute plant and communications are areas of constant change
– Communication Middleware isolates system-specific software from processor and network changes
– Changes inevitable over system life-cycle
I© 2015 RTI
Start using DDS Today!
Download the FREE complete RTI Connext DDS Pro package for Windows and Linux:
• Leading implementation of DDS• C, C++, C#/.NET and Java APIs• Tools to monitor, debug, test, visualize and
prototype distributed applications and systems• Adapters to integrate with existing applications and
IT systems