Interoperability for teaming and autonomy

Interoperability for Teaming and Autonomy

Gordon A. Hunt – AUVSI 2013 Wash DC

Chief Engineer, RTI • UCS WG CE interoperability • Commander USN-R

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

Swarming and Teaming

What’s the difference?

How are they achieved?

© 2013 RTI

© 2013 RTI

Reference Scenario

© 2013 RTI

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

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.

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

Can’t make complexity go away, just move where it is

© 2013 RTI

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 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 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• 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



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



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



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


• Requires– A stand alone system

• Result– Stand alone systems that

have no interoperability

• Non-Functional Need Met

– None








© 2013 RTI


• Requires– Communications Infrastructure

established

• Result– Bits & Bytes are exchanged in an

unambiguous manner

• Non-Functional Need Met– Replaceability

Interchangeability








© 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

• Non-Functional Need Met– Interchangeability and

IntegrateabilityLevel 0: No Interoperability







© 2013 RTI









• 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

04/08/2023 25

Integration by Example

© 2013 RTI

04/08/2023 26

Interoperation by Example

© 2013 RTI

04/08/2023 27

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

© 2013 RTI

Interoperability by Example

Not only what we say, but what does it mean?

It is the Data that Matters

How do you Define & Design it?

What does the Architecture look like?

© 2013 RTI

04/08/2023 31

MODEL

A model is anything used in any way to represent something else

© 2013 RTI

04/08/2023 32

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 33

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 36

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

© 2013 RTI

04/08/2023 37

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 38

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

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 41

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 42

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

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

Interoperability for teaming and autonomy

Business

system b system n system

system of systems definitions

system of systems properties

complex system

component systems

constituent systems

dedicated systems

increased interoperability