two approaches you must consider when architecting radar systems

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


Air Search Ground Radar

RADAR


Ships and Radars

RADAR


Aircraft and Radar

RADAR


Ground Portable Radar

RADAR


Long Lived Radar

RADAR


Dish /= Radar

RADARNOTRADAR


Passive Listening

NOTRADARRADAR


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


Tracking Subsystem

Command and Control Subsystem

UserSubsystem


Time and Position

Subsystem

CooperatingSystem

StorageSubsystem

?

Data Centric Communications Architecture

© 2013 RTI

Receiving Subsystem


Tracking Subsystem

Command and Control Subsystem

UserSubsystem


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


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




• 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


System



• 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


System C



• 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


Data Distribution Design Patterns

TIME

SENSOR DATA

TRACKS

STATE

POSITION

COMMAND

DISPLAY

DD

SD

DS

Objective/State

One-to-Many

High Throughput


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


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


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


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

• …

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

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

two approaches you must consider when architecting radar systems

Software

lived radar radar

radar systems

ground portable radar

rtiair search radar

radars radar

radar radarnotradar

air search ground radar

nonreal time