Difference between revisions of "Systems of Systems (SoS)"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "<center>'''SEBoK v. 2.6, released 20 May 2022'''</center>" to "<center>'''SEBoK v. 2.7, released 31 October 2022'''</center>")
(33 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
----
 +
'''''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.
 
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.
  
Line 7: Line 10:
 
*[[Capability Engineering]]
 
*[[Capability Engineering]]
  
−
==Definition and Characteristics of Systems of Systems==
+
==Characteristics and Definitionof Systems of Systems==
−
There are several definitions of system(s) of systems (SoS), some of which are dependent on the particularity of an application area. Maier (1998) postulated five key characteristics 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. Jamshidi has reviewed several potential definitions of SoS; although not all are universally accepted by the community, the following has received substantial attention:
+
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: 
 +
 
 +
<blockquote>'''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''</blockquote><blockquote>'''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.''</blockquote>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. 
  
−
<blockquote>''A SoS is an integration of a finite number of constituent systems which are independent and operatable, and which are networked together for a period of time to achieve a certain higher goal.'' (Jamshidi 2009)</blockquote>
+
{|
 +
|+ '''Table 1. Differences Between Systems and Systems of Systems as They Apply to Systems Engineering.'''
 +
!SE Process
 +
!'''Implementation as Applied to SoS'''
 +
|-
 +
|'''Agreement processes'''
 +
|Because there is often no top level SoS authority, effective agreements among the systems in the SoS are key to successful SoSE.
 +
|-
 +
|'''Organizational project enabling processes'''
 +
|SoSE develops and maintains those processes which are critical for the SoS within the constraints of the system level processes.
 +
|-
 +
|'''Technical management processes'''
 +
|SoSE implements technical management processes applied to the particular considerations of SoS engineering - planning, analyzing, organizing, and integrating the capabilities of a mix of existing and new systems into a system-of-systems capability while systems continue to be responsible for technical management of their systems.
 +
|-
 +
|'''Technical processes'''
 +
|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, constrained by system architectures. 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.
 +
|}
  
−
It should be noted that according to this definition, 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.
+
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.
−
DeLaurentis and Crossley (2005) have added to the five SoS characteristics above for SoS Engineering to include: inter-disciplinarity, heterogeneity of the systems involved, and networks of 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==
 
==Types of SoS==
−
SoS can take different forms. Based on a recognized taxonomy, there are four types of SoS (Maier 1998; Dahmann and Baldwin 2008):
+
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;
 
*  '''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;
Line 24: Line 60:
 
*  '''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.
 
*  '''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.
  
−
Further, in most actual cases, an SoS will reflect a combination of SoS types.
+
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)
  
−
It is important to note that in many cases, a system of systems will not be identified as such because it is the result of unplanned interactions between constituent systems.  These are not explicitly the subject of systems engineering. This added ‘ad hoc’ type of SoS, has also been termed ‘accidental’ (Kemp).  
+
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.
  
−
This taxonomy is based on the aforementioned aspect of degree of independence of constituents.  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. Other taxonomies may focus on nature/type of components, their heterogeneity, etc.
+
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.
  
−
==Emergence==
+
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.
−
Emergence is key to SoS, since in effect multiple, independent systems are brought together in an SoS explicitly to create new capability based on the interaction among the constituent systems.
 
  
−
As defined by Checkland, emergence is “the principle that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts.” (Checkland 1999, 314). Emergent system behavior can be viewed as a consequence of the interactions and relationships between system elements rather than the behavior of individual elements. It emerges from a combination of the behavior and properties of the system elements and the systems structure or allowable interactions between the elements, and may be triggered or influenced by a stimulus from the systems environment. [SEBoK EMERGENCE]
+
==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.  
  
−
However, there is much concern about emergent behavior which is unexpected or cannot be predicted by knowledge of the system’s constituent parts. As discussed in the US Department of Defense ''Systems Engineering Guide for Systems of Systems'' (DoD 2008) “for the purposes of a SoS, ''unexpected'' means unintentional, not purposely or consciously designed-in, not known in advance, or surprising to the developers and users of the SoS. In a SoS context, ''not predictable by knowledge of its constituent parts'' means the impossibility or impracticability (in time and resources) of subjecting all possible logical threads across the myriad functions, capabilities, and data of the systems to a comprehensive SE process."
+
Some examples include:
  
−
==Application Domains and the Difference between System of Systems Engineering and Systems Engineering==
 
−
Application of SoSE is broad and is expanding into almost all walks of life.  Originally addressed in the military 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. 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,
 
*  '''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,  
 
*  '''Energy''' - smart grid, smart houses, and integrated production/consumption,  
 
*  '''Health Care''' - regional facilities management, emergency services, and personal health management,
 
*  '''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,
 
*  '''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,  
 
*  '''Disaster Response''' - responses to disaster events including forest fires, floods, and terrorist attacks,  
 
*  '''Consumer Products''' - integrated entertainment and household product integration,
 
*  '''Consumer Products''' - integrated entertainment and household product integration,
−
*  '''Business- '''banking and finance,''' '''and
+
*  '''Business- '''banking and finance,and
−
'''
 
 
*  '''Media''' - film, radio, and television.  
 
*  '''Media''' - film, radio, and television.  
  
−
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.  In each case, the degree of difference varies in practice and with complexity of current systems and system development environments - many of the SoS characterizations may apply to systems in certain circumstances.
+
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. <blockquote>                              '''Table 2. Differences Between Systems and Systems of Systems as They Apply to Systems Engineering.''' (INCOSE, 2018)</blockquote>
 
{|
 
{|
−
|+ '''Table 1. Differences Between Systems and Systems of Systems as They Apply to Systems Engineering.''' (SEBoK Original), adapted from Dahmann and Baldwin (2008) and Neaga et al. (2009)
+
|+
−
|-
+
!Systems tend to ...
−
!
+
!Systems of systems tend to ...
−
!Systems Engineering
 
−
!Systems of Systems Engineering
 
−
|-
 
−
|colspan="3"|'''Management and Oversight'''
 
−
|-
 
−
|System
 
−
|Physical engineering
 
−
|Socio-technical management and engineering
 
−
|-
 
−
|Stakeholder Involvement
 
−
|Clear set of stakeholders
 
−
|Multiple levels of stakeholders with mixed and possibly competing interests
 
−
|-
 
−
|Governance
 
−
|Aligned management and funding
 
−
|Added levels of complexity due to management and funding for both SoS and systems; SoS does not have control over all constituent systems
 
−
|-
 
−
|colspan="3"|'''Operational Focus (Goals)'''
 
−
|-
 
−
|Operational Focus
 
−
|Designed and developed to meet common objectives
 
−
|Called upon to meet new SoS objectives using systems whose objectives may or may not align with the SoS objectives
 
−
|-
 
−
|colspan="3"|'''Implementation'''
 
−
|-
 
−
|Acquisition/Development
 
−
|Aligned to established acquisition and development processes
 
−
|Cross multiple system lifecycles across asynchronous acquisition and development efforts, involving legacy systems, developmental systems, and technology insertion
 
 
|-
 
|-
−
|Process
+
|Have a clear set of stakeholders
−
|Well-established
+
|Have multiple levels of stakeholders with mixed and possibly competing interests
−
|Learning and Adaptation
 
 
|-
 
|-
−
|Test and Evaluation
+
|Have clear objectives and purpose
−
|Test and evaluation of the system is possible
+
|Have multiple, and possibly contradictory, objectives and purpose
−
|Testing is more challenging due to systems' asynchronous life cycles and given the complexity of all the parts
 
 
|-
 
|-
−
|colspan="3"|'''Engineering and Design Considerations'''
+
|Have clear operational priorities, with escalation to resolve priorities
 +
|Have multiple, and sometimes different, operational priorities with no clear escalation routes
 
|-
 
|-
−
|Boundaries and Interfaces
+
|Have a single lifecycle
−
|Focuses on boundaries and interfaces
+
|Have multiple lifecycles with elements being implemented asynchronously
−
|Focus on identifying systems contributing to SoS objectives and enabling flow of data, control and functionality across the SoS while balancing needs of the systems OR focus on interactions between systems.  Difficult to define system-of-interest
 
 
|-
 
|-
−
|Performance and Behavior
+
|Have clear ownership with the ability to move resources between elements
−
|Performance of the system to meet performance objectives
+
|Have multiple owners making independent resourcing decisions
−
|Performance across the SoS that satisfies SoS use capability needs while balancing needs of the systems
 
−
|-
 
−
|Metrics
 
−
|Well defined (e.g., INCOSE handbook)
 
−
|Difficult to define, agree, and quantify
 
 
|}
 
|}
 +
 +
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==  
 
==References==  
  
−
===Works Cited===
+
===Works Cited ===
−
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.  
+
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: <nowiki>https://acqnotes.com/wp-content/uploads/2014/09/DoD-Systems-Engineering-Guide-for-Systems-of-Systems-Aug-2008.pdf</nowiki>
 +
 
 +
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[[# msocom 1|.]]
 +
 
 +
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.
  
−
DeLaurentis, D., and W. Crossley. "A Taxonomy-Based Perspective for System of Systems Design Methods." Paper 925, presented at IEEE Conference on Systems, Man, and Cybernetics, October 10-12, 2005, Waikoba, HI, USA.
+
Jamshidi, M. (ed). 2009a. ''Systems of Systems Engineering – Innovations for the 21st Century''. Hoboken, NJ, USA: Wiley.
  
−
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 November 12, 2013. Available: http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf.
+
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.
 
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.
  
−
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.
+
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=6384211
  
 
Maier, M.W. 1998. "Architecting Principles for Systems-of-Systems." ''Systems Engineering.'' 1 (4): 267-284.
 
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[[# msocom 1|.]]
  
 
===Primary References===
 
===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.  
 
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.  
 
Jamshidi, M. (ed). 2009a. ''[[Systems of Systems Engineering – Innovations for the 21st Century]]''. Hoboken, NJ, USA: Wiley.  
−
 
−
Jamshidi, M. (ed). 2009b. ''[[Systems of Systems Engineering - Principles and Applications]]''. Boca Raton, FL, USA: CRC Press.
 
  
 
Maier, M.W. 1998. "[[Architecting Principles for Systems-of-Systems]]." ''Systems Engineering''. 1 (4): 267-284.
 
Maier, M.W. 1998. "[[Architecting Principles for Systems-of-Systems]]." ''Systems Engineering''. 1 (4): 267-284.
−
 
−
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.
 
  
 
===Additional References===
 
===Additional References===
Line 147: Line 193:
  
 
Luzeaux, D., and J.R. Ruault. 2010. ''Systems of Systems''. London, UK: ISTE.
 
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: [https://mitre.tahoe.appsembler.com/blog]
 +
 +
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).
 
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).
−
 
−
Rebovich Jr., G. 2009. "Chapter 6: Enterprise System of Systems," in ''Systems of Systems Engineering - Principles and Applications''. Boca Raton, FL, USA: CRC Press.
 
  
 
Ring J. 2002. "Toward an ontology of systems engineering." ''INSIGHT.'' 5 (1): 19-22.
 
Ring J. 2002. "Toward an ontology of systems engineering." ''INSIGHT.'' 5 (1): 19-22.
  
 +
===Relevant Videos===
 +
*[https://www.youtube.com/watch?v=ryLeFaHarPQ Systems of Systems (Somerville)]
 +
*[https://www.youtube.com/watch?v=h2br2_twHfw&t=1s System of Systems]
 
----
 
----
 
<center>[[Enterprise Capability Management|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Architecting Approaches for Systems of Systems|Next Article >]]</center>
 
<center>[[Enterprise Capability Management|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Architecting Approaches for Systems of Systems|Next Article >]]</center>
  
 +
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center>
  
−
 
+
[[Category: Part 4]]
−
[[Category: Part 4]][[Category:Knowledge Area]]
+
[[Category:Knowledge Area]]
−
{{DISQUS}}
 

Revision as of 08:33, 10 October 2022

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.

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:

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
Agreement processes Because there is often no top level SoS authority, effective agreements among the systems in the SoS are key to successful SoSE.
Organizational project enabling processes SoSE develops and maintains those processes which are critical for the SoS within the constraints of the system level processes.
Technical management processes SoSE implements technical management processes applied to the particular considerations of SoS engineering - planning, analyzing, organizing, and integrating the capabilities of a mix of existing and new systems into a system-of-systems capability while systems continue to be responsible for technical management of their systems.
Technical processes 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, constrained by system architectures. 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 a clear set of stakeholders Have multiple levels of stakeholders with mixed and possibly competing interests
Have clear objectives and purpose Have multiple, and possibly contradictory, objectives and purpose
Have clear operational priorities, with escalation to resolve priorities Have multiple, and sometimes different, operational priorities with no clear escalation routes
Have a single lifecycle Have multiple lifecycles with elements being implemented asynchronously
Have clear ownership with the ability to move resources between elements Have multiple owners making independent resourcing decisions

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-Systems-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=6384211

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

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.7, released 31 October 2022
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Systems_of_Systems_(SoS)&oldid=66495"