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

From SEBoK
Jump to navigation Jump to search
Line 59: Line 59:
  
 
==Emergence==
 
==Emergence==
Whilst emergent behavior is an issue for systems, emergence in SOS is particularly problematic.  This is due to:
+
Whilst emergent behavior is an issue for systems, emergence in SoS is particularly problematic.  This is due to:
 
*  The strong human element in the system, where users may not understand the full implications of their actions,
 
*  The strong human element in the system, where users may not understand the full implications of their actions,
 
*  The ability of SoS to dynamically re-configure, undermining the normal performance and safety management processes which rely on fixed configurations, and
 
*  The ability of SoS to dynamically re-configure, undermining the normal performance and safety management processes which rely on fixed configurations, and

Revision as of 18:39, 9 October 2013

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:


Definition and Characteristics of Systems of Systems

What do we mean by Systems of Systems? SoS abound in the modern world, and are arguably on the increase, but challenge simple attempts at definition since all systems are to some extent systems of systems, in at least two respects:

• The fundamental SE paradigm is based on breaking a system into a set of subsystems which can be further broken into subsystems and components, which are built separately and progressively assembled. Our ability to do so successfully depends on our ability to model system performance at the point of design and decomposition, to avoid negative emergent properties.

• When we build a system, we may very well build (or modify, or reuse, or interface to) a number of others, such as the prototyping, manufacturing, test, maintenance and disposal systems. We might consider a SoS to exist when a number of systems – under development or during operations – are somehow coupled. This coupling might take a number of forms:

• Systems which share common technology or subsystems, as in commercial product development. • Systems which share support infrastructur (such as test equipment, manufacturing facilities or maintenance). • Systems which contribute towards a common mission or goal during operation – probably the most class most usually referred to as an SoS.


In no particular order, here are a number of systems of systems which fit somewhere in the spaces referred to above:

• A system and all the associated systems which support it through life, whether developed especially for the system of interest or shared with others;

• A family of systems sharing common platforms, eg a range of cars, photocopiers or cameras;

• A group of military systems contributing to a common mission, whether developed with this in mind or not;

• All the equipment we bring together in our home, to serve a common purpose, often acting as our own system integrator and responding opportunistically to new technology;

• Large systems which emerge, for example when we link information systems using internet technology.


There are several definitions of System(s) of Systems, 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. Jamshidi (2009) has reviewed several potential definitions of SoS; although not all are universally accepted by the community, the following has received substantial attention:

"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."

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.

DeLaurentis (2005) has added to the five SoS characteristics above for SoS Engineering to include: inter-disciplinarity, heterogeneity of the systems involved, and networks of systems.

Not all SoS will exhibit all of the characteristics, but it is generally assumed that a SoS is characterized by exhibiting a majority of the Maier characteristics. Although the individual systems in a SoS are usually considered to have independent operational viability, it is sometimes the case that the SoS must contain some systems that have the sole purpose of enabling the interoperation of the other component systems; i.e. the enabling systems cannot operate outside of the SoS.

All attempts to cope with SoS are to some extent management strategies, so it is no longer sufficient to make managerial independence the defining characteristic. In practice we find management approaches lie on a continuum ranging from hands-on control (suitable for bringing together a range of previously-developed systems into an integrated program) to laissez-faire (eg how we integrate all the commercial systems into our home office and entertainment systems) or even nil (as in the systems which emerge by bring pre-existing systems together speculatively). There are a number of other management strategies which fit in-between, for example industrial collaboration to create common frameworks or standards, or empowering design teams to negotiate agreements on a peer-to-peer basis.

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):

  • 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 characterization offers a framework for understanding SoS based on the origin of the SoS capability objectives and the relationships among the stakeholders for both the SoS and the systems.

Emergence

Whilst emergent behavior is an issue for systems, emergence in SoS is particularly problematic. This is due to:

  • The strong human element in the system, where users may not understand the full implications of their actions,
  • The ability of SoS to dynamically re-configure, undermining the normal performance and safety management processes which rely on fixed configurations, and
  • The lack of a single design or operating authority, making SoSE a collaborative, rather than directive, activity.

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 DoD SoS SE Guide (US 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."

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 military applications, the defense sector has provided a base for some initial approaches to conceiving and engineering SoS, which offer intellectual foundation, technical approaches, and practical experience to this field. However, SoS is far from limited to defense. In fact, as one looks at the world through a SoS lens, it becomes clear that SoS concepts and principles apply across other governmental, civil and commercial domains. Some examples include:

  • Transportation - the European rail network, integrated ground transportation, cargo transport, air traffic, 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,
  • Natural Resource Management - global environment, regional water resources, forestry, and recreational resources,
  • Disaster Response - forest fires, floods, and terrorist attacks,
  • Consumer Products - integrated entertainment and household product integration, and
  • Media - film, radio, television.

Understanding the environment in which a system or SoS will be developed and employed is central to understanding how best to apply SE principles within that environment. Observations regarding differences between individual or constituent systems and SoS are listed in Table 1. 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.

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 Engineering Systems of Systems Engineering
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
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
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 Well-established Learning and Adaptation
Test and Evaluation Test and evaluation of the system is possible Testing is more challenging due to systems' asynchronous life cycles and given the complexity of all the parts
Engineering and Design Considerations
Boundaries and Interfaces Focuses on boundaries and interfaces 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 Performance of the system to meet performance objectives 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

References

Works Cited

Dahmann, J. and K. Baldwin. 2008. "Understanding the Current State of US Defense Systems of Systems and the Implications for Systems Engineering." Paper presented at IEEE Systems Conference, 7-10 April, Montreal, Canada.

DeLaurentis, D. and W. Crossley. "A Taxonomy-Based Perspective for System of Systems Design Methods," Paper 925, IEEE 2005 Conference on Systems, Man, and Cybernetics, Waikoba, HI, Oct. 10-12, 2005.

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, 20th - 23rd April 2009, Loughborough University, UK.

Maier, M.W. 1998. "Architecting Principles for Systems-of-Systems." Systems Engineering. 1(4): 267-284.

Primary References

Dahmann, J., and K. Baldwin. 2008. "Understanding the Current State of US Defense Systems of Systems and the Implications for Systems Engineering." Paper presented at IEEE Systems Conference, 7-10 April, Montreal, Canada.

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.

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

Additional References

Barot, V., Henson, S., Henshaw, M., Siemieniuch, C., Sinclair, M., Lim, S.L., Jamshidi, M., and DeLaurentis, D. 2012. "Trans-Atlantic Research and Education Agenda in Systems of Systems (T-AREA-SoS) SOA Report", Ref. TAREA-RE-WP2-R-LU-7

Carlock, P. and J.A. Lane. 2006. System of Systems Enterprise Systems Engineering, the Enterprise Architecture Management Framework, and System of Systems Cost Estimation. 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.

DeLaurentis, D. and W. Crossley. "A Taxonomy-Based Perspective for System of Systems Design Methods," Paper 925, IEEE 2005 Conference on Systems, Man, and Cybernetics, Waikoba, HI, Oct. 10-12, 2005.

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: ISTE.

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." 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.


< Previous Article | Parent Article | Next Article >
SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus