How to Leverage Open Architectures for Existing Systems

How to leverage Open
Architectures for existing
systems
Mark Swick – RTI Webinar
Principal Applications Engineer, RTI • UCS WG Data Model Lead

Agenda
• Background
– Open Architecture and Current Approaches
• Open Systems
– Definitions and Examples
• Interoperability Architecture
– Data is the primary driver
– Capture and define its meaning
– Interoperability by Design

Background
How Do We ‘Do’ Interoperability?
What is labeled ‘Open’?
© 2013 RTI

Current Technical Approaches
• Protocol Definitions & Standards
– Tell me the messages
• Open Architecture Mandates
– Interoperability on Commonality
• (Implementation) Architecture of the Day
– Service Oriented Architecture
– RESTful Interfaces
– …
© 2013 RTI

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
Complexity is inherent in
solution, must be managed
• 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
© 2013 RTI

Open Systems
• Open Systems
– Are defined sufficiently that
so that multiple
organizations can work
cooperatively on the same
or separate sub-components
– Have requirements which
are stable over
a sufficient length of time to
allow for concurrent
development
– Are documented fully and
openly to the development
community
– Are not under the control of
any one firm or vendor.
© 2012 RTI • COMPANY CONFIDENTIAL

Example: Blue Force Tracker Systems
8
BFT1
L-Band
TSG TSG
TSG
JNN
Ku-Band
ARMY
BFT1
VSAT
JCR
NOC
L-Band
Ground Stations
EPLRS EPLRS
EPLRS
ARMY EPLRS
EPLRS
EPLRS EPLRS
USMC
TSG
TSG
TSG
DISA
JBCP
NOC

Open Precepts, Applied
• Message-Centric NOC
Architecture
– Point to Point
– State is Implicit
– Intermediate messages are
not actionable
• Data-Centric NOC
Architecture
– Observable databus
– State is Explicit
– Intermediate state is
actionable
Comtech
Side A
Comtech
Side B
CUI Network
Gateway
Satcom 1
CUI Network
Gateway
Satcom 2
SEC
Region
Server
3
1
2 Dell PowerEdge 815
SEC
NOC
Cntlr
SEC
MySQL
Server
SEC
NTP
SEC
CDI
CUI
Region
Server
1
CUI
NOC
Cntrlr
CUI
MySQL
Server
CUI
CDI
CUI
NDS
CUI
NAS
Network Switch Network Switch
NIPR
NTP
NIPR
CDI
SEC
C2R
DDS
CUI NOC Secret NOC
Radiant
Mercury
CUI ASA 5510
Comtech
LBAND
NIPRNET
SEC Router
SEC Isolation
Router
CUI Isolation
Router
CUI Isolation
Router
BFT1
NEH
Cisco
2924XL
SEC Legacy
Gateway
SEC JCR
Gateway
SEC
Satcom
Gateway
SIPRNET
SEC
NDS
SEC
NAS
Cisco
2924XL
CUI
Aux
Trans
CUI
NTP
SEC
Aux
Trans
CUI
MTS-ES
CUI
Region
Server
2
SEC
Region
Server
4
1
2
3 4
5 6 7
8
9
1
0
1
1
SEC Enclave
RTI DDS
Radiant
Mercury
CP Conduit G
SIPRNet
CP Conduit H
Cross Domain Conduit J
SA
Process
C2
Process
SDSA
Process
KGV-72 x 4
CUI
SA
Process
C2
Process
SDSA
Process
SA
Process
C2
Process
SDSA
Process
JCR NOC
NOC SA Display Conduit K
SA
Process
C2
Process
SDSA
Process
Type 1 Conduit I
SA
Process
C2
Process
SDSA
Process
SIPRNet
Persistence
Server
SDSA/C2
Routing
Configuration
Management
Logging
Health
Monitoring
DataStore
NOC
Addressed
C2 Display
ASCOPE ASCOPE
Datastore

Results of Opening System
• Before
I. Custom implementation for
the Army
II. Centralized, monolithic and
tightly coupled
III. Under development for 8
years
IV. 500,000 SLoC
V. Required 21 quad-core
servers
VI. Supported 10,000
sustained tracks
VII. Suffered reliability and
uptime challenges
• After
I. Standards based, COTS
and Open Architecture
II. De-centralized, modular
and de-coupled
III. PoC completed in 1 week,
full system in 1 year
IV. 50,000 SLoC
V. Only requires a single core
system
VI. Supports 500,000
sustained tracks
VII. Inherently supports full
redundancy
10

System of Systems
System of Systems
• A system systems is a
collection of task-oriented
or dedicated
systems that pool
their resources and
capabilities together
to create a new, more
complex system
which offers more
functionality and
performance than
simply the sum of the
constituent systems.
System
A
System
B
System
[n]
System
A
System
B
… System
[n]
Has a set of >[n+1] capabilities

System of Systems/
Open Systems
Properties
1. Operational independence of the
component systems
2. Managerial independence of its component
systems
3. Evolutionary Independence of the
constituent systems
4. Emergent Behavior
© 2013 RTI

Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability/
Portability
• Extensibility
• Integratability
System
System
A
System
B
System
System
B
System
C
F(A,B)
Results in
X
F(C,B)
Results in
X
A and C
provide
Equal
Capability
© 2013 RTI

• Replaceability
/Portability
• Extensibility
• Integratability
System
System
A
System
B
System
System
B
System
C
F(A,B)
Results in
X, Y, Z
F(C,B)
Results in
Y, Z, W
C is NOT an
Equal
Capability, but it
Is a suitable substitute
© 2013 RTI

System
System
• Replaceability/
Portability
• Extensibility
• Integratability
System
System
B
F(A,B)
Results in
X
System
C
F(A,B,C)
Results in
X and Y
System
A
System
B
System
A
System
C
F(C)
Results in
Y
© 2013 RTI

System C
• Replaceability/
Portability
• Extensibility
• Integratability
System
B
F(A)
Results
In X
F(A,B)
Results in
Z, where
Z=G[f(X), g(Y)]
System
A
System
B
System
A
F(B)
Results
in Y
© 2013 RTI

The Key Non-Functional Requirement for a SoS
• 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.
F(A) and G(B)
Become
G[F(A)] and
F[G(B)]
F(A)
Results
In X
System
B
System
A
G(B)
Results
In Y
System of Systems
System
B
System
A
© 2013 RTI

Levels of Conceptual Interoperability
Level 6: Conceptual
Interoperability
Level 5: Dynamic Interoperability
Level 4: Pragmatic
Interoperability
Level 3: Semantic
Interoperability
Level 2: Syntactic Interoperability
Level 1: Technical
Interoperability
Level 0: No Interoperability
Increasing Capability Interoperation
© 2013 RTI

• Requires
– A stand alone system
• Result
– Stand alone systems that
have no interoperability
• Non-Functional Need
Met
– None
Level 6: Conceptual
Interoperability
Level 4: Pragmatic
Interoperability
Level 3: Semantic
Interoperability
Level 1: Technical
Interoperability
© 2013 RTI

Level 1: Technical Interoperability
• Requires
– Communications Infrastructure
established
• Result
– Bits & Bytes are exchanged in an
unambiguous manner
• Non-Functional Need Met
– Replaceability 
Interchangeability
Level 6: Conceptual
Interoperability
Level 4: Pragmatic
Interoperability
Level 3: Semantic
Interoperability
Level 1: Technical
Interoperability
© 2013 RTI

• Requires
– Communications Infrastructure
established
– Common structure or common
data format for exchanging
information
• Result
– Bits/Bytes and the Structure of
Data are exchanged in an
unambiguous manner
– Interchangeability and
Integrateability
Level 6: Conceptual
Interoperability
Level 4: Pragmatic
Interoperability
Level 3: Semantic
Interoperability
Level 1: Technical
Interoperability
© 2013 RTI

Level 3: Semantic Interoperability
Level 6: Conceptual
Interoperability
Level 4: Pragmatic
Interoperability
Level 3: Semantic
Interoperability
Level 1: Technical
Interoperability
• Required
– Communications Infrastructure and
Common Data Format are established
– Common information model is
defined for exchanging the meaning
of information
• Result
– Bits/Bytes and the structure of data
are exchanged in an unambiguous
manner
– Content of the information
exchanged is unambiguously defined
– Actual, high-level Interoperability
© 2013 RTI

Level X: Temporal Interoperability
Level 6: Conceptual
Interoperability
Level 4: Pragmatic
Interoperability
Level 3: Semantic
Interoperability
Level 1: Technical
Interoperability
• Required
– Temporal/order dependencies
between data elements are well
defined
• Result
– “Turn_On” followed by
“Turn_Off” means the same thing
across a system
– Predictable, Consistent behavior
© 2013 RTI

Integration by Example
8/22/2014 © 2013 RTI 24

Interoperation by Example
8/22/2014 © 2013 RTI 25

Interoperation by Example
8/22/2014 © 2013 RTI 26

Interoperability by Example
The procedure is actually quite simple. First you arrange things into
different groups. Of course, one pile may be sufficient depending on how
much there is to do. If you have to go somewhere else due to lack of
facilities that is the next step, otherwise you are pretty well set. It is
important not to overdo things. That is, it is better to do too few things at
once than too many. In the short run this may not seem important but
complications can easily arise. A mistake can be expensive as well. At
first the whole procedure will seem complicated.
Soon, however, it will become just another facet of life. It is difficult to
foresee any end to the necessity for this task in the immediate future, but
then one never can tell, After the procedure is completed one arranges
the materials into different groups again. Then they can be put into their
appropriate places. Eventually they will be used once more and the whole
cycle will then have to be repeated. However, that is part of life.
- Bransford & Johnson (1972)
© 2013 RTI

Data is the Key
How do you Define & Design it?
What does the Architecture look like?
© 2013 RTI

A model is anything used in any way to represent something
else
MODEL
8/22/2014 © 2013 RTI 29

A data model is a representation that describes the data about
the things that exist in your domain
DATA MODEL
8/22/2014 © 2013 RTI 30

Systems of Systems are
Different
requirements +
the requirement
for Semantic
Interoperability
many things to
System
of
Systems
[n] types of
systems
[n]sets of
express
many different
representations of
those expressions
to achieve
interoperability
8/22/2014 © 2013 RTI
31

The SOS Data Model Shall…
1. Meet the requirements of all of the constituent systems
2. Support the overarching requirement for Semantic
Interoperability
3. Allow for changes to be made to the model without
requiring changes to the existing system and
application interfaces that use it
1. 2. 3.
Formal
Language
Rigorous
Documentation
Formal Process
We Need A Formal Approach!
© 2013 RTI

Formal Language for Data
Modeling
• Similar to
structured,
rigorous
programming
languages
• Ambiguity is
not acceptable
– Syntax
– Semantics
Formal
Language
Alphabet
Transformation
Rules
Formation
Rules
© 2013 RTI

Semantics, Ambiguity, and
Language
Natural Language
Representation
• A brush hog costs 1500
dollars. I wait until the
unit goes on sale. I can
spend 450 dollars,
including 8.25% tax. On
Monday, the vendor
discounts everything by
50%. Each day an item is
not sold, it is discounted
another 25%. How soon
can I buy my part?
Formal Language
Representation
Pc = $1500...
Pc =
$1500 ´(1+ 0.0825)
or
$1500
ì
ïï
í
ï
ï
î
=
$1, 623.75
or
$1, 500.00
t = tbuywhen P £ $450
ì
í ï
î ï
@t =1,P = Pc ´(1- 0.5)
=
$811.88
or
$750.00
ì
í ï
î ï
@t ³ 2, P = Pc ´ 1- 0.5 ( ) éë
ùû
´ t -1 ( ) ´ 0.75 éë
ùû
=...
8/22/2014 © 2013 RTI
34

Documentation Methodology
• Documenting only
your messages is
insufficient
• Documentation
doesn’t end at the
data model
– Your system
– Key decisions
– Context
8/22/2014 © 2013 RTI 35

Formal Process
• Mandates are
insufficient with so
many stakeholders
• Can’t dictate
everything, must
accommodate many
things
• Data Model needs to
enforce rigorous well
defined processes,
not mandate
messages
Atomic Elements
Elements
of
Meaning
8/22/2014 © 2013 RTI
36

Model and Implementation
• Model provides the Context and Semantics
– Containment and relationships
– May not necessarily be in the messages
• Messages can be compact
– Use the model for context
– ‘Know’ the relateability of a command to a status
• Using machine readable context
– Can generate the system appropriate mediation
– Really only need the ID of ‘what’ in the message
© 2013 RTI

Putting the Pieces Together
Things to
Model from
System A
Data Model
Data Modeling Process
Structure
Behavior
Context
representation
A
representation
A
representation
[n]
per a
Rigorous and Formal
Approach
8/22/2014 © 2013 RTI
38

Data Centric Integration Solution
Legacy System A
Mediation
Mediation
New System B
Mediation
Future System C
• Technical
Interoperability
– Infrastructure &
Protocol
• Syntactic
Interoperability
– Common Data
Structure
• Semantic
Interoperability
– Common Data
Definition
8/22/2014 © 2013 RTI
39

Who is Doing this Currently?
• US OSD and the UCS (UAV Control Segment)
– Working Group has built a formal, conceptual data model by which to enforce
interoperability.
– Provides ability to calculate mediation and integration of messages from different
standards, without loss of context and semantics.
• OpenGroup FACE (Future Airborne Capability Environment)
– Focus on portability and interoperability. Using the same conceptual
data model concepts.
© 2013 RTI

UCS
• https://www.rti.com/industries/ucs.html
• Release 3.2, March 2014
– Architecture Description (UCS-INF-AD) Version 2.2
– Architecture Technical Governance (UCS-SPEC-TECHGOV) Version 2.3
– Conformance Specification (UCS-SPEC-CONFORMANCE) 2.1
– Governance (UCS-PLN-GOV) Version 3.1
– Interface Control Document (ICD) (UCS-INF-ICD) Version 2.2
– Interface Control Document (ICD) Source (UCS-INF-ICD-SRC) 2.2
– Interface Control Document: Data Distribution Service (DDS) (UCS-G-ICDDDS) Version 2.2
– Interface Control Document: Data Distribution Service (DDS) Source (UCS-G-ICDDDS-SRC) Version 2.2
– Interface Control Document: Java Messaging Service (JMS) (UCS-G-ICDJMS) Version 2.2
– Interface Control Document: Java Messaging Service (JMS) Source (UCS-G-ICDJMS-SRC) Version 2.2
– Model (UCS-SPEC-MODEL) Version 3.2
– Model Examples (UCS-G-MODELEX) Version 1.2
– Model Implementation Reference (UCS-G-MIR) Version 2.2
– Model Interchange Guide (UCS-G-MIG) 1.0
– Program of Work (UCS-PLN-AV1) Version 3.2
– EA Version of UCS ICD Model (UCS-INF-ICD-EA) 1.0
– Rhapsody Version of UCS ICD Model (UCS-INF-ICD-RPY) 1.0
– RSA Version of UCS ICD Model (UCS-INF-ICD-RSA) 1.0
– UCS/FACE Shared Data Metamodel (UCS-SPEC-UCSFACEDMM) 1.0
– Use Case to Service Interface Trace (UCS-INF-UCTRACE) Version 1.2
– Version Description Document (UCS-INF-VDD) Version 1.2

FACE
• OpenGroup FACE (Future Airborne
Capability Environment)
– Focus on portability and interoperability. Using the
same conceptual data model concepts.

FACE
• https://www.rti.com/industries/face.html
• Published Documents
– FACE Business Guide
– FACE Shared Data Model 2.0
– FACE Data Model Governance Plan
– FACE Technical Standard Edition 1.0
– Corrigendum
– FACE Reference Implementation Guide
– FACE Conformance Program Documents
– FACE Library Infrastructure Documents
• Face 101
– FACE 101 Technical Briefing
• Coming Soon
– FACE Business Guide 2.0
– FACE Contract Guide
– FACE Library Requirements 2.1
– FACE Conformance Certification Guide
– FACE Conformance Test Suite

Summary
• Open Architecture (OA) is an acquisition concept
– It is not a specific technical solution
• A large infrastructure to manage OA isn’t needed
– Architecture solely for the sake of Architecture is a waste
• Interoperability has to be by design
– By specification works for small teams
• Processes need to readily accommodate change
– Most systems are inherently dynamic
• A system’s data is the key to risk and cost
management– it must be a “first-class” citizen
– Manage content, context, and behavior….
© 2013 RTI

How to Leverage Open Architectures for Existing Systems

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (8)

Similar a How to Leverage Open Architectures for Existing Systems

Similar a How to Leverage Open Architectures for Existing Systems (20)

Más de Real-Time Innovations (RTI)

Más de Real-Time Innovations (RTI) (17)

Último

Último (20)

How to Leverage Open Architectures for Existing Systems