Perspectives on Interoperability

Hans Polzer

April 2005

Interoperability Definitions/Overview Joint Publication 1-02 definition (2) for interoperability

defines C4 interoperability as the condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users.

NATO AAP-6 Definition for interoperability is “the ability of systems, units or forces to provide service to and accept services from other systems, units or forces and to use the services so exchanged to enable them to operate effectively together”

Perspectives on interoperability are diverse and context-specific

A key factor is the degree of autonomy among the interacting systems

Systems providing services to each other is a common theme

Common Approaches to System of Systems Interoperability

Commonality-Based Interaction-Based

Top-Down

(Architecture)

Bottom-Up

(Execution Environment)

NCOW-RM

NCES

DII COEJ2EE

.NET CORBA

AdaJava

SQL

SOAPXML

GCCS

GIG

WSDL, UDDI

Enterprise Architectures

Virtual EnterprisesSupply Chains

COIsBML

COM

POSIX

DNS

IP v6

ebXML

UPC code

LISI

Actual SoS Implementations are Usually Some Mixture of These Approaches

IERsJTA

System(s) of Systems Definition• System of Systems (SOS) Definitions are also diverse

– No authoritative definition that spans all customer/system types• CJCSI 3170 glossary includes definitions for Family of

Systems (FoS) and System of Systems (SoS)– An FoS has less system interdependence than an SoS

– Boundaries between Systems and Systems of Systems are soft• Key cues in definitions of interoperability:

– Definitions don’t focus on commonality across force elements– Notion of services offered to each other by semi-autonomous force

elements– Coupling between force elements is dynamic and ad hoc

A System of Systems is one comprised of systems whose A System of Systems is one comprised of systems whose internal structure and exposed service set is not driven internal structure and exposed service set is not driven exclusivelyexclusively by the purpose of the larger system, or by each other by the purpose of the larger system, or by each other

–Otherwise it’s just a big, complex system with subsystemsOtherwise it’s just a big, complex system with subsystems

SOS Interoperability Challenges• Most programs do not have enterprise scope• New found capability orientation in customer acquisitions

– No real operational examples as yet• Systems are often part of multiple capabilities and systems

of systems• Systems often need to interact with multiple enterprises on

the GIG and beyond• Systems comprising a SOS are often on widely varying

timelines and technology bases– Diverse system ownership likely

• Security considerations create obstacles to information flow among systems of systems

• Operational contexts for systems are typically not manifest in their offered interfaces

Systems, Capabilities, Operations, Programs, Enterprises (SCOPE)

• An enterprise has scope in operational, time, resource and other domains

• So does a capability, which may involve multiple enterprises• Most enterprises have multiple capabilities and use them to varying

degrees to achieve enterprise goals• An operation is a kind of enterprise, usually with more limited time span

and goals– But some operations dwarf many traditional “enterprises” – e.g., Iraqi

Freedom, WW2• A program is a mini-enterprise/operation focused on building a system

that provides some capability for a larger/customer enterprise• A program may be responsible for developing multiple systems needed

for a capability (e.g., an LSI program)– More often a capability is implemented through multiple systems under

heterogeneous sponsorship – Horizontal Integration (HI)

System(s) of Systems Engineering encompasses both single program System(s) of Systems Engineering encompasses both single program capability engineering (LSI) and multi-program/system interoperabilitycapability engineering (LSI) and multi-program/system interoperability

Tactical C2 MCP

Missile Defense MCP

Time-Critical Strike MCP

AWN78

SUWN76

USWN77

EXWN75

ASWN74

Relating Enterprise, Mission Capabilities, Operations, Programs and System of Systems

Systems of systems aligned to these capabilitiesSystems of systems aligned to these capabilities

Current Navy Warfare SponsorsCurrent Navy Warfare Sponsors

ISR MCP

Navigation MCP

““Intergalactic Radiator”Intergalactic Radiator”by Capt Yurchakby Capt Yurchak

For scope illustration onlyFor scope illustration only

Illustrates Complex Dependencies in Capability AcquisitionIllustrates Complex Dependencies in Capability Acquisition

Budgets allocated verticallyBudgets allocated vertically

Individual Program/SystemIndividual Program/System

EnterpriseEnterprise

OperationsOperations

Growing Importance of Interoperability

• Network Centric warfighting concepts push systems towards greater interaction

• Advent of the GIG increasingly makes systems accessible to one another

• Growing experience with coalition operations drives coalition interoperability

• Commercial adoption of the Internet increases customer “sense of the possible”

• Customer initiatives in joint battle management and capability-oriented acquisition create KPPs for our programs

Customer Initiatives in Interoperability• CJSCI/M 3170.01 Joint Capability Integration and Development

System (JCIDS)• CJCSI 6212.01C Interoperability and Supportability of Information

Technology and National Security Systems• DOD Architecture Framework (DODAF)

– Provides a process and representation framework for developing and sharing architectures

• Global Information Grid (GIG)– Provides pervasive network connectivity to DoD Systems

• GIG Network Centric Enterprise Services (NCES)– Provides Core Enterprise Services to DoD Systems beyond 06– Facilitates Community of Interest (COI) shared services

• Horizontal Fusion Initiative– OSD Initiative to foster horizontal integration across programs

Interoperability Assessment Approaches

• Levels of Information System Interoperability (LISI)– Inspeqtor assessment tool (questionnaire)

• JITC Compliance Testing• Net Ready KPP

– Partially based on LISI and Inspeqtor tool• NATO Industrial Advisory Group (NIAG) Study

Group 76 Report on Interoperability– Enhanced by Lockheed Martin to mesh better with

DODAF architecture views• Many other approaches, mostly “level” based

and IT technology-oriented or program-centric

PEnterprise

Domain

Functional

Connected

Isolated

Universal

Integrated

Distributed

Peer-to-Peer

Manual

EnterpriseLevel

DomainLevel

ProgramLevel

Local/SiteLevel

AccessControl

Interactive

Groupware

DesktopAutomation

StandardSystemDrivers

N/A

Multi-DimensionalTopologies

World-wideNetworks

LocalNetworks

SimpleConnection

Independent

EnterpriseModel

DomainModel

ProgramModel

Local

Private

4

3

2

1

0

A I DDescription LevelComputing

Environment

LISI Reference Model

(Manual)

4

3

2

1

0c

d

b

a

c

c

a

c

PP AA II DD

(Universal)

(Integrated)

(Distributed)

(Peer-to-Peer)

Interoperability Attributes

DoD Enterprise

DomainService/Agency

Doctrine, Procedures,Training, etc.

ProgramStandard Procedures,

Training, etc.

StandardsCompliant

(e.g., JTA)

Security Profile

N/A PrivateData

Basic Messaging(e.g.,Unformatted Text,

E-mail w/o attachments)

Basic OperationsDocumentsBriefings

Pictures & Maps Spreadsheets

Databases

Web Browser

Full Text Cut & Paste

Group Collaboration(e.g.,White Boards, VTC)

Interactive(cross

applications)

LAN

Two Way

One Way

DomainModels

EnterpriseModel

NATOLevel 3

NATO Level 2

ProgramModels

&Advanced

DataFormats

WAN

Multi-DimensionalTopologies

NET

BasicData

Formats

(e.g., DII-COE Level 5)

Compliance

Simple Interaction(e.g., Telemetry, Remote Access

Text Chatter, Voice, Fax)

Multi-NationalEnterprises

RemovableMedia

b

a

LEVEL

c

ba

b

a

o

Full Object Cut & Paste

Adv. MessagingMessage Parsers

E-Mail w/Attachments

ManualRe-entry

Shared Data(e.g., Situation DisplaysDirect DB Exchanges)

DBMS

b

CommonOperating

Environment

IsolatedLevel

ConnectedLevel

FunctionalLevel

DomainLevel

EnterpriseLevel

(Environment)

Cross-Enterprise

Models

Data File Transfer

NATOLevel 1

ManualAccess

Controls

Media ExchangeProcedures

Media Formats

NO KNOWN INTEROPERABILITY

d

Cross GovernmentEnterprise

LISI Level Examples

NIAG SG-76 Interoperability Assessment

• Study Chartered by NATO NG-5– Focused on Naval C2 Interoperability, but also supporting joint

warfighting scenario– Scope expanded to consider non-NATO forces as well

• LISI proved to be incomplete in addressing this scenario– Focused on IT and not operational warfighting domains

• Developed “LISI-like” levels for operational and system/technical DODAF architecture views– Lockheed Martin contributed work done on Rainbow Initiative– Focused on relating interoperability dimensions to operational

effectiveness• Study report (Dec 03) includes a broad range of interoperability

related reference material• Approach subsequently enhanced to better align it with DODAF

Views

Revised LM Interoperability Assessment Model

• Align better with DODAF views– LISI PAID mapping to DODAF views not obvious– Focus on interaction between the three primary views– Recognize that systems are often part of multiple OVs

• “Net-Ready” Subdimensions and Levels for interaction of System view elements using Technical view elements– Operational Architecture independent

• “Functional Capability” Subdimensions for interaction of systems to achieve Operational view capabilities– Technical Architecture independent

• “Technical Feasibility” Subdimensions and Levels for achievability of Operational view capabilities given Technical view elements– System Architecture independent

Operational View

Technical ViewsSystems View

Identifies Participant Relationshipsand Information Needs

Relates Capabilities/Characteristicsto Operational Requirements

Prescribes Standardsand Conventions

DODAF Views and Capability Assessment CriteriaUJTLs

Net-Ready Levels

Capability Scope Levels

Technical Feasibility Levels

How do systems interact?What standards are used?

What do systems say to each other?How is this information represented?

Which Systemsinteract?About what?How much?And why?To what effect?

Data models, processalgorithms

BattlespaceRepresentation andNaming standards

Data element standards,Protocols, environments

Can capability beachieved with current stds & technologies? Are new standards needed?Is the informationobtainable,Accurate, timely?

Technologyreadiness levels

High

Low

High

Low

High

Low

Net Ready Dimensions and Levels

• These measure System attributes that may support multiple capabilities on the Net– Leverages emerging DoD/JCIDS notion of “Net Ready KPP”

• The “net” in “Net Ready” generally means the GIG, but by extension, can reach into subsidiary networks and data links, inside and outside DoD

• Can be viewed as an extension of JTA compliance measures for existing systems

• This is a “starter” set of dimensions– More likely to be discovered/added, including sub-dimensions– Common number of “levels” shown for illustration purposes– Levels shown as dimensions to avoid “maturity model” paradigm

• “Goldilocks” model is generally more appropriate

Measure Overall Degree to Which a Systems Makes its Services Net Accessible

Net Ready Dimensions and Levels

Information Granularity

Complex obj

ATO, Oplan

Record Level

Mission, EDI

Data Element

Standards

ASCII Text, URLs

System Arch

Binding

Specific vend.

Architecture

Industry open

architecture

Netwrk based

Interface only

Any IP net

Information

Assurance

Link encrypt -

SSL

Single signon

support

DoD-Wide PKI support

MSL, cross-

domain spprt

Service Discovery

Service specs pub at design

Service specs pub run-time

OWL spec for

Services

Comparative

service select

Service

Evolvability

Version spec in interface

Multi-version

support

Service specs

extensible

Ops context

aware interf

Tech Arch Life Cycle

Some current tech interfs

All current tech interfs

Some emrgng tech interfs

All emergng tech interfs

Level

Category

Tighter Coupling / Less Net-Readiness

Looser Coupling / More Net-Readiness

Functional Capability Dimensions

• Assess the overall level of functional capability provided by a set of systems

• Two major categories:– Capability Scope Measures/Levels– Capability-Specific Measures/Levels

• Capability Scope assesses the operational extent and pervasiveness of a capability

• Capability-Specific measures are based on MOEs and DOTMLPF considerations

Capability Scope Dimensions

Overall Scope Single Unit Single Service or Agency

DoD-Wide World-Wide

Enterprise Breadth

Single Functnal Domain/Service

Multi-Domain,

Multi-Service

Multi-Dept, NGO, Industry

Coalition

Enterprise

Depth

Single Level Two Levels Three Echelons

Four or More Echelons

Unity of SoS Ownership

Single DoD Acquis. Exec

Multiple DoD Acquis. Exec

DoD & US Syst. Owners

Multi-National Syst. Owners

Semantic Congruence

Single Domain Vocabulary

Multi-Domain Vocabulary

Single Language

Multiple Languages

Acquisition

Congruence

All Systems on Same Timeline

Timeline within 2 years

Timeline within 5 years

Timelines >5 years apart

Information Domain

Sensor/Factual Model-based (Cognitive)

Multi-model Social Reality (Collaborative)

Operational Context

Single Ops Context

Multiple Ops Contexts

Future/Past

Integration

Hypothetical Entities

Level

Category

Narrower Scope Broader Scope

Marine Corps Strat21

JointFunctionalConcepts

EnablingConcepts

JointOperating Concepts

ServiceConcepts

Air ForceCONOPS

Army Operating Concepts

Naval Operating Concept

One Possible Enterprise Breadth “Hypercube”

Battlespace Information Models (S)

Battlespace Information Models (O)

Capability Information Domains

Phenomenology – Sensing the Real World

Data From Deployed/TaskedData Collection Assets

EncyclopedicInformation, Public Info

Models, AndOpen Source

Data

World Model Building Activities

Doctrine,OPCONS,

Effects,Process

Battlespace Information Models (T)

Oplan Development and Execution

Strategy Development and Execution – Intention, Desired Effect

“Sense-making”

Purpose, Situational Awareness

Purpose, Situational Understanding

People,Objectives,

Perceptions, Intentions,

Assessments

Capability Information Types

Reality

Sensor/Factual

Battlespace Model

Operational Context

Social Reality

Capability Managed Data

Objective reality potentially detectable through phenomenology

Data collected through military assets and sensors

Representation of reality in systems contributing to a capability (eg, COP)

Subjective reality and data outside military or capability control (eg, CNN)

Subjective warfighter reality based on objectives, assessment, effects...

Linking the Three Capability Managed information Types to Each OtherIs a Key Objective of Capability Engineering and Horizontal Integration

Less Structured Information

Plan, Organize, Deploy, Employ and Sustain

Cycle

Conveyed Commander’s Intent

Physical Domain Force Advantage

Position Advantage

Information DomainInformation Advantage

Cognitive DomainCognitive AdvantageProcess Advantage

Precision Force

Compressed Operations

Shared Awareness

Speed and Access

NetworkCentric

Operations

Social DomainCultural Awareness

Net Enabling the Social and Cognitive Domains Through the Information Domain

Sample Capability-Specific Scope Dimensions

Time to Target Engagement

1 Hour 30 Minutes 10 Minutes 1 Minute

Stryker Bde Deploy Time

30 Days 7 Days 72 Hours 24 Hours

Total Lift Capacity

Single aircraft type

Multiple aircraft types

Multiple lift types

All lift types

Target Detection

Single sensor Multiple sensor Multiple sensor types

All source

ISR Management

Single Platform Multiple Platforms

Multiple platform types

All platform types

Power Grid Denial

Single Substation

Single Plant 30% Power Capacity

100% Power Capacity

LevelExampleCategory

Less Capability More Capability

Technical Feasibility Dimensions

• Represent physical and resource contraints on realizing an operational capability among systems using specific technical standards and technologies– Inherent network latency– Bandwidth availability/cost– Run-time computing power requirements– Development complexity/cost/risk

• Focus is on technical/economic feasibility of connecting systems with each other

Technical Feasibility Dimensions

Inter-System Time Binding to Achieve Capability

Days Minutes Seconds Milliseconds

GIG/NCES Resources Needed

Negligible GIG-BE Capacity

GIG FOC

Capacity

Beyond GIG FOC Capacity

Run-Time Computing Resources Needed

<1% of existing system resources

1-10% 10-50% >50% of existing system resources

Interface Development Complexity

<1% of system size

1-10% 10-50% >50% of system size

Technology Readiness Level for System Connections

TRL Levels 8-9 TRL Levels 6-7 TRL Levels 4-5 TRL Levels 1-3

Level

Category

Smaller Risk Larger Risk

Relating Interoperability Dimensions to Operational Effectiveness

• Operational value of tight coupling along a specific dimension offset by fragility in the face of change and coordination scope

• Desired operational capabilities impact different interoperability dimensions– Suggest different tradeoffs/balance points

• High performance requirements suggest greater coupling and commonality

• Broad, diverse force structures and mission types suggest less coupling and more run-time discovery

Sample Mapping to Operational Measures

Sample OA Drivers (from NATO AJP-1) Net Ready Dimensions Capability Scope Dimensions

Le

ve

l of

Ab

str

ac

tio

n

Arc

hit

ec

ture

Tim

e

Bin

din

g

Info

rma

tio

n

As

su

ran

ce

Re

so

urc

e

Co

st

Siz

e

Bre

ad

th

De

pth

Ow

ne

rsh

ip

Se

ma

nti

cs

Re

alit

y

Objective 10 40 5 5 40

Unity of Effort 10 5 5 20 25 10 5 10 10

Cooperation 10 10 10 10 5 20 10 5 10 10

Sustainment 20 5 5 30 20 10 10

Concentrate Forces 10 10 10 10 30 20 10 10 10 5

Economy of Effort 20 10 20 20 30

Flexibility 10 20 5 5 20 10 10 10 10 10

Initiative 10 15 10 5 20 20 5 10 5

Morale 5 20 10 15 30 10 10

Surprise 10 10 30 10 10 10 20

Security 50 10 10 10 10 10

Simplicity 20 20 5 5 5 20 20 10

TOTAL 110 95 60 130 35 230 155 80 125 125 65

Joint Amphibious Forced Entry Operation

Key Points• Systems contributing to capabilities are imprecise,

incomplete representations of objective reality– Different systems have different representations of the battlespace– Some of these differences are inherent in the role of the systems

• Likewise, such systems are generally weak in representing operational context or linking to social reality– Advent of net centric and collaborative C2 will drive improvements

• Sensor data is only a partial representation of reality– Needs to be fused with battlespace model and operational context

information

• Operational Context information is diverse and relatively unstructured– Includes people to people interaction and subjective assessments

• Capability implementation needs to consider all of these information types flowing between systems

Changing the scope of a capability increases the impact of each point