• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Easing Integration of Large-Scale Real-Time Systems with DDS

on

  • 939 views

Webcast (sorry, audio not included) on system integration design patterns from July of 2010 pertaining mostly (but not exclusively) to Data-Distribution Service (DDS) technology.

Webcast (sorry, audio not included) on system integration design patterns from July of 2010 pertaining mostly (but not exclusively) to Data-Distribution Service (DDS) technology.

Statistics

Views

Total Views
939
Views on SlideShare
939
Embed Views
0

Actions

Likes
0
Downloads
27
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • When I say “large” in this presentation, I’m primarily talking about complexity. I’m not talking primarily about a unified simple design that happens to have lots of participants in it.Same principles apply to defense systems, financial systems, power systems, industrial automation, etc.
  • Care about lots of the same things as any system designers — functionality, performance, … — but care about certain things much more.Isolation relates to governance: making sure integration doesn’t violate SLAs
  • This will eventually be a talk about DDS, but we’ll get to that later
  • Same principles apply in every industry
  • Same principles apply in every industry
  • Same principles apply in every industry
  • Same principles apply in every industry
  • 2 problem areas brought up before that we haven’t discussed yet.These will be bridge to technology-specific discussion in 2nd half.
  • From the beginning, the data stream is associated with the schema of the data that will be propagated on that stream. Your applications already have some expectations; if you express those to a data-centric infrastructure, it can help you. For example, you can use this schema to automatically transform data into other formats. (This is how the Routing Service and Web Integration Service work.) The infrastructure can also dissect your data to filter on content (for example “give me updates where x > 5”).“Key” means “this field establishes the identity of a unique object.” Like the key in a relational database table. In DDS, can be any number of fields of any type(s).New track you’ve never seen before. Notice that since type is already known, only need to send field values, not field names or types.Update to a track you’ve already seenAnother new track – notice that the key is differentA track you’ve seen before has gone away
  • Test results from lab of hundreds of multi-core Linux machines connected by gigabit Ethernet

Easing Integration of Large-Scale Real-Time Systems with DDS Easing Integration of Large-Scale Real-Time Systems with DDS Presentation Transcript

  • Easing Integration of Large-Scale Real-Time Systems with DDS
    Rick Warren, Principal Engineer rick.warren@rti.com
  • Introduction
    Rick Warren
    Principal Engineer; with RTI since 2001
    Engineering organization; previously Professional Services
    Together with CTO, lead RTI’s Object Management Group (OMG) initiatives
    Passionate about systems integration, standards, and usability
    This Presentation
    Large-scale design patterns for integrating heterogeneous distributed systems
    Part 1: Architecture and requirements
    Part 2: Addressing Part 1 with OMG DDS
    © 2010 Real-Time Innovations, Inc.
    2
  • RTI: The Global Leader in DDS
    70%+ worldwide DDS market share
    First with…
    DDS API (2004)
    DDS-RTPS interoperability protocol(2007) — based on RTI’s native protocol
    Most mature solution
    12+ years of commercial availability
    Technology Readiness Level (TRL) 9:successful mission operations
    Diverse range of industries: defense, finance, medical, industrial control, power generation, communications
    300+ commercial customers, 100+ research projects
    100,000+ licensed copies
    Leading OMG standardization
    Board of Directors member
    Co-chair DDS Special Interest Group
    Chair several DDS standard finalization, revision task forces
    © 2010 Real-Time Innovations, Inc.
    3
  • © 2010 Real-Time Innovations, Inc.
    4
    Customer Application Highlights
    Weapon System
    Lockheed Martin Aegis
    Radar, weapons, displays, C2
    Unmanned Air System
    Boeing ScanEagle
    Sensors, ground station
    Control System
    Grand Coulee Dam: largest electricity producer in US
    Controls, high availability
    Driver Safety
    Volkswagen
    Vision systems, analysis, driver information systems
    Medical Imaging
    NMR and MRI
    Sensors, RF generators, user interface, control computers
    Automated Trading
    Automated Trading Desk (ATD, now Citigroup)
    Market data feed handlers, pricing engines, algorithmic trading applications
  • What do I mean by “large system”?
    Systems of systems
    Modular, hierarchical design
    Legacy components, subsystems
    Multiple technologies
    Global scale
    Decoupled subsystem lifecycles
    Independent development
    Independent deployment and use
    Independent management
    Independent revision and retirement
    Multiple communities of interest
    Different data interest, entitlements
    Non-uniform levels of trust
    © 2009 Real-Time Innovations, Inc.
    5
    DDS #1
    (Initech)
    LAN
    JMS
    (Dunder Mifflin)
    DDS #2
    (Acme)
    Satellite Links
    Legacy
    (COBOL ‘R’ US)
  • What matters to integrators of large systems?
    Governance (including over security)
    What information will be exchanged?
    Under what conditions will it be exchanged?
    Who is allowed to exchange this information?
    If these SLAs are violated, can the exchange be prevented?Can I be notified?
    (In the past, what has occurred wrt these SLAs?)
    Isolation
    When I connect A and B, ensure they don’t break (each other)
    When I disconnect A, ensure B doesn’t break
    When I connect C, don’t change A or B
    Scalability(like in any system,
    Fault Tolerancebut stakes are higher)
    © 2009 Real-Time Innovations, Inc.
    6
  • Part 1: Architecture
    (we’ll get to technology later)
    © 2010 Real-Time Innovations, Inc.
    7
  • System
    Component
    Component
    Class
    A Modest Proposition
    © 2009 Real-Time Innovations, Inc.
    8
    Fundamental design principles scale
    Abstraction: Provide interface based on relevant concepts
    Encapsulation: Hide internal implementation, communication
    Composition: Combine existing capabilities into new ones
    Class
    State
    Component
    Behavior
  • Schematic of a Composed System
    Isolation
    P
    P
    P
    P
    LAN
    Router/Gateway
    Router/Gateway
    LAN
    WAN
    P
    P
    P
    P
    P
    P
    Additional Governance
    Subsystem 2
    Subsystem 1
    Subsystems may have different network environments
    Integration may have different network environment than subsystems themselves
    Data may need to be transformed / cleansed as it moves among subsystems
    Routing / gateway services will adapt data types / formats / protocols
  • Schematic of a Composed System
    P
    P
    P
    P
    Router/Gateway
    Router/Gateway
    P
    P
    P
    P
    P
    P
    Subsystem 2
    Subsystem 1
    Wash, rinse, repeat
    © 2010 Real-Time Innovations, Inc.
    10
  • Same data model?
    Same network env.?
    Same lifecycle?
    Behavior unaffected?
    Understandable?
    Apples and Oranges
    P
    P
    Router/Gateway
    P
    P
    Router/Gateway
    P
    P
    P
    P
    P
    P
    Subsystem 2
    Subsystem 1
    P
    P
    P
    P
    P
    P
    P
    P
    P
    P
    Subsystem 1 + Subsystem 2
  • Nothing New Under the Sun
    © 2009 Real-Time Innovations, Inc.
    12
    Subsystem Data Space
    Subsystem Data Space
    Router/Gateway
    Router/Gateway
    Integration Data Space
    Router/Gateway
    Subsystem Data Space
  • Nothing New Under the Sun
    © 2010 Real-Time Innovations, Inc.
    13
    U.S. CombatData Space
    Allied CombatData Space
    Router/Gateway
    Router/Gateway
    Integration Data Space
    Router/Gateway
    U.S. C4IData Space
    Defense Industry
  • Nothing New Under the Sun
    © 2010 Real-Time Innovations, Inc.
    14
    NYC TradingData Space
    London TradingData Space
    Router/Gateway
    Router/Gateway
    Integration Data Space
    Router/Gateway
    Tokyo TradingData Space
    Financial Services Industry
  • Nothing New Under the Sun
    © 2010 Real-Time Innovations, Inc.
    15
    GenerationData Space
    Substation #1Data Space
    Router/Gateway
    Router/Gateway
    Integration Data Space
    Router/Gateway
    Substation #2Data Space
    Power Industry
  • Architecture Recap
    Solve big problems like you solve small ones
    Break them into pieces
    Define interfaces between pieces
    Implement each piece
    Integrate along the interfaces
    Translation
    Define subsystems
    Implement them however you like
    May have different requirements, therefore technology
    Router/gateway defines/enforces interfaces
    © 2010 Real-Time Innovations, Inc.
    16
  • Fault Tolerance and Scalability
    Fault tolerance: Router/gateway can’t be single point of failure. 3 answers:
    Persistent data survives system failures
    Segmented/load-balanced configuration limits scope of failures
    Redundancy allows continued service during failure
    Scalability: How big can a subsystem be?
    How big a subsystem can you understand, test, and debug?
    How well does infrastructure scale?
    © 2010 Real-Time Innovations, Inc.
    17
  • Part 2: DDS
    © 2010 Real-Time Innovations, Inc.
    18
  • DDS Is Open Architecture
    Cross-vendor portability
    DDS API
    Middleware
    Real-Time
    Publish-Subscribe
    Protocol (DDS-RTPS)
    Cross-vendor interoperability
    OMG standard for data-centric publish-subscribe communication
    Vendor independent
    API for portability
    Network protocol for interoperability
    8+ implementations
    Commercial, open-source, and hybrid licenses
    Supports heterogeneous systems
    C, C++, C#/.NET, Java, Ada, …
    Windows, Linux and other Unix, embedded, RTOS
    © 2010 Real-Time Innovations, Inc.
    19
  • Example: Data-Centric Track Data
    © 2009 Real-Time Innovations, Inc. COMPANY CONFIDENTIAL
    20
    Data Schema
    Map this into XML; rows + cols
    id : string (key)
    Express content-based filters
    x : float
    Propagate data efficiently
    y : float
    Publish
    Subscribe
    New
    Update
    New
    Dispose
    “AA123”
    “AA123”
    “DL987”
    “AA123”
    45.6
    56.7
    65.4
    X
    78.9
    89.0
    32.1
  • Example: Data-Centric Track Data
    © 2009 Real-Time Innovations, Inc. COMPANY CONFIDENTIAL
    21
    Data Schema
    Quality of Service
    id : string (key)
    History
    x : float
    Deadline
    y : float
    Time-Based Filter
    Publish
    Subscribe
    Once infrastructure understands objects, can attach QoS contracts to them
    “Keep only the latest value” or “I need updates at this rate” make no sense unless per-object
    Flight AA123 updates shouldn’t overwrite DL987, even if AA123 is updated more frequently
    Update rate for one track shouldn’t change just because another track appeared
  • Analysis by U.S. Armed Services
    Adapted from NSWC-DD OA Documentation
    NESI, P1190 rev 3, http://nesipublic.spawar.navy.mil/nesix/Frames/P1190
    © 2010 Real-Time Innovations, Inc.
    22
  • How Does DDS Stack Up?
    Governance
    Structural SLA: data type
    Behavioral SLA: delivery QoS
    Security
    Problem detection/prevention/notification
    System monitoring and recording
    Isolation
    Prevent data “leaks” and side effects
    Allow dynamic (dis-|re-)connection
    Support independent integration and evolution
    Fault tolerance
    Data persistence
    Segmented/load-balanced routing
    Redundant routing
    Scalability
    WAN, DIL connectivity
    Peer-to-peer communication
    Brokered/managed communication
    Built in
    Built in
    Products available; future standards
    Built in
    Products available
    Built in: domains, partitions
    Built in
    Built in, esp. w/ DDS-XTypes spec
    Built in
    Built in if router uses DDS
    Built in if router uses DDS
    Products available; future standards
    Highly scalable
    Protocol support if necessary
    © 2010 Real-Time Innovations, Inc.
    23
  • DDS Scalability: Two Aspects
    Application data
    How does performance fall off as # participants, writers, readers increase?
    Any single writer/reader pair can saturate gig-E:achieving high aggregate throughput is not main issue
    Interesting issue: Fan-out – number of readers per writer
    Discovery
    How many DDS applications can discover one another?
    Interesting issue: How many applications need to discover one another?
    Hard limits, if any, very dependent on DDS implementation, machine configuration, network, etc.
    Following results based on RTI on modern commodity HW
    © 2010 Real-Time Innovations, Inc.
    24
  • 1. DDS Scalability: Application Data
    DDS-RTPS reliable multicast scales at least:
    …to hundreds of readers per writer
    …with very little degradation in throughput.
    Larger testing facilities welcomed. 
    © 2010 Real-Time Innovations, Inc.
    25
    < 15% decrease
    1~900 readers
    RTI Data Distribution Service 4.3
    Red Hat EL 5.0, 32-bit
    2.4 GHz processors
    Gigabit Ethernet
    UDP/IPv4
    Reliable ordered delivery
  • 2. DDS Scalability: P2P Discovery Scenarios
    Single domain, symmetric discovery
    Everyone discovers everyone else
    Easiest to configure; most challenging wrt scalability
    RTI test results: 1,800 participants; 3.2M endpoint matches
    Single domain, asymmetric discovery
    Each participant only knows of certain others in its domain
    Good for partitioning domains in which not everyone talks
    Multiple domains
    Greatest separation for subsystems that rarely exchange data
    DDS-RTPS maps to different IP ports
    © 2009 Real-Time Innovations, Inc.
    26
    1

    n
  • Summary: Large-Scale P2P Scalability
    Experimental results: DDS-RTPS allows participant to talk to ≥ 1-2K others in single symmetric domain
    Implication: Compose arbitrarily large systems out of subsystems this size or smaller
    Large (sub)systems often have requirements for:
    Increased governance, e.g. over security boundaries
    Data transformation
    Protocol mediation
    These typically require data brokering anyway
    © 2009 Real-Time Innovations, Inc.
    27
  • Geographic Scalability: WAN Transport
    Site-to-site comms need DDS across WAN(s)
    Including untrusted networks
    Including firewall, NAT traversal
    Challenge: UDP may not be routable, especially if multicast
    Standard DDS-RTPS protocol designed for layeringatop diverse lower-level protocols
    RTI supports:
    Shared memory for performance on a single machine
    UDP (unicast, multicast) for scalability, determinism w/in LAN
    TCP for routing across WAN
    (D)TLS for transport-level security
    etc.
    …simultaneously
    © 2010 Real-Time Innovations, Inc.
    28
  • Geographic Scalability: DIL Transport
    DDS is also great on disadvantaged networks
    DDS QoS provide tunable behavior, performance
    DDS-RTPS protocol encapsulates data efficiently w/ CDR
    © 2010 Real-Time Innovations, Inc.
    29
    Source:
    • SELEX-SI/ ConsorzioSESM/ University of Naples
    • “Flexible Communication Among DDS Publishers and Subscribers”
    • July 2008, Real-Time Systems Workshop, Washington, DC
    10x more compact than XML or JSON
  • Geographic Scalability: DIL Transport
    DDS is also great on disadvantaged networks
    DDS QoS provide tunable behavior, performance
    DDS-RTPS protocol encapsulates data efficiently w/ CDR
    © 2010 Real-Time Innovations, Inc.
    30
    Source:
    • SELEX-SI/ ConsorzioSESM/ University of Naples
    • “Flexible Communication Among DDS Publishers and Subscribers”
    • July 2008, Real-Time Systems Workshop, Washington, DC
    20x faster
  • RTI Routing Service:Integrating Non-DDS Applications
    Adapt to other protocols and interfaces
    Adapter SDK with customizable plugins
    JMS
    Socket
    File
    Take advantage of RoutingService capabilities
    Data transformation and filtering
    Data life-cycle management
    Cross networks, transportsand platforms
    Dynamic discovery
    DDS
    Plug-in Adapters
    JMS
    CANbus
    Socket
    LINK11
    © 2010 Real-Time Innovations, Inc.
    31
  • Recap
    Large systems usually composed of smaller systems
    Developed independently
    …With different network environments
    …And different data interest/entitlements
    Not an accident: hierarchical design is a best practice at any scale
    Subsystems managed by router/gateway
    Restrict access to internal topics/flows
    Mediate internal/external protocols
    Transform/cleanse internal/external data types
    Impose governance: enforce policy, attach monitoring
    Inter-router integration space is itself a “subsystem” for further hierarchical composition
    © 2010 Real-Time Innovations, Inc.
    32
  • Recap
    DDS is uniquely qualified to meet these needs
    Strong SLAs for governance
    Multiple topologies for fault-tolerant subsystem isolation
    High-performance, scalable, deterministic interoperabilityin various network environments
    What other standard technology offers this combination?(Not JMS. Not CORBA. Not AMQP. Not web services. …)
    © 2010 Real-Time Innovations, Inc.
    33
  • Next Steps
    Free software downloads
    www.rti.com/downloads
    Product evaluation:full RTI Professional Edition
    Free trial with comprehensive tutorial
    Free licenses for research & academia
    Includes:
    Leading DDS implementation
    Data recording
    System monitoring and debugging
    Integrates with JMS, databases,Microsoft Excel
    More
    Shapes demo: no coding required
    Videos, webinars, and whitepapers
    www.rti.com/resources
    © 2010 Real-Time Innovations, Inc.
    34