SoS Methodology

The distinctive feature of the DANSE SoS engineering lifecycle is that it relies upon an evolutionary process (see figure). Classical models of systems engineering, such as the V Model rely upon a top-down view of design and a linear, once-through approach to systems engineering. The SoS of interest to DANSE are an aggregation of pre-existing "legacy" systems, with added functionality, and new constituent systems developed specifically for the new SoS. This has consequences on the systems engineering lifecycle.

The figure shows five system-of-systems engineering processes and a set of constituent systems engineering processes. The first two processes are complementary:

  1. Model SoS behaviour – Simulation models run continuously during the lifecycle of the SoS and performance indices obtained by simulation are compared as they become available with operational data. Since most SoS are too large and complex to run comprehensive model validation experiments, validation cannot be but an incremental process. Modelling, validation and design corrections based on the proven technology of contract-driven design developed in SPEEDS [SPEEDS2010] will be performed continuously.
  2. Operate the SoS – An SoS will operate continuously and experience incidents of emergent behaviour on a regular basis. When the operating data diverges significantly from the predictions of the operational model, the operational model must be adapted to cope with the inaccuracy that may lead to negative emergent behaviours.
  3. The lower three SoS engineering processes embody a learning cycle and support steady performance improvement for modelling and operations over time, as the SoS evolves:
    1. Define potential needs - This task is based on a two-step process:
    2. Identifying a need - Ongoing analysis of system performance can lead to the determination of the needs in two ways. Either: 1) modelling and analysis suggest that better performance is possible or 2) the system‘s behaviour differs significantly from the current prediction obtained by the DANSE operational simulation. Incidents of unexpected emergent behaviour may be negative (indicating performance problems or malfunctioning), or positive (indicating opportunities).
    3. Analyzing the cause - Root-cause analysis is supplemented with a knowledge base of previously analyzed incidents to support rapid identification of recurring patterns. The knowledge base becomes increasingly sophisticated as the system and its operators - learn. The validation of a causal mechanism is strongly supported by the DANSE simulation technology.
  4. Analyze possible architecture changes - Analyzed needs drive changes in the system to exploit opportunities or correct problems. A change may suggest fundamental changes to the architecture of the SoS or to the architecture of component systems. A key architectural tool is the predictive modelling and simulation capability used to compare architectural alternatives. Simulation also has an important role in the verification and validation of proposed architectures since logical validation can offer significant savings in testing. A complementary and interesting technology consists in using control design techniques. So far, control has hardly been an integral part of SoS design methodology (even systems design methodology). When applied, techniques from control are, sort of, considered apart from the main design flow. We believe that integrating optimisation techniques from control inside SoS design flow would be of great benefit. As a candidate approach, we believe that Model-based Predictive Control (MPC) best fits the style already in use in systems design methodology. By manipulating finite receding horizons and allowing for arbitrary dynamics and constraints in addition to an objective criterion for minimization, MPC does not suffer from restrictions in dynamics nor does it put emphasis on difficult issues such as stability.
  5. Influence and implement changes - Types of changes include: 1) Updating a simulation model to give more accurate estimates of system behaviour, 2) Modification of a contract between the SoS and one or more component systems. 3) Refactoring the architecture at the SoS level. 

The Vs in the lower part of the lifecycle diagram represent systems engineering efforts at the level of constituent systems. Constituent systems are typically legacy systems that were developed using a variety of engineering processes. During SoS operation, when the capability engineering process identifies a needed capability enhancement it may influence the various constituent systems to implement a change. Engineering processes at the component systems level are not dictated from the SoS level, but must be coordinated with the overall SoS goals applying contract based technology.

Most SoS are initially created as opportunistic aggregations of legacy systems after studying and mapping the potential component systems, external actors and other significant features. Typically, most or all of the component systems have been operating for some time prior to being inserted as part of the SoS.