Your SlideShare is downloading. ×
0
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
The Promise of Interoperability
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The Promise of Interoperability

457

Published on

View On-Demand: http://ecast.opensystemsmedia.com/369 …

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
457
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Your systems. Working as one.The Promise of InteroperabilityPractical 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 OpenArchitecture?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 Distribution2008 © 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 middleware12/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 bysix 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 AircraftSystem Control Segment(UCS) 22
  • 23. OA Acquisition ObjectivesTo remove the traditional barriers to Effective Competition in theUAS Control Segment and provide market access to a broad,heterogeneous industrial base of software providers in an agileacquisition and integration environment. UNCLASSIFIED - Release 12-S-1669 Pubic Pubic Release 12-S-1669
  • 24. OUSD ST&S UAS Common Architecture DoD Open AppStore MarketplaceOpen GCS Architecture for UAS 30+ PoR ready Apps & DemosJoint HMI Style Guide for GCSs PoR: TCS, Block 50, OSRVT, and GSRA (TBD) 2.1.1 Model HMI GuideDoD Contract Guidebook & IP Rights New OSD Guidance is NeededOpen 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 25UNCLASSIFIED - 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 PlatformRadio 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/OInterface 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 RTPS12/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 forInfrastructure VendorsEnabling 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 ProjectPaid commercial license Paid commercial IC: AudiScope: 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 GovernmentAcquisitionAchieving the promise of interoperability © 2012 Real-Time Innovations, Inc. 48
  • 49. The sole imperative to control software cost is toestablish a stable team working on a single codebase -- 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 ModulesMultiple 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 RSystem-of-systems RTI Databus RTI Databusrouting 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™

×