Interoperability for
Teaming and Autonomy
Gordon A. Hunt – AUVSI 2013 Wash DC
Chief Engineer, RTI • UCS WG CE interoperabi...
Agenda
• Swarming and Teaming
– Control versus Command
• Background
– Open Architecture and Current Approaches
• A Team is...
Swarming and Teaming
What’s the difference?
How are they achieved?
© 2013 RTI
Reference Scenario
© 2013 RTI
What does this Scenario Take
• Close cooperation – obviously
• Awareness of each AUV’s objectives
– Leverage nearby assets...
Team or a Swarm?
• Swarm
– Usually controlled an implemented by a single integration
agency / implementer on a common time...
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
– Inte...
Is Current Practice Working
• Recent studies have shown a growth in interoperability
policy issuance in DoD
– Thousands of...
Are these Approaches
Sufficient?
What is different and unique in
teaming operations?
© 2013 RTI
SYSTEMS
© 2013 RTI
System of Systems
System of Systems
• A system of systems
is a collection of task-
oriented or dedicated
systems that pool...
System of Systems Properties
1. Operational independence of the
component systems
2. Managerial independence of its
compon...
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• Extensibility
• Integratability
Syste...
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• Extensibility
• Integratability
Syste...
System
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• Extensibility
• Integratabilit...
System C
Key Non-Functional Requirements for a System
• Interchangeability
• Replaceability
• Extensibility
• Integratabil...
The Key Non-Functional Requirement for a SoS
• Interoperability
the ability of
systems, units, or
forces to provide
servic...
Levels of Conceptual Interoperability
Level 0: No Interoperability
Level 1: Technical
Interoperability
Level 2: Syntactic ...
Level 0: No Interoperability
• Requires
– A stand alone system
• Result
– Stand alone systems that
have no interoperabilit...
Level 1: Technical Interoperability
• Requires
– Communications Infrastructure
established
• Result
– Bits & Bytes are exc...
Level 2: Syntactic Interoperability
• Requires
– Communications Infrastructure
established
– Common structure or common
da...
Level 3: Semantic Interoperability
Level 0: No Interoperability
Level 1: Technical
Interoperability
Level 2: Syntactic Int...
Integration by Example
8/20/2013 25© 2013 RTI
Interoperation by Example
8/20/2013 26© 2013 RTI
Interoperation by Example
8/20/2013 27© 2013 RTI
Interoperability by Example
The procedure is actually quite simple. First you arrange things into
different groups. Of cou...
Interoperability by Example
Not only what we say,
but what does it mean?
© 2013 RTI
It is the Data that Matters
How do you Define & Design it?
What does the Architecture look like?
© 2013 RTI
MODEL
A model is anything used in any way to represent something
else
8/20/2013 31© 2013 RTI
DATA MODEL
A data model is a representation that describes the data about
the things that exist in your domain
8/20/2013 3...
Systems of Systems are
Different
8/20/2013 33
System
of
Systems
[n] types of
systems
[n]sets of
requirements +
the require...
The SOS Data Model Shall…
1. Meet the requirements of all of the constituent systems
2. Support the overarching requiremen...
Formal Language for Data
Modeling
• Similar to
structured, rig
orous
programming
languages
• Ambiguity is
not acceptable
–...
Semantics, Ambiguity, and
Language
Natural Language
Representation
• A super charger costs
1500 dollars. I wait until
the ...
Documentation Methodology
• Documenting only
your messages is
insufficient
• Documentation
doesn’t end at the
data model
–...
Formal Process
• Mandates are
insufficient with so
many stakeholders
• Can’t dictate
everything, must
accommodate many
thi...
Model and Implementation
• Model provides the Context and Semantics
– Containment and relationships
– May not necessarily ...
Putting the Pieces Together
8/20/2013 41
Things to
Model from
System A
Data Model
Data Modeling Process
Structure
Behavior...
Data Centric Integration Solution
8/20/2013 42
Legacy System A
Mediation
Future System C
Mediation
New System B
Mediation
...
Who is Doing this Currently?
• US OSD and the UCS (UAV Control Segment)
– Working Group has built a formal, conceptual dat...
Thoughts On Where We Are and
Where We Have to Go…
• OA is an acquisition concept
– It is not a specific technical matter
•...
Upcoming SlideShare
Loading in …5
×

Interoperability for Teaming and Autonomy

369
-1

Published on

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.

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
369
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Interoperability for Teaming and Autonomy

  1. 1. Interoperability for Teaming and Autonomy Gordon A. Hunt – AUVSI 2013 Wash DC Chief Engineer, RTI • UCS WG CE interoperability • Commander USN-R
  2. 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. 3. Swarming and Teaming What’s the difference? How are they achieved? © 2013 RTI
  4. 4. Reference Scenario © 2013 RTI
  5. 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. 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. 7. Background How Do We ‘Do’ Interoperability? What is labeled ‘Open’? © 2013 RTI
  8. 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. 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. 10. Are these Approaches Sufficient? What is different and unique in teaming operations? © 2013 RTI
  11. 11. SYSTEMS © 2013 RTI
  12. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. Integration by Example 8/20/2013 25© 2013 RTI
  25. 25. Interoperation by Example 8/20/2013 26© 2013 RTI
  26. 26. Interoperation by Example 8/20/2013 27© 2013 RTI
  27. 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. 28. Interoperability by Example Not only what we say, but what does it mean? © 2013 RTI
  29. 29. It is the Data that Matters How do you Define & Design it? What does the Architecture look like? © 2013 RTI
  30. 30. MODEL A model is anything used in any way to represent something else 8/20/2013 31© 2013 RTI
  31. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×