While swarming has been successfully demonstrated in unmanned vehicles, the underlying assumption was that the swarm was made up of UVs of the same type from the same developer. The next challenge is Air Vehicle (AV) Teaming; Co-ordinated AV’s of different types, potentially from different manufacturers, manned and unmanned, working together. This session covers recent advances in system and system-of-system architecture theory & practice, and demonstrates how common data architecture enables interoperable & dynamic implementation of teaming. The key advance is the data-centric architecture detailing the semantic context of information exchanged over AV system-interface boundaries. The definition of interoperable data architecture, and how to build in semantics for auto-discovery of AV capability, is covered along with examples of how to create a context-based (semantic) architecture. As a summary, current industry initiatives towards interoperable architectures will be highlighted.

1. Interoperability for
Teaming and Autonomy
Gordon A. Hunt – AUVSI 2013 Wash DC
Chief Engineer, RTI • UCS WG CE interoperability • Commander USN-R

2. Agenda
• Swarming and Teaming
– Control versus Command
• Background
– Open Architecture and Current Approaches
• A Team is a System of Systems
– Definitions and Examples
• Interoperability Architecture
– It is all about the Data
– How to capture and define its meaning
– Interoperability by Design

3. Swarming and Teaming
What’s the difference?
How are they achieved?
© 2013 RTI

4. Reference Scenario
© 2013 RTI

5. What does this Scenario Take
• Close cooperation – obviously
• Awareness of each AUV’s objectives
– Leverage nearby assets seamlessly
• Shared and integrated mission
management
– Right capability, right place, right time
• Ability to react to dynamic changes
– Shared awareness of system state
© 2013 RTI

6. Team or a Swarm?
• Swarm
– Usually controlled an implemented by a single integration
agency / implementer on a common timescale
• Team
– Loose grouping of assets controlled and managed by
different agencies and implementers on variable
timescales
• However…
– Have really only seen machine to machine collaboration
with swarms
– Teams are typically formed by human powered intuition
– Need to move from human-enabled to machine-enabled
collaboration and cooperation.
© 2013 RTI

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

8. 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

9. 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
© 2013 RTI

10. Are these Approaches
Sufficient?
What is different and unique in
teaming operations?
© 2013 RTI

11. SYSTEMS
© 2013 RTI

12. System of Systems
System of Systems
• A system of 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

13. System of 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

14. Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• 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

15. Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• 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

16. System
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• Extensibility
• Integratability
System
System
B
System
C
F(A,B)
Results in
X
F(A,B,C)
Results in
X and Y
System
A
System
System
B
System
A
System
C
F(C)
Results in
Y
© 2013 RTI

17. System C
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• 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

18. 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

19. 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
IncreasingCapabilityInteroperation
© 2013 RTI

20. 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

21. 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

22. 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
Integrateability
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

23. 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

24. Integration by Example
8/20/2013 25© 2013 RTI

25. Interoperation by Example
8/20/2013 26© 2013 RTI

26. Interoperation by Example
8/20/2013 27© 2013 RTI

27. 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

28. Interoperability by Example
Not only what we say,
but what does it mean?
© 2013 RTI

29. It is the Data that Matters
How do you Define & Design it?
What does the Architecture look like?
© 2013 RTI

30. MODEL
A model is anything used in any way to represent something
else
8/20/2013 31© 2013 RTI

31. DATA MODEL
A data model is a representation that describes the data about
the things that exist in your domain
8/20/2013 32© 2013 RTI

32. Systems of Systems are
Different
8/20/2013 33
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

33. 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

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

35. Semantics, Ambiguity, and
Language
Natural Language
Representation
• A super charger costs
1500 dollars. I wait until
the part goes on sale. I
can spend 450
dollars, including 8.25%
tax. On Monday, the store
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
8/20/2013 36
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éë ùû
ì
í
ï
î
ï
=...
© 2013 RTI

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

37. Formal Process
• Mandates are
insufficient with so
many stakeholders
• Can’t dictate
everything, must
accommodate many
things
• SOS DM needs to
enforce rigorous well
defined
processes, not
mandate messages
8/20/2013 38
Atomic Elements
Elements
of
Meaning
© 2013 RTI

38. 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

39. Putting the Pieces Together
8/20/2013 41
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

40. Data Centric Integration Solution
8/20/2013 42
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

41. 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

42. Thoughts On Where We Are and
Where We Have to Go…
• OA is an acquisition concept
– It is not a specific technical matter
• A large infrastructure to manage OA isn’t needed
– No Architecture solely for Architecture
• Interoperability has to be by design
– By specification works for small teams
• Processes need to remain flexible
– Systems are dynamic
• Need to own the most important aspect of a
system, the data.
– It content, context, and behavior….
© 2013 RTI