Regular Paper
System of Systems Integration: Key
Considerations and Challenges
Azad M. Madni*,1 and Michael Sievers†,2
1
Daniel J. Epstein Department of Industrial and Systems Engineering, Viterbi School of Engineering, University of Southern California,
Los Angeles, CA 90089
2
Jet Propulsion Laboratory, California Institute of Technology, Pasadena, CA 91109
SoSI: KEY CONSIDERATIONS AND CHALLENGES
Received 22 December 2012; Revised 9 February 2013; Accepted 9 February 2013, after one or more revisions
Published online 1 July 2013 in Wiley Online Library (wileyonlinelibrary.com).
DOI 10.1002/sys.21272
ABSTRACT
As systems are called on to participate on demand within system-of-systems (SoS), system-of-systems
integration (SoSI) has become a key concern. This capability is especially important in defense and
aerospace where systems are increasingly required to interoperate on demand to satisfy mission requirements. SoSI is also becoming increasingly important in healthcare and energy domains. SoSI involves
interfacing and enabling the interactions of component systems to create the needed SoS capability to
accomplish mission or business goals. SoSI, which is part of the overall SoS development life cycle,
increases in complexity when there are legacy systems that need to be integrated, and when humans are
tasked to perform in various capacities within the SoS. An added layer of complexity is introduced when
the SoS has to exhibit certain quality attributes such as adaptability and resilience in the face of
contingencies and disruptions in the operational environment. This paper addresses key considerations
and challenges in SoSI. © 2013 Wiley Periodicals, Inc. Syst Eng 17: 330−347, 2014
Key words: system of systems; system of systems integration; human-systems integration; interoperability; integration ontology
1996]. An SoS may also be a system designed to accommodate varying missions, some of which cannot yet be defined
with any precision. An SoS may be formed dynamically to
perform a given mission and then reorganized as needed for
other missions including those that have not yet been envisioned. A good SoS design might have modules that are not
as good as their stand-alone counterparts that perform the
same functions. As such, these modules might not be employed independently even though technically they could. An
SoS is commonly characterized using terms such as interoperable, synergistic, distributed, adaptable, trans-domain, reconfigurable, and heterogeneous. As SoS complexity
increases [Madni, 2012b; Vuletid et al., 2005], system of
systems integration (SoSI) takes on a new meaning that comes
with a host of new challenges. SoSI is intended to create a
new mission capability through composition of component
1. INTRODUCTION
A system of systems (SoS) is a collection of systems that were
originally designed as stand-alone systems for specific and
different purposes but that have been brought together within
the SoS umbrella to create a new capability needed for a
particular mission [Mayk and Madni, 2006; Manthorpe,
*Author to whom all correspondence should be addressed (e-mail:
azad.madni@usc.edu).
†
This work was done as a private venture and not in the author’s capacity as
an employee of the Jet Propulsion Laboratory, California Institute of Technology.
Systems Engineering Vol. 17, No. 3,
2, 2014
© 2013 Wiley Periodicals, Inc.
1
330
2
MADNI AND SIEVERS
systems that contribute to the overall capability. Once the
component systems are developed, they are incrementally
integrated and tested and, ultimately, deployed in the operational environment. Often, the component systems tend to
have different customers and purposes and, as such, tend to
employ different terminologies and concepts. Integrating
such systems requires resolving semantic and syntactic differences which adds to overall SoS complexity. Furthermore,
when SoSI involves integrating legacy systems, it is rarely the
case that the documentation and expertise needed for smooth
integration are readily available.
At the outset, it is worth noting that the conditions under
which an SoS has to operate are becoming increasingly more
challenging [Neches and Madni, 2012]. For example, defense
and aerospace systems today have to satisfy affordability,
adaptability, security, reliability, and resilience requirements
[Madni and Jackson, 2009; Rehage et al., 2004; Mosterman
et al., 2005]. The same is true of healthcare enterprises and
energy grids.
Whether or not a given configuration is an SoS is more a
matter of degree, rather than a binary decision. In fact, a
system and an SoS lie on a continuum. Table I shows several
key characteristics that are typically associated with an SoS.
The more a system exhibits these characteristics, the more apt
it is to view it as an SoS.
The criteria in Table I can be applied, for example, to
determine whether or not the Curiosity rover (that landed on
Mars in 2012) is an SoS. Curiosity comprises a number of
interoperating subsystems designed to provide basic control,
communications, power, thermal, and scientific services.
However, these subsystems cannot operate in stand-alone
fashion and, consequently, do not have operational independence. Therefore, the Curiosity rover does not qualify as
an SoS.
Emergence is a less well-understood and more complicated concept. An SoS could exhibit new behaviors that were
previously not observed because the conditions that caused
them did not exist previously. In this case, the SoS is doing
Table I.
SoSI: KEY CONSIDERATIONS AND CHALLENGES 331
what it was designed to do but its behavior appears to be
unanticipated because the outcome space was not fully explored. Is this emergence? It is debatable.
We can look beyond engineered systems to explore the
concept of emergence. If a chemical solution exhibits precipitation at some temperature, is that emergence? Does that
depend on whether or not precipitation was anticipated? Once
again, it depends on how one chooses to define emergence.
Emergence within complex adaptive systems (CAS) is easier
to grasp with physical phenomena such as phase changes.
However, biologists do not view this as a CAS phenomenon
(no sensate “ agents” ). It is interesting to note how a phenomenon like phase change which initially appeared almost magical has become part of intent and design now that the
phenomenon is understood. This observation raises further
questions about emergence. Should emergence be redefined
to cover the expected and designed, or should it be redefined
in some other sense? Should emergence be defined along a
continuum (i.e., is it a matter of degree)? These are but a few
questions that need to be answered before emergence can be
defined in a consistent and useful way.
There are other important considerations that come into
play when a system assumes a role within an SoS. For
example, it is likely that some degree of autonomy will be
sacrificed when a system participates within an SoS. Also,
some characteristics can potentially be both time-dependent
and goal-dependent. Thus, at a given time, a system may want
to control certain local resources and not make them available
to the SoS to achieve its overall goal. At some other time, the
system may have completed its local task, and released the
previously tied up resources to the SoS. In this regard, Baldwin et al. [2012] define a game-theoretic approach that is
relevant for analyzing such a collaborative SoS.
The remainder of this paper is organized as follows. Section 2 discusses the unique characteristics of SoS. Section 3
presents an SoS typology in use today. Section 4 discusses
SoS integration from several different perspectives. Section 5
presents an SoSI ontology to inform and guide SoS integra-
Key Characteristics of SoS [Maier, 1998; Sage and Cuppan, 2001]
Systems Engineering DOI 10.1002/sys
Systems Engineering DOI 10.1002/sys
SoSI: KEY CONSIDERATIONS AND CHALLENGES
332 MADNI AND SIEVERS
tion. Section 6 presents an SoS model for a directed SoS used
for Earth seismic studies. Section 7 discusses SoS interoperability for different SoS types from a variety of perspectives.
Section 8 presents human–systems integration challenges in
SoS. Section 9 summarizes the contributions of this paper.
2. UNIQUE CHARACTERISTICS OF SYSTEM OF
SYSTEMS
There are several integration characteristics that apply to both
systems and an acknowledged SoS (Table II). These include:
certification and accreditation (C&A), acquisition, structure,
integration mechanisms, and verification (does the SoS conform to established requirements) and validation (does the
SoS have the desired capabilities). C&A is a major complexity
driver because of the multiple management layers, multiple
3
funding sources, and lack of synchronization in the life cycles
of the various systems within an SoS. Acquisition is a complexity driver due to multiple acquisition programs, multiple
systems’ life cycles across programs, and the need to achieve
interoperability among legacy and new systems. Structure is
a major complexity driver in that the structure of an SoS can
change dynamically as systems continue to enter/exit the SoS.
Integration mechanisms are a major complexity driver in that
they need to support dynamic interoperability among constituent systems. Verification and validation (V&V) is a complexity driver because of the difficulty in synchronizing
across multiple systems’ life cycles, the dynamic entry/exit
requirement for some of the SoS components, and the lack of
a defined set of behaviors or requirements in some SoS.
In general, the boundary between a system and SoS is
fuzzy with respect to these characteristics. However, in gen-
Table II. Comparing an Acknowledged SoS with System
Systems Engineering DOI 10.1002/sys
Systems Engineering DOI 10.1002/sys
4
MADNI AND SIEVERS
eral, an SoS tends to be more complex than a system due to
the added requirements for integration and a different emphasis and approach for design and validation. Creating detailed
requirements and evaluating compliance is possible when the
objectives of an SoS are clear, and the SoS structure is closely
managed. For example, an SoS could provide local situational
awareness from data collected and processed by field-wearable sensors and processors. Additionally, if reconnaissance
aircraft data are available, then information about a neighborhood can be fused with information provided by ground
sensors. Big picture situational awareness is achieved from
integrating ground-based, aircraft-borne, and spacecraft sensors. Such an SoS has well-defined objectives that drive
requirements for sensors, processors, and communications.
These requirements can be flowed down to individual systems, and independently validated by each system engineering team.
In sharp contrast, consider the difficulty in generating
requirements when the objectives and architecture of an SoS
are unknown until stakeholders get together and specify a
needed capability. In this case, requirements refer to communications protocols, information semantics, and usage restrictions. When each system is locally managed and maintained,
assessing compliance even for general requirements may be
left to local oversight with no external guarantees of compliance in terms of consistency and completeness.
There are additional differences between a system and an
SoS beyond those identified in Table II. For example, the
typical role of the human in a system tends to be mostly fixed
with the human in the role of an operator (or an agent) with
predefined interfaces. However, in an SoS, the human can
orchestrate the SoS configuration, and invariably perform as
an agent with changing interfaces to other agents/systems
SoSI: KEY CONSIDERATIONS AND CHALLENGES 333
under the SoS. This dynamic behavior occurs because a
system can enter and exit an SoS based on changing mission
requirements that determine the mission capability package.
Specifically, humans in an SoS can experience ongoing
changes with respect to the agents they collaborate with as
systems enter/exit the SoS. Continuous context switching
associated with ephemeral SoS teams can produce excessive
cognitive load that subsequently tends to show up in the form
of human errors and increased human error rates [Madni,
2010, 2011]. Also, given that some participating systems in
an SoS are temporary collaborators, issues of trust and lack
of shared understanding can arise compromising overall SoS
performance.
3. SoS TYPOLOGY
According to the Systems Engineering Guide for SoS (2008),
an SoS can be classified according to the way it is managed
and its openness to change and new capabilities (Table III).
The form and rigor of SoSI is directly related to SoS type—an
unmanaged SoS is inherently more difficult to integrate than
a tightly managed SoS. Table III offers a coarse SoS classification defined in this guide. The boundaries between these
types can be defined in terms of the degree of operational and
managerial independence of the components.
In principle, each SoS type in Table III is open to any
system that conforms with the interoperability rules of the
SoS. However, an SoS may choose to restrict membership to
only well-known, trusted systems. The Internet is an example
of the former, while a secure banking network is an example
of the latter. In an open, collaborative SoS, new, untrusted
systems may enter and leave with unknowable impact on
Table III. Typology of System(s) of Systems [adapted from OUSD AT&L, 2008]
Systems Engineering DOI 10.1002/sys
Systems Engineering DOI 10.1002/sys
334 MADNI AND SIEVERS
overall SoS integrity. In a closed SoS, the pool of systems are
trusted (to some extent) and may also be required to undergo
periodic inspection and validation to continue to maintain
membership in the SoS.
4. SYSTEM OF SYSTEMS INTEGRATION
A virtual SoS and a collaborative SoS are not prespecified.
This means that there can be no a priori expectation that
information paths and/or information content are consistent
in the SoS. Typically, an SoS is constituted and dynamically
configured in a “ loosely coupled” fashion to achieve the
interoperability needed to create a mission capability package, and then reorganized as necessary to satisfy subsequent
mission needs. In some cases, the systems, behaviors, and
connectivity of an SoS become known only after a mission
capability is specified. In this environment, traditional topdown integration and validation normally associated with
systems integration are not applicable [Madni and Sievers,
2013]. Conversely, a Directed SoS and an Acknowledged SoS
are prespecified making them predictable and compatible
with functional verification and validation methods.
Figure 1 shows a simplified SoSI flow. The systems in this
figure are linked directly or through an intermediary. While
the figure shows only two SoSI configurations, there are
many more possibilities as the “ n” available systems are
organically and dynamically configured to satisfy the needs
of a mission capability package.
Figure 1 implies a well-controlled and rigorous flow. However, for an unmanaged SoS, structure and integration primarily revolve around the needs of the stakeholders, technologies
involved, and legacy constraints [Madni, 2012a]. Moreover,
cost and schedule constraints often conflict with the desire to
thoroughly test a given level of integration before moving to
Figure 1. SoSI showing two possible integration configurations.
The two SoS are configured organically and dynamically for a
particular need, and subsequently reassembled to satisfy other needs.
[Color figure can be viewed in the online issue, which is available
at wileyonlinelibrary.com.]
Systems Engineering DOI 10.1002/sys
SoSI: KEY CONSIDERATIONS AND CHALLENGES
5
the next level. At this point, there are two questions that one
might ask: (1) what does it mean to dynamically integrate a
collection of possibly unknown resources, and (2) what assurance is there that the SoS correctly provides the services
needed by its users? The answer to both questions depends,
in part, on the type of SoS and the interoperability and
connectivity mechanisms used.
Currently, there are no formal or uniformly applied mechanisms to identify and isolate systems that do not comply with
the protocols and rules implicit with membership in an unmanaged SoS. Generally, SoS users stop using a “ misbehaving” system and prevent that system from interoperating with
other systems in the SoS. Various organizations today create
and maintain lists of systems that are untrustworthy or have
been found to host malicious applications (http://www.spamhaus.org).
5. SoS INTEGRATION ONTOLOGY
As described in an earlier paper [Madni and Sievers, 2013],
the definition, management, and evaluation of integration
approaches for systems and SoS are hampered by the lack of
common terminology and clear definitions of technical and
nontechnical interdependencies. To overcome this problem,
we propose an SoS integration ontology shown in Figure 2.
This ontology serves to:
1. Define standard terminology to describe integration
features
2. Define a checklist of salient issues and influences that
impact integration
3. Enable development of integration models that
guide/support reasoning
4. Accommodate all stakeholders’ needs and their respective viewpoints.
It is important to note that ontologies, in general, are not
unique for a particular problem domain and, ultimately, all
ontologies are transformed into useful representations that
help answer questions and assist in reasoning in the problem
space. An instantiated integration model links the properties
shown in Figure 2 to each other and to properties associated
with the behaviors, requirements, architectures, and allocations that are commonly held within a model of the technical
characteristics of the SoS. Figure 2 also includes a “ V&V”
entity that captures pertinent V&V metrics and artifacts.
As shown in Figure 2, several core concepts are involved
in SoSI. These concepts provide the semantic underpinnings
for defining and managing SoSI. Practically speaking, the
SoSI ontology offers a way of unifying the concerns in SoSI.
The characteristics of the SoSI ontology and each concept in
this ontology are described next.
SoSI Ontology. SoSI ontology includes both artifacts
(documentation) and metrics (measurements or tests used to
assess integration success). SoSI concepts are related to the
SoSI domain through relationships (associations) such as:
SoSI hasStakeholders, SoSI hasCA, and SoSI hasIntegrationResources. In an instantiated SoSI model, data property assertions assign values to properties such as “ documentation”
Systems Engineering DOI 10.1002/sys
6
MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES 335
Figure 2. SoS integration ontology. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]
and “ metrics.” For example, a model could assign “ Protocol
Document D” to the documentation property meaning
“ MySoSIntegration hasDocumentation = ProtocolDocumentD,” where MySoSIntegration is an instance of SoS
Integration. Data property assertions are not restricted to
single entities. The assigned values are allowed to be a class
or any element derived from a class. This characteristic enables defining, for example, a class structure for the metrics
property of SoS Integration. If this class is named “ MyMetrics,” then MySoSIntegration hasMetrics = MyMetrics
allows defining multiple metrics, and assigning values to
each.
Object property assertions represent relationships between
instantiations of the compositional elements in Figure 1.
These assertions form the logical network that links elements
of the SoSI model. As an example, a Stakeholder defined as
“ Manager” could have a property assertion, “ hasCostReport,” that is linked to the data property EarnedValue, which
is contained in the concept, C&A. That is, Stakeholder_Manager hasCostReport = EarnedValue in which
EarnedValue refers to an equation that involves data properties, schedule and expenditures, held in Integration Resources.
The network formed by object property assertions can be
expected to grow quite large and complicated. Therefore, as
with any complicated model, it is advantageous to define
viewpoints that capture specific concerns and characteristics
of stakeholders, and that are associated with views that organize the model according to the viewpoint. For example, one
Systems Engineering DOI 10.1002/sys
viewpoint for SoSI might be ScheduleRisk. This viewpoint
captures the concerns associated with issues that could delay
procuring, developing, or maintaining the SoS. This viewpoint is of interest to and could be shared by a number of
stakeholders including the ProjectManager, the SystemScheduler, and the MaintenanceSupervisor. An example of
a view that conforms to this viewpoint might be the availability of physical resources as defined in the instance of the
IntegrationResources model element.
SoS Stakeholders. Stakeholders are individuals, organizations, or external systems with an interest in the SoS, or in
a component system that could potentially become part of or
participate in the SoS. Stakeholder “ concerns” are those
issues that are important to specific stakeholders. Some stakeholders can exert “ influence” on some aspect of SoS integration and can, in turn, be influenced by other aspects. The
concerns and influences of stakeholders define the “ viewpoints” that characterize specific aspects and relationships
(within the model) represented as views that conform with a
particular viewpoint. There are typically a number of viewpoints for a given model that can be associated with one or
more stakeholders. For example, a Project Manager (stakeholder) is typically concerned about schedules, costs, and
risks. Figure 3 shows an instance of a viewpoint for this
stakeholder that has a view defined as Earned Value Analysis.
Earned Value Analysis depends on the expenditures and
schedule values in the Integration Resources element. Other
stakeholders (e.g., the Project Customer), who may also want
Systems Engineering DOI 10.1002/sys
336 MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES
7
Figure 3. Viewpoint and view for two stakeholders: Project Manager and Customer. [Color figure can be viewed in the online issue,
which is available at wileyonlinelibrary.com.]
to view/review an earned value report, can also share the
Earned Value Viewpoint.
SoSI requires defining stakeholders, and then managing
their needs and expectations. These needs and expectations
can often be in conflict. Thus, managing them is as much a
part of SoSI as the process of building and testing the SoS.
All stakeholders are influenced by and can influence one or
more stakeholders. Invariably, stakeholders monitor metrics
associated with system parameters that relate to their concerns. Some stakeholders (e.g., designers, testers) also provide artifacts. The interactions, associations, and semantics
that link stakeholders represent communications pathways,
checks and balances, and testable assertions.
Integration Resources and Influence of External Factors. Because they are closely related, Integration Resources
(or Enablers) and External Factors can be addressed together.
Integration Resources define the “ what,” while “ external
factors” defines influences that affect the “ what.” That is,
Integration Resources are the physical resources (equipment,
facilities, materials, and so on), integration plans, required
interfaces to external entities, and schedule and budget necessary for integration. External Influences contribute to Integration Resources but often may not be under the control of
the SoS integrator. Thus, for example, suppose that an SoS
plans to use a particular protocol defined by an international
standards organization. Although the SoS integrator may
have some influence on the decisions of the international
body, it may not be able to change aspects of the protocol that
are inconvenient or inefficient for the particular mechanisms
planned for the SoS. In this case, an international body
becomes an external influence on the design and integration
of the SoS.
SoS Structure. The structure (or architecture) of an SoS
defines the component systems and their interfaces. The
dynamic nature of an SoS implies that the constituent systems
and interfaces vary based on capabilities needed to satisfy
mission goals. Moreover, certain functions may exist in more
than one constituent system. These systems are incorporated
within the SoS as needed to accommodate, for example, local
maintenance schedules, availability, performance requirements, and interconnection traffic. While the specific components within the SoS structure need not be fixed, the
mechanisms available to link and unlink systems need to
conform to defined rules.
Figure 4 shows an exemplar SoS comprising “ m” systems
interconnected through two communications fabrics. In this
Systems Engineering DOI 10.1002/sys
Figure 4. An example of an SoS comprising two distinct communications fabrics. [Color figure can be viewed in the online issue,
which is available at wileyonlinelibrary.com.]
example, System m and System m + 2 may use either of the
two fabrics. These fabrics do not necessarily have the same
semantic and syntactic interfaces. This fact complicates SoS
integration and validation. The example in Figure 4 also
implies that connecting Systems 1 and n, for example, requires cooperation from System m.
In virtual and collaborative SoS, there is no central authority with the knowledge of available capabilities, and their
ability to be integrated at any point in time. SoS integrators
need an understanding of whether nondeterminism is an issue
for users of the SoS to make informed decisions regarding the
mechanisms used.
NASA’s Deep Space Network (DSN; http://deepspace.jpl.nasa.gov/dsn) is an example of a Directed SoS structure as defined by DoD. It is important to note, however, that
using the criteria in Table I, a directed SoS could not exist,
because once management is centralized, an SoS becomes just
another system. The DSN is an international network of radio
antennas and data relays used to communicate with Earth-orbiting satellites, and interplanetary spacecraft, as well as carry
out radio and radar astronomy observations. There are currently three stations in the DSN located at Goldstone California, Madrid Spain, and Canberra Australia (Fig. 5). Each
station is locally managed and maintained. However, for
certain NASA missions, they come together to provide communication with the spacecraft and to coordinate communication handover as the spacecraft goes out of view of one
station and into the view of another. Station activities are
coordinated by a centralized operations center that coincides
with spacecraft visibility. Data collection and control activities are planned by the centralized operations center and
automatically switched as signal strength declines at one
station and increases at another. Although there are variations
in when the stations assume communication related to Earth
orbit and spacecraft trajectory, there are very well tested
models that can predict what each station does and when.
There are also a fixed set of functions that each station needs
to provide while in contact and while waiting for contact. The
SoS is carefully tested well in advance and simulated tracking
and hand-offs are performed to assure that all resources are
Systems Engineering DOI 10.1002/sys
8
MADNI AND SIEVERS
Figure 5. 70M antenna at the Goldstone Tracking Station
(http://deepspace.jpl.nasa.gov/dsn/gallery/goldstone3.html). [Color
figure can be viewed in the online issue, which is available at
wileyonlinelibrary.com.]
working as expected well before the need arises. While critical missions may use more than one station to assure uninterrupted communication, other missions might have only one
station assigned. Typically, each station serves multiple missions and when not acting as a command and telemetry relay,
can be repurposed for astronomy observation. The SoS is
carefully controlled by a time-based activity schedule that
dictates the configuration and services that a station must
perform in support of flight missions as well as nonmission
time that is scheduled by science teams.
The ARPANET, sponsored by the U.S. Advanced Research Projects Agency, evolved from work done at MIT
Lincoln Labs, UCLA, Stanford, UC Santa Barbara, University of Utah, and Bolt, Beranek and Newman (BBN). The
original ARPANET was a centrally managed, directed SoS
but over time evolved into an unplanned, collaborative SoS—
the Internet. The Internet itself has evolved from a chaotic
collection of disparate resources available only to researchers
and dedicated enthusiasts to one that is somewhat organized
by web services and search engines. In the early days of the
Internet, users knew how to access the resources they needed
and made use of well-documented protocols for making con-
SoSI: KEY CONSIDERATIONS AND CHALLENGES 337
nections and exchanging information. In many cases, users
depended on personal communication with other users to find
resources, learn semantic interfaces, and solve problems. The
modern Internet is supported by application layers, object and
semantic standards, and message transport protocols that hide
many of the connectivity details and also assure communication compliance. From an SoSI perspective, the modern Internet exists by virtue of the protocols developed and stable
intermediate services that provide the links between systems.
Regardless of its management and determinism, a key structural theme for SoSI structures is stable and robust communications. This characteristic implies that SoS architects should
exert as much control as possible over the systems and standards that form the basis of SoSI [Rechtin, 1991].
Certification and Accreditation (C&A). C&A defines
the records, tests, regulations, rules, policies, and other such
considerations that are binding on the SoS [Mayk and Madni,
2006]. For example, a company may write a policy that
defines how components of a system must be grounded. All
products from that company need to adhere to that policy to
ensure that integration does not fail due to grounding-related
incompatibilities.
In an SoS, C&A may take the form of international standards and protocols rather than corporate or government regulations. Compliance failure is not officially policed, but
systems found lacking are kept from participating in the SoS
until they become compliant or are made compliant. A centrally managed SoS may have formal requirements on a
number of local operations, maintenance, testing, and scheduling. The form that C&A takes depends on the particular use
of the SoS and the impact of failure. Table IV presents SoS
examples within diverse sectors along with examples of representative C&A.
Mechanisms. Mechanisms are processes, procedures,
tests, and inspections that are required for integration. They
are generally motivated by safety and verification concerns.
At the most basic level, mechanisms assure that appropriate
safety precautions have been taken (e.g., checks performed
before attaching a cable to a connector). At higher levels,
procedures are put in place to ensure that enabling a given
function for the first time does not adversely affect or cause
the failure of other components, subsystems, or systems. It is
important to note that mechanisms tend to be somewhat
specific to given industries and products. Table V presents
some common SoS integration mechanisms. These mecha-
Table IV. Representative C&A
Systems Engineering DOI 10.1002/sys
Systems Engineering DOI 10.1002/sys
338 MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES
9
Table V. Key SoSI Mechanisms and SoS Categories (Table III)
*Coercive power emerges through agreements among major sites to block traffic and sites observed to misbehave.
nisms are fundamentally applicable to any integration process. It is also worth noting that each mechanism has associated
documentation that gets filed (i.e., persistently stored) in the
development project database. These documents serve as
evidence that certain required processes were in fact performed. As important, they become a source of information
that can be useful for diagnosing anomalous behavior after an
SoS has been deployed.
The banking industry, for example, is governed by a wide
variety of local, federal, and international rules, regulations,
treaties, and laws. There are ISO standards that define currency codes, securities identifiers, Eurobond identifiers, business codes, standard e-business ontology, licensing, and so
forth. The U.S. Office of Comptroller of the Currency publishes a number of regulations and may take enforcement
action when laws, rules, or regulations are violated. There are
also a number of regulations published by the U.S. Consumer
Financial Protection Bureau (CFPB), Federal Reserve Bank
(FRB), Federal Deposit Insurance Corporation (FDIC), and
regulations defined by each country the bank does business
with. Also, banks may have internal policies and procedures
for managing and protecting customer information and assets.
Although banks are integrated as a collaborative SoS,
required C&A imposes tight restrictions on allowable integration mechanisms to ensure the safety and security of the bank
and customers as well as mechanisms that conform to government regulation. The Bank Secrecy Act (BSA) of 1970,
for example, requires financial institutions in the United
States to detect and prevent money laundering. A financial
institution must file five reports for transactions in excess of
$10,000. Given that most transactions are managed electronically, each financial institution must provide a means to
Systems Engineering DOI 10.1002/sys
integrate information potentially from multiple sources and
trigger a warning when any BSA condition occurs.
Risk Management. Risk management activities are an
integral part of SoSI initiatives. Risk management during
SoSI subsumes acceptance testing, deployment, transition
from existing system to new SoS, operations, maintenance,
logistics, training, and upgrades. SoSI needs integration plans
which are derived from development plans, engineering
plans, and test plans. NASA, for example, has issued a Risk
Management Handbook (NASA-SP-2011-3422) that includes the informational flow and roles shown in Figure 6.
Figure 6. NASA risk information flow and functional roles
(NASA/SP-2011-3422, http://www.hq.nasa.gov/office/codeq/doctree/NHBK_2011_3422.pdf). [Color figure can be viewed in the
online issue, which is available at wileyonlinelibrary.com.]
Systems Engineering DOI 10.1002/sys
10
MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES 339
Table VI. Key Elements of Configuration Management
Risk items are typically inserted in a table that places risk
likelihood on one axis and risk consequence on the other. The
intersection of a likelihood and consequence defines the criticality of the risk. A color code is used in the matrix in which
high-likelihood and high-consequence risks are coded red,
intermediate risks are coded yellow, and low risks are coded
green. Risk is assigned an action that indicates what, if anything, should be done to mitigate the risk. Additionally, the
risk trend (increasing, decreasing, no change) is tracked.
The flow in Figure 6 and the risk table are applicable to a
centrally managed SoS such as the DSN in which a Flight
Director for a specific flight mission can articulate a set of
objectives and values that are analyzed and adjudicated. Risk
items are difficult to identify and even more difficult to track
or mitigate in collaborative or virtual SoS. This is the case
because of the dynamic nature of the SoS, the lack of specific
goals, and little or no insight into the systems expected to
participate in carrying out a particular capability. In this latter
environment, one might almost want to assume the worst
case, that is, the likelihood of the risk occurring is high, and
the consequence is that the capability is not available. In
noncritical applications this condition might be acceptable
since the payoff when the capability does work is high. Of
course, if a multi-billion-dollar spacecraft is heading to Mars,
Flight Directors want very high assurance that no “ red” or
“ yellow” risks are outstanding and that all “ green” risks are
under control.
Configuration Management (CM). CM typically comprises processes and documentation that control the performance, capabilities, and composition of the SoS (Table VI). CM
assures that expected behaviors are present in the SoS and that
these behaviors agree with their associated artifacts. Global
CM is possible for an SoS that is centrally managed and, to
some extent, for locally managed component systems. In
general, however, systems within an SoS have no obligation
to publish or maintain their configuration. Consequently, SoS
configuration changes as new systems join, member systems
leave, local maintenance is performed, and systems elect to
temporarily opt out of the SoS entirely, or in part.
SoS Model package contains the elements related to requirements, behaviors, and structures of the SoS.
The SoS comprises a central operations center and a number of remote data collection stations. Nominally, the stations
collect science data as determined by a local scheduling
function. For global studies or when a large earthquake occurs, the operations center forms an SoS with one or more
6. AN SoSI MODEL FOR A DIRECTED SoS
The SoSI ontology (Fig. 2) is used to develop an SoSI model
using SysML notation for a Directed SoS used for Earth
seismic studies. Figure 7 shows a package structure for this
model. The top-level packages are SoSI Model and SoS
Model. The SoSI Model contains the elements associated with
defining and instantiation elements of the SoSI ontology. The
Systems Engineering DOI 10.1002/sys
Figure 7. SoS package structure. [Color figure can be viewed in the
online issue, which is available at wileyonlinelibrary.com.]
Systems Engineering DOI 10.1002/sys
340 MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES
11
Figure 8. Simplified seismic study SoS aggregation diagram. [Color figure can be viewed in the online issue, which is available at
wileyonlinelibrary.com.]
stations so that global patterns can be monitored. Figure 8
shows an aggregation diagram for the SoS. The aggregation
diagram comprises an Operations Center and one or more
Stations. Each Station has a number of basic properties and
any number of specialized parts (data storage, local processing, network connections, sensors, and so forth) as required
for the science observations which are carried out when the
Station is not employed for global seismic studies. The Operations Center provides centralized coordination of the Stations for global science studies and data collection and has its
own suite of subsystems (e.g., data storage, global data fusion,
health and status monitoring).
Figure 8 includes the SoS Integration Domain defined in
Section 5 and a Ground Communications Fabric that provides
global connectivity when needed.
SoSI Stakeholders. Figure 9 shows six hypothetical
stakeholders for the Seismic SoS. These stakeholders are: the
mission manager, the mission planner, the science user, the
station manager, the network support personnel, and the station operator. The roles, concerns, and stakeholder views for
each stakeholder are presented in Table VII.
Figure 10 shows the Mission Operations Viewpoint which
identifies the Mission Manager and Mission Planner as stakeholders. This viewpoint has a corresponding view that depends on properties within an instance of the Integration
Resources element. That instance has data property assertions
for Global Schedule, Local Schedule, Priority List, and State
of Health properties as shown in Figure 10. Figure 10 also
shows that the Mission Operations View “ imports” Mission
Operations Elements (i.e., the members of this package become members of the Mission Operations View namespace).
Using a fully instantiated model, a Mission Manager could
query the model to determine when each station was planning
maintenance and when each had been committed for local
Figure 9. Seismic SoS stakeholders. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]
Systems Engineering DOI 10.1002/sys
Systems Engineering DOI 10.1002/sys
12
MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES 341
Table VII. Seismic SoS Stakeholder Roles, Concerns, and Views
science studies. From this information, the Mission Manager
could populate a Daily Task schedule showing the times when
certain SoS capabilities are available. The Daily Schedule
could then be used by the Mission Planner, who is also a
stakeholder of the Mission Operations Viewpoint. The Mission Planner could access the Priority List and add global
science collection opportunities. Then, the Daily Task schedule can be allocated to each station and accessed by Station
Managers, who have different viewpoints and views that also
depends on the Integration Resources Instance (not shown).
Figure 11 shows a representative schedule structure for a
member of the Mission Operations Element package. It is
seen that three child schedules inherit the properties and
operations of the generalized schedule. One reason for defining this structure is that it aids semantic compatibility across
the SoS thereby facilitating information sharing and analyses.
SoSI Structure and Mechanisms. The DSN is a directed
SoS in which station systems are added and released according to a master schedule held by the Mission Manager. Much
of the contents related to this element are imported from the
SoS Model package shown in Figure 7. Figure 12 shows a
simple instantiation of the SoS structure.
The communications ports C1 to C4 represent physical and
logical interconnections between the operations center, communications fabric, and the stations. Nominally, requirements
are written that define and constrain the C1–C2 and C3–C4
interfaces. Additional requirements are assigned to the communications fabric such that it implements its interface responsibilities. For example, the C3–C4 interface may require
that stations produce outputs in metric units and use a particular data format that specifies the data units and data transmission using TCP/IP. On the other end, the Operations Center
may expect Imperial units. In this case, the communications
fabric would perform the translation between Imperial and
metric units while hiding the details of the translation. We
may know that stations will come and go during the life of
this SoS, and we may also know that we cannot specify the
internal operations of the stations. To protect against semantic
errors, a protocol can be established in which units are explic-
Figure 10. Mission Operations Viewpoint and View. [Color figure
can be viewed in the online issue, which is available at wileyonlinelibrary.com.]
Figure 11. Example schedule structure and inheritance. [Color
figure can be viewed in the online issue, which is available at
wileyonlinelibrary.com.]
Systems Engineering DOI 10.1002/sys
Systems Engineering DOI 10.1002/sys
342 MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES
13
Figure 12. Simplified SoS structure. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]
itly stated. Then, the operations center can make a query that
explicitly states the expected units, and a mechanism within
the communications fabric would perform any needed transformations.
SoSI Resources and External Influences. A number of
influences determine the composition and capabilities of the
Earth Science SoS. For example, stations may be unavailable
due to disruptions and contingencies such as power failures,
earthquakes, and network outages. The state of health, an
attribute of the Integration Resources element, collects current status information on which stations are available. Maintenance and other schedules, which are also contained within
the Integration Resources element, enable scheduling of certain types of data collection for particular studies. For example, a station may be waiting for a replacement part which is
on back-order. In this case, an external influence, that is, the
vendor of the back-ordered part, interferes with integration.
Also, the SoS depends on standards enforced by one or more
organizations. These organizations are external influences on
the SoS.
SoSI Requirements and Interface Definitions. Since the
Earth Science SoS requires communication paths between the
stations and the central Operations Center, we can assume that
there are at least two governing organizations that oversee
connectivity: the International Telecommunications Union
(ITU) and the National Telecommunications and Information
Administration (NTIA). The ITU (http://www.itu.int) publishes a set of handbooks and standards that cover electromagnetic effects protection, implementation guidelines,
semantics, networking, quality of service, and security. NTIA
(http://www.ntia.doc.gov) regulates radio spectrum sharing
and the Internet. In our ontology, these documents are covered
by C&A and Requirements and Interface Definitions.
SoSI Configuration Management. Each station in our
SoS is responsible for maintaining local configuration documentation, and managing its change process. The Operations
Center may request access to that information. However,
whether or not that access is granted is not necessarily under
the control of the Operations Center. In some situations,
although each system is under local control, a single entity
may provide blanket funding for all stations and the Operations Center. In those situations, enforcing documentation
standards and configuration change processes can be influenced by the funding source’s need to make the best use of
funds (an external influence). For our hypothetical SoS, the
Configuration Management Element has a defined set of
configuration plans and a resource database (Fig. 13). The
documents consist of a set of plans for managing the network
and emergency configurations, and for performing upgrades.
The resource database contains the stations and network
components.
SoSI Risk Management. There may be a central authority
(e.g., a blanket funding source) that defines the risk for the
SoS. In this case, that authority can dictate a risk posture and
the types of risk that are acceptable. However, if no such entity
exists, then the risk is affected by how rigorously the individual stations comply with the standards and protocols defined
for the SoS. Where standards or protocols do not exist, there
may be a high likelihood of something not working as anticipated. However, the impact may be sufficiently small for the
risk to be viewed as negligibly low. To some extent, SoS users
influence risk and determine risk mitigation.
In the Earth Science example, the Mission Manager might
define a risk associated with needing certain resources at a
critical point in time. To mitigate that risk, the Mission
Manager could require that each local station publish its
schedule, that stations cannot vary from that schedule without
the Mission Manager’s approval, and that the Mission Manager has the ability to override the schedule if a warning is
given of a certain amount of time remaining. The Mission
Manager could also require a maintenance and testing schedule that assures the operability of each station’s resources.
7. INTEROPERABILITY IS A CROSS-CUTTING
ISSUE
Figure 13. Configuration Management data properties. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]
Systems Engineering DOI 10.1002/sys
Interoperability is the ability of distinct systems to share
semantically compatible information and then process and
manage the information in semantically compatible ways,
enabling users to perform desired tasks [Madni and Sievers,
Systems Engineering DOI 10.1002/sys
14
MADNI AND SIEVERS
2013; Zeigler and Mittal, 2008]. The emphasis on distinct
systems that were not designed to be integrated with each
other is implicit in the concept of interoperability. Interoperability is intended to create a capability that serves an important human purpose and/or satisfies a mission requirement.
Interoperability implies far more than getting systems to
communicate with each other. It requires that the organizations involved employ some degree of compatible semantics
and common interpretations of the information they exchange. The Levels of Conceptual Interoperability Model
(LCIM) is a key advance in this regard [Tolk and Muguira,
2003]. A 2006 NRC Report on Defense Modeling, Simulation
and Analysis lays out a strategy for meeting the interoperability challenge as well.
Interoperability is a cross-cutting concern that is beyond
the scope of a single system development effort, or organization [Naudet et al., 2010]. It is also important to realize that
systems are often designed and implemented before a recognized need for their interoperation exists. Such a need, when
it arises, extends interoperability beyond the original scope of
the system. Even so, there are internal concerns that need to
be addressed by any system, if some day it is called on to
interoperate with others. These include adherence to standards, choice of information processing procedures and algorithms, the validity criteria surrounding the representation and
processing of information, interfaces to other systems and to
their users, and the nonfunctional, quality attributes such as
reliability, availability, security, privacy, and information assurance.
For results to be meaningful and valid, interoperable systems need to share common/compatible semantics. This requirement implies that interoperating systems must have
compatible mechanisms for exchanging, representing, modifying, and updating semantic descriptions of information
items. As important, an interoperable system needs to process
information in ways that are meaningful to the other systems
with which it interoperates. To the extent that the meaning and
form of information is dynamic (i.e., can change over time),
these systems need to be able to dynamically modify their
information processing approaches and, possibly, their representations.
Since interoperability is a cross-system issue, it involves
other cross-cutting concerns (e.g., security) to achieve interoperability solutions. The cross-cutting nature of interoperability has other important consequences. First,
interoperability cannot be implemented piecemeal. Second,
interoperability has a unique and crucial coordination role
relative to the other cross-cutting concerns [Rothenberg,
2008]. Third, interoperability cannot be added as an afterthought without incurring substantial costs and diminished
effectiveness.
In sum, when a system participates within an SoS, it is
necessary to ensure that it understands the data, processing,
and policies of the other systems in the SoS with which it
interoperates, and that they, in turn, understand its data, processing, and policies. This requirement creates a need to explicitly represent and share the subset of system semantics
needed to interoperate with these other systems. This need,
which is rooted in the SoS construct, is rarely acknowledged
or resourced within individual system design efforts, espe-
Systems Engineering DOI 10.1002/sys
SoSI: KEY CONSIDERATIONS AND CHALLENGES 343
cially for preexisting systems that were designed without
interoperability considerations in mind.
SoS Interoperability. It is difficult enough to implement
interoperability when the system is being designed with interoperability in mind. It is even more difficult when this is
not the case. Table VIII presents interoperability cases in
increasing order of difficulty. The first two cases in Table VIII
are demanding but straightforward, since they involve the
design and implementation of a new system that is to be made
interoperable with an intentionally designed SoS. The last
three cases, however, are increasingly problematic, since they
involve various combinations of retrofitting existing systems
and achieving interoperability within ad hoc, non-intentionally designed SoS. Many real-world initiatives exemplify the
last, most challenging case.
For an SoS, interoperability often serves as a surrogate for
integration when independently developed, stand-alone systems are combined to provide a new capability in an SoS. In
many cases, the SoS is not intentionally designed as an SoS.
Rather, it is constituted and dynamically configured as
needed. While an ad hoc SoS of this kind can create useful
new capabilities, it can place significant stress on the component systems which, in general, were not designed to work
with each other. Even for an intentionally designed SoS, it is
challenging to make its component systems interoperate.
Clearly, when an ad hoc SoS is created out of existing standalone systems, the challenge is considerably harder. Even so,
interoperability is easier to achieve in such cases than integration, and in fact can offer some of the same advantages as
integration while providing potentially greater flexibility and
scalability. In all cases, to make systems work together effectively, it is essential to recognize that interoperability is a
cross-cutting concern, which must be implemented pervasively both within and across systems.
Interoperability and Semantics. System interoperability
needs to address both syntactic interoperability and semantic
interoperability. Syntactic interoperability is the ability of two
or more systems to communicate and exchange data. In this
case, specified data formats and communication protocols are
key. Standards such as Extensible Markup Language (XML)
and Structured Query Language (SQL) offer a means to
provide syntactic interoperability. Syntactic interoperability
is a prerequisite to semantic interoperability. Semantic interoperability is the ability of two or more systems to automatically interpret the meaning of exchanged information,
and to accurately produce useful results for end users (of both
systems). For semantic interoperability, any two systems
within an SoS have to agree on a common information exchange reference model that can be used by both. However,
a standard model that has been adopted by an SoS community
to facilitate interoperability among systems in the SoS community is clearly preferable. Regardless, the information exchange request content is unambiguously defined, that is,
what is sent is consistent with what is understood.
Specifically, for humans to collaborate and tools to work
together, it is imperative that the information exchanged is
both correct and meaningful [Mayk and Madni, 2006]. This
requires compatibility among concepts, terms, processes, and
policies. Such compatibility is essential for semantic interoperability. The compatibility requirements for semantic in-
Systems Engineering DOI 10.1002/sys
344 MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES
15
Table VIII. SoS Interoperability Cases
teroperability encompass: terminology and controlled vocabularies; data definitions; units of expressions; computational methods and assumptions used to produce results;
conceptual and functional models; key policies (e.g., access,
authentication, authorization, security, transparency, accountability, privacy); business process models; atomic transactions; interface definitions and procedure invocation; state
and mode definitions and compatibility; and clear definition
of limits and restrictions.
If terminology and data are not aligned, there exists the
likelihood of misinterpretation in exchanged information. If
processes and procedures are incompatible, then it may be
difficult or impossible to combine them to create new, integrated processes that implement new (composite) capabilities. If computational algorithms and information processing
are not semantically compatible, the results are likely to be
meaningless or, worse yet, misleading. If policies (e.g., privacy, access) are misaligned, interactions may be infeasible
or in conflict with specific organizational policies. From the
foregoing, it is evident that semantic interoperability is desirable (and sometimes essential) for meaningful interactions
among systems, applications, and organizations. It is also the
case that semantic interoperability is a substantial, potentially
costly undertaking (as a design goal) because of increased
validation and verification complexity.
Often, organizations or systems may have good business/technical reason to maintain distinct semantics. In such
cases, to assure interoperability such distinctions need to be
made explicit so that mechanisms can be developed that
Systems Engineering DOI 10.1002/sys
automatically map one set of semantics to another. It is worth
noting that the mappings may not be one-to-one and may
include semantics from one set that have no equivalent semantics in the other.
Also, organizations may not wish to expose their internal
semantics to system users (e.g., human users, other organizations). Therefore, to enable system users to understand and
interact with a “ black box” effectively, an organization must
either modify its internal semantics, match external user
semantics, or map internal semantics to external user semantics. However, developing explicit semantics requires articulating the key assumptions and tacit knowledge shared by a
community of practitioners with a common purpose and
mindset. Invariably, these practitioners tend to be unfamiliar
with formal methods for knowledge representation.
Semantic representation includes the Semantic Web 2.0,
and XML-based tools such as Resource Description Framework (RDF) and Web Ontology Language (OWL). However,
current semantic representation tools do not provide mechanisms to support interoperability. Therefore, an SoS should
include a semantic interoperability development process
model to facilitate the development of requisite semantics.
Such process models can enable organizations to explicitly
represent and align their processes with those of other organizations with whom they wish to interoperate.
“Designing In” versus “Retrofitting” Interoperability.
Practically speaking, interoperability is achieved in one of
two ways. It can be designed in (at system inception), or it can
be retrofitted (after the fact). Clearly, designing interoperabil-
Systems Engineering DOI 10.1002/sys
16
MADNI AND SIEVERS
ity into a system is easier, more effective, and less expensive.
Yet the need for interoperability is not always apparent when
a system is designed, leading to the need to achieve interoperability after the fact. While retrofitting interoperability may
be worthwhile, it may come at an enormous cost. The crosscutting nature of interoperability requires it to be infused into
several aspects of a system (e.g. external interfaces, user
interface, use of standards and communication protocols,
internal processing, policies, and procedures for data handling; data access privileges). Modifying these aspects of an
existing system to make it interoperable will typically require
substantial effort. Also, since interoperability depends on
shared semantics, retrofitting interoperability can require major redesign of the system’s representation and algorithms, as
well as realignment of policies. These considerations can
potentially pose serious obstacles.
System Architecture Informs Interoperability Design.
Ultimately, interoperability depends on the architecture of the
SoS [Chen et al., 2008]. This architecture can be explicit or
implicit, formal or ad hoc. When preexisting or independently
designed systems are required to interoperate in the absence
of a common or reference architecture, the linkages between
any two independently designed systems are invariably designed and implemented in ad hoc fashion, producing an ad
hoc integration architecture.
Ad hoc architectures typically lack coherence and scalability. Therefore, it is usually desirable to develop open architectures. However, in practice, the cost and schedule of the initial
development might not seem justifiable to managers and
customers. So, at a minimum, interoperability should be part
of the design trade space and given serious consideration in
defining the system’s life cycle. Ideally, by adopting a reference architecture and explicit architectural framework, and
assuring that each system conforms to the framework, it
becomes possible to achieve significantly greater interoperability among disparate systems. However, often times it is
impractical to enforce such a framework for preexisting systems. In such cases, the result is an ad hoc SoS. In general, the
architecture of an SoS, whether predesigned or ad hoc, can
enhance or inhibit the ability of the component systems of the
SoS to interoperate. In other words, some architectures promote interoperability, while others do not. A Service-Oriented
Architecture (SOA) is an example of an architectural framework that promotes interoperability between its component
services so long as they comply with the SOA paradigm and
its tenets.
Interoperability and Reuse. Reuse is a key motivation
for interoperability. The ability to compose an SoS out of
reusable component systems has the potential to make the
resulting SoS cheaper, more reliable, easier and faster to
develop. It also has the potential to make the resulting SoS
more consistent, easier to maintain and support, and more
flexible and scalable. Reusability and interoperability converge in strategies such as the SOA, in which the behavior and
interfaces of components are formally defined, thereby allowing them to interoperate with each other, and also be reused
as components of multiple systems. A reusable component
must provide a function that is of general value to other
components. In some cases, this can be achieved by offering
a single, well-defined capability that is of general use, such
Systems Engineering DOI 10.1002/sys
SoSI: KEY CONSIDERATIONS AND CHALLENGES 345
as looking up names in a directory or registry. The need to
balance the generality of reusable components against their
ability to be customized (i.e., customizability) is a key challenge. There is no general strategy to ensure that components
will achieve this balance. Therefore, each component must
attempt to find its own “ sweet spot’’ that balances generality
against customizability in ways that depend on its function
and its relationship to other components.
Moreover, as noted above, the services in SOA are typically designed (or at least packaged) as reusable, interoperable components rather than as stand-alone systems in their
own rights. These services are envisioned as components of
a larger system, rather than existing systems that are to be
combined into an SoS. It is, therefore, unclear that the reusability of SOA services translates into reusability of interoperable systems in an SoS. Also, interoperability achieved
through SOA can produce a testing nightmare unless strict
constraints are placed on the interfaces, timing, and functionality. It might also become necessary to stipulate that SOA
services are either stateless or at least have strict limitations
on states and rules for state transition. Also, transactions need
to be atomic to prevent side-effects, if the occurrence of faults
prevents their completion.
Interoperability Pros and Cons. Interoperability offers a
number of advantages including: (a) increased flexibility, by
allowing mixing and matching of systems; (b) creation of new
capabilities, by composing new functions from existing ones;
and (c) increased cost-effectiveness, by allowing reuse of
existing systems and capabilities [Rothenberg, 2008]. The
mixing and matching of systems enables performing unanticipated/unprecedented tasks from new combinations of existing functions. This can be accomplished on-the-fly (for
nonrepetitive tasks), or a priori in a principled manner for
repetitive or recurring tasks. Similarly, interoperability can
reduce the cost of creating new capabilities by allowing
existing systems to be reused in multiple ways for multiple
purposes. An unheralded advantage of interoperability is that
it hides overall system complexity from users by creating the
illusion of an integrated system. Interoperability is usually
accomplished through a common user interface, uniform
semantics, and uniform policies and procedures. However, in
the real world this is not always the case. In some cases,
interoperability is achieved through somewhat “ clumsy”
means. In fact, one might question if such systems can be
claimed to be truly interoperable. One example of clumsy
integration is that employed on the International Space Station. The ISS employs a low-speed 1553 interface between
itself and any experiment bolted on to it. While there is also
a high-speed Ethernet interface for downlink from an experiment, there is no direct uplink path. Thus, if an experiment
needs the high-speed link, crew members have to put the data
on a thumb drive and walk it to another computer that can
perform data uplink over the Ethernet. While one could argue
that this is an interoperable system, it is clearly not automated,
which is typically what is implied by true interoperability.
Despite obvious advantages, interoperability also has
some disadvantages stemming from the increase in technical
complexity and “ open” system design [Rothenberg, 2008].
In particular, issues of privacy and security arise when systems are made interoperable. As important, costs can escalate
Systems Engineering DOI 10.1002/sys
346 MADNI AND SIEVERS
SoSI: KEY CONSIDERATIONS AND CHALLENGES
17
from having to make systems interoperable. Finally, interoperability adds technical complexity to system design in that
new interoperability requirements are now imposed that the
designer has to satisfy. Even so, the benefits of interoperability invariably outweigh the costs.
clusion, we remind the readers that SoSI continues to be a
fertile area of research and development. It is our hope that
this paper will serve as a starting point for systems engineers
who have the responsibility for planning and executing SoSI
initiatives.
8. HUMAN–SYSTEMS INTEGRATION
CHALLENGES IN SoS INTEGRATION
REFERENCES
Humans within an SoS have to continually adapt to changes
in configuration, modes, and levels of autonomy of the SoS
based on changing mission requirements [Madni, 2010].
These behaviors tend to dramatically complicate the lives of
humans and often result in human error. This is not surprising
in that while humans exhibit adaptivity, the adaptation tends
to be slow, not always complete, and occasionally not possible
[Madni, 2010, 2011]. Also, humans tend to be poor at multitasking and context-switching, especially when contextswitching frequency exceeds a maximum threshold. While
several advances have been made in human systems integration [Booher, 2003], existing methods, processes, and tools
are inadequate for integrating humans with adaptable SoS
[Madni, 2010, 2011]. To fill this gap, research is needed to
create new methods, processes, and tools that enable the
development of dynamic HSI strategies for SoS. To this end,
HSI research needs to integrate, build on, and extend the
existing body of knowledge in HSI to address the needs of
adaptable systems. The existing body of knowledge in HSI is
quite fragmented and addresses diverse topics such as information overload, dynamic attention reallocation in multitasking and context-switching situations, distributed decision
making and team coordination stress, ability to back up automation when needed, and cognitive bias in shared human–
machine decision making. Integrating this fragmented body
of knowledge for a variety of use cases is a promising starting
point for realizing the goal of integrating humans with adaptable systems.
9. CONCLUDING REMARKS
Advances in system of systems integration (SoSI) have become critical today as SoS continues to grow in scale and
complexity, and as humans continue to assume a variety of
roles in SoS [Madni, 2010; Brown and Eremenko, 2009;
Hively and Loebl, 2004]. In this paper, we have discussed the
different definitions of SoS, key challenges in SoSI, and an
underlying semantic model for SoS integration. We have
identified external factors as potentially having a significant
impact on SoSI. We have discussed SoSI in terms of requirements and interface definitions, emphasized the importance
of C&A, and presented various forms that C&A can take
based on a variety of factors. We identified the various stakeholders in SoSI along with their concerns, influences, metrics,
and needed resources. We also presented various mechanisms
(i.e., processes, procedures, tests, and inspections) needed for
successful SoSI. We discussed interoperability in terms of
advantages/disadvantages, examples, implications for SoS,
and designing in versus retrofitting interoperability. In con-
Systems Engineering DOI 10.1002/sys
R.L. Ackoff, Toward a system of systems concept, Manage Sci 17
(1971), 661–671.
W.C. Baldwin, T. Ben-Zvi, and B.J. Sauser, Formation of collaborative systems of systems through belonging choice mechanisms,
IEEE Trans Syst Man Cybern Part A 42 (2012), 793–801.
S. Biffl, A. Schatten, and A. Zoitl, Integration of heterogeneous
engineering environments for the automation systems lifecycle,
7th IEEE International Conference on Industrial Informatics
(INDIN 2009), pp. 576–581.
M. Bonjour and G. Falquet, Concept bases: A support to information
systems integration, Lect Notes Comput Sci 811 (1994), 242–
255.
H.R. Booher (Editor), Handbook of human systems integration,
Wiley Online Laboratory, 2003.
O.C. Brown and P. Eremenko, Value-centric design methodologies
for fractionated spacecraft: Progress summary from Phase I of
the DARPA System F6 Program, AIAA SPACE 2009 Conference & Exposition, 14–17 September 2009.
T.R. Browning, Applying the design structure matrix to system
decomposition and integration problems: A review and new
directions, IEEE Trans Eng Manage 48(3) (2001).
G. Cabri, Agent-based plug-and-play integration of role-enabled
medical devices, Joint Workshop on High Confidence Medical
Devices, Software, and Systems and Medical Device Plug-andPlay Interoperability, 2007, HCMDSS-MDPnP, 25–27 June
2007.
D. Chen, G. Doumeingts, and F. Vernadat, Architectures for enterprise integration and interoperability: Past, present and future,
Comput Ind 59 (2008), 647–659.
M.W. Chowdhury and M.Z. Iqbal, Integration of legacy systems in
software architecture, Paper presented at Specification and Verification of Component-Based Systems, 2004.
F.A. Cummins, Enterprise integration: An architecture for enterprise
application and systems engineering, Wiley, New York, 2002.
J.S. Dahmann, G. Rebovich, Jr., and J. Lane, Systems engineering
for capabilities, CrossTalk J Defense Software Eng 21 (2008),
4–9.
Defense Modeling, Simulation and Analysis: Meeting the Challenge, Committee on Modeling and Simulation for Defense
Transformation, National Research Council, Washington, DC,
2006.
L.M. Hively and A.S. Loebl, Horizontal system-of-systems integration via commonality, Oak Ridge National Laboratory, TN, 2004.
M.O. Kahn, M. Sievers, and S. Standley, Model-based verification
and validation of spacecraft avionics, Infotech@Aerospace Conference, 2012.
V. Kotov, Systems of systems as communicating structures, Hewlett
Packard Company, 1997.
A.J. Krygiel, Behind the wizard’s curtain: An integration environment for a system of systems, CCRP, July 1999.
Systems Engineering DOI 10.1002/sys
18
MADNI AND SIEVERS
A.M. Madni, Integrating humans with software and systems: Technical challenges and a research agenda, INCOSE J Syst Eng 13(3)
(2010).
A.M. Madni, Integrating humans with and within software and
systems: Challenges and opportunities (Invited Paper), CrossTalk J Defense Software Eng May/June 2011.
A. Madni, Adaptable platform-based engineering: Key enablers and
outlook for the future, INCOSE J Syst Eng 15(2012a), 95–107.
A.M. Madni, Elegant systems design: Creative fusion of simplicity
and power, INCOSE J Syst Eng 15 (2012b), 347–354.
A.M. Madni and S. Jackson, Towards a conceptual framework for
resilience engineering, IEEE Syst J 3(2) (2009).
A.M. Madni and A. Moini, Viewing enterprises as systems-of-systems (SoS): Implications for SoS research, J Integrated Design
Process Sci 11(2) (2007), 3–14.
A.M. Madni and M. Sievers, Systems integration: Key perspectives,
experiences, and challenges, INCOSE J Syst Eng 16(4) 2013.
M.W. Maier, Architecting principles for systems-of-systems, Syst
Eng 1(4) (1998), 267–284.
M.W. Maier and E. Rechtin, The art of systems architecting, 3rd
edition, CRC Press, Boca Raton, FL, 2009.
W.H.J. Manthorpe, Jr., The emerging joint system of systems: A
systems engineering challenge and opportunity for APL, Johns
Hopkins APL Tech Dig 17 (1996), 305–313.
I. Mayk and A.M. Madni, The role of ontology in system-of-systems
acquisition, Proceedings of the 2006 Command and Control
Research and Technology Symposium, San Diego, CA, June
20–22, 2006.
P.J. Mosterman, J. Ghidella, and J. Friedman, Model-based design
for system integration, Second CDEN International Conference
on Design Education, Innovation, and Practice, Alberta, Canada,
2005.
NASA system engineering handbook, DIANE Publishing, 2010.
SoSI: KEY CONSIDERATIONS AND CHALLENGES 347
Y. Naudet, T. Latour, W. Guedria, and D. Chen, Toward a systemic
formalization of interoperability, Comput Ind 61 (2010), 176–
185.
R. Neches and A.M. Madni, Towards affordably adaptable and
effective systems, INCOSE J Syst Eng 16 (2013), 224–234.
E.G. Nilsson, E.K. Nordhagen, and G. Oftedal, Aspects of systems
integration, Proceedings of the First International Conference on
Systems Integration, 1990, pp. 434–443.
Office of the Undersecretary of Defense for Acquisition, Technology, and Logistics (OUSD AT&L), Systems engineering guide
for systems of systems, Washington, DC, August 2008.
E. Rechtin, System architecting: Creating and building complex
systems, Prentice–Hall, Englewood Cliffs, NJ, 1991.
D. Rehage, U.B. Caol, M. Merkel, and A. Vahl, The effects on
reliability of aircraft systems based on integrated modular avionics, Lect Notes Comput Sci 3219 (2004), 224–238.
J. Rothenberg, Interoperability as a cross-cutting concern, RAND
Corporation, 2008.
A.P. Sage and C.D. Cuppan, On the systems engineering and management of systems of systems and federations of systems, Inf
Knowl Syst Manage 2 (2001), 325–345.
C.E. Siemieniuch and M.A. Sinclair, Systems integration, Appl
Ergon 37 (2006), 91–110.
V. Stavridou, Integration in software intensive systems, J Syst Software 48 (1999), 91–104.
A. Tolk and J.A. Muguira, The levels of conceptual interoperability
model, Predings of the Fall 2003 Simulation Interoperability
Workshop, Orlando, FL, 2003.
M. Vuletid, L. Pozzi, and P. Ienne, Seamless hardware-software
integration in reconfigurable computing systems, Des Test Comput 22(2) (2005), 102–113.
B.P. Zeigler and S. Mittal, Towards a formal standard for interoperability in M&S/system of systems integration, Symposium on
Critical Issues in C4I, 2008.
Azad Madni is a Professor in the Daniel J. Epstein Department of Industrial and Systems Engineering, and the Director
of the multidisciplinary Systems Architecting and Engineering (SAE) Program in the University of Southern California’s Viterbi School of Engineering. He holds joint appointments in USC’s Keck School of Medicine and Rossier School
of Education. He is the founder, Chairman, and Chief Scientist of Intelligent Systems Technology, Inc. He received his
B.S., M.S., and Ph.D. degrees from the University of California, Los Angeles. His research has been sponsored by
several major government research agencies including OSD, DARPA, DHS S&T, MDA, DTRA, ONR, AFOSR, AFRL,
ARI, RDECOM, NIST, DOE, and NASA. He is the recipient of the 2011 Pioneer Award from the International Council
of Systems Engineering. In 2012, he received INCOSE-LA’s Exceptional Achievement Award for transformative
advances in systems engineering. He is also the recipient of SBA’s 1999 National Tibbetts Award for California, the
2000 Blue Chip Entrepreneurship Award from MassMutual and the U.S. Chamber of Commerce, the 2008 President’s
Award, and the 2006 C.V. Ramamoorthy Distinguished Scholar Award from the Society of Design and Process Science.
He is also the recipient of the Developer of the Year Award from the Technology Council of Southern California in
2000 and 2004. He is a Fellow of AAAS, AIAA, INCOSE, and SDPS, and a Life Fellow of IEEE and IETE. He is
listed in the major Who’s Who including Marquis Who’s Who in Science and Engineering, Who’s Who in Industry
and Finance, and Who’s Who in America.
Michael Sievers is a Senior Systems Engineer at Caltech’s Jet Propulsion Laboratory and a Visiting Lecturer in System
Engineering at the University of Southern California. He conducts research in model-based systems engineering as
well as contributing to a number of JPL’s flight missions. He holds a Ph.D. degree in Computer Science from the
University of California, Los Angeles, and is a member of INCOSE and a Senior Member of IEEE and AIAA.
Systems Engineering DOI 10.1002/sys
Systems Engineering DOI 10.1002/sys