by Philip Boxer
The Office of the Secretary of Defense (OSD) has released a Systems Engineering Guide for Systems of Systems. It “addresses SE considerations to meet capability needs through integrating independently useful systems into a larger system that delivers unique capabilities – a system of systems (SoS) – within the Department of Defense”.
The guide references the work on the Pragmatics of Demand as follows:
The architecture of an SoS is somewhat 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. The functionality that the individual systems contribute to the SoS can be described in a functional architecture that puts the key functions in order, thereby sequencing the SoS tasks. An example is the ballistic missile defense end-to-end process through boost, mid-course, and terminal phases of ballistic missile threats which would serve as the framework for this functional process in the case of one SoS. 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 design of the SoS, or the physical architecture that defines the physical components (constituent systems) of which the SoS will be composed. The variability in the execution of these functions in the field also needs to be understood and factored into the SoS architecture [Boxer, 2008].
This version of the document does not go on to describe the methods for analysing this variability, outlined in the work with Thales UK in terms of agility and innovation. However, it does reference the earlier work on the Navigator approach to managing system-of-systems interoperability:
Finally, the SoS systems engineer is challenged to develop approaches to evolve the ensemble of systems to meet new needs while accommodating the independently owned and funded constituent systems, which themselves are often evolving to meet their own system users’ needs. To attain this delicate balance and support decisions that are typically outside of the SE purview, the SoS systems engineer must understand systems and their relationships from multiple perspectives, including technical and organizational relationships. These decisions include analysis of options and trades for SoS design/architecture given current characteristics and development plans of systems; assessments to determine which requirements can be addressed in what time frame given system objectives, funding, and development schedules; and analysis of how internal and external changes will affect the SoS. Several activities, including the Software Engineering Institute’s SoS Navigator initiative, are examining these needs and approaches [Brownsword, Fisher, Morris, Smith & Kirwan, 2006].