View On-Demand: http://ecast.opensystemsmedia.com/369 To dramatically reduce defense costs, Open Architecture (OA) offers a vision of complex systems of systems built from composable, replaceable modules. From its origins with the Navy's OA program for ship systems nearly 10 years ago, this design philosophy is spreading to military programs worldwide, including the the Future Architecture Computing Environment (FACE) for avionics, the Unmanned Air Segment Control Segment (UCS) for ground stations, the Army's Common Operating Environment (COE) and the UK's Generic Vehicle Architecture (GVA). These programs are defining technology and acquisition policy for the next generation of defense systems.

1. Your systems. Working as one.
The Promise of Interoperability
Practical efficiency for large system software development

2. Interoperability Challenge
© 2012 Real-Time Innovations, Inc. GVA DEF STAN 23-09 2
2

3. Who Cares About OA?
UKMOD
GVA, etc.
© 2012 RTI 3

4. © 2012 Real-Time Innovations, Inc. 4

5. Why Interoperable Open
Architecture?
So we can afford our future…
© 2012 Real-Time Innovations, Inc. 5

6. RTI Experience: Real-Time Infrastructure
© 2012 Real-Time Innovations, Inc. 6

7. 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
1Embedded Market Forecasters
2VDC Analyst Report
© 2012 Real-Time Innovations, Inc. 7

8. Global Support and Distribution
2008 © 2012 Real-Time Innovations, Inc. 8

9. RTI Connext™: Edge to Enterprise
Diverse
Small Device General-Purpose Apps/Systems
DDS Apps
Apps Real-Time Apps
Pub/Sub API Pub/Sub API Messaging API
Adapters
(DDS subset) (Full DDS) (DDS++ & JMS)
Connext Connext Connext Connext
Micro DDS Messaging Integrator
RTI DataBus™
Administration Recording Persistence
Monitoring Replay Logging
Visualization
Common Tools and Infrastructure Services
© 2012 Real-Time Innovations, Inc. 9

10. Tales from the pointy end…
© 2012 Real-Time Innovations, Inc. 10

11. Interoperability
Interoperability
Business Models
© 2012 Real-Time Innovations, Inc. 11

12. Interoperability
Interoperability
Business Models
© 2012 Real-Time Innovations, Inc. 12

13. Data Centric Approach
• Data-centric middleware maintains state
• Infrastructure manages the content
• Developers write applications that read and update a
virtual global data space
Source
Power Phase
(Key)
WPT1 37.4 122.0 -12.20
WPT2 10.7 74.0 -12.23
WPTN 50.2 150.07 -11.98
Persistence Recording
Service Service
Popular standards: DDS API, wire spec
© 2012 Real-Time Innovations, Inc. 13

14. 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

15. DDS: the Data Bus Standard
• Data Distribution Service from OMG
Cross-vendor source portability
• OMG: world’s largest systems software
standards org
– 470+ members
– UML, DDS, SysML, MoDAF, DoDAF,
more DDS API
• DDS: open & cross-vendor
– Standard API enables choice of
middleware Distribution Fabric
– Standard wire spec enables subsystem
physical interoperability
– ~10 competitive implementations (!) DDS-RTPS Protocol
Real-Time Publish-Subscribe
Cross-vendor interoperability
© 2012 Real-Time Innovations, Inc. 15

16. 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
© 2012 Real-Time Innovations, Inc. 16

17. Interoperability between the applications demonstrated by
six different vendors in 2012
OCI ETRI PrismTech IBM RTI TwinOaks
© 2012 Real-Time Innovations, Inc. 17

18. Is This Interoperability?
Semantic
• Technical Communications
Syntactic
(how to share data)
• Syntactic Interfaces (what
data to share)
• Semantic data dictionary
Technical
(what data means)
© 2012 Real-Time Innovations, Inc. 18

19. What are we Trying to Achieve?
Interchangeability
Integrateability
Extensibility
Interoperability: all of the above
without rewriting everything
Open Architecture Requires Interoperability at a Higher Level
Than Key Interfaces.
© 2012 RTI 19

20. Interoperability
Interoperability
Business Models
© 2012 Real-Time Innovations, Inc. 20

21. Architecture Efforts
Navy CCRL
AF Avionics OSD UCS
GVA DEF STAN 23-09
Army COE © 2012 Real-Time Innovations, Inc. 21

22. Unmanned Aircraft
System Control Segment
(UCS)
22

23. 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.
UNCLASSIFIED - Release 12-S-1669
Pubic
Pubic Release 12-S-1669

24. OUSD ST&S UAS Common Architecture
DoD Open AppStore Marketplace
Open GCS Architecture for UAS 30+ PoR ready Apps & Demos
Joint HMI Style Guide for GCSs PoR: TCS, Block 50, OSRVT, and GSRA (TBD)
2.1.1 Model
HMI Guide
DoD Contract Guidebook & IP Rights New OSD Guidance is Needed
Open Business Model for UAS GCSs Existing UCS ADMs: OSD, Army, Navy,
RFP Language for UAS GCSs New UCS ADMs: GSRA AF
UNCLASSIFIED - Pubic Release 12-S-1669

25. UCS Participants
25
UNCLASSIFIED - Pubic Release 12-S-1669

26. © 2012 Real-Time Innovations, Inc. 26

27. FACE Architecture
Layered 16Mar12
FACE
Operating System Segment
Portable Components Segment
Common Services and Portable
Applications reside here
FACE defined
TS
interface set
Transport Services Segment
Transport
Transport
Transport
Transport
Vendor
Vendor
Vendor
Vendor
All application I/O, including inter-application I/O is
achieved through message based transport
middleware which resides in this segment.
TS FACE defined
interface set
Platform Specific Services Segment
Standardized application-level data products and
indirect hardware access are provided by this
segment
FACE defined
IO interface set
I/O Services Segment
Standardized, but indirect hardware
access is provided by this segment
Hardware
Device Drivers
Interface Hardware
(i.e. MIL-STD-1553, Ethernet)
Platform Platform Platform User Input Platform Other
Devices Sensors Displays Devices
© 2012 RTI Radios Transports 27

28. FACE Vision: Interoperability
The same FACE application is now
portable across war fighting platforms
FACE Application “X” FACE Application”X”
FACE Computing Platform FACE Computing Platform
Radio OFP Sensor Display CDU Input Radio OFP Sensor Display CDU Input
Platform X Platform Y
The addition of
FACE Computing Platform Software
enables application portability across
dissimilar war fighting platforms
© 2012 RTI 28

29. FACE and Partitioning
25Jan2012
Component
Component
Portable
Portable
Portable Portable
Component Component
Platform Common
Services
Common Common Platform Common Common
I/O Services Services Services Device Service Service Graphics I/O Services
HMFM Lib Lib
Lib Lib Services Services
FACE FACE FACE FACE FACE FACE FACE
I/O I/O Transport FACE Transport FACE Transport I/O Transport FACE Transport Transport I/O
Interface Interface Services Services Lib Services Lib Interface Services Services Lib Services Interface
Lib Lib Lib Lib
Lib Device Lib Device Lib Device
Driver Driver Driver
POSIX APEX POSIX POSIX POSIX POSIX POSIX POSIX
Operating System Segment
Partitioned FACE Environment
© 2012 RTI 29

30. Connext Micro
Diverse
Small Device General-Purpose Apps/Systems
DDS Apps
Apps Real-Time Apps
Pub/Sub API Pub/Sub API Messaging API
Adapters
(DDS subset) (Full DDS) (DDS++ & JMS)
Connext Connext Connext Connext
Micro DDS Messaging Integrator
RTI DataBus™
Administration Recording Persistence
Monitoring Replay Logging
Visualization
Common Tools and Infrastructure Services
© 2012 RTI 30

31. RTI FACE Implementation
Safety Level A Safety Safety Level D
Level C
Data Auto
Store Routing
Sensors
I/O Service Signature
OFP Fusion
Analysis
PSS Service
TSS Micro
TSS Micro TSS Micro TSS Micro
DDS DDS
APEX
MILS FACE Compliant OS
RTPS
12/4/2012 © 2012 RTI • COMPANY CONFIDENTIAL 31

32. 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

33. 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

34. User-Configurable Feature Set
User Application
Listeners
Base-line configuration
Optional
Compile-time options
APIs
DDS API Subset
Reliability
Transport API OS API Queue API Discovery API
Durability &
History
RTPS
Other QoS
Static
UDPv4 Linux Linear Q Discovery
Dynamic
APEX VxWorks Keyed Q Discovery
Shared
VxWorks 653
memory
Required plug-in components
Connext Micro
© 2012 RTI 34

35. Interoperability
Interoperability
Business Models
© 2012 Real-Time Innovations, Inc. 35

36. Open Business Models for
Infrastructure Vendors
Enabling the basis for interoperability
© 2012 Real-Time Innovations, Inc. 36

37. 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
© 2012 Real-Time Innovations, Inc. 37

38. 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
© 2012 Real-Time Innovations, Inc. 38

39. 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
© 2012 Real-Time Innovations, Inc. 39

40. 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”
© 2012 Real-Time Innovations, Inc. 40

41. Infrastructure Communities
Free Project
IC: JHU APL
Free Project
Paid commercial
license
Paid commercial
IC: Audi
Scope: Project Free Project
license
Scope: Project Paid commercial
license
Scope: Project Paid commercial
Free Project Paid commercial license Free Project
license Scope: Project
Scope: Project
Free Project Paid commercial
license
Scope: Project
Free Project
IC: UCS
Paid commercial
license
Scope: Project Paid commercial
license Free Project
Scope: Project
Free Project Paid commercial
license
Scope: Project
© 2012 Real-Time Innovations, Inc. 41

42. 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
© 2012 Real-Time Innovations, Inc. 42

43. 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
© 2012 Real-Time Innovations, Inc. 43

44. Many Biz Model Needs
• Professional resources • Ensure vendor partnership
– Support all versions (free, – Proactively develop to match
paid) needs
– Offer professional guidance, – Encourage latest technology,
services no branches
• No legal strings – Motivate features, usability,
– Offer warranty and quality, accessibility
indemnification – Ensure vendor profitability
– Control provenance • Open, fair pricing
– No copyleft; keep your IP – Offer usable free product
• Drive quality & usability – Predictably & reasonably
– Enforce quality control price advanced product
– Push usability, docs, examples – Bound support costs
– Eliminate runtimes
© 2012 Real-Time Innovations, Inc. 44

45. 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
© 2012 Real-Time Innovations, Inc. 45

46. Open Community Source Balance
• Open Community Source • Low friction upgrade
– Free, viral adoption – Advanced
functionality, tools,
– “Good enough” product platforms, warranty
– Support available – Clear, reasonable fees
without surprise
• IC model benefits
– Provides you freedom
– Encourages vendor
investment
– Lowers overall cost
© 2012 Real-Time Innovations, Inc. 46

47. 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
© 2012 Real-Time Innovations, Inc. 47

48. Business Models for Government
Acquisition
Achieving the promise of interoperability
© 2012 Real-Time Innovations, Inc. 48

49. The sole imperative to control software cost is to
establish a stable team working on a single code
base
-- Stan Schneider
© 2012 Real-Time Innovations, Inc. 49

50. 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
© 2012 Real-Time Innovations, Inc. 50

51. Repository Competition Process
Team Team Team Team
Team
Code
Base Code
Base
Code
Creation Base
“Reuse”
Competition
• Competition divorces team from code
• “Reuse” implies re-learn, re-design, re-build…and re-code
• Result is very expensive!
© 2012 Real-Time Innovations, Inc. 51

52. Code-Team Competition Process
Team
Code Team
Base
Code
Base
Team
Team Team
Code
Base
Code Code
Base Base
Team
Team
Compete these Pairs for
Code Base
Each Module of Each Project
Code
Base
Create and Maintain Build Project from Modules
Multiple Code-Team Pairs
for Each Module
© 2012 Real-Time Innovations, Inc. 52

53. How? Interoperability.
© 2012 Real-Time Innovations, Inc. 53

54. 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
© 2012 Real-Time Innovations, Inc. 54

55. 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”
© 2012 Real-Time Innovations, Inc. 55

56. The Required Technology is Maturing
RTI Databus
Peer-to-peer for performance
R R
System-of-systems
RTI Databus RTI Databus
routing
R R
Hierarchical topology:
• Peer-to-peer within a system
R R R R
• Automatically route data
up/down the hierarchy
© 2012 Real-Time Innovations, Inc. 56

57. 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
© 2012 Real-Time Innovations, Inc. 57

58. Why Invest in Interoperability?
© 2012 Real-Time Innovations, Inc. 58

59. © 2012 Real-Time Innovations, Inc. 59

60. Your systems. Working as one.
Working as One™