Difference between revisions of "Architecting Approaches for Systems of Systems"

From SEBoK
Jump to navigation Jump to search
m (Removed protection from "Architecting Approaches for Systems of Systems": Opening for Core Team Edit)
m (Text replacement - "SEBoK v. 2.9, released 13 November 2023" to "SEBoK v. 2.9, released 20 November 2023")
 
(69 intermediate revisions by 10 users not shown)
Line 1: Line 1:
−
A key part of the SoSE task is to establish a technical framework for composing systems to meet SoS needs, including possible changes in systems functionality, performance or interfaces, and evolving the SoS over time to meet changing SoS objectives. This technical framework is essentially an overlay to systems which comprise the SoS, and is often referred to as the ''architecture'' for the SoS.   Notably, a SoS architecture does not address the details of the individual systems; rather, it defines the way the systems work together to meet user needs and addresses the implementation of individual systems only when their functionality is key to crosscutting issues of the SoS. Developing and evolving the SoS architecture is core to the engineering of a SoS.   
+
----
 +
'''''Lead Authors:''''' ''Judith Dahmann, Bud Lawson, Mike Henshaw''
 +
----
 +
A key part of {{Term|Systems Engineering (glossary)|systems engineering}} (SE) for {{Term|System of Systems (SoS) (glossary)|system of systems}} (SoS) is the composition of systems to meet SoS needs. This may include simply interfacing systems and leveraging their existing functionality or it may require changing the systems functionality, performance or interfaces. These changes occur incrementally, as a SoS evolves over time to meet changing SoS objectives. System of Systems Engineering (SoSE) supports these changes by developing and evolving a technical framework that acts as an overlay to the systems of which the SoS is composed. This framework provides the ''architecture'' for the SoS. The SoS architecture defines how the systems work together to meet SoS objectives and considers the details of the individual systems and their impact the SoS performance or functionality.   
  
 
==The Role of System of Systems Architecting==
 
==The Role of System of Systems Architecting==
−
An [[Architecture (glossary)|architecture]] is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time (IEEE Std 610.12). The architecture of a SoS is a persistent technical framework for governing the evolution of a SoS over time. 
+
An {{Term|Architecture (glossary)|architecture}} is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time (IEEE 610.12-1990).  
−
An architecture for a SoS includes:
 
−
 
 
−
*[[Concept of Operations (ConOps) (glossary)|Concept of operations (CONOPs)]]; how the systems will be employed by the users in an operational setting
 
−
*Systems, functions, and relationships and dependencies, both internal and external
 
−
*End-to-end functionality and data flow as well as communications
 
−
 
 
−
The architecture of a SoS is constrained by the structure and content of the individual systems, particularly the extent to which changes in those systems are affordable and feasible, since systems will typically need to continue to function in other settings in parallel with participation in the SoS.  Architecture data on constituent systems can be an important input to SoS architecture development.
 
−
 
 
−
Developing a SoS architecture requires analysis and assessments of trades among different options. Architecture analysis may be supported by different assessment approaches.  Available architecture frameworks (e.g. Zachman 1987; DoDAF; MoDAF) provide tools to collect and organize information to support SoS architecture development and represent architecture decisions.
 
  
−
The functional architecture is derived from the CONOPs. While for directed SoS, major changes in the systems may be possible, in other types of SoS legacy systems may constrain change.
+
In a SoS, the architecture is the technical framework for the systems comprising the SoS which designates how the systems will be employed by the users in an operational setting (sometimes called the {{Term|Concept of Operations (ConOps) (glossary)|concept of operations}} (CONOPs or CONOPs), the internal and external relationships and dependencies among the constituent systems and their functions and, finally, the end-to-end functionality and data flow as well as communications among the systems.
  
−
The functional architecture provides a functional ''picture'' of the system. It details the complete set of functions to be performed within the SoS as well as the relationships among the functions. The output of the design process is the physical architecture that defines the physical components (constituent systems) of the SoS.  
+
Because SoS largely comprise extant independent systems, these place constraints on the SoS architecture and may require that migration to a SoS architecture be incremental. Developing a SoS architecture requires consideration of technical feasibility for the constituent systems as well as the needs of the SoS itself. Architecture data for the constituent systems can also be important data for architecting the SoS.  There is some similarity here to the introduction of Commercial Off The Shelf (COTS) products into systems: the COTS product has been independently managed but sufficient data is required by the systems developer to ensure satisfactory integration. However, in this case the COTS product is not independently operated
  
−
In most cases, due to legacy systems, the migration to an architecture of a SoS will be incremental. Ideally the architecture of a SoS will persist over multiple increments of SoS development, allowing for change in some areas while providing stability in others. This ability to persist and provide a useful framework in light of changes is a core characteristic of a good architecture. Over time, the SoS will face changes from a number of sources (e.g., capability objectives, actual user experience, changing concepts of operations and technology, and unanticipated changes in systems) which may all affect the viability of the architecture and may call for changes. Consequently the SoS systems engineer needs to regularly assess the architecture to ensure that it supports the SoS evolution.
+
Maier (1998) provides a conceptual discussion on the impact of SoS characteristics on SoS architecting. Additionally, the US DoD SE Guide for SoS (2008) describes practical considerations in developing and evolving a SoS architecture as a core element of SoSE.
  
 
==Challenges in Architecting SoS==
 
==Challenges in Architecting SoS==
−
In the case of a new system development, the systems engineer can begin with a fresh, unencumbered approach to architecture. However, in a SoS, the systems contributing to the SoS objectives are typically in place when the SoS is established, and the SoS systems engineer needs to consider the current state and plans of the individual systems as important factors in developing an architecture for the SoS. This, along with the fact that constituent systems may be complex systems in their own right, leads to a set of challenges to architecting SoS.
+
In the case of a new system development, the systems engineer can begin with a fresh, unencumbered approach to architecture. However, in a SoS, the systems contributing to the SoS objectives are typically in place when the SoS is established and the SoS engineer needs to consider the current state and plans of the individual systems as factors in developing an architecture for the SoS. This, along with the fact that constituent systems may be complex systems in their own right, leads to a set of challenges to architecting SoS. The approach to architecting must be determined by the type of SoS under consideration.  Whereas a directed SoS can be architected in much the same way as a monolithic system, the other types are less straightforward, because the SOI may be less clearly defined and because the SoS architects knowledge of the constituent systems may be partial. Furthermore, whereas in a directed SoS the owner may have authority and funding to require architectural changes of constituent systems, in acknowledged and collaborative SoS re-architecting is at the discretion of the owners of the constituent systems. Maier (Maier 1998) has focused architecting attention on communication for SoS, arguing that this is the common feature of all types, and he partitions the communication into layers that have a similarity to the layers of interoperability (NCOIC, 2008).
−
 
 
−
First, as noted above, the managerial and operational independence of constituent systems can pose major challenges for the SoS architecture.  Because systems are likely to continue to face new functional requirements and the need for technology upgrades independent of the SoS, there is an advantage to a SoS architecture which is loosely coupled — that is, it has limited impact on the individual systems, allowing for changes in functionality and technology in some systems without impact on others or on the SoS objectives.  
 
  
−
Second, the independence of the constituent systems also means that these systems are typically not designed to optimize SoS objectives.  In the area of trust for example, a system may severely constrain access to services to provide a level of security when a SoS may depend on free exchange of those services. (Rebovich 2009) has articulated this difficulty as a fundamental problem of SoS:
+
The independence of the constituent systems means that these systems are typically not designed to optimize SoS objectives.  It may even be the case that a constituent system should operate sub-optimally at the system level in order to achieve overall SoS effectiveness. (Rebovich 2009) has articulated this difficulty as a fundamental problem of SoS:  
 +
<blockquote>''From the single-system community's perspective, its part of the SoS capability represents additional obligations, constraints and complexities. Rarely is participation in an (sic) SoS seen as a net gain from the viewpoint of single-system stakeholders.''</blockquote>
  
−
<blockquote>From the single-system community's perspective, its part of the SoS capability represents additional obligations, constraints and complexities. Rarely is participation in an (''sic'') SoS seen as a net gain from the viewpoint of single-system stakeholders.</blockquote>
+
The development and implementation of a SoS architecture may be significantly constrained by a reluctance to make changes or invest in the constituent systems, which could be very mature (e.g. in sustainment) or currently productively supporting other uses. In this case, approaches such as gateways and wrapping may be used to incorporate these systems into the SoS without making significant changes in the other systems.
−
 
 
−
Third, as introduced in the [Emergence] sub-section, there are risks associated with unexpected or unintended behavior resulting from combining systems with individual complex behavior.  These become serious in cases where safety, for example, is threatened through unintended interactions among services provided by multiple constituent systems in a SoS.
 
−
 
 
−
Finally, the development and implementation of a SoS architecture may be significantly constrained by a reluctance to make changes or invest in the constituent systems, which in many cases are very mature (e.g. in sustainment) or currently productively supporting other systems. In this case, approaches such as gateways and ''wrapping'' may be used to incorporate these systems into the SoS without making significant changes in the other systems.
 
  
 
==Architecture Analysis==
 
==Architecture Analysis==
−
''Large-scale systems integration'' has grown in importance. In parallel, there is a growing interest in SoS concepts and strategies. The performance and functioning of groups of heterogeneous systems has become the focus of various applications including military, security, aerospace, distributed energy, healthcare, and disaster management systems (Lopez 2006; Wojcik and Hoffman 2006). There is an increasing interest in achieving synergy between these independent systems to achieve the desired overall system performance (Azarnoush, et. al. 2006).  
+
''Large-scale systems integration'' has grown in importance and correspondingly, there has been a growing interest in SoS concepts and strategies. The performance and functioning of groups of heterogeneous systems has become the focus of various applications including military, security, aerospace, distributed energy, healthcare, and disaster management systems (Lopez 2006; Wojcik and Hoffman 2006). There is an increasing interest in exploiting synergy between these independent systems to achieve the desired overall system performance (Azarnoush et al. 2006).
 +
 +
Modeling and simulation is conducted to analyze architecture effectiveness and to verify architectural features. In the literature, researchers have addressed the issues of coordination and {{Term|Interoperability (glossary)|interoperability}} in a SoS (Abel and Sukkarieh 2006; Sahin et al. 2007). In order to study SoS characteristics and parameters, one needs to have realistic simulation frameworks properly designed for system of systems architecture. There are some attempts to develop simulation frameworks for multi-agent systems using Discrete Event Simulation (DEVS) tools (Zeigler et al. 2000a). In these research efforts, the major focus is given to DEVS architecture with JAVA. In (Mittall 2000), DEVS state machine approach is introduced. Finally, DEVS Modeling Language (DEVSML) is developed by using XML based JAVA in order to simulate systems in a net-centric way with relative ease. Sahin et al. (2007) have recently introduced a discrete event XML based SoS simulation framework based on DEVS and JAVA.
  
−
Modelling and simulation is conducted to analyse architecture effectiveness and to verify architectural features.  In the literature, researchers have addressed the issues of coordination and interoperability in a SoS (Abel & Sukkarieh 2006; Sahin et. al. 2007). In order to study SoS characteristics and parameters, one needs to have realistic simulation frameworks properly designed for system of systems architecture. There are some attempts to develop simulation frameworks for multi-agent systems using Discrete Event Simulation tools (Zeigler, et. al. 2000a). In these research efforts, the major focus is given to DEVS architecture with JAVA.  In (Mittall, 2000b), DEVS state machine approach is introduced. Finally, DEVS Modeling Language (DEVSML) is developed by using XML based JAVAL in order to simulate systems in a net-centric way with relative ease. (Sahin et. al., 2007) have recently introduced a discrete event XML based SoS simulation framework based on DEVS and JAVA.
+
==The Open Approach to SoS Engineering==
 +
As noted above, one of the key challenges with SoS architecting is that the constituent systems of a SoS may not have been designed, developed and employed with regard to their role in the SoS, which constrains SoS architecture options. The degree to the architecture which ''overlays'' these constituent systems and supports the SoS end-to-end capabilities can be based on open standards; the SoS may be able to benefit from open architecture for future evolution.
  
−
==The Open approach to SoS Engineering==
+
The critical challenge of moving from SoS, as a concept to the engineering of SoS, is the significant technological, human, and organizational differences in consideration system of systems engineering and management approaches (Wells and Sage 2008). A potential approach to engineering a SoS can be the ''open systems approach'' to SoSE (Azani 2009). The following open systems principles are listed by Azani (2009):
−
The critical challenge of moving from SoS as a concept to the engineering of SoS is the significant technological, human, and organizational differences when considering system of systems engineering and management (Wells and Sage 2008). A potential approach to engineering of SoS can be the ''open systems approach'' to SoSE (Azani 2009).   The open systems principles listed by Azani (Azani 2009) are:
+
*'''Open interface principle''' - Open systems have permeable boundaries that allow them to exchange mass, energy, and information with other systems;
 +
*'''Synergism principle''' – The notion that designates that the co-operative interaction between constituent systems has a greater effect in their combined efforts than the sum of their individual parts. Essentially, this is what gives rise to emergence;
 +
*'''Self-government principle''' - This implies that the SoS maintains and develops its internal order without interference from external sources. This could be through cybernetic control, homeostasis, or self-organization;
 +
*'''Emergence principle''' - In this case, this refers to the occurrence of novel and coherent structures, patterns, and properties during the self-organization of the SoS;
 +
*'''Conservation principle''' – This principle states that energy and mass (material) are conserved within the SoS;
 +
*'''Reconfiguration principle''' – This refers to the SoS reconfiguring and adapting itself to sustain itself against changes in its environment;
 +
*'''Symbiosis principle''' - The systems within the SoS have a symbiotic relationship to each other; more transparently, the successful development and sustainment of a SoS depends on symbiotic collaboration between the stakeholders of the systems of which it is comprised; and
 +
*'''Modularity principle''' -  This holds that each level and each system is to some extent independent of others. In SoS design, the development of independent modular systems that interoperate with each other through standardized interfaces enables greater flexibility to promote better evolution of the SoS.
 +
 +
Azani (2009) elaborates on the open systems development strategies and principles utilized by biotic SoS, discusses the implications of engineering of man-made SoS, and introduces an integrated SoS development methodology for the engineering and development of an adaptable, sustainable, and interoperable SoS based on open systems principles and strategies.
 +
 +
Hitchens (2003, 107), on the other hand, discusses the principles of open systems rather differently in terms of their systems life cycles, as the seven principles that he addresses are system reactions, system cohesion, system adaptation, connected variety, limited variety, preferred patterns, and cyclic progression. This description takes a systems dynamics approach to show how open systems evolve; the description is applicable to natural and man-made systems.
 +
 +
The enablers of openness include open standards and open specifications, which draw from consensus amongst a community of interest, and are published by, and freely available within, that community. An open specification must ensure that its detail-level is allows for it to be implementable by independent parties. Compliance with open standards is intended to ensure consistent results (Henshaw, et. al., 2011). This parallels the notion of open systems architecture, which is an open specification of the architecture of a system or system of systems for the purpose of acquiring specified capabilities. As a general feature of good design (for a system or system of systems), an open system architecture should allow for the quick and easy improvement and updating of the system capabilities, by adding or changing components.  However, Henshaw et. al. (2011) also denote that open architecture represents a commercial challenge (rather than a technical one) and that establishing open architecture approaches to acquisition can be challenging, due to issues involving protection of intellectual property (IP) and commercial advantage.
  
−
*Open interface principle: open systems have permeable boundaries that allow them to exchange mass, energy, and information with other systems.
+
==Networks and Network Analysis==
−
*Synergism principle: the co-operative interaction between constituent systems so that their combined effect is greater than the sum of the individual parts.  Essentially, this is what gives rise to emergence.
+
Because networks are such a common component of SoS, they warrant specific attention. In SoS that are based on an underlying network, communications and information exchange typically constitute a SoS in its own right. This enabling SoS requires architecting like any other SoS, which will be addressed in this section. In the case of an enabling network SoS, the ‘user’, the end-to-end functionality of the larger SoS and enabling network SoS is driven by these user needs. The relationship between SoSE concepts and network enablement, as well as the concepts of networks and network analysis that extend beyond information sharing, have been explored extensively by the defense community (Dickerson and Mavris 2009). For instance, during the U.S. Navy’s work on command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) as part of a SoS (Owens 1996), the term network included organizational aspects of command and control (C2) structure as well as communications.
−
*Self-government principle: this implies that the SoS maintains and develops its internal order without interference from external sources. This could be through cybernetic control, homeostasis, or self-organization.
+
−
*Emergence principle: in this case, this refers to the occurence of novel and coherent structures, patterns, and properties during the self-organization of the SoS.
+
Differences in the architecting of an enabling network SoS derive from the fact that these SoS are typically built on commercial technologies and architectures, which are changing rapidly in today’s dynamic technological environment. In addition, these enabling networks are often shared among SoS and hence may further constrain the overall SoS architecture. For example, many SoS (for cost and convenience) expect to operate over the internet, and therefore must consider characteristics of the internet in the expectations for performance and security provided by use of a shared enabling infrastructure.
−
*Conservation principle: energy and mass (material) are conserved within the SoS.
+
−
*Reconfiguration principle: the SoS reconfigures and adapts itself to sustain itself against changes in its environment.
+
Enabling network SoS architecting is particularly well-served by the initial analysis that explores sensitivities through modeling, simulation, analysis, and/or laboratory experimentation and identifies scalability issues or divergent behavior (e.g., concerning requirements or usage assumptions, assumed network bandwidth, or others), beyond which performance starts to break down. This type of analysis provides a basis for network architecture decisions.
−
*Symbiosis principle: the systems within the SoS have a symbiotic relationship to each other; more transparently, the successful development and sustainment of a SoS depends on symbiotic collaboration between the stakeholders of the systems of which it is comprised.
+
   
−
*Modularity principle: each level and each system is to some extent independent of others.  In SoS design, the development of independent modular systems that interoperate with each other through standardized interfaces enables greater flexibility to promote better evolution of the SoS.
+
In directed SoS, because of the top-down control, there is the option for creating a specialized network for the particular SoS. In the other types of SoS, if the constituents are already supported by some type of a network then the overall SoS networking approach typically needs to accommodate these since the constituent systems are likely to need to continue to use their current approach to support their original users.
  
−
Azani (Azani 2009) has elaborated the open systems development strategies and principles utilized by biotic SoS, discussed their implications for engineering of man-made SoS, and introduced an integrated SoS development methodology for engineering and development of adaptable, sustainable, and interoperable SoS based on open systems principles and strategies.
+
==Interoperability==
 +
{{Term|Interoperability (glossary)|Interoperability}} within a SoS implies that each system can communicate and interact (control) with any other system regardless of their hardware and software characteristics or nature. This implies that each constituent member (and potential new members) of a SoS should be able to communicate with others without compatibility issues in the operating systems, communication hardware, and so on. For this purpose, a SoS needs a common language the SoS’s systems can speak. Challenges here are to work towards a common language for exchange of information and data among systems of a SoS. Examples of such system are XML (eXtensible Markup Language), as one potential candidate (Jamshidi, 2009a).
 +
 +
However, interoperability must be achieved at many levels and not just at the data/network level. There are a number of frameworks that describe the levels of interoperability. From military applications, the NCOIC (Network Centric Operations Industry Consortium) Interoperability Framework (NCOIC 2008) covers three broad levels of interoperability, subdivided into further layers as indicated below:
  
−
(Hitchens, 2003, 107) has expressed the principles of open systems rather differently, in the context of systems life cycles, as the seven principles of system reactions, system cohesion, system adaptation, connected variety, limited variety, preferred patterns, and cyclic progression.  This description takes a systems dynamics approach to show how open systems evolve.
+
* Network Transport:
 +
** Physical Interoperability and  
 +
** Connectivity and Network Interoperability;
  
−
The enablers of openness include open standards and open specifications, which draw from consensus amongst a community of interest, and are published by and freely available within that community. An open specification should be at a level of detail sufficient to be implementable by independent parties. Compliance with open standards is intended to ensure consistent results (Henshaw, et. al., 2011).  These support the notion of open systems architecture, which is an open specification of the architecture of a system or system of systems for the purpose of acquiring specified capabilities. As a general feature of good design (for a system or system of systems), an open system architecture should allow for easy improvement and update of system capabilities by adding or changing components.
+
* Information Services:
 +
** Data/Object Model Interoperability,  
 +
** Semantic/Information Interoperability, and  
 +
** Knowledge/Awareness of Actions Interoperability; and  
  
−
==Networks and network analysis==
+
* People, Processes and Applications:
−
Because networks are such a common component of SoS, they warrant specific attention.  In those SoS based on an underlying network, communications and information exchange typically constitute a SoS in its own right.  This enabling SoS requires architecting like any other SoS as discussed across this section. In the case of an enabling network SoS, the ‘user’ the end-to-end functionality of the larger SoS and enabling network SoS is driven by these user needs. The relationship between SoSE concepts and network enablement has been explored extensively by the defense community, and the concepts of networks and network analysis extend beyond information sharing (Dickerson and Mavris 2009). For instance in U.S. Navy work on C4ISR as part of a SoS (Owens 1996) the term ''network'' included organizational aspects of C2 structure as well as communications.  
+
** Aligned Procedures,  
 +
** Aligned Operations,  
 +
** Harmonized Strategy/Doctrine, and  
 +
** Political or Business Objectives.  
  
−
Differences in architecting of enabling network SoS derive from the fact that these SoS are typically built on commercial technologies and architectures, and these are changing rapidly in today’s dynamic technological environment. In addition, these enabling networks are often shared among SoS and hence may further constrain the overall SoS architecture. For example, many SoS (for cost and convenience) expect to operate over the internet, and hence must consider characteristics of the internet in the expectations for performance and security provided by use of a shared enabling infrastructure.
+
This spectrum of interoperability layers requires appropriate coherence at each layer consistent with the SoS shared goals.
 +
 +
There exist interoperability frameworks in other fields of activity. An example is the European Interoperability Framework (European Commission 2004), which focuses on enabling business (particularly e-business) interoperability and has four levels within a political context:
 +
*  Legal Interoperability,
 +
* Organizational Interoperability,  
 +
*  Semantic Interoperability, and  
 +
*  Technical Interoperability.  
  
−
Enabling network SoS architecting is particularly well served by up-front analyses to explore sensitivities through modeling, simulation, analysis, and/or lab experimentation to identify scalability issues or knees in the curve (e.g., concerning requirements or usage assumptions, assumed network bandwidth, or others) beyond which performance starts to break down. This type of analysis provides a basis for the network architecture decisions.
+
The interoperability between the component systems of a SoS is a fundamental design consideration for SoS that may be managed through the application of standards.
  
−
In directed SoS, because of the top down control, there is the option for creating a specialized network for the particular SoS.  In the other types of SoS, if the constituents are already supported by some type of a network then the overall SoS networking approach typically needs to accommodate these since the constituent systems are likely to need to continue to use their current approach to support their original users.
+
==References==
  
−
==[[Interoperability (glossary)|Interoperability]]==
+
===Works Cited===
−
Interoperability within a SoS implies that each system can communicate and interact (control) with any other system regardless of their hardware, software characteristics or nature. This implies that each constituent member (and potential new members)  of a SoS should be able to communicate with others without compatibility issues such as operating systems, communication hardware, and so on. For this purpose, a SoS needs a common language the SoS’s systems can speak.   Integration also implies the control aspects of the SoS because systems need to understand each other in order to take commands or signals from other SoS systems (Cloutier et. al. 2009). Challenges here are to work towards a common language for exchange of information and data among systems of a SoS. Examples of such system are XML (eXtensible Markup Language), as one potential environment (Jamshidi, 2009a).
+
Abel, A., and S. Sukkarieh. 2006. "The Coordination of Multiple Autonomous Systems using Information Theoretic Political Science Voting Models." Proceedings of the IEEE International Conference on System of Systems Engineering, April 24-26, 2006, Los Angeles, CA, USA.
  
−
However, interoperability must be achieved at many levels and not just at the data network level.  There are a number of frameworks that describe the levels of interoperability. From military applications, the NCOIC (Network Centric Operations Industry Consortium) Interoperability Framework (NCOIC 2008) covers three broad levels of interoperability, subdivided into nine more detailed levels:
+
Azani, C. 2009. ''A Multi-criteria Decision Model for Migrating Legacy System Architectures into Open Systems and Systems-of-Systems Architectures.'' Washington, DC, USA: Defense Acquisition University.
  
−
*Network Transport
+
Azarnoush, H., B. Horan, P. Sridhar, A.M. Madni, and M. Jamshidi. 2006. "Towards optimization of a real-world robotic-sensor system of systems". Proceedings of the World Automation Congress (WAC), July 24-26, 2006, Budapest, Hungary.
−
**Physical interoperability
 
−
**Connectivity and network interoperability
 
−
*Information Services
 
−
**Data/object model interoperability
 
−
**Sematic/information interoperability
 
−
**Knowledge/awareness of actions interoperability
 
−
*People, Processes and Applications
 
−
**Aligned procedures
 
−
**Aligned operations
 
−
**Harmonized strategy/doctrine
 
−
**Political or business objectives
 
−
This  spectrum of interoperability levels requires appropriate coherence at each level consistent with the SoS shared goals.
 
  
−
There exist interoperability frameworks in other fields of activity. An example is the European Interoperability Framework (European Commission 2004), which focuses on enabling business (paricularly e-business) interoperability and has four levels within a context:
+
Cloutier, R.M., J. DiMario, and H.W. Polzer. 2009. "Net-Centricity and System of Systems," in ''Systems of Systems Engineering - Principles and Applications'', edited by M. Jamshidi. Boca Raton, FL, USA: CRC Press.
−
*Political context
 
−
**Legal interoperability
 
−
**Organizational interoperability
 
−
**Semantic interoperability
 
−
**Technical interoperability
 
  
−
The interoperability between the systems of a SoS is a fundamental design consideration for SoS that may be managed through the application of standards.
+
Dagli, C.H., and N. Kilicay-Ergin. 2009. "System of Systems Architecting," in ''Systems of Systems Engineering - Principles and Applications'', edited by M. Jamshidi. Boca Raton, FL, USA: CRC Press.
 +
 +
Dickerson, C.E., and D. Mavris. (2009) ''Architecture and Principles of Systems Engineering''. New York, NY, USA: CRC Press, Auerbach Publications.
  
−
==Standards==
+
DoD. 1998. ''Levels of Information System Interoperability''. Washington, DC, USA: C4IST Interoperability Working Group, US Department of Defense.
−
There are currently no [[Systems Engineering Standards|standards]] specifically written for SoS or SoSE products, processes, management, or other endeavours (Johnson 2009); however, there are many standards which address aspects of interoperability relevant to SoS. The term, ''standard'', has a both general and specific meaning within the realm of contemporary standards. In general, a standard represents a document produced by a standards body, organization, or entity.  A specific standard represents either a part of a document or the whole document that is required, recommended, or permitted to be used as practices, processes, formats, contents, etc.  
 
  
−
Much of the current work in SoS is being done in engineering and acquisition; within engineering the concept of a universally agreed-upon set of guidelines for interoperability is important. Such guidelines provide four levels of standardization: compatibility, interchangability, commonality, and reference (Johnson 2009), which are relevant to the SoS environment through the creation of compatability, similarity, measurement, and symbol and ontological standardization. As the various disciplines relevant to SoS mature, standards will be required to ensure these four levels of the SoS Standardization are met (Jamshidi 2009b).
+
Hall, J. 2007. "Openness – An Important Principle For The Stewardship of DoD IT Standards." ''DSPO Journal'', 4-7. Available: http://www.dsp.dla.mil/app_uil/content/newsletters/journal/DSPJ-01-07.pdf.
  
−
Future standards for SoS will most likely mimic current systems oriented standards by incorporating extensions for SoS perspectives and needs.  An important need for systems is adaptability, and this will be even more important for SoS due to the uncertainties, technologies, systems, stakeholders, organizations, and other entities that may be a part of future evolution of the SoS. The other key area of standardization is interoperability and one effort to provide a semantic and syntactic interoperability standard is the development by US DoD C4ISR organization’s ''Levels of Information System Interoperability'' (DoD 1998).
+
Henshaw, M. (ed.). 2011. ''Assessment of open architectures within defence procurement issue 1: systems of systems approach community forum working group 1 - open systems and architectures.'' London, UK: SoSA Community Forum Working Group 1 (Crown owned copyright). Available: https://dspace.lboro.ac.uk/2134/8828.
  
−
Standard approaches to modeling and simulating systems, processes, interactions, and other SoS activities are an important area in which standards for SoS may evolve.  Model-based standards (ref) may also be a significant area of future development in this topic.
+
Hitchins, D.K. 2003. ''Advanced Systems Thinking, Engineering and Management''. Norwood, MA, USA: Artech House, Inc.
  
−
Overall,  open standards are viewed as an effective way to reduce the risks associated with lack of interoperability in SoS. An open standard is standard that is consensus-based amongst a community of interest, and is published by and freely available within that community of interest (Henshaw et. al 2011).  This has been emphasized in the software domain, for instance (Hall 2007) as a strategy for DoD to adopt open IT standards and to influence these appropriately through participation in relevant standards developing organizations and/or standards setting organizations in the area of information and communications technologies.
+
IEEE. 1990. IEEE 610.12-1990, ''Standard Glossary of Software Engineering Terminology''. Washington, DC, USA: Institute of Electrical & Electronics Engineers (IEEE).
  
−
==References==
+
Jamshidi, M. (ed.) 2009. ''Systems of Systems Engineering - Principles and Applications''. Boca Raton, FL, USA: CRC Press.
  
−
===Works Cited===
+
Johnson M. 2009. "System of Systems Standards," in ''System of Systems Engineering - Innovations for the 21st Century''. Hoboken, NJ, USA: Wiley.  
−
Abel A. and Sukkarieh S. 2006. The Coordination of Multiple Autonomous Systems using Information Theoretic Political Science Voting Models. Proc. IEEE International Conference on System of Systems Engineering, 24-26 April, Los Angeles.
 
  
−
Azani Cyrus. 2009. ''A Multi-criteria Decision Model for Migrating Legacy System Architectures into Open Systems and Systems-of-Systems Architectures.'' Washington, DC, USA:Defense Acquisition University.
+
Lopez D. 2006. "Lessons Learned From the Front Lines of the Aerospace." Proceedings of the IEEE International Conference on System of Systems Engineering, April 24-26, 2006, Los Angeles, CA, US.
  
−
Azarnoush H, Horan B, Sridhar P, Madni A M, and Jamshidi M. (2006) Towards optimization of a real-world robotic-sensor system of systems. In Proc World Automation Congress (WAC), July 24-26. Budapest, Hungary.
+
Mittal, S. 2000. "DEVS Unified Process for Integrated Development and Testing of Service Oriented Architectures." PhD Dissertation. Tucson, AZ, USA: University of Arizona.
  
−
Cloutier R M., DiMario J. and Polzer H W. 2009. Net-Centricity and System of Systems. Chapter in (Jamshidi 2009a)
+
NCOIC. 2008. "NCOIC Interoperability Framework (NIF(R))." Available: http://www.ncoic.org/technology/technical-products/frameworks/10-technology/33-tech-prod-framework-nif.
  
−
Dickerson C E. and Mavris D. (2009) ''Architecture and Principles of Systems Engineering''. New York, NY, USA:CRC Press, Auerbach Publications.
+
Owens, W.A. 1996. ''The Emerging U.S. System-of-Systems''. Washington, DC, USA: The National Defense University, Institute of National Security Studies.
  
−
DoD. 1998. Levels of Information System Interoperability. Washington, DC, USA: C4IST Interoperability Working Group, US Department of Defense.
+
Rebovich Jr., G. 2009. "Chapter 6: Enterprise System of Systems," in ''Systems of Systems Engineering - Principles and Applications.'' Boca Raton, FL, USA: CRC Press. p. 169.
  
−
Hall Jim. 2007. Openness – An Important Principle For The Stewardship of DoD IT Standards. Assistant Deputy Under Secretary of Defense (LMR/LPS), and DoD Standards Executive, in ''DSPO Journal'' pg. 4-7, Mar/Jan. http://www.dsp.dla.mil/app_uil/content/newsletters/journal/DSPJ-01-07.pdf
+
Sahin, F., M. Jamshidi, and P. Sridhar. 2007. "A Discrete Event XML based Simulation Framework for System of Systems Architectures." Proceedings of the IEEE International Conference on System of Systems, April 16-18, 2007, San Antonio, TX, USA.
  
−
Henshaw Michael J D. 2011. Assessment of Open Architectures within Defence Procurement. '''(need complete ref)'''
+
US Department of Defense. 2008. ''Systems Engineering Guide for Systems of Systems,'' version 1.0. Washington, DC, USA: US Department of Defense.
  
−
Hitchins DK. 2003. ''Advanced Systems Thinking, Engineering and Management''. Norwood, MA, USA: ARTECH HOUSE, INC. (ISBN 1-58053-691-0).
+
Wells, G.D., and A.P. Sage. 2008. "Engineering of a System of Systems," in ''Systems of Systems Engineering - Principles and Applications.'' Boca Raton, FL, USA: CRC Press.
  
−
IEEE. 1990. Standard Glossary of Software Engineering Terminology, Std 610.12-1990. Washington, DC: Institute of Electrical & Electronics Engineers (IEEE).  (ISBN 1-55937-067-X).
+
Wojcik, L.A., and K.C. Hoffman. 2006. "Systems of Systems Engineering in the Enterprise Context: A Unifying Framework for Dynamics." Proceedings of the IEEE International Conference on System of Systems Engineering, April 24-26, 2006, Los Angeles, CA, USA.
  
−
Jamshidi, Mo (ed.) 2009b. ''Systems of Systems Engineering - Principles and Applications''. Boca Raton, FL, USA:CRC Press. (ISBN 978-1-4200-6588-6)
+
Zachmann, J. 1987. "A framework for information systems architecture." ''IBM Systems Journal''. 26 (3).
  
−
Johnson Mark. 2009. System of Systems Standards. In (Jamshidi 2009a.)
+
Zeigler, B.P., T.G. Kim, and H. Praehofer. 2000. ''Theory of Modeling and Simulation''. New York, NY, USA: Academic Press.
  
−
Lopez D. 2006. Lessons Learned From the Front Lines of the Aerospace. In Proc. IEEE International Conference on System of Systems Engineering. 24-26 April. Los Angeles, US.
+
===Primary References===
  
−
Mittal S. 2000b. DEVS Unified Process for Integrated Development and Testing of Service Oriented Architectures. Ph. D. Dissertation, Univ. Arizona.
+
Chen, D., G. Doumeingts, F. Vernadat. 2008. "[[Architectures for Enterprise Integration and Interoperability]]: Past, Present and Future." ''Comput.Ind''. 59 (7):647-659.  
  
−
NCOIC. 2008. NCOIC Interoperability Framework (NIF(R)). https://www.ncoic.org/technology/deliverables/nif/
+
Maier, M.W. 1998. "[[Architecting Principles for Systems-of-Systems]]." ''Systems Engineering.'' 1 (4): 267-284.
  
−
Owens W A. (1996) The Emerging U.S. System-of-Systems. In The National Defense University, Institute of National Security Studies, Number 63, Washington D.C. February.
+
===Additional References===
 +
Dickerson, C.E., S.M. Soules, M.R. Sabins, and P.H. Charles. 2004. ''Using Architectures for Research, Development, and Acquisition''. Washington, DC, USA: Office of the Assistant Secretary of The Navy (Research Development And Acquisition). ADA427961. Available: http://handle.dtic.mil/100.2/ADA427961.
  
−
Rebovich Jr. George. 2009. Enterprise System of Systems, in (Jamshidi 2009b), chapter 6, pg. 169.
+
European Commission. 2010. "Annex to the Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Region," in ''Towards interoperability for European public services.'' Available: http://ec.eupora.eu/isa/strategy/doc/annex_ii_eif_en.pdf
  
−
Sahin F, Jamshidi M, and Sridhar P. 2007. A Discrete Event XML based Simulation Framework for System of Systems Architectures. Proc IEEE International Conference on System of Systems, 16-18 April. San Antonio, TX, US.
+
Giachetti, R.E. 2010. ''Design of Enterprise Systems, Theory, Architecture, and Methods''. Boca Raton, FL, USA: CRC Press.
−
 
+
−
Wells G. D. and A. P. Sage 2008. Engineering of a System of Systems (in Jamshidi 2009b) 
+
Rhodes, D.H., A.M. Ross, and D.J. Nightingale. 2010. "Architecting the System of Systems Enterprise: Enabling Constructs and Methods from the Field of Engineering Systems." IEEE International Systems Conference, March 23-26, 2009, Vancouver, Canada.
−
 
 
−
Wojcik L A and Hoffman K C. 2006. Systems of Systems Engineering in the Enterprise Context: A Unifying Framework for Dynamics. Proc. IEEE International Conference on System of Systems Engineering, 24-26 April. Los Angeles, CA, US.
 
−
 
 
−
Zachmann J. 1987. A framework for information systems architecture. ''IBM SYSTEMS JOURNAL'', 26(3).
 
−
 
 
−
Zeigler B P, Kim T G, and Praehofer H. 2000a. Theory of Modeling and Simulation. New York, NY, USA: Academic Press, .
 
  
−
===Primary References===
+
MITRE. 2012. "Architectures Federation," in ''Systems Engineering Guide.'' Bedford, MA, USA: MITRE Corporation. Accessed September 11, 2012. Available: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/engineering_info_intensive_enterprises/architectures_federation.html.
  
 +
Mittal, S. 2000. "Extending DoDAF to Allow DEVS-Based Modeling and Simulation." ''Journal of Defense Modeling and Simulation (JDMS).'' 3 (2).
  
−
Chen D, Doumeingts G, Vernadat F. 2008. Architectures for enterprise integration and interoperability: Past, present and future. ''Comput.Ind''. 9;59(7):647-659.
+
Valerdi R., E. Axelband, T. Baehren, B. Boehm, and D. Dorenbos. 2008. "A research agenda for systems of systems architecting." ''International Journal of System of Systems Engineering''. 1 (1-2): 171-188.
−
*The paper defines and clarifies basic concepts of enterprise architectures. Then an overview on architectures for enterprise integration developed since the middle of the 1980s is presented. The main part of the paper focuses on the recent developments on architectures for enterprise interoperability. The main initiatives and existing works are presented. Future trends and some research issues are discussed and conclusions are given at the end of the paper.
 
  
−
Maier, M W. 1998. Architecting Principles for Systems-of-Systems. ''Systems Eng'' 1(4): 267-284.
+
Zeigler, B.P., D. Fulton, P. Hammonds, and J. Nutaro. 2000. "Framework for M&S–Based System Development and Testing in a Net-Centric Environment." ''ITEA Journal of Test and Evaluation''. 26 (3): 21-34.
−
*This is the paper in which the five characteristics of, or criteria for, Systems of Systems are defined.  It is the most frequently cited paper for SoS definition.
 
  
−
===Additional References===
 
−
Dickerson C E., Soules S M., Sabins M R. and Charles P H. (2004) Using Architectures for Research, Development, and Acquisition. Office of the Assistant Secretary of The Navy (Research Development And Acquisition) Washington DC. (ADA427961). http://handle.dtic.mil/100.2/ADA427961
 
−
 
−
European Commission. 2010. Annex to the Communication from the Commission to the European Parliment, the Council, the European Economic and Social Committee and the Committee of Regions ''Towards interoperability for European public services.''http://ec.eupora.eu/isa/strategy/doc/annex_ii_eif_en.pdf
 
−
 
−
Giachetti R E. 2010. ''Design of Enterprise Systems, Theory, Architecture, and Methods''. Boca Raton, FL, USA: CRC Press,
 
−
 
−
Mittal S. 2000a. Extending DoDAF to Allow DEVS-Based Modeling and Simulation.  ''J. Defense Modeling and Simulation JDMS,'' 3(2).
 
−
 
−
Zeigler B P,  Fulton D, Hammonds P, and Nutaro J. 2000.  Framework for M&S–Based System Development and  Testing in a Net-Centric Environment. ''ITEA Journal of Test and Evaluation''. 26(3), 21-34.
 
 
----
 
----
−
<center>[[Systems of Systems (SoS)|<- Previous Article]] | [[Systems of Systems (SoS)|Parent Article]] | [[Socio-Technical Features of Systems of Systems|Next Article ->]]</center>
+
<center>[[Systems of Systems (SoS)|< Previous Article]] | [[Systems of Systems (SoS)|Parent Article]] | [[Socio-Technical Features of Systems of Systems|Next Article >]]</center>
  
 
[[Category: Part 4]][[Category:Topic]]
 
[[Category: Part 4]][[Category:Topic]]
−
 
−
 
−
{{5comments}}
 
 
[[Category:Systems of Systems (SoS)]]
 
[[Category:Systems of Systems (SoS)]]
 +
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>

Latest revision as of 21:57, 18 November 2023

Lead Authors: Judith Dahmann, Bud Lawson, Mike Henshaw

A key part of systems engineeringsystems engineering (SE) for system of systemssystem of systems (SoS) is the composition of systems to meet SoS needs. This may include simply interfacing systems and leveraging their existing functionality or it may require changing the systems functionality, performance or interfaces. These changes occur incrementally, as a SoS evolves over time to meet changing SoS objectives. System of Systems Engineering (SoSE) supports these changes by developing and evolving a technical framework that acts as an overlay to the systems of which the SoS is composed. This framework provides the architecture for the SoS. The SoS architecture defines how the systems work together to meet SoS objectives and considers the details of the individual systems and their impact the SoS performance or functionality.

The Role of System of Systems Architecting

An architecturearchitecture is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time (IEEE 610.12-1990).

In a SoS, the architecture is the technical framework for the systems comprising the SoS which designates how the systems will be employed by the users in an operational setting (sometimes called the concept of operationsconcept of operations (CONOPs or CONOPs), the internal and external relationships and dependencies among the constituent systems and their functions and, finally, the end-to-end functionality and data flow as well as communications among the systems.

Because SoS largely comprise extant independent systems, these place constraints on the SoS architecture and may require that migration to a SoS architecture be incremental. Developing a SoS architecture requires consideration of technical feasibility for the constituent systems as well as the needs of the SoS itself. Architecture data for the constituent systems can also be important data for architecting the SoS. There is some similarity here to the introduction of Commercial Off The Shelf (COTS) products into systems: the COTS product has been independently managed but sufficient data is required by the systems developer to ensure satisfactory integration. However, in this case the COTS product is not independently operated

Maier (1998) provides a conceptual discussion on the impact of SoS characteristics on SoS architecting. Additionally, the US DoD SE Guide for SoS (2008) describes practical considerations in developing and evolving a SoS architecture as a core element of SoSE.

Challenges in Architecting SoS

In the case of a new system development, the systems engineer can begin with a fresh, unencumbered approach to architecture. However, in a SoS, the systems contributing to the SoS objectives are typically in place when the SoS is established and the SoS engineer needs to consider the current state and plans of the individual systems as factors in developing an architecture for the SoS. This, along with the fact that constituent systems may be complex systems in their own right, leads to a set of challenges to architecting SoS. The approach to architecting must be determined by the type of SoS under consideration. Whereas a directed SoS can be architected in much the same way as a monolithic system, the other types are less straightforward, because the SOI may be less clearly defined and because the SoS architects knowledge of the constituent systems may be partial. Furthermore, whereas in a directed SoS the owner may have authority and funding to require architectural changes of constituent systems, in acknowledged and collaborative SoS re-architecting is at the discretion of the owners of the constituent systems. Maier (Maier 1998) has focused architecting attention on communication for SoS, arguing that this is the common feature of all types, and he partitions the communication into layers that have a similarity to the layers of interoperability (NCOIC, 2008).

The independence of the constituent systems means that these systems are typically not designed to optimize SoS objectives. It may even be the case that a constituent system should operate sub-optimally at the system level in order to achieve overall SoS effectiveness. (Rebovich 2009) has articulated this difficulty as a fundamental problem of 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 (sic) SoS seen as a net gain from the viewpoint of single-system stakeholders.

The development and implementation of a SoS architecture may be significantly constrained by a reluctance to make changes or invest in the constituent systems, which could be very mature (e.g. in sustainment) or currently productively supporting other uses. In this case, approaches such as gateways and wrapping may be used to incorporate these systems into the SoS without making significant changes in the other systems.

Architecture Analysis

Large-scale systems integration has grown in importance and correspondingly, there has been a growing interest in SoS concepts and strategies. The performance and functioning of groups of heterogeneous systems has become the focus of various applications including military, security, aerospace, distributed energy, healthcare, and disaster management systems (Lopez 2006; Wojcik and Hoffman 2006). There is an increasing interest in exploiting synergy between these independent systems to achieve the desired overall system performance (Azarnoush et al. 2006).

Modeling and simulation is conducted to analyze architecture effectiveness and to verify architectural features. In the literature, researchers have addressed the issues of coordination and interoperabilityinteroperability in a SoS (Abel and Sukkarieh 2006; Sahin et al. 2007). In order to study SoS characteristics and parameters, one needs to have realistic simulation frameworks properly designed for system of systems architecture. There are some attempts to develop simulation frameworks for multi-agent systems using Discrete Event Simulation (DEVS) tools (Zeigler et al. 2000a). In these research efforts, the major focus is given to DEVS architecture with JAVA. In (Mittall 2000), DEVS state machine approach is introduced. Finally, DEVS Modeling Language (DEVSML) is developed by using XML based JAVA in order to simulate systems in a net-centric way with relative ease. Sahin et al. (2007) have recently introduced a discrete event XML based SoS simulation framework based on DEVS and JAVA.

The Open Approach to SoS Engineering

As noted above, one of the key challenges with SoS architecting is that the constituent systems of a SoS may not have been designed, developed and employed with regard to their role in the SoS, which constrains SoS architecture options. The degree to the architecture which overlays these constituent systems and supports the SoS end-to-end capabilities can be based on open standards; the SoS may be able to benefit from open architecture for future evolution.

The critical challenge of moving from SoS, as a concept to the engineering of SoS, is the significant technological, human, and organizational differences in consideration system of systems engineering and management approaches (Wells and Sage 2008). A potential approach to engineering a SoS can be the open systems approach to SoSE (Azani 2009). The following open systems principles are listed by Azani (2009):

  • Open interface principle - Open systems have permeable boundaries that allow them to exchange mass, energy, and information with other systems;
  • Synergism principle – The notion that designates that the co-operative interaction between constituent systems has a greater effect in their combined efforts than the sum of their individual parts. Essentially, this is what gives rise to emergence;
  • Self-government principle - This implies that the SoS maintains and develops its internal order without interference from external sources. This could be through cybernetic control, homeostasis, or self-organization;
  • Emergence principle - In this case, this refers to the occurrence of novel and coherent structures, patterns, and properties during the self-organization of the SoS;
  • Conservation principle – This principle states that energy and mass (material) are conserved within the SoS;
  • Reconfiguration principle – This refers to the SoS reconfiguring and adapting itself to sustain itself against changes in its environment;
  • Symbiosis principle - The systems within the SoS have a symbiotic relationship to each other; more transparently, the successful development and sustainment of a SoS depends on symbiotic collaboration between the stakeholders of the systems of which it is comprised; and
  • Modularity principle - This holds that each level and each system is to some extent independent of others. In SoS design, the development of independent modular systems that interoperate with each other through standardized interfaces enables greater flexibility to promote better evolution of the SoS.

Azani (2009) elaborates on the open systems development strategies and principles utilized by biotic SoS, discusses the implications of engineering of man-made SoS, and introduces an integrated SoS development methodology for the engineering and development of an adaptable, sustainable, and interoperable SoS based on open systems principles and strategies.

Hitchens (2003, 107), on the other hand, discusses the principles of open systems rather differently in terms of their systems life cycles, as the seven principles that he addresses are system reactions, system cohesion, system adaptation, connected variety, limited variety, preferred patterns, and cyclic progression. This description takes a systems dynamics approach to show how open systems evolve; the description is applicable to natural and man-made systems.

The enablers of openness include open standards and open specifications, which draw from consensus amongst a community of interest, and are published by, and freely available within, that community. An open specification must ensure that its detail-level is allows for it to be implementable by independent parties. Compliance with open standards is intended to ensure consistent results (Henshaw, et. al., 2011). This parallels the notion of open systems architecture, which is an open specification of the architecture of a system or system of systems for the purpose of acquiring specified capabilities. As a general feature of good design (for a system or system of systems), an open system architecture should allow for the quick and easy improvement and updating of the system capabilities, by adding or changing components. However, Henshaw et. al. (2011) also denote that open architecture represents a commercial challenge (rather than a technical one) and that establishing open architecture approaches to acquisition can be challenging, due to issues involving protection of intellectual property (IP) and commercial advantage.

Networks and Network Analysis

Because networks are such a common component of SoS, they warrant specific attention. In SoS that are based on an underlying network, communications and information exchange typically constitute a SoS in its own right. This enabling SoS requires architecting like any other SoS, which will be addressed in this section. In the case of an enabling network SoS, the ‘user’, the end-to-end functionality of the larger SoS and enabling network SoS is driven by these user needs. The relationship between SoSE concepts and network enablement, as well as the concepts of networks and network analysis that extend beyond information sharing, have been explored extensively by the defense community (Dickerson and Mavris 2009). For instance, during the U.S. Navy’s work on command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) as part of a SoS (Owens 1996), the term network included organizational aspects of command and control (C2) structure as well as communications.

Differences in the architecting of an enabling network SoS derive from the fact that these SoS are typically built on commercial technologies and architectures, which are changing rapidly in today’s dynamic technological environment. In addition, these enabling networks are often shared among SoS and hence may further constrain the overall SoS architecture. For example, many SoS (for cost and convenience) expect to operate over the internet, and therefore must consider characteristics of the internet in the expectations for performance and security provided by use of a shared enabling infrastructure.

Enabling network SoS architecting is particularly well-served by the initial analysis that explores sensitivities through modeling, simulation, analysis, and/or laboratory experimentation and identifies scalability issues or divergent behavior (e.g., concerning requirements or usage assumptions, assumed network bandwidth, or others), beyond which performance starts to break down. This type of analysis provides a basis for network architecture decisions.

In directed SoS, because of the top-down control, there is the option for creating a specialized network for the particular SoS. In the other types of SoS, if the constituents are already supported by some type of a network then the overall SoS networking approach typically needs to accommodate these since the constituent systems are likely to need to continue to use their current approach to support their original users.

Interoperability

InteroperabilityInteroperability within a SoS implies that each system can communicate and interact (control) with any other system regardless of their hardware and software characteristics or nature. This implies that each constituent member (and potential new members) of a SoS should be able to communicate with others without compatibility issues in the operating systems, communication hardware, and so on. For this purpose, a SoS needs a common language the SoS’s systems can speak. Challenges here are to work towards a common language for exchange of information and data among systems of a SoS. Examples of such system are XML (eXtensible Markup Language), as one potential candidate (Jamshidi, 2009a).

However, interoperability must be achieved at many levels and not just at the data/network level. There are a number of frameworks that describe the levels of interoperability. From military applications, the NCOIC (Network Centric Operations Industry Consortium) Interoperability Framework (NCOIC 2008) covers three broad levels of interoperability, subdivided into further layers as indicated below:

  • Network Transport:
    • Physical Interoperability and
    • Connectivity and Network Interoperability;
  • Information Services:
    • Data/Object Model Interoperability,
    • Semantic/Information Interoperability, and
    • Knowledge/Awareness of Actions Interoperability; and
  • People, Processes and Applications:
    • Aligned Procedures,
    • Aligned Operations,
    • Harmonized Strategy/Doctrine, and
    • Political or Business Objectives.

This spectrum of interoperability layers requires appropriate coherence at each layer consistent with the SoS shared goals.

There exist interoperability frameworks in other fields of activity. An example is the European Interoperability Framework (European Commission 2004), which focuses on enabling business (particularly e-business) interoperability and has four levels within a political context:

  • Legal Interoperability,
  • Organizational Interoperability,
  • Semantic Interoperability, and
  • Technical Interoperability.

The interoperability between the component systems of a SoS is a fundamental design consideration for SoS that may be managed through the application of standards.

References

Works Cited

Abel, A., and S. Sukkarieh. 2006. "The Coordination of Multiple Autonomous Systems using Information Theoretic Political Science Voting Models." Proceedings of the IEEE International Conference on System of Systems Engineering, April 24-26, 2006, Los Angeles, CA, USA.

Azani, C. 2009. A Multi-criteria Decision Model for Migrating Legacy System Architectures into Open Systems and Systems-of-Systems Architectures. Washington, DC, USA: Defense Acquisition University.

Azarnoush, H., B. Horan, P. Sridhar, A.M. Madni, and M. Jamshidi. 2006. "Towards optimization of a real-world robotic-sensor system of systems". Proceedings of the World Automation Congress (WAC), July 24-26, 2006, Budapest, Hungary.

Cloutier, R.M., J. DiMario, and H.W. Polzer. 2009. "Net-Centricity and System of Systems," in Systems of Systems Engineering - Principles and Applications, edited by M. Jamshidi. Boca Raton, FL, USA: CRC Press.

Dagli, C.H., and N. Kilicay-Ergin. 2009. "System of Systems Architecting," in Systems of Systems Engineering - Principles and Applications, edited by M. Jamshidi. Boca Raton, FL, USA: CRC Press.

Dickerson, C.E., and D. Mavris. (2009) Architecture and Principles of Systems Engineering. New York, NY, USA: CRC Press, Auerbach Publications.

DoD. 1998. Levels of Information System Interoperability. Washington, DC, USA: C4IST Interoperability Working Group, US Department of Defense.

Hall, J. 2007. "Openness – An Important Principle For The Stewardship of DoD IT Standards." DSPO Journal, 4-7. Available: http://www.dsp.dla.mil/app_uil/content/newsletters/journal/DSPJ-01-07.pdf.

Henshaw, M. (ed.). 2011. Assessment of open architectures within defence procurement issue 1: systems of systems approach community forum working group 1 - open systems and architectures. London, UK: SoSA Community Forum Working Group 1 (Crown owned copyright). Available: https://dspace.lboro.ac.uk/2134/8828.

Hitchins, D.K. 2003. Advanced Systems Thinking, Engineering and Management. Norwood, MA, USA: Artech House, Inc.

IEEE. 1990. IEEE 610.12-1990, Standard Glossary of Software Engineering Terminology. Washington, DC, USA: Institute of Electrical & Electronics Engineers (IEEE).

Jamshidi, M. (ed.) 2009. Systems of Systems Engineering - Principles and Applications. Boca Raton, FL, USA: CRC Press.

Johnson M. 2009. "System of Systems Standards," in System of Systems Engineering - Innovations for the 21st Century. Hoboken, NJ, USA: Wiley.

Lopez D. 2006. "Lessons Learned From the Front Lines of the Aerospace." Proceedings of the IEEE International Conference on System of Systems Engineering, April 24-26, 2006, Los Angeles, CA, US.

Mittal, S. 2000. "DEVS Unified Process for Integrated Development and Testing of Service Oriented Architectures." PhD Dissertation. Tucson, AZ, USA: University of Arizona.

NCOIC. 2008. "NCOIC Interoperability Framework (NIF(R))." Available: http://www.ncoic.org/technology/technical-products/frameworks/10-technology/33-tech-prod-framework-nif.

Owens, W.A. 1996. The Emerging U.S. System-of-Systems. Washington, DC, USA: The National Defense University, Institute of National Security Studies.

Rebovich Jr., G. 2009. "Chapter 6: Enterprise System of Systems," in Systems of Systems Engineering - Principles and Applications. Boca Raton, FL, USA: CRC Press. p. 169.

Sahin, F., M. Jamshidi, and P. Sridhar. 2007. "A Discrete Event XML based Simulation Framework for System of Systems Architectures." Proceedings of the IEEE International Conference on System of Systems, April 16-18, 2007, San Antonio, TX, USA.

US Department of Defense. 2008. Systems Engineering Guide for Systems of Systems, version 1.0. Washington, DC, USA: US Department of Defense.

Wells, G.D., and A.P. Sage. 2008. "Engineering of a System of Systems," in Systems of Systems Engineering - Principles and Applications. Boca Raton, FL, USA: CRC Press.

Wojcik, L.A., and K.C. Hoffman. 2006. "Systems of Systems Engineering in the Enterprise Context: A Unifying Framework for Dynamics." Proceedings of the IEEE International Conference on System of Systems Engineering, April 24-26, 2006, Los Angeles, CA, USA.

Zachmann, J. 1987. "A framework for information systems architecture." IBM Systems Journal. 26 (3).

Zeigler, B.P., T.G. Kim, and H. Praehofer. 2000. Theory of Modeling and Simulation. New York, NY, USA: Academic Press.

Primary References

Chen, D., G. Doumeingts, F. Vernadat. 2008. "Architectures for Enterprise Integration and Interoperability: Past, Present and Future." Comput.Ind. 59 (7):647-659.

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

Additional References

Dickerson, C.E., S.M. Soules, M.R. Sabins, and P.H. Charles. 2004. Using Architectures for Research, Development, and Acquisition. Washington, DC, USA: Office of the Assistant Secretary of The Navy (Research Development And Acquisition). ADA427961. Available: http://handle.dtic.mil/100.2/ADA427961.

European Commission. 2010. "Annex to the Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Region," in Towards interoperability for European public services. Available: http://ec.eupora.eu/isa/strategy/doc/annex_ii_eif_en.pdf

Giachetti, R.E. 2010. Design of Enterprise Systems, Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press.

Rhodes, D.H., A.M. Ross, and D.J. Nightingale. 2010. "Architecting the System of Systems Enterprise: Enabling Constructs and Methods from the Field of Engineering Systems." IEEE International Systems Conference, March 23-26, 2009, Vancouver, Canada.

MITRE. 2012. "Architectures Federation," in Systems Engineering Guide. Bedford, MA, USA: MITRE Corporation. Accessed September 11, 2012. Available: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/engineering_info_intensive_enterprises/architectures_federation.html.

Mittal, S. 2000. "Extending DoDAF to Allow DEVS-Based Modeling and Simulation." Journal of Defense Modeling and Simulation (JDMS). 3 (2).

Valerdi R., E. Axelband, T. Baehren, B. Boehm, and D. Dorenbos. 2008. "A research agenda for systems of systems architecting." International Journal of System of Systems Engineering. 1 (1-2): 171-188.

Zeigler, B.P., D. Fulton, P. Hammonds, and J. Nutaro. 2000. "Framework for M&S–Based System Development and Testing in a Net-Centric Environment." ITEA Journal of Test and Evaluation. 26 (3): 21-34.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Architecting_Approaches_for_Systems_of_Systems&oldid=69360"