the promise of interoperability

Your systems. Working as one. Your systems. Working as one.

The Promise of Interoperability

Practical efficiency for large system software development

Interoperability Challenge

© 2012 Real-Time Innovations, Inc. 2

2

GVA DEF STAN 23-09

Who Cares About OA?

© 2012 RTI 3

UKMOD GVA, etc.

Why Interoperable Open Architecture?

So we can afford our future…


RTI Experience: Real-Time Infrastructure


RTI Background

• Market Leader – Over 70% DDS mw market share1

– Largest embedded middleware vendor2

• Standards Leader – Active in 15 standards efforts – OMG Board of Directors – DDS authors

• Real-Time Pedigree – Founded by Stanford researchers – High-performance control, tools history

• Maturity Leader – 500+ designs – 350,000+ licensed copies – TRL 9

© 2012 Real-Time Innovations, Inc.

1Embedded Market Forecasters 2VDC Analyst Report

7

2008

Global Support and Distribution


RTI Connext™: Edge to Enterprise

RTI DataBus™

Connext

Micro

Pub/Sub API (DDS subset)

Small Device Apps

Connext

DDS

Pub/Sub API (Full DDS)

DDS Apps

Connext

Messaging

Messaging API (DDS++ & JMS)

General-Purpose Real-Time Apps

Connext

Integrator

Adapters

Diverse Apps/Systems

Administration

Monitoring

Recording

Replay

Persistence

Logging

Visualization

Common Tools and Infrastructure Services


Tales from the pointy end…


Interoperability


Interoperability

Bu

sin

ess

Mo

del

s

Data Centric Approach

• Data-centric middleware maintains state • Infrastructure manages the content • Developers write applications that read and update a

virtual global data space


Persistence Service

Recording Service

Source (Key)

Power Phase

WPT1 37.4 122.0 -12.20

WPT2 10.7 74.0 -12.23

WPTN 50.2 150.07 -11.98

Popular standards: DDS API, wire spec

13

Controlled State

• Data centric

– Single source of truth

– Known structure

– Clear rules for access, changes, updates

• Technologies

– Database

– Data-centric middleware

12/4/2012 © 2012 RTI • COMPANY CONFIDENTIAL 14

DDS: the Data Bus Standard

• Data Distribution Service from OMG • OMG: world’s largest systems software

standards org – 470+ members – UML, DDS, SysML, MoDAF, DoDAF,

more

• DDS: open & cross-vendor – Standard API enables choice of

middleware – Standard wire spec enables subsystem

physical interoperability – ~10 competitive implementations (!)


Cross-vendor source portability

Cross-vendor interoperability

DDS-RTPS Protocol Real-Time Publish-Subscribe

Distribution Fabric

DDS API

15

Government Adopts DDS

• Dominant in military – DISA: DISR mandated – Navy: Open Architecture,

FORCEnet – Air Force, Navy and DISA: NESI – Army, OSD: UCS – NATO, UK MOD, South Korea,

many more

• Many other applications – Air traffic control, industrial

automation, transportation, medical

• Hundreds of active programs – Multiple interoperable

implementations


17

Interoperability between the applications demonstrated by six different vendors in 2012

OCI ETRI PrismTech IBM RTI TwinOaks


Is This Interoperability?


Semantic

Syntactic

Technical

• Technical Communications (how to share data)

• Syntactic Interfaces (what data to share)

• Semantic data dictionary (what data means)

What are we Trying to Achieve?

© 2012 RTI 19

Open Architecture Requires Interoperability at a Higher Level Than Key Interfaces.

Interchangeability

Integrateability

Extensibility

Interoperability: all of the above without rewriting everything

Interoperability


Interoperability

Bu

sin

ess

Mo

del

s

Architecture Efforts


AF Avionics

Navy CCRL

Army COE

OSD UCS

GVA DEF STAN 23-09

22

Unmanned Aircraft System Control Segment (UCS)

UNCLASSIFIED - Pubic Release 12-S-1669

OA Acquisition Objectives

To remove the traditional barriers to Effective Competition in the

UAS Control Segment and provide market access to a broad,

heterogeneous industrial base of software providers in an agile

acquisition and integration environment.

Pubic Release 12-S-1669


OUSD ST&S UAS Common Architecture

DoD Open AppStore Marketplace 30+ PoR ready Apps & Demos

PoR: TCS, Block 50, OSRVT, and GSRA (TBD)

DoD Contract Guidebook & IP Rights Open Business Model for UAS GCSs RFP Language for UAS GCSs

Open GCS Architecture for UAS Joint HMI Style Guide for GCSs

2.1.1 Model HMI Guide

New OSD Guidance is Needed Existing UCS ADMs: OSD, Army, Navy,

New UCS ADMs: GSRA AF


UCS Participants

25

FACE Architecture

© 2012 RTI 27

FACELayered 16Mar12

Interface Hardware

(i.e. MIL-STD-1553, Ethernet)

Platform

Devices

Platform

Sensors

Platform

Displays

User Input

Devices

Platform

Radios

Other

Transports

IO

Operating System Segment

Portable Components Segment

Common Services and Portable

Applications reside here

Platform Specific Services Segment

Standardized application-level data products and

indirect hardware access are provided by this

segment

I/O Services Segment

Standardized, but indirect hardware

access is provided by this segment

FACE defined

interface set

FACE defined

interface set

FACE defined

interface set

Hardware

Device Drivers

Transport Services Segment

Ve

nd

or

Tra

nsp

ort

Ve

nd

or

Tra

nsp

ort

Ve

nd

or

Tra

nsp

ort

Ve

nd

or

Tra

nsp

ort

All application I/O, including inter-application I/O is

achieved through message based transport

middleware which resides in this segment.

TS

TS

FACE Vision: Interoperability

© 2012 RTI 28

Platform YPlatform X

Radio RadioOFP Sensor Display CDU Input Sensor Display InputCDU

FACE Application “X”

The same FACE application is now

portable across war fighting platforms

OFP

The addition of

FACE Computing Platform Software

enables application portability across

dissimilar war fighting platforms

FACE Computing Platform

FACE Application”X”

FACE Computing Platform

FACE and Partitioning

© 2012 RTI 29

Operating System Segment

APEX POSIXPOSIXPOSIX

I/O Services

POSIX POSIX

FACE

I/O

Interface

Lib

FACE Transport

Services Lib

FACE Transport

Services Lib

POSIX

Portable

Component

FACE

Transport

Services

Lib

P

ort

ab

le

C

om

po

ne

nt

FACE

I/O

Interface

Lib

I/O Services

Partitioned FACE Environment

Device

Driver

Device

Driver

FACE Transport

Services Lib

Common

Services

Lib

Common

Service

Lib

25Jan2012

Platform Common

Services

HMFM

Platform

Device

Services

Graphics

Services

P

ort

ab

le

C

om

po

ne

nt

Common

Service

Lib

FACE

I/O

Interface

Lib

Portable

Component

Common

Services

Lib

POSIX

FACE

Transport

Services

Lib Device

Driver

FACE

Transport

Services

Lib

FACE

I/O

Interface

Lib

Connext Micro

RTI DataBus™

Connext

Micro

Pub/Sub API (DDS subset)

Small Device Apps

Connext

DDS

Pub/Sub API (Full DDS)

DDS Apps

Connext

Messaging

Messaging API (DDS++ & JMS)

General-Purpose Real-Time Apps

Connext

Integrator

Adapters

Diverse Apps/Systems

Administration

Monitoring

Recording

Replay

Persistence

Logging

Visualization

Common Tools and Infrastructure Services

© 2012 RTI 30

RTI FACE Implementation

12/4/2012 © 2012 RTI • COMPANY CONFIDENTIAL 31

MILS FACE Compliant OS

Safety Level A Safety Level C

Safety Level D

RTPS

APEX

OFP

TSS Micro

Fusion

Data

Store

Signature

Analysis

DDS

Sensors

TSS Micro

I/O Service

PSS Service

TSS Micro TSS Micro

Auto

Routing

DDS

RTI’s Role in Interoperability Efforts

• Thought & standards leadership – UCS (ground stations)

• Platform architecture (App PSM) subcommittee chair • Data model key architect

– FACE (avionics) • Key contributor to architecture & data model

– DDS • Prime author, Board, SIG co-chair

• Products – Supplying RTI DDS to UCS (entire organization is an IC) – Building TRL-9 product for FACE TSS

• Services – Guidance implementation and compliance – RTI product application – Use case discovery & architecture study

© 2012 RTI 32

Connext Micro

• Resource-constrained systems – Stringent SWaP requirements – Small memory footprint (~200KB library) – Low CPU load (< 10%)

• Typical target – 8MB RAM/32MB flash – Low-power CPU – Embedded or no operating system

• Safety certification in progress – Cert to DO178C-level A – Appropriate for avionics, medical

© 2012 RTI 33

User-Configurable Feature Set

DDS API Subset

Transport API

Base-line configuration

Static Discovery

OS API

User Application

UDPv4 Linux

VxWorks APEX Dynamic Discovery

Queue API

Listeners

Required plug-in components

Linear Q

Keyed Q

Discovery API

Reliability

Durability & History

Other QoS

Optional APIs

Shared memory

VxWorks 653

Co

mp

ile-t

ime

op

tio

ns

RTPS

Connext Micro

© 2012 RTI 34

Interoperability


Interoperability

Bu

sin

ess

Mo

del

s

Open Business Models for Infrastructure Vendors

Enabling the basis for interoperability


The Great OSS Biz Model Quest

• “Free beer” – Pay only for support & services – A poor biz model

• “Free speech” – Worked for Linux – Community development challenge

• “Free puppy” – Hidden adoption expense

• Freemium (Dual licensing) – Hard balance between “good

enough” & paid


What Do Users Want from “Open Source”?

• No license cost

• Can modify and distribute modifications

• Community development

• Community forum

• Use for any application

• Access (right) to source code

• Freely downloadable


Highly Distributed Real-Time Systems

• Many applications, processors – 100+ processors in a car

– 1,000+ processors on a ship

– 100k+ processors in an industrial system

– 40M+ lines of code

• Many people & teams – Crosses divisions, companies, orgs

– Includes end users, suppliers, subs

– 50+ s/w suppliers for a modern naval ship


What Is an Infrastructure Community?

• Any community sharing software – Seeking a common or interoperable

software infrastructure – Across projects, divisions, companies,

programs

• Examples – Software supply chains – Enterprises or corporate divisions – Government or industry standards

communities (FACE, UCS, COE, ICE) – Large projects

• “Everyone you care about”


Infrastructure Communities


IC: JHU APL

Paid commercial license

Scope: Project

Free Project

Free Project

Free Project Paid commercial

license Scope: Project


Scope: Project

IC: UCS


Scope: Project

Free Project

Free Project




Scope: Project

IC: Audi


Scope: Project

Free Project

Free Project




Scope: Project

41

OCS Model Summary

• Free, full source & binary DDS for IC – No cost, no hassle, no strings

– Latest version

– Share source & binaries

– Professional T&M support

• Low-cost commercial product for projects – Tools, advanced functionality, warranty, platforms

– Simple, open, per-developer pricing

– Starts at $995/developer

– No royalties or deployment fees


It’s Not “Approved” Open Source!

• It’s restricted to an IC – This is not OSI compliant or “Free software”

• But… – Within your IC: very open

– Outside your IC: why do you care?

– And it’s a better deal

• It maps well to the enduring infrastructure problem


Many Biz Model Needs

• Professional resources – Support all versions (free,

paid) – Offer professional guidance,

services

• No legal strings – Offer warranty and

indemnification – Control provenance – No copyleft; keep your IP

• Drive quality & usability – Enforce quality control – Push usability, docs, examples

• Ensure vendor partnership – Proactively develop to match

needs – Encourage latest technology,

no branches – Motivate features, usability,

quality, accessibility – Ensure vendor profitability

• Open, fair pricing – Offer usable free product – Predictably & reasonably

price advanced product – Bound support costs – Eliminate runtimes


What’s Important in a Model?

• Let you adopt without friction

• Support healthy vendor with known cost

• Encourage speculative vendor investment

• Retain your IP control

• Drive efficiency and low cost


Open Community Source Balance

• Open Community Source – Free, viral adoption – “Good enough” product – Support available

• Low friction upgrade – Advanced

functionality, tools, platforms, warranty

– Clear, reasonable fees without surprise


• IC model benefits – Provides you freedom

– Encourages vendor investment

– Lowers overall cost

Open Community Source Model

• Addresses real needs of customers

– Free, current, supported base product

– Powerful, low-friction upgrade

– Clean, open licensing

– Clean, open pricing

• Addresses real needs of vendor

– Encourages investment in product

– Supports strong relationship


Business Models for Government Acquisition

Achieving the promise of interoperability


The sole imperative to control software cost is to establish a stable team working on a single code base

-- Stan Schneider


Implications (!)

• “Use” is better than “reuse” – Stable teams imply continuous investment

• Code repositories are expensive branches – Even more expensive to revive

• “Government purpose rights” are escrow only – The IP without the team is inefficient

• “Community development” is a myth – At least for emerging products, there is no stable external

team

• The best structure for large projects is team/code pairs – Modularize by reducing team/code size => define

interfaces and architecture


Repository Competition Process

• Competition divorces team from code

• “Reuse” implies re-learn, re-design, re-build…and re-code

• Result is very expensive!


Creation

Team

Code Base

Team Team Team

Code Base

Competition

Team

Code Base

“Reuse”

Code-Team Competition Process


Code Base

Team

Create and Maintain Multiple Code-Team Pairs

for Each Module

Code Base

Team

Code Base

Team Compete these Pairs for

Each Module of Each Project

Code Base

Team

Build Project from Modules

Team

Code Base

Code Base

Team

Team

Code Base


How? Interoperability.

53

How Does Interoperability Cut Cost?

• Interoperability changes the nature of competition

• Modules are less expensive than code repositories

• Business model rewards more than hours…it rewards excellence


Achieving Cost Control


• Address interoperability levels with architecture – Communications (how to share data)

– Interfaces (what data to share)

– Semantic data dictionary (what data means)

• Reward module competition with acquisition policy – Look for opportunities to compete modules

– Encourage buy v build

– Reduce module granularity over time

• Strive to reduce code in “final assembly”

The Required Technology is Maturing


RTI Databus Peer-to-peer for performance

System-of-systems routing

RTI Databus

R

RTI Databus

R

R R

R R

R R

Hierarchical topology: • Peer-to-peer within a system • Automatically route data

up/down the hierarchy

Government’s Role…

• Treat infrastructure as a “1st class citizen”

– Enduring organizations to evolve it

– Structures across programs to leverage it

– Open acquisition model to encourage it

• Specify or own the right things

– Open semantic data model

– Open standard interfaces

– Code repositories only when forced


Why Invest in Interoperability?


Your systems. Working as one. Your systems. Working as one.

Working as One™

the promise of interoperability

Documents

realtime innovations

dds dds

realtime infrastructure

dds api dds

ddsrtps protocol realtime

dds dominant

interoperability challenge

rti connext