Implementing a MOSA Decision Support Tool in a Model-Based Environment

Abstract

The Modular Open Systems Approach (MOSA) is a DoD initiative that requires major defense acquisition programs to employ modular architectures using widely accepted standards. In order to realize the benefits of modular and open architectures, program stakeholders must successfully navigate various technical and programmatic decisions throughout the acquisition life cycle. Our observation is that many programs do not have sufficient methods and tools to perform analysis, assess trades, and produce evidence for decisions that produce good program outcomes in general and in specific respect to modularity. This paper presents a model-based approach to rigorously collect and present acquisition context data and data from analysis tools in a Decision Support Framework (DSF). Through an example multi-domain mission engineering problem, we demonstrate how the DSF enables comparison of modular/non-modular mission architectures in terms of cost and performance. In addition, an MBSE enterprise architecture model is used to implement the DSF and is shown to (1) provide detailed visualizations of alternative architecture solutions for better comparison; (2) allow traceability between features of the architecture and organizational requirements to better document adherence to MOSA principles; and (3) lay the groundwork for continued model-based engineering development downstream of the Analysis of Alternatives activity to the rest of the acquisition life cycle.

Appendix A: RPO Input Data for Example Mission Engineering Problem

In this example, candidate systems are labeled generically (e.g., Satellite System 1–5) and use notional data. The data in Fig. A.1 can be read as follows: Satellite System 1 contributes 100 to “SoS Capability 3” and requires 75 [units] in communication bandwidth and 95 [units] in power input. Likewise, Power System 3 offers no SoS or communication capabilities, but is capable to supply 300 [units] of power to other systems. Each capability is subject to an uncertainty that may result in violating node input requirements. This information is reflected in a risk aversion metric shown on the horizontal axis of Fig. 4. Finally, compatibility and selection constraints are set in the input spreadsheet as well. Here, the optimizer can select one option from systems 1–5 (Ground Systems) and 11–15 (Aerial Systems) and up to two options from systems 6–10 (Satellite Surveillance Systems). Likewise, the optimizer is constrained to select one Naval System (16–18) and two Power Systems.

Fig. A.1

Example of RPO input data for the example problem