high-performance interoperable architecture for information dominance
DESCRIPTION
To view this webinar: http://ecast.opensystemsmedia.com/320Suppliers of C4I, C2, Cyber, ISR and sensor and weapons platforms are challenged to meet commercial pressure from defense procurement for more capability at lower cost, and from acquisition officials for increasing interoperability across their combat systems in order to be able to enable new system capability through Information Dominance (ID).RTI will present an architecture and its Connext solution, designed to meet these twin imperatives. Built upon proven open technology, Connext is a foundational system architecture that delivers significant productivity gains in integration, while also enabling discovery and rapid assimilation of existing system entities, potentially from 3rd party suppliers or already deployed in the field of operation.Given the unique requirements of tactical system-of-systems, the architecture must support both real-time combat systems as well as brigade and command HQ enterprise style systems, bringing them together in a scalable, dynamic, and flexible framework. Connext addresses the performance and scale impedance mismatch between these disparate systems types, and delivers the ability to develop a common infrastructure that runs over DIL (Disconnected Intermittent Loss) communications as well as it does over Ethernet, putting minimal strain on the communications interfaces and maximizing information exchange.The Connext foundation is in use in over 400 defense programs globally with over 350,000 licensed deployments. It has been approved by the US DoD to TRL9 (Technology Readiness Level).TRANSCRIPT
High-Performance Interoperable Architecture for Information Dominance
Gordon A. Hunt – RTI Webinar
Chief Engineer, RTI • UCS WG Sub-Committee Chair • Commander USN-R
Agenda
• High Performance– It really is about time…
• Interoperable Architecture– What is Interoperability– Architecture foundations
• [for] Information Dominance– Putting it all together– Right time – right data – right place
So, a little about Performance.
Measure the right thingfor the right reason.
Performance
• What can we measure?– Message rates– Numbers of messages– Size of messages– Time to process messages– Number of clients, number of servers– Throughput of a broker/server
• Do the measurements matter?– Consider that “Messages” are about something.– What I really care about, is how long it takes to know that
something.
Performance is often Defined by…
Point-to-point, sockets, RPC, RMIConcerned with an applications individual throughput/latencyBottleneck at the slowest applicationLittle correlation between bus/fabric speeds and system performance
Centralized, DB, ESBsMeasure the aggregate performanceReplication rates, transaction ratesNumber of supported clientsGenerally not measure client
performance
Decentralized, Data CentricMeasures data as presented to the applicationMeasures data update rates (1-1, 1-many, etc.)Measures time to get the consistent state
BrokerESB
DBMS
Performance Does Matter
• Impacts Scale– How big is the System-of Systems going to be?– Physically can’t send all the data everywhere.– Can’t revisit existing application when adding new capability.
• Impacts flexibility of Implementation– Not arbitrarily constrained to messages rates/sizes.– Capability and distribution can be added.
• However, the following is required– Applications need to manage their performance requirements– Applications need to manage their behavior explicitly
Application Behavior Concerns
• What data is valid– Do I have the current value(s), from everyone
• How much of the data do I need– Reliably, only get me date that changes by a little bit– Send me data no faster than this rate
• What happens if– I expected an update to data at …, what do you do.– I want an acknowledgement, wait for this long, for this many
• I’m too busy– Old data that I am just getting around to looking at– Are the updates I’m about to send even valid anymore?
Managed Performance for Information Dominance
Integration Bus for Information Dominance
Operational Systems / Tactical Systems
DATA-IN_MOTION
Information Technology (IT)Command & Control (C2)
DATA-AT-REST
ApplicationQuality of Service
(Desired Behaviors,..)
ApplicationQuality of Service
(Desired Behaviors,..)
An Integration Capability that
• Supports Integration of applications and delivery of consistent behaviors when– Environment is ADHOC– Performance concerns are mixed– Scale is unknown– Technologies are mixed
• Enables Information Dominance via– Architectural approach that supports a rigorous yet
flexible integration methodology that is interoperable across data form/function boundaries
Interoperable Architecture
How Do We ‘Do’ Interoperability?
What does the Architecture look like?
Current Approaches
• Protocol Definitions & Standards– Tell me the messages
• Open Architecture Mandates– Interoperability on Commonality
• Service Oriented Architecture – Stateless services
Is Current Practice Working
• Recent studies have shown a growth in interoperability policy issuance in DoD– Thousands of pages of directives, instructions, and mandates– Numerous standards and architecture bodies in the DoD
• No Correlation between Increased Interoperability and Standards– Standards are necessary, but not sufficient for interoperability
• Conventional means of developing platform, unit command, and theater architectures are complex, manpower intensive, and time consuming.– Achieving Interoperability increases complexity– Complexity of systems-of-systems not understood or well managed – Can’t make complexity go away, just move where it is
Pause: What are we Trying to Achieve?
DriverInterchangeability To put each of (two things) in the place of the other, or to be used in place of
each other.
Integratability To form, coordinate, or blend into a functioning or unified whole. To incorporate into a larger, functioning or unified whole.
Replaceability One thing or person taking the place of another especially as a substitute or successor.
Extensibility The ability to add new components, subsystems, and capabilities to a system.
Interoperability The ability of systems, units, or forces to provide services to and accept services from other systems, units, or forces, and to use the services so exchanged to enable them to operate effectively together.
Open Architecture Requires Interoperability at a Higher Level Than Key Interfaces.
Levels of Interoperability -- Technical --
System BehaviorCommunication protocol for exchanging
data. Bits & Bytes
are exchanged in
an unambiguous
manner.
Non-Functional NeedInterchangeability,
Integrateability, Replaceability,
Extensibility,
and Meaningful
InteroperabilityTechnical
Levels of Interoperability-- Syntactic --
System BehaviorCommon structure or data format defined for exchanging information.
This format
must be unambiguously defined.
Non-Functional NeedInterchangeability,
Integrateability, Replaceability,
Extensibility,
And Meaningful
Interoperability
Syntactic
Technical
Levels of Interoperability-- Semantic --
System BehaviorMeaning of data
is exchanged
via common
information
model.
The meaningof information is shared and unambiguously defined.
Non-Functional NeedInterchangeability,
Integrateability, Replaceability,
Extensibility,
And Meaningful
Interoperability
Semantic
Syntactic
Technical
What’s the Difference?
• Semantic definition captures concepts of– Structure (Content)– Relationships (Context) – Time (Behaviors)
• This makes the state of the system and the application’s data– Explicit– Directly Observable– Manageable
• Everything has state…
Why is this hard?
Consider a measure of complexity on application development approaches.
How to Architect Systems to Achieve Interoperability
1. Application Centric: Building Interoperable Apps– Application manages Technical, Syntactic, and Semantic Interoperability
2. Message Centric: Building Interoperable Messaging Systems– Delegates Syntactic Interoperability to Messaging Middleware– Application manages Semantic Interoperability
3. Data Centric: Building Truly Data Centric Systems– Delegates Semantic Interoperability to Middleware– Open Architecture Requires a Data Centric Approach.
19
20
Application Centric Development
• Scales O(n) only if– fully known, distributed, and homogeneous
knowledge of interfaces and state
Node/Service
Interface: Colors denote uniqueness
Data State: Color denote uniqueness
21
Application Centric Development
• Scales O(n2) only if– each System invokes the Specified Interface of the
System that it wishes to communicate with and no application state
– n is the number of interfaces
Application Centric Development
• Scales O(n3)– Each system must understand the interaction
patterns and the remote data state….– n is the number of data states
22
23
Application Centric Development
• Small systems aren’t the problem, and they give a false sense of hope. – This is ~3.5 time more ‘complex’ than 2 nodes
24
Application Centric Development
• O(n3) Scaling – ~8 times more
complex
25
Message Centric Development
• Delegate syntacticinteroperability– Scales O(n2)– State is still in Apps
Data-Centric Development
• Delegate to middlewareSyntactic and Semantic Interoperability– Scales O(n)– State synced with middleware
– State IN the middlewareand infrastructure
– Data-Centric Pub/Sub
26
An Interoperable Architecture
HAS a Data-Centric bus and is Semantically Defined.
What is State?
• Things have attributes and characteristics
– The meeting will run 1:00–2:00 in the conference room.
– My friend’s phone number is 555-1234 and he’s currently grooming his cat.
– The car is blue and is traveling north from Sunnyvale at 65 mph.
– The UAS is performing this mission, with these goals and resources.
…whether they exist in the real world, in the computer, or both
…whether or not we observe or acknowledge them
“State” (“data”) is a snapshot of these attributes and characteristics.
Best Practice: operate on state, not dialogs about state.
Data-Centric is Explicit Understanding of State
Weather Service- Stateless Service- Provides current weather
only when asked
Weather ‘Client’- Asks for a Weather Report- Get the current prediction
State- The fact that I asked, - Where, at a certain time- ‘Somebody’ has to keep it current…
Example: Data-Centric FlightPlan
Publish
Subscribe
New
45.6
78.9
“AA123”Update
56.7
89.0
“AA123”New
65.4
32.1
“DL987”Dispose
“AA123”
X
Start with a Semantic understanding of FlightPlans
Content is understood – can represent data efficiently
Context is understood, know what’s what….
Example: Data-Centric FlightPlan
• Once infrastructure understands objects, can attach behavior (QoS) contracts to them
• Data-in-motion behavior includes time perspective• “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
Publish
Subscribe
Quality of Service
Deadline
Time-Based Filter
HistoryFlightPlanFlightPlanFlightPlanFlightPlan
[for] Information Dominance
Making it Happen, Steps you can take…
32
Challenges for Information Dominance
• Consistent Application Performance– Regardless of Scale– Numbers of nodes, amount of data, data rates…
• Dynamic systems’ topology– No system always on, nodes come and go– Capabilities derived from rapid integration
• Disparate Technologies– Different deployment concerns– Different interaction patterns and behaviors
• Data-in-Motion and Data-at-Rest– Making at all actionable at the right place & time
Data-Centric Infrastructure Supports Information Dominance
Integration Bus for Information Dominance
Operational Systems / Tactical Systems
DATA-IN_MOTION
Information Technology (IT)Command & Control (C2)
DATA-AT-REST
ApplicationQuality of Service
(Time, Performance,..)
ApplicationQuality of Service
(Time, Performance,..)
RTI Connext :Edge-to-Enterprise Real-Time SOA
Facilitates cross-organizational integration:• Well-defined and discoverable information models;• Standard data-centric operations• Standard wire interoperability protocol• Mediation: integrate with any interface, expose via any interface
Connext Integrator
Operational Systems Information Technology (IT)
Connext Micro
Connext DDS
Connext Messaging
RTI Connext™: A Data-Centric Infrastructure
RTI DataBus™
ConnextMicro
Pub/Sub API
Small Device Apps
ConnextDDS
Pub/Sub API
DDS Apps
ConnextMessaging
Messaging API
General-Purpose Real-Time Apps
ConnextIntegrator
Adapters
Discrete OT & IT Apps/Systems
Administration
Monitoring
Logging
Recording
Replay
Federation
Transformation
PersistenceVisualization
Common Tools and Infrastructure Services
Summary
• Information Dominance is enabled by– Access to the right information – Managed expectations with regards to performance
• Access to the right information is facilitated by– The right architecture and description of data– Content, Context, and Behavior
• Leveraging the data is facilitated by – Having that data presented to the application in the
right form and function– Decoupling the applications view from the
infrastructures management of the state
Where is State
Point-to-point, sockets, RPC, RMIState is in the applicationsEach application maintains its view
Centralized, DB, ESBsState is in the DatabaseManaged interactions with state
Decentralized, Data CentricState is in the busStateless clients/servicesState has explicit properties to manage its behavior
BrokerESB
DBMS
DownloadConnextFree TrialNOW
www.rti.com/downloads