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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

Outline

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

Conclusion

page 7
 Carnegie Mellon
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

Outline

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

Conclusion

page 12
 Carnegie Mellon
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

LISI Model: Levels of Interoperability

page 16
Carnegie Mellon
Software Engineering Institute

LISI Model: “PAID” Attributes

page 17
 Carnegie Mellon
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

Outline

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

of interoperability

Conclusion
page 21
 Carnegie Mellon
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

Outline

Background of “the interoperability problem”

Origins in integration research

Current models of interoperability

Proposed characteristics of a unified model

Conclusion

page 31
Carnegie Mellon
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

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
Software Engineering Institute

For More Information

David Carney, Patricia Oberndorf

Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA, USA 15213

{djc, po}@sei.cmu.edu

page 35