perspectives on interoperability hans polzer april 2005
TRANSCRIPT
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