27
Your systems. Working as one. Architect Scalable Real-Time Systems David Barnett

Don't Architect a Real-Time System that Can't Scale

Embed Size (px)

DESCRIPTION

View On-Demand : http://ecast.opensystemsmedia.com/340 As distributed system scale up, so does their integration time and cost. This integration challenge is particularly acute for real-time and intelligent systems: increased connectivity cannot come at the expense of performance, reliability or resource consumption. Adopting an inherently scalable architecture is the secret to agilely and affordably building systems that encompass ever more applications, nodes and real-time data. This webinar will review how you can apply proven integration techniques—such as loose coupling and service orientation—to demanding real-time systems. Unlike approaches designed for conventional business applications, the architecture we'll introduce is appropriate for systems that span embedded, high performance and IT applications. This webinar targets software architects, chief engineers and development leads in all industries that design real-time and intelligent systems. This includes defense, industrial, transportation, medical and aerospace applications. Better integration is increasingly the key to competitive advantage. It provides end-users with higher situational awareness, responsiveness and resource utilization. Don't let your architecture hold you back.

Citation preview

Page 1: Don't Architect a Real-Time System that Can't Scale

Your systems. Working as one.

Architect Scalable Real-Time Systems

David Barnett

Page 2: Don't Architect a Real-Time System that Can't Scale

About RTI

• World leader in communications software for real-time systems– 350,000+ deployed copies– 500+ unique designs

• Standards leader– Participate in 15+ standards

organizations– Authored DDS (OMG)

Page 3: Don't Architect a Real-Time System that Can't Scale

Real-Time Systems

Page 4: Don't Architect a Real-Time System that Can't Scale

Characteristics of Real-Time Systems

• Time sensitive• Low latency• High throughput• Non-stop availability• Dynamic, ad hoc• Autonomous, no sys admin• Components run outside

data center– Decentralized– Processing distributed– Few or no central servers– Embedded, resource constrained– Disadvantaged networks

Page 5: Don't Architect a Real-Time System that Can't Scale

Challenge: Increasing Scale

• More CPUs, nodes, apps, data, orgs, developers…

• Systems of systems

System of systems

Existing architectures and infrastructure break under the load

Page 6: Don't Architect a Real-Time System that Can't Scale

Traditional Integration

• Point-to-point• Custom, e.g., using sockets• RPC, RMI

• Complex• Costly – O(n2)• Poor reuse• Limits information

sharing

Page 7: Don't Architect a Real-Time System that Can't Scale

Cost Constrains Integration

Time & cost of integration,

maintenance and upgrades

System Scale and Age

Page 8: Don't Architect a Real-Time System that Can't Scale

Six Keys to Scalability

Page 9: Don't Architect a Real-Time System that Can't Scale

1. Publish/Subscribe

• Simplifies integration – O(n) • Improves information sharing

Bus

Sensor

Sens

or D

ata

Sens

or D

ata

Control App

Com

man

ds

Stat

us

Sensor

Sens

or D

ata

Actuator

Com

man

ds

Stat

us

Display App

Sens

or D

ata

Stat

us

Page 10: Don't Architect a Real-Time System that Can't Scale

2. Explicit, Well-Defined Data Model

Page 11: Don't Architect a Real-Time System that Can't Scale

3. Maintain State in Infrastructure

• External to applications• System-wide single version of truth• Temporal decoupling• Simplifies system development and integration• Essential for robust, dynamic systems

Source(Key)

LatitudeLongitud

eAltitude

RADAR1 37.4 -122.0 500.0

UAV2 40.7 -74.0 250.0

LPD3 50.2 -0.7 0.0

Page 12: Don't Architect a Real-Time System that Can't Scale

Message Message

Data Centric

• Infrastructure manages data and lifecycle

• Standard data operations (CRUD)• Automatic state synchronization

when applications join• Robust, scalable

• Applications must manage data• Application layer protocol required for

lifecycle management• State synchronization requires persisting

every message or application protocol• Brittle, inefficient

Source(Key)

Latitude Longitude Altitude

RADAR1 37.4 -122.0 500.0

UAV2 40.7 -74.0 250.0

LPD3 50.2 -0.7 0.0

Application

Create UpdateRead Delete

Src=RADAR1Msg=Create

X=37.4Y=37.4Z=500

Src=RADAR1Msg=Update

X=37.4Y=37.4

ReceiveSend

Application Logic

Message Centric

Page 13: Don't Architect a Real-Time System that Can't Scale

4. Explicit Quality of Service Contracts

Bus

Sensor

Sens

or D

ata

Sens

or D

ata

Control App

Com

man

ds

Stat

us

Sensor

Sens

or D

ata

Actuator

Com

man

ds

Stat

us

Display App

Sens

or D

ata

Stat

us

Reliable 1000 Hz primary

Reliable 1000 Hz backup

Reliable100 Hz

Best effort 1 Hz

Reliable100 Hz

Page 14: Don't Architect a Real-Time System that Can't Scale

Sample Real-Time QoS

• Volatility– Durability– History– Lifespan

• Delivery– Reliability– Time based filter– Content filter– Deadline

• High availability– Liveliness– Ownership– Ownership strength

Page 15: Don't Architect a Real-Time System that Can't Scale

5. Govern Interactions with Middleware

• Instantiates data model• Provides

– Syntactic interoperability– Discovery– Access control

• Independent of:– Programming language– Operating system– CPU type– Physical location– Transport protocol– Network type

Modular, Loosely Coupled Services

Bus

Evolvable, interoperable,shareable, swappable, reusable

Page 16: Don't Architect a Real-Time System that Can't Scale

Example: Data Distribution Service

• Standard means to define data– IDL, XML, dynamically via API– Generated from UML

• Wire protocol for interoperability

• API for portability

Real-Time Publish-Subscribe

Wire Protocol (RTPS)

Middleware

DDS API

Portability

InteroperabilityRTPS also standardized as IEC 61148

Data def’n

Page 17: Don't Architect a Real-Time System that Can't Scale

6. Decentralized Physical Architecture

• No central ESBs, brokers, database or servers• Peer-to-peer communication

– Components, services, applications, devices, subsystems, systems

• Bus is virtual

Network

Page 18: Don't Architect a Real-Time System that Can't Scale

Comparison

• Server-based• Administration heavy• Assume high-bandwidth, reliable

network (TCP)• Poor latency, scalability• Slow failover

• Library only, easy to embed• Low latency; good determinism• Highly scalable• No single point of failure:

non stop availability‑

Centralized: Traditional ITDecentralized: Real Time

Page 19: Don't Architect a Real-Time System that Can't Scale

Relative JMS Performance

0 25,000 50,000 75,000 100,000

JBoss

Sun

ActiveMQ

Sonic

Tibco

RTI

1 KB Messages per Second

Page 20: Don't Architect a Real-Time System that Can't Scale

P2P Publish/Subscribe over Multicast

Minimizes:• CPU overhead• Network overhead• Latency• Determinism

Publisher

Subscriber SubscriberSubscriber

Switch• Replication• Filtering

Page 21: Don't Architect a Real-Time System that Can't Scale

Multicast Scalability

0 100 200 300 400 500 600 700 800 900 1,0000

100,000

200,000

300,000

400,000

500,000

600,000

Gigabit Ethernet

Subscribers

Mes

sage

s pe

r Sec

ond

Page 22: Don't Architect a Real-Time System that Can't Scale

Summary:Architecting Scalable Real-Time Systems

1. Publish/subscribe2. Explicit data model3. Maintain state in infrastructure4. Explicit QoS contracts5. Govern interactions with middleware6. Decentralized physical architecture

Page 23: Don't Architect a Real-Time System that Can't Scale

RTI’s Solution

RTI DataBus™

ConnextMicro

Pub/Sub API(DDS subset)

Small Device Apps

ConnextDDS

Pub/Sub API(Full DDS)

DDS Apps

ConnextMessaging

Messaging API(DDS++ & JMS)

General-Purpose Real-Time Apps

ConnextIntegrator

Adapters

DiscreteApps/Systems

Administration

Monitoring

Logging

Recording

Replay

Federation

Transformation

PersistenceVisualization

Common Tools and Infrastructure Services

Page 24: Don't Architect a Real-Time System that Can't Scale

Designed for Real-Time Systems

• Fully embeddable– Applications are self-contained– Deterministic resource utilization– Support embedded and real-time OS– C, C++, C#, Java and Ada APIs; no Java dependence

• Autonomous operation– Plug-and-play via automatic discovery– No sys admin– Supports highly dynamic and ad hoc systems– Self healing

• Real-time Quality of Service (QoS)– Control and visibility over timing and resources– Built-in filtering by time and content

• Disadvantaged network support– E.g.: wireless, radio, satellite, WAN– No TCP or IP dependence

Page 25: Don't Architect a Real-Time System that Can't Scale

Learn More

• Contact RTI• Downloads

– www.rti.com/downloads– Interactive “Shapes” demo– Free trial with comprehensive

tutorial– Free licenses for internally-funded

IR&D• Videos, webinars and whitepaper

– www.rti.com/resources

Page 26: Don't Architect a Real-Time System that Can't Scale

DownloadConnextFree TrialNOW

www.rti.com/downloads

Page 27: Don't Architect a Real-Time System that Can't Scale

Thank You!