Abstract
System of Systems (SoS) is designed to deliver value to participant stakeholders in a dynamic and uncertain environment where new systems are added and current systems are removed continuously and on their own volition. This requires effective evolution management at the SoS architectural level with adequate support of process, methods, and tools. This paper follows the principle of Model-Based Systems Engineering (MBSE) and develops a holistic framework integrating MBSE conceptual representations and approximate dynamic programming (ADP) to support the SoS evolution. The conceptual models provide a common architectural representation to improve communication between various decision makers while the dynamic optimization method suggests evolution planning decisions from the analytical perspective. The Department of Defense Architecture Framework (DoDAF) models using Systems Modeling Language (SysML) are used as MBSE artifacts to connect with ADP modeling elements through DoDAF metamodels to increase information traceability and reduce unnecessary information loss. Using a surface warfare SoS as an example, this paper demonstrates and explains the procedures of developing DoDAF models, mapping DoDAF models to ADP elements, formulating ADP formulation, and generating evolutionary decisions. The effectiveness of using ADP in supporting evolution to achieve a near-optimal solution that can maximize the SoS capability over time is illustrated by comparing ADP solution to other alternative solutions. The entire framework also sheds light on bridging the DoDAF-based conceptual models and other mathematical optimization methods.
1. Introduction
System-of-Systems (SoS) problems have received increased attention in the aerospace industry in recent years with the advancement of communication and information technologies. In these problems, multiple heterogeneous, geographically distributed systems interact and collaborate for an overarching purpose while maintaining managerial and operational independence [1, 2]. Integrated defense system is a typical combat SoS consisting of various kinds of platforms, aircraft, sensors, weapons, and so on. Compared to traditional monolithic systems, an SoS appears more dynamic and evolutionary because it is almost impossible to have a complete and fully formed SoS. Over time, new systems can be added, current systems can be replaced or removed, and the interdependency network can switch to a more efficient structure. The change of the command and control structure in the defense community from hierarchy to multidomain illustrates a typical evolution process that is challenging to manage. Evolution is often considered as a major challenge in the SoS area [3] due to its complexity and difficulty resulting from the SoS characteristics including system autonomy, system diversity, complicated interactions, uncertainties, and dynamicity.
The U.S. Department of Defense (DoD) has made a significant effort to address the complexity of SoS evolution management from the Systems Engineering (SE) perspective for enhancing defense acquisition success. SE Guide for SoS [4] and Defense Acquisition Guidebook (DAG) [5] provided useful guidance on streamlining the evolutionary acquisition process. Dahmann [6] further unwinded the “trapeze model” in the SE guide for SoS to an intuitive time-sequenced “wave model” that is well recognized by the acquisition and SoS community. The model consists of four key decision points—“conduct SoS analysis,” “develop/evolve SoS architecture,” “plan SoS update,” and “implement SoS update,” as shown in Figure 1. The “wave model” itself does not specify any particular methods or tools to support the decision-making process for SoS development; hence, this paper employs it as an overarching framework for developing effective methods to support the SoS evolution.
Following the procedures of the “wave model,” this paper uses a Model-Based Systems Engineering (MBSE) approach to identify the operational tasks, system alternatives, interfaces, connectivity, and exchanges within and between the constituent systems for an SoS problem. MBSE is a new paradigm in SE that formalizes the practice of system development through the use of system models that are usually depicted with Systems Modeling Language (SysML) [7]. To further manage the complexity of SoS problems, this paper brings in the U.S. DoD Architecture Framework (DoDAF), supported by SysML, to describe the models of the target problem from different stakeholders’ viewpoints. The conceptual architecture description is important because it allows the SoS practitioners to organize all the information in a structured way and allows all the associated stakeholders to have a common understanding of the problem.
While the conceptual architectural models demonstrate how different elements fit together into a consistent whole, analytical methods are also in need to provide quantitative solutions for decision makers. At the architectural level, the evolutionary process of system addition, removal, and modification within an SoS can be addressed as a special multistage portfolio planning problem where decisions occur at the “develop/evolve SoS architecture” block in the “wave model.” Decisions, subject to various constraints, at the current stage could have an impact on the parameters, decisions, and capabilities in the future. For instance, new technology investment decisions at present that decrease the budget for current acquisition might increase technology readiness level and in turn improve future system capability or lower future acquisition cost. This paper adopts approximate dynamic programming (ADP) [8] to solve this multistage decision-making problem based on three major considerations: (1) the decision-tree-like representation of ADP shares similarity with the SoS evolution process; (2) ADP leverages various approximation strategies and other techniques to address the explosion issue of state space, decision space, and sample space that commonly occurs in a complex SoS; (3) ADP is able to capture the interaction between decisions and exogenous parameters.
In the current literature, the conceptual models and analytical methods were often studied separately, and thus this paper proposes to integrate the architectural models with the dynamic optimization method for better supporting SoS evolution. On the one hand, the DoDAF-based conceptual models help to identify the key elements determining the consistent performance delivery during SoS evolution; on the other hand, the ADP method provides sequential decision support from the analytical perspective based on the key information extracted from the DoDAF models. Initial attempts to connect the conceptual models and optimization methods have been published in some recent papers [9–11], but significant efforts, such as a clearer mapping between DoDAF models and mathematical elements, are still required. Overall, this paper aims to contribute to the SoS research by developing a comprehensive framework that links the architectural models and dynamic optimization method based on the steps in the “wave model” to generate effective decision support for SoS evolution. More specifically, this paper (1) develops the ADP formulation and solution approach for the evolutionary multistage decision-making process of an SoS problem, (2) links the DoDAF models and ADP formulation through the DoDAF metamodel (DM2) that can enhance the traceability between different phases of analysis, and (3) sheds light on how to build the connections between DoDAF conceptual models and other mathematical optimization methods.
The rest of this paper consists of four sections. Section 2 introduces the background and state of the art of relevant research. Section 3 employs a surface warfare SoS as a motivating example to explain the process of building DoDAF models, mapping DoDAF models to ADP elements, building ADP formulation for SoS evolution, and solving the ADP problem. Section 4 generates and explains the results of the example in Section 3. Section 5 concludes the paper and indicates future directions.
2. Background and Related Work
2.1. System-of-Systems Evolution
Evolutionary development is one of the five distinguishing SoS features that are commonly accepted by the SoS community. Evolution generally reflects a process of progressive change in the attributes of the evolving entity or that of one or more of its constituent elements [12]. Factors that can influence the SoS evolution are quite diverse, and thus organizations and researchers have studied the subject from a wide range of perspectives and some of them are not even under the name of SoS evolution. In the defense domain, official documents such as SE Guide for SoS [4] and DAG [5] as well as DoDAF and MBSE relevant methodologies aim to formalize the development and evolution process to improve efficiency and reduce risks. The U.S. DoD emphasizes the criticality of modularity and openness [13] in military system design and acquisition to better deal with unexpected changes. Maier [1] also articulated the importance of “stable intermediate form” and “leverage at the interfaces” for successfully architecting an SoS. Lock [14] proposed a qualitative analysis method to identify, organize, and discuss the information from the aspects of target, context, keyword, risk, consequences, and actions to manage SoS evolution risks. Carney et al. [15] discussed the motivation, locality, and outcome of SoS evolution by borrowing ideas from software evolution. Lehman [16, 17], as a pioneer in software evolution, developed eight important laws of software evolution from the 1970s to 1990s, including continuing change, increasing complexity, self-regulation, conservation of organizational stability, conservation of familiarity, continuing growth, declining quality, and feedback system. These laws are also applicable to SoS evolution, but with necessary shift from code to SoS elements.
An important line of research that is quite related to the quantitative and analytical support for SoS evolution is dynamic strategic planning (DSP) [18]. A variety of methods are available for addressing the DSP problem or more specifically multistage decision-making problem under uncertainty. Real options analysis (ROA) [19, 20] has been employed in evaluating the value of the flexibility-enabling staged deployment of SoSs such as low Earth orbit communications satellite constellation, maritime domain protection system, and so on. Epoch-Era Analysis (EEA) [21, 22] is another method for analyzing uncertain future contexts on the value of a system in a special structure where an epoch is a time period of fixed contexts and an era is a sequence of epochs that create a potential lifecycle. The time-expanded decision network (TDN) [23] method aims to select the development path with minimum cost under different operating scenarios. Davison et al. [24] also proposed a graph-theory-based method for charting development pathways with a trade space of potential architectures, with a view to enabling robustness to technology portfolio realization and later architectural changes. Tan et al. [25] proposed a multiobjective evolutionary algorithm (EA) to obtain system development plans informing which system components should be advanced to which maturity levels within resource limit. Acheson et al. [26] used genetic algorithm (GA) to populate initial SoS meta-architecture and formulate the trade space of possible architectures in a “wave model” driven agent-based simulation of SoS evolution. Some of the methods such as ROA, EEA, and TDNs are intuitive to understand, but suffer from the computational complexity when the problem size increases; while others such as EA and GA are not quite intuitive for decision makers to understand in the SoS context and cannot capture the impact of decisions on parameters in the future. Plus, most of them focus on the value calculation of flexibility rather than the evolutionary decision-making support of system addition, removal, and modification.
Approximate dynamic programming that combines dynamic programming with stochastic approximations illustrates great potential in representing the evolutionary process intuitively, along with the capability to alleviate the computational complexity resulted from the large number of systems, interactions, and uncertainties in an SoS. Maier [27] has proposed dynamic programming as one of the most promising methods to formulate the SoS management problem. ADP is favorable in addressing multistage decision-making problems under uncertainty by leveraging proper value function approximations. ADP applications are available in various examples, such as military airlift operations [28], energy resource allocation problem [29], and carbon reduction strategy analysis [30], to name a few. In the SoS context, Nusawardhana [31] employed ADP to a class of SoS problems that involves simultaneous design of a new system (e.g., aircraft) and allocation of the new system along with existing systems (e.g., airline fleet allocation) over a finite horizon. Fang and her co-authors [32–34] have also demonstrated the ability of ADP in supporting SoS evolution decision making for defense acquisition with proper assumptions. This paper continues leveraging the advantages of ADP in addressing complex multistage decision-making problems under uncertainty in the SoS context with more elements incorporated in the formulation.
2.2. MBSE and Architectural Models Enabled Analysis
The International Council on Systems Engineering (INCOSE) defined MBSE in their SE Vision 2020 as “the formalized application of modeling to support system requirements, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life-cycle phases” [35]. As stated previously, MBSE relevant methodologies can support the SoS evolution from the perspective of standardization and formalization. The goal of MBSE is to replace the traditional document-centric approach by model-centric approach to achieve improved design quality, enhanced communications, reduced development risks, and increased productivity [36]. SysML that emerges from Unified Modeling Language (UML) has been adopted widely in supporting MBSE. Although MBSE and SysML were not initially proposed for SoS development, they have received great attention from the SoS community. For example, Mori et al. [37] proposed a SysML profile for SoS and demonstrated how to use the profile in a model-driven engineering process to support different types of analysis. Lane and Bohn [38] demonstrated that the SysML models can capture information distilled from a multitude of constituent system documents and engineering experts and then integrate them to better facilitate SoS engineering. While SysML provides graphical representations for modeling, DoDAF provides different viewpoints to view and analyze an SoS, primarily including capability viewpoint (CV), operational viewpoint (OV), system viewpoint (SV), services viewpoint (SvcV), and data and information viewpoint (DIV). A successful example of integrating DoDAF and SysML is the Unified Profile for DoDAF /MODAF (UPDM) that was started by members of INCOSE and OMG [39]. Hayden and Jeffries [40] employed SysML, DoDAF 2.0, and UPDM to model the architecture for the joint polar satellite system ground system. Mitchell [41] used UPDM with SysML and DoDAF for modeling a common submarine combat system. This paper also uses SysML to develop DoDAF models for understanding and analyzing an SoS problem.
Conceptual DoDAF models and quantitative methods need to be closely connected to reduce unnecessary information loss. In the past, the integration of conceptual models and simulation models has been paid closer attention. For example, researchers have developed architectural models enabled executable simulation models based on colored Petri net [42, 43], agent-based modeling [44], and network-based simulation [45, 46]. However, not much work has focused on building the connection between DoDAF models and optimization-based models or analytical models [10]. A few researchers have started exploring the integration of analytical methods and model-based architectures. For instance, LaSorda et al. [9] combined model-based systems engineering with programmatic optimization for satellite SoS architecting. Guariniello et al. [10] took the initial step to connect a few analytical methods for SoS development and DoDAF models. Huff et al. [11] explored the links between DoDAF-based models and an integer linear program for rigorously evaluating system vulnerability. This paper aims to build a bridge between the DoDAF models and ADP-focused mathematical formulation to reduce the information loss between different phases in the “wave model” and provide more informed decision support for SoS evolution.
3. Proposed Framework: Architectural Models Enabled Dynamic Optimization
The proposed methodology package includes DoDAF modeling, mathematical formulation, and solution generation. Figure 2 provides an overview of the steps involved in the method and their connections to the steps in the “wave model.” In the phase of “conduct SoS analysis,” DoDAF models are developed for clarifying the mission objectives, requirements, operational tasks, existing and potential systems, exchanged resources, and future possibilities. The primary elements required for ADP formulation are also identified in this phase. The SoS evolutionary solutions are then generated in the phase of “develop/evolve SoS architecture.” Although we can generate the entire evolutionary path, only the architectural decisions at the current stage will be implemented. When the “wave model” moves to the next “Vee,” both internal and external changes could occur, and another round of decision making begins.
To clearly illustrate the implementation procedures, this paper employs a Surface Warfare (SUW) system as an SoS example to describe the method step by step. SUW is a littoral combat ship (LCS) centered mission, tasked with conducting detect-to-engage operations against surface contacts. LCS uses open architecture design that allows to be equipped with modular “plug-and-fight” mission packages. Based on references [47, 48], the SUW mission package primarily contains helicopters (e.g., MH-60R), unmanned aerial vehicles (UAV, e.g., MQ-8), unmanned surface vehicles (USV), and other supporting systems. The managerial independence and operational independence of the geographically distributed participant systems characterize the SUW system as an SoS. To satisfy the user needs continuously as time proceeds and prevent chaos when various changes occur, a visible and formalized model-based approach is important to drive the SUW architecture towards desired outcomes. For simplicity, we limit the scope of SoS evolution as in the area inside the rectangle with dashed line in Figure 3. That is, this paper only considers evolution decisions in the form of system addition in a stable operational context.
3.1. Step I: Developing Supportive DoDAF Models
“Fit-for-Purpose” is the key principle of DoDAF 2.02. Following this principle, the paper only builds necessary DoDAF models to understand the SoS problem. Table 1 lists the DoDAF views used in this paper and their purposes, including OV-5a (operational activity decomposition tree), OV-5b (operational activity model), OV-6a (operational rules model), SV-4 (systems functionality description), SV-5b (operational activity to systems traceability matrix), SV-7 (systems measures matrix), SV-8 (systems evolution description), and SV-10a (systems rules model). The DoDAF models are developed with SysML using MagicDraw software and a couple of supplementary matrices and graphs. In SysML, block definition diagram (BDD) represents structural elements called blocks and their interconnections; activity diagram represents behaviors in terms of the order in which actions execute based on the availability of their inputs, outputs, and control and how the actions transform the inputs to outputs. As shown in Table 1, we use BDD for building OV-5a and SV-4 models and activity diagram for building OV-5b models. Other forms including graphs, matrices, and texts are also used for developing OV-6a, SV-5b, SV-7, SV-8, and SV-10a models.
OV-5a decomposes the mission objective of clearing surface threats into several operational activities including search and detect, track, classify, engage, and command and control. The granularity is kept at a coarse level for the ease of understanding the procedures. Based on OV-5a, OV-5b further clarifies the interdependency relationship and information exchange between the operational activities. As illustrated in Figure 4, target information is the primary information exchanged between different activities and command and control activity processes most of the sensor and communication information. The operational activities depend on a number of physical systems to complete the mission. We identify the potential system alternatives including LCS, helicopter, UAV, and USV and respective system functionalities in SV-4. Each type of system has four variations with different levels of capability. The systems and system functions in SV-4 can both be mapped to operational activities in OV-5b. The mapping between potential systems and operational activities is described in SV-5b, as shown in Figure 5. LCSs can conduct all the operational activities; helicopters and UAVs are able to detect, track, classify, and engage targets; USVs are only responsible for detecting and tracking targets.
SV-7 specifies the qualitative and quantitative measures of resources. In this example, SV-7 in Table 2 lists the selected metrics for the major operational activities and specific measures for each alternative system. The ranges of most input data in the table are extracted from Jacobson’s thesis [49]. Flexibility indicates the ability of a system to incorporate new technology; it affects the technology development cost and performance improvement. For the ease of representation, it is assumed that systems of type III and IV are better than systems of type I and II in terms of performance while systems of type II and IV are better than systems of type I and III regarding flexibility.
SV-8 in Figure 6 provides a graphical representation of the evolution process of a helicopter system. The change of a system depends both on internal decisions such as technology development and external environment such as budget change and technology maturation. OV-6a and SV-10a are able to describe the rules constraining the activities and systems, such as budget constraint, quantity constraint, and production capacity constraint.
3.2. Step II: Mapping DoDAF Models to ADP Elements
ADP is a flexible modeling and algorithmic framework for solving multistage decision-making problems under uncertainty. Figure 7 illustrates a representative decision-making process of ADP. The circles represent the system states while the rectangles represent the decision nodes. The decision nodes in Figure 7 can be mapped to the decision points “develop/evolve SoS architecture” in the “wave model.” Prior to determining the architectural decisions, we need to map the DoDAF models to ADP elements during the SoS analysis phase. The key ADP formulation elements include state variables, decision variables, objective function, transition function, exogenous information, and constraints if necessary [8]. Table 3 illustrates the mapping relationship between the adopted DoDAF models and ADP modeling elements through the metamodel. The metamodels are the fundamental building blocks of DoDAF models, including the data elements of activity, resource, performer, capability, measure, measure type, and many others. For example, the conceptual metamodel of OV-5 involves activity, resource flow, performer, etc.
Decision Variables. The optimization of SUW SoS capability of detecting and destroying enemy boats needs the support of physical systems in SVs to conduct the operational activities in OV-5. The decision variables are associated with the physical systems listed in SV-5b in Figure 5. Two types of decisions are under consideration: an integer decision variable , describing the number of system that is acquired at time , and a binary decision variable , indicating whether a new technology is developed for system at time . The technology development decision affects the performance of potential systems in a cumulative way.
State Variables. The state variables consist of the current state of budget and information about system parameters in SV-7 in Table 2. Other state variables such as the operational tasks and activities are not taken into account because they are assumed to be stable in this paper. The system parameters influencing the contribution of a system to an operational activity and in turn impacting the SoS capability can be aggregated as a single index . can then be used as a representative state variable. This paper employs additive value model to obtain the values of based on the information in SV-7. According to references [50, 51], additive value model requires identification of key metrics associated with a system function, measures of merit, and scoring functions that normalize different measures of merit to 0 to 100, as shown in the following expression:where is the measure of merit; is the total number of measures of merit; is the weight of the measure of merit; is the level of the measure of merit; and represents the value of the scoring function at level . The scoring function is a single dimensional value function that assigns value to the system’s ability to reach the objective. The following formulation based on references [50, 51] is one of the options for constructing scoring functions:where represents a measure of merit (e.g., range of detection) with maximum capability of and minimum capability of and is the shape parameter that changes the curve and reflects the subjective preferences of the decision makers.
Objective Function. According to DoDAF CV-6 (Capability to Operational Activities Mapping), although not explicitly specified in this paper, the capabilities of an SoS can be fulfilled by the operational activities. That is, the capability contribution of each operational activity in OV-5b in Figure 4 composes the aggregate SoS capability. The basic structure is given as follows:where , a function of , represents the capability contributed by operational activity to the overall SUW capability at time and functions and are parametric models resulting from expert experience, engineering judgement, historical data, or simulation analysis. This paper presumes a linear form for both and for simplicity.where and are weighting factors denoting the importance of operational activity and system in contributing to the overall SUW SoS and activity , respectively. Weight selection of a multicriteria optimization problem has been long studied and various approaches are available (for example, analytic hierarchy process, analytic network process, and statistical analysis). This paper assumes that the values of and can be elicited through expert opinions. Plugging equation (6) into (5), we obtain the complete objective function.
Exogenous Information. Exogenous information includes all sort of information that can change the current state, primarily in the form of random variables. According to SV-8 in Figure 6, exogenous information in this study contains the stochastic capability improvement of system , denoted as , due to the technology development decisions at each time step, as well as the budget change rate . For the ease of representation, system capability improvement occurs stochastically only to one of the three operational activities (i.e., search and detect, classify, and engage). Specifically, systems of LCS type and USV type are improved stochastically on the capability of detecting threats; systems of helicopter type are enhanced stochastically on the capability of classifying targets; systems of UAV type are improved stochastically on the capability of engaging threats. The capability increases of all systems are assumed to follow truncated normal distributions.
Transition Functions. Transition function indicates the change of SoS states due to the decisions or exogenous information. Based on the evolution demonstration of SV-8, system capability improves when associated technologies are developed. Meanwhile, budget at each time step changes at a rate of . The equations are described as follows:
Constraints. The information for formulating the constraints can come from the rules in OV-6a and SV-10a. The SUW objective function is assumed to be subject to budget constraint, production capability constraint, and some other requirement constraints.where , , , and represent the minimum quantity requirements of systems of LCS type, helicopter type, UAV type, and USV type, respectively, and is the acquisition cost of system at time while is the technology development cost for system at time . Equation (14) constrains both the system acquisition decisions and technology development decisions by the limited budget. indicates production capacity of system at time .
3.3. Step III: Building ADP Formulation for SoS Evolution
The foundation of dynamic programming is the Bellman equation, in which the value of an optimization problem at a specific decision stage is expressed in terms of the immediate payoff and the optimal value of the future objective function. The value at each decision stage is calculated recursively using the Bellman equation. The major issue of dynamic programming is the intractability of calculating expected value function when the sizes of state space, decision space, and sample space grow exponentially. ADP replaces the exact value function by approximate value to reduce the computational complexity while still being able to generate near-optimal solutions [8]. Meanwhile, ADP allows for a straightforward representation of decision-dependent parameters that are difficult to incorporate using dynamic programming. The Bellman equation of ADP can be expressed as follows:where denotes the primary state variables that capture the future value. The first portion inside the expectation notation describes the capability contributed by decision at time while the second portion indicates the approximate value function of being in state . is a discount factor with the value between 0 and 1 that helps decrease the emphasis of future value in the objective function to reduce the approximation errors. Decision makers need to find appropriate approximation strategies for a given problem. For an SoS evolution problem at the architectural level, collecting adequate physical details to build a comprehensive and complex approximation model is challenging and unnecessary. A linear structure for approximating value function as in equation (18) would be an easier and faster solution for high-level decision makers, although some accuracy might lose as a price.where refers to basis functions that capture the important features contributing to the overall capability. The major state variables are selected for the basis functions in the SUW example. represents the vector of adjusting parameters that enable different approximate value functions. After replacing the exact value function with approximate one, equation (17) is still challenging to solve due to the computation of expectation. We adopt a concept of postdecision state variable proposed by Powell [8] to separate the effect of decisions and exogenous information. The expectation can then be removed by using sample realizations of uncertain parameters. The new objective function can be expressed as follows:
This study employs a least square temporal difference (LSTD) learning method to update the coefficient parameters in the approximation. LSTD learns by sampling the exogenous information and approximates its current estimate based on previously learned estimates. The updating equations can be expressed as follows according to reference [8]. is a sample estimate obtained by solving equation (19) with coefficient at iteration .
3.4. Step IV: Generating SoS Evolution Solutions
To generate SoS evolution solutions, we need to solve the mathematical formulation discussed in the previous sections. The algorithmic procedure for solving the ADP problem is summarized as follows: Step 1: Set . Initialize . Step 2: Sample the uncertain exogenous information (for example, in this study). Step 3: For , do: Step 3a: Determine decision variables by solving equation (19). Step 3b: Update by updating the coefficient vector according to equations (20) and (21). Step 3c: Update system states using equation (8). Step 4: Let . If or , go to Step 2.
4. Results and Discussion
According to the DoDAF models enabled mathematical formulation and the adopted ADP algorithm provided in the previous section, this paper uses “intlinprog” function in Matlab to solve the integer programming problem at each time step for every iteration. The function “intlinprog” might be inefficient for large size problems, in which case we can switch to more efficient commercial computation tools such as CPLEX and Gurobi optimizers. This result section primarily aims to demonstrate the effectiveness of the ADP method in supporting SoS evolution while the usefulness of integrating MBSE and ADP will also be discussed in the last subsection.
4.1. Convergence Analysis
Before generating any decisions that could be useful, the first step is always checking the convergence status of the ADP algorithm. Since the deterministic experiment is a special case of the stochastic experiment, we only plot the convergence analysis figure of the stochastic experiment where the capability improvement of each type of system follows a normal distribution. The initial budget is set as 1000 million dollars and increases at a constant rate of 5% during every decision stage. Figure 8 illustrates the convergence status using the linear value function approximation in equation (18). The objective value (i.e., the value function at the first stage) converges within 100 iterations. Fluctuations exist but remain in a small range, around 5% of the mean objective value.
4.2. Solution Comparison
Since the decision-dependent parameters are difficult to capture in many methods, the comparison starts with experiments that do not include the technology development decisions. The value function converges slowly in this case, so we set a small discount factor that equals 0.5 to increase the convergence rate. The discount factor does not impact the comparison once the ADP algorithm and the regular single-stage optimization choose the same discount factor. Figure 9 demonstrates the approximate total value (i.e., value function at the first stage) at each iteration and the exact total value obtained by adding together the capability value at each decision stage solved by single-stage integer programming. After 1000 iterations, the difference between the approximate objective value and exact one is within 1%, which demonstrates the effectiveness of value function approximation strategy with as basis functions.
With technology development decisions incorporated, we begin with a simplified version as a three-stage problem with fixed capability increase because the increasing number of decision stages quickly increases the intractability of the problem. Figure 10 compares ADP solution to the solution of a nonlinear programming (particularly genetic algorithm). Based on the plot, both the objective value at each stage and the total objective value over three stages obtained by ADP (i.e., area under the solid blue curve) are larger than those values from the genetic algorithm. That is, the result from the ADP method is closer to the optimal solution than that from the genetic algorithm that was adopted by quite a few papers to support SoS evolution.
In the stochastic experiment with technology development decisions, Figure 11 compares the capability value obtained from the ADP algorithm at each decision stage with four other test cases under a special scenario where the mean values of the stochastic parameters are used as representatives. In those test cases, decision makers are not sure about the ratio between budget on system acquisition decisions and budget on technology investment decisions. Hence, we use four test cases, where the percentage of technology investment is 0%, 10%, 20%, and 50%, respectively, to represent the possible decisions. Based on the plot, only Case 1 provides a solution close to the results from ADP while some of the cases such as Case 4 provide pretty bad solutions. The total capability values over ten stages (i.e., area under each curve) of these five cases are 20302, 18052, 20023, 17864, and 11010, respectively. Although the ADP solution does not reach the exact optimal value, it outperforms all the other example solutions (and many others not listed) in this experiment. Although decision makers might still be able to pick the right decision, the loss for the bad decisions could be significant yet avoidable.
4.3. Demonstration of SoS Evolution Decisions
The SoS evolution decisions in this example include the number of systems acquired to join the SUW SoS and whether new technologies are developed for a specific system. Figure 12 demonstrates the system addition decisions in the form of mean values. Note that the actual decision that will be implemented is solely the current decision although the evolutionary decisions are generated over ten decision stages. Based on the graph, LCS_III, LCS_IV, Helicopter_III, UAV_IV, and USV_IV take up the majority part of the system acquisition plan. Recall that type III and IV systems have better performances than type I and II systems while type II and IV systems are more flexible to adapt to changes than type I and III systems. Although type I systems are cheaper, almost none are selected. On the contrary, type IV systems are the most attractive options. An interesting observation is that more type III systems are chosen than type II systems. Higher performance seems more favorable to decision makers than higher flexibility in this example. If the benefit provided by the flexibility increases, the result might change accordingly. We can also observe that the number of type IV systems increases quickly in the later stages; this is because the cumulative benefit earned by technology development and flexible design surpasses the cost at a certain point.
4.4. Discussion
The results in this section demonstrate the effectiveness of ADP in supporting SoS evolution by analyzing the convergence status and comparing solutions from ADP and other alternative methods. The mathematical equations in the previous section are of course not the only way to formulate the SoS evolution problem, but they did provide an idea for decision makers on how to extract useful information from DoDAF models, put the information together as mathematical expressions, and generate quantitative solutions for SoS evolution. Although we have made quite a few assumptions to simplify the process, such as linear parametric models used in the objective function, linear value function approximation, and simple exogenous information, these perspectives can definitely be improved by more sophisticated methods. We also used some synthetic input data, such as the capability improvement and system quantity requirements; fortunately, they do not affect the essence of the proposed method and can be replaced by real data.
The function of the DoDAF models is to provide a common platform to enable more effective communication between different types of stakeholders involved in an SoS. The bridge made between DoDAF models and the ADP method allows the decision makers to directly generate evolutionary decisions based on the information extracted from the DoDAF models. On the one hand, the link increases the traceability between conceptual models and analytical methods. On the other hand, when users employ DoDAF models to conduct other types of analysis, the source information and data will be kept as the same for different types of analysis. Decision makers can thus investigate and analyze an SoS problem from different facets using different methods with less information mismatch. This paper has not realized the automated conversion process from DoDAF models to ADP modeling elements yet, and the manual translation through metamodel can be considered as a preliminary step towards the automated process.
5. Conclusions
Using MBSE artifacts as a common input source for different SoS architectural analysis has been a pressing need for many industry and government agencies. This paper employed MBSE artifacts, more specifically DoDAF models using SysML, and the ADP method to provide decision support for SoS evolution in the form of “wave model.” Using a motivating SUW SoS example, this paper developed an entire framework from DoDAF model development, mapping between DoDAF models to ADP elements, to ADP formulation construction and solution generation. The key contribution of this paper is building the bridge between DoDAF models and ADP elements through metamodels including resources, activities, systems, rules, and so on. Although not fully automated yet, the integration can help decrease the possibility of information loss during the quantitative analysis and allow for a holistic understanding of an SoS problem. Moreover, this paper formulated the SoS evolution problem as a multistage portfolio planning problem involving decision-dependent parameters, uncertainties, etc., and made full use of ADP in addressing such a type of problems. The results demonstrated the effectiveness of ADP in achieving a near-optimal solution, even with simple linear value function approximation. Finally, the proposed method is not only suitable for ADP method but also provides an idea for decision makers on how to build connections between DoDAF conceptual models and other mathematical optimization methods.
Research in this paper can be considered as a preliminary step towards fully automated MBSE process. The manual connection between DoDAF models and ADP formulation still imposes a substantial burden on the SoS engineers. Therefore, part of the future work will focus on deriving mathematical formulation from DoDAF models in an automatic or partially automatic manner. This requires a clear understanding of the logic between metamodels in the DoDAF models and the logic between the ADP elements. In addition, many assumptions in the formulation can be relaxed in the future. For example, current ADP formulation has not captured the interaction effect among operational activities described in OV-5b yet. Furthermore, the proposed work should be applied to a large-scale and fully detailed problem in the future.
Nomenclature
| : | Index of operational activity |
| : | Set of all operational activities |
| : | Total number of operational activities |
| : | Index of system |
| : | Set of all systems |
| : | Total number of systems |
| : | Index of time step or decision stage |
| : | Set of all time steps or decision stages |
| : | Capability contributed by activity to SoS at time |
| : | Capability contributed by system to activity at time |
| : | Weight of activity in contributing to SoS |
| : | Weight of system in completing activity |
| : | Number of system that is acquired at time |
| : | Whether a new technology is developed for system at time |
| : | Capability improvement of system to activity at time |
| : | Budget at time |
| : | Budget increase rate |
| : | Acquisition cost of system at time |
| : | Technology development cost of system at time |
| : | Quantity requirement of LCS system |
| : | Quantity requirement of helicopter system |
| : | Quantity requirement of UAV system |
| : | Quantity requirement of USV system |
| : | Production capacity of system at time |
| : | Value function approximation from to the end |
| : | Discount factor |
| : | Basis functions for value function approximation |
| : | Coefficient vector of basis functions for value function approximation |
| : | Sample estimate of value function at iteration at time . |
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was partially supported by the National Natural Science Foundation of China under grant no. 61273207, Independent Innovation Funding of Huazhong University of Science and Technology under grant no. 2019kfyXJJS17, and Natural Science Foundation of Hubei Province under grant no. 2014CFB581.