Integration and Interoperability

Carnegie Mellon
Software Engineering Institute

Pittsburgh, PA 15213-3890
Integration and Interoperability

Models for Systems of Systems
David Carney
Patricia Oberndorf
April 21, 2004
Systems and Software Technology Conference

INCOSE-Sponsored Track
Sponsored by the U.S. Department of Defense

© 2004 by Carnegie Mellon University
page 1
Carnegie Mellon
Outline
Background of “the interoperability problem”
Origins in integration research
Current models of interoperability
Proposed characteristics of a unified model
Conclusion
page 2
Carnegie Mellon
Current State of Software Engineering

New systems usually a heterogeneous collection of
custom and commercial products
• Integration provided by some third-party technology
New systems seldom expected to function independently
• Expected to cooperate with existing systems
(e.g., as a part of a system of systems)
• Ability to achieve “cooperation” is generally termed
"interoperability"
Elements of these cooperating systems undergo frequent
changes (e.g., upgrades of commercial products)
Thus: boundaries within and between systems begin
to blur
• Distinctions between a "system of systems" and a single,
complex, distributed system disappear
page 3
Carnegie Mellon
Current State - 2
Interoperability can occur only when some degree

of compatibility exists among all elements that
must cooperate in some purpose
Interoperability is based on the existence of (and

cannot occur lacking) a single, common
conceptual view
• Conceptual view can be embodied in an architecture
or design
• Conceptual view can be implemented through a
common protocol
• Single conceptual view determines whether a system
(or system-of-systems) can made to cooperate as
intended
page 4
Carnegie Mellon
The Problem Space

Incomplete understanding of scope and nature of
the engineering to be accomplished
• Cannot discern incompatible solutions or
intractable problems
Ongoing inertia toward separate programs,
managed and executed independently
• Cannot, in such a climate, ensure that
independent programs act in service of a
common goal (i.e., the interoperable end goal)
Few technologies currently exist that permit
quantification of any aspect of interoperability
page 5
Carnegie Mellon
An Instance of the Problem

We know quite a lot about
constructing systems from
components (over which we may Unplanned, unexpected,
have little or no control). emergent behavior here…
We know something about

composing systems of systems
from individual systems from System “B”
individual systems (over which
we may have little or no control).
We know very little about constructing

an interoperable network of
systems…the key distinction being that
the network is unbounded (or very System “A”
System “C”
loosely bounded) and has no single
“SYSTEM D”
controlling authority.
page 6
Carnegie Mellon
Outline
Conclusion
page 7
Carnegie Mellon
Integrated CASE Environments

Extensive research between c. 1987 and 1993 to
create integrated collections of CASE tools
• Also called Project Support Environments, Software
Engineering Environments, …
• Extensive technogies developed to provide
third-party integrating capability
• PCTE (ECMA) and CAIS-A (U.S. DoD) were major
integrating technologies
Considerable advance of knowledge about
integration, but few tangible instances of usable
environments
• Three integration research efforts were noteworthy
page 8
Carnegie Mellon
Wassermann
Distinguished three (later five) dimensions
of integration
Permits multiple, independent descriptions
of different facets of integration
• Tool1
Presentation
• Tool2
o l
o nt r
C
Data
page 9
Carnegie Mellon
Thomas & Nejmeh

Defined integration as “the property of a
relationship”
Distinguished between “well integrated”

and “easily integrable”
Provides a means to characterize different

aspects of integration based on different
human perspectives.
page 10
Carnegie Mellon
ECMA/NIST model
Defined capabilities in terms of “services” rather than
implementations or products
Separated notion of “framework” from tools and
applications that depend on that framework
T o o ls
O b j e c t M a n a g e m e n t S e r v ic e s
. . . . . . .
P r o c e s s M a n a g e m e n t S e r v ic e s
U se r In te r fa c e S e r v ic e s
C o m m u n ic a tio n S e r v ic e s
page 11
Carnegie Mellon
Outline
Conclusion
page 12
Carnegie Mellon
NATO C3 SAF Model
NATO C3 System Architecture Framework (NC3SAF)

• Mandated for NC3 systems architectures.
• Includes three main types of guidance for architecture
development
- Guidelines that include guiding principles for
building architectures
- Process to build and integrate architectures
- Templates with detailed descriptions.
Based on the DoD C4ISR Architectural Framework

• Different from its U.S. counterpart in that it is inclusive
of specific NATO directives, precepts and tenets.
Includes an extensive discussion of interoperability
page 13
Carnegie Mellon
NATO - 2
Levels of interoperability:
• No Data Exchange
- No physical connection exists
• Unstructured Data Exchange
- Exchange of human-interpretable, unstructured data (free text)
• Structured Data Exchange
- Exchange of human-interpretable structured data intended for
manual and/or automated handling, but requires manual
compilation, receipt, and/or message dispatch
• Seamless Sharing of Data
- Automated data sharing within systems based on a common
exchange model
• Seamless Sharing of Information
- Universal interpretation of information through cooperative
data processing
page 14
Carnegie Mellon
NATO - 3
Sub-degree descriptions:
Unstructured Data Exchange
1.A Network Connectivity Network connectivity can range from a
simple transport line for file transfer or basic email connecting to non-
NATO systems, to full connectivity with services required by the higher
sub-degrees….
1.A.1InternetworkingAll LAN, MAN, WAN Connections.
1.A.2Secure Internetworking Secure LAN, WAN, WAN Connections.
1.A.3Packet Switch WAN Connecting to NIDTS/PTT Packet Network.
1.A.4Circuit Switched WAN Connecting to NCN, National, Commercial
Switched Network.
1.A.5Remote Terminal Interactive computer session from remote
location.
1.A.6TADIL CommsCommunications for Tactical Link 11, 16 and 22
Data Interchange.
1.A.7SATCOMConnecting to UHF and EHF Satellite Comms.
…….
page 15
Carnegie Mellon
LISI Model: Levels of Interoperability
page 16
Carnegie Mellon
LISI Model: “PAID” Attributes
page 17
Carnegie Mellon
LCIM model
Incorporates notion of Conceptual interoperability
• Explicit focus on semantic issues
• Maintains concept of increasing maturity, levels, etc.
Level 4
Harmonized Data and Processes Common Conceptual Model /
(Conceptual Model, Intend of Use) Semantic Consistency
Level 3
Conceptual Interoperability
Aligned Dynamical Data Common System Approach /

and “Implemented Processes” Open Source Code
Level 2
Aligned Static Data Use of Common Reference Models /
through (Meta) Data Management Common Ontology
Level 1
Documented Data Documentation of
Data and Interfaces
Level 0
Systems Specific Data Isolated Systems
page 18
Carnegie Mellon
SOSI model
Focus is on different domains of interoperability
• Programmatic, Constructive, Operational
• Different kinds of activities and relationships in each
domain
Activities performed to manage the
Program acquisition of a system. Focus is on
contracts, incentives, and practices
Management
such as risk management.
Construction
System
Activities performed to create and sustain a system.

Focus is on architecture, standards, and commercial
off-the-shelf (COTS) products.
Activities performed to operate a system.

Operational Focus is on interactions with other systems
System and with users.
page 19
Carnegie Mellon
SoSI - 2
Pro
PM g ram
ma
Construction
tic
Co In ter
ns t op
ruc e ra
t ive PM bili
ty
Construction
System
Int
e rop
era PM
Op b ility
Construction
era
tio
nal System
Int
ero
per
abi
lity System
page 20
Carnegie Mellon
Outline

of interoperability
Conclusion
page 21
Carnegie Mellon
Some General Precepts

“Interoperability” is a multi-dimensional aspect of
system engineering
• Scope is far greater than simply interoperability of
data
• Encompasses interoperablity at the programmatic
(and other) levels
• A model must includes degrees of coupling,
heterogeneity, synchronicity, . . .
We can never anticipate fully the boundaries that a
given system will be expected to operate within
Interoperability must be quantifiable to be
achievable
Interoperability must be sustainable and sustained
page 22
Carnegie Mellon
Proposed Characteristics
Based on observations about desired types

and levels of interoperability
Must be verified and validated through

scenarios drawn from real programs
Characteristics chosen are not necessary

discrete
List needs refinement through further research
page 23
Carnegie Mellon
Proposed Characteristics - 2
Six principal characteristics:
• Coupling
• Heterogeneity
• Synchronicity
• Boundedness
• Ownership
• Usage patterns
May be more characteristics
• These may be at a lower (or higher)
level of importance
page 24
Carnegie Mellon
Coupling
Should permit modeling the aggregate degree of

coupling in an interoperating system
• Coupling among its elements (i.e., systems)
• Elements may themselves be collections of systems
• Continues recursively until some base level of
complexity of internal coupling within an individual
system
Aggregate degree of coupling has implications for

techniques, strategies, difficulty, etc. to create, use,
or sustain the entire system of systems.
page 25
Carnegie Mellon
Heterogeneity
Should permit modeling both syntactic and

semantic complexity
• Each pair-wise set of systems will exhibit both
kinds
• As the number of systems grows beyond a pair,
this complexity grows combinatorially
The degree of heterogeneity (and at both syntactic

and semantic levels) may suggest the degree of
difficulty in achieving and sustaining
interoperability between the pair.
page 26
Carnegie Mellon
Synchronicity
Should permit modeling the rates at which

elements (i.e., individual systems) undergo change
• Change includes update, modernization, repair,
and so forth
• Like other properties, this is recursive down to
the level of individual components
The degree to which individual systems’ rates of

change are synchronous will affect the degree to
which the aggregate interoperability is sustainable
(and perhaps achievable at all).
page 27
Carnegie Mellon
Boundedness
Should permit modeling the degree and nature of

external and internal system boundaries
• Some interoperable systems occurs when the
aggregate collection of systems is initially
known
• Other interoperable systems, actual extent of the
system-of-systems is known to be unknown.
Methods, techniques, and technologies used to
bring about the aggregate interoperation will likely
be different
• Ongoing maintenance of the overall system will
also differ
page 28
Carnegie Mellon
Ownership
Should permit modeling the different qualities of
authority over systems and elements of systems
• Some complex systems of systems are methodically
planned (e.g., U.S. DoD’s Future Combat System)
- Possible (or should be) to identify some controlling
agency of the overall system(s)
• Some interoperability occurs opportunistically, when
two (or more) diverse systems are linked in unplanned
but useful ways
- Usually impossible to identify any agency with
responsibility for the overall aggregate system
Will generally be very different processes,
techniques, and methods used to bring about the
interoperability between the constituent systems
page 29
Carnegie Mellon
Usage Patterns
Should permit modeling the conformity between
intended and actual usage patterns throughout the
system
• All elements of any system (i.e., components, entire
systems) have an intended pattern of use
• An interoperating set of systems also has an intended
pattern of use
- This will conform to usage patterns of some
elements, and conflict with usage patterns of other
elements
Aggregate degree of harmony and conflict may
determine the usability and robustness of the
overall system
• This characteristics will be inconsistent across the
system’s elements
page 30
Carnegie Mellon
Outline
Conclusion
page 31
Carnegie Mellon
Conclusion
Appropriate models have proven to be of

considerable value in many engineering
domains
We are presently in need of such models for
integrating collections of software systems
Current efforts have produced several
interesting and useful models
• Much more work is needed
page 32
Carnegie Mellon
Conclusion - 2
Trend toward ever-increasing intercon-

nection between systems will continue
Nature and quality of these intercon-

nections will be governed by decisions
now being made
Effects of these decisions may be long-

lasting
page 33
Carnegie Mellon
References
Levine, L. et al. Proceedings of the System of Systems Interoperability
Workshop (February 2003) (CMU/SEI-2003-TN-016). Pittsburgh, PA:
Software Engineering Institute, Carnegie Mellon University, 2003
<www.sei.cmu.edu/publications/documents/03.reports/03tn016.html>
Brownsword, Carney, et al. Current Perspectives on Interoperability
CMU/SEI-2004-TR009, March 2004
Tolk, A. & Muguira, J. “The Levels of Conceptual Interoperability Model.”
Proceedings of the 2003 Fall Simulation Interoperability Workshop.
Orlando, Florida, Sept. 14-19, 2003. Orlando, FL: Simulation Interoperability
Standards Organization, 2003
C4ISR Architecture Working Group. Levels of Information Systems
Interoperability (LISI). U.S. Department of Defense, March 1998
<www.defenselink.mil/nii/org/cio/i3/lisirpt.pdf>
Warner, N. “Interoperability - An Australian View.” Proceedings of the 7th
International Command and Control Research and Technology Symposium.
Quebec City, Canada, Sept. 16-20, 2002. Washington, DC:
CCRP/Department of Defense, 2002.
page 34
Carnegie Mellon
For More Information
David Carney, Patricia Oberndorf

Carnegie Mellon University
Pittsburgh, PA, USA 15213
{djc, po}@sei.cmu.edu
page 35

Integration and Interoperability

Uploaded by

Copyright:

Available Formats

Integration and Interoperability

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Integration and Interoperability

Uploaded by

Copyright:

Available Formats

Carnegie Mellon

Software Engineering Institute

Integration and Interoperability

Systems and Software Technology Conference

Sponsored by the U.S. Department of Defense

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

Current State of Software Engineering

Interoperability can occur only when some degree

Interoperability is based on the existence of (and

The Problem Space

An Instance of the Problem

We know something about

We know very little about constructing

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

Integrated CASE Environments

Thomas & Nejmeh

Distinguished between “well integrated”

Provides a means to characterize different

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

NATO C3 SAF Model

NATO C3 System Architecture Framework (NC3SAF)

Based on the DoD C4ISR Architectural Framework

Includes an extensive discussion of interoperability

LISI Model: Levels of Interoperability

LISI Model: “PAID” Attributes

Aligned Dynamical Data Common System Approach /

Activities performed to create and sustain a system.

Activities performed to operate a system.

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

Some General Precepts

Based on observations about desired types

Must be verified and validated through

Characteristics chosen are not necessary

List needs refinement through further research

Should permit modeling the aggregate degree of

Aggregate degree of coupling has implications for

Should permit modeling both syntactic and

The degree of heterogeneity (and at both syntactic

Should permit modeling the rates at which

The degree to which individual systems’ rates of

Should permit modeling the degree and nature of

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

Appropriate models have proven to be of

Trend toward ever-increasing intercon-

Nature and quality of these intercon-