Architectural Models Enabled Dynamic Optimization for System-of-Systems Evolution

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 eﬀective 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 eﬀectiveness 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.


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. e 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. e 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. e 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. e "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. e 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.
is 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][10][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. e 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.

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. e 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. ese 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. e 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 coauthors [32][33][34] have also demonstrated the ability of ADP in supporting SoS evolution decision making for defense acquisition with proper assumptions. is 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.

MBSE and Architectural Models Enabled Analysis.
e 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. e 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. is 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. is paper aims to build a bridge between the DoDAF models and ADPfocused mathematical formulation to reduce the information loss between different phases in the "wave model" and provide more informed decision support for SoS evolution.

Proposed Framework: Architectural Models
Enabled Dynamic Optimization e 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. e primary elements required for ADP formulation are also identified in this phase. e 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. e 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.
at 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). e 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. e 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 Step II: mapping DoDAF models to ADP elements Step III: building ADP formulation for SoS evolution Step IV: generating SoS evolution solutions Step I: developing supportive DoDAF models …… …… Wave model Proposed procedures Operational context OV (T 1 ) Complexity 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. e 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. e systems and system functions in SV-4 can both be mapped to operational activities in OV-5b. e 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. e 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. e 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 decisionmaking process of ADP. e circles represent the system states while the rectangles represent the decision nodes. e 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.
e key ADP formulation elements include state variables, decision variables, objective function, transition function, exogenous information, and constraints  6 Complexity if necessary [8]. Table 3 illustrates the mapping relationship between the adopted DoDAF models and ADP modeling elements through the metamodel. e 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. e 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. e decision variables are  State Variables. e 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. e system parameters influencing the contribution of a system i to an operational activity j and in turn impacting the SoS capability can be aggregated as a single index fcap j,i,t . fcap j,i,t can then be used as a representative state variable. is paper employs additive value model to obtain the values of fcap j,i,t 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 k is the measure of merit; q is the total number of measures of merit; ω k is the weight of the kth measure of merit; l k is the level of the kth measure of merit; and v k (l k ) represents the value of the scoring function at level l k . e scoring function is a single dimensional value function that assigns value to the system's ability to reach the objective. e following formulation based on references [50,51] is one of the options for constructing scoring functions: where MOM represents a measure of merit (e.g., range of detection) with maximum capability of MOM max and minimum capability of MOM min 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.
at is, the capability contribution of each operational activity in OV-5b in Figure 4 composes the aggregate SoS capability. e basic structure is given as follows: where Fcap j,t , a function of fcap j,i,t , represents the capability contributed by operational activity j to the overall SUW capability at time t and functions g( ) and h( ) are parametric models resulting from expert experience, engineering judgement, historical data, or simulation analysis. is paper presumes a linear form for both g( ) and h( ) for simplicity.
where ωfcn j and ωsys j,i are weighting factors denoting the importance of operational activity j and system i in contributing to the overall SUW SoS and activity j, 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). is paper assumes that the values of ωfcn j and ωsys j,i 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 i, denoted as dtfcap j,i,t , due to the technology development decisions at each time step, as well as the budget change rate Bgt t+1 � Bgt t · (1 + δ).
Constraints. e information for formulating the constraints can come from the rules in OV-6a and SV-10a. e SUW objective function is assumed to be subject to budget constraint, production capability constraint, and some other requirement constraints.
i∈I Helicopter i∈I UAV i∈I USV where SysReq LCS t , SysReq Helicopter t , SysReq UAV t , and SysReq USV t represent the minimum quantity requirements of systems of LCS type, helicopter type, UAV type, and USV type, respectively, and cost acq i,t is the acquisition cost of system i at time t while cost dev i,t is the technology development cost for system i at time t. Equation (14) constrains both the system acquisition decisions and technology development decisions by the limited budget. ProdCapacity i,t indicates production capacity of system i at time t.

Step III: Building ADP Formulation for SoS Evolution.
e 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. e value at each decision stage is calculated recursively using the Bellman equation.
e 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.
e Bellman equation of ADP can be expressed as follows: where S t denotes the primary state variables that capture the future value. e first portion inside the expectation notation E describes the capability contributed by decision x acq i,t at time t while the second portion indicates the approximate value function of being in state S t . c 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 φ(S t+1 ) refers to basis functions that capture the important features contributing to the overall capability. e major state variables fcap j,i,t are selected for the basis functions in the SUW example. θ T t+1 represents the vector of adjusting parameters θ j,i,t+1 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. e expectation can then be removed by using sample realizations of uncertain parameters. e new objective function can be expressed as follows: is 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. e updating equations can be expressed as follows according to reference [8]. υ n t is a sample estimate obtained by solving equation (19) with coefficient θ n− 1 at iteration n.

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. e algorithmic procedure for solving the ADP problem is summarized as follows: Step 1: Set n � 1. Initialize V n�1 t , t � 1, . . . , T { }.
Step 2: Sample the uncertain exogenous information (for example, dtfcap j,i,t in this study).
Step 3b: Update V n t− 1 by updating the coefficient vector θ according to equations (20) and (21).

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. e 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. is 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.

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 dtfcap j,i,t of each type of system follows a normal distribution. e 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). e 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.

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. e value function converges slowly in this case, so we set a small discount factor that equals 0.5 to increase the convergence rate. e 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 fcap j,i,t 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. at 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. e 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.

Demonstration of SoS Evolution Decisions.
e 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.

Discussion.
e 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. e 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 dtfcap j,i,t and system quantity requirements; fortunately, they do not affect the essence of the proposed method and can be replaced by real data. e 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. e 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. is 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.

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. is 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. e 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. e 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. e manual connection between DoDAF models and ADP formulation still imposes a substantial burden on the SoS engineers. erefore, part of the future work will focus on deriving mathematical formulation from DoDAF models in an automatic or partially automatic manner. is 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.

Complexity
Nomenclature j: Index of operational activity J: Set of all operational activities n: Total number of operational activities i: Index of system I: Set of all systems m: Total number of systems t: Index of time step or decision stage T: Set of all time steps or decision stages Fcap j,t : Capability contributed by activity j to SoS at time t fcap j,i,t : Capability contributed by system i to activity j at time t ωfcn j : Weight of activity j in contributing to SoS ωsys j,i : Weight of system i in completing activity j x acq i,t : Number of system i that is acquired at time t x dev i,t : Whether a new technology is developed for system i at time t dtfcap j,i,t : Capability improvement of system i to activity j at time t Bgt t : Budget at time t δ: Budget increase rate cost acq i,t : Acquisition cost of system i at time t cost dev i,t : Technology development cost of system i at time t SysReq LCS t : Quantity requirement of LCS system SysReq Helicopter t : Quantity requirement of helicopter system SysReq UAV t : Quantity requirement of UAV system SysReq USV t : Quantity requirement of USV system ProdCapacity i,t : Production capacity of system i at time t V t+1 : Value function approximation from t + 1 to the end c: Discount factor φ: Basis functions for value function approximation θ T t : Coefficient vector of basis functions for value function approximation υ n t : Sample estimate of value function at iteration n at time t.
Data Availability e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that they have no conflicts of interest.