HOW TO COMMUNICATE HOW TO CONNECT HOW TO PROMOTE SUCCESS Financial Aid Services.
How to leverage_open_architectures_for existing_systems
-
Upload
real-time-innovations-rti -
Category
Technology
-
view
245 -
download
0
description
Transcript of 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
• 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
Complexity is inherent in solution, must be managed
© 2013 RTI
OPENSYSTEMS
© 2013 RTI
© 2012 RTI • COMPANY CONFIDENTIAL
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.
Example: Blue Force Tracker Systems
8
TSG TSG
TSG
JNNKu-Band
ARMYBFT1
BFT1L-Band
VSAT
JCRNOC
L-Band Ground Stations
EPLRSEPLRS
EPLRS EPLRS
ARMY EPLRS
EPLRS EPLRS
USMC
GCSS-J – GCSS-A - DDS
Rea
chb
ack
TSG
TSG
TSG
DISAVPN
JBCPNOC
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
ComtechSide A
ComtechSide B
CUI Network Gateway Satcom 1
CUI Network Gateway Satcom 2
SE
C
Re
gio
n
Se
rver
3
SE
C
NO
C
Cn
tlr
SE
CM
yS
QL
S
erv
er
SE
C
NT
P
SE
C
CD
I
CU
I R
eg
ion
S
erv
er
1
CU
I N
OC
C
ntr
lr
CU
IM
yS
QL
S
erv
er
CU
I C
DI
CU
I N
DS
CU
I N
AS
Network Switch Network Switch
NIP
R
NT
P
NIP
R
CD
I
SE
CC
2R
D
DS
CUI NOC Secret NOC
Ra
dia
nt
Me
rcu
ry
CUI ASA 5510
ComtechLBAND
NIPRNET
SEC Router
SEC Isolation Router
CUI Isolation Router
CUI Isolation Router
BF
T1
NE
H
Cisco 2924XL
SEC Legacy Gateway
SEC JCR Gateway
SECSatcom Gateway
SIPRNET
SE
C
ND
SS
EC
N
AS
Cisco 2924XL
CU
I A
ux
Tra
ns
CU
I N
TP
SE
C
Au
x
Tra
ns
CU
I M
TS
-E
S
CU
I R
eg
ion
S
erv
er
2
SE
C
Re
gio
n
Se
rver
4
1
2
3 4
5 6 7
8
9
10
11
12 Dell PowerEdge 815
RTI DDS
SEC Enclave
RadiantMercury
CP Conduit G
SIPRNet
CP Conduit H
Cross Domain Conduit J
SA Process
C2 Process
SDSA Process
KGV-72 x 4CUI
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
PersistenceServer
SDSA/C2 Routing
ConfigurationManagement
Logging
Health Monitoring
DataStore
NOC Addressed C2 Display
ASCOPE ASCOPEDatastore
Results of Opening System
• BeforeI. 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
• AfterI. 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 inX
F(C,B)Results inX
A and C provideEqual Capability
© 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 inX, Y, Z
F(C,B) Results inY, Z, W
C is NOT an Equal Capability, but it Is a suitable substitute
© 2013 RTI
System
Key Non-Functional Requirements for a System
• Interchangeability• Replaceability/
Portability• Extensibility• Integratability
System
System B
System C
F(A,B) Results inX
F(A,B,C)Results inX and Y
System A
System
System B
System A
System C
F(C) Results inY
© 2013 RTI
System C
Key Non-Functional Requirements for a System
• Interchangeability• Replaceability/
Portability• Extensibility• Integratability
System B
F(A)Results In X
F(A,B)Results inZ, 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
• Interoperabilitythe 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)BecomeG[F(A)] and F[G(B)]
F(A)ResultsIn X
System B
System A
G(B)ResultsIn Y
System of Systems
System B
System A
© 2013 RTI
Levels of Conceptual Interoperability
Level 0: No Interoperability
Level 1: Technical Interoperability
Level 2: Syntactic Interoperability
Level 3: Semantic Interoperability
Level 4: Pragmatic Interoperability
Level 5: Dynamic Interoperability
Level 6: Conceptual Interoperability
Incr
easi
ng C
apab
ility
Inte
rope
ratio
n
© 2013 RTI
Level 0: No Interoperability
• Requires– A stand alone system
• Result– Stand alone systems that
have no interoperability
• Non-Functional Need Met
– None
Level 0: No Interoperability
Level 1: Technical Interoperability
Level 2: Syntactic Interoperability
Level 3: Semantic Interoperability
Level 4: Pragmatic Interoperability
Level 5: Dynamic Interoperability
Level 6: Conceptual 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 0: No Interoperability
Level 1: Technical Interoperability
Level 2: Syntactic Interoperability
Level 3: Semantic Interoperability
Level 4: Pragmatic Interoperability
Level 5: Dynamic Interoperability
Level 6: Conceptual Interoperability
© 2013 RTI
Level 2: Syntactic Interoperability
• 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
• Non-Functional Need Met– Interchangeability and
IntegrateabilityLevel 0: No Interoperability
Level 1: Technical Interoperability
Level 2: Syntactic Interoperability
Level 3: Semantic Interoperability
Level 4: Pragmatic Interoperability
Level 5: Dynamic Interoperability
Level 6: Conceptual Interoperability
© 2013 RTI
Level 3: Semantic Interoperability
Level 0: No Interoperability
Level 1: Technical Interoperability
Level 2: Syntactic Interoperability
Level 3: Semantic Interoperability
Level 4: Pragmatic Interoperability
Level 5: Dynamic Interoperability
Level 6: Conceptual 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
• Non-Functional Need Met– Actual, high-level Interoperability
© 2013 RTI
Level X: Temporal Interoperability
Level 0: No Interoperability
Level 1: Technical Interoperability
Level 2: Syntactic Interoperability
Level 3: Semantic Interoperability
Level 4: Pragmatic Interoperability
Level 5: Dynamic Interoperability
Level 6: Conceptual 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
• Non-Functional Need Met– Predictable, Consistent behavior
© 2013 RTI
04/08/2023 24
Integration by Example
© 2013 RTI
04/08/2023 25
Interoperation by Example
© 2013 RTI
04/08/2023 26
Interoperation by Example
© 2013 RTI
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
04/08/2023 29
MODEL
A model is anything used in any way to represent something else
© 2013 RTI
04/08/2023 30
DATA MODEL
A data model is a representation that describes the data about the things that exist in your domain
© 2013 RTI
04/08/2023 31
Systems of Systems are Different
System of
Systems
[n] types of systems
[n]sets of requirements +
the requirement for Semantic
Interoperability
many things to express
many different representations of those expressions
to achieve interoperability
© 2013 RTI
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
Formal Language
Rigorous Documentation Formal Process
1. 2. 3.
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
04/08/2023 34
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
© 2013 RTI
04/08/2023 35
Documentation Methodology
• Documenting only your messages is insufficient
• Documentation doesn’t end at the data model– Your system– Key decisions – Context
© 2013 RTI
04/08/2023 36
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 ElementsElements
of Meaning
© 2013 RTI
© 2013 RTI
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
04/08/2023 38
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
© 2013 RTI
04/08/2023 39
Data Centric Integration Solution
Legacy System A
Mediation
Future System C
Mediation
New System B
Mediation
• Technical Interoperability– Infrastructure &
Protocol
• Syntactic Interoperability– Common Data
Structure
• Semantic Interoperability– Common Data
Definition
© 2013 RTI
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
© 2012 RTI • COMPANY CONFIDENTIAL
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
© 2012 RTI • COMPANY CONFIDENTIAL
FACE• OpenGroup FACE (Future Airborne Capability
Environment)– Focus on portability and interoperability. Using the
same conceptual data model concepts.
© 2012 RTI • COMPANY CONFIDENTIAL
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 Technical Standard Edition 2.0– FACE Technical Standard Edition 2.1– 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