Framework Development for Efficient Mission-Oriented Satellite System-Level Design

Abstract

The space mission analysis and design process defines a space system at the system level to accomplish space mission objectives. Although the traditional process is well established and comprehensive through several years of experience, we propose a novel design process framework in this paper to aid the traditional process focusing on the following areas of improvement: (1) clarification of the direct connection between mission objectives and final system-level baseline design and requirements, (2) development of a comprehensive quantitative judgment criterion to evaluate various design alternatives, (3) derivation of system drivers and critical requirements after obtaining sufficient design knowledge based on the analysis of big data obtained from exploration of entire design space using an integrated design environment, and (4) system optimization even at the system level with a holistic perspective to guarantee that the baseline design meets the mission objectives. Examples of design steps in the proposed framework are characterizing stakeholder needs and engineering characteristics, building an integrated design environment, exploring and analyzing design space, optimizing system-level design, and elaborating mission utility to ensure an efficient mission-oriented design approach. The proposed framework is implemented in an example space mission involving quantum cryptographic communication. Accordingly, we demonstrate that the proposed framework provides an efficient mission-oriented satellite system-level baseline design.

1. Introduction

Space mission analysis and design (SMAD) is a process that defines a space system at the system level to accomplish given mission objectives. The SMAD process is mostly used in the following areas [1]: (1) the early stages of space system development, such as mission concept development, requirement analysis, and conceptual design to derive a system-level design, which meets the given mission objectives; (2) assistance in decision making for budget acquisition of new space programs by verifying feasibility and economic viability, and persuading stakeholders; (3) establishment of technology development plans for future space missions by identifying gaps in technologies to overcome current insufficiencies in feasibility and economic viability. In the first area, the important point is that the system-level design must fulfill the given mission objectives while satisfying the given constraints and will be a criterion for measuring improvements in the subsequent design and development phases. The second area focuses more on trade-offs to identify a reasonable combination of requirements, constraints, and system configurations such as performance, cost, schedule, and risk, which shows the feasibility and economic viability of a new space program, and if it is, also provides information on the extent. The third area requires the assessment of the impacts of new technology on the requirements and system configurations in the current design to build new technology development portfolios and plans.

A general procedure has been conducted in the SMAD process established over several years through past experiences [2,3]. In this process, starting from mission objectives and constraints mainly coming from stakeholders or users, the outcome through the top–down approach is ultimately a system-level design, which includes mission architecture, requirements, system drivers of system elements, and system-level configurations. Various trade-off analyses and iterations are often required in the course of the process. Because of the generic nature and complexity of the SMAD process, sufficient efforts for comprehensively improving the entire process from mission objectives to system-level design have yet to be made in the academic field.

Previous academic studies related to the SMAD process can be broadly categorized into three cases. The first case is the demonstration of a point design at the system level for a specific mission with several trade-off studies. This category mainly focuses on technical feasibility and economic viability. When considering as many elements to accomplish the mission as possible, a sequential approach or limited optimization for specific important key parameters based on relatively firm requirements is implemented to justify the resultant design. T. Sands demonstrated the feasibility and economic viability, showing a point design result for electronic warfare satellites [4]. M. Xu et al. demonstrated the technical feasibility of a super-low-altitude satellite using the existing bus and payload [5]. A. Almazrouei et al. demonstrated a CubeSat point design for the mission investigating terrestrial gamma-ray flashes including mission concept, analysis, design, and test [6]. The second case is the development of a computational tool or particular design method to aid the SMAD process. This category provides an easy trade-off environment using database and/or system algorithms. Y. Chang et al. developed a system-engineering design tool for small-satellite conceptual design, implementing a graphical user interface (GUI) based on characteristic trend equations derived from data from 200 previously launched small satellites [7]. G. Radice et al. also developed a concurrent design tool for the SMAD process, where the implemented GUI easily provides a rapid trade-off environment [8]. The third case is the demonstration of multidisciplinary design optimization (MDO) for a specific mission at the system level. This category focuses on the multidisciplinary nature of the SMAD process, and many previous studies related to mission analysis and design belong to this category. More elaborated modeling, analysis, and optimization are used. The optimization goals usually represent some important parameters, which often include satellite mass. R. Shi et al. conducted MDO for an all-electric geostationary orbit (GEO) satellite for minimizing the total satellite mass [9]. X. Hu et al. performed reliability-based design optimization through a multidisciplinary approach with several multiobjective goals, including payload cost-effective ratio, satellite mass, and five reliability constraints [10]. The other studies that have been conducted fall into the three stated categories [11,12,13,14]. Although these research efforts are valuable for improving some characteristics of the SMAD process, there is a need to develop a way of improving the SMAD process from an overall and mission-oriented perspective.

In this study, we developed a novel efficient mission-oriented framework to improve the SMAD process. Note that the suggested framework is the process itself, not a product or tool to aid the process or the design result of a specific mission. The proposed framework features the following properties: (1) direct connection between mission objectives and final system-level baseline design and requirements are clearly given by developing a comprehensive quantitative judgment criterion and applying it throughout the entire design process; (2) system drivers and critical requirements are derived by analyzing the big data obtained from entire design space exploration using an integrated design environment; (3) system-level baseline design and requirements are obtained through optimization, which is necessary because we cannot easily confirm that the chosen design is better than any other design due to the very large design space incurred by simultaneously considering all system elements; (4) the analysis is based mainly on the physics-based approach to complement insights, past experiences, and historical data, and make more reliable decisions (design can be considered as a decision-making process). Property (1) ensures the mission-oriented approach and process efficiency comes from properties (2) and (3). Property (4) enables more reliable and confident design.

The use of the framework would provide the following benefits: (1) the degree to which the resultant system-level baseline design meets the mission objectives can be quantitatively evaluated relative to the other alternatives; (2) system drivers and critical requirements for every mission of interest can be confidently identified; (3) the integrated design environment and optimization can reduce design iterations and risks in the subsequent design and development phases; (4) the incorporation of the proposed framework into the current model-based systems engineering [15] and the concurrent engineering [16] practices could yield many synergies for the SMAD process. Ultimately, a key benefit would be enabling rapid design decision making by directly reflecting mission objectives through the proposed consistent process while reducing human resources/cost required for communication between development teams.

This paper comprises the following sections. In Section 2, the proposed framework is presented in detail, as well as the comparison with the current generic SMAD process. Next, the SMAD process for an example space mission implementing the proposed framework, here a quantum cryptographic communication mission, is explained step by step in Section 3. In Section 4, the system algorithms used in the process for the example mission are briefly described. Finally, the conclusions and future work are presented in Section 5.

2. Proposed Efficient Mission-Oriented Framework for the SMAD Process

The goal of the SMAD process is ultimately to realize knowledge-based decision making depending on its application areas, whether to proceed to the subsequent development phase, make go/no-go judgments, or identify technologies that need to be developed. Here, the term “knowledge-based” means that one desires to make a decision on the matter of interest with as much information as possible hoping for the expected results to facilitate an intelligent decision with increased confidence.

To achieve an improved and efficient mission-oriented SMAD process, we propose a separate SMAD process to aid the traditional process, as presented in Figure 1. Figure 1 shows the traditional generic SMAD process on the left and the proposed SMAD process on the right. The areas of improvement adopted in the proposed process are discussed herein in terms of steps in the generic process. In Step 4, quantitative top-level preliminary mission requirements reflecting the mission objectives using typical examples from past experiences are estimated. Because it could be a challenging task at this early stage of the process, we recommend employing a systematic approach with sufficient knowledge of how they are estimated. From the same viewpoint, the method of defining system drivers and identifying key requirements in Step 7 can be more confidently determined based on the big data analysis from the design space exploration (DSE) to complement qualitative decision making based on common examples and judgments of people involved in the process. In Step 8, although sequential trade-offs and a repetitive approach are used in general, we recommend simultaneously considering all the related elements overall for accelerating the process and avoiding missing any interactions among elements. In Step 9, there is a need to incorporate an optimization concept during trade studies and various assessments of feasibility, performance, and mission utility for better supporting the decision making on the system-level design. Finally, decision makers may need a quantitative criterion to judge how much the resultant baseline system design obtained from the process satisfies the mission objectives.

In the following subsections, we explain the proposed SMAD process step by step, as shown on the right in Figure 1, to aid the traditional one while ensuring the properties of the proposed process.

2.1. Step 1: Define Mission Objectives and Constraints

To start the SMAD process, first, mission objectives and constraints need to be clearly defined. This step is the same as Step 1 in the traditional process. In this step, we first begin with the mission statement, which is a top-level qualitative mission description that occupies several paragraphs. The mission statement usually comes from stakeholders or users who want to achieve specific goals from the mission. If some constraint-like goals exist, they should also be included. Next, the mission statement is translated into the mission objectives stated in the form of the “To + verb” expression arranged in order of importance. They can be considered concise summaries of the mission statement. Several iterations among stakeholders, users, and developers may be required to finalize it. The mission objectives act as a creed for everyone who participates in the mission life cycle, ensuring that they always work toward the same goals. On the basis of the mission objectives, basic studies on the mission, such as data collection, literature search, expert survey, and currently available technology, are performed.

2.2. Step 2: Derive Alternative Mission Architectures

In this step, various alternatives for the mission architecture are sought in advance. The mission architecture comprises the mission concept (concept of operations) and elements of the mission. For achieving the mission objectives, there could be several architectures. For example, we may achieve the objectives through a low Earth orbit (LEO) constellation, a single satellite in GEO, or an LEO satellite with several ground stations. The primary goal of this step is to identify what elements are required and how the interactions occur among them. The secondary goal is to make developers contemplate the system algorithms that should be prepared, from which associated design variables and output parameters can be derived at the later steps. Some of the design variables will turn out to be system drivers, and some of the output parameters act as critical requirements.

In the proposed process, we recommend using at least a high-level operational concept graphic (OV-1) and operational node connectivity description (OV-2) from the United States Department of Defense Architecture Framework (DoDAF Ver. 1.5) [17]. Here, OV means the operational view among the three views used in the framework development. OV-1 is one big visual graphic accompanied by brief descriptions emphasizing the elements related to the mission and the unique properties of the mission operations. It can provide a quick and high-level explanation of what needs to be done and how to do it. OV-2 is an architecture that graphically displays the operational nodes (elements) and indicates the role of each node and what information needs to be exchanged between each pair of nodes. If OV-1 briefly represents the mission operation concept, then OV-2 expresses the mission concept more concretely by describing the interactions among the mission elements. The outputs of this step are several pairs of OV-1 and OV-2 generated by developing each mission architecture. For example, one pair is the architecture for LEO, and the other is for GEO.

2.3. Step 3: Characterize Stakeholder Needs and Engineering Characteristics

Because stakeholders are actually the ones who either fund the budget and/or are benefactors of the mission and may be different according to the application areas, clearly identifying them and deriving their needs is important. The generic approach for the identification of stakeholders and the derivation of their needs can be found in many systems engineering studies [18,19]. Although G. Benedetti et al. have recently presented stakeholder analysis to derive the mission objectives based on their needs [20], the stakeholder needs are derived from the mission objectives while considering their perspectives, roles, interests, and requests in the proposed approach. Then, appropriate engineering characteristics should be derived, which could ultimately fulfill the stakeholder needs.

The characterization in this step means that the stakeholder needs and engineering characteristics are derived in the form of systematic hierarchical classification and categorization. When constructing systematic classifications for both, we can use some of the seven quality management and planning tools, such as the affinity diagram, tree diagram, and interrelationship diagraph [21]. During this process, several brainstorming sessions with basic research results are required.

When characterizing stakeholder needs according to the mission objectives derived in Step 1, the needs are described in qualitative terms because they are usually expressed that way. Although there may be some cases where the stakeholders specify the exact technological requirements quantitatively, they can be dealt with as critical engineering characteristics. Thus, it is recommended that the exact technical requirements should be translated into qualitative needs for consistency. In addition to mission objectives, the needs should essentially incorporate the aspects of cost, schedule, and risk as well as hidden agenda. Furthermore, as the stakeholders may usually not be technological experts, the needs from the developers’ perspectives on the mission should also be included. Consensus through several iterations among stakeholders, users, and developers will yield the final stakeholder needs characterization. The characterization of the engineering characteristics utilizes the results of the stakeholder needs characterization and mission architectures constructed in Step 2. The engineering characteristics may be well characterized by experts in each system element identified in the mission architectures.

2.4. Step 4: Derive and Prioritize Initial Requirements

With the systematic classifications of the stakeholder needs and engineering characteristics, we estimate initial requirements for each engineering characteristic to meet the stakeholder needs in this step. This step is very important to ensure that the entire proposed process is always mission-oriented. Furthermore, the initial requirements and their prioritization provide the guideline for constructing system algorithms, which are used in the subsequent steps for efficient design space analysis (DSA). To achieve this, we need to properly translate the stakeholder needs into engineering characteristics. Then, whether the mission objectives are met or not can be judged by the requirements for each engineering characteristic.

The translation methodology is quality function deployment (QFD), which is a powerful tool to relate the “voice of customer (VOC)” to the “voice of engineer (VOE)” [22]. VOC represents the stakeholder needs, and VOE can be considered the engineering characteristics here. The QFD technique is a systematic and structured tool in a visual form that allows developers to focus on customers’ needs throughout the entire system development process. It aims at a system thinking (strategic thinking) perspective and can be considered a support tool for systematically balancing and judging various considerations from the customers. Some advantages of QFD are that it encourages all developers to focus on VOC rather than their own internal desires and allows the production of a comprehensive balanced result considering all VOCs, their relative importance, and additional considerations of achieving engineering characteristics such as difficulty and risk. The main contribution from the QFD here is to identify the relative importance of each engineering characteristic to meet the needs.

Although QFD is a flexible tool and can have various forms according to applications, the form shown in Figure 2 is suggested in the proposed approach. The primary process of QFD is to analyze the relationship structure between the stakeholders’ needs in the far-left column and the engineering characteristics in the top row through the relationship matrix in the middle. The important results are relative ratings (quantitative weightings) and target values (quantitative requirements) of the engineering characteristics. The relationship analysis process is a qualitative mapping through a pairwise evaluation performed by system element experts to measure the impact of each engineering characteristic on each stakeholder need. Evaluation is done on the 0, 1, 3, and 9 scales as used in the usual QFD technique. The evaluator must focus on only each pair, not the other stakeholder needs or engineering characteristics, to minimize biased results.

The relative importance column in Figure 2 indicates the relative importance of the stakeholder needs, which can be evaluated using the analytic hierarchy process (AHP) [23]. The relative importance also needs consensus among stakeholders, users, and developers. Target direction indicates the direction in which each engineering characteristic is beneficial for accomplishing the mission and is represented by up (increase is better) or down (decrease is better) arrows. In the initial stage of QFD creation, which could be refined several times (as knowledge of the system to be designed gradually grows), there are often cases where the target directions for certain engineering characteristics cannot be easily specified. For example, orbit altitude is an important engineering characteristic in many missions; however, specifying the target direction is difficult because it is often subject to trade-offs generally between coverage and resolution. These engineering characteristics are recommended to be maintained in the initial QFD stage to identify the relative importance of a given mission. However, in the refinement process for QFD, treating them as design variables that can be controlled by the designer may be better when developing the system algorithm in Steps 5 and 6. Accordingly, the engineering characteristics in the final system-level QFD must be composed of those having a clear target direction, so that various system design alternatives could be evaluated quantitatively. The engineering characteristics converted into the design variables can also be dealt with as optimization variables when analyzing big data obtained from DSE using the integrated design environment in Step 7.

The additional consideration criteria are those that may affect the evaluation of the relative importance of engineering characteristics such as difficulty and risk by qualitative evaluation. The inclusion of specific criteria depends on the necessity regarding the current mission of interest. The relative importance rating of each engineering characteristic is calculated using the usual method of QFD based on the relative importance of stakeholder needs and the results of qualitative mapping through the relationship analysis process with proper normalization, which also provides the relative ranking of each engineering characteristic. It should be emphasized that these relative ratings of engineering characteristics eventually provide the developers with the so-called design philosophy for accomplishing the specific mission. In other words, the developers can determine which engineering characteristics are critical or not and must focus on the important engineering characteristics throughout the entire design process, not just system-level design. The ratings also play an important role in optimizing the system-level design in Step 8 and elaborating utility analysis in Step 9.

Because the QFD process inherently utilizes qualitative mapping, there may be some doubts about whether the resultant ratings may vary depending on the evaluators. Of course, the individual pairwise qualitative mapping may vary; however, if the stakeholder needs and engineering characteristics do not change, the overall ratings do not change significantly. Rather, they are very robust according to the authors’ experience because of the inherent property of QFD to produce a comprehensive balanced result. Therefore, characterizing the stakeholder needs and the associated engineering characteristics appropriately in Step 3 is more important.

Now, we are at the stage of deriving the requirements for each engineering characteristic based on their importance ratings. To achieve this, the typical market value or its range is prepared for each engineering characteristic. It is recommended that market values be chosen as those expected from the current technologies. The consideration of new technologies can be treated separately with new technology impact algorithms along with system algorithms, particularly for the third SMAD application (establishment of technology development plans), which will not be discussed in detail in this paper. The reason for separate treatment is to better understand the effect of new technology relative to the current technology. With the market value ranges and ratings for each engineering characteristic, the initial system-level target values can be specified. Considering the range of typical market values, the higher the importance of engineering characteristics, the more rigorously the target values are set.

Finally, the initial system-level requirements set is established while maintaining a mission-oriented perspective. This requirement set provides the developers with the guideline and the degree of expected quantitative requirements for the subsequent design process. Each requirement can be changed according to the results of the DSE and analysis in Step 7, where sufficient knowledge of the system can be obtained.

2.5. Step 5: Identify Design Variables and Their Ranges for Each

Steps 5 and 6 aim to develop system-level quantitative analysis tools (system algorithms) to explore the suggested mission architectures in Step 2 and the large design space associated with them. The key considerations for developing system algorithms are given in Section 4. Step 5 involves identifying design variables and their ranges for each analysis tool by preparing the so-called interface control document (ICD). An example form for an optical camera comprising input and output sections is presented in

Table 1. Example form of the interface control document: (a) inputs section; (b) outputs section.

(a)
Segment	Element	Subsystem	Input Variable	Unit	Type	Min. Value	Max. Value	Description	From Subsystem
Space	Payload	Optical camera	Diameter	m	Continuous	0.05	1	Aperture diameter	Internal variable
…	…	…	…	…	…	…	…	…	…
(b)
Classification		Output Variable	Unit	Type		Description		To Subsystem
Performance		Required pointing accuracy	deg	Continuous		Pointing accuracy required for optical camera		Attitude determination and control subsystem
…		…	…	…		…		…
Configuration		Mass	kg	Continuous		Camera Mass		Configuration management
…		…	…	…		…		…

. Because a large DSE requires an integrated analysis, this type of document must be prepared in advance.

In the input sections of Table 1, the segment classifies space, ground, launch, etc.; the elements are payload, bus, etc.; the subsystems are optical cameras, infrared cameras, etc. The input variables are classified as design variables, parameters, and outputs from other subsystems. Design variables are system-level variables specific to the current subsystem and can be controlled by designers. Parameters are environmental variables, categorized into controllable parameters such as options for system standards or general technological properties and noncontrollable ones that depend on the environment or societal regulations. Outputs from other subsystems refer to inputs that are to be retrieved from some other subsystems’ outputs. Proper units are also provided. The type is divided into continuous or discrete. It is recommended that the design variable be continuous unless it is unavoidable. The reason is that it is convenient to conduct analysis using the design of experiment (DOE) and optimize the design with continuous variables later with the results of DSE. Because optimization leads to narrowing down the design space to a design point that can accomplish the mission optimally, discrete design variable values could be assigned in the vicinity of that point. In the case of a continuous variable, the range that can be varied is given by designating the minimum and maximum values. For the discrete variable, possible values are listed. The description of the design variable is written in the description column so that other subsystem experts can understand and consider it. The last column contains the subsystem name if the variable should be input from another subsystem, and if it is a variable specific to the current subsystem, it is recorded as an internal variable.

In the output sections of Table 1, the classification usually indicates the output category such as technical performance or configuration. The outputs must include all the requirements identified in the QFD process for the corresponding subsystems. The last column contains the subsystem name if the variable should be input to another subsystem. Although it may not be clear which subsystem is directly related when each subsystem expert tries to write a certain subsystem in the “From Subsystem” and “To Subsystem” columns, it can be clear at the time of integrating the tools. In addition, when integrating the tools, some missing input or output variables can be identified. Therefore, the ICD is continuously updated through the next step, which builds system algorithms and the integrated design environment.

2.6. Step 6: Build System Algorithms and the Integrated Design Environment

The system algorithm in the proposed process denotes a tool that can quantitatively analyze performance, cost, schedule, and risk at the system level for all elements included in the concept of operations and architectures. Each tool is developed according to the ICD in Step 5 and should be as flexible as possible so that the output values can be calculated for all ranges in which design variables or parameters can change. More importantly, the outputs from the system algorithms must include the engineering requirements identified in the QFD process in Step 4, so that various alternatives can be evaluated later from the mission-oriented design perspective. Because analysis of a large design space is essential, it is recommended that they be generally developed at the Excel^TM level for computationally efficient DSE. In addition, the development strategy for technical performance should follow the physics-based approach as much as possible. In the case of the first-order method, the system algorithm can be developed directly; moreover, when the use of a sophisticated method often utilized in the preliminary design phase is unavoidable, a metamodel is developed by using the DOE on the ranges of design variables considered and the statistical method. If applying the above two methods is difficult, one can use a related database commonly used in configuration elements such as cost or schedule and develop a regression equation through the curve fitting method.

Once the system algorithms are prepared for all the elements involved, an integrated design environment is developed. The integrated design environment basically connects the inputs and outputs that interact between each pair of elements defined in the “From Subsystem” and “To Subsystem” columns of the ICD and analyzes the system overall, where the outputs of all elements can be calculated for the inputs of the design variables of all elements. It is important to note that even if each element is connected, the analysis within the entire environment must be composed of only feedforward calculations without a feedback process such that the calculations are executed sequentially. When the feedback process is included, not only must an algorithm for finding solutions between mutual variables through iterative calculations be given but also considerable computational time is required. For example, in the case of the optical camera system ICD in Table 1, the required pointing accuracy is output and delivered to the attitude determination and control subsystem (ADCS) as input. If the pointing accuracy is determined by design variables in the ADCS system algorithm itself (an output of the ADCS), the design variables of the ADCS for providing the required pointing accuracy of the optical camera must be calculated in reverse; thus, a feedback process is inevitably required. Therefore, to avoid this feedback process, the required pointing accuracy is taken as one of the outputs of the integrated design environment rather than being passed to the ADCS system algorithm. By analyzing big data obtained from DSE later, it is possible to find combinations of design variables for the ADCS statistically that satisfy the required pointing accuracy from the optical camera system. One can use the design structure matrix (DSM) to find whether feedback processes exist [24,25]. The integrated design environment can be developed by using Excel^TM if all the system algorithms are developed with the same tool; however, it is recommended to use commercial tools such as Model Center^TM [26] or iSight^TM [27] because there are frequent cases where other tools such as executables files and routines of MATLAB^TM are used. Other reasons are that identifying the presence of feedback processes is easy, and handling inputs and outputs systematically is convenient. In addition, it enables efficient DSE because it provides various DOE methods.

2.7. Step 7: Explore and Analyze the Design Space

The ranges of all design variables specified in Step 5 constitute the design space of the system. A design point within this space that can best achieve the mission objective ultimately becomes the baseline. Any engineering system has a very large design space at the beginning of the design, which is a distinct characteristic that the system-level design phase differs from the subsequent phases. In other words, alternatives that can achieve the mission objective can be actually chosen from a wide variety within the design space. Therefore, all these alternatives should be analyzed efficiently to identify the characteristics of the design space so that knowledge-based decision making on design can be achieved and the risk of the entire development process could be minimized.

Appropriate DOE methods are applied to a wide design space for efficient DSE; then big data containing the quantitative relations between design variables and requirements can be generated, which allows us to grasp the characteristics of the design space. By applying statistical techniques to big data, metamodels such as response surface models (RSM) can be created. The change in each requirement for each design variable and parameter change can be quickly assessed with metamodels. The initial DOE is called a screening DOE, which enables the identification of system drivers for each requirement by performing statistical analysis such as Pareto analysis on initially chosen design variables and parameters. Then, we can narrow down the design space by excluding variables that have little influence at the system level. Additional statistical analysis includes analysis of the interaction between mission elements, sensitivity analysis of design variables, parametric study for specific requirements, and system requirements trade-off analysis. In DSA, it is helpful to establish basic feasibility criteria such as margins of mission links, power operation, satellite volume, mass, and satellite average temperature ranges, as well as feasibility criteria for critical requirements for the mission being considered. In addition, if the design variables that have significant impacts on each requirement are sorted in order of importance through Pareto analysis, it is easy to identify which design variables are to be adjusted in the event of overcoming certain constraints or conducting trade-offs later.

As the knowledge of the space system through DSE and analysis expands, refinement is iteratively performed on the necessary steps from Steps 2 to 6, and more concrete knowledge can be obtained by redoing Step 7.

2.8. Step 8: Optimize the System-Level Design

Optimization at the system level is performed using metamodels. An objective function is assessed with the quantitative importance (weightings) of each requirement derived through the QFD process and the values of each requirement corresponding to the given design variable combination. From the optimization process, a combination of design variables and parameters that maximizes the objective function can be produced along with optimized quantitative values of requirements. Because the optimization result is obtained by utilizing the metamodels, it should be checked whether the resulting values of requirements are calculated with appropriate reliability using the actual system algorithms.

Although the optimization result is given as a form of point design, an area that can best achieve the given mission is identified in the broad design space. Primarily, it can be assumed that the mission-oriented design process is continuously maintained thus far. There may be cases where the optimization result does not satisfy some basic feasibility criteria established in Step 7. If this is the case, satisfying them is possible by adjusting the listed design variables that significantly influence those criteria prepared in Step 7 in advance. A modified design that can satisfy the criteria can be found near the area close to the optimization point by performing parametric studies for the design variables and analyzing the change in infeasible criteria. In addition, if there are constraints, such as the possible performance of current commercial products that are likely to be used, obtaining a modified design is similarly possible. Figure 3 illustrates the optimization and design modification philosophy of the proposed process for the simple two-design-variable design space.

2.9. Step 9: Elaborate Mission Utility and System Requirements

Through Steps 7 and 8, sufficient knowledge and insights can be obtained on the design space, and it is narrowed down through a mission-oriented optimization process to derive a baseline system-level design. In this step, on the basis of the results of the previous two steps, the mission utilities for various alternatives are quantitatively determined to support knowledge-based decision making for the mission architectures and baseline, and system-level requirements are elaborated among stakeholders, developers, and users. Mission utility represents the overall mission performance of the system design, and quantitative measures of effectiveness are required to determine it. In the proposed process, a measure of effectiveness, which is often represented by overall evaluation criteria (OEC), is preferred for making more distinct decisions rather than dealing with multiple measures of effectiveness as in the generic process. The Technique for Order Preference by the Similarity to Ideal Solution (TOPSIS) method is applied to evaluate the OEC in the proposed approach [28]. It is one of the multiattribute decision making (MADM) techniques, which apply the concept of Euclidean distance in an N-dimensional attribute space to all the alternatives. Imaginary positive and negative ideal solutions derived from all the alternatives are used to calculate the Euclidean distances from them to each alternative and rank the alternatives. Figure 4 shows the TOPSIS concept for a simple two-dimensional attribute space. Accordingly, the OEC calculated by TOPSIS is similar to the objective function used in the optimization in Step 8.

OEC enables the quantitative determination of the degree of improvement in the mission utility of the baseline derived in Step 8 compared to the other design alternatives, such as randomly selected ones during the DOE process. In addition, it is possible to intuitively judge the extent of change in the overall mission utility when some modifications are required from the baseline for various reasons mentioned before.

The initial system requirement set in the QFD process can also be refined using knowledge of the design space. In other words, quantitative system requirements can be elaborated by determining how considerably critical requirements can be achieved, and to what extent they can be achieved if the initial desired requirements are not met. In particular, for critical requirements that are difficult to achieve, one can gain insights into the type of new technologies that could be applied and to what extent. Thus, this step outputs the well-defined mission-oriented system requirements with the corresponding architecture and baseline.

2.10. Step 10: Allocate System Requirements to System Elements

At this stage, we finish the conceptual design stage and proceed to the preliminary design phase. The system-level requirements flow down to those of various system elements. The methods are the same as those of the generic process; accordingly, one can refer to Refs. [2,3].

3. An Application Example of the Proposed Efficient Mission-Oriented Framework

3.1. Introduction to an Example Mission

As an example of applying the proposed framework, we present the mission of constructing a secure satellite communication relay network using quantum key distribution, in which data duplication and interception are fundamentally impossible. For satellites employed in quantum cryptography missions, there have been several examples including a representative Chinese Micius satellite and even CubeSats [29,30,31,32,33]; however, there have been no published cases from the SMAD perspective. Here, we present the procedure of conducting a system-level design by applying the proposed framework.

3.2. Step 1: Define Mission Objectives and Constraints, and Step 2: Derive Alternative Mission Architectures

Let us assume that the following finalized mission statement is given from several iterations among stakeholders, users, and developers.

From the mission statement, the purpose of the mission is to present a system-level design that can judge the feasibility and viability of developing a microsatellite that performs practical quantum cryptography communication missions in line with the trend of miniaturization of satellites according to recent technological developments. Thus, the mission objectives, which represent a concise summary of the mission statement, can be translated from the mission statement into the following:

As stated before, the mission objectives must be finalized through several iterations among stakeholders, users, and developers. From the mission statements and objectives, the purpose of the SMAD process here is to help the decision making on the budget acquisition of the new space program, which is the second of the three areas stated in the Section 1.

In general, the mission concept and architecture can be considerably diverse; however, in this case, it can be easily derived as the operations of microsatellites in LEO because it is impossible to implement communication between ground stations by a single satellite in GEO if ground stations are located on opposite sides of the Earth from each other. The corresponding OV-1 and OV-2 are shown in Figure 5. Suppose that several architectures might be considered possible for other missions. In that case, we recommend utilizing Step 4 in the generic process, where quantitative needs, requirements, and constraints are estimated based on mission technical requirements and political and economic goals, to reduce the number of architectures.

3.3. Step 3: Characterize Stakeholder Needs and Engineering Characteristics

To derive systematic stakeholder needs as well as those directly presented in mission objectives, the classification of usual project constraints, i.e., performance, cost, schedule, and risk, is used. The categorization is first prepared by the developers and then finalized through several iterations with stakeholders and users. Among the derived stakeholder needs, the needs that the stakeholders consider the most important are identified for needs prioritization in Step 4. The final stakeholder needs categorization for this example is given in

Table 2. Stakeholder needs categorization.

Level 1	Level 2	No.	Stakeholder Needs	Critical Needs
Performance	Mission	1	Maximize key generation rate	⊙
		2	Large data transmission
	Satellite System	3	Minimize mass and size	⊙
		4	Maximize mission lifetime
		5	Maintain mission orbit
		6	Maximize pointing accuracy	⊙
		7	Minimize ground support
		8	Minimize required power
		9	Maximize onboard computer performance
		10	Maximize data storage
	Reliability	11	Maximize redundancy
		12	Consider radiation-hardened design
		13	Consider electromagnetic interference/compatibility
		14	Maximize contingency
Cost	RDT&E	15	Low development cost
	Acquisition	16	Low acquisition cost
	Operation and Maintenance	17	Low operation and maintenance cost
	Wrap	18	Low management cost
	Launch	19	Low launch cost
Schedule	Development Schedule	20	Minimize development period
Risk	Risk	21	Minimize risk

.

Engineering characteristics to realize the given stakeholder needs are derived by considering each node and interactions between them according to the architecture and concept of operations and are categorized through systematic classification as well. This task is possibly executed by experts of all the system elements involved. The final engineering characteristics categorization for this example is given in

Table 3. Engineering characteristics categorization.

Group	Engineering Characteristic	No.	Importance	Critical Characteristic
Mission Operation	Quantum Key Distribution (QKD) Mean Response Time	1	Important
	GS Mean Response Time	2	Neutral
	Required Delta V for Orbit Maintenance	3	Neutral
System	Satellite System Mass	4	Important	⊙
	Power Margin	5	Important
	Mission Link Margin	6	Important
	Daily Communication Data	7	Minor
Link	Mission Data Up/Downlink Speed	8	Neutral
Payload	Data Relay Effective Isotropic Radiated Power (EIRP)	9	Neutral
	Data Relay G/T	10	Neutral
	QKD Key Rate	11	Important	⊙
	QKD Quantum Bit Error Rate (QBER)	12	Neutral
Propulsion	Propellant Mass	13	Minor
	Total Delta V	14	Neutral
ADCS	Pointing Accuracy	15	Important	⊙
	Slew Rate	16	Important
Electrical power system (EPS)	Solar Array Power Generation	17	Neutral
	Satellite Maximum Required Power	18	Important
	Battery Required Capacity	19	Important
Comm.	Comm. EIRP	20	Minor
	Comm. G/T	21	Minor
Structure	Bus Mass	22	Important	⊙
	Satellite Size	23	Important
Thermal control subsystem (TCS)	Satellite Maximum Equilibrium Temperature	24	Neutral
	Satellite Minimum Equilibrium Temperature	25	Neutral
Ground Station	Satellite Operation G/T	26	Minor
	Satellite Operation EIRP	27	Minor
	Mission G/T	28	Minor
	Mission EIRP	29	Minor
Reliability	Satellite Reliability	30	Neutral
Launch Vehicle	Reliability (Launch Success Rate)	31	Minor
	Launch Cost	32	Minor

. Note that the categorization in Table 3 is the final form obtained from several iterations from this point to Step 5. During iterations, some engineering characteristics can be dealt with as design variables from the perspective of system algorithm development. Some may be discarded by the consideration of whether they fit the system level. In this case, the examples are those representing excessively detailed levels of characteristics corresponding to the subsystem or component. The importance column represents the criticality of each engineering characteristic derived from relative importance in Step 4. They are classified as Important, Neutral, or Minor.

Thus far, 21 stakeholder needs and 32 engineering characteristics have been identified.

3.4. Step 4: Derive and Prioritize Initial Requirements

Figure 6 shows the final QFD result (see Figure 2 for the format) after several refinements for deriving and prioritizing initial requirements for engineering characteristics. The construction process explained in Section 2.4 is followed to translate the stakeholder needs into engineering characteristics by system element experts. In the relationship matrix, the double circle, circle, and triangle are used to represent the 9, 3, and 1 scales, respectively. The relative importance of stakeholder needs is evaluated using AHP. Additionally, the relative importance of Level 1 stakeholder needs (performance, cost, schedule, and risk) is given. The difficulty in achieving the desired engineering characteristics is chosen as an additional consideration criterion in this example. On the basis of the ranking for each engineering characteristic and typical market value, the initial requirement set can be defined. The initial requirement acts as a guideline for not only subsequent steps but also the development of system algorithms. The ranking represents the design philosophy in this example mission. The relative importance of engineering characteristics is a quantitative value, which is used for optimization to derive the baseline system-level design.

3.5. Step 5: Identify Design Variables and Their Ranges for Each

The design variables and their ranges are derived to analyze the given engineering characteristics for each element, such as mission operation, payload, bus system, ground station, and link. Design variables are those unique to the system of interest and can basically be controlled by the developer. Because uncontrollable parameters that depend on the environment, such as the degradation rate of solar panel efficiency or atmospheric communication loss, are necessary for system analysis, they are also included in the design variable category to reflect and identify their effects. Design variables that can achieve the initial requirements derived through QFD analysis are carefully selected for each mission element, and their variation range (design space) is set. Therefore, it is desirable for each subsystem expert to perform this step. In the design variable selection process, those presented as engineering characteristics in the QFD process may be considered design variables, and those that are too detailed or have a relatively small influence at the system level may be excluded. As mentioned in Step 3, Table 3 results from these considerations.

The identified design variables and ranges are organized through ICD preparation for each element.

Table 4. Interface control document for QKD payload.

(a)
Segment	Element	Subsystem	Input Variable	Unit	Type	Min. Value	Max. Value	Description	From Subsystem
Space	Payload	QKD	QKD Optic Size	m	Cont.	0.05	0.4	QKD Optic Aperture Diameter	Internal
			Distance	km	Cont.	500	-	QKD Comm. Max. Distance	Mission Operation
			GS QKD Optic Size	m	Cont.	0.2	0.5	Ground OKD Optic Aperture Diameter	Ground Station
(b)
Classification		Output Variable		Unit	Type	Description		ToSubsystem
Performance		QBER		%	Cont.	QKD Bit Error Rate		-
		Key Rate		cps	Cont.	QKD Key Generation Rate		GS
		Pointing Accuracy Requirement		deg	Cont.	Required Pointing Accuracy for QKD Operation		ADCS
Configuration		QKD Payload Mass		kg	Cont.	QKD Payload Total Mass		Configuration Management
		QKD Payload Size		m	Cont.	QKD Payload Total Size		Structure
		QKD Payload Power		W	Cont.	QKD Payload Power Consumption		EPS

and

Table 5. Interface control document for mission operation.

(a)
Segment	Element	Subsystem	Input Variable	Unit	Type	Min. Value	Max. Value	Description	From Subsystem
Space	Mission	Mission Operation	Altitude	km	Cont.	500	800	Orbit Altitude	Internal
			Inclination	deg	Cont.	49	60	Orbit Inclination	Internal
(b)
Classification		Output Variable		Unit	Type	Description		To Subsystem
Performance		Average Comm. Period		h	Cont.	Daily Average Comm. Period		-
		Average Comm. Time		h	Cont.	Daily Average Comm. Time		Configuration Management
		Required Delta V		m/s	Cont.	Required Delta V for Orbit Maintenance		Propulsion
Configuration		Distance		km	Cont.	QKD Comm. Max. Distance		QKD Payload
		Orbit Deployment Delta V		m/s	Cont.	Required Delta V for Orbit Deployment		Propulsion

present examples of ICDs for the quantum key distribution (QKD) payload and mission operation elements.

The final design variable selection is made through the impact analysis of the design variables from Screening DSE in Step 7. The initial draft of the design variable selection at this step is presented in

Table 6. Initial draft of chosen design variables.

Group	No.	Design Variable	Default	Unit	Low	High
Mission Operation	1	Altitude	550	km	500	800
	2	Inclination	49	deg	49	60
Payload	3	Data Transmit Power	1.0	W	1.0	10.0
	4	Data Antenna Beam Width	50.0	deg	31.0	69.1
	5	Data Antenna Efficiency	55.0	%	50.0	80.0
	6	QKD Optic Size	0.25	m	0.05	0.4
Comm.	7	Comm. Transmit Power	1.0	W	0.5	2.0
	8	Comm. Antenna Efficiency	55.0	%	50.0	80.0
EPS	9	Solar Array Efficiency	28.0	%	15.0	30.0
	10	Solar Array Area Ratio	3	-	1	3
	11	Power Consumption Margin	10.0	%	10.0	20.0
	12	Solar Array Degradation	2.75	%	2.0	5.0
	13	On/Off Time Margin	120	sec	120	300
ADCS	14	Max. Attitude Angle	30.0	deg	30.0	45.0
Propulsion	15	Available Delta V	30.0	m/s	30.0	100.0
	16	Specific Impulse	40.0	sec	30.0	70.0
Structure	17	Satellite X Size	3	Unit	2	4
	18	Satellite Y Size	3	Unit	2	4
	19	Satellite Z Size	7	Unit	3	8
	20	CG Deviation Margin	5.0	%	1.0	10.0
	21	Structure Margin	10.0	%	5.0	15.0
TCS	22	Radiator Usage	40.0	%	10.0	60.0
Link	23	Daily TM Data Amount	3.0	Mbyte	3.0	15.0
	24	Data Frequency	2300	MHz	1500	2500
	25	Data Amount	3.0	Mbyte	3.0	15.0
	26	Data Code Rate	0.9	-	0.25	0.9
	27	Atmospheric Loss	−2.0	dB	−2.0	0.0
	28	Comm. Realization Loss	−3.0	dB	−3.0	0.0
Ground Station	29	GS QKD Optic Size	0.4	m	0.2	0.5
	30	GS Max Transmit Power	10.0	W	10.0	100.0
	31	Satellite Control Antenna Size	3.0	m	1.0	3.0
	32	Mission Antenna Size	5.0	m	3.0	8.0
	33	Satellite Control Antenna Efficiency	60.0	%	50.0	80.0
	34	Mission Antenna Efficiency	60.0	%	50.0	80.0
Launch Vehicle	35	LV Cost Weighting	75.0	%	20.0	100.0

. Note that we do not have any specific satellite size, platform, or performance of previous or existing space systems in mind to focus strictly on the mission-oriented design approach.

3.6. Step 6: Build system Algorithms and the Integrated Design Environment

Considering the engineering characteristics and their requirements presented in Steps 3 and 4 and the design variables with their ranges presented in Step 5, system algorithms for all elements of interest are developed based on the ICDs. The system algorithm for each element will be discussed in more detail down to the level of introductory explanation in Section 4.

To establish an integrated design environment interconnecting the system algorithms, clearly identifying the inputs and outputs that need to be connected among each element is necessary. In addition, the feedback process between system algorithms must be eliminated through discussions between developers for each element or structured methods such as DSM. This work can be more easily achieved by referencing ICDs for each element.

3.7. Step 7: Explore and Analyze the Design Space

Before exploring the design space composed of the ranges of design variables in Step 5, the criteria for judging the basic feasibility of each design resulting from various combinations of design variables are established. The recommended criteria are mission life; those for determining whether the basic integration and assembly are possible such as volume and mass margins; and those for determining whether the designed satellite system can actually operate, such as the link margin, power margin, and satellite system equilibrium temperature, as presented in

Table 7. Examples of basic feasibility criteria.

No.	Item	Criterion	No.	Item	Criterion
1	Mission Life	Three years or more	5	Power Margin	0 Whr or more
2	Volume Margin	0% or more	6	Max. Equil. Temp.	−10 °C to 40 °C
3	Mass Margin	0% or more	7	Min. Equil. Temp.	−10 °C to 40 °C
4	Link Margin	3 dB or more

. In the case of volume and mass margins, they indicate the differences between the size and mass (based on 1.33 kg for 1 unit) determined from the number of units in each direction (design variables) and the total size and mass calculated from the size and mass of payload and each satellite subsystem (design results).

To understand the significance of each design variable initially derived in Step 5 and obtain basic knowledge for design strategy, screening of DSE and analysis are first conducted. Typical DOE methods provided by commercial integrated system analysis tools can be used to generate big data for screening analysis. If there are discrete variables, one can use the custom DOE provided by commercial statistical software. In this example, 1500 design variable combinations (at least n² + n + 1 combinations are required when RSM is used, where n is the number of design variables) were created for the 35 design variables given in Table 6 and applied to the integrated design environment to obtain the design results for each combination.

The analysis of the existence of feasible design variable combinations by applying the basic feasibility criteria presented in Table 7 to the 1500 screening DSE results showed that only 74 design variable combinations satisfied all the criteria, constituting only 4.9% of the total number of combinations. Obviously, as the design space is very wide, it is difficult to find a design that meets various requirements from the 1500 cases DSE. Because analyzing almost infinite design variable combinations is inefficient, the optimization process performed in Step 8 is necessary even at the system-level design stage. Nonetheless, all 1500 cases are useful for creating metamodels.

To understand the significance of each design variable, a Pareto analysis is performed, as shown in Figure 7, which is for the Satellite System Mass engineering characteristic. The term in the left vertical axis is the magnitude estimate of the effect of a design variable, which is orthogonalized to be uncorrelated and standardized to have equal variances for all variables in statistics. Pareto analysis allows us to determine the degree of significance and effect of each design variable on the corresponding engineering characteristic in Table 3.

Table 8. System drivers for each engineering characteristic (in order of significance).

Group	Engineering Characteristic	System Drivers (In Order of Significance)
Mission Operation	QKD Mean Response Time	Data Antenna Beam Width, Inclination, Altitude, Max Attitude Angle
	GS Mean Response Time	Inclination, Altitude
	Required Delta V for Orbit Maintenance	Altitude, Satellite Y Size
System	Satellite System Mass	Satellite Z Size, QKD Optic Size, Satellite X Size, Satellite Y Size, Available Delta V, Specific Impulse, Structure Margin
	Power Margin	Solar Array Area Ratio, Satellite Z Size, Solar Array Efficiency, Satellite X Size, QKD Optic Size, Satellite Y Size, Altitude, Power Consumption Margin, Solar Array Degradation
	Mission Link Margin	Comm. Transmit Power, Satellite Control Antenna Size, Altitude, Comm. Realization Loss, Comm. Antenna Efficiency, Atmospheric Loss, Satellite Control Antenna Efficiency, Max Attitude Angle
	Daily Communication Data	Data Amount, Altitude, Daily TM Data Amount, Inclination, Data Antenna Efficiency
Link	Mission Data Up/Downlink Speed	Data Amount, Altitude, Daily TM Data Amount
Payload	Data Relay EIRP	Data Transmit Power, Data Antenna Beam Width, Data Antenna Efficiency
	Data Relay G/T	Data Antenna Beam Width, Data Antenna Efficiency
	QKD Key Rate	QKD Optic Size, GS QKD Optic Size, Altitude
	QKD QBER	Altitude, Inclination
Propulsion	Propellant Mass	Available Delta V, Satellite Z Size, Specific Impulse, Satellite X Size, Satellite Y Size
	Total Delta V	Available Delta V, Inclination
ADCS	Pointing Accuracy	Satellite Z Size, Satellite Y Size, Satellite X Size, CG Deviation Margin, Solar Array Area Ratio
	Slew Rate	Data Antenna Beam Width, Altitude, Max. Attitude Angle
EPS	Solar Array Power Generation	Solar Array Area Ratio, Satellite Z Size, Solar Array Efficiency, Satellite X Size, Satellite Y Size, Solar Array Degradation
	Satellite Maximum Required Power	QKD Optic Size, On/Off Time Margin, Altitude, Data Antenna Beam Width
	Battery Required Capacity	QKD Optic Size, Power Consumption Margin, On/Off Time Margin, Altitude
Comm.	Comm. EIRP	Comm. Transmit Power, Comm. Antenna Efficiency
	Comm. G/T	Comm. Antenna Efficiency
Structure	Bus Mass	Satellite Z Size, Satellite X Size, Satellite Y Size, Available Delta V, Specific Impulse, Structure Margin
	Satellite Size	Satellite Z Size, Satellite X Size, Satellite Y Size
TCS	Satellite Maximum Equilibrium Temperature	Radiator Usage, Satellite X Size, Satellite Y Size, Solar Array Area Ratio, QKD Optic Size
	Satellite Minimum Equilibrium Temperature	Radiator Usage, Satellite X Size, Satellite Y Size, Satellite Z Size, QKD Optic Size
Ground Station	Satellite Operation G/T	Satellite Control Antenna Size, Satellite Control Antenna Efficiency
	Satellite Operation EIRP	GS Max. Transmit Power, Satellite Control Antenna Size, Satellite Control Antenna Efficiency
	Mission G/T	Mission Antenna Size, Data Frequency, Mission Antenna Efficiency
	Mission EIRP	GS Max. Transmit Power, Mission Antenna Size, Data Frequency, Mission Antenna Efficiency
Reliability	Satellite Reliability	On/Off Time Margin, Data Antenna Beam Width, Altitude, Max Attitude Angle
Launch Vehicle	Launch Reliability (Launch Success Rate)	LV Cost Weighting
	Launch Cost (LV Cost per kg)	LV Cost Weighting

presents related design variables (system drivers) for each engineering characteristic in order of significance.

The initial design space can be efficiently reduced in the system-level design process by screening the design variables that have insignificant influence on the engineering characteristics on the basis of the information presented in Table 8. In addition, this design knowledge is significant in providing an actual system-level design strategy, such as which design variables should be adjusted when specific requirements are not met or specific engineering characteristics that are to be further improved in the optimization results in Step 8.

To screen design variables appropriately, the criteria given in

Table 9. Design variable screening criteria.

No.	Criterion
1	Design variables that have no effect on any engineering characteristic
2	A design variable for a specific engineering characteristic affected by only that design variable (This case can be treated separately using a parametric study)
3	Design variables that have an effect on a small number of engineering characteristics
4	Design variables that have a lower effect on “minor-priority” engineering characteristics
5	Low-significance design variables compared to other design variables for a specific engineering characteristic

are recommended. When applying Table 9, it is also recommended that at least two of criteria 3, 4, and 5 must be satisfied simultaneously.

Table 10. Screened design variables.

No.	Design Variable	Applied Criteria	No.	Design Variable	Applied Criteria
1	Solar Array Efficiency	3, 5	8	Data Code Rate	1
2	Solar Array Degradation	3, 5	9	Atmospheric Loss	3, 5
3	Specific Impulse	4, 5	10	Comm. Realization Loss	3, 5
4	CG Deviation Margin	3, 5	11	Satellite Control Antenna Efficiency	4, 5
5	Structure Margin	3, 5	12	Mission Antenna Efficiency	3, 4, 5
6	Daily TM Amount	3, 4, 5	13	LV Cost Weighting	2
7	Data Frequency	3, 4, 5

lists the screened design variables according to the system drivers for each engineering characteristic given in Table 8 and the criteria given in Table 9.

Accordingly, 13 design variables were screened out of the initial 35 design variables, and 22 design variables were finally chosen, which can be called the final system drivers. In the DSE and analysis for the finally chosen design variables, the default values are set to the screened design variables.

As in the screening, DSE and analysis for the final system drivers are conducted. Again, typical DOE methods are used to generate the big data. A total of 1000 design variable combinations were created for the 22 design variables and applied to the integrated design environment to obtain the design results for each combination. The analysis based on the basic feasibility criteria for the 1000 DSE results shows that only 45 design variable combinations satisfy all the criteria, which constitute only 0.45% of the total number of combinations. Although the design space is reduced, a very small number of design results from DOE satisfy the basic feasibility conditions.

An example of a prediction profiler as shown in Figure 8 can be obtained by generating metamodels such as RSMs as a function of design variables by statistical analysis for engineering characteristics. The prediction profiler visually indicates the influence of each design variable on each engineering characteristic within its range of variation, so that one can quickly acquire design knowledge such as the sensitivity of each design variable and its effect trends.

3.8. Step 8: Optimize the System-Level Design

This step involves the process of finding the point design that best achieves the mission objective at the system level in the entire design space under the proposed framework. The combination of design variables that maximize the objective function is found using the metamodels created in Step 7. If the metamodels are usually RSMs, the optimization is relatively easy because the models are represented as second-order polynomial equations. The objective function (performance index) is given as Equation (1):

$$Maximize Obj=\frac{{\displaystyle \sum _{j=maximize}{w}_j\frac{E{C}_j}{E{C}_{j,ref}}}}{{\displaystyle \sum _{k=minimize}{w}_k\frac{E{C}_k}{E{C}_{k,ref}}}}$$

(1)

where $j$ and $k$ are the indices and subscripts of the engineering characteristics (ECs) listed in Table 3, which should be maximized and minimized, respectively. The subscript ref indicates the reference value for the normalization of each engineering characteristic. $w_{j\hspace{0.17em}or\hspace{0.17em}k}$ is the weighting for each EC derived from the QFD process in Step 4. The constraints for the optimization are those given in Table 7 to ensure basic feasibility.

Optimization leads to a point design close to the optimal area that maximizes mission objectives in a very large design space (see Figure 3). In other words, the optimization yields the design variables and engineering characteristics that best satisfy the mission objectives in the proposed design framework, and they are used to construct the system-level requirements of the mission, system, and subsystems to start the preliminary design phase.

The optimization result based on the metamodels is refined with the actual system algorithms. The resultant values of design variables obtained from optimization are directly input to the integrated design environment to retrieve the actual values of ECs. Because the design variable values obtained from the optimization results are obtained by using a rigorous mathematical method, their values include decimal points, which is not significantly meaningful at the system level. It is better to convert them into typical values according to the conceptual design level considering each design variable for the future design stages. For example, the solar array area ratio and the satellite sizes are converted into a standard unit (without a decimal point) considering manufacturing. The resultant design variables and ECs of the final baseline design along with optimization results are given in

Table 11. Design variable values of the final baseline design.

Group	No.	Design Variable	Optimization	Baseline Design
Mission Operation	1	Altitude (km)	520.4377	520
	2	Inclination (deg)	52.7768	53
Payload	3	Data Transmit Power (W)	9.0458	9.0
	4	Data Antenna Beam Width (deg)	62.8570	63
	5	Data Antenna Efficiency (%)	75.3939	75
	6	QKD Optic Size (m)	0.2019	0.2
Bus	7	Comm. Transmit Power (W)	1.6402	1.6
	8	Comm. Antenna Efficiency (%)	77.6443	78
	9	Solar Array Area Ratio	3.0	3
	10	Power Consumption Margin (%)	19.0937	19
	11	On/Off Time Margin (sec)	128.9578	129
	12	Max. Attitude Angle (deg)	42.8588	43
	13	Available Delta V (m/s)	31.0054	31
	14	Satellite X Size (U)	3.7437	3
	15	Satellite Y Size (U)	3.5085	3
	16	Satellite Z Size (U)	3.0493	4
	17	Radiator Usage (U)	38.5309	38
Link	18	Data Amount (Mbyte)	8.9158	9
Ground Station	19	GS QKD Optic Size (m)	0.4999	0.5
	20	GS Max Transmit Power (W)	97.5799	98
	21	Satellite Control Antenna Size (m)	2.3851	3
	22	Mission Antenna Size (m)	6.5983	6

and

Table 12. Engineering characteristics of the final baseline design.

Group	No.	Engineering Characteristic	Optimization	Baseline Design
Mission Operation	1	QKD Mean Response Time (h)	7.5095	8.9169
	2	GS Mean Response Time (h)	3.1945	3.5386
	3	Required Delta V for Orbit Maintenance (m/s)	0.2188	0.2433
System	4	Satellite System Mass (kg)	39.3187	37.4631
	5	Power Margin (Whr)	71.2454	79.2533
	6	Mission Link Margin (dB)	21.2085	22.6545
	7	Daily Communication Data (Mbyte)	29.3203	30.7177
Link	8	Mission Data Up/Downlink Speed (kbps)	359.2824	401.3080
Payload	9	Data Relay EIRP (dBW)	17.7956	18.3309
	10	Data Relay G/T (dB/K)	−18.2028	−18.0932
	11	QKD Key Rate (cps)	7598.49	6694.58
	12	QKD QBER (%)	3.4691	3.4672
Propulsion	13	Propellant Mass (kg)	4.1365	4.0276
	14	Total Delta V (m/s)	34.4505	34.4444
ADCS	15	Pointing Accuracy (deg)	0.0153	0.0153
	16	Slew Rate (deg/sec)	1.0256	1.0432
EPS	17	Solar Array Power Generation (W)	106.8539	113.3950
	18	Satellite Maximum Required Power (W)	10.8964	10.8663
	19	Battery Required Capacity (Whr)	55.9974	56.0343
Comm.	20	Comm. EIRP (dBW)	2.3046	2.1122
	21	Comm. G/T (dB/K)	−26.8316	−26.8107
Structure	22	Bus Mass (kg)	26.2754	24.7073
	23	Satellite Size (U)	41.2370	36
TCS	24	Satellite Max. Equilibrium Temperature (degC)	19.6866	21.8099
	25	Satellite Min. Equilibrium Temperature (degC)	−3.7018	−8.9892
Ground Station	26	Satellite Operation G/T (dB/K)	−7.1086	−5.4918
	27	Satellite Operation EIRP (dBW)	32.9559	34.7238
	28	Mission G/T (dB/K)	20.4748	19.5658
	29	Mission EIRP (dBW)	60.5693	59.7814
Reliability	30	Satellite Reliability	0.9427	0.9426
Launch Vehicle	31	Launch Success Rate (%)	100	100
	32	Launch Vehicle Cost per kg (USD)	72,450	72,450

, respectively.

Some other ECs of interest are listed in

Table 13. Other engineering characteristics of the final baseline design of interest.

Group	No.	Engineering Characteristic	Baseline Design
Mission Operation	1	QKD Daily Average Revisit Time (h)	11.86
	2	GS Daily Average Communication Time (h)	0.17
System	3	Satellite Volume Margin (%)	40.21
	4	Satellite Mass Margin (%)	28.87
Payload	5	Data Antenna Size (m)	0.11
	6	QKD Payload Size (U)	12.4
	7	QKD Payload Length (m)	0.31
Bus	8	Comm. Antenna Length (m)	0.32
	9	Solar Array Area (m2)	0.72
	10	Pointing Stability (km)	0.14
	11	Satellite Volume (m3)	0.036
	12	OBC RAM Capacity (Mbyte)	54.6
Schedule	13	Total RDT&E Schedule (Month)	49
	14	FM Manufacturing Schedule (Month)	18
Cost	15	Total Life Cycle Cost (M USD)	24.65
Product Assurance	16	Minimum Required Radiation Tolerance (krad)	19.5

, and the three-dimensional (3D) rendering of the final baseline satellite design is shown in Figure 9.

Suppose there are constraints in currently available commercial products or limitations from development and manufacturing standpoints. In that case, actions are taken by fine-tuning the design near the optimized design point (see Figure 3) through parametric studies of the relevant system drivers, referring to Table 8. For example, if the currently available QKD optical system size is not allowed to be more than 0.1 m, a parametric study while maintaining other design variables (optimized values) intact can be performed through the integrated design environment, as shown in Figure 10. Of course, referring to Table 7, the study is conducted for the ECs affected by the QKD optic size.

In some cases, the requirements for specific ECs may not be satisfied by the constraint of the QKD optic size of 0.1 m or less. One can refer to Table 8 to choose other system drivers affecting the violated ECs and perform the parametric study again with the chosen drivers to satisfy them. If specific ECs are still not met through parametric studies, wider design space, a trade-off for those requirements, or new technology infusion may be required. Here, it is emphasized that the design revision to meet the constraints inside the design space should be conducted near the system-level baseline design obtained through the mission-oriented design process.

3.9. Step 9: Elaborate Mission Utility and System Requirements

In this step, quantitative measures of effectiveness are first calculated to assess the mission utilities for the optimization result and system-level baseline design relative to the alternatives from DOE. The quantitative OECs are calculated using the TOPSIS method with 45 feasible designs from DOE and an initial optimization design. The OEC value of the initial optimization is 0.7240; the OEC distribution for DOE designs is shown in Figure 11. The average value of OEC for 45 feasible DOE designs is 0.4972. The highest value is 0.6257, and the lowest value is 0.2952. The optimization yields a better design than the design alternatives randomly chosen from the DOE, as expected.

If the baseline design modified from the initial optimization is included in the TOPSIS analysis, the OEC value of the initial optimization is slightly changed to 0.7202, and the baseline design has an OEC value of 0.7045. Thus, the baseline design is confirmed to have been found in the design near the initial optimization point. If several parametric studies should be performed, one can intuitively assess the extent to which the OEC (overall mission utility) changes for each design modification relative to the baseline design.

Evidently, sufficient knowledge about the design space can be obtained from the proposed design process. System requirements can be determined with more confidence based on this knowledge. In particular, the design variables that are system drivers and the extent to which the values of ECs can be achieved were identified. In addition, a mission-oriented baseline design was derived. Because the baseline design becomes a reference for improvement in subsequent design stages, it is recommended to set the engineering characteristic values within a certain margin derived from the baseline design as the system requirements.

3.10. Step 10: Allocate System Requirements to System Elements

The chosen system requirement set in the previous step flows down relevant system elements. One can follow the generic process to accomplish this and proceed to the preliminary design phase.

4. System Algorithms

The system algorithm is an important part that forms the basis of the proposed design framework and directly influences the reliability of the system-level design result. The developed tools based on system algorithms must include all mission elements identified in the concept of operations and architectures, and their associated technical performances as well as configuration properties such as mass, size, link, cost, and acquisition schedule should be analyzed for strategic decision making with a holistic view. The properties that a system algorithm must possess are summarized as follows:

(1)

Computational efficiency: this is the most important property because it is essential to generate big data for analyzing a wide design space and identifying characteristics of the design space.

(2)

Preference for the physics-based approach: to increase the reliability of DSA, a physics-based analysis is preferred.

(3)

Development in black-box format: for integrated analysis including all subsystems, each system algorithm is developed in black-box format along with ICD.

Note that even though the system algorithm is implemented based on the physics-based formulae, the experiences of engineers should be reflected in tuning parameters such as the charge/discharge efficiency of the battery and implementation loss in the link budget. These parameters are usually too detailed or of low significance in the system-level design phase; however, the experiences of expert engineers allow us to derive a practical and realistic system-level design by setting reasonable values for those parameters.

Because this paper focuses on a novel satellite system-level design framework, each system algorithm will be briefly described in this section without going into too much detail.

4.1. Mission Operation

The mission orbit is designed by using analytical methods, assuming a circular orbit based on the given altitude and inclination and considering the region of interest (ROI), repeated ground orbit, and sun-synchronous orbit. Changes in orbital elements are analyzed by considering J₂ perturbation and atmospheric drag. Orbit deployment control is implemented as a thruster-based two-time instantaneous thrust control, and orbit maintenance control is implemented by applying instantaneous thrust every specific period [34].

The access characteristics (period and time) of the mission ROI are calculated according to the geometric relationship between the ROI and the satellite and the change in the right ascension of ascending node according to the orbit dynamics. The maximum Earth central angle (from the target to the subsatellite point at the center of the Earth) determines whether to visit or not according to the elevation angle of the ROI, attitude control range, and payload beam width. With this process, calculating the relevant access characteristics for the ROI, such as the mean response time, is possible.

The mission lifetime is taken as the minimum value by comparing the lifetime of the satellite parts with the thruster lifetime calculated from the total available delta V and the delta V required for orbit deployment and maintenance.

The mission operation system algorithm additionally provides the number of satellite operating mode changes and minimum and maximum daylight hours.

4.2. System

Configuration information such as the power margin for each satellite operation mode, the communication amount and link margin for each data communication link, and the size and mass of each part of the satellite are combined to determine the feasibility of the entire system. This system algorithm outputs daily communication amount, mission link margin, power margin, volume margin, and mass margin. For example, the volume margin is the ratio of the free volume to the total volume of the satellite, considering the sum of each part volume. The mass margin is the ratio of the free mass to the total mass of the satellite based on the mass obtained by applying the mass ratio of 1.33 kg per 1U (a typical standard for nanosatellites), considering the sum of each part mass [35].

4.3. Data Relay Payload

Effective isotropic radiated power (EIRP) and antenna G/T, the main performance factors of the data relay payload, are calculated from the transmit power and antenna beamwidth. Antennas are divided into four types—half-wave dipole, patch, helix, and parabolic patch antenna—and the gain of each antenna is calculated considering loss such as orientation error and noise temperature. The diameter or length of each antenna is calculated using the wavelength, frequency, and permittivity [36]. The configuration information, such as mass, power consumption, size, and cost, is derived from commercial transceivers proven in the space environment.

4.4. QKD Payload

The key rate and quantum bit error rate are calculated considering the sizes of the QKD optic system and the GS optic system, quantum generation rate, wavelength on the transmitting side, slant range, elevation angle, and losses between the satellite and ground station [37,38,39]. Figure 12 shows an example analysis for the variation of key rate with elevation angle for different optic sizes of satellite and ground station and quantum generation rate conducted by the QKD payload system algorithm alone. The required pointing accuracy is calculated by considering the pointing, acquisition, and tracking (PAT) angle range and the half-power beam width calculated from the wavelength and the QKD optic size.

The masses and sizes of the reflector and barrel are obtained using scaling based on the QKD optic diameter. Further, the masses and sizes of the quantum transmitter and beacon transceiver are obtained by referring to existing products. Power consumption is calculated by referring to the specifications of existing products considering the duty cycle. Costs are estimated by referring to existing parts, including development costs.

4.5. Bus

4.5.1. Comm. Subsystem

EIRP and antenna G/T are calculated from the transmit power and antenna beamwidth by applying the same method as the data relay payload. The configuration information, such as mass, size, cost, and power consumption, is estimated by referring to existing products.

4.5.2. Electrical Power Subsystem

From the information on mission operation and orbit and power consumption information of each subsystem of the satellite, the system algorithm calculates minimum/maximum power consumption, solar panel area, and performance, battery required capacity, and power margin for each operation mode, such as mission mode and communication mode.

The solar panel area is calculated according to the three deployment methods (design variables) shown in Figure 13. The minimum power generation is calculated by considering the sunlight incident angle, solar panel power efficiency, area, and solar panel degradation rate with the intended mission life. The required power for each operation mode is calculated considering active subsystems in each mode and the duty cycle. The on/off time margin—the maximum time it takes to start operating after power input—is considered for subsystems other than those always used, such as the onboard computer and electrical power system (EPS).

The configuration information, such as mass, size, power consumption, and cost, is estimated by referring to existing products. The information for the battery module is predicted from regression equations (assigning required battery capacity as input variable) created using the data of existing products.

4.5.3. Attitude Determination and Control Subsystem

The attitude pointing accuracy, slew rate, and the required torque and momentum of the reaction wheels are calculated using the maximum attitude angle, the physical characteristics of the reaction wheel, and the torque and momentum margin. For this purpose, information on the mission altitude, ROI visit time, satellite moment of inertia, satellite cross-sectional area, and distance difference between the center of mass and geometric center is utilized. The star tracker is applied by default, considering the QKD mission.

Attitude pointing accuracy is calculated according to the attitude determination precision error of the sensor and the static and dynamic imbalance of the reaction wheels [40]. When calculating the required torque for the reaction wheel, perturbations due to gravity gradients, solar radiation pressure, the Earth’s magnetic field, and atmospheric drag are taken into account.

The configuration information, such as mass, size, cost, and power consumption, is calculated from the information from existing commercial products.

4.5.4. Propulsion Subsystem

After calculating the required maximum thrust, delta V, and propellant mass, the configuration information, such as mass, size, cost, and power consumption, is estimated by creating regression models for the required propellant mass using the information of existing products.

4.5.5. Structure

The bus total mass, moment of inertia, cross-sectional area, surface area, volume, and position difference between the center of mass and the geometric center are calculated from the size of each axis of the satellite, density, and thickness of the solar panel, and margins considering the design uncertainties such as the mass of harness and miscellaneous parts.

The bus total mass is calculated by summing up the mass of each subsystem with the mass margin. The moment of inertia is calculated by reflecting the solar panel deployment method defined in the EPS and using the parallel-axis theorem. Mass and cost are calculated by creating regression models for the size using the structural information of various existing products.

4.5.6. Thermal Control Subsystem

The minimum and maximum equilibrium temperatures are calculated by assuming the satellite to be a blackbody. For this purpose, the ratio of radiator and insulation area in the total surface area of the satellite, solar absorption, infrared (IR) radiation, effective radiation, and the ratio of daylight hours during the orbital period are taken into account. The solar absorption, IR radiation, and effective emissivity/density are assumed to be representative values given in references [2,3].

Mass is estimated from the satellite surface area and the ratio of radiator and insulation with their densities. The power consumption is calculated by considering the power consumption and duty cycle of heaters used for EPS and QKD optical systems, which are active thermal control modules. The cost is estimated from the power consumption of the active thermal control module.

4.5.7. Command and Data Handling Subsystem

The processing speed, required memory, storage capacity of the onboard computer, and flight software source lines of code (SLOC) are calculated. The processing speed is derived according to million instructions per second, and the memory is estimated on the basis of SLOC. Storage capacity is assumed to be the sum of control and mission data. The configuration information, such as mass, size, cost, and power consumption, is estimated by referring to existing products.

4.6. Ground Station

Because the characteristics of control communication and mission communication are different in general, each EIRP and antenna G/T is calculated, assuming that facilities for control and mission communication are separately constructed. The antenna orientation error is considered through the antenna efficiency. The antenna is assumed to be a Yagi–Uda antenna for frequencies below the L-band and a reflector type for frequencies above the L-band. The beamwidth and gain are calculated according to each antenna type [36,41]. The cost of the ground station is dealt with in the cost system algorithm.

4.7. Launch Vehicle

A database for 44 launch vehicles is built with information on launchable altitude, payload mass and volume, launch success rate, and launch unit price per kg [42,43,44]. The optimal launch vehicle is recommended according to LV cost weighting as a design variable indicating the weight for the unit price relative to the launch vehicle reliability.

4.8. Reliability

The satellite system reliability and the minimum radiation tolerance to achieve the target lifetime are calculated. Reliability is obtained by applying the method presented in MIL-HDBK-217F [45] using the failure rate, redundancy, operating temperature, failure rate coefficient during non-operation, and duty cycle for each module. In the case of radiation tolerance, the minimum required radiation tolerance is estimated to provide the information on the required amount of shielding, assuming that radiation exposure is 6.5 krad per year in LEO [46].

4.9. Cost

Cost is calculated according to three phases of the life cycle: RDT&E, production, and operation and maintenance. To increase the reliability of cost estimation, a combination of grassroots cost estimation and the parametric cost model is used. The cost is estimated using the small-satellite cost model (SSCM) [47], which is a parametric cost model; however, the grassroots cost is applied to the part where information on the latest cost can be obtained. SSCM estimates life cycle cost using the cost estimating relationship (CER), including satellite development cost and ground station development and operation cost. The launch cost is calculated from the unit cost suggested in the launch vehicle system algorithm and the satellite mass and added to the overall cost system algorithm.

4.10. Schedule

The schedule comprises satellite design, payload and bus development, assembly, integration and test (AIT), launch vehicle schedule, ground station construction and operation, and administrative processing to estimate the entire life cycle schedule and development schedule [48]. AIT is assumed to begin after the end of payload and bus development, and ground station construction is to begin after the critical design review. The launch schedule includes launch vehicle selection, contract schedule, and launch campaign. Subject matter experts suggest the schedule for each element.

5. Conclusions and Future Work

The SMAD process is frequently used in three areas: (1) the development process up to the initial conceptual design stage, (2) the demonstration of feasibility and economic viability for decision making on whether to develop, and (3) the creation of a portfolio of new technologies by identifying gaps in current technologies.

In this paper, a novel design framework is proposed to aid the generic SMAD process, focusing on a mission-oriented approach and process efficiency (reducing design iterations). The proposed process results in a system-level baseline through a consistent, mission-oriented top–down design process based on a system-level physics-based approach and entire design space exploration and analysis. It allows one to acquire sufficient knowledge of the entire design space and make knowledge-based decisions. The validity of the proposed process is demonstrated with an example of quantum cryptographic communication satellite design.

To maintain the mission-oriented design process, several systems engineering techniques such as QFD and AHP are utilized, and optimization is performed according to the relative importance of the ECs obtained from QFD to derive the final system-level baseline design. In addition, the degree of mission achievement among various design alternatives is presented more clearly through OEC. For the efficiency of the design process, statistical techniques such as metamodel generation, prediction profiler, and Pareto analysis are used.

These features of the proposed framework clearly provide a direct connection between mission objectives and the final system-level baseline and requirements through the comprehensive quantitative criterion (OEC) and explicitly describe the process of improving the design. Moreover, quantitative top-level mission requirements and information on system drivers and critical requirements are confidently determined with sufficient knowledge of the design space. Optimization further leads to a near-optimal system-level design with information on the degree to which the resultant design meets the mission objectives. Notably, the proposed systematic process allows us to simultaneously handle the entire design space by employing the appropriate systems engineering and statistical techniques. Considering that VOC in the space industry has been diversified as the commercial space industry is rapidly growing, the proposed framework directly reflecting VOC is helpful as the systematic process for making decisions rapidly on initiating new projects and deriving/changing system designs with relatively low human resources and cost.

The limitations to consider when applying the proposed framework are as follows. Exploring and analyzing the entire design space can be time-consuming when there are a large number of architectures that can achieve the mission. In addition, efforts to develop corresponding system algorithms are required when new payloads or bus subsystems need to be considered.

Future work includes the identification of the difference in the system-level baseline design when the relative importance of stakeholder needs changes. In addition, it is necessary to perform additional validation of the proposed framework by applying it to other missions and other SMAD application areas. To overcome the limitations on application to extremely wide design spaces due to the ambiguous mission concepts, a hierarchical SMAD process utilizing the proposed approach will also be studied.