Keywords

1 Introduction

System of systems (SoS) are important to the functioning of modern society . They define infrastructures such as transportation, energy, and healthcare. They are used to achieve specific needs such as military missions as well as future plans for an intelligent transportation system or smart cities. As important as they are, SoS architecting remains a difficult problem due to the interplay of a large number of variables. Modeling can greatly benefit this effort; however, modeling is itself a difficult task. Deciding upon a modeling approach and implementing it along with the requisite models is not trivial and can consume significant time and resources. A tool for SoS architecting that already implements a flexible modeling approach can allow the architect to model the SoS while eliminating much of the difficulty. SoS Explorer is designed to be such a tool.

One way in which SoS Explorer provides value is by structuring the SoS architecting modeling effort. This structure helps to direct the model development and to allow the tool to run and interpret the results allowing for interactive visualization, optimization, and negotiation. Interactive visualization allows the architect to perform “what-if” analysis via a graphical representation of the SoS architecture. Optimization methods give the architect a set of optimal architectures on which to base the final solution. The negotiation models provide insights into how the SoS may be affected by management decisions regarding resource allocation.

2 SoS Explorer

The SoS Explorer tool consists of four major components : problem definition, evaluation, optimization, and solutions. The graphical user interface is shown in Fig. 14.1 to illustrate how this is laid-out in the SoS Explorer. The purpose of this layout is to guide the architect through the steps of defining an architecture using this approach.

Fig. 14.1
figure 1

SoS Explorer graphical user interface

Full size image

The purpose of the problem-definition section is to define a meta-architecture. The meta-architecture describes how individual architectures (or architecture instances) are composed. The meta-architecture allows for description of the problem to be entered and for the systems available for the SoS to be defined in terms of their characteristics, capabilities, and feasible interfaces. These are described in the SoS model.

The evaluation section is where the key performance measures (KPMs) are defined. These are referred to as objectives in deference to how they are used in optimization. The objectives are calculated based on the characteristics, capabilities, and feasible interfaces of the systems and interfaces selected in a given architecture. Therefore, the objectives define the modeling required for the SoS. The SoS Explorer allows the objectives to be calculated using the following languages: Python, MATLAB, or F#. An overall objective can also be defined that takes the other objectives as arguments. Its purpose is to enable single-objective optimization. For each objective, there is a “delta” as well as a calculated value. The delta shows the difference in the values between architectures or when an architecture is modified.

The optimization section allows the architect to choose an algorithm with which to find optimal architectures (solutions) and its termination criteria. There are two multiple-objective algorithms and one single-objective algorithm from which to choose. The algorithms can be tuned by modifying their parameters from the “Parameters” menu. The termination criteria are a combination of maximum number of evaluations and the point of detection of convergence. This is selected from the drop-down box. Negotiation modeling is planned but not yet implemented.

The solution (architecture instance) section represents the architecture solutions visually. These solutions are maintained as a set and may be paged through, added to, and modified. The architect can interact with the solutions by right-clicking on systems or interfaces and by left-clicking to create new interfaces. The problem and its solutions may then be saved as an Excel-format file.

3 SoS Model

A model should be as simple as possible for the purpose at hand and, at the same time, should not artificially restrict the problem being modeled. There are two key components of every SoS: systems and interfaces [1]. Therefore, systems and interfaces will be the basis for the SoS model. Keeping it simple, systems can either participate in the SoS or not. An interface either exists between two systems or it does not. Regarding the individual systems, they are characterized by the following: characteristics, capabilities, and feasible interfaces.

For the system model , characteristics are real-valued quantities and can represent items such as the cost of the system, the cost of implementing an interface with another system, performance measures, time to complete, etc. Capabilities are Boolean and represent individual capabilities of each system. These are sometimes referred to as the “little C” capability which contributes to the desired overall or the “big C” capability required by the SoS. The feasible interfaces are also Boolean and indicate whether it is possible to implement or have an interface between two systems.

The purpose of the system models is to estimate key performance measures (KPMs) for the SoS. The KPMs are used as the objectives while using an optimization method as well as to provide feedback on changes made interactively to an architecture. The only system characteristics, capabilities, and interfaces that need to be considered are those that affect the KPMs used to measure the performance of the SoS.

4 Optimization

The solution space of possible SoS architectures cannot be assumed to have a definable gradient because there is no reason for changes in architecture to produce continuous, let alone smooth, changes in their evaluation. Therefore, a non-gradient method must be employed for optimization. Evolutionary algorithms (EAs) are popular, actively researched non-gradient methods that can be readily applied to selection problems such as the given SoS model where systems and interfaces are selected to participate in the SoS. Using EAs to optimize the SoS architecture, the architecture must be represented as a chromosome. This is straightforward as each system’s participation and each specified interface can be represented as a Boolean value. Therefore, the chromosome can be defined by (n 2 + n)/2 bits for undirected interfaces and n 2 bits for directed interfaces as shown in Fig. 14.2.

Fig. 14.2
figure 2

Chromosomes for SoS with (a) undirected and (b) directed interfaces

Full size image

SoS Explorer supports both single- and multiple-objective optimizations. The user-defined objectives, O i , are of the form O i  : M Char , M Cap , M Feas , C ↦ ℝ , 1 ≤ i ≤ N, where M Char ∈ ℝ n × a is the characteristics matrix, M Cap ∈ {T, F}n × b is the capabilities matrix, M Feas ∈ {T, F}n × n is the interface-feasibility matrix, C ∈ ℝ ℓ is the chromosome, N is the number of objectives, n is the number of systems, a is the number of characteristics, b is the number of capabilities, and ℓ is the number of bits in the chromosome. For single-objective optimization, another function, O Overall, of the form O Overall : O 1 , O 2 ,  ⋯  , O N  ↦ ℝ needs to be defined by the user.

The multiple-objective EAs included with the SoS Explorer are NSGA-III [2] and MOEA-DM [3]. Both of these are, more specifically, many-objective optimization (MaOP ) algorithms . The typical SoS tends to have four or more objectives which creates issues for standard multi-objective approaches using Pareto dominance [4]. The many-objective approaches employ other criteria outside Pareto dominance to overcome these issues. The SoS Explorer comes with one single-objective EA—Simple SOGA that is a plain multi-modal EA using single-point crossover and bit-flip mutation [5].

5 Demonstration

To demonstrate the use of the SoS Explorer, an example problem is presented. The problem is a notional intelligence, surveillance, and reconnaissance (ISR) problem consisting of 22 systems [6]. Each selected system contributes one or more of the following capabilities : electro-optical/infra-red (EO/IR), synthetic aperture radar (SAR), exploitation, command and control (C2), and communication. The SoS must have all of these capabilities to be feasible. The individual systems are characterized by interface development cost, operational cost, performance, and development time. The KPMs (objectives) are performance, affordability, flexibility, and robustness. The objectives are modeled by Eqs. 14.1, 14.2, 14.3, and 14.4 respectively.

$$ \mathrm{Performance}={\sum}_{i=1}^n\left(\left\{\begin{array}{c}{\mathrm{Perf}}_i,\mathrm{if}\ {S}_i\\ {}0,\mathrm{otherwise}\end{array}\right.\right){\prod}_{j=1}^n\left\{\begin{array}{c}1+\delta, \mathrm{if}\ {S}_j\wedge {I}_{ij}\\ {}1,\mathrm{otherwise}\end{array}\right. $$
(14.1)
$$ \mathrm{Affordability}=-{\sum}_{i=1}^n\left(\left\{\begin{array}{c}\mathrm{Ops}\ {\mathrm{Cost}}_i,\mathrm{if}\ {S}_i\\ {}0,\mathrm{otherwise}\end{array}\right.\right){\sum}_{j=1}^n\left\{\begin{array}{c}I/F\ {\mathrm{Cost}}_i,\mathrm{if}\ {I}_{ij}\\ {}0,\mathrm{otherwise}\end{array}\right. $$
(14.2)
$$ \mathrm{Flexibility}={\sum}_{i=1}^n{\sum}_{j=1}^m\left\{\begin{array}{c}1,\mathrm{if}\ {S}_i\wedge {\mathrm{Cap}}_{ij}\\ {}0,\mathrm{otherwise}\end{array}\right.\kern0.75em $$
(14.3)
$$ \mathrm{Robustness}=-\max \left(\left\{\begin{array}{c}{\mathrm{Perf}}_i,\mathrm{if}\ {S}_i\\ {}0,\mathrm{otherwise}\end{array}\right.,1\le i\le n\right)\kern1.75em $$
(14.4)

where S i  , I ij  , Perf i  , Ops Cost i  , I/F Cost i  , Cap ij  , and δ represent the ith system’s participation, the interface between the ith and jth systems, ith system’s performance, ith system’s operational cost, ith system’s interface cost, ith system’s jth capability, and the performance boost provided by each implemented interface, respectively. When using an optimization algorithm, feasibility may be encouraged using a penalty function. The penalty function used in this case is

$$ \mathrm{Penalty}=-{\sum}_{i=1}^m\left\{\begin{array}{c}\rho, \mathrm{if}\ \mathrm{missing}\ {\mathrm{Cap}}_i\\ {}0,\mathrm{otherwise}\end{array}\right. $$

where ρ is the penalty for each missing capability in the SoS. The penalty is added to each objective, and ρ is chosen such that the penalty for infeasible solutions outweighs the actual objective.

To solve this problem in the SoS Explorer, the following steps may be performed:

  1. 1.

    Enter the information for the meta-architecture: systems, characteristics, capabilities, and feasible interfaces.

  2. 2.

    Enter the names of the objectives.

  3. 3.

    Create the code templates in the desired languages using “File → Create Python/MATLAB/F# Files.”

  4. 4.

    Modify the resulting source files to implement the objective functions.

Step 1 is shown in Fig. 14.3 and steps 2–3 are shown in Fig. 14.4.

Fig. 14.3
figure 3

SoS Explorer meta-architecture being defined

Full size image
Fig. 14.4
figure 4

SoS Explorer objectives named and code being created

Full size image

Now the ISR problem is modeled and architecture work can begin. A reasonable starting point would be to generate optimal solutions using one of the supplied methods. The results using Simple SOGA are shown in Fig. 14.5. To generate the set of optimal solutions, select an algorithm, termination criteria, and click on the “Optimize” button. The progress bar shows how much longer the calculation has to finish.

Fig. 14.5
figure 5

SoS Explorer solutions found by optimization algorithm

Full size image

The individual solutions returned by the optimization algorithm can be accessed by paging through using the left and right arrows in the lower right-hand corner. The values in the objectives show the architecture’s assessment while the deltas show how the current architecture’s assessment changed from the previous architecture’s. Furthermore, any architecture may by modified by hand through the visual representation. By changing the systems’ participation and their interfaces, the architect can perform “what-if” analysis and design a custom solution using the feedback provided in the evaluation section.

6 Conclusion

The SoS Explorer allows an architect to model, optimize, and visualize SoS architectures. The architect is provided a framework in which simple models allow architectures to be manipulated and evaluated. Optimization algorithms are provided that find candidate solutions for the architect. The architect can then compare and interact with these solutions to gain an understanding of the solution trade space. With this information, the architect can create a final solution while the feedback provided by the real-time architecture evaluation helps in guiding the design.

7 Future Work

A negotiation model is planned for the SoS Explorer but has not yet been implemented. The negotiation model could allow for competitive, semi-cooperative, and cooperative negotiation between the systems and a managing authority. A method such as chromosome fixing could be employed to enforce feasibility and provide constraints. Significant performance gains could be obtained by removing infeasible interfaces from the search space defined by the chromosome. If certain systems are required by the SoS, there should be a column where those systems could be so marked, and these systems should also be removed from the search space.