Discuss requirements and SoS architecture for system of systems.

A system will be called a System of Systems (SoS) when: The component systems achieve well-substantiated requirements by themselves and continue to operate in this way and accomplish these requirements even if detached from the overall system, and The component systems are managed in large part for their own requirements rather than the requirements for the whole. Yet, they function to also resolve requirements of the whole that are generally unachievable by the individual systems acting independently. (Sage, 2005) Its development is evolutionary in the sense that functions and requirements are added, removed, and modified with experience in use of the system. As consequences of this evolutionary development, the resulting SoS will have the property of emergent behaviour whereby it functions and carries out requirements that are not possible by any of the component systems. (Sage, 2005) Requirements are detailed descriptions pertaining to two separate and very different decompositions covering: User needs System makeup and attributes SoS objectives are the genesis of SoS architectures. These objectives are defined by operational stakeholders and provide top-level requirements and constraints for SoS. The requirements should focus on SoS purpose and behaviour in the context of the operational environment and conditions. Scope of a SoS need to be defined before requirements to bound the problem/solution space. The objectives are abstracted into a requirements baseline using a variety of tools such as context view, use cases, activity diagrams and state diagrams during SoS requirements analysis(ML Butterfield, 2008). Operational concepts for the entire life-cycle to be developed for prevention of requirements omissions. With stakeholders involvement from early stage will provide common understanding among the systems. Requirements are assembled from multiple program stakeholders and integrated based on operational strategies and industry standards. Every system within SoS will identify external interface to ensure the system works within the larger SoS. All the SoS requirement developers need to share the same vision to prevent misinterpretations to get needed, clear, concise, and unambiguous requirements. Each requirement rationale is discussed to capture corporate knowledge and limitations imposed by existing systems. A set of measures at the SoS level for each requirement and verification and validation method also identified to ensure verifiableness and reduce review time (Hooks, 2004). The process is an iterative one at each level, assuring that requirements are consistently and validly matched between the SoS level interoperability specifications and available component systems, to best address operational functionality for the stakeholder needs (ML Butterfield, 2008). This coordination must be measured (refer to Figure 1).

Figure 1: Measures of Merit (ML Butterfield, 2008)

Figure 2: SoS V- model (ML Butterfield, 2008)

Requirements are to be responsive to emergent behaviours of the SoS as well as constitutes a distinct identity (unique) and separates it from all others. Since an SoS doesnt have a limited life-

cycle but continues with the evolution of the SoS, its strategic plan also must also evolve. The SoS capabilities must evolve as needs change and new technologies becomes available. These requirements must be provided to all stakeholders so they understand and agree to the requirements before venturing forward, or the risks will be unmanageable (Hooks, 2004). Requirements will be an important aspect of an SoS, as it is to all systems. It is critical to do the pre-requirements work of scope definition, documentation, dissemination, and stakeholder buy-in before the SoS requirements are developed. Each individual system must pay more attention to its defensive and self-healing requirements to participate in future SoS. SoS Architectures The architecture of an SoS represents a persistent technical framework that guides the evolution of an SoS over time (Jamshidi, 2009). Developing and evolving an SoS architecture includes creating and maintaining the SoS concept of operations, determining the systems, their functions, and their relationships and dependencies (both internal and external to the SoS), and establishing an understanding of the end-to-end functionality, data flows, and communications within the SoS (B. John & B. Stephen, 2009). SoS architecting process begins with scoping, aggregation, partitioning, and certification at metalevel (Jamshidi, 2009). It concentrates on selecting the right collection of systems to satisfy the customer requirements. Therefore, the SoS architecting process spans through multiple abstraction layer and domains to foster collaborative functions among independent systems.

Figure 3: The integration of requirements from many sources can be managed using a structured method (ML Butterfield, 2008) A successful SoS architecture will provide the technical framework for assessing the options and implications for meeting SoS requirements over time. It shall have persistence and tolerance for changes.

In the SoS, architecture has more influence on the requirements but SoS environment architectural constraints imposed by existing system can have a major influence on overall capabilities and system behavior (Jamshidi, 2009).

Figure 4: Slomans H-Cogaff architecture, 2000 Different architecting tools are required at high-levels of complexity. The uses of many architecture and interoperability, such as levels of information system interoperability, architecture framework and etc., have missing linkages to SoS (Chen and Clothier, 2003). Specifically, model-centric frameworks and executable models become important tools for SoS analysis and architecting as they provide insights into SoS architecture behavior.

Architecting properties

SoS architectures Abstract, meta-level Fuzzy uncertain requirements Network-centric Software intensive People-intensive Intensive communication infrastructure Network of various stakeholders Collaborative emergent development

Architecting constraints

Dynamic architecture It starts from meta-level Concentrating is on choosing the right collections of system Scalability Interoperability Trustworthiness Hidden cascading failure Confusing life-cycle context Abstraction level determines the integration of legacy systems to other systems Large amount and variety of legacy systems Model centric and executable models Balance to heuristics, analytical and integrated modelling

Legacy systems

Architecting tools

Figure 5: SoS architecting (Jamshidi, 2009) In some situations, the evolution of an SoS begins by improving the way the SoS functions with-out making any explicit architecture changes. SoS exhibits emergent behavior such that it achieves purposes that are not possible by its component subsystems (Sage, 2005). SoS architecture may not be sufficient for true evolutionary development; rather from the SoS architecture as a starting point, the individual systems can be evolved in directions more conducive to the objective SoS, resulting in a second generation SoS architecture that will be evolvable (B. John & B. Stephen, 2009). The common SoS architectures can be detailed as; a) Network-Centric operations This networking, combined with changes in technology, organization, processes, and people may allow new forms of organizational behavior. It is interoperable so that different legacy systems can be integrated into the architecture at various abstraction levels. (Albert, 2000)

Figure 6: The evolving net-centric architecture (Jamshidi, 2009)

b) Dynamically changing meta-architecture

A collection of different complex adaptive systems those are readily available to be plugged into the evolvable net-centric communication. This shift the focus from component and individual system level to meta-level architecting. This plug ann play concept provides flexibility to respond to changing operational and environmental situation. (Jamshidi, 2009)

Figure 7: Dynamically changing meta-architecture for SoS (Dagli and Kilicay, 2007)

Either way, as the architecture of an SoS is employed to increase the capability of the SoS, it will evolve and mature over time thru the result of technical reviews at the SoS level and due to its linkage to specific systems comprising the SoS.

References: Andrew.P.Sage., 2005, System of Systems: Architecture Based Systems design and Integration, IEEE 2005 International Conference on Systems, Man and Cybernetics, October 10-12, Hawaaii, USA. Slide 25. Marion .L Butterfield., 2008, A System-of-System Engineering GEOSS Architectural Approach, IEEE GEOSS Paper, Jan 2008, Copyright 2007 by Boeing, www.ieee-earth.org/files/System-ofSystems_Engineering.pdf , Accessed 2009-10-08. Hooks, Ivy F., 2004, Managing System of Systems Requirements, CROSSTALK, The Journal of Defense Software Engineering, Aug 2004, http://www.stsc.hill.af.mil/crosstalk/2004/08/0408Hooks.html , Accessed 2009-10-06 John Bergey, Stephen Blanchette, Jr., Paul Clements, Mike Gagliardi, John Klein, Rob Wojcik, Bill Wood., 2009, U.S. Army Workshop on Exploring Enterprise, System of Systems, System, and Software Architectures, TECHNICAL REPORT:CMU/SEI-2009-TR-008, Mar 2009, http://www.sei.cmu.edu , Accessed 2009-10-06 Jamshidi, M., 2009, SoS Architecting, System of Systems Engineering, 4(3): 80 - 98.

Chen, P., Clothier, J., Advancing systems engineering for systems-o-systems challenges, Systems Engineering, 6(3): 170-183. Alberts, D.S., Garstka, J.J., Stein, F.P., (2000) Network Centric Warfare: Developing and Leveraging Information Superiority, CCRP Publ., 2nd Edition (Revised). Aug 1999, Second Print Feb 2000 Dagli, C., Kilicay,N ., 2007, Understanding behaviour of system of systems through computational intelligence techniques, CD Proceedings of 1st Annula IEEE Systems Conference, April 9-12, Honolulu, Hawaaii.