Systems of Systems

(SoS)
System of Systems and Complexity > Systems of Systems Engineering –
Innovations for the 21st Century > Systems of Systems (SoS)

The printable version is no longer supported and may

have rendering errors. Please update your browser
bookmarks and please use the default browser print
function instead.

Lead Authors: Mike Henshaw, Judith Dahmann, Bud

Lawson

System of systems engineering (SoSE) is not a new

discipline; however, this is an opportunity for the
systems engineering community to define the complex
systems of the twenty-first century (Jamshidi 2009).
While systems engineering is a fairly established field,
SoSE represents a challenge for the present systems
engineers on a global level. In general, SoSE requires
considerations beyond those usually associated with
engineering to include socio-technical and sometimes
socio-economic phenomena.

Contents
Topics
Characteristics and Definitionof Systems of Systems
Types of SoS
SoSE Application Domains
Difference between System of Systems Engineering and
Systems Engineering
SoSE Standards
References
Works Cited
Primary References
Additional References
Relevant Videos
Topics
Each part of the SEBoK is divided into knowledge areas
(KAs), which are groupings of information with a related
theme. The KAs in turn are divided into topics. This KA
contains the following topics:

Architecting Approaches for Systems of Systems

Socio-Technical Features of Systems of Systems
Capability Engineering

Characteristics and Definitionof

Systems of Systems
Maier (1998) postulated five key characteristics (not
criteria) of SoS: operational independence of component
systems, managerial independence of component
systems, geographical distribution, emergent behavior,
and evolutionary development processes, and identified
operational independence and managerial independence
as the two principal distinguishing characteristics for
applying the term 'systems-of-systems.' A system that
does not exhibit these two characteristics is not
considered a system-of-systems regardless of the
complexity or geographic distribution of its components.

In the Maier characterization, emergence is noted as a

common characteristic of SoS particularly in SoS
composed of multiple large existing systems, based on
the challenge (in time and resources) of subjecting all
possible logical threads across the myriad functions,
capabilities, and data of the systems in an SoS. As
introduced in the article Emergence, there are risks
associated with unexpected or unintended behavior
resulting from combining systems that have individually
complex behavior. These become serious in cases which
safety, for example, is threatened through unintended
interactions among the functions provided by multiple
constituent systems in a SoS.

ISO/IEC/IEEE 21839 (ISO, 2019) provides a definition of

SoS and constituent system:

System of Systems (SoS) — Set of

systems or system elements that interact
to provide a unique capability that none of
the constituent systems can accomplish on
its own. Note: Systems elements can be
necessary to facilitate the interaction of
 the constituent systems in the system of
systems

Constituent Systems — Constituent

systems can be part of one or more SoS.
Note: Each constituent is a useful system
by itself, having its own development,
management goals and resources, but
interacts within the SoS to provide the
unique capability of the SoS.

In addition, there are several definitions of system(s) of

systems (SoS), some of which are dependent on the
particularity of an application area (Jamshidi, 2005).

It should be noted that formation of a SoS is not

necessarily a permanent phenomenon, but rather a
matter of necessity for integrating and networking
systems in a coordinated way for specific goals such as
robustness, cost, efficiency, etc.

The US DoD (2008) defines Systems of Systems

Engineering as “planning, analyzing, organizing, and
integrating the capabilities of a mix of existing and new
systems into an SoS capability greater than the sum of
the capabilities of the constituent parts”.

ISO/IEC/IEEE 15288 Annex G (2015) also describes the

impact of these characteristics on the implementation of
systems engineering processes. Because of the
independence of the constituent systems, these
processes are in most cases implemented for
engineering both the systems and the system of systems
and need to be tailored to support the characteristics of
SoS. These processes are shown in the table below
highlighting the fact that these processes are
implemented at both the system and SoS levels, with
SoSE often constrained by the systems.

Table 1. Differences Between Systems and Systems of

Systems as They Apply to Systems Engineering.
SE Process Implementation as Applied to SoS
Because there is often no top level SoS
Agreement authority, effective agreements among
processes the systems in the SoS are key to
successful SoSE.
SoSE develops and maintains those
Organizational
processes which are critical for the SoS
project enabling
within the constraints of the system level
processes
processes.
 SoSE implements technical management
processes applied to the particular
considerations of SoS engineering -
Technical planning, analyzing, organizing, and
management integrating the capabilities of a mix of
processes existing and new systems into a system-
of-systems capability while systems
continue to be responsible for technical
management of their systems.
SoSE technical processes define the
cross-cutting SoS capability, through SoS
level business/mission analysis and
stakeholder needs and requirements
definition. SoS architecture and design
frame the planning, organization and
integration of the constituent systems,
Technical constrained by system architectures.
processes Development, integration, verification,
transition and validation are implemented
by the systems. with SoSE monitoring and
review. SoSE integration, verification,
transition and validation applies when
constituent systems are integrated into
the SoS and performance is verified and
validated.

Finally, based on work done by the INCOSE Systems of

Systems Work Group (Dahmann, 2014), the major
challenges facing SoSE have been catalogued in terms of
seven pain points. These challenges are presented in the
SoSE section of the INCOSE SE Handbook. (INCOSE
2015). These challenges include:

SoS Authorities. In a SoS each constituent system

has its own local ‘owner’ with its stakeholders, users,
business processes and development approach. As a
result, the type of organizational structure assumed
for most traditional systems engineering under a
single authority responsible for the entire system is
absent from most SoS. In a SoS, SE relies on cross-
cutting analysis and on composition and integration of
constituent systems which, in turn, depend on an
agreed common purpose and motivation for these
systems to work together towards collective
objectives which may or may not coincide with those
of the individual constituent systems.
Leadership. Recognizing that the lack of common
authorities and funding pose challenges for SoS, a
related issue is the challenge of leadership in the
multiple organizational environment of a SoS. This
question of leadership is experienced where a lack of
structured control normally present in SE of systems
requires alternatives to provide coherence and
direction, such as influence and incentives.
Constituent Systems’ Perspectives. Systems of
systems are typically comprised, at least in part, of in-
service systems, which were often developed for other
purposes and are now being leveraged to meet a new
or different application with new objectives. This is
the basis for a major issue facing SoS SE; that is, how
to technically address issues which arise from the fact
that the systems identified for the SoS may be limited
in the degree to which they can support the SoS.
These limitations may affect the initial efforts at
incorporating a system into a SoS, and systems
‘commitments to other users may mean that they
may not be compatible with the SoS over time.
Further, because the systems were developed and
operate in different situations, there is a risk that
there could be a mismatch in understanding the
services or data provided by one system to the SoS if
the particular system’s context differs from that of the
SoS.
Capabilities and Requirements. Traditionally (and
ideally) the SE process begins with a clear, complete
set of user requirements and provides a disciplined
approach to develop a system to meet these
requirements. Typically, SoS are comprised of multiple
independent systems with their own requirements,
working towards broader capability objectives. In the
best case the SoS capability needs are met by the
constituent systems as they meet their own local
requirements. However, in many cases the SoS needs
may not be consistent with the requirements for the
constituent systems. In these cases, the SoS SE
needs to identify alternative approaches to meeting
those needs through changes to the constituent
systems or additions of other systems to the SoS. In
effect this is asking the systems to take on new
requirements with the SoS acting as the ‘user’.
Autonomy, Interdependencies and Emergence.
The independence of constituent systems in a SoS is
the source of a number of technical issues facing SE of
SoS. The fact that a constituent system may continue
to change independently of the SoS, along with
interdependencies between that constituent system
and other constituent systems, add to the complexity
of the SoS and further challenges SE at the SoS level.
In particular, these dynamics can lead to
unanticipated effects at the SoS level leading to
unexpected or unpredictable behavior in a SoS even if
the behavior of constituent systems is well
understood.
Testing, Validation, and Learning. The fact that
SoS are typically composed of constituent systems
which are independent of the SoS poses challenges in
conducting end-to-end SoS testing as is typically done
with systems. Firstly, unless there is a clear
understanding of the SoS-level expectations and
measures of these expectations, it can be very
difficult to assess level of performance as the basis for
determining areas which need attention, or to assure
users of the capabilities and limitations of the SoS.
Even when there is a clear understanding of SoS
objectives and metrics, testing in a traditional sense
can be difficult. Depending on the SoS context, there
may not be funding or authority for SoS testing. Often
the development cycles of the constituent systems
are tied to the needs of their owners and original
ongoing user base. With multiple constituent systems
subject to asynchronous development cycles, finding
ways to conduct traditional end-to-end testing across
the SoS can be difficult if not impossible. In addition,
many SoS are large and diverse making traditional full
end-to-end testing with every change in a constituent
system prohibitively costly. Often the only way to get
a good measure of SoS performance is from data
collected from actual operations or through estimates
based on modeling, simulation and analysis.
Nonetheless the SoS SE team needs to enable
continuity of operation and performance of the SoS
despite these challenges.
SoS Principles. SoS is a relatively new area, with
the result that there has been limited attention given
to ways to extend systems thinking to the issues
particular to SoS. Work is needed to identify and
articulate the cross cutting principles that apply to
SoS in general, and to developing working examples
of the application of these principles. There is a major
learning curve for the average systems engineer
moving to a SoS environment, and a problem with SoS
knowledge transfer within or across organizations.
Types of SoS
In today’s interconnected world, SoS occur in a broad
range of circumstances. In those situations where the
SoS is recognized and treated as a system in its right, an
SoS can be described as one of four types (Maier, 1998;
Dahmann and Baldwin, 2008, ISO 21839, 2019):

Directed - The SoS is created and managed to fulfill

specific purposes and the constituent systems are
subordinated to the SoS. The component systems
maintain an ability to operate independently;
however, their normal operational mode is
subordinated to the central managed purpose;
Acknowledged - The SoS has recognized objectives,
a designated manager, and resources for the SoS;
however, the constituent systems retain their
independent ownership, objectives, funding, and
development and sustainment approaches. Changes
in the systems are based on cooperative agreements
between the SoS and the system;
Collaborative - The component systems interact
more or less voluntarily to fulfill agreed upon central
purposes. The central players collectively decide how
to provide or deny service, thereby providing some
means of enforcing and maintaining standards; and
Virtual - The SoS lacks a central management
authority and a centrally agreed upon purpose for the
SoS. Large-scale behavior emerges—and may be
desirable—but this type of SoS must rely on relatively
invisible mechanisms to maintain it.

This taxonomy is based on the degree of independence

of constituents and it offers a framework for
understanding SoS based on the origin of the SoS
objectives and the relationships among the stakeholders
for both the SoS and its constituent systems. In most
actual cases, an SoS will reflect a combination of SoS
types which may change over time. This taxonomy is in
general use. It is presented in 15288 Annex G and in ISO
21841, "Taxonomy of Systems of systems". Other
taxonomies may focus on nature/type of components,
their heterogeneity, etc. (Cook, 2014)

As noted above, many SoS exist in an unrecognized

state; this is increasingly true as the levels of
interconnectivity between modern systems keeps
increasing. Kemp et al (2013) describe such systems as
“accidental” but they can be described as “discovered”
(Dahmann and Henshaw, 2016) because it is only when
they become significant for some reason that we
recognize them, at which point they can usually fall into
one of the above four categories, since their significance
means they must now operate, with management, in
some defined way.

From the SoSE point of view, another potential

classification would consider the level of
anticipation/preparation of SoSE with respect to SoS
operations and level of stability of the SoS objectives;
this is referred to as variability by Kinder et. al. (2012).
This could range from an SoS which responds to a
particular trigger and is put immediately in place when
needs are expressed. An example of such an SoS would
be a crisis management SoS. This type of SoS is updated
dynamically during the operation. At the other end of
the spectrum there are well-specified and stable SoS
developed to answer to specified ongoing needs. An
example of such a persistent SoS is an air traffic
management system. This type of SoS is acquired and
qualified in a well-defined environment and any need for
evolution will imply a formal SE evolution and re-
qualification.

While much of the early attention to SoS has focused on

Acknowledged SoS where current SE practices can be
adapted and applied, there is an increasing recognition
that the predominance of SoS exist in the collaborative
and virtual types (Honour 2016), and in those areas
where SoS may not be officially recognized but affect
many of the broader capabilities in today’s
interconnected world. In these cases, the focus is
shifting to understanding SoS as socio-technical,
complex adaptive systems rather than extensions of
current technical systems with a focus on understand
and addressing the inherent complexity of these types of
SoS.

SoSE Application Domains

Application of SoSE is broad and is expanding into
almost all walks of life. Originally identified in the
defense environment, SoSE application is now much
broader and still expanding. The early work in the
defense sector has provided the initial basis for SoSE,
including its intellectual foundation, technical
approaches, and practical experience. In addition,
parallel developments in information services and rail
have helped to develop SoSE practice (Kemp and Daw,
2015). Now, SoSE concepts and principles apply across
other governmental, civil and commercial domains.

Some examples include:

Transportation - air traffic management, the

European rail network, integrated ground
transportation, cargo transport, highway
management, and space systems,
Energy - smart grid, smart houses, and integrated
production/consumption,
Health Care - regional facilities management,
emergency services, and personal health
management,
Defense - Military missions such as missile defense,
networked sensors,
Rail – Urban, national, international rail systems,
Natural Resource Management - global
environment, regional water resources, forestry, and
recreational resources,
Disaster Response - responses to disaster events
including forest fires, floods, and terrorist attacks,
Consumer Products - integrated entertainment and
household product integration,
Business- banking and finance,and
Media - film, radio, and television.

Increased networking and interconnectedness of

systems today contributes to growth in the number and
domains where SoS are becoming the norm, particularly
with the considerable converge among systems of
systems, cyber-physical systems and the internet of
things. (Henshaw, 2016).

Difference between System of

Systems Engineering and Systems
Engineering
Observations regarding differences between individual
or constituent systems and SoS are listed in Table 1.
These differences are not as black and white as the table
might suggest and in each case, the degree of difference
varies in practice. Modern systems tend to be highly
inter-connected, so that the assumptions that lead to the
characteristics of Systems Engineering in Table 2 are
less frequently met.
 Table 2. Differences Between Systems
and Systems of Systems as They Apply
to Systems Engineering. (INCOSE,
2018)

Systems tend to ... Systems of systems tend to ...

Have multiple levels of
Have a clear set of
stakeholders with mixed and
stakeholders
possibly competing interests
Have multiple, and possibly
Have clear objectives
contradictory, objectives and
and purpose
purpose
Have clear operational Have multiple, and sometimes
priorities, with escalation different, operational priorities with
to resolve priorities no clear escalation routes
Have multiple lifecycles with
Have a single lifecycle elements being implemented
asynchronously
Have clear ownership
with the ability to move Have multiple owners making
resources between independent resourcing decisions
elements

It is the characteristics of management and operational

independence (Maier,1998) that most fundamentally
distinguishes the behavior of SoS from unitary systems:
this has been explained by Rebovich (2009) as the
fundamental problem for SoS :

From the single-system community’s perspective, its part

of the SoS capability represents additional obligations,
constraints and complexities. Rarely is participation in
an SoS seen as a net gain from the viewpoint of single-
system stakeholders [Rebovich, 2009].

SoSE Standards
The first standards for system of systems engineering
have been adopted by the International Standards
organization. These were initiated in 2016 response to
the report of an ISO SoS Standards study group (ISO,
2016) recognizing the increased attention to SoS and the
value to standards to the maturation of SoSE. Three
standards were adopted in 2019 (INCOSE 2020):

ISO/IEC/IEEE 21839 – System of Systems (SoS)

Considerations in Life Cycle Stages of a System

This standard provides a set of critical considerations to

be addressed at key points in the life cycle of systems
created by humans and refers to a constituent system
that will interact in a system of systems as the system of
interest (SOI). These considerations are aligned with
ISO/IEC/IEEE 15288 and the ISO/IEC/IEEE 24748
framework for system life cycle stages and associated
terminology.

ISO/IEC/IEEE 21840 – Guidelines for the

utilization of ISO/IEC/IEEE 15288 in the context
of System of Systems (SoS) Engineering

This standard provides guidance for the utilization of

ISO/IEC/IEEE 15288 in the context of SoS. While
ISO/IEC/IEEE 15288 applies to systems (including
constituent systems), this document provides guidance
on application of these processes to SoS. However,
ISO/IEC/IEEE 21840 is not a self-contained SoS
replacement for ISO/IEC/IEEE 15288. This document is
intended to be used in conjunction with ISO/IEC/IEEE
15288, ISO/IEC/IEEE 21839 and ISO/IEC/IEEE 21841
and is not intended to be used without them.

ISO/IEC/IEEE 21841 – Taxonomy of Systems of

Systems

The purpose of this standard is to define normalized

taxonomies for systems of systems (SoS) to facilitate
communications among stakeholders. It also briefly
explains what a taxonomy is and how it applies to the
SoS to aid in understanding and communication.

References

Works Cited

Cook, S. C. and Pratt, J. M., “Towards designing

innovative SoSE approaches for the Australian defence
force,” Proc. 9th Int. Conf. Syst. Syst. Eng. Socio-
Technical Perspect. SoSE 2014, pp. 295–300, 2014.

Dahmann, J, and M.J.D Henshaw. 2016. “Introduction to

Systems of Systems Engineering”, INCOSE INSIGHT,
October 2016, Volume 19, Issue 3, pages 12-16.

Dahmann, Judith. 2015. Systems of Systems Pain Points,

INCOSE International Symposium, Seattle, WA.

Dahmann, J., and K. Baldwin. 2008. "Understanding the

Current State of US Defense Systems of Systems and the
Implications for Systems Engineering." Presented at
IEEE Systems Conference, April 7-10, 2008, Montreal,
Canada.

DoD. 2008. Systems Engineering Guide for Systems of

Systems. Arlington, VA: US Department of Defense,
Director, Systems and Software Engineering, Deputy
Under Secretary of Defense (Acquisition and
Technology), Office of the Under Secretary of Defense
(Acquisition, Technology and Logistics). Accessed 2
/26/2022. Available:
https://acqnotes.com/wp-content/uploads/2014/09/DoD-S
ystems-Engineering-Guide-for-Systems-of-Systems-
Aug-2008.pdf

Henshaw, M.J.d,, “Systems of Systems. Cyber-Physical

Systems, the Internet of Things… Whatever Next?”
INCOSE INSIGHT, October 2016, Volume 19, Issue 3,
pages 51-54.

Honour, E.., "Engineering the Virtual or Collaborative

SoS", INCOSE INSIGHT, October 2016, Volume 19,
Issue 3, pages 67-69.

INCOSE, 2020. Systems of Systems Standards Quick

reference Guide, INCOSE -2020 -sosstandards.

INCOSE, 2018. Systems of Systems Primer, INCOSE-

TP-2018-003-01.0.

INCOSE SE Handbook. 2015

International Organization for Standardization (ISO).

2019. ISO/IEC/IEEE 21839 —Systems and Software
Engineering—System of systems considerations in life
cycle stages of a system.

International Organization for Standardization (ISO).

2019. ISO/IEC/IEEE 21840 —Guidelines for the
utilization of ISO/IEC/IEEE 15288 in the context of
system of systems.

International Organization for Standardization (ISO).

2019. ISO/IEC/IEEE 21481 —Systems and Software
Engineering—Taxonomy of systems of systems.

International Standards Organization, 2016. Report of

the SC7 SG on Systems of Systems Engineering.

International Organization for Standardization (ISO).

2015. ISO/IEC/IEEE 15288—Systems and Software
Engineering—System life cycle processes.

Jamshidi, M. (ed). 2009a. Systems of Systems

Engineering – Innovations for the 21st Century.
Hoboken, NJ, USA: Wiley.

Jamshidi, Mo. (2005). System-of-Systems Engineering-a

Definition.

Kemp, D., et. al.. 2013. Steampunk System of Systems

Engineering: A case study of successful System of
Systems engineering in 19th century Britain." Presented
at INCOSE International Symposium, June 24–27, 2013,
Philadelphia, PA.

Kinder, A., Barot, V., Henshaw, M., & Siemieniuch, C.

(2012). System of Systems: “Defining the system of
interest.” In Proc. 7th Int. Conf. Systems of Systems
Eng., Genoa, italy (pp. 463–468). Retrieved from
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=638
4211

Maier, M.W. 1998. "Architecting Principles for Systems-

of-Systems." Systems Engineering. 1 (4): 267-284.

Rebovich Jr., G. 2009. "Chapter 6: Enterprise System of

Systems," in Systems of Systems Engineering -
Principles and Applications. Boca Raton, FL, USA: CRC
Press.

Primary References

Dahmann, J., and K. Baldwin. 2008. "Understanding the

Current State of US Defense Systems of Systems and the
Implications for Systems Engineering." Presented at
IEEE Systems Conference, April 7-10, 2008, Montreal,
Canada.

DoD. 2008. Systems Engineering Guide for Systems of

Systems, version 1.0. Washington, DC, USA: US
Department of Defense (DoD). Available:
http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf.

INCOSE Systems Engineering Handbook, 4th Edition,

John Wiley & Sons Inc., 2015

International Standards Organization, 2016. Report of

the SC7 SG on Systems of Systems Engineering.

Jamshidi, M. (ed). 2009a. Systems of Systems

Engineering – Innovations for the 21st Century.
Hoboken, NJ, USA: Wiley.

Maier, M.W. 1998. "Architecting Principles for Systems-

of-Systems." Systems Engineering. 1 (4): 267-284.
Additional References

Barot, V., S. Henson, M. Henshaw, C. Siemieniuch, M.

Sinclair, S.L. Lim, M. Jamshidi, and D. DeLaurentis.
2012. Trans-Atlantic Research and Education Agenda in
Systems of Systems (T-AREA-SoS) SOA Report.
Longborough, England, UK: Longborough University.
Ref. TAREA-RE-WP2-R-LU-7.

Boardman, J., and B. Sauser. 2006. "System of Systems -

the Meaning of Of." IEEE Conference on Systems of
Systems Engineering, April 24-26, 2006, Los Angeles,
CA.

Carlock, P., and J.A. Lane. 2006. System of Systems

Enterprise Systems Engineering, the Enterprise
Architecture Management Framework, and System of
Systems Cost Estimation. Los Angeles, CA, USA: Center
for Systems and Software Engineering (CSSE),
University of Southern California (USC). USC-
CSE-2006-618.

Checkland, P.B. 1999. Systems Thinking, Systems

Practice. Chichester, UK: John Wiley & Sons Ltd.

Dahmann, J., Rebovich, G., Lane, J., Lowry, R. &

Baldwin, K. 2011. "An Implementer's View of Systems
Engineering for Systems of Systems." IEEE Systems
Conference, April 4-7, 2011, Montreal, Canada. p.
212-217.

Keating C.B., J.J. Padilla, and K. Adams. 2008. "System of

systems engineering requirements: Challenges and
guidelines". EMJ - Engineering Management Journal. 20
(4): 24-31.

Luzeaux, D., and J.R. Ruault. 2010. Systems of Systems.

London, UK: ISTE.

MITRE. "System of Systems Engineering Collaborators

Information Exchange (SoSECIE) Webinar Archive,"
MITRE, 2019. Available: [1]

Neaga, E.I., M.J.d. Henshaw, and Y. Yue. 2009. "The

influence of the concept of capability-based management
on the development of the systems engineering
discipline." Proceedings of the 7th Annual Conference on
Systems Engineering Research, April 20-23, 2009,
Loughborough University, Loughborough, England, UK.

Poza, A.S., S. Kovacic, and C. Keating. 2008. "System of

Systems Engineering: An Emerging Multidiscipline".
International Journal of System of Systems Engineering.
1 (1/2).

Ring J. 2002. "Toward an ontology of systems

engineering." INSIGHT. 5 (1): 19-22.

Relevant Videos
Systems of Systems (Somerville)
System of Systems

< Previous Article | Parent Article | Next Article >

SEBoK v. 2.7, released 31 October 2022

Retrieved from
"https://sebokwiki.org/w/index.php?title=Systems_of_Systems_(SoS)
&oldid=66495"

This page was last edited on 10 October 2022, at 08:33.