Test and Evaluation of Systems of Systems

Definitions: A system of systems (SoS) is "a collection of systems, each capable of independent operation, that interoperate together to achieve additional desired capabilities [1]." Test and evaluation (T&E) is the process by which an SoS and/or its constituents are compared against capability requirements and specifications.

Keywords: systems of systems (SoS), SoS test, SoS test and evaluation, SoS testing, SoS validation, SoS verification

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to understand the characteristics of systems of systems (SoS) and the implications for systems engineering in an SoS environment, including SoS test and evaluation. SEs are expected to develop systems engineering and test and evaluation (T&E) plans for systems that are constituents of SoS as well as for the SoS themselves.


This article addresses the unique aspects of T&E of SoS and outlines strategies and techniques for handling them.

Systems of systems (SoS) differ from traditional systems in several ways. As a result, applying systems engineering to SoS requires that it be tailored to address the characteristics of SoS. Likewise, the distinctive characteristics of SoS have implications for the application of T&E. This discussion specifically addresses "acknowledged SoS," a type of SoS that is growing in significance in the Department of Defense (DoD). Acknowledged SoS have recognized objectives, a designated manager, and resources. However, the constituent systems (those that interoperate with each other to achieve the SoS capabilities) retain their independent ownership, objectives, funding, development, and sustainment approaches. Changes in the constituent systems are based on collaboration among the SoS and the systems levels. SoS raise unique development challenges consequent to the far-reaching SoS capability objectives: the lack of control SoS have over the constituent systems and the dependence of SoS capability on leveraging already fielded systems that address user and SoS needs. Further, SoS are often not formal programs of record. Instead they depend on changes made through acquisition programs or operations and maintenance of fielded systems. As a result, the question addressed here is not simply: How do we implement T&E for SoS? But rather: What does it mean to test and evaluate SoS?

SoS Characteristics Impacting Test and Evaluation

Most of the key differences between systems and acknowledged SoS (Table 1) are a result of the independence of the SoS's constituent systems. The constituent systems may evolve in response to user needs, technical direction, funding, and management control independent of the SoS. Thus, SoS evolve through cooperation among the constituent systems, instead of through direction from a central authority, by leveraging the constituent systems' efforts to improve their own individual capabilities.

Table 1. Comparing Systems and Acknowledged Systems of Systems

Aspect of Environment


Acknowledged System of Systems

Management and Oversight

Stakeholder Involvement

Clearer set of stakeholders.

Stakeholders at both the system level and SoS levels (including system owners), with competing interests and priorities. In some cases, the system stakeholder has no vested interest in the SoS. Not all stakeholders may be recognized.


Aligned program manager and funding.

Added levels of complexity due to management and funding for both the SoS and individual systems. SoS does not have authority over all the systems.

Operational Environment

Operational Focus

Designed and developed to meet operational objectives.

Called on to meet a set of operational objectives using systems whose objectives may or may not align with the SoS objectives.



Aligned to acquisition category milestones, documented requirements, SE.

Added complexity due to multiple systems' life cycles across acquisition programs involving legacy systems, systems under development, new developments, and technology insertion. Typically have stated capability objectives up front, which may need to be translated into formal requirements.

Test and Evaluation

Test and evaluation of the system is generally possible.

More challenging testing due to the difficulty of synchronizing across multiple systems' life cycles, given the complexity of all the moving parts and the potential for unintended consequences.

Engineering and Design Considerations

Boundaries and Interfaces

Focuses on boundaries and interfaces for the single system.

Focus on identifying the systems that contribute to the SoS objectives and enabling the flow of data, control, and functionality across the SoS while balancing the needs of the systems.

Performance and Behavior

Performance of the system to meet specified objectives.

Performance across the SoS that satisfies SoS user capability needs while balancing the needs of the systems.

An SoS will face T&E challenges that stem from the independence of its constituent systems:

  • Independent development cycles mean that systems' upgrades to meet SoS needs are delivered asynchronously and are bundled with other changes to the system in response to other needs (beyond those of the SoS).
  • The number and variability of the systems that influence SoS results mean that large SoS, in particular, are complex and that interactions among the constituents may lead to unintended effects or emergent behavior.

T&E in the SoS Systems Engineering Process

The SoS Guide [1] presents seven core SoS systems engineering elements, four of which are critical to T&E of the SoS. The SoS Guide gives more detail on these elements. This article summarizes their key aspects (Figure 1), showing how T&E activities fit into the SoS systems engineering core elements and what challenges SoS pose for T&E.

Figure 1. SoS Systems Engineering Core Elements and Their Relationships to T&E


  1. Capability objectives of an SoS are often stated at a high level, particularly when the need for an SoS is first established.

Translating capability objectives into high-level SoS requirements is a core element in the SoS systems engineering process. In most cases, SoS capability objectives are framed in high-level language that needs to be interpreted into high-level requirements to serve as the foundation of the engineering process.

"SoS objectives are typically couched in terms of needed capabilities, and the systems engineer is responsible for working with the SoS manager and users to translate these into high-level requirements that provide the foundation for the technical planning to evolve the capability over time" [1, p. 18].

These objectives establish the capability context for the SoS, which grounds the assessment of current SoS performance. In most cases, SoS do not have requirements per se; they have capability objectives or goals that provide the starting point for specific requirements that drive changes in the constituent systems to create increments of SoS evolution.

  1. Requirements are specified at the level of the system for each SoS upgrade cycle.

In the SoS systems engineering core element, "assessing requirements and solution options," managers and systems engineers collaboratively plan increments of SoS improvements at the SoS and system levels. Typically, each increment has specific expectations about system changes that will produce an anticipated overall effect on the SoS performance. Although it may be possible to confidently define specifications for the system changes, it is more difficult to do this for the SoS, which is, in effect, the cumulative result of the changes in the systems.

"It is key for the systems engineer to understand the individual systems and their technical and organizational context and constraints when identifying viable options to address SoS needs and to consider the impact of these options at the systems level. It is the SoS systems engineer's role to work with requirements managers for the individual systems to identify the specific requirements to be addressed by appropriate systems (that is to collaboratively derive, decompose, and allocate requirements to systems)" [1, p. 20].

As a result, most SoS requirements are specified at the system level for each upgrade cycle, which provides the basis for assessing system-level performance. As discussed below, the systems typically perform T&E of system changes as part of their processes.

  1. Systems implement changes as part of their own development processes.

The main source of T&E challenges arises from SoS upgrades that are the product of changes in independent operating systems and in the SoS itself. The SoS systems engineering team needs to work with the systems engineering systems teams to plan and track these systems changes that will contribute to meeting the SoS capability objectives.

"Once an option for addressing a need has been selected, it is the SoS systems engineer's role to work with the SoS sponsor, the SoS manager, the constituent systems' sponsors, managers, systems engineers, and contractors to fund, plan, contractually enable, facilitate, integrate, and test upgrades to the SoS. The actual changes are made by the consistent systems' owners, but the SoS systems engineer orchestrates the process, taking a lead role in the synchronization, integration, and test across the SoS and providing oversight to ensure that the changes agreed to by the systems are implemented in a way that supports the SoS" [1, p. 20].

  1. System-level T&E validates implementation of system requirements.

Consequently, T&E is implemented as part of this element at both the system and SoS levels. It seems fairly straightforward to assess whether the systems have made the changes as specified in the plan, however, it is less clear how the results of these changes at the SoS level are to be tested and evaluated.

"Throughout orchestration, the systems are implementing changes according to the negotiated plans, and they are following their own SE and T&E processes. The SoS systems engineer works with the SE teams of the constituent systems to enable SoS insight into progress of the system developments as laid out in the SoS plan. The SoS SE team members are responsible for integration and for verification and validation of the changes across the suite of system updates under an SoS increment, including T&E tailored to the specific needs of the increments. Their efforts may result in both performance assessments and a statement of capabilities and limitations of the increment of SoS capability from the perspectives of SoS users and users of the individual systems. These assessments may be done in various venues, including distributed simulation environments, system integration laboratories, and field environments. The assessments can take a variety of forms, including analysis, demonstration, and inspection. Often SoS systems engineers leverage system-level activities that are under way in order to address SoS issues" [1, p. 68].

Creating an end-to-end test environment sufficient to address the met needs of the SoS capability has significant challenges. To mitigate them, conduct T&E on a subset of systems prior to fielding the entire SoS increment, though at the expense of some T&E validity. Prepare contingency plans when the SoS's T&E results don't reflect expected improvements in case the systems are ready to be fielded based on system-level test results and owners' needs.

  1. Constituent system development processes are typically asynchronous.

The asynchronous nature of the constituent systems development schedules presents a challenge to straightforward T&E at the SoS level. Although it is obviously desirable to coordinate the development plans of the systems and synchronize the delivery of upgrades, as a practical matter, this is often difficult or impossible. Even when it is possible to plan synchronous developments, the result may still be asynchronous deliveries due to the inevitable issues that lead to development schedule delays, particularly with a large number of systems or when the developments are complex.

"SoS SE approaches based on multiple, small increments offer a more effective way to structure SoS evolution. Big-bang implementations typically will not work in this environment; it is not feasible with asynchronous independent programs. Specifically, several SoS initiatives have adopted what could be termed a "bus stop," spin, or block-with-wave type of development approach. In this type of approach, there are regular time-based SoS "delivery" points, and systems target their changes for these points. Integration, test, and evaluation are done for each drop. If systems miss a delivery point because of technical or programmatic issues, they know that they have another opportunity at the next point (there will be another bus coming to pick up passengers in three months, for instance). The impact of missing the scheduled bus can be evaluated and addressed. By providing this type of SoS battle rhythm, discipline can be inserted into the inherently asynchronous SoS environment. In a complex SoS environment, multiple iterations of incremental development may be under way concurrently.

"Approaches such as this may have a negative impact on certification testing, especially if the item is software related to interoperability and/or safety issues (such as Air Worthiness Release). When synchronization is critical, considerations such as this may require large sections of the SoS, or the entire SoS, to be tested together before any of the pieces are fielded" [1, pp. 68–69].

As these passages indicate, the asynchronous nature of system developments frequently means that other SoS constituents are unprepared to test with earlier delivering systems, complicating end-to-end testing. However, as autonomous entities, constituent systems expect to field based on results of their own independent testing apart from the larger impact on SoS capability. Holding some systems back until all are ready to test successfully is impractical and undesirable in most cases. These dependencies form a core impediment to mapping traditional T&E to SoS.

  1. SoS performance is assessed in various settings.

SoS typically have broad capability objectives rather than specific performance requirements, as is usually the case with independent systems. These capability objectives provide the basis for identifying systems as candidate constituents of an SoS, developing an SoS architecture, and recommending changes or additions to constituent systems.

"In an SoS environment there may be a variety of approaches to addressing objectives. This means that the SoS systems engineer needs to establish metrics and methods for assessing performance of the SoS capabilities which are independent of alternative implementation approaches. A part of effective mission capability assessment is to identify the most important mission threads and focus the assessment effort on end-to-end performance. Since SoS often comprise fielded suites of systems, feedback on SoS performance may be based on operational experience and issues arising from operational settings, including live exercises as well as actual operations. By monitoring performance in the field or in exercise settings, systems engineers can proactively identify and assess areas needing attention, emergent behavior in the SoS, and impacts on the SoS of changes in constituent systems" [1, pp. 18–19].

This suggests the necessity for generating metrics that define end-to-end SoS capabilities for ongoing benchmarking of SoS development. Developing these metrics and collecting data to assess the state of the SoS are part of the SoS systems engineering core element "assessing the extent to which SoS performance meets capability objectives over time." This element provides the capability metrics for the SoS, which may be collected from a variety of settings as input on performance, including new operational conditions [1, p. 43]. Hence, assessing SoS performance is an ongoing activity that goes beyond assessment of specific changes in elements of the SoS.

T&E objectives, particularly key performance parameters, are used as the basis for making a fielding decision. In addition, SoS metrics, as discussed earlier, provide an ongoing benchmark for SoS development which, when assessed over time, should show an improvement in meeting user capability objectives. Because SoS typically comprise a mix of fielded systems and new developments, there may not be a discrete SoS fielding decision; instead, the various systems are deployed as they are ready, at some point reaching the threshold that enables the new SoS capability.

In some circumstances, the SoS capability objectives can be effectively modeled in simulation environments that can be used to identify changes at the system levels. If the fidelity of the simulation is sufficient, it may provide validation of the system changes needed to enable SoS-level capability. In those cases, the fidelity of the simulation may also be able to provide for the SoS evaluation.

In cases where simulation is not practical, other analytical approaches may be used for T&E. Test conditions that validate the analysis must be carefully chosen to balance test preparation and logistics constraints against the need to demonstrate the objective capability under realistic operational conditions.

Best Practices and Lessons Learned

Approach SoS T&E as an evidence-based approach to addressing risk. Full conventional T&E before fielding may be impractical for incremental changes to SoS because systems may have asynchronous development paths. In addition, explicit test conditions at the SoS level may not be feasible due to the difficulty in bringing all constituent systems together to set up meaningful test conditions. Thus, an incremental risk-based approach to identifying key T&E issues is recommended.

For each increment, a risk-based approach identifies areas critical to success and areas that could have adverse impacts on user missions. This is followed by a pre-deployment T&E. Risk is assessed using evidence from a range of sources, including live test. In some circumstances, the evidence can be based on activity at the SoS level; in others, it may be based on roll-ups of activity at the constituent systems level. The activity can range from explicit verification testing, results of models and simulations, use of linked integration facilities, and results of system-level operational test and evaluation.

Finally, these risks must be factored into SoS and system development plans in case the T&E results indicate that the changes will have a negative impact, in which case they can then be discarded without jeopardizing system update deliveries to users. The results could be used to provide end-user feedback in the form of "capabilities and limitations."

Encourage development of analytic methods to support planning and assessment. Analytical models of the SoS can serve as effective tools to assess system-level performance against SoS operational scenarios. They may also be used to validate the requirements allocations to systems and to provide an analytical framework for SoS-level capability verification. Such models may be used to develop reasonable expectations for SoS performance. Relevant operational conditions should be developed with end-user input and guided by "design of experiments" principles so as to explore a broad a range of conditions.

Address independent evaluation of networks that support multiple SoS. Based on the government vision of enabling distributed net-centric operations, the "network" has assumed a central role as a unique constituent of every SoS. Realistic assessment of SoS performance demands evaluation of both network performance and potential for degradation under changing operational conditions. Because government departments and agencies seek to develop a set of network capabilities for a wide range of applications, consider developing an approach to network assessment independent of particular SoS applications as part of SoS planning and T&E.

Employ a range of venues to assess SoS performance over time. For SoS, evaluation criteria may be end-user metrics that assess the results of loosely defined capabilities. Though these may not be expressly timed to the development and fielding of system changes to address SoS capability objectives, these data can support periodic assessments of evolving capability and provide valuable insight to developers and users.

Assessment opportunities should be both planned and spontaneous. For spontaneous opportunities, T&E needs to be organized in a way that facilitates responding flexibly as they arise.

Establish a robust process for feedback once fielded. Once deployed, continuing evaluation of the fielded SoS can be used to identify operational problems and make improvements. This continuous evaluation can be facilitated through system instrumentation and data collection to provide feedback on constraints, incipient failures warnings, and unique operational conditions.

By establishing and exercising robust feedback mechanisms among field organizations and their operations and the SoS systems engineering and management teams, SoS T&E can provide a critical link to the ongoing operational needs of the SoS. Feedback mechanisms can be technical (e.g., instrumenting systems for feedback post-fielding) and organizational (e.g., posting a member of the SoS systems engineering and management team to the SoS operational organization).

References and Resources

  1. Office of the Under Secretary of Defense for Acquisition, Technology and Logistics (OUSD AT&L), August 2008, Systems Engineering Guide for Systems of Systems, Washington, D.C.

Additional References and Resources

Dahmann, J., G. Rebovich, J. Lane, R. Lowry, and J. Palmer, 2010, "Systems of Systems Test and Evaluation Challenges," 5th IEEE International Conference on System of Systems Engineering.

Dahmann, J., 2012, "Integrating Systems Engineering and Test and Evaluation in System of Systems Development," 2012 IEEE International Systems Conference (SysCon), accessed October 19, 2017.

The MITRE Institute, September 1, 2007, MITRE Systems Engineering (SE) Competency Model, Ver. 1, Sect. 2.6.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team