# Similarity Assessment of the Engineering Concepts: Decision-Making Support and Metrics

Yaroslav Menshenin, Suhail Alsalehi, Markus Guerster, Edward Crawley

► To cite this version:

Yaroslav Menshenin, Suhail Alsalehi, Markus Guerster, Edward Crawley. Similarity Assessment of the Engineering Concepts: Decision-Making Support and Metrics. Systems Engineering, 2025, 10.1002/sys.21812. hal-04996874

HAL Id: hal-04996874

https://hal.science/hal-04996874v1

Submitted on 19 Mar 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Similarity Assessment of the Engineering Concepts: Decision-Making Support and Metrics

Yaroslav Menshenin<fnref n="1" /> ID | Suhail Alsalehi² | Markus Guerster<fnref n="3" /> | Edward Crawley<fnref n="3" /> ID

**Correspondence:** Yaroslav Menshenin (yaroslav.menshenin@grenoble-inp.fr)

**Received:** 31 May 2024 | **Revised:** 22 January 2025 | **Accepted:** 26 February 2025

**Funding:** The authors received no specific funding for this work.

**Keywords:** decision-making | MBSE | new product development (NPD) | product concept | similarity in design | systems engineering

## ABSTRACT

The new product development (NPD) process is a systematic approach to bring new products and innovations to market. Nowadays, this process is affected by a number of influencing factors associated with the fast-paced technological changes. One of those factors is the distributed design nature of product development activities: team members are spread geographically having different cultures, languages, time zones, and level of digital engineering tools awareness and utilization. Another factor is the customization of the products to meet the requirements of different customers, or the different requirements of the same customer for product variants. This is linked to the need of being able to predict the next generation of products. All those factors influence the embodiment of the engineering concept into the final product. What is critically important in such an engineering environment is to properly encode and track the engineering concepts to enable smooth planning and management of the next generations of products. One of the critical needs in this process is the assessment of the engineering concepts' similarities. This paper presents a method for the similarity assessment of product concepts through the integration of the decision-making support and mathematical representation of similarity scores. To demonstrate its utility, the proposed approach is applied to seven alternative suborbital spaceflight concepts. Using the proposed method, the pairwise similarity score among them is calculated quantitatively. A practical utility of the paper is that it presents an approach to evaluate product concepts' similarity in any industrial and business sector.

## 1 | Introduction

The new product development (NPD) process is a systematic approach to bring new products and innovations to market. Nowadays, this process is affected by a number of influencing factors associated with the fast-paced technological changes. One of those factors is the distributed design nature of product development activities: team members are spread geographically having different cultures, languages, time zones, and level of digital engineering tools awareness and utilization. This creates not only technical layers of complexity, but also the cognitive ones [1].

Various engineering approaches were proposed to facilitate the distributed design activities in the engineering domain, such as a virtual environment with the support of audio and speech recognition [2]. Virtual reality (VR) in engineering was also studied to enable the modification of the shapes created in VR during the early stage of the design into the CAD software in detailed design [3]. The integration of the 3D virtual environment with the SysML-based model was discussed in [4]. The VR applications support the design representations, yet they have limitations in regards to the evaluation of product concept similarities, especially, when it comes to the quantitative nature of such assessment.

This is an open access article under the terms of the Creative Commons Attribution License, which permits use, distribution and reproduction in any medium, provided the original work is properly cited.

© 2025 The Author(s). Systems Engineering published by Wiley Periodicals LLC.

<footnote n="1">¹G-SCOP, CNRS, Grenoble INP, Univ. Grenoble Alpes, Grenoble, France | ²Systems Engineering Department, Boston University, Boston, Massachusetts, USA |</footnote>

<footnote n="3">³Department of Aeronautics and Astronautics, Massachusetts Institute of Technology, Cambridge, Massachusetts, USA</footnote>
The feasibility studies for the concepts were performed through the concurrent engineering (CE) [5, 6] methodology. A widely used in space programs [7, 8], CE became a means to connect different engineering specialists equipped with the same method to achieve the space mission objectives in a collaborative manner. It was discussed that the computer-supported collaborative design (CSCD) framework [9] covers a broader set of stakeholders and teams, comparing to the CE approach. However, those methods are limited to the feasibility studies.

Another factor influencing the complexity within the NPD process is the necessity to customize products [10] to adapt them to the different needs of various customers; or to different requirements of the same customer for product variants. For this, the ability to evaluate the similarities between different solutions plays an important role, as it would enable prediction and management of the next generations of products for the product platforms [11, 12]. Such capability is paired with the engineering design teams' intent to reserve a design margin [13, 14] for a future change in product design to launch the next generations of products. In such context, the ability to assess the engineering concepts' similarities would increase the systems engineering team's awareness of the product similarities on different levels of granularity [15] — on the product level, as well as for the product components. Ultimately, knowing the product similarities vector would speed up the product development process, positively contributing to the time-to-market strategy.

This paper is structured as follows. Section 2 is dedicated to the review of the similarity in design (Section 2.1), the model-based systems engineering (MBSE) support review (Section 2.2), and the research gaps and objectives (Section 2.3). The methodology is provided in Section 3, in which the approach to encode the concept alternatives is provided in Section 3.1, and the application of the similarity score is discussed in Section 3.2. Section 3.3 is dedicated to the operational taxonomical units and binary similarity. The case study of the suborbital human spaceflight concepts is introduced in Section 4. Using the system concept representation framework (SCRF), the conceptual data for the suborbital concepts is encoded in a modeling environment (Section 4.1). Section 4.2 presents an example of the encoding of the “Blue Origin” concept. After this, in Section 4.3 the architectural decisions table for suborbital concepts is built. Section 4.4 discusses the alternative suborbital concept representations. In Section 4.5 the binary vector is constructed to encode alternative concepts, and the similarity scores are computed for those concepts. The key results are discussed in Section 5. Section 6 concludes the paper.

# 2 | Similarity in Design and Model-Based Systems Engineering Support

## 2.1 | Similarity in Design

The idea of using similarity in design is not new. It was studied to propose a framework measuring the requirements similarities [16], enabling the reuse of the requirements for the new product from the requirements of the previously developed products. The core issues related to the concept of similarity assessment were considered through addressing issues in cognitive science and AI

[17]. A similarity measure is used in the engineering model within the European Space Agency [18]. Such model provides recommendations for system design through the similarity of metadata, which is used to analyze the similar components. Although the authors of that work used the Jaccard similarity matrix, the research gap is still present: how could systems engineers encode the architectural decisions data through the digital engineering solution to enable conceptual similarity analysis on product level. Such assessment should be started at the conceptual design stage.

The conceptual design stage is characterized by a high level of uncertainty concerning the final embodiment of the product concept. At this stage, the systems engineering team members need to make decisions that lead to alternative product concepts. The engineers often rely on expertise to evaluate alternative solutions by comparing their projected cost and performance. Existing concept evaluations rely on quantitative data (e.g., cost and performance metrics) to get insights and make decisions. At the conceptual design stage, such data might be unavailable or inaccurate: the customers often have fuzzy stated needs which should be clarified and detailed before tracing them to the system requirements. For a complex system, predicting the cost and performance is a difficult task as there is uncertainty around these metrics. To overcome these drawbacks, the evaluation tools need to utilize available conceptual data, which is often unstructured and incomplete at this stage.

This paper presents a similarity assessment tool that uses the data encoded through a model-based system architecture method informing the architectural decision table. The similarity measures approach is inspired by the works in the system biology [19] and semantic similarity [20] fields.

The definition of the similarity measure is based on the similarity function. This function is used to quantitatively assess the similarity between two objects [21]. In the lack of a formal definition of similarity measure, it can be defined as the inverse of the distance metrics. For instance, consider two points of data, which have close x and y coordinates. In this case, the probability of similarity between those two data points is higher than that of two data points having a larger distance between the x and y coordinates.

In this paper, a normalized similarity measure taking the values in the interval between 0 and 1 is used. If the two objects have a similarity measure close to 0, they are considered as dissimilar; and vice versa: a similarity measure close to 1 would mean that the two objects under consideration are almost identical.

The similarity assessment capability would support systems engineers, engineering design teams, and decision-makers during the early phases of product concepts evaluations. Furthermore, system engineers could use the concept of similarity assessment to reduce the size of design spaces by clustering concepts that are similar.

## 2.2 | Model-Based Systems Engineering Support

MBSE appeared around three decades ago [22] to overcome “the limitations of document-based approaches” [23] through the model-based paradigm. The core idea is to enable a “single source
of truth” through the system models rather than documents. Such
system models would create a digital thread throughout the entire
product lifecycle, establishing traceability among all key entities
of the system development process — stakeholders and their
needs, system requirements, and logical & physical architecture.

MBSE is an instrument transforming engineering practice in
different industries — from aerospace [24] to MedTech [25]
— into the digital, model-based paradigm. Therefore, it is not
by coincidence that large vendors (such as Dassault Systemes,
Siemens, IBM, and others) have developed sophisticated software
to enable MBSE in industrial settings.

The MBSE [26–28] is backed up by the systems engineering prin-
ciples and methods that need to be properly exploited to enable
digital transformation in the R&D environment. To enable early-
phase system modeling, the model-based system architecting
method has been proposed [29] and is used as the basis for the
SCRF framework utilized in this work.

## 2.3 | Research Gaps and Objectives

There is at present a lack of rigorous tool that would quantitatively
assess the conceptual similarity between alternative product con-
cepts based on the core architectural decisions needed to be made
at conceptual design phase. This paper aims at fulfilling this gap.

Thus, there is a research opportunity to create a decision-making
support framework for similarity assessment between alternative
concepts. The conceptual similarity assessment can be used as a
proxy for the cost of change from one concept to another, or from
one system component to another one.

The specific objective of this paper is to present a decision-making
support framework that can systematically encode alternative
concepts and enable the similarity assessment of them. As the
case study, the proposed approach is applied to similarity assess-
ment of the alternative suborbital human spaceflight concepts.
In particular, the framework is validated through its applica-
tion to seven suborbital concepts studied in this work: Blue
Origin, Virgin Galactic, 2-stage spaceplane, XCOR, Copenhagen,
Rocketplane, and Shuttle concept.

The proposed framework has several forms of utility. One form
of utility is that it allows the encoding of unstructured product
concepts' data systematically through the SCRF framework.
Such unstructured concepts' data is contained in a variety
of documents specifying suborbital systems, as well as in
stakeholders' and experts' knowledge, which can be extracted
using SCRF. SCRF is traced to the architectural decisions table,
which both serve as the decision-making support approach and
further inform the similarity metrics. The Conceptual Similarity
Assessment Tool (CSAT) is used to evaluate alternative suborbital
concepts.

The proposed approach might be used by systems engineers,
engineering design teams, and decision-makers as a tool for a
proxy for change cost from one concept to another. In addition,
the proposed method provides a systematic approach to sup-
port the decision-making process through the systems modeling

approach and the development of the architectural decision
table.

## 3 | Methodology

The methodology for similarity assessment of the engineer-
ing concepts comprised two elements. The first is the SCRF
framework introduced in a PhD Thesis and then adopted as
a decision-making support tool for model-based system archi-
tecting [29, 30]. The SCRF framework is briefly discussed in
Section 3.1. The second element is the CSAT [31], which utilizes
the structured information obtained using the SCRF framework
to assess similarity among product concept alternative solutions.
The CSAT application is introduced in Section 3.2.

### 3.1 | Encoding Concept Alternatives Through the SCRF Framework

The core idea of the SCRF framework is the introduction of key
entities required to represent a concept [32], supported by the
MBSE approach [33–36]. The core 28 entities of SCRF are spread
among five domains depicted in Figure 1. For more details about
SCRF, see [29, 30].

The SCRF framework is used to encode the alternative suborbital
concepts into the model-based system architectures, which
would be developed with the same systems method and store
the same amount and type of concepts-related data. The SCRF
framework uses the Object-Process Methodology (OPM) [37] and
its conceptual modeling environment OPCloud [34]. The diagram
in Figure 1 is built in this Cloud-based modeling environment.
Five core domains are depicted in Figure 1. The *Stakeholders (D1)*
domain captures stakeholders and their needs. The purpose of
the *Solution-Neutral Environment (D2)* is to establish a solution-
independent problem statement which is open to all possible
technical means to satisfy that problem. Narrowing those abstract
concepts toward a more concrete alternatives is performed within
the *Solution-Specific Environment (D3)* domain, which outlines
potential alternative product concepts. The *Integrated Concept
(D4)* domain is meant to decompose each one of those solutions.
The *Concept of Operations (D5)* domain encodes how the product
concept is expected to perform its activities to meet stakeholders'
expectations.

## 3.2 | Application of CSAT

Having the data encoded in the SCRF framework, the next step
is to create the architectural decisions table. The table consists
of architectural decisions corresponding to system function and
form options for each architectural decision. Each function can
be fulfilled using one or more form options. Ultimately, the
architectural decisions table serves as a decision-making support
having the concept elaboration and core conceptual information
as an input, and the structured data enabling the creation of
binary vectors as an output.

In the next step, each alternative is represented by its form
options from the architectural decisions table. Weights can be
<figure><img src="image_2.png" /><figcaption>FIGURE 1 | Five domains of the system concept representation (SCRF) framework (adapted from [29]).</figcaption></figure>

<table><caption>TABLE 1 | Binary similarity measures.</caption><thead><tr><th>Concepts</th><th>x (presence)</th><th>x&#773; (absence)</th><th>Sum</th></tr></thead><tbody><tr><td>y (presence)</td><td>a = x * y</td><td>b = x&#773; * y</td><td>a + b</td></tr><tr><td>y&#773; (absence)</td><td>c = x * y&#773;</td><td>d = x&#773; * y</td><td>c + d</td></tr><tr><td>Sum</td><td>a + c</td><td>b + d</td><td>n = a + b + c + d</td></tr></tbody></table>

assigned to each architectural decision to reflect the importance of each architectural decision. This is followed by encoding the representation of the alternative concepts into binary vectors using a technique called one-hot encoding.

Finally, these binary vectors are processed using a similarity measure to determine pair-wise similarity scores among the different alternative concepts.

In summary, the approach has five steps:

Step 1: Create a model-based system architecture representation of the concepts using the SCRF framework;

Step 2: Create the architectural decisions table;

Step 3: Represent alternative concepts by their form options;

Step 4: Encode alternative concept representation by a binary vector;

Step 5: Compute pair-wise similarity scores among alternative concepts.

## 3.3 | Operational Taxonomical Units and Binary Similarity

Consider two concepts x and y, each one of which is represented by the binary feature vector form, where n is the dimension of the feature vector. Table 1 presents a binary similarity measure based on the operational taxonomic units (OTU) [38]. This approach is widely used to define the binary similarity measures in a 2 × 2 contingency table. The “positive match” is denoted by a, meaning that the number of features where the values of x and y are equal to 1. “x absence mismatches” is denoted by b, meaning that the number of features where the value of x and y is (0,1). “y absence mismatches” is denoted by c, meaning that the number of attributes where the value of x and y is (1,0). The “negative match” is denoted by d, meaning that the number of attributes

where both x and y are equal to 0. The total number of matches between x and y is represented by diagonal sum (a + d). The total number of mismatches between x and y is represented by another diagonal sum (b + c). The total sum of the 2 × 2 table (a + b + c + d) is always n. The binary similarity measures are used in pattern analysis techniques, such as clustering and classification [39].

The choice of the Jaccard distance measure was rationalized in the previous work of authors [28]. The case studies on different examples showed consistent results when using the Jaccard distance measure in comparison to other measures; it does not account for similar negatives (i.e., the options that are not used in the concept).

Next, the binary distance between the concepts is calculated using the Jaccard similarity measure formula:

$$S_{\text{Jaccard}} = a/(n-d) = a/((a+b+c)) \quad (1)$$

## 4 | Suborbital Human Spaceflight Case Study

The sizing of suborbital spaceflight systems has been investigated by several authors. Frank [38] uses a design framework combined with metaheuristic algorithms to find the optimal design for four concepts, optimizing additionally with business variables [40]. Based on Frank [41], a previous body of work by [42] explored 33 different concepts of suborbital spaceflight systems and assessed the general commercial viability of the industry [43].

They found that given the right management of development, suborbital vehicles can generate positive net present value. In that, the size of the vehicle and the expansion strategy are key decisions. Furthermore, their simulation-based trade-space optimization revealed that only six out of the 33 concepts are dominant in a safety-cost trade-off space. However, by establishing the design space with the 33 concepts, the authors in [43] did not consider the similarity between different concepts, which is the objective of this work. In this paper, the “Blue Origin” concept is considered in addition to these six architectures.

As described in Section 3, there are five steps in the framework for similarity assessment of the engineering concepts. In subsequent Sections, these steps are described for a suborbital human spaceflight case study.
<figure><img src="image_3.png" /><figcaption>FIGURE 2 | Suborbital human spaceflight system in OPD diagram.</figcaption></figure>

**4.1 | Encoding Conceptual Data for the Suborbital Concepts Using SCRF Framework**

The proposed framework for suborbital concepts has an Object-Process Diagram (OPD) representation [37] built in OPCloud environment [34] and shown in Figure 2. This diagram illustrates that the first architectural decision to be made by systems engineers is the number of modules.

Aligned with [42], a module is defined as a system that separates
during flight and lands independently. The vehicle can consist
of either one or two modules. This decision defines whether the
system concept has one module, as it is, for example, for the
“XCOR” concept, or two modules as it is, for instance, in the case
of the “Blue Origin” concept. This decision is shown in the OPD
of Figure 2 and correspondingly in the architectural decision table
(see the first row in Table 2). Based on the information encoded in
OPD, the systems engineer can develop the architectural decision
table. Its full representation for suborbital concepts is demon-
strated in Table 2, and is taken from OPD of Figure 2, which also
encodes the information about traceability to the decisions.

As such, Figure 2 illustrates that regardless of the chosen subor-
bital concept, any of them should perform three fundamental pro-
cesses: “Launching,” “Flying,” and “Landing.” The instruments
assigned to those processes lead to the fundamental differences
between the competing suborbital solutions (see Figure 2).

**4.2 | Example of System Model for “Blue Origin” Concept**

Figure 3 illustrates an example of “Blue Origin” concept decom-
position into its two modules — “Propulsion Module” and “Crew

Capsule” (the decomposition is denoted in Figure 3 as a filled-in
triangle). It also stores the data that the entire system is launched
vertically (Decision #2) by the rocket engine (Decision #3).

Consider Module 1, which is the “Propulsion Module” (see Figure 4). Conceptual modeling informs about the absence of either pilots or passengers inside this module (Decisions #4 and #5, respectively.) It also stores information about the absence of the lifting instrument for the “Propulsion Module” (Decision #6), and the usage of the aerodynamic surfaces for the module’s “Guiding” process (Decision #7). Another important conceptual information is that the “Propulsion Module” lands vertically (Decision #10) using its rocket engine and landing gear (Decision #11).

Similarly, Module 2 is defined as the “Crew Capsule” (see Figure 5). The capsule does not have any pilots (Decision #12), yet it carries six passengers (Decision #13). This is exactly what brings value to the operation of the whole system. The capsule uses thrusters for the “Guiding” process (Decision #15). The aerodynamic decelerators are decreasing the capsule’s energy (Decision #17). The “Crew Capsule” lands vertically (Decision #18) deploying its parachutes (Decision #19).

These are examples of the models built for “Blue Origin” concept
using the approach presented in Figure 2.

**4.3 | Architectural Decisions Table for Suborbital Concepts**

One form of utility of the proposed framework is that it informs
systems engineers, engineering design teams, and decision-
makers about the core entries of the architectural decision table
<table><caption>TABLE 2 | Architectural decision table for suborbital human spaceflight concepts.</caption><thead><tr><th></th><th>Decision #</th><th>Option 1</th><th>Option 2</th><th>Option 3</th><th>Option 4</th><th>Option 5</th><th>Option 6</th><th>Option 7</th></tr></thead><tbody><tr><td><strong>General</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Number of modules</td><td>1</td><td>1</td><td>2</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>Launching</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Type of launch</td><td>2</td><td>Horizontal</td><td>Vertical</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Instrument of launching</td><td>3</td><td>Landing gear</td><td>Rocket engine</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>General 1</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Number of pilots</td><td>4</td><td>0</td><td>1</td><td>2</td><td></td><td></td><td></td><td></td></tr><tr><td>Number of passengers</td><td>5</td><td>0</td><td>1</td><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td></tr><tr><td><strong>Flying 1</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Lifting</td><td>6</td><td>Wing</td><td>None</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Guiding</td><td>7</td><td>Aerodynamic surfaces</td><td>Rocket engine</td><td>Thrusters</td><td>None</td><td></td><td></td><td></td></tr><tr><td>Increasing energy of module</td><td>8</td><td>Jet engine</td><td>Rocket engine</td><td>Jet engine + Rocket engine</td><td>None</td><td></td><td></td><td></td></tr><tr><td>Decreasing energy of module</td><td>9</td><td>Aerodynamic decelerators</td><td>Jet engine</td><td>Rocket engine</td><td>Wings</td><td>Rocket engine + wings</td><td>None</td><td></td></tr><tr><td><strong>Landing 1</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Type of landing</td><td>10</td><td>Horizontal</td><td>Vertical</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Instrument of landing</td><td>11</td><td>Landing gear</td><td>Rocket engine</td><td>Parachute</td><td>Land gear + Rocket engine</td><td></td><td></td><td></td></tr><tr><td><strong>General 2</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Number of pilots</td><td>12</td><td>0</td><td>1</td><td>2</td><td></td><td></td><td></td><td></td></tr><tr><td>Number of passengers</td><td>13</td><td>0</td><td>1</td><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td></tr><tr><td><strong>Flying 2</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Lifting</td><td>14</td><td>Wing</td><td>None</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Guiding</td><td>15</td><td>Aerodynamic surfaces</td><td>Rocket engine</td><td>Thrusters</td><td>Aerodynamic surfaces + thrusters</td><td>None</td><td></td><td></td></tr><tr><td>Increasing energy of module</td><td>16</td><td>Jet engine</td><td>Rocket engine</td><td>None</td><td></td><td></td><td></td><td></td></tr><tr><td>Decreasing energy of module</td><td>17</td><td>Aerodynamic decelerators</td><td>Jet engine</td><td>Rocket engine</td><td>Wings</td><td>None</td><td></td><td></td></tr><tr><td><strong>Landing 2</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Type of landing</td><td>18</td><td>Horizontal</td><td>Vertical</td><td>None</td><td></td><td></td><td></td><td></td></tr><tr><td>Instrument of landing</td><td>19</td><td>Landing gear</td><td>Rocket engine</td><td>Parachute</td><td>None</td><td></td><td></td><td></td></tr></tbody></table>

[44]. Such a table is used to encode all possible concepts, and their sub-systems and allocate such sub-systems to the functions they perform. Ultimately, any possible concept to be developed for a specific mission is represented by a combination of specific entries in each line of Table 2.

The architectural decision table is constructed based on the OPD representation described in Section 4.1. It includes additional details compared to the representation of [43] to capture the

additional attributes of the concept framework. There are three decisions on the vehicle level (Decisions #1–3 in Table 2) and eight decisions per module (Decisions #4–11 & #12–19 in Table 2). Hence, for a one-module vehicle, the architect makes 11 decisions, and for a two-modules vehicle – 19 decisions.

The architectural decisions related to the vehicle consist of the “Number of modules” (Decision #1 in Table 2), “Type of launch” (Decision #2), and “Instrument of launching” (Decision #3).
<figure><img src="image_4.png" /><figcaption>FIGURE 4 | Architectural decisions for the “Propulsion Module”.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>FIGURE 5 | Architectural decisions for the “Crew Capsule”.</figcaption></figure>
<table><caption>TABLE 3 | OTU values for the function “Launching” for concepts Blue Origin and Copenhagen.</caption><thead><tr><td>OTU element</td><td>Value</td></tr></thead><tbody><tr><td>a</td><td>2</td></tr><tr><td>b</td><td>0</td></tr><tr><td>c</td><td>0</td></tr><tr><td>d</td><td>2</td></tr></tbody></table>

<table><caption>TABLE 4 | Weights assigned to the architectural decisions.</caption><thead><tr><td></td><td>Relative weight</td><td>Abs. weight</td></tr></thead><tbody><tr><td>General</td><td>4</td><td>0.20</td></tr><tr><td>Launching</td><td>1</td><td>0.05</td></tr><tr><td>General 1</td><td>4</td><td>0.20</td></tr><tr><td>Flying 1</td><td>4</td><td>0.20</td></tr><tr><td>Landing 1</td><td>4</td><td>0.20</td></tr><tr><td>General 2</td><td>1</td><td>0.05</td></tr><tr><td>Flying 2</td><td>1</td><td>0.05</td></tr><tr><td>Landing 2</td><td>1</td><td>0.05</td></tr></tbody></table>

<table><caption>TABLE 5 | Similarity scores among the functions of the concepts Blue Origin and Copenhagen.</caption><thead><tr><td></td><td>Similarity score (S_jaccard)</td><td>Absolute weight (w)</td></tr></thead><tbody><tr><td>General</td><td>0.0</td><td>0.20</td></tr><tr><td>Launching</td><td>1.0</td><td>0.05</td></tr><tr><td>General 1</td><td>0.3</td><td>0.20</td></tr><tr><td>Flying 1</td><td>0.3</td><td>0.20</td></tr><tr><td>Landing 1</td><td>0.3</td><td>0.20</td></tr><tr><td>General 2</td><td>0.0</td><td>0.05</td></tr><tr><td>Flying 2</td><td>0.0</td><td>0.05</td></tr><tr><td>Landing 2</td><td>0.0</td><td>0.05</td></tr></tbody></table>

Next, the similarity between the form of “Launching” for both concepts is computed as follows:

$$S_{jaccard\_launching} = \frac{a}{a+b+c} = \frac{2}{2+0+0} = 1$$

The same process is iterated for the other functions. Once the similarity scores for each function are established, it is then normalized and aggregated properly to get an overall similarity value between the alternative concepts.

$$S_{jaccard} = S_{jaccard-general1} \cdot w_{general_1} + \cdots + S_{jaccard-landing2} \cdot w_{landing2}$$

The weights and similarity scores for each function can be seen in Tables 4 and 5, respectively. Using the formula, a similarity score of 0.25 between the concepts of Blue Origin and Copenhagen

is calculated. In the next section, this value is put in context by comparing the seven suborbital vehicle concepts.

## 5 | Results and Discussion

By applying the approach presented in Section 3, a quantitative measure of the similarity between suborbital vehicle concepts can be assessed, as described in Section 4. The results are shown in Table 6 as a matrix with the similarity value between different concepts in columns and rows. Table 6 illustrates that the concepts “XCOR” and “Shuttle” have the highest similarity score 0.67. On the other hand, the concepts “Copenhagen” and “Virgin Galactic” have the lowest similarity score 0 (highest dissimilarity). This can be explained as follows. Both concepts, “XCOR” and “Shuttle” consist of one module and have the same concept for “Launching” and “Landing” (see Table 2 and Table A1). On the other hand, the concepts “Virgin Galactic” and “Copenhagen” have no common architectural decisions in the list that was composed for the evaluation.

In addition to the quantitative similarity assessment, the results can serve as a cost proxy. This can be seen if, for example, systems engineers and decision-makers consider changing a concept with two modules to a concept with one module. The conceptual similarity score is small between the two concepts (one module and two modules), which will be reflected in costs as well. While this might be intuitive and trivial in our example, this is not the case if the concepts under consideration contain hundreds or thousands of architectural decisions.

The value of the presented similarity assessment is that it can be applied to alternative concepts in different industries for a variety of systems and products.

The benefit of using the proposed approach is that it provides the mathematical rigorousness to the alternative concepts or their subsystems/components evaluation. The methodology though would require the access to the domain experts to align the core architectural decisions with them.

## 6 | Conclusion

This paper presents the decision-making support and conceptual similarity assessment approach to evaluate alternative concepts to support systems engineers, engineering design teams, and decision-makers with the informed decision-making process while designing innovative solutions. To demonstrate its utility, the approach has been applied to the suborbital human spaceflight concept development and analysis. Such a framework is supported by the model-based system architecture approach to developing the architectural decisions table and can systematically represent suborbital concepts and their constituents. The focus was made on seven alternative concepts aiming at suborbital spaceflight capability. The utility of the approach is that it can also be applied to the system/product concepts in different industries.

In this work, we demonstrated how the proposed framework facilitates the process of architectural decision development and
<table><caption>TABLE 6 | Similarity between pairs of suborbital vehicle concepts.</caption><thead><tr><th>Similarity score</th><th>Blue origin</th><th>Virgin galactic</th><th>2-stage spaceplane</th><th>XCOR</th><th>Copenhagen</th><th>Rocketplane</th><th>Shuttle concept</th></tr></thead><tbody><tr><th>Blue origin</th><td>1.00</td><td>0.31</td><td>0.35</td><td>0.07</td><td>0.25</td><td>0.03</td><td>0.12</td></tr><tr><th>Virgin galactic</th><td>0.31</td><td>1.00</td><td>0.61</td><td>0.32</td><td>0.00</td><td>0.32</td><td>0.27</td></tr><tr><th>2-stage spaceplane</th><td>0.35</td><td>0.61</td><td>1.00</td><td>0.52</td><td>0.03</td><td>0.38</td><td>0.47</td></tr><tr><th>XCOR</th><td>0.07</td><td>0.32</td><td>0.52</td><td>1.00</td><td>0.30</td><td>0.58</td><td>0.67</td></tr><tr><th>Copenhagen</th><td>0.25</td><td>0.00</td><td>0.03</td><td>0.30</td><td>1.00</td><td>0.20</td><td>0.28</td></tr><tr><th>Rocketplane</th><td>0.03</td><td>0.32</td><td>0.38</td><td>0.58</td><td>0.20</td><td>1.00</td><td>0.53</td></tr><tr><th>Shuttle concept</th><td>0.12</td><td>0.27</td><td>0.47</td><td>0.67</td><td>0.28</td><td>0.53</td><td>1.00</td></tr></tbody></table>

the formal analysis, such as conceptual similarity assessment, which is used as a proxy of cost of change from one concept to another.

One form of the utility of the proposed framework is that it allows encoding unstructured data into a set of texts and models, which are consistent with each other. Such unstructured data might be found in a variety of documents specifying suborbital space projects, fuzzy stated stakeholder needs, and variations in experts' opinions. The proposed approach specifies the core information that is required for suborbital concept development from the early phase of the design process.

Another form of utility is that the proposed framework provides a systematic approach to architectural decision table development. Having such a framework, system engineers can develop the architectural decision table, which is shown in the paper for the suborbital concepts. Ultimately, systems engineers, engineering design teams, and decision-makers are empowered with a tool to support the decision-making process.

An important practical utility of the approach is that it can be used as a tool to analyze alternative concepts to define the conceptual similarity between them. Such a quantitative assessment can be used as a proxy for the cost of change between alternative suborbital concepts. Applying the proposed approach to seven alternative concepts, it is shown that such concepts as “XCOR” and “Shuttle” have the highest similarity scores, whereas the concepts “Copenhagen” and “Virgin Galactic” have the lowest similarity scores.

The future work will focus on the enlargement of the quantitative assessments enabled by the proposed framework. In particular, there is an opportunity to assess the elements' criticality to define which subsystem is the most critical one for the entire system. Engaging the generative design for this and contributing to [45] is another avenue for future work.

Another direction of future work is related to the potential contribution to the tradeoff analysis, particularly, to the tradespace exploration [46]. The recommendation to change the components A to B could be made based on a conceptual similarity assessment made following the approach presented in this paper.

The generic nature of the approach make it useful for any domain application. Therefore, the authors expect the application of the proposed framework to the variety of industrial sectors — MedTech and automotive are among the first candidates.

## Data Availability Statement

The data that support the findings of this study are available from the corresponding author upon reasonable request.

## References

1. S. Y. Lang, J. Dickinson, and R. O. Buchal, “Cognitive Factors in Distributed Design,” *Computers in Industry* 48, no. 1 (2002): 89–98, https://doi.org/10.1016/S0166-3615(02)00012-X.

2. M. Daily, M. Howard, J. Jerald et al., “Distributed Design Review in Virtual Environments,” in *Proceedings of the third International Conference on Collaborative Virtual Environments*, (2000), 57–63, https://doi.org/10.1145/351006.351013.

3. T. T. Hoa Tran, G. Foucault, and R. Pinquié, “Direct Solid Modelling in Virtual Reality for Systems Architecting,” *Procedia CIRP* 128 (2024): 656–661, https://doi.org/10.1016/j.procir.2024.08.230.

4. A. M. Madni and E. D. MBSE, “Testbed for Unmanned Vehicles: System Concept and Prototype Implementation,” *Handbook of Model-Based Systems Engineering* (Springer International Publishing, 2023), 675–704, https://doi.org/10.1007/978-3-030-93582-5_39.

5. B. Prasad, *Concurrent Engineering Fundamentals* (Prentice Hall PTR, 1996).

6. D. Knoll, C. Fortin, and A. Golkar, “A Process Model for Concurrent Conceptual Design of Space Systems,” *Systems Engineering* 24, no. 4 (2021): 234–249, https://doi.org/10.1002/sys.21576.

7. M. Bandecchi, B. Melton, and F. Ongaro, “Concurrent Engineering Applied to Space Mission Assessment and Design,” *European Space Agency Bulletin* (1999): 99.

8. D. Di Domizio and P. Gaudenzi, “A Model for Preliminary Design Procedures of Satellite Systems,” *Concurrent Engineering* 16, no. 2 (2008): 149–159, https://doi.org/10.1177/1063293x08092488.

9. W. Shen, Q. Hao, and W. Li, “Computer Supported Collaborative Design: Retrospective and Perspective,” *Computers in Industry* 59, no. 9 (2008): 855–862, https://doi.org/10.1016/j.compind.2008.07.001.

10. H. Johannesson, J. Landahl, C. Levandowski, and D. Raudberget, “Development of Product Platforms: Theory and Methodology,” *Concurrent Engineering* 25, no. 3 (2017): 195–211, https://doi.org/10.1177/1063293x17709866.
11. R. Boas, B. G. Cameron, and E. F. Crawley, "Divergence and Lifecycle Offsets in Product Families With Commonality," *Systems Engineering* 16, no. 2 (2013): 175-192, https://doi.org/10.1002/sys.21223.

12. T. W. Simpson, J. R. Maier, and F. Mistree, "Product Platform Design: Method and Application," *Research in Engineering Design* 13 (2001): 2-22, https://doi.org/10.1007/s001630100002.

13. C. Eckert, O. Isaksson, S. Lebjioui, C. Earl, and S. Edlund, "Design Margins in Industrial Practice," *Design Science* 6 (2020): 1-36, https://doi.org/10.1017/dsj.2020.19.

14. C. Eckert, O. Isaksson, and C. Earl, "Design Margins: A Hidden Issue in Industry," *Design Science* 5 (2019): 1-24, https://doi.org/10.1017/dsj.2019.7.

15. J. F. Maier, C. M. Eckert, and P. John Clarkson, "Model Granularity in Engineering Design — Concepts and Framework," *Design Science* 3 (2017): 1-29, https://doi.org/10.1017/dsj.2016.16.

16. M. Ilyas and J Kung, "A Similarity Measurement Framework for Requirements Engineering," in *2009 Fourth International Multi-Conference on Computing in the Global Information Technology*, (IEEE, 2009), 31-34, https://doi.org/10.1109/ICCGI.2009.12.

17. D. B. Leake, A. G. Maguitman, and A. J. Cañas, "Assessing Conceptual Similarity to Support Concept Mapping," *FLAIRS* (2002): 168-172.

18. P. Darm, A. Berquand, L. Mansilla, and A. Riccardi, "A System Engineering Recommendation System Based on Language Similarity Analysis: An Application to Space Systems Conceptual Design," in *10th International Systems & Concurrent Engineering for Space Applications Conference (SECESA 2022)*, (European Space Agency, 2022).

19. R. Henkel, R. Hoehndorf, T. Kacprowski, C. Knüpfer, W. Liebermeister, and D. Waltemath, "Notions of Similarity for Systems Biology Models," *Briefings in Bioinformatics* 19, no. 1 (2013): 77-88, https://doi.org/10.1093/bib/bbw090.

20. S. A. Elavarasi, J. Akilandeswari, and K. T. Menaga, "A Survey on Semantic Similarity Measure," *International Journal of Research in Advent Technology* 2, no. 3 (2014): 389-398.

21. F. Ashby and D. Ennis, "Similarity Measures," *Scholarpedia* 2, no. 12 (2007): 4116, https://doi.org/10.4249/scholarpedia.4116.

22. A. W. Wymore, *Model-Based Systems Engineering* (CRC Press, 1993), https://doi.org/10.1201/9780203746936.

23. INCOSE. *Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities* (Wiley, 2023).

24. A. E. Trujillo and A. M. Madni, "Exploration of MBSE Methods for Inheritance and Design Reuse in Space missions," *Recent Trends and Advances in Model Based Systems Engineering* (Springer International Publishing, 2022), 553-564, https://doi.org/10.1007/978-3-030-82083-1_47.

25. Y. Menshenin and R. Pinquié, "The Influence of Human-Systems Integration on "Fuzzy Front End" of Innovation: A MedTech Case Study," in *Proceedings of the INCOSE Human-Systems Integration Conference*, (2024).

26. A. Madni and N. Augustine, *Handbook of Model-Based Systems Engineering* (Springer International Publishing, 2023).

27. P. De Saqui-Sannes, R. A. Vingerhoeds, C. Garion, and X. Thirioux, "A Taxonomy of MBSE Approaches by Languages, Tools and Methods," *Institute of Electrical and Electronics Engineers Access* 10 (2022): 120936-120950, https://doi.org/10.1109/ACCESS.2022.3222387.

28. B. Cameron and D. M. Adsit, "Model-Based Systems Engineering Uptake in Engineering Practice," *IEEE Transactions on Engineering Management* 67, no. 1 (2018): 152-162, https://doi.org/10.1109/TEM.2018.2863041.

29. Y. Menshenin, Y. Mordecai, E. F. Crawley, and B. G. Cameron, *Model-Based System Architecting and Decision-Making. Handbook of Model-Based Systems Engineering* (Springer International Publishing, 2022), 289-330, https://doi.org/10.1007/978-3-030-27486-3_17-1.

30. Y. Menshenin, "Model-Based Framework for System Concept," (PhD Thesis, Skoltech, 2020).

31. S Alsalehi, "Similarity in Design: A Framework for Evaluation," (M.Sc. Thesis, Skoltech, 2019).

32. Y. Menshenin and E. F. Crawley, "A System Concept Representation Framework and Its Testing on Patents, Urban Architectural Patterns, and Software Patterns," *Systems Engineering* 23, no. 4 (2020): 492-515, https://doi.org/10.1002/sys.21547.

33. B. W. Stirgwolt, T. A. Mazzuchi, and S. Sarkani, "A Model-Based Systems Engineering Approach for Developing Modular System Architectures," *Journal of Engineering Design* 33, no. 2 (2022): 95-119, https://doi.org/10.1080/09544828.2021.1980203.

34. D. Dori, H. Kohen, A. Jbara, et al., "OPCloud: An OPM Integrated Conceptual-conceptual Executable Modeling Environment for Industry 4.0," *Systems Engineering in the Fourth Industrial Revolution* (2019): 243-271, https://doi.org/10.1002/9781119513957.ch11.

35. K. Kernschmidt, S. Feldmann, and B. Vogel-Heuser, "A Model-Based Framework for Increasing the Interdisciplinary Design of Mechatronic Production Systems," *Journal of Engineering Design* 29, no. 11 (2018): 617-643, https://doi.org/10.1080/09544828.2018.1520205.

36. A. Madni and M. Sievers, "Model-Based Systems Engineering: Motivation, Current Status, and Research Opportunities," *Systems Engineering* 21, no. 3 (2018): 172-190, https://doi.org/10.1002/sys.21438.

37. D. Dori, *Object-Process Methodology: A Holistic Systems Paradigm* (Springer Science & Business Media, 2002).

38. B. S. Everitt and G. Dunn, *An Introduction to Mathematical Taxonomy* (Cambridge University, 1982).

39. S. S. Choi, S. H. Cha, and C. C. Tappert, "A Survey of Binary Similarity and Distance Measures," *Journal of Systemics, Cybernetics and Informatics* 8, no. 1 (2010): 43-48.

40. F. Burgaud, C. Frank, and D. N. Mavris, "A Business-Driven Optimization Methodology Applied to Suborbital Vehicle Programs," *American Institute of Aeronautics and Astronautics Space 2016* (2016): 1-26, https://doi.org/10.2514/6.2016-5248.

41. C. Frank, O. J. Pinon-Fischer, and D. N Mavris, "Design Space Exploration Methodology to Support Decisions under Evolving Requirements' Uncertainty and Its Application to Suborbital Vehicles," in *53rd AIAA Aerospace Sciences Meeting*, https://doi.org/10.2514/6.2015-1010.

42. M. Guerster and E. F. Crawley, "Dominant Suborbital Space Tourism Architectures," *Journal of Spacecraft and Rockets* 56, no. 5 (2019): 1580-1592, https://doi.org/10.2514/1.A34385.

43. M. Guerster, E. F. Crawley, and R. de Neufville, "Commercial Viability Evaluation of the Suborbital Space Tourism Industry," *New Space* 7, no. 2 (2019): 79-92, https://doi.org/10.1089/space.2018.0038.

44. E. F. Crawley, B. G. Cameron, and D. Selva, *System Architecture: Strategy and Product Development for Complex Systems* (Prentice Hall Press, 2015).

45. T. McDermott, D. DeLaurentis, P. Beling, M. Blackburn, and M. Bone, "AI4SE and SE4AI: A Research Roadmap," *Insight (American Society of Ophthalmic Registered Nurses)* 23, no. 1 (2020): 8-14, https://doi.org/10.1002/inst.12278.

46. A. M. Ross and D. E Hastings, "The Tradespace Exploration Paradigm," in *INCOSE International Symposium*, (2005).

## Appendix

See Table A1.
<table><caption>TABLE A1 | Architectural decisions for seven suborbital vehicle concepts that were used in the case study. The numbers in the cells correspond to the option number from Table 2.</caption><thead><tr><th></th><th>Blue<br>origin</th><th>Virgin<br>galactic</th><th>XCOR</th><th>Copenhagen</th><th>Rocketplane</th><th>2-stage<br>spaceplane</th><th>Shuttle<br>concept</th></tr></thead><tbody><tr><td><strong>General</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Number of modules</td><td>2</td><td>2</td><td>1</td><td>1</td><td>1</td><td>2</td><td>1</td></tr><tr><td><strong>Launching</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Type of launch</td><td>2</td><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>2</td></tr><tr><td>Instrument of launching</td><td>2</td><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>2</td></tr><tr><td><strong>General 1</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Number of pilots</td><td>1</td><td>3</td><td>2</td><td>1</td><td>2</td><td>2</td><td>2</td></tr><tr><td>Number of passengers</td><td>1</td><td>1</td><td>2</td><td>2</td><td>6</td><td>1</td><td>5</td></tr><tr><td><strong>Flying 1</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Lifting</td><td>2</td><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Guiding</td><td>1</td><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Increasing energy of module</td><td>2</td><td>1</td><td>2</td><td>2</td><td>3</td><td>2</td><td>2</td></tr><tr><td>Decreasing energy of module</td><td>2</td><td>3</td><td>4</td><td>1</td><td>5</td><td>4</td><td>4</td></tr><tr><td><strong>Landing 1</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Type of landing</td><td>2</td><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Instrument of landing</td><td>4</td><td>1</td><td>1</td><td>3</td><td>1</td><td>1</td><td>1</td></tr><tr><td><strong>General 2</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Number of pilots</td><td>1</td><td>3</td><td>0</td><td>0</td><td>0</td><td>2</td><td>0</td></tr><tr><td>Number of passengers</td><td>7</td><td>7</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td></tr><tr><td><strong>Flying 2</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Lifting</td><td>2</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td></tr><tr><td>Guiding</td><td>3</td><td>4</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td></tr><tr><td>Increasing energy of module</td><td>3</td><td>2</td><td>0</td><td>0</td><td>0</td><td>2</td><td>0</td></tr><tr><td>Decreasing energy of module</td><td>1</td><td>2</td><td>0</td><td>0</td><td>0</td><td>4</td><td>0</td></tr><tr><td><strong>Landing 2</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Type of landing</td><td>2</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td></tr><tr><td>Instrument of landing</td><td>3</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td></tr></tbody></table>