®

INCOSE Systems of Systems Primer

INCOSE-TP-2018-003-01.0
Introducing How do I know if I’m in an SoS?
One widely-used definition proposed by Mark Maier
Systems of Systems in 1998 defines an SoS as follows:
A System of Systems (SoS) is a collection of • The constituent parts are operationally and
independent systems, integrated into a larger system managerially independent (i.e., they can make
that delivers unique capabilities. The independent decisions about their future and are capable of
constituent systems collaborate to produce global leaving the SoS if they wish)
behavior that they cannot produce alone. This type of • The systems in the SoS are distributed
collaboration is powerful, but brings major challenges
for systems engineering: • The SoS evolves continually over time
• Because they are independent, constituent • The SoS exhibits emergent behaviour.
systems may make decisions or upgrades without “Emergent behaviour” is the global behaviour
considering the rest of the SoS. Sometimes this produced by interactions of the constituents
unintentionally forces others to make changes too which cannot be reproduced by constituents
acting alone.
• Constituent systems may withdraw (possibly
without warning) from the SoS if their own goals
conflict with SoS goals Example SoS: emergency response
• Separate constituent systems are often drawn An emergency response service responds to life-
from different engineering disciplines, and the threatening situations. The optimal response to a
SoS itself is commonly large-scale and usually situation may require any combination of fire crews,
highly complex. It’s difficult to produce accurate ambulances, police, mountain rescue, coast guard,
predictive models of all emergent behaviors, and etc. Each of these services is autonomous, with its
so global SoS performance is difficult to design own budget, structure, leadership, processes and
• Testing and verifying upgrades to an SoS is systems, but none can implement the necessary
difficult and expensive (sometimes prohibitively) comprehensive response acting alone. For example,
due to scale, complexity and constant evolution paramedics rely on police to secure the area, and
on fire crews to open up dangerous buildings or
Why should I care about SoS? damaged vehicles. In return, police and fire crews
Many systems engineers (SEs) work in an SoS rely on paramedics to treat and transport casualties.
context at some time during their careers – perhaps Together the services establish enablers such as
without even realizing it. This could be as an SE in shared protocols to facilitate joint operations without
a constituent system, or directly working on the SoS compromising their autonomous decision-making.
functionality itself. SoS contexts are associated with
specific challenges, and the existence of the SoS
places long-term, evolving requirements on each of
the constituents. Without an awareness of the wider INCOSE’s Vision 2025
SoS context, engineers on separate constituent INCOSE has identified system design in an SoS
systems run the risk that their system will struggle to context as one of the key transformations we must
meet operational requirements in the long term, even achieve to respond to changing global contexts.
if it currently meet its immediate requirements. Transformative technologies such as Internet
SoS span socio-technical contexts and enterprises of Things (IoT) and autonomous systems mean
as well as technology. Developing an SoS approach more future systems will be SoS, composed
to problem-solving involves taking a step back, of independent stakeholders, and delivering
identifying critical players and understanding their emergent behavior that is difficult to design and
motivations, looking at how they interact and then predict. INCOSE’s “Vision 2020” argues that
considering options in this light. This includes looking SoS engineering techniques must be improved
at technology challenges as well as organizational and widely adopted to deliver interoperability,
or socio-technical challenges across the SoS. predictable emergent behaviors, high performance
Developing this awareness of the SoS context can and quality of service. This will require continuous
help SEs working on separate constituent systems to verification and methods for managing the
identify potential sources of change earlier and plan integration of systems in a dynamic context with
more effectively for emerging long-term requirements. limited control.

INCOSE Systems of Systems Primer INCOSE-TP-2018-003-01.0

Systems tend to… Systems of systems tend to…
Have multiple levels of stakeholders with mixed
Have a clear set of stakeholders
and possibly competing interests

Have multiple, and possibly contradictory,

Have clear objectives and purpose
objectives and purpose

Have a clear management structure and clear Have disparate management structure with no
accountabilities clear accountability
Have multiple, and sometimes different,
Have clear operational priorities, with escalation
operational priorities with no clear escalation
to resolve priorities
routes
Have multiple lifecycles with elements being
Have a single lifecycle
implemented asynchronously

Have clear ownership with the ability to move Have multiple owners making individual
resources between elements resourcing decisions

Types of SoS
A taxonomy has evolved (proposed by Maier 1998, and extended by Dahmann & Baldwin 2008), which has
been widely used to categorise SoS into four different types based on the degree of control exhibited. It’s worth
noting that SoS are often complex, and may be classed differently depending on the level of granularity they
are viewed at, or their current operating mode at any one time.

Directed SoS are built and managed to fulfill specific purposes. Operations are centrally managed
to ensure goals are met. Although constituent systems retain the ability to operate independently,
they accept that their normal operational mode is subordinate to the central goals. Examples
can be found in metropolitan transportation systems. Although independently-owned, constituent
services may collaborate to deliver metro services, they must also accept considerable operational
direction in order to participate.

Acknowledged SoS have objectives recognized by the constituent systems, a designated

manager, and dedicated SoS resources. Constituent systems retain independent ownership,
objectives, funding, development and sustainment approaches. Unlike a directed SoS, changes
are based on agreed collaboration. Air traffic control is an example. Systems delivering managed
and safe airspaces globally all recognise their shared goals, collaborate on best practice and
adhere to regulations and protocols.

Collaborative SoS comprise constituent systems which voluntarily choose to participate to fulfil
some central purposes, which can evolve based on collaboration between constituents and SoS.
An electrical grid is an example. Autonomous constituent systems produce, transmit and distribute
electricity to consumers. Unlike an acknowledged SoS, there is no overall directing authority.
Constituent systems adhere to standards and regulations but can negotiate individually to evolve
roles and working practices.

Virtual SoS have no central authority, nor an explicit, recognized purpose accepted by all. A virtual
SoS can exhibit large-scale emergent behavior, but relies on standardised formats or protocols.
The internet is an example. The Internet Engineering Task Force (IEFT) publishes agreed
standards and protocols. Independent service providers can leverage these for new services or
products. No management or governance is either provided or accepted regarding usage, and
there is no central purpose for all parties.

INCOSE Systems of Systems Primer INCOSE-TP-2018-003-01.0

 Testing
SoS Pain
How to tackle SoS validation, testing
and continuous learning? End-to-end testing
is important, as SoS are often required to be
Points
highly reliable, but testing can be challenging and
expensive due to scale and complexity. There may What does a systems engineer
not even be resources dedicated to testing SoS
capabilities. Unsynchronized development cycles across need to know about SoS?
constituent systems complicates test planning. To tackle Many existing systems do play a role in an SoS,
this, modelling & simulation can reduce testing costs whether they are explicitly aware of this or not.
Working in an SoS context brings a number of
whilst modular architectures can reduce the change
challenges, and it can help to be aware of these.
propagation. To reduce risk, many SoS monitor
Surveys conducted by the INCOSE SoS Working
performance through actual operational data, Group have identified “pain points” which are
coupled with risk identification & mitigation particularly associated with SoS by practising
strategies. systems engineers (summarized by Judith
Dahmann 2014).

[1] COMPASS project: http://thecompassclub.org/

Capabilities
[2] DANSE project: http://danse-ip.eu/home/
[3] INTO-CPS project: http://projects.au.dk

& Requirements
How can systems engineering address SoS
capabilities and requirements? In SoS engineering
each constituent has its own requirements, whilst the
expectations for the SoS may be expressed as high-level
capabilities. Systems engineers at the SoS level need to
identify alternative approaches to meet SoS needs (e.g.,
replacing or adding to constituent systems, or agreeing Autonomy,
updates with constituent system developers). Each
constituent has constraints and limits; sometimes Interdependence
& Emergence
ideal SoS choices cannot feasibly be implemented.
Considering a range of options is a priority.
How can system engineering address the complexities
of SoS inter-dependencies and emergent behaviors?
Independent, uncoordinated evolution of constituent systems
can lead to unanticipated emergent effects at the SoS level, often
not observable until the SoS is simulated or tested. Complex
interdependencies are common between constituent systems
at different stages of maturity, often not well understood or
documented. The scale, diversity & independence in an SoS
makes it difficult to produce models that can accurately
predict SoS-level performance. Recent work has begun
to research SoS and emergence, SoS uncertainty &
complexity, and modelling & simulation – see, for
example,
[1, 2, 3].

INCOSE Systems of Systems Primer INCOSE-TP-2018-003-01.0

 SoS Authority SoS Principles
How do we handle collaboration and What are the key SoS thinking principles?
agreement when there is no overall director? Surveys of SoS practitioners have identified
Effective patterns for collaboration are needed, areas where basic principles are lacking.
but are often difficult to recognise or establish. The These include: lack of formalized SoS
defense sector tackles this with a focus on finding processes; lack of SoS success stories;
ways to balance the values & needs of constituent and information about workflows. Much
systems with those of the SoS. Other application more research on SoS working contexts
domains tackle this through incentivizing is needed to develop a body of
constituent systems, creating an environment recognized best practice.
where they can meet their own goals whilst
collaborating to support SoS goals.

Leadership
What are the roles & characteristics of
effective SoS leaders? The increasingly complex
collection of independent systems in an SoS
typically straddles disciplines, application domains,
organizations and even national boundaries, and each
constituent system is capable of following their own
interests and agenda. As a result, effective means of
leadership are important. Structure and directorship
usually found in SE projects is often absent for
SoS, and other methods are needed to ensure
coherence and direction.

Constituent
Systems
How to integrate constituent systems? Each
constituent system has its own agenda and
goals, and can act autonomously. Some may be
legacy systems not designed for SoS contexts,
not easily adapted, resulting in interoperability
challenges. Operating an SoS means finding means to
coordinate, incentivize and manage multiple separate
constituent systems, with separate working cultures,
schedules, processes and working practices, as
well as coping with technical challenges such
as communications and data exchange.
Mismatched assumptions and
expectations are a real risk.

INCOSE Systems of Systems Primer INCOSE-TP-2018-003-01.0

Core Elements of SoS Engineering
The DoD Systems Engineering Guide for SoS collects together seven core elements of SoS engineering,
representing the current state of best practice in this still-developing field. It’s recognized that these core
elements are interpreted and inform practises differently for each SoS context: an SoS team coordinating a
Directed or Acknowledged SoS would use different practises from a Constituent System (CS) team that is part
of a Collaborative or Virtual SoS. Below are some generalized principles, based on DoD guidelines.

Understanding capability objectives

SoS exist to deliver high-level capabilities implemented
by their constituent systems (CSs) in collaboration.
A key part of SoS engineering is to know and
understand these capabilities, and thereby to ensure
CS requirements are aligned with those capabilities. Yet
those capabilities often adapt and change more rapidly
than detailed engineering can follow. An SoS team can
define and manage the capabilities and can sometimes
even allocate capabilities into CS requirements. A CS
team often must envision the SoS capabilities and their
role in those capabilities based on partial information. Developing & Evolving an SoS
Use cases, scenarios or reference missions are helpful
for evaluating planned SoS operation and deriving CS Architecture
requirements. The SoS architecture does not define system details but
concentrates on defining how systems work together. It
Understanding systems and includes:
relationships • A concept of operations, capturing how systems will be
used by users
A good understanding is needed of the often-conflicting
priorities and drivers of the separate constituent systems • Systems, functions, relationships and dependencies
(CSs) and the SoS. This involves identifying CS functions between constituent systems as well as with the
and data exchange and collecting information about: environment
• Organizational relationships between systems • End-to-end functionality, data flow, and communications
• Details of stakeholders (users of the SoS and of CSs) Up-front analyses identify and capture sensitivities through
models, simulations, experimentation or other analysis,
• Details of CS resources and funding particularly examining scalability issues or thresholds at
• CS requirements which performance degrades. An SoS team can usually take
• Development processes and plans for separate a holistic view of the SoS. A constituent system team may
constituent systems. have only partial visibility into the entire SoS, and may model
the visible SoS architecture specifically for its own CS goals.
This leads to a better understanding of the SoS and its Issues with scale often hinder SoS modeling, such as trying
environment, for identifying where informal or formal to represent sufficient engineering detail while maintaining an
working agreements are required. abstracted, holistic view.

Assessing Performance against Monitoring & Assessing Changes

Capability Objectives Evolutionary development is the norm in an SoS
SEs working in SoS contexts collaborate with test because of the disparate ownership. Anticipating
and evaluation practitioners to establish metrics and changes is important – examples include underlying
methods for assessing SoS operational performance. technologies that affect the SoS, changes to SoS
Data from operational systems is used to monitor and objectives, changes to CS goals, or changes in external
understand the SoS state. However, different groups environment. SoS engineering involves identifying,
in the SoS will have different metrics, that often may tracking and anticipating trends. SoS teams may engage
conflict. An SoS team can define SoS metrics and constituent system owners to understand their changes
possibly influence constituents to contribute positively. and the likely SoS impact. CS teams may participate
At the higher levels of SoS, a constituent systems team with other CS teams or with SoS groups to anticipate
will define their own private metrics for participation in impacts on their own systems.
the SoS.

INCOSE Systems of Systems Primer INCOSE-TP-2018-003-01.0

 References
Below you can find sources for the information in this
guide.

Addressing Requirements & Dahmann, J., 2014. “Systems of Systems Pain

Solution Options Points”. Proceedings of the 24th INCOSE International
Symposium. Henderson, NV, USA. INCOSE, June 2014.
Defining and managing formal SoS requirements
are often nearly impossible due to the rapidly Dahmann, J. and Baldwin, K., 2008. “Understanding
evolving SoS. Yet each CS typically manages formal the Current State of US Defense Systems of Systems
requirements that impact the SoS objectives. The and the Implications for Systems Engineering”. IEEE
linkage between SoS objectives, CS requirements Systems Conference. IEEE, April 2008.
and engineering solutions is an important part
of SoS engineering. An SoS team can provide Department of Defense (DoD), 2008. “Systems
a valuable service to constituent systems by Engineering Guide for Systems of Systems: Version
coordinating the SoS needs and updates, even 1.0”. August 2008. http://www.acq.osd.mil/se/docs/SE-
allocating SoS functions into CS requirements. The Guide-for-SoS.pdf
SoS team will recommend requirements and work
with constituent systems to identify and assess INCOSE, 2014. “A World in Motion: Systems
alternatives. At higher SoS levels, CS teams may Engineering Vision 2025”. http://www.incose.org/docs/
assess options for their own systems in parallel, with default-source/aboutse/se-vision-2025.pdf?sfvrsn=4
collaboration to evaluate SoS impacts. Conflicts
Maier, M. W. 1998. “Architecting Principles for Systems-
between SoS and constituent systems should be
of-Systems”, Systems Engineering 1(4), 267-284.
identified, risk mitigation plans developed, and
alternatives evaluated.

Orchestrating Upgrades Further reading

Because an SoS is completely composed of Below you can find some recommended further reading
constituent systems, changes always occur at the to find out more information in the principles of SoS
constituent level. Generally, scheduling is dictated engineering.
by practicalities and it is not feasible to align all
constituent system schedules. Plans may be INCOSE System of Systems Working Group (SoS WG).
disrupted by external factors, including technical https://www.incose.org/incose-member-resources/
issues that systems engineers might not have fully working-groups/analytic/system-of-systems
understood, programmatic issues, budget changes,
or newly-emerging higher-priority development Systems and software engineering - system life cycle
needs. An SoS team can use SE processes processes (ISO/IEC/IEEE Standard 15288).
to coordinate independent constituent system
Annex G of this standard addresses “Application of
activities, agreeing scheduling of iterations with the
system life cycle processes to a system of systems”.
constituent program managers.
https://www.iso.org/standard/63711.html
The SoS team might search for activities already
under way in the constituent systems that can The Systems Engineering Body of Knowledge (SEBOK),
be leveraged for SoS goals; this is easier if an produced by the BKCASE project (INCOSE, IEEE
incremental approach is adopted. A CS team can Computer Society and the Systems Engineering
use the collaborative groups, including an SoS Research Centre). http://sebokwiki.org/
team or control board, to discover what changes
are planned to other constituent systems. Through INCOSE INSIGHT special issue on Systems of
coordination, the CS team can plan its own changes Systems Engineering 2016, special edition of INCOSE
for best effect toward its own goals. As upgrades practitioner’s magazine focusing on SoS engineering
are delivered, all teams continually assesses the
http://onlinelibrary.wiley.com/
SoS performance, testing and evaluating changes to
identify emergent issues and unexpected changes.

INCOSE Systems of Systems Primer INCOSE-TP-2018-003-01.0

Key points to remember SoS Considerations in the
• A System of Systems (SoS) is a collection of Lifecycle of A System
independent systems, integrated into a larger In today’s connected world, when engineering a system
system that delivers unique capabilities. Each it is important to ask: “How does the larger SoS
system contributes towards a global behavior context affect my decisions about the system?” Here
that can’t be achieved without the others. You will are some prompts to consider at each lifecycle stage:
probably work in an SoS during your career.
• Constituent system (CS) goals are separate to Concept
(and may conflict with) goals for the SoS itself. • What are the systems of systems surrounding my
Identifying links between SoS objectives, CS system?
requirements and engineering solutions is a key • Current operational, business, technical context?
part of SoS engineering.
• Impact of or on existing systems?
• SoS often have: stakeholders with competing • Interfaces?
interests; contradictory objectives between
participating systems; unsynchronized lifecycles; • Trade-offs within context and current systems?
disparate management; no clear accountability Development
between the separate constituent systems; no
• SoS impacts on constraints, coherence, including
clear escalation routes.
systems attributes, interfaces, performance
• Constituent systems may make decisions which requirements, or other design considerations for
impact you without warning. Understanding the the system?
relationship between your system, other systems, • SoS technical requirements and resulting
and the environment, will help you identify interfaces addressed in the system design
possible risks and anticipate sources of change. Interfaces?
Evolutionary, continuous development is the norm.
• Interoperability, system dependencies and changes
• Choose architectures to reduce change in other systems?
propagation, but be prepared to adapt if other
• SoS impacts of system design trade-offs?
constituent systems are unable or unwilling to
transition.
Production
• Focus on mitigation strategies and real-time
• What is the impact of changes on the ability of the
monitoring of operational performance.
system to operate effectively as part of the SoS?
• Independent evolution of constituent systems
means that unanticipated emergent behaviors Utilization / Support
can appear. However, it may be difficult to build • Effect on the system of changes in the operational
realistic testing environments, or to schedule context of the system?
testing windows to test global behavior.
• Impact on system of changes in the technical
• Modelling & simulation may reduce testing design or interfaces of other system in the SoS?
costs or the risk of unexpected emergence. • Impact of new technologies and the obsolescence
However, heterogeneous modelling notations of existing technologies on the system and the
and independent systems make it difficult to build SoS?
meaningful simulations of SoS-level behavior.
You’ll only have partial information for reasoning at Retirement
the SoS level. • Effect of system retirement of the system on SoS
• Consider organizational contexts. Work on capabilities?
understanding constituent systems goals and • Can remaining constituent systems, including new
ensuring they can be satisfied. This will help you systems being deployed support the SoS?
build incentives for other systems that you need to
help you meet your own goals.
Almost all systems today operate as part of a larger
• Where possible, establish an SoS team or control system of systems (SoS). Systems engineers need to
board and use it to discover planned changes for consider the SoS implications on the system at each
constituent systems which can be leveraged to stage of the system lifecycle
help the SoS achieve its own goals. Emerging Standard: ISO/IEC/IEEE 21839

INCOSE Systems of Systems Primer INCOSE-TP-2018-003-01.0